386 files changed, 138279 insertions, 372619 deletions

diff --git a/appl/popper/pop3.rfc1081 b/appl/popper/pop3.rfc1081
deleted file mode 100644
index 08ea6dd14..000000000
--- a/appl/popper/pop3.rfc1081
+++ /dev/null
@@ -1,898 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            M. Rose
-Request for Comments: 1081                                           TWG
-                                                           November 1988
-
-                    Post Office Protocol - Version 3
-
-
-Status of this Memo
-
-   This memo suggests a simple method for workstations to dynamically
-   access mail from a mailbox server.  This RFC specifies a proposed
-   protocol for the Internet community, and requests discussion and
-   suggestions for improvements.  Distribution of this memo is
-   unlimited.
-
-   This memo is based on RFC 918 (since revised as RFC 937).  Although
-   similar in form to the original Post Office Protocol (POP) proposed
-   for the Internet community, the protocol discussed in this memo is
-   similar in spirit to the ideas investigated by the MZnet project at
-   the University of California, Irvine.
-
-   Further, substantial work was done on examining POP in a PC-based
-   environment.  This work, which resulted in additional functionality
-   in this protocol, was performed by the ACIS Networking Systems Group
-   at Stanford University.  The author gratefully acknowledges their
-   interest.
-
-Introduction
-
-   On certain types of smaller nodes in the Internet it is often
-   impractical to maintain a message transport system (MTS).  For
-   example, a workstation may not have sufficient resources (cycles,
-   disk space) in order to permit a SMTP server and associated local
-   mail delivery system to be kept resident and continuously running.
-   Similarly, it may be expensive (or impossible) to keep a personal
-   computer interconnected to an IP-style network for long amounts of
-   time (the node is lacking the resource known as "connectivity").
-
-   Despite this, it is often very useful to be able to manage mail on
-   these smaller nodes, and they often support a user agent (UA) to aid
-   the tasks of mail handling.  To solve this problem, a node which can
-   support an MTS entity offers a maildrop service to these less endowed
-   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
-   permit a workstation to dynamically access a maildrop on a server
-   host in a useful fashion.  Usually, this means that the POP3 is used
-   to allow a workstation to retrieve mail that the server is holding
-   for it.
-
-
-
-
-Rose                                                            [Page 1]
-
-RFC 1081                          POP3                     November 1988
-
-
-   For the remainder of this memo, the term "client host" refers to a
-   host making use of the POP3 service, while the term "server host"
-   refers to a host which offers the POP3 service.
-
-A Short Digression
-
-   This memo does not specify how a client host enters mail into the
-   transport system, although a method consistent with the philosophy of
-   this memo is presented here:
-
-      When the user agent on a client host wishes to enter a message
-      into the transport system, it establishes an SMTP connection to
-      its relay host (this relay host could be, but need not be, the
-      POP3 server host for the client host).
-
-   If this method is followed, then the client host appears to the MTS
-   as a user agent, and should NOT be regarded as a "trusted" MTS entity
-   in any sense whatsoever.  This concept, along with the role of the
-   POP3 as a part of a split-UA model is discussed later in this memo.
-
-   Initially, the server host starts the POP3 service by listening on
-   TCP port 110.  When a client host wishes to make use of the service,
-   it establishes a TCP connection with the server host.  When the
-   connection is established, the POP3 server sends a greeting.  The
-   client and POP3 server then exchange commands and responses
-   (respectively) until the connection is closed or aborted.
-
-   Commands in the POP3 consist of a keyword possibly followed by an
-   argument.  All commands are terminated by a CRLF pair.
-
-   Responses in the POP3 consist of a success indicator and a keyword
-   possibly followed by additional information.  All responses are
-   terminated by a CRLF pair.  There are currently two success
-   indicators: positive ("+OK") and negative ("-ERR").
-
-   Responses to certain commands are multi-line.  In these cases, which
-   are clearly indicated below, after sending the first line of the
-   response and a CRLF, any additional lines are sent, each terminated
-   by a CRLF pair.  When all lines of the response have been sent, a
-   final line is sent, consisting of a termination octet (decimal code
-   046, ".") and a CRLF pair.  If any line of the multi-line response
-   begins with the termination octet, the line is "byte-stuffed" by
-   pre-pending the termination octet to that line of the response.
-   Hence a multi-line response is terminated with the five octets
-   "CRLF.CRLF".  When examining a multi-line response, the client checks
-   to see if the line begins with the termination octet.  If so and if
-   octets other than CRLF follow, the the first octet of the line (the
-   termination octet) is stripped away.  If so and if CRLF immediately
-
-
-
-Rose                                                            [Page 2]
-
-RFC 1081                          POP3                     November 1988
-
-
-   follows the termination character, then the response from the POP
-   server is ended and the line containing ".CRLF" is not considered
-   part of the multi-line response.
-
-   A POP3 session progresses through a number of states during its
-   lifetime.  Once the TCP connection has been opened and the POP3
-   server has sent the greeting, the session enters the AUTHORIZATION
-   state.  In this state, the client must identify itself to the POP3
-   server.  Once the client has successfully done this, the server
-   acquires resources associated with the client's maildrop, and the
-   session enters the TRANSACTION state.  In this state, the client
-   requests actions on the part of the POP3 server.  When the client has
-   finished its transactions, the session enters the UPDATE state.  In
-   this state, the POP3 server releases any resources acquired during
-   the TRANSACTION state and says goodbye.  The TCP connection is then
-   closed.
-
-The AUTHORIZATION State
-
-   Once the TCP connection has been opened by a POP3 client, the POP3
-   server issues a one line greeting.  This can be any string terminated
-   by CRLF.  An example might be:
-
-      S.  +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU)
-
-   Note that this greeting is a POP3 reply.  The POP3 server should
-   always give a positive response as the greeting.
-
-   The POP3 session is now in the AUTHORIZATION state.  The client must
-   now issue the USER command.  If the POP3 server responds with a
-   positive success indicator ("+OK"), then the client may issue either
-   the PASS command to complete the authorization, or the QUIT command
-   to terminate the POP3 session.  If the POP3 server responds with a
-   negative success indicator ("-ERR") to the USER command, then the
-   client may either issue a new USER command or may issue the QUIT
-   command.
-
-   When the client issues the PASS command, the POP3 server uses the
-   argument pair from the USER and PASS commands to determine if the
-   client should be given access to the appropriate maildrop.  If so,
-   the POP3 server then acquires an exclusive-access lock on the
-   maildrop.  If the lock is successfully acquired, the POP3 server
-   parses the maildrop into individual messages (read note below),
-   determines the last message (if any) present in the maildrop that was
-   referenced by the RETR command, and responds with a positive success
-   indicator.  The POP3 session now enters the TRANSACTION state.  If
-   the lock can not be acquired or the client should is denied access to
-   the appropriate maildrop or the maildrop can't be parsed for some
-
-
-
-Rose                                                            [Page 3]
-
-RFC 1081                          POP3                     November 1988
-
-
-   reason, the POP3 server responds with a negative success indicator.
-   (If a lock was acquired but the POP3 server intends to respond with a
-   negative success indicator, the POP3 server must release the lock
-   prior to rejecting the command.)  At this point, the client may
-   either issue a new USER command and start again, or the client may
-   issue the QUIT command.
-
-                 NOTE: Minimal implementations of the POP3 need only be
-                 able to break a maildrop into its component messages;
-                 they need NOT be able to parse individual messages.
-                 More advanced implementations may wish to have this
-                 capability, for reasons discussed later.
-
-   After the POP3 server has parsed the maildrop into individual
-   messages, it assigns a message-id to each message, and notes the size
-   of the message in octets.  The first message in the maildrop is
-   assigned a message-id of "1", the second is assigned "2", and so on,
-   so that the n'th message in a maildrop is assigned a message-id of
-   "n".  In POP3 commands and responses, all message-id's and message
-   sizes are expressed in base-10 (i.e., decimal).
-
-   It sets the "highest number accessed" to be that of the last message
-   referenced by the RETR command.
-
-   Here are summaries for the three POP3 commands discussed thus far:
-
-           USER name
-               Arguments: a server specific user-id (required)
-               Restrictions: may only be given in the AUTHORIZATION
-                   state after the POP3 greeting or after an
-                   unsuccessful USER or PASS command
-               Possible Responses:
-                   +OK name is welcome here
-                   -ERR never heard of name
-               Examples:
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-                     ...
-                   C:    USER frated
-                   S:    -ERR sorry, frated doesn't get his mail here
-
-           PASS string
-               Arguments: a server/user-id specific password (required)
-               Restrictions: may only be given in the AUTHORIZATION
-                   state after a successful USER command
-               Possible Responses:
-                   +OK maildrop locked and ready
-                   -ERR invalid password
-
-
-
-Rose                                                            [Page 4]
-
-RFC 1081                          POP3                     November 1988
-
-
-                   -ERR unable to lock maildrop
-               Examples:
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-                   C:    PASS secret
-                   S:    +OK mrose's maildrop has 2 messages
-                         (320 octets)
-                     ...
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-                   C:    PASS secret
-                   S:    -ERR unable to lock mrose's maildrop, file
-                         already locked
-
-           QUIT
-               Arguments: none
-               Restrictions: none
-               Possible Responses:
-                   +OK
-               Examples:
-                   C:    QUIT
-                   S:    +OK dewey POP3 server signing off
-
-
-The TRANSACTION State
-
-   Once the client has successfully identified itself to the POP3 server
-   and the POP3 server has locked and burst the appropriate maildrop,
-   the POP3 session is now in the TRANSACTION state.  The client may now
-   issue any of the following POP3 commands repeatedly.  After each
-   command, the POP3 server issues a response.  Eventually, the client
-   issues the QUIT command and the POP3 session enters the UPDATE state.
-
-   Here are the POP3 commands valid in the TRANSACTION state:
-
-           STAT
-               Arguments: none
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 The POP3 server issues a positive response with a line
-                 containing information for the maildrop.  This line is
-                 called a "drop listing" for that maildrop.
-
-                 In order to simplify parsing, all POP3 servers are
-                 required to use a certain format for drop listings.
-                 The first octets present must indicate the number of
-                 messages in the maildrop.  Following this is the size
-
-
-
-Rose                                                            [Page 5]
-
-RFC 1081                          POP3                     November 1988
-
-
-                 of the maildrop in octets.  This memo makes no
-                 requirement on what follows the maildrop size.
-                 Minimal implementations should just end that line of
-                 the response with a CRLF pair.  More advanced
-                 implementations may include other information.
-
-                      NOTE: This memo STRONGLY discourages
-                      implementations from supplying additional
-                      information in the drop listing.  Other,
-                      optional, facilities are discussed later on
-                      which permit the client to parse the messages
-                      in the maildrop.
-
-                 Note that messages marked as deleted are not counted in
-                 either total.
-
-               Possible Responses:
-                   +OK nn mm
-               Examples:
-                   C:    STAT
-                   S:    +OK 2 320
-
-           LIST [msg]
-               Arguments: a message-id (optionally)  If a message-id is
-                   given, it may NOT refer to a message marked as
-                   deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 If an argument was given and the POP3 server issues a
-                 positive response with a line containing information
-                 for that message.  This line is called a "scan listing"
-                 for that message.
-
-                 If no argument was given and the POP3 server issues a
-                 positive response, then the response given is
-                 multi-line.  After the initial +OK, for each message
-                 in the maildrop, the POP3 server responds with a line
-                 containing information for that message.  This line
-                 is called a "scan listing" for that message.
-
-                 In order to simplify parsing, all POP3 servers are
-                 required to use a certain format for scan listings.
-                 The first octets present must be the message-id of
-                 the message.  Following the message-id is the size of
-                 the message in octets.  This memo makes no requirement
-                 on what follows the message size in the scan listing.
-                 Minimal implementations should just end that line of
-
-
-
-Rose                                                            [Page 6]
-
-RFC 1081                          POP3                     November 1988
-
-
-                 the response with a CRLF pair.  More advanced
-                 implementations may include other information, as
-                 parsed from the message.
-
-                      NOTE: This memo STRONGLY discourages
-                      implementations from supplying additional
-                      information in the scan listing.  Other, optional,
-                      facilities are discussed later on which permit
-                      the client to parse the messages in the maildrop.
-
-                 Note that messages marked as deleted are not listed.
-
-               Possible Responses:
-                   +OK scan listing follows
-                   -ERR no such message
-               Examples:
-                   C:    LIST
-                   S:    +OK 2 messages (320 octets)
-                   S:    1 120
-                   S:    2 200
-                   S:    .
-                     ...
-                   C:    LIST 2
-                   S:    +OK 2 200
-                     ...
-                   C:    LIST 3
-                   S:    -ERR no such message, only 2 messages in
-                         maildrop
-
-           RETR msg
-               Arguments: a message-id (required)  This message-id may
-                   NOT refer to a message marked as deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 If the POP3 server issues a positive response, then the
-                 response given is multi-line.  After the initial +OK,
-                 the POP3 server sends the message corresponding to the
-                 given message-id, being careful to byte-stuff the
-                 termination character (as with all multi-line
-                 responses).
-
-                 If the number associated with this message is higher
-                 than the "highest number accessed" in the maildrop, the
-                 POP3 server updates the "highest number accessed" to
-                 the number associated with this message.
-
-
-
-
-
-Rose                                                            [Page 7]
-
-RFC 1081                          POP3                     November 1988
-
-
-               Possible Responses:
-                   +OK message follows
-                   -ERR no such message
-               Examples:
-                   C:    RETR 1
-                   S:    +OK 120 octets
-                   S:    <the POP3 server sends the entire message here>
-                   S:    .
-
-           DELE msg
-               Arguments: a message-id (required)  This message-id
-                   may NOT refer to a message marked as deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 The POP3 server marks the message as deleted.  Any
-                 future reference to the message-id associated with the
-                 message in a POP3 command generates an error.  The POP3
-                 server does not actually delete the message until the
-                 POP3 session enters the UPDATE state.
-
-                 If the number associated with this message is higher
-                 than the "highest number accessed" in the maildrop,
-                 the POP3 server updates the "highest number accessed"
-                 to the number associated with this message.
-
-               Possible Responses:
-                   +OK message deleted
-                   -ERR no such message
-               Examples:
-                   C:    DELE 1
-                   S:    +OK message 1 deleted
-                     ...
-                   C:    DELE 2
-                   S:    -ERR message 2 already deleted
-
-           NOOP
-               Arguments: none
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 The POP3 server does nothing, it merely replies with a
-                 positive response.
-
-               Possible Responses:
-                   +OK
-
-
-
-
-
-Rose                                                            [Page 8]
-
-RFC 1081                          POP3                     November 1988
-
-
-               Examples:
-                   C:    NOOP
-                   S:    +OK
-
-           LAST
-               Arguments: none
-               Restrictions: may only be issued in the TRANSACTION state.
-               Discussion:
-
-                 The POP3 server issues a positive response with a line
-                 containing the highest message number which accessed.
-                 Zero is returned in case no message in the maildrop has
-                 been accessed during previous transactions.  A client
-                 may thereafter infer that messages, if any, numbered
-                 greater than the response to the LAST command are
-                 messages not yet accessed by the client.
-
-             Possible Response:
-                   +OK nn
-
-             Examples:
-                   C:      STAT
-                   S:      +OK 4 320
-                   C:      LAST
-                   S:      +OK 1
-                   C:      RETR 3
-                   S:      +OK 120 octets
-                   S:      <the POP3 server sends the entire message
-                           here>
-                   S:      .
-                   C:      LAST
-                   S:      +OK 3
-                   C:      DELE 2
-                   S:      +OK message 2 deleted
-                   C:      LAST
-                   S:      +OK 3
-                   C:      RSET
-                   S:      +OK
-                   C:      LAST
-                   S:      +OK 1
-
-           RSET
-               Arguments: none
-               Restrictions: may only be given in the TRANSACTION
-                   state.
-               Discussion:
-
-                 If any messages have been marked as deleted by the POP3
-
-
-
-Rose                                                            [Page 9]
-
-RFC 1081                          POP3                     November 1988
-
-
-                 server, they are unmarked.  The POP3 server then
-                 replies with a positive response.  In addition, the
-                 "highest number accessed" is also reset to the value
-                 determined at the beginning of the POP3 session.
-
-               Possible Responses:
-                   +OK
-               Examples:
-                   C:    RSET
-                   S:    +OK maildrop has 2 messages (320 octets)
-
-
-
-The UPDATE State
-
-   When the client issues the QUIT command from the TRANSACTION state,
-   the POP3 session enters the UPDATE state.  (Note that if the client
-   issues the QUIT command from the AUTHORIZATION state, the POP3
-   session terminates but does NOT enter the UPDATE state.)
-
-           QUIT
-               Arguments: none
-               Restrictions: none
-               Discussion:
-
-                 The POP3 server removes all messages marked as deleted
-                 from the maildrop.  It then releases the
-                 exclusive-access lock on the maildrop and replies as
-                 to the success of
-                 these operations.  The TCP connection is then closed.
-
-               Possible Responses:
-                   +OK
-               Examples:
-                   C:    QUIT
-                   S:    +OK dewey POP3 server signing off (maildrop
-                         empty)
-                     ...
-                   C:    QUIT
-                   S:    +OK dewey POP3 server signing off (2 messages
-                         left)
-                     ...
-
-
-Optional POP3 Commands
-
-   The POP3 commands discussed above must be supported by all minimal
-   implementations of POP3 servers.
-
-
-
-Rose                                                           [Page 10]
-
-RFC 1081                          POP3                     November 1988
-
-
-   The optional POP3 commands described below permit a POP3 client
-   greater freedom in message handling, while preserving a simple POP3
-   server implementation.
-
-                 NOTE: This memo STRONGLY encourages implementations to
-                 support these commands in lieu of developing augmented
-                 drop and scan listings.  In short, the philosophy of
-                 this memo is to put intelligence in the part of the
-                 POP3 client and not the POP3 server.
-
-           TOP msg n
-               Arguments: a message-id (required) and a number.  This
-                   message-id may NOT refer to a message marked as
-                   deleted.
-               Restrictions: may only be given in the TRANSACTION state.
-               Discussion:
-
-                 If the POP3 server issues a positive response, then
-                 the response given is multi-line.  After the initial
-                 +OK, the POP3 server sends the headers of the message,
-                 the blank line separating the headers from the body,
-                 and then the number of lines indicated message's body,
-                 being careful to byte-stuff the termination character
-                 (as with all multi-line responses).
-
-                 Note that if the number of lines requested by the POP3
-                 client is greater than than the number of lines in the
-                 body, then the POP3 server sends the entire message.
-
-               Possible Responses:
-                   +OK top of message follows
-                   -ERR no such message
-               Examples:
-                   C:    TOP 10
-                   S:    +OK
-                   S:    <the POP3 server sends the headers of the
-                          message, a blank line, and the first 10 lines
-                          of the body of the message>
-                   S:    .
-                     ...
-                   C:    TOP 100
-                   S:    -ERR no such message
-
-           RPOP user
-               Arguments: a client specific user-id (required)
-               Restrictions: may only be given in the AUTHORIZATION
-                   state after a successful USER command; in addition,
-                   may only be given if the client used a reserved
-
-
-
-Rose                                                           [Page 11]
-
-RFC 1081                          POP3                     November 1988
-
-
-                   (privileged) TCP port to connect to the server.
-               Discussion:
-
-                 The RPOP command may be used instead of the PASS
-                 command to authenticate access to the maildrop.  In
-                 order for this command to be successful, the POP3
-                 client must use a reserved TCP port (port < 1024) to
-                 connect tothe server.  The POP3 server uses the
-                 argument pair from the USER and RPOP commands to
-                 determine if the client should be given access to
-                 the appropriate maildrop.  Unlike the PASS command
-                 however, the POP3 server considers if the remote user
-                 specified by the RPOP command who resides on the POP3
-                 client host is allowed to access the maildrop for the
-                 user specified by the USER command (e.g., on Berkeley
-                 UNIX, the .rhosts mechanism is used).  With the
-                 exception of this differing in authentication, this
-                 command is identical to the PASS command.
-
-                 Note that the use of this feature has allowed much wider
-                 penetration into numerous hosts on local networks (and
-                 sometimes remote networks) by those who gain illegal
-                 access to computers by guessing passwords or otherwise
-                 breaking into the system.
-
-               Possible Responses:
-                   +OK maildrop locked and ready
-                   -ERR permission denied
-               Examples:
-                   C:    USER mrose
-                   S:    +OK mrose is a real hoopy frood
-                   C:    RPOP mrose
-                   S:    +OK mrose's maildrop has 2 messages (320
-                         octets)
-
-       Minimal POP3 Commands:
-           USER name               valid in the AUTHORIZATION state
-           PASS string
-           QUIT
-
-           STAT                    valid in the TRANSACTION state
-           LIST [msg]
-           RETR msg
-           DELE msg
-           NOOP
-           LAST
-           RSET
-
-
-
-
-Rose                                                           [Page 12]
-
-RFC 1081                          POP3                     November 1988
-
-
-           QUIT                    valid in the UPDATE state
-
-       Optional POP3 Commands:
-           RPOP user               valid in the AUTHORIZATION state
-
-           TOP msg n               valid in the TRANSACTION state
-
-       POP3 Replies:
-           +OK
-           -ERR
-
-       Note that with the exception of the STAT command, the reply given
-       by the POP3 server to any command is significant only to "+OK"
-       and "-ERR".  Any text occurring after this reply may be ignored
-       by the client.
-
-Example POP3 Session
-
-    S: <wait for connection on TCP port 110>
-        ...
-    C: <open connection>
-    S:    +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU)
-    C:    USER mrose
-    S:    +OK mrose is a real hoopy frood
-    C:    PASS secret
-    S:    +OK mrose's maildrop has 2 messages (320 octets)
-    C:    STAT
-    S:    +OK 2 320
-    C:    LIST
-    S:    +OK 2 messages (320 octets)
-    S:    1 120
-    S:    2 200
-    S:    .
-    C:    RETR 1
-    S:    +OK 120 octets
-    S:    <the POP3 server sends message 1>
-    S:    .
-    C:    DELE 1
-    S:    +OK message 1 deleted
-    C:    RETR 2
-    S:    +OK 200 octets
-    S:    <the POP3 server sends message 2>
-    S:    .
-    C:    DELE 2
-    S:    +OK message 2 deleted
-    C:    QUIT
-
-
-
-
-
-Rose                                                           [Page 13]
-
-RFC 1081                          POP3                     November 1988
-
-
-    S:    +OK dewey POP3 server signing off (maildrop empty)
-    C:  <close connection>
-    S:  <wait for next connection>
-
-Message Format
-
-   All messages transmitted during a POP3 session are assumed to conform
-   to the standard for the format of Internet text messages [RFC822].
-
-   It is important to note that the byte count for a message on the
-   server host may differ from the octet count assigned to that message
-   due to local conventions for designating end-of-line.  Usually,
-   during the AUTHORIZATION state of the POP3 session, the POP3 client
-   can calculate the size of each message in octets when it parses the
-   maildrop into messages.  For example, if the POP3 server host
-   internally represents end-of-line as a single character, then the
-   POP3 server simply counts each occurrence of this character in a
-   message as two octets.  Note that lines in the message which start
-   with the termination octet need not be counted twice, since the POP3
-   client will remove all byte-stuffed termination characters when it
-   receives a multi-line response.
-
-The POP and the Split-UA model
-
-   The underlying paradigm in which the POP3 functions is that of a
-   split-UA model.  The POP3 client host, being a remote PC based
-   workstation, acts solely as a client to the message transport system.
-   It does not provide delivery/authentication services to others.
-   Hence, it is acting as a UA, on behalf of the person using the
-   workstation.  Furthermore, the workstation uses SMTP to enter mail
-   into the MTS.
-
-   In this sense, we have two UA functions which interface to the
-   message transport system: Posting (SMTP) and Retrieval (POP3).  The
-   entity which supports this type of environment is called a split-UA
-   (since the user agent is split between two hosts which must
-   interoperate to provide these functions).
-
-                 ASIDE:  Others might term this a remote-UA instead.
-                 There are arguments supporting the use of both terms.
-
-   This memo has explicitly referenced TCP as the underlying transport
-   agent for the POP3.  This need not be the case.  In the MZnet split-
-   UA, for example, personal micro-computer systems are used which do
-   not have IP-style networking capability.  To connect to the POP3
-   server host, a PC establishes a terminal connection using some simple
-   protocol (PhoneNet).  A program on the PC drives the connection,
-   first establishing a login session as a normal user.  The login shell
-
-
-
-Rose                                                           [Page 14]
-
-RFC 1081                          POP3                     November 1988
-
-
-   for this pseudo-user is a program which drives the other half of the
-   terminal protocol and communicates with one of two servers.  Although
-   MZnet can support several PCs, a single pseudo-user login is present
-   on the server host.  The user-id and password for this pseudo-user
-   login is known to all members of MZnet.  Hence, the first action of
-   the login shell, after starting the terminal protocol, is to demand a
-   USER/PASS authorization pair from the PC.  This second level of
-   authorization is used to ascertain who is interacting with the MTS.
-   Although the server host is deemed to support a "trusted" MTS entity,
-   PCs in MZnet are not.  Naturally, the USER/PASS authorization pair
-   for a PC is known only to the owner of the PC (in theory, at least).
-
-   After successfully verifying the identity of the client, a modified
-   SMTP server is started, and the PC posts mail with the server host.
-   After the QUIT command is given to the SMTP server and it terminates,
-   a modified POP3 server is started, and the PC retrieves mail from the
-   server host.  After the QUIT command is given to the POP3 server and
-   it terminates, the login shell for the pseudo-user terminates the
-   terminal protocol and logs the job out.  The PC then closes the
-   terminal connection to the server host.
-
-   The SMTP server used by MZnet is modified in the sense that it knows
-   that it's talking to a user agent and not a "trusted" entity in the
-   message transport system.  Hence, it does performs the validation
-   activities normally performed by an entity in the MTS when it accepts
-   a message from a UA.
-
-   The POP3 server used by MZnet is modified in the sense that it does
-   not require a USER/PASS combination before entering the TRANSACTION
-   state.  The reason for this (of course) is that the PC has already
-   identified itself during the second-level authorization step
-   described above.
-
-                 NOTE: Truth in advertising laws require that the author
-                 of this memo state that MZnet has not actually been
-                 fully implemented.  The concepts presented and proven
-                 by the project led to the notion of the MZnet
-                 split-slot model.  This notion has inspired the
-                 split-UA concept described in this memo, led to the
-                 author's interest in the POP, and heavily influenced
-                 the the description of the POP3 herein.
-
-   In fact, some UAs present in the Internet already support the notion
-   of posting directly to an SMTP server and retrieving mail directly
-   from a POP server, even if the POP server and client resided on the
-   same host!
-
-                 ASIDE: this discussion raises an issue which this memo
-
-
-
-Rose                                                           [Page 15]
-
-RFC 1081                          POP3                     November 1988
-
-
-                 purposedly avoids: how does SMTP know that it's talking
-                 to a "trusted" MTS entity?
-
-References
-
-     [MZnet]   Stefferud, E., J. Sweet, and T. Domae, "MZnet: Mail
-               Service for Personal Micro-Computer Systems",
-               Proceedings, IFIP 6.5 International Conference on
-               Computer Message Systems, Nottingham, U.K., May 1984.
-
-     [RFC821]  Postel, J., "Simple Mail Transfer Protocol",
-               USC/Information Sciences Institute, August 1982.
-
-     [RFC822]  Crocker, D., "Standard for the Format of ARPA-Internet
-               Text Messages", University of Delaware, August 1982.
-
-     [RFC937]  Butler, M., J. Postel, D. Chase, J. Goldberger, and J.
-               Reynolds, "Post Office Protocol - Version 2", RFC 937,
-               USC/Information Sciences Institute, February 1985.
-
-     [RFC1010] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
-               1010, USC/Information Sciences Institute, May 1987.
-
-Author's Address:
-
-
-   Marshall Rose
-   The Wollongong Group
-   1129 San Antonio Rd.
-   Palo Alto, California 94303
-
-   Phone: (415) 962-7100
-
-   Email: MRose@TWG.COM
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose                                                           [Page 16]
diff --git a/appl/popper/pop3e.rfc1082 b/appl/popper/pop3e.rfc1082
deleted file mode 100644
index ac49448b5..000000000
--- a/appl/popper/pop3e.rfc1082
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            M. Rose
-Request for Comments: 1082                                           TWG
-                                                           November 1988
-
-
-
-                    Post Office Protocol - Version 3
-                       Extended Service Offerings
-
-Status of This Memo
-
-   This memo suggests a simple method for workstations to dynamically
-   access mail from a discussion group server, as an extension to an
-   earlier memo which dealt with dynamically accessing mail from a
-   mailbox server using the Post Office Protocol -  Version 3 (POP3).
-   This RFC specifies a proposed protocol for the Internet community,
-   and requests discussion and suggestions for improvements.  All of the
-   extensions described in this memo to the POP3 are OPTIONAL.
-   Distribution of this memo is unlimited.
-
-Introduction and Motivation
-
-   It is assumed that the reader is familiar with RFC 1081 that
-   discusses the Post Office Protocol - Version 3 (POP3) [RFC1081].
-   This memo describes extensions to the POP3 which enhance the service
-   it offers to clients.  This additional service permits a client host
-   to access discussion group mail, which is often kept in a separate
-   spool area, using the general POP3 facilities.
-
-   The next section describes the evolution of discussion groups and the
-   technologies currently used to implement them.  To summarize:
-
-       o An exploder is used to map from a single address to
-       a list of addresses which subscribe to the list, and redirects
-       any subsequent error reports associated with the delivery of
-       each message.  This has two primary advantages:
-             - Subscribers need know only a single address
-             - Responsible parties get the error reports and not
-               the subscribers
-
-
-
-
-
-
-
-
-
-
-
-
-Rose                                                            [Page 1]
-
-RFC 1082                 POP3 Extended Service             November 1988
-
-
-       o Typically, each subscription address is not a person's private
-       maildrop, but a system-wide maildrop, which can be accessed
-       by more than one user.  This has several advantages:
-             - Only a single copy of each message need traverse the
-               net for a given site (which may contain several local
-               hosts).  This conserves bandwidth and cycles.
-             - Only a single copy of each message need reside on each
-               subscribing host.  This conserves disk space.
-             - The private maildrop for each user is not cluttered
-               with discussion group mail.
-
-   Despite this optimization of resources, further economy can be
-   achieved at sites with more than one host.  Typically, sites with
-   more than one host either:
-
-        1.  Replicate discussion group mail on each host.  This
-        results in literally gigabytes of disk space committed to
-        unnecessarily store redundant information.
-
-        2.  Keep discussion group mail on one host and give all users a
-        login on that host (in addition to any other logins they may
-        have).  This is usually a gross inconvenience for users who
-        work on other hosts, or a burden to users who are forced to
-        work on that host.
-
-   As discussed in [RFC1081], the problem of giving workstations dynamic
-   access to mail from a mailbox server has been explored in great
-   detail (originally there was [RFC918], this prompted the author to
-   write [RFC1081], independently of this [RFC918] was upgraded to
-   [RFC937]).  A natural solution to the problem outlined above is to
-   keep discussion group mail on a mailbox server at each site and
-   permit different hosts at that site to employ the POP3 to access
-   discussion group mail.  If implemented properly, this avoids the
-   problems of both strategies outlined above.
-
-        ASIDE:     It might be noted that a good distributed filesystem
-                   could also solve this problem.  Sadly, "good"
-                   distributed filesystems, which do not suffer
-                   unacceptable response time for interactive use, are
-                   few and far between these days!
-
-   Given this motivation, now let's consider discussion groups, both in
-   general and from the point of view of a user agent.  Following this,
-   extensions to the POP3 defined in [RFC1081] are presented.  Finally,
-   some additional policy details are discussed along with some initial
-   experiences.
-
-
-
-
-
-Rose                                                            [Page 2]
-
-RFC 1082                 POP3 Extended Service             November 1988
-
-
-What's in a Discussion Group
-
-   Since mailers and user agents first crawled out of the primordial
-   ARPAnet, the value of discussion groups have been appreciated,
-   (though their implementation has not always been well-understood).
-
-   Described simply, a discussion group is composed of a number of
-   subscribers with a common interest.  These subscribers post mail to a
-   single address, known as a distribution address.  From this
-   distribution address, a copy of the message is sent to each
-   subscriber.  Each group has a moderator, which is the person that
-   administrates the group.  The moderator can usually be reached at a
-   special address, known as a request address.  Usually, the
-   responsibilities of the moderator are quite simple, since the mail
-   system handles the distribution to subscribers automatically.  In
-   some cases, the interest group, instead of being distributed directly
-   to its subscribers, is put into a digest format by the moderator and
-   then sent to the subscribers.  Although this requires more work on
-   the part of the moderator, such groups tend to be better organized.
-
-   Unfortunately, there are a few problems with the scheme outlined
-   above.  First, if two users on the same host subscribe to the same
-   interest group, two copies of the message get delivered.  This is
-   wasteful of both processor and disk resources.
-
-   Second, some of these groups carry a lot of traffic.  Although
-   subscription to an group does indicate interest on the part of a
-   subscriber, it is usually not interesting to get 50 messages or so
-   delivered to the user's private maildrop each day, interspersed with
-   personal mail, that is likely to be of a much more important and
-   timely nature.
-
-   Third, if a subscriber on the distribution list for a group becomes
-   "bad" somehow, the originator of the message and not the moderator of
-   the group is notified.  It is not uncommon for a large list to have
-   10 or so bogus addresses present.  This results in the originator
-   being flooded with "error messages" from mailers across the Internet
-   stating that a given address on the list was bad.  Needless to say,
-   the originator usually could not care less if the bogus addresses got
-   a copy of the message or not.  The originator is merely interested in
-   posting a message to the group at large.  Furthermore, the moderator
-   of the group does care if there are bogus addresses on the list, but
-   ironically does not receive notification.
-
-   There are various approaches which can be used to solve some or all
-   of these problems.  Usually these involve placing an exploder agent
-   at the distribution source of the discussion group, which expands the
-   name of the group into the list of subscription addresses for the
-
-
-
-Rose                                                            [Page 3]
-
-RFC 1082                 POP3 Extended Service             November 1988
-
-
-   group.  In the process, the exploder will also change the address
-   that receives error notifications to be the request address or other
-   responsible party.
-
-   A complementary approach, used in order to cut down on resource
-   utilization of all kinds, replaces all the subscribers at a single
-   host (or group of hosts under a single administration) with a single
-   address at that host.  This address maps to a file on the host,
-   usually in a spool area, which all users can access.  (Advanced
-   implementations can also implement private discussion groups this
-   way, in which a single copy of each message is kept, but is
-   accessible to only a select number of users on the host.)
-
-   The two approaches can be combined to avoid all of the problems
-   described above.
-
-   Finally, a third approach can be taken, which can be used to aid user
-   agents processing mail for the discussion group:  In order to speed
-   querying of the maildrop which contains the local host's copy of the
-   discussion group, two other items are usually associated with the
-   discussion group, on a local basis.  These are the maxima and the
-   last-date.  Each time a message is received for the group on the
-   local host, the maxima is increased by at least one.  Furthermore,
-   when a new maxima is generated, the current date is determined.  This
-   is called the last date.  As the message is entered into the local
-   maildrop, it is given the current maxima and last-date.  This permits
-   the user agent to quickly determine if new messages are present in
-   the maildrop.
-
-       NOTE:      The maxima may be characterized as a monotonically
-                  increasing quanity.  Although sucessive values of the
-                  maxima need not be consecutive, any maxima assigned
-                  is always greater than any previously assigned value.
-
-Definition of Terms
-
-   To formalize these notions somewhat, consider the following 7
-   parameters which describe a given discussion group from the
-   perspective of the user agent (the syntax given is from [RFC822]):
-
-
-
-
-
-
-
-
-
-
-
-
-Rose                                                            [Page 4]
-
-RFC 1082                 POP3 Extended Service             November 1988
-
-
-         NAME            Meaning: the name of the discussion group
-                         Syntax:  TOKEN (ALPHA *[ ALPHA / DIGIT / "-" ])
-                                  (case-insensitive recognition)
-                         Example: unix-wizards
-
-         ALIASES         Meaning: alternates names for the group, which
-                                  are locally meaningful; these are
-                                  typically used to shorten user typein
-                         Syntax:  TOKEN (case-insensitive recognition)
-                         Example: uwiz
-
-         ADDRESS         Meaning: the primary source of the group
-                         Syntax:  822 address
-                         Example: Unix-Wizards@BRL.MIL
-
-         REQUEST         Meaning: the primary moderator of the group
-                         Syntax:  822 address
-                         Example: Unix-Wizards-Request@BRL.MIL
-
-         FLAGS           Meaning: locally meaningful flags associated
-                                  with the discussion group; this memo
-                                  leaves interpretation of this
-                                  parameter to each POP3 implementation
-                         Syntax:  octal number
-                         Example: 01
-
-         MAXIMA          Meaning: the magic cookie associated with the
-                                  last message locally received for the
-                                  group; it is the property of the magic
-                                  cookie that it's value NEVER
-                                  decreases, and increases by at least
-                                  one each time a message is locally
-                                  received
-                         Syntax:  decimal number
-                         Example: 1004
-
-         LASTDATE        Meaning: the date that the last message was
-                                  locally received
-                         Syntax:  822 date
-                         Example: Thu, 19 Dec 85 10:26:48 -0800
-
-   Note that the last two values are locally determined for the maildrop
-   associated with the discussion group and with each message in that
-   maildrop.  Note however that the last message in the maildrop have a
-   different MAXIMA and LASTDATE than the discussion group.  This often
-   occurs when the maildrop has been archived.
-
-
-
-
-
-Rose                                                            [Page 5]
-
-RFC 1082                 POP3 Extended Service             November 1988
-
-
-   Finally, some local systems provide mechanisms for automatically
-   archiving discussion group mail.  In some cases, a two-level archive
-   scheme is used:  current mail is kept in the standard maildrop,
-   recent mail is kept in an archive maildrop, and older mail is kept
-   off-line.  With this scheme, in addition to having a "standard"
-   maildrop for each discussion group, an "archive" maildrop may also be
-   available.  This permits a user agent to examine the most recent
-   archive using the same mechanisms as those used on the current mail.
-
-The XTND Command
-
-   The following commands are valid only in the TRANSACTION state of the
-   POP3.  This implies that the POP3 server has already opened the
-   user's maildrop (which may be empty).  This maildrop is called the
-   "default maildrop".  The phrase "closes the current maildrop" has two
-   meanings, depending on whether the current maildrop is the default
-   maildrop or is a maildrop associated with a discussion group.
-
-   In the former context, when the current maildrop is closed any
-   messages marked as deleted are removed from the maildrop currently in
-   use.  The exclusive-access lock on the maildrop is then released
-   along with any implementation-specific resources (e.g., file-
-   descriptors).
-
-   In the latter context, a maildrop associated with a discussion group
-   is considered to be read-only to the POP3 client.  In this case, the
-   phrase "closes the current maildrop" merely means that any
-   implementation-specific resources are released.  (Hence, the POP3
-   command DELE is a no-op.)
-
-   All the new facilities are introduced via a single POP3 command,
-   XTND.  All positive reponses to the XTND command are multi-line.
-
-   The most common multi-line response to the commands contains a
-   "discussion group listing" which presents the name of the discussion
-   group along with it's maxima.  In order to simplify parsing all POP3
-   servers are required to use a certain format for discussion group
-   listings:
-
-                              NAME SP MAXIMA
-
-   This memo makes no requirement on what follows the maxima in the
-   listing.  Minimal implementations should just end that line of the
-   response with a CRLF pair.  More advanced implementations may include
-   other information, as parsed from the message.
-
-       NOTE:      This memo STRONGLY discourages implementations from
-                  supplying additional information in the listing.
-
-
-
-Rose                                                            [Page 6]
-
-RFC 1082                 POP3 Extended Service             November 1988
-
-
-   XTND BBOARDS [name]
-   Arguments: the name of a discussion group (optionally)
-   Restrictions: may only be given in the TRANSACTION state.
-   Discussion:
-
-   If an argument was given, the POP3 server closes the current
-   maildrop.  The POP3 server then validates the argument as the name of
-   a discussion group.  If this is successful, it opens the maildrop
-   associated with the group, and returns a multi-line response
-   containing the discussion group listing.  If the discussion group
-   named is not valid, or the associated archive maildrop is not
-   readable by the user, then an error response is returned.
-
-   If no argument was given, the POP3 server issues a multi-line
-   response.  After the initial +OK, for each discussion group known,
-   the POP3 server responds with a line containing the listing for that
-   discussion group.  Note that only world-readable discussion groups
-   are included in the multi-line response.
-
-   In order to aid user agents, this memo requires an extension to the
-   scan listing when an "XTND BBOARDS" command has been given.
-   Normally, a scan listing, as generated by the LIST, takes the form:
-
-          MSGNO SIZE
-
-   where MSGNO is the number of the message being listed and SIZE is the
-   size of the message in octets.  When reading a maildrop accessed via
-   "XTND BBOARDS", the scan listing takes the form
-
-          MSGNO SIZE MAXIMA
-
-   where MAXIMA is the maxima that was assigned to the message when it
-   was placed in the BBoard.
-
-   Possible Responses:
-       +OK XTND
-       -ERR no such bboard
-   Examples:
-       C:    XTND BBOARDS
-       S:    +OK XTND
-       S:    system 10
-       S:    mh-users 100
-       S:    .
-       C:    XTND BBOARDS system
-       S:    + OK XTND
-       S:    system 10
-       S:    .
-
-
-
-
-Rose                                                            [Page 7]
-
-RFC 1082                 POP3 Extended Service             November 1988
-
-
-   XTND ARCHIVE name
-   Arguments: the name of a discussion group (required)
-   Restrictions: may only be given in the TRANSACTION state.
-   Discussion:
-
-   The POP3 server closes the current maildrop.  The POP3 server then
-   validates the argument as the name of a discussion group.  If this is
-   successful, it opens the archive maildrop associated with the group,
-   and returns a multi-line response containing the discussion group
-   listing.  If the discussion group named is not valid, or the
-   associated archive maildrop is not readable by the user, then an
-   error response is returned.
-
-   In addition, the scan listing generated by the LIST command is
-   augmented (as described above).
-
-   Possible Responses:
-       +OK XTND
-       -ERR no such bboard Examples:
-       C:    XTND ARCHIVE system
-       S:    + OK XTND
-       S:    system 3
-       S:    .
-
-   XTND X-BBOARDS name
-   Arguments: the name of a discussion group (required)
-   Restrictions: may only be given in the TRANSACTION state.
-   Discussion:
-
-   The POP3 server validates the argument as the name of a
-   discussion group.  If this is unsuccessful, then an error
-   response is returned.  Otherwise a multi-line response is
-   returned.  The first 14 lines of this response (after the
-   initial +OK) are defined in this memo.  Minimal implementations
-   need not include other information (and may omit certain
-   information, outputing a bare CRLF pair).  More advanced
-   implementations may include other information.
-
-           Line    Information (refer to "Definition of Terms")
-           ----    -----------
-             1     NAME
-             2     ALIASES, separated by SP
-             3     system-specific: maildrop
-             4     system-specific: archive maildrop
-             5     system-specific: information
-             6     system-specific: maildrop map
-             7     system-specific: encrypted password
-             8     system-specific: local leaders, separated by SP
-
-
-
-Rose                                                            [Page 8]
-
-RFC 1082                 POP3 Extended Service             November 1988
-
-
-             9     ADDRESS
-            10     REQUEST
-            11     system-specific: incoming feed
-            12     system-specific: outgoing feeds
-            13     FLAGS SP MAXIMA
-            14     LASTDATE
-
-   Most of this information is entirely too specific to the UCI Version
-   of the Rand MH Message Handling System [MRose85].  Nevertheless,
-   lines 1, 2, 9, 10, 13, and 14 are of general interest, regardless of
-   the implementation.
-
-           Possible Responses:
-               +OK XTND
-               -ERR no such bboard
-           Examples:
-               C:    XTND X-BBOARDS system
-               S:    + OK XTND
-               S:    system
-               S:    local general
-               S:    /usr/bboards/system.mbox
-               S:    /usr/bboards/archive/system.mbox
-               S:    /usr/bboards/.system.cnt
-               S:    /usr/bboards/.system.map
-               S:    *
-               S:    mother
-               S:    system@nrtc.northrop.com
-               S:    system-request@nrtc.northrop.com
-               S:
-               S:    dist-system@nrtc-gremlin.northrop.com
-               S:    01 10
-               S:    Thu, 19 Dec 85 00:08:49 -0800
-               S:    .
-
-Policy Notes
-
-   Depending on the particular entity administrating the POP3 service
-   host, two additional policies might be implemented:
-
-   1.  Private Discussion Groups
-
-   In the general case, discussion groups are world-readable, any user,
-   once logged in (via a terminal, terminal server, or POP3, etc.), is
-   able to read the maildrop for each discussion group known to the POP3
-   service host.  Nevertheless, it is desirable, usually for privacy
-   reasons, to implement private discussion groups as well.
-
-   Support of this is consistent with the extensions outlined in this
-
-
-
-Rose                                                            [Page 9]
-
-RFC 1082                 POP3 Extended Service             November 1988
-
-
-   memo.  Once the AUTHORIZATION state has successfully concluded, the
-   POP3 server grants the user access to exactly those discussion groups
-   the POP3 service host permits the authenticated user to access.  As a
-   "security" feature, discussion groups associated with unreadable
-   maildrops should not be listed in a positive response to the XTND
-   BBOARDS command.
-
-   2.  Anonymous POP3 Users
-
-   In order to minimize the authentication problem, a policy permitting
-   "anonymous" access to the world-readable maildrops for discussion
-   groups on the POP3 server may be implemented.
-
-   Support of this is consistent with the extensions outlined in this
-   memo.  The POP3 server can be modified to accept a USER command for a
-   well-known pseudonym (i.e., "anonymous") which is valid with any PASS
-   command.  As a "security" feature, it is advisable to limit this kind
-   of access to only hosts at the local site, or to hosts named in an
-   access list.
-
-Experiences and Conclusions
-
-   All of the facilities described in this memo and in [RFC1081] have
-   been implemented in MH #6.1.  Initial experiences have been, on the
-   whole, very positive.
-
-   After the first implementation, some performance tuning was required.
-   This consisted primarily of caching the datastructures which describe
-   discussion groups in the POP3 server.  A second optimization
-   pertained to the client:  the program most commonly used to read
-   BBoards in MH was modified to retrieve messages only when needed.
-   Two schemes are used:
-
-         o If only the headers (and the first few lines of the body) of
-           the message are required (e.g., for a scan listing), then only
-           these are retrieved.  The resulting output is then cached, on
-           a per-message basis.
-
-         o If the entire message is required, then it is retrieved intact,
-            and cached locally.
-
-   With these optimizations, response time is quite adequate when the
-   POP3 server and client are connected via a high-speed local area
-   network.  In fact, the author uses this mechanism to access certain
-   private discussion groups over the Internet.  In this case, response
-   is still good.  When a 9.6Kbps modem is inserted in the path,
-   response went from good to almost tolerable (fortunately the author
-   only reads a few discussion groups in this fashion).
-
-
-
-Rose                                                           [Page 10]
-
-RFC 1082                 POP3 Extended Service             November 1988
-
-
-   To conclude: the POP3 is a good thing, not only for personal mail but
-   for discussion group mail as well.
-
-
-References
-
-     [RFC1081] Rose, M., "Post Office Protocol - Verison 3 (POP3)", RFC
-               1081, TWG, November 1988.
-
-     [MRose85] Rose, M., and J. Romine, "The Rand MH Message Handling
-               System: User's Manual", University of California, Irvine,
-               November 1985.
-
-     [RFC822]  Crocker, D., "Standard for the Format of ARPA-Internet
-               Text Messages", RFC 822, University of Delaware, August
-               1982.
-
-     [RFC918]  Reynolds, J., "Post Office Protocol", RFC 918,
-               USC/Information Sciences Institute, October 1984.
-
-     [RFC937]  Butler, M., J. Postel, D. Chase, J. Goldberger, and J.
-               Reynolds, "Post Office Protocol - Version 2", RFC 937,
-               USC/Information Sciences Institute, February 1985.
-
-Author's Address:
-
-
-   Marshall Rose
-   The Wollongong Group
-   1129 San Antonio Rd.
-   Palo Alto, California 94303
-
-   Phone: (415) 962-7100
-
-   Email: MRose@TWG.COM
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose                                                           [Page 11]
-
diff --git a/debian/README.Debian b/debian/README.Debian
new file mode 100644
index 000000000..afd4703ee
--- /dev/null
+++ b/debian/README.Debian
@@ -0,0 +1,130 @@
+Note on ksu
+-----------
+This program is not installed setuid root be default. If you want to
+install it setuid root, then you can override the package permissions
+with:
+
+dpkg-statoverride --update --add root root 4755 /usr/bin/ksu
+
+Note on ipropd and/or hpropd
+----------------------------
+The following entries may be required in you /etc/services
+file (see bug #139845):
+
+krb_prop      754/tcp                         # Kerberos slave propagation
+iprop         2121/tcp                        # incremental propagation
+
+Note on kerberos.8 man page
+---------------------------
+This man page is not currently included due to conflict with kerberos4kth-kdc
+package. For more information on Kerberos, see:
+http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html
+
+Installing heimdal for Debian
+-----------------------------
+(Note: if you do not have a krb4 KDC, you may need to include
+"krb4_get_tickets = no" in the [libdefaults] section of
+kdc.conf; otherwise kinit will complain with an error).
+
+Things you will have to do manually (see info documentation for
+details):
+
+On KDC:
+1. Add adminstrator keys using kadmin.
+
+For example:
+# kadmin -l
+kadmin> add bam/admin
+Max ticket life [unlimited]:
+Max renewable life [unlimited]:
+Principal expiration time [never]:
+Password expiration time [never]:
+Attributes []:
+bam/admin@CHOCBIT.ORG.AU's Password:
+Verifying password - bam/admin@CHOCBIT.ORG.AU's Password:
+
+2. Add kadmin/admin key to KDC:
+
+For example:
+# kadmin -l
+kadmin> add -r kadmin/admin@CHOCBIT.ORG.AU
+Max ticket life [unlimited]:
+Max renewable life [unlimited]:
+Principal expiration time [never]:
+Password expiration time [never]:
+Attributes []:
+
+(note: this key doesn't need to be extracted).
+
+3. Enable remote admistration by creating /etc/heimdal-kdc/kadmind.acl
+
+For example:
+echo 'bam/admin@CHOCBIT.ORG.AU all' > /etc/heimdal-kdc/kadmind.acl
+
+4. Test.
+
+For example:
+# kadmin -p bam/admin
+bam/admin@CHOCBIT.ORG.AU's Password:
+kadmin> list *
+[should list all keys]
+
+5. Add user keys
+
+For example:
+# kadmin -p bam/admin
+bam/admin@CHOCBIT.ORG.AU's Password:
+kadmin> add bam
+
+
+On other computers:
+1. If you installed heimdal-clients-x or heimdal-servers-x,
+then you will need to add the following entry to /etc/services
+kx              2111/tcp                        # X over kerberos
+(check to make sure this doesn't already exist).
+2. edit /etc/krb5.conf
+3. setup secret keys each computer, using kadmin and/or ktutil.
+
+For example, on remote computer dewey.chocbit.org.au:
+bam/admin@CHOCBIT.ORG.AU's Password:
+kadmin> add -r host/dewey.chocbit.org.au
+[...]
+kadmin> ext host/dewey.chocbit.org.au
+kadmin> add -r ftp/dewey.chocbit.org.au
+[...]
+kadmin> ext ftp/dewey.chocbit.org.au
+
+The ext command extracts keys to /etc/krb5.keytab, where
+they can be inspected with the "ktutil list" command at the
+shell prompt.
+
+Tell me if any files conflict with any other package - do not
+try to force the package to install, otherwise things may break...
+In general, this package conflicts with kerberos4kth and
+probably MIT Kerberos (not packaged as of potato). Local
+installations under /usr/local should be OK.
+
+Changes from upstream source:
+1. popper checks for $HOME/Maildir, $HOME/Mailbox and /var/spool/mail/<user>
+in that order.
+2. /var/lib/heimdal-kdc used instead of /var/heimdal
+3. /usr/bin/login moved to /usr/lib/heimdal-servers
+4. /usr/lib/heimdal-servers used instead of /usr/libexec
+5. telnet and ftp have been renamed to ktelnet and kftp, and
+use the update-alternatives mechanism. In the future, this
+should allow heimdal-clients to exist at the same time
+as telnet-ssl.
+6. kdc config files kdc.conf and kadmind.acl stored in
+/etc/heimdal-kdc instead of /usr/lib/heimdal-servers.
+
+Automatically creating users
+-----------------------------
+
+Option #1: Use perl glue found at
+<ftp://ftp.su.se/pub/users/leifj/Heimdal-Kadm5-0.04.tar.gz>
+
+Option #2: cat kadmin-commands | kadmin
+
+For more details, see <http://bugs.debian.org/276402>.
+
+ -- Brian May <bam@debian.org>, Wed,  8 Dec 1999 11:54:13 +1100
diff --git a/debian/README.source b/debian/README.source
new file mode 100644
index 000000000..28702e080
--- /dev/null
+++ b/debian/README.source
@@ -0,0 +1,2 @@
+The dfsg version of the tarball was created by the script in 
+debian/scripts/convert_source.
diff --git a/debian/changelog b/debian/changelog
new file mode 100644
index 000000000..99573c1bb
--- /dev/null
+++ b/debian/changelog
@@ -0,0 +1,1539 @@
+heimdal (1.4.0+git20101228.dfsg.1-1) experimental; urgency=low
+
+  * New upstream snapshot.
+   + No longer installs kauth.
+   + Fixes support for linking with --as-needed. Closes: #607589
+  * Build hcrypto library rather than using libssl. Required by Samba 4.
+
+ -- Jelmer Vernooij <jelmer@debian.org>  Mon, 20 Dec 2010 00:17:51 +0100
+
+heimdal (1.4.0-1) unstable; urgency=low
+
+  * New upstream version.
+  * Update standards version to 3.9.1.
+  * Rewrite debian/rules clean list.
+
+ -- Brian May <bam@debian.org>  Tue, 02 Nov 2010 12:03:56 +1100
+
+heimdal (1.4.0~git20100726.dfsg.1-1) unstable; urgency=low
+
+  * New upstream version.
+  * Update standards version to 3.9.0.
+
+ -- Brian May <bam@debian.org>  Mon, 26 Jul 2010 15:19:37 +1000
+
+heimdal (1.4.0~git20100605.dfsg.1-3) unstable; urgency=low
+
+  * Retry remove dangling symlinks to windc.so (closes: #577229).
+  * Also remove windc.la and windc.a, as they would appear to be pointless.
+
+ -- Brian May <bam@debian.org>  Thu, 01 Jul 2010 15:16:02 +1000
+
+heimdal (1.4.0~git20100605.dfsg.1-2) unstable; urgency=low
+
+  * Include updated Danish (da) debconf translations (closes: #585575).
+  * Removing dangling symlinks to windc.so (closes: #577229).
+  * Do not set -e in init.d script (closes: #574425).
+
+ -- Brian May <bam@debian.org>  Thu, 17 Jun 2010 14:57:18 +1000
+
+heimdal (1.4.0~git20100605.dfsg.1-1) unstable; urgency=low
+
+  * New upstream version.
+      * Git version abd5fdab5a7e189ef3f9c6aeafcebf94ddde157d.
+      * Check the GSS-API checksum exists before trying to use
+        it [CVE-2010-1321].
+
+ -- Brian May <bam@debian.org>  Sat, 05 Jun 2010 10:31:49 +1000
+
+heimdal (1.4.0~git20100322.dfsg.2-4) unstable; urgency=low
+
+  * Add a db_stop before automatically-added debhelper parts (Closes: #579127).
+
+ -- Brian May <bam@debian.org>  Wed, 28 Apr 2010 15:18:46 +1000
+
+heimdal (1.4.0~git20100322.dfsg.2-3) unstable; urgency=low
+
+  * Add depends on libwind0-heimdal to heimdal-multidev.
+
+ -- Brian May <bam@debian.org>  Tue, 13 Apr 2010 15:25:48 +1000
+
+heimdal (1.4.0~git20100322.dfsg.2-2) unstable; urgency=low
+
+  * Fix watch file to properly mangle upstream release candidate
+    versions (closes: #575872).
+
+ -- Brian May <bam@debian.org>  Thu, 08 Apr 2010 15:07:30 +1000
+
+heimdal (1.4.0~git20100322.dfsg.2-1) unstable; urgency=low
+
+  * Remove non-free RFCs again. Somehow the change went missing from the script
+  in debian/scripts/convert_source.
+
+ -- Brian May <bam@debian.org>  Mon, 22 Mar 2010 15:42:05 +1100
+
+heimdal (1.4.0~git20100322.dfsg.1-1) unstable; urgency=low
+
+  * New upstream version.
+
+ -- Brian May <bam@debian.org>  Mon, 22 Mar 2010 13:03:56 +1100
+
+heimdal (1.4.0~git20100221.dfsg.2-3) unstable; urgency=low
+
+  * Remove yucky comerr backport, requires libcomerr2 version 1.41.11-1
+    or higher.
+  * Rework debian/patches, make similar to prio 1.4.0 versions.
+  * Add package-name-doesnt-match-sonames overrides for all shared libraries
+    as discussed in #574572.
+  * Update configure so it detects libedit library (closes: #574700).
+
+ -- Brian May <bam@debian.org>  Sun, 21 Mar 2010 11:16:57 +1100
+
+heimdal (1.4.0~git20100221.dfsg.2-2) unstable; urgency=low
+
+  * Fix shlibs versions.
+
+ -- Brian May <bam@debian.org>  Fri, 19 Mar 2010 16:46:43 +1100
+
+heimdal (1.4.0~git20100221.dfsg.2-1) unstable; urgency=low
+
+  * Last upload went to unstable by mistake. Lets not panic, this version
+  should work fine...
+  * Remove nonfree RFCs from source code (closes: #574431).
+  * Add iprop-log and man page (closes: #574424).
+
+ -- Brian May <bam@debian.org>  Fri, 19 Mar 2010 13:33:35 +1100
+
+heimdal (1.4.0~git20100221.dfsg.1-2) experimental; urgency=low
+  * Update debshlibs dependancies. Anything compiled against the
+    version of Heimdal in experimental will require the libraries from
+    experimental. May not strictly be required for all libraries, but
+    better be safe then sorry.
+  * This also will resolves a bug for the experimental version that has
+    already been solved in stable (closes: 571206).
+
+ -- Brian May <bam@debian.org>  Wed, 17 Mar 2010 12:11:51 +1100
+
+heimdal (1.4.0~git20100221.dfsg.1-1) experimental; urgency=low
+
+  * New upstream snapshot.
+   + Exports more symbols. Closes: #563275
+  * Bump standards version to 3.8.4.
+  * Non-maintainer upload, acked by Brian.
+  * Document how the dfsg-compatible version is created. Closes: #570413
+
+ -- Jelmer Vernooij <jelmer@debian.org>  Sat, 20 Feb 2010 17:54:44 +0100
+
+heimdal (1.3.1.rc2.dfsg.1-2) unstable; urgency=low
+
+  * heimdal-kdc: Change depends on logrotate to a recommends; while
+  functionality will be lost if logrotate isn't installed, it won't cause
+  the sky to fall (closes: #565115). Not in my lifetime anyway.
+  * Update watch files (closes: #568340).
+  * Update my email address.
+
+ -- Brian May <bam@debian.org>  Thu, 04 Feb 2010 14:42:55 +1100
+
+heimdal (1.3.1.rc2.dfsg.1-1) unstable; urgency=low
+
+  * New upstream package.
+  * Include heimdal-dbg (closes: #561940).
+  * Apply patch to fix segfaults (closes: #561850).
+
+ -- Brian May <bam@snoopy.debian.net>  Tue, 05 Jan 2010 10:33:29 +1100
+
+heimdal (1.3.1.dfsg.1-6) unstable; urgency=low
+
+  * Remove references to quilt from debian/rules (closes: #561401).
+
+ -- Brian May <bam@snoopy.debian.net>  Fri, 18 Dec 2009 14:13:16 +1100
+
+heimdal (1.3.1.dfsg.1-5) unstable; urgency=low
+
+  * Increase soname for libkrb5, after version symbols changed
+    (closes: #560216).
+
+ -- Brian May <bam@snoopy.debian.net>  Tue, 15 Dec 2009 10:35:39 +1100
+
+heimdal (1.3.1.dfsg.1-4) unstable; urgency=low
+
+  * heimdal-dev: remove dependancy on heimsqlite library.
+  * heimdal-dev: remove symlinks to heimsqlite library.
+  * Build against libedit-dev that comes with Debian (closes: #559910).
+
+ -- Brian May <bam@snoopy.debian.net>  Tue, 08 Dec 2009 10:27:10 +1100
+
+heimdal (1.3.1.dfsg.1-3) unstable; urgency=low
+
+  * Build against sqlite3 library (closes: #559616).
+  * Remove heimsqlite library as it isn't built anymore.
+
+ -- Brian May <bam@snoopy.debian.net>  Mon, 07 Dec 2009 14:44:21 +1100
+
+heimdal (1.3.1.dfsg.1-2) unstable; urgency=low
+
+  * Don't fail if /usr/share/info/dir can't be deleted (closes: #552677).
+    Really make the change this time.
+  * Fix glaring errors on previous two changelog entries. We are still
+    using new source format. Previous version fixed lintian warnings.
+  * Really build against openldap (closes: #559730).
+
+ -- Brian May <bam@snoopy.debian.net>  Mon, 07 Dec 2009 09:19:33 +1100
+
+heimdal (1.3.1.dfsg.1-1) unstable; urgency=low
+
+  * New upstream release (closes: #557716).
+  * Discard patches that don't apply cleanly on assumption they have been
+    integrated upstream already.
+  * Increase soname for libhx509 to 5.
+  * Replace symlinks to dirs with real directories (closes: #550646).
+  * New heimsqlite library.
+  * Fix lintian warnings:
+    * heimdal-kdc: don't fail if /etc/default/heimdal-kdc doesn't exist.
+    * heimdal-kdc: override permissions warning on /var/lib/heimdal-kdc.
+
+ -- Brian May <bam@snoopy.debian.net>  Tue, 01 Dec 2009 09:44:23 +1100
+
+heimdal (1.2.e1.dfsg.1-5) unstable; urgency=low
+
+  * Use new 3.0 (quilt) format.
+
+ -- Brian May <bam@snoopy.debian.net>  Mon, 23 Nov 2009 14:21:59 +1100
+
+heimdal (1.2.e1.dfsg.1-4) unstable; urgency=low
+
+  * heimdal-docs: don't distribute /usr/share/info/dir.gz (closes: #552083).
+  * Fix lintian warnings:
+    * heimdal-docs: add depends on dpkg (>= 1.15.4) | install-info to fix
+      lintian warning.
+    * heimdal-kdc: add ${misc:Depends} to depends.
+    * Update standards version to 3.8.3
+    * Create debian/README.source.
+
+ -- Brian May <bam@snoopy.debian.net>  Mon, 26 Oct 2009 10:46:47 +1100
+
+heimdal (1.2.e1.dfsg.1-3) unstable; urgency=low
+
+  * heimdal-kdc: remove FILE: prefix from default kdc.conf file, it does
+    not work (closes: #550357).
+
+ -- Brian May <bam@snoopy.debian.net>  Wed, 21 Oct 2009 10:14:07 +1100
+
+heimdal (1.2.e1.dfsg.1-2) unstable; urgency=low
+
+  * debian/rules: clean out dependency_libs in the .la files shipped by
+    heimdal-dev, so that reverse-dependencies don't fail to build looking
+    for libdb when they don't need it.  Thanks to Thomas Viehmann for the
+    patch.  Closes: #266003.
+
+ -- Brian May <bam@snoopy.debian.net>  Thu, 03 Sep 2009 12:51:24 +1000
+
+heimdal (1.2.e1.dfsg.1-1.1) unstable; urgency=low
+
+  * Non-maintainer upload with permission of maintainer, Closes: #538697 
+  * Implement heimdal-multidev package to provide set of headers and
+    libraries that can be installed along-side MIT Kerberos Development
+    files  
+
+ -- Sam Hartman <hartmans@debian.org>  Sat, 25 Jul 2009 13:35:51 -0400
+
+heimdal (1.2.e1.dfsg.1-1) unstable; urgency=low
+
+  * New upstream version.
+  * Increase soname of libhx509-3-heimdal to libhx509-4-heimdal.
+
+ -- Brian May <bam@snoopy.debian.net>  Mon, 13 Jul 2009 14:43:12 +1000
+
+heimdal (1.2.dfsg.1-5) unstable; urgency=low
+
+  * Fix problems with postinst script. kdc.conf installed gzipped.
+  * Fix line 112 of sample kdc.conf - line was intended to be commented out.
+    Avoid unmatched } error.
+  * Improve call to kadmin init when initially creating database.
+  * Improve description of heimdal-clients package. Closes: #527021.
+
+ -- Brian May <bam@snoopy.debian.net>  Wed, 13 May 2009 11:27:03 +1000
+
+heimdal (1.2.dfsg.1-4) unstable; urgency=low
+
+  * Update to use unversioned libdb-dev. Closes: #524292.
+
+ -- Brian May <bam@snoopy.debian.net>  Thu, 16 Apr 2009 16:28:51 +1000
+
+heimdal (1.2.dfsg.1-3) unstable; urgency=low
+
+  * Update to use db4.5. Closes: #421938.
+  * Add information on automatically creating users. Closes: #276402.
+  * Update Spanish Translation (es). Closes: #507754.
+  * heimdal-servers: Add provides for pop3-server. Closes: #515087.
+  * Add home page header to control file.
+  * Update default kdc.conf and fix it so that our Debian paths will get used.
+    Closes: #495463.
+  * Hack postinst script so symlinks will be created for older installs.
+  * Fix various lintian warnings. Update debian/compat, standards versions,
+    etc.
+
+ -- Brian May <bam@snoopy.debian.net>  Mon, 06 Apr 2009 09:38:38 +1000
+
+heimdal (1.2.dfsg.1-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * fix segfaults when using pkinit with wrong PIN. Closes: #499405
+
+ -- Guido Günther <agx@sigxcpu.org>  Sun, 05 Oct 2008 15:12:05 +0200
+
+heimdal (1.2.dfsg.1-2) unstable; urgency=low
+
+  * Fix library version symbols. Again. Closes: #492427.
+  * Install swedish (sv) debconf translations from #491767. Closes: #483764, #491767.
+
+ -- Brian May <bam@snoopy.debian.net>  Tue, 29 Jul 2008 13:11:57 +1000
+
+heimdal (1.2.dfsg.1-1) unstable; urgency=low
+
+  * New upstream release.
+  * Removed non-free RFC content.
+  * Install hxtool in heimdal-clients (closes: #487119).
+  * Fix issues converting source to new quilt format (closes: #485108).
+    * remove more autobuilt files in clean rule
+    * more series file to debian/patches
+  * Update standards version to 3.8.0.
+  * Use build depends on x11proto-core-dev instead of x-dev.
+
+ -- Brian May <bam@snoopy.debian.net>  Sat, 21 Jun 2008 01:00:05 +0000
+
+heimdal (1.1-3) unstable; urgency=low
+
+  * Fix versioned symbols on x86_64. Closes: #453241.
+
+ -- Brian May <bam@snoopy.debian.net>  Mon, 12 May 2008 12:47:15 +1000
+
+heimdal (1.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump shlibs of libasn1-8-heimdal because of newly exported
+    symbol oid_id_heim_rsa_pkcs1_x509. Closes: #479437
+
+ -- Andreas Barth <aba@not.so.argh.org>  Sat, 10 May 2008 09:58:40 +0000
+
+heimdal (1.1-2) unstable; urgency=low
+
+  * Create symlink at /var/lib/heimdal-kdc/kdc.conf pointing to
+    /etc/heimdal-kdc/kdc.conf, closes: #470404.
+  * On upgrading existing installations create a symlink from
+    /usr/share/doc/heimdal-kdc/examples/kadmind.acl pointing to
+    /etc/heimdal-kdc/kadmind.acl.conf, as the kdc.conf configuration
+    is not updated automatically.
+  * Replace "echo -n" with printf, closes: #472229.
+  * Install Dutch (nl) debconf translation, closes: #467495.
+  * Install Czech (cs) debconf translation, closes: #452880.
+  * Increase standards version to 3.7.3.
+  * Convert debian/copyright to UTF-8.
+  * Fix various lintian warnings.
+
+ -- Brian May <bam@snoopy.debian.net>  Fri, 28 Mar 2008 09:46:09 +1100
+
+heimdal (1.1-1) unstable; urgency=low
+
+  * New upstream release.
+  o Apply patch from upstream to fix pointer conversion in LDAP,
+    closes: #463410.
+  * Add missing ldap schema file, closes: #455024.
+  * Add LSB formatted dependency info into init.d scripts,
+    closes: #468189.
+
+ -- Brian May <bam@snoopy.debian.net>  Fri, 29 Feb 2008 11:05:18 +1100
+
+heimdal (1.0.1-5) unstable; urgency=low
+
+  * The "I can make these changes. Really!" release.
+  * Move po files from po/* to debian/po/*.
+  * Debconf templates and debian/control reviewed by the debian-l10n-
+    english team as part of the Smith review project. Closes: #443532
+  * Debconf translation updates:
+  * Vietnamese. Closes: #444169
+  * Russian. Closes: #444191
+  * Finnish. Closes: #444255
+  * Japanese. Closes: #444273
+  * Galician. Closes: #444749
+  * French. Closes: #445429
+  * Italian. Closes: #445438
+  * Brazilian Portuguese. Closes: #445733
+  * German. Closes: #446013
+  * Portuguese. Closes: #446542
+
+ -- Brian May <bam@snoopy.debian.net>  Thu,  8 Nov 2007 10:18:10 +1100
+
+heimdal (1.0.1-4) unstable; urgency=low
+
+  * Debconf templates and debian/control reviewed by the debian-l10n-
+    english team as part of the Smith review project. Closes: #443532
+  * Debconf translation updates:
+  * Vietnamese. Closes: #444169
+  * Russian. Closes: #444191
+  * Finnish. Closes: #444255
+  * Japanese. Closes: #444273
+  * Galician. Closes: #444749
+  * French. Closes: #445429
+  * Italian. Closes: #445438
+  * Brazilian Portuguese. Closes: #445733
+  * German. Closes: #446013
+  * Portuguese. Closes: #446542
+
+ -- Brian May <bam@snoopy.debian.net>  Thu,  8 Nov 2007 10:18:10 +1100
+
+heimdal (1.0.1-3) unstable; urgency=low
+
+  * Update debconf templates and debian/control as per review (closes:
+    #443532).
+  * Update vi translation (closes: #444169).
+  * Update ru translation (closes: #444191).
+  * Update fi translation (closes: #444255).
+  * Update ja translation (closes: #444273).
+  * Update gl translation (closes: #444749).
+  * Upload to unstable.
+
+ -- Brian May <bam@snoopy.debian.net>  Fri,  5 Oct 2007 13:18:06 +1000
+
+heimdal (1.0.1-2) experimental; urgency=low
+
+  * hcrypto4 is not built when using openssl libraries. Don't know why it got
+    built on initial tests. Delete the package. Closes: #440443.
+
+ -- Brian May <bam@snoopy.debian.net>  Wed,  5 Sep 2007 12:13:04 +1000
+
+heimdal (1.0.1-1) experimental; urgency=low
+
+  * New upstream release.
+  * libgssapi2-heimdal conflicts with libgssapi2; this means Heimdal libraries
+    cannot be installed at same time as nfs, because nfs is compiled against
+    libgssapi2.
+
+ -- Brian May <bam@snoopy.debian.net>  Fri, 10 Aug 2007 11:26:03 +1000
+
+heimdal (0.8.1-1) experimental; urgency=low
+
+  * New upstream version. Closes: #410231.
+
+ -- Brian May <bam@snoopy.debian.net>  Mon,  4 Jun 2007 13:06:24 +1000
+
+heimdal (0.7.2.dfsg.1-10) unstable; urgency=low
+
+  * Add Portuguese debconf translation (closes: #408186).
+  * Properly quote values in heimdal-kdc's postinst (closes: #408908).
+  * Fixes broken conflicts in libsl0-heimdal (closes: #406651).
+
+ -- Brian May <bam@snoopy.debian.net>  Thu,  8 Feb 2007 15:27:28 +1100
+
+heimdal (0.7.2.dfsg.1-9) unstable; urgency=low
+
+  * Include Spanish po-debconf translation (closes: #403481).
+
+ -- Brian May <bam@snoopy.debian.net>  Thu, 11 Jan 2007 09:09:26 +1100
+
+heimdal (0.7.2.dfsg.1-8) unstable; urgency=high
+
+  * Swap -n with -z in test, otherwise servers won't get added on initial
+    installation. This was due to broken fix for #401258.
+
+ -- Brian May <bam@snoopy.debian.net>  Wed, 13 Dec 2006 14:45:52 +1100
+
+heimdal (0.7.2.dfsg.1-7) unstable; urgency=high
+
+  * Don't change services on upgrades, only on fresh installation, purge, and
+    upgrade from old versions.  Closes: #401258.
+
+ -- Brian May <bam@snoopy.debian.net>  Tue, 12 Dec 2006 14:45:22 +1100
+
+heimdal (0.7.2.dfsg.1-6) unstable; urgency=low
+
+  * Update maintainer E-Mail address.
+
+ -- Brian May <bam@snoopy.debian.net>  Mon, 20 Nov 2006 12:02:02 +1100
+
+heimdal (0.7.2.dfsg.1-5) unstable; urgency=low
+
+  * Rebuild against latest openldap (closes: #385809).
+  * Add SLAVE_PARAMS to KDC /etc/default/heimdal-kdc file (closes: #392933).
+  * Fix klist man page (closes: #389848).
+
+ -- Brian May <bam@debian.org>  Mon, 16 Oct 2006 15:15:32 +1000
+
+heimdal (0.7.2.dfsg.1-4) unstable; urgency=low
+
+  * Include KCM (closes: #379245).
+  * Move heimdal-docs to Section: doc.
+
+ -- Brian May <bam@debian.org>  Tue, 22 Aug 2006 12:19:57 +1000
+
+heimdal (0.7.2.dfsg.1-3) unstable; urgency=low
+
+  * Remove bashism in debian/rules. Closes: #376082.
+  * Build depends on texinfo, required for makeinfo. Closes: #376224.
+
+ -- Brian May <bam@debian.org>  Sun,  2 Jul 2006 10:49:35 +1000
+
+heimdal (0.7.2.dfsg.1-2) unstable; urgency=low
+
+  * Search for all references to HDB_DB_DIR "/kdc.conf" and replace with
+    "/etc/heimdal-kdc/kdc.conf". Closes: #365883, #365890.
+
+ -- Brian May <bam@debian.org>  Sun, 14 May 2006 10:42:24 +1000
+
+heimdal (0.7.2.dfsg.1-1) unstable; urgency=low
+
+  * Remove non-free documentation. Closes: #364860.
+  * Add Galician debconf templates. Closes: #362091.
+  * Update standards version to 3.7.2.
+
+ -- Brian May <bam@debian.org>  Sat, 13 May 2006 16:02:41 +1000
+
+heimdal (0.7.2-4) unstable; urgency=low
+
+  * Fix file deletion in postrm. Closes: #361411.
+
+ -- Brian May <bam@debian.org>  Mon, 10 Apr 2006 12:45:34 +1000
+
+heimdal (0.7.2-3) unstable; urgency=low
+
+  * Move heimdal-kdc config files, kdc.conf, kadmind.acl and .configured, from
+    /var/lib/heimdal-kdc to /etc/heimdal-kdc. Closes: #351960.
+
+ -- Brian May <bam@debian.org>  Fri,  7 Apr 2006 10:13:55 +1000
+
+heimdal (0.7.2-2) unstable; urgency=low
+
+  * Install krcp.1 manpage.
+  * Move xnlock.1 man page to correct man page section 1.
+  * heimdal-dev: add depends on comerr-dev. Closes: #357115.
+
+ -- Brian May <bam@debian.org>  Thu, 16 Mar 2006 19:15:32 +1100
+
+heimdal (0.7.2-1) unstable; urgency=low
+
+  * New upstream version. Includes security fixes. Changes from upstream:
+
+        * Fix security problem in rshd that enable an attacker to overwrite
+          and change ownership of any file that root could write
+          (CVE-2006-0582).
+
+        * Fix a DOS in telnetd. The attacker could force the server to crash
+          in a NULL de-reference before the user logged in, resulting in inetd
+          turning telnetd off because it forked too fast (CVE-2006-0677).
+
+        * Make gss_acquire_cred(GSS_C_ACCEPT) check that the requested name
+          exists in the keytab before returning success. This allows servers
+          to check if its even possible to use GSSAPI.
+
+        * Fix receiving end of token delegation for GSS-API. It still wrongly
+          uses subkey for sending for compatibility reasons, this will change
+          in 0.8.
+
+        * telnetd, login and rshd are now more verbose in logging failed and
+          successful logins.
+
+        * Bug fixes.
+
+  * Ditch dbs build system in preference for quilt and cdbs.
+
+  * Don't install /usr/include/ss. It's not included by any other header
+    in heimdal-dev and is provided by ss-dev. Closes: #349213.
+
+  * Also remove /usr/bin/mk_cmds which is also provided by ss-dev.
+
+  * Supply /etc/ldap/schema/hdb.schema. Closes: #355287.
+
+  * Move iprop man pages from heimdal-clients package into
+    heimdal-kdc package. Closes: #347555.
+
+  * Change default program for krsh from rlogin to ktelnet if no parameters
+    given.  Closes: #355080.
+
+ -- Brian May <bam@debian.org>  Thu,  9 Mar 2006 18:24:51 +1100
+
+heimdal (0.7.1-3) unstable; urgency=high
+
+  * Brian May <bam@debian.org>:
+    * Delete patches for old Heimdal versions.
+    * Update Swedish debconf translation (closes: #347605).
+  * Michael Banck <mbanck@debian.org>:
+    * Changes for GNU HURD: 026_posix_max (closes: #113317),
+                            026_no_afs (closes: #324342).
+  * Steve Langasek <vorlon@debian.org>:
+    * 025_pthreads
+    * High-urgency upload for RC bugfix.
+    * Use -pthread -lpthread when linking shared libs, not just -pthread,
+      needed for proper linking of libgssapi on mips/mipsel.  Closes: #346346.
+    * Build-depend on libx11-dev, libxau-dev, libxt-dev, x-dev instead of the
+      obsolete xlibs-dev.  Closes: #346680.
+
+ -- Brian May <bam@debian.org>  Fri, 13 Jan 2006 19:04:05 +1100
+
+heimdal (0.7.1-2) unstable; urgency=low
+
+  * Apply 022_ftp-roken-glob again.
+  * Upload for unstable.
+
+ -- Brian May <bam@debian.org>  Thu, 22 Dec 2005 11:24:21 +1100
+
+heimdal (0.7.1-1) experimental; urgency=low
+
+  * New upstream version.
+  * Remove krb4 support (closes: #315059, #334632).
+  * Conflict with krb4.
+
+ -- Brian May <bam@debian.org>  Mon, 24 Oct 2005 08:08:39 +1000
+
+heimdal (0.6.3-13) unstable; urgency=low
+
+  * Add alternative depends of debconf-2.0 in heimdal-kdc. Closes
+    <URL:http://lists.debian.org/debian-devel/2005/08/msg00136.html>.
+  * Update sv translations (closes: #330318).
+
+ -- Brian May <bam@debian.org>  Sun,  2 Oct 2005 12:36:49 +1000
+
+heimdal (0.6.3-12) unstable; urgency=low
+
+  * Rebuild to fix broken *.la files (closes: #316980).
+  * Modify rxtelnet and rxterm to use ktelnet and krsh (closes: #274063).
+  * Add Vietnamese debconf translation (closes: #314197).
+  * Add Czech debconf translation (closes: #314749).
+  * Move string2key into heimdal-clients (closes: #314365).
+  * Fix LDAP searches (closes: #318409).
+
+ -- Brian May <bam@debian.org>  Thu, 25 Aug 2005 11:39:59 +1000
+
+heimdal (0.6.3-11) unstable; urgency=low
+
+  * Apply patch to fix "Remotely exploitable buffer overflow in
+    getterminaltype function", reported in Secunia advisory SA15718 at
+    http://secunia.com/advisories/15718/. Closes: #315065.
+
+ -- Brian May <bam@debian.org>  Sun,  3 Jul 2005 13:54:19 +1000
+
+heimdal (0.6.3-10) unstable; urgency=low
+
+  * LDAP support (closes: #95246).
+  * Fix buffer overflow security bug in telnet client, CAN-2005-0469,
+    closes: #305574.
+
+ -- Brian May <bam@debian.org>  Mon, 25 Apr 2005 14:48:03 +1000
+
+heimdal (0.6.3-9) unstable; urgency=low
+
+  * Add Japanese debconf translation (closes: #302485)
+  * Updated replaces for heimdal-clients (closes: #303751).
+  * Support update-alternatives with rcp man page (closes: #303753).
+
+ -- Brian May <bam@debian.org>  Sun, 10 Apr 2005 12:47:40 +1000
+
+heimdal (0.6.3-8) unstable; urgency=low
+
+  * Apply patch to build on amd64 (closes: #300811).
+  * Move verify_krb5_conf man page to heimdal-clients (closes: #299905).
+  * Include danish debconf translations (closes: #296987).
+  * Add missing (versioned) comerr-dev to build depends (closes: #293270).
+
+ -- Brian May <bam@debian.org>  Thu, 24 Mar 2005 10:34:46 +1100
+
+heimdal (0.6.3-7) unstable; urgency=low
+
+  * Remove setconfig from built package, the new kdc.conf config broke this
+    script, and the config it changed wasn't used by Heimdal anyway.
+    Closes: #289295.
+  * Add patch from upstream to stop KDC crashing with SIGPIPE error.
+    Closes: #284498.
+
+ -- Brian May <bam@debian.org>  Fri, 14 Jan 2005 15:59:20 +1100
+
+heimdal (0.6.3-6) unstable; urgency=low
+
+  * Make conflict between heimdal-kdc and krb5-admin-server explicit, see
+    #274763 for details.
+  * Supply better example kdc.conf (closes: #210575). I deliberately omitted
+    the database setting as upstream say it isn't currently usable and will
+    change soon. Improvements welcome.
+  * Fix hardcoded paths to work with openafs (closes: #286249).
+
+ -- Brian May <bam@debian.org>  Mon, 20 Dec 2004 10:39:43 +1100
+
+heimdal (0.6.3-5) unstable; urgency=low
+
+  * Add new German debconf translations (closes: #284375).
+  * Set Project-Id-Version, PO-Revision-Date, Last-Translator fields to
+    Swedish and Russian translations from information in BTS.
+  * Remove kerberos.8.gz man page. This hack is to remove the conflict with
+    kerberos4kth which also contains the same file. It doesn't appear worth
+    keeping. See bug #274763 for details on conflict.
+  * Add note concerning above item in README.Debian.
+  * Make conflict between heimdal-kdc and krb5-kdc explicit, see #274763
+    for details.
+
+ -- Brian May <bam@debian.org>  Sun, 12 Dec 2004 15:41:05 +1100
+
+heimdal (0.6.3-4) unstable; urgency=low
+
+  * Adding the attached Brazilian Portuguese templates (closes: #278730).
+  * Fix typo in prerm script (closes: #280354).
+
+ -- Brian May <bam@debian.org>  Tue,  9 Nov 2004 14:09:01 +1100
+
+heimdal (0.6.3-3) unstable; urgency=low
+
+  * Move kerberos.8.gz from heimdal-servers into heimdal-docs package.
+  * Move kadmind.8.gz from heimdal-servers into heimdal-kdc package.
+  * Conflict with pop3-server instead of qpopper (closes: #274774).
+
+ -- Brian May <bam@debian.org>  Mon, 18 Oct 2004 17:12:05 +1000
+
+heimdal (0.6.3-2) unstable; urgency=low
+
+  * Stop all daemons as long as PID file exists, regardless if deamon is
+    enabled or not (closes: #266575).
+  * Add Dutch po-debconf translations (closes: #263597).
+  * Add some cleanups recommended in #95246 to debian/rules.
+    * Remove debian/*.ex files.
+    * Remove debian/control.* files.
+    * Remove debian/ex.doc-base.package.
+    * Remove obsolete libtool hack.
+    * Remove calls to obsolete dh_suidregister program.
+
+ -- Brian May <bam@debian.org>  Sat, 25 Sep 2004 14:59:21 +1000
+
+heimdal (0.6.3-1) unstable; urgency=low
+
+  * New upstream version.
+
+ -- Brian May <bam@debian.org>  Tue, 14 Sep 2004 08:28:11 +1000
+
+heimdal (0.6.2-0.6.3rc3-1) unstable; urgency=low
+
+  * New upstream version.
+  * Fixes security bugs in FTP server.
+
+ -- Brian May <bam@debian.org>  Mon, 13 Sep 2004 16:00:23 +1000
+
+heimdal (0.6.2-6) unstable; urgency=low
+
+  * Update replaces header for heimdal-clients, to allow for push.8.gz
+    moving from heimdal-servers to heimdal-clients (closes: #264979).
+
+ -- Brian May <bam@debian.org>  Thu, 12 Aug 2004 09:02:48 +1000
+
+heimdal (0.6.2-5) unstable; urgency=low
+
+  * Cave in to pressure and remove libdb4.2-dev from depends in
+    heimdal-dev. See bug #253894 for reasons, both for and against.
+
+ -- Brian May <bam@debian.org>  Mon,  2 Aug 2004 17:46:29 +1000
+
+heimdal (0.6.2-4) unstable; urgency=low
+
+  * Add patch 000_afslog to make afslog work (closes: #261065).
+
+ -- Brian May <bam@debian.org>  Sat, 31 Jul 2004 14:56:32 +1000
+
+heimdal (0.6.2-3) unstable; urgency=low
+
+  * Use default realm configured by krb5-config for KDC (closes:
+    #251725).
+  * Move push.8 man page from heimdal-servers to heimdal-clients
+    (push binary is already in heimdal-clients).
+
+ -- Brian May <bam@debian.org>  Mon, 31 May 2004 08:30:54 +1000
+
+heimdal (0.6.2-2) unstable; urgency=low
+
+  * Make build depends on libssl-dev versioned (closes: #249595).
+  * libdb4.2 support (closes: #223055).
+
+ -- Brian May <bam@debian.org>  Sun, 23 May 2004 10:10:04 +1000
+
+heimdal (0.6.2-1) unstable; urgency=low
+
+  * New upstream version.
+    * Fixes possible buffer overflow bug in the krb4 code in kadmin
+      (CAN-2004-0472).
+    * Disables krb4 support by default in kadmin.
+    * Next upstream version will remove krb4 support in kadmin.
+
+ -- Brian May <bam@debian.org>  Tue, 11 May 2004 09:57:12 +1000
+
+heimdal (0.6.1-1) unstable; urgency=low
+
+  * New upstream version:
+    * Fix cross realm trust vulnerability (closes: #241524).
+
+  * The following patches removed as they appear to be in upstream:
+    * patches/001_sasl_external.
+    * patches/010_gcc33.
+    * patches/016_nessus_dos.
+    * patches/023_db4
+
+  * Simplify patches/032_libtool_version_script, remove hunks that only
+    change line numbers (these created rejects).
+
+ -- Brian May <bam@debian.org>  Sun,  4 Apr 2004 10:14:22 +1000
+
+heimdal (0.6-8) unstable; urgency=low
+
+  * Change /etc/defaults/heimdal-kdc to /etc/default/heimdal-kdc in
+    heimdal-kdc init.d script (closes: #236289).
+  * Add french debconf templates (closes: #236891).
+
+ -- Brian May <bam@debian.org>  Thu, 11 Mar 2004 13:07:59 +1100
+
+heimdal (0.6-7) unstable; urgency=low
+
+  * Use new gettext based debconf (closes: #235170).
+
+ -- Brian May <bam@debian.org>  Sat, 28 Feb 2004 13:15:41 +1100
+
+heimdal (0.6-6) unstable; urgency=low
+
+  * Move /etc/defaults/heimdal-kdc to /etc/default/heimdal-kdc (closes:
+    #233824)
+
+ -- Brian May <bam@debian.org>  Wed, 25 Feb 2004 11:09:29 +1100
+
+heimdal (0.6-5) unstable; urgency=low
+
+  * Add sample kadmind.acl on initial installation (closes: #215649)
+  * Split KDC init.d script into /etc/default/heimdal-kdc (closes: #213534).
+  * Add openldap patch from upstream 001_sasl_external (LDAP is not
+    enabled in build though).
+
+ -- Brian May <bam@debian.org>  Wed, 31 Dec 2003 12:41:38 +1100
+
+heimdal (0.6-4) unstable; urgency=low
+
+  * The "Lets fix all these bugs release" (and see what breaks!).
+  * Set standards version to 3.6.1.
+  * Upgrade to DH_COMPAT version 4.
+  * Fix minor errors reported by linda, including:
+    * Remove call to dh_suidregister.
+    * Add versioned dependancy on debhelper (closes: #216290).
+    * Add versioned depends on debconf,
+  * When START_KDC is set, the init.d script should stop kdc; when
+    START_KPASSWDD is set, the init.d script should stop kpasswdd; not the
+    other way around. Closes #214447.
+  * Fix info pages by installing all files, closes #214248.
+  * Add libtool patch to version symbols, thanks Steve Langasek
+    <vorlon@netexpress.net>. Closes: #205592.
+  * Attempt to link against libdb4.1 instead of libdb3 failed, as automake
+    wouldn't stop complaining about lib/roken/Makefile.am (not touched by
+    this patch). Added debian/patch/db4 all the same.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Sat, 13 Dec 2003 11:17:42 +1100
+
+heimdal (0.6-3) unstable; urgency=low
+
+  * Remove heimdal-libs package, I am not sure why I kept it, it isn't really
+    required for upgrades. This solves the (non-)issue with the description
+    (closes: #209552).
+
+  * Fix nessus DOS attack (closes: #197161).
+
+  * Since 0.6-2.2 no longer links with libreadline (closes: #198511).
+
+ -- Brian May <bam@snoopy.apana.org.au>  Sun, 28 Sep 2003 11:06:57 +1000
+
+heimdal (0.6-2.3) unstable; urgency=low
+
+  * NMU with Blessings from Brian May <bam@debian.org>
+
+ -- Mikael Andersson <mikan@debian.org>  Tue, 16 Sep 2003 07:14:03 +0200
+
+heimdal (0.6-2.2) unstable; urgency=low
+
+  * Compile against libedit instead of libreadline4.
+    Added patch 015_editline
+    Recreated 030_autotools (Need $TMP to be set, and add libtoolize)
+    Changed builddependency from libreadline4-dev to libedit-dev
+    Change configure --with-readline in rules
+
+ -- Mikael Andersson <mikan@debian.org>  Mon, 15 Sep 2003 12:31:46 +0200
+
+heimdal (0.6-2.1) unstable; urgency=low
+
+  * Use com_err from comerr-dev.
+  
+  * Removed comerr-dev, ss-dev from Conflicts of heimdal-dev
+
+ -- Mikael Andersson <mikan@debian.org>  Mon, 15 Sep 2003 11:36:49 +0200
+
+heimdal (0.6-2) unstable; urgency=low
+
+  * Remove login man page, it conflicts with the login package.
+
+ -- Brian May <bam@debian.org>  Sat,  6 Sep 2003 12:40:01 +1000
+
+heimdal (0.6-1) unstable; urgency=low
+
+  * New upstream version.
+  * Built for woody.
+
+ -- Brian May <bam@debian.org>  Thu, 28 Aug 2003 15:50:17 +1000
+
+heimdal (0.5.2-5) unstable; urgency=low
+
+  * Update conflicts for heimdal-clients not to conflict with ftp, as it
+    uses update-alternatives since version 0.16-1 (closes: #202701).
+
+ -- Brian May <bam@debian.org>  Wed,  6 Aug 2003 12:15:05 +1000
+
+heimdal (0.5.2-4) unstable; urgency=low
+
+  * Move conflicts libdb3-dev to depends libdb3-dev, really-closes
+    #196157.
+
+ -- Brian May <bam@debian.org>  Sun, 29 Jun 2003 09:32:20 +1000
+
+heimdal (0.5.2-3) unstable; urgency=low
+
+  * Fix FTBFS error with GCC-3.3 by adding debian/patches/010_gcc33
+    (closes: #196406).
+  * heimdal-dev depends on libdb3-dev, closes: #196157.
+
+ -- Brian May <bam@debian.org>  Sat, 28 Jun 2003 15:47:53 +1000
+
+heimdal (0.5.2-2) unstable; urgency=low
+
+  * Make heimdal-kdc daemons configurable. Also fix type in
+    etc/init.d/heimdal-kdc (closes: #186353).
+  * Upstream said kftp -n option was fixed in 0.5.2-1 (closes: #181697).
+
+ -- Brian May <bam@debian.org>  Thu, 27 Mar 2003 12:26:09 +1100
+
+heimdal (0.5.2-1) unstable; urgency=high
+
+  * New upstream version; Fixes krb4 security bug (closes: #185164).
+  * Remove versioned symbols patch, this more important.
+  * Remove debian/patches/016_openssl, hopefully it is no longer required.
+  * Remove debian/patches/018_sasize, hopefully it is no longer required.
+
+ -- Brian May <bam@debian.org>  Tue, 18 Mar 2003 10:57:31 +1100
+
+heimdal (0.5.1-7) unstable; urgency=low
+
+  * Use versioned symbols for all libraries.
+
+ -- Brian May <bam@debian.org>  Mon, 17 Mar 2003 12:50:38 +1100
+
+heimdal (0.5.1-6) unstable; urgency=low
+
+  * Fix credential delegation bug (018_gssapi_forward).
+  * Rename 023_sasize patch to 018_sasize, 02* is for Debian specific
+  changes, not bugs fixes of upstream code, that is for 01*.
+
+ -- Brian May <bam@debian.org>  Fri,  7 Mar 2003 18:47:29 +1100
+
+heimdal (0.5.1-5) unstable; urgency=low
+
+  * Fix error with sa_size not getting initialized properly. See
+  debian/patches/023_sasize.
+
+ -- Brian May <bam@debian.org>  Tue,  4 Mar 2003 19:06:01 +1100
+
+heimdal (0.5.1-4) unstable; urgency=low
+
+  * Rebuild for sid.
+  * 016_openssl patch to work with openssl 0.9.7.
+  * Now builds on sid (closes: #178775).
+  * New build will have correct dependancy on libroken (closes: #177250).
+
+ -- Brian May <bam@debian.org>  Thu, 30 Jan 2003 11:35:44 +1100
+
+heimdal (0.5.1-3) unstable; urgency=low
+
+  * 015_getifaddrs patch fixes segmentation fault.
+  * Remove *.rej file from 014_cache patch.
+
+ -- Brian May <bam@debian.org>  Thu, 16 Jan 2003 13:30:07 +1100
+
+heimdal (0.5.1-2) unstable; urgency=low
+
+  * Move dependancy on krb5-config to heimdal-servers and heimdal-
+    clients (closes: #171868).
+  * Add build depends on libhesiod-dev, it is only small, and
+    all versions of Heimdal need to be built the same.
+  * These changes were in 0.4e-23, but missed in 0.5.1-1.
+
+ -- Brian May <bam@debian.org>  Thu,  9 Jan 2003 16:29:39 +1100
+
+heimdal (0.5.1-1) unstable; urgency=low
+
+  * New upstream version.
+  * Build-depends on kerberos4kth-dev 1.2.1, it includes a new version
+    of libroken.
+  * New major version of libasn1-6-heimdal (was libasn1-5-heimdal).
+
+ -- Brian May <bam@debian.org>  Thu,  9 Jan 2003 14:34:54 +1100
+
+heimdal (0.5-1) unstable; urgency=low
+
+  * New upstream version.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Sun, 29 Sep 2002 10:06:28 +1000
+
+heimdal (0.4e-20) unstable; urgency=low
+
+  * Add missing depends of kerberos4kth-dev to heimdal-dev (closes:
+    160669).
+  * Add description of changes required to /etc/services to get hprop
+    and/or iprop to work (closes: 139845).
+  * Add sample inetd entry for hprop and sample code in init.d script
+    for iprop (closes: #139851).
+
+ -- Brian May <bam@snoopy.apana.org.au>  Fri, 13 Sep 2002 13:34:04 +1000
+
+heimdal (0.4e-19) unstable; urgency=low
+
+  * Apply patch to fix time sync problem (closes: #155816).
+
+ -- Brian May <bam@snoopy.apana.org.au>  Tue, 20 Aug 2002 13:04:51 +1000
+
+heimdal (0.4e-18) unstable; urgency=low
+
+  * Apply patches from Mikael Andersson to fix FTP bug, closes: 150967.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Thu, 15 Aug 2002 10:05:46 +1000
+
+heimdal (0.4e-17) unstable; urgency=low
+
+  * Use Maintainer Mode for automake.
+  * Include krb5.conf.5heimdal man page (closes: #150293).
+
+ -- Brian May <bam@snoopy.apana.org.au>  Tue,  6 Aug 2002 10:30:07 +1000
+
+heimdal (0.4e-16) unstable; urgency=low
+
+  * Fix heap overflow bug in ftp client that allows remote code
+    execution by malicious ftp server.
+  * Don't delete libkafs.so
+
+ -- Brian May <bam@snoopy.apana.org.au>  Thu, 30 May 2002 09:33:21 +1000
+
+heimdal (0.4e-15) unstable; urgency=low
+
+  * Attempt to use libraries from kerberos4kth.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Mon, 22 Apr 2002 18:03:13 +1000
+
+heimdal (0.4e-14) unstable; urgency=low
+
+  * Attempt to recompile with krb4 support. Closes: #143273.
+    For some reason this was marked as grave, even though the
+    rest of Heimdal functioned OK.
+  * Reopens bug: cyclic dependancies exist between Heimdal and
+    Kerberos4kth. This really needs to get fixed.
+  * Attempt to fix this in debian/patches-0.4e-trial (still needs
+    further work), but this failed as autoconf in Debian doesn't like
+    autoconf files used in Heimdal.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Sat, 20 Apr 2002 15:12:57 +1000
+
+heimdal (0.4e-13) unstable; urgency=low
+
+  * Move push to heimdal-clients (closes: #142331).
+  * The 'but I am sure I removed the build depends for kerberos4kth'
+    release. Closes: #142491
+  * Also get rid of libkafs0, as including an empty libkafs0 could be
+    confusing. closes: #142411
+
+ -- Brian May <bam@snoopy.apana.org.au>  Fri, 12 Apr 2002 18:44:34 +1000
+
+heimdal (0.4e-12) unstable; urgency=low
+
+  * Remove krb4 support, and remove build depends loop.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Wed, 10 Apr 2002 08:29:52 +1000
+
+heimdal (0.4e-11) unstable; urgency=low
+
+  * Move to main.
+  * Attempt to get priorities correct.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Wed,  3 Apr 2002 09:12:15 +1000
+
+heimdal (0.4e-10) unstable; urgency=low
+
+  * Change build depends from libssl096-dev to libssl-dev, closes:
+    #140690.
+  * Some dependancies are still in non-us, so this can't go in
+    main yet. Examples: krb5-config and kerberos4kth.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Mon,  1 Apr 2002 10:39:31 +1000
+
+heimdal (0.4e-9) unstable; urgency=low
+
+  * Use /bin/login instead of /usr/sbin/login (which doesn't exist),
+    closes #139250. /bin/login is better then the login provided with
+    Heimdal, as it provides support for PAM.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Thu, 21 Mar 2002 16:19:28 +1100
+
+heimdal (0.4e-8) unstable; urgency=low
+
+  * heimdal-servers: add conflicts qpopper (closes: #137208).
+  * Add russian debconf template (closes: #137657). I hope the character
+    encoding comes up Ok...
+  * Added note in README.Debian on making ksu setuid root (closes: #84468).
+
+ -- Brian May <bam@snoopy.apana.org.au>  Thu, 14 Mar 2002 11:35:15 +1100
+
+heimdal (0.4e-7) unstable; urgency=low
+
+  * Move krb5-config man page to heimdal-dev (closes: #135957).
+  * Fix extended descriptions (closes #135525, #135515).
+  * Move ktutil man page to heimdal-clients (closes: #136449).
+
+ -- Brian May <bam@snoopy.apana.org.au>  Mon,  4 Mar 2002 14:19:53 +1100
+
+heimdal (0.4e-6) unstable; urgency=low
+
+  * Versioned conflicts against openafs (closes: #127817,#128105).
+
+ -- Brian May <bam@snoopy.apana.org.au>  Tue,  8 Jan 2002 11:19:12 +1100
+
+heimdal (0.4e-5) unstable; urgency=low
+
+  * Change conflicts keerberos4kth-clients, as it has changed from
+    kerberos4kth-user (closes: #124020). heimdal-clients is supposed to
+    have Kerberos4kth support, hence there should be no need to have
+    both installed as the same time.
+  * Build problem on hppa was previously fixed (closes: #101064). 
+  * Fix BSD license (closes: #123822).
+
+ -- Brian May <bam@snoopy.apana.org.au>  Fri, 21 Dec 2001 11:46:23 +1100
+
+heimdal (0.4e-4) unstable; urgency=low
+
+  * Move login back to /usr/sbin/login.
+  * Use update-alternatives for pagsh.
+  * Apply patch to stop kstash from segfaulting (closes: #120502).
+
+ -- Brian May <bam@snoopy.apana.org.au>  Tue,  4 Dec 2001 20:30:38 +1100
+
+heimdal (0.4e-3) unstable; urgency=low
+
+  * Move files to correct packages (closes: #121131)
+
+ -- Brian May <bam@snoopy.apana.org.au>  Mon, 26 Nov 2001 09:22:36 +1100
+
+heimdal (0.4e-2) unstable; urgency=low
+
+  * Kerberos 4 support (closes: #65387).
+  * Build libsl packages (closes: #120496).
+
+ -- Brian May <bam@snoopy.apana.org.au>  Wed, 14 Nov 2001 17:49:40 +1100
+
+heimdal (0.4e-1) unstable; urgency=low
+
+  * New upstream version.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Mon, 10 Sep 2001 09:40:06 +1000
+
+heimdal (0.4c-2) unstable; urgency=low
+
+  * Include devfs fix, telnetd now supports /dev/pts filesystem.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Mon,  6 Aug 2001 14:20:50 +1000
+
+heimdal (0.4c-1) unstable; urgency=low
+
+  * New upstream version.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Sun, 29 Jul 2001 14:33:17 +1000
+
+heimdal (0.3f-1) unstable; urgency=low
+
+  * New upstream version.
+  * Move krb5.conf.5.gz man page from libkrb5 package to heimdal-doc,
+    in order to allow different versions of libkrb5 to be installed
+    at same time. What was I thinking?
+  * Previous compilation was based on old libraries. Lets try again...
+
+ -- Brian May <bam@snoopy.apana.org.au>  Thu, 28 Jun 2001 09:05:09 +1000
+
+heimdal (0.3e-6) unstable; urgency=low
+
+  * heimdal-dev no longer conflicts with kerberos4kth-dev.
+  * build conflicts with heimdal-dev, due to libtool hack.
+  * remove build dependancy on kerberos4kth-dev, as it is not
+    yet used.
+  * remove kafs.h and kafs.3.gz is these conflict with files from
+    kerberos4kth.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Tue, 12 Jun 2001 09:41:34 +1000
+
+heimdal (0.3e-5) unstable; urgency=low
+
+  * Fix library dependancy problem on libdb.
+  * Use libtool 1.4. Other packages should link -lkrb5 or -lgssapi,
+    and none of the other libraries (unless really required).
+  * Split libraries apart.
+  * Remove libsl, as it doesn't seem to be used anymore.
+  * Remove conflicts with kerberos4kth libraries (closes: #58090).
+  * Attempt build with kerberos4kth libraries (not-closed: #65387);
+    attempt failed (compile error); waiting till I get more time to fix
+    this or for somebody to fix it for me ;-).
+  * Uses updated config.sub and config.guess files from libtool 1.4
+    (as far as I can tell). Closes: #98153.
+  * add 31_autotools patch to work around install libtool bug.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Tue, 22 May 2001 11:14:25 +1000
+
+heimdal (0.3e-4) unstable; urgency=low
+
+  * Fix more silly postinst bugs. Disable anonymous ftp logins
+    by default.
+
+ -- Brian May <bam@debian.org>  Thu, 22 Feb 2001 09:38:40 +1100
+
+heimdal (0.3e-3) unstable; urgency=low
+
+  * Use update-alternatives for rcp (closes: #86702)
+  * Remove update-alternatives for rsh when package is removed.
+  * Add upstream patch to select versions for replay_log.
+
+ -- Brian May <bam@debian.org>  Wed, 21 Feb 2001 09:04:58 +1100
+
+heimdal (0.3e-2) unstable; urgency=low
+
+  * Disable anonymous ftp logins by default. This can be changed by
+    using the -a option to ftpd in /etc/inetd.conf.
+  * Add upstream patch to fix weak key detection.
+
+ -- Brian May <bam@debian.org>  Sat, 17 Feb 2001 13:52:35 +1100
+
+heimdal (0.3e-1) unstable; urgency=low
+
+  * New upstream version 0.3e. Warning: This fixes a potential security
+    problem (buffer overrun) in ftpd.
+
+ -- Brian May <bam@debian.org>  Tue,  6 Feb 2001 12:59:14 +1100
+
+heimdal (0.3d-8) unstable; urgency=low
+
+  * Change section to non-US.
+  * Add german translation to heimdal-lib.templates file (closes: #83754).
+  * Add german translation to heimdal-kdc.templates file (closes: #83864).
+  * Add Depends: libssl096 to heimdal-dev, so packages that use
+    heimdal-dev no longer need to include this in build-depends:
+    (unless they really do guse libssl).
+  * disable openldap support by default (I may enable it latter)
+    (closes: #83993).
+  * add patch for openldap.
+  * don't build binary-all for binary-dep target (closes: #84171).
+
+ -- Brian May <bam@debian.org>  Wed, 31 Jan 2001 09:26:39 +1100
+
+heimdal (0.3d-7) unstable; urgency=low
+
+  * Replace missing prerm script for heimdal-kdc, as kadmind wasn't being
+    disabled (in /etc/inetd.conf) on --remove (closes: #83526).
+  * Fix type in postrm script for heimdal-servers, as inetd entry for ftp
+    wasn't getting removed on -purge.
+  * Fix type in postrm script for heimdal-servers-x, as inetd entry for kx
+    wasn't getting removed on -purge.
+  * Add swedish translation to heimdal-lib.templates file.
+    Also add same translation to question in heimdal-kdc.templates, as the
+    question is exactly the same (closes: #83535).
+
+ -- Brian May <bam@debian.org>  Fri, 26 Jan 2001 10:27:13 +1100
+
+heimdal (0.3d-6) unstable; urgency=low
+
+  * Use rsh-server and telnet-sever virtual packages (see bug #77404).
+
+ -- Brian May <bam@debian.org>  Thu, 18 Jan 2001 18:20:54 +1100
+
+heimdal (0.3d-5) unstable; urgency=low
+
+  * Fix ftp bug with ports > 32767 (closes: #81663).
+  * Move krb5-config to heimdal-dev.
+
+ -- Brian May <bam@debian.org>  Fri, 12 Jan 2001 09:02:03 +1100
+
+heimdal (0.3d-4) unstable; urgency=low
+
+  * Better, non-hacked fix for krb5-config. Patch from
+    GOMBAS Gabor <gombasg@inf.elte.hu>.
+
+ -- Brian May <bam@debian.org>  Tue,  9 Jan 2001 10:13:28 +1100
+
+heimdal (0.3d-3) unstable; urgency=low
+
+  * Compile using libssl026 instead of libdes. Patch from
+    GOMBAS Gabor <gombasg@inf.elte.hu>.
+
+ -- Brian May <bam@debian.org>  Sat,  6 Jan 2001 10:30:03 +1100
+
+heimdal (0.3d-2) unstable; urgency=low
+
+  * Add libdb2-dev to build-depends (closes: #80442).
+
+ -- Brian May <bam@debian.org>  Tue, 26 Dec 2000 10:59:44 +1100
+
+heimdal (0.3d-1) unstable; urgency=low
+
+  * New upstream version.
+
+ -- Brian May <bam@debian.org>  Tue, 12 Dec 2000 16:20:34 +1100
+
+heimdal (0.3c-6) unstable; urgency=low
+
+  * Rename xnlock.man to xnlock.1, closes: #78117
+  * Move xnlock.1 to heimdal-clients-x.
+
+ -- Brian May <bam@debian.org>  Tue, 28 Nov 2000 09:55:12 +1100
+
+heimdal (0.3c-5) unstable; urgency=low
+
+  * New structure for source. Now there is a different patch for each
+  change from upstream (closes: 77000).
+  * Move TODO and NEWS documentation to heimdal-docs, where it should always
+  have been
+  * Apply patch from
+  http://ns1.logidee.com/~joko/heimdal/src/heimdal_cache.patch,
+  which should allow PAM module to work.
+
+ -- Brian May <bam@debian.org>  Sat, 18 Nov 2000 13:04:39 +1100
+
+heimdal (0.3c-4) unstable; urgency=low
+
+  * applied patch to fix ftpd problem (closes: #64746).
+
+ -- Brian May <bam@debian.org>  Wed,  8 Nov 2000 17:26:16 +1100
+
+heimdal (0.3c-3) unstable; urgency=low
+
+  * Try to strip binaries again, by making libeditline libtool
+  controlled.
+
+ -- Brian May <bam@debian.org>  Mon,  9 Oct 2000 09:20:27 +1100
+
+heimdal (0.3c-2) unstable; urgency=low
+
+  * applied patch to disable line editing in ftp (closes: #69301).
+
+ -- Brian May <bam@debian.org>  Thu,  5 Oct 2000 09:15:44 +1100
+
+heimdal (0.3c-1) unstable; urgency=low
+
+  * New upstream version.
+  * applied patch to fix missing newline problem in ftp (closes: #64289).
+  * dh_strip commented out, as it crashed the build process.
+    A bug (#73637) has been opened on this issue.
+
+ -- Brian May <bam@debian.org>  Mon,  2 Oct 2000 10:07:53 +1100
+
+heimdal (0.3b-2) unstable; urgency=low
+
+  * Add debhelper, xlib6g-dev to build dependancies (closes: #70718).
+  
+  * Change documentation to indicate that kadmind uses kadmind.acl,
+    not kadm5.acl, as previously specified. Add warning in default
+    kdc.conf file that it needs checking, as it may not be
+    correct. Everything should work OK though with default values.
+    closes: #69139.
+
+ -- Brian May <bam@debian.org>  Sat,  2 Sep 2000 15:46:53 +1100
+
+heimdal (0.3b-1) unstable; urgency=low
+
+  * New upstream version.
+  
+  * Shouldn't conflict with telnet anymore, as both use
+    update-alternatives (not tested yet).
+  
+  * Provides telnet-client instead of telnet, as telnet-client is now
+    the accepted virtual package (see closed bug #58759).
+
+ -- Brian May <bam@debian.org>  Wed, 30 Aug 2000 10:58:07 +1100
+
+heimdal (0.3a-2) unstable; urgency=low
+
+  * Remove /usr/include/glob.h from heimdal-dev (closes: #68649). This
+  file conflicts with libc6-dev.
+
+  * For some reason heimdal doesn't detect /usr/include/glob.h, why?
+
+ -- Brian May <bam@debian.org>  Sun,  6 Aug 2000 18:07:52 +1000
+
+heimdal (0.3a-1) unstable; urgency=low
+
+  * New upstream version.
+  
+  * -rpath hack no longer required.
+  
+  * fix bug in postinst script (closes: #67509).
+
+  * No longer conflicts with rsh-client (<< 0.16.1-1), as rsh-client
+  now uses update-alternatives (closes: #58102).
+
+  * Uses new libtool version 1.3c (closes: 59037).
+
+ -- Brian May <bam@debian.org>  Mon, 31 Jul 2000 13:21:21 +1000
+
+heimdal (0.2t-1) unstable; urgency=low
+
+  * New upstream version.
+
+ -- Brian May <bam@debian.org>  Fri, 19 May 2000 15:24:31 +1000
+
+heimdal (0.2r-2) unstable; urgency=low
+
+  * Add Build-Depends and Build-Conflicts line. It is possible
+  that the Build-Conflicts might be excessive (some libraries  
+  can be turned of with command line options to Configure),
+  however, I think this is safest for now.
+
+ -- Brian May <bam@debian.org>  Sun, 16 Apr 2000 10:29:33 +1000
+
+heimdal (0.2r-1) unstable; urgency=low
+
+  * New upstream version.
+  * Fix yet another silly typo in postinst script.
+  * Added hack to use defaults inside kadmin init without crashing.
+
+ -- Brian May <bam@debian.org>  Wed,  5 Apr 2000 14:36:55 +1000
+
+heimdal (0.2q-3) unstable; urgency=low
+
+  * fix silly typo in postinst script (closes: #61482).
+
+ -- Brian May <bam@debian.org>  Sat,  1 Apr 2000 12:33:34 +1000
+
+heimdal (0.2q-2) unstable; urgency=low
+
+  * Password to kstash now handled by debconf.
+
+ -- Brian May <bam@debian.org>  Sun, 12 Mar 2000 12:16:25 +1100
+
+heimdal (0.2q-1) unstable; urgency=low
+
+  * New upstream version.
+  * Looking through the upstream Changelog, I cannot see any changes
+  that might break functionality that wasn't already broken.
+  * Fix problem with debconf script (closes: #58011).
+  * Change ftp dependancy to ftp-server (closes: #58118).
+  * Replaced power-pc fix with patch from upstream.
+  * Fixed shlibs dependancy information - all executables will now
+  depend on *this* upstream version of heimdal-lib. This is currently
+  a hacked solution to allow clean (future) upgrades.
+  * Moved README.Debian to heimdal-docs.
+  * Include doc/standardisation in heimdal-docs, contains information
+  not found elsewhere.
+  * Use update-alternatives for rsh.
+  * Hack debian/rules not to run configure.
+  * ftp/ftpd no longer seems to work, fixes welcome.
+  * This should really go to frozen, but because of above problem
+  will go into unstable only.
+  
+ -- Brian May <bam@debian.org>  Fri, 25 Feb 2000 15:46:16 +1100
+
+heimdal (0.2l-7) frozen unstable; urgency=low
+
+  * Copied copyright file from doc/heimdal.texi
+  * heimdal-servers no longer conflicts with rsh-server (closes: #57545).
+  * heimdal-lib conflicts with kerberos4kth (closes: #57587, #57602, #57654).
+  * this conflicts business is never ending...
+  * fixed minor bugs in README.Debian, eg there is no need to
+  extract the kadmin/admin key to /etc/krb5.keytab.
+  * fixed compilation problem on power-pc (closes: #57919).
+
+ -- Brian May <bam@debian.org>  Sun, 13 Feb 2000 19:46:37 +1100
+
+heimdal (0.2l-6) frozen unstable; urgency=low
+
+  * Move /usr/bin/compile_et into heimdal-dev.
+  * heimdal-clients conflicts with otp.
+  * heimdal-dev conflicts with ss-dev and comerr-dev (closes: #56281).
+  * minor changes to sample kdc.conf file. eg stash file created
+  by postinst script wasn't used by kdc...
+
+ -- Brian May <bam@debian.org>  Sat, 29 Jan 2000 09:58:00 +1100
+
+heimdal (0.2l-5) frozen unstable; urgency=low
+
+  * Heimdal-servers: reenable telnet properly after upgrade
+    (closes: #55733).
+  * Change section to non-US/main (closes: #55546).
+  * These changes wont break anything that wasn't already broken ;-).
+  
+ -- Brian May <bam@debian.org>  Thu, 20 Jan 2000 16:13:21 +1100
+
+heimdal (0.2l-4) frozen unstable; urgency=low
+
+  * heimdal-kdc nows starts password server, so users can change
+    passwords.
+  * heimdal-kdc now inserts entry for kadmind into /etc/inetd.conf.
+    kadmind is essential for normal kerberos administration.
+  * Fix /etc/init.d/heimdal-kdc restart so it works.
+  * No code has been changed/added/removed apart from postinst,
+    prerm, postrm and init scripts for the above changes.
+  * Got rid of stupid looking syntax for log file in sample kdc.conf.
+  * Minor changes (including addition of examples) into README.Debian.
+  * Known problem: debconf doesn't replace default value for
+    some reason on initial installation. I can't see whats wrong...
+    This is annoying, but not a critical problem.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Mon, 17 Jan 2000 19:07:06 +1100
+
+heimdal (0.2l-3) unstable; urgency=low
+
+  * Conflicts with kerberos4kth packages. closes: #54783.
+  * Move kstash and man page to heimdal-kdc.
+  * Move kxd man page to heimdal-servers-x.
+  * Move kadmind page to heimdal-kdc.
+  * Move kpasswdd and man page to heimdal-kdc.
+  * Fix permissions of /var/lib/heimdal-kdc.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Fri, 14 Jan 2000 19:18:51 +1100
+
+heimdal (0.2l-2) unstable; urgency=low
+
+  * Move man pages into proper packages.
+  * heimdal-servers now conflicts and provides ftpd.
+    (closes: #54818).
+  * Problems believed to already be fixed. closes: #54792.
+  * heimdal-lib postrm: add -f parameter to rm so that it will not
+    fail if the file doesn't exist. closes: #54847.
+  * Rename telnet and ftp to ktelnet and kftp respectively.
+  * Use update-alternatives for ftp and telnet.
+    (note rxtelnet still uses telnet, not ktelnet).
+
+ -- Brian May <bam@snoopy.apana.org.au>  Thu, 13 Jan 2000 10:47:14 +1100
+
+heimdal (0.2l-1) unstable; urgency=low
+
+  * New upstream source.
+  * heimdal-clients now provides ftp, telnet, and rsh-client
+    (closes: #54497).
+  * heimdal-servers now provides telnetd and rsh-server.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Sun,  9 Jan 2000 10:00:02 +1100
+
+heimdal (0.2j-1) unstable; urgency=low
+
+  * New upstream source.
+  * Improved debconf support, using setconfig helper program.
+  * setconfig may not parse all valid configuration files correctly.
+    Patches welcome!
+  * Moved /usr/bin/login to /usr/lib/heimdal-servers/login, as I
+    suspect this will help porting to the Hurd, if/when anyone tries.
+  * kdc now supports (and requires) logrotate.
+  * kdc tested and now works with minimal configuration.
+  * heimdal-kdc does not support dpkg-reconfigure (not sure how to
+    reconfigure without deleting existing setup first).
+
+ -- Brian May <bam@snoopy.apana.org.au>  Wed,  5 Jan 2000 02:31:00 +0000
+
+heimdal (0.2i-1) unstable; urgency=low
+
+  * Initial Release.
+
+ -- Brian May <bam@snoopy.apana.org.au>  Wed,  8 Dec 1999 11:54:13 +1100
+
diff --git a/debian/compat b/debian/compat
new file mode 100644
index 000000000..7f8f011eb
--- /dev/null
+++ b/debian/compat
@@ -0,0 +1 @@
+7
diff --git a/debian/control b/debian/control
new file mode 100644
index 000000000..c541f6b6c
--- /dev/null
+++ b/debian/control
@@ -0,0 +1,322 @@
+Source: heimdal
+Section: net
+Priority: optional
+Maintainer: Brian May <bam@debian.org>
+Uploaders: Jelmer Vernooij <jelmer@debian.org>
+Homepage: http://www.h5l.org/
+Standards-Version: 3.9.1
+Build-Depends: libncurses5-dev, bison, flex, debhelper (>= 7), libx11-dev, libxau-dev, libxt-dev, x11proto-core-dev, libdb-dev, cdbs, libhesiod-dev, comerr-dev (>= 1.41.11), libldap2-dev, ss-dev, texinfo, python, libsqlite3-dev, libedit-dev
+Build-Conflicts: heimdal-dev
+
+Package: heimdal-docs
+Section: doc
+Priority: extra
+Architecture: all
+Depends: ${misc:Depends}, dpkg (>= 1.15.4) | install-info
+Replaces: heimdal-lib (<< 0.3c-5), libkrb5-15-heimdal, heimdal-servers (<< 0.6.3-3)
+Conflicts: heimdal-lib (<< 0.3c-5)
+Suggests: heimdal-clients, heimdal-clients-x, heimdal-servers, heimdal-servers-x
+Description: Heimdal Kerberos - documentation
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package includes documentation (in info format) on how to
+ use Heimdal, and relevant standards for Kerberos.
+
+Package: heimdal-kdc
+Priority: extra
+Architecture: any
+Conflicts: kerberos4kth-kdc, heimdal-clients (<< 0.4e-3), heimdal-servers (<< 0.6.3-3), krb5-kdc, krb5-admin-server
+Depends: ${shlibs:Depends}, ${misc:Depends}, heimdal-clients, debconf (>= 0.5.00) | debconf-2.0, krb5-config, openbsd-inetd|inet-superserver
+Recommends: logrotate
+Replaces: heimdal-clients (<< 0.7.2-1), heimdal-servers (<< 0.4e-3)
+Suggests: heimdal-docs
+Description: Heimdal Kerberos - key distribution center (KDC)
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package includes the KDC (key distribution center) server,
+ which is designed to run on a secure computer and keeps track
+ of users' passwords. This is done using the Kerberos protocol in
+ such a way that the server computers do not need to know the
+ passwords.
+
+Package: heimdal-multidev
+Section: devel
+Priority: extra
+Architecture: any
+Conflicts: heimdal-clients (<< 0.4e-7), kerberos4kth-dev
+Depends: ${misc:Depends}, libasn1-8-heimdal (= ${binary:Version}), libkrb5-26-heimdal (= ${binary:Version}), libhdb9-heimdal (= ${binary:Version}), libkadm5srv8-heimdal (= ${binary:Version}), libkadm5clnt7-heimdal (= ${binary:Version}), libgssapi2-heimdal (= ${binary:Version}), libkafs0-heimdal (= ${binary:Version}), libwind0-heimdal (= ${binary:Version}), libhcrypto4-heimdal (= ${binary:Version}), libheimbase1-heimdal (= ${binary:Version}), comerr-dev
+Replaces: heimdal-clients (<< 0.4e-7)
+Suggests: heimdal-docs
+Description: Heimdal Kerberos - Multi-implementation Development
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package provides versions of the Heimdal development files that
+ can be installed along-side MIT Kerberos development files.
+ Normally, heimdal-dev should be used. However if a package needs to
+ build  against both Heimdal Kerberos and MIT Kerberos, then the
+ multidev package should be used. 
+
+Package: heimdal-dev
+Depends: heimdal-multidev (= ${binary:Version}), ${misc:Depends}
+Section: devel
+Conflicts: libkrb5-dev
+Priority: extra
+Architecture: any
+Description: Heimdal Kerberos - development files
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This is the development package, required for developing
+ programs for Heimdal.
+
+Package: heimdal-clients-x
+Priority: extra
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, heimdal-clients
+Replaces: heimdal-clients (<< 0.2l-2)
+Conflicts: heimdal-clients (<< 0.2l-2), kerberos4kth-x11
+Suggests: heimdal-docs
+Description: Heimdal Kerberos - X11 client programs
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package includes Kerberos client programs for forwarding the X
+ connection securely to a remote computer.
+
+Package: heimdal-clients
+Priority: extra
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, krb5-config
+Conflicts: telnet (<< 0.17-1), ftp (<< 0.16-1), rsh-client (<< 0.16.1-1), netstd, telnet-ssl (<< 0.14.9-2), ssltelnet, kerberos4kth-user, kerberos4kth-clients, otp, heimdal-servers (<< 0.4e-7), openafs-client (<< 1.2.2-3)
+Provides: telnet-client, ftp, rsh-client
+Suggests: heimdal-docs, heimdal-kcm
+Replaces: heimdal-servers (<< 0.6.3-12)
+Description: Heimdal Kerberos - clients
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package includes Kerberos utilities like kadmin, kinit, kpasswd and
+ klist. It also includes client programs like telnet and ftp that have been
+ compiled with Kerberos support.
+
+Package: heimdal-kcm
+Priority: extra
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - KCM daemon
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package includes the KCM daemon which can hold the credentials
+ for all users in the system. Access control is done with Unix-like
+ permissions. The daemon checks the access on all operations based on
+ the UID and GID of the user. The tickets are renewed as long as is
+ permitted by the KDC's policy.
+
+Package: heimdal-servers-x
+Priority: extra
+Architecture: any
+Conflicts: kerberos4kth-x11, heimdal-servers (<< 0.2l-3)
+Depends: ${shlibs:Depends}, ${misc:Depends}, openbsd-inetd|inet-superserver, heimdal-servers
+Suggests: heimdal-docs
+Replaces: heimdal-servers (<< 0.2l-3)
+Description: Heimdal Kerberos - X11 server programs
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package includes Kerberos server programs for forwarding the X
+ connection securely from a remote computer.
+
+Package: heimdal-servers
+Priority: extra
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, openbsd-inetd|inet-superserver, krb5-config
+Conflicts: telnetd,  wu-ftpd-academ (<< 2.5.0), netstd, heimdal-clients (<< 0.2l-2), telnetd-ssl, kerberos4kth-services, ftp-server, rsh-server, telnet-server, pop3-server
+Provides: ftp-server, rsh-server, telnet-server, pop3-server
+Suggests: heimdal-docs
+Replaces: heimdal-clients (<< 0.2l-2)
+Description: Heimdal Kerberos - server programs
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package includes servers such as telnetd and ftpd that have been
+ compiled with Heimdal support.
+
+Package: heimdal-dbg
+Priority: extra
+Architecture: any
+Section: debug
+Depends: ${shlibs:Depends}, ${misc:Depends}, libkrb5-26-heimdal (= ${binary:Version})
+Description: Heimdal Kerberos - key distribution center (KDC)
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package contains the debugging symbols for all heimdal libraries.
+
+Package: libheimbase1-heimdal
+Section: libs
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - Base library
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package contains the base library.
+
+Package: libasn1-8-heimdal
+Section: libs
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - ASN.1 library
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package contains the ASN.1 parser required for Heimdal.
+
+Package: libkrb5-26-heimdal
+Section: libs
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - libraries
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package contains the Kerberos 5 library.
+
+Package: libhdb9-heimdal
+Section: libs
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Replaces: heimdal-lib (<< 0.3e-5)
+Conflicts: heimdal-libs (<< 0.3e-5)
+Description: Heimdal Kerberos - kadmin server library
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package contains the library for storing the KDC database.
+
+Package: libkadm5srv8-heimdal
+Section: libs
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Libraries for Heimdal Kerberos
+ Heimdal is a free implementation of Kerberos 5, that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package contains the server library for kadmin.
+
+Package: libkadm5clnt7-heimdal
+Section: libs
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - kadmin client library
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package contains the client library for kadmin.
+
+Package: libgssapi2-heimdal
+Section: libs
+Architecture: any
+Conflicts: libgssapi2
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - GSSAPI support library
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package contains the library for GSSAPI support.
+
+Package: libkafs0-heimdal
+Section: libs
+Priority: extra
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - KAFS support library
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package contains the library for KAFS support.
+
+Package: libroken18-heimdal
+Section: libs
+Priority: extra
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - roken support library
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package contains the library for roken support.
+
+Package: libotp0-heimdal
+Section: libs
+Priority: extra
+Architecture: any
+Conflicts: libotp0-kerberos4kth
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - OTP support library
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package contains the library for OTP support.
+
+Package: libsl0-heimdal
+Section: libs
+Priority: extra
+Architecture: any
+Conflicts: libsl0-kerberos4kth
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - SL support library
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package contains the library for SL support.
+
+Package: libkdc2-heimdal
+Section: libs
+Priority: extra
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - KDC support library
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+
+Package: libhx509-5-heimdal
+Section: libs
+Priority: extra
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - X509 support library
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+
+Package: libheimntlm0-heimdal
+Section: libs
+Priority: extra
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - NTLM support library
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+
+Package: libwind0-heimdal
+Section: libs
+Priority: extra
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - NTLM support library
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+
+Package: libhcrypto4-heimdal
+Section: libs
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: Heimdal Kerberos - crypto library
+ Heimdal is a free implementation of Kerberos 5 that aims to be
+ compatible with MIT Kerberos.
+ .
+ This package contains the cryptographic library required for Heimdal.
diff --git a/debian/copyright b/debian/copyright
new file mode 100644
index 000000000..0386f224f
--- /dev/null
+++ b/debian/copyright
@@ -0,0 +1,186 @@
+This package was debianized by Brian May <bam@snoopy.apana.org.au> on
+Wed,  8 Dec 1999 11:54:13 +1100.
+
+It was downloaded from http://www.pdc.kth.se/heimdal/
+
+Upstream Authors: heimdal-bugs@pdc.kth.se
+(see above URL for mailing list info).
+
+Copyrights:
+
+As found in doc/heimdal.texi.
+
+
+
+Copyright (c) 1996-2000 Kungliga Tekniska Högskolan 
+(Royal Institute of Technology, Stockholm, Sweden).
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+3. Neither the name of the Institute nor the names of its contributors
+   may be used to endorse or promote products derived from this software
+   without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+
+
+Copyright (C) 1995-1997 Eric Young (eay@@mincom.oz.au)
+All rights reserved.
+
+This package is an DES implementation written by Eric Young (eay@@mincom.oz.au).
+The implementation was written so as to conform with MIT's libdes.
+
+This library is free for commercial and non-commercial use as long as
+the following conditions are aheared to.  The following conditions
+apply to all code found in this distribution.
+
+Copyright remains Eric Young's, and as such any Copyright notices in
+the code are not to be removed.
+If this package is used in a product, Eric Young should be given attribution
+as the author of that the SSL library.  This can be in the form of a textual
+message at program startup or in documentation (online or textual) provided
+with the package.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+1. Redistributions of source code must retain the copyright
+   notice, this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+3. All advertising materials mentioning features or use of this software
+   must display the following acknowledgement:
+   This product includes software developed by Eric Young (eay@@mincom.oz.au)
+
+THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+
+
+Copyright (C) 1990 by the Massachusetts Institute of Technology
+
+Export of this software from the United States of America may
+require a specific license from the United States Government.
+It is the responsibility of any person or organization contemplating
+export to obtain such a license before exporting.
+
+WITHIN THAT CONSTRAINT, permission to use, copy, modify, and
+distribute this software and its documentation for any purpose and
+without fee is hereby granted, provided that the above copyright
+notice appear in all copies and that both that copyright notice and
+this permission notice appear in supporting documentation, and that
+the name of M.I.T. not be used in advertising or publicity pertaining
+to distribution of the software without specific, written prior
+permission.  M.I.T. makes no representations about the suitability of
+this software for any purpose.  It is provided "as is" without express
+or implied warranty.
+
+
+
+Copyright (c) 1988, 1990, 1993
+     The Regents of the University of California.  All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+3. Neither the name of the University nor the names of its contributors
+   may be used to endorse or promote products derived from this software
+   without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+
+
+Copyright 1992 Simmule Turner and Rich Salz.  All rights reserved. 
+
+This software is not subject to any license of the American Telephone 
+and Telegraph Company or of the Regents of the University of California. 
+
+Permission is granted to anyone to use this software for any purpose on
+any computer system, and to alter it and redistribute it freely, subject
+to the following restrictions:
+
+1. The authors are not responsible for the consequences of use of this
+   software, no matter how awful, even if they arise from flaws in it.
+
+2. The origin of this software must not be misrepresented, either by
+   explicit claim or by omission.  Since few users ever read sources,
+   credits must appear in the documentation.
+
+3. Altered versions must be plainly marked as such, and must not be
+   misrepresented as being the original software.  Since few users
+   ever read sources, credits must appear in the documentation.
+
+4. This notice may not be removed or altered.
+
+
+
+
+RFCs in lib/wind:
+
+rfc3454.txt has been stripped of content, only the tables remain.
+
+rfc3490.txt, rfc3491.txt, rfc4013.txt, rfc4518.txt have been removed.
+
+rfc3492.txt contains the following license:
+
+   Regarding this entire document or any portion of it (including the
+   pseudocode and C code), the author makes no guarantees and is not
+   responsible for any damage resulting from its use.  The author grants
+   irrevocable permission to anyone to use, modify, and distribute it in
+   any way that does not diminish the rights of anyone else to use,
+   modify, and distribute it, provided that redistributed derivative
+   works do not contain misleading author or version information.
+   Derivative works need not be licensed under similar terms.
diff --git a/debian/extras/default b/debian/extras/default
new file mode 100644
index 000000000..6ed54f390
--- /dev/null
+++ b/debian/extras/default
@@ -0,0 +1,17 @@
+# Do we start the KDC?
+KDC_ENABLED=yes
+KDC_PARAMS="--config-file=/etc/heimdal-kdc/kdc.conf"
+
+# the kpasswdd?
+KPASSWDD_ENABLED=yes
+KPASSWDD_PARAMS=""
+
+# kprop master?
+MASTER_ENABLED=no
+
+# How about the kprop slave?
+SLAVE_ENABLED=no
+
+# Add at least your master server name here when using iprop-replication
+# otherwise it would fail silently.
+SLAVE_PARAMS=""
diff --git a/debian/extras/kadmind.acl b/debian/extras/kadmind.acl
new file mode 100644
index 000000000..e5da87fb5
--- /dev/null
+++ b/debian/extras/kadmind.acl
@@ -0,0 +1 @@
+#principal       [priv1,priv2,...]       [glob-pattern]
diff --git a/debian/extras/kdc.conf b/debian/extras/kdc.conf
new file mode 100644
index 000000000..4464d8b3c
--- /dev/null
+++ b/debian/extras/kdc.conf
@@ -0,0 +1,188 @@
+[logging]
+# Specifies that entity should use the specified
+# destination for logging.  See the krb5_openlog(3)
+# manual page for a list of defined destinations.
+#
+kdc = FILE:/var/log/heimdal-kdc.log
+#
+# syslog also supported:
+#
+# kdc = SYSLOG:INFO
+
+[kdc]
+
+# database = {
+#
+#  dbname = DATABASENAME
+#       Use this database for this realm.  See
+#       the info documetation how to configure
+#       diffrent database backends.
+#
+#  realm = REALM
+#       Specifies the realm that will be stored
+#       in this database.  It realm isn't set,
+#       it will used as the default database,
+#       there can only be one entry that doesn't
+#       have a realm stanza.
+#
+#  mkey_file = FILENAME
+#       Use this keytab file for the master key
+#       of this database.  If not specified
+#       DATABASENAME.mkey will be used.
+#
+#  acl_file = PA FILENAME
+#       Use this file for the ACL list of this
+#       database.
+#
+#  log_file = FILENAME
+#       Use this file as the log of changes per-
+#       formed to the database.  This file is
+#       used by ipropd-master for propagating
+#       changes to slaves.
+#
+# }
+
+database = {
+  dbname = /var/lib/heimdal-kdc/heimdal
+  acl_file = /etc/heimdal-kdc/kadmind.acl
+}
+
+# Maximum size of a kdc request.
+#
+# max-request = SIZE
+
+# If set pre-authentication is required.  Since krb4
+# requests are not pre-authenticated they will be
+# rejected.
+#
+# require-preauth = BOOL
+
+# List of ports the kdc should listen to.
+#
+# ports = list of ports
+
+# List of addresses the kdc should bind to.
+#
+# addresses = list of interfaces
+
+# Should the kdc answer kdc-requests over http.
+#
+# enable-http = BOOL
+
+# If this kdc should emulate the AFS kaserver.
+#
+# enable-kaserver = BOOL
+
+# Verify the addresses in the tickets used in tgs
+# requests.
+#
+# check-ticket-addresses = BOOL
+
+# Allow address-less tickets.
+#
+# allow-null-ticket-addresses = BOOL
+
+# If the kdc is allowed to hand out anonymous tick-
+# ets.
+#
+# allow-anonymous = BOOL
+
+# Encode as-rep as tgs-rep tobe compatible with mis-
+# takes older DCE secd did.
+# encode_as_rep_as_tgs_rep = BOOL
+
+# The time before expiration that the user should be
+# warned that her password is about to expire.
+#
+# kdc_warn_pwexpire = TIME
+
+# What type of logging the kdc should use, see also
+# [logging]/kdc.
+#
+# logging = Logging
+
+# use_2b = {
+#
+#  principal = BOOL
+#       boolean value if the 524 daemon should
+#       return AFS 2b tokens for principal.
+#
+#  ...
+#
+# }
+
+# If the LDAP backend is used for storing principals,
+# this is the structural object that will be used
+# when creating and when reading objects.  The
+# default value is account .
+#
+# hdb-ldap-structural-object structural object
+
+# is the dn that will be appended to the principal
+# when creating entries.  Default value is the search
+# dn.
+#
+# hdb-ldap-create-base creation dn
+
+[kadmin]
+
+# If pre-authentication is required to talk to the
+# kadmin server.
+#
+# require-preauth = BOOL
+
+# If a principal already have its password set for
+# expiration, this is the time it will be valid for
+# after a change.
+#
+# password_lifetime = time
+
+# For each entry in default_keys try to parse it as a
+# sequence of etype:salttype:salt syntax of this if
+# something like:
+#
+# [(des|des3|etype):](pw-salt|afs3-salt)[:string]
+#
+# If etype is omitted it means everything, and if
+# string is omitted it means the default salt string
+# (for that principal and encryption type).  Addi-
+# tional special values of keytypes are:
+#
+#  v5   The Kerberos 5 salt pw-salt
+#
+#  v4   The Kerberos 4 salt des:pw-salt:
+#
+# default_keys = keytypes...
+
+# When true, this is the same as
+# 
+# default_keys = des3:pw-salt v4
+# 
+# and is only left for backwards compatibility.
+# use_v4_salt = BOOL
+
+[password-quality]
+# Check the Password quality assurance in the info documentation
+# for more information.
+
+# Library name that contains the password check_func-
+# tion
+#
+# check_library = library-name
+
+# Function name for checking passwords in
+# check_library
+#
+# check_function = function-name
+
+# List of libraries that can do password policy
+# checks
+#
+# policy_libraries = library1 ... libraryN
+
+# List of policy names to apply to the password.
+# Builtin policies are among other minimum-length,
+# character-class, external-check.
+#
+# policies = policy1 ... policyN
+
diff --git a/debian/format b/debian/format
new file mode 100644
index 000000000..163aaf8d8
--- /dev/null
+++ b/debian/format
@@ -0,0 +1 @@
+3.0 (quilt)
diff --git a/debian/heimdal-clients-x.install b/debian/heimdal-clients-x.install
new file mode 100644
index 000000000..4a441281d
--- /dev/null
+++ b/debian/heimdal-clients-x.install
@@ -0,0 +1,10 @@
+usr/bin/kx
+usr/bin/rxterm
+usr/bin/rxtelnet
+usr/bin/tenletxr
+usr/bin/xnlock
+usr/share/man/man1/kx.1
+usr/share/man/man1/rxterm.1
+usr/share/man/man1/rxtelnet.1
+usr/share/man/man1/tenletxr.1
+usr/share/man/man1/xnlock.1
diff --git a/debian/heimdal-clients.install b/debian/heimdal-clients.install
new file mode 100644
index 000000000..c6e1f30a5
--- /dev/null
+++ b/debian/heimdal-clients.install
@@ -0,0 +1,43 @@
+usr/bin/afslog
+usr/bin/rsh
+usr/bin/kdestroy
+usr/bin/kf
+usr/bin/kgetcred
+usr/bin/kinit
+usr/bin/klist
+usr/bin/kpasswd
+usr/bin/otp
+usr/bin/otpprint
+usr/bin/su
+usr/bin/pfrom
+usr/bin/rcp
+usr/bin/string2key
+usr/bin/ftp
+usr/bin/verify_krb5_conf
+usr/bin/telnet
+usr/bin/pagsh
+usr/bin/hxtool
+usr/sbin/kadmin
+usr/sbin/ktutil
+usr/sbin/push
+usr/share/man/man1/kdestroy.1
+usr/share/man/man1/kf.1
+usr/share/man/man1/kinit.1
+usr/share/man/man1/klist.1
+usr/share/man/man1/kpasswd.1
+usr/share/man/man1/otp.1
+usr/share/man/man1/otpprint.1
+usr/share/man/man1/su.1
+usr/share/man/man1/pfrom.1
+usr/share/man/man1/ftp.1
+usr/share/man/man1/telnet.1
+usr/share/man/man1/afslog.1
+usr/share/man/man1/rcp.1
+usr/share/man/man1/rsh.1
+usr/share/man/man1/kgetcred.1
+usr/share/man/man1/pagsh.1
+usr/share/man/man8/kadmin.8
+usr/share/man/man8/ktutil.8
+usr/share/man/man8/push.8
+usr/share/man/man8/verify_krb5_conf.8
+usr/share/man/man8/string2key.8
diff --git a/debian/heimdal-clients.postinst b/debian/heimdal-clients.postinst
new file mode 100644
index 000000000..db283d7f4
--- /dev/null
+++ b/debian/heimdal-clients.postinst
@@ -0,0 +1,10 @@
+#!/bin/sh -e
+
+for i in ftp telnet rsh rcp pagsh
+do
+    update-alternatives --install /usr/bin/$i $i /usr/bin/k$i 23 \
+    --slave /usr/share/man/man1/$i.1.gz $i.1.gz /usr/share/man/man1/k$i.1.gz
+done
+
+#DEBHELPER#
+
diff --git a/debian/heimdal-clients.prerm b/debian/heimdal-clients.prerm
new file mode 100644
index 000000000..46957302a
--- /dev/null
+++ b/debian/heimdal-clients.prerm
@@ -0,0 +1,13 @@
+#!/bin/sh -e
+
+if [ "$1" != "upgrade" ]
+then
+    for i in ftp telnet rsh rcp pagsh
+    do
+	update-alternatives --remove $i /usr/bin/k$i
+    done
+fi
+
+#DEBHELPER#
+
+
diff --git a/debian/heimdal-dev.dirs b/debian/heimdal-dev.dirs
new file mode 100644
index 000000000..e43b95cb9
--- /dev/null
+++ b/debian/heimdal-dev.dirs
@@ -0,0 +1 @@
+usr/include
diff --git a/debian/heimdal-dev.install b/debian/heimdal-dev.install
new file mode 100644
index 000000000..d0a3840aa
--- /dev/null
+++ b/debian/heimdal-dev.install
@@ -0,0 +1,4 @@
+usr/bin/krb5-config
+usr/share/man/man1/krb5-config.1
+usr/share/man/man3
+usr/lib/*.la
diff --git a/debian/heimdal-dev.links b/debian/heimdal-dev.links
new file mode 100644
index 000000000..167c608b1
--- /dev/null
+++ b/debian/heimdal-dev.links
@@ -0,0 +1,30 @@
+usr/lib/heimdal/libasn1.a usr/lib/libasn1.a
+usr/lib/heimdal/libasn1.so usr/lib/libasn1.so
+usr/lib/heimdal/libgssapi.a usr/lib/libgssapi.a
+usr/lib/heimdal/libgssapi.so usr/lib/libgssapi.so
+usr/lib/heimdal/libhdb.a usr/lib/libhdb.a
+usr/lib/heimdal/libhdb.so usr/lib/libhdb.so
+usr/lib/heimdal/libheimntlm.a usr/lib/libheimntlm.a
+usr/lib/heimdal/libheimntlm.so usr/lib/libheimntlm.so
+usr/lib/heimdal/libhcrypto.a usr/lib/libhcrypto.a
+usr/lib/heimdal/libhcrypto.so usr/lib/libhcrypto.so
+usr/lib/heimdal/libhx509.a usr/lib/libhx509.a
+usr/lib/heimdal/libhx509.so usr/lib/libhx509.so
+usr/lib/heimdal/libkadm5clnt.a usr/lib/libkadm5clnt.a
+usr/lib/heimdal/libkadm5clnt.so usr/lib/libkadm5clnt.so
+usr/lib/heimdal/libkadm5srv.a usr/lib/libkadm5srv.a
+usr/lib/heimdal/libkadm5srv.so usr/lib/libkadm5srv.so
+usr/lib/heimdal/libkafs.a usr/lib/libkafs.a
+usr/lib/heimdal/libkafs.so usr/lib/libkafs.so
+usr/lib/heimdal/libkdc.a usr/lib/libkdc.a
+usr/lib/heimdal/libkdc.so usr/lib/libkdc.so
+usr/lib/heimdal/libkrb5.a usr/lib/libkrb5.a
+usr/lib/heimdal/libkrb5.so usr/lib/libkrb5.so
+usr/lib/heimdal/libotp.a usr/lib/libotp.a
+usr/lib/heimdal/libotp.so usr/lib/libotp.so
+usr/lib/heimdal/libroken.a usr/lib/libroken.a
+usr/lib/heimdal/libroken.so usr/lib/libroken.so
+usr/lib/heimdal/libsl.a usr/lib/libsl.a
+usr/lib/heimdal/libsl.so usr/lib/libsl.so
+usr/lib/heimdal/libwind.a usr/lib/libwind.a
+usr/lib/heimdal/libwind.so usr/lib/libwind.so
diff --git a/debian/heimdal-docs.install b/debian/heimdal-docs.install
new file mode 100644
index 000000000..3a18bf34f
--- /dev/null
+++ b/debian/heimdal-docs.install
@@ -0,0 +1,2 @@
+usr/share/man/man5/krb5.conf.5
+usr/share/info
diff --git a/debian/heimdal-kcm.init b/debian/heimdal-kcm.init
new file mode 100644
index 000000000..3659a69b6
--- /dev/null
+++ b/debian/heimdal-kcm.init
@@ -0,0 +1,66 @@
+#! /bin/sh
+### BEGIN INIT INFO
+# Provides:          heimdal-kcm
+# Required-Start:    $remote_fs $syslog
+# Required-Stop:     $remote_fs $syslog
+# Default-Start:     2 3 4 5
+# Default-Stop:      0 1 6
+# Short-Description: Start KCM server
+### END INIT INFO
+
+PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+KCM_DAEMON="/usr/sbin/kcm"
+KCM_NAME="kcm"
+KCM_DESC="Heimdal KCM"
+KCM_PARAMS="--detach"
+
+test -f $KCM_DAEMON || exit 0
+
+set -e
+
+case "$1" in
+  start)
+	echo -n "Starting $KCM_DESC: "
+	start-stop-daemon --start --quiet \
+		--pidfile /var/run/$KCM_NAME.pid \
+		--exec $KCM_DAEMON -- $KCM_PARAMS
+	echo "$KCM_NAME."
+	;;
+  stop)
+	echo -n "Stopping $KCM_DESC: "
+	start-stop-daemon --stop --oknodo --quiet \
+		--pidfile /var/run/$KCM_NAME.pid \
+		--exec $KCM_DAEMON -- $KCM_PARAMS
+	echo "$KCM_NAME."
+	;;
+  #reload)
+	#
+	#	If the daemon can reload its config files on the fly
+	#	for example by sending it SIGHUP, do it here.
+	#
+	#	If the daemon responds to changes in its config file
+	#	directly anyway, make this a do-nothing entry.
+	#
+	# echo "Reloading $DESC configuration files."
+	# start-stop-daemon --stop --signal 1 --quiet --pidfile \
+	#	/var/run/$NAME.pid --exec $DAEMON
+  #;;
+  restart|force-reload)
+	#
+	#	If the "reload" option is implemented, move the "force-reload"
+	#	option to the "reload" entry above. If not, "force-reload" is
+	#	just the same as "restart".
+	#
+	/etc/init.d/heimdal-kcm stop
+	sleep 1
+	/etc/init.d/heimdal-kcm start
+	;;
+  *)
+	N=/etc/init.d/$NAME
+	# echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2
+	echo "Usage: $N {start|stop|restart|force-reload}" >&2
+	exit 1
+	;;
+esac
+
+exit 0
diff --git a/debian/heimdal-kcm.install b/debian/heimdal-kcm.install
new file mode 100644
index 000000000..5a04cc258
--- /dev/null
+++ b/debian/heimdal-kcm.install
@@ -0,0 +1,2 @@
+usr/sbin/kcm
+usr/share/man/man8/kcm.8
diff --git a/debian/heimdal-kdc.NEWS b/debian/heimdal-kdc.NEWS
new file mode 100644
index 000000000..8d0aee329
--- /dev/null
+++ b/debian/heimdal-kdc.NEWS
@@ -0,0 +1,12 @@
+heimdal (1.2.dfsg.1-3) unstable; urgency=low
+
+  The default /etc/heimdal-kdc/kdc.conf has changed. Previous versions
+  contained errors with respect to some paths. You may want to merge in changes
+  (or copy) from the default file /usr/share/doc/heimdal-kdc/examples/kdc.conf.
+
+  If you upgraded from an old version, then symlinks should be created
+  automatically for backwards compatibility. However, the log file may appear in
+  the wrong spot.  The default place for the log file, if not correctly
+  specified, is /var/lib/heimdal-kdc/kdc.log and not /var/log/heimdal-kdc.log.
+
+ -- Brian May <bam@snoopy.debian.net>  Mon, 06 Apr 2009 12:17:05 +1000
diff --git a/debian/heimdal-kdc.dirs b/debian/heimdal-kdc.dirs
new file mode 100644
index 000000000..7646c4242
--- /dev/null
+++ b/debian/heimdal-kdc.dirs
@@ -0,0 +1,5 @@
+etc/default
+etc/heimdal-kdc
+etc/ldap/schema
+usr/lib/heimdal-servers
+var/lib/heimdal-kdc
diff --git a/debian/heimdal-kdc.examples b/debian/heimdal-kdc.examples
new file mode 100644
index 000000000..2e6a436d5
--- /dev/null
+++ b/debian/heimdal-kdc.examples
@@ -0,0 +1,2 @@
+debian/extras/kdc.conf
+debian/extras/kadmind.acl
diff --git a/debian/heimdal-kdc.init b/debian/heimdal-kdc.init
new file mode 100644
index 000000000..acd76ff2d
--- /dev/null
+++ b/debian/heimdal-kdc.init
@@ -0,0 +1,124 @@
+#! /bin/sh
+### BEGIN INIT INFO
+# Provides:          heimdal-kdc
+# Required-Start:    $remote_fs $syslog
+# Required-Stop:     $remote_fs $syslog
+# Default-Start:     2 3 4 5
+# Default-Stop:      0 1 6
+# Short-Description: Start KDC server
+### END INIT INFO
+
+PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+KDC_DAEMON=/usr/lib/heimdal-servers/kdc
+KDC_NAME=heimdal-kdc
+KDC_DESC="Heimdal KDC"
+KPASSWDD_DAEMON=/usr/lib/heimdal-servers/kpasswdd
+KPASSWDD_NAME=kpasswdd
+KPASSWDD_DESC="Heimdal password server"
+
+if [ -f "/etc/default/heimdal-kdc" ] ; then
+	. /etc/default/heimdal-kdc
+fi
+
+test -f $KDC_DAEMON || exit 0
+test -f $KPASSWDD_DAEMON || exit 0
+
+# commented out due to bug #574425.
+# set -e
+
+case "$1" in
+  start)
+	if [ "$KDC_ENABLED" = "yes" ];
+	then
+		echo -n "Starting $KDC_DESC: "
+		start-stop-daemon --start --quiet --background \
+			--make-pidfile --pidfile /var/run/$KDC_NAME.pid \
+			--exec $KDC_DAEMON -- $KDC_PARAMS
+		echo "$KDC_NAME."
+	fi
+	if [ "$KPASSWDD_ENABLED" = "yes" ];
+	then
+		echo -n "Starting $KPASSWDD_DESC: "
+		start-stop-daemon --start --quiet --background \
+			--make-pidfile --pidfile /var/run/$KPASSWDD_NAME.pid \
+			--exec $KPASSWDD_DAEMON -- $KPASSWDD_PARAMS
+		echo "$KPASSWDD_NAME."
+	fi
+	if [ "$MASTER_ENABLED" = "yes" ];
+	then
+		echo -n "Starting incremental propagation master: "
+		start-stop-daemon --start --quiet --background \
+			--make-pidfile --pidfile /var/run/ipropd-master.pid \
+			--exec /usr/sbin/ipropd-master -- $MASTER_PARAMS
+		echo "ipropd-master."
+	fi
+	if [ "$SLAVE_ENABLED" = "yes" ];
+	then
+		echo -n "Starting incremental propagation slave: "
+		start-stop-daemon --start --quiet --background \
+			--make-pidfile --pidfile /var/run/ipropd-slave.pid \
+			--exec /usr/sbin/ipropd-slave -- $SLAVE_PARAMS
+		echo "ipropd-slave."
+	fi
+	;;
+  stop)
+	if [ -f /var/run/$KPASSWDD_NAME.pid ]
+	then
+		echo -n "Stopping $KPASSWDD_DESC: "
+		start-stop-daemon --stop --oknodo --quiet --pidfile /var/run/$KPASSWDD_NAME.pid \
+			--exec $KPASSWDD_DAEMON -- $KPASSWDD_PARAMS
+		echo "$KPASSWDD_NAME."
+	fi
+	if [ -f /var/run/$KDC_NAME.pid  ]
+	then
+		echo -n "Stopping $KDC_DESC: "
+		start-stop-daemon --stop --oknodo --quiet --pidfile /var/run/$KDC_NAME.pid \
+			--exec $KDC_DAEMON -- $KDC_PARAMS
+		echo "$KDC_NAME."
+	fi
+	if [ -f /var/run/ipropd-master.pid ]
+	then
+		echo -n "Stopping incremental propagation master: "
+		start-stop-daemon --stop --oknodo --quiet --pidfile /var/run/ipropd-master.pid \
+			--exec /usr/sbin/ipropd-master -- $MASTER_PARAMS
+		echo "ipropd-master."
+	fi
+	if [ -f /var/run/ipropd-slave.pid ]
+	then
+		echo -n "Stopping incremental propagation slave: "
+		start-stop-daemon --stop --oknodo --quiet --pidfile /var/run/ipropd-slave.pid \
+			--exec /usr/sbin/ipropd-slave -- $SLAVE_PARAMS
+		echo "/usr/sbin/ipropd-slave."
+	fi
+	;;
+  #reload)
+	#
+	#	If the daemon can reload its config files on the fly
+	#	for example by sending it SIGHUP, do it here.
+	#
+	#	If the daemon responds to changes in its config file
+	#	directly anyway, make this a do-nothing entry.
+	#
+	# echo "Reloading $DESC configuration files."
+	# start-stop-daemon --stop --signal 1 --quiet --pidfile \
+	#	/var/run/$NAME.pid --exec $DAEMON
+  #;;
+  restart|force-reload)
+	#
+	#	If the "reload" option is implemented, move the "force-reload"
+	#	option to the "reload" entry above. If not, "force-reload" is
+	#	just the same as "restart".
+	#
+	/etc/init.d/heimdal-kdc stop
+	sleep 1
+	/etc/init.d/heimdal-kdc start
+	;;
+  *)
+	N=/etc/init.d/$NAME
+	# echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2
+	echo "Usage: $N {start|stop|restart|force-reload}" >&2
+	exit 1
+	;;
+esac
+
+exit 0
diff --git a/debian/heimdal-kdc.install b/debian/heimdal-kdc.install
new file mode 100644
index 000000000..45c4f9339
--- /dev/null
+++ b/debian/heimdal-kdc.install
@@ -0,0 +1,17 @@
+usr/sbin/kstash
+usr/sbin/hprop
+usr/sbin/hpropd
+usr/sbin/iprop-log
+usr/sbin/ipropd-master
+usr/sbin/ipropd-slave
+usr/sbin/kdc
+usr/sbin/kadmind
+usr/sbin/kpasswdd
+usr/share/man/man8/iprop.8
+usr/share/man/man8/iprop-log.8
+usr/share/man/man8/kdc.8
+usr/share/man/man8/kadmind.8
+usr/share/man/man8/kstash.8
+usr/share/man/man8/kpasswdd.8
+usr/share/man/man8/hprop.8
+usr/share/man/man8/hpropd.8
diff --git a/debian/heimdal-kdc.lintian-overrides b/debian/heimdal-kdc.lintian-overrides
new file mode 100644
index 000000000..32f34ec07
--- /dev/null
+++ b/debian/heimdal-kdc.lintian-overrides
@@ -0,0 +1 @@
+non-standard-dir-perm
diff --git a/debian/heimdal-kdc.logrotate b/debian/heimdal-kdc.logrotate
new file mode 100644
index 000000000..c5fad41b9
--- /dev/null
+++ b/debian/heimdal-kdc.logrotate
@@ -0,0 +1,5 @@
+/var/log/heimdal-kdc.log {
+	rotate 5
+	weekly
+	compress
+}
diff --git a/debian/heimdal-kdc.postinst b/debian/heimdal-kdc.postinst
new file mode 100644
index 000000000..aa365d07d
--- /dev/null
+++ b/debian/heimdal-kdc.postinst
@@ -0,0 +1,118 @@
+#!/bin/sh -e
+
+. /usr/share/debconf/confmodule
+
+if [ ! -f /var/log/heimdal-kdc.log ]
+then
+	touch /var/log/heimdal-kdc.log
+	chmod 600 /var/log/heimdal-kdc.log
+fi
+
+add_servers() {
+kadmin_entry="kerberos-adm	stream	tcp	nowait	root	/usr/sbin/tcpd /usr/lib/heimdal-servers/kadmind"
+hprop_entry="#krb_prop	stream	tcp	nowait	root	/usr/sbin/tcpd /usr/sbin/hpropd"
+
+	update-inetd --group KRB5 --add "$kadmin_entry"
+	update-inetd --group KRB5 --add "$hprop_entry"
+}
+
+enable_servers() {
+	update-inetd --pattern '[ \t]/usr/lib/heimdal-servers/kadmind' --enable kerberos-adm
+}
+
+# if not configured but config exists in wrong place, try moving existing configuration
+if [ ! -f /etc/heimdal-kdc/.configured ] &&
+   [   -f /var/lib/heimdal-kdc/.configured ]
+then
+        for i in kdc.conf kadmind.acl
+        do
+                if [ -f /var/lib/heimdal-kdc/$i ]
+                then
+                        mv /var/lib/heimdal-kdc/$i /etc/heimdal-kdc/$i
+                        ln -s /etc/heimdal-kdc/$i /var/lib/heimdal-kdc/$i
+                fi
+        done
+        mv /var/lib/heimdal-kdc/.configured /etc/heimdal-kdc/.configured
+fi
+
+# Sample kdc.conf was broken in older versions, create symlink to kadmind.acl
+# as a work around
+if [ -n "$2" ] && dpkg --compare-versions "$2" lt 1.2.dfsg.1-3; then
+        # also check to make sure that the symlink to kdc.conf exists - it is
+        # required
+        for i in kdc.conf kadmind.acl
+        do
+                if [ ! -e /var/lib/heimdal-kdc/$i ]
+                then
+                        ln -s /etc/heimdal-kdc/$i /var/lib/heimdal-kdc/$i
+                fi
+        done
+fi
+
+# if already configured - dont reconfigure
+if [ ! -f /etc/heimdal-kdc/.configured ]
+then
+        # get default realm
+        # should use krb5-config setting???
+        if db_get krb5-config/default_realm && [ "x$RET" != "x" ]
+        then
+                default_realm="$RET"
+        else
+                default_realm="`hostname -d | tr a-z A-Z`"
+        fi
+        db_fget heimdal/realm seen
+        if [ "$RET" != "true" ]; then
+                db_set heimdal/realm "$default_realm"
+        fi
+        db_subst heimdal/realm default_realm "$default_realm"
+        db_input medium heimdal/realm || true
+        db_go
+        db_get heimdal/realm; REALM="$RET"
+
+        # get password
+        db_input medium heimdal-kdc/password || true
+        db_go
+        db_get heimdal-kdc/password; PASSWORD="$RET"
+        db_set heimdal-kdc/password ""
+
+        # do stuff
+        DST=/etc/heimdal-kdc/kdc.conf
+        zcat /usr/share/doc/heimdal-kdc/examples/kdc.conf.gz > "$DST"
+        # note this symlink is required as we haven't patched the source
+        if [ ! -e /var/lib/heimdal-kdc/kdc.conf ]
+        then
+                ln -s "$DST" /var/lib/heimdal-kdc/kdc.conf
+        fi
+
+        DST=/etc/heimdal-kdc/kadmind.acl
+        cp -a /usr/share/doc/heimdal-kdc/examples/kadmind.acl "$DST"
+
+        kstash --master-key-fd=0 <<EOF
+$PASSWORD
+EOF
+
+        kadmin  -l init --realm-max-ticket-life=unlimited --realm-max-renewable-life=unlimited "$REALM"
+
+        touch /etc/heimdal-kdc/.configured
+fi
+
+case "$1" in
+abort-upgrade | abort-deconfigure | abort-remove)
+        ;;
+configure)
+        if [ -z "$2" ]
+        then
+                add_servers
+        elif dpkg --compare-versions "$2" le "0.7.2.dfsg.1-6"
+        then
+                enable_servers
+        fi
+        ;;
+*)
+        printf "$0: incorrect arguments: $*\n" >&2
+        exit 1
+        ;;
+esac
+
+db_stop
+#DEBHELPER#
diff --git a/debian/heimdal-kdc.postrm b/debian/heimdal-kdc.postrm
new file mode 100644
index 000000000..640fde5f2
--- /dev/null
+++ b/debian/heimdal-kdc.postrm
@@ -0,0 +1,32 @@
+#!/bin/sh -e
+
+remove_servers() {
+	update-inetd --remove 'kerberos-adm[ \t].*[ \t]/usr/lib/heimdal-servers/kadmind'
+	update-inetd --remove 'krb_prop[ \t].*[ \t]/usr/sbin/hpropd'
+}
+
+case "$1" in
+abort-install | remove | abort-upgrade | upgrade | failed-upgrade | disappear)
+	;;
+purge)
+	# If netbase is not installed, then we don't need to do the remove.
+	if command -v update-inetd >/dev/null 2>&1; then
+		remove_servers
+	fi
+	;;
+*)
+	echo "$0: incorrect arguments: $*" >&2
+	exit 1
+	;;
+esac
+
+if [ "$1" = "purge" ]
+then
+	rm -f /var/log/heimdal-kdc.log*
+	rm -rf /var/lib/heimdal-kdc
+	rm -f /etc/heimdal-kdc/.configured
+	rm -f /etc/heimdal-kdc/kdc.conf
+	rm -f /etc/heimdal-kdc/kadmind.acl
+fi
+
+#DEBHELPER#
diff --git a/debian/heimdal-kdc.templates b/debian/heimdal-kdc.templates
new file mode 100644
index 000000000..e7d840cd7
--- /dev/null
+++ b/debian/heimdal-kdc.templates
@@ -0,0 +1,24 @@
+# These templates have been reviewed by the debian-l10n-english
+# team
+#
+# If modifications/additions/rewording are needed, please ask
+# debian-l10n-english@lists.debian.org for advice.
+#
+# Even minor modifications require translation updates and such
+# changes should be coordinated with translators and reviewers.
+
+Template: heimdal/realm
+Type: string
+_Description: Local realm name:
+ Please enter the name of the local Kerberos realm. 
+ .
+ Using the uppercase domain name is common. For instance, if the host
+ name is host.example.org, then the realm will become EXAMPLE.ORG. The
+ default for this host is ${default_realm}.
+
+Template: heimdal-kdc/password
+Type: password
+_Description: KDC password:
+ Heimdal can encrypt the key distribution center (KDC) data with
+ a password. A hashed representation of this password will be stored
+ in /var/lib/heimdal-kdc/m-key.
diff --git a/debian/heimdal-multidev.install b/debian/heimdal-multidev.install
new file mode 100644
index 000000000..f740803d2
--- /dev/null
+++ b/debian/heimdal-multidev.install
@@ -0,0 +1,3 @@
+usr/lib/*.a usr/lib/heimdal
+usr/lib/*.so usr/lib/heimdal
+usr/include/* usr/include/heimdal
diff --git a/debian/heimdal-servers-x.dirs b/debian/heimdal-servers-x.dirs
new file mode 100644
index 000000000..6209a9dfe
--- /dev/null
+++ b/debian/heimdal-servers-x.dirs
@@ -0,0 +1 @@
+usr/lib/heimdal-servers
diff --git a/debian/heimdal-servers-x.install b/debian/heimdal-servers-x.install
new file mode 100644
index 000000000..250b28b3c
--- /dev/null
+++ b/debian/heimdal-servers-x.install
@@ -0,0 +1,2 @@
+usr/sbin/kxd
+usr/share/man/man8/kxd.8
diff --git a/debian/heimdal-servers-x.postinst b/debian/heimdal-servers-x.postinst
new file mode 100644
index 000000000..bb0ea22fd
--- /dev/null
+++ b/debian/heimdal-servers-x.postinst
@@ -0,0 +1,34 @@
+#!/bin/sh -e
+
+add_servers() {
+    kx_entry="kx	stream	tcp	nowait	root	/usr/sbin/tcpd /usr/lib/heimdal-servers/kxd"
+	update-inetd --group KRB5 --add "$kx_entry"
+}
+
+enable_servers() {
+	update-inetd --pattern '[ \t]/usr/lib/heimdal-servers/kx' --enable kx
+}
+
+remove_servers() {
+	update-inetd --remove 'kx[ \t].*[ \t]/usr/lib/heimdal-servers/kxd'
+}
+
+case "$1" in
+abort-upgrade | abort-deconfigure | abort-remove)
+	enable_servers
+	;;
+configure)
+	if [ -n "$2" ] && dpkg --compare-versions "$2" ge 0.2h-1; then
+		enable_servers
+	else
+		remove_servers
+		add_servers
+	fi
+	;;
+*)
+	printf "$0: incorrect arguments: $*\n" >&2
+	exit 1
+	;;
+esac
+
+#DEBHELPER#
diff --git a/debian/heimdal-servers-x.postrm b/debian/heimdal-servers-x.postrm
new file mode 100644
index 000000000..4bfc21456
--- /dev/null
+++ b/debian/heimdal-servers-x.postrm
@@ -0,0 +1,23 @@
+#!/bin/sh -e
+# $Id: heimdal-servers-x.postrm,v 1.2 1999/12/26 00:00:46 bam Exp $
+
+remove_servers() {
+	update-inetd --remove 'kx[ \t].*[ \t]/usr/lib/heimdal-servers/kxd'
+}
+
+case "$1" in
+abort-install | remove | abort-upgrade | upgrade | failed-upgrade | disappear)
+	;;
+purge)
+	# If netbase is not installed, then we don't need to do the remove.
+	if command -v update-inetd >/dev/null 2>&1; then
+		remove_servers
+	fi
+	;;
+*)
+	echo "$0: incorrect arguments: $*" >&2
+	exit 1
+	;;
+esac
+
+#DEBHELPER#
diff --git a/debian/heimdal-servers-x.prerm b/debian/heimdal-servers-x.prerm
new file mode 100644
index 000000000..646eb898c
--- /dev/null
+++ b/debian/heimdal-servers-x.prerm
@@ -0,0 +1,11 @@
+#!/bin/sh -e
+
+disable_servers() {
+	update-inetd --pattern '[ \t]/usr/lib/heimdal-servers/kx' --disable kx
+}
+
+if command -v update-inetd >/dev/null 2>&1; then
+	disable_servers
+fi
+
+#DEBHELPER#
diff --git a/debian/heimdal-servers.dirs b/debian/heimdal-servers.dirs
new file mode 100644
index 000000000..6209a9dfe
--- /dev/null
+++ b/debian/heimdal-servers.dirs
@@ -0,0 +1 @@
+usr/lib/heimdal-servers
diff --git a/debian/heimdal-servers.install b/debian/heimdal-servers.install
new file mode 100644
index 000000000..f4c7b8e3c
--- /dev/null
+++ b/debian/heimdal-servers.install
@@ -0,0 +1,12 @@
+usr/sbin/kfd
+usr/sbin/ftpd
+usr/sbin/rshd
+usr/sbin/telnetd
+usr/sbin/popper
+usr/bin/login
+usr/share/man/man5/ftpusers.5
+usr/share/man/man8/ftpd.8
+usr/share/man/man8/popper.8
+usr/share/man/man8/telnetd.8
+usr/share/man/man8/kfd.8
+usr/share/man/man8/rshd.8
diff --git a/debian/heimdal-servers.postinst b/debian/heimdal-servers.postinst
new file mode 100644
index 000000000..a1d936081
--- /dev/null
+++ b/debian/heimdal-servers.postinst
@@ -0,0 +1,47 @@
+#!/bin/sh -e
+
+add_servers() {
+kshell_entry="kshell	stream	tcp	nowait	root	/usr/sbin/tcpd /usr/lib/heimdal-servers/rshd -k"
+   ftp_entry="ftp	stream	tcp	nowait	root	/usr/sbin/tcpd /usr/lib/heimdal-servers/ftpd -a plain"
+telnet_entry="telnet	stream	tcp	nowait	root	/usr/sbin/tcpd /usr/lib/heimdal-servers/telnetd -a none"
+ pop3_entry="pop-3	stream	tcp	nowait	root	/usr/sbin/tcpd /usr/lib/heimdal-servers/popper"
+
+	update-inetd --group KRB5 --add "$kshell_entry"
+	update-inetd --group KRB5 --add "$ftp_entry"
+	update-inetd --group KRB5 --add "$telnet_entry"
+	update-inetd --group KRB5 --add "$pop3_entry"
+}
+
+enable_servers() {
+	update-inetd --pattern '[ \t]/usr/lib/heimdal-servers/rshd' --enable kshell
+	update-inetd --pattern '[ \t]/usr/lib/heimdal-servers/ftpd' --enable ftp
+	update-inetd --pattern '[ \t]/usr/lib/heimdal-servers/telnetd' --enable telnet
+	update-inetd --pattern '[ \t]/usr/lib/heimdal-servers/popper' --enable pop-3
+}
+
+remove_servers() {
+	update-inetd --remove 'kshell[ \t].*[ \t]/usr/lib/heimdal-servers/rshd'
+	update-inetd --remove 'ftp[ \t].*[ \t]/usr/lib/heimdal-servers/ftpd'
+	update-inetd --remove 'telnet[ \t].*[ \t]/usr/lib/heimdal-servers/telnetd'
+	update-inetd --remove 'pop-3[ \t].*[ \t]/usr/lib/heimdal-servers/popper'
+}
+
+case "$1" in
+abort-upgrade | abort-deconfigure | abort-remove)
+	enable_servers
+	;;
+configure)
+	if [ -n "$2" ] && dpkg --compare-versions "$2" ge 0.3e-4; then
+		enable_servers
+	else
+		remove_servers
+		add_servers
+	fi
+	;;
+*)
+	printf "$0: incorrect arguments: $*\n" >&2
+	exit 1
+	;;
+esac
+
+#DEBHELPER#
diff --git a/debian/heimdal-servers.postrm b/debian/heimdal-servers.postrm
new file mode 100644
index 000000000..c8aa0f428
--- /dev/null
+++ b/debian/heimdal-servers.postrm
@@ -0,0 +1,26 @@
+#!/bin/sh -e
+# $Id: heimdal-servers.postrm,v 1.4 1999/12/26 01:51:03 bam Exp $
+
+remove_servers() {
+	update-inetd --remove 'kshell[ \t].*[ \t]/usr/lib/heimdal-servers/rshd'
+	update-inetd --remove 'ftp[ \t].*[ \t]/usr/lib/heimdal-servers/ftpd'
+	update-inetd --remove 'telnet[ \t].*[ \t]/usr/lib/heimdal-servers/telnetd'
+	update-inetd --remove 'pop-3[ \t].*[ \t]/usr/lib/heimdal-servers/popper'
+}
+
+case "$1" in
+abort-install | remove | abort-upgrade | upgrade | failed-upgrade | disappear)
+	;;
+purge)
+	# If netbase is not installed, then we don't need to do the remove.
+	if command -v update-inetd >/dev/null 2>&1; then
+		remove_servers
+	fi
+	;;
+*)
+	echo "$0: incorrect arguments: $*" >&2
+	exit 1
+	;;
+esac
+
+#DEBHELPER#
diff --git a/debian/heimdal-servers.prerm b/debian/heimdal-servers.prerm
new file mode 100644
index 000000000..d9789942a
--- /dev/null
+++ b/debian/heimdal-servers.prerm
@@ -0,0 +1,14 @@
+#!/bin/sh -e
+
+disable_servers() {
+	update-inetd --pattern '[ \t]/usr/lib/heimdal-servers/rshd' --disable kshell
+	update-inetd --pattern '[ \t]/usr/lib/heimdal-servers/ftpd' --disable ftp
+	update-inetd --pattern '[ \t]/usr/lib/heimdal-servers/telnetd' --disable telnet
+	update-inetd --pattern '[ \t]/usr/lib/heimdal-servers/popper' --disable pop-3
+}
+
+if command -v update-inetd >/dev/null 2>&1; then
+	disable_servers
+fi
+
+#DEBHELPER#
diff --git a/debian/libasn1-8-heimdal.install b/debian/libasn1-8-heimdal.install
new file mode 100644
index 000000000..a4c26aa34
--- /dev/null
+++ b/debian/libasn1-8-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libasn1.so.8.*
+usr/lib/libasn1.so.8
diff --git a/debian/libasn1-8-heimdal.lintian-overrides b/debian/libasn1-8-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libasn1-8-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libgssapi2-heimdal.install b/debian/libgssapi2-heimdal.install
new file mode 100644
index 000000000..07155297a
--- /dev/null
+++ b/debian/libgssapi2-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libgssapi.so.2.*
+usr/lib/libgssapi.so.2
diff --git a/debian/libgssapi2-heimdal.lintian-overrides b/debian/libgssapi2-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libgssapi2-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libhcrypto4-heimdal.install b/debian/libhcrypto4-heimdal.install
new file mode 100644
index 000000000..de98b4b76
--- /dev/null
+++ b/debian/libhcrypto4-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libhcrypto.so.4.*
+usr/lib/libhcrypto.so.4
diff --git a/debian/libhcrypto4-heimdal.lintian-overrides b/debian/libhcrypto4-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libhcrypto4-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libhdb9-heimdal.install b/debian/libhdb9-heimdal.install
new file mode 100644
index 000000000..17ee8daaf
--- /dev/null
+++ b/debian/libhdb9-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libhdb.so.9.*
+usr/lib/libhdb.so.9
diff --git a/debian/libhdb9-heimdal.lintian-overrides b/debian/libhdb9-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libhdb9-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libheimbase1-heimdal.install b/debian/libheimbase1-heimdal.install
new file mode 100644
index 000000000..dfb7afd23
--- /dev/null
+++ b/debian/libheimbase1-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libheimbase.so.1.*
+usr/lib/libheimbase.so.1
diff --git a/debian/libheimbase1-heimdal.lintian-overrides b/debian/libheimbase1-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libheimbase1-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libheimntlm0-heimdal.install b/debian/libheimntlm0-heimdal.install
new file mode 100644
index 000000000..44b43f676
--- /dev/null
+++ b/debian/libheimntlm0-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libheimntlm.so.0.*
+usr/lib/libheimntlm.so.0
diff --git a/debian/libheimntlm0-heimdal.lintian-overrides b/debian/libheimntlm0-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libheimntlm0-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libhx509-5-heimdal.install b/debian/libhx509-5-heimdal.install
new file mode 100644
index 000000000..e1c1fd9cb
--- /dev/null
+++ b/debian/libhx509-5-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libhx509.so.5.*
+usr/lib/libhx509.so.5
diff --git a/debian/libhx509-5-heimdal.lintian-overrides b/debian/libhx509-5-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libhx509-5-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libkadm5clnt7-heimdal.install b/debian/libkadm5clnt7-heimdal.install
new file mode 100644
index 000000000..1428c50d7
--- /dev/null
+++ b/debian/libkadm5clnt7-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libkadm5clnt.so.7.*
+usr/lib/libkadm5clnt.so.7
diff --git a/debian/libkadm5clnt7-heimdal.lintian-overrides b/debian/libkadm5clnt7-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libkadm5clnt7-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libkadm5srv8-heimdal.install b/debian/libkadm5srv8-heimdal.install
new file mode 100644
index 000000000..cf13be1e5
--- /dev/null
+++ b/debian/libkadm5srv8-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libkadm5srv.so.8.*
+usr/lib/libkadm5srv.so.8
diff --git a/debian/libkadm5srv8-heimdal.lintian-overrides b/debian/libkadm5srv8-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libkadm5srv8-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libkafs0-heimdal.install b/debian/libkafs0-heimdal.install
new file mode 100644
index 000000000..0a2c47960
--- /dev/null
+++ b/debian/libkafs0-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libkafs.so.0.*
+usr/lib/libkafs.so.0
diff --git a/debian/libkafs0-heimdal.lintian-overrides b/debian/libkafs0-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libkafs0-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libkdc2-heimdal.install b/debian/libkdc2-heimdal.install
new file mode 100644
index 000000000..dae55240b
--- /dev/null
+++ b/debian/libkdc2-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libkdc.so.2.*
+usr/lib/libkdc.so.2
diff --git a/debian/libkdc2-heimdal.lintian-overrides b/debian/libkdc2-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libkdc2-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libkrb5-26-heimdal.install b/debian/libkrb5-26-heimdal.install
new file mode 100644
index 000000000..8f791a526
--- /dev/null
+++ b/debian/libkrb5-26-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libkrb5.so.26.*
+usr/lib/libkrb5.so.26
diff --git a/debian/libkrb5-26-heimdal.lintian-overrides b/debian/libkrb5-26-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libkrb5-26-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libotp0-heimdal.install b/debian/libotp0-heimdal.install
new file mode 100644
index 000000000..d2f09f337
--- /dev/null
+++ b/debian/libotp0-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libotp.so.0.*
+usr/lib/libotp.so.0
diff --git a/debian/libotp0-heimdal.lintian-overrides b/debian/libotp0-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libotp0-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libroken18-heimdal.install b/debian/libroken18-heimdal.install
new file mode 100644
index 000000000..c544e71f3
--- /dev/null
+++ b/debian/libroken18-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libroken.so.18.*
+usr/lib/libroken.so.18
diff --git a/debian/libroken18-heimdal.lintian-overrides b/debian/libroken18-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libroken18-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libsl0-heimdal.install b/debian/libsl0-heimdal.install
new file mode 100644
index 000000000..ae611425a
--- /dev/null
+++ b/debian/libsl0-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libsl.so.0.*
+usr/lib/libsl.so.0
diff --git a/debian/libsl0-heimdal.lintian-overrides b/debian/libsl0-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libsl0-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/libwind0-heimdal.install b/debian/libwind0-heimdal.install
new file mode 100644
index 000000000..85488115a
--- /dev/null
+++ b/debian/libwind0-heimdal.install
@@ -0,0 +1,2 @@
+usr/lib/libwind.so.0.*
+usr/lib/libwind.so.0
diff --git a/debian/libwind0-heimdal.lintian-overrides b/debian/libwind0-heimdal.lintian-overrides
new file mode 100644
index 000000000..867597936
--- /dev/null
+++ b/debian/libwind0-heimdal.lintian-overrides
@@ -0,0 +1 @@
+package-name-doesnt-match-sonames
diff --git a/debian/patches/011_sharedlibs b/debian/patches/011_sharedlibs
new file mode 100644
index 000000000..a0a576bb1
--- /dev/null
+++ b/debian/patches/011_sharedlibs
@@ -0,0 +1,16 @@
+=== modified file 'tools/krb5-config.in'
+--- a/tools/krb5-config.in	2010-02-08 00:28:48 +0000
++++ b/tools/krb5-config.in	2010-02-08 00:39:07 +0000
+@@ -135,10 +135,7 @@
+ 	lib_flags="$lib_flags -lkafs"
+ 	;;
+     esac
+-    lib_flags="$lib_flags -lkrb5 @LIB_pkinit@ -lcom_err"
+-    lib_flags="$lib_flags @LIB_hcrypto_appl@ -lasn1 -lwind -lroken"
+-    lib_flags="$lib_flags @LIB_crypt@ @PTHREAD_LIBADD@ @LIB_dlopen@"
+-    lib_flags="$lib_flags @LIB_door_create@ @LIBS@"
++    lib_flags="$lib_flags -lkrb5"
+     echo $lib_flags
+ fi
+ if test "$do_cflags" = "yes"; then
+
diff --git a/debian/patches/020_maintainermode b/debian/patches/020_maintainermode
new file mode 100644
index 000000000..6a76d4ab4
--- /dev/null
+++ b/debian/patches/020_maintainermode
@@ -0,0 +1,12 @@
+Index: heimdal-1.3.1.dfsg.1/configure.ac
+===================================================================
+--- heimdal-1.3.1.dfsg.1.orig/configure.ac	2009-11-22 02:41:51.000000000 +1100
++++ heimdal-1.3.1.dfsg.1/configure.ac	2009-11-24 11:10:18.995671485 +1100
+@@ -3,6 +3,7 @@
+ AC_PREREQ(2.62)
+ test -z "$CFLAGS" && CFLAGS="-g"
+ AC_INIT([Heimdal],[1.4.99],[heimdal-bugs@h5l.org])
++AM_MAINTAINER_MODE
+ AC_CONFIG_SRCDIR([kuser/kinit.c])
+ AC_CONFIG_HEADERS(include/config.h)
+ AC_CONFIG_MACRO_DIR([cf])
diff --git a/debian/patches/021_debian b/debian/patches/021_debian
new file mode 100644
index 000000000..13d3e8235
--- /dev/null
+++ b/debian/patches/021_debian
@@ -0,0 +1,39 @@
+Index: heimdal-1.3.1.dfsg.1/kdc/kdc.8
+===================================================================
+--- heimdal-1.3.1.dfsg.1.orig/kdc/kdc.8	2009-11-22 02:41:51.000000000 +1100
++++ heimdal-1.3.1.dfsg.1/kdc/kdc.8	2009-11-24 11:10:25.099669790 +1100
+@@ -77,7 +77,7 @@
+ .Fl -config-file= Ns Ar file
+ .Xc
+ Specifies the location of the config file, the default is
+-.Pa /var/heimdal/kdc.conf .
++.Pa /etc/heimdal-kdc/kdc.conf .
+ This is the only value that can't be specified in the config file.
+ .It Xo
+ .Fl p ,
+Index: heimdal-1.3.1.dfsg.1/doc/setup.texi
+===================================================================
+--- heimdal-1.3.1.dfsg.1.orig/doc/setup.texi	2009-11-22 02:41:51.000000000 +1100
++++ heimdal-1.3.1.dfsg.1/doc/setup.texi	2009-11-24 11:10:25.111669774 +1100
+@@ -363,7 +363,7 @@
+ as @samp{749/tcp}.
+ 
+ Access to the administration server is controlled by an ACL file,
+-(default @file{/var/heimdal/kadmind.acl}.) The file has the following
++(default @file{/etc/heimdal-kdc/kadmind.acl}.) The file has the following
+ syntax:
+ @smallexample
+ principal       [priv1,priv2,...]       [glob-pattern]
+Index: heimdal-1.3.1.dfsg.1/appl/telnet/telnetd/telnetd.h
+===================================================================
+--- heimdal-1.3.1.dfsg.1.orig/appl/telnet/telnetd/telnetd.h	2009-11-22 02:41:51.000000000 +1100
++++ heimdal-1.3.1.dfsg.1/appl/telnet/telnetd/telnetd.h	2009-11-24 11:10:25.213453707 +1100
+@@ -212,7 +212,7 @@
+ #endif
+ 
+ #undef _PATH_LOGIN
+-#define _PATH_LOGIN	BINDIR "/login"
++#define _PATH_LOGIN	"/bin/login"
+ 
+ /* fallbacks */
+ 
diff --git a/debian/patches/022_openafs b/debian/patches/022_openafs
new file mode 100644
index 000000000..8bd9983c9
--- /dev/null
+++ b/debian/patches/022_openafs
@@ -0,0 +1,15 @@
+Index: heimdal-1.3.1.dfsg.1/lib/krb5/keytab_keyfile.c
+===================================================================
+--- heimdal-1.3.1.dfsg.1.orig/lib/krb5/keytab_keyfile.c	2009-11-22 02:41:51.000000000 +1100
++++ heimdal-1.3.1.dfsg.1/lib/krb5/keytab_keyfile.c	2009-11-24 11:14:30.219670116 +1100
+@@ -48,8 +48,8 @@
+  *
+  */
+ 
+-#define AFS_SERVERTHISCELL "/usr/afs/etc/ThisCell"
+-#define AFS_SERVERMAGICKRBCONF "/usr/afs/etc/krb.conf"
++#define AFS_SERVERTHISCELL "/etc/openafs/ThisCell"
++#define AFS_SERVERMAGICKRBCONF "/etc/openafs/etc/krb.conf"
+ 
+ struct akf_data {
+     uint32_t num_entries;
diff --git a/debian/patches/024_rxtelnet b/debian/patches/024_rxtelnet
new file mode 100644
index 000000000..16afa0048
--- /dev/null
+++ b/debian/patches/024_rxtelnet
@@ -0,0 +1,26 @@
+Index: heimdal-1.3.1.dfsg.1/appl/kx/rxtelnet.in
+===================================================================
+--- heimdal-1.3.1.dfsg.1.orig/appl/kx/rxtelnet.in	2009-11-22 02:41:51.000000000 +1100
++++ heimdal-1.3.1.dfsg.1/appl/kx/rxtelnet.in	2009-11-24 11:14:51.915670587 +1100
+@@ -2,7 +2,7 @@
+ # $Id$
+ #
+ usage="Usage: $0 [-l username] [-k] [-fF] [-t args_to_telnet] [-x args_to_xterm] [-K args_to_kx] [-w term_emulator] [-b telnet_binary] [-n] [-v] [-h | --help] [--version] host [port]"
+-binary=telnet
++binary=ktelnet
+ term=
+ kx_args=-P
+ while true
+Index: heimdal-1.3.1.dfsg.1/appl/kx/rxterm.in
+===================================================================
+--- heimdal-1.3.1.dfsg.1.orig/appl/kx/rxterm.in	2009-11-22 02:41:51.000000000 +1100
++++ heimdal-1.3.1.dfsg.1/appl/kx/rxterm.in	2009-11-24 11:14:51.915670587 +1100
+@@ -2,7 +2,7 @@
+ # $Id$
+ #
+ usage="Usage: $0 [-l username] [-k] [-f] [-r rsh_args] [-x xterm_args] [-K kx_args] [-w term_emulator] [-b rsh_binary][-v] [-h | --help] [--version] host"
+-binary=rsh
++binary=krsh
+ term=xterm
+ while true
+ do
diff --git a/debian/patches/025_pthreads b/debian/patches/025_pthreads
new file mode 100644
index 000000000..88cf998bc
--- /dev/null
+++ b/debian/patches/025_pthreads
@@ -0,0 +1,13 @@
+=== modified file 'cf/pthreads.m4'
+--- a/cf/pthreads.m4	2010-02-08 00:28:48 +0000
++++ b/cf/pthreads.m4	2010-02-08 00:46:50 +0000
+@@ -44,7 +44,7 @@
+ 	2.*)
+ 		native_pthread_support=yes
+ 		PTHREAD_CFLAGS=-pthread
+-		PTHREAD_LIBADD=-pthread
++		PTHREAD_LIBADD="-pthread -lpthread"
+ 		;;
+ 	esac
+ 	;;
+
diff --git a/debian/patches/027_rsh_use_ktelnet b/debian/patches/027_rsh_use_ktelnet
new file mode 100644
index 000000000..c7f99331c
--- /dev/null
+++ b/debian/patches/027_rsh_use_ktelnet
@@ -0,0 +1,37 @@
+Index: heimdal-1.3.1.dfsg.1/appl/rsh/rsh.c
+===================================================================
+--- heimdal-1.3.1.dfsg.1.orig/appl/rsh/rsh.c	2009-11-22 02:41:51.000000000 +1100
++++ heimdal-1.3.1.dfsg.1/appl/rsh/rsh.c	2009-11-24 11:16:22.355669068 +1100
+@@ -958,8 +958,8 @@
+     if (argindex == argc) {
+ 	close (priv_socket1);
+ 	close (priv_socket2);
+-	argv[0] = "rlogin";
+-	execvp ("rlogin", argv);
++	argv[0] = "ktelnet";
++	execvp ("ktelnet", argv);
+ 	err (1, "execvp rlogin");
+     }
+ 
+Index: heimdal-1.3.1.dfsg.1/appl/rsh/rsh.1
+===================================================================
+--- heimdal-1.3.1.dfsg.1.orig/appl/rsh/rsh.1	2009-11-22 02:41:51.000000000 +1100
++++ heimdal-1.3.1.dfsg.1/appl/rsh/rsh.1	2009-11-24 11:16:22.359669263 +1100
+@@ -228,7 +228,7 @@
+ .\".Ar command
+ .\".Nm
+ .\"will just exec
+-.\".Xr rlogin 1
++.\".Xr ktelnet 1
+ .\"with the same arguments.
+ .Sh EXAMPLES
+ Care should be taken when issuing commands containing shell meta
+@@ -256,7 +256,7 @@
+ .El
+ .\".Sh DIAGNOSTICS
+ .Sh SEE ALSO
+-.Xr rlogin 1 ,
++.Xr ktelnet 1 ,
+ .Xr krb_realmofhost 3 ,
+ .Xr krb_sendauth 3 ,
+ .Xr hosts.equiv 5 ,
diff --git a/debian/patches/030_autotools b/debian/patches/030_autotools
new file mode 100644
index 000000000..489c738d2
--- /dev/null
+++ b/debian/patches/030_autotools
@@ -0,0 +1,129916 @@
+Index: git/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/Makefile.in	2010-12-29 04:07:18.308900214 +0100
+@@ -0,0 +1,1096 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = README $(am__configure_deps) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common $(top_srcdir)/configure \
++	ChangeLog NEWS TODO compile config.guess config.sub depcomp \
++	install-sh ltmain.sh missing ylwrap
++subdir = .
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++am__CONFIG_DISTCLEAN_FILES = config.status config.cache config.log \
++ configure.lineno config.status.lineno
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \
++	html-recursive info-recursive install-data-recursive \
++	install-dvi-recursive install-exec-recursive \
++	install-html-recursive install-info-recursive \
++	install-pdf-recursive install-ps-recursive install-recursive \
++	installcheck-recursive installdirs-recursive pdf-recursive \
++	ps-recursive uninstall-recursive
++RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive	\
++  distclean-recursive maintainer-clean-recursive
++AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \
++	$(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS \
++	distdir dist dist-all distcheck
++ETAGS = etags
++CTAGS = ctags
++DIST_SUBDIRS = include base lib kuser kdc admin kadmin kpasswd kcm \
++	appl doc tools tests packages etc po
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++distdir = $(PACKAGE)-$(VERSION)
++top_distdir = $(distdir)
++am__remove_distdir = \
++  { test ! -d "$(distdir)" \
++    || { find "$(distdir)" -type d ! -perm -200 -exec chmod u+w {} ';' \
++         && rm -fr "$(distdir)"; }; }
++am__relativize = \
++  dir0=`pwd`; \
++  sed_first='s,^\([^/]*\)/.*$$,\1,'; \
++  sed_rest='s,^[^/]*/*,,'; \
++  sed_last='s,^.*/\([^/]*\)$$,\1,'; \
++  sed_butlast='s,/*[^/]*$$,,'; \
++  while test -n "$$dir1"; do \
++    first=`echo "$$dir1" | sed -e "$$sed_first"`; \
++    if test "$$first" != "."; then \
++      if test "$$first" = ".."; then \
++        dir2=`echo "$$dir0" | sed -e "$$sed_last"`/"$$dir2"; \
++        dir0=`echo "$$dir0" | sed -e "$$sed_butlast"`; \
++      else \
++        first2=`echo "$$dir2" | sed -e "$$sed_first"`; \
++        if test "$$first2" = "$$first"; then \
++          dir2=`echo "$$dir2" | sed -e "$$sed_rest"`; \
++        else \
++          dir2="../$$dir2"; \
++        fi; \
++        dir0="$$dir0"/"$$first"; \
++      fi; \
++    fi; \
++    dir1=`echo "$$dir1" | sed -e "$$sed_rest"`; \
++  done; \
++  reldir="$$dir2"
++DIST_ARCHIVES = $(distdir).tar.gz
++GZIP_ENV = --best
++distuninstallcheck_listfiles = find . -type f -print
++distcleancheck_listfiles = find . -type f -print
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++@KCM_TRUE@kcm_dir = kcm
++SUBDIRS = include base lib kuser kdc admin kadmin kpasswd $(kcm_dir) \
++	appl doc tools tests packages etc po
++ACLOCAL_AMFLAGS = -I cf
++EXTRA_DIST = \
++	TODO \
++	LICENSE \
++	README \
++	ChangeLog \
++	ChangeLog.1998 \
++	ChangeLog.1999 \
++	ChangeLog.2000 \
++	ChangeLog.2001 \
++	ChangeLog.2002 \
++	ChangeLog.2003 \
++	ChangeLog.2004 \
++	ChangeLog.2005 \
++	ChangeLog.2006 \
++	Makefile.am.common \
++	autogen.sh \
++	krb5.conf \
++	cf/make-proto.pl \
++	cf/install-catman.sh \
++	cf/ChangeLog \
++	cf/c-function.m4 \
++	cf/ChangeLog \
++	cf/have-pragma-weak.m4 \
++	cf/have-types.m4 \
++	cf/krb-func-getcwd-broken.m4 \
++	cf/krb-prog-ranlib.m4 \
++	cf/krb-prog-yacc.m4 \
++	cf/krb-sys-aix.m4 \
++	cf/krb-sys-nextstep.m4 \
++	cf/krb-version.m4 \
++	cf/roken.m4 \
++	cf/valgrind-suppressions \
++	cf/vararray.m4
++
++all: all-recursive
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++am--refresh:
++	@:
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      echo ' cd $(srcdir) && $(AUTOMAKE) --foreign'; \
++	      $(am__cd) $(srcdir) && $(AUTOMAKE) --foreign \
++		&& exit 0; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    echo ' $(SHELL) ./config.status'; \
++	    $(SHELL) ./config.status;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	$(SHELL) ./config.status --recheck
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	$(am__cd) $(srcdir) && $(AUTOCONF)
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	$(am__cd) $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++distclean-libtool:
++	-rm -f libtool config.lt
++
++# This directory's subdirectories are mostly independent; you can cd
++# into them and run `make' without going through this Makefile.
++# To change the values of `make' variables: instead of editing Makefiles,
++# (1) if the variable is set in `config.status', edit `config.status'
++#     (which will cause the Makefiles to be regenerated when you run `make');
++# (2) otherwise, pass the desired values on the `make' command line.
++$(RECURSIVE_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	target=`echo $@ | sed s/-recursive//`; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    dot_seen=yes; \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done; \
++	if test "$$dot_seen" = "no"; then \
++	  $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
++	fi; test -z "$$fail"
++
++$(RECURSIVE_CLEAN_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	case "$@" in \
++	  distclean-* | maintainer-clean-*) list='$(DIST_SUBDIRS)' ;; \
++	  *) list='$(SUBDIRS)' ;; \
++	esac; \
++	rev=''; for subdir in $$list; do \
++	  if test "$$subdir" = "."; then :; else \
++	    rev="$$subdir $$rev"; \
++	  fi; \
++	done; \
++	rev="$$rev ."; \
++	target=`echo $@ | sed s/-recursive//`; \
++	for subdir in $$rev; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done && test -z "$$fail"
++tags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
++	done
++ctags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) ctags); \
++	done
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS: tags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	if ($(ETAGS) --etags-include --version) >/dev/null 2>&1; then \
++	  include_option=--etags-include; \
++	  empty_fix=.; \
++	else \
++	  include_option=--include; \
++	  empty_fix=; \
++	fi; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test ! -f $$subdir/TAGS || \
++	      set "$$@" "$$include_option=$$here/$$subdir/TAGS"; \
++	  fi; \
++	done; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS: ctags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	$(am__remove_distdir)
++	test -d "$(distdir)" || mkdir "$(distdir)"
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test -d "$(distdir)/$$subdir" \
++	    || $(MKDIR_P) "$(distdir)/$$subdir" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    dir1=$$subdir; dir2="$(distdir)/$$subdir"; \
++	    $(am__relativize); \
++	    new_distdir=$$reldir; \
++	    dir1=$$subdir; dir2="$(top_distdir)"; \
++	    $(am__relativize); \
++	    new_top_distdir=$$reldir; \
++	    echo " (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir="$$new_top_distdir" distdir="$$new_distdir" \\"; \
++	    echo "     am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)"; \
++	    ($(am__cd) $$subdir && \
++	      $(MAKE) $(AM_MAKEFLAGS) \
++	        top_distdir="$$new_top_distdir" \
++	        distdir="$$new_distdir" \
++		am__remove_distdir=: \
++		am__skip_length_check=: \
++		am__skip_mode_fix=: \
++	        distdir) \
++	      || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++	-test -n "$(am__skip_mode_fix)" \
++	|| find "$(distdir)" -type d ! -perm -755 \
++		-exec chmod u+rwx,go+rx {} \; -o \
++	  ! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
++	  ! -type d ! -perm -400 -exec chmod a+r {} \; -o \
++	  ! -type d ! -perm -444 -exec $(install_sh) -c -m a+r {} {} \; \
++	|| chmod -R a+r "$(distdir)"
++dist-gzip: distdir
++	tardir=$(distdir) && $(am__tar) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).tar.gz
++	$(am__remove_distdir)
++
++dist-bzip2: distdir
++	tardir=$(distdir) && $(am__tar) | bzip2 -9 -c >$(distdir).tar.bz2
++	$(am__remove_distdir)
++
++dist-lzma: distdir
++	tardir=$(distdir) && $(am__tar) | lzma -9 -c >$(distdir).tar.lzma
++	$(am__remove_distdir)
++
++dist-xz: distdir
++	tardir=$(distdir) && $(am__tar) | xz -c >$(distdir).tar.xz
++	$(am__remove_distdir)
++
++dist-tarZ: distdir
++	tardir=$(distdir) && $(am__tar) | compress -c >$(distdir).tar.Z
++	$(am__remove_distdir)
++
++dist-shar: distdir
++	shar $(distdir) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).shar.gz
++	$(am__remove_distdir)
++
++dist-zip: distdir
++	-rm -f $(distdir).zip
++	zip -rq $(distdir).zip $(distdir)
++	$(am__remove_distdir)
++
++dist dist-all: distdir
++	tardir=$(distdir) && $(am__tar) | GZIP=$(GZIP_ENV) gzip -c >$(distdir).tar.gz
++	$(am__remove_distdir)
++
++# This target untars the dist file and tries a VPATH configuration.  Then
++# it guarantees that the distribution is self-contained by making another
++# tarfile.
++distcheck: dist
++	case '$(DIST_ARCHIVES)' in \
++	*.tar.gz*) \
++	  GZIP=$(GZIP_ENV) gzip -dc $(distdir).tar.gz | $(am__untar) ;;\
++	*.tar.bz2*) \
++	  bzip2 -dc $(distdir).tar.bz2 | $(am__untar) ;;\
++	*.tar.lzma*) \
++	  lzma -dc $(distdir).tar.lzma | $(am__untar) ;;\
++	*.tar.xz*) \
++	  xz -dc $(distdir).tar.xz | $(am__untar) ;;\
++	*.tar.Z*) \
++	  uncompress -c $(distdir).tar.Z | $(am__untar) ;;\
++	*.shar.gz*) \
++	  GZIP=$(GZIP_ENV) gzip -dc $(distdir).shar.gz | unshar ;;\
++	*.zip*) \
++	  unzip $(distdir).zip ;;\
++	esac
++	chmod -R a-w $(distdir); chmod a+w $(distdir)
++	mkdir $(distdir)/_build
++	mkdir $(distdir)/_inst
++	chmod a-w $(distdir)
++	test -d $(distdir)/_build || exit 0; \
++	dc_install_base=`$(am__cd) $(distdir)/_inst && pwd | sed -e 's,^[^:\\/]:[\\/],/,'` \
++	  && dc_destdir="$${TMPDIR-/tmp}/am-dc-$$$$/" \
++	  && am__cwd=`pwd` \
++	  && $(am__cd) $(distdir)/_build \
++	  && ../configure --srcdir=.. --prefix="$$dc_install_base" \
++	    $(DISTCHECK_CONFIGURE_FLAGS) \
++	  && $(MAKE) $(AM_MAKEFLAGS) \
++	  && $(MAKE) $(AM_MAKEFLAGS) dvi \
++	  && $(MAKE) $(AM_MAKEFLAGS) check \
++	  && $(MAKE) $(AM_MAKEFLAGS) install \
++	  && $(MAKE) $(AM_MAKEFLAGS) installcheck \
++	  && $(MAKE) $(AM_MAKEFLAGS) uninstall \
++	  && $(MAKE) $(AM_MAKEFLAGS) distuninstallcheck_dir="$$dc_install_base" \
++	        distuninstallcheck \
++	  && chmod -R a-w "$$dc_install_base" \
++	  && ({ \
++	       (cd ../.. && umask 077 && mkdir "$$dc_destdir") \
++	       && $(MAKE) $(AM_MAKEFLAGS) DESTDIR="$$dc_destdir" install \
++	       && $(MAKE) $(AM_MAKEFLAGS) DESTDIR="$$dc_destdir" uninstall \
++	       && $(MAKE) $(AM_MAKEFLAGS) DESTDIR="$$dc_destdir" \
++	            distuninstallcheck_dir="$$dc_destdir" distuninstallcheck; \
++	      } || { rm -rf "$$dc_destdir"; exit 1; }) \
++	  && rm -rf "$$dc_destdir" \
++	  && $(MAKE) $(AM_MAKEFLAGS) dist \
++	  && rm -rf $(DIST_ARCHIVES) \
++	  && $(MAKE) $(AM_MAKEFLAGS) distcleancheck \
++	  && cd "$$am__cwd" \
++	  || exit 1
++	$(am__remove_distdir)
++	@(echo "$(distdir) archives ready for distribution: "; \
++	  list='$(DIST_ARCHIVES)'; for i in $$list; do echo $$i; done) | \
++	  sed -e 1h -e 1s/./=/g -e 1p -e 1x -e '$$p' -e '$$x'
++distuninstallcheck:
++	@$(am__cd) '$(distuninstallcheck_dir)' \
++	&& test `$(distuninstallcheck_listfiles) | wc -l` -le 1 \
++	   || { echo "ERROR: files left after uninstall:" ; \
++	        if test -n "$(DESTDIR)"; then \
++	          echo "  (check DESTDIR support)"; \
++	        fi ; \
++	        $(distuninstallcheck_listfiles) ; \
++	        exit 1; } >&2
++distcleancheck: distclean
++	@if test '$(srcdir)' = . ; then \
++	  echo "ERROR: distcleancheck can only run from a VPATH build" ; \
++	  exit 1 ; \
++	fi
++	@test `$(distcleancheck_listfiles) | wc -l` -eq 0 \
++	  || { echo "ERROR: files left in build directory after distclean:" ; \
++	       $(distcleancheck_listfiles) ; \
++	       exit 1; } >&2
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-recursive
++all-am: Makefile all-local
++installdirs: installdirs-recursive
++installdirs-am:
++install: install-recursive
++install-exec: install-exec-recursive
++install-data: install-data-recursive
++uninstall: uninstall-recursive
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-recursive
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-recursive
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-recursive
++	-rm -f $(am__CONFIG_DISTCLEAN_FILES)
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic distclean-libtool \
++	distclean-tags
++
++dvi: dvi-recursive
++
++dvi-am:
++
++html: html-recursive
++
++html-am:
++
++info: info-recursive
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-recursive
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-recursive
++
++install-html-am:
++
++install-info: install-info-recursive
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-recursive
++
++install-pdf-am:
++
++install-ps: install-ps-recursive
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-recursive
++	-rm -f $(am__CONFIG_DISTCLEAN_FILES)
++	-rm -rf $(top_srcdir)/autom4te.cache
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-recursive
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-recursive
++
++pdf-am:
++
++ps: ps-recursive
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) check-am \
++	ctags-recursive install-am install-data-am install-exec-am \
++	install-strip tags-recursive uninstall-am
++
++.PHONY: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) CTAGS GTAGS \
++	all all-am all-local am--refresh check check-am check-local \
++	clean clean-generic clean-libtool ctags ctags-recursive dist \
++	dist-all dist-bzip2 dist-gzip dist-hook dist-lzma dist-shar \
++	dist-tarZ dist-xz dist-zip distcheck distclean \
++	distclean-generic distclean-libtool distclean-tags \
++	distcleancheck distdir distuninstallcheck dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	installdirs-am maintainer-clean maintainer-clean-generic \
++	mostlyclean mostlyclean-generic mostlyclean-libtool pdf pdf-am \
++	ps ps-am tags tags-recursive uninstall uninstall-am \
++	uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++print-distdir:
++	@echo $(distdir)
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/aclocal.m4
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/aclocal.m4	2010-12-29 04:06:23.991512219 +0100
+@@ -0,0 +1,1111 @@
++# generated automatically by aclocal 1.11.1 -*- Autoconf -*-
++
++# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
++# 2005, 2006, 2007, 2008, 2009  Free Software Foundation, Inc.
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++m4_ifndef([AC_AUTOCONF_VERSION],
++  [m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
++m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.67],,
++[m4_warning([this file was generated for autoconf 2.67.
++You have another version of autoconf.  It may work, but is not guaranteed to.
++If you have problems, you may need to regenerate the build system entirely.
++To do so, use the procedure documented by the package, typically `autoreconf'.])])
++
++# Copyright (C) 2002, 2003, 2005, 2006, 2007, 2008  Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# AM_AUTOMAKE_VERSION(VERSION)
++# ----------------------------
++# Automake X.Y traces this macro to ensure aclocal.m4 has been
++# generated from the m4 files accompanying Automake X.Y.
++# (This private macro should not be called outside this file.)
++AC_DEFUN([AM_AUTOMAKE_VERSION],
++[am__api_version='1.11'
++dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to
++dnl require some minimum version.  Point them to the right macro.
++m4_if([$1], [1.11.1], [],
++      [AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl
++])
++
++# _AM_AUTOCONF_VERSION(VERSION)
++# -----------------------------
++# aclocal traces this macro to find the Autoconf version.
++# This is a private macro too.  Using m4_define simplifies
++# the logic in aclocal, which can simply ignore this definition.
++m4_define([_AM_AUTOCONF_VERSION], [])
++
++# AM_SET_CURRENT_AUTOMAKE_VERSION
++# -------------------------------
++# Call AM_AUTOMAKE_VERSION and AM_AUTOMAKE_VERSION so they can be traced.
++# This function is AC_REQUIREd by AM_INIT_AUTOMAKE.
++AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
++[AM_AUTOMAKE_VERSION([1.11.1])dnl
++m4_ifndef([AC_AUTOCONF_VERSION],
++  [m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
++_AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))])
++
++# AM_AUX_DIR_EXPAND                                         -*- Autoconf -*-
++
++# Copyright (C) 2001, 2003, 2005  Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# For projects using AC_CONFIG_AUX_DIR([foo]), Autoconf sets
++# $ac_aux_dir to `$srcdir/foo'.  In other projects, it is set to
++# `$srcdir', `$srcdir/..', or `$srcdir/../..'.
++#
++# Of course, Automake must honor this variable whenever it calls a
++# tool from the auxiliary directory.  The problem is that $srcdir (and
++# therefore $ac_aux_dir as well) can be either absolute or relative,
++# depending on how configure is run.  This is pretty annoying, since
++# it makes $ac_aux_dir quite unusable in subdirectories: in the top
++# source directory, any form will work fine, but in subdirectories a
++# relative path needs to be adjusted first.
++#
++# $ac_aux_dir/missing
++#    fails when called from a subdirectory if $ac_aux_dir is relative
++# $top_srcdir/$ac_aux_dir/missing
++#    fails if $ac_aux_dir is absolute,
++#    fails when called from a subdirectory in a VPATH build with
++#          a relative $ac_aux_dir
++#
++# The reason of the latter failure is that $top_srcdir and $ac_aux_dir
++# are both prefixed by $srcdir.  In an in-source build this is usually
++# harmless because $srcdir is `.', but things will broke when you
++# start a VPATH build or use an absolute $srcdir.
++#
++# So we could use something similar to $top_srcdir/$ac_aux_dir/missing,
++# iff we strip the leading $srcdir from $ac_aux_dir.  That would be:
++#   am_aux_dir='\$(top_srcdir)/'`expr "$ac_aux_dir" : "$srcdir//*\(.*\)"`
++# and then we would define $MISSING as
++#   MISSING="\${SHELL} $am_aux_dir/missing"
++# This will work as long as MISSING is not called from configure, because
++# unfortunately $(top_srcdir) has no meaning in configure.
++# However there are other variables, like CC, which are often used in
++# configure, and could therefore not use this "fixed" $ac_aux_dir.
++#
++# Another solution, used here, is to always expand $ac_aux_dir to an
++# absolute PATH.  The drawback is that using absolute paths prevent a
++# configured tree to be moved without reconfiguration.
++
++AC_DEFUN([AM_AUX_DIR_EXPAND],
++[dnl Rely on autoconf to set up CDPATH properly.
++AC_PREREQ([2.50])dnl
++# expand $ac_aux_dir to an absolute path
++am_aux_dir=`cd $ac_aux_dir && pwd`
++])
++
++# AM_CONDITIONAL                                            -*- Autoconf -*-
++
++# Copyright (C) 1997, 2000, 2001, 2003, 2004, 2005, 2006, 2008
++# Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# serial 9
++
++# AM_CONDITIONAL(NAME, SHELL-CONDITION)
++# -------------------------------------
++# Define a conditional.
++AC_DEFUN([AM_CONDITIONAL],
++[AC_PREREQ(2.52)dnl
++ ifelse([$1], [TRUE],  [AC_FATAL([$0: invalid condition: $1])],
++	[$1], [FALSE], [AC_FATAL([$0: invalid condition: $1])])dnl
++AC_SUBST([$1_TRUE])dnl
++AC_SUBST([$1_FALSE])dnl
++_AM_SUBST_NOTMAKE([$1_TRUE])dnl
++_AM_SUBST_NOTMAKE([$1_FALSE])dnl
++m4_define([_AM_COND_VALUE_$1], [$2])dnl
++if $2; then
++  $1_TRUE=
++  $1_FALSE='#'
++else
++  $1_TRUE='#'
++  $1_FALSE=
++fi
++AC_CONFIG_COMMANDS_PRE(
++[if test -z "${$1_TRUE}" && test -z "${$1_FALSE}"; then
++  AC_MSG_ERROR([[conditional "$1" was never defined.
++Usually this means the macro was only invoked conditionally.]])
++fi])])
++
++# Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2009
++# Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# serial 10
++
++# There are a few dirty hacks below to avoid letting `AC_PROG_CC' be
++# written in clear, in which case automake, when reading aclocal.m4,
++# will think it sees a *use*, and therefore will trigger all it's
++# C support machinery.  Also note that it means that autoscan, seeing
++# CC etc. in the Makefile, will ask for an AC_PROG_CC use...
++
++
++# _AM_DEPENDENCIES(NAME)
++# ----------------------
++# See how the compiler implements dependency checking.
++# NAME is "CC", "CXX", "GCJ", or "OBJC".
++# We try a few techniques and use that to set a single cache variable.
++#
++# We don't AC_REQUIRE the corresponding AC_PROG_CC since the latter was
++# modified to invoke _AM_DEPENDENCIES(CC); we would have a circular
++# dependency, and given that the user is not expected to run this macro,
++# just rely on AC_PROG_CC.
++AC_DEFUN([_AM_DEPENDENCIES],
++[AC_REQUIRE([AM_SET_DEPDIR])dnl
++AC_REQUIRE([AM_OUTPUT_DEPENDENCY_COMMANDS])dnl
++AC_REQUIRE([AM_MAKE_INCLUDE])dnl
++AC_REQUIRE([AM_DEP_TRACK])dnl
++
++ifelse([$1], CC,   [depcc="$CC"   am_compiler_list=],
++       [$1], CXX,  [depcc="$CXX"  am_compiler_list=],
++       [$1], OBJC, [depcc="$OBJC" am_compiler_list='gcc3 gcc'],
++       [$1], UPC,  [depcc="$UPC"  am_compiler_list=],
++       [$1], GCJ,  [depcc="$GCJ"  am_compiler_list='gcc3 gcc'],
++                   [depcc="$$1"   am_compiler_list=])
++
++AC_CACHE_CHECK([dependency style of $depcc],
++               [am_cv_$1_dependencies_compiler_type],
++[if test -z "$AMDEP_TRUE" && test -f "$am_depcomp"; then
++  # We make a subdir and do the tests there.  Otherwise we can end up
++  # making bogus files that we don't know about and never remove.  For
++  # instance it was reported that on HP-UX the gcc test will end up
++  # making a dummy file named `D' -- because `-MD' means `put the output
++  # in D'.
++  mkdir conftest.dir
++  # Copy depcomp to subdir because otherwise we won't find it if we're
++  # using a relative directory.
++  cp "$am_depcomp" conftest.dir
++  cd conftest.dir
++  # We will build objects and dependencies in a subdirectory because
++  # it helps to detect inapplicable dependency modes.  For instance
++  # both Tru64's cc and ICC support -MD to output dependencies as a
++  # side effect of compilation, but ICC will put the dependencies in
++  # the current directory while Tru64 will put them in the object
++  # directory.
++  mkdir sub
++
++  am_cv_$1_dependencies_compiler_type=none
++  if test "$am_compiler_list" = ""; then
++     am_compiler_list=`sed -n ['s/^#*\([a-zA-Z0-9]*\))$/\1/p'] < ./depcomp`
++  fi
++  am__universal=false
++  m4_case([$1], [CC],
++    [case " $depcc " in #(
++     *\ -arch\ *\ -arch\ *) am__universal=true ;;
++     esac],
++    [CXX],
++    [case " $depcc " in #(
++     *\ -arch\ *\ -arch\ *) am__universal=true ;;
++     esac])
++
++  for depmode in $am_compiler_list; do
++    # Setup a source with many dependencies, because some compilers
++    # like to wrap large dependency lists on column 80 (with \), and
++    # we should not choose a depcomp mode which is confused by this.
++    #
++    # We need to recreate these files for each test, as the compiler may
++    # overwrite some of them when testing with obscure command lines.
++    # This happens at least with the AIX C compiler.
++    : > sub/conftest.c
++    for i in 1 2 3 4 5 6; do
++      echo '#include "conftst'$i'.h"' >> sub/conftest.c
++      # Using `: > sub/conftst$i.h' creates only sub/conftst1.h with
++      # Solaris 8's {/usr,}/bin/sh.
++      touch sub/conftst$i.h
++    done
++    echo "${am__include} ${am__quote}sub/conftest.Po${am__quote}" > confmf
++
++    # We check with `-c' and `-o' for the sake of the "dashmstdout"
++    # mode.  It turns out that the SunPro C++ compiler does not properly
++    # handle `-M -o', and we need to detect this.  Also, some Intel
++    # versions had trouble with output in subdirs
++    am__obj=sub/conftest.${OBJEXT-o}
++    am__minus_obj="-o $am__obj"
++    case $depmode in
++    gcc)
++      # This depmode causes a compiler race in universal mode.
++      test "$am__universal" = false || continue
++      ;;
++    nosideeffect)
++      # after this tag, mechanisms are not by side-effect, so they'll
++      # only be used when explicitly requested
++      if test "x$enable_dependency_tracking" = xyes; then
++	continue
++      else
++	break
++      fi
++      ;;
++    msvisualcpp | msvcmsys)
++      # This compiler won't grok `-c -o', but also, the minuso test has
++      # not run yet.  These depmodes are late enough in the game, and
++      # so weak that their functioning should not be impacted.
++      am__obj=conftest.${OBJEXT-o}
++      am__minus_obj=
++      ;;
++    none) break ;;
++    esac
++    if depmode=$depmode \
++       source=sub/conftest.c object=$am__obj \
++       depfile=sub/conftest.Po tmpdepfile=sub/conftest.TPo \
++       $SHELL ./depcomp $depcc -c $am__minus_obj sub/conftest.c \
++         >/dev/null 2>conftest.err &&
++       grep sub/conftst1.h sub/conftest.Po > /dev/null 2>&1 &&
++       grep sub/conftst6.h sub/conftest.Po > /dev/null 2>&1 &&
++       grep $am__obj sub/conftest.Po > /dev/null 2>&1 &&
++       ${MAKE-make} -s -f confmf > /dev/null 2>&1; then
++      # icc doesn't choke on unknown options, it will just issue warnings
++      # or remarks (even with -Werror).  So we grep stderr for any message
++      # that says an option was ignored or not supported.
++      # When given -MP, icc 7.0 and 7.1 complain thusly:
++      #   icc: Command line warning: ignoring option '-M'; no argument required
++      # The diagnosis changed in icc 8.0:
++      #   icc: Command line remark: option '-MP' not supported
++      if (grep 'ignoring option' conftest.err ||
++          grep 'not supported' conftest.err) >/dev/null 2>&1; then :; else
++        am_cv_$1_dependencies_compiler_type=$depmode
++        break
++      fi
++    fi
++  done
++
++  cd ..
++  rm -rf conftest.dir
++else
++  am_cv_$1_dependencies_compiler_type=none
++fi
++])
++AC_SUBST([$1DEPMODE], [depmode=$am_cv_$1_dependencies_compiler_type])
++AM_CONDITIONAL([am__fastdep$1], [
++  test "x$enable_dependency_tracking" != xno \
++  && test "$am_cv_$1_dependencies_compiler_type" = gcc3])
++])
++
++
++# AM_SET_DEPDIR
++# -------------
++# Choose a directory name for dependency files.
++# This macro is AC_REQUIREd in _AM_DEPENDENCIES
++AC_DEFUN([AM_SET_DEPDIR],
++[AC_REQUIRE([AM_SET_LEADING_DOT])dnl
++AC_SUBST([DEPDIR], ["${am__leading_dot}deps"])dnl
++])
++
++
++# AM_DEP_TRACK
++# ------------
++AC_DEFUN([AM_DEP_TRACK],
++[AC_ARG_ENABLE(dependency-tracking,
++[  --disable-dependency-tracking  speeds up one-time build
++  --enable-dependency-tracking   do not reject slow dependency extractors])
++if test "x$enable_dependency_tracking" != xno; then
++  am_depcomp="$ac_aux_dir/depcomp"
++  AMDEPBACKSLASH='\'
++fi
++AM_CONDITIONAL([AMDEP], [test "x$enable_dependency_tracking" != xno])
++AC_SUBST([AMDEPBACKSLASH])dnl
++_AM_SUBST_NOTMAKE([AMDEPBACKSLASH])dnl
++])
++
++# Generate code to set up dependency tracking.              -*- Autoconf -*-
++
++# Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2008
++# Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++#serial 5
++
++# _AM_OUTPUT_DEPENDENCY_COMMANDS
++# ------------------------------
++AC_DEFUN([_AM_OUTPUT_DEPENDENCY_COMMANDS],
++[{
++  # Autoconf 2.62 quotes --file arguments for eval, but not when files
++  # are listed without --file.  Let's play safe and only enable the eval
++  # if we detect the quoting.
++  case $CONFIG_FILES in
++  *\'*) eval set x "$CONFIG_FILES" ;;
++  *)   set x $CONFIG_FILES ;;
++  esac
++  shift
++  for mf
++  do
++    # Strip MF so we end up with the name of the file.
++    mf=`echo "$mf" | sed -e 's/:.*$//'`
++    # Check whether this is an Automake generated Makefile or not.
++    # We used to match only the files named `Makefile.in', but
++    # some people rename them; so instead we look at the file content.
++    # Grep'ing the first line is not enough: some people post-process
++    # each Makefile.in and add a new line on top of each file to say so.
++    # Grep'ing the whole file is not good either: AIX grep has a line
++    # limit of 2048, but all sed's we know have understand at least 4000.
++    if sed -n 's,^#.*generated by automake.*,X,p' "$mf" | grep X >/dev/null 2>&1; then
++      dirpart=`AS_DIRNAME("$mf")`
++    else
++      continue
++    fi
++    # Extract the definition of DEPDIR, am__include, and am__quote
++    # from the Makefile without running `make'.
++    DEPDIR=`sed -n 's/^DEPDIR = //p' < "$mf"`
++    test -z "$DEPDIR" && continue
++    am__include=`sed -n 's/^am__include = //p' < "$mf"`
++    test -z "am__include" && continue
++    am__quote=`sed -n 's/^am__quote = //p' < "$mf"`
++    # When using ansi2knr, U may be empty or an underscore; expand it
++    U=`sed -n 's/^U = //p' < "$mf"`
++    # Find all dependency output files, they are included files with
++    # $(DEPDIR) in their names.  We invoke sed twice because it is the
++    # simplest approach to changing $(DEPDIR) to its actual value in the
++    # expansion.
++    for file in `sed -n "
++      s/^$am__include $am__quote\(.*(DEPDIR).*\)$am__quote"'$/\1/p' <"$mf" | \
++	 sed -e 's/\$(DEPDIR)/'"$DEPDIR"'/g' -e 's/\$U/'"$U"'/g'`; do
++      # Make sure the directory exists.
++      test -f "$dirpart/$file" && continue
++      fdir=`AS_DIRNAME(["$file"])`
++      AS_MKDIR_P([$dirpart/$fdir])
++      # echo "creating $dirpart/$file"
++      echo '# dummy' > "$dirpart/$file"
++    done
++  done
++}
++])# _AM_OUTPUT_DEPENDENCY_COMMANDS
++
++
++# AM_OUTPUT_DEPENDENCY_COMMANDS
++# -----------------------------
++# This macro should only be invoked once -- use via AC_REQUIRE.
++#
++# This code is only required when automatic dependency tracking
++# is enabled.  FIXME.  This creates each `.P' file that we will
++# need in order to bootstrap the dependency handling code.
++AC_DEFUN([AM_OUTPUT_DEPENDENCY_COMMANDS],
++[AC_CONFIG_COMMANDS([depfiles],
++     [test x"$AMDEP_TRUE" != x"" || _AM_OUTPUT_DEPENDENCY_COMMANDS],
++     [AMDEP_TRUE="$AMDEP_TRUE" ac_aux_dir="$ac_aux_dir"])
++])
++
++# Do all the work for Automake.                             -*- Autoconf -*-
++
++# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
++# 2005, 2006, 2008, 2009 Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# serial 16
++
++# This macro actually does too much.  Some checks are only needed if
++# your package does certain things.  But this isn't really a big deal.
++
++# AM_INIT_AUTOMAKE(PACKAGE, VERSION, [NO-DEFINE])
++# AM_INIT_AUTOMAKE([OPTIONS])
++# -----------------------------------------------
++# The call with PACKAGE and VERSION arguments is the old style
++# call (pre autoconf-2.50), which is being phased out.  PACKAGE
++# and VERSION should now be passed to AC_INIT and removed from
++# the call to AM_INIT_AUTOMAKE.
++# We support both call styles for the transition.  After
++# the next Automake release, Autoconf can make the AC_INIT
++# arguments mandatory, and then we can depend on a new Autoconf
++# release and drop the old call support.
++AC_DEFUN([AM_INIT_AUTOMAKE],
++[AC_PREREQ([2.62])dnl
++dnl Autoconf wants to disallow AM_ names.  We explicitly allow
++dnl the ones we care about.
++m4_pattern_allow([^AM_[A-Z]+FLAGS$])dnl
++AC_REQUIRE([AM_SET_CURRENT_AUTOMAKE_VERSION])dnl
++AC_REQUIRE([AC_PROG_INSTALL])dnl
++if test "`cd $srcdir && pwd`" != "`pwd`"; then
++  # Use -I$(srcdir) only when $(srcdir) != ., so that make's output
++  # is not polluted with repeated "-I."
++  AC_SUBST([am__isrc], [' -I$(srcdir)'])_AM_SUBST_NOTMAKE([am__isrc])dnl
++  # test to see if srcdir already configured
++  if test -f $srcdir/config.status; then
++    AC_MSG_ERROR([source directory already configured; run "make distclean" there first])
++  fi
++fi
++
++# test whether we have cygpath
++if test -z "$CYGPATH_W"; then
++  if (cygpath --version) >/dev/null 2>/dev/null; then
++    CYGPATH_W='cygpath -w'
++  else
++    CYGPATH_W=echo
++  fi
++fi
++AC_SUBST([CYGPATH_W])
++
++# Define the identity of the package.
++dnl Distinguish between old-style and new-style calls.
++m4_ifval([$2],
++[m4_ifval([$3], [_AM_SET_OPTION([no-define])])dnl
++ AC_SUBST([PACKAGE], [$1])dnl
++ AC_SUBST([VERSION], [$2])],
++[_AM_SET_OPTIONS([$1])dnl
++dnl Diagnose old-style AC_INIT with new-style AM_AUTOMAKE_INIT.
++m4_if(m4_ifdef([AC_PACKAGE_NAME], 1)m4_ifdef([AC_PACKAGE_VERSION], 1), 11,,
++  [m4_fatal([AC_INIT should be called with package and version arguments])])dnl
++ AC_SUBST([PACKAGE], ['AC_PACKAGE_TARNAME'])dnl
++ AC_SUBST([VERSION], ['AC_PACKAGE_VERSION'])])dnl
++
++_AM_IF_OPTION([no-define],,
++[AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE", [Name of package])
++ AC_DEFINE_UNQUOTED(VERSION, "$VERSION", [Version number of package])])dnl
++
++# Some tools Automake needs.
++AC_REQUIRE([AM_SANITY_CHECK])dnl
++AC_REQUIRE([AC_ARG_PROGRAM])dnl
++AM_MISSING_PROG(ACLOCAL, aclocal-${am__api_version})
++AM_MISSING_PROG(AUTOCONF, autoconf)
++AM_MISSING_PROG(AUTOMAKE, automake-${am__api_version})
++AM_MISSING_PROG(AUTOHEADER, autoheader)
++AM_MISSING_PROG(MAKEINFO, makeinfo)
++AC_REQUIRE([AM_PROG_INSTALL_SH])dnl
++AC_REQUIRE([AM_PROG_INSTALL_STRIP])dnl
++AC_REQUIRE([AM_PROG_MKDIR_P])dnl
++# We need awk for the "check" target.  The system "awk" is bad on
++# some platforms.
++AC_REQUIRE([AC_PROG_AWK])dnl
++AC_REQUIRE([AC_PROG_MAKE_SET])dnl
++AC_REQUIRE([AM_SET_LEADING_DOT])dnl
++_AM_IF_OPTION([tar-ustar], [_AM_PROG_TAR([ustar])],
++	      [_AM_IF_OPTION([tar-pax], [_AM_PROG_TAR([pax])],
++			     [_AM_PROG_TAR([v7])])])
++_AM_IF_OPTION([no-dependencies],,
++[AC_PROVIDE_IFELSE([AC_PROG_CC],
++		  [_AM_DEPENDENCIES(CC)],
++		  [define([AC_PROG_CC],
++			  defn([AC_PROG_CC])[_AM_DEPENDENCIES(CC)])])dnl
++AC_PROVIDE_IFELSE([AC_PROG_CXX],
++		  [_AM_DEPENDENCIES(CXX)],
++		  [define([AC_PROG_CXX],
++			  defn([AC_PROG_CXX])[_AM_DEPENDENCIES(CXX)])])dnl
++AC_PROVIDE_IFELSE([AC_PROG_OBJC],
++		  [_AM_DEPENDENCIES(OBJC)],
++		  [define([AC_PROG_OBJC],
++			  defn([AC_PROG_OBJC])[_AM_DEPENDENCIES(OBJC)])])dnl
++])
++_AM_IF_OPTION([silent-rules], [AC_REQUIRE([AM_SILENT_RULES])])dnl
++dnl The `parallel-tests' driver may need to know about EXEEXT, so add the
++dnl `am__EXEEXT' conditional if _AM_COMPILER_EXEEXT was seen.  This macro
++dnl is hooked onto _AC_COMPILER_EXEEXT early, see below.
++AC_CONFIG_COMMANDS_PRE(dnl
++[m4_provide_if([_AM_COMPILER_EXEEXT],
++  [AM_CONDITIONAL([am__EXEEXT], [test -n "$EXEEXT"])])])dnl
++])
++
++dnl Hook into `_AC_COMPILER_EXEEXT' early to learn its expansion.  Do not
++dnl add the conditional right here, as _AC_COMPILER_EXEEXT may be further
++dnl mangled by Autoconf and run in a shell conditional statement.
++m4_define([_AC_COMPILER_EXEEXT],
++m4_defn([_AC_COMPILER_EXEEXT])[m4_provide([_AM_COMPILER_EXEEXT])])
++
++
++# When config.status generates a header, we must update the stamp-h file.
++# This file resides in the same directory as the config header
++# that is generated.  The stamp files are numbered to have different names.
++
++# Autoconf calls _AC_AM_CONFIG_HEADER_HOOK (when defined) in the
++# loop where config.status creates the headers, so we can generate
++# our stamp files there.
++AC_DEFUN([_AC_AM_CONFIG_HEADER_HOOK],
++[# Compute $1's index in $config_headers.
++_am_arg=$1
++_am_stamp_count=1
++for _am_header in $config_headers :; do
++  case $_am_header in
++    $_am_arg | $_am_arg:* )
++      break ;;
++    * )
++      _am_stamp_count=`expr $_am_stamp_count + 1` ;;
++  esac
++done
++echo "timestamp for $_am_arg" >`AS_DIRNAME(["$_am_arg"])`/stamp-h[]$_am_stamp_count])
++
++# Copyright (C) 2001, 2003, 2005, 2008  Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# AM_PROG_INSTALL_SH
++# ------------------
++# Define $install_sh.
++AC_DEFUN([AM_PROG_INSTALL_SH],
++[AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
++if test x"${install_sh}" != xset; then
++  case $am_aux_dir in
++  *\ * | *\	*)
++    install_sh="\${SHELL} '$am_aux_dir/install-sh'" ;;
++  *)
++    install_sh="\${SHELL} $am_aux_dir/install-sh"
++  esac
++fi
++AC_SUBST(install_sh)])
++
++# Copyright (C) 2003, 2005  Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# serial 2
++
++# Check whether the underlying file-system supports filenames
++# with a leading dot.  For instance MS-DOS doesn't.
++AC_DEFUN([AM_SET_LEADING_DOT],
++[rm -rf .tst 2>/dev/null
++mkdir .tst 2>/dev/null
++if test -d .tst; then
++  am__leading_dot=.
++else
++  am__leading_dot=_
++fi
++rmdir .tst 2>/dev/null
++AC_SUBST([am__leading_dot])])
++
++# Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2005
++# Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# serial 5
++
++# AM_PROG_LEX
++# -----------
++# Autoconf leaves LEX=: if lex or flex can't be found.  Change that to a
++# "missing" invocation, for better error output.
++AC_DEFUN([AM_PROG_LEX],
++[AC_PREREQ(2.50)dnl
++AC_REQUIRE([AM_MISSING_HAS_RUN])dnl
++AC_REQUIRE([AC_PROG_LEX])dnl
++if test "$LEX" = :; then
++  LEX=${am_missing_run}flex
++fi])
++
++# Add --enable-maintainer-mode option to configure.         -*- Autoconf -*-
++# From Jim Meyering
++
++# Copyright (C) 1996, 1998, 2000, 2001, 2002, 2003, 2004, 2005, 2008
++# Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# serial 5
++
++# AM_MAINTAINER_MODE([DEFAULT-MODE])
++# ----------------------------------
++# Control maintainer-specific portions of Makefiles.
++# Default is to disable them, unless `enable' is passed literally.
++# For symmetry, `disable' may be passed as well.  Anyway, the user
++# can override the default with the --enable/--disable switch.
++AC_DEFUN([AM_MAINTAINER_MODE],
++[m4_case(m4_default([$1], [disable]),
++       [enable], [m4_define([am_maintainer_other], [disable])],
++       [disable], [m4_define([am_maintainer_other], [enable])],
++       [m4_define([am_maintainer_other], [enable])
++        m4_warn([syntax], [unexpected argument to AM@&t@_MAINTAINER_MODE: $1])])
++AC_MSG_CHECKING([whether to am_maintainer_other maintainer-specific portions of Makefiles])
++  dnl maintainer-mode's default is 'disable' unless 'enable' is passed
++  AC_ARG_ENABLE([maintainer-mode],
++[  --][am_maintainer_other][-maintainer-mode  am_maintainer_other make rules and dependencies not useful
++			  (and sometimes confusing) to the casual installer],
++      [USE_MAINTAINER_MODE=$enableval],
++      [USE_MAINTAINER_MODE=]m4_if(am_maintainer_other, [enable], [no], [yes]))
++  AC_MSG_RESULT([$USE_MAINTAINER_MODE])
++  AM_CONDITIONAL([MAINTAINER_MODE], [test $USE_MAINTAINER_MODE = yes])
++  MAINT=$MAINTAINER_MODE_TRUE
++  AC_SUBST([MAINT])dnl
++]
++)
++
++AU_DEFUN([jm_MAINTAINER_MODE], [AM_MAINTAINER_MODE])
++
++# Check to see how 'make' treats includes.	            -*- Autoconf -*-
++
++# Copyright (C) 2001, 2002, 2003, 2005, 2009  Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# serial 4
++
++# AM_MAKE_INCLUDE()
++# -----------------
++# Check to see how make treats includes.
++AC_DEFUN([AM_MAKE_INCLUDE],
++[am_make=${MAKE-make}
++cat > confinc << 'END'
++am__doit:
++	@echo this is the am__doit target
++.PHONY: am__doit
++END
++# If we don't find an include directive, just comment out the code.
++AC_MSG_CHECKING([for style of include used by $am_make])
++am__include="#"
++am__quote=
++_am_result=none
++# First try GNU make style include.
++echo "include confinc" > confmf
++# Ignore all kinds of additional output from `make'.
++case `$am_make -s -f confmf 2> /dev/null` in #(
++*the\ am__doit\ target*)
++  am__include=include
++  am__quote=
++  _am_result=GNU
++  ;;
++esac
++# Now try BSD make style include.
++if test "$am__include" = "#"; then
++   echo '.include "confinc"' > confmf
++   case `$am_make -s -f confmf 2> /dev/null` in #(
++   *the\ am__doit\ target*)
++     am__include=.include
++     am__quote="\""
++     _am_result=BSD
++     ;;
++   esac
++fi
++AC_SUBST([am__include])
++AC_SUBST([am__quote])
++AC_MSG_RESULT([$_am_result])
++rm -f confinc confmf
++])
++
++# Copyright (C) 1999, 2000, 2001, 2003, 2004, 2005, 2008
++# Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# serial 6
++
++# AM_PROG_CC_C_O
++# --------------
++# Like AC_PROG_CC_C_O, but changed for automake.
++AC_DEFUN([AM_PROG_CC_C_O],
++[AC_REQUIRE([AC_PROG_CC_C_O])dnl
++AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
++AC_REQUIRE_AUX_FILE([compile])dnl
++# FIXME: we rely on the cache variable name because
++# there is no other way.
++set dummy $CC
++am_cc=`echo $[2] | sed ['s/[^a-zA-Z0-9_]/_/g;s/^[0-9]/_/']`
++eval am_t=\$ac_cv_prog_cc_${am_cc}_c_o
++if test "$am_t" != yes; then
++   # Losing compiler, so override with the script.
++   # FIXME: It is wrong to rewrite CC.
++   # But if we don't then we get into trouble of one sort or another.
++   # A longer-term fix would be to have automake use am__CC in this case,
++   # and then we could set am__CC="\$(top_srcdir)/compile \$(CC)"
++   CC="$am_aux_dir/compile $CC"
++fi
++dnl Make sure AC_PROG_CC is never called again, or it will override our
++dnl setting of CC.
++m4_define([AC_PROG_CC],
++          [m4_fatal([AC_PROG_CC cannot be called after AM_PROG_CC_C_O])])
++])
++
++# Fake the existence of programs that GNU maintainers use.  -*- Autoconf -*-
++
++# Copyright (C) 1997, 1999, 2000, 2001, 2003, 2004, 2005, 2008
++# Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# serial 6
++
++# AM_MISSING_PROG(NAME, PROGRAM)
++# ------------------------------
++AC_DEFUN([AM_MISSING_PROG],
++[AC_REQUIRE([AM_MISSING_HAS_RUN])
++$1=${$1-"${am_missing_run}$2"}
++AC_SUBST($1)])
++
++
++# AM_MISSING_HAS_RUN
++# ------------------
++# Define MISSING if not defined so far and test if it supports --run.
++# If it does, set am_missing_run to use it, otherwise, to nothing.
++AC_DEFUN([AM_MISSING_HAS_RUN],
++[AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
++AC_REQUIRE_AUX_FILE([missing])dnl
++if test x"${MISSING+set}" != xset; then
++  case $am_aux_dir in
++  *\ * | *\	*)
++    MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
++  *)
++    MISSING="\${SHELL} $am_aux_dir/missing" ;;
++  esac
++fi
++# Use eval to expand $SHELL
++if eval "$MISSING --run true"; then
++  am_missing_run="$MISSING --run "
++else
++  am_missing_run=
++  AC_MSG_WARN([`missing' script is too old or missing])
++fi
++])
++
++# Copyright (C) 2003, 2004, 2005, 2006  Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# AM_PROG_MKDIR_P
++# ---------------
++# Check for `mkdir -p'.
++AC_DEFUN([AM_PROG_MKDIR_P],
++[AC_PREREQ([2.60])dnl
++AC_REQUIRE([AC_PROG_MKDIR_P])dnl
++dnl Automake 1.8 to 1.9.6 used to define mkdir_p.  We now use MKDIR_P,
++dnl while keeping a definition of mkdir_p for backward compatibility.
++dnl @MKDIR_P@ is magic: AC_OUTPUT adjusts its value for each Makefile.
++dnl However we cannot define mkdir_p as $(MKDIR_P) for the sake of
++dnl Makefile.ins that do not define MKDIR_P, so we do our own
++dnl adjustment using top_builddir (which is defined more often than
++dnl MKDIR_P).
++AC_SUBST([mkdir_p], ["$MKDIR_P"])dnl
++case $mkdir_p in
++  [[\\/$]]* | ?:[[\\/]]*) ;;
++  */*) mkdir_p="\$(top_builddir)/$mkdir_p" ;;
++esac
++])
++
++# Helper functions for option handling.                     -*- Autoconf -*-
++
++# Copyright (C) 2001, 2002, 2003, 2005, 2008  Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# serial 4
++
++# _AM_MANGLE_OPTION(NAME)
++# -----------------------
++AC_DEFUN([_AM_MANGLE_OPTION],
++[[_AM_OPTION_]m4_bpatsubst($1, [[^a-zA-Z0-9_]], [_])])
++
++# _AM_SET_OPTION(NAME)
++# ------------------------------
++# Set option NAME.  Presently that only means defining a flag for this option.
++AC_DEFUN([_AM_SET_OPTION],
++[m4_define(_AM_MANGLE_OPTION([$1]), 1)])
++
++# _AM_SET_OPTIONS(OPTIONS)
++# ----------------------------------
++# OPTIONS is a space-separated list of Automake options.
++AC_DEFUN([_AM_SET_OPTIONS],
++[m4_foreach_w([_AM_Option], [$1], [_AM_SET_OPTION(_AM_Option)])])
++
++# _AM_IF_OPTION(OPTION, IF-SET, [IF-NOT-SET])
++# -------------------------------------------
++# Execute IF-SET if OPTION is set, IF-NOT-SET otherwise.
++AC_DEFUN([_AM_IF_OPTION],
++[m4_ifset(_AM_MANGLE_OPTION([$1]), [$2], [$3])])
++
++# Check to make sure that the build environment is sane.    -*- Autoconf -*-
++
++# Copyright (C) 1996, 1997, 2000, 2001, 2003, 2005, 2008
++# Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# serial 5
++
++# AM_SANITY_CHECK
++# ---------------
++AC_DEFUN([AM_SANITY_CHECK],
++[AC_MSG_CHECKING([whether build environment is sane])
++# Just in case
++sleep 1
++echo timestamp > conftest.file
++# Reject unsafe characters in $srcdir or the absolute working directory
++# name.  Accept space and tab only in the latter.
++am_lf='
++'
++case `pwd` in
++  *[[\\\"\#\$\&\'\`$am_lf]]*)
++    AC_MSG_ERROR([unsafe absolute working directory name]);;
++esac
++case $srcdir in
++  *[[\\\"\#\$\&\'\`$am_lf\ \	]]*)
++    AC_MSG_ERROR([unsafe srcdir value: `$srcdir']);;
++esac
++
++# Do `set' in a subshell so we don't clobber the current shell's
++# arguments.  Must try -L first in case configure is actually a
++# symlink; some systems play weird games with the mod time of symlinks
++# (eg FreeBSD returns the mod time of the symlink's containing
++# directory).
++if (
++   set X `ls -Lt "$srcdir/configure" conftest.file 2> /dev/null`
++   if test "$[*]" = "X"; then
++      # -L didn't work.
++      set X `ls -t "$srcdir/configure" conftest.file`
++   fi
++   rm -f conftest.file
++   if test "$[*]" != "X $srcdir/configure conftest.file" \
++      && test "$[*]" != "X conftest.file $srcdir/configure"; then
++
++      # If neither matched, then we have a broken ls.  This can happen
++      # if, for instance, CONFIG_SHELL is bash and it inherits a
++      # broken ls alias from the environment.  This has actually
++      # happened.  Such a system could not be considered "sane".
++      AC_MSG_ERROR([ls -t appears to fail.  Make sure there is not a broken
++alias in your environment])
++   fi
++
++   test "$[2]" = conftest.file
++   )
++then
++   # Ok.
++   :
++else
++   AC_MSG_ERROR([newly created file is older than distributed files!
++Check your system clock])
++fi
++AC_MSG_RESULT(yes)])
++
++# Copyright (C) 2001, 2003, 2005  Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# AM_PROG_INSTALL_STRIP
++# ---------------------
++# One issue with vendor `install' (even GNU) is that you can't
++# specify the program used to strip binaries.  This is especially
++# annoying in cross-compiling environments, where the build's strip
++# is unlikely to handle the host's binaries.
++# Fortunately install-sh will honor a STRIPPROG variable, so we
++# always use install-sh in `make install-strip', and initialize
++# STRIPPROG with the value of the STRIP variable (set by the user).
++AC_DEFUN([AM_PROG_INSTALL_STRIP],
++[AC_REQUIRE([AM_PROG_INSTALL_SH])dnl
++# Installed binaries are usually stripped using `strip' when the user
++# run `make install-strip'.  However `strip' might not be the right
++# tool to use in cross-compilation environments, therefore Automake
++# will honor the `STRIP' environment variable to overrule this program.
++dnl Don't test for $cross_compiling = yes, because it might be `maybe'.
++if test "$cross_compiling" != no; then
++  AC_CHECK_TOOL([STRIP], [strip], :)
++fi
++INSTALL_STRIP_PROGRAM="\$(install_sh) -c -s"
++AC_SUBST([INSTALL_STRIP_PROGRAM])])
++
++# Copyright (C) 2006, 2008  Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# serial 2
++
++# _AM_SUBST_NOTMAKE(VARIABLE)
++# ---------------------------
++# Prevent Automake from outputting VARIABLE = @VARIABLE@ in Makefile.in.
++# This macro is traced by Automake.
++AC_DEFUN([_AM_SUBST_NOTMAKE])
++
++# AM_SUBST_NOTMAKE(VARIABLE)
++# ---------------------------
++# Public sister of _AM_SUBST_NOTMAKE.
++AC_DEFUN([AM_SUBST_NOTMAKE], [_AM_SUBST_NOTMAKE($@)])
++
++# Check how to create a tarball.                            -*- Autoconf -*-
++
++# Copyright (C) 2004, 2005  Free Software Foundation, Inc.
++#
++# This file is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# serial 2
++
++# _AM_PROG_TAR(FORMAT)
++# --------------------
++# Check how to create a tarball in format FORMAT.
++# FORMAT should be one of `v7', `ustar', or `pax'.
++#
++# Substitute a variable $(am__tar) that is a command
++# writing to stdout a FORMAT-tarball containing the directory
++# $tardir.
++#     tardir=directory && $(am__tar) > result.tar
++#
++# Substitute a variable $(am__untar) that extract such
++# a tarball read from stdin.
++#     $(am__untar) < result.tar
++AC_DEFUN([_AM_PROG_TAR],
++[# Always define AMTAR for backward compatibility.
++AM_MISSING_PROG([AMTAR], [tar])
++m4_if([$1], [v7],
++     [am__tar='${AMTAR} chof - "$$tardir"'; am__untar='${AMTAR} xf -'],
++     [m4_case([$1], [ustar],, [pax],,
++              [m4_fatal([Unknown tar format])])
++AC_MSG_CHECKING([how to create a $1 tar archive])
++# Loop over all known methods to create a tar archive until one works.
++_am_tools='gnutar m4_if([$1], [ustar], [plaintar]) pax cpio none'
++_am_tools=${am_cv_prog_tar_$1-$_am_tools}
++# Do not fold the above two line into one, because Tru64 sh and
++# Solaris sh will not grok spaces in the rhs of `-'.
++for _am_tool in $_am_tools
++do
++  case $_am_tool in
++  gnutar)
++    for _am_tar in tar gnutar gtar;
++    do
++      AM_RUN_LOG([$_am_tar --version]) && break
++    done
++    am__tar="$_am_tar --format=m4_if([$1], [pax], [posix], [$1]) -chf - "'"$$tardir"'
++    am__tar_="$_am_tar --format=m4_if([$1], [pax], [posix], [$1]) -chf - "'"$tardir"'
++    am__untar="$_am_tar -xf -"
++    ;;
++  plaintar)
++    # Must skip GNU tar: if it does not support --format= it doesn't create
++    # ustar tarball either.
++    (tar --version) >/dev/null 2>&1 && continue
++    am__tar='tar chf - "$$tardir"'
++    am__tar_='tar chf - "$tardir"'
++    am__untar='tar xf -'
++    ;;
++  pax)
++    am__tar='pax -L -x $1 -w "$$tardir"'
++    am__tar_='pax -L -x $1 -w "$tardir"'
++    am__untar='pax -r'
++    ;;
++  cpio)
++    am__tar='find "$$tardir" -print | cpio -o -H $1 -L'
++    am__tar_='find "$tardir" -print | cpio -o -H $1 -L'
++    am__untar='cpio -i -H $1 -d'
++    ;;
++  none)
++    am__tar=false
++    am__tar_=false
++    am__untar=false
++    ;;
++  esac
++
++  # If the value was cached, stop now.  We just wanted to have am__tar
++  # and am__untar set.
++  test -n "${am_cv_prog_tar_$1}" && break
++
++  # tar/untar a dummy directory, and stop if the command works
++  rm -rf conftest.dir
++  mkdir conftest.dir
++  echo GrepMe > conftest.dir/file
++  AM_RUN_LOG([tardir=conftest.dir && eval $am__tar_ >conftest.tar])
++  rm -rf conftest.dir
++  if test -s conftest.tar; then
++    AM_RUN_LOG([$am__untar <conftest.tar])
++    grep GrepMe conftest.dir/file >/dev/null 2>&1 && break
++  fi
++done
++rm -rf conftest.dir
++
++AC_CACHE_VAL([am_cv_prog_tar_$1], [am_cv_prog_tar_$1=$_am_tool])
++AC_MSG_RESULT([$am_cv_prog_tar_$1])])
++AC_SUBST([am__tar])
++AC_SUBST([am__untar])
++]) # _AM_PROG_TAR
++
++m4_include([cf/aix.m4])
++m4_include([cf/auth-modules.m4])
++m4_include([cf/broken-getaddrinfo.m4])
++m4_include([cf/broken-glob.m4])
++m4_include([cf/broken-realloc.m4])
++m4_include([cf/broken-snprintf.m4])
++m4_include([cf/broken.m4])
++m4_include([cf/broken2.m4])
++m4_include([cf/c-attribute.m4])
++m4_include([cf/capabilities.m4])
++m4_include([cf/check-compile-et.m4])
++m4_include([cf/check-getpwnam_r-posix.m4])
++m4_include([cf/check-man.m4])
++m4_include([cf/check-netinet-ip-and-tcp.m4])
++m4_include([cf/check-type-extra.m4])
++m4_include([cf/check-var.m4])
++m4_include([cf/check-x.m4])
++m4_include([cf/check-xau.m4])
++m4_include([cf/crypto.m4])
++m4_include([cf/db.m4])
++m4_include([cf/destdirs.m4])
++m4_include([cf/dispatch.m4])
++m4_include([cf/dlopen.m4])
++m4_include([cf/find-func-no-libs.m4])
++m4_include([cf/find-func-no-libs2.m4])
++m4_include([cf/find-func.m4])
++m4_include([cf/find-if-not-broken.m4])
++m4_include([cf/framework-security.m4])
++m4_include([cf/have-struct-field.m4])
++m4_include([cf/have-type.m4])
++m4_include([cf/irix.m4])
++m4_include([cf/krb-bigendian.m4])
++m4_include([cf/krb-func-getlogin.m4])
++m4_include([cf/krb-ipv6.m4])
++m4_include([cf/krb-prog-ln-s.m4])
++m4_include([cf/krb-readline.m4])
++m4_include([cf/krb-struct-spwd.m4])
++m4_include([cf/krb-struct-winsize.m4])
++m4_include([cf/largefile.m4])
++m4_include([cf/libtool.m4])
++m4_include([cf/ltoptions.m4])
++m4_include([cf/ltsugar.m4])
++m4_include([cf/ltversion.m4])
++m4_include([cf/lt~obsolete.m4])
++m4_include([cf/mips-abi.m4])
++m4_include([cf/misc.m4])
++m4_include([cf/need-proto.m4])
++m4_include([cf/osfc2.m4])
++m4_include([cf/otp.m4])
++m4_include([cf/pkg.m4])
++m4_include([cf/proto-compat.m4])
++m4_include([cf/pthreads.m4])
++m4_include([cf/resolv.m4])
++m4_include([cf/retsigtype.m4])
++m4_include([cf/roken-frag.m4])
++m4_include([cf/socket-wrapper.m4])
++m4_include([cf/sunos.m4])
++m4_include([cf/telnet.m4])
++m4_include([cf/test-package.m4])
++m4_include([cf/version-script.m4])
++m4_include([cf/wflags.m4])
++m4_include([cf/win32.m4])
++m4_include([cf/with-all.m4])
++m4_include([acinclude.m4])
+Index: git/admin/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/admin/Makefile.in	2010-12-29 04:07:00.423304554 +0100
+@@ -0,0 +1,991 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++sbin_PROGRAMS = ktutil$(EXEEXT)
++subdir = admin
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(sbindir)" "$(DESTDIR)$(man8dir)"
++PROGRAMS = $(sbin_PROGRAMS)
++dist_ktutil_OBJECTS = add.$(OBJEXT) change.$(OBJEXT) copy.$(OBJEXT) \
++	destroy.$(OBJEXT) get.$(OBJEXT) ktutil.$(OBJEXT) \
++	list.$(OBJEXT) purge.$(OBJEXT) remove.$(OBJEXT) \
++	rename.$(OBJEXT)
++nodist_ktutil_OBJECTS = ktutil-commands.$(OBJEXT)
++ktutil_OBJECTS = $(dist_ktutil_OBJECTS) $(nodist_ktutil_OBJECTS)
++ktutil_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++ktutil_DEPENDENCIES = $(top_builddir)/lib/kadm5/libkadm5clnt.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/sl/libsl.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(dist_ktutil_SOURCES) $(nodist_ktutil_SOURCES)
++DIST_SOURCES = $(dist_ktutil_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_readline) $(INCLUDE_hcrypto)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++man_MANS = ktutil.8
++dist_ktutil_SOURCES = \
++	add.c					\
++	change.c				\
++	copy.c					\
++	destroy.c				\
++	get.c					\
++	ktutil.c				\
++	ktutil_locl.h				\
++	list.c					\
++	purge.c					\
++	remove.c				\
++	rename.c
++
++nodist_ktutil_SOURCES = \
++	ktutil-commands.c
++
++CLEANFILES = ktutil-commands.h ktutil-commands.c
++LDADD = \
++	$(top_builddir)/lib/kadm5/libkadm5clnt.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/sl/libsl.la \
++	$(LIB_readline) \
++	$(LIB_roken)
++
++EXTRA_DIST = $(man_MANS) ktutil-commands.in
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign admin/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign admin/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-sbinPROGRAMS: $(sbin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(sbindir)" || $(MKDIR_P) "$(DESTDIR)$(sbindir)"
++	@list='$(sbin_PROGRAMS)'; test -n "$(sbindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(sbindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(sbindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-sbinPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(sbin_PROGRAMS)'; test -n "$(sbindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(sbindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(sbindir)" && rm -f $$files
++
++clean-sbinPROGRAMS:
++	@list='$(sbin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++ktutil$(EXEEXT): $(ktutil_OBJECTS) $(ktutil_DEPENDENCIES) 
++	@rm -f ktutil$(EXEEXT)
++	$(LINK) $(ktutil_OBJECTS) $(ktutil_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/add.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/change.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/copy.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/destroy.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/get.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ktutil-commands.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ktutil.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/list.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/purge.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/remove.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/rename.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(sbindir)" "$(DESTDIR)$(man8dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool clean-sbinPROGRAMS \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-sbinPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-man uninstall-sbinPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libtool clean-sbinPROGRAMS ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-man8 install-pdf install-pdf-am install-ps \
++	install-ps-am install-sbinPROGRAMS install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-hook uninstall-man \
++	uninstall-man8 uninstall-sbinPROGRAMS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(ktutil_OBJECTS): ktutil-commands.h
++
++ktutil-commands.c ktutil-commands.h: ktutil-commands.in
++	$(SLC) $(srcdir)/ktutil-commands.in
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/Makefile.in	2010-12-29 04:07:00.583355180 +0100
+@@ -0,0 +1,930 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = appl
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \
++	html-recursive info-recursive install-data-recursive \
++	install-dvi-recursive install-exec-recursive \
++	install-html-recursive install-info-recursive \
++	install-pdf-recursive install-ps-recursive install-recursive \
++	installcheck-recursive installdirs-recursive pdf-recursive \
++	ps-recursive uninstall-recursive
++RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive	\
++  distclean-recursive maintainer-clean-recursive
++AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \
++	$(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS \
++	distdir
++ETAGS = etags
++CTAGS = ctags
++DIST_SUBDIRS = afsutil ftp login otp gssmask popper push rsh rcp su \
++	xnlock telnet test kx kf dceutils
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++am__relativize = \
++  dir0=`pwd`; \
++  sed_first='s,^\([^/]*\)/.*$$,\1,'; \
++  sed_rest='s,^[^/]*/*,,'; \
++  sed_last='s,^.*/\([^/]*\)$$,\1,'; \
++  sed_butlast='s,/*[^/]*$$,,'; \
++  while test -n "$$dir1"; do \
++    first=`echo "$$dir1" | sed -e "$$sed_first"`; \
++    if test "$$first" != "."; then \
++      if test "$$first" = ".."; then \
++        dir2=`echo "$$dir0" | sed -e "$$sed_last"`/"$$dir2"; \
++        dir0=`echo "$$dir0" | sed -e "$$sed_butlast"`; \
++      else \
++        first2=`echo "$$dir2" | sed -e "$$sed_first"`; \
++        if test "$$first2" = "$$first"; then \
++          dir2=`echo "$$dir2" | sed -e "$$sed_rest"`; \
++        else \
++          dir2="../$$dir2"; \
++        fi; \
++        dir0="$$dir0"/"$$first"; \
++      fi; \
++    fi; \
++    dir1=`echo "$$dir1" | sed -e "$$sed_rest"`; \
++  done; \
++  reldir="$$dir2"
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++@OTP_TRUE@dir_otp = otp
++@DCE_TRUE@dir_dce = dceutils
++SUBDIRS = \
++	  afsutil				\
++	  ftp					\
++	  login					\
++	  $(dir_otp)				\
++	  gssmask				\
++	  popper				\
++	  push					\
++	  rsh					\
++	  rcp					\
++	  su					\
++	  xnlock				\
++	  telnet				\
++	  test					\
++	  kx					\
++	  kf					\
++	  $(dir_dce)
++
++all: all-recursive
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++# This directory's subdirectories are mostly independent; you can cd
++# into them and run `make' without going through this Makefile.
++# To change the values of `make' variables: instead of editing Makefiles,
++# (1) if the variable is set in `config.status', edit `config.status'
++#     (which will cause the Makefiles to be regenerated when you run `make');
++# (2) otherwise, pass the desired values on the `make' command line.
++$(RECURSIVE_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	target=`echo $@ | sed s/-recursive//`; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    dot_seen=yes; \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done; \
++	if test "$$dot_seen" = "no"; then \
++	  $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
++	fi; test -z "$$fail"
++
++$(RECURSIVE_CLEAN_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	case "$@" in \
++	  distclean-* | maintainer-clean-*) list='$(DIST_SUBDIRS)' ;; \
++	  *) list='$(SUBDIRS)' ;; \
++	esac; \
++	rev=''; for subdir in $$list; do \
++	  if test "$$subdir" = "."; then :; else \
++	    rev="$$subdir $$rev"; \
++	  fi; \
++	done; \
++	rev="$$rev ."; \
++	target=`echo $@ | sed s/-recursive//`; \
++	for subdir in $$rev; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done && test -z "$$fail"
++tags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
++	done
++ctags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) ctags); \
++	done
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS: tags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	if ($(ETAGS) --etags-include --version) >/dev/null 2>&1; then \
++	  include_option=--etags-include; \
++	  empty_fix=.; \
++	else \
++	  include_option=--include; \
++	  empty_fix=; \
++	fi; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test ! -f $$subdir/TAGS || \
++	      set "$$@" "$$include_option=$$here/$$subdir/TAGS"; \
++	  fi; \
++	done; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS: ctags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test -d "$(distdir)/$$subdir" \
++	    || $(MKDIR_P) "$(distdir)/$$subdir" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    dir1=$$subdir; dir2="$(distdir)/$$subdir"; \
++	    $(am__relativize); \
++	    new_distdir=$$reldir; \
++	    dir1=$$subdir; dir2="$(top_distdir)"; \
++	    $(am__relativize); \
++	    new_top_distdir=$$reldir; \
++	    echo " (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir="$$new_top_distdir" distdir="$$new_distdir" \\"; \
++	    echo "     am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)"; \
++	    ($(am__cd) $$subdir && \
++	      $(MAKE) $(AM_MAKEFLAGS) \
++	        top_distdir="$$new_top_distdir" \
++	        distdir="$$new_distdir" \
++		am__remove_distdir=: \
++		am__skip_length_check=: \
++		am__skip_mode_fix=: \
++	        distdir) \
++	      || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-recursive
++all-am: Makefile all-local
++installdirs: installdirs-recursive
++installdirs-am:
++install: install-recursive
++install-exec: install-exec-recursive
++install-data: install-data-recursive
++uninstall: uninstall-recursive
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-recursive
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-recursive
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-recursive
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic distclean-tags
++
++dvi: dvi-recursive
++
++dvi-am:
++
++html: html-recursive
++
++html-am:
++
++info: info-recursive
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-recursive
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-recursive
++
++install-html-am:
++
++install-info: install-info-recursive
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-recursive
++
++install-pdf-am:
++
++install-ps: install-ps-recursive
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-recursive
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-recursive
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-recursive
++
++pdf-am:
++
++ps: ps-recursive
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) check-am \
++	ctags-recursive install-am install-data-am install-exec-am \
++	install-strip tags-recursive uninstall-am
++
++.PHONY: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) CTAGS GTAGS \
++	all all-am all-local check check-am check-local clean \
++	clean-generic clean-libtool ctags ctags-recursive dist-hook \
++	distclean distclean-generic distclean-libtool distclean-tags \
++	distdir dvi dvi-am html html-am info info-am install \
++	install-am install-data install-data-am install-data-hook \
++	install-dvi install-dvi-am install-exec install-exec-am \
++	install-exec-hook install-html install-html-am install-info \
++	install-info-am install-man install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs installdirs-am maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags tags-recursive \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/afsutil/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/afsutil/Makefile.in	2010-12-29 04:07:00.773415298 +0100
+@@ -0,0 +1,965 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++bin_PROGRAMS = afslog$(EXEEXT) pagsh$(EXEEXT)
++subdir = appl/afsutil
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)"
++PROGRAMS = $(bin_PROGRAMS)
++am_afslog_OBJECTS = afslog.$(OBJEXT)
++afslog_OBJECTS = $(am_afslog_OBJECTS)
++afslog_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++am__DEPENDENCIES_2 = $(top_builddir)/lib/kafs/libkafs.la \
++	$(am__DEPENDENCIES_1)
++afslog_DEPENDENCIES = $(am__DEPENDENCIES_2) $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++am_pagsh_OBJECTS = pagsh.$(OBJEXT)
++pagsh_OBJECTS = $(am_pagsh_OBJECTS)
++pagsh_LDADD = $(LDADD)
++pagsh_DEPENDENCIES = $(am__DEPENDENCIES_2) $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(afslog_SOURCES) $(pagsh_SOURCES)
++DIST_SOURCES = $(afslog_SOURCES) $(pagsh_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man1dir = $(mandir)/man1
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_krb4)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++afslog_SOURCES = afslog.c
++pagsh_SOURCES = pagsh.c
++man_MANS = afslog.1 pagsh.1
++LDADD = $(LIB_kafs) \
++	$(LIB_krb4) \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_hcrypto) \
++	$(LIB_roken)
++
++EXTRA_DIST = $(man_MANS)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/afsutil/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/afsutil/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++afslog$(EXEEXT): $(afslog_OBJECTS) $(afslog_DEPENDENCIES) 
++	@rm -f afslog$(EXEEXT)
++	$(LINK) $(afslog_OBJECTS) $(afslog_LDADD) $(LIBS)
++pagsh$(EXEEXT): $(pagsh_OBJECTS) $(pagsh_DEPENDENCIES) 
++	@rm -f pagsh$(EXEEXT)
++	$(LINK) $(pagsh_OBJECTS) $(pagsh_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/afslog.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pagsh.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-binPROGRAMS \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-man install-man1 install-pdf install-pdf-am install-ps \
++	install-ps-am install-strip installcheck installcheck-am \
++	installdirs maintainer-clean maintainer-clean-generic \
++	mostlyclean mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags uninstall \
++	uninstall-am uninstall-binPROGRAMS uninstall-hook \
++	uninstall-man uninstall-man1
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/dceutils/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/dceutils/Makefile.in	2010-12-29 04:07:00.973478578 +0100
+@@ -0,0 +1,907 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++libexec_PROGRAMS = $(am__EXEEXT_1) $(am__EXEEXT_2)
++subdir = appl/dceutils
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__EXEEXT_1 = k5dcecon$(EXEEXT)
++@AIX_TRUE@am__EXEEXT_2 = dpagaix$(EXEEXT)
++am__installdirs = "$(DESTDIR)$(libexecdir)"
++PROGRAMS = $(libexec_PROGRAMS)
++am_dpagaix_OBJECTS = dpagaix-dpagaix.$(OBJEXT)
++dpagaix_OBJECTS = $(am_dpagaix_OBJECTS)
++am__DEPENDENCIES_1 =
++dpagaix_DEPENDENCIES = $(am__DEPENDENCIES_1)
++dpagaix_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(dpagaix_CFLAGS) $(CFLAGS) \
++	$(dpagaix_LDFLAGS) $(LDFLAGS) -o $@
++am_k5dcecon_OBJECTS = k5dcecon.$(OBJEXT)
++k5dcecon_OBJECTS = $(am_k5dcecon_OBJECTS)
++k5dcecon_LDADD = $(LDADD)
++@IRIX_FALSE@k5dcecon_DEPENDENCIES = $(am__DEPENDENCIES_1) \
++@IRIX_FALSE@	$(am__DEPENDENCIES_1)
++@IRIX_TRUE@k5dcecon_DEPENDENCIES = $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(dpagaix_SOURCES) $(k5dcecon_SOURCES)
++DIST_SOURCES = $(dpagaix_SOURCES) $(k5dcecon_SOURCES)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++DFSPROGS = k5dcecon
++@AIX_TRUE@AIX_DFSPROGS = dpagaix
++dpagaix_CFLAGS = $(dpagaix_cflags)
++dpagaix_LDFLAGS = $(dpagaix_ldflags)
++dpagaix_LDADD = $(dpagaix_ldadd)
++LIB_dce = -ldce
++k5dcecon_SOURCES = k5dcecon.c k5dce.h
++dpagaix_SOURCES = dpagaix.c
++EXTRA_DIST = \
++	dfspag.exp \
++	README.dcedfs \
++	README.original \
++	testpag.c
++
++@IRIX_FALSE@LDADD = $(LIB_roken) $(LIB_dce)
++@IRIX_TRUE@LDADD = $(LIB_dce)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/dceutils/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/dceutils/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libexecPROGRAMS: $(libexec_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexecPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
++
++clean-libexecPROGRAMS:
++	@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++k5dcecon$(EXEEXT): $(k5dcecon_OBJECTS) $(k5dcecon_DEPENDENCIES) 
++	@rm -f k5dcecon$(EXEEXT)
++	$(LINK) $(k5dcecon_OBJECTS) $(k5dcecon_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/dpagaix-dpagaix.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/k5dcecon.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++dpagaix-dpagaix.o: dpagaix.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(dpagaix_CFLAGS) $(CFLAGS) -MT dpagaix-dpagaix.o -MD -MP -MF $(DEPDIR)/dpagaix-dpagaix.Tpo -c -o dpagaix-dpagaix.o `test -f 'dpagaix.c' || echo '$(srcdir)/'`dpagaix.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/dpagaix-dpagaix.Tpo $(DEPDIR)/dpagaix-dpagaix.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='dpagaix.c' object='dpagaix-dpagaix.o' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(dpagaix_CFLAGS) $(CFLAGS) -c -o dpagaix-dpagaix.o `test -f 'dpagaix.c' || echo '$(srcdir)/'`dpagaix.c
++
++dpagaix-dpagaix.obj: dpagaix.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(dpagaix_CFLAGS) $(CFLAGS) -MT dpagaix-dpagaix.obj -MD -MP -MF $(DEPDIR)/dpagaix-dpagaix.Tpo -c -o dpagaix-dpagaix.obj `if test -f 'dpagaix.c'; then $(CYGPATH_W) 'dpagaix.c'; else $(CYGPATH_W) '$(srcdir)/dpagaix.c'; fi`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/dpagaix-dpagaix.Tpo $(DEPDIR)/dpagaix-dpagaix.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='dpagaix.c' object='dpagaix-dpagaix.obj' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(dpagaix_CFLAGS) $(CFLAGS) -c -o dpagaix-dpagaix.obj `if test -f 'dpagaix.c'; then $(CYGPATH_W) 'dpagaix.c'; else $(CYGPATH_W) '$(srcdir)/dpagaix.c'; fi`
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libexecdir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libexecPROGRAMS clean-libtool \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libexecPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-libexecPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libexecPROGRAMS clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am \
++	install-libexecPROGRAMS install-man install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-hook \
++	uninstall-libexecPROGRAMS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++dpagaix$(EXEEXT): $(dpagaix_OBJECTS)
++	ld -edpagaix -o dpagaix$(EXEEXT) $(dpagaix_OBJECTS) $(srcdir)/dfspag.exp
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/ftp/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/ftp/Makefile.in	2010-12-29 04:07:01.133529152 +0100
+@@ -0,0 +1,910 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++subdir = appl/ftp
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \
++	html-recursive info-recursive install-data-recursive \
++	install-dvi-recursive install-exec-recursive \
++	install-html-recursive install-info-recursive \
++	install-pdf-recursive install-ps-recursive install-recursive \
++	installcheck-recursive installdirs-recursive pdf-recursive \
++	ps-recursive uninstall-recursive
++RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive	\
++  distclean-recursive maintainer-clean-recursive
++AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \
++	$(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS \
++	distdir
++ETAGS = etags
++CTAGS = ctags
++DIST_SUBDIRS = $(SUBDIRS)
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++am__relativize = \
++  dir0=`pwd`; \
++  sed_first='s,^\([^/]*\)/.*$$,\1,'; \
++  sed_rest='s,^[^/]*/*,,'; \
++  sed_last='s,^.*/\([^/]*\)$$,\1,'; \
++  sed_butlast='s,/*[^/]*$$,,'; \
++  while test -n "$$dir1"; do \
++    first=`echo "$$dir1" | sed -e "$$sed_first"`; \
++    if test "$$first" != "."; then \
++      if test "$$first" = ".."; then \
++        dir2=`echo "$$dir0" | sed -e "$$sed_last"`/"$$dir2"; \
++        dir0=`echo "$$dir0" | sed -e "$$sed_butlast"`; \
++      else \
++        first2=`echo "$$dir2" | sed -e "$$sed_first"`; \
++        if test "$$first2" = "$$first"; then \
++          dir2=`echo "$$dir2" | sed -e "$$sed_rest"`; \
++        else \
++          dir2="../$$dir2"; \
++        fi; \
++        dir0="$$dir0"/"$$first"; \
++      fi; \
++    fi; \
++    dir1=`echo "$$dir1" | sed -e "$$sed_rest"`; \
++  done; \
++  reldir="$$dir2"
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++SUBDIRS = common ftp ftpd
++all: all-recursive
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/ftp/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/ftp/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++# This directory's subdirectories are mostly independent; you can cd
++# into them and run `make' without going through this Makefile.
++# To change the values of `make' variables: instead of editing Makefiles,
++# (1) if the variable is set in `config.status', edit `config.status'
++#     (which will cause the Makefiles to be regenerated when you run `make');
++# (2) otherwise, pass the desired values on the `make' command line.
++$(RECURSIVE_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	target=`echo $@ | sed s/-recursive//`; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    dot_seen=yes; \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done; \
++	if test "$$dot_seen" = "no"; then \
++	  $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
++	fi; test -z "$$fail"
++
++$(RECURSIVE_CLEAN_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	case "$@" in \
++	  distclean-* | maintainer-clean-*) list='$(DIST_SUBDIRS)' ;; \
++	  *) list='$(SUBDIRS)' ;; \
++	esac; \
++	rev=''; for subdir in $$list; do \
++	  if test "$$subdir" = "."; then :; else \
++	    rev="$$subdir $$rev"; \
++	  fi; \
++	done; \
++	rev="$$rev ."; \
++	target=`echo $@ | sed s/-recursive//`; \
++	for subdir in $$rev; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done && test -z "$$fail"
++tags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
++	done
++ctags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) ctags); \
++	done
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS: tags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	if ($(ETAGS) --etags-include --version) >/dev/null 2>&1; then \
++	  include_option=--etags-include; \
++	  empty_fix=.; \
++	else \
++	  include_option=--include; \
++	  empty_fix=; \
++	fi; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test ! -f $$subdir/TAGS || \
++	      set "$$@" "$$include_option=$$here/$$subdir/TAGS"; \
++	  fi; \
++	done; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS: ctags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test -d "$(distdir)/$$subdir" \
++	    || $(MKDIR_P) "$(distdir)/$$subdir" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    dir1=$$subdir; dir2="$(distdir)/$$subdir"; \
++	    $(am__relativize); \
++	    new_distdir=$$reldir; \
++	    dir1=$$subdir; dir2="$(top_distdir)"; \
++	    $(am__relativize); \
++	    new_top_distdir=$$reldir; \
++	    echo " (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir="$$new_top_distdir" distdir="$$new_distdir" \\"; \
++	    echo "     am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)"; \
++	    ($(am__cd) $$subdir && \
++	      $(MAKE) $(AM_MAKEFLAGS) \
++	        top_distdir="$$new_top_distdir" \
++	        distdir="$$new_distdir" \
++		am__remove_distdir=: \
++		am__skip_length_check=: \
++		am__skip_mode_fix=: \
++	        distdir) \
++	      || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-recursive
++all-am: Makefile all-local
++installdirs: installdirs-recursive
++installdirs-am:
++install: install-recursive
++install-exec: install-exec-recursive
++install-data: install-data-recursive
++uninstall: uninstall-recursive
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-recursive
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-recursive
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-recursive
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic distclean-tags
++
++dvi: dvi-recursive
++
++dvi-am:
++
++html: html-recursive
++
++html-am:
++
++info: info-recursive
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-recursive
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-recursive
++
++install-html-am:
++
++install-info: install-info-recursive
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-recursive
++
++install-pdf-am:
++
++install-ps: install-ps-recursive
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-recursive
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-recursive
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-recursive
++
++pdf-am:
++
++ps: ps-recursive
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) check-am \
++	ctags-recursive install-am install-data-am install-exec-am \
++	install-strip tags-recursive uninstall-am
++
++.PHONY: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) CTAGS GTAGS \
++	all all-am all-local check check-am check-local clean \
++	clean-generic clean-libtool ctags ctags-recursive dist-hook \
++	distclean distclean-generic distclean-libtool distclean-tags \
++	distdir dvi dvi-am html html-am info info-am install \
++	install-am install-data install-data-am install-data-hook \
++	install-dvi install-dvi-am install-exec install-exec-am \
++	install-exec-hook install-html install-html-am install-info \
++	install-info-am install-man install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs installdirs-am maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags tags-recursive \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/ftp/common/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/ftp/common/Makefile.in	2010-12-29 04:07:01.323589194 +0100
+@@ -0,0 +1,824 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = appl/ftp/common
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++LIBRARIES = $(noinst_LIBRARIES)
++ARFLAGS = cru
++libcommon_a_AR = $(AR) $(ARFLAGS)
++libcommon_a_LIBADD =
++am_libcommon_a_OBJECTS = sockbuf.$(OBJEXT) buffer.$(OBJEXT)
++libcommon_a_OBJECTS = $(am_libcommon_a_OBJECTS)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(libcommon_a_SOURCES)
++DIST_SOURCES = $(libcommon_a_SOURCES)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_krb4)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++noinst_LIBRARIES = libcommon.a
++libcommon_a_SOURCES = \
++	sockbuf.c \
++	buffer.c \
++	common.h
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/ftp/common/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/ftp/common/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++clean-noinstLIBRARIES:
++	-test -z "$(noinst_LIBRARIES)" || rm -f $(noinst_LIBRARIES)
++libcommon.a: $(libcommon_a_OBJECTS) $(libcommon_a_DEPENDENCIES) 
++	-rm -f libcommon.a
++	$(libcommon_a_AR) libcommon.a $(libcommon_a_OBJECTS) $(libcommon_a_LIBADD)
++	$(RANLIB) libcommon.a
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/buffer.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/sockbuf.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(LIBRARIES) all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool clean-noinstLIBRARIES \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libtool clean-noinstLIBRARIES ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-compile mostlyclean-generic mostlyclean-libtool \
++	pdf pdf-am ps ps-am tags uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/ftp/ftp/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/ftp/ftp/Makefile.in	2010-12-29 04:07:01.523652398 +0100
+@@ -0,0 +1,987 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++bin_PROGRAMS = ftp$(EXEEXT)
++subdir = appl/ftp/ftp
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)"
++PROGRAMS = $(bin_PROGRAMS)
++am__ftp_SOURCES_DIST = cmds.c cmdtab.c extern.h ftp.c ftp_locl.h \
++	ftp_var.h main.c pathnames.h ruserpass.c domacro.c globals.c \
++	security.c security.h kauth.c gssapi.c
++@KRB5_TRUE@am__objects_1 = gssapi.$(OBJEXT)
++am_ftp_OBJECTS = cmds.$(OBJEXT) cmdtab.$(OBJEXT) ftp.$(OBJEXT) \
++	main.$(OBJEXT) ruserpass.$(OBJEXT) domacro.$(OBJEXT) \
++	globals.$(OBJEXT) security.$(OBJEXT) kauth.$(OBJEXT) \
++	$(am__objects_1)
++ftp_OBJECTS = $(am_ftp_OBJECTS)
++ftp_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++ftp_DEPENDENCIES = ../common/libcommon.a $(LIB_gssapi) $(LIB_krb5) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(ftp_SOURCES) $(EXTRA_ftp_SOURCES)
++DIST_SOURCES = $(am__ftp_SOURCES_DIST) $(EXTRA_ftp_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man1dir = $(mandir)/man1
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) -I$(srcdir)/../common \
++	$(INCLUDE_readline) $(INCLUDE_hcrypto)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++CHECK_LOCAL = 
++@KRB5_TRUE@krb5_sources = gssapi.c
++ftp_SOURCES = \
++	cmds.c \
++	cmdtab.c \
++	extern.h \
++	ftp.c \
++	ftp_locl.h \
++	ftp_var.h \
++	main.c \
++	pathnames.h \
++	ruserpass.c \
++	domacro.c \
++	globals.c \
++	security.c \
++	security.h \
++	kauth.c \
++	$(krb5_sources)
++
++EXTRA_ftp_SOURCES = gssapi.c
++man_MANS = ftp.1
++LDADD = \
++	../common/libcommon.a \
++	$(LIB_gssapi) \
++	$(LIB_krb5) \
++	$(LIB_hcrypto) \
++	$(LIB_roken) \
++	$(LIB_readline)
++
++EXTRA_DIST = $(man_MANS)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/ftp/ftp/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/ftp/ftp/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++ftp$(EXEEXT): $(ftp_OBJECTS) $(ftp_DEPENDENCIES) 
++	@rm -f ftp$(EXEEXT)
++	$(LINK) $(ftp_OBJECTS) $(ftp_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/cmds.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/cmdtab.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/domacro.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ftp.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/globals.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gssapi.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kauth.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/main.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ruserpass.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/security.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-binPROGRAMS \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-man install-man1 install-pdf install-pdf-am install-ps \
++	install-ps-am install-strip installcheck installcheck-am \
++	installdirs maintainer-clean maintainer-clean-generic \
++	mostlyclean mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags uninstall \
++	uninstall-am uninstall-binPROGRAMS uninstall-hook \
++	uninstall-man uninstall-man1
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/ftp/ftpd/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/ftp/ftpd/Makefile.in	2010-12-29 04:07:01.753725080 +0100
+@@ -0,0 +1,1050 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ftpcmd.c
++libexec_PROGRAMS = ftpd$(EXEEXT)
++subdir = appl/ftp/ftpd
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(man5dir)" \
++	"$(DESTDIR)$(man8dir)"
++PROGRAMS = $(libexec_PROGRAMS)
++am__ftpd_SOURCES_DIST = extern.h ftpcmd.y ftpd.c ftpd_locl.h logwtmp.c \
++	ls.c pathnames.h popen.c security.c kauth.c klist.c gssapi.c \
++	gss_userok.c
++@KRB5_TRUE@am__objects_1 = gssapi.$(OBJEXT) gss_userok.$(OBJEXT)
++am_ftpd_OBJECTS = ftpcmd.$(OBJEXT) ftpd.$(OBJEXT) logwtmp.$(OBJEXT) \
++	ls.$(OBJEXT) popen.$(OBJEXT) security.$(OBJEXT) \
++	kauth.$(OBJEXT) klist.$(OBJEXT) $(am__objects_1)
++ftpd_OBJECTS = $(am_ftpd_OBJECTS)
++ftpd_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++am__DEPENDENCIES_2 = $(top_builddir)/lib/kafs/libkafs.la \
++	$(am__DEPENDENCIES_1)
++ftpd_DEPENDENCIES = ../common/libcommon.a $(am__DEPENDENCIES_1) \
++	$(LIB_gssapi) $(LIB_krb5) $(am__DEPENDENCIES_2) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++@MAINTAINER_MODE_FALSE@am__skipyacc = test -f $@ ||
++YACCCOMPILE = $(YACC) $(YFLAGS) $(AM_YFLAGS)
++LTYACCCOMPILE = $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(YACC) $(YFLAGS) $(AM_YFLAGS)
++YLWRAP = $(top_srcdir)/ylwrap
++SOURCES = $(ftpd_SOURCES) $(EXTRA_ftpd_SOURCES)
++DIST_SOURCES = $(am__ftpd_SOURCES_DIST) $(EXTRA_ftpd_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man5dir = $(mandir)/man5
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) -I$(srcdir)/../common $(INCLUDE_krb4) \
++	-DFTP_SERVER
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++CHECK_LOCAL = 
++@KRB5_TRUE@krb5_sources = gssapi.c gss_userok.c
++ftpd_SOURCES = \
++	extern.h	\
++	ftpcmd.y	\
++	ftpd.c		\
++	ftpd_locl.h	\
++	logwtmp.c	\
++	ls.c		\
++	pathnames.h	\
++	popen.c		\
++	security.c	\
++	kauth.c		\
++	klist.c		\
++	$(krb4_sources) \
++	$(krb5_sources)
++
++EXTRA_ftpd_SOURCES = kauth.c gssapi.c gss_userok.c
++CLEANFILES = security.c security.h gssapi.c
++man_MANS = ftpd.8 ftpusers.5
++LDADD = ../common/libcommon.a \
++	$(LIB_otp) \
++	$(LIB_gssapi) \
++	$(LIB_krb5) \
++	$(LIB_kafs) \
++	$(LIB_krb4) \
++	$(LIB_hcrypto) \
++	$(LIB_roken)
++
++EXTRA_DIST = $(man_MANS)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj .y
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/ftp/ftpd/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/ftp/ftpd/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libexecPROGRAMS: $(libexec_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexecPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
++
++clean-libexecPROGRAMS:
++	@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++ftpd$(EXEEXT): $(ftpd_OBJECTS) $(ftpd_DEPENDENCIES) 
++	@rm -f ftpd$(EXEEXT)
++	$(LINK) $(ftpd_OBJECTS) $(ftpd_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ftpcmd.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ftpd.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gss_userok.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gssapi.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kauth.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/klist.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/logwtmp.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ls.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/popen.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/security.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++.y.c:
++	$(am__skipyacc) $(SHELL) $(YLWRAP) $< y.tab.c $@ y.tab.h $*.h y.output $*.output -- $(YACCCOMPILE)
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man5: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man5dir)" || $(MKDIR_P) "$(DESTDIR)$(man5dir)"
++	@list=''; test -n "$(man5dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.5[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^5][0-9a-z]*$$,5,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man5dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man5dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man5dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man5dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man5:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man5dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.5[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^5][0-9a-z]*$$,5,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man5dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man5dir)" && rm -f $$files; }
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(man5dir)" "$(DESTDIR)$(man8dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++	-rm -f ftpcmd.c
++clean: clean-am
++
++clean-am: clean-generic clean-libexecPROGRAMS clean-libtool \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libexecPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man5 install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-libexecPROGRAMS uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man5 uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libexecPROGRAMS clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am \
++	install-libexecPROGRAMS install-man install-man5 install-man8 \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-compile mostlyclean-generic mostlyclean-libtool \
++	pdf pdf-am ps ps-am tags uninstall uninstall-am uninstall-hook \
++	uninstall-libexecPROGRAMS uninstall-man uninstall-man5 \
++	uninstall-man8
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(ftpd_OBJECTS): security.h
++
++security.c:
++	@test -f security.c || $(LN_S) $(srcdir)/../ftp/security.c .
++security.h:
++	@test -f security.h || $(LN_S) $(srcdir)/../ftp/security.h .
++gssapi.c:
++	@test -f gssapi.c || $(LN_S) $(srcdir)/../ftp/gssapi.c .
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/gssmask/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/gssmask/Makefile.in	2010-12-29 04:07:01.973794602 +0100
+@@ -0,0 +1,837 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++noinst_PROGRAMS = gssmask$(EXEEXT) gssmaestro$(EXEEXT)
++subdir = appl/gssmask
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++PROGRAMS = $(noinst_PROGRAMS)
++am_gssmaestro_OBJECTS = gssmaestro.$(OBJEXT) common.$(OBJEXT)
++gssmaestro_OBJECTS = $(am_gssmaestro_OBJECTS)
++gssmaestro_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++gssmaestro_DEPENDENCIES = $(top_builddir)/lib/gssapi/libgssapi.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/krb5/libkrb5.la
++am_gssmask_OBJECTS = gssmask.$(OBJEXT) common.$(OBJEXT)
++gssmask_OBJECTS = $(am_gssmask_OBJECTS)
++gssmask_LDADD = $(LDADD)
++gssmask_DEPENDENCIES = $(top_builddir)/lib/gssapi/libgssapi.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/krb5/libkrb5.la
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(gssmaestro_SOURCES) $(gssmask_SOURCES)
++DIST_SOURCES = $(gssmaestro_SOURCES) $(gssmask_SOURCES)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++gssmask_SOURCES = gssmask.c common.c common.h protocol.h
++gssmaestro_SOURCES = gssmaestro.c common.c common.h protocol.h
++LDADD = $(top_builddir)/lib/gssapi/libgssapi.la $(LIB_roken) $(top_builddir)/lib/krb5/libkrb5.la
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/gssmask/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/gssmask/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++gssmaestro$(EXEEXT): $(gssmaestro_OBJECTS) $(gssmaestro_DEPENDENCIES) 
++	@rm -f gssmaestro$(EXEEXT)
++	$(LINK) $(gssmaestro_OBJECTS) $(gssmaestro_LDADD) $(LIBS)
++gssmask$(EXEEXT): $(gssmask_OBJECTS) $(gssmask_DEPENDENCIES) 
++	@rm -f gssmask$(EXEEXT)
++	$(LINK) $(gssmask_OBJECTS) $(gssmask_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/common.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gssmaestro.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gssmask.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool clean-noinstPROGRAMS \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libtool clean-noinstPROGRAMS ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-compile mostlyclean-generic mostlyclean-libtool \
++	pdf pdf-am ps ps-am tags uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/kf/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/kf/Makefile.in	2010-12-29 04:07:02.193864050 +0100
+@@ -0,0 +1,1047 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++bin_PROGRAMS = kf$(EXEEXT)
++libexec_PROGRAMS = kfd$(EXEEXT)
++subdir = appl/kf
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(libexecdir)" \
++	"$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man8dir)"
++PROGRAMS = $(bin_PROGRAMS) $(libexec_PROGRAMS)
++am_kf_OBJECTS = kf.$(OBJEXT)
++kf_OBJECTS = $(am_kf_OBJECTS)
++kf_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++kf_DEPENDENCIES = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1)
++am_kfd_OBJECTS = kfd.$(OBJEXT)
++kfd_OBJECTS = $(am_kfd_OBJECTS)
++kfd_LDADD = $(LDADD)
++kfd_DEPENDENCIES = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(kf_SOURCES) $(kfd_SOURCES)
++DIST_SOURCES = $(kf_SOURCES) $(kfd_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man1dir = $(mandir)/man1
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++man_MANS = kf.1 kfd.8
++kf_SOURCES = kf.c kf_locl.h
++kfd_SOURCES = kfd.c kf_locl.h
++LDADD = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_roken)
++
++EXTRA_DIST = $(man_MANS)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/kf/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/kf/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++install-libexecPROGRAMS: $(libexec_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexecPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
++
++clean-libexecPROGRAMS:
++	@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++kf$(EXEEXT): $(kf_OBJECTS) $(kf_DEPENDENCIES) 
++	@rm -f kf$(EXEEXT)
++	$(LINK) $(kf_OBJECTS) $(kf_LDADD) $(LIBS)
++kfd$(EXEEXT): $(kfd_OBJECTS) $(kfd_DEPENDENCIES) 
++	@rm -f kfd$(EXEEXT)
++	$(LINK) $(kfd_OBJECTS) $(kfd_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kf.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kfd.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man8dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libexecPROGRAMS \
++	clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS install-libexecPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1 install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-libexecPROGRAMS \
++	uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1 uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libexecPROGRAMS \
++	clean-libtool ctags dist-hook distclean distclean-compile \
++	distclean-generic distclean-libtool distclean-tags distdir dvi \
++	dvi-am html html-am info info-am install install-am \
++	install-binPROGRAMS install-data install-data-am \
++	install-data-hook install-dvi install-dvi-am install-exec \
++	install-exec-am install-exec-hook install-html install-html-am \
++	install-info install-info-am install-libexecPROGRAMS \
++	install-man install-man1 install-man8 install-pdf \
++	install-pdf-am install-ps install-ps-am install-strip \
++	installcheck installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-binPROGRAMS \
++	uninstall-hook uninstall-libexecPROGRAMS uninstall-man \
++	uninstall-man1 uninstall-man8
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/kx/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/kx/Makefile.in	2010-12-29 04:07:02.423936643 +0100
+@@ -0,0 +1,1137 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++@HAVE_X_TRUE@bin_PROGRAMS = kx$(EXEEXT)
++@HAVE_X_TRUE@libexec_PROGRAMS = kxd$(EXEEXT)
++subdir = appl/kx
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(libexecdir)" \
++	"$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)" \
++	"$(DESTDIR)$(man8dir)"
++PROGRAMS = $(bin_PROGRAMS) $(libexec_PROGRAMS)
++am__kx_SOURCES_DIST = kx.c kx.h common.c context.c krb5.c writeauth.c
++@NEED_WRITEAUTH_TRUE@am__objects_1 = writeauth.$(OBJEXT)
++am_kx_OBJECTS = kx.$(OBJEXT) common.$(OBJEXT) context.$(OBJEXT) \
++	krb5.$(OBJEXT) $(am__objects_1)
++kx_OBJECTS = $(am_kx_OBJECTS)
++kx_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++am__DEPENDENCIES_2 = $(top_builddir)/lib/kafs/libkafs.la \
++	$(am__DEPENDENCIES_1)
++kx_DEPENDENCIES = $(am__DEPENDENCIES_2) $(LIB_krb5) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++am__kxd_SOURCES_DIST = kxd.c kx.h common.c context.c krb5.c \
++	writeauth.c
++am_kxd_OBJECTS = kxd.$(OBJEXT) common.$(OBJEXT) context.$(OBJEXT) \
++	krb5.$(OBJEXT) $(am__objects_1)
++kxd_OBJECTS = $(am_kxd_OBJECTS)
++kxd_LDADD = $(LDADD)
++kxd_DEPENDENCIES = $(am__DEPENDENCIES_2) $(LIB_krb5) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++SCRIPTS = $(bin_SCRIPTS)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(kx_SOURCES) $(EXTRA_kx_SOURCES) $(kxd_SOURCES) \
++	$(EXTRA_kxd_SOURCES)
++DIST_SOURCES = $(am__kx_SOURCES_DIST) $(EXTRA_kx_SOURCES) \
++	$(am__kxd_SOURCES_DIST) $(EXTRA_kxd_SOURCES)
++man1dir = $(mandir)/man1
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@ $(WFLAGS_NOIMPLICITINT)
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(X_CFLAGS)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++@HAVE_X_FALSE@bin_SCRIPTS = 
++@HAVE_X_TRUE@bin_SCRIPTS = rxterm rxtelnet tenletxr
++CLEANFILES = rxterm rxtelnet tenletxr
++@NEED_WRITEAUTH_TRUE@XauWriteAuth_c = writeauth.c
++kx_SOURCES = \
++	kx.c \
++	kx.h \
++	common.c \
++	context.c \
++	krb5.c \
++	$(XauWriteAuth_c)
++
++EXTRA_kx_SOURCES = writeauth.c
++kxd_SOURCES = \
++	kxd.c \
++	kx.h \
++	common.c \
++	context.c \
++	krb5.c \
++	$(XauWriteAuth_c)
++
++EXTRA_kxd_SOURCES = writeauth.c
++EXTRA_DIST = rxterm.in rxtelnet.in tenletxr.in $(man_MANS)
++man_MANS = kx.1 rxtelnet.1 rxterm.1 tenletxr.1 kxd.8
++LDADD = \
++	$(LIB_kafs)				\
++	$(LIB_krb5) 				\
++	$(LIB_hcrypto)				\
++	$(LIB_roken)				\
++	$(X_LIBS) $(LIB_XauReadAuth) $(X_PRE_LIBS) $(X_EXTRA_LIBS)
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/kx/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/kx/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++install-libexecPROGRAMS: $(libexec_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexecPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
++
++clean-libexecPROGRAMS:
++	@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++kx$(EXEEXT): $(kx_OBJECTS) $(kx_DEPENDENCIES) 
++	@rm -f kx$(EXEEXT)
++	$(LINK) $(kx_OBJECTS) $(kx_LDADD) $(LIBS)
++kxd$(EXEEXT): $(kxd_OBJECTS) $(kxd_DEPENDENCIES) 
++	@rm -f kxd$(EXEEXT)
++	$(LINK) $(kxd_OBJECTS) $(kxd_LDADD) $(LIBS)
++install-binSCRIPTS: $(bin_SCRIPTS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_SCRIPTS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  if test -f "$$d$$p"; then echo "$$d$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n' \
++	    -e 'h;s|.*|.|' \
++	    -e 'p;x;s,.*/,,;$(transform)' | sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1; } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) { files[d] = files[d] " " $$1; \
++	      if (++n[d] == $(am__install_max)) { \
++		print "f", d, files[d]; n[d] = 0; files[d] = "" } } \
++	    else { print "f", d "/" $$4, $$1 } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	     if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	     test -z "$$files" || { \
++	       echo " $(INSTALL_SCRIPT) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	       $(INSTALL_SCRIPT) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	     } \
++	; done
++
++uninstall-binSCRIPTS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_SCRIPTS)'; test -n "$(bindir)" || exit 0; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	       sed -e 's,.*/,,;$(transform)'`; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/common.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/context.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/krb5.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kx.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kxd.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/writeauth.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(SCRIPTS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man8dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libexecPROGRAMS \
++	clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS install-binSCRIPTS \
++	install-libexecPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1 install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-binSCRIPTS \
++	uninstall-libexecPROGRAMS uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1 uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libexecPROGRAMS \
++	clean-libtool ctags dist-hook distclean distclean-compile \
++	distclean-generic distclean-libtool distclean-tags distdir dvi \
++	dvi-am html html-am info info-am install install-am \
++	install-binPROGRAMS install-binSCRIPTS install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am \
++	install-libexecPROGRAMS install-man install-man1 install-man8 \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-compile mostlyclean-generic mostlyclean-libtool \
++	pdf pdf-am ps ps-am tags uninstall uninstall-am \
++	uninstall-binPROGRAMS uninstall-binSCRIPTS uninstall-hook \
++	uninstall-libexecPROGRAMS uninstall-man uninstall-man1 \
++	uninstall-man8
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++rxterm: rxterm.in
++	sed -e "s!%bindir%!$(bindir)!" $(srcdir)/rxterm.in > $@
++	chmod +x $@
++
++rxtelnet: rxtelnet.in
++	sed -e "s!%bindir%!$(bindir)!" $(srcdir)/rxtelnet.in > $@
++	chmod +x $@
++
++tenletxr: tenletxr.in
++	sed -e "s!%bindir%!$(bindir)!" $(srcdir)/tenletxr.in > $@
++	chmod +x $@
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/login/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/login/Makefile.in	2010-12-29 04:07:02.623999769 +0100
+@@ -0,0 +1,1030 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++bin_PROGRAMS = login$(EXEEXT)
++subdir = appl/login
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)" \
++	"$(DESTDIR)$(man5dir)"
++PROGRAMS = $(bin_PROGRAMS)
++am_login_OBJECTS = conf.$(OBJEXT) env.$(OBJEXT) login.$(OBJEXT) \
++	login_access.$(OBJEXT) limits_conf.$(OBJEXT) osfc2.$(OBJEXT) \
++	read_string.$(OBJEXT) shadow.$(OBJEXT) stty_default.$(OBJEXT) \
++	tty.$(OBJEXT) utmp_login.$(OBJEXT) utmpx_login.$(OBJEXT)
++login_OBJECTS = $(am_login_OBJECTS)
++login_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++am__DEPENDENCIES_2 = $(top_builddir)/lib/kafs/libkafs.la \
++	$(am__DEPENDENCIES_1)
++login_DEPENDENCIES = $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_2) \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(login_SOURCES)
++DIST_SOURCES = $(login_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man1dir = $(mandir)/man1
++man5dir = $(mandir)/man5
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++man_MANS = login.1 login.access.5
++login_SOURCES = \
++		conf.c				\
++		env.c				\
++		login.c				\
++		login_access.c			\
++		login_locl.h			\
++		login-protos.h			\
++		loginpaths.h			\
++		limits_conf.c			\
++		osfc2.c				\
++		read_string.c			\
++		shadow.c			\
++		stty_default.c			\
++		tty.c				\
++		utmp_login.c			\
++		utmpx_login.c
++
++LDADD = $(LIB_otp) \
++	$(LIB_kafs) \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_roken) \
++	$(LIB_security) \
++	$(DBLIB)
++
++EXTRA_DIST = $(man_MANS)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/login/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/login/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++login$(EXEEXT): $(login_OBJECTS) $(login_DEPENDENCIES) 
++	@rm -f login$(EXEEXT)
++	$(LINK) $(login_OBJECTS) $(login_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/conf.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/env.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/limits_conf.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/login.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/login_access.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/osfc2.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/read_string.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/shadow.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/stty_default.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/tty.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/utmp_login.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/utmpx_login.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++install-man5: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man5dir)" || $(MKDIR_P) "$(DESTDIR)$(man5dir)"
++	@list=''; test -n "$(man5dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.5[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^5][0-9a-z]*$$,5,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man5dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man5dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man5dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man5dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man5:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man5dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.5[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^5][0-9a-z]*$$,5,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man5dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man5dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man5dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1 install-man5
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1 uninstall-man5
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-binPROGRAMS \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-man install-man1 install-man5 install-pdf \
++	install-pdf-am install-ps install-ps-am install-strip \
++	installcheck installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-binPROGRAMS \
++	uninstall-hook uninstall-man uninstall-man1 uninstall-man5
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(srcdir)/login-protos.h:
++	cd $(srcdir); perl ../../cf/make-proto.pl -o login-protos.h -q -P comment $(login_SOURCES) || rm -f login-protos.h
++
++$(login_OBJECTS): $(srcdir)/login-protos.h
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/otp/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/otp/Makefile.in	2010-12-29 04:07:02.814059735 +0100
+@@ -0,0 +1,953 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++bin_PROGRAMS = otp$(EXEEXT) otpprint$(EXEEXT)
++subdir = appl/otp
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)"
++PROGRAMS = $(bin_PROGRAMS)
++am_otp_OBJECTS = otp.$(OBJEXT)
++otp_OBJECTS = $(am_otp_OBJECTS)
++am__DEPENDENCIES_1 =
++otp_DEPENDENCIES = $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/otp/libotp.la
++am_otpprint_OBJECTS = otpprint.$(OBJEXT)
++otpprint_OBJECTS = $(am_otpprint_OBJECTS)
++otpprint_DEPENDENCIES = $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/otp/libotp.la
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(otp_SOURCES) $(otpprint_SOURCES)
++DIST_SOURCES = $(otp_SOURCES) $(otpprint_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man1dir = $(mandir)/man1
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_hcrypto)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++bin_SUIDS = otp
++otp_SOURCES = otp.c otp_locl.h
++otp_LDADD = $(LIB_hcrypto) $(LIB_roken) $(top_builddir)/lib/otp/libotp.la
++otpprint_SOURCES = otpprint.c otp_locl.h
++otpprint_LDADD = $(LIB_hcrypto) $(LIB_roken) $(top_builddir)/lib/otp/libotp.la
++man_MANS = otp.1  otpprint.1
++EXTRA_DIST = $(man_MANS)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/otp/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/otp/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++otp$(EXEEXT): $(otp_OBJECTS) $(otp_DEPENDENCIES) 
++	@rm -f otp$(EXEEXT)
++	$(LINK) $(otp_OBJECTS) $(otp_LDADD) $(LIBS)
++otpprint$(EXEEXT): $(otpprint_OBJECTS) $(otpprint_DEPENDENCIES) 
++	@rm -f otpprint$(EXEEXT)
++	$(LINK) $(otpprint_OBJECTS) $(otpprint_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/otp.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/otpprint.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-binPROGRAMS \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-man install-man1 install-pdf install-pdf-am install-ps \
++	install-ps-am install-strip installcheck installcheck-am \
++	installdirs maintainer-clean maintainer-clean-generic \
++	mostlyclean mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags uninstall \
++	uninstall-am uninstall-binPROGRAMS uninstall-hook \
++	uninstall-man uninstall-man1
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/popper/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/popper/Makefile.in	2010-12-29 04:07:03.024126011 +0100
+@@ -0,0 +1,1035 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = README $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++noinst_PROGRAMS = pop_debug$(EXEEXT)
++libexec_PROGRAMS = popper$(EXEEXT)
++subdir = appl/popper
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(man8dir)"
++PROGRAMS = $(libexec_PROGRAMS) $(noinst_PROGRAMS)
++pop_debug_SOURCES = pop_debug.c
++pop_debug_OBJECTS = pop_debug.$(OBJEXT)
++pop_debug_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++pop_debug_DEPENDENCIES = $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/gssapi/libgssapi.la $(LIB_krb5) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++am_popper_OBJECTS = pop_auth.$(OBJEXT) pop_dele.$(OBJEXT) \
++	pop_dropcopy.$(OBJEXT) pop_dropinfo.$(OBJEXT) \
++	pop_get_command.$(OBJEXT) pop_init.$(OBJEXT) \
++	pop_last.$(OBJEXT) pop_list.$(OBJEXT) pop_log.$(OBJEXT) \
++	pop_msg.$(OBJEXT) pop_parse.$(OBJEXT) pop_pass.$(OBJEXT) \
++	pop_quit.$(OBJEXT) pop_rset.$(OBJEXT) pop_send.$(OBJEXT) \
++	pop_stat.$(OBJEXT) pop_uidl.$(OBJEXT) pop_updt.$(OBJEXT) \
++	pop_user.$(OBJEXT) pop_xover.$(OBJEXT) popper.$(OBJEXT) \
++	maildir.$(OBJEXT) auth_gssapi.$(OBJEXT)
++popper_OBJECTS = $(am_popper_OBJECTS)
++popper_LDADD = $(LDADD)
++popper_DEPENDENCIES = $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/gssapi/libgssapi.la $(LIB_krb5) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = pop_debug.c $(popper_SOURCES)
++DIST_SOURCES = pop_debug.c $(popper_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++popper_SOURCES = \
++	pop_auth.c				\
++	pop_auth.h				\
++	pop_dele.c				\
++	pop_dropcopy.c				\
++	pop_dropinfo.c				\
++	pop_get_command.c			\
++	pop_init.c				\
++	pop_last.c				\
++	pop_list.c				\
++	pop_log.c				\
++	pop_msg.c				\
++	pop_parse.c				\
++	pop_pass.c				\
++	pop_quit.c				\
++	pop_rset.c				\
++	pop_send.c				\
++	pop_stat.c				\
++	pop_uidl.c				\
++	pop_updt.c				\
++	pop_user.c				\
++	pop_xover.c				\
++	popper.c				\
++	maildir.c				\
++	auth_gssapi.c				\
++	popper.h				\
++	version.h
++
++LDADD = \
++	$(LIB_otp) \
++	$(top_builddir)/lib/gssapi/libgssapi.la \
++	$(LIB_krb5) \
++	$(LIB_hcrypto) \
++	$(LIB_roken) \
++	$(DBLIB)
++
++man_MANS = popper.8
++EXTRA_DIST = pop3.rfc1081 pop3e.rfc1082 \
++	popper.README.release README-FIRST \
++	$(man_MANS)
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/popper/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/popper/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libexecPROGRAMS: $(libexec_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexecPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
++
++clean-libexecPROGRAMS:
++	@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++pop_debug$(EXEEXT): $(pop_debug_OBJECTS) $(pop_debug_DEPENDENCIES) 
++	@rm -f pop_debug$(EXEEXT)
++	$(LINK) $(pop_debug_OBJECTS) $(pop_debug_LDADD) $(LIBS)
++popper$(EXEEXT): $(popper_OBJECTS) $(popper_DEPENDENCIES) 
++	@rm -f popper$(EXEEXT)
++	$(LINK) $(popper_OBJECTS) $(popper_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/auth_gssapi.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/maildir.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_auth.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_debug.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_dele.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_dropcopy.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_dropinfo.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_get_command.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_init.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_last.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_list.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_log.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_msg.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_parse.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_pass.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_quit.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_rset.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_send.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_stat.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_uidl.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_updt.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_user.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pop_xover.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/popper.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(man8dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libexecPROGRAMS clean-libtool \
++	clean-noinstPROGRAMS mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libexecPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-libexecPROGRAMS uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libexecPROGRAMS clean-libtool \
++	clean-noinstPROGRAMS ctags dist-hook distclean \
++	distclean-compile distclean-generic distclean-libtool \
++	distclean-tags distdir dvi dvi-am html html-am info info-am \
++	install install-am install-data install-data-am \
++	install-data-hook install-dvi install-dvi-am install-exec \
++	install-exec-am install-exec-hook install-html install-html-am \
++	install-info install-info-am install-libexecPROGRAMS \
++	install-man install-man8 install-pdf install-pdf-am install-ps \
++	install-ps-am install-strip installcheck installcheck-am \
++	installdirs maintainer-clean maintainer-clean-generic \
++	mostlyclean mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags uninstall \
++	uninstall-am uninstall-hook uninstall-libexecPROGRAMS \
++	uninstall-man uninstall-man8
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/push/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/push/Makefile.in	2010-12-29 04:07:03.224189054 +0100
+@@ -0,0 +1,1033 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++libexec_PROGRAMS = push$(EXEEXT)
++subdir = appl/push
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(bindir)" \
++	"$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man8dir)"
++PROGRAMS = $(libexec_PROGRAMS)
++am_push_OBJECTS = push.$(OBJEXT)
++push_OBJECTS = $(am_push_OBJECTS)
++push_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++push_DEPENDENCIES = $(LIB_krb5) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++SCRIPTS = $(bin_SCRIPTS)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(push_SOURCES)
++DIST_SOURCES = $(push_SOURCES)
++man1dir = $(mandir)/man1
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_hesiod)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++bin_SCRIPTS = pfrom
++push_SOURCES = push.c push_locl.h
++man_MANS = push.8 pfrom.1
++CLEANFILES = pfrom
++EXTRA_DIST = pfrom.in $(man_MANS)
++LDADD = $(LIB_krb5) \
++	$(LIB_hcrypto) \
++	$(LIB_roken) \
++	$(LIB_hesiod)
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/push/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/push/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libexecPROGRAMS: $(libexec_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexecPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
++
++clean-libexecPROGRAMS:
++	@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++push$(EXEEXT): $(push_OBJECTS) $(push_DEPENDENCIES) 
++	@rm -f push$(EXEEXT)
++	$(LINK) $(push_OBJECTS) $(push_LDADD) $(LIBS)
++install-binSCRIPTS: $(bin_SCRIPTS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_SCRIPTS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  if test -f "$$d$$p"; then echo "$$d$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n' \
++	    -e 'h;s|.*|.|' \
++	    -e 'p;x;s,.*/,,;$(transform)' | sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1; } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) { files[d] = files[d] " " $$1; \
++	      if (++n[d] == $(am__install_max)) { \
++		print "f", d, files[d]; n[d] = 0; files[d] = "" } } \
++	    else { print "f", d "/" $$4, $$1 } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	     if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	     test -z "$$files" || { \
++	       echo " $(INSTALL_SCRIPT) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	       $(INSTALL_SCRIPT) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	     } \
++	; done
++
++uninstall-binSCRIPTS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_SCRIPTS)'; test -n "$(bindir)" || exit 0; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	       sed -e 's,.*/,,;$(transform)'`; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/push.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(SCRIPTS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man8dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libexecPROGRAMS clean-libtool \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binSCRIPTS install-libexecPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1 install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binSCRIPTS uninstall-libexecPROGRAMS \
++	uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1 uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libexecPROGRAMS clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-binSCRIPTS \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-libexecPROGRAMS install-man install-man1 install-man8 \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-compile mostlyclean-generic mostlyclean-libtool \
++	pdf pdf-am ps ps-am tags uninstall uninstall-am \
++	uninstall-binSCRIPTS uninstall-hook uninstall-libexecPROGRAMS \
++	uninstall-man uninstall-man1 uninstall-man8
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++pfrom: pfrom.in
++	sed -e "s!%libexecdir%!$(libexecdir)!" $(srcdir)/pfrom.in > $@
++	chmod +x $@
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/rcp/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/rcp/Makefile.in	2010-12-29 04:07:03.414248946 +0100
+@@ -0,0 +1,943 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++bin_PROGRAMS = rcp$(EXEEXT)
++subdir = appl/rcp
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)"
++PROGRAMS = $(bin_PROGRAMS)
++am_rcp_OBJECTS = rcp.$(OBJEXT) util.$(OBJEXT)
++rcp_OBJECTS = $(am_rcp_OBJECTS)
++rcp_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++rcp_DEPENDENCIES = $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(rcp_SOURCES)
++DIST_SOURCES = $(rcp_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man1dir = $(mandir)/man1
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_krb4)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++rcp_SOURCES = rcp.c util.c rcp_locl.h extern.h
++man_MANS = rcp.1
++EXTRA_DIST = $(man_MANS)
++LDADD = $(LIB_roken)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/rcp/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/rcp/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++rcp$(EXEEXT): $(rcp_OBJECTS) $(rcp_DEPENDENCIES) 
++	@rm -f rcp$(EXEEXT)
++	$(LINK) $(rcp_OBJECTS) $(rcp_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/rcp.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/util.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-binPROGRAMS \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-man install-man1 install-pdf install-pdf-am install-ps \
++	install-ps-am install-strip installcheck installcheck-am \
++	installdirs maintainer-clean maintainer-clean-generic \
++	mostlyclean mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags uninstall \
++	uninstall-am uninstall-binPROGRAMS uninstall-hook \
++	uninstall-man uninstall-man1
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/rsh/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/rsh/Makefile.in	2010-12-29 04:07:03.614311991 +0100
+@@ -0,0 +1,1058 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++bin_PROGRAMS = rsh$(EXEEXT)
++libexec_PROGRAMS = rshd$(EXEEXT)
++subdir = appl/rsh
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(libexecdir)" \
++	"$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man8dir)"
++PROGRAMS = $(bin_PROGRAMS) $(libexec_PROGRAMS)
++am_rsh_OBJECTS = rsh.$(OBJEXT) common.$(OBJEXT)
++rsh_OBJECTS = $(am_rsh_OBJECTS)
++rsh_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++am__DEPENDENCIES_2 = $(top_builddir)/lib/kafs/libkafs.la \
++	$(am__DEPENDENCIES_1)
++rsh_DEPENDENCIES = $(am__DEPENDENCIES_2) $(LIB_krb5) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++am_rshd_OBJECTS = rshd.$(OBJEXT) common.$(OBJEXT) \
++	login_access.$(OBJEXT) limits_conf.$(OBJEXT)
++rshd_OBJECTS = $(am_rshd_OBJECTS)
++rshd_LDADD = $(LDADD)
++rshd_DEPENDENCIES = $(am__DEPENDENCIES_2) $(LIB_krb5) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(rsh_SOURCES) $(rshd_SOURCES)
++DIST_SOURCES = $(rsh_SOURCES) $(rshd_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man1dir = $(mandir)/man1
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) -I$(srcdir)/../login \
++	$(INCLUDE_hcrypto)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++man_MANS = rsh.1 rshd.8
++rsh_SOURCES = rsh.c common.c rsh_locl.h
++rshd_SOURCES = rshd.c common.c login_access.c limits_conf.c rsh_locl.h
++LDADD = $(LIB_kafs) \
++	$(LIB_krb5) \
++	$(LIB_hcrypto) \
++	$(LIB_roken)
++
++EXTRA_DIST = $(man_MANS)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/rsh/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/rsh/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++install-libexecPROGRAMS: $(libexec_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexecPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
++
++clean-libexecPROGRAMS:
++	@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++rsh$(EXEEXT): $(rsh_OBJECTS) $(rsh_DEPENDENCIES) 
++	@rm -f rsh$(EXEEXT)
++	$(LINK) $(rsh_OBJECTS) $(rsh_LDADD) $(LIBS)
++rshd$(EXEEXT): $(rshd_OBJECTS) $(rshd_DEPENDENCIES) 
++	@rm -f rshd$(EXEEXT)
++	$(LINK) $(rshd_OBJECTS) $(rshd_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/common.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/limits_conf.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/login_access.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/rsh.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/rshd.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man8dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libexecPROGRAMS \
++	clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS install-libexecPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1 install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-libexecPROGRAMS \
++	uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1 uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libexecPROGRAMS \
++	clean-libtool ctags dist-hook distclean distclean-compile \
++	distclean-generic distclean-libtool distclean-tags distdir dvi \
++	dvi-am html html-am info info-am install install-am \
++	install-binPROGRAMS install-data install-data-am \
++	install-data-hook install-dvi install-dvi-am install-exec \
++	install-exec-am install-exec-hook install-html install-html-am \
++	install-info install-info-am install-libexecPROGRAMS \
++	install-man install-man1 install-man8 install-pdf \
++	install-pdf-am install-ps install-ps-am install-strip \
++	installcheck installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-binPROGRAMS \
++	uninstall-hook uninstall-libexecPROGRAMS uninstall-man \
++	uninstall-man1 uninstall-man8
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++login_access.c:
++	$(LN_S) $(srcdir)/../login/login_access.c .
++
++limits_conf.c:
++	$(LN_S) $(srcdir)/../login/limits_conf.c .
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/su/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/su/Makefile.in	2010-12-29 04:07:03.804371885 +0100
+@@ -0,0 +1,952 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++bin_PROGRAMS = su$(EXEEXT)
++subdir = appl/su
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)"
++PROGRAMS = $(bin_PROGRAMS)
++am_su_OBJECTS = su.$(OBJEXT)
++su_OBJECTS = $(am_su_OBJECTS)
++su_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++am__DEPENDENCIES_2 = $(top_builddir)/lib/kafs/libkafs.la \
++	$(am__DEPENDENCIES_1)
++su_DEPENDENCIES = $(am__DEPENDENCIES_2) \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(su_SOURCES)
++DIST_SOURCES = $(su_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man1dir = $(mandir)/man1
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_krb4) $(INCLUDE_hcrypto)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++bin_SUIDS = su
++su_SOURCES = su.c supaths.h
++man_MANS = su.1
++LDADD = $(LIB_kafs) \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_roken)
++
++EXTRA_DIST = $(man_MANS)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/su/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/su/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++su$(EXEEXT): $(su_OBJECTS) $(su_DEPENDENCIES) 
++	@rm -f su$(EXEEXT)
++	$(LINK) $(su_OBJECTS) $(su_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/su.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-binPROGRAMS \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-man install-man1 install-pdf install-pdf-am install-ps \
++	install-ps-am install-strip installcheck installcheck-am \
++	installdirs maintainer-clean maintainer-clean-generic \
++	mostlyclean mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags uninstall \
++	uninstall-am uninstall-binPROGRAMS uninstall-hook \
++	uninstall-man uninstall-man1
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/telnet/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/telnet/Makefile.in	2010-12-29 04:07:03.964422321 +0100
+@@ -0,0 +1,915 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++subdir = appl/telnet
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \
++	html-recursive info-recursive install-data-recursive \
++	install-dvi-recursive install-exec-recursive \
++	install-html-recursive install-info-recursive \
++	install-pdf-recursive install-ps-recursive install-recursive \
++	installcheck-recursive installdirs-recursive pdf-recursive \
++	ps-recursive uninstall-recursive
++RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive	\
++  distclean-recursive maintainer-clean-recursive
++AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \
++	$(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS \
++	distdir
++ETAGS = etags
++CTAGS = ctags
++DIST_SUBDIRS = $(SUBDIRS)
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++am__relativize = \
++  dir0=`pwd`; \
++  sed_first='s,^\([^/]*\)/.*$$,\1,'; \
++  sed_rest='s,^[^/]*/*,,'; \
++  sed_last='s,^.*/\([^/]*\)$$,\1,'; \
++  sed_butlast='s,/*[^/]*$$,,'; \
++  while test -n "$$dir1"; do \
++    first=`echo "$$dir1" | sed -e "$$sed_first"`; \
++    if test "$$first" != "."; then \
++      if test "$$first" = ".."; then \
++        dir2=`echo "$$dir0" | sed -e "$$sed_last"`/"$$dir2"; \
++        dir0=`echo "$$dir0" | sed -e "$$sed_butlast"`; \
++      else \
++        first2=`echo "$$dir2" | sed -e "$$sed_first"`; \
++        if test "$$first2" = "$$first"; then \
++          dir2=`echo "$$dir2" | sed -e "$$sed_rest"`; \
++        else \
++          dir2="../$$dir2"; \
++        fi; \
++        dir0="$$dir0"/"$$first"; \
++      fi; \
++    fi; \
++    dir1=`echo "$$dir1" | sed -e "$$sed_rest"`; \
++  done; \
++  reldir="$$dir2"
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++SUBDIRS = libtelnet telnet telnetd
++EXTRA_DIST = README.ORIG telnet.state
++all: all-recursive
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/telnet/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/telnet/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++# This directory's subdirectories are mostly independent; you can cd
++# into them and run `make' without going through this Makefile.
++# To change the values of `make' variables: instead of editing Makefiles,
++# (1) if the variable is set in `config.status', edit `config.status'
++#     (which will cause the Makefiles to be regenerated when you run `make');
++# (2) otherwise, pass the desired values on the `make' command line.
++$(RECURSIVE_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	target=`echo $@ | sed s/-recursive//`; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    dot_seen=yes; \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done; \
++	if test "$$dot_seen" = "no"; then \
++	  $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
++	fi; test -z "$$fail"
++
++$(RECURSIVE_CLEAN_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	case "$@" in \
++	  distclean-* | maintainer-clean-*) list='$(DIST_SUBDIRS)' ;; \
++	  *) list='$(SUBDIRS)' ;; \
++	esac; \
++	rev=''; for subdir in $$list; do \
++	  if test "$$subdir" = "."; then :; else \
++	    rev="$$subdir $$rev"; \
++	  fi; \
++	done; \
++	rev="$$rev ."; \
++	target=`echo $@ | sed s/-recursive//`; \
++	for subdir in $$rev; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done && test -z "$$fail"
++tags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
++	done
++ctags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) ctags); \
++	done
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS: tags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	if ($(ETAGS) --etags-include --version) >/dev/null 2>&1; then \
++	  include_option=--etags-include; \
++	  empty_fix=.; \
++	else \
++	  include_option=--include; \
++	  empty_fix=; \
++	fi; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test ! -f $$subdir/TAGS || \
++	      set "$$@" "$$include_option=$$here/$$subdir/TAGS"; \
++	  fi; \
++	done; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS: ctags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test -d "$(distdir)/$$subdir" \
++	    || $(MKDIR_P) "$(distdir)/$$subdir" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    dir1=$$subdir; dir2="$(distdir)/$$subdir"; \
++	    $(am__relativize); \
++	    new_distdir=$$reldir; \
++	    dir1=$$subdir; dir2="$(top_distdir)"; \
++	    $(am__relativize); \
++	    new_top_distdir=$$reldir; \
++	    echo " (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir="$$new_top_distdir" distdir="$$new_distdir" \\"; \
++	    echo "     am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)"; \
++	    ($(am__cd) $$subdir && \
++	      $(MAKE) $(AM_MAKEFLAGS) \
++	        top_distdir="$$new_top_distdir" \
++	        distdir="$$new_distdir" \
++		am__remove_distdir=: \
++		am__skip_length_check=: \
++		am__skip_mode_fix=: \
++	        distdir) \
++	      || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-recursive
++all-am: Makefile all-local
++installdirs: installdirs-recursive
++installdirs-am:
++install: install-recursive
++install-exec: install-exec-recursive
++install-data: install-data-recursive
++uninstall: uninstall-recursive
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-recursive
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-recursive
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-recursive
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic distclean-tags
++
++dvi: dvi-recursive
++
++dvi-am:
++
++html: html-recursive
++
++html-am:
++
++info: info-recursive
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-recursive
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-recursive
++
++install-html-am:
++
++install-info: install-info-recursive
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-recursive
++
++install-pdf-am:
++
++install-ps: install-ps-recursive
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-recursive
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-recursive
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-recursive
++
++pdf-am:
++
++ps: ps-recursive
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) check-am \
++	ctags-recursive install-am install-data-am install-exec-am \
++	install-strip tags-recursive uninstall-am
++
++.PHONY: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) CTAGS GTAGS \
++	all all-am all-local check check-am check-local clean \
++	clean-generic clean-libtool ctags ctags-recursive dist-hook \
++	distclean distclean-generic distclean-libtool distclean-tags \
++	distdir dvi dvi-am html html-am info info-am install \
++	install-am install-data install-data-am install-data-hook \
++	install-dvi install-dvi-am install-exec install-exec-am \
++	install-exec-hook install-html install-html-am install-info \
++	install-info-am install-man install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs installdirs-am maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags tags-recursive \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++dist-hook:
++	$(mkinstalldirs) $(distdir)/arpa
++	$(INSTALL_DATA) $(srcdir)/arpa/telnet.h $(distdir)/arpa
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/telnet/libtelnet/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/telnet/libtelnet/Makefile.in	2010-12-29 04:07:04.144479008 +0100
+@@ -0,0 +1,840 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = appl/telnet/libtelnet
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++LIBRARIES = $(noinst_LIBRARIES)
++ARFLAGS = cru
++libtelnet_a_AR = $(AR) $(ARFLAGS)
++libtelnet_a_LIBADD =
++am_libtelnet_a_OBJECTS = auth.$(OBJEXT) enc_des.$(OBJEXT) \
++	encrypt.$(OBJEXT) genget.$(OBJEXT) kerberos5.$(OBJEXT) \
++	misc.$(OBJEXT)
++libtelnet_a_OBJECTS = $(am_libtelnet_a_OBJECTS)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(libtelnet_a_SOURCES)
++DIST_SOURCES = $(libtelnet_a_SOURCES)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) -I$(srcdir)/.. $(INCLUDE_hcrypto)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++noinst_LIBRARIES = libtelnet.a
++libtelnet_a_SOURCES = \
++	auth-proto.h	\
++	auth.c		\
++	auth.h		\
++	enc-proto.h	\
++	enc_des.c	\
++	encrypt.c	\
++	encrypt.h	\
++	genget.c	\
++	kerberos5.c	\
++	misc-proto.h	\
++	misc.c		\
++	misc.h
++
++EXTRA_DIST = rsaencpwd.c spx.c
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/telnet/libtelnet/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/telnet/libtelnet/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++clean-noinstLIBRARIES:
++	-test -z "$(noinst_LIBRARIES)" || rm -f $(noinst_LIBRARIES)
++libtelnet.a: $(libtelnet_a_OBJECTS) $(libtelnet_a_DEPENDENCIES) 
++	-rm -f libtelnet.a
++	$(libtelnet_a_AR) libtelnet.a $(libtelnet_a_OBJECTS) $(libtelnet_a_LIBADD)
++	$(RANLIB) libtelnet.a
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/auth.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/enc_des.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/encrypt.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/genget.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kerberos5.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/misc.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(LIBRARIES) all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool clean-noinstLIBRARIES \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libtool clean-noinstLIBRARIES ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-compile mostlyclean-generic mostlyclean-libtool \
++	pdf pdf-am ps ps-am tags uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/telnet/telnet/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/telnet/telnet/Makefile.in	2010-12-29 04:07:04.344541975 +0100
+@@ -0,0 +1,965 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++bin_PROGRAMS = telnet$(EXEEXT)
++subdir = appl/telnet/telnet
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)"
++PROGRAMS = $(bin_PROGRAMS)
++am_telnet_OBJECTS = authenc.$(OBJEXT) commands.$(OBJEXT) \
++	main.$(OBJEXT) network.$(OBJEXT) ring.$(OBJEXT) \
++	sys_bsd.$(OBJEXT) telnet.$(OBJEXT) terminal.$(OBJEXT) \
++	utilities.$(OBJEXT)
++telnet_OBJECTS = $(am_telnet_OBJECTS)
++telnet_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++telnet_DEPENDENCIES = ../libtelnet/libtelnet.a $(LIB_krb5) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) $(LIB_kdfs) \
++	$(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(telnet_SOURCES)
++DIST_SOURCES = $(telnet_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man1dir = $(mandir)/man1
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) -I$(srcdir)/.. $(INCLUDE_hcrypto)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++CHECK_LOCAL = 
++telnet_SOURCES = authenc.c commands.c main.c network.c ring.c \
++		  sys_bsd.c telnet.c terminal.c \
++		  utilities.c defines.h externs.h ring.h telnet_locl.h types.h
++
++man_MANS = telnet.1
++LDADD = ../libtelnet/libtelnet.a \
++	$(LIB_krb5) \
++	$(LIB_hcrypto) \
++	$(LIB_tgetent) \
++	$(LIB_kdfs) \
++	$(LIB_roken)
++
++EXTRA_DIST = $(man_MANS)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/telnet/telnet/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/telnet/telnet/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++telnet$(EXEEXT): $(telnet_OBJECTS) $(telnet_DEPENDENCIES) 
++	@rm -f telnet$(EXEEXT)
++	$(LINK) $(telnet_OBJECTS) $(telnet_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/authenc.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/commands.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/main.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/network.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ring.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/sys_bsd.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/telnet.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/terminal.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/utilities.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-binPROGRAMS \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-man install-man1 install-pdf install-pdf-am install-ps \
++	install-ps-am install-strip installcheck installcheck-am \
++	installdirs maintainer-clean maintainer-clean-generic \
++	mostlyclean mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags uninstall \
++	uninstall-am uninstall-binPROGRAMS uninstall-hook \
++	uninstall-man uninstall-man1
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/telnet/telnetd/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/telnet/telnetd/Makefile.in	2010-12-29 04:07:04.544604943 +0100
+@@ -0,0 +1,968 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++libexec_PROGRAMS = telnetd$(EXEEXT)
++subdir = appl/telnet/telnetd
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(man8dir)"
++PROGRAMS = $(libexec_PROGRAMS)
++am_telnetd_OBJECTS = telnetd.$(OBJEXT) state.$(OBJEXT) \
++	termstat.$(OBJEXT) slc.$(OBJEXT) sys_term.$(OBJEXT) \
++	utility.$(OBJEXT) global.$(OBJEXT) authenc.$(OBJEXT)
++telnetd_OBJECTS = $(am_telnetd_OBJECTS)
++telnetd_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++telnetd_DEPENDENCIES = ../libtelnet/libtelnet.a $(LIB_krb5) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(LIB_kdfs) $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(telnetd_SOURCES)
++DIST_SOURCES = $(telnetd_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) -I$(srcdir)/.. $(INCLUDE_hcrypto)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++CHECK_LOCAL = 
++telnetd_SOURCES = telnetd.c state.c termstat.c slc.c sys_term.c \
++		   utility.c global.c authenc.c defs.h ext.h telnetd.h
++
++man_MANS = telnetd.8
++LDADD = \
++	../libtelnet/libtelnet.a \
++	$(LIB_krb5) \
++	$(LIB_hcrypto) \
++	$(LIB_tgetent) \
++	$(LIB_logwtmp) \
++	$(LIB_logout) \
++	$(LIB_openpty) \
++	$(LIB_kdfs) \
++	$(LIB_roken)
++
++EXTRA_DIST = $(man_MANS)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/telnet/telnetd/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/telnet/telnetd/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libexecPROGRAMS: $(libexec_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexecPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
++
++clean-libexecPROGRAMS:
++	@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++telnetd$(EXEEXT): $(telnetd_OBJECTS) $(telnetd_DEPENDENCIES) 
++	@rm -f telnetd$(EXEEXT)
++	$(LINK) $(telnetd_OBJECTS) $(telnetd_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/authenc.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/global.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/slc.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/state.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/sys_term.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/telnetd.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/termstat.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/utility.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(man8dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libexecPROGRAMS clean-libtool \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libexecPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-libexecPROGRAMS uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libexecPROGRAMS clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am \
++	install-libexecPROGRAMS install-man install-man8 install-pdf \
++	install-pdf-am install-ps install-ps-am install-strip \
++	installcheck installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-hook \
++	uninstall-libexecPROGRAMS uninstall-man uninstall-man8
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/test/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/test/Makefile.in	2010-12-29 04:07:04.774677354 +0100
+@@ -0,0 +1,942 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++noinst_PROGRAMS = tcp_client$(EXEEXT) tcp_server$(EXEEXT) \
++	gssapi_server$(EXEEXT) gssapi_client$(EXEEXT) \
++	uu_server$(EXEEXT) uu_client$(EXEEXT) nt_gss_server$(EXEEXT) \
++	nt_gss_client$(EXEEXT) http_client$(EXEEXT)
++subdir = appl/test
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++PROGRAMS = $(noinst_PROGRAMS)
++am_gssapi_client_OBJECTS = gssapi_client.$(OBJEXT) \
++	gss_common.$(OBJEXT) common.$(OBJEXT)
++gssapi_client_OBJECTS = $(am_gssapi_client_OBJECTS)
++am__DEPENDENCIES_1 =
++am__DEPENDENCIES_2 = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1)
++am__DEPENDENCIES_3 = $(top_builddir)/lib/gssapi/libgssapi.la \
++	$(am__DEPENDENCIES_2)
++gssapi_client_DEPENDENCIES = $(am__DEPENDENCIES_3)
++am_gssapi_server_OBJECTS = gssapi_server.$(OBJEXT) \
++	gss_common.$(OBJEXT) common.$(OBJEXT)
++gssapi_server_OBJECTS = $(am_gssapi_server_OBJECTS)
++gssapi_server_DEPENDENCIES = $(top_builddir)/lib/gssapi/libgssapi.la \
++	$(am__DEPENDENCIES_2)
++am_http_client_OBJECTS = http_client.$(OBJEXT) gss_common.$(OBJEXT) \
++	common.$(OBJEXT)
++http_client_OBJECTS = $(am_http_client_OBJECTS)
++http_client_DEPENDENCIES = $(top_builddir)/lib/gssapi/libgssapi.la \
++	$(am__DEPENDENCIES_2)
++am_nt_gss_client_OBJECTS = nt_gss_client.$(OBJEXT) \
++	nt_gss_common.$(OBJEXT) common.$(OBJEXT)
++nt_gss_client_OBJECTS = $(am_nt_gss_client_OBJECTS)
++nt_gss_client_DEPENDENCIES = $(am__DEPENDENCIES_3)
++am_nt_gss_server_OBJECTS = nt_gss_server.$(OBJEXT) \
++	nt_gss_common.$(OBJEXT)
++nt_gss_server_OBJECTS = $(am_nt_gss_server_OBJECTS)
++am__DEPENDENCIES_4 = $(am__DEPENDENCIES_3)
++nt_gss_server_DEPENDENCIES = $(am__DEPENDENCIES_4)
++am_tcp_client_OBJECTS = tcp_client.$(OBJEXT) common.$(OBJEXT)
++tcp_client_OBJECTS = $(am_tcp_client_OBJECTS)
++tcp_client_LDADD = $(LDADD)
++tcp_client_DEPENDENCIES = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1)
++am_tcp_server_OBJECTS = tcp_server.$(OBJEXT) common.$(OBJEXT)
++tcp_server_OBJECTS = $(am_tcp_server_OBJECTS)
++tcp_server_LDADD = $(LDADD)
++tcp_server_DEPENDENCIES = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1)
++am_uu_client_OBJECTS = uu_client.$(OBJEXT) common.$(OBJEXT)
++uu_client_OBJECTS = $(am_uu_client_OBJECTS)
++uu_client_LDADD = $(LDADD)
++uu_client_DEPENDENCIES = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1)
++am_uu_server_OBJECTS = uu_server.$(OBJEXT) common.$(OBJEXT)
++uu_server_OBJECTS = $(am_uu_server_OBJECTS)
++uu_server_LDADD = $(LDADD)
++uu_server_DEPENDENCIES = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(gssapi_client_SOURCES) $(gssapi_server_SOURCES) \
++	$(http_client_SOURCES) $(nt_gss_client_SOURCES) \
++	$(nt_gss_server_SOURCES) $(tcp_client_SOURCES) \
++	$(tcp_server_SOURCES) $(uu_client_SOURCES) \
++	$(uu_server_SOURCES)
++DIST_SOURCES = $(gssapi_client_SOURCES) $(gssapi_server_SOURCES) \
++	$(http_client_SOURCES) $(nt_gss_client_SOURCES) \
++	$(nt_gss_server_SOURCES) $(tcp_client_SOURCES) \
++	$(tcp_server_SOURCES) $(uu_client_SOURCES) \
++	$(uu_server_SOURCES)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++tcp_client_SOURCES = tcp_client.c common.c test_locl.h
++tcp_server_SOURCES = tcp_server.c common.c test_locl.h
++gssapi_server_SOURCES = gssapi_server.c gss_common.c common.c \
++	gss_common.h test_locl.h
++
++gssapi_client_SOURCES = gssapi_client.c gss_common.c common.c \
++	gss_common.h test_locl.h
++
++http_client_SOURCES = http_client.c gss_common.c common.c \
++	gss_common.h test_locl.h
++
++uu_server_SOURCES = uu_server.c common.c test_locl.h
++uu_client_SOURCES = uu_client.c common.c test_locl.h
++gssapi_server_LDADD = $(top_builddir)/lib/gssapi/libgssapi.la $(LDADD)
++gssapi_client_LDADD = $(gssapi_server_LDADD)
++http_client_LDADD = $(top_builddir)/lib/gssapi/libgssapi.la $(LDADD)
++nt_gss_client_SOURCES = nt_gss_client.c nt_gss_common.c nt_gss_common.h common.c
++nt_gss_server_SOURCES = nt_gss_server.c nt_gss_common.c nt_gss_common.h
++nt_gss_client_LDADD = $(gssapi_server_LDADD)
++nt_gss_server_LDADD = $(nt_gss_client_LDADD)
++LDADD = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_roken)
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/test/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/test/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++gssapi_client$(EXEEXT): $(gssapi_client_OBJECTS) $(gssapi_client_DEPENDENCIES) 
++	@rm -f gssapi_client$(EXEEXT)
++	$(LINK) $(gssapi_client_OBJECTS) $(gssapi_client_LDADD) $(LIBS)
++gssapi_server$(EXEEXT): $(gssapi_server_OBJECTS) $(gssapi_server_DEPENDENCIES) 
++	@rm -f gssapi_server$(EXEEXT)
++	$(LINK) $(gssapi_server_OBJECTS) $(gssapi_server_LDADD) $(LIBS)
++http_client$(EXEEXT): $(http_client_OBJECTS) $(http_client_DEPENDENCIES) 
++	@rm -f http_client$(EXEEXT)
++	$(LINK) $(http_client_OBJECTS) $(http_client_LDADD) $(LIBS)
++nt_gss_client$(EXEEXT): $(nt_gss_client_OBJECTS) $(nt_gss_client_DEPENDENCIES) 
++	@rm -f nt_gss_client$(EXEEXT)
++	$(LINK) $(nt_gss_client_OBJECTS) $(nt_gss_client_LDADD) $(LIBS)
++nt_gss_server$(EXEEXT): $(nt_gss_server_OBJECTS) $(nt_gss_server_DEPENDENCIES) 
++	@rm -f nt_gss_server$(EXEEXT)
++	$(LINK) $(nt_gss_server_OBJECTS) $(nt_gss_server_LDADD) $(LIBS)
++tcp_client$(EXEEXT): $(tcp_client_OBJECTS) $(tcp_client_DEPENDENCIES) 
++	@rm -f tcp_client$(EXEEXT)
++	$(LINK) $(tcp_client_OBJECTS) $(tcp_client_LDADD) $(LIBS)
++tcp_server$(EXEEXT): $(tcp_server_OBJECTS) $(tcp_server_DEPENDENCIES) 
++	@rm -f tcp_server$(EXEEXT)
++	$(LINK) $(tcp_server_OBJECTS) $(tcp_server_LDADD) $(LIBS)
++uu_client$(EXEEXT): $(uu_client_OBJECTS) $(uu_client_DEPENDENCIES) 
++	@rm -f uu_client$(EXEEXT)
++	$(LINK) $(uu_client_OBJECTS) $(uu_client_LDADD) $(LIBS)
++uu_server$(EXEEXT): $(uu_server_OBJECTS) $(uu_server_DEPENDENCIES) 
++	@rm -f uu_server$(EXEEXT)
++	$(LINK) $(uu_server_OBJECTS) $(uu_server_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/common.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gss_common.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gssapi_client.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gssapi_server.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/http_client.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/nt_gss_client.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/nt_gss_common.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/nt_gss_server.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/tcp_client.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/tcp_server.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/uu_client.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/uu_server.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool clean-noinstPROGRAMS \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libtool clean-noinstPROGRAMS ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-compile mostlyclean-generic mostlyclean-libtool \
++	pdf pdf-am ps ps-am tags uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/appl/xnlock/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/appl/xnlock/Makefile.in	2010-12-29 04:07:04.984743472 +0100
+@@ -0,0 +1,955 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = README $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++@HAVE_X_TRUE@bin_PROGRAMS = xnlock$(EXEEXT)
++subdir = appl/xnlock
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)"
++PROGRAMS = $(bin_PROGRAMS)
++xnlock_SOURCES = xnlock.c
++xnlock_OBJECTS = xnlock.$(OBJEXT)
++xnlock_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++am__DEPENDENCIES_2 = $(top_builddir)/lib/kafs/libkafs.la \
++	$(am__DEPENDENCIES_1)
++xnlock_DEPENDENCIES = $(am__DEPENDENCIES_2) $(LIB_krb5) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = xnlock.c
++DIST_SOURCES = xnlock.c
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man1dir = $(mandir)/man1
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@ $(WFLAGS_NOIMPLICITINT)
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(X_CFLAGS)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++CHECK_LOCAL = no-check-local
++man_MANS = xnlock.1
++EXTRA_DIST = $(man_MANS) nose.0.left nose.0.right nose.1.left nose.1.right \
++	nose.down nose.front nose.left.front nose.right.front
++
++LDADD = \
++	$(LIB_kafs) \
++	$(LIB_krb5) \
++	$(LIB_hcrypto) \
++	$(LIB_roken) \
++	$(X_LIBS) -lXt $(X_PRE_LIBS) -lX11 $(X_EXTRA_LIBS)
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign appl/xnlock/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign appl/xnlock/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++xnlock$(EXEEXT): $(xnlock_OBJECTS) $(xnlock_DEPENDENCIES) 
++	@rm -f xnlock$(EXEEXT)
++	$(LINK) $(xnlock_OBJECTS) $(xnlock_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/xnlock.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-binPROGRAMS \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-man install-man1 install-pdf install-pdf-am install-ps \
++	install-ps-am install-strip installcheck installcheck-am \
++	installdirs maintainer-clean maintainer-clean-generic \
++	mostlyclean mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags uninstall \
++	uninstall-am uninstall-binPROGRAMS uninstall-hook \
++	uninstall-man uninstall-man1
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/cf/libtool.m4
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/cf/libtool.m4	2010-12-29 04:06:55.851854332 +0100
+@@ -0,0 +1,7377 @@
++# libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-
++#
++#   Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
++#                 2006, 2007, 2008 Free Software Foundation, Inc.
++#   Written by Gordon Matzigkeit, 1996
++#
++# This file is free software; the Free Software Foundation gives
++# unlimited permission to copy and/or distribute it, with or without
++# modifications, as long as this notice is preserved.
++
++m4_define([_LT_COPYING], [dnl
++#   Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
++#                 2006, 2007, 2008 Free Software Foundation, Inc.
++#   Written by Gordon Matzigkeit, 1996
++#
++#   This file is part of GNU Libtool.
++#
++# GNU Libtool is free software; you can redistribute it and/or
++# modify it under the terms of the GNU General Public License as
++# published by the Free Software Foundation; either version 2 of
++# the License, or (at your option) any later version.
++#
++# As a special exception to the GNU General Public License,
++# if you distribute this file as part of a program or library that
++# is built using GNU Libtool, you may include this file under the
++# same distribution terms that you use for the rest of that program.
++#
++# GNU Libtool is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY; without even the implied warranty of
++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++# GNU General Public License for more details.
++#
++# You should have received a copy of the GNU General Public License
++# along with GNU Libtool; see the file COPYING.  If not, a copy
++# can be downloaded from http://www.gnu.org/licenses/gpl.html, or
++# obtained by writing to the Free Software Foundation, Inc.,
++# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
++])
++
++# serial 56 LT_INIT
++
++
++# LT_PREREQ(VERSION)
++# ------------------
++# Complain and exit if this libtool version is less that VERSION.
++m4_defun([LT_PREREQ],
++[m4_if(m4_version_compare(m4_defn([LT_PACKAGE_VERSION]), [$1]), -1,
++       [m4_default([$3],
++		   [m4_fatal([Libtool version $1 or higher is required],
++		             63)])],
++       [$2])])
++
++
++# _LT_CHECK_BUILDDIR
++# ------------------
++# Complain if the absolute build directory name contains unusual characters
++m4_defun([_LT_CHECK_BUILDDIR],
++[case `pwd` in
++  *\ * | *\	*)
++    AC_MSG_WARN([Libtool does not cope well with whitespace in `pwd`]) ;;
++esac
++])
++
++
++# LT_INIT([OPTIONS])
++# ------------------
++AC_DEFUN([LT_INIT],
++[AC_PREREQ([2.58])dnl We use AC_INCLUDES_DEFAULT
++AC_BEFORE([$0], [LT_LANG])dnl
++AC_BEFORE([$0], [LT_OUTPUT])dnl
++AC_BEFORE([$0], [LTDL_INIT])dnl
++m4_require([_LT_CHECK_BUILDDIR])dnl
++
++dnl Autoconf doesn't catch unexpanded LT_ macros by default:
++m4_pattern_forbid([^_?LT_[A-Z_]+$])dnl
++m4_pattern_allow([^(_LT_EOF|LT_DLGLOBAL|LT_DLLAZY_OR_NOW|LT_MULTI_MODULE)$])dnl
++dnl aclocal doesn't pull ltoptions.m4, ltsugar.m4, or ltversion.m4
++dnl unless we require an AC_DEFUNed macro:
++AC_REQUIRE([LTOPTIONS_VERSION])dnl
++AC_REQUIRE([LTSUGAR_VERSION])dnl
++AC_REQUIRE([LTVERSION_VERSION])dnl
++AC_REQUIRE([LTOBSOLETE_VERSION])dnl
++m4_require([_LT_PROG_LTMAIN])dnl
++
++dnl Parse OPTIONS
++_LT_SET_OPTIONS([$0], [$1])
++
++# This can be used to rebuild libtool when needed
++LIBTOOL_DEPS="$ltmain"
++
++# Always use our own libtool.
++LIBTOOL='$(SHELL) $(top_builddir)/libtool'
++AC_SUBST(LIBTOOL)dnl
++
++_LT_SETUP
++
++# Only expand once:
++m4_define([LT_INIT])
++])# LT_INIT
++
++# Old names:
++AU_ALIAS([AC_PROG_LIBTOOL], [LT_INIT])
++AU_ALIAS([AM_PROG_LIBTOOL], [LT_INIT])
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AC_PROG_LIBTOOL], [])
++dnl AC_DEFUN([AM_PROG_LIBTOOL], [])
++
++
++# _LT_CC_BASENAME(CC)
++# -------------------
++# Calculate cc_basename.  Skip known compiler wrappers and cross-prefix.
++m4_defun([_LT_CC_BASENAME],
++[for cc_temp in $1""; do
++  case $cc_temp in
++    compile | *[[\\/]]compile | ccache | *[[\\/]]ccache ) ;;
++    distcc | *[[\\/]]distcc | purify | *[[\\/]]purify ) ;;
++    \-*) ;;
++    *) break;;
++  esac
++done
++cc_basename=`$ECHO "X$cc_temp" | $Xsed -e 's%.*/%%' -e "s%^$host_alias-%%"`
++])
++
++
++# _LT_FILEUTILS_DEFAULTS
++# ----------------------
++# It is okay to use these file commands and assume they have been set
++# sensibly after `m4_require([_LT_FILEUTILS_DEFAULTS])'.
++m4_defun([_LT_FILEUTILS_DEFAULTS],
++[: ${CP="cp -f"}
++: ${MV="mv -f"}
++: ${RM="rm -f"}
++])# _LT_FILEUTILS_DEFAULTS
++
++
++# _LT_SETUP
++# ---------
++m4_defun([_LT_SETUP],
++[AC_REQUIRE([AC_CANONICAL_HOST])dnl
++AC_REQUIRE([AC_CANONICAL_BUILD])dnl
++_LT_DECL([], [host_alias], [0], [The host system])dnl
++_LT_DECL([], [host], [0])dnl
++_LT_DECL([], [host_os], [0])dnl
++dnl
++_LT_DECL([], [build_alias], [0], [The build system])dnl
++_LT_DECL([], [build], [0])dnl
++_LT_DECL([], [build_os], [0])dnl
++dnl
++AC_REQUIRE([AC_PROG_CC])dnl
++AC_REQUIRE([LT_PATH_LD])dnl
++AC_REQUIRE([LT_PATH_NM])dnl
++dnl
++AC_REQUIRE([AC_PROG_LN_S])dnl
++test -z "$LN_S" && LN_S="ln -s"
++_LT_DECL([], [LN_S], [1], [Whether we need soft or hard links])dnl
++dnl
++AC_REQUIRE([LT_CMD_MAX_LEN])dnl
++_LT_DECL([objext], [ac_objext], [0], [Object file suffix (normally "o")])dnl
++_LT_DECL([], [exeext], [0], [Executable file suffix (normally "")])dnl
++dnl
++m4_require([_LT_FILEUTILS_DEFAULTS])dnl
++m4_require([_LT_CHECK_SHELL_FEATURES])dnl
++m4_require([_LT_CMD_RELOAD])dnl
++m4_require([_LT_CHECK_MAGIC_METHOD])dnl
++m4_require([_LT_CMD_OLD_ARCHIVE])dnl
++m4_require([_LT_CMD_GLOBAL_SYMBOLS])dnl
++
++_LT_CONFIG_LIBTOOL_INIT([
++# See if we are running on zsh, and set the options which allow our
++# commands through without removal of \ escapes INIT.
++if test -n "\${ZSH_VERSION+set}" ; then
++   setopt NO_GLOB_SUBST
++fi
++])
++if test -n "${ZSH_VERSION+set}" ; then
++   setopt NO_GLOB_SUBST
++fi
++
++_LT_CHECK_OBJDIR
++
++m4_require([_LT_TAG_COMPILER])dnl
++_LT_PROG_ECHO_BACKSLASH
++
++case $host_os in
++aix3*)
++  # AIX sometimes has problems with the GCC collect2 program.  For some
++  # reason, if we set the COLLECT_NAMES environment variable, the problems
++  # vanish in a puff of smoke.
++  if test "X${COLLECT_NAMES+set}" != Xset; then
++    COLLECT_NAMES=
++    export COLLECT_NAMES
++  fi
++  ;;
++esac
++
++# Sed substitution that helps us do robust quoting.  It backslashifies
++# metacharacters that are still active within double-quoted strings.
++sed_quote_subst='s/\([["`$\\]]\)/\\\1/g'
++
++# Same as above, but do not quote variable references.
++double_quote_subst='s/\([["`\\]]\)/\\\1/g'
++
++# Sed substitution to delay expansion of an escaped shell variable in a
++# double_quote_subst'ed string.
++delay_variable_subst='s/\\\\\\\\\\\$/\\\\\\$/g'
++
++# Sed substitution to delay expansion of an escaped single quote.
++delay_single_quote_subst='s/'\''/'\'\\\\\\\'\''/g'
++
++# Sed substitution to avoid accidental globbing in evaled expressions
++no_glob_subst='s/\*/\\\*/g'
++
++# Global variables:
++ofile=libtool
++can_build_shared=yes
++
++# All known linkers require a `.a' archive for static linking (except MSVC,
++# which needs '.lib').
++libext=a
++
++with_gnu_ld="$lt_cv_prog_gnu_ld"
++
++old_CC="$CC"
++old_CFLAGS="$CFLAGS"
++
++# Set sane defaults for various variables
++test -z "$CC" && CC=cc
++test -z "$LTCC" && LTCC=$CC
++test -z "$LTCFLAGS" && LTCFLAGS=$CFLAGS
++test -z "$LD" && LD=ld
++test -z "$ac_objext" && ac_objext=o
++
++_LT_CC_BASENAME([$compiler])
++
++# Only perform the check for file, if the check method requires it
++test -z "$MAGIC_CMD" && MAGIC_CMD=file
++case $deplibs_check_method in
++file_magic*)
++  if test "$file_magic_cmd" = '$MAGIC_CMD'; then
++    _LT_PATH_MAGIC
++  fi
++  ;;
++esac
++
++# Use C for the default configuration in the libtool script
++LT_SUPPORTED_TAG([CC])
++_LT_LANG_C_CONFIG
++_LT_LANG_DEFAULT_CONFIG
++_LT_CONFIG_COMMANDS
++])# _LT_SETUP
++
++
++# _LT_PROG_LTMAIN
++# ---------------
++# Note that this code is called both from `configure', and `config.status'
++# now that we use AC_CONFIG_COMMANDS to generate libtool.  Notably,
++# `config.status' has no value for ac_aux_dir unless we are using Automake,
++# so we pass a copy along to make sure it has a sensible value anyway.
++m4_defun([_LT_PROG_LTMAIN],
++[m4_ifdef([AC_REQUIRE_AUX_FILE], [AC_REQUIRE_AUX_FILE([ltmain.sh])])dnl
++_LT_CONFIG_LIBTOOL_INIT([ac_aux_dir='$ac_aux_dir'])
++ltmain="$ac_aux_dir/ltmain.sh"
++])# _LT_PROG_LTMAIN
++
++
++## ------------------------------------- ##
++## Accumulate code for creating libtool. ##
++## ------------------------------------- ##
++
++# So that we can recreate a full libtool script including additional
++# tags, we accumulate the chunks of code to send to AC_CONFIG_COMMANDS
++# in macros and then make a single call at the end using the `libtool'
++# label.
++
++
++# _LT_CONFIG_LIBTOOL_INIT([INIT-COMMANDS])
++# ----------------------------------------
++# Register INIT-COMMANDS to be passed to AC_CONFIG_COMMANDS later.
++m4_define([_LT_CONFIG_LIBTOOL_INIT],
++[m4_ifval([$1],
++          [m4_append([_LT_OUTPUT_LIBTOOL_INIT],
++                     [$1
++])])])
++
++# Initialize.
++m4_define([_LT_OUTPUT_LIBTOOL_INIT])
++
++
++# _LT_CONFIG_LIBTOOL([COMMANDS])
++# ------------------------------
++# Register COMMANDS to be passed to AC_CONFIG_COMMANDS later.
++m4_define([_LT_CONFIG_LIBTOOL],
++[m4_ifval([$1],
++          [m4_append([_LT_OUTPUT_LIBTOOL_COMMANDS],
++                     [$1
++])])])
++
++# Initialize.
++m4_define([_LT_OUTPUT_LIBTOOL_COMMANDS])
++
++
++# _LT_CONFIG_SAVE_COMMANDS([COMMANDS], [INIT_COMMANDS])
++# -----------------------------------------------------
++m4_defun([_LT_CONFIG_SAVE_COMMANDS],
++[_LT_CONFIG_LIBTOOL([$1])
++_LT_CONFIG_LIBTOOL_INIT([$2])
++])
++
++
++# _LT_FORMAT_COMMENT([COMMENT])
++# -----------------------------
++# Add leading comment marks to the start of each line, and a trailing
++# full-stop to the whole comment if one is not present already.
++m4_define([_LT_FORMAT_COMMENT],
++[m4_ifval([$1], [
++m4_bpatsubst([m4_bpatsubst([$1], [^ *], [# ])],
++              [['`$\]], [\\\&])]m4_bmatch([$1], [[!?.]$], [], [.])
++)])
++
++
++
++## ------------------------ ##
++## FIXME: Eliminate VARNAME ##
++## ------------------------ ##
++
++
++# _LT_DECL([CONFIGNAME], VARNAME, VALUE, [DESCRIPTION], [IS-TAGGED?])
++# -------------------------------------------------------------------
++# CONFIGNAME is the name given to the value in the libtool script.
++# VARNAME is the (base) name used in the configure script.
++# VALUE may be 0, 1 or 2 for a computed quote escaped value based on
++# VARNAME.  Any other value will be used directly.
++m4_define([_LT_DECL],
++[lt_if_append_uniq([lt_decl_varnames], [$2], [, ],
++    [lt_dict_add_subkey([lt_decl_dict], [$2], [libtool_name],
++	[m4_ifval([$1], [$1], [$2])])
++    lt_dict_add_subkey([lt_decl_dict], [$2], [value], [$3])
++    m4_ifval([$4],
++	[lt_dict_add_subkey([lt_decl_dict], [$2], [description], [$4])])
++    lt_dict_add_subkey([lt_decl_dict], [$2],
++	[tagged?], [m4_ifval([$5], [yes], [no])])])
++])
++
++
++# _LT_TAGDECL([CONFIGNAME], VARNAME, VALUE, [DESCRIPTION])
++# --------------------------------------------------------
++m4_define([_LT_TAGDECL], [_LT_DECL([$1], [$2], [$3], [$4], [yes])])
++
++
++# lt_decl_tag_varnames([SEPARATOR], [VARNAME1...])
++# ------------------------------------------------
++m4_define([lt_decl_tag_varnames],
++[_lt_decl_filter([tagged?], [yes], $@)])
++
++
++# _lt_decl_filter(SUBKEY, VALUE, [SEPARATOR], [VARNAME1..])
++# ---------------------------------------------------------
++m4_define([_lt_decl_filter],
++[m4_case([$#],
++  [0], [m4_fatal([$0: too few arguments: $#])],
++  [1], [m4_fatal([$0: too few arguments: $#: $1])],
++  [2], [lt_dict_filter([lt_decl_dict], [$1], [$2], [], lt_decl_varnames)],
++  [3], [lt_dict_filter([lt_decl_dict], [$1], [$2], [$3], lt_decl_varnames)],
++  [lt_dict_filter([lt_decl_dict], $@)])[]dnl
++])
++
++
++# lt_decl_quote_varnames([SEPARATOR], [VARNAME1...])
++# --------------------------------------------------
++m4_define([lt_decl_quote_varnames],
++[_lt_decl_filter([value], [1], $@)])
++
++
++# lt_decl_dquote_varnames([SEPARATOR], [VARNAME1...])
++# ---------------------------------------------------
++m4_define([lt_decl_dquote_varnames],
++[_lt_decl_filter([value], [2], $@)])
++
++
++# lt_decl_varnames_tagged([SEPARATOR], [VARNAME1...])
++# ---------------------------------------------------
++m4_define([lt_decl_varnames_tagged],
++[m4_assert([$# <= 2])dnl
++_$0(m4_quote(m4_default([$1], [[, ]])),
++    m4_ifval([$2], [[$2]], [m4_dquote(lt_decl_tag_varnames)]),
++    m4_split(m4_normalize(m4_quote(_LT_TAGS)), [ ]))])
++m4_define([_lt_decl_varnames_tagged],
++[m4_ifval([$3], [lt_combine([$1], [$2], [_], $3)])])
++
++
++# lt_decl_all_varnames([SEPARATOR], [VARNAME1...])
++# ------------------------------------------------
++m4_define([lt_decl_all_varnames],
++[_$0(m4_quote(m4_default([$1], [[, ]])),
++     m4_if([$2], [],
++	   m4_quote(lt_decl_varnames),
++	m4_quote(m4_shift($@))))[]dnl
++])
++m4_define([_lt_decl_all_varnames],
++[lt_join($@, lt_decl_varnames_tagged([$1],
++			lt_decl_tag_varnames([[, ]], m4_shift($@))))dnl
++])
++
++
++# _LT_CONFIG_STATUS_DECLARE([VARNAME])
++# ------------------------------------
++# Quote a variable value, and forward it to `config.status' so that its
++# declaration there will have the same value as in `configure'.  VARNAME
++# must have a single quote delimited value for this to work.
++m4_define([_LT_CONFIG_STATUS_DECLARE],
++[$1='`$ECHO "X$][$1" | $Xsed -e "$delay_single_quote_subst"`'])
++
++
++# _LT_CONFIG_STATUS_DECLARATIONS
++# ------------------------------
++# We delimit libtool config variables with single quotes, so when
++# we write them to config.status, we have to be sure to quote all
++# embedded single quotes properly.  In configure, this macro expands
++# each variable declared with _LT_DECL (and _LT_TAGDECL) into:
++#
++#    <var>='`$ECHO "X$<var>" | $Xsed -e "$delay_single_quote_subst"`'
++m4_defun([_LT_CONFIG_STATUS_DECLARATIONS],
++[m4_foreach([_lt_var], m4_quote(lt_decl_all_varnames),
++    [m4_n([_LT_CONFIG_STATUS_DECLARE(_lt_var)])])])
++
++
++# _LT_LIBTOOL_TAGS
++# ----------------
++# Output comment and list of tags supported by the script
++m4_defun([_LT_LIBTOOL_TAGS],
++[_LT_FORMAT_COMMENT([The names of the tagged configurations supported by this script])dnl
++available_tags="_LT_TAGS"dnl
++])
++
++
++# _LT_LIBTOOL_DECLARE(VARNAME, [TAG])
++# -----------------------------------
++# Extract the dictionary values for VARNAME (optionally with TAG) and
++# expand to a commented shell variable setting:
++#
++#    # Some comment about what VAR is for.
++#    visible_name=$lt_internal_name
++m4_define([_LT_LIBTOOL_DECLARE],
++[_LT_FORMAT_COMMENT(m4_quote(lt_dict_fetch([lt_decl_dict], [$1],
++					   [description])))[]dnl
++m4_pushdef([_libtool_name],
++    m4_quote(lt_dict_fetch([lt_decl_dict], [$1], [libtool_name])))[]dnl
++m4_case(m4_quote(lt_dict_fetch([lt_decl_dict], [$1], [value])),
++    [0], [_libtool_name=[$]$1],
++    [1], [_libtool_name=$lt_[]$1],
++    [2], [_libtool_name=$lt_[]$1],
++    [_libtool_name=lt_dict_fetch([lt_decl_dict], [$1], [value])])[]dnl
++m4_ifval([$2], [_$2])[]m4_popdef([_libtool_name])[]dnl
++])
++
++
++# _LT_LIBTOOL_CONFIG_VARS
++# -----------------------
++# Produce commented declarations of non-tagged libtool config variables
++# suitable for insertion in the LIBTOOL CONFIG section of the `libtool'
++# script.  Tagged libtool config variables (even for the LIBTOOL CONFIG
++# section) are produced by _LT_LIBTOOL_TAG_VARS.
++m4_defun([_LT_LIBTOOL_CONFIG_VARS],
++[m4_foreach([_lt_var],
++    m4_quote(_lt_decl_filter([tagged?], [no], [], lt_decl_varnames)),
++    [m4_n([_LT_LIBTOOL_DECLARE(_lt_var)])])])
++
++
++# _LT_LIBTOOL_TAG_VARS(TAG)
++# -------------------------
++m4_define([_LT_LIBTOOL_TAG_VARS],
++[m4_foreach([_lt_var], m4_quote(lt_decl_tag_varnames),
++    [m4_n([_LT_LIBTOOL_DECLARE(_lt_var, [$1])])])])
++
++
++# _LT_TAGVAR(VARNAME, [TAGNAME])
++# ------------------------------
++m4_define([_LT_TAGVAR], [m4_ifval([$2], [$1_$2], [$1])])
++
++
++# _LT_CONFIG_COMMANDS
++# -------------------
++# Send accumulated output to $CONFIG_STATUS.  Thanks to the lists of
++# variables for single and double quote escaping we saved from calls
++# to _LT_DECL, we can put quote escaped variables declarations
++# into `config.status', and then the shell code to quote escape them in
++# for loops in `config.status'.  Finally, any additional code accumulated
++# from calls to _LT_CONFIG_LIBTOOL_INIT is expanded.
++m4_defun([_LT_CONFIG_COMMANDS],
++[AC_PROVIDE_IFELSE([LT_OUTPUT],
++	dnl If the libtool generation code has been placed in $CONFIG_LT,
++	dnl instead of duplicating it all over again into config.status,
++	dnl then we will have config.status run $CONFIG_LT later, so it
++	dnl needs to know what name is stored there:
++        [AC_CONFIG_COMMANDS([libtool],
++            [$SHELL $CONFIG_LT || AS_EXIT(1)], [CONFIG_LT='$CONFIG_LT'])],
++    dnl If the libtool generation code is destined for config.status,
++    dnl expand the accumulated commands and init code now:
++    [AC_CONFIG_COMMANDS([libtool],
++        [_LT_OUTPUT_LIBTOOL_COMMANDS], [_LT_OUTPUT_LIBTOOL_COMMANDS_INIT])])
++])#_LT_CONFIG_COMMANDS
++
++
++# Initialize.
++m4_define([_LT_OUTPUT_LIBTOOL_COMMANDS_INIT],
++[
++
++# The HP-UX ksh and POSIX shell print the target directory to stdout
++# if CDPATH is set.
++(unset CDPATH) >/dev/null 2>&1 && unset CDPATH
++
++sed_quote_subst='$sed_quote_subst'
++double_quote_subst='$double_quote_subst'
++delay_variable_subst='$delay_variable_subst'
++_LT_CONFIG_STATUS_DECLARATIONS
++LTCC='$LTCC'
++LTCFLAGS='$LTCFLAGS'
++compiler='$compiler_DEFAULT'
++
++# Quote evaled strings.
++for var in lt_decl_all_varnames([[ \
++]], lt_decl_quote_varnames); do
++    case \`eval \\\\\$ECHO "X\\\\\$\$var"\` in
++    *[[\\\\\\\`\\"\\\$]]*)
++      eval "lt_\$var=\\\\\\"\\\`\\\$ECHO \\"X\\\$\$var\\" | \\\$Xsed -e \\"\\\$sed_quote_subst\\"\\\`\\\\\\""
++      ;;
++    *)
++      eval "lt_\$var=\\\\\\"\\\$\$var\\\\\\""
++      ;;
++    esac
++done
++
++# Double-quote double-evaled strings.
++for var in lt_decl_all_varnames([[ \
++]], lt_decl_dquote_varnames); do
++    case \`eval \\\\\$ECHO "X\\\\\$\$var"\` in
++    *[[\\\\\\\`\\"\\\$]]*)
++      eval "lt_\$var=\\\\\\"\\\`\\\$ECHO \\"X\\\$\$var\\" | \\\$Xsed -e \\"\\\$double_quote_subst\\" -e \\"\\\$sed_quote_subst\\" -e \\"\\\$delay_variable_subst\\"\\\`\\\\\\""
++      ;;
++    *)
++      eval "lt_\$var=\\\\\\"\\\$\$var\\\\\\""
++      ;;
++    esac
++done
++
++# Fix-up fallback echo if it was mangled by the above quoting rules.
++case \$lt_ECHO in
++*'\\\[$]0 --fallback-echo"')dnl "
++  lt_ECHO=\`\$ECHO "X\$lt_ECHO" | \$Xsed -e 's/\\\\\\\\\\\\\\\[$]0 --fallback-echo"\[$]/\[$]0 --fallback-echo"/'\`
++  ;;
++esac
++
++_LT_OUTPUT_LIBTOOL_INIT
++])
++
++
++# LT_OUTPUT
++# ---------
++# This macro allows early generation of the libtool script (before
++# AC_OUTPUT is called), incase it is used in configure for compilation
++# tests.
++AC_DEFUN([LT_OUTPUT],
++[: ${CONFIG_LT=./config.lt}
++AC_MSG_NOTICE([creating $CONFIG_LT])
++cat >"$CONFIG_LT" <<_LTEOF
++#! $SHELL
++# Generated by $as_me.
++# Run this file to recreate a libtool stub with the current configuration.
++
++lt_cl_silent=false
++SHELL=\${CONFIG_SHELL-$SHELL}
++_LTEOF
++
++cat >>"$CONFIG_LT" <<\_LTEOF
++AS_SHELL_SANITIZE
++_AS_PREPARE
++
++exec AS_MESSAGE_FD>&1
++exec AS_MESSAGE_LOG_FD>>config.log
++{
++  echo
++  AS_BOX([Running $as_me.])
++} >&AS_MESSAGE_LOG_FD
++
++lt_cl_help="\
++\`$as_me' creates a local libtool stub from the current configuration,
++for use in further configure time tests before the real libtool is
++generated.
++
++Usage: $[0] [[OPTIONS]]
++
++  -h, --help      print this help, then exit
++  -V, --version   print version number, then exit
++  -q, --quiet     do not print progress messages
++  -d, --debug     don't remove temporary files
++
++Report bugs to <bug-libtool@gnu.org>."
++
++lt_cl_version="\
++m4_ifset([AC_PACKAGE_NAME], [AC_PACKAGE_NAME ])config.lt[]dnl
++m4_ifset([AC_PACKAGE_VERSION], [ AC_PACKAGE_VERSION])
++configured by $[0], generated by m4_PACKAGE_STRING.
++
++Copyright (C) 2008 Free Software Foundation, Inc.
++This config.lt script is free software; the Free Software Foundation
++gives unlimited permision to copy, distribute and modify it."
++
++while test $[#] != 0
++do
++  case $[1] in
++    --version | --v* | -V )
++      echo "$lt_cl_version"; exit 0 ;;
++    --help | --h* | -h )
++      echo "$lt_cl_help"; exit 0 ;;
++    --debug | --d* | -d )
++      debug=: ;;
++    --quiet | --q* | --silent | --s* | -q )
++      lt_cl_silent=: ;;
++
++    -*) AC_MSG_ERROR([unrecognized option: $[1]
++Try \`$[0] --help' for more information.]) ;;
++
++    *) AC_MSG_ERROR([unrecognized argument: $[1]
++Try \`$[0] --help' for more information.]) ;;
++  esac
++  shift
++done
++
++if $lt_cl_silent; then
++  exec AS_MESSAGE_FD>/dev/null
++fi
++_LTEOF
++
++cat >>"$CONFIG_LT" <<_LTEOF
++_LT_OUTPUT_LIBTOOL_COMMANDS_INIT
++_LTEOF
++
++cat >>"$CONFIG_LT" <<\_LTEOF
++AC_MSG_NOTICE([creating $ofile])
++_LT_OUTPUT_LIBTOOL_COMMANDS
++AS_EXIT(0)
++_LTEOF
++chmod +x "$CONFIG_LT"
++
++# configure is writing to config.log, but config.lt does its own redirection,
++# appending to config.log, which fails on DOS, as config.log is still kept
++# open by configure.  Here we exec the FD to /dev/null, effectively closing
++# config.log, so it can be properly (re)opened and appended to by config.lt.
++if test "$no_create" != yes; then
++  lt_cl_success=:
++  test "$silent" = yes &&
++    lt_config_lt_args="$lt_config_lt_args --quiet"
++  exec AS_MESSAGE_LOG_FD>/dev/null
++  $SHELL "$CONFIG_LT" $lt_config_lt_args || lt_cl_success=false
++  exec AS_MESSAGE_LOG_FD>>config.log
++  $lt_cl_success || AS_EXIT(1)
++fi
++])# LT_OUTPUT
++
++
++# _LT_CONFIG(TAG)
++# ---------------
++# If TAG is the built-in tag, create an initial libtool script with a
++# default configuration from the untagged config vars.  Otherwise add code
++# to config.status for appending the configuration named by TAG from the
++# matching tagged config vars.
++m4_defun([_LT_CONFIG],
++[m4_require([_LT_FILEUTILS_DEFAULTS])dnl
++_LT_CONFIG_SAVE_COMMANDS([
++  m4_define([_LT_TAG], m4_if([$1], [], [C], [$1]))dnl
++  m4_if(_LT_TAG, [C], [
++    # See if we are running on zsh, and set the options which allow our
++    # commands through without removal of \ escapes.
++    if test -n "${ZSH_VERSION+set}" ; then
++      setopt NO_GLOB_SUBST
++    fi
++
++    cfgfile="${ofile}T"
++    trap "$RM \"$cfgfile\"; exit 1" 1 2 15
++    $RM "$cfgfile"
++
++    cat <<_LT_EOF >> "$cfgfile"
++#! $SHELL
++
++# `$ECHO "$ofile" | sed 's%^.*/%%'` - Provide generalized library-building support services.
++# Generated automatically by $as_me ($PACKAGE$TIMESTAMP) $VERSION
++# Libtool was configured on host `(hostname || uname -n) 2>/dev/null | sed 1q`:
++# NOTE: Changes made to this file will be lost: look at ltmain.sh.
++#
++_LT_COPYING
++_LT_LIBTOOL_TAGS
++
++# ### BEGIN LIBTOOL CONFIG
++_LT_LIBTOOL_CONFIG_VARS
++_LT_LIBTOOL_TAG_VARS
++# ### END LIBTOOL CONFIG
++
++_LT_EOF
++
++  case $host_os in
++  aix3*)
++    cat <<\_LT_EOF >> "$cfgfile"
++# AIX sometimes has problems with the GCC collect2 program.  For some
++# reason, if we set the COLLECT_NAMES environment variable, the problems
++# vanish in a puff of smoke.
++if test "X${COLLECT_NAMES+set}" != Xset; then
++  COLLECT_NAMES=
++  export COLLECT_NAMES
++fi
++_LT_EOF
++    ;;
++  esac
++
++  _LT_PROG_LTMAIN
++
++  # We use sed instead of cat because bash on DJGPP gets confused if
++  # if finds mixed CR/LF and LF-only lines.  Since sed operates in
++  # text mode, it properly converts lines to CR/LF.  This bash problem
++  # is reportedly fixed, but why not run on old versions too?
++  sed '/^# Generated shell functions inserted here/q' "$ltmain" >> "$cfgfile" \
++    || (rm -f "$cfgfile"; exit 1)
++
++  _LT_PROG_XSI_SHELLFNS
++
++  sed -n '/^# Generated shell functions inserted here/,$p' "$ltmain" >> "$cfgfile" \
++    || (rm -f "$cfgfile"; exit 1)
++
++  mv -f "$cfgfile" "$ofile" ||
++    (rm -f "$ofile" && cp "$cfgfile" "$ofile" && rm -f "$cfgfile")
++  chmod +x "$ofile"
++],
++[cat <<_LT_EOF >> "$ofile"
++
++dnl Unfortunately we have to use $1 here, since _LT_TAG is not expanded
++dnl in a comment (ie after a #).
++# ### BEGIN LIBTOOL TAG CONFIG: $1
++_LT_LIBTOOL_TAG_VARS(_LT_TAG)
++# ### END LIBTOOL TAG CONFIG: $1
++_LT_EOF
++])dnl /m4_if
++],
++[m4_if([$1], [], [
++    PACKAGE='$PACKAGE'
++    VERSION='$VERSION'
++    TIMESTAMP='$TIMESTAMP'
++    RM='$RM'
++    ofile='$ofile'], [])
++])dnl /_LT_CONFIG_SAVE_COMMANDS
++])# _LT_CONFIG
++
++
++# LT_SUPPORTED_TAG(TAG)
++# ---------------------
++# Trace this macro to discover what tags are supported by the libtool
++# --tag option, using:
++#    autoconf --trace 'LT_SUPPORTED_TAG:$1'
++AC_DEFUN([LT_SUPPORTED_TAG], [])
++
++
++# C support is built-in for now
++m4_define([_LT_LANG_C_enabled], [])
++m4_define([_LT_TAGS], [])
++
++
++# LT_LANG(LANG)
++# -------------
++# Enable libtool support for the given language if not already enabled.
++AC_DEFUN([LT_LANG],
++[AC_BEFORE([$0], [LT_OUTPUT])dnl
++m4_case([$1],
++  [C],			[_LT_LANG(C)],
++  [C++],		[_LT_LANG(CXX)],
++  [Java],		[_LT_LANG(GCJ)],
++  [Fortran 77],		[_LT_LANG(F77)],
++  [Fortran],		[_LT_LANG(FC)],
++  [Windows Resource],	[_LT_LANG(RC)],
++  [m4_ifdef([_LT_LANG_]$1[_CONFIG],
++    [_LT_LANG($1)],
++    [m4_fatal([$0: unsupported language: "$1"])])])dnl
++])# LT_LANG
++
++
++# _LT_LANG(LANGNAME)
++# ------------------
++m4_defun([_LT_LANG],
++[m4_ifdef([_LT_LANG_]$1[_enabled], [],
++  [LT_SUPPORTED_TAG([$1])dnl
++  m4_append([_LT_TAGS], [$1 ])dnl
++  m4_define([_LT_LANG_]$1[_enabled], [])dnl
++  _LT_LANG_$1_CONFIG($1)])dnl
++])# _LT_LANG
++
++
++# _LT_LANG_DEFAULT_CONFIG
++# -----------------------
++m4_defun([_LT_LANG_DEFAULT_CONFIG],
++[AC_PROVIDE_IFELSE([AC_PROG_CXX],
++  [LT_LANG(CXX)],
++  [m4_define([AC_PROG_CXX], defn([AC_PROG_CXX])[LT_LANG(CXX)])])
++
++AC_PROVIDE_IFELSE([AC_PROG_F77],
++  [LT_LANG(F77)],
++  [m4_define([AC_PROG_F77], defn([AC_PROG_F77])[LT_LANG(F77)])])
++
++AC_PROVIDE_IFELSE([AC_PROG_FC],
++  [LT_LANG(FC)],
++  [m4_define([AC_PROG_FC], defn([AC_PROG_FC])[LT_LANG(FC)])])
++
++dnl The call to [A][M_PROG_GCJ] is quoted like that to stop aclocal
++dnl pulling things in needlessly.
++AC_PROVIDE_IFELSE([AC_PROG_GCJ],
++  [LT_LANG(GCJ)],
++  [AC_PROVIDE_IFELSE([A][M_PROG_GCJ],
++    [LT_LANG(GCJ)],
++    [AC_PROVIDE_IFELSE([LT_PROG_GCJ],
++      [LT_LANG(GCJ)],
++      [m4_ifdef([AC_PROG_GCJ],
++	[m4_define([AC_PROG_GCJ], defn([AC_PROG_GCJ])[LT_LANG(GCJ)])])
++       m4_ifdef([A][M_PROG_GCJ],
++	[m4_define([A][M_PROG_GCJ], defn([A][M_PROG_GCJ])[LT_LANG(GCJ)])])
++       m4_ifdef([LT_PROG_GCJ],
++	[m4_define([LT_PROG_GCJ], defn([LT_PROG_GCJ])[LT_LANG(GCJ)])])])])])
++
++AC_PROVIDE_IFELSE([LT_PROG_RC],
++  [LT_LANG(RC)],
++  [m4_define([LT_PROG_RC], defn([LT_PROG_RC])[LT_LANG(RC)])])
++])# _LT_LANG_DEFAULT_CONFIG
++
++# Obsolete macros:
++AU_DEFUN([AC_LIBTOOL_CXX], [LT_LANG(C++)])
++AU_DEFUN([AC_LIBTOOL_F77], [LT_LANG(Fortran 77)])
++AU_DEFUN([AC_LIBTOOL_FC], [LT_LANG(Fortran)])
++AU_DEFUN([AC_LIBTOOL_GCJ], [LT_LANG(Java)])
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AC_LIBTOOL_CXX], [])
++dnl AC_DEFUN([AC_LIBTOOL_F77], [])
++dnl AC_DEFUN([AC_LIBTOOL_FC], [])
++dnl AC_DEFUN([AC_LIBTOOL_GCJ], [])
++
++
++# _LT_TAG_COMPILER
++# ----------------
++m4_defun([_LT_TAG_COMPILER],
++[AC_REQUIRE([AC_PROG_CC])dnl
++
++_LT_DECL([LTCC], [CC], [1], [A C compiler])dnl
++_LT_DECL([LTCFLAGS], [CFLAGS], [1], [LTCC compiler flags])dnl
++_LT_TAGDECL([CC], [compiler], [1], [A language specific compiler])dnl
++_LT_TAGDECL([with_gcc], [GCC], [0], [Is the compiler the GNU compiler?])dnl
++
++# If no C compiler was specified, use CC.
++LTCC=${LTCC-"$CC"}
++
++# If no C compiler flags were specified, use CFLAGS.
++LTCFLAGS=${LTCFLAGS-"$CFLAGS"}
++
++# Allow CC to be a program name with arguments.
++compiler=$CC
++])# _LT_TAG_COMPILER
++
++
++# _LT_COMPILER_BOILERPLATE
++# ------------------------
++# Check for compiler boilerplate output or warnings with
++# the simple compiler test code.
++m4_defun([_LT_COMPILER_BOILERPLATE],
++[m4_require([_LT_DECL_SED])dnl
++ac_outfile=conftest.$ac_objext
++echo "$lt_simple_compile_test_code" >conftest.$ac_ext
++eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
++_lt_compiler_boilerplate=`cat conftest.err`
++$RM conftest*
++])# _LT_COMPILER_BOILERPLATE
++
++
++# _LT_LINKER_BOILERPLATE
++# ----------------------
++# Check for linker boilerplate output or warnings with
++# the simple link test code.
++m4_defun([_LT_LINKER_BOILERPLATE],
++[m4_require([_LT_DECL_SED])dnl
++ac_outfile=conftest.$ac_objext
++echo "$lt_simple_link_test_code" >conftest.$ac_ext
++eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
++_lt_linker_boilerplate=`cat conftest.err`
++$RM -r conftest*
++])# _LT_LINKER_BOILERPLATE
++
++# _LT_REQUIRED_DARWIN_CHECKS
++# -------------------------
++m4_defun_once([_LT_REQUIRED_DARWIN_CHECKS],[
++  case $host_os in
++    rhapsody* | darwin*)
++    AC_CHECK_TOOL([DSYMUTIL], [dsymutil], [:])
++    AC_CHECK_TOOL([NMEDIT], [nmedit], [:])
++    AC_CHECK_TOOL([LIPO], [lipo], [:])
++    AC_CHECK_TOOL([OTOOL], [otool], [:])
++    AC_CHECK_TOOL([OTOOL64], [otool64], [:])
++    _LT_DECL([], [DSYMUTIL], [1],
++      [Tool to manipulate archived DWARF debug symbol files on Mac OS X])
++    _LT_DECL([], [NMEDIT], [1],
++      [Tool to change global to local symbols on Mac OS X])
++    _LT_DECL([], [LIPO], [1],
++      [Tool to manipulate fat objects and archives on Mac OS X])
++    _LT_DECL([], [OTOOL], [1],
++      [ldd/readelf like tool for Mach-O binaries on Mac OS X])
++    _LT_DECL([], [OTOOL64], [1],
++      [ldd/readelf like tool for 64 bit Mach-O binaries on Mac OS X 10.4])
++
++    AC_CACHE_CHECK([for -single_module linker flag],[lt_cv_apple_cc_single_mod],
++      [lt_cv_apple_cc_single_mod=no
++      if test -z "${LT_MULTI_MODULE}"; then
++	# By default we will add the -single_module flag. You can override
++	# by either setting the environment variable LT_MULTI_MODULE
++	# non-empty at configure time, or by adding -multi_module to the
++	# link flags.
++	rm -rf libconftest.dylib*
++	echo "int foo(void){return 1;}" > conftest.c
++	echo "$LTCC $LTCFLAGS $LDFLAGS -o libconftest.dylib \
++-dynamiclib -Wl,-single_module conftest.c" >&AS_MESSAGE_LOG_FD
++	$LTCC $LTCFLAGS $LDFLAGS -o libconftest.dylib \
++	  -dynamiclib -Wl,-single_module conftest.c 2>conftest.err
++        _lt_result=$?
++	if test -f libconftest.dylib && test ! -s conftest.err && test $_lt_result = 0; then
++	  lt_cv_apple_cc_single_mod=yes
++	else
++	  cat conftest.err >&AS_MESSAGE_LOG_FD
++	fi
++	rm -rf libconftest.dylib*
++	rm -f conftest.*
++      fi])
++    AC_CACHE_CHECK([for -exported_symbols_list linker flag],
++      [lt_cv_ld_exported_symbols_list],
++      [lt_cv_ld_exported_symbols_list=no
++      save_LDFLAGS=$LDFLAGS
++      echo "_main" > conftest.sym
++      LDFLAGS="$LDFLAGS -Wl,-exported_symbols_list,conftest.sym"
++      AC_LINK_IFELSE([AC_LANG_PROGRAM([],[])],
++	[lt_cv_ld_exported_symbols_list=yes],
++	[lt_cv_ld_exported_symbols_list=no])
++	LDFLAGS="$save_LDFLAGS"
++    ])
++    case $host_os in
++    rhapsody* | darwin1.[[012]])
++      _lt_dar_allow_undefined='${wl}-undefined ${wl}suppress' ;;
++    darwin1.*)
++      _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
++    darwin*) # darwin 5.x on
++      # if running on 10.5 or later, the deployment target defaults
++      # to the OS version, if on x86, and 10.4, the deployment
++      # target defaults to 10.4. Don't you love it?
++      case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
++	10.0,*86*-darwin8*|10.0,*-darwin[[91]]*)
++	  _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
++	10.[[012]]*)
++	  _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
++	10.*)
++	  _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
++      esac
++    ;;
++  esac
++    if test "$lt_cv_apple_cc_single_mod" = "yes"; then
++      _lt_dar_single_mod='$single_module'
++    fi
++    if test "$lt_cv_ld_exported_symbols_list" = "yes"; then
++      _lt_dar_export_syms=' ${wl}-exported_symbols_list,$output_objdir/${libname}-symbols.expsym'
++    else
++      _lt_dar_export_syms='~$NMEDIT -s $output_objdir/${libname}-symbols.expsym ${lib}'
++    fi
++    if test "$DSYMUTIL" != ":"; then
++      _lt_dsymutil='~$DSYMUTIL $lib || :'
++    else
++      _lt_dsymutil=
++    fi
++    ;;
++  esac
++])
++
++
++# _LT_DARWIN_LINKER_FEATURES
++# --------------------------
++# Checks for linker and compiler features on darwin
++m4_defun([_LT_DARWIN_LINKER_FEATURES],
++[
++  m4_require([_LT_REQUIRED_DARWIN_CHECKS])
++  _LT_TAGVAR(archive_cmds_need_lc, $1)=no
++  _LT_TAGVAR(hardcode_direct, $1)=no
++  _LT_TAGVAR(hardcode_automatic, $1)=yes
++  _LT_TAGVAR(hardcode_shlibpath_var, $1)=unsupported
++  _LT_TAGVAR(whole_archive_flag_spec, $1)=''
++  _LT_TAGVAR(link_all_deplibs, $1)=yes
++  _LT_TAGVAR(allow_undefined_flag, $1)="$_lt_dar_allow_undefined"
++  case $cc_basename in
++     ifort*) _lt_dar_can_shared=yes ;;
++     *) _lt_dar_can_shared=$GCC ;;
++  esac
++  if test "$_lt_dar_can_shared" = "yes"; then
++    output_verbose_link_cmd=echo
++    _LT_TAGVAR(archive_cmds, $1)="\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring $_lt_dar_single_mod${_lt_dsymutil}"
++    _LT_TAGVAR(module_cmds, $1)="\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags${_lt_dsymutil}"
++    _LT_TAGVAR(archive_expsym_cmds, $1)="sed 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring ${_lt_dar_single_mod}${_lt_dar_export_syms}${_lt_dsymutil}"
++    _LT_TAGVAR(module_expsym_cmds, $1)="sed -e 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags${_lt_dar_export_syms}${_lt_dsymutil}"
++    m4_if([$1], [CXX],
++[   if test "$lt_cv_apple_cc_single_mod" != "yes"; then
++      _LT_TAGVAR(archive_cmds, $1)="\$CC -r -keep_private_externs -nostdlib -o \${lib}-master.o \$libobjs~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \${lib}-master.o \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring${_lt_dsymutil}"
++      _LT_TAGVAR(archive_expsym_cmds, $1)="sed 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC -r -keep_private_externs -nostdlib -o \${lib}-master.o \$libobjs~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \${lib}-master.o \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring${_lt_dar_export_syms}${_lt_dsymutil}"
++    fi
++],[])
++  else
++  _LT_TAGVAR(ld_shlibs, $1)=no
++  fi
++])
++
++# _LT_SYS_MODULE_PATH_AIX
++# -----------------------
++# Links a minimal program and checks the executable
++# for the system default hardcoded library path. In most cases,
++# this is /usr/lib:/lib, but when the MPI compilers are used
++# the location of the communication and MPI libs are included too.
++# If we don't find anything, use the default library path according
++# to the aix ld manual.
++m4_defun([_LT_SYS_MODULE_PATH_AIX],
++[m4_require([_LT_DECL_SED])dnl
++AC_LINK_IFELSE(AC_LANG_PROGRAM,[
++lt_aix_libpath_sed='
++    /Import File Strings/,/^$/ {
++	/^0/ {
++	    s/^0  *\(.*\)$/\1/
++	    p
++	}
++    }'
++aix_libpath=`dump -H conftest$ac_exeext 2>/dev/null | $SED -n -e "$lt_aix_libpath_sed"`
++# Check for a 64-bit object if we didn't find anything.
++if test -z "$aix_libpath"; then
++  aix_libpath=`dump -HX64 conftest$ac_exeext 2>/dev/null | $SED -n -e "$lt_aix_libpath_sed"`
++fi],[])
++if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
++])# _LT_SYS_MODULE_PATH_AIX
++
++
++# _LT_SHELL_INIT(ARG)
++# -------------------
++m4_define([_LT_SHELL_INIT],
++[ifdef([AC_DIVERSION_NOTICE],
++	     [AC_DIVERT_PUSH(AC_DIVERSION_NOTICE)],
++	 [AC_DIVERT_PUSH(NOTICE)])
++$1
++AC_DIVERT_POP
++])# _LT_SHELL_INIT
++
++
++# _LT_PROG_ECHO_BACKSLASH
++# -----------------------
++# Add some code to the start of the generated configure script which
++# will find an echo command which doesn't interpret backslashes.
++m4_defun([_LT_PROG_ECHO_BACKSLASH],
++[_LT_SHELL_INIT([
++# Check that we are running under the correct shell.
++SHELL=${CONFIG_SHELL-/bin/sh}
++
++case X$lt_ECHO in
++X*--fallback-echo)
++  # Remove one level of quotation (which was required for Make).
++  ECHO=`echo "$lt_ECHO" | sed 's,\\\\\[$]\\[$]0,'[$]0','`
++  ;;
++esac
++
++ECHO=${lt_ECHO-echo}
++if test "X[$]1" = X--no-reexec; then
++  # Discard the --no-reexec flag, and continue.
++  shift
++elif test "X[$]1" = X--fallback-echo; then
++  # Avoid inline document here, it may be left over
++  :
++elif test "X`{ $ECHO '\t'; } 2>/dev/null`" = 'X\t' ; then
++  # Yippee, $ECHO works!
++  :
++else
++  # Restart under the correct shell.
++  exec $SHELL "[$]0" --no-reexec ${1+"[$]@"}
++fi
++
++if test "X[$]1" = X--fallback-echo; then
++  # used as fallback echo
++  shift
++  cat <<_LT_EOF
++[$]*
++_LT_EOF
++  exit 0
++fi
++
++# The HP-UX ksh and POSIX shell print the target directory to stdout
++# if CDPATH is set.
++(unset CDPATH) >/dev/null 2>&1 && unset CDPATH
++
++if test -z "$lt_ECHO"; then
++  if test "X${echo_test_string+set}" != Xset; then
++    # find a string as large as possible, as long as the shell can cope with it
++    for cmd in 'sed 50q "[$]0"' 'sed 20q "[$]0"' 'sed 10q "[$]0"' 'sed 2q "[$]0"' 'echo test'; do
++      # expected sizes: less than 2Kb, 1Kb, 512 bytes, 16 bytes, ...
++      if { echo_test_string=`eval $cmd`; } 2>/dev/null &&
++	 { test "X$echo_test_string" = "X$echo_test_string"; } 2>/dev/null
++      then
++        break
++      fi
++    done
++  fi
++
++  if test "X`{ $ECHO '\t'; } 2>/dev/null`" = 'X\t' &&
++     echo_testing_string=`{ $ECHO "$echo_test_string"; } 2>/dev/null` &&
++     test "X$echo_testing_string" = "X$echo_test_string"; then
++    :
++  else
++    # The Solaris, AIX, and Digital Unix default echo programs unquote
++    # backslashes.  This makes it impossible to quote backslashes using
++    #   echo "$something" | sed 's/\\/\\\\/g'
++    #
++    # So, first we look for a working echo in the user's PATH.
++
++    lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
++    for dir in $PATH /usr/ucb; do
++      IFS="$lt_save_ifs"
++      if (test -f $dir/echo || test -f $dir/echo$ac_exeext) &&
++         test "X`($dir/echo '\t') 2>/dev/null`" = 'X\t' &&
++         echo_testing_string=`($dir/echo "$echo_test_string") 2>/dev/null` &&
++         test "X$echo_testing_string" = "X$echo_test_string"; then
++        ECHO="$dir/echo"
++        break
++      fi
++    done
++    IFS="$lt_save_ifs"
++
++    if test "X$ECHO" = Xecho; then
++      # We didn't find a better echo, so look for alternatives.
++      if test "X`{ print -r '\t'; } 2>/dev/null`" = 'X\t' &&
++         echo_testing_string=`{ print -r "$echo_test_string"; } 2>/dev/null` &&
++         test "X$echo_testing_string" = "X$echo_test_string"; then
++        # This shell has a builtin print -r that does the trick.
++        ECHO='print -r'
++      elif { test -f /bin/ksh || test -f /bin/ksh$ac_exeext; } &&
++	   test "X$CONFIG_SHELL" != X/bin/ksh; then
++        # If we have ksh, try running configure again with it.
++        ORIGINAL_CONFIG_SHELL=${CONFIG_SHELL-/bin/sh}
++        export ORIGINAL_CONFIG_SHELL
++        CONFIG_SHELL=/bin/ksh
++        export CONFIG_SHELL
++        exec $CONFIG_SHELL "[$]0" --no-reexec ${1+"[$]@"}
++      else
++        # Try using printf.
++        ECHO='printf %s\n'
++        if test "X`{ $ECHO '\t'; } 2>/dev/null`" = 'X\t' &&
++	   echo_testing_string=`{ $ECHO "$echo_test_string"; } 2>/dev/null` &&
++	   test "X$echo_testing_string" = "X$echo_test_string"; then
++	  # Cool, printf works
++	  :
++        elif echo_testing_string=`($ORIGINAL_CONFIG_SHELL "[$]0" --fallback-echo '\t') 2>/dev/null` &&
++	     test "X$echo_testing_string" = 'X\t' &&
++	     echo_testing_string=`($ORIGINAL_CONFIG_SHELL "[$]0" --fallback-echo "$echo_test_string") 2>/dev/null` &&
++	     test "X$echo_testing_string" = "X$echo_test_string"; then
++	  CONFIG_SHELL=$ORIGINAL_CONFIG_SHELL
++	  export CONFIG_SHELL
++	  SHELL="$CONFIG_SHELL"
++	  export SHELL
++	  ECHO="$CONFIG_SHELL [$]0 --fallback-echo"
++        elif echo_testing_string=`($CONFIG_SHELL "[$]0" --fallback-echo '\t') 2>/dev/null` &&
++	     test "X$echo_testing_string" = 'X\t' &&
++	     echo_testing_string=`($CONFIG_SHELL "[$]0" --fallback-echo "$echo_test_string") 2>/dev/null` &&
++	     test "X$echo_testing_string" = "X$echo_test_string"; then
++	  ECHO="$CONFIG_SHELL [$]0 --fallback-echo"
++        else
++	  # maybe with a smaller string...
++	  prev=:
++
++	  for cmd in 'echo test' 'sed 2q "[$]0"' 'sed 10q "[$]0"' 'sed 20q "[$]0"' 'sed 50q "[$]0"'; do
++	    if { test "X$echo_test_string" = "X`eval $cmd`"; } 2>/dev/null
++	    then
++	      break
++	    fi
++	    prev="$cmd"
++	  done
++
++	  if test "$prev" != 'sed 50q "[$]0"'; then
++	    echo_test_string=`eval $prev`
++	    export echo_test_string
++	    exec ${ORIGINAL_CONFIG_SHELL-${CONFIG_SHELL-/bin/sh}} "[$]0" ${1+"[$]@"}
++	  else
++	    # Oops.  We lost completely, so just stick with echo.
++	    ECHO=echo
++	  fi
++        fi
++      fi
++    fi
++  fi
++fi
++
++# Copy echo and quote the copy suitably for passing to libtool from
++# the Makefile, instead of quoting the original, which is used later.
++lt_ECHO=$ECHO
++if test "X$lt_ECHO" = "X$CONFIG_SHELL [$]0 --fallback-echo"; then
++   lt_ECHO="$CONFIG_SHELL \\\$\[$]0 --fallback-echo"
++fi
++
++AC_SUBST(lt_ECHO)
++])
++_LT_DECL([], [SHELL], [1], [Shell to use when invoking shell scripts])
++_LT_DECL([], [ECHO], [1],
++    [An echo program that does not interpret backslashes])
++])# _LT_PROG_ECHO_BACKSLASH
++
++
++# _LT_ENABLE_LOCK
++# ---------------
++m4_defun([_LT_ENABLE_LOCK],
++[AC_ARG_ENABLE([libtool-lock],
++  [AS_HELP_STRING([--disable-libtool-lock],
++    [avoid locking (might break parallel builds)])])
++test "x$enable_libtool_lock" != xno && enable_libtool_lock=yes
++
++# Some flags need to be propagated to the compiler or linker for good
++# libtool support.
++case $host in
++ia64-*-hpux*)
++  # Find out which ABI we are using.
++  echo 'int i;' > conftest.$ac_ext
++  if AC_TRY_EVAL(ac_compile); then
++    case `/usr/bin/file conftest.$ac_objext` in
++      *ELF-32*)
++	HPUX_IA64_MODE="32"
++	;;
++      *ELF-64*)
++	HPUX_IA64_MODE="64"
++	;;
++    esac
++  fi
++  rm -rf conftest*
++  ;;
++*-*-irix6*)
++  # Find out which ABI we are using.
++  echo '[#]line __oline__ "configure"' > conftest.$ac_ext
++  if AC_TRY_EVAL(ac_compile); then
++    if test "$lt_cv_prog_gnu_ld" = yes; then
++      case `/usr/bin/file conftest.$ac_objext` in
++	*32-bit*)
++	  LD="${LD-ld} -melf32bsmip"
++	  ;;
++	*N32*)
++	  LD="${LD-ld} -melf32bmipn32"
++	  ;;
++	*64-bit*)
++	  LD="${LD-ld} -melf64bmip"
++	;;
++      esac
++    else
++      case `/usr/bin/file conftest.$ac_objext` in
++	*32-bit*)
++	  LD="${LD-ld} -32"
++	  ;;
++	*N32*)
++	  LD="${LD-ld} -n32"
++	  ;;
++	*64-bit*)
++	  LD="${LD-ld} -64"
++	  ;;
++      esac
++    fi
++  fi
++  rm -rf conftest*
++  ;;
++
++x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
++s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
++  # Find out which ABI we are using.
++  echo 'int i;' > conftest.$ac_ext
++  if AC_TRY_EVAL(ac_compile); then
++    case `/usr/bin/file conftest.o` in
++      *32-bit*)
++	case $host in
++	  x86_64-*kfreebsd*-gnu)
++	    LD="${LD-ld} -m elf_i386_fbsd"
++	    ;;
++	  x86_64-*linux*)
++	    LD="${LD-ld} -m elf_i386"
++	    ;;
++	  ppc64-*linux*|powerpc64-*linux*)
++	    LD="${LD-ld} -m elf32ppclinux"
++	    ;;
++	  s390x-*linux*)
++	    LD="${LD-ld} -m elf_s390"
++	    ;;
++	  sparc64-*linux*)
++	    LD="${LD-ld} -m elf32_sparc"
++	    ;;
++	esac
++	;;
++      *64-bit*)
++	case $host in
++	  x86_64-*kfreebsd*-gnu)
++	    LD="${LD-ld} -m elf_x86_64_fbsd"
++	    ;;
++	  x86_64-*linux*)
++	    LD="${LD-ld} -m elf_x86_64"
++	    ;;
++	  ppc*-*linux*|powerpc*-*linux*)
++	    LD="${LD-ld} -m elf64ppc"
++	    ;;
++	  s390*-*linux*|s390*-*tpf*)
++	    LD="${LD-ld} -m elf64_s390"
++	    ;;
++	  sparc*-*linux*)
++	    LD="${LD-ld} -m elf64_sparc"
++	    ;;
++	esac
++	;;
++    esac
++  fi
++  rm -rf conftest*
++  ;;
++
++*-*-sco3.2v5*)
++  # On SCO OpenServer 5, we need -belf to get full-featured binaries.
++  SAVE_CFLAGS="$CFLAGS"
++  CFLAGS="$CFLAGS -belf"
++  AC_CACHE_CHECK([whether the C compiler needs -belf], lt_cv_cc_needs_belf,
++    [AC_LANG_PUSH(C)
++     AC_LINK_IFELSE([AC_LANG_PROGRAM([[]],[[]])],[lt_cv_cc_needs_belf=yes],[lt_cv_cc_needs_belf=no])
++     AC_LANG_POP])
++  if test x"$lt_cv_cc_needs_belf" != x"yes"; then
++    # this is probably gcc 2.8.0, egcs 1.0 or newer; no need for -belf
++    CFLAGS="$SAVE_CFLAGS"
++  fi
++  ;;
++sparc*-*solaris*)
++  # Find out which ABI we are using.
++  echo 'int i;' > conftest.$ac_ext
++  if AC_TRY_EVAL(ac_compile); then
++    case `/usr/bin/file conftest.o` in
++    *64-bit*)
++      case $lt_cv_prog_gnu_ld in
++      yes*) LD="${LD-ld} -m elf64_sparc" ;;
++      *)
++	if ${LD-ld} -64 -r -o conftest2.o conftest.o >/dev/null 2>&1; then
++	  LD="${LD-ld} -64"
++	fi
++	;;
++      esac
++      ;;
++    esac
++  fi
++  rm -rf conftest*
++  ;;
++esac
++
++need_locks="$enable_libtool_lock"
++])# _LT_ENABLE_LOCK
++
++
++# _LT_CMD_OLD_ARCHIVE
++# -------------------
++m4_defun([_LT_CMD_OLD_ARCHIVE],
++[AC_CHECK_TOOL(AR, ar, false)
++test -z "$AR" && AR=ar
++test -z "$AR_FLAGS" && AR_FLAGS=cru
++_LT_DECL([], [AR], [1], [The archiver])
++_LT_DECL([], [AR_FLAGS], [1])
++
++AC_CHECK_TOOL(STRIP, strip, :)
++test -z "$STRIP" && STRIP=:
++_LT_DECL([], [STRIP], [1], [A symbol stripping program])
++
++AC_CHECK_TOOL(RANLIB, ranlib, :)
++test -z "$RANLIB" && RANLIB=:
++_LT_DECL([], [RANLIB], [1],
++    [Commands used to install an old-style archive])
++
++# Determine commands to create old-style static archives.
++old_archive_cmds='$AR $AR_FLAGS $oldlib$oldobjs'
++old_postinstall_cmds='chmod 644 $oldlib'
++old_postuninstall_cmds=
++
++if test -n "$RANLIB"; then
++  case $host_os in
++  openbsd*)
++    old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$oldlib"
++    ;;
++  *)
++    old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
++    ;;
++  esac
++  old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib"
++fi
++_LT_DECL([], [old_postinstall_cmds], [2])
++_LT_DECL([], [old_postuninstall_cmds], [2])
++_LT_TAGDECL([], [old_archive_cmds], [2],
++    [Commands used to build an old-style archive])
++])# _LT_CMD_OLD_ARCHIVE
++
++
++# _LT_COMPILER_OPTION(MESSAGE, VARIABLE-NAME, FLAGS,
++#		[OUTPUT-FILE], [ACTION-SUCCESS], [ACTION-FAILURE])
++# ----------------------------------------------------------------
++# Check whether the given compiler option works
++AC_DEFUN([_LT_COMPILER_OPTION],
++[m4_require([_LT_FILEUTILS_DEFAULTS])dnl
++m4_require([_LT_DECL_SED])dnl
++AC_CACHE_CHECK([$1], [$2],
++  [$2=no
++   m4_if([$4], , [ac_outfile=conftest.$ac_objext], [ac_outfile=$4])
++   echo "$lt_simple_compile_test_code" > conftest.$ac_ext
++   lt_compiler_flag="$3"
++   # Insert the option either (1) after the last *FLAGS variable, or
++   # (2) before a word containing "conftest.", or (3) at the end.
++   # Note that $ac_compile itself does not contain backslashes and begins
++   # with a dollar sign (not a hyphen), so the echo should work correctly.
++   # The option is referenced via a variable to avoid confusing sed.
++   lt_compile=`echo "$ac_compile" | $SED \
++   -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
++   -e 's: [[^ ]]*conftest\.: $lt_compiler_flag&:; t' \
++   -e 's:$: $lt_compiler_flag:'`
++   (eval echo "\"\$as_me:__oline__: $lt_compile\"" >&AS_MESSAGE_LOG_FD)
++   (eval "$lt_compile" 2>conftest.err)
++   ac_status=$?
++   cat conftest.err >&AS_MESSAGE_LOG_FD
++   echo "$as_me:__oline__: \$? = $ac_status" >&AS_MESSAGE_LOG_FD
++   if (exit $ac_status) && test -s "$ac_outfile"; then
++     # The compiler can only warn and ignore the option if not recognized
++     # So say no if there are warnings other than the usual output.
++     $ECHO "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' >conftest.exp
++     $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
++     if test ! -s conftest.er2 || diff conftest.exp conftest.er2 >/dev/null; then
++       $2=yes
++     fi
++   fi
++   $RM conftest*
++])
++
++if test x"[$]$2" = xyes; then
++    m4_if([$5], , :, [$5])
++else
++    m4_if([$6], , :, [$6])
++fi
++])# _LT_COMPILER_OPTION
++
++# Old name:
++AU_ALIAS([AC_LIBTOOL_COMPILER_OPTION], [_LT_COMPILER_OPTION])
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AC_LIBTOOL_COMPILER_OPTION], [])
++
++
++# _LT_LINKER_OPTION(MESSAGE, VARIABLE-NAME, FLAGS,
++#                  [ACTION-SUCCESS], [ACTION-FAILURE])
++# ----------------------------------------------------
++# Check whether the given linker option works
++AC_DEFUN([_LT_LINKER_OPTION],
++[m4_require([_LT_FILEUTILS_DEFAULTS])dnl
++m4_require([_LT_DECL_SED])dnl
++AC_CACHE_CHECK([$1], [$2],
++  [$2=no
++   save_LDFLAGS="$LDFLAGS"
++   LDFLAGS="$LDFLAGS $3"
++   echo "$lt_simple_link_test_code" > conftest.$ac_ext
++   if (eval $ac_link 2>conftest.err) && test -s conftest$ac_exeext; then
++     # The linker can only warn and ignore the option if not recognized
++     # So say no if there are warnings
++     if test -s conftest.err; then
++       # Append any errors to the config.log.
++       cat conftest.err 1>&AS_MESSAGE_LOG_FD
++       $ECHO "X$_lt_linker_boilerplate" | $Xsed -e '/^$/d' > conftest.exp
++       $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
++       if diff conftest.exp conftest.er2 >/dev/null; then
++         $2=yes
++       fi
++     else
++       $2=yes
++     fi
++   fi
++   $RM -r conftest*
++   LDFLAGS="$save_LDFLAGS"
++])
++
++if test x"[$]$2" = xyes; then
++    m4_if([$4], , :, [$4])
++else
++    m4_if([$5], , :, [$5])
++fi
++])# _LT_LINKER_OPTION
++
++# Old name:
++AU_ALIAS([AC_LIBTOOL_LINKER_OPTION], [_LT_LINKER_OPTION])
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AC_LIBTOOL_LINKER_OPTION], [])
++
++
++# LT_CMD_MAX_LEN
++#---------------
++AC_DEFUN([LT_CMD_MAX_LEN],
++[AC_REQUIRE([AC_CANONICAL_HOST])dnl
++# find the maximum length of command line arguments
++AC_MSG_CHECKING([the maximum length of command line arguments])
++AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [dnl
++  i=0
++  teststring="ABCD"
++
++  case $build_os in
++  msdosdjgpp*)
++    # On DJGPP, this test can blow up pretty badly due to problems in libc
++    # (any single argument exceeding 2000 bytes causes a buffer overrun
++    # during glob expansion).  Even if it were fixed, the result of this
++    # check would be larger than it should be.
++    lt_cv_sys_max_cmd_len=12288;    # 12K is about right
++    ;;
++
++  gnu*)
++    # Under GNU Hurd, this test is not required because there is
++    # no limit to the length of command line arguments.
++    # Libtool will interpret -1 as no limit whatsoever
++    lt_cv_sys_max_cmd_len=-1;
++    ;;
++
++  cygwin* | mingw* | cegcc*)
++    # On Win9x/ME, this test blows up -- it succeeds, but takes
++    # about 5 minutes as the teststring grows exponentially.
++    # Worse, since 9x/ME are not pre-emptively multitasking,
++    # you end up with a "frozen" computer, even though with patience
++    # the test eventually succeeds (with a max line length of 256k).
++    # Instead, let's just punt: use the minimum linelength reported by
++    # all of the supported platforms: 8192 (on NT/2K/XP).
++    lt_cv_sys_max_cmd_len=8192;
++    ;;
++
++  amigaos*)
++    # On AmigaOS with pdksh, this test takes hours, literally.
++    # So we just punt and use a minimum line length of 8192.
++    lt_cv_sys_max_cmd_len=8192;
++    ;;
++
++  netbsd* | freebsd* | openbsd* | darwin* | dragonfly*)
++    # This has been around since 386BSD, at least.  Likely further.
++    if test -x /sbin/sysctl; then
++      lt_cv_sys_max_cmd_len=`/sbin/sysctl -n kern.argmax`
++    elif test -x /usr/sbin/sysctl; then
++      lt_cv_sys_max_cmd_len=`/usr/sbin/sysctl -n kern.argmax`
++    else
++      lt_cv_sys_max_cmd_len=65536	# usable default for all BSDs
++    fi
++    # And add a safety zone
++    lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
++    lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
++    ;;
++
++  interix*)
++    # We know the value 262144 and hardcode it with a safety zone (like BSD)
++    lt_cv_sys_max_cmd_len=196608
++    ;;
++
++  osf*)
++    # Dr. Hans Ekkehard Plesser reports seeing a kernel panic running configure
++    # due to this test when exec_disable_arg_limit is 1 on Tru64. It is not
++    # nice to cause kernel panics so lets avoid the loop below.
++    # First set a reasonable default.
++    lt_cv_sys_max_cmd_len=16384
++    #
++    if test -x /sbin/sysconfig; then
++      case `/sbin/sysconfig -q proc exec_disable_arg_limit` in
++        *1*) lt_cv_sys_max_cmd_len=-1 ;;
++      esac
++    fi
++    ;;
++  sco3.2v5*)
++    lt_cv_sys_max_cmd_len=102400
++    ;;
++  sysv5* | sco5v6* | sysv4.2uw2*)
++    kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2>/dev/null`
++    if test -n "$kargmax"; then
++      lt_cv_sys_max_cmd_len=`echo $kargmax | sed 's/.*[[	 ]]//'`
++    else
++      lt_cv_sys_max_cmd_len=32768
++    fi
++    ;;
++  *)
++    lt_cv_sys_max_cmd_len=`(getconf ARG_MAX) 2> /dev/null`
++    if test -n "$lt_cv_sys_max_cmd_len"; then
++      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
++      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
++    else
++      # Make teststring a little bigger before we do anything with it.
++      # a 1K string should be a reasonable start.
++      for i in 1 2 3 4 5 6 7 8 ; do
++        teststring=$teststring$teststring
++      done
++      SHELL=${SHELL-${CONFIG_SHELL-/bin/sh}}
++      # If test is not a shell built-in, we'll probably end up computing a
++      # maximum length that is only half of the actual maximum length, but
++      # we can't tell.
++      while { test "X"`$SHELL [$]0 --fallback-echo "X$teststring$teststring" 2>/dev/null` \
++	         = "XX$teststring$teststring"; } >/dev/null 2>&1 &&
++	      test $i != 17 # 1/2 MB should be enough
++      do
++        i=`expr $i + 1`
++        teststring=$teststring$teststring
++      done
++      # Only check the string length outside the loop.
++      lt_cv_sys_max_cmd_len=`expr "X$teststring" : ".*" 2>&1`
++      teststring=
++      # Add a significant safety factor because C++ compilers can tack on
++      # massive amounts of additional arguments before passing them to the
++      # linker.  It appears as though 1/2 is a usable value.
++      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 2`
++    fi
++    ;;
++  esac
++])
++if test -n $lt_cv_sys_max_cmd_len ; then
++  AC_MSG_RESULT($lt_cv_sys_max_cmd_len)
++else
++  AC_MSG_RESULT(none)
++fi
++max_cmd_len=$lt_cv_sys_max_cmd_len
++_LT_DECL([], [max_cmd_len], [0],
++    [What is the maximum length of a command?])
++])# LT_CMD_MAX_LEN
++
++# Old name:
++AU_ALIAS([AC_LIBTOOL_SYS_MAX_CMD_LEN], [LT_CMD_MAX_LEN])
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AC_LIBTOOL_SYS_MAX_CMD_LEN], [])
++
++
++# _LT_HEADER_DLFCN
++# ----------------
++m4_defun([_LT_HEADER_DLFCN],
++[AC_CHECK_HEADERS([dlfcn.h], [], [], [AC_INCLUDES_DEFAULT])dnl
++])# _LT_HEADER_DLFCN
++
++
++# _LT_TRY_DLOPEN_SELF (ACTION-IF-TRUE, ACTION-IF-TRUE-W-USCORE,
++#                      ACTION-IF-FALSE, ACTION-IF-CROSS-COMPILING)
++# ----------------------------------------------------------------
++m4_defun([_LT_TRY_DLOPEN_SELF],
++[m4_require([_LT_HEADER_DLFCN])dnl
++if test "$cross_compiling" = yes; then :
++  [$4]
++else
++  lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
++  lt_status=$lt_dlunknown
++  cat > conftest.$ac_ext <<_LT_EOF
++[#line __oline__ "configure"
++#include "confdefs.h"
++
++#if HAVE_DLFCN_H
++#include <dlfcn.h>
++#endif
++
++#include <stdio.h>
++
++#ifdef RTLD_GLOBAL
++#  define LT_DLGLOBAL		RTLD_GLOBAL
++#else
++#  ifdef DL_GLOBAL
++#    define LT_DLGLOBAL		DL_GLOBAL
++#  else
++#    define LT_DLGLOBAL		0
++#  endif
++#endif
++
++/* We may have to define LT_DLLAZY_OR_NOW in the command line if we
++   find out it does not work in some platform. */
++#ifndef LT_DLLAZY_OR_NOW
++#  ifdef RTLD_LAZY
++#    define LT_DLLAZY_OR_NOW		RTLD_LAZY
++#  else
++#    ifdef DL_LAZY
++#      define LT_DLLAZY_OR_NOW		DL_LAZY
++#    else
++#      ifdef RTLD_NOW
++#        define LT_DLLAZY_OR_NOW	RTLD_NOW
++#      else
++#        ifdef DL_NOW
++#          define LT_DLLAZY_OR_NOW	DL_NOW
++#        else
++#          define LT_DLLAZY_OR_NOW	0
++#        endif
++#      endif
++#    endif
++#  endif
++#endif
++
++void fnord() { int i=42;}
++int main ()
++{
++  void *self = dlopen (0, LT_DLGLOBAL|LT_DLLAZY_OR_NOW);
++  int status = $lt_dlunknown;
++
++  if (self)
++    {
++      if (dlsym (self,"fnord"))       status = $lt_dlno_uscore;
++      else if (dlsym( self,"_fnord")) status = $lt_dlneed_uscore;
++      /* dlclose (self); */
++    }
++  else
++    puts (dlerror ());
++
++  return status;
++}]
++_LT_EOF
++  if AC_TRY_EVAL(ac_link) && test -s conftest${ac_exeext} 2>/dev/null; then
++    (./conftest; exit; ) >&AS_MESSAGE_LOG_FD 2>/dev/null
++    lt_status=$?
++    case x$lt_status in
++      x$lt_dlno_uscore) $1 ;;
++      x$lt_dlneed_uscore) $2 ;;
++      x$lt_dlunknown|x*) $3 ;;
++    esac
++  else :
++    # compilation failed
++    $3
++  fi
++fi
++rm -fr conftest*
++])# _LT_TRY_DLOPEN_SELF
++
++
++# LT_SYS_DLOPEN_SELF
++# ------------------
++AC_DEFUN([LT_SYS_DLOPEN_SELF],
++[m4_require([_LT_HEADER_DLFCN])dnl
++if test "x$enable_dlopen" != xyes; then
++  enable_dlopen=unknown
++  enable_dlopen_self=unknown
++  enable_dlopen_self_static=unknown
++else
++  lt_cv_dlopen=no
++  lt_cv_dlopen_libs=
++
++  case $host_os in
++  beos*)
++    lt_cv_dlopen="load_add_on"
++    lt_cv_dlopen_libs=
++    lt_cv_dlopen_self=yes
++    ;;
++
++  mingw* | pw32* | cegcc*)
++    lt_cv_dlopen="LoadLibrary"
++    lt_cv_dlopen_libs=
++    ;;
++
++  cygwin*)
++    lt_cv_dlopen="dlopen"
++    lt_cv_dlopen_libs=
++    ;;
++
++  darwin*)
++  # if libdl is installed we need to link against it
++    AC_CHECK_LIB([dl], [dlopen],
++		[lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-ldl"],[
++    lt_cv_dlopen="dyld"
++    lt_cv_dlopen_libs=
++    lt_cv_dlopen_self=yes
++    ])
++    ;;
++
++  *)
++    AC_CHECK_FUNC([shl_load],
++	  [lt_cv_dlopen="shl_load"],
++      [AC_CHECK_LIB([dld], [shl_load],
++	    [lt_cv_dlopen="shl_load" lt_cv_dlopen_libs="-ldld"],
++	[AC_CHECK_FUNC([dlopen],
++	      [lt_cv_dlopen="dlopen"],
++	  [AC_CHECK_LIB([dl], [dlopen],
++		[lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-ldl"],
++	    [AC_CHECK_LIB([svld], [dlopen],
++		  [lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-lsvld"],
++	      [AC_CHECK_LIB([dld], [dld_link],
++		    [lt_cv_dlopen="dld_link" lt_cv_dlopen_libs="-ldld"])
++	      ])
++	    ])
++	  ])
++	])
++      ])
++    ;;
++  esac
++
++  if test "x$lt_cv_dlopen" != xno; then
++    enable_dlopen=yes
++  else
++    enable_dlopen=no
++  fi
++
++  case $lt_cv_dlopen in
++  dlopen)
++    save_CPPFLAGS="$CPPFLAGS"
++    test "x$ac_cv_header_dlfcn_h" = xyes && CPPFLAGS="$CPPFLAGS -DHAVE_DLFCN_H"
++
++    save_LDFLAGS="$LDFLAGS"
++    wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
++
++    save_LIBS="$LIBS"
++    LIBS="$lt_cv_dlopen_libs $LIBS"
++
++    AC_CACHE_CHECK([whether a program can dlopen itself],
++	  lt_cv_dlopen_self, [dnl
++	  _LT_TRY_DLOPEN_SELF(
++	    lt_cv_dlopen_self=yes, lt_cv_dlopen_self=yes,
++	    lt_cv_dlopen_self=no, lt_cv_dlopen_self=cross)
++    ])
++
++    if test "x$lt_cv_dlopen_self" = xyes; then
++      wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $lt_prog_compiler_static\"
++      AC_CACHE_CHECK([whether a statically linked program can dlopen itself],
++	  lt_cv_dlopen_self_static, [dnl
++	  _LT_TRY_DLOPEN_SELF(
++	    lt_cv_dlopen_self_static=yes, lt_cv_dlopen_self_static=yes,
++	    lt_cv_dlopen_self_static=no,  lt_cv_dlopen_self_static=cross)
++      ])
++    fi
++
++    CPPFLAGS="$save_CPPFLAGS"
++    LDFLAGS="$save_LDFLAGS"
++    LIBS="$save_LIBS"
++    ;;
++  esac
++
++  case $lt_cv_dlopen_self in
++  yes|no) enable_dlopen_self=$lt_cv_dlopen_self ;;
++  *) enable_dlopen_self=unknown ;;
++  esac
++
++  case $lt_cv_dlopen_self_static in
++  yes|no) enable_dlopen_self_static=$lt_cv_dlopen_self_static ;;
++  *) enable_dlopen_self_static=unknown ;;
++  esac
++fi
++_LT_DECL([dlopen_support], [enable_dlopen], [0],
++	 [Whether dlopen is supported])
++_LT_DECL([dlopen_self], [enable_dlopen_self], [0],
++	 [Whether dlopen of programs is supported])
++_LT_DECL([dlopen_self_static], [enable_dlopen_self_static], [0],
++	 [Whether dlopen of statically linked programs is supported])
++])# LT_SYS_DLOPEN_SELF
++
++# Old name:
++AU_ALIAS([AC_LIBTOOL_DLOPEN_SELF], [LT_SYS_DLOPEN_SELF])
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AC_LIBTOOL_DLOPEN_SELF], [])
++
++
++# _LT_COMPILER_C_O([TAGNAME])
++# ---------------------------
++# Check to see if options -c and -o are simultaneously supported by compiler.
++# This macro does not hard code the compiler like AC_PROG_CC_C_O.
++m4_defun([_LT_COMPILER_C_O],
++[m4_require([_LT_DECL_SED])dnl
++m4_require([_LT_FILEUTILS_DEFAULTS])dnl
++m4_require([_LT_TAG_COMPILER])dnl
++AC_CACHE_CHECK([if $compiler supports -c -o file.$ac_objext],
++  [_LT_TAGVAR(lt_cv_prog_compiler_c_o, $1)],
++  [_LT_TAGVAR(lt_cv_prog_compiler_c_o, $1)=no
++   $RM -r conftest 2>/dev/null
++   mkdir conftest
++   cd conftest
++   mkdir out
++   echo "$lt_simple_compile_test_code" > conftest.$ac_ext
++
++   lt_compiler_flag="-o out/conftest2.$ac_objext"
++   # Insert the option either (1) after the last *FLAGS variable, or
++   # (2) before a word containing "conftest.", or (3) at the end.
++   # Note that $ac_compile itself does not contain backslashes and begins
++   # with a dollar sign (not a hyphen), so the echo should work correctly.
++   lt_compile=`echo "$ac_compile" | $SED \
++   -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
++   -e 's: [[^ ]]*conftest\.: $lt_compiler_flag&:; t' \
++   -e 's:$: $lt_compiler_flag:'`
++   (eval echo "\"\$as_me:__oline__: $lt_compile\"" >&AS_MESSAGE_LOG_FD)
++   (eval "$lt_compile" 2>out/conftest.err)
++   ac_status=$?
++   cat out/conftest.err >&AS_MESSAGE_LOG_FD
++   echo "$as_me:__oline__: \$? = $ac_status" >&AS_MESSAGE_LOG_FD
++   if (exit $ac_status) && test -s out/conftest2.$ac_objext
++   then
++     # The compiler can only warn and ignore the option if not recognized
++     # So say no if there are warnings
++     $ECHO "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' > out/conftest.exp
++     $SED '/^$/d; /^ *+/d' out/conftest.err >out/conftest.er2
++     if test ! -s out/conftest.er2 || diff out/conftest.exp out/conftest.er2 >/dev/null; then
++       _LT_TAGVAR(lt_cv_prog_compiler_c_o, $1)=yes
++     fi
++   fi
++   chmod u+w . 2>&AS_MESSAGE_LOG_FD
++   $RM conftest*
++   # SGI C++ compiler will create directory out/ii_files/ for
++   # template instantiation
++   test -d out/ii_files && $RM out/ii_files/* && rmdir out/ii_files
++   $RM out/* && rmdir out
++   cd ..
++   $RM -r conftest
++   $RM conftest*
++])
++_LT_TAGDECL([compiler_c_o], [lt_cv_prog_compiler_c_o], [1],
++	[Does compiler simultaneously support -c and -o options?])
++])# _LT_COMPILER_C_O
++
++
++# _LT_COMPILER_FILE_LOCKS([TAGNAME])
++# ----------------------------------
++# Check to see if we can do hard links to lock some files if needed
++m4_defun([_LT_COMPILER_FILE_LOCKS],
++[m4_require([_LT_ENABLE_LOCK])dnl
++m4_require([_LT_FILEUTILS_DEFAULTS])dnl
++_LT_COMPILER_C_O([$1])
++
++hard_links="nottested"
++if test "$_LT_TAGVAR(lt_cv_prog_compiler_c_o, $1)" = no && test "$need_locks" != no; then
++  # do not overwrite the value of need_locks provided by the user
++  AC_MSG_CHECKING([if we can lock with hard links])
++  hard_links=yes
++  $RM conftest*
++  ln conftest.a conftest.b 2>/dev/null && hard_links=no
++  touch conftest.a
++  ln conftest.a conftest.b 2>&5 || hard_links=no
++  ln conftest.a conftest.b 2>/dev/null && hard_links=no
++  AC_MSG_RESULT([$hard_links])
++  if test "$hard_links" = no; then
++    AC_MSG_WARN([`$CC' does not support `-c -o', so `make -j' may be unsafe])
++    need_locks=warn
++  fi
++else
++  need_locks=no
++fi
++_LT_DECL([], [need_locks], [1], [Must we lock files when doing compilation?])
++])# _LT_COMPILER_FILE_LOCKS
++
++
++# _LT_CHECK_OBJDIR
++# ----------------
++m4_defun([_LT_CHECK_OBJDIR],
++[AC_CACHE_CHECK([for objdir], [lt_cv_objdir],
++[rm -f .libs 2>/dev/null
++mkdir .libs 2>/dev/null
++if test -d .libs; then
++  lt_cv_objdir=.libs
++else
++  # MS-DOS does not allow filenames that begin with a dot.
++  lt_cv_objdir=_libs
++fi
++rmdir .libs 2>/dev/null])
++objdir=$lt_cv_objdir
++_LT_DECL([], [objdir], [0],
++         [The name of the directory that contains temporary libtool files])dnl
++m4_pattern_allow([LT_OBJDIR])dnl
++AC_DEFINE_UNQUOTED(LT_OBJDIR, "$lt_cv_objdir/",
++  [Define to the sub-directory in which libtool stores uninstalled libraries.])
++])# _LT_CHECK_OBJDIR
++
++
++# _LT_LINKER_HARDCODE_LIBPATH([TAGNAME])
++# --------------------------------------
++# Check hardcoding attributes.
++m4_defun([_LT_LINKER_HARDCODE_LIBPATH],
++[AC_MSG_CHECKING([how to hardcode library paths into programs])
++_LT_TAGVAR(hardcode_action, $1)=
++if test -n "$_LT_TAGVAR(hardcode_libdir_flag_spec, $1)" ||
++   test -n "$_LT_TAGVAR(runpath_var, $1)" ||
++   test "X$_LT_TAGVAR(hardcode_automatic, $1)" = "Xyes" ; then
++
++  # We can hardcode non-existent directories.
++  if test "$_LT_TAGVAR(hardcode_direct, $1)" != no &&
++     # If the only mechanism to avoid hardcoding is shlibpath_var, we
++     # have to relink, otherwise we might link with an installed library
++     # when we should be linking with a yet-to-be-installed one
++     ## test "$_LT_TAGVAR(hardcode_shlibpath_var, $1)" != no &&
++     test "$_LT_TAGVAR(hardcode_minus_L, $1)" != no; then
++    # Linking always hardcodes the temporary library directory.
++    _LT_TAGVAR(hardcode_action, $1)=relink
++  else
++    # We can link without hardcoding, and we can hardcode nonexisting dirs.
++    _LT_TAGVAR(hardcode_action, $1)=immediate
++  fi
++else
++  # We cannot hardcode anything, or else we can only hardcode existing
++  # directories.
++  _LT_TAGVAR(hardcode_action, $1)=unsupported
++fi
++AC_MSG_RESULT([$_LT_TAGVAR(hardcode_action, $1)])
++
++if test "$_LT_TAGVAR(hardcode_action, $1)" = relink ||
++   test "$_LT_TAGVAR(inherit_rpath, $1)" = yes; then
++  # Fast installation is not supported
++  enable_fast_install=no
++elif test "$shlibpath_overrides_runpath" = yes ||
++     test "$enable_shared" = no; then
++  # Fast installation is not necessary
++  enable_fast_install=needless
++fi
++_LT_TAGDECL([], [hardcode_action], [0],
++    [How to hardcode a shared library path into an executable])
++])# _LT_LINKER_HARDCODE_LIBPATH
++
++
++# _LT_CMD_STRIPLIB
++# ----------------
++m4_defun([_LT_CMD_STRIPLIB],
++[m4_require([_LT_DECL_EGREP])
++striplib=
++old_striplib=
++AC_MSG_CHECKING([whether stripping libraries is possible])
++if test -n "$STRIP" && $STRIP -V 2>&1 | $GREP "GNU strip" >/dev/null; then
++  test -z "$old_striplib" && old_striplib="$STRIP --strip-debug"
++  test -z "$striplib" && striplib="$STRIP --strip-unneeded"
++  AC_MSG_RESULT([yes])
++else
++# FIXME - insert some real tests, host_os isn't really good enough
++  case $host_os in
++  darwin*)
++    if test -n "$STRIP" ; then
++      striplib="$STRIP -x"
++      old_striplib="$STRIP -S"
++      AC_MSG_RESULT([yes])
++    else
++      AC_MSG_RESULT([no])
++    fi
++    ;;
++  *)
++    AC_MSG_RESULT([no])
++    ;;
++  esac
++fi
++_LT_DECL([], [old_striplib], [1], [Commands to strip libraries])
++_LT_DECL([], [striplib], [1])
++])# _LT_CMD_STRIPLIB
++
++
++# _LT_SYS_DYNAMIC_LINKER([TAG])
++# -----------------------------
++# PORTME Fill in your ld.so characteristics
++m4_defun([_LT_SYS_DYNAMIC_LINKER],
++[AC_REQUIRE([AC_CANONICAL_HOST])dnl
++m4_require([_LT_DECL_EGREP])dnl
++m4_require([_LT_FILEUTILS_DEFAULTS])dnl
++m4_require([_LT_DECL_OBJDUMP])dnl
++m4_require([_LT_DECL_SED])dnl
++AC_MSG_CHECKING([dynamic linker characteristics])
++m4_if([$1],
++	[], [
++if test "$GCC" = yes; then
++  case $host_os in
++    darwin*) lt_awk_arg="/^libraries:/,/LR/" ;;
++    *) lt_awk_arg="/^libraries:/" ;;
++  esac
++  lt_search_path_spec=`$CC -print-search-dirs | awk $lt_awk_arg | $SED -e "s/^libraries://" -e "s,=/,/,g"`
++  if $ECHO "$lt_search_path_spec" | $GREP ';' >/dev/null ; then
++    # if the path contains ";" then we assume it to be the separator
++    # otherwise default to the standard path separator (i.e. ":") - it is
++    # assumed that no part of a normal pathname contains ";" but that should
++    # okay in the real world where ";" in dirpaths is itself problematic.
++    lt_search_path_spec=`$ECHO "$lt_search_path_spec" | $SED -e 's/;/ /g'`
++  else
++    lt_search_path_spec=`$ECHO "$lt_search_path_spec" | $SED  -e "s/$PATH_SEPARATOR/ /g"`
++  fi
++  # Ok, now we have the path, separated by spaces, we can step through it
++  # and add multilib dir if necessary.
++  lt_tmp_lt_search_path_spec=
++  lt_multi_os_dir=`$CC $CPPFLAGS $CFLAGS $LDFLAGS -print-multi-os-directory 2>/dev/null`
++  for lt_sys_path in $lt_search_path_spec; do
++    if test -d "$lt_sys_path/$lt_multi_os_dir"; then
++      lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path/$lt_multi_os_dir"
++    else
++      test -d "$lt_sys_path" && \
++	lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path"
++    fi
++  done
++  lt_search_path_spec=`$ECHO $lt_tmp_lt_search_path_spec | awk '
++BEGIN {RS=" "; FS="/|\n";} {
++  lt_foo="";
++  lt_count=0;
++  for (lt_i = NF; lt_i > 0; lt_i--) {
++    if ($lt_i != "" && $lt_i != ".") {
++      if ($lt_i == "..") {
++        lt_count++;
++      } else {
++        if (lt_count == 0) {
++          lt_foo="/" $lt_i lt_foo;
++        } else {
++          lt_count--;
++        }
++      }
++    }
++  }
++  if (lt_foo != "") { lt_freq[[lt_foo]]++; }
++  if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
++}'`
++  sys_lib_search_path_spec=`$ECHO $lt_search_path_spec`
++else
++  sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
++fi])
++library_names_spec=
++libname_spec='lib$name'
++soname_spec=
++shrext_cmds=".so"
++postinstall_cmds=
++postuninstall_cmds=
++finish_cmds=
++finish_eval=
++shlibpath_var=
++shlibpath_overrides_runpath=unknown
++version_type=none
++dynamic_linker="$host_os ld.so"
++sys_lib_dlsearch_path_spec="/lib /usr/lib"
++need_lib_prefix=unknown
++hardcode_into_libs=no
++
++# when you set need_version to no, make sure it does not cause -set_version
++# flags to be left without arguments
++need_version=unknown
++
++case $host_os in
++aix3*)
++  version_type=linux
++  library_names_spec='${libname}${release}${shared_ext}$versuffix $libname.a'
++  shlibpath_var=LIBPATH
++
++  # AIX 3 has no versioning support, so we append a major version to the name.
++  soname_spec='${libname}${release}${shared_ext}$major'
++  ;;
++
++aix[[4-9]]*)
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  hardcode_into_libs=yes
++  if test "$host_cpu" = ia64; then
++    # AIX 5 supports IA64
++    library_names_spec='${libname}${release}${shared_ext}$major ${libname}${release}${shared_ext}$versuffix $libname${shared_ext}'
++    shlibpath_var=LD_LIBRARY_PATH
++  else
++    # With GCC up to 2.95.x, collect2 would create an import file
++    # for dependence libraries.  The import file would start with
++    # the line `#! .'.  This would cause the generated library to
++    # depend on `.', always an invalid library.  This was fixed in
++    # development snapshots of GCC prior to 3.0.
++    case $host_os in
++      aix4 | aix4.[[01]] | aix4.[[01]].*)
++      if { echo '#if __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 97)'
++	   echo ' yes '
++	   echo '#endif'; } | ${CC} -E - | $GREP yes > /dev/null; then
++	:
++      else
++	can_build_shared=no
++      fi
++      ;;
++    esac
++    # AIX (on Power*) has no versioning support, so currently we can not hardcode correct
++    # soname into executable. Probably we can add versioning support to
++    # collect2, so additional links can be useful in future.
++    if test "$aix_use_runtimelinking" = yes; then
++      # If using run time linking (on AIX 4.2 or later) use lib<name>.so
++      # instead of lib<name>.a to let people know that these are not
++      # typical AIX shared libraries.
++      library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++    else
++      # We preserve .a as extension for shared libraries through AIX4.2
++      # and later when we are not doing run time linking.
++      library_names_spec='${libname}${release}.a $libname.a'
++      soname_spec='${libname}${release}${shared_ext}$major'
++    fi
++    shlibpath_var=LIBPATH
++  fi
++  ;;
++
++amigaos*)
++  case $host_cpu in
++  powerpc)
++    # Since July 2007 AmigaOS4 officially supports .so libraries.
++    # When compiling the executable, add -use-dynld -Lsobjs: to the compileline.
++    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++    ;;
++  m68k)
++    library_names_spec='$libname.ixlibrary $libname.a'
++    # Create ${libname}_ixlibrary.a entries in /sys/libs.
++    finish_eval='for lib in `ls $libdir/*.ixlibrary 2>/dev/null`; do libname=`$ECHO "X$lib" | $Xsed -e '\''s%^.*/\([[^/]]*\)\.ixlibrary$%\1%'\''`; test $RM /sys/libs/${libname}_ixlibrary.a; $show "cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a"; cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a || exit 1; done'
++    ;;
++  esac
++  ;;
++
++beos*)
++  library_names_spec='${libname}${shared_ext}'
++  dynamic_linker="$host_os ld.so"
++  shlibpath_var=LIBRARY_PATH
++  ;;
++
++bsdi[[45]]*)
++  version_type=linux
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  finish_cmds='PATH="\$PATH:/sbin" ldconfig $libdir'
++  shlibpath_var=LD_LIBRARY_PATH
++  sys_lib_search_path_spec="/shlib /usr/lib /usr/X11/lib /usr/contrib/lib /lib /usr/local/lib"
++  sys_lib_dlsearch_path_spec="/shlib /usr/lib /usr/local/lib"
++  # the default ld.so.conf also contains /usr/contrib/lib and
++  # /usr/X11R6/lib (/usr/X11 is a link to /usr/X11R6), but let us allow
++  # libtool to hard-code these into programs
++  ;;
++
++cygwin* | mingw* | pw32* | cegcc*)
++  version_type=windows
++  shrext_cmds=".dll"
++  need_version=no
++  need_lib_prefix=no
++
++  case $GCC,$host_os in
++  yes,cygwin* | yes,mingw* | yes,pw32* | yes,cegcc*)
++    library_names_spec='$libname.dll.a'
++    # DLL is installed to $(libdir)/../bin by postinstall_cmds
++    postinstall_cmds='base_file=`basename \${file}`~
++      dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i; echo \$dlname'\''`~
++      dldir=$destdir/`dirname \$dlpath`~
++      test -d \$dldir || mkdir -p \$dldir~
++      $install_prog $dir/$dlname \$dldir/$dlname~
++      chmod a+x \$dldir/$dlname~
++      if test -n '\''$stripme'\'' && test -n '\''$striplib'\''; then
++        eval '\''$striplib \$dldir/$dlname'\'' || exit \$?;
++      fi'
++    postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; echo \$dlname'\''`~
++      dlpath=$dir/\$dldll~
++       $RM \$dlpath'
++    shlibpath_overrides_runpath=yes
++
++    case $host_os in
++    cygwin*)
++      # Cygwin DLLs use 'cyg' prefix rather than 'lib'
++      soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} | $SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
++      sys_lib_search_path_spec="/usr/lib /lib/w32api /lib /usr/local/lib"
++      ;;
++    mingw* | cegcc*)
++      # MinGW DLLs use traditional 'lib' prefix
++      soname_spec='${libname}`echo ${release} | $SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
++      sys_lib_search_path_spec=`$CC -print-search-dirs | $GREP "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"`
++      if $ECHO "$sys_lib_search_path_spec" | [$GREP ';[c-zC-Z]:/' >/dev/null]; then
++        # It is most probably a Windows format PATH printed by
++        # mingw gcc, but we are running on Cygwin. Gcc prints its search
++        # path with ; separators, and with drive letters. We can handle the
++        # drive letters (cygwin fileutils understands them), so leave them,
++        # especially as we might pass files found there to a mingw objdump,
++        # which wouldn't understand a cygwinified path. Ahh.
++        sys_lib_search_path_spec=`$ECHO "$sys_lib_search_path_spec" | $SED -e 's/;/ /g'`
++      else
++        sys_lib_search_path_spec=`$ECHO "$sys_lib_search_path_spec" | $SED  -e "s/$PATH_SEPARATOR/ /g"`
++      fi
++      ;;
++    pw32*)
++      # pw32 DLLs use 'pw' prefix rather than 'lib'
++      library_names_spec='`echo ${libname} | sed -e 's/^lib/pw/'``echo ${release} | $SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
++      ;;
++    esac
++    ;;
++
++  *)
++    library_names_spec='${libname}`echo ${release} | $SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext} $libname.lib'
++    ;;
++  esac
++  dynamic_linker='Win32 ld.exe'
++  # FIXME: first we should search . and the directory the executable is in
++  shlibpath_var=PATH
++  ;;
++
++darwin* | rhapsody*)
++  dynamic_linker="$host_os dyld"
++  version_type=darwin
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${major}$shared_ext ${libname}$shared_ext'
++  soname_spec='${libname}${release}${major}$shared_ext'
++  shlibpath_overrides_runpath=yes
++  shlibpath_var=DYLD_LIBRARY_PATH
++  shrext_cmds='`test .$module = .yes && echo .so || echo .dylib`'
++m4_if([$1], [],[
++  sys_lib_search_path_spec="$sys_lib_search_path_spec /usr/local/lib"])
++  sys_lib_dlsearch_path_spec='/usr/local/lib /lib /usr/lib'
++  ;;
++
++dgux*)
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname$shared_ext'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  ;;
++
++freebsd1*)
++  dynamic_linker=no
++  ;;
++
++freebsd* | dragonfly*)
++  # DragonFly does not have aout.  When/if they implement a new
++  # versioning mechanism, adjust this.
++  if test -x /usr/bin/objformat; then
++    objformat=`/usr/bin/objformat`
++  else
++    case $host_os in
++    freebsd[[123]]*) objformat=aout ;;
++    *) objformat=elf ;;
++    esac
++  fi
++  version_type=freebsd-$objformat
++  case $version_type in
++    freebsd-elf*)
++      library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext} $libname${shared_ext}'
++      need_version=no
++      need_lib_prefix=no
++      ;;
++    freebsd-*)
++      library_names_spec='${libname}${release}${shared_ext}$versuffix $libname${shared_ext}$versuffix'
++      need_version=yes
++      ;;
++  esac
++  shlibpath_var=LD_LIBRARY_PATH
++  case $host_os in
++  freebsd2*)
++    shlibpath_overrides_runpath=yes
++    ;;
++  freebsd3.[[01]]* | freebsdelf3.[[01]]*)
++    shlibpath_overrides_runpath=yes
++    hardcode_into_libs=yes
++    ;;
++  freebsd3.[[2-9]]* | freebsdelf3.[[2-9]]* | \
++  freebsd4.[[0-5]] | freebsdelf4.[[0-5]] | freebsd4.1.1 | freebsdelf4.1.1)
++    shlibpath_overrides_runpath=no
++    hardcode_into_libs=yes
++    ;;
++  *) # from 4.6 on, and DragonFly
++    shlibpath_overrides_runpath=yes
++    hardcode_into_libs=yes
++    ;;
++  esac
++  ;;
++
++gnu*)
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  hardcode_into_libs=yes
++  ;;
++
++hpux9* | hpux10* | hpux11*)
++  # Give a soname corresponding to the major version so that dld.sl refuses to
++  # link against other versions.
++  version_type=sunos
++  need_lib_prefix=no
++  need_version=no
++  case $host_cpu in
++  ia64*)
++    shrext_cmds='.so'
++    hardcode_into_libs=yes
++    dynamic_linker="$host_os dld.so"
++    shlibpath_var=LD_LIBRARY_PATH
++    shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
++    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++    soname_spec='${libname}${release}${shared_ext}$major'
++    if test "X$HPUX_IA64_MODE" = X32; then
++      sys_lib_search_path_spec="/usr/lib/hpux32 /usr/local/lib/hpux32 /usr/local/lib"
++    else
++      sys_lib_search_path_spec="/usr/lib/hpux64 /usr/local/lib/hpux64"
++    fi
++    sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
++    ;;
++  hppa*64*)
++    shrext_cmds='.sl'
++    hardcode_into_libs=yes
++    dynamic_linker="$host_os dld.sl"
++    shlibpath_var=LD_LIBRARY_PATH # How should we handle SHLIB_PATH
++    shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
++    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++    soname_spec='${libname}${release}${shared_ext}$major'
++    sys_lib_search_path_spec="/usr/lib/pa20_64 /usr/ccs/lib/pa20_64"
++    sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
++    ;;
++  *)
++    shrext_cmds='.sl'
++    dynamic_linker="$host_os dld.sl"
++    shlibpath_var=SHLIB_PATH
++    shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
++    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++    soname_spec='${libname}${release}${shared_ext}$major'
++    ;;
++  esac
++  # HP-UX runs *really* slowly unless shared libraries are mode 555.
++  postinstall_cmds='chmod 555 $lib'
++  ;;
++
++interix[[3-9]]*)
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  dynamic_linker='Interix 3.x ld.so.1 (PE, like ELF)'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=no
++  hardcode_into_libs=yes
++  ;;
++
++irix5* | irix6* | nonstopux*)
++  case $host_os in
++    nonstopux*) version_type=nonstopux ;;
++    *)
++	if test "$lt_cv_prog_gnu_ld" = yes; then
++		version_type=linux
++	else
++		version_type=irix
++	fi ;;
++  esac
++  need_lib_prefix=no
++  need_version=no
++  soname_spec='${libname}${release}${shared_ext}$major'
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${release}${shared_ext} $libname${shared_ext}'
++  case $host_os in
++  irix5* | nonstopux*)
++    libsuff= shlibsuff=
++    ;;
++  *)
++    case $LD in # libtool.m4 will add one of these switches to LD
++    *-32|*"-32 "|*-melf32bsmip|*"-melf32bsmip ")
++      libsuff= shlibsuff= libmagic=32-bit;;
++    *-n32|*"-n32 "|*-melf32bmipn32|*"-melf32bmipn32 ")
++      libsuff=32 shlibsuff=N32 libmagic=N32;;
++    *-64|*"-64 "|*-melf64bmip|*"-melf64bmip ")
++      libsuff=64 shlibsuff=64 libmagic=64-bit;;
++    *) libsuff= shlibsuff= libmagic=never-match;;
++    esac
++    ;;
++  esac
++  shlibpath_var=LD_LIBRARY${shlibsuff}_PATH
++  shlibpath_overrides_runpath=no
++  sys_lib_search_path_spec="/usr/lib${libsuff} /lib${libsuff} /usr/local/lib${libsuff}"
++  sys_lib_dlsearch_path_spec="/usr/lib${libsuff} /lib${libsuff}"
++  hardcode_into_libs=yes
++  ;;
++
++# No shared lib support for Linux oldld, aout, or coff.
++linux*oldld* | linux*aout* | linux*coff*)
++  dynamic_linker=no
++  ;;
++
++# This must be Linux ELF.
++linux* | k*bsd*-gnu | kopensolaris*-gnu)
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=no
++  # Some binutils ld are patched to set DT_RUNPATH
++  save_LDFLAGS=$LDFLAGS
++  save_libdir=$libdir
++  eval "libdir=/foo; wl=\"$_LT_TAGVAR(lt_prog_compiler_wl, $1)\"; \
++       LDFLAGS=\"\$LDFLAGS $_LT_TAGVAR(hardcode_libdir_flag_spec, $1)\""
++  AC_LINK_IFELSE([AC_LANG_PROGRAM([],[])],
++    [AS_IF([ ($OBJDUMP -p conftest$ac_exeext) 2>/dev/null | grep "RUNPATH.*$libdir" >/dev/null],
++       [shlibpath_overrides_runpath=yes])])
++  LDFLAGS=$save_LDFLAGS
++  libdir=$save_libdir
++
++  # This implies no fast_install, which is unacceptable.
++  # Some rework will be needed to allow for fast_install
++  # before this can be enabled.
++  hardcode_into_libs=yes
++
++  # Append ld.so.conf contents to the search path
++  if test -f /etc/ld.so.conf; then
++    lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s 2>/dev/null", \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }' < /etc/ld.so.conf | $SED -e 's/#.*//;/^[	 ]*hwcap[	 ]/d;s/[:,	]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d' | tr '\n' ' '`
++    sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
++  fi
++
++  # We used to test for /lib/ld.so.1 and disable shared libraries on
++  # powerpc, because MkLinux only supported shared libraries with the
++  # GNU dynamic linker.  Since this was broken with cross compilers,
++  # most powerpc-linux boxes support dynamic linking these days and
++  # people can always --disable-shared, the test was removed, and we
++  # assume the GNU/Linux dynamic linker is in use.
++  dynamic_linker='GNU/Linux ld.so'
++  ;;
++
++netbsdelf*-gnu)
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=no
++  hardcode_into_libs=yes
++  dynamic_linker='NetBSD ld.elf_so'
++  ;;
++
++netbsd*)
++  version_type=sunos
++  need_lib_prefix=no
++  need_version=no
++  if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null; then
++    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
++    finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
++    dynamic_linker='NetBSD (a.out) ld.so'
++  else
++    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
++    soname_spec='${libname}${release}${shared_ext}$major'
++    dynamic_linker='NetBSD ld.elf_so'
++  fi
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=yes
++  hardcode_into_libs=yes
++  ;;
++
++newsos6)
++  version_type=linux
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=yes
++  ;;
++
++*nto* | *qnx*)
++  version_type=qnx
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=no
++  hardcode_into_libs=yes
++  dynamic_linker='ldqnx.so'
++  ;;
++
++openbsd*)
++  version_type=sunos
++  sys_lib_dlsearch_path_spec="/usr/lib"
++  need_lib_prefix=no
++  # Some older versions of OpenBSD (3.3 at least) *do* need versioned libs.
++  case $host_os in
++    openbsd3.3 | openbsd3.3.*)	need_version=yes ;;
++    *)				need_version=no  ;;
++  esac
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
++  finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
++  shlibpath_var=LD_LIBRARY_PATH
++  if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
++    case $host_os in
++      openbsd2.[[89]] | openbsd2.[[89]].*)
++	shlibpath_overrides_runpath=no
++	;;
++      *)
++	shlibpath_overrides_runpath=yes
++	;;
++      esac
++  else
++    shlibpath_overrides_runpath=yes
++  fi
++  ;;
++
++os2*)
++  libname_spec='$name'
++  shrext_cmds=".dll"
++  need_lib_prefix=no
++  library_names_spec='$libname${shared_ext} $libname.a'
++  dynamic_linker='OS/2 ld.exe'
++  shlibpath_var=LIBPATH
++  ;;
++
++osf3* | osf4* | osf5*)
++  version_type=osf
++  need_lib_prefix=no
++  need_version=no
++  soname_spec='${libname}${release}${shared_ext}$major'
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  shlibpath_var=LD_LIBRARY_PATH
++  sys_lib_search_path_spec="/usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc /usr/lib /usr/local/lib /var/shlib"
++  sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
++  ;;
++
++rdos*)
++  dynamic_linker=no
++  ;;
++
++solaris*)
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=yes
++  hardcode_into_libs=yes
++  # ldd complains unless libraries are executable
++  postinstall_cmds='chmod +x $lib'
++  ;;
++
++sunos4*)
++  version_type=sunos
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
++  finish_cmds='PATH="\$PATH:/usr/etc" ldconfig $libdir'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=yes
++  if test "$with_gnu_ld" = yes; then
++    need_lib_prefix=no
++  fi
++  need_version=yes
++  ;;
++
++sysv4 | sysv4.3*)
++  version_type=linux
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  case $host_vendor in
++    sni)
++      shlibpath_overrides_runpath=no
++      need_lib_prefix=no
++      runpath_var=LD_RUN_PATH
++      ;;
++    siemens)
++      need_lib_prefix=no
++      ;;
++    motorola)
++      need_lib_prefix=no
++      need_version=no
++      shlibpath_overrides_runpath=no
++      sys_lib_search_path_spec='/lib /usr/lib /usr/ccs/lib'
++      ;;
++  esac
++  ;;
++
++sysv4*MP*)
++  if test -d /usr/nec ;then
++    version_type=linux
++    library_names_spec='$libname${shared_ext}.$versuffix $libname${shared_ext}.$major $libname${shared_ext}'
++    soname_spec='$libname${shared_ext}.$major'
++    shlibpath_var=LD_LIBRARY_PATH
++  fi
++  ;;
++
++sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
++  version_type=freebsd-elf
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext} $libname${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=yes
++  hardcode_into_libs=yes
++  if test "$with_gnu_ld" = yes; then
++    sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib /usr/lib /lib'
++  else
++    sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
++    case $host_os in
++      sco3.2v5*)
++        sys_lib_search_path_spec="$sys_lib_search_path_spec /lib"
++	;;
++    esac
++  fi
++  sys_lib_dlsearch_path_spec='/usr/lib'
++  ;;
++
++tpf*)
++  # TPF is a cross-target only.  Preferred cross-host = GNU/Linux.
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=no
++  hardcode_into_libs=yes
++  ;;
++
++uts4*)
++  version_type=linux
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  ;;
++
++*)
++  dynamic_linker=no
++  ;;
++esac
++AC_MSG_RESULT([$dynamic_linker])
++test "$dynamic_linker" = no && can_build_shared=no
++
++variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
++if test "$GCC" = yes; then
++  variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
++fi
++
++if test "${lt_cv_sys_lib_search_path_spec+set}" = set; then
++  sys_lib_search_path_spec="$lt_cv_sys_lib_search_path_spec"
++fi
++if test "${lt_cv_sys_lib_dlsearch_path_spec+set}" = set; then
++  sys_lib_dlsearch_path_spec="$lt_cv_sys_lib_dlsearch_path_spec"
++fi
++
++_LT_DECL([], [variables_saved_for_relink], [1],
++    [Variables whose values should be saved in libtool wrapper scripts and
++    restored at link time])
++_LT_DECL([], [need_lib_prefix], [0],
++    [Do we need the "lib" prefix for modules?])
++_LT_DECL([], [need_version], [0], [Do we need a version for libraries?])
++_LT_DECL([], [version_type], [0], [Library versioning type])
++_LT_DECL([], [runpath_var], [0],  [Shared library runtime path variable])
++_LT_DECL([], [shlibpath_var], [0],[Shared library path variable])
++_LT_DECL([], [shlibpath_overrides_runpath], [0],
++    [Is shlibpath searched before the hard-coded library search path?])
++_LT_DECL([], [libname_spec], [1], [Format of library name prefix])
++_LT_DECL([], [library_names_spec], [1],
++    [[List of archive names.  First name is the real one, the rest are links.
++    The last name is the one that the linker finds with -lNAME]])
++_LT_DECL([], [soname_spec], [1],
++    [[The coded name of the library, if different from the real name]])
++_LT_DECL([], [postinstall_cmds], [2],
++    [Command to use after installation of a shared archive])
++_LT_DECL([], [postuninstall_cmds], [2],
++    [Command to use after uninstallation of a shared archive])
++_LT_DECL([], [finish_cmds], [2],
++    [Commands used to finish a libtool library installation in a directory])
++_LT_DECL([], [finish_eval], [1],
++    [[As "finish_cmds", except a single script fragment to be evaled but
++    not shown]])
++_LT_DECL([], [hardcode_into_libs], [0],
++    [Whether we should hardcode library paths into libraries])
++_LT_DECL([], [sys_lib_search_path_spec], [2],
++    [Compile-time system search path for libraries])
++_LT_DECL([], [sys_lib_dlsearch_path_spec], [2],
++    [Run-time system search path for libraries])
++])# _LT_SYS_DYNAMIC_LINKER
++
++
++# _LT_PATH_TOOL_PREFIX(TOOL)
++# --------------------------
++# find a file program which can recognize shared library
++AC_DEFUN([_LT_PATH_TOOL_PREFIX],
++[m4_require([_LT_DECL_EGREP])dnl
++AC_MSG_CHECKING([for $1])
++AC_CACHE_VAL(lt_cv_path_MAGIC_CMD,
++[case $MAGIC_CMD in
++[[\\/*] |  ?:[\\/]*])
++  lt_cv_path_MAGIC_CMD="$MAGIC_CMD" # Let the user override the test with a path.
++  ;;
++*)
++  lt_save_MAGIC_CMD="$MAGIC_CMD"
++  lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
++dnl $ac_dummy forces splitting on constant user-supplied paths.
++dnl POSIX.2 word splitting is done only on the output of word expansions,
++dnl not every word.  This closes a longstanding sh security hole.
++  ac_dummy="m4_if([$2], , $PATH, [$2])"
++  for ac_dir in $ac_dummy; do
++    IFS="$lt_save_ifs"
++    test -z "$ac_dir" && ac_dir=.
++    if test -f $ac_dir/$1; then
++      lt_cv_path_MAGIC_CMD="$ac_dir/$1"
++      if test -n "$file_magic_test_file"; then
++	case $deplibs_check_method in
++	"file_magic "*)
++	  file_magic_regex=`expr "$deplibs_check_method" : "file_magic \(.*\)"`
++	  MAGIC_CMD="$lt_cv_path_MAGIC_CMD"
++	  if eval $file_magic_cmd \$file_magic_test_file 2> /dev/null |
++	    $EGREP "$file_magic_regex" > /dev/null; then
++	    :
++	  else
++	    cat <<_LT_EOF 1>&2
++
++*** Warning: the command libtool uses to detect shared libraries,
++*** $file_magic_cmd, produces output that libtool cannot recognize.
++*** The result is that libtool may fail to recognize shared libraries
++*** as such.  This will affect the creation of libtool libraries that
++*** depend on shared libraries, but programs linked with such libtool
++*** libraries will work regardless of this problem.  Nevertheless, you
++*** may want to report the problem to your system manager and/or to
++*** bug-libtool@gnu.org
++
++_LT_EOF
++	  fi ;;
++	esac
++      fi
++      break
++    fi
++  done
++  IFS="$lt_save_ifs"
++  MAGIC_CMD="$lt_save_MAGIC_CMD"
++  ;;
++esac])
++MAGIC_CMD="$lt_cv_path_MAGIC_CMD"
++if test -n "$MAGIC_CMD"; then
++  AC_MSG_RESULT($MAGIC_CMD)
++else
++  AC_MSG_RESULT(no)
++fi
++_LT_DECL([], [MAGIC_CMD], [0],
++	 [Used to examine libraries when file_magic_cmd begins with "file"])dnl
++])# _LT_PATH_TOOL_PREFIX
++
++# Old name:
++AU_ALIAS([AC_PATH_TOOL_PREFIX], [_LT_PATH_TOOL_PREFIX])
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AC_PATH_TOOL_PREFIX], [])
++
++
++# _LT_PATH_MAGIC
++# --------------
++# find a file program which can recognize a shared library
++m4_defun([_LT_PATH_MAGIC],
++[_LT_PATH_TOOL_PREFIX(${ac_tool_prefix}file, /usr/bin$PATH_SEPARATOR$PATH)
++if test -z "$lt_cv_path_MAGIC_CMD"; then
++  if test -n "$ac_tool_prefix"; then
++    _LT_PATH_TOOL_PREFIX(file, /usr/bin$PATH_SEPARATOR$PATH)
++  else
++    MAGIC_CMD=:
++  fi
++fi
++])# _LT_PATH_MAGIC
++
++
++# LT_PATH_LD
++# ----------
++# find the pathname to the GNU or non-GNU linker
++AC_DEFUN([LT_PATH_LD],
++[AC_REQUIRE([AC_PROG_CC])dnl
++AC_REQUIRE([AC_CANONICAL_HOST])dnl
++AC_REQUIRE([AC_CANONICAL_BUILD])dnl
++m4_require([_LT_DECL_SED])dnl
++m4_require([_LT_DECL_EGREP])dnl
++
++AC_ARG_WITH([gnu-ld],
++    [AS_HELP_STRING([--with-gnu-ld],
++	[assume the C compiler uses GNU ld @<:@default=no@:>@])],
++    [test "$withval" = no || with_gnu_ld=yes],
++    [with_gnu_ld=no])dnl
++
++ac_prog=ld
++if test "$GCC" = yes; then
++  # Check if gcc -print-prog-name=ld gives a path.
++  AC_MSG_CHECKING([for ld used by $CC])
++  case $host in
++  *-*-mingw*)
++    # gcc leaves a trailing carriage return which upsets mingw
++    ac_prog=`($CC -print-prog-name=ld) 2>&5 | tr -d '\015'` ;;
++  *)
++    ac_prog=`($CC -print-prog-name=ld) 2>&5` ;;
++  esac
++  case $ac_prog in
++    # Accept absolute paths.
++    [[\\/]]* | ?:[[\\/]]*)
++      re_direlt='/[[^/]][[^/]]*/\.\./'
++      # Canonicalize the pathname of ld
++      ac_prog=`$ECHO "$ac_prog"| $SED 's%\\\\%/%g'`
++      while $ECHO "$ac_prog" | $GREP "$re_direlt" > /dev/null 2>&1; do
++	ac_prog=`$ECHO $ac_prog| $SED "s%$re_direlt%/%"`
++      done
++      test -z "$LD" && LD="$ac_prog"
++      ;;
++  "")
++    # If it fails, then pretend we aren't using GCC.
++    ac_prog=ld
++    ;;
++  *)
++    # If it is relative, then search for the first ld in PATH.
++    with_gnu_ld=unknown
++    ;;
++  esac
++elif test "$with_gnu_ld" = yes; then
++  AC_MSG_CHECKING([for GNU ld])
++else
++  AC_MSG_CHECKING([for non-GNU ld])
++fi
++AC_CACHE_VAL(lt_cv_path_LD,
++[if test -z "$LD"; then
++  lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
++  for ac_dir in $PATH; do
++    IFS="$lt_save_ifs"
++    test -z "$ac_dir" && ac_dir=.
++    if test -f "$ac_dir/$ac_prog" || test -f "$ac_dir/$ac_prog$ac_exeext"; then
++      lt_cv_path_LD="$ac_dir/$ac_prog"
++      # Check to see if the program is GNU ld.  I'd rather use --version,
++      # but apparently some variants of GNU ld only accept -v.
++      # Break only if it was the GNU/non-GNU ld that we prefer.
++      case `"$lt_cv_path_LD" -v 2>&1 </dev/null` in
++      *GNU* | *'with BFD'*)
++	test "$with_gnu_ld" != no && break
++	;;
++      *)
++	test "$with_gnu_ld" != yes && break
++	;;
++      esac
++    fi
++  done
++  IFS="$lt_save_ifs"
++else
++  lt_cv_path_LD="$LD" # Let the user override the test with a path.
++fi])
++LD="$lt_cv_path_LD"
++if test -n "$LD"; then
++  AC_MSG_RESULT($LD)
++else
++  AC_MSG_RESULT(no)
++fi
++test -z "$LD" && AC_MSG_ERROR([no acceptable ld found in \$PATH])
++_LT_PATH_LD_GNU
++AC_SUBST([LD])
++
++_LT_TAGDECL([], [LD], [1], [The linker used to build libraries])
++])# LT_PATH_LD
++
++# Old names:
++AU_ALIAS([AM_PROG_LD], [LT_PATH_LD])
++AU_ALIAS([AC_PROG_LD], [LT_PATH_LD])
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AM_PROG_LD], [])
++dnl AC_DEFUN([AC_PROG_LD], [])
++
++
++# _LT_PATH_LD_GNU
++#- --------------
++m4_defun([_LT_PATH_LD_GNU],
++[AC_CACHE_CHECK([if the linker ($LD) is GNU ld], lt_cv_prog_gnu_ld,
++[# I'd rather use --version here, but apparently some GNU lds only accept -v.
++case `$LD -v 2>&1 </dev/null` in
++*GNU* | *'with BFD'*)
++  lt_cv_prog_gnu_ld=yes
++  ;;
++*)
++  lt_cv_prog_gnu_ld=no
++  ;;
++esac])
++with_gnu_ld=$lt_cv_prog_gnu_ld
++])# _LT_PATH_LD_GNU
++
++
++# _LT_CMD_RELOAD
++# --------------
++# find reload flag for linker
++#   -- PORTME Some linkers may need a different reload flag.
++m4_defun([_LT_CMD_RELOAD],
++[AC_CACHE_CHECK([for $LD option to reload object files],
++  lt_cv_ld_reload_flag,
++  [lt_cv_ld_reload_flag='-r'])
++reload_flag=$lt_cv_ld_reload_flag
++case $reload_flag in
++"" | " "*) ;;
++*) reload_flag=" $reload_flag" ;;
++esac
++reload_cmds='$LD$reload_flag -o $output$reload_objs'
++case $host_os in
++  darwin*)
++    if test "$GCC" = yes; then
++      reload_cmds='$LTCC $LTCFLAGS -nostdlib ${wl}-r -o $output$reload_objs'
++    else
++      reload_cmds='$LD$reload_flag -o $output$reload_objs'
++    fi
++    ;;
++esac
++_LT_DECL([], [reload_flag], [1], [How to create reloadable object files])dnl
++_LT_DECL([], [reload_cmds], [2])dnl
++])# _LT_CMD_RELOAD
++
++
++# _LT_CHECK_MAGIC_METHOD
++# ----------------------
++# how to check for library dependencies
++#  -- PORTME fill in with the dynamic library characteristics
++m4_defun([_LT_CHECK_MAGIC_METHOD],
++[m4_require([_LT_DECL_EGREP])
++m4_require([_LT_DECL_OBJDUMP])
++AC_CACHE_CHECK([how to recognize dependent libraries],
++lt_cv_deplibs_check_method,
++[lt_cv_file_magic_cmd='$MAGIC_CMD'
++lt_cv_file_magic_test_file=
++lt_cv_deplibs_check_method='unknown'
++# Need to set the preceding variable on all platforms that support
++# interlibrary dependencies.
++# 'none' -- dependencies not supported.
++# `unknown' -- same as none, but documents that we really don't know.
++# 'pass_all' -- all dependencies passed with no checks.
++# 'test_compile' -- check by making test program.
++# 'file_magic [[regex]]' -- check by looking for files in library path
++# which responds to the $file_magic_cmd with a given extended regex.
++# If you have `file' or equivalent on your system and you're not sure
++# whether `pass_all' will *always* work, you probably want this one.
++
++case $host_os in
++aix[[4-9]]*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++beos*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++bsdi[[45]]*)
++  lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[ML]]SB (shared object|dynamic lib)'
++  lt_cv_file_magic_cmd='/usr/bin/file -L'
++  lt_cv_file_magic_test_file=/shlib/libc.so
++  ;;
++
++cygwin*)
++  # func_win32_libid is a shell function defined in ltmain.sh
++  lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
++  lt_cv_file_magic_cmd='func_win32_libid'
++  ;;
++
++mingw* | pw32*)
++  # Base MSYS/MinGW do not provide the 'file' command needed by
++  # func_win32_libid shell function, so use a weaker test based on 'objdump',
++  # unless we find 'file', for example because we are cross-compiling.
++  if ( file / ) >/dev/null 2>&1; then
++    lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
++    lt_cv_file_magic_cmd='func_win32_libid'
++  else
++    lt_cv_deplibs_check_method='file_magic file format pei*-i386(.*architecture: i386)?'
++    lt_cv_file_magic_cmd='$OBJDUMP -f'
++  fi
++  ;;
++
++cegcc)
++  # use the weaker test based on 'objdump'. See mingw*.
++  lt_cv_deplibs_check_method='file_magic file format pe-arm-.*little(.*architecture: arm)?'
++  lt_cv_file_magic_cmd='$OBJDUMP -f'
++  ;;
++
++darwin* | rhapsody*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++freebsd* | dragonfly*)
++  if echo __ELF__ | $CC -E - | $GREP __ELF__ > /dev/null; then
++    case $host_cpu in
++    i*86 )
++      # Not sure whether the presence of OpenBSD here was a mistake.
++      # Let's accept both of them until this is cleared up.
++      lt_cv_deplibs_check_method='file_magic (FreeBSD|OpenBSD|DragonFly)/i[[3-9]]86 (compact )?demand paged shared library'
++      lt_cv_file_magic_cmd=/usr/bin/file
++      lt_cv_file_magic_test_file=`echo /usr/lib/libc.so.*`
++      ;;
++    esac
++  else
++    lt_cv_deplibs_check_method=pass_all
++  fi
++  ;;
++
++gnu*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++hpux10.20* | hpux11*)
++  lt_cv_file_magic_cmd=/usr/bin/file
++  case $host_cpu in
++  ia64*)
++    lt_cv_deplibs_check_method='file_magic (s[[0-9]][[0-9]][[0-9]]|ELF-[[0-9]][[0-9]]) shared object file - IA64'
++    lt_cv_file_magic_test_file=/usr/lib/hpux32/libc.so
++    ;;
++  hppa*64*)
++    [lt_cv_deplibs_check_method='file_magic (s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared object file - PA-RISC [0-9].[0-9]']
++    lt_cv_file_magic_test_file=/usr/lib/pa20_64/libc.sl
++    ;;
++  *)
++    lt_cv_deplibs_check_method='file_magic (s[[0-9]][[0-9]][[0-9]]|PA-RISC[[0-9]].[[0-9]]) shared library'
++    lt_cv_file_magic_test_file=/usr/lib/libc.sl
++    ;;
++  esac
++  ;;
++
++interix[[3-9]]*)
++  # PIC code is broken on Interix 3.x, that's why |\.a not |_pic\.a here
++  lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|\.a)$'
++  ;;
++
++irix5* | irix6* | nonstopux*)
++  case $LD in
++  *-32|*"-32 ") libmagic=32-bit;;
++  *-n32|*"-n32 ") libmagic=N32;;
++  *-64|*"-64 ") libmagic=64-bit;;
++  *) libmagic=never-match;;
++  esac
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++# This must be Linux ELF.
++linux* | k*bsd*-gnu | kopensolaris*-gnu)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++netbsd* | netbsdelf*-gnu)
++  if echo __ELF__ | $CC -E - | $GREP __ELF__ > /dev/null; then
++    lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so\.[[0-9]]+\.[[0-9]]+|_pic\.a)$'
++  else
++    lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|_pic\.a)$'
++  fi
++  ;;
++
++newos6*)
++  lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[ML]]SB (executable|dynamic lib)'
++  lt_cv_file_magic_cmd=/usr/bin/file
++  lt_cv_file_magic_test_file=/usr/lib/libnls.so
++  ;;
++
++*nto* | *qnx*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++openbsd*)
++  if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
++    lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so\.[[0-9]]+\.[[0-9]]+|\.so|_pic\.a)$'
++  else
++    lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so\.[[0-9]]+\.[[0-9]]+|_pic\.a)$'
++  fi
++  ;;
++
++osf3* | osf4* | osf5*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++rdos*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++solaris*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++sysv4 | sysv4.3*)
++  case $host_vendor in
++  motorola)
++    lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[ML]]SB (shared object|dynamic lib) M[[0-9]][[0-9]]* Version [[0-9]]'
++    lt_cv_file_magic_test_file=`echo /usr/lib/libc.so*`
++    ;;
++  ncr)
++    lt_cv_deplibs_check_method=pass_all
++    ;;
++  sequent)
++    lt_cv_file_magic_cmd='/bin/file'
++    lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[LM]]SB (shared object|dynamic lib )'
++    ;;
++  sni)
++    lt_cv_file_magic_cmd='/bin/file'
++    lt_cv_deplibs_check_method="file_magic ELF [[0-9]][[0-9]]*-bit [[LM]]SB dynamic lib"
++    lt_cv_file_magic_test_file=/lib/libc.so
++    ;;
++  siemens)
++    lt_cv_deplibs_check_method=pass_all
++    ;;
++  pc)
++    lt_cv_deplibs_check_method=pass_all
++    ;;
++  esac
++  ;;
++
++tpf*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++esac
++])
++file_magic_cmd=$lt_cv_file_magic_cmd
++deplibs_check_method=$lt_cv_deplibs_check_method
++test -z "$deplibs_check_method" && deplibs_check_method=unknown
++
++_LT_DECL([], [deplibs_check_method], [1],
++    [Method to check whether dependent libraries are shared objects])
++_LT_DECL([], [file_magic_cmd], [1],
++    [Command to use when deplibs_check_method == "file_magic"])
++])# _LT_CHECK_MAGIC_METHOD
++
++
++# LT_PATH_NM
++# ----------
++# find the pathname to a BSD- or MS-compatible name lister
++AC_DEFUN([LT_PATH_NM],
++[AC_REQUIRE([AC_PROG_CC])dnl
++AC_CACHE_CHECK([for BSD- or MS-compatible name lister (nm)], lt_cv_path_NM,
++[if test -n "$NM"; then
++  # Let the user override the test.
++  lt_cv_path_NM="$NM"
++else
++  lt_nm_to_check="${ac_tool_prefix}nm"
++  if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
++    lt_nm_to_check="$lt_nm_to_check nm"
++  fi
++  for lt_tmp_nm in $lt_nm_to_check; do
++    lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
++    for ac_dir in $PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin; do
++      IFS="$lt_save_ifs"
++      test -z "$ac_dir" && ac_dir=.
++      tmp_nm="$ac_dir/$lt_tmp_nm"
++      if test -f "$tmp_nm" || test -f "$tmp_nm$ac_exeext" ; then
++	# Check to see if the nm accepts a BSD-compat flag.
++	# Adding the `sed 1q' prevents false positives on HP-UX, which says:
++	#   nm: unknown option "B" ignored
++	# Tru64's nm complains that /dev/null is an invalid object file
++	case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
++	*/dev/null* | *'Invalid file or object type'*)
++	  lt_cv_path_NM="$tmp_nm -B"
++	  break
++	  ;;
++	*)
++	  case `"$tmp_nm" -p /dev/null 2>&1 | sed '1q'` in
++	  */dev/null*)
++	    lt_cv_path_NM="$tmp_nm -p"
++	    break
++	    ;;
++	  *)
++	    lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
++	    continue # so that we can try to find one that supports BSD flags
++	    ;;
++	  esac
++	  ;;
++	esac
++      fi
++    done
++    IFS="$lt_save_ifs"
++  done
++  : ${lt_cv_path_NM=no}
++fi])
++if test "$lt_cv_path_NM" != "no"; then
++  NM="$lt_cv_path_NM"
++else
++  # Didn't find any BSD compatible name lister, look for dumpbin.
++  AC_CHECK_TOOLS(DUMPBIN, ["dumpbin -symbols" "link -dump -symbols"], :)
++  AC_SUBST([DUMPBIN])
++  if test "$DUMPBIN" != ":"; then
++    NM="$DUMPBIN"
++  fi
++fi
++test -z "$NM" && NM=nm
++AC_SUBST([NM])
++_LT_DECL([], [NM], [1], [A BSD- or MS-compatible name lister])dnl
++
++AC_CACHE_CHECK([the name lister ($NM) interface], [lt_cv_nm_interface],
++  [lt_cv_nm_interface="BSD nm"
++  echo "int some_variable = 0;" > conftest.$ac_ext
++  (eval echo "\"\$as_me:__oline__: $ac_compile\"" >&AS_MESSAGE_LOG_FD)
++  (eval "$ac_compile" 2>conftest.err)
++  cat conftest.err >&AS_MESSAGE_LOG_FD
++  (eval echo "\"\$as_me:__oline__: $NM \\\"conftest.$ac_objext\\\"\"" >&AS_MESSAGE_LOG_FD)
++  (eval "$NM \"conftest.$ac_objext\"" 2>conftest.err > conftest.out)
++  cat conftest.err >&AS_MESSAGE_LOG_FD
++  (eval echo "\"\$as_me:__oline__: output\"" >&AS_MESSAGE_LOG_FD)
++  cat conftest.out >&AS_MESSAGE_LOG_FD
++  if $GREP 'External.*some_variable' conftest.out > /dev/null; then
++    lt_cv_nm_interface="MS dumpbin"
++  fi
++  rm -f conftest*])
++])# LT_PATH_NM
++
++# Old names:
++AU_ALIAS([AM_PROG_NM], [LT_PATH_NM])
++AU_ALIAS([AC_PROG_NM], [LT_PATH_NM])
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AM_PROG_NM], [])
++dnl AC_DEFUN([AC_PROG_NM], [])
++
++
++# LT_LIB_M
++# --------
++# check for math library
++AC_DEFUN([LT_LIB_M],
++[AC_REQUIRE([AC_CANONICAL_HOST])dnl
++LIBM=
++case $host in
++*-*-beos* | *-*-cygwin* | *-*-pw32* | *-*-darwin*)
++  # These system don't have libm, or don't need it
++  ;;
++*-ncr-sysv4.3*)
++  AC_CHECK_LIB(mw, _mwvalidcheckl, LIBM="-lmw")
++  AC_CHECK_LIB(m, cos, LIBM="$LIBM -lm")
++  ;;
++*)
++  AC_CHECK_LIB(m, cos, LIBM="-lm")
++  ;;
++esac
++AC_SUBST([LIBM])
++])# LT_LIB_M
++
++# Old name:
++AU_ALIAS([AC_CHECK_LIBM], [LT_LIB_M])
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AC_CHECK_LIBM], [])
++
++
++# _LT_COMPILER_NO_RTTI([TAGNAME])
++# -------------------------------
++m4_defun([_LT_COMPILER_NO_RTTI],
++[m4_require([_LT_TAG_COMPILER])dnl
++
++_LT_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)=
++
++if test "$GCC" = yes; then
++  _LT_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)=' -fno-builtin'
++
++  _LT_COMPILER_OPTION([if $compiler supports -fno-rtti -fno-exceptions],
++    lt_cv_prog_compiler_rtti_exceptions,
++    [-fno-rtti -fno-exceptions], [],
++    [_LT_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)="$_LT_TAGVAR(lt_prog_compiler_no_builtin_flag, $1) -fno-rtti -fno-exceptions"])
++fi
++_LT_TAGDECL([no_builtin_flag], [lt_prog_compiler_no_builtin_flag], [1],
++	[Compiler flag to turn off builtin functions])
++])# _LT_COMPILER_NO_RTTI
++
++
++# _LT_CMD_GLOBAL_SYMBOLS
++# ----------------------
++m4_defun([_LT_CMD_GLOBAL_SYMBOLS],
++[AC_REQUIRE([AC_CANONICAL_HOST])dnl
++AC_REQUIRE([AC_PROG_CC])dnl
++AC_REQUIRE([LT_PATH_NM])dnl
++AC_REQUIRE([LT_PATH_LD])dnl
++m4_require([_LT_DECL_SED])dnl
++m4_require([_LT_DECL_EGREP])dnl
++m4_require([_LT_TAG_COMPILER])dnl
++
++# Check for command to grab the raw symbol name followed by C symbol from nm.
++AC_MSG_CHECKING([command to parse $NM output from $compiler object])
++AC_CACHE_VAL([lt_cv_sys_global_symbol_pipe],
++[
++# These are sane defaults that work on at least a few old systems.
++# [They come from Ultrix.  What could be older than Ultrix?!! ;)]
++
++# Character class describing NM global symbol codes.
++symcode='[[BCDEGRST]]'
++
++# Regexp to match symbols that can be accessed directly from C.
++sympat='\([[_A-Za-z]][[_A-Za-z0-9]]*\)'
++
++# Define system-specific variables.
++case $host_os in
++aix*)
++  symcode='[[BCDT]]'
++  ;;
++cygwin* | mingw* | pw32* | cegcc*)
++  symcode='[[ABCDGISTW]]'
++  ;;
++hpux*)
++  if test "$host_cpu" = ia64; then
++    symcode='[[ABCDEGRST]]'
++  fi
++  ;;
++irix* | nonstopux*)
++  symcode='[[BCDEGRST]]'
++  ;;
++osf*)
++  symcode='[[BCDEGQRST]]'
++  ;;
++solaris*)
++  symcode='[[BDRT]]'
++  ;;
++sco3.2v5*)
++  symcode='[[DT]]'
++  ;;
++sysv4.2uw2*)
++  symcode='[[DT]]'
++  ;;
++sysv5* | sco5v6* | unixware* | OpenUNIX*)
++  symcode='[[ABDT]]'
++  ;;
++sysv4)
++  symcode='[[DFNSTU]]'
++  ;;
++esac
++
++# If we're using GNU nm, then use its standard symbol codes.
++case `$NM -V 2>&1` in
++*GNU* | *'with BFD'*)
++  symcode='[[ABCDGIRSTW]]' ;;
++esac
++
++# Transform an extracted symbol line into a proper C declaration.
++# Some systems (esp. on ia64) link data and code symbols differently,
++# so use this general approach.
++lt_cv_sys_global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern int \1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'"
++
++# Transform an extracted symbol line into symbol name and symbol address
++lt_cv_sys_global_symbol_to_c_name_address="sed -n -e 's/^: \([[^ ]]*\) $/  {\\\"\1\\\", (void *) 0},/p' -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/  {\"\2\", (void *) \&\2},/p'"
++lt_cv_sys_global_symbol_to_c_name_address_lib_prefix="sed -n -e 's/^: \([[^ ]]*\) $/  {\\\"\1\\\", (void *) 0},/p' -e 's/^$symcode* \([[^ ]]*\) \(lib[[^ ]]*\)$/  {\"\2\", (void *) \&\2},/p' -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/  {\"lib\2\", (void *) \&\2},/p'"
++
++# Handle CRLF in mingw tool chain
++opt_cr=
++case $build_os in
++mingw*)
++  opt_cr=`$ECHO 'x\{0,1\}' | tr x '\015'` # option cr in regexp
++  ;;
++esac
++
++# Try without a prefix underscore, then with it.
++for ac_symprfx in "" "_"; do
++
++  # Transform symcode, sympat, and symprfx into a raw symbol and a C symbol.
++  symxfrm="\\1 $ac_symprfx\\2 \\2"
++
++  # Write the raw and C identifiers.
++  if test "$lt_cv_nm_interface" = "MS dumpbin"; then
++    # Fake it for dumpbin and say T for any non-static function
++    # and D for any global variable.
++    # Also find C++ and __fastcall symbols from MSVC++,
++    # which start with @ or ?.
++    lt_cv_sys_global_symbol_pipe="$AWK ['"\
++"     {last_section=section; section=\$ 3};"\
++"     /Section length .*#relocs.*(pick any)/{hide[last_section]=1};"\
++"     \$ 0!~/External *\|/{next};"\
++"     / 0+ UNDEF /{next}; / UNDEF \([^|]\)*()/{next};"\
++"     {if(hide[section]) next};"\
++"     {f=0}; \$ 0~/\(\).*\|/{f=1}; {printf f ? \"T \" : \"D \"};"\
++"     {split(\$ 0, a, /\||\r/); split(a[2], s)};"\
++"     s[1]~/^[@?]/{print s[1], s[1]; next};"\
++"     s[1]~prfx {split(s[1],t,\"@\"); print t[1], substr(t[1],length(prfx))}"\
++"     ' prfx=^$ac_symprfx]"
++  else
++    lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[[	 ]]\($symcode$symcode*\)[[	 ]][[	 ]]*$ac_symprfx$sympat$opt_cr$/$symxfrm/p'"
++  fi
++
++  # Check to see that the pipe works correctly.
++  pipe_works=no
++
++  rm -f conftest*
++  cat > conftest.$ac_ext <<_LT_EOF
++#ifdef __cplusplus
++extern "C" {
++#endif
++char nm_test_var;
++void nm_test_func(void);
++void nm_test_func(void){}
++#ifdef __cplusplus
++}
++#endif
++int main(){nm_test_var='a';nm_test_func();return(0);}
++_LT_EOF
++
++  if AC_TRY_EVAL(ac_compile); then
++    # Now try to grab the symbols.
++    nlist=conftest.nm
++    if AC_TRY_EVAL(NM conftest.$ac_objext \| $lt_cv_sys_global_symbol_pipe \> $nlist) && test -s "$nlist"; then
++      # Try sorting and uniquifying the output.
++      if sort "$nlist" | uniq > "$nlist"T; then
++	mv -f "$nlist"T "$nlist"
++      else
++	rm -f "$nlist"T
++      fi
++
++      # Make sure that we snagged all the symbols we need.
++      if $GREP ' nm_test_var$' "$nlist" >/dev/null; then
++	if $GREP ' nm_test_func$' "$nlist" >/dev/null; then
++	  cat <<_LT_EOF > conftest.$ac_ext
++#ifdef __cplusplus
++extern "C" {
++#endif
++
++_LT_EOF
++	  # Now generate the symbol file.
++	  eval "$lt_cv_sys_global_symbol_to_cdecl"' < "$nlist" | $GREP -v main >> conftest.$ac_ext'
++
++	  cat <<_LT_EOF >> conftest.$ac_ext
++
++/* The mapping between symbol names and symbols.  */
++const struct {
++  const char *name;
++  void       *address;
++}
++lt__PROGRAM__LTX_preloaded_symbols[[]] =
++{
++  { "@PROGRAM@", (void *) 0 },
++_LT_EOF
++	  $SED "s/^$symcode$symcode* \(.*\) \(.*\)$/  {\"\2\", (void *) \&\2},/" < "$nlist" | $GREP -v main >> conftest.$ac_ext
++	  cat <<\_LT_EOF >> conftest.$ac_ext
++  {0, (void *) 0}
++};
++
++/* This works around a problem in FreeBSD linker */
++#ifdef FREEBSD_WORKAROUND
++static const void *lt_preloaded_setup() {
++  return lt__PROGRAM__LTX_preloaded_symbols;
++}
++#endif
++
++#ifdef __cplusplus
++}
++#endif
++_LT_EOF
++	  # Now try linking the two files.
++	  mv conftest.$ac_objext conftstm.$ac_objext
++	  lt_save_LIBS="$LIBS"
++	  lt_save_CFLAGS="$CFLAGS"
++	  LIBS="conftstm.$ac_objext"
++	  CFLAGS="$CFLAGS$_LT_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)"
++	  if AC_TRY_EVAL(ac_link) && test -s conftest${ac_exeext}; then
++	    pipe_works=yes
++	  fi
++	  LIBS="$lt_save_LIBS"
++	  CFLAGS="$lt_save_CFLAGS"
++	else
++	  echo "cannot find nm_test_func in $nlist" >&AS_MESSAGE_LOG_FD
++	fi
++      else
++	echo "cannot find nm_test_var in $nlist" >&AS_MESSAGE_LOG_FD
++      fi
++    else
++      echo "cannot run $lt_cv_sys_global_symbol_pipe" >&AS_MESSAGE_LOG_FD
++    fi
++  else
++    echo "$progname: failed program was:" >&AS_MESSAGE_LOG_FD
++    cat conftest.$ac_ext >&5
++  fi
++  rm -rf conftest* conftst*
++
++  # Do not use the global_symbol_pipe unless it works.
++  if test "$pipe_works" = yes; then
++    break
++  else
++    lt_cv_sys_global_symbol_pipe=
++  fi
++done
++])
++if test -z "$lt_cv_sys_global_symbol_pipe"; then
++  lt_cv_sys_global_symbol_to_cdecl=
++fi
++if test -z "$lt_cv_sys_global_symbol_pipe$lt_cv_sys_global_symbol_to_cdecl"; then
++  AC_MSG_RESULT(failed)
++else
++  AC_MSG_RESULT(ok)
++fi
++
++_LT_DECL([global_symbol_pipe], [lt_cv_sys_global_symbol_pipe], [1],
++    [Take the output of nm and produce a listing of raw symbols and C names])
++_LT_DECL([global_symbol_to_cdecl], [lt_cv_sys_global_symbol_to_cdecl], [1],
++    [Transform the output of nm in a proper C declaration])
++_LT_DECL([global_symbol_to_c_name_address],
++    [lt_cv_sys_global_symbol_to_c_name_address], [1],
++    [Transform the output of nm in a C name address pair])
++_LT_DECL([global_symbol_to_c_name_address_lib_prefix],
++    [lt_cv_sys_global_symbol_to_c_name_address_lib_prefix], [1],
++    [Transform the output of nm in a C name address pair when lib prefix is needed])
++]) # _LT_CMD_GLOBAL_SYMBOLS
++
++
++# _LT_COMPILER_PIC([TAGNAME])
++# ---------------------------
++m4_defun([_LT_COMPILER_PIC],
++[m4_require([_LT_TAG_COMPILER])dnl
++_LT_TAGVAR(lt_prog_compiler_wl, $1)=
++_LT_TAGVAR(lt_prog_compiler_pic, $1)=
++_LT_TAGVAR(lt_prog_compiler_static, $1)=
++
++AC_MSG_CHECKING([for $compiler option to produce PIC])
++m4_if([$1], [CXX], [
++  # C++ specific cases for pic, static, wl, etc.
++  if test "$GXX" = yes; then
++    _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++    _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
++
++    case $host_os in
++    aix*)
++      # All AIX code is PIC.
++      if test "$host_cpu" = ia64; then
++	# AIX 5 now supports IA64 processor
++	_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++      fi
++      ;;
++
++    amigaos*)
++      case $host_cpu in
++      powerpc)
++            # see comment about AmigaOS4 .so support
++            _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
++        ;;
++      m68k)
++            # FIXME: we need at least 68020 code to build shared libraries, but
++            # adding the `-m68020' flag to GCC prevents building anything better,
++            # like `-m68040'.
++            _LT_TAGVAR(lt_prog_compiler_pic, $1)='-m68020 -resident32 -malways-restore-a4'
++        ;;
++      esac
++      ;;
++
++    beos* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
++      # PIC is the default for these OSes.
++      ;;
++    mingw* | cygwin* | os2* | pw32* | cegcc*)
++      # This hack is so that the source file can tell whether it is being
++      # built for inclusion in a dll (and should export symbols for example).
++      # Although the cygwin gcc ignores -fPIC, still need this for old-style
++      # (--disable-auto-import) libraries
++      m4_if([$1], [GCJ], [],
++	[_LT_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'])
++      ;;
++    darwin* | rhapsody*)
++      # PIC is the default on this platform
++      # Common symbols not allowed in MH_DYLIB files
++      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fno-common'
++      ;;
++    *djgpp*)
++      # DJGPP does not support shared libraries at all
++      _LT_TAGVAR(lt_prog_compiler_pic, $1)=
++      ;;
++    interix[[3-9]]*)
++      # Interix 3.x gcc -fpic/-fPIC options generate broken code.
++      # Instead, we relocate shared libraries at runtime.
++      ;;
++    sysv4*MP*)
++      if test -d /usr/nec; then
++	_LT_TAGVAR(lt_prog_compiler_pic, $1)=-Kconform_pic
++      fi
++      ;;
++    hpux*)
++      # PIC is the default for 64-bit PA HP-UX, but not for 32-bit
++      # PA HP-UX.  On IA64 HP-UX, PIC is the default but the pic flag
++      # sets the default TLS model and affects inlining.
++      case $host_cpu in
++      hppa*64*)
++	;;
++      *)
++	_LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
++	;;
++      esac
++      ;;
++    *qnx* | *nto*)
++      # QNX uses GNU C++, but need to define -shared option too, otherwise
++      # it will coredump.
++      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC -shared'
++      ;;
++    *)
++      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
++      ;;
++    esac
++  else
++    case $host_os in
++      aix[[4-9]]*)
++	# All AIX code is PIC.
++	if test "$host_cpu" = ia64; then
++	  # AIX 5 now supports IA64 processor
++	  _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++	else
++	  _LT_TAGVAR(lt_prog_compiler_static, $1)='-bnso -bI:/lib/syscalls.exp'
++	fi
++	;;
++      chorus*)
++	case $cc_basename in
++	cxch68*)
++	  # Green Hills C++ Compiler
++	  # _LT_TAGVAR(lt_prog_compiler_static, $1)="--no_auto_instantiation -u __main -u __premain -u _abort -r $COOL_DIR/lib/libOrb.a $MVME_DIR/lib/CC/libC.a $MVME_DIR/lib/classix/libcx.s.a"
++	  ;;
++	esac
++	;;
++      dgux*)
++	case $cc_basename in
++	  ec++*)
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
++	    ;;
++	  ghcx*)
++	    # Green Hills C++ Compiler
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
++	    ;;
++	  *)
++	    ;;
++	esac
++	;;
++      freebsd* | dragonfly*)
++	# FreeBSD uses GNU C++
++	;;
++      hpux9* | hpux10* | hpux11*)
++	case $cc_basename in
++	  CC*)
++	    _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	    _LT_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
++	    if test "$host_cpu" != ia64; then
++	      _LT_TAGVAR(lt_prog_compiler_pic, $1)='+Z'
++	    fi
++	    ;;
++	  aCC*)
++	    _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	    _LT_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
++	    case $host_cpu in
++	    hppa*64*|ia64*)
++	      # +Z the default
++	      ;;
++	    *)
++	      _LT_TAGVAR(lt_prog_compiler_pic, $1)='+Z'
++	      ;;
++	    esac
++	    ;;
++	  *)
++	    ;;
++	esac
++	;;
++      interix*)
++	# This is c89, which is MS Visual C++ (no shared libs)
++	# Anyone wants to do a port?
++	;;
++      irix5* | irix6* | nonstopux*)
++	case $cc_basename in
++	  CC*)
++	    _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	    _LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
++	    # CC pic flag -KPIC is the default.
++	    ;;
++	  *)
++	    ;;
++	esac
++	;;
++      linux* | k*bsd*-gnu | kopensolaris*-gnu)
++	case $cc_basename in
++	  KCC*)
++	    # KAI C++ Compiler
++	    _LT_TAGVAR(lt_prog_compiler_wl, $1)='--backend -Wl,'
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
++	    ;;
++	  ecpc* )
++	    # old Intel C++ for x86_64 which still supported -KPIC.
++	    _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
++	    _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
++	    ;;
++	  icpc* )
++	    # Intel C++, used to be incompatible with GCC.
++	    # ICC 10 doesn't accept -KPIC any more.
++	    _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
++	    _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
++	    ;;
++	  pgCC* | pgcpp*)
++	    # Portland Group C++ compiler
++	    _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
++	    _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++	    ;;
++	  cxx*)
++	    # Compaq C++
++	    # Make sure the PIC flag is empty.  It appears that all Alpha
++	    # Linux and Compaq Tru64 Unix objects are PIC.
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)=
++	    _LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
++	    ;;
++	  xlc* | xlC*)
++	    # IBM XL 8.0 on PPC
++	    _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-qpic'
++	    _LT_TAGVAR(lt_prog_compiler_static, $1)='-qstaticlink'
++	    ;;
++	  *)
++	    case `$CC -V 2>&1 | sed 5q` in
++	    *Sun\ C*)
++	      # Sun C++ 5.9
++	      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
++	      _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++	      _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld '
++	      ;;
++	    esac
++	    ;;
++	esac
++	;;
++      lynxos*)
++	;;
++      m88k*)
++	;;
++      mvs*)
++	case $cc_basename in
++	  cxx*)
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-W c,exportall'
++	    ;;
++	  *)
++	    ;;
++	esac
++	;;
++      netbsd* | netbsdelf*-gnu)
++	;;
++      *qnx* | *nto*)
++        # QNX uses GNU C++, but need to define -shared option too, otherwise
++        # it will coredump.
++        _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC -shared'
++        ;;
++      osf3* | osf4* | osf5*)
++	case $cc_basename in
++	  KCC*)
++	    _LT_TAGVAR(lt_prog_compiler_wl, $1)='--backend -Wl,'
++	    ;;
++	  RCC*)
++	    # Rational C++ 2.4.1
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
++	    ;;
++	  cxx*)
++	    # Digital/Compaq C++
++	    _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	    # Make sure the PIC flag is empty.  It appears that all Alpha
++	    # Linux and Compaq Tru64 Unix objects are PIC.
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)=
++	    _LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
++	    ;;
++	  *)
++	    ;;
++	esac
++	;;
++      psos*)
++	;;
++      solaris*)
++	case $cc_basename in
++	  CC*)
++	    # Sun C++ 4.2, 5.x and Centerline C++
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
++	    _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++	    _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld '
++	    ;;
++	  gcx*)
++	    # Green Hills C++ Compiler
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-PIC'
++	    ;;
++	  *)
++	    ;;
++	esac
++	;;
++      sunos4*)
++	case $cc_basename in
++	  CC*)
++	    # Sun C++ 4.x
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
++	    _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++	    ;;
++	  lcc*)
++	    # Lucid
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
++	    ;;
++	  *)
++	    ;;
++	esac
++	;;
++      sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
++	case $cc_basename in
++	  CC*)
++	    _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
++	    _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++	    ;;
++	esac
++	;;
++      tandem*)
++	case $cc_basename in
++	  NCC*)
++	    # NonStop-UX NCC 3.20
++	    _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
++	    ;;
++	  *)
++	    ;;
++	esac
++	;;
++      vxworks*)
++	;;
++      *)
++	_LT_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no
++	;;
++    esac
++  fi
++],
++[
++  if test "$GCC" = yes; then
++    _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++    _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
++
++    case $host_os in
++      aix*)
++      # All AIX code is PIC.
++      if test "$host_cpu" = ia64; then
++	# AIX 5 now supports IA64 processor
++	_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++      fi
++      ;;
++
++    amigaos*)
++      case $host_cpu in
++      powerpc)
++            # see comment about AmigaOS4 .so support
++            _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
++        ;;
++      m68k)
++            # FIXME: we need at least 68020 code to build shared libraries, but
++            # adding the `-m68020' flag to GCC prevents building anything better,
++            # like `-m68040'.
++            _LT_TAGVAR(lt_prog_compiler_pic, $1)='-m68020 -resident32 -malways-restore-a4'
++        ;;
++      esac
++      ;;
++
++    beos* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
++      # PIC is the default for these OSes.
++      ;;
++
++    mingw* | cygwin* | pw32* | os2* | cegcc*)
++      # This hack is so that the source file can tell whether it is being
++      # built for inclusion in a dll (and should export symbols for example).
++      # Although the cygwin gcc ignores -fPIC, still need this for old-style
++      # (--disable-auto-import) libraries
++      m4_if([$1], [GCJ], [],
++	[_LT_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'])
++      ;;
++
++    darwin* | rhapsody*)
++      # PIC is the default on this platform
++      # Common symbols not allowed in MH_DYLIB files
++      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fno-common'
++      ;;
++
++    hpux*)
++      # PIC is the default for 64-bit PA HP-UX, but not for 32-bit
++      # PA HP-UX.  On IA64 HP-UX, PIC is the default but the pic flag
++      # sets the default TLS model and affects inlining.
++      case $host_cpu in
++      hppa*64*)
++	# +Z the default
++	;;
++      *)
++	_LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
++	;;
++      esac
++      ;;
++
++    interix[[3-9]]*)
++      # Interix 3.x gcc -fpic/-fPIC options generate broken code.
++      # Instead, we relocate shared libraries at runtime.
++      ;;
++
++    msdosdjgpp*)
++      # Just because we use GCC doesn't mean we suddenly get shared libraries
++      # on systems that don't support them.
++      _LT_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no
++      enable_shared=no
++      ;;
++
++    *nto* | *qnx*)
++      # QNX uses GNU C++, but need to define -shared option too, otherwise
++      # it will coredump.
++      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC -shared'
++      ;;
++
++    sysv4*MP*)
++      if test -d /usr/nec; then
++	_LT_TAGVAR(lt_prog_compiler_pic, $1)=-Kconform_pic
++      fi
++      ;;
++
++    *)
++      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
++      ;;
++    esac
++  else
++    # PORTME Check for flag to pass linker flags through the system compiler.
++    case $host_os in
++    aix*)
++      _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++      if test "$host_cpu" = ia64; then
++	# AIX 5 now supports IA64 processor
++	_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++      else
++	_LT_TAGVAR(lt_prog_compiler_static, $1)='-bnso -bI:/lib/syscalls.exp'
++      fi
++      ;;
++
++    mingw* | cygwin* | pw32* | os2* | cegcc*)
++      # This hack is so that the source file can tell whether it is being
++      # built for inclusion in a dll (and should export symbols for example).
++      m4_if([$1], [GCJ], [],
++	[_LT_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'])
++      ;;
++
++    hpux9* | hpux10* | hpux11*)
++      _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++      # PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
++      # not for PA HP-UX.
++      case $host_cpu in
++      hppa*64*|ia64*)
++	# +Z the default
++	;;
++      *)
++	_LT_TAGVAR(lt_prog_compiler_pic, $1)='+Z'
++	;;
++      esac
++      # Is there a better lt_prog_compiler_static that works with the bundled CC?
++      _LT_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
++      ;;
++
++    irix5* | irix6* | nonstopux*)
++      _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++      # PIC (with -KPIC) is the default.
++      _LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
++      ;;
++
++    linux* | k*bsd*-gnu | kopensolaris*-gnu)
++      case $cc_basename in
++      # old Intel for x86_64 which still supported -KPIC.
++      ecc*)
++	_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	_LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
++	_LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
++        ;;
++      # icc used to be incompatible with GCC.
++      # ICC 10 doesn't accept -KPIC any more.
++      icc* | ifort*)
++	_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	_LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
++	_LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
++        ;;
++      # Lahey Fortran 8.1.
++      lf95*)
++	_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	_LT_TAGVAR(lt_prog_compiler_pic, $1)='--shared'
++	_LT_TAGVAR(lt_prog_compiler_static, $1)='--static'
++	;;
++      pgcc* | pgf77* | pgf90* | pgf95*)
++        # Portland Group compilers (*not* the Pentium gcc compiler,
++	# which looks to be a dead project)
++	_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	_LT_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
++	_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++        ;;
++      ccc*)
++        _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++        # All Alpha code is PIC.
++        _LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
++        ;;
++      xl*)
++	# IBM XL C 8.0/Fortran 10.1 on PPC
++	_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	_LT_TAGVAR(lt_prog_compiler_pic, $1)='-qpic'
++	_LT_TAGVAR(lt_prog_compiler_static, $1)='-qstaticlink'
++	;;
++      *)
++	case `$CC -V 2>&1 | sed 5q` in
++	*Sun\ C*)
++	  # Sun C 5.9
++	  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
++	  _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++	  _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++	  ;;
++	*Sun\ F*)
++	  # Sun Fortran 8.3 passes all unrecognized flags to the linker
++	  _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
++	  _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++	  _LT_TAGVAR(lt_prog_compiler_wl, $1)=''
++	  ;;
++	esac
++	;;
++      esac
++      ;;
++
++    newsos6)
++      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
++      _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++      ;;
++
++    *nto* | *qnx*)
++      # QNX uses GNU C++, but need to define -shared option too, otherwise
++      # it will coredump.
++      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC -shared'
++      ;;
++
++    osf3* | osf4* | osf5*)
++      _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++      # All OSF/1 code is PIC.
++      _LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
++      ;;
++
++    rdos*)
++      _LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
++      ;;
++
++    solaris*)
++      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
++      _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++      case $cc_basename in
++      f77* | f90* | f95*)
++	_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld ';;
++      *)
++	_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,';;
++      esac
++      ;;
++
++    sunos4*)
++      _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld '
++      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-PIC'
++      _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++      ;;
++
++    sysv4 | sysv4.2uw2* | sysv4.3*)
++      _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
++      _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++      ;;
++
++    sysv4*MP*)
++      if test -d /usr/nec ;then
++	_LT_TAGVAR(lt_prog_compiler_pic, $1)='-Kconform_pic'
++	_LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++      fi
++      ;;
++
++    sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
++      _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
++      _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++      ;;
++
++    unicos*)
++      _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
++      _LT_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no
++      ;;
++
++    uts4*)
++      _LT_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
++      _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
++      ;;
++
++    *)
++      _LT_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no
++      ;;
++    esac
++  fi
++])
++case $host_os in
++  # For platforms which do not support PIC, -DPIC is meaningless:
++  *djgpp*)
++    _LT_TAGVAR(lt_prog_compiler_pic, $1)=
++    ;;
++  *)
++    _LT_TAGVAR(lt_prog_compiler_pic, $1)="$_LT_TAGVAR(lt_prog_compiler_pic, $1)@&t@m4_if([$1],[],[ -DPIC],[m4_if([$1],[CXX],[ -DPIC],[])])"
++    ;;
++esac
++AC_MSG_RESULT([$_LT_TAGVAR(lt_prog_compiler_pic, $1)])
++_LT_TAGDECL([wl], [lt_prog_compiler_wl], [1],
++	[How to pass a linker flag through the compiler])
++
++#
++# Check to make sure the PIC flag actually works.
++#
++if test -n "$_LT_TAGVAR(lt_prog_compiler_pic, $1)"; then
++  _LT_COMPILER_OPTION([if $compiler PIC flag $_LT_TAGVAR(lt_prog_compiler_pic, $1) works],
++    [_LT_TAGVAR(lt_cv_prog_compiler_pic_works, $1)],
++    [$_LT_TAGVAR(lt_prog_compiler_pic, $1)@&t@m4_if([$1],[],[ -DPIC],[m4_if([$1],[CXX],[ -DPIC],[])])], [],
++    [case $_LT_TAGVAR(lt_prog_compiler_pic, $1) in
++     "" | " "*) ;;
++     *) _LT_TAGVAR(lt_prog_compiler_pic, $1)=" $_LT_TAGVAR(lt_prog_compiler_pic, $1)" ;;
++     esac],
++    [_LT_TAGVAR(lt_prog_compiler_pic, $1)=
++     _LT_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no])
++fi
++_LT_TAGDECL([pic_flag], [lt_prog_compiler_pic], [1],
++	[Additional compiler flags for building library objects])
++
++#
++# Check to make sure the static flag actually works.
++#
++wl=$_LT_TAGVAR(lt_prog_compiler_wl, $1) eval lt_tmp_static_flag=\"$_LT_TAGVAR(lt_prog_compiler_static, $1)\"
++_LT_LINKER_OPTION([if $compiler static flag $lt_tmp_static_flag works],
++  _LT_TAGVAR(lt_cv_prog_compiler_static_works, $1),
++  $lt_tmp_static_flag,
++  [],
++  [_LT_TAGVAR(lt_prog_compiler_static, $1)=])
++_LT_TAGDECL([link_static_flag], [lt_prog_compiler_static], [1],
++	[Compiler flag to prevent dynamic linking])
++])# _LT_COMPILER_PIC
++
++
++# _LT_LINKER_SHLIBS([TAGNAME])
++# ----------------------------
++# See if the linker supports building shared libraries.
++m4_defun([_LT_LINKER_SHLIBS],
++[AC_REQUIRE([LT_PATH_LD])dnl
++AC_REQUIRE([LT_PATH_NM])dnl
++m4_require([_LT_FILEUTILS_DEFAULTS])dnl
++m4_require([_LT_DECL_EGREP])dnl
++m4_require([_LT_DECL_SED])dnl
++m4_require([_LT_CMD_GLOBAL_SYMBOLS])dnl
++m4_require([_LT_TAG_COMPILER])dnl
++AC_MSG_CHECKING([whether the $compiler linker ($LD) supports shared libraries])
++m4_if([$1], [CXX], [
++  _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols'
++  case $host_os in
++  aix[[4-9]]*)
++    # If we're using GNU nm, then we don't want the "-C" option.
++    # -C means demangle to AIX nm, but means don't demangle with GNU nm
++    if $NM -V 2>&1 | $GREP 'GNU' > /dev/null; then
++      _LT_TAGVAR(export_symbols_cmds, $1)='$NM -Bpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B")) && ([substr](\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
++    else
++      _LT_TAGVAR(export_symbols_cmds, $1)='$NM -BCpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B")) && ([substr](\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
++    fi
++    ;;
++  pw32*)
++    _LT_TAGVAR(export_symbols_cmds, $1)="$ltdll_cmds"
++  ;;
++  cygwin* | mingw* | cegcc*)
++    _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1 DATA/;/^.*[[ ]]__nm__/s/^.*[[ ]]__nm__\([[^ ]]*\)[[ ]][[^ ]]*/\1 DATA/;/^I[[ ]]/d;/^[[AITW]][[ ]]/s/.* //'\'' | sort | uniq > $export_symbols'
++  ;;
++  linux* | k*bsd*-gnu)
++    _LT_TAGVAR(link_all_deplibs, $1)=no
++  ;;
++  *)
++    _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols'
++  ;;
++  esac
++  _LT_TAGVAR(exclude_expsyms, $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*']
++], [
++  runpath_var=
++  _LT_TAGVAR(allow_undefined_flag, $1)=
++  _LT_TAGVAR(always_export_symbols, $1)=no
++  _LT_TAGVAR(archive_cmds, $1)=
++  _LT_TAGVAR(archive_expsym_cmds, $1)=
++  _LT_TAGVAR(compiler_needs_object, $1)=no
++  _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=no
++  _LT_TAGVAR(export_dynamic_flag_spec, $1)=
++  _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols'
++  _LT_TAGVAR(hardcode_automatic, $1)=no
++  _LT_TAGVAR(hardcode_direct, $1)=no
++  _LT_TAGVAR(hardcode_direct_absolute, $1)=no
++  _LT_TAGVAR(hardcode_libdir_flag_spec, $1)=
++  _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)=
++  _LT_TAGVAR(hardcode_libdir_separator, $1)=
++  _LT_TAGVAR(hardcode_minus_L, $1)=no
++  _LT_TAGVAR(hardcode_shlibpath_var, $1)=unsupported
++  _LT_TAGVAR(inherit_rpath, $1)=no
++  _LT_TAGVAR(link_all_deplibs, $1)=unknown
++  _LT_TAGVAR(module_cmds, $1)=
++  _LT_TAGVAR(module_expsym_cmds, $1)=
++  _LT_TAGVAR(old_archive_from_new_cmds, $1)=
++  _LT_TAGVAR(old_archive_from_expsyms_cmds, $1)=
++  _LT_TAGVAR(thread_safe_flag_spec, $1)=
++  _LT_TAGVAR(whole_archive_flag_spec, $1)=
++  # include_expsyms should be a list of space-separated symbols to be *always*
++  # included in the symbol list
++  _LT_TAGVAR(include_expsyms, $1)=
++  # exclude_expsyms can be an extended regexp of symbols to exclude
++  # it will be wrapped by ` (' and `)$', so one must not match beginning or
++  # end of line.  Example: `a|bc|.*d.*' will exclude the symbols `a' and `bc',
++  # as well as any symbol that contains `d'.
++  _LT_TAGVAR(exclude_expsyms, $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*']
++  # Although _GLOBAL_OFFSET_TABLE_ is a valid symbol C name, most a.out
++  # platforms (ab)use it in PIC code, but their linkers get confused if
++  # the symbol is explicitly referenced.  Since portable code cannot
++  # rely on this symbol name, it's probably fine to never include it in
++  # preloaded symbol tables.
++  # Exclude shared library initialization/finalization symbols.
++dnl Note also adjust exclude_expsyms for C++ above.
++  extract_expsyms_cmds=
++
++  case $host_os in
++  cygwin* | mingw* | pw32* | cegcc*)
++    # FIXME: the MSVC++ port hasn't been tested in a loooong time
++    # When not using gcc, we currently assume that we are using
++    # Microsoft Visual C++.
++    if test "$GCC" != yes; then
++      with_gnu_ld=no
++    fi
++    ;;
++  interix*)
++    # we just hope/assume this is gcc and not c89 (= MSVC++)
++    with_gnu_ld=yes
++    ;;
++  openbsd*)
++    with_gnu_ld=no
++    ;;
++  linux* | k*bsd*-gnu)
++    _LT_TAGVAR(link_all_deplibs, $1)=no
++    ;;
++  esac
++
++  _LT_TAGVAR(ld_shlibs, $1)=yes
++  if test "$with_gnu_ld" = yes; then
++    # If archive_cmds runs LD, not CC, wlarc should be empty
++    wlarc='${wl}'
++
++    # Set some defaults for GNU ld with shared library support. These
++    # are reset later if shared libraries are not supported. Putting them
++    # here allows them to be overridden if necessary.
++    runpath_var=LD_RUN_PATH
++    _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
++    _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
++    # ancient GNU ld didn't support --whole-archive et. al.
++    if $LD --help 2>&1 | $GREP 'no-whole-archive' > /dev/null; then
++      _LT_TAGVAR(whole_archive_flag_spec, $1)="$wlarc"'--whole-archive$convenience '"$wlarc"'--no-whole-archive'
++    else
++      _LT_TAGVAR(whole_archive_flag_spec, $1)=
++    fi
++    supports_anon_versioning=no
++    case `$LD -v 2>&1` in
++      *GNU\ gold*) supports_anon_versioning=yes ;;
++      *\ [[01]].* | *\ 2.[[0-9]].* | *\ 2.10.*) ;; # catch versions < 2.11
++      *\ 2.11.93.0.2\ *) supports_anon_versioning=yes ;; # RH7.3 ...
++      *\ 2.11.92.0.12\ *) supports_anon_versioning=yes ;; # Mandrake 8.2 ...
++      *\ 2.11.*) ;; # other 2.11 versions
++      *) supports_anon_versioning=yes ;;
++    esac
++
++    # See if GNU ld supports shared libraries.
++    case $host_os in
++    aix[[3-9]]*)
++      # On AIX/PPC, the GNU linker is very broken
++      if test "$host_cpu" != ia64; then
++	_LT_TAGVAR(ld_shlibs, $1)=no
++	cat <<_LT_EOF 1>&2
++
++*** Warning: the GNU linker, at least up to release 2.9.1, is reported
++*** to be unable to reliably create shared libraries on AIX.
++*** Therefore, libtool is disabling shared libraries support.  If you
++*** really care for shared libraries, you may want to modify your PATH
++*** so that a non-GNU linker is found, and then restart.
++
++_LT_EOF
++      fi
++      ;;
++
++    amigaos*)
++      case $host_cpu in
++      powerpc)
++            # see comment about AmigaOS4 .so support
++            _LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++            _LT_TAGVAR(archive_expsym_cmds, $1)=''
++        ;;
++      m68k)
++            _LT_TAGVAR(archive_cmds, $1)='$RM $output_objdir/a2ixlibrary.data~$ECHO "#define NAME $libname" > $output_objdir/a2ixlibrary.data~$ECHO "#define LIBRARY_ID 1" >> $output_objdir/a2ixlibrary.data~$ECHO "#define VERSION $major" >> $output_objdir/a2ixlibrary.data~$ECHO "#define REVISION $revision" >> $output_objdir/a2ixlibrary.data~$AR $AR_FLAGS $lib $libobjs~$RANLIB $lib~(cd $output_objdir && a2ixlibrary -32)'
++            _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
++            _LT_TAGVAR(hardcode_minus_L, $1)=yes
++        ;;
++      esac
++      ;;
++
++    beos*)
++      if $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null; then
++	_LT_TAGVAR(allow_undefined_flag, $1)=unsupported
++	# Joseph Beckenbach <jrb3@best.com> says some releases of gcc
++	# support --undefined.  This deserves some investigation.  FIXME
++	_LT_TAGVAR(archive_cmds, $1)='$CC -nostart $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++      else
++	_LT_TAGVAR(ld_shlibs, $1)=no
++      fi
++      ;;
++
++    cygwin* | mingw* | pw32* | cegcc*)
++      # _LT_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
++      # as there is no search path for DLLs.
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
++      _LT_TAGVAR(allow_undefined_flag, $1)=unsupported
++      _LT_TAGVAR(always_export_symbols, $1)=no
++      _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
++      _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1 DATA/'\'' | $SED -e '\''/^[[AITW]][[ ]]/s/.*[[ ]]//'\'' | sort | uniq > $export_symbols'
++
++      if $LD --help 2>&1 | $GREP 'auto-import' > /dev/null; then
++        _LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
++	# If the export-symbols file already is a .def file (1st line
++	# is EXPORTS), use it as is; otherwise, prepend...
++	_LT_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
++	  cp $export_symbols $output_objdir/$soname.def;
++	else
++	  echo EXPORTS > $output_objdir/$soname.def;
++	  cat $export_symbols >> $output_objdir/$soname.def;
++	fi~
++	$CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
++      else
++	_LT_TAGVAR(ld_shlibs, $1)=no
++      fi
++      ;;
++
++    interix[[3-9]]*)
++      _LT_TAGVAR(hardcode_direct, $1)=no
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
++      _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
++      # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
++      # Instead, shared libraries are loaded at an image base (0x10000000 by
++      # default) and relocated if they conflict, which is a slow very memory
++      # consuming and fragmenting process.  To avoid this, we pick a random,
++      # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
++      # time.  Moving up from 0x10000000 also allows more sbrk(2) space.
++      _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
++      _LT_TAGVAR(archive_expsym_cmds, $1)='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
++      ;;
++
++    gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu)
++      tmp_diet=no
++      if test "$host_os" = linux-dietlibc; then
++	case $cc_basename in
++	  diet\ *) tmp_diet=yes;;	# linux-dietlibc with static linking (!diet-dyn)
++	esac
++      fi
++      if $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null \
++	 && test "$tmp_diet" = no
++      then
++	tmp_addflag=
++	tmp_sharedflag='-shared'
++	case $cc_basename,$host_cpu in
++        pgcc*)				# Portland Group C compiler
++	  _LT_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`for conv in $convenience\"\"; do test  -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $ECHO \"$new_convenience\"` ${wl}--no-whole-archive'
++	  tmp_addflag=' $pic_flag'
++	  ;;
++	pgf77* | pgf90* | pgf95*)	# Portland Group f77 and f90 compilers
++	  _LT_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`for conv in $convenience\"\"; do test  -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $ECHO \"$new_convenience\"` ${wl}--no-whole-archive'
++	  tmp_addflag=' $pic_flag -Mnomain' ;;
++	ecc*,ia64* | icc*,ia64*)	# Intel C compiler on ia64
++	  tmp_addflag=' -i_dynamic' ;;
++	efc*,ia64* | ifort*,ia64*)	# Intel Fortran compiler on ia64
++	  tmp_addflag=' -i_dynamic -nofor_main' ;;
++	ifc* | ifort*)			# Intel Fortran compiler
++	  tmp_addflag=' -nofor_main' ;;
++	lf95*)				# Lahey Fortran 8.1
++	  _LT_TAGVAR(whole_archive_flag_spec, $1)=
++	  tmp_sharedflag='--shared' ;;
++	xl[[cC]]*)			# IBM XL C 8.0 on PPC (deal with xlf below)
++	  tmp_sharedflag='-qmkshrobj'
++	  tmp_addflag= ;;
++	esac
++	case `$CC -V 2>&1 | sed 5q` in
++	*Sun\ C*)			# Sun C 5.9
++	  _LT_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`new_convenience=; for conv in $convenience\"\"; do test -z \"$conv\" || new_convenience=\"$new_convenience,$conv\"; done; $ECHO \"$new_convenience\"` ${wl}--no-whole-archive'
++	  _LT_TAGVAR(compiler_needs_object, $1)=yes
++	  tmp_sharedflag='-G' ;;
++	*Sun\ F*)			# Sun Fortran 8.3
++	  tmp_sharedflag='-G' ;;
++	esac
++	_LT_TAGVAR(archive_cmds, $1)='$CC '"$tmp_sharedflag""$tmp_addflag"' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++
++        if test "x$supports_anon_versioning" = xyes; then
++          _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $output_objdir/$libname.ver~
++	    cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $output_objdir/$libname.ver~
++	    echo "local: *; };" >> $output_objdir/$libname.ver~
++	    $CC '"$tmp_sharedflag""$tmp_addflag"' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-version-script ${wl}$output_objdir/$libname.ver -o $lib'
++        fi
++
++	case $cc_basename in
++	xlf*)
++	  # IBM XL Fortran 10.1 on PPC cannot create shared libs itself
++	  _LT_TAGVAR(whole_archive_flag_spec, $1)='--whole-archive$convenience --no-whole-archive'
++	  _LT_TAGVAR(hardcode_libdir_flag_spec, $1)=
++	  _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='-rpath $libdir'
++	  _LT_TAGVAR(archive_cmds, $1)='$LD -shared $libobjs $deplibs $compiler_flags -soname $soname -o $lib'
++	  if test "x$supports_anon_versioning" = xyes; then
++	    _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $output_objdir/$libname.ver~
++	      cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $output_objdir/$libname.ver~
++	      echo "local: *; };" >> $output_objdir/$libname.ver~
++	      $LD -shared $libobjs $deplibs $compiler_flags -soname $soname -version-script $output_objdir/$libname.ver -o $lib'
++	  fi
++	  ;;
++	esac
++      else
++        _LT_TAGVAR(ld_shlibs, $1)=no
++      fi
++      ;;
++
++    netbsd* | netbsdelf*-gnu)
++      if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null; then
++	_LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable $libobjs $deplibs $linker_flags -o $lib'
++	wlarc=
++      else
++	_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++	_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
++      fi
++      ;;
++
++    solaris*)
++      if $LD -v 2>&1 | $GREP 'BFD 2\.8' > /dev/null; then
++	_LT_TAGVAR(ld_shlibs, $1)=no
++	cat <<_LT_EOF 1>&2
++
++*** Warning: The releases 2.8.* of the GNU linker cannot reliably
++*** create shared libraries on Solaris systems.  Therefore, libtool
++*** is disabling shared libraries support.  We urge you to upgrade GNU
++*** binutils to release 2.9.1 or newer.  Another option is to modify
++*** your PATH or compiler configuration so that the native linker is
++*** used, and then restart.
++
++_LT_EOF
++      elif $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null; then
++	_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++	_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
++      else
++	_LT_TAGVAR(ld_shlibs, $1)=no
++      fi
++      ;;
++
++    sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX*)
++      case `$LD -v 2>&1` in
++        *\ [[01]].* | *\ 2.[[0-9]].* | *\ 2.1[[0-5]].*)
++	_LT_TAGVAR(ld_shlibs, $1)=no
++	cat <<_LT_EOF 1>&2
++
++*** Warning: Releases of the GNU linker prior to 2.16.91.0.3 can not
++*** reliably create shared libraries on SCO systems.  Therefore, libtool
++*** is disabling shared libraries support.  We urge you to upgrade GNU
++*** binutils to release 2.16.91.0.3 or newer.  Another option is to modify
++*** your PATH or compiler configuration so that the native linker is
++*** used, and then restart.
++
++_LT_EOF
++	;;
++	*)
++	  # For security reasons, it is highly recommended that you always
++	  # use absolute paths for naming shared libraries, and exclude the
++	  # DT_RUNPATH tag from executables and libraries.  But doing so
++	  # requires that you compile everything twice, which is a pain.
++	  if $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null; then
++	    _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
++	    _LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++	    _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
++	  else
++	    _LT_TAGVAR(ld_shlibs, $1)=no
++	  fi
++	;;
++      esac
++      ;;
++
++    sunos4*)
++      _LT_TAGVAR(archive_cmds, $1)='$LD -assert pure-text -Bshareable -o $lib $libobjs $deplibs $linker_flags'
++      wlarc=
++      _LT_TAGVAR(hardcode_direct, $1)=yes
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      ;;
++
++    *)
++      if $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null; then
++	_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++	_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
++      else
++	_LT_TAGVAR(ld_shlibs, $1)=no
++      fi
++      ;;
++    esac
++
++    if test "$_LT_TAGVAR(ld_shlibs, $1)" = no; then
++      runpath_var=
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)=
++      _LT_TAGVAR(export_dynamic_flag_spec, $1)=
++      _LT_TAGVAR(whole_archive_flag_spec, $1)=
++    fi
++  else
++    # PORTME fill in a description of your system's linker (not GNU ld)
++    case $host_os in
++    aix3*)
++      _LT_TAGVAR(allow_undefined_flag, $1)=unsupported
++      _LT_TAGVAR(always_export_symbols, $1)=yes
++      _LT_TAGVAR(archive_expsym_cmds, $1)='$LD -o $output_objdir/$soname $libobjs $deplibs $linker_flags -bE:$export_symbols -T512 -H512 -bM:SRE~$AR $AR_FLAGS $lib $output_objdir/$soname'
++      # Note: this linker hardcodes the directories in LIBPATH if there
++      # are no directories specified by -L.
++      _LT_TAGVAR(hardcode_minus_L, $1)=yes
++      if test "$GCC" = yes && test -z "$lt_prog_compiler_static"; then
++	# Neither direct hardcoding nor static linking is supported with a
++	# broken collect2.
++	_LT_TAGVAR(hardcode_direct, $1)=unsupported
++      fi
++      ;;
++
++    aix[[4-9]]*)
++      if test "$host_cpu" = ia64; then
++	# On IA64, the linker does run time linking by default, so we don't
++	# have to do anything special.
++	aix_use_runtimelinking=no
++	exp_sym_flag='-Bexport'
++	no_entry_flag=""
++      else
++	# If we're using GNU nm, then we don't want the "-C" option.
++	# -C means demangle to AIX nm, but means don't demangle with GNU nm
++	if $NM -V 2>&1 | $GREP 'GNU' > /dev/null; then
++	  _LT_TAGVAR(export_symbols_cmds, $1)='$NM -Bpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B")) && ([substr](\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
++	else
++	  _LT_TAGVAR(export_symbols_cmds, $1)='$NM -BCpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B")) && ([substr](\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
++	fi
++	aix_use_runtimelinking=no
++
++	# Test if we are trying to use run time linking or normal
++	# AIX style linking. If -brtl is somewhere in LDFLAGS, we
++	# need to do runtime linking.
++	case $host_os in aix4.[[23]]|aix4.[[23]].*|aix[[5-9]]*)
++	  for ld_flag in $LDFLAGS; do
++	  if (test $ld_flag = "-brtl" || test $ld_flag = "-Wl,-brtl"); then
++	    aix_use_runtimelinking=yes
++	    break
++	  fi
++	  done
++	  ;;
++	esac
++
++	exp_sym_flag='-bexport'
++	no_entry_flag='-bnoentry'
++      fi
++
++      # When large executables or shared objects are built, AIX ld can
++      # have problems creating the table of contents.  If linking a library
++      # or program results in "error TOC overflow" add -mminimal-toc to
++      # CXXFLAGS/CFLAGS for g++/gcc.  In the cases where that is not
++      # enough to fix the problem, add -Wl,-bbigtoc to LDFLAGS.
++
++      _LT_TAGVAR(archive_cmds, $1)=''
++      _LT_TAGVAR(hardcode_direct, $1)=yes
++      _LT_TAGVAR(hardcode_direct_absolute, $1)=yes
++      _LT_TAGVAR(hardcode_libdir_separator, $1)=':'
++      _LT_TAGVAR(link_all_deplibs, $1)=yes
++      _LT_TAGVAR(file_list_spec, $1)='${wl}-f,'
++
++      if test "$GCC" = yes; then
++	case $host_os in aix4.[[012]]|aix4.[[012]].*)
++	# We only want to do this on AIX 4.2 and lower, the check
++	# below for broken collect2 doesn't work under 4.3+
++	  collect2name=`${CC} -print-prog-name=collect2`
++	  if test -f "$collect2name" &&
++	   strings "$collect2name" | $GREP resolve_lib_name >/dev/null
++	  then
++	  # We have reworked collect2
++	  :
++	  else
++	  # We have old collect2
++	  _LT_TAGVAR(hardcode_direct, $1)=unsupported
++	  # It fails to find uninstalled libraries when the uninstalled
++	  # path is not listed in the libpath.  Setting hardcode_minus_L
++	  # to unsupported forces relinking
++	  _LT_TAGVAR(hardcode_minus_L, $1)=yes
++	  _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
++	  _LT_TAGVAR(hardcode_libdir_separator, $1)=
++	  fi
++	  ;;
++	esac
++	shared_flag='-shared'
++	if test "$aix_use_runtimelinking" = yes; then
++	  shared_flag="$shared_flag "'${wl}-G'
++	fi
++	_LT_TAGVAR(link_all_deplibs, $1)=no
++      else
++	# not using gcc
++	if test "$host_cpu" = ia64; then
++	# VisualAge C++, Version 5.5 for AIX 5L for IA-64, Beta 3 Release
++	# chokes on -Wl,-G. The following line is correct:
++	  shared_flag='-G'
++	else
++	  if test "$aix_use_runtimelinking" = yes; then
++	    shared_flag='${wl}-G'
++	  else
++	    shared_flag='${wl}-bM:SRE'
++	  fi
++	fi
++      fi
++
++      _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-bexpall'
++      # It seems that -bexpall does not export symbols beginning with
++      # underscore (_), so it is better to generate a list of symbols to export.
++      _LT_TAGVAR(always_export_symbols, $1)=yes
++      if test "$aix_use_runtimelinking" = yes; then
++	# Warning - without using the other runtime loading flags (-brtl),
++	# -berok will link without error, but may produce a broken library.
++	_LT_TAGVAR(allow_undefined_flag, $1)='-berok'
++        # Determine the default libpath from the value encoded in an
++        # empty executable.
++        _LT_SYS_MODULE_PATH_AIX
++        _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-blibpath:$libdir:'"$aix_libpath"
++        _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then $ECHO "X${wl}${allow_undefined_flag}" | $Xsed; else :; fi` '"\${wl}$exp_sym_flag:\$export_symbols $shared_flag"
++      else
++	if test "$host_cpu" = ia64; then
++	  _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-R $libdir:/usr/lib:/lib'
++	  _LT_TAGVAR(allow_undefined_flag, $1)="-z nodefs"
++	  _LT_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$exp_sym_flag:\$export_symbols"
++	else
++	 # Determine the default libpath from the value encoded in an
++	 # empty executable.
++	 _LT_SYS_MODULE_PATH_AIX
++	 _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-blibpath:$libdir:'"$aix_libpath"
++	  # Warning - without using the other run time loading flags,
++	  # -berok will link without error, but may produce a broken library.
++	  _LT_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
++	  _LT_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
++	  # Exported symbols can be pulled into shared objects from archives
++	  _LT_TAGVAR(whole_archive_flag_spec, $1)='$convenience'
++	  _LT_TAGVAR(archive_cmds_need_lc, $1)=yes
++	  # This is similar to how AIX traditionally builds its shared libraries.
++	  _LT_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs ${wl}-bnoentry $compiler_flags ${wl}-bE:$export_symbols${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
++	fi
++      fi
++      ;;
++
++    amigaos*)
++      case $host_cpu in
++      powerpc)
++            # see comment about AmigaOS4 .so support
++            _LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++            _LT_TAGVAR(archive_expsym_cmds, $1)=''
++        ;;
++      m68k)
++            _LT_TAGVAR(archive_cmds, $1)='$RM $output_objdir/a2ixlibrary.data~$ECHO "#define NAME $libname" > $output_objdir/a2ixlibrary.data~$ECHO "#define LIBRARY_ID 1" >> $output_objdir/a2ixlibrary.data~$ECHO "#define VERSION $major" >> $output_objdir/a2ixlibrary.data~$ECHO "#define REVISION $revision" >> $output_objdir/a2ixlibrary.data~$AR $AR_FLAGS $lib $libobjs~$RANLIB $lib~(cd $output_objdir && a2ixlibrary -32)'
++            _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
++            _LT_TAGVAR(hardcode_minus_L, $1)=yes
++        ;;
++      esac
++      ;;
++
++    bsdi[[45]]*)
++      _LT_TAGVAR(export_dynamic_flag_spec, $1)=-rdynamic
++      ;;
++
++    cygwin* | mingw* | pw32* | cegcc*)
++      # When not using gcc, we currently assume that we are using
++      # Microsoft Visual C++.
++      # hardcode_libdir_flag_spec is actually meaningless, as there is
++      # no search path for DLLs.
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)=' '
++      _LT_TAGVAR(allow_undefined_flag, $1)=unsupported
++      # Tell ltmain to make .lib files, not .a files.
++      libext=lib
++      # Tell ltmain to make .dll files, not .so files.
++      shrext_cmds=".dll"
++      # FIXME: Setting linknames here is a bad hack.
++      _LT_TAGVAR(archive_cmds, $1)='$CC -o $lib $libobjs $compiler_flags `$ECHO "X$deplibs" | $Xsed -e '\''s/ -lc$//'\''` -link -dll~linknames='
++      # The linker will automatically build a .lib file if we build a DLL.
++      _LT_TAGVAR(old_archive_from_new_cmds, $1)='true'
++      # FIXME: Should let the user specify the lib program.
++      _LT_TAGVAR(old_archive_cmds, $1)='lib -OUT:$oldlib$oldobjs$old_deplibs'
++      _LT_TAGVAR(fix_srcfile_path, $1)='`cygpath -w "$srcfile"`'
++      _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
++      ;;
++
++    darwin* | rhapsody*)
++      _LT_DARWIN_LINKER_FEATURES($1)
++      ;;
++
++    dgux*)
++      _LT_TAGVAR(archive_cmds, $1)='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      ;;
++
++    freebsd1*)
++      _LT_TAGVAR(ld_shlibs, $1)=no
++      ;;
++
++    # FreeBSD 2.2.[012] allows us to include c++rt0.o to get C++ constructor
++    # support.  Future versions do this automatically, but an explicit c++rt0.o
++    # does not break anything, and helps significantly (at the cost of a little
++    # extra space).
++    freebsd2.2*)
++      _LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags /usr/lib/c++rt0.o'
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
++      _LT_TAGVAR(hardcode_direct, $1)=yes
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      ;;
++
++    # Unfortunately, older versions of FreeBSD 2 do not have this feature.
++    freebsd2*)
++      _LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags'
++      _LT_TAGVAR(hardcode_direct, $1)=yes
++      _LT_TAGVAR(hardcode_minus_L, $1)=yes
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      ;;
++
++    # FreeBSD 3 and greater uses gcc -shared to do shared libraries.
++    freebsd* | dragonfly*)
++      _LT_TAGVAR(archive_cmds, $1)='$CC -shared -o $lib $libobjs $deplibs $compiler_flags'
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
++      _LT_TAGVAR(hardcode_direct, $1)=yes
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      ;;
++
++    hpux9*)
++      if test "$GCC" = yes; then
++	_LT_TAGVAR(archive_cmds, $1)='$RM $output_objdir/$soname~$CC -shared -fPIC ${wl}+b ${wl}$install_libdir -o $output_objdir/$soname $libobjs $deplibs $compiler_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
++      else
++	_LT_TAGVAR(archive_cmds, $1)='$RM $output_objdir/$soname~$LD -b +b $install_libdir -o $output_objdir/$soname $libobjs $deplibs $linker_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
++      fi
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
++      _LT_TAGVAR(hardcode_libdir_separator, $1)=:
++      _LT_TAGVAR(hardcode_direct, $1)=yes
++
++      # hardcode_minus_L: Not really in the search PATH,
++      # but as the default location of the library.
++      _LT_TAGVAR(hardcode_minus_L, $1)=yes
++      _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
++      ;;
++
++    hpux10*)
++      if test "$GCC" = yes -a "$with_gnu_ld" = no; then
++	_LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
++      else
++	_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
++      fi
++      if test "$with_gnu_ld" = no; then
++	_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
++	_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
++	_LT_TAGVAR(hardcode_libdir_separator, $1)=:
++	_LT_TAGVAR(hardcode_direct, $1)=yes
++	_LT_TAGVAR(hardcode_direct_absolute, $1)=yes
++	_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
++	# hardcode_minus_L: Not really in the search PATH,
++	# but as the default location of the library.
++	_LT_TAGVAR(hardcode_minus_L, $1)=yes
++      fi
++      ;;
++
++    hpux11*)
++      if test "$GCC" = yes -a "$with_gnu_ld" = no; then
++	case $host_cpu in
++	hppa*64*)
++	  _LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
++	  ;;
++	ia64*)
++	  _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
++	  ;;
++	*)
++	  _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
++	  ;;
++	esac
++      else
++	case $host_cpu in
++	hppa*64*)
++	  _LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
++	  ;;
++	ia64*)
++	  _LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
++	  ;;
++	*)
++	  _LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
++	  ;;
++	esac
++      fi
++      if test "$with_gnu_ld" = no; then
++	_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
++	_LT_TAGVAR(hardcode_libdir_separator, $1)=:
++
++	case $host_cpu in
++	hppa*64*|ia64*)
++	  _LT_TAGVAR(hardcode_direct, $1)=no
++	  _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++	  ;;
++	*)
++	  _LT_TAGVAR(hardcode_direct, $1)=yes
++	  _LT_TAGVAR(hardcode_direct_absolute, $1)=yes
++	  _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
++
++	  # hardcode_minus_L: Not really in the search PATH,
++	  # but as the default location of the library.
++	  _LT_TAGVAR(hardcode_minus_L, $1)=yes
++	  ;;
++	esac
++      fi
++      ;;
++
++    irix5* | irix6* | nonstopux*)
++      if test "$GCC" = yes; then
++	_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && $ECHO "X${wl}-set_version ${wl}$verstring" | $Xsed` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
++	# Try to use the -exported_symbol ld option, if it does not
++	# work, assume that -exports_file does not work either and
++	# implicitly export all symbols.
++        save_LDFLAGS="$LDFLAGS"
++        LDFLAGS="$LDFLAGS -shared ${wl}-exported_symbol ${wl}foo ${wl}-update_registry ${wl}/dev/null"
++        AC_LINK_IFELSE(int foo(void) {},
++          _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && $ECHO "X${wl}-set_version ${wl}$verstring" | $Xsed` ${wl}-update_registry ${wl}${output_objdir}/so_locations ${wl}-exports_file ${wl}$export_symbols -o $lib'
++        )
++        LDFLAGS="$save_LDFLAGS"
++      else
++	_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -soname $soname `test -n "$verstring" && $ECHO "X-set_version $verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -o $lib'
++	_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -soname $soname `test -n "$verstring" && $ECHO "X-set_version $verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -exports_file $export_symbols -o $lib'
++      fi
++      _LT_TAGVAR(archive_cmds_need_lc, $1)='no'
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
++      _LT_TAGVAR(hardcode_libdir_separator, $1)=:
++      _LT_TAGVAR(inherit_rpath, $1)=yes
++      _LT_TAGVAR(link_all_deplibs, $1)=yes
++      ;;
++
++    netbsd* | netbsdelf*-gnu)
++      if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null; then
++	_LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags'  # a.out
++      else
++	_LT_TAGVAR(archive_cmds, $1)='$LD -shared -o $lib $libobjs $deplibs $linker_flags'      # ELF
++      fi
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
++      _LT_TAGVAR(hardcode_direct, $1)=yes
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      ;;
++
++    newsos6)
++      _LT_TAGVAR(archive_cmds, $1)='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
++      _LT_TAGVAR(hardcode_direct, $1)=yes
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
++      _LT_TAGVAR(hardcode_libdir_separator, $1)=:
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      ;;
++
++    *nto* | *qnx*)
++      ;;
++
++    openbsd*)
++      if test -f /usr/libexec/ld.so; then
++	_LT_TAGVAR(hardcode_direct, $1)=yes
++	_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++	_LT_TAGVAR(hardcode_direct_absolute, $1)=yes
++	if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
++	  _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags'
++	  _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-retain-symbols-file,$export_symbols'
++	  _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
++	  _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
++	else
++	  case $host_os in
++	   openbsd[[01]].* | openbsd2.[[0-7]] | openbsd2.[[0-7]].*)
++	     _LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags'
++	     _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
++	     ;;
++	   *)
++	     _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags'
++	     _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
++	     ;;
++	  esac
++	fi
++      else
++	_LT_TAGVAR(ld_shlibs, $1)=no
++      fi
++      ;;
++
++    os2*)
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
++      _LT_TAGVAR(hardcode_minus_L, $1)=yes
++      _LT_TAGVAR(allow_undefined_flag, $1)=unsupported
++      _LT_TAGVAR(archive_cmds, $1)='$ECHO "LIBRARY $libname INITINSTANCE" > $output_objdir/$libname.def~$ECHO "DESCRIPTION \"$libname\"" >> $output_objdir/$libname.def~$ECHO DATA >> $output_objdir/$libname.def~$ECHO " SINGLE NONSHARED" >> $output_objdir/$libname.def~$ECHO EXPORTS >> $output_objdir/$libname.def~emxexp $libobjs >> $output_objdir/$libname.def~$CC -Zdll -Zcrtdll -o $lib $libobjs $deplibs $compiler_flags $output_objdir/$libname.def'
++      _LT_TAGVAR(old_archive_from_new_cmds, $1)='emximp -o $output_objdir/$libname.a $output_objdir/$libname.def'
++      ;;
++
++    osf3*)
++      if test "$GCC" = yes; then
++	_LT_TAGVAR(allow_undefined_flag, $1)=' ${wl}-expect_unresolved ${wl}\*'
++	_LT_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag} $libobjs $deplibs $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && $ECHO "X${wl}-set_version ${wl}$verstring" | $Xsed` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
++      else
++	_LT_TAGVAR(allow_undefined_flag, $1)=' -expect_unresolved \*'
++	_LT_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag} $libobjs $deplibs $compiler_flags -soname $soname `test -n "$verstring" && $ECHO "X-set_version $verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -o $lib'
++      fi
++      _LT_TAGVAR(archive_cmds_need_lc, $1)='no'
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
++      _LT_TAGVAR(hardcode_libdir_separator, $1)=:
++      ;;
++
++    osf4* | osf5*)	# as osf3* with the addition of -msym flag
++      if test "$GCC" = yes; then
++	_LT_TAGVAR(allow_undefined_flag, $1)=' ${wl}-expect_unresolved ${wl}\*'
++	_LT_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag} $libobjs $deplibs $compiler_flags ${wl}-msym ${wl}-soname ${wl}$soname `test -n "$verstring" && $ECHO "X${wl}-set_version ${wl}$verstring" | $Xsed` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
++	_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
++      else
++	_LT_TAGVAR(allow_undefined_flag, $1)=' -expect_unresolved \*'
++	_LT_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag} $libobjs $deplibs $compiler_flags -msym -soname $soname `test -n "$verstring" && $ECHO "X-set_version $verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -o $lib'
++	_LT_TAGVAR(archive_expsym_cmds, $1)='for i in `cat $export_symbols`; do printf "%s %s\\n" -exported_symbol "\$i" >> $lib.exp; done; printf "%s\\n" "-hidden">> $lib.exp~
++	$CC -shared${allow_undefined_flag} ${wl}-input ${wl}$lib.exp $compiler_flags $libobjs $deplibs -soname $soname `test -n "$verstring" && $ECHO "X-set_version $verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -o $lib~$RM $lib.exp'
++
++	# Both c and cxx compiler support -rpath directly
++	_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-rpath $libdir'
++      fi
++      _LT_TAGVAR(archive_cmds_need_lc, $1)='no'
++      _LT_TAGVAR(hardcode_libdir_separator, $1)=:
++      ;;
++
++    solaris*)
++      _LT_TAGVAR(no_undefined_flag, $1)=' -z defs'
++      if test "$GCC" = yes; then
++	wlarc='${wl}'
++	_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-z ${wl}text ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
++	_LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
++	  $CC -shared ${wl}-z ${wl}text ${wl}-M ${wl}$lib.exp ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp'
++      else
++	case `$CC -V 2>&1` in
++	*"Compilers 5.0"*)
++	  wlarc=''
++	  _LT_TAGVAR(archive_cmds, $1)='$LD -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $linker_flags'
++	  _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
++	  $LD -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $linker_flags~$RM $lib.exp'
++	  ;;
++	*)
++	  wlarc='${wl}'
++	  _LT_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $compiler_flags'
++	  _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
++	  $CC -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp'
++	  ;;
++	esac
++      fi
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      case $host_os in
++      solaris2.[[0-5]] | solaris2.[[0-5]].*) ;;
++      *)
++	# The compiler driver will combine and reorder linker options,
++	# but understands `-z linker_flag'.  GCC discards it without `$wl',
++	# but is careful enough not to reorder.
++	# Supported since Solaris 2.6 (maybe 2.5.1?)
++	if test "$GCC" = yes; then
++	  _LT_TAGVAR(whole_archive_flag_spec, $1)='${wl}-z ${wl}allextract$convenience ${wl}-z ${wl}defaultextract'
++	else
++	  _LT_TAGVAR(whole_archive_flag_spec, $1)='-z allextract$convenience -z defaultextract'
++	fi
++	;;
++      esac
++      _LT_TAGVAR(link_all_deplibs, $1)=yes
++      ;;
++
++    sunos4*)
++      if test "x$host_vendor" = xsequent; then
++	# Use $CC to link under sequent, because it throws in some extra .o
++	# files that make .init and .fini sections work.
++	_LT_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h $soname -o $lib $libobjs $deplibs $compiler_flags'
++      else
++	_LT_TAGVAR(archive_cmds, $1)='$LD -assert pure-text -Bstatic -o $lib $libobjs $deplibs $linker_flags'
++      fi
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
++      _LT_TAGVAR(hardcode_direct, $1)=yes
++      _LT_TAGVAR(hardcode_minus_L, $1)=yes
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      ;;
++
++    sysv4)
++      case $host_vendor in
++	sni)
++	  _LT_TAGVAR(archive_cmds, $1)='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
++	  _LT_TAGVAR(hardcode_direct, $1)=yes # is this really true???
++	;;
++	siemens)
++	  ## LD is ld it makes a PLAMLIB
++	  ## CC just makes a GrossModule.
++	  _LT_TAGVAR(archive_cmds, $1)='$LD -G -o $lib $libobjs $deplibs $linker_flags'
++	  _LT_TAGVAR(reload_cmds, $1)='$CC -r -o $output$reload_objs'
++	  _LT_TAGVAR(hardcode_direct, $1)=no
++        ;;
++	motorola)
++	  _LT_TAGVAR(archive_cmds, $1)='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
++	  _LT_TAGVAR(hardcode_direct, $1)=no #Motorola manual says yes, but my tests say they lie
++	;;
++      esac
++      runpath_var='LD_RUN_PATH'
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      ;;
++
++    sysv4.3*)
++      _LT_TAGVAR(archive_cmds, $1)='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      _LT_TAGVAR(export_dynamic_flag_spec, $1)='-Bexport'
++      ;;
++
++    sysv4*MP*)
++      if test -d /usr/nec; then
++	_LT_TAGVAR(archive_cmds, $1)='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
++	_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++	runpath_var=LD_RUN_PATH
++	hardcode_runpath_var=yes
++	_LT_TAGVAR(ld_shlibs, $1)=yes
++      fi
++      ;;
++
++    sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* | sco3.2v5.0.[[024]]*)
++      _LT_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
++      _LT_TAGVAR(archive_cmds_need_lc, $1)=no
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      runpath_var='LD_RUN_PATH'
++
++      if test "$GCC" = yes; then
++	_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++      else
++	_LT_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++      fi
++      ;;
++
++    sysv5* | sco3.2v5* | sco5v6*)
++      # Note: We can NOT use -z defs as we might desire, because we do not
++      # link with -lc, and that would cause any symbols used from libc to
++      # always be unresolved, which means just about no library would
++      # ever link correctly.  If we're not using GNU ld we use -z text
++      # though, which does catch some bad symbols but isn't as heavy-handed
++      # as -z defs.
++      _LT_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
++      _LT_TAGVAR(allow_undefined_flag, $1)='${wl}-z,nodefs'
++      _LT_TAGVAR(archive_cmds_need_lc, $1)=no
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-R,$libdir'
++      _LT_TAGVAR(hardcode_libdir_separator, $1)=':'
++      _LT_TAGVAR(link_all_deplibs, $1)=yes
++      _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-Bexport'
++      runpath_var='LD_RUN_PATH'
++
++      if test "$GCC" = yes; then
++	_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++      else
++	_LT_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++      fi
++      ;;
++
++    uts4*)
++      _LT_TAGVAR(archive_cmds, $1)='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
++      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      ;;
++
++    *)
++      _LT_TAGVAR(ld_shlibs, $1)=no
++      ;;
++    esac
++
++    if test x$host_vendor = xsni; then
++      case $host in
++      sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
++	_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-Blargedynsym'
++	;;
++      esac
++    fi
++  fi
++])
++AC_MSG_RESULT([$_LT_TAGVAR(ld_shlibs, $1)])
++test "$_LT_TAGVAR(ld_shlibs, $1)" = no && can_build_shared=no
++
++_LT_TAGVAR(with_gnu_ld, $1)=$with_gnu_ld
++
++_LT_DECL([], [libext], [0], [Old archive suffix (normally "a")])dnl
++_LT_DECL([], [shrext_cmds], [1], [Shared library suffix (normally ".so")])dnl
++_LT_DECL([], [extract_expsyms_cmds], [2],
++    [The commands to extract the exported symbol list from a shared archive])
++
++#
++# Do we need to explicitly link libc?
++#
++case "x$_LT_TAGVAR(archive_cmds_need_lc, $1)" in
++x|xyes)
++  # Assume -lc should be added
++  _LT_TAGVAR(archive_cmds_need_lc, $1)=yes
++
++  if test "$enable_shared" = yes && test "$GCC" = yes; then
++    case $_LT_TAGVAR(archive_cmds, $1) in
++    *'~'*)
++      # FIXME: we may have to deal with multi-command sequences.
++      ;;
++    '$CC '*)
++      # Test whether the compiler implicitly links with -lc since on some
++      # systems, -lgcc has to come before -lc. If gcc already passes -lc
++      # to ld, don't add -lc before -lgcc.
++      AC_MSG_CHECKING([whether -lc should be explicitly linked in])
++      $RM conftest*
++      echo "$lt_simple_compile_test_code" > conftest.$ac_ext
++
++      if AC_TRY_EVAL(ac_compile) 2>conftest.err; then
++        soname=conftest
++        lib=conftest
++        libobjs=conftest.$ac_objext
++        deplibs=
++        wl=$_LT_TAGVAR(lt_prog_compiler_wl, $1)
++	pic_flag=$_LT_TAGVAR(lt_prog_compiler_pic, $1)
++        compiler_flags=-v
++        linker_flags=-v
++        verstring=
++        output_objdir=.
++        libname=conftest
++        lt_save_allow_undefined_flag=$_LT_TAGVAR(allow_undefined_flag, $1)
++        _LT_TAGVAR(allow_undefined_flag, $1)=
++        if AC_TRY_EVAL(_LT_TAGVAR(archive_cmds, $1) 2\>\&1 \| $GREP \" -lc \" \>/dev/null 2\>\&1)
++        then
++	  _LT_TAGVAR(archive_cmds_need_lc, $1)=no
++        else
++	  _LT_TAGVAR(archive_cmds_need_lc, $1)=yes
++        fi
++        _LT_TAGVAR(allow_undefined_flag, $1)=$lt_save_allow_undefined_flag
++      else
++        cat conftest.err 1>&5
++      fi
++      $RM conftest*
++      AC_MSG_RESULT([$_LT_TAGVAR(archive_cmds_need_lc, $1)])
++      ;;
++    esac
++  fi
++  ;;
++esac
++
++_LT_TAGDECL([build_libtool_need_lc], [archive_cmds_need_lc], [0],
++    [Whether or not to add -lc for building shared libraries])
++_LT_TAGDECL([allow_libtool_libs_with_static_runtimes],
++    [enable_shared_with_static_runtimes], [0],
++    [Whether or not to disallow shared libs when runtime libs are static])
++_LT_TAGDECL([], [export_dynamic_flag_spec], [1],
++    [Compiler flag to allow reflexive dlopens])
++_LT_TAGDECL([], [whole_archive_flag_spec], [1],
++    [Compiler flag to generate shared objects directly from archives])
++_LT_TAGDECL([], [compiler_needs_object], [1],
++    [Whether the compiler copes with passing no objects directly])
++_LT_TAGDECL([], [old_archive_from_new_cmds], [2],
++    [Create an old-style archive from a shared archive])
++_LT_TAGDECL([], [old_archive_from_expsyms_cmds], [2],
++    [Create a temporary old-style archive to link instead of a shared archive])
++_LT_TAGDECL([], [archive_cmds], [2], [Commands used to build a shared archive])
++_LT_TAGDECL([], [archive_expsym_cmds], [2])
++_LT_TAGDECL([], [module_cmds], [2],
++    [Commands used to build a loadable module if different from building
++    a shared archive.])
++_LT_TAGDECL([], [module_expsym_cmds], [2])
++_LT_TAGDECL([], [with_gnu_ld], [1],
++    [Whether we are building with GNU ld or not])
++_LT_TAGDECL([], [allow_undefined_flag], [1],
++    [Flag that allows shared libraries with undefined symbols to be built])
++_LT_TAGDECL([], [no_undefined_flag], [1],
++    [Flag that enforces no undefined symbols])
++_LT_TAGDECL([], [hardcode_libdir_flag_spec], [1],
++    [Flag to hardcode $libdir into a binary during linking.
++    This must work even if $libdir does not exist])
++_LT_TAGDECL([], [hardcode_libdir_flag_spec_ld], [1],
++    [[If ld is used when linking, flag to hardcode $libdir into a binary
++    during linking.  This must work even if $libdir does not exist]])
++_LT_TAGDECL([], [hardcode_libdir_separator], [1],
++    [Whether we need a single "-rpath" flag with a separated argument])
++_LT_TAGDECL([], [hardcode_direct], [0],
++    [Set to "yes" if using DIR/libNAME${shared_ext} during linking hardcodes
++    DIR into the resulting binary])
++_LT_TAGDECL([], [hardcode_direct_absolute], [0],
++    [Set to "yes" if using DIR/libNAME${shared_ext} during linking hardcodes
++    DIR into the resulting binary and the resulting library dependency is
++    "absolute", i.e impossible to change by setting ${shlibpath_var} if the
++    library is relocated])
++_LT_TAGDECL([], [hardcode_minus_L], [0],
++    [Set to "yes" if using the -LDIR flag during linking hardcodes DIR
++    into the resulting binary])
++_LT_TAGDECL([], [hardcode_shlibpath_var], [0],
++    [Set to "yes" if using SHLIBPATH_VAR=DIR during linking hardcodes DIR
++    into the resulting binary])
++_LT_TAGDECL([], [hardcode_automatic], [0],
++    [Set to "yes" if building a shared library automatically hardcodes DIR
++    into the library and all subsequent libraries and executables linked
++    against it])
++_LT_TAGDECL([], [inherit_rpath], [0],
++    [Set to yes if linker adds runtime paths of dependent libraries
++    to runtime path list])
++_LT_TAGDECL([], [link_all_deplibs], [0],
++    [Whether libtool must link a program against all its dependency libraries])
++_LT_TAGDECL([], [fix_srcfile_path], [1],
++    [Fix the shell variable $srcfile for the compiler])
++_LT_TAGDECL([], [always_export_symbols], [0],
++    [Set to "yes" if exported symbols are required])
++_LT_TAGDECL([], [export_symbols_cmds], [2],
++    [The commands to list exported symbols])
++_LT_TAGDECL([], [exclude_expsyms], [1],
++    [Symbols that should not be listed in the preloaded symbols])
++_LT_TAGDECL([], [include_expsyms], [1],
++    [Symbols that must always be exported])
++_LT_TAGDECL([], [prelink_cmds], [2],
++    [Commands necessary for linking programs (against libraries) with templates])
++_LT_TAGDECL([], [file_list_spec], [1],
++    [Specify filename containing input files])
++dnl FIXME: Not yet implemented
++dnl _LT_TAGDECL([], [thread_safe_flag_spec], [1],
++dnl    [Compiler flag to generate thread safe objects])
++])# _LT_LINKER_SHLIBS
++
++
++# _LT_LANG_C_CONFIG([TAG])
++# ------------------------
++# Ensure that the configuration variables for a C compiler are suitably
++# defined.  These variables are subsequently used by _LT_CONFIG to write
++# the compiler configuration to `libtool'.
++m4_defun([_LT_LANG_C_CONFIG],
++[m4_require([_LT_DECL_EGREP])dnl
++lt_save_CC="$CC"
++AC_LANG_PUSH(C)
++
++# Source file extension for C test sources.
++ac_ext=c
++
++# Object file extension for compiled C test sources.
++objext=o
++_LT_TAGVAR(objext, $1)=$objext
++
++# Code to be used in simple compile tests
++lt_simple_compile_test_code="int some_variable = 0;"
++
++# Code to be used in simple link tests
++lt_simple_link_test_code='int main(){return(0);}'
++
++_LT_TAG_COMPILER
++# Save the default compiler, since it gets overwritten when the other
++# tags are being tested, and _LT_TAGVAR(compiler, []) is a NOP.
++compiler_DEFAULT=$CC
++
++# save warnings/boilerplate of simple test code
++_LT_COMPILER_BOILERPLATE
++_LT_LINKER_BOILERPLATE
++
++## CAVEAT EMPTOR:
++## There is no encapsulation within the following macros, do not change
++## the running order or otherwise move them around unless you know exactly
++## what you are doing...
++if test -n "$compiler"; then
++  _LT_COMPILER_NO_RTTI($1)
++  _LT_COMPILER_PIC($1)
++  _LT_COMPILER_C_O($1)
++  _LT_COMPILER_FILE_LOCKS($1)
++  _LT_LINKER_SHLIBS($1)
++  _LT_SYS_DYNAMIC_LINKER($1)
++  _LT_LINKER_HARDCODE_LIBPATH($1)
++  LT_SYS_DLOPEN_SELF
++  _LT_CMD_STRIPLIB
++
++  # Report which library types will actually be built
++  AC_MSG_CHECKING([if libtool supports shared libraries])
++  AC_MSG_RESULT([$can_build_shared])
++
++  AC_MSG_CHECKING([whether to build shared libraries])
++  test "$can_build_shared" = "no" && enable_shared=no
++
++  # On AIX, shared libraries and static libraries use the same namespace, and
++  # are all built from PIC.
++  case $host_os in
++  aix3*)
++    test "$enable_shared" = yes && enable_static=no
++    if test -n "$RANLIB"; then
++      archive_cmds="$archive_cmds~\$RANLIB \$lib"
++      postinstall_cmds='$RANLIB $lib'
++    fi
++    ;;
++
++  aix[[4-9]]*)
++    if test "$host_cpu" != ia64 && test "$aix_use_runtimelinking" = no ; then
++      test "$enable_shared" = yes && enable_static=no
++    fi
++    ;;
++  esac
++  AC_MSG_RESULT([$enable_shared])
++
++  AC_MSG_CHECKING([whether to build static libraries])
++  # Make sure either enable_shared or enable_static is yes.
++  test "$enable_shared" = yes || enable_static=yes
++  AC_MSG_RESULT([$enable_static])
++
++  _LT_CONFIG($1)
++fi
++AC_LANG_POP
++CC="$lt_save_CC"
++])# _LT_LANG_C_CONFIG
++
++
++# _LT_PROG_CXX
++# ------------
++# Since AC_PROG_CXX is broken, in that it returns g++ if there is no c++
++# compiler, we have our own version here.
++m4_defun([_LT_PROG_CXX],
++[
++pushdef([AC_MSG_ERROR], [_lt_caught_CXX_error=yes])
++AC_PROG_CXX
++if test -n "$CXX" && ( test "X$CXX" != "Xno" &&
++    ( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) ||
++    (test "X$CXX" != "Xg++"))) ; then
++  AC_PROG_CXXCPP
++else
++  _lt_caught_CXX_error=yes
++fi
++popdef([AC_MSG_ERROR])
++])# _LT_PROG_CXX
++
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([_LT_PROG_CXX], [])
++
++
++# _LT_LANG_CXX_CONFIG([TAG])
++# --------------------------
++# Ensure that the configuration variables for a C++ compiler are suitably
++# defined.  These variables are subsequently used by _LT_CONFIG to write
++# the compiler configuration to `libtool'.
++m4_defun([_LT_LANG_CXX_CONFIG],
++[AC_REQUIRE([_LT_PROG_CXX])dnl
++m4_require([_LT_FILEUTILS_DEFAULTS])dnl
++m4_require([_LT_DECL_EGREP])dnl
++
++AC_LANG_PUSH(C++)
++_LT_TAGVAR(archive_cmds_need_lc, $1)=no
++_LT_TAGVAR(allow_undefined_flag, $1)=
++_LT_TAGVAR(always_export_symbols, $1)=no
++_LT_TAGVAR(archive_expsym_cmds, $1)=
++_LT_TAGVAR(compiler_needs_object, $1)=no
++_LT_TAGVAR(export_dynamic_flag_spec, $1)=
++_LT_TAGVAR(hardcode_direct, $1)=no
++_LT_TAGVAR(hardcode_direct_absolute, $1)=no
++_LT_TAGVAR(hardcode_libdir_flag_spec, $1)=
++_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)=
++_LT_TAGVAR(hardcode_libdir_separator, $1)=
++_LT_TAGVAR(hardcode_minus_L, $1)=no
++_LT_TAGVAR(hardcode_shlibpath_var, $1)=unsupported
++_LT_TAGVAR(hardcode_automatic, $1)=no
++_LT_TAGVAR(inherit_rpath, $1)=no
++_LT_TAGVAR(module_cmds, $1)=
++_LT_TAGVAR(module_expsym_cmds, $1)=
++_LT_TAGVAR(link_all_deplibs, $1)=unknown
++_LT_TAGVAR(old_archive_cmds, $1)=$old_archive_cmds
++_LT_TAGVAR(no_undefined_flag, $1)=
++_LT_TAGVAR(whole_archive_flag_spec, $1)=
++_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=no
++
++# Source file extension for C++ test sources.
++ac_ext=cpp
++
++# Object file extension for compiled C++ test sources.
++objext=o
++_LT_TAGVAR(objext, $1)=$objext
++
++# No sense in running all these tests if we already determined that
++# the CXX compiler isn't working.  Some variables (like enable_shared)
++# are currently assumed to apply to all compilers on this platform,
++# and will be corrupted by setting them based on a non-working compiler.
++if test "$_lt_caught_CXX_error" != yes; then
++  # Code to be used in simple compile tests
++  lt_simple_compile_test_code="int some_variable = 0;"
++
++  # Code to be used in simple link tests
++  lt_simple_link_test_code='int main(int, char *[[]]) { return(0); }'
++
++  # ltmain only uses $CC for tagged configurations so make sure $CC is set.
++  _LT_TAG_COMPILER
++
++  # save warnings/boilerplate of simple test code
++  _LT_COMPILER_BOILERPLATE
++  _LT_LINKER_BOILERPLATE
++
++  # Allow CC to be a program name with arguments.
++  lt_save_CC=$CC
++  lt_save_LD=$LD
++  lt_save_GCC=$GCC
++  GCC=$GXX
++  lt_save_with_gnu_ld=$with_gnu_ld
++  lt_save_path_LD=$lt_cv_path_LD
++  if test -n "${lt_cv_prog_gnu_ldcxx+set}"; then
++    lt_cv_prog_gnu_ld=$lt_cv_prog_gnu_ldcxx
++  else
++    $as_unset lt_cv_prog_gnu_ld
++  fi
++  if test -n "${lt_cv_path_LDCXX+set}"; then
++    lt_cv_path_LD=$lt_cv_path_LDCXX
++  else
++    $as_unset lt_cv_path_LD
++  fi
++  test -z "${LDCXX+set}" || LD=$LDCXX
++  CC=${CXX-"c++"}
++  compiler=$CC
++  _LT_TAGVAR(compiler, $1)=$CC
++  _LT_CC_BASENAME([$compiler])
++
++  if test -n "$compiler"; then
++    # We don't want -fno-exception when compiling C++ code, so set the
++    # no_builtin_flag separately
++    if test "$GXX" = yes; then
++      _LT_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)=' -fno-builtin'
++    else
++      _LT_TAGVAR(lt_prog_compiler_no_builtin_flag, $1)=
++    fi
++
++    if test "$GXX" = yes; then
++      # Set up default GNU C++ configuration
++
++      LT_PATH_LD
++
++      # Check if GNU C++ uses GNU ld as the underlying linker, since the
++      # archiving commands below assume that GNU ld is being used.
++      if test "$with_gnu_ld" = yes; then
++        _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
++        _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
++
++        _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
++        _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
++
++        # If archive_cmds runs LD, not CC, wlarc should be empty
++        # XXX I think wlarc can be eliminated in ltcf-cxx, but I need to
++        #     investigate it a little bit more. (MM)
++        wlarc='${wl}'
++
++        # ancient GNU ld didn't support --whole-archive et. al.
++        if eval "`$CC -print-prog-name=ld` --help 2>&1" |
++	  $GREP 'no-whole-archive' > /dev/null; then
++          _LT_TAGVAR(whole_archive_flag_spec, $1)="$wlarc"'--whole-archive$convenience '"$wlarc"'--no-whole-archive'
++        else
++          _LT_TAGVAR(whole_archive_flag_spec, $1)=
++        fi
++      else
++        with_gnu_ld=no
++        wlarc=
++
++        # A generic and very simple default shared library creation
++        # command for GNU C++ for the case where it uses the native
++        # linker, instead of GNU ld.  If possible, this setting should
++        # overridden to take advantage of the native linker features on
++        # the platform it is being used on.
++        _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $lib'
++      fi
++
++      # Commands to make compiler produce verbose output that lists
++      # what "hidden" libraries, object files and flags are used when
++      # linking a shared library.
++      output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP "\-L"'
++
++    else
++      GXX=no
++      with_gnu_ld=no
++      wlarc=
++    fi
++
++    # PORTME: fill in a description of your system's C++ link characteristics
++    AC_MSG_CHECKING([whether the $compiler linker ($LD) supports shared libraries])
++    _LT_TAGVAR(ld_shlibs, $1)=yes
++    case $host_os in
++      aix3*)
++        # FIXME: insert proper C++ library support
++        _LT_TAGVAR(ld_shlibs, $1)=no
++        ;;
++      aix[[4-9]]*)
++        if test "$host_cpu" = ia64; then
++          # On IA64, the linker does run time linking by default, so we don't
++          # have to do anything special.
++          aix_use_runtimelinking=no
++          exp_sym_flag='-Bexport'
++          no_entry_flag=""
++        else
++          aix_use_runtimelinking=no
++
++          # Test if we are trying to use run time linking or normal
++          # AIX style linking. If -brtl is somewhere in LDFLAGS, we
++          # need to do runtime linking.
++          case $host_os in aix4.[[23]]|aix4.[[23]].*|aix[[5-9]]*)
++	    for ld_flag in $LDFLAGS; do
++	      case $ld_flag in
++	      *-brtl*)
++	        aix_use_runtimelinking=yes
++	        break
++	        ;;
++	      esac
++	    done
++	    ;;
++          esac
++
++          exp_sym_flag='-bexport'
++          no_entry_flag='-bnoentry'
++        fi
++
++        # When large executables or shared objects are built, AIX ld can
++        # have problems creating the table of contents.  If linking a library
++        # or program results in "error TOC overflow" add -mminimal-toc to
++        # CXXFLAGS/CFLAGS for g++/gcc.  In the cases where that is not
++        # enough to fix the problem, add -Wl,-bbigtoc to LDFLAGS.
++
++        _LT_TAGVAR(archive_cmds, $1)=''
++        _LT_TAGVAR(hardcode_direct, $1)=yes
++        _LT_TAGVAR(hardcode_direct_absolute, $1)=yes
++        _LT_TAGVAR(hardcode_libdir_separator, $1)=':'
++        _LT_TAGVAR(link_all_deplibs, $1)=yes
++        _LT_TAGVAR(file_list_spec, $1)='${wl}-f,'
++
++        if test "$GXX" = yes; then
++          case $host_os in aix4.[[012]]|aix4.[[012]].*)
++          # We only want to do this on AIX 4.2 and lower, the check
++          # below for broken collect2 doesn't work under 4.3+
++	  collect2name=`${CC} -print-prog-name=collect2`
++	  if test -f "$collect2name" &&
++	     strings "$collect2name" | $GREP resolve_lib_name >/dev/null
++	  then
++	    # We have reworked collect2
++	    :
++	  else
++	    # We have old collect2
++	    _LT_TAGVAR(hardcode_direct, $1)=unsupported
++	    # It fails to find uninstalled libraries when the uninstalled
++	    # path is not listed in the libpath.  Setting hardcode_minus_L
++	    # to unsupported forces relinking
++	    _LT_TAGVAR(hardcode_minus_L, $1)=yes
++	    _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
++	    _LT_TAGVAR(hardcode_libdir_separator, $1)=
++	  fi
++          esac
++          shared_flag='-shared'
++	  if test "$aix_use_runtimelinking" = yes; then
++	    shared_flag="$shared_flag "'${wl}-G'
++	  fi
++        else
++          # not using gcc
++          if test "$host_cpu" = ia64; then
++	  # VisualAge C++, Version 5.5 for AIX 5L for IA-64, Beta 3 Release
++	  # chokes on -Wl,-G. The following line is correct:
++	  shared_flag='-G'
++          else
++	    if test "$aix_use_runtimelinking" = yes; then
++	      shared_flag='${wl}-G'
++	    else
++	      shared_flag='${wl}-bM:SRE'
++	    fi
++          fi
++        fi
++
++        _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-bexpall'
++        # It seems that -bexpall does not export symbols beginning with
++        # underscore (_), so it is better to generate a list of symbols to
++	# export.
++        _LT_TAGVAR(always_export_symbols, $1)=yes
++        if test "$aix_use_runtimelinking" = yes; then
++          # Warning - without using the other runtime loading flags (-brtl),
++          # -berok will link without error, but may produce a broken library.
++          _LT_TAGVAR(allow_undefined_flag, $1)='-berok'
++          # Determine the default libpath from the value encoded in an empty
++          # executable.
++          _LT_SYS_MODULE_PATH_AIX
++          _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-blibpath:$libdir:'"$aix_libpath"
++
++          _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then $ECHO "X${wl}${allow_undefined_flag}" | $Xsed; else :; fi` '"\${wl}$exp_sym_flag:\$export_symbols $shared_flag"
++        else
++          if test "$host_cpu" = ia64; then
++	    _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-R $libdir:/usr/lib:/lib'
++	    _LT_TAGVAR(allow_undefined_flag, $1)="-z nodefs"
++	    _LT_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$exp_sym_flag:\$export_symbols"
++          else
++	    # Determine the default libpath from the value encoded in an
++	    # empty executable.
++	    _LT_SYS_MODULE_PATH_AIX
++	    _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-blibpath:$libdir:'"$aix_libpath"
++	    # Warning - without using the other run time loading flags,
++	    # -berok will link without error, but may produce a broken library.
++	    _LT_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
++	    _LT_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
++	    # Exported symbols can be pulled into shared objects from archives
++	    _LT_TAGVAR(whole_archive_flag_spec, $1)='$convenience'
++	    _LT_TAGVAR(archive_cmds_need_lc, $1)=yes
++	    # This is similar to how AIX traditionally builds its shared
++	    # libraries.
++	    _LT_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs ${wl}-bnoentry $compiler_flags ${wl}-bE:$export_symbols${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
++          fi
++        fi
++        ;;
++
++      beos*)
++	if $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null; then
++	  _LT_TAGVAR(allow_undefined_flag, $1)=unsupported
++	  # Joseph Beckenbach <jrb3@best.com> says some releases of gcc
++	  # support --undefined.  This deserves some investigation.  FIXME
++	  _LT_TAGVAR(archive_cmds, $1)='$CC -nostart $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++	else
++	  _LT_TAGVAR(ld_shlibs, $1)=no
++	fi
++	;;
++
++      chorus*)
++        case $cc_basename in
++          *)
++	  # FIXME: insert proper C++ library support
++	  _LT_TAGVAR(ld_shlibs, $1)=no
++	  ;;
++        esac
++        ;;
++
++      cygwin* | mingw* | pw32* | cegcc*)
++        # _LT_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
++        # as there is no search path for DLLs.
++        _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
++        _LT_TAGVAR(allow_undefined_flag, $1)=unsupported
++        _LT_TAGVAR(always_export_symbols, $1)=no
++        _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
++
++        if $LD --help 2>&1 | $GREP 'auto-import' > /dev/null; then
++          _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
++          # If the export-symbols file already is a .def file (1st line
++          # is EXPORTS), use it as is; otherwise, prepend...
++          _LT_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
++	    cp $export_symbols $output_objdir/$soname.def;
++          else
++	    echo EXPORTS > $output_objdir/$soname.def;
++	    cat $export_symbols >> $output_objdir/$soname.def;
++          fi~
++          $CC -shared -nostdlib $output_objdir/$soname.def $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
++        else
++          _LT_TAGVAR(ld_shlibs, $1)=no
++        fi
++        ;;
++      darwin* | rhapsody*)
++        _LT_DARWIN_LINKER_FEATURES($1)
++	;;
++
++      dgux*)
++        case $cc_basename in
++          ec++*)
++	    # FIXME: insert proper C++ library support
++	    _LT_TAGVAR(ld_shlibs, $1)=no
++	    ;;
++          ghcx*)
++	    # Green Hills C++ Compiler
++	    # FIXME: insert proper C++ library support
++	    _LT_TAGVAR(ld_shlibs, $1)=no
++	    ;;
++          *)
++	    # FIXME: insert proper C++ library support
++	    _LT_TAGVAR(ld_shlibs, $1)=no
++	    ;;
++        esac
++        ;;
++
++      freebsd[[12]]*)
++        # C++ shared libraries reported to be fairly broken before
++	# switch to ELF
++        _LT_TAGVAR(ld_shlibs, $1)=no
++        ;;
++
++      freebsd-elf*)
++        _LT_TAGVAR(archive_cmds_need_lc, $1)=no
++        ;;
++
++      freebsd* | dragonfly*)
++        # FreeBSD 3 and later use GNU C++ and GNU ld with standard ELF
++        # conventions
++        _LT_TAGVAR(ld_shlibs, $1)=yes
++        ;;
++
++      gnu*)
++        ;;
++
++      hpux9*)
++        _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
++        _LT_TAGVAR(hardcode_libdir_separator, $1)=:
++        _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
++        _LT_TAGVAR(hardcode_direct, $1)=yes
++        _LT_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
++				             # but as the default
++				             # location of the library.
++
++        case $cc_basename in
++          CC*)
++            # FIXME: insert proper C++ library support
++            _LT_TAGVAR(ld_shlibs, $1)=no
++            ;;
++          aCC*)
++            _LT_TAGVAR(archive_cmds, $1)='$RM $output_objdir/$soname~$CC -b ${wl}+b ${wl}$install_libdir -o $output_objdir/$soname $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
++            # Commands to make compiler produce verbose output that lists
++            # what "hidden" libraries, object files and flags are used when
++            # linking a shared library.
++            #
++            # There doesn't appear to be a way to prevent this compiler from
++            # explicitly linking system object files so we need to strip them
++            # from the output so that they don't get included in the library
++            # dependencies.
++            output_verbose_link_cmd='templist=`($CC -b $CFLAGS -v conftest.$objext 2>&1) | $EGREP "\-L"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; $ECHO "X$list" | $Xsed'
++            ;;
++          *)
++            if test "$GXX" = yes; then
++              _LT_TAGVAR(archive_cmds, $1)='$RM $output_objdir/$soname~$CC -shared -nostdlib -fPIC ${wl}+b ${wl}$install_libdir -o $output_objdir/$soname $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
++            else
++              # FIXME: insert proper C++ library support
++              _LT_TAGVAR(ld_shlibs, $1)=no
++            fi
++            ;;
++        esac
++        ;;
++
++      hpux10*|hpux11*)
++        if test $with_gnu_ld = no; then
++	  _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
++	  _LT_TAGVAR(hardcode_libdir_separator, $1)=:
++
++          case $host_cpu in
++            hppa*64*|ia64*)
++              ;;
++            *)
++	      _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
++              ;;
++          esac
++        fi
++        case $host_cpu in
++          hppa*64*|ia64*)
++            _LT_TAGVAR(hardcode_direct, $1)=no
++            _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++            ;;
++          *)
++            _LT_TAGVAR(hardcode_direct, $1)=yes
++            _LT_TAGVAR(hardcode_direct_absolute, $1)=yes
++            _LT_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
++					         # but as the default
++					         # location of the library.
++            ;;
++        esac
++
++        case $cc_basename in
++          CC*)
++	    # FIXME: insert proper C++ library support
++	    _LT_TAGVAR(ld_shlibs, $1)=no
++	    ;;
++          aCC*)
++	    case $host_cpu in
++	      hppa*64*)
++	        _LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
++	        ;;
++	      ia64*)
++	        _LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
++	        ;;
++	      *)
++	        _LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
++	        ;;
++	    esac
++	    # Commands to make compiler produce verbose output that lists
++	    # what "hidden" libraries, object files and flags are used when
++	    # linking a shared library.
++	    #
++	    # There doesn't appear to be a way to prevent this compiler from
++	    # explicitly linking system object files so we need to strip them
++	    # from the output so that they don't get included in the library
++	    # dependencies.
++	    output_verbose_link_cmd='templist=`($CC -b $CFLAGS -v conftest.$objext 2>&1) | $GREP "\-L"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; $ECHO "X$list" | $Xsed'
++	    ;;
++          *)
++	    if test "$GXX" = yes; then
++	      if test $with_gnu_ld = no; then
++	        case $host_cpu in
++	          hppa*64*)
++	            _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
++	            ;;
++	          ia64*)
++	            _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
++	            ;;
++	          *)
++	            _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
++	            ;;
++	        esac
++	      fi
++	    else
++	      # FIXME: insert proper C++ library support
++	      _LT_TAGVAR(ld_shlibs, $1)=no
++	    fi
++	    ;;
++        esac
++        ;;
++
++      interix[[3-9]]*)
++	_LT_TAGVAR(hardcode_direct, $1)=no
++	_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++	_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
++	_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
++	# Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
++	# Instead, shared libraries are loaded at an image base (0x10000000 by
++	# default) and relocated if they conflict, which is a slow very memory
++	# consuming and fragmenting process.  To avoid this, we pick a random,
++	# 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
++	# time.  Moving up from 0x10000000 also allows more sbrk(2) space.
++	_LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
++	_LT_TAGVAR(archive_expsym_cmds, $1)='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
++	;;
++      irix5* | irix6*)
++        case $cc_basename in
++          CC*)
++	    # SGI C++
++	    _LT_TAGVAR(archive_cmds, $1)='$CC -shared -all -multigot $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -soname $soname `test -n "$verstring" && $ECHO "X-set_version $verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -o $lib'
++
++	    # Archives containing C++ object files must be created using
++	    # "CC -ar", where "CC" is the IRIX C++ compiler.  This is
++	    # necessary to make sure instantiated templates are included
++	    # in the archive.
++	    _LT_TAGVAR(old_archive_cmds, $1)='$CC -ar -WR,-u -o $oldlib $oldobjs'
++	    ;;
++          *)
++	    if test "$GXX" = yes; then
++	      if test "$with_gnu_ld" = no; then
++	        _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && $ECHO "X${wl}-set_version ${wl}$verstring" | $Xsed` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
++	      else
++	        _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && $ECHO "X${wl}-set_version ${wl}$verstring" | $Xsed` -o $lib'
++	      fi
++	    fi
++	    _LT_TAGVAR(link_all_deplibs, $1)=yes
++	    ;;
++        esac
++        _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
++        _LT_TAGVAR(hardcode_libdir_separator, $1)=:
++        _LT_TAGVAR(inherit_rpath, $1)=yes
++        ;;
++
++      linux* | k*bsd*-gnu | kopensolaris*-gnu)
++        case $cc_basename in
++          KCC*)
++	    # Kuck and Associates, Inc. (KAI) C++ Compiler
++
++	    # KCC will only create a shared library if the output file
++	    # ends with ".so" (or ".sl" for HP-UX), so rename the library
++	    # to its proper name (with version) after linking.
++	    _LT_TAGVAR(archive_cmds, $1)='tempext=`echo $shared_ext | $SED -e '\''s/\([[^()0-9A-Za-z{}]]\)/\\\\\1/g'\''`; templib=`echo $lib | $SED -e "s/\${tempext}\..*/.so/"`; $CC $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags --soname $soname -o \$templib; mv \$templib $lib'
++	    _LT_TAGVAR(archive_expsym_cmds, $1)='tempext=`echo $shared_ext | $SED -e '\''s/\([[^()0-9A-Za-z{}]]\)/\\\\\1/g'\''`; templib=`echo $lib | $SED -e "s/\${tempext}\..*/.so/"`; $CC $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags --soname $soname -o \$templib ${wl}-retain-symbols-file,$export_symbols; mv \$templib $lib'
++	    # Commands to make compiler produce verbose output that lists
++	    # what "hidden" libraries, object files and flags are used when
++	    # linking a shared library.
++	    #
++	    # There doesn't appear to be a way to prevent this compiler from
++	    # explicitly linking system object files so we need to strip them
++	    # from the output so that they don't get included in the library
++	    # dependencies.
++	    output_verbose_link_cmd='templist=`$CC $CFLAGS -v conftest.$objext -o libconftest$shared_ext 2>&1 | $GREP "ld"`; rm -f libconftest$shared_ext; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; $ECHO "X$list" | $Xsed'
++
++	    _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
++	    _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
++
++	    # Archives containing C++ object files must be created using
++	    # "CC -Bstatic", where "CC" is the KAI C++ compiler.
++	    _LT_TAGVAR(old_archive_cmds, $1)='$CC -Bstatic -o $oldlib $oldobjs'
++	    ;;
++	  icpc* | ecpc* )
++	    # Intel C++
++	    with_gnu_ld=yes
++	    # version 8.0 and above of icpc choke on multiply defined symbols
++	    # if we add $predep_objects and $postdep_objects, however 7.1 and
++	    # earlier do not add the objects themselves.
++	    case `$CC -V 2>&1` in
++	      *"Version 7."*)
++	        _LT_TAGVAR(archive_cmds, $1)='$CC -shared $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
++		_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
++		;;
++	      *)  # Version 8.0 or newer
++	        tmp_idyn=
++	        case $host_cpu in
++		  ia64*) tmp_idyn=' -i_dynamic';;
++		esac
++	        _LT_TAGVAR(archive_cmds, $1)='$CC -shared'"$tmp_idyn"' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++		_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared'"$tmp_idyn"' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
++		;;
++	    esac
++	    _LT_TAGVAR(archive_cmds_need_lc, $1)=no
++	    _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
++	    _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
++	    _LT_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive$convenience ${wl}--no-whole-archive'
++	    ;;
++          pgCC* | pgcpp*)
++            # Portland Group C++ compiler
++	    case `$CC -V` in
++	    *pgCC\ [[1-5]]* | *pgcpp\ [[1-5]]*)
++	      _LT_TAGVAR(prelink_cmds, $1)='tpldir=Template.dir~
++		rm -rf $tpldir~
++		$CC --prelink_objects --instantiation_dir $tpldir $objs $libobjs $compile_deplibs~
++		compile_command="$compile_command `find $tpldir -name \*.o | $NL2SP`"'
++	      _LT_TAGVAR(old_archive_cmds, $1)='tpldir=Template.dir~
++		rm -rf $tpldir~
++		$CC --prelink_objects --instantiation_dir $tpldir $oldobjs$old_deplibs~
++		$AR $AR_FLAGS $oldlib$oldobjs$old_deplibs `find $tpldir -name \*.o | $NL2SP`~
++		$RANLIB $oldlib'
++	      _LT_TAGVAR(archive_cmds, $1)='tpldir=Template.dir~
++		rm -rf $tpldir~
++		$CC --prelink_objects --instantiation_dir $tpldir $predep_objects $libobjs $deplibs $convenience $postdep_objects~
++		$CC -shared $pic_flag $predep_objects $libobjs $deplibs `find $tpldir -name \*.o | $NL2SP` $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname -o $lib'
++	      _LT_TAGVAR(archive_expsym_cmds, $1)='tpldir=Template.dir~
++		rm -rf $tpldir~
++		$CC --prelink_objects --instantiation_dir $tpldir $predep_objects $libobjs $deplibs $convenience $postdep_objects~
++		$CC -shared $pic_flag $predep_objects $libobjs $deplibs `find $tpldir -name \*.o | $NL2SP` $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname ${wl}-retain-symbols-file ${wl}$export_symbols -o $lib'
++	      ;;
++	    *) # Version 6 will use weak symbols
++	      _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname -o $lib'
++	      _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname ${wl}-retain-symbols-file ${wl}$export_symbols -o $lib'
++	      ;;
++	    esac
++
++	    _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}--rpath ${wl}$libdir'
++	    _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
++	    _LT_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`for conv in $convenience\"\"; do test  -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $ECHO \"$new_convenience\"` ${wl}--no-whole-archive'
++            ;;
++	  cxx*)
++	    # Compaq C++
++	    _LT_TAGVAR(archive_cmds, $1)='$CC -shared $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
++	    _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname  -o $lib ${wl}-retain-symbols-file $wl$export_symbols'
++
++	    runpath_var=LD_RUN_PATH
++	    _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-rpath $libdir'
++	    _LT_TAGVAR(hardcode_libdir_separator, $1)=:
++
++	    # Commands to make compiler produce verbose output that lists
++	    # what "hidden" libraries, object files and flags are used when
++	    # linking a shared library.
++	    #
++	    # There doesn't appear to be a way to prevent this compiler from
++	    # explicitly linking system object files so we need to strip them
++	    # from the output so that they don't get included in the library
++	    # dependencies.
++	    output_verbose_link_cmd='templist=`$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP "ld"`; templist=`$ECHO "X$templist" | $Xsed -e "s/\(^.*ld.*\)\( .*ld .*$\)/\1/"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; $ECHO "X$list" | $Xsed'
++	    ;;
++	  xl*)
++	    # IBM XL 8.0 on PPC, with GNU ld
++	    _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
++	    _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
++	    _LT_TAGVAR(archive_cmds, $1)='$CC -qmkshrobj $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++	    if test "x$supports_anon_versioning" = xyes; then
++	      _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $output_objdir/$libname.ver~
++		cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $output_objdir/$libname.ver~
++		echo "local: *; };" >> $output_objdir/$libname.ver~
++		$CC -qmkshrobj $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-version-script ${wl}$output_objdir/$libname.ver -o $lib'
++	    fi
++	    ;;
++	  *)
++	    case `$CC -V 2>&1 | sed 5q` in
++	    *Sun\ C*)
++	      # Sun C++ 5.9
++	      _LT_TAGVAR(no_undefined_flag, $1)=' -zdefs'
++	      _LT_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag} -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
++	      _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -G${allow_undefined_flag} -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-retain-symbols-file ${wl}$export_symbols'
++	      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
++	      _LT_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`new_convenience=; for conv in $convenience\"\"; do test -z \"$conv\" || new_convenience=\"$new_convenience,$conv\"; done; $ECHO \"$new_convenience\"` ${wl}--no-whole-archive'
++	      _LT_TAGVAR(compiler_needs_object, $1)=yes
++
++	      # Not sure whether something based on
++	      # $CC $CFLAGS -v conftest.$objext -o libconftest$shared_ext 2>&1
++	      # would be better.
++	      output_verbose_link_cmd='echo'
++
++	      # Archives containing C++ object files must be created using
++	      # "CC -xar", where "CC" is the Sun C++ compiler.  This is
++	      # necessary to make sure instantiated templates are included
++	      # in the archive.
++	      _LT_TAGVAR(old_archive_cmds, $1)='$CC -xar -o $oldlib $oldobjs'
++	      ;;
++	    esac
++	    ;;
++	esac
++	;;
++
++      lynxos*)
++        # FIXME: insert proper C++ library support
++	_LT_TAGVAR(ld_shlibs, $1)=no
++	;;
++
++      m88k*)
++        # FIXME: insert proper C++ library support
++        _LT_TAGVAR(ld_shlibs, $1)=no
++	;;
++
++      mvs*)
++        case $cc_basename in
++          cxx*)
++	    # FIXME: insert proper C++ library support
++	    _LT_TAGVAR(ld_shlibs, $1)=no
++	    ;;
++	  *)
++	    # FIXME: insert proper C++ library support
++	    _LT_TAGVAR(ld_shlibs, $1)=no
++	    ;;
++	esac
++	;;
++
++      netbsd*)
++        if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null; then
++	  _LT_TAGVAR(archive_cmds, $1)='$LD -Bshareable  -o $lib $predep_objects $libobjs $deplibs $postdep_objects $linker_flags'
++	  wlarc=
++	  _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
++	  _LT_TAGVAR(hardcode_direct, $1)=yes
++	  _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++	fi
++	# Workaround some broken pre-1.5 toolchains
++	output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP conftest.$objext | $SED -e "s:-lgcc -lc -lgcc::"'
++	;;
++
++      *nto* | *qnx*)
++        _LT_TAGVAR(ld_shlibs, $1)=yes
++	;;
++
++      openbsd2*)
++        # C++ shared libraries are fairly broken
++	_LT_TAGVAR(ld_shlibs, $1)=no
++	;;
++
++      openbsd*)
++	if test -f /usr/libexec/ld.so; then
++	  _LT_TAGVAR(hardcode_direct, $1)=yes
++	  _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++	  _LT_TAGVAR(hardcode_direct_absolute, $1)=yes
++	  _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $lib'
++	  _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
++	  if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
++	    _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-retain-symbols-file,$export_symbols -o $lib'
++	    _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
++	    _LT_TAGVAR(whole_archive_flag_spec, $1)="$wlarc"'--whole-archive$convenience '"$wlarc"'--no-whole-archive'
++	  fi
++	  output_verbose_link_cmd=echo
++	else
++	  _LT_TAGVAR(ld_shlibs, $1)=no
++	fi
++	;;
++
++      osf3* | osf4* | osf5*)
++        case $cc_basename in
++          KCC*)
++	    # Kuck and Associates, Inc. (KAI) C++ Compiler
++
++	    # KCC will only create a shared library if the output file
++	    # ends with ".so" (or ".sl" for HP-UX), so rename the library
++	    # to its proper name (with version) after linking.
++	    _LT_TAGVAR(archive_cmds, $1)='tempext=`echo $shared_ext | $SED -e '\''s/\([[^()0-9A-Za-z{}]]\)/\\\\\1/g'\''`; templib=`echo "$lib" | $SED -e "s/\${tempext}\..*/.so/"`; $CC $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags --soname $soname -o \$templib; mv \$templib $lib'
++
++	    _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
++	    _LT_TAGVAR(hardcode_libdir_separator, $1)=:
++
++	    # Archives containing C++ object files must be created using
++	    # the KAI C++ compiler.
++	    case $host in
++	      osf3*) _LT_TAGVAR(old_archive_cmds, $1)='$CC -Bstatic -o $oldlib $oldobjs' ;;
++	      *) _LT_TAGVAR(old_archive_cmds, $1)='$CC -o $oldlib $oldobjs' ;;
++	    esac
++	    ;;
++          RCC*)
++	    # Rational C++ 2.4.1
++	    # FIXME: insert proper C++ library support
++	    _LT_TAGVAR(ld_shlibs, $1)=no
++	    ;;
++          cxx*)
++	    case $host in
++	      osf3*)
++	        _LT_TAGVAR(allow_undefined_flag, $1)=' ${wl}-expect_unresolved ${wl}\*'
++	        _LT_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $soname `test -n "$verstring" && $ECHO "X${wl}-set_version $verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -o $lib'
++	        _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
++		;;
++	      *)
++	        _LT_TAGVAR(allow_undefined_flag, $1)=' -expect_unresolved \*'
++	        _LT_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -msym -soname $soname `test -n "$verstring" && $ECHO "X-set_version $verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -o $lib'
++	        _LT_TAGVAR(archive_expsym_cmds, $1)='for i in `cat $export_symbols`; do printf "%s %s\\n" -exported_symbol "\$i" >> $lib.exp; done~
++	          echo "-hidden">> $lib.exp~
++	          $CC -shared$allow_undefined_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -msym -soname $soname ${wl}-input ${wl}$lib.exp  `test -n "$verstring" && $ECHO "X-set_version $verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -o $lib~
++	          $RM $lib.exp'
++	        _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-rpath $libdir'
++		;;
++	    esac
++
++	    _LT_TAGVAR(hardcode_libdir_separator, $1)=:
++
++	    # Commands to make compiler produce verbose output that lists
++	    # what "hidden" libraries, object files and flags are used when
++	    # linking a shared library.
++	    #
++	    # There doesn't appear to be a way to prevent this compiler from
++	    # explicitly linking system object files so we need to strip them
++	    # from the output so that they don't get included in the library
++	    # dependencies.
++	    output_verbose_link_cmd='templist=`$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP "ld" | $GREP -v "ld:"`; templist=`$ECHO "X$templist" | $Xsed -e "s/\(^.*ld.*\)\( .*ld.*$\)/\1/"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; $ECHO "X$list" | $Xsed'
++	    ;;
++	  *)
++	    if test "$GXX" = yes && test "$with_gnu_ld" = no; then
++	      _LT_TAGVAR(allow_undefined_flag, $1)=' ${wl}-expect_unresolved ${wl}\*'
++	      case $host in
++	        osf3*)
++	          _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib ${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && $ECHO "X${wl}-set_version ${wl}$verstring" | $Xsed` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
++		  ;;
++	        *)
++	          _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib ${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-msym ${wl}-soname ${wl}$soname `test -n "$verstring" && $ECHO "${wl}-set_version ${wl}$verstring" | $Xsed` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
++		  ;;
++	      esac
++
++	      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
++	      _LT_TAGVAR(hardcode_libdir_separator, $1)=:
++
++	      # Commands to make compiler produce verbose output that lists
++	      # what "hidden" libraries, object files and flags are used when
++	      # linking a shared library.
++	      output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP "\-L"'
++
++	    else
++	      # FIXME: insert proper C++ library support
++	      _LT_TAGVAR(ld_shlibs, $1)=no
++	    fi
++	    ;;
++        esac
++        ;;
++
++      psos*)
++        # FIXME: insert proper C++ library support
++        _LT_TAGVAR(ld_shlibs, $1)=no
++        ;;
++
++      sunos4*)
++        case $cc_basename in
++          CC*)
++	    # Sun C++ 4.x
++	    # FIXME: insert proper C++ library support
++	    _LT_TAGVAR(ld_shlibs, $1)=no
++	    ;;
++          lcc*)
++	    # Lucid
++	    # FIXME: insert proper C++ library support
++	    _LT_TAGVAR(ld_shlibs, $1)=no
++	    ;;
++          *)
++	    # FIXME: insert proper C++ library support
++	    _LT_TAGVAR(ld_shlibs, $1)=no
++	    ;;
++        esac
++        ;;
++
++      solaris*)
++        case $cc_basename in
++          CC*)
++	    # Sun C++ 4.2, 5.x and Centerline C++
++            _LT_TAGVAR(archive_cmds_need_lc,$1)=yes
++	    _LT_TAGVAR(no_undefined_flag, $1)=' -zdefs'
++	    _LT_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag}  -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
++	    _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
++	      $CC -G${allow_undefined_flag} ${wl}-M ${wl}$lib.exp -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM $lib.exp'
++
++	    _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
++	    _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++	    case $host_os in
++	      solaris2.[[0-5]] | solaris2.[[0-5]].*) ;;
++	      *)
++		# The compiler driver will combine and reorder linker options,
++		# but understands `-z linker_flag'.
++	        # Supported since Solaris 2.6 (maybe 2.5.1?)
++		_LT_TAGVAR(whole_archive_flag_spec, $1)='-z allextract$convenience -z defaultextract'
++	        ;;
++	    esac
++	    _LT_TAGVAR(link_all_deplibs, $1)=yes
++
++	    output_verbose_link_cmd='echo'
++
++	    # Archives containing C++ object files must be created using
++	    # "CC -xar", where "CC" is the Sun C++ compiler.  This is
++	    # necessary to make sure instantiated templates are included
++	    # in the archive.
++	    _LT_TAGVAR(old_archive_cmds, $1)='$CC -xar -o $oldlib $oldobjs'
++	    ;;
++          gcx*)
++	    # Green Hills C++ Compiler
++	    _LT_TAGVAR(archive_cmds, $1)='$CC -shared $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-h $wl$soname -o $lib'
++
++	    # The C++ compiler must be used to create the archive.
++	    _LT_TAGVAR(old_archive_cmds, $1)='$CC $LDFLAGS -archive -o $oldlib $oldobjs'
++	    ;;
++          *)
++	    # GNU C++ compiler with Solaris linker
++	    if test "$GXX" = yes && test "$with_gnu_ld" = no; then
++	      _LT_TAGVAR(no_undefined_flag, $1)=' ${wl}-z ${wl}defs'
++	      if $CC --version | $GREP -v '^2\.7' > /dev/null; then
++	        _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $LDFLAGS $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-h $wl$soname -o $lib'
++	        _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
++		  $CC -shared -nostdlib ${wl}-M $wl$lib.exp -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM $lib.exp'
++
++	        # Commands to make compiler produce verbose output that lists
++	        # what "hidden" libraries, object files and flags are used when
++	        # linking a shared library.
++	        output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP "\-L"'
++	      else
++	        # g++ 2.7 appears to require `-G' NOT `-shared' on this
++	        # platform.
++	        _LT_TAGVAR(archive_cmds, $1)='$CC -G -nostdlib $LDFLAGS $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-h $wl$soname -o $lib'
++	        _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
++		  $CC -G -nostdlib ${wl}-M $wl$lib.exp -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM $lib.exp'
++
++	        # Commands to make compiler produce verbose output that lists
++	        # what "hidden" libraries, object files and flags are used when
++	        # linking a shared library.
++	        output_verbose_link_cmd='$CC -G $CFLAGS -v conftest.$objext 2>&1 | $GREP "\-L"'
++	      fi
++
++	      _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-R $wl$libdir'
++	      case $host_os in
++		solaris2.[[0-5]] | solaris2.[[0-5]].*) ;;
++		*)
++		  _LT_TAGVAR(whole_archive_flag_spec, $1)='${wl}-z ${wl}allextract$convenience ${wl}-z ${wl}defaultextract'
++		  ;;
++	      esac
++	    fi
++	    ;;
++        esac
++        ;;
++
++    sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* | sco3.2v5.0.[[024]]*)
++      _LT_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
++      _LT_TAGVAR(archive_cmds_need_lc, $1)=no
++      _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++      runpath_var='LD_RUN_PATH'
++
++      case $cc_basename in
++        CC*)
++	  _LT_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	  _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	  ;;
++	*)
++	  _LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	  _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	  ;;
++      esac
++      ;;
++
++      sysv5* | sco3.2v5* | sco5v6*)
++	# Note: We can NOT use -z defs as we might desire, because we do not
++	# link with -lc, and that would cause any symbols used from libc to
++	# always be unresolved, which means just about no library would
++	# ever link correctly.  If we're not using GNU ld we use -z text
++	# though, which does catch some bad symbols but isn't as heavy-handed
++	# as -z defs.
++	_LT_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
++	_LT_TAGVAR(allow_undefined_flag, $1)='${wl}-z,nodefs'
++	_LT_TAGVAR(archive_cmds_need_lc, $1)=no
++	_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
++	_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-R,$libdir'
++	_LT_TAGVAR(hardcode_libdir_separator, $1)=':'
++	_LT_TAGVAR(link_all_deplibs, $1)=yes
++	_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-Bexport'
++	runpath_var='LD_RUN_PATH'
++
++	case $cc_basename in
++          CC*)
++	    _LT_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	    _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	    ;;
++	  *)
++	    _LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	    _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	    ;;
++	esac
++      ;;
++
++      tandem*)
++        case $cc_basename in
++          NCC*)
++	    # NonStop-UX NCC 3.20
++	    # FIXME: insert proper C++ library support
++	    _LT_TAGVAR(ld_shlibs, $1)=no
++	    ;;
++          *)
++	    # FIXME: insert proper C++ library support
++	    _LT_TAGVAR(ld_shlibs, $1)=no
++	    ;;
++        esac
++        ;;
++
++      vxworks*)
++        # FIXME: insert proper C++ library support
++        _LT_TAGVAR(ld_shlibs, $1)=no
++        ;;
++
++      *)
++        # FIXME: insert proper C++ library support
++        _LT_TAGVAR(ld_shlibs, $1)=no
++        ;;
++    esac
++
++    AC_MSG_RESULT([$_LT_TAGVAR(ld_shlibs, $1)])
++    test "$_LT_TAGVAR(ld_shlibs, $1)" = no && can_build_shared=no
++
++    _LT_TAGVAR(GCC, $1)="$GXX"
++    _LT_TAGVAR(LD, $1)="$LD"
++
++    ## CAVEAT EMPTOR:
++    ## There is no encapsulation within the following macros, do not change
++    ## the running order or otherwise move them around unless you know exactly
++    ## what you are doing...
++    _LT_SYS_HIDDEN_LIBDEPS($1)
++    _LT_COMPILER_PIC($1)
++    _LT_COMPILER_C_O($1)
++    _LT_COMPILER_FILE_LOCKS($1)
++    _LT_LINKER_SHLIBS($1)
++    _LT_SYS_DYNAMIC_LINKER($1)
++    _LT_LINKER_HARDCODE_LIBPATH($1)
++
++    _LT_CONFIG($1)
++  fi # test -n "$compiler"
++
++  CC=$lt_save_CC
++  LDCXX=$LD
++  LD=$lt_save_LD
++  GCC=$lt_save_GCC
++  with_gnu_ld=$lt_save_with_gnu_ld
++  lt_cv_path_LDCXX=$lt_cv_path_LD
++  lt_cv_path_LD=$lt_save_path_LD
++  lt_cv_prog_gnu_ldcxx=$lt_cv_prog_gnu_ld
++  lt_cv_prog_gnu_ld=$lt_save_with_gnu_ld
++fi # test "$_lt_caught_CXX_error" != yes
++
++AC_LANG_POP
++])# _LT_LANG_CXX_CONFIG
++
++
++# _LT_SYS_HIDDEN_LIBDEPS([TAGNAME])
++# ---------------------------------
++# Figure out "hidden" library dependencies from verbose
++# compiler output when linking a shared library.
++# Parse the compiler output and extract the necessary
++# objects, libraries and library flags.
++m4_defun([_LT_SYS_HIDDEN_LIBDEPS],
++[m4_require([_LT_FILEUTILS_DEFAULTS])dnl
++# Dependencies to place before and after the object being linked:
++_LT_TAGVAR(predep_objects, $1)=
++_LT_TAGVAR(postdep_objects, $1)=
++_LT_TAGVAR(predeps, $1)=
++_LT_TAGVAR(postdeps, $1)=
++_LT_TAGVAR(compiler_lib_search_path, $1)=
++
++dnl we can't use the lt_simple_compile_test_code here,
++dnl because it contains code intended for an executable,
++dnl not a library.  It's possible we should let each
++dnl tag define a new lt_????_link_test_code variable,
++dnl but it's only used here...
++m4_if([$1], [], [cat > conftest.$ac_ext <<_LT_EOF
++int a;
++void foo (void) { a = 0; }
++_LT_EOF
++], [$1], [CXX], [cat > conftest.$ac_ext <<_LT_EOF
++class Foo
++{
++public:
++  Foo (void) { a = 0; }
++private:
++  int a;
++};
++_LT_EOF
++], [$1], [F77], [cat > conftest.$ac_ext <<_LT_EOF
++      subroutine foo
++      implicit none
++      integer*4 a
++      a=0
++      return
++      end
++_LT_EOF
++], [$1], [FC], [cat > conftest.$ac_ext <<_LT_EOF
++      subroutine foo
++      implicit none
++      integer a
++      a=0
++      return
++      end
++_LT_EOF
++], [$1], [GCJ], [cat > conftest.$ac_ext <<_LT_EOF
++public class foo {
++  private int a;
++  public void bar (void) {
++    a = 0;
++  }
++};
++_LT_EOF
++])
++dnl Parse the compiler output and extract the necessary
++dnl objects, libraries and library flags.
++if AC_TRY_EVAL(ac_compile); then
++  # Parse the compiler output and extract the necessary
++  # objects, libraries and library flags.
++
++  # Sentinel used to keep track of whether or not we are before
++  # the conftest object file.
++  pre_test_object_deps_done=no
++
++  for p in `eval "$output_verbose_link_cmd"`; do
++    case $p in
++
++    -L* | -R* | -l*)
++       # Some compilers place space between "-{L,R}" and the path.
++       # Remove the space.
++       if test $p = "-L" ||
++          test $p = "-R"; then
++	 prev=$p
++	 continue
++       else
++	 prev=
++       fi
++
++       if test "$pre_test_object_deps_done" = no; then
++	 case $p in
++	 -L* | -R*)
++	   # Internal compiler library paths should come after those
++	   # provided the user.  The postdeps already come after the
++	   # user supplied libs so there is no need to process them.
++	   if test -z "$_LT_TAGVAR(compiler_lib_search_path, $1)"; then
++	     _LT_TAGVAR(compiler_lib_search_path, $1)="${prev}${p}"
++	   else
++	     _LT_TAGVAR(compiler_lib_search_path, $1)="${_LT_TAGVAR(compiler_lib_search_path, $1)} ${prev}${p}"
++	   fi
++	   ;;
++	 # The "-l" case would never come before the object being
++	 # linked, so don't bother handling this case.
++	 esac
++       else
++	 if test -z "$_LT_TAGVAR(postdeps, $1)"; then
++	   _LT_TAGVAR(postdeps, $1)="${prev}${p}"
++	 else
++	   _LT_TAGVAR(postdeps, $1)="${_LT_TAGVAR(postdeps, $1)} ${prev}${p}"
++	 fi
++       fi
++       ;;
++
++    *.$objext)
++       # This assumes that the test object file only shows up
++       # once in the compiler output.
++       if test "$p" = "conftest.$objext"; then
++	 pre_test_object_deps_done=yes
++	 continue
++       fi
++
++       if test "$pre_test_object_deps_done" = no; then
++	 if test -z "$_LT_TAGVAR(predep_objects, $1)"; then
++	   _LT_TAGVAR(predep_objects, $1)="$p"
++	 else
++	   _LT_TAGVAR(predep_objects, $1)="$_LT_TAGVAR(predep_objects, $1) $p"
++	 fi
++       else
++	 if test -z "$_LT_TAGVAR(postdep_objects, $1)"; then
++	   _LT_TAGVAR(postdep_objects, $1)="$p"
++	 else
++	   _LT_TAGVAR(postdep_objects, $1)="$_LT_TAGVAR(postdep_objects, $1) $p"
++	 fi
++       fi
++       ;;
++
++    *) ;; # Ignore the rest.
++
++    esac
++  done
++
++  # Clean up.
++  rm -f a.out a.exe
++else
++  echo "libtool.m4: error: problem compiling $1 test program"
++fi
++
++$RM -f confest.$objext
++
++# PORTME: override above test on systems where it is broken
++m4_if([$1], [CXX],
++[case $host_os in
++interix[[3-9]]*)
++  # Interix 3.5 installs completely hosed .la files for C++, so rather than
++  # hack all around it, let's just trust "g++" to DTRT.
++  _LT_TAGVAR(predep_objects,$1)=
++  _LT_TAGVAR(postdep_objects,$1)=
++  _LT_TAGVAR(postdeps,$1)=
++  ;;
++
++linux*)
++  case `$CC -V 2>&1 | sed 5q` in
++  *Sun\ C*)
++    # Sun C++ 5.9
++
++    # The more standards-conforming stlport4 library is
++    # incompatible with the Cstd library. Avoid specifying
++    # it if it's in CXXFLAGS. Ignore libCrun as
++    # -library=stlport4 depends on it.
++    case " $CXX $CXXFLAGS " in
++    *" -library=stlport4 "*)
++      solaris_use_stlport4=yes
++      ;;
++    esac
++
++    if test "$solaris_use_stlport4" != yes; then
++      _LT_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun'
++    fi
++    ;;
++  esac
++  ;;
++
++solaris*)
++  case $cc_basename in
++  CC*)
++    # The more standards-conforming stlport4 library is
++    # incompatible with the Cstd library. Avoid specifying
++    # it if it's in CXXFLAGS. Ignore libCrun as
++    # -library=stlport4 depends on it.
++    case " $CXX $CXXFLAGS " in
++    *" -library=stlport4 "*)
++      solaris_use_stlport4=yes
++      ;;
++    esac
++
++    # Adding this requires a known-good setup of shared libraries for
++    # Sun compiler versions before 5.6, else PIC objects from an old
++    # archive will be linked into the output, leading to subtle bugs.
++    if test "$solaris_use_stlport4" != yes; then
++      _LT_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun'
++    fi
++    ;;
++  esac
++  ;;
++esac
++])
++
++case " $_LT_TAGVAR(postdeps, $1) " in
++*" -lc "*) _LT_TAGVAR(archive_cmds_need_lc, $1)=no ;;
++esac
++ _LT_TAGVAR(compiler_lib_search_dirs, $1)=
++if test -n "${_LT_TAGVAR(compiler_lib_search_path, $1)}"; then
++ _LT_TAGVAR(compiler_lib_search_dirs, $1)=`echo " ${_LT_TAGVAR(compiler_lib_search_path, $1)}" | ${SED} -e 's! -L! !g' -e 's!^ !!'`
++fi
++_LT_TAGDECL([], [compiler_lib_search_dirs], [1],
++    [The directories searched by this compiler when creating a shared library])
++_LT_TAGDECL([], [predep_objects], [1],
++    [Dependencies to place before and after the objects being linked to
++    create a shared library])
++_LT_TAGDECL([], [postdep_objects], [1])
++_LT_TAGDECL([], [predeps], [1])
++_LT_TAGDECL([], [postdeps], [1])
++_LT_TAGDECL([], [compiler_lib_search_path], [1],
++    [The library search path used internally by the compiler when linking
++    a shared library])
++])# _LT_SYS_HIDDEN_LIBDEPS
++
++
++# _LT_PROG_F77
++# ------------
++# Since AC_PROG_F77 is broken, in that it returns the empty string
++# if there is no fortran compiler, we have our own version here.
++m4_defun([_LT_PROG_F77],
++[
++pushdef([AC_MSG_ERROR], [_lt_disable_F77=yes])
++AC_PROG_F77
++if test -z "$F77" || test "X$F77" = "Xno"; then
++  _lt_disable_F77=yes
++fi
++popdef([AC_MSG_ERROR])
++])# _LT_PROG_F77
++
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([_LT_PROG_F77], [])
++
++
++# _LT_LANG_F77_CONFIG([TAG])
++# --------------------------
++# Ensure that the configuration variables for a Fortran 77 compiler are
++# suitably defined.  These variables are subsequently used by _LT_CONFIG
++# to write the compiler configuration to `libtool'.
++m4_defun([_LT_LANG_F77_CONFIG],
++[AC_REQUIRE([_LT_PROG_F77])dnl
++AC_LANG_PUSH(Fortran 77)
++
++_LT_TAGVAR(archive_cmds_need_lc, $1)=no
++_LT_TAGVAR(allow_undefined_flag, $1)=
++_LT_TAGVAR(always_export_symbols, $1)=no
++_LT_TAGVAR(archive_expsym_cmds, $1)=
++_LT_TAGVAR(export_dynamic_flag_spec, $1)=
++_LT_TAGVAR(hardcode_direct, $1)=no
++_LT_TAGVAR(hardcode_direct_absolute, $1)=no
++_LT_TAGVAR(hardcode_libdir_flag_spec, $1)=
++_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)=
++_LT_TAGVAR(hardcode_libdir_separator, $1)=
++_LT_TAGVAR(hardcode_minus_L, $1)=no
++_LT_TAGVAR(hardcode_automatic, $1)=no
++_LT_TAGVAR(inherit_rpath, $1)=no
++_LT_TAGVAR(module_cmds, $1)=
++_LT_TAGVAR(module_expsym_cmds, $1)=
++_LT_TAGVAR(link_all_deplibs, $1)=unknown
++_LT_TAGVAR(old_archive_cmds, $1)=$old_archive_cmds
++_LT_TAGVAR(no_undefined_flag, $1)=
++_LT_TAGVAR(whole_archive_flag_spec, $1)=
++_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=no
++
++# Source file extension for f77 test sources.
++ac_ext=f
++
++# Object file extension for compiled f77 test sources.
++objext=o
++_LT_TAGVAR(objext, $1)=$objext
++
++# No sense in running all these tests if we already determined that
++# the F77 compiler isn't working.  Some variables (like enable_shared)
++# are currently assumed to apply to all compilers on this platform,
++# and will be corrupted by setting them based on a non-working compiler.
++if test "$_lt_disable_F77" != yes; then
++  # Code to be used in simple compile tests
++  lt_simple_compile_test_code="\
++      subroutine t
++      return
++      end
++"
++
++  # Code to be used in simple link tests
++  lt_simple_link_test_code="\
++      program t
++      end
++"
++
++  # ltmain only uses $CC for tagged configurations so make sure $CC is set.
++  _LT_TAG_COMPILER
++
++  # save warnings/boilerplate of simple test code
++  _LT_COMPILER_BOILERPLATE
++  _LT_LINKER_BOILERPLATE
++
++  # Allow CC to be a program name with arguments.
++  lt_save_CC="$CC"
++  lt_save_GCC=$GCC
++  CC=${F77-"f77"}
++  compiler=$CC
++  _LT_TAGVAR(compiler, $1)=$CC
++  _LT_CC_BASENAME([$compiler])
++  GCC=$G77
++  if test -n "$compiler"; then
++    AC_MSG_CHECKING([if libtool supports shared libraries])
++    AC_MSG_RESULT([$can_build_shared])
++
++    AC_MSG_CHECKING([whether to build shared libraries])
++    test "$can_build_shared" = "no" && enable_shared=no
++
++    # On AIX, shared libraries and static libraries use the same namespace, and
++    # are all built from PIC.
++    case $host_os in
++      aix3*)
++        test "$enable_shared" = yes && enable_static=no
++        if test -n "$RANLIB"; then
++          archive_cmds="$archive_cmds~\$RANLIB \$lib"
++          postinstall_cmds='$RANLIB $lib'
++        fi
++        ;;
++      aix[[4-9]]*)
++	if test "$host_cpu" != ia64 && test "$aix_use_runtimelinking" = no ; then
++	  test "$enable_shared" = yes && enable_static=no
++	fi
++        ;;
++    esac
++    AC_MSG_RESULT([$enable_shared])
++
++    AC_MSG_CHECKING([whether to build static libraries])
++    # Make sure either enable_shared or enable_static is yes.
++    test "$enable_shared" = yes || enable_static=yes
++    AC_MSG_RESULT([$enable_static])
++
++    _LT_TAGVAR(GCC, $1)="$G77"
++    _LT_TAGVAR(LD, $1)="$LD"
++
++    ## CAVEAT EMPTOR:
++    ## There is no encapsulation within the following macros, do not change
++    ## the running order or otherwise move them around unless you know exactly
++    ## what you are doing...
++    _LT_COMPILER_PIC($1)
++    _LT_COMPILER_C_O($1)
++    _LT_COMPILER_FILE_LOCKS($1)
++    _LT_LINKER_SHLIBS($1)
++    _LT_SYS_DYNAMIC_LINKER($1)
++    _LT_LINKER_HARDCODE_LIBPATH($1)
++
++    _LT_CONFIG($1)
++  fi # test -n "$compiler"
++
++  GCC=$lt_save_GCC
++  CC="$lt_save_CC"
++fi # test "$_lt_disable_F77" != yes
++
++AC_LANG_POP
++])# _LT_LANG_F77_CONFIG
++
++
++# _LT_PROG_FC
++# -----------
++# Since AC_PROG_FC is broken, in that it returns the empty string
++# if there is no fortran compiler, we have our own version here.
++m4_defun([_LT_PROG_FC],
++[
++pushdef([AC_MSG_ERROR], [_lt_disable_FC=yes])
++AC_PROG_FC
++if test -z "$FC" || test "X$FC" = "Xno"; then
++  _lt_disable_FC=yes
++fi
++popdef([AC_MSG_ERROR])
++])# _LT_PROG_FC
++
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([_LT_PROG_FC], [])
++
++
++# _LT_LANG_FC_CONFIG([TAG])
++# -------------------------
++# Ensure that the configuration variables for a Fortran compiler are
++# suitably defined.  These variables are subsequently used by _LT_CONFIG
++# to write the compiler configuration to `libtool'.
++m4_defun([_LT_LANG_FC_CONFIG],
++[AC_REQUIRE([_LT_PROG_FC])dnl
++AC_LANG_PUSH(Fortran)
++
++_LT_TAGVAR(archive_cmds_need_lc, $1)=no
++_LT_TAGVAR(allow_undefined_flag, $1)=
++_LT_TAGVAR(always_export_symbols, $1)=no
++_LT_TAGVAR(archive_expsym_cmds, $1)=
++_LT_TAGVAR(export_dynamic_flag_spec, $1)=
++_LT_TAGVAR(hardcode_direct, $1)=no
++_LT_TAGVAR(hardcode_direct_absolute, $1)=no
++_LT_TAGVAR(hardcode_libdir_flag_spec, $1)=
++_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)=
++_LT_TAGVAR(hardcode_libdir_separator, $1)=
++_LT_TAGVAR(hardcode_minus_L, $1)=no
++_LT_TAGVAR(hardcode_automatic, $1)=no
++_LT_TAGVAR(inherit_rpath, $1)=no
++_LT_TAGVAR(module_cmds, $1)=
++_LT_TAGVAR(module_expsym_cmds, $1)=
++_LT_TAGVAR(link_all_deplibs, $1)=unknown
++_LT_TAGVAR(old_archive_cmds, $1)=$old_archive_cmds
++_LT_TAGVAR(no_undefined_flag, $1)=
++_LT_TAGVAR(whole_archive_flag_spec, $1)=
++_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=no
++
++# Source file extension for fc test sources.
++ac_ext=${ac_fc_srcext-f}
++
++# Object file extension for compiled fc test sources.
++objext=o
++_LT_TAGVAR(objext, $1)=$objext
++
++# No sense in running all these tests if we already determined that
++# the FC compiler isn't working.  Some variables (like enable_shared)
++# are currently assumed to apply to all compilers on this platform,
++# and will be corrupted by setting them based on a non-working compiler.
++if test "$_lt_disable_FC" != yes; then
++  # Code to be used in simple compile tests
++  lt_simple_compile_test_code="\
++      subroutine t
++      return
++      end
++"
++
++  # Code to be used in simple link tests
++  lt_simple_link_test_code="\
++      program t
++      end
++"
++
++  # ltmain only uses $CC for tagged configurations so make sure $CC is set.
++  _LT_TAG_COMPILER
++
++  # save warnings/boilerplate of simple test code
++  _LT_COMPILER_BOILERPLATE
++  _LT_LINKER_BOILERPLATE
++
++  # Allow CC to be a program name with arguments.
++  lt_save_CC="$CC"
++  lt_save_GCC=$GCC
++  CC=${FC-"f95"}
++  compiler=$CC
++  GCC=$ac_cv_fc_compiler_gnu
++
++  _LT_TAGVAR(compiler, $1)=$CC
++  _LT_CC_BASENAME([$compiler])
++
++  if test -n "$compiler"; then
++    AC_MSG_CHECKING([if libtool supports shared libraries])
++    AC_MSG_RESULT([$can_build_shared])
++
++    AC_MSG_CHECKING([whether to build shared libraries])
++    test "$can_build_shared" = "no" && enable_shared=no
++
++    # On AIX, shared libraries and static libraries use the same namespace, and
++    # are all built from PIC.
++    case $host_os in
++      aix3*)
++        test "$enable_shared" = yes && enable_static=no
++        if test -n "$RANLIB"; then
++          archive_cmds="$archive_cmds~\$RANLIB \$lib"
++          postinstall_cmds='$RANLIB $lib'
++        fi
++        ;;
++      aix[[4-9]]*)
++	if test "$host_cpu" != ia64 && test "$aix_use_runtimelinking" = no ; then
++	  test "$enable_shared" = yes && enable_static=no
++	fi
++        ;;
++    esac
++    AC_MSG_RESULT([$enable_shared])
++
++    AC_MSG_CHECKING([whether to build static libraries])
++    # Make sure either enable_shared or enable_static is yes.
++    test "$enable_shared" = yes || enable_static=yes
++    AC_MSG_RESULT([$enable_static])
++
++    _LT_TAGVAR(GCC, $1)="$ac_cv_fc_compiler_gnu"
++    _LT_TAGVAR(LD, $1)="$LD"
++
++    ## CAVEAT EMPTOR:
++    ## There is no encapsulation within the following macros, do not change
++    ## the running order or otherwise move them around unless you know exactly
++    ## what you are doing...
++    _LT_SYS_HIDDEN_LIBDEPS($1)
++    _LT_COMPILER_PIC($1)
++    _LT_COMPILER_C_O($1)
++    _LT_COMPILER_FILE_LOCKS($1)
++    _LT_LINKER_SHLIBS($1)
++    _LT_SYS_DYNAMIC_LINKER($1)
++    _LT_LINKER_HARDCODE_LIBPATH($1)
++
++    _LT_CONFIG($1)
++  fi # test -n "$compiler"
++
++  GCC=$lt_save_GCC
++  CC="$lt_save_CC"
++fi # test "$_lt_disable_FC" != yes
++
++AC_LANG_POP
++])# _LT_LANG_FC_CONFIG
++
++
++# _LT_LANG_GCJ_CONFIG([TAG])
++# --------------------------
++# Ensure that the configuration variables for the GNU Java Compiler compiler
++# are suitably defined.  These variables are subsequently used by _LT_CONFIG
++# to write the compiler configuration to `libtool'.
++m4_defun([_LT_LANG_GCJ_CONFIG],
++[AC_REQUIRE([LT_PROG_GCJ])dnl
++AC_LANG_SAVE
++
++# Source file extension for Java test sources.
++ac_ext=java
++
++# Object file extension for compiled Java test sources.
++objext=o
++_LT_TAGVAR(objext, $1)=$objext
++
++# Code to be used in simple compile tests
++lt_simple_compile_test_code="class foo {}"
++
++# Code to be used in simple link tests
++lt_simple_link_test_code='public class conftest { public static void main(String[[]] argv) {}; }'
++
++# ltmain only uses $CC for tagged configurations so make sure $CC is set.
++_LT_TAG_COMPILER
++
++# save warnings/boilerplate of simple test code
++_LT_COMPILER_BOILERPLATE
++_LT_LINKER_BOILERPLATE
++
++# Allow CC to be a program name with arguments.
++lt_save_CC="$CC"
++lt_save_GCC=$GCC
++GCC=yes
++CC=${GCJ-"gcj"}
++compiler=$CC
++_LT_TAGVAR(compiler, $1)=$CC
++_LT_TAGVAR(LD, $1)="$LD"
++_LT_CC_BASENAME([$compiler])
++
++# GCJ did not exist at the time GCC didn't implicitly link libc in.
++_LT_TAGVAR(archive_cmds_need_lc, $1)=no
++
++_LT_TAGVAR(old_archive_cmds, $1)=$old_archive_cmds
++
++## CAVEAT EMPTOR:
++## There is no encapsulation within the following macros, do not change
++## the running order or otherwise move them around unless you know exactly
++## what you are doing...
++if test -n "$compiler"; then
++  _LT_COMPILER_NO_RTTI($1)
++  _LT_COMPILER_PIC($1)
++  _LT_COMPILER_C_O($1)
++  _LT_COMPILER_FILE_LOCKS($1)
++  _LT_LINKER_SHLIBS($1)
++  _LT_LINKER_HARDCODE_LIBPATH($1)
++
++  _LT_CONFIG($1)
++fi
++
++AC_LANG_RESTORE
++
++GCC=$lt_save_GCC
++CC="$lt_save_CC"
++])# _LT_LANG_GCJ_CONFIG
++
++
++# _LT_LANG_RC_CONFIG([TAG])
++# -------------------------
++# Ensure that the configuration variables for the Windows resource compiler
++# are suitably defined.  These variables are subsequently used by _LT_CONFIG
++# to write the compiler configuration to `libtool'.
++m4_defun([_LT_LANG_RC_CONFIG],
++[AC_REQUIRE([LT_PROG_RC])dnl
++AC_LANG_SAVE
++
++# Source file extension for RC test sources.
++ac_ext=rc
++
++# Object file extension for compiled RC test sources.
++objext=o
++_LT_TAGVAR(objext, $1)=$objext
++
++# Code to be used in simple compile tests
++lt_simple_compile_test_code='sample MENU { MENUITEM "&Soup", 100, CHECKED }'
++
++# Code to be used in simple link tests
++lt_simple_link_test_code="$lt_simple_compile_test_code"
++
++# ltmain only uses $CC for tagged configurations so make sure $CC is set.
++_LT_TAG_COMPILER
++
++# save warnings/boilerplate of simple test code
++_LT_COMPILER_BOILERPLATE
++_LT_LINKER_BOILERPLATE
++
++# Allow CC to be a program name with arguments.
++lt_save_CC="$CC"
++lt_save_GCC=$GCC
++GCC=
++CC=${RC-"windres"}
++compiler=$CC
++_LT_TAGVAR(compiler, $1)=$CC
++_LT_CC_BASENAME([$compiler])
++_LT_TAGVAR(lt_cv_prog_compiler_c_o, $1)=yes
++
++if test -n "$compiler"; then
++  :
++  _LT_CONFIG($1)
++fi
++
++GCC=$lt_save_GCC
++AC_LANG_RESTORE
++CC="$lt_save_CC"
++])# _LT_LANG_RC_CONFIG
++
++
++# LT_PROG_GCJ
++# -----------
++AC_DEFUN([LT_PROG_GCJ],
++[m4_ifdef([AC_PROG_GCJ], [AC_PROG_GCJ],
++  [m4_ifdef([A][M_PROG_GCJ], [A][M_PROG_GCJ],
++    [AC_CHECK_TOOL(GCJ, gcj,)
++      test "x${GCJFLAGS+set}" = xset || GCJFLAGS="-g -O2"
++      AC_SUBST(GCJFLAGS)])])[]dnl
++])
++
++# Old name:
++AU_ALIAS([LT_AC_PROG_GCJ], [LT_PROG_GCJ])
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([LT_AC_PROG_GCJ], [])
++
++
++# LT_PROG_RC
++# ----------
++AC_DEFUN([LT_PROG_RC],
++[AC_CHECK_TOOL(RC, windres,)
++])
++
++# Old name:
++AU_ALIAS([LT_AC_PROG_RC], [LT_PROG_RC])
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([LT_AC_PROG_RC], [])
++
++
++# _LT_DECL_EGREP
++# --------------
++# If we don't have a new enough Autoconf to choose the best grep
++# available, choose the one first in the user's PATH.
++m4_defun([_LT_DECL_EGREP],
++[AC_REQUIRE([AC_PROG_EGREP])dnl
++AC_REQUIRE([AC_PROG_FGREP])dnl
++test -z "$GREP" && GREP=grep
++_LT_DECL([], [GREP], [1], [A grep program that handles long lines])
++_LT_DECL([], [EGREP], [1], [An ERE matcher])
++_LT_DECL([], [FGREP], [1], [A literal string matcher])
++dnl Non-bleeding-edge autoconf doesn't subst GREP, so do it here too
++AC_SUBST([GREP])
++])
++
++
++# _LT_DECL_OBJDUMP
++# --------------
++# If we don't have a new enough Autoconf to choose the best objdump
++# available, choose the one first in the user's PATH.
++m4_defun([_LT_DECL_OBJDUMP],
++[AC_CHECK_TOOL(OBJDUMP, objdump, false)
++test -z "$OBJDUMP" && OBJDUMP=objdump
++_LT_DECL([], [OBJDUMP], [1], [An object symbol dumper])
++AC_SUBST([OBJDUMP])
++])
++
++
++# _LT_DECL_SED
++# ------------
++# Check for a fully-functional sed program, that truncates
++# as few characters as possible.  Prefer GNU sed if found.
++m4_defun([_LT_DECL_SED],
++[AC_PROG_SED
++test -z "$SED" && SED=sed
++Xsed="$SED -e 1s/^X//"
++_LT_DECL([], [SED], [1], [A sed program that does not truncate output])
++_LT_DECL([], [Xsed], ["\$SED -e 1s/^X//"],
++    [Sed that helps us avoid accidentally triggering echo(1) options like -n])
++])# _LT_DECL_SED
++
++m4_ifndef([AC_PROG_SED], [
++############################################################
++# NOTE: This macro has been submitted for inclusion into   #
++#  GNU Autoconf as AC_PROG_SED.  When it is available in   #
++#  a released version of Autoconf we should remove this    #
++#  macro and use it instead.                               #
++############################################################
++
++m4_defun([AC_PROG_SED],
++[AC_MSG_CHECKING([for a sed that does not truncate output])
++AC_CACHE_VAL(lt_cv_path_SED,
++[# Loop through the user's path and test for sed and gsed.
++# Then use that list of sed's as ones to test for truncation.
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++  for lt_ac_prog in sed gsed; do
++    for ac_exec_ext in '' $ac_executable_extensions; do
++      if $as_executable_p "$as_dir/$lt_ac_prog$ac_exec_ext"; then
++        lt_ac_sed_list="$lt_ac_sed_list $as_dir/$lt_ac_prog$ac_exec_ext"
++      fi
++    done
++  done
++done
++IFS=$as_save_IFS
++lt_ac_max=0
++lt_ac_count=0
++# Add /usr/xpg4/bin/sed as it is typically found on Solaris
++# along with /bin/sed that truncates output.
++for lt_ac_sed in $lt_ac_sed_list /usr/xpg4/bin/sed; do
++  test ! -f $lt_ac_sed && continue
++  cat /dev/null > conftest.in
++  lt_ac_count=0
++  echo $ECHO_N "0123456789$ECHO_C" >conftest.in
++  # Check for GNU sed and select it if it is found.
++  if "$lt_ac_sed" --version 2>&1 < /dev/null | grep 'GNU' > /dev/null; then
++    lt_cv_path_SED=$lt_ac_sed
++    break
++  fi
++  while true; do
++    cat conftest.in conftest.in >conftest.tmp
++    mv conftest.tmp conftest.in
++    cp conftest.in conftest.nl
++    echo >>conftest.nl
++    $lt_ac_sed -e 's/a$//' < conftest.nl >conftest.out || break
++    cmp -s conftest.out conftest.nl || break
++    # 10000 chars as input seems more than enough
++    test $lt_ac_count -gt 10 && break
++    lt_ac_count=`expr $lt_ac_count + 1`
++    if test $lt_ac_count -gt $lt_ac_max; then
++      lt_ac_max=$lt_ac_count
++      lt_cv_path_SED=$lt_ac_sed
++    fi
++  done
++done
++])
++SED=$lt_cv_path_SED
++AC_SUBST([SED])
++AC_MSG_RESULT([$SED])
++])#AC_PROG_SED
++])#m4_ifndef
++
++# Old name:
++AU_ALIAS([LT_AC_PROG_SED], [AC_PROG_SED])
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([LT_AC_PROG_SED], [])
++
++
++# _LT_CHECK_SHELL_FEATURES
++# ------------------------
++# Find out whether the shell is Bourne or XSI compatible,
++# or has some other useful features.
++m4_defun([_LT_CHECK_SHELL_FEATURES],
++[AC_MSG_CHECKING([whether the shell understands some XSI constructs])
++# Try some XSI features
++xsi_shell=no
++( _lt_dummy="a/b/c"
++  test "${_lt_dummy##*/},${_lt_dummy%/*},"${_lt_dummy%"$_lt_dummy"}, \
++      = c,a/b,, \
++    && eval 'test $(( 1 + 1 )) -eq 2 \
++    && test "${#_lt_dummy}" -eq 5' ) >/dev/null 2>&1 \
++  && xsi_shell=yes
++AC_MSG_RESULT([$xsi_shell])
++_LT_CONFIG_LIBTOOL_INIT([xsi_shell='$xsi_shell'])
++
++AC_MSG_CHECKING([whether the shell understands "+="])
++lt_shell_append=no
++( foo=bar; set foo baz; eval "$[1]+=\$[2]" && test "$foo" = barbaz ) \
++    >/dev/null 2>&1 \
++  && lt_shell_append=yes
++AC_MSG_RESULT([$lt_shell_append])
++_LT_CONFIG_LIBTOOL_INIT([lt_shell_append='$lt_shell_append'])
++
++if ( (MAIL=60; unset MAIL) || exit) >/dev/null 2>&1; then
++  lt_unset=unset
++else
++  lt_unset=false
++fi
++_LT_DECL([], [lt_unset], [0], [whether the shell understands "unset"])dnl
++
++# test EBCDIC or ASCII
++case `echo X|tr X '\101'` in
++ A) # ASCII based system
++    # \n is not interpreted correctly by Solaris 8 /usr/ucb/tr
++  lt_SP2NL='tr \040 \012'
++  lt_NL2SP='tr \015\012 \040\040'
++  ;;
++ *) # EBCDIC based system
++  lt_SP2NL='tr \100 \n'
++  lt_NL2SP='tr \r\n \100\100'
++  ;;
++esac
++_LT_DECL([SP2NL], [lt_SP2NL], [1], [turn spaces into newlines])dnl
++_LT_DECL([NL2SP], [lt_NL2SP], [1], [turn newlines into spaces])dnl
++])# _LT_CHECK_SHELL_FEATURES
++
++
++# _LT_PROG_XSI_SHELLFNS
++# ---------------------
++# Bourne and XSI compatible variants of some useful shell functions.
++m4_defun([_LT_PROG_XSI_SHELLFNS],
++[case $xsi_shell in
++  yes)
++    cat << \_LT_EOF >> "$cfgfile"
++
++# func_dirname file append nondir_replacement
++# Compute the dirname of FILE.  If nonempty, add APPEND to the result,
++# otherwise set result to NONDIR_REPLACEMENT.
++func_dirname ()
++{
++  case ${1} in
++    */*) func_dirname_result="${1%/*}${2}" ;;
++    *  ) func_dirname_result="${3}" ;;
++  esac
++}
++
++# func_basename file
++func_basename ()
++{
++  func_basename_result="${1##*/}"
++}
++
++# func_dirname_and_basename file append nondir_replacement
++# perform func_basename and func_dirname in a single function
++# call:
++#   dirname:  Compute the dirname of FILE.  If nonempty,
++#             add APPEND to the result, otherwise set result
++#             to NONDIR_REPLACEMENT.
++#             value returned in "$func_dirname_result"
++#   basename: Compute filename of FILE.
++#             value retuned in "$func_basename_result"
++# Implementation must be kept synchronized with func_dirname
++# and func_basename. For efficiency, we do not delegate to
++# those functions but instead duplicate the functionality here.
++func_dirname_and_basename ()
++{
++  case ${1} in
++    */*) func_dirname_result="${1%/*}${2}" ;;
++    *  ) func_dirname_result="${3}" ;;
++  esac
++  func_basename_result="${1##*/}"
++}
++
++# func_stripname prefix suffix name
++# strip PREFIX and SUFFIX off of NAME.
++# PREFIX and SUFFIX must not contain globbing or regex special
++# characters, hashes, percent signs, but SUFFIX may contain a leading
++# dot (in which case that matches only a dot).
++func_stripname ()
++{
++  # pdksh 5.2.14 does not do ${X%$Y} correctly if both X and Y are
++  # positional parameters, so assign one to ordinary parameter first.
++  func_stripname_result=${3}
++  func_stripname_result=${func_stripname_result#"${1}"}
++  func_stripname_result=${func_stripname_result%"${2}"}
++}
++
++# func_opt_split
++func_opt_split ()
++{
++  func_opt_split_opt=${1%%=*}
++  func_opt_split_arg=${1#*=}
++}
++
++# func_lo2o object
++func_lo2o ()
++{
++  case ${1} in
++    *.lo) func_lo2o_result=${1%.lo}.${objext} ;;
++    *)    func_lo2o_result=${1} ;;
++  esac
++}
++
++# func_xform libobj-or-source
++func_xform ()
++{
++  func_xform_result=${1%.*}.lo
++}
++
++# func_arith arithmetic-term...
++func_arith ()
++{
++  func_arith_result=$(( $[*] ))
++}
++
++# func_len string
++# STRING may not start with a hyphen.
++func_len ()
++{
++  func_len_result=${#1}
++}
++
++_LT_EOF
++    ;;
++  *) # Bourne compatible functions.
++    cat << \_LT_EOF >> "$cfgfile"
++
++# func_dirname file append nondir_replacement
++# Compute the dirname of FILE.  If nonempty, add APPEND to the result,
++# otherwise set result to NONDIR_REPLACEMENT.
++func_dirname ()
++{
++  # Extract subdirectory from the argument.
++  func_dirname_result=`$ECHO "X${1}" | $Xsed -e "$dirname"`
++  if test "X$func_dirname_result" = "X${1}"; then
++    func_dirname_result="${3}"
++  else
++    func_dirname_result="$func_dirname_result${2}"
++  fi
++}
++
++# func_basename file
++func_basename ()
++{
++  func_basename_result=`$ECHO "X${1}" | $Xsed -e "$basename"`
++}
++
++dnl func_dirname_and_basename
++dnl A portable version of this function is already defined in general.m4sh
++dnl so there is no need for it here.
++
++# func_stripname prefix suffix name
++# strip PREFIX and SUFFIX off of NAME.
++# PREFIX and SUFFIX must not contain globbing or regex special
++# characters, hashes, percent signs, but SUFFIX may contain a leading
++# dot (in which case that matches only a dot).
++# func_strip_suffix prefix name
++func_stripname ()
++{
++  case ${2} in
++    .*) func_stripname_result=`$ECHO "X${3}" \
++           | $Xsed -e "s%^${1}%%" -e "s%\\\\${2}\$%%"`;;
++    *)  func_stripname_result=`$ECHO "X${3}" \
++           | $Xsed -e "s%^${1}%%" -e "s%${2}\$%%"`;;
++  esac
++}
++
++# sed scripts:
++my_sed_long_opt='1s/^\(-[[^=]]*\)=.*/\1/;q'
++my_sed_long_arg='1s/^-[[^=]]*=//'
++
++# func_opt_split
++func_opt_split ()
++{
++  func_opt_split_opt=`$ECHO "X${1}" | $Xsed -e "$my_sed_long_opt"`
++  func_opt_split_arg=`$ECHO "X${1}" | $Xsed -e "$my_sed_long_arg"`
++}
++
++# func_lo2o object
++func_lo2o ()
++{
++  func_lo2o_result=`$ECHO "X${1}" | $Xsed -e "$lo2o"`
++}
++
++# func_xform libobj-or-source
++func_xform ()
++{
++  func_xform_result=`$ECHO "X${1}" | $Xsed -e 's/\.[[^.]]*$/.lo/'`
++}
++
++# func_arith arithmetic-term...
++func_arith ()
++{
++  func_arith_result=`expr "$[@]"`
++}
++
++# func_len string
++# STRING may not start with a hyphen.
++func_len ()
++{
++  func_len_result=`expr "$[1]" : ".*" 2>/dev/null || echo $max_cmd_len`
++}
++
++_LT_EOF
++esac
++
++case $lt_shell_append in
++  yes)
++    cat << \_LT_EOF >> "$cfgfile"
++
++# func_append var value
++# Append VALUE to the end of shell variable VAR.
++func_append ()
++{
++  eval "$[1]+=\$[2]"
++}
++_LT_EOF
++    ;;
++  *)
++    cat << \_LT_EOF >> "$cfgfile"
++
++# func_append var value
++# Append VALUE to the end of shell variable VAR.
++func_append ()
++{
++  eval "$[1]=\$$[1]\$[2]"
++}
++
++_LT_EOF
++    ;;
++  esac
++])
+Index: git/cf/ltoptions.m4
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/cf/ltoptions.m4	2010-12-29 04:06:56.111937071 +0100
+@@ -0,0 +1,368 @@
++# Helper functions for option handling.                    -*- Autoconf -*-
++#
++#   Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
++#   Written by Gary V. Vaughan, 2004
++#
++# This file is free software; the Free Software Foundation gives
++# unlimited permission to copy and/or distribute it, with or without
++# modifications, as long as this notice is preserved.
++
++# serial 6 ltoptions.m4
++
++# This is to help aclocal find these macros, as it can't see m4_define.
++AC_DEFUN([LTOPTIONS_VERSION], [m4_if([1])])
++
++
++# _LT_MANGLE_OPTION(MACRO-NAME, OPTION-NAME)
++# ------------------------------------------
++m4_define([_LT_MANGLE_OPTION],
++[[_LT_OPTION_]m4_bpatsubst($1__$2, [[^a-zA-Z0-9_]], [_])])
++
++
++# _LT_SET_OPTION(MACRO-NAME, OPTION-NAME)
++# ---------------------------------------
++# Set option OPTION-NAME for macro MACRO-NAME, and if there is a
++# matching handler defined, dispatch to it.  Other OPTION-NAMEs are
++# saved as a flag.
++m4_define([_LT_SET_OPTION],
++[m4_define(_LT_MANGLE_OPTION([$1], [$2]))dnl
++m4_ifdef(_LT_MANGLE_DEFUN([$1], [$2]),
++        _LT_MANGLE_DEFUN([$1], [$2]),
++    [m4_warning([Unknown $1 option `$2'])])[]dnl
++])
++
++
++# _LT_IF_OPTION(MACRO-NAME, OPTION-NAME, IF-SET, [IF-NOT-SET])
++# ------------------------------------------------------------
++# Execute IF-SET if OPTION is set, IF-NOT-SET otherwise.
++m4_define([_LT_IF_OPTION],
++[m4_ifdef(_LT_MANGLE_OPTION([$1], [$2]), [$3], [$4])])
++
++
++# _LT_UNLESS_OPTIONS(MACRO-NAME, OPTION-LIST, IF-NOT-SET)
++# -------------------------------------------------------
++# Execute IF-NOT-SET unless all options in OPTION-LIST for MACRO-NAME
++# are set.
++m4_define([_LT_UNLESS_OPTIONS],
++[m4_foreach([_LT_Option], m4_split(m4_normalize([$2])),
++	    [m4_ifdef(_LT_MANGLE_OPTION([$1], _LT_Option),
++		      [m4_define([$0_found])])])[]dnl
++m4_ifdef([$0_found], [m4_undefine([$0_found])], [$3
++])[]dnl
++])
++
++
++# _LT_SET_OPTIONS(MACRO-NAME, OPTION-LIST)
++# ----------------------------------------
++# OPTION-LIST is a space-separated list of Libtool options associated
++# with MACRO-NAME.  If any OPTION has a matching handler declared with
++# LT_OPTION_DEFINE, dispatch to that macro; otherwise complain about
++# the unknown option and exit.
++m4_defun([_LT_SET_OPTIONS],
++[# Set options
++m4_foreach([_LT_Option], m4_split(m4_normalize([$2])),
++    [_LT_SET_OPTION([$1], _LT_Option)])
++
++m4_if([$1],[LT_INIT],[
++  dnl
++  dnl Simply set some default values (i.e off) if boolean options were not
++  dnl specified:
++  _LT_UNLESS_OPTIONS([LT_INIT], [dlopen], [enable_dlopen=no
++  ])
++  _LT_UNLESS_OPTIONS([LT_INIT], [win32-dll], [enable_win32_dll=no
++  ])
++  dnl
++  dnl If no reference was made to various pairs of opposing options, then
++  dnl we run the default mode handler for the pair.  For example, if neither
++  dnl `shared' nor `disable-shared' was passed, we enable building of shared
++  dnl archives by default:
++  _LT_UNLESS_OPTIONS([LT_INIT], [shared disable-shared], [_LT_ENABLE_SHARED])
++  _LT_UNLESS_OPTIONS([LT_INIT], [static disable-static], [_LT_ENABLE_STATIC])
++  _LT_UNLESS_OPTIONS([LT_INIT], [pic-only no-pic], [_LT_WITH_PIC])
++  _LT_UNLESS_OPTIONS([LT_INIT], [fast-install disable-fast-install],
++  		   [_LT_ENABLE_FAST_INSTALL])
++  ])
++])# _LT_SET_OPTIONS
++
++
++## --------------------------------- ##
++## Macros to handle LT_INIT options. ##
++## --------------------------------- ##
++
++# _LT_MANGLE_DEFUN(MACRO-NAME, OPTION-NAME)
++# -----------------------------------------
++m4_define([_LT_MANGLE_DEFUN],
++[[_LT_OPTION_DEFUN_]m4_bpatsubst(m4_toupper([$1__$2]), [[^A-Z0-9_]], [_])])
++
++
++# LT_OPTION_DEFINE(MACRO-NAME, OPTION-NAME, CODE)
++# -----------------------------------------------
++m4_define([LT_OPTION_DEFINE],
++[m4_define(_LT_MANGLE_DEFUN([$1], [$2]), [$3])[]dnl
++])# LT_OPTION_DEFINE
++
++
++# dlopen
++# ------
++LT_OPTION_DEFINE([LT_INIT], [dlopen], [enable_dlopen=yes
++])
++
++AU_DEFUN([AC_LIBTOOL_DLOPEN],
++[_LT_SET_OPTION([LT_INIT], [dlopen])
++AC_DIAGNOSE([obsolete],
++[$0: Remove this warning and the call to _LT_SET_OPTION when you
++put the `dlopen' option into LT_INIT's first parameter.])
++])
++
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AC_LIBTOOL_DLOPEN], [])
++
++
++# win32-dll
++# ---------
++# Declare package support for building win32 dll's.
++LT_OPTION_DEFINE([LT_INIT], [win32-dll],
++[enable_win32_dll=yes
++
++case $host in
++*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-cegcc*)
++  AC_CHECK_TOOL(AS, as, false)
++  AC_CHECK_TOOL(DLLTOOL, dlltool, false)
++  AC_CHECK_TOOL(OBJDUMP, objdump, false)
++  ;;
++esac
++
++test -z "$AS" && AS=as
++_LT_DECL([], [AS],      [0], [Assembler program])dnl
++
++test -z "$DLLTOOL" && DLLTOOL=dlltool
++_LT_DECL([], [DLLTOOL], [0], [DLL creation program])dnl
++
++test -z "$OBJDUMP" && OBJDUMP=objdump
++_LT_DECL([], [OBJDUMP], [0], [Object dumper program])dnl
++])# win32-dll
++
++AU_DEFUN([AC_LIBTOOL_WIN32_DLL],
++[AC_REQUIRE([AC_CANONICAL_HOST])dnl
++_LT_SET_OPTION([LT_INIT], [win32-dll])
++AC_DIAGNOSE([obsolete],
++[$0: Remove this warning and the call to _LT_SET_OPTION when you
++put the `win32-dll' option into LT_INIT's first parameter.])
++])
++
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AC_LIBTOOL_WIN32_DLL], [])
++
++
++# _LT_ENABLE_SHARED([DEFAULT])
++# ----------------------------
++# implement the --enable-shared flag, and supports the `shared' and
++# `disable-shared' LT_INIT options.
++# DEFAULT is either `yes' or `no'.  If omitted, it defaults to `yes'.
++m4_define([_LT_ENABLE_SHARED],
++[m4_define([_LT_ENABLE_SHARED_DEFAULT], [m4_if($1, no, no, yes)])dnl
++AC_ARG_ENABLE([shared],
++    [AS_HELP_STRING([--enable-shared@<:@=PKGS@:>@],
++	[build shared libraries @<:@default=]_LT_ENABLE_SHARED_DEFAULT[@:>@])],
++    [p=${PACKAGE-default}
++    case $enableval in
++    yes) enable_shared=yes ;;
++    no) enable_shared=no ;;
++    *)
++      enable_shared=no
++      # Look at the argument we got.  We use all the common list separators.
++      lt_save_ifs="$IFS"; IFS="${IFS}$PATH_SEPARATOR,"
++      for pkg in $enableval; do
++	IFS="$lt_save_ifs"
++	if test "X$pkg" = "X$p"; then
++	  enable_shared=yes
++	fi
++      done
++      IFS="$lt_save_ifs"
++      ;;
++    esac],
++    [enable_shared=]_LT_ENABLE_SHARED_DEFAULT)
++
++    _LT_DECL([build_libtool_libs], [enable_shared], [0],
++	[Whether or not to build shared libraries])
++])# _LT_ENABLE_SHARED
++
++LT_OPTION_DEFINE([LT_INIT], [shared], [_LT_ENABLE_SHARED([yes])])
++LT_OPTION_DEFINE([LT_INIT], [disable-shared], [_LT_ENABLE_SHARED([no])])
++
++# Old names:
++AC_DEFUN([AC_ENABLE_SHARED],
++[_LT_SET_OPTION([LT_INIT], m4_if([$1], [no], [disable-])[shared])
++])
++
++AC_DEFUN([AC_DISABLE_SHARED],
++[_LT_SET_OPTION([LT_INIT], [disable-shared])
++])
++
++AU_DEFUN([AM_ENABLE_SHARED], [AC_ENABLE_SHARED($@)])
++AU_DEFUN([AM_DISABLE_SHARED], [AC_DISABLE_SHARED($@)])
++
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AM_ENABLE_SHARED], [])
++dnl AC_DEFUN([AM_DISABLE_SHARED], [])
++
++
++
++# _LT_ENABLE_STATIC([DEFAULT])
++# ----------------------------
++# implement the --enable-static flag, and support the `static' and
++# `disable-static' LT_INIT options.
++# DEFAULT is either `yes' or `no'.  If omitted, it defaults to `yes'.
++m4_define([_LT_ENABLE_STATIC],
++[m4_define([_LT_ENABLE_STATIC_DEFAULT], [m4_if($1, no, no, yes)])dnl
++AC_ARG_ENABLE([static],
++    [AS_HELP_STRING([--enable-static@<:@=PKGS@:>@],
++	[build static libraries @<:@default=]_LT_ENABLE_STATIC_DEFAULT[@:>@])],
++    [p=${PACKAGE-default}
++    case $enableval in
++    yes) enable_static=yes ;;
++    no) enable_static=no ;;
++    *)
++     enable_static=no
++      # Look at the argument we got.  We use all the common list separators.
++      lt_save_ifs="$IFS"; IFS="${IFS}$PATH_SEPARATOR,"
++      for pkg in $enableval; do
++	IFS="$lt_save_ifs"
++	if test "X$pkg" = "X$p"; then
++	  enable_static=yes
++	fi
++      done
++      IFS="$lt_save_ifs"
++      ;;
++    esac],
++    [enable_static=]_LT_ENABLE_STATIC_DEFAULT)
++
++    _LT_DECL([build_old_libs], [enable_static], [0],
++	[Whether or not to build static libraries])
++])# _LT_ENABLE_STATIC
++
++LT_OPTION_DEFINE([LT_INIT], [static], [_LT_ENABLE_STATIC([yes])])
++LT_OPTION_DEFINE([LT_INIT], [disable-static], [_LT_ENABLE_STATIC([no])])
++
++# Old names:
++AC_DEFUN([AC_ENABLE_STATIC],
++[_LT_SET_OPTION([LT_INIT], m4_if([$1], [no], [disable-])[static])
++])
++
++AC_DEFUN([AC_DISABLE_STATIC],
++[_LT_SET_OPTION([LT_INIT], [disable-static])
++])
++
++AU_DEFUN([AM_ENABLE_STATIC], [AC_ENABLE_STATIC($@)])
++AU_DEFUN([AM_DISABLE_STATIC], [AC_DISABLE_STATIC($@)])
++
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AM_ENABLE_STATIC], [])
++dnl AC_DEFUN([AM_DISABLE_STATIC], [])
++
++
++
++# _LT_ENABLE_FAST_INSTALL([DEFAULT])
++# ----------------------------------
++# implement the --enable-fast-install flag, and support the `fast-install'
++# and `disable-fast-install' LT_INIT options.
++# DEFAULT is either `yes' or `no'.  If omitted, it defaults to `yes'.
++m4_define([_LT_ENABLE_FAST_INSTALL],
++[m4_define([_LT_ENABLE_FAST_INSTALL_DEFAULT], [m4_if($1, no, no, yes)])dnl
++AC_ARG_ENABLE([fast-install],
++    [AS_HELP_STRING([--enable-fast-install@<:@=PKGS@:>@],
++    [optimize for fast installation @<:@default=]_LT_ENABLE_FAST_INSTALL_DEFAULT[@:>@])],
++    [p=${PACKAGE-default}
++    case $enableval in
++    yes) enable_fast_install=yes ;;
++    no) enable_fast_install=no ;;
++    *)
++      enable_fast_install=no
++      # Look at the argument we got.  We use all the common list separators.
++      lt_save_ifs="$IFS"; IFS="${IFS}$PATH_SEPARATOR,"
++      for pkg in $enableval; do
++	IFS="$lt_save_ifs"
++	if test "X$pkg" = "X$p"; then
++	  enable_fast_install=yes
++	fi
++      done
++      IFS="$lt_save_ifs"
++      ;;
++    esac],
++    [enable_fast_install=]_LT_ENABLE_FAST_INSTALL_DEFAULT)
++
++_LT_DECL([fast_install], [enable_fast_install], [0],
++	 [Whether or not to optimize for fast installation])dnl
++])# _LT_ENABLE_FAST_INSTALL
++
++LT_OPTION_DEFINE([LT_INIT], [fast-install], [_LT_ENABLE_FAST_INSTALL([yes])])
++LT_OPTION_DEFINE([LT_INIT], [disable-fast-install], [_LT_ENABLE_FAST_INSTALL([no])])
++
++# Old names:
++AU_DEFUN([AC_ENABLE_FAST_INSTALL],
++[_LT_SET_OPTION([LT_INIT], m4_if([$1], [no], [disable-])[fast-install])
++AC_DIAGNOSE([obsolete],
++[$0: Remove this warning and the call to _LT_SET_OPTION when you put
++the `fast-install' option into LT_INIT's first parameter.])
++])
++
++AU_DEFUN([AC_DISABLE_FAST_INSTALL],
++[_LT_SET_OPTION([LT_INIT], [disable-fast-install])
++AC_DIAGNOSE([obsolete],
++[$0: Remove this warning and the call to _LT_SET_OPTION when you put
++the `disable-fast-install' option into LT_INIT's first parameter.])
++])
++
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AC_ENABLE_FAST_INSTALL], [])
++dnl AC_DEFUN([AM_DISABLE_FAST_INSTALL], [])
++
++
++# _LT_WITH_PIC([MODE])
++# --------------------
++# implement the --with-pic flag, and support the `pic-only' and `no-pic'
++# LT_INIT options.
++# MODE is either `yes' or `no'.  If omitted, it defaults to `both'.
++m4_define([_LT_WITH_PIC],
++[AC_ARG_WITH([pic],
++    [AS_HELP_STRING([--with-pic],
++	[try to use only PIC/non-PIC objects @<:@default=use both@:>@])],
++    [pic_mode="$withval"],
++    [pic_mode=default])
++
++test -z "$pic_mode" && pic_mode=m4_default([$1], [default])
++
++_LT_DECL([], [pic_mode], [0], [What type of objects to build])dnl
++])# _LT_WITH_PIC
++
++LT_OPTION_DEFINE([LT_INIT], [pic-only], [_LT_WITH_PIC([yes])])
++LT_OPTION_DEFINE([LT_INIT], [no-pic], [_LT_WITH_PIC([no])])
++
++# Old name:
++AU_DEFUN([AC_LIBTOOL_PICMODE],
++[_LT_SET_OPTION([LT_INIT], [pic-only])
++AC_DIAGNOSE([obsolete],
++[$0: Remove this warning and the call to _LT_SET_OPTION when you
++put the `pic-only' option into LT_INIT's first parameter.])
++])
++
++dnl aclocal-1.4 backwards compatibility:
++dnl AC_DEFUN([AC_LIBTOOL_PICMODE], [])
++
++## ----------------- ##
++## LTDL_INIT Options ##
++## ----------------- ##
++
++m4_define([_LTDL_MODE], [])
++LT_OPTION_DEFINE([LTDL_INIT], [nonrecursive],
++		 [m4_define([_LTDL_MODE], [nonrecursive])])
++LT_OPTION_DEFINE([LTDL_INIT], [recursive],
++		 [m4_define([_LTDL_MODE], [recursive])])
++LT_OPTION_DEFINE([LTDL_INIT], [subproject],
++		 [m4_define([_LTDL_MODE], [subproject])])
++
++m4_define([_LTDL_TYPE], [])
++LT_OPTION_DEFINE([LTDL_INIT], [installable],
++		 [m4_define([_LTDL_TYPE], [installable])])
++LT_OPTION_DEFINE([LTDL_INIT], [convenience],
++		 [m4_define([_LTDL_TYPE], [convenience])])
+Index: git/cf/ltsugar.m4
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/cf/ltsugar.m4	2010-12-29 04:06:56.362016566 +0100
+@@ -0,0 +1,123 @@
++# ltsugar.m4 -- libtool m4 base layer.                         -*-Autoconf-*-
++#
++# Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
++# Written by Gary V. Vaughan, 2004
++#
++# This file is free software; the Free Software Foundation gives
++# unlimited permission to copy and/or distribute it, with or without
++# modifications, as long as this notice is preserved.
++
++# serial 6 ltsugar.m4
++
++# This is to help aclocal find these macros, as it can't see m4_define.
++AC_DEFUN([LTSUGAR_VERSION], [m4_if([0.1])])
++
++
++# lt_join(SEP, ARG1, [ARG2...])
++# -----------------------------
++# Produce ARG1SEPARG2...SEPARGn, omitting [] arguments and their
++# associated separator.
++# Needed until we can rely on m4_join from Autoconf 2.62, since all earlier
++# versions in m4sugar had bugs.
++m4_define([lt_join],
++[m4_if([$#], [1], [],
++       [$#], [2], [[$2]],
++       [m4_if([$2], [], [], [[$2]_])$0([$1], m4_shift(m4_shift($@)))])])
++m4_define([_lt_join],
++[m4_if([$#$2], [2], [],
++       [m4_if([$2], [], [], [[$1$2]])$0([$1], m4_shift(m4_shift($@)))])])
++
++
++# lt_car(LIST)
++# lt_cdr(LIST)
++# ------------
++# Manipulate m4 lists.
++# These macros are necessary as long as will still need to support
++# Autoconf-2.59 which quotes differently.
++m4_define([lt_car], [[$1]])
++m4_define([lt_cdr],
++[m4_if([$#], 0, [m4_fatal([$0: cannot be called without arguments])],
++       [$#], 1, [],
++       [m4_dquote(m4_shift($@))])])
++m4_define([lt_unquote], $1)
++
++
++# lt_append(MACRO-NAME, STRING, [SEPARATOR])
++# ------------------------------------------
++# Redefine MACRO-NAME to hold its former content plus `SEPARATOR'`STRING'.
++# Note that neither SEPARATOR nor STRING are expanded; they are appended
++# to MACRO-NAME as is (leaving the expansion for when MACRO-NAME is invoked).
++# No SEPARATOR is output if MACRO-NAME was previously undefined (different
++# than defined and empty).
++#
++# This macro is needed until we can rely on Autoconf 2.62, since earlier
++# versions of m4sugar mistakenly expanded SEPARATOR but not STRING.
++m4_define([lt_append],
++[m4_define([$1],
++	   m4_ifdef([$1], [m4_defn([$1])[$3]])[$2])])
++
++
++
++# lt_combine(SEP, PREFIX-LIST, INFIX, SUFFIX1, [SUFFIX2...])
++# ----------------------------------------------------------
++# Produce a SEP delimited list of all paired combinations of elements of
++# PREFIX-LIST with SUFFIX1 through SUFFIXn.  Each element of the list
++# has the form PREFIXmINFIXSUFFIXn.
++# Needed until we can rely on m4_combine added in Autoconf 2.62.
++m4_define([lt_combine],
++[m4_if(m4_eval([$# > 3]), [1],
++       [m4_pushdef([_Lt_sep], [m4_define([_Lt_sep], m4_defn([lt_car]))])]]dnl
++[[m4_foreach([_Lt_prefix], [$2],
++	     [m4_foreach([_Lt_suffix],
++		]m4_dquote(m4_dquote(m4_shift(m4_shift(m4_shift($@)))))[,
++	[_Lt_sep([$1])[]m4_defn([_Lt_prefix])[$3]m4_defn([_Lt_suffix])])])])])
++
++
++# lt_if_append_uniq(MACRO-NAME, VARNAME, [SEPARATOR], [UNIQ], [NOT-UNIQ])
++# -----------------------------------------------------------------------
++# Iff MACRO-NAME does not yet contain VARNAME, then append it (delimited
++# by SEPARATOR if supplied) and expand UNIQ, else NOT-UNIQ.
++m4_define([lt_if_append_uniq],
++[m4_ifdef([$1],
++	  [m4_if(m4_index([$3]m4_defn([$1])[$3], [$3$2$3]), [-1],
++		 [lt_append([$1], [$2], [$3])$4],
++		 [$5])],
++	  [lt_append([$1], [$2], [$3])$4])])
++
++
++# lt_dict_add(DICT, KEY, VALUE)
++# -----------------------------
++m4_define([lt_dict_add],
++[m4_define([$1($2)], [$3])])
++
++
++# lt_dict_add_subkey(DICT, KEY, SUBKEY, VALUE)
++# --------------------------------------------
++m4_define([lt_dict_add_subkey],
++[m4_define([$1($2:$3)], [$4])])
++
++
++# lt_dict_fetch(DICT, KEY, [SUBKEY])
++# ----------------------------------
++m4_define([lt_dict_fetch],
++[m4_ifval([$3],
++	m4_ifdef([$1($2:$3)], [m4_defn([$1($2:$3)])]),
++    m4_ifdef([$1($2)], [m4_defn([$1($2)])]))])
++
++
++# lt_if_dict_fetch(DICT, KEY, [SUBKEY], VALUE, IF-TRUE, [IF-FALSE])
++# -----------------------------------------------------------------
++m4_define([lt_if_dict_fetch],
++[m4_if(lt_dict_fetch([$1], [$2], [$3]), [$4],
++	[$5],
++    [$6])])
++
++
++# lt_dict_filter(DICT, [SUBKEY], VALUE, [SEPARATOR], KEY, [...])
++# --------------------------------------------------------------
++m4_define([lt_dict_filter],
++[m4_if([$5], [], [],
++  [lt_join(m4_quote(m4_default([$4], [[, ]])),
++           lt_unquote(m4_split(m4_normalize(m4_foreach(_Lt_key, lt_car([m4_shiftn(4, $@)]),
++		      [lt_if_dict_fetch([$1], _Lt_key, [$2], [$3], [_Lt_key ])])))))])[]dnl
++])
+Index: git/cf/ltversion.m4
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/cf/ltversion.m4	2010-12-29 04:06:56.632102422 +0100
+@@ -0,0 +1,23 @@
++# ltversion.m4 -- version numbers			-*- Autoconf -*-
++#
++#   Copyright (C) 2004 Free Software Foundation, Inc.
++#   Written by Scott James Remnant, 2004
++#
++# This file is free software; the Free Software Foundation gives
++# unlimited permission to copy and/or distribute it, with or without
++# modifications, as long as this notice is preserved.
++
++# Generated from ltversion.in.
++
++# serial 3017 ltversion.m4
++# This file is part of GNU Libtool
++
++m4_define([LT_PACKAGE_VERSION], [2.2.6b])
++m4_define([LT_PACKAGE_REVISION], [1.3017])
++
++AC_DEFUN([LTVERSION_VERSION],
++[macro_version='2.2.6b'
++macro_revision='1.3017'
++_LT_DECL(, macro_version, 0, [Which release of libtool.m4 was used?])
++_LT_DECL(, macro_revision, 0)
++])
+Index: git/cf/lt~obsolete.m4
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/cf/lt~obsolete.m4	2010-12-29 04:06:56.892185100 +0100
+@@ -0,0 +1,92 @@
++# lt~obsolete.m4 -- aclocal satisfying obsolete definitions.    -*-Autoconf-*-
++#
++#   Copyright (C) 2004, 2005, 2007 Free Software Foundation, Inc.
++#   Written by Scott James Remnant, 2004.
++#
++# This file is free software; the Free Software Foundation gives
++# unlimited permission to copy and/or distribute it, with or without
++# modifications, as long as this notice is preserved.
++
++# serial 4 lt~obsolete.m4
++
++# These exist entirely to fool aclocal when bootstrapping libtool.
++#
++# In the past libtool.m4 has provided macros via AC_DEFUN (or AU_DEFUN)
++# which have later been changed to m4_define as they aren't part of the
++# exported API, or moved to Autoconf or Automake where they belong.
++#
++# The trouble is, aclocal is a bit thick.  It'll see the old AC_DEFUN
++# in /usr/share/aclocal/libtool.m4 and remember it, then when it sees us
++# using a macro with the same name in our local m4/libtool.m4 it'll
++# pull the old libtool.m4 in (it doesn't see our shiny new m4_define
++# and doesn't know about Autoconf macros at all.)
++#
++# So we provide this file, which has a silly filename so it's always
++# included after everything else.  This provides aclocal with the
++# AC_DEFUNs it wants, but when m4 processes it, it doesn't do anything
++# because those macros already exist, or will be overwritten later.
++# We use AC_DEFUN over AU_DEFUN for compatibility with aclocal-1.6. 
++#
++# Anytime we withdraw an AC_DEFUN or AU_DEFUN, remember to add it here.
++# Yes, that means every name once taken will need to remain here until
++# we give up compatibility with versions before 1.7, at which point
++# we need to keep only those names which we still refer to.
++
++# This is to help aclocal find these macros, as it can't see m4_define.
++AC_DEFUN([LTOBSOLETE_VERSION], [m4_if([1])])
++
++m4_ifndef([AC_LIBTOOL_LINKER_OPTION],	[AC_DEFUN([AC_LIBTOOL_LINKER_OPTION])])
++m4_ifndef([AC_PROG_EGREP],		[AC_DEFUN([AC_PROG_EGREP])])
++m4_ifndef([_LT_AC_PROG_ECHO_BACKSLASH],	[AC_DEFUN([_LT_AC_PROG_ECHO_BACKSLASH])])
++m4_ifndef([_LT_AC_SHELL_INIT],		[AC_DEFUN([_LT_AC_SHELL_INIT])])
++m4_ifndef([_LT_AC_SYS_LIBPATH_AIX],	[AC_DEFUN([_LT_AC_SYS_LIBPATH_AIX])])
++m4_ifndef([_LT_PROG_LTMAIN],		[AC_DEFUN([_LT_PROG_LTMAIN])])
++m4_ifndef([_LT_AC_TAGVAR],		[AC_DEFUN([_LT_AC_TAGVAR])])
++m4_ifndef([AC_LTDL_ENABLE_INSTALL],	[AC_DEFUN([AC_LTDL_ENABLE_INSTALL])])
++m4_ifndef([AC_LTDL_PREOPEN],		[AC_DEFUN([AC_LTDL_PREOPEN])])
++m4_ifndef([_LT_AC_SYS_COMPILER],	[AC_DEFUN([_LT_AC_SYS_COMPILER])])
++m4_ifndef([_LT_AC_LOCK],		[AC_DEFUN([_LT_AC_LOCK])])
++m4_ifndef([AC_LIBTOOL_SYS_OLD_ARCHIVE],	[AC_DEFUN([AC_LIBTOOL_SYS_OLD_ARCHIVE])])
++m4_ifndef([_LT_AC_TRY_DLOPEN_SELF],	[AC_DEFUN([_LT_AC_TRY_DLOPEN_SELF])])
++m4_ifndef([AC_LIBTOOL_PROG_CC_C_O],	[AC_DEFUN([AC_LIBTOOL_PROG_CC_C_O])])
++m4_ifndef([AC_LIBTOOL_SYS_HARD_LINK_LOCKS], [AC_DEFUN([AC_LIBTOOL_SYS_HARD_LINK_LOCKS])])
++m4_ifndef([AC_LIBTOOL_OBJDIR],		[AC_DEFUN([AC_LIBTOOL_OBJDIR])])
++m4_ifndef([AC_LTDL_OBJDIR],		[AC_DEFUN([AC_LTDL_OBJDIR])])
++m4_ifndef([AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH], [AC_DEFUN([AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH])])
++m4_ifndef([AC_LIBTOOL_SYS_LIB_STRIP],	[AC_DEFUN([AC_LIBTOOL_SYS_LIB_STRIP])])
++m4_ifndef([AC_PATH_MAGIC],		[AC_DEFUN([AC_PATH_MAGIC])])
++m4_ifndef([AC_PROG_LD_GNU],		[AC_DEFUN([AC_PROG_LD_GNU])])
++m4_ifndef([AC_PROG_LD_RELOAD_FLAG],	[AC_DEFUN([AC_PROG_LD_RELOAD_FLAG])])
++m4_ifndef([AC_DEPLIBS_CHECK_METHOD],	[AC_DEFUN([AC_DEPLIBS_CHECK_METHOD])])
++m4_ifndef([AC_LIBTOOL_PROG_COMPILER_NO_RTTI], [AC_DEFUN([AC_LIBTOOL_PROG_COMPILER_NO_RTTI])])
++m4_ifndef([AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE], [AC_DEFUN([AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE])])
++m4_ifndef([AC_LIBTOOL_PROG_COMPILER_PIC], [AC_DEFUN([AC_LIBTOOL_PROG_COMPILER_PIC])])
++m4_ifndef([AC_LIBTOOL_PROG_LD_SHLIBS],	[AC_DEFUN([AC_LIBTOOL_PROG_LD_SHLIBS])])
++m4_ifndef([AC_LIBTOOL_POSTDEP_PREDEP],	[AC_DEFUN([AC_LIBTOOL_POSTDEP_PREDEP])])
++m4_ifndef([LT_AC_PROG_EGREP],		[AC_DEFUN([LT_AC_PROG_EGREP])])
++m4_ifndef([LT_AC_PROG_SED],		[AC_DEFUN([LT_AC_PROG_SED])])
++m4_ifndef([_LT_CC_BASENAME],		[AC_DEFUN([_LT_CC_BASENAME])])
++m4_ifndef([_LT_COMPILER_BOILERPLATE],	[AC_DEFUN([_LT_COMPILER_BOILERPLATE])])
++m4_ifndef([_LT_LINKER_BOILERPLATE],	[AC_DEFUN([_LT_LINKER_BOILERPLATE])])
++m4_ifndef([_AC_PROG_LIBTOOL],		[AC_DEFUN([_AC_PROG_LIBTOOL])])
++m4_ifndef([AC_LIBTOOL_SETUP],		[AC_DEFUN([AC_LIBTOOL_SETUP])])
++m4_ifndef([_LT_AC_CHECK_DLFCN],		[AC_DEFUN([_LT_AC_CHECK_DLFCN])])
++m4_ifndef([AC_LIBTOOL_SYS_DYNAMIC_LINKER],	[AC_DEFUN([AC_LIBTOOL_SYS_DYNAMIC_LINKER])])
++m4_ifndef([_LT_AC_TAGCONFIG],		[AC_DEFUN([_LT_AC_TAGCONFIG])])
++m4_ifndef([AC_DISABLE_FAST_INSTALL],	[AC_DEFUN([AC_DISABLE_FAST_INSTALL])])
++m4_ifndef([_LT_AC_LANG_CXX],		[AC_DEFUN([_LT_AC_LANG_CXX])])
++m4_ifndef([_LT_AC_LANG_F77],		[AC_DEFUN([_LT_AC_LANG_F77])])
++m4_ifndef([_LT_AC_LANG_GCJ],		[AC_DEFUN([_LT_AC_LANG_GCJ])])
++m4_ifndef([AC_LIBTOOL_RC],		[AC_DEFUN([AC_LIBTOOL_RC])])
++m4_ifndef([AC_LIBTOOL_LANG_C_CONFIG],	[AC_DEFUN([AC_LIBTOOL_LANG_C_CONFIG])])
++m4_ifndef([_LT_AC_LANG_C_CONFIG],	[AC_DEFUN([_LT_AC_LANG_C_CONFIG])])
++m4_ifndef([AC_LIBTOOL_LANG_CXX_CONFIG],	[AC_DEFUN([AC_LIBTOOL_LANG_CXX_CONFIG])])
++m4_ifndef([_LT_AC_LANG_CXX_CONFIG],	[AC_DEFUN([_LT_AC_LANG_CXX_CONFIG])])
++m4_ifndef([AC_LIBTOOL_LANG_F77_CONFIG],	[AC_DEFUN([AC_LIBTOOL_LANG_F77_CONFIG])])
++m4_ifndef([_LT_AC_LANG_F77_CONFIG],	[AC_DEFUN([_LT_AC_LANG_F77_CONFIG])])
++m4_ifndef([AC_LIBTOOL_LANG_GCJ_CONFIG],	[AC_DEFUN([AC_LIBTOOL_LANG_GCJ_CONFIG])])
++m4_ifndef([_LT_AC_LANG_GCJ_CONFIG],	[AC_DEFUN([_LT_AC_LANG_GCJ_CONFIG])])
++m4_ifndef([AC_LIBTOOL_LANG_RC_CONFIG],	[AC_DEFUN([AC_LIBTOOL_LANG_RC_CONFIG])])
++m4_ifndef([_LT_AC_LANG_RC_CONFIG],	[AC_DEFUN([_LT_AC_LANG_RC_CONFIG])])
++m4_ifndef([AC_LIBTOOL_CONFIG],		[AC_DEFUN([AC_LIBTOOL_CONFIG])])
++m4_ifndef([_LT_AC_FILE_LTDLL_C],	[AC_DEFUN([_LT_AC_FILE_LTDLL_C])])
+Index: git/compile
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/compile	2010-12-29 04:04:06.000000000 +0100
+@@ -0,0 +1,143 @@
++#! /bin/sh
++# Wrapper for compilers which do not understand `-c -o'.
++
++scriptversion=2009-10-06.20; # UTC
++
++# Copyright (C) 1999, 2000, 2003, 2004, 2005, 2009  Free Software
++# Foundation, Inc.
++# Written by Tom Tromey <tromey@cygnus.com>.
++#
++# This program is free software; you can redistribute it and/or modify
++# it under the terms of the GNU General Public License as published by
++# the Free Software Foundation; either version 2, or (at your option)
++# any later version.
++#
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY; without even the implied warranty of
++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++# GNU General Public License for more details.
++#
++# You should have received a copy of the GNU General Public License
++# along with this program.  If not, see <http://www.gnu.org/licenses/>.
++
++# As a special exception to the GNU General Public License, if you
++# distribute this file as part of a program that contains a
++# configuration script generated by Autoconf, you may include it under
++# the same distribution terms that you use for the rest of that program.
++
++# This file is maintained in Automake, please report
++# bugs to <bug-automake@gnu.org> or send patches to
++# <automake-patches@gnu.org>.
++
++case $1 in
++  '')
++     echo "$0: No command.  Try \`$0 --help' for more information." 1>&2
++     exit 1;
++     ;;
++  -h | --h*)
++    cat <<\EOF
++Usage: compile [--help] [--version] PROGRAM [ARGS]
++
++Wrapper for compilers which do not understand `-c -o'.
++Remove `-o dest.o' from ARGS, run PROGRAM with the remaining
++arguments, and rename the output as expected.
++
++If you are trying to build a whole package this is not the
++right script to run: please start by reading the file `INSTALL'.
++
++Report bugs to <bug-automake@gnu.org>.
++EOF
++    exit $?
++    ;;
++  -v | --v*)
++    echo "compile $scriptversion"
++    exit $?
++    ;;
++esac
++
++ofile=
++cfile=
++eat=
++
++for arg
++do
++  if test -n "$eat"; then
++    eat=
++  else
++    case $1 in
++      -o)
++	# configure might choose to run compile as `compile cc -o foo foo.c'.
++	# So we strip `-o arg' only if arg is an object.
++	eat=1
++	case $2 in
++	  *.o | *.obj)
++	    ofile=$2
++	    ;;
++	  *)
++	    set x "$@" -o "$2"
++	    shift
++	    ;;
++	esac
++	;;
++      *.c)
++	cfile=$1
++	set x "$@" "$1"
++	shift
++	;;
++      *)
++	set x "$@" "$1"
++	shift
++	;;
++    esac
++  fi
++  shift
++done
++
++if test -z "$ofile" || test -z "$cfile"; then
++  # If no `-o' option was seen then we might have been invoked from a
++  # pattern rule where we don't need one.  That is ok -- this is a
++  # normal compilation that the losing compiler can handle.  If no
++  # `.c' file was seen then we are probably linking.  That is also
++  # ok.
++  exec "$@"
++fi
++
++# Name of file we expect compiler to create.
++cofile=`echo "$cfile" | sed 's|^.*[\\/]||; s|^[a-zA-Z]:||; s/\.c$/.o/'`
++
++# Create the lock directory.
++# Note: use `[/\\:.-]' here to ensure that we don't use the same name
++# that we are using for the .o file.  Also, base the name on the expected
++# object file name, since that is what matters with a parallel build.
++lockdir=`echo "$cofile" | sed -e 's|[/\\:.-]|_|g'`.d
++while true; do
++  if mkdir "$lockdir" >/dev/null 2>&1; then
++    break
++  fi
++  sleep 1
++done
++# FIXME: race condition here if user kills between mkdir and trap.
++trap "rmdir '$lockdir'; exit 1" 1 2 15
++
++# Run the compile.
++"$@"
++ret=$?
++
++if test -f "$cofile"; then
++  test "$cofile" = "$ofile" || mv "$cofile" "$ofile"
++elif test -f "${cofile}bj"; then
++  test "${cofile}bj" = "$ofile" || mv "${cofile}bj" "$ofile"
++fi
++
++rmdir "$lockdir"
++exit $ret
++
++# Local Variables:
++# mode: shell-script
++# sh-indentation: 2
++# eval: (add-hook 'write-file-hooks 'time-stamp)
++# time-stamp-start: "scriptversion="
++# time-stamp-format: "%:y-%02m-%02d.%02H"
++# time-stamp-time-zone: "UTC"
++# time-stamp-end: "; # UTC"
++# End:
+Index: git/config.guess
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/config.guess	2010-12-29 04:04:06.000000000 +0100
+@@ -0,0 +1,1502 @@
++#! /bin/sh
++# Attempt to guess a canonical system name.
++#   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
++#   2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
++#   Free Software Foundation, Inc.
++
++timestamp='2009-12-30'
++
++# This file is free software; you can redistribute it and/or modify it
++# under the terms of the GNU General Public License as published by
++# the Free Software Foundation; either version 2 of the License, or
++# (at your option) any later version.
++#
++# This program is distributed in the hope that it will be useful, but
++# WITHOUT ANY WARRANTY; without even the implied warranty of
++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
++# General Public License for more details.
++#
++# You should have received a copy of the GNU General Public License
++# along with this program; if not, write to the Free Software
++# Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA
++# 02110-1301, USA.
++#
++# As a special exception to the GNU General Public License, if you
++# distribute this file as part of a program that contains a
++# configuration script generated by Autoconf, you may include it under
++# the same distribution terms that you use for the rest of that program.
++
++
++# Originally written by Per Bothner.  Please send patches (context
++# diff format) to <config-patches@gnu.org> and include a ChangeLog
++# entry.
++#
++# This script attempts to guess a canonical system name similar to
++# config.sub.  If it succeeds, it prints the system name on stdout, and
++# exits with 0.  Otherwise, it exits with 1.
++#
++# You can get the latest version of this script from:
++# http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
++
++me=`echo "$0" | sed -e 's,.*/,,'`
++
++usage="\
++Usage: $0 [OPTION]
++
++Output the configuration name of the system \`$me' is run on.
++
++Operation modes:
++  -h, --help         print this help, then exit
++  -t, --time-stamp   print date of last modification, then exit
++  -v, --version      print version number, then exit
++
++Report bugs and patches to <config-patches@gnu.org>."
++
++version="\
++GNU config.guess ($timestamp)
++
++Originally written by Per Bothner.
++Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
++2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free
++Software Foundation, Inc.
++
++This is free software; see the source for copying conditions.  There is NO
++warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
++
++help="
++Try \`$me --help' for more information."
++
++# Parse command line
++while test $# -gt 0 ; do
++  case $1 in
++    --time-stamp | --time* | -t )
++       echo "$timestamp" ; exit ;;
++    --version | -v )
++       echo "$version" ; exit ;;
++    --help | --h* | -h )
++       echo "$usage"; exit ;;
++    -- )     # Stop option processing
++       shift; break ;;
++    - )	# Use stdin as input.
++       break ;;
++    -* )
++       echo "$me: invalid option $1$help" >&2
++       exit 1 ;;
++    * )
++       break ;;
++  esac
++done
++
++if test $# != 0; then
++  echo "$me: too many arguments$help" >&2
++  exit 1
++fi
++
++trap 'exit 1' 1 2 15
++
++# CC_FOR_BUILD -- compiler used by this script. Note that the use of a
++# compiler to aid in system detection is discouraged as it requires
++# temporary files to be created and, as you can see below, it is a
++# headache to deal with in a portable fashion.
++
++# Historically, `CC_FOR_BUILD' used to be named `HOST_CC'. We still
++# use `HOST_CC' if defined, but it is deprecated.
++
++# Portable tmp directory creation inspired by the Autoconf team.
++
++set_cc_for_build='
++trap "exitcode=\$?; (rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null) && exit \$exitcode" 0 ;
++trap "rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null; exit 1" 1 2 13 15 ;
++: ${TMPDIR=/tmp} ;
++ { tmp=`(umask 077 && mktemp -d "$TMPDIR/cgXXXXXX") 2>/dev/null` && test -n "$tmp" && test -d "$tmp" ; } ||
++ { test -n "$RANDOM" && tmp=$TMPDIR/cg$$-$RANDOM && (umask 077 && mkdir $tmp) ; } ||
++ { tmp=$TMPDIR/cg-$$ && (umask 077 && mkdir $tmp) && echo "Warning: creating insecure temp directory" >&2 ; } ||
++ { echo "$me: cannot create a temporary directory in $TMPDIR" >&2 ; exit 1 ; } ;
++dummy=$tmp/dummy ;
++tmpfiles="$dummy.c $dummy.o $dummy.rel $dummy" ;
++case $CC_FOR_BUILD,$HOST_CC,$CC in
++ ,,)    echo "int x;" > $dummy.c ;
++	for c in cc gcc c89 c99 ; do
++	  if ($c -c -o $dummy.o $dummy.c) >/dev/null 2>&1 ; then
++	     CC_FOR_BUILD="$c"; break ;
++	  fi ;
++	done ;
++	if test x"$CC_FOR_BUILD" = x ; then
++	  CC_FOR_BUILD=no_compiler_found ;
++	fi
++	;;
++ ,,*)   CC_FOR_BUILD=$CC ;;
++ ,*,*)  CC_FOR_BUILD=$HOST_CC ;;
++esac ; set_cc_for_build= ;'
++
++# This is needed to find uname on a Pyramid OSx when run in the BSD universe.
++# (ghazi@noc.rutgers.edu 1994-08-24)
++if (test -f /.attbin/uname) >/dev/null 2>&1 ; then
++	PATH=$PATH:/.attbin ; export PATH
++fi
++
++UNAME_MACHINE=`(uname -m) 2>/dev/null` || UNAME_MACHINE=unknown
++UNAME_RELEASE=`(uname -r) 2>/dev/null` || UNAME_RELEASE=unknown
++UNAME_SYSTEM=`(uname -s) 2>/dev/null`  || UNAME_SYSTEM=unknown
++UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown
++
++# Note: order is significant - the case branches are not exclusive.
++
++case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
++    *:NetBSD:*:*)
++	# NetBSD (nbsd) targets should (where applicable) match one or
++	# more of the tupples: *-*-netbsdelf*, *-*-netbsdaout*,
++	# *-*-netbsdecoff* and *-*-netbsd*.  For targets that recently
++	# switched to ELF, *-*-netbsd* would select the old
++	# object file format.  This provides both forward
++	# compatibility and a consistent mechanism for selecting the
++	# object file format.
++	#
++	# Note: NetBSD doesn't particularly care about the vendor
++	# portion of the name.  We always set it to "unknown".
++	sysctl="sysctl -n hw.machine_arch"
++	UNAME_MACHINE_ARCH=`(/sbin/$sysctl 2>/dev/null || \
++	    /usr/sbin/$sysctl 2>/dev/null || echo unknown)`
++	case "${UNAME_MACHINE_ARCH}" in
++	    armeb) machine=armeb-unknown ;;
++	    arm*) machine=arm-unknown ;;
++	    sh3el) machine=shl-unknown ;;
++	    sh3eb) machine=sh-unknown ;;
++	    sh5el) machine=sh5le-unknown ;;
++	    *) machine=${UNAME_MACHINE_ARCH}-unknown ;;
++	esac
++	# The Operating System including object format, if it has switched
++	# to ELF recently, or will in the future.
++	case "${UNAME_MACHINE_ARCH}" in
++	    arm*|i386|m68k|ns32k|sh3*|sparc|vax)
++		eval $set_cc_for_build
++		if echo __ELF__ | $CC_FOR_BUILD -E - 2>/dev/null \
++			| grep -q __ELF__
++		then
++		    # Once all utilities can be ECOFF (netbsdecoff) or a.out (netbsdaout).
++		    # Return netbsd for either.  FIX?
++		    os=netbsd
++		else
++		    os=netbsdelf
++		fi
++		;;
++	    *)
++	        os=netbsd
++		;;
++	esac
++	# The OS release
++	# Debian GNU/NetBSD machines have a different userland, and
++	# thus, need a distinct triplet. However, they do not need
++	# kernel version information, so it can be replaced with a
++	# suitable tag, in the style of linux-gnu.
++	case "${UNAME_VERSION}" in
++	    Debian*)
++		release='-gnu'
++		;;
++	    *)
++		release=`echo ${UNAME_RELEASE}|sed -e 's/[-_].*/\./'`
++		;;
++	esac
++	# Since CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM:
++	# contains redundant information, the shorter form:
++	# CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM is used.
++	echo "${machine}-${os}${release}"
++	exit ;;
++    *:OpenBSD:*:*)
++	UNAME_MACHINE_ARCH=`arch | sed 's/OpenBSD.//'`
++	echo ${UNAME_MACHINE_ARCH}-unknown-openbsd${UNAME_RELEASE}
++	exit ;;
++    *:ekkoBSD:*:*)
++	echo ${UNAME_MACHINE}-unknown-ekkobsd${UNAME_RELEASE}
++	exit ;;
++    *:SolidBSD:*:*)
++	echo ${UNAME_MACHINE}-unknown-solidbsd${UNAME_RELEASE}
++	exit ;;
++    macppc:MirBSD:*:*)
++	echo powerpc-unknown-mirbsd${UNAME_RELEASE}
++	exit ;;
++    *:MirBSD:*:*)
++	echo ${UNAME_MACHINE}-unknown-mirbsd${UNAME_RELEASE}
++	exit ;;
++    alpha:OSF1:*:*)
++	case $UNAME_RELEASE in
++	*4.0)
++		UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $3}'`
++		;;
++	*5.*)
++	        UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $4}'`
++		;;
++	esac
++	# According to Compaq, /usr/sbin/psrinfo has been available on
++	# OSF/1 and Tru64 systems produced since 1995.  I hope that
++	# covers most systems running today.  This code pipes the CPU
++	# types through head -n 1, so we only detect the type of CPU 0.
++	ALPHA_CPU_TYPE=`/usr/sbin/psrinfo -v | sed -n -e 's/^  The alpha \(.*\) processor.*$/\1/p' | head -n 1`
++	case "$ALPHA_CPU_TYPE" in
++	    "EV4 (21064)")
++		UNAME_MACHINE="alpha" ;;
++	    "EV4.5 (21064)")
++		UNAME_MACHINE="alpha" ;;
++	    "LCA4 (21066/21068)")
++		UNAME_MACHINE="alpha" ;;
++	    "EV5 (21164)")
++		UNAME_MACHINE="alphaev5" ;;
++	    "EV5.6 (21164A)")
++		UNAME_MACHINE="alphaev56" ;;
++	    "EV5.6 (21164PC)")
++		UNAME_MACHINE="alphapca56" ;;
++	    "EV5.7 (21164PC)")
++		UNAME_MACHINE="alphapca57" ;;
++	    "EV6 (21264)")
++		UNAME_MACHINE="alphaev6" ;;
++	    "EV6.7 (21264A)")
++		UNAME_MACHINE="alphaev67" ;;
++	    "EV6.8CB (21264C)")
++		UNAME_MACHINE="alphaev68" ;;
++	    "EV6.8AL (21264B)")
++		UNAME_MACHINE="alphaev68" ;;
++	    "EV6.8CX (21264D)")
++		UNAME_MACHINE="alphaev68" ;;
++	    "EV6.9A (21264/EV69A)")
++		UNAME_MACHINE="alphaev69" ;;
++	    "EV7 (21364)")
++		UNAME_MACHINE="alphaev7" ;;
++	    "EV7.9 (21364A)")
++		UNAME_MACHINE="alphaev79" ;;
++	esac
++	# A Pn.n version is a patched version.
++	# A Vn.n version is a released version.
++	# A Tn.n version is a released field test version.
++	# A Xn.n version is an unreleased experimental baselevel.
++	# 1.2 uses "1.2" for uname -r.
++	echo ${UNAME_MACHINE}-dec-osf`echo ${UNAME_RELEASE} | sed -e 's/^[PVTX]//' | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'`
++	exit ;;
++    Alpha\ *:Windows_NT*:*)
++	# How do we know it's Interix rather than the generic POSIX subsystem?
++	# Should we change UNAME_MACHINE based on the output of uname instead
++	# of the specific Alpha model?
++	echo alpha-pc-interix
++	exit ;;
++    21064:Windows_NT:50:3)
++	echo alpha-dec-winnt3.5
++	exit ;;
++    Amiga*:UNIX_System_V:4.0:*)
++	echo m68k-unknown-sysv4
++	exit ;;
++    *:[Aa]miga[Oo][Ss]:*:*)
++	echo ${UNAME_MACHINE}-unknown-amigaos
++	exit ;;
++    *:[Mm]orph[Oo][Ss]:*:*)
++	echo ${UNAME_MACHINE}-unknown-morphos
++	exit ;;
++    *:OS/390:*:*)
++	echo i370-ibm-openedition
++	exit ;;
++    *:z/VM:*:*)
++	echo s390-ibm-zvmoe
++	exit ;;
++    *:OS400:*:*)
++        echo powerpc-ibm-os400
++	exit ;;
++    arm:RISC*:1.[012]*:*|arm:riscix:1.[012]*:*)
++	echo arm-acorn-riscix${UNAME_RELEASE}
++	exit ;;
++    arm:riscos:*:*|arm:RISCOS:*:*)
++	echo arm-unknown-riscos
++	exit ;;
++    SR2?01:HI-UX/MPP:*:* | SR8000:HI-UX/MPP:*:*)
++	echo hppa1.1-hitachi-hiuxmpp
++	exit ;;
++    Pyramid*:OSx*:*:* | MIS*:OSx*:*:* | MIS*:SMP_DC-OSx*:*:*)
++	# akee@wpdis03.wpafb.af.mil (Earle F. Ake) contributed MIS and NILE.
++	if test "`(/bin/universe) 2>/dev/null`" = att ; then
++		echo pyramid-pyramid-sysv3
++	else
++		echo pyramid-pyramid-bsd
++	fi
++	exit ;;
++    NILE*:*:*:dcosx)
++	echo pyramid-pyramid-svr4
++	exit ;;
++    DRS?6000:unix:4.0:6*)
++	echo sparc-icl-nx6
++	exit ;;
++    DRS?6000:UNIX_SV:4.2*:7* | DRS?6000:isis:4.2*:7*)
++	case `/usr/bin/uname -p` in
++	    sparc) echo sparc-icl-nx7; exit ;;
++	esac ;;
++    s390x:SunOS:*:*)
++	echo ${UNAME_MACHINE}-ibm-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
++	exit ;;
++    sun4H:SunOS:5.*:*)
++	echo sparc-hal-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
++	exit ;;
++    sun4*:SunOS:5.*:* | tadpole*:SunOS:5.*:*)
++	echo sparc-sun-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
++	exit ;;
++    i86pc:AuroraUX:5.*:* | i86xen:AuroraUX:5.*:*)
++	echo i386-pc-auroraux${UNAME_RELEASE}
++	exit ;;
++    i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*)
++	eval $set_cc_for_build
++	SUN_ARCH="i386"
++	# If there is a compiler, see if it is configured for 64-bit objects.
++	# Note that the Sun cc does not turn __LP64__ into 1 like gcc does.
++	# This test works for both compilers.
++	if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then
++	    if (echo '#ifdef __amd64'; echo IS_64BIT_ARCH; echo '#endif') | \
++		(CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \
++		grep IS_64BIT_ARCH >/dev/null
++	    then
++		SUN_ARCH="x86_64"
++	    fi
++	fi
++	echo ${SUN_ARCH}-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
++	exit ;;
++    sun4*:SunOS:6*:*)
++	# According to config.sub, this is the proper way to canonicalize
++	# SunOS6.  Hard to guess exactly what SunOS6 will be like, but
++	# it's likely to be more like Solaris than SunOS4.
++	echo sparc-sun-solaris3`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
++	exit ;;
++    sun4*:SunOS:*:*)
++	case "`/usr/bin/arch -k`" in
++	    Series*|S4*)
++		UNAME_RELEASE=`uname -v`
++		;;
++	esac
++	# Japanese Language versions have a version number like `4.1.3-JL'.
++	echo sparc-sun-sunos`echo ${UNAME_RELEASE}|sed -e 's/-/_/'`
++	exit ;;
++    sun3*:SunOS:*:*)
++	echo m68k-sun-sunos${UNAME_RELEASE}
++	exit ;;
++    sun*:*:4.2BSD:*)
++	UNAME_RELEASE=`(sed 1q /etc/motd | awk '{print substr($5,1,3)}') 2>/dev/null`
++	test "x${UNAME_RELEASE}" = "x" && UNAME_RELEASE=3
++	case "`/bin/arch`" in
++	    sun3)
++		echo m68k-sun-sunos${UNAME_RELEASE}
++		;;
++	    sun4)
++		echo sparc-sun-sunos${UNAME_RELEASE}
++		;;
++	esac
++	exit ;;
++    aushp:SunOS:*:*)
++	echo sparc-auspex-sunos${UNAME_RELEASE}
++	exit ;;
++    # The situation for MiNT is a little confusing.  The machine name
++    # can be virtually everything (everything which is not
++    # "atarist" or "atariste" at least should have a processor
++    # > m68000).  The system name ranges from "MiNT" over "FreeMiNT"
++    # to the lowercase version "mint" (or "freemint").  Finally
++    # the system name "TOS" denotes a system which is actually not
++    # MiNT.  But MiNT is downward compatible to TOS, so this should
++    # be no problem.
++    atarist[e]:*MiNT:*:* | atarist[e]:*mint:*:* | atarist[e]:*TOS:*:*)
++        echo m68k-atari-mint${UNAME_RELEASE}
++	exit ;;
++    atari*:*MiNT:*:* | atari*:*mint:*:* | atarist[e]:*TOS:*:*)
++	echo m68k-atari-mint${UNAME_RELEASE}
++        exit ;;
++    *falcon*:*MiNT:*:* | *falcon*:*mint:*:* | *falcon*:*TOS:*:*)
++        echo m68k-atari-mint${UNAME_RELEASE}
++	exit ;;
++    milan*:*MiNT:*:* | milan*:*mint:*:* | *milan*:*TOS:*:*)
++        echo m68k-milan-mint${UNAME_RELEASE}
++        exit ;;
++    hades*:*MiNT:*:* | hades*:*mint:*:* | *hades*:*TOS:*:*)
++        echo m68k-hades-mint${UNAME_RELEASE}
++        exit ;;
++    *:*MiNT:*:* | *:*mint:*:* | *:*TOS:*:*)
++        echo m68k-unknown-mint${UNAME_RELEASE}
++        exit ;;
++    m68k:machten:*:*)
++	echo m68k-apple-machten${UNAME_RELEASE}
++	exit ;;
++    powerpc:machten:*:*)
++	echo powerpc-apple-machten${UNAME_RELEASE}
++	exit ;;
++    RISC*:Mach:*:*)
++	echo mips-dec-mach_bsd4.3
++	exit ;;
++    RISC*:ULTRIX:*:*)
++	echo mips-dec-ultrix${UNAME_RELEASE}
++	exit ;;
++    VAX*:ULTRIX*:*:*)
++	echo vax-dec-ultrix${UNAME_RELEASE}
++	exit ;;
++    2020:CLIX:*:* | 2430:CLIX:*:*)
++	echo clipper-intergraph-clix${UNAME_RELEASE}
++	exit ;;
++    mips:*:*:UMIPS | mips:*:*:RISCos)
++	eval $set_cc_for_build
++	sed 's/^	//' << EOF >$dummy.c
++#ifdef __cplusplus
++#include <stdio.h>  /* for printf() prototype */
++	int main (int argc, char *argv[]) {
++#else
++	int main (argc, argv) int argc; char *argv[]; {
++#endif
++	#if defined (host_mips) && defined (MIPSEB)
++	#if defined (SYSTYPE_SYSV)
++	  printf ("mips-mips-riscos%ssysv\n", argv[1]); exit (0);
++	#endif
++	#if defined (SYSTYPE_SVR4)
++	  printf ("mips-mips-riscos%ssvr4\n", argv[1]); exit (0);
++	#endif
++	#if defined (SYSTYPE_BSD43) || defined(SYSTYPE_BSD)
++	  printf ("mips-mips-riscos%sbsd\n", argv[1]); exit (0);
++	#endif
++	#endif
++	  exit (-1);
++	}
++EOF
++	$CC_FOR_BUILD -o $dummy $dummy.c &&
++	  dummyarg=`echo "${UNAME_RELEASE}" | sed -n 's/\([0-9]*\).*/\1/p'` &&
++	  SYSTEM_NAME=`$dummy $dummyarg` &&
++	    { echo "$SYSTEM_NAME"; exit; }
++	echo mips-mips-riscos${UNAME_RELEASE}
++	exit ;;
++    Motorola:PowerMAX_OS:*:*)
++	echo powerpc-motorola-powermax
++	exit ;;
++    Motorola:*:4.3:PL8-*)
++	echo powerpc-harris-powermax
++	exit ;;
++    Night_Hawk:*:*:PowerMAX_OS | Synergy:PowerMAX_OS:*:*)
++	echo powerpc-harris-powermax
++	exit ;;
++    Night_Hawk:Power_UNIX:*:*)
++	echo powerpc-harris-powerunix
++	exit ;;
++    m88k:CX/UX:7*:*)
++	echo m88k-harris-cxux7
++	exit ;;
++    m88k:*:4*:R4*)
++	echo m88k-motorola-sysv4
++	exit ;;
++    m88k:*:3*:R3*)
++	echo m88k-motorola-sysv3
++	exit ;;
++    AViiON:dgux:*:*)
++        # DG/UX returns AViiON for all architectures
++        UNAME_PROCESSOR=`/usr/bin/uname -p`
++	if [ $UNAME_PROCESSOR = mc88100 ] || [ $UNAME_PROCESSOR = mc88110 ]
++	then
++	    if [ ${TARGET_BINARY_INTERFACE}x = m88kdguxelfx ] || \
++	       [ ${TARGET_BINARY_INTERFACE}x = x ]
++	    then
++		echo m88k-dg-dgux${UNAME_RELEASE}
++	    else
++		echo m88k-dg-dguxbcs${UNAME_RELEASE}
++	    fi
++	else
++	    echo i586-dg-dgux${UNAME_RELEASE}
++	fi
++ 	exit ;;
++    M88*:DolphinOS:*:*)	# DolphinOS (SVR3)
++	echo m88k-dolphin-sysv3
++	exit ;;
++    M88*:*:R3*:*)
++	# Delta 88k system running SVR3
++	echo m88k-motorola-sysv3
++	exit ;;
++    XD88*:*:*:*) # Tektronix XD88 system running UTekV (SVR3)
++	echo m88k-tektronix-sysv3
++	exit ;;
++    Tek43[0-9][0-9]:UTek:*:*) # Tektronix 4300 system running UTek (BSD)
++	echo m68k-tektronix-bsd
++	exit ;;
++    *:IRIX*:*:*)
++	echo mips-sgi-irix`echo ${UNAME_RELEASE}|sed -e 's/-/_/g'`
++	exit ;;
++    ????????:AIX?:[12].1:2)   # AIX 2.2.1 or AIX 2.1.1 is RT/PC AIX.
++	echo romp-ibm-aix     # uname -m gives an 8 hex-code CPU id
++	exit ;;               # Note that: echo "'`uname -s`'" gives 'AIX '
++    i*86:AIX:*:*)
++	echo i386-ibm-aix
++	exit ;;
++    ia64:AIX:*:*)
++	if [ -x /usr/bin/oslevel ] ; then
++		IBM_REV=`/usr/bin/oslevel`
++	else
++		IBM_REV=${UNAME_VERSION}.${UNAME_RELEASE}
++	fi
++	echo ${UNAME_MACHINE}-ibm-aix${IBM_REV}
++	exit ;;
++    *:AIX:2:3)
++	if grep bos325 /usr/include/stdio.h >/dev/null 2>&1; then
++		eval $set_cc_for_build
++		sed 's/^		//' << EOF >$dummy.c
++		#include <sys/systemcfg.h>
++
++		main()
++			{
++			if (!__power_pc())
++				exit(1);
++			puts("powerpc-ibm-aix3.2.5");
++			exit(0);
++			}
++EOF
++		if $CC_FOR_BUILD -o $dummy $dummy.c && SYSTEM_NAME=`$dummy`
++		then
++			echo "$SYSTEM_NAME"
++		else
++			echo rs6000-ibm-aix3.2.5
++		fi
++	elif grep bos324 /usr/include/stdio.h >/dev/null 2>&1; then
++		echo rs6000-ibm-aix3.2.4
++	else
++		echo rs6000-ibm-aix3.2
++	fi
++	exit ;;
++    *:AIX:*:[456])
++	IBM_CPU_ID=`/usr/sbin/lsdev -C -c processor -S available | sed 1q | awk '{ print $1 }'`
++	if /usr/sbin/lsattr -El ${IBM_CPU_ID} | grep ' POWER' >/dev/null 2>&1; then
++		IBM_ARCH=rs6000
++	else
++		IBM_ARCH=powerpc
++	fi
++	if [ -x /usr/bin/oslevel ] ; then
++		IBM_REV=`/usr/bin/oslevel`
++	else
++		IBM_REV=${UNAME_VERSION}.${UNAME_RELEASE}
++	fi
++	echo ${IBM_ARCH}-ibm-aix${IBM_REV}
++	exit ;;
++    *:AIX:*:*)
++	echo rs6000-ibm-aix
++	exit ;;
++    ibmrt:4.4BSD:*|romp-ibm:BSD:*)
++	echo romp-ibm-bsd4.4
++	exit ;;
++    ibmrt:*BSD:*|romp-ibm:BSD:*)            # covers RT/PC BSD and
++	echo romp-ibm-bsd${UNAME_RELEASE}   # 4.3 with uname added to
++	exit ;;                             # report: romp-ibm BSD 4.3
++    *:BOSX:*:*)
++	echo rs6000-bull-bosx
++	exit ;;
++    DPX/2?00:B.O.S.:*:*)
++	echo m68k-bull-sysv3
++	exit ;;
++    9000/[34]??:4.3bsd:1.*:*)
++	echo m68k-hp-bsd
++	exit ;;
++    hp300:4.4BSD:*:* | 9000/[34]??:4.3bsd:2.*:*)
++	echo m68k-hp-bsd4.4
++	exit ;;
++    9000/[34678]??:HP-UX:*:*)
++	HPUX_REV=`echo ${UNAME_RELEASE}|sed -e 's/[^.]*.[0B]*//'`
++	case "${UNAME_MACHINE}" in
++	    9000/31? )            HP_ARCH=m68000 ;;
++	    9000/[34]?? )         HP_ARCH=m68k ;;
++	    9000/[678][0-9][0-9])
++		if [ -x /usr/bin/getconf ]; then
++		    sc_cpu_version=`/usr/bin/getconf SC_CPU_VERSION 2>/dev/null`
++                    sc_kernel_bits=`/usr/bin/getconf SC_KERNEL_BITS 2>/dev/null`
++                    case "${sc_cpu_version}" in
++                      523) HP_ARCH="hppa1.0" ;; # CPU_PA_RISC1_0
++                      528) HP_ARCH="hppa1.1" ;; # CPU_PA_RISC1_1
++                      532)                      # CPU_PA_RISC2_0
++                        case "${sc_kernel_bits}" in
++                          32) HP_ARCH="hppa2.0n" ;;
++                          64) HP_ARCH="hppa2.0w" ;;
++			  '') HP_ARCH="hppa2.0" ;;   # HP-UX 10.20
++                        esac ;;
++                    esac
++		fi
++		if [ "${HP_ARCH}" = "" ]; then
++		    eval $set_cc_for_build
++		    sed 's/^              //' << EOF >$dummy.c
++
++              #define _HPUX_SOURCE
++              #include <stdlib.h>
++              #include <unistd.h>
++
++              int main ()
++              {
++              #if defined(_SC_KERNEL_BITS)
++                  long bits = sysconf(_SC_KERNEL_BITS);
++              #endif
++                  long cpu  = sysconf (_SC_CPU_VERSION);
++
++                  switch (cpu)
++              	{
++              	case CPU_PA_RISC1_0: puts ("hppa1.0"); break;
++              	case CPU_PA_RISC1_1: puts ("hppa1.1"); break;
++              	case CPU_PA_RISC2_0:
++              #if defined(_SC_KERNEL_BITS)
++              	    switch (bits)
++              		{
++              		case 64: puts ("hppa2.0w"); break;
++              		case 32: puts ("hppa2.0n"); break;
++              		default: puts ("hppa2.0"); break;
++              		} break;
++              #else  /* !defined(_SC_KERNEL_BITS) */
++              	    puts ("hppa2.0"); break;
++              #endif
++              	default: puts ("hppa1.0"); break;
++              	}
++                  exit (0);
++              }
++EOF
++		    (CCOPTS= $CC_FOR_BUILD -o $dummy $dummy.c 2>/dev/null) && HP_ARCH=`$dummy`
++		    test -z "$HP_ARCH" && HP_ARCH=hppa
++		fi ;;
++	esac
++	if [ ${HP_ARCH} = "hppa2.0w" ]
++	then
++	    eval $set_cc_for_build
++
++	    # hppa2.0w-hp-hpux* has a 64-bit kernel and a compiler generating
++	    # 32-bit code.  hppa64-hp-hpux* has the same kernel and a compiler
++	    # generating 64-bit code.  GNU and HP use different nomenclature:
++	    #
++	    # $ CC_FOR_BUILD=cc ./config.guess
++	    # => hppa2.0w-hp-hpux11.23
++	    # $ CC_FOR_BUILD="cc +DA2.0w" ./config.guess
++	    # => hppa64-hp-hpux11.23
++
++	    if echo __LP64__ | (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) |
++		grep -q __LP64__
++	    then
++		HP_ARCH="hppa2.0w"
++	    else
++		HP_ARCH="hppa64"
++	    fi
++	fi
++	echo ${HP_ARCH}-hp-hpux${HPUX_REV}
++	exit ;;
++    ia64:HP-UX:*:*)
++	HPUX_REV=`echo ${UNAME_RELEASE}|sed -e 's/[^.]*.[0B]*//'`
++	echo ia64-hp-hpux${HPUX_REV}
++	exit ;;
++    3050*:HI-UX:*:*)
++	eval $set_cc_for_build
++	sed 's/^	//' << EOF >$dummy.c
++	#include <unistd.h>
++	int
++	main ()
++	{
++	  long cpu = sysconf (_SC_CPU_VERSION);
++	  /* The order matters, because CPU_IS_HP_MC68K erroneously returns
++	     true for CPU_PA_RISC1_0.  CPU_IS_PA_RISC returns correct
++	     results, however.  */
++	  if (CPU_IS_PA_RISC (cpu))
++	    {
++	      switch (cpu)
++		{
++		  case CPU_PA_RISC1_0: puts ("hppa1.0-hitachi-hiuxwe2"); break;
++		  case CPU_PA_RISC1_1: puts ("hppa1.1-hitachi-hiuxwe2"); break;
++		  case CPU_PA_RISC2_0: puts ("hppa2.0-hitachi-hiuxwe2"); break;
++		  default: puts ("hppa-hitachi-hiuxwe2"); break;
++		}
++	    }
++	  else if (CPU_IS_HP_MC68K (cpu))
++	    puts ("m68k-hitachi-hiuxwe2");
++	  else puts ("unknown-hitachi-hiuxwe2");
++	  exit (0);
++	}
++EOF
++	$CC_FOR_BUILD -o $dummy $dummy.c && SYSTEM_NAME=`$dummy` &&
++		{ echo "$SYSTEM_NAME"; exit; }
++	echo unknown-hitachi-hiuxwe2
++	exit ;;
++    9000/7??:4.3bsd:*:* | 9000/8?[79]:4.3bsd:*:* )
++	echo hppa1.1-hp-bsd
++	exit ;;
++    9000/8??:4.3bsd:*:*)
++	echo hppa1.0-hp-bsd
++	exit ;;
++    *9??*:MPE/iX:*:* | *3000*:MPE/iX:*:*)
++	echo hppa1.0-hp-mpeix
++	exit ;;
++    hp7??:OSF1:*:* | hp8?[79]:OSF1:*:* )
++	echo hppa1.1-hp-osf
++	exit ;;
++    hp8??:OSF1:*:*)
++	echo hppa1.0-hp-osf
++	exit ;;
++    i*86:OSF1:*:*)
++	if [ -x /usr/sbin/sysversion ] ; then
++	    echo ${UNAME_MACHINE}-unknown-osf1mk
++	else
++	    echo ${UNAME_MACHINE}-unknown-osf1
++	fi
++	exit ;;
++    parisc*:Lites*:*:*)
++	echo hppa1.1-hp-lites
++	exit ;;
++    C1*:ConvexOS:*:* | convex:ConvexOS:C1*:*)
++	echo c1-convex-bsd
++        exit ;;
++    C2*:ConvexOS:*:* | convex:ConvexOS:C2*:*)
++	if getsysinfo -f scalar_acc
++	then echo c32-convex-bsd
++	else echo c2-convex-bsd
++	fi
++        exit ;;
++    C34*:ConvexOS:*:* | convex:ConvexOS:C34*:*)
++	echo c34-convex-bsd
++        exit ;;
++    C38*:ConvexOS:*:* | convex:ConvexOS:C38*:*)
++	echo c38-convex-bsd
++        exit ;;
++    C4*:ConvexOS:*:* | convex:ConvexOS:C4*:*)
++	echo c4-convex-bsd
++        exit ;;
++    CRAY*Y-MP:*:*:*)
++	echo ymp-cray-unicos${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
++	exit ;;
++    CRAY*[A-Z]90:*:*:*)
++	echo ${UNAME_MACHINE}-cray-unicos${UNAME_RELEASE} \
++	| sed -e 's/CRAY.*\([A-Z]90\)/\1/' \
++	      -e y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/ \
++	      -e 's/\.[^.]*$/.X/'
++	exit ;;
++    CRAY*TS:*:*:*)
++	echo t90-cray-unicos${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
++	exit ;;
++    CRAY*T3E:*:*:*)
++	echo alphaev5-cray-unicosmk${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
++	exit ;;
++    CRAY*SV1:*:*:*)
++	echo sv1-cray-unicos${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
++	exit ;;
++    *:UNICOS/mp:*:*)
++	echo craynv-cray-unicosmp${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
++	exit ;;
++    F30[01]:UNIX_System_V:*:* | F700:UNIX_System_V:*:*)
++	FUJITSU_PROC=`uname -m | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'`
++        FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'`
++        FUJITSU_REL=`echo ${UNAME_RELEASE} | sed -e 's/ /_/'`
++        echo "${FUJITSU_PROC}-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
++        exit ;;
++    5000:UNIX_System_V:4.*:*)
++        FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'`
++        FUJITSU_REL=`echo ${UNAME_RELEASE} | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/ /_/'`
++        echo "sparc-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
++	exit ;;
++    i*86:BSD/386:*:* | i*86:BSD/OS:*:* | *:Ascend\ Embedded/OS:*:*)
++	echo ${UNAME_MACHINE}-pc-bsdi${UNAME_RELEASE}
++	exit ;;
++    sparc*:BSD/OS:*:*)
++	echo sparc-unknown-bsdi${UNAME_RELEASE}
++	exit ;;
++    *:BSD/OS:*:*)
++	echo ${UNAME_MACHINE}-unknown-bsdi${UNAME_RELEASE}
++	exit ;;
++    *:FreeBSD:*:*)
++	case ${UNAME_MACHINE} in
++	    pc98)
++		echo i386-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;
++	    amd64)
++		echo x86_64-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;
++	    *)
++		echo ${UNAME_MACHINE}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;
++	esac
++	exit ;;
++    i*:CYGWIN*:*)
++	echo ${UNAME_MACHINE}-pc-cygwin
++	exit ;;
++    *:MINGW*:*)
++	echo ${UNAME_MACHINE}-pc-mingw32
++	exit ;;
++    i*:windows32*:*)
++    	# uname -m includes "-pc" on this system.
++    	echo ${UNAME_MACHINE}-mingw32
++	exit ;;
++    i*:PW*:*)
++	echo ${UNAME_MACHINE}-pc-pw32
++	exit ;;
++    *:Interix*:*)
++    	case ${UNAME_MACHINE} in
++	    x86)
++		echo i586-pc-interix${UNAME_RELEASE}
++		exit ;;
++	    authenticamd | genuineintel | EM64T)
++		echo x86_64-unknown-interix${UNAME_RELEASE}
++		exit ;;
++	    IA64)
++		echo ia64-unknown-interix${UNAME_RELEASE}
++		exit ;;
++	esac ;;
++    [345]86:Windows_95:* | [345]86:Windows_98:* | [345]86:Windows_NT:*)
++	echo i${UNAME_MACHINE}-pc-mks
++	exit ;;
++    8664:Windows_NT:*)
++	echo x86_64-pc-mks
++	exit ;;
++    i*:Windows_NT*:* | Pentium*:Windows_NT*:*)
++	# How do we know it's Interix rather than the generic POSIX subsystem?
++	# It also conflicts with pre-2.0 versions of AT&T UWIN. Should we
++	# UNAME_MACHINE based on the output of uname instead of i386?
++	echo i586-pc-interix
++	exit ;;
++    i*:UWIN*:*)
++	echo ${UNAME_MACHINE}-pc-uwin
++	exit ;;
++    amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*)
++	echo x86_64-unknown-cygwin
++	exit ;;
++    p*:CYGWIN*:*)
++	echo powerpcle-unknown-cygwin
++	exit ;;
++    prep*:SunOS:5.*:*)
++	echo powerpcle-unknown-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
++	exit ;;
++    *:GNU:*:*)
++	# the GNU system
++	echo `echo ${UNAME_MACHINE}|sed -e 's,[-/].*$,,'`-unknown-gnu`echo ${UNAME_RELEASE}|sed -e 's,/.*$,,'`
++	exit ;;
++    *:GNU/*:*:*)
++	# other systems with GNU libc and userland
++	echo ${UNAME_MACHINE}-unknown-`echo ${UNAME_SYSTEM} | sed 's,^[^/]*/,,' | tr '[A-Z]' '[a-z]'``echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`-gnu
++	exit ;;
++    i*86:Minix:*:*)
++	echo ${UNAME_MACHINE}-pc-minix
++	exit ;;
++    alpha:Linux:*:*)
++	case `sed -n '/^cpu model/s/^.*: \(.*\)/\1/p' < /proc/cpuinfo` in
++	  EV5)   UNAME_MACHINE=alphaev5 ;;
++	  EV56)  UNAME_MACHINE=alphaev56 ;;
++	  PCA56) UNAME_MACHINE=alphapca56 ;;
++	  PCA57) UNAME_MACHINE=alphapca56 ;;
++	  EV6)   UNAME_MACHINE=alphaev6 ;;
++	  EV67)  UNAME_MACHINE=alphaev67 ;;
++	  EV68*) UNAME_MACHINE=alphaev68 ;;
++        esac
++	objdump --private-headers /bin/sh | grep -q ld.so.1
++	if test "$?" = 0 ; then LIBC="libc1" ; else LIBC="" ; fi
++	echo ${UNAME_MACHINE}-unknown-linux-gnu${LIBC}
++	exit ;;
++    arm*:Linux:*:*)
++	eval $set_cc_for_build
++	if echo __ARM_EABI__ | $CC_FOR_BUILD -E - 2>/dev/null \
++	    | grep -q __ARM_EABI__
++	then
++	    echo ${UNAME_MACHINE}-unknown-linux-gnu
++	else
++	    echo ${UNAME_MACHINE}-unknown-linux-gnueabi
++	fi
++	exit ;;
++    avr32*:Linux:*:*)
++	echo ${UNAME_MACHINE}-unknown-linux-gnu
++	exit ;;
++    cris:Linux:*:*)
++	echo cris-axis-linux-gnu
++	exit ;;
++    crisv32:Linux:*:*)
++	echo crisv32-axis-linux-gnu
++	exit ;;
++    frv:Linux:*:*)
++    	echo frv-unknown-linux-gnu
++	exit ;;
++    i*86:Linux:*:*)
++	LIBC=gnu
++	eval $set_cc_for_build
++	sed 's/^	//' << EOF >$dummy.c
++	#ifdef __dietlibc__
++	LIBC=dietlibc
++	#endif
++EOF
++	eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^LIBC'`
++	echo "${UNAME_MACHINE}-pc-linux-${LIBC}"
++	exit ;;
++    ia64:Linux:*:*)
++	echo ${UNAME_MACHINE}-unknown-linux-gnu
++	exit ;;
++    m32r*:Linux:*:*)
++	echo ${UNAME_MACHINE}-unknown-linux-gnu
++	exit ;;
++    m68*:Linux:*:*)
++	echo ${UNAME_MACHINE}-unknown-linux-gnu
++	exit ;;
++    mips:Linux:*:* | mips64:Linux:*:*)
++	eval $set_cc_for_build
++	sed 's/^	//' << EOF >$dummy.c
++	#undef CPU
++	#undef ${UNAME_MACHINE}
++	#undef ${UNAME_MACHINE}el
++	#if defined(__MIPSEL__) || defined(__MIPSEL) || defined(_MIPSEL) || defined(MIPSEL)
++	CPU=${UNAME_MACHINE}el
++	#else
++	#if defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || defined(MIPSEB)
++	CPU=${UNAME_MACHINE}
++	#else
++	CPU=
++	#endif
++	#endif
++EOF
++	eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'`
++	test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; }
++	;;
++    or32:Linux:*:*)
++	echo or32-unknown-linux-gnu
++	exit ;;
++    padre:Linux:*:*)
++	echo sparc-unknown-linux-gnu
++	exit ;;
++    parisc64:Linux:*:* | hppa64:Linux:*:*)
++	echo hppa64-unknown-linux-gnu
++	exit ;;
++    parisc:Linux:*:* | hppa:Linux:*:*)
++	# Look for CPU level
++	case `grep '^cpu[^a-z]*:' /proc/cpuinfo 2>/dev/null | cut -d' ' -f2` in
++	  PA7*) echo hppa1.1-unknown-linux-gnu ;;
++	  PA8*) echo hppa2.0-unknown-linux-gnu ;;
++	  *)    echo hppa-unknown-linux-gnu ;;
++	esac
++	exit ;;
++    ppc64:Linux:*:*)
++	echo powerpc64-unknown-linux-gnu
++	exit ;;
++    ppc:Linux:*:*)
++	echo powerpc-unknown-linux-gnu
++	exit ;;
++    s390:Linux:*:* | s390x:Linux:*:*)
++	echo ${UNAME_MACHINE}-ibm-linux
++	exit ;;
++    sh64*:Linux:*:*)
++    	echo ${UNAME_MACHINE}-unknown-linux-gnu
++	exit ;;
++    sh*:Linux:*:*)
++	echo ${UNAME_MACHINE}-unknown-linux-gnu
++	exit ;;
++    sparc:Linux:*:* | sparc64:Linux:*:*)
++	echo ${UNAME_MACHINE}-unknown-linux-gnu
++	exit ;;
++    vax:Linux:*:*)
++	echo ${UNAME_MACHINE}-dec-linux-gnu
++	exit ;;
++    x86_64:Linux:*:*)
++	echo x86_64-unknown-linux-gnu
++	exit ;;
++    xtensa*:Linux:*:*)
++    	echo ${UNAME_MACHINE}-unknown-linux-gnu
++	exit ;;
++    i*86:DYNIX/ptx:4*:*)
++	# ptx 4.0 does uname -s correctly, with DYNIX/ptx in there.
++	# earlier versions are messed up and put the nodename in both
++	# sysname and nodename.
++	echo i386-sequent-sysv4
++	exit ;;
++    i*86:UNIX_SV:4.2MP:2.*)
++        # Unixware is an offshoot of SVR4, but it has its own version
++        # number series starting with 2...
++        # I am not positive that other SVR4 systems won't match this,
++	# I just have to hope.  -- rms.
++        # Use sysv4.2uw... so that sysv4* matches it.
++	echo ${UNAME_MACHINE}-pc-sysv4.2uw${UNAME_VERSION}
++	exit ;;
++    i*86:OS/2:*:*)
++	# If we were able to find `uname', then EMX Unix compatibility
++	# is probably installed.
++	echo ${UNAME_MACHINE}-pc-os2-emx
++	exit ;;
++    i*86:XTS-300:*:STOP)
++	echo ${UNAME_MACHINE}-unknown-stop
++	exit ;;
++    i*86:atheos:*:*)
++	echo ${UNAME_MACHINE}-unknown-atheos
++	exit ;;
++    i*86:syllable:*:*)
++	echo ${UNAME_MACHINE}-pc-syllable
++	exit ;;
++    i*86:LynxOS:2.*:* | i*86:LynxOS:3.[01]*:* | i*86:LynxOS:4.[02]*:*)
++	echo i386-unknown-lynxos${UNAME_RELEASE}
++	exit ;;
++    i*86:*DOS:*:*)
++	echo ${UNAME_MACHINE}-pc-msdosdjgpp
++	exit ;;
++    i*86:*:4.*:* | i*86:SYSTEM_V:4.*:*)
++	UNAME_REL=`echo ${UNAME_RELEASE} | sed 's/\/MP$//'`
++	if grep Novell /usr/include/link.h >/dev/null 2>/dev/null; then
++		echo ${UNAME_MACHINE}-univel-sysv${UNAME_REL}
++	else
++		echo ${UNAME_MACHINE}-pc-sysv${UNAME_REL}
++	fi
++	exit ;;
++    i*86:*:5:[678]*)
++    	# UnixWare 7.x, OpenUNIX and OpenServer 6.
++	case `/bin/uname -X | grep "^Machine"` in
++	    *486*)	     UNAME_MACHINE=i486 ;;
++	    *Pentium)	     UNAME_MACHINE=i586 ;;
++	    *Pent*|*Celeron) UNAME_MACHINE=i686 ;;
++	esac
++	echo ${UNAME_MACHINE}-unknown-sysv${UNAME_RELEASE}${UNAME_SYSTEM}${UNAME_VERSION}
++	exit ;;
++    i*86:*:3.2:*)
++	if test -f /usr/options/cb.name; then
++		UNAME_REL=`sed -n 's/.*Version //p' </usr/options/cb.name`
++		echo ${UNAME_MACHINE}-pc-isc$UNAME_REL
++	elif /bin/uname -X 2>/dev/null >/dev/null ; then
++		UNAME_REL=`(/bin/uname -X|grep Release|sed -e 's/.*= //')`
++		(/bin/uname -X|grep i80486 >/dev/null) && UNAME_MACHINE=i486
++		(/bin/uname -X|grep '^Machine.*Pentium' >/dev/null) \
++			&& UNAME_MACHINE=i586
++		(/bin/uname -X|grep '^Machine.*Pent *II' >/dev/null) \
++			&& UNAME_MACHINE=i686
++		(/bin/uname -X|grep '^Machine.*Pentium Pro' >/dev/null) \
++			&& UNAME_MACHINE=i686
++		echo ${UNAME_MACHINE}-pc-sco$UNAME_REL
++	else
++		echo ${UNAME_MACHINE}-pc-sysv32
++	fi
++	exit ;;
++    pc:*:*:*)
++	# Left here for compatibility:
++        # uname -m prints for DJGPP always 'pc', but it prints nothing about
++        # the processor, so we play safe by assuming i586.
++	# Note: whatever this is, it MUST be the same as what config.sub
++	# prints for the "djgpp" host, or else GDB configury will decide that
++	# this is a cross-build.
++	echo i586-pc-msdosdjgpp
++        exit ;;
++    Intel:Mach:3*:*)
++	echo i386-pc-mach3
++	exit ;;
++    paragon:*:*:*)
++	echo i860-intel-osf1
++	exit ;;
++    i860:*:4.*:*) # i860-SVR4
++	if grep Stardent /usr/include/sys/uadmin.h >/dev/null 2>&1 ; then
++	  echo i860-stardent-sysv${UNAME_RELEASE} # Stardent Vistra i860-SVR4
++	else # Add other i860-SVR4 vendors below as they are discovered.
++	  echo i860-unknown-sysv${UNAME_RELEASE}  # Unknown i860-SVR4
++	fi
++	exit ;;
++    mini*:CTIX:SYS*5:*)
++	# "miniframe"
++	echo m68010-convergent-sysv
++	exit ;;
++    mc68k:UNIX:SYSTEM5:3.51m)
++	echo m68k-convergent-sysv
++	exit ;;
++    M680?0:D-NIX:5.3:*)
++	echo m68k-diab-dnix
++	exit ;;
++    M68*:*:R3V[5678]*:*)
++	test -r /sysV68 && { echo 'm68k-motorola-sysv'; exit; } ;;
++    3[345]??:*:4.0:3.0 | 3[34]??A:*:4.0:3.0 | 3[34]??,*:*:4.0:3.0 | 3[34]??/*:*:4.0:3.0 | 4400:*:4.0:3.0 | 4850:*:4.0:3.0 | SKA40:*:4.0:3.0 | SDS2:*:4.0:3.0 | SHG2:*:4.0:3.0 | S7501*:*:4.0:3.0)
++	OS_REL=''
++	test -r /etc/.relid \
++	&& OS_REL=.`sed -n 's/[^ ]* [^ ]* \([0-9][0-9]\).*/\1/p' < /etc/.relid`
++	/bin/uname -p 2>/dev/null | grep 86 >/dev/null \
++	  && { echo i486-ncr-sysv4.3${OS_REL}; exit; }
++	/bin/uname -p 2>/dev/null | /bin/grep entium >/dev/null \
++	  && { echo i586-ncr-sysv4.3${OS_REL}; exit; } ;;
++    3[34]??:*:4.0:* | 3[34]??,*:*:4.0:*)
++        /bin/uname -p 2>/dev/null | grep 86 >/dev/null \
++          && { echo i486-ncr-sysv4; exit; } ;;
++    NCR*:*:4.2:* | MPRAS*:*:4.2:*)
++	OS_REL='.3'
++	test -r /etc/.relid \
++	    && OS_REL=.`sed -n 's/[^ ]* [^ ]* \([0-9][0-9]\).*/\1/p' < /etc/.relid`
++	/bin/uname -p 2>/dev/null | grep 86 >/dev/null \
++	    && { echo i486-ncr-sysv4.3${OS_REL}; exit; }
++	/bin/uname -p 2>/dev/null | /bin/grep entium >/dev/null \
++	    && { echo i586-ncr-sysv4.3${OS_REL}; exit; }
++	/bin/uname -p 2>/dev/null | /bin/grep pteron >/dev/null \
++	    && { echo i586-ncr-sysv4.3${OS_REL}; exit; } ;;
++    m68*:LynxOS:2.*:* | m68*:LynxOS:3.0*:*)
++	echo m68k-unknown-lynxos${UNAME_RELEASE}
++	exit ;;
++    mc68030:UNIX_System_V:4.*:*)
++	echo m68k-atari-sysv4
++	exit ;;
++    TSUNAMI:LynxOS:2.*:*)
++	echo sparc-unknown-lynxos${UNAME_RELEASE}
++	exit ;;
++    rs6000:LynxOS:2.*:*)
++	echo rs6000-unknown-lynxos${UNAME_RELEASE}
++	exit ;;
++    PowerPC:LynxOS:2.*:* | PowerPC:LynxOS:3.[01]*:* | PowerPC:LynxOS:4.[02]*:*)
++	echo powerpc-unknown-lynxos${UNAME_RELEASE}
++	exit ;;
++    SM[BE]S:UNIX_SV:*:*)
++	echo mips-dde-sysv${UNAME_RELEASE}
++	exit ;;
++    RM*:ReliantUNIX-*:*:*)
++	echo mips-sni-sysv4
++	exit ;;
++    RM*:SINIX-*:*:*)
++	echo mips-sni-sysv4
++	exit ;;
++    *:SINIX-*:*:*)
++	if uname -p 2>/dev/null >/dev/null ; then
++		UNAME_MACHINE=`(uname -p) 2>/dev/null`
++		echo ${UNAME_MACHINE}-sni-sysv4
++	else
++		echo ns32k-sni-sysv
++	fi
++	exit ;;
++    PENTIUM:*:4.0*:*) # Unisys `ClearPath HMP IX 4000' SVR4/MP effort
++                      # says <Richard.M.Bartel@ccMail.Census.GOV>
++        echo i586-unisys-sysv4
++        exit ;;
++    *:UNIX_System_V:4*:FTX*)
++	# From Gerald Hewes <hewes@openmarket.com>.
++	# How about differentiating between stratus architectures? -djm
++	echo hppa1.1-stratus-sysv4
++	exit ;;
++    *:*:*:FTX*)
++	# From seanf@swdc.stratus.com.
++	echo i860-stratus-sysv4
++	exit ;;
++    i*86:VOS:*:*)
++	# From Paul.Green@stratus.com.
++	echo ${UNAME_MACHINE}-stratus-vos
++	exit ;;
++    *:VOS:*:*)
++	# From Paul.Green@stratus.com.
++	echo hppa1.1-stratus-vos
++	exit ;;
++    mc68*:A/UX:*:*)
++	echo m68k-apple-aux${UNAME_RELEASE}
++	exit ;;
++    news*:NEWS-OS:6*:*)
++	echo mips-sony-newsos6
++	exit ;;
++    R[34]000:*System_V*:*:* | R4000:UNIX_SYSV:*:* | R*000:UNIX_SV:*:*)
++	if [ -d /usr/nec ]; then
++	        echo mips-nec-sysv${UNAME_RELEASE}
++	else
++	        echo mips-unknown-sysv${UNAME_RELEASE}
++	fi
++        exit ;;
++    BeBox:BeOS:*:*)	# BeOS running on hardware made by Be, PPC only.
++	echo powerpc-be-beos
++	exit ;;
++    BeMac:BeOS:*:*)	# BeOS running on Mac or Mac clone, PPC only.
++	echo powerpc-apple-beos
++	exit ;;
++    BePC:BeOS:*:*)	# BeOS running on Intel PC compatible.
++	echo i586-pc-beos
++	exit ;;
++    BePC:Haiku:*:*)	# Haiku running on Intel PC compatible.
++	echo i586-pc-haiku
++	exit ;;
++    SX-4:SUPER-UX:*:*)
++	echo sx4-nec-superux${UNAME_RELEASE}
++	exit ;;
++    SX-5:SUPER-UX:*:*)
++	echo sx5-nec-superux${UNAME_RELEASE}
++	exit ;;
++    SX-6:SUPER-UX:*:*)
++	echo sx6-nec-superux${UNAME_RELEASE}
++	exit ;;
++    SX-7:SUPER-UX:*:*)
++	echo sx7-nec-superux${UNAME_RELEASE}
++	exit ;;
++    SX-8:SUPER-UX:*:*)
++	echo sx8-nec-superux${UNAME_RELEASE}
++	exit ;;
++    SX-8R:SUPER-UX:*:*)
++	echo sx8r-nec-superux${UNAME_RELEASE}
++	exit ;;
++    Power*:Rhapsody:*:*)
++	echo powerpc-apple-rhapsody${UNAME_RELEASE}
++	exit ;;
++    *:Rhapsody:*:*)
++	echo ${UNAME_MACHINE}-apple-rhapsody${UNAME_RELEASE}
++	exit ;;
++    *:Darwin:*:*)
++	UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
++	case $UNAME_PROCESSOR in
++	    i386)
++		eval $set_cc_for_build
++		if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then
++		  if (echo '#ifdef __LP64__'; echo IS_64BIT_ARCH; echo '#endif') | \
++		      (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \
++		      grep IS_64BIT_ARCH >/dev/null
++		  then
++		      UNAME_PROCESSOR="x86_64"
++		  fi
++		fi ;;
++	    unknown) UNAME_PROCESSOR=powerpc ;;
++	esac
++	echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE}
++	exit ;;
++    *:procnto*:*:* | *:QNX:[0123456789]*:*)
++	UNAME_PROCESSOR=`uname -p`
++	if test "$UNAME_PROCESSOR" = "x86"; then
++		UNAME_PROCESSOR=i386
++		UNAME_MACHINE=pc
++	fi
++	echo ${UNAME_PROCESSOR}-${UNAME_MACHINE}-nto-qnx${UNAME_RELEASE}
++	exit ;;
++    *:QNX:*:4*)
++	echo i386-pc-qnx
++	exit ;;
++    NSE-?:NONSTOP_KERNEL:*:*)
++	echo nse-tandem-nsk${UNAME_RELEASE}
++	exit ;;
++    NSR-?:NONSTOP_KERNEL:*:*)
++	echo nsr-tandem-nsk${UNAME_RELEASE}
++	exit ;;
++    *:NonStop-UX:*:*)
++	echo mips-compaq-nonstopux
++	exit ;;
++    BS2000:POSIX*:*:*)
++	echo bs2000-siemens-sysv
++	exit ;;
++    DS/*:UNIX_System_V:*:*)
++	echo ${UNAME_MACHINE}-${UNAME_SYSTEM}-${UNAME_RELEASE}
++	exit ;;
++    *:Plan9:*:*)
++	# "uname -m" is not consistent, so use $cputype instead. 386
++	# is converted to i386 for consistency with other x86
++	# operating systems.
++	if test "$cputype" = "386"; then
++	    UNAME_MACHINE=i386
++	else
++	    UNAME_MACHINE="$cputype"
++	fi
++	echo ${UNAME_MACHINE}-unknown-plan9
++	exit ;;
++    *:TOPS-10:*:*)
++	echo pdp10-unknown-tops10
++	exit ;;
++    *:TENEX:*:*)
++	echo pdp10-unknown-tenex
++	exit ;;
++    KS10:TOPS-20:*:* | KL10:TOPS-20:*:* | TYPE4:TOPS-20:*:*)
++	echo pdp10-dec-tops20
++	exit ;;
++    XKL-1:TOPS-20:*:* | TYPE5:TOPS-20:*:*)
++	echo pdp10-xkl-tops20
++	exit ;;
++    *:TOPS-20:*:*)
++	echo pdp10-unknown-tops20
++	exit ;;
++    *:ITS:*:*)
++	echo pdp10-unknown-its
++	exit ;;
++    SEI:*:*:SEIUX)
++        echo mips-sei-seiux${UNAME_RELEASE}
++	exit ;;
++    *:DragonFly:*:*)
++	echo ${UNAME_MACHINE}-unknown-dragonfly`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`
++	exit ;;
++    *:*VMS:*:*)
++    	UNAME_MACHINE=`(uname -p) 2>/dev/null`
++	case "${UNAME_MACHINE}" in
++	    A*) echo alpha-dec-vms ; exit ;;
++	    I*) echo ia64-dec-vms ; exit ;;
++	    V*) echo vax-dec-vms ; exit ;;
++	esac ;;
++    *:XENIX:*:SysV)
++	echo i386-pc-xenix
++	exit ;;
++    i*86:skyos:*:*)
++	echo ${UNAME_MACHINE}-pc-skyos`echo ${UNAME_RELEASE}` | sed -e 's/ .*$//'
++	exit ;;
++    i*86:rdos:*:*)
++	echo ${UNAME_MACHINE}-pc-rdos
++	exit ;;
++    i*86:AROS:*:*)
++	echo ${UNAME_MACHINE}-pc-aros
++	exit ;;
++esac
++
++#echo '(No uname command or uname output not recognized.)' 1>&2
++#echo "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" 1>&2
++
++eval $set_cc_for_build
++cat >$dummy.c <<EOF
++#ifdef _SEQUENT_
++# include <sys/types.h>
++# include <sys/utsname.h>
++#endif
++main ()
++{
++#if defined (sony)
++#if defined (MIPSEB)
++  /* BFD wants "bsd" instead of "newsos".  Perhaps BFD should be changed,
++     I don't know....  */
++  printf ("mips-sony-bsd\n"); exit (0);
++#else
++#include <sys/param.h>
++  printf ("m68k-sony-newsos%s\n",
++#ifdef NEWSOS4
++          "4"
++#else
++	  ""
++#endif
++         ); exit (0);
++#endif
++#endif
++
++#if defined (__arm) && defined (__acorn) && defined (__unix)
++  printf ("arm-acorn-riscix\n"); exit (0);
++#endif
++
++#if defined (hp300) && !defined (hpux)
++  printf ("m68k-hp-bsd\n"); exit (0);
++#endif
++
++#if defined (NeXT)
++#if !defined (__ARCHITECTURE__)
++#define __ARCHITECTURE__ "m68k"
++#endif
++  int version;
++  version=`(hostinfo | sed -n 's/.*NeXT Mach \([0-9]*\).*/\1/p') 2>/dev/null`;
++  if (version < 4)
++    printf ("%s-next-nextstep%d\n", __ARCHITECTURE__, version);
++  else
++    printf ("%s-next-openstep%d\n", __ARCHITECTURE__, version);
++  exit (0);
++#endif
++
++#if defined (MULTIMAX) || defined (n16)
++#if defined (UMAXV)
++  printf ("ns32k-encore-sysv\n"); exit (0);
++#else
++#if defined (CMU)
++  printf ("ns32k-encore-mach\n"); exit (0);
++#else
++  printf ("ns32k-encore-bsd\n"); exit (0);
++#endif
++#endif
++#endif
++
++#if defined (__386BSD__)
++  printf ("i386-pc-bsd\n"); exit (0);
++#endif
++
++#if defined (sequent)
++#if defined (i386)
++  printf ("i386-sequent-dynix\n"); exit (0);
++#endif
++#if defined (ns32000)
++  printf ("ns32k-sequent-dynix\n"); exit (0);
++#endif
++#endif
++
++#if defined (_SEQUENT_)
++    struct utsname un;
++
++    uname(&un);
++
++    if (strncmp(un.version, "V2", 2) == 0) {
++	printf ("i386-sequent-ptx2\n"); exit (0);
++    }
++    if (strncmp(un.version, "V1", 2) == 0) { /* XXX is V1 correct? */
++	printf ("i386-sequent-ptx1\n"); exit (0);
++    }
++    printf ("i386-sequent-ptx\n"); exit (0);
++
++#endif
++
++#if defined (vax)
++# if !defined (ultrix)
++#  include <sys/param.h>
++#  if defined (BSD)
++#   if BSD == 43
++      printf ("vax-dec-bsd4.3\n"); exit (0);
++#   else
++#    if BSD == 199006
++      printf ("vax-dec-bsd4.3reno\n"); exit (0);
++#    else
++      printf ("vax-dec-bsd\n"); exit (0);
++#    endif
++#   endif
++#  else
++    printf ("vax-dec-bsd\n"); exit (0);
++#  endif
++# else
++    printf ("vax-dec-ultrix\n"); exit (0);
++# endif
++#endif
++
++#if defined (alliant) && defined (i860)
++  printf ("i860-alliant-bsd\n"); exit (0);
++#endif
++
++  exit (1);
++}
++EOF
++
++$CC_FOR_BUILD -o $dummy $dummy.c 2>/dev/null && SYSTEM_NAME=`$dummy` &&
++	{ echo "$SYSTEM_NAME"; exit; }
++
++# Apollos put the system type in the environment.
++
++test -d /usr/apollo && { echo ${ISP}-apollo-${SYSTYPE}; exit; }
++
++# Convex versions that predate uname can use getsysinfo(1)
++
++if [ -x /usr/convex/getsysinfo ]
++then
++    case `getsysinfo -f cpu_type` in
++    c1*)
++	echo c1-convex-bsd
++	exit ;;
++    c2*)
++	if getsysinfo -f scalar_acc
++	then echo c32-convex-bsd
++	else echo c2-convex-bsd
++	fi
++	exit ;;
++    c34*)
++	echo c34-convex-bsd
++	exit ;;
++    c38*)
++	echo c38-convex-bsd
++	exit ;;
++    c4*)
++	echo c4-convex-bsd
++	exit ;;
++    esac
++fi
++
++cat >&2 <<EOF
++$0: unable to guess system type
++
++This script, last modified $timestamp, has failed to recognize
++the operating system you are using. It is advised that you
++download the most up to date version of the config scripts from
++
++  http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
++and
++  http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
++
++If the version you run ($0) is already up to date, please
++send the following data and any information you think might be
++pertinent to <config-patches@gnu.org> in order to provide the needed
++information to handle your system.
++
++config.guess timestamp = $timestamp
++
++uname -m = `(uname -m) 2>/dev/null || echo unknown`
++uname -r = `(uname -r) 2>/dev/null || echo unknown`
++uname -s = `(uname -s) 2>/dev/null || echo unknown`
++uname -v = `(uname -v) 2>/dev/null || echo unknown`
++
++/usr/bin/uname -p = `(/usr/bin/uname -p) 2>/dev/null`
++/bin/uname -X     = `(/bin/uname -X) 2>/dev/null`
++
++hostinfo               = `(hostinfo) 2>/dev/null`
++/bin/universe          = `(/bin/universe) 2>/dev/null`
++/usr/bin/arch -k       = `(/usr/bin/arch -k) 2>/dev/null`
++/bin/arch              = `(/bin/arch) 2>/dev/null`
++/usr/bin/oslevel       = `(/usr/bin/oslevel) 2>/dev/null`
++/usr/convex/getsysinfo = `(/usr/convex/getsysinfo) 2>/dev/null`
++
++UNAME_MACHINE = ${UNAME_MACHINE}
++UNAME_RELEASE = ${UNAME_RELEASE}
++UNAME_SYSTEM  = ${UNAME_SYSTEM}
++UNAME_VERSION = ${UNAME_VERSION}
++EOF
++
++exit 1
++
++# Local variables:
++# eval: (add-hook 'write-file-hooks 'time-stamp)
++# time-stamp-start: "timestamp='"
++# time-stamp-format: "%:y-%02m-%02d"
++# time-stamp-end: "'"
++# End:
+Index: git/config.sub
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/config.sub	2010-12-29 04:04:06.000000000 +0100
+@@ -0,0 +1,1714 @@
++#! /bin/sh
++# Configuration validation subroutine script.
++#   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
++#   2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
++#   Free Software Foundation, Inc.
++
++timestamp='2010-01-22'
++
++# This file is (in principle) common to ALL GNU software.
++# The presence of a machine in this file suggests that SOME GNU software
++# can handle that machine.  It does not imply ALL GNU software can.
++#
++# This file is free software; you can redistribute it and/or modify
++# it under the terms of the GNU General Public License as published by
++# the Free Software Foundation; either version 2 of the License, or
++# (at your option) any later version.
++#
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY; without even the implied warranty of
++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++# GNU General Public License for more details.
++#
++# You should have received a copy of the GNU General Public License
++# along with this program; if not, write to the Free Software
++# Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA
++# 02110-1301, USA.
++#
++# As a special exception to the GNU General Public License, if you
++# distribute this file as part of a program that contains a
++# configuration script generated by Autoconf, you may include it under
++# the same distribution terms that you use for the rest of that program.
++
++
++# Please send patches to <config-patches@gnu.org>.  Submit a context
++# diff and a properly formatted GNU ChangeLog entry.
++#
++# Configuration subroutine to validate and canonicalize a configuration type.
++# Supply the specified configuration type as an argument.
++# If it is invalid, we print an error message on stderr and exit with code 1.
++# Otherwise, we print the canonical config type on stdout and succeed.
++
++# You can get the latest version of this script from:
++# http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
++
++# This file is supposed to be the same for all GNU packages
++# and recognize all the CPU types, system types and aliases
++# that are meaningful with *any* GNU software.
++# Each package is responsible for reporting which valid configurations
++# it does not support.  The user should be able to distinguish
++# a failure to support a valid configuration from a meaningless
++# configuration.
++
++# The goal of this file is to map all the various variations of a given
++# machine specification into a single specification in the form:
++#	CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
++# or in some cases, the newer four-part form:
++#	CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
++# It is wrong to echo any other type of specification.
++
++me=`echo "$0" | sed -e 's,.*/,,'`
++
++usage="\
++Usage: $0 [OPTION] CPU-MFR-OPSYS
++       $0 [OPTION] ALIAS
++
++Canonicalize a configuration name.
++
++Operation modes:
++  -h, --help         print this help, then exit
++  -t, --time-stamp   print date of last modification, then exit
++  -v, --version      print version number, then exit
++
++Report bugs and patches to <config-patches@gnu.org>."
++
++version="\
++GNU config.sub ($timestamp)
++
++Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
++2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free
++Software Foundation, Inc.
++
++This is free software; see the source for copying conditions.  There is NO
++warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
++
++help="
++Try \`$me --help' for more information."
++
++# Parse command line
++while test $# -gt 0 ; do
++  case $1 in
++    --time-stamp | --time* | -t )
++       echo "$timestamp" ; exit ;;
++    --version | -v )
++       echo "$version" ; exit ;;
++    --help | --h* | -h )
++       echo "$usage"; exit ;;
++    -- )     # Stop option processing
++       shift; break ;;
++    - )	# Use stdin as input.
++       break ;;
++    -* )
++       echo "$me: invalid option $1$help"
++       exit 1 ;;
++
++    *local*)
++       # First pass through any local machine types.
++       echo $1
++       exit ;;
++
++    * )
++       break ;;
++  esac
++done
++
++case $# in
++ 0) echo "$me: missing argument$help" >&2
++    exit 1;;
++ 1) ;;
++ *) echo "$me: too many arguments$help" >&2
++    exit 1;;
++esac
++
++# Separate what the user gave into CPU-COMPANY and OS or KERNEL-OS (if any).
++# Here we must recognize all the valid KERNEL-OS combinations.
++maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'`
++case $maybe_os in
++  nto-qnx* | linux-gnu* | linux-dietlibc | linux-newlib* | linux-uclibc* | \
++  uclinux-uclibc* | uclinux-gnu* | kfreebsd*-gnu* | knetbsd*-gnu* | netbsd*-gnu* | \
++  kopensolaris*-gnu* | \
++  storm-chaos* | os2-emx* | rtmk-nova*)
++    os=-$maybe_os
++    basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
++    ;;
++  *)
++    basic_machine=`echo $1 | sed 's/-[^-]*$//'`
++    if [ $basic_machine != $1 ]
++    then os=`echo $1 | sed 's/.*-/-/'`
++    else os=; fi
++    ;;
++esac
++
++### Let's recognize common machines as not being operating systems so
++### that things like config.sub decstation-3100 work.  We also
++### recognize some manufacturers as not being operating systems, so we
++### can provide default operating systems below.
++case $os in
++	-sun*os*)
++		# Prevent following clause from handling this invalid input.
++		;;
++	-dec* | -mips* | -sequent* | -encore* | -pc532* | -sgi* | -sony* | \
++	-att* | -7300* | -3300* | -delta* | -motorola* | -sun[234]* | \
++	-unicom* | -ibm* | -next | -hp | -isi* | -apollo | -altos* | \
++	-convergent* | -ncr* | -news | -32* | -3600* | -3100* | -hitachi* |\
++	-c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \
++	-harris | -dolphin | -highlevel | -gould | -cbm | -ns | -masscomp | \
++	-apple | -axis | -knuth | -cray | -microblaze)
++		os=
++		basic_machine=$1
++		;;
++        -bluegene*)
++	        os=-cnk
++		;;
++	-sim | -cisco | -oki | -wec | -winbond)
++		os=
++		basic_machine=$1
++		;;
++	-scout)
++		;;
++	-wrs)
++		os=-vxworks
++		basic_machine=$1
++		;;
++	-chorusos*)
++		os=-chorusos
++		basic_machine=$1
++		;;
++ 	-chorusrdb)
++ 		os=-chorusrdb
++		basic_machine=$1
++ 		;;
++	-hiux*)
++		os=-hiuxwe2
++		;;
++	-sco6)
++		os=-sco5v6
++		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
++		;;
++	-sco5)
++		os=-sco3.2v5
++		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
++		;;
++	-sco4)
++		os=-sco3.2v4
++		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
++		;;
++	-sco3.2.[4-9]*)
++		os=`echo $os | sed -e 's/sco3.2./sco3.2v/'`
++		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
++		;;
++	-sco3.2v[4-9]*)
++		# Don't forget version if it is 3.2v4 or newer.
++		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
++		;;
++	-sco5v6*)
++		# Don't forget version if it is 3.2v4 or newer.
++		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
++		;;
++	-sco*)
++		os=-sco3.2v2
++		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
++		;;
++	-udk*)
++		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
++		;;
++	-isc)
++		os=-isc2.2
++		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
++		;;
++	-clix*)
++		basic_machine=clipper-intergraph
++		;;
++	-isc*)
++		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
++		;;
++	-lynx*)
++		os=-lynxos
++		;;
++	-ptx*)
++		basic_machine=`echo $1 | sed -e 's/86-.*/86-sequent/'`
++		;;
++	-windowsnt*)
++		os=`echo $os | sed -e 's/windowsnt/winnt/'`
++		;;
++	-psos*)
++		os=-psos
++		;;
++	-mint | -mint[0-9]*)
++		basic_machine=m68k-atari
++		os=-mint
++		;;
++esac
++
++# Decode aliases for certain CPU-COMPANY combinations.
++case $basic_machine in
++	# Recognize the basic CPU types without company name.
++	# Some are omitted here because they have special meanings below.
++	1750a | 580 \
++	| a29k \
++	| alpha | alphaev[4-8] | alphaev56 | alphaev6[78] | alphapca5[67] \
++	| alpha64 | alpha64ev[4-8] | alpha64ev56 | alpha64ev6[78] | alpha64pca5[67] \
++	| am33_2.0 \
++	| arc | arm | arm[bl]e | arme[lb] | armv[2345] | armv[345][lb] | avr | avr32 \
++	| bfin \
++	| c4x | clipper \
++	| d10v | d30v | dlx | dsp16xx \
++	| fido | fr30 | frv \
++	| h8300 | h8500 | hppa | hppa1.[01] | hppa2.0 | hppa2.0[nw] | hppa64 \
++	| i370 | i860 | i960 | ia64 \
++	| ip2k | iq2000 \
++	| lm32 \
++	| m32c | m32r | m32rle | m68000 | m68k | m88k \
++	| maxq | mb | microblaze | mcore | mep | metag \
++	| mips | mipsbe | mipseb | mipsel | mipsle \
++	| mips16 \
++	| mips64 | mips64el \
++	| mips64octeon | mips64octeonel \
++	| mips64orion | mips64orionel \
++	| mips64r5900 | mips64r5900el \
++	| mips64vr | mips64vrel \
++	| mips64vr4100 | mips64vr4100el \
++	| mips64vr4300 | mips64vr4300el \
++	| mips64vr5000 | mips64vr5000el \
++	| mips64vr5900 | mips64vr5900el \
++	| mipsisa32 | mipsisa32el \
++	| mipsisa32r2 | mipsisa32r2el \
++	| mipsisa64 | mipsisa64el \
++	| mipsisa64r2 | mipsisa64r2el \
++	| mipsisa64sb1 | mipsisa64sb1el \
++	| mipsisa64sr71k | mipsisa64sr71kel \
++	| mipstx39 | mipstx39el \
++	| mn10200 | mn10300 \
++	| moxie \
++	| mt \
++	| msp430 \
++	| nios | nios2 \
++	| ns16k | ns32k \
++	| or32 \
++	| pdp10 | pdp11 | pj | pjl \
++	| powerpc | powerpc64 | powerpc64le | powerpcle | ppcbe \
++	| pyramid \
++	| rx \
++	| score \
++	| sh | sh[1234] | sh[24]a | sh[24]aeb | sh[23]e | sh[34]eb | sheb | shbe | shle | sh[1234]le | sh3ele \
++	| sh64 | sh64le \
++	| sparc | sparc64 | sparc64b | sparc64v | sparc86x | sparclet | sparclite \
++	| sparcv8 | sparcv9 | sparcv9b | sparcv9v \
++	| spu | strongarm \
++	| tahoe | thumb | tic4x | tic80 | tron \
++	| ubicom32 \
++	| v850 | v850e \
++	| we32k \
++	| x86 | xc16x | xscale | xscalee[bl] | xstormy16 | xtensa \
++	| z8k | z80)
++		basic_machine=$basic_machine-unknown
++		;;
++	m6811 | m68hc11 | m6812 | m68hc12 | picochip)
++		# Motorola 68HC11/12.
++		basic_machine=$basic_machine-unknown
++		os=-none
++		;;
++	m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | v70 | w65 | z8k)
++		;;
++	ms1)
++		basic_machine=mt-unknown
++		;;
++
++	# We use `pc' rather than `unknown'
++	# because (1) that's what they normally are, and
++	# (2) the word "unknown" tends to confuse beginning users.
++	i*86 | x86_64)
++	  basic_machine=$basic_machine-pc
++	  ;;
++	# Object if more than one company name word.
++	*-*-*)
++		echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2
++		exit 1
++		;;
++	# Recognize the basic CPU types with company name.
++	580-* \
++	| a29k-* \
++	| alpha-* | alphaev[4-8]-* | alphaev56-* | alphaev6[78]-* \
++	| alpha64-* | alpha64ev[4-8]-* | alpha64ev56-* | alpha64ev6[78]-* \
++	| alphapca5[67]-* | alpha64pca5[67]-* | arc-* \
++	| arm-*  | armbe-* | armle-* | armeb-* | armv*-* \
++	| avr-* | avr32-* \
++	| bfin-* | bs2000-* \
++	| c[123]* | c30-* | [cjt]90-* | c4x-* | c54x-* | c55x-* | c6x-* \
++	| clipper-* | craynv-* | cydra-* \
++	| d10v-* | d30v-* | dlx-* \
++	| elxsi-* \
++	| f30[01]-* | f700-* | fido-* | fr30-* | frv-* | fx80-* \
++	| h8300-* | h8500-* \
++	| hppa-* | hppa1.[01]-* | hppa2.0-* | hppa2.0[nw]-* | hppa64-* \
++	| i*86-* | i860-* | i960-* | ia64-* \
++	| ip2k-* | iq2000-* \
++	| lm32-* \
++	| m32c-* | m32r-* | m32rle-* \
++	| m68000-* | m680[012346]0-* | m68360-* | m683?2-* | m68k-* \
++	| m88110-* | m88k-* | maxq-* | mcore-* | metag-* | microblaze-* \
++	| mips-* | mipsbe-* | mipseb-* | mipsel-* | mipsle-* \
++	| mips16-* \
++	| mips64-* | mips64el-* \
++	| mips64octeon-* | mips64octeonel-* \
++	| mips64orion-* | mips64orionel-* \
++	| mips64r5900-* | mips64r5900el-* \
++	| mips64vr-* | mips64vrel-* \
++	| mips64vr4100-* | mips64vr4100el-* \
++	| mips64vr4300-* | mips64vr4300el-* \
++	| mips64vr5000-* | mips64vr5000el-* \
++	| mips64vr5900-* | mips64vr5900el-* \
++	| mipsisa32-* | mipsisa32el-* \
++	| mipsisa32r2-* | mipsisa32r2el-* \
++	| mipsisa64-* | mipsisa64el-* \
++	| mipsisa64r2-* | mipsisa64r2el-* \
++	| mipsisa64sb1-* | mipsisa64sb1el-* \
++	| mipsisa64sr71k-* | mipsisa64sr71kel-* \
++	| mipstx39-* | mipstx39el-* \
++	| mmix-* \
++	| mt-* \
++	| msp430-* \
++	| nios-* | nios2-* \
++	| none-* | np1-* | ns16k-* | ns32k-* \
++	| orion-* \
++	| pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \
++	| powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* | ppcbe-* \
++	| pyramid-* \
++	| romp-* | rs6000-* | rx-* \
++	| sh-* | sh[1234]-* | sh[24]a-* | sh[24]aeb-* | sh[23]e-* | sh[34]eb-* | sheb-* | shbe-* \
++	| shle-* | sh[1234]le-* | sh3ele-* | sh64-* | sh64le-* \
++	| sparc-* | sparc64-* | sparc64b-* | sparc64v-* | sparc86x-* | sparclet-* \
++	| sparclite-* \
++	| sparcv8-* | sparcv9-* | sparcv9b-* | sparcv9v-* | strongarm-* | sv1-* | sx?-* \
++	| tahoe-* | thumb-* \
++	| tic30-* | tic4x-* | tic54x-* | tic55x-* | tic6x-* | tic80-* \
++	| tile-* | tilegx-* \
++	| tron-* \
++	| ubicom32-* \
++	| v850-* | v850e-* | vax-* \
++	| we32k-* \
++	| x86-* | x86_64-* | xc16x-* | xps100-* | xscale-* | xscalee[bl]-* \
++	| xstormy16-* | xtensa*-* \
++	| ymp-* \
++	| z8k-* | z80-*)
++		;;
++	# Recognize the basic CPU types without company name, with glob match.
++	xtensa*)
++		basic_machine=$basic_machine-unknown
++		;;
++	# Recognize the various machine names and aliases which stand
++	# for a CPU type and a company and sometimes even an OS.
++	386bsd)
++		basic_machine=i386-unknown
++		os=-bsd
++		;;
++	3b1 | 7300 | 7300-att | att-7300 | pc7300 | safari | unixpc)
++		basic_machine=m68000-att
++		;;
++	3b*)
++		basic_machine=we32k-att
++		;;
++	a29khif)
++		basic_machine=a29k-amd
++		os=-udi
++		;;
++    	abacus)
++		basic_machine=abacus-unknown
++		;;
++	adobe68k)
++		basic_machine=m68010-adobe
++		os=-scout
++		;;
++	alliant | fx80)
++		basic_machine=fx80-alliant
++		;;
++	altos | altos3068)
++		basic_machine=m68k-altos
++		;;
++	am29k)
++		basic_machine=a29k-none
++		os=-bsd
++		;;
++	amd64)
++		basic_machine=x86_64-pc
++		;;
++	amd64-*)
++		basic_machine=x86_64-`echo $basic_machine | sed 's/^[^-]*-//'`
++		;;
++	amdahl)
++		basic_machine=580-amdahl
++		os=-sysv
++		;;
++	amiga | amiga-*)
++		basic_machine=m68k-unknown
++		;;
++	amigaos | amigados)
++		basic_machine=m68k-unknown
++		os=-amigaos
++		;;
++	amigaunix | amix)
++		basic_machine=m68k-unknown
++		os=-sysv4
++		;;
++	apollo68)
++		basic_machine=m68k-apollo
++		os=-sysv
++		;;
++	apollo68bsd)
++		basic_machine=m68k-apollo
++		os=-bsd
++		;;
++	aros)
++		basic_machine=i386-pc
++		os=-aros
++		;;
++	aux)
++		basic_machine=m68k-apple
++		os=-aux
++		;;
++	balance)
++		basic_machine=ns32k-sequent
++		os=-dynix
++		;;
++	blackfin)
++		basic_machine=bfin-unknown
++		os=-linux
++		;;
++	blackfin-*)
++		basic_machine=bfin-`echo $basic_machine | sed 's/^[^-]*-//'`
++		os=-linux
++		;;
++	bluegene*)
++		basic_machine=powerpc-ibm
++		os=-cnk
++		;;
++	c90)
++		basic_machine=c90-cray
++		os=-unicos
++		;;
++        cegcc)
++		basic_machine=arm-unknown
++		os=-cegcc
++		;;
++	convex-c1)
++		basic_machine=c1-convex
++		os=-bsd
++		;;
++	convex-c2)
++		basic_machine=c2-convex
++		os=-bsd
++		;;
++	convex-c32)
++		basic_machine=c32-convex
++		os=-bsd
++		;;
++	convex-c34)
++		basic_machine=c34-convex
++		os=-bsd
++		;;
++	convex-c38)
++		basic_machine=c38-convex
++		os=-bsd
++		;;
++	cray | j90)
++		basic_machine=j90-cray
++		os=-unicos
++		;;
++	craynv)
++		basic_machine=craynv-cray
++		os=-unicosmp
++		;;
++	cr16)
++		basic_machine=cr16-unknown
++		os=-elf
++		;;
++	crds | unos)
++		basic_machine=m68k-crds
++		;;
++	crisv32 | crisv32-* | etraxfs*)
++		basic_machine=crisv32-axis
++		;;
++	cris | cris-* | etrax*)
++		basic_machine=cris-axis
++		;;
++	crx)
++		basic_machine=crx-unknown
++		os=-elf
++		;;
++	da30 | da30-*)
++		basic_machine=m68k-da30
++		;;
++	decstation | decstation-3100 | pmax | pmax-* | pmin | dec3100 | decstatn)
++		basic_machine=mips-dec
++		;;
++	decsystem10* | dec10*)
++		basic_machine=pdp10-dec
++		os=-tops10
++		;;
++	decsystem20* | dec20*)
++		basic_machine=pdp10-dec
++		os=-tops20
++		;;
++	delta | 3300 | motorola-3300 | motorola-delta \
++	      | 3300-motorola | delta-motorola)
++		basic_machine=m68k-motorola
++		;;
++	delta88)
++		basic_machine=m88k-motorola
++		os=-sysv3
++		;;
++	dicos)
++		basic_machine=i686-pc
++		os=-dicos
++		;;
++	djgpp)
++		basic_machine=i586-pc
++		os=-msdosdjgpp
++		;;
++	dpx20 | dpx20-*)
++		basic_machine=rs6000-bull
++		os=-bosx
++		;;
++	dpx2* | dpx2*-bull)
++		basic_machine=m68k-bull
++		os=-sysv3
++		;;
++	ebmon29k)
++		basic_machine=a29k-amd
++		os=-ebmon
++		;;
++	elxsi)
++		basic_machine=elxsi-elxsi
++		os=-bsd
++		;;
++	encore | umax | mmax)
++		basic_machine=ns32k-encore
++		;;
++	es1800 | OSE68k | ose68k | ose | OSE)
++		basic_machine=m68k-ericsson
++		os=-ose
++		;;
++	fx2800)
++		basic_machine=i860-alliant
++		;;
++	genix)
++		basic_machine=ns32k-ns
++		;;
++	gmicro)
++		basic_machine=tron-gmicro
++		os=-sysv
++		;;
++	go32)
++		basic_machine=i386-pc
++		os=-go32
++		;;
++	h3050r* | hiux*)
++		basic_machine=hppa1.1-hitachi
++		os=-hiuxwe2
++		;;
++	h8300hms)
++		basic_machine=h8300-hitachi
++		os=-hms
++		;;
++	h8300xray)
++		basic_machine=h8300-hitachi
++		os=-xray
++		;;
++	h8500hms)
++		basic_machine=h8500-hitachi
++		os=-hms
++		;;
++	harris)
++		basic_machine=m88k-harris
++		os=-sysv3
++		;;
++	hp300-*)
++		basic_machine=m68k-hp
++		;;
++	hp300bsd)
++		basic_machine=m68k-hp
++		os=-bsd
++		;;
++	hp300hpux)
++		basic_machine=m68k-hp
++		os=-hpux
++		;;
++	hp3k9[0-9][0-9] | hp9[0-9][0-9])
++		basic_machine=hppa1.0-hp
++		;;
++	hp9k2[0-9][0-9] | hp9k31[0-9])
++		basic_machine=m68000-hp
++		;;
++	hp9k3[2-9][0-9])
++		basic_machine=m68k-hp
++		;;
++	hp9k6[0-9][0-9] | hp6[0-9][0-9])
++		basic_machine=hppa1.0-hp
++		;;
++	hp9k7[0-79][0-9] | hp7[0-79][0-9])
++		basic_machine=hppa1.1-hp
++		;;
++	hp9k78[0-9] | hp78[0-9])
++		# FIXME: really hppa2.0-hp
++		basic_machine=hppa1.1-hp
++		;;
++	hp9k8[67]1 | hp8[67]1 | hp9k80[24] | hp80[24] | hp9k8[78]9 | hp8[78]9 | hp9k893 | hp893)
++		# FIXME: really hppa2.0-hp
++		basic_machine=hppa1.1-hp
++		;;
++	hp9k8[0-9][13679] | hp8[0-9][13679])
++		basic_machine=hppa1.1-hp
++		;;
++	hp9k8[0-9][0-9] | hp8[0-9][0-9])
++		basic_machine=hppa1.0-hp
++		;;
++	hppa-next)
++		os=-nextstep3
++		;;
++	hppaosf)
++		basic_machine=hppa1.1-hp
++		os=-osf
++		;;
++	hppro)
++		basic_machine=hppa1.1-hp
++		os=-proelf
++		;;
++	i370-ibm* | ibm*)
++		basic_machine=i370-ibm
++		;;
++# I'm not sure what "Sysv32" means.  Should this be sysv3.2?
++	i*86v32)
++		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
++		os=-sysv32
++		;;
++	i*86v4*)
++		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
++		os=-sysv4
++		;;
++	i*86v)
++		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
++		os=-sysv
++		;;
++	i*86sol2)
++		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
++		os=-solaris2
++		;;
++	i386mach)
++		basic_machine=i386-mach
++		os=-mach
++		;;
++	i386-vsta | vsta)
++		basic_machine=i386-unknown
++		os=-vsta
++		;;
++	iris | iris4d)
++		basic_machine=mips-sgi
++		case $os in
++		    -irix*)
++			;;
++		    *)
++			os=-irix4
++			;;
++		esac
++		;;
++	isi68 | isi)
++		basic_machine=m68k-isi
++		os=-sysv
++		;;
++	m68knommu)
++		basic_machine=m68k-unknown
++		os=-linux
++		;;
++	m68knommu-*)
++		basic_machine=m68k-`echo $basic_machine | sed 's/^[^-]*-//'`
++		os=-linux
++		;;
++	m88k-omron*)
++		basic_machine=m88k-omron
++		;;
++	magnum | m3230)
++		basic_machine=mips-mips
++		os=-sysv
++		;;
++	merlin)
++		basic_machine=ns32k-utek
++		os=-sysv
++		;;
++        microblaze)
++		basic_machine=microblaze-xilinx
++		;;
++	mingw32)
++		basic_machine=i386-pc
++		os=-mingw32
++		;;
++	mingw32ce)
++		basic_machine=arm-unknown
++		os=-mingw32ce
++		;;
++	miniframe)
++		basic_machine=m68000-convergent
++		;;
++	*mint | -mint[0-9]* | *MiNT | *MiNT[0-9]*)
++		basic_machine=m68k-atari
++		os=-mint
++		;;
++	mips3*-*)
++		basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`
++		;;
++	mips3*)
++		basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`-unknown
++		;;
++	monitor)
++		basic_machine=m68k-rom68k
++		os=-coff
++		;;
++	morphos)
++		basic_machine=powerpc-unknown
++		os=-morphos
++		;;
++	msdos)
++		basic_machine=i386-pc
++		os=-msdos
++		;;
++	ms1-*)
++		basic_machine=`echo $basic_machine | sed -e 's/ms1-/mt-/'`
++		;;
++	mvs)
++		basic_machine=i370-ibm
++		os=-mvs
++		;;
++	ncr3000)
++		basic_machine=i486-ncr
++		os=-sysv4
++		;;
++	netbsd386)
++		basic_machine=i386-unknown
++		os=-netbsd
++		;;
++	netwinder)
++		basic_machine=armv4l-rebel
++		os=-linux
++		;;
++	news | news700 | news800 | news900)
++		basic_machine=m68k-sony
++		os=-newsos
++		;;
++	news1000)
++		basic_machine=m68030-sony
++		os=-newsos
++		;;
++	news-3600 | risc-news)
++		basic_machine=mips-sony
++		os=-newsos
++		;;
++	necv70)
++		basic_machine=v70-nec
++		os=-sysv
++		;;
++	next | m*-next )
++		basic_machine=m68k-next
++		case $os in
++		    -nextstep* )
++			;;
++		    -ns2*)
++		      os=-nextstep2
++			;;
++		    *)
++		      os=-nextstep3
++			;;
++		esac
++		;;
++	nh3000)
++		basic_machine=m68k-harris
++		os=-cxux
++		;;
++	nh[45]000)
++		basic_machine=m88k-harris
++		os=-cxux
++		;;
++	nindy960)
++		basic_machine=i960-intel
++		os=-nindy
++		;;
++	mon960)
++		basic_machine=i960-intel
++		os=-mon960
++		;;
++	nonstopux)
++		basic_machine=mips-compaq
++		os=-nonstopux
++		;;
++	np1)
++		basic_machine=np1-gould
++		;;
++	nsr-tandem)
++		basic_machine=nsr-tandem
++		;;
++	op50n-* | op60c-*)
++		basic_machine=hppa1.1-oki
++		os=-proelf
++		;;
++	openrisc | openrisc-*)
++		basic_machine=or32-unknown
++		;;
++	os400)
++		basic_machine=powerpc-ibm
++		os=-os400
++		;;
++	OSE68000 | ose68000)
++		basic_machine=m68000-ericsson
++		os=-ose
++		;;
++	os68k)
++		basic_machine=m68k-none
++		os=-os68k
++		;;
++	pa-hitachi)
++		basic_machine=hppa1.1-hitachi
++		os=-hiuxwe2
++		;;
++	paragon)
++		basic_machine=i860-intel
++		os=-osf
++		;;
++	parisc)
++		basic_machine=hppa-unknown
++		os=-linux
++		;;
++	parisc-*)
++		basic_machine=hppa-`echo $basic_machine | sed 's/^[^-]*-//'`
++		os=-linux
++		;;
++	pbd)
++		basic_machine=sparc-tti
++		;;
++	pbb)
++		basic_machine=m68k-tti
++		;;
++	pc532 | pc532-*)
++		basic_machine=ns32k-pc532
++		;;
++	pc98)
++		basic_machine=i386-pc
++		;;
++	pc98-*)
++		basic_machine=i386-`echo $basic_machine | sed 's/^[^-]*-//'`
++		;;
++	pentium | p5 | k5 | k6 | nexgen | viac3)
++		basic_machine=i586-pc
++		;;
++	pentiumpro | p6 | 6x86 | athlon | athlon_*)
++		basic_machine=i686-pc
++		;;
++	pentiumii | pentium2 | pentiumiii | pentium3)
++		basic_machine=i686-pc
++		;;
++	pentium4)
++		basic_machine=i786-pc
++		;;
++	pentium-* | p5-* | k5-* | k6-* | nexgen-* | viac3-*)
++		basic_machine=i586-`echo $basic_machine | sed 's/^[^-]*-//'`
++		;;
++	pentiumpro-* | p6-* | 6x86-* | athlon-*)
++		basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'`
++		;;
++	pentiumii-* | pentium2-* | pentiumiii-* | pentium3-*)
++		basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'`
++		;;
++	pentium4-*)
++		basic_machine=i786-`echo $basic_machine | sed 's/^[^-]*-//'`
++		;;
++	pn)
++		basic_machine=pn-gould
++		;;
++	power)	basic_machine=power-ibm
++		;;
++	ppc)	basic_machine=powerpc-unknown
++		;;
++	ppc-*)	basic_machine=powerpc-`echo $basic_machine | sed 's/^[^-]*-//'`
++		;;
++	ppcle | powerpclittle | ppc-le | powerpc-little)
++		basic_machine=powerpcle-unknown
++		;;
++	ppcle-* | powerpclittle-*)
++		basic_machine=powerpcle-`echo $basic_machine | sed 's/^[^-]*-//'`
++		;;
++	ppc64)	basic_machine=powerpc64-unknown
++		;;
++	ppc64-*) basic_machine=powerpc64-`echo $basic_machine | sed 's/^[^-]*-//'`
++		;;
++	ppc64le | powerpc64little | ppc64-le | powerpc64-little)
++		basic_machine=powerpc64le-unknown
++		;;
++	ppc64le-* | powerpc64little-*)
++		basic_machine=powerpc64le-`echo $basic_machine | sed 's/^[^-]*-//'`
++		;;
++	ps2)
++		basic_machine=i386-ibm
++		;;
++	pw32)
++		basic_machine=i586-unknown
++		os=-pw32
++		;;
++	rdos)
++		basic_machine=i386-pc
++		os=-rdos
++		;;
++	rom68k)
++		basic_machine=m68k-rom68k
++		os=-coff
++		;;
++	rm[46]00)
++		basic_machine=mips-siemens
++		;;
++	rtpc | rtpc-*)
++		basic_machine=romp-ibm
++		;;
++	s390 | s390-*)
++		basic_machine=s390-ibm
++		;;
++	s390x | s390x-*)
++		basic_machine=s390x-ibm
++		;;
++	sa29200)
++		basic_machine=a29k-amd
++		os=-udi
++		;;
++	sb1)
++		basic_machine=mipsisa64sb1-unknown
++		;;
++	sb1el)
++		basic_machine=mipsisa64sb1el-unknown
++		;;
++	sde)
++		basic_machine=mipsisa32-sde
++		os=-elf
++		;;
++	sei)
++		basic_machine=mips-sei
++		os=-seiux
++		;;
++	sequent)
++		basic_machine=i386-sequent
++		;;
++	sh)
++		basic_machine=sh-hitachi
++		os=-hms
++		;;
++	sh5el)
++		basic_machine=sh5le-unknown
++		;;
++	sh64)
++		basic_machine=sh64-unknown
++		;;
++	sparclite-wrs | simso-wrs)
++		basic_machine=sparclite-wrs
++		os=-vxworks
++		;;
++	sps7)
++		basic_machine=m68k-bull
++		os=-sysv2
++		;;
++	spur)
++		basic_machine=spur-unknown
++		;;
++	st2000)
++		basic_machine=m68k-tandem
++		;;
++	stratus)
++		basic_machine=i860-stratus
++		os=-sysv4
++		;;
++	sun2)
++		basic_machine=m68000-sun
++		;;
++	sun2os3)
++		basic_machine=m68000-sun
++		os=-sunos3
++		;;
++	sun2os4)
++		basic_machine=m68000-sun
++		os=-sunos4
++		;;
++	sun3os3)
++		basic_machine=m68k-sun
++		os=-sunos3
++		;;
++	sun3os4)
++		basic_machine=m68k-sun
++		os=-sunos4
++		;;
++	sun4os3)
++		basic_machine=sparc-sun
++		os=-sunos3
++		;;
++	sun4os4)
++		basic_machine=sparc-sun
++		os=-sunos4
++		;;
++	sun4sol2)
++		basic_machine=sparc-sun
++		os=-solaris2
++		;;
++	sun3 | sun3-*)
++		basic_machine=m68k-sun
++		;;
++	sun4)
++		basic_machine=sparc-sun
++		;;
++	sun386 | sun386i | roadrunner)
++		basic_machine=i386-sun
++		;;
++	sv1)
++		basic_machine=sv1-cray
++		os=-unicos
++		;;
++	symmetry)
++		basic_machine=i386-sequent
++		os=-dynix
++		;;
++	t3e)
++		basic_machine=alphaev5-cray
++		os=-unicos
++		;;
++	t90)
++		basic_machine=t90-cray
++		os=-unicos
++		;;
++	tic54x | c54x*)
++		basic_machine=tic54x-unknown
++		os=-coff
++		;;
++	tic55x | c55x*)
++		basic_machine=tic55x-unknown
++		os=-coff
++		;;
++	tic6x | c6x*)
++		basic_machine=tic6x-unknown
++		os=-coff
++		;;
++        # This must be matched before tile*.
++        tilegx*)
++		basic_machine=tilegx-unknown
++		os=-linux-gnu
++		;;
++	tile*)
++		basic_machine=tile-unknown
++		os=-linux-gnu
++		;;
++	tx39)
++		basic_machine=mipstx39-unknown
++		;;
++	tx39el)
++		basic_machine=mipstx39el-unknown
++		;;
++	toad1)
++		basic_machine=pdp10-xkl
++		os=-tops20
++		;;
++	tower | tower-32)
++		basic_machine=m68k-ncr
++		;;
++	tpf)
++		basic_machine=s390x-ibm
++		os=-tpf
++		;;
++	udi29k)
++		basic_machine=a29k-amd
++		os=-udi
++		;;
++	ultra3)
++		basic_machine=a29k-nyu
++		os=-sym1
++		;;
++	v810 | necv810)
++		basic_machine=v810-nec
++		os=-none
++		;;
++	vaxv)
++		basic_machine=vax-dec
++		os=-sysv
++		;;
++	vms)
++		basic_machine=vax-dec
++		os=-vms
++		;;
++	vpp*|vx|vx-*)
++		basic_machine=f301-fujitsu
++		;;
++	vxworks960)
++		basic_machine=i960-wrs
++		os=-vxworks
++		;;
++	vxworks68)
++		basic_machine=m68k-wrs
++		os=-vxworks
++		;;
++	vxworks29k)
++		basic_machine=a29k-wrs
++		os=-vxworks
++		;;
++	w65*)
++		basic_machine=w65-wdc
++		os=-none
++		;;
++	w89k-*)
++		basic_machine=hppa1.1-winbond
++		os=-proelf
++		;;
++	xbox)
++		basic_machine=i686-pc
++		os=-mingw32
++		;;
++	xps | xps100)
++		basic_machine=xps100-honeywell
++		;;
++	ymp)
++		basic_machine=ymp-cray
++		os=-unicos
++		;;
++	z8k-*-coff)
++		basic_machine=z8k-unknown
++		os=-sim
++		;;
++	z80-*-coff)
++		basic_machine=z80-unknown
++		os=-sim
++		;;
++	none)
++		basic_machine=none-none
++		os=-none
++		;;
++
++# Here we handle the default manufacturer of certain CPU types.  It is in
++# some cases the only manufacturer, in others, it is the most popular.
++	w89k)
++		basic_machine=hppa1.1-winbond
++		;;
++	op50n)
++		basic_machine=hppa1.1-oki
++		;;
++	op60c)
++		basic_machine=hppa1.1-oki
++		;;
++	romp)
++		basic_machine=romp-ibm
++		;;
++	mmix)
++		basic_machine=mmix-knuth
++		;;
++	rs6000)
++		basic_machine=rs6000-ibm
++		;;
++	vax)
++		basic_machine=vax-dec
++		;;
++	pdp10)
++		# there are many clones, so DEC is not a safe bet
++		basic_machine=pdp10-unknown
++		;;
++	pdp11)
++		basic_machine=pdp11-dec
++		;;
++	we32k)
++		basic_machine=we32k-att
++		;;
++	sh[1234] | sh[24]a | sh[24]aeb | sh[34]eb | sh[1234]le | sh[23]ele)
++		basic_machine=sh-unknown
++		;;
++	sparc | sparcv8 | sparcv9 | sparcv9b | sparcv9v)
++		basic_machine=sparc-sun
++		;;
++	cydra)
++		basic_machine=cydra-cydrome
++		;;
++	orion)
++		basic_machine=orion-highlevel
++		;;
++	orion105)
++		basic_machine=clipper-highlevel
++		;;
++	mac | mpw | mac-mpw)
++		basic_machine=m68k-apple
++		;;
++	pmac | pmac-mpw)
++		basic_machine=powerpc-apple
++		;;
++	*-unknown)
++		# Make sure to match an already-canonicalized machine name.
++		;;
++	*)
++		echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2
++		exit 1
++		;;
++esac
++
++# Here we canonicalize certain aliases for manufacturers.
++case $basic_machine in
++	*-digital*)
++		basic_machine=`echo $basic_machine | sed 's/digital.*/dec/'`
++		;;
++	*-commodore*)
++		basic_machine=`echo $basic_machine | sed 's/commodore.*/cbm/'`
++		;;
++	*)
++		;;
++esac
++
++# Decode manufacturer-specific aliases for certain operating systems.
++
++if [ x"$os" != x"" ]
++then
++case $os in
++        # First match some system type aliases
++        # that might get confused with valid system types.
++	# -solaris* is a basic system type, with this one exception.
++        -auroraux)
++	        os=-auroraux
++		;;
++	-solaris1 | -solaris1.*)
++		os=`echo $os | sed -e 's|solaris1|sunos4|'`
++		;;
++	-solaris)
++		os=-solaris2
++		;;
++	-svr4*)
++		os=-sysv4
++		;;
++	-unixware*)
++		os=-sysv4.2uw
++		;;
++	-gnu/linux*)
++		os=`echo $os | sed -e 's|gnu/linux|linux-gnu|'`
++		;;
++	# First accept the basic system types.
++	# The portable systems comes first.
++	# Each alternative MUST END IN A *, to match a version number.
++	# -sysv* is not here because it comes later, after sysvr4.
++	-gnu* | -bsd* | -mach* | -minix* | -genix* | -ultrix* | -irix* \
++	      | -*vms* | -sco* | -esix* | -isc* | -aix* | -cnk* | -sunos | -sunos[34]*\
++	      | -hpux* | -unos* | -osf* | -luna* | -dgux* | -auroraux* | -solaris* \
++	      | -sym* | -kopensolaris* \
++	      | -amigaos* | -amigados* | -msdos* | -newsos* | -unicos* | -aof* \
++	      | -aos* | -aros* \
++	      | -nindy* | -vxsim* | -vxworks* | -ebmon* | -hms* | -mvs* \
++	      | -clix* | -riscos* | -uniplus* | -iris* | -rtu* | -xenix* \
++	      | -hiux* | -386bsd* | -knetbsd* | -mirbsd* | -netbsd* \
++	      | -openbsd* | -solidbsd* \
++	      | -ekkobsd* | -kfreebsd* | -freebsd* | -riscix* | -lynxos* \
++	      | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \
++	      | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \
++	      | -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \
++	      | -chorusos* | -chorusrdb* | -cegcc* \
++	      | -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \
++	      | -mingw32* | -linux-gnu* | -linux-newlib* | -linux-uclibc* \
++	      | -uxpv* | -beos* | -mpeix* | -udk* \
++	      | -interix* | -uwin* | -mks* | -rhapsody* | -darwin* | -opened* \
++	      | -openstep* | -oskit* | -conix* | -pw32* | -nonstopux* \
++	      | -storm-chaos* | -tops10* | -tenex* | -tops20* | -its* \
++	      | -os2* | -vos* | -palmos* | -uclinux* | -nucleus* \
++	      | -morphos* | -superux* | -rtmk* | -rtmk-nova* | -windiss* \
++	      | -powermax* | -dnix* | -nx6 | -nx7 | -sei* | -dragonfly* \
++	      | -skyos* | -haiku* | -rdos* | -toppers* | -drops* | -es*)
++	# Remember, each alternative MUST END IN *, to match a version number.
++		;;
++	-qnx*)
++		case $basic_machine in
++		    x86-* | i*86-*)
++			;;
++		    *)
++			os=-nto$os
++			;;
++		esac
++		;;
++	-nto-qnx*)
++		;;
++	-nto*)
++		os=`echo $os | sed -e 's|nto|nto-qnx|'`
++		;;
++	-sim | -es1800* | -hms* | -xray | -os68k* | -none* | -v88r* \
++	      | -windows* | -osx | -abug | -netware* | -os9* | -beos* | -haiku* \
++	      | -macos* | -mpw* | -magic* | -mmixware* | -mon960* | -lnews*)
++		;;
++	-mac*)
++		os=`echo $os | sed -e 's|mac|macos|'`
++		;;
++	-linux-dietlibc)
++		os=-linux-dietlibc
++		;;
++	-linux*)
++		os=`echo $os | sed -e 's|linux|linux-gnu|'`
++		;;
++	-sunos5*)
++		os=`echo $os | sed -e 's|sunos5|solaris2|'`
++		;;
++	-sunos6*)
++		os=`echo $os | sed -e 's|sunos6|solaris3|'`
++		;;
++	-opened*)
++		os=-openedition
++		;;
++        -os400*)
++		os=-os400
++		;;
++	-wince*)
++		os=-wince
++		;;
++	-osfrose*)
++		os=-osfrose
++		;;
++	-osf*)
++		os=-osf
++		;;
++	-utek*)
++		os=-bsd
++		;;
++	-dynix*)
++		os=-bsd
++		;;
++	-acis*)
++		os=-aos
++		;;
++	-atheos*)
++		os=-atheos
++		;;
++	-syllable*)
++		os=-syllable
++		;;
++	-386bsd)
++		os=-bsd
++		;;
++	-ctix* | -uts*)
++		os=-sysv
++		;;
++	-nova*)
++		os=-rtmk-nova
++		;;
++	-ns2 )
++		os=-nextstep2
++		;;
++	-nsk*)
++		os=-nsk
++		;;
++	# Preserve the version number of sinix5.
++	-sinix5.*)
++		os=`echo $os | sed -e 's|sinix|sysv|'`
++		;;
++	-sinix*)
++		os=-sysv4
++		;;
++        -tpf*)
++		os=-tpf
++		;;
++	-triton*)
++		os=-sysv3
++		;;
++	-oss*)
++		os=-sysv3
++		;;
++	-svr4)
++		os=-sysv4
++		;;
++	-svr3)
++		os=-sysv3
++		;;
++	-sysvr4)
++		os=-sysv4
++		;;
++	# This must come after -sysvr4.
++	-sysv*)
++		;;
++	-ose*)
++		os=-ose
++		;;
++	-es1800*)
++		os=-ose
++		;;
++	-xenix)
++		os=-xenix
++		;;
++	-*mint | -mint[0-9]* | -*MiNT | -MiNT[0-9]*)
++		os=-mint
++		;;
++	-aros*)
++		os=-aros
++		;;
++	-kaos*)
++		os=-kaos
++		;;
++	-zvmoe)
++		os=-zvmoe
++		;;
++	-dicos*)
++		os=-dicos
++		;;
++        -nacl*)
++	        ;;
++	-none)
++		;;
++	*)
++		# Get rid of the `-' at the beginning of $os.
++		os=`echo $os | sed 's/[^-]*-//'`
++		echo Invalid configuration \`$1\': system \`$os\' not recognized 1>&2
++		exit 1
++		;;
++esac
++else
++
++# Here we handle the default operating systems that come with various machines.
++# The value should be what the vendor currently ships out the door with their
++# machine or put another way, the most popular os provided with the machine.
++
++# Note that if you're going to try to match "-MANUFACTURER" here (say,
++# "-sun"), then you have to tell the case statement up towards the top
++# that MANUFACTURER isn't an operating system.  Otherwise, code above
++# will signal an error saying that MANUFACTURER isn't an operating
++# system, and we'll never get to this point.
++
++case $basic_machine in
++        score-*)
++		os=-elf
++		;;
++        spu-*)
++		os=-elf
++		;;
++	*-acorn)
++		os=-riscix1.2
++		;;
++	arm*-rebel)
++		os=-linux
++		;;
++	arm*-semi)
++		os=-aout
++		;;
++        c4x-* | tic4x-*)
++        	os=-coff
++		;;
++	# This must come before the *-dec entry.
++	pdp10-*)
++		os=-tops20
++		;;
++	pdp11-*)
++		os=-none
++		;;
++	*-dec | vax-*)
++		os=-ultrix4.2
++		;;
++	m68*-apollo)
++		os=-domain
++		;;
++	i386-sun)
++		os=-sunos4.0.2
++		;;
++	m68000-sun)
++		os=-sunos3
++		# This also exists in the configure program, but was not the
++		# default.
++		# os=-sunos4
++		;;
++	m68*-cisco)
++		os=-aout
++		;;
++        mep-*)
++		os=-elf
++		;;
++	mips*-cisco)
++		os=-elf
++		;;
++	mips*-*)
++		os=-elf
++		;;
++	or32-*)
++		os=-coff
++		;;
++	*-tti)	# must be before sparc entry or we get the wrong os.
++		os=-sysv3
++		;;
++	sparc-* | *-sun)
++		os=-sunos4.1.1
++		;;
++	*-be)
++		os=-beos
++		;;
++	*-haiku)
++		os=-haiku
++		;;
++	*-ibm)
++		os=-aix
++		;;
++    	*-knuth)
++		os=-mmixware
++		;;
++	*-wec)
++		os=-proelf
++		;;
++	*-winbond)
++		os=-proelf
++		;;
++	*-oki)
++		os=-proelf
++		;;
++	*-hp)
++		os=-hpux
++		;;
++	*-hitachi)
++		os=-hiux
++		;;
++	i860-* | *-att | *-ncr | *-altos | *-motorola | *-convergent)
++		os=-sysv
++		;;
++	*-cbm)
++		os=-amigaos
++		;;
++	*-dg)
++		os=-dgux
++		;;
++	*-dolphin)
++		os=-sysv3
++		;;
++	m68k-ccur)
++		os=-rtu
++		;;
++	m88k-omron*)
++		os=-luna
++		;;
++	*-next )
++		os=-nextstep
++		;;
++	*-sequent)
++		os=-ptx
++		;;
++	*-crds)
++		os=-unos
++		;;
++	*-ns)
++		os=-genix
++		;;
++	i370-*)
++		os=-mvs
++		;;
++	*-next)
++		os=-nextstep3
++		;;
++	*-gould)
++		os=-sysv
++		;;
++	*-highlevel)
++		os=-bsd
++		;;
++	*-encore)
++		os=-bsd
++		;;
++	*-sgi)
++		os=-irix
++		;;
++	*-siemens)
++		os=-sysv4
++		;;
++	*-masscomp)
++		os=-rtu
++		;;
++	f30[01]-fujitsu | f700-fujitsu)
++		os=-uxpv
++		;;
++	*-rom68k)
++		os=-coff
++		;;
++	*-*bug)
++		os=-coff
++		;;
++	*-apple)
++		os=-macos
++		;;
++	*-atari*)
++		os=-mint
++		;;
++	*)
++		os=-none
++		;;
++esac
++fi
++
++# Here we handle the case where we know the os, and the CPU type, but not the
++# manufacturer.  We pick the logical manufacturer.
++vendor=unknown
++case $basic_machine in
++	*-unknown)
++		case $os in
++			-riscix*)
++				vendor=acorn
++				;;
++			-sunos*)
++				vendor=sun
++				;;
++			-cnk*|-aix*)
++				vendor=ibm
++				;;
++			-beos*)
++				vendor=be
++				;;
++			-hpux*)
++				vendor=hp
++				;;
++			-mpeix*)
++				vendor=hp
++				;;
++			-hiux*)
++				vendor=hitachi
++				;;
++			-unos*)
++				vendor=crds
++				;;
++			-dgux*)
++				vendor=dg
++				;;
++			-luna*)
++				vendor=omron
++				;;
++			-genix*)
++				vendor=ns
++				;;
++			-mvs* | -opened*)
++				vendor=ibm
++				;;
++			-os400*)
++				vendor=ibm
++				;;
++			-ptx*)
++				vendor=sequent
++				;;
++			-tpf*)
++				vendor=ibm
++				;;
++			-vxsim* | -vxworks* | -windiss*)
++				vendor=wrs
++				;;
++			-aux*)
++				vendor=apple
++				;;
++			-hms*)
++				vendor=hitachi
++				;;
++			-mpw* | -macos*)
++				vendor=apple
++				;;
++			-*mint | -mint[0-9]* | -*MiNT | -MiNT[0-9]*)
++				vendor=atari
++				;;
++			-vos*)
++				vendor=stratus
++				;;
++		esac
++		basic_machine=`echo $basic_machine | sed "s/unknown/$vendor/"`
++		;;
++esac
++
++echo $basic_machine$os
++exit
++
++# Local variables:
++# eval: (add-hook 'write-file-hooks 'time-stamp)
++# time-stamp-start: "timestamp='"
++# time-stamp-format: "%:y-%02m-%02d"
++# time-stamp-end: "'"
++# End:
+Index: git/configure
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/configure	2010-12-29 04:06:34.595000498 +0100
+@@ -0,0 +1,30164 @@
++#! /bin/sh
++# From configure.ac Revision.
++# Guess values for system-dependent variables and create Makefiles.
++# Generated by GNU Autoconf 2.67 for Heimdal 1.4.99.
++#
++# Report bugs to <heimdal-bugs@h5l.org>.
++#
++#
++# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001,
++# 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
++# Foundation, Inc.
++#
++#
++# This configure script is free software; the Free Software Foundation
++# gives unlimited permission to copy, distribute and modify it.
++## -------------------- ##
++## M4sh Initialization. ##
++## -------------------- ##
++
++# Be more Bourne compatible
++DUALCASE=1; export DUALCASE # for MKS sh
++if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then :
++  emulate sh
++  NULLCMD=:
++  # Pre-4.2 versions of Zsh do word splitting on ${1+"$@"}, which
++  # is contrary to our usage.  Disable this feature.
++  alias -g '${1+"$@"}'='"$@"'
++  setopt NO_GLOB_SUBST
++else
++  case `(set -o) 2>/dev/null` in #(
++  *posix*) :
++    set -o posix ;; #(
++  *) :
++     ;;
++esac
++fi
++
++
++as_nl='
++'
++export as_nl
++# Printing a long string crashes Solaris 7 /usr/bin/printf.
++as_echo='\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'
++as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo
++as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo$as_echo
++# Prefer a ksh shell builtin over an external printf program on Solaris,
++# but without wasting forks for bash or zsh.
++if test -z "$BASH_VERSION$ZSH_VERSION" \
++    && (test "X`print -r -- $as_echo`" = "X$as_echo") 2>/dev/null; then
++  as_echo='print -r --'
++  as_echo_n='print -rn --'
++elif (test "X`printf %s $as_echo`" = "X$as_echo") 2>/dev/null; then
++  as_echo='printf %s\n'
++  as_echo_n='printf %s'
++else
++  if test "X`(/usr/ucb/echo -n -n $as_echo) 2>/dev/null`" = "X-n $as_echo"; then
++    as_echo_body='eval /usr/ucb/echo -n "$1$as_nl"'
++    as_echo_n='/usr/ucb/echo -n'
++  else
++    as_echo_body='eval expr "X$1" : "X\\(.*\\)"'
++    as_echo_n_body='eval
++      arg=$1;
++      case $arg in #(
++      *"$as_nl"*)
++	expr "X$arg" : "X\\(.*\\)$as_nl";
++	arg=`expr "X$arg" : ".*$as_nl\\(.*\\)"`;;
++      esac;
++      expr "X$arg" : "X\\(.*\\)" | tr -d "$as_nl"
++    '
++    export as_echo_n_body
++    as_echo_n='sh -c $as_echo_n_body as_echo'
++  fi
++  export as_echo_body
++  as_echo='sh -c $as_echo_body as_echo'
++fi
++
++# The user is always right.
++if test "${PATH_SEPARATOR+set}" != set; then
++  PATH_SEPARATOR=:
++  (PATH='/bin;/bin'; FPATH=$PATH; sh -c :) >/dev/null 2>&1 && {
++    (PATH='/bin:/bin'; FPATH=$PATH; sh -c :) >/dev/null 2>&1 ||
++      PATH_SEPARATOR=';'
++  }
++fi
++
++
++# IFS
++# We need space, tab and new line, in precisely that order.  Quoting is
++# there to prevent editors from complaining about space-tab.
++# (If _AS_PATH_WALK were called with IFS unset, it would disable word
++# splitting by setting IFS to empty value.)
++IFS=" ""	$as_nl"
++
++# Find who we are.  Look in the path if we contain no directory separator.
++case $0 in #((
++  *[\\/]* ) as_myself=$0 ;;
++  *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    test -r "$as_dir/$0" && as_myself=$as_dir/$0 && break
++  done
++IFS=$as_save_IFS
++
++     ;;
++esac
++# We did not find ourselves, most probably we were run as `sh COMMAND'
++# in which case we are not to be found in the path.
++if test "x$as_myself" = x; then
++  as_myself=$0
++fi
++if test ! -f "$as_myself"; then
++  $as_echo "$as_myself: error: cannot find myself; rerun with an absolute file name" >&2
++  exit 1
++fi
++
++# Unset variables that we do not need and which cause bugs (e.g. in
++# pre-3.0 UWIN ksh).  But do not cause bugs in bash 2.01; the "|| exit 1"
++# suppresses any "Segmentation fault" message there.  '((' could
++# trigger a bug in pdksh 5.2.14.
++for as_var in BASH_ENV ENV MAIL MAILPATH
++do eval test x\${$as_var+set} = xset \
++  && ( (unset $as_var) || exit 1) >/dev/null 2>&1 && unset $as_var || :
++done
++PS1='$ '
++PS2='> '
++PS4='+ '
++
++# NLS nuisances.
++LC_ALL=C
++export LC_ALL
++LANGUAGE=C
++export LANGUAGE
++
++# CDPATH.
++(unset CDPATH) >/dev/null 2>&1 && unset CDPATH
++
++if test "x$CONFIG_SHELL" = x; then
++  as_bourne_compatible="if test -n \"\${ZSH_VERSION+set}\" && (emulate sh) >/dev/null 2>&1; then :
++  emulate sh
++  NULLCMD=:
++  # Pre-4.2 versions of Zsh do word splitting on \${1+\"\$@\"}, which
++  # is contrary to our usage.  Disable this feature.
++  alias -g '\${1+\"\$@\"}'='\"\$@\"'
++  setopt NO_GLOB_SUBST
++else
++  case \`(set -o) 2>/dev/null\` in #(
++  *posix*) :
++    set -o posix ;; #(
++  *) :
++     ;;
++esac
++fi
++"
++  as_required="as_fn_return () { (exit \$1); }
++as_fn_success () { as_fn_return 0; }
++as_fn_failure () { as_fn_return 1; }
++as_fn_ret_success () { return 0; }
++as_fn_ret_failure () { return 1; }
++
++exitcode=0
++as_fn_success || { exitcode=1; echo as_fn_success failed.; }
++as_fn_failure && { exitcode=1; echo as_fn_failure succeeded.; }
++as_fn_ret_success || { exitcode=1; echo as_fn_ret_success failed.; }
++as_fn_ret_failure && { exitcode=1; echo as_fn_ret_failure succeeded.; }
++if ( set x; as_fn_ret_success y && test x = \"\$1\" ); then :
++
++else
++  exitcode=1; echo positional parameters were not saved.
++fi
++test x\$exitcode = x0 || exit 1"
++  as_suggested="  as_lineno_1=";as_suggested=$as_suggested$LINENO;as_suggested=$as_suggested" as_lineno_1a=\$LINENO
++  as_lineno_2=";as_suggested=$as_suggested$LINENO;as_suggested=$as_suggested" as_lineno_2a=\$LINENO
++  eval 'test \"x\$as_lineno_1'\$as_run'\" != \"x\$as_lineno_2'\$as_run'\" &&
++  test \"x\`expr \$as_lineno_1'\$as_run' + 1\`\" = \"x\$as_lineno_2'\$as_run'\"' || exit 1
++test \$(( 1 + 1 )) = 2 || exit 1"
++  if (eval "$as_required") 2>/dev/null; then :
++  as_have_required=yes
++else
++  as_have_required=no
++fi
++  if test x$as_have_required = xyes && (eval "$as_suggested") 2>/dev/null; then :
++
++else
++  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++as_found=false
++for as_dir in /bin$PATH_SEPARATOR/usr/bin$PATH_SEPARATOR$PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++  as_found=:
++  case $as_dir in #(
++	 /*)
++	   for as_base in sh bash ksh sh5; do
++	     # Try only shells that exist, to save several forks.
++	     as_shell=$as_dir/$as_base
++	     if { test -f "$as_shell" || test -f "$as_shell.exe"; } &&
++		    { $as_echo "$as_bourne_compatible""$as_required" | as_run=a "$as_shell"; } 2>/dev/null; then :
++  CONFIG_SHELL=$as_shell as_have_required=yes
++		   if { $as_echo "$as_bourne_compatible""$as_suggested" | as_run=a "$as_shell"; } 2>/dev/null; then :
++  break 2
++fi
++fi
++	   done;;
++       esac
++  as_found=false
++done
++$as_found || { if { test -f "$SHELL" || test -f "$SHELL.exe"; } &&
++	      { $as_echo "$as_bourne_compatible""$as_required" | as_run=a "$SHELL"; } 2>/dev/null; then :
++  CONFIG_SHELL=$SHELL as_have_required=yes
++fi; }
++IFS=$as_save_IFS
++
++
++      if test "x$CONFIG_SHELL" != x; then :
++  # We cannot yet assume a decent shell, so we have to provide a
++	# neutralization value for shells without unset; and this also
++	# works around shells that cannot unset nonexistent variables.
++	BASH_ENV=/dev/null
++	ENV=/dev/null
++	(unset BASH_ENV) >/dev/null 2>&1 && unset BASH_ENV ENV
++	export CONFIG_SHELL
++	exec "$CONFIG_SHELL" "$as_myself" ${1+"$@"}
++fi
++
++    if test x$as_have_required = xno; then :
++  $as_echo "$0: This script requires a shell more modern than all"
++  $as_echo "$0: the shells that I found on your system."
++  if test x${ZSH_VERSION+set} = xset ; then
++    $as_echo "$0: In particular, zsh $ZSH_VERSION has bugs and should"
++    $as_echo "$0: be upgraded to zsh 4.3.4 or later."
++  else
++    $as_echo "$0: Please tell bug-autoconf@gnu.org and
++$0: heimdal-bugs@h5l.org about your system, including any
++$0: error possibly output before this message. Then install
++$0: a modern shell, or manually run the script under such a
++$0: shell if you do have one."
++  fi
++  exit 1
++fi
++fi
++fi
++SHELL=${CONFIG_SHELL-/bin/sh}
++export SHELL
++# Unset more variables known to interfere with behavior of common tools.
++CLICOLOR_FORCE= GREP_OPTIONS=
++unset CLICOLOR_FORCE GREP_OPTIONS
++
++## --------------------- ##
++## M4sh Shell Functions. ##
++## --------------------- ##
++# as_fn_unset VAR
++# ---------------
++# Portably unset VAR.
++as_fn_unset ()
++{
++  { eval $1=; unset $1;}
++}
++as_unset=as_fn_unset
++
++# as_fn_set_status STATUS
++# -----------------------
++# Set $? to STATUS, without forking.
++as_fn_set_status ()
++{
++  return $1
++} # as_fn_set_status
++
++# as_fn_exit STATUS
++# -----------------
++# Exit the shell with STATUS, even in a "trap 0" or "set -e" context.
++as_fn_exit ()
++{
++  set +e
++  as_fn_set_status $1
++  exit $1
++} # as_fn_exit
++
++# as_fn_mkdir_p
++# -------------
++# Create "$as_dir" as a directory, including parents if necessary.
++as_fn_mkdir_p ()
++{
++
++  case $as_dir in #(
++  -*) as_dir=./$as_dir;;
++  esac
++  test -d "$as_dir" || eval $as_mkdir_p || {
++    as_dirs=
++    while :; do
++      case $as_dir in #(
++      *\'*) as_qdir=`$as_echo "$as_dir" | sed "s/'/'\\\\\\\\''/g"`;; #'(
++      *) as_qdir=$as_dir;;
++      esac
++      as_dirs="'$as_qdir' $as_dirs"
++      as_dir=`$as_dirname -- "$as_dir" ||
++$as_expr X"$as_dir" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
++	 X"$as_dir" : 'X\(//\)[^/]' \| \
++	 X"$as_dir" : 'X\(//\)$' \| \
++	 X"$as_dir" : 'X\(/\)' \| . 2>/dev/null ||
++$as_echo X"$as_dir" |
++    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\/\)[^/].*/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\/\)$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\).*/{
++	    s//\1/
++	    q
++	  }
++	  s/.*/./; q'`
++      test -d "$as_dir" && break
++    done
++    test -z "$as_dirs" || eval "mkdir $as_dirs"
++  } || test -d "$as_dir" || as_fn_error $? "cannot create directory $as_dir"
++
++
++} # as_fn_mkdir_p
++# as_fn_append VAR VALUE
++# ----------------------
++# Append the text in VALUE to the end of the definition contained in VAR. Take
++# advantage of any shell optimizations that allow amortized linear growth over
++# repeated appends, instead of the typical quadratic growth present in naive
++# implementations.
++if (eval "as_var=1; as_var+=2; test x\$as_var = x12") 2>/dev/null; then :
++  eval 'as_fn_append ()
++  {
++    eval $1+=\$2
++  }'
++else
++  as_fn_append ()
++  {
++    eval $1=\$$1\$2
++  }
++fi # as_fn_append
++
++# as_fn_arith ARG...
++# ------------------
++# Perform arithmetic evaluation on the ARGs, and store the result in the
++# global $as_val. Take advantage of shells that can avoid forks. The arguments
++# must be portable across $(()) and expr.
++if (eval "test \$(( 1 + 1 )) = 2") 2>/dev/null; then :
++  eval 'as_fn_arith ()
++  {
++    as_val=$(( $* ))
++  }'
++else
++  as_fn_arith ()
++  {
++    as_val=`expr "$@" || test $? -eq 1`
++  }
++fi # as_fn_arith
++
++
++# as_fn_error STATUS ERROR [LINENO LOG_FD]
++# ----------------------------------------
++# Output "`basename $0`: error: ERROR" to stderr. If LINENO and LOG_FD are
++# provided, also output the error to LOG_FD, referencing LINENO. Then exit the
++# script with STATUS, using 1 if that was 0.
++as_fn_error ()
++{
++  as_status=$1; test $as_status -eq 0 && as_status=1
++  if test "$4"; then
++    as_lineno=${as_lineno-"$3"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
++    $as_echo "$as_me:${as_lineno-$LINENO}: error: $2" >&$4
++  fi
++  $as_echo "$as_me: error: $2" >&2
++  as_fn_exit $as_status
++} # as_fn_error
++
++if expr a : '\(a\)' >/dev/null 2>&1 &&
++   test "X`expr 00001 : '.*\(...\)'`" = X001; then
++  as_expr=expr
++else
++  as_expr=false
++fi
++
++if (basename -- /) >/dev/null 2>&1 && test "X`basename -- / 2>&1`" = "X/"; then
++  as_basename=basename
++else
++  as_basename=false
++fi
++
++if (as_dir=`dirname -- /` && test "X$as_dir" = X/) >/dev/null 2>&1; then
++  as_dirname=dirname
++else
++  as_dirname=false
++fi
++
++as_me=`$as_basename -- "$0" ||
++$as_expr X/"$0" : '.*/\([^/][^/]*\)/*$' \| \
++	 X"$0" : 'X\(//\)$' \| \
++	 X"$0" : 'X\(/\)' \| . 2>/dev/null ||
++$as_echo X/"$0" |
++    sed '/^.*\/\([^/][^/]*\)\/*$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\/\(\/\/\)$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\/\(\/\).*/{
++	    s//\1/
++	    q
++	  }
++	  s/.*/./; q'`
++
++# Avoid depending upon Character Ranges.
++as_cr_letters='abcdefghijklmnopqrstuvwxyz'
++as_cr_LETTERS='ABCDEFGHIJKLMNOPQRSTUVWXYZ'
++as_cr_Letters=$as_cr_letters$as_cr_LETTERS
++as_cr_digits='0123456789'
++as_cr_alnum=$as_cr_Letters$as_cr_digits
++
++
++  as_lineno_1=$LINENO as_lineno_1a=$LINENO
++  as_lineno_2=$LINENO as_lineno_2a=$LINENO
++  eval 'test "x$as_lineno_1'$as_run'" != "x$as_lineno_2'$as_run'" &&
++  test "x`expr $as_lineno_1'$as_run' + 1`" = "x$as_lineno_2'$as_run'"' || {
++  # Blame Lee E. McMahon (1931-1989) for sed's syntax.  :-)
++  sed -n '
++    p
++    /[$]LINENO/=
++  ' <$as_myself |
++    sed '
++      s/[$]LINENO.*/&-/
++      t lineno
++      b
++      :lineno
++      N
++      :loop
++      s/[$]LINENO\([^'$as_cr_alnum'_].*\n\)\(.*\)/\2\1\2/
++      t loop
++      s/-\n.*//
++    ' >$as_me.lineno &&
++  chmod +x "$as_me.lineno" ||
++    { $as_echo "$as_me: error: cannot create $as_me.lineno; rerun with a POSIX shell" >&2; as_fn_exit 1; }
++
++  # Don't try to exec as it changes $[0], causing all sort of problems
++  # (the dirname of $[0] is not the place where we might find the
++  # original and so on.  Autoconf is especially sensitive to this).
++  . "./$as_me.lineno"
++  # Exit status is that of the last command.
++  exit
++}
++
++ECHO_C= ECHO_N= ECHO_T=
++case `echo -n x` in #(((((
++-n*)
++  case `echo 'xy\c'` in
++  *c*) ECHO_T='	';;	# ECHO_T is single tab character.
++  xy)  ECHO_C='\c';;
++  *)   echo `echo ksh88 bug on AIX 6.1` > /dev/null
++       ECHO_T='	';;
++  esac;;
++*)
++  ECHO_N='-n';;
++esac
++
++rm -f conf$$ conf$$.exe conf$$.file
++if test -d conf$$.dir; then
++  rm -f conf$$.dir/conf$$.file
++else
++  rm -f conf$$.dir
++  mkdir conf$$.dir 2>/dev/null
++fi
++if (echo >conf$$.file) 2>/dev/null; then
++  if ln -s conf$$.file conf$$ 2>/dev/null; then
++    as_ln_s='ln -s'
++    # ... but there are two gotchas:
++    # 1) On MSYS, both `ln -s file dir' and `ln file dir' fail.
++    # 2) DJGPP < 2.04 has no symlinks; `ln -s' creates a wrapper executable.
++    # In both cases, we have to default to `cp -p'.
++    ln -s conf$$.file conf$$.dir 2>/dev/null && test ! -f conf$$.exe ||
++      as_ln_s='cp -p'
++  elif ln conf$$.file conf$$ 2>/dev/null; then
++    as_ln_s=ln
++  else
++    as_ln_s='cp -p'
++  fi
++else
++  as_ln_s='cp -p'
++fi
++rm -f conf$$ conf$$.exe conf$$.dir/conf$$.file conf$$.file
++rmdir conf$$.dir 2>/dev/null
++
++if mkdir -p . 2>/dev/null; then
++  as_mkdir_p='mkdir -p "$as_dir"'
++else
++  test -d ./-p && rmdir ./-p
++  as_mkdir_p=false
++fi
++
++if test -x / >/dev/null 2>&1; then
++  as_test_x='test -x'
++else
++  if ls -dL / >/dev/null 2>&1; then
++    as_ls_L_option=L
++  else
++    as_ls_L_option=
++  fi
++  as_test_x='
++    eval sh -c '\''
++      if test -d "$1"; then
++	test -d "$1/.";
++      else
++	case $1 in #(
++	-*)set "./$1";;
++	esac;
++	case `ls -ld'$as_ls_L_option' "$1" 2>/dev/null` in #((
++	???[sx]*):;;*)false;;esac;fi
++    '\'' sh
++  '
++fi
++as_executable_p=$as_test_x
++
++# Sed expression to map a string onto a valid CPP name.
++as_tr_cpp="eval sed 'y%*$as_cr_letters%P$as_cr_LETTERS%;s%[^_$as_cr_alnum]%_%g'"
++
++# Sed expression to map a string onto a valid variable name.
++as_tr_sh="eval sed 'y%*+%pp%;s%[^_$as_cr_alnum]%_%g'"
++
++
++
++# Check that we are running under the correct shell.
++SHELL=${CONFIG_SHELL-/bin/sh}
++
++case X$lt_ECHO in
++X*--fallback-echo)
++  # Remove one level of quotation (which was required for Make).
++  ECHO=`echo "$lt_ECHO" | sed 's,\\\\\$\\$0,'$0','`
++  ;;
++esac
++
++ECHO=${lt_ECHO-echo}
++if test "X$1" = X--no-reexec; then
++  # Discard the --no-reexec flag, and continue.
++  shift
++elif test "X$1" = X--fallback-echo; then
++  # Avoid inline document here, it may be left over
++  :
++elif test "X`{ $ECHO '\t'; } 2>/dev/null`" = 'X\t' ; then
++  # Yippee, $ECHO works!
++  :
++else
++  # Restart under the correct shell.
++  exec $SHELL "$0" --no-reexec ${1+"$@"}
++fi
++
++if test "X$1" = X--fallback-echo; then
++  # used as fallback echo
++  shift
++  cat <<_LT_EOF
++$*
++_LT_EOF
++  exit 0
++fi
++
++# The HP-UX ksh and POSIX shell print the target directory to stdout
++# if CDPATH is set.
++(unset CDPATH) >/dev/null 2>&1 && unset CDPATH
++
++if test -z "$lt_ECHO"; then
++  if test "X${echo_test_string+set}" != Xset; then
++    # find a string as large as possible, as long as the shell can cope with it
++    for cmd in 'sed 50q "$0"' 'sed 20q "$0"' 'sed 10q "$0"' 'sed 2q "$0"' 'echo test'; do
++      # expected sizes: less than 2Kb, 1Kb, 512 bytes, 16 bytes, ...
++      if { echo_test_string=`eval $cmd`; } 2>/dev/null &&
++	 { test "X$echo_test_string" = "X$echo_test_string"; } 2>/dev/null
++      then
++        break
++      fi
++    done
++  fi
++
++  if test "X`{ $ECHO '\t'; } 2>/dev/null`" = 'X\t' &&
++     echo_testing_string=`{ $ECHO "$echo_test_string"; } 2>/dev/null` &&
++     test "X$echo_testing_string" = "X$echo_test_string"; then
++    :
++  else
++    # The Solaris, AIX, and Digital Unix default echo programs unquote
++    # backslashes.  This makes it impossible to quote backslashes using
++    #   echo "$something" | sed 's/\\/\\\\/g'
++    #
++    # So, first we look for a working echo in the user's PATH.
++
++    lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
++    for dir in $PATH /usr/ucb; do
++      IFS="$lt_save_ifs"
++      if (test -f $dir/echo || test -f $dir/echo$ac_exeext) &&
++         test "X`($dir/echo '\t') 2>/dev/null`" = 'X\t' &&
++         echo_testing_string=`($dir/echo "$echo_test_string") 2>/dev/null` &&
++         test "X$echo_testing_string" = "X$echo_test_string"; then
++        ECHO="$dir/echo"
++        break
++      fi
++    done
++    IFS="$lt_save_ifs"
++
++    if test "X$ECHO" = Xecho; then
++      # We didn't find a better echo, so look for alternatives.
++      if test "X`{ print -r '\t'; } 2>/dev/null`" = 'X\t' &&
++         echo_testing_string=`{ print -r "$echo_test_string"; } 2>/dev/null` &&
++         test "X$echo_testing_string" = "X$echo_test_string"; then
++        # This shell has a builtin print -r that does the trick.
++        ECHO='print -r'
++      elif { test -f /bin/ksh || test -f /bin/ksh$ac_exeext; } &&
++	   test "X$CONFIG_SHELL" != X/bin/ksh; then
++        # If we have ksh, try running configure again with it.
++        ORIGINAL_CONFIG_SHELL=${CONFIG_SHELL-/bin/sh}
++        export ORIGINAL_CONFIG_SHELL
++        CONFIG_SHELL=/bin/ksh
++        export CONFIG_SHELL
++        exec $CONFIG_SHELL "$0" --no-reexec ${1+"$@"}
++      else
++        # Try using printf.
++        ECHO='printf %s\n'
++        if test "X`{ $ECHO '\t'; } 2>/dev/null`" = 'X\t' &&
++	   echo_testing_string=`{ $ECHO "$echo_test_string"; } 2>/dev/null` &&
++	   test "X$echo_testing_string" = "X$echo_test_string"; then
++	  # Cool, printf works
++	  :
++        elif echo_testing_string=`($ORIGINAL_CONFIG_SHELL "$0" --fallback-echo '\t') 2>/dev/null` &&
++	     test "X$echo_testing_string" = 'X\t' &&
++	     echo_testing_string=`($ORIGINAL_CONFIG_SHELL "$0" --fallback-echo "$echo_test_string") 2>/dev/null` &&
++	     test "X$echo_testing_string" = "X$echo_test_string"; then
++	  CONFIG_SHELL=$ORIGINAL_CONFIG_SHELL
++	  export CONFIG_SHELL
++	  SHELL="$CONFIG_SHELL"
++	  export SHELL
++	  ECHO="$CONFIG_SHELL $0 --fallback-echo"
++        elif echo_testing_string=`($CONFIG_SHELL "$0" --fallback-echo '\t') 2>/dev/null` &&
++	     test "X$echo_testing_string" = 'X\t' &&
++	     echo_testing_string=`($CONFIG_SHELL "$0" --fallback-echo "$echo_test_string") 2>/dev/null` &&
++	     test "X$echo_testing_string" = "X$echo_test_string"; then
++	  ECHO="$CONFIG_SHELL $0 --fallback-echo"
++        else
++	  # maybe with a smaller string...
++	  prev=:
++
++	  for cmd in 'echo test' 'sed 2q "$0"' 'sed 10q "$0"' 'sed 20q "$0"' 'sed 50q "$0"'; do
++	    if { test "X$echo_test_string" = "X`eval $cmd`"; } 2>/dev/null
++	    then
++	      break
++	    fi
++	    prev="$cmd"
++	  done
++
++	  if test "$prev" != 'sed 50q "$0"'; then
++	    echo_test_string=`eval $prev`
++	    export echo_test_string
++	    exec ${ORIGINAL_CONFIG_SHELL-${CONFIG_SHELL-/bin/sh}} "$0" ${1+"$@"}
++	  else
++	    # Oops.  We lost completely, so just stick with echo.
++	    ECHO=echo
++	  fi
++        fi
++      fi
++    fi
++  fi
++fi
++
++# Copy echo and quote the copy suitably for passing to libtool from
++# the Makefile, instead of quoting the original, which is used later.
++lt_ECHO=$ECHO
++if test "X$lt_ECHO" = "X$CONFIG_SHELL $0 --fallback-echo"; then
++   lt_ECHO="$CONFIG_SHELL \\\$\$0 --fallback-echo"
++fi
++
++
++
++
++test -n "$DJDIR" || exec 7<&0 </dev/null
++exec 6>&1
++
++# Name of the host.
++# hostname on some systems (SVR3.2, old GNU/Linux) returns a bogus exit status,
++# so uname gets run too.
++ac_hostname=`(hostname || uname -n) 2>/dev/null | sed 1q`
++
++#
++# Initializations.
++#
++ac_default_prefix=/usr/local
++ac_clean_files=
++ac_config_libobj_dir=.
++LIBOBJS=
++cross_compiling=no
++subdirs=
++MFLAGS=
++MAKEFLAGS=
++
++# Identity of this package.
++PACKAGE_NAME='Heimdal'
++PACKAGE_TARNAME='heimdal'
++PACKAGE_VERSION='1.4.99'
++PACKAGE_STRING='Heimdal 1.4.99'
++PACKAGE_BUGREPORT='heimdal-bugs@h5l.org'
++PACKAGE_URL=''
++
++ac_unique_file="kuser/kinit.c"
++# Factoring default headers for most tests.
++ac_includes_default="\
++#include <stdio.h>
++#ifdef HAVE_SYS_TYPES_H
++# include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_STAT_H
++# include <sys/stat.h>
++#endif
++#ifdef STDC_HEADERS
++# include <stdlib.h>
++# include <stddef.h>
++#else
++# ifdef HAVE_STDLIB_H
++#  include <stdlib.h>
++# endif
++#endif
++#ifdef HAVE_STRING_H
++# if !defined STDC_HEADERS && defined HAVE_MEMORY_H
++#  include <memory.h>
++# endif
++# include <string.h>
++#endif
++#ifdef HAVE_STRINGS_H
++# include <strings.h>
++#endif
++#ifdef HAVE_INTTYPES_H
++# include <inttypes.h>
++#endif
++#ifdef HAVE_STDINT_H
++# include <stdint.h>
++#endif
++#ifdef HAVE_UNISTD_H
++# include <unistd.h>
++#endif"
++
++ac_default_prefix=/usr/heimdal
++ac_header_list=
++ac_subst_vars='am__EXEEXT_FALSE
++am__EXEEXT_TRUE
++LTLIBOBJS
++LIB_AUTH_SUBDIRS
++LIB_com_err_so
++LIB_com_err_a
++LIB_com_err
++DIR_com_err
++COM_ERR_FALSE
++COM_ERR_TRUE
++COMPILE_ET
++el_compat_FALSE
++el_compat_TRUE
++EDITLINE_FALSE
++EDITLINE_TRUE
++LIB_el_init
++FRAMEWORK_SECURITY_FALSE
++FRAMEWORK_SECURITY_TRUE
++KCM_FALSE
++KCM_TRUE
++LIB_door_create
++LIB_getpwnam_r
++LIB_tgetent
++LIB_openpty
++LIB_logout
++LIB_logwtmp
++NEED_WRITEAUTH_FALSE
++NEED_WRITEAUTH_TRUE
++LIB_XauFileName
++LIB_XauReadAuth
++LIB_XauWriteAuth
++HAVE_X_FALSE
++HAVE_X_TRUE
++X_EXTRA_LIBS
++X_LIBS
++X_PRE_LIBS
++X_CFLAGS
++XMKMF
++LIB_hesiod
++INCLUDE_hesiod
++LIB_readline
++INCLUDE_readline
++CATMANEXT
++CATMAN_FALSE
++CATMAN_TRUE
++CATMAN
++GROFF
++NROFF
++LIB_security
++have_gcd_FALSE
++have_gcd_TRUE
++LIB_dispatch_async_f
++OTP_FALSE
++OTP_TRUE
++LIB_otp
++LIBADD_roken
++INCLUDES_roken
++LIB_roken
++DIR_roken
++have_socket_wrapper_FALSE
++have_socket_wrapper_TRUE
++LIB_crypt
++have_fnmatch_h_FALSE
++have_fnmatch_h_TRUE
++LIB_gai_strerror
++LIB_freeaddrinfo
++LIB_getnameinfo
++LIB_getaddrinfo
++LIB_pidfile
++LIB_bswap32
++LIB_bswap16
++LIB_hstrerror
++LIB_setsockopt
++LIB_getsockopt
++have_cgetent_FALSE
++have_cgetent_TRUE
++have_glob_h_FALSE
++have_glob_h_TRUE
++LIBOBJS
++LIB_dn_expand
++LIB_dns_search
++LIB_res_ndestroy
++LIB_res_nsearch
++LIB_res_search
++LIB_gethostbyname2
++LIB_syslog
++LIB_gethostbyname
++LIB_socket
++have_vis_h_FALSE
++have_vis_h_TRUE
++have_ifaddrs_h_FALSE
++have_ifaddrs_h_TRUE
++have_err_h_FALSE
++have_err_h_TRUE
++WFLAGS_NOIMPLICITINT
++WFLAGS_NOUNUSED
++WFLAGS
++LIB_NDBM
++DBLIB
++HAVE_DBHEADER_FALSE
++HAVE_DBHEADER_TRUE
++HAVE_NDBM_FALSE
++HAVE_NDBM_TRUE
++HAVE_DB3_FALSE
++HAVE_DB3_TRUE
++HAVE_DB1_FALSE
++HAVE_DB1_TRUE
++LIB_dbm_firstkey
++LIB_dbopen
++LIB_db_create
++DBHEADER
++NO_AFS
++dpagaix_ldflags
++dpagaix_ldadd
++dpagaix_cflags
++DCE_FALSE
++DCE_TRUE
++PTHREAD_LIBADD
++PTHREAD_LDADD
++PTHREAD_CFLAGS
++LIB_hcrypto_appl
++LIB_hcrypto_so
++LIB_hcrypto_a
++LIB_hcrypto
++INCLUDE_hcrypto
++DIR_hcrypto
++HAVE_OPENSSL_FALSE
++HAVE_OPENSSL_TRUE
++LIB_kdb
++do_roken_rename_FALSE
++do_roken_rename_TRUE
++KRB5_FALSE
++KRB5_TRUE
++KRB4_FALSE
++KRB4_TRUE
++LIB_krb4
++INCLUDE_krb4
++DIR_hdbdir
++LIB_libintl
++INCLUDE_libintl
++have_scc_FALSE
++have_scc_TRUE
++SQLITE3_FALSE
++SQLITE3_TRUE
++LIB_sqlite3
++INCLUDE_sqlite3
++HAVE_CAPNG_FALSE
++HAVE_CAPNG_TRUE
++CAPNG_LIBS
++CAPNG_CFLAGS
++PKG_CONFIG
++PKINIT_FALSE
++PKINIT_TRUE
++OPENLDAP_MODULE_FALSE
++OPENLDAP_MODULE_TRUE
++LIB_openldap
++INCLUDE_openldap
++SLC_DEP
++SLC
++ASN1_COMPILE_DEP
++ASN1_COMPILE
++CROSS_COMPILE_FALSE
++CROSS_COMPILE_TRUE
++LDFLAGS_VERSION_SCRIPT
++versionscript_FALSE
++versionscript_TRUE
++VERSIONING
++ENABLE_SHARED_FALSE
++ENABLE_SHARED_TRUE
++LEXLIB
++LEX_OUTPUT_ROOT
++LEX
++YFLAGS
++YACC
++IRIX_FALSE
++IRIX_TRUE
++AIX_EXTRA_KAFS
++AIX_DYNAMIC_AFS_FALSE
++AIX_DYNAMIC_AFS_TRUE
++LIB_loadquery
++HAVE_DLOPEN_FALSE
++HAVE_DLOPEN_TRUE
++LIB_dlopen
++AIX4_FALSE
++AIX4_TRUE
++AIX_FALSE
++AIX_TRUE
++CANONICAL_HOST
++OTOOL64
++OTOOL
++LIPO
++NMEDIT
++DSYMUTIL
++lt_ECHO
++RANLIB
++AR
++OBJDUMP
++LN_S
++NM
++ac_ct_DUMPBIN
++DUMPBIN
++LD
++FGREP
++EGREP
++GREP
++SED
++host_os
++host_vendor
++host_cpu
++host
++build_os
++build_vendor
++build_cpu
++build
++LIBTOOL
++CPP
++am__fastdepCC_FALSE
++am__fastdepCC_TRUE
++CCDEPMODE
++AMDEPBACKSLASH
++AMDEP_FALSE
++AMDEP_TRUE
++am__quote
++am__include
++DEPDIR
++OBJEXT
++EXEEXT
++ac_ct_CC
++CPPFLAGS
++LDFLAGS
++CFLAGS
++CC
++am__untar
++am__tar
++AMTAR
++am__leading_dot
++SET_MAKE
++AWK
++mkdir_p
++MKDIR_P
++INSTALL_STRIP_PROGRAM
++STRIP
++install_sh
++MAKEINFO
++AUTOHEADER
++AUTOMAKE
++AUTOCONF
++ACLOCAL
++VERSION
++PACKAGE
++CYGPATH_W
++am__isrc
++INSTALL_DATA
++INSTALL_SCRIPT
++INSTALL_PROGRAM
++MAINT
++MAINTAINER_MODE_FALSE
++MAINTAINER_MODE_TRUE
++target_alias
++host_alias
++build_alias
++LIBS
++ECHO_T
++ECHO_N
++ECHO_C
++DEFS
++mandir
++localedir
++libdir
++psdir
++pdfdir
++dvidir
++htmldir
++infodir
++docdir
++oldincludedir
++includedir
++localstatedir
++sharedstatedir
++sysconfdir
++datadir
++datarootdir
++libexecdir
++sbindir
++bindir
++program_transform_name
++prefix
++exec_prefix
++PACKAGE_URL
++PACKAGE_BUGREPORT
++PACKAGE_STRING
++PACKAGE_VERSION
++PACKAGE_TARNAME
++PACKAGE_NAME
++PATH_SEPARATOR
++SHELL'
++ac_subst_files=''
++ac_user_opts='
++enable_option_checking
++enable_maintainer_mode
++enable_dependency_tracking
++enable_shared
++enable_static
++with_pic
++enable_fast_install
++with_gnu_ld
++enable_libtool_lock
++enable_largefile
++enable_dynamic_afs
++with_mips_abi
++with_cross_tools
++with_openldap
++with_openldap_lib
++with_openldap_include
++with_openldap_config
++enable_hdb_openldap_module
++enable_pk_init
++enable_digest
++enable_kx509
++enable_krb4
++with_capng
++with_sqlite3
++with_sqlite3_lib
++with_sqlite3_include
++with_sqlite3_config
++enable_sqlite_cache
++with_libintl
++with_libintl_lib
++with_libintl_include
++with_libintl_config
++with_hdbdir
++with_openssl
++with_openssl_lib
++with_openssl_include
++enable_pthread_support
++enable_dce
++enable_afs_support
++with_berkeley_db
++with_berkeley_db_include
++enable_ndbm_db
++enable_developer
++with_ipv6
++enable_socket_wrapper
++enable_otp
++enable_osfc2
++enable_mmap
++enable_afs_string_to_key
++with_readline
++with_readline_lib
++with_readline_include
++with_readline_config
++with_hesiod
++with_hesiod_lib
++with_hesiod_include
++with_hesiod_config
++enable_bigendian
++enable_littleendian
++with_x
++enable_kcm
++'
++      ac_precious_vars='build_alias
++host_alias
++target_alias
++CC
++CFLAGS
++LDFLAGS
++LIBS
++CPPFLAGS
++CPP
++YACC
++YFLAGS
++PKG_CONFIG
++CAPNG_CFLAGS
++CAPNG_LIBS
++XMKMF'
++
++
++# Initialize some variables set by options.
++ac_init_help=
++ac_init_version=false
++ac_unrecognized_opts=
++ac_unrecognized_sep=
++# The variables have the same names as the options, with
++# dashes changed to underlines.
++cache_file=/dev/null
++exec_prefix=NONE
++no_create=
++no_recursion=
++prefix=NONE
++program_prefix=NONE
++program_suffix=NONE
++program_transform_name=s,x,x,
++silent=
++site=
++srcdir=
++verbose=
++x_includes=NONE
++x_libraries=NONE
++
++# Installation directory options.
++# These are left unexpanded so users can "make install exec_prefix=/foo"
++# and all the variables that are supposed to be based on exec_prefix
++# by default will actually change.
++# Use braces instead of parens because sh, perl, etc. also accept them.
++# (The list follows the same order as the GNU Coding Standards.)
++bindir='${exec_prefix}/bin'
++sbindir='${exec_prefix}/sbin'
++libexecdir='${exec_prefix}/libexec'
++datarootdir='${prefix}/share'
++datadir='${datarootdir}'
++sysconfdir='${prefix}/etc'
++sharedstatedir='${prefix}/com'
++localstatedir='${prefix}/var'
++includedir='${prefix}/include'
++oldincludedir='/usr/include'
++docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
++infodir='${datarootdir}/info'
++htmldir='${docdir}'
++dvidir='${docdir}'
++pdfdir='${docdir}'
++psdir='${docdir}'
++libdir='${exec_prefix}/lib'
++localedir='${datarootdir}/locale'
++mandir='${datarootdir}/man'
++
++ac_prev=
++ac_dashdash=
++for ac_option
++do
++  # If the previous option needs an argument, assign it.
++  if test -n "$ac_prev"; then
++    eval $ac_prev=\$ac_option
++    ac_prev=
++    continue
++  fi
++
++  case $ac_option in
++  *=?*) ac_optarg=`expr "X$ac_option" : '[^=]*=\(.*\)'` ;;
++  *=)   ac_optarg= ;;
++  *)    ac_optarg=yes ;;
++  esac
++
++  # Accept the important Cygnus configure options, so we can diagnose typos.
++
++  case $ac_dashdash$ac_option in
++  --)
++    ac_dashdash=yes ;;
++
++  -bindir | --bindir | --bindi | --bind | --bin | --bi)
++    ac_prev=bindir ;;
++  -bindir=* | --bindir=* | --bindi=* | --bind=* | --bin=* | --bi=*)
++    bindir=$ac_optarg ;;
++
++  -build | --build | --buil | --bui | --bu)
++    ac_prev=build_alias ;;
++  -build=* | --build=* | --buil=* | --bui=* | --bu=*)
++    build_alias=$ac_optarg ;;
++
++  -cache-file | --cache-file | --cache-fil | --cache-fi \
++  | --cache-f | --cache- | --cache | --cach | --cac | --ca | --c)
++    ac_prev=cache_file ;;
++  -cache-file=* | --cache-file=* | --cache-fil=* | --cache-fi=* \
++  | --cache-f=* | --cache-=* | --cache=* | --cach=* | --cac=* | --ca=* | --c=*)
++    cache_file=$ac_optarg ;;
++
++  --config-cache | -C)
++    cache_file=config.cache ;;
++
++  -datadir | --datadir | --datadi | --datad)
++    ac_prev=datadir ;;
++  -datadir=* | --datadir=* | --datadi=* | --datad=*)
++    datadir=$ac_optarg ;;
++
++  -datarootdir | --datarootdir | --datarootdi | --datarootd | --dataroot \
++  | --dataroo | --dataro | --datar)
++    ac_prev=datarootdir ;;
++  -datarootdir=* | --datarootdir=* | --datarootdi=* | --datarootd=* \
++  | --dataroot=* | --dataroo=* | --dataro=* | --datar=*)
++    datarootdir=$ac_optarg ;;
++
++  -disable-* | --disable-*)
++    ac_useropt=`expr "x$ac_option" : 'x-*disable-\(.*\)'`
++    # Reject names that are not valid shell variable names.
++    expr "x$ac_useropt" : ".*[^-+._$as_cr_alnum]" >/dev/null &&
++      as_fn_error $? "invalid feature name: $ac_useropt"
++    ac_useropt_orig=$ac_useropt
++    ac_useropt=`$as_echo "$ac_useropt" | sed 's/[-+.]/_/g'`
++    case $ac_user_opts in
++      *"
++"enable_$ac_useropt"
++"*) ;;
++      *) ac_unrecognized_opts="$ac_unrecognized_opts$ac_unrecognized_sep--disable-$ac_useropt_orig"
++	 ac_unrecognized_sep=', ';;
++    esac
++    eval enable_$ac_useropt=no ;;
++
++  -docdir | --docdir | --docdi | --doc | --do)
++    ac_prev=docdir ;;
++  -docdir=* | --docdir=* | --docdi=* | --doc=* | --do=*)
++    docdir=$ac_optarg ;;
++
++  -dvidir | --dvidir | --dvidi | --dvid | --dvi | --dv)
++    ac_prev=dvidir ;;
++  -dvidir=* | --dvidir=* | --dvidi=* | --dvid=* | --dvi=* | --dv=*)
++    dvidir=$ac_optarg ;;
++
++  -enable-* | --enable-*)
++    ac_useropt=`expr "x$ac_option" : 'x-*enable-\([^=]*\)'`
++    # Reject names that are not valid shell variable names.
++    expr "x$ac_useropt" : ".*[^-+._$as_cr_alnum]" >/dev/null &&
++      as_fn_error $? "invalid feature name: $ac_useropt"
++    ac_useropt_orig=$ac_useropt
++    ac_useropt=`$as_echo "$ac_useropt" | sed 's/[-+.]/_/g'`
++    case $ac_user_opts in
++      *"
++"enable_$ac_useropt"
++"*) ;;
++      *) ac_unrecognized_opts="$ac_unrecognized_opts$ac_unrecognized_sep--enable-$ac_useropt_orig"
++	 ac_unrecognized_sep=', ';;
++    esac
++    eval enable_$ac_useropt=\$ac_optarg ;;
++
++  -exec-prefix | --exec_prefix | --exec-prefix | --exec-prefi \
++  | --exec-pref | --exec-pre | --exec-pr | --exec-p | --exec- \
++  | --exec | --exe | --ex)
++    ac_prev=exec_prefix ;;
++  -exec-prefix=* | --exec_prefix=* | --exec-prefix=* | --exec-prefi=* \
++  | --exec-pref=* | --exec-pre=* | --exec-pr=* | --exec-p=* | --exec-=* \
++  | --exec=* | --exe=* | --ex=*)
++    exec_prefix=$ac_optarg ;;
++
++  -gas | --gas | --ga | --g)
++    # Obsolete; use --with-gas.
++    with_gas=yes ;;
++
++  -help | --help | --hel | --he | -h)
++    ac_init_help=long ;;
++  -help=r* | --help=r* | --hel=r* | --he=r* | -hr*)
++    ac_init_help=recursive ;;
++  -help=s* | --help=s* | --hel=s* | --he=s* | -hs*)
++    ac_init_help=short ;;
++
++  -host | --host | --hos | --ho)
++    ac_prev=host_alias ;;
++  -host=* | --host=* | --hos=* | --ho=*)
++    host_alias=$ac_optarg ;;
++
++  -htmldir | --htmldir | --htmldi | --htmld | --html | --htm | --ht)
++    ac_prev=htmldir ;;
++  -htmldir=* | --htmldir=* | --htmldi=* | --htmld=* | --html=* | --htm=* \
++  | --ht=*)
++    htmldir=$ac_optarg ;;
++
++  -includedir | --includedir | --includedi | --included | --include \
++  | --includ | --inclu | --incl | --inc)
++    ac_prev=includedir ;;
++  -includedir=* | --includedir=* | --includedi=* | --included=* | --include=* \
++  | --includ=* | --inclu=* | --incl=* | --inc=*)
++    includedir=$ac_optarg ;;
++
++  -infodir | --infodir | --infodi | --infod | --info | --inf)
++    ac_prev=infodir ;;
++  -infodir=* | --infodir=* | --infodi=* | --infod=* | --info=* | --inf=*)
++    infodir=$ac_optarg ;;
++
++  -libdir | --libdir | --libdi | --libd)
++    ac_prev=libdir ;;
++  -libdir=* | --libdir=* | --libdi=* | --libd=*)
++    libdir=$ac_optarg ;;
++
++  -libexecdir | --libexecdir | --libexecdi | --libexecd | --libexec \
++  | --libexe | --libex | --libe)
++    ac_prev=libexecdir ;;
++  -libexecdir=* | --libexecdir=* | --libexecdi=* | --libexecd=* | --libexec=* \
++  | --libexe=* | --libex=* | --libe=*)
++    libexecdir=$ac_optarg ;;
++
++  -localedir | --localedir | --localedi | --localed | --locale)
++    ac_prev=localedir ;;
++  -localedir=* | --localedir=* | --localedi=* | --localed=* | --locale=*)
++    localedir=$ac_optarg ;;
++
++  -localstatedir | --localstatedir | --localstatedi | --localstated \
++  | --localstate | --localstat | --localsta | --localst | --locals)
++    ac_prev=localstatedir ;;
++  -localstatedir=* | --localstatedir=* | --localstatedi=* | --localstated=* \
++  | --localstate=* | --localstat=* | --localsta=* | --localst=* | --locals=*)
++    localstatedir=$ac_optarg ;;
++
++  -mandir | --mandir | --mandi | --mand | --man | --ma | --m)
++    ac_prev=mandir ;;
++  -mandir=* | --mandir=* | --mandi=* | --mand=* | --man=* | --ma=* | --m=*)
++    mandir=$ac_optarg ;;
++
++  -nfp | --nfp | --nf)
++    # Obsolete; use --without-fp.
++    with_fp=no ;;
++
++  -no-create | --no-create | --no-creat | --no-crea | --no-cre \
++  | --no-cr | --no-c | -n)
++    no_create=yes ;;
++
++  -no-recursion | --no-recursion | --no-recursio | --no-recursi \
++  | --no-recurs | --no-recur | --no-recu | --no-rec | --no-re | --no-r)
++    no_recursion=yes ;;
++
++  -oldincludedir | --oldincludedir | --oldincludedi | --oldincluded \
++  | --oldinclude | --oldinclud | --oldinclu | --oldincl | --oldinc \
++  | --oldin | --oldi | --old | --ol | --o)
++    ac_prev=oldincludedir ;;
++  -oldincludedir=* | --oldincludedir=* | --oldincludedi=* | --oldincluded=* \
++  | --oldinclude=* | --oldinclud=* | --oldinclu=* | --oldincl=* | --oldinc=* \
++  | --oldin=* | --oldi=* | --old=* | --ol=* | --o=*)
++    oldincludedir=$ac_optarg ;;
++
++  -prefix | --prefix | --prefi | --pref | --pre | --pr | --p)
++    ac_prev=prefix ;;
++  -prefix=* | --prefix=* | --prefi=* | --pref=* | --pre=* | --pr=* | --p=*)
++    prefix=$ac_optarg ;;
++
++  -program-prefix | --program-prefix | --program-prefi | --program-pref \
++  | --program-pre | --program-pr | --program-p)
++    ac_prev=program_prefix ;;
++  -program-prefix=* | --program-prefix=* | --program-prefi=* \
++  | --program-pref=* | --program-pre=* | --program-pr=* | --program-p=*)
++    program_prefix=$ac_optarg ;;
++
++  -program-suffix | --program-suffix | --program-suffi | --program-suff \
++  | --program-suf | --program-su | --program-s)
++    ac_prev=program_suffix ;;
++  -program-suffix=* | --program-suffix=* | --program-suffi=* \
++  | --program-suff=* | --program-suf=* | --program-su=* | --program-s=*)
++    program_suffix=$ac_optarg ;;
++
++  -program-transform-name | --program-transform-name \
++  | --program-transform-nam | --program-transform-na \
++  | --program-transform-n | --program-transform- \
++  | --program-transform | --program-transfor \
++  | --program-transfo | --program-transf \
++  | --program-trans | --program-tran \
++  | --progr-tra | --program-tr | --program-t)
++    ac_prev=program_transform_name ;;
++  -program-transform-name=* | --program-transform-name=* \
++  | --program-transform-nam=* | --program-transform-na=* \
++  | --program-transform-n=* | --program-transform-=* \
++  | --program-transform=* | --program-transfor=* \
++  | --program-transfo=* | --program-transf=* \
++  | --program-trans=* | --program-tran=* \
++  | --progr-tra=* | --program-tr=* | --program-t=*)
++    program_transform_name=$ac_optarg ;;
++
++  -pdfdir | --pdfdir | --pdfdi | --pdfd | --pdf | --pd)
++    ac_prev=pdfdir ;;
++  -pdfdir=* | --pdfdir=* | --pdfdi=* | --pdfd=* | --pdf=* | --pd=*)
++    pdfdir=$ac_optarg ;;
++
++  -psdir | --psdir | --psdi | --psd | --ps)
++    ac_prev=psdir ;;
++  -psdir=* | --psdir=* | --psdi=* | --psd=* | --ps=*)
++    psdir=$ac_optarg ;;
++
++  -q | -quiet | --quiet | --quie | --qui | --qu | --q \
++  | -silent | --silent | --silen | --sile | --sil)
++    silent=yes ;;
++
++  -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
++    ac_prev=sbindir ;;
++  -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
++  | --sbi=* | --sb=*)
++    sbindir=$ac_optarg ;;
++
++  -sharedstatedir | --sharedstatedir | --sharedstatedi \
++  | --sharedstated | --sharedstate | --sharedstat | --sharedsta \
++  | --sharedst | --shareds | --shared | --share | --shar \
++  | --sha | --sh)
++    ac_prev=sharedstatedir ;;
++  -sharedstatedir=* | --sharedstatedir=* | --sharedstatedi=* \
++  | --sharedstated=* | --sharedstate=* | --sharedstat=* | --sharedsta=* \
++  | --sharedst=* | --shareds=* | --shared=* | --share=* | --shar=* \
++  | --sha=* | --sh=*)
++    sharedstatedir=$ac_optarg ;;
++
++  -site | --site | --sit)
++    ac_prev=site ;;
++  -site=* | --site=* | --sit=*)
++    site=$ac_optarg ;;
++
++  -srcdir | --srcdir | --srcdi | --srcd | --src | --sr)
++    ac_prev=srcdir ;;
++  -srcdir=* | --srcdir=* | --srcdi=* | --srcd=* | --src=* | --sr=*)
++    srcdir=$ac_optarg ;;
++
++  -sysconfdir | --sysconfdir | --sysconfdi | --sysconfd | --sysconf \
++  | --syscon | --sysco | --sysc | --sys | --sy)
++    ac_prev=sysconfdir ;;
++  -sysconfdir=* | --sysconfdir=* | --sysconfdi=* | --sysconfd=* | --sysconf=* \
++  | --syscon=* | --sysco=* | --sysc=* | --sys=* | --sy=*)
++    sysconfdir=$ac_optarg ;;
++
++  -target | --target | --targe | --targ | --tar | --ta | --t)
++    ac_prev=target_alias ;;
++  -target=* | --target=* | --targe=* | --targ=* | --tar=* | --ta=* | --t=*)
++    target_alias=$ac_optarg ;;
++
++  -v | -verbose | --verbose | --verbos | --verbo | --verb)
++    verbose=yes ;;
++
++  -version | --version | --versio | --versi | --vers | -V)
++    ac_init_version=: ;;
++
++  -with-* | --with-*)
++    ac_useropt=`expr "x$ac_option" : 'x-*with-\([^=]*\)'`
++    # Reject names that are not valid shell variable names.
++    expr "x$ac_useropt" : ".*[^-+._$as_cr_alnum]" >/dev/null &&
++      as_fn_error $? "invalid package name: $ac_useropt"
++    ac_useropt_orig=$ac_useropt
++    ac_useropt=`$as_echo "$ac_useropt" | sed 's/[-+.]/_/g'`
++    case $ac_user_opts in
++      *"
++"with_$ac_useropt"
++"*) ;;
++      *) ac_unrecognized_opts="$ac_unrecognized_opts$ac_unrecognized_sep--with-$ac_useropt_orig"
++	 ac_unrecognized_sep=', ';;
++    esac
++    eval with_$ac_useropt=\$ac_optarg ;;
++
++  -without-* | --without-*)
++    ac_useropt=`expr "x$ac_option" : 'x-*without-\(.*\)'`
++    # Reject names that are not valid shell variable names.
++    expr "x$ac_useropt" : ".*[^-+._$as_cr_alnum]" >/dev/null &&
++      as_fn_error $? "invalid package name: $ac_useropt"
++    ac_useropt_orig=$ac_useropt
++    ac_useropt=`$as_echo "$ac_useropt" | sed 's/[-+.]/_/g'`
++    case $ac_user_opts in
++      *"
++"with_$ac_useropt"
++"*) ;;
++      *) ac_unrecognized_opts="$ac_unrecognized_opts$ac_unrecognized_sep--without-$ac_useropt_orig"
++	 ac_unrecognized_sep=', ';;
++    esac
++    eval with_$ac_useropt=no ;;
++
++  --x)
++    # Obsolete; use --with-x.
++    with_x=yes ;;
++
++  -x-includes | --x-includes | --x-include | --x-includ | --x-inclu \
++  | --x-incl | --x-inc | --x-in | --x-i)
++    ac_prev=x_includes ;;
++  -x-includes=* | --x-includes=* | --x-include=* | --x-includ=* | --x-inclu=* \
++  | --x-incl=* | --x-inc=* | --x-in=* | --x-i=*)
++    x_includes=$ac_optarg ;;
++
++  -x-libraries | --x-libraries | --x-librarie | --x-librari \
++  | --x-librar | --x-libra | --x-libr | --x-lib | --x-li | --x-l)
++    ac_prev=x_libraries ;;
++  -x-libraries=* | --x-libraries=* | --x-librarie=* | --x-librari=* \
++  | --x-librar=* | --x-libra=* | --x-libr=* | --x-lib=* | --x-li=* | --x-l=*)
++    x_libraries=$ac_optarg ;;
++
++  -*) as_fn_error $? "unrecognized option: \`$ac_option'
++Try \`$0 --help' for more information"
++    ;;
++
++  *=*)
++    ac_envvar=`expr "x$ac_option" : 'x\([^=]*\)='`
++    # Reject names that are not valid shell variable names.
++    case $ac_envvar in #(
++      '' | [0-9]* | *[!_$as_cr_alnum]* )
++      as_fn_error $? "invalid variable name: \`$ac_envvar'" ;;
++    esac
++    eval $ac_envvar=\$ac_optarg
++    export $ac_envvar ;;
++
++  *)
++    # FIXME: should be removed in autoconf 3.0.
++    $as_echo "$as_me: WARNING: you should use --build, --host, --target" >&2
++    expr "x$ac_option" : ".*[^-._$as_cr_alnum]" >/dev/null &&
++      $as_echo "$as_me: WARNING: invalid host type: $ac_option" >&2
++    : ${build_alias=$ac_option} ${host_alias=$ac_option} ${target_alias=$ac_option}
++    ;;
++
++  esac
++done
++
++if test -n "$ac_prev"; then
++  ac_option=--`echo $ac_prev | sed 's/_/-/g'`
++  as_fn_error $? "missing argument to $ac_option"
++fi
++
++if test -n "$ac_unrecognized_opts"; then
++  case $enable_option_checking in
++    no) ;;
++    fatal) as_fn_error $? "unrecognized options: $ac_unrecognized_opts" ;;
++    *)     $as_echo "$as_me: WARNING: unrecognized options: $ac_unrecognized_opts" >&2 ;;
++  esac
++fi
++
++# Check all directory arguments for consistency.
++for ac_var in	exec_prefix prefix bindir sbindir libexecdir datarootdir \
++		datadir sysconfdir sharedstatedir localstatedir includedir \
++		oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
++		libdir localedir mandir
++do
++  eval ac_val=\$$ac_var
++  # Remove trailing slashes.
++  case $ac_val in
++    */ )
++      ac_val=`expr "X$ac_val" : 'X\(.*[^/]\)' \| "X$ac_val" : 'X\(.*\)'`
++      eval $ac_var=\$ac_val;;
++  esac
++  # Be sure to have absolute directory names.
++  case $ac_val in
++    [\\/$]* | ?:[\\/]* )  continue;;
++    NONE | '' ) case $ac_var in *prefix ) continue;; esac;;
++  esac
++  as_fn_error $? "expected an absolute directory name for --$ac_var: $ac_val"
++done
++
++# There might be people who depend on the old broken behavior: `$host'
++# used to hold the argument of --host etc.
++# FIXME: To remove some day.
++build=$build_alias
++host=$host_alias
++target=$target_alias
++
++# FIXME: To remove some day.
++if test "x$host_alias" != x; then
++  if test "x$build_alias" = x; then
++    cross_compiling=maybe
++    $as_echo "$as_me: WARNING: if you wanted to set the --build type, don't use --host.
++    If a cross compiler is detected then cross compile mode will be used" >&2
++  elif test "x$build_alias" != "x$host_alias"; then
++    cross_compiling=yes
++  fi
++fi
++
++ac_tool_prefix=
++test -n "$host_alias" && ac_tool_prefix=$host_alias-
++
++test "$silent" = yes && exec 6>/dev/null
++
++
++ac_pwd=`pwd` && test -n "$ac_pwd" &&
++ac_ls_di=`ls -di .` &&
++ac_pwd_ls_di=`cd "$ac_pwd" && ls -di .` ||
++  as_fn_error $? "working directory cannot be determined"
++test "X$ac_ls_di" = "X$ac_pwd_ls_di" ||
++  as_fn_error $? "pwd does not report name of working directory"
++
++
++# Find the source files, if location was not specified.
++if test -z "$srcdir"; then
++  ac_srcdir_defaulted=yes
++  # Try the directory containing this script, then the parent directory.
++  ac_confdir=`$as_dirname -- "$as_myself" ||
++$as_expr X"$as_myself" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
++	 X"$as_myself" : 'X\(//\)[^/]' \| \
++	 X"$as_myself" : 'X\(//\)$' \| \
++	 X"$as_myself" : 'X\(/\)' \| . 2>/dev/null ||
++$as_echo X"$as_myself" |
++    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\/\)[^/].*/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\/\)$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\).*/{
++	    s//\1/
++	    q
++	  }
++	  s/.*/./; q'`
++  srcdir=$ac_confdir
++  if test ! -r "$srcdir/$ac_unique_file"; then
++    srcdir=..
++  fi
++else
++  ac_srcdir_defaulted=no
++fi
++if test ! -r "$srcdir/$ac_unique_file"; then
++  test "$ac_srcdir_defaulted" = yes && srcdir="$ac_confdir or .."
++  as_fn_error $? "cannot find sources ($ac_unique_file) in $srcdir"
++fi
++ac_msg="sources are in $srcdir, but \`cd $srcdir' does not work"
++ac_abs_confdir=`(
++	cd "$srcdir" && test -r "./$ac_unique_file" || as_fn_error $? "$ac_msg"
++	pwd)`
++# When building in place, set srcdir=.
++if test "$ac_abs_confdir" = "$ac_pwd"; then
++  srcdir=.
++fi
++# Remove unnecessary trailing slashes from srcdir.
++# Double slashes in file names in object file debugging info
++# mess up M-x gdb in Emacs.
++case $srcdir in
++*/) srcdir=`expr "X$srcdir" : 'X\(.*[^/]\)' \| "X$srcdir" : 'X\(.*\)'`;;
++esac
++for ac_var in $ac_precious_vars; do
++  eval ac_env_${ac_var}_set=\${${ac_var}+set}
++  eval ac_env_${ac_var}_value=\$${ac_var}
++  eval ac_cv_env_${ac_var}_set=\${${ac_var}+set}
++  eval ac_cv_env_${ac_var}_value=\$${ac_var}
++done
++
++#
++# Report the --help message.
++#
++if test "$ac_init_help" = "long"; then
++  # Omit some internal or obsolete options to make the list less imposing.
++  # This message is too long to be a string in the A/UX 3.1 sh.
++  cat <<_ACEOF
++\`configure' configures Heimdal 1.4.99 to adapt to many kinds of systems.
++
++Usage: $0 [OPTION]... [VAR=VALUE]...
++
++To assign environment variables (e.g., CC, CFLAGS...), specify them as
++VAR=VALUE.  See below for descriptions of some of the useful variables.
++
++Defaults for the options are specified in brackets.
++
++Configuration:
++  -h, --help              display this help and exit
++      --help=short        display options specific to this package
++      --help=recursive    display the short help of all the included packages
++  -V, --version           display version information and exit
++  -q, --quiet, --silent   do not print \`checking ...' messages
++      --cache-file=FILE   cache test results in FILE [disabled]
++  -C, --config-cache      alias for \`--cache-file=config.cache'
++  -n, --no-create         do not create output files
++      --srcdir=DIR        find the sources in DIR [configure dir or \`..']
++
++Installation directories:
++  --prefix=PREFIX         install architecture-independent files in PREFIX
++                          [$ac_default_prefix]
++  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
++                          [PREFIX]
++
++By default, \`make install' will install all the files in
++\`$ac_default_prefix/bin', \`$ac_default_prefix/lib' etc.  You can specify
++an installation prefix other than \`$ac_default_prefix' using \`--prefix',
++for instance \`--prefix=\$HOME'.
++
++For better control, use the options below.
++
++Fine tuning of the installation directories:
++  --bindir=DIR            user executables [EPREFIX/bin]
++  --sbindir=DIR           system admin executables [EPREFIX/sbin]
++  --libexecdir=DIR        program executables [EPREFIX/libexec]
++  --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
++  --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
++  --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
++  --libdir=DIR            object code libraries [EPREFIX/lib]
++  --includedir=DIR        C header files [PREFIX/include]
++  --oldincludedir=DIR     C header files for non-gcc [/usr/include]
++  --datarootdir=DIR       read-only arch.-independent data root [PREFIX/share]
++  --datadir=DIR           read-only architecture-independent data [DATAROOTDIR]
++  --infodir=DIR           info documentation [DATAROOTDIR/info]
++  --localedir=DIR         locale-dependent data [DATAROOTDIR/locale]
++  --mandir=DIR            man documentation [DATAROOTDIR/man]
++  --docdir=DIR            documentation root [DATAROOTDIR/doc/heimdal]
++  --htmldir=DIR           html documentation [DOCDIR]
++  --dvidir=DIR            dvi documentation [DOCDIR]
++  --pdfdir=DIR            pdf documentation [DOCDIR]
++  --psdir=DIR             ps documentation [DOCDIR]
++_ACEOF
++
++  cat <<\_ACEOF
++
++Program names:
++  --program-prefix=PREFIX            prepend PREFIX to installed program names
++  --program-suffix=SUFFIX            append SUFFIX to installed program names
++  --program-transform-name=PROGRAM   run sed PROGRAM on installed program names
++
++X features:
++  --x-includes=DIR    X include files are in DIR
++  --x-libraries=DIR   X library files are in DIR
++
++System types:
++  --build=BUILD     configure for building on BUILD [guessed]
++  --host=HOST       cross-compile to build programs to run on HOST [BUILD]
++_ACEOF
++fi
++
++if test -n "$ac_init_help"; then
++  case $ac_init_help in
++     short | recursive ) echo "Configuration of Heimdal 1.4.99:";;
++   esac
++  cat <<\_ACEOF
++
++Optional Features:
++  --disable-option-checking  ignore unrecognized --enable/--with options
++  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
++  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
++  --enable-maintainer-mode  enable make rules and dependencies not useful
++			  (and sometimes confusing) to the casual installer
++  --disable-dependency-tracking  speeds up one-time build
++  --enable-dependency-tracking   do not reject slow dependency extractors
++  --enable-shared[=PKGS]  build shared libraries [default=yes]
++  --enable-static[=PKGS]  build static libraries [default=yes]
++  --enable-fast-install[=PKGS]
++                          optimize for fast installation [default=yes]
++  --disable-libtool-lock  avoid locking (might break parallel builds)
++  --disable-largefile     omit support for large files
++  --disable-dynamic-afs   do not use loaded AFS library with AIX
++  --enable-hdb-openldap-module
++                          if you want support to build openldap hdb as shared
++                          object
++  --disable-pk-init       if you want disable to PK-INIT support
++  --disable-digest        if you want disable to DIGEST support
++  --disable-kx509         if you want disable to kx509 support
++  --disable-krb4          if you want disable to krb4 support
++  --disable-sqlite-cache  if you want support for cache in sqlite
++  --enable-pthread-support
++                          if you want thread safe libraries
++  --enable-dce            if you want support for DCE/DFS PAG's
++  --disable-afs-support   if you don't want support for AFS
++  --disable-ndbm-db       if you don't want ndbm db
++  --enable-developer      enable developer warnings
++  --enable-socket-wrapper use sambas socket-wrapper for testing
++  --disable-otp           if you don't want OTP support
++  --enable-osfc2          enable some OSF C2 support
++  --disable-mmap          disable use of mmap
++  --disable-afs-string-to-key
++                          disable use of weak AFS string-to-key functions
++  --enable-bigendian      the target is big endian
++  --enable-littleendian   the target is little endian
++  --enable-kcm            enable Kerberos Credentials Manager
++
++Optional Packages:
++  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
++  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
++  --with-pic              try to use only PIC/non-PIC objects [default=use
++                          both]
++  --with-gnu-ld           assume the C compiler uses GNU ld [default=no]
++  --with-mips-abi=abi     ABI to use for IRIX (32, n32, or 64)
++  --with-cross-tools=dir  use cross tools in dir
++  --with-openldap=dir     use openldap in dir
++  --with-openldap-lib=dir use openldap libraries in dir
++  --with-openldap-include=dir
++                          use openldap headers in dir
++  --with-openldap-config=path
++                          config program for openldap
++  --with-capng            use libcap-ng to drop KDC privileges [default=check]
++  --with-sqlite3=dir      use sqlite3 in dir
++  --with-sqlite3-lib=dir  use sqlite3 libraries in dir
++  --with-sqlite3-include=dir
++                          use sqlite3 headers in dir
++  --with-sqlite3-config=path
++                          config program for sqlite3
++  --with-libintl=dir      use libintl in dir
++  --with-libintl-lib=dir  use libintl libraries in dir
++  --with-libintl-include=dir
++                          use libintl headers in dir
++  --with-libintl-config=path
++                          config program for libintl
++  --with-hdbdir           Default location for KDC database
++                          [default=/var/heimdal]
++  --with-openssl=dir      use openssl in dir
++  --with-openssl-lib=dir  use openssl libraries in dir
++  --with-openssl-include=dir
++                          use openssl headers in dir
++  --with-berkeley-db      enable support for berkeley db [default=check]
++  --with-berkeley-db-include=dir
++                          use berkeley-db headers in dir
++  --without-ipv6          do not enable IPv6 support
++  --with-readline=dir     use readline in dir
++  --with-readline-lib=dir use readline libraries in dir
++  --with-readline-include=dir
++                          use readline headers in dir
++  --with-readline-config=path
++                          config program for readline
++  --with-hesiod=dir       use hesiod in dir
++  --with-hesiod-lib=dir   use hesiod libraries in dir
++  --with-hesiod-include=dir
++                          use hesiod headers in dir
++  --with-hesiod-config=path
++                          config program for hesiod
++  --with-x                use the X Window System
++
++Some influential environment variables:
++  CC          C compiler command
++  CFLAGS      C compiler flags
++  LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
++              nonstandard directory <lib dir>
++  LIBS        libraries to pass to the linker, e.g. -l<library>
++  CPPFLAGS    (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
++              you have headers in a nonstandard directory <include dir>
++  CPP         C preprocessor
++  YACC        The `Yet Another C Compiler' implementation to use. Defaults to
++              the first program found out of: `bison -y', `byacc', `yacc'.
++  YFLAGS      The list of arguments that will be passed by default to $YACC.
++              This script will default YFLAGS to the empty string to avoid a
++              default value of `-d' given by some make applications.
++  PKG_CONFIG  path to pkg-config utility
++  CAPNG_CFLAGS
++              C compiler flags for CAPNG, overriding pkg-config
++  CAPNG_LIBS  linker flags for CAPNG, overriding pkg-config
++  XMKMF       Path to xmkmf, Makefile generator for X Window System
++
++Use these variables to override the choices made by `configure' or to help
++it to find libraries and programs with nonstandard names/locations.
++
++Report bugs to <heimdal-bugs@h5l.org>.
++_ACEOF
++ac_status=$?
++fi
++
++if test "$ac_init_help" = "recursive"; then
++  # If there are subdirs, report their specific --help.
++  for ac_dir in : $ac_subdirs_all; do test "x$ac_dir" = x: && continue
++    test -d "$ac_dir" ||
++      { cd "$srcdir" && ac_pwd=`pwd` && srcdir=. && test -d "$ac_dir"; } ||
++      continue
++    ac_builddir=.
++
++case "$ac_dir" in
++.) ac_dir_suffix= ac_top_builddir_sub=. ac_top_build_prefix= ;;
++*)
++  ac_dir_suffix=/`$as_echo "$ac_dir" | sed 's|^\.[\\/]||'`
++  # A ".." for each directory in $ac_dir_suffix.
++  ac_top_builddir_sub=`$as_echo "$ac_dir_suffix" | sed 's|/[^\\/]*|/..|g;s|/||'`
++  case $ac_top_builddir_sub in
++  "") ac_top_builddir_sub=. ac_top_build_prefix= ;;
++  *)  ac_top_build_prefix=$ac_top_builddir_sub/ ;;
++  esac ;;
++esac
++ac_abs_top_builddir=$ac_pwd
++ac_abs_builddir=$ac_pwd$ac_dir_suffix
++# for backward compatibility:
++ac_top_builddir=$ac_top_build_prefix
++
++case $srcdir in
++  .)  # We are building in place.
++    ac_srcdir=.
++    ac_top_srcdir=$ac_top_builddir_sub
++    ac_abs_top_srcdir=$ac_pwd ;;
++  [\\/]* | ?:[\\/]* )  # Absolute name.
++    ac_srcdir=$srcdir$ac_dir_suffix;
++    ac_top_srcdir=$srcdir
++    ac_abs_top_srcdir=$srcdir ;;
++  *) # Relative name.
++    ac_srcdir=$ac_top_build_prefix$srcdir$ac_dir_suffix
++    ac_top_srcdir=$ac_top_build_prefix$srcdir
++    ac_abs_top_srcdir=$ac_pwd/$srcdir ;;
++esac
++ac_abs_srcdir=$ac_abs_top_srcdir$ac_dir_suffix
++
++    cd "$ac_dir" || { ac_status=$?; continue; }
++    # Check for guested configure.
++    if test -f "$ac_srcdir/configure.gnu"; then
++      echo &&
++      $SHELL "$ac_srcdir/configure.gnu" --help=recursive
++    elif test -f "$ac_srcdir/configure"; then
++      echo &&
++      $SHELL "$ac_srcdir/configure" --help=recursive
++    else
++      $as_echo "$as_me: WARNING: no configuration information is in $ac_dir" >&2
++    fi || ac_status=$?
++    cd "$ac_pwd" || { ac_status=$?; break; }
++  done
++fi
++
++test -n "$ac_init_help" && exit $ac_status
++if $ac_init_version; then
++  cat <<\_ACEOF
++Heimdal configure 1.4.99
++generated by GNU Autoconf 2.67
++
++Copyright (C) 2010 Free Software Foundation, Inc.
++This configure script is free software; the Free Software Foundation
++gives unlimited permission to copy, distribute and modify it.
++_ACEOF
++  exit
++fi
++
++## ------------------------ ##
++## Autoconf initialization. ##
++## ------------------------ ##
++
++# ac_fn_c_try_compile LINENO
++# --------------------------
++# Try to compile conftest.$ac_ext, and return whether this succeeded.
++ac_fn_c_try_compile ()
++{
++  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
++  rm -f conftest.$ac_objext
++  if { { ac_try="$ac_compile"
++case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_compile") 2>conftest.err
++  ac_status=$?
++  if test -s conftest.err; then
++    grep -v '^ *+' conftest.err >conftest.er1
++    cat conftest.er1 >&5
++    mv -f conftest.er1 conftest.err
++  fi
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; } && {
++	 test -z "$ac_c_werror_flag" ||
++	 test ! -s conftest.err
++       } && test -s conftest.$ac_objext; then :
++  ac_retval=0
++else
++  $as_echo "$as_me: failed program was:" >&5
++sed 's/^/| /' conftest.$ac_ext >&5
++
++	ac_retval=1
++fi
++  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
++  as_fn_set_status $ac_retval
++
++} # ac_fn_c_try_compile
++
++# ac_fn_c_try_cpp LINENO
++# ----------------------
++# Try to preprocess conftest.$ac_ext, and return whether this succeeded.
++ac_fn_c_try_cpp ()
++{
++  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
++  if { { ac_try="$ac_cpp conftest.$ac_ext"
++case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_cpp conftest.$ac_ext") 2>conftest.err
++  ac_status=$?
++  if test -s conftest.err; then
++    grep -v '^ *+' conftest.err >conftest.er1
++    cat conftest.er1 >&5
++    mv -f conftest.er1 conftest.err
++  fi
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; } > conftest.i && {
++	 test -z "$ac_c_preproc_warn_flag$ac_c_werror_flag" ||
++	 test ! -s conftest.err
++       }; then :
++  ac_retval=0
++else
++  $as_echo "$as_me: failed program was:" >&5
++sed 's/^/| /' conftest.$ac_ext >&5
++
++    ac_retval=1
++fi
++  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
++  as_fn_set_status $ac_retval
++
++} # ac_fn_c_try_cpp
++
++# ac_fn_c_try_link LINENO
++# -----------------------
++# Try to link conftest.$ac_ext, and return whether this succeeded.
++ac_fn_c_try_link ()
++{
++  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
++  rm -f conftest.$ac_objext conftest$ac_exeext
++  if { { ac_try="$ac_link"
++case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_link") 2>conftest.err
++  ac_status=$?
++  if test -s conftest.err; then
++    grep -v '^ *+' conftest.err >conftest.er1
++    cat conftest.er1 >&5
++    mv -f conftest.er1 conftest.err
++  fi
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; } && {
++	 test -z "$ac_c_werror_flag" ||
++	 test ! -s conftest.err
++       } && test -s conftest$ac_exeext && {
++	 test "$cross_compiling" = yes ||
++	 $as_test_x conftest$ac_exeext
++       }; then :
++  ac_retval=0
++else
++  $as_echo "$as_me: failed program was:" >&5
++sed 's/^/| /' conftest.$ac_ext >&5
++
++	ac_retval=1
++fi
++  # Delete the IPA/IPO (Inter Procedural Analysis/Optimization) information
++  # created by the PGI compiler (conftest_ipa8_conftest.oo), as it would
++  # interfere with the next link command; also delete a directory that is
++  # left behind by Apple's compiler.  We do this before executing the actions.
++  rm -rf conftest.dSYM conftest_ipa8_conftest.oo
++  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
++  as_fn_set_status $ac_retval
++
++} # ac_fn_c_try_link
++
++# ac_fn_c_check_header_compile LINENO HEADER VAR INCLUDES
++# -------------------------------------------------------
++# Tests whether HEADER exists and can be compiled using the include files in
++# INCLUDES, setting the cache variable VAR accordingly.
++ac_fn_c_check_header_compile ()
++{
++  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
++$as_echo_n "checking for $2... " >&6; }
++if eval "test \"\${$3+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++$4
++#include <$2>
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "$3=yes"
++else
++  eval "$3=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++eval ac_res=\$$3
++	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
++$as_echo "$ac_res" >&6; }
++  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
++
++} # ac_fn_c_check_header_compile
++
++# ac_fn_c_try_run LINENO
++# ----------------------
++# Try to link conftest.$ac_ext, and return whether this succeeded. Assumes
++# that executables *can* be run.
++ac_fn_c_try_run ()
++{
++  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
++  if { { ac_try="$ac_link"
++case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_link") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; } && { ac_try='./conftest$ac_exeext'
++  { { case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_try") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; }; then :
++  ac_retval=0
++else
++  $as_echo "$as_me: program exited with status $ac_status" >&5
++       $as_echo "$as_me: failed program was:" >&5
++sed 's/^/| /' conftest.$ac_ext >&5
++
++       ac_retval=$ac_status
++fi
++  rm -rf conftest.dSYM conftest_ipa8_conftest.oo
++  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
++  as_fn_set_status $ac_retval
++
++} # ac_fn_c_try_run
++
++# ac_fn_c_check_func LINENO FUNC VAR
++# ----------------------------------
++# Tests whether FUNC exists, setting the cache variable VAR accordingly
++ac_fn_c_check_func ()
++{
++  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
++$as_echo_n "checking for $2... " >&6; }
++if eval "test \"\${$3+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++/* Define $2 to an innocuous variant, in case <limits.h> declares $2.
++   For example, HP-UX 11i <limits.h> declares gettimeofday.  */
++#define $2 innocuous_$2
++
++/* System header to define __stub macros and hopefully few prototypes,
++    which can conflict with char $2 (); below.
++    Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
++    <limits.h> exists even on freestanding compilers.  */
++
++#ifdef __STDC__
++# include <limits.h>
++#else
++# include <assert.h>
++#endif
++
++#undef $2
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char $2 ();
++/* The GNU C library defines this for functions which it implements
++    to always fail with ENOSYS.  Some functions are actually named
++    something starting with __ and the normal name is an alias.  */
++#if defined __stub_$2 || defined __stub___$2
++choke me
++#endif
++
++int
++main ()
++{
++return $2 ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "$3=yes"
++else
++  eval "$3=no"
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++eval ac_res=\$$3
++	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
++$as_echo "$ac_res" >&6; }
++  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
++
++} # ac_fn_c_check_func
++
++# ac_fn_c_check_header_mongrel LINENO HEADER VAR INCLUDES
++# -------------------------------------------------------
++# Tests whether HEADER exists, giving a warning if it cannot be compiled using
++# the include files in INCLUDES and setting the cache variable VAR
++# accordingly.
++ac_fn_c_check_header_mongrel ()
++{
++  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
++  if eval "test \"\${$3+set}\"" = set; then :
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
++$as_echo_n "checking for $2... " >&6; }
++if eval "test \"\${$3+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++fi
++eval ac_res=\$$3
++	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
++$as_echo "$ac_res" >&6; }
++else
++  # Is the header compilable?
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking $2 usability" >&5
++$as_echo_n "checking $2 usability... " >&6; }
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++$4
++#include <$2>
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_header_compiler=yes
++else
++  ac_header_compiler=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_header_compiler" >&5
++$as_echo "$ac_header_compiler" >&6; }
++
++# Is the header present?
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking $2 presence" >&5
++$as_echo_n "checking $2 presence... " >&6; }
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <$2>
++_ACEOF
++if ac_fn_c_try_cpp "$LINENO"; then :
++  ac_header_preproc=yes
++else
++  ac_header_preproc=no
++fi
++rm -f conftest.err conftest.i conftest.$ac_ext
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_header_preproc" >&5
++$as_echo "$ac_header_preproc" >&6; }
++
++# So?  What about this header?
++case $ac_header_compiler:$ac_header_preproc:$ac_c_preproc_warn_flag in #((
++  yes:no: )
++    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: accepted by the compiler, rejected by the preprocessor!" >&5
++$as_echo "$as_me: WARNING: $2: accepted by the compiler, rejected by the preprocessor!" >&2;}
++    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: proceeding with the compiler's result" >&5
++$as_echo "$as_me: WARNING: $2: proceeding with the compiler's result" >&2;}
++    ;;
++  no:yes:* )
++    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: present but cannot be compiled" >&5
++$as_echo "$as_me: WARNING: $2: present but cannot be compiled" >&2;}
++    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2:     check for missing prerequisite headers?" >&5
++$as_echo "$as_me: WARNING: $2:     check for missing prerequisite headers?" >&2;}
++    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: see the Autoconf documentation" >&5
++$as_echo "$as_me: WARNING: $2: see the Autoconf documentation" >&2;}
++    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2:     section \"Present But Cannot Be Compiled\"" >&5
++$as_echo "$as_me: WARNING: $2:     section \"Present But Cannot Be Compiled\"" >&2;}
++    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: proceeding with the compiler's result" >&5
++$as_echo "$as_me: WARNING: $2: proceeding with the compiler's result" >&2;}
++( $as_echo "## ----------------------------------- ##
++## Report this to heimdal-bugs@h5l.org ##
++## ----------------------------------- ##"
++     ) | sed "s/^/$as_me: WARNING:     /" >&2
++    ;;
++esac
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
++$as_echo_n "checking for $2... " >&6; }
++if eval "test \"\${$3+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  eval "$3=\$ac_header_compiler"
++fi
++eval ac_res=\$$3
++	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
++$as_echo "$ac_res" >&6; }
++fi
++  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
++
++} # ac_fn_c_check_header_mongrel
++
++# ac_fn_c_check_type LINENO TYPE VAR INCLUDES
++# -------------------------------------------
++# Tests whether TYPE exists after having included INCLUDES, setting cache
++# variable VAR accordingly.
++ac_fn_c_check_type ()
++{
++  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
++$as_echo_n "checking for $2... " >&6; }
++if eval "test \"\${$3+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  eval "$3=no"
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++$4
++int
++main ()
++{
++if (sizeof ($2))
++	 return 0;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++$4
++int
++main ()
++{
++if (sizeof (($2)))
++	    return 0;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++
++else
++  eval "$3=yes"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++eval ac_res=\$$3
++	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
++$as_echo "$ac_res" >&6; }
++  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
++
++} # ac_fn_c_check_type
++
++# ac_fn_c_check_header_preproc LINENO HEADER VAR
++# ----------------------------------------------
++# Tests whether HEADER is present, setting the cache variable VAR accordingly.
++ac_fn_c_check_header_preproc ()
++{
++  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
++$as_echo_n "checking for $2... " >&6; }
++if eval "test \"\${$3+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <$2>
++_ACEOF
++if ac_fn_c_try_cpp "$LINENO"; then :
++  eval "$3=yes"
++else
++  eval "$3=no"
++fi
++rm -f conftest.err conftest.i conftest.$ac_ext
++fi
++eval ac_res=\$$3
++	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
++$as_echo "$ac_res" >&6; }
++  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
++
++} # ac_fn_c_check_header_preproc
++cat >config.log <<_ACEOF
++This file contains any messages produced by compilers while
++running configure, to aid debugging if configure makes a mistake.
++
++It was created by Heimdal $as_me 1.4.99, which was
++generated by GNU Autoconf 2.67.  Invocation command line was
++
++  $ $0 $@
++
++_ACEOF
++exec 5>>config.log
++{
++cat <<_ASUNAME
++## --------- ##
++## Platform. ##
++## --------- ##
++
++hostname = `(hostname || uname -n) 2>/dev/null | sed 1q`
++uname -m = `(uname -m) 2>/dev/null || echo unknown`
++uname -r = `(uname -r) 2>/dev/null || echo unknown`
++uname -s = `(uname -s) 2>/dev/null || echo unknown`
++uname -v = `(uname -v) 2>/dev/null || echo unknown`
++
++/usr/bin/uname -p = `(/usr/bin/uname -p) 2>/dev/null || echo unknown`
++/bin/uname -X     = `(/bin/uname -X) 2>/dev/null     || echo unknown`
++
++/bin/arch              = `(/bin/arch) 2>/dev/null              || echo unknown`
++/usr/bin/arch -k       = `(/usr/bin/arch -k) 2>/dev/null       || echo unknown`
++/usr/convex/getsysinfo = `(/usr/convex/getsysinfo) 2>/dev/null || echo unknown`
++/usr/bin/hostinfo      = `(/usr/bin/hostinfo) 2>/dev/null      || echo unknown`
++/bin/machine           = `(/bin/machine) 2>/dev/null           || echo unknown`
++/usr/bin/oslevel       = `(/usr/bin/oslevel) 2>/dev/null       || echo unknown`
++/bin/universe          = `(/bin/universe) 2>/dev/null          || echo unknown`
++
++_ASUNAME
++
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    $as_echo "PATH: $as_dir"
++  done
++IFS=$as_save_IFS
++
++} >&5
++
++cat >&5 <<_ACEOF
++
++
++## ----------- ##
++## Core tests. ##
++## ----------- ##
++
++_ACEOF
++
++
++# Keep a trace of the command line.
++# Strip out --no-create and --no-recursion so they do not pile up.
++# Strip out --silent because we don't want to record it for future runs.
++# Also quote any args containing shell meta-characters.
++# Make two passes to allow for proper duplicate-argument suppression.
++ac_configure_args=
++ac_configure_args0=
++ac_configure_args1=
++ac_must_keep_next=false
++for ac_pass in 1 2
++do
++  for ac_arg
++  do
++    case $ac_arg in
++    -no-create | --no-c* | -n | -no-recursion | --no-r*) continue ;;
++    -q | -quiet | --quiet | --quie | --qui | --qu | --q \
++    | -silent | --silent | --silen | --sile | --sil)
++      continue ;;
++    *\'*)
++      ac_arg=`$as_echo "$ac_arg" | sed "s/'/'\\\\\\\\''/g"` ;;
++    esac
++    case $ac_pass in
++    1) as_fn_append ac_configure_args0 " '$ac_arg'" ;;
++    2)
++      as_fn_append ac_configure_args1 " '$ac_arg'"
++      if test $ac_must_keep_next = true; then
++	ac_must_keep_next=false # Got value, back to normal.
++      else
++	case $ac_arg in
++	  *=* | --config-cache | -C | -disable-* | --disable-* \
++	  | -enable-* | --enable-* | -gas | --g* | -nfp | --nf* \
++	  | -q | -quiet | --q* | -silent | --sil* | -v | -verb* \
++	  | -with-* | --with-* | -without-* | --without-* | --x)
++	    case "$ac_configure_args0 " in
++	      "$ac_configure_args1"*" '$ac_arg' "* ) continue ;;
++	    esac
++	    ;;
++	  -* ) ac_must_keep_next=true ;;
++	esac
++      fi
++      as_fn_append ac_configure_args " '$ac_arg'"
++      ;;
++    esac
++  done
++done
++{ ac_configure_args0=; unset ac_configure_args0;}
++{ ac_configure_args1=; unset ac_configure_args1;}
++
++# When interrupted or exit'd, cleanup temporary files, and complete
++# config.log.  We remove comments because anyway the quotes in there
++# would cause problems or look ugly.
++# WARNING: Use '\'' to represent an apostrophe within the trap.
++# WARNING: Do not start the trap code with a newline, due to a FreeBSD 4.0 bug.
++trap 'exit_status=$?
++  # Save into config.log some information that might help in debugging.
++  {
++    echo
++
++    $as_echo "## ---------------- ##
++## Cache variables. ##
++## ---------------- ##"
++    echo
++    # The following way of writing the cache mishandles newlines in values,
++(
++  for ac_var in `(set) 2>&1 | sed -n '\''s/^\([a-zA-Z_][a-zA-Z0-9_]*\)=.*/\1/p'\''`; do
++    eval ac_val=\$$ac_var
++    case $ac_val in #(
++    *${as_nl}*)
++      case $ac_var in #(
++      *_cv_*) { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: cache variable $ac_var contains a newline" >&5
++$as_echo "$as_me: WARNING: cache variable $ac_var contains a newline" >&2;} ;;
++      esac
++      case $ac_var in #(
++      _ | IFS | as_nl) ;; #(
++      BASH_ARGV | BASH_SOURCE) eval $ac_var= ;; #(
++      *) { eval $ac_var=; unset $ac_var;} ;;
++      esac ;;
++    esac
++  done
++  (set) 2>&1 |
++    case $as_nl`(ac_space='\'' '\''; set) 2>&1` in #(
++    *${as_nl}ac_space=\ *)
++      sed -n \
++	"s/'\''/'\''\\\\'\'''\''/g;
++	  s/^\\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\\)=\\(.*\\)/\\1='\''\\2'\''/p"
++      ;; #(
++    *)
++      sed -n "/^[_$as_cr_alnum]*_cv_[_$as_cr_alnum]*=/p"
++      ;;
++    esac |
++    sort
++)
++    echo
++
++    $as_echo "## ----------------- ##
++## Output variables. ##
++## ----------------- ##"
++    echo
++    for ac_var in $ac_subst_vars
++    do
++      eval ac_val=\$$ac_var
++      case $ac_val in
++      *\'\''*) ac_val=`$as_echo "$ac_val" | sed "s/'\''/'\''\\\\\\\\'\'''\''/g"`;;
++      esac
++      $as_echo "$ac_var='\''$ac_val'\''"
++    done | sort
++    echo
++
++    if test -n "$ac_subst_files"; then
++      $as_echo "## ------------------- ##
++## File substitutions. ##
++## ------------------- ##"
++      echo
++      for ac_var in $ac_subst_files
++      do
++	eval ac_val=\$$ac_var
++	case $ac_val in
++	*\'\''*) ac_val=`$as_echo "$ac_val" | sed "s/'\''/'\''\\\\\\\\'\'''\''/g"`;;
++	esac
++	$as_echo "$ac_var='\''$ac_val'\''"
++      done | sort
++      echo
++    fi
++
++    if test -s confdefs.h; then
++      $as_echo "## ----------- ##
++## confdefs.h. ##
++## ----------- ##"
++      echo
++      cat confdefs.h
++      echo
++    fi
++    test "$ac_signal" != 0 &&
++      $as_echo "$as_me: caught signal $ac_signal"
++    $as_echo "$as_me: exit $exit_status"
++  } >&5
++  rm -f core *.core core.conftest.* &&
++    rm -f -r conftest* confdefs* conf$$* $ac_clean_files &&
++    exit $exit_status
++' 0
++for ac_signal in 1 2 13 15; do
++  trap 'ac_signal='$ac_signal'; as_fn_exit 1' $ac_signal
++done
++ac_signal=0
++
++# confdefs.h avoids OS command line length limits that DEFS can exceed.
++rm -f -r conftest* confdefs.h
++
++$as_echo "/* confdefs.h */" > confdefs.h
++
++# Predefined preprocessor variables.
++
++cat >>confdefs.h <<_ACEOF
++#define PACKAGE_NAME "$PACKAGE_NAME"
++_ACEOF
++
++cat >>confdefs.h <<_ACEOF
++#define PACKAGE_TARNAME "$PACKAGE_TARNAME"
++_ACEOF
++
++cat >>confdefs.h <<_ACEOF
++#define PACKAGE_VERSION "$PACKAGE_VERSION"
++_ACEOF
++
++cat >>confdefs.h <<_ACEOF
++#define PACKAGE_STRING "$PACKAGE_STRING"
++_ACEOF
++
++cat >>confdefs.h <<_ACEOF
++#define PACKAGE_BUGREPORT "$PACKAGE_BUGREPORT"
++_ACEOF
++
++cat >>confdefs.h <<_ACEOF
++#define PACKAGE_URL "$PACKAGE_URL"
++_ACEOF
++
++
++# Let the site file select an alternate cache file if it wants to.
++# Prefer an explicitly selected file to automatically selected ones.
++ac_site_file1=NONE
++ac_site_file2=NONE
++if test -n "$CONFIG_SITE"; then
++  # We do not want a PATH search for config.site.
++  case $CONFIG_SITE in #((
++    -*)  ac_site_file1=./$CONFIG_SITE;;
++    */*) ac_site_file1=$CONFIG_SITE;;
++    *)   ac_site_file1=./$CONFIG_SITE;;
++  esac
++elif test "x$prefix" != xNONE; then
++  ac_site_file1=$prefix/share/config.site
++  ac_site_file2=$prefix/etc/config.site
++else
++  ac_site_file1=$ac_default_prefix/share/config.site
++  ac_site_file2=$ac_default_prefix/etc/config.site
++fi
++for ac_site_file in "$ac_site_file1" "$ac_site_file2"
++do
++  test "x$ac_site_file" = xNONE && continue
++  if test /dev/null != "$ac_site_file" && test -r "$ac_site_file"; then
++    { $as_echo "$as_me:${as_lineno-$LINENO}: loading site script $ac_site_file" >&5
++$as_echo "$as_me: loading site script $ac_site_file" >&6;}
++    sed 's/^/| /' "$ac_site_file" >&5
++    . "$ac_site_file" \
++      || { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
++$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
++as_fn_error $? "failed to load site script $ac_site_file
++See \`config.log' for more details" "$LINENO" 5 ; }
++  fi
++done
++
++if test -r "$cache_file"; then
++  # Some versions of bash will fail to source /dev/null (special files
++  # actually), so we avoid doing that.  DJGPP emulates it as a regular file.
++  if test /dev/null != "$cache_file" && test -f "$cache_file"; then
++    { $as_echo "$as_me:${as_lineno-$LINENO}: loading cache $cache_file" >&5
++$as_echo "$as_me: loading cache $cache_file" >&6;}
++    case $cache_file in
++      [\\/]* | ?:[\\/]* ) . "$cache_file";;
++      *)                      . "./$cache_file";;
++    esac
++  fi
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: creating cache $cache_file" >&5
++$as_echo "$as_me: creating cache $cache_file" >&6;}
++  >$cache_file
++fi
++
++as_fn_append ac_header_list " stdlib.h"
++as_fn_append ac_header_list " unistd.h"
++as_fn_append ac_header_list " sys/param.h"
++# Check that the precious variables saved in the cache have kept the same
++# value.
++ac_cache_corrupted=false
++for ac_var in $ac_precious_vars; do
++  eval ac_old_set=\$ac_cv_env_${ac_var}_set
++  eval ac_new_set=\$ac_env_${ac_var}_set
++  eval ac_old_val=\$ac_cv_env_${ac_var}_value
++  eval ac_new_val=\$ac_env_${ac_var}_value
++  case $ac_old_set,$ac_new_set in
++    set,)
++      { $as_echo "$as_me:${as_lineno-$LINENO}: error: \`$ac_var' was set to \`$ac_old_val' in the previous run" >&5
++$as_echo "$as_me: error: \`$ac_var' was set to \`$ac_old_val' in the previous run" >&2;}
++      ac_cache_corrupted=: ;;
++    ,set)
++      { $as_echo "$as_me:${as_lineno-$LINENO}: error: \`$ac_var' was not set in the previous run" >&5
++$as_echo "$as_me: error: \`$ac_var' was not set in the previous run" >&2;}
++      ac_cache_corrupted=: ;;
++    ,);;
++    *)
++      if test "x$ac_old_val" != "x$ac_new_val"; then
++	# differences in whitespace do not lead to failure.
++	ac_old_val_w=`echo x $ac_old_val`
++	ac_new_val_w=`echo x $ac_new_val`
++	if test "$ac_old_val_w" != "$ac_new_val_w"; then
++	  { $as_echo "$as_me:${as_lineno-$LINENO}: error: \`$ac_var' has changed since the previous run:" >&5
++$as_echo "$as_me: error: \`$ac_var' has changed since the previous run:" >&2;}
++	  ac_cache_corrupted=:
++	else
++	  { $as_echo "$as_me:${as_lineno-$LINENO}: warning: ignoring whitespace changes in \`$ac_var' since the previous run:" >&5
++$as_echo "$as_me: warning: ignoring whitespace changes in \`$ac_var' since the previous run:" >&2;}
++	  eval $ac_var=\$ac_old_val
++	fi
++	{ $as_echo "$as_me:${as_lineno-$LINENO}:   former value:  \`$ac_old_val'" >&5
++$as_echo "$as_me:   former value:  \`$ac_old_val'" >&2;}
++	{ $as_echo "$as_me:${as_lineno-$LINENO}:   current value: \`$ac_new_val'" >&5
++$as_echo "$as_me:   current value: \`$ac_new_val'" >&2;}
++      fi;;
++  esac
++  # Pass precious variables to config.status.
++  if test "$ac_new_set" = set; then
++    case $ac_new_val in
++    *\'*) ac_arg=$ac_var=`$as_echo "$ac_new_val" | sed "s/'/'\\\\\\\\''/g"` ;;
++    *) ac_arg=$ac_var=$ac_new_val ;;
++    esac
++    case " $ac_configure_args " in
++      *" '$ac_arg' "*) ;; # Avoid dups.  Use of quotes ensures accuracy.
++      *) as_fn_append ac_configure_args " '$ac_arg'" ;;
++    esac
++  fi
++done
++if $ac_cache_corrupted; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
++$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
++  { $as_echo "$as_me:${as_lineno-$LINENO}: error: changes in the environment can compromise the build" >&5
++$as_echo "$as_me: error: changes in the environment can compromise the build" >&2;}
++  as_fn_error $? "run \`make distclean' and/or \`rm $cache_file' and start over" "$LINENO" 5
++fi
++## -------------------- ##
++## Main body of script. ##
++## -------------------- ##
++
++ac_ext=c
++ac_cpp='$CPP $CPPFLAGS'
++ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
++ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
++ac_compiler_gnu=$ac_cv_c_compiler_gnu
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether to enable maintainer-specific portions of Makefiles" >&5
++$as_echo_n "checking whether to enable maintainer-specific portions of Makefiles... " >&6; }
++    # Check whether --enable-maintainer-mode was given.
++if test "${enable_maintainer_mode+set}" = set; then :
++  enableval=$enable_maintainer_mode; USE_MAINTAINER_MODE=$enableval
++else
++  USE_MAINTAINER_MODE=no
++fi
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $USE_MAINTAINER_MODE" >&5
++$as_echo "$USE_MAINTAINER_MODE" >&6; }
++   if test $USE_MAINTAINER_MODE = yes; then
++  MAINTAINER_MODE_TRUE=
++  MAINTAINER_MODE_FALSE='#'
++else
++  MAINTAINER_MODE_TRUE='#'
++  MAINTAINER_MODE_FALSE=
++fi
++
++  MAINT=$MAINTAINER_MODE_TRUE
++
++
++
++ac_config_headers="$ac_config_headers include/config.h"
++
++
++
++am__api_version='1.11'
++
++ac_aux_dir=
++for ac_dir in "$srcdir" "$srcdir/.." "$srcdir/../.."; do
++  if test -f "$ac_dir/install-sh"; then
++    ac_aux_dir=$ac_dir
++    ac_install_sh="$ac_aux_dir/install-sh -c"
++    break
++  elif test -f "$ac_dir/install.sh"; then
++    ac_aux_dir=$ac_dir
++    ac_install_sh="$ac_aux_dir/install.sh -c"
++    break
++  elif test -f "$ac_dir/shtool"; then
++    ac_aux_dir=$ac_dir
++    ac_install_sh="$ac_aux_dir/shtool install -c"
++    break
++  fi
++done
++if test -z "$ac_aux_dir"; then
++  as_fn_error $? "cannot find install-sh, install.sh, or shtool in \"$srcdir\" \"$srcdir/..\" \"$srcdir/../..\"" "$LINENO" 5
++fi
++
++# These three variables are undocumented and unsupported,
++# and are intended to be withdrawn in a future Autoconf release.
++# They can cause serious problems if a builder's source tree is in a directory
++# whose full name contains unusual characters.
++ac_config_guess="$SHELL $ac_aux_dir/config.guess"  # Please don't use this var.
++ac_config_sub="$SHELL $ac_aux_dir/config.sub"  # Please don't use this var.
++ac_configure="$SHELL $ac_aux_dir/configure"  # Please don't use this var.
++
++
++# Find a good install program.  We prefer a C program (faster),
++# so one script is as good as another.  But avoid the broken or
++# incompatible versions:
++# SysV /etc/install, /usr/sbin/install
++# SunOS /usr/etc/install
++# IRIX /sbin/install
++# AIX /bin/install
++# AmigaOS /C/install, which installs bootblocks on floppy discs
++# AIX 4 /usr/bin/installbsd, which doesn't work without a -g flag
++# AFS /usr/afsws/bin/install, which mishandles nonexistent args
++# SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff"
++# OS/2's system install, which has a completely different semantic
++# ./install, which can be erroneously created by make from ./install.sh.
++# Reject install programs that cannot install multiple files.
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for a BSD-compatible install" >&5
++$as_echo_n "checking for a BSD-compatible install... " >&6; }
++if test -z "$INSTALL"; then
++if test "${ac_cv_path_install+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    # Account for people who put trailing slashes in PATH elements.
++case $as_dir/ in #((
++  ./ | .// | /[cC]/* | \
++  /etc/* | /usr/sbin/* | /usr/etc/* | /sbin/* | /usr/afsws/bin/* | \
++  ?:[\\/]os2[\\/]install[\\/]* | ?:[\\/]OS2[\\/]INSTALL[\\/]* | \
++  /usr/ucb/* ) ;;
++  *)
++    # OSF1 and SCO ODT 3.0 have their own names for install.
++    # Don't use installbsd from OSF since it installs stuff as root
++    # by default.
++    for ac_prog in ginstall scoinst install; do
++      for ac_exec_ext in '' $ac_executable_extensions; do
++	if { test -f "$as_dir/$ac_prog$ac_exec_ext" && $as_test_x "$as_dir/$ac_prog$ac_exec_ext"; }; then
++	  if test $ac_prog = install &&
++	    grep dspmsg "$as_dir/$ac_prog$ac_exec_ext" >/dev/null 2>&1; then
++	    # AIX install.  It has an incompatible calling convention.
++	    :
++	  elif test $ac_prog = install &&
++	    grep pwplus "$as_dir/$ac_prog$ac_exec_ext" >/dev/null 2>&1; then
++	    # program-specific install script used by HP pwplus--don't use.
++	    :
++	  else
++	    rm -rf conftest.one conftest.two conftest.dir
++	    echo one > conftest.one
++	    echo two > conftest.two
++	    mkdir conftest.dir
++	    if "$as_dir/$ac_prog$ac_exec_ext" -c conftest.one conftest.two "`pwd`/conftest.dir" &&
++	      test -s conftest.one && test -s conftest.two &&
++	      test -s conftest.dir/conftest.one &&
++	      test -s conftest.dir/conftest.two
++	    then
++	      ac_cv_path_install="$as_dir/$ac_prog$ac_exec_ext -c"
++	      break 3
++	    fi
++	  fi
++	fi
++      done
++    done
++    ;;
++esac
++
++  done
++IFS=$as_save_IFS
++
++rm -rf conftest.one conftest.two conftest.dir
++
++fi
++  if test "${ac_cv_path_install+set}" = set; then
++    INSTALL=$ac_cv_path_install
++  else
++    # As a last resort, use the slow shell script.  Don't cache a
++    # value for INSTALL within a source directory, because that will
++    # break other packages using the cache if that directory is
++    # removed, or if the value is a relative name.
++    INSTALL=$ac_install_sh
++  fi
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $INSTALL" >&5
++$as_echo "$INSTALL" >&6; }
++
++# Use test -z because SunOS4 sh mishandles braces in ${var-val}.
++# It thinks the first close brace ends the variable substitution.
++test -z "$INSTALL_PROGRAM" && INSTALL_PROGRAM='${INSTALL}'
++
++test -z "$INSTALL_SCRIPT" && INSTALL_SCRIPT='${INSTALL}'
++
++test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether build environment is sane" >&5
++$as_echo_n "checking whether build environment is sane... " >&6; }
++# Just in case
++sleep 1
++echo timestamp > conftest.file
++# Reject unsafe characters in $srcdir or the absolute working directory
++# name.  Accept space and tab only in the latter.
++am_lf='
++'
++case `pwd` in
++  *[\\\"\#\$\&\'\`$am_lf]*)
++    as_fn_error $? "unsafe absolute working directory name" "$LINENO" 5 ;;
++esac
++case $srcdir in
++  *[\\\"\#\$\&\'\`$am_lf\ \	]*)
++    as_fn_error $? "unsafe srcdir value: \`$srcdir'" "$LINENO" 5 ;;
++esac
++
++# Do `set' in a subshell so we don't clobber the current shell's
++# arguments.  Must try -L first in case configure is actually a
++# symlink; some systems play weird games with the mod time of symlinks
++# (eg FreeBSD returns the mod time of the symlink's containing
++# directory).
++if (
++   set X `ls -Lt "$srcdir/configure" conftest.file 2> /dev/null`
++   if test "$*" = "X"; then
++      # -L didn't work.
++      set X `ls -t "$srcdir/configure" conftest.file`
++   fi
++   rm -f conftest.file
++   if test "$*" != "X $srcdir/configure conftest.file" \
++      && test "$*" != "X conftest.file $srcdir/configure"; then
++
++      # If neither matched, then we have a broken ls.  This can happen
++      # if, for instance, CONFIG_SHELL is bash and it inherits a
++      # broken ls alias from the environment.  This has actually
++      # happened.  Such a system could not be considered "sane".
++      as_fn_error $? "ls -t appears to fail.  Make sure there is not a broken
++alias in your environment" "$LINENO" 5
++   fi
++
++   test "$2" = conftest.file
++   )
++then
++   # Ok.
++   :
++else
++   as_fn_error $? "newly created file is older than distributed files!
++Check your system clock" "$LINENO" 5
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++test "$program_prefix" != NONE &&
++  program_transform_name="s&^&$program_prefix&;$program_transform_name"
++# Use a double $ so make ignores it.
++test "$program_suffix" != NONE &&
++  program_transform_name="s&\$&$program_suffix&;$program_transform_name"
++# Double any \ or $.
++# By default was `s,x,x', remove it if useless.
++ac_script='s/[\\$]/&&/g;s/;s,x,x,$//'
++program_transform_name=`$as_echo "$program_transform_name" | sed "$ac_script"`
++
++# expand $ac_aux_dir to an absolute path
++am_aux_dir=`cd $ac_aux_dir && pwd`
++
++if test x"${MISSING+set}" != xset; then
++  case $am_aux_dir in
++  *\ * | *\	*)
++    MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
++  *)
++    MISSING="\${SHELL} $am_aux_dir/missing" ;;
++  esac
++fi
++# Use eval to expand $SHELL
++if eval "$MISSING --run true"; then
++  am_missing_run="$MISSING --run "
++else
++  am_missing_run=
++  { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: \`missing' script is too old or missing" >&5
++$as_echo "$as_me: WARNING: \`missing' script is too old or missing" >&2;}
++fi
++
++if test x"${install_sh}" != xset; then
++  case $am_aux_dir in
++  *\ * | *\	*)
++    install_sh="\${SHELL} '$am_aux_dir/install-sh'" ;;
++  *)
++    install_sh="\${SHELL} $am_aux_dir/install-sh"
++  esac
++fi
++
++# Installed binaries are usually stripped using `strip' when the user
++# run `make install-strip'.  However `strip' might not be the right
++# tool to use in cross-compilation environments, therefore Automake
++# will honor the `STRIP' environment variable to overrule this program.
++if test "$cross_compiling" != no; then
++  if test -n "$ac_tool_prefix"; then
++  # Extract the first word of "${ac_tool_prefix}strip", so it can be a program name with args.
++set dummy ${ac_tool_prefix}strip; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_STRIP+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$STRIP"; then
++  ac_cv_prog_STRIP="$STRIP" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_STRIP="${ac_tool_prefix}strip"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++STRIP=$ac_cv_prog_STRIP
++if test -n "$STRIP"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $STRIP" >&5
++$as_echo "$STRIP" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++fi
++if test -z "$ac_cv_prog_STRIP"; then
++  ac_ct_STRIP=$STRIP
++  # Extract the first word of "strip", so it can be a program name with args.
++set dummy strip; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_ac_ct_STRIP+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$ac_ct_STRIP"; then
++  ac_cv_prog_ac_ct_STRIP="$ac_ct_STRIP" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_ac_ct_STRIP="strip"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++ac_ct_STRIP=$ac_cv_prog_ac_ct_STRIP
++if test -n "$ac_ct_STRIP"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_STRIP" >&5
++$as_echo "$ac_ct_STRIP" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++  if test "x$ac_ct_STRIP" = x; then
++    STRIP=":"
++  else
++    case $cross_compiling:$ac_tool_warned in
++yes:)
++{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
++$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
++ac_tool_warned=yes ;;
++esac
++    STRIP=$ac_ct_STRIP
++  fi
++else
++  STRIP="$ac_cv_prog_STRIP"
++fi
++
++fi
++INSTALL_STRIP_PROGRAM="\$(install_sh) -c -s"
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for a thread-safe mkdir -p" >&5
++$as_echo_n "checking for a thread-safe mkdir -p... " >&6; }
++if test -z "$MKDIR_P"; then
++  if test "${ac_cv_path_mkdir+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH$PATH_SEPARATOR/opt/sfw/bin
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_prog in mkdir gmkdir; do
++	 for ac_exec_ext in '' $ac_executable_extensions; do
++	   { test -f "$as_dir/$ac_prog$ac_exec_ext" && $as_test_x "$as_dir/$ac_prog$ac_exec_ext"; } || continue
++	   case `"$as_dir/$ac_prog$ac_exec_ext" --version 2>&1` in #(
++	     'mkdir (GNU coreutils) '* | \
++	     'mkdir (coreutils) '* | \
++	     'mkdir (fileutils) '4.1*)
++	       ac_cv_path_mkdir=$as_dir/$ac_prog$ac_exec_ext
++	       break 3;;
++	   esac
++	 done
++       done
++  done
++IFS=$as_save_IFS
++
++fi
++
++  test -d ./--version && rmdir ./--version
++  if test "${ac_cv_path_mkdir+set}" = set; then
++    MKDIR_P="$ac_cv_path_mkdir -p"
++  else
++    # As a last resort, use the slow shell script.  Don't cache a
++    # value for MKDIR_P within a source directory, because that will
++    # break other packages using the cache if that directory is
++    # removed, or if the value is a relative name.
++    MKDIR_P="$ac_install_sh -d"
++  fi
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $MKDIR_P" >&5
++$as_echo "$MKDIR_P" >&6; }
++
++mkdir_p="$MKDIR_P"
++case $mkdir_p in
++  [\\/$]* | ?:[\\/]*) ;;
++  */*) mkdir_p="\$(top_builddir)/$mkdir_p" ;;
++esac
++
++for ac_prog in gawk mawk nawk awk
++do
++  # Extract the first word of "$ac_prog", so it can be a program name with args.
++set dummy $ac_prog; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_AWK+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$AWK"; then
++  ac_cv_prog_AWK="$AWK" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_AWK="$ac_prog"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++AWK=$ac_cv_prog_AWK
++if test -n "$AWK"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $AWK" >&5
++$as_echo "$AWK" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++  test -n "$AWK" && break
++done
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ${MAKE-make} sets \$(MAKE)" >&5
++$as_echo_n "checking whether ${MAKE-make} sets \$(MAKE)... " >&6; }
++set x ${MAKE-make}
++ac_make=`$as_echo "$2" | sed 's/+/p/g; s/[^a-zA-Z0-9_]/_/g'`
++if eval "test \"\${ac_cv_prog_make_${ac_make}_set+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat >conftest.make <<\_ACEOF
++SHELL = /bin/sh
++all:
++	@echo '@@@%%%=$(MAKE)=@@@%%%'
++_ACEOF
++# GNU make sometimes prints "make[1]: Entering ...", which would confuse us.
++case `${MAKE-make} -f conftest.make 2>/dev/null` in
++  *@@@%%%=?*=@@@%%%*)
++    eval ac_cv_prog_make_${ac_make}_set=yes;;
++  *)
++    eval ac_cv_prog_make_${ac_make}_set=no;;
++esac
++rm -f conftest.make
++fi
++if eval test \$ac_cv_prog_make_${ac_make}_set = yes; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++  SET_MAKE=
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++  SET_MAKE="MAKE=${MAKE-make}"
++fi
++
++rm -rf .tst 2>/dev/null
++mkdir .tst 2>/dev/null
++if test -d .tst; then
++  am__leading_dot=.
++else
++  am__leading_dot=_
++fi
++rmdir .tst 2>/dev/null
++
++if test "`cd $srcdir && pwd`" != "`pwd`"; then
++  # Use -I$(srcdir) only when $(srcdir) != ., so that make's output
++  # is not polluted with repeated "-I."
++  am__isrc=' -I$(srcdir)'
++  # test to see if srcdir already configured
++  if test -f $srcdir/config.status; then
++    as_fn_error $? "source directory already configured; run \"make distclean\" there first" "$LINENO" 5
++  fi
++fi
++
++# test whether we have cygpath
++if test -z "$CYGPATH_W"; then
++  if (cygpath --version) >/dev/null 2>/dev/null; then
++    CYGPATH_W='cygpath -w'
++  else
++    CYGPATH_W=echo
++  fi
++fi
++
++
++# Define the identity of the package.
++ PACKAGE='heimdal'
++ VERSION='1.4.99'
++
++
++cat >>confdefs.h <<_ACEOF
++#define PACKAGE "$PACKAGE"
++_ACEOF
++
++
++cat >>confdefs.h <<_ACEOF
++#define VERSION "$VERSION"
++_ACEOF
++
++# Some tools Automake needs.
++
++ACLOCAL=${ACLOCAL-"${am_missing_run}aclocal-${am__api_version}"}
++
++
++AUTOCONF=${AUTOCONF-"${am_missing_run}autoconf"}
++
++
++AUTOMAKE=${AUTOMAKE-"${am_missing_run}automake-${am__api_version}"}
++
++
++AUTOHEADER=${AUTOHEADER-"${am_missing_run}autoheader"}
++
++
++MAKEINFO=${MAKEINFO-"${am_missing_run}makeinfo"}
++
++# We need awk for the "check" target.  The system "awk" is bad on
++# some platforms.
++# Always define AMTAR for backward compatibility.
++
++AMTAR=${AMTAR-"${am_missing_run}tar"}
++
++am__tar='${AMTAR} chof - "$$tardir"'; am__untar='${AMTAR} xf -'
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether to enable maintainer-specific portions of Makefiles" >&5
++$as_echo_n "checking whether to enable maintainer-specific portions of Makefiles... " >&6; }
++    # Check whether --enable-maintainer-mode was given.
++if test "${enable_maintainer_mode+set}" = set; then :
++  enableval=$enable_maintainer_mode; USE_MAINTAINER_MODE=$enableval
++else
++  USE_MAINTAINER_MODE=no
++fi
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $USE_MAINTAINER_MODE" >&5
++$as_echo "$USE_MAINTAINER_MODE" >&6; }
++   if test $USE_MAINTAINER_MODE = yes; then
++  MAINTAINER_MODE_TRUE=
++  MAINTAINER_MODE_FALSE='#'
++else
++  MAINTAINER_MODE_TRUE='#'
++  MAINTAINER_MODE_FALSE=
++fi
++
++  MAINT=$MAINTAINER_MODE_TRUE
++
++
++
++ac_ext=c
++ac_cpp='$CPP $CPPFLAGS'
++ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
++ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
++ac_compiler_gnu=$ac_cv_c_compiler_gnu
++if test -n "$ac_tool_prefix"; then
++  # Extract the first word of "${ac_tool_prefix}gcc", so it can be a program name with args.
++set dummy ${ac_tool_prefix}gcc; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_CC+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$CC"; then
++  ac_cv_prog_CC="$CC" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_CC="${ac_tool_prefix}gcc"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++CC=$ac_cv_prog_CC
++if test -n "$CC"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $CC" >&5
++$as_echo "$CC" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++fi
++if test -z "$ac_cv_prog_CC"; then
++  ac_ct_CC=$CC
++  # Extract the first word of "gcc", so it can be a program name with args.
++set dummy gcc; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$ac_ct_CC"; then
++  ac_cv_prog_ac_ct_CC="$ac_ct_CC" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_ac_ct_CC="gcc"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++ac_ct_CC=$ac_cv_prog_ac_ct_CC
++if test -n "$ac_ct_CC"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_CC" >&5
++$as_echo "$ac_ct_CC" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++  if test "x$ac_ct_CC" = x; then
++    CC=""
++  else
++    case $cross_compiling:$ac_tool_warned in
++yes:)
++{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
++$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
++ac_tool_warned=yes ;;
++esac
++    CC=$ac_ct_CC
++  fi
++else
++  CC="$ac_cv_prog_CC"
++fi
++
++if test -z "$CC"; then
++          if test -n "$ac_tool_prefix"; then
++    # Extract the first word of "${ac_tool_prefix}cc", so it can be a program name with args.
++set dummy ${ac_tool_prefix}cc; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_CC+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$CC"; then
++  ac_cv_prog_CC="$CC" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_CC="${ac_tool_prefix}cc"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++CC=$ac_cv_prog_CC
++if test -n "$CC"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $CC" >&5
++$as_echo "$CC" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++  fi
++fi
++if test -z "$CC"; then
++  # Extract the first word of "cc", so it can be a program name with args.
++set dummy cc; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_CC+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$CC"; then
++  ac_cv_prog_CC="$CC" # Let the user override the test.
++else
++  ac_prog_rejected=no
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    if test "$as_dir/$ac_word$ac_exec_ext" = "/usr/ucb/cc"; then
++       ac_prog_rejected=yes
++       continue
++     fi
++    ac_cv_prog_CC="cc"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++if test $ac_prog_rejected = yes; then
++  # We found a bogon in the path, so make sure we never use it.
++  set dummy $ac_cv_prog_CC
++  shift
++  if test $# != 0; then
++    # We chose a different compiler from the bogus one.
++    # However, it has the same basename, so the bogon will be chosen
++    # first if we set CC to just the basename; use the full file name.
++    shift
++    ac_cv_prog_CC="$as_dir/$ac_word${1+' '}$@"
++  fi
++fi
++fi
++fi
++CC=$ac_cv_prog_CC
++if test -n "$CC"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $CC" >&5
++$as_echo "$CC" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++fi
++if test -z "$CC"; then
++  if test -n "$ac_tool_prefix"; then
++  for ac_prog in cl.exe
++  do
++    # Extract the first word of "$ac_tool_prefix$ac_prog", so it can be a program name with args.
++set dummy $ac_tool_prefix$ac_prog; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_CC+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$CC"; then
++  ac_cv_prog_CC="$CC" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_CC="$ac_tool_prefix$ac_prog"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++CC=$ac_cv_prog_CC
++if test -n "$CC"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $CC" >&5
++$as_echo "$CC" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++    test -n "$CC" && break
++  done
++fi
++if test -z "$CC"; then
++  ac_ct_CC=$CC
++  for ac_prog in cl.exe
++do
++  # Extract the first word of "$ac_prog", so it can be a program name with args.
++set dummy $ac_prog; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_ac_ct_CC+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$ac_ct_CC"; then
++  ac_cv_prog_ac_ct_CC="$ac_ct_CC" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_ac_ct_CC="$ac_prog"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++ac_ct_CC=$ac_cv_prog_ac_ct_CC
++if test -n "$ac_ct_CC"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_CC" >&5
++$as_echo "$ac_ct_CC" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++  test -n "$ac_ct_CC" && break
++done
++
++  if test "x$ac_ct_CC" = x; then
++    CC=""
++  else
++    case $cross_compiling:$ac_tool_warned in
++yes:)
++{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
++$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
++ac_tool_warned=yes ;;
++esac
++    CC=$ac_ct_CC
++  fi
++fi
++
++fi
++
++
++test -z "$CC" && { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
++$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
++as_fn_error $? "no acceptable C compiler found in \$PATH
++See \`config.log' for more details" "$LINENO" 5 ; }
++
++# Provide some information about the compiler.
++$as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler version" >&5
++set X $ac_compile
++ac_compiler=$2
++for ac_option in --version -v -V -qversion; do
++  { { ac_try="$ac_compiler $ac_option >&5"
++case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_compiler $ac_option >&5") 2>conftest.err
++  ac_status=$?
++  if test -s conftest.err; then
++    sed '10a\
++... rest of stderr output deleted ...
++         10q' conftest.err >conftest.er1
++    cat conftest.er1 >&5
++  fi
++  rm -f conftest.er1 conftest.err
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }
++done
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++ac_clean_files_save=$ac_clean_files
++ac_clean_files="$ac_clean_files a.out a.out.dSYM a.exe b.out"
++# Try to create an executable without -o first, disregard a.out.
++# It will help us diagnose broken compilers, and finding out an intuition
++# of exeext.
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the C compiler works" >&5
++$as_echo_n "checking whether the C compiler works... " >&6; }
++ac_link_default=`$as_echo "$ac_link" | sed 's/ -o *conftest[^ ]*//'`
++
++# The possible output files:
++ac_files="a.out conftest.exe conftest a.exe a_out.exe b.out conftest.*"
++
++ac_rmfiles=
++for ac_file in $ac_files
++do
++  case $ac_file in
++    *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map | *.inf | *.dSYM | *.o | *.obj ) ;;
++    * ) ac_rmfiles="$ac_rmfiles $ac_file";;
++  esac
++done
++rm -f $ac_rmfiles
++
++if { { ac_try="$ac_link_default"
++case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_link_default") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; then :
++  # Autoconf-2.13 could set the ac_cv_exeext variable to `no'.
++# So ignore a value of `no', otherwise this would lead to `EXEEXT = no'
++# in a Makefile.  We should not override ac_cv_exeext if it was cached,
++# so that the user can short-circuit this test for compilers unknown to
++# Autoconf.
++for ac_file in $ac_files ''
++do
++  test -f "$ac_file" || continue
++  case $ac_file in
++    *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map | *.inf | *.dSYM | *.o | *.obj )
++	;;
++    [ab].out )
++	# We found the default executable, but exeext='' is most
++	# certainly right.
++	break;;
++    *.* )
++	if test "${ac_cv_exeext+set}" = set && test "$ac_cv_exeext" != no;
++	then :; else
++	   ac_cv_exeext=`expr "$ac_file" : '[^.]*\(\..*\)'`
++	fi
++	# We set ac_cv_exeext here because the later test for it is not
++	# safe: cross compilers may not add the suffix if given an `-o'
++	# argument, so we may need to know it at that point already.
++	# Even if this section looks crufty: it has the advantage of
++	# actually working.
++	break;;
++    * )
++	break;;
++  esac
++done
++test "$ac_cv_exeext" = no && ac_cv_exeext=
++
++else
++  ac_file=''
++fi
++if test -z "$ac_file"; then :
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++$as_echo "$as_me: failed program was:" >&5
++sed 's/^/| /' conftest.$ac_ext >&5
++
++{ { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
++$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
++as_fn_error 77 "C compiler cannot create executables
++See \`config.log' for more details" "$LINENO" 5 ; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for C compiler default output file name" >&5
++$as_echo_n "checking for C compiler default output file name... " >&6; }
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_file" >&5
++$as_echo "$ac_file" >&6; }
++ac_exeext=$ac_cv_exeext
++
++rm -f -r a.out a.out.dSYM a.exe conftest$ac_cv_exeext b.out
++ac_clean_files=$ac_clean_files_save
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of executables" >&5
++$as_echo_n "checking for suffix of executables... " >&6; }
++if { { ac_try="$ac_link"
++case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_link") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; then :
++  # If both `conftest.exe' and `conftest' are `present' (well, observable)
++# catch `conftest.exe'.  For instance with Cygwin, `ls conftest' will
++# work properly (i.e., refer to `conftest.exe'), while it won't with
++# `rm'.
++for ac_file in conftest.exe conftest conftest.*; do
++  test -f "$ac_file" || continue
++  case $ac_file in
++    *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map | *.inf | *.dSYM | *.o | *.obj ) ;;
++    *.* ) ac_cv_exeext=`expr "$ac_file" : '[^.]*\(\..*\)'`
++	  break;;
++    * ) break;;
++  esac
++done
++else
++  { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
++$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
++as_fn_error $? "cannot compute suffix of executables: cannot compile and link
++See \`config.log' for more details" "$LINENO" 5 ; }
++fi
++rm -f conftest conftest$ac_cv_exeext
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_exeext" >&5
++$as_echo "$ac_cv_exeext" >&6; }
++
++rm -f conftest.$ac_ext
++EXEEXT=$ac_cv_exeext
++ac_exeext=$EXEEXT
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdio.h>
++int
++main ()
++{
++FILE *f = fopen ("conftest.out", "w");
++ return ferror (f) || fclose (f) != 0;
++
++  ;
++  return 0;
++}
++_ACEOF
++ac_clean_files="$ac_clean_files conftest.out"
++# Check that the compiler produces executables we can run.  If not, either
++# the compiler is broken, or we cross compile.
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are cross compiling" >&5
++$as_echo_n "checking whether we are cross compiling... " >&6; }
++if test "$cross_compiling" != yes; then
++  { { ac_try="$ac_link"
++case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_link") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }
++  if { ac_try='./conftest$ac_cv_exeext'
++  { { case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_try") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; }; then
++    cross_compiling=no
++  else
++    if test "$cross_compiling" = maybe; then
++	cross_compiling=yes
++    else
++	{ { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
++$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
++as_fn_error $? "cannot run C compiled programs.
++If you meant to cross compile, use \`--host'.
++See \`config.log' for more details" "$LINENO" 5 ; }
++    fi
++  fi
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $cross_compiling" >&5
++$as_echo "$cross_compiling" >&6; }
++
++rm -f conftest.$ac_ext conftest$ac_cv_exeext conftest.out
++ac_clean_files=$ac_clean_files_save
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of object files" >&5
++$as_echo_n "checking for suffix of object files... " >&6; }
++if test "${ac_cv_objext+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++rm -f conftest.o conftest.obj
++if { { ac_try="$ac_compile"
++case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_compile") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; then :
++  for ac_file in conftest.o conftest.obj conftest.*; do
++  test -f "$ac_file" || continue;
++  case $ac_file in
++    *.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map | *.inf | *.dSYM ) ;;
++    *) ac_cv_objext=`expr "$ac_file" : '.*\.\(.*\)'`
++       break;;
++  esac
++done
++else
++  $as_echo "$as_me: failed program was:" >&5
++sed 's/^/| /' conftest.$ac_ext >&5
++
++{ { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
++$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
++as_fn_error $? "cannot compute suffix of object files: cannot compile
++See \`config.log' for more details" "$LINENO" 5 ; }
++fi
++rm -f conftest.$ac_cv_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_objext" >&5
++$as_echo "$ac_cv_objext" >&6; }
++OBJEXT=$ac_cv_objext
++ac_objext=$OBJEXT
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether we are using the GNU C compiler" >&5
++$as_echo_n "checking whether we are using the GNU C compiler... " >&6; }
++if test "${ac_cv_c_compiler_gnu+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++#ifndef __GNUC__
++       choke me
++#endif
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_compiler_gnu=yes
++else
++  ac_compiler_gnu=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++ac_cv_c_compiler_gnu=$ac_compiler_gnu
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_c_compiler_gnu" >&5
++$as_echo "$ac_cv_c_compiler_gnu" >&6; }
++if test $ac_compiler_gnu = yes; then
++  GCC=yes
++else
++  GCC=
++fi
++ac_test_CFLAGS=${CFLAGS+set}
++ac_save_CFLAGS=$CFLAGS
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC accepts -g" >&5
++$as_echo_n "checking whether $CC accepts -g... " >&6; }
++if test "${ac_cv_prog_cc_g+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_save_c_werror_flag=$ac_c_werror_flag
++   ac_c_werror_flag=yes
++   ac_cv_prog_cc_g=no
++   CFLAGS="-g"
++   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_prog_cc_g=yes
++else
++  CFLAGS=""
++      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++
++else
++  ac_c_werror_flag=$ac_save_c_werror_flag
++	 CFLAGS="-g"
++	 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_prog_cc_g=yes
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++   ac_c_werror_flag=$ac_save_c_werror_flag
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_prog_cc_g" >&5
++$as_echo "$ac_cv_prog_cc_g" >&6; }
++if test "$ac_test_CFLAGS" = set; then
++  CFLAGS=$ac_save_CFLAGS
++elif test $ac_cv_prog_cc_g = yes; then
++  if test "$GCC" = yes; then
++    CFLAGS="-g -O2"
++  else
++    CFLAGS="-g"
++  fi
++else
++  if test "$GCC" = yes; then
++    CFLAGS="-O2"
++  else
++    CFLAGS=
++  fi
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $CC option to accept ISO C89" >&5
++$as_echo_n "checking for $CC option to accept ISO C89... " >&6; }
++if test "${ac_cv_prog_cc_c89+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_cv_prog_cc_c89=no
++ac_save_CC=$CC
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdarg.h>
++#include <stdio.h>
++#include <sys/types.h>
++#include <sys/stat.h>
++/* Most of the following tests are stolen from RCS 5.7's src/conf.sh.  */
++struct buf { int x; };
++FILE * (*rcsopen) (struct buf *, struct stat *, int);
++static char *e (p, i)
++     char **p;
++     int i;
++{
++  return p[i];
++}
++static char *f (char * (*g) (char **, int), char **p, ...)
++{
++  char *s;
++  va_list v;
++  va_start (v,p);
++  s = g (p, va_arg (v,int));
++  va_end (v);
++  return s;
++}
++
++/* OSF 4.0 Compaq cc is some sort of almost-ANSI by default.  It has
++   function prototypes and stuff, but not '\xHH' hex character constants.
++   These don't provoke an error unfortunately, instead are silently treated
++   as 'x'.  The following induces an error, until -std is added to get
++   proper ANSI mode.  Curiously '\x00'!='x' always comes out true, for an
++   array size at least.  It's necessary to write '\x00'==0 to get something
++   that's true only with -std.  */
++int osf4_cc_array ['\x00' == 0 ? 1 : -1];
++
++/* IBM C 6 for AIX is almost-ANSI by default, but it replaces macro parameters
++   inside strings and character constants.  */
++#define FOO(x) 'x'
++int xlc6_cc_array[FOO(a) == 'x' ? 1 : -1];
++
++int test (int i, double x);
++struct s1 {int (*f) (int a);};
++struct s2 {int (*f) (double a);};
++int pairnames (int, char **, FILE *(*)(struct buf *, struct stat *, int), int, int);
++int argc;
++char **argv;
++int
++main ()
++{
++return f (e, argv, 0) != argv[0]  ||  f (e, argv, 1) != argv[1];
++  ;
++  return 0;
++}
++_ACEOF
++for ac_arg in '' -qlanglvl=extc89 -qlanglvl=ansi -std \
++	-Ae "-Aa -D_HPUX_SOURCE" "-Xc -D__EXTENSIONS__"
++do
++  CC="$ac_save_CC $ac_arg"
++  if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_prog_cc_c89=$ac_arg
++fi
++rm -f core conftest.err conftest.$ac_objext
++  test "x$ac_cv_prog_cc_c89" != "xno" && break
++done
++rm -f conftest.$ac_ext
++CC=$ac_save_CC
++
++fi
++# AC_CACHE_VAL
++case "x$ac_cv_prog_cc_c89" in
++  x)
++    { $as_echo "$as_me:${as_lineno-$LINENO}: result: none needed" >&5
++$as_echo "none needed" >&6; } ;;
++  xno)
++    { $as_echo "$as_me:${as_lineno-$LINENO}: result: unsupported" >&5
++$as_echo "unsupported" >&6; } ;;
++  *)
++    CC="$CC $ac_cv_prog_cc_c89"
++    { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_prog_cc_c89" >&5
++$as_echo "$ac_cv_prog_cc_c89" >&6; } ;;
++esac
++if test "x$ac_cv_prog_cc_c89" != xno; then :
++
++fi
++
++ac_ext=c
++ac_cpp='$CPP $CPPFLAGS'
++ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
++ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
++ac_compiler_gnu=$ac_cv_c_compiler_gnu
++DEPDIR="${am__leading_dot}deps"
++
++ac_config_commands="$ac_config_commands depfiles"
++
++
++am_make=${MAKE-make}
++cat > confinc << 'END'
++am__doit:
++	@echo this is the am__doit target
++.PHONY: am__doit
++END
++# If we don't find an include directive, just comment out the code.
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for style of include used by $am_make" >&5
++$as_echo_n "checking for style of include used by $am_make... " >&6; }
++am__include="#"
++am__quote=
++_am_result=none
++# First try GNU make style include.
++echo "include confinc" > confmf
++# Ignore all kinds of additional output from `make'.
++case `$am_make -s -f confmf 2> /dev/null` in #(
++*the\ am__doit\ target*)
++  am__include=include
++  am__quote=
++  _am_result=GNU
++  ;;
++esac
++# Now try BSD make style include.
++if test "$am__include" = "#"; then
++   echo '.include "confinc"' > confmf
++   case `$am_make -s -f confmf 2> /dev/null` in #(
++   *the\ am__doit\ target*)
++     am__include=.include
++     am__quote="\""
++     _am_result=BSD
++     ;;
++   esac
++fi
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $_am_result" >&5
++$as_echo "$_am_result" >&6; }
++rm -f confinc confmf
++
++# Check whether --enable-dependency-tracking was given.
++if test "${enable_dependency_tracking+set}" = set; then :
++  enableval=$enable_dependency_tracking;
++fi
++
++if test "x$enable_dependency_tracking" != xno; then
++  am_depcomp="$ac_aux_dir/depcomp"
++  AMDEPBACKSLASH='\'
++fi
++ if test "x$enable_dependency_tracking" != xno; then
++  AMDEP_TRUE=
++  AMDEP_FALSE='#'
++else
++  AMDEP_TRUE='#'
++  AMDEP_FALSE=
++fi
++
++
++
++depcc="$CC"   am_compiler_list=
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking dependency style of $depcc" >&5
++$as_echo_n "checking dependency style of $depcc... " >&6; }
++if test "${am_cv_CC_dependencies_compiler_type+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -z "$AMDEP_TRUE" && test -f "$am_depcomp"; then
++  # We make a subdir and do the tests there.  Otherwise we can end up
++  # making bogus files that we don't know about and never remove.  For
++  # instance it was reported that on HP-UX the gcc test will end up
++  # making a dummy file named `D' -- because `-MD' means `put the output
++  # in D'.
++  mkdir conftest.dir
++  # Copy depcomp to subdir because otherwise we won't find it if we're
++  # using a relative directory.
++  cp "$am_depcomp" conftest.dir
++  cd conftest.dir
++  # We will build objects and dependencies in a subdirectory because
++  # it helps to detect inapplicable dependency modes.  For instance
++  # both Tru64's cc and ICC support -MD to output dependencies as a
++  # side effect of compilation, but ICC will put the dependencies in
++  # the current directory while Tru64 will put them in the object
++  # directory.
++  mkdir sub
++
++  am_cv_CC_dependencies_compiler_type=none
++  if test "$am_compiler_list" = ""; then
++     am_compiler_list=`sed -n 's/^#*\([a-zA-Z0-9]*\))$/\1/p' < ./depcomp`
++  fi
++  am__universal=false
++  case " $depcc " in #(
++     *\ -arch\ *\ -arch\ *) am__universal=true ;;
++     esac
++
++  for depmode in $am_compiler_list; do
++    # Setup a source with many dependencies, because some compilers
++    # like to wrap large dependency lists on column 80 (with \), and
++    # we should not choose a depcomp mode which is confused by this.
++    #
++    # We need to recreate these files for each test, as the compiler may
++    # overwrite some of them when testing with obscure command lines.
++    # This happens at least with the AIX C compiler.
++    : > sub/conftest.c
++    for i in 1 2 3 4 5 6; do
++      echo '#include "conftst'$i'.h"' >> sub/conftest.c
++      # Using `: > sub/conftst$i.h' creates only sub/conftst1.h with
++      # Solaris 8's {/usr,}/bin/sh.
++      touch sub/conftst$i.h
++    done
++    echo "${am__include} ${am__quote}sub/conftest.Po${am__quote}" > confmf
++
++    # We check with `-c' and `-o' for the sake of the "dashmstdout"
++    # mode.  It turns out that the SunPro C++ compiler does not properly
++    # handle `-M -o', and we need to detect this.  Also, some Intel
++    # versions had trouble with output in subdirs
++    am__obj=sub/conftest.${OBJEXT-o}
++    am__minus_obj="-o $am__obj"
++    case $depmode in
++    gcc)
++      # This depmode causes a compiler race in universal mode.
++      test "$am__universal" = false || continue
++      ;;
++    nosideeffect)
++      # after this tag, mechanisms are not by side-effect, so they'll
++      # only be used when explicitly requested
++      if test "x$enable_dependency_tracking" = xyes; then
++	continue
++      else
++	break
++      fi
++      ;;
++    msvisualcpp | msvcmsys)
++      # This compiler won't grok `-c -o', but also, the minuso test has
++      # not run yet.  These depmodes are late enough in the game, and
++      # so weak that their functioning should not be impacted.
++      am__obj=conftest.${OBJEXT-o}
++      am__minus_obj=
++      ;;
++    none) break ;;
++    esac
++    if depmode=$depmode \
++       source=sub/conftest.c object=$am__obj \
++       depfile=sub/conftest.Po tmpdepfile=sub/conftest.TPo \
++       $SHELL ./depcomp $depcc -c $am__minus_obj sub/conftest.c \
++         >/dev/null 2>conftest.err &&
++       grep sub/conftst1.h sub/conftest.Po > /dev/null 2>&1 &&
++       grep sub/conftst6.h sub/conftest.Po > /dev/null 2>&1 &&
++       grep $am__obj sub/conftest.Po > /dev/null 2>&1 &&
++       ${MAKE-make} -s -f confmf > /dev/null 2>&1; then
++      # icc doesn't choke on unknown options, it will just issue warnings
++      # or remarks (even with -Werror).  So we grep stderr for any message
++      # that says an option was ignored or not supported.
++      # When given -MP, icc 7.0 and 7.1 complain thusly:
++      #   icc: Command line warning: ignoring option '-M'; no argument required
++      # The diagnosis changed in icc 8.0:
++      #   icc: Command line remark: option '-MP' not supported
++      if (grep 'ignoring option' conftest.err ||
++          grep 'not supported' conftest.err) >/dev/null 2>&1; then :; else
++        am_cv_CC_dependencies_compiler_type=$depmode
++        break
++      fi
++    fi
++  done
++
++  cd ..
++  rm -rf conftest.dir
++else
++  am_cv_CC_dependencies_compiler_type=none
++fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $am_cv_CC_dependencies_compiler_type" >&5
++$as_echo "$am_cv_CC_dependencies_compiler_type" >&6; }
++CCDEPMODE=depmode=$am_cv_CC_dependencies_compiler_type
++
++ if
++  test "x$enable_dependency_tracking" != xno \
++  && test "$am_cv_CC_dependencies_compiler_type" = gcc3; then
++  am__fastdepCC_TRUE=
++  am__fastdepCC_FALSE='#'
++else
++  am__fastdepCC_TRUE='#'
++  am__fastdepCC_FALSE=
++fi
++
++
++if test "x$CC" != xcc; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $CC and cc understand -c and -o together" >&5
++$as_echo_n "checking whether $CC and cc understand -c and -o together... " >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether cc understands -c and -o together" >&5
++$as_echo_n "checking whether cc understands -c and -o together... " >&6; }
++fi
++set dummy $CC; ac_cc=`$as_echo "$2" |
++		      sed 's/[^a-zA-Z0-9_]/_/g;s/^[0-9]/_/'`
++if eval "test \"\${ac_cv_prog_cc_${ac_cc}_c_o+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++# Make sure it works both with $CC and with simple cc.
++# We do the test twice because some compilers refuse to overwrite an
++# existing .o file with -o, though they will create one.
++ac_try='$CC -c conftest.$ac_ext -o conftest2.$ac_objext >&5'
++rm -f conftest2.*
++if { { case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_try") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; } &&
++   test -f conftest2.$ac_objext && { { case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_try") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; };
++then
++  eval ac_cv_prog_cc_${ac_cc}_c_o=yes
++  if test "x$CC" != xcc; then
++    # Test first that cc exists at all.
++    if { ac_try='cc -c conftest.$ac_ext >&5'
++  { { case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_try") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; }; then
++      ac_try='cc -c conftest.$ac_ext -o conftest2.$ac_objext >&5'
++      rm -f conftest2.*
++      if { { case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_try") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; } &&
++	 test -f conftest2.$ac_objext && { { case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$ac_try") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; };
++      then
++	# cc works too.
++	:
++      else
++	# cc exists but doesn't like -o.
++	eval ac_cv_prog_cc_${ac_cc}_c_o=no
++      fi
++    fi
++  fi
++else
++  eval ac_cv_prog_cc_${ac_cc}_c_o=no
++fi
++rm -f core conftest*
++
++fi
++if eval test \$ac_cv_prog_cc_${ac_cc}_c_o = yes; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++
++$as_echo "#define NO_MINUS_C_MINUS_O 1" >>confdefs.h
++
++fi
++
++# FIXME: we rely on the cache variable name because
++# there is no other way.
++set dummy $CC
++am_cc=`echo $2 | sed 's/[^a-zA-Z0-9_]/_/g;s/^[0-9]/_/'`
++eval am_t=\$ac_cv_prog_cc_${am_cc}_c_o
++if test "$am_t" != yes; then
++   # Losing compiler, so override with the script.
++   # FIXME: It is wrong to rewrite CC.
++   # But if we don't then we get into trouble of one sort or another.
++   # A longer-term fix would be to have automake use am__CC in this case,
++   # and then we could set am__CC="\$(top_srcdir)/compile \$(CC)"
++   CC="$am_aux_dir/compile $CC"
++fi
++
++
++ac_ext=c
++ac_cpp='$CPP $CPPFLAGS'
++ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
++ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
++ac_compiler_gnu=$ac_cv_c_compiler_gnu
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking how to run the C preprocessor" >&5
++$as_echo_n "checking how to run the C preprocessor... " >&6; }
++# On Suns, sometimes $CPP names a directory.
++if test -n "$CPP" && test -d "$CPP"; then
++  CPP=
++fi
++if test -z "$CPP"; then
++  if test "${ac_cv_prog_CPP+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++      # Double quotes because CPP needs to be expanded
++    for CPP in "$CC -E" "$CC -E -traditional-cpp" "/lib/cpp"
++    do
++      ac_preproc_ok=false
++for ac_c_preproc_warn_flag in '' yes
++do
++  # Use a header file that comes with gcc, so configuring glibc
++  # with a fresh cross-compiler works.
++  # Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
++  # <limits.h> exists even on freestanding compilers.
++  # On the NeXT, cc -E runs the code through the compiler's parser,
++  # not just through cpp. "Syntax error" is here to catch this case.
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef __STDC__
++# include <limits.h>
++#else
++# include <assert.h>
++#endif
++		     Syntax error
++_ACEOF
++if ac_fn_c_try_cpp "$LINENO"; then :
++
++else
++  # Broken: fails on valid input.
++continue
++fi
++rm -f conftest.err conftest.i conftest.$ac_ext
++
++  # OK, works on sane cases.  Now check whether nonexistent headers
++  # can be detected and how.
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <ac_nonexistent.h>
++_ACEOF
++if ac_fn_c_try_cpp "$LINENO"; then :
++  # Broken: success on invalid input.
++continue
++else
++  # Passes both tests.
++ac_preproc_ok=:
++break
++fi
++rm -f conftest.err conftest.i conftest.$ac_ext
++
++done
++# Because of `break', _AC_PREPROC_IFELSE's cleaning code was skipped.
++rm -f conftest.i conftest.err conftest.$ac_ext
++if $ac_preproc_ok; then :
++  break
++fi
++
++    done
++    ac_cv_prog_CPP=$CPP
++
++fi
++  CPP=$ac_cv_prog_CPP
++else
++  ac_cv_prog_CPP=$CPP
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $CPP" >&5
++$as_echo "$CPP" >&6; }
++ac_preproc_ok=false
++for ac_c_preproc_warn_flag in '' yes
++do
++  # Use a header file that comes with gcc, so configuring glibc
++  # with a fresh cross-compiler works.
++  # Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
++  # <limits.h> exists even on freestanding compilers.
++  # On the NeXT, cc -E runs the code through the compiler's parser,
++  # not just through cpp. "Syntax error" is here to catch this case.
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef __STDC__
++# include <limits.h>
++#else
++# include <assert.h>
++#endif
++		     Syntax error
++_ACEOF
++if ac_fn_c_try_cpp "$LINENO"; then :
++
++else
++  # Broken: fails on valid input.
++continue
++fi
++rm -f conftest.err conftest.i conftest.$ac_ext
++
++  # OK, works on sane cases.  Now check whether nonexistent headers
++  # can be detected and how.
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <ac_nonexistent.h>
++_ACEOF
++if ac_fn_c_try_cpp "$LINENO"; then :
++  # Broken: success on invalid input.
++continue
++else
++  # Passes both tests.
++ac_preproc_ok=:
++break
++fi
++rm -f conftest.err conftest.i conftest.$ac_ext
++
++done
++# Because of `break', _AC_PREPROC_IFELSE's cleaning code was skipped.
++rm -f conftest.i conftest.err conftest.$ac_ext
++if $ac_preproc_ok; then :
++
++else
++  { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
++$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
++as_fn_error $? "C preprocessor \"$CPP\" fails sanity check
++See \`config.log' for more details" "$LINENO" 5 ; }
++fi
++
++ac_ext=c
++ac_cpp='$CPP $CPPFLAGS'
++ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
++ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
++ac_compiler_gnu=$ac_cv_c_compiler_gnu
++
++case `pwd` in
++  *\ * | *\	*)
++    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: Libtool does not cope well with whitespace in \`pwd\`" >&5
++$as_echo "$as_me: WARNING: Libtool does not cope well with whitespace in \`pwd\`" >&2;} ;;
++esac
++
++
++
++macro_version='2.2.6b'
++macro_revision='1.3017'
++
++
++
++
++
++
++
++
++
++
++
++
++
++ltmain="$ac_aux_dir/ltmain.sh"
++
++# Make sure we can run config.sub.
++$SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&1 ||
++  as_fn_error $? "cannot run $SHELL $ac_aux_dir/config.sub" "$LINENO" 5
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking build system type" >&5
++$as_echo_n "checking build system type... " >&6; }
++if test "${ac_cv_build+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_build_alias=$build_alias
++test "x$ac_build_alias" = x &&
++  ac_build_alias=`$SHELL "$ac_aux_dir/config.guess"`
++test "x$ac_build_alias" = x &&
++  as_fn_error $? "cannot guess build type; you must specify one" "$LINENO" 5
++ac_cv_build=`$SHELL "$ac_aux_dir/config.sub" $ac_build_alias` ||
++  as_fn_error $? "$SHELL $ac_aux_dir/config.sub $ac_build_alias failed" "$LINENO" 5
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_build" >&5
++$as_echo "$ac_cv_build" >&6; }
++case $ac_cv_build in
++*-*-*) ;;
++*) as_fn_error $? "invalid value of canonical build" "$LINENO" 5 ;;
++esac
++build=$ac_cv_build
++ac_save_IFS=$IFS; IFS='-'
++set x $ac_cv_build
++shift
++build_cpu=$1
++build_vendor=$2
++shift; shift
++# Remember, the first character of IFS is used to create $*,
++# except with old shells:
++build_os=$*
++IFS=$ac_save_IFS
++case $build_os in *\ *) build_os=`echo "$build_os" | sed 's/ /-/g'`;; esac
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking host system type" >&5
++$as_echo_n "checking host system type... " >&6; }
++if test "${ac_cv_host+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test "x$host_alias" = x; then
++  ac_cv_host=$ac_cv_build
++else
++  ac_cv_host=`$SHELL "$ac_aux_dir/config.sub" $host_alias` ||
++    as_fn_error $? "$SHELL $ac_aux_dir/config.sub $host_alias failed" "$LINENO" 5
++fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_host" >&5
++$as_echo "$ac_cv_host" >&6; }
++case $ac_cv_host in
++*-*-*) ;;
++*) as_fn_error $? "invalid value of canonical host" "$LINENO" 5 ;;
++esac
++host=$ac_cv_host
++ac_save_IFS=$IFS; IFS='-'
++set x $ac_cv_host
++shift
++host_cpu=$1
++host_vendor=$2
++shift; shift
++# Remember, the first character of IFS is used to create $*,
++# except with old shells:
++host_os=$*
++IFS=$ac_save_IFS
++case $host_os in *\ *) host_os=`echo "$host_os" | sed 's/ /-/g'`;; esac
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for a sed that does not truncate output" >&5
++$as_echo_n "checking for a sed that does not truncate output... " >&6; }
++if test "${ac_cv_path_SED+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++            ac_script=s/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb/
++     for ac_i in 1 2 3 4 5 6 7; do
++       ac_script="$ac_script$as_nl$ac_script"
++     done
++     echo "$ac_script" 2>/dev/null | sed 99q >conftest.sed
++     { ac_script=; unset ac_script;}
++     if test -z "$SED"; then
++  ac_path_SED_found=false
++  # Loop through the user's path and test for each of PROGNAME-LIST
++  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_prog in sed gsed; do
++    for ac_exec_ext in '' $ac_executable_extensions; do
++      ac_path_SED="$as_dir/$ac_prog$ac_exec_ext"
++      { test -f "$ac_path_SED" && $as_test_x "$ac_path_SED"; } || continue
++# Check for GNU ac_path_SED and select it if it is found.
++  # Check for GNU $ac_path_SED
++case `"$ac_path_SED" --version 2>&1` in
++*GNU*)
++  ac_cv_path_SED="$ac_path_SED" ac_path_SED_found=:;;
++*)
++  ac_count=0
++  $as_echo_n 0123456789 >"conftest.in"
++  while :
++  do
++    cat "conftest.in" "conftest.in" >"conftest.tmp"
++    mv "conftest.tmp" "conftest.in"
++    cp "conftest.in" "conftest.nl"
++    $as_echo '' >> "conftest.nl"
++    "$ac_path_SED" -f conftest.sed < "conftest.nl" >"conftest.out" 2>/dev/null || break
++    diff "conftest.out" "conftest.nl" >/dev/null 2>&1 || break
++    as_fn_arith $ac_count + 1 && ac_count=$as_val
++    if test $ac_count -gt ${ac_path_SED_max-0}; then
++      # Best one so far, save it but keep looking for a better one
++      ac_cv_path_SED="$ac_path_SED"
++      ac_path_SED_max=$ac_count
++    fi
++    # 10*(2^10) chars as input seems more than enough
++    test $ac_count -gt 10 && break
++  done
++  rm -f conftest.in conftest.tmp conftest.nl conftest.out;;
++esac
++
++      $ac_path_SED_found && break 3
++    done
++  done
++  done
++IFS=$as_save_IFS
++  if test -z "$ac_cv_path_SED"; then
++    as_fn_error $? "no acceptable sed could be found in \$PATH" "$LINENO" 5
++  fi
++else
++  ac_cv_path_SED=$SED
++fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_path_SED" >&5
++$as_echo "$ac_cv_path_SED" >&6; }
++ SED="$ac_cv_path_SED"
++  rm -f conftest.sed
++
++test -z "$SED" && SED=sed
++Xsed="$SED -e 1s/^X//"
++
++
++
++
++
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for grep that handles long lines and -e" >&5
++$as_echo_n "checking for grep that handles long lines and -e... " >&6; }
++if test "${ac_cv_path_GREP+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -z "$GREP"; then
++  ac_path_GREP_found=false
++  # Loop through the user's path and test for each of PROGNAME-LIST
++  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH$PATH_SEPARATOR/usr/xpg4/bin
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_prog in grep ggrep; do
++    for ac_exec_ext in '' $ac_executable_extensions; do
++      ac_path_GREP="$as_dir/$ac_prog$ac_exec_ext"
++      { test -f "$ac_path_GREP" && $as_test_x "$ac_path_GREP"; } || continue
++# Check for GNU ac_path_GREP and select it if it is found.
++  # Check for GNU $ac_path_GREP
++case `"$ac_path_GREP" --version 2>&1` in
++*GNU*)
++  ac_cv_path_GREP="$ac_path_GREP" ac_path_GREP_found=:;;
++*)
++  ac_count=0
++  $as_echo_n 0123456789 >"conftest.in"
++  while :
++  do
++    cat "conftest.in" "conftest.in" >"conftest.tmp"
++    mv "conftest.tmp" "conftest.in"
++    cp "conftest.in" "conftest.nl"
++    $as_echo 'GREP' >> "conftest.nl"
++    "$ac_path_GREP" -e 'GREP$' -e '-(cannot match)-' < "conftest.nl" >"conftest.out" 2>/dev/null || break
++    diff "conftest.out" "conftest.nl" >/dev/null 2>&1 || break
++    as_fn_arith $ac_count + 1 && ac_count=$as_val
++    if test $ac_count -gt ${ac_path_GREP_max-0}; then
++      # Best one so far, save it but keep looking for a better one
++      ac_cv_path_GREP="$ac_path_GREP"
++      ac_path_GREP_max=$ac_count
++    fi
++    # 10*(2^10) chars as input seems more than enough
++    test $ac_count -gt 10 && break
++  done
++  rm -f conftest.in conftest.tmp conftest.nl conftest.out;;
++esac
++
++      $ac_path_GREP_found && break 3
++    done
++  done
++  done
++IFS=$as_save_IFS
++  if test -z "$ac_cv_path_GREP"; then
++    as_fn_error $? "no acceptable grep could be found in $PATH$PATH_SEPARATOR/usr/xpg4/bin" "$LINENO" 5
++  fi
++else
++  ac_cv_path_GREP=$GREP
++fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_path_GREP" >&5
++$as_echo "$ac_cv_path_GREP" >&6; }
++ GREP="$ac_cv_path_GREP"
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for egrep" >&5
++$as_echo_n "checking for egrep... " >&6; }
++if test "${ac_cv_path_EGREP+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if echo a | $GREP -E '(a|b)' >/dev/null 2>&1
++   then ac_cv_path_EGREP="$GREP -E"
++   else
++     if test -z "$EGREP"; then
++  ac_path_EGREP_found=false
++  # Loop through the user's path and test for each of PROGNAME-LIST
++  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH$PATH_SEPARATOR/usr/xpg4/bin
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_prog in egrep; do
++    for ac_exec_ext in '' $ac_executable_extensions; do
++      ac_path_EGREP="$as_dir/$ac_prog$ac_exec_ext"
++      { test -f "$ac_path_EGREP" && $as_test_x "$ac_path_EGREP"; } || continue
++# Check for GNU ac_path_EGREP and select it if it is found.
++  # Check for GNU $ac_path_EGREP
++case `"$ac_path_EGREP" --version 2>&1` in
++*GNU*)
++  ac_cv_path_EGREP="$ac_path_EGREP" ac_path_EGREP_found=:;;
++*)
++  ac_count=0
++  $as_echo_n 0123456789 >"conftest.in"
++  while :
++  do
++    cat "conftest.in" "conftest.in" >"conftest.tmp"
++    mv "conftest.tmp" "conftest.in"
++    cp "conftest.in" "conftest.nl"
++    $as_echo 'EGREP' >> "conftest.nl"
++    "$ac_path_EGREP" 'EGREP$' < "conftest.nl" >"conftest.out" 2>/dev/null || break
++    diff "conftest.out" "conftest.nl" >/dev/null 2>&1 || break
++    as_fn_arith $ac_count + 1 && ac_count=$as_val
++    if test $ac_count -gt ${ac_path_EGREP_max-0}; then
++      # Best one so far, save it but keep looking for a better one
++      ac_cv_path_EGREP="$ac_path_EGREP"
++      ac_path_EGREP_max=$ac_count
++    fi
++    # 10*(2^10) chars as input seems more than enough
++    test $ac_count -gt 10 && break
++  done
++  rm -f conftest.in conftest.tmp conftest.nl conftest.out;;
++esac
++
++      $ac_path_EGREP_found && break 3
++    done
++  done
++  done
++IFS=$as_save_IFS
++  if test -z "$ac_cv_path_EGREP"; then
++    as_fn_error $? "no acceptable egrep could be found in $PATH$PATH_SEPARATOR/usr/xpg4/bin" "$LINENO" 5
++  fi
++else
++  ac_cv_path_EGREP=$EGREP
++fi
++
++   fi
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_path_EGREP" >&5
++$as_echo "$ac_cv_path_EGREP" >&6; }
++ EGREP="$ac_cv_path_EGREP"
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for fgrep" >&5
++$as_echo_n "checking for fgrep... " >&6; }
++if test "${ac_cv_path_FGREP+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if echo 'ab*c' | $GREP -F 'ab*c' >/dev/null 2>&1
++   then ac_cv_path_FGREP="$GREP -F"
++   else
++     if test -z "$FGREP"; then
++  ac_path_FGREP_found=false
++  # Loop through the user's path and test for each of PROGNAME-LIST
++  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH$PATH_SEPARATOR/usr/xpg4/bin
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_prog in fgrep; do
++    for ac_exec_ext in '' $ac_executable_extensions; do
++      ac_path_FGREP="$as_dir/$ac_prog$ac_exec_ext"
++      { test -f "$ac_path_FGREP" && $as_test_x "$ac_path_FGREP"; } || continue
++# Check for GNU ac_path_FGREP and select it if it is found.
++  # Check for GNU $ac_path_FGREP
++case `"$ac_path_FGREP" --version 2>&1` in
++*GNU*)
++  ac_cv_path_FGREP="$ac_path_FGREP" ac_path_FGREP_found=:;;
++*)
++  ac_count=0
++  $as_echo_n 0123456789 >"conftest.in"
++  while :
++  do
++    cat "conftest.in" "conftest.in" >"conftest.tmp"
++    mv "conftest.tmp" "conftest.in"
++    cp "conftest.in" "conftest.nl"
++    $as_echo 'FGREP' >> "conftest.nl"
++    "$ac_path_FGREP" FGREP < "conftest.nl" >"conftest.out" 2>/dev/null || break
++    diff "conftest.out" "conftest.nl" >/dev/null 2>&1 || break
++    as_fn_arith $ac_count + 1 && ac_count=$as_val
++    if test $ac_count -gt ${ac_path_FGREP_max-0}; then
++      # Best one so far, save it but keep looking for a better one
++      ac_cv_path_FGREP="$ac_path_FGREP"
++      ac_path_FGREP_max=$ac_count
++    fi
++    # 10*(2^10) chars as input seems more than enough
++    test $ac_count -gt 10 && break
++  done
++  rm -f conftest.in conftest.tmp conftest.nl conftest.out;;
++esac
++
++      $ac_path_FGREP_found && break 3
++    done
++  done
++  done
++IFS=$as_save_IFS
++  if test -z "$ac_cv_path_FGREP"; then
++    as_fn_error $? "no acceptable fgrep could be found in $PATH$PATH_SEPARATOR/usr/xpg4/bin" "$LINENO" 5
++  fi
++else
++  ac_cv_path_FGREP=$FGREP
++fi
++
++   fi
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_path_FGREP" >&5
++$as_echo "$ac_cv_path_FGREP" >&6; }
++ FGREP="$ac_cv_path_FGREP"
++
++
++test -z "$GREP" && GREP=grep
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++# Check whether --with-gnu-ld was given.
++if test "${with_gnu_ld+set}" = set; then :
++  withval=$with_gnu_ld; test "$withval" = no || with_gnu_ld=yes
++else
++  with_gnu_ld=no
++fi
++
++ac_prog=ld
++if test "$GCC" = yes; then
++  # Check if gcc -print-prog-name=ld gives a path.
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ld used by $CC" >&5
++$as_echo_n "checking for ld used by $CC... " >&6; }
++  case $host in
++  *-*-mingw*)
++    # gcc leaves a trailing carriage return which upsets mingw
++    ac_prog=`($CC -print-prog-name=ld) 2>&5 | tr -d '\015'` ;;
++  *)
++    ac_prog=`($CC -print-prog-name=ld) 2>&5` ;;
++  esac
++  case $ac_prog in
++    # Accept absolute paths.
++    [\\/]* | ?:[\\/]*)
++      re_direlt='/[^/][^/]*/\.\./'
++      # Canonicalize the pathname of ld
++      ac_prog=`$ECHO "$ac_prog"| $SED 's%\\\\%/%g'`
++      while $ECHO "$ac_prog" | $GREP "$re_direlt" > /dev/null 2>&1; do
++	ac_prog=`$ECHO $ac_prog| $SED "s%$re_direlt%/%"`
++      done
++      test -z "$LD" && LD="$ac_prog"
++      ;;
++  "")
++    # If it fails, then pretend we aren't using GCC.
++    ac_prog=ld
++    ;;
++  *)
++    # If it is relative, then search for the first ld in PATH.
++    with_gnu_ld=unknown
++    ;;
++  esac
++elif test "$with_gnu_ld" = yes; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU ld" >&5
++$as_echo_n "checking for GNU ld... " >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for non-GNU ld" >&5
++$as_echo_n "checking for non-GNU ld... " >&6; }
++fi
++if test "${lt_cv_path_LD+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -z "$LD"; then
++  lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
++  for ac_dir in $PATH; do
++    IFS="$lt_save_ifs"
++    test -z "$ac_dir" && ac_dir=.
++    if test -f "$ac_dir/$ac_prog" || test -f "$ac_dir/$ac_prog$ac_exeext"; then
++      lt_cv_path_LD="$ac_dir/$ac_prog"
++      # Check to see if the program is GNU ld.  I'd rather use --version,
++      # but apparently some variants of GNU ld only accept -v.
++      # Break only if it was the GNU/non-GNU ld that we prefer.
++      case `"$lt_cv_path_LD" -v 2>&1 </dev/null` in
++      *GNU* | *'with BFD'*)
++	test "$with_gnu_ld" != no && break
++	;;
++      *)
++	test "$with_gnu_ld" != yes && break
++	;;
++      esac
++    fi
++  done
++  IFS="$lt_save_ifs"
++else
++  lt_cv_path_LD="$LD" # Let the user override the test with a path.
++fi
++fi
++
++LD="$lt_cv_path_LD"
++if test -n "$LD"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $LD" >&5
++$as_echo "$LD" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++test -z "$LD" && as_fn_error $? "no acceptable ld found in \$PATH" "$LINENO" 5
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if the linker ($LD) is GNU ld" >&5
++$as_echo_n "checking if the linker ($LD) is GNU ld... " >&6; }
++if test "${lt_cv_prog_gnu_ld+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  # I'd rather use --version here, but apparently some GNU lds only accept -v.
++case `$LD -v 2>&1 </dev/null` in
++*GNU* | *'with BFD'*)
++  lt_cv_prog_gnu_ld=yes
++  ;;
++*)
++  lt_cv_prog_gnu_ld=no
++  ;;
++esac
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_prog_gnu_ld" >&5
++$as_echo "$lt_cv_prog_gnu_ld" >&6; }
++with_gnu_ld=$lt_cv_prog_gnu_ld
++
++
++
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for BSD- or MS-compatible name lister (nm)" >&5
++$as_echo_n "checking for BSD- or MS-compatible name lister (nm)... " >&6; }
++if test "${lt_cv_path_NM+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$NM"; then
++  # Let the user override the test.
++  lt_cv_path_NM="$NM"
++else
++  lt_nm_to_check="${ac_tool_prefix}nm"
++  if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
++    lt_nm_to_check="$lt_nm_to_check nm"
++  fi
++  for lt_tmp_nm in $lt_nm_to_check; do
++    lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
++    for ac_dir in $PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin; do
++      IFS="$lt_save_ifs"
++      test -z "$ac_dir" && ac_dir=.
++      tmp_nm="$ac_dir/$lt_tmp_nm"
++      if test -f "$tmp_nm" || test -f "$tmp_nm$ac_exeext" ; then
++	# Check to see if the nm accepts a BSD-compat flag.
++	# Adding the `sed 1q' prevents false positives on HP-UX, which says:
++	#   nm: unknown option "B" ignored
++	# Tru64's nm complains that /dev/null is an invalid object file
++	case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
++	*/dev/null* | *'Invalid file or object type'*)
++	  lt_cv_path_NM="$tmp_nm -B"
++	  break
++	  ;;
++	*)
++	  case `"$tmp_nm" -p /dev/null 2>&1 | sed '1q'` in
++	  */dev/null*)
++	    lt_cv_path_NM="$tmp_nm -p"
++	    break
++	    ;;
++	  *)
++	    lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
++	    continue # so that we can try to find one that supports BSD flags
++	    ;;
++	  esac
++	  ;;
++	esac
++      fi
++    done
++    IFS="$lt_save_ifs"
++  done
++  : ${lt_cv_path_NM=no}
++fi
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_path_NM" >&5
++$as_echo "$lt_cv_path_NM" >&6; }
++if test "$lt_cv_path_NM" != "no"; then
++  NM="$lt_cv_path_NM"
++else
++  # Didn't find any BSD compatible name lister, look for dumpbin.
++  if test -n "$ac_tool_prefix"; then
++  for ac_prog in "dumpbin -symbols" "link -dump -symbols"
++  do
++    # Extract the first word of "$ac_tool_prefix$ac_prog", so it can be a program name with args.
++set dummy $ac_tool_prefix$ac_prog; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_DUMPBIN+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$DUMPBIN"; then
++  ac_cv_prog_DUMPBIN="$DUMPBIN" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_DUMPBIN="$ac_tool_prefix$ac_prog"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++DUMPBIN=$ac_cv_prog_DUMPBIN
++if test -n "$DUMPBIN"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $DUMPBIN" >&5
++$as_echo "$DUMPBIN" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++    test -n "$DUMPBIN" && break
++  done
++fi
++if test -z "$DUMPBIN"; then
++  ac_ct_DUMPBIN=$DUMPBIN
++  for ac_prog in "dumpbin -symbols" "link -dump -symbols"
++do
++  # Extract the first word of "$ac_prog", so it can be a program name with args.
++set dummy $ac_prog; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_ac_ct_DUMPBIN+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$ac_ct_DUMPBIN"; then
++  ac_cv_prog_ac_ct_DUMPBIN="$ac_ct_DUMPBIN" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_ac_ct_DUMPBIN="$ac_prog"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++ac_ct_DUMPBIN=$ac_cv_prog_ac_ct_DUMPBIN
++if test -n "$ac_ct_DUMPBIN"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_DUMPBIN" >&5
++$as_echo "$ac_ct_DUMPBIN" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++  test -n "$ac_ct_DUMPBIN" && break
++done
++
++  if test "x$ac_ct_DUMPBIN" = x; then
++    DUMPBIN=":"
++  else
++    case $cross_compiling:$ac_tool_warned in
++yes:)
++{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
++$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
++ac_tool_warned=yes ;;
++esac
++    DUMPBIN=$ac_ct_DUMPBIN
++  fi
++fi
++
++
++  if test "$DUMPBIN" != ":"; then
++    NM="$DUMPBIN"
++  fi
++fi
++test -z "$NM" && NM=nm
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking the name lister ($NM) interface" >&5
++$as_echo_n "checking the name lister ($NM) interface... " >&6; }
++if test "${lt_cv_nm_interface+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  lt_cv_nm_interface="BSD nm"
++  echo "int some_variable = 0;" > conftest.$ac_ext
++  (eval echo "\"\$as_me:5204: $ac_compile\"" >&5)
++  (eval "$ac_compile" 2>conftest.err)
++  cat conftest.err >&5
++  (eval echo "\"\$as_me:5207: $NM \\\"conftest.$ac_objext\\\"\"" >&5)
++  (eval "$NM \"conftest.$ac_objext\"" 2>conftest.err > conftest.out)
++  cat conftest.err >&5
++  (eval echo "\"\$as_me:5210: output\"" >&5)
++  cat conftest.out >&5
++  if $GREP 'External.*some_variable' conftest.out > /dev/null; then
++    lt_cv_nm_interface="MS dumpbin"
++  fi
++  rm -f conftest*
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_nm_interface" >&5
++$as_echo "$lt_cv_nm_interface" >&6; }
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ln -s works" >&5
++$as_echo_n "checking whether ln -s works... " >&6; }
++LN_S=$as_ln_s
++if test "$LN_S" = "ln -s"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no, using $LN_S" >&5
++$as_echo "no, using $LN_S" >&6; }
++fi
++
++# find the maximum length of command line arguments
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking the maximum length of command line arguments" >&5
++$as_echo_n "checking the maximum length of command line arguments... " >&6; }
++if test "${lt_cv_sys_max_cmd_len+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++    i=0
++  teststring="ABCD"
++
++  case $build_os in
++  msdosdjgpp*)
++    # On DJGPP, this test can blow up pretty badly due to problems in libc
++    # (any single argument exceeding 2000 bytes causes a buffer overrun
++    # during glob expansion).  Even if it were fixed, the result of this
++    # check would be larger than it should be.
++    lt_cv_sys_max_cmd_len=12288;    # 12K is about right
++    ;;
++
++  gnu*)
++    # Under GNU Hurd, this test is not required because there is
++    # no limit to the length of command line arguments.
++    # Libtool will interpret -1 as no limit whatsoever
++    lt_cv_sys_max_cmd_len=-1;
++    ;;
++
++  cygwin* | mingw* | cegcc*)
++    # On Win9x/ME, this test blows up -- it succeeds, but takes
++    # about 5 minutes as the teststring grows exponentially.
++    # Worse, since 9x/ME are not pre-emptively multitasking,
++    # you end up with a "frozen" computer, even though with patience
++    # the test eventually succeeds (with a max line length of 256k).
++    # Instead, let's just punt: use the minimum linelength reported by
++    # all of the supported platforms: 8192 (on NT/2K/XP).
++    lt_cv_sys_max_cmd_len=8192;
++    ;;
++
++  amigaos*)
++    # On AmigaOS with pdksh, this test takes hours, literally.
++    # So we just punt and use a minimum line length of 8192.
++    lt_cv_sys_max_cmd_len=8192;
++    ;;
++
++  netbsd* | freebsd* | openbsd* | darwin* | dragonfly*)
++    # This has been around since 386BSD, at least.  Likely further.
++    if test -x /sbin/sysctl; then
++      lt_cv_sys_max_cmd_len=`/sbin/sysctl -n kern.argmax`
++    elif test -x /usr/sbin/sysctl; then
++      lt_cv_sys_max_cmd_len=`/usr/sbin/sysctl -n kern.argmax`
++    else
++      lt_cv_sys_max_cmd_len=65536	# usable default for all BSDs
++    fi
++    # And add a safety zone
++    lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
++    lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
++    ;;
++
++  interix*)
++    # We know the value 262144 and hardcode it with a safety zone (like BSD)
++    lt_cv_sys_max_cmd_len=196608
++    ;;
++
++  osf*)
++    # Dr. Hans Ekkehard Plesser reports seeing a kernel panic running configure
++    # due to this test when exec_disable_arg_limit is 1 on Tru64. It is not
++    # nice to cause kernel panics so lets avoid the loop below.
++    # First set a reasonable default.
++    lt_cv_sys_max_cmd_len=16384
++    #
++    if test -x /sbin/sysconfig; then
++      case `/sbin/sysconfig -q proc exec_disable_arg_limit` in
++        *1*) lt_cv_sys_max_cmd_len=-1 ;;
++      esac
++    fi
++    ;;
++  sco3.2v5*)
++    lt_cv_sys_max_cmd_len=102400
++    ;;
++  sysv5* | sco5v6* | sysv4.2uw2*)
++    kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2>/dev/null`
++    if test -n "$kargmax"; then
++      lt_cv_sys_max_cmd_len=`echo $kargmax | sed 's/.*[	 ]//'`
++    else
++      lt_cv_sys_max_cmd_len=32768
++    fi
++    ;;
++  *)
++    lt_cv_sys_max_cmd_len=`(getconf ARG_MAX) 2> /dev/null`
++    if test -n "$lt_cv_sys_max_cmd_len"; then
++      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
++      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
++    else
++      # Make teststring a little bigger before we do anything with it.
++      # a 1K string should be a reasonable start.
++      for i in 1 2 3 4 5 6 7 8 ; do
++        teststring=$teststring$teststring
++      done
++      SHELL=${SHELL-${CONFIG_SHELL-/bin/sh}}
++      # If test is not a shell built-in, we'll probably end up computing a
++      # maximum length that is only half of the actual maximum length, but
++      # we can't tell.
++      while { test "X"`$SHELL $0 --fallback-echo "X$teststring$teststring" 2>/dev/null` \
++	         = "XX$teststring$teststring"; } >/dev/null 2>&1 &&
++	      test $i != 17 # 1/2 MB should be enough
++      do
++        i=`expr $i + 1`
++        teststring=$teststring$teststring
++      done
++      # Only check the string length outside the loop.
++      lt_cv_sys_max_cmd_len=`expr "X$teststring" : ".*" 2>&1`
++      teststring=
++      # Add a significant safety factor because C++ compilers can tack on
++      # massive amounts of additional arguments before passing them to the
++      # linker.  It appears as though 1/2 is a usable value.
++      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 2`
++    fi
++    ;;
++  esac
++
++fi
++
++if test -n $lt_cv_sys_max_cmd_len ; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_sys_max_cmd_len" >&5
++$as_echo "$lt_cv_sys_max_cmd_len" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: none" >&5
++$as_echo "none" >&6; }
++fi
++max_cmd_len=$lt_cv_sys_max_cmd_len
++
++
++
++
++
++
++: ${CP="cp -f"}
++: ${MV="mv -f"}
++: ${RM="rm -f"}
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the shell understands some XSI constructs" >&5
++$as_echo_n "checking whether the shell understands some XSI constructs... " >&6; }
++# Try some XSI features
++xsi_shell=no
++( _lt_dummy="a/b/c"
++  test "${_lt_dummy##*/},${_lt_dummy%/*},"${_lt_dummy%"$_lt_dummy"}, \
++      = c,a/b,, \
++    && eval 'test $(( 1 + 1 )) -eq 2 \
++    && test "${#_lt_dummy}" -eq 5' ) >/dev/null 2>&1 \
++  && xsi_shell=yes
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $xsi_shell" >&5
++$as_echo "$xsi_shell" >&6; }
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the shell understands \"+=\"" >&5
++$as_echo_n "checking whether the shell understands \"+=\"... " >&6; }
++lt_shell_append=no
++( foo=bar; set foo baz; eval "$1+=\$2" && test "$foo" = barbaz ) \
++    >/dev/null 2>&1 \
++  && lt_shell_append=yes
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_shell_append" >&5
++$as_echo "$lt_shell_append" >&6; }
++
++
++if ( (MAIL=60; unset MAIL) || exit) >/dev/null 2>&1; then
++  lt_unset=unset
++else
++  lt_unset=false
++fi
++
++
++
++
++
++# test EBCDIC or ASCII
++case `echo X|tr X '\101'` in
++ A) # ASCII based system
++    # \n is not interpreted correctly by Solaris 8 /usr/ucb/tr
++  lt_SP2NL='tr \040 \012'
++  lt_NL2SP='tr \015\012 \040\040'
++  ;;
++ *) # EBCDIC based system
++  lt_SP2NL='tr \100 \n'
++  lt_NL2SP='tr \r\n \100\100'
++  ;;
++esac
++
++
++
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $LD option to reload object files" >&5
++$as_echo_n "checking for $LD option to reload object files... " >&6; }
++if test "${lt_cv_ld_reload_flag+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  lt_cv_ld_reload_flag='-r'
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_ld_reload_flag" >&5
++$as_echo "$lt_cv_ld_reload_flag" >&6; }
++reload_flag=$lt_cv_ld_reload_flag
++case $reload_flag in
++"" | " "*) ;;
++*) reload_flag=" $reload_flag" ;;
++esac
++reload_cmds='$LD$reload_flag -o $output$reload_objs'
++case $host_os in
++  darwin*)
++    if test "$GCC" = yes; then
++      reload_cmds='$LTCC $LTCFLAGS -nostdlib ${wl}-r -o $output$reload_objs'
++    else
++      reload_cmds='$LD$reload_flag -o $output$reload_objs'
++    fi
++    ;;
++esac
++
++
++
++
++
++
++
++
++
++if test -n "$ac_tool_prefix"; then
++  # Extract the first word of "${ac_tool_prefix}objdump", so it can be a program name with args.
++set dummy ${ac_tool_prefix}objdump; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_OBJDUMP+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$OBJDUMP"; then
++  ac_cv_prog_OBJDUMP="$OBJDUMP" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_OBJDUMP="${ac_tool_prefix}objdump"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++OBJDUMP=$ac_cv_prog_OBJDUMP
++if test -n "$OBJDUMP"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $OBJDUMP" >&5
++$as_echo "$OBJDUMP" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++fi
++if test -z "$ac_cv_prog_OBJDUMP"; then
++  ac_ct_OBJDUMP=$OBJDUMP
++  # Extract the first word of "objdump", so it can be a program name with args.
++set dummy objdump; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_ac_ct_OBJDUMP+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$ac_ct_OBJDUMP"; then
++  ac_cv_prog_ac_ct_OBJDUMP="$ac_ct_OBJDUMP" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_ac_ct_OBJDUMP="objdump"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++ac_ct_OBJDUMP=$ac_cv_prog_ac_ct_OBJDUMP
++if test -n "$ac_ct_OBJDUMP"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_OBJDUMP" >&5
++$as_echo "$ac_ct_OBJDUMP" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++  if test "x$ac_ct_OBJDUMP" = x; then
++    OBJDUMP="false"
++  else
++    case $cross_compiling:$ac_tool_warned in
++yes:)
++{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
++$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
++ac_tool_warned=yes ;;
++esac
++    OBJDUMP=$ac_ct_OBJDUMP
++  fi
++else
++  OBJDUMP="$ac_cv_prog_OBJDUMP"
++fi
++
++test -z "$OBJDUMP" && OBJDUMP=objdump
++
++
++
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking how to recognize dependent libraries" >&5
++$as_echo_n "checking how to recognize dependent libraries... " >&6; }
++if test "${lt_cv_deplibs_check_method+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  lt_cv_file_magic_cmd='$MAGIC_CMD'
++lt_cv_file_magic_test_file=
++lt_cv_deplibs_check_method='unknown'
++# Need to set the preceding variable on all platforms that support
++# interlibrary dependencies.
++# 'none' -- dependencies not supported.
++# `unknown' -- same as none, but documents that we really don't know.
++# 'pass_all' -- all dependencies passed with no checks.
++# 'test_compile' -- check by making test program.
++# 'file_magic [[regex]]' -- check by looking for files in library path
++# which responds to the $file_magic_cmd with a given extended regex.
++# If you have `file' or equivalent on your system and you're not sure
++# whether `pass_all' will *always* work, you probably want this one.
++
++case $host_os in
++aix[4-9]*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++beos*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++bsdi[45]*)
++  lt_cv_deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [ML]SB (shared object|dynamic lib)'
++  lt_cv_file_magic_cmd='/usr/bin/file -L'
++  lt_cv_file_magic_test_file=/shlib/libc.so
++  ;;
++
++cygwin*)
++  # func_win32_libid is a shell function defined in ltmain.sh
++  lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
++  lt_cv_file_magic_cmd='func_win32_libid'
++  ;;
++
++mingw* | pw32*)
++  # Base MSYS/MinGW do not provide the 'file' command needed by
++  # func_win32_libid shell function, so use a weaker test based on 'objdump',
++  # unless we find 'file', for example because we are cross-compiling.
++  if ( file / ) >/dev/null 2>&1; then
++    lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
++    lt_cv_file_magic_cmd='func_win32_libid'
++  else
++    lt_cv_deplibs_check_method='file_magic file format pei*-i386(.*architecture: i386)?'
++    lt_cv_file_magic_cmd='$OBJDUMP -f'
++  fi
++  ;;
++
++cegcc)
++  # use the weaker test based on 'objdump'. See mingw*.
++  lt_cv_deplibs_check_method='file_magic file format pe-arm-.*little(.*architecture: arm)?'
++  lt_cv_file_magic_cmd='$OBJDUMP -f'
++  ;;
++
++darwin* | rhapsody*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++freebsd* | dragonfly*)
++  if echo __ELF__ | $CC -E - | $GREP __ELF__ > /dev/null; then
++    case $host_cpu in
++    i*86 )
++      # Not sure whether the presence of OpenBSD here was a mistake.
++      # Let's accept both of them until this is cleared up.
++      lt_cv_deplibs_check_method='file_magic (FreeBSD|OpenBSD|DragonFly)/i[3-9]86 (compact )?demand paged shared library'
++      lt_cv_file_magic_cmd=/usr/bin/file
++      lt_cv_file_magic_test_file=`echo /usr/lib/libc.so.*`
++      ;;
++    esac
++  else
++    lt_cv_deplibs_check_method=pass_all
++  fi
++  ;;
++
++gnu*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++hpux10.20* | hpux11*)
++  lt_cv_file_magic_cmd=/usr/bin/file
++  case $host_cpu in
++  ia64*)
++    lt_cv_deplibs_check_method='file_magic (s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared object file - IA64'
++    lt_cv_file_magic_test_file=/usr/lib/hpux32/libc.so
++    ;;
++  hppa*64*)
++    lt_cv_deplibs_check_method='file_magic (s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared object file - PA-RISC [0-9].[0-9]'
++    lt_cv_file_magic_test_file=/usr/lib/pa20_64/libc.sl
++    ;;
++  *)
++    lt_cv_deplibs_check_method='file_magic (s[0-9][0-9][0-9]|PA-RISC[0-9].[0-9]) shared library'
++    lt_cv_file_magic_test_file=/usr/lib/libc.sl
++    ;;
++  esac
++  ;;
++
++interix[3-9]*)
++  # PIC code is broken on Interix 3.x, that's why |\.a not |_pic\.a here
++  lt_cv_deplibs_check_method='match_pattern /lib[^/]+(\.so|\.a)$'
++  ;;
++
++irix5* | irix6* | nonstopux*)
++  case $LD in
++  *-32|*"-32 ") libmagic=32-bit;;
++  *-n32|*"-n32 ") libmagic=N32;;
++  *-64|*"-64 ") libmagic=64-bit;;
++  *) libmagic=never-match;;
++  esac
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++# This must be Linux ELF.
++linux* | k*bsd*-gnu | kopensolaris*-gnu)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++netbsd* | netbsdelf*-gnu)
++  if echo __ELF__ | $CC -E - | $GREP __ELF__ > /dev/null; then
++    lt_cv_deplibs_check_method='match_pattern /lib[^/]+(\.so\.[0-9]+\.[0-9]+|_pic\.a)$'
++  else
++    lt_cv_deplibs_check_method='match_pattern /lib[^/]+(\.so|_pic\.a)$'
++  fi
++  ;;
++
++newos6*)
++  lt_cv_deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [ML]SB (executable|dynamic lib)'
++  lt_cv_file_magic_cmd=/usr/bin/file
++  lt_cv_file_magic_test_file=/usr/lib/libnls.so
++  ;;
++
++*nto* | *qnx*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++openbsd*)
++  if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
++    lt_cv_deplibs_check_method='match_pattern /lib[^/]+(\.so\.[0-9]+\.[0-9]+|\.so|_pic\.a)$'
++  else
++    lt_cv_deplibs_check_method='match_pattern /lib[^/]+(\.so\.[0-9]+\.[0-9]+|_pic\.a)$'
++  fi
++  ;;
++
++osf3* | osf4* | osf5*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++rdos*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++solaris*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++
++sysv4 | sysv4.3*)
++  case $host_vendor in
++  motorola)
++    lt_cv_deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [ML]SB (shared object|dynamic lib) M[0-9][0-9]* Version [0-9]'
++    lt_cv_file_magic_test_file=`echo /usr/lib/libc.so*`
++    ;;
++  ncr)
++    lt_cv_deplibs_check_method=pass_all
++    ;;
++  sequent)
++    lt_cv_file_magic_cmd='/bin/file'
++    lt_cv_deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib )'
++    ;;
++  sni)
++    lt_cv_file_magic_cmd='/bin/file'
++    lt_cv_deplibs_check_method="file_magic ELF [0-9][0-9]*-bit [LM]SB dynamic lib"
++    lt_cv_file_magic_test_file=/lib/libc.so
++    ;;
++  siemens)
++    lt_cv_deplibs_check_method=pass_all
++    ;;
++  pc)
++    lt_cv_deplibs_check_method=pass_all
++    ;;
++  esac
++  ;;
++
++tpf*)
++  lt_cv_deplibs_check_method=pass_all
++  ;;
++esac
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_deplibs_check_method" >&5
++$as_echo "$lt_cv_deplibs_check_method" >&6; }
++file_magic_cmd=$lt_cv_file_magic_cmd
++deplibs_check_method=$lt_cv_deplibs_check_method
++test -z "$deplibs_check_method" && deplibs_check_method=unknown
++
++
++
++
++
++
++
++
++
++
++
++
++if test -n "$ac_tool_prefix"; then
++  # Extract the first word of "${ac_tool_prefix}ar", so it can be a program name with args.
++set dummy ${ac_tool_prefix}ar; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_AR+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$AR"; then
++  ac_cv_prog_AR="$AR" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_AR="${ac_tool_prefix}ar"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++AR=$ac_cv_prog_AR
++if test -n "$AR"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $AR" >&5
++$as_echo "$AR" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++fi
++if test -z "$ac_cv_prog_AR"; then
++  ac_ct_AR=$AR
++  # Extract the first word of "ar", so it can be a program name with args.
++set dummy ar; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_ac_ct_AR+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$ac_ct_AR"; then
++  ac_cv_prog_ac_ct_AR="$ac_ct_AR" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_ac_ct_AR="ar"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++ac_ct_AR=$ac_cv_prog_ac_ct_AR
++if test -n "$ac_ct_AR"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_AR" >&5
++$as_echo "$ac_ct_AR" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++  if test "x$ac_ct_AR" = x; then
++    AR="false"
++  else
++    case $cross_compiling:$ac_tool_warned in
++yes:)
++{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
++$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
++ac_tool_warned=yes ;;
++esac
++    AR=$ac_ct_AR
++  fi
++else
++  AR="$ac_cv_prog_AR"
++fi
++
++test -z "$AR" && AR=ar
++test -z "$AR_FLAGS" && AR_FLAGS=cru
++
++
++
++
++
++
++
++
++
++
++
++if test -n "$ac_tool_prefix"; then
++  # Extract the first word of "${ac_tool_prefix}strip", so it can be a program name with args.
++set dummy ${ac_tool_prefix}strip; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_STRIP+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$STRIP"; then
++  ac_cv_prog_STRIP="$STRIP" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_STRIP="${ac_tool_prefix}strip"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++STRIP=$ac_cv_prog_STRIP
++if test -n "$STRIP"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $STRIP" >&5
++$as_echo "$STRIP" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++fi
++if test -z "$ac_cv_prog_STRIP"; then
++  ac_ct_STRIP=$STRIP
++  # Extract the first word of "strip", so it can be a program name with args.
++set dummy strip; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_ac_ct_STRIP+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$ac_ct_STRIP"; then
++  ac_cv_prog_ac_ct_STRIP="$ac_ct_STRIP" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_ac_ct_STRIP="strip"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++ac_ct_STRIP=$ac_cv_prog_ac_ct_STRIP
++if test -n "$ac_ct_STRIP"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_STRIP" >&5
++$as_echo "$ac_ct_STRIP" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++  if test "x$ac_ct_STRIP" = x; then
++    STRIP=":"
++  else
++    case $cross_compiling:$ac_tool_warned in
++yes:)
++{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
++$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
++ac_tool_warned=yes ;;
++esac
++    STRIP=$ac_ct_STRIP
++  fi
++else
++  STRIP="$ac_cv_prog_STRIP"
++fi
++
++test -z "$STRIP" && STRIP=:
++
++
++
++
++
++
++if test -n "$ac_tool_prefix"; then
++  # Extract the first word of "${ac_tool_prefix}ranlib", so it can be a program name with args.
++set dummy ${ac_tool_prefix}ranlib; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_RANLIB+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$RANLIB"; then
++  ac_cv_prog_RANLIB="$RANLIB" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_RANLIB="${ac_tool_prefix}ranlib"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++RANLIB=$ac_cv_prog_RANLIB
++if test -n "$RANLIB"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $RANLIB" >&5
++$as_echo "$RANLIB" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++fi
++if test -z "$ac_cv_prog_RANLIB"; then
++  ac_ct_RANLIB=$RANLIB
++  # Extract the first word of "ranlib", so it can be a program name with args.
++set dummy ranlib; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_ac_ct_RANLIB+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$ac_ct_RANLIB"; then
++  ac_cv_prog_ac_ct_RANLIB="$ac_ct_RANLIB" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_ac_ct_RANLIB="ranlib"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++ac_ct_RANLIB=$ac_cv_prog_ac_ct_RANLIB
++if test -n "$ac_ct_RANLIB"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_RANLIB" >&5
++$as_echo "$ac_ct_RANLIB" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++  if test "x$ac_ct_RANLIB" = x; then
++    RANLIB=":"
++  else
++    case $cross_compiling:$ac_tool_warned in
++yes:)
++{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
++$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
++ac_tool_warned=yes ;;
++esac
++    RANLIB=$ac_ct_RANLIB
++  fi
++else
++  RANLIB="$ac_cv_prog_RANLIB"
++fi
++
++test -z "$RANLIB" && RANLIB=:
++
++
++
++
++
++
++# Determine commands to create old-style static archives.
++old_archive_cmds='$AR $AR_FLAGS $oldlib$oldobjs'
++old_postinstall_cmds='chmod 644 $oldlib'
++old_postuninstall_cmds=
++
++if test -n "$RANLIB"; then
++  case $host_os in
++  openbsd*)
++    old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$oldlib"
++    ;;
++  *)
++    old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
++    ;;
++  esac
++  old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib"
++fi
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++# If no C compiler was specified, use CC.
++LTCC=${LTCC-"$CC"}
++
++# If no C compiler flags were specified, use CFLAGS.
++LTCFLAGS=${LTCFLAGS-"$CFLAGS"}
++
++# Allow CC to be a program name with arguments.
++compiler=$CC
++
++
++# Check for command to grab the raw symbol name followed by C symbol from nm.
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking command to parse $NM output from $compiler object" >&5
++$as_echo_n "checking command to parse $NM output from $compiler object... " >&6; }
++if test "${lt_cv_sys_global_symbol_pipe+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++# These are sane defaults that work on at least a few old systems.
++# [They come from Ultrix.  What could be older than Ultrix?!! ;)]
++
++# Character class describing NM global symbol codes.
++symcode='[BCDEGRST]'
++
++# Regexp to match symbols that can be accessed directly from C.
++sympat='\([_A-Za-z][_A-Za-z0-9]*\)'
++
++# Define system-specific variables.
++case $host_os in
++aix*)
++  symcode='[BCDT]'
++  ;;
++cygwin* | mingw* | pw32* | cegcc*)
++  symcode='[ABCDGISTW]'
++  ;;
++hpux*)
++  if test "$host_cpu" = ia64; then
++    symcode='[ABCDEGRST]'
++  fi
++  ;;
++irix* | nonstopux*)
++  symcode='[BCDEGRST]'
++  ;;
++osf*)
++  symcode='[BCDEGQRST]'
++  ;;
++solaris*)
++  symcode='[BDRT]'
++  ;;
++sco3.2v5*)
++  symcode='[DT]'
++  ;;
++sysv4.2uw2*)
++  symcode='[DT]'
++  ;;
++sysv5* | sco5v6* | unixware* | OpenUNIX*)
++  symcode='[ABDT]'
++  ;;
++sysv4)
++  symcode='[DFNSTU]'
++  ;;
++esac
++
++# If we're using GNU nm, then use its standard symbol codes.
++case `$NM -V 2>&1` in
++*GNU* | *'with BFD'*)
++  symcode='[ABCDGIRSTW]' ;;
++esac
++
++# Transform an extracted symbol line into a proper C declaration.
++# Some systems (esp. on ia64) link data and code symbols differently,
++# so use this general approach.
++lt_cv_sys_global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern int \1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'"
++
++# Transform an extracted symbol line into symbol name and symbol address
++lt_cv_sys_global_symbol_to_c_name_address="sed -n -e 's/^: \([^ ]*\) $/  {\\\"\1\\\", (void *) 0},/p' -e 's/^$symcode* \([^ ]*\) \([^ ]*\)$/  {\"\2\", (void *) \&\2},/p'"
++lt_cv_sys_global_symbol_to_c_name_address_lib_prefix="sed -n -e 's/^: \([^ ]*\) $/  {\\\"\1\\\", (void *) 0},/p' -e 's/^$symcode* \([^ ]*\) \(lib[^ ]*\)$/  {\"\2\", (void *) \&\2},/p' -e 's/^$symcode* \([^ ]*\) \([^ ]*\)$/  {\"lib\2\", (void *) \&\2},/p'"
++
++# Handle CRLF in mingw tool chain
++opt_cr=
++case $build_os in
++mingw*)
++  opt_cr=`$ECHO 'x\{0,1\}' | tr x '\015'` # option cr in regexp
++  ;;
++esac
++
++# Try without a prefix underscore, then with it.
++for ac_symprfx in "" "_"; do
++
++  # Transform symcode, sympat, and symprfx into a raw symbol and a C symbol.
++  symxfrm="\\1 $ac_symprfx\\2 \\2"
++
++  # Write the raw and C identifiers.
++  if test "$lt_cv_nm_interface" = "MS dumpbin"; then
++    # Fake it for dumpbin and say T for any non-static function
++    # and D for any global variable.
++    # Also find C++ and __fastcall symbols from MSVC++,
++    # which start with @ or ?.
++    lt_cv_sys_global_symbol_pipe="$AWK '"\
++"     {last_section=section; section=\$ 3};"\
++"     /Section length .*#relocs.*(pick any)/{hide[last_section]=1};"\
++"     \$ 0!~/External *\|/{next};"\
++"     / 0+ UNDEF /{next}; / UNDEF \([^|]\)*()/{next};"\
++"     {if(hide[section]) next};"\
++"     {f=0}; \$ 0~/\(\).*\|/{f=1}; {printf f ? \"T \" : \"D \"};"\
++"     {split(\$ 0, a, /\||\r/); split(a[2], s)};"\
++"     s[1]~/^[@?]/{print s[1], s[1]; next};"\
++"     s[1]~prfx {split(s[1],t,\"@\"); print t[1], substr(t[1],length(prfx))}"\
++"     ' prfx=^$ac_symprfx"
++  else
++    lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[	 ]\($symcode$symcode*\)[	 ][	 ]*$ac_symprfx$sympat$opt_cr$/$symxfrm/p'"
++  fi
++
++  # Check to see that the pipe works correctly.
++  pipe_works=no
++
++  rm -f conftest*
++  cat > conftest.$ac_ext <<_LT_EOF
++#ifdef __cplusplus
++extern "C" {
++#endif
++char nm_test_var;
++void nm_test_func(void);
++void nm_test_func(void){}
++#ifdef __cplusplus
++}
++#endif
++int main(){nm_test_var='a';nm_test_func();return(0);}
++_LT_EOF
++
++  if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_compile\""; } >&5
++  (eval $ac_compile) 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; then
++    # Now try to grab the symbols.
++    nlist=conftest.nm
++    if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$NM conftest.$ac_objext \| $lt_cv_sys_global_symbol_pipe \> $nlist\""; } >&5
++  (eval $NM conftest.$ac_objext \| $lt_cv_sys_global_symbol_pipe \> $nlist) 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; } && test -s "$nlist"; then
++      # Try sorting and uniquifying the output.
++      if sort "$nlist" | uniq > "$nlist"T; then
++	mv -f "$nlist"T "$nlist"
++      else
++	rm -f "$nlist"T
++      fi
++
++      # Make sure that we snagged all the symbols we need.
++      if $GREP ' nm_test_var$' "$nlist" >/dev/null; then
++	if $GREP ' nm_test_func$' "$nlist" >/dev/null; then
++	  cat <<_LT_EOF > conftest.$ac_ext
++#ifdef __cplusplus
++extern "C" {
++#endif
++
++_LT_EOF
++	  # Now generate the symbol file.
++	  eval "$lt_cv_sys_global_symbol_to_cdecl"' < "$nlist" | $GREP -v main >> conftest.$ac_ext'
++
++	  cat <<_LT_EOF >> conftest.$ac_ext
++
++/* The mapping between symbol names and symbols.  */
++const struct {
++  const char *name;
++  void       *address;
++}
++lt__PROGRAM__LTX_preloaded_symbols[] =
++{
++  { "@PROGRAM@", (void *) 0 },
++_LT_EOF
++	  $SED "s/^$symcode$symcode* \(.*\) \(.*\)$/  {\"\2\", (void *) \&\2},/" < "$nlist" | $GREP -v main >> conftest.$ac_ext
++	  cat <<\_LT_EOF >> conftest.$ac_ext
++  {0, (void *) 0}
++};
++
++/* This works around a problem in FreeBSD linker */
++#ifdef FREEBSD_WORKAROUND
++static const void *lt_preloaded_setup() {
++  return lt__PROGRAM__LTX_preloaded_symbols;
++}
++#endif
++
++#ifdef __cplusplus
++}
++#endif
++_LT_EOF
++	  # Now try linking the two files.
++	  mv conftest.$ac_objext conftstm.$ac_objext
++	  lt_save_LIBS="$LIBS"
++	  lt_save_CFLAGS="$CFLAGS"
++	  LIBS="conftstm.$ac_objext"
++	  CFLAGS="$CFLAGS$lt_prog_compiler_no_builtin_flag"
++	  if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_link\""; } >&5
++  (eval $ac_link) 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; } && test -s conftest${ac_exeext}; then
++	    pipe_works=yes
++	  fi
++	  LIBS="$lt_save_LIBS"
++	  CFLAGS="$lt_save_CFLAGS"
++	else
++	  echo "cannot find nm_test_func in $nlist" >&5
++	fi
++      else
++	echo "cannot find nm_test_var in $nlist" >&5
++      fi
++    else
++      echo "cannot run $lt_cv_sys_global_symbol_pipe" >&5
++    fi
++  else
++    echo "$progname: failed program was:" >&5
++    cat conftest.$ac_ext >&5
++  fi
++  rm -rf conftest* conftst*
++
++  # Do not use the global_symbol_pipe unless it works.
++  if test "$pipe_works" = yes; then
++    break
++  else
++    lt_cv_sys_global_symbol_pipe=
++  fi
++done
++
++fi
++
++if test -z "$lt_cv_sys_global_symbol_pipe"; then
++  lt_cv_sys_global_symbol_to_cdecl=
++fi
++if test -z "$lt_cv_sys_global_symbol_pipe$lt_cv_sys_global_symbol_to_cdecl"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: failed" >&5
++$as_echo "failed" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: ok" >&5
++$as_echo "ok" >&6; }
++fi
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++# Check whether --enable-libtool-lock was given.
++if test "${enable_libtool_lock+set}" = set; then :
++  enableval=$enable_libtool_lock;
++fi
++
++test "x$enable_libtool_lock" != xno && enable_libtool_lock=yes
++
++# Some flags need to be propagated to the compiler or linker for good
++# libtool support.
++case $host in
++ia64-*-hpux*)
++  # Find out which ABI we are using.
++  echo 'int i;' > conftest.$ac_ext
++  if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_compile\""; } >&5
++  (eval $ac_compile) 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; then
++    case `/usr/bin/file conftest.$ac_objext` in
++      *ELF-32*)
++	HPUX_IA64_MODE="32"
++	;;
++      *ELF-64*)
++	HPUX_IA64_MODE="64"
++	;;
++    esac
++  fi
++  rm -rf conftest*
++  ;;
++*-*-irix6*)
++  # Find out which ABI we are using.
++  echo '#line 6416 "configure"' > conftest.$ac_ext
++  if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_compile\""; } >&5
++  (eval $ac_compile) 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; then
++    if test "$lt_cv_prog_gnu_ld" = yes; then
++      case `/usr/bin/file conftest.$ac_objext` in
++	*32-bit*)
++	  LD="${LD-ld} -melf32bsmip"
++	  ;;
++	*N32*)
++	  LD="${LD-ld} -melf32bmipn32"
++	  ;;
++	*64-bit*)
++	  LD="${LD-ld} -melf64bmip"
++	;;
++      esac
++    else
++      case `/usr/bin/file conftest.$ac_objext` in
++	*32-bit*)
++	  LD="${LD-ld} -32"
++	  ;;
++	*N32*)
++	  LD="${LD-ld} -n32"
++	  ;;
++	*64-bit*)
++	  LD="${LD-ld} -64"
++	  ;;
++      esac
++    fi
++  fi
++  rm -rf conftest*
++  ;;
++
++x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
++s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
++  # Find out which ABI we are using.
++  echo 'int i;' > conftest.$ac_ext
++  if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_compile\""; } >&5
++  (eval $ac_compile) 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; then
++    case `/usr/bin/file conftest.o` in
++      *32-bit*)
++	case $host in
++	  x86_64-*kfreebsd*-gnu)
++	    LD="${LD-ld} -m elf_i386_fbsd"
++	    ;;
++	  x86_64-*linux*)
++	    LD="${LD-ld} -m elf_i386"
++	    ;;
++	  ppc64-*linux*|powerpc64-*linux*)
++	    LD="${LD-ld} -m elf32ppclinux"
++	    ;;
++	  s390x-*linux*)
++	    LD="${LD-ld} -m elf_s390"
++	    ;;
++	  sparc64-*linux*)
++	    LD="${LD-ld} -m elf32_sparc"
++	    ;;
++	esac
++	;;
++      *64-bit*)
++	case $host in
++	  x86_64-*kfreebsd*-gnu)
++	    LD="${LD-ld} -m elf_x86_64_fbsd"
++	    ;;
++	  x86_64-*linux*)
++	    LD="${LD-ld} -m elf_x86_64"
++	    ;;
++	  ppc*-*linux*|powerpc*-*linux*)
++	    LD="${LD-ld} -m elf64ppc"
++	    ;;
++	  s390*-*linux*|s390*-*tpf*)
++	    LD="${LD-ld} -m elf64_s390"
++	    ;;
++	  sparc*-*linux*)
++	    LD="${LD-ld} -m elf64_sparc"
++	    ;;
++	esac
++	;;
++    esac
++  fi
++  rm -rf conftest*
++  ;;
++
++*-*-sco3.2v5*)
++  # On SCO OpenServer 5, we need -belf to get full-featured binaries.
++  SAVE_CFLAGS="$CFLAGS"
++  CFLAGS="$CFLAGS -belf"
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the C compiler needs -belf" >&5
++$as_echo_n "checking whether the C compiler needs -belf... " >&6; }
++if test "${lt_cv_cc_needs_belf+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_ext=c
++ac_cpp='$CPP $CPPFLAGS'
++ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
++ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
++ac_compiler_gnu=$ac_cv_c_compiler_gnu
++
++     cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  lt_cv_cc_needs_belf=yes
++else
++  lt_cv_cc_needs_belf=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++     ac_ext=c
++ac_cpp='$CPP $CPPFLAGS'
++ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
++ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
++ac_compiler_gnu=$ac_cv_c_compiler_gnu
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_cc_needs_belf" >&5
++$as_echo "$lt_cv_cc_needs_belf" >&6; }
++  if test x"$lt_cv_cc_needs_belf" != x"yes"; then
++    # this is probably gcc 2.8.0, egcs 1.0 or newer; no need for -belf
++    CFLAGS="$SAVE_CFLAGS"
++  fi
++  ;;
++sparc*-*solaris*)
++  # Find out which ABI we are using.
++  echo 'int i;' > conftest.$ac_ext
++  if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_compile\""; } >&5
++  (eval $ac_compile) 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; then
++    case `/usr/bin/file conftest.o` in
++    *64-bit*)
++      case $lt_cv_prog_gnu_ld in
++      yes*) LD="${LD-ld} -m elf64_sparc" ;;
++      *)
++	if ${LD-ld} -64 -r -o conftest2.o conftest.o >/dev/null 2>&1; then
++	  LD="${LD-ld} -64"
++	fi
++	;;
++      esac
++      ;;
++    esac
++  fi
++  rm -rf conftest*
++  ;;
++esac
++
++need_locks="$enable_libtool_lock"
++
++
++  case $host_os in
++    rhapsody* | darwin*)
++    if test -n "$ac_tool_prefix"; then
++  # Extract the first word of "${ac_tool_prefix}dsymutil", so it can be a program name with args.
++set dummy ${ac_tool_prefix}dsymutil; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_DSYMUTIL+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$DSYMUTIL"; then
++  ac_cv_prog_DSYMUTIL="$DSYMUTIL" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_DSYMUTIL="${ac_tool_prefix}dsymutil"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++DSYMUTIL=$ac_cv_prog_DSYMUTIL
++if test -n "$DSYMUTIL"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $DSYMUTIL" >&5
++$as_echo "$DSYMUTIL" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++fi
++if test -z "$ac_cv_prog_DSYMUTIL"; then
++  ac_ct_DSYMUTIL=$DSYMUTIL
++  # Extract the first word of "dsymutil", so it can be a program name with args.
++set dummy dsymutil; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_ac_ct_DSYMUTIL+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$ac_ct_DSYMUTIL"; then
++  ac_cv_prog_ac_ct_DSYMUTIL="$ac_ct_DSYMUTIL" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_ac_ct_DSYMUTIL="dsymutil"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++ac_ct_DSYMUTIL=$ac_cv_prog_ac_ct_DSYMUTIL
++if test -n "$ac_ct_DSYMUTIL"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_DSYMUTIL" >&5
++$as_echo "$ac_ct_DSYMUTIL" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++  if test "x$ac_ct_DSYMUTIL" = x; then
++    DSYMUTIL=":"
++  else
++    case $cross_compiling:$ac_tool_warned in
++yes:)
++{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
++$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
++ac_tool_warned=yes ;;
++esac
++    DSYMUTIL=$ac_ct_DSYMUTIL
++  fi
++else
++  DSYMUTIL="$ac_cv_prog_DSYMUTIL"
++fi
++
++    if test -n "$ac_tool_prefix"; then
++  # Extract the first word of "${ac_tool_prefix}nmedit", so it can be a program name with args.
++set dummy ${ac_tool_prefix}nmedit; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_NMEDIT+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$NMEDIT"; then
++  ac_cv_prog_NMEDIT="$NMEDIT" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_NMEDIT="${ac_tool_prefix}nmedit"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++NMEDIT=$ac_cv_prog_NMEDIT
++if test -n "$NMEDIT"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $NMEDIT" >&5
++$as_echo "$NMEDIT" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++fi
++if test -z "$ac_cv_prog_NMEDIT"; then
++  ac_ct_NMEDIT=$NMEDIT
++  # Extract the first word of "nmedit", so it can be a program name with args.
++set dummy nmedit; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_ac_ct_NMEDIT+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$ac_ct_NMEDIT"; then
++  ac_cv_prog_ac_ct_NMEDIT="$ac_ct_NMEDIT" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_ac_ct_NMEDIT="nmedit"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++ac_ct_NMEDIT=$ac_cv_prog_ac_ct_NMEDIT
++if test -n "$ac_ct_NMEDIT"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_NMEDIT" >&5
++$as_echo "$ac_ct_NMEDIT" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++  if test "x$ac_ct_NMEDIT" = x; then
++    NMEDIT=":"
++  else
++    case $cross_compiling:$ac_tool_warned in
++yes:)
++{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
++$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
++ac_tool_warned=yes ;;
++esac
++    NMEDIT=$ac_ct_NMEDIT
++  fi
++else
++  NMEDIT="$ac_cv_prog_NMEDIT"
++fi
++
++    if test -n "$ac_tool_prefix"; then
++  # Extract the first word of "${ac_tool_prefix}lipo", so it can be a program name with args.
++set dummy ${ac_tool_prefix}lipo; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_LIPO+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$LIPO"; then
++  ac_cv_prog_LIPO="$LIPO" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_LIPO="${ac_tool_prefix}lipo"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++LIPO=$ac_cv_prog_LIPO
++if test -n "$LIPO"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $LIPO" >&5
++$as_echo "$LIPO" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++fi
++if test -z "$ac_cv_prog_LIPO"; then
++  ac_ct_LIPO=$LIPO
++  # Extract the first word of "lipo", so it can be a program name with args.
++set dummy lipo; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_ac_ct_LIPO+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$ac_ct_LIPO"; then
++  ac_cv_prog_ac_ct_LIPO="$ac_ct_LIPO" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_ac_ct_LIPO="lipo"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++ac_ct_LIPO=$ac_cv_prog_ac_ct_LIPO
++if test -n "$ac_ct_LIPO"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_LIPO" >&5
++$as_echo "$ac_ct_LIPO" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++  if test "x$ac_ct_LIPO" = x; then
++    LIPO=":"
++  else
++    case $cross_compiling:$ac_tool_warned in
++yes:)
++{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
++$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
++ac_tool_warned=yes ;;
++esac
++    LIPO=$ac_ct_LIPO
++  fi
++else
++  LIPO="$ac_cv_prog_LIPO"
++fi
++
++    if test -n "$ac_tool_prefix"; then
++  # Extract the first word of "${ac_tool_prefix}otool", so it can be a program name with args.
++set dummy ${ac_tool_prefix}otool; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_OTOOL+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$OTOOL"; then
++  ac_cv_prog_OTOOL="$OTOOL" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_OTOOL="${ac_tool_prefix}otool"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++OTOOL=$ac_cv_prog_OTOOL
++if test -n "$OTOOL"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $OTOOL" >&5
++$as_echo "$OTOOL" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++fi
++if test -z "$ac_cv_prog_OTOOL"; then
++  ac_ct_OTOOL=$OTOOL
++  # Extract the first word of "otool", so it can be a program name with args.
++set dummy otool; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_ac_ct_OTOOL+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$ac_ct_OTOOL"; then
++  ac_cv_prog_ac_ct_OTOOL="$ac_ct_OTOOL" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_ac_ct_OTOOL="otool"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++ac_ct_OTOOL=$ac_cv_prog_ac_ct_OTOOL
++if test -n "$ac_ct_OTOOL"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_OTOOL" >&5
++$as_echo "$ac_ct_OTOOL" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++  if test "x$ac_ct_OTOOL" = x; then
++    OTOOL=":"
++  else
++    case $cross_compiling:$ac_tool_warned in
++yes:)
++{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
++$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
++ac_tool_warned=yes ;;
++esac
++    OTOOL=$ac_ct_OTOOL
++  fi
++else
++  OTOOL="$ac_cv_prog_OTOOL"
++fi
++
++    if test -n "$ac_tool_prefix"; then
++  # Extract the first word of "${ac_tool_prefix}otool64", so it can be a program name with args.
++set dummy ${ac_tool_prefix}otool64; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_OTOOL64+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$OTOOL64"; then
++  ac_cv_prog_OTOOL64="$OTOOL64" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_OTOOL64="${ac_tool_prefix}otool64"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++OTOOL64=$ac_cv_prog_OTOOL64
++if test -n "$OTOOL64"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $OTOOL64" >&5
++$as_echo "$OTOOL64" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++fi
++if test -z "$ac_cv_prog_OTOOL64"; then
++  ac_ct_OTOOL64=$OTOOL64
++  # Extract the first word of "otool64", so it can be a program name with args.
++set dummy otool64; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_ac_ct_OTOOL64+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$ac_ct_OTOOL64"; then
++  ac_cv_prog_ac_ct_OTOOL64="$ac_ct_OTOOL64" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_ac_ct_OTOOL64="otool64"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++ac_ct_OTOOL64=$ac_cv_prog_ac_ct_OTOOL64
++if test -n "$ac_ct_OTOOL64"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_OTOOL64" >&5
++$as_echo "$ac_ct_OTOOL64" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++  if test "x$ac_ct_OTOOL64" = x; then
++    OTOOL64=":"
++  else
++    case $cross_compiling:$ac_tool_warned in
++yes:)
++{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
++$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
++ac_tool_warned=yes ;;
++esac
++    OTOOL64=$ac_ct_OTOOL64
++  fi
++else
++  OTOOL64="$ac_cv_prog_OTOOL64"
++fi
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for -single_module linker flag" >&5
++$as_echo_n "checking for -single_module linker flag... " >&6; }
++if test "${lt_cv_apple_cc_single_mod+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  lt_cv_apple_cc_single_mod=no
++      if test -z "${LT_MULTI_MODULE}"; then
++	# By default we will add the -single_module flag. You can override
++	# by either setting the environment variable LT_MULTI_MODULE
++	# non-empty at configure time, or by adding -multi_module to the
++	# link flags.
++	rm -rf libconftest.dylib*
++	echo "int foo(void){return 1;}" > conftest.c
++	echo "$LTCC $LTCFLAGS $LDFLAGS -o libconftest.dylib \
++-dynamiclib -Wl,-single_module conftest.c" >&5
++	$LTCC $LTCFLAGS $LDFLAGS -o libconftest.dylib \
++	  -dynamiclib -Wl,-single_module conftest.c 2>conftest.err
++        _lt_result=$?
++	if test -f libconftest.dylib && test ! -s conftest.err && test $_lt_result = 0; then
++	  lt_cv_apple_cc_single_mod=yes
++	else
++	  cat conftest.err >&5
++	fi
++	rm -rf libconftest.dylib*
++	rm -f conftest.*
++      fi
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_apple_cc_single_mod" >&5
++$as_echo "$lt_cv_apple_cc_single_mod" >&6; }
++    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for -exported_symbols_list linker flag" >&5
++$as_echo_n "checking for -exported_symbols_list linker flag... " >&6; }
++if test "${lt_cv_ld_exported_symbols_list+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  lt_cv_ld_exported_symbols_list=no
++      save_LDFLAGS=$LDFLAGS
++      echo "_main" > conftest.sym
++      LDFLAGS="$LDFLAGS -Wl,-exported_symbols_list,conftest.sym"
++      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  lt_cv_ld_exported_symbols_list=yes
++else
++  lt_cv_ld_exported_symbols_list=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	LDFLAGS="$save_LDFLAGS"
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_ld_exported_symbols_list" >&5
++$as_echo "$lt_cv_ld_exported_symbols_list" >&6; }
++    case $host_os in
++    rhapsody* | darwin1.[012])
++      _lt_dar_allow_undefined='${wl}-undefined ${wl}suppress' ;;
++    darwin1.*)
++      _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
++    darwin*) # darwin 5.x on
++      # if running on 10.5 or later, the deployment target defaults
++      # to the OS version, if on x86, and 10.4, the deployment
++      # target defaults to 10.4. Don't you love it?
++      case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
++	10.0,*86*-darwin8*|10.0,*-darwin[91]*)
++	  _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
++	10.[012]*)
++	  _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
++	10.*)
++	  _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
++      esac
++    ;;
++  esac
++    if test "$lt_cv_apple_cc_single_mod" = "yes"; then
++      _lt_dar_single_mod='$single_module'
++    fi
++    if test "$lt_cv_ld_exported_symbols_list" = "yes"; then
++      _lt_dar_export_syms=' ${wl}-exported_symbols_list,$output_objdir/${libname}-symbols.expsym'
++    else
++      _lt_dar_export_syms='~$NMEDIT -s $output_objdir/${libname}-symbols.expsym ${lib}'
++    fi
++    if test "$DSYMUTIL" != ":"; then
++      _lt_dsymutil='~$DSYMUTIL $lib || :'
++    else
++      _lt_dsymutil=
++    fi
++    ;;
++  esac
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ANSI C header files" >&5
++$as_echo_n "checking for ANSI C header files... " >&6; }
++if test "${ac_cv_header_stdc+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdlib.h>
++#include <stdarg.h>
++#include <string.h>
++#include <float.h>
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_header_stdc=yes
++else
++  ac_cv_header_stdc=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++if test $ac_cv_header_stdc = yes; then
++  # SunOS 4.x string.h does not declare mem*, contrary to ANSI.
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <string.h>
++
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "memchr" >/dev/null 2>&1; then :
++
++else
++  ac_cv_header_stdc=no
++fi
++rm -f conftest*
++
++fi
++
++if test $ac_cv_header_stdc = yes; then
++  # ISC 2.0.2 stdlib.h does not declare free, contrary to ANSI.
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdlib.h>
++
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "free" >/dev/null 2>&1; then :
++
++else
++  ac_cv_header_stdc=no
++fi
++rm -f conftest*
++
++fi
++
++if test $ac_cv_header_stdc = yes; then
++  # /bin/cc in Irix-4.0.5 gets non-ANSI ctype macros unless using -ansi.
++  if test "$cross_compiling" = yes; then :
++  :
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <ctype.h>
++#include <stdlib.h>
++#if ((' ' & 0x0FF) == 0x020)
++# define ISLOWER(c) ('a' <= (c) && (c) <= 'z')
++# define TOUPPER(c) (ISLOWER(c) ? 'A' + ((c) - 'a') : (c))
++#else
++# define ISLOWER(c) \
++		   (('a' <= (c) && (c) <= 'i') \
++		     || ('j' <= (c) && (c) <= 'r') \
++		     || ('s' <= (c) && (c) <= 'z'))
++# define TOUPPER(c) (ISLOWER(c) ? ((c) | 0x40) : (c))
++#endif
++
++#define XOR(e, f) (((e) && !(f)) || (!(e) && (f)))
++int
++main ()
++{
++  int i;
++  for (i = 0; i < 256; i++)
++    if (XOR (islower (i), ISLOWER (i))
++	|| toupper (i) != TOUPPER (i))
++      return 2;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_run "$LINENO"; then :
++
++else
++  ac_cv_header_stdc=no
++fi
++rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
++  conftest.$ac_objext conftest.beam conftest.$ac_ext
++fi
++
++fi
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_header_stdc" >&5
++$as_echo "$ac_cv_header_stdc" >&6; }
++if test $ac_cv_header_stdc = yes; then
++
++$as_echo "#define STDC_HEADERS 1" >>confdefs.h
++
++fi
++
++# On IRIX 5.3, sys/types and inttypes.h are conflicting.
++for ac_header in sys/types.h sys/stat.h stdlib.h string.h memory.h strings.h \
++		  inttypes.h stdint.h unistd.h
++do :
++  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
++ac_fn_c_check_header_compile "$LINENO" "$ac_header" "$as_ac_Header" "$ac_includes_default
++"
++if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in dlfcn.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "dlfcn.h" "ac_cv_header_dlfcn_h" "$ac_includes_default
++"
++if test "x$ac_cv_header_dlfcn_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_DLFCN_H 1
++_ACEOF
++
++fi
++
++done
++
++
++
++# Set options
++
++
++
++        enable_dlopen=no
++
++
++  enable_win32_dll=no
++
++
++            # Check whether --enable-shared was given.
++if test "${enable_shared+set}" = set; then :
++  enableval=$enable_shared; p=${PACKAGE-default}
++    case $enableval in
++    yes) enable_shared=yes ;;
++    no) enable_shared=no ;;
++    *)
++      enable_shared=no
++      # Look at the argument we got.  We use all the common list separators.
++      lt_save_ifs="$IFS"; IFS="${IFS}$PATH_SEPARATOR,"
++      for pkg in $enableval; do
++	IFS="$lt_save_ifs"
++	if test "X$pkg" = "X$p"; then
++	  enable_shared=yes
++	fi
++      done
++      IFS="$lt_save_ifs"
++      ;;
++    esac
++else
++  enable_shared=yes
++fi
++
++
++
++
++
++
++
++
++
++  # Check whether --enable-static was given.
++if test "${enable_static+set}" = set; then :
++  enableval=$enable_static; p=${PACKAGE-default}
++    case $enableval in
++    yes) enable_static=yes ;;
++    no) enable_static=no ;;
++    *)
++     enable_static=no
++      # Look at the argument we got.  We use all the common list separators.
++      lt_save_ifs="$IFS"; IFS="${IFS}$PATH_SEPARATOR,"
++      for pkg in $enableval; do
++	IFS="$lt_save_ifs"
++	if test "X$pkg" = "X$p"; then
++	  enable_static=yes
++	fi
++      done
++      IFS="$lt_save_ifs"
++      ;;
++    esac
++else
++  enable_static=yes
++fi
++
++
++
++
++
++
++
++
++
++
++# Check whether --with-pic was given.
++if test "${with_pic+set}" = set; then :
++  withval=$with_pic; pic_mode="$withval"
++else
++  pic_mode=default
++fi
++
++
++test -z "$pic_mode" && pic_mode=default
++
++
++
++
++
++
++
++  # Check whether --enable-fast-install was given.
++if test "${enable_fast_install+set}" = set; then :
++  enableval=$enable_fast_install; p=${PACKAGE-default}
++    case $enableval in
++    yes) enable_fast_install=yes ;;
++    no) enable_fast_install=no ;;
++    *)
++      enable_fast_install=no
++      # Look at the argument we got.  We use all the common list separators.
++      lt_save_ifs="$IFS"; IFS="${IFS}$PATH_SEPARATOR,"
++      for pkg in $enableval; do
++	IFS="$lt_save_ifs"
++	if test "X$pkg" = "X$p"; then
++	  enable_fast_install=yes
++	fi
++      done
++      IFS="$lt_save_ifs"
++      ;;
++    esac
++else
++  enable_fast_install=yes
++fi
++
++
++
++
++
++
++
++
++
++
++
++# This can be used to rebuild libtool when needed
++LIBTOOL_DEPS="$ltmain"
++
++# Always use our own libtool.
++LIBTOOL='$(SHELL) $(top_builddir)/libtool'
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++test -z "$LN_S" && LN_S="ln -s"
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++if test -n "${ZSH_VERSION+set}" ; then
++   setopt NO_GLOB_SUBST
++fi
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for objdir" >&5
++$as_echo_n "checking for objdir... " >&6; }
++if test "${lt_cv_objdir+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  rm -f .libs 2>/dev/null
++mkdir .libs 2>/dev/null
++if test -d .libs; then
++  lt_cv_objdir=.libs
++else
++  # MS-DOS does not allow filenames that begin with a dot.
++  lt_cv_objdir=_libs
++fi
++rmdir .libs 2>/dev/null
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_objdir" >&5
++$as_echo "$lt_cv_objdir" >&6; }
++objdir=$lt_cv_objdir
++
++
++
++
++
++cat >>confdefs.h <<_ACEOF
++#define LT_OBJDIR "$lt_cv_objdir/"
++_ACEOF
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++case $host_os in
++aix3*)
++  # AIX sometimes has problems with the GCC collect2 program.  For some
++  # reason, if we set the COLLECT_NAMES environment variable, the problems
++  # vanish in a puff of smoke.
++  if test "X${COLLECT_NAMES+set}" != Xset; then
++    COLLECT_NAMES=
++    export COLLECT_NAMES
++  fi
++  ;;
++esac
++
++# Sed substitution that helps us do robust quoting.  It backslashifies
++# metacharacters that are still active within double-quoted strings.
++sed_quote_subst='s/\(["`$\\]\)/\\\1/g'
++
++# Same as above, but do not quote variable references.
++double_quote_subst='s/\(["`\\]\)/\\\1/g'
++
++# Sed substitution to delay expansion of an escaped shell variable in a
++# double_quote_subst'ed string.
++delay_variable_subst='s/\\\\\\\\\\\$/\\\\\\$/g'
++
++# Sed substitution to delay expansion of an escaped single quote.
++delay_single_quote_subst='s/'\''/'\'\\\\\\\'\''/g'
++
++# Sed substitution to avoid accidental globbing in evaled expressions
++no_glob_subst='s/\*/\\\*/g'
++
++# Global variables:
++ofile=libtool
++can_build_shared=yes
++
++# All known linkers require a `.a' archive for static linking (except MSVC,
++# which needs '.lib').
++libext=a
++
++with_gnu_ld="$lt_cv_prog_gnu_ld"
++
++old_CC="$CC"
++old_CFLAGS="$CFLAGS"
++
++# Set sane defaults for various variables
++test -z "$CC" && CC=cc
++test -z "$LTCC" && LTCC=$CC
++test -z "$LTCFLAGS" && LTCFLAGS=$CFLAGS
++test -z "$LD" && LD=ld
++test -z "$ac_objext" && ac_objext=o
++
++for cc_temp in $compiler""; do
++  case $cc_temp in
++    compile | *[\\/]compile | ccache | *[\\/]ccache ) ;;
++    distcc | *[\\/]distcc | purify | *[\\/]purify ) ;;
++    \-*) ;;
++    *) break;;
++  esac
++done
++cc_basename=`$ECHO "X$cc_temp" | $Xsed -e 's%.*/%%' -e "s%^$host_alias-%%"`
++
++
++# Only perform the check for file, if the check method requires it
++test -z "$MAGIC_CMD" && MAGIC_CMD=file
++case $deplibs_check_method in
++file_magic*)
++  if test "$file_magic_cmd" = '$MAGIC_CMD'; then
++    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ${ac_tool_prefix}file" >&5
++$as_echo_n "checking for ${ac_tool_prefix}file... " >&6; }
++if test "${lt_cv_path_MAGIC_CMD+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  case $MAGIC_CMD in
++[\\/*] |  ?:[\\/]*)
++  lt_cv_path_MAGIC_CMD="$MAGIC_CMD" # Let the user override the test with a path.
++  ;;
++*)
++  lt_save_MAGIC_CMD="$MAGIC_CMD"
++  lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
++  ac_dummy="/usr/bin$PATH_SEPARATOR$PATH"
++  for ac_dir in $ac_dummy; do
++    IFS="$lt_save_ifs"
++    test -z "$ac_dir" && ac_dir=.
++    if test -f $ac_dir/${ac_tool_prefix}file; then
++      lt_cv_path_MAGIC_CMD="$ac_dir/${ac_tool_prefix}file"
++      if test -n "$file_magic_test_file"; then
++	case $deplibs_check_method in
++	"file_magic "*)
++	  file_magic_regex=`expr "$deplibs_check_method" : "file_magic \(.*\)"`
++	  MAGIC_CMD="$lt_cv_path_MAGIC_CMD"
++	  if eval $file_magic_cmd \$file_magic_test_file 2> /dev/null |
++	    $EGREP "$file_magic_regex" > /dev/null; then
++	    :
++	  else
++	    cat <<_LT_EOF 1>&2
++
++*** Warning: the command libtool uses to detect shared libraries,
++*** $file_magic_cmd, produces output that libtool cannot recognize.
++*** The result is that libtool may fail to recognize shared libraries
++*** as such.  This will affect the creation of libtool libraries that
++*** depend on shared libraries, but programs linked with such libtool
++*** libraries will work regardless of this problem.  Nevertheless, you
++*** may want to report the problem to your system manager and/or to
++*** bug-libtool@gnu.org
++
++_LT_EOF
++	  fi ;;
++	esac
++      fi
++      break
++    fi
++  done
++  IFS="$lt_save_ifs"
++  MAGIC_CMD="$lt_save_MAGIC_CMD"
++  ;;
++esac
++fi
++
++MAGIC_CMD="$lt_cv_path_MAGIC_CMD"
++if test -n "$MAGIC_CMD"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $MAGIC_CMD" >&5
++$as_echo "$MAGIC_CMD" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++
++
++
++if test -z "$lt_cv_path_MAGIC_CMD"; then
++  if test -n "$ac_tool_prefix"; then
++    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for file" >&5
++$as_echo_n "checking for file... " >&6; }
++if test "${lt_cv_path_MAGIC_CMD+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  case $MAGIC_CMD in
++[\\/*] |  ?:[\\/]*)
++  lt_cv_path_MAGIC_CMD="$MAGIC_CMD" # Let the user override the test with a path.
++  ;;
++*)
++  lt_save_MAGIC_CMD="$MAGIC_CMD"
++  lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
++  ac_dummy="/usr/bin$PATH_SEPARATOR$PATH"
++  for ac_dir in $ac_dummy; do
++    IFS="$lt_save_ifs"
++    test -z "$ac_dir" && ac_dir=.
++    if test -f $ac_dir/file; then
++      lt_cv_path_MAGIC_CMD="$ac_dir/file"
++      if test -n "$file_magic_test_file"; then
++	case $deplibs_check_method in
++	"file_magic "*)
++	  file_magic_regex=`expr "$deplibs_check_method" : "file_magic \(.*\)"`
++	  MAGIC_CMD="$lt_cv_path_MAGIC_CMD"
++	  if eval $file_magic_cmd \$file_magic_test_file 2> /dev/null |
++	    $EGREP "$file_magic_regex" > /dev/null; then
++	    :
++	  else
++	    cat <<_LT_EOF 1>&2
++
++*** Warning: the command libtool uses to detect shared libraries,
++*** $file_magic_cmd, produces output that libtool cannot recognize.
++*** The result is that libtool may fail to recognize shared libraries
++*** as such.  This will affect the creation of libtool libraries that
++*** depend on shared libraries, but programs linked with such libtool
++*** libraries will work regardless of this problem.  Nevertheless, you
++*** may want to report the problem to your system manager and/or to
++*** bug-libtool@gnu.org
++
++_LT_EOF
++	  fi ;;
++	esac
++      fi
++      break
++    fi
++  done
++  IFS="$lt_save_ifs"
++  MAGIC_CMD="$lt_save_MAGIC_CMD"
++  ;;
++esac
++fi
++
++MAGIC_CMD="$lt_cv_path_MAGIC_CMD"
++if test -n "$MAGIC_CMD"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $MAGIC_CMD" >&5
++$as_echo "$MAGIC_CMD" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++  else
++    MAGIC_CMD=:
++  fi
++fi
++
++  fi
++  ;;
++esac
++
++# Use C for the default configuration in the libtool script
++
++lt_save_CC="$CC"
++ac_ext=c
++ac_cpp='$CPP $CPPFLAGS'
++ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
++ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
++ac_compiler_gnu=$ac_cv_c_compiler_gnu
++
++
++# Source file extension for C test sources.
++ac_ext=c
++
++# Object file extension for compiled C test sources.
++objext=o
++objext=$objext
++
++# Code to be used in simple compile tests
++lt_simple_compile_test_code="int some_variable = 0;"
++
++# Code to be used in simple link tests
++lt_simple_link_test_code='int main(){return(0);}'
++
++
++
++
++
++
++
++# If no C compiler was specified, use CC.
++LTCC=${LTCC-"$CC"}
++
++# If no C compiler flags were specified, use CFLAGS.
++LTCFLAGS=${LTCFLAGS-"$CFLAGS"}
++
++# Allow CC to be a program name with arguments.
++compiler=$CC
++
++# Save the default compiler, since it gets overwritten when the other
++# tags are being tested, and _LT_TAGVAR(compiler, []) is a NOP.
++compiler_DEFAULT=$CC
++
++# save warnings/boilerplate of simple test code
++ac_outfile=conftest.$ac_objext
++echo "$lt_simple_compile_test_code" >conftest.$ac_ext
++eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
++_lt_compiler_boilerplate=`cat conftest.err`
++$RM conftest*
++
++ac_outfile=conftest.$ac_objext
++echo "$lt_simple_link_test_code" >conftest.$ac_ext
++eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
++_lt_linker_boilerplate=`cat conftest.err`
++$RM -r conftest*
++
++
++## CAVEAT EMPTOR:
++## There is no encapsulation within the following macros, do not change
++## the running order or otherwise move them around unless you know exactly
++## what you are doing...
++if test -n "$compiler"; then
++
++lt_prog_compiler_no_builtin_flag=
++
++if test "$GCC" = yes; then
++  lt_prog_compiler_no_builtin_flag=' -fno-builtin'
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking if $compiler supports -fno-rtti -fno-exceptions" >&5
++$as_echo_n "checking if $compiler supports -fno-rtti -fno-exceptions... " >&6; }
++if test "${lt_cv_prog_compiler_rtti_exceptions+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  lt_cv_prog_compiler_rtti_exceptions=no
++   ac_outfile=conftest.$ac_objext
++   echo "$lt_simple_compile_test_code" > conftest.$ac_ext
++   lt_compiler_flag="-fno-rtti -fno-exceptions"
++   # Insert the option either (1) after the last *FLAGS variable, or
++   # (2) before a word containing "conftest.", or (3) at the end.
++   # Note that $ac_compile itself does not contain backslashes and begins
++   # with a dollar sign (not a hyphen), so the echo should work correctly.
++   # The option is referenced via a variable to avoid confusing sed.
++   lt_compile=`echo "$ac_compile" | $SED \
++   -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
++   -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
++   -e 's:$: $lt_compiler_flag:'`
++   (eval echo "\"\$as_me:7808: $lt_compile\"" >&5)
++   (eval "$lt_compile" 2>conftest.err)
++   ac_status=$?
++   cat conftest.err >&5
++   echo "$as_me:7812: \$? = $ac_status" >&5
++   if (exit $ac_status) && test -s "$ac_outfile"; then
++     # The compiler can only warn and ignore the option if not recognized
++     # So say no if there are warnings other than the usual output.
++     $ECHO "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' >conftest.exp
++     $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
++     if test ! -s conftest.er2 || diff conftest.exp conftest.er2 >/dev/null; then
++       lt_cv_prog_compiler_rtti_exceptions=yes
++     fi
++   fi
++   $RM conftest*
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_prog_compiler_rtti_exceptions" >&5
++$as_echo "$lt_cv_prog_compiler_rtti_exceptions" >&6; }
++
++if test x"$lt_cv_prog_compiler_rtti_exceptions" = xyes; then
++    lt_prog_compiler_no_builtin_flag="$lt_prog_compiler_no_builtin_flag -fno-rtti -fno-exceptions"
++else
++    :
++fi
++
++fi
++
++
++
++
++
++
++  lt_prog_compiler_wl=
++lt_prog_compiler_pic=
++lt_prog_compiler_static=
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $compiler option to produce PIC" >&5
++$as_echo_n "checking for $compiler option to produce PIC... " >&6; }
++
++  if test "$GCC" = yes; then
++    lt_prog_compiler_wl='-Wl,'
++    lt_prog_compiler_static='-static'
++
++    case $host_os in
++      aix*)
++      # All AIX code is PIC.
++      if test "$host_cpu" = ia64; then
++	# AIX 5 now supports IA64 processor
++	lt_prog_compiler_static='-Bstatic'
++      fi
++      ;;
++
++    amigaos*)
++      case $host_cpu in
++      powerpc)
++            # see comment about AmigaOS4 .so support
++            lt_prog_compiler_pic='-fPIC'
++        ;;
++      m68k)
++            # FIXME: we need at least 68020 code to build shared libraries, but
++            # adding the `-m68020' flag to GCC prevents building anything better,
++            # like `-m68040'.
++            lt_prog_compiler_pic='-m68020 -resident32 -malways-restore-a4'
++        ;;
++      esac
++      ;;
++
++    beos* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
++      # PIC is the default for these OSes.
++      ;;
++
++    mingw* | cygwin* | pw32* | os2* | cegcc*)
++      # This hack is so that the source file can tell whether it is being
++      # built for inclusion in a dll (and should export symbols for example).
++      # Although the cygwin gcc ignores -fPIC, still need this for old-style
++      # (--disable-auto-import) libraries
++      lt_prog_compiler_pic='-DDLL_EXPORT'
++      ;;
++
++    darwin* | rhapsody*)
++      # PIC is the default on this platform
++      # Common symbols not allowed in MH_DYLIB files
++      lt_prog_compiler_pic='-fno-common'
++      ;;
++
++    hpux*)
++      # PIC is the default for 64-bit PA HP-UX, but not for 32-bit
++      # PA HP-UX.  On IA64 HP-UX, PIC is the default but the pic flag
++      # sets the default TLS model and affects inlining.
++      case $host_cpu in
++      hppa*64*)
++	# +Z the default
++	;;
++      *)
++	lt_prog_compiler_pic='-fPIC'
++	;;
++      esac
++      ;;
++
++    interix[3-9]*)
++      # Interix 3.x gcc -fpic/-fPIC options generate broken code.
++      # Instead, we relocate shared libraries at runtime.
++      ;;
++
++    msdosdjgpp*)
++      # Just because we use GCC doesn't mean we suddenly get shared libraries
++      # on systems that don't support them.
++      lt_prog_compiler_can_build_shared=no
++      enable_shared=no
++      ;;
++
++    *nto* | *qnx*)
++      # QNX uses GNU C++, but need to define -shared option too, otherwise
++      # it will coredump.
++      lt_prog_compiler_pic='-fPIC -shared'
++      ;;
++
++    sysv4*MP*)
++      if test -d /usr/nec; then
++	lt_prog_compiler_pic=-Kconform_pic
++      fi
++      ;;
++
++    *)
++      lt_prog_compiler_pic='-fPIC'
++      ;;
++    esac
++  else
++    # PORTME Check for flag to pass linker flags through the system compiler.
++    case $host_os in
++    aix*)
++      lt_prog_compiler_wl='-Wl,'
++      if test "$host_cpu" = ia64; then
++	# AIX 5 now supports IA64 processor
++	lt_prog_compiler_static='-Bstatic'
++      else
++	lt_prog_compiler_static='-bnso -bI:/lib/syscalls.exp'
++      fi
++      ;;
++
++    mingw* | cygwin* | pw32* | os2* | cegcc*)
++      # This hack is so that the source file can tell whether it is being
++      # built for inclusion in a dll (and should export symbols for example).
++      lt_prog_compiler_pic='-DDLL_EXPORT'
++      ;;
++
++    hpux9* | hpux10* | hpux11*)
++      lt_prog_compiler_wl='-Wl,'
++      # PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
++      # not for PA HP-UX.
++      case $host_cpu in
++      hppa*64*|ia64*)
++	# +Z the default
++	;;
++      *)
++	lt_prog_compiler_pic='+Z'
++	;;
++      esac
++      # Is there a better lt_prog_compiler_static that works with the bundled CC?
++      lt_prog_compiler_static='${wl}-a ${wl}archive'
++      ;;
++
++    irix5* | irix6* | nonstopux*)
++      lt_prog_compiler_wl='-Wl,'
++      # PIC (with -KPIC) is the default.
++      lt_prog_compiler_static='-non_shared'
++      ;;
++
++    linux* | k*bsd*-gnu | kopensolaris*-gnu)
++      case $cc_basename in
++      # old Intel for x86_64 which still supported -KPIC.
++      ecc*)
++	lt_prog_compiler_wl='-Wl,'
++	lt_prog_compiler_pic='-KPIC'
++	lt_prog_compiler_static='-static'
++        ;;
++      # icc used to be incompatible with GCC.
++      # ICC 10 doesn't accept -KPIC any more.
++      icc* | ifort*)
++	lt_prog_compiler_wl='-Wl,'
++	lt_prog_compiler_pic='-fPIC'
++	lt_prog_compiler_static='-static'
++        ;;
++      # Lahey Fortran 8.1.
++      lf95*)
++	lt_prog_compiler_wl='-Wl,'
++	lt_prog_compiler_pic='--shared'
++	lt_prog_compiler_static='--static'
++	;;
++      pgcc* | pgf77* | pgf90* | pgf95*)
++        # Portland Group compilers (*not* the Pentium gcc compiler,
++	# which looks to be a dead project)
++	lt_prog_compiler_wl='-Wl,'
++	lt_prog_compiler_pic='-fpic'
++	lt_prog_compiler_static='-Bstatic'
++        ;;
++      ccc*)
++        lt_prog_compiler_wl='-Wl,'
++        # All Alpha code is PIC.
++        lt_prog_compiler_static='-non_shared'
++        ;;
++      xl*)
++	# IBM XL C 8.0/Fortran 10.1 on PPC
++	lt_prog_compiler_wl='-Wl,'
++	lt_prog_compiler_pic='-qpic'
++	lt_prog_compiler_static='-qstaticlink'
++	;;
++      *)
++	case `$CC -V 2>&1 | sed 5q` in
++	*Sun\ C*)
++	  # Sun C 5.9
++	  lt_prog_compiler_pic='-KPIC'
++	  lt_prog_compiler_static='-Bstatic'
++	  lt_prog_compiler_wl='-Wl,'
++	  ;;
++	*Sun\ F*)
++	  # Sun Fortran 8.3 passes all unrecognized flags to the linker
++	  lt_prog_compiler_pic='-KPIC'
++	  lt_prog_compiler_static='-Bstatic'
++	  lt_prog_compiler_wl=''
++	  ;;
++	esac
++	;;
++      esac
++      ;;
++
++    newsos6)
++      lt_prog_compiler_pic='-KPIC'
++      lt_prog_compiler_static='-Bstatic'
++      ;;
++
++    *nto* | *qnx*)
++      # QNX uses GNU C++, but need to define -shared option too, otherwise
++      # it will coredump.
++      lt_prog_compiler_pic='-fPIC -shared'
++      ;;
++
++    osf3* | osf4* | osf5*)
++      lt_prog_compiler_wl='-Wl,'
++      # All OSF/1 code is PIC.
++      lt_prog_compiler_static='-non_shared'
++      ;;
++
++    rdos*)
++      lt_prog_compiler_static='-non_shared'
++      ;;
++
++    solaris*)
++      lt_prog_compiler_pic='-KPIC'
++      lt_prog_compiler_static='-Bstatic'
++      case $cc_basename in
++      f77* | f90* | f95*)
++	lt_prog_compiler_wl='-Qoption ld ';;
++      *)
++	lt_prog_compiler_wl='-Wl,';;
++      esac
++      ;;
++
++    sunos4*)
++      lt_prog_compiler_wl='-Qoption ld '
++      lt_prog_compiler_pic='-PIC'
++      lt_prog_compiler_static='-Bstatic'
++      ;;
++
++    sysv4 | sysv4.2uw2* | sysv4.3*)
++      lt_prog_compiler_wl='-Wl,'
++      lt_prog_compiler_pic='-KPIC'
++      lt_prog_compiler_static='-Bstatic'
++      ;;
++
++    sysv4*MP*)
++      if test -d /usr/nec ;then
++	lt_prog_compiler_pic='-Kconform_pic'
++	lt_prog_compiler_static='-Bstatic'
++      fi
++      ;;
++
++    sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
++      lt_prog_compiler_wl='-Wl,'
++      lt_prog_compiler_pic='-KPIC'
++      lt_prog_compiler_static='-Bstatic'
++      ;;
++
++    unicos*)
++      lt_prog_compiler_wl='-Wl,'
++      lt_prog_compiler_can_build_shared=no
++      ;;
++
++    uts4*)
++      lt_prog_compiler_pic='-pic'
++      lt_prog_compiler_static='-Bstatic'
++      ;;
++
++    *)
++      lt_prog_compiler_can_build_shared=no
++      ;;
++    esac
++  fi
++
++case $host_os in
++  # For platforms which do not support PIC, -DPIC is meaningless:
++  *djgpp*)
++    lt_prog_compiler_pic=
++    ;;
++  *)
++    lt_prog_compiler_pic="$lt_prog_compiler_pic -DPIC"
++    ;;
++esac
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_prog_compiler_pic" >&5
++$as_echo "$lt_prog_compiler_pic" >&6; }
++
++
++
++
++
++
++#
++# Check to make sure the PIC flag actually works.
++#
++if test -n "$lt_prog_compiler_pic"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking if $compiler PIC flag $lt_prog_compiler_pic works" >&5
++$as_echo_n "checking if $compiler PIC flag $lt_prog_compiler_pic works... " >&6; }
++if test "${lt_cv_prog_compiler_pic_works+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  lt_cv_prog_compiler_pic_works=no
++   ac_outfile=conftest.$ac_objext
++   echo "$lt_simple_compile_test_code" > conftest.$ac_ext
++   lt_compiler_flag="$lt_prog_compiler_pic -DPIC"
++   # Insert the option either (1) after the last *FLAGS variable, or
++   # (2) before a word containing "conftest.", or (3) at the end.
++   # Note that $ac_compile itself does not contain backslashes and begins
++   # with a dollar sign (not a hyphen), so the echo should work correctly.
++   # The option is referenced via a variable to avoid confusing sed.
++   lt_compile=`echo "$ac_compile" | $SED \
++   -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
++   -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
++   -e 's:$: $lt_compiler_flag:'`
++   (eval echo "\"\$as_me:8147: $lt_compile\"" >&5)
++   (eval "$lt_compile" 2>conftest.err)
++   ac_status=$?
++   cat conftest.err >&5
++   echo "$as_me:8151: \$? = $ac_status" >&5
++   if (exit $ac_status) && test -s "$ac_outfile"; then
++     # The compiler can only warn and ignore the option if not recognized
++     # So say no if there are warnings other than the usual output.
++     $ECHO "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' >conftest.exp
++     $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
++     if test ! -s conftest.er2 || diff conftest.exp conftest.er2 >/dev/null; then
++       lt_cv_prog_compiler_pic_works=yes
++     fi
++   fi
++   $RM conftest*
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_prog_compiler_pic_works" >&5
++$as_echo "$lt_cv_prog_compiler_pic_works" >&6; }
++
++if test x"$lt_cv_prog_compiler_pic_works" = xyes; then
++    case $lt_prog_compiler_pic in
++     "" | " "*) ;;
++     *) lt_prog_compiler_pic=" $lt_prog_compiler_pic" ;;
++     esac
++else
++    lt_prog_compiler_pic=
++     lt_prog_compiler_can_build_shared=no
++fi
++
++fi
++
++
++
++
++
++
++#
++# Check to make sure the static flag actually works.
++#
++wl=$lt_prog_compiler_wl eval lt_tmp_static_flag=\"$lt_prog_compiler_static\"
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if $compiler static flag $lt_tmp_static_flag works" >&5
++$as_echo_n "checking if $compiler static flag $lt_tmp_static_flag works... " >&6; }
++if test "${lt_cv_prog_compiler_static_works+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  lt_cv_prog_compiler_static_works=no
++   save_LDFLAGS="$LDFLAGS"
++   LDFLAGS="$LDFLAGS $lt_tmp_static_flag"
++   echo "$lt_simple_link_test_code" > conftest.$ac_ext
++   if (eval $ac_link 2>conftest.err) && test -s conftest$ac_exeext; then
++     # The linker can only warn and ignore the option if not recognized
++     # So say no if there are warnings
++     if test -s conftest.err; then
++       # Append any errors to the config.log.
++       cat conftest.err 1>&5
++       $ECHO "X$_lt_linker_boilerplate" | $Xsed -e '/^$/d' > conftest.exp
++       $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
++       if diff conftest.exp conftest.er2 >/dev/null; then
++         lt_cv_prog_compiler_static_works=yes
++       fi
++     else
++       lt_cv_prog_compiler_static_works=yes
++     fi
++   fi
++   $RM -r conftest*
++   LDFLAGS="$save_LDFLAGS"
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_prog_compiler_static_works" >&5
++$as_echo "$lt_cv_prog_compiler_static_works" >&6; }
++
++if test x"$lt_cv_prog_compiler_static_works" = xyes; then
++    :
++else
++    lt_prog_compiler_static=
++fi
++
++
++
++
++
++
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking if $compiler supports -c -o file.$ac_objext" >&5
++$as_echo_n "checking if $compiler supports -c -o file.$ac_objext... " >&6; }
++if test "${lt_cv_prog_compiler_c_o+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  lt_cv_prog_compiler_c_o=no
++   $RM -r conftest 2>/dev/null
++   mkdir conftest
++   cd conftest
++   mkdir out
++   echo "$lt_simple_compile_test_code" > conftest.$ac_ext
++
++   lt_compiler_flag="-o out/conftest2.$ac_objext"
++   # Insert the option either (1) after the last *FLAGS variable, or
++   # (2) before a word containing "conftest.", or (3) at the end.
++   # Note that $ac_compile itself does not contain backslashes and begins
++   # with a dollar sign (not a hyphen), so the echo should work correctly.
++   lt_compile=`echo "$ac_compile" | $SED \
++   -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
++   -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
++   -e 's:$: $lt_compiler_flag:'`
++   (eval echo "\"\$as_me:8252: $lt_compile\"" >&5)
++   (eval "$lt_compile" 2>out/conftest.err)
++   ac_status=$?
++   cat out/conftest.err >&5
++   echo "$as_me:8256: \$? = $ac_status" >&5
++   if (exit $ac_status) && test -s out/conftest2.$ac_objext
++   then
++     # The compiler can only warn and ignore the option if not recognized
++     # So say no if there are warnings
++     $ECHO "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' > out/conftest.exp
++     $SED '/^$/d; /^ *+/d' out/conftest.err >out/conftest.er2
++     if test ! -s out/conftest.er2 || diff out/conftest.exp out/conftest.er2 >/dev/null; then
++       lt_cv_prog_compiler_c_o=yes
++     fi
++   fi
++   chmod u+w . 2>&5
++   $RM conftest*
++   # SGI C++ compiler will create directory out/ii_files/ for
++   # template instantiation
++   test -d out/ii_files && $RM out/ii_files/* && rmdir out/ii_files
++   $RM out/* && rmdir out
++   cd ..
++   $RM -r conftest
++   $RM conftest*
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_prog_compiler_c_o" >&5
++$as_echo "$lt_cv_prog_compiler_c_o" >&6; }
++
++
++
++
++
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking if $compiler supports -c -o file.$ac_objext" >&5
++$as_echo_n "checking if $compiler supports -c -o file.$ac_objext... " >&6; }
++if test "${lt_cv_prog_compiler_c_o+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  lt_cv_prog_compiler_c_o=no
++   $RM -r conftest 2>/dev/null
++   mkdir conftest
++   cd conftest
++   mkdir out
++   echo "$lt_simple_compile_test_code" > conftest.$ac_ext
++
++   lt_compiler_flag="-o out/conftest2.$ac_objext"
++   # Insert the option either (1) after the last *FLAGS variable, or
++   # (2) before a word containing "conftest.", or (3) at the end.
++   # Note that $ac_compile itself does not contain backslashes and begins
++   # with a dollar sign (not a hyphen), so the echo should work correctly.
++   lt_compile=`echo "$ac_compile" | $SED \
++   -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
++   -e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
++   -e 's:$: $lt_compiler_flag:'`
++   (eval echo "\"\$as_me:8307: $lt_compile\"" >&5)
++   (eval "$lt_compile" 2>out/conftest.err)
++   ac_status=$?
++   cat out/conftest.err >&5
++   echo "$as_me:8311: \$? = $ac_status" >&5
++   if (exit $ac_status) && test -s out/conftest2.$ac_objext
++   then
++     # The compiler can only warn and ignore the option if not recognized
++     # So say no if there are warnings
++     $ECHO "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' > out/conftest.exp
++     $SED '/^$/d; /^ *+/d' out/conftest.err >out/conftest.er2
++     if test ! -s out/conftest.er2 || diff out/conftest.exp out/conftest.er2 >/dev/null; then
++       lt_cv_prog_compiler_c_o=yes
++     fi
++   fi
++   chmod u+w . 2>&5
++   $RM conftest*
++   # SGI C++ compiler will create directory out/ii_files/ for
++   # template instantiation
++   test -d out/ii_files && $RM out/ii_files/* && rmdir out/ii_files
++   $RM out/* && rmdir out
++   cd ..
++   $RM -r conftest
++   $RM conftest*
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_prog_compiler_c_o" >&5
++$as_echo "$lt_cv_prog_compiler_c_o" >&6; }
++
++
++
++
++hard_links="nottested"
++if test "$lt_cv_prog_compiler_c_o" = no && test "$need_locks" != no; then
++  # do not overwrite the value of need_locks provided by the user
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking if we can lock with hard links" >&5
++$as_echo_n "checking if we can lock with hard links... " >&6; }
++  hard_links=yes
++  $RM conftest*
++  ln conftest.a conftest.b 2>/dev/null && hard_links=no
++  touch conftest.a
++  ln conftest.a conftest.b 2>&5 || hard_links=no
++  ln conftest.a conftest.b 2>/dev/null && hard_links=no
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $hard_links" >&5
++$as_echo "$hard_links" >&6; }
++  if test "$hard_links" = no; then
++    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: \`$CC' does not support \`-c -o', so \`make -j' may be unsafe" >&5
++$as_echo "$as_me: WARNING: \`$CC' does not support \`-c -o', so \`make -j' may be unsafe" >&2;}
++    need_locks=warn
++  fi
++else
++  need_locks=no
++fi
++
++
++
++
++
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the $compiler linker ($LD) supports shared libraries" >&5
++$as_echo_n "checking whether the $compiler linker ($LD) supports shared libraries... " >&6; }
++
++  runpath_var=
++  allow_undefined_flag=
++  always_export_symbols=no
++  archive_cmds=
++  archive_expsym_cmds=
++  compiler_needs_object=no
++  enable_shared_with_static_runtimes=no
++  export_dynamic_flag_spec=
++  export_symbols_cmds='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols'
++  hardcode_automatic=no
++  hardcode_direct=no
++  hardcode_direct_absolute=no
++  hardcode_libdir_flag_spec=
++  hardcode_libdir_flag_spec_ld=
++  hardcode_libdir_separator=
++  hardcode_minus_L=no
++  hardcode_shlibpath_var=unsupported
++  inherit_rpath=no
++  link_all_deplibs=unknown
++  module_cmds=
++  module_expsym_cmds=
++  old_archive_from_new_cmds=
++  old_archive_from_expsyms_cmds=
++  thread_safe_flag_spec=
++  whole_archive_flag_spec=
++  # include_expsyms should be a list of space-separated symbols to be *always*
++  # included in the symbol list
++  include_expsyms=
++  # exclude_expsyms can be an extended regexp of symbols to exclude
++  # it will be wrapped by ` (' and `)$', so one must not match beginning or
++  # end of line.  Example: `a|bc|.*d.*' will exclude the symbols `a' and `bc',
++  # as well as any symbol that contains `d'.
++  exclude_expsyms='_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*'
++  # Although _GLOBAL_OFFSET_TABLE_ is a valid symbol C name, most a.out
++  # platforms (ab)use it in PIC code, but their linkers get confused if
++  # the symbol is explicitly referenced.  Since portable code cannot
++  # rely on this symbol name, it's probably fine to never include it in
++  # preloaded symbol tables.
++  # Exclude shared library initialization/finalization symbols.
++  extract_expsyms_cmds=
++
++  case $host_os in
++  cygwin* | mingw* | pw32* | cegcc*)
++    # FIXME: the MSVC++ port hasn't been tested in a loooong time
++    # When not using gcc, we currently assume that we are using
++    # Microsoft Visual C++.
++    if test "$GCC" != yes; then
++      with_gnu_ld=no
++    fi
++    ;;
++  interix*)
++    # we just hope/assume this is gcc and not c89 (= MSVC++)
++    with_gnu_ld=yes
++    ;;
++  openbsd*)
++    with_gnu_ld=no
++    ;;
++  linux* | k*bsd*-gnu)
++    link_all_deplibs=no
++    ;;
++  esac
++
++  ld_shlibs=yes
++  if test "$with_gnu_ld" = yes; then
++    # If archive_cmds runs LD, not CC, wlarc should be empty
++    wlarc='${wl}'
++
++    # Set some defaults for GNU ld with shared library support. These
++    # are reset later if shared libraries are not supported. Putting them
++    # here allows them to be overridden if necessary.
++    runpath_var=LD_RUN_PATH
++    hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
++    export_dynamic_flag_spec='${wl}--export-dynamic'
++    # ancient GNU ld didn't support --whole-archive et. al.
++    if $LD --help 2>&1 | $GREP 'no-whole-archive' > /dev/null; then
++      whole_archive_flag_spec="$wlarc"'--whole-archive$convenience '"$wlarc"'--no-whole-archive'
++    else
++      whole_archive_flag_spec=
++    fi
++    supports_anon_versioning=no
++    case `$LD -v 2>&1` in
++      *GNU\ gold*) supports_anon_versioning=yes ;;
++      *\ [01].* | *\ 2.[0-9].* | *\ 2.10.*) ;; # catch versions < 2.11
++      *\ 2.11.93.0.2\ *) supports_anon_versioning=yes ;; # RH7.3 ...
++      *\ 2.11.92.0.12\ *) supports_anon_versioning=yes ;; # Mandrake 8.2 ...
++      *\ 2.11.*) ;; # other 2.11 versions
++      *) supports_anon_versioning=yes ;;
++    esac
++
++    # See if GNU ld supports shared libraries.
++    case $host_os in
++    aix[3-9]*)
++      # On AIX/PPC, the GNU linker is very broken
++      if test "$host_cpu" != ia64; then
++	ld_shlibs=no
++	cat <<_LT_EOF 1>&2
++
++*** Warning: the GNU linker, at least up to release 2.9.1, is reported
++*** to be unable to reliably create shared libraries on AIX.
++*** Therefore, libtool is disabling shared libraries support.  If you
++*** really care for shared libraries, you may want to modify your PATH
++*** so that a non-GNU linker is found, and then restart.
++
++_LT_EOF
++      fi
++      ;;
++
++    amigaos*)
++      case $host_cpu in
++      powerpc)
++            # see comment about AmigaOS4 .so support
++            archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++            archive_expsym_cmds=''
++        ;;
++      m68k)
++            archive_cmds='$RM $output_objdir/a2ixlibrary.data~$ECHO "#define NAME $libname" > $output_objdir/a2ixlibrary.data~$ECHO "#define LIBRARY_ID 1" >> $output_objdir/a2ixlibrary.data~$ECHO "#define VERSION $major" >> $output_objdir/a2ixlibrary.data~$ECHO "#define REVISION $revision" >> $output_objdir/a2ixlibrary.data~$AR $AR_FLAGS $lib $libobjs~$RANLIB $lib~(cd $output_objdir && a2ixlibrary -32)'
++            hardcode_libdir_flag_spec='-L$libdir'
++            hardcode_minus_L=yes
++        ;;
++      esac
++      ;;
++
++    beos*)
++      if $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null; then
++	allow_undefined_flag=unsupported
++	# Joseph Beckenbach <jrb3@best.com> says some releases of gcc
++	# support --undefined.  This deserves some investigation.  FIXME
++	archive_cmds='$CC -nostart $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++      else
++	ld_shlibs=no
++      fi
++      ;;
++
++    cygwin* | mingw* | pw32* | cegcc*)
++      # _LT_TAGVAR(hardcode_libdir_flag_spec, ) is actually meaningless,
++      # as there is no search path for DLLs.
++      hardcode_libdir_flag_spec='-L$libdir'
++      allow_undefined_flag=unsupported
++      always_export_symbols=no
++      enable_shared_with_static_runtimes=yes
++      export_symbols_cmds='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[BCDGRS][ ]/s/.*[ ]\([^ ]*\)/\1 DATA/'\'' | $SED -e '\''/^[AITW][ ]/s/.*[ ]//'\'' | sort | uniq > $export_symbols'
++
++      if $LD --help 2>&1 | $GREP 'auto-import' > /dev/null; then
++        archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
++	# If the export-symbols file already is a .def file (1st line
++	# is EXPORTS), use it as is; otherwise, prepend...
++	archive_expsym_cmds='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
++	  cp $export_symbols $output_objdir/$soname.def;
++	else
++	  echo EXPORTS > $output_objdir/$soname.def;
++	  cat $export_symbols >> $output_objdir/$soname.def;
++	fi~
++	$CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
++      else
++	ld_shlibs=no
++      fi
++      ;;
++
++    interix[3-9]*)
++      hardcode_direct=no
++      hardcode_shlibpath_var=no
++      hardcode_libdir_flag_spec='${wl}-rpath,$libdir'
++      export_dynamic_flag_spec='${wl}-E'
++      # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
++      # Instead, shared libraries are loaded at an image base (0x10000000 by
++      # default) and relocated if they conflict, which is a slow very memory
++      # consuming and fragmenting process.  To avoid this, we pick a random,
++      # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
++      # time.  Moving up from 0x10000000 also allows more sbrk(2) space.
++      archive_cmds='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
++      archive_expsym_cmds='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
++      ;;
++
++    gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu)
++      tmp_diet=no
++      if test "$host_os" = linux-dietlibc; then
++	case $cc_basename in
++	  diet\ *) tmp_diet=yes;;	# linux-dietlibc with static linking (!diet-dyn)
++	esac
++      fi
++      if $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null \
++	 && test "$tmp_diet" = no
++      then
++	tmp_addflag=
++	tmp_sharedflag='-shared'
++	case $cc_basename,$host_cpu in
++        pgcc*)				# Portland Group C compiler
++	  whole_archive_flag_spec='${wl}--whole-archive`for conv in $convenience\"\"; do test  -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $ECHO \"$new_convenience\"` ${wl}--no-whole-archive'
++	  tmp_addflag=' $pic_flag'
++	  ;;
++	pgf77* | pgf90* | pgf95*)	# Portland Group f77 and f90 compilers
++	  whole_archive_flag_spec='${wl}--whole-archive`for conv in $convenience\"\"; do test  -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $ECHO \"$new_convenience\"` ${wl}--no-whole-archive'
++	  tmp_addflag=' $pic_flag -Mnomain' ;;
++	ecc*,ia64* | icc*,ia64*)	# Intel C compiler on ia64
++	  tmp_addflag=' -i_dynamic' ;;
++	efc*,ia64* | ifort*,ia64*)	# Intel Fortran compiler on ia64
++	  tmp_addflag=' -i_dynamic -nofor_main' ;;
++	ifc* | ifort*)			# Intel Fortran compiler
++	  tmp_addflag=' -nofor_main' ;;
++	lf95*)				# Lahey Fortran 8.1
++	  whole_archive_flag_spec=
++	  tmp_sharedflag='--shared' ;;
++	xl[cC]*)			# IBM XL C 8.0 on PPC (deal with xlf below)
++	  tmp_sharedflag='-qmkshrobj'
++	  tmp_addflag= ;;
++	esac
++	case `$CC -V 2>&1 | sed 5q` in
++	*Sun\ C*)			# Sun C 5.9
++	  whole_archive_flag_spec='${wl}--whole-archive`new_convenience=; for conv in $convenience\"\"; do test -z \"$conv\" || new_convenience=\"$new_convenience,$conv\"; done; $ECHO \"$new_convenience\"` ${wl}--no-whole-archive'
++	  compiler_needs_object=yes
++	  tmp_sharedflag='-G' ;;
++	*Sun\ F*)			# Sun Fortran 8.3
++	  tmp_sharedflag='-G' ;;
++	esac
++	archive_cmds='$CC '"$tmp_sharedflag""$tmp_addflag"' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++
++        if test "x$supports_anon_versioning" = xyes; then
++          archive_expsym_cmds='echo "{ global:" > $output_objdir/$libname.ver~
++	    cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $output_objdir/$libname.ver~
++	    echo "local: *; };" >> $output_objdir/$libname.ver~
++	    $CC '"$tmp_sharedflag""$tmp_addflag"' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-version-script ${wl}$output_objdir/$libname.ver -o $lib'
++        fi
++
++	case $cc_basename in
++	xlf*)
++	  # IBM XL Fortran 10.1 on PPC cannot create shared libs itself
++	  whole_archive_flag_spec='--whole-archive$convenience --no-whole-archive'
++	  hardcode_libdir_flag_spec=
++	  hardcode_libdir_flag_spec_ld='-rpath $libdir'
++	  archive_cmds='$LD -shared $libobjs $deplibs $compiler_flags -soname $soname -o $lib'
++	  if test "x$supports_anon_versioning" = xyes; then
++	    archive_expsym_cmds='echo "{ global:" > $output_objdir/$libname.ver~
++	      cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $output_objdir/$libname.ver~
++	      echo "local: *; };" >> $output_objdir/$libname.ver~
++	      $LD -shared $libobjs $deplibs $compiler_flags -soname $soname -version-script $output_objdir/$libname.ver -o $lib'
++	  fi
++	  ;;
++	esac
++      else
++        ld_shlibs=no
++      fi
++      ;;
++
++    netbsd* | netbsdelf*-gnu)
++      if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null; then
++	archive_cmds='$LD -Bshareable $libobjs $deplibs $linker_flags -o $lib'
++	wlarc=
++      else
++	archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++	archive_expsym_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
++      fi
++      ;;
++
++    solaris*)
++      if $LD -v 2>&1 | $GREP 'BFD 2\.8' > /dev/null; then
++	ld_shlibs=no
++	cat <<_LT_EOF 1>&2
++
++*** Warning: The releases 2.8.* of the GNU linker cannot reliably
++*** create shared libraries on Solaris systems.  Therefore, libtool
++*** is disabling shared libraries support.  We urge you to upgrade GNU
++*** binutils to release 2.9.1 or newer.  Another option is to modify
++*** your PATH or compiler configuration so that the native linker is
++*** used, and then restart.
++
++_LT_EOF
++      elif $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null; then
++	archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++	archive_expsym_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
++      else
++	ld_shlibs=no
++      fi
++      ;;
++
++    sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX*)
++      case `$LD -v 2>&1` in
++        *\ [01].* | *\ 2.[0-9].* | *\ 2.1[0-5].*)
++	ld_shlibs=no
++	cat <<_LT_EOF 1>&2
++
++*** Warning: Releases of the GNU linker prior to 2.16.91.0.3 can not
++*** reliably create shared libraries on SCO systems.  Therefore, libtool
++*** is disabling shared libraries support.  We urge you to upgrade GNU
++*** binutils to release 2.16.91.0.3 or newer.  Another option is to modify
++*** your PATH or compiler configuration so that the native linker is
++*** used, and then restart.
++
++_LT_EOF
++	;;
++	*)
++	  # For security reasons, it is highly recommended that you always
++	  # use absolute paths for naming shared libraries, and exclude the
++	  # DT_RUNPATH tag from executables and libraries.  But doing so
++	  # requires that you compile everything twice, which is a pain.
++	  if $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null; then
++	    hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
++	    archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++	    archive_expsym_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
++	  else
++	    ld_shlibs=no
++	  fi
++	;;
++      esac
++      ;;
++
++    sunos4*)
++      archive_cmds='$LD -assert pure-text -Bshareable -o $lib $libobjs $deplibs $linker_flags'
++      wlarc=
++      hardcode_direct=yes
++      hardcode_shlibpath_var=no
++      ;;
++
++    *)
++      if $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null; then
++	archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++	archive_expsym_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
++      else
++	ld_shlibs=no
++      fi
++      ;;
++    esac
++
++    if test "$ld_shlibs" = no; then
++      runpath_var=
++      hardcode_libdir_flag_spec=
++      export_dynamic_flag_spec=
++      whole_archive_flag_spec=
++    fi
++  else
++    # PORTME fill in a description of your system's linker (not GNU ld)
++    case $host_os in
++    aix3*)
++      allow_undefined_flag=unsupported
++      always_export_symbols=yes
++      archive_expsym_cmds='$LD -o $output_objdir/$soname $libobjs $deplibs $linker_flags -bE:$export_symbols -T512 -H512 -bM:SRE~$AR $AR_FLAGS $lib $output_objdir/$soname'
++      # Note: this linker hardcodes the directories in LIBPATH if there
++      # are no directories specified by -L.
++      hardcode_minus_L=yes
++      if test "$GCC" = yes && test -z "$lt_prog_compiler_static"; then
++	# Neither direct hardcoding nor static linking is supported with a
++	# broken collect2.
++	hardcode_direct=unsupported
++      fi
++      ;;
++
++    aix[4-9]*)
++      if test "$host_cpu" = ia64; then
++	# On IA64, the linker does run time linking by default, so we don't
++	# have to do anything special.
++	aix_use_runtimelinking=no
++	exp_sym_flag='-Bexport'
++	no_entry_flag=""
++      else
++	# If we're using GNU nm, then we don't want the "-C" option.
++	# -C means demangle to AIX nm, but means don't demangle with GNU nm
++	if $NM -V 2>&1 | $GREP 'GNU' > /dev/null; then
++	  export_symbols_cmds='$NM -Bpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
++	else
++	  export_symbols_cmds='$NM -BCpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
++	fi
++	aix_use_runtimelinking=no
++
++	# Test if we are trying to use run time linking or normal
++	# AIX style linking. If -brtl is somewhere in LDFLAGS, we
++	# need to do runtime linking.
++	case $host_os in aix4.[23]|aix4.[23].*|aix[5-9]*)
++	  for ld_flag in $LDFLAGS; do
++	  if (test $ld_flag = "-brtl" || test $ld_flag = "-Wl,-brtl"); then
++	    aix_use_runtimelinking=yes
++	    break
++	  fi
++	  done
++	  ;;
++	esac
++
++	exp_sym_flag='-bexport'
++	no_entry_flag='-bnoentry'
++      fi
++
++      # When large executables or shared objects are built, AIX ld can
++      # have problems creating the table of contents.  If linking a library
++      # or program results in "error TOC overflow" add -mminimal-toc to
++      # CXXFLAGS/CFLAGS for g++/gcc.  In the cases where that is not
++      # enough to fix the problem, add -Wl,-bbigtoc to LDFLAGS.
++
++      archive_cmds=''
++      hardcode_direct=yes
++      hardcode_direct_absolute=yes
++      hardcode_libdir_separator=':'
++      link_all_deplibs=yes
++      file_list_spec='${wl}-f,'
++
++      if test "$GCC" = yes; then
++	case $host_os in aix4.[012]|aix4.[012].*)
++	# We only want to do this on AIX 4.2 and lower, the check
++	# below for broken collect2 doesn't work under 4.3+
++	  collect2name=`${CC} -print-prog-name=collect2`
++	  if test -f "$collect2name" &&
++	   strings "$collect2name" | $GREP resolve_lib_name >/dev/null
++	  then
++	  # We have reworked collect2
++	  :
++	  else
++	  # We have old collect2
++	  hardcode_direct=unsupported
++	  # It fails to find uninstalled libraries when the uninstalled
++	  # path is not listed in the libpath.  Setting hardcode_minus_L
++	  # to unsupported forces relinking
++	  hardcode_minus_L=yes
++	  hardcode_libdir_flag_spec='-L$libdir'
++	  hardcode_libdir_separator=
++	  fi
++	  ;;
++	esac
++	shared_flag='-shared'
++	if test "$aix_use_runtimelinking" = yes; then
++	  shared_flag="$shared_flag "'${wl}-G'
++	fi
++	link_all_deplibs=no
++      else
++	# not using gcc
++	if test "$host_cpu" = ia64; then
++	# VisualAge C++, Version 5.5 for AIX 5L for IA-64, Beta 3 Release
++	# chokes on -Wl,-G. The following line is correct:
++	  shared_flag='-G'
++	else
++	  if test "$aix_use_runtimelinking" = yes; then
++	    shared_flag='${wl}-G'
++	  else
++	    shared_flag='${wl}-bM:SRE'
++	  fi
++	fi
++      fi
++
++      export_dynamic_flag_spec='${wl}-bexpall'
++      # It seems that -bexpall does not export symbols beginning with
++      # underscore (_), so it is better to generate a list of symbols to export.
++      always_export_symbols=yes
++      if test "$aix_use_runtimelinking" = yes; then
++	# Warning - without using the other runtime loading flags (-brtl),
++	# -berok will link without error, but may produce a broken library.
++	allow_undefined_flag='-berok'
++        # Determine the default libpath from the value encoded in an
++        # empty executable.
++        cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++
++lt_aix_libpath_sed='
++    /Import File Strings/,/^$/ {
++	/^0/ {
++	    s/^0  *\(.*\)$/\1/
++	    p
++	}
++    }'
++aix_libpath=`dump -H conftest$ac_exeext 2>/dev/null | $SED -n -e "$lt_aix_libpath_sed"`
++# Check for a 64-bit object if we didn't find anything.
++if test -z "$aix_libpath"; then
++  aix_libpath=`dump -HX64 conftest$ac_exeext 2>/dev/null | $SED -n -e "$lt_aix_libpath_sed"`
++fi
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
++
++        hardcode_libdir_flag_spec='${wl}-blibpath:$libdir:'"$aix_libpath"
++        archive_expsym_cmds='$CC -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then $ECHO "X${wl}${allow_undefined_flag}" | $Xsed; else :; fi` '"\${wl}$exp_sym_flag:\$export_symbols $shared_flag"
++      else
++	if test "$host_cpu" = ia64; then
++	  hardcode_libdir_flag_spec='${wl}-R $libdir:/usr/lib:/lib'
++	  allow_undefined_flag="-z nodefs"
++	  archive_expsym_cmds="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$exp_sym_flag:\$export_symbols"
++	else
++	 # Determine the default libpath from the value encoded in an
++	 # empty executable.
++	 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++
++lt_aix_libpath_sed='
++    /Import File Strings/,/^$/ {
++	/^0/ {
++	    s/^0  *\(.*\)$/\1/
++	    p
++	}
++    }'
++aix_libpath=`dump -H conftest$ac_exeext 2>/dev/null | $SED -n -e "$lt_aix_libpath_sed"`
++# Check for a 64-bit object if we didn't find anything.
++if test -z "$aix_libpath"; then
++  aix_libpath=`dump -HX64 conftest$ac_exeext 2>/dev/null | $SED -n -e "$lt_aix_libpath_sed"`
++fi
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
++
++	 hardcode_libdir_flag_spec='${wl}-blibpath:$libdir:'"$aix_libpath"
++	  # Warning - without using the other run time loading flags,
++	  # -berok will link without error, but may produce a broken library.
++	  no_undefined_flag=' ${wl}-bernotok'
++	  allow_undefined_flag=' ${wl}-berok'
++	  # Exported symbols can be pulled into shared objects from archives
++	  whole_archive_flag_spec='$convenience'
++	  archive_cmds_need_lc=yes
++	  # This is similar to how AIX traditionally builds its shared libraries.
++	  archive_expsym_cmds="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs ${wl}-bnoentry $compiler_flags ${wl}-bE:$export_symbols${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
++	fi
++      fi
++      ;;
++
++    amigaos*)
++      case $host_cpu in
++      powerpc)
++            # see comment about AmigaOS4 .so support
++            archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
++            archive_expsym_cmds=''
++        ;;
++      m68k)
++            archive_cmds='$RM $output_objdir/a2ixlibrary.data~$ECHO "#define NAME $libname" > $output_objdir/a2ixlibrary.data~$ECHO "#define LIBRARY_ID 1" >> $output_objdir/a2ixlibrary.data~$ECHO "#define VERSION $major" >> $output_objdir/a2ixlibrary.data~$ECHO "#define REVISION $revision" >> $output_objdir/a2ixlibrary.data~$AR $AR_FLAGS $lib $libobjs~$RANLIB $lib~(cd $output_objdir && a2ixlibrary -32)'
++            hardcode_libdir_flag_spec='-L$libdir'
++            hardcode_minus_L=yes
++        ;;
++      esac
++      ;;
++
++    bsdi[45]*)
++      export_dynamic_flag_spec=-rdynamic
++      ;;
++
++    cygwin* | mingw* | pw32* | cegcc*)
++      # When not using gcc, we currently assume that we are using
++      # Microsoft Visual C++.
++      # hardcode_libdir_flag_spec is actually meaningless, as there is
++      # no search path for DLLs.
++      hardcode_libdir_flag_spec=' '
++      allow_undefined_flag=unsupported
++      # Tell ltmain to make .lib files, not .a files.
++      libext=lib
++      # Tell ltmain to make .dll files, not .so files.
++      shrext_cmds=".dll"
++      # FIXME: Setting linknames here is a bad hack.
++      archive_cmds='$CC -o $lib $libobjs $compiler_flags `$ECHO "X$deplibs" | $Xsed -e '\''s/ -lc$//'\''` -link -dll~linknames='
++      # The linker will automatically build a .lib file if we build a DLL.
++      old_archive_from_new_cmds='true'
++      # FIXME: Should let the user specify the lib program.
++      old_archive_cmds='lib -OUT:$oldlib$oldobjs$old_deplibs'
++      fix_srcfile_path='`cygpath -w "$srcfile"`'
++      enable_shared_with_static_runtimes=yes
++      ;;
++
++    darwin* | rhapsody*)
++
++
++  archive_cmds_need_lc=no
++  hardcode_direct=no
++  hardcode_automatic=yes
++  hardcode_shlibpath_var=unsupported
++  whole_archive_flag_spec=''
++  link_all_deplibs=yes
++  allow_undefined_flag="$_lt_dar_allow_undefined"
++  case $cc_basename in
++     ifort*) _lt_dar_can_shared=yes ;;
++     *) _lt_dar_can_shared=$GCC ;;
++  esac
++  if test "$_lt_dar_can_shared" = "yes"; then
++    output_verbose_link_cmd=echo
++    archive_cmds="\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring $_lt_dar_single_mod${_lt_dsymutil}"
++    module_cmds="\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags${_lt_dsymutil}"
++    archive_expsym_cmds="sed 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring ${_lt_dar_single_mod}${_lt_dar_export_syms}${_lt_dsymutil}"
++    module_expsym_cmds="sed -e 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags${_lt_dar_export_syms}${_lt_dsymutil}"
++
++  else
++  ld_shlibs=no
++  fi
++
++      ;;
++
++    dgux*)
++      archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
++      hardcode_libdir_flag_spec='-L$libdir'
++      hardcode_shlibpath_var=no
++      ;;
++
++    freebsd1*)
++      ld_shlibs=no
++      ;;
++
++    # FreeBSD 2.2.[012] allows us to include c++rt0.o to get C++ constructor
++    # support.  Future versions do this automatically, but an explicit c++rt0.o
++    # does not break anything, and helps significantly (at the cost of a little
++    # extra space).
++    freebsd2.2*)
++      archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags /usr/lib/c++rt0.o'
++      hardcode_libdir_flag_spec='-R$libdir'
++      hardcode_direct=yes
++      hardcode_shlibpath_var=no
++      ;;
++
++    # Unfortunately, older versions of FreeBSD 2 do not have this feature.
++    freebsd2*)
++      archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags'
++      hardcode_direct=yes
++      hardcode_minus_L=yes
++      hardcode_shlibpath_var=no
++      ;;
++
++    # FreeBSD 3 and greater uses gcc -shared to do shared libraries.
++    freebsd* | dragonfly*)
++      archive_cmds='$CC -shared -o $lib $libobjs $deplibs $compiler_flags'
++      hardcode_libdir_flag_spec='-R$libdir'
++      hardcode_direct=yes
++      hardcode_shlibpath_var=no
++      ;;
++
++    hpux9*)
++      if test "$GCC" = yes; then
++	archive_cmds='$RM $output_objdir/$soname~$CC -shared -fPIC ${wl}+b ${wl}$install_libdir -o $output_objdir/$soname $libobjs $deplibs $compiler_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
++      else
++	archive_cmds='$RM $output_objdir/$soname~$LD -b +b $install_libdir -o $output_objdir/$soname $libobjs $deplibs $linker_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
++      fi
++      hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
++      hardcode_libdir_separator=:
++      hardcode_direct=yes
++
++      # hardcode_minus_L: Not really in the search PATH,
++      # but as the default location of the library.
++      hardcode_minus_L=yes
++      export_dynamic_flag_spec='${wl}-E'
++      ;;
++
++    hpux10*)
++      if test "$GCC" = yes -a "$with_gnu_ld" = no; then
++	archive_cmds='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
++      else
++	archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
++      fi
++      if test "$with_gnu_ld" = no; then
++	hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
++	hardcode_libdir_flag_spec_ld='+b $libdir'
++	hardcode_libdir_separator=:
++	hardcode_direct=yes
++	hardcode_direct_absolute=yes
++	export_dynamic_flag_spec='${wl}-E'
++	# hardcode_minus_L: Not really in the search PATH,
++	# but as the default location of the library.
++	hardcode_minus_L=yes
++      fi
++      ;;
++
++    hpux11*)
++      if test "$GCC" = yes -a "$with_gnu_ld" = no; then
++	case $host_cpu in
++	hppa*64*)
++	  archive_cmds='$CC -shared ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
++	  ;;
++	ia64*)
++	  archive_cmds='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
++	  ;;
++	*)
++	  archive_cmds='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
++	  ;;
++	esac
++      else
++	case $host_cpu in
++	hppa*64*)
++	  archive_cmds='$CC -b ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
++	  ;;
++	ia64*)
++	  archive_cmds='$CC -b ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
++	  ;;
++	*)
++	  archive_cmds='$CC -b ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
++	  ;;
++	esac
++      fi
++      if test "$with_gnu_ld" = no; then
++	hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
++	hardcode_libdir_separator=:
++
++	case $host_cpu in
++	hppa*64*|ia64*)
++	  hardcode_direct=no
++	  hardcode_shlibpath_var=no
++	  ;;
++	*)
++	  hardcode_direct=yes
++	  hardcode_direct_absolute=yes
++	  export_dynamic_flag_spec='${wl}-E'
++
++	  # hardcode_minus_L: Not really in the search PATH,
++	  # but as the default location of the library.
++	  hardcode_minus_L=yes
++	  ;;
++	esac
++      fi
++      ;;
++
++    irix5* | irix6* | nonstopux*)
++      if test "$GCC" = yes; then
++	archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && $ECHO "X${wl}-set_version ${wl}$verstring" | $Xsed` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
++	# Try to use the -exported_symbol ld option, if it does not
++	# work, assume that -exports_file does not work either and
++	# implicitly export all symbols.
++        save_LDFLAGS="$LDFLAGS"
++        LDFLAGS="$LDFLAGS -shared ${wl}-exported_symbol ${wl}foo ${wl}-update_registry ${wl}/dev/null"
++        cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++int foo(void) {}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  archive_expsym_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && $ECHO "X${wl}-set_version ${wl}$verstring" | $Xsed` ${wl}-update_registry ${wl}${output_objdir}/so_locations ${wl}-exports_file ${wl}$export_symbols -o $lib'
++
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++        LDFLAGS="$save_LDFLAGS"
++      else
++	archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags -soname $soname `test -n "$verstring" && $ECHO "X-set_version $verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -o $lib'
++	archive_expsym_cmds='$CC -shared $libobjs $deplibs $compiler_flags -soname $soname `test -n "$verstring" && $ECHO "X-set_version $verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -exports_file $export_symbols -o $lib'
++      fi
++      archive_cmds_need_lc='no'
++      hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
++      hardcode_libdir_separator=:
++      inherit_rpath=yes
++      link_all_deplibs=yes
++      ;;
++
++    netbsd* | netbsdelf*-gnu)
++      if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null; then
++	archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags'  # a.out
++      else
++	archive_cmds='$LD -shared -o $lib $libobjs $deplibs $linker_flags'      # ELF
++      fi
++      hardcode_libdir_flag_spec='-R$libdir'
++      hardcode_direct=yes
++      hardcode_shlibpath_var=no
++      ;;
++
++    newsos6)
++      archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
++      hardcode_direct=yes
++      hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
++      hardcode_libdir_separator=:
++      hardcode_shlibpath_var=no
++      ;;
++
++    *nto* | *qnx*)
++      ;;
++
++    openbsd*)
++      if test -f /usr/libexec/ld.so; then
++	hardcode_direct=yes
++	hardcode_shlibpath_var=no
++	hardcode_direct_absolute=yes
++	if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
++	  archive_cmds='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags'
++	  archive_expsym_cmds='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-retain-symbols-file,$export_symbols'
++	  hardcode_libdir_flag_spec='${wl}-rpath,$libdir'
++	  export_dynamic_flag_spec='${wl}-E'
++	else
++	  case $host_os in
++	   openbsd[01].* | openbsd2.[0-7] | openbsd2.[0-7].*)
++	     archive_cmds='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags'
++	     hardcode_libdir_flag_spec='-R$libdir'
++	     ;;
++	   *)
++	     archive_cmds='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags'
++	     hardcode_libdir_flag_spec='${wl}-rpath,$libdir'
++	     ;;
++	  esac
++	fi
++      else
++	ld_shlibs=no
++      fi
++      ;;
++
++    os2*)
++      hardcode_libdir_flag_spec='-L$libdir'
++      hardcode_minus_L=yes
++      allow_undefined_flag=unsupported
++      archive_cmds='$ECHO "LIBRARY $libname INITINSTANCE" > $output_objdir/$libname.def~$ECHO "DESCRIPTION \"$libname\"" >> $output_objdir/$libname.def~$ECHO DATA >> $output_objdir/$libname.def~$ECHO " SINGLE NONSHARED" >> $output_objdir/$libname.def~$ECHO EXPORTS >> $output_objdir/$libname.def~emxexp $libobjs >> $output_objdir/$libname.def~$CC -Zdll -Zcrtdll -o $lib $libobjs $deplibs $compiler_flags $output_objdir/$libname.def'
++      old_archive_from_new_cmds='emximp -o $output_objdir/$libname.a $output_objdir/$libname.def'
++      ;;
++
++    osf3*)
++      if test "$GCC" = yes; then
++	allow_undefined_flag=' ${wl}-expect_unresolved ${wl}\*'
++	archive_cmds='$CC -shared${allow_undefined_flag} $libobjs $deplibs $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && $ECHO "X${wl}-set_version ${wl}$verstring" | $Xsed` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
++      else
++	allow_undefined_flag=' -expect_unresolved \*'
++	archive_cmds='$CC -shared${allow_undefined_flag} $libobjs $deplibs $compiler_flags -soname $soname `test -n "$verstring" && $ECHO "X-set_version $verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -o $lib'
++      fi
++      archive_cmds_need_lc='no'
++      hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
++      hardcode_libdir_separator=:
++      ;;
++
++    osf4* | osf5*)	# as osf3* with the addition of -msym flag
++      if test "$GCC" = yes; then
++	allow_undefined_flag=' ${wl}-expect_unresolved ${wl}\*'
++	archive_cmds='$CC -shared${allow_undefined_flag} $libobjs $deplibs $compiler_flags ${wl}-msym ${wl}-soname ${wl}$soname `test -n "$verstring" && $ECHO "X${wl}-set_version ${wl}$verstring" | $Xsed` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
++	hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
++      else
++	allow_undefined_flag=' -expect_unresolved \*'
++	archive_cmds='$CC -shared${allow_undefined_flag} $libobjs $deplibs $compiler_flags -msym -soname $soname `test -n "$verstring" && $ECHO "X-set_version $verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -o $lib'
++	archive_expsym_cmds='for i in `cat $export_symbols`; do printf "%s %s\\n" -exported_symbol "\$i" >> $lib.exp; done; printf "%s\\n" "-hidden">> $lib.exp~
++	$CC -shared${allow_undefined_flag} ${wl}-input ${wl}$lib.exp $compiler_flags $libobjs $deplibs -soname $soname `test -n "$verstring" && $ECHO "X-set_version $verstring" | $Xsed` -update_registry ${output_objdir}/so_locations -o $lib~$RM $lib.exp'
++
++	# Both c and cxx compiler support -rpath directly
++	hardcode_libdir_flag_spec='-rpath $libdir'
++      fi
++      archive_cmds_need_lc='no'
++      hardcode_libdir_separator=:
++      ;;
++
++    solaris*)
++      no_undefined_flag=' -z defs'
++      if test "$GCC" = yes; then
++	wlarc='${wl}'
++	archive_cmds='$CC -shared ${wl}-z ${wl}text ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
++	archive_expsym_cmds='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
++	  $CC -shared ${wl}-z ${wl}text ${wl}-M ${wl}$lib.exp ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp'
++      else
++	case `$CC -V 2>&1` in
++	*"Compilers 5.0"*)
++	  wlarc=''
++	  archive_cmds='$LD -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $linker_flags'
++	  archive_expsym_cmds='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
++	  $LD -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $linker_flags~$RM $lib.exp'
++	  ;;
++	*)
++	  wlarc='${wl}'
++	  archive_cmds='$CC -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $compiler_flags'
++	  archive_expsym_cmds='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
++	  $CC -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp'
++	  ;;
++	esac
++      fi
++      hardcode_libdir_flag_spec='-R$libdir'
++      hardcode_shlibpath_var=no
++      case $host_os in
++      solaris2.[0-5] | solaris2.[0-5].*) ;;
++      *)
++	# The compiler driver will combine and reorder linker options,
++	# but understands `-z linker_flag'.  GCC discards it without `$wl',
++	# but is careful enough not to reorder.
++	# Supported since Solaris 2.6 (maybe 2.5.1?)
++	if test "$GCC" = yes; then
++	  whole_archive_flag_spec='${wl}-z ${wl}allextract$convenience ${wl}-z ${wl}defaultextract'
++	else
++	  whole_archive_flag_spec='-z allextract$convenience -z defaultextract'
++	fi
++	;;
++      esac
++      link_all_deplibs=yes
++      ;;
++
++    sunos4*)
++      if test "x$host_vendor" = xsequent; then
++	# Use $CC to link under sequent, because it throws in some extra .o
++	# files that make .init and .fini sections work.
++	archive_cmds='$CC -G ${wl}-h $soname -o $lib $libobjs $deplibs $compiler_flags'
++      else
++	archive_cmds='$LD -assert pure-text -Bstatic -o $lib $libobjs $deplibs $linker_flags'
++      fi
++      hardcode_libdir_flag_spec='-L$libdir'
++      hardcode_direct=yes
++      hardcode_minus_L=yes
++      hardcode_shlibpath_var=no
++      ;;
++
++    sysv4)
++      case $host_vendor in
++	sni)
++	  archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
++	  hardcode_direct=yes # is this really true???
++	;;
++	siemens)
++	  ## LD is ld it makes a PLAMLIB
++	  ## CC just makes a GrossModule.
++	  archive_cmds='$LD -G -o $lib $libobjs $deplibs $linker_flags'
++	  reload_cmds='$CC -r -o $output$reload_objs'
++	  hardcode_direct=no
++        ;;
++	motorola)
++	  archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
++	  hardcode_direct=no #Motorola manual says yes, but my tests say they lie
++	;;
++      esac
++      runpath_var='LD_RUN_PATH'
++      hardcode_shlibpath_var=no
++      ;;
++
++    sysv4.3*)
++      archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
++      hardcode_shlibpath_var=no
++      export_dynamic_flag_spec='-Bexport'
++      ;;
++
++    sysv4*MP*)
++      if test -d /usr/nec; then
++	archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
++	hardcode_shlibpath_var=no
++	runpath_var=LD_RUN_PATH
++	hardcode_runpath_var=yes
++	ld_shlibs=yes
++      fi
++      ;;
++
++    sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[01].[10]* | unixware7* | sco3.2v5.0.[024]*)
++      no_undefined_flag='${wl}-z,text'
++      archive_cmds_need_lc=no
++      hardcode_shlibpath_var=no
++      runpath_var='LD_RUN_PATH'
++
++      if test "$GCC" = yes; then
++	archive_cmds='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	archive_expsym_cmds='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++      else
++	archive_cmds='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	archive_expsym_cmds='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++      fi
++      ;;
++
++    sysv5* | sco3.2v5* | sco5v6*)
++      # Note: We can NOT use -z defs as we might desire, because we do not
++      # link with -lc, and that would cause any symbols used from libc to
++      # always be unresolved, which means just about no library would
++      # ever link correctly.  If we're not using GNU ld we use -z text
++      # though, which does catch some bad symbols but isn't as heavy-handed
++      # as -z defs.
++      no_undefined_flag='${wl}-z,text'
++      allow_undefined_flag='${wl}-z,nodefs'
++      archive_cmds_need_lc=no
++      hardcode_shlibpath_var=no
++      hardcode_libdir_flag_spec='${wl}-R,$libdir'
++      hardcode_libdir_separator=':'
++      link_all_deplibs=yes
++      export_dynamic_flag_spec='${wl}-Bexport'
++      runpath_var='LD_RUN_PATH'
++
++      if test "$GCC" = yes; then
++	archive_cmds='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	archive_expsym_cmds='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++      else
++	archive_cmds='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++	archive_expsym_cmds='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
++      fi
++      ;;
++
++    uts4*)
++      archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
++      hardcode_libdir_flag_spec='-L$libdir'
++      hardcode_shlibpath_var=no
++      ;;
++
++    *)
++      ld_shlibs=no
++      ;;
++    esac
++
++    if test x$host_vendor = xsni; then
++      case $host in
++      sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
++	export_dynamic_flag_spec='${wl}-Blargedynsym'
++	;;
++      esac
++    fi
++  fi
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ld_shlibs" >&5
++$as_echo "$ld_shlibs" >&6; }
++test "$ld_shlibs" = no && can_build_shared=no
++
++with_gnu_ld=$with_gnu_ld
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++#
++# Do we need to explicitly link libc?
++#
++case "x$archive_cmds_need_lc" in
++x|xyes)
++  # Assume -lc should be added
++  archive_cmds_need_lc=yes
++
++  if test "$enable_shared" = yes && test "$GCC" = yes; then
++    case $archive_cmds in
++    *'~'*)
++      # FIXME: we may have to deal with multi-command sequences.
++      ;;
++    '$CC '*)
++      # Test whether the compiler implicitly links with -lc since on some
++      # systems, -lgcc has to come before -lc. If gcc already passes -lc
++      # to ld, don't add -lc before -lgcc.
++      { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether -lc should be explicitly linked in" >&5
++$as_echo_n "checking whether -lc should be explicitly linked in... " >&6; }
++      $RM conftest*
++      echo "$lt_simple_compile_test_code" > conftest.$ac_ext
++
++      if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_compile\""; } >&5
++  (eval $ac_compile) 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; } 2>conftest.err; then
++        soname=conftest
++        lib=conftest
++        libobjs=conftest.$ac_objext
++        deplibs=
++        wl=$lt_prog_compiler_wl
++	pic_flag=$lt_prog_compiler_pic
++        compiler_flags=-v
++        linker_flags=-v
++        verstring=
++        output_objdir=.
++        libname=conftest
++        lt_save_allow_undefined_flag=$allow_undefined_flag
++        allow_undefined_flag=
++        if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$archive_cmds 2\>\&1 \| $GREP \" -lc \" \>/dev/null 2\>\&1\""; } >&5
++  (eval $archive_cmds 2\>\&1 \| $GREP \" -lc \" \>/dev/null 2\>\&1) 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }
++        then
++	  archive_cmds_need_lc=no
++        else
++	  archive_cmds_need_lc=yes
++        fi
++        allow_undefined_flag=$lt_save_allow_undefined_flag
++      else
++        cat conftest.err 1>&5
++      fi
++      $RM conftest*
++      { $as_echo "$as_me:${as_lineno-$LINENO}: result: $archive_cmds_need_lc" >&5
++$as_echo "$archive_cmds_need_lc" >&6; }
++      ;;
++    esac
++  fi
++  ;;
++esac
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking dynamic linker characteristics" >&5
++$as_echo_n "checking dynamic linker characteristics... " >&6; }
++
++if test "$GCC" = yes; then
++  case $host_os in
++    darwin*) lt_awk_arg="/^libraries:/,/LR/" ;;
++    *) lt_awk_arg="/^libraries:/" ;;
++  esac
++  lt_search_path_spec=`$CC -print-search-dirs | awk $lt_awk_arg | $SED -e "s/^libraries://" -e "s,=/,/,g"`
++  if $ECHO "$lt_search_path_spec" | $GREP ';' >/dev/null ; then
++    # if the path contains ";" then we assume it to be the separator
++    # otherwise default to the standard path separator (i.e. ":") - it is
++    # assumed that no part of a normal pathname contains ";" but that should
++    # okay in the real world where ";" in dirpaths is itself problematic.
++    lt_search_path_spec=`$ECHO "$lt_search_path_spec" | $SED -e 's/;/ /g'`
++  else
++    lt_search_path_spec=`$ECHO "$lt_search_path_spec" | $SED  -e "s/$PATH_SEPARATOR/ /g"`
++  fi
++  # Ok, now we have the path, separated by spaces, we can step through it
++  # and add multilib dir if necessary.
++  lt_tmp_lt_search_path_spec=
++  lt_multi_os_dir=`$CC $CPPFLAGS $CFLAGS $LDFLAGS -print-multi-os-directory 2>/dev/null`
++  for lt_sys_path in $lt_search_path_spec; do
++    if test -d "$lt_sys_path/$lt_multi_os_dir"; then
++      lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path/$lt_multi_os_dir"
++    else
++      test -d "$lt_sys_path" && \
++	lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path"
++    fi
++  done
++  lt_search_path_spec=`$ECHO $lt_tmp_lt_search_path_spec | awk '
++BEGIN {RS=" "; FS="/|\n";} {
++  lt_foo="";
++  lt_count=0;
++  for (lt_i = NF; lt_i > 0; lt_i--) {
++    if ($lt_i != "" && $lt_i != ".") {
++      if ($lt_i == "..") {
++        lt_count++;
++      } else {
++        if (lt_count == 0) {
++          lt_foo="/" $lt_i lt_foo;
++        } else {
++          lt_count--;
++        }
++      }
++    }
++  }
++  if (lt_foo != "") { lt_freq[lt_foo]++; }
++  if (lt_freq[lt_foo] == 1) { print lt_foo; }
++}'`
++  sys_lib_search_path_spec=`$ECHO $lt_search_path_spec`
++else
++  sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
++fi
++library_names_spec=
++libname_spec='lib$name'
++soname_spec=
++shrext_cmds=".so"
++postinstall_cmds=
++postuninstall_cmds=
++finish_cmds=
++finish_eval=
++shlibpath_var=
++shlibpath_overrides_runpath=unknown
++version_type=none
++dynamic_linker="$host_os ld.so"
++sys_lib_dlsearch_path_spec="/lib /usr/lib"
++need_lib_prefix=unknown
++hardcode_into_libs=no
++
++# when you set need_version to no, make sure it does not cause -set_version
++# flags to be left without arguments
++need_version=unknown
++
++case $host_os in
++aix3*)
++  version_type=linux
++  library_names_spec='${libname}${release}${shared_ext}$versuffix $libname.a'
++  shlibpath_var=LIBPATH
++
++  # AIX 3 has no versioning support, so we append a major version to the name.
++  soname_spec='${libname}${release}${shared_ext}$major'
++  ;;
++
++aix[4-9]*)
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  hardcode_into_libs=yes
++  if test "$host_cpu" = ia64; then
++    # AIX 5 supports IA64
++    library_names_spec='${libname}${release}${shared_ext}$major ${libname}${release}${shared_ext}$versuffix $libname${shared_ext}'
++    shlibpath_var=LD_LIBRARY_PATH
++  else
++    # With GCC up to 2.95.x, collect2 would create an import file
++    # for dependence libraries.  The import file would start with
++    # the line `#! .'.  This would cause the generated library to
++    # depend on `.', always an invalid library.  This was fixed in
++    # development snapshots of GCC prior to 3.0.
++    case $host_os in
++      aix4 | aix4.[01] | aix4.[01].*)
++      if { echo '#if __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 97)'
++	   echo ' yes '
++	   echo '#endif'; } | ${CC} -E - | $GREP yes > /dev/null; then
++	:
++      else
++	can_build_shared=no
++      fi
++      ;;
++    esac
++    # AIX (on Power*) has no versioning support, so currently we can not hardcode correct
++    # soname into executable. Probably we can add versioning support to
++    # collect2, so additional links can be useful in future.
++    if test "$aix_use_runtimelinking" = yes; then
++      # If using run time linking (on AIX 4.2 or later) use lib<name>.so
++      # instead of lib<name>.a to let people know that these are not
++      # typical AIX shared libraries.
++      library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++    else
++      # We preserve .a as extension for shared libraries through AIX4.2
++      # and later when we are not doing run time linking.
++      library_names_spec='${libname}${release}.a $libname.a'
++      soname_spec='${libname}${release}${shared_ext}$major'
++    fi
++    shlibpath_var=LIBPATH
++  fi
++  ;;
++
++amigaos*)
++  case $host_cpu in
++  powerpc)
++    # Since July 2007 AmigaOS4 officially supports .so libraries.
++    # When compiling the executable, add -use-dynld -Lsobjs: to the compileline.
++    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++    ;;
++  m68k)
++    library_names_spec='$libname.ixlibrary $libname.a'
++    # Create ${libname}_ixlibrary.a entries in /sys/libs.
++    finish_eval='for lib in `ls $libdir/*.ixlibrary 2>/dev/null`; do libname=`$ECHO "X$lib" | $Xsed -e '\''s%^.*/\([^/]*\)\.ixlibrary$%\1%'\''`; test $RM /sys/libs/${libname}_ixlibrary.a; $show "cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a"; cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a || exit 1; done'
++    ;;
++  esac
++  ;;
++
++beos*)
++  library_names_spec='${libname}${shared_ext}'
++  dynamic_linker="$host_os ld.so"
++  shlibpath_var=LIBRARY_PATH
++  ;;
++
++bsdi[45]*)
++  version_type=linux
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  finish_cmds='PATH="\$PATH:/sbin" ldconfig $libdir'
++  shlibpath_var=LD_LIBRARY_PATH
++  sys_lib_search_path_spec="/shlib /usr/lib /usr/X11/lib /usr/contrib/lib /lib /usr/local/lib"
++  sys_lib_dlsearch_path_spec="/shlib /usr/lib /usr/local/lib"
++  # the default ld.so.conf also contains /usr/contrib/lib and
++  # /usr/X11R6/lib (/usr/X11 is a link to /usr/X11R6), but let us allow
++  # libtool to hard-code these into programs
++  ;;
++
++cygwin* | mingw* | pw32* | cegcc*)
++  version_type=windows
++  shrext_cmds=".dll"
++  need_version=no
++  need_lib_prefix=no
++
++  case $GCC,$host_os in
++  yes,cygwin* | yes,mingw* | yes,pw32* | yes,cegcc*)
++    library_names_spec='$libname.dll.a'
++    # DLL is installed to $(libdir)/../bin by postinstall_cmds
++    postinstall_cmds='base_file=`basename \${file}`~
++      dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i; echo \$dlname'\''`~
++      dldir=$destdir/`dirname \$dlpath`~
++      test -d \$dldir || mkdir -p \$dldir~
++      $install_prog $dir/$dlname \$dldir/$dlname~
++      chmod a+x \$dldir/$dlname~
++      if test -n '\''$stripme'\'' && test -n '\''$striplib'\''; then
++        eval '\''$striplib \$dldir/$dlname'\'' || exit \$?;
++      fi'
++    postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; echo \$dlname'\''`~
++      dlpath=$dir/\$dldll~
++       $RM \$dlpath'
++    shlibpath_overrides_runpath=yes
++
++    case $host_os in
++    cygwin*)
++      # Cygwin DLLs use 'cyg' prefix rather than 'lib'
++      soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} | $SED -e 's/[.]/-/g'`${versuffix}${shared_ext}'
++      sys_lib_search_path_spec="/usr/lib /lib/w32api /lib /usr/local/lib"
++      ;;
++    mingw* | cegcc*)
++      # MinGW DLLs use traditional 'lib' prefix
++      soname_spec='${libname}`echo ${release} | $SED -e 's/[.]/-/g'`${versuffix}${shared_ext}'
++      sys_lib_search_path_spec=`$CC -print-search-dirs | $GREP "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"`
++      if $ECHO "$sys_lib_search_path_spec" | $GREP ';[c-zC-Z]:/' >/dev/null; then
++        # It is most probably a Windows format PATH printed by
++        # mingw gcc, but we are running on Cygwin. Gcc prints its search
++        # path with ; separators, and with drive letters. We can handle the
++        # drive letters (cygwin fileutils understands them), so leave them,
++        # especially as we might pass files found there to a mingw objdump,
++        # which wouldn't understand a cygwinified path. Ahh.
++        sys_lib_search_path_spec=`$ECHO "$sys_lib_search_path_spec" | $SED -e 's/;/ /g'`
++      else
++        sys_lib_search_path_spec=`$ECHO "$sys_lib_search_path_spec" | $SED  -e "s/$PATH_SEPARATOR/ /g"`
++      fi
++      ;;
++    pw32*)
++      # pw32 DLLs use 'pw' prefix rather than 'lib'
++      library_names_spec='`echo ${libname} | sed -e 's/^lib/pw/'``echo ${release} | $SED -e 's/[.]/-/g'`${versuffix}${shared_ext}'
++      ;;
++    esac
++    ;;
++
++  *)
++    library_names_spec='${libname}`echo ${release} | $SED -e 's/[.]/-/g'`${versuffix}${shared_ext} $libname.lib'
++    ;;
++  esac
++  dynamic_linker='Win32 ld.exe'
++  # FIXME: first we should search . and the directory the executable is in
++  shlibpath_var=PATH
++  ;;
++
++darwin* | rhapsody*)
++  dynamic_linker="$host_os dyld"
++  version_type=darwin
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${major}$shared_ext ${libname}$shared_ext'
++  soname_spec='${libname}${release}${major}$shared_ext'
++  shlibpath_overrides_runpath=yes
++  shlibpath_var=DYLD_LIBRARY_PATH
++  shrext_cmds='`test .$module = .yes && echo .so || echo .dylib`'
++
++  sys_lib_search_path_spec="$sys_lib_search_path_spec /usr/local/lib"
++  sys_lib_dlsearch_path_spec='/usr/local/lib /lib /usr/lib'
++  ;;
++
++dgux*)
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname$shared_ext'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  ;;
++
++freebsd1*)
++  dynamic_linker=no
++  ;;
++
++freebsd* | dragonfly*)
++  # DragonFly does not have aout.  When/if they implement a new
++  # versioning mechanism, adjust this.
++  if test -x /usr/bin/objformat; then
++    objformat=`/usr/bin/objformat`
++  else
++    case $host_os in
++    freebsd[123]*) objformat=aout ;;
++    *) objformat=elf ;;
++    esac
++  fi
++  version_type=freebsd-$objformat
++  case $version_type in
++    freebsd-elf*)
++      library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext} $libname${shared_ext}'
++      need_version=no
++      need_lib_prefix=no
++      ;;
++    freebsd-*)
++      library_names_spec='${libname}${release}${shared_ext}$versuffix $libname${shared_ext}$versuffix'
++      need_version=yes
++      ;;
++  esac
++  shlibpath_var=LD_LIBRARY_PATH
++  case $host_os in
++  freebsd2*)
++    shlibpath_overrides_runpath=yes
++    ;;
++  freebsd3.[01]* | freebsdelf3.[01]*)
++    shlibpath_overrides_runpath=yes
++    hardcode_into_libs=yes
++    ;;
++  freebsd3.[2-9]* | freebsdelf3.[2-9]* | \
++  freebsd4.[0-5] | freebsdelf4.[0-5] | freebsd4.1.1 | freebsdelf4.1.1)
++    shlibpath_overrides_runpath=no
++    hardcode_into_libs=yes
++    ;;
++  *) # from 4.6 on, and DragonFly
++    shlibpath_overrides_runpath=yes
++    hardcode_into_libs=yes
++    ;;
++  esac
++  ;;
++
++gnu*)
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  hardcode_into_libs=yes
++  ;;
++
++hpux9* | hpux10* | hpux11*)
++  # Give a soname corresponding to the major version so that dld.sl refuses to
++  # link against other versions.
++  version_type=sunos
++  need_lib_prefix=no
++  need_version=no
++  case $host_cpu in
++  ia64*)
++    shrext_cmds='.so'
++    hardcode_into_libs=yes
++    dynamic_linker="$host_os dld.so"
++    shlibpath_var=LD_LIBRARY_PATH
++    shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
++    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++    soname_spec='${libname}${release}${shared_ext}$major'
++    if test "X$HPUX_IA64_MODE" = X32; then
++      sys_lib_search_path_spec="/usr/lib/hpux32 /usr/local/lib/hpux32 /usr/local/lib"
++    else
++      sys_lib_search_path_spec="/usr/lib/hpux64 /usr/local/lib/hpux64"
++    fi
++    sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
++    ;;
++  hppa*64*)
++    shrext_cmds='.sl'
++    hardcode_into_libs=yes
++    dynamic_linker="$host_os dld.sl"
++    shlibpath_var=LD_LIBRARY_PATH # How should we handle SHLIB_PATH
++    shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
++    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++    soname_spec='${libname}${release}${shared_ext}$major'
++    sys_lib_search_path_spec="/usr/lib/pa20_64 /usr/ccs/lib/pa20_64"
++    sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
++    ;;
++  *)
++    shrext_cmds='.sl'
++    dynamic_linker="$host_os dld.sl"
++    shlibpath_var=SHLIB_PATH
++    shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
++    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++    soname_spec='${libname}${release}${shared_ext}$major'
++    ;;
++  esac
++  # HP-UX runs *really* slowly unless shared libraries are mode 555.
++  postinstall_cmds='chmod 555 $lib'
++  ;;
++
++interix[3-9]*)
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  dynamic_linker='Interix 3.x ld.so.1 (PE, like ELF)'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=no
++  hardcode_into_libs=yes
++  ;;
++
++irix5* | irix6* | nonstopux*)
++  case $host_os in
++    nonstopux*) version_type=nonstopux ;;
++    *)
++	if test "$lt_cv_prog_gnu_ld" = yes; then
++		version_type=linux
++	else
++		version_type=irix
++	fi ;;
++  esac
++  need_lib_prefix=no
++  need_version=no
++  soname_spec='${libname}${release}${shared_ext}$major'
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${release}${shared_ext} $libname${shared_ext}'
++  case $host_os in
++  irix5* | nonstopux*)
++    libsuff= shlibsuff=
++    ;;
++  *)
++    case $LD in # libtool.m4 will add one of these switches to LD
++    *-32|*"-32 "|*-melf32bsmip|*"-melf32bsmip ")
++      libsuff= shlibsuff= libmagic=32-bit;;
++    *-n32|*"-n32 "|*-melf32bmipn32|*"-melf32bmipn32 ")
++      libsuff=32 shlibsuff=N32 libmagic=N32;;
++    *-64|*"-64 "|*-melf64bmip|*"-melf64bmip ")
++      libsuff=64 shlibsuff=64 libmagic=64-bit;;
++    *) libsuff= shlibsuff= libmagic=never-match;;
++    esac
++    ;;
++  esac
++  shlibpath_var=LD_LIBRARY${shlibsuff}_PATH
++  shlibpath_overrides_runpath=no
++  sys_lib_search_path_spec="/usr/lib${libsuff} /lib${libsuff} /usr/local/lib${libsuff}"
++  sys_lib_dlsearch_path_spec="/usr/lib${libsuff} /lib${libsuff}"
++  hardcode_into_libs=yes
++  ;;
++
++# No shared lib support for Linux oldld, aout, or coff.
++linux*oldld* | linux*aout* | linux*coff*)
++  dynamic_linker=no
++  ;;
++
++# This must be Linux ELF.
++linux* | k*bsd*-gnu | kopensolaris*-gnu)
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=no
++  # Some binutils ld are patched to set DT_RUNPATH
++  save_LDFLAGS=$LDFLAGS
++  save_libdir=$libdir
++  eval "libdir=/foo; wl=\"$lt_prog_compiler_wl\"; \
++       LDFLAGS=\"\$LDFLAGS $hardcode_libdir_flag_spec\""
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  if  ($OBJDUMP -p conftest$ac_exeext) 2>/dev/null | grep "RUNPATH.*$libdir" >/dev/null; then :
++  shlibpath_overrides_runpath=yes
++fi
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++  LDFLAGS=$save_LDFLAGS
++  libdir=$save_libdir
++
++  # This implies no fast_install, which is unacceptable.
++  # Some rework will be needed to allow for fast_install
++  # before this can be enabled.
++  hardcode_into_libs=yes
++
++  # Append ld.so.conf contents to the search path
++  if test -f /etc/ld.so.conf; then
++    lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s 2>/dev/null", \$2)); skip = 1; } { if (!skip) print \$0; skip = 0; }' < /etc/ld.so.conf | $SED -e 's/#.*//;/^[	 ]*hwcap[	 ]/d;s/[:,	]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d' | tr '\n' ' '`
++    sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
++  fi
++
++  # We used to test for /lib/ld.so.1 and disable shared libraries on
++  # powerpc, because MkLinux only supported shared libraries with the
++  # GNU dynamic linker.  Since this was broken with cross compilers,
++  # most powerpc-linux boxes support dynamic linking these days and
++  # people can always --disable-shared, the test was removed, and we
++  # assume the GNU/Linux dynamic linker is in use.
++  dynamic_linker='GNU/Linux ld.so'
++  ;;
++
++netbsdelf*-gnu)
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=no
++  hardcode_into_libs=yes
++  dynamic_linker='NetBSD ld.elf_so'
++  ;;
++
++netbsd*)
++  version_type=sunos
++  need_lib_prefix=no
++  need_version=no
++  if echo __ELF__ | $CC -E - | $GREP __ELF__ >/dev/null; then
++    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
++    finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
++    dynamic_linker='NetBSD (a.out) ld.so'
++  else
++    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
++    soname_spec='${libname}${release}${shared_ext}$major'
++    dynamic_linker='NetBSD ld.elf_so'
++  fi
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=yes
++  hardcode_into_libs=yes
++  ;;
++
++newsos6)
++  version_type=linux
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=yes
++  ;;
++
++*nto* | *qnx*)
++  version_type=qnx
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=no
++  hardcode_into_libs=yes
++  dynamic_linker='ldqnx.so'
++  ;;
++
++openbsd*)
++  version_type=sunos
++  sys_lib_dlsearch_path_spec="/usr/lib"
++  need_lib_prefix=no
++  # Some older versions of OpenBSD (3.3 at least) *do* need versioned libs.
++  case $host_os in
++    openbsd3.3 | openbsd3.3.*)	need_version=yes ;;
++    *)				need_version=no  ;;
++  esac
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
++  finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
++  shlibpath_var=LD_LIBRARY_PATH
++  if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
++    case $host_os in
++      openbsd2.[89] | openbsd2.[89].*)
++	shlibpath_overrides_runpath=no
++	;;
++      *)
++	shlibpath_overrides_runpath=yes
++	;;
++      esac
++  else
++    shlibpath_overrides_runpath=yes
++  fi
++  ;;
++
++os2*)
++  libname_spec='$name'
++  shrext_cmds=".dll"
++  need_lib_prefix=no
++  library_names_spec='$libname${shared_ext} $libname.a'
++  dynamic_linker='OS/2 ld.exe'
++  shlibpath_var=LIBPATH
++  ;;
++
++osf3* | osf4* | osf5*)
++  version_type=osf
++  need_lib_prefix=no
++  need_version=no
++  soname_spec='${libname}${release}${shared_ext}$major'
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  shlibpath_var=LD_LIBRARY_PATH
++  sys_lib_search_path_spec="/usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc /usr/lib /usr/local/lib /var/shlib"
++  sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
++  ;;
++
++rdos*)
++  dynamic_linker=no
++  ;;
++
++solaris*)
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=yes
++  hardcode_into_libs=yes
++  # ldd complains unless libraries are executable
++  postinstall_cmds='chmod +x $lib'
++  ;;
++
++sunos4*)
++  version_type=sunos
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
++  finish_cmds='PATH="\$PATH:/usr/etc" ldconfig $libdir'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=yes
++  if test "$with_gnu_ld" = yes; then
++    need_lib_prefix=no
++  fi
++  need_version=yes
++  ;;
++
++sysv4 | sysv4.3*)
++  version_type=linux
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  case $host_vendor in
++    sni)
++      shlibpath_overrides_runpath=no
++      need_lib_prefix=no
++      runpath_var=LD_RUN_PATH
++      ;;
++    siemens)
++      need_lib_prefix=no
++      ;;
++    motorola)
++      need_lib_prefix=no
++      need_version=no
++      shlibpath_overrides_runpath=no
++      sys_lib_search_path_spec='/lib /usr/lib /usr/ccs/lib'
++      ;;
++  esac
++  ;;
++
++sysv4*MP*)
++  if test -d /usr/nec ;then
++    version_type=linux
++    library_names_spec='$libname${shared_ext}.$versuffix $libname${shared_ext}.$major $libname${shared_ext}'
++    soname_spec='$libname${shared_ext}.$major'
++    shlibpath_var=LD_LIBRARY_PATH
++  fi
++  ;;
++
++sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
++  version_type=freebsd-elf
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext} $libname${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=yes
++  hardcode_into_libs=yes
++  if test "$with_gnu_ld" = yes; then
++    sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib /usr/lib /lib'
++  else
++    sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
++    case $host_os in
++      sco3.2v5*)
++        sys_lib_search_path_spec="$sys_lib_search_path_spec /lib"
++	;;
++    esac
++  fi
++  sys_lib_dlsearch_path_spec='/usr/lib'
++  ;;
++
++tpf*)
++  # TPF is a cross-target only.  Preferred cross-host = GNU/Linux.
++  version_type=linux
++  need_lib_prefix=no
++  need_version=no
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  shlibpath_var=LD_LIBRARY_PATH
++  shlibpath_overrides_runpath=no
++  hardcode_into_libs=yes
++  ;;
++
++uts4*)
++  version_type=linux
++  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
++  soname_spec='${libname}${release}${shared_ext}$major'
++  shlibpath_var=LD_LIBRARY_PATH
++  ;;
++
++*)
++  dynamic_linker=no
++  ;;
++esac
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $dynamic_linker" >&5
++$as_echo "$dynamic_linker" >&6; }
++test "$dynamic_linker" = no && can_build_shared=no
++
++variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
++if test "$GCC" = yes; then
++  variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
++fi
++
++if test "${lt_cv_sys_lib_search_path_spec+set}" = set; then
++  sys_lib_search_path_spec="$lt_cv_sys_lib_search_path_spec"
++fi
++if test "${lt_cv_sys_lib_dlsearch_path_spec+set}" = set; then
++  sys_lib_dlsearch_path_spec="$lt_cv_sys_lib_dlsearch_path_spec"
++fi
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking how to hardcode library paths into programs" >&5
++$as_echo_n "checking how to hardcode library paths into programs... " >&6; }
++hardcode_action=
++if test -n "$hardcode_libdir_flag_spec" ||
++   test -n "$runpath_var" ||
++   test "X$hardcode_automatic" = "Xyes" ; then
++
++  # We can hardcode non-existent directories.
++  if test "$hardcode_direct" != no &&
++     # If the only mechanism to avoid hardcoding is shlibpath_var, we
++     # have to relink, otherwise we might link with an installed library
++     # when we should be linking with a yet-to-be-installed one
++     ## test "$_LT_TAGVAR(hardcode_shlibpath_var, )" != no &&
++     test "$hardcode_minus_L" != no; then
++    # Linking always hardcodes the temporary library directory.
++    hardcode_action=relink
++  else
++    # We can link without hardcoding, and we can hardcode nonexisting dirs.
++    hardcode_action=immediate
++  fi
++else
++  # We cannot hardcode anything, or else we can only hardcode existing
++  # directories.
++  hardcode_action=unsupported
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $hardcode_action" >&5
++$as_echo "$hardcode_action" >&6; }
++
++if test "$hardcode_action" = relink ||
++   test "$inherit_rpath" = yes; then
++  # Fast installation is not supported
++  enable_fast_install=no
++elif test "$shlibpath_overrides_runpath" = yes ||
++     test "$enable_shared" = no; then
++  # Fast installation is not necessary
++  enable_fast_install=needless
++fi
++
++
++
++
++
++
++  if test "x$enable_dlopen" != xyes; then
++  enable_dlopen=unknown
++  enable_dlopen_self=unknown
++  enable_dlopen_self_static=unknown
++else
++  lt_cv_dlopen=no
++  lt_cv_dlopen_libs=
++
++  case $host_os in
++  beos*)
++    lt_cv_dlopen="load_add_on"
++    lt_cv_dlopen_libs=
++    lt_cv_dlopen_self=yes
++    ;;
++
++  mingw* | pw32* | cegcc*)
++    lt_cv_dlopen="LoadLibrary"
++    lt_cv_dlopen_libs=
++    ;;
++
++  cygwin*)
++    lt_cv_dlopen="dlopen"
++    lt_cv_dlopen_libs=
++    ;;
++
++  darwin*)
++  # if libdl is installed we need to link against it
++    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for dlopen in -ldl" >&5
++$as_echo_n "checking for dlopen in -ldl... " >&6; }
++if test "${ac_cv_lib_dl_dlopen+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_check_lib_save_LIBS=$LIBS
++LIBS="-ldl  $LIBS"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char dlopen ();
++int
++main ()
++{
++return dlopen ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_dl_dlopen=yes
++else
++  ac_cv_lib_dl_dlopen=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++LIBS=$ac_check_lib_save_LIBS
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_dl_dlopen" >&5
++$as_echo "$ac_cv_lib_dl_dlopen" >&6; }
++if test "x$ac_cv_lib_dl_dlopen" = x""yes; then :
++  lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-ldl"
++else
++
++    lt_cv_dlopen="dyld"
++    lt_cv_dlopen_libs=
++    lt_cv_dlopen_self=yes
++
++fi
++
++    ;;
++
++  *)
++    ac_fn_c_check_func "$LINENO" "shl_load" "ac_cv_func_shl_load"
++if test "x$ac_cv_func_shl_load" = x""yes; then :
++  lt_cv_dlopen="shl_load"
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for shl_load in -ldld" >&5
++$as_echo_n "checking for shl_load in -ldld... " >&6; }
++if test "${ac_cv_lib_dld_shl_load+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_check_lib_save_LIBS=$LIBS
++LIBS="-ldld  $LIBS"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char shl_load ();
++int
++main ()
++{
++return shl_load ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_dld_shl_load=yes
++else
++  ac_cv_lib_dld_shl_load=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++LIBS=$ac_check_lib_save_LIBS
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_dld_shl_load" >&5
++$as_echo "$ac_cv_lib_dld_shl_load" >&6; }
++if test "x$ac_cv_lib_dld_shl_load" = x""yes; then :
++  lt_cv_dlopen="shl_load" lt_cv_dlopen_libs="-ldld"
++else
++  ac_fn_c_check_func "$LINENO" "dlopen" "ac_cv_func_dlopen"
++if test "x$ac_cv_func_dlopen" = x""yes; then :
++  lt_cv_dlopen="dlopen"
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for dlopen in -ldl" >&5
++$as_echo_n "checking for dlopen in -ldl... " >&6; }
++if test "${ac_cv_lib_dl_dlopen+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_check_lib_save_LIBS=$LIBS
++LIBS="-ldl  $LIBS"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char dlopen ();
++int
++main ()
++{
++return dlopen ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_dl_dlopen=yes
++else
++  ac_cv_lib_dl_dlopen=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++LIBS=$ac_check_lib_save_LIBS
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_dl_dlopen" >&5
++$as_echo "$ac_cv_lib_dl_dlopen" >&6; }
++if test "x$ac_cv_lib_dl_dlopen" = x""yes; then :
++  lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-ldl"
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for dlopen in -lsvld" >&5
++$as_echo_n "checking for dlopen in -lsvld... " >&6; }
++if test "${ac_cv_lib_svld_dlopen+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_check_lib_save_LIBS=$LIBS
++LIBS="-lsvld  $LIBS"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char dlopen ();
++int
++main ()
++{
++return dlopen ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_svld_dlopen=yes
++else
++  ac_cv_lib_svld_dlopen=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++LIBS=$ac_check_lib_save_LIBS
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_svld_dlopen" >&5
++$as_echo "$ac_cv_lib_svld_dlopen" >&6; }
++if test "x$ac_cv_lib_svld_dlopen" = x""yes; then :
++  lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-lsvld"
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for dld_link in -ldld" >&5
++$as_echo_n "checking for dld_link in -ldld... " >&6; }
++if test "${ac_cv_lib_dld_dld_link+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_check_lib_save_LIBS=$LIBS
++LIBS="-ldld  $LIBS"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char dld_link ();
++int
++main ()
++{
++return dld_link ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_dld_dld_link=yes
++else
++  ac_cv_lib_dld_dld_link=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++LIBS=$ac_check_lib_save_LIBS
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_dld_dld_link" >&5
++$as_echo "$ac_cv_lib_dld_dld_link" >&6; }
++if test "x$ac_cv_lib_dld_dld_link" = x""yes; then :
++  lt_cv_dlopen="dld_link" lt_cv_dlopen_libs="-ldld"
++fi
++
++
++fi
++
++
++fi
++
++
++fi
++
++
++fi
++
++
++fi
++
++    ;;
++  esac
++
++  if test "x$lt_cv_dlopen" != xno; then
++    enable_dlopen=yes
++  else
++    enable_dlopen=no
++  fi
++
++  case $lt_cv_dlopen in
++  dlopen)
++    save_CPPFLAGS="$CPPFLAGS"
++    test "x$ac_cv_header_dlfcn_h" = xyes && CPPFLAGS="$CPPFLAGS -DHAVE_DLFCN_H"
++
++    save_LDFLAGS="$LDFLAGS"
++    wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
++
++    save_LIBS="$LIBS"
++    LIBS="$lt_cv_dlopen_libs $LIBS"
++
++    { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether a program can dlopen itself" >&5
++$as_echo_n "checking whether a program can dlopen itself... " >&6; }
++if test "${lt_cv_dlopen_self+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  	  if test "$cross_compiling" = yes; then :
++  lt_cv_dlopen_self=cross
++else
++  lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
++  lt_status=$lt_dlunknown
++  cat > conftest.$ac_ext <<_LT_EOF
++#line 10691 "configure"
++#include "confdefs.h"
++
++#if HAVE_DLFCN_H
++#include <dlfcn.h>
++#endif
++
++#include <stdio.h>
++
++#ifdef RTLD_GLOBAL
++#  define LT_DLGLOBAL		RTLD_GLOBAL
++#else
++#  ifdef DL_GLOBAL
++#    define LT_DLGLOBAL		DL_GLOBAL
++#  else
++#    define LT_DLGLOBAL		0
++#  endif
++#endif
++
++/* We may have to define LT_DLLAZY_OR_NOW in the command line if we
++   find out it does not work in some platform. */
++#ifndef LT_DLLAZY_OR_NOW
++#  ifdef RTLD_LAZY
++#    define LT_DLLAZY_OR_NOW		RTLD_LAZY
++#  else
++#    ifdef DL_LAZY
++#      define LT_DLLAZY_OR_NOW		DL_LAZY
++#    else
++#      ifdef RTLD_NOW
++#        define LT_DLLAZY_OR_NOW	RTLD_NOW
++#      else
++#        ifdef DL_NOW
++#          define LT_DLLAZY_OR_NOW	DL_NOW
++#        else
++#          define LT_DLLAZY_OR_NOW	0
++#        endif
++#      endif
++#    endif
++#  endif
++#endif
++
++void fnord() { int i=42;}
++int main ()
++{
++  void *self = dlopen (0, LT_DLGLOBAL|LT_DLLAZY_OR_NOW);
++  int status = $lt_dlunknown;
++
++  if (self)
++    {
++      if (dlsym (self,"fnord"))       status = $lt_dlno_uscore;
++      else if (dlsym( self,"_fnord")) status = $lt_dlneed_uscore;
++      /* dlclose (self); */
++    }
++  else
++    puts (dlerror ());
++
++  return status;
++}
++_LT_EOF
++  if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_link\""; } >&5
++  (eval $ac_link) 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; } && test -s conftest${ac_exeext} 2>/dev/null; then
++    (./conftest; exit; ) >&5 2>/dev/null
++    lt_status=$?
++    case x$lt_status in
++      x$lt_dlno_uscore) lt_cv_dlopen_self=yes ;;
++      x$lt_dlneed_uscore) lt_cv_dlopen_self=yes ;;
++      x$lt_dlunknown|x*) lt_cv_dlopen_self=no ;;
++    esac
++  else :
++    # compilation failed
++    lt_cv_dlopen_self=no
++  fi
++fi
++rm -fr conftest*
++
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_dlopen_self" >&5
++$as_echo "$lt_cv_dlopen_self" >&6; }
++
++    if test "x$lt_cv_dlopen_self" = xyes; then
++      wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $lt_prog_compiler_static\"
++      { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether a statically linked program can dlopen itself" >&5
++$as_echo_n "checking whether a statically linked program can dlopen itself... " >&6; }
++if test "${lt_cv_dlopen_self_static+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  	  if test "$cross_compiling" = yes; then :
++  lt_cv_dlopen_self_static=cross
++else
++  lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
++  lt_status=$lt_dlunknown
++  cat > conftest.$ac_ext <<_LT_EOF
++#line 10787 "configure"
++#include "confdefs.h"
++
++#if HAVE_DLFCN_H
++#include <dlfcn.h>
++#endif
++
++#include <stdio.h>
++
++#ifdef RTLD_GLOBAL
++#  define LT_DLGLOBAL		RTLD_GLOBAL
++#else
++#  ifdef DL_GLOBAL
++#    define LT_DLGLOBAL		DL_GLOBAL
++#  else
++#    define LT_DLGLOBAL		0
++#  endif
++#endif
++
++/* We may have to define LT_DLLAZY_OR_NOW in the command line if we
++   find out it does not work in some platform. */
++#ifndef LT_DLLAZY_OR_NOW
++#  ifdef RTLD_LAZY
++#    define LT_DLLAZY_OR_NOW		RTLD_LAZY
++#  else
++#    ifdef DL_LAZY
++#      define LT_DLLAZY_OR_NOW		DL_LAZY
++#    else
++#      ifdef RTLD_NOW
++#        define LT_DLLAZY_OR_NOW	RTLD_NOW
++#      else
++#        ifdef DL_NOW
++#          define LT_DLLAZY_OR_NOW	DL_NOW
++#        else
++#          define LT_DLLAZY_OR_NOW	0
++#        endif
++#      endif
++#    endif
++#  endif
++#endif
++
++void fnord() { int i=42;}
++int main ()
++{
++  void *self = dlopen (0, LT_DLGLOBAL|LT_DLLAZY_OR_NOW);
++  int status = $lt_dlunknown;
++
++  if (self)
++    {
++      if (dlsym (self,"fnord"))       status = $lt_dlno_uscore;
++      else if (dlsym( self,"_fnord")) status = $lt_dlneed_uscore;
++      /* dlclose (self); */
++    }
++  else
++    puts (dlerror ());
++
++  return status;
++}
++_LT_EOF
++  if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_link\""; } >&5
++  (eval $ac_link) 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; } && test -s conftest${ac_exeext} 2>/dev/null; then
++    (./conftest; exit; ) >&5 2>/dev/null
++    lt_status=$?
++    case x$lt_status in
++      x$lt_dlno_uscore) lt_cv_dlopen_self_static=yes ;;
++      x$lt_dlneed_uscore) lt_cv_dlopen_self_static=yes ;;
++      x$lt_dlunknown|x*) lt_cv_dlopen_self_static=no ;;
++    esac
++  else :
++    # compilation failed
++    lt_cv_dlopen_self_static=no
++  fi
++fi
++rm -fr conftest*
++
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $lt_cv_dlopen_self_static" >&5
++$as_echo "$lt_cv_dlopen_self_static" >&6; }
++    fi
++
++    CPPFLAGS="$save_CPPFLAGS"
++    LDFLAGS="$save_LDFLAGS"
++    LIBS="$save_LIBS"
++    ;;
++  esac
++
++  case $lt_cv_dlopen_self in
++  yes|no) enable_dlopen_self=$lt_cv_dlopen_self ;;
++  *) enable_dlopen_self=unknown ;;
++  esac
++
++  case $lt_cv_dlopen_self_static in
++  yes|no) enable_dlopen_self_static=$lt_cv_dlopen_self_static ;;
++  *) enable_dlopen_self_static=unknown ;;
++  esac
++fi
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++striplib=
++old_striplib=
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether stripping libraries is possible" >&5
++$as_echo_n "checking whether stripping libraries is possible... " >&6; }
++if test -n "$STRIP" && $STRIP -V 2>&1 | $GREP "GNU strip" >/dev/null; then
++  test -z "$old_striplib" && old_striplib="$STRIP --strip-debug"
++  test -z "$striplib" && striplib="$STRIP --strip-unneeded"
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++else
++# FIXME - insert some real tests, host_os isn't really good enough
++  case $host_os in
++  darwin*)
++    if test -n "$STRIP" ; then
++      striplib="$STRIP -x"
++      old_striplib="$STRIP -S"
++      { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++    else
++      { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++    fi
++    ;;
++  *)
++    { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++    ;;
++  esac
++fi
++
++
++
++
++
++
++
++
++
++
++
++
++  # Report which library types will actually be built
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking if libtool supports shared libraries" >&5
++$as_echo_n "checking if libtool supports shared libraries... " >&6; }
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $can_build_shared" >&5
++$as_echo "$can_build_shared" >&6; }
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether to build shared libraries" >&5
++$as_echo_n "checking whether to build shared libraries... " >&6; }
++  test "$can_build_shared" = "no" && enable_shared=no
++
++  # On AIX, shared libraries and static libraries use the same namespace, and
++  # are all built from PIC.
++  case $host_os in
++  aix3*)
++    test "$enable_shared" = yes && enable_static=no
++    if test -n "$RANLIB"; then
++      archive_cmds="$archive_cmds~\$RANLIB \$lib"
++      postinstall_cmds='$RANLIB $lib'
++    fi
++    ;;
++
++  aix[4-9]*)
++    if test "$host_cpu" != ia64 && test "$aix_use_runtimelinking" = no ; then
++      test "$enable_shared" = yes && enable_static=no
++    fi
++    ;;
++  esac
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $enable_shared" >&5
++$as_echo "$enable_shared" >&6; }
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether to build static libraries" >&5
++$as_echo_n "checking whether to build static libraries... " >&6; }
++  # Make sure either enable_shared or enable_static is yes.
++  test "$enable_shared" = yes || enable_static=yes
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $enable_static" >&5
++$as_echo "$enable_static" >&6; }
++
++
++
++
++fi
++ac_ext=c
++ac_cpp='$CPP $CPPFLAGS'
++ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
++ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
++ac_compiler_gnu=$ac_cv_c_compiler_gnu
++
++CC="$lt_save_CC"
++
++
++
++
++
++
++
++
++
++
++
++
++
++        ac_config_commands="$ac_config_commands libtool"
++
++
++
++
++# Only expand once:
++
++
++
++
++
++test "$sysconfdir" = '${prefix}/etc' && sysconfdir='/etc'
++test "$localstatedir" = '${prefix}/var' && localstatedir='/var/heimdal'
++
++
++CANONICAL_HOST=$host
++
++
++# Check whether --enable-largefile was given.
++if test "${enable_largefile+set}" = set; then :
++  enableval=$enable_largefile;
++fi
++
++if test "$enable_largefile" != no; then
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for special C compiler options needed for large files" >&5
++$as_echo_n "checking for special C compiler options needed for large files... " >&6; }
++if test "${ac_cv_sys_largefile_CC+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_cv_sys_largefile_CC=no
++     if test "$GCC" != yes; then
++       ac_save_CC=$CC
++       while :; do
++	 # IRIX 6.2 and later do not support large files by default,
++	 # so use the C compiler's -n32 option if that helps.
++	 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sys/types.h>
++ /* Check that off_t can represent 2**63 - 1 correctly.
++    We can't simply define LARGE_OFF_T to be 9223372036854775807,
++    since some C++ compilers masquerading as C compilers
++    incorrectly reject 9223372036854775807.  */
++#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
++  int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
++		       && LARGE_OFF_T % 2147483647 == 1)
++		      ? 1 : -1];
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++	 if ac_fn_c_try_compile "$LINENO"; then :
++  break
++fi
++rm -f core conftest.err conftest.$ac_objext
++	 CC="$CC -n32"
++	 if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_sys_largefile_CC=' -n32'; break
++fi
++rm -f core conftest.err conftest.$ac_objext
++	 break
++       done
++       CC=$ac_save_CC
++       rm -f conftest.$ac_ext
++    fi
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_sys_largefile_CC" >&5
++$as_echo "$ac_cv_sys_largefile_CC" >&6; }
++  if test "$ac_cv_sys_largefile_CC" != no; then
++    CC=$CC$ac_cv_sys_largefile_CC
++  fi
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for _FILE_OFFSET_BITS value needed for large files" >&5
++$as_echo_n "checking for _FILE_OFFSET_BITS value needed for large files... " >&6; }
++if test "${ac_cv_sys_file_offset_bits+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  while :; do
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sys/types.h>
++ /* Check that off_t can represent 2**63 - 1 correctly.
++    We can't simply define LARGE_OFF_T to be 9223372036854775807,
++    since some C++ compilers masquerading as C compilers
++    incorrectly reject 9223372036854775807.  */
++#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
++  int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
++		       && LARGE_OFF_T % 2147483647 == 1)
++		      ? 1 : -1];
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_sys_file_offset_bits=no; break
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#define _FILE_OFFSET_BITS 64
++#include <sys/types.h>
++ /* Check that off_t can represent 2**63 - 1 correctly.
++    We can't simply define LARGE_OFF_T to be 9223372036854775807,
++    since some C++ compilers masquerading as C compilers
++    incorrectly reject 9223372036854775807.  */
++#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
++  int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
++		       && LARGE_OFF_T % 2147483647 == 1)
++		      ? 1 : -1];
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_sys_file_offset_bits=64; break
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++  ac_cv_sys_file_offset_bits=unknown
++  break
++done
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_sys_file_offset_bits" >&5
++$as_echo "$ac_cv_sys_file_offset_bits" >&6; }
++case $ac_cv_sys_file_offset_bits in #(
++  no | unknown) ;;
++  *)
++cat >>confdefs.h <<_ACEOF
++#define _FILE_OFFSET_BITS $ac_cv_sys_file_offset_bits
++_ACEOF
++;;
++esac
++rm -rf conftest*
++  if test $ac_cv_sys_file_offset_bits = unknown; then
++    { $as_echo "$as_me:${as_lineno-$LINENO}: checking for _LARGE_FILES value needed for large files" >&5
++$as_echo_n "checking for _LARGE_FILES value needed for large files... " >&6; }
++if test "${ac_cv_sys_large_files+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  while :; do
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sys/types.h>
++ /* Check that off_t can represent 2**63 - 1 correctly.
++    We can't simply define LARGE_OFF_T to be 9223372036854775807,
++    since some C++ compilers masquerading as C compilers
++    incorrectly reject 9223372036854775807.  */
++#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
++  int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
++		       && LARGE_OFF_T % 2147483647 == 1)
++		      ? 1 : -1];
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_sys_large_files=no; break
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#define _LARGE_FILES 1
++#include <sys/types.h>
++ /* Check that off_t can represent 2**63 - 1 correctly.
++    We can't simply define LARGE_OFF_T to be 9223372036854775807,
++    since some C++ compilers masquerading as C compilers
++    incorrectly reject 9223372036854775807.  */
++#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
++  int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
++		       && LARGE_OFF_T % 2147483647 == 1)
++		      ? 1 : -1];
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_sys_large_files=1; break
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++  ac_cv_sys_large_files=unknown
++  break
++done
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_sys_large_files" >&5
++$as_echo "$ac_cv_sys_large_files" >&6; }
++case $ac_cv_sys_large_files in #(
++  no | unknown) ;;
++  *)
++cat >>confdefs.h <<_ACEOF
++#define _LARGE_FILES $ac_cv_sys_large_files
++_ACEOF
++;;
++esac
++rm -rf conftest*
++  fi
++fi
++
++
++if test "$enable_largefile" != no -a "$ac_cv_sys_large_files" != no; then
++	CPPFLAGS="$CPPFLAGS -D_LARGE_FILES=$ac_cv_sys_large_files"
++fi
++if test "$enable_largefile" != no -a "$ac_cv_sys_file_offset_bits" != no; then
++	CPPFLAGS="$CPPFLAGS -D_FILE_OFFSET_BITS=$ac_cv_sys_file_offset_bits"
++fi
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for dlopen" >&5
++$as_echo_n "checking for dlopen... " >&6; }
++if test "${ac_cv_funclib_dlopen+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_dlopen\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" dl; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_DLFCN_H
++#include <dlfcn.h>
++#endif
++int
++main ()
++{
++dlopen(0,0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_dlopen=$ac_lib; else ac_cv_funclib_dlopen=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_dlopen=\${ac_cv_funclib_dlopen-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_dlopen"
++
++if false; then
++	for ac_func in dlopen
++do :
++  ac_fn_c_check_func "$LINENO" "dlopen" "ac_cv_func_dlopen"
++if test "x$ac_cv_func_dlopen" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_DLOPEN 1
++_ACEOF
++
++fi
++done
++
++fi
++# dlopen
++eval "ac_tr_func=HAVE_`echo dlopen | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_dlopen=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_dlopen=yes"
++	eval "LIB_dlopen="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_dlopen=no"
++	eval "LIB_dlopen="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_dlopen=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++	 if test "$ac_cv_funclib_dlopen" != no; then
++  HAVE_DLOPEN_TRUE=
++  HAVE_DLOPEN_FALSE='#'
++else
++  HAVE_DLOPEN_TRUE='#'
++  HAVE_DLOPEN_FALSE=
++fi
++
++
++
++
++aix=no
++case "$host" in
++*-*-aix3*)
++	aix=3
++	;;
++*-*-aix[4-9]*)
++	aix=4
++	;;
++esac
++
++ if test "$aix" != no; then
++  AIX_TRUE=
++  AIX_FALSE='#'
++else
++  AIX_TRUE='#'
++  AIX_FALSE=
++fi
++ if test "$aix" = 4; then
++  AIX4_TRUE=
++  AIX4_FALSE='#'
++else
++  AIX4_TRUE='#'
++  AIX4_FALSE=
++fi
++
++# Check whether --enable-dynamic-afs was given.
++if test "${enable_dynamic_afs+set}" = set; then :
++  enableval=$enable_dynamic_afs;
++fi
++
++
++if test "$aix" != no; then
++
++
++$as_echo "#define NEED_QSORT 1" >>confdefs.h
++
++
++	if test "$enable_dynamic_afs" != no; then
++
++		if test "$ac_cv_func_dlopen" = no; then
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for loadquery" >&5
++$as_echo_n "checking for loadquery... " >&6; }
++if test "${ac_cv_funclib_loadquery+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_loadquery\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" ld; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++loadquery()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_loadquery=$ac_lib; else ac_cv_funclib_loadquery=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_loadquery=\${ac_cv_funclib_loadquery-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_loadquery"
++
++if false; then
++	for ac_func in loadquery
++do :
++  ac_fn_c_check_func "$LINENO" "loadquery" "ac_cv_func_loadquery"
++if test "x$ac_cv_func_loadquery" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_LOADQUERY 1
++_ACEOF
++
++fi
++done
++
++fi
++# loadquery
++eval "ac_tr_func=HAVE_`echo loadquery | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_loadquery=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_loadquery=yes"
++	eval "LIB_loadquery="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_loadquery=no"
++	eval "LIB_loadquery="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_loadquery=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++		fi
++		if test "$ac_cv_func_dlopen" != no; then
++			AIX_EXTRA_KAFS='$(LIB_dlopen)'
++		elif test "$ac_cv_func_loadquery" != no; then
++			AIX_EXTRA_KAFS='$(LIB_loadquery)'
++		else
++			{ $as_echo "$as_me:${as_lineno-$LINENO}: not using dynloaded AFS library" >&5
++$as_echo "$as_me: not using dynloaded AFS library" >&6;}
++			AIX_EXTRA_KAFS=
++			enable_dynamic_afs=no
++		fi
++	else
++		AIX_EXTRA_KAFS=
++	fi
++fi
++
++ if test "$enable_dynamic_afs" != no; then
++  AIX_DYNAMIC_AFS_TRUE=
++  AIX_DYNAMIC_AFS_FALSE='#'
++else
++  AIX_DYNAMIC_AFS_TRUE='#'
++  AIX_DYNAMIC_AFS_FALSE=
++fi
++
++if test "$aix" != no; then
++
++$as_echo "#define _ALL_SOURCE 1" >>confdefs.h
++
++fi
++
++
++
++
++
++irix=no
++case "$host" in
++*-*-irix*)
++	irix=yes
++	;;
++esac
++ if test "$irix" != no; then
++  IRIX_TRUE=
++  IRIX_FALSE='#'
++else
++  IRIX_TRUE='#'
++  IRIX_FALSE=
++fi
++
++
++
++sunos=no
++case "$host" in
++*-*-solaris2.7)
++	sunos=57
++	;;
++*-*-solaris2.[89] | *-*-solaris2.1[0-9])
++	sunos=58
++	;;
++*-*-solaris2*)
++	sunos=50
++	;;
++esac
++if test "$sunos" != no; then
++
++cat >>confdefs.h <<_ACEOF
++#define SunOS $sunos
++_ACEOF
++
++fi
++
++
++
++$as_echo "#define _GNU_SOURCE 1" >>confdefs.h
++
++
++
++
++
++for ac_prog in 'bison -y' byacc
++do
++  # Extract the first word of "$ac_prog", so it can be a program name with args.
++set dummy $ac_prog; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_YACC+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$YACC"; then
++  ac_cv_prog_YACC="$YACC" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_YACC="$ac_prog"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++YACC=$ac_cv_prog_YACC
++if test -n "$YACC"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $YACC" >&5
++$as_echo "$YACC" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++  test -n "$YACC" && break
++done
++test -n "$YACC" || YACC="yacc"
++
++for ac_prog in flex lex
++do
++  # Extract the first word of "$ac_prog", so it can be a program name with args.
++set dummy $ac_prog; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_LEX+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$LEX"; then
++  ac_cv_prog_LEX="$LEX" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_LEX="$ac_prog"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++LEX=$ac_cv_prog_LEX
++if test -n "$LEX"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $LEX" >&5
++$as_echo "$LEX" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++  test -n "$LEX" && break
++done
++test -n "$LEX" || LEX=":"
++
++if test "x$LEX" != "x:"; then
++  cat >conftest.l <<_ACEOF
++%%
++a { ECHO; }
++b { REJECT; }
++c { yymore (); }
++d { yyless (1); }
++e { yyless (input () != 0); }
++f { unput (yytext[0]); }
++. { BEGIN INITIAL; }
++%%
++#ifdef YYTEXT_POINTER
++extern char *yytext;
++#endif
++int
++main (void)
++{
++  return ! yylex () + ! yywrap ();
++}
++_ACEOF
++{ { ac_try="$LEX conftest.l"
++case "(($ac_try" in
++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
++  *) ac_try_echo=$ac_try;;
++esac
++eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
++$as_echo "$ac_try_echo"; } >&5
++  (eval "$LEX conftest.l") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking lex output file root" >&5
++$as_echo_n "checking lex output file root... " >&6; }
++if test "${ac_cv_prog_lex_root+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if test -f lex.yy.c; then
++  ac_cv_prog_lex_root=lex.yy
++elif test -f lexyy.c; then
++  ac_cv_prog_lex_root=lexyy
++else
++  as_fn_error $? "cannot find output from $LEX; giving up" "$LINENO" 5
++fi
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_prog_lex_root" >&5
++$as_echo "$ac_cv_prog_lex_root" >&6; }
++LEX_OUTPUT_ROOT=$ac_cv_prog_lex_root
++
++if test -z "${LEXLIB+set}"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking lex library" >&5
++$as_echo_n "checking lex library... " >&6; }
++if test "${ac_cv_lib_lex+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++    ac_save_LIBS=$LIBS
++    ac_cv_lib_lex='none needed'
++    for ac_lib in '' -lfl -ll; do
++      LIBS="$ac_lib $ac_save_LIBS"
++      cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++`cat $LEX_OUTPUT_ROOT.c`
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_lex=$ac_lib
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++      test "$ac_cv_lib_lex" != 'none needed' && break
++    done
++    LIBS=$ac_save_LIBS
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_lex" >&5
++$as_echo "$ac_cv_lib_lex" >&6; }
++  test "$ac_cv_lib_lex" != 'none needed' && LEXLIB=$ac_cv_lib_lex
++fi
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether yytext is a pointer" >&5
++$as_echo_n "checking whether yytext is a pointer... " >&6; }
++if test "${ac_cv_prog_lex_yytext_pointer+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  # POSIX says lex can declare yytext either as a pointer or an array; the
++# default is implementation-dependent.  Figure out which it is, since
++# not all implementations provide the %pointer and %array declarations.
++ac_cv_prog_lex_yytext_pointer=no
++ac_save_LIBS=$LIBS
++LIBS="$LEXLIB $ac_save_LIBS"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#define YYTEXT_POINTER 1
++`cat $LEX_OUTPUT_ROOT.c`
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_prog_lex_yytext_pointer=yes
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++LIBS=$ac_save_LIBS
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_prog_lex_yytext_pointer" >&5
++$as_echo "$ac_cv_prog_lex_yytext_pointer" >&6; }
++if test $ac_cv_prog_lex_yytext_pointer = yes; then
++
++$as_echo "#define YYTEXT_POINTER 1" >>confdefs.h
++
++fi
++rm -f conftest.l $LEX_OUTPUT_ROOT.c
++
++fi
++if test "$LEX" = :; then
++  LEX=${am_missing_run}flex
++fi
++for ac_prog in gawk mawk nawk awk
++do
++  # Extract the first word of "$ac_prog", so it can be a program name with args.
++set dummy $ac_prog; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_AWK+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$AWK"; then
++  ac_cv_prog_AWK="$AWK" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_AWK="$ac_prog"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++AWK=$ac_cv_prog_AWK
++if test -n "$AWK"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $AWK" >&5
++$as_echo "$AWK" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++  test -n "$AWK" && break
++done
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ln -s or something else" >&5
++$as_echo_n "checking for ln -s or something else... " >&6; }
++if test "${ac_cv_prog_LN_S+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  rm -f conftestdata
++if ln -s X conftestdata 2>/dev/null
++then
++  rm -f conftestdata
++  ac_cv_prog_LN_S="ln -s"
++else
++  touch conftestdata1
++  if ln conftestdata1 conftestdata2; then
++    rm -f conftestdata*
++    ac_cv_prog_LN_S=ln
++  else
++    ac_cv_prog_LN_S=cp
++  fi
++fi
++fi
++LN_S="$ac_cv_prog_LN_S"
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_prog_LN_S" >&5
++$as_echo "$ac_cv_prog_LN_S" >&6; }
++
++
++
++
++# Check whether --with-mips_abi was given.
++if test "${with_mips_abi+set}" = set; then :
++  withval=$with_mips_abi;
++fi
++
++
++case "$host_os" in
++irix*)
++with_mips_abi="${with_mips_abi:-yes}"
++if test -n "$GCC"; then
++
++# GCC < 2.8 only supports the O32 ABI. GCC >= 2.8 has a flag to select
++# which ABI to use, but only supports (as of 2.8.1) the N32 and 64 ABIs.
++#
++# Default to N32, but if GCC doesn't grok -mabi=n32, we assume an old
++# GCC and revert back to O32. The same goes if O32 is asked for - old
++# GCCs doesn't like the -mabi option, and new GCCs can't output O32.
++#
++# Don't you just love *all* the different SGI ABIs?
++
++case "${with_mips_abi}" in
++        32|o32) abi='-mabi=32';  abilibdirext=''     ;;
++       n32|yes) abi='-mabi=n32'; abilibdirext='32'  ;;
++        64) abi='-mabi=64';  abilibdirext='64'   ;;
++	no) abi=''; abilibdirext='';;
++         *) as_fn_error $? "\"Invalid ABI specified\"" "$LINENO" 5  ;;
++esac
++if test -n "$abi" ; then
++ac_foo=krb_cv_gcc_`echo $abi | tr =- __`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if $CC supports the $abi option" >&5
++$as_echo_n "checking if $CC supports the $abi option... " >&6; }
++if eval "test \"\${$ac_foo+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++save_CFLAGS="$CFLAGS"
++CFLAGS="$CFLAGS $abi"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++int x;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval $ac_foo=yes
++else
++  eval $ac_foo=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_extCFLAGS="$save_CFLAGS"
++
++fi
++
++ac_res=`eval echo \\\$$ac_foo`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
++$as_echo "$ac_res" >&6; }
++if test $ac_res = no; then
++# Try to figure out why that failed...
++case $abi in
++	-mabi=32)
++	save_CFLAGS="$CFLAGS"
++	CFLAGS="$CFLAGS -mabi=n32"
++	cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++int x;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_res=yes
++else
++  ac_res=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext	CLAGS="$save_CFLAGS"
++	if test $ac_res = yes; then
++		# New GCC
++		as_fn_error $? "$CC does not support the $with_mips_abi ABI" "$LINENO" 5
++	fi
++	# Old GCC
++	abi=''
++	abilibdirext=''
++	;;
++	-mabi=n32|-mabi=64)
++		if test $with_mips_abi = yes; then
++			# Old GCC, default to O32
++			abi=''
++			abilibdirext=''
++		else
++			# Some broken GCC
++			as_fn_error $? "$CC does not support the $with_mips_abi ABI" "$LINENO" 5
++		fi
++	;;
++esac
++fi #if test $ac_res = no; then
++fi #if test -n "$abi" ; then
++else
++case "${with_mips_abi}" in
++        32|o32) abi='-32'; abilibdirext=''     ;;
++       n32|yes) abi='-n32'; abilibdirext='32'  ;;
++        64) abi='-64'; abilibdirext='64'   ;;
++	no) abi=''; abilibdirext='';;
++         *) as_fn_error $? "\"Invalid ABI specified\"" "$LINENO" 5  ;;
++esac
++fi #if test -n "$GCC"; then
++;;
++esac
++
++CC="$CC $abi"
++libdir="$libdir$abilibdirext"
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for __attribute__" >&5
++$as_echo_n "checking for __attribute__... " >&6; }
++if test "${ac_cv___attribute__+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdlib.h>
++static void foo(void) __attribute__ ((noreturn));
++
++static void
++foo(void)
++{
++  exit(1);
++}
++
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv___attribute__=yes
++else
++  ac_cv___attribute__=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++
++if test "$ac_cv___attribute__" = "yes"; then
++
++$as_echo "#define HAVE___ATTRIBUTE__ 1" >>confdefs.h
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv___attribute__" >&5
++$as_echo "$ac_cv___attribute__" >&6; }
++
++
++
++
++
++ if test "$enable_shared" = "yes"; then
++  ENABLE_SHARED_TRUE=
++  ENABLE_SHARED_FALSE='#'
++else
++  ENABLE_SHARED_TRUE='#'
++  ENABLE_SHARED_FALSE=
++fi
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ld --version-script" >&5
++$as_echo_n "checking for ld --version-script... " >&6; }
++if test "${rk_cv_version_script+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++  rk_cv_version_script=no
++
++  cat > conftest.map <<EOF
++HEIM_GSS_V1 {
++        global: gss*;
++};
++HEIM_GSS_V1_1 {
++        global: gss_init_creds;
++} HEIM_GSS_V1;
++EOF
++cat > conftest.c <<EOF
++int gss_init_creds(int foo) { return 0; }
++EOF
++
++  if { ac_try='${CC-cc} -c $CFLAGS -fPIC conftest.c'
++  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
++  (eval $ac_try) 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; }  &&
++     { ac_try='${CC-cc} -shared -Wl,--version-script,conftest.map $CFLAGS $LDFLAGS -o libconftestlib.so conftest.o'
++  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
++  (eval $ac_try) 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; };
++  then
++    rk_cv_version_script=yes
++  fi
++rm -rf conftest* libconftest* .libs
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $rk_cv_version_script" >&5
++$as_echo "$rk_cv_version_script" >&6; }
++
++if test $rk_cv_version_script = yes ; then
++  doversioning=yes
++  LDFLAGS_VERSION_SCRIPT="-Wl,--version-script,"
++else
++  doversioning=no
++  LDFLAGS_VERSION_SCRIPT=
++fi
++
++
++ if test $doversioning = yes; then
++  versionscript_TRUE=
++  versionscript_FALSE='#'
++else
++  versionscript_TRUE='#'
++  versionscript_FALSE=
++fi
++
++
++
++
++
++
++
++
++ if test "${cross_compiling}" = yes; then
++  CROSS_COMPILE_TRUE=
++  CROSS_COMPILE_FALSE='#'
++else
++  CROSS_COMPILE_TRUE='#'
++  CROSS_COMPILE_FALSE=
++fi
++
++
++
++# Check whether --with-cross-tools was given.
++if test "${with_cross_tools+set}" = set; then :
++  withval=$with_cross_tools; if test "$withval" = "yes"; then
++		as_fn_error $? "Need path to cross tools" "$LINENO" 5
++	fi
++	with_cross_tools="${with_cross_tools}/"
++
++fi
++
++
++if test "${cross_compiling}" != yes ; then
++
++   ASN1_COMPILE="\$(top_builddir)/lib/asn1/asn1_compile\$(EXEEXT)"
++   SLC="\$(top_builddir)/lib/sl/slc"
++
++   ASN1_COMPILE_DEP="\$(ASN1_COMPILE)"
++   SLC_DEP="\$(SLC)"
++else
++   ASN1_COMPILE="${with_cross_tools}asn1_compile"
++   SLC="${with_cross_tools}slc"
++
++   ASN1_COMPILE_DEP=
++   SLC_DEP=
++fi
++
++
++
++
++
++
++
++
++
++$as_echo "#define HEIM_WEAK_CRYPTO 1" >>confdefs.h
++
++
++
++
++# Check whether --with-openldap was given.
++if test "${with_openldap+set}" = set; then :
++  withval=$with_openldap;
++fi
++
++
++# Check whether --with-openldap-lib was given.
++if test "${with_openldap_lib+set}" = set; then :
++  withval=$with_openldap_lib; if test "$withval" = "yes" -o "$withval" = "no"; then
++  as_fn_error $? "No argument for --with-openldap-lib" "$LINENO" 5
++elif test "X$with_openldap" = "X"; then
++  with_openldap=yes
++fi
++fi
++
++
++# Check whether --with-openldap-include was given.
++if test "${with_openldap_include+set}" = set; then :
++  withval=$with_openldap_include; if test "$withval" = "yes" -o "$withval" = "no"; then
++  as_fn_error $? "No argument for --with-openldap-include" "$LINENO" 5
++elif test "X$with_openldap" = "X"; then
++  with_openldap=yes
++fi
++fi
++
++
++# Check whether --with-openldap-config was given.
++if test "${with_openldap_config+set}" = set; then :
++  withval=$with_openldap_config;
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for openldap" >&5
++$as_echo_n "checking for openldap... " >&6; }
++
++case "$with_openldap" in
++yes|"") d='' ;;
++no)	d= ;;
++*)	d="$with_openldap" ;;
++esac
++
++header_dirs=
++lib_dirs=
++for i in $d; do
++	if test "$with_openldap_include" = ""; then
++		if test -d "$i/include/openldap"; then
++			header_dirs="$header_dirs $i/include/openldap"
++		fi
++		if test -d "$i/include"; then
++			header_dirs="$header_dirs $i/include"
++		fi
++	fi
++	if test "$with_openldap_lib" = ""; then
++		if test -d "$i/lib$abilibdirext"; then
++			lib_dirs="$lib_dirs $i/lib$abilibdirext"
++		fi
++	fi
++done
++
++if test "$with_openldap_include"; then
++	header_dirs="$with_openldap_include $header_dirs"
++fi
++if test "$with_openldap_lib"; then
++	lib_dirs="$with_openldap_lib $lib_dirs"
++fi
++
++if test "$with_openldap_config" = ""; then
++	with_openldap_config=''
++fi
++
++openldap_cflags=
++openldap_libs=
++
++case "$with_openldap_config" in
++yes|no|""|"")
++	if test -f $with_openldap/bin/ ; then
++		with_openldap_config=$with_openldap/bin/
++	fi
++	;;
++esac
++
++case "$with_openldap_config" in
++yes|no|"")
++	;;
++*)
++	openldap_cflags="`$with_openldap_config --cflags 2>&1`"
++	openldap_libs="`$with_openldap_config --libs 2>&1`"
++	;;
++esac
++
++found=no
++if test "$with_openldap" != no; then
++	save_CFLAGS="$CFLAGS"
++	save_LIBS="$LIBS"
++	if test "$openldap_cflags" -a "$openldap_libs"; then
++		CFLAGS="$openldap_cflags $save_CFLAGS"
++		LIBS="$openldap_libs $save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <lber.h>
++#include <ldap.h>
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++
++			INCLUDE_openldap="$openldap_cflags"
++			LIB_openldap="$openldap_libs"
++			{ $as_echo "$as_me:${as_lineno-$LINENO}: result: from $with_openldap_config" >&5
++$as_echo "from $with_openldap_config" >&6; }
++			found=yes
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	fi
++	if test "$found" = no; then
++		ires= lres=
++		for i in $header_dirs; do
++			CFLAGS="-I$i $save_CFLAGS"
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <lber.h>
++#include <ldap.h>
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ires=$i;break
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++		done
++		for i in $lib_dirs; do
++			LIBS="-L$i -lldap -llber  $save_LIBS"
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <lber.h>
++#include <ldap.h>
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  lres=$i;break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++		done
++		if test "$ires" -a "$lres" -a "$with_openldap" != "no"; then
++			INCLUDE_openldap="-I$ires"
++			LIB_openldap="-L$lres -lldap -llber "
++			found=yes
++			{ $as_echo "$as_me:${as_lineno-$LINENO}: result: headers $ires, libraries $lres" >&5
++$as_echo "headers $ires, libraries $lres" >&6; }
++		fi
++	fi
++	CFLAGS="$save_CFLAGS"
++	LIBS="$save_LIBS"
++fi
++
++if test "$found" = yes; then
++
++cat >>confdefs.h <<_ACEOF
++#define OPENLDAP 1
++_ACEOF
++
++	with_openldap=yes
++else
++	with_openldap=no
++	INCLUDE_openldap=
++	LIB_openldap=
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++
++
++
++# Check whether --enable-hdb-openldap-module was given.
++if test "${enable_hdb_openldap_module+set}" = set; then :
++  enableval=$enable_hdb_openldap_module;
++fi
++
++if test "$enable_hdb_openldap_module" = yes -a "$with_openldap" = yes; then
++
++$as_echo "#define OPENLDAP_MODULE 1" >>confdefs.h
++
++fi
++ if test "$enable_hdb_openldap_module" = yes -a "$with_openldap" = yes; then
++  OPENLDAP_MODULE_TRUE=
++  OPENLDAP_MODULE_FALSE='#'
++else
++  OPENLDAP_MODULE_TRUE='#'
++  OPENLDAP_MODULE_FALSE=
++fi
++
++
++
++# Check whether --enable-pk-init was given.
++if test "${enable_pk_init+set}" = set; then :
++  enableval=$enable_pk_init;
++fi
++
++if test "$enable_pk_init" != no ;then
++
++$as_echo "#define PKINIT 1" >>confdefs.h
++
++fi
++ if test "$enable_pk_init" != no; then
++  PKINIT_TRUE=
++  PKINIT_FALSE='#'
++else
++  PKINIT_TRUE='#'
++  PKINIT_FALSE=
++fi
++
++
++# Check whether --enable-digest was given.
++if test "${enable_digest+set}" = set; then :
++  enableval=$enable_digest;
++fi
++
++if test "$enable_digest" != no ;then
++
++$as_echo "#define DIGEST 1" >>confdefs.h
++
++fi
++
++# Check whether --enable-kx509 was given.
++if test "${enable_kx509+set}" = set; then :
++  enableval=$enable_kx509;
++fi
++
++if test "$enable_kx509" != no ;then
++
++$as_echo "#define KX509 1" >>confdefs.h
++
++fi
++
++# Check whether --enable-krb4 was given.
++if test "${enable_krb4+set}" = set; then :
++  enableval=$enable_krb4;
++fi
++
++if test "$enable_krb4" != no ;then
++
++$as_echo "#define KRB4 1" >>confdefs.h
++
++fi
++
++
++
++if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then
++	if test -n "$ac_tool_prefix"; then
++  # Extract the first word of "${ac_tool_prefix}pkg-config", so it can be a program name with args.
++set dummy ${ac_tool_prefix}pkg-config; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_path_PKG_CONFIG+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  case $PKG_CONFIG in
++  [\\/]* | ?:[\\/]*)
++  ac_cv_path_PKG_CONFIG="$PKG_CONFIG" # Let the user override the test with a path.
++  ;;
++  *)
++  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_path_PKG_CONFIG="$as_dir/$ac_word$ac_exec_ext"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++  ;;
++esac
++fi
++PKG_CONFIG=$ac_cv_path_PKG_CONFIG
++if test -n "$PKG_CONFIG"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $PKG_CONFIG" >&5
++$as_echo "$PKG_CONFIG" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++fi
++if test -z "$ac_cv_path_PKG_CONFIG"; then
++  ac_pt_PKG_CONFIG=$PKG_CONFIG
++  # Extract the first word of "pkg-config", so it can be a program name with args.
++set dummy pkg-config; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_path_ac_pt_PKG_CONFIG+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  case $ac_pt_PKG_CONFIG in
++  [\\/]* | ?:[\\/]*)
++  ac_cv_path_ac_pt_PKG_CONFIG="$ac_pt_PKG_CONFIG" # Let the user override the test with a path.
++  ;;
++  *)
++  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_path_ac_pt_PKG_CONFIG="$as_dir/$ac_word$ac_exec_ext"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++  ;;
++esac
++fi
++ac_pt_PKG_CONFIG=$ac_cv_path_ac_pt_PKG_CONFIG
++if test -n "$ac_pt_PKG_CONFIG"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_pt_PKG_CONFIG" >&5
++$as_echo "$ac_pt_PKG_CONFIG" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++  if test "x$ac_pt_PKG_CONFIG" = x; then
++    PKG_CONFIG=""
++  else
++    case $cross_compiling:$ac_tool_warned in
++yes:)
++{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5
++$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;}
++ac_tool_warned=yes ;;
++esac
++    PKG_CONFIG=$ac_pt_PKG_CONFIG
++  fi
++else
++  PKG_CONFIG="$ac_cv_path_PKG_CONFIG"
++fi
++
++fi
++if test -n "$PKG_CONFIG"; then
++	_pkg_min_version=0.9.0
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: checking pkg-config is at least version $_pkg_min_version" >&5
++$as_echo_n "checking pkg-config is at least version $_pkg_min_version... " >&6; }
++	if $PKG_CONFIG --atleast-pkgconfig-version $_pkg_min_version; then
++		{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	else
++		{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++		PKG_CONFIG=""
++	fi
++
++fi
++
++
++# Check whether --with-capng was given.
++if test "${with_capng+set}" = set; then :
++  withval=$with_capng;
++else
++  with_capng=check
++fi
++
++if test "$with_capng" != "no"; then
++
++pkg_failed=no
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for CAPNG" >&5
++$as_echo_n "checking for CAPNG... " >&6; }
++
++if test -n "$PKG_CONFIG"; then
++    if test -n "$CAPNG_CFLAGS"; then
++        pkg_cv_CAPNG_CFLAGS="$CAPNG_CFLAGS"
++    else
++        if test -n "$PKG_CONFIG" && \
++    { { $as_echo "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists --print-errors \"libcap-ng >= 0.4.0\""; } >&5
++  ($PKG_CONFIG --exists --print-errors "libcap-ng >= 0.4.0") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; then
++  pkg_cv_CAPNG_CFLAGS=`$PKG_CONFIG --cflags "libcap-ng >= 0.4.0" 2>/dev/null`
++else
++  pkg_failed=yes
++fi
++    fi
++else
++	pkg_failed=untried
++fi
++if test -n "$PKG_CONFIG"; then
++    if test -n "$CAPNG_LIBS"; then
++        pkg_cv_CAPNG_LIBS="$CAPNG_LIBS"
++    else
++        if test -n "$PKG_CONFIG" && \
++    { { $as_echo "$as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists --print-errors \"libcap-ng >= 0.4.0\""; } >&5
++  ($PKG_CONFIG --exists --print-errors "libcap-ng >= 0.4.0") 2>&5
++  ac_status=$?
++  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
++  test $ac_status = 0; }; then
++  pkg_cv_CAPNG_LIBS=`$PKG_CONFIG --libs "libcap-ng >= 0.4.0" 2>/dev/null`
++else
++  pkg_failed=yes
++fi
++    fi
++else
++	pkg_failed=untried
++fi
++
++
++
++if test $pkg_failed = yes; then
++
++if $PKG_CONFIG --atleast-pkgconfig-version 0.20; then
++        _pkg_short_errors_supported=yes
++else
++        _pkg_short_errors_supported=no
++fi
++        if test $_pkg_short_errors_supported = yes; then
++	        CAPNG_PKG_ERRORS=`$PKG_CONFIG --short-errors --errors-to-stdout --print-errors "libcap-ng >= 0.4.0"`
++        else
++	        CAPNG_PKG_ERRORS=`$PKG_CONFIG --errors-to-stdout --print-errors "libcap-ng >= 0.4.0"`
++        fi
++	# Put the nasty error message in config.log where it belongs
++	echo "$CAPNG_PKG_ERRORS" >&5
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++                with_capng=no
++elif test $pkg_failed = untried; then
++	with_capng=no
++else
++	CAPNG_CFLAGS=$pkg_cv_CAPNG_CFLAGS
++	CAPNG_LIBS=$pkg_cv_CAPNG_LIBS
++        { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	with_capng=yes
++fi
++fi
++if test "$with_capng" = "yes"; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_CAPNG 1
++_ACEOF
++
++fi
++ if test "$with_capng" != "no"; then
++  HAVE_CAPNG_TRUE=
++  HAVE_CAPNG_FALSE='#'
++else
++  HAVE_CAPNG_TRUE='#'
++  HAVE_CAPNG_FALSE=
++fi
++
++
++
++
++
++
++# Check whether --with-sqlite3 was given.
++if test "${with_sqlite3+set}" = set; then :
++  withval=$with_sqlite3;
++fi
++
++
++# Check whether --with-sqlite3-lib was given.
++if test "${with_sqlite3_lib+set}" = set; then :
++  withval=$with_sqlite3_lib; if test "$withval" = "yes" -o "$withval" = "no"; then
++  as_fn_error $? "No argument for --with-sqlite3-lib" "$LINENO" 5
++elif test "X$with_sqlite3" = "X"; then
++  with_sqlite3=yes
++fi
++fi
++
++
++# Check whether --with-sqlite3-include was given.
++if test "${with_sqlite3_include+set}" = set; then :
++  withval=$with_sqlite3_include; if test "$withval" = "yes" -o "$withval" = "no"; then
++  as_fn_error $? "No argument for --with-sqlite3-include" "$LINENO" 5
++elif test "X$with_sqlite3" = "X"; then
++  with_sqlite3=yes
++fi
++fi
++
++
++# Check whether --with-sqlite3-config was given.
++if test "${with_sqlite3_config+set}" = set; then :
++  withval=$with_sqlite3_config;
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for sqlite3" >&5
++$as_echo_n "checking for sqlite3... " >&6; }
++
++case "$with_sqlite3" in
++yes|"") d='' ;;
++no)	d= ;;
++*)	d="$with_sqlite3" ;;
++esac
++
++header_dirs=
++lib_dirs=
++for i in $d; do
++	if test "$with_sqlite3_include" = ""; then
++		if test -d "$i/include/sqlite3"; then
++			header_dirs="$header_dirs $i/include/sqlite3"
++		fi
++		if test -d "$i/include"; then
++			header_dirs="$header_dirs $i/include"
++		fi
++	fi
++	if test "$with_sqlite3_lib" = ""; then
++		if test -d "$i/lib$abilibdirext"; then
++			lib_dirs="$lib_dirs $i/lib$abilibdirext"
++		fi
++	fi
++done
++
++if test "$with_sqlite3_include"; then
++	header_dirs="$with_sqlite3_include $header_dirs"
++fi
++if test "$with_sqlite3_lib"; then
++	lib_dirs="$with_sqlite3_lib $lib_dirs"
++fi
++
++if test "$with_sqlite3_config" = ""; then
++	with_sqlite3_config=''
++fi
++
++sqlite3_cflags=
++sqlite3_libs=
++
++case "$with_sqlite3_config" in
++yes|no|""|"")
++	if test -f $with_sqlite3/bin/ ; then
++		with_sqlite3_config=$with_sqlite3/bin/
++	fi
++	;;
++esac
++
++case "$with_sqlite3_config" in
++yes|no|"")
++	;;
++*)
++	sqlite3_cflags="`$with_sqlite3_config --cflags 2>&1`"
++	sqlite3_libs="`$with_sqlite3_config --libs 2>&1`"
++	;;
++esac
++
++found=no
++if test "$with_sqlite3" != no; then
++	save_CFLAGS="$CFLAGS"
++	save_LIBS="$LIBS"
++	if test "$sqlite3_cflags" -a "$sqlite3_libs"; then
++		CFLAGS="$sqlite3_cflags $save_CFLAGS"
++		LIBS="$sqlite3_libs $save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sqlite3.h>
++#ifndef SQLITE_OPEN_CREATE
++#error "old version"
++#endif
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++
++			INCLUDE_sqlite3="$sqlite3_cflags"
++			LIB_sqlite3="$sqlite3_libs"
++			{ $as_echo "$as_me:${as_lineno-$LINENO}: result: from $with_sqlite3_config" >&5
++$as_echo "from $with_sqlite3_config" >&6; }
++			found=yes
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	fi
++	if test "$found" = no; then
++		ires= lres=
++		for i in $header_dirs; do
++			CFLAGS="-I$i $save_CFLAGS"
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sqlite3.h>
++#ifndef SQLITE_OPEN_CREATE
++#error "old version"
++#endif
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ires=$i;break
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++		done
++		for i in $lib_dirs; do
++			LIBS="-L$i -lsqlite3  $save_LIBS"
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sqlite3.h>
++#ifndef SQLITE_OPEN_CREATE
++#error "old version"
++#endif
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  lres=$i;break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++		done
++		if test "$ires" -a "$lres" -a "$with_sqlite3" != "no"; then
++			INCLUDE_sqlite3="-I$ires"
++			LIB_sqlite3="-L$lres -lsqlite3 "
++			found=yes
++			{ $as_echo "$as_me:${as_lineno-$LINENO}: result: headers $ires, libraries $lres" >&5
++$as_echo "headers $ires, libraries $lres" >&6; }
++		fi
++	fi
++	CFLAGS="$save_CFLAGS"
++	LIBS="$save_LIBS"
++fi
++
++if test "$found" = yes; then
++
++cat >>confdefs.h <<_ACEOF
++#define SQLITE3 1
++_ACEOF
++
++	with_sqlite3=yes
++else
++	with_sqlite3=no
++	INCLUDE_sqlite3=
++	LIB_sqlite3=
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++
++
++
++if test "X$with_sqlite3" != Xyes ; then
++   INCLUDE_sqlite3="-I\$(top_srcdir)/lib/sqlite"
++   LIB_sqlite3="\$(top_builddir)/lib/sqlite/libheimsqlite.la"
++fi
++ if test "X$with_sqlite3" = Xyes; then
++  SQLITE3_TRUE=
++  SQLITE3_FALSE='#'
++else
++  SQLITE3_TRUE='#'
++  SQLITE3_FALSE=
++fi
++
++
++# Check whether --enable-sqlite-cache was given.
++if test "${enable_sqlite_cache+set}" = set; then :
++  enableval=$enable_sqlite_cache;
++fi
++
++if test "$enable_sqlite_cache" != no; then
++
++$as_echo "#define HAVE_SCC 1" >>confdefs.h
++
++fi
++ if test "$enable_sqlite_cache" != no; then
++  have_scc_TRUE=
++  have_scc_FALSE='#'
++else
++  have_scc_TRUE='#'
++  have_scc_FALSE=
++fi
++
++
++
++
++
++# Check whether --with-libintl was given.
++if test "${with_libintl+set}" = set; then :
++  withval=$with_libintl;
++fi
++
++
++# Check whether --with-libintl-lib was given.
++if test "${with_libintl_lib+set}" = set; then :
++  withval=$with_libintl_lib; if test "$withval" = "yes" -o "$withval" = "no"; then
++  as_fn_error $? "No argument for --with-libintl-lib" "$LINENO" 5
++elif test "X$with_libintl" = "X"; then
++  with_libintl=yes
++fi
++fi
++
++
++# Check whether --with-libintl-include was given.
++if test "${with_libintl_include+set}" = set; then :
++  withval=$with_libintl_include; if test "$withval" = "yes" -o "$withval" = "no"; then
++  as_fn_error $? "No argument for --with-libintl-include" "$LINENO" 5
++elif test "X$with_libintl" = "X"; then
++  with_libintl=yes
++fi
++fi
++
++
++# Check whether --with-libintl-config was given.
++if test "${with_libintl_config+set}" = set; then :
++  withval=$with_libintl_config;
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for libintl" >&5
++$as_echo_n "checking for libintl... " >&6; }
++
++case "$with_libintl" in
++yes|"") d='' ;;
++no)	d= ;;
++*)	d="$with_libintl" ;;
++esac
++
++header_dirs=
++lib_dirs=
++for i in $d; do
++	if test "$with_libintl_include" = ""; then
++		if test -d "$i/include/libintl"; then
++			header_dirs="$header_dirs $i/include/libintl"
++		fi
++		if test -d "$i/include"; then
++			header_dirs="$header_dirs $i/include"
++		fi
++	fi
++	if test "$with_libintl_lib" = ""; then
++		if test -d "$i/lib$abilibdirext"; then
++			lib_dirs="$lib_dirs $i/lib$abilibdirext"
++		fi
++	fi
++done
++
++if test "$with_libintl_include"; then
++	header_dirs="$with_libintl_include $header_dirs"
++fi
++if test "$with_libintl_lib"; then
++	lib_dirs="$with_libintl_lib $lib_dirs"
++fi
++
++if test "$with_libintl_config" = ""; then
++	with_libintl_config=''
++fi
++
++libintl_cflags=
++libintl_libs=
++
++case "$with_libintl_config" in
++yes|no|""|"")
++	if test -f $with_libintl/bin/ ; then
++		with_libintl_config=$with_libintl/bin/
++	fi
++	;;
++esac
++
++case "$with_libintl_config" in
++yes|no|"")
++	;;
++*)
++	libintl_cflags="`$with_libintl_config --cflags 2>&1`"
++	libintl_libs="`$with_libintl_config --libs 2>&1`"
++	;;
++esac
++
++found=no
++if test "$with_libintl" != no; then
++	save_CFLAGS="$CFLAGS"
++	save_LIBS="$LIBS"
++	if test "$libintl_cflags" -a "$libintl_libs"; then
++		CFLAGS="$libintl_cflags $save_CFLAGS"
++		LIBS="$libintl_libs $save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <libintl.h>
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++
++			INCLUDE_libintl="$libintl_cflags"
++			LIB_libintl="$libintl_libs"
++			{ $as_echo "$as_me:${as_lineno-$LINENO}: result: from $with_libintl_config" >&5
++$as_echo "from $with_libintl_config" >&6; }
++			found=yes
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	fi
++	if test "$found" = no; then
++		ires= lres=
++		for i in $header_dirs; do
++			CFLAGS="-I$i $save_CFLAGS"
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <libintl.h>
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ires=$i;break
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++		done
++		for i in $lib_dirs; do
++			LIBS="-L$i -lintl  $save_LIBS"
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <libintl.h>
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  lres=$i;break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++		done
++		if test "$ires" -a "$lres" -a "$with_libintl" != "no"; then
++			INCLUDE_libintl="-I$ires"
++			LIB_libintl="-L$lres -lintl "
++			found=yes
++			{ $as_echo "$as_me:${as_lineno-$LINENO}: result: headers $ires, libraries $lres" >&5
++$as_echo "headers $ires, libraries $lres" >&6; }
++		fi
++	fi
++	CFLAGS="$save_CFLAGS"
++	LIBS="$save_LIBS"
++fi
++
++if test "$found" = yes; then
++
++cat >>confdefs.h <<_ACEOF
++#define LIBINTL 1
++_ACEOF
++
++	with_libintl=yes
++else
++	with_libintl=no
++	INCLUDE_libintl=
++	LIB_libintl=
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++
++
++
++
++# Check whether --with-hdbdir was given.
++if test "${with_hdbdir+set}" = set; then :
++  withval=$with_hdbdir;
++else
++  with_hdbdir=/var/heimdal
++fi
++
++DIR_hdbdir="$with_hdbdir"
++
++
++
++with_krb4=no
++
++
++ if false; then
++  KRB4_TRUE=
++  KRB4_FALSE='#'
++else
++  KRB4_TRUE='#'
++  KRB4_FALSE=
++fi
++
++
++ if true; then
++  KRB5_TRUE=
++  KRB5_FALSE='#'
++else
++  KRB5_TRUE='#'
++  KRB5_FALSE=
++fi
++
++ if true; then
++  do_roken_rename_TRUE=
++  do_roken_rename_FALSE='#'
++else
++  do_roken_rename_TRUE='#'
++  do_roken_rename_FALSE=
++fi
++
++
++
++$as_echo "#define SUPPORT_INETD 1" >>confdefs.h
++
++
++
++$as_echo "#define KRB5 1" >>confdefs.h
++
++
++crypto_lib=unknown
++
++
++# Check whether --with-openssl was given.
++if test "${with_openssl+set}" = set; then :
++  withval=$with_openssl;
++fi
++
++
++
++# Check whether --with-openssl-lib was given.
++if test "${with_openssl_lib+set}" = set; then :
++  withval=$with_openssl_lib; if test "$withval" = "yes" -o "$withval" = "no"; then
++  as_fn_error $? "No argument for --with-openssl-lib" "$LINENO" 5
++elif test "X$with_openssl" = "X"; then
++  with_openssl=yes
++fi
++fi
++
++
++
++# Check whether --with-openssl-include was given.
++if test "${with_openssl_include+set}" = set; then :
++  withval=$with_openssl_include; if test "$withval" = "yes" -o "$withval" = "no"; then
++  as_fn_error $? "No argument for --with-openssl-include" "$LINENO" 5
++elif test "X$with_openssl" = "X"; then
++  with_openssl=yes
++fi
++fi
++
++
++case "$with_openssl" in
++yes)	;;
++no)	;;
++"")	;;
++*)	if test "$with_openssl_include" = ""; then
++		with_openssl_include="$with_openssl/include"
++	fi
++	if test "$with_openssl_lib" = ""; then
++		with_openssl_lib="$with_openssl/lib$abilibdirext"
++	fi
++	;;
++esac
++
++
++DIR_hcrypto=
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for crypto library" >&5
++$as_echo_n "checking for crypto library... " >&6; }
++
++openssl=no
++
++if test "$crypto_lib" = "unknown" -a "$with_krb4" != "no"; then
++	save_CPPFLAGS="$CPPFLAGS"
++	save_LIBS="$LIBS"
++
++	cdirs= clibs=
++	for i in $LIB_krb4; do
++		case "$i" in
++		-L*) cdirs="$cdirs $i";;
++		-l*) clibs="$clibs $i";;
++		esac
++	done
++
++	ires=
++	for i in $INCLUDE_krb4; do
++		CFLAGS="-DHAVE_OPENSSL $i $save_CFLAGS"
++		for j in $cdirs; do
++			for k in $clibs; do
++				LIBS="$j $k $save_LIBS"
++				cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++		#undef KRB5 /* makes md4.h et al unhappy */
++		#ifdef HAVE_OPENSSL
++		#ifdef HAVE_SYS_TYPES_H
++		#include <sys/types.h>
++		#endif
++		#include <openssl/evp.h>
++		#include <openssl/md4.h>
++		#include <openssl/md5.h>
++		#include <openssl/sha.h>
++		#include <openssl/des.h>
++		#include <openssl/rc4.h>
++		#include <openssl/aes.h>
++		#include <openssl/ec.h>
++		#include <openssl/engine.h>
++		#include <openssl/ui.h>
++		#include <openssl/rand.h>
++		#include <openssl/hmac.h>
++		#include <openssl/pkcs12.h>
++		#else
++		#include <hcrypto/evp.h>
++		#include <hcrypto/md4.h>
++		#include <hcrypto/md5.h>
++		#include <hcrypto/sha.h>
++		#include <hcrypto/des.h>
++		#include <hcrypto/rc4.h>
++		#include <hcrypto/aes.h>
++		#include <hcrypto/engine.h>
++		#include <hcrypto/hmac.h>
++		#include <hcrypto/pkcs12.h>
++		#endif
++
++int
++main ()
++{
++
++		void *schedule = 0;
++		EVP_MD_CTX mdctx;
++
++		EVP_md4();
++		EVP_md5();
++		EVP_sha1();
++		EVP_sha256();
++
++		EVP_MD_CTX_init(&mdctx);
++		EVP_DigestInit_ex(&mdctx, EVP_sha1(), (ENGINE *)0);
++		EVP_CIPHER_iv_length(((EVP_CIPHER*)0));
++		UI_UTIL_read_pw_string(0,0,0,0);
++		RAND_status();
++		#ifdef HAVE_OPENSSL
++		EC_KEY_new();
++		#endif
++
++		OpenSSL_add_all_algorithms();
++		AES_encrypt(0,0,0);
++		DES_cbc_encrypt(0, 0, 0, schedule, 0, 0);
++		RC4(0, 0, 0, 0);
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  openssl=yes ires="$i" lres="$j $k"; break 3
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++			done
++		done
++		CFLAGS="$i $save_CFLAGS"
++		for j in $cdirs; do
++			for k in $clibs; do
++				LIBS="$j $k $save_LIBS"
++				cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++		#undef KRB5 /* makes md4.h et al unhappy */
++		#ifdef HAVE_OPENSSL
++		#ifdef HAVE_SYS_TYPES_H
++		#include <sys/types.h>
++		#endif
++		#include <openssl/evp.h>
++		#include <openssl/md4.h>
++		#include <openssl/md5.h>
++		#include <openssl/sha.h>
++		#include <openssl/des.h>
++		#include <openssl/rc4.h>
++		#include <openssl/aes.h>
++		#include <openssl/ec.h>
++		#include <openssl/engine.h>
++		#include <openssl/ui.h>
++		#include <openssl/rand.h>
++		#include <openssl/hmac.h>
++		#include <openssl/pkcs12.h>
++		#else
++		#include <hcrypto/evp.h>
++		#include <hcrypto/md4.h>
++		#include <hcrypto/md5.h>
++		#include <hcrypto/sha.h>
++		#include <hcrypto/des.h>
++		#include <hcrypto/rc4.h>
++		#include <hcrypto/aes.h>
++		#include <hcrypto/engine.h>
++		#include <hcrypto/hmac.h>
++		#include <hcrypto/pkcs12.h>
++		#endif
++
++int
++main ()
++{
++
++		void *schedule = 0;
++		EVP_MD_CTX mdctx;
++
++		EVP_md4();
++		EVP_md5();
++		EVP_sha1();
++		EVP_sha256();
++
++		EVP_MD_CTX_init(&mdctx);
++		EVP_DigestInit_ex(&mdctx, EVP_sha1(), (ENGINE *)0);
++		EVP_CIPHER_iv_length(((EVP_CIPHER*)0));
++		UI_UTIL_read_pw_string(0,0,0,0);
++		RAND_status();
++		#ifdef HAVE_OPENSSL
++		EC_KEY_new();
++		#endif
++
++		OpenSSL_add_all_algorithms();
++		AES_encrypt(0,0,0);
++		DES_cbc_encrypt(0, 0, 0, schedule, 0, 0);
++		RC4(0, 0, 0, 0);
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  openssl=no ires="$i" lres="$j $k"; break 3
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++			done
++		done
++	done
++
++	CFLAGS="$save_CFLAGS"
++	LIBS="$save_LIBS"
++	if test "$ires" -a "$lres"; then
++		INCLUDE_hcrypto="$ires"
++		LIB_hcrypto="$lres"
++		crypto_lib=krb4
++		{ $as_echo "$as_me:${as_lineno-$LINENO}: result: same as krb4" >&5
++$as_echo "same as krb4" >&6; }
++		LIB_hcrypto_a='$(LIB_hcrypto)'
++		LIB_hcrypto_so='$(LIB_hcrypto)'
++		LIB_hcrypto_appl='$(LIB_hcrypto)'
++	fi
++fi
++
++if test "$crypto_lib" = "unknown" -a "$with_openssl" != "no"; then
++	save_CFLAGS="$CFLAGS"
++	save_LIBS="$LIBS"
++	INCLUDE_hcrypto=
++	LIB_hcrypto=
++	if test "$with_openssl_include" != ""; then
++		INCLUDE_hcrypto="-I${with_openssl_include}"
++	fi
++	if test "$with_openssl_lib" != ""; then
++		LIB_hcrypto="-L${with_openssl_lib}"
++	fi
++	CFLAGS="-DHAVE_OPENSSL ${INCLUDE_hcrypto} ${CFLAGS}"
++	saved_LIB_hcrypto="$LIB_hcrypto"
++	for lres in "" "-ldl" "-lnsl -lsocket" "-lnsl -lsocket -ldl"; do
++		LIB_hcrypto="${saved_LIB_hcrypto} -lcrypto $lres"
++		LIB_hcrypto_a="$LIB_hcrypto"
++		LIB_hcrypto_so="$LIB_hcrypto"
++		LIB_hcrypto_appl="$LIB_hcrypto"
++		LIBS="${LIBS} ${LIB_hcrypto}"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++		#undef KRB5 /* makes md4.h et al unhappy */
++		#ifdef HAVE_OPENSSL
++		#ifdef HAVE_SYS_TYPES_H
++		#include <sys/types.h>
++		#endif
++		#include <openssl/evp.h>
++		#include <openssl/md4.h>
++		#include <openssl/md5.h>
++		#include <openssl/sha.h>
++		#include <openssl/des.h>
++		#include <openssl/rc4.h>
++		#include <openssl/aes.h>
++		#include <openssl/ec.h>
++		#include <openssl/engine.h>
++		#include <openssl/ui.h>
++		#include <openssl/rand.h>
++		#include <openssl/hmac.h>
++		#include <openssl/pkcs12.h>
++		#else
++		#include <hcrypto/evp.h>
++		#include <hcrypto/md4.h>
++		#include <hcrypto/md5.h>
++		#include <hcrypto/sha.h>
++		#include <hcrypto/des.h>
++		#include <hcrypto/rc4.h>
++		#include <hcrypto/aes.h>
++		#include <hcrypto/engine.h>
++		#include <hcrypto/hmac.h>
++		#include <hcrypto/pkcs12.h>
++		#endif
++
++int
++main ()
++{
++
++		void *schedule = 0;
++		EVP_MD_CTX mdctx;
++
++		EVP_md4();
++		EVP_md5();
++		EVP_sha1();
++		EVP_sha256();
++
++		EVP_MD_CTX_init(&mdctx);
++		EVP_DigestInit_ex(&mdctx, EVP_sha1(), (ENGINE *)0);
++		EVP_CIPHER_iv_length(((EVP_CIPHER*)0));
++		UI_UTIL_read_pw_string(0,0,0,0);
++		RAND_status();
++		#ifdef HAVE_OPENSSL
++		EC_KEY_new();
++		#endif
++
++		OpenSSL_add_all_algorithms();
++		AES_encrypt(0,0,0);
++		DES_cbc_encrypt(0, 0, 0, schedule, 0, 0);
++		RC4(0, 0, 0, 0);
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++
++			crypto_lib=libcrypto openssl=yes
++			{ $as_echo "$as_me:${as_lineno-$LINENO}: result: libcrypto" >&5
++$as_echo "libcrypto" >&6; }
++
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++		if test "$crypto_lib" = libcrypto ; then
++			break;
++		fi
++	done
++	CFLAGS="$save_CFLAGS"
++	LIBS="$save_LIBS"
++fi
++
++if test "$crypto_lib" = "unknown"; then
++
++  DIR_hcrypto='hcrypto'
++  LIB_hcrypto='$(top_builddir)/lib/hcrypto/libhcrypto.la'
++  LIB_hcrypto_a='$(top_builddir)/lib/hcrypto/.libs/libhcrypto.a'
++  LIB_hcrypto_so='$(top_builddir)/lib/hcrypto/.libs/libhcrypto.so'
++  LIB_hcrypto_appl="-lhcrypto"
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: included libhcrypto" >&5
++$as_echo "included libhcrypto" >&6; }
++
++fi
++
++if test "$with_krb4" != no -a "$crypto_lib" != krb4; then
++	as_fn_error $? "the crypto library used by krb4 lacks features
++required by Kerberos 5; to continue, you need to install a newer
++Kerberos 4 or configure --without-krb4" "$LINENO" 5
++fi
++
++if test "$openssl" = "yes"; then
++
++$as_echo "#define HAVE_OPENSSL 1" >>confdefs.h
++
++fi
++ if test "$openssl" = yes; then
++  HAVE_OPENSSL_TRUE=
++  HAVE_OPENSSL_FALSE='#'
++else
++  HAVE_OPENSSL_TRUE='#'
++  HAVE_OPENSSL_FALSE=
++fi
++
++
++
++
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if compiling threadsafe libraries" >&5
++$as_echo_n "checking if compiling threadsafe libraries... " >&6; }
++
++# Check whether --enable-pthread-support was given.
++if test "${enable_pthread_support+set}" = set; then :
++  enableval=$enable_pthread_support;
++else
++  enable_pthread_support=maybe
++fi
++
++
++case "$host" in
++*-*-solaris2*)
++	native_pthread_support=yes
++	if test "$GCC" = yes; then
++		PTHREAD_CFLAGS=-pthreads
++		PTHREAD_LIBADD=-pthreads
++	else
++		PTHREAD_CFLAGS=-mt
++		PTHREAD_LDADD=-mt
++		PTHREAD_LIBADD=-mt
++	fi
++	;;
++*-*-netbsd[12]*)
++	native_pthread_support="if running netbsd 1.6T or newer"
++		PTHREAD_LIBADD="-lpthread"
++	;;
++*-*-netbsd[3456789]*)
++	native_pthread_support="netbsd 3 uses explict pthread"
++		PTHREAD_LIBADD="-lpthread"
++	;;
++*-*-freebsd[56789]*)
++	native_pthread_support=yes
++	PTHREAD_LIBADD="-pthread"
++	;;
++*-*-openbsd*)
++	native_pthread_support=yes
++	PTHREAD_CFLAGS=-pthread
++	PTHREAD_LIBADD=-pthread
++	;;
++*-*-linux* | *-*-linux-gnu)
++	case `uname -r` in
++	2.*)
++		native_pthread_support=yes
++		PTHREAD_CFLAGS=-pthread
++		PTHREAD_LIBADD="-pthread -lpthread"
++		;;
++	esac
++	;;
++*-*-kfreebsd*-gnu*)
++	native_pthread_support=yes
++	PTHREAD_CFLAGS=-pthread
++	PTHREAD_LIBADD=-pthread
++	;;
++*-*-aix*)
++	        	native_pthread_support=no
++	;;
++mips-sgi-irix6.[5-9])  # maybe works for earlier versions too
++	native_pthread_support=yes
++	PTHREAD_LIBADD="-lpthread"
++	;;
++*-*-darwin*)
++	native_pthread_support=yes
++	;;
++*)
++	native_pthread_support=no
++	;;
++esac
++
++if test "$enable_pthread_support" = maybe ; then
++	enable_pthread_support="$native_pthread_support"
++fi
++
++if test "$enable_pthread_support" != no; then
++
++$as_echo "#define ENABLE_PTHREAD_SUPPORT 1" >>confdefs.h
++
++            LIBS="$PTHREAD_LIBADD $LIBS"
++else
++  PTHREAD_CFLAGS=""
++  PTHREAD_LIBADD=""
++fi
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $enable_pthread_support" >&5
++$as_echo "$enable_pthread_support" >&6; }
++
++
++# Check whether --enable-dce was given.
++if test "${enable_dce+set}" = set; then :
++  enableval=$enable_dce;
++fi
++
++if test "$enable_dce" = yes; then
++
++$as_echo "#define DCE 1" >>confdefs.h
++
++fi
++ if test "$enable_dce" = yes; then
++  DCE_TRUE=
++  DCE_FALSE='#'
++else
++  DCE_TRUE='#'
++  DCE_FALSE=
++fi
++
++
++## XXX quite horrible:
++if test -f /etc/ibmcxx.cfg; then
++	dpagaix_ldadd=`sed -n '/^xlc_r4/,/^$/p' /etc/ibmcxx.cfg | sed -n -e '/libraries/{;s/^[^=]*=\(.*\)/\1/;s/,/ /gp;}'`
++	dpagaix_cflags=`sed -n '/^xlc_r4/,/^$/p' /etc/ibmcxx.cfg | sed -n -e '/options/{;s/^[^=]*=\(.*\)/\1/;s/-q^,*//;s/,/ /gp;}'`
++	dpagaix_ldflags=
++else
++	dpagaix_cflags="-D_THREAD_SAFE -D_AIX_PTHREADS_D7 -D_AIX32_THREADS=1 -D_AES_SOURCE -D_AIX41 -I/usr/include/dce"
++	dpagaix_ldadd="-L/usr/lib/threads -ldcelibc_r -ldcepthreads -lpthreads_compat lpthreads -lc_r"
++	dpagaix_ldflags="-Wl,-bI:dfspag.exp"
++fi
++
++
++
++
++# Check whether --enable-afs-support was given.
++if test "${enable_afs_support+set}" = set; then :
++  enableval=$enable_afs_support;
++fi
++
++if test "$enable_afs_support" = no; then
++
++$as_echo "#define NO_AFS 1" >>confdefs.h
++
++	NO_AFS="1"
++fi
++
++
++
++# Check whether --with-berkeley-db was given.
++if test "${with_berkeley_db+set}" = set; then :
++  withval=$with_berkeley_db;
++else
++  with_berkeley_db=check
++fi
++
++
++dbheader=""
++
++# Check whether --with-berkeley-db-include was given.
++if test "${with_berkeley_db_include+set}" = set; then :
++  withval=$with_berkeley_db_include; dbheader=$withval
++else
++  with_berkeley_db_include=check
++fi
++
++
++# Check whether --enable-ndbm-db was given.
++if test "${enable_ndbm_db+set}" = set; then :
++  enableval=$enable_ndbm_db;
++
++fi
++
++
++have_ndbm=no
++db_type=unknown
++
++if test "x$with_berkeley_db" != xno; then :
++  if test "x$with_berkeley_db_include" != xcheck; then :
++  for ac_header in "$dbheader/db.h"
++do :
++  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
++ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" "$ac_includes_default"
++if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
++_ACEOF
++ DBHEADER=$dbheader
++
++
++$as_echo "#define HAVE_DBHEADER 1" >>confdefs.h
++
++
++else
++  if test "x$with_berkeley_db_include" != xcheck; then
++		     { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
++$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
++as_fn_error $? "--with-berkeley-db-include was given but include test failed
++See \`config.log' for more details" "$LINENO" 5 ; }
++		    fi
++
++fi
++
++done
++
++else
++  for ac_header in 					\
++	           db5/db.h				\
++	           db4/db.h				\
++	           db3/db.h				\
++	           db.h					\
++	           db_185.h				\
++
++do :
++  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
++ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" "$ac_includes_default"
++if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++
++done
++
++fi
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for db_create" >&5
++$as_echo_n "checking for db_create... " >&6; }
++if test "${ac_cv_funclib_db_create+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_db_create\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" $dbheader db5 db4 db3 db; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++  #include <stdio.h>
++  #ifdef HAVE_DBHEADER
++  #include <$dbheader/db.h>
++  #elif HAVE_DB5_DB_H
++  #include <db5/db.h>
++  #elif HAVE_DB4_DB_H
++  #include <db4/db.h>
++  #elif defined(HAVE_DB3_DB_H)
++  #include <db3/db.h>
++  #else
++  #include <db.h>
++  #endif
++
++int
++main ()
++{
++db_create(NULL, NULL, 0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_db_create=$ac_lib; else ac_cv_funclib_db_create=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_db_create=\${ac_cv_funclib_db_create-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_db_create"
++
++if false; then
++	for ac_func in db_create
++do :
++  ac_fn_c_check_func "$LINENO" "db_create" "ac_cv_func_db_create"
++if test "x$ac_cv_func_db_create" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_DB_CREATE 1
++_ACEOF
++
++fi
++done
++
++fi
++# db_create
++eval "ac_tr_func=HAVE_`echo db_create | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_db_create=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_db_create=yes"
++	eval "LIB_db_create="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_db_create=no"
++	eval "LIB_db_create="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_db_create=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++  if test "$ac_cv_func_db_create" = "yes"; then
++    db_type=db3
++    if test "$ac_cv_funclib_db_create" != "yes"; then
++      DBLIB="$ac_cv_funclib_db_create"
++    else
++      DBLIB=""
++    fi
++
++$as_echo "#define HAVE_DB3 1" >>confdefs.h
++
++  else
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for dbopen" >&5
++$as_echo_n "checking for dbopen... " >&6; }
++if test "${ac_cv_funclib_dbopen+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_dbopen\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" db2 db; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++    #include <stdio.h>
++    #if defined(HAVE_DB2_DB_H)
++    #include <db2/db.h>
++    #elif defined(HAVE_DB_185_H)
++    #include <db_185.h>
++    #elif defined(HAVE_DB_H)
++    #include <db.h>
++    #else
++    #error no db.h
++    #endif
++
++int
++main ()
++{
++dbopen(NULL, 0, 0, 0, NULL)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_dbopen=$ac_lib; else ac_cv_funclib_dbopen=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_dbopen=\${ac_cv_funclib_dbopen-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_dbopen"
++
++if false; then
++	for ac_func in dbopen
++do :
++  ac_fn_c_check_func "$LINENO" "dbopen" "ac_cv_func_dbopen"
++if test "x$ac_cv_func_dbopen" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_DBOPEN 1
++_ACEOF
++
++fi
++done
++
++fi
++# dbopen
++eval "ac_tr_func=HAVE_`echo dbopen | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_dbopen=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_dbopen=yes"
++	eval "LIB_dbopen="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_dbopen=no"
++	eval "LIB_dbopen="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_dbopen=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++    if test "$ac_cv_func_dbopen" = "yes"; then
++      db_type=db1
++      if test "$ac_cv_funclib_dbopen" != "yes"; then
++        DBLIB="$ac_cv_funclib_dbopen"
++      else
++        DBLIB=""
++      fi
++
++$as_echo "#define HAVE_DB1 1" >>confdefs.h
++
++    fi
++  fi
++
++
++  if test "$ac_cv_func_dbm_firstkey" != yes; then
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for dbm_firstkey" >&5
++$as_echo_n "checking for dbm_firstkey... " >&6; }
++if test "${ac_cv_funclib_dbm_firstkey+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_dbm_firstkey\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in $ac_cv_funclib_dbopen $ac_cv_funclib_db_create; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++    #include <stdio.h>
++    #define DB_DBM_HSEARCH 1
++    #include <db.h>
++    DBM *dbm;
++
++int
++main ()
++{
++dbm_firstkey(NULL)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_dbm_firstkey=$ac_lib; else ac_cv_funclib_dbm_firstkey=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_dbm_firstkey=\${ac_cv_funclib_dbm_firstkey-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_dbm_firstkey"
++
++if false; then
++	for ac_func in dbm_firstkey
++do :
++  ac_fn_c_check_func "$LINENO" "dbm_firstkey" "ac_cv_func_dbm_firstkey"
++if test "x$ac_cv_func_dbm_firstkey" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_DBM_FIRSTKEY 1
++_ACEOF
++
++fi
++done
++
++fi
++# dbm_firstkey
++eval "ac_tr_func=HAVE_`echo dbm_firstkey | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_dbm_firstkey=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_dbm_firstkey=yes"
++	eval "LIB_dbm_firstkey="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_dbm_firstkey=no"
++	eval "LIB_dbm_firstkey="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_dbm_firstkey=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++    if test "$ac_cv_func_dbm_firstkey" = "yes"; then
++      if test "$ac_cv_funclib_dbm_firstkey" != "yes"; then
++        LIB_NDBM="$ac_cv_funclib_dbm_firstkey"
++      else
++        LIB_NDBM=""
++      fi
++
++$as_echo "#define HAVE_DB_NDBM 1" >>confdefs.h
++
++
++$as_echo "#define HAVE_NEW_DB 1" >>confdefs.h
++
++    else
++      $as_unset ac_cv_func_dbm_firstkey
++      $as_unset ac_cv_funclib_dbm_firstkey
++    fi
++  fi
++
++
++fi # fi berkeley db
++
++if test "$enable_ndbm_db" != "no"; then
++
++  if test "$db_type" = "unknown" -o "$ac_cv_func_dbm_firstkey" = ""; then
++
++    for ac_header in 				\
++  	dbm.h					\
++  	ndbm.h					\
++
++do :
++  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
++ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" "$ac_includes_default"
++if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++
++done
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for dbm_firstkey" >&5
++$as_echo_n "checking for dbm_firstkey... " >&6; }
++if test "${ac_cv_funclib_dbm_firstkey+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_dbm_firstkey\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" ndbm; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++    #include <stdio.h>
++    #if defined(HAVE_NDBM_H)
++    #include <ndbm.h>
++    #elif defined(HAVE_DBM_H)
++    #include <dbm.h>
++    #endif
++    DBM *dbm;
++
++int
++main ()
++{
++dbm_firstkey(NULL)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_dbm_firstkey=$ac_lib; else ac_cv_funclib_dbm_firstkey=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_dbm_firstkey=\${ac_cv_funclib_dbm_firstkey-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_dbm_firstkey"
++
++if false; then
++	for ac_func in dbm_firstkey
++do :
++  ac_fn_c_check_func "$LINENO" "dbm_firstkey" "ac_cv_func_dbm_firstkey"
++if test "x$ac_cv_func_dbm_firstkey" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_DBM_FIRSTKEY 1
++_ACEOF
++
++fi
++done
++
++fi
++# dbm_firstkey
++eval "ac_tr_func=HAVE_`echo dbm_firstkey | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_dbm_firstkey=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_dbm_firstkey=yes"
++	eval "LIB_dbm_firstkey="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_dbm_firstkey=no"
++	eval "LIB_dbm_firstkey="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_dbm_firstkey=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++    if test "$ac_cv_func_dbm_firstkey" = "yes"; then
++      if test "$ac_cv_funclib_dbm_firstkey" != "yes"; then
++        LIB_NDBM="$ac_cv_funclib_dbm_firstkey"
++      else
++        LIB_NDBM=""
++      fi
++
++$as_echo "#define HAVE_NDBM 1" >>confdefs.h
++      have_ndbm=yes
++      if test "$db_type" = "unknown"; then
++        db_type=ndbm
++        DBLIB="$LIB_NDBM"
++      fi
++    else
++
++      $as_unset ac_cv_func_dbm_firstkey
++      $as_unset ac_cv_funclib_dbm_firstkey
++
++      for ac_header in 				\
++  	  gdbm/ndbm.h				\
++
++do :
++  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
++ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" "$ac_includes_default"
++if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++
++done
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for dbm_firstkey" >&5
++$as_echo_n "checking for dbm_firstkey... " >&6; }
++if test "${ac_cv_funclib_dbm_firstkey+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_dbm_firstkey\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" gdbm; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++      #include <stdio.h>
++      #include <gdbm/ndbm.h>
++      DBM *dbm;
++
++int
++main ()
++{
++dbm_firstkey(NULL)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_dbm_firstkey=$ac_lib; else ac_cv_funclib_dbm_firstkey=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_dbm_firstkey=\${ac_cv_funclib_dbm_firstkey-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_dbm_firstkey"
++
++if false; then
++	for ac_func in dbm_firstkey
++do :
++  ac_fn_c_check_func "$LINENO" "dbm_firstkey" "ac_cv_func_dbm_firstkey"
++if test "x$ac_cv_func_dbm_firstkey" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_DBM_FIRSTKEY 1
++_ACEOF
++
++fi
++done
++
++fi
++# dbm_firstkey
++eval "ac_tr_func=HAVE_`echo dbm_firstkey | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_dbm_firstkey=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_dbm_firstkey=yes"
++	eval "LIB_dbm_firstkey="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_dbm_firstkey=no"
++	eval "LIB_dbm_firstkey="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_dbm_firstkey=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++      if test "$ac_cv_func_dbm_firstkey" = "yes"; then
++        if test "$ac_cv_funclib_dbm_firstkey" != "yes"; then
++  	LIB_NDBM="$ac_cv_funclib_dbm_firstkey"
++        else
++  	LIB_NDBM=""
++        fi
++
++$as_echo "#define HAVE_NDBM 1" >>confdefs.h
++        have_ndbm=yes
++        if test "$db_type" = "unknown"; then
++  	db_type=ndbm
++  	DBLIB="$LIB_NDBM"
++        fi
++      fi
++    fi
++  fi #enable_ndbm_db
++fi # unknown
++
++if test "$have_ndbm" = "yes"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking if ndbm is implemented with db" >&5
++$as_echo_n "checking if ndbm is implemented with db... " >&6; }
++  if test "$cross_compiling" = yes; then :
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no-cross" >&5
++$as_echo "no-cross" >&6; }
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <unistd.h>
++#include <fcntl.h>
++#if defined(HAVE_GDBM_NDBM_H)
++#include <gdbm/ndbm.h>
++#elif defined(HAVE_NDBM_H)
++#include <ndbm.h>
++#elif defined(HAVE_DBM_H)
++#include <dbm.h>
++#endif
++int main(int argc, char **argv)
++{
++  DBM *d;
++
++  d = dbm_open("conftest", O_RDWR | O_CREAT, 0666);
++  if (d == NULL)
++    return 1;
++  dbm_close(d);
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_run "$LINENO"; then :
++
++    if test -f conftest.db; then
++      { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++
++$as_echo "#define HAVE_NEW_DB 1" >>confdefs.h
++
++    else
++      { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++    fi
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
++  conftest.$ac_objext conftest.beam conftest.$ac_ext
++fi
++
++fi
++
++ if test "$db_type" = db1; then
++  HAVE_DB1_TRUE=
++  HAVE_DB1_FALSE='#'
++else
++  HAVE_DB1_TRUE='#'
++  HAVE_DB1_FALSE=
++fi
++ if test "$db_type" = db3; then
++  HAVE_DB3_TRUE=
++  HAVE_DB3_FALSE='#'
++else
++  HAVE_DB3_TRUE='#'
++  HAVE_DB3_FALSE=
++fi
++ if test "$db_type" = ndbm; then
++  HAVE_NDBM_TRUE=
++  HAVE_NDBM_FALSE='#'
++else
++  HAVE_NDBM_TRUE='#'
++  HAVE_NDBM_FALSE=
++fi
++ if test "$dbheader" != ""; then
++  HAVE_DBHEADER_TRUE=
++  HAVE_DBHEADER_FALSE='#'
++else
++  HAVE_DBHEADER_TRUE='#'
++  HAVE_DBHEADER_FALSE=
++fi
++
++## it's probably not correct to include LDFLAGS here, but we might
++## need it, for now just add any possible -L
++z=""
++for i in $LDFLAGS; do
++	case "$i" in
++	-L*) z="$z $i";;
++	esac
++done
++DBLIB="$z $DBLIB"
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for inline" >&5
++$as_echo_n "checking for inline... " >&6; }
++if test "${ac_cv_c_inline+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_cv_c_inline=no
++for ac_kw in inline __inline__ __inline; do
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifndef __cplusplus
++typedef int foo_t;
++static $ac_kw foo_t static_foo () {return 0; }
++$ac_kw foo_t foo () {return 0; }
++#endif
++
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_c_inline=$ac_kw
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++  test "$ac_cv_c_inline" != no && break
++done
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_c_inline" >&5
++$as_echo "$ac_cv_c_inline" >&6; }
++
++case $ac_cv_c_inline in
++  inline | yes) ;;
++  *)
++    case $ac_cv_c_inline in
++      no) ac_val=;;
++      *) ac_val=$ac_cv_c_inline;;
++    esac
++    cat >>confdefs.h <<_ACEOF
++#ifndef __cplusplus
++#define inline $ac_val
++#endif
++_ACEOF
++    ;;
++esac
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for an ANSI C-conforming const" >&5
++$as_echo_n "checking for an ANSI C-conforming const... " >&6; }
++if test "${ac_cv_c_const+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++/* FIXME: Include the comments suggested by Paul. */
++#ifndef __cplusplus
++  /* Ultrix mips cc rejects this.  */
++  typedef int charset[2];
++  const charset cs;
++  /* SunOS 4.1.1 cc rejects this.  */
++  char const *const *pcpcc;
++  char **ppc;
++  /* NEC SVR4.0.2 mips cc rejects this.  */
++  struct point {int x, y;};
++  static struct point const zero = {0,0};
++  /* AIX XL C 1.02.0.0 rejects this.
++     It does not let you subtract one const X* pointer from another in
++     an arm of an if-expression whose if-part is not a constant
++     expression */
++  const char *g = "string";
++  pcpcc = &g + (g ? g-g : 0);
++  /* HPUX 7.0 cc rejects these. */
++  ++pcpcc;
++  ppc = (char**) pcpcc;
++  pcpcc = (char const *const *) ppc;
++  { /* SCO 3.2v4 cc rejects this.  */
++    char *t;
++    char const *s = 0 ? (char *) 0 : (char const *) 0;
++
++    *t++ = 0;
++    if (s) return 0;
++  }
++  { /* Someone thinks the Sun supposedly-ANSI compiler will reject this.  */
++    int x[] = {25, 17};
++    const int *foo = &x[0];
++    ++foo;
++  }
++  { /* Sun SC1.0 ANSI compiler rejects this -- but not the above. */
++    typedef const int *iptr;
++    iptr p = 0;
++    ++p;
++  }
++  { /* AIX XL C 1.02.0.0 rejects this saying
++       "k.c", line 2.27: 1506-025 (S) Operand must be a modifiable lvalue. */
++    struct s { int j; const int *ap[3]; };
++    struct s *b; b->j = 5;
++  }
++  { /* ULTRIX-32 V3.1 (Rev 9) vcc rejects this */
++    const int foo = 10;
++    if (!foo) return 0;
++  }
++  return !cs[0] && !zero.x;
++#endif
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_c_const=yes
++else
++  ac_cv_c_const=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_c_const" >&5
++$as_echo "$ac_cv_c_const" >&6; }
++if test $ac_cv_c_const = no; then
++
++$as_echo "#define const /**/" >>confdefs.h
++
++fi
++
++ac_fn_c_check_type "$LINENO" "size_t" "ac_cv_type_size_t" "$ac_includes_default"
++if test "x$ac_cv_type_size_t" = x""yes; then :
++
++else
++
++cat >>confdefs.h <<_ACEOF
++#define size_t unsigned int
++_ACEOF
++
++fi
++
++ac_fn_c_check_type "$LINENO" "pid_t" "ac_cv_type_pid_t" "$ac_includes_default"
++if test "x$ac_cv_type_pid_t" = x""yes; then :
++
++else
++
++cat >>confdefs.h <<_ACEOF
++#define pid_t int
++_ACEOF
++
++fi
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for uid_t in sys/types.h" >&5
++$as_echo_n "checking for uid_t in sys/types.h... " >&6; }
++if test "${ac_cv_type_uid_t+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sys/types.h>
++
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "uid_t" >/dev/null 2>&1; then :
++  ac_cv_type_uid_t=yes
++else
++  ac_cv_type_uid_t=no
++fi
++rm -f conftest*
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_uid_t" >&5
++$as_echo "$ac_cv_type_uid_t" >&6; }
++if test $ac_cv_type_uid_t = no; then
++
++$as_echo "#define uid_t int" >>confdefs.h
++
++
++$as_echo "#define gid_t int" >>confdefs.h
++
++fi
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking return type of signal handlers" >&5
++$as_echo_n "checking return type of signal handlers... " >&6; }
++if test "${ac_cv_type_signal+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sys/types.h>
++#include <signal.h>
++
++int
++main ()
++{
++return *(signal (0, 0)) (0) == 1;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_signal=int
++else
++  ac_cv_type_signal=void
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_signal" >&5
++$as_echo "$ac_cv_type_signal" >&6; }
++
++cat >>confdefs.h <<_ACEOF
++#define RETSIGTYPE $ac_cv_type_signal
++_ACEOF
++
++
++if test "$ac_cv_type_signal" = "void" ; then
++
++$as_echo "#define VOID_RETSIGTYPE 1" >>confdefs.h
++
++fi
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether time.h and sys/time.h may both be included" >&5
++$as_echo_n "checking whether time.h and sys/time.h may both be included... " >&6; }
++if test "${ac_cv_header_time+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sys/types.h>
++#include <sys/time.h>
++#include <time.h>
++
++int
++main ()
++{
++if ((struct tm *) 0)
++return 0;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_header_time=yes
++else
++  ac_cv_header_time=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_header_time" >&5
++$as_echo "$ac_cv_header_time" >&6; }
++if test $ac_cv_header_time = yes; then
++
++$as_echo "#define TIME_WITH_SYS_TIME 1" >>confdefs.h
++
++fi
++
++
++for ac_header in standards.h
++do :
++  ac_fn_c_check_header_mongrel "$LINENO" "standards.h" "ac_cv_header_standards_h" "$ac_includes_default"
++if test "x$ac_cv_header_standards_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_STANDARDS_H 1
++_ACEOF
++
++fi
++
++done
++
++for i in netinet/ip.h netinet/tcp.h; do
++
++cv=`echo "$i" | sed 'y%./+-%__p_%'`
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $i" >&5
++$as_echo_n "checking for $i... " >&6; }
++if eval "test \"\${ac_cv_header_$cv+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_STANDARDS_H
++#include <standards.h>
++#endif
++#include <$i>
++
++_ACEOF
++if ac_fn_c_try_cpp "$LINENO"; then :
++  eval "ac_cv_header_$cv=yes"
++else
++  eval "ac_cv_header_$cv=no"
++fi
++rm -f conftest.err conftest.i conftest.$ac_ext
++fi
++eval ac_res=\$ac_cv_header_$cv
++	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
++$as_echo "$ac_res" >&6; }
++ac_res=`eval echo \\$ac_cv_header_$cv`
++if test "$ac_res" = yes; then
++	ac_tr_hdr=HAVE_`echo $i | sed 'y%abcdefghijklmnopqrstuvwxyz./-%ABCDEFGHIJKLMNOPQRSTUVWXYZ___%'`
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_hdr 1
++_ACEOF
++
++fi
++done
++if false;then
++	for ac_header in netinet/ip.h netinet/tcp.h
++do :
++  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
++ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" "$ac_includes_default"
++if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++
++done
++
++fi
++
++
++for ac_func in getlogin setlogin
++do :
++  as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
++ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var"
++if eval test \"x\$"$as_ac_var"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++done
++
++if test "$ac_cv_func_getlogin" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if getlogin is posix" >&5
++$as_echo_n "checking if getlogin is posix... " >&6; }
++if test "${ac_cv_func_getlogin_posix+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if test "$ac_cv_func_getlogin" = yes -a "$ac_cv_func_setlogin" = yes; then
++	ac_cv_func_getlogin_posix=no
++else
++	ac_cv_func_getlogin_posix=yes
++fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_getlogin_posix" >&5
++$as_echo "$ac_cv_func_getlogin_posix" >&6; }
++if test "$ac_cv_func_getlogin_posix" = yes; then
++
++$as_echo "#define POSIX_GETLOGIN 1" >>confdefs.h
++
++fi
++fi
++
++
++
++
++  for ac_header in $ac_header_list
++do :
++  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
++ac_fn_c_check_header_compile "$LINENO" "$ac_header" "$as_ac_Header" "$ac_includes_default
++"
++if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++
++done
++
++
++
++
++
++
++
++
++for ac_func in getpagesize
++do :
++  ac_fn_c_check_func "$LINENO" "getpagesize" "ac_cv_func_getpagesize"
++if test "x$ac_cv_func_getpagesize" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_GETPAGESIZE 1
++_ACEOF
++
++fi
++done
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mmap" >&5
++$as_echo_n "checking for working mmap... " >&6; }
++if test "${ac_cv_func_mmap_fixed_mapped+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test "$cross_compiling" = yes; then :
++  ac_cv_func_mmap_fixed_mapped=no
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++$ac_includes_default
++/* malloc might have been renamed as rpl_malloc. */
++#undef malloc
++
++/* Thanks to Mike Haertel and Jim Avera for this test.
++   Here is a matrix of mmap possibilities:
++	mmap private not fixed
++	mmap private fixed at somewhere currently unmapped
++	mmap private fixed at somewhere already mapped
++	mmap shared not fixed
++	mmap shared fixed at somewhere currently unmapped
++	mmap shared fixed at somewhere already mapped
++   For private mappings, we should verify that changes cannot be read()
++   back from the file, nor mmap's back from the file at a different
++   address.  (There have been systems where private was not correctly
++   implemented like the infamous i386 svr4.0, and systems where the
++   VM page cache was not coherent with the file system buffer cache
++   like early versions of FreeBSD and possibly contemporary NetBSD.)
++   For shared mappings, we should conversely verify that changes get
++   propagated back to all the places they're supposed to be.
++
++   Grep wants private fixed already mapped.
++   The main things grep needs to know about mmap are:
++   * does it exist and is it safe to write into the mmap'd area
++   * how to use it (BSD variants)  */
++
++#include <fcntl.h>
++#include <sys/mman.h>
++
++#if !defined STDC_HEADERS && !defined HAVE_STDLIB_H
++char *malloc ();
++#endif
++
++/* This mess was copied from the GNU getpagesize.h.  */
++#ifndef HAVE_GETPAGESIZE
++# ifdef _SC_PAGESIZE
++#  define getpagesize() sysconf(_SC_PAGESIZE)
++# else /* no _SC_PAGESIZE */
++#  ifdef HAVE_SYS_PARAM_H
++#   include <sys/param.h>
++#   ifdef EXEC_PAGESIZE
++#    define getpagesize() EXEC_PAGESIZE
++#   else /* no EXEC_PAGESIZE */
++#    ifdef NBPG
++#     define getpagesize() NBPG * CLSIZE
++#     ifndef CLSIZE
++#      define CLSIZE 1
++#     endif /* no CLSIZE */
++#    else /* no NBPG */
++#     ifdef NBPC
++#      define getpagesize() NBPC
++#     else /* no NBPC */
++#      ifdef PAGESIZE
++#       define getpagesize() PAGESIZE
++#      endif /* PAGESIZE */
++#     endif /* no NBPC */
++#    endif /* no NBPG */
++#   endif /* no EXEC_PAGESIZE */
++#  else /* no HAVE_SYS_PARAM_H */
++#   define getpagesize() 8192	/* punt totally */
++#  endif /* no HAVE_SYS_PARAM_H */
++# endif /* no _SC_PAGESIZE */
++
++#endif /* no HAVE_GETPAGESIZE */
++
++int
++main ()
++{
++  char *data, *data2, *data3;
++  const char *cdata2;
++  int i, pagesize;
++  int fd, fd2;
++
++  pagesize = getpagesize ();
++
++  /* First, make a file with some known garbage in it. */
++  data = (char *) malloc (pagesize);
++  if (!data)
++    return 1;
++  for (i = 0; i < pagesize; ++i)
++    *(data + i) = rand ();
++  umask (0);
++  fd = creat ("conftest.mmap", 0600);
++  if (fd < 0)
++    return 2;
++  if (write (fd, data, pagesize) != pagesize)
++    return 3;
++  close (fd);
++
++  /* Next, check that the tail of a page is zero-filled.  File must have
++     non-zero length, otherwise we risk SIGBUS for entire page.  */
++  fd2 = open ("conftest.txt", O_RDWR | O_CREAT | O_TRUNC, 0600);
++  if (fd2 < 0)
++    return 4;
++  cdata2 = "";
++  if (write (fd2, cdata2, 1) != 1)
++    return 5;
++  data2 = (char *) mmap (0, pagesize, PROT_READ | PROT_WRITE, MAP_SHARED, fd2, 0L);
++  if (data2 == MAP_FAILED)
++    return 6;
++  for (i = 0; i < pagesize; ++i)
++    if (*(data2 + i))
++      return 7;
++  close (fd2);
++  if (munmap (data2, pagesize))
++    return 8;
++
++  /* Next, try to mmap the file at a fixed address which already has
++     something else allocated at it.  If we can, also make sure that
++     we see the same garbage.  */
++  fd = open ("conftest.mmap", O_RDWR);
++  if (fd < 0)
++    return 9;
++  if (data2 != mmap (data2, pagesize, PROT_READ | PROT_WRITE,
++		     MAP_PRIVATE | MAP_FIXED, fd, 0L))
++    return 10;
++  for (i = 0; i < pagesize; ++i)
++    if (*(data + i) != *(data2 + i))
++      return 11;
++
++  /* Finally, make sure that changes to the mapped area do not
++     percolate back to the file as seen by read().  (This is a bug on
++     some variants of i386 svr4.0.)  */
++  for (i = 0; i < pagesize; ++i)
++    *(data2 + i) = *(data2 + i) + 1;
++  data3 = (char *) malloc (pagesize);
++  if (!data3)
++    return 12;
++  if (read (fd, data3, pagesize) != pagesize)
++    return 13;
++  for (i = 0; i < pagesize; ++i)
++    if (*(data + i) != *(data3 + i))
++      return 14;
++  close (fd);
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_run "$LINENO"; then :
++  ac_cv_func_mmap_fixed_mapped=yes
++else
++  ac_cv_func_mmap_fixed_mapped=no
++fi
++rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
++  conftest.$ac_objext conftest.beam conftest.$ac_ext
++fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_mmap_fixed_mapped" >&5
++$as_echo "$ac_cv_func_mmap_fixed_mapped" >&6; }
++if test $ac_cv_func_mmap_fixed_mapped = yes; then
++
++$as_echo "#define HAVE_MMAP 1" >>confdefs.h
++
++fi
++rm -f conftest.mmap conftest.txt
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if realloc if broken" >&5
++$as_echo_n "checking if realloc if broken... " >&6; }
++if test "${ac_cv_func_realloc_broken+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++ac_cv_func_realloc_broken=no
++if test "$cross_compiling" = yes; then :
++  :
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <stddef.h>
++#include <stdlib.h>
++
++int main(int argc, char **argv)
++{
++	return realloc(NULL, 17) == NULL;
++}
++
++_ACEOF
++if ac_fn_c_try_run "$LINENO"; then :
++  :
++else
++  ac_cv_func_realloc_broken=yes
++fi
++rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
++  conftest.$ac_objext conftest.beam conftest.$ac_ext
++fi
++
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_realloc_broken" >&5
++$as_echo "$ac_cv_func_realloc_broken" >&6; }
++if test "$ac_cv_func_realloc_broken" = yes ; then
++
++$as_echo "#define BROKEN_REALLOC 1" >>confdefs.h
++
++fi
++
++
++
++
++
++
++DIR_roken=roken
++LIB_roken='$(top_builddir)/lib/roken/libroken.la'
++INCLUDES_roken='-I$(top_builddir)/lib/roken -I$(top_srcdir)/lib/roken'
++
++
++
++
++
++
++
++
++
++
++$as_echo "#define rk_PATH_DELIM '/'" >>confdefs.h
++
++
++
++
++
++
++
++
++# Check whether --enable-developer was given.
++if test "${enable_developer+set}" = set; then :
++  enableval=$enable_developer;
++fi
++
++if test "X$enable_developer" = Xyes; then
++    dwflags="-Werror"
++fi
++
++WFLAGS_NOUNUSED=""
++WFLAGS_NOIMPLICITINT=""
++if test -z "$WFLAGS" -a "$GCC" = "yes"; then
++  # -Wno-implicit-int for broken X11 headers
++  # leave these out for now:
++  #   -Wcast-align doesn't work well on alpha osf/1
++  #   -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast
++  #   -Wmissing-declarations -Wnested-externs
++  #   -Wstrict-overflow=5
++  WFLAGS="-Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs $dwflags"
++  WFLAGS_NOUNUSED="-Wno-unused"
++  WFLAGS_NOIMPLICITINT="-Wno-implicit-int"
++fi
++
++
++
++
++
++
++
++
++cv=`echo "ssize_t" | sed 'y%./+- %__p__%'`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ssize_t" >&5
++$as_echo_n "checking for ssize_t... " >&6; }
++if eval "test \"\${ac_cv_type_$cv+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/types.h>
++#if STDC_HEADERS
++#include <stdlib.h>
++#include <stddef.h>
++#endif
++#include <unistd.h>
++int
++main ()
++{
++ssize_t foo;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_type_$cv=yes"
++else
++  eval "ac_cv_type_$cv=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++ac_foo=`eval echo \\$ac_cv_type_$cv`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++  ac_tr_hdr=HAVE_`echo ssize_t | sed 'y%abcdefghijklmnopqrstuvwxyz./- %ABCDEFGHIJKLMNOPQRSTUVWXYZ____%'`
++if false; then
++	ac_fn_c_check_type "$LINENO" "ssize_t" "ac_cv_type_ssize_t" "$ac_includes_default"
++if test "x$ac_cv_type_ssize_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_SSIZE_T 1
++_ACEOF
++
++
++fi
++
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define $ac_tr_hdr 1
++_ACEOF
++
++fi
++
++
++
++
++
++cv=`echo "long long" | sed 'y%./+- %__p__%'`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for long long" >&5
++$as_echo_n "checking for long long... " >&6; }
++if eval "test \"\${ac_cv_type_$cv+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/types.h>
++#if STDC_HEADERS
++#include <stdlib.h>
++#include <stddef.h>
++#endif
++
++int
++main ()
++{
++long long foo;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_type_$cv=yes"
++else
++  eval "ac_cv_type_$cv=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++ac_foo=`eval echo \\$ac_cv_type_$cv`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++  ac_tr_hdr=HAVE_`echo long long | sed 'y%abcdefghijklmnopqrstuvwxyz./- %ABCDEFGHIJKLMNOPQRSTUVWXYZ____%'`
++if false; then
++	ac_fn_c_check_type "$LINENO" "long long" "ac_cv_type_long_long" "$ac_includes_default"
++if test "x$ac_cv_type_long_long" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_LONG_LONG 1
++_ACEOF
++
++
++fi
++
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define $ac_tr_hdr 1
++_ACEOF
++
++fi
++
++
++
++
++
++
++
++for ac_header in \
++	arpa/inet.h				\
++	config.h				\
++	crypt.h					\
++	dirent.h				\
++	errno.h					\
++	err.h					\
++	fcntl.h					\
++	fnmatch.h				\
++	grp.h					\
++	ifaddrs.h				\
++	netinet/in.h				\
++	netinet/in6.h				\
++	netinet/in_systm.h			\
++	netinet6/in6.h				\
++	paths.h					\
++	poll.h					\
++	pwd.h					\
++	rpcsvc/ypclnt.h				\
++	shadow.h				\
++	stdint.h				\
++	sys/bswap.h				\
++	sys/ioctl.h				\
++	sys/mman.h				\
++	sys/param.h				\
++	sys/resource.h				\
++	sys/sockio.h				\
++	sys/stat.h				\
++	sys/time.h				\
++	sys/tty.h				\
++	sys/types.h				\
++	sys/uio.h				\
++	sys/utsname.h				\
++	sys/wait.h				\
++	syslog.h				\
++	termios.h				\
++	winsock2.h				\
++	ws2tcpip.h				\
++	unistd.h				\
++	userconf.h				\
++	usersec.h				\
++	util.h					\
++
++do :
++  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
++ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" "$ac_includes_default"
++if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++
++done
++
++
++
++
++cv=`echo "uintptr_t" | sed 'y%./+- %__p__%'`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for uintptr_t" >&5
++$as_echo_n "checking for uintptr_t... " >&6; }
++if eval "test \"\${ac_cv_type_$cv+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/types.h>
++#if STDC_HEADERS
++#include <stdlib.h>
++#include <stddef.h>
++#endif
++#ifdef HAVE_STDINT_H
++#include <stdint.h>
++#endif
++int
++main ()
++{
++uintptr_t foo;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_type_$cv=yes"
++else
++  eval "ac_cv_type_$cv=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++ac_foo=`eval echo \\$ac_cv_type_$cv`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++  ac_tr_hdr=HAVE_`echo uintptr_t | sed 'y%abcdefghijklmnopqrstuvwxyz./- %ABCDEFGHIJKLMNOPQRSTUVWXYZ____%'`
++if false; then
++	ac_fn_c_check_type "$LINENO" "uintptr_t" "ac_cv_type_uintptr_t" "$ac_includes_default"
++if test "x$ac_cv_type_uintptr_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_UINTPTR_T 1
++_ACEOF
++
++
++fi
++
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define $ac_tr_hdr 1
++_ACEOF
++
++fi
++
++
++for ac_header in vis.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "vis.h" "ac_cv_header_vis_h" "
++#include <vis.h>
++#ifndef VIS_SP
++#error invis
++#endif
++"
++if test "x$ac_cv_header_vis_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_VIS_H 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in netdb.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "netdb.h" "ac_cv_header_netdb_h" "$ac_includes_default
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++
++"
++if test "x$ac_cv_header_netdb_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_NETDB_H 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in sys/socket.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "sys/socket.h" "ac_cv_header_sys_socket_h" "$ac_includes_default
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++
++"
++if test "x$ac_cv_header_sys_socket_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_SYS_SOCKET_H 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in net/if.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "net/if.h" "ac_cv_header_net_if_h" "$ac_includes_default
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#if HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++"
++if test "x$ac_cv_header_net_if_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_NET_IF_H 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in netinet6/in6_var.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "netinet6/in6_var.h" "ac_cv_header_netinet6_in6_var_h" "$ac_includes_default
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#if HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_NETINET6_IN6_H
++#include <netinet6/in6.h>
++#endif
++
++"
++if test "x$ac_cv_header_netinet6_in6_var_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_NETINET6_IN6_VAR_H 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in sys/sysctl.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "sys/sysctl.h" "ac_cv_header_sys_sysctl_h" "$ac_includes_default
++#ifdef HAVE_SYS_PARAM_H
++#include <sys/param.h>
++#endif
++
++"
++if test "x$ac_cv_header_sys_sysctl_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_SYS_SYSCTL_H 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in sys/proc.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "sys/proc.h" "ac_cv_header_sys_proc_h" "$ac_includes_default
++#ifdef HAVE_SYS_PARAM_H
++#include <sys/param.h>
++#endif
++
++"
++if test "x$ac_cv_header_sys_proc_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_SYS_PROC_H 1
++_ACEOF
++
++fi
++
++done
++
++
++
++
++ if test "$ac_cv_header_err_h" = yes; then
++  have_err_h_TRUE=
++  have_err_h_FALSE='#'
++else
++  have_err_h_TRUE='#'
++  have_err_h_FALSE=
++fi
++
++ if test "$ac_cv_header_ifaddrs_h" = yes; then
++  have_ifaddrs_h_TRUE=
++  have_ifaddrs_h_FALSE='#'
++else
++  have_ifaddrs_h_TRUE='#'
++  have_ifaddrs_h_FALSE=
++fi
++
++ if test "$ac_cv_header_vis_h" = yes; then
++  have_vis_h_TRUE=
++  have_vis_h_FALSE='#'
++else
++  have_vis_h_TRUE='#'
++  have_vis_h_FALSE=
++fi
++
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for socket" >&5
++$as_echo_n "checking for socket... " >&6; }
++if test "${ac_cv_funclib_socket+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_socket\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" socket; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++socket()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_socket=$ac_lib; else ac_cv_funclib_socket=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_socket=\${ac_cv_funclib_socket-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_socket"
++
++if false; then
++	for ac_func in socket
++do :
++  ac_fn_c_check_func "$LINENO" "socket" "ac_cv_func_socket"
++if test "x$ac_cv_func_socket" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_SOCKET 1
++_ACEOF
++
++fi
++done
++
++fi
++# socket
++eval "ac_tr_func=HAVE_`echo socket | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_socket=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_socket=yes"
++	eval "LIB_socket="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_socket=no"
++	eval "LIB_socket="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_socket=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test -n "$LIB_socket"; then
++	LIBS="$LIB_socket $LIBS"
++fi
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for gethostbyname" >&5
++$as_echo_n "checking for gethostbyname... " >&6; }
++if test "${ac_cv_funclib_gethostbyname+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_gethostbyname\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" nsl; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++gethostbyname()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_gethostbyname=$ac_lib; else ac_cv_funclib_gethostbyname=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_gethostbyname=\${ac_cv_funclib_gethostbyname-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_gethostbyname"
++
++if false; then
++	for ac_func in gethostbyname
++do :
++  ac_fn_c_check_func "$LINENO" "gethostbyname" "ac_cv_func_gethostbyname"
++if test "x$ac_cv_func_gethostbyname" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_GETHOSTBYNAME 1
++_ACEOF
++
++fi
++done
++
++fi
++# gethostbyname
++eval "ac_tr_func=HAVE_`echo gethostbyname | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_gethostbyname=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_gethostbyname=yes"
++	eval "LIB_gethostbyname="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_gethostbyname=no"
++	eval "LIB_gethostbyname="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_gethostbyname=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test -n "$LIB_gethostbyname"; then
++	LIBS="$LIB_gethostbyname $LIBS"
++fi
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for syslog" >&5
++$as_echo_n "checking for syslog... " >&6; }
++if test "${ac_cv_funclib_syslog+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_syslog\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" syslog; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++syslog()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_syslog=$ac_lib; else ac_cv_funclib_syslog=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_syslog=\${ac_cv_funclib_syslog-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_syslog"
++
++if false; then
++	for ac_func in syslog
++do :
++  ac_fn_c_check_func "$LINENO" "syslog" "ac_cv_func_syslog"
++if test "x$ac_cv_func_syslog" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_SYSLOG 1
++_ACEOF
++
++fi
++done
++
++fi
++# syslog
++eval "ac_tr_func=HAVE_`echo syslog | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_syslog=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_syslog=yes"
++	eval "LIB_syslog="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_syslog=no"
++	eval "LIB_syslog="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_syslog=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test -n "$LIB_syslog"; then
++	LIBS="$LIB_syslog $LIBS"
++fi
++
++
++
++
++# Check whether --with-ipv6 was given.
++if test "${with_ipv6+set}" = set; then :
++  withval=$with_ipv6;
++        ac_cv_lib_ipv6="$withval"
++
++fi
++
++save_CFLAGS="${CFLAGS}"
++
++if test "X$ac_cv_lib_ipv6" != "Xno"; then
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for IPv6 stack type" >&5
++$as_echo_n "checking for IPv6 stack type... " >&6; }
++if test "${rk_cv_v6type+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  	v6type=unknown
++	v6lib=none
++
++	for i in v6d toshiba kame inria zeta linux; do
++		case $i in
++		v6d)
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include </usr/local/v6/include/sys/types.h>
++#ifdef __V6D__
++yes
++#endif
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "yes" >/dev/null 2>&1; then :
++  v6type=$i; v6lib=v6;
++				v6libdir=/usr/local/v6/lib;
++				CFLAGS="-I/usr/local/v6/include $CFLAGS"
++fi
++rm -f conftest*
++
++			;;
++		toshiba)
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/param.h>
++#ifdef _TOSHIBA_INET6
++yes
++#endif
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "yes" >/dev/null 2>&1; then :
++  v6type=$i; v6lib=inet6;
++				v6libdir=/usr/local/v6/lib;
++				CFLAGS="-DINET6 $CFLAGS"
++fi
++rm -f conftest*
++
++			;;
++		kame)
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <netinet/in.h>
++#ifdef __KAME__
++yes
++#endif
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "yes" >/dev/null 2>&1; then :
++  v6type=$i; v6lib=inet6;
++				v6libdir=/usr/local/v6/lib;
++				CFLAGS="-DINET6 $CFLAGS"
++fi
++rm -f conftest*
++
++			;;
++		inria)
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <netinet/in.h>
++#ifdef IPV6_INRIA_VERSION
++yes
++#endif
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "yes" >/dev/null 2>&1; then :
++  v6type=$i; CFLAGS="-DINET6 $CFLAGS"
++fi
++rm -f conftest*
++
++			;;
++		zeta)
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/param.h>
++#ifdef _ZETA_MINAMI_INET6
++yes
++#endif
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "yes" >/dev/null 2>&1; then :
++  v6type=$i; v6lib=inet6;
++				v6libdir=/usr/local/v6/lib;
++				CFLAGS="-DINET6 $CFLAGS"
++fi
++rm -f conftest*
++
++			;;
++		linux)
++			if test -d /usr/inet6; then
++				v6type=$i
++				v6lib=inet6
++				v6libdir=/usr/inet6
++				CFLAGS="-DINET6 $CFLAGS"
++			fi
++			;;
++		esac
++		if test "$v6type" != "unknown"; then
++			break
++		fi
++	done
++
++	if test "$v6lib" != "none"; then
++		for dir in $v6libdir /usr/local/v6/lib /usr/local/lib; do
++			if test -d $dir -a -f $dir/lib$v6lib.a; then
++				LIBS="-L$dir -l$v6lib $LIBS"
++				break
++			fi
++		done
++	fi
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $rk_cv_v6type" >&5
++$as_echo "$rk_cv_v6type" >&6; }
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for IPv6" >&5
++$as_echo_n "checking for IPv6... " >&6; }
++if test "${rk_cv_lib_ipv6+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++	cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_NETINET_IN6_H
++#include <netinet/in6.h>
++#endif
++
++int
++main ()
++{
++
++ struct sockaddr_in6 sin6;
++ int s;
++
++ s = socket(AF_INET6, SOCK_DGRAM, 0);
++
++ sin6.sin6_family = AF_INET6;
++ sin6.sin6_port = htons(17);
++ sin6.sin6_addr = in6addr_any;
++ bind(s, (struct sockaddr *)&sin6, sizeof(sin6));
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_ipv6=yes
++else
++  ac_cv_lib_ipv6=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $rk_cv_lib_ipv6" >&5
++$as_echo "$rk_cv_lib_ipv6" >&6; }
++fi
++
++if test "$ac_cv_lib_ipv6" = yes; then
++
++$as_echo "#define HAVE_IPV6 1" >>confdefs.h
++
++else
++  CFLAGS="${save_CFLAGS}"
++fi
++
++## test for AIX missing in6addr_loopback
++if test "$ac_cv_lib_ipv6" = yes; then
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for in6addr_loopback" >&5
++$as_echo_n "checking for in6addr_loopback... " >&6; }
++if test "${rk_cv_var_in6addr_loopback+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++	cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_NETINET_IN6_H
++#include <netinet/in6.h>
++#endif
++int
++main ()
++{
++
++struct sockaddr_in6 sin6;
++sin6.sin6_addr = in6addr_loopback;
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var_in6addr_loopback=yes
++else
++  ac_cv_var_in6addr_loopback=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $rk_cv_var_in6addr_loopback" >&5
++$as_echo "$rk_cv_var_in6addr_loopback" >&6; }
++	if test "$ac_cv_var_in6addr_loopback" = yes; then
++
++$as_echo "#define HAVE_IN6ADDR_LOOPBACK 1" >>confdefs.h
++
++	fi
++fi
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for gethostbyname2" >&5
++$as_echo_n "checking for gethostbyname2... " >&6; }
++if test "${ac_cv_funclib_gethostbyname2+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_gethostbyname2\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" inet6 ip6; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++gethostbyname2()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_gethostbyname2=$ac_lib; else ac_cv_funclib_gethostbyname2=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_gethostbyname2=\${ac_cv_funclib_gethostbyname2-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_gethostbyname2"
++
++if false; then
++	for ac_func in gethostbyname2
++do :
++  ac_fn_c_check_func "$LINENO" "gethostbyname2" "ac_cv_func_gethostbyname2"
++if test "x$ac_cv_func_gethostbyname2" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_GETHOSTBYNAME2 1
++_ACEOF
++
++fi
++done
++
++fi
++# gethostbyname2
++eval "ac_tr_func=HAVE_`echo gethostbyname2 | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_gethostbyname2=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_gethostbyname2=yes"
++	eval "LIB_gethostbyname2="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_gethostbyname2=no"
++	eval "LIB_gethostbyname2="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_gethostbyname2=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test -n "$LIB_gethostbyname2"; then
++	LIBS="$LIB_gethostbyname2 $LIBS"
++fi
++
++
++
++
++for ac_header in arpa/nameser.h dns.h
++do :
++  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
++ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" "$ac_includes_default"
++if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in resolv.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "resolv.h" "ac_cv_header_resolv_h" "$ac_includes_default
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_NAMESER_H
++#include <arpa/nameser.h>
++#endif
++
++"
++if test "x$ac_cv_header_resolv_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_RESOLV_H 1
++_ACEOF
++
++fi
++
++done
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for res_search" >&5
++$as_echo_n "checking for res_search... " >&6; }
++if test "${ac_cv_funclib_res_search+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_res_search\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" resolv; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <stdio.h>
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_NAMESER_H
++#include <arpa/nameser.h>
++#endif
++#ifdef HAVE_RESOLV_H
++#include <resolv.h>
++#endif
++
++int
++main ()
++{
++res_search(0,0,0,0,0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_res_search=$ac_lib; else ac_cv_funclib_res_search=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_res_search=\${ac_cv_funclib_res_search-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_res_search"
++
++if false; then
++	for ac_func in res_search
++do :
++  ac_fn_c_check_func "$LINENO" "res_search" "ac_cv_func_res_search"
++if test "x$ac_cv_func_res_search" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_RES_SEARCH 1
++_ACEOF
++
++fi
++done
++
++fi
++# res_search
++eval "ac_tr_func=HAVE_`echo res_search | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_res_search=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_res_search=yes"
++	eval "LIB_res_search="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_res_search=no"
++	eval "LIB_res_search="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_res_search=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test -n "$LIB_res_search"; then
++	LIBS="$LIB_res_search $LIBS"
++fi
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for res_nsearch" >&5
++$as_echo_n "checking for res_nsearch... " >&6; }
++if test "${ac_cv_funclib_res_nsearch+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_res_nsearch\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" resolv; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <stdio.h>
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_NAMESER_H
++#include <arpa/nameser.h>
++#endif
++#ifdef HAVE_RESOLV_H
++#include <resolv.h>
++#endif
++
++int
++main ()
++{
++res_nsearch(0,0,0,0,0,0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_res_nsearch=$ac_lib; else ac_cv_funclib_res_nsearch=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_res_nsearch=\${ac_cv_funclib_res_nsearch-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_res_nsearch"
++
++if false; then
++	for ac_func in res_nsearch
++do :
++  ac_fn_c_check_func "$LINENO" "res_nsearch" "ac_cv_func_res_nsearch"
++if test "x$ac_cv_func_res_nsearch" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_RES_NSEARCH 1
++_ACEOF
++
++fi
++done
++
++fi
++# res_nsearch
++eval "ac_tr_func=HAVE_`echo res_nsearch | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_res_nsearch=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_res_nsearch=yes"
++	eval "LIB_res_nsearch="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_res_nsearch=no"
++	eval "LIB_res_nsearch="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_res_nsearch=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test -n "$LIB_res_nsearch"; then
++	LIBS="$LIB_res_nsearch $LIBS"
++fi
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for res_ndestroy" >&5
++$as_echo_n "checking for res_ndestroy... " >&6; }
++if test "${ac_cv_funclib_res_ndestroy+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_res_ndestroy\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" resolv; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <stdio.h>
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_NAMESER_H
++#include <arpa/nameser.h>
++#endif
++#ifdef HAVE_RESOLV_H
++#include <resolv.h>
++#endif
++
++int
++main ()
++{
++res_ndestroy(0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_res_ndestroy=$ac_lib; else ac_cv_funclib_res_ndestroy=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_res_ndestroy=\${ac_cv_funclib_res_ndestroy-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_res_ndestroy"
++
++if false; then
++	for ac_func in res_ndestroy
++do :
++  ac_fn_c_check_func "$LINENO" "res_ndestroy" "ac_cv_func_res_ndestroy"
++if test "x$ac_cv_func_res_ndestroy" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_RES_NDESTROY 1
++_ACEOF
++
++fi
++done
++
++fi
++# res_ndestroy
++eval "ac_tr_func=HAVE_`echo res_ndestroy | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_res_ndestroy=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_res_ndestroy=yes"
++	eval "LIB_res_ndestroy="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_res_ndestroy=no"
++	eval "LIB_res_ndestroy="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_res_ndestroy=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test -n "$LIB_res_ndestroy"; then
++	LIBS="$LIB_res_ndestroy $LIBS"
++fi
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for dns_search" >&5
++$as_echo_n "checking for dns_search... " >&6; }
++if test "${ac_cv_funclib_dns_search+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_dns_search\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" ; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_DNS_H
++#include <dns.h>
++#endif
++
++int
++main ()
++{
++dns_search(0,0,0,0,0,0,0,0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_dns_search=$ac_lib; else ac_cv_funclib_dns_search=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_dns_search=\${ac_cv_funclib_dns_search-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_dns_search"
++
++if false; then
++	for ac_func in dns_search
++do :
++  ac_fn_c_check_func "$LINENO" "dns_search" "ac_cv_func_dns_search"
++if test "x$ac_cv_func_dns_search" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_DNS_SEARCH 1
++_ACEOF
++
++fi
++done
++
++fi
++# dns_search
++eval "ac_tr_func=HAVE_`echo dns_search | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_dns_search=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_dns_search=yes"
++	eval "LIB_dns_search="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_dns_search=no"
++	eval "LIB_dns_search="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_dns_search=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for dn_expand" >&5
++$as_echo_n "checking for dn_expand... " >&6; }
++if test "${ac_cv_funclib_dn_expand+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_dn_expand\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" resolv; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <stdio.h>
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_NAMESER_H
++#include <arpa/nameser.h>
++#endif
++#ifdef HAVE_RESOLV_H
++#include <resolv.h>
++#endif
++
++int
++main ()
++{
++dn_expand(0,0,0,0,0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_dn_expand=$ac_lib; else ac_cv_funclib_dn_expand=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_dn_expand=\${ac_cv_funclib_dn_expand-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_dn_expand"
++
++if false; then
++	for ac_func in dn_expand
++do :
++  ac_fn_c_check_func "$LINENO" "dn_expand" "ac_cv_func_dn_expand"
++if test "x$ac_cv_func_dn_expand" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_DN_EXPAND 1
++_ACEOF
++
++fi
++done
++
++fi
++# dn_expand
++eval "ac_tr_func=HAVE_`echo dn_expand | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_dn_expand=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_dn_expand=yes"
++	eval "LIB_dn_expand="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_dn_expand=no"
++	eval "LIB_dn_expand="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_dn_expand=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test -n "$LIB_dn_expand"; then
++	LIBS="$LIB_dn_expand $LIBS"
++fi
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for _res" >&5
++$as_echo_n "checking for _res... " >&6; }
++if test "${ac_cv_var__res+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++
++	cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdio.h>
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_NAMESER_H
++#include <arpa/nameser.h>
++#endif
++#ifdef HAVE_RESOLV_H
++#include <resolv.h>
++#endif
++	void * foo(void) { return &_res; }
++int
++main ()
++{
++foo()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var__res=yes
++else
++  ac_cv_var__res=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++if test "$ac_cv_var__res" != yes ; then
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdio.h>
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_NAMESER_H
++#include <arpa/nameser.h>
++#endif
++#ifdef HAVE_RESOLV_H
++#include <resolv.h>
++#endif
++extern int _res;
++int foo(void) { return _res; }
++int
++main ()
++{
++foo()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var__res=yes
++else
++  ac_cv_var__res=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++
++fi
++
++ac_foo=`eval echo \\$ac_cv_var__res`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE__RES 1
++_ACEOF
++
++
++# ac_fn_c_check_decl LINENO SYMBOL VAR INCLUDES
++# ---------------------------------------------
++# Tests whether SYMBOL is declared in INCLUDES, setting cache variable VAR
++# accordingly.
++ac_fn_c_check_decl ()
++{
++  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
++  as_decl_name=`echo $2|sed 's/ *(.*//'`
++  as_decl_use=`echo $2|sed -e 's/(/((/' -e 's/)/) 0&/' -e 's/,/) 0& (/g'`
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $as_decl_name is declared" >&5
++$as_echo_n "checking whether $as_decl_name is declared... " >&6; }
++if eval "test \"\${$3+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++$4
++int
++main ()
++{
++#ifndef $as_decl_name
++#ifdef __cplusplus
++  (void) $as_decl_use;
++#else
++  (void) $as_decl_name;
++#endif
++#endif
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "$3=yes"
++else
++  eval "$3=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++eval ac_res=\$$3
++	       { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
++$as_echo "$ac_res" >&6; }
++  eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset as_lineno;}
++
++} # ac_fn_c_check_decl
++ac_fn_c_check_decl "$LINENO" "_res" "ac_cv_have_decl__res" "#include <stdio.h>
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_NAMESER_H
++#include <arpa/nameser.h>
++#endif
++#ifdef HAVE_RESOLV_H
++#include <resolv.h>
++#endif
++"
++if test "x$ac_cv_have_decl__res" = x""yes; then :
++  ac_have_decl=1
++else
++  ac_have_decl=0
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_DECL__RES $ac_have_decl
++_ACEOF
++
++fi
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for working snprintf" >&5
++$as_echo_n "checking for working snprintf... " >&6; }
++if test "${ac_cv_func_snprintf_working+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_cv_func_snprintf_working=yes
++if test "$cross_compiling" = yes; then :
++  :
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <stdio.h>
++#include <string.h>
++int main(int argc, char **argv)
++{
++	char foo[3];
++	snprintf(foo, 2, "12");
++	return strcmp(foo, "1") || snprintf(NULL, 0, "%d", 12) != 2;
++}
++_ACEOF
++if ac_fn_c_try_run "$LINENO"; then :
++  :
++else
++  ac_cv_func_snprintf_working=no
++fi
++rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
++  conftest.$ac_objext conftest.beam conftest.$ac_ext
++fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_snprintf_working" >&5
++$as_echo "$ac_cv_func_snprintf_working" >&6; }
++
++if test "$ac_cv_func_snprintf_working" = yes; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_SNPRINTF 1
++_ACEOF
++
++fi
++if test "$ac_cv_func_snprintf_working" = yes; then
++
++if test "$ac_cv_func_snprintf+set" != set -o "$ac_cv_func_snprintf" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if snprintf needs a prototype" >&5
++$as_echo_n "checking if snprintf needs a prototype... " >&6; }
++if test "${ac_cv_func_snprintf_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdio.h>
++struct foo { int foo; } xx;
++extern int snprintf (struct foo*);
++int
++main ()
++{
++snprintf(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_snprintf_noproto=yes"
++else
++  eval "ac_cv_func_snprintf_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_snprintf_noproto" >&5
++$as_echo "$ac_cv_func_snprintf_noproto" >&6; }
++if test "$ac_cv_func_snprintf_noproto" = yes; then
++
++$as_echo "#define NEED_SNPRINTF_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++fi
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for working vsnprintf" >&5
++$as_echo_n "checking for working vsnprintf... " >&6; }
++if test "${ac_cv_func_vsnprintf_working+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_cv_func_vsnprintf_working=yes
++if test "$cross_compiling" = yes; then :
++  :
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <stdio.h>
++#include <string.h>
++#include <stdarg.h>
++
++int foo(int num, ...)
++{
++	char bar[3];
++	va_list arg;
++	va_start(arg, num);
++	vsnprintf(bar, 2, "%s", arg);
++	va_end(arg);
++	return strcmp(bar, "1");
++}
++
++int bar(int num, int len, ...)
++{
++	int r;
++	va_list arg;
++	va_start(arg, len);
++	r = vsnprintf(NULL, 0, "%s", arg);
++	va_end(arg);
++	return r != len;
++}
++
++int main(int argc, char **argv)
++{
++	return foo(0, "12") || bar(0, 2, "12");
++}
++_ACEOF
++if ac_fn_c_try_run "$LINENO"; then :
++  :
++else
++  ac_cv_func_vsnprintf_working=no
++fi
++rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
++  conftest.$ac_objext conftest.beam conftest.$ac_ext
++fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_vsnprintf_working" >&5
++$as_echo "$ac_cv_func_vsnprintf_working" >&6; }
++
++if test "$ac_cv_func_vsnprintf_working" = yes; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_VSNPRINTF 1
++_ACEOF
++
++fi
++if test "$ac_cv_func_vsnprintf_working" = yes; then
++
++if test "$ac_cv_func_vsnprintf+set" != set -o "$ac_cv_func_vsnprintf" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if vsnprintf needs a prototype" >&5
++$as_echo_n "checking if vsnprintf needs a prototype... " >&6; }
++if test "${ac_cv_func_vsnprintf_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdio.h>
++struct foo { int foo; } xx;
++extern int vsnprintf (struct foo*);
++int
++main ()
++{
++vsnprintf(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_vsnprintf_noproto=yes"
++else
++  eval "ac_cv_func_vsnprintf_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_vsnprintf_noproto" >&5
++$as_echo "$ac_cv_func_vsnprintf_noproto" >&6; }
++if test "$ac_cv_func_vsnprintf_noproto" = yes; then
++
++$as_echo "#define NEED_VSNPRINTF_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++fi
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for working glob" >&5
++$as_echo_n "checking for working glob... " >&6; }
++if test "${ac_cv_func_glob_working+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_cv_func_glob_working=yes
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <stdio.h>
++#include <glob.h>
++int
++main ()
++{
++
++glob(NULL, GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE|
++#ifdef GLOB_MAXPATH
++GLOB_MAXPATH
++#else
++GLOB_LIMIT
++#endif
++,
++NULL, NULL);
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  :
++else
++  ac_cv_func_glob_working=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_glob_working" >&5
++$as_echo "$ac_cv_func_glob_working" >&6; }
++
++if test "$ac_cv_func_glob_working" = yes; then
++
++$as_echo "#define HAVE_GLOB 1" >>confdefs.h
++
++fi
++if test "$ac_cv_func_glob_working" = yes; then
++
++if test "$ac_cv_func_glob+set" != set -o "$ac_cv_func_glob" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if glob needs a prototype" >&5
++$as_echo_n "checking if glob needs a prototype... " >&6; }
++if test "${ac_cv_func_glob_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdio.h>
++#include <glob.h>
++struct foo { int foo; } xx;
++extern int glob (struct foo*);
++int
++main ()
++{
++glob(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_glob_noproto=yes"
++else
++  eval "ac_cv_func_glob_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_glob_noproto" >&5
++$as_echo "$ac_cv_func_glob_noproto" >&6; }
++if test "$ac_cv_func_glob_noproto" = yes; then
++
++$as_echo "#define NEED_GLOB_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++fi
++
++if test "$ac_cv_func_glob_working" != yes; then
++	case " $LIBOBJS " in
++  *" glob.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS glob.$ac_objext"
++ ;;
++esac
++
++fi
++ if test "$ac_cv_func_glob_working" = yes; then
++  have_glob_h_TRUE=
++  have_glob_h_FALSE='#'
++else
++  have_glob_h_TRUE='#'
++  have_glob_h_FALSE=
++fi
++
++
++
++for ac_func in 				\
++	asnprintf				\
++	asprintf				\
++	atexit					\
++	cgetent					\
++	getconfattr				\
++	getprogname				\
++	getrlimit				\
++	getspnam				\
++	initstate				\
++	issetugid				\
++	on_exit					\
++	poll					\
++	random					\
++	setprogname				\
++	setstate				\
++	strsvis					\
++	strsvisx				\
++	strunvis				\
++	strvis					\
++	strvisx					\
++	svis					\
++	sysconf					\
++	sysctl					\
++	uname					\
++	unvis					\
++	vasnprintf				\
++	vasprintf				\
++	vis					\
++
++do :
++  as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
++ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var"
++if eval test \"x\$"$as_ac_var"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++done
++
++
++if test "$ac_cv_func_cgetent" = no; then
++	case " $LIBOBJS " in
++  *" getcap.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS getcap.$ac_objext"
++ ;;
++esac
++
++fi
++ if test "$ac_cv_func_cgetent" = yes; then
++  have_cgetent_TRUE=
++  have_cgetent_FALSE='#'
++else
++  have_cgetent_TRUE='#'
++  have_cgetent_FALSE=
++fi
++
++
++
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for getsockopt" >&5
++$as_echo_n "checking for getsockopt... " >&6; }
++if test "${ac_cv_funclib_getsockopt+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_getsockopt\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" ; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++int
++main ()
++{
++getsockopt(0,0,0,0,0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_getsockopt=$ac_lib; else ac_cv_funclib_getsockopt=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_getsockopt=\${ac_cv_funclib_getsockopt-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_getsockopt"
++
++if false; then
++	for ac_func in getsockopt
++do :
++  ac_fn_c_check_func "$LINENO" "getsockopt" "ac_cv_func_getsockopt"
++if test "x$ac_cv_func_getsockopt" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_GETSOCKOPT 1
++_ACEOF
++
++fi
++done
++
++fi
++# getsockopt
++eval "ac_tr_func=HAVE_`echo getsockopt | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_getsockopt=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_getsockopt=yes"
++	eval "LIB_getsockopt="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_getsockopt=no"
++	eval "LIB_getsockopt="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_getsockopt=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for setsockopt" >&5
++$as_echo_n "checking for setsockopt... " >&6; }
++if test "${ac_cv_funclib_setsockopt+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_setsockopt\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" ; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++int
++main ()
++{
++setsockopt(0,0,0,0,0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_setsockopt=$ac_lib; else ac_cv_funclib_setsockopt=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_setsockopt=\${ac_cv_funclib_setsockopt-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_setsockopt"
++
++if false; then
++	for ac_func in setsockopt
++do :
++  ac_fn_c_check_func "$LINENO" "setsockopt" "ac_cv_func_setsockopt"
++if test "x$ac_cv_func_setsockopt" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_SETSOCKOPT 1
++_ACEOF
++
++fi
++done
++
++fi
++# setsockopt
++eval "ac_tr_func=HAVE_`echo setsockopt | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_setsockopt=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_setsockopt=yes"
++	eval "LIB_setsockopt="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_setsockopt=no"
++	eval "LIB_setsockopt="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_setsockopt=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for hstrerror" >&5
++$as_echo_n "checking for hstrerror... " >&6; }
++if test "${ac_cv_funclib_hstrerror+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_hstrerror\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" resolv; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++int
++main ()
++{
++hstrerror(17)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_hstrerror=$ac_lib; else ac_cv_funclib_hstrerror=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_hstrerror=\${ac_cv_funclib_hstrerror-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_hstrerror"
++
++if false; then
++	for ac_func in hstrerror
++do :
++  ac_fn_c_check_func "$LINENO" "hstrerror" "ac_cv_func_hstrerror"
++if test "x$ac_cv_func_hstrerror" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_HSTRERROR 1
++_ACEOF
++
++fi
++done
++
++fi
++# hstrerror
++eval "ac_tr_func=HAVE_`echo hstrerror | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_hstrerror=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_hstrerror=yes"
++	eval "LIB_hstrerror="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_hstrerror=no"
++	eval "LIB_hstrerror="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_hstrerror=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test -n "$LIB_hstrerror"; then
++	LIBS="$LIB_hstrerror $LIBS"
++fi
++
++if eval "test \"$ac_cv_func_hstrerror\" != yes"; then
++	case " $LIBOBJS " in
++  *" hstrerror.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS hstrerror.$ac_objext"
++ ;;
++esac
++
++fi
++
++
++if test "$ac_cv_func_hstrerror+set" != set -o "$ac_cv_func_hstrerror" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if hstrerror needs a prototype" >&5
++$as_echo_n "checking if hstrerror needs a prototype... " >&6; }
++if test "${ac_cv_func_hstrerror_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++struct foo { int foo; } xx;
++extern int hstrerror (struct foo*);
++int
++main ()
++{
++hstrerror(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_hstrerror_noproto=yes"
++else
++  eval "ac_cv_func_hstrerror_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_hstrerror_noproto" >&5
++$as_echo "$ac_cv_func_hstrerror_noproto" >&6; }
++if test "$ac_cv_func_hstrerror_noproto" = yes; then
++
++$as_echo "#define NEED_HSTRERROR_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++
++
++if test "$ac_cv_func_asprintf+set" != set -o "$ac_cv_func_asprintf" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if asprintf needs a prototype" >&5
++$as_echo_n "checking if asprintf needs a prototype... " >&6; }
++if test "${ac_cv_func_asprintf_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++	#include <stdio.h>
++	#include <string.h>
++struct foo { int foo; } xx;
++extern int asprintf (struct foo*);
++int
++main ()
++{
++asprintf(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_asprintf_noproto=yes"
++else
++  eval "ac_cv_func_asprintf_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_asprintf_noproto" >&5
++$as_echo "$ac_cv_func_asprintf_noproto" >&6; }
++if test "$ac_cv_func_asprintf_noproto" = yes; then
++
++$as_echo "#define NEED_ASPRINTF_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++if test "$ac_cv_func_vasprintf+set" != set -o "$ac_cv_func_vasprintf" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if vasprintf needs a prototype" >&5
++$as_echo_n "checking if vasprintf needs a prototype... " >&6; }
++if test "${ac_cv_func_vasprintf_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++	#include <stdio.h>
++	#include <string.h>
++struct foo { int foo; } xx;
++extern int vasprintf (struct foo*);
++int
++main ()
++{
++vasprintf(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_vasprintf_noproto=yes"
++else
++  eval "ac_cv_func_vasprintf_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_vasprintf_noproto" >&5
++$as_echo "$ac_cv_func_vasprintf_noproto" >&6; }
++if test "$ac_cv_func_vasprintf_noproto" = yes; then
++
++$as_echo "#define NEED_VASPRINTF_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++if test "$ac_cv_func_asnprintf+set" != set -o "$ac_cv_func_asnprintf" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if asnprintf needs a prototype" >&5
++$as_echo_n "checking if asnprintf needs a prototype... " >&6; }
++if test "${ac_cv_func_asnprintf_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++	#include <stdio.h>
++	#include <string.h>
++struct foo { int foo; } xx;
++extern int asnprintf (struct foo*);
++int
++main ()
++{
++asnprintf(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_asnprintf_noproto=yes"
++else
++  eval "ac_cv_func_asnprintf_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_asnprintf_noproto" >&5
++$as_echo "$ac_cv_func_asnprintf_noproto" >&6; }
++if test "$ac_cv_func_asnprintf_noproto" = yes; then
++
++$as_echo "#define NEED_ASNPRINTF_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++if test "$ac_cv_func_vasnprintf+set" != set -o "$ac_cv_func_vasnprintf" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if vasnprintf needs a prototype" >&5
++$as_echo_n "checking if vasnprintf needs a prototype... " >&6; }
++if test "${ac_cv_func_vasnprintf_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++	#include <stdio.h>
++	#include <string.h>
++struct foo { int foo; } xx;
++extern int vasnprintf (struct foo*);
++int
++main ()
++{
++vasnprintf(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_vasnprintf_noproto=yes"
++else
++  eval "ac_cv_func_vasnprintf_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_vasnprintf_noproto" >&5
++$as_echo "$ac_cv_func_vasnprintf_noproto" >&6; }
++if test "$ac_cv_func_vasnprintf_noproto" = yes; then
++
++$as_echo "#define NEED_VASNPRINTF_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for bswap16" >&5
++$as_echo_n "checking for bswap16... " >&6; }
++if test "${ac_cv_funclib_bswap16+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_bswap16\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" ; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_BSWAP_H
++#include <sys/bswap.h>
++#endif
++int
++main ()
++{
++bswap16(0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_bswap16=$ac_lib; else ac_cv_funclib_bswap16=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_bswap16=\${ac_cv_funclib_bswap16-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_bswap16"
++
++if false; then
++	for ac_func in bswap16
++do :
++  ac_fn_c_check_func "$LINENO" "bswap16" "ac_cv_func_bswap16"
++if test "x$ac_cv_func_bswap16" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_BSWAP16 1
++_ACEOF
++
++fi
++done
++
++fi
++# bswap16
++eval "ac_tr_func=HAVE_`echo bswap16 | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_bswap16=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_bswap16=yes"
++	eval "LIB_bswap16="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_bswap16=no"
++	eval "LIB_bswap16="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_bswap16=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for bswap32" >&5
++$as_echo_n "checking for bswap32... " >&6; }
++if test "${ac_cv_funclib_bswap32+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_bswap32\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" ; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_BSWAP_H
++#include <sys/bswap.h>
++#endif
++int
++main ()
++{
++bswap32(0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_bswap32=$ac_lib; else ac_cv_funclib_bswap32=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_bswap32=\${ac_cv_funclib_bswap32-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_bswap32"
++
++if false; then
++	for ac_func in bswap32
++do :
++  ac_fn_c_check_func "$LINENO" "bswap32" "ac_cv_func_bswap32"
++if test "x$ac_cv_func_bswap32" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_BSWAP32 1
++_ACEOF
++
++fi
++done
++
++fi
++# bswap32
++eval "ac_tr_func=HAVE_`echo bswap32 | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_bswap32=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_bswap32=yes"
++	eval "LIB_bswap32="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_bswap32=no"
++	eval "LIB_bswap32="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_bswap32=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for pidfile" >&5
++$as_echo_n "checking for pidfile... " >&6; }
++if test "${ac_cv_funclib_pidfile+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_pidfile\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" util; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_UTIL_H
++#include <util.h>
++#endif
++int
++main ()
++{
++pidfile(0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_pidfile=$ac_lib; else ac_cv_funclib_pidfile=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_pidfile=\${ac_cv_funclib_pidfile-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_pidfile"
++
++if false; then
++	for ac_func in pidfile
++do :
++  ac_fn_c_check_func "$LINENO" "pidfile" "ac_cv_func_pidfile"
++if test "x$ac_cv_func_pidfile" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_PIDFILE 1
++_ACEOF
++
++fi
++done
++
++fi
++# pidfile
++eval "ac_tr_func=HAVE_`echo pidfile | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_pidfile=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_pidfile=yes"
++	eval "LIB_pidfile="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_pidfile=no"
++	eval "LIB_pidfile="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_pidfile=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for getaddrinfo" >&5
++$as_echo_n "checking for getaddrinfo... " >&6; }
++if test "${ac_cv_funclib_getaddrinfo+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_getaddrinfo\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" ; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++int
++main ()
++{
++getaddrinfo(0,0,0,0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_getaddrinfo=$ac_lib; else ac_cv_funclib_getaddrinfo=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_getaddrinfo=\${ac_cv_funclib_getaddrinfo-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_getaddrinfo"
++
++if false; then
++	for ac_func in getaddrinfo
++do :
++  ac_fn_c_check_func "$LINENO" "getaddrinfo" "ac_cv_func_getaddrinfo"
++if test "x$ac_cv_func_getaddrinfo" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_GETADDRINFO 1
++_ACEOF
++
++fi
++done
++
++fi
++# getaddrinfo
++eval "ac_tr_func=HAVE_`echo getaddrinfo | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_getaddrinfo=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_getaddrinfo=yes"
++	eval "LIB_getaddrinfo="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_getaddrinfo=no"
++	eval "LIB_getaddrinfo="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_getaddrinfo=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test -n "$LIB_getaddrinfo"; then
++	LIBS="$LIB_getaddrinfo $LIBS"
++fi
++
++if eval "test \"$ac_cv_func_getaddrinfo\" != yes"; then
++	case " $LIBOBJS " in
++  *" getaddrinfo.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS getaddrinfo.$ac_objext"
++ ;;
++esac
++
++fi
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for getnameinfo" >&5
++$as_echo_n "checking for getnameinfo... " >&6; }
++if test "${ac_cv_funclib_getnameinfo+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_getnameinfo\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" ; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++int
++main ()
++{
++getnameinfo(0,0,0,0,0,0,0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_getnameinfo=$ac_lib; else ac_cv_funclib_getnameinfo=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_getnameinfo=\${ac_cv_funclib_getnameinfo-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_getnameinfo"
++
++if false; then
++	for ac_func in getnameinfo
++do :
++  ac_fn_c_check_func "$LINENO" "getnameinfo" "ac_cv_func_getnameinfo"
++if test "x$ac_cv_func_getnameinfo" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_GETNAMEINFO 1
++_ACEOF
++
++fi
++done
++
++fi
++# getnameinfo
++eval "ac_tr_func=HAVE_`echo getnameinfo | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_getnameinfo=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_getnameinfo=yes"
++	eval "LIB_getnameinfo="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_getnameinfo=no"
++	eval "LIB_getnameinfo="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_getnameinfo=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test -n "$LIB_getnameinfo"; then
++	LIBS="$LIB_getnameinfo $LIBS"
++fi
++
++if eval "test \"$ac_cv_func_getnameinfo\" != yes"; then
++	case " $LIBOBJS " in
++  *" getnameinfo.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS getnameinfo.$ac_objext"
++ ;;
++esac
++
++fi
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for freeaddrinfo" >&5
++$as_echo_n "checking for freeaddrinfo... " >&6; }
++if test "${ac_cv_funclib_freeaddrinfo+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_freeaddrinfo\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" ; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++int
++main ()
++{
++freeaddrinfo(0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_freeaddrinfo=$ac_lib; else ac_cv_funclib_freeaddrinfo=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_freeaddrinfo=\${ac_cv_funclib_freeaddrinfo-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_freeaddrinfo"
++
++if false; then
++	for ac_func in freeaddrinfo
++do :
++  ac_fn_c_check_func "$LINENO" "freeaddrinfo" "ac_cv_func_freeaddrinfo"
++if test "x$ac_cv_func_freeaddrinfo" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_FREEADDRINFO 1
++_ACEOF
++
++fi
++done
++
++fi
++# freeaddrinfo
++eval "ac_tr_func=HAVE_`echo freeaddrinfo | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_freeaddrinfo=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_freeaddrinfo=yes"
++	eval "LIB_freeaddrinfo="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_freeaddrinfo=no"
++	eval "LIB_freeaddrinfo="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_freeaddrinfo=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test -n "$LIB_freeaddrinfo"; then
++	LIBS="$LIB_freeaddrinfo $LIBS"
++fi
++
++if eval "test \"$ac_cv_func_freeaddrinfo\" != yes"; then
++	case " $LIBOBJS " in
++  *" freeaddrinfo.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS freeaddrinfo.$ac_objext"
++ ;;
++esac
++
++fi
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for gai_strerror" >&5
++$as_echo_n "checking for gai_strerror... " >&6; }
++if test "${ac_cv_funclib_gai_strerror+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_gai_strerror\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" ; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++int
++main ()
++{
++gai_strerror(0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_gai_strerror=$ac_lib; else ac_cv_funclib_gai_strerror=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_gai_strerror=\${ac_cv_funclib_gai_strerror-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_gai_strerror"
++
++if false; then
++	for ac_func in gai_strerror
++do :
++  ac_fn_c_check_func "$LINENO" "gai_strerror" "ac_cv_func_gai_strerror"
++if test "x$ac_cv_func_gai_strerror" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_GAI_STRERROR 1
++_ACEOF
++
++fi
++done
++
++fi
++# gai_strerror
++eval "ac_tr_func=HAVE_`echo gai_strerror | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_gai_strerror=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_gai_strerror=yes"
++	eval "LIB_gai_strerror="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_gai_strerror=no"
++	eval "LIB_gai_strerror="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_gai_strerror=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test -n "$LIB_gai_strerror"; then
++	LIBS="$LIB_gai_strerror $LIBS"
++fi
++
++if eval "test \"$ac_cv_func_gai_strerror\" != yes"; then
++	case " $LIBOBJS " in
++  *" gai_strerror.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS gai_strerror.$ac_objext"
++ ;;
++esac
++
++fi
++
++
++case "$host_os" in
++	darwin*)
++		;;
++	*)
++
++$as_echo "#define SUPPORT_DETACH 1" >>confdefs.h
++
++		ac_fn_c_check_func "$LINENO" "daemon" "ac_cv_func_daemon"
++if test "x$ac_cv_func_daemon" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_DAEMON 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" daemon.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS daemon.$ac_objext"
++ ;;
++esac
++
++fi
++ ;;
++esac
++
++ac_fn_c_check_func "$LINENO" "chown" "ac_cv_func_chown"
++if test "x$ac_cv_func_chown" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_CHOWN 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" chown.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS chown.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "copyhostent" "ac_cv_func_copyhostent"
++if test "x$ac_cv_func_copyhostent" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_COPYHOSTENT 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" copyhostent.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS copyhostent.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "closefrom" "ac_cv_func_closefrom"
++if test "x$ac_cv_func_closefrom" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_CLOSEFROM 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" closefrom.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS closefrom.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "ecalloc" "ac_cv_func_ecalloc"
++if test "x$ac_cv_func_ecalloc" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_ECALLOC 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" ecalloc.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS ecalloc.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "emalloc" "ac_cv_func_emalloc"
++if test "x$ac_cv_func_emalloc" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_EMALLOC 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" emalloc.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS emalloc.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "erealloc" "ac_cv_func_erealloc"
++if test "x$ac_cv_func_erealloc" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_EREALLOC 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" erealloc.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS erealloc.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "estrdup" "ac_cv_func_estrdup"
++if test "x$ac_cv_func_estrdup" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_ESTRDUP 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" estrdup.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS estrdup.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "err" "ac_cv_func_err"
++if test "x$ac_cv_func_err" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_ERR 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" err.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS err.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "errx" "ac_cv_func_errx"
++if test "x$ac_cv_func_errx" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_ERRX 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" errx.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS errx.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "fchown" "ac_cv_func_fchown"
++if test "x$ac_cv_func_fchown" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_FCHOWN 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" fchown.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS fchown.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "flock" "ac_cv_func_flock"
++if test "x$ac_cv_func_flock" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_FLOCK 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" flock.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS flock.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "fnmatch" "ac_cv_func_fnmatch"
++if test "x$ac_cv_func_fnmatch" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_FNMATCH 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" fnmatch.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS fnmatch.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "freehostent" "ac_cv_func_freehostent"
++if test "x$ac_cv_func_freehostent" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_FREEHOSTENT 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" freehostent.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS freehostent.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "getcwd" "ac_cv_func_getcwd"
++if test "x$ac_cv_func_getcwd" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_GETCWD 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" getcwd.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS getcwd.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "getdtablesize" "ac_cv_func_getdtablesize"
++if test "x$ac_cv_func_getdtablesize" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_GETDTABLESIZE 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" getdtablesize.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS getdtablesize.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "getegid" "ac_cv_func_getegid"
++if test "x$ac_cv_func_getegid" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_GETEGID 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" getegid.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS getegid.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "geteuid" "ac_cv_func_geteuid"
++if test "x$ac_cv_func_geteuid" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_GETEUID 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" geteuid.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS geteuid.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "getgid" "ac_cv_func_getgid"
++if test "x$ac_cv_func_getgid" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_GETGID 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" getgid.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS getgid.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "gethostname" "ac_cv_func_gethostname"
++if test "x$ac_cv_func_gethostname" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_GETHOSTNAME 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" gethostname.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS gethostname.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "getifaddrs" "ac_cv_func_getifaddrs"
++if test "x$ac_cv_func_getifaddrs" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_GETIFADDRS 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" getifaddrs.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS getifaddrs.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "getipnodebyaddr" "ac_cv_func_getipnodebyaddr"
++if test "x$ac_cv_func_getipnodebyaddr" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_GETIPNODEBYADDR 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" getipnodebyaddr.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS getipnodebyaddr.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "getipnodebyname" "ac_cv_func_getipnodebyname"
++if test "x$ac_cv_func_getipnodebyname" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_GETIPNODEBYNAME 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" getipnodebyname.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS getipnodebyname.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "getopt" "ac_cv_func_getopt"
++if test "x$ac_cv_func_getopt" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_GETOPT 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" getopt.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS getopt.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "gettimeofday" "ac_cv_func_gettimeofday"
++if test "x$ac_cv_func_gettimeofday" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_GETTIMEOFDAY 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" gettimeofday.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS gettimeofday.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "getuid" "ac_cv_func_getuid"
++if test "x$ac_cv_func_getuid" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_GETUID 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" getuid.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS getuid.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "getusershell" "ac_cv_func_getusershell"
++if test "x$ac_cv_func_getusershell" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_GETUSERSHELL 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" getusershell.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS getusershell.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "initgroups" "ac_cv_func_initgroups"
++if test "x$ac_cv_func_initgroups" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_INITGROUPS 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" initgroups.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS initgroups.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "innetgr" "ac_cv_func_innetgr"
++if test "x$ac_cv_func_innetgr" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_INNETGR 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" innetgr.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS innetgr.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "iruserok" "ac_cv_func_iruserok"
++if test "x$ac_cv_func_iruserok" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_IRUSEROK 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" iruserok.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS iruserok.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "localtime_r" "ac_cv_func_localtime_r"
++if test "x$ac_cv_func_localtime_r" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_LOCALTIME_R 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" localtime_r.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS localtime_r.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "lstat" "ac_cv_func_lstat"
++if test "x$ac_cv_func_lstat" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_LSTAT 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" lstat.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS lstat.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "memmove" "ac_cv_func_memmove"
++if test "x$ac_cv_func_memmove" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_MEMMOVE 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" memmove.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS memmove.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "mkstemp" "ac_cv_func_mkstemp"
++if test "x$ac_cv_func_mkstemp" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_MKSTEMP 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" mkstemp.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS mkstemp.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "putenv" "ac_cv_func_putenv"
++if test "x$ac_cv_func_putenv" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_PUTENV 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" putenv.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS putenv.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "rcmd" "ac_cv_func_rcmd"
++if test "x$ac_cv_func_rcmd" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_RCMD 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" rcmd.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS rcmd.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "readv" "ac_cv_func_readv"
++if test "x$ac_cv_func_readv" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_READV 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" readv.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS readv.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "recvmsg" "ac_cv_func_recvmsg"
++if test "x$ac_cv_func_recvmsg" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_RECVMSG 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" recvmsg.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS recvmsg.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "sendmsg" "ac_cv_func_sendmsg"
++if test "x$ac_cv_func_sendmsg" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_SENDMSG 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" sendmsg.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS sendmsg.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "setegid" "ac_cv_func_setegid"
++if test "x$ac_cv_func_setegid" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_SETEGID 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" setegid.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS setegid.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "setenv" "ac_cv_func_setenv"
++if test "x$ac_cv_func_setenv" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_SETENV 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" setenv.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS setenv.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "seteuid" "ac_cv_func_seteuid"
++if test "x$ac_cv_func_seteuid" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_SETEUID 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" seteuid.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS seteuid.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strcasecmp" "ac_cv_func_strcasecmp"
++if test "x$ac_cv_func_strcasecmp" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRCASECMP 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strcasecmp.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strcasecmp.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strdup" "ac_cv_func_strdup"
++if test "x$ac_cv_func_strdup" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRDUP 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strdup.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strdup.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strerror" "ac_cv_func_strerror"
++if test "x$ac_cv_func_strerror" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRERROR 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strerror.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strerror.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strftime" "ac_cv_func_strftime"
++if test "x$ac_cv_func_strftime" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRFTIME 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strftime.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strftime.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strlcat" "ac_cv_func_strlcat"
++if test "x$ac_cv_func_strlcat" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRLCAT 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strlcat.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strlcat.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strlcpy" "ac_cv_func_strlcpy"
++if test "x$ac_cv_func_strlcpy" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRLCPY 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strlcpy.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strlcpy.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strlwr" "ac_cv_func_strlwr"
++if test "x$ac_cv_func_strlwr" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRLWR 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strlwr.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strlwr.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strncasecmp" "ac_cv_func_strncasecmp"
++if test "x$ac_cv_func_strncasecmp" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRNCASECMP 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strncasecmp.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strncasecmp.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strndup" "ac_cv_func_strndup"
++if test "x$ac_cv_func_strndup" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRNDUP 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strndup.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strndup.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strnlen" "ac_cv_func_strnlen"
++if test "x$ac_cv_func_strnlen" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRNLEN 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strnlen.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strnlen.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strptime" "ac_cv_func_strptime"
++if test "x$ac_cv_func_strptime" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRPTIME 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strptime.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strptime.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strsep" "ac_cv_func_strsep"
++if test "x$ac_cv_func_strsep" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRSEP 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strsep.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strsep.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strsep_copy" "ac_cv_func_strsep_copy"
++if test "x$ac_cv_func_strsep_copy" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRSEP_COPY 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strsep_copy.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strsep_copy.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strtok_r" "ac_cv_func_strtok_r"
++if test "x$ac_cv_func_strtok_r" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRTOK_R 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strtok_r.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strtok_r.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "strupr" "ac_cv_func_strupr"
++if test "x$ac_cv_func_strupr" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRUPR 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" strupr.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS strupr.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "swab" "ac_cv_func_swab"
++if test "x$ac_cv_func_swab" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_SWAB 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" swab.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS swab.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "timegm" "ac_cv_func_timegm"
++if test "x$ac_cv_func_timegm" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_TIMEGM 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" timegm.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS timegm.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "unsetenv" "ac_cv_func_unsetenv"
++if test "x$ac_cv_func_unsetenv" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_UNSETENV 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" unsetenv.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS unsetenv.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "verr" "ac_cv_func_verr"
++if test "x$ac_cv_func_verr" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_VERR 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" verr.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS verr.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "verrx" "ac_cv_func_verrx"
++if test "x$ac_cv_func_verrx" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_VERRX 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" verrx.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS verrx.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "vsyslog" "ac_cv_func_vsyslog"
++if test "x$ac_cv_func_vsyslog" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_VSYSLOG 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" vsyslog.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS vsyslog.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "vwarn" "ac_cv_func_vwarn"
++if test "x$ac_cv_func_vwarn" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_VWARN 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" vwarn.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS vwarn.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "vwarnx" "ac_cv_func_vwarnx"
++if test "x$ac_cv_func_vwarnx" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_VWARNX 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" vwarnx.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS vwarnx.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "warn" "ac_cv_func_warn"
++if test "x$ac_cv_func_warn" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_WARN 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" warn.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS warn.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "warnx" "ac_cv_func_warnx"
++if test "x$ac_cv_func_warnx" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_WARNX 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" warnx.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS warnx.$ac_objext"
++ ;;
++esac
++
++fi
++ac_fn_c_check_func "$LINENO" "writev" "ac_cv_func_writev"
++if test "x$ac_cv_func_writev" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_WRITEV 1
++_ACEOF
++
++else
++  case " $LIBOBJS " in
++  *" writev.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS writev.$ac_objext"
++ ;;
++esac
++
++fi
++
++
++ if test "$ac_cv_header_fnmatch_h" = yes -a "$ac_cv_func_fnmatch" = yes; then
++  have_fnmatch_h_TRUE=
++  have_fnmatch_h_FALSE='#'
++else
++  have_fnmatch_h_TRUE='#'
++  have_fnmatch_h_FALSE=
++fi
++
++
++
++if test "$ac_cv_func_strndup+set" != set -o "$ac_cv_func_strndup" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if strndup needs a prototype" >&5
++$as_echo_n "checking if strndup needs a prototype... " >&6; }
++if test "${ac_cv_func_strndup_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <string.h>
++struct foo { int foo; } xx;
++extern int strndup (struct foo*);
++int
++main ()
++{
++strndup(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_strndup_noproto=yes"
++else
++  eval "ac_cv_func_strndup_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_strndup_noproto" >&5
++$as_echo "$ac_cv_func_strndup_noproto" >&6; }
++if test "$ac_cv_func_strndup_noproto" = yes; then
++
++$as_echo "#define NEED_STRNDUP_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++if test "$ac_cv_func_strsep+set" != set -o "$ac_cv_func_strsep" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if strsep needs a prototype" >&5
++$as_echo_n "checking if strsep needs a prototype... " >&6; }
++if test "${ac_cv_func_strsep_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <string.h>
++struct foo { int foo; } xx;
++extern int strsep (struct foo*);
++int
++main ()
++{
++strsep(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_strsep_noproto=yes"
++else
++  eval "ac_cv_func_strsep_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_strsep_noproto" >&5
++$as_echo "$ac_cv_func_strsep_noproto" >&6; }
++if test "$ac_cv_func_strsep_noproto" = yes; then
++
++$as_echo "#define NEED_STRSEP_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++if test "$ac_cv_func_strtok_r+set" != set -o "$ac_cv_func_strtok_r" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if strtok_r needs a prototype" >&5
++$as_echo_n "checking if strtok_r needs a prototype... " >&6; }
++if test "${ac_cv_func_strtok_r_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <string.h>
++struct foo { int foo; } xx;
++extern int strtok_r (struct foo*);
++int
++main ()
++{
++strtok_r(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_strtok_r_noproto=yes"
++else
++  eval "ac_cv_func_strtok_r_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_strtok_r_noproto" >&5
++$as_echo "$ac_cv_func_strtok_r_noproto" >&6; }
++if test "$ac_cv_func_strtok_r_noproto" = yes; then
++
++$as_echo "#define NEED_STRTOK_R_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++
++
++if test "$ac_cv_func_strsvis+set" != set -o "$ac_cv_func_strsvis" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if strsvis needs a prototype" >&5
++$as_echo_n "checking if strsvis needs a prototype... " >&6; }
++if test "${ac_cv_func_strsvis_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_VIS_H
++#include <vis.h>
++#endif
++struct foo { int foo; } xx;
++extern int strsvis (struct foo*);
++int
++main ()
++{
++strsvis(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_strsvis_noproto=yes"
++else
++  eval "ac_cv_func_strsvis_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_strsvis_noproto" >&5
++$as_echo "$ac_cv_func_strsvis_noproto" >&6; }
++if test "$ac_cv_func_strsvis_noproto" = yes; then
++
++$as_echo "#define NEED_STRSVIS_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++if test "$ac_cv_func_strsvisx+set" != set -o "$ac_cv_func_strsvisx" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if strsvisx needs a prototype" >&5
++$as_echo_n "checking if strsvisx needs a prototype... " >&6; }
++if test "${ac_cv_func_strsvisx_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_VIS_H
++#include <vis.h>
++#endif
++struct foo { int foo; } xx;
++extern int strsvisx (struct foo*);
++int
++main ()
++{
++strsvisx(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_strsvisx_noproto=yes"
++else
++  eval "ac_cv_func_strsvisx_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_strsvisx_noproto" >&5
++$as_echo "$ac_cv_func_strsvisx_noproto" >&6; }
++if test "$ac_cv_func_strsvisx_noproto" = yes; then
++
++$as_echo "#define NEED_STRSVISX_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++if test "$ac_cv_func_strunvis+set" != set -o "$ac_cv_func_strunvis" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if strunvis needs a prototype" >&5
++$as_echo_n "checking if strunvis needs a prototype... " >&6; }
++if test "${ac_cv_func_strunvis_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_VIS_H
++#include <vis.h>
++#endif
++struct foo { int foo; } xx;
++extern int strunvis (struct foo*);
++int
++main ()
++{
++strunvis(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_strunvis_noproto=yes"
++else
++  eval "ac_cv_func_strunvis_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_strunvis_noproto" >&5
++$as_echo "$ac_cv_func_strunvis_noproto" >&6; }
++if test "$ac_cv_func_strunvis_noproto" = yes; then
++
++$as_echo "#define NEED_STRUNVIS_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++if test "$ac_cv_func_strvis+set" != set -o "$ac_cv_func_strvis" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if strvis needs a prototype" >&5
++$as_echo_n "checking if strvis needs a prototype... " >&6; }
++if test "${ac_cv_func_strvis_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_VIS_H
++#include <vis.h>
++#endif
++struct foo { int foo; } xx;
++extern int strvis (struct foo*);
++int
++main ()
++{
++strvis(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_strvis_noproto=yes"
++else
++  eval "ac_cv_func_strvis_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_strvis_noproto" >&5
++$as_echo "$ac_cv_func_strvis_noproto" >&6; }
++if test "$ac_cv_func_strvis_noproto" = yes; then
++
++$as_echo "#define NEED_STRVIS_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++if test "$ac_cv_func_strvisx+set" != set -o "$ac_cv_func_strvisx" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if strvisx needs a prototype" >&5
++$as_echo_n "checking if strvisx needs a prototype... " >&6; }
++if test "${ac_cv_func_strvisx_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_VIS_H
++#include <vis.h>
++#endif
++struct foo { int foo; } xx;
++extern int strvisx (struct foo*);
++int
++main ()
++{
++strvisx(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_strvisx_noproto=yes"
++else
++  eval "ac_cv_func_strvisx_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_strvisx_noproto" >&5
++$as_echo "$ac_cv_func_strvisx_noproto" >&6; }
++if test "$ac_cv_func_strvisx_noproto" = yes; then
++
++$as_echo "#define NEED_STRVISX_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++if test "$ac_cv_func_svis+set" != set -o "$ac_cv_func_svis" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if svis needs a prototype" >&5
++$as_echo_n "checking if svis needs a prototype... " >&6; }
++if test "${ac_cv_func_svis_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_VIS_H
++#include <vis.h>
++#endif
++struct foo { int foo; } xx;
++extern int svis (struct foo*);
++int
++main ()
++{
++svis(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_svis_noproto=yes"
++else
++  eval "ac_cv_func_svis_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_svis_noproto" >&5
++$as_echo "$ac_cv_func_svis_noproto" >&6; }
++if test "$ac_cv_func_svis_noproto" = yes; then
++
++$as_echo "#define NEED_SVIS_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++if test "$ac_cv_func_unvis+set" != set -o "$ac_cv_func_unvis" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if unvis needs a prototype" >&5
++$as_echo_n "checking if unvis needs a prototype... " >&6; }
++if test "${ac_cv_func_unvis_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_VIS_H
++#include <vis.h>
++#endif
++struct foo { int foo; } xx;
++extern int unvis (struct foo*);
++int
++main ()
++{
++unvis(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_unvis_noproto=yes"
++else
++  eval "ac_cv_func_unvis_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_unvis_noproto" >&5
++$as_echo "$ac_cv_func_unvis_noproto" >&6; }
++if test "$ac_cv_func_unvis_noproto" = yes; then
++
++$as_echo "#define NEED_UNVIS_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++if test "$ac_cv_func_vis+set" != set -o "$ac_cv_func_vis" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if vis needs a prototype" >&5
++$as_echo_n "checking if vis needs a prototype... " >&6; }
++if test "${ac_cv_func_vis_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_VIS_H
++#include <vis.h>
++#endif
++struct foo { int foo; } xx;
++extern int vis (struct foo*);
++int
++main ()
++{
++vis(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_vis_noproto=yes"
++else
++  eval "ac_cv_func_vis_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_vis_noproto" >&5
++$as_echo "$ac_cv_func_vis_noproto" >&6; }
++if test "$ac_cv_func_vis_noproto" = yes; then
++
++$as_echo "#define NEED_VIS_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking checking for dirfd" >&5
++$as_echo_n "checking checking for dirfd... " >&6; }
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sys/types.h>
++#ifdef HAVE_DIRENT_H
++#include <dirent.h>
++#endif
++
++int
++main ()
++{
++DIR *d = 0; dirfd(d);
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_rk_have_dirfd=yes
++else
++  ac_rk_have_dirfd=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++if test "$ac_rk_have_dirfd" = "yes" ; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_DIRFD 1
++_ACEOF
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_rk_have_dirfd" >&5
++$as_echo "$ac_rk_have_dirfd" >&6; }
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for dd_fd in DIR" >&5
++$as_echo_n "checking for dd_fd in DIR... " >&6; }
++if test "${ac_cv_type_dir_dd_fd+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sys/types.h>
++#ifdef HAVE_DIRENT_H
++#include <dirent.h>
++#endif
++int
++main ()
++{
++DIR x; memset(&x, 0, sizeof(x)); x.dd_fd
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_dir_dd_fd=yes
++else
++  ac_cv_type_dir_dd_fd=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_dir_dd_fd" >&5
++$as_echo "$ac_cv_type_dir_dd_fd" >&6; }
++if test "$ac_cv_type_dir_dd_fd" = yes; then
++
++
++$as_echo "#define HAVE_DIR_DD_FD 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for inet_aton" >&5
++$as_echo_n "checking for inet_aton... " >&6; }
++if test "${ac_cv_func_inet_aton+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_INET_H
++#include <arpa/inet.h>
++#endif
++int
++main ()
++{
++
++/* The GNU C library defines this for functions which it implements
++    to always fail with ENOSYS.  Some functions are actually named
++    something starting with __ and the normal name is an alias.  */
++#if defined (__stub_inet_aton) || defined (__stub___inet_aton)
++choke me
++#else
++inet_aton(0,0);
++#endif
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "ac_cv_func_inet_aton=yes"
++else
++  eval "ac_cv_func_inet_aton=no"
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++
++if eval "test \"\${ac_cv_func_inet_aton}\" = yes"; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_INET_ATON 1
++_ACEOF
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++  case " $LIBOBJS " in
++  *" inet_aton.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS inet_aton.$ac_objext"
++ ;;
++esac
++
++fi
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for inet_ntop" >&5
++$as_echo_n "checking for inet_ntop... " >&6; }
++if test "${ac_cv_func_inet_ntop+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_INET_H
++#include <arpa/inet.h>
++#endif
++int
++main ()
++{
++
++/* The GNU C library defines this for functions which it implements
++    to always fail with ENOSYS.  Some functions are actually named
++    something starting with __ and the normal name is an alias.  */
++#if defined (__stub_inet_ntop) || defined (__stub___inet_ntop)
++choke me
++#else
++inet_ntop(0, 0, 0, 0);
++#endif
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "ac_cv_func_inet_ntop=yes"
++else
++  eval "ac_cv_func_inet_ntop=no"
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++
++if eval "test \"\${ac_cv_func_inet_ntop}\" = yes"; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_INET_NTOP 1
++_ACEOF
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++  case " $LIBOBJS " in
++  *" inet_ntop.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS inet_ntop.$ac_objext"
++ ;;
++esac
++
++fi
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for inet_pton" >&5
++$as_echo_n "checking for inet_pton... " >&6; }
++if test "${ac_cv_func_inet_pton+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_INET_H
++#include <arpa/inet.h>
++#endif
++int
++main ()
++{
++
++/* The GNU C library defines this for functions which it implements
++    to always fail with ENOSYS.  Some functions are actually named
++    something starting with __ and the normal name is an alias.  */
++#if defined (__stub_inet_pton) || defined (__stub___inet_pton)
++choke me
++#else
++inet_pton(0,0,0);
++#endif
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "ac_cv_func_inet_pton=yes"
++else
++  eval "ac_cv_func_inet_pton=no"
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++
++if eval "test \"\${ac_cv_func_inet_pton}\" = yes"; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_INET_PTON 1
++_ACEOF
++
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++  case " $LIBOBJS " in
++  *" inet_pton.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS inet_pton.$ac_objext"
++ ;;
++esac
++
++fi
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for sa_len in struct sockaddr" >&5
++$as_echo_n "checking for sa_len in struct sockaddr... " >&6; }
++if test "${ac_cv_type_struct_sockaddr_sa_len+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sys/types.h>
++#include <sys/socket.h>
++int
++main ()
++{
++struct sockaddr x; memset(&x, 0, sizeof(x)); x.sa_len
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_sockaddr_sa_len=yes
++else
++  ac_cv_type_struct_sockaddr_sa_len=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_sockaddr_sa_len" >&5
++$as_echo "$ac_cv_type_struct_sockaddr_sa_len" >&6; }
++if test "$ac_cv_type_struct_sockaddr_sa_len" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_SOCKADDR_SA_LEN 1" >>confdefs.h
++
++
++fi
++
++
++
++if test "$ac_cv_func_getaddrinfo" = "yes"; then
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if getaddrinfo handles numeric services" >&5
++$as_echo_n "checking if getaddrinfo handles numeric services... " >&6; }
++if test "${ac_cv_func_getaddrinfo_numserv+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test "$cross_compiling" = yes; then :
++  ac_cv_func_getaddrinfo_numserv=yes
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdio.h>
++#include <sys/types.h>
++#include <sys/socket.h>
++#include <netdb.h>
++
++int
++main(int argc, char **argv)
++{
++	struct addrinfo hints, *ai;
++	memset(&hints, 0, sizeof(hints));
++	hints.ai_flags = AI_PASSIVE;
++	hints.ai_socktype = SOCK_STREAM;
++	hints.ai_family = PF_UNSPEC;
++	if(getaddrinfo(NULL, "17", &hints, &ai) != 0)
++		return 1;
++	if(getaddrinfo(NULL, "0", &hints, &ai) != 0)
++		return 1;
++	return 0;
++}
++
++_ACEOF
++if ac_fn_c_try_run "$LINENO"; then :
++  ac_cv_func_getaddrinfo_numserv=yes
++else
++  ac_cv_func_getaddrinfo_numserv=no
++fi
++rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
++  conftest.$ac_objext conftest.beam conftest.$ac_ext
++fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_getaddrinfo_numserv" >&5
++$as_echo "$ac_cv_func_getaddrinfo_numserv" >&6; }
++  if test "$ac_cv_func_getaddrinfo_numserv" = no; then
++	case " $LIBOBJS " in
++  *" getaddrinfo.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS getaddrinfo.$ac_objext"
++ ;;
++esac
++
++	case " $LIBOBJS " in
++  *" freeaddrinfo.$ac_objext "* ) ;;
++  *) LIBOBJS="$LIBOBJS freeaddrinfo.$ac_objext"
++ ;;
++esac
++
++  fi
++fi
++
++
++if test "$ac_cv_func_setenv+set" != set -o "$ac_cv_func_setenv" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if setenv needs a prototype" >&5
++$as_echo_n "checking if setenv needs a prototype... " >&6; }
++if test "${ac_cv_func_setenv_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdlib.h>
++struct foo { int foo; } xx;
++extern int setenv (struct foo*);
++int
++main ()
++{
++setenv(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_setenv_noproto=yes"
++else
++  eval "ac_cv_func_setenv_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_setenv_noproto" >&5
++$as_echo "$ac_cv_func_setenv_noproto" >&6; }
++if test "$ac_cv_func_setenv_noproto" = yes; then
++
++$as_echo "#define NEED_SETENV_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++
++if test "$ac_cv_func_unsetenv+set" != set -o "$ac_cv_func_unsetenv" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if unsetenv needs a prototype" >&5
++$as_echo_n "checking if unsetenv needs a prototype... " >&6; }
++if test "${ac_cv_func_unsetenv_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdlib.h>
++struct foo { int foo; } xx;
++extern int unsetenv (struct foo*);
++int
++main ()
++{
++unsetenv(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_unsetenv_noproto=yes"
++else
++  eval "ac_cv_func_unsetenv_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_unsetenv_noproto" >&5
++$as_echo "$ac_cv_func_unsetenv_noproto" >&6; }
++if test "$ac_cv_func_unsetenv_noproto" = yes; then
++
++$as_echo "#define NEED_UNSETENV_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++
++if test "$ac_cv_func_gethostname+set" != set -o "$ac_cv_func_gethostname" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if gethostname needs a prototype" >&5
++$as_echo_n "checking if gethostname needs a prototype... " >&6; }
++if test "${ac_cv_func_gethostname_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <unistd.h>
++struct foo { int foo; } xx;
++extern int gethostname (struct foo*);
++int
++main ()
++{
++gethostname(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_gethostname_noproto=yes"
++else
++  eval "ac_cv_func_gethostname_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_gethostname_noproto" >&5
++$as_echo "$ac_cv_func_gethostname_noproto" >&6; }
++if test "$ac_cv_func_gethostname_noproto" = yes; then
++
++$as_echo "#define NEED_GETHOSTNAME_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++
++if test "$ac_cv_func_mkstemp+set" != set -o "$ac_cv_func_mkstemp" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if mkstemp needs a prototype" >&5
++$as_echo_n "checking if mkstemp needs a prototype... " >&6; }
++if test "${ac_cv_func_mkstemp_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <unistd.h>
++struct foo { int foo; } xx;
++extern int mkstemp (struct foo*);
++int
++main ()
++{
++mkstemp(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_mkstemp_noproto=yes"
++else
++  eval "ac_cv_func_mkstemp_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_mkstemp_noproto" >&5
++$as_echo "$ac_cv_func_mkstemp_noproto" >&6; }
++if test "$ac_cv_func_mkstemp_noproto" = yes; then
++
++$as_echo "#define NEED_MKSTEMP_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++
++if test "$ac_cv_func_getusershell+set" != set -o "$ac_cv_func_getusershell" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if getusershell needs a prototype" >&5
++$as_echo_n "checking if getusershell needs a prototype... " >&6; }
++if test "${ac_cv_func_getusershell_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <unistd.h>
++struct foo { int foo; } xx;
++extern int getusershell (struct foo*);
++int
++main ()
++{
++getusershell(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_getusershell_noproto=yes"
++else
++  eval "ac_cv_func_getusershell_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_getusershell_noproto" >&5
++$as_echo "$ac_cv_func_getusershell_noproto" >&6; }
++if test "$ac_cv_func_getusershell_noproto" = yes; then
++
++$as_echo "#define NEED_GETUSERSHELL_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++
++if test "$ac_cv_func_daemon+set" != set -o "$ac_cv_func_daemon" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if daemon needs a prototype" >&5
++$as_echo_n "checking if daemon needs a prototype... " >&6; }
++if test "${ac_cv_func_daemon_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <unistd.h>
++struct foo { int foo; } xx;
++extern int daemon (struct foo*);
++int
++main ()
++{
++daemon(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_daemon_noproto=yes"
++else
++  eval "ac_cv_func_daemon_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_daemon_noproto" >&5
++$as_echo "$ac_cv_func_daemon_noproto" >&6; }
++if test "$ac_cv_func_daemon_noproto" = yes; then
++
++$as_echo "#define NEED_DAEMON_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++
++if test "$ac_cv_func_iruserok+set" != set -o "$ac_cv_func_iruserok" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if iruserok needs a prototype" >&5
++$as_echo_n "checking if iruserok needs a prototype... " >&6; }
++if test "${ac_cv_func_iruserok_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_INET_H
++#include <arpa/inet.h>
++#endif
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_UNISTD_H
++#include <unistd.h>
++#endif
++struct foo { int foo; } xx;
++extern int iruserok (struct foo*);
++int
++main ()
++{
++iruserok(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_iruserok_noproto=yes"
++else
++  eval "ac_cv_func_iruserok_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_iruserok_noproto" >&5
++$as_echo "$ac_cv_func_iruserok_noproto" >&6; }
++if test "$ac_cv_func_iruserok_noproto" = yes; then
++
++$as_echo "#define NEED_IRUSEROK_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++
++
++if test "$ac_cv_func_inet_aton+set" != set -o "$ac_cv_func_inet_aton" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if inet_aton needs a prototype" >&5
++$as_echo_n "checking if inet_aton needs a prototype... " >&6; }
++if test "${ac_cv_func_inet_aton_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_INET_H
++#include <arpa/inet.h>
++#endif
++struct foo { int foo; } xx;
++extern int inet_aton (struct foo*);
++int
++main ()
++{
++inet_aton(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_inet_aton_noproto=yes"
++else
++  eval "ac_cv_func_inet_aton_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_inet_aton_noproto" >&5
++$as_echo "$ac_cv_func_inet_aton_noproto" >&6; }
++if test "$ac_cv_func_inet_aton_noproto" = yes; then
++
++$as_echo "#define NEED_INET_ATON_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for crypt" >&5
++$as_echo_n "checking for crypt... " >&6; }
++if test "${ac_cv_funclib_crypt+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_crypt\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" crypt; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++crypt()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_crypt=$ac_lib; else ac_cv_funclib_crypt=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_crypt=\${ac_cv_funclib_crypt-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_crypt"
++
++if false; then
++	for ac_func in crypt
++do :
++  ac_fn_c_check_func "$LINENO" "crypt" "ac_cv_func_crypt"
++if test "x$ac_cv_func_crypt" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_CRYPT 1
++_ACEOF
++
++fi
++done
++
++fi
++# crypt
++eval "ac_tr_func=HAVE_`echo crypt | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_crypt=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_crypt=yes"
++	eval "LIB_crypt="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_crypt=no"
++	eval "LIB_crypt="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_crypt=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if strerror_r is compatible with system prototype" >&5
++$as_echo_n "checking if strerror_r is compatible with system prototype... " >&6; }
++if test "${ac_cv_func_strerror_r_proto_compat+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <stdio.h>
++#include <string.h>
++
++int
++main ()
++{
++int strerror_r(int, char *, size_t)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_strerror_r_proto_compat=yes"
++else
++  eval "ac_cv_func_strerror_r_proto_compat=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_strerror_r_proto_compat" >&5
++$as_echo "$ac_cv_func_strerror_r_proto_compat" >&6; }
++
++if test "$ac_cv_func_strerror_r_proto_compat" = yes; then
++
++$as_echo "#define STRERROR_R_PROTO_COMPATIBLE 1" >>confdefs.h
++
++fi
++
++
++
++ac_fn_c_check_func "$LINENO" "strerror_r" "ac_cv_func_strerror_r"
++if test "x$ac_cv_func_strerror_r" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRERROR_R 1
++_ACEOF
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if gethostbyname is compatible with system prototype" >&5
++$as_echo_n "checking if gethostbyname is compatible with system prototype... " >&6; }
++if test "${ac_cv_func_gethostbyname_proto_compat+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_INET_H
++#include <arpa/inet.h>
++#endif
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++
++int
++main ()
++{
++struct hostent *gethostbyname(const char *)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_gethostbyname_proto_compat=yes"
++else
++  eval "ac_cv_func_gethostbyname_proto_compat=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_gethostbyname_proto_compat" >&5
++$as_echo "$ac_cv_func_gethostbyname_proto_compat" >&6; }
++
++if test "$ac_cv_func_gethostbyname_proto_compat" = yes; then
++
++$as_echo "#define GETHOSTBYNAME_PROTO_COMPATIBLE 1" >>confdefs.h
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if gethostbyaddr is compatible with system prototype" >&5
++$as_echo_n "checking if gethostbyaddr is compatible with system prototype... " >&6; }
++if test "${ac_cv_func_gethostbyaddr_proto_compat+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_INET_H
++#include <arpa/inet.h>
++#endif
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++
++int
++main ()
++{
++struct hostent *gethostbyaddr(const void *, size_t, int)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_gethostbyaddr_proto_compat=yes"
++else
++  eval "ac_cv_func_gethostbyaddr_proto_compat=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_gethostbyaddr_proto_compat" >&5
++$as_echo "$ac_cv_func_gethostbyaddr_proto_compat" >&6; }
++
++if test "$ac_cv_func_gethostbyaddr_proto_compat" = yes; then
++
++$as_echo "#define GETHOSTBYADDR_PROTO_COMPATIBLE 1" >>confdefs.h
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if getservbyname is compatible with system prototype" >&5
++$as_echo_n "checking if getservbyname is compatible with system prototype... " >&6; }
++if test "${ac_cv_func_getservbyname_proto_compat+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_NETINET_IN_H
++#include <netinet/in.h>
++#endif
++#ifdef HAVE_ARPA_INET_H
++#include <arpa/inet.h>
++#endif
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++
++int
++main ()
++{
++struct servent *getservbyname(const char *, const char *)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_getservbyname_proto_compat=yes"
++else
++  eval "ac_cv_func_getservbyname_proto_compat=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_getservbyname_proto_compat" >&5
++$as_echo "$ac_cv_func_getservbyname_proto_compat" >&6; }
++
++if test "$ac_cv_func_getservbyname_proto_compat" = yes; then
++
++$as_echo "#define GETSERVBYNAME_PROTO_COMPATIBLE 1" >>confdefs.h
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if getsockname is compatible with system prototype" >&5
++$as_echo_n "checking if getsockname is compatible with system prototype... " >&6; }
++if test "${ac_cv_func_getsockname_proto_compat+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++
++int
++main ()
++{
++int getsockname(int, struct sockaddr*, socklen_t*)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_getsockname_proto_compat=yes"
++else
++  eval "ac_cv_func_getsockname_proto_compat=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_getsockname_proto_compat" >&5
++$as_echo "$ac_cv_func_getsockname_proto_compat" >&6; }
++
++if test "$ac_cv_func_getsockname_proto_compat" = yes; then
++
++$as_echo "#define GETSOCKNAME_PROTO_COMPATIBLE 1" >>confdefs.h
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if openlog is compatible with system prototype" >&5
++$as_echo_n "checking if openlog is compatible with system prototype... " >&6; }
++if test "${ac_cv_func_openlog_proto_compat+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_SYSLOG_H
++#include <syslog.h>
++#endif
++
++int
++main ()
++{
++void openlog(const char *, int, int)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_openlog_proto_compat=yes"
++else
++  eval "ac_cv_func_openlog_proto_compat=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_openlog_proto_compat" >&5
++$as_echo "$ac_cv_func_openlog_proto_compat" >&6; }
++
++if test "$ac_cv_func_openlog_proto_compat" = yes; then
++
++$as_echo "#define OPENLOG_PROTO_COMPATIBLE 1" >>confdefs.h
++
++fi
++
++
++
++
++if test "$ac_cv_func_crypt+set" != set -o "$ac_cv_func_crypt" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if crypt needs a prototype" >&5
++$as_echo_n "checking if crypt needs a prototype... " >&6; }
++if test "${ac_cv_func_crypt_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_CRYPT_H
++#include <crypt.h>
++#endif
++#ifdef HAVE_UNISTD_H
++#include <unistd.h>
++#endif
++
++struct foo { int foo; } xx;
++extern int crypt (struct foo*);
++int
++main ()
++{
++crypt(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_crypt_noproto=yes"
++else
++  eval "ac_cv_func_crypt_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_crypt_noproto" >&5
++$as_echo "$ac_cv_func_crypt_noproto" >&6; }
++if test "$ac_cv_func_crypt_noproto" = yes; then
++
++$as_echo "#define NEED_CRYPT_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for h_errno" >&5
++$as_echo_n "checking for h_errno... " >&6; }
++if test "${ac_cv_var_h_errno+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++
++	cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++
++	void * foo(void) { return &h_errno; }
++int
++main ()
++{
++foo()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var_h_errno=yes
++else
++  ac_cv_var_h_errno=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++if test "$ac_cv_var_h_errno" != yes ; then
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++
++extern int h_errno;
++int foo(void) { return h_errno; }
++int
++main ()
++{
++foo()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var_h_errno=yes
++else
++  ac_cv_var_h_errno=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++
++fi
++
++ac_foo=`eval echo \\$ac_cv_var_h_errno`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_H_ERRNO 1
++_ACEOF
++
++	ac_fn_c_check_decl "$LINENO" "h_errno" "ac_cv_have_decl_h_errno" "#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++
++"
++if test "x$ac_cv_have_decl_h_errno" = x""yes; then :
++  ac_have_decl=1
++else
++  ac_have_decl=0
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_DECL_H_ERRNO $ac_have_decl
++_ACEOF
++
++fi
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for h_errlist" >&5
++$as_echo_n "checking for h_errlist... " >&6; }
++if test "${ac_cv_var_h_errlist+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++
++	cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++	void * foo(void) { return &h_errlist; }
++int
++main ()
++{
++foo()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var_h_errlist=yes
++else
++  ac_cv_var_h_errlist=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++if test "$ac_cv_var_h_errlist" != yes ; then
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++extern int h_errlist;
++int foo(void) { return h_errlist; }
++int
++main ()
++{
++foo()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var_h_errlist=yes
++else
++  ac_cv_var_h_errlist=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++
++fi
++
++ac_foo=`eval echo \\$ac_cv_var_h_errlist`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_H_ERRLIST 1
++_ACEOF
++
++	ac_fn_c_check_decl "$LINENO" "h_errlist" "ac_cv_have_decl_h_errlist" "#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++"
++if test "x$ac_cv_have_decl_h_errlist" = x""yes; then :
++  ac_have_decl=1
++else
++  ac_have_decl=0
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_DECL_H_ERRLIST $ac_have_decl
++_ACEOF
++
++fi
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for h_nerr" >&5
++$as_echo_n "checking for h_nerr... " >&6; }
++if test "${ac_cv_var_h_nerr+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++
++	cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++	void * foo(void) { return &h_nerr; }
++int
++main ()
++{
++foo()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var_h_nerr=yes
++else
++  ac_cv_var_h_nerr=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++if test "$ac_cv_var_h_nerr" != yes ; then
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++extern int h_nerr;
++int foo(void) { return h_nerr; }
++int
++main ()
++{
++foo()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var_h_nerr=yes
++else
++  ac_cv_var_h_nerr=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++
++fi
++
++ac_foo=`eval echo \\$ac_cv_var_h_nerr`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_H_NERR 1
++_ACEOF
++
++	ac_fn_c_check_decl "$LINENO" "h_nerr" "ac_cv_have_decl_h_nerr" "#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++"
++if test "x$ac_cv_have_decl_h_nerr" = x""yes; then :
++  ac_have_decl=1
++else
++  ac_have_decl=0
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_DECL_H_NERR $ac_have_decl
++_ACEOF
++
++fi
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for __progname" >&5
++$as_echo_n "checking for __progname... " >&6; }
++if test "${ac_cv_var___progname+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++
++	cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_ERR_H
++#include <err.h>
++#endif
++	void * foo(void) { return &__progname; }
++int
++main ()
++{
++foo()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var___progname=yes
++else
++  ac_cv_var___progname=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++if test "$ac_cv_var___progname" != yes ; then
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_ERR_H
++#include <err.h>
++#endif
++extern int __progname;
++int foo(void) { return __progname; }
++int
++main ()
++{
++foo()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var___progname=yes
++else
++  ac_cv_var___progname=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++
++fi
++
++ac_foo=`eval echo \\$ac_cv_var___progname`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE___PROGNAME 1
++_ACEOF
++
++	ac_fn_c_check_decl "$LINENO" "__progname" "ac_cv_have_decl___progname" "#ifdef HAVE_ERR_H
++#include <err.h>
++#endif
++"
++if test "x$ac_cv_have_decl___progname" = x""yes; then :
++  ac_have_decl=1
++else
++  ac_have_decl=0
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_DECL___PROGNAME $ac_have_decl
++_ACEOF
++
++fi
++
++
++ac_fn_c_check_decl "$LINENO" "optarg" "ac_cv_have_decl_optarg" "
++#include <stdlib.h>
++#ifdef HAVE_UNISTD_H
++#include <unistd.h>
++#endif
++"
++if test "x$ac_cv_have_decl_optarg" = x""yes; then :
++  ac_have_decl=1
++else
++  ac_have_decl=0
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_DECL_OPTARG $ac_have_decl
++_ACEOF
++ac_fn_c_check_decl "$LINENO" "optind" "ac_cv_have_decl_optind" "
++#include <stdlib.h>
++#ifdef HAVE_UNISTD_H
++#include <unistd.h>
++#endif
++"
++if test "x$ac_cv_have_decl_optind" = x""yes; then :
++  ac_have_decl=1
++else
++  ac_have_decl=0
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_DECL_OPTIND $ac_have_decl
++_ACEOF
++ac_fn_c_check_decl "$LINENO" "opterr" "ac_cv_have_decl_opterr" "
++#include <stdlib.h>
++#ifdef HAVE_UNISTD_H
++#include <unistd.h>
++#endif
++"
++if test "x$ac_cv_have_decl_opterr" = x""yes; then :
++  ac_have_decl=1
++else
++  ac_have_decl=0
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_DECL_OPTERR $ac_have_decl
++_ACEOF
++ac_fn_c_check_decl "$LINENO" "optopt" "ac_cv_have_decl_optopt" "
++#include <stdlib.h>
++#ifdef HAVE_UNISTD_H
++#include <unistd.h>
++#endif
++"
++if test "x$ac_cv_have_decl_optopt" = x""yes; then :
++  ac_have_decl=1
++else
++  ac_have_decl=0
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_DECL_OPTOPT $ac_have_decl
++_ACEOF
++ac_fn_c_check_decl "$LINENO" "environ" "ac_cv_have_decl_environ" "
++#include <stdlib.h>
++#ifdef HAVE_UNISTD_H
++#include <unistd.h>
++#endif
++"
++if test "x$ac_cv_have_decl_environ" = x""yes; then :
++  ac_have_decl=1
++else
++  ac_have_decl=0
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_DECL_ENVIRON $ac_have_decl
++_ACEOF
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for tm_gmtoff in struct tm" >&5
++$as_echo_n "checking for tm_gmtoff in struct tm... " >&6; }
++if test "${ac_cv_type_struct_tm_tm_gmtoff+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <time.h>
++int
++main ()
++{
++struct tm x; memset(&x, 0, sizeof(x)); x.tm_gmtoff
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_tm_tm_gmtoff=yes
++else
++  ac_cv_type_struct_tm_tm_gmtoff=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_tm_tm_gmtoff" >&5
++$as_echo "$ac_cv_type_struct_tm_tm_gmtoff" >&6; }
++if test "$ac_cv_type_struct_tm_tm_gmtoff" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_TM_TM_GMTOFF 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for tm_zone in struct tm" >&5
++$as_echo_n "checking for tm_zone in struct tm... " >&6; }
++if test "${ac_cv_type_struct_tm_tm_zone+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <time.h>
++int
++main ()
++{
++struct tm x; memset(&x, 0, sizeof(x)); x.tm_zone
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_tm_tm_zone=yes
++else
++  ac_cv_type_struct_tm_tm_zone=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_tm_tm_zone" >&5
++$as_echo "$ac_cv_type_struct_tm_tm_zone" >&6; }
++if test "$ac_cv_type_struct_tm_tm_zone" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_TM_TM_ZONE 1" >>confdefs.h
++
++
++fi
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for timezone" >&5
++$as_echo_n "checking for timezone... " >&6; }
++if test "${ac_cv_var_timezone+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++
++	cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <time.h>
++	void * foo(void) { return &timezone; }
++int
++main ()
++{
++foo()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var_timezone=yes
++else
++  ac_cv_var_timezone=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++if test "$ac_cv_var_timezone" != yes ; then
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <time.h>
++extern int timezone;
++int foo(void) { return timezone; }
++int
++main ()
++{
++foo()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var_timezone=yes
++else
++  ac_cv_var_timezone=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++
++fi
++
++ac_foo=`eval echo \\$ac_cv_var_timezone`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_TIMEZONE 1
++_ACEOF
++
++	ac_fn_c_check_decl "$LINENO" "timezone" "ac_cv_have_decl_timezone" "#include <time.h>
++"
++if test "x$ac_cv_have_decl_timezone" = x""yes; then :
++  ac_have_decl=1
++else
++  ac_have_decl=0
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_DECL_TIMEZONE $ac_have_decl
++_ACEOF
++
++fi
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for altzone" >&5
++$as_echo_n "checking for altzone... " >&6; }
++if test "${ac_cv_var_altzone+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++
++	cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <time.h>
++	void * foo(void) { return &altzone; }
++int
++main ()
++{
++foo()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var_altzone=yes
++else
++  ac_cv_var_altzone=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++if test "$ac_cv_var_altzone" != yes ; then
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <time.h>
++extern int altzone;
++int foo(void) { return altzone; }
++int
++main ()
++{
++foo()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_var_altzone=yes
++else
++  ac_cv_var_altzone=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++
++fi
++
++ac_foo=`eval echo \\$ac_cv_var_altzone`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_ALTZONE 1
++_ACEOF
++
++	ac_fn_c_check_decl "$LINENO" "altzone" "ac_cv_have_decl_altzone" "#include <time.h>
++"
++if test "x$ac_cv_have_decl_altzone" = x""yes; then :
++  ac_have_decl=1
++else
++  ac_have_decl=0
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_DECL_ALTZONE $ac_have_decl
++_ACEOF
++
++fi
++
++
++
++
++cv=`echo "sa_family_t" | sed 'y%./+- %__p__%'`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for sa_family_t" >&5
++$as_echo_n "checking for sa_family_t... " >&6; }
++if eval "test \"\${ac_cv_type_$cv+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/types.h>
++#if STDC_HEADERS
++#include <stdlib.h>
++#include <stddef.h>
++#endif
++
++#include <sys/types.h>
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++int
++main ()
++{
++sa_family_t foo;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_type_$cv=yes"
++else
++  eval "ac_cv_type_$cv=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++ac_foo=`eval echo \\$ac_cv_type_$cv`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++  ac_tr_hdr=HAVE_`echo sa_family_t | sed 'y%abcdefghijklmnopqrstuvwxyz./- %ABCDEFGHIJKLMNOPQRSTUVWXYZ____%'`
++if false; then
++	ac_fn_c_check_type "$LINENO" "sa_family_t" "ac_cv_type_sa_family_t" "$ac_includes_default"
++if test "x$ac_cv_type_sa_family_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_SA_FAMILY_T 1
++_ACEOF
++
++
++fi
++
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define $ac_tr_hdr 1
++_ACEOF
++
++fi
++
++
++
++cv=`echo "socklen_t" | sed 'y%./+- %__p__%'`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for socklen_t" >&5
++$as_echo_n "checking for socklen_t... " >&6; }
++if eval "test \"\${ac_cv_type_$cv+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/types.h>
++#if STDC_HEADERS
++#include <stdlib.h>
++#include <stddef.h>
++#endif
++
++#include <sys/types.h>
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++int
++main ()
++{
++socklen_t foo;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_type_$cv=yes"
++else
++  eval "ac_cv_type_$cv=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++ac_foo=`eval echo \\$ac_cv_type_$cv`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++  ac_tr_hdr=HAVE_`echo socklen_t | sed 'y%abcdefghijklmnopqrstuvwxyz./- %ABCDEFGHIJKLMNOPQRSTUVWXYZ____%'`
++if false; then
++	ac_fn_c_check_type "$LINENO" "socklen_t" "ac_cv_type_socklen_t" "$ac_includes_default"
++if test "x$ac_cv_type_socklen_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_SOCKLEN_T 1
++_ACEOF
++
++
++fi
++
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define $ac_tr_hdr 1
++_ACEOF
++
++fi
++
++
++
++cv=`echo "struct sockaddr" | sed 'y%./+- %__p__%'`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for struct sockaddr" >&5
++$as_echo_n "checking for struct sockaddr... " >&6; }
++if eval "test \"\${ac_cv_type_$cv+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/types.h>
++#if STDC_HEADERS
++#include <stdlib.h>
++#include <stddef.h>
++#endif
++
++#include <sys/types.h>
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++int
++main ()
++{
++struct sockaddr foo;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_type_$cv=yes"
++else
++  eval "ac_cv_type_$cv=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++ac_foo=`eval echo \\$ac_cv_type_$cv`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++  ac_tr_hdr=HAVE_`echo struct sockaddr | sed 'y%abcdefghijklmnopqrstuvwxyz./- %ABCDEFGHIJKLMNOPQRSTUVWXYZ____%'`
++if false; then
++	ac_fn_c_check_type "$LINENO" "struct sockaddr" "ac_cv_type_struct_sockaddr" "$ac_includes_default"
++if test "x$ac_cv_type_struct_sockaddr" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRUCT_SOCKADDR 1
++_ACEOF
++
++
++fi
++
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define $ac_tr_hdr 1
++_ACEOF
++
++fi
++
++
++
++cv=`echo "struct sockaddr_storage" | sed 'y%./+- %__p__%'`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for struct sockaddr_storage" >&5
++$as_echo_n "checking for struct sockaddr_storage... " >&6; }
++if eval "test \"\${ac_cv_type_$cv+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/types.h>
++#if STDC_HEADERS
++#include <stdlib.h>
++#include <stddef.h>
++#endif
++
++#include <sys/types.h>
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++int
++main ()
++{
++struct sockaddr_storage foo;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_type_$cv=yes"
++else
++  eval "ac_cv_type_$cv=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++ac_foo=`eval echo \\$ac_cv_type_$cv`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++  ac_tr_hdr=HAVE_`echo struct sockaddr_storage | sed 'y%abcdefghijklmnopqrstuvwxyz./- %ABCDEFGHIJKLMNOPQRSTUVWXYZ____%'`
++if false; then
++	ac_fn_c_check_type "$LINENO" "struct sockaddr_storage" "ac_cv_type_struct_sockaddr_storage" "$ac_includes_default"
++if test "x$ac_cv_type_struct_sockaddr_storage" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRUCT_SOCKADDR_STORAGE 1
++_ACEOF
++
++
++fi
++
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define $ac_tr_hdr 1
++_ACEOF
++
++fi
++
++
++
++cv=`echo "struct addrinfo" | sed 'y%./+- %__p__%'`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for struct addrinfo" >&5
++$as_echo_n "checking for struct addrinfo... " >&6; }
++if eval "test \"\${ac_cv_type_$cv+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/types.h>
++#if STDC_HEADERS
++#include <stdlib.h>
++#include <stddef.h>
++#endif
++
++#include <sys/types.h>
++#ifdef HAVE_NETDB_H
++#include <netdb.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++int
++main ()
++{
++struct addrinfo foo;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_type_$cv=yes"
++else
++  eval "ac_cv_type_$cv=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++ac_foo=`eval echo \\$ac_cv_type_$cv`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++  ac_tr_hdr=HAVE_`echo struct addrinfo | sed 'y%abcdefghijklmnopqrstuvwxyz./- %ABCDEFGHIJKLMNOPQRSTUVWXYZ____%'`
++if false; then
++	ac_fn_c_check_type "$LINENO" "struct addrinfo" "ac_cv_type_struct_addrinfo" "$ac_includes_default"
++if test "x$ac_cv_type_struct_addrinfo" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRUCT_ADDRINFO 1
++_ACEOF
++
++
++fi
++
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define $ac_tr_hdr 1
++_ACEOF
++
++fi
++
++
++
++cv=`echo "struct ifaddrs" | sed 'y%./+- %__p__%'`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for struct ifaddrs" >&5
++$as_echo_n "checking for struct ifaddrs... " >&6; }
++if eval "test \"\${ac_cv_type_$cv+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/types.h>
++#if STDC_HEADERS
++#include <stdlib.h>
++#include <stddef.h>
++#endif
++#include <ifaddrs.h>
++int
++main ()
++{
++struct ifaddrs foo;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_type_$cv=yes"
++else
++  eval "ac_cv_type_$cv=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++ac_foo=`eval echo \\$ac_cv_type_$cv`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++  ac_tr_hdr=HAVE_`echo struct ifaddrs | sed 'y%abcdefghijklmnopqrstuvwxyz./- %ABCDEFGHIJKLMNOPQRSTUVWXYZ____%'`
++if false; then
++	ac_fn_c_check_type "$LINENO" "struct ifaddrs" "ac_cv_type_struct_ifaddrs" "$ac_includes_default"
++if test "x$ac_cv_type_struct_ifaddrs" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRUCT_IFADDRS 1
++_ACEOF
++
++
++fi
++
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define $ac_tr_hdr 1
++_ACEOF
++
++fi
++
++
++
++cv=`echo "struct iovec" | sed 'y%./+- %__p__%'`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for struct iovec" >&5
++$as_echo_n "checking for struct iovec... " >&6; }
++if eval "test \"\${ac_cv_type_$cv+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/types.h>
++#if STDC_HEADERS
++#include <stdlib.h>
++#include <stddef.h>
++#endif
++
++#include <sys/types.h>
++#include <sys/uio.h>
++
++int
++main ()
++{
++struct iovec foo;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_type_$cv=yes"
++else
++  eval "ac_cv_type_$cv=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++ac_foo=`eval echo \\$ac_cv_type_$cv`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++  ac_tr_hdr=HAVE_`echo struct iovec | sed 'y%abcdefghijklmnopqrstuvwxyz./- %ABCDEFGHIJKLMNOPQRSTUVWXYZ____%'`
++if false; then
++	ac_fn_c_check_type "$LINENO" "struct iovec" "ac_cv_type_struct_iovec" "$ac_includes_default"
++if test "x$ac_cv_type_struct_iovec" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRUCT_IOVEC 1
++_ACEOF
++
++
++fi
++
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define $ac_tr_hdr 1
++_ACEOF
++
++fi
++
++
++
++cv=`echo "struct msghdr" | sed 'y%./+- %__p__%'`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for struct msghdr" >&5
++$as_echo_n "checking for struct msghdr... " >&6; }
++if eval "test \"\${ac_cv_type_$cv+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/types.h>
++#if STDC_HEADERS
++#include <stdlib.h>
++#include <stddef.h>
++#endif
++
++#include <sys/types.h>
++#ifdef HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++#ifdef HAVE_WS2TCPIP_H
++#include <ws2tcpip.h>
++#endif
++int
++main ()
++{
++struct msghdr foo;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_type_$cv=yes"
++else
++  eval "ac_cv_type_$cv=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++ac_foo=`eval echo \\$ac_cv_type_$cv`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++  ac_tr_hdr=HAVE_`echo struct msghdr | sed 'y%abcdefghijklmnopqrstuvwxyz./- %ABCDEFGHIJKLMNOPQRSTUVWXYZ____%'`
++if false; then
++	ac_fn_c_check_type "$LINENO" "struct msghdr" "ac_cv_type_struct_msghdr" "$ac_includes_default"
++if test "x$ac_cv_type_struct_msghdr" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_STRUCT_MSGHDR 1
++_ACEOF
++
++
++fi
++
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define $ac_tr_hdr 1
++_ACEOF
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for struct winsize" >&5
++$as_echo_n "checking for struct winsize... " >&6; }
++if test "${ac_cv_struct_winsize+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++ac_cv_struct_winsize=no
++for i in sys/termios.h sys/ioctl.h; do
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <$i>
++
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "struct[ 	]*winsize" >/dev/null 2>&1; then :
++  ac_cv_struct_winsize=yes; break
++fi
++rm -f conftest*
++done
++
++fi
++
++if test "$ac_cv_struct_winsize" = "yes"; then
++
++$as_echo "#define HAVE_STRUCT_WINSIZE 1" >>confdefs.h
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_struct_winsize" >&5
++$as_echo "$ac_cv_struct_winsize" >&6; }
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <termios.h>
++
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "ws_xpixel" >/dev/null 2>&1; then :
++
++$as_echo "#define HAVE_WS_XPIXEL 1" >>confdefs.h
++
++fi
++rm -f conftest*
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <termios.h>
++
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "ws_ypixel" >/dev/null 2>&1; then :
++
++$as_echo "#define HAVE_WS_YPIXEL 1" >>confdefs.h
++
++fi
++rm -f conftest*
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for struct spwd" >&5
++$as_echo_n "checking for struct spwd... " >&6; }
++if test "${ac_cv_struct_spwd+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <pwd.h>
++#ifdef HAVE_SHADOW_H
++#include <shadow.h>
++#endif
++int
++main ()
++{
++struct spwd foo;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_struct_spwd=yes
++else
++  ac_cv_struct_spwd=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_struct_spwd" >&5
++$as_echo "$ac_cv_struct_spwd" >&6; }
++
++if test "$ac_cv_struct_spwd" = "yes"; then
++
++$as_echo "#define HAVE_STRUCT_SPWD 1" >>confdefs.h
++
++fi
++
++
++#
++# Check if we want samba's socket wrapper
++#
++
++
++
++# Check whether --enable-socket-wrapper was given.
++if test "${enable_socket_wrapper+set}" = set; then :
++  enableval=$enable_socket_wrapper;
++fi
++
++
++ if test "x$enable_socket_wrapper" = xyes; then
++  have_socket_wrapper_TRUE=
++  have_socket_wrapper_FALSE='#'
++else
++  have_socket_wrapper_TRUE='#'
++  have_socket_wrapper_FALSE=
++fi
++
++if test "x$enable_socket_wrapper" = xyes ; then
++
++$as_echo "#define SOCKET_WRAPPER_REPLACE 1" >>confdefs.h
++
++fi
++
++
++
++
++LIB_roken="${LIB_roken} \$(LIB_crypt) \$(LIB_dbopen)"
++
++
++LIBADD_roken="$LIB_roken"
++LIB_roken="\$(top_builddir)/lib/vers/libvers.la $LIB_roken"
++
++
++# Check whether --enable-otp was given.
++if test "${enable_otp+set}" = set; then :
++  enableval=$enable_otp;
++fi
++
++if test "$enable_otp" = yes -a "$db_type" = unknown; then
++	as_fn_error $? "OTP requires a NDBM/DB compatible library" "$LINENO" 5
++fi
++if test "$enable_otp" != no; then
++	if test "$db_type" != unknown; then
++		enable_otp=yes
++	else
++		enable_otp=no
++	fi
++fi
++if test "$enable_otp" = yes; then
++
++$as_echo "#define OTP 1" >>confdefs.h
++
++	LIB_otp='$(top_builddir)/lib/otp/libotp.la'
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether to enable OTP library" >&5
++$as_echo_n "checking whether to enable OTP library... " >&6; }
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $enable_otp" >&5
++$as_echo "$enable_otp" >&6; }
++ if test "$enable_otp" = yes; then
++  OTP_TRUE=
++  OTP_FALSE='#'
++else
++  OTP_TRUE='#'
++  OTP_FALSE=
++fi
++
++
++
++
++for ac_header in dispatch/dispatch.h
++do :
++  ac_fn_c_check_header_mongrel "$LINENO" "dispatch/dispatch.h" "ac_cv_header_dispatch_dispatch_h" "$ac_includes_default"
++if test "x$ac_cv_header_dispatch_dispatch_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_DISPATCH_DISPATCH_H 1
++_ACEOF
++
++fi
++
++done
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for dispatch_async_f" >&5
++$as_echo_n "checking for dispatch_async_f... " >&6; }
++if test "${ac_cv_funclib_dispatch_async_f+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_dispatch_async_f\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" dispatch; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifdef HAVE_DISPATCH_DISPATCH_H
++#include <dispatch/dispatch.h>
++#endif
++int
++main ()
++{
++dispatch_async_f(0,0,0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_dispatch_async_f=$ac_lib; else ac_cv_funclib_dispatch_async_f=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_dispatch_async_f=\${ac_cv_funclib_dispatch_async_f-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_dispatch_async_f"
++
++if false; then
++	for ac_func in dispatch_async_f
++do :
++  ac_fn_c_check_func "$LINENO" "dispatch_async_f" "ac_cv_func_dispatch_async_f"
++if test "x$ac_cv_func_dispatch_async_f" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_DISPATCH_ASYNC_F 1
++_ACEOF
++
++fi
++done
++
++fi
++# dispatch_async_f
++eval "ac_tr_func=HAVE_`echo dispatch_async_f | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_dispatch_async_f=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_dispatch_async_f=yes"
++	eval "LIB_dispatch_async_f="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_dispatch_async_f=no"
++	eval "LIB_dispatch_async_f="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_dispatch_async_f=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++if test "$ac_cv_func_dispatch_async_f" = yes ; then
++
++$as_echo "#define HAVE_GCD 1" >>confdefs.h
++
++    libdispatch=yes
++else
++    libdispatch=no
++fi
++
++ if test "$libdispatch" = yes; then
++  have_gcd_TRUE=
++  have_gcd_FALSE='#'
++else
++  have_gcd_TRUE='#'
++  have_gcd_FALSE=
++fi
++
++
++
++
++
++# Check whether --enable-osfc2 was given.
++if test "${enable_osfc2+set}" = set; then :
++  enableval=$enable_osfc2;
++fi
++
++LIB_security=
++if test "$enable_osfc2" = yes; then
++
++$as_echo "#define HAVE_OSFC2 1" >>confdefs.h
++
++	LIB_security=-lsecurity
++fi
++
++
++
++# Check whether --enable-mmap was given.
++if test "${enable_mmap+set}" = set; then :
++  enableval=$enable_mmap;
++fi
++
++if test "$enable_mmap" = "no"; then
++
++$as_echo "#define NO_MMAP 1" >>confdefs.h
++
++fi
++
++# Check whether --enable-afs-string-to-key was given.
++if test "${enable_afs_string_to_key+set}" = set; then :
++  enableval=$enable_afs_string_to_key;
++else
++  enable_afs_string_to_key=yes
++fi
++
++
++if test "$enable_afs_string_to_key" = "yes"; then
++
++$as_echo "#define ENABLE_AFS_STRING_TO_KEY 1" >>confdefs.h
++
++fi
++
++
++# Extract the first word of "nroff", so it can be a program name with args.
++set dummy nroff; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_path_NROFF+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  case $NROFF in
++  [\\/]* | ?:[\\/]*)
++  ac_cv_path_NROFF="$NROFF" # Let the user override the test with a path.
++  ;;
++  *)
++  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_path_NROFF="$as_dir/$ac_word$ac_exec_ext"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++  ;;
++esac
++fi
++NROFF=$ac_cv_path_NROFF
++if test -n "$NROFF"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $NROFF" >&5
++$as_echo "$NROFF" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++# Extract the first word of "groff", so it can be a program name with args.
++set dummy groff; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_path_GROFF+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  case $GROFF in
++  [\\/]* | ?:[\\/]*)
++  ac_cv_path_GROFF="$GROFF" # Let the user override the test with a path.
++  ;;
++  *)
++  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_path_GROFF="$as_dir/$ac_word$ac_exec_ext"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++  ;;
++esac
++fi
++GROFF=$ac_cv_path_GROFF
++if test -n "$GROFF"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $GROFF" >&5
++$as_echo "$GROFF" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking how to format man pages" >&5
++$as_echo_n "checking how to format man pages... " >&6; }
++if test "${ac_cv_sys_man_format+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat > conftest.1 << END
++.Dd January 1, 1970
++.Dt CONFTEST 1
++.Sh NAME
++.Nm conftest
++.Nd
++foobar
++END
++
++if test "$NROFF" ; then
++	for i in "-mdoc" "-mandoc"; do
++		if "$NROFF" $i conftest.1 2> /dev/null | \
++			grep Jan > /dev/null 2>&1 ; then
++			ac_cv_sys_man_format="$NROFF $i"
++			break
++		fi
++	done
++fi
++if test "$ac_cv_sys_man_format" = "" -a "$GROFF" ; then
++	for i in "-mdoc" "-mandoc"; do
++		if "$GROFF" -Tascii $i conftest.1 2> /dev/null | \
++			grep Jan > /dev/null 2>&1 ; then
++			ac_cv_sys_man_format="$GROFF -Tascii $i"
++			break
++		fi
++	done
++fi
++if test "$ac_cv_sys_man_format"; then
++	ac_cv_sys_man_format="$ac_cv_sys_man_format \$< > \$@"
++fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_sys_man_format" >&5
++$as_echo "$ac_cv_sys_man_format" >&6; }
++if test "$ac_cv_sys_man_format"; then
++	CATMAN="$ac_cv_sys_man_format"
++
++fi
++ if test "$CATMAN"; then
++  CATMAN_TRUE=
++  CATMAN_FALSE='#'
++else
++  CATMAN_TRUE='#'
++  CATMAN_FALSE=
++fi
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking extension of pre-formatted manual pages" >&5
++$as_echo_n "checking extension of pre-formatted manual pages... " >&6; }
++if test "${ac_cv_sys_catman_ext+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if grep _suffix /etc/man.conf > /dev/null 2>&1; then
++	ac_cv_sys_catman_ext=0
++else
++	ac_cv_sys_catman_ext=number
++fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_sys_catman_ext" >&5
++$as_echo "$ac_cv_sys_catman_ext" >&6; }
++if test "$ac_cv_sys_catman_ext" = number; then
++	CATMANEXT='$$section'
++else
++	CATMANEXT=0
++fi
++
++
++
++
++
++# Check whether --with-readline was given.
++if test "${with_readline+set}" = set; then :
++  withval=$with_readline;
++fi
++
++
++# Check whether --with-readline-lib was given.
++if test "${with_readline_lib+set}" = set; then :
++  withval=$with_readline_lib; if test "$withval" = "yes" -o "$withval" = "no"; then
++  as_fn_error $? "No argument for --with-readline-lib" "$LINENO" 5
++elif test "X$with_readline" = "X"; then
++  with_readline=yes
++fi
++fi
++
++
++# Check whether --with-readline-include was given.
++if test "${with_readline_include+set}" = set; then :
++  withval=$with_readline_include; if test "$withval" = "yes" -o "$withval" = "no"; then
++  as_fn_error $? "No argument for --with-readline-include" "$LINENO" 5
++elif test "X$with_readline" = "X"; then
++  with_readline=yes
++fi
++fi
++
++
++# Check whether --with-readline-config was given.
++if test "${with_readline_config+set}" = set; then :
++  withval=$with_readline_config;
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for readline" >&5
++$as_echo_n "checking for readline... " >&6; }
++
++case "$with_readline" in
++yes|"") d='' ;;
++no)	d= ;;
++*)	d="$with_readline" ;;
++esac
++
++header_dirs=
++lib_dirs=
++for i in $d; do
++	if test "$with_readline_include" = ""; then
++		if test -d "$i/include/readline"; then
++			header_dirs="$header_dirs $i/include/readline"
++		fi
++		if test -d "$i/include"; then
++			header_dirs="$header_dirs $i/include"
++		fi
++	fi
++	if test "$with_readline_lib" = ""; then
++		if test -d "$i/lib$abilibdirext"; then
++			lib_dirs="$lib_dirs $i/lib$abilibdirext"
++		fi
++	fi
++done
++
++if test "$with_readline_include"; then
++	header_dirs="$with_readline_include $header_dirs"
++fi
++if test "$with_readline_lib"; then
++	lib_dirs="$with_readline_lib $lib_dirs"
++fi
++
++if test "$with_readline_config" = ""; then
++	with_readline_config=''
++fi
++
++readline_cflags=
++readline_libs=
++
++case "$with_readline_config" in
++yes|no|""|"")
++	if test -f $with_readline/bin/ ; then
++		with_readline_config=$with_readline/bin/
++	fi
++	;;
++esac
++
++case "$with_readline_config" in
++yes|no|"")
++	;;
++*)
++	readline_cflags="`$with_readline_config --cflags 2>&1`"
++	readline_libs="`$with_readline_config --libs 2>&1`"
++	;;
++esac
++
++found=no
++if test "$with_readline" != no; then
++	save_CFLAGS="$CFLAGS"
++	save_LIBS="$LIBS"
++	if test "$readline_cflags" -a "$readline_libs"; then
++		CFLAGS="$readline_cflags $save_CFLAGS"
++		LIBS="$readline_libs $save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdio.h>
++ #include <readline.h>
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++
++			INCLUDE_readline="$readline_cflags"
++			LIB_readline="$readline_libs"
++			{ $as_echo "$as_me:${as_lineno-$LINENO}: result: from $with_readline_config" >&5
++$as_echo "from $with_readline_config" >&6; }
++			found=yes
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	fi
++	if test "$found" = no; then
++		ires= lres=
++		for i in $header_dirs; do
++			CFLAGS="-I$i $save_CFLAGS"
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdio.h>
++ #include <readline.h>
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ires=$i;break
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++		done
++		for i in $lib_dirs; do
++			LIBS="-L$i -ledit  $save_LIBS"
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdio.h>
++ #include <readline.h>
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  lres=$i;break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++		done
++		if test "$ires" -a "$lres" -a "$with_readline" != "no"; then
++			INCLUDE_readline="-I$ires"
++			LIB_readline="-L$lres -ledit "
++			found=yes
++			{ $as_echo "$as_me:${as_lineno-$LINENO}: result: headers $ires, libraries $lres" >&5
++$as_echo "headers $ires, libraries $lres" >&6; }
++		fi
++	fi
++	CFLAGS="$save_CFLAGS"
++	LIBS="$save_LIBS"
++fi
++
++if test "$found" = yes; then
++
++cat >>confdefs.h <<_ACEOF
++#define READLINE 1
++_ACEOF
++
++	with_readline=yes
++else
++	with_readline=no
++	INCLUDE_readline=
++	LIB_readline=
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++
++
++
++
++
++# Check whether --with-hesiod was given.
++if test "${with_hesiod+set}" = set; then :
++  withval=$with_hesiod;
++fi
++
++
++# Check whether --with-hesiod-lib was given.
++if test "${with_hesiod_lib+set}" = set; then :
++  withval=$with_hesiod_lib; if test "$withval" = "yes" -o "$withval" = "no"; then
++  as_fn_error $? "No argument for --with-hesiod-lib" "$LINENO" 5
++elif test "X$with_hesiod" = "X"; then
++  with_hesiod=yes
++fi
++fi
++
++
++# Check whether --with-hesiod-include was given.
++if test "${with_hesiod_include+set}" = set; then :
++  withval=$with_hesiod_include; if test "$withval" = "yes" -o "$withval" = "no"; then
++  as_fn_error $? "No argument for --with-hesiod-include" "$LINENO" 5
++elif test "X$with_hesiod" = "X"; then
++  with_hesiod=yes
++fi
++fi
++
++
++# Check whether --with-hesiod-config was given.
++if test "${with_hesiod_config+set}" = set; then :
++  withval=$with_hesiod_config;
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for hesiod" >&5
++$as_echo_n "checking for hesiod... " >&6; }
++
++case "$with_hesiod" in
++yes|"") d='' ;;
++no)	d= ;;
++*)	d="$with_hesiod" ;;
++esac
++
++header_dirs=
++lib_dirs=
++for i in $d; do
++	if test "$with_hesiod_include" = ""; then
++		if test -d "$i/include/hesiod"; then
++			header_dirs="$header_dirs $i/include/hesiod"
++		fi
++		if test -d "$i/include"; then
++			header_dirs="$header_dirs $i/include"
++		fi
++	fi
++	if test "$with_hesiod_lib" = ""; then
++		if test -d "$i/lib$abilibdirext"; then
++			lib_dirs="$lib_dirs $i/lib$abilibdirext"
++		fi
++	fi
++done
++
++if test "$with_hesiod_include"; then
++	header_dirs="$with_hesiod_include $header_dirs"
++fi
++if test "$with_hesiod_lib"; then
++	lib_dirs="$with_hesiod_lib $lib_dirs"
++fi
++
++if test "$with_hesiod_config" = ""; then
++	with_hesiod_config=''
++fi
++
++hesiod_cflags=
++hesiod_libs=
++
++case "$with_hesiod_config" in
++yes|no|""|"")
++	if test -f $with_hesiod/bin/ ; then
++		with_hesiod_config=$with_hesiod/bin/
++	fi
++	;;
++esac
++
++case "$with_hesiod_config" in
++yes|no|"")
++	;;
++*)
++	hesiod_cflags="`$with_hesiod_config --cflags 2>&1`"
++	hesiod_libs="`$with_hesiod_config --libs 2>&1`"
++	;;
++esac
++
++found=no
++if test "$with_hesiod" != no; then
++	save_CFLAGS="$CFLAGS"
++	save_LIBS="$LIBS"
++	if test "$hesiod_cflags" -a "$hesiod_libs"; then
++		CFLAGS="$hesiod_cflags $save_CFLAGS"
++		LIBS="$hesiod_libs $save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <hesiod.h>
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++
++			INCLUDE_hesiod="$hesiod_cflags"
++			LIB_hesiod="$hesiod_libs"
++			{ $as_echo "$as_me:${as_lineno-$LINENO}: result: from $with_hesiod_config" >&5
++$as_echo "from $with_hesiod_config" >&6; }
++			found=yes
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	fi
++	if test "$found" = no; then
++		ires= lres=
++		for i in $header_dirs; do
++			CFLAGS="-I$i $save_CFLAGS"
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <hesiod.h>
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ires=$i;break
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++		done
++		for i in $lib_dirs; do
++			LIBS="-L$i -lhesiod  $save_LIBS"
++			cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <hesiod.h>
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  lres=$i;break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++		done
++		if test "$ires" -a "$lres" -a "$with_hesiod" != "no"; then
++			INCLUDE_hesiod="-I$ires"
++			LIB_hesiod="-L$lres -lhesiod "
++			found=yes
++			{ $as_echo "$as_me:${as_lineno-$LINENO}: result: headers $ires, libraries $lres" >&5
++$as_echo "headers $ires, libraries $lres" >&6; }
++		fi
++	fi
++	CFLAGS="$save_CFLAGS"
++	LIBS="$save_LIBS"
++fi
++
++if test "$found" = yes; then
++
++cat >>confdefs.h <<_ACEOF
++#define HESIOD 1
++_ACEOF
++
++	with_hesiod=yes
++else
++	with_hesiod=no
++	INCLUDE_hesiod=
++	LIB_hesiod=
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++
++
++
++
++# Check whether --enable-bigendian was given.
++if test "${enable_bigendian+set}" = set; then :
++  enableval=$enable_bigendian; krb_cv_c_bigendian=yes
++fi
++
++# Check whether --enable-littleendian was given.
++if test "${enable_littleendian+set}" = set; then :
++  enableval=$enable_littleendian; krb_cv_c_bigendian=no
++fi
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether byte order is known at compile time" >&5
++$as_echo_n "checking whether byte order is known at compile time... " >&6; }
++if test "${krb_cv_c_bigendian_compile+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/types.h>
++#include <sys/param.h>
++#if !BYTE_ORDER || !BIG_ENDIAN || !LITTLE_ENDIAN
++ bogus endian macros
++#endif
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  krb_cv_c_bigendian_compile=yes
++else
++  krb_cv_c_bigendian_compile=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $krb_cv_c_bigendian_compile" >&5
++$as_echo "$krb_cv_c_bigendian_compile" >&6; }
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether byte ordering is bigendian" >&5
++$as_echo_n "checking whether byte ordering is bigendian... " >&6; }
++if test "${krb_cv_c_bigendian+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++  if test "$krb_cv_c_bigendian_compile" = "yes"; then
++    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/types.h>
++#include <sys/param.h>
++#if BYTE_ORDER != BIG_ENDIAN
++  not big endian
++#endif
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  krb_cv_c_bigendian=yes
++else
++  krb_cv_c_bigendian=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++  else
++    if test "$cross_compiling" = yes; then :
++  as_fn_error $? "specify either --enable-bigendian or --enable-littleendian" "$LINENO" 5
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++main (int argc, char **argv) {
++      /* Are we little or big endian?  From Harbison&Steele.  */
++      union
++      {
++	long l;
++	char c[sizeof (long)];
++    } u;
++    u.l = 1;
++    exit (u.c[sizeof (long) - 1] == 1);
++  }
++_ACEOF
++if ac_fn_c_try_run "$LINENO"; then :
++  krb_cv_c_bigendian=no
++else
++  krb_cv_c_bigendian=yes
++fi
++rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
++  conftest.$ac_objext conftest.beam conftest.$ac_ext
++fi
++
++  fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $krb_cv_c_bigendian" >&5
++$as_echo "$krb_cv_c_bigendian" >&6; }
++if test "$krb_cv_c_bigendian" = "yes"; then
++
++$as_echo "#define WORDS_BIGENDIAN 1" >>confdefs.h
++fi
++if test "$krb_cv_c_bigendian_compile" = "yes"; then
++
++$as_echo "#define ENDIANESS_IN_SYS_PARAM_H 1" >>confdefs.h
++fi
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for inline" >&5
++$as_echo_n "checking for inline... " >&6; }
++if test "${ac_cv_c_inline+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_cv_c_inline=no
++for ac_kw in inline __inline__ __inline; do
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#ifndef __cplusplus
++typedef int foo_t;
++static $ac_kw foo_t static_foo () {return 0; }
++$ac_kw foo_t foo () {return 0; }
++#endif
++
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_c_inline=$ac_kw
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++  test "$ac_cv_c_inline" != no && break
++done
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_c_inline" >&5
++$as_echo "$ac_cv_c_inline" >&6; }
++
++case $ac_cv_c_inline in
++  inline | yes) ;;
++  *)
++    case $ac_cv_c_inline in
++      no) ac_val=;;
++      *) ac_val=$ac_cv_c_inline;;
++    esac
++    cat >>confdefs.h <<_ACEOF
++#ifndef __cplusplus
++#define inline $ac_val
++#endif
++_ACEOF
++    ;;
++esac
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for X" >&5
++$as_echo_n "checking for X... " >&6; }
++
++
++# Check whether --with-x was given.
++if test "${with_x+set}" = set; then :
++  withval=$with_x;
++fi
++
++# $have_x is `yes', `no', `disabled', or empty when we do not yet know.
++if test "x$with_x" = xno; then
++  # The user explicitly disabled X.
++  have_x=disabled
++else
++  case $x_includes,$x_libraries in #(
++    *\'*) as_fn_error $? "cannot use X directory names containing '" "$LINENO" 5 ;; #(
++    *,NONE | NONE,*) if test "${ac_cv_have_x+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  # One or both of the vars are not set, and there is no cached value.
++ac_x_includes=no ac_x_libraries=no
++rm -f -r conftest.dir
++if mkdir conftest.dir; then
++  cd conftest.dir
++  cat >Imakefile <<'_ACEOF'
++incroot:
++	@echo incroot='${INCROOT}'
++usrlibdir:
++	@echo usrlibdir='${USRLIBDIR}'
++libdir:
++	@echo libdir='${LIBDIR}'
++_ACEOF
++  if (export CC; ${XMKMF-xmkmf}) >/dev/null 2>/dev/null && test -f Makefile; then
++    # GNU make sometimes prints "make[1]: Entering ...", which would confuse us.
++    for ac_var in incroot usrlibdir libdir; do
++      eval "ac_im_$ac_var=\`\${MAKE-make} $ac_var 2>/dev/null | sed -n 's/^$ac_var=//p'\`"
++    done
++    # Open Windows xmkmf reportedly sets LIBDIR instead of USRLIBDIR.
++    for ac_extension in a so sl dylib la dll; do
++      if test ! -f "$ac_im_usrlibdir/libX11.$ac_extension" &&
++	 test -f "$ac_im_libdir/libX11.$ac_extension"; then
++	ac_im_usrlibdir=$ac_im_libdir; break
++      fi
++    done
++    # Screen out bogus values from the imake configuration.  They are
++    # bogus both because they are the default anyway, and because
++    # using them would break gcc on systems where it needs fixed includes.
++    case $ac_im_incroot in
++	/usr/include) ac_x_includes= ;;
++	*) test -f "$ac_im_incroot/X11/Xos.h" && ac_x_includes=$ac_im_incroot;;
++    esac
++    case $ac_im_usrlibdir in
++	/usr/lib | /usr/lib64 | /lib | /lib64) ;;
++	*) test -d "$ac_im_usrlibdir" && ac_x_libraries=$ac_im_usrlibdir ;;
++    esac
++  fi
++  cd ..
++  rm -f -r conftest.dir
++fi
++
++# Standard set of common directories for X headers.
++# Check X11 before X11Rn because it is often a symlink to the current release.
++ac_x_header_dirs='
++/usr/X11/include
++/usr/X11R7/include
++/usr/X11R6/include
++/usr/X11R5/include
++/usr/X11R4/include
++
++/usr/include/X11
++/usr/include/X11R7
++/usr/include/X11R6
++/usr/include/X11R5
++/usr/include/X11R4
++
++/usr/local/X11/include
++/usr/local/X11R7/include
++/usr/local/X11R6/include
++/usr/local/X11R5/include
++/usr/local/X11R4/include
++
++/usr/local/include/X11
++/usr/local/include/X11R7
++/usr/local/include/X11R6
++/usr/local/include/X11R5
++/usr/local/include/X11R4
++
++/usr/X386/include
++/usr/x386/include
++/usr/XFree86/include/X11
++
++/usr/include
++/usr/local/include
++/usr/unsupported/include
++/usr/athena/include
++/usr/local/x11r5/include
++/usr/lpp/Xamples/include
++
++/usr/openwin/include
++/usr/openwin/share/include'
++
++if test "$ac_x_includes" = no; then
++  # Guess where to find include files, by looking for Xlib.h.
++  # First, try using that file with no special directory specified.
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <X11/Xlib.h>
++_ACEOF
++if ac_fn_c_try_cpp "$LINENO"; then :
++  # We can compile using X headers with no special include directory.
++ac_x_includes=
++else
++  for ac_dir in $ac_x_header_dirs; do
++  if test -r "$ac_dir/X11/Xlib.h"; then
++    ac_x_includes=$ac_dir
++    break
++  fi
++done
++fi
++rm -f conftest.err conftest.i conftest.$ac_ext
++fi # $ac_x_includes = no
++
++if test "$ac_x_libraries" = no; then
++  # Check for the libraries.
++  # See if we find them without any special options.
++  # Don't add to $LIBS permanently.
++  ac_save_LIBS=$LIBS
++  LIBS="-lX11 $LIBS"
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <X11/Xlib.h>
++int
++main ()
++{
++XrmInitialize ()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  LIBS=$ac_save_LIBS
++# We can link X programs with no special library path.
++ac_x_libraries=
++else
++  LIBS=$ac_save_LIBS
++for ac_dir in `$as_echo "$ac_x_includes $ac_x_header_dirs" | sed s/include/lib/g`
++do
++  # Don't even attempt the hair of trying to link an X program!
++  for ac_extension in a so sl dylib la dll; do
++    if test -r "$ac_dir/libX11.$ac_extension"; then
++      ac_x_libraries=$ac_dir
++      break 2
++    fi
++  done
++done
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi # $ac_x_libraries = no
++
++case $ac_x_includes,$ac_x_libraries in #(
++  no,* | *,no | *\'*)
++    # Didn't find X, or a directory has "'" in its name.
++    ac_cv_have_x="have_x=no";; #(
++  *)
++    # Record where we found X for the cache.
++    ac_cv_have_x="have_x=yes\
++	ac_x_includes='$ac_x_includes'\
++	ac_x_libraries='$ac_x_libraries'"
++esac
++fi
++;; #(
++    *) have_x=yes;;
++  esac
++  eval "$ac_cv_have_x"
++fi # $with_x != no
++
++if test "$have_x" != yes; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $have_x" >&5
++$as_echo "$have_x" >&6; }
++  no_x=yes
++else
++  # If each of the values was on the command line, it overrides each guess.
++  test "x$x_includes" = xNONE && x_includes=$ac_x_includes
++  test "x$x_libraries" = xNONE && x_libraries=$ac_x_libraries
++  # Update the cache value to reflect the command line values.
++  ac_cv_have_x="have_x=yes\
++	ac_x_includes='$x_includes'\
++	ac_x_libraries='$x_libraries'"
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: libraries $x_libraries, headers $x_includes" >&5
++$as_echo "libraries $x_libraries, headers $x_includes" >&6; }
++fi
++
++
++if test "$no_x" = yes; then
++  # Not all programs may use this symbol, but it does not hurt to define it.
++
++$as_echo "#define X_DISPLAY_MISSING 1" >>confdefs.h
++
++  X_CFLAGS= X_PRE_LIBS= X_LIBS= X_EXTRA_LIBS=
++else
++  if test -n "$x_includes"; then
++    X_CFLAGS="$X_CFLAGS -I$x_includes"
++  fi
++
++  # It would also be nice to do this for all -L options, not just this one.
++  if test -n "$x_libraries"; then
++    X_LIBS="$X_LIBS -L$x_libraries"
++    # For Solaris; some versions of Sun CC require a space after -R and
++    # others require no space.  Words are not sufficient . . . .
++    { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether -R must be followed by a space" >&5
++$as_echo_n "checking whether -R must be followed by a space... " >&6; }
++    ac_xsave_LIBS=$LIBS; LIBS="$LIBS -R$x_libraries"
++    ac_xsave_c_werror_flag=$ac_c_werror_flag
++    ac_c_werror_flag=yes
++    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++       X_LIBS="$X_LIBS -R$x_libraries"
++else
++  LIBS="$ac_xsave_LIBS -R $x_libraries"
++       cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	  X_LIBS="$X_LIBS -R $x_libraries"
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: neither works" >&5
++$as_echo "neither works" >&6; }
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++    ac_c_werror_flag=$ac_xsave_c_werror_flag
++    LIBS=$ac_xsave_LIBS
++  fi
++
++  # Check for system-dependent libraries X programs must link with.
++  # Do this before checking for the system-independent R6 libraries
++  # (-lICE), since we may need -lsocket or whatever for X linking.
++
++  if test "$ISC" = yes; then
++    X_EXTRA_LIBS="$X_EXTRA_LIBS -lnsl_s -linet"
++  else
++    # Martyn Johnson says this is needed for Ultrix, if the X
++    # libraries were built with DECnet support.  And Karl Berry says
++    # the Alpha needs dnet_stub (dnet does not exist).
++    ac_xsave_LIBS="$LIBS"; LIBS="$LIBS $X_LIBS -lX11"
++    cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char XOpenDisplay ();
++int
++main ()
++{
++return XOpenDisplay ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for dnet_ntoa in -ldnet" >&5
++$as_echo_n "checking for dnet_ntoa in -ldnet... " >&6; }
++if test "${ac_cv_lib_dnet_dnet_ntoa+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_check_lib_save_LIBS=$LIBS
++LIBS="-ldnet  $LIBS"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char dnet_ntoa ();
++int
++main ()
++{
++return dnet_ntoa ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_dnet_dnet_ntoa=yes
++else
++  ac_cv_lib_dnet_dnet_ntoa=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++LIBS=$ac_check_lib_save_LIBS
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_dnet_dnet_ntoa" >&5
++$as_echo "$ac_cv_lib_dnet_dnet_ntoa" >&6; }
++if test "x$ac_cv_lib_dnet_dnet_ntoa" = x""yes; then :
++  X_EXTRA_LIBS="$X_EXTRA_LIBS -ldnet"
++fi
++
++    if test $ac_cv_lib_dnet_dnet_ntoa = no; then
++      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for dnet_ntoa in -ldnet_stub" >&5
++$as_echo_n "checking for dnet_ntoa in -ldnet_stub... " >&6; }
++if test "${ac_cv_lib_dnet_stub_dnet_ntoa+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_check_lib_save_LIBS=$LIBS
++LIBS="-ldnet_stub  $LIBS"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char dnet_ntoa ();
++int
++main ()
++{
++return dnet_ntoa ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_dnet_stub_dnet_ntoa=yes
++else
++  ac_cv_lib_dnet_stub_dnet_ntoa=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++LIBS=$ac_check_lib_save_LIBS
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_dnet_stub_dnet_ntoa" >&5
++$as_echo "$ac_cv_lib_dnet_stub_dnet_ntoa" >&6; }
++if test "x$ac_cv_lib_dnet_stub_dnet_ntoa" = x""yes; then :
++  X_EXTRA_LIBS="$X_EXTRA_LIBS -ldnet_stub"
++fi
++
++    fi
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++    LIBS="$ac_xsave_LIBS"
++
++    # msh@cis.ufl.edu says -lnsl (and -lsocket) are needed for his 386/AT,
++    # to get the SysV transport functions.
++    # Chad R. Larson says the Pyramis MIS-ES running DC/OSx (SVR4)
++    # needs -lnsl.
++    # The nsl library prevents programs from opening the X display
++    # on Irix 5.2, according to T.E. Dickey.
++    # The functions gethostbyname, getservbyname, and inet_addr are
++    # in -lbsd on LynxOS 3.0.1/i386, according to Lars Hecking.
++    ac_fn_c_check_func "$LINENO" "gethostbyname" "ac_cv_func_gethostbyname"
++if test "x$ac_cv_func_gethostbyname" = x""yes; then :
++
++fi
++
++    if test $ac_cv_func_gethostbyname = no; then
++      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for gethostbyname in -lnsl" >&5
++$as_echo_n "checking for gethostbyname in -lnsl... " >&6; }
++if test "${ac_cv_lib_nsl_gethostbyname+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_check_lib_save_LIBS=$LIBS
++LIBS="-lnsl  $LIBS"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char gethostbyname ();
++int
++main ()
++{
++return gethostbyname ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_nsl_gethostbyname=yes
++else
++  ac_cv_lib_nsl_gethostbyname=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++LIBS=$ac_check_lib_save_LIBS
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_nsl_gethostbyname" >&5
++$as_echo "$ac_cv_lib_nsl_gethostbyname" >&6; }
++if test "x$ac_cv_lib_nsl_gethostbyname" = x""yes; then :
++  X_EXTRA_LIBS="$X_EXTRA_LIBS -lnsl"
++fi
++
++      if test $ac_cv_lib_nsl_gethostbyname = no; then
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for gethostbyname in -lbsd" >&5
++$as_echo_n "checking for gethostbyname in -lbsd... " >&6; }
++if test "${ac_cv_lib_bsd_gethostbyname+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_check_lib_save_LIBS=$LIBS
++LIBS="-lbsd  $LIBS"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char gethostbyname ();
++int
++main ()
++{
++return gethostbyname ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_bsd_gethostbyname=yes
++else
++  ac_cv_lib_bsd_gethostbyname=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++LIBS=$ac_check_lib_save_LIBS
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_bsd_gethostbyname" >&5
++$as_echo "$ac_cv_lib_bsd_gethostbyname" >&6; }
++if test "x$ac_cv_lib_bsd_gethostbyname" = x""yes; then :
++  X_EXTRA_LIBS="$X_EXTRA_LIBS -lbsd"
++fi
++
++      fi
++    fi
++
++    # lieder@skyler.mavd.honeywell.com says without -lsocket,
++    # socket/setsockopt and other routines are undefined under SCO ODT
++    # 2.0.  But -lsocket is broken on IRIX 5.2 (and is not necessary
++    # on later versions), says Simon Leinen: it contains gethostby*
++    # variants that don't use the name server (or something).  -lsocket
++    # must be given before -lnsl if both are needed.  We assume that
++    # if connect needs -lnsl, so does gethostbyname.
++    ac_fn_c_check_func "$LINENO" "connect" "ac_cv_func_connect"
++if test "x$ac_cv_func_connect" = x""yes; then :
++
++fi
++
++    if test $ac_cv_func_connect = no; then
++      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for connect in -lsocket" >&5
++$as_echo_n "checking for connect in -lsocket... " >&6; }
++if test "${ac_cv_lib_socket_connect+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_check_lib_save_LIBS=$LIBS
++LIBS="-lsocket $X_EXTRA_LIBS $LIBS"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char connect ();
++int
++main ()
++{
++return connect ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_socket_connect=yes
++else
++  ac_cv_lib_socket_connect=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++LIBS=$ac_check_lib_save_LIBS
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_socket_connect" >&5
++$as_echo "$ac_cv_lib_socket_connect" >&6; }
++if test "x$ac_cv_lib_socket_connect" = x""yes; then :
++  X_EXTRA_LIBS="-lsocket $X_EXTRA_LIBS"
++fi
++
++    fi
++
++    # Guillermo Gomez says -lposix is necessary on A/UX.
++    ac_fn_c_check_func "$LINENO" "remove" "ac_cv_func_remove"
++if test "x$ac_cv_func_remove" = x""yes; then :
++
++fi
++
++    if test $ac_cv_func_remove = no; then
++      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for remove in -lposix" >&5
++$as_echo_n "checking for remove in -lposix... " >&6; }
++if test "${ac_cv_lib_posix_remove+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_check_lib_save_LIBS=$LIBS
++LIBS="-lposix  $LIBS"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char remove ();
++int
++main ()
++{
++return remove ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_posix_remove=yes
++else
++  ac_cv_lib_posix_remove=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++LIBS=$ac_check_lib_save_LIBS
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_posix_remove" >&5
++$as_echo "$ac_cv_lib_posix_remove" >&6; }
++if test "x$ac_cv_lib_posix_remove" = x""yes; then :
++  X_EXTRA_LIBS="$X_EXTRA_LIBS -lposix"
++fi
++
++    fi
++
++    # BSDI BSD/OS 2.1 needs -lipc for XOpenDisplay.
++    ac_fn_c_check_func "$LINENO" "shmat" "ac_cv_func_shmat"
++if test "x$ac_cv_func_shmat" = x""yes; then :
++
++fi
++
++    if test $ac_cv_func_shmat = no; then
++      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for shmat in -lipc" >&5
++$as_echo_n "checking for shmat in -lipc... " >&6; }
++if test "${ac_cv_lib_ipc_shmat+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_check_lib_save_LIBS=$LIBS
++LIBS="-lipc  $LIBS"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char shmat ();
++int
++main ()
++{
++return shmat ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_ipc_shmat=yes
++else
++  ac_cv_lib_ipc_shmat=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++LIBS=$ac_check_lib_save_LIBS
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ipc_shmat" >&5
++$as_echo "$ac_cv_lib_ipc_shmat" >&6; }
++if test "x$ac_cv_lib_ipc_shmat" = x""yes; then :
++  X_EXTRA_LIBS="$X_EXTRA_LIBS -lipc"
++fi
++
++    fi
++  fi
++
++  # Check for libraries that X11R6 Xt/Xaw programs need.
++  ac_save_LDFLAGS=$LDFLAGS
++  test -n "$x_libraries" && LDFLAGS="$LDFLAGS -L$x_libraries"
++  # SM needs ICE to (dynamically) link under SunOS 4.x (so we have to
++  # check for ICE first), but we must link in the order -lSM -lICE or
++  # we get undefined symbols.  So assume we have SM if we have ICE.
++  # These have to be linked with before -lX11, unlike the other
++  # libraries we check for below, so use a different variable.
++  # John Interrante, Karl Berry
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for IceConnectionNumber in -lICE" >&5
++$as_echo_n "checking for IceConnectionNumber in -lICE... " >&6; }
++if test "${ac_cv_lib_ICE_IceConnectionNumber+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_check_lib_save_LIBS=$LIBS
++LIBS="-lICE $X_EXTRA_LIBS $LIBS"
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++/* Override any GCC internal prototype to avoid an error.
++   Use char because int might match the return type of a GCC
++   builtin and then its argument prototype would still apply.  */
++#ifdef __cplusplus
++extern "C"
++#endif
++char IceConnectionNumber ();
++int
++main ()
++{
++return IceConnectionNumber ();
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_cv_lib_ICE_IceConnectionNumber=yes
++else
++  ac_cv_lib_ICE_IceConnectionNumber=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++LIBS=$ac_check_lib_save_LIBS
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_lib_ICE_IceConnectionNumber" >&5
++$as_echo "$ac_cv_lib_ICE_IceConnectionNumber" >&6; }
++if test "x$ac_cv_lib_ICE_IceConnectionNumber" = x""yes; then :
++  X_PRE_LIBS="$X_PRE_LIBS -lSM -lICE"
++fi
++
++  LDFLAGS=$ac_save_LDFLAGS
++
++fi
++
++
++# try to figure out if we need any additional ld flags, like -R
++# and yes, the autoconf X test is utterly broken
++if test "$no_x" != yes; then
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for special X linker flags" >&5
++$as_echo_n "checking for special X linker flags... " >&6; }
++if test "${krb_cv_sys_x_libs_rpath+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++	ac_save_libs="$LIBS"
++	ac_save_cflags="$CFLAGS"
++	CFLAGS="$CFLAGS $X_CFLAGS"
++	krb_cv_sys_x_libs_rpath=""
++	krb_cv_sys_x_libs=""
++	for rflag in "" "-R" "-R " "-rpath "; do
++		if test "$rflag" = ""; then
++			foo="$X_LIBS"
++		else
++			foo=""
++			for flag in $X_LIBS; do
++			case $flag in
++			-L*)
++				foo="$foo $flag `echo $flag | sed \"s/-L/$rflag/\"`"
++				;;
++			*)
++				foo="$foo $flag"
++				;;
++			esac
++			done
++		fi
++		LIBS="$ac_save_libs $foo $X_PRE_LIBS -lX11 $X_EXTRA_LIBS"
++		if test "$cross_compiling" = yes; then :
++  krb_cv_sys_x_libs_rpath="" ; krb_cv_sys_x_libs="" ; break
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++		#include <X11/Xlib.h>
++		foo(void)
++		{
++		XOpenDisplay(NULL);
++		}
++		main(int argc, char **argv)
++		{
++		return 0;
++		}
++
++_ACEOF
++if ac_fn_c_try_run "$LINENO"; then :
++  krb_cv_sys_x_libs_rpath="$rflag"; krb_cv_sys_x_libs="$foo"; break
++else
++  :
++fi
++rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
++  conftest.$ac_objext conftest.beam conftest.$ac_ext
++fi
++
++	done
++	LIBS="$ac_save_libs"
++	CFLAGS="$ac_save_cflags"
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $krb_cv_sys_x_libs_rpath" >&5
++$as_echo "$krb_cv_sys_x_libs_rpath" >&6; }
++	X_LIBS="$krb_cv_sys_x_libs"
++fi
++
++
++ if test "$no_x" != yes; then
++  HAVE_X_TRUE=
++  HAVE_X_FALSE='#'
++else
++  HAVE_X_TRUE='#'
++  HAVE_X_FALSE=
++fi
++
++
++
++save_CFLAGS="$CFLAGS"
++CFLAGS="$X_CFLAGS $CFLAGS"
++save_LIBS="$LIBS"
++LIBS="$X_PRE_LIBS $X_EXTRA_LIBS $LIBS"
++save_LDFLAGS="$LDFLAGS"
++LDFLAGS="$LDFLAGS $X_LIBS"
++
++## check for XauWriteAuth first, so we detect the case where
++## XauReadAuth is in -lX11, but XauWriteAuth is only in -lXau this
++## could be done by checking for XauReadAuth in -lXau first, but this
++## breaks in IRIX 6.5
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for XauWriteAuth" >&5
++$as_echo_n "checking for XauWriteAuth... " >&6; }
++if test "${ac_cv_funclib_XauWriteAuth+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_XauWriteAuth\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" X11 Xau; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <X11/Xauth.h>
++int
++main ()
++{
++XauWriteAuth(0,0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_XauWriteAuth=$ac_lib; else ac_cv_funclib_XauWriteAuth=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_XauWriteAuth=\${ac_cv_funclib_XauWriteAuth-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_XauWriteAuth"
++
++if false; then
++	for ac_func in XauWriteAuth
++do :
++  ac_fn_c_check_func "$LINENO" "XauWriteAuth" "ac_cv_func_XauWriteAuth"
++if test "x$ac_cv_func_XauWriteAuth" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_XAUWRITEAUTH 1
++_ACEOF
++
++fi
++done
++
++fi
++# XauWriteAuth
++eval "ac_tr_func=HAVE_`echo XauWriteAuth | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_XauWriteAuth=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_XauWriteAuth=yes"
++	eval "LIB_XauWriteAuth="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_XauWriteAuth=no"
++	eval "LIB_XauWriteAuth="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_XauWriteAuth=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++ac_xxx="$LIBS"
++LIBS="$LIB_XauWriteAuth $LIBS"
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for XauReadAuth" >&5
++$as_echo_n "checking for XauReadAuth... " >&6; }
++if test "${ac_cv_funclib_XauReadAuth+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_XauReadAuth\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" X11 Xau; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <X11/Xauth.h>
++int
++main ()
++{
++XauReadAuth(0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_XauReadAuth=$ac_lib; else ac_cv_funclib_XauReadAuth=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_XauReadAuth=\${ac_cv_funclib_XauReadAuth-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_XauReadAuth"
++
++if false; then
++	for ac_func in XauReadAuth
++do :
++  ac_fn_c_check_func "$LINENO" "XauReadAuth" "ac_cv_func_XauReadAuth"
++if test "x$ac_cv_func_XauReadAuth" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_XAUREADAUTH 1
++_ACEOF
++
++fi
++done
++
++fi
++# XauReadAuth
++eval "ac_tr_func=HAVE_`echo XauReadAuth | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_XauReadAuth=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_XauReadAuth=yes"
++	eval "LIB_XauReadAuth="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_XauReadAuth=no"
++	eval "LIB_XauReadAuth="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_XauReadAuth=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++LIBS="$LIB_XauReadAauth $LIBS"
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for XauFileName" >&5
++$as_echo_n "checking for XauFileName... " >&6; }
++if test "${ac_cv_funclib_XauFileName+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_XauFileName\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" X11 Xau; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <X11/Xauth.h>
++int
++main ()
++{
++XauFileName()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_XauFileName=$ac_lib; else ac_cv_funclib_XauFileName=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_XauFileName=\${ac_cv_funclib_XauFileName-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_XauFileName"
++
++if false; then
++	for ac_func in XauFileName
++do :
++  ac_fn_c_check_func "$LINENO" "XauFileName" "ac_cv_func_XauFileName"
++if test "x$ac_cv_func_XauFileName" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_XAUFILENAME 1
++_ACEOF
++
++fi
++done
++
++fi
++# XauFileName
++eval "ac_tr_func=HAVE_`echo XauFileName | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_XauFileName=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_XauFileName=yes"
++	eval "LIB_XauFileName="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_XauFileName=no"
++	eval "LIB_XauFileName="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_XauFileName=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++LIBS="$ac_xxx"
++
++## set LIB_XauReadAuth to union of these tests, since this is what the
++## Makefiles are using
++case "$ac_cv_funclib_XauWriteAuth" in
++yes)	;;
++no)	;;
++*)	if test "$ac_cv_funclib_XauReadAuth" = yes; then
++		if test "$ac_cv_funclib_XauFileName" = yes; then
++			LIB_XauReadAuth="$LIB_XauWriteAuth"
++		else
++			LIB_XauReadAuth="$LIB_XauWriteAuth $LIB_XauFileName"
++		fi
++	else
++		if test "$ac_cv_funclib_XauFileName" = yes; then
++			LIB_XauReadAuth="$LIB_XauReadAuth $LIB_XauWriteAuth"
++		else
++			LIB_XauReadAuth="$LIB_XauReadAuth $LIB_XauWriteAuth $LIB_XauFileName"
++		fi
++	fi
++	;;
++esac
++
++if test "$AUTOMAKE" != ""; then
++	 if test "$ac_cv_func_XauWriteAuth" != "yes"; then
++  NEED_WRITEAUTH_TRUE=
++  NEED_WRITEAUTH_FALSE='#'
++else
++  NEED_WRITEAUTH_TRUE='#'
++  NEED_WRITEAUTH_FALSE=
++fi
++
++else
++
++
++	if test "$ac_cv_func_XauWriteAuth" != "yes"; then
++		NEED_WRITEAUTH_TRUE=
++		NEED_WRITEAUTH_FALSE='#'
++	else
++		NEED_WRITEAUTH_TRUE='#'
++		NEED_WRITEAUTH_FALSE=
++	fi
++fi
++CFLAGS=$save_CFLAGS
++LIBS=$save_LIBS
++LDFLAGS=$save_LDFLAGS
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for an ANSI C-conforming const" >&5
++$as_echo_n "checking for an ANSI C-conforming const... " >&6; }
++if test "${ac_cv_c_const+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++/* FIXME: Include the comments suggested by Paul. */
++#ifndef __cplusplus
++  /* Ultrix mips cc rejects this.  */
++  typedef int charset[2];
++  const charset cs;
++  /* SunOS 4.1.1 cc rejects this.  */
++  char const *const *pcpcc;
++  char **ppc;
++  /* NEC SVR4.0.2 mips cc rejects this.  */
++  struct point {int x, y;};
++  static struct point const zero = {0,0};
++  /* AIX XL C 1.02.0.0 rejects this.
++     It does not let you subtract one const X* pointer from another in
++     an arm of an if-expression whose if-part is not a constant
++     expression */
++  const char *g = "string";
++  pcpcc = &g + (g ? g-g : 0);
++  /* HPUX 7.0 cc rejects these. */
++  ++pcpcc;
++  ppc = (char**) pcpcc;
++  pcpcc = (char const *const *) ppc;
++  { /* SCO 3.2v4 cc rejects this.  */
++    char *t;
++    char const *s = 0 ? (char *) 0 : (char const *) 0;
++
++    *t++ = 0;
++    if (s) return 0;
++  }
++  { /* Someone thinks the Sun supposedly-ANSI compiler will reject this.  */
++    int x[] = {25, 17};
++    const int *foo = &x[0];
++    ++foo;
++  }
++  { /* Sun SC1.0 ANSI compiler rejects this -- but not the above. */
++    typedef const int *iptr;
++    iptr p = 0;
++    ++p;
++  }
++  { /* AIX XL C 1.02.0.0 rejects this saying
++       "k.c", line 2.27: 1506-025 (S) Operand must be a modifiable lvalue. */
++    struct s { int j; const int *ap[3]; };
++    struct s *b; b->j = 5;
++  }
++  { /* ULTRIX-32 V3.1 (Rev 9) vcc rejects this */
++    const int foo = 10;
++    if (!foo) return 0;
++  }
++  return !cs[0] && !zero.x;
++#endif
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_c_const=yes
++else
++  ac_cv_c_const=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_c_const" >&5
++$as_echo "$ac_cv_c_const" >&6; }
++if test $ac_cv_c_const = no; then
++
++$as_echo "#define const /**/" >>confdefs.h
++
++fi
++
++ac_fn_c_check_type "$LINENO" "off_t" "ac_cv_type_off_t" "$ac_includes_default"
++if test "x$ac_cv_type_off_t" = x""yes; then :
++
++else
++
++cat >>confdefs.h <<_ACEOF
++#define off_t long int
++_ACEOF
++
++fi
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for mode_t" >&5
++$as_echo_n "checking for mode_t... " >&6; }
++if test "${ac_cv_type_mode_t+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sys/types.h>
++#if STDC_HEADERS
++#include <stdlib.h>
++#include <stddef.h>
++#endif
++
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "mode_t[^a-zA-Z_0-9]" >/dev/null 2>&1; then :
++  ac_cv_type_mode_t=yes
++else
++  ac_cv_type_mode_t=no
++fi
++rm -f conftest*
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_mode_t" >&5
++$as_echo "$ac_cv_type_mode_t" >&6; }
++if test $ac_cv_type_mode_t = no; then
++
++$as_echo "#define mode_t unsigned short" >>confdefs.h
++
++fi
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for sig_atomic_t" >&5
++$as_echo_n "checking for sig_atomic_t... " >&6; }
++if test "${ac_cv_type_sig_atomic_t+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sys/types.h>
++#if STDC_HEADERS
++#include <stdlib.h>
++#include <stddef.h>
++#endif
++#include <signal.h>
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "sig_atomic_t[^a-zA-Z_0-9]" >/dev/null 2>&1; then :
++  ac_cv_type_sig_atomic_t=yes
++else
++  ac_cv_type_sig_atomic_t=no
++fi
++rm -f conftest*
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_sig_atomic_t" >&5
++$as_echo "$ac_cv_type_sig_atomic_t" >&6; }
++if test $ac_cv_type_sig_atomic_t = no; then
++
++$as_echo "#define sig_atomic_t int" >>confdefs.h
++
++fi
++
++
++
++cv=`echo "long long" | sed 'y%./+- %__p__%'`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for long long" >&5
++$as_echo_n "checking for long long... " >&6; }
++if eval "test \"\${ac_cv_type_$cv+set}\"" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <sys/types.h>
++#if STDC_HEADERS
++#include <stdlib.h>
++#include <stddef.h>
++#endif
++
++int
++main ()
++{
++long long foo;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_type_$cv=yes"
++else
++  eval "ac_cv_type_$cv=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++ac_foo=`eval echo \\$ac_cv_type_$cv`
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_foo" >&5
++$as_echo "$ac_foo" >&6; }
++if test "$ac_foo" = yes; then
++  ac_tr_hdr=HAVE_`echo long long | sed 'y%abcdefghijklmnopqrstuvwxyz./- %ABCDEFGHIJKLMNOPQRSTUVWXYZ____%'`
++if false; then
++	ac_fn_c_check_type "$LINENO" "long long" "ac_cv_type_long_long" "$ac_includes_default"
++if test "x$ac_cv_type_long_long" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_LONG_LONG 1
++_ACEOF
++
++
++fi
++
++fi
++
++cat >>confdefs.h <<_ACEOF
++#define $ac_tr_hdr 1
++_ACEOF
++
++fi
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether time.h and sys/time.h may both be included" >&5
++$as_echo_n "checking whether time.h and sys/time.h may both be included... " >&6; }
++if test "${ac_cv_header_time+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sys/types.h>
++#include <sys/time.h>
++#include <time.h>
++
++int
++main ()
++{
++if ((struct tm *) 0)
++return 0;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_header_time=yes
++else
++  ac_cv_header_time=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_header_time" >&5
++$as_echo "$ac_cv_header_time" >&6; }
++if test $ac_cv_header_time = yes; then
++
++$as_echo "#define TIME_WITH_SYS_TIME 1" >>confdefs.h
++
++fi
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether struct tm is in sys/time.h or time.h" >&5
++$as_echo_n "checking whether struct tm is in sys/time.h or time.h... " >&6; }
++if test "${ac_cv_struct_tm+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sys/types.h>
++#include <time.h>
++
++int
++main ()
++{
++struct tm tm;
++				     int *p = &tm.tm_sec;
++				     return !p;
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_struct_tm=time.h
++else
++  ac_cv_struct_tm=sys/time.h
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_struct_tm" >&5
++$as_echo "$ac_cv_struct_tm" >&6; }
++if test $ac_cv_struct_tm = sys/time.h; then
++
++$as_echo "#define TM_IN_SYS_TIME 1" >>confdefs.h
++
++fi
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ANSI C header files" >&5
++$as_echo_n "checking for ANSI C header files... " >&6; }
++if test "${ac_cv_header_stdc+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdlib.h>
++#include <stdarg.h>
++#include <string.h>
++#include <float.h>
++
++int
++main ()
++{
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_header_stdc=yes
++else
++  ac_cv_header_stdc=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++if test $ac_cv_header_stdc = yes; then
++  # SunOS 4.x string.h does not declare mem*, contrary to ANSI.
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <string.h>
++
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "memchr" >/dev/null 2>&1; then :
++
++else
++  ac_cv_header_stdc=no
++fi
++rm -f conftest*
++
++fi
++
++if test $ac_cv_header_stdc = yes; then
++  # ISC 2.0.2 stdlib.h does not declare free, contrary to ANSI.
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdlib.h>
++
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "free" >/dev/null 2>&1; then :
++
++else
++  ac_cv_header_stdc=no
++fi
++rm -f conftest*
++
++fi
++
++if test $ac_cv_header_stdc = yes; then
++  # /bin/cc in Irix-4.0.5 gets non-ANSI ctype macros unless using -ansi.
++  if test "$cross_compiling" = yes; then :
++  :
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <ctype.h>
++#include <stdlib.h>
++#if ((' ' & 0x0FF) == 0x020)
++# define ISLOWER(c) ('a' <= (c) && (c) <= 'z')
++# define TOUPPER(c) (ISLOWER(c) ? 'A' + ((c) - 'a') : (c))
++#else
++# define ISLOWER(c) \
++		   (('a' <= (c) && (c) <= 'i') \
++		     || ('j' <= (c) && (c) <= 'r') \
++		     || ('s' <= (c) && (c) <= 'z'))
++# define TOUPPER(c) (ISLOWER(c) ? ((c) | 0x40) : (c))
++#endif
++
++#define XOR(e, f) (((e) && !(f)) || (!(e) && (f)))
++int
++main ()
++{
++  int i;
++  for (i = 0; i < 256; i++)
++    if (XOR (islower (i), ISLOWER (i))
++	|| toupper (i) != TOUPPER (i))
++      return 2;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_run "$LINENO"; then :
++
++else
++  ac_cv_header_stdc=no
++fi
++rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
++  conftest.$ac_objext conftest.beam conftest.$ac_ext
++fi
++
++fi
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_header_stdc" >&5
++$as_echo "$ac_cv_header_stdc" >&6; }
++if test $ac_cv_header_stdc = yes; then
++
++$as_echo "#define STDC_HEADERS 1" >>confdefs.h
++
++fi
++
++
++for ac_header in \
++	CommonCrypto/CommonDigest.h		\
++	CommonCrypto/CommonCryptor.h		\
++	arpa/ftp.h				\
++	arpa/telnet.h				\
++	bind/bitypes.h				\
++	bsdsetjmp.h				\
++	curses.h				\
++	dlfcn.h					\
++	fnmatch.h				\
++	inttypes.h				\
++	io.h					\
++	libutil.h				\
++	limits.h				\
++	maillock.h				\
++	netgroup.h				\
++	netinet/in6_machtypes.h			\
++	pthread.h				\
++	pty.h					\
++	sac.h					\
++	sgtty.h					\
++	siad.h					\
++	signal.h				\
++	strings.h				\
++	stropts.h				\
++	sys/bitypes.h				\
++	sys/category.h				\
++	sys/file.h				\
++	sys/filio.h				\
++	sys/ioccom.h				\
++	sys/mman.h				\
++	sys/param.h				\
++	sys/pty.h				\
++	sys/ptyio.h				\
++	sys/select.h				\
++	sys/socket.h				\
++	sys/str_tty.h				\
++	sys/stream.h				\
++	sys/stropts.h				\
++	sys/syscall.h				\
++	sys/termio.h				\
++	sys/timeb.h				\
++	sys/times.h				\
++	sys/types.h				\
++	sys/un.h				\
++	locale.h				\
++	termcap.h				\
++	termio.h				\
++	termios.h				\
++	time.h					\
++	tmpdir.h				\
++	udb.h					\
++	util.h					\
++	utmp.h					\
++	utmpx.h					\
++
++do :
++  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
++ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" "$ac_includes_default"
++if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in term.h
++do :
++  ac_fn_c_check_header_preproc "$LINENO" "term.h" "ac_cv_header_term_h"
++if test "x$ac_cv_header_term_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_TERM_H 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in asl.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "asl.h" "ac_cv_header_asl_h" "
++#include <asl.h>
++#ifndef ASL_STRING_EMERG
++#error ASL_STRING_EMERG missing
++#endif
++"
++if test "x$ac_cv_header_asl_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_ASL_H 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in net/if.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "net/if.h" "ac_cv_header_net_if_h" "$ac_includes_default
++#if HAVE_SYS_SOCKET_H
++#include <sys/socket.h>
++#endif
++"
++if test "x$ac_cv_header_net_if_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_NET_IF_H 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in sys/ptyvar.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "sys/ptyvar.h" "ac_cv_header_sys_ptyvar_h" "$ac_includes_default
++#if HAVE_SYS_TTY_H
++#include <sys/tty.h>
++#endif
++"
++if test "x$ac_cv_header_sys_ptyvar_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_SYS_PTYVAR_H 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in sys/strtty.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "sys/strtty.h" "ac_cv_header_sys_strtty_h" "$ac_includes_default
++#if HAVE_TERMIOS_H
++#include <termios.h>
++#endif
++#if HAVE_SYS_STREAM_H
++#include <sys/stream.h>
++#endif
++"
++if test "x$ac_cv_header_sys_strtty_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_SYS_STRTTY_H 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in sys/ucred.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "sys/ucred.h" "ac_cv_header_sys_ucred_h" "$ac_includes_default
++#if HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#if HAVE_SYS_PARAM_H
++#include <sys/param.h>
++#endif
++"
++if test "x$ac_cv_header_sys_ucred_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_SYS_UCRED_H 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_header in security/pam_modules.h
++do :
++  ac_fn_c_check_header_compile "$LINENO" "security/pam_modules.h" "ac_cv_header_security_pam_modules_h" "$ac_includes_default
++#include <security/pam_appl.h>
++
++"
++if test "x$ac_cv_header_security_pam_modules_h" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_SECURITY_PAM_MODULES_H 1
++_ACEOF
++
++fi
++
++done
++
++
++
++
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for logwtmp" >&5
++$as_echo_n "checking for logwtmp... " >&6; }
++if test "${ac_cv_funclib_logwtmp+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_logwtmp\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" util; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_UTIL_H
++#include <util.h>
++#endif
++
++int
++main ()
++{
++logwtmp(0,0,0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_logwtmp=$ac_lib; else ac_cv_funclib_logwtmp=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_logwtmp=\${ac_cv_funclib_logwtmp-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_logwtmp"
++
++if false; then
++	for ac_func in logwtmp
++do :
++  ac_fn_c_check_func "$LINENO" "logwtmp" "ac_cv_func_logwtmp"
++if test "x$ac_cv_func_logwtmp" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_LOGWTMP 1
++_ACEOF
++
++fi
++done
++
++fi
++# logwtmp
++eval "ac_tr_func=HAVE_`echo logwtmp | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_logwtmp=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_logwtmp=yes"
++	eval "LIB_logwtmp="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_logwtmp=no"
++	eval "LIB_logwtmp="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_logwtmp=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for logout" >&5
++$as_echo_n "checking for logout... " >&6; }
++if test "${ac_cv_funclib_logout+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_logout\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" util; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_UTIL_H
++#include <util.h>
++#endif
++
++int
++main ()
++{
++logout(0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_logout=$ac_lib; else ac_cv_funclib_logout=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_logout=\${ac_cv_funclib_logout-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_logout"
++
++if false; then
++	for ac_func in logout
++do :
++  ac_fn_c_check_func "$LINENO" "logout" "ac_cv_func_logout"
++if test "x$ac_cv_func_logout" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_LOGOUT 1
++_ACEOF
++
++fi
++done
++
++fi
++# logout
++eval "ac_tr_func=HAVE_`echo logout | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_logout=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_logout=yes"
++	eval "LIB_logout="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_logout=no"
++	eval "LIB_logout="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_logout=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for openpty" >&5
++$as_echo_n "checking for openpty... " >&6; }
++if test "${ac_cv_funclib_openpty+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_openpty\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" util; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_UTIL_H
++#include <util.h>
++#endif
++
++int
++main ()
++{
++openpty(0,0,0,0,0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_openpty=$ac_lib; else ac_cv_funclib_openpty=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_openpty=\${ac_cv_funclib_openpty-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_openpty"
++
++if false; then
++	for ac_func in openpty
++do :
++  ac_fn_c_check_func "$LINENO" "openpty" "ac_cv_func_openpty"
++if test "x$ac_cv_func_openpty" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_OPENPTY 1
++_ACEOF
++
++fi
++done
++
++fi
++# openpty
++eval "ac_tr_func=HAVE_`echo openpty | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_openpty=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_openpty=yes"
++	eval "LIB_openpty="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_openpty=no"
++	eval "LIB_openpty="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_openpty=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for tgetent" >&5
++$as_echo_n "checking for tgetent... " >&6; }
++if test "${ac_cv_funclib_tgetent+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_tgetent\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" termcap ncurses curses; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#ifdef HAVE_TERMCAP_H
++#include <termcap.h>
++#endif
++#ifdef HAVE_CURSES_H
++#include <curses.h>
++#endif
++
++int
++main ()
++{
++tgetent(0,0)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_tgetent=$ac_lib; else ac_cv_funclib_tgetent=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_tgetent=\${ac_cv_funclib_tgetent-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_tgetent"
++
++if false; then
++	for ac_func in tgetent
++do :
++  ac_fn_c_check_func "$LINENO" "tgetent" "ac_cv_func_tgetent"
++if test "x$ac_cv_func_tgetent" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_TGETENT 1
++_ACEOF
++
++fi
++done
++
++fi
++# tgetent
++eval "ac_tr_func=HAVE_`echo tgetent | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_tgetent=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_tgetent=yes"
++	eval "LIB_tgetent="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_tgetent=no"
++	eval "LIB_tgetent="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_tgetent=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++
++
++for ac_func in 				\
++	_getpty					\
++	_scrsize				\
++	arc4random				\
++	fcntl					\
++	getpeereid				\
++	getpeerucred				\
++	grantpt					\
++	mktime					\
++	ptsname					\
++	rand					\
++	revoke					\
++	select					\
++	setitimer				\
++	setpcred				\
++	setpgid					\
++	setproctitle				\
++	setregid				\
++	setresgid				\
++	setresuid				\
++	setreuid				\
++	setsid					\
++	setutent				\
++	sigaction				\
++	strstr					\
++	ttyname					\
++	ttyslot					\
++	umask					\
++	unlockpt				\
++	vhangup					\
++	yp_get_default_domain			\
++
++do :
++  as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
++ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var"
++if eval test \"x\$"$as_ac_var"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++done
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking checking for __sync_add_and_fetch" >&5
++$as_echo_n "checking checking for __sync_add_and_fetch... " >&6; }
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <sys/types.h>
++int
++main ()
++{
++unsigned int foo; __sync_add_and_fetch(&foo, 1);
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  ac_rk_have___sync_add_and_fetch=yes
++else
++  ac_rk_have___sync_add_and_fetch=no
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++if test "$ac_rk_have___sync_add_and_fetch" = "yes" ; then
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE___SYNC_ADD_AND_FETCH 1
++_ACEOF
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_rk_have___sync_add_and_fetch" >&5
++$as_echo "$ac_rk_have___sync_add_and_fetch" >&6; }
++
++
++for ac_func in getpagesize
++do :
++  ac_fn_c_check_func "$LINENO" "getpagesize" "ac_cv_func_getpagesize"
++if test "x$ac_cv_func_getpagesize" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_GETPAGESIZE 1
++_ACEOF
++
++fi
++done
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for working mmap" >&5
++$as_echo_n "checking for working mmap... " >&6; }
++if test "${ac_cv_func_mmap_fixed_mapped+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test "$cross_compiling" = yes; then :
++  ac_cv_func_mmap_fixed_mapped=no
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++$ac_includes_default
++/* malloc might have been renamed as rpl_malloc. */
++#undef malloc
++
++/* Thanks to Mike Haertel and Jim Avera for this test.
++   Here is a matrix of mmap possibilities:
++	mmap private not fixed
++	mmap private fixed at somewhere currently unmapped
++	mmap private fixed at somewhere already mapped
++	mmap shared not fixed
++	mmap shared fixed at somewhere currently unmapped
++	mmap shared fixed at somewhere already mapped
++   For private mappings, we should verify that changes cannot be read()
++   back from the file, nor mmap's back from the file at a different
++   address.  (There have been systems where private was not correctly
++   implemented like the infamous i386 svr4.0, and systems where the
++   VM page cache was not coherent with the file system buffer cache
++   like early versions of FreeBSD and possibly contemporary NetBSD.)
++   For shared mappings, we should conversely verify that changes get
++   propagated back to all the places they're supposed to be.
++
++   Grep wants private fixed already mapped.
++   The main things grep needs to know about mmap are:
++   * does it exist and is it safe to write into the mmap'd area
++   * how to use it (BSD variants)  */
++
++#include <fcntl.h>
++#include <sys/mman.h>
++
++#if !defined STDC_HEADERS && !defined HAVE_STDLIB_H
++char *malloc ();
++#endif
++
++/* This mess was copied from the GNU getpagesize.h.  */
++#ifndef HAVE_GETPAGESIZE
++# ifdef _SC_PAGESIZE
++#  define getpagesize() sysconf(_SC_PAGESIZE)
++# else /* no _SC_PAGESIZE */
++#  ifdef HAVE_SYS_PARAM_H
++#   include <sys/param.h>
++#   ifdef EXEC_PAGESIZE
++#    define getpagesize() EXEC_PAGESIZE
++#   else /* no EXEC_PAGESIZE */
++#    ifdef NBPG
++#     define getpagesize() NBPG * CLSIZE
++#     ifndef CLSIZE
++#      define CLSIZE 1
++#     endif /* no CLSIZE */
++#    else /* no NBPG */
++#     ifdef NBPC
++#      define getpagesize() NBPC
++#     else /* no NBPC */
++#      ifdef PAGESIZE
++#       define getpagesize() PAGESIZE
++#      endif /* PAGESIZE */
++#     endif /* no NBPC */
++#    endif /* no NBPG */
++#   endif /* no EXEC_PAGESIZE */
++#  else /* no HAVE_SYS_PARAM_H */
++#   define getpagesize() 8192	/* punt totally */
++#  endif /* no HAVE_SYS_PARAM_H */
++# endif /* no _SC_PAGESIZE */
++
++#endif /* no HAVE_GETPAGESIZE */
++
++int
++main ()
++{
++  char *data, *data2, *data3;
++  const char *cdata2;
++  int i, pagesize;
++  int fd, fd2;
++
++  pagesize = getpagesize ();
++
++  /* First, make a file with some known garbage in it. */
++  data = (char *) malloc (pagesize);
++  if (!data)
++    return 1;
++  for (i = 0; i < pagesize; ++i)
++    *(data + i) = rand ();
++  umask (0);
++  fd = creat ("conftest.mmap", 0600);
++  if (fd < 0)
++    return 2;
++  if (write (fd, data, pagesize) != pagesize)
++    return 3;
++  close (fd);
++
++  /* Next, check that the tail of a page is zero-filled.  File must have
++     non-zero length, otherwise we risk SIGBUS for entire page.  */
++  fd2 = open ("conftest.txt", O_RDWR | O_CREAT | O_TRUNC, 0600);
++  if (fd2 < 0)
++    return 4;
++  cdata2 = "";
++  if (write (fd2, cdata2, 1) != 1)
++    return 5;
++  data2 = (char *) mmap (0, pagesize, PROT_READ | PROT_WRITE, MAP_SHARED, fd2, 0L);
++  if (data2 == MAP_FAILED)
++    return 6;
++  for (i = 0; i < pagesize; ++i)
++    if (*(data2 + i))
++      return 7;
++  close (fd2);
++  if (munmap (data2, pagesize))
++    return 8;
++
++  /* Next, try to mmap the file at a fixed address which already has
++     something else allocated at it.  If we can, also make sure that
++     we see the same garbage.  */
++  fd = open ("conftest.mmap", O_RDWR);
++  if (fd < 0)
++    return 9;
++  if (data2 != mmap (data2, pagesize, PROT_READ | PROT_WRITE,
++		     MAP_PRIVATE | MAP_FIXED, fd, 0L))
++    return 10;
++  for (i = 0; i < pagesize; ++i)
++    if (*(data + i) != *(data2 + i))
++      return 11;
++
++  /* Finally, make sure that changes to the mapped area do not
++     percolate back to the file as seen by read().  (This is a bug on
++     some variants of i386 svr4.0.)  */
++  for (i = 0; i < pagesize; ++i)
++    *(data2 + i) = *(data2 + i) + 1;
++  data3 = (char *) malloc (pagesize);
++  if (!data3)
++    return 12;
++  if (read (fd, data3, pagesize) != pagesize)
++    return 13;
++  for (i = 0; i < pagesize; ++i)
++    if (*(data + i) != *(data3 + i))
++      return 14;
++  close (fd);
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_run "$LINENO"; then :
++  ac_cv_func_mmap_fixed_mapped=yes
++else
++  ac_cv_func_mmap_fixed_mapped=no
++fi
++rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
++  conftest.$ac_objext conftest.beam conftest.$ac_ext
++fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_mmap_fixed_mapped" >&5
++$as_echo "$ac_cv_func_mmap_fixed_mapped" >&6; }
++if test $ac_cv_func_mmap_fixed_mapped = yes; then
++
++$as_echo "#define HAVE_MMAP 1" >>confdefs.h
++
++fi
++rm -f conftest.mmap conftest.txt
++
++
++
++
++for ac_header in capability.h sys/capability.h
++do :
++  as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
++ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" "$ac_includes_default"
++if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++
++done
++
++
++for ac_func in sgi_getcapabilitybyname cap_set_proc
++do :
++  as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
++ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var"
++if eval test \"x\$"$as_ac_var"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++done
++
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for getpwnam_r" >&5
++$as_echo_n "checking for getpwnam_r... " >&6; }
++if test "${ac_cv_funclib_getpwnam_r+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_getpwnam_r\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" c_r; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++getpwnam_r()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_getpwnam_r=$ac_lib; else ac_cv_funclib_getpwnam_r=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_getpwnam_r=\${ac_cv_funclib_getpwnam_r-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_getpwnam_r"
++
++if false; then
++	for ac_func in getpwnam_r
++do :
++  ac_fn_c_check_func "$LINENO" "getpwnam_r" "ac_cv_func_getpwnam_r"
++if test "x$ac_cv_func_getpwnam_r" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_GETPWNAM_R 1
++_ACEOF
++
++fi
++done
++
++fi
++# getpwnam_r
++eval "ac_tr_func=HAVE_`echo getpwnam_r | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_getpwnam_r=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_getpwnam_r=yes"
++	eval "LIB_getpwnam_r="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_getpwnam_r=no"
++	eval "LIB_getpwnam_r="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_getpwnam_r=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test "$ac_cv_func_getpwnam_r" = yes; then
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if getpwnam_r is posix" >&5
++$as_echo_n "checking if getpwnam_r is posix... " >&6; }
++if test "${ac_cv_func_getpwnam_r_posix+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  ac_libs="$LIBS"
++	LIBS="$LIBS $LIB_getpwnam_r"
++	if test "$cross_compiling" = yes; then :
++  :
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#define _POSIX_PTHREAD_SEMANTICS
++#include <pwd.h>
++int main(int argc, char **argv)
++{
++	struct passwd pw, *pwd;
++	return getpwnam_r("", &pw, NULL, 0, &pwd) < 0;
++}
++
++_ACEOF
++if ac_fn_c_try_run "$LINENO"; then :
++  ac_cv_func_getpwnam_r_posix=yes
++else
++  ac_cv_func_getpwnam_r_posix=no
++fi
++rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
++  conftest.$ac_objext conftest.beam conftest.$ac_ext
++fi
++
++LIBS="$ac_libs"
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_getpwnam_r_posix" >&5
++$as_echo "$ac_cv_func_getpwnam_r_posix" >&6; }
++if test "$ac_cv_func_getpwnam_r_posix" = yes; then
++
++$as_echo "#define POSIX_GETPWNAM_R 1" >>confdefs.h
++
++fi
++fi
++
++
++if test "$enable_pthread_support" != no; then
++   saved_LIBS="$LIBS"
++   LIBS="$LIBS $PTHREADS_LIBS"
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for door_create" >&5
++$as_echo_n "checking for door_create... " >&6; }
++if test "${ac_cv_funclib_door_create+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_door_create\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" door; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib  $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++door_create()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_door_create=$ac_lib; else ac_cv_funclib_door_create=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_door_create=\${ac_cv_funclib_door_create-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_door_create"
++
++if false; then
++	for ac_func in door_create
++do :
++  ac_fn_c_check_func "$LINENO" "door_create" "ac_cv_func_door_create"
++if test "x$ac_cv_func_door_create" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_DOOR_CREATE 1
++_ACEOF
++
++fi
++done
++
++fi
++# door_create
++eval "ac_tr_func=HAVE_`echo door_create | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_door_create=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_door_create=yes"
++	eval "LIB_door_create="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_door_create=no"
++	eval "LIB_door_create="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_door_create=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++   LIBS="$saved_LIBS"
++fi
++
++# Check whether --enable-kcm was given.
++if test "${enable_kcm+set}" = set; then :
++  enableval=$enable_kcm;
++else
++  enable_kcm=yes
++fi
++
++
++if test "$enable_kcm" = yes ; then
++   if test  "$ac_cv_header_sys_un_h" != yes -a "$ac_cv_funclib_door_create" != yes ; then
++  	enable_kcm=no
++   fi
++fi
++if test "$enable_kcm" = yes; then
++
++$as_echo "#define HAVE_KCM 1" >>confdefs.h
++
++fi
++ if test "$enable_kcm" = yes; then
++  KCM_TRUE=
++  KCM_FALSE='#'
++else
++  KCM_TRUE='#'
++  KCM_FALSE=
++fi
++
++
++
++
++for ac_func in getudbnam setlim
++do :
++  as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
++ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var"
++if eval test \"x\$"$as_ac_var"\" = x"yes"; then :
++  cat >>confdefs.h <<_ACEOF
++#define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1
++_ACEOF
++
++fi
++done
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_addr in struct utmp" >&5
++$as_echo_n "checking for ut_addr in struct utmp... " >&6; }
++if test "${ac_cv_type_struct_utmp_ut_addr+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmp.h>
++int
++main ()
++{
++struct utmp x; memset(&x, 0, sizeof(x)); x.ut_addr
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmp_ut_addr=yes
++else
++  ac_cv_type_struct_utmp_ut_addr=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmp_ut_addr" >&5
++$as_echo "$ac_cv_type_struct_utmp_ut_addr" >&6; }
++if test "$ac_cv_type_struct_utmp_ut_addr" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMP_UT_ADDR 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_host in struct utmp" >&5
++$as_echo_n "checking for ut_host in struct utmp... " >&6; }
++if test "${ac_cv_type_struct_utmp_ut_host+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmp.h>
++int
++main ()
++{
++struct utmp x; memset(&x, 0, sizeof(x)); x.ut_host
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmp_ut_host=yes
++else
++  ac_cv_type_struct_utmp_ut_host=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmp_ut_host" >&5
++$as_echo "$ac_cv_type_struct_utmp_ut_host" >&6; }
++if test "$ac_cv_type_struct_utmp_ut_host" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMP_UT_HOST 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_id in struct utmp" >&5
++$as_echo_n "checking for ut_id in struct utmp... " >&6; }
++if test "${ac_cv_type_struct_utmp_ut_id+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmp.h>
++int
++main ()
++{
++struct utmp x; memset(&x, 0, sizeof(x)); x.ut_id
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmp_ut_id=yes
++else
++  ac_cv_type_struct_utmp_ut_id=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmp_ut_id" >&5
++$as_echo "$ac_cv_type_struct_utmp_ut_id" >&6; }
++if test "$ac_cv_type_struct_utmp_ut_id" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMP_UT_ID 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_pid in struct utmp" >&5
++$as_echo_n "checking for ut_pid in struct utmp... " >&6; }
++if test "${ac_cv_type_struct_utmp_ut_pid+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmp.h>
++int
++main ()
++{
++struct utmp x; memset(&x, 0, sizeof(x)); x.ut_pid
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmp_ut_pid=yes
++else
++  ac_cv_type_struct_utmp_ut_pid=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmp_ut_pid" >&5
++$as_echo "$ac_cv_type_struct_utmp_ut_pid" >&6; }
++if test "$ac_cv_type_struct_utmp_ut_pid" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMP_UT_PID 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_type in struct utmp" >&5
++$as_echo_n "checking for ut_type in struct utmp... " >&6; }
++if test "${ac_cv_type_struct_utmp_ut_type+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmp.h>
++int
++main ()
++{
++struct utmp x; memset(&x, 0, sizeof(x)); x.ut_type
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmp_ut_type=yes
++else
++  ac_cv_type_struct_utmp_ut_type=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmp_ut_type" >&5
++$as_echo "$ac_cv_type_struct_utmp_ut_type" >&6; }
++if test "$ac_cv_type_struct_utmp_ut_type" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMP_UT_TYPE 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_user in struct utmp" >&5
++$as_echo_n "checking for ut_user in struct utmp... " >&6; }
++if test "${ac_cv_type_struct_utmp_ut_user+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmp.h>
++int
++main ()
++{
++struct utmp x; memset(&x, 0, sizeof(x)); x.ut_user
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmp_ut_user=yes
++else
++  ac_cv_type_struct_utmp_ut_user=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmp_ut_user" >&5
++$as_echo "$ac_cv_type_struct_utmp_ut_user" >&6; }
++if test "$ac_cv_type_struct_utmp_ut_user" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMP_UT_USER 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_host in struct utmpx" >&5
++$as_echo_n "checking for ut_host in struct utmpx... " >&6; }
++if test "${ac_cv_type_struct_utmpx_ut_host+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmpx.h>
++int
++main ()
++{
++struct utmpx x; memset(&x, 0, sizeof(x)); x.ut_host
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmpx_ut_host=yes
++else
++  ac_cv_type_struct_utmpx_ut_host=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmpx_ut_host" >&5
++$as_echo "$ac_cv_type_struct_utmpx_ut_host" >&6; }
++if test "$ac_cv_type_struct_utmpx_ut_host" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMPX_UT_HOST 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_id in struct utmpx" >&5
++$as_echo_n "checking for ut_id in struct utmpx... " >&6; }
++if test "${ac_cv_type_struct_utmpx_ut_id+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmpx.h>
++int
++main ()
++{
++struct utmpx x; memset(&x, 0, sizeof(x)); x.ut_id
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmpx_ut_id=yes
++else
++  ac_cv_type_struct_utmpx_ut_id=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmpx_ut_id" >&5
++$as_echo "$ac_cv_type_struct_utmpx_ut_id" >&6; }
++if test "$ac_cv_type_struct_utmpx_ut_id" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMPX_UT_ID 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_line in struct utmpx" >&5
++$as_echo_n "checking for ut_line in struct utmpx... " >&6; }
++if test "${ac_cv_type_struct_utmpx_ut_line+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmpx.h>
++int
++main ()
++{
++struct utmpx x; memset(&x, 0, sizeof(x)); x.ut_line
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmpx_ut_line=yes
++else
++  ac_cv_type_struct_utmpx_ut_line=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmpx_ut_line" >&5
++$as_echo "$ac_cv_type_struct_utmpx_ut_line" >&6; }
++if test "$ac_cv_type_struct_utmpx_ut_line" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMPX_UT_LINE 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_pid in struct utmpx" >&5
++$as_echo_n "checking for ut_pid in struct utmpx... " >&6; }
++if test "${ac_cv_type_struct_utmpx_ut_pid+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmpx.h>
++int
++main ()
++{
++struct utmpx x; memset(&x, 0, sizeof(x)); x.ut_pid
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmpx_ut_pid=yes
++else
++  ac_cv_type_struct_utmpx_ut_pid=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmpx_ut_pid" >&5
++$as_echo "$ac_cv_type_struct_utmpx_ut_pid" >&6; }
++if test "$ac_cv_type_struct_utmpx_ut_pid" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMPX_UT_PID 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_tv in struct utmpx" >&5
++$as_echo_n "checking for ut_tv in struct utmpx... " >&6; }
++if test "${ac_cv_type_struct_utmpx_ut_tv+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmpx.h>
++int
++main ()
++{
++struct utmpx x; memset(&x, 0, sizeof(x)); x.ut_tv
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmpx_ut_tv=yes
++else
++  ac_cv_type_struct_utmpx_ut_tv=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmpx_ut_tv" >&5
++$as_echo "$ac_cv_type_struct_utmpx_ut_tv" >&6; }
++if test "$ac_cv_type_struct_utmpx_ut_tv" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMPX_UT_TV 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_type in struct utmpx" >&5
++$as_echo_n "checking for ut_type in struct utmpx... " >&6; }
++if test "${ac_cv_type_struct_utmpx_ut_type+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmpx.h>
++int
++main ()
++{
++struct utmpx x; memset(&x, 0, sizeof(x)); x.ut_type
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmpx_ut_type=yes
++else
++  ac_cv_type_struct_utmpx_ut_type=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmpx_ut_type" >&5
++$as_echo "$ac_cv_type_struct_utmpx_ut_type" >&6; }
++if test "$ac_cv_type_struct_utmpx_ut_type" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMPX_UT_TYPE 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_user in struct utmpx" >&5
++$as_echo_n "checking for ut_user in struct utmpx... " >&6; }
++if test "${ac_cv_type_struct_utmpx_ut_user+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmpx.h>
++int
++main ()
++{
++struct utmpx x; memset(&x, 0, sizeof(x)); x.ut_user
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmpx_ut_user=yes
++else
++  ac_cv_type_struct_utmpx_ut_user=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmpx_ut_user" >&5
++$as_echo "$ac_cv_type_struct_utmpx_ut_user" >&6; }
++if test "$ac_cv_type_struct_utmpx_ut_user" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMPX_UT_USER 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_exit in struct utmpx" >&5
++$as_echo_n "checking for ut_exit in struct utmpx... " >&6; }
++if test "${ac_cv_type_struct_utmpx_ut_exit+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmpx.h>
++int
++main ()
++{
++struct utmpx x; memset(&x, 0, sizeof(x)); x.ut_exit
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmpx_ut_exit=yes
++else
++  ac_cv_type_struct_utmpx_ut_exit=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmpx_ut_exit" >&5
++$as_echo "$ac_cv_type_struct_utmpx_ut_exit" >&6; }
++if test "$ac_cv_type_struct_utmpx_ut_exit" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMPX_UT_EXIT 1" >>confdefs.h
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for ut_syslen in struct utmpx" >&5
++$as_echo_n "checking for ut_syslen in struct utmpx... " >&6; }
++if test "${ac_cv_type_struct_utmpx_ut_syslen+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <utmpx.h>
++int
++main ()
++{
++struct utmpx x; memset(&x, 0, sizeof(x)); x.ut_syslen
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_type_struct_utmpx_ut_syslen=yes
++else
++  ac_cv_type_struct_utmpx_ut_syslen=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_type_struct_utmpx_ut_syslen" >&5
++$as_echo "$ac_cv_type_struct_utmpx_ut_syslen" >&6; }
++if test "$ac_cv_type_struct_utmpx_ut_syslen" = yes; then
++
++
++$as_echo "#define HAVE_STRUCT_UTMPX_UT_SYSLEN 1" >>confdefs.h
++
++
++fi
++
++
++
++ac_fn_c_check_type "$LINENO" "int8_t" "ac_cv_type_int8_t" "
++#ifdef HAVE_INTTYPES_H
++#include <inttypes.h>
++#endif
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_BITYPES_H
++#include <sys/bitypes.h>
++#endif
++#ifdef HAVE_BIND_BITYPES_H
++#include <bind/bitypes.h>
++#endif
++#ifdef HAVE_NETINET_IN6_MACHTYPES_H
++#include <netinet/in6_machtypes.h>
++#endif
++
++"
++if test "x$ac_cv_type_int8_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_INT8_T 1
++_ACEOF
++
++
++fi
++ac_fn_c_check_type "$LINENO" "int16_t" "ac_cv_type_int16_t" "
++#ifdef HAVE_INTTYPES_H
++#include <inttypes.h>
++#endif
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_BITYPES_H
++#include <sys/bitypes.h>
++#endif
++#ifdef HAVE_BIND_BITYPES_H
++#include <bind/bitypes.h>
++#endif
++#ifdef HAVE_NETINET_IN6_MACHTYPES_H
++#include <netinet/in6_machtypes.h>
++#endif
++
++"
++if test "x$ac_cv_type_int16_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_INT16_T 1
++_ACEOF
++
++
++fi
++ac_fn_c_check_type "$LINENO" "int32_t" "ac_cv_type_int32_t" "
++#ifdef HAVE_INTTYPES_H
++#include <inttypes.h>
++#endif
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_BITYPES_H
++#include <sys/bitypes.h>
++#endif
++#ifdef HAVE_BIND_BITYPES_H
++#include <bind/bitypes.h>
++#endif
++#ifdef HAVE_NETINET_IN6_MACHTYPES_H
++#include <netinet/in6_machtypes.h>
++#endif
++
++"
++if test "x$ac_cv_type_int32_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_INT32_T 1
++_ACEOF
++
++
++fi
++ac_fn_c_check_type "$LINENO" "int64_t" "ac_cv_type_int64_t" "
++#ifdef HAVE_INTTYPES_H
++#include <inttypes.h>
++#endif
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_BITYPES_H
++#include <sys/bitypes.h>
++#endif
++#ifdef HAVE_BIND_BITYPES_H
++#include <bind/bitypes.h>
++#endif
++#ifdef HAVE_NETINET_IN6_MACHTYPES_H
++#include <netinet/in6_machtypes.h>
++#endif
++
++"
++if test "x$ac_cv_type_int64_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_INT64_T 1
++_ACEOF
++
++
++fi
++ac_fn_c_check_type "$LINENO" "u_int8_t" "ac_cv_type_u_int8_t" "
++#ifdef HAVE_INTTYPES_H
++#include <inttypes.h>
++#endif
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_BITYPES_H
++#include <sys/bitypes.h>
++#endif
++#ifdef HAVE_BIND_BITYPES_H
++#include <bind/bitypes.h>
++#endif
++#ifdef HAVE_NETINET_IN6_MACHTYPES_H
++#include <netinet/in6_machtypes.h>
++#endif
++
++"
++if test "x$ac_cv_type_u_int8_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_U_INT8_T 1
++_ACEOF
++
++
++fi
++ac_fn_c_check_type "$LINENO" "u_int16_t" "ac_cv_type_u_int16_t" "
++#ifdef HAVE_INTTYPES_H
++#include <inttypes.h>
++#endif
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_BITYPES_H
++#include <sys/bitypes.h>
++#endif
++#ifdef HAVE_BIND_BITYPES_H
++#include <bind/bitypes.h>
++#endif
++#ifdef HAVE_NETINET_IN6_MACHTYPES_H
++#include <netinet/in6_machtypes.h>
++#endif
++
++"
++if test "x$ac_cv_type_u_int16_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_U_INT16_T 1
++_ACEOF
++
++
++fi
++ac_fn_c_check_type "$LINENO" "u_int32_t" "ac_cv_type_u_int32_t" "
++#ifdef HAVE_INTTYPES_H
++#include <inttypes.h>
++#endif
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_BITYPES_H
++#include <sys/bitypes.h>
++#endif
++#ifdef HAVE_BIND_BITYPES_H
++#include <bind/bitypes.h>
++#endif
++#ifdef HAVE_NETINET_IN6_MACHTYPES_H
++#include <netinet/in6_machtypes.h>
++#endif
++
++"
++if test "x$ac_cv_type_u_int32_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_U_INT32_T 1
++_ACEOF
++
++
++fi
++ac_fn_c_check_type "$LINENO" "u_int64_t" "ac_cv_type_u_int64_t" "
++#ifdef HAVE_INTTYPES_H
++#include <inttypes.h>
++#endif
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_BITYPES_H
++#include <sys/bitypes.h>
++#endif
++#ifdef HAVE_BIND_BITYPES_H
++#include <bind/bitypes.h>
++#endif
++#ifdef HAVE_NETINET_IN6_MACHTYPES_H
++#include <netinet/in6_machtypes.h>
++#endif
++
++"
++if test "x$ac_cv_type_u_int64_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_U_INT64_T 1
++_ACEOF
++
++
++fi
++ac_fn_c_check_type "$LINENO" "uint8_t" "ac_cv_type_uint8_t" "
++#ifdef HAVE_INTTYPES_H
++#include <inttypes.h>
++#endif
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_BITYPES_H
++#include <sys/bitypes.h>
++#endif
++#ifdef HAVE_BIND_BITYPES_H
++#include <bind/bitypes.h>
++#endif
++#ifdef HAVE_NETINET_IN6_MACHTYPES_H
++#include <netinet/in6_machtypes.h>
++#endif
++
++"
++if test "x$ac_cv_type_uint8_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_UINT8_T 1
++_ACEOF
++
++
++fi
++ac_fn_c_check_type "$LINENO" "uint16_t" "ac_cv_type_uint16_t" "
++#ifdef HAVE_INTTYPES_H
++#include <inttypes.h>
++#endif
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_BITYPES_H
++#include <sys/bitypes.h>
++#endif
++#ifdef HAVE_BIND_BITYPES_H
++#include <bind/bitypes.h>
++#endif
++#ifdef HAVE_NETINET_IN6_MACHTYPES_H
++#include <netinet/in6_machtypes.h>
++#endif
++
++"
++if test "x$ac_cv_type_uint16_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_UINT16_T 1
++_ACEOF
++
++
++fi
++ac_fn_c_check_type "$LINENO" "uint32_t" "ac_cv_type_uint32_t" "
++#ifdef HAVE_INTTYPES_H
++#include <inttypes.h>
++#endif
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_BITYPES_H
++#include <sys/bitypes.h>
++#endif
++#ifdef HAVE_BIND_BITYPES_H
++#include <bind/bitypes.h>
++#endif
++#ifdef HAVE_NETINET_IN6_MACHTYPES_H
++#include <netinet/in6_machtypes.h>
++#endif
++
++"
++if test "x$ac_cv_type_uint32_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_UINT32_T 1
++_ACEOF
++
++
++fi
++ac_fn_c_check_type "$LINENO" "uint64_t" "ac_cv_type_uint64_t" "
++#ifdef HAVE_INTTYPES_H
++#include <inttypes.h>
++#endif
++#ifdef HAVE_SYS_TYPES_H
++#include <sys/types.h>
++#endif
++#ifdef HAVE_SYS_BITYPES_H
++#include <sys/bitypes.h>
++#endif
++#ifdef HAVE_BIND_BITYPES_H
++#include <bind/bitypes.h>
++#endif
++#ifdef HAVE_NETINET_IN6_MACHTYPES_H
++#include <netinet/in6_machtypes.h>
++#endif
++
++"
++if test "x$ac_cv_type_uint64_t" = x""yes; then :
++
++cat >>confdefs.h <<_ACEOF
++#define HAVE_UINT64_T 1
++_ACEOF
++
++
++fi
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for framework security" >&5
++$as_echo_n "checking for framework security... " >&6; }
++if test "${rk_cv_framework_security+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if test "$rk_cv_framework_security" != yes; then
++	ac_save_LIBS="$LIBS"
++	LIBS="$ac_save_LIBS -framework Security -framework CoreFoundation"
++	cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <Security/Security.h>
++
++int
++main ()
++{
++SecKeychainSearchRef searchRef;
++SecKeychainSearchCreateFromAttributes(NULL,kSecCertificateItemClass,NULL, &searchRef);
++CFRelease(&searchRef);
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  rk_cv_framework_security=yes
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++if test "$rk_cv_framework_security" = yes; then
++
++$as_echo "#define HAVE_FRAMEWORK_SECURITY 1" >>confdefs.h
++
++   { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++else
++   { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++ if test "$rk_cv_framework_security" = yes; then
++  FRAMEWORK_SECURITY_TRUE=
++  FRAMEWORK_SECURITY_FALSE='#'
++else
++  FRAMEWORK_SECURITY_TRUE='#'
++  FRAMEWORK_SECURITY_FALSE=
++fi
++
++
++if test "$rk_cv_framework_security" = yes; then
++
++if test "$ac_cv_func_SecKeyGetCSPHandle+set" != set -o "$ac_cv_func_SecKeyGetCSPHandle" = yes; then
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if SecKeyGetCSPHandle needs a prototype" >&5
++$as_echo_n "checking if SecKeyGetCSPHandle needs a prototype... " >&6; }
++if test "${ac_cv_func_SecKeyGetCSPHandle_noproto+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <Security/Security.h>
++struct foo { int foo; } xx;
++extern int SecKeyGetCSPHandle (struct foo*);
++int
++main ()
++{
++SecKeyGetCSPHandle(&xx)
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  eval "ac_cv_func_SecKeyGetCSPHandle_noproto=yes"
++else
++  eval "ac_cv_func_SecKeyGetCSPHandle_noproto=no"
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_SecKeyGetCSPHandle_noproto" >&5
++$as_echo "$ac_cv_func_SecKeyGetCSPHandle_noproto" >&6; }
++if test "$ac_cv_func_SecKeyGetCSPHandle_noproto" = yes; then
++
++$as_echo "#define NEED_SECKEYGETCSPHANDLE_PROTO 1" >>confdefs.h
++
++fi
++fi
++
++fi
++
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for el_init" >&5
++$as_echo_n "checking for el_init... " >&6; }
++if test "${ac_cv_funclib_el_init+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++if eval "test \"\$ac_cv_func_el_init\" != yes" ; then
++	ac_save_LIBS="$LIBS"
++	for ac_lib in "" edit; do
++		case "$ac_lib" in
++		"") ;;
++		yes) ac_lib="" ;;
++		no) continue ;;
++		-l*) ;;
++		*) ac_lib="-l$ac_lib" ;;
++		esac
++		LIBS=" $ac_lib $LIB_tgetent $ac_save_LIBS"
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++int
++main ()
++{
++el_init()
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  eval "if test -n \"$ac_lib\";then ac_cv_funclib_el_init=$ac_lib; else ac_cv_funclib_el_init=yes; fi";break
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++	done
++	eval "ac_cv_funclib_el_init=\${ac_cv_funclib_el_init-no}"
++	LIBS="$ac_save_LIBS"
++fi
++
++fi
++
++
++eval "ac_res=\$ac_cv_funclib_el_init"
++
++if false; then
++	for ac_func in el_init
++do :
++  ac_fn_c_check_func "$LINENO" "el_init" "ac_cv_func_el_init"
++if test "x$ac_cv_func_el_init" = x""yes; then :
++  cat >>confdefs.h <<_ACEOF
++#define HAVE_EL_INIT 1
++_ACEOF
++
++fi
++done
++
++fi
++# el_init
++eval "ac_tr_func=HAVE_`echo el_init | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "ac_tr_lib=HAVE_LIB`echo $ac_res | sed -e 's/-l//' | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
++eval "LIB_el_init=$ac_res"
++
++case "$ac_res" in
++	yes)
++	eval "ac_cv_func_el_init=yes"
++	eval "LIB_el_init="
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++	;;
++	no)
++	eval "ac_cv_func_el_init=no"
++	eval "LIB_el_init="
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++	;;
++	*)
++	eval "ac_cv_func_el_init=yes"
++	eval "ac_cv_lib_`echo "$ac_res" | sed 's/-l//'`=yes"
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_func 1
++_ACEOF
++
++	cat >>confdefs.h <<_ACEOF
++#define $ac_tr_lib 1
++_ACEOF
++
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: yes, in $ac_res" >&5
++$as_echo "yes, in $ac_res" >&6; }
++	;;
++esac
++
++
++if test "$ac_cv_func_el_init" = yes ; then
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for four argument el_init" >&5
++$as_echo_n "checking for four argument el_init... " >&6; }
++if test "${ac_cv_func_el_init_four+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++
++		cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <stdio.h>
++			#include <histedit.h>
++int
++main ()
++{
++el_init("", NULL, NULL, NULL);
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_compile "$LINENO"; then :
++  ac_cv_func_el_init_four=yes
++else
++  ac_cv_func_el_init_four=no
++fi
++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_el_init_four" >&5
++$as_echo "$ac_cv_func_el_init_four" >&6; }
++	if test "$ac_cv_func_el_init_four" = yes; then
++
++$as_echo "#define HAVE_FOUR_VALUED_EL_INIT 1" >>confdefs.h
++
++	fi
++fi
++
++
++ac_foo=no
++build_editline=no
++if test "$with_readline" = yes; then
++	:
++elif test "$ac_cv_func_readline" = yes; then
++	:
++elif test "$ac_cv_func_el_init" = yes; then
++	ac_foo=yes
++	build_editline=yes
++	LIB_readline="\$(top_builddir)/lib/editline/libel_compat.la \$(LIB_el_init) \$(LIB_tgetent)"
++else
++	build_editline=yes
++	LIB_readline="\$(top_builddir)/lib/editline/libeditline.la \$(LIB_tgetent)"
++fi
++ if test "$build_editline" = yes; then
++  EDITLINE_TRUE=
++  EDITLINE_FALSE='#'
++else
++  EDITLINE_TRUE='#'
++  EDITLINE_FALSE=
++fi
++
++ if test "$ac_foo" = yes; then
++  el_compat_TRUE=
++  el_compat_FALSE='#'
++else
++  el_compat_TRUE='#'
++  el_compat_FALSE=
++fi
++
++
++$as_echo "#define HAVE_READLINE 1" >>confdefs.h
++
++
++
++
++
++$as_echo "#define AUTHENTICATION 1" >>confdefs.h
++
++$as_echo "#define ENCRYPTION 1" >>confdefs.h
++
++$as_echo "#define DES_ENCRYPTION 1" >>confdefs.h
++
++$as_echo "#define DIAGNOSTICS 1" >>confdefs.h
++
++$as_echo "#define OLD_ENVIRON 1" >>confdefs.h
++if false; then
++
++$as_echo "#define ENV_HACK 1" >>confdefs.h
++
++fi
++
++# Simple test for streamspty, based on the existance of getmsg(), alas
++# this breaks on SunOS4 which have streams but BSD-like ptys
++#
++# And also something wierd has happend with dec-osf1, fallback to bsd-ptys
++
++case "$host" in
++*-*-aix3*|*-*-sunos4*|*-*-osf*|*-*-hpux1[01]*)
++	;;
++*)
++	ac_fn_c_check_func "$LINENO" "getmsg" "ac_cv_func_getmsg"
++if test "x$ac_cv_func_getmsg" = x""yes; then :
++
++fi
++
++	if test "$ac_cv_func_getmsg" = "yes"; then
++		{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if getmsg works" >&5
++$as_echo_n "checking if getmsg works... " >&6; }
++if test "${ac_cv_func_getmsg_works+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test "$cross_compiling" = yes; then :
++  ac_cv_func_getmsg_works=no
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++			#include <stdio.h>
++			#include <errno.h>
++
++			int main(int argc, char **argv)
++			{
++			  int ret;
++			  ret = getmsg(open("/dev/null", 0), NULL, NULL, NULL);
++			  if(ret < 0 && errno == ENOSYS)
++			    return 1;
++			  return 0;
++			}
++
++_ACEOF
++if ac_fn_c_try_run "$LINENO"; then :
++  ac_cv_func_getmsg_works=yes
++else
++  ac_cv_func_getmsg_works=no
++fi
++rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
++  conftest.$ac_objext conftest.beam conftest.$ac_ext
++fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_func_getmsg_works" >&5
++$as_echo "$ac_cv_func_getmsg_works" >&6; }
++		if test "$ac_cv_func_getmsg_works" = "yes"; then
++
++$as_echo "#define HAVE_GETMSG 1" >>confdefs.h
++
++
++$as_echo "#define STREAMSPTY 1" >>confdefs.h
++
++		fi
++	fi
++	;;
++esac
++
++
++
++
++
++
++# Extract the first word of "compile_et", so it can be a program name with args.
++set dummy compile_et; ac_word=$2
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
++$as_echo_n "checking for $ac_word... " >&6; }
++if test "${ac_cv_prog_COMPILE_ET+set}" = set; then :
++  $as_echo_n "(cached) " >&6
++else
++  if test -n "$COMPILE_ET"; then
++  ac_cv_prog_COMPILE_ET="$COMPILE_ET" # Let the user override the test.
++else
++as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    for ac_exec_ext in '' $ac_executable_extensions; do
++  if { test -f "$as_dir/$ac_word$ac_exec_ext" && $as_test_x "$as_dir/$ac_word$ac_exec_ext"; }; then
++    ac_cv_prog_COMPILE_ET="compile_et"
++    $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
++    break 2
++  fi
++done
++  done
++IFS=$as_save_IFS
++
++fi
++fi
++COMPILE_ET=$ac_cv_prog_COMPILE_ET
++if test -n "$COMPILE_ET"; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $COMPILE_ET" >&5
++$as_echo "$COMPILE_ET" >&6; }
++else
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++fi
++
++
++
++krb_cv_compile_et="no"
++krb_cv_com_err_need_r=""
++krb_cv_compile_et_cross=no
++if test "${COMPILE_ET}" = "compile_et"; then
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether compile_et has the features we need" >&5
++$as_echo_n "checking whether compile_et has the features we need... " >&6; }
++cat > conftest_et.et <<'EOF'
++error_table test conf
++prefix CONFTEST
++index 1
++error_code CODE1, "CODE1"
++index 128
++error_code CODE2, "CODE2"
++end
++EOF
++if ${COMPILE_ET} conftest_et.et >/dev/null 2>&1; then
++    save_CPPFLAGS="${CPPFLAGS}"
++  if test -d "/usr/include/et"; then
++    CPPFLAGS="-I/usr/include/et ${CPPFLAGS}"
++  fi
++    if test "$cross_compiling" = yes; then :
++  krb_cv_compile_et="yes" krb_cv_compile_et_cross=yes
++else
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++
++#include <com_err.h>
++#include <string.h>
++#include "conftest_et.h"
++int main(int argc, char **argv){
++#ifndef ERROR_TABLE_BASE_conf
++#error compile_et does not handle error_table N M
++#endif
++return (CONFTEST_CODE2 - CONFTEST_CODE1) != 127;}
++
++_ACEOF
++if ac_fn_c_try_run "$LINENO"; then :
++  krb_cv_compile_et="yes"
++else
++  CPPFLAGS="${save_CPPFLAGS}"
++fi
++rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
++  conftest.$ac_objext conftest.beam conftest.$ac_ext
++fi
++
++fi
++{ $as_echo "$as_me:${as_lineno-$LINENO}: result: ${krb_cv_compile_et}" >&5
++$as_echo "${krb_cv_compile_et}" >&6; }
++if test "${krb_cv_compile_et}" = "yes" -a "${krb_cv_compile_et_cross}" = no; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for if com_err generates a initialize_conf_error_table_r" >&5
++$as_echo_n "checking for if com_err generates a initialize_conf_error_table_r... " >&6; }
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include "conftest_et.h"
++_ACEOF
++if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
++  $EGREP "initialize_conf_error_table_r.*struct et_list" >/dev/null 2>&1; then :
++  krb_cv_com_err_need_r="ok"
++fi
++rm -f conftest*
++
++  if test X"$krb_cv_com_err_need_r" = X ; then
++    { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
++$as_echo "no" >&6; }
++    krb_cv_compile_et=no
++  else
++    { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
++$as_echo "yes" >&6; }
++  fi
++fi
++rm -fr conftest*
++fi
++
++if test "${krb_cv_compile_et_cross}" = yes ; then
++  krb_cv_com_err="cross"
++elif test "${krb_cv_compile_et}" = "yes"; then
++    krb_cv_save_LIBS="${LIBS}"
++  LIBS="${LIBS} -lcom_err"
++  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for com_err" >&5
++$as_echo_n "checking for com_err... " >&6; }
++  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
++/* end confdefs.h.  */
++#include <com_err.h>
++int
++main ()
++{
++
++    const char *p;
++    p = error_message(0);
++    initialize_error_table_r(0,0,0,0);
++    com_right_r(0, 0, 0, 0);
++
++  ;
++  return 0;
++}
++_ACEOF
++if ac_fn_c_try_link "$LINENO"; then :
++  krb_cv_com_err="yes"
++else
++  krb_cv_com_err="no"; CPPFLAGS="${save_CPPFLAGS}"
++fi
++rm -f core conftest.err conftest.$ac_objext \
++    conftest$ac_exeext conftest.$ac_ext
++  { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${krb_cv_com_err}" >&5
++$as_echo "${krb_cv_com_err}" >&6; }
++  LIBS="${krb_cv_save_LIBS}"
++else
++    krb_cv_com_err="no"
++fi
++
++if test "${krb_cv_com_err}" = "yes"; then
++    DIR_com_err=""
++    LIB_com_err="-lcom_err"
++    LIB_com_err_a=""
++    LIB_com_err_so=""
++    { $as_echo "$as_me:${as_lineno-$LINENO}: Using the already-installed com_err" >&5
++$as_echo "$as_me: Using the already-installed com_err" >&6;}
++    localcomerr=no
++elif test "${krb_cv_com_err}" = "cross"; then
++    DIR_com_err="com_err"
++    LIB_com_err="\$(top_builddir)/lib/com_err/libcom_err.la"
++    LIB_com_err_a="\$(top_builddir)/lib/com_err/.libs/libcom_err.a"
++    LIB_com_err_so="\$(top_builddir)/lib/com_err/.libs/libcom_err.so"
++    { $as_echo "$as_me:${as_lineno-$LINENO}: Using our own com_err with toolchain compile_et" >&5
++$as_echo "$as_me: Using our own com_err with toolchain compile_et" >&6;}
++    localcomerr=yes
++else
++    COMPILE_ET="\$(top_builddir)/lib/com_err/compile_et"
++    DIR_com_err="com_err"
++    LIB_com_err="\$(top_builddir)/lib/com_err/libcom_err.la"
++    LIB_com_err_a="\$(top_builddir)/lib/com_err/.libs/libcom_err.a"
++    LIB_com_err_so="\$(top_builddir)/lib/com_err/.libs/libcom_err.so"
++    { $as_echo "$as_me:${as_lineno-$LINENO}: Using our own com_err" >&5
++$as_echo "$as_me: Using our own com_err" >&6;}
++    localcomerr=yes
++fi
++ if test "$localcomerr" = yes; then
++  COM_ERR_TRUE=
++  COM_ERR_FALSE='#'
++else
++  COM_ERR_TRUE='#'
++  COM_ERR_FALSE=
++fi
++
++
++
++
++
++
++
++
++{ $as_echo "$as_me:${as_lineno-$LINENO}: checking which authentication modules should be built" >&5
++$as_echo_n "checking which authentication modules should be built... " >&6; }
++
++z='sia afskauthlib'
++LIB_AUTH_SUBDIRS=
++for i in $z; do
++case $i in
++sia)
++if test "$ac_cv_header_siad_h" = yes; then
++	LIB_AUTH_SUBDIRS="$LIB_AUTH_SUBDIRS sia"
++fi
++;;
++pam)
++case "${host}" in
++*-*-freebsd*)	ac_cv_want_pam_krb4=no ;;
++*)		ac_cv_want_pam_krb4=yes ;;
++esac
++
++if test "$ac_cv_want_pam_krb4" = yes -a \
++    "$ac_cv_header_security_pam_modules_h" = yes -a \
++    "$enable_shared" = yes; then
++	LIB_AUTH_SUBDIRS="$LIB_AUTH_SUBDIRS pam"
++fi
++;;
++afskauthlib)
++case "${host}" in
++*-*-irix[56]*) LIB_AUTH_SUBDIRS="$LIB_AUTH_SUBDIRS afskauthlib" ;;
++esac
++;;
++esac
++done
++if test "$LIB_AUTH_SUBDIRS"; then
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $LIB_AUTH_SUBDIRS" >&5
++$as_echo "$LIB_AUTH_SUBDIRS" >&6; }
++else
++	{ $as_echo "$as_me:${as_lineno-$LINENO}: result: none" >&5
++$as_echo "none" >&6; }
++fi
++
++
++
++
++# This is done by AC_OUTPUT but we need the result here.
++test "x$prefix" = xNONE && prefix=$ac_default_prefix
++test "x$exec_prefix" = xNONE && exec_prefix='${prefix}'
++
++
++	x="${bindir}"
++	eval y="$x"
++	while test "x$y" != "x$x"; do
++		x="$y"
++		eval y="$x"
++	done
++
++cat >>confdefs.h <<_ACEOF
++#define BINDIR "$x"
++_ACEOF
++
++	x="${libdir}"
++	eval y="$x"
++	while test "x$y" != "x$x"; do
++		x="$y"
++		eval y="$x"
++	done
++
++cat >>confdefs.h <<_ACEOF
++#define LIBDIR "$x"
++_ACEOF
++
++	x="${libexecdir}"
++	eval y="$x"
++	while test "x$y" != "x$x"; do
++		x="$y"
++		eval y="$x"
++	done
++
++cat >>confdefs.h <<_ACEOF
++#define LIBEXECDIR "$x"
++_ACEOF
++
++	x="${localstatedir}"
++	eval y="$x"
++	while test "x$y" != "x$x"; do
++		x="$y"
++		eval y="$x"
++	done
++
++cat >>confdefs.h <<_ACEOF
++#define LOCALSTATEDIR "$x"
++_ACEOF
++
++	x="${sbindir}"
++	eval y="$x"
++	while test "x$y" != "x$x"; do
++		x="$y"
++		eval y="$x"
++	done
++
++cat >>confdefs.h <<_ACEOF
++#define SBINDIR "$x"
++_ACEOF
++
++	x="${sysconfdir}"
++	eval y="$x"
++	while test "x$y" != "x$x"; do
++		x="$y"
++		eval y="$x"
++	done
++
++cat >>confdefs.h <<_ACEOF
++#define SYSCONFDIR "$x"
++_ACEOF
++
++
++
++
++
++# Check whether --enable-developer was given.
++if test "${enable_developer+set}" = set; then :
++  enableval=$enable_developer;
++fi
++
++if test "X$enable_developer" = Xyes; then
++    dwflags="-Werror"
++fi
++
++WFLAGS_NOUNUSED=""
++WFLAGS_NOIMPLICITINT=""
++if test -z "$WFLAGS" -a "$GCC" = "yes"; then
++  # -Wno-implicit-int for broken X11 headers
++  # leave these out for now:
++  #   -Wcast-align doesn't work well on alpha osf/1
++  #   -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast
++  #   -Wmissing-declarations -Wnested-externs
++  #   -Wstrict-overflow=5
++  WFLAGS="-Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs $dwflags"
++  WFLAGS_NOUNUSED="-Wno-unused"
++  WFLAGS_NOIMPLICITINT="-Wno-implicit-int"
++fi
++
++
++
++
++
++
++
++ac_config_files="$ac_config_files Makefile etc/Makefile include/Makefile include/gssapi/Makefile include/hcrypto/Makefile include/kadm5/Makefile lib/Makefile base/Makefile lib/asn1/Makefile lib/com_err/Makefile lib/hcrypto/Makefile lib/editline/Makefile lib/hx509/Makefile lib/gssapi/Makefile lib/ntlm/Makefile lib/hdb/Makefile lib/ipc/Makefile lib/kadm5/Makefile lib/kafs/Makefile lib/kdfs/Makefile lib/krb5/Makefile lib/otp/Makefile lib/roken/Makefile lib/sl/Makefile lib/sqlite/Makefile lib/vers/Makefile lib/wind/Makefile po/Makefile kuser/Makefile kpasswd/Makefile kadmin/Makefile admin/Makefile kcm/Makefile kdc/Makefile appl/Makefile appl/afsutil/Makefile appl/ftp/Makefile appl/ftp/common/Makefile appl/ftp/ftp/Makefile appl/ftp/ftpd/Makefile appl/gssmask/Makefile appl/kx/Makefile appl/login/Makefile appl/otp/Makefile appl/popper/Makefile appl/push/Makefile appl/rsh/Makefile appl/rcp/Makefile appl/su/Makefile appl/xnlock/Makefile appl/telnet/Makefile appl/telnet/libtelnet/Makefile appl/telnet/telnet/Makefile appl/telnet/telnetd/Makefile appl/test/Makefile appl/kf/Makefile appl/dceutils/Makefile tests/Makefile tests/bin/Makefile tests/can/Makefile tests/db/Makefile tests/kdc/Makefile tests/ldap/Makefile tests/gss/Makefile tests/java/Makefile tests/plugin/Makefile packages/Makefile packages/mac/Makefile doc/Makefile tools/Makefile"
++
++
++cat >confcache <<\_ACEOF
++# This file is a shell script that caches the results of configure
++# tests run on this system so they can be shared between configure
++# scripts and configure runs, see configure's option --config-cache.
++# It is not useful on other systems.  If it contains results you don't
++# want to keep, you may remove or edit it.
++#
++# config.status only pays attention to the cache file if you give it
++# the --recheck option to rerun configure.
++#
++# `ac_cv_env_foo' variables (set or unset) will be overridden when
++# loading this file, other *unset* `ac_cv_foo' will be assigned the
++# following values.
++
++_ACEOF
++
++# The following way of writing the cache mishandles newlines in values,
++# but we know of no workaround that is simple, portable, and efficient.
++# So, we kill variables containing newlines.
++# Ultrix sh set writes to stderr and can't be redirected directly,
++# and sets the high bit in the cache file unless we assign to the vars.
++(
++  for ac_var in `(set) 2>&1 | sed -n 's/^\([a-zA-Z_][a-zA-Z0-9_]*\)=.*/\1/p'`; do
++    eval ac_val=\$$ac_var
++    case $ac_val in #(
++    *${as_nl}*)
++      case $ac_var in #(
++      *_cv_*) { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: cache variable $ac_var contains a newline" >&5
++$as_echo "$as_me: WARNING: cache variable $ac_var contains a newline" >&2;} ;;
++      esac
++      case $ac_var in #(
++      _ | IFS | as_nl) ;; #(
++      BASH_ARGV | BASH_SOURCE) eval $ac_var= ;; #(
++      *) { eval $ac_var=; unset $ac_var;} ;;
++      esac ;;
++    esac
++  done
++
++  (set) 2>&1 |
++    case $as_nl`(ac_space=' '; set) 2>&1` in #(
++    *${as_nl}ac_space=\ *)
++      # `set' does not quote correctly, so add quotes: double-quote
++      # substitution turns \\\\ into \\, and sed turns \\ into \.
++      sed -n \
++	"s/'/'\\\\''/g;
++	  s/^\\([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*\\)=\\(.*\\)/\\1='\\2'/p"
++      ;; #(
++    *)
++      # `set' quotes correctly as required by POSIX, so do not add quotes.
++      sed -n "/^[_$as_cr_alnum]*_cv_[_$as_cr_alnum]*=/p"
++      ;;
++    esac |
++    sort
++) |
++  sed '
++     /^ac_cv_env_/b end
++     t clear
++     :clear
++     s/^\([^=]*\)=\(.*[{}].*\)$/test "${\1+set}" = set || &/
++     t end
++     s/^\([^=]*\)=\(.*\)$/\1=${\1=\2}/
++     :end' >>confcache
++if diff "$cache_file" confcache >/dev/null 2>&1; then :; else
++  if test -w "$cache_file"; then
++    test "x$cache_file" != "x/dev/null" &&
++      { $as_echo "$as_me:${as_lineno-$LINENO}: updating cache $cache_file" >&5
++$as_echo "$as_me: updating cache $cache_file" >&6;}
++    cat confcache >$cache_file
++  else
++    { $as_echo "$as_me:${as_lineno-$LINENO}: not updating unwritable cache $cache_file" >&5
++$as_echo "$as_me: not updating unwritable cache $cache_file" >&6;}
++  fi
++fi
++rm -f confcache
++
++test "x$prefix" = xNONE && prefix=$ac_default_prefix
++# Let make expand exec_prefix.
++test "x$exec_prefix" = xNONE && exec_prefix='${prefix}'
++
++DEFS=-DHAVE_CONFIG_H
++
++ac_libobjs=
++ac_ltlibobjs=
++U=
++for ac_i in : $LIBOBJS; do test "x$ac_i" = x: && continue
++  # 1. Remove the extension, and $U if already installed.
++  ac_script='s/\$U\././;s/\.o$//;s/\.obj$//'
++  ac_i=`$as_echo "$ac_i" | sed "$ac_script"`
++  # 2. Prepend LIBOBJDIR.  When used with automake>=1.10 LIBOBJDIR
++  #    will be set to the directory where LIBOBJS objects are built.
++  as_fn_append ac_libobjs " \${LIBOBJDIR}$ac_i\$U.$ac_objext"
++  as_fn_append ac_ltlibobjs " \${LIBOBJDIR}$ac_i"'$U.lo'
++done
++LIBOBJS=$ac_libobjs
++
++LTLIBOBJS=$ac_ltlibobjs
++
++
++if test -z "${MAINTAINER_MODE_TRUE}" && test -z "${MAINTAINER_MODE_FALSE}"; then
++  as_fn_error $? "conditional \"MAINTAINER_MODE\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++ if test -n "$EXEEXT"; then
++  am__EXEEXT_TRUE=
++  am__EXEEXT_FALSE='#'
++else
++  am__EXEEXT_TRUE='#'
++  am__EXEEXT_FALSE=
++fi
++
++if test -z "${MAINTAINER_MODE_TRUE}" && test -z "${MAINTAINER_MODE_FALSE}"; then
++  as_fn_error $? "conditional \"MAINTAINER_MODE\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${AMDEP_TRUE}" && test -z "${AMDEP_FALSE}"; then
++  as_fn_error $? "conditional \"AMDEP\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${am__fastdepCC_TRUE}" && test -z "${am__fastdepCC_FALSE}"; then
++  as_fn_error $? "conditional \"am__fastdepCC\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${AIX_TRUE}" && test -z "${AIX_FALSE}"; then
++  as_fn_error $? "conditional \"AIX\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${AIX4_TRUE}" && test -z "${AIX4_FALSE}"; then
++  as_fn_error $? "conditional \"AIX4\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${HAVE_DLOPEN_TRUE}" && test -z "${HAVE_DLOPEN_FALSE}"; then
++  as_fn_error $? "conditional \"HAVE_DLOPEN\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${AIX_DYNAMIC_AFS_TRUE}" && test -z "${AIX_DYNAMIC_AFS_FALSE}"; then
++  as_fn_error $? "conditional \"AIX_DYNAMIC_AFS\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${IRIX_TRUE}" && test -z "${IRIX_FALSE}"; then
++  as_fn_error $? "conditional \"IRIX\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${ENABLE_SHARED_TRUE}" && test -z "${ENABLE_SHARED_FALSE}"; then
++  as_fn_error $? "conditional \"ENABLE_SHARED\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${versionscript_TRUE}" && test -z "${versionscript_FALSE}"; then
++  as_fn_error $? "conditional \"versionscript\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${CROSS_COMPILE_TRUE}" && test -z "${CROSS_COMPILE_FALSE}"; then
++  as_fn_error $? "conditional \"CROSS_COMPILE\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${OPENLDAP_MODULE_TRUE}" && test -z "${OPENLDAP_MODULE_FALSE}"; then
++  as_fn_error $? "conditional \"OPENLDAP_MODULE\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${PKINIT_TRUE}" && test -z "${PKINIT_FALSE}"; then
++  as_fn_error $? "conditional \"PKINIT\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${HAVE_CAPNG_TRUE}" && test -z "${HAVE_CAPNG_FALSE}"; then
++  as_fn_error $? "conditional \"HAVE_CAPNG\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${SQLITE3_TRUE}" && test -z "${SQLITE3_FALSE}"; then
++  as_fn_error $? "conditional \"SQLITE3\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${have_scc_TRUE}" && test -z "${have_scc_FALSE}"; then
++  as_fn_error $? "conditional \"have_scc\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${KRB4_TRUE}" && test -z "${KRB4_FALSE}"; then
++  as_fn_error $? "conditional \"KRB4\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${KRB5_TRUE}" && test -z "${KRB5_FALSE}"; then
++  as_fn_error $? "conditional \"KRB5\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${do_roken_rename_TRUE}" && test -z "${do_roken_rename_FALSE}"; then
++  as_fn_error $? "conditional \"do_roken_rename\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${HAVE_OPENSSL_TRUE}" && test -z "${HAVE_OPENSSL_FALSE}"; then
++  as_fn_error $? "conditional \"HAVE_OPENSSL\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${DCE_TRUE}" && test -z "${DCE_FALSE}"; then
++  as_fn_error $? "conditional \"DCE\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${HAVE_DB1_TRUE}" && test -z "${HAVE_DB1_FALSE}"; then
++  as_fn_error $? "conditional \"HAVE_DB1\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${HAVE_DB3_TRUE}" && test -z "${HAVE_DB3_FALSE}"; then
++  as_fn_error $? "conditional \"HAVE_DB3\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${HAVE_NDBM_TRUE}" && test -z "${HAVE_NDBM_FALSE}"; then
++  as_fn_error $? "conditional \"HAVE_NDBM\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${HAVE_DBHEADER_TRUE}" && test -z "${HAVE_DBHEADER_FALSE}"; then
++  as_fn_error $? "conditional \"HAVE_DBHEADER\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${have_err_h_TRUE}" && test -z "${have_err_h_FALSE}"; then
++  as_fn_error $? "conditional \"have_err_h\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${have_ifaddrs_h_TRUE}" && test -z "${have_ifaddrs_h_FALSE}"; then
++  as_fn_error $? "conditional \"have_ifaddrs_h\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${have_vis_h_TRUE}" && test -z "${have_vis_h_FALSE}"; then
++  as_fn_error $? "conditional \"have_vis_h\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${have_glob_h_TRUE}" && test -z "${have_glob_h_FALSE}"; then
++  as_fn_error $? "conditional \"have_glob_h\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${have_cgetent_TRUE}" && test -z "${have_cgetent_FALSE}"; then
++  as_fn_error $? "conditional \"have_cgetent\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${have_fnmatch_h_TRUE}" && test -z "${have_fnmatch_h_FALSE}"; then
++  as_fn_error $? "conditional \"have_fnmatch_h\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${have_socket_wrapper_TRUE}" && test -z "${have_socket_wrapper_FALSE}"; then
++  as_fn_error $? "conditional \"have_socket_wrapper\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${OTP_TRUE}" && test -z "${OTP_FALSE}"; then
++  as_fn_error $? "conditional \"OTP\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${have_gcd_TRUE}" && test -z "${have_gcd_FALSE}"; then
++  as_fn_error $? "conditional \"have_gcd\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${CATMAN_TRUE}" && test -z "${CATMAN_FALSE}"; then
++  as_fn_error $? "conditional \"CATMAN\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${HAVE_X_TRUE}" && test -z "${HAVE_X_FALSE}"; then
++  as_fn_error $? "conditional \"HAVE_X\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${NEED_WRITEAUTH_TRUE}" && test -z "${NEED_WRITEAUTH_FALSE}"; then
++  as_fn_error $? "conditional \"NEED_WRITEAUTH\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${KCM_TRUE}" && test -z "${KCM_FALSE}"; then
++  as_fn_error $? "conditional \"KCM\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${FRAMEWORK_SECURITY_TRUE}" && test -z "${FRAMEWORK_SECURITY_FALSE}"; then
++  as_fn_error $? "conditional \"FRAMEWORK_SECURITY\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${EDITLINE_TRUE}" && test -z "${EDITLINE_FALSE}"; then
++  as_fn_error $? "conditional \"EDITLINE\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${el_compat_TRUE}" && test -z "${el_compat_FALSE}"; then
++  as_fn_error $? "conditional \"el_compat\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++if test -z "${COM_ERR_TRUE}" && test -z "${COM_ERR_FALSE}"; then
++  as_fn_error $? "conditional \"COM_ERR\" was never defined.
++Usually this means the macro was only invoked conditionally." "$LINENO" 5
++fi
++
++: ${CONFIG_STATUS=./config.status}
++ac_write_fail=0
++ac_clean_files_save=$ac_clean_files
++ac_clean_files="$ac_clean_files $CONFIG_STATUS"
++{ $as_echo "$as_me:${as_lineno-$LINENO}: creating $CONFIG_STATUS" >&5
++$as_echo "$as_me: creating $CONFIG_STATUS" >&6;}
++as_write_fail=0
++cat >$CONFIG_STATUS <<_ASEOF || as_write_fail=1
++#! $SHELL
++# Generated by $as_me.
++# Run this file to recreate the current configuration.
++# Compiler output produced by configure, useful for debugging
++# configure, is in config.log if it exists.
++
++debug=false
++ac_cs_recheck=false
++ac_cs_silent=false
++
++SHELL=\${CONFIG_SHELL-$SHELL}
++export SHELL
++_ASEOF
++cat >>$CONFIG_STATUS <<\_ASEOF || as_write_fail=1
++## -------------------- ##
++## M4sh Initialization. ##
++## -------------------- ##
++
++# Be more Bourne compatible
++DUALCASE=1; export DUALCASE # for MKS sh
++if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then :
++  emulate sh
++  NULLCMD=:
++  # Pre-4.2 versions of Zsh do word splitting on ${1+"$@"}, which
++  # is contrary to our usage.  Disable this feature.
++  alias -g '${1+"$@"}'='"$@"'
++  setopt NO_GLOB_SUBST
++else
++  case `(set -o) 2>/dev/null` in #(
++  *posix*) :
++    set -o posix ;; #(
++  *) :
++     ;;
++esac
++fi
++
++
++as_nl='
++'
++export as_nl
++# Printing a long string crashes Solaris 7 /usr/bin/printf.
++as_echo='\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'
++as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo
++as_echo=$as_echo$as_echo$as_echo$as_echo$as_echo$as_echo
++# Prefer a ksh shell builtin over an external printf program on Solaris,
++# but without wasting forks for bash or zsh.
++if test -z "$BASH_VERSION$ZSH_VERSION" \
++    && (test "X`print -r -- $as_echo`" = "X$as_echo") 2>/dev/null; then
++  as_echo='print -r --'
++  as_echo_n='print -rn --'
++elif (test "X`printf %s $as_echo`" = "X$as_echo") 2>/dev/null; then
++  as_echo='printf %s\n'
++  as_echo_n='printf %s'
++else
++  if test "X`(/usr/ucb/echo -n -n $as_echo) 2>/dev/null`" = "X-n $as_echo"; then
++    as_echo_body='eval /usr/ucb/echo -n "$1$as_nl"'
++    as_echo_n='/usr/ucb/echo -n'
++  else
++    as_echo_body='eval expr "X$1" : "X\\(.*\\)"'
++    as_echo_n_body='eval
++      arg=$1;
++      case $arg in #(
++      *"$as_nl"*)
++	expr "X$arg" : "X\\(.*\\)$as_nl";
++	arg=`expr "X$arg" : ".*$as_nl\\(.*\\)"`;;
++      esac;
++      expr "X$arg" : "X\\(.*\\)" | tr -d "$as_nl"
++    '
++    export as_echo_n_body
++    as_echo_n='sh -c $as_echo_n_body as_echo'
++  fi
++  export as_echo_body
++  as_echo='sh -c $as_echo_body as_echo'
++fi
++
++# The user is always right.
++if test "${PATH_SEPARATOR+set}" != set; then
++  PATH_SEPARATOR=:
++  (PATH='/bin;/bin'; FPATH=$PATH; sh -c :) >/dev/null 2>&1 && {
++    (PATH='/bin:/bin'; FPATH=$PATH; sh -c :) >/dev/null 2>&1 ||
++      PATH_SEPARATOR=';'
++  }
++fi
++
++
++# IFS
++# We need space, tab and new line, in precisely that order.  Quoting is
++# there to prevent editors from complaining about space-tab.
++# (If _AS_PATH_WALK were called with IFS unset, it would disable word
++# splitting by setting IFS to empty value.)
++IFS=" ""	$as_nl"
++
++# Find who we are.  Look in the path if we contain no directory separator.
++case $0 in #((
++  *[\\/]* ) as_myself=$0 ;;
++  *) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
++for as_dir in $PATH
++do
++  IFS=$as_save_IFS
++  test -z "$as_dir" && as_dir=.
++    test -r "$as_dir/$0" && as_myself=$as_dir/$0 && break
++  done
++IFS=$as_save_IFS
++
++     ;;
++esac
++# We did not find ourselves, most probably we were run as `sh COMMAND'
++# in which case we are not to be found in the path.
++if test "x$as_myself" = x; then
++  as_myself=$0
++fi
++if test ! -f "$as_myself"; then
++  $as_echo "$as_myself: error: cannot find myself; rerun with an absolute file name" >&2
++  exit 1
++fi
++
++# Unset variables that we do not need and which cause bugs (e.g. in
++# pre-3.0 UWIN ksh).  But do not cause bugs in bash 2.01; the "|| exit 1"
++# suppresses any "Segmentation fault" message there.  '((' could
++# trigger a bug in pdksh 5.2.14.
++for as_var in BASH_ENV ENV MAIL MAILPATH
++do eval test x\${$as_var+set} = xset \
++  && ( (unset $as_var) || exit 1) >/dev/null 2>&1 && unset $as_var || :
++done
++PS1='$ '
++PS2='> '
++PS4='+ '
++
++# NLS nuisances.
++LC_ALL=C
++export LC_ALL
++LANGUAGE=C
++export LANGUAGE
++
++# CDPATH.
++(unset CDPATH) >/dev/null 2>&1 && unset CDPATH
++
++
++# as_fn_error STATUS ERROR [LINENO LOG_FD]
++# ----------------------------------------
++# Output "`basename $0`: error: ERROR" to stderr. If LINENO and LOG_FD are
++# provided, also output the error to LOG_FD, referencing LINENO. Then exit the
++# script with STATUS, using 1 if that was 0.
++as_fn_error ()
++{
++  as_status=$1; test $as_status -eq 0 && as_status=1
++  if test "$4"; then
++    as_lineno=${as_lineno-"$3"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
++    $as_echo "$as_me:${as_lineno-$LINENO}: error: $2" >&$4
++  fi
++  $as_echo "$as_me: error: $2" >&2
++  as_fn_exit $as_status
++} # as_fn_error
++
++
++# as_fn_set_status STATUS
++# -----------------------
++# Set $? to STATUS, without forking.
++as_fn_set_status ()
++{
++  return $1
++} # as_fn_set_status
++
++# as_fn_exit STATUS
++# -----------------
++# Exit the shell with STATUS, even in a "trap 0" or "set -e" context.
++as_fn_exit ()
++{
++  set +e
++  as_fn_set_status $1
++  exit $1
++} # as_fn_exit
++
++# as_fn_unset VAR
++# ---------------
++# Portably unset VAR.
++as_fn_unset ()
++{
++  { eval $1=; unset $1;}
++}
++as_unset=as_fn_unset
++# as_fn_append VAR VALUE
++# ----------------------
++# Append the text in VALUE to the end of the definition contained in VAR. Take
++# advantage of any shell optimizations that allow amortized linear growth over
++# repeated appends, instead of the typical quadratic growth present in naive
++# implementations.
++if (eval "as_var=1; as_var+=2; test x\$as_var = x12") 2>/dev/null; then :
++  eval 'as_fn_append ()
++  {
++    eval $1+=\$2
++  }'
++else
++  as_fn_append ()
++  {
++    eval $1=\$$1\$2
++  }
++fi # as_fn_append
++
++# as_fn_arith ARG...
++# ------------------
++# Perform arithmetic evaluation on the ARGs, and store the result in the
++# global $as_val. Take advantage of shells that can avoid forks. The arguments
++# must be portable across $(()) and expr.
++if (eval "test \$(( 1 + 1 )) = 2") 2>/dev/null; then :
++  eval 'as_fn_arith ()
++  {
++    as_val=$(( $* ))
++  }'
++else
++  as_fn_arith ()
++  {
++    as_val=`expr "$@" || test $? -eq 1`
++  }
++fi # as_fn_arith
++
++
++if expr a : '\(a\)' >/dev/null 2>&1 &&
++   test "X`expr 00001 : '.*\(...\)'`" = X001; then
++  as_expr=expr
++else
++  as_expr=false
++fi
++
++if (basename -- /) >/dev/null 2>&1 && test "X`basename -- / 2>&1`" = "X/"; then
++  as_basename=basename
++else
++  as_basename=false
++fi
++
++if (as_dir=`dirname -- /` && test "X$as_dir" = X/) >/dev/null 2>&1; then
++  as_dirname=dirname
++else
++  as_dirname=false
++fi
++
++as_me=`$as_basename -- "$0" ||
++$as_expr X/"$0" : '.*/\([^/][^/]*\)/*$' \| \
++	 X"$0" : 'X\(//\)$' \| \
++	 X"$0" : 'X\(/\)' \| . 2>/dev/null ||
++$as_echo X/"$0" |
++    sed '/^.*\/\([^/][^/]*\)\/*$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\/\(\/\/\)$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\/\(\/\).*/{
++	    s//\1/
++	    q
++	  }
++	  s/.*/./; q'`
++
++# Avoid depending upon Character Ranges.
++as_cr_letters='abcdefghijklmnopqrstuvwxyz'
++as_cr_LETTERS='ABCDEFGHIJKLMNOPQRSTUVWXYZ'
++as_cr_Letters=$as_cr_letters$as_cr_LETTERS
++as_cr_digits='0123456789'
++as_cr_alnum=$as_cr_Letters$as_cr_digits
++
++ECHO_C= ECHO_N= ECHO_T=
++case `echo -n x` in #(((((
++-n*)
++  case `echo 'xy\c'` in
++  *c*) ECHO_T='	';;	# ECHO_T is single tab character.
++  xy)  ECHO_C='\c';;
++  *)   echo `echo ksh88 bug on AIX 6.1` > /dev/null
++       ECHO_T='	';;
++  esac;;
++*)
++  ECHO_N='-n';;
++esac
++
++rm -f conf$$ conf$$.exe conf$$.file
++if test -d conf$$.dir; then
++  rm -f conf$$.dir/conf$$.file
++else
++  rm -f conf$$.dir
++  mkdir conf$$.dir 2>/dev/null
++fi
++if (echo >conf$$.file) 2>/dev/null; then
++  if ln -s conf$$.file conf$$ 2>/dev/null; then
++    as_ln_s='ln -s'
++    # ... but there are two gotchas:
++    # 1) On MSYS, both `ln -s file dir' and `ln file dir' fail.
++    # 2) DJGPP < 2.04 has no symlinks; `ln -s' creates a wrapper executable.
++    # In both cases, we have to default to `cp -p'.
++    ln -s conf$$.file conf$$.dir 2>/dev/null && test ! -f conf$$.exe ||
++      as_ln_s='cp -p'
++  elif ln conf$$.file conf$$ 2>/dev/null; then
++    as_ln_s=ln
++  else
++    as_ln_s='cp -p'
++  fi
++else
++  as_ln_s='cp -p'
++fi
++rm -f conf$$ conf$$.exe conf$$.dir/conf$$.file conf$$.file
++rmdir conf$$.dir 2>/dev/null
++
++
++# as_fn_mkdir_p
++# -------------
++# Create "$as_dir" as a directory, including parents if necessary.
++as_fn_mkdir_p ()
++{
++
++  case $as_dir in #(
++  -*) as_dir=./$as_dir;;
++  esac
++  test -d "$as_dir" || eval $as_mkdir_p || {
++    as_dirs=
++    while :; do
++      case $as_dir in #(
++      *\'*) as_qdir=`$as_echo "$as_dir" | sed "s/'/'\\\\\\\\''/g"`;; #'(
++      *) as_qdir=$as_dir;;
++      esac
++      as_dirs="'$as_qdir' $as_dirs"
++      as_dir=`$as_dirname -- "$as_dir" ||
++$as_expr X"$as_dir" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
++	 X"$as_dir" : 'X\(//\)[^/]' \| \
++	 X"$as_dir" : 'X\(//\)$' \| \
++	 X"$as_dir" : 'X\(/\)' \| . 2>/dev/null ||
++$as_echo X"$as_dir" |
++    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\/\)[^/].*/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\/\)$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\).*/{
++	    s//\1/
++	    q
++	  }
++	  s/.*/./; q'`
++      test -d "$as_dir" && break
++    done
++    test -z "$as_dirs" || eval "mkdir $as_dirs"
++  } || test -d "$as_dir" || as_fn_error $? "cannot create directory $as_dir"
++
++
++} # as_fn_mkdir_p
++if mkdir -p . 2>/dev/null; then
++  as_mkdir_p='mkdir -p "$as_dir"'
++else
++  test -d ./-p && rmdir ./-p
++  as_mkdir_p=false
++fi
++
++if test -x / >/dev/null 2>&1; then
++  as_test_x='test -x'
++else
++  if ls -dL / >/dev/null 2>&1; then
++    as_ls_L_option=L
++  else
++    as_ls_L_option=
++  fi
++  as_test_x='
++    eval sh -c '\''
++      if test -d "$1"; then
++	test -d "$1/.";
++      else
++	case $1 in #(
++	-*)set "./$1";;
++	esac;
++	case `ls -ld'$as_ls_L_option' "$1" 2>/dev/null` in #((
++	???[sx]*):;;*)false;;esac;fi
++    '\'' sh
++  '
++fi
++as_executable_p=$as_test_x
++
++# Sed expression to map a string onto a valid CPP name.
++as_tr_cpp="eval sed 'y%*$as_cr_letters%P$as_cr_LETTERS%;s%[^_$as_cr_alnum]%_%g'"
++
++# Sed expression to map a string onto a valid variable name.
++as_tr_sh="eval sed 'y%*+%pp%;s%[^_$as_cr_alnum]%_%g'"
++
++
++exec 6>&1
++## ----------------------------------- ##
++## Main body of $CONFIG_STATUS script. ##
++## ----------------------------------- ##
++_ASEOF
++test $as_write_fail = 0 && chmod +x $CONFIG_STATUS || ac_write_fail=1
++
++cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
++# Save the log message, to keep $0 and so on meaningful, and to
++# report actual input values of CONFIG_FILES etc. instead of their
++# values after options handling.
++ac_log="
++This file was extended by Heimdal $as_me 1.4.99, which was
++generated by GNU Autoconf 2.67.  Invocation command line was
++
++  CONFIG_FILES    = $CONFIG_FILES
++  CONFIG_HEADERS  = $CONFIG_HEADERS
++  CONFIG_LINKS    = $CONFIG_LINKS
++  CONFIG_COMMANDS = $CONFIG_COMMANDS
++  $ $0 $@
++
++on `(hostname || uname -n) 2>/dev/null | sed 1q`
++"
++
++_ACEOF
++
++case $ac_config_files in *"
++"*) set x $ac_config_files; shift; ac_config_files=$*;;
++esac
++
++case $ac_config_headers in *"
++"*) set x $ac_config_headers; shift; ac_config_headers=$*;;
++esac
++
++
++cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
++# Files that config.status was made for.
++config_files="$ac_config_files"
++config_headers="$ac_config_headers"
++config_commands="$ac_config_commands"
++
++_ACEOF
++
++cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
++ac_cs_usage="\
++\`$as_me' instantiates files and other configuration actions
++from templates according to the current configuration.  Unless the files
++and actions are specified as TAGs, all are instantiated by default.
++
++Usage: $0 [OPTION]... [TAG]...
++
++  -h, --help       print this help, then exit
++  -V, --version    print version number and configuration settings, then exit
++      --config     print configuration, then exit
++  -q, --quiet, --silent
++                   do not print progress messages
++  -d, --debug      don't remove temporary files
++      --recheck    update $as_me by reconfiguring in the same conditions
++      --file=FILE[:TEMPLATE]
++                   instantiate the configuration file FILE
++      --header=FILE[:TEMPLATE]
++                   instantiate the configuration header FILE
++
++Configuration files:
++$config_files
++
++Configuration headers:
++$config_headers
++
++Configuration commands:
++$config_commands
++
++Report bugs to <heimdal-bugs@h5l.org>."
++
++_ACEOF
++cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
++ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`"
++ac_cs_version="\\
++Heimdal config.status 1.4.99
++configured by $0, generated by GNU Autoconf 2.67,
++  with options \\"\$ac_cs_config\\"
++
++Copyright (C) 2010 Free Software Foundation, Inc.
++This config.status script is free software; the Free Software Foundation
++gives unlimited permission to copy, distribute and modify it."
++
++ac_pwd='$ac_pwd'
++srcdir='$srcdir'
++INSTALL='$INSTALL'
++MKDIR_P='$MKDIR_P'
++AWK='$AWK'
++test -n "\$AWK" || AWK=awk
++_ACEOF
++
++cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
++# The default lists apply if the user does not specify any file.
++ac_need_defaults=:
++while test $# != 0
++do
++  case $1 in
++  --*=?*)
++    ac_option=`expr "X$1" : 'X\([^=]*\)='`
++    ac_optarg=`expr "X$1" : 'X[^=]*=\(.*\)'`
++    ac_shift=:
++    ;;
++  --*=)
++    ac_option=`expr "X$1" : 'X\([^=]*\)='`
++    ac_optarg=
++    ac_shift=:
++    ;;
++  *)
++    ac_option=$1
++    ac_optarg=$2
++    ac_shift=shift
++    ;;
++  esac
++
++  case $ac_option in
++  # Handling of the options.
++  -recheck | --recheck | --rechec | --reche | --rech | --rec | --re | --r)
++    ac_cs_recheck=: ;;
++  --version | --versio | --versi | --vers | --ver | --ve | --v | -V )
++    $as_echo "$ac_cs_version"; exit ;;
++  --config | --confi | --conf | --con | --co | --c )
++    $as_echo "$ac_cs_config"; exit ;;
++  --debug | --debu | --deb | --de | --d | -d )
++    debug=: ;;
++  --file | --fil | --fi | --f )
++    $ac_shift
++    case $ac_optarg in
++    *\'*) ac_optarg=`$as_echo "$ac_optarg" | sed "s/'/'\\\\\\\\''/g"` ;;
++    '') as_fn_error $? "missing file argument" ;;
++    esac
++    as_fn_append CONFIG_FILES " '$ac_optarg'"
++    ac_need_defaults=false;;
++  --header | --heade | --head | --hea )
++    $ac_shift
++    case $ac_optarg in
++    *\'*) ac_optarg=`$as_echo "$ac_optarg" | sed "s/'/'\\\\\\\\''/g"` ;;
++    esac
++    as_fn_append CONFIG_HEADERS " '$ac_optarg'"
++    ac_need_defaults=false;;
++  --he | --h)
++    # Conflict between --help and --header
++    as_fn_error $? "ambiguous option: \`$1'
++Try \`$0 --help' for more information.";;
++  --help | --hel | -h )
++    $as_echo "$ac_cs_usage"; exit ;;
++  -q | -quiet | --quiet | --quie | --qui | --qu | --q \
++  | -silent | --silent | --silen | --sile | --sil | --si | --s)
++    ac_cs_silent=: ;;
++
++  # This is an error.
++  -*) as_fn_error $? "unrecognized option: \`$1'
++Try \`$0 --help' for more information." ;;
++
++  *) as_fn_append ac_config_targets " $1"
++     ac_need_defaults=false ;;
++
++  esac
++  shift
++done
++
++ac_configure_extra_args=
++
++if $ac_cs_silent; then
++  exec 6>/dev/null
++  ac_configure_extra_args="$ac_configure_extra_args --silent"
++fi
++
++_ACEOF
++cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
++if \$ac_cs_recheck; then
++  set X '$SHELL' '$0' $ac_configure_args \$ac_configure_extra_args --no-create --no-recursion
++  shift
++  \$as_echo "running CONFIG_SHELL=$SHELL \$*" >&6
++  CONFIG_SHELL='$SHELL'
++  export CONFIG_SHELL
++  exec "\$@"
++fi
++
++_ACEOF
++cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
++exec 5>>config.log
++{
++  echo
++  sed 'h;s/./-/g;s/^.../## /;s/...$/ ##/;p;x;p;x' <<_ASBOX
++## Running $as_me. ##
++_ASBOX
++  $as_echo "$ac_log"
++} >&5
++
++_ACEOF
++cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
++#
++# INIT-COMMANDS
++#
++AMDEP_TRUE="$AMDEP_TRUE" ac_aux_dir="$ac_aux_dir"
++
++
++# The HP-UX ksh and POSIX shell print the target directory to stdout
++# if CDPATH is set.
++(unset CDPATH) >/dev/null 2>&1 && unset CDPATH
++
++sed_quote_subst='$sed_quote_subst'
++double_quote_subst='$double_quote_subst'
++delay_variable_subst='$delay_variable_subst'
++macro_version='`$ECHO "X$macro_version" | $Xsed -e "$delay_single_quote_subst"`'
++macro_revision='`$ECHO "X$macro_revision" | $Xsed -e "$delay_single_quote_subst"`'
++enable_shared='`$ECHO "X$enable_shared" | $Xsed -e "$delay_single_quote_subst"`'
++enable_static='`$ECHO "X$enable_static" | $Xsed -e "$delay_single_quote_subst"`'
++pic_mode='`$ECHO "X$pic_mode" | $Xsed -e "$delay_single_quote_subst"`'
++enable_fast_install='`$ECHO "X$enable_fast_install" | $Xsed -e "$delay_single_quote_subst"`'
++host_alias='`$ECHO "X$host_alias" | $Xsed -e "$delay_single_quote_subst"`'
++host='`$ECHO "X$host" | $Xsed -e "$delay_single_quote_subst"`'
++host_os='`$ECHO "X$host_os" | $Xsed -e "$delay_single_quote_subst"`'
++build_alias='`$ECHO "X$build_alias" | $Xsed -e "$delay_single_quote_subst"`'
++build='`$ECHO "X$build" | $Xsed -e "$delay_single_quote_subst"`'
++build_os='`$ECHO "X$build_os" | $Xsed -e "$delay_single_quote_subst"`'
++SED='`$ECHO "X$SED" | $Xsed -e "$delay_single_quote_subst"`'
++Xsed='`$ECHO "X$Xsed" | $Xsed -e "$delay_single_quote_subst"`'
++GREP='`$ECHO "X$GREP" | $Xsed -e "$delay_single_quote_subst"`'
++EGREP='`$ECHO "X$EGREP" | $Xsed -e "$delay_single_quote_subst"`'
++FGREP='`$ECHO "X$FGREP" | $Xsed -e "$delay_single_quote_subst"`'
++LD='`$ECHO "X$LD" | $Xsed -e "$delay_single_quote_subst"`'
++NM='`$ECHO "X$NM" | $Xsed -e "$delay_single_quote_subst"`'
++LN_S='`$ECHO "X$LN_S" | $Xsed -e "$delay_single_quote_subst"`'
++max_cmd_len='`$ECHO "X$max_cmd_len" | $Xsed -e "$delay_single_quote_subst"`'
++ac_objext='`$ECHO "X$ac_objext" | $Xsed -e "$delay_single_quote_subst"`'
++exeext='`$ECHO "X$exeext" | $Xsed -e "$delay_single_quote_subst"`'
++lt_unset='`$ECHO "X$lt_unset" | $Xsed -e "$delay_single_quote_subst"`'
++lt_SP2NL='`$ECHO "X$lt_SP2NL" | $Xsed -e "$delay_single_quote_subst"`'
++lt_NL2SP='`$ECHO "X$lt_NL2SP" | $Xsed -e "$delay_single_quote_subst"`'
++reload_flag='`$ECHO "X$reload_flag" | $Xsed -e "$delay_single_quote_subst"`'
++reload_cmds='`$ECHO "X$reload_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++OBJDUMP='`$ECHO "X$OBJDUMP" | $Xsed -e "$delay_single_quote_subst"`'
++deplibs_check_method='`$ECHO "X$deplibs_check_method" | $Xsed -e "$delay_single_quote_subst"`'
++file_magic_cmd='`$ECHO "X$file_magic_cmd" | $Xsed -e "$delay_single_quote_subst"`'
++AR='`$ECHO "X$AR" | $Xsed -e "$delay_single_quote_subst"`'
++AR_FLAGS='`$ECHO "X$AR_FLAGS" | $Xsed -e "$delay_single_quote_subst"`'
++STRIP='`$ECHO "X$STRIP" | $Xsed -e "$delay_single_quote_subst"`'
++RANLIB='`$ECHO "X$RANLIB" | $Xsed -e "$delay_single_quote_subst"`'
++old_postinstall_cmds='`$ECHO "X$old_postinstall_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++old_postuninstall_cmds='`$ECHO "X$old_postuninstall_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++old_archive_cmds='`$ECHO "X$old_archive_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++CC='`$ECHO "X$CC" | $Xsed -e "$delay_single_quote_subst"`'
++CFLAGS='`$ECHO "X$CFLAGS" | $Xsed -e "$delay_single_quote_subst"`'
++compiler='`$ECHO "X$compiler" | $Xsed -e "$delay_single_quote_subst"`'
++GCC='`$ECHO "X$GCC" | $Xsed -e "$delay_single_quote_subst"`'
++lt_cv_sys_global_symbol_pipe='`$ECHO "X$lt_cv_sys_global_symbol_pipe" | $Xsed -e "$delay_single_quote_subst"`'
++lt_cv_sys_global_symbol_to_cdecl='`$ECHO "X$lt_cv_sys_global_symbol_to_cdecl" | $Xsed -e "$delay_single_quote_subst"`'
++lt_cv_sys_global_symbol_to_c_name_address='`$ECHO "X$lt_cv_sys_global_symbol_to_c_name_address" | $Xsed -e "$delay_single_quote_subst"`'
++lt_cv_sys_global_symbol_to_c_name_address_lib_prefix='`$ECHO "X$lt_cv_sys_global_symbol_to_c_name_address_lib_prefix" | $Xsed -e "$delay_single_quote_subst"`'
++objdir='`$ECHO "X$objdir" | $Xsed -e "$delay_single_quote_subst"`'
++SHELL='`$ECHO "X$SHELL" | $Xsed -e "$delay_single_quote_subst"`'
++ECHO='`$ECHO "X$ECHO" | $Xsed -e "$delay_single_quote_subst"`'
++MAGIC_CMD='`$ECHO "X$MAGIC_CMD" | $Xsed -e "$delay_single_quote_subst"`'
++lt_prog_compiler_no_builtin_flag='`$ECHO "X$lt_prog_compiler_no_builtin_flag" | $Xsed -e "$delay_single_quote_subst"`'
++lt_prog_compiler_wl='`$ECHO "X$lt_prog_compiler_wl" | $Xsed -e "$delay_single_quote_subst"`'
++lt_prog_compiler_pic='`$ECHO "X$lt_prog_compiler_pic" | $Xsed -e "$delay_single_quote_subst"`'
++lt_prog_compiler_static='`$ECHO "X$lt_prog_compiler_static" | $Xsed -e "$delay_single_quote_subst"`'
++lt_cv_prog_compiler_c_o='`$ECHO "X$lt_cv_prog_compiler_c_o" | $Xsed -e "$delay_single_quote_subst"`'
++need_locks='`$ECHO "X$need_locks" | $Xsed -e "$delay_single_quote_subst"`'
++DSYMUTIL='`$ECHO "X$DSYMUTIL" | $Xsed -e "$delay_single_quote_subst"`'
++NMEDIT='`$ECHO "X$NMEDIT" | $Xsed -e "$delay_single_quote_subst"`'
++LIPO='`$ECHO "X$LIPO" | $Xsed -e "$delay_single_quote_subst"`'
++OTOOL='`$ECHO "X$OTOOL" | $Xsed -e "$delay_single_quote_subst"`'
++OTOOL64='`$ECHO "X$OTOOL64" | $Xsed -e "$delay_single_quote_subst"`'
++libext='`$ECHO "X$libext" | $Xsed -e "$delay_single_quote_subst"`'
++shrext_cmds='`$ECHO "X$shrext_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++extract_expsyms_cmds='`$ECHO "X$extract_expsyms_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++archive_cmds_need_lc='`$ECHO "X$archive_cmds_need_lc" | $Xsed -e "$delay_single_quote_subst"`'
++enable_shared_with_static_runtimes='`$ECHO "X$enable_shared_with_static_runtimes" | $Xsed -e "$delay_single_quote_subst"`'
++export_dynamic_flag_spec='`$ECHO "X$export_dynamic_flag_spec" | $Xsed -e "$delay_single_quote_subst"`'
++whole_archive_flag_spec='`$ECHO "X$whole_archive_flag_spec" | $Xsed -e "$delay_single_quote_subst"`'
++compiler_needs_object='`$ECHO "X$compiler_needs_object" | $Xsed -e "$delay_single_quote_subst"`'
++old_archive_from_new_cmds='`$ECHO "X$old_archive_from_new_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++old_archive_from_expsyms_cmds='`$ECHO "X$old_archive_from_expsyms_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++archive_cmds='`$ECHO "X$archive_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++archive_expsym_cmds='`$ECHO "X$archive_expsym_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++module_cmds='`$ECHO "X$module_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++module_expsym_cmds='`$ECHO "X$module_expsym_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++with_gnu_ld='`$ECHO "X$with_gnu_ld" | $Xsed -e "$delay_single_quote_subst"`'
++allow_undefined_flag='`$ECHO "X$allow_undefined_flag" | $Xsed -e "$delay_single_quote_subst"`'
++no_undefined_flag='`$ECHO "X$no_undefined_flag" | $Xsed -e "$delay_single_quote_subst"`'
++hardcode_libdir_flag_spec='`$ECHO "X$hardcode_libdir_flag_spec" | $Xsed -e "$delay_single_quote_subst"`'
++hardcode_libdir_flag_spec_ld='`$ECHO "X$hardcode_libdir_flag_spec_ld" | $Xsed -e "$delay_single_quote_subst"`'
++hardcode_libdir_separator='`$ECHO "X$hardcode_libdir_separator" | $Xsed -e "$delay_single_quote_subst"`'
++hardcode_direct='`$ECHO "X$hardcode_direct" | $Xsed -e "$delay_single_quote_subst"`'
++hardcode_direct_absolute='`$ECHO "X$hardcode_direct_absolute" | $Xsed -e "$delay_single_quote_subst"`'
++hardcode_minus_L='`$ECHO "X$hardcode_minus_L" | $Xsed -e "$delay_single_quote_subst"`'
++hardcode_shlibpath_var='`$ECHO "X$hardcode_shlibpath_var" | $Xsed -e "$delay_single_quote_subst"`'
++hardcode_automatic='`$ECHO "X$hardcode_automatic" | $Xsed -e "$delay_single_quote_subst"`'
++inherit_rpath='`$ECHO "X$inherit_rpath" | $Xsed -e "$delay_single_quote_subst"`'
++link_all_deplibs='`$ECHO "X$link_all_deplibs" | $Xsed -e "$delay_single_quote_subst"`'
++fix_srcfile_path='`$ECHO "X$fix_srcfile_path" | $Xsed -e "$delay_single_quote_subst"`'
++always_export_symbols='`$ECHO "X$always_export_symbols" | $Xsed -e "$delay_single_quote_subst"`'
++export_symbols_cmds='`$ECHO "X$export_symbols_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++exclude_expsyms='`$ECHO "X$exclude_expsyms" | $Xsed -e "$delay_single_quote_subst"`'
++include_expsyms='`$ECHO "X$include_expsyms" | $Xsed -e "$delay_single_quote_subst"`'
++prelink_cmds='`$ECHO "X$prelink_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++file_list_spec='`$ECHO "X$file_list_spec" | $Xsed -e "$delay_single_quote_subst"`'
++variables_saved_for_relink='`$ECHO "X$variables_saved_for_relink" | $Xsed -e "$delay_single_quote_subst"`'
++need_lib_prefix='`$ECHO "X$need_lib_prefix" | $Xsed -e "$delay_single_quote_subst"`'
++need_version='`$ECHO "X$need_version" | $Xsed -e "$delay_single_quote_subst"`'
++version_type='`$ECHO "X$version_type" | $Xsed -e "$delay_single_quote_subst"`'
++runpath_var='`$ECHO "X$runpath_var" | $Xsed -e "$delay_single_quote_subst"`'
++shlibpath_var='`$ECHO "X$shlibpath_var" | $Xsed -e "$delay_single_quote_subst"`'
++shlibpath_overrides_runpath='`$ECHO "X$shlibpath_overrides_runpath" | $Xsed -e "$delay_single_quote_subst"`'
++libname_spec='`$ECHO "X$libname_spec" | $Xsed -e "$delay_single_quote_subst"`'
++library_names_spec='`$ECHO "X$library_names_spec" | $Xsed -e "$delay_single_quote_subst"`'
++soname_spec='`$ECHO "X$soname_spec" | $Xsed -e "$delay_single_quote_subst"`'
++postinstall_cmds='`$ECHO "X$postinstall_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++postuninstall_cmds='`$ECHO "X$postuninstall_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++finish_cmds='`$ECHO "X$finish_cmds" | $Xsed -e "$delay_single_quote_subst"`'
++finish_eval='`$ECHO "X$finish_eval" | $Xsed -e "$delay_single_quote_subst"`'
++hardcode_into_libs='`$ECHO "X$hardcode_into_libs" | $Xsed -e "$delay_single_quote_subst"`'
++sys_lib_search_path_spec='`$ECHO "X$sys_lib_search_path_spec" | $Xsed -e "$delay_single_quote_subst"`'
++sys_lib_dlsearch_path_spec='`$ECHO "X$sys_lib_dlsearch_path_spec" | $Xsed -e "$delay_single_quote_subst"`'
++hardcode_action='`$ECHO "X$hardcode_action" | $Xsed -e "$delay_single_quote_subst"`'
++enable_dlopen='`$ECHO "X$enable_dlopen" | $Xsed -e "$delay_single_quote_subst"`'
++enable_dlopen_self='`$ECHO "X$enable_dlopen_self" | $Xsed -e "$delay_single_quote_subst"`'
++enable_dlopen_self_static='`$ECHO "X$enable_dlopen_self_static" | $Xsed -e "$delay_single_quote_subst"`'
++old_striplib='`$ECHO "X$old_striplib" | $Xsed -e "$delay_single_quote_subst"`'
++striplib='`$ECHO "X$striplib" | $Xsed -e "$delay_single_quote_subst"`'
++
++LTCC='$LTCC'
++LTCFLAGS='$LTCFLAGS'
++compiler='$compiler_DEFAULT'
++
++# Quote evaled strings.
++for var in SED \
++GREP \
++EGREP \
++FGREP \
++LD \
++NM \
++LN_S \
++lt_SP2NL \
++lt_NL2SP \
++reload_flag \
++OBJDUMP \
++deplibs_check_method \
++file_magic_cmd \
++AR \
++AR_FLAGS \
++STRIP \
++RANLIB \
++CC \
++CFLAGS \
++compiler \
++lt_cv_sys_global_symbol_pipe \
++lt_cv_sys_global_symbol_to_cdecl \
++lt_cv_sys_global_symbol_to_c_name_address \
++lt_cv_sys_global_symbol_to_c_name_address_lib_prefix \
++SHELL \
++ECHO \
++lt_prog_compiler_no_builtin_flag \
++lt_prog_compiler_wl \
++lt_prog_compiler_pic \
++lt_prog_compiler_static \
++lt_cv_prog_compiler_c_o \
++need_locks \
++DSYMUTIL \
++NMEDIT \
++LIPO \
++OTOOL \
++OTOOL64 \
++shrext_cmds \
++export_dynamic_flag_spec \
++whole_archive_flag_spec \
++compiler_needs_object \
++with_gnu_ld \
++allow_undefined_flag \
++no_undefined_flag \
++hardcode_libdir_flag_spec \
++hardcode_libdir_flag_spec_ld \
++hardcode_libdir_separator \
++fix_srcfile_path \
++exclude_expsyms \
++include_expsyms \
++file_list_spec \
++variables_saved_for_relink \
++libname_spec \
++library_names_spec \
++soname_spec \
++finish_eval \
++old_striplib \
++striplib; do
++    case \`eval \\\\\$ECHO "X\\\\\$\$var"\` in
++    *[\\\\\\\`\\"\\\$]*)
++      eval "lt_\$var=\\\\\\"\\\`\\\$ECHO \\"X\\\$\$var\\" | \\\$Xsed -e \\"\\\$sed_quote_subst\\"\\\`\\\\\\""
++      ;;
++    *)
++      eval "lt_\$var=\\\\\\"\\\$\$var\\\\\\""
++      ;;
++    esac
++done
++
++# Double-quote double-evaled strings.
++for var in reload_cmds \
++old_postinstall_cmds \
++old_postuninstall_cmds \
++old_archive_cmds \
++extract_expsyms_cmds \
++old_archive_from_new_cmds \
++old_archive_from_expsyms_cmds \
++archive_cmds \
++archive_expsym_cmds \
++module_cmds \
++module_expsym_cmds \
++export_symbols_cmds \
++prelink_cmds \
++postinstall_cmds \
++postuninstall_cmds \
++finish_cmds \
++sys_lib_search_path_spec \
++sys_lib_dlsearch_path_spec; do
++    case \`eval \\\\\$ECHO "X\\\\\$\$var"\` in
++    *[\\\\\\\`\\"\\\$]*)
++      eval "lt_\$var=\\\\\\"\\\`\\\$ECHO \\"X\\\$\$var\\" | \\\$Xsed -e \\"\\\$double_quote_subst\\" -e \\"\\\$sed_quote_subst\\" -e \\"\\\$delay_variable_subst\\"\\\`\\\\\\""
++      ;;
++    *)
++      eval "lt_\$var=\\\\\\"\\\$\$var\\\\\\""
++      ;;
++    esac
++done
++
++# Fix-up fallback echo if it was mangled by the above quoting rules.
++case \$lt_ECHO in
++*'\\\$0 --fallback-echo"')  lt_ECHO=\`\$ECHO "X\$lt_ECHO" | \$Xsed -e 's/\\\\\\\\\\\\\\\$0 --fallback-echo"\$/\$0 --fallback-echo"/'\`
++  ;;
++esac
++
++ac_aux_dir='$ac_aux_dir'
++xsi_shell='$xsi_shell'
++lt_shell_append='$lt_shell_append'
++
++# See if we are running on zsh, and set the options which allow our
++# commands through without removal of \ escapes INIT.
++if test -n "\${ZSH_VERSION+set}" ; then
++   setopt NO_GLOB_SUBST
++fi
++
++
++    PACKAGE='$PACKAGE'
++    VERSION='$VERSION'
++    TIMESTAMP='$TIMESTAMP'
++    RM='$RM'
++    ofile='$ofile'
++
++
++
++
++_ACEOF
++
++cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
++
++# Handling of arguments.
++for ac_config_target in $ac_config_targets
++do
++  case $ac_config_target in
++    "include/config.h") CONFIG_HEADERS="$CONFIG_HEADERS include/config.h" ;;
++    "depfiles") CONFIG_COMMANDS="$CONFIG_COMMANDS depfiles" ;;
++    "libtool") CONFIG_COMMANDS="$CONFIG_COMMANDS libtool" ;;
++    "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
++    "etc/Makefile") CONFIG_FILES="$CONFIG_FILES etc/Makefile" ;;
++    "include/Makefile") CONFIG_FILES="$CONFIG_FILES include/Makefile" ;;
++    "include/gssapi/Makefile") CONFIG_FILES="$CONFIG_FILES include/gssapi/Makefile" ;;
++    "include/hcrypto/Makefile") CONFIG_FILES="$CONFIG_FILES include/hcrypto/Makefile" ;;
++    "include/kadm5/Makefile") CONFIG_FILES="$CONFIG_FILES include/kadm5/Makefile" ;;
++    "lib/Makefile") CONFIG_FILES="$CONFIG_FILES lib/Makefile" ;;
++    "base/Makefile") CONFIG_FILES="$CONFIG_FILES base/Makefile" ;;
++    "lib/asn1/Makefile") CONFIG_FILES="$CONFIG_FILES lib/asn1/Makefile" ;;
++    "lib/com_err/Makefile") CONFIG_FILES="$CONFIG_FILES lib/com_err/Makefile" ;;
++    "lib/hcrypto/Makefile") CONFIG_FILES="$CONFIG_FILES lib/hcrypto/Makefile" ;;
++    "lib/editline/Makefile") CONFIG_FILES="$CONFIG_FILES lib/editline/Makefile" ;;
++    "lib/hx509/Makefile") CONFIG_FILES="$CONFIG_FILES lib/hx509/Makefile" ;;
++    "lib/gssapi/Makefile") CONFIG_FILES="$CONFIG_FILES lib/gssapi/Makefile" ;;
++    "lib/ntlm/Makefile") CONFIG_FILES="$CONFIG_FILES lib/ntlm/Makefile" ;;
++    "lib/hdb/Makefile") CONFIG_FILES="$CONFIG_FILES lib/hdb/Makefile" ;;
++    "lib/ipc/Makefile") CONFIG_FILES="$CONFIG_FILES lib/ipc/Makefile" ;;
++    "lib/kadm5/Makefile") CONFIG_FILES="$CONFIG_FILES lib/kadm5/Makefile" ;;
++    "lib/kafs/Makefile") CONFIG_FILES="$CONFIG_FILES lib/kafs/Makefile" ;;
++    "lib/kdfs/Makefile") CONFIG_FILES="$CONFIG_FILES lib/kdfs/Makefile" ;;
++    "lib/krb5/Makefile") CONFIG_FILES="$CONFIG_FILES lib/krb5/Makefile" ;;
++    "lib/otp/Makefile") CONFIG_FILES="$CONFIG_FILES lib/otp/Makefile" ;;
++    "lib/roken/Makefile") CONFIG_FILES="$CONFIG_FILES lib/roken/Makefile" ;;
++    "lib/sl/Makefile") CONFIG_FILES="$CONFIG_FILES lib/sl/Makefile" ;;
++    "lib/sqlite/Makefile") CONFIG_FILES="$CONFIG_FILES lib/sqlite/Makefile" ;;
++    "lib/vers/Makefile") CONFIG_FILES="$CONFIG_FILES lib/vers/Makefile" ;;
++    "lib/wind/Makefile") CONFIG_FILES="$CONFIG_FILES lib/wind/Makefile" ;;
++    "po/Makefile") CONFIG_FILES="$CONFIG_FILES po/Makefile" ;;
++    "kuser/Makefile") CONFIG_FILES="$CONFIG_FILES kuser/Makefile" ;;
++    "kpasswd/Makefile") CONFIG_FILES="$CONFIG_FILES kpasswd/Makefile" ;;
++    "kadmin/Makefile") CONFIG_FILES="$CONFIG_FILES kadmin/Makefile" ;;
++    "admin/Makefile") CONFIG_FILES="$CONFIG_FILES admin/Makefile" ;;
++    "kcm/Makefile") CONFIG_FILES="$CONFIG_FILES kcm/Makefile" ;;
++    "kdc/Makefile") CONFIG_FILES="$CONFIG_FILES kdc/Makefile" ;;
++    "appl/Makefile") CONFIG_FILES="$CONFIG_FILES appl/Makefile" ;;
++    "appl/afsutil/Makefile") CONFIG_FILES="$CONFIG_FILES appl/afsutil/Makefile" ;;
++    "appl/ftp/Makefile") CONFIG_FILES="$CONFIG_FILES appl/ftp/Makefile" ;;
++    "appl/ftp/common/Makefile") CONFIG_FILES="$CONFIG_FILES appl/ftp/common/Makefile" ;;
++    "appl/ftp/ftp/Makefile") CONFIG_FILES="$CONFIG_FILES appl/ftp/ftp/Makefile" ;;
++    "appl/ftp/ftpd/Makefile") CONFIG_FILES="$CONFIG_FILES appl/ftp/ftpd/Makefile" ;;
++    "appl/gssmask/Makefile") CONFIG_FILES="$CONFIG_FILES appl/gssmask/Makefile" ;;
++    "appl/kx/Makefile") CONFIG_FILES="$CONFIG_FILES appl/kx/Makefile" ;;
++    "appl/login/Makefile") CONFIG_FILES="$CONFIG_FILES appl/login/Makefile" ;;
++    "appl/otp/Makefile") CONFIG_FILES="$CONFIG_FILES appl/otp/Makefile" ;;
++    "appl/popper/Makefile") CONFIG_FILES="$CONFIG_FILES appl/popper/Makefile" ;;
++    "appl/push/Makefile") CONFIG_FILES="$CONFIG_FILES appl/push/Makefile" ;;
++    "appl/rsh/Makefile") CONFIG_FILES="$CONFIG_FILES appl/rsh/Makefile" ;;
++    "appl/rcp/Makefile") CONFIG_FILES="$CONFIG_FILES appl/rcp/Makefile" ;;
++    "appl/su/Makefile") CONFIG_FILES="$CONFIG_FILES appl/su/Makefile" ;;
++    "appl/xnlock/Makefile") CONFIG_FILES="$CONFIG_FILES appl/xnlock/Makefile" ;;
++    "appl/telnet/Makefile") CONFIG_FILES="$CONFIG_FILES appl/telnet/Makefile" ;;
++    "appl/telnet/libtelnet/Makefile") CONFIG_FILES="$CONFIG_FILES appl/telnet/libtelnet/Makefile" ;;
++    "appl/telnet/telnet/Makefile") CONFIG_FILES="$CONFIG_FILES appl/telnet/telnet/Makefile" ;;
++    "appl/telnet/telnetd/Makefile") CONFIG_FILES="$CONFIG_FILES appl/telnet/telnetd/Makefile" ;;
++    "appl/test/Makefile") CONFIG_FILES="$CONFIG_FILES appl/test/Makefile" ;;
++    "appl/kf/Makefile") CONFIG_FILES="$CONFIG_FILES appl/kf/Makefile" ;;
++    "appl/dceutils/Makefile") CONFIG_FILES="$CONFIG_FILES appl/dceutils/Makefile" ;;
++    "tests/Makefile") CONFIG_FILES="$CONFIG_FILES tests/Makefile" ;;
++    "tests/bin/Makefile") CONFIG_FILES="$CONFIG_FILES tests/bin/Makefile" ;;
++    "tests/can/Makefile") CONFIG_FILES="$CONFIG_FILES tests/can/Makefile" ;;
++    "tests/db/Makefile") CONFIG_FILES="$CONFIG_FILES tests/db/Makefile" ;;
++    "tests/kdc/Makefile") CONFIG_FILES="$CONFIG_FILES tests/kdc/Makefile" ;;
++    "tests/ldap/Makefile") CONFIG_FILES="$CONFIG_FILES tests/ldap/Makefile" ;;
++    "tests/gss/Makefile") CONFIG_FILES="$CONFIG_FILES tests/gss/Makefile" ;;
++    "tests/java/Makefile") CONFIG_FILES="$CONFIG_FILES tests/java/Makefile" ;;
++    "tests/plugin/Makefile") CONFIG_FILES="$CONFIG_FILES tests/plugin/Makefile" ;;
++    "packages/Makefile") CONFIG_FILES="$CONFIG_FILES packages/Makefile" ;;
++    "packages/mac/Makefile") CONFIG_FILES="$CONFIG_FILES packages/mac/Makefile" ;;
++    "doc/Makefile") CONFIG_FILES="$CONFIG_FILES doc/Makefile" ;;
++    "tools/Makefile") CONFIG_FILES="$CONFIG_FILES tools/Makefile" ;;
++
++  *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5 ;;
++  esac
++done
++
++
++# If the user did not use the arguments to specify the items to instantiate,
++# then the envvar interface is used.  Set only those that are not.
++# We use the long form for the default assignment because of an extremely
++# bizarre bug on SunOS 4.1.3.
++if $ac_need_defaults; then
++  test "${CONFIG_FILES+set}" = set || CONFIG_FILES=$config_files
++  test "${CONFIG_HEADERS+set}" = set || CONFIG_HEADERS=$config_headers
++  test "${CONFIG_COMMANDS+set}" = set || CONFIG_COMMANDS=$config_commands
++fi
++
++# Have a temporary directory for convenience.  Make it in the build tree
++# simply because there is no reason against having it here, and in addition,
++# creating and moving files from /tmp can sometimes cause problems.
++# Hook for its removal unless debugging.
++# Note that there is a small window in which the directory will not be cleaned:
++# after its creation but before its name has been assigned to `$tmp'.
++$debug ||
++{
++  tmp=
++  trap 'exit_status=$?
++  { test -z "$tmp" || test ! -d "$tmp" || rm -fr "$tmp"; } && exit $exit_status
++' 0
++  trap 'as_fn_exit 1' 1 2 13 15
++}
++# Create a (secure) tmp directory for tmp files.
++
++{
++  tmp=`(umask 077 && mktemp -d "./confXXXXXX") 2>/dev/null` &&
++  test -n "$tmp" && test -d "$tmp"
++}  ||
++{
++  tmp=./conf$$-$RANDOM
++  (umask 077 && mkdir "$tmp")
++} || as_fn_error $? "cannot create a temporary directory in ." "$LINENO" 5
++
++# Set up the scripts for CONFIG_FILES section.
++# No need to generate them if there are no CONFIG_FILES.
++# This happens for instance with `./config.status config.h'.
++if test -n "$CONFIG_FILES"; then
++
++
++ac_cr=`echo X | tr X '\015'`
++# On cygwin, bash can eat \r inside `` if the user requested igncr.
++# But we know of no other shell where ac_cr would be empty at this
++# point, so we can use a bashism as a fallback.
++if test "x$ac_cr" = x; then
++  eval ac_cr=\$\'\\r\'
++fi
++ac_cs_awk_cr=`$AWK 'BEGIN { print "a\rb" }' </dev/null 2>/dev/null`
++if test "$ac_cs_awk_cr" = "a${ac_cr}b"; then
++  ac_cs_awk_cr='\\r'
++else
++  ac_cs_awk_cr=$ac_cr
++fi
++
++echo 'BEGIN {' >"$tmp/subs1.awk" &&
++_ACEOF
++
++
++{
++  echo "cat >conf$$subs.awk <<_ACEOF" &&
++  echo "$ac_subst_vars" | sed 's/.*/&!$&$ac_delim/' &&
++  echo "_ACEOF"
++} >conf$$subs.sh ||
++  as_fn_error $? "could not make $CONFIG_STATUS" "$LINENO" 5
++ac_delim_num=`echo "$ac_subst_vars" | grep -c '^'`
++ac_delim='%!_!# '
++for ac_last_try in false false false false false :; do
++  . ./conf$$subs.sh ||
++    as_fn_error $? "could not make $CONFIG_STATUS" "$LINENO" 5
++
++  ac_delim_n=`sed -n "s/.*$ac_delim\$/X/p" conf$$subs.awk | grep -c X`
++  if test $ac_delim_n = $ac_delim_num; then
++    break
++  elif $ac_last_try; then
++    as_fn_error $? "could not make $CONFIG_STATUS" "$LINENO" 5
++  else
++    ac_delim="$ac_delim!$ac_delim _$ac_delim!! "
++  fi
++done
++rm -f conf$$subs.sh
++
++cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
++cat >>"\$tmp/subs1.awk" <<\\_ACAWK &&
++_ACEOF
++sed -n '
++h
++s/^/S["/; s/!.*/"]=/
++p
++g
++s/^[^!]*!//
++:repl
++t repl
++s/'"$ac_delim"'$//
++t delim
++:nl
++h
++s/\(.\{148\}\)..*/\1/
++t more1
++s/["\\]/\\&/g; s/^/"/; s/$/\\n"\\/
++p
++n
++b repl
++:more1
++s/["\\]/\\&/g; s/^/"/; s/$/"\\/
++p
++g
++s/.\{148\}//
++t nl
++:delim
++h
++s/\(.\{148\}\)..*/\1/
++t more2
++s/["\\]/\\&/g; s/^/"/; s/$/"/
++p
++b
++:more2
++s/["\\]/\\&/g; s/^/"/; s/$/"\\/
++p
++g
++s/.\{148\}//
++t delim
++' <conf$$subs.awk | sed '
++/^[^""]/{
++  N
++  s/\n//
++}
++' >>$CONFIG_STATUS || ac_write_fail=1
++rm -f conf$$subs.awk
++cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
++_ACAWK
++cat >>"\$tmp/subs1.awk" <<_ACAWK &&
++  for (key in S) S_is_set[key] = 1
++  FS = ""
++
++}
++{
++  line = $ 0
++  nfields = split(line, field, "@")
++  substed = 0
++  len = length(field[1])
++  for (i = 2; i < nfields; i++) {
++    key = field[i]
++    keylen = length(key)
++    if (S_is_set[key]) {
++      value = S[key]
++      line = substr(line, 1, len) "" value "" substr(line, len + keylen + 3)
++      len += length(value) + length(field[++i])
++      substed = 1
++    } else
++      len += 1 + keylen
++  }
++
++  print line
++}
++
++_ACAWK
++_ACEOF
++cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
++if sed "s/$ac_cr//" < /dev/null > /dev/null 2>&1; then
++  sed "s/$ac_cr\$//; s/$ac_cr/$ac_cs_awk_cr/g"
++else
++  cat
++fi < "$tmp/subs1.awk" > "$tmp/subs.awk" \
++  || as_fn_error $? "could not setup config files machinery" "$LINENO" 5
++_ACEOF
++
++# VPATH may cause trouble with some makes, so we remove sole $(srcdir),
++# ${srcdir} and @srcdir@ entries from VPATH if srcdir is ".", strip leading and
++# trailing colons and then remove the whole line if VPATH becomes empty
++# (actually we leave an empty line to preserve line numbers).
++if test "x$srcdir" = x.; then
++  ac_vpsub='/^[	 ]*VPATH[	 ]*=[	 ]*/{
++h
++s///
++s/^/:/
++s/[	 ]*$/:/
++s/:\$(srcdir):/:/g
++s/:\${srcdir}:/:/g
++s/:@srcdir@:/:/g
++s/^:*//
++s/:*$//
++x
++s/\(=[	 ]*\).*/\1/
++G
++s/\n//
++s/^[^=]*=[	 ]*$//
++}'
++fi
++
++cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
++fi # test -n "$CONFIG_FILES"
++
++# Set up the scripts for CONFIG_HEADERS section.
++# No need to generate them if there are no CONFIG_HEADERS.
++# This happens for instance with `./config.status Makefile'.
++if test -n "$CONFIG_HEADERS"; then
++cat >"$tmp/defines.awk" <<\_ACAWK ||
++BEGIN {
++_ACEOF
++
++# Transform confdefs.h into an awk script `defines.awk', embedded as
++# here-document in config.status, that substitutes the proper values into
++# config.h.in to produce config.h.
++
++# Create a delimiter string that does not exist in confdefs.h, to ease
++# handling of long lines.
++ac_delim='%!_!# '
++for ac_last_try in false false :; do
++  ac_t=`sed -n "/$ac_delim/p" confdefs.h`
++  if test -z "$ac_t"; then
++    break
++  elif $ac_last_try; then
++    as_fn_error $? "could not make $CONFIG_HEADERS" "$LINENO" 5
++  else
++    ac_delim="$ac_delim!$ac_delim _$ac_delim!! "
++  fi
++done
++
++# For the awk script, D is an array of macro values keyed by name,
++# likewise P contains macro parameters if any.  Preserve backslash
++# newline sequences.
++
++ac_word_re=[_$as_cr_Letters][_$as_cr_alnum]*
++sed -n '
++s/.\{148\}/&'"$ac_delim"'/g
++t rset
++:rset
++s/^[	 ]*#[	 ]*define[	 ][	 ]*/ /
++t def
++d
++:def
++s/\\$//
++t bsnl
++s/["\\]/\\&/g
++s/^ \('"$ac_word_re"'\)\(([^()]*)\)[	 ]*\(.*\)/P["\1"]="\2"\
++D["\1"]=" \3"/p
++s/^ \('"$ac_word_re"'\)[	 ]*\(.*\)/D["\1"]=" \2"/p
++d
++:bsnl
++s/["\\]/\\&/g
++s/^ \('"$ac_word_re"'\)\(([^()]*)\)[	 ]*\(.*\)/P["\1"]="\2"\
++D["\1"]=" \3\\\\\\n"\\/p
++t cont
++s/^ \('"$ac_word_re"'\)[	 ]*\(.*\)/D["\1"]=" \2\\\\\\n"\\/p
++t cont
++d
++:cont
++n
++s/.\{148\}/&'"$ac_delim"'/g
++t clear
++:clear
++s/\\$//
++t bsnlc
++s/["\\]/\\&/g; s/^/"/; s/$/"/p
++d
++:bsnlc
++s/["\\]/\\&/g; s/^/"/; s/$/\\\\\\n"\\/p
++b cont
++' <confdefs.h | sed '
++s/'"$ac_delim"'/"\\\
++"/g' >>$CONFIG_STATUS || ac_write_fail=1
++
++cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
++  for (key in D) D_is_set[key] = 1
++  FS = ""
++}
++/^[\t ]*#[\t ]*(define|undef)[\t ]+$ac_word_re([\t (]|\$)/ {
++  line = \$ 0
++  split(line, arg, " ")
++  if (arg[1] == "#") {
++    defundef = arg[2]
++    mac1 = arg[3]
++  } else {
++    defundef = substr(arg[1], 2)
++    mac1 = arg[2]
++  }
++  split(mac1, mac2, "(") #)
++  macro = mac2[1]
++  prefix = substr(line, 1, index(line, defundef) - 1)
++  if (D_is_set[macro]) {
++    # Preserve the white space surrounding the "#".
++    print prefix "define", macro P[macro] D[macro]
++    next
++  } else {
++    # Replace #undef with comments.  This is necessary, for example,
++    # in the case of _POSIX_SOURCE, which is predefined and required
++    # on some systems where configure will not decide to define it.
++    if (defundef == "undef") {
++      print "/*", prefix defundef, macro, "*/"
++      next
++    }
++  }
++}
++{ print }
++_ACAWK
++_ACEOF
++cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
++  as_fn_error $? "could not setup config headers machinery" "$LINENO" 5
++fi # test -n "$CONFIG_HEADERS"
++
++
++eval set X "  :F $CONFIG_FILES  :H $CONFIG_HEADERS    :C $CONFIG_COMMANDS"
++shift
++for ac_tag
++do
++  case $ac_tag in
++  :[FHLC]) ac_mode=$ac_tag; continue;;
++  esac
++  case $ac_mode$ac_tag in
++  :[FHL]*:*);;
++  :L* | :C*:*) as_fn_error $? "invalid tag \`$ac_tag'" "$LINENO" 5 ;;
++  :[FH]-) ac_tag=-:-;;
++  :[FH]*) ac_tag=$ac_tag:$ac_tag.in;;
++  esac
++  ac_save_IFS=$IFS
++  IFS=:
++  set x $ac_tag
++  IFS=$ac_save_IFS
++  shift
++  ac_file=$1
++  shift
++
++  case $ac_mode in
++  :L) ac_source=$1;;
++  :[FH])
++    ac_file_inputs=
++    for ac_f
++    do
++      case $ac_f in
++      -) ac_f="$tmp/stdin";;
++      *) # Look for the file first in the build tree, then in the source tree
++	 # (if the path is not absolute).  The absolute path cannot be DOS-style,
++	 # because $ac_f cannot contain `:'.
++	 test -f "$ac_f" ||
++	   case $ac_f in
++	   [\\/$]*) false;;
++	   *) test -f "$srcdir/$ac_f" && ac_f="$srcdir/$ac_f";;
++	   esac ||
++	   as_fn_error 1 "cannot find input file: \`$ac_f'" "$LINENO" 5 ;;
++      esac
++      case $ac_f in *\'*) ac_f=`$as_echo "$ac_f" | sed "s/'/'\\\\\\\\''/g"`;; esac
++      as_fn_append ac_file_inputs " '$ac_f'"
++    done
++
++    # Let's still pretend it is `configure' which instantiates (i.e., don't
++    # use $as_me), people would be surprised to read:
++    #    /* config.h.  Generated by config.status.  */
++    configure_input='Generated from '`
++	  $as_echo "$*" | sed 's|^[^:]*/||;s|:[^:]*/|, |g'
++	`' by configure.'
++    if test x"$ac_file" != x-; then
++      configure_input="$ac_file.  $configure_input"
++      { $as_echo "$as_me:${as_lineno-$LINENO}: creating $ac_file" >&5
++$as_echo "$as_me: creating $ac_file" >&6;}
++    fi
++    # Neutralize special characters interpreted by sed in replacement strings.
++    case $configure_input in #(
++    *\&* | *\|* | *\\* )
++       ac_sed_conf_input=`$as_echo "$configure_input" |
++       sed 's/[\\\\&|]/\\\\&/g'`;; #(
++    *) ac_sed_conf_input=$configure_input;;
++    esac
++
++    case $ac_tag in
++    *:-:* | *:-) cat >"$tmp/stdin" \
++      || as_fn_error $? "could not create $ac_file" "$LINENO" 5  ;;
++    esac
++    ;;
++  esac
++
++  ac_dir=`$as_dirname -- "$ac_file" ||
++$as_expr X"$ac_file" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
++	 X"$ac_file" : 'X\(//\)[^/]' \| \
++	 X"$ac_file" : 'X\(//\)$' \| \
++	 X"$ac_file" : 'X\(/\)' \| . 2>/dev/null ||
++$as_echo X"$ac_file" |
++    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\/\)[^/].*/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\/\)$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\).*/{
++	    s//\1/
++	    q
++	  }
++	  s/.*/./; q'`
++  as_dir="$ac_dir"; as_fn_mkdir_p
++  ac_builddir=.
++
++case "$ac_dir" in
++.) ac_dir_suffix= ac_top_builddir_sub=. ac_top_build_prefix= ;;
++*)
++  ac_dir_suffix=/`$as_echo "$ac_dir" | sed 's|^\.[\\/]||'`
++  # A ".." for each directory in $ac_dir_suffix.
++  ac_top_builddir_sub=`$as_echo "$ac_dir_suffix" | sed 's|/[^\\/]*|/..|g;s|/||'`
++  case $ac_top_builddir_sub in
++  "") ac_top_builddir_sub=. ac_top_build_prefix= ;;
++  *)  ac_top_build_prefix=$ac_top_builddir_sub/ ;;
++  esac ;;
++esac
++ac_abs_top_builddir=$ac_pwd
++ac_abs_builddir=$ac_pwd$ac_dir_suffix
++# for backward compatibility:
++ac_top_builddir=$ac_top_build_prefix
++
++case $srcdir in
++  .)  # We are building in place.
++    ac_srcdir=.
++    ac_top_srcdir=$ac_top_builddir_sub
++    ac_abs_top_srcdir=$ac_pwd ;;
++  [\\/]* | ?:[\\/]* )  # Absolute name.
++    ac_srcdir=$srcdir$ac_dir_suffix;
++    ac_top_srcdir=$srcdir
++    ac_abs_top_srcdir=$srcdir ;;
++  *) # Relative name.
++    ac_srcdir=$ac_top_build_prefix$srcdir$ac_dir_suffix
++    ac_top_srcdir=$ac_top_build_prefix$srcdir
++    ac_abs_top_srcdir=$ac_pwd/$srcdir ;;
++esac
++ac_abs_srcdir=$ac_abs_top_srcdir$ac_dir_suffix
++
++
++  case $ac_mode in
++  :F)
++  #
++  # CONFIG_FILE
++  #
++
++  case $INSTALL in
++  [\\/$]* | ?:[\\/]* ) ac_INSTALL=$INSTALL ;;
++  *) ac_INSTALL=$ac_top_build_prefix$INSTALL ;;
++  esac
++  ac_MKDIR_P=$MKDIR_P
++  case $MKDIR_P in
++  [\\/$]* | ?:[\\/]* ) ;;
++  */*) ac_MKDIR_P=$ac_top_build_prefix$MKDIR_P ;;
++  esac
++_ACEOF
++
++cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
++# If the template does not know about datarootdir, expand it.
++# FIXME: This hack should be removed a few years after 2.60.
++ac_datarootdir_hack=; ac_datarootdir_seen=
++ac_sed_dataroot='
++/datarootdir/ {
++  p
++  q
++}
++/@datadir@/p
++/@docdir@/p
++/@infodir@/p
++/@localedir@/p
++/@mandir@/p'
++case `eval "sed -n \"\$ac_sed_dataroot\" $ac_file_inputs"` in
++*datarootdir*) ac_datarootdir_seen=yes;;
++*@datadir@*|*@docdir@*|*@infodir@*|*@localedir@*|*@mandir@*)
++  { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $ac_file_inputs seems to ignore the --datarootdir setting" >&5
++$as_echo "$as_me: WARNING: $ac_file_inputs seems to ignore the --datarootdir setting" >&2;}
++_ACEOF
++cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
++  ac_datarootdir_hack='
++  s&@datadir@&$datadir&g
++  s&@docdir@&$docdir&g
++  s&@infodir@&$infodir&g
++  s&@localedir@&$localedir&g
++  s&@mandir@&$mandir&g
++  s&\\\${datarootdir}&$datarootdir&g' ;;
++esac
++_ACEOF
++
++# Neutralize VPATH when `$srcdir' = `.'.
++# Shell code in configure.ac might set extrasub.
++# FIXME: do we really want to maintain this feature?
++cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
++ac_sed_extra="$ac_vpsub
++$extrasub
++_ACEOF
++cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
++:t
++/@[a-zA-Z_][a-zA-Z_0-9]*@/!b
++s|@configure_input@|$ac_sed_conf_input|;t t
++s&@top_builddir@&$ac_top_builddir_sub&;t t
++s&@top_build_prefix@&$ac_top_build_prefix&;t t
++s&@srcdir@&$ac_srcdir&;t t
++s&@abs_srcdir@&$ac_abs_srcdir&;t t
++s&@top_srcdir@&$ac_top_srcdir&;t t
++s&@abs_top_srcdir@&$ac_abs_top_srcdir&;t t
++s&@builddir@&$ac_builddir&;t t
++s&@abs_builddir@&$ac_abs_builddir&;t t
++s&@abs_top_builddir@&$ac_abs_top_builddir&;t t
++s&@INSTALL@&$ac_INSTALL&;t t
++s&@MKDIR_P@&$ac_MKDIR_P&;t t
++$ac_datarootdir_hack
++"
++eval sed \"\$ac_sed_extra\" "$ac_file_inputs" | $AWK -f "$tmp/subs.awk" >$tmp/out \
++  || as_fn_error $? "could not create $ac_file" "$LINENO" 5
++
++test -z "$ac_datarootdir_hack$ac_datarootdir_seen" &&
++  { ac_out=`sed -n '/\${datarootdir}/p' "$tmp/out"`; test -n "$ac_out"; } &&
++  { ac_out=`sed -n '/^[	 ]*datarootdir[	 ]*:*=/p' "$tmp/out"`; test -z "$ac_out"; } &&
++  { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $ac_file contains a reference to the variable \`datarootdir'
++which seems to be undefined.  Please make sure it is defined" >&5
++$as_echo "$as_me: WARNING: $ac_file contains a reference to the variable \`datarootdir'
++which seems to be undefined.  Please make sure it is defined" >&2;}
++
++  rm -f "$tmp/stdin"
++  case $ac_file in
++  -) cat "$tmp/out" && rm -f "$tmp/out";;
++  *) rm -f "$ac_file" && mv "$tmp/out" "$ac_file";;
++  esac \
++  || as_fn_error $? "could not create $ac_file" "$LINENO" 5
++ ;;
++  :H)
++  #
++  # CONFIG_HEADER
++  #
++  if test x"$ac_file" != x-; then
++    {
++      $as_echo "/* $configure_input  */" \
++      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs"
++    } >"$tmp/config.h" \
++      || as_fn_error $? "could not create $ac_file" "$LINENO" 5
++    if diff "$ac_file" "$tmp/config.h" >/dev/null 2>&1; then
++      { $as_echo "$as_me:${as_lineno-$LINENO}: $ac_file is unchanged" >&5
++$as_echo "$as_me: $ac_file is unchanged" >&6;}
++    else
++      rm -f "$ac_file"
++      mv "$tmp/config.h" "$ac_file" \
++	|| as_fn_error $? "could not create $ac_file" "$LINENO" 5
++    fi
++  else
++    $as_echo "/* $configure_input  */" \
++      && eval '$AWK -f "$tmp/defines.awk"' "$ac_file_inputs" \
++      || as_fn_error $? "could not create -" "$LINENO" 5
++  fi
++# Compute "$ac_file"'s index in $config_headers.
++_am_arg="$ac_file"
++_am_stamp_count=1
++for _am_header in $config_headers :; do
++  case $_am_header in
++    $_am_arg | $_am_arg:* )
++      break ;;
++    * )
++      _am_stamp_count=`expr $_am_stamp_count + 1` ;;
++  esac
++done
++echo "timestamp for $_am_arg" >`$as_dirname -- "$_am_arg" ||
++$as_expr X"$_am_arg" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
++	 X"$_am_arg" : 'X\(//\)[^/]' \| \
++	 X"$_am_arg" : 'X\(//\)$' \| \
++	 X"$_am_arg" : 'X\(/\)' \| . 2>/dev/null ||
++$as_echo X"$_am_arg" |
++    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\/\)[^/].*/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\/\)$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\).*/{
++	    s//\1/
++	    q
++	  }
++	  s/.*/./; q'`/stamp-h$_am_stamp_count
++ ;;
++
++  :C)  { $as_echo "$as_me:${as_lineno-$LINENO}: executing $ac_file commands" >&5
++$as_echo "$as_me: executing $ac_file commands" >&6;}
++ ;;
++  esac
++
++
++  case $ac_file$ac_mode in
++    "depfiles":C) test x"$AMDEP_TRUE" != x"" || {
++  # Autoconf 2.62 quotes --file arguments for eval, but not when files
++  # are listed without --file.  Let's play safe and only enable the eval
++  # if we detect the quoting.
++  case $CONFIG_FILES in
++  *\'*) eval set x "$CONFIG_FILES" ;;
++  *)   set x $CONFIG_FILES ;;
++  esac
++  shift
++  for mf
++  do
++    # Strip MF so we end up with the name of the file.
++    mf=`echo "$mf" | sed -e 's/:.*$//'`
++    # Check whether this is an Automake generated Makefile or not.
++    # We used to match only the files named `Makefile.in', but
++    # some people rename them; so instead we look at the file content.
++    # Grep'ing the first line is not enough: some people post-process
++    # each Makefile.in and add a new line on top of each file to say so.
++    # Grep'ing the whole file is not good either: AIX grep has a line
++    # limit of 2048, but all sed's we know have understand at least 4000.
++    if sed -n 's,^#.*generated by automake.*,X,p' "$mf" | grep X >/dev/null 2>&1; then
++      dirpart=`$as_dirname -- "$mf" ||
++$as_expr X"$mf" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
++	 X"$mf" : 'X\(//\)[^/]' \| \
++	 X"$mf" : 'X\(//\)$' \| \
++	 X"$mf" : 'X\(/\)' \| . 2>/dev/null ||
++$as_echo X"$mf" |
++    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\/\)[^/].*/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\/\)$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\).*/{
++	    s//\1/
++	    q
++	  }
++	  s/.*/./; q'`
++    else
++      continue
++    fi
++    # Extract the definition of DEPDIR, am__include, and am__quote
++    # from the Makefile without running `make'.
++    DEPDIR=`sed -n 's/^DEPDIR = //p' < "$mf"`
++    test -z "$DEPDIR" && continue
++    am__include=`sed -n 's/^am__include = //p' < "$mf"`
++    test -z "am__include" && continue
++    am__quote=`sed -n 's/^am__quote = //p' < "$mf"`
++    # When using ansi2knr, U may be empty or an underscore; expand it
++    U=`sed -n 's/^U = //p' < "$mf"`
++    # Find all dependency output files, they are included files with
++    # $(DEPDIR) in their names.  We invoke sed twice because it is the
++    # simplest approach to changing $(DEPDIR) to its actual value in the
++    # expansion.
++    for file in `sed -n "
++      s/^$am__include $am__quote\(.*(DEPDIR).*\)$am__quote"'$/\1/p' <"$mf" | \
++	 sed -e 's/\$(DEPDIR)/'"$DEPDIR"'/g' -e 's/\$U/'"$U"'/g'`; do
++      # Make sure the directory exists.
++      test -f "$dirpart/$file" && continue
++      fdir=`$as_dirname -- "$file" ||
++$as_expr X"$file" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
++	 X"$file" : 'X\(//\)[^/]' \| \
++	 X"$file" : 'X\(//\)$' \| \
++	 X"$file" : 'X\(/\)' \| . 2>/dev/null ||
++$as_echo X"$file" |
++    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\/\)[^/].*/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\/\)$/{
++	    s//\1/
++	    q
++	  }
++	  /^X\(\/\).*/{
++	    s//\1/
++	    q
++	  }
++	  s/.*/./; q'`
++      as_dir=$dirpart/$fdir; as_fn_mkdir_p
++      # echo "creating $dirpart/$file"
++      echo '# dummy' > "$dirpart/$file"
++    done
++  done
++}
++ ;;
++    "libtool":C)
++
++    # See if we are running on zsh, and set the options which allow our
++    # commands through without removal of \ escapes.
++    if test -n "${ZSH_VERSION+set}" ; then
++      setopt NO_GLOB_SUBST
++    fi
++
++    cfgfile="${ofile}T"
++    trap "$RM \"$cfgfile\"; exit 1" 1 2 15
++    $RM "$cfgfile"
++
++    cat <<_LT_EOF >> "$cfgfile"
++#! $SHELL
++
++# `$ECHO "$ofile" | sed 's%^.*/%%'` - Provide generalized library-building support services.
++# Generated automatically by $as_me ($PACKAGE$TIMESTAMP) $VERSION
++# Libtool was configured on host `(hostname || uname -n) 2>/dev/null | sed 1q`:
++# NOTE: Changes made to this file will be lost: look at ltmain.sh.
++#
++#   Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
++#                 2006, 2007, 2008 Free Software Foundation, Inc.
++#   Written by Gordon Matzigkeit, 1996
++#
++#   This file is part of GNU Libtool.
++#
++# GNU Libtool is free software; you can redistribute it and/or
++# modify it under the terms of the GNU General Public License as
++# published by the Free Software Foundation; either version 2 of
++# the License, or (at your option) any later version.
++#
++# As a special exception to the GNU General Public License,
++# if you distribute this file as part of a program or library that
++# is built using GNU Libtool, you may include this file under the
++# same distribution terms that you use for the rest of that program.
++#
++# GNU Libtool is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY; without even the implied warranty of
++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++# GNU General Public License for more details.
++#
++# You should have received a copy of the GNU General Public License
++# along with GNU Libtool; see the file COPYING.  If not, a copy
++# can be downloaded from http://www.gnu.org/licenses/gpl.html, or
++# obtained by writing to the Free Software Foundation, Inc.,
++# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
++
++
++# The names of the tagged configurations supported by this script.
++available_tags=""
++
++# ### BEGIN LIBTOOL CONFIG
++
++# Which release of libtool.m4 was used?
++macro_version=$macro_version
++macro_revision=$macro_revision
++
++# Whether or not to build shared libraries.
++build_libtool_libs=$enable_shared
++
++# Whether or not to build static libraries.
++build_old_libs=$enable_static
++
++# What type of objects to build.
++pic_mode=$pic_mode
++
++# Whether or not to optimize for fast installation.
++fast_install=$enable_fast_install
++
++# The host system.
++host_alias=$host_alias
++host=$host
++host_os=$host_os
++
++# The build system.
++build_alias=$build_alias
++build=$build
++build_os=$build_os
++
++# A sed program that does not truncate output.
++SED=$lt_SED
++
++# Sed that helps us avoid accidentally triggering echo(1) options like -n.
++Xsed="\$SED -e 1s/^X//"
++
++# A grep program that handles long lines.
++GREP=$lt_GREP
++
++# An ERE matcher.
++EGREP=$lt_EGREP
++
++# A literal string matcher.
++FGREP=$lt_FGREP
++
++# A BSD- or MS-compatible name lister.
++NM=$lt_NM
++
++# Whether we need soft or hard links.
++LN_S=$lt_LN_S
++
++# What is the maximum length of a command?
++max_cmd_len=$max_cmd_len
++
++# Object file suffix (normally "o").
++objext=$ac_objext
++
++# Executable file suffix (normally "").
++exeext=$exeext
++
++# whether the shell understands "unset".
++lt_unset=$lt_unset
++
++# turn spaces into newlines.
++SP2NL=$lt_lt_SP2NL
++
++# turn newlines into spaces.
++NL2SP=$lt_lt_NL2SP
++
++# How to create reloadable object files.
++reload_flag=$lt_reload_flag
++reload_cmds=$lt_reload_cmds
++
++# An object symbol dumper.
++OBJDUMP=$lt_OBJDUMP
++
++# Method to check whether dependent libraries are shared objects.
++deplibs_check_method=$lt_deplibs_check_method
++
++# Command to use when deplibs_check_method == "file_magic".
++file_magic_cmd=$lt_file_magic_cmd
++
++# The archiver.
++AR=$lt_AR
++AR_FLAGS=$lt_AR_FLAGS
++
++# A symbol stripping program.
++STRIP=$lt_STRIP
++
++# Commands used to install an old-style archive.
++RANLIB=$lt_RANLIB
++old_postinstall_cmds=$lt_old_postinstall_cmds
++old_postuninstall_cmds=$lt_old_postuninstall_cmds
++
++# A C compiler.
++LTCC=$lt_CC
++
++# LTCC compiler flags.
++LTCFLAGS=$lt_CFLAGS
++
++# Take the output of nm and produce a listing of raw symbols and C names.
++global_symbol_pipe=$lt_lt_cv_sys_global_symbol_pipe
++
++# Transform the output of nm in a proper C declaration.
++global_symbol_to_cdecl=$lt_lt_cv_sys_global_symbol_to_cdecl
++
++# Transform the output of nm in a C name address pair.
++global_symbol_to_c_name_address=$lt_lt_cv_sys_global_symbol_to_c_name_address
++
++# Transform the output of nm in a C name address pair when lib prefix is needed.
++global_symbol_to_c_name_address_lib_prefix=$lt_lt_cv_sys_global_symbol_to_c_name_address_lib_prefix
++
++# The name of the directory that contains temporary libtool files.
++objdir=$objdir
++
++# Shell to use when invoking shell scripts.
++SHELL=$lt_SHELL
++
++# An echo program that does not interpret backslashes.
++ECHO=$lt_ECHO
++
++# Used to examine libraries when file_magic_cmd begins with "file".
++MAGIC_CMD=$MAGIC_CMD
++
++# Must we lock files when doing compilation?
++need_locks=$lt_need_locks
++
++# Tool to manipulate archived DWARF debug symbol files on Mac OS X.
++DSYMUTIL=$lt_DSYMUTIL
++
++# Tool to change global to local symbols on Mac OS X.
++NMEDIT=$lt_NMEDIT
++
++# Tool to manipulate fat objects and archives on Mac OS X.
++LIPO=$lt_LIPO
++
++# ldd/readelf like tool for Mach-O binaries on Mac OS X.
++OTOOL=$lt_OTOOL
++
++# ldd/readelf like tool for 64 bit Mach-O binaries on Mac OS X 10.4.
++OTOOL64=$lt_OTOOL64
++
++# Old archive suffix (normally "a").
++libext=$libext
++
++# Shared library suffix (normally ".so").
++shrext_cmds=$lt_shrext_cmds
++
++# The commands to extract the exported symbol list from a shared archive.
++extract_expsyms_cmds=$lt_extract_expsyms_cmds
++
++# Variables whose values should be saved in libtool wrapper scripts and
++# restored at link time.
++variables_saved_for_relink=$lt_variables_saved_for_relink
++
++# Do we need the "lib" prefix for modules?
++need_lib_prefix=$need_lib_prefix
++
++# Do we need a version for libraries?
++need_version=$need_version
++
++# Library versioning type.
++version_type=$version_type
++
++# Shared library runtime path variable.
++runpath_var=$runpath_var
++
++# Shared library path variable.
++shlibpath_var=$shlibpath_var
++
++# Is shlibpath searched before the hard-coded library search path?
++shlibpath_overrides_runpath=$shlibpath_overrides_runpath
++
++# Format of library name prefix.
++libname_spec=$lt_libname_spec
++
++# List of archive names.  First name is the real one, the rest are links.
++# The last name is the one that the linker finds with -lNAME
++library_names_spec=$lt_library_names_spec
++
++# The coded name of the library, if different from the real name.
++soname_spec=$lt_soname_spec
++
++# Command to use after installation of a shared archive.
++postinstall_cmds=$lt_postinstall_cmds
++
++# Command to use after uninstallation of a shared archive.
++postuninstall_cmds=$lt_postuninstall_cmds
++
++# Commands used to finish a libtool library installation in a directory.
++finish_cmds=$lt_finish_cmds
++
++# As "finish_cmds", except a single script fragment to be evaled but
++# not shown.
++finish_eval=$lt_finish_eval
++
++# Whether we should hardcode library paths into libraries.
++hardcode_into_libs=$hardcode_into_libs
++
++# Compile-time system search path for libraries.
++sys_lib_search_path_spec=$lt_sys_lib_search_path_spec
++
++# Run-time system search path for libraries.
++sys_lib_dlsearch_path_spec=$lt_sys_lib_dlsearch_path_spec
++
++# Whether dlopen is supported.
++dlopen_support=$enable_dlopen
++
++# Whether dlopen of programs is supported.
++dlopen_self=$enable_dlopen_self
++
++# Whether dlopen of statically linked programs is supported.
++dlopen_self_static=$enable_dlopen_self_static
++
++# Commands to strip libraries.
++old_striplib=$lt_old_striplib
++striplib=$lt_striplib
++
++
++# The linker used to build libraries.
++LD=$lt_LD
++
++# Commands used to build an old-style archive.
++old_archive_cmds=$lt_old_archive_cmds
++
++# A language specific compiler.
++CC=$lt_compiler
++
++# Is the compiler the GNU compiler?
++with_gcc=$GCC
++
++# Compiler flag to turn off builtin functions.
++no_builtin_flag=$lt_lt_prog_compiler_no_builtin_flag
++
++# How to pass a linker flag through the compiler.
++wl=$lt_lt_prog_compiler_wl
++
++# Additional compiler flags for building library objects.
++pic_flag=$lt_lt_prog_compiler_pic
++
++# Compiler flag to prevent dynamic linking.
++link_static_flag=$lt_lt_prog_compiler_static
++
++# Does compiler simultaneously support -c and -o options?
++compiler_c_o=$lt_lt_cv_prog_compiler_c_o
++
++# Whether or not to add -lc for building shared libraries.
++build_libtool_need_lc=$archive_cmds_need_lc
++
++# Whether or not to disallow shared libs when runtime libs are static.
++allow_libtool_libs_with_static_runtimes=$enable_shared_with_static_runtimes
++
++# Compiler flag to allow reflexive dlopens.
++export_dynamic_flag_spec=$lt_export_dynamic_flag_spec
++
++# Compiler flag to generate shared objects directly from archives.
++whole_archive_flag_spec=$lt_whole_archive_flag_spec
++
++# Whether the compiler copes with passing no objects directly.
++compiler_needs_object=$lt_compiler_needs_object
++
++# Create an old-style archive from a shared archive.
++old_archive_from_new_cmds=$lt_old_archive_from_new_cmds
++
++# Create a temporary old-style archive to link instead of a shared archive.
++old_archive_from_expsyms_cmds=$lt_old_archive_from_expsyms_cmds
++
++# Commands used to build a shared archive.
++archive_cmds=$lt_archive_cmds
++archive_expsym_cmds=$lt_archive_expsym_cmds
++
++# Commands used to build a loadable module if different from building
++# a shared archive.
++module_cmds=$lt_module_cmds
++module_expsym_cmds=$lt_module_expsym_cmds
++
++# Whether we are building with GNU ld or not.
++with_gnu_ld=$lt_with_gnu_ld
++
++# Flag that allows shared libraries with undefined symbols to be built.
++allow_undefined_flag=$lt_allow_undefined_flag
++
++# Flag that enforces no undefined symbols.
++no_undefined_flag=$lt_no_undefined_flag
++
++# Flag to hardcode \$libdir into a binary during linking.
++# This must work even if \$libdir does not exist
++hardcode_libdir_flag_spec=$lt_hardcode_libdir_flag_spec
++
++# If ld is used when linking, flag to hardcode \$libdir into a binary
++# during linking.  This must work even if \$libdir does not exist.
++hardcode_libdir_flag_spec_ld=$lt_hardcode_libdir_flag_spec_ld
++
++# Whether we need a single "-rpath" flag with a separated argument.
++hardcode_libdir_separator=$lt_hardcode_libdir_separator
++
++# Set to "yes" if using DIR/libNAME\${shared_ext} during linking hardcodes
++# DIR into the resulting binary.
++hardcode_direct=$hardcode_direct
++
++# Set to "yes" if using DIR/libNAME\${shared_ext} during linking hardcodes
++# DIR into the resulting binary and the resulting library dependency is
++# "absolute",i.e impossible to change by setting \${shlibpath_var} if the
++# library is relocated.
++hardcode_direct_absolute=$hardcode_direct_absolute
++
++# Set to "yes" if using the -LDIR flag during linking hardcodes DIR
++# into the resulting binary.
++hardcode_minus_L=$hardcode_minus_L
++
++# Set to "yes" if using SHLIBPATH_VAR=DIR during linking hardcodes DIR
++# into the resulting binary.
++hardcode_shlibpath_var=$hardcode_shlibpath_var
++
++# Set to "yes" if building a shared library automatically hardcodes DIR
++# into the library and all subsequent libraries and executables linked
++# against it.
++hardcode_automatic=$hardcode_automatic
++
++# Set to yes if linker adds runtime paths of dependent libraries
++# to runtime path list.
++inherit_rpath=$inherit_rpath
++
++# Whether libtool must link a program against all its dependency libraries.
++link_all_deplibs=$link_all_deplibs
++
++# Fix the shell variable \$srcfile for the compiler.
++fix_srcfile_path=$lt_fix_srcfile_path
++
++# Set to "yes" if exported symbols are required.
++always_export_symbols=$always_export_symbols
++
++# The commands to list exported symbols.
++export_symbols_cmds=$lt_export_symbols_cmds
++
++# Symbols that should not be listed in the preloaded symbols.
++exclude_expsyms=$lt_exclude_expsyms
++
++# Symbols that must always be exported.
++include_expsyms=$lt_include_expsyms
++
++# Commands necessary for linking programs (against libraries) with templates.
++prelink_cmds=$lt_prelink_cmds
++
++# Specify filename containing input files.
++file_list_spec=$lt_file_list_spec
++
++# How to hardcode a shared library path into an executable.
++hardcode_action=$hardcode_action
++
++# ### END LIBTOOL CONFIG
++
++_LT_EOF
++
++  case $host_os in
++  aix3*)
++    cat <<\_LT_EOF >> "$cfgfile"
++# AIX sometimes has problems with the GCC collect2 program.  For some
++# reason, if we set the COLLECT_NAMES environment variable, the problems
++# vanish in a puff of smoke.
++if test "X${COLLECT_NAMES+set}" != Xset; then
++  COLLECT_NAMES=
++  export COLLECT_NAMES
++fi
++_LT_EOF
++    ;;
++  esac
++
++
++ltmain="$ac_aux_dir/ltmain.sh"
++
++
++  # We use sed instead of cat because bash on DJGPP gets confused if
++  # if finds mixed CR/LF and LF-only lines.  Since sed operates in
++  # text mode, it properly converts lines to CR/LF.  This bash problem
++  # is reportedly fixed, but why not run on old versions too?
++  sed '/^# Generated shell functions inserted here/q' "$ltmain" >> "$cfgfile" \
++    || (rm -f "$cfgfile"; exit 1)
++
++  case $xsi_shell in
++  yes)
++    cat << \_LT_EOF >> "$cfgfile"
++
++# func_dirname file append nondir_replacement
++# Compute the dirname of FILE.  If nonempty, add APPEND to the result,
++# otherwise set result to NONDIR_REPLACEMENT.
++func_dirname ()
++{
++  case ${1} in
++    */*) func_dirname_result="${1%/*}${2}" ;;
++    *  ) func_dirname_result="${3}" ;;
++  esac
++}
++
++# func_basename file
++func_basename ()
++{
++  func_basename_result="${1##*/}"
++}
++
++# func_dirname_and_basename file append nondir_replacement
++# perform func_basename and func_dirname in a single function
++# call:
++#   dirname:  Compute the dirname of FILE.  If nonempty,
++#             add APPEND to the result, otherwise set result
++#             to NONDIR_REPLACEMENT.
++#             value returned in "$func_dirname_result"
++#   basename: Compute filename of FILE.
++#             value retuned in "$func_basename_result"
++# Implementation must be kept synchronized with func_dirname
++# and func_basename. For efficiency, we do not delegate to
++# those functions but instead duplicate the functionality here.
++func_dirname_and_basename ()
++{
++  case ${1} in
++    */*) func_dirname_result="${1%/*}${2}" ;;
++    *  ) func_dirname_result="${3}" ;;
++  esac
++  func_basename_result="${1##*/}"
++}
++
++# func_stripname prefix suffix name
++# strip PREFIX and SUFFIX off of NAME.
++# PREFIX and SUFFIX must not contain globbing or regex special
++# characters, hashes, percent signs, but SUFFIX may contain a leading
++# dot (in which case that matches only a dot).
++func_stripname ()
++{
++  # pdksh 5.2.14 does not do ${X%$Y} correctly if both X and Y are
++  # positional parameters, so assign one to ordinary parameter first.
++  func_stripname_result=${3}
++  func_stripname_result=${func_stripname_result#"${1}"}
++  func_stripname_result=${func_stripname_result%"${2}"}
++}
++
++# func_opt_split
++func_opt_split ()
++{
++  func_opt_split_opt=${1%%=*}
++  func_opt_split_arg=${1#*=}
++}
++
++# func_lo2o object
++func_lo2o ()
++{
++  case ${1} in
++    *.lo) func_lo2o_result=${1%.lo}.${objext} ;;
++    *)    func_lo2o_result=${1} ;;
++  esac
++}
++
++# func_xform libobj-or-source
++func_xform ()
++{
++  func_xform_result=${1%.*}.lo
++}
++
++# func_arith arithmetic-term...
++func_arith ()
++{
++  func_arith_result=$(( $* ))
++}
++
++# func_len string
++# STRING may not start with a hyphen.
++func_len ()
++{
++  func_len_result=${#1}
++}
++
++_LT_EOF
++    ;;
++  *) # Bourne compatible functions.
++    cat << \_LT_EOF >> "$cfgfile"
++
++# func_dirname file append nondir_replacement
++# Compute the dirname of FILE.  If nonempty, add APPEND to the result,
++# otherwise set result to NONDIR_REPLACEMENT.
++func_dirname ()
++{
++  # Extract subdirectory from the argument.
++  func_dirname_result=`$ECHO "X${1}" | $Xsed -e "$dirname"`
++  if test "X$func_dirname_result" = "X${1}"; then
++    func_dirname_result="${3}"
++  else
++    func_dirname_result="$func_dirname_result${2}"
++  fi
++}
++
++# func_basename file
++func_basename ()
++{
++  func_basename_result=`$ECHO "X${1}" | $Xsed -e "$basename"`
++}
++
++
++# func_stripname prefix suffix name
++# strip PREFIX and SUFFIX off of NAME.
++# PREFIX and SUFFIX must not contain globbing or regex special
++# characters, hashes, percent signs, but SUFFIX may contain a leading
++# dot (in which case that matches only a dot).
++# func_strip_suffix prefix name
++func_stripname ()
++{
++  case ${2} in
++    .*) func_stripname_result=`$ECHO "X${3}" \
++           | $Xsed -e "s%^${1}%%" -e "s%\\\\${2}\$%%"`;;
++    *)  func_stripname_result=`$ECHO "X${3}" \
++           | $Xsed -e "s%^${1}%%" -e "s%${2}\$%%"`;;
++  esac
++}
++
++# sed scripts:
++my_sed_long_opt='1s/^\(-[^=]*\)=.*/\1/;q'
++my_sed_long_arg='1s/^-[^=]*=//'
++
++# func_opt_split
++func_opt_split ()
++{
++  func_opt_split_opt=`$ECHO "X${1}" | $Xsed -e "$my_sed_long_opt"`
++  func_opt_split_arg=`$ECHO "X${1}" | $Xsed -e "$my_sed_long_arg"`
++}
++
++# func_lo2o object
++func_lo2o ()
++{
++  func_lo2o_result=`$ECHO "X${1}" | $Xsed -e "$lo2o"`
++}
++
++# func_xform libobj-or-source
++func_xform ()
++{
++  func_xform_result=`$ECHO "X${1}" | $Xsed -e 's/\.[^.]*$/.lo/'`
++}
++
++# func_arith arithmetic-term...
++func_arith ()
++{
++  func_arith_result=`expr "$@"`
++}
++
++# func_len string
++# STRING may not start with a hyphen.
++func_len ()
++{
++  func_len_result=`expr "$1" : ".*" 2>/dev/null || echo $max_cmd_len`
++}
++
++_LT_EOF
++esac
++
++case $lt_shell_append in
++  yes)
++    cat << \_LT_EOF >> "$cfgfile"
++
++# func_append var value
++# Append VALUE to the end of shell variable VAR.
++func_append ()
++{
++  eval "$1+=\$2"
++}
++_LT_EOF
++    ;;
++  *)
++    cat << \_LT_EOF >> "$cfgfile"
++
++# func_append var value
++# Append VALUE to the end of shell variable VAR.
++func_append ()
++{
++  eval "$1=\$$1\$2"
++}
++
++_LT_EOF
++    ;;
++  esac
++
++
++  sed -n '/^# Generated shell functions inserted here/,$p' "$ltmain" >> "$cfgfile" \
++    || (rm -f "$cfgfile"; exit 1)
++
++  mv -f "$cfgfile" "$ofile" ||
++    (rm -f "$ofile" && cp "$cfgfile" "$ofile" && rm -f "$cfgfile")
++  chmod +x "$ofile"
++
++ ;;
++
++  esac
++done # for ac_tag
++
++
++as_fn_exit 0
++_ACEOF
++ac_clean_files=$ac_clean_files_save
++
++test $ac_write_fail = 0 ||
++  as_fn_error $? "write failure creating $CONFIG_STATUS" "$LINENO" 5
++
++
++# configure is writing to config.log, and then calls config.status.
++# config.status does its own redirection, appending to config.log.
++# Unfortunately, on DOS this fails, as config.log is still kept open
++# by configure, so config.status won't be able to write to it; its
++# output is simply discarded.  So we exec the FD to /dev/null,
++# effectively closing config.log, so it can be properly (re)opened and
++# appended to by config.status.  When coming back to configure, we
++# need to make the FD available again.
++if test "$no_create" != yes; then
++  ac_cs_success=:
++  ac_config_status_args=
++  test "$silent" = yes &&
++    ac_config_status_args="$ac_config_status_args --quiet"
++  exec 5>/dev/null
++  $SHELL $CONFIG_STATUS $ac_config_status_args || ac_cs_success=false
++  exec 5>>config.log
++  # Use ||, not &&, to avoid exiting from the if with $? = 1, which
++  # would make configure fail if this is the last instruction.
++  $ac_cs_success || as_fn_exit 1
++fi
++if test -n "$ac_unrecognized_opts" && test "$enable_option_checking" != no; then
++  { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: unrecognized options: $ac_unrecognized_opts" >&5
++$as_echo "$as_me: WARNING: unrecognized options: $ac_unrecognized_opts" >&2;}
++fi
++
++
++
++cat > include/newversion.h.in <<EOF
++#ifndef VERSION_HIDDEN
++#define VERSION_HIDDEN
++#endif
++VERSION_HIDDEN const char *heimdal_long_version = "@(#)\$Version: $PACKAGE_STRING by @USER@ on @HOST@ ($host) @DATE@ \$";
++VERSION_HIDDEN const char *heimdal_version = "Heimdal 1.4.99";
++EOF
++
++if test -f include/version.h && cmp -s include/newversion.h.in include/version.h.in; then
++	echo "include/version.h is unchanged"
++	rm -f include/newversion.h.in
++else
++ 	echo "creating include/version.h"
++ 	User=${USER-${LOGNAME}}
++ 	Host=`(hostname || uname -n || echo unknown) 2>/dev/null | sed 1q`
++ 	Date=`date`
++	mv -f include/newversion.h.in include/version.h.in
++	sed -e "s/@USER@/$User/" -e "s/@HOST@/$Host/" -e "s/@DATE@/$Date/" include/version.h.in > include/version.h
++fi
+Index: git/depcomp
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/depcomp	2010-12-29 04:04:06.000000000 +0100
+@@ -0,0 +1,630 @@
++#! /bin/sh
++# depcomp - compile a program generating dependencies as side-effects
++
++scriptversion=2009-04-28.21; # UTC
++
++# Copyright (C) 1999, 2000, 2003, 2004, 2005, 2006, 2007, 2009 Free
++# Software Foundation, Inc.
++
++# This program is free software; you can redistribute it and/or modify
++# it under the terms of the GNU General Public License as published by
++# the Free Software Foundation; either version 2, or (at your option)
++# any later version.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY; without even the implied warranty of
++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++# GNU General Public License for more details.
++
++# You should have received a copy of the GNU General Public License
++# along with this program.  If not, see <http://www.gnu.org/licenses/>.
++
++# As a special exception to the GNU General Public License, if you
++# distribute this file as part of a program that contains a
++# configuration script generated by Autoconf, you may include it under
++# the same distribution terms that you use for the rest of that program.
++
++# Originally written by Alexandre Oliva <oliva@dcc.unicamp.br>.
++
++case $1 in
++  '')
++     echo "$0: No command.  Try \`$0 --help' for more information." 1>&2
++     exit 1;
++     ;;
++  -h | --h*)
++    cat <<\EOF
++Usage: depcomp [--help] [--version] PROGRAM [ARGS]
++
++Run PROGRAMS ARGS to compile a file, generating dependencies
++as side-effects.
++
++Environment variables:
++  depmode     Dependency tracking mode.
++  source      Source file read by `PROGRAMS ARGS'.
++  object      Object file output by `PROGRAMS ARGS'.
++  DEPDIR      directory where to store dependencies.
++  depfile     Dependency file to output.
++  tmpdepfile  Temporary file to use when outputing dependencies.
++  libtool     Whether libtool is used (yes/no).
++
++Report bugs to <bug-automake@gnu.org>.
++EOF
++    exit $?
++    ;;
++  -v | --v*)
++    echo "depcomp $scriptversion"
++    exit $?
++    ;;
++esac
++
++if test -z "$depmode" || test -z "$source" || test -z "$object"; then
++  echo "depcomp: Variables source, object and depmode must be set" 1>&2
++  exit 1
++fi
++
++# Dependencies for sub/bar.o or sub/bar.obj go into sub/.deps/bar.Po.
++depfile=${depfile-`echo "$object" |
++  sed 's|[^\\/]*$|'${DEPDIR-.deps}'/&|;s|\.\([^.]*\)$|.P\1|;s|Pobj$|Po|'`}
++tmpdepfile=${tmpdepfile-`echo "$depfile" | sed 's/\.\([^.]*\)$/.T\1/'`}
++
++rm -f "$tmpdepfile"
++
++# Some modes work just like other modes, but use different flags.  We
++# parameterize here, but still list the modes in the big case below,
++# to make depend.m4 easier to write.  Note that we *cannot* use a case
++# here, because this file can only contain one case statement.
++if test "$depmode" = hp; then
++  # HP compiler uses -M and no extra arg.
++  gccflag=-M
++  depmode=gcc
++fi
++
++if test "$depmode" = dashXmstdout; then
++   # This is just like dashmstdout with a different argument.
++   dashmflag=-xM
++   depmode=dashmstdout
++fi
++
++cygpath_u="cygpath -u -f -"
++if test "$depmode" = msvcmsys; then
++   # This is just like msvisualcpp but w/o cygpath translation.
++   # Just convert the backslash-escaped backslashes to single forward
++   # slashes to satisfy depend.m4
++   cygpath_u="sed s,\\\\\\\\,/,g"
++   depmode=msvisualcpp
++fi
++
++case "$depmode" in
++gcc3)
++## gcc 3 implements dependency tracking that does exactly what
++## we want.  Yay!  Note: for some reason libtool 1.4 doesn't like
++## it if -MD -MP comes after the -MF stuff.  Hmm.
++## Unfortunately, FreeBSD c89 acceptance of flags depends upon
++## the command line argument order; so add the flags where they
++## appear in depend2.am.  Note that the slowdown incurred here
++## affects only configure: in makefiles, %FASTDEP% shortcuts this.
++  for arg
++  do
++    case $arg in
++    -c) set fnord "$@" -MT "$object" -MD -MP -MF "$tmpdepfile" "$arg" ;;
++    *)  set fnord "$@" "$arg" ;;
++    esac
++    shift # fnord
++    shift # $arg
++  done
++  "$@"
++  stat=$?
++  if test $stat -eq 0; then :
++  else
++    rm -f "$tmpdepfile"
++    exit $stat
++  fi
++  mv "$tmpdepfile" "$depfile"
++  ;;
++
++gcc)
++## There are various ways to get dependency output from gcc.  Here's
++## why we pick this rather obscure method:
++## - Don't want to use -MD because we'd like the dependencies to end
++##   up in a subdir.  Having to rename by hand is ugly.
++##   (We might end up doing this anyway to support other compilers.)
++## - The DEPENDENCIES_OUTPUT environment variable makes gcc act like
++##   -MM, not -M (despite what the docs say).
++## - Using -M directly means running the compiler twice (even worse
++##   than renaming).
++  if test -z "$gccflag"; then
++    gccflag=-MD,
++  fi
++  "$@" -Wp,"$gccflag$tmpdepfile"
++  stat=$?
++  if test $stat -eq 0; then :
++  else
++    rm -f "$tmpdepfile"
++    exit $stat
++  fi
++  rm -f "$depfile"
++  echo "$object : \\" > "$depfile"
++  alpha=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
++## The second -e expression handles DOS-style file names with drive letters.
++  sed -e 's/^[^:]*: / /' \
++      -e 's/^['$alpha']:\/[^:]*: / /' < "$tmpdepfile" >> "$depfile"
++## This next piece of magic avoids the `deleted header file' problem.
++## The problem is that when a header file which appears in a .P file
++## is deleted, the dependency causes make to die (because there is
++## typically no way to rebuild the header).  We avoid this by adding
++## dummy dependencies for each header file.  Too bad gcc doesn't do
++## this for us directly.
++  tr ' ' '
++' < "$tmpdepfile" |
++## Some versions of gcc put a space before the `:'.  On the theory
++## that the space means something, we add a space to the output as
++## well.
++## Some versions of the HPUX 10.20 sed can't process this invocation
++## correctly.  Breaking it into two sed invocations is a workaround.
++    sed -e 's/^\\$//' -e '/^$/d' -e '/:$/d' | sed -e 's/$/ :/' >> "$depfile"
++  rm -f "$tmpdepfile"
++  ;;
++
++hp)
++  # This case exists only to let depend.m4 do its work.  It works by
++  # looking at the text of this script.  This case will never be run,
++  # since it is checked for above.
++  exit 1
++  ;;
++
++sgi)
++  if test "$libtool" = yes; then
++    "$@" "-Wp,-MDupdate,$tmpdepfile"
++  else
++    "$@" -MDupdate "$tmpdepfile"
++  fi
++  stat=$?
++  if test $stat -eq 0; then :
++  else
++    rm -f "$tmpdepfile"
++    exit $stat
++  fi
++  rm -f "$depfile"
++
++  if test -f "$tmpdepfile"; then  # yes, the sourcefile depend on other files
++    echo "$object : \\" > "$depfile"
++
++    # Clip off the initial element (the dependent).  Don't try to be
++    # clever and replace this with sed code, as IRIX sed won't handle
++    # lines with more than a fixed number of characters (4096 in
++    # IRIX 6.2 sed, 8192 in IRIX 6.5).  We also remove comment lines;
++    # the IRIX cc adds comments like `#:fec' to the end of the
++    # dependency line.
++    tr ' ' '
++' < "$tmpdepfile" \
++    | sed -e 's/^.*\.o://' -e 's/#.*$//' -e '/^$/ d' | \
++    tr '
++' ' ' >> "$depfile"
++    echo >> "$depfile"
++
++    # The second pass generates a dummy entry for each header file.
++    tr ' ' '
++' < "$tmpdepfile" \
++   | sed -e 's/^.*\.o://' -e 's/#.*$//' -e '/^$/ d' -e 's/$/:/' \
++   >> "$depfile"
++  else
++    # The sourcefile does not contain any dependencies, so just
++    # store a dummy comment line, to avoid errors with the Makefile
++    # "include basename.Plo" scheme.
++    echo "#dummy" > "$depfile"
++  fi
++  rm -f "$tmpdepfile"
++  ;;
++
++aix)
++  # The C for AIX Compiler uses -M and outputs the dependencies
++  # in a .u file.  In older versions, this file always lives in the
++  # current directory.  Also, the AIX compiler puts `$object:' at the
++  # start of each line; $object doesn't have directory information.
++  # Version 6 uses the directory in both cases.
++  dir=`echo "$object" | sed -e 's|/[^/]*$|/|'`
++  test "x$dir" = "x$object" && dir=
++  base=`echo "$object" | sed -e 's|^.*/||' -e 's/\.o$//' -e 's/\.lo$//'`
++  if test "$libtool" = yes; then
++    tmpdepfile1=$dir$base.u
++    tmpdepfile2=$base.u
++    tmpdepfile3=$dir.libs/$base.u
++    "$@" -Wc,-M
++  else
++    tmpdepfile1=$dir$base.u
++    tmpdepfile2=$dir$base.u
++    tmpdepfile3=$dir$base.u
++    "$@" -M
++  fi
++  stat=$?
++
++  if test $stat -eq 0; then :
++  else
++    rm -f "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3"
++    exit $stat
++  fi
++
++  for tmpdepfile in "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3"
++  do
++    test -f "$tmpdepfile" && break
++  done
++  if test -f "$tmpdepfile"; then
++    # Each line is of the form `foo.o: dependent.h'.
++    # Do two passes, one to just change these to
++    # `$object: dependent.h' and one to simply `dependent.h:'.
++    sed -e "s,^.*\.[a-z]*:,$object:," < "$tmpdepfile" > "$depfile"
++    # That's a tab and a space in the [].
++    sed -e 's,^.*\.[a-z]*:[	 ]*,,' -e 's,$,:,' < "$tmpdepfile" >> "$depfile"
++  else
++    # The sourcefile does not contain any dependencies, so just
++    # store a dummy comment line, to avoid errors with the Makefile
++    # "include basename.Plo" scheme.
++    echo "#dummy" > "$depfile"
++  fi
++  rm -f "$tmpdepfile"
++  ;;
++
++icc)
++  # Intel's C compiler understands `-MD -MF file'.  However on
++  #    icc -MD -MF foo.d -c -o sub/foo.o sub/foo.c
++  # ICC 7.0 will fill foo.d with something like
++  #    foo.o: sub/foo.c
++  #    foo.o: sub/foo.h
++  # which is wrong.  We want:
++  #    sub/foo.o: sub/foo.c
++  #    sub/foo.o: sub/foo.h
++  #    sub/foo.c:
++  #    sub/foo.h:
++  # ICC 7.1 will output
++  #    foo.o: sub/foo.c sub/foo.h
++  # and will wrap long lines using \ :
++  #    foo.o: sub/foo.c ... \
++  #     sub/foo.h ... \
++  #     ...
++
++  "$@" -MD -MF "$tmpdepfile"
++  stat=$?
++  if test $stat -eq 0; then :
++  else
++    rm -f "$tmpdepfile"
++    exit $stat
++  fi
++  rm -f "$depfile"
++  # Each line is of the form `foo.o: dependent.h',
++  # or `foo.o: dep1.h dep2.h \', or ` dep3.h dep4.h \'.
++  # Do two passes, one to just change these to
++  # `$object: dependent.h' and one to simply `dependent.h:'.
++  sed "s,^[^:]*:,$object :," < "$tmpdepfile" > "$depfile"
++  # Some versions of the HPUX 10.20 sed can't process this invocation
++  # correctly.  Breaking it into two sed invocations is a workaround.
++  sed 's,^[^:]*: \(.*\)$,\1,;s/^\\$//;/^$/d;/:$/d' < "$tmpdepfile" |
++    sed -e 's/$/ :/' >> "$depfile"
++  rm -f "$tmpdepfile"
++  ;;
++
++hp2)
++  # The "hp" stanza above does not work with aCC (C++) and HP's ia64
++  # compilers, which have integrated preprocessors.  The correct option
++  # to use with these is +Maked; it writes dependencies to a file named
++  # 'foo.d', which lands next to the object file, wherever that
++  # happens to be.
++  # Much of this is similar to the tru64 case; see comments there.
++  dir=`echo "$object" | sed -e 's|/[^/]*$|/|'`
++  test "x$dir" = "x$object" && dir=
++  base=`echo "$object" | sed -e 's|^.*/||' -e 's/\.o$//' -e 's/\.lo$//'`
++  if test "$libtool" = yes; then
++    tmpdepfile1=$dir$base.d
++    tmpdepfile2=$dir.libs/$base.d
++    "$@" -Wc,+Maked
++  else
++    tmpdepfile1=$dir$base.d
++    tmpdepfile2=$dir$base.d
++    "$@" +Maked
++  fi
++  stat=$?
++  if test $stat -eq 0; then :
++  else
++     rm -f "$tmpdepfile1" "$tmpdepfile2"
++     exit $stat
++  fi
++
++  for tmpdepfile in "$tmpdepfile1" "$tmpdepfile2"
++  do
++    test -f "$tmpdepfile" && break
++  done
++  if test -f "$tmpdepfile"; then
++    sed -e "s,^.*\.[a-z]*:,$object:," "$tmpdepfile" > "$depfile"
++    # Add `dependent.h:' lines.
++    sed -ne '2,${
++	       s/^ *//
++	       s/ \\*$//
++	       s/$/:/
++	       p
++	     }' "$tmpdepfile" >> "$depfile"
++  else
++    echo "#dummy" > "$depfile"
++  fi
++  rm -f "$tmpdepfile" "$tmpdepfile2"
++  ;;
++
++tru64)
++   # The Tru64 compiler uses -MD to generate dependencies as a side
++   # effect.  `cc -MD -o foo.o ...' puts the dependencies into `foo.o.d'.
++   # At least on Alpha/Redhat 6.1, Compaq CCC V6.2-504 seems to put
++   # dependencies in `foo.d' instead, so we check for that too.
++   # Subdirectories are respected.
++   dir=`echo "$object" | sed -e 's|/[^/]*$|/|'`
++   test "x$dir" = "x$object" && dir=
++   base=`echo "$object" | sed -e 's|^.*/||' -e 's/\.o$//' -e 's/\.lo$//'`
++
++   if test "$libtool" = yes; then
++      # With Tru64 cc, shared objects can also be used to make a
++      # static library.  This mechanism is used in libtool 1.4 series to
++      # handle both shared and static libraries in a single compilation.
++      # With libtool 1.4, dependencies were output in $dir.libs/$base.lo.d.
++      #
++      # With libtool 1.5 this exception was removed, and libtool now
++      # generates 2 separate objects for the 2 libraries.  These two
++      # compilations output dependencies in $dir.libs/$base.o.d and
++      # in $dir$base.o.d.  We have to check for both files, because
++      # one of the two compilations can be disabled.  We should prefer
++      # $dir$base.o.d over $dir.libs/$base.o.d because the latter is
++      # automatically cleaned when .libs/ is deleted, while ignoring
++      # the former would cause a distcleancheck panic.
++      tmpdepfile1=$dir.libs/$base.lo.d   # libtool 1.4
++      tmpdepfile2=$dir$base.o.d          # libtool 1.5
++      tmpdepfile3=$dir.libs/$base.o.d    # libtool 1.5
++      tmpdepfile4=$dir.libs/$base.d      # Compaq CCC V6.2-504
++      "$@" -Wc,-MD
++   else
++      tmpdepfile1=$dir$base.o.d
++      tmpdepfile2=$dir$base.d
++      tmpdepfile3=$dir$base.d
++      tmpdepfile4=$dir$base.d
++      "$@" -MD
++   fi
++
++   stat=$?
++   if test $stat -eq 0; then :
++   else
++      rm -f "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3" "$tmpdepfile4"
++      exit $stat
++   fi
++
++   for tmpdepfile in "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3" "$tmpdepfile4"
++   do
++     test -f "$tmpdepfile" && break
++   done
++   if test -f "$tmpdepfile"; then
++      sed -e "s,^.*\.[a-z]*:,$object:," < "$tmpdepfile" > "$depfile"
++      # That's a tab and a space in the [].
++      sed -e 's,^.*\.[a-z]*:[	 ]*,,' -e 's,$,:,' < "$tmpdepfile" >> "$depfile"
++   else
++      echo "#dummy" > "$depfile"
++   fi
++   rm -f "$tmpdepfile"
++   ;;
++
++#nosideeffect)
++  # This comment above is used by automake to tell side-effect
++  # dependency tracking mechanisms from slower ones.
++
++dashmstdout)
++  # Important note: in order to support this mode, a compiler *must*
++  # always write the preprocessed file to stdout, regardless of -o.
++  "$@" || exit $?
++
++  # Remove the call to Libtool.
++  if test "$libtool" = yes; then
++    while test "X$1" != 'X--mode=compile'; do
++      shift
++    done
++    shift
++  fi
++
++  # Remove `-o $object'.
++  IFS=" "
++  for arg
++  do
++    case $arg in
++    -o)
++      shift
++      ;;
++    $object)
++      shift
++      ;;
++    *)
++      set fnord "$@" "$arg"
++      shift # fnord
++      shift # $arg
++      ;;
++    esac
++  done
++
++  test -z "$dashmflag" && dashmflag=-M
++  # Require at least two characters before searching for `:'
++  # in the target name.  This is to cope with DOS-style filenames:
++  # a dependency such as `c:/foo/bar' could be seen as target `c' otherwise.
++  "$@" $dashmflag |
++    sed 's:^[  ]*[^: ][^:][^:]*\:[    ]*:'"$object"'\: :' > "$tmpdepfile"
++  rm -f "$depfile"
++  cat < "$tmpdepfile" > "$depfile"
++  tr ' ' '
++' < "$tmpdepfile" | \
++## Some versions of the HPUX 10.20 sed can't process this invocation
++## correctly.  Breaking it into two sed invocations is a workaround.
++    sed -e 's/^\\$//' -e '/^$/d' -e '/:$/d' | sed -e 's/$/ :/' >> "$depfile"
++  rm -f "$tmpdepfile"
++  ;;
++
++dashXmstdout)
++  # This case only exists to satisfy depend.m4.  It is never actually
++  # run, as this mode is specially recognized in the preamble.
++  exit 1
++  ;;
++
++makedepend)
++  "$@" || exit $?
++  # Remove any Libtool call
++  if test "$libtool" = yes; then
++    while test "X$1" != 'X--mode=compile'; do
++      shift
++    done
++    shift
++  fi
++  # X makedepend
++  shift
++  cleared=no eat=no
++  for arg
++  do
++    case $cleared in
++    no)
++      set ""; shift
++      cleared=yes ;;
++    esac
++    if test $eat = yes; then
++      eat=no
++      continue
++    fi
++    case "$arg" in
++    -D*|-I*)
++      set fnord "$@" "$arg"; shift ;;
++    # Strip any option that makedepend may not understand.  Remove
++    # the object too, otherwise makedepend will parse it as a source file.
++    -arch)
++      eat=yes ;;
++    -*|$object)
++      ;;
++    *)
++      set fnord "$@" "$arg"; shift ;;
++    esac
++  done
++  obj_suffix=`echo "$object" | sed 's/^.*\././'`
++  touch "$tmpdepfile"
++  ${MAKEDEPEND-makedepend} -o"$obj_suffix" -f"$tmpdepfile" "$@"
++  rm -f "$depfile"
++  cat < "$tmpdepfile" > "$depfile"
++  sed '1,2d' "$tmpdepfile" | tr ' ' '
++' | \
++## Some versions of the HPUX 10.20 sed can't process this invocation
++## correctly.  Breaking it into two sed invocations is a workaround.
++    sed -e 's/^\\$//' -e '/^$/d' -e '/:$/d' | sed -e 's/$/ :/' >> "$depfile"
++  rm -f "$tmpdepfile" "$tmpdepfile".bak
++  ;;
++
++cpp)
++  # Important note: in order to support this mode, a compiler *must*
++  # always write the preprocessed file to stdout.
++  "$@" || exit $?
++
++  # Remove the call to Libtool.
++  if test "$libtool" = yes; then
++    while test "X$1" != 'X--mode=compile'; do
++      shift
++    done
++    shift
++  fi
++
++  # Remove `-o $object'.
++  IFS=" "
++  for arg
++  do
++    case $arg in
++    -o)
++      shift
++      ;;
++    $object)
++      shift
++      ;;
++    *)
++      set fnord "$@" "$arg"
++      shift # fnord
++      shift # $arg
++      ;;
++    esac
++  done
++
++  "$@" -E |
++    sed -n -e '/^# [0-9][0-9]* "\([^"]*\)".*/ s:: \1 \\:p' \
++       -e '/^#line [0-9][0-9]* "\([^"]*\)".*/ s:: \1 \\:p' |
++    sed '$ s: \\$::' > "$tmpdepfile"
++  rm -f "$depfile"
++  echo "$object : \\" > "$depfile"
++  cat < "$tmpdepfile" >> "$depfile"
++  sed < "$tmpdepfile" '/^$/d;s/^ //;s/ \\$//;s/$/ :/' >> "$depfile"
++  rm -f "$tmpdepfile"
++  ;;
++
++msvisualcpp)
++  # Important note: in order to support this mode, a compiler *must*
++  # always write the preprocessed file to stdout.
++  "$@" || exit $?
++
++  # Remove the call to Libtool.
++  if test "$libtool" = yes; then
++    while test "X$1" != 'X--mode=compile'; do
++      shift
++    done
++    shift
++  fi
++
++  IFS=" "
++  for arg
++  do
++    case "$arg" in
++    -o)
++      shift
++      ;;
++    $object)
++      shift
++      ;;
++    "-Gm"|"/Gm"|"-Gi"|"/Gi"|"-ZI"|"/ZI")
++	set fnord "$@"
++	shift
++	shift
++	;;
++    *)
++	set fnord "$@" "$arg"
++	shift
++	shift
++	;;
++    esac
++  done
++  "$@" -E 2>/dev/null |
++  sed -n '/^#line [0-9][0-9]* "\([^"]*\)"/ s::\1:p' | $cygpath_u | sort -u > "$tmpdepfile"
++  rm -f "$depfile"
++  echo "$object : \\" > "$depfile"
++  sed < "$tmpdepfile" -n -e 's% %\\ %g' -e '/^\(.*\)$/ s::	\1 \\:p' >> "$depfile"
++  echo "	" >> "$depfile"
++  sed < "$tmpdepfile" -n -e 's% %\\ %g' -e '/^\(.*\)$/ s::\1\::p' >> "$depfile"
++  rm -f "$tmpdepfile"
++  ;;
++
++msvcmsys)
++  # This case exists only to let depend.m4 do its work.  It works by
++  # looking at the text of this script.  This case will never be run,
++  # since it is checked for above.
++  exit 1
++  ;;
++
++none)
++  exec "$@"
++  ;;
++
++*)
++  echo "Unknown depmode $depmode" 1>&2
++  exit 1
++  ;;
++esac
++
++exit 0
++
++# Local Variables:
++# mode: shell-script
++# sh-indentation: 2
++# eval: (add-hook 'write-file-hooks 'time-stamp)
++# time-stamp-start: "scriptversion="
++# time-stamp-format: "%:y-%02m-%02d.%02H"
++# time-stamp-time-zone: "UTC"
++# time-stamp-end: "; # UTC"
++# End:
+Index: git/doc/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/doc/Makefile.in	2010-12-29 04:07:05.434884979 +0100
+@@ -0,0 +1,1117 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(heimdal_TEXINFOS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common mdate-sh
++subdir = doc
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++INFO_DEPS = $(srcdir)/heimdal.info $(srcdir)/hx509.info
++am__TEXINFO_TEX_DIR = $(srcdir)
++DVIS = heimdal.dvi hx509.dvi
++PDFS = heimdal.pdf hx509.pdf
++PSS = heimdal.ps hx509.ps
++HTMLS = heimdal.html hx509.html
++TEXINFOS = heimdal.texi hx509.texi
++TEXI2PDF = $(TEXI2DVI) --pdf --batch
++MAKEINFOHTML = $(MAKEINFO) --html
++AM_MAKEINFOHTMLFLAGS = $(AM_MAKEINFOFLAGS)
++DVIPS = dvips
++am__installdirs = "$(DESTDIR)$(infodir)"
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++AUTOMAKE_OPTIONS = no-texinfo.tex
++MAKEINFOFLAGS = --css-include=$(srcdir)/heimdal.css
++TEXI2DVI = true # ARGH, make distcheck can't be disabled to not build dvifiles
++info_TEXINFOS = heimdal.texi hx509.texi
++dxy_subst = sed -e 's,[@]srcdir[@],$(srcdir),g' \
++	-e 's,[@]objdir[@],.,g' \
++	-e 's,[@]PACKAGE_VERSION[@],$(PACKAGE_VERSION),g'
++
++texi_subst = sed -e 's,[@]dbdir[@],$(localstatedir),g' \
++	-e 's,[@]PACKAGE_VERSION[@],$(PACKAGE_VERSION),g'
++
++PROJECTS = hcrypto hdb hx509 gssapi krb5 ntlm wind 
++heimdal_TEXINFOS = \
++	ack.texi \
++	apps.texi \
++	copyright.texi \
++	heimdal.texi \
++	install.texi \
++	intro.texi \
++	kerberos4.texi \
++	migration.texi \
++	misc.texi \
++	programming.texi \
++	setup.texi \
++	vars.texi \
++	whatis.texi \
++	win2k.texi
++
++EXTRA_DIST = \
++	doxyout \
++	footer.html \
++	gssapi.din \
++	hdb.din \
++	hcrypto.din \
++	header.html \
++	heimdal.css \
++	hx509.din \
++	krb5.din \
++	ntlm.din \
++	init-creds \
++	latin1.tex \
++	layman.asc \
++	doxytmpl.dxy \
++	wind.din \
++	vars.tin
++
++CLEANFILES = \
++	hcrypto.dxy* \
++	hx509.dxy* \
++	hdb.dxy* \
++	gssapi.dxy* \
++	krb5.dxy* \
++	ntlm.dxy* \
++	wind.dxy* \
++	vars.texi*
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .dvi .html .info .pdf .ps .texi
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign doc/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign doc/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++.texi.info:
++	restore=: && backupdir="$(am__leading_dot)am$$$$" && \
++	am__cwd=`pwd` && $(am__cd) $(srcdir) && \
++	rm -rf $$backupdir && mkdir $$backupdir && \
++	if ($(MAKEINFO) --version) >/dev/null 2>&1; then \
++	  for f in $@ $@-[0-9] $@-[0-9][0-9] $(@:.info=).i[0-9] $(@:.info=).i[0-9][0-9]; do \
++	    if test -f $$f; then mv $$f $$backupdir; restore=mv; else :; fi; \
++	  done; \
++	else :; fi && \
++	cd "$$am__cwd"; \
++	if $(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -I $(srcdir) \
++	 -o $@ $<; \
++	then \
++	  rc=0; \
++	  $(am__cd) $(srcdir); \
++	else \
++	  rc=$$?; \
++	  $(am__cd) $(srcdir) && \
++	  $$restore $$backupdir/* `echo "./$@" | sed 's|[^/]*$$||'`; \
++	fi; \
++	rm -rf $$backupdir; exit $$rc
++
++.texi.dvi:
++	TEXINPUTS="$(am__TEXINFO_TEX_DIR)$(PATH_SEPARATOR)$$TEXINPUTS" \
++	MAKEINFO='$(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -I $(srcdir)' \
++	$(TEXI2DVI) $<
++
++.texi.pdf:
++	TEXINPUTS="$(am__TEXINFO_TEX_DIR)$(PATH_SEPARATOR)$$TEXINPUTS" \
++	MAKEINFO='$(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -I $(srcdir)' \
++	$(TEXI2PDF) $<
++
++.texi.html:
++	rm -rf $(@:.html=.htp)
++	if $(MAKEINFOHTML) $(AM_MAKEINFOHTMLFLAGS) $(MAKEINFOFLAGS) -I $(srcdir) \
++	 -o $(@:.html=.htp) $<; \
++	then \
++	  rm -rf $@; \
++	  if test ! -d $(@:.html=.htp) && test -d $(@:.html=); then \
++	    mv $(@:.html=) $@; else mv $(@:.html=.htp) $@; fi; \
++	else \
++	  if test ! -d $(@:.html=.htp) && test -d $(@:.html=); then \
++	    rm -rf $(@:.html=); else rm -Rf $(@:.html=.htp) $@; fi; \
++	  exit 1; \
++	fi
++$(srcdir)/heimdal.info: heimdal.texi $(heimdal_TEXINFOS)
++heimdal.dvi: heimdal.texi $(heimdal_TEXINFOS)
++heimdal.pdf: heimdal.texi $(heimdal_TEXINFOS)
++heimdal.html: heimdal.texi $(heimdal_TEXINFOS)
++$(srcdir)/hx509.info: hx509.texi 
++hx509.dvi: hx509.texi 
++hx509.pdf: hx509.texi 
++hx509.html: hx509.texi 
++.dvi.ps:
++	TEXINPUTS="$(am__TEXINFO_TEX_DIR)$(PATH_SEPARATOR)$$TEXINPUTS" \
++	$(DVIPS) -o $@ $<
++
++uninstall-dvi-am:
++	@$(NORMAL_UNINSTALL)
++	@list='$(DVIS)'; test -n "$(dvidir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " rm -f '$(DESTDIR)$(dvidir)/$$f'"; \
++	  rm -f "$(DESTDIR)$(dvidir)/$$f"; \
++	done
++
++uninstall-html-am:
++	@$(NORMAL_UNINSTALL)
++	@list='$(HTMLS)'; test -n "$(htmldir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " rm -rf '$(DESTDIR)$(htmldir)/$$f'"; \
++	  rm -rf "$(DESTDIR)$(htmldir)/$$f"; \
++	done
++
++uninstall-info-am:
++	@$(PRE_UNINSTALL)
++	@if test -d '$(DESTDIR)$(infodir)' && \
++	    (install-info --version && \
++	     install-info --version 2>&1 | sed 1q | grep -i -v debian) >/dev/null 2>&1; then \
++	  list='$(INFO_DEPS)'; \
++	  for file in $$list; do \
++	    relfile=`echo "$$file" | sed 's|^.*/||'`; \
++	    echo " install-info --info-dir='$(DESTDIR)$(infodir)' --remove '$(DESTDIR)$(infodir)/$$relfile'"; \
++	    if install-info --info-dir="$(DESTDIR)$(infodir)" --remove "$(DESTDIR)$(infodir)/$$relfile"; \
++	    then :; else test ! -f "$(DESTDIR)$(infodir)/$$relfile" || exit 1; fi; \
++	  done; \
++	else :; fi
++	@$(NORMAL_UNINSTALL)
++	@list='$(INFO_DEPS)'; \
++	for file in $$list; do \
++	  relfile=`echo "$$file" | sed 's|^.*/||'`; \
++	  relfile_i=`echo "$$relfile" | sed 's|\.info$$||;s|$$|.i|'`; \
++	  (if test -d "$(DESTDIR)$(infodir)" && cd "$(DESTDIR)$(infodir)"; then \
++	     echo " cd '$(DESTDIR)$(infodir)' && rm -f $$relfile $$relfile-[0-9] $$relfile-[0-9][0-9] $$relfile_i[0-9] $$relfile_i[0-9][0-9]"; \
++	     rm -f $$relfile $$relfile-[0-9] $$relfile-[0-9][0-9] $$relfile_i[0-9] $$relfile_i[0-9][0-9]; \
++	   else :; fi); \
++	done
++
++uninstall-pdf-am:
++	@$(NORMAL_UNINSTALL)
++	@list='$(PDFS)'; test -n "$(pdfdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " rm -f '$(DESTDIR)$(pdfdir)/$$f'"; \
++	  rm -f "$(DESTDIR)$(pdfdir)/$$f"; \
++	done
++
++uninstall-ps-am:
++	@$(NORMAL_UNINSTALL)
++	@list='$(PSS)'; test -n "$(psdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " rm -f '$(DESTDIR)$(psdir)/$$f'"; \
++	  rm -f "$(DESTDIR)$(psdir)/$$f"; \
++	done
++
++dist-info: $(INFO_DEPS)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; \
++	list='$(INFO_DEPS)'; \
++	for base in $$list; do \
++	  case $$base in \
++	    $(srcdir)/*) base=`echo "$$base" | sed "s|^$$srcdirstrip/||"`;; \
++	  esac; \
++	  if test -f $$base; then d=.; else d=$(srcdir); fi; \
++	  base_i=`echo "$$base" | sed 's|\.info$$||;s|$$|.i|'`; \
++	  for file in $$d/$$base $$d/$$base-[0-9] $$d/$$base-[0-9][0-9] $$d/$$base_i[0-9] $$d/$$base_i[0-9][0-9]; do \
++	    if test -f $$file; then \
++	      relfile=`expr "$$file" : "$$d/\(.*\)"`; \
++	      test -f "$(distdir)/$$relfile" || \
++		cp -p $$file "$(distdir)/$$relfile"; \
++	    else :; fi; \
++	  done; \
++	done
++
++mostlyclean-aminfo:
++	-rm -rf heimdal.aux heimdal.cp heimdal.cps heimdal.fn heimdal.fns \
++	  heimdal.ky heimdal.kys heimdal.log heimdal.pg heimdal.tmp \
++	  heimdal.toc heimdal.tp heimdal.tps heimdal.vr heimdal.vrs \
++	  hx509.aux hx509.cp hx509.cps hx509.fn hx509.fns hx509.ky \
++	  hx509.kys hx509.log hx509.pg hx509.tmp hx509.toc hx509.tp \
++	  hx509.tps hx509.vr hx509.vrs
++
++clean-aminfo:
++	-test -z "heimdal.dvi heimdal.pdf heimdal.ps heimdal.html hx509.dvi hx509.pdf \
++	  hx509.ps hx509.html" \
++	|| rm -rf heimdal.dvi heimdal.pdf heimdal.ps heimdal.html hx509.dvi hx509.pdf \
++	  hx509.ps hx509.html
++
++maintainer-clean-aminfo:
++	@list='$(INFO_DEPS)'; for i in $$list; do \
++	  i_i=`echo "$$i" | sed 's|\.info$$||;s|$$|.i|'`; \
++	  echo " rm -f $$i $$i-[0-9] $$i-[0-9][0-9] $$i_i[0-9] $$i_i[0-9][0-9]"; \
++	  rm -f $$i $$i-[0-9] $$i-[0-9][0-9] $$i_i[0-9] $$i_i[0-9][0-9]; \
++	done
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-info dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(INFO_DEPS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(infodir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-aminfo clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am: $(DVIS)
++
++html: html-am
++
++html-am: $(HTMLS)
++
++info: info-am
++
++info-am: $(INFO_DEPS)
++
++install-data-am: install-info-am
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am: $(DVIS)
++	@$(NORMAL_INSTALL)
++	test -z "$(dvidir)" || $(MKDIR_P) "$(DESTDIR)$(dvidir)"
++	@list='$(DVIS)'; test -n "$(dvidir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(dvidir)'"; \
++	  $(INSTALL_DATA) $$files "$(DESTDIR)$(dvidir)" || exit $$?; \
++	done
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am: $(HTMLS)
++	@$(NORMAL_INSTALL)
++	test -z "$(htmldir)" || $(MKDIR_P) "$(DESTDIR)$(htmldir)"
++	@list='$(HTMLS)'; list2=; test -n "$(htmldir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p" || test -d "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  $(am__strip_dir) \
++	  if test -d "$$d$$p"; then \
++	    echo " $(MKDIR_P) '$(DESTDIR)$(htmldir)/$$f'"; \
++	    $(MKDIR_P) "$(DESTDIR)$(htmldir)/$$f" || exit 1; \
++	    echo " $(INSTALL_DATA) '$$d$$p'/* '$(DESTDIR)$(htmldir)/$$f'"; \
++	    $(INSTALL_DATA) "$$d$$p"/* "$(DESTDIR)$(htmldir)/$$f" || exit $$?; \
++	  else \
++	    list2="$$list2 $$d$$p"; \
++	  fi; \
++	done; \
++	test -z "$$list2" || { echo "$$list2" | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(htmldir)'"; \
++	  $(INSTALL_DATA) $$files "$(DESTDIR)$(htmldir)" || exit $$?; \
++	done; }
++install-info: install-info-am
++
++install-info-am: $(INFO_DEPS)
++	@$(NORMAL_INSTALL)
++	test -z "$(infodir)" || $(MKDIR_P) "$(DESTDIR)$(infodir)"
++	@srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; \
++	list='$(INFO_DEPS)'; test -n "$(infodir)" || list=; \
++	for file in $$list; do \
++	  case $$file in \
++	    $(srcdir)/*) file=`echo "$$file" | sed "s|^$$srcdirstrip/||"`;; \
++	  esac; \
++	  if test -f $$file; then d=.; else d=$(srcdir); fi; \
++	  file_i=`echo "$$file" | sed 's|\.info$$||;s|$$|.i|'`; \
++	  for ifile in $$d/$$file $$d/$$file-[0-9] $$d/$$file-[0-9][0-9] \
++	               $$d/$$file_i[0-9] $$d/$$file_i[0-9][0-9] ; do \
++	    if test -f $$ifile; then \
++	      echo "$$ifile"; \
++	    else : ; fi; \
++	  done; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(infodir)'"; \
++	  $(INSTALL_DATA) $$files "$(DESTDIR)$(infodir)" || exit $$?; done
++	@$(POST_INSTALL)
++	@if (install-info --version && \
++	     install-info --version 2>&1 | sed 1q | grep -i -v debian) >/dev/null 2>&1; then \
++	  list='$(INFO_DEPS)'; test -n "$(infodir)" || list=; \
++	  for file in $$list; do \
++	    relfile=`echo "$$file" | sed 's|^.*/||'`; \
++	    echo " install-info --info-dir='$(DESTDIR)$(infodir)' '$(DESTDIR)$(infodir)/$$relfile'";\
++	    install-info --info-dir="$(DESTDIR)$(infodir)" "$(DESTDIR)$(infodir)/$$relfile" || :;\
++	  done; \
++	else : ; fi
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am: $(PDFS)
++	@$(NORMAL_INSTALL)
++	test -z "$(pdfdir)" || $(MKDIR_P) "$(DESTDIR)$(pdfdir)"
++	@list='$(PDFS)'; test -n "$(pdfdir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(pdfdir)'"; \
++	  $(INSTALL_DATA) $$files "$(DESTDIR)$(pdfdir)" || exit $$?; done
++install-ps: install-ps-am
++
++install-ps-am: $(PSS)
++	@$(NORMAL_INSTALL)
++	test -z "$(psdir)" || $(MKDIR_P) "$(DESTDIR)$(psdir)"
++	@list='$(PSS)'; test -n "$(psdir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(psdir)'"; \
++	  $(INSTALL_DATA) $$files "$(DESTDIR)$(psdir)" || exit $$?; done
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-aminfo \
++	maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-aminfo mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am: $(PDFS)
++
++ps: ps-am
++
++ps-am: $(PSS)
++
++uninstall-am: uninstall-dvi-am uninstall-html-am uninstall-info-am \
++	uninstall-pdf-am uninstall-ps-am
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: all all-am all-local check check-am check-local clean \
++	clean-aminfo clean-generic clean-libtool dist-hook dist-info \
++	distclean distclean-generic distclean-libtool distdir dvi \
++	dvi-am html html-am info info-am install install-am \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-man install-pdf install-pdf-am install-ps \
++	install-ps-am install-strip installcheck installcheck-am \
++	installdirs maintainer-clean maintainer-clean-aminfo \
++	maintainer-clean-generic mostlyclean mostlyclean-aminfo \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	uninstall uninstall-am uninstall-dvi-am uninstall-hook \
++	uninstall-html-am uninstall-info-am uninstall-pdf-am \
++	uninstall-ps-am
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++hcrypto.dxy: hcrypto.din Makefile
++	$(dxy_subst) < $(srcdir)/hcrypto.din > hcrypto.dxy.tmp
++	chmod +x hcrypto.dxy.tmp
++	mv hcrypto.dxy.tmp hcrypto.dxy
++
++hdb.dxy: hdb.din Makefile
++	$(dxy_subst) < $(srcdir)/hdb.din > hdb.dxy.tmp
++	chmod +x hdb.dxy.tmp
++	mv hdb.dxy.tmp hdb.dxy
++
++hx509.dxy: hx509.din Makefile
++	$(dxy_subst) < $(srcdir)/hx509.din > hx509.dxy.tmp
++	chmod +x hx509.dxy.tmp
++	mv hx509.dxy.tmp hx509.dxy
++
++gssapi.dxy: gssapi.din Makefile
++	$(dxy_subst) < $(srcdir)/gssapi.din > gssapi.dxy.tmp
++	chmod +x gssapi.dxy.tmp
++	mv gssapi.dxy.tmp gssapi.dxy
++
++krb5.dxy: krb5.din Makefile
++	$(dxy_subst) < $(srcdir)/krb5.din > krb5.dxy.tmp
++	chmod +x krb5.dxy.tmp
++	mv krb5.dxy.tmp krb5.dxy
++
++ntlm.dxy: ntlm.din Makefile
++	$(dxy_subst) < $(srcdir)/ntlm.din > ntlm.dxy.tmp
++	chmod +x ntlm.dxy.tmp
++	mv ntlm.dxy.tmp ntlm.dxy
++
++wind.dxy: wind.din Makefile
++	$(dxy_subst) < $(srcdir)/wind.din > wind.dxy.tmp
++	chmod +x wind.dxy.tmp
++	mv wind.dxy.tmp wind.dxy
++
++vars.texi: vars.tin Makefile
++	$(texi_subst) < $(srcdir)/vars.tin > vars.texi.tmp
++	chmod +x vars.texi.tmp
++	mv vars.texi.tmp vars.texi
++
++doxyout doxygen: hdb.dxy hx509.dxy hcrypto.dxy gssapi.dxy krb5.dxy ntlm.dxy wind.dxy
++	@find $(srcdir)/doxyout -type d ! -perm -200 -exec chmod u+w {} ';' ; \
++	rm -rf $(srcdir)/doxyout ; \
++	mkdir $(srcdir)/doxyout ; \
++	for a in $(PROJECTS) ; do \
++		echo $$a ; \
++		doxygen $$a.dxy; \
++		(cd $(srcdir)/doxyout && find $$a/man -type f > $$a/manpages ) ; \
++	done
++
++install-data-hook: install-doxygen-manpage
++uninstall-hook: uninstall-doxygen-manpage
++dist-hook: doxygen
++
++install-doxygen-manpage:
++	for a in $(PROJECTS) ; do \
++		f="$(srcdir)/doxyout/$$a/manpages" ; \
++		test -f $$f || continue ; \
++		echo "install $$a manual pages $$(wc -l < $$f)" ; \
++		while read x ; do \
++			section=`echo "$$x" | sed 's/.*\.\([0-9]\)/\1/'` ; \
++			$(mkinstalldirs) "$(DESTDIR)$(mandir)/man$$section" ; \
++			$(INSTALL_DATA) $(srcdir)/doxyout/$$x "$(DESTDIR)$(mandir)/man$$section" ; \
++		done < $$f ; \
++	done ; exit 0
++
++uninstall-doxygen-manpage:
++	@for a in $(PROJECTS) ; do \
++		f="$(srcdir)/doxyout/$$a/manpages" ; \
++		test -f $$f || continue ; \
++		echo "removing $$a manual pages" ; \
++		while read x ; do \
++			section=`echo "$$x" | sed 's/.*\.\([0-9]\)/\1/'` ; \
++			base=`basename $$x` ; \
++			rm "$(DESTDIR)$(mandir)/man$$section/$$base" ; \
++		done < $$f ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/etc/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/etc/Makefile.in	2010-12-29 04:07:05.594935290 +0100
+@@ -0,0 +1,709 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = etc
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++EXTRA_DIST = services.append
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign etc/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign etc/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: all all-am all-local check check-am check-local clean \
++	clean-generic clean-libtool dist-hook distclean \
++	distclean-generic distclean-libtool distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/include/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/include/Makefile.in	2010-12-29 04:07:05.794998180 +0100
+@@ -0,0 +1,1134 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(noinst_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(srcdir)/config.h.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++noinst_PROGRAMS = bits$(EXEEXT)
++subdir = include
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++PROGRAMS = $(noinst_PROGRAMS)
++bits_SOURCES = bits.c
++bits_OBJECTS = bits.$(OBJEXT)
++bits_LDADD = $(LDADD)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = bits.c
++DIST_SOURCES = bits.c
++RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \
++	html-recursive info-recursive install-data-recursive \
++	install-dvi-recursive install-exec-recursive \
++	install-html-recursive install-info-recursive \
++	install-pdf-recursive install-ps-recursive install-recursive \
++	installcheck-recursive installdirs-recursive pdf-recursive \
++	ps-recursive uninstall-recursive
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(includedir)"
++HEADERS = $(nodist_include_HEADERS) $(noinst_HEADERS)
++RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive	\
++  distclean-recursive maintainer-clean-recursive
++AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \
++	$(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS \
++	distdir
++ETAGS = etags
++CTAGS = ctags
++DIST_SUBDIRS = $(SUBDIRS)
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++am__relativize = \
++  dir0=`pwd`; \
++  sed_first='s,^\([^/]*\)/.*$$,\1,'; \
++  sed_rest='s,^[^/]*/*,,'; \
++  sed_last='s,^.*/\([^/]*\)$$,\1,'; \
++  sed_butlast='s,/*[^/]*$$,,'; \
++  while test -n "$$dir1"; do \
++    first=`echo "$$dir1" | sed -e "$$sed_first"`; \
++    if test "$$first" != "."; then \
++      if test "$$first" = ".."; then \
++        dir2=`echo "$$dir0" | sed -e "$$sed_last"`/"$$dir2"; \
++        dir0=`echo "$$dir0" | sed -e "$$sed_butlast"`; \
++      else \
++        first2=`echo "$$dir2" | sed -e "$$sed_first"`; \
++        if test "$$first2" = "$$first"; then \
++          dir2=`echo "$$dir2" | sed -e "$$sed_rest"`; \
++        else \
++          dir2="../$$dir2"; \
++        fi; \
++        dir0="$$dir0"/"$$first"; \
++      fi; \
++    fi; \
++    dir1=`echo "$$dir1" | sed -e "$$sed_rest"`; \
++  done; \
++  reldir="$$dir2"
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) -DHOST=\"$(CANONICAL_HOST)\"
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++SUBDIRS = kadm5 hcrypto gssapi
++CHECK_LOCAL = no-check-local
++nodist_include_HEADERS = krb5-types.h
++noinst_HEADERS = heim_threads.h crypto-headers.h
++EXTRA_DIST = krb5-types.cross
++CLEANFILES = \
++	asn1.h			\
++	asn1-common.h		\
++	asn1-template.h		\
++	asn1_err.h		\
++	base64.h		\
++	cms_asn1.h 		\
++	crmf_asn1.h		\
++	com_err.h		\
++	com_right.h		\
++	ccache_plugin.h		\
++	der-protos.h 		\
++	der-private.h 		\
++	der.h			\
++	digest_asn1.h 		\
++	editline.h		\
++	err.h			\
++	getarg.h		\
++	glob.h			\
++	gssapi.h		\
++	hdb-protos.h		\
++	hdb.h			\
++	hdb_asn1.h		\
++	hdb_err.h		\
++	heim-ipc.h		\
++	heim_asn1.h		\
++	heim_err.h		\
++	heimbase.h		\
++	heimntlm-protos.h	\
++	heimntlm.h		\
++	hex.h			\
++	hx509-protos.h		\
++	hx509.h			\
++	hx509_err.h		\
++	k524_err.h		\
++	kafs.h			\
++	kdc-protos.h		\
++	kdc.h			\
++	krb5-private.h		\
++	krb5-protos.h		\
++	krb5-types.h		\
++	krb5.h			\
++	krb5_asn1.h		\
++	krb5_ccapi.h		\
++	krb5_err.h		\
++	krb_err.h		\
++	kx509_asn1.h		\
++	kx509_err.h		\
++	locate_plugin.h		\
++	ntlm_err.h		\
++	ocsp_asn1.h		\
++	otp.h			\
++	parse_bytes.h		\
++	parse_time.h		\
++	parse_units.h		\
++	pkcs10_asn1.h		\
++	pkcs12_asn1.h		\
++	pkcs8_asn1.h		\
++	pkcs9_asn1.h		\
++	pkinit_asn1.h		\
++	resolve.h		\
++	rfc2459_asn1.h		\
++	roken-common.h		\
++	roken.h			\
++	rtbl.h			\
++	send_to_kdc_plugin.h	\
++	sl.h			\
++	test-mem.h		\
++	vers.h			\
++	vis.h			\
++	wind.h			\
++	wind_err.h		\
++	windc_plugin.h		\
++	xdbm.h
++
++DISTCLEANFILES = \
++	version.h	\
++	version.h.in
++
++all: config.h
++	$(MAKE) $(AM_MAKEFLAGS) all-recursive
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign include/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign include/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++config.h: stamp-h1
++	@if test ! -f $@; then \
++	  rm -f stamp-h1; \
++	  $(MAKE) $(AM_MAKEFLAGS) stamp-h1; \
++	else :; fi
++
++stamp-h1: $(srcdir)/config.h.in $(top_builddir)/config.status
++	@rm -f stamp-h1
++	cd $(top_builddir) && $(SHELL) ./config.status include/config.h
++$(srcdir)/config.h.in: @MAINTAINER_MODE_TRUE@ $(am__configure_deps) 
++	($(am__cd) $(top_srcdir) && $(AUTOHEADER))
++	rm -f stamp-h1
++	touch $@
++
++distclean-hdr:
++	-rm -f config.h stamp-h1
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++bits$(EXEEXT): $(bits_OBJECTS) $(bits_DEPENDENCIES) 
++	@rm -f bits$(EXEEXT)
++	$(LINK) $(bits_OBJECTS) $(bits_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/bits.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-nodist_includeHEADERS: $(nodist_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-nodist_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++
++# This directory's subdirectories are mostly independent; you can cd
++# into them and run `make' without going through this Makefile.
++# To change the values of `make' variables: instead of editing Makefiles,
++# (1) if the variable is set in `config.status', edit `config.status'
++#     (which will cause the Makefiles to be regenerated when you run `make');
++# (2) otherwise, pass the desired values on the `make' command line.
++$(RECURSIVE_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	target=`echo $@ | sed s/-recursive//`; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    dot_seen=yes; \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done; \
++	if test "$$dot_seen" = "no"; then \
++	  $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
++	fi; test -z "$$fail"
++
++$(RECURSIVE_CLEAN_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	case "$@" in \
++	  distclean-* | maintainer-clean-*) list='$(DIST_SUBDIRS)' ;; \
++	  *) list='$(SUBDIRS)' ;; \
++	esac; \
++	rev=''; for subdir in $$list; do \
++	  if test "$$subdir" = "."; then :; else \
++	    rev="$$subdir $$rev"; \
++	  fi; \
++	done; \
++	rev="$$rev ."; \
++	target=`echo $@ | sed s/-recursive//`; \
++	for subdir in $$rev; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done && test -z "$$fail"
++tags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
++	done
++ctags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) ctags); \
++	done
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS: tags-recursive $(HEADERS) $(SOURCES) config.h.in $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	if ($(ETAGS) --etags-include --version) >/dev/null 2>&1; then \
++	  include_option=--etags-include; \
++	  empty_fix=.; \
++	else \
++	  include_option=--include; \
++	  empty_fix=; \
++	fi; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test ! -f $$subdir/TAGS || \
++	      set "$$@" "$$include_option=$$here/$$subdir/TAGS"; \
++	  fi; \
++	done; \
++	list='$(SOURCES) $(HEADERS) config.h.in $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS: ctags-recursive $(HEADERS) $(SOURCES) config.h.in $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS) config.h.in $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test -d "$(distdir)/$$subdir" \
++	    || $(MKDIR_P) "$(distdir)/$$subdir" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    dir1=$$subdir; dir2="$(distdir)/$$subdir"; \
++	    $(am__relativize); \
++	    new_distdir=$$reldir; \
++	    dir1=$$subdir; dir2="$(top_distdir)"; \
++	    $(am__relativize); \
++	    new_top_distdir=$$reldir; \
++	    echo " (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir="$$new_top_distdir" distdir="$$new_distdir" \\"; \
++	    echo "     am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)"; \
++	    ($(am__cd) $$subdir && \
++	      $(MAKE) $(AM_MAKEFLAGS) \
++	        top_distdir="$$new_top_distdir" \
++	        distdir="$$new_distdir" \
++		am__remove_distdir=: \
++		am__skip_length_check=: \
++		am__skip_mode_fix=: \
++	        distdir) \
++	      || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-recursive
++all-am: Makefile $(PROGRAMS) $(HEADERS) config.h all-local
++installdirs: installdirs-recursive
++installdirs-am:
++	for dir in "$(DESTDIR)$(includedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-recursive
++install-exec: install-exec-recursive
++install-data: install-data-recursive
++uninstall: uninstall-recursive
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-recursive
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++	-test -z "$(DISTCLEANFILES)" || rm -f $(DISTCLEANFILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-recursive
++
++clean-am: clean-generic clean-libtool clean-noinstPROGRAMS \
++	mostlyclean-am
++
++distclean: distclean-recursive
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-hdr distclean-tags
++
++dvi: dvi-recursive
++
++dvi-am:
++
++html: html-recursive
++
++html-am:
++
++info: info-recursive
++
++info-am:
++
++install-data-am: install-nodist_includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-recursive
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-recursive
++
++install-html-am:
++
++install-info: install-info-recursive
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-recursive
++
++install-pdf-am:
++
++install-ps: install-ps-recursive
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-recursive
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-recursive
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-recursive
++
++pdf-am:
++
++ps: ps-recursive
++
++ps-am:
++
++uninstall-am: uninstall-nodist_includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) all check-am \
++	ctags-recursive install-am install-data-am install-exec-am \
++	install-strip tags-recursive uninstall-am
++
++.PHONY: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) CTAGS GTAGS \
++	all all-am all-local check check-am check-local clean \
++	clean-generic clean-libtool clean-noinstPROGRAMS ctags \
++	ctags-recursive dist-hook distclean distclean-compile \
++	distclean-generic distclean-hdr distclean-libtool \
++	distclean-tags distdir dvi dvi-am html html-am info info-am \
++	install install-am install-data install-data-am \
++	install-data-hook install-dvi install-dvi-am install-exec \
++	install-exec-am install-exec-hook install-html install-html-am \
++	install-info install-info-am install-man \
++	install-nodist_includeHEADERS install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs installdirs-am maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags tags-recursive uninstall uninstall-am uninstall-hook \
++	uninstall-nodist_includeHEADERS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++@CROSS_COMPILE_FALSE@krb5-types.h: bits$(EXEEXT)
++@CROSS_COMPILE_FALSE@	./bits$(EXEEXT) krb5-types.h
++
++@CROSS_COMPILE_TRUE@krb5-types.h: krb5-types.cross
++@CROSS_COMPILE_TRUE@	cp $(srcdir)/krb5-types.cross krb5-types.h
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/include/config.h.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/include/config.h.in	2010-12-29 04:04:06.000000000 +0100
+@@ -0,0 +1,1607 @@
++/* include/config.h.in.  Generated from configure.ac by autoheader.  */
++
++#ifndef RCSID
++#define RCSID(msg) \
++static /**/const char *const rcsid[] = { (const char *)rcsid, "@(#)" msg }
++#endif
++
++/* Maximum values on all known systems */
++#define MaxHostNameLen (64+4)
++#define MaxPathLen (1024+4)
++
++
++
++#ifdef BUILD_KRB5_LIB
++#ifndef KRB5_LIB
++#ifdef _WIN32_
++#define KRB5_LIB_FUNCTION __declspec(dllexport)
++#define KRB5_LIB_CALL __stdcall
++#define KRB5_LIB_VARIABLE __declspec(dllexport)
++#else
++#define KRB5_LIB_FUNCTION
++#define KRB5_LIB_CALL
++#define KRB5_LIB_VARIABLE
++#endif
++#endif
++#endif
++
++
++#ifdef BUILD_ROKEN_LIB
++#ifndef ROKEN_LIB
++#ifdef _WIN32_
++#define ROKEN_LIB_FUNCTION __declspec(dllexport)
++#define ROKEN_LIB_CALL __stdcall
++#define ROKEN_LIB_VARIABLE __declspec(dllexport)
++#else
++#define ROKEN_LIB_FUNCTION
++#define ROKEN_LIB_CALL
++#define ROKEN_LIB_VARIABLE
++#endif
++#endif
++#endif
++
++
++#ifdef BUILD_GSSAPI_LIB
++#ifndef GSSAPI_LIB
++#ifdef _WIN32_
++#define GSSAPI_LIB_FUNCTION __declspec(dllexport)
++#define GSSAPI_LIB_CALL __stdcall
++#define GSSAPI_LIB_VARIABLE __declspec(dllexport)
++#else
++#define GSSAPI_LIB_FUNCTION
++#define GSSAPI_LIB_CALL
++#define GSSAPI_LIB_VARIABLE
++#endif
++#endif
++#endif
++
++
++/* Define if you want authentication support in telnet. */
++#undef AUTHENTICATION
++
++/* path to bin */
++#undef BINDIR
++
++/* Define if realloc(NULL) doesn't work. */
++#undef BROKEN_REALLOC
++
++/* Define if you want support for DCE/DFS PAG's. */
++#undef DCE
++
++/* Define if you want to use DES encryption in telnet. */
++#undef DES_ENCRYPTION
++
++/* Define this to enable diagnostics in telnet. */
++#undef DIAGNOSTICS
++
++/* Define to enable DIGEST. */
++#undef DIGEST
++
++/* Define if want to use the weak AFS string to key functions. */
++#undef ENABLE_AFS_STRING_TO_KEY
++
++/* Define if you want have a thread safe libraries */
++#undef ENABLE_PTHREAD_SUPPORT
++
++/* Define if you want encryption support in telnet. */
++#undef ENCRYPTION
++
++/* define if sys/param.h defines the endiness */
++#undef ENDIANESS_IN_SYS_PARAM_H
++
++/* Define this if you want support for broken ENV_{VAR,VAL} telnets. */
++#undef ENV_HACK
++
++/* define if prototype of gethostbyaddr is compatible with struct hostent
++   *gethostbyaddr(const void *, size_t, int) */
++#undef GETHOSTBYADDR_PROTO_COMPATIBLE
++
++/* define if prototype of gethostbyname is compatible with struct hostent
++   *gethostbyname(const char *) */
++#undef GETHOSTBYNAME_PROTO_COMPATIBLE
++
++/* define if prototype of getservbyname is compatible with struct servent
++   *getservbyname(const char *, const char *) */
++#undef GETSERVBYNAME_PROTO_COMPATIBLE
++
++/* define if prototype of getsockname is compatible with int getsockname(int,
++   struct sockaddr*, socklen_t*) */
++#undef GETSOCKNAME_PROTO_COMPATIBLE
++
++/* Define if you have the `altzone' variable. */
++#undef HAVE_ALTZONE
++
++/* Define to 1 if you have the `arc4random' function. */
++#undef HAVE_ARC4RANDOM
++
++/* Define to 1 if you have the <arpa/ftp.h> header file. */
++#undef HAVE_ARPA_FTP_H
++
++/* Define to 1 if you have the <arpa/inet.h> header file. */
++#undef HAVE_ARPA_INET_H
++
++/* Define to 1 if you have the <arpa/nameser.h> header file. */
++#undef HAVE_ARPA_NAMESER_H
++
++/* Define to 1 if you have the <arpa/telnet.h> header file. */
++#undef HAVE_ARPA_TELNET_H
++
++/* Define to 1 if you have the <asl.h> header file. */
++#undef HAVE_ASL_H
++
++/* Define to 1 if you have the `asnprintf' function. */
++#undef HAVE_ASNPRINTF
++
++/* Define to 1 if you have the `asprintf' function. */
++#undef HAVE_ASPRINTF
++
++/* Define to 1 if you have the `atexit' function. */
++#undef HAVE_ATEXIT
++
++/* Define to 1 if you have the <bind/bitypes.h> header file. */
++#undef HAVE_BIND_BITYPES_H
++
++/* Define to 1 if you have the <bsdsetjmp.h> header file. */
++#undef HAVE_BSDSETJMP_H
++
++/* Define to 1 if you have the `bswap16' function. */
++#undef HAVE_BSWAP16
++
++/* Define to 1 if you have the `bswap32' function. */
++#undef HAVE_BSWAP32
++
++/* Define to 1 if you have the <capability.h> header file. */
++#undef HAVE_CAPABILITY_H
++
++/* whether capng is available for privilege reduction */
++#undef HAVE_CAPNG
++
++/* Define to 1 if you have the `cap_set_proc' function. */
++#undef HAVE_CAP_SET_PROC
++
++/* Define to 1 if you have the `cgetent' function. */
++#undef HAVE_CGETENT
++
++/* Define if you have the function `chown'. */
++#undef HAVE_CHOWN
++
++/* Define if you have the function `closefrom'. */
++#undef HAVE_CLOSEFROM
++
++/* Define to 1 if you have the <CommonCrypto/CommonCryptor.h> header file. */
++#undef HAVE_COMMONCRYPTO_COMMONCRYPTOR_H
++
++/* Define to 1 if you have the <CommonCrypto/CommonDigest.h> header file. */
++#undef HAVE_COMMONCRYPTO_COMMONDIGEST_H
++
++/* Define to 1 if you have the <config.h> header file. */
++#undef HAVE_CONFIG_H
++
++/* Define if you have the function `copyhostent'. */
++#undef HAVE_COPYHOSTENT
++
++/* Define to 1 if you have the `crypt' function. */
++#undef HAVE_CRYPT
++
++/* Define to 1 if you have the <crypt.h> header file. */
++#undef HAVE_CRYPT_H
++
++/* Define to 1 if you have the <curses.h> header file. */
++#undef HAVE_CURSES_H
++
++/* Define if you have the function `daemon'. */
++#undef HAVE_DAEMON
++
++/* define if you have a berkeley db1/2 library */
++#undef HAVE_DB1
++
++/* define if you have a berkeley db3/4/5 library */
++#undef HAVE_DB3
++
++/* Define to 1 if you have the <db3/db.h> header file. */
++#undef HAVE_DB3_DB_H
++
++/* Define to 1 if you have the <db4/db.h> header file. */
++#undef HAVE_DB4_DB_H
++
++/* Define to 1 if you have the <db5/db.h> header file. */
++#undef HAVE_DB5_DB_H
++
++/* Define if you have user supplied header location */
++#undef HAVE_DBHEADER
++
++/* Define to 1 if you have the `dbm_firstkey' function. */
++#undef HAVE_DBM_FIRSTKEY
++
++/* Define to 1 if you have the <dbm.h> header file. */
++#undef HAVE_DBM_H
++
++/* Define to 1 if you have the `dbopen' function. */
++#undef HAVE_DBOPEN
++
++/* Define to 1 if you have the <db_185.h> header file. */
++#undef HAVE_DB_185_H
++
++/* Define to 1 if you have the `db_create' function. */
++#undef HAVE_DB_CREATE
++
++/* Define to 1 if you have the <db.h> header file. */
++#undef HAVE_DB_H
++
++/* define if you have ndbm compat in db */
++#undef HAVE_DB_NDBM
++
++/* Define to 1 if you have the declaration of `altzone', and to 0 if you
++   don't. */
++#undef HAVE_DECL_ALTZONE
++
++/* Define to 1 if you have the declaration of `environ', and to 0 if you
++   don't. */
++#undef HAVE_DECL_ENVIRON
++
++/* Define to 1 if you have the declaration of `h_errlist', and to 0 if you
++   don't. */
++#undef HAVE_DECL_H_ERRLIST
++
++/* Define to 1 if you have the declaration of `h_errno', and to 0 if you
++   don't. */
++#undef HAVE_DECL_H_ERRNO
++
++/* Define to 1 if you have the declaration of `h_nerr', and to 0 if you don't.
++   */
++#undef HAVE_DECL_H_NERR
++
++/* Define to 1 if you have the declaration of `optarg', and to 0 if you don't.
++   */
++#undef HAVE_DECL_OPTARG
++
++/* Define to 1 if you have the declaration of `opterr', and to 0 if you don't.
++   */
++#undef HAVE_DECL_OPTERR
++
++/* Define to 1 if you have the declaration of `optind', and to 0 if you don't.
++   */
++#undef HAVE_DECL_OPTIND
++
++/* Define to 1 if you have the declaration of `optopt', and to 0 if you don't.
++   */
++#undef HAVE_DECL_OPTOPT
++
++/* Define to 1 if you have the declaration of `timezone', and to 0 if you
++   don't. */
++#undef HAVE_DECL_TIMEZONE
++
++/* Define to 1 if you have the declaration of `_res', and to 0 if you don't.
++   */
++#undef HAVE_DECL__RES
++
++/* Define to 1 if you have the declaration of `__progname', and to 0 if you
++   don't. */
++#undef HAVE_DECL___PROGNAME
++
++/* Define to 1 if you have the <dirent.h> header file. */
++#undef HAVE_DIRENT_H
++
++/* have a dirfd function/macro */
++#undef HAVE_DIRFD
++
++/* Define if DIR has field dd_fd. */
++#undef HAVE_DIR_DD_FD
++
++/* Define to 1 if you have the `dispatch_async_f' function. */
++#undef HAVE_DISPATCH_ASYNC_F
++
++/* Define to 1 if you have the <dispatch/dispatch.h> header file. */
++#undef HAVE_DISPATCH_DISPATCH_H
++
++/* Define to 1 if you have the <dlfcn.h> header file. */
++#undef HAVE_DLFCN_H
++
++/* Define to 1 if you have the `dlopen' function. */
++#undef HAVE_DLOPEN
++
++/* Define to 1 if you have the <dns.h> header file. */
++#undef HAVE_DNS_H
++
++/* Define to 1 if you have the `dns_search' function. */
++#undef HAVE_DNS_SEARCH
++
++/* Define to 1 if you have the `dn_expand' function. */
++#undef HAVE_DN_EXPAND
++
++/* Define to 1 if you have the `door_create' function. */
++#undef HAVE_DOOR_CREATE
++
++/* Define if you have the function `ecalloc'. */
++#undef HAVE_ECALLOC
++
++/* Define to 1 if you have the `el_init' function. */
++#undef HAVE_EL_INIT
++
++/* Define if you have the function `emalloc'. */
++#undef HAVE_EMALLOC
++
++/* Define if you have the function `erealloc'. */
++#undef HAVE_EREALLOC
++
++/* Define if you have the function `err'. */
++#undef HAVE_ERR
++
++/* Define to 1 if you have the <errno.h> header file. */
++#undef HAVE_ERRNO_H
++
++/* Define if you have the function `errx'. */
++#undef HAVE_ERRX
++
++/* Define to 1 if you have the <err.h> header file. */
++#undef HAVE_ERR_H
++
++/* Define if you have the function `estrdup'. */
++#undef HAVE_ESTRDUP
++
++/* Define if you have the function `fchown'. */
++#undef HAVE_FCHOWN
++
++/* Define to 1 if you have the `fcntl' function. */
++#undef HAVE_FCNTL
++
++/* Define to 1 if you have the <fcntl.h> header file. */
++#undef HAVE_FCNTL_H
++
++/* Define if you have the function `flock'. */
++#undef HAVE_FLOCK
++
++/* Define if you have the function `fnmatch'. */
++#undef HAVE_FNMATCH
++
++/* Define to 1 if you have the <fnmatch.h> header file. */
++#undef HAVE_FNMATCH_H
++
++/* Define if el_init takes four arguments. */
++#undef HAVE_FOUR_VALUED_EL_INIT
++
++/* Have -framework Security */
++#undef HAVE_FRAMEWORK_SECURITY
++
++/* Define to 1 if you have the `freeaddrinfo' function. */
++#undef HAVE_FREEADDRINFO
++
++/* Define if you have the function `freehostent'. */
++#undef HAVE_FREEHOSTENT
++
++/* Define to 1 if you have the `gai_strerror' function. */
++#undef HAVE_GAI_STRERROR
++
++/* Define if os support gcd. */
++#undef HAVE_GCD
++
++/* Define to 1 if you have the <gdbm/ndbm.h> header file. */
++#undef HAVE_GDBM_NDBM_H
++
++/* Define to 1 if you have the `getaddrinfo' function. */
++#undef HAVE_GETADDRINFO
++
++/* Define to 1 if you have the `getconfattr' function. */
++#undef HAVE_GETCONFATTR
++
++/* Define if you have the function `getcwd'. */
++#undef HAVE_GETCWD
++
++/* Define if you have the function `getdtablesize'. */
++#undef HAVE_GETDTABLESIZE
++
++/* Define if you have the function `getegid'. */
++#undef HAVE_GETEGID
++
++/* Define if you have the function `geteuid'. */
++#undef HAVE_GETEUID
++
++/* Define if you have the function `getgid'. */
++#undef HAVE_GETGID
++
++/* Define to 1 if you have the `gethostbyname' function. */
++#undef HAVE_GETHOSTBYNAME
++
++/* Define to 1 if you have the `gethostbyname2' function. */
++#undef HAVE_GETHOSTBYNAME2
++
++/* Define if you have the function `gethostname'. */
++#undef HAVE_GETHOSTNAME
++
++/* Define if you have the function `getifaddrs'. */
++#undef HAVE_GETIFADDRS
++
++/* Define if you have the function `getipnodebyaddr'. */
++#undef HAVE_GETIPNODEBYADDR
++
++/* Define if you have the function `getipnodebyname'. */
++#undef HAVE_GETIPNODEBYNAME
++
++/* Define to 1 if you have the `getlogin' function. */
++#undef HAVE_GETLOGIN
++
++/* Define if you have a working getmsg. */
++#undef HAVE_GETMSG
++
++/* Define to 1 if you have the `getnameinfo' function. */
++#undef HAVE_GETNAMEINFO
++
++/* Define if you have the function `getopt'. */
++#undef HAVE_GETOPT
++
++/* Define to 1 if you have the `getpagesize' function. */
++#undef HAVE_GETPAGESIZE
++
++/* Define to 1 if you have the `getpeereid' function. */
++#undef HAVE_GETPEEREID
++
++/* Define to 1 if you have the `getpeerucred' function. */
++#undef HAVE_GETPEERUCRED
++
++/* Define to 1 if you have the `getprogname' function. */
++#undef HAVE_GETPROGNAME
++
++/* Define to 1 if you have the `getpwnam_r' function. */
++#undef HAVE_GETPWNAM_R
++
++/* Define to 1 if you have the `getrlimit' function. */
++#undef HAVE_GETRLIMIT
++
++/* Define to 1 if you have the `getsockopt' function. */
++#undef HAVE_GETSOCKOPT
++
++/* Define to 1 if you have the `getspnam' function. */
++#undef HAVE_GETSPNAM
++
++/* Define if you have the function `gettimeofday'. */
++#undef HAVE_GETTIMEOFDAY
++
++/* Define to 1 if you have the `getudbnam' function. */
++#undef HAVE_GETUDBNAM
++
++/* Define if you have the function `getuid'. */
++#undef HAVE_GETUID
++
++/* Define if you have the function `getusershell'. */
++#undef HAVE_GETUSERSHELL
++
++/* define if you have a glob() that groks GLOB_BRACE, GLOB_NOCHECK,
++   GLOB_QUOTE, GLOB_TILDE, and GLOB_LIMIT */
++#undef HAVE_GLOB
++
++/* Define to 1 if you have the `grantpt' function. */
++#undef HAVE_GRANTPT
++
++/* Define to 1 if you have the <grp.h> header file. */
++#undef HAVE_GRP_H
++
++/* Define to 1 if you have the `hstrerror' function. */
++#undef HAVE_HSTRERROR
++
++/* Define if you have the `h_errlist' variable. */
++#undef HAVE_H_ERRLIST
++
++/* Define if you have the `h_errno' variable. */
++#undef HAVE_H_ERRNO
++
++/* Define if you have the `h_nerr' variable. */
++#undef HAVE_H_NERR
++
++/* Define to 1 if you have the <ifaddrs.h> header file. */
++#undef HAVE_IFADDRS_H
++
++/* Define if you have the in6addr_loopback variable */
++#undef HAVE_IN6ADDR_LOOPBACK
++
++/* define */
++#undef HAVE_INET_ATON
++
++/* define */
++#undef HAVE_INET_NTOP
++
++/* define */
++#undef HAVE_INET_PTON
++
++/* Define if you have the function `initgroups'. */
++#undef HAVE_INITGROUPS
++
++/* Define to 1 if you have the `initstate' function. */
++#undef HAVE_INITSTATE
++
++/* Define if you have the function `innetgr'. */
++#undef HAVE_INNETGR
++
++/* Define to 1 if the system has the type `int16_t'. */
++#undef HAVE_INT16_T
++
++/* Define to 1 if the system has the type `int32_t'. */
++#undef HAVE_INT32_T
++
++/* Define to 1 if the system has the type `int64_t'. */
++#undef HAVE_INT64_T
++
++/* Define to 1 if the system has the type `int8_t'. */
++#undef HAVE_INT8_T
++
++/* Define to 1 if you have the <inttypes.h> header file. */
++#undef HAVE_INTTYPES_H
++
++/* Define to 1 if you have the <io.h> header file. */
++#undef HAVE_IO_H
++
++/* Define if you have IPv6. */
++#undef HAVE_IPV6
++
++/* Define if you have the function `iruserok'. */
++#undef HAVE_IRUSEROK
++
++/* Define to 1 if you have the `issetugid' function. */
++#undef HAVE_ISSETUGID
++
++/* Define if you want to use the Kerberos Credentials Manager. */
++#undef HAVE_KCM
++
++/* Define to 1 if you have the <libutil.h> header file. */
++#undef HAVE_LIBUTIL_H
++
++/* Define to 1 if you have the <limits.h> header file. */
++#undef HAVE_LIMITS_H
++
++/* Define to 1 if you have the `loadquery' function. */
++#undef HAVE_LOADQUERY
++
++/* Define to 1 if you have the <locale.h> header file. */
++#undef HAVE_LOCALE_H
++
++/* Define if you have the function `localtime_r'. */
++#undef HAVE_LOCALTIME_R
++
++/* Define to 1 if you have the `logout' function. */
++#undef HAVE_LOGOUT
++
++/* Define to 1 if you have the `logwtmp' function. */
++#undef HAVE_LOGWTMP
++
++/* Define to 1 if the system has the type `long long'. */
++#undef HAVE_LONG_LONG
++
++/* Define if you have the function `lstat'. */
++#undef HAVE_LSTAT
++
++/* Define to 1 if you have the <maillock.h> header file. */
++#undef HAVE_MAILLOCK_H
++
++/* Define if you have the function `memmove'. */
++#undef HAVE_MEMMOVE
++
++/* Define to 1 if you have the <memory.h> header file. */
++#undef HAVE_MEMORY_H
++
++/* Define if you have the function `mkstemp'. */
++#undef HAVE_MKSTEMP
++
++/* Define to 1 if you have the `mktime' function. */
++#undef HAVE_MKTIME
++
++/* Define to 1 if you have a working `mmap' system call. */
++#undef HAVE_MMAP
++
++/* define if you have a ndbm library */
++#undef HAVE_NDBM
++
++/* Define to 1 if you have the <ndbm.h> header file. */
++#undef HAVE_NDBM_H
++
++/* Define to 1 if you have the <netdb.h> header file. */
++#undef HAVE_NETDB_H
++
++/* Define to 1 if you have the <netgroup.h> header file. */
++#undef HAVE_NETGROUP_H
++
++/* Define to 1 if you have the <netinet6/in6.h> header file. */
++#undef HAVE_NETINET6_IN6_H
++
++/* Define to 1 if you have the <netinet6/in6_var.h> header file. */
++#undef HAVE_NETINET6_IN6_VAR_H
++
++/* Define to 1 if you have the <netinet/in6.h> header file. */
++#undef HAVE_NETINET_IN6_H
++
++/* Define to 1 if you have the <netinet/in6_machtypes.h> header file. */
++#undef HAVE_NETINET_IN6_MACHTYPES_H
++
++/* Define to 1 if you have the <netinet/in.h> header file. */
++#undef HAVE_NETINET_IN_H
++
++/* Define to 1 if you have the <netinet/in_systm.h> header file. */
++#undef HAVE_NETINET_IN_SYSTM_H
++
++/* Define to 1 if you have the <netinet/ip.h> header file. */
++#undef HAVE_NETINET_IP_H
++
++/* Define to 1 if you have the <netinet/tcp.h> header file. */
++#undef HAVE_NETINET_TCP_H
++
++/* Define to 1 if you have the <net/if.h> header file. */
++#undef HAVE_NET_IF_H
++
++/* Define if NDBM really is DB (creates files *.db) */
++#undef HAVE_NEW_DB
++
++/* Define to 1 if you have the `on_exit' function. */
++#undef HAVE_ON_EXIT
++
++/* Define to 1 if you have the `openpty' function. */
++#undef HAVE_OPENPTY
++
++/* define to use openssl's libcrypto */
++#undef HAVE_OPENSSL
++
++/* Define to enable basic OSF C2 support. */
++#undef HAVE_OSFC2
++
++/* Define to 1 if you have the <paths.h> header file. */
++#undef HAVE_PATHS_H
++
++/* Define to 1 if you have the `pidfile' function. */
++#undef HAVE_PIDFILE
++
++/* Define to 1 if you have the `poll' function. */
++#undef HAVE_POLL
++
++/* Define to 1 if you have the <poll.h> header file. */
++#undef HAVE_POLL_H
++
++/* Define to 1 if you have the <pthread.h> header file. */
++#undef HAVE_PTHREAD_H
++
++/* Define to 1 if you have the `ptsname' function. */
++#undef HAVE_PTSNAME
++
++/* Define to 1 if you have the <pty.h> header file. */
++#undef HAVE_PTY_H
++
++/* Define if you have the function `putenv'. */
++#undef HAVE_PUTENV
++
++/* Define to 1 if you have the <pwd.h> header file. */
++#undef HAVE_PWD_H
++
++/* Define to 1 if you have the `rand' function. */
++#undef HAVE_RAND
++
++/* Define to 1 if you have the `random' function. */
++#undef HAVE_RANDOM
++
++/* Define if you have the function `rcmd'. */
++#undef HAVE_RCMD
++
++/* Define if you have a readline compatible library. */
++#undef HAVE_READLINE
++
++/* Define if you have the function `readv'. */
++#undef HAVE_READV
++
++/* Define if you have the function `recvmsg'. */
++#undef HAVE_RECVMSG
++
++/* Define to 1 if you have the <resolv.h> header file. */
++#undef HAVE_RESOLV_H
++
++/* Define to 1 if you have the `res_ndestroy' function. */
++#undef HAVE_RES_NDESTROY
++
++/* Define to 1 if you have the `res_nsearch' function. */
++#undef HAVE_RES_NSEARCH
++
++/* Define to 1 if you have the `res_search' function. */
++#undef HAVE_RES_SEARCH
++
++/* Define to 1 if you have the `revoke' function. */
++#undef HAVE_REVOKE
++
++/* Define to 1 if you have the <rpcsvc/ypclnt.h> header file. */
++#undef HAVE_RPCSVC_YPCLNT_H
++
++/* Define to 1 if you have the <sac.h> header file. */
++#undef HAVE_SAC_H
++
++/* Define to 1 if the system has the type `sa_family_t'. */
++#undef HAVE_SA_FAMILY_T
++
++/* Define if you want support for cache in sqlite. */
++#undef HAVE_SCC
++
++/* Define to 1 if you have the <security/pam_modules.h> header file. */
++#undef HAVE_SECURITY_PAM_MODULES_H
++
++/* Define to 1 if you have the `select' function. */
++#undef HAVE_SELECT
++
++/* Define if you have the function `sendmsg'. */
++#undef HAVE_SENDMSG
++
++/* Define if you have the function `setegid'. */
++#undef HAVE_SETEGID
++
++/* Define if you have the function `setenv'. */
++#undef HAVE_SETENV
++
++/* Define if you have the function `seteuid'. */
++#undef HAVE_SETEUID
++
++/* Define to 1 if you have the `setitimer' function. */
++#undef HAVE_SETITIMER
++
++/* Define to 1 if you have the `setlim' function. */
++#undef HAVE_SETLIM
++
++/* Define to 1 if you have the `setlogin' function. */
++#undef HAVE_SETLOGIN
++
++/* Define to 1 if you have the `setpcred' function. */
++#undef HAVE_SETPCRED
++
++/* Define to 1 if you have the `setpgid' function. */
++#undef HAVE_SETPGID
++
++/* Define to 1 if you have the `setproctitle' function. */
++#undef HAVE_SETPROCTITLE
++
++/* Define to 1 if you have the `setprogname' function. */
++#undef HAVE_SETPROGNAME
++
++/* Define to 1 if you have the `setregid' function. */
++#undef HAVE_SETREGID
++
++/* Define to 1 if you have the `setresgid' function. */
++#undef HAVE_SETRESGID
++
++/* Define to 1 if you have the `setresuid' function. */
++#undef HAVE_SETRESUID
++
++/* Define to 1 if you have the `setreuid' function. */
++#undef HAVE_SETREUID
++
++/* Define to 1 if you have the `setsid' function. */
++#undef HAVE_SETSID
++
++/* Define to 1 if you have the `setsockopt' function. */
++#undef HAVE_SETSOCKOPT
++
++/* Define to 1 if you have the `setstate' function. */
++#undef HAVE_SETSTATE
++
++/* Define to 1 if you have the `setutent' function. */
++#undef HAVE_SETUTENT
++
++/* Define to 1 if you have the `sgi_getcapabilitybyname' function. */
++#undef HAVE_SGI_GETCAPABILITYBYNAME
++
++/* Define to 1 if you have the <sgtty.h> header file. */
++#undef HAVE_SGTTY_H
++
++/* Define to 1 if you have the <shadow.h> header file. */
++#undef HAVE_SHADOW_H
++
++/* Define to 1 if you have the <siad.h> header file. */
++#undef HAVE_SIAD_H
++
++/* Define to 1 if you have the `sigaction' function. */
++#undef HAVE_SIGACTION
++
++/* Define to 1 if you have the <signal.h> header file. */
++#undef HAVE_SIGNAL_H
++
++/* define if you have a working snprintf */
++#undef HAVE_SNPRINTF
++
++/* Define to 1 if you have the `socket' function. */
++#undef HAVE_SOCKET
++
++/* Define to 1 if the system has the type `socklen_t'. */
++#undef HAVE_SOCKLEN_T
++
++/* Define to 1 if the system has the type `ssize_t'. */
++#undef HAVE_SSIZE_T
++
++/* Define to 1 if you have the <standards.h> header file. */
++#undef HAVE_STANDARDS_H
++
++/* Define to 1 if you have the <stdint.h> header file. */
++#undef HAVE_STDINT_H
++
++/* Define to 1 if you have the <stdlib.h> header file. */
++#undef HAVE_STDLIB_H
++
++/* Define if you have the function `strcasecmp'. */
++#undef HAVE_STRCASECMP
++
++/* Define if you have the function `strdup'. */
++#undef HAVE_STRDUP
++
++/* Define if you have the function `strerror'. */
++#undef HAVE_STRERROR
++
++/* Define if you have the function strerror_r. */
++#undef HAVE_STRERROR_R
++
++/* Define if you have the function `strftime'. */
++#undef HAVE_STRFTIME
++
++/* Define to 1 if you have the <strings.h> header file. */
++#undef HAVE_STRINGS_H
++
++/* Define to 1 if you have the <string.h> header file. */
++#undef HAVE_STRING_H
++
++/* Define if you have the function `strlcat'. */
++#undef HAVE_STRLCAT
++
++/* Define if you have the function `strlcpy'. */
++#undef HAVE_STRLCPY
++
++/* Define if you have the function `strlwr'. */
++#undef HAVE_STRLWR
++
++/* Define if you have the function `strncasecmp'. */
++#undef HAVE_STRNCASECMP
++
++/* Define if you have the function `strndup'. */
++#undef HAVE_STRNDUP
++
++/* Define if you have the function `strnlen'. */
++#undef HAVE_STRNLEN
++
++/* Define to 1 if you have the <stropts.h> header file. */
++#undef HAVE_STROPTS_H
++
++/* Define if you have the function `strptime'. */
++#undef HAVE_STRPTIME
++
++/* Define if you have the function `strsep'. */
++#undef HAVE_STRSEP
++
++/* Define if you have the function `strsep_copy'. */
++#undef HAVE_STRSEP_COPY
++
++/* Define to 1 if you have the `strstr' function. */
++#undef HAVE_STRSTR
++
++/* Define to 1 if you have the `strsvis' function. */
++#undef HAVE_STRSVIS
++
++/* Define to 1 if you have the `strsvisx' function. */
++#undef HAVE_STRSVISX
++
++/* Define if you have the function `strtok_r'. */
++#undef HAVE_STRTOK_R
++
++/* Define to 1 if the system has the type `struct addrinfo'. */
++#undef HAVE_STRUCT_ADDRINFO
++
++/* Define to 1 if the system has the type `struct ifaddrs'. */
++#undef HAVE_STRUCT_IFADDRS
++
++/* Define to 1 if the system has the type `struct iovec'. */
++#undef HAVE_STRUCT_IOVEC
++
++/* Define to 1 if the system has the type `struct msghdr'. */
++#undef HAVE_STRUCT_MSGHDR
++
++/* Define to 1 if the system has the type `struct sockaddr'. */
++#undef HAVE_STRUCT_SOCKADDR
++
++/* Define if struct sockaddr has field sa_len. */
++#undef HAVE_STRUCT_SOCKADDR_SA_LEN
++
++/* Define to 1 if the system has the type `struct sockaddr_storage'. */
++#undef HAVE_STRUCT_SOCKADDR_STORAGE
++
++/* define if you have struct spwd */
++#undef HAVE_STRUCT_SPWD
++
++/* Define if struct tm has field tm_gmtoff. */
++#undef HAVE_STRUCT_TM_TM_GMTOFF
++
++/* Define if struct tm has field tm_zone. */
++#undef HAVE_STRUCT_TM_TM_ZONE
++
++/* Define if struct utmpx has field ut_exit. */
++#undef HAVE_STRUCT_UTMPX_UT_EXIT
++
++/* Define if struct utmpx has field ut_host. */
++#undef HAVE_STRUCT_UTMPX_UT_HOST
++
++/* Define if struct utmpx has field ut_id. */
++#undef HAVE_STRUCT_UTMPX_UT_ID
++
++/* Define if struct utmpx has field ut_line. */
++#undef HAVE_STRUCT_UTMPX_UT_LINE
++
++/* Define if struct utmpx has field ut_pid. */
++#undef HAVE_STRUCT_UTMPX_UT_PID
++
++/* Define if struct utmpx has field ut_syslen. */
++#undef HAVE_STRUCT_UTMPX_UT_SYSLEN
++
++/* Define if struct utmpx has field ut_tv. */
++#undef HAVE_STRUCT_UTMPX_UT_TV
++
++/* Define if struct utmpx has field ut_type. */
++#undef HAVE_STRUCT_UTMPX_UT_TYPE
++
++/* Define if struct utmpx has field ut_user. */
++#undef HAVE_STRUCT_UTMPX_UT_USER
++
++/* Define if struct utmp has field ut_addr. */
++#undef HAVE_STRUCT_UTMP_UT_ADDR
++
++/* Define if struct utmp has field ut_host. */
++#undef HAVE_STRUCT_UTMP_UT_HOST
++
++/* Define if struct utmp has field ut_id. */
++#undef HAVE_STRUCT_UTMP_UT_ID
++
++/* Define if struct utmp has field ut_pid. */
++#undef HAVE_STRUCT_UTMP_UT_PID
++
++/* Define if struct utmp has field ut_type. */
++#undef HAVE_STRUCT_UTMP_UT_TYPE
++
++/* Define if struct utmp has field ut_user. */
++#undef HAVE_STRUCT_UTMP_UT_USER
++
++/* define if struct winsize is declared in sys/termios.h */
++#undef HAVE_STRUCT_WINSIZE
++
++/* Define to 1 if you have the `strunvis' function. */
++#undef HAVE_STRUNVIS
++
++/* Define if you have the function `strupr'. */
++#undef HAVE_STRUPR
++
++/* Define to 1 if you have the `strvis' function. */
++#undef HAVE_STRVIS
++
++/* Define to 1 if you have the `strvisx' function. */
++#undef HAVE_STRVISX
++
++/* Define to 1 if you have the `svis' function. */
++#undef HAVE_SVIS
++
++/* Define if you have the function `swab'. */
++#undef HAVE_SWAB
++
++/* Define to 1 if you have the `sysconf' function. */
++#undef HAVE_SYSCONF
++
++/* Define to 1 if you have the `sysctl' function. */
++#undef HAVE_SYSCTL
++
++/* Define to 1 if you have the `syslog' function. */
++#undef HAVE_SYSLOG
++
++/* Define to 1 if you have the <syslog.h> header file. */
++#undef HAVE_SYSLOG_H
++
++/* Define to 1 if you have the <sys/bitypes.h> header file. */
++#undef HAVE_SYS_BITYPES_H
++
++/* Define to 1 if you have the <sys/bswap.h> header file. */
++#undef HAVE_SYS_BSWAP_H
++
++/* Define to 1 if you have the <sys/capability.h> header file. */
++#undef HAVE_SYS_CAPABILITY_H
++
++/* Define to 1 if you have the <sys/category.h> header file. */
++#undef HAVE_SYS_CATEGORY_H
++
++/* Define to 1 if you have the <sys/file.h> header file. */
++#undef HAVE_SYS_FILE_H
++
++/* Define to 1 if you have the <sys/filio.h> header file. */
++#undef HAVE_SYS_FILIO_H
++
++/* Define to 1 if you have the <sys/ioccom.h> header file. */
++#undef HAVE_SYS_IOCCOM_H
++
++/* Define to 1 if you have the <sys/ioctl.h> header file. */
++#undef HAVE_SYS_IOCTL_H
++
++/* Define to 1 if you have the <sys/mman.h> header file. */
++#undef HAVE_SYS_MMAN_H
++
++/* Define to 1 if you have the <sys/param.h> header file. */
++#undef HAVE_SYS_PARAM_H
++
++/* Define to 1 if you have the <sys/proc.h> header file. */
++#undef HAVE_SYS_PROC_H
++
++/* Define to 1 if you have the <sys/ptyio.h> header file. */
++#undef HAVE_SYS_PTYIO_H
++
++/* Define to 1 if you have the <sys/ptyvar.h> header file. */
++#undef HAVE_SYS_PTYVAR_H
++
++/* Define to 1 if you have the <sys/pty.h> header file. */
++#undef HAVE_SYS_PTY_H
++
++/* Define to 1 if you have the <sys/resource.h> header file. */
++#undef HAVE_SYS_RESOURCE_H
++
++/* Define to 1 if you have the <sys/select.h> header file. */
++#undef HAVE_SYS_SELECT_H
++
++/* Define to 1 if you have the <sys/socket.h> header file. */
++#undef HAVE_SYS_SOCKET_H
++
++/* Define to 1 if you have the <sys/sockio.h> header file. */
++#undef HAVE_SYS_SOCKIO_H
++
++/* Define to 1 if you have the <sys/stat.h> header file. */
++#undef HAVE_SYS_STAT_H
++
++/* Define to 1 if you have the <sys/stream.h> header file. */
++#undef HAVE_SYS_STREAM_H
++
++/* Define to 1 if you have the <sys/stropts.h> header file. */
++#undef HAVE_SYS_STROPTS_H
++
++/* Define to 1 if you have the <sys/strtty.h> header file. */
++#undef HAVE_SYS_STRTTY_H
++
++/* Define to 1 if you have the <sys/str_tty.h> header file. */
++#undef HAVE_SYS_STR_TTY_H
++
++/* Define to 1 if you have the <sys/syscall.h> header file. */
++#undef HAVE_SYS_SYSCALL_H
++
++/* Define to 1 if you have the <sys/sysctl.h> header file. */
++#undef HAVE_SYS_SYSCTL_H
++
++/* Define to 1 if you have the <sys/termio.h> header file. */
++#undef HAVE_SYS_TERMIO_H
++
++/* Define to 1 if you have the <sys/timeb.h> header file. */
++#undef HAVE_SYS_TIMEB_H
++
++/* Define to 1 if you have the <sys/times.h> header file. */
++#undef HAVE_SYS_TIMES_H
++
++/* Define to 1 if you have the <sys/time.h> header file. */
++#undef HAVE_SYS_TIME_H
++
++/* Define to 1 if you have the <sys/tty.h> header file. */
++#undef HAVE_SYS_TTY_H
++
++/* Define to 1 if you have the <sys/types.h> header file. */
++#undef HAVE_SYS_TYPES_H
++
++/* Define to 1 if you have the <sys/ucred.h> header file. */
++#undef HAVE_SYS_UCRED_H
++
++/* Define to 1 if you have the <sys/uio.h> header file. */
++#undef HAVE_SYS_UIO_H
++
++/* Define to 1 if you have the <sys/un.h> header file. */
++#undef HAVE_SYS_UN_H
++
++/* Define to 1 if you have the <sys/utsname.h> header file. */
++#undef HAVE_SYS_UTSNAME_H
++
++/* Define to 1 if you have the <sys/wait.h> header file. */
++#undef HAVE_SYS_WAIT_H
++
++/* Define to 1 if you have the <termcap.h> header file. */
++#undef HAVE_TERMCAP_H
++
++/* Define to 1 if you have the <termios.h> header file. */
++#undef HAVE_TERMIOS_H
++
++/* Define to 1 if you have the <termio.h> header file. */
++#undef HAVE_TERMIO_H
++
++/* Define to 1 if you have the <term.h> header file. */
++#undef HAVE_TERM_H
++
++/* Define to 1 if you have the `tgetent' function. */
++#undef HAVE_TGETENT
++
++/* Define if you have the function `timegm'. */
++#undef HAVE_TIMEGM
++
++/* Define if you have the `timezone' variable. */
++#undef HAVE_TIMEZONE
++
++/* Define to 1 if you have the <time.h> header file. */
++#undef HAVE_TIME_H
++
++/* Define to 1 if you have the <tmpdir.h> header file. */
++#undef HAVE_TMPDIR_H
++
++/* Define to 1 if you have the `ttyname' function. */
++#undef HAVE_TTYNAME
++
++/* Define to 1 if you have the `ttyslot' function. */
++#undef HAVE_TTYSLOT
++
++/* Define to 1 if you have the <udb.h> header file. */
++#undef HAVE_UDB_H
++
++/* Define to 1 if the system has the type `uint16_t'. */
++#undef HAVE_UINT16_T
++
++/* Define to 1 if the system has the type `uint32_t'. */
++#undef HAVE_UINT32_T
++
++/* Define to 1 if the system has the type `uint64_t'. */
++#undef HAVE_UINT64_T
++
++/* Define to 1 if the system has the type `uint8_t'. */
++#undef HAVE_UINT8_T
++
++/* Define to 1 if the system has the type `uintptr_t'. */
++#undef HAVE_UINTPTR_T
++
++/* Define to 1 if you have the `umask' function. */
++#undef HAVE_UMASK
++
++/* Define to 1 if you have the `uname' function. */
++#undef HAVE_UNAME
++
++/* Define to 1 if you have the <unistd.h> header file. */
++#undef HAVE_UNISTD_H
++
++/* Define to 1 if you have the `unlockpt' function. */
++#undef HAVE_UNLOCKPT
++
++/* Define if you have the function `unsetenv'. */
++#undef HAVE_UNSETENV
++
++/* Define to 1 if you have the `unvis' function. */
++#undef HAVE_UNVIS
++
++/* Define to 1 if you have the <userconf.h> header file. */
++#undef HAVE_USERCONF_H
++
++/* Define to 1 if you have the <usersec.h> header file. */
++#undef HAVE_USERSEC_H
++
++/* Define to 1 if you have the <util.h> header file. */
++#undef HAVE_UTIL_H
++
++/* Define to 1 if you have the <utmpx.h> header file. */
++#undef HAVE_UTMPX_H
++
++/* Define to 1 if you have the <utmp.h> header file. */
++#undef HAVE_UTMP_H
++
++/* Define to 1 if the system has the type `u_int16_t'. */
++#undef HAVE_U_INT16_T
++
++/* Define to 1 if the system has the type `u_int32_t'. */
++#undef HAVE_U_INT32_T
++
++/* Define to 1 if the system has the type `u_int64_t'. */
++#undef HAVE_U_INT64_T
++
++/* Define to 1 if the system has the type `u_int8_t'. */
++#undef HAVE_U_INT8_T
++
++/* Define to 1 if you have the `vasnprintf' function. */
++#undef HAVE_VASNPRINTF
++
++/* Define to 1 if you have the `vasprintf' function. */
++#undef HAVE_VASPRINTF
++
++/* Define if you have the function `verr'. */
++#undef HAVE_VERR
++
++/* Define if you have the function `verrx'. */
++#undef HAVE_VERRX
++
++/* Define to 1 if you have the `vhangup' function. */
++#undef HAVE_VHANGUP
++
++/* Define to 1 if you have the `vis' function. */
++#undef HAVE_VIS
++
++/* Define to 1 if you have the <vis.h> header file. */
++#undef HAVE_VIS_H
++
++/* define if you have a working vsnprintf */
++#undef HAVE_VSNPRINTF
++
++/* Define if you have the function `vsyslog'. */
++#undef HAVE_VSYSLOG
++
++/* Define if you have the function `vwarn'. */
++#undef HAVE_VWARN
++
++/* Define if you have the function `vwarnx'. */
++#undef HAVE_VWARNX
++
++/* Define if you have the function `warn'. */
++#undef HAVE_WARN
++
++/* Define if you have the function `warnx'. */
++#undef HAVE_WARNX
++
++/* Define to 1 if you have the <winsock2.h> header file. */
++#undef HAVE_WINSOCK2_H
++
++/* Define if you have the function `writev'. */
++#undef HAVE_WRITEV
++
++/* Define to 1 if you have the <ws2tcpip.h> header file. */
++#undef HAVE_WS2TCPIP_H
++
++/* define if struct winsize has ws_xpixel */
++#undef HAVE_WS_XPIXEL
++
++/* define if struct winsize has ws_ypixel */
++#undef HAVE_WS_YPIXEL
++
++/* Define to 1 if you have the `XauFileName' function. */
++#undef HAVE_XAUFILENAME
++
++/* Define to 1 if you have the `XauReadAuth' function. */
++#undef HAVE_XAUREADAUTH
++
++/* Define to 1 if you have the `XauWriteAuth' function. */
++#undef HAVE_XAUWRITEAUTH
++
++/* Define to 1 if you have the `yp_get_default_domain' function. */
++#undef HAVE_YP_GET_DEFAULT_DOMAIN
++
++/* Define to 1 if you have the `_getpty' function. */
++#undef HAVE__GETPTY
++
++/* Define if you have the `_res' variable. */
++#undef HAVE__RES
++
++/* Define to 1 if you have the `_scrsize' function. */
++#undef HAVE__SCRSIZE
++
++/* define if your compiler has __attribute__ */
++#undef HAVE___ATTRIBUTE__
++
++/* Define if you have the `__progname' variable. */
++#undef HAVE___PROGNAME
++
++/* have __sync_add_and_fetch */
++#undef HAVE___SYNC_ADD_AND_FETCH
++
++/* Define if you want support for weak crypto */
++#undef HEIM_WEAK_CRYPTO
++
++/* Define if you have the hesiod package. */
++#undef HESIOD
++
++/* Define to enable Kerberos 4. */
++#undef KRB4
++
++/* Enable Kerberos 5 support in applications. */
++#undef KRB5
++
++/* Define to enable kx509. */
++#undef KX509
++
++/* path to lib */
++#undef LIBDIR
++
++/* path to libexec */
++#undef LIBEXECDIR
++
++/* Define if you have the libintl package. */
++#undef LIBINTL
++
++/* path to localstate */
++#undef LOCALSTATEDIR
++
++/* Define to the sub-directory in which libtool stores uninstalled libraries.
++   */
++#undef LT_OBJDIR
++
++/* define if the system is missing a prototype for asnprintf() */
++#undef NEED_ASNPRINTF_PROTO
++
++/* define if the system is missing a prototype for asprintf() */
++#undef NEED_ASPRINTF_PROTO
++
++/* define if the system is missing a prototype for crypt() */
++#undef NEED_CRYPT_PROTO
++
++/* define if the system is missing a prototype for daemon() */
++#undef NEED_DAEMON_PROTO
++
++/* define if the system is missing a prototype for gethostname() */
++#undef NEED_GETHOSTNAME_PROTO
++
++/* define if the system is missing a prototype for getusershell() */
++#undef NEED_GETUSERSHELL_PROTO
++
++/* define if the system is missing a prototype for glob() */
++#undef NEED_GLOB_PROTO
++
++/* define if the system is missing a prototype for hstrerror() */
++#undef NEED_HSTRERROR_PROTO
++
++/* define if the system is missing a prototype for inet_aton() */
++#undef NEED_INET_ATON_PROTO
++
++/* define if the system is missing a prototype for iruserok() */
++#undef NEED_IRUSEROK_PROTO
++
++/* define if the system is missing a prototype for mkstemp() */
++#undef NEED_MKSTEMP_PROTO
++
++/* if your qsort is not a stable sort */
++#undef NEED_QSORT
++
++/* define if the system is missing a prototype for SecKeyGetCSPHandle() */
++#undef NEED_SECKEYGETCSPHANDLE_PROTO
++
++/* define if the system is missing a prototype for setenv() */
++#undef NEED_SETENV_PROTO
++
++/* define if the system is missing a prototype for snprintf() */
++#undef NEED_SNPRINTF_PROTO
++
++/* define if the system is missing a prototype for strndup() */
++#undef NEED_STRNDUP_PROTO
++
++/* define if the system is missing a prototype for strsep() */
++#undef NEED_STRSEP_PROTO
++
++/* define if the system is missing a prototype for strsvisx() */
++#undef NEED_STRSVISX_PROTO
++
++/* define if the system is missing a prototype for strsvis() */
++#undef NEED_STRSVIS_PROTO
++
++/* define if the system is missing a prototype for strtok_r() */
++#undef NEED_STRTOK_R_PROTO
++
++/* define if the system is missing a prototype for strunvis() */
++#undef NEED_STRUNVIS_PROTO
++
++/* define if the system is missing a prototype for strvisx() */
++#undef NEED_STRVISX_PROTO
++
++/* define if the system is missing a prototype for strvis() */
++#undef NEED_STRVIS_PROTO
++
++/* define if the system is missing a prototype for svis() */
++#undef NEED_SVIS_PROTO
++
++/* define if the system is missing a prototype for unsetenv() */
++#undef NEED_UNSETENV_PROTO
++
++/* define if the system is missing a prototype for unvis() */
++#undef NEED_UNVIS_PROTO
++
++/* define if the system is missing a prototype for vasnprintf() */
++#undef NEED_VASNPRINTF_PROTO
++
++/* define if the system is missing a prototype for vasprintf() */
++#undef NEED_VASPRINTF_PROTO
++
++/* define if the system is missing a prototype for vis() */
++#undef NEED_VIS_PROTO
++
++/* define if the system is missing a prototype for vsnprintf() */
++#undef NEED_VSNPRINTF_PROTO
++
++/* Define if you don't wan't support for AFS. */
++#undef NO_AFS
++
++/* Define to 1 if your C compiler doesn't accept -c and -o together. */
++#undef NO_MINUS_C_MINUS_O
++
++/* Define if you don't want to use mmap. */
++#undef NO_MMAP
++
++/* Define this to enable old environment option in telnet. */
++#undef OLD_ENVIRON
++
++/* Define if you have the openldap package. */
++#undef OPENLDAP
++
++/* Define if you want support for hdb ldap module */
++#undef OPENLDAP_MODULE
++
++/* define if prototype of openlog is compatible with void openlog(const char
++   *, int, int) */
++#undef OPENLOG_PROTO_COMPATIBLE
++
++/* Define if you want OTP support in applications. */
++#undef OTP
++
++/* Name of package */
++#undef PACKAGE
++
++/* Define to the address where bug reports for this package should be sent. */
++#undef PACKAGE_BUGREPORT
++
++/* Define to the full name of this package. */
++#undef PACKAGE_NAME
++
++/* Define to the full name and version of this package. */
++#undef PACKAGE_STRING
++
++/* Define to the one symbol short name of this package. */
++#undef PACKAGE_TARNAME
++
++/* Define to the home page for this package. */
++#undef PACKAGE_URL
++
++/* Define to the version of this package. */
++#undef PACKAGE_VERSION
++
++/* Define to enable PKINIT. */
++#undef PKINIT
++
++/* Define if getlogin has POSIX flavour (and not BSD). */
++#undef POSIX_GETLOGIN
++
++/* Define if getpwnam_r has POSIX flavour. */
++#undef POSIX_GETPWNAM_R
++
++/* Define if you have the readline package. */
++#undef READLINE
++
++/* Define as the return type of signal handlers (`int' or `void'). */
++#undef RETSIGTYPE
++
++/* path to sbin */
++#undef SBINDIR
++
++/* Define if you want to use samba socket wrappers. */
++#undef SOCKET_WRAPPER_REPLACE
++
++/* Define if you have the sqlite3 package. */
++#undef SQLITE3
++
++/* Define to 1 if you have the ANSI C header files. */
++#undef STDC_HEADERS
++
++/* Define if you have streams ptys. */
++#undef STREAMSPTY
++
++/* define if prototype of strerror_r is compatible with int strerror_r(int,
++   char *, size_t) */
++#undef STRERROR_R_PROTO_COMPATIBLE
++
++/* Define if os support want to detach is daemonens. */
++#undef SUPPORT_DETACH
++
++/* Enable use of inetd style startup. */
++#undef SUPPORT_INETD
++
++/* path to sysconf */
++#undef SYSCONFDIR
++
++/* Define to what version of SunOS you are running. */
++#undef SunOS
++
++/* Define to 1 if you can safely include both <sys/time.h> and <time.h>. */
++#undef TIME_WITH_SYS_TIME
++
++/* Define to 1 if your <sys/time.h> declares `struct tm'. */
++#undef TM_IN_SYS_TIME
++
++/* Version number of package */
++#undef VERSION
++
++/* Define if signal handlers return void. */
++#undef VOID_RETSIGTYPE
++
++/* define if target is big endian */
++#undef WORDS_BIGENDIAN
++
++/* Define to 1 if the X Window System is missing or not being used. */
++#undef X_DISPLAY_MISSING
++
++/* Define to 1 if `lex' declares `yytext' as a `char *' by default, not a
++   `char[]'. */
++#undef YYTEXT_POINTER
++
++/* Required for functional/sane headers on AIX */
++#undef _ALL_SOURCE
++
++/* Number of bits in a file offset, on hosts where this is settable. */
++#undef _FILE_OFFSET_BITS
++
++/* Define to enable extensions on glibc-based systems such as Linux. */
++#undef _GNU_SOURCE
++
++/* Define for large files, on AIX-style hosts. */
++#undef _LARGE_FILES
++
++/* Define to empty if `const' does not conform to ANSI C. */
++#undef const
++
++/* Define to `int' if <sys/types.h> doesn't define. */
++#undef gid_t
++
++/* Define to `__inline__' or `__inline' if that's what the C compiler
++   calls it, or to nothing if 'inline' is not supported under any name.  */
++#ifndef __cplusplus
++#undef inline
++#endif
++
++/* Define this to what the type mode_t should be. */
++#undef mode_t
++
++/* Define to `long int' if <sys/types.h> does not define. */
++#undef off_t
++
++/* Define to `int' if <sys/types.h> does not define. */
++#undef pid_t
++
++/* Path name delimiter */
++#undef rk_PATH_DELIM
++
++/* Define this to what the type sig_atomic_t should be. */
++#undef sig_atomic_t
++
++/* Define to `unsigned int' if <sys/types.h> does not define. */
++#undef size_t
++
++/* Define to `int' if <sys/types.h> doesn't define. */
++#undef uid_t
++
++#if _AIX
++/* XXX this is gross, but kills about a gazillion warnings */
++struct ether_addr;
++struct sockaddr;
++struct sockaddr_dl;
++struct sockaddr_in;
++#endif
++
++#ifdef __APPLE__
++#include <AvailabilityMacros.h>
++#endif
++
++#ifdef ROKEN_RENAME
++#include "roken_rename.h"
++#endif
++
++#ifdef VOID_RETSIGTYPE
++#define SIGRETURN(x) return
++#else
++#define SIGRETURN(x) return (RETSIGTYPE)(x)
++#endif
++
++#ifdef BROKEN_REALLOC
++#define realloc(X, Y) rk_realloc((X), (Y))
++#endif
++
++
++#ifdef ENDIANESS_IN_SYS_PARAM_H
++#  include <sys/types.h>
++#  include <sys/param.h>
++#  if BYTE_ORDER == BIG_ENDIAN
++#  define WORDS_BIGENDIAN 1
++#  endif
++#endif
++
++
++
++
++/* Set this to the default system lead string for telnetd 
++ * can contain %-escapes: %s=sysname, %m=machine, %r=os-release
++ * %v=os-version, %t=tty, %h=hostname, %d=date and time
++ */
++#undef USE_IM
++
++/* Used with login -p */
++#undef LOGIN_ARGS
++
++/* set this to a sensible login */
++#ifndef LOGIN_PATH
++#define LOGIN_PATH BINDIR "/login"
++#endif
++
+Index: git/include/gssapi/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/include/gssapi/Makefile.in	2010-12-29 04:07:05.955048491 +0100
+@@ -0,0 +1,710 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = include/gssapi
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++CLEANFILES = gssapi.h gssapi_krb5.h gssapi_spnego.h gssapi_ntlm.h gssapi_oid.h
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign include/gssapi/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign include/gssapi/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: all all-am all-local check check-am check-local clean \
++	clean-generic clean-libtool dist-hook distclean \
++	distclean-generic distclean-libtool distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/include/hcrypto/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/include/hcrypto/Makefile.in	2010-12-29 04:07:06.115098761 +0100
+@@ -0,0 +1,734 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = include/hcrypto
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++CLEANFILES = \
++	aes.h		\
++	bn.h		\
++	des.h		\
++	dh.h		\
++	dsa.h		\
++	ec.h		\
++	ecdsa.h		\
++	ecdh.h		\
++	engine.h	\
++	evp.h		\
++	evp-hcrypto.h	\
++	evp-cc.h	\
++	hmac.h		\
++	md2.h		\
++	md4.h		\
++	md5.h		\
++	pkcs12.h	\
++	rand.h		\
++	rc2.h		\
++	rc4.h		\
++	rsa.h		\
++	sha.h		\
++	ui.h
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign include/hcrypto/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign include/hcrypto/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: all all-am all-local check check-am check-local clean \
++	clean-generic clean-libtool dist-hook distclean \
++	distclean-generic distclean-libtool distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/include/kadm5/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/include/kadm5/Makefile.in	2010-12-29 04:07:06.265145868 +0100
+@@ -0,0 +1,711 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = include/kadm5
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++CLEANFILES = admin.h kadm5_err.h private.h kadm5-private.h \
++	kadm5-protos.h kadm5-pwcheck.h
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign include/kadm5/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign include/kadm5/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: all all-am all-local check check-am check-local clean \
++	clean-generic clean-libtool dist-hook distclean \
++	distclean-generic distclean-libtool distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/install-sh
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/install-sh	2010-12-29 04:04:06.000000000 +0100
+@@ -0,0 +1,520 @@
++#!/bin/sh
++# install - install a program, script, or datafile
++
++scriptversion=2009-04-28.21; # UTC
++
++# This originates from X11R5 (mit/util/scripts/install.sh), which was
++# later released in X11R6 (xc/config/util/install.sh) with the
++# following copyright and license.
++#
++# Copyright (C) 1994 X Consortium
++#
++# Permission is hereby granted, free of charge, to any person obtaining a copy
++# of this software and associated documentation files (the "Software"), to
++# deal in the Software without restriction, including without limitation the
++# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
++# sell copies of the Software, and to permit persons to whom the Software is
++# furnished to do so, subject to the following conditions:
++#
++# The above copyright notice and this permission notice shall be included in
++# all copies or substantial portions of the Software.
++#
++# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
++# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
++# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
++# X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
++# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNEC-
++# TION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
++#
++# Except as contained in this notice, the name of the X Consortium shall not
++# be used in advertising or otherwise to promote the sale, use or other deal-
++# ings in this Software without prior written authorization from the X Consor-
++# tium.
++#
++#
++# FSF changes to this file are in the public domain.
++#
++# Calling this script install-sh is preferred over install.sh, to prevent
++# `make' implicit rules from creating a file called install from it
++# when there is no Makefile.
++#
++# This script is compatible with the BSD install script, but was written
++# from scratch.
++
++nl='
++'
++IFS=" ""	$nl"
++
++# set DOITPROG to echo to test this script
++
++# Don't use :- since 4.3BSD and earlier shells don't like it.
++doit=${DOITPROG-}
++if test -z "$doit"; then
++  doit_exec=exec
++else
++  doit_exec=$doit
++fi
++
++# Put in absolute file names if you don't have them in your path;
++# or use environment vars.
++
++chgrpprog=${CHGRPPROG-chgrp}
++chmodprog=${CHMODPROG-chmod}
++chownprog=${CHOWNPROG-chown}
++cmpprog=${CMPPROG-cmp}
++cpprog=${CPPROG-cp}
++mkdirprog=${MKDIRPROG-mkdir}
++mvprog=${MVPROG-mv}
++rmprog=${RMPROG-rm}
++stripprog=${STRIPPROG-strip}
++
++posix_glob='?'
++initialize_posix_glob='
++  test "$posix_glob" != "?" || {
++    if (set -f) 2>/dev/null; then
++      posix_glob=
++    else
++      posix_glob=:
++    fi
++  }
++'
++
++posix_mkdir=
++
++# Desired mode of installed file.
++mode=0755
++
++chgrpcmd=
++chmodcmd=$chmodprog
++chowncmd=
++mvcmd=$mvprog
++rmcmd="$rmprog -f"
++stripcmd=
++
++src=
++dst=
++dir_arg=
++dst_arg=
++
++copy_on_change=false
++no_target_directory=
++
++usage="\
++Usage: $0 [OPTION]... [-T] SRCFILE DSTFILE
++   or: $0 [OPTION]... SRCFILES... DIRECTORY
++   or: $0 [OPTION]... -t DIRECTORY SRCFILES...
++   or: $0 [OPTION]... -d DIRECTORIES...
++
++In the 1st form, copy SRCFILE to DSTFILE.
++In the 2nd and 3rd, copy all SRCFILES to DIRECTORY.
++In the 4th, create DIRECTORIES.
++
++Options:
++     --help     display this help and exit.
++     --version  display version info and exit.
++
++  -c            (ignored)
++  -C            install only if different (preserve the last data modification time)
++  -d            create directories instead of installing files.
++  -g GROUP      $chgrpprog installed files to GROUP.
++  -m MODE       $chmodprog installed files to MODE.
++  -o USER       $chownprog installed files to USER.
++  -s            $stripprog installed files.
++  -t DIRECTORY  install into DIRECTORY.
++  -T            report an error if DSTFILE is a directory.
++
++Environment variables override the default commands:
++  CHGRPPROG CHMODPROG CHOWNPROG CMPPROG CPPROG MKDIRPROG MVPROG
++  RMPROG STRIPPROG
++"
++
++while test $# -ne 0; do
++  case $1 in
++    -c) ;;
++
++    -C) copy_on_change=true;;
++
++    -d) dir_arg=true;;
++
++    -g) chgrpcmd="$chgrpprog $2"
++	shift;;
++
++    --help) echo "$usage"; exit $?;;
++
++    -m) mode=$2
++	case $mode in
++	  *' '* | *'	'* | *'
++'*	  | *'*'* | *'?'* | *'['*)
++	    echo "$0: invalid mode: $mode" >&2
++	    exit 1;;
++	esac
++	shift;;
++
++    -o) chowncmd="$chownprog $2"
++	shift;;
++
++    -s) stripcmd=$stripprog;;
++
++    -t) dst_arg=$2
++	shift;;
++
++    -T) no_target_directory=true;;
++
++    --version) echo "$0 $scriptversion"; exit $?;;
++
++    --)	shift
++	break;;
++
++    -*)	echo "$0: invalid option: $1" >&2
++	exit 1;;
++
++    *)  break;;
++  esac
++  shift
++done
++
++if test $# -ne 0 && test -z "$dir_arg$dst_arg"; then
++  # When -d is used, all remaining arguments are directories to create.
++  # When -t is used, the destination is already specified.
++  # Otherwise, the last argument is the destination.  Remove it from $@.
++  for arg
++  do
++    if test -n "$dst_arg"; then
++      # $@ is not empty: it contains at least $arg.
++      set fnord "$@" "$dst_arg"
++      shift # fnord
++    fi
++    shift # arg
++    dst_arg=$arg
++  done
++fi
++
++if test $# -eq 0; then
++  if test -z "$dir_arg"; then
++    echo "$0: no input file specified." >&2
++    exit 1
++  fi
++  # It's OK to call `install-sh -d' without argument.
++  # This can happen when creating conditional directories.
++  exit 0
++fi
++
++if test -z "$dir_arg"; then
++  trap '(exit $?); exit' 1 2 13 15
++
++  # Set umask so as not to create temps with too-generous modes.
++  # However, 'strip' requires both read and write access to temps.
++  case $mode in
++    # Optimize common cases.
++    *644) cp_umask=133;;
++    *755) cp_umask=22;;
++
++    *[0-7])
++      if test -z "$stripcmd"; then
++	u_plus_rw=
++      else
++	u_plus_rw='% 200'
++      fi
++      cp_umask=`expr '(' 777 - $mode % 1000 ')' $u_plus_rw`;;
++    *)
++      if test -z "$stripcmd"; then
++	u_plus_rw=
++      else
++	u_plus_rw=,u+rw
++      fi
++      cp_umask=$mode$u_plus_rw;;
++  esac
++fi
++
++for src
++do
++  # Protect names starting with `-'.
++  case $src in
++    -*) src=./$src;;
++  esac
++
++  if test -n "$dir_arg"; then
++    dst=$src
++    dstdir=$dst
++    test -d "$dstdir"
++    dstdir_status=$?
++  else
++
++    # Waiting for this to be detected by the "$cpprog $src $dsttmp" command
++    # might cause directories to be created, which would be especially bad
++    # if $src (and thus $dsttmp) contains '*'.
++    if test ! -f "$src" && test ! -d "$src"; then
++      echo "$0: $src does not exist." >&2
++      exit 1
++    fi
++
++    if test -z "$dst_arg"; then
++      echo "$0: no destination specified." >&2
++      exit 1
++    fi
++
++    dst=$dst_arg
++    # Protect names starting with `-'.
++    case $dst in
++      -*) dst=./$dst;;
++    esac
++
++    # If destination is a directory, append the input filename; won't work
++    # if double slashes aren't ignored.
++    if test -d "$dst"; then
++      if test -n "$no_target_directory"; then
++	echo "$0: $dst_arg: Is a directory" >&2
++	exit 1
++      fi
++      dstdir=$dst
++      dst=$dstdir/`basename "$src"`
++      dstdir_status=0
++    else
++      # Prefer dirname, but fall back on a substitute if dirname fails.
++      dstdir=`
++	(dirname "$dst") 2>/dev/null ||
++	expr X"$dst" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
++	     X"$dst" : 'X\(//\)[^/]' \| \
++	     X"$dst" : 'X\(//\)$' \| \
++	     X"$dst" : 'X\(/\)' \| . 2>/dev/null ||
++	echo X"$dst" |
++	    sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{
++		   s//\1/
++		   q
++		 }
++		 /^X\(\/\/\)[^/].*/{
++		   s//\1/
++		   q
++		 }
++		 /^X\(\/\/\)$/{
++		   s//\1/
++		   q
++		 }
++		 /^X\(\/\).*/{
++		   s//\1/
++		   q
++		 }
++		 s/.*/./; q'
++      `
++
++      test -d "$dstdir"
++      dstdir_status=$?
++    fi
++  fi
++
++  obsolete_mkdir_used=false
++
++  if test $dstdir_status != 0; then
++    case $posix_mkdir in
++      '')
++	# Create intermediate dirs using mode 755 as modified by the umask.
++	# This is like FreeBSD 'install' as of 1997-10-28.
++	umask=`umask`
++	case $stripcmd.$umask in
++	  # Optimize common cases.
++	  *[2367][2367]) mkdir_umask=$umask;;
++	  .*0[02][02] | .[02][02] | .[02]) mkdir_umask=22;;
++
++	  *[0-7])
++	    mkdir_umask=`expr $umask + 22 \
++	      - $umask % 100 % 40 + $umask % 20 \
++	      - $umask % 10 % 4 + $umask % 2
++	    `;;
++	  *) mkdir_umask=$umask,go-w;;
++	esac
++
++	# With -d, create the new directory with the user-specified mode.
++	# Otherwise, rely on $mkdir_umask.
++	if test -n "$dir_arg"; then
++	  mkdir_mode=-m$mode
++	else
++	  mkdir_mode=
++	fi
++
++	posix_mkdir=false
++	case $umask in
++	  *[123567][0-7][0-7])
++	    # POSIX mkdir -p sets u+wx bits regardless of umask, which
++	    # is incompatible with FreeBSD 'install' when (umask & 300) != 0.
++	    ;;
++	  *)
++	    tmpdir=${TMPDIR-/tmp}/ins$RANDOM-$$
++	    trap 'ret=$?; rmdir "$tmpdir/d" "$tmpdir" 2>/dev/null; exit $ret' 0
++
++	    if (umask $mkdir_umask &&
++		exec $mkdirprog $mkdir_mode -p -- "$tmpdir/d") >/dev/null 2>&1
++	    then
++	      if test -z "$dir_arg" || {
++		   # Check for POSIX incompatibilities with -m.
++		   # HP-UX 11.23 and IRIX 6.5 mkdir -m -p sets group- or
++		   # other-writeable bit of parent directory when it shouldn't.
++		   # FreeBSD 6.1 mkdir -m -p sets mode of existing directory.
++		   ls_ld_tmpdir=`ls -ld "$tmpdir"`
++		   case $ls_ld_tmpdir in
++		     d????-?r-*) different_mode=700;;
++		     d????-?--*) different_mode=755;;
++		     *) false;;
++		   esac &&
++		   $mkdirprog -m$different_mode -p -- "$tmpdir" && {
++		     ls_ld_tmpdir_1=`ls -ld "$tmpdir"`
++		     test "$ls_ld_tmpdir" = "$ls_ld_tmpdir_1"
++		   }
++		 }
++	      then posix_mkdir=:
++	      fi
++	      rmdir "$tmpdir/d" "$tmpdir"
++	    else
++	      # Remove any dirs left behind by ancient mkdir implementations.
++	      rmdir ./$mkdir_mode ./-p ./-- 2>/dev/null
++	    fi
++	    trap '' 0;;
++	esac;;
++    esac
++
++    if
++      $posix_mkdir && (
++	umask $mkdir_umask &&
++	$doit_exec $mkdirprog $mkdir_mode -p -- "$dstdir"
++      )
++    then :
++    else
++
++      # The umask is ridiculous, or mkdir does not conform to POSIX,
++      # or it failed possibly due to a race condition.  Create the
++      # directory the slow way, step by step, checking for races as we go.
++
++      case $dstdir in
++	/*) prefix='/';;
++	-*) prefix='./';;
++	*)  prefix='';;
++      esac
++
++      eval "$initialize_posix_glob"
++
++      oIFS=$IFS
++      IFS=/
++      $posix_glob set -f
++      set fnord $dstdir
++      shift
++      $posix_glob set +f
++      IFS=$oIFS
++
++      prefixes=
++
++      for d
++      do
++	test -z "$d" && continue
++
++	prefix=$prefix$d
++	if test -d "$prefix"; then
++	  prefixes=
++	else
++	  if $posix_mkdir; then
++	    (umask=$mkdir_umask &&
++	     $doit_exec $mkdirprog $mkdir_mode -p -- "$dstdir") && break
++	    # Don't fail if two instances are running concurrently.
++	    test -d "$prefix" || exit 1
++	  else
++	    case $prefix in
++	      *\'*) qprefix=`echo "$prefix" | sed "s/'/'\\\\\\\\''/g"`;;
++	      *) qprefix=$prefix;;
++	    esac
++	    prefixes="$prefixes '$qprefix'"
++	  fi
++	fi
++	prefix=$prefix/
++      done
++
++      if test -n "$prefixes"; then
++	# Don't fail if two instances are running concurrently.
++	(umask $mkdir_umask &&
++	 eval "\$doit_exec \$mkdirprog $prefixes") ||
++	  test -d "$dstdir" || exit 1
++	obsolete_mkdir_used=true
++      fi
++    fi
++  fi
++
++  if test -n "$dir_arg"; then
++    { test -z "$chowncmd" || $doit $chowncmd "$dst"; } &&
++    { test -z "$chgrpcmd" || $doit $chgrpcmd "$dst"; } &&
++    { test "$obsolete_mkdir_used$chowncmd$chgrpcmd" = false ||
++      test -z "$chmodcmd" || $doit $chmodcmd $mode "$dst"; } || exit 1
++  else
++
++    # Make a couple of temp file names in the proper directory.
++    dsttmp=$dstdir/_inst.$$_
++    rmtmp=$dstdir/_rm.$$_
++
++    # Trap to clean up those temp files at exit.
++    trap 'ret=$?; rm -f "$dsttmp" "$rmtmp" && exit $ret' 0
++
++    # Copy the file name to the temp name.
++    (umask $cp_umask && $doit_exec $cpprog "$src" "$dsttmp") &&
++
++    # and set any options; do chmod last to preserve setuid bits.
++    #
++    # If any of these fail, we abort the whole thing.  If we want to
++    # ignore errors from any of these, just make sure not to ignore
++    # errors from the above "$doit $cpprog $src $dsttmp" command.
++    #
++    { test -z "$chowncmd" || $doit $chowncmd "$dsttmp"; } &&
++    { test -z "$chgrpcmd" || $doit $chgrpcmd "$dsttmp"; } &&
++    { test -z "$stripcmd" || $doit $stripcmd "$dsttmp"; } &&
++    { test -z "$chmodcmd" || $doit $chmodcmd $mode "$dsttmp"; } &&
++
++    # If -C, don't bother to copy if it wouldn't change the file.
++    if $copy_on_change &&
++       old=`LC_ALL=C ls -dlL "$dst"	2>/dev/null` &&
++       new=`LC_ALL=C ls -dlL "$dsttmp"	2>/dev/null` &&
++
++       eval "$initialize_posix_glob" &&
++       $posix_glob set -f &&
++       set X $old && old=:$2:$4:$5:$6 &&
++       set X $new && new=:$2:$4:$5:$6 &&
++       $posix_glob set +f &&
++
++       test "$old" = "$new" &&
++       $cmpprog "$dst" "$dsttmp" >/dev/null 2>&1
++    then
++      rm -f "$dsttmp"
++    else
++      # Rename the file to the real destination.
++      $doit $mvcmd -f "$dsttmp" "$dst" 2>/dev/null ||
++
++      # The rename failed, perhaps because mv can't rename something else
++      # to itself, or perhaps because mv is so ancient that it does not
++      # support -f.
++      {
++	# Now remove or move aside any old file at destination location.
++	# We try this two ways since rm can't unlink itself on some
++	# systems and the destination file might be busy for other
++	# reasons.  In this case, the final cleanup might fail but the new
++	# file should still install successfully.
++	{
++	  test ! -f "$dst" ||
++	  $doit $rmcmd -f "$dst" 2>/dev/null ||
++	  { $doit $mvcmd -f "$dst" "$rmtmp" 2>/dev/null &&
++	    { $doit $rmcmd -f "$rmtmp" 2>/dev/null; :; }
++	  } ||
++	  { echo "$0: cannot unlink or rename $dst" >&2
++	    (exit 1); exit 1
++	  }
++	} &&
++
++	# Now rename the file to the real destination.
++	$doit $mvcmd "$dsttmp" "$dst"
++      }
++    fi || exit 1
++
++    trap '' 0
++  fi
++done
++
++# Local variables:
++# eval: (add-hook 'write-file-hooks 'time-stamp)
++# time-stamp-start: "scriptversion="
++# time-stamp-format: "%:y-%02m-%02d.%02H"
++# time-stamp-time-zone: "UTC"
++# time-stamp-end: "; # UTC"
++# End:
+Index: git/kadmin/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/kadmin/Makefile.in	2010-12-29 04:07:06.525227524 +0100
+@@ -0,0 +1,1246 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++sbin_PROGRAMS = kadmin$(EXEEXT)
++libexec_PROGRAMS = kadmind$(EXEEXT)
++noinst_PROGRAMS = add_random_users$(EXEEXT)
++TESTS = test_util$(EXEEXT)
++check_PROGRAMS = $(am__EXEEXT_1)
++subdir = kadmin
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__EXEEXT_1 = test_util$(EXEEXT)
++am__installdirs = "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(sbindir)" \
++	"$(DESTDIR)$(man8dir)"
++PROGRAMS = $(libexec_PROGRAMS) $(noinst_PROGRAMS) $(sbin_PROGRAMS)
++am_add_random_users_OBJECTS = add-random-users.$(OBJEXT)
++add_random_users_OBJECTS = $(am_add_random_users_OBJECTS)
++am__DEPENDENCIES_1 =
++am__DEPENDENCIES_2 = $(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++add_random_users_DEPENDENCIES =  \
++	$(top_builddir)/lib/kadm5/libkadm5clnt.la \
++	$(top_builddir)/lib/kadm5/libkadm5srv.la $(am__DEPENDENCIES_2) \
++	$(am__DEPENDENCIES_1)
++dist_kadmin_OBJECTS = ank.$(OBJEXT) add_enctype.$(OBJEXT) \
++	check.$(OBJEXT) cpw.$(OBJEXT) del.$(OBJEXT) \
++	del_enctype.$(OBJEXT) dump.$(OBJEXT) ext.$(OBJEXT) \
++	get.$(OBJEXT) init.$(OBJEXT) kadmin.$(OBJEXT) load.$(OBJEXT) \
++	mod.$(OBJEXT) rename.$(OBJEXT) stash.$(OBJEXT) util.$(OBJEXT) \
++	pw_quality.$(OBJEXT) random_password.$(OBJEXT)
++nodist_kadmin_OBJECTS = kadmin-commands.$(OBJEXT)
++kadmin_OBJECTS = $(dist_kadmin_OBJECTS) $(nodist_kadmin_OBJECTS)
++kadmin_DEPENDENCIES = $(top_builddir)/lib/kadm5/libkadm5clnt.la \
++	$(top_builddir)/lib/kadm5/libkadm5srv.la \
++	$(top_builddir)/lib/sl/libsl.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_2) $(am__DEPENDENCIES_1)
++am_kadmind_OBJECTS = rpc.$(OBJEXT) server.$(OBJEXT) kadmind.$(OBJEXT) \
++	kadm_conn.$(OBJEXT)
++kadmind_OBJECTS = $(am_kadmind_OBJECTS)
++kadmind_DEPENDENCIES = $(top_builddir)/lib/kadm5/libkadm5srv.la \
++	../lib/gssapi/libgssapi.la $(am__DEPENDENCIES_2) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++am_test_util_OBJECTS = test_util.$(OBJEXT) util.$(OBJEXT)
++test_util_OBJECTS = $(am_test_util_OBJECTS)
++am__DEPENDENCIES_3 = $(top_builddir)/lib/kadm5/libkadm5clnt.la \
++	$(top_builddir)/lib/kadm5/libkadm5srv.la \
++	$(top_builddir)/lib/sl/libsl.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_2) $(am__DEPENDENCIES_1)
++test_util_DEPENDENCIES = $(am__DEPENDENCIES_3)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(add_random_users_SOURCES) $(dist_kadmin_SOURCES) \
++	$(nodist_kadmin_SOURCES) $(kadmind_SOURCES) \
++	$(test_util_SOURCES)
++DIST_SOURCES = $(add_random_users_SOURCES) $(dist_kadmin_SOURCES) \
++	$(kadmind_SOURCES) $(test_util_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_libintl) $(INCLUDE_readline) \
++	$(INCLUDE_hcrypto) -I$(srcdir)/../lib/krb5 \
++	-I$(top_builddir)/include/gssapi
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++man_MANS = kadmin.8 kadmind.8
++dist_kadmin_SOURCES = \
++	ank.c					\
++	add_enctype.c				\
++	check.c					\
++	cpw.c					\
++	del.c					\
++	del_enctype.c				\
++	dump.c					\
++	ext.c					\
++	get.c					\
++	init.c					\
++	kadmin.c				\
++	load.c					\
++	mod.c					\
++	rename.c				\
++	stash.c					\
++	util.c					\
++	pw_quality.c				\
++	random_password.c			\
++	kadmin_locl.h
++
++nodist_kadmin_SOURCES = \
++	kadmin-commands.c			\
++	kadmin-commands.h
++
++CLEANFILES = kadmin-commands.h kadmin-commands.c
++kadmind_SOURCES = \
++	rpc.c					\
++	server.c				\
++	kadmind.c				\
++	kadmin_locl.h				\
++	kadm_conn.c
++
++add_random_users_SOURCES = add-random-users.c
++test_util_SOURCES = test_util.c util.c
++LDADD_common = \
++	$(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_roken) \
++	$(DBLIB)
++
++kadmind_LDADD = $(top_builddir)/lib/kadm5/libkadm5srv.la \
++	../lib/gssapi/libgssapi.la \
++	$(LDADD_common) \
++	$(LIB_pidfile) \
++	$(LIB_dlopen)
++
++kadmin_LDADD = \
++	$(top_builddir)/lib/kadm5/libkadm5clnt.la \
++	$(top_builddir)/lib/kadm5/libkadm5srv.la \
++	$(top_builddir)/lib/sl/libsl.la \
++	$(LIB_readline) \
++	$(LDADD_common) \
++	$(LIB_dlopen)
++
++add_random_users_LDADD = \
++	$(top_builddir)/lib/kadm5/libkadm5clnt.la \
++	$(top_builddir)/lib/kadm5/libkadm5srv.la \
++	$(LDADD_common) \
++	$(LIB_dlopen)
++
++test_util_LDADD = $(kadmin_LDADD)
++EXTRA_DIST = $(man_MANS) kadmin-commands.in
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign kadmin/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign kadmin/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++clean-checkPROGRAMS:
++	@list='$(check_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++install-libexecPROGRAMS: $(libexec_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexecPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
++
++clean-libexecPROGRAMS:
++	@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++install-sbinPROGRAMS: $(sbin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(sbindir)" || $(MKDIR_P) "$(DESTDIR)$(sbindir)"
++	@list='$(sbin_PROGRAMS)'; test -n "$(sbindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(sbindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(sbindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-sbinPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(sbin_PROGRAMS)'; test -n "$(sbindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(sbindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(sbindir)" && rm -f $$files
++
++clean-sbinPROGRAMS:
++	@list='$(sbin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++add_random_users$(EXEEXT): $(add_random_users_OBJECTS) $(add_random_users_DEPENDENCIES) 
++	@rm -f add_random_users$(EXEEXT)
++	$(LINK) $(add_random_users_OBJECTS) $(add_random_users_LDADD) $(LIBS)
++kadmin$(EXEEXT): $(kadmin_OBJECTS) $(kadmin_DEPENDENCIES) 
++	@rm -f kadmin$(EXEEXT)
++	$(LINK) $(kadmin_OBJECTS) $(kadmin_LDADD) $(LIBS)
++kadmind$(EXEEXT): $(kadmind_OBJECTS) $(kadmind_DEPENDENCIES) 
++	@rm -f kadmind$(EXEEXT)
++	$(LINK) $(kadmind_OBJECTS) $(kadmind_LDADD) $(LIBS)
++test_util$(EXEEXT): $(test_util_OBJECTS) $(test_util_DEPENDENCIES) 
++	@rm -f test_util$(EXEEXT)
++	$(LINK) $(test_util_OBJECTS) $(test_util_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/add-random-users.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/add_enctype.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ank.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/check.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/cpw.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/del.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/del_enctype.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/dump.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ext.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/get.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/init.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kadm_conn.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kadmin-commands.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kadmin.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kadmind.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/load.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/mod.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pw_quality.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/random_password.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/rename.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/rpc.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/server.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/stash.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_util.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/util.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(sbindir)" "$(DESTDIR)$(man8dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-checkPROGRAMS clean-generic clean-libexecPROGRAMS \
++	clean-libtool clean-noinstPROGRAMS clean-sbinPROGRAMS \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libexecPROGRAMS install-sbinPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-libexecPROGRAMS uninstall-man \
++	uninstall-sbinPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-TESTS check-am \
++	check-local clean clean-checkPROGRAMS clean-generic \
++	clean-libexecPROGRAMS clean-libtool clean-noinstPROGRAMS \
++	clean-sbinPROGRAMS ctags dist-hook distclean distclean-compile \
++	distclean-generic distclean-libtool distclean-tags distdir dvi \
++	dvi-am html html-am info info-am install install-am \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-libexecPROGRAMS install-man install-man8 install-pdf \
++	install-pdf-am install-ps install-ps-am install-sbinPROGRAMS \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-compile mostlyclean-generic mostlyclean-libtool \
++	pdf pdf-am ps ps-am tags uninstall uninstall-am uninstall-hook \
++	uninstall-libexecPROGRAMS uninstall-man uninstall-man8 \
++	uninstall-sbinPROGRAMS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(kadmin_OBJECTS): kadmin-commands.h
++
++kadmin-commands.c kadmin-commands.h: kadmin-commands.in
++	$(SLC) $(srcdir)/kadmin-commands.in
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/kcm/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/kcm/Makefile.in	2010-12-29 04:07:06.735293475 +0100
+@@ -0,0 +1,994 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++libexec_PROGRAMS = kcm$(EXEEXT)
++subdir = kcm
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(man8dir)"
++PROGRAMS = $(libexec_PROGRAMS)
++am_kcm_OBJECTS = acl.$(OBJEXT) acquire.$(OBJEXT) cache.$(OBJEXT) \
++	client.$(OBJEXT) config.$(OBJEXT) connect.$(OBJEXT) \
++	events.$(OBJEXT) glue.$(OBJEXT) log.$(OBJEXT) main.$(OBJEXT) \
++	protocol.$(OBJEXT) renew.$(OBJEXT)
++kcm_OBJECTS = $(am_kcm_OBJECTS)
++kcm_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++kcm_DEPENDENCIES = $(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/ntlm/libheimntlm.la \
++	$(top_builddir)/lib/ipc/libheim-ipcs.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(kcm_SOURCES)
++DIST_SOURCES = $(kcm_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_libintl) $(INCLUDE_krb4) \
++	$(INCLUDE_hcrypto) -I$(srcdir)/../lib/krb5
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++kcm_SOURCES = \
++	acl.c		\
++	acquire.c	\
++	cache.c		\
++	client.c	\
++	config.c	\
++	connect.c	\
++	events.c	\
++	glue.c		\
++	headers.h	\
++	kcm_locl.h	\
++	kcm-protos.h	\
++	log.c		\
++	main.c		\
++	protocol.c	\
++	renew.c
++
++man_MANS = kcm.8
++LDADD = $(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_krb4) \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/ntlm/libheimntlm.la \
++	$(top_builddir)/lib/ipc/libheim-ipcs.la \
++	$(LIB_roken) \
++	$(LIB_door_create) \
++	$(LIB_pidfile)
++
++EXTRA_DIST = $(man_MANS)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign kcm/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign kcm/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libexecPROGRAMS: $(libexec_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexecPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
++
++clean-libexecPROGRAMS:
++	@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++kcm$(EXEEXT): $(kcm_OBJECTS) $(kcm_DEPENDENCIES) 
++	@rm -f kcm$(EXEEXT)
++	$(LINK) $(kcm_OBJECTS) $(kcm_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/acl.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/acquire.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/cache.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/client.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/config.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/connect.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/events.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/glue.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/log.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/main.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/protocol.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/renew.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(man8dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libexecPROGRAMS clean-libtool \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libexecPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-libexecPROGRAMS uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libexecPROGRAMS clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am \
++	install-libexecPROGRAMS install-man install-man8 install-pdf \
++	install-pdf-am install-ps install-ps-am install-strip \
++	installcheck installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-hook \
++	uninstall-libexecPROGRAMS uninstall-man uninstall-man8
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(srcdir)/kcm-protos.h:
++	cd $(srcdir); perl ../cf/make-proto.pl -o kcm-protos.h -q -P comment $(kcm_SOURCES) || rm -f kcm-protos.h
++
++$(kcm_OBJECTS): $(srcdir)/kcm-protos.h
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/kdc/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/kdc/Makefile.in	2010-12-29 04:07:07.045390817 +0100
+@@ -0,0 +1,1384 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(include_HEADERS) $(krb5_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++bin_PROGRAMS = string2key$(EXEEXT)
++sbin_PROGRAMS = kstash$(EXEEXT)
++libexec_PROGRAMS = hprop$(EXEEXT) hpropd$(EXEEXT) kdc$(EXEEXT) \
++	digest-service$(EXEEXT)
++noinst_PROGRAMS = kdc-replay$(EXEEXT)
++@versionscript_TRUE@am__append_1 = $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-script.map
++subdir = kdc
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(bindir)" \
++	"$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(sbindir)" \
++	"$(DESTDIR)$(man8dir)" "$(DESTDIR)$(includedir)" \
++	"$(DESTDIR)$(krb5dir)"
++LTLIBRARIES = $(lib_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++libkdc_la_DEPENDENCIES = $(LIB_pkinit) \
++	$(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/ntlm/libheimntlm.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++am_libkdc_la_OBJECTS = default_config.lo set_dbinfo.lo digest.lo \
++	kerberos5.lo krb5tgs.lo pkinit.lo log.lo misc.lo kx509.lo \
++	process.lo windc.lo
++libkdc_la_OBJECTS = $(am_libkdc_la_OBJECTS)
++libkdc_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libkdc_la_LDFLAGS) $(LDFLAGS) -o $@
++PROGRAMS = $(bin_PROGRAMS) $(libexec_PROGRAMS) $(noinst_PROGRAMS) \
++	$(sbin_PROGRAMS)
++am_digest_service_OBJECTS = digest-service.$(OBJEXT)
++digest_service_OBJECTS = $(am_digest_service_OBJECTS)
++am__DEPENDENCIES_2 = $(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++digest_service_DEPENDENCIES = libkdc.la ../lib/ipc/libheim-ipcs.la \
++	$(am__DEPENDENCIES_2) $(am__DEPENDENCIES_1)
++am_hprop_OBJECTS = hprop.$(OBJEXT) mit_dump.$(OBJEXT)
++hprop_OBJECTS = $(am_hprop_OBJECTS)
++hprop_DEPENDENCIES = $(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++am_hpropd_OBJECTS = hpropd.$(OBJEXT)
++hpropd_OBJECTS = $(am_hpropd_OBJECTS)
++hpropd_DEPENDENCIES = $(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++am_kdc_OBJECTS = kdc-connect.$(OBJEXT) kdc-config.$(OBJEXT) \
++	kdc-announce.$(OBJEXT) kdc-main.$(OBJEXT)
++kdc_OBJECTS = $(am_kdc_OBJECTS)
++kdc_DEPENDENCIES = libkdc.la $(am__DEPENDENCIES_2) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++kdc_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(kdc_CFLAGS) $(CFLAGS) $(kdc_LDFLAGS) \
++	$(LDFLAGS) -o $@
++kdc_replay_SOURCES = kdc-replay.c
++kdc_replay_OBJECTS = kdc-replay.$(OBJEXT)
++kdc_replay_DEPENDENCIES = libkdc.la $(am__DEPENDENCIES_2) \
++	$(am__DEPENDENCIES_1)
++am_kstash_OBJECTS = kstash.$(OBJEXT)
++kstash_OBJECTS = $(am_kstash_OBJECTS)
++kstash_LDADD = $(LDADD)
++kstash_DEPENDENCIES = $(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++am_string2key_OBJECTS = string2key.$(OBJEXT)
++string2key_OBJECTS = $(am_string2key_OBJECTS)
++string2key_LDADD = $(LDADD)
++string2key_DEPENDENCIES = $(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(libkdc_la_SOURCES) $(digest_service_SOURCES) \
++	$(hprop_SOURCES) $(hpropd_SOURCES) $(kdc_SOURCES) kdc-replay.c \
++	$(kstash_SOURCES) $(string2key_SOURCES)
++DIST_SOURCES = $(libkdc_la_SOURCES) $(digest_service_SOURCES) \
++	$(hprop_SOURCES) $(hpropd_SOURCES) $(kdc_SOURCES) kdc-replay.c \
++	$(kstash_SOURCES) $(string2key_SOURCES)
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++HEADERS = $(include_HEADERS) $(krb5_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_libintl) $(INCLUDE_krb4) \
++	$(INCLUDE_hcrypto) -I$(srcdir)/../lib/krb5
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++lib_LTLIBRARIES = libkdc.la
++man_MANS = kdc.8 kstash.8 hprop.8 hpropd.8 string2key.8
++hprop_SOURCES = hprop.c mit_dump.c hprop.h
++hpropd_SOURCES = hpropd.c hprop.h
++kstash_SOURCES = kstash.c headers.h
++string2key_SOURCES = string2key.c headers.h
++digest_service_SOURCES = \
++	digest-service.c
++
++kdc_SOURCES = connect.c	\
++	config.c	\
++	announce.c	\
++	main.c
++
++libkdc_la_SOURCES = \
++	kdc-private.h	 	\
++	kdc-protos.h	 	\
++	default_config.c 	\
++	set_dbinfo.c	 	\
++	digest.c		\
++	kdc_locl.h		\
++	kerberos5.c		\
++	krb5tgs.c		\
++	pkinit.c		\
++	log.c			\
++	misc.c			\
++	kx509.c			\
++	process.c		\
++	windc.c			\
++	rx.h
++
++libkdc_la_LDFLAGS = -version-info 2:0:0 $(am__append_1)
++hprop_LDADD = \
++	$(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_kdb) $(LIB_krb4) \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_roken) \
++	$(DBLIB) 
++
++hpropd_LDADD = \
++	$(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_kdb) $(LIB_krb4) \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_roken) \
++	$(DBLIB) 
++
++@PKINIT_TRUE@LIB_pkinit = $(top_builddir)/lib/hx509/libhx509.la
++libkdc_la_LIBADD = \
++	$(LIB_pkinit) \
++	$(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_kdb) $(LIB_krb4) \
++	$(top_builddir)/lib/ntlm/libheimntlm.la \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_roken) \
++	$(DBLIB) 
++
++LDADD = $(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_krb4) \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_roken) \
++	$(DBLIB)
++
++kdc_LDADD = libkdc.la $(LDADD) $(LIB_pidfile) $(CAPNG_LIBS)
++@FRAMEWORK_SECURITY_TRUE@kdc_LDFLAGS = -framework SystemConfiguration -framework CoreFoundation
++kdc_CFLAGS = $(CAPNG_CFLAGS)
++digest_service_LDADD = \
++	libkdc.la \
++	../lib/ipc/libheim-ipcs.la \
++	$(LDADD) $(LIB_pidfile)
++
++kdc_replay_LDADD = libkdc.la $(LDADD) $(LIB_pidfile)
++include_HEADERS = kdc.h kdc-protos.h
++krb5dir = $(includedir)/krb5
++krb5_HEADERS = windc_plugin.h
++build_HEADERZ = $(krb5_HEADERS) # XXX
++EXTRA_DIST = $(man_MANS) version-script.map
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign kdc/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign kdc/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libkdc.la: $(libkdc_la_OBJECTS) $(libkdc_la_DEPENDENCIES) 
++	$(libkdc_la_LINK) -rpath $(libdir) $(libkdc_la_OBJECTS) $(libkdc_la_LIBADD) $(LIBS)
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++install-libexecPROGRAMS: $(libexec_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexecPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
++
++clean-libexecPROGRAMS:
++	@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++install-sbinPROGRAMS: $(sbin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(sbindir)" || $(MKDIR_P) "$(DESTDIR)$(sbindir)"
++	@list='$(sbin_PROGRAMS)'; test -n "$(sbindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(sbindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(sbindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-sbinPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(sbin_PROGRAMS)'; test -n "$(sbindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(sbindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(sbindir)" && rm -f $$files
++
++clean-sbinPROGRAMS:
++	@list='$(sbin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++digest-service$(EXEEXT): $(digest_service_OBJECTS) $(digest_service_DEPENDENCIES) 
++	@rm -f digest-service$(EXEEXT)
++	$(LINK) $(digest_service_OBJECTS) $(digest_service_LDADD) $(LIBS)
++hprop$(EXEEXT): $(hprop_OBJECTS) $(hprop_DEPENDENCIES) 
++	@rm -f hprop$(EXEEXT)
++	$(LINK) $(hprop_OBJECTS) $(hprop_LDADD) $(LIBS)
++hpropd$(EXEEXT): $(hpropd_OBJECTS) $(hpropd_DEPENDENCIES) 
++	@rm -f hpropd$(EXEEXT)
++	$(LINK) $(hpropd_OBJECTS) $(hpropd_LDADD) $(LIBS)
++kdc$(EXEEXT): $(kdc_OBJECTS) $(kdc_DEPENDENCIES) 
++	@rm -f kdc$(EXEEXT)
++	$(kdc_LINK) $(kdc_OBJECTS) $(kdc_LDADD) $(LIBS)
++kdc-replay$(EXEEXT): $(kdc_replay_OBJECTS) $(kdc_replay_DEPENDENCIES) 
++	@rm -f kdc-replay$(EXEEXT)
++	$(LINK) $(kdc_replay_OBJECTS) $(kdc_replay_LDADD) $(LIBS)
++kstash$(EXEEXT): $(kstash_OBJECTS) $(kstash_DEPENDENCIES) 
++	@rm -f kstash$(EXEEXT)
++	$(LINK) $(kstash_OBJECTS) $(kstash_LDADD) $(LIBS)
++string2key$(EXEEXT): $(string2key_OBJECTS) $(string2key_DEPENDENCIES) 
++	@rm -f string2key$(EXEEXT)
++	$(LINK) $(string2key_OBJECTS) $(string2key_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/default_config.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/digest-service.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/digest.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hprop.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hpropd.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kdc-announce.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kdc-config.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kdc-connect.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kdc-main.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kdc-replay.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kerberos5.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/krb5tgs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kstash.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kx509.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/log.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/misc.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/mit_dump.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pkinit.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/process.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/set_dbinfo.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/string2key.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/windc.Plo@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++kdc-connect.o: connect.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -MT kdc-connect.o -MD -MP -MF $(DEPDIR)/kdc-connect.Tpo -c -o kdc-connect.o `test -f 'connect.c' || echo '$(srcdir)/'`connect.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/kdc-connect.Tpo $(DEPDIR)/kdc-connect.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='connect.c' object='kdc-connect.o' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -c -o kdc-connect.o `test -f 'connect.c' || echo '$(srcdir)/'`connect.c
++
++kdc-connect.obj: connect.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -MT kdc-connect.obj -MD -MP -MF $(DEPDIR)/kdc-connect.Tpo -c -o kdc-connect.obj `if test -f 'connect.c'; then $(CYGPATH_W) 'connect.c'; else $(CYGPATH_W) '$(srcdir)/connect.c'; fi`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/kdc-connect.Tpo $(DEPDIR)/kdc-connect.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='connect.c' object='kdc-connect.obj' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -c -o kdc-connect.obj `if test -f 'connect.c'; then $(CYGPATH_W) 'connect.c'; else $(CYGPATH_W) '$(srcdir)/connect.c'; fi`
++
++kdc-config.o: config.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -MT kdc-config.o -MD -MP -MF $(DEPDIR)/kdc-config.Tpo -c -o kdc-config.o `test -f 'config.c' || echo '$(srcdir)/'`config.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/kdc-config.Tpo $(DEPDIR)/kdc-config.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='config.c' object='kdc-config.o' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -c -o kdc-config.o `test -f 'config.c' || echo '$(srcdir)/'`config.c
++
++kdc-config.obj: config.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -MT kdc-config.obj -MD -MP -MF $(DEPDIR)/kdc-config.Tpo -c -o kdc-config.obj `if test -f 'config.c'; then $(CYGPATH_W) 'config.c'; else $(CYGPATH_W) '$(srcdir)/config.c'; fi`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/kdc-config.Tpo $(DEPDIR)/kdc-config.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='config.c' object='kdc-config.obj' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -c -o kdc-config.obj `if test -f 'config.c'; then $(CYGPATH_W) 'config.c'; else $(CYGPATH_W) '$(srcdir)/config.c'; fi`
++
++kdc-announce.o: announce.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -MT kdc-announce.o -MD -MP -MF $(DEPDIR)/kdc-announce.Tpo -c -o kdc-announce.o `test -f 'announce.c' || echo '$(srcdir)/'`announce.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/kdc-announce.Tpo $(DEPDIR)/kdc-announce.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='announce.c' object='kdc-announce.o' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -c -o kdc-announce.o `test -f 'announce.c' || echo '$(srcdir)/'`announce.c
++
++kdc-announce.obj: announce.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -MT kdc-announce.obj -MD -MP -MF $(DEPDIR)/kdc-announce.Tpo -c -o kdc-announce.obj `if test -f 'announce.c'; then $(CYGPATH_W) 'announce.c'; else $(CYGPATH_W) '$(srcdir)/announce.c'; fi`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/kdc-announce.Tpo $(DEPDIR)/kdc-announce.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='announce.c' object='kdc-announce.obj' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -c -o kdc-announce.obj `if test -f 'announce.c'; then $(CYGPATH_W) 'announce.c'; else $(CYGPATH_W) '$(srcdir)/announce.c'; fi`
++
++kdc-main.o: main.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -MT kdc-main.o -MD -MP -MF $(DEPDIR)/kdc-main.Tpo -c -o kdc-main.o `test -f 'main.c' || echo '$(srcdir)/'`main.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/kdc-main.Tpo $(DEPDIR)/kdc-main.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='main.c' object='kdc-main.o' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -c -o kdc-main.o `test -f 'main.c' || echo '$(srcdir)/'`main.c
++
++kdc-main.obj: main.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -MT kdc-main.obj -MD -MP -MF $(DEPDIR)/kdc-main.Tpo -c -o kdc-main.obj `if test -f 'main.c'; then $(CYGPATH_W) 'main.c'; else $(CYGPATH_W) '$(srcdir)/main.c'; fi`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/kdc-main.Tpo $(DEPDIR)/kdc-main.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='main.c' object='kdc-main.obj' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(kdc_CFLAGS) $(CFLAGS) -c -o kdc-main.obj `if test -f 'main.c'; then $(CYGPATH_W) 'main.c'; else $(CYGPATH_W) '$(srcdir)/main.c'; fi`
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++install-includeHEADERS: $(include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++install-krb5HEADERS: $(krb5_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(krb5dir)" || $(MKDIR_P) "$(DESTDIR)$(krb5dir)"
++	@list='$(krb5_HEADERS)'; test -n "$(krb5dir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(krb5dir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(krb5dir)" || exit $$?; \
++	done
++
++uninstall-krb5HEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(krb5_HEADERS)'; test -n "$(krb5dir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(krb5dir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(krb5dir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(MANS) $(HEADERS) \
++		all-local
++install-binPROGRAMS: install-libLTLIBRARIES
++
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(bindir)" "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(sbindir)" "$(DESTDIR)$(man8dir)" "$(DESTDIR)$(includedir)" "$(DESTDIR)$(krb5dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libLTLIBRARIES \
++	clean-libexecPROGRAMS clean-libtool clean-noinstPROGRAMS \
++	clean-sbinPROGRAMS mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-includeHEADERS install-krb5HEADERS \
++	install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS install-libLTLIBRARIES \
++	install-libexecPROGRAMS install-sbinPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-includeHEADERS \
++	uninstall-krb5HEADERS uninstall-libLTLIBRARIES \
++	uninstall-libexecPROGRAMS uninstall-man uninstall-sbinPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libLTLIBRARIES \
++	clean-libexecPROGRAMS clean-libtool clean-noinstPROGRAMS \
++	clean-sbinPROGRAMS ctags dist-hook distclean distclean-compile \
++	distclean-generic distclean-libtool distclean-tags distdir dvi \
++	dvi-am html html-am info info-am install install-am \
++	install-binPROGRAMS install-data install-data-am \
++	install-data-hook install-dvi install-dvi-am install-exec \
++	install-exec-am install-exec-hook install-html install-html-am \
++	install-includeHEADERS install-info install-info-am \
++	install-krb5HEADERS install-libLTLIBRARIES \
++	install-libexecPROGRAMS install-man install-man8 install-pdf \
++	install-pdf-am install-ps install-ps-am install-sbinPROGRAMS \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-compile mostlyclean-generic mostlyclean-libtool \
++	pdf pdf-am ps ps-am tags uninstall uninstall-am \
++	uninstall-binPROGRAMS uninstall-hook uninstall-includeHEADERS \
++	uninstall-krb5HEADERS uninstall-libLTLIBRARIES \
++	uninstall-libexecPROGRAMS uninstall-man uninstall-man8 \
++	uninstall-sbinPROGRAMS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(libkdc_la_OBJECTS): $(srcdir)/kdc-protos.h $(srcdir)/kdc-private.h
++$(libkdc_la_OBJECTS): $(srcdir)/version-script.map
++
++$(srcdir)/kdc-protos.h:
++	cd $(srcdir) && perl ../cf/make-proto.pl -q -P comment -o kdc-protos.h $(libkdc_la_SOURCES) || rm -f kdc-protos.h
++
++$(srcdir)/kdc-private.h:
++	cd $(srcdir) && perl ../cf/make-proto.pl -q -P comment -p kdc-private.h $(libkdc_la_SOURCES) || rm -f kdc-private.h
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/kpasswd/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/kpasswd/Makefile.in	2010-12-29 04:07:07.265459824 +0100
+@@ -0,0 +1,1079 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++bin_PROGRAMS = kpasswd$(EXEEXT)
++libexec_PROGRAMS = kpasswdd$(EXEEXT)
++noinst_PROGRAMS = kpasswd-generator$(EXEEXT)
++subdir = kpasswd
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(libexecdir)" \
++	"$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man8dir)"
++PROGRAMS = $(bin_PROGRAMS) $(libexec_PROGRAMS) $(noinst_PROGRAMS)
++am_kpasswd_OBJECTS = kpasswd.$(OBJEXT)
++kpasswd_OBJECTS = $(am_kpasswd_OBJECTS)
++kpasswd_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++kpasswd_DEPENDENCIES = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1)
++kpasswd_generator_SOURCES = kpasswd-generator.c
++kpasswd_generator_OBJECTS = kpasswd-generator.$(OBJEXT)
++kpasswd_generator_LDADD = $(LDADD)
++kpasswd_generator_DEPENDENCIES = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1)
++am_kpasswdd_OBJECTS = kpasswdd.$(OBJEXT)
++kpasswdd_OBJECTS = $(am_kpasswdd_OBJECTS)
++am__DEPENDENCIES_2 = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1)
++kpasswdd_DEPENDENCIES = $(top_builddir)/lib/kadm5/libkadm5srv.la \
++	$(top_builddir)/lib/hdb/libhdb.la $(am__DEPENDENCIES_2) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(kpasswd_SOURCES) kpasswd-generator.c $(kpasswdd_SOURCES)
++DIST_SOURCES = $(kpasswd_SOURCES) kpasswd-generator.c \
++	$(kpasswdd_SOURCES)
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man1dir = $(mandir)/man1
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_hcrypto)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++man_MANS = kpasswd.1 kpasswdd.8
++kpasswd_SOURCES = kpasswd.c kpasswd_locl.h
++kpasswdd_SOURCES = kpasswdd.c kpasswd_locl.h
++kpasswdd_LDADD = \
++	$(top_builddir)/lib/kadm5/libkadm5srv.la \
++	$(top_builddir)/lib/hdb/libhdb.la \
++	$(LDADD) \
++	$(LIB_pidfile) \
++	$(LIB_dlopen) \
++	$(DBLIB)
++
++LDADD = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_roken)
++
++EXTRA_DIST = $(man_MANS)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign kpasswd/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign kpasswd/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++install-libexecPROGRAMS: $(libexec_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexecPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
++
++clean-libexecPROGRAMS:
++	@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++kpasswd$(EXEEXT): $(kpasswd_OBJECTS) $(kpasswd_DEPENDENCIES) 
++	@rm -f kpasswd$(EXEEXT)
++	$(LINK) $(kpasswd_OBJECTS) $(kpasswd_LDADD) $(LIBS)
++kpasswd-generator$(EXEEXT): $(kpasswd_generator_OBJECTS) $(kpasswd_generator_DEPENDENCIES) 
++	@rm -f kpasswd-generator$(EXEEXT)
++	$(LINK) $(kpasswd_generator_OBJECTS) $(kpasswd_generator_LDADD) $(LIBS)
++kpasswdd$(EXEEXT): $(kpasswdd_OBJECTS) $(kpasswdd_DEPENDENCIES) 
++	@rm -f kpasswdd$(EXEEXT)
++	$(LINK) $(kpasswdd_OBJECTS) $(kpasswdd_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kpasswd-generator.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kpasswd.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kpasswdd.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man8dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libexecPROGRAMS \
++	clean-libtool clean-noinstPROGRAMS mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS install-libexecPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1 install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-libexecPROGRAMS \
++	uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1 uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libexecPROGRAMS \
++	clean-libtool clean-noinstPROGRAMS ctags dist-hook distclean \
++	distclean-compile distclean-generic distclean-libtool \
++	distclean-tags distdir dvi dvi-am html html-am info info-am \
++	install install-am install-binPROGRAMS install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am \
++	install-libexecPROGRAMS install-man install-man1 install-man8 \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-compile mostlyclean-generic mostlyclean-libtool \
++	pdf pdf-am ps ps-am tags uninstall uninstall-am \
++	uninstall-binPROGRAMS uninstall-hook uninstall-libexecPROGRAMS \
++	uninstall-man uninstall-man1 uninstall-man8
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/kuser/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/kuser/Makefile.in	2010-12-29 04:07:07.545547650 +0100
+@@ -0,0 +1,1200 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++bin_PROGRAMS = kinit$(EXEEXT) kdestroy$(EXEEXT) kgetcred$(EXEEXT) \
++	kcc$(EXEEXT)
++libexec_PROGRAMS = kdigest$(EXEEXT) kimpersonate$(EXEEXT)
++noinst_PROGRAMS = kverify$(EXEEXT) kdecode_ticket$(EXEEXT) \
++	generate-requests$(EXEEXT)
++subdir = kuser
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(libexecdir)" \
++	"$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man8dir)"
++PROGRAMS = $(bin_PROGRAMS) $(libexec_PROGRAMS) $(noinst_PROGRAMS)
++generate_requests_SOURCES = generate-requests.c
++generate_requests_OBJECTS = generate-requests.$(OBJEXT)
++generate_requests_LDADD = $(LDADD)
++am__DEPENDENCIES_1 =
++generate_requests_DEPENDENCIES = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1)
++dist_kcc_OBJECTS = kcc.$(OBJEXT) klist.$(OBJEXT) kswitch.$(OBJEXT) \
++	copy_cred_cache.$(OBJEXT)
++nodist_kcc_OBJECTS = kcc-commands.$(OBJEXT)
++kcc_OBJECTS = $(dist_kcc_OBJECTS) $(nodist_kcc_OBJECTS)
++am__DEPENDENCIES_2 = $(top_builddir)/lib/kafs/libkafs.la \
++	$(am__DEPENDENCIES_1)
++am__DEPENDENCIES_3 = $(am__DEPENDENCIES_2) \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/ntlm/libheimntlm.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++kcc_DEPENDENCIES = $(top_builddir)/lib/sl/libsl.la \
++	$(am__DEPENDENCIES_3)
++kdecode_ticket_SOURCES = kdecode_ticket.c
++kdecode_ticket_OBJECTS = kdecode_ticket.$(OBJEXT)
++kdecode_ticket_LDADD = $(LDADD)
++kdecode_ticket_DEPENDENCIES = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1)
++kdestroy_SOURCES = kdestroy.c
++kdestroy_OBJECTS = kdestroy.$(OBJEXT)
++kdestroy_DEPENDENCIES = $(am__DEPENDENCIES_3)
++dist_kdigest_OBJECTS = kdigest.$(OBJEXT)
++nodist_kdigest_OBJECTS = kdigest-commands.$(OBJEXT)
++kdigest_OBJECTS = $(dist_kdigest_OBJECTS) $(nodist_kdigest_OBJECTS)
++kdigest_DEPENDENCIES = $(top_builddir)/lib/ntlm/libheimntlm.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/sl/libsl.la $(am__DEPENDENCIES_1)
++kgetcred_SOURCES = kgetcred.c
++kgetcred_OBJECTS = kgetcred.$(OBJEXT)
++kgetcred_LDADD = $(LDADD)
++kgetcred_DEPENDENCIES = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1)
++kimpersonate_SOURCES = kimpersonate.c
++kimpersonate_OBJECTS = kimpersonate.$(OBJEXT)
++kimpersonate_DEPENDENCIES = $(am__DEPENDENCIES_3)
++kinit_SOURCES = kinit.c
++kinit_OBJECTS = kinit.$(OBJEXT)
++kinit_DEPENDENCIES = $(am__DEPENDENCIES_2) \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/ntlm/libheimntlm.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++kverify_SOURCES = kverify.c
++kverify_OBJECTS = kverify.$(OBJEXT)
++kverify_LDADD = $(LDADD)
++kverify_DEPENDENCIES = $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1) $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = generate-requests.c $(dist_kcc_SOURCES) \
++	$(nodist_kcc_SOURCES) kdecode_ticket.c kdestroy.c \
++	$(dist_kdigest_SOURCES) $(nodist_kdigest_SOURCES) kgetcred.c \
++	kimpersonate.c kinit.c kverify.c
++DIST_SOURCES = generate-requests.c $(dist_kcc_SOURCES) \
++	kdecode_ticket.c kdestroy.c $(dist_kdigest_SOURCES) kgetcred.c \
++	kimpersonate.c kinit.c kverify.c
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++man1dir = $(mandir)/man1
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_hcrypto) \
++	-I$(srcdir)/../lib/krb5 $(INCLUDE_libintl) \
++	-DHEIMDAL_LOCALEDIR='"$(localedir)"'
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++man_MANS = \
++	kinit.1 \
++	klist.1 \
++	kdestroy.1 \
++	kswitch.1 \
++	kdigest.8 \
++	kgetcred.1 \
++	kimpersonate.8
++
++kinit_LDADD = \
++	$(LIB_kafs) \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/ntlm/libheimntlm.la \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_libintl) \
++	$(LIB_roken)
++
++kdestroy_LDADD = $(kinit_LDADD)
++kimpersonate_LDADD = $(kinit_LDADD)
++kcc_LDADD = \
++	$(top_builddir)/lib/sl/libsl.la \
++	$(kinit_LDADD)
++
++dist_kcc_SOURCES = kcc.c klist.c kswitch.c copy_cred_cache.c
++nodist_kcc_SOURCES = kcc-commands.c
++dist_kdigest_SOURCES = kdigest.c
++nodist_kdigest_SOURCES = kdigest-commands.c
++kdigest_LDADD = \
++	$(top_builddir)/lib/ntlm/libheimntlm.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/sl/libsl.la \
++	$(LIB_roken)
++
++CLEANFILES = \
++	kdigest-commands.h kdigest-commands.c \
++	kcc-commands.h kcc-commands.c
++
++LDADD = \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_roken)
++
++EXTRA_DIST = $(man_MANS) \
++	kuser_locl.h kcc-commands.in kdigest-commands.in copy_cred_cache.1
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign kuser/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign kuser/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++install-libexecPROGRAMS: $(libexec_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexecPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
++
++clean-libexecPROGRAMS:
++	@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++generate-requests$(EXEEXT): $(generate_requests_OBJECTS) $(generate_requests_DEPENDENCIES) 
++	@rm -f generate-requests$(EXEEXT)
++	$(LINK) $(generate_requests_OBJECTS) $(generate_requests_LDADD) $(LIBS)
++kcc$(EXEEXT): $(kcc_OBJECTS) $(kcc_DEPENDENCIES) 
++	@rm -f kcc$(EXEEXT)
++	$(LINK) $(kcc_OBJECTS) $(kcc_LDADD) $(LIBS)
++kdecode_ticket$(EXEEXT): $(kdecode_ticket_OBJECTS) $(kdecode_ticket_DEPENDENCIES) 
++	@rm -f kdecode_ticket$(EXEEXT)
++	$(LINK) $(kdecode_ticket_OBJECTS) $(kdecode_ticket_LDADD) $(LIBS)
++kdestroy$(EXEEXT): $(kdestroy_OBJECTS) $(kdestroy_DEPENDENCIES) 
++	@rm -f kdestroy$(EXEEXT)
++	$(LINK) $(kdestroy_OBJECTS) $(kdestroy_LDADD) $(LIBS)
++kdigest$(EXEEXT): $(kdigest_OBJECTS) $(kdigest_DEPENDENCIES) 
++	@rm -f kdigest$(EXEEXT)
++	$(LINK) $(kdigest_OBJECTS) $(kdigest_LDADD) $(LIBS)
++kgetcred$(EXEEXT): $(kgetcred_OBJECTS) $(kgetcred_DEPENDENCIES) 
++	@rm -f kgetcred$(EXEEXT)
++	$(LINK) $(kgetcred_OBJECTS) $(kgetcred_LDADD) $(LIBS)
++kimpersonate$(EXEEXT): $(kimpersonate_OBJECTS) $(kimpersonate_DEPENDENCIES) 
++	@rm -f kimpersonate$(EXEEXT)
++	$(LINK) $(kimpersonate_OBJECTS) $(kimpersonate_LDADD) $(LIBS)
++kinit$(EXEEXT): $(kinit_OBJECTS) $(kinit_DEPENDENCIES) 
++	@rm -f kinit$(EXEEXT)
++	$(LINK) $(kinit_OBJECTS) $(kinit_LDADD) $(LIBS)
++kverify$(EXEEXT): $(kverify_OBJECTS) $(kverify_DEPENDENCIES) 
++	@rm -f kverify$(EXEEXT)
++	$(LINK) $(kverify_OBJECTS) $(kverify_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/copy_cred_cache.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/generate-requests.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kcc-commands.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kcc.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kdecode_ticket.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kdestroy.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kdigest-commands.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kdigest.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kgetcred.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kimpersonate.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kinit.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/klist.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kswitch.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kverify.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(PROGRAMS) $(MANS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man8dir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libexecPROGRAMS \
++	clean-libtool clean-noinstPROGRAMS mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS install-libexecPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1 install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-libexecPROGRAMS \
++	uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1 uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libexecPROGRAMS \
++	clean-libtool clean-noinstPROGRAMS ctags dist-hook distclean \
++	distclean-compile distclean-generic distclean-libtool \
++	distclean-tags distdir dvi dvi-am html html-am info info-am \
++	install install-am install-binPROGRAMS install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am \
++	install-libexecPROGRAMS install-man install-man1 install-man8 \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-compile mostlyclean-generic mostlyclean-libtool \
++	pdf pdf-am ps ps-am tags uninstall uninstall-am \
++	uninstall-binPROGRAMS uninstall-hook uninstall-libexecPROGRAMS \
++	uninstall-man uninstall-man1 uninstall-man8
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(kcc_OBJECTS): kcc-commands.h
++
++$(kdigest_OBJECTS): kdigest-commands.h
++
++kdigest-commands.c kdigest-commands.h: kdigest-commands.in
++	$(SLC) $(srcdir)/kdigest-commands.in
++
++kcc-commands.c kcc-commands.h: kcc-commands.in
++	$(SLC) $(srcdir)/kcc-commands.in
++
++# make sure install-exec-hook doesn't have any commands in Makefile.am.common
++install-exec-hook:
++	(cd $(DESTDIR)$(bindir) && rm -f klist && $(LN_S) kcc klist)
++	(cd $(DESTDIR)$(bindir) && rm -f kswitch && $(LN_S) kcc kswitch)
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/Makefile.in	2010-12-29 04:07:07.715600974 +0100
+@@ -0,0 +1,937 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = lib
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \
++	html-recursive info-recursive install-data-recursive \
++	install-dvi-recursive install-exec-recursive \
++	install-html-recursive install-info-recursive \
++	install-pdf-recursive install-ps-recursive install-recursive \
++	installcheck-recursive installdirs-recursive pdf-recursive \
++	ps-recursive uninstall-recursive
++RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive	\
++  distclean-recursive maintainer-clean-recursive
++AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \
++	$(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS \
++	distdir
++ETAGS = etags
++CTAGS = ctags
++DIST_SUBDIRS = roken vers editline com_err sl wind asn1 sqlite hcrypto \
++	ipc hx509 krb5 ntlm kafs gssapi hdb kadm5 otp kdfs
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++am__relativize = \
++  dir0=`pwd`; \
++  sed_first='s,^\([^/]*\)/.*$$,\1,'; \
++  sed_rest='s,^[^/]*/*,,'; \
++  sed_last='s,^.*/\([^/]*\)$$,\1,'; \
++  sed_butlast='s,/*[^/]*$$,,'; \
++  while test -n "$$dir1"; do \
++    first=`echo "$$dir1" | sed -e "$$sed_first"`; \
++    if test "$$first" != "."; then \
++      if test "$$first" = ".."; then \
++        dir2=`echo "$$dir0" | sed -e "$$sed_last"`/"$$dir2"; \
++        dir0=`echo "$$dir0" | sed -e "$$sed_butlast"`; \
++      else \
++        first2=`echo "$$dir2" | sed -e "$$sed_first"`; \
++        if test "$$first2" = "$$first"; then \
++          dir2=`echo "$$dir2" | sed -e "$$sed_rest"`; \
++        else \
++          dir2="../$$dir2"; \
++        fi; \
++        dir0="$$dir0"/"$$first"; \
++      fi; \
++    fi; \
++    dir1=`echo "$$dir1" | sed -e "$$sed_rest"`; \
++  done; \
++  reldir="$$dir2"
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++@EDITLINE_TRUE@dir_editline = editline
++@OTP_TRUE@dir_otp = otp
++@DCE_TRUE@dir_dce = kdfs
++@COM_ERR_TRUE@dir_com_err = com_err
++@HAVE_OPENSSL_FALSE@dir_hcrypto = hcrypto
++@SQLITE3_FALSE@dir_sqlite = sqlite
++SUBDIRS = \
++	roken \
++	vers \
++	$(dir_editline) \
++	$(dir_com_err) \
++	sl \
++	wind \
++	asn1 \
++	$(dir_sqlite) \
++	$(dir_hcrypto) \
++	ipc \
++	hx509 \
++	krb5 \
++	ntlm \
++	kafs \
++	gssapi \
++	hdb \
++	kadm5 \
++	$(dir_otp) \
++	$(dir_dce)
++
++all: all-recursive
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++# This directory's subdirectories are mostly independent; you can cd
++# into them and run `make' without going through this Makefile.
++# To change the values of `make' variables: instead of editing Makefiles,
++# (1) if the variable is set in `config.status', edit `config.status'
++#     (which will cause the Makefiles to be regenerated when you run `make');
++# (2) otherwise, pass the desired values on the `make' command line.
++$(RECURSIVE_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	target=`echo $@ | sed s/-recursive//`; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    dot_seen=yes; \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done; \
++	if test "$$dot_seen" = "no"; then \
++	  $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
++	fi; test -z "$$fail"
++
++$(RECURSIVE_CLEAN_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	case "$@" in \
++	  distclean-* | maintainer-clean-*) list='$(DIST_SUBDIRS)' ;; \
++	  *) list='$(SUBDIRS)' ;; \
++	esac; \
++	rev=''; for subdir in $$list; do \
++	  if test "$$subdir" = "."; then :; else \
++	    rev="$$subdir $$rev"; \
++	  fi; \
++	done; \
++	rev="$$rev ."; \
++	target=`echo $@ | sed s/-recursive//`; \
++	for subdir in $$rev; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done && test -z "$$fail"
++tags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
++	done
++ctags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) ctags); \
++	done
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS: tags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	if ($(ETAGS) --etags-include --version) >/dev/null 2>&1; then \
++	  include_option=--etags-include; \
++	  empty_fix=.; \
++	else \
++	  include_option=--include; \
++	  empty_fix=; \
++	fi; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test ! -f $$subdir/TAGS || \
++	      set "$$@" "$$include_option=$$here/$$subdir/TAGS"; \
++	  fi; \
++	done; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS: ctags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test -d "$(distdir)/$$subdir" \
++	    || $(MKDIR_P) "$(distdir)/$$subdir" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    dir1=$$subdir; dir2="$(distdir)/$$subdir"; \
++	    $(am__relativize); \
++	    new_distdir=$$reldir; \
++	    dir1=$$subdir; dir2="$(top_distdir)"; \
++	    $(am__relativize); \
++	    new_top_distdir=$$reldir; \
++	    echo " (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir="$$new_top_distdir" distdir="$$new_distdir" \\"; \
++	    echo "     am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)"; \
++	    ($(am__cd) $$subdir && \
++	      $(MAKE) $(AM_MAKEFLAGS) \
++	        top_distdir="$$new_top_distdir" \
++	        distdir="$$new_distdir" \
++		am__remove_distdir=: \
++		am__skip_length_check=: \
++		am__skip_mode_fix=: \
++	        distdir) \
++	      || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-recursive
++all-am: Makefile all-local
++installdirs: installdirs-recursive
++installdirs-am:
++install: install-recursive
++install-exec: install-exec-recursive
++install-data: install-data-recursive
++uninstall: uninstall-recursive
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-recursive
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-recursive
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-recursive
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic distclean-tags
++
++dvi: dvi-recursive
++
++dvi-am:
++
++html: html-recursive
++
++html-am:
++
++info: info-recursive
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-recursive
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-recursive
++
++install-html-am:
++
++install-info: install-info-recursive
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-recursive
++
++install-pdf-am:
++
++install-ps: install-ps-recursive
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-recursive
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-recursive
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-recursive
++
++pdf-am:
++
++ps: ps-recursive
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) check-am \
++	ctags-recursive install-am install-data-am install-exec-am \
++	install-strip tags-recursive uninstall-am
++
++.PHONY: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) CTAGS GTAGS \
++	all all-am all-local check check-am check-local clean \
++	clean-generic clean-libtool ctags ctags-recursive dist-hook \
++	distclean distclean-generic distclean-libtool distclean-tags \
++	distdir dvi dvi-am html html-am info info-am install \
++	install-am install-data install-data-am install-data-hook \
++	install-dvi install-dvi-am install-exec install-exec-am \
++	install-exec-hook install-html install-html-am install-info \
++	install-info-am install-man install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs installdirs-am maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags tags-recursive \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/asn1/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/asn1/Makefile.in	2010-12-29 04:07:08.055707600 +0100
+@@ -0,0 +1,1465 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(dist_include_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog asn1parse.c \
++	asn1parse.h lex.c
++@versionscript_TRUE@am__append_1 = $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-script.map
++noinst_PROGRAMS = asn1_gen$(EXEEXT)
++libexec_heimdal_PROGRAMS = asn1_compile$(EXEEXT) asn1_print$(EXEEXT)
++TESTS = check-der$(EXEEXT) check-gen$(EXEEXT) check-timegm$(EXEEXT) \
++	check-ber$(EXEEXT) check-template$(EXEEXT)
++check_PROGRAMS = $(am__EXEEXT_1)
++subdir = lib/asn1
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" \
++	"$(DESTDIR)$(libexec_heimdaldir)" "$(DESTDIR)$(includedir)" \
++	"$(DESTDIR)$(includedir)"
++LTLIBRARIES = $(lib_LTLIBRARIES) $(noinst_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++libasn1_la_DEPENDENCIES = libasn1base.la $(am__DEPENDENCIES_1)
++am__objects_1 = asn1_rfc2459_asn1.lo
++am__objects_2 = asn1_cms_asn1.lo
++am__objects_3 = asn1_krb5_asn1.lo
++am__objects_4 = asn1_pkinit_asn1.lo
++am__objects_5 = asn1_pkcs8_asn1.lo
++am__objects_6 = asn1_pkcs9_asn1.lo
++am__objects_7 = asn1_pkcs12_asn1.lo
++am__objects_8 = asn1_digest_asn1.lo
++am__objects_9 = asn1_kx509_asn1.lo
++am__objects_10 = $(am__objects_1) $(am__objects_2) $(am__objects_3) \
++	$(am__objects_4) $(am__objects_5) $(am__objects_6) \
++	$(am__objects_7) $(am__objects_8) $(am__objects_9)
++nodist_libasn1_la_OBJECTS = $(am__objects_10)
++libasn1_la_OBJECTS = $(nodist_libasn1_la_OBJECTS)
++libasn1_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libasn1_la_LDFLAGS) $(LDFLAGS) -o $@
++libasn1base_la_LIBADD =
++dist_libasn1base_la_OBJECTS = der.lo der_get.lo der_put.lo der_free.lo \
++	der_length.lo der_copy.lo der_cmp.lo der_format.lo extra.lo \
++	template.lo timegm.lo
++nodist_libasn1base_la_OBJECTS = asn1_err.lo
++libasn1base_la_OBJECTS = $(dist_libasn1base_la_OBJECTS) \
++	$(nodist_libasn1base_la_OBJECTS)
++am__EXEEXT_1 = check-der$(EXEEXT) check-gen$(EXEEXT) \
++	check-timegm$(EXEEXT) check-ber$(EXEEXT) \
++	check-template$(EXEEXT)
++PROGRAMS = $(libexec_heimdal_PROGRAMS) $(noinst_PROGRAMS)
++am_asn1_compile_OBJECTS = asn1parse.$(OBJEXT) gen.$(OBJEXT) \
++	gen_copy.$(OBJEXT) gen_decode.$(OBJEXT) gen_encode.$(OBJEXT) \
++	gen_free.$(OBJEXT) gen_glue.$(OBJEXT) gen_length.$(OBJEXT) \
++	gen_seq.$(OBJEXT) gen_template.$(OBJEXT) hash.$(OBJEXT) \
++	lex.$(OBJEXT) main.$(OBJEXT) symbol.$(OBJEXT)
++asn1_compile_OBJECTS = $(am_asn1_compile_OBJECTS)
++asn1_compile_DEPENDENCIES = $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++am_asn1_gen_OBJECTS = asn1_gen.$(OBJEXT)
++asn1_gen_OBJECTS = $(am_asn1_gen_OBJECTS)
++am__DEPENDENCIES_2 = libasn1base.la $(am__DEPENDENCIES_1)
++asn1_gen_DEPENDENCIES = $(am__DEPENDENCIES_2)
++am_asn1_print_OBJECTS = asn1_print.$(OBJEXT)
++asn1_print_OBJECTS = $(am_asn1_print_OBJECTS)
++asn1_print_DEPENDENCIES = $(am__DEPENDENCIES_2) $(am__DEPENDENCIES_1)
++check_ber_SOURCES = check-ber.c
++check_ber_OBJECTS = check-ber.$(OBJEXT)
++am__DEPENDENCIES_3 = libasn1.la $(am__DEPENDENCIES_1)
++check_ber_DEPENDENCIES = $(am__DEPENDENCIES_3)
++am_check_der_OBJECTS = check-der.$(OBJEXT) check-common.$(OBJEXT)
++check_der_OBJECTS = $(am_check_der_OBJECTS)
++check_der_DEPENDENCIES = libasn1base.la $(am__DEPENDENCIES_1)
++dist_check_gen_OBJECTS = check-gen.$(OBJEXT) check-common.$(OBJEXT)
++am__objects_11 = asn1_test_asn1.$(OBJEXT)
++nodist_check_gen_OBJECTS = $(am__objects_11)
++check_gen_OBJECTS = $(dist_check_gen_OBJECTS) \
++	$(nodist_check_gen_OBJECTS)
++check_gen_DEPENDENCIES = libasn1.la $(am__DEPENDENCIES_1)
++am_check_template_OBJECTS = check-template.$(OBJEXT) \
++	check-common.$(OBJEXT)
++nodist_check_template_OBJECTS = $(am__objects_11)
++check_template_OBJECTS = $(am_check_template_OBJECTS) \
++	$(nodist_check_template_OBJECTS)
++check_template_DEPENDENCIES = $(am__DEPENDENCIES_2)
++check_timegm_SOURCES = check-timegm.c
++check_timegm_OBJECTS = check-timegm.$(OBJEXT)
++check_timegm_DEPENDENCIES = $(am__DEPENDENCIES_2)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++@MAINTAINER_MODE_FALSE@am__skiplex = test -f $@ ||
++LEXCOMPILE = $(LEX) $(LFLAGS) $(AM_LFLAGS)
++LTLEXCOMPILE = $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(LEX) $(LFLAGS) $(AM_LFLAGS)
++YLWRAP = $(top_srcdir)/ylwrap
++@MAINTAINER_MODE_FALSE@am__skipyacc = test -f $@ ||
++YACCCOMPILE = $(YACC) $(YFLAGS) $(AM_YFLAGS)
++LTYACCCOMPILE = $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(YACC) $(YFLAGS) $(AM_YFLAGS)
++SOURCES = $(nodist_libasn1_la_SOURCES) $(dist_libasn1base_la_SOURCES) \
++	$(nodist_libasn1base_la_SOURCES) $(asn1_compile_SOURCES) \
++	$(asn1_gen_SOURCES) $(asn1_print_SOURCES) check-ber.c \
++	$(check_der_SOURCES) $(dist_check_gen_SOURCES) \
++	$(nodist_check_gen_SOURCES) $(check_template_SOURCES) \
++	$(nodist_check_template_SOURCES) check-timegm.c
++DIST_SOURCES = $(dist_libasn1base_la_SOURCES) $(asn1_compile_SOURCES) \
++	$(asn1_gen_SOURCES) $(asn1_print_SOURCES) check-ber.c \
++	$(check_der_SOURCES) $(dist_check_gen_SOURCES) \
++	$(check_template_SOURCES) check-timegm.c
++HEADERS = $(dist_include_HEADERS) $(nodist_include_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = -d -t
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++lib_LTLIBRARIES = libasn1.la
++libasn1_la_LDFLAGS = -version-info 8:0:0 $(am__append_1)
++noinst_LTLIBRARIES = libasn1base.la
++libasn1_la_LIBADD = \
++	libasn1base.la \
++	@LIB_com_err@ \
++	$(LIBADD_roken)
++
++BUILT_SOURCES = \
++	$(gen_files_rfc2459:.x=.c)	\
++	$(gen_files_cms:.x=.c)		\
++	$(gen_files_krb5:.x=.c)		\
++	$(gen_files_pkinit:.x=.c)	\
++	$(gen_files_pkcs8:.x=.c)	\
++	$(gen_files_pkcs9:.x=.c)	\
++	$(gen_files_pkcs12:.x=.c)	\
++	$(gen_files_digest:.x=.c)	\
++	$(gen_files_kx509:.x=.c)
++
++gen_files_krb5 = asn1_krb5_asn1.x
++gen_files_cms = asn1_cms_asn1.x
++gen_files_rfc2459 = asn1_rfc2459_asn1.x
++gen_files_pkinit = asn1_pkinit_asn1.x
++gen_files_pkcs12 = asn1_pkcs12_asn1.x
++gen_files_pkcs8 = asn1_pkcs8_asn1.x
++gen_files_pkcs9 = asn1_pkcs9_asn1.x
++gen_files_test = asn1_test_asn1.x
++gen_files_digest = asn1_digest_asn1.x
++gen_files_kx509 = asn1_kx509_asn1.x
++asn1_gen_SOURCES = asn1_gen.c
++asn1_print_SOURCES = asn1_print.c
++check_der_SOURCES = check-der.c check-common.c check-common.h
++check_template_SOURCES = check-template.c check-common.c check-common.h
++nodist_check_template_SOURCES = $(gen_files_test:.x=.c)
++dist_check_gen_SOURCES = check-gen.c check-common.c check-common.h
++nodist_check_gen_SOURCES = $(gen_files_test:.x=.c)
++build_HEADERZ = asn1-template.h
++asn1_compile_SOURCES = \
++	asn1_queue.h				\
++	asn1parse.y				\
++	der.h					\
++	gen.c					\
++	gen_copy.c				\
++	gen_decode.c				\
++	gen_encode.c				\
++	gen_free.c				\
++	gen_glue.c				\
++	gen_length.c				\
++	gen_locl.h				\
++	gen_seq.c				\
++	gen_template.c				\
++	hash.c					\
++	hash.h					\
++	lex.l					\
++	lex.h					\
++	main.c					\
++	asn1-template.h				\
++	symbol.c				\
++	symbol.h
++
++dist_libasn1base_la_SOURCES = \
++	der_locl.h 				\
++	der.c					\
++	der.h					\
++	der_get.c				\
++	der_put.c				\
++	der_free.c				\
++	der_length.c				\
++	der_copy.c				\
++	der_cmp.c				\
++	der_format.c				\
++	heim_asn1.h				\
++	extra.c					\
++	template.c				\
++	timegm.c
++
++nodist_libasn1base_la_SOURCES = \
++	asn1_err.h			\
++	asn1_err.c
++
++nodist_libasn1_la_SOURCES = $(BUILT_SOURCES)
++asn1_compile_LDADD = \
++	$(LIB_roken) $(LEXLIB)
++
++check_der_LDADD = \
++	libasn1base.la \
++	$(LIB_roken)
++
++check_template_LDADD = $(check_der_LDADD)
++asn1_print_LDADD = $(check_der_LDADD) $(LIB_com_err)
++asn1_gen_LDADD = $(check_der_LDADD)
++check_timegm_LDADD = $(check_der_LDADD)
++check_gen_LDADD = \
++	libasn1.la \
++	$(LIB_roken)
++
++check_ber_LDADD = $(check_gen_LDADD)
++CLEANFILES = \
++	$(BUILT_SOURCES) \
++	$(gen_files_rfc2459) \
++	$(gen_files_cms) \
++	$(gen_files_krb5) \
++	$(gen_files_pkinit) \
++	$(gen_files_pkcs8) \
++	$(gen_files_pkcs9) \
++	$(gen_files_pkcs12) \
++	$(gen_files_digest) \
++	$(gen_files_kx509) \
++	$(gen_files_test) $(nodist_check_gen_SOURCES) \
++	asn1_err.c asn1_err.h \
++	rfc2459_asn1_files rfc2459_asn1*.h* \
++	cms_asn1_files cms_asn1*.h* \
++	krb5_asn1_files krb5_asn1*.h* \
++	pkinit_asn1_files pkinit_asn1*.h* \
++	pkcs8_asn1_files pkcs8_asn1*.h* \
++	pkcs9_asn1_files pkcs9_asn1*.h* \
++	pkcs12_asn1_files pkcs12_asn1*.h* \
++	digest_asn1_files digest_asn1*.h* \
++	kx509_asn1_files kx509_asn1*.h* \
++	test_asn1_files test_asn1*.h*
++
++dist_include_HEADERS = der.h heim_asn1.h der-protos.h der-private.h \
++	asn1-common.h
++nodist_include_HEADERS = asn1_err.h krb5_asn1.h pkinit_asn1.h \
++	cms_asn1.h rfc2459_asn1.h pkcs8_asn1.h pkcs9_asn1.h \
++	pkcs12_asn1.h digest_asn1.h kx509_asn1.h
++priv_headers = krb5_asn1-priv.h pkinit_asn1-priv.h cms_asn1-priv.h \
++	rfc2459_asn1-priv.h pkcs8_asn1-priv.h pkcs9_asn1-priv.h \
++	pkcs12_asn1-priv.h digest_asn1-priv.h kx509_asn1-priv.h \
++	test_asn1.h test_asn1-priv.h
++EXTRA_DIST = \
++	cms.asn1	\
++	cms.opt		\
++	asn1_err.et	\
++	canthandle.asn1	\
++	digest.asn1	\
++	krb5.asn1	\
++	krb5.opt	\
++	kx509.asn1	\
++	pkcs12.asn1	\
++	pkcs8.asn1	\
++	pkcs9.asn1	\
++	pkinit.asn1	\
++	rfc2459.asn1	\
++	setchgpw2.asn1	\
++	test.asn1	\
++	test.gen	\
++	version-script.map
++
++all: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .l .lo .o .obj .y
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/asn1/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/asn1/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++
++clean-noinstLTLIBRARIES:
++	-test -z "$(noinst_LTLIBRARIES)" || rm -f $(noinst_LTLIBRARIES)
++	@list='$(noinst_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libasn1.la: $(libasn1_la_OBJECTS) $(libasn1_la_DEPENDENCIES) 
++	$(libasn1_la_LINK) -rpath $(libdir) $(libasn1_la_OBJECTS) $(libasn1_la_LIBADD) $(LIBS)
++libasn1base.la: $(libasn1base_la_OBJECTS) $(libasn1base_la_DEPENDENCIES) 
++	$(LINK)  $(libasn1base_la_OBJECTS) $(libasn1base_la_LIBADD) $(LIBS)
++
++clean-checkPROGRAMS:
++	@list='$(check_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++install-libexec_heimdalPROGRAMS: $(libexec_heimdal_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexec_heimdaldir)" || $(MKDIR_P) "$(DESTDIR)$(libexec_heimdaldir)"
++	@list='$(libexec_heimdal_PROGRAMS)'; test -n "$(libexec_heimdaldir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexec_heimdaldir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexec_heimdaldir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexec_heimdalPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_heimdal_PROGRAMS)'; test -n "$(libexec_heimdaldir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexec_heimdaldir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexec_heimdaldir)" && rm -f $$files
++
++clean-libexec_heimdalPROGRAMS:
++	@list='$(libexec_heimdal_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++asn1_compile$(EXEEXT): $(asn1_compile_OBJECTS) $(asn1_compile_DEPENDENCIES) 
++	@rm -f asn1_compile$(EXEEXT)
++	$(LINK) $(asn1_compile_OBJECTS) $(asn1_compile_LDADD) $(LIBS)
++asn1_gen$(EXEEXT): $(asn1_gen_OBJECTS) $(asn1_gen_DEPENDENCIES) 
++	@rm -f asn1_gen$(EXEEXT)
++	$(LINK) $(asn1_gen_OBJECTS) $(asn1_gen_LDADD) $(LIBS)
++asn1_print$(EXEEXT): $(asn1_print_OBJECTS) $(asn1_print_DEPENDENCIES) 
++	@rm -f asn1_print$(EXEEXT)
++	$(LINK) $(asn1_print_OBJECTS) $(asn1_print_LDADD) $(LIBS)
++check-ber$(EXEEXT): $(check_ber_OBJECTS) $(check_ber_DEPENDENCIES) 
++	@rm -f check-ber$(EXEEXT)
++	$(LINK) $(check_ber_OBJECTS) $(check_ber_LDADD) $(LIBS)
++check-der$(EXEEXT): $(check_der_OBJECTS) $(check_der_DEPENDENCIES) 
++	@rm -f check-der$(EXEEXT)
++	$(LINK) $(check_der_OBJECTS) $(check_der_LDADD) $(LIBS)
++check-gen$(EXEEXT): $(check_gen_OBJECTS) $(check_gen_DEPENDENCIES) 
++	@rm -f check-gen$(EXEEXT)
++	$(LINK) $(check_gen_OBJECTS) $(check_gen_LDADD) $(LIBS)
++check-template$(EXEEXT): $(check_template_OBJECTS) $(check_template_DEPENDENCIES) 
++	@rm -f check-template$(EXEEXT)
++	$(LINK) $(check_template_OBJECTS) $(check_template_LDADD) $(LIBS)
++check-timegm$(EXEEXT): $(check_timegm_OBJECTS) $(check_timegm_DEPENDENCIES) 
++	@rm -f check-timegm$(EXEEXT)
++	$(LINK) $(check_timegm_OBJECTS) $(check_timegm_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_cms_asn1.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_digest_asn1.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_err.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_gen.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_krb5_asn1.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_kx509_asn1.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_pkcs12_asn1.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_pkcs8_asn1.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_pkcs9_asn1.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_pkinit_asn1.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_print.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_rfc2459_asn1.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_test_asn1.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1parse.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/check-ber.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/check-common.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/check-der.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/check-gen.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/check-template.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/check-timegm.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/der.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/der_cmp.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/der_copy.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/der_format.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/der_free.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/der_get.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/der_length.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/der_put.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/extra.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gen.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gen_copy.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gen_decode.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gen_encode.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gen_free.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gen_glue.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gen_length.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gen_seq.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gen_template.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hash.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/lex.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/main.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/symbol.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/template.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/timegm.Plo@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++.l.c:
++	$(am__skiplex) $(SHELL) $(YLWRAP) $< $(LEX_OUTPUT_ROOT).c $@ -- $(LEXCOMPILE)
++
++.y.c:
++	$(am__skipyacc) $(SHELL) $(YLWRAP) $< y.tab.c $@ y.tab.h $*.h y.output $*.output -- $(YACCCOMPILE)
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-dist_includeHEADERS: $(dist_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(dist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-dist_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(dist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++install-nodist_includeHEADERS: $(nodist_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-nodist_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(HEADERS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(libexec_heimdaldir)" "$(DESTDIR)$(includedir)" "$(DESTDIR)$(includedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++	-rm -f asn1parse.c
++	-rm -f asn1parse.h
++	-rm -f lex.c
++	-test -z "$(BUILT_SOURCES)" || rm -f $(BUILT_SOURCES)
++clean: clean-am
++
++clean-am: clean-checkPROGRAMS clean-generic clean-libLTLIBRARIES \
++	clean-libexec_heimdalPROGRAMS clean-libtool \
++	clean-noinstLTLIBRARIES clean-noinstPROGRAMS mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-dist_includeHEADERS \
++	install-nodist_includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libLTLIBRARIES \
++	install-libexec_heimdalPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-dist_includeHEADERS uninstall-libLTLIBRARIES \
++	uninstall-libexec_heimdalPROGRAMS \
++	uninstall-nodist_includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: all check check-am install install-am install-data-am \
++	install-exec-am install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-TESTS check-am \
++	check-local clean clean-checkPROGRAMS clean-generic \
++	clean-libLTLIBRARIES clean-libexec_heimdalPROGRAMS \
++	clean-libtool clean-noinstLTLIBRARIES clean-noinstPROGRAMS \
++	ctags dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dist_includeHEADERS \
++	install-dvi install-dvi-am install-exec install-exec-am \
++	install-exec-hook install-html install-html-am install-info \
++	install-info-am install-libLTLIBRARIES \
++	install-libexec_heimdalPROGRAMS install-man \
++	install-nodist_includeHEADERS install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-dist_includeHEADERS \
++	uninstall-hook uninstall-libLTLIBRARIES \
++	uninstall-libexec_heimdalPROGRAMS \
++	uninstall-nodist_includeHEADERS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(asn1_compile_OBJECTS): asn1parse.h asn1parse.c $(srcdir)/der-protos.h $(srcdir)/der-private.h
++$(libasn1_la_OBJECTS): $(nodist_include_HEADERS) $(priv_headers) asn1_err.h $(srcdir)/der-protos.h $(srcdir)/der-private.h
++$(libasn1base_la_OBJECTS): asn1_err.h $(srcdir)/der-protos.h $(srcdir)/der-private.h
++$(check_gen_OBJECTS): test_asn1.h
++$(check_template_OBJECTS): test_asn1_files
++$(asn1_print_OBJECTS): krb5_asn1.h
++
++asn1parse.h: asn1parse.c
++
++$(gen_files_krb5) krb5_asn1.hx krb5_asn1-priv.hx: krb5_asn1_files
++$(gen_files_pkinit) pkinit_asn1.hx pkinit_asn1-priv.hx: pkinit_asn1_files
++$(gen_files_pkcs8) pkcs8_asn1.hx pkcs8_asn1-priv.hx: pkcs8_asn1_files
++$(gen_files_pkcs9) pkcs9_asn1.hx pkcs9_asn1-priv.hx: pkcs9_asn1_files
++$(gen_files_pkcs12) pkcs12_asn1.hx pkcs12_asn1-priv.hx: pkcs12_asn1_files
++$(gen_files_digest) digest_asn1.hx digest_asn1-priv.hx: digest_asn1_files
++$(gen_files_kx509) kx509_asn1.hx kx509_asn1-priv.hx: kx509_asn1_files
++$(gen_files_rfc2459) rfc2459_asn1.hx rfc2459_asn1-priv.hx: rfc2459_asn1_files
++$(gen_files_cms) cms_asn1.hx cms_asn1-priv.hx: cms_asn1_files
++$(gen_files_test) test_asn1.hx test_asn1-priv.hx: test_asn1_files
++
++rfc2459_asn1_files: asn1_compile$(EXEEXT) $(srcdir)/rfc2459.asn1
++	$(ASN1_COMPILE) --one-code-file --preserve-binary=TBSCertificate --preserve-binary=TBSCRLCertList --preserve-binary=Name --sequence=GeneralNames --sequence=Extensions --sequence=CRLDistributionPoints $(srcdir)/rfc2459.asn1 rfc2459_asn1 || (rm -f rfc2459_asn1_files ; exit 1)
++
++cms_asn1_files: asn1_compile$(EXEEXT) $(srcdir)/cms.asn1 $(srcdir)/cms.opt
++	$(ASN1_COMPILE) --one-code-file --option-file=$(srcdir)/cms.opt $(srcdir)/cms.asn1 cms_asn1 || (rm -f cms_asn1_files ; exit 1)
++
++krb5_asn1_files: asn1_compile$(EXEEXT) $(srcdir)/krb5.asn1 $(srcdir)/krb5.opt
++	$(ASN1_COMPILE) --one-code-file --option-file=$(srcdir)/krb5.opt $(srcdir)/krb5.asn1 krb5_asn1 || (rm -f krb5_asn1_files ; exit 1)
++
++pkinit_asn1_files: asn1_compile$(EXEEXT) $(srcdir)/pkinit.asn1
++	$(ASN1_COMPILE) --one-code-file $(srcdir)/pkinit.asn1 pkinit_asn1 || (rm -f pkinit_asn1_files ; exit 1)
++
++pkcs8_asn1_files: asn1_compile$(EXEEXT) $(srcdir)/pkcs8.asn1
++	$(ASN1_COMPILE) --one-code-file $(srcdir)/pkcs8.asn1 pkcs8_asn1 || (rm -f pkcs8_asn1_files ; exit 1)
++
++pkcs9_asn1_files: asn1_compile$(EXEEXT) $(srcdir)/pkcs9.asn1
++	$(ASN1_COMPILE) --one-code-file $(srcdir)/pkcs9.asn1 pkcs9_asn1 || (rm -f pkcs9_asn1_files ; exit 1)
++
++pkcs12_asn1_files: asn1_compile$(EXEEXT) $(srcdir)/pkcs12.asn1
++	$(ASN1_COMPILE) --one-code-file $(srcdir)/pkcs12.asn1 pkcs12_asn1 || (rm -f pkcs12_asn1_files ; exit 1)
++
++digest_asn1_files: asn1_compile$(EXEEXT) $(srcdir)/digest.asn1
++	$(ASN1_COMPILE) --one-code-file $(srcdir)/digest.asn1 digest_asn1 || (rm -f digest_asn1_files ; exit 1)
++
++kx509_asn1_files: asn1_compile$(EXEEXT) $(srcdir)/kx509.asn1
++	$(ASN1_COMPILE) --one-code-file $(srcdir)/kx509.asn1 kx509_asn1 || (rm -f kx509_asn1_files ; exit 1)
++
++test_asn1_files: asn1_compile$(EXEEXT) $(srcdir)/test.asn1
++	$(ASN1_COMPILE) --one-code-file --sequence=TESTSeqOf $(srcdir)/test.asn1 test_asn1 || (rm -f test_asn1_files ; exit 1)
++
++$(srcdir)/der-protos.h:
++	cd $(srcdir) && perl ../../cf/make-proto.pl -q -P comment -o der-protos.h $(dist_libasn1base_la_SOURCES) || rm -f der-protos.h
++
++$(srcdir)/der-private.h:
++	cd $(srcdir) && perl ../../cf/make-proto.pl -q -P comment -p der-private.h $(dist_libasn1base_la_SOURCES) || rm -f der-private.h
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/com_err/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/com_err/Makefile.in	2010-12-29 04:07:08.345798453 +0100
+@@ -0,0 +1,1040 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(include_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog lex.c parse.c \
++	parse.h
++@versionscript_TRUE@am__append_1 = $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-script.map
++bin_PROGRAMS = compile_et$(EXEEXT)
++subdir = lib/com_err
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(bindir)" \
++	"$(DESTDIR)$(includedir)"
++LTLIBRARIES = $(lib_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++libcom_err_la_DEPENDENCIES = $(am__DEPENDENCIES_1)
++dist_libcom_err_la_OBJECTS = libcom_err_la-error.lo \
++	libcom_err_la-com_err.lo
++@do_roken_rename_TRUE@nodist_libcom_err_la_OBJECTS =  \
++@do_roken_rename_TRUE@	libcom_err_la-snprintf.lo \
++@do_roken_rename_TRUE@	libcom_err_la-strlcpy.lo
++libcom_err_la_OBJECTS = $(dist_libcom_err_la_OBJECTS) \
++	$(nodist_libcom_err_la_OBJECTS)
++libcom_err_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libcom_err_la_LDFLAGS) $(LDFLAGS) -o $@
++PROGRAMS = $(bin_PROGRAMS)
++am_compile_et_OBJECTS = compile_et.$(OBJEXT) parse.$(OBJEXT) \
++	lex.$(OBJEXT)
++compile_et_OBJECTS = $(am_compile_et_OBJECTS)
++compile_et_DEPENDENCIES = libcom_err.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++@MAINTAINER_MODE_FALSE@am__skiplex = test -f $@ ||
++LEXCOMPILE = $(LEX) $(LFLAGS) $(AM_LFLAGS)
++LTLEXCOMPILE = $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(LEX) $(LFLAGS) $(AM_LFLAGS)
++YLWRAP = $(top_srcdir)/ylwrap
++@MAINTAINER_MODE_FALSE@am__skipyacc = test -f $@ ||
++YACCCOMPILE = $(YACC) $(YFLAGS) $(AM_YFLAGS)
++LTYACCCOMPILE = $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(YACC) $(YFLAGS) $(AM_YFLAGS)
++SOURCES = $(dist_libcom_err_la_SOURCES) \
++	$(nodist_libcom_err_la_SOURCES) $(compile_et_SOURCES)
++DIST_SOURCES = $(dist_libcom_err_la_SOURCES) $(compile_et_SOURCES)
++HEADERS = $(include_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = -d
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++lib_LTLIBRARIES = libcom_err.la
++libcom_err_la_LDFLAGS = -version-info 2:3:1 $(am__append_1)
++libcom_err_la_LIBADD = $(LIB_libintl)
++include_HEADERS = com_err.h com_right.h
++compile_et_SOURCES = compile_et.c compile_et.h parse.y lex.l lex.h
++libcom_err_la_CPPFLAGS = $(ROKEN_RENAME) $(INCLUDE_libintl)
++dist_libcom_err_la_SOURCES = error.c com_err.c roken_rename.h
++@do_roken_rename_TRUE@nodist_libcom_err_la_SOURCES = snprintf.c strlcpy.c
++compile_et_LDADD = \
++	libcom_err.la \
++	$(LIB_roken) \
++	$(LEXLIB)
++
++EXTRA_DIST = version-script.map
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .l .lo .o .obj .y
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/com_err/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/com_err/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libcom_err.la: $(libcom_err_la_OBJECTS) $(libcom_err_la_DEPENDENCIES) 
++	$(libcom_err_la_LINK) -rpath $(libdir) $(libcom_err_la_OBJECTS) $(libcom_err_la_LIBADD) $(LIBS)
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++parse.h: parse.c
++	@if test ! -f $@; then \
++	  rm -f parse.c; \
++	  $(MAKE) $(AM_MAKEFLAGS) parse.c; \
++	else :; fi
++compile_et$(EXEEXT): $(compile_et_OBJECTS) $(compile_et_DEPENDENCIES) 
++	@rm -f compile_et$(EXEEXT)
++	$(LINK) $(compile_et_OBJECTS) $(compile_et_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/compile_et.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/lex.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libcom_err_la-com_err.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libcom_err_la-error.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libcom_err_la-snprintf.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libcom_err_la-strlcpy.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/parse.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++libcom_err_la-error.lo: error.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libcom_err_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libcom_err_la-error.lo -MD -MP -MF $(DEPDIR)/libcom_err_la-error.Tpo -c -o libcom_err_la-error.lo `test -f 'error.c' || echo '$(srcdir)/'`error.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libcom_err_la-error.Tpo $(DEPDIR)/libcom_err_la-error.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='error.c' object='libcom_err_la-error.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libcom_err_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libcom_err_la-error.lo `test -f 'error.c' || echo '$(srcdir)/'`error.c
++
++libcom_err_la-com_err.lo: com_err.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libcom_err_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libcom_err_la-com_err.lo -MD -MP -MF $(DEPDIR)/libcom_err_la-com_err.Tpo -c -o libcom_err_la-com_err.lo `test -f 'com_err.c' || echo '$(srcdir)/'`com_err.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libcom_err_la-com_err.Tpo $(DEPDIR)/libcom_err_la-com_err.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='com_err.c' object='libcom_err_la-com_err.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libcom_err_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libcom_err_la-com_err.lo `test -f 'com_err.c' || echo '$(srcdir)/'`com_err.c
++
++libcom_err_la-snprintf.lo: snprintf.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libcom_err_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libcom_err_la-snprintf.lo -MD -MP -MF $(DEPDIR)/libcom_err_la-snprintf.Tpo -c -o libcom_err_la-snprintf.lo `test -f 'snprintf.c' || echo '$(srcdir)/'`snprintf.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libcom_err_la-snprintf.Tpo $(DEPDIR)/libcom_err_la-snprintf.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='snprintf.c' object='libcom_err_la-snprintf.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libcom_err_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libcom_err_la-snprintf.lo `test -f 'snprintf.c' || echo '$(srcdir)/'`snprintf.c
++
++libcom_err_la-strlcpy.lo: strlcpy.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libcom_err_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libcom_err_la-strlcpy.lo -MD -MP -MF $(DEPDIR)/libcom_err_la-strlcpy.Tpo -c -o libcom_err_la-strlcpy.lo `test -f 'strlcpy.c' || echo '$(srcdir)/'`strlcpy.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libcom_err_la-strlcpy.Tpo $(DEPDIR)/libcom_err_la-strlcpy.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='strlcpy.c' object='libcom_err_la-strlcpy.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libcom_err_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libcom_err_la-strlcpy.lo `test -f 'strlcpy.c' || echo '$(srcdir)/'`strlcpy.c
++
++.l.c:
++	$(am__skiplex) $(SHELL) $(YLWRAP) $< $(LEX_OUTPUT_ROOT).c $@ -- $(LEXCOMPILE)
++
++.y.c:
++	$(am__skipyacc) $(SHELL) $(YLWRAP) $< y.tab.c $@ y.tab.h $*.h y.output $*.output -- $(YACCCOMPILE)
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-includeHEADERS: $(include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(HEADERS) all-local
++install-binPROGRAMS: install-libLTLIBRARIES
++
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(bindir)" "$(DESTDIR)$(includedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++	-rm -f lex.c
++	-rm -f parse.c
++	-rm -f parse.h
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-generic clean-libLTLIBRARIES \
++	clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-includeHEADERS \
++	uninstall-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-binPROGRAMS clean-generic clean-libLTLIBRARIES \
++	clean-libtool ctags dist-hook distclean distclean-compile \
++	distclean-generic distclean-libtool distclean-tags distdir dvi \
++	dvi-am html html-am info info-am install install-am \
++	install-binPROGRAMS install-data install-data-am \
++	install-data-hook install-dvi install-dvi-am install-exec \
++	install-exec-am install-exec-hook install-html install-html-am \
++	install-includeHEADERS install-info install-info-am \
++	install-libLTLIBRARIES install-man install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-binPROGRAMS \
++	uninstall-hook uninstall-includeHEADERS \
++	uninstall-libLTLIBRARIES
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(compile_et_OBJECTS): parse.h parse.c ## XXX broken automake 1.4s
++
++snprintf.c:
++	$(LN_S) $(srcdir)/../roken/snprintf.c .
++strlcpy.c:
++	$(LN_S) $(srcdir)/../roken/strlcpy.c .
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/editline/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/editline/Makefile.in	2010-12-29 04:07:08.565867373 +0100
+@@ -0,0 +1,1030 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = README $(include_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++noinst_PROGRAMS = testit$(EXEEXT)
++subdir = lib/editline
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(man3dir)" \
++	"$(DESTDIR)$(includedir)"
++LTLIBRARIES = $(lib_LTLIBRARIES) $(noinst_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++libeditline_la_DEPENDENCIES = $(am__DEPENDENCIES_1)
++am__libeditline_la_SOURCES_DIST = edit_locl.h complete.c editline.c \
++	sysunix.c editline.h roken_rename.h unix.h snprintf.c strdup.c \
++	strlcat.c
++@do_roken_rename_TRUE@am__objects_1 = snprintf.lo strdup.lo strlcat.lo
++am__objects_2 = $(am__objects_1)
++am_libeditline_la_OBJECTS = complete.lo editline.lo sysunix.lo \
++	$(am__objects_2)
++libeditline_la_OBJECTS = $(am_libeditline_la_OBJECTS)
++libel_compat_la_LIBADD =
++am_libel_compat_la_OBJECTS = edit_compat.lo
++libel_compat_la_OBJECTS = $(am_libel_compat_la_OBJECTS)
++@el_compat_TRUE@am_libel_compat_la_rpath =
++PROGRAMS = $(noinst_PROGRAMS)
++testit_SOURCES = testit.c
++testit_OBJECTS = testit.$(OBJEXT)
++testit_DEPENDENCIES = libeditline.la $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(libeditline_la_SOURCES) $(libel_compat_la_SOURCES) \
++	testit.c
++DIST_SOURCES = $(am__libeditline_la_SOURCES_DIST) \
++	$(libel_compat_la_SOURCES) testit.c
++man3dir = $(mandir)/man3
++MANS = $(man_MANS)
++HEADERS = $(include_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(ROKEN_RENAME)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++@do_roken_rename_TRUE@ES = snprintf.c strdup.c strlcat.c
++man_MANS = editline.3
++lib_LTLIBRARIES = libeditline.la
++@el_compat_TRUE@noinst_LTLIBRARIES = libel_compat.la
++CHECK_LOCAL = 
++testit_LDADD = \
++	libeditline.la \
++	$(LIB_roken)
++
++include_HEADERS = editline.h
++libeditline_la_LIBADD = $(LIB_tgetent)
++libeditline_la_SOURCES = \
++	edit_locl.h \
++	complete.c \
++	editline.c \
++	sysunix.c \
++	editline.h \
++	roken_rename.h \
++	unix.h \
++	$(EXTRA_SOURCE)
++
++EXTRA_SOURCE = $(ES) 
++libel_compat_la_SOURCES = edit_compat.c edit_compat.h
++EXTRA_DIST = $(man_MANS)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/editline/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/editline/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++
++clean-noinstLTLIBRARIES:
++	-test -z "$(noinst_LTLIBRARIES)" || rm -f $(noinst_LTLIBRARIES)
++	@list='$(noinst_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libeditline.la: $(libeditline_la_OBJECTS) $(libeditline_la_DEPENDENCIES) 
++	$(LINK) -rpath $(libdir) $(libeditline_la_OBJECTS) $(libeditline_la_LIBADD) $(LIBS)
++libel_compat.la: $(libel_compat_la_OBJECTS) $(libel_compat_la_DEPENDENCIES) 
++	$(LINK) $(am_libel_compat_la_rpath) $(libel_compat_la_OBJECTS) $(libel_compat_la_LIBADD) $(LIBS)
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++testit$(EXEEXT): $(testit_OBJECTS) $(testit_DEPENDENCIES) 
++	@rm -f testit$(EXEEXT)
++	$(LINK) $(testit_OBJECTS) $(testit_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/complete.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/edit_compat.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/editline.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/snprintf.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/strdup.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/strlcat.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/sysunix.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/testit.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man3: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man3dir)" || $(MKDIR_P) "$(DESTDIR)$(man3dir)"
++	@list=''; test -n "$(man3dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.3[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^3][0-9a-z]*$$,3,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man3dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man3dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man3dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man3dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man3:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man3dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.3[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^3][0-9a-z]*$$,3,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man3dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man3dir)" && rm -f $$files; }
++install-includeHEADERS: $(include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(MANS) $(HEADERS) \
++		all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(man3dir)" "$(DESTDIR)$(includedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libLTLIBRARIES clean-libtool \
++	clean-noinstLTLIBRARIES clean-noinstPROGRAMS mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-includeHEADERS install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man3
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-includeHEADERS uninstall-libLTLIBRARIES \
++	uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man3
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libLTLIBRARIES clean-libtool \
++	clean-noinstLTLIBRARIES clean-noinstPROGRAMS ctags dist-hook \
++	distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-includeHEADERS install-info \
++	install-info-am install-libLTLIBRARIES install-man \
++	install-man3 install-pdf install-pdf-am install-ps \
++	install-ps-am install-strip installcheck installcheck-am \
++	installdirs maintainer-clean maintainer-clean-generic \
++	mostlyclean mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags uninstall \
++	uninstall-am uninstall-hook uninstall-includeHEADERS \
++	uninstall-libLTLIBRARIES uninstall-man uninstall-man3
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++snprintf.c:
++	$(LN_S) $(srcdir)/../roken/snprintf.c .
++strdup.c:
++	$(LN_S) $(srcdir)/../roken/strdup.c .
++strlcat.c:
++	$(LN_S) $(srcdir)/../roken/strlcat.c .
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/gssapi/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/gssapi/Makefile.in	2010-12-29 04:07:08.945986420 +0100
+@@ -0,0 +1,2441 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(include_HEADERS) $(nobase_include_HEADERS) \
++	$(noinst_HEADERS) $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++@versionscript_TRUE@am__append_1 = $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-script.map
++TESTS = test_oid$(EXEEXT) test_names$(EXEEXT) test_cfx$(EXEEXT)
++check_PROGRAMS = test_acquire_cred$(EXEEXT) $(am__EXEEXT_1)
++bin_PROGRAMS = gsstool$(EXEEXT)
++noinst_PROGRAMS = test_cred$(EXEEXT) test_kcred$(EXEEXT) \
++	test_context$(EXEEXT) test_ntlm$(EXEEXT)
++subdir = lib/gssapi
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(bindir)" \
++	"$(DESTDIR)$(man3dir)" "$(DESTDIR)$(man5dir)" \
++	"$(DESTDIR)$(includedir)" "$(DESTDIR)$(includedir)" \
++	"$(DESTDIR)$(gssapidir)"
++LTLIBRARIES = $(lib_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++libgssapi_la_DEPENDENCIES = $(top_builddir)/lib/ntlm/libheimntlm.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++am__dirstamp = $(am__leading_dot)dirstamp
++am__objects_1 = krb5/8003.lo krb5/accept_sec_context.lo \
++	krb5/acquire_cred.lo krb5/add_cred.lo \
++	krb5/address_to_krb5addr.lo krb5/aeap.lo krb5/arcfour.lo \
++	krb5/canonicalize_name.lo krb5/creds.lo krb5/ccache_name.lo \
++	krb5/cfx.lo krb5/compare_name.lo krb5/compat.lo \
++	krb5/context_time.lo krb5/copy_ccache.lo krb5/decapsulate.lo \
++	krb5/delete_sec_context.lo krb5/display_name.lo \
++	krb5/display_status.lo krb5/duplicate_name.lo \
++	krb5/encapsulate.lo krb5/export_name.lo \
++	krb5/export_sec_context.lo krb5/external.lo krb5/get_mic.lo \
++	krb5/import_name.lo krb5/import_sec_context.lo \
++	krb5/indicate_mechs.lo krb5/init.lo krb5/init_sec_context.lo \
++	krb5/inquire_context.lo krb5/inquire_cred.lo \
++	krb5/inquire_cred_by_mech.lo krb5/inquire_cred_by_oid.lo \
++	krb5/inquire_mechs_for_name.lo krb5/inquire_names_for_mech.lo \
++	krb5/inquire_sec_context_by_oid.lo \
++	krb5/process_context_token.lo krb5/prf.lo \
++	krb5/release_buffer.lo krb5/release_cred.lo \
++	krb5/release_name.lo krb5/sequence.lo krb5/store_cred.lo \
++	krb5/set_cred_option.lo krb5/set_sec_context_option.lo \
++	krb5/ticket_flags.lo krb5/unwrap.lo krb5/verify_mic.lo \
++	krb5/wrap.lo
++am__objects_2 = mech/context.lo mech/doxygen.lo \
++	mech/gss_accept_sec_context.lo mech/gss_acquire_cred.lo \
++	mech/gss_add_cred.lo mech/gss_add_oid_set_member.lo \
++	mech/gss_aeap.lo mech/gss_buffer_set.lo \
++	mech/gss_canonicalize_name.lo mech/gss_compare_name.lo \
++	mech/gss_context_time.lo mech/gss_create_empty_oid_set.lo \
++	mech/gss_cred.lo mech/gss_decapsulate_token.lo \
++	mech/gss_delete_sec_context.lo mech/gss_display_name.lo \
++	mech/gss_display_status.lo mech/gss_duplicate_name.lo \
++	mech/gss_duplicate_oid.lo mech/gss_encapsulate_token.lo \
++	mech/gss_export_name.lo mech/gss_export_sec_context.lo \
++	mech/gss_get_mic.lo mech/gss_import_name.lo \
++	mech/gss_import_sec_context.lo mech/gss_indicate_mechs.lo \
++	mech/gss_init_sec_context.lo mech/gss_inquire_context.lo \
++	mech/gss_inquire_cred.lo mech/gss_inquire_cred_by_mech.lo \
++	mech/gss_inquire_cred_by_oid.lo \
++	mech/gss_inquire_mechs_for_name.lo \
++	mech/gss_inquire_names_for_mech.lo mech/gss_krb5.lo \
++	mech/gss_mech_switch.lo mech/gss_mo.lo mech/gss_names.lo \
++	mech/gss_oid.lo mech/gss_oid_equal.lo mech/gss_oid_to_str.lo \
++	mech/gss_process_context_token.lo mech/gss_pseudo_random.lo \
++	mech/gss_release_buffer.lo mech/gss_release_cred.lo \
++	mech/gss_release_name.lo mech/gss_release_oid.lo \
++	mech/gss_release_oid_set.lo mech/gss_seal.lo \
++	mech/gss_set_cred_option.lo mech/gss_set_sec_context_option.lo \
++	mech/gss_sign.lo mech/gss_store_cred.lo \
++	mech/gss_test_oid_set_member.lo mech/gss_unseal.lo \
++	mech/gss_unwrap.lo mech/gss_utils.lo mech/gss_verify.lo \
++	mech/gss_verify_mic.lo mech/gss_wrap.lo \
++	mech/gss_wrap_size_limit.lo \
++	mech/gss_inquire_sec_context_by_oid.lo
++am__objects_3 = ntlm/accept_sec_context.lo ntlm/acquire_cred.lo \
++	ntlm/add_cred.lo ntlm/canonicalize_name.lo \
++	ntlm/compare_name.lo ntlm/context_time.lo ntlm/crypto.lo \
++	ntlm/delete_sec_context.lo ntlm/display_name.lo \
++	ntlm/display_status.lo ntlm/duplicate_name.lo \
++	ntlm/export_name.lo ntlm/export_sec_context.lo \
++	ntlm/external.lo ntlm/import_name.lo \
++	ntlm/import_sec_context.lo ntlm/indicate_mechs.lo \
++	ntlm/init_sec_context.lo ntlm/inquire_context.lo \
++	ntlm/inquire_cred.lo ntlm/inquire_cred_by_mech.lo \
++	ntlm/inquire_mechs_for_name.lo ntlm/inquire_names_for_mech.lo \
++	ntlm/process_context_token.lo ntlm/release_cred.lo \
++	ntlm/release_name.lo ntlm/kdc.lo
++am__objects_4 = spnego/accept_sec_context.lo spnego/compat.lo \
++	spnego/context_stubs.lo spnego/cred_stubs.lo \
++	spnego/external.lo spnego/init_sec_context.lo
++dist_libgssapi_la_OBJECTS = $(am__objects_1) $(am__objects_2) \
++	$(am__objects_3) $(am__objects_4)
++am__objects_5 = asn1_ContextFlags.lo asn1_MechType.lo \
++	asn1_MechTypeList.lo asn1_NegotiationToken.lo \
++	asn1_NegotiationTokenWin.lo asn1_NegHints.lo \
++	asn1_NegTokenInit.lo asn1_NegTokenInitWin.lo \
++	asn1_NegTokenResp.lo
++am__objects_6 = asn1_GSSAPIContextToken.lo
++am__objects_7 = $(am__objects_5) $(am__objects_6)
++nodist_libgssapi_la_OBJECTS = gkrb5_err.lo $(am__objects_7)
++libgssapi_la_OBJECTS = $(dist_libgssapi_la_OBJECTS) \
++	$(nodist_libgssapi_la_OBJECTS)
++libgssapi_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libgssapi_la_LDFLAGS) $(LDFLAGS) -o $@
++am__EXEEXT_1 = test_oid$(EXEEXT) test_names$(EXEEXT) test_cfx$(EXEEXT)
++PROGRAMS = $(bin_PROGRAMS) $(noinst_PROGRAMS)
++dist_gsstool_OBJECTS = gsstool.$(OBJEXT)
++nodist_gsstool_OBJECTS = gss-commands.$(OBJEXT)
++gsstool_OBJECTS = $(dist_gsstool_OBJECTS) $(nodist_gsstool_OBJECTS)
++gsstool_DEPENDENCIES = libgssapi.la $(top_builddir)/lib/sl/libsl.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++am_test_acquire_cred_OBJECTS = test_acquire_cred.$(OBJEXT) \
++	test_common.$(OBJEXT)
++test_acquire_cred_OBJECTS = $(am_test_acquire_cred_OBJECTS)
++test_acquire_cred_LDADD = $(LDADD)
++test_acquire_cred_DEPENDENCIES = libgssapi.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1)
++am_test_cfx_OBJECTS = krb5/test_cfx.$(OBJEXT)
++test_cfx_OBJECTS = $(am_test_cfx_OBJECTS)
++test_cfx_LDADD = $(LDADD)
++test_cfx_DEPENDENCIES = libgssapi.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1)
++am_test_context_OBJECTS = test_context.$(OBJEXT) test_common.$(OBJEXT)
++test_context_OBJECTS = $(am_test_context_OBJECTS)
++test_context_LDADD = $(LDADD)
++test_context_DEPENDENCIES = libgssapi.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1)
++test_cred_SOURCES = test_cred.c
++test_cred_OBJECTS = test_cred.$(OBJEXT)
++test_cred_LDADD = $(LDADD)
++test_cred_DEPENDENCIES = libgssapi.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1)
++test_kcred_SOURCES = test_kcred.c
++test_kcred_OBJECTS = test_kcred.$(OBJEXT)
++test_kcred_LDADD = $(LDADD)
++test_kcred_DEPENDENCIES = libgssapi.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1)
++test_names_SOURCES = test_names.c
++test_names_OBJECTS = test_names.$(OBJEXT)
++test_names_LDADD = $(LDADD)
++test_names_DEPENDENCIES = libgssapi.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1)
++am_test_ntlm_OBJECTS = test_ntlm.$(OBJEXT) test_common.$(OBJEXT)
++test_ntlm_OBJECTS = $(am_test_ntlm_OBJECTS)
++am__DEPENDENCIES_2 = libgssapi.la $(top_builddir)/lib/krb5/libkrb5.la \
++	$(am__DEPENDENCIES_1)
++test_ntlm_DEPENDENCIES = $(top_builddir)/lib/ntlm/libheimntlm.la \
++	$(am__DEPENDENCIES_2)
++test_oid_SOURCES = test_oid.c
++test_oid_OBJECTS = test_oid.$(OBJEXT)
++test_oid_LDADD = $(LDADD)
++test_oid_DEPENDENCIES = libgssapi.la \
++	$(top_builddir)/lib/krb5/libkrb5.la $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(dist_libgssapi_la_SOURCES) $(nodist_libgssapi_la_SOURCES) \
++	$(dist_gsstool_SOURCES) $(nodist_gsstool_SOURCES) \
++	$(test_acquire_cred_SOURCES) $(test_cfx_SOURCES) \
++	$(test_context_SOURCES) test_cred.c test_kcred.c test_names.c \
++	$(test_ntlm_SOURCES) test_oid.c
++DIST_SOURCES = $(dist_libgssapi_la_SOURCES) $(dist_gsstool_SOURCES) \
++	$(test_acquire_cred_SOURCES) $(test_cfx_SOURCES) \
++	$(test_context_SOURCES) test_cred.c test_kcred.c test_names.c \
++	$(test_ntlm_SOURCES) test_oid.c
++man3dir = $(mandir)/man3
++man5dir = $(mandir)/man5
++MANS = $(man_MANS)
++HEADERS = $(include_HEADERS) $(nobase_include_HEADERS) \
++	$(nodist_gssapi_HEADERS) $(noinst_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) -I$(srcdir)/../krb5 -I$(srcdir) \
++	-I$(srcdir)/gssapi -I$(srcdir)/mech -I$(srcdir)/ntlm \
++	-I$(srcdir)/krb5 -I$(srcdir)/spnego $(INCLUDE_libintl) \
++	$(INCLUDE_hcrypto) $(INCLUDE_krb4)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++AUTOMAKE_OPTIONS = subdir-objects
++lib_LTLIBRARIES = libgssapi.la
++krb5src = \
++	krb5/8003.c \
++	krb5/accept_sec_context.c \
++	krb5/acquire_cred.c \
++	krb5/add_cred.c \
++	krb5/address_to_krb5addr.c \
++	krb5/aeap.c \
++	krb5/arcfour.c \
++	krb5/canonicalize_name.c \
++	krb5/creds.c \
++	krb5/ccache_name.c \
++	krb5/cfx.c \
++	krb5/cfx.h \
++	krb5/compare_name.c \
++	krb5/compat.c \
++	krb5/context_time.c \
++	krb5/copy_ccache.c \
++	krb5/decapsulate.c \
++	krb5/delete_sec_context.c \
++	krb5/display_name.c \
++	krb5/display_status.c \
++	krb5/duplicate_name.c \
++	krb5/encapsulate.c \
++	krb5/export_name.c \
++	krb5/export_sec_context.c \
++	krb5/external.c \
++	krb5/get_mic.c \
++	krb5/gsskrb5_locl.h \
++	krb5/gsskrb5-private.h \
++	krb5/import_name.c \
++	krb5/import_sec_context.c \
++	krb5/indicate_mechs.c \
++	krb5/init.c \
++	krb5/init_sec_context.c \
++	krb5/inquire_context.c \
++	krb5/inquire_cred.c \
++	krb5/inquire_cred_by_mech.c \
++	krb5/inquire_cred_by_oid.c \
++	krb5/inquire_mechs_for_name.c \
++	krb5/inquire_names_for_mech.c \
++	krb5/inquire_sec_context_by_oid.c \
++	krb5/process_context_token.c \
++	krb5/prf.c \
++	krb5/release_buffer.c \
++	krb5/release_cred.c \
++	krb5/release_name.c \
++	krb5/sequence.c \
++	krb5/store_cred.c \
++	krb5/set_cred_option.c \
++	krb5/set_sec_context_option.c \
++	krb5/ticket_flags.c \
++	krb5/unwrap.c \
++	krb5/verify_mic.c \
++	krb5/wrap.c
++
++mechsrc = \
++	mech/context.h \
++	mech/context.c \
++	mech/cred.h \
++	mech/doxygen.c \
++	mech/gss_accept_sec_context.c \
++	mech/gss_acquire_cred.c \
++	mech/gss_add_cred.c \
++	mech/gss_add_oid_set_member.c \
++	mech/gss_aeap.c \
++	mech/gss_buffer_set.c \
++	mech/gss_canonicalize_name.c \
++	mech/gss_compare_name.c \
++	mech/gss_context_time.c \
++	mech/gss_create_empty_oid_set.c \
++	mech/gss_cred.c \
++	mech/gss_decapsulate_token.c \
++	mech/gss_delete_sec_context.c \
++	mech/gss_display_name.c \
++	mech/gss_display_status.c \
++	mech/gss_duplicate_name.c \
++	mech/gss_duplicate_oid.c \
++	mech/gss_encapsulate_token.c \
++	mech/gss_export_name.c \
++	mech/gss_export_sec_context.c \
++	mech/gss_get_mic.c \
++	mech/gss_import_name.c \
++	mech/gss_import_sec_context.c \
++	mech/gss_indicate_mechs.c \
++	mech/gss_init_sec_context.c \
++	mech/gss_inquire_context.c \
++	mech/gss_inquire_cred.c \
++	mech/gss_inquire_cred_by_mech.c \
++	mech/gss_inquire_cred_by_oid.c \
++	mech/gss_inquire_mechs_for_name.c \
++	mech/gss_inquire_names_for_mech.c \
++	mech/gss_krb5.c \
++	mech/gss_mech_switch.c \
++	mech/gss_mo.c \
++	mech/gss_names.c \
++	mech/gss_oid.c \
++	mech/gss_oid_equal.c \
++	mech/gss_oid_to_str.c \
++	mech/gss_process_context_token.c \
++	mech/gss_pseudo_random.c \
++	mech/gss_release_buffer.c \
++	mech/gss_release_cred.c \
++	mech/gss_release_name.c \
++	mech/gss_release_oid.c \
++	mech/gss_release_oid_set.c \
++	mech/gss_seal.c \
++	mech/gss_set_cred_option.c \
++	mech/gss_set_sec_context_option.c \
++	mech/gss_sign.c \
++	mech/gss_store_cred.c \
++	mech/gss_test_oid_set_member.c \
++	mech/gss_unseal.c \
++	mech/gss_unwrap.c \
++	mech/gss_utils.c \
++	mech/gss_verify.c \
++	mech/gss_verify_mic.c \
++	mech/gss_wrap.c \
++	mech/gss_wrap_size_limit.c \
++	mech/gss_inquire_sec_context_by_oid.c \
++	mech/mech_switch.h \
++	mech/mechqueue.h \
++	mech/mech_locl.h \
++	mech/name.h \
++	mech/utils.h
++
++spnegosrc = \
++	spnego/accept_sec_context.c \
++	spnego/compat.c \
++	spnego/context_stubs.c \
++	spnego/cred_stubs.c \
++	spnego/external.c \
++	spnego/init_sec_context.c \
++	spnego/spnego_locl.h \
++	spnego/spnego-private.h
++
++ntlmsrc = \
++	ntlm/accept_sec_context.c \
++	ntlm/acquire_cred.c \
++	ntlm/add_cred.c \
++	ntlm/canonicalize_name.c \
++	ntlm/compare_name.c \
++	ntlm/context_time.c \
++	ntlm/crypto.c \
++	ntlm/delete_sec_context.c \
++	ntlm/display_name.c \
++	ntlm/display_status.c \
++	ntlm/duplicate_name.c \
++	ntlm/export_name.c \
++	ntlm/export_sec_context.c \
++	ntlm/external.c \
++	ntlm/ntlm.h \
++	ntlm/ntlm-private.h \
++	ntlm/import_name.c \
++	ntlm/import_sec_context.c \
++	ntlm/indicate_mechs.c \
++	ntlm/init_sec_context.c \
++	ntlm/inquire_context.c \
++	ntlm/inquire_cred.c \
++	ntlm/inquire_cred_by_mech.c \
++	ntlm/inquire_mechs_for_name.c \
++	ntlm/inquire_names_for_mech.c \
++	ntlm/process_context_token.c \
++	ntlm/release_cred.c \
++	ntlm/release_name.c \
++	ntlm/kdc.c
++
++dist_libgssapi_la_SOURCES = \
++	$(krb5src) \
++	$(mechsrc) \
++	$(ntlmsrc) \
++	$(spnegosrc)
++
++nodist_libgssapi_la_SOURCES = \
++	gkrb5_err.c \
++	gkrb5_err.h \
++	$(BUILT_SOURCES)
++
++libgssapi_la_LDFLAGS = -version-info 2:0:0 $(am__append_1)
++libgssapi_la_LIBADD = \
++	$(top_builddir)/lib/ntlm/libheimntlm.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_com_err) \
++	$(LIB_hcrypto) \
++	$(LIBADD_roken)
++
++man_MANS = gssapi.3 gss_acquire_cred.3 mech/mech.5
++include_HEADERS = gssapi.h
++noinst_HEADERS = \
++	gssapi_mech.h \
++	ntlm/ntlm-private.h \
++	spnego/spnego-private.h \
++	krb5/gsskrb5-private.h
++
++nobase_include_HEADERS = \
++	gssapi/gssapi.h \
++	gssapi/gssapi_krb5.h \
++	gssapi/gssapi_ntlm.h \
++	gssapi/gssapi_oid.h \
++	gssapi/gssapi_spnego.h
++
++gssapidir = $(includedir)/gssapi
++nodist_gssapi_HEADERS = gkrb5_err.h
++gssapi_files = asn1_GSSAPIContextToken.x
++spnego_files = \
++	asn1_ContextFlags.x			\
++	asn1_MechType.x				\
++	asn1_MechTypeList.x			\
++	asn1_NegotiationToken.x			\
++	asn1_NegotiationTokenWin.x		\
++	asn1_NegHints.x				\
++	asn1_NegTokenInit.x			\
++	asn1_NegTokenInitWin.x			\
++	asn1_NegTokenResp.x
++
++BUILTHEADERS = \
++	$(srcdir)/krb5/gsskrb5-private.h \
++	$(srcdir)/spnego/spnego-private.h \
++	$(srcdir)/ntlm/ntlm-private.h
++
++BUILT_SOURCES = $(spnego_files:.x=.c) $(gssapi_files:.x=.c)
++CLEANFILES = $(BUILT_SOURCES) \
++	gkrb5_err.h gkrb5_err.c \
++	$(spnego_files) spnego_asn1*.h* spnego_asn1_files spnego_asn1-template.c \
++	$(gssapi_files) gssapi_asn1*.h* gssapi_asn1_files gssapi_asn1-template.c \
++	gss-commands.h gss-commands.c
++
++# test_sequence 
++test_cfx_SOURCES = krb5/test_cfx.c
++test_context_SOURCES = test_context.c test_common.c test_common.h
++test_ntlm_SOURCES = test_ntlm.c test_common.c test_common.h
++test_acquire_cred_SOURCES = test_acquire_cred.c test_common.c test_common.h
++test_ntlm_LDADD = \
++	$(top_builddir)/lib/ntlm/libheimntlm.la \
++	$(LDADD)
++
++LDADD = libgssapi.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_roken)
++
++
++# gss
++dist_gsstool_SOURCES = gsstool.c
++nodist_gsstool_SOURCES = gss-commands.c gss-commands.h
++gsstool_LDADD = libgssapi.la \
++	$(top_builddir)/lib/sl/libsl.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(LIB_readline) \
++	$(LIB_roken)
++
++EXTRA_DIST = \
++	$(man_MANS) \
++	krb5/gkrb5_err.et \
++	mech/gssapi.asn1 \
++	spnego/spnego.asn1 \
++	spnego/spnego.opt \
++	version-script.map \
++	gss-commands.in
++
++all: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/gssapi/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/gssapi/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++krb5/$(am__dirstamp):
++	@$(MKDIR_P) krb5
++	@: > krb5/$(am__dirstamp)
++krb5/$(DEPDIR)/$(am__dirstamp):
++	@$(MKDIR_P) krb5/$(DEPDIR)
++	@: > krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/8003.lo: krb5/$(am__dirstamp) krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/accept_sec_context.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/acquire_cred.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/add_cred.lo: krb5/$(am__dirstamp) krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/address_to_krb5addr.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/aeap.lo: krb5/$(am__dirstamp) krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/arcfour.lo: krb5/$(am__dirstamp) krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/canonicalize_name.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/creds.lo: krb5/$(am__dirstamp) krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/ccache_name.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/cfx.lo: krb5/$(am__dirstamp) krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/compare_name.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/compat.lo: krb5/$(am__dirstamp) krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/context_time.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/copy_ccache.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/decapsulate.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/delete_sec_context.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/display_name.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/display_status.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/duplicate_name.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/encapsulate.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/export_name.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/export_sec_context.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/external.lo: krb5/$(am__dirstamp) krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/get_mic.lo: krb5/$(am__dirstamp) krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/import_name.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/import_sec_context.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/indicate_mechs.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/init.lo: krb5/$(am__dirstamp) krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/init_sec_context.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/inquire_context.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/inquire_cred.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/inquire_cred_by_mech.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/inquire_cred_by_oid.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/inquire_mechs_for_name.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/inquire_names_for_mech.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/inquire_sec_context_by_oid.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/process_context_token.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/prf.lo: krb5/$(am__dirstamp) krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/release_buffer.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/release_cred.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/release_name.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/sequence.lo: krb5/$(am__dirstamp) krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/store_cred.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/set_cred_option.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/set_sec_context_option.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/ticket_flags.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/unwrap.lo: krb5/$(am__dirstamp) krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/verify_mic.lo: krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++krb5/wrap.lo: krb5/$(am__dirstamp) krb5/$(DEPDIR)/$(am__dirstamp)
++mech/$(am__dirstamp):
++	@$(MKDIR_P) mech
++	@: > mech/$(am__dirstamp)
++mech/$(DEPDIR)/$(am__dirstamp):
++	@$(MKDIR_P) mech/$(DEPDIR)
++	@: > mech/$(DEPDIR)/$(am__dirstamp)
++mech/context.lo: mech/$(am__dirstamp) mech/$(DEPDIR)/$(am__dirstamp)
++mech/doxygen.lo: mech/$(am__dirstamp) mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_accept_sec_context.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_acquire_cred.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_add_cred.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_add_oid_set_member.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_aeap.lo: mech/$(am__dirstamp) mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_buffer_set.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_canonicalize_name.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_compare_name.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_context_time.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_create_empty_oid_set.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_cred.lo: mech/$(am__dirstamp) mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_decapsulate_token.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_delete_sec_context.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_display_name.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_display_status.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_duplicate_name.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_duplicate_oid.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_encapsulate_token.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_export_name.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_export_sec_context.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_get_mic.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_import_name.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_import_sec_context.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_indicate_mechs.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_init_sec_context.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_inquire_context.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_inquire_cred.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_inquire_cred_by_mech.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_inquire_cred_by_oid.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_inquire_mechs_for_name.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_inquire_names_for_mech.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_krb5.lo: mech/$(am__dirstamp) mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_mech_switch.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_mo.lo: mech/$(am__dirstamp) mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_names.lo: mech/$(am__dirstamp) mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_oid.lo: mech/$(am__dirstamp) mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_oid_equal.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_oid_to_str.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_process_context_token.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_pseudo_random.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_release_buffer.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_release_cred.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_release_name.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_release_oid.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_release_oid_set.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_seal.lo: mech/$(am__dirstamp) mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_set_cred_option.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_set_sec_context_option.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_sign.lo: mech/$(am__dirstamp) mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_store_cred.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_test_oid_set_member.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_unseal.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_unwrap.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_utils.lo: mech/$(am__dirstamp) mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_verify.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_verify_mic.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_wrap.lo: mech/$(am__dirstamp) mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_wrap_size_limit.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++mech/gss_inquire_sec_context_by_oid.lo: mech/$(am__dirstamp) \
++	mech/$(DEPDIR)/$(am__dirstamp)
++ntlm/$(am__dirstamp):
++	@$(MKDIR_P) ntlm
++	@: > ntlm/$(am__dirstamp)
++ntlm/$(DEPDIR)/$(am__dirstamp):
++	@$(MKDIR_P) ntlm/$(DEPDIR)
++	@: > ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/accept_sec_context.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/acquire_cred.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/add_cred.lo: ntlm/$(am__dirstamp) ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/canonicalize_name.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/compare_name.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/context_time.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/crypto.lo: ntlm/$(am__dirstamp) ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/delete_sec_context.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/display_name.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/display_status.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/duplicate_name.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/export_name.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/export_sec_context.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/external.lo: ntlm/$(am__dirstamp) ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/import_name.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/import_sec_context.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/indicate_mechs.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/init_sec_context.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/inquire_context.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/inquire_cred.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/inquire_cred_by_mech.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/inquire_mechs_for_name.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/inquire_names_for_mech.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/process_context_token.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/release_cred.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/release_name.lo: ntlm/$(am__dirstamp) \
++	ntlm/$(DEPDIR)/$(am__dirstamp)
++ntlm/kdc.lo: ntlm/$(am__dirstamp) ntlm/$(DEPDIR)/$(am__dirstamp)
++spnego/$(am__dirstamp):
++	@$(MKDIR_P) spnego
++	@: > spnego/$(am__dirstamp)
++spnego/$(DEPDIR)/$(am__dirstamp):
++	@$(MKDIR_P) spnego/$(DEPDIR)
++	@: > spnego/$(DEPDIR)/$(am__dirstamp)
++spnego/accept_sec_context.lo: spnego/$(am__dirstamp) \
++	spnego/$(DEPDIR)/$(am__dirstamp)
++spnego/compat.lo: spnego/$(am__dirstamp) \
++	spnego/$(DEPDIR)/$(am__dirstamp)
++spnego/context_stubs.lo: spnego/$(am__dirstamp) \
++	spnego/$(DEPDIR)/$(am__dirstamp)
++spnego/cred_stubs.lo: spnego/$(am__dirstamp) \
++	spnego/$(DEPDIR)/$(am__dirstamp)
++spnego/external.lo: spnego/$(am__dirstamp) \
++	spnego/$(DEPDIR)/$(am__dirstamp)
++spnego/init_sec_context.lo: spnego/$(am__dirstamp) \
++	spnego/$(DEPDIR)/$(am__dirstamp)
++libgssapi.la: $(libgssapi_la_OBJECTS) $(libgssapi_la_DEPENDENCIES) 
++	$(libgssapi_la_LINK) -rpath $(libdir) $(libgssapi_la_OBJECTS) $(libgssapi_la_LIBADD) $(LIBS)
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-checkPROGRAMS:
++	@list='$(check_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++gsstool$(EXEEXT): $(gsstool_OBJECTS) $(gsstool_DEPENDENCIES) 
++	@rm -f gsstool$(EXEEXT)
++	$(LINK) $(gsstool_OBJECTS) $(gsstool_LDADD) $(LIBS)
++test_acquire_cred$(EXEEXT): $(test_acquire_cred_OBJECTS) $(test_acquire_cred_DEPENDENCIES) 
++	@rm -f test_acquire_cred$(EXEEXT)
++	$(LINK) $(test_acquire_cred_OBJECTS) $(test_acquire_cred_LDADD) $(LIBS)
++krb5/test_cfx.$(OBJEXT): krb5/$(am__dirstamp) \
++	krb5/$(DEPDIR)/$(am__dirstamp)
++test_cfx$(EXEEXT): $(test_cfx_OBJECTS) $(test_cfx_DEPENDENCIES) 
++	@rm -f test_cfx$(EXEEXT)
++	$(LINK) $(test_cfx_OBJECTS) $(test_cfx_LDADD) $(LIBS)
++test_context$(EXEEXT): $(test_context_OBJECTS) $(test_context_DEPENDENCIES) 
++	@rm -f test_context$(EXEEXT)
++	$(LINK) $(test_context_OBJECTS) $(test_context_LDADD) $(LIBS)
++test_cred$(EXEEXT): $(test_cred_OBJECTS) $(test_cred_DEPENDENCIES) 
++	@rm -f test_cred$(EXEEXT)
++	$(LINK) $(test_cred_OBJECTS) $(test_cred_LDADD) $(LIBS)
++test_kcred$(EXEEXT): $(test_kcred_OBJECTS) $(test_kcred_DEPENDENCIES) 
++	@rm -f test_kcred$(EXEEXT)
++	$(LINK) $(test_kcred_OBJECTS) $(test_kcred_LDADD) $(LIBS)
++test_names$(EXEEXT): $(test_names_OBJECTS) $(test_names_DEPENDENCIES) 
++	@rm -f test_names$(EXEEXT)
++	$(LINK) $(test_names_OBJECTS) $(test_names_LDADD) $(LIBS)
++test_ntlm$(EXEEXT): $(test_ntlm_OBJECTS) $(test_ntlm_DEPENDENCIES) 
++	@rm -f test_ntlm$(EXEEXT)
++	$(LINK) $(test_ntlm_OBJECTS) $(test_ntlm_LDADD) $(LIBS)
++test_oid$(EXEEXT): $(test_oid_OBJECTS) $(test_oid_DEPENDENCIES) 
++	@rm -f test_oid$(EXEEXT)
++	$(LINK) $(test_oid_OBJECTS) $(test_oid_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++	-rm -f krb5/8003.$(OBJEXT)
++	-rm -f krb5/8003.lo
++	-rm -f krb5/accept_sec_context.$(OBJEXT)
++	-rm -f krb5/accept_sec_context.lo
++	-rm -f krb5/acquire_cred.$(OBJEXT)
++	-rm -f krb5/acquire_cred.lo
++	-rm -f krb5/add_cred.$(OBJEXT)
++	-rm -f krb5/add_cred.lo
++	-rm -f krb5/address_to_krb5addr.$(OBJEXT)
++	-rm -f krb5/address_to_krb5addr.lo
++	-rm -f krb5/aeap.$(OBJEXT)
++	-rm -f krb5/aeap.lo
++	-rm -f krb5/arcfour.$(OBJEXT)
++	-rm -f krb5/arcfour.lo
++	-rm -f krb5/canonicalize_name.$(OBJEXT)
++	-rm -f krb5/canonicalize_name.lo
++	-rm -f krb5/ccache_name.$(OBJEXT)
++	-rm -f krb5/ccache_name.lo
++	-rm -f krb5/cfx.$(OBJEXT)
++	-rm -f krb5/cfx.lo
++	-rm -f krb5/compare_name.$(OBJEXT)
++	-rm -f krb5/compare_name.lo
++	-rm -f krb5/compat.$(OBJEXT)
++	-rm -f krb5/compat.lo
++	-rm -f krb5/context_time.$(OBJEXT)
++	-rm -f krb5/context_time.lo
++	-rm -f krb5/copy_ccache.$(OBJEXT)
++	-rm -f krb5/copy_ccache.lo
++	-rm -f krb5/creds.$(OBJEXT)
++	-rm -f krb5/creds.lo
++	-rm -f krb5/decapsulate.$(OBJEXT)
++	-rm -f krb5/decapsulate.lo
++	-rm -f krb5/delete_sec_context.$(OBJEXT)
++	-rm -f krb5/delete_sec_context.lo
++	-rm -f krb5/display_name.$(OBJEXT)
++	-rm -f krb5/display_name.lo
++	-rm -f krb5/display_status.$(OBJEXT)
++	-rm -f krb5/display_status.lo
++	-rm -f krb5/duplicate_name.$(OBJEXT)
++	-rm -f krb5/duplicate_name.lo
++	-rm -f krb5/encapsulate.$(OBJEXT)
++	-rm -f krb5/encapsulate.lo
++	-rm -f krb5/export_name.$(OBJEXT)
++	-rm -f krb5/export_name.lo
++	-rm -f krb5/export_sec_context.$(OBJEXT)
++	-rm -f krb5/export_sec_context.lo
++	-rm -f krb5/external.$(OBJEXT)
++	-rm -f krb5/external.lo
++	-rm -f krb5/get_mic.$(OBJEXT)
++	-rm -f krb5/get_mic.lo
++	-rm -f krb5/import_name.$(OBJEXT)
++	-rm -f krb5/import_name.lo
++	-rm -f krb5/import_sec_context.$(OBJEXT)
++	-rm -f krb5/import_sec_context.lo
++	-rm -f krb5/indicate_mechs.$(OBJEXT)
++	-rm -f krb5/indicate_mechs.lo
++	-rm -f krb5/init.$(OBJEXT)
++	-rm -f krb5/init.lo
++	-rm -f krb5/init_sec_context.$(OBJEXT)
++	-rm -f krb5/init_sec_context.lo
++	-rm -f krb5/inquire_context.$(OBJEXT)
++	-rm -f krb5/inquire_context.lo
++	-rm -f krb5/inquire_cred.$(OBJEXT)
++	-rm -f krb5/inquire_cred.lo
++	-rm -f krb5/inquire_cred_by_mech.$(OBJEXT)
++	-rm -f krb5/inquire_cred_by_mech.lo
++	-rm -f krb5/inquire_cred_by_oid.$(OBJEXT)
++	-rm -f krb5/inquire_cred_by_oid.lo
++	-rm -f krb5/inquire_mechs_for_name.$(OBJEXT)
++	-rm -f krb5/inquire_mechs_for_name.lo
++	-rm -f krb5/inquire_names_for_mech.$(OBJEXT)
++	-rm -f krb5/inquire_names_for_mech.lo
++	-rm -f krb5/inquire_sec_context_by_oid.$(OBJEXT)
++	-rm -f krb5/inquire_sec_context_by_oid.lo
++	-rm -f krb5/prf.$(OBJEXT)
++	-rm -f krb5/prf.lo
++	-rm -f krb5/process_context_token.$(OBJEXT)
++	-rm -f krb5/process_context_token.lo
++	-rm -f krb5/release_buffer.$(OBJEXT)
++	-rm -f krb5/release_buffer.lo
++	-rm -f krb5/release_cred.$(OBJEXT)
++	-rm -f krb5/release_cred.lo
++	-rm -f krb5/release_name.$(OBJEXT)
++	-rm -f krb5/release_name.lo
++	-rm -f krb5/sequence.$(OBJEXT)
++	-rm -f krb5/sequence.lo
++	-rm -f krb5/set_cred_option.$(OBJEXT)
++	-rm -f krb5/set_cred_option.lo
++	-rm -f krb5/set_sec_context_option.$(OBJEXT)
++	-rm -f krb5/set_sec_context_option.lo
++	-rm -f krb5/store_cred.$(OBJEXT)
++	-rm -f krb5/store_cred.lo
++	-rm -f krb5/test_cfx.$(OBJEXT)
++	-rm -f krb5/ticket_flags.$(OBJEXT)
++	-rm -f krb5/ticket_flags.lo
++	-rm -f krb5/unwrap.$(OBJEXT)
++	-rm -f krb5/unwrap.lo
++	-rm -f krb5/verify_mic.$(OBJEXT)
++	-rm -f krb5/verify_mic.lo
++	-rm -f krb5/wrap.$(OBJEXT)
++	-rm -f krb5/wrap.lo
++	-rm -f mech/context.$(OBJEXT)
++	-rm -f mech/context.lo
++	-rm -f mech/doxygen.$(OBJEXT)
++	-rm -f mech/doxygen.lo
++	-rm -f mech/gss_accept_sec_context.$(OBJEXT)
++	-rm -f mech/gss_accept_sec_context.lo
++	-rm -f mech/gss_acquire_cred.$(OBJEXT)
++	-rm -f mech/gss_acquire_cred.lo
++	-rm -f mech/gss_add_cred.$(OBJEXT)
++	-rm -f mech/gss_add_cred.lo
++	-rm -f mech/gss_add_oid_set_member.$(OBJEXT)
++	-rm -f mech/gss_add_oid_set_member.lo
++	-rm -f mech/gss_aeap.$(OBJEXT)
++	-rm -f mech/gss_aeap.lo
++	-rm -f mech/gss_buffer_set.$(OBJEXT)
++	-rm -f mech/gss_buffer_set.lo
++	-rm -f mech/gss_canonicalize_name.$(OBJEXT)
++	-rm -f mech/gss_canonicalize_name.lo
++	-rm -f mech/gss_compare_name.$(OBJEXT)
++	-rm -f mech/gss_compare_name.lo
++	-rm -f mech/gss_context_time.$(OBJEXT)
++	-rm -f mech/gss_context_time.lo
++	-rm -f mech/gss_create_empty_oid_set.$(OBJEXT)
++	-rm -f mech/gss_create_empty_oid_set.lo
++	-rm -f mech/gss_cred.$(OBJEXT)
++	-rm -f mech/gss_cred.lo
++	-rm -f mech/gss_decapsulate_token.$(OBJEXT)
++	-rm -f mech/gss_decapsulate_token.lo
++	-rm -f mech/gss_delete_sec_context.$(OBJEXT)
++	-rm -f mech/gss_delete_sec_context.lo
++	-rm -f mech/gss_display_name.$(OBJEXT)
++	-rm -f mech/gss_display_name.lo
++	-rm -f mech/gss_display_status.$(OBJEXT)
++	-rm -f mech/gss_display_status.lo
++	-rm -f mech/gss_duplicate_name.$(OBJEXT)
++	-rm -f mech/gss_duplicate_name.lo
++	-rm -f mech/gss_duplicate_oid.$(OBJEXT)
++	-rm -f mech/gss_duplicate_oid.lo
++	-rm -f mech/gss_encapsulate_token.$(OBJEXT)
++	-rm -f mech/gss_encapsulate_token.lo
++	-rm -f mech/gss_export_name.$(OBJEXT)
++	-rm -f mech/gss_export_name.lo
++	-rm -f mech/gss_export_sec_context.$(OBJEXT)
++	-rm -f mech/gss_export_sec_context.lo
++	-rm -f mech/gss_get_mic.$(OBJEXT)
++	-rm -f mech/gss_get_mic.lo
++	-rm -f mech/gss_import_name.$(OBJEXT)
++	-rm -f mech/gss_import_name.lo
++	-rm -f mech/gss_import_sec_context.$(OBJEXT)
++	-rm -f mech/gss_import_sec_context.lo
++	-rm -f mech/gss_indicate_mechs.$(OBJEXT)
++	-rm -f mech/gss_indicate_mechs.lo
++	-rm -f mech/gss_init_sec_context.$(OBJEXT)
++	-rm -f mech/gss_init_sec_context.lo
++	-rm -f mech/gss_inquire_context.$(OBJEXT)
++	-rm -f mech/gss_inquire_context.lo
++	-rm -f mech/gss_inquire_cred.$(OBJEXT)
++	-rm -f mech/gss_inquire_cred.lo
++	-rm -f mech/gss_inquire_cred_by_mech.$(OBJEXT)
++	-rm -f mech/gss_inquire_cred_by_mech.lo
++	-rm -f mech/gss_inquire_cred_by_oid.$(OBJEXT)
++	-rm -f mech/gss_inquire_cred_by_oid.lo
++	-rm -f mech/gss_inquire_mechs_for_name.$(OBJEXT)
++	-rm -f mech/gss_inquire_mechs_for_name.lo
++	-rm -f mech/gss_inquire_names_for_mech.$(OBJEXT)
++	-rm -f mech/gss_inquire_names_for_mech.lo
++	-rm -f mech/gss_inquire_sec_context_by_oid.$(OBJEXT)
++	-rm -f mech/gss_inquire_sec_context_by_oid.lo
++	-rm -f mech/gss_krb5.$(OBJEXT)
++	-rm -f mech/gss_krb5.lo
++	-rm -f mech/gss_mech_switch.$(OBJEXT)
++	-rm -f mech/gss_mech_switch.lo
++	-rm -f mech/gss_mo.$(OBJEXT)
++	-rm -f mech/gss_mo.lo
++	-rm -f mech/gss_names.$(OBJEXT)
++	-rm -f mech/gss_names.lo
++	-rm -f mech/gss_oid.$(OBJEXT)
++	-rm -f mech/gss_oid.lo
++	-rm -f mech/gss_oid_equal.$(OBJEXT)
++	-rm -f mech/gss_oid_equal.lo
++	-rm -f mech/gss_oid_to_str.$(OBJEXT)
++	-rm -f mech/gss_oid_to_str.lo
++	-rm -f mech/gss_process_context_token.$(OBJEXT)
++	-rm -f mech/gss_process_context_token.lo
++	-rm -f mech/gss_pseudo_random.$(OBJEXT)
++	-rm -f mech/gss_pseudo_random.lo
++	-rm -f mech/gss_release_buffer.$(OBJEXT)
++	-rm -f mech/gss_release_buffer.lo
++	-rm -f mech/gss_release_cred.$(OBJEXT)
++	-rm -f mech/gss_release_cred.lo
++	-rm -f mech/gss_release_name.$(OBJEXT)
++	-rm -f mech/gss_release_name.lo
++	-rm -f mech/gss_release_oid.$(OBJEXT)
++	-rm -f mech/gss_release_oid.lo
++	-rm -f mech/gss_release_oid_set.$(OBJEXT)
++	-rm -f mech/gss_release_oid_set.lo
++	-rm -f mech/gss_seal.$(OBJEXT)
++	-rm -f mech/gss_seal.lo
++	-rm -f mech/gss_set_cred_option.$(OBJEXT)
++	-rm -f mech/gss_set_cred_option.lo
++	-rm -f mech/gss_set_sec_context_option.$(OBJEXT)
++	-rm -f mech/gss_set_sec_context_option.lo
++	-rm -f mech/gss_sign.$(OBJEXT)
++	-rm -f mech/gss_sign.lo
++	-rm -f mech/gss_store_cred.$(OBJEXT)
++	-rm -f mech/gss_store_cred.lo
++	-rm -f mech/gss_test_oid_set_member.$(OBJEXT)
++	-rm -f mech/gss_test_oid_set_member.lo
++	-rm -f mech/gss_unseal.$(OBJEXT)
++	-rm -f mech/gss_unseal.lo
++	-rm -f mech/gss_unwrap.$(OBJEXT)
++	-rm -f mech/gss_unwrap.lo
++	-rm -f mech/gss_utils.$(OBJEXT)
++	-rm -f mech/gss_utils.lo
++	-rm -f mech/gss_verify.$(OBJEXT)
++	-rm -f mech/gss_verify.lo
++	-rm -f mech/gss_verify_mic.$(OBJEXT)
++	-rm -f mech/gss_verify_mic.lo
++	-rm -f mech/gss_wrap.$(OBJEXT)
++	-rm -f mech/gss_wrap.lo
++	-rm -f mech/gss_wrap_size_limit.$(OBJEXT)
++	-rm -f mech/gss_wrap_size_limit.lo
++	-rm -f ntlm/accept_sec_context.$(OBJEXT)
++	-rm -f ntlm/accept_sec_context.lo
++	-rm -f ntlm/acquire_cred.$(OBJEXT)
++	-rm -f ntlm/acquire_cred.lo
++	-rm -f ntlm/add_cred.$(OBJEXT)
++	-rm -f ntlm/add_cred.lo
++	-rm -f ntlm/canonicalize_name.$(OBJEXT)
++	-rm -f ntlm/canonicalize_name.lo
++	-rm -f ntlm/compare_name.$(OBJEXT)
++	-rm -f ntlm/compare_name.lo
++	-rm -f ntlm/context_time.$(OBJEXT)
++	-rm -f ntlm/context_time.lo
++	-rm -f ntlm/crypto.$(OBJEXT)
++	-rm -f ntlm/crypto.lo
++	-rm -f ntlm/delete_sec_context.$(OBJEXT)
++	-rm -f ntlm/delete_sec_context.lo
++	-rm -f ntlm/display_name.$(OBJEXT)
++	-rm -f ntlm/display_name.lo
++	-rm -f ntlm/display_status.$(OBJEXT)
++	-rm -f ntlm/display_status.lo
++	-rm -f ntlm/duplicate_name.$(OBJEXT)
++	-rm -f ntlm/duplicate_name.lo
++	-rm -f ntlm/export_name.$(OBJEXT)
++	-rm -f ntlm/export_name.lo
++	-rm -f ntlm/export_sec_context.$(OBJEXT)
++	-rm -f ntlm/export_sec_context.lo
++	-rm -f ntlm/external.$(OBJEXT)
++	-rm -f ntlm/external.lo
++	-rm -f ntlm/import_name.$(OBJEXT)
++	-rm -f ntlm/import_name.lo
++	-rm -f ntlm/import_sec_context.$(OBJEXT)
++	-rm -f ntlm/import_sec_context.lo
++	-rm -f ntlm/indicate_mechs.$(OBJEXT)
++	-rm -f ntlm/indicate_mechs.lo
++	-rm -f ntlm/init_sec_context.$(OBJEXT)
++	-rm -f ntlm/init_sec_context.lo
++	-rm -f ntlm/inquire_context.$(OBJEXT)
++	-rm -f ntlm/inquire_context.lo
++	-rm -f ntlm/inquire_cred.$(OBJEXT)
++	-rm -f ntlm/inquire_cred.lo
++	-rm -f ntlm/inquire_cred_by_mech.$(OBJEXT)
++	-rm -f ntlm/inquire_cred_by_mech.lo
++	-rm -f ntlm/inquire_mechs_for_name.$(OBJEXT)
++	-rm -f ntlm/inquire_mechs_for_name.lo
++	-rm -f ntlm/inquire_names_for_mech.$(OBJEXT)
++	-rm -f ntlm/inquire_names_for_mech.lo
++	-rm -f ntlm/kdc.$(OBJEXT)
++	-rm -f ntlm/kdc.lo
++	-rm -f ntlm/process_context_token.$(OBJEXT)
++	-rm -f ntlm/process_context_token.lo
++	-rm -f ntlm/release_cred.$(OBJEXT)
++	-rm -f ntlm/release_cred.lo
++	-rm -f ntlm/release_name.$(OBJEXT)
++	-rm -f ntlm/release_name.lo
++	-rm -f spnego/accept_sec_context.$(OBJEXT)
++	-rm -f spnego/accept_sec_context.lo
++	-rm -f spnego/compat.$(OBJEXT)
++	-rm -f spnego/compat.lo
++	-rm -f spnego/context_stubs.$(OBJEXT)
++	-rm -f spnego/context_stubs.lo
++	-rm -f spnego/cred_stubs.$(OBJEXT)
++	-rm -f spnego/cred_stubs.lo
++	-rm -f spnego/external.$(OBJEXT)
++	-rm -f spnego/external.lo
++	-rm -f spnego/init_sec_context.$(OBJEXT)
++	-rm -f spnego/init_sec_context.lo
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_ContextFlags.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_GSSAPIContextToken.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_MechType.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_MechTypeList.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_NegHints.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_NegTokenInit.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_NegTokenInitWin.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_NegTokenResp.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_NegotiationToken.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_NegotiationTokenWin.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gkrb5_err.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gss-commands.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/gsstool.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_acquire_cred.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_common.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_context.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_cred.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_kcred.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_names.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_ntlm.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_oid.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/8003.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/accept_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/acquire_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/add_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/address_to_krb5addr.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/aeap.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/arcfour.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/canonicalize_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/ccache_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/cfx.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/compare_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/compat.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/context_time.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/copy_ccache.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/creds.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/decapsulate.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/delete_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/display_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/display_status.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/duplicate_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/encapsulate.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/export_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/export_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/external.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/get_mic.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/import_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/import_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/indicate_mechs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/init.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/init_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/inquire_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/inquire_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/inquire_cred_by_mech.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/inquire_cred_by_oid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/inquire_mechs_for_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/inquire_names_for_mech.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/inquire_sec_context_by_oid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/prf.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/process_context_token.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/release_buffer.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/release_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/release_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/sequence.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/set_cred_option.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/set_sec_context_option.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/store_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/test_cfx.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/ticket_flags.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/unwrap.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/verify_mic.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@krb5/$(DEPDIR)/wrap.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/doxygen.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_accept_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_acquire_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_add_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_add_oid_set_member.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_aeap.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_buffer_set.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_canonicalize_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_compare_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_context_time.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_create_empty_oid_set.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_decapsulate_token.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_delete_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_display_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_display_status.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_duplicate_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_duplicate_oid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_encapsulate_token.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_export_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_export_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_get_mic.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_import_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_import_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_indicate_mechs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_init_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_inquire_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_inquire_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_inquire_cred_by_mech.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_inquire_cred_by_oid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_inquire_mechs_for_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_inquire_names_for_mech.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_inquire_sec_context_by_oid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_krb5.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_mech_switch.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_mo.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_names.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_oid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_oid_equal.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_oid_to_str.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_process_context_token.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_pseudo_random.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_release_buffer.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_release_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_release_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_release_oid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_release_oid_set.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_seal.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_set_cred_option.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_set_sec_context_option.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_sign.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_store_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_test_oid_set_member.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_unseal.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_unwrap.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_utils.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_verify.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_verify_mic.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_wrap.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@mech/$(DEPDIR)/gss_wrap_size_limit.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/accept_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/acquire_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/add_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/canonicalize_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/compare_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/context_time.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/crypto.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/delete_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/display_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/display_status.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/duplicate_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/export_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/export_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/external.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/import_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/import_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/indicate_mechs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/init_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/inquire_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/inquire_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/inquire_cred_by_mech.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/inquire_mechs_for_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/inquire_names_for_mech.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/kdc.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/process_context_token.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/release_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@ntlm/$(DEPDIR)/release_name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@spnego/$(DEPDIR)/accept_sec_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@spnego/$(DEPDIR)/compat.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@spnego/$(DEPDIR)/context_stubs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@spnego/$(DEPDIR)/cred_stubs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@spnego/$(DEPDIR)/external.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@spnego/$(DEPDIR)/init_sec_context.Plo@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`;\
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\
++@am__fastdepCC_TRUE@	$(am__mv) $$depbase.Tpo $$depbase.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c -o $@ $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.obj$$||'`;\
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ `$(CYGPATH_W) '$<'` &&\
++@am__fastdepCC_TRUE@	$(am__mv) $$depbase.Tpo $$depbase.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c -o $@ `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.lo$$||'`;\
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\
++@am__fastdepCC_TRUE@	$(am__mv) $$depbase.Tpo $$depbase.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++	-rm -rf krb5/.libs krb5/_libs
++	-rm -rf mech/.libs mech/_libs
++	-rm -rf ntlm/.libs ntlm/_libs
++	-rm -rf spnego/.libs spnego/_libs
++install-man3: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man3dir)" || $(MKDIR_P) "$(DESTDIR)$(man3dir)"
++	@list=''; test -n "$(man3dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.3[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^3][0-9a-z]*$$,3,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man3dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man3dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man3dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man3dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man3:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man3dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.3[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^3][0-9a-z]*$$,3,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man3dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man3dir)" && rm -f $$files; }
++install-man5: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man5dir)" || $(MKDIR_P) "$(DESTDIR)$(man5dir)"
++	@list=''; test -n "$(man5dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.5[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^5][0-9a-z]*$$,5,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man5dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man5dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man5dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man5dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man5:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man5dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.5[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^5][0-9a-z]*$$,5,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man5dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man5dir)" && rm -f $$files; }
++install-includeHEADERS: $(include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++install-nobase_includeHEADERS: $(nobase_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(nobase_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	$(am__nobase_list) | while read dir files; do \
++	  xfiles=; for file in $$files; do \
++	    if test -f "$$file"; then xfiles="$$xfiles $$file"; \
++	    else xfiles="$$xfiles $(srcdir)/$$file"; fi; done; \
++	  test -z "$$xfiles" || { \
++	    test "x$$dir" = x. || { \
++	      echo "$(MKDIR_P) '$(DESTDIR)$(includedir)/$$dir'"; \
++	      $(MKDIR_P) "$(DESTDIR)$(includedir)/$$dir"; }; \
++	    echo " $(INSTALL_HEADER) $$xfiles '$(DESTDIR)$(includedir)/$$dir'"; \
++	    $(INSTALL_HEADER) $$xfiles "$(DESTDIR)$(includedir)/$$dir" || exit $$?; }; \
++	done
++
++uninstall-nobase_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(nobase_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	$(am__nobase_strip_setup); files=`$(am__nobase_strip)`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++install-nodist_gssapiHEADERS: $(nodist_gssapi_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(gssapidir)" || $(MKDIR_P) "$(DESTDIR)$(gssapidir)"
++	@list='$(nodist_gssapi_HEADERS)'; test -n "$(gssapidir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(gssapidir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(gssapidir)" || exit $$?; \
++	done
++
++uninstall-nodist_gssapiHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(nodist_gssapi_HEADERS)'; test -n "$(gssapidir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(gssapidir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(gssapidir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(MANS) $(HEADERS) \
++		all-local
++install-binPROGRAMS: install-libLTLIBRARIES
++
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man3dir)" "$(DESTDIR)$(man5dir)" "$(DESTDIR)$(includedir)" "$(DESTDIR)$(includedir)" "$(DESTDIR)$(gssapidir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++	-rm -f krb5/$(DEPDIR)/$(am__dirstamp)
++	-rm -f krb5/$(am__dirstamp)
++	-rm -f mech/$(DEPDIR)/$(am__dirstamp)
++	-rm -f mech/$(am__dirstamp)
++	-rm -f ntlm/$(DEPDIR)/$(am__dirstamp)
++	-rm -f ntlm/$(am__dirstamp)
++	-rm -f spnego/$(DEPDIR)/$(am__dirstamp)
++	-rm -f spnego/$(am__dirstamp)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++	-test -z "$(BUILT_SOURCES)" || rm -f $(BUILT_SOURCES)
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-checkPROGRAMS clean-generic \
++	clean-libLTLIBRARIES clean-libtool clean-noinstPROGRAMS \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR) krb5/$(DEPDIR) mech/$(DEPDIR) ntlm/$(DEPDIR) spnego/$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-includeHEADERS install-man \
++	install-nobase_includeHEADERS install-nodist_gssapiHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man3 install-man5
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR) krb5/$(DEPDIR) mech/$(DEPDIR) ntlm/$(DEPDIR) spnego/$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-includeHEADERS \
++	uninstall-libLTLIBRARIES uninstall-man \
++	uninstall-nobase_includeHEADERS uninstall-nodist_gssapiHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man3 uninstall-man5
++
++.MAKE: all check check-am install install-am install-data-am \
++	install-exec-am install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-TESTS check-am \
++	check-local clean clean-binPROGRAMS clean-checkPROGRAMS \
++	clean-generic clean-libLTLIBRARIES clean-libtool \
++	clean-noinstPROGRAMS ctags dist-hook distclean \
++	distclean-compile distclean-generic distclean-libtool \
++	distclean-tags distdir dvi dvi-am html html-am info info-am \
++	install install-am install-binPROGRAMS install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-includeHEADERS install-info \
++	install-info-am install-libLTLIBRARIES install-man \
++	install-man3 install-man5 install-nobase_includeHEADERS \
++	install-nodist_gssapiHEADERS install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-binPROGRAMS \
++	uninstall-hook uninstall-includeHEADERS \
++	uninstall-libLTLIBRARIES uninstall-man uninstall-man3 \
++	uninstall-man5 uninstall-nobase_includeHEADERS \
++	uninstall-nodist_gssapiHEADERS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(srcdir)/ntlm/ntlm-private.h:
++	cd $(srcdir) && perl ../../cf/make-proto.pl -q -P comment -p ntlm/ntlm-private.h $(ntlmsrc) || rm -f ntlm/ntlm-private.h
++
++$(libgssapi_la_OBJECTS): $(BUILTHEADERS)
++$(test_context_OBJECTS): $(BUILTHEADERS)
++
++$(libgssapi_la_OBJECTS): $(srcdir)/version-script.map
++
++$(spnego_files) spnego_asn1.hx spnego_asn1-priv.hx: spnego_asn1_files
++$(gssapi_files) gssapi_asn1.hx gssapi_asn1-priv.hx: gssapi_asn1_files
++
++spnego_asn1_files: $(ASN1_COMPILE_DEP) $(srcdir)/spnego/spnego.asn1 $(srcdir)/spnego/spnego.opt
++	$(ASN1_COMPILE) --option-file=$(srcdir)/spnego/spnego.opt $(srcdir)/spnego/spnego.asn1 spnego_asn1
++
++gssapi_asn1_files: $(ASN1_COMPILE_DEP) $(srcdir)/mech/gssapi.asn1
++	$(ASN1_COMPILE) $(srcdir)/mech/gssapi.asn1 gssapi_asn1
++
++$(srcdir)/krb5/gsskrb5-private.h:
++	cd $(srcdir) && perl ../../cf/make-proto.pl -q -P comment -p krb5/gsskrb5-private.h $(krb5src) || rm -f krb5/gsskrb5-private.h
++
++$(srcdir)/spnego/spnego-private.h:
++	cd $(srcdir) && perl ../../cf/make-proto.pl -q -P comment -p spnego/spnego-private.h $(spnegosrc) || rm -f spnego/spnego-private.h
++
++gss-commands.c gss-commands.h: gss-commands.in
++	$(SLC) $(srcdir)/gss-commands.in
++
++$(gsstool_OBJECTS): gss-commands.h
++
++$(libgssapi_la_OBJECTS): gkrb5_err.h gssapi_asn1.h gssapi_asn1-priv.h
++$(libgssapi_la_OBJECTS): spnego_asn1.h spnego_asn1-priv.h
++$(libgssapi_la_OBJECTS): $(srcdir)/gssapi/gssapi_oid.h
++
++gkrb5_err.h gkrb5_err.c: $(srcdir)/krb5/gkrb5_err.et
++	$(COMPILE_ET) $(srcdir)/krb5/gkrb5_err.et
++
++$(srcdir)/gssapi/gssapi_oid.h $(srcdir)/mech/gss_oid.c:
++	perl $(srcdir)/gen-oid.pl -b base -h $(srcdir)/oid.txt > $(srcdir)/gssapi/gssapi_oid.h
++	perl $(srcdir)/gen-oid.pl -b base $(srcdir)/oid.txt > $(srcdir)/mech/gss_oid.c
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/hcrypto/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/hcrypto/Makefile.in	2010-12-29 04:07:10.336421233 +0100
+@@ -0,0 +1,2850 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(hcryptoinclude_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++noinst_PROGRAMS = test_rand$(EXEEXT)
++check_PROGRAMS = $(am__EXEEXT_1) test_rsa$(EXEEXT) test_dh$(EXEEXT) \
++	example_evp_cipher$(EXEEXT)
++TESTS = $(am__EXEEXT_1) $(SCRIPT_TESTS)
++@versionscript_TRUE@am__append_1 = $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-script.map
++subdir = lib/hcrypto
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" \
++	"$(DESTDIR)$(hcryptoincludedir)"
++LTLIBRARIES = $(lib_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++libhcrypto_la_DEPENDENCIES = $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++am__objects_1 = libhcrypto_la-bncore.lo libhcrypto_la-bn_mp_init.lo \
++	libhcrypto_la-bn_mp_clear.lo libhcrypto_la-bn_mp_exch.lo \
++	libhcrypto_la-bn_mp_grow.lo libhcrypto_la-bn_mp_shrink.lo \
++	libhcrypto_la-bn_mp_clamp.lo libhcrypto_la-bn_mp_zero.lo \
++	libhcrypto_la-bn_mp_zero_multi.lo libhcrypto_la-bn_mp_set.lo \
++	libhcrypto_la-bn_mp_set_int.lo \
++	libhcrypto_la-bn_mp_init_size.lo libhcrypto_la-bn_mp_copy.lo \
++	libhcrypto_la-bn_mp_init_copy.lo libhcrypto_la-bn_mp_abs.lo \
++	libhcrypto_la-bn_mp_neg.lo libhcrypto_la-bn_mp_cmp_mag.lo \
++	libhcrypto_la-bn_mp_cmp.lo libhcrypto_la-bn_mp_cmp_d.lo \
++	libhcrypto_la-bn_mp_rshd.lo libhcrypto_la-bn_mp_lshd.lo \
++	libhcrypto_la-bn_mp_mod_2d.lo libhcrypto_la-bn_mp_div_2d.lo \
++	libhcrypto_la-bn_mp_mul_2d.lo libhcrypto_la-bn_mp_div_2.lo \
++	libhcrypto_la-bn_mp_mul_2.lo libhcrypto_la-bn_s_mp_add.lo \
++	libhcrypto_la-bn_s_mp_sub.lo \
++	libhcrypto_la-bn_fast_s_mp_mul_digs.lo \
++	libhcrypto_la-bn_s_mp_mul_digs.lo \
++	libhcrypto_la-bn_fast_s_mp_mul_high_digs.lo \
++	libhcrypto_la-bn_s_mp_mul_high_digs.lo \
++	libhcrypto_la-bn_fast_s_mp_sqr.lo libhcrypto_la-bn_s_mp_sqr.lo \
++	libhcrypto_la-bn_mp_add.lo libhcrypto_la-bn_mp_sub.lo \
++	libhcrypto_la-bn_mp_karatsuba_mul.lo \
++	libhcrypto_la-bn_mp_mul.lo \
++	libhcrypto_la-bn_mp_karatsuba_sqr.lo \
++	libhcrypto_la-bn_mp_sqr.lo libhcrypto_la-bn_mp_div.lo \
++	libhcrypto_la-bn_mp_mod.lo libhcrypto_la-bn_mp_add_d.lo \
++	libhcrypto_la-bn_mp_sub_d.lo libhcrypto_la-bn_mp_mul_d.lo \
++	libhcrypto_la-bn_mp_div_d.lo libhcrypto_la-bn_mp_mod_d.lo \
++	libhcrypto_la-bn_mp_expt_d.lo libhcrypto_la-bn_mp_addmod.lo \
++	libhcrypto_la-bn_mp_submod.lo libhcrypto_la-bn_mp_mulmod.lo \
++	libhcrypto_la-bn_mp_sqrmod.lo libhcrypto_la-bn_mp_gcd.lo \
++	libhcrypto_la-bn_mp_lcm.lo libhcrypto_la-bn_fast_mp_invmod.lo \
++	libhcrypto_la-bn_mp_invmod.lo libhcrypto_la-bn_mp_reduce.lo \
++	libhcrypto_la-bn_mp_montgomery_setup.lo \
++	libhcrypto_la-bn_fast_mp_montgomery_reduce.lo \
++	libhcrypto_la-bn_mp_montgomery_reduce.lo \
++	libhcrypto_la-bn_mp_exptmod_fast.lo \
++	libhcrypto_la-bn_mp_exptmod.lo libhcrypto_la-bn_mp_2expt.lo \
++	libhcrypto_la-bn_mp_n_root.lo libhcrypto_la-bn_mp_jacobi.lo \
++	libhcrypto_la-bn_reverse.lo libhcrypto_la-bn_mp_count_bits.lo \
++	libhcrypto_la-bn_mp_read_unsigned_bin.lo \
++	libhcrypto_la-bn_mp_read_signed_bin.lo \
++	libhcrypto_la-bn_mp_to_unsigned_bin.lo \
++	libhcrypto_la-bn_mp_to_signed_bin.lo \
++	libhcrypto_la-bn_mp_unsigned_bin_size.lo \
++	libhcrypto_la-bn_mp_signed_bin_size.lo \
++	libhcrypto_la-bn_mp_xor.lo libhcrypto_la-bn_mp_and.lo \
++	libhcrypto_la-bn_mp_or.lo libhcrypto_la-bn_mp_rand.lo \
++	libhcrypto_la-bn_mp_montgomery_calc_normalization.lo \
++	libhcrypto_la-bn_mp_prime_is_divisible.lo \
++	libhcrypto_la-bn_prime_tab.lo \
++	libhcrypto_la-bn_mp_prime_fermat.lo \
++	libhcrypto_la-bn_mp_prime_miller_rabin.lo \
++	libhcrypto_la-bn_mp_prime_is_prime.lo \
++	libhcrypto_la-bn_mp_prime_next_prime.lo \
++	libhcrypto_la-bn_mp_find_prime.lo \
++	libhcrypto_la-bn_mp_isprime.lo \
++	libhcrypto_la-bn_mp_dr_reduce.lo \
++	libhcrypto_la-bn_mp_dr_is_modulus.lo \
++	libhcrypto_la-bn_mp_dr_setup.lo \
++	libhcrypto_la-bn_mp_reduce_setup.lo \
++	libhcrypto_la-bn_mp_toom_mul.lo \
++	libhcrypto_la-bn_mp_toom_sqr.lo libhcrypto_la-bn_mp_div_3.lo \
++	libhcrypto_la-bn_s_mp_exptmod.lo \
++	libhcrypto_la-bn_mp_reduce_2k.lo \
++	libhcrypto_la-bn_mp_reduce_is_2k.lo \
++	libhcrypto_la-bn_mp_reduce_2k_setup.lo \
++	libhcrypto_la-bn_mp_reduce_2k_l.lo \
++	libhcrypto_la-bn_mp_reduce_is_2k_l.lo \
++	libhcrypto_la-bn_mp_reduce_2k_setup_l.lo \
++	libhcrypto_la-bn_mp_radix_smap.lo \
++	libhcrypto_la-bn_mp_read_radix.lo \
++	libhcrypto_la-bn_mp_toradix.lo \
++	libhcrypto_la-bn_mp_radix_size.lo libhcrypto_la-bn_mp_fread.lo \
++	libhcrypto_la-bn_mp_fwrite.lo libhcrypto_la-bn_mp_cnt_lsb.lo \
++	libhcrypto_la-bn_error.lo libhcrypto_la-bn_mp_init_multi.lo \
++	libhcrypto_la-bn_mp_clear_multi.lo \
++	libhcrypto_la-bn_mp_exteuclid.lo \
++	libhcrypto_la-bn_mp_toradix_n.lo \
++	libhcrypto_la-bn_mp_prime_random_ex.lo \
++	libhcrypto_la-bn_mp_get_int.lo libhcrypto_la-bn_mp_sqrt.lo \
++	libhcrypto_la-bn_mp_is_square.lo \
++	libhcrypto_la-bn_mp_init_set.lo \
++	libhcrypto_la-bn_mp_init_set_int.lo \
++	libhcrypto_la-bn_mp_invmod_slow.lo \
++	libhcrypto_la-bn_mp_prime_rabin_miller_trials.lo \
++	libhcrypto_la-bn_mp_to_signed_bin_n.lo \
++	libhcrypto_la-bn_mp_to_unsigned_bin_n.lo
++am_libhcrypto_la_OBJECTS = $(am__objects_1) libhcrypto_la-aes.lo \
++	libhcrypto_la-bn.lo libhcrypto_la-common.lo \
++	libhcrypto_la-camellia.lo libhcrypto_la-camellia-ntt.lo \
++	libhcrypto_la-des.lo libhcrypto_la-dh.lo \
++	libhcrypto_la-dh-ltm.lo libhcrypto_la-dsa.lo \
++	libhcrypto_la-doxygen.lo libhcrypto_la-evp.lo \
++	libhcrypto_la-evp-hcrypto.lo libhcrypto_la-evp-cc.lo \
++	libhcrypto_la-engine.lo libhcrypto_la-hmac.lo \
++	libhcrypto_la-md2.lo libhcrypto_la-md4.lo libhcrypto_la-md5.lo \
++	libhcrypto_la-pkcs5.lo libhcrypto_la-pkcs12.lo \
++	libhcrypto_la-rand-egd.lo libhcrypto_la-rand-fortuna.lo \
++	libhcrypto_la-rand-timer.lo libhcrypto_la-rand-unix.lo \
++	libhcrypto_la-rand.lo libhcrypto_la-rc2.lo \
++	libhcrypto_la-rc4.lo libhcrypto_la-rijndael-alg-fst.lo \
++	libhcrypto_la-rnd_keys.lo libhcrypto_la-rsa.lo \
++	libhcrypto_la-rsa-gmp.lo libhcrypto_la-rsa-ltm.lo \
++	libhcrypto_la-sha.lo libhcrypto_la-sha256.lo \
++	libhcrypto_la-sha512.lo libhcrypto_la-validate.lo \
++	libhcrypto_la-ui.lo
++libhcrypto_la_OBJECTS = $(am_libhcrypto_la_OBJECTS)
++libhcrypto_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libhcrypto_la_LDFLAGS) $(LDFLAGS) -o $@
++libhctest_la_LIBADD =
++am_libhctest_la_OBJECTS = des.lo ui.lo
++libhctest_la_OBJECTS = $(am_libhctest_la_OBJECTS)
++am__EXEEXT_1 = destest$(EXEEXT) mdtest$(EXEEXT) rc2test$(EXEEXT) \
++	rctest$(EXEEXT) test_bn$(EXEEXT) test_cipher$(EXEEXT) \
++	test_engine_dso$(EXEEXT) test_hmac$(EXEEXT) \
++	test_pkcs12$(EXEEXT) test_pkcs5$(EXEEXT)
++PROGRAMS = $(noinst_PROGRAMS)
++destest_SOURCES = destest.c
++destest_OBJECTS = destest.$(OBJEXT)
++destest_DEPENDENCIES = libhctest.la $(am__DEPENDENCIES_1)
++example_evp_cipher_SOURCES = example_evp_cipher.c
++example_evp_cipher_OBJECTS = example_evp_cipher.$(OBJEXT)
++example_evp_cipher_LDADD = $(LDADD)
++example_evp_cipher_DEPENDENCIES = $(lib_LTLIBRARIES) \
++	$(am__DEPENDENCIES_1)
++mdtest_SOURCES = mdtest.c
++mdtest_OBJECTS = mdtest.$(OBJEXT)
++mdtest_LDADD = $(LDADD)
++mdtest_DEPENDENCIES = $(lib_LTLIBRARIES) $(am__DEPENDENCIES_1)
++rc2test_SOURCES = rc2test.c
++rc2test_OBJECTS = rc2test.$(OBJEXT)
++rc2test_LDADD = $(LDADD)
++rc2test_DEPENDENCIES = $(lib_LTLIBRARIES) $(am__DEPENDENCIES_1)
++rctest_SOURCES = rctest.c
++rctest_OBJECTS = rctest.$(OBJEXT)
++rctest_LDADD = $(LDADD)
++rctest_DEPENDENCIES = $(lib_LTLIBRARIES) $(am__DEPENDENCIES_1)
++test_bn_SOURCES = test_bn.c
++test_bn_OBJECTS = test_bn.$(OBJEXT)
++test_bn_LDADD = $(LDADD)
++test_bn_DEPENDENCIES = $(lib_LTLIBRARIES) $(am__DEPENDENCIES_1)
++test_cipher_SOURCES = test_cipher.c
++test_cipher_OBJECTS = test_cipher.$(OBJEXT)
++test_cipher_LDADD = $(LDADD)
++test_cipher_DEPENDENCIES = $(lib_LTLIBRARIES) $(am__DEPENDENCIES_1)
++test_dh_SOURCES = test_dh.c
++test_dh_OBJECTS = test_dh.$(OBJEXT)
++test_dh_LDADD = $(LDADD)
++test_dh_DEPENDENCIES = $(lib_LTLIBRARIES) $(am__DEPENDENCIES_1)
++test_engine_dso_SOURCES = test_engine_dso.c
++test_engine_dso_OBJECTS = test_engine_dso.$(OBJEXT)
++test_engine_dso_LDADD = $(LDADD)
++test_engine_dso_DEPENDENCIES = $(lib_LTLIBRARIES) \
++	$(am__DEPENDENCIES_1)
++test_hmac_SOURCES = test_hmac.c
++test_hmac_OBJECTS = test_hmac.$(OBJEXT)
++test_hmac_LDADD = $(LDADD)
++test_hmac_DEPENDENCIES = $(lib_LTLIBRARIES) $(am__DEPENDENCIES_1)
++test_pkcs12_SOURCES = test_pkcs12.c
++test_pkcs12_OBJECTS = test_pkcs12.$(OBJEXT)
++test_pkcs12_LDADD = $(LDADD)
++test_pkcs12_DEPENDENCIES = $(lib_LTLIBRARIES) $(am__DEPENDENCIES_1)
++test_pkcs5_SOURCES = test_pkcs5.c
++test_pkcs5_OBJECTS = test_pkcs5.$(OBJEXT)
++test_pkcs5_LDADD = $(LDADD)
++test_pkcs5_DEPENDENCIES = $(lib_LTLIBRARIES) $(am__DEPENDENCIES_1)
++test_rand_SOURCES = test_rand.c
++test_rand_OBJECTS = test_rand.$(OBJEXT)
++test_rand_LDADD = $(LDADD)
++test_rand_DEPENDENCIES = $(lib_LTLIBRARIES) $(am__DEPENDENCIES_1)
++test_rsa_SOURCES = test_rsa.c
++test_rsa_OBJECTS = test_rsa.$(OBJEXT)
++test_rsa_LDADD = $(LDADD)
++test_rsa_DEPENDENCIES = $(lib_LTLIBRARIES) $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(libhcrypto_la_SOURCES) $(libhctest_la_SOURCES) destest.c \
++	example_evp_cipher.c mdtest.c rc2test.c rctest.c test_bn.c \
++	test_cipher.c test_dh.c test_engine_dso.c test_hmac.c \
++	test_pkcs12.c test_pkcs5.c test_rand.c test_rsa.c
++DIST_SOURCES = $(libhcrypto_la_SOURCES) $(libhctest_la_SOURCES) \
++	destest.c example_evp_cipher.c mdtest.c rc2test.c rctest.c \
++	test_bn.c test_cipher.c test_dh.c test_engine_dso.c \
++	test_hmac.c test_pkcs12.c test_pkcs5.c test_rand.c test_rsa.c
++HEADERS = $(hcryptoinclude_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) -I$(srcdir)/libtommath \
++	-DUSE_HCRYPTO_LTM=1
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++lib_LTLIBRARIES = libhcrypto.la
++check_LTLIBRARIES = libhctest.la
++libhcrypto_la_LDFLAGS = -version-info 5:0:1 $(am__append_1)
++libhcrypto_la_LIBADD = \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_dlopen) \
++	$(LIBADD_roken)
++
++hcryptoincludedir = $(includedir)/hcrypto
++buildhcryptoinclude = $(buildinclude)/hcrypto
++hcryptoinclude_HEADERS = \
++	aes.h			\
++	bn.h			\
++	des.h			\
++	dh.h			\
++	dsa.h			\
++	ec.h			\
++	ecdh.h			\
++	ecdsa.h			\
++	engine.h		\
++	evp.h			\
++	evp-hcrypto.h		\
++	evp-cc.h		\
++	hmac.h			\
++	md2.h			\
++	md4.h			\
++	md5.h			\
++	pkcs12.h		\
++	rand.h			\
++	rc2.h			\
++	rc4.h			\
++	rsa.h			\
++	sha.h			\
++	ui.h
++
++PROGRAM_TESTS = \
++	destest \
++	mdtest \
++	rc2test  \
++	rctest \
++	test_bn \
++	test_cipher \
++	test_engine_dso \
++	test_hmac \
++	test_pkcs12 \
++	test_pkcs5
++
++libhctest_la_SOURCES = \
++	des-tables.h	\
++	des.c		\
++	des.h		\
++	ui.c		\
++	ui.h
++
++destest_LDADD = libhctest.la $(LIB_roken)
++SCRIPT_TESTS = \
++	test_crypto
++
++check_SCRIPTS = $(SCRIPT_TESTS)
++LDADD = $(lib_LTLIBRARIES) $(LIB_roken)
++libhcrypto_la_SOURCES = \
++	$(ltmsources)	\
++	aes.c		\
++	aes.h		\
++	bn.c		\
++	bn.h		\
++	common.c	\
++	common.h	\
++	camellia.h	\
++	camellia.c	\
++	camellia-ntt.c	\
++	camellia-ntt.h	\
++	des-tables.h	\
++	des.c		\
++	des.h		\
++	dh.c		\
++	dh.h		\
++	dh-ltm.c	\
++	dsa.c		\
++	dsa.h		\
++	doxygen.c	\
++	evp.c		\
++	evp.h		\
++	evp-hcrypto.c	\
++	evp-cc.c	\
++	engine.c	\
++	engine.h	\
++	hash.h		\
++	hmac.c		\
++	hmac.h		\
++	md2.c		\
++	md2.h		\
++	md4.c		\
++	md4.h		\
++	md5.c		\
++	md5.h		\
++	pkcs5.c		\
++	pkcs12.c	\
++	rand-egd.c	\
++	rand-fortuna.c	\
++	rand-timer.c	\
++	rand-unix.c	\
++	rand.c		\
++	rand.h		\
++	randi.h		\
++	rc2.c		\
++	rc2.h		\
++	rc4.c		\
++	rc4.h		\
++	rijndael-alg-fst.c \
++	rijndael-alg-fst.h \
++	rnd_keys.c	\
++	rsa.c		\
++	rsa-gmp.c	\
++	rsa-ltm.c	\
++	rsa.h		\
++	sha.c		\
++	sha.h		\
++	sha256.c	\
++	sha512.c	\
++	validate.c	\
++	ui.c		\
++	ui.h
++
++ltmsources = \
++	libtommath/tommath.h \
++	libtommath/tommath_class.h \
++	libtommath/tommath_superclass.h \
++	libtommath/bncore.c \
++	libtommath/bn_mp_init.c \
++	libtommath/bn_mp_clear.c \
++	libtommath/bn_mp_exch.c \
++	libtommath/bn_mp_grow.c \
++	libtommath/bn_mp_shrink.c \
++	libtommath/bn_mp_clamp.c \
++	libtommath/bn_mp_zero.c \
++	libtommath/bn_mp_zero_multi.c \
++	libtommath/bn_mp_set.c \
++	libtommath/bn_mp_set_int.c \
++	libtommath/bn_mp_init_size.c \
++	libtommath/bn_mp_copy.c \
++	libtommath/bn_mp_init_copy.c \
++	libtommath/bn_mp_abs.c \
++	libtommath/bn_mp_neg.c \
++	libtommath/bn_mp_cmp_mag.c \
++	libtommath/bn_mp_cmp.c \
++	libtommath/bn_mp_cmp_d.c \
++	libtommath/bn_mp_rshd.c \
++	libtommath/bn_mp_lshd.c \
++	libtommath/bn_mp_mod_2d.c \
++	libtommath/bn_mp_div_2d.c \
++	libtommath/bn_mp_mul_2d.c \
++	libtommath/bn_mp_div_2.c \
++	libtommath/bn_mp_mul_2.c \
++	libtommath/bn_s_mp_add.c \
++	libtommath/bn_s_mp_sub.c \
++	libtommath/bn_fast_s_mp_mul_digs.c \
++	libtommath/bn_s_mp_mul_digs.c \
++	libtommath/bn_fast_s_mp_mul_high_digs.c \
++	libtommath/bn_s_mp_mul_high_digs.c \
++	libtommath/bn_fast_s_mp_sqr.c \
++	libtommath/bn_s_mp_sqr.c \
++	libtommath/bn_mp_add.c \
++	libtommath/bn_mp_sub.c \
++	libtommath/bn_mp_karatsuba_mul.c \
++	libtommath/bn_mp_mul.c \
++	libtommath/bn_mp_karatsuba_sqr.c \
++	libtommath/bn_mp_sqr.c \
++	libtommath/bn_mp_div.c \
++	libtommath/bn_mp_mod.c \
++	libtommath/bn_mp_add_d.c \
++	libtommath/bn_mp_sub_d.c \
++	libtommath/bn_mp_mul_d.c \
++	libtommath/bn_mp_div_d.c \
++	libtommath/bn_mp_mod_d.c \
++	libtommath/bn_mp_expt_d.c \
++	libtommath/bn_mp_addmod.c \
++	libtommath/bn_mp_submod.c \
++	libtommath/bn_mp_mulmod.c \
++	libtommath/bn_mp_sqrmod.c \
++	libtommath/bn_mp_gcd.c \
++	libtommath/bn_mp_lcm.c \
++	libtommath/bn_fast_mp_invmod.c \
++	libtommath/bn_mp_invmod.c \
++	libtommath/bn_mp_reduce.c \
++	libtommath/bn_mp_montgomery_setup.c \
++	libtommath/bn_fast_mp_montgomery_reduce.c \
++	libtommath/bn_mp_montgomery_reduce.c \
++	libtommath/bn_mp_exptmod_fast.c \
++	libtommath/bn_mp_exptmod.c \
++	libtommath/bn_mp_2expt.c \
++	libtommath/bn_mp_n_root.c \
++	libtommath/bn_mp_jacobi.c \
++	libtommath/bn_reverse.c \
++	libtommath/bn_mp_count_bits.c \
++	libtommath/bn_mp_read_unsigned_bin.c \
++	libtommath/bn_mp_read_signed_bin.c \
++	libtommath/bn_mp_to_unsigned_bin.c \
++	libtommath/bn_mp_to_signed_bin.c \
++	libtommath/bn_mp_unsigned_bin_size.c \
++	libtommath/bn_mp_signed_bin_size.c \
++	libtommath/bn_mp_xor.c \
++	libtommath/bn_mp_and.c \
++	libtommath/bn_mp_or.c \
++	libtommath/bn_mp_rand.c \
++	libtommath/bn_mp_montgomery_calc_normalization.c \
++	libtommath/bn_mp_prime_is_divisible.c \
++	libtommath/bn_prime_tab.c \
++	libtommath/bn_mp_prime_fermat.c \
++	libtommath/bn_mp_prime_miller_rabin.c \
++	libtommath/bn_mp_prime_is_prime.c \
++	libtommath/bn_mp_prime_next_prime.c \
++	libtommath/bn_mp_find_prime.c \
++	libtommath/bn_mp_isprime.c \
++	libtommath/bn_mp_dr_reduce.c \
++	libtommath/bn_mp_dr_is_modulus.c \
++	libtommath/bn_mp_dr_setup.c \
++	libtommath/bn_mp_reduce_setup.c \
++	libtommath/bn_mp_toom_mul.c \
++	libtommath/bn_mp_toom_sqr.c \
++	libtommath/bn_mp_div_3.c \
++	libtommath/bn_s_mp_exptmod.c \
++	libtommath/bn_mp_reduce_2k.c \
++	libtommath/bn_mp_reduce_is_2k.c \
++	libtommath/bn_mp_reduce_2k_setup.c \
++	libtommath/bn_mp_reduce_2k_l.c \
++	libtommath/bn_mp_reduce_is_2k_l.c \
++	libtommath/bn_mp_reduce_2k_setup_l.c \
++	libtommath/bn_mp_radix_smap.c \
++	libtommath/bn_mp_read_radix.c \
++	libtommath/bn_mp_toradix.c \
++	libtommath/bn_mp_radix_size.c \
++	libtommath/bn_mp_fread.c \
++	libtommath/bn_mp_fwrite.c \
++	libtommath/bn_mp_cnt_lsb.c \
++	libtommath/bn_error.c \
++	libtommath/bn_mp_init_multi.c \
++	libtommath/bn_mp_clear_multi.c \
++	libtommath/bn_mp_exteuclid.c \
++	libtommath/bn_mp_toradix_n.c \
++	libtommath/bn_mp_prime_random_ex.c \
++	libtommath/bn_mp_get_int.c \
++	libtommath/bn_mp_sqrt.c \
++	libtommath/bn_mp_is_square.c \
++	libtommath/bn_mp_init_set.c \
++	libtommath/bn_mp_init_set_int.c \
++	libtommath/bn_mp_invmod_slow.c \
++	libtommath/bn_mp_prime_rabin_miller_trials.c \
++	libtommath/bn_mp_to_signed_bin_n.c \
++	libtommath/bn_mp_to_unsigned_bin_n.c
++
++libhcrypto_la_CPPFLAGS = -DBUILD_HCRYPTO_LIB $(AM_CPPFLAGS)
++do_subst = sed -e 's,[@]srcdir[@],$(srcdir),g' -e 's,[@]exeext[@],$(exeext),g'
++CLEANFILES = \
++	crypto-test \
++	crypto-test2 \
++	error \
++	hcrypto \
++	hcrypto-link \
++	test.file \
++	test_crypto \
++	test-out* \
++	test_crypto.tmp \
++	test_crypto.tmp
++
++EXTRA_DIST = \
++	DESperate.txt \
++	dllmain.c \
++	ec.h \
++	ecdh.h \
++	ecdsa.h \
++	gen-des.pl \
++	md5crypt_test.c \
++	passwd_dialog.aps \
++	passwd_dialog.clw \
++	passwd_dialog.rc \
++	passwd_dialog.res \
++	passwd_dlg.c \
++	passwd_dlg.h \
++	resource.h \
++	rsakey.der \
++	rsakey2048.der \
++	rsakey4096.der \
++	test_crypto.in \
++	version-script.map
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/hcrypto/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/hcrypto/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++clean-checkLTLIBRARIES:
++	-test -z "$(check_LTLIBRARIES)" || rm -f $(check_LTLIBRARIES)
++	@list='$(check_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libhcrypto.la: $(libhcrypto_la_OBJECTS) $(libhcrypto_la_DEPENDENCIES) 
++	$(libhcrypto_la_LINK) -rpath $(libdir) $(libhcrypto_la_OBJECTS) $(libhcrypto_la_LIBADD) $(LIBS)
++libhctest.la: $(libhctest_la_OBJECTS) $(libhctest_la_DEPENDENCIES) 
++	$(LINK)  $(libhctest_la_OBJECTS) $(libhctest_la_LIBADD) $(LIBS)
++
++clean-checkPROGRAMS:
++	@list='$(check_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++destest$(EXEEXT): $(destest_OBJECTS) $(destest_DEPENDENCIES) 
++	@rm -f destest$(EXEEXT)
++	$(LINK) $(destest_OBJECTS) $(destest_LDADD) $(LIBS)
++example_evp_cipher$(EXEEXT): $(example_evp_cipher_OBJECTS) $(example_evp_cipher_DEPENDENCIES) 
++	@rm -f example_evp_cipher$(EXEEXT)
++	$(LINK) $(example_evp_cipher_OBJECTS) $(example_evp_cipher_LDADD) $(LIBS)
++mdtest$(EXEEXT): $(mdtest_OBJECTS) $(mdtest_DEPENDENCIES) 
++	@rm -f mdtest$(EXEEXT)
++	$(LINK) $(mdtest_OBJECTS) $(mdtest_LDADD) $(LIBS)
++rc2test$(EXEEXT): $(rc2test_OBJECTS) $(rc2test_DEPENDENCIES) 
++	@rm -f rc2test$(EXEEXT)
++	$(LINK) $(rc2test_OBJECTS) $(rc2test_LDADD) $(LIBS)
++rctest$(EXEEXT): $(rctest_OBJECTS) $(rctest_DEPENDENCIES) 
++	@rm -f rctest$(EXEEXT)
++	$(LINK) $(rctest_OBJECTS) $(rctest_LDADD) $(LIBS)
++test_bn$(EXEEXT): $(test_bn_OBJECTS) $(test_bn_DEPENDENCIES) 
++	@rm -f test_bn$(EXEEXT)
++	$(LINK) $(test_bn_OBJECTS) $(test_bn_LDADD) $(LIBS)
++test_cipher$(EXEEXT): $(test_cipher_OBJECTS) $(test_cipher_DEPENDENCIES) 
++	@rm -f test_cipher$(EXEEXT)
++	$(LINK) $(test_cipher_OBJECTS) $(test_cipher_LDADD) $(LIBS)
++test_dh$(EXEEXT): $(test_dh_OBJECTS) $(test_dh_DEPENDENCIES) 
++	@rm -f test_dh$(EXEEXT)
++	$(LINK) $(test_dh_OBJECTS) $(test_dh_LDADD) $(LIBS)
++test_engine_dso$(EXEEXT): $(test_engine_dso_OBJECTS) $(test_engine_dso_DEPENDENCIES) 
++	@rm -f test_engine_dso$(EXEEXT)
++	$(LINK) $(test_engine_dso_OBJECTS) $(test_engine_dso_LDADD) $(LIBS)
++test_hmac$(EXEEXT): $(test_hmac_OBJECTS) $(test_hmac_DEPENDENCIES) 
++	@rm -f test_hmac$(EXEEXT)
++	$(LINK) $(test_hmac_OBJECTS) $(test_hmac_LDADD) $(LIBS)
++test_pkcs12$(EXEEXT): $(test_pkcs12_OBJECTS) $(test_pkcs12_DEPENDENCIES) 
++	@rm -f test_pkcs12$(EXEEXT)
++	$(LINK) $(test_pkcs12_OBJECTS) $(test_pkcs12_LDADD) $(LIBS)
++test_pkcs5$(EXEEXT): $(test_pkcs5_OBJECTS) $(test_pkcs5_DEPENDENCIES) 
++	@rm -f test_pkcs5$(EXEEXT)
++	$(LINK) $(test_pkcs5_OBJECTS) $(test_pkcs5_LDADD) $(LIBS)
++test_rand$(EXEEXT): $(test_rand_OBJECTS) $(test_rand_DEPENDENCIES) 
++	@rm -f test_rand$(EXEEXT)
++	$(LINK) $(test_rand_OBJECTS) $(test_rand_LDADD) $(LIBS)
++test_rsa$(EXEEXT): $(test_rsa_OBJECTS) $(test_rsa_DEPENDENCIES) 
++	@rm -f test_rsa$(EXEEXT)
++	$(LINK) $(test_rsa_OBJECTS) $(test_rsa_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/des.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/destest.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/example_evp_cipher.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-aes.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_error.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_fast_mp_invmod.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_fast_mp_montgomery_reduce.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_fast_s_mp_mul_digs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_fast_s_mp_mul_high_digs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_fast_s_mp_sqr.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_2expt.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_abs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_add.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_add_d.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_addmod.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_and.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_clamp.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_clear.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_clear_multi.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_cmp.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_cmp_d.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_cmp_mag.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_cnt_lsb.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_copy.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_count_bits.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_div.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_div_2.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_div_2d.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_div_3.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_div_d.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_dr_is_modulus.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_dr_reduce.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_dr_setup.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_exch.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_expt_d.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_exptmod.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_exptmod_fast.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_exteuclid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_find_prime.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_fread.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_fwrite.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_gcd.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_get_int.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_grow.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_init.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_init_copy.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_init_multi.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_init_set.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_init_set_int.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_init_size.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_invmod.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_invmod_slow.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_is_square.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_isprime.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_jacobi.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_karatsuba_mul.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_karatsuba_sqr.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_lcm.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_lshd.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_mod.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_mod_2d.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_mod_d.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_montgomery_calc_normalization.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_montgomery_reduce.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_montgomery_setup.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_mul.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_mul_2.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_mul_2d.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_mul_d.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_mulmod.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_n_root.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_neg.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_or.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_prime_fermat.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_prime_is_divisible.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_prime_is_prime.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_prime_miller_rabin.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_prime_next_prime.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_prime_rabin_miller_trials.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_prime_random_ex.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_radix_size.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_radix_smap.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_rand.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_read_radix.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_read_signed_bin.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_read_unsigned_bin.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_reduce.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k_l.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k_setup.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k_setup_l.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_reduce_is_2k.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_reduce_is_2k_l.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_reduce_setup.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_rshd.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_set.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_set_int.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_shrink.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_signed_bin_size.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_sqr.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_sqrmod.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_sqrt.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_sub.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_sub_d.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_submod.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_to_signed_bin.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_to_signed_bin_n.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_to_unsigned_bin.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_to_unsigned_bin_n.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_toom_mul.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_toom_sqr.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_toradix.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_toradix_n.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_unsigned_bin_size.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_xor.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_zero.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_mp_zero_multi.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_prime_tab.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_reverse.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_s_mp_add.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_s_mp_exptmod.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_s_mp_mul_digs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_s_mp_mul_high_digs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_s_mp_sqr.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bn_s_mp_sub.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-bncore.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-camellia-ntt.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-camellia.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-common.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-des.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-dh-ltm.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-dh.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-doxygen.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-dsa.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-engine.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-evp-cc.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-evp-hcrypto.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-evp.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-hmac.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-md2.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-md4.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-md5.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-pkcs12.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-pkcs5.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-rand-egd.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-rand-fortuna.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-rand-timer.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-rand-unix.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-rand.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-rc2.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-rc4.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-rijndael-alg-fst.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-rnd_keys.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-rsa-gmp.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-rsa-ltm.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-rsa.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-sha.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-sha256.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-sha512.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-ui.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhcrypto_la-validate.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/mdtest.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/rc2test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/rctest.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_bn.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_cipher.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_dh.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_engine_dso.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_hmac.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_pkcs12.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_pkcs5.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_rand.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_rsa.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ui.Plo@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++libhcrypto_la-bncore.lo: libtommath/bncore.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bncore.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bncore.Tpo -c -o libhcrypto_la-bncore.lo `test -f 'libtommath/bncore.c' || echo '$(srcdir)/'`libtommath/bncore.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bncore.Tpo $(DEPDIR)/libhcrypto_la-bncore.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bncore.c' object='libhcrypto_la-bncore.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bncore.lo `test -f 'libtommath/bncore.c' || echo '$(srcdir)/'`libtommath/bncore.c
++
++libhcrypto_la-bn_mp_init.lo: libtommath/bn_mp_init.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_init.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_init.Tpo -c -o libhcrypto_la-bn_mp_init.lo `test -f 'libtommath/bn_mp_init.c' || echo '$(srcdir)/'`libtommath/bn_mp_init.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_init.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_init.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_init.c' object='libhcrypto_la-bn_mp_init.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_init.lo `test -f 'libtommath/bn_mp_init.c' || echo '$(srcdir)/'`libtommath/bn_mp_init.c
++
++libhcrypto_la-bn_mp_clear.lo: libtommath/bn_mp_clear.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_clear.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_clear.Tpo -c -o libhcrypto_la-bn_mp_clear.lo `test -f 'libtommath/bn_mp_clear.c' || echo '$(srcdir)/'`libtommath/bn_mp_clear.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_clear.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_clear.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_clear.c' object='libhcrypto_la-bn_mp_clear.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_clear.lo `test -f 'libtommath/bn_mp_clear.c' || echo '$(srcdir)/'`libtommath/bn_mp_clear.c
++
++libhcrypto_la-bn_mp_exch.lo: libtommath/bn_mp_exch.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_exch.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_exch.Tpo -c -o libhcrypto_la-bn_mp_exch.lo `test -f 'libtommath/bn_mp_exch.c' || echo '$(srcdir)/'`libtommath/bn_mp_exch.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_exch.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_exch.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_exch.c' object='libhcrypto_la-bn_mp_exch.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_exch.lo `test -f 'libtommath/bn_mp_exch.c' || echo '$(srcdir)/'`libtommath/bn_mp_exch.c
++
++libhcrypto_la-bn_mp_grow.lo: libtommath/bn_mp_grow.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_grow.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_grow.Tpo -c -o libhcrypto_la-bn_mp_grow.lo `test -f 'libtommath/bn_mp_grow.c' || echo '$(srcdir)/'`libtommath/bn_mp_grow.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_grow.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_grow.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_grow.c' object='libhcrypto_la-bn_mp_grow.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_grow.lo `test -f 'libtommath/bn_mp_grow.c' || echo '$(srcdir)/'`libtommath/bn_mp_grow.c
++
++libhcrypto_la-bn_mp_shrink.lo: libtommath/bn_mp_shrink.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_shrink.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_shrink.Tpo -c -o libhcrypto_la-bn_mp_shrink.lo `test -f 'libtommath/bn_mp_shrink.c' || echo '$(srcdir)/'`libtommath/bn_mp_shrink.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_shrink.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_shrink.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_shrink.c' object='libhcrypto_la-bn_mp_shrink.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_shrink.lo `test -f 'libtommath/bn_mp_shrink.c' || echo '$(srcdir)/'`libtommath/bn_mp_shrink.c
++
++libhcrypto_la-bn_mp_clamp.lo: libtommath/bn_mp_clamp.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_clamp.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_clamp.Tpo -c -o libhcrypto_la-bn_mp_clamp.lo `test -f 'libtommath/bn_mp_clamp.c' || echo '$(srcdir)/'`libtommath/bn_mp_clamp.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_clamp.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_clamp.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_clamp.c' object='libhcrypto_la-bn_mp_clamp.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_clamp.lo `test -f 'libtommath/bn_mp_clamp.c' || echo '$(srcdir)/'`libtommath/bn_mp_clamp.c
++
++libhcrypto_la-bn_mp_zero.lo: libtommath/bn_mp_zero.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_zero.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_zero.Tpo -c -o libhcrypto_la-bn_mp_zero.lo `test -f 'libtommath/bn_mp_zero.c' || echo '$(srcdir)/'`libtommath/bn_mp_zero.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_zero.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_zero.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_zero.c' object='libhcrypto_la-bn_mp_zero.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_zero.lo `test -f 'libtommath/bn_mp_zero.c' || echo '$(srcdir)/'`libtommath/bn_mp_zero.c
++
++libhcrypto_la-bn_mp_zero_multi.lo: libtommath/bn_mp_zero_multi.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_zero_multi.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_zero_multi.Tpo -c -o libhcrypto_la-bn_mp_zero_multi.lo `test -f 'libtommath/bn_mp_zero_multi.c' || echo '$(srcdir)/'`libtommath/bn_mp_zero_multi.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_zero_multi.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_zero_multi.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_zero_multi.c' object='libhcrypto_la-bn_mp_zero_multi.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_zero_multi.lo `test -f 'libtommath/bn_mp_zero_multi.c' || echo '$(srcdir)/'`libtommath/bn_mp_zero_multi.c
++
++libhcrypto_la-bn_mp_set.lo: libtommath/bn_mp_set.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_set.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_set.Tpo -c -o libhcrypto_la-bn_mp_set.lo `test -f 'libtommath/bn_mp_set.c' || echo '$(srcdir)/'`libtommath/bn_mp_set.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_set.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_set.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_set.c' object='libhcrypto_la-bn_mp_set.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_set.lo `test -f 'libtommath/bn_mp_set.c' || echo '$(srcdir)/'`libtommath/bn_mp_set.c
++
++libhcrypto_la-bn_mp_set_int.lo: libtommath/bn_mp_set_int.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_set_int.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_set_int.Tpo -c -o libhcrypto_la-bn_mp_set_int.lo `test -f 'libtommath/bn_mp_set_int.c' || echo '$(srcdir)/'`libtommath/bn_mp_set_int.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_set_int.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_set_int.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_set_int.c' object='libhcrypto_la-bn_mp_set_int.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_set_int.lo `test -f 'libtommath/bn_mp_set_int.c' || echo '$(srcdir)/'`libtommath/bn_mp_set_int.c
++
++libhcrypto_la-bn_mp_init_size.lo: libtommath/bn_mp_init_size.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_init_size.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_init_size.Tpo -c -o libhcrypto_la-bn_mp_init_size.lo `test -f 'libtommath/bn_mp_init_size.c' || echo '$(srcdir)/'`libtommath/bn_mp_init_size.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_init_size.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_init_size.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_init_size.c' object='libhcrypto_la-bn_mp_init_size.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_init_size.lo `test -f 'libtommath/bn_mp_init_size.c' || echo '$(srcdir)/'`libtommath/bn_mp_init_size.c
++
++libhcrypto_la-bn_mp_copy.lo: libtommath/bn_mp_copy.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_copy.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_copy.Tpo -c -o libhcrypto_la-bn_mp_copy.lo `test -f 'libtommath/bn_mp_copy.c' || echo '$(srcdir)/'`libtommath/bn_mp_copy.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_copy.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_copy.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_copy.c' object='libhcrypto_la-bn_mp_copy.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_copy.lo `test -f 'libtommath/bn_mp_copy.c' || echo '$(srcdir)/'`libtommath/bn_mp_copy.c
++
++libhcrypto_la-bn_mp_init_copy.lo: libtommath/bn_mp_init_copy.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_init_copy.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_init_copy.Tpo -c -o libhcrypto_la-bn_mp_init_copy.lo `test -f 'libtommath/bn_mp_init_copy.c' || echo '$(srcdir)/'`libtommath/bn_mp_init_copy.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_init_copy.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_init_copy.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_init_copy.c' object='libhcrypto_la-bn_mp_init_copy.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_init_copy.lo `test -f 'libtommath/bn_mp_init_copy.c' || echo '$(srcdir)/'`libtommath/bn_mp_init_copy.c
++
++libhcrypto_la-bn_mp_abs.lo: libtommath/bn_mp_abs.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_abs.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_abs.Tpo -c -o libhcrypto_la-bn_mp_abs.lo `test -f 'libtommath/bn_mp_abs.c' || echo '$(srcdir)/'`libtommath/bn_mp_abs.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_abs.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_abs.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_abs.c' object='libhcrypto_la-bn_mp_abs.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_abs.lo `test -f 'libtommath/bn_mp_abs.c' || echo '$(srcdir)/'`libtommath/bn_mp_abs.c
++
++libhcrypto_la-bn_mp_neg.lo: libtommath/bn_mp_neg.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_neg.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_neg.Tpo -c -o libhcrypto_la-bn_mp_neg.lo `test -f 'libtommath/bn_mp_neg.c' || echo '$(srcdir)/'`libtommath/bn_mp_neg.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_neg.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_neg.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_neg.c' object='libhcrypto_la-bn_mp_neg.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_neg.lo `test -f 'libtommath/bn_mp_neg.c' || echo '$(srcdir)/'`libtommath/bn_mp_neg.c
++
++libhcrypto_la-bn_mp_cmp_mag.lo: libtommath/bn_mp_cmp_mag.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_cmp_mag.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_cmp_mag.Tpo -c -o libhcrypto_la-bn_mp_cmp_mag.lo `test -f 'libtommath/bn_mp_cmp_mag.c' || echo '$(srcdir)/'`libtommath/bn_mp_cmp_mag.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_cmp_mag.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_cmp_mag.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_cmp_mag.c' object='libhcrypto_la-bn_mp_cmp_mag.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_cmp_mag.lo `test -f 'libtommath/bn_mp_cmp_mag.c' || echo '$(srcdir)/'`libtommath/bn_mp_cmp_mag.c
++
++libhcrypto_la-bn_mp_cmp.lo: libtommath/bn_mp_cmp.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_cmp.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_cmp.Tpo -c -o libhcrypto_la-bn_mp_cmp.lo `test -f 'libtommath/bn_mp_cmp.c' || echo '$(srcdir)/'`libtommath/bn_mp_cmp.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_cmp.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_cmp.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_cmp.c' object='libhcrypto_la-bn_mp_cmp.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_cmp.lo `test -f 'libtommath/bn_mp_cmp.c' || echo '$(srcdir)/'`libtommath/bn_mp_cmp.c
++
++libhcrypto_la-bn_mp_cmp_d.lo: libtommath/bn_mp_cmp_d.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_cmp_d.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_cmp_d.Tpo -c -o libhcrypto_la-bn_mp_cmp_d.lo `test -f 'libtommath/bn_mp_cmp_d.c' || echo '$(srcdir)/'`libtommath/bn_mp_cmp_d.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_cmp_d.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_cmp_d.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_cmp_d.c' object='libhcrypto_la-bn_mp_cmp_d.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_cmp_d.lo `test -f 'libtommath/bn_mp_cmp_d.c' || echo '$(srcdir)/'`libtommath/bn_mp_cmp_d.c
++
++libhcrypto_la-bn_mp_rshd.lo: libtommath/bn_mp_rshd.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_rshd.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_rshd.Tpo -c -o libhcrypto_la-bn_mp_rshd.lo `test -f 'libtommath/bn_mp_rshd.c' || echo '$(srcdir)/'`libtommath/bn_mp_rshd.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_rshd.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_rshd.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_rshd.c' object='libhcrypto_la-bn_mp_rshd.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_rshd.lo `test -f 'libtommath/bn_mp_rshd.c' || echo '$(srcdir)/'`libtommath/bn_mp_rshd.c
++
++libhcrypto_la-bn_mp_lshd.lo: libtommath/bn_mp_lshd.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_lshd.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_lshd.Tpo -c -o libhcrypto_la-bn_mp_lshd.lo `test -f 'libtommath/bn_mp_lshd.c' || echo '$(srcdir)/'`libtommath/bn_mp_lshd.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_lshd.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_lshd.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_lshd.c' object='libhcrypto_la-bn_mp_lshd.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_lshd.lo `test -f 'libtommath/bn_mp_lshd.c' || echo '$(srcdir)/'`libtommath/bn_mp_lshd.c
++
++libhcrypto_la-bn_mp_mod_2d.lo: libtommath/bn_mp_mod_2d.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_mod_2d.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_mod_2d.Tpo -c -o libhcrypto_la-bn_mp_mod_2d.lo `test -f 'libtommath/bn_mp_mod_2d.c' || echo '$(srcdir)/'`libtommath/bn_mp_mod_2d.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_mod_2d.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_mod_2d.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_mod_2d.c' object='libhcrypto_la-bn_mp_mod_2d.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_mod_2d.lo `test -f 'libtommath/bn_mp_mod_2d.c' || echo '$(srcdir)/'`libtommath/bn_mp_mod_2d.c
++
++libhcrypto_la-bn_mp_div_2d.lo: libtommath/bn_mp_div_2d.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_div_2d.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_div_2d.Tpo -c -o libhcrypto_la-bn_mp_div_2d.lo `test -f 'libtommath/bn_mp_div_2d.c' || echo '$(srcdir)/'`libtommath/bn_mp_div_2d.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_div_2d.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_div_2d.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_div_2d.c' object='libhcrypto_la-bn_mp_div_2d.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_div_2d.lo `test -f 'libtommath/bn_mp_div_2d.c' || echo '$(srcdir)/'`libtommath/bn_mp_div_2d.c
++
++libhcrypto_la-bn_mp_mul_2d.lo: libtommath/bn_mp_mul_2d.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_mul_2d.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_mul_2d.Tpo -c -o libhcrypto_la-bn_mp_mul_2d.lo `test -f 'libtommath/bn_mp_mul_2d.c' || echo '$(srcdir)/'`libtommath/bn_mp_mul_2d.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_mul_2d.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_mul_2d.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_mul_2d.c' object='libhcrypto_la-bn_mp_mul_2d.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_mul_2d.lo `test -f 'libtommath/bn_mp_mul_2d.c' || echo '$(srcdir)/'`libtommath/bn_mp_mul_2d.c
++
++libhcrypto_la-bn_mp_div_2.lo: libtommath/bn_mp_div_2.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_div_2.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_div_2.Tpo -c -o libhcrypto_la-bn_mp_div_2.lo `test -f 'libtommath/bn_mp_div_2.c' || echo '$(srcdir)/'`libtommath/bn_mp_div_2.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_div_2.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_div_2.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_div_2.c' object='libhcrypto_la-bn_mp_div_2.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_div_2.lo `test -f 'libtommath/bn_mp_div_2.c' || echo '$(srcdir)/'`libtommath/bn_mp_div_2.c
++
++libhcrypto_la-bn_mp_mul_2.lo: libtommath/bn_mp_mul_2.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_mul_2.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_mul_2.Tpo -c -o libhcrypto_la-bn_mp_mul_2.lo `test -f 'libtommath/bn_mp_mul_2.c' || echo '$(srcdir)/'`libtommath/bn_mp_mul_2.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_mul_2.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_mul_2.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_mul_2.c' object='libhcrypto_la-bn_mp_mul_2.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_mul_2.lo `test -f 'libtommath/bn_mp_mul_2.c' || echo '$(srcdir)/'`libtommath/bn_mp_mul_2.c
++
++libhcrypto_la-bn_s_mp_add.lo: libtommath/bn_s_mp_add.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_s_mp_add.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_s_mp_add.Tpo -c -o libhcrypto_la-bn_s_mp_add.lo `test -f 'libtommath/bn_s_mp_add.c' || echo '$(srcdir)/'`libtommath/bn_s_mp_add.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_s_mp_add.Tpo $(DEPDIR)/libhcrypto_la-bn_s_mp_add.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_s_mp_add.c' object='libhcrypto_la-bn_s_mp_add.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_s_mp_add.lo `test -f 'libtommath/bn_s_mp_add.c' || echo '$(srcdir)/'`libtommath/bn_s_mp_add.c
++
++libhcrypto_la-bn_s_mp_sub.lo: libtommath/bn_s_mp_sub.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_s_mp_sub.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_s_mp_sub.Tpo -c -o libhcrypto_la-bn_s_mp_sub.lo `test -f 'libtommath/bn_s_mp_sub.c' || echo '$(srcdir)/'`libtommath/bn_s_mp_sub.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_s_mp_sub.Tpo $(DEPDIR)/libhcrypto_la-bn_s_mp_sub.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_s_mp_sub.c' object='libhcrypto_la-bn_s_mp_sub.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_s_mp_sub.lo `test -f 'libtommath/bn_s_mp_sub.c' || echo '$(srcdir)/'`libtommath/bn_s_mp_sub.c
++
++libhcrypto_la-bn_fast_s_mp_mul_digs.lo: libtommath/bn_fast_s_mp_mul_digs.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_fast_s_mp_mul_digs.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_fast_s_mp_mul_digs.Tpo -c -o libhcrypto_la-bn_fast_s_mp_mul_digs.lo `test -f 'libtommath/bn_fast_s_mp_mul_digs.c' || echo '$(srcdir)/'`libtommath/bn_fast_s_mp_mul_digs.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_fast_s_mp_mul_digs.Tpo $(DEPDIR)/libhcrypto_la-bn_fast_s_mp_mul_digs.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_fast_s_mp_mul_digs.c' object='libhcrypto_la-bn_fast_s_mp_mul_digs.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_fast_s_mp_mul_digs.lo `test -f 'libtommath/bn_fast_s_mp_mul_digs.c' || echo '$(srcdir)/'`libtommath/bn_fast_s_mp_mul_digs.c
++
++libhcrypto_la-bn_s_mp_mul_digs.lo: libtommath/bn_s_mp_mul_digs.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_s_mp_mul_digs.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_s_mp_mul_digs.Tpo -c -o libhcrypto_la-bn_s_mp_mul_digs.lo `test -f 'libtommath/bn_s_mp_mul_digs.c' || echo '$(srcdir)/'`libtommath/bn_s_mp_mul_digs.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_s_mp_mul_digs.Tpo $(DEPDIR)/libhcrypto_la-bn_s_mp_mul_digs.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_s_mp_mul_digs.c' object='libhcrypto_la-bn_s_mp_mul_digs.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_s_mp_mul_digs.lo `test -f 'libtommath/bn_s_mp_mul_digs.c' || echo '$(srcdir)/'`libtommath/bn_s_mp_mul_digs.c
++
++libhcrypto_la-bn_fast_s_mp_mul_high_digs.lo: libtommath/bn_fast_s_mp_mul_high_digs.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_fast_s_mp_mul_high_digs.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_fast_s_mp_mul_high_digs.Tpo -c -o libhcrypto_la-bn_fast_s_mp_mul_high_digs.lo `test -f 'libtommath/bn_fast_s_mp_mul_high_digs.c' || echo '$(srcdir)/'`libtommath/bn_fast_s_mp_mul_high_digs.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_fast_s_mp_mul_high_digs.Tpo $(DEPDIR)/libhcrypto_la-bn_fast_s_mp_mul_high_digs.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_fast_s_mp_mul_high_digs.c' object='libhcrypto_la-bn_fast_s_mp_mul_high_digs.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_fast_s_mp_mul_high_digs.lo `test -f 'libtommath/bn_fast_s_mp_mul_high_digs.c' || echo '$(srcdir)/'`libtommath/bn_fast_s_mp_mul_high_digs.c
++
++libhcrypto_la-bn_s_mp_mul_high_digs.lo: libtommath/bn_s_mp_mul_high_digs.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_s_mp_mul_high_digs.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_s_mp_mul_high_digs.Tpo -c -o libhcrypto_la-bn_s_mp_mul_high_digs.lo `test -f 'libtommath/bn_s_mp_mul_high_digs.c' || echo '$(srcdir)/'`libtommath/bn_s_mp_mul_high_digs.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_s_mp_mul_high_digs.Tpo $(DEPDIR)/libhcrypto_la-bn_s_mp_mul_high_digs.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_s_mp_mul_high_digs.c' object='libhcrypto_la-bn_s_mp_mul_high_digs.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_s_mp_mul_high_digs.lo `test -f 'libtommath/bn_s_mp_mul_high_digs.c' || echo '$(srcdir)/'`libtommath/bn_s_mp_mul_high_digs.c
++
++libhcrypto_la-bn_fast_s_mp_sqr.lo: libtommath/bn_fast_s_mp_sqr.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_fast_s_mp_sqr.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_fast_s_mp_sqr.Tpo -c -o libhcrypto_la-bn_fast_s_mp_sqr.lo `test -f 'libtommath/bn_fast_s_mp_sqr.c' || echo '$(srcdir)/'`libtommath/bn_fast_s_mp_sqr.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_fast_s_mp_sqr.Tpo $(DEPDIR)/libhcrypto_la-bn_fast_s_mp_sqr.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_fast_s_mp_sqr.c' object='libhcrypto_la-bn_fast_s_mp_sqr.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_fast_s_mp_sqr.lo `test -f 'libtommath/bn_fast_s_mp_sqr.c' || echo '$(srcdir)/'`libtommath/bn_fast_s_mp_sqr.c
++
++libhcrypto_la-bn_s_mp_sqr.lo: libtommath/bn_s_mp_sqr.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_s_mp_sqr.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_s_mp_sqr.Tpo -c -o libhcrypto_la-bn_s_mp_sqr.lo `test -f 'libtommath/bn_s_mp_sqr.c' || echo '$(srcdir)/'`libtommath/bn_s_mp_sqr.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_s_mp_sqr.Tpo $(DEPDIR)/libhcrypto_la-bn_s_mp_sqr.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_s_mp_sqr.c' object='libhcrypto_la-bn_s_mp_sqr.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_s_mp_sqr.lo `test -f 'libtommath/bn_s_mp_sqr.c' || echo '$(srcdir)/'`libtommath/bn_s_mp_sqr.c
++
++libhcrypto_la-bn_mp_add.lo: libtommath/bn_mp_add.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_add.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_add.Tpo -c -o libhcrypto_la-bn_mp_add.lo `test -f 'libtommath/bn_mp_add.c' || echo '$(srcdir)/'`libtommath/bn_mp_add.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_add.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_add.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_add.c' object='libhcrypto_la-bn_mp_add.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_add.lo `test -f 'libtommath/bn_mp_add.c' || echo '$(srcdir)/'`libtommath/bn_mp_add.c
++
++libhcrypto_la-bn_mp_sub.lo: libtommath/bn_mp_sub.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_sub.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_sub.Tpo -c -o libhcrypto_la-bn_mp_sub.lo `test -f 'libtommath/bn_mp_sub.c' || echo '$(srcdir)/'`libtommath/bn_mp_sub.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_sub.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_sub.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_sub.c' object='libhcrypto_la-bn_mp_sub.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_sub.lo `test -f 'libtommath/bn_mp_sub.c' || echo '$(srcdir)/'`libtommath/bn_mp_sub.c
++
++libhcrypto_la-bn_mp_karatsuba_mul.lo: libtommath/bn_mp_karatsuba_mul.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_karatsuba_mul.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_karatsuba_mul.Tpo -c -o libhcrypto_la-bn_mp_karatsuba_mul.lo `test -f 'libtommath/bn_mp_karatsuba_mul.c' || echo '$(srcdir)/'`libtommath/bn_mp_karatsuba_mul.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_karatsuba_mul.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_karatsuba_mul.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_karatsuba_mul.c' object='libhcrypto_la-bn_mp_karatsuba_mul.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_karatsuba_mul.lo `test -f 'libtommath/bn_mp_karatsuba_mul.c' || echo '$(srcdir)/'`libtommath/bn_mp_karatsuba_mul.c
++
++libhcrypto_la-bn_mp_mul.lo: libtommath/bn_mp_mul.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_mul.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_mul.Tpo -c -o libhcrypto_la-bn_mp_mul.lo `test -f 'libtommath/bn_mp_mul.c' || echo '$(srcdir)/'`libtommath/bn_mp_mul.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_mul.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_mul.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_mul.c' object='libhcrypto_la-bn_mp_mul.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_mul.lo `test -f 'libtommath/bn_mp_mul.c' || echo '$(srcdir)/'`libtommath/bn_mp_mul.c
++
++libhcrypto_la-bn_mp_karatsuba_sqr.lo: libtommath/bn_mp_karatsuba_sqr.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_karatsuba_sqr.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_karatsuba_sqr.Tpo -c -o libhcrypto_la-bn_mp_karatsuba_sqr.lo `test -f 'libtommath/bn_mp_karatsuba_sqr.c' || echo '$(srcdir)/'`libtommath/bn_mp_karatsuba_sqr.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_karatsuba_sqr.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_karatsuba_sqr.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_karatsuba_sqr.c' object='libhcrypto_la-bn_mp_karatsuba_sqr.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_karatsuba_sqr.lo `test -f 'libtommath/bn_mp_karatsuba_sqr.c' || echo '$(srcdir)/'`libtommath/bn_mp_karatsuba_sqr.c
++
++libhcrypto_la-bn_mp_sqr.lo: libtommath/bn_mp_sqr.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_sqr.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_sqr.Tpo -c -o libhcrypto_la-bn_mp_sqr.lo `test -f 'libtommath/bn_mp_sqr.c' || echo '$(srcdir)/'`libtommath/bn_mp_sqr.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_sqr.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_sqr.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_sqr.c' object='libhcrypto_la-bn_mp_sqr.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_sqr.lo `test -f 'libtommath/bn_mp_sqr.c' || echo '$(srcdir)/'`libtommath/bn_mp_sqr.c
++
++libhcrypto_la-bn_mp_div.lo: libtommath/bn_mp_div.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_div.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_div.Tpo -c -o libhcrypto_la-bn_mp_div.lo `test -f 'libtommath/bn_mp_div.c' || echo '$(srcdir)/'`libtommath/bn_mp_div.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_div.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_div.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_div.c' object='libhcrypto_la-bn_mp_div.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_div.lo `test -f 'libtommath/bn_mp_div.c' || echo '$(srcdir)/'`libtommath/bn_mp_div.c
++
++libhcrypto_la-bn_mp_mod.lo: libtommath/bn_mp_mod.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_mod.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_mod.Tpo -c -o libhcrypto_la-bn_mp_mod.lo `test -f 'libtommath/bn_mp_mod.c' || echo '$(srcdir)/'`libtommath/bn_mp_mod.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_mod.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_mod.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_mod.c' object='libhcrypto_la-bn_mp_mod.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_mod.lo `test -f 'libtommath/bn_mp_mod.c' || echo '$(srcdir)/'`libtommath/bn_mp_mod.c
++
++libhcrypto_la-bn_mp_add_d.lo: libtommath/bn_mp_add_d.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_add_d.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_add_d.Tpo -c -o libhcrypto_la-bn_mp_add_d.lo `test -f 'libtommath/bn_mp_add_d.c' || echo '$(srcdir)/'`libtommath/bn_mp_add_d.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_add_d.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_add_d.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_add_d.c' object='libhcrypto_la-bn_mp_add_d.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_add_d.lo `test -f 'libtommath/bn_mp_add_d.c' || echo '$(srcdir)/'`libtommath/bn_mp_add_d.c
++
++libhcrypto_la-bn_mp_sub_d.lo: libtommath/bn_mp_sub_d.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_sub_d.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_sub_d.Tpo -c -o libhcrypto_la-bn_mp_sub_d.lo `test -f 'libtommath/bn_mp_sub_d.c' || echo '$(srcdir)/'`libtommath/bn_mp_sub_d.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_sub_d.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_sub_d.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_sub_d.c' object='libhcrypto_la-bn_mp_sub_d.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_sub_d.lo `test -f 'libtommath/bn_mp_sub_d.c' || echo '$(srcdir)/'`libtommath/bn_mp_sub_d.c
++
++libhcrypto_la-bn_mp_mul_d.lo: libtommath/bn_mp_mul_d.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_mul_d.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_mul_d.Tpo -c -o libhcrypto_la-bn_mp_mul_d.lo `test -f 'libtommath/bn_mp_mul_d.c' || echo '$(srcdir)/'`libtommath/bn_mp_mul_d.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_mul_d.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_mul_d.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_mul_d.c' object='libhcrypto_la-bn_mp_mul_d.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_mul_d.lo `test -f 'libtommath/bn_mp_mul_d.c' || echo '$(srcdir)/'`libtommath/bn_mp_mul_d.c
++
++libhcrypto_la-bn_mp_div_d.lo: libtommath/bn_mp_div_d.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_div_d.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_div_d.Tpo -c -o libhcrypto_la-bn_mp_div_d.lo `test -f 'libtommath/bn_mp_div_d.c' || echo '$(srcdir)/'`libtommath/bn_mp_div_d.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_div_d.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_div_d.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_div_d.c' object='libhcrypto_la-bn_mp_div_d.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_div_d.lo `test -f 'libtommath/bn_mp_div_d.c' || echo '$(srcdir)/'`libtommath/bn_mp_div_d.c
++
++libhcrypto_la-bn_mp_mod_d.lo: libtommath/bn_mp_mod_d.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_mod_d.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_mod_d.Tpo -c -o libhcrypto_la-bn_mp_mod_d.lo `test -f 'libtommath/bn_mp_mod_d.c' || echo '$(srcdir)/'`libtommath/bn_mp_mod_d.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_mod_d.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_mod_d.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_mod_d.c' object='libhcrypto_la-bn_mp_mod_d.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_mod_d.lo `test -f 'libtommath/bn_mp_mod_d.c' || echo '$(srcdir)/'`libtommath/bn_mp_mod_d.c
++
++libhcrypto_la-bn_mp_expt_d.lo: libtommath/bn_mp_expt_d.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_expt_d.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_expt_d.Tpo -c -o libhcrypto_la-bn_mp_expt_d.lo `test -f 'libtommath/bn_mp_expt_d.c' || echo '$(srcdir)/'`libtommath/bn_mp_expt_d.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_expt_d.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_expt_d.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_expt_d.c' object='libhcrypto_la-bn_mp_expt_d.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_expt_d.lo `test -f 'libtommath/bn_mp_expt_d.c' || echo '$(srcdir)/'`libtommath/bn_mp_expt_d.c
++
++libhcrypto_la-bn_mp_addmod.lo: libtommath/bn_mp_addmod.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_addmod.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_addmod.Tpo -c -o libhcrypto_la-bn_mp_addmod.lo `test -f 'libtommath/bn_mp_addmod.c' || echo '$(srcdir)/'`libtommath/bn_mp_addmod.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_addmod.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_addmod.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_addmod.c' object='libhcrypto_la-bn_mp_addmod.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_addmod.lo `test -f 'libtommath/bn_mp_addmod.c' || echo '$(srcdir)/'`libtommath/bn_mp_addmod.c
++
++libhcrypto_la-bn_mp_submod.lo: libtommath/bn_mp_submod.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_submod.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_submod.Tpo -c -o libhcrypto_la-bn_mp_submod.lo `test -f 'libtommath/bn_mp_submod.c' || echo '$(srcdir)/'`libtommath/bn_mp_submod.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_submod.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_submod.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_submod.c' object='libhcrypto_la-bn_mp_submod.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_submod.lo `test -f 'libtommath/bn_mp_submod.c' || echo '$(srcdir)/'`libtommath/bn_mp_submod.c
++
++libhcrypto_la-bn_mp_mulmod.lo: libtommath/bn_mp_mulmod.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_mulmod.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_mulmod.Tpo -c -o libhcrypto_la-bn_mp_mulmod.lo `test -f 'libtommath/bn_mp_mulmod.c' || echo '$(srcdir)/'`libtommath/bn_mp_mulmod.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_mulmod.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_mulmod.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_mulmod.c' object='libhcrypto_la-bn_mp_mulmod.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_mulmod.lo `test -f 'libtommath/bn_mp_mulmod.c' || echo '$(srcdir)/'`libtommath/bn_mp_mulmod.c
++
++libhcrypto_la-bn_mp_sqrmod.lo: libtommath/bn_mp_sqrmod.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_sqrmod.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_sqrmod.Tpo -c -o libhcrypto_la-bn_mp_sqrmod.lo `test -f 'libtommath/bn_mp_sqrmod.c' || echo '$(srcdir)/'`libtommath/bn_mp_sqrmod.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_sqrmod.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_sqrmod.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_sqrmod.c' object='libhcrypto_la-bn_mp_sqrmod.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_sqrmod.lo `test -f 'libtommath/bn_mp_sqrmod.c' || echo '$(srcdir)/'`libtommath/bn_mp_sqrmod.c
++
++libhcrypto_la-bn_mp_gcd.lo: libtommath/bn_mp_gcd.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_gcd.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_gcd.Tpo -c -o libhcrypto_la-bn_mp_gcd.lo `test -f 'libtommath/bn_mp_gcd.c' || echo '$(srcdir)/'`libtommath/bn_mp_gcd.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_gcd.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_gcd.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_gcd.c' object='libhcrypto_la-bn_mp_gcd.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_gcd.lo `test -f 'libtommath/bn_mp_gcd.c' || echo '$(srcdir)/'`libtommath/bn_mp_gcd.c
++
++libhcrypto_la-bn_mp_lcm.lo: libtommath/bn_mp_lcm.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_lcm.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_lcm.Tpo -c -o libhcrypto_la-bn_mp_lcm.lo `test -f 'libtommath/bn_mp_lcm.c' || echo '$(srcdir)/'`libtommath/bn_mp_lcm.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_lcm.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_lcm.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_lcm.c' object='libhcrypto_la-bn_mp_lcm.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_lcm.lo `test -f 'libtommath/bn_mp_lcm.c' || echo '$(srcdir)/'`libtommath/bn_mp_lcm.c
++
++libhcrypto_la-bn_fast_mp_invmod.lo: libtommath/bn_fast_mp_invmod.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_fast_mp_invmod.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_fast_mp_invmod.Tpo -c -o libhcrypto_la-bn_fast_mp_invmod.lo `test -f 'libtommath/bn_fast_mp_invmod.c' || echo '$(srcdir)/'`libtommath/bn_fast_mp_invmod.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_fast_mp_invmod.Tpo $(DEPDIR)/libhcrypto_la-bn_fast_mp_invmod.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_fast_mp_invmod.c' object='libhcrypto_la-bn_fast_mp_invmod.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_fast_mp_invmod.lo `test -f 'libtommath/bn_fast_mp_invmod.c' || echo '$(srcdir)/'`libtommath/bn_fast_mp_invmod.c
++
++libhcrypto_la-bn_mp_invmod.lo: libtommath/bn_mp_invmod.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_invmod.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_invmod.Tpo -c -o libhcrypto_la-bn_mp_invmod.lo `test -f 'libtommath/bn_mp_invmod.c' || echo '$(srcdir)/'`libtommath/bn_mp_invmod.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_invmod.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_invmod.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_invmod.c' object='libhcrypto_la-bn_mp_invmod.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_invmod.lo `test -f 'libtommath/bn_mp_invmod.c' || echo '$(srcdir)/'`libtommath/bn_mp_invmod.c
++
++libhcrypto_la-bn_mp_reduce.lo: libtommath/bn_mp_reduce.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_reduce.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_reduce.Tpo -c -o libhcrypto_la-bn_mp_reduce.lo `test -f 'libtommath/bn_mp_reduce.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_reduce.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_reduce.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_reduce.c' object='libhcrypto_la-bn_mp_reduce.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_reduce.lo `test -f 'libtommath/bn_mp_reduce.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce.c
++
++libhcrypto_la-bn_mp_montgomery_setup.lo: libtommath/bn_mp_montgomery_setup.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_montgomery_setup.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_montgomery_setup.Tpo -c -o libhcrypto_la-bn_mp_montgomery_setup.lo `test -f 'libtommath/bn_mp_montgomery_setup.c' || echo '$(srcdir)/'`libtommath/bn_mp_montgomery_setup.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_montgomery_setup.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_montgomery_setup.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_montgomery_setup.c' object='libhcrypto_la-bn_mp_montgomery_setup.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_montgomery_setup.lo `test -f 'libtommath/bn_mp_montgomery_setup.c' || echo '$(srcdir)/'`libtommath/bn_mp_montgomery_setup.c
++
++libhcrypto_la-bn_fast_mp_montgomery_reduce.lo: libtommath/bn_fast_mp_montgomery_reduce.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_fast_mp_montgomery_reduce.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_fast_mp_montgomery_reduce.Tpo -c -o libhcrypto_la-bn_fast_mp_montgomery_reduce.lo `test -f 'libtommath/bn_fast_mp_montgomery_reduce.c' || echo '$(srcdir)/'`libtommath/bn_fast_mp_montgomery_reduce.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_fast_mp_montgomery_reduce.Tpo $(DEPDIR)/libhcrypto_la-bn_fast_mp_montgomery_reduce.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_fast_mp_montgomery_reduce.c' object='libhcrypto_la-bn_fast_mp_montgomery_reduce.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_fast_mp_montgomery_reduce.lo `test -f 'libtommath/bn_fast_mp_montgomery_reduce.c' || echo '$(srcdir)/'`libtommath/bn_fast_mp_montgomery_reduce.c
++
++libhcrypto_la-bn_mp_montgomery_reduce.lo: libtommath/bn_mp_montgomery_reduce.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_montgomery_reduce.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_montgomery_reduce.Tpo -c -o libhcrypto_la-bn_mp_montgomery_reduce.lo `test -f 'libtommath/bn_mp_montgomery_reduce.c' || echo '$(srcdir)/'`libtommath/bn_mp_montgomery_reduce.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_montgomery_reduce.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_montgomery_reduce.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_montgomery_reduce.c' object='libhcrypto_la-bn_mp_montgomery_reduce.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_montgomery_reduce.lo `test -f 'libtommath/bn_mp_montgomery_reduce.c' || echo '$(srcdir)/'`libtommath/bn_mp_montgomery_reduce.c
++
++libhcrypto_la-bn_mp_exptmod_fast.lo: libtommath/bn_mp_exptmod_fast.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_exptmod_fast.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_exptmod_fast.Tpo -c -o libhcrypto_la-bn_mp_exptmod_fast.lo `test -f 'libtommath/bn_mp_exptmod_fast.c' || echo '$(srcdir)/'`libtommath/bn_mp_exptmod_fast.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_exptmod_fast.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_exptmod_fast.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_exptmod_fast.c' object='libhcrypto_la-bn_mp_exptmod_fast.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_exptmod_fast.lo `test -f 'libtommath/bn_mp_exptmod_fast.c' || echo '$(srcdir)/'`libtommath/bn_mp_exptmod_fast.c
++
++libhcrypto_la-bn_mp_exptmod.lo: libtommath/bn_mp_exptmod.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_exptmod.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_exptmod.Tpo -c -o libhcrypto_la-bn_mp_exptmod.lo `test -f 'libtommath/bn_mp_exptmod.c' || echo '$(srcdir)/'`libtommath/bn_mp_exptmod.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_exptmod.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_exptmod.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_exptmod.c' object='libhcrypto_la-bn_mp_exptmod.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_exptmod.lo `test -f 'libtommath/bn_mp_exptmod.c' || echo '$(srcdir)/'`libtommath/bn_mp_exptmod.c
++
++libhcrypto_la-bn_mp_2expt.lo: libtommath/bn_mp_2expt.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_2expt.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_2expt.Tpo -c -o libhcrypto_la-bn_mp_2expt.lo `test -f 'libtommath/bn_mp_2expt.c' || echo '$(srcdir)/'`libtommath/bn_mp_2expt.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_2expt.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_2expt.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_2expt.c' object='libhcrypto_la-bn_mp_2expt.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_2expt.lo `test -f 'libtommath/bn_mp_2expt.c' || echo '$(srcdir)/'`libtommath/bn_mp_2expt.c
++
++libhcrypto_la-bn_mp_n_root.lo: libtommath/bn_mp_n_root.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_n_root.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_n_root.Tpo -c -o libhcrypto_la-bn_mp_n_root.lo `test -f 'libtommath/bn_mp_n_root.c' || echo '$(srcdir)/'`libtommath/bn_mp_n_root.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_n_root.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_n_root.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_n_root.c' object='libhcrypto_la-bn_mp_n_root.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_n_root.lo `test -f 'libtommath/bn_mp_n_root.c' || echo '$(srcdir)/'`libtommath/bn_mp_n_root.c
++
++libhcrypto_la-bn_mp_jacobi.lo: libtommath/bn_mp_jacobi.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_jacobi.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_jacobi.Tpo -c -o libhcrypto_la-bn_mp_jacobi.lo `test -f 'libtommath/bn_mp_jacobi.c' || echo '$(srcdir)/'`libtommath/bn_mp_jacobi.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_jacobi.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_jacobi.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_jacobi.c' object='libhcrypto_la-bn_mp_jacobi.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_jacobi.lo `test -f 'libtommath/bn_mp_jacobi.c' || echo '$(srcdir)/'`libtommath/bn_mp_jacobi.c
++
++libhcrypto_la-bn_reverse.lo: libtommath/bn_reverse.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_reverse.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_reverse.Tpo -c -o libhcrypto_la-bn_reverse.lo `test -f 'libtommath/bn_reverse.c' || echo '$(srcdir)/'`libtommath/bn_reverse.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_reverse.Tpo $(DEPDIR)/libhcrypto_la-bn_reverse.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_reverse.c' object='libhcrypto_la-bn_reverse.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_reverse.lo `test -f 'libtommath/bn_reverse.c' || echo '$(srcdir)/'`libtommath/bn_reverse.c
++
++libhcrypto_la-bn_mp_count_bits.lo: libtommath/bn_mp_count_bits.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_count_bits.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_count_bits.Tpo -c -o libhcrypto_la-bn_mp_count_bits.lo `test -f 'libtommath/bn_mp_count_bits.c' || echo '$(srcdir)/'`libtommath/bn_mp_count_bits.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_count_bits.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_count_bits.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_count_bits.c' object='libhcrypto_la-bn_mp_count_bits.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_count_bits.lo `test -f 'libtommath/bn_mp_count_bits.c' || echo '$(srcdir)/'`libtommath/bn_mp_count_bits.c
++
++libhcrypto_la-bn_mp_read_unsigned_bin.lo: libtommath/bn_mp_read_unsigned_bin.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_read_unsigned_bin.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_read_unsigned_bin.Tpo -c -o libhcrypto_la-bn_mp_read_unsigned_bin.lo `test -f 'libtommath/bn_mp_read_unsigned_bin.c' || echo '$(srcdir)/'`libtommath/bn_mp_read_unsigned_bin.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_read_unsigned_bin.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_read_unsigned_bin.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_read_unsigned_bin.c' object='libhcrypto_la-bn_mp_read_unsigned_bin.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_read_unsigned_bin.lo `test -f 'libtommath/bn_mp_read_unsigned_bin.c' || echo '$(srcdir)/'`libtommath/bn_mp_read_unsigned_bin.c
++
++libhcrypto_la-bn_mp_read_signed_bin.lo: libtommath/bn_mp_read_signed_bin.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_read_signed_bin.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_read_signed_bin.Tpo -c -o libhcrypto_la-bn_mp_read_signed_bin.lo `test -f 'libtommath/bn_mp_read_signed_bin.c' || echo '$(srcdir)/'`libtommath/bn_mp_read_signed_bin.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_read_signed_bin.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_read_signed_bin.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_read_signed_bin.c' object='libhcrypto_la-bn_mp_read_signed_bin.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_read_signed_bin.lo `test -f 'libtommath/bn_mp_read_signed_bin.c' || echo '$(srcdir)/'`libtommath/bn_mp_read_signed_bin.c
++
++libhcrypto_la-bn_mp_to_unsigned_bin.lo: libtommath/bn_mp_to_unsigned_bin.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_to_unsigned_bin.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_to_unsigned_bin.Tpo -c -o libhcrypto_la-bn_mp_to_unsigned_bin.lo `test -f 'libtommath/bn_mp_to_unsigned_bin.c' || echo '$(srcdir)/'`libtommath/bn_mp_to_unsigned_bin.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_to_unsigned_bin.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_to_unsigned_bin.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_to_unsigned_bin.c' object='libhcrypto_la-bn_mp_to_unsigned_bin.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_to_unsigned_bin.lo `test -f 'libtommath/bn_mp_to_unsigned_bin.c' || echo '$(srcdir)/'`libtommath/bn_mp_to_unsigned_bin.c
++
++libhcrypto_la-bn_mp_to_signed_bin.lo: libtommath/bn_mp_to_signed_bin.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_to_signed_bin.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_to_signed_bin.Tpo -c -o libhcrypto_la-bn_mp_to_signed_bin.lo `test -f 'libtommath/bn_mp_to_signed_bin.c' || echo '$(srcdir)/'`libtommath/bn_mp_to_signed_bin.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_to_signed_bin.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_to_signed_bin.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_to_signed_bin.c' object='libhcrypto_la-bn_mp_to_signed_bin.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_to_signed_bin.lo `test -f 'libtommath/bn_mp_to_signed_bin.c' || echo '$(srcdir)/'`libtommath/bn_mp_to_signed_bin.c
++
++libhcrypto_la-bn_mp_unsigned_bin_size.lo: libtommath/bn_mp_unsigned_bin_size.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_unsigned_bin_size.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_unsigned_bin_size.Tpo -c -o libhcrypto_la-bn_mp_unsigned_bin_size.lo `test -f 'libtommath/bn_mp_unsigned_bin_size.c' || echo '$(srcdir)/'`libtommath/bn_mp_unsigned_bin_size.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_unsigned_bin_size.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_unsigned_bin_size.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_unsigned_bin_size.c' object='libhcrypto_la-bn_mp_unsigned_bin_size.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_unsigned_bin_size.lo `test -f 'libtommath/bn_mp_unsigned_bin_size.c' || echo '$(srcdir)/'`libtommath/bn_mp_unsigned_bin_size.c
++
++libhcrypto_la-bn_mp_signed_bin_size.lo: libtommath/bn_mp_signed_bin_size.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_signed_bin_size.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_signed_bin_size.Tpo -c -o libhcrypto_la-bn_mp_signed_bin_size.lo `test -f 'libtommath/bn_mp_signed_bin_size.c' || echo '$(srcdir)/'`libtommath/bn_mp_signed_bin_size.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_signed_bin_size.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_signed_bin_size.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_signed_bin_size.c' object='libhcrypto_la-bn_mp_signed_bin_size.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_signed_bin_size.lo `test -f 'libtommath/bn_mp_signed_bin_size.c' || echo '$(srcdir)/'`libtommath/bn_mp_signed_bin_size.c
++
++libhcrypto_la-bn_mp_xor.lo: libtommath/bn_mp_xor.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_xor.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_xor.Tpo -c -o libhcrypto_la-bn_mp_xor.lo `test -f 'libtommath/bn_mp_xor.c' || echo '$(srcdir)/'`libtommath/bn_mp_xor.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_xor.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_xor.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_xor.c' object='libhcrypto_la-bn_mp_xor.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_xor.lo `test -f 'libtommath/bn_mp_xor.c' || echo '$(srcdir)/'`libtommath/bn_mp_xor.c
++
++libhcrypto_la-bn_mp_and.lo: libtommath/bn_mp_and.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_and.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_and.Tpo -c -o libhcrypto_la-bn_mp_and.lo `test -f 'libtommath/bn_mp_and.c' || echo '$(srcdir)/'`libtommath/bn_mp_and.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_and.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_and.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_and.c' object='libhcrypto_la-bn_mp_and.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_and.lo `test -f 'libtommath/bn_mp_and.c' || echo '$(srcdir)/'`libtommath/bn_mp_and.c
++
++libhcrypto_la-bn_mp_or.lo: libtommath/bn_mp_or.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_or.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_or.Tpo -c -o libhcrypto_la-bn_mp_or.lo `test -f 'libtommath/bn_mp_or.c' || echo '$(srcdir)/'`libtommath/bn_mp_or.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_or.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_or.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_or.c' object='libhcrypto_la-bn_mp_or.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_or.lo `test -f 'libtommath/bn_mp_or.c' || echo '$(srcdir)/'`libtommath/bn_mp_or.c
++
++libhcrypto_la-bn_mp_rand.lo: libtommath/bn_mp_rand.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_rand.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_rand.Tpo -c -o libhcrypto_la-bn_mp_rand.lo `test -f 'libtommath/bn_mp_rand.c' || echo '$(srcdir)/'`libtommath/bn_mp_rand.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_rand.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_rand.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_rand.c' object='libhcrypto_la-bn_mp_rand.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_rand.lo `test -f 'libtommath/bn_mp_rand.c' || echo '$(srcdir)/'`libtommath/bn_mp_rand.c
++
++libhcrypto_la-bn_mp_montgomery_calc_normalization.lo: libtommath/bn_mp_montgomery_calc_normalization.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_montgomery_calc_normalization.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_montgomery_calc_normalization.Tpo -c -o libhcrypto_la-bn_mp_montgomery_calc_normalization.lo `test -f 'libtommath/bn_mp_montgomery_calc_normalization.c' || echo '$(srcdir)/'`libtommath/bn_mp_montgomery_calc_normalization.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_montgomery_calc_normalization.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_montgomery_calc_normalization.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_montgomery_calc_normalization.c' object='libhcrypto_la-bn_mp_montgomery_calc_normalization.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_montgomery_calc_normalization.lo `test -f 'libtommath/bn_mp_montgomery_calc_normalization.c' || echo '$(srcdir)/'`libtommath/bn_mp_montgomery_calc_normalization.c
++
++libhcrypto_la-bn_mp_prime_is_divisible.lo: libtommath/bn_mp_prime_is_divisible.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_prime_is_divisible.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_prime_is_divisible.Tpo -c -o libhcrypto_la-bn_mp_prime_is_divisible.lo `test -f 'libtommath/bn_mp_prime_is_divisible.c' || echo '$(srcdir)/'`libtommath/bn_mp_prime_is_divisible.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_prime_is_divisible.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_prime_is_divisible.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_prime_is_divisible.c' object='libhcrypto_la-bn_mp_prime_is_divisible.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_prime_is_divisible.lo `test -f 'libtommath/bn_mp_prime_is_divisible.c' || echo '$(srcdir)/'`libtommath/bn_mp_prime_is_divisible.c
++
++libhcrypto_la-bn_prime_tab.lo: libtommath/bn_prime_tab.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_prime_tab.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_prime_tab.Tpo -c -o libhcrypto_la-bn_prime_tab.lo `test -f 'libtommath/bn_prime_tab.c' || echo '$(srcdir)/'`libtommath/bn_prime_tab.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_prime_tab.Tpo $(DEPDIR)/libhcrypto_la-bn_prime_tab.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_prime_tab.c' object='libhcrypto_la-bn_prime_tab.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_prime_tab.lo `test -f 'libtommath/bn_prime_tab.c' || echo '$(srcdir)/'`libtommath/bn_prime_tab.c
++
++libhcrypto_la-bn_mp_prime_fermat.lo: libtommath/bn_mp_prime_fermat.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_prime_fermat.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_prime_fermat.Tpo -c -o libhcrypto_la-bn_mp_prime_fermat.lo `test -f 'libtommath/bn_mp_prime_fermat.c' || echo '$(srcdir)/'`libtommath/bn_mp_prime_fermat.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_prime_fermat.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_prime_fermat.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_prime_fermat.c' object='libhcrypto_la-bn_mp_prime_fermat.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_prime_fermat.lo `test -f 'libtommath/bn_mp_prime_fermat.c' || echo '$(srcdir)/'`libtommath/bn_mp_prime_fermat.c
++
++libhcrypto_la-bn_mp_prime_miller_rabin.lo: libtommath/bn_mp_prime_miller_rabin.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_prime_miller_rabin.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_prime_miller_rabin.Tpo -c -o libhcrypto_la-bn_mp_prime_miller_rabin.lo `test -f 'libtommath/bn_mp_prime_miller_rabin.c' || echo '$(srcdir)/'`libtommath/bn_mp_prime_miller_rabin.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_prime_miller_rabin.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_prime_miller_rabin.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_prime_miller_rabin.c' object='libhcrypto_la-bn_mp_prime_miller_rabin.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_prime_miller_rabin.lo `test -f 'libtommath/bn_mp_prime_miller_rabin.c' || echo '$(srcdir)/'`libtommath/bn_mp_prime_miller_rabin.c
++
++libhcrypto_la-bn_mp_prime_is_prime.lo: libtommath/bn_mp_prime_is_prime.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_prime_is_prime.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_prime_is_prime.Tpo -c -o libhcrypto_la-bn_mp_prime_is_prime.lo `test -f 'libtommath/bn_mp_prime_is_prime.c' || echo '$(srcdir)/'`libtommath/bn_mp_prime_is_prime.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_prime_is_prime.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_prime_is_prime.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_prime_is_prime.c' object='libhcrypto_la-bn_mp_prime_is_prime.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_prime_is_prime.lo `test -f 'libtommath/bn_mp_prime_is_prime.c' || echo '$(srcdir)/'`libtommath/bn_mp_prime_is_prime.c
++
++libhcrypto_la-bn_mp_prime_next_prime.lo: libtommath/bn_mp_prime_next_prime.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_prime_next_prime.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_prime_next_prime.Tpo -c -o libhcrypto_la-bn_mp_prime_next_prime.lo `test -f 'libtommath/bn_mp_prime_next_prime.c' || echo '$(srcdir)/'`libtommath/bn_mp_prime_next_prime.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_prime_next_prime.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_prime_next_prime.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_prime_next_prime.c' object='libhcrypto_la-bn_mp_prime_next_prime.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_prime_next_prime.lo `test -f 'libtommath/bn_mp_prime_next_prime.c' || echo '$(srcdir)/'`libtommath/bn_mp_prime_next_prime.c
++
++libhcrypto_la-bn_mp_find_prime.lo: libtommath/bn_mp_find_prime.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_find_prime.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_find_prime.Tpo -c -o libhcrypto_la-bn_mp_find_prime.lo `test -f 'libtommath/bn_mp_find_prime.c' || echo '$(srcdir)/'`libtommath/bn_mp_find_prime.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_find_prime.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_find_prime.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_find_prime.c' object='libhcrypto_la-bn_mp_find_prime.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_find_prime.lo `test -f 'libtommath/bn_mp_find_prime.c' || echo '$(srcdir)/'`libtommath/bn_mp_find_prime.c
++
++libhcrypto_la-bn_mp_isprime.lo: libtommath/bn_mp_isprime.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_isprime.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_isprime.Tpo -c -o libhcrypto_la-bn_mp_isprime.lo `test -f 'libtommath/bn_mp_isprime.c' || echo '$(srcdir)/'`libtommath/bn_mp_isprime.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_isprime.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_isprime.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_isprime.c' object='libhcrypto_la-bn_mp_isprime.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_isprime.lo `test -f 'libtommath/bn_mp_isprime.c' || echo '$(srcdir)/'`libtommath/bn_mp_isprime.c
++
++libhcrypto_la-bn_mp_dr_reduce.lo: libtommath/bn_mp_dr_reduce.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_dr_reduce.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_dr_reduce.Tpo -c -o libhcrypto_la-bn_mp_dr_reduce.lo `test -f 'libtommath/bn_mp_dr_reduce.c' || echo '$(srcdir)/'`libtommath/bn_mp_dr_reduce.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_dr_reduce.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_dr_reduce.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_dr_reduce.c' object='libhcrypto_la-bn_mp_dr_reduce.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_dr_reduce.lo `test -f 'libtommath/bn_mp_dr_reduce.c' || echo '$(srcdir)/'`libtommath/bn_mp_dr_reduce.c
++
++libhcrypto_la-bn_mp_dr_is_modulus.lo: libtommath/bn_mp_dr_is_modulus.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_dr_is_modulus.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_dr_is_modulus.Tpo -c -o libhcrypto_la-bn_mp_dr_is_modulus.lo `test -f 'libtommath/bn_mp_dr_is_modulus.c' || echo '$(srcdir)/'`libtommath/bn_mp_dr_is_modulus.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_dr_is_modulus.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_dr_is_modulus.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_dr_is_modulus.c' object='libhcrypto_la-bn_mp_dr_is_modulus.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_dr_is_modulus.lo `test -f 'libtommath/bn_mp_dr_is_modulus.c' || echo '$(srcdir)/'`libtommath/bn_mp_dr_is_modulus.c
++
++libhcrypto_la-bn_mp_dr_setup.lo: libtommath/bn_mp_dr_setup.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_dr_setup.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_dr_setup.Tpo -c -o libhcrypto_la-bn_mp_dr_setup.lo `test -f 'libtommath/bn_mp_dr_setup.c' || echo '$(srcdir)/'`libtommath/bn_mp_dr_setup.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_dr_setup.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_dr_setup.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_dr_setup.c' object='libhcrypto_la-bn_mp_dr_setup.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_dr_setup.lo `test -f 'libtommath/bn_mp_dr_setup.c' || echo '$(srcdir)/'`libtommath/bn_mp_dr_setup.c
++
++libhcrypto_la-bn_mp_reduce_setup.lo: libtommath/bn_mp_reduce_setup.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_reduce_setup.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_reduce_setup.Tpo -c -o libhcrypto_la-bn_mp_reduce_setup.lo `test -f 'libtommath/bn_mp_reduce_setup.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce_setup.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_reduce_setup.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_reduce_setup.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_reduce_setup.c' object='libhcrypto_la-bn_mp_reduce_setup.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_reduce_setup.lo `test -f 'libtommath/bn_mp_reduce_setup.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce_setup.c
++
++libhcrypto_la-bn_mp_toom_mul.lo: libtommath/bn_mp_toom_mul.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_toom_mul.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_toom_mul.Tpo -c -o libhcrypto_la-bn_mp_toom_mul.lo `test -f 'libtommath/bn_mp_toom_mul.c' || echo '$(srcdir)/'`libtommath/bn_mp_toom_mul.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_toom_mul.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_toom_mul.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_toom_mul.c' object='libhcrypto_la-bn_mp_toom_mul.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_toom_mul.lo `test -f 'libtommath/bn_mp_toom_mul.c' || echo '$(srcdir)/'`libtommath/bn_mp_toom_mul.c
++
++libhcrypto_la-bn_mp_toom_sqr.lo: libtommath/bn_mp_toom_sqr.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_toom_sqr.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_toom_sqr.Tpo -c -o libhcrypto_la-bn_mp_toom_sqr.lo `test -f 'libtommath/bn_mp_toom_sqr.c' || echo '$(srcdir)/'`libtommath/bn_mp_toom_sqr.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_toom_sqr.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_toom_sqr.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_toom_sqr.c' object='libhcrypto_la-bn_mp_toom_sqr.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_toom_sqr.lo `test -f 'libtommath/bn_mp_toom_sqr.c' || echo '$(srcdir)/'`libtommath/bn_mp_toom_sqr.c
++
++libhcrypto_la-bn_mp_div_3.lo: libtommath/bn_mp_div_3.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_div_3.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_div_3.Tpo -c -o libhcrypto_la-bn_mp_div_3.lo `test -f 'libtommath/bn_mp_div_3.c' || echo '$(srcdir)/'`libtommath/bn_mp_div_3.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_div_3.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_div_3.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_div_3.c' object='libhcrypto_la-bn_mp_div_3.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_div_3.lo `test -f 'libtommath/bn_mp_div_3.c' || echo '$(srcdir)/'`libtommath/bn_mp_div_3.c
++
++libhcrypto_la-bn_s_mp_exptmod.lo: libtommath/bn_s_mp_exptmod.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_s_mp_exptmod.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_s_mp_exptmod.Tpo -c -o libhcrypto_la-bn_s_mp_exptmod.lo `test -f 'libtommath/bn_s_mp_exptmod.c' || echo '$(srcdir)/'`libtommath/bn_s_mp_exptmod.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_s_mp_exptmod.Tpo $(DEPDIR)/libhcrypto_la-bn_s_mp_exptmod.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_s_mp_exptmod.c' object='libhcrypto_la-bn_s_mp_exptmod.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_s_mp_exptmod.lo `test -f 'libtommath/bn_s_mp_exptmod.c' || echo '$(srcdir)/'`libtommath/bn_s_mp_exptmod.c
++
++libhcrypto_la-bn_mp_reduce_2k.lo: libtommath/bn_mp_reduce_2k.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_reduce_2k.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k.Tpo -c -o libhcrypto_la-bn_mp_reduce_2k.lo `test -f 'libtommath/bn_mp_reduce_2k.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce_2k.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_reduce_2k.c' object='libhcrypto_la-bn_mp_reduce_2k.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_reduce_2k.lo `test -f 'libtommath/bn_mp_reduce_2k.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce_2k.c
++
++libhcrypto_la-bn_mp_reduce_is_2k.lo: libtommath/bn_mp_reduce_is_2k.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_reduce_is_2k.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_reduce_is_2k.Tpo -c -o libhcrypto_la-bn_mp_reduce_is_2k.lo `test -f 'libtommath/bn_mp_reduce_is_2k.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce_is_2k.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_reduce_is_2k.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_reduce_is_2k.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_reduce_is_2k.c' object='libhcrypto_la-bn_mp_reduce_is_2k.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_reduce_is_2k.lo `test -f 'libtommath/bn_mp_reduce_is_2k.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce_is_2k.c
++
++libhcrypto_la-bn_mp_reduce_2k_setup.lo: libtommath/bn_mp_reduce_2k_setup.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_reduce_2k_setup.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k_setup.Tpo -c -o libhcrypto_la-bn_mp_reduce_2k_setup.lo `test -f 'libtommath/bn_mp_reduce_2k_setup.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce_2k_setup.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k_setup.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k_setup.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_reduce_2k_setup.c' object='libhcrypto_la-bn_mp_reduce_2k_setup.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_reduce_2k_setup.lo `test -f 'libtommath/bn_mp_reduce_2k_setup.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce_2k_setup.c
++
++libhcrypto_la-bn_mp_reduce_2k_l.lo: libtommath/bn_mp_reduce_2k_l.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_reduce_2k_l.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k_l.Tpo -c -o libhcrypto_la-bn_mp_reduce_2k_l.lo `test -f 'libtommath/bn_mp_reduce_2k_l.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce_2k_l.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k_l.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k_l.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_reduce_2k_l.c' object='libhcrypto_la-bn_mp_reduce_2k_l.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_reduce_2k_l.lo `test -f 'libtommath/bn_mp_reduce_2k_l.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce_2k_l.c
++
++libhcrypto_la-bn_mp_reduce_is_2k_l.lo: libtommath/bn_mp_reduce_is_2k_l.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_reduce_is_2k_l.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_reduce_is_2k_l.Tpo -c -o libhcrypto_la-bn_mp_reduce_is_2k_l.lo `test -f 'libtommath/bn_mp_reduce_is_2k_l.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce_is_2k_l.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_reduce_is_2k_l.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_reduce_is_2k_l.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_reduce_is_2k_l.c' object='libhcrypto_la-bn_mp_reduce_is_2k_l.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_reduce_is_2k_l.lo `test -f 'libtommath/bn_mp_reduce_is_2k_l.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce_is_2k_l.c
++
++libhcrypto_la-bn_mp_reduce_2k_setup_l.lo: libtommath/bn_mp_reduce_2k_setup_l.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_reduce_2k_setup_l.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k_setup_l.Tpo -c -o libhcrypto_la-bn_mp_reduce_2k_setup_l.lo `test -f 'libtommath/bn_mp_reduce_2k_setup_l.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce_2k_setup_l.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k_setup_l.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_reduce_2k_setup_l.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_reduce_2k_setup_l.c' object='libhcrypto_la-bn_mp_reduce_2k_setup_l.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_reduce_2k_setup_l.lo `test -f 'libtommath/bn_mp_reduce_2k_setup_l.c' || echo '$(srcdir)/'`libtommath/bn_mp_reduce_2k_setup_l.c
++
++libhcrypto_la-bn_mp_radix_smap.lo: libtommath/bn_mp_radix_smap.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_radix_smap.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_radix_smap.Tpo -c -o libhcrypto_la-bn_mp_radix_smap.lo `test -f 'libtommath/bn_mp_radix_smap.c' || echo '$(srcdir)/'`libtommath/bn_mp_radix_smap.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_radix_smap.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_radix_smap.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_radix_smap.c' object='libhcrypto_la-bn_mp_radix_smap.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_radix_smap.lo `test -f 'libtommath/bn_mp_radix_smap.c' || echo '$(srcdir)/'`libtommath/bn_mp_radix_smap.c
++
++libhcrypto_la-bn_mp_read_radix.lo: libtommath/bn_mp_read_radix.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_read_radix.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_read_radix.Tpo -c -o libhcrypto_la-bn_mp_read_radix.lo `test -f 'libtommath/bn_mp_read_radix.c' || echo '$(srcdir)/'`libtommath/bn_mp_read_radix.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_read_radix.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_read_radix.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_read_radix.c' object='libhcrypto_la-bn_mp_read_radix.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_read_radix.lo `test -f 'libtommath/bn_mp_read_radix.c' || echo '$(srcdir)/'`libtommath/bn_mp_read_radix.c
++
++libhcrypto_la-bn_mp_toradix.lo: libtommath/bn_mp_toradix.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_toradix.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_toradix.Tpo -c -o libhcrypto_la-bn_mp_toradix.lo `test -f 'libtommath/bn_mp_toradix.c' || echo '$(srcdir)/'`libtommath/bn_mp_toradix.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_toradix.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_toradix.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_toradix.c' object='libhcrypto_la-bn_mp_toradix.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_toradix.lo `test -f 'libtommath/bn_mp_toradix.c' || echo '$(srcdir)/'`libtommath/bn_mp_toradix.c
++
++libhcrypto_la-bn_mp_radix_size.lo: libtommath/bn_mp_radix_size.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_radix_size.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_radix_size.Tpo -c -o libhcrypto_la-bn_mp_radix_size.lo `test -f 'libtommath/bn_mp_radix_size.c' || echo '$(srcdir)/'`libtommath/bn_mp_radix_size.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_radix_size.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_radix_size.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_radix_size.c' object='libhcrypto_la-bn_mp_radix_size.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_radix_size.lo `test -f 'libtommath/bn_mp_radix_size.c' || echo '$(srcdir)/'`libtommath/bn_mp_radix_size.c
++
++libhcrypto_la-bn_mp_fread.lo: libtommath/bn_mp_fread.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_fread.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_fread.Tpo -c -o libhcrypto_la-bn_mp_fread.lo `test -f 'libtommath/bn_mp_fread.c' || echo '$(srcdir)/'`libtommath/bn_mp_fread.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_fread.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_fread.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_fread.c' object='libhcrypto_la-bn_mp_fread.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_fread.lo `test -f 'libtommath/bn_mp_fread.c' || echo '$(srcdir)/'`libtommath/bn_mp_fread.c
++
++libhcrypto_la-bn_mp_fwrite.lo: libtommath/bn_mp_fwrite.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_fwrite.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_fwrite.Tpo -c -o libhcrypto_la-bn_mp_fwrite.lo `test -f 'libtommath/bn_mp_fwrite.c' || echo '$(srcdir)/'`libtommath/bn_mp_fwrite.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_fwrite.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_fwrite.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_fwrite.c' object='libhcrypto_la-bn_mp_fwrite.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_fwrite.lo `test -f 'libtommath/bn_mp_fwrite.c' || echo '$(srcdir)/'`libtommath/bn_mp_fwrite.c
++
++libhcrypto_la-bn_mp_cnt_lsb.lo: libtommath/bn_mp_cnt_lsb.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_cnt_lsb.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_cnt_lsb.Tpo -c -o libhcrypto_la-bn_mp_cnt_lsb.lo `test -f 'libtommath/bn_mp_cnt_lsb.c' || echo '$(srcdir)/'`libtommath/bn_mp_cnt_lsb.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_cnt_lsb.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_cnt_lsb.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_cnt_lsb.c' object='libhcrypto_la-bn_mp_cnt_lsb.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_cnt_lsb.lo `test -f 'libtommath/bn_mp_cnt_lsb.c' || echo '$(srcdir)/'`libtommath/bn_mp_cnt_lsb.c
++
++libhcrypto_la-bn_error.lo: libtommath/bn_error.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_error.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_error.Tpo -c -o libhcrypto_la-bn_error.lo `test -f 'libtommath/bn_error.c' || echo '$(srcdir)/'`libtommath/bn_error.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_error.Tpo $(DEPDIR)/libhcrypto_la-bn_error.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_error.c' object='libhcrypto_la-bn_error.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_error.lo `test -f 'libtommath/bn_error.c' || echo '$(srcdir)/'`libtommath/bn_error.c
++
++libhcrypto_la-bn_mp_init_multi.lo: libtommath/bn_mp_init_multi.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_init_multi.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_init_multi.Tpo -c -o libhcrypto_la-bn_mp_init_multi.lo `test -f 'libtommath/bn_mp_init_multi.c' || echo '$(srcdir)/'`libtommath/bn_mp_init_multi.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_init_multi.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_init_multi.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_init_multi.c' object='libhcrypto_la-bn_mp_init_multi.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_init_multi.lo `test -f 'libtommath/bn_mp_init_multi.c' || echo '$(srcdir)/'`libtommath/bn_mp_init_multi.c
++
++libhcrypto_la-bn_mp_clear_multi.lo: libtommath/bn_mp_clear_multi.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_clear_multi.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_clear_multi.Tpo -c -o libhcrypto_la-bn_mp_clear_multi.lo `test -f 'libtommath/bn_mp_clear_multi.c' || echo '$(srcdir)/'`libtommath/bn_mp_clear_multi.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_clear_multi.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_clear_multi.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_clear_multi.c' object='libhcrypto_la-bn_mp_clear_multi.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_clear_multi.lo `test -f 'libtommath/bn_mp_clear_multi.c' || echo '$(srcdir)/'`libtommath/bn_mp_clear_multi.c
++
++libhcrypto_la-bn_mp_exteuclid.lo: libtommath/bn_mp_exteuclid.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_exteuclid.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_exteuclid.Tpo -c -o libhcrypto_la-bn_mp_exteuclid.lo `test -f 'libtommath/bn_mp_exteuclid.c' || echo '$(srcdir)/'`libtommath/bn_mp_exteuclid.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_exteuclid.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_exteuclid.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_exteuclid.c' object='libhcrypto_la-bn_mp_exteuclid.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_exteuclid.lo `test -f 'libtommath/bn_mp_exteuclid.c' || echo '$(srcdir)/'`libtommath/bn_mp_exteuclid.c
++
++libhcrypto_la-bn_mp_toradix_n.lo: libtommath/bn_mp_toradix_n.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_toradix_n.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_toradix_n.Tpo -c -o libhcrypto_la-bn_mp_toradix_n.lo `test -f 'libtommath/bn_mp_toradix_n.c' || echo '$(srcdir)/'`libtommath/bn_mp_toradix_n.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_toradix_n.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_toradix_n.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_toradix_n.c' object='libhcrypto_la-bn_mp_toradix_n.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_toradix_n.lo `test -f 'libtommath/bn_mp_toradix_n.c' || echo '$(srcdir)/'`libtommath/bn_mp_toradix_n.c
++
++libhcrypto_la-bn_mp_prime_random_ex.lo: libtommath/bn_mp_prime_random_ex.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_prime_random_ex.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_prime_random_ex.Tpo -c -o libhcrypto_la-bn_mp_prime_random_ex.lo `test -f 'libtommath/bn_mp_prime_random_ex.c' || echo '$(srcdir)/'`libtommath/bn_mp_prime_random_ex.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_prime_random_ex.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_prime_random_ex.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_prime_random_ex.c' object='libhcrypto_la-bn_mp_prime_random_ex.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_prime_random_ex.lo `test -f 'libtommath/bn_mp_prime_random_ex.c' || echo '$(srcdir)/'`libtommath/bn_mp_prime_random_ex.c
++
++libhcrypto_la-bn_mp_get_int.lo: libtommath/bn_mp_get_int.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_get_int.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_get_int.Tpo -c -o libhcrypto_la-bn_mp_get_int.lo `test -f 'libtommath/bn_mp_get_int.c' || echo '$(srcdir)/'`libtommath/bn_mp_get_int.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_get_int.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_get_int.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_get_int.c' object='libhcrypto_la-bn_mp_get_int.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_get_int.lo `test -f 'libtommath/bn_mp_get_int.c' || echo '$(srcdir)/'`libtommath/bn_mp_get_int.c
++
++libhcrypto_la-bn_mp_sqrt.lo: libtommath/bn_mp_sqrt.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_sqrt.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_sqrt.Tpo -c -o libhcrypto_la-bn_mp_sqrt.lo `test -f 'libtommath/bn_mp_sqrt.c' || echo '$(srcdir)/'`libtommath/bn_mp_sqrt.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_sqrt.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_sqrt.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_sqrt.c' object='libhcrypto_la-bn_mp_sqrt.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_sqrt.lo `test -f 'libtommath/bn_mp_sqrt.c' || echo '$(srcdir)/'`libtommath/bn_mp_sqrt.c
++
++libhcrypto_la-bn_mp_is_square.lo: libtommath/bn_mp_is_square.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_is_square.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_is_square.Tpo -c -o libhcrypto_la-bn_mp_is_square.lo `test -f 'libtommath/bn_mp_is_square.c' || echo '$(srcdir)/'`libtommath/bn_mp_is_square.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_is_square.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_is_square.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_is_square.c' object='libhcrypto_la-bn_mp_is_square.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_is_square.lo `test -f 'libtommath/bn_mp_is_square.c' || echo '$(srcdir)/'`libtommath/bn_mp_is_square.c
++
++libhcrypto_la-bn_mp_init_set.lo: libtommath/bn_mp_init_set.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_init_set.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_init_set.Tpo -c -o libhcrypto_la-bn_mp_init_set.lo `test -f 'libtommath/bn_mp_init_set.c' || echo '$(srcdir)/'`libtommath/bn_mp_init_set.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_init_set.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_init_set.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_init_set.c' object='libhcrypto_la-bn_mp_init_set.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_init_set.lo `test -f 'libtommath/bn_mp_init_set.c' || echo '$(srcdir)/'`libtommath/bn_mp_init_set.c
++
++libhcrypto_la-bn_mp_init_set_int.lo: libtommath/bn_mp_init_set_int.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_init_set_int.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_init_set_int.Tpo -c -o libhcrypto_la-bn_mp_init_set_int.lo `test -f 'libtommath/bn_mp_init_set_int.c' || echo '$(srcdir)/'`libtommath/bn_mp_init_set_int.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_init_set_int.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_init_set_int.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_init_set_int.c' object='libhcrypto_la-bn_mp_init_set_int.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_init_set_int.lo `test -f 'libtommath/bn_mp_init_set_int.c' || echo '$(srcdir)/'`libtommath/bn_mp_init_set_int.c
++
++libhcrypto_la-bn_mp_invmod_slow.lo: libtommath/bn_mp_invmod_slow.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_invmod_slow.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_invmod_slow.Tpo -c -o libhcrypto_la-bn_mp_invmod_slow.lo `test -f 'libtommath/bn_mp_invmod_slow.c' || echo '$(srcdir)/'`libtommath/bn_mp_invmod_slow.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_invmod_slow.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_invmod_slow.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_invmod_slow.c' object='libhcrypto_la-bn_mp_invmod_slow.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_invmod_slow.lo `test -f 'libtommath/bn_mp_invmod_slow.c' || echo '$(srcdir)/'`libtommath/bn_mp_invmod_slow.c
++
++libhcrypto_la-bn_mp_prime_rabin_miller_trials.lo: libtommath/bn_mp_prime_rabin_miller_trials.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_prime_rabin_miller_trials.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_prime_rabin_miller_trials.Tpo -c -o libhcrypto_la-bn_mp_prime_rabin_miller_trials.lo `test -f 'libtommath/bn_mp_prime_rabin_miller_trials.c' || echo '$(srcdir)/'`libtommath/bn_mp_prime_rabin_miller_trials.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_prime_rabin_miller_trials.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_prime_rabin_miller_trials.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_prime_rabin_miller_trials.c' object='libhcrypto_la-bn_mp_prime_rabin_miller_trials.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_prime_rabin_miller_trials.lo `test -f 'libtommath/bn_mp_prime_rabin_miller_trials.c' || echo '$(srcdir)/'`libtommath/bn_mp_prime_rabin_miller_trials.c
++
++libhcrypto_la-bn_mp_to_signed_bin_n.lo: libtommath/bn_mp_to_signed_bin_n.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_to_signed_bin_n.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_to_signed_bin_n.Tpo -c -o libhcrypto_la-bn_mp_to_signed_bin_n.lo `test -f 'libtommath/bn_mp_to_signed_bin_n.c' || echo '$(srcdir)/'`libtommath/bn_mp_to_signed_bin_n.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_to_signed_bin_n.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_to_signed_bin_n.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_to_signed_bin_n.c' object='libhcrypto_la-bn_mp_to_signed_bin_n.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_to_signed_bin_n.lo `test -f 'libtommath/bn_mp_to_signed_bin_n.c' || echo '$(srcdir)/'`libtommath/bn_mp_to_signed_bin_n.c
++
++libhcrypto_la-bn_mp_to_unsigned_bin_n.lo: libtommath/bn_mp_to_unsigned_bin_n.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn_mp_to_unsigned_bin_n.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn_mp_to_unsigned_bin_n.Tpo -c -o libhcrypto_la-bn_mp_to_unsigned_bin_n.lo `test -f 'libtommath/bn_mp_to_unsigned_bin_n.c' || echo '$(srcdir)/'`libtommath/bn_mp_to_unsigned_bin_n.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn_mp_to_unsigned_bin_n.Tpo $(DEPDIR)/libhcrypto_la-bn_mp_to_unsigned_bin_n.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='libtommath/bn_mp_to_unsigned_bin_n.c' object='libhcrypto_la-bn_mp_to_unsigned_bin_n.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn_mp_to_unsigned_bin_n.lo `test -f 'libtommath/bn_mp_to_unsigned_bin_n.c' || echo '$(srcdir)/'`libtommath/bn_mp_to_unsigned_bin_n.c
++
++libhcrypto_la-aes.lo: aes.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-aes.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-aes.Tpo -c -o libhcrypto_la-aes.lo `test -f 'aes.c' || echo '$(srcdir)/'`aes.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-aes.Tpo $(DEPDIR)/libhcrypto_la-aes.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='aes.c' object='libhcrypto_la-aes.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-aes.lo `test -f 'aes.c' || echo '$(srcdir)/'`aes.c
++
++libhcrypto_la-bn.lo: bn.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-bn.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-bn.Tpo -c -o libhcrypto_la-bn.lo `test -f 'bn.c' || echo '$(srcdir)/'`bn.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-bn.Tpo $(DEPDIR)/libhcrypto_la-bn.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='bn.c' object='libhcrypto_la-bn.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-bn.lo `test -f 'bn.c' || echo '$(srcdir)/'`bn.c
++
++libhcrypto_la-common.lo: common.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-common.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-common.Tpo -c -o libhcrypto_la-common.lo `test -f 'common.c' || echo '$(srcdir)/'`common.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-common.Tpo $(DEPDIR)/libhcrypto_la-common.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='common.c' object='libhcrypto_la-common.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-common.lo `test -f 'common.c' || echo '$(srcdir)/'`common.c
++
++libhcrypto_la-camellia.lo: camellia.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-camellia.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-camellia.Tpo -c -o libhcrypto_la-camellia.lo `test -f 'camellia.c' || echo '$(srcdir)/'`camellia.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-camellia.Tpo $(DEPDIR)/libhcrypto_la-camellia.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='camellia.c' object='libhcrypto_la-camellia.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-camellia.lo `test -f 'camellia.c' || echo '$(srcdir)/'`camellia.c
++
++libhcrypto_la-camellia-ntt.lo: camellia-ntt.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-camellia-ntt.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-camellia-ntt.Tpo -c -o libhcrypto_la-camellia-ntt.lo `test -f 'camellia-ntt.c' || echo '$(srcdir)/'`camellia-ntt.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-camellia-ntt.Tpo $(DEPDIR)/libhcrypto_la-camellia-ntt.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='camellia-ntt.c' object='libhcrypto_la-camellia-ntt.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-camellia-ntt.lo `test -f 'camellia-ntt.c' || echo '$(srcdir)/'`camellia-ntt.c
++
++libhcrypto_la-des.lo: des.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-des.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-des.Tpo -c -o libhcrypto_la-des.lo `test -f 'des.c' || echo '$(srcdir)/'`des.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-des.Tpo $(DEPDIR)/libhcrypto_la-des.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='des.c' object='libhcrypto_la-des.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-des.lo `test -f 'des.c' || echo '$(srcdir)/'`des.c
++
++libhcrypto_la-dh.lo: dh.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-dh.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-dh.Tpo -c -o libhcrypto_la-dh.lo `test -f 'dh.c' || echo '$(srcdir)/'`dh.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-dh.Tpo $(DEPDIR)/libhcrypto_la-dh.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='dh.c' object='libhcrypto_la-dh.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-dh.lo `test -f 'dh.c' || echo '$(srcdir)/'`dh.c
++
++libhcrypto_la-dh-ltm.lo: dh-ltm.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-dh-ltm.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-dh-ltm.Tpo -c -o libhcrypto_la-dh-ltm.lo `test -f 'dh-ltm.c' || echo '$(srcdir)/'`dh-ltm.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-dh-ltm.Tpo $(DEPDIR)/libhcrypto_la-dh-ltm.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='dh-ltm.c' object='libhcrypto_la-dh-ltm.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-dh-ltm.lo `test -f 'dh-ltm.c' || echo '$(srcdir)/'`dh-ltm.c
++
++libhcrypto_la-dsa.lo: dsa.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-dsa.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-dsa.Tpo -c -o libhcrypto_la-dsa.lo `test -f 'dsa.c' || echo '$(srcdir)/'`dsa.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-dsa.Tpo $(DEPDIR)/libhcrypto_la-dsa.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='dsa.c' object='libhcrypto_la-dsa.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-dsa.lo `test -f 'dsa.c' || echo '$(srcdir)/'`dsa.c
++
++libhcrypto_la-doxygen.lo: doxygen.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-doxygen.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-doxygen.Tpo -c -o libhcrypto_la-doxygen.lo `test -f 'doxygen.c' || echo '$(srcdir)/'`doxygen.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-doxygen.Tpo $(DEPDIR)/libhcrypto_la-doxygen.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='doxygen.c' object='libhcrypto_la-doxygen.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-doxygen.lo `test -f 'doxygen.c' || echo '$(srcdir)/'`doxygen.c
++
++libhcrypto_la-evp.lo: evp.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-evp.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-evp.Tpo -c -o libhcrypto_la-evp.lo `test -f 'evp.c' || echo '$(srcdir)/'`evp.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-evp.Tpo $(DEPDIR)/libhcrypto_la-evp.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='evp.c' object='libhcrypto_la-evp.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-evp.lo `test -f 'evp.c' || echo '$(srcdir)/'`evp.c
++
++libhcrypto_la-evp-hcrypto.lo: evp-hcrypto.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-evp-hcrypto.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-evp-hcrypto.Tpo -c -o libhcrypto_la-evp-hcrypto.lo `test -f 'evp-hcrypto.c' || echo '$(srcdir)/'`evp-hcrypto.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-evp-hcrypto.Tpo $(DEPDIR)/libhcrypto_la-evp-hcrypto.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='evp-hcrypto.c' object='libhcrypto_la-evp-hcrypto.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-evp-hcrypto.lo `test -f 'evp-hcrypto.c' || echo '$(srcdir)/'`evp-hcrypto.c
++
++libhcrypto_la-evp-cc.lo: evp-cc.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-evp-cc.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-evp-cc.Tpo -c -o libhcrypto_la-evp-cc.lo `test -f 'evp-cc.c' || echo '$(srcdir)/'`evp-cc.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-evp-cc.Tpo $(DEPDIR)/libhcrypto_la-evp-cc.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='evp-cc.c' object='libhcrypto_la-evp-cc.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-evp-cc.lo `test -f 'evp-cc.c' || echo '$(srcdir)/'`evp-cc.c
++
++libhcrypto_la-engine.lo: engine.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-engine.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-engine.Tpo -c -o libhcrypto_la-engine.lo `test -f 'engine.c' || echo '$(srcdir)/'`engine.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-engine.Tpo $(DEPDIR)/libhcrypto_la-engine.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='engine.c' object='libhcrypto_la-engine.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-engine.lo `test -f 'engine.c' || echo '$(srcdir)/'`engine.c
++
++libhcrypto_la-hmac.lo: hmac.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-hmac.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-hmac.Tpo -c -o libhcrypto_la-hmac.lo `test -f 'hmac.c' || echo '$(srcdir)/'`hmac.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-hmac.Tpo $(DEPDIR)/libhcrypto_la-hmac.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='hmac.c' object='libhcrypto_la-hmac.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-hmac.lo `test -f 'hmac.c' || echo '$(srcdir)/'`hmac.c
++
++libhcrypto_la-md2.lo: md2.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-md2.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-md2.Tpo -c -o libhcrypto_la-md2.lo `test -f 'md2.c' || echo '$(srcdir)/'`md2.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-md2.Tpo $(DEPDIR)/libhcrypto_la-md2.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='md2.c' object='libhcrypto_la-md2.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-md2.lo `test -f 'md2.c' || echo '$(srcdir)/'`md2.c
++
++libhcrypto_la-md4.lo: md4.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-md4.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-md4.Tpo -c -o libhcrypto_la-md4.lo `test -f 'md4.c' || echo '$(srcdir)/'`md4.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-md4.Tpo $(DEPDIR)/libhcrypto_la-md4.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='md4.c' object='libhcrypto_la-md4.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-md4.lo `test -f 'md4.c' || echo '$(srcdir)/'`md4.c
++
++libhcrypto_la-md5.lo: md5.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-md5.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-md5.Tpo -c -o libhcrypto_la-md5.lo `test -f 'md5.c' || echo '$(srcdir)/'`md5.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-md5.Tpo $(DEPDIR)/libhcrypto_la-md5.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='md5.c' object='libhcrypto_la-md5.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-md5.lo `test -f 'md5.c' || echo '$(srcdir)/'`md5.c
++
++libhcrypto_la-pkcs5.lo: pkcs5.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-pkcs5.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-pkcs5.Tpo -c -o libhcrypto_la-pkcs5.lo `test -f 'pkcs5.c' || echo '$(srcdir)/'`pkcs5.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-pkcs5.Tpo $(DEPDIR)/libhcrypto_la-pkcs5.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='pkcs5.c' object='libhcrypto_la-pkcs5.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-pkcs5.lo `test -f 'pkcs5.c' || echo '$(srcdir)/'`pkcs5.c
++
++libhcrypto_la-pkcs12.lo: pkcs12.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-pkcs12.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-pkcs12.Tpo -c -o libhcrypto_la-pkcs12.lo `test -f 'pkcs12.c' || echo '$(srcdir)/'`pkcs12.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-pkcs12.Tpo $(DEPDIR)/libhcrypto_la-pkcs12.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='pkcs12.c' object='libhcrypto_la-pkcs12.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-pkcs12.lo `test -f 'pkcs12.c' || echo '$(srcdir)/'`pkcs12.c
++
++libhcrypto_la-rand-egd.lo: rand-egd.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-rand-egd.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-rand-egd.Tpo -c -o libhcrypto_la-rand-egd.lo `test -f 'rand-egd.c' || echo '$(srcdir)/'`rand-egd.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-rand-egd.Tpo $(DEPDIR)/libhcrypto_la-rand-egd.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rand-egd.c' object='libhcrypto_la-rand-egd.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-rand-egd.lo `test -f 'rand-egd.c' || echo '$(srcdir)/'`rand-egd.c
++
++libhcrypto_la-rand-fortuna.lo: rand-fortuna.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-rand-fortuna.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-rand-fortuna.Tpo -c -o libhcrypto_la-rand-fortuna.lo `test -f 'rand-fortuna.c' || echo '$(srcdir)/'`rand-fortuna.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-rand-fortuna.Tpo $(DEPDIR)/libhcrypto_la-rand-fortuna.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rand-fortuna.c' object='libhcrypto_la-rand-fortuna.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-rand-fortuna.lo `test -f 'rand-fortuna.c' || echo '$(srcdir)/'`rand-fortuna.c
++
++libhcrypto_la-rand-timer.lo: rand-timer.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-rand-timer.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-rand-timer.Tpo -c -o libhcrypto_la-rand-timer.lo `test -f 'rand-timer.c' || echo '$(srcdir)/'`rand-timer.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-rand-timer.Tpo $(DEPDIR)/libhcrypto_la-rand-timer.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rand-timer.c' object='libhcrypto_la-rand-timer.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-rand-timer.lo `test -f 'rand-timer.c' || echo '$(srcdir)/'`rand-timer.c
++
++libhcrypto_la-rand-unix.lo: rand-unix.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-rand-unix.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-rand-unix.Tpo -c -o libhcrypto_la-rand-unix.lo `test -f 'rand-unix.c' || echo '$(srcdir)/'`rand-unix.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-rand-unix.Tpo $(DEPDIR)/libhcrypto_la-rand-unix.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rand-unix.c' object='libhcrypto_la-rand-unix.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-rand-unix.lo `test -f 'rand-unix.c' || echo '$(srcdir)/'`rand-unix.c
++
++libhcrypto_la-rand.lo: rand.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-rand.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-rand.Tpo -c -o libhcrypto_la-rand.lo `test -f 'rand.c' || echo '$(srcdir)/'`rand.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-rand.Tpo $(DEPDIR)/libhcrypto_la-rand.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rand.c' object='libhcrypto_la-rand.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-rand.lo `test -f 'rand.c' || echo '$(srcdir)/'`rand.c
++
++libhcrypto_la-rc2.lo: rc2.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-rc2.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-rc2.Tpo -c -o libhcrypto_la-rc2.lo `test -f 'rc2.c' || echo '$(srcdir)/'`rc2.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-rc2.Tpo $(DEPDIR)/libhcrypto_la-rc2.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rc2.c' object='libhcrypto_la-rc2.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-rc2.lo `test -f 'rc2.c' || echo '$(srcdir)/'`rc2.c
++
++libhcrypto_la-rc4.lo: rc4.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-rc4.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-rc4.Tpo -c -o libhcrypto_la-rc4.lo `test -f 'rc4.c' || echo '$(srcdir)/'`rc4.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-rc4.Tpo $(DEPDIR)/libhcrypto_la-rc4.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rc4.c' object='libhcrypto_la-rc4.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-rc4.lo `test -f 'rc4.c' || echo '$(srcdir)/'`rc4.c
++
++libhcrypto_la-rijndael-alg-fst.lo: rijndael-alg-fst.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-rijndael-alg-fst.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-rijndael-alg-fst.Tpo -c -o libhcrypto_la-rijndael-alg-fst.lo `test -f 'rijndael-alg-fst.c' || echo '$(srcdir)/'`rijndael-alg-fst.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-rijndael-alg-fst.Tpo $(DEPDIR)/libhcrypto_la-rijndael-alg-fst.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rijndael-alg-fst.c' object='libhcrypto_la-rijndael-alg-fst.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-rijndael-alg-fst.lo `test -f 'rijndael-alg-fst.c' || echo '$(srcdir)/'`rijndael-alg-fst.c
++
++libhcrypto_la-rnd_keys.lo: rnd_keys.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-rnd_keys.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-rnd_keys.Tpo -c -o libhcrypto_la-rnd_keys.lo `test -f 'rnd_keys.c' || echo '$(srcdir)/'`rnd_keys.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-rnd_keys.Tpo $(DEPDIR)/libhcrypto_la-rnd_keys.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rnd_keys.c' object='libhcrypto_la-rnd_keys.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-rnd_keys.lo `test -f 'rnd_keys.c' || echo '$(srcdir)/'`rnd_keys.c
++
++libhcrypto_la-rsa.lo: rsa.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-rsa.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-rsa.Tpo -c -o libhcrypto_la-rsa.lo `test -f 'rsa.c' || echo '$(srcdir)/'`rsa.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-rsa.Tpo $(DEPDIR)/libhcrypto_la-rsa.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rsa.c' object='libhcrypto_la-rsa.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-rsa.lo `test -f 'rsa.c' || echo '$(srcdir)/'`rsa.c
++
++libhcrypto_la-rsa-gmp.lo: rsa-gmp.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-rsa-gmp.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-rsa-gmp.Tpo -c -o libhcrypto_la-rsa-gmp.lo `test -f 'rsa-gmp.c' || echo '$(srcdir)/'`rsa-gmp.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-rsa-gmp.Tpo $(DEPDIR)/libhcrypto_la-rsa-gmp.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rsa-gmp.c' object='libhcrypto_la-rsa-gmp.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-rsa-gmp.lo `test -f 'rsa-gmp.c' || echo '$(srcdir)/'`rsa-gmp.c
++
++libhcrypto_la-rsa-ltm.lo: rsa-ltm.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-rsa-ltm.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-rsa-ltm.Tpo -c -o libhcrypto_la-rsa-ltm.lo `test -f 'rsa-ltm.c' || echo '$(srcdir)/'`rsa-ltm.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-rsa-ltm.Tpo $(DEPDIR)/libhcrypto_la-rsa-ltm.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rsa-ltm.c' object='libhcrypto_la-rsa-ltm.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-rsa-ltm.lo `test -f 'rsa-ltm.c' || echo '$(srcdir)/'`rsa-ltm.c
++
++libhcrypto_la-sha.lo: sha.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-sha.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-sha.Tpo -c -o libhcrypto_la-sha.lo `test -f 'sha.c' || echo '$(srcdir)/'`sha.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-sha.Tpo $(DEPDIR)/libhcrypto_la-sha.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='sha.c' object='libhcrypto_la-sha.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-sha.lo `test -f 'sha.c' || echo '$(srcdir)/'`sha.c
++
++libhcrypto_la-sha256.lo: sha256.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-sha256.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-sha256.Tpo -c -o libhcrypto_la-sha256.lo `test -f 'sha256.c' || echo '$(srcdir)/'`sha256.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-sha256.Tpo $(DEPDIR)/libhcrypto_la-sha256.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='sha256.c' object='libhcrypto_la-sha256.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-sha256.lo `test -f 'sha256.c' || echo '$(srcdir)/'`sha256.c
++
++libhcrypto_la-sha512.lo: sha512.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-sha512.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-sha512.Tpo -c -o libhcrypto_la-sha512.lo `test -f 'sha512.c' || echo '$(srcdir)/'`sha512.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-sha512.Tpo $(DEPDIR)/libhcrypto_la-sha512.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='sha512.c' object='libhcrypto_la-sha512.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-sha512.lo `test -f 'sha512.c' || echo '$(srcdir)/'`sha512.c
++
++libhcrypto_la-validate.lo: validate.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-validate.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-validate.Tpo -c -o libhcrypto_la-validate.lo `test -f 'validate.c' || echo '$(srcdir)/'`validate.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-validate.Tpo $(DEPDIR)/libhcrypto_la-validate.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='validate.c' object='libhcrypto_la-validate.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-validate.lo `test -f 'validate.c' || echo '$(srcdir)/'`validate.c
++
++libhcrypto_la-ui.lo: ui.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhcrypto_la-ui.lo -MD -MP -MF $(DEPDIR)/libhcrypto_la-ui.Tpo -c -o libhcrypto_la-ui.lo `test -f 'ui.c' || echo '$(srcdir)/'`ui.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhcrypto_la-ui.Tpo $(DEPDIR)/libhcrypto_la-ui.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='ui.c' object='libhcrypto_la-ui.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhcrypto_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhcrypto_la-ui.lo `test -f 'ui.c' || echo '$(srcdir)/'`ui.c
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-hcryptoincludeHEADERS: $(hcryptoinclude_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(hcryptoincludedir)" || $(MKDIR_P) "$(DESTDIR)$(hcryptoincludedir)"
++	@list='$(hcryptoinclude_HEADERS)'; test -n "$(hcryptoincludedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(hcryptoincludedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(hcryptoincludedir)" || exit $$?; \
++	done
++
++uninstall-hcryptoincludeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(hcryptoinclude_HEADERS)'; test -n "$(hcryptoincludedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(hcryptoincludedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(hcryptoincludedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_LTLIBRARIES) $(check_PROGRAMS) \
++	  $(check_SCRIPTS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(HEADERS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(hcryptoincludedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-checkLTLIBRARIES clean-checkPROGRAMS clean-generic \
++	clean-libLTLIBRARIES clean-libtool clean-noinstPROGRAMS \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-hcryptoincludeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-hcryptoincludeHEADERS uninstall-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-TESTS check-am \
++	check-local clean clean-checkLTLIBRARIES clean-checkPROGRAMS \
++	clean-generic clean-libLTLIBRARIES clean-libtool \
++	clean-noinstPROGRAMS ctags dist-hook distclean \
++	distclean-compile distclean-generic distclean-libtool \
++	distclean-tags distdir dvi dvi-am html html-am info info-am \
++	install install-am install-data install-data-am \
++	install-data-hook install-dvi install-dvi-am install-exec \
++	install-exec-am install-exec-hook \
++	install-hcryptoincludeHEADERS install-html install-html-am \
++	install-info install-info-am install-libLTLIBRARIES \
++	install-man install-pdf install-pdf-am install-ps \
++	install-ps-am install-strip installcheck installcheck-am \
++	installdirs maintainer-clean maintainer-clean-generic \
++	mostlyclean mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags uninstall \
++	uninstall-am uninstall-hcryptoincludeHEADERS uninstall-hook \
++	uninstall-libLTLIBRARIES
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++install-build-headers:: $(hcryptoinclude_HEADERS)
++	@foo='$(hcryptoinclude_HEADERS)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildhcryptoinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo "cp $$file $(buildhcryptoinclude)/$$f";\
++			cp $$file $(buildhcryptoinclude)/$$f; \
++		fi ; \
++	done
++
++$(libhcrypto_la_OBJECTS): hcrypto-link
++$(libhcrypto_la_OBJECTS): $(srcdir)/version-script.map
++
++hcrypto-link:
++	$(LN_S) $(srcdir)/../hcrypto hcrypto
++	touch hcrypto-link
++
++test_crypto: test_crypto.in Makefile
++	$(do_subst) < $(srcdir)/test_crypto.in > test_crypto.tmp
++	chmod +x test_crypto.tmp
++	mv test_crypto.tmp test_crypto
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/hdb/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/hdb/Makefile.in	2010-12-29 04:07:10.596502485 +0100
+@@ -0,0 +1,1147 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(include_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++@HAVE_DBHEADER_TRUE@am__append_1 = -I$(DBHEADER)
++@versionscript_TRUE@am__append_2 = $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-script.map
++noinst_PROGRAMS = test_dbinfo$(EXEEXT) test_hdbkeys$(EXEEXT) \
++	test_mkey$(EXEEXT)
++subdir = lib/hdb
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(includedir)" \
++	"$(DESTDIR)$(includedir)"
++LTLIBRARIES = $(lib_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++@OPENLDAP_MODULE_TRUE@hdb_ldap_la_DEPENDENCIES =  \
++@OPENLDAP_MODULE_TRUE@	$(am__DEPENDENCIES_1) libhdb.la
++am__hdb_ldap_la_SOURCES_DIST = hdb-ldap.c
++@OPENLDAP_MODULE_TRUE@am_hdb_ldap_la_OBJECTS = hdb-ldap.lo
++hdb_ldap_la_OBJECTS = $(am_hdb_ldap_la_OBJECTS)
++hdb_ldap_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(hdb_ldap_la_LDFLAGS) $(LDFLAGS) -o $@
++@OPENLDAP_MODULE_TRUE@am_hdb_ldap_la_rpath = -rpath $(libdir)
++@OPENLDAP_MODULE_FALSE@am__DEPENDENCIES_2 = $(am__DEPENDENCIES_1)
++libhdb_la_DEPENDENCIES = $(am__DEPENDENCIES_1) ../krb5/libkrb5.la \
++	../asn1/libasn1.la $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_2) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++am__dist_libhdb_la_SOURCES_DIST = common.c db.c db3.c ext.c hdb-ldap.c \
++	hdb.c hdb-sqlite.c hdb-keytab.c hdb-mitdb.c hdb_locl.h \
++	hdb-private.h keys.c keytab.c dbinfo.c mkey.c ndbm.c print.c
++@OPENLDAP_MODULE_FALSE@am__objects_1 = hdb-ldap.lo
++dist_libhdb_la_OBJECTS = common.lo db.lo db3.lo ext.lo \
++	$(am__objects_1) hdb.lo hdb-sqlite.lo hdb-keytab.lo \
++	hdb-mitdb.lo keys.lo keytab.lo dbinfo.lo mkey.lo ndbm.lo \
++	print.lo
++am__objects_2 = asn1_Salt.lo asn1_Key.lo asn1_Event.lo \
++	asn1_HDBFlags.lo asn1_GENERATION.lo asn1_HDB_Ext_PKINIT_acl.lo \
++	asn1_HDB_Ext_PKINIT_cert.lo asn1_HDB_Ext_PKINIT_hash.lo \
++	asn1_HDB_Ext_Constrained_delegation_acl.lo \
++	asn1_HDB_Ext_Lan_Manager_OWF.lo asn1_HDB_Ext_Password.lo \
++	asn1_HDB_Ext_Aliases.lo asn1_HDB_extension.lo \
++	asn1_HDB_extensions.lo asn1_hdb_entry.lo \
++	asn1_hdb_entry_alias.lo asn1_hdb_keyset.lo
++am__objects_3 = $(am__objects_2) hdb_err.lo
++nodist_libhdb_la_OBJECTS = $(am__objects_3)
++libhdb_la_OBJECTS = $(dist_libhdb_la_OBJECTS) \
++	$(nodist_libhdb_la_OBJECTS)
++libhdb_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libhdb_la_LDFLAGS) $(LDFLAGS) -o $@
++PROGRAMS = $(noinst_PROGRAMS)
++test_dbinfo_SOURCES = test_dbinfo.c
++test_dbinfo_OBJECTS = test_dbinfo.$(OBJEXT)
++test_dbinfo_LDADD = $(LDADD)
++test_dbinfo_DEPENDENCIES = libhdb.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) ../krb5/libkrb5.la ../asn1/libasn1.la \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++test_hdbkeys_SOURCES = test_hdbkeys.c
++test_hdbkeys_OBJECTS = test_hdbkeys.$(OBJEXT)
++test_hdbkeys_LDADD = $(LDADD)
++test_hdbkeys_DEPENDENCIES = libhdb.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) ../krb5/libkrb5.la ../asn1/libasn1.la \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++test_mkey_SOURCES = test_mkey.c
++test_mkey_OBJECTS = test_mkey.$(OBJEXT)
++test_mkey_LDADD = $(LDADD)
++test_mkey_DEPENDENCIES = libhdb.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) ../krb5/libkrb5.la ../asn1/libasn1.la \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(hdb_ldap_la_SOURCES) $(dist_libhdb_la_SOURCES) \
++	$(nodist_libhdb_la_SOURCES) test_dbinfo.c test_hdbkeys.c \
++	test_mkey.c
++DIST_SOURCES = $(am__hdb_ldap_la_SOURCES_DIST) \
++	$(am__dist_libhdb_la_SOURCES_DIST) test_dbinfo.c \
++	test_hdbkeys.c test_mkey.c
++HEADERS = $(include_HEADERS) $(nodist_include_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) -I../asn1 -I$(srcdir)/../asn1 \
++	$(INCLUDE_hcrypto) $(INCLUDE_openldap) \
++	-DHDB_DB_DIR=\"$(DIR_hdbdir)\" -I$(srcdir)/../krb5 \
++	$(INCLUDE_sqlite3) $(INCLUDE_libintl) $(am__append_1)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++BUILT_SOURCES = \
++	$(gen_files_hdb:.x=.c)	\
++	hdb_err.c \
++	hdb_err.h
++
++gen_files_hdb = \
++	asn1_Salt.x \
++	asn1_Key.x \
++	asn1_Event.x \
++	asn1_HDBFlags.x \
++	asn1_GENERATION.x \
++	asn1_HDB_Ext_PKINIT_acl.x \
++	asn1_HDB_Ext_PKINIT_cert.x \
++	asn1_HDB_Ext_PKINIT_hash.x \
++	asn1_HDB_Ext_Constrained_delegation_acl.x \
++	asn1_HDB_Ext_Lan_Manager_OWF.x \
++	asn1_HDB_Ext_Password.x \
++	asn1_HDB_Ext_Aliases.x \
++	asn1_HDB_extension.x \
++	asn1_HDB_extensions.x \
++	asn1_hdb_entry.x \
++	asn1_hdb_entry_alias.x \
++	asn1_hdb_keyset.x
++
++CLEANFILES = $(BUILT_SOURCES) $(gen_files_hdb) \
++	hdb_asn1{,-priv}.h* hdb_asn1_files hdb_asn1-template.c*
++
++LDADD = libhdb.la \
++	$(LIB_openldap) \
++	$(LIB_libintl) \
++	../krb5/libkrb5.la \
++	../asn1/libasn1.la \
++	$(LIB_hcrypto) \
++	$(LIB_roken) \
++	$(LIB_ldopen)
++
++@OPENLDAP_MODULE_TRUE@ldap_so = hdb_ldap.la
++@OPENLDAP_MODULE_TRUE@hdb_ldap_la_SOURCES = hdb-ldap.c
++@OPENLDAP_MODULE_TRUE@hdb_ldap_la_LDFLAGS = -module -avoid-version
++@OPENLDAP_MODULE_TRUE@hdb_ldap_la_LIBADD = $(LIB_openldap) libhdb.la
++@OPENLDAP_MODULE_FALSE@ldap = hdb-ldap.c
++@OPENLDAP_MODULE_FALSE@ldap_lib = $(LIB_openldap)
++lib_LTLIBRARIES = libhdb.la $(ldap_so)
++libhdb_la_LDFLAGS = -version-info 11:0:2 $(am__append_2)
++dist_libhdb_la_SOURCES = \
++	common.c				\
++	db.c					\
++	db3.c					\
++	ext.c					\
++	$(ldap)					\
++	hdb.c					\
++	hdb-sqlite.c				\
++	hdb-keytab.c				\
++	hdb-mitdb.c				\
++	hdb_locl.h				\
++	hdb-private.h				\
++	keys.c					\
++	keytab.c				\
++	dbinfo.c				\
++	mkey.c					\
++	ndbm.c					\
++	print.c
++
++nodist_libhdb_la_SOURCES = $(BUILT_SOURCES)
++include_HEADERS = hdb.h hdb-protos.h
++nodist_include_HEADERS = hdb_err.h hdb_asn1.h
++libhdb_la_LIBADD = \
++	$(LIB_com_err) \
++	../krb5/libkrb5.la \
++	../asn1/libasn1.la \
++	$(LIB_sqlite3) \
++	$(LIBADD_roken) \
++	$(ldap_lib) \
++	$(LIB_dlopen) \
++	$(DBLIB) \
++	$(LIB_NDBM)
++
++test_dbinfo_LIBS = libhdb.la
++test_hdbkeys_LIBS = ../krb5/libkrb5.la libhdb.la
++test_mkey_LIBS = $(test_hdbkeys_LIBS)
++EXTRA_DIST = \
++	hdb.asn1 \
++	hdb_err.et \
++	hdb.schema \
++	version-script.map \
++	data-mkey.mit.des3.le \
++	data-mkey.mit.des3.be
++
++all: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/hdb/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/hdb/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++hdb_ldap.la: $(hdb_ldap_la_OBJECTS) $(hdb_ldap_la_DEPENDENCIES) 
++	$(hdb_ldap_la_LINK) $(am_hdb_ldap_la_rpath) $(hdb_ldap_la_OBJECTS) $(hdb_ldap_la_LIBADD) $(LIBS)
++libhdb.la: $(libhdb_la_OBJECTS) $(libhdb_la_DEPENDENCIES) 
++	$(libhdb_la_LINK) -rpath $(libdir) $(libhdb_la_OBJECTS) $(libhdb_la_LIBADD) $(LIBS)
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++test_dbinfo$(EXEEXT): $(test_dbinfo_OBJECTS) $(test_dbinfo_DEPENDENCIES) 
++	@rm -f test_dbinfo$(EXEEXT)
++	$(LINK) $(test_dbinfo_OBJECTS) $(test_dbinfo_LDADD) $(LIBS)
++test_hdbkeys$(EXEEXT): $(test_hdbkeys_OBJECTS) $(test_hdbkeys_DEPENDENCIES) 
++	@rm -f test_hdbkeys$(EXEEXT)
++	$(LINK) $(test_hdbkeys_OBJECTS) $(test_hdbkeys_LDADD) $(LIBS)
++test_mkey$(EXEEXT): $(test_mkey_OBJECTS) $(test_mkey_DEPENDENCIES) 
++	@rm -f test_mkey$(EXEEXT)
++	$(LINK) $(test_mkey_OBJECTS) $(test_mkey_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_Event.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_GENERATION.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_HDBFlags.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_HDB_Ext_Aliases.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_HDB_Ext_Constrained_delegation_acl.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_HDB_Ext_Lan_Manager_OWF.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_HDB_Ext_PKINIT_acl.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_HDB_Ext_PKINIT_cert.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_HDB_Ext_PKINIT_hash.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_HDB_Ext_Password.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_HDB_extension.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_HDB_extensions.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_Key.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_Salt.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_hdb_entry.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_hdb_entry_alias.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/asn1_hdb_keyset.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/common.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/db.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/db3.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/dbinfo.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ext.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hdb-keytab.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hdb-ldap.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hdb-mitdb.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hdb-sqlite.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hdb.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hdb_err.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/keys.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/keytab.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/mkey.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ndbm.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/print.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_dbinfo.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_hdbkeys.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_mkey.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-includeHEADERS: $(include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++install-nodist_includeHEADERS: $(nodist_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-nodist_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(HEADERS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(includedir)" "$(DESTDIR)$(includedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++	-test -z "$(BUILT_SOURCES)" || rm -f $(BUILT_SOURCES)
++clean: clean-am
++
++clean-am: clean-generic clean-libLTLIBRARIES clean-libtool \
++	clean-noinstPROGRAMS mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-includeHEADERS install-nodist_includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-includeHEADERS uninstall-libLTLIBRARIES \
++	uninstall-nodist_includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: all check check-am install install-am install-data-am \
++	install-exec-am install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libLTLIBRARIES clean-libtool \
++	clean-noinstPROGRAMS ctags dist-hook distclean \
++	distclean-compile distclean-generic distclean-libtool \
++	distclean-tags distdir dvi dvi-am html html-am info info-am \
++	install install-am install-data install-data-am \
++	install-data-hook install-dvi install-dvi-am install-exec \
++	install-exec-am install-exec-hook install-html install-html-am \
++	install-includeHEADERS install-info install-info-am \
++	install-libLTLIBRARIES install-man \
++	install-nodist_includeHEADERS install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-hook \
++	uninstall-includeHEADERS uninstall-libLTLIBRARIES \
++	uninstall-nodist_includeHEADERS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(libhdb_la_OBJECTS): $(srcdir)/hdb-protos.h $(srcdir)/hdb-private.h
++$(libhdb_la_OBJECTS): hdb_asn1.h hdb_asn1-priv.h hdb_err.h
++
++$(srcdir)/hdb-protos.h:
++	cd $(srcdir); perl ../../cf/make-proto.pl -q -P comment -o hdb-protos.h $(dist_libhdb_la_SOURCES) || rm -f hdb-protos.h
++
++$(srcdir)/hdb-private.h:
++	cd $(srcdir); perl ../../cf/make-proto.pl -q -P comment -p hdb-private.h $(dist_libhdb_la_SOURCES) || rm -f hdb-private.h
++
++$(gen_files_hdb) hdb_asn1.hx hdb_asn1-priv.hx: hdb_asn1_files
++
++hdb_asn1_files: $(ASN1_COMPILE_DEP) $(srcdir)/hdb.asn1
++	$(ASN1_COMPILE) $(srcdir)/hdb.asn1 hdb_asn1
++
++# to help stupid solaris make
++
++hdb_err.h: hdb_err.et
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/hx509/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/hx509/Makefile.in	2010-12-29 04:07:11.236702400 +0100
+@@ -0,0 +1,2007 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(dist_include_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog TODO sel-gram.c \
++	sel-gram.h sel-lex.c
++@FRAMEWORK_SECURITY_TRUE@am__append_1 = -framework Security -framework CoreFoundation
++@versionscript_TRUE@am__append_2 = $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-script.map
++bin_PROGRAMS = hxtool$(EXEEXT)
++check_PROGRAMS = $(am__EXEEXT_1) test_soft_pkcs11$(EXEEXT)
++TESTS = $(SCRIPT_TESTS) $(am__EXEEXT_1)
++subdir = lib/hx509
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(bindir)" \
++	"$(DESTDIR)$(includedir)" "$(DESTDIR)$(includedir)"
++LTLIBRARIES = $(lib_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++libhx509_la_DEPENDENCIES = $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++dist_libhx509_la_OBJECTS = libhx509_la-ca.lo libhx509_la-cert.lo \
++	libhx509_la-cms.lo libhx509_la-collector.lo \
++	libhx509_la-crypto.lo libhx509_la-doxygen.lo \
++	libhx509_la-error.lo libhx509_la-env.lo libhx509_la-file.lo \
++	libhx509_la-sel.lo libhx509_la-sel-gram.lo \
++	libhx509_la-sel-lex.lo libhx509_la-keyset.lo \
++	libhx509_la-ks_dir.lo libhx509_la-ks_file.lo \
++	libhx509_la-ks_mem.lo libhx509_la-ks_null.lo \
++	libhx509_la-ks_p11.lo libhx509_la-ks_p12.lo \
++	libhx509_la-ks_keychain.lo libhx509_la-lock.lo \
++	libhx509_la-name.lo libhx509_la-peer.lo libhx509_la-print.lo \
++	libhx509_la-softp11.lo libhx509_la-req.lo \
++	libhx509_la-revoke.lo
++am__objects_1 = libhx509_la-asn1_OCSPBasicOCSPResponse.lo \
++	libhx509_la-asn1_OCSPCertID.lo \
++	libhx509_la-asn1_OCSPCertStatus.lo \
++	libhx509_la-asn1_OCSPInnerRequest.lo \
++	libhx509_la-asn1_OCSPKeyHash.lo \
++	libhx509_la-asn1_OCSPRequest.lo \
++	libhx509_la-asn1_OCSPResponderID.lo \
++	libhx509_la-asn1_OCSPResponse.lo \
++	libhx509_la-asn1_OCSPResponseBytes.lo \
++	libhx509_la-asn1_OCSPResponseData.lo \
++	libhx509_la-asn1_OCSPResponseStatus.lo \
++	libhx509_la-asn1_OCSPSignature.lo \
++	libhx509_la-asn1_OCSPSingleResponse.lo \
++	libhx509_la-asn1_OCSPTBSRequest.lo \
++	libhx509_la-asn1_OCSPVersion.lo \
++	libhx509_la-asn1_id_pkix_ocsp.lo \
++	libhx509_la-asn1_id_pkix_ocsp_basic.lo \
++	libhx509_la-asn1_id_pkix_ocsp_nonce.lo
++am__objects_2 = libhx509_la-asn1_CertificationRequestInfo.lo \
++	libhx509_la-asn1_CertificationRequest.lo
++am__objects_3 = $(am__objects_1) $(am__objects_2) \
++	libhx509_la-hx509_err.lo
++nodist_libhx509_la_OBJECTS = $(am__objects_3)
++libhx509_la_OBJECTS = $(dist_libhx509_la_OBJECTS) \
++	$(nodist_libhx509_la_OBJECTS)
++libhx509_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libhx509_la_LDFLAGS) $(LDFLAGS) -o $@
++am__EXEEXT_1 = test_name$(EXEEXT) test_expr$(EXEEXT)
++PROGRAMS = $(bin_PROGRAMS)
++dist_hxtool_OBJECTS = hxtool-hxtool.$(OBJEXT)
++nodist_hxtool_OBJECTS = hxtool-hxtool-commands.$(OBJEXT)
++hxtool_OBJECTS = $(dist_hxtool_OBJECTS) $(nodist_hxtool_OBJECTS)
++hxtool_DEPENDENCIES = libhx509.la $(top_builddir)/lib/asn1/libasn1.la \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/sl/libsl.la
++test_expr_SOURCES = test_expr.c
++test_expr_OBJECTS = test_expr.$(OBJEXT)
++test_expr_LDADD = $(LDADD)
++test_expr_DEPENDENCIES = libhx509.la
++test_name_SOURCES = test_name.c
++test_name_OBJECTS = test_name.$(OBJEXT)
++test_name_LDADD = $(LDADD)
++test_name_DEPENDENCIES = libhx509.la
++test_soft_pkcs11_SOURCES = test_soft_pkcs11.c
++test_soft_pkcs11_OBJECTS =  \
++	test_soft_pkcs11-test_soft_pkcs11.$(OBJEXT)
++test_soft_pkcs11_DEPENDENCIES = libhx509.la
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++@MAINTAINER_MODE_FALSE@am__skiplex = test -f $@ ||
++LEXCOMPILE = $(LEX) $(LFLAGS) $(AM_LFLAGS)
++LTLEXCOMPILE = $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(LEX) $(LFLAGS) $(AM_LFLAGS)
++YLWRAP = $(top_srcdir)/ylwrap
++@MAINTAINER_MODE_FALSE@am__skipyacc = test -f $@ ||
++YACCCOMPILE = $(YACC) $(YFLAGS) $(AM_YFLAGS)
++LTYACCCOMPILE = $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(YACC) $(YFLAGS) $(AM_YFLAGS)
++SOURCES = $(dist_libhx509_la_SOURCES) $(nodist_libhx509_la_SOURCES) \
++	$(dist_hxtool_SOURCES) $(nodist_hxtool_SOURCES) test_expr.c \
++	test_name.c test_soft_pkcs11.c
++DIST_SOURCES = $(dist_libhx509_la_SOURCES) $(dist_hxtool_SOURCES) \
++	test_expr.c test_name.c test_soft_pkcs11.c
++HEADERS = $(dist_include_HEADERS) $(nodist_include_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++lib_LTLIBRARIES = libhx509.la
++libhx509_la_LDFLAGS = -version-info 5:0:0 $(am__append_1) \
++	$(am__append_2)
++BUILT_SOURCES = \
++	sel-gram.h			\
++	$(gen_files_ocsp:.x=.c)		\
++	$(gen_files_pkcs10:.x=.c)	\
++	hx509_err.c			\
++	hx509_err.h
++
++gen_files_ocsp = \
++	asn1_OCSPBasicOCSPResponse.x	\
++	asn1_OCSPCertID.x		\
++	asn1_OCSPCertStatus.x		\
++	asn1_OCSPInnerRequest.x		\
++	asn1_OCSPKeyHash.x		\
++	asn1_OCSPRequest.x		\
++	asn1_OCSPResponderID.x		\
++	asn1_OCSPResponse.x		\
++	asn1_OCSPResponseBytes.x	\
++	asn1_OCSPResponseData.x		\
++	asn1_OCSPResponseStatus.x	\
++	asn1_OCSPSignature.x		\
++	asn1_OCSPSingleResponse.x	\
++	asn1_OCSPTBSRequest.x		\
++	asn1_OCSPVersion.x		\
++	asn1_id_pkix_ocsp.x		\
++	asn1_id_pkix_ocsp_basic.x	\
++	asn1_id_pkix_ocsp_nonce.x
++
++gen_files_pkcs10 = \
++	asn1_CertificationRequestInfo.x	\
++	asn1_CertificationRequest.x
++
++gen_files_crmf = \
++	asn1_CRMFRDNSequence.x		\
++	asn1_CertReqMessages.x		\
++	asn1_CertReqMsg.x		\
++	asn1_CertRequest.x		\
++	asn1_CertTemplate.x		\
++	asn1_Controls.x			\
++	asn1_PBMParameter.x		\
++	asn1_PKMACValue.x		\
++	asn1_POPOPrivKey.x		\
++	asn1_POPOSigningKey.x		\
++	asn1_POPOSigningKeyInput.x	\
++	asn1_ProofOfPossession.x	\
++	asn1_SubsequentMessage.x	
++
++AM_YFLAGS = -d
++dist_libhx509_la_SOURCES = \
++	ca.c \
++	cert.c \
++	char_map.h \
++	cms.c \
++	collector.c \
++	crypto.c \
++	doxygen.c \
++	error.c \
++	env.c \
++	file.c \
++	hx509-private.h \
++	hx509-protos.h \
++	hx509.h \
++	hx_locl.h \
++	sel.c \
++	sel.h \
++	sel-gram.y \
++	sel-lex.l \
++	keyset.c \
++	ks_dir.c \
++	ks_file.c \
++	ks_mem.c \
++	ks_null.c \
++	ks_p11.c \
++	ks_p12.c \
++	ks_keychain.c \
++	lock.c \
++	name.c \
++	peer.c \
++	print.c \
++	softp11.c \
++	ref/pkcs11.h \
++	req.c \
++	revoke.c
++
++libhx509_la_LIBADD = \
++	$(LIB_com_err) \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la \
++	$(LIBADD_roken) \
++	$(LIB_dlopen)
++
++libhx509_la_CPPFLAGS = -I$(srcdir)/ref $(INCLUDE_hcrypto)
++nodist_libhx509_la_SOURCES = $(BUILT_SOURCES)
++dist_include_HEADERS = hx509.h hx509-protos.h
++nodist_include_HEADERS = hx509_err.h ocsp_asn1.h pkcs10_asn1.h \
++	crmf_asn1.h
++priv_headers = ocsp_asn1-priv.h pkcs10_asn1-priv.h crmf_asn1-priv.h
++dist_hxtool_SOURCES = hxtool.c
++nodist_hxtool_SOURCES = hxtool-commands.c hxtool-commands.h
++hxtool_CPPFLAGS = $(INCLUDE_hcrypto)
++hxtool_LDADD = \
++	libhx509.la \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_hcrypto) \
++	$(LIB_roken) \
++	$(top_builddir)/lib/sl/libsl.la
++
++CLEANFILES = $(BUILT_SOURCES) sel-gram.c sel-lex.c \
++	$(gen_files_ocsp) ocsp_asn1_files ocsp_asn1{,-priv}.h* \
++	ocsp_asn1-template.[ch]* \
++	$(gen_files_pkcs10) pkcs10_asn1_files pkcs10_asn1{,-priv}.h* \
++	pkcs10_asn1-template.[ch]* \
++	$(gen_files_crmf) crmf_asn1_files crmf_asn1{,-priv}.h* \
++	crmf_asn1-template.[ch]* \
++	$(TESTS) \
++	hxtool-commands.c hxtool-commands.h *.tmp \
++	request.out \
++	out.pem out2.pem \
++	sd sd.pem \
++	sd.data sd.data.out \
++	ev.data ev.data.out \
++	cert-null.pem cert-sub-ca2.pem \
++	cert-ee.pem cert-ca.pem \
++	cert-sub-ee.pem cert-sub-ca.pem \
++	cert-proxy.der cert-ca.der cert-ee.der pkcs10-request.der \
++	wca.pem wuser.pem wdc.pem wcrl.crl \
++	random-data statfile crl.crl \
++	test p11dbg.log pkcs11.cfg \
++	test-rc-file.rc
++
++
++#
++# regression tests
++#
++check_SCRIPTS = $(SCRIPT_TESTS)
++LDADD = libhx509.la
++test_soft_pkcs11_LDADD = libhx509.la
++test_soft_pkcs11_CPPFLAGS = -I$(srcdir)/ref
++PROGRAM_TESTS = \
++	test_name		\
++	test_expr
++
++SCRIPT_TESTS = \
++	test_ca			\
++	test_cert		\
++	test_chain		\
++	test_cms		\
++	test_crypto		\
++	test_nist		\
++	test_nist2		\
++	test_pkcs11		\
++	test_java_pkcs11	\
++	test_nist_cert		\
++	test_nist_pkcs12	\
++	test_req		\
++	test_windows		\
++	test_query
++
++do_subst = sed -e 's,[@]srcdir[@],$(srcdir),g' \
++	-e 's,[@]objdir[@],$(top_builddir)/lib/hx509,g' \
++	-e 's,[@]egrep[@],$(EGREP),g'
++
++EXTRA_DIST = \
++	version-script.map \
++	crmf.asn1 \
++	hx509_err.et \
++	hxtool-commands.in \
++	quote.py \
++	ocsp.asn1 \
++	ocsp.opt \
++	pkcs10.asn1 \
++	pkcs10.opt \
++	test_ca.in \
++	test_chain.in \
++	test_cert.in \
++	test_cms.in \
++	test_crypto.in \
++	test_nist.in \
++	test_nist2.in \
++	test_nist_cert.in \
++	test_nist_pkcs12.in \
++	test_pkcs11.in \
++	test_java_pkcs11.in \
++	test_query.in \
++	test_req.in \
++	test_windows.in \
++	tst-crypto-available1 \
++	tst-crypto-available2 \
++	tst-crypto-available3 \
++	tst-crypto-select \
++	tst-crypto-select1 \
++	tst-crypto-select2 \
++	tst-crypto-select3 \
++	tst-crypto-select4 \
++	tst-crypto-select5 \
++	tst-crypto-select6 \
++	tst-crypto-select7 \
++	data/n0ll.pem \
++	data/secp160r1TestCA.cert.pem \
++	data/secp160r1TestCA.key.pem \
++	data/secp160r1TestCA.pem \
++	data/secp160r2TestClient.cert.pem \
++	data/secp160r2TestClient.key.pem \
++	data/secp160r2TestClient.pem \
++	data/secp160r2TestServer.cert.pem \
++	data/secp160r2TestServer.key.pem \
++	data/secp160r2TestServer.pem \
++	data/bleichenbacher-bad.pem \
++	data/bleichenbacher-good.pem \
++	data/bleichenbacher-sf-pad-correct.pem \
++	data/ca.crt \
++	data/ca.key \
++	data/crl1.crl \
++	data/crl1.der \
++	data/gen-req.sh \
++	data/j.pem \
++	data/kdc.crt \
++	data/kdc.key \
++	data/key.der \
++	data/key2.der \
++	data/nist-data \
++	data/nist-data2 \
++	data/no-proxy-test.crt \
++	data/no-proxy-test.key \
++	data/ocsp-req1.der \
++	data/ocsp-req2.der \
++	data/ocsp-resp1-2.der \
++	data/ocsp-resp1-3.der \
++	data/ocsp-resp1-ca.der \
++	data/ocsp-resp1-keyhash.der \
++	data/ocsp-resp1-ocsp-no-cert.der \
++	data/ocsp-resp1-ocsp.der \
++	data/ocsp-resp1.der \
++	data/ocsp-resp2.der \
++	data/ocsp-responder.crt \
++	data/ocsp-responder.key \
++	data/openssl.cnf \
++	data/pkinit-proxy-chain.crt \
++	data/pkinit-proxy.crt \
++	data/pkinit-proxy.key \
++	data/pkinit-pw.key \
++	data/pkinit.crt \
++	data/pkinit.key \
++	data/pkinit-ec.crt \
++	data/pkinit-ec.key \
++	data/proxy-level-test.crt \
++	data/proxy-level-test.key \
++	data/proxy-test.crt \
++	data/proxy-test.key \
++	data/proxy10-child-test.crt \
++	data/proxy10-child-test.key \
++	data/proxy10-child-child-test.crt \
++	data/proxy10-child-child-test.key \
++	data/proxy10-test.crt \
++	data/proxy10-test.key \
++	data/revoke.crt \
++	data/revoke.key \
++	data/sf-class2-root.pem \
++	data/static-file \
++	data/sub-ca.crt \
++	data/sub-ca.key \
++	data/sub-cert.crt \
++	data/sub-cert.key \
++	data/sub-cert.p12 \
++	data/test-ds-only.crt \
++	data/test-ds-only.key \
++	data/test-enveloped-aes-128 \
++	data/test-enveloped-aes-256 \
++	data/test-enveloped-des \
++	data/test-enveloped-des-ede3 \
++	data/test-enveloped-rc2-128 \
++	data/test-enveloped-rc2-40 \
++	data/test-enveloped-rc2-64 \
++	data/test-ke-only.crt \
++	data/test-ke-only.key \
++	data/test-nopw.p12 \
++	data/test-pw.key \
++	data/test-signed-data \
++	data/test-signed-data-noattr \
++	data/test-signed-data-noattr-nocerts \
++	data/test-signed-sha-1 \
++	data/test-signed-sha-256 \
++	data/test-signed-sha-512 \
++	data/test.combined.crt \
++	data/test.crt \
++	data/test.key \
++	data/test.p12 \
++	data/win-u16-in-printablestring.der \
++	data/yutaka-pad-broken-ca.pem \
++	data/yutaka-pad-broken-cert.pem \
++	data/yutaka-pad-ok-ca.pem \
++	data/yutaka-pad-ok-cert.pem \
++	data/yutaka-pad.key
++
++all: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .l .lo .o .obj .y
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/hx509/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/hx509/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++sel-gram.h: sel-gram.c
++	@if test ! -f $@; then \
++	  rm -f sel-gram.c; \
++	  $(MAKE) $(AM_MAKEFLAGS) sel-gram.c; \
++	else :; fi
++libhx509.la: $(libhx509_la_OBJECTS) $(libhx509_la_DEPENDENCIES) 
++	$(libhx509_la_LINK) -rpath $(libdir) $(libhx509_la_OBJECTS) $(libhx509_la_LIBADD) $(LIBS)
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-checkPROGRAMS:
++	@list='$(check_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++hxtool$(EXEEXT): $(hxtool_OBJECTS) $(hxtool_DEPENDENCIES) 
++	@rm -f hxtool$(EXEEXT)
++	$(LINK) $(hxtool_OBJECTS) $(hxtool_LDADD) $(LIBS)
++test_expr$(EXEEXT): $(test_expr_OBJECTS) $(test_expr_DEPENDENCIES) 
++	@rm -f test_expr$(EXEEXT)
++	$(LINK) $(test_expr_OBJECTS) $(test_expr_LDADD) $(LIBS)
++test_name$(EXEEXT): $(test_name_OBJECTS) $(test_name_DEPENDENCIES) 
++	@rm -f test_name$(EXEEXT)
++	$(LINK) $(test_name_OBJECTS) $(test_name_LDADD) $(LIBS)
++test_soft_pkcs11$(EXEEXT): $(test_soft_pkcs11_OBJECTS) $(test_soft_pkcs11_DEPENDENCIES) 
++	@rm -f test_soft_pkcs11$(EXEEXT)
++	$(LINK) $(test_soft_pkcs11_OBJECTS) $(test_soft_pkcs11_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hxtool-hxtool-commands.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hxtool-hxtool.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_CertificationRequest.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_CertificationRequestInfo.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPBasicOCSPResponse.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPCertID.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPCertStatus.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPInnerRequest.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPKeyHash.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPRequest.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPResponderID.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPResponse.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPResponseBytes.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPResponseData.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPResponseStatus.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPSignature.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPSingleResponse.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPTBSRequest.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_OCSPVersion.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_id_pkix_ocsp.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_id_pkix_ocsp_basic.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-asn1_id_pkix_ocsp_nonce.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-ca.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-cert.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-cms.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-collector.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-crypto.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-doxygen.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-env.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-error.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-file.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-hx509_err.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-keyset.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-ks_dir.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-ks_file.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-ks_keychain.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-ks_mem.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-ks_null.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-ks_p11.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-ks_p12.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-lock.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-name.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-peer.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-print.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-req.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-revoke.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-sel-gram.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-sel-lex.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-sel.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libhx509_la-softp11.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_expr.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_name.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_soft_pkcs11-test_soft_pkcs11.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++libhx509_la-ca.lo: ca.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-ca.lo -MD -MP -MF $(DEPDIR)/libhx509_la-ca.Tpo -c -o libhx509_la-ca.lo `test -f 'ca.c' || echo '$(srcdir)/'`ca.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-ca.Tpo $(DEPDIR)/libhx509_la-ca.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='ca.c' object='libhx509_la-ca.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-ca.lo `test -f 'ca.c' || echo '$(srcdir)/'`ca.c
++
++libhx509_la-cert.lo: cert.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-cert.lo -MD -MP -MF $(DEPDIR)/libhx509_la-cert.Tpo -c -o libhx509_la-cert.lo `test -f 'cert.c' || echo '$(srcdir)/'`cert.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-cert.Tpo $(DEPDIR)/libhx509_la-cert.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='cert.c' object='libhx509_la-cert.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-cert.lo `test -f 'cert.c' || echo '$(srcdir)/'`cert.c
++
++libhx509_la-cms.lo: cms.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-cms.lo -MD -MP -MF $(DEPDIR)/libhx509_la-cms.Tpo -c -o libhx509_la-cms.lo `test -f 'cms.c' || echo '$(srcdir)/'`cms.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-cms.Tpo $(DEPDIR)/libhx509_la-cms.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='cms.c' object='libhx509_la-cms.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-cms.lo `test -f 'cms.c' || echo '$(srcdir)/'`cms.c
++
++libhx509_la-collector.lo: collector.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-collector.lo -MD -MP -MF $(DEPDIR)/libhx509_la-collector.Tpo -c -o libhx509_la-collector.lo `test -f 'collector.c' || echo '$(srcdir)/'`collector.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-collector.Tpo $(DEPDIR)/libhx509_la-collector.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='collector.c' object='libhx509_la-collector.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-collector.lo `test -f 'collector.c' || echo '$(srcdir)/'`collector.c
++
++libhx509_la-crypto.lo: crypto.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-crypto.lo -MD -MP -MF $(DEPDIR)/libhx509_la-crypto.Tpo -c -o libhx509_la-crypto.lo `test -f 'crypto.c' || echo '$(srcdir)/'`crypto.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-crypto.Tpo $(DEPDIR)/libhx509_la-crypto.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto.c' object='libhx509_la-crypto.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-crypto.lo `test -f 'crypto.c' || echo '$(srcdir)/'`crypto.c
++
++libhx509_la-doxygen.lo: doxygen.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-doxygen.lo -MD -MP -MF $(DEPDIR)/libhx509_la-doxygen.Tpo -c -o libhx509_la-doxygen.lo `test -f 'doxygen.c' || echo '$(srcdir)/'`doxygen.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-doxygen.Tpo $(DEPDIR)/libhx509_la-doxygen.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='doxygen.c' object='libhx509_la-doxygen.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-doxygen.lo `test -f 'doxygen.c' || echo '$(srcdir)/'`doxygen.c
++
++libhx509_la-error.lo: error.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-error.lo -MD -MP -MF $(DEPDIR)/libhx509_la-error.Tpo -c -o libhx509_la-error.lo `test -f 'error.c' || echo '$(srcdir)/'`error.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-error.Tpo $(DEPDIR)/libhx509_la-error.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='error.c' object='libhx509_la-error.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-error.lo `test -f 'error.c' || echo '$(srcdir)/'`error.c
++
++libhx509_la-env.lo: env.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-env.lo -MD -MP -MF $(DEPDIR)/libhx509_la-env.Tpo -c -o libhx509_la-env.lo `test -f 'env.c' || echo '$(srcdir)/'`env.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-env.Tpo $(DEPDIR)/libhx509_la-env.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='env.c' object='libhx509_la-env.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-env.lo `test -f 'env.c' || echo '$(srcdir)/'`env.c
++
++libhx509_la-file.lo: file.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-file.lo -MD -MP -MF $(DEPDIR)/libhx509_la-file.Tpo -c -o libhx509_la-file.lo `test -f 'file.c' || echo '$(srcdir)/'`file.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-file.Tpo $(DEPDIR)/libhx509_la-file.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='file.c' object='libhx509_la-file.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-file.lo `test -f 'file.c' || echo '$(srcdir)/'`file.c
++
++libhx509_la-sel.lo: sel.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-sel.lo -MD -MP -MF $(DEPDIR)/libhx509_la-sel.Tpo -c -o libhx509_la-sel.lo `test -f 'sel.c' || echo '$(srcdir)/'`sel.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-sel.Tpo $(DEPDIR)/libhx509_la-sel.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='sel.c' object='libhx509_la-sel.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-sel.lo `test -f 'sel.c' || echo '$(srcdir)/'`sel.c
++
++libhx509_la-sel-gram.lo: sel-gram.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-sel-gram.lo -MD -MP -MF $(DEPDIR)/libhx509_la-sel-gram.Tpo -c -o libhx509_la-sel-gram.lo `test -f 'sel-gram.c' || echo '$(srcdir)/'`sel-gram.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-sel-gram.Tpo $(DEPDIR)/libhx509_la-sel-gram.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='sel-gram.c' object='libhx509_la-sel-gram.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-sel-gram.lo `test -f 'sel-gram.c' || echo '$(srcdir)/'`sel-gram.c
++
++libhx509_la-sel-lex.lo: sel-lex.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-sel-lex.lo -MD -MP -MF $(DEPDIR)/libhx509_la-sel-lex.Tpo -c -o libhx509_la-sel-lex.lo `test -f 'sel-lex.c' || echo '$(srcdir)/'`sel-lex.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-sel-lex.Tpo $(DEPDIR)/libhx509_la-sel-lex.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='sel-lex.c' object='libhx509_la-sel-lex.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-sel-lex.lo `test -f 'sel-lex.c' || echo '$(srcdir)/'`sel-lex.c
++
++libhx509_la-keyset.lo: keyset.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-keyset.lo -MD -MP -MF $(DEPDIR)/libhx509_la-keyset.Tpo -c -o libhx509_la-keyset.lo `test -f 'keyset.c' || echo '$(srcdir)/'`keyset.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-keyset.Tpo $(DEPDIR)/libhx509_la-keyset.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='keyset.c' object='libhx509_la-keyset.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-keyset.lo `test -f 'keyset.c' || echo '$(srcdir)/'`keyset.c
++
++libhx509_la-ks_dir.lo: ks_dir.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-ks_dir.lo -MD -MP -MF $(DEPDIR)/libhx509_la-ks_dir.Tpo -c -o libhx509_la-ks_dir.lo `test -f 'ks_dir.c' || echo '$(srcdir)/'`ks_dir.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-ks_dir.Tpo $(DEPDIR)/libhx509_la-ks_dir.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='ks_dir.c' object='libhx509_la-ks_dir.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-ks_dir.lo `test -f 'ks_dir.c' || echo '$(srcdir)/'`ks_dir.c
++
++libhx509_la-ks_file.lo: ks_file.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-ks_file.lo -MD -MP -MF $(DEPDIR)/libhx509_la-ks_file.Tpo -c -o libhx509_la-ks_file.lo `test -f 'ks_file.c' || echo '$(srcdir)/'`ks_file.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-ks_file.Tpo $(DEPDIR)/libhx509_la-ks_file.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='ks_file.c' object='libhx509_la-ks_file.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-ks_file.lo `test -f 'ks_file.c' || echo '$(srcdir)/'`ks_file.c
++
++libhx509_la-ks_mem.lo: ks_mem.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-ks_mem.lo -MD -MP -MF $(DEPDIR)/libhx509_la-ks_mem.Tpo -c -o libhx509_la-ks_mem.lo `test -f 'ks_mem.c' || echo '$(srcdir)/'`ks_mem.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-ks_mem.Tpo $(DEPDIR)/libhx509_la-ks_mem.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='ks_mem.c' object='libhx509_la-ks_mem.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-ks_mem.lo `test -f 'ks_mem.c' || echo '$(srcdir)/'`ks_mem.c
++
++libhx509_la-ks_null.lo: ks_null.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-ks_null.lo -MD -MP -MF $(DEPDIR)/libhx509_la-ks_null.Tpo -c -o libhx509_la-ks_null.lo `test -f 'ks_null.c' || echo '$(srcdir)/'`ks_null.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-ks_null.Tpo $(DEPDIR)/libhx509_la-ks_null.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='ks_null.c' object='libhx509_la-ks_null.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-ks_null.lo `test -f 'ks_null.c' || echo '$(srcdir)/'`ks_null.c
++
++libhx509_la-ks_p11.lo: ks_p11.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-ks_p11.lo -MD -MP -MF $(DEPDIR)/libhx509_la-ks_p11.Tpo -c -o libhx509_la-ks_p11.lo `test -f 'ks_p11.c' || echo '$(srcdir)/'`ks_p11.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-ks_p11.Tpo $(DEPDIR)/libhx509_la-ks_p11.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='ks_p11.c' object='libhx509_la-ks_p11.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-ks_p11.lo `test -f 'ks_p11.c' || echo '$(srcdir)/'`ks_p11.c
++
++libhx509_la-ks_p12.lo: ks_p12.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-ks_p12.lo -MD -MP -MF $(DEPDIR)/libhx509_la-ks_p12.Tpo -c -o libhx509_la-ks_p12.lo `test -f 'ks_p12.c' || echo '$(srcdir)/'`ks_p12.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-ks_p12.Tpo $(DEPDIR)/libhx509_la-ks_p12.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='ks_p12.c' object='libhx509_la-ks_p12.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-ks_p12.lo `test -f 'ks_p12.c' || echo '$(srcdir)/'`ks_p12.c
++
++libhx509_la-ks_keychain.lo: ks_keychain.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-ks_keychain.lo -MD -MP -MF $(DEPDIR)/libhx509_la-ks_keychain.Tpo -c -o libhx509_la-ks_keychain.lo `test -f 'ks_keychain.c' || echo '$(srcdir)/'`ks_keychain.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-ks_keychain.Tpo $(DEPDIR)/libhx509_la-ks_keychain.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='ks_keychain.c' object='libhx509_la-ks_keychain.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-ks_keychain.lo `test -f 'ks_keychain.c' || echo '$(srcdir)/'`ks_keychain.c
++
++libhx509_la-lock.lo: lock.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-lock.lo -MD -MP -MF $(DEPDIR)/libhx509_la-lock.Tpo -c -o libhx509_la-lock.lo `test -f 'lock.c' || echo '$(srcdir)/'`lock.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-lock.Tpo $(DEPDIR)/libhx509_la-lock.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='lock.c' object='libhx509_la-lock.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-lock.lo `test -f 'lock.c' || echo '$(srcdir)/'`lock.c
++
++libhx509_la-name.lo: name.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-name.lo -MD -MP -MF $(DEPDIR)/libhx509_la-name.Tpo -c -o libhx509_la-name.lo `test -f 'name.c' || echo '$(srcdir)/'`name.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-name.Tpo $(DEPDIR)/libhx509_la-name.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='name.c' object='libhx509_la-name.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-name.lo `test -f 'name.c' || echo '$(srcdir)/'`name.c
++
++libhx509_la-peer.lo: peer.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-peer.lo -MD -MP -MF $(DEPDIR)/libhx509_la-peer.Tpo -c -o libhx509_la-peer.lo `test -f 'peer.c' || echo '$(srcdir)/'`peer.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-peer.Tpo $(DEPDIR)/libhx509_la-peer.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='peer.c' object='libhx509_la-peer.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-peer.lo `test -f 'peer.c' || echo '$(srcdir)/'`peer.c
++
++libhx509_la-print.lo: print.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-print.lo -MD -MP -MF $(DEPDIR)/libhx509_la-print.Tpo -c -o libhx509_la-print.lo `test -f 'print.c' || echo '$(srcdir)/'`print.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-print.Tpo $(DEPDIR)/libhx509_la-print.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='print.c' object='libhx509_la-print.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-print.lo `test -f 'print.c' || echo '$(srcdir)/'`print.c
++
++libhx509_la-softp11.lo: softp11.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-softp11.lo -MD -MP -MF $(DEPDIR)/libhx509_la-softp11.Tpo -c -o libhx509_la-softp11.lo `test -f 'softp11.c' || echo '$(srcdir)/'`softp11.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-softp11.Tpo $(DEPDIR)/libhx509_la-softp11.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='softp11.c' object='libhx509_la-softp11.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-softp11.lo `test -f 'softp11.c' || echo '$(srcdir)/'`softp11.c
++
++libhx509_la-req.lo: req.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-req.lo -MD -MP -MF $(DEPDIR)/libhx509_la-req.Tpo -c -o libhx509_la-req.lo `test -f 'req.c' || echo '$(srcdir)/'`req.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-req.Tpo $(DEPDIR)/libhx509_la-req.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='req.c' object='libhx509_la-req.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-req.lo `test -f 'req.c' || echo '$(srcdir)/'`req.c
++
++libhx509_la-revoke.lo: revoke.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-revoke.lo -MD -MP -MF $(DEPDIR)/libhx509_la-revoke.Tpo -c -o libhx509_la-revoke.lo `test -f 'revoke.c' || echo '$(srcdir)/'`revoke.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-revoke.Tpo $(DEPDIR)/libhx509_la-revoke.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='revoke.c' object='libhx509_la-revoke.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-revoke.lo `test -f 'revoke.c' || echo '$(srcdir)/'`revoke.c
++
++libhx509_la-asn1_OCSPBasicOCSPResponse.lo: asn1_OCSPBasicOCSPResponse.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPBasicOCSPResponse.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPBasicOCSPResponse.Tpo -c -o libhx509_la-asn1_OCSPBasicOCSPResponse.lo `test -f 'asn1_OCSPBasicOCSPResponse.c' || echo '$(srcdir)/'`asn1_OCSPBasicOCSPResponse.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPBasicOCSPResponse.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPBasicOCSPResponse.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPBasicOCSPResponse.c' object='libhx509_la-asn1_OCSPBasicOCSPResponse.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPBasicOCSPResponse.lo `test -f 'asn1_OCSPBasicOCSPResponse.c' || echo '$(srcdir)/'`asn1_OCSPBasicOCSPResponse.c
++
++libhx509_la-asn1_OCSPCertID.lo: asn1_OCSPCertID.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPCertID.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPCertID.Tpo -c -o libhx509_la-asn1_OCSPCertID.lo `test -f 'asn1_OCSPCertID.c' || echo '$(srcdir)/'`asn1_OCSPCertID.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPCertID.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPCertID.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPCertID.c' object='libhx509_la-asn1_OCSPCertID.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPCertID.lo `test -f 'asn1_OCSPCertID.c' || echo '$(srcdir)/'`asn1_OCSPCertID.c
++
++libhx509_la-asn1_OCSPCertStatus.lo: asn1_OCSPCertStatus.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPCertStatus.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPCertStatus.Tpo -c -o libhx509_la-asn1_OCSPCertStatus.lo `test -f 'asn1_OCSPCertStatus.c' || echo '$(srcdir)/'`asn1_OCSPCertStatus.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPCertStatus.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPCertStatus.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPCertStatus.c' object='libhx509_la-asn1_OCSPCertStatus.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPCertStatus.lo `test -f 'asn1_OCSPCertStatus.c' || echo '$(srcdir)/'`asn1_OCSPCertStatus.c
++
++libhx509_la-asn1_OCSPInnerRequest.lo: asn1_OCSPInnerRequest.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPInnerRequest.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPInnerRequest.Tpo -c -o libhx509_la-asn1_OCSPInnerRequest.lo `test -f 'asn1_OCSPInnerRequest.c' || echo '$(srcdir)/'`asn1_OCSPInnerRequest.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPInnerRequest.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPInnerRequest.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPInnerRequest.c' object='libhx509_la-asn1_OCSPInnerRequest.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPInnerRequest.lo `test -f 'asn1_OCSPInnerRequest.c' || echo '$(srcdir)/'`asn1_OCSPInnerRequest.c
++
++libhx509_la-asn1_OCSPKeyHash.lo: asn1_OCSPKeyHash.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPKeyHash.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPKeyHash.Tpo -c -o libhx509_la-asn1_OCSPKeyHash.lo `test -f 'asn1_OCSPKeyHash.c' || echo '$(srcdir)/'`asn1_OCSPKeyHash.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPKeyHash.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPKeyHash.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPKeyHash.c' object='libhx509_la-asn1_OCSPKeyHash.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPKeyHash.lo `test -f 'asn1_OCSPKeyHash.c' || echo '$(srcdir)/'`asn1_OCSPKeyHash.c
++
++libhx509_la-asn1_OCSPRequest.lo: asn1_OCSPRequest.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPRequest.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPRequest.Tpo -c -o libhx509_la-asn1_OCSPRequest.lo `test -f 'asn1_OCSPRequest.c' || echo '$(srcdir)/'`asn1_OCSPRequest.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPRequest.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPRequest.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPRequest.c' object='libhx509_la-asn1_OCSPRequest.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPRequest.lo `test -f 'asn1_OCSPRequest.c' || echo '$(srcdir)/'`asn1_OCSPRequest.c
++
++libhx509_la-asn1_OCSPResponderID.lo: asn1_OCSPResponderID.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPResponderID.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPResponderID.Tpo -c -o libhx509_la-asn1_OCSPResponderID.lo `test -f 'asn1_OCSPResponderID.c' || echo '$(srcdir)/'`asn1_OCSPResponderID.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPResponderID.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPResponderID.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPResponderID.c' object='libhx509_la-asn1_OCSPResponderID.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPResponderID.lo `test -f 'asn1_OCSPResponderID.c' || echo '$(srcdir)/'`asn1_OCSPResponderID.c
++
++libhx509_la-asn1_OCSPResponse.lo: asn1_OCSPResponse.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPResponse.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPResponse.Tpo -c -o libhx509_la-asn1_OCSPResponse.lo `test -f 'asn1_OCSPResponse.c' || echo '$(srcdir)/'`asn1_OCSPResponse.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPResponse.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPResponse.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPResponse.c' object='libhx509_la-asn1_OCSPResponse.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPResponse.lo `test -f 'asn1_OCSPResponse.c' || echo '$(srcdir)/'`asn1_OCSPResponse.c
++
++libhx509_la-asn1_OCSPResponseBytes.lo: asn1_OCSPResponseBytes.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPResponseBytes.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPResponseBytes.Tpo -c -o libhx509_la-asn1_OCSPResponseBytes.lo `test -f 'asn1_OCSPResponseBytes.c' || echo '$(srcdir)/'`asn1_OCSPResponseBytes.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPResponseBytes.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPResponseBytes.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPResponseBytes.c' object='libhx509_la-asn1_OCSPResponseBytes.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPResponseBytes.lo `test -f 'asn1_OCSPResponseBytes.c' || echo '$(srcdir)/'`asn1_OCSPResponseBytes.c
++
++libhx509_la-asn1_OCSPResponseData.lo: asn1_OCSPResponseData.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPResponseData.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPResponseData.Tpo -c -o libhx509_la-asn1_OCSPResponseData.lo `test -f 'asn1_OCSPResponseData.c' || echo '$(srcdir)/'`asn1_OCSPResponseData.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPResponseData.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPResponseData.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPResponseData.c' object='libhx509_la-asn1_OCSPResponseData.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPResponseData.lo `test -f 'asn1_OCSPResponseData.c' || echo '$(srcdir)/'`asn1_OCSPResponseData.c
++
++libhx509_la-asn1_OCSPResponseStatus.lo: asn1_OCSPResponseStatus.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPResponseStatus.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPResponseStatus.Tpo -c -o libhx509_la-asn1_OCSPResponseStatus.lo `test -f 'asn1_OCSPResponseStatus.c' || echo '$(srcdir)/'`asn1_OCSPResponseStatus.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPResponseStatus.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPResponseStatus.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPResponseStatus.c' object='libhx509_la-asn1_OCSPResponseStatus.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPResponseStatus.lo `test -f 'asn1_OCSPResponseStatus.c' || echo '$(srcdir)/'`asn1_OCSPResponseStatus.c
++
++libhx509_la-asn1_OCSPSignature.lo: asn1_OCSPSignature.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPSignature.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPSignature.Tpo -c -o libhx509_la-asn1_OCSPSignature.lo `test -f 'asn1_OCSPSignature.c' || echo '$(srcdir)/'`asn1_OCSPSignature.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPSignature.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPSignature.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPSignature.c' object='libhx509_la-asn1_OCSPSignature.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPSignature.lo `test -f 'asn1_OCSPSignature.c' || echo '$(srcdir)/'`asn1_OCSPSignature.c
++
++libhx509_la-asn1_OCSPSingleResponse.lo: asn1_OCSPSingleResponse.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPSingleResponse.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPSingleResponse.Tpo -c -o libhx509_la-asn1_OCSPSingleResponse.lo `test -f 'asn1_OCSPSingleResponse.c' || echo '$(srcdir)/'`asn1_OCSPSingleResponse.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPSingleResponse.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPSingleResponse.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPSingleResponse.c' object='libhx509_la-asn1_OCSPSingleResponse.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPSingleResponse.lo `test -f 'asn1_OCSPSingleResponse.c' || echo '$(srcdir)/'`asn1_OCSPSingleResponse.c
++
++libhx509_la-asn1_OCSPTBSRequest.lo: asn1_OCSPTBSRequest.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPTBSRequest.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPTBSRequest.Tpo -c -o libhx509_la-asn1_OCSPTBSRequest.lo `test -f 'asn1_OCSPTBSRequest.c' || echo '$(srcdir)/'`asn1_OCSPTBSRequest.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPTBSRequest.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPTBSRequest.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPTBSRequest.c' object='libhx509_la-asn1_OCSPTBSRequest.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPTBSRequest.lo `test -f 'asn1_OCSPTBSRequest.c' || echo '$(srcdir)/'`asn1_OCSPTBSRequest.c
++
++libhx509_la-asn1_OCSPVersion.lo: asn1_OCSPVersion.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_OCSPVersion.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_OCSPVersion.Tpo -c -o libhx509_la-asn1_OCSPVersion.lo `test -f 'asn1_OCSPVersion.c' || echo '$(srcdir)/'`asn1_OCSPVersion.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_OCSPVersion.Tpo $(DEPDIR)/libhx509_la-asn1_OCSPVersion.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_OCSPVersion.c' object='libhx509_la-asn1_OCSPVersion.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_OCSPVersion.lo `test -f 'asn1_OCSPVersion.c' || echo '$(srcdir)/'`asn1_OCSPVersion.c
++
++libhx509_la-asn1_id_pkix_ocsp.lo: asn1_id_pkix_ocsp.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_id_pkix_ocsp.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_id_pkix_ocsp.Tpo -c -o libhx509_la-asn1_id_pkix_ocsp.lo `test -f 'asn1_id_pkix_ocsp.c' || echo '$(srcdir)/'`asn1_id_pkix_ocsp.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_id_pkix_ocsp.Tpo $(DEPDIR)/libhx509_la-asn1_id_pkix_ocsp.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_id_pkix_ocsp.c' object='libhx509_la-asn1_id_pkix_ocsp.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_id_pkix_ocsp.lo `test -f 'asn1_id_pkix_ocsp.c' || echo '$(srcdir)/'`asn1_id_pkix_ocsp.c
++
++libhx509_la-asn1_id_pkix_ocsp_basic.lo: asn1_id_pkix_ocsp_basic.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_id_pkix_ocsp_basic.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_id_pkix_ocsp_basic.Tpo -c -o libhx509_la-asn1_id_pkix_ocsp_basic.lo `test -f 'asn1_id_pkix_ocsp_basic.c' || echo '$(srcdir)/'`asn1_id_pkix_ocsp_basic.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_id_pkix_ocsp_basic.Tpo $(DEPDIR)/libhx509_la-asn1_id_pkix_ocsp_basic.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_id_pkix_ocsp_basic.c' object='libhx509_la-asn1_id_pkix_ocsp_basic.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_id_pkix_ocsp_basic.lo `test -f 'asn1_id_pkix_ocsp_basic.c' || echo '$(srcdir)/'`asn1_id_pkix_ocsp_basic.c
++
++libhx509_la-asn1_id_pkix_ocsp_nonce.lo: asn1_id_pkix_ocsp_nonce.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_id_pkix_ocsp_nonce.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_id_pkix_ocsp_nonce.Tpo -c -o libhx509_la-asn1_id_pkix_ocsp_nonce.lo `test -f 'asn1_id_pkix_ocsp_nonce.c' || echo '$(srcdir)/'`asn1_id_pkix_ocsp_nonce.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_id_pkix_ocsp_nonce.Tpo $(DEPDIR)/libhx509_la-asn1_id_pkix_ocsp_nonce.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_id_pkix_ocsp_nonce.c' object='libhx509_la-asn1_id_pkix_ocsp_nonce.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_id_pkix_ocsp_nonce.lo `test -f 'asn1_id_pkix_ocsp_nonce.c' || echo '$(srcdir)/'`asn1_id_pkix_ocsp_nonce.c
++
++libhx509_la-asn1_CertificationRequestInfo.lo: asn1_CertificationRequestInfo.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_CertificationRequestInfo.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_CertificationRequestInfo.Tpo -c -o libhx509_la-asn1_CertificationRequestInfo.lo `test -f 'asn1_CertificationRequestInfo.c' || echo '$(srcdir)/'`asn1_CertificationRequestInfo.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_CertificationRequestInfo.Tpo $(DEPDIR)/libhx509_la-asn1_CertificationRequestInfo.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_CertificationRequestInfo.c' object='libhx509_la-asn1_CertificationRequestInfo.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_CertificationRequestInfo.lo `test -f 'asn1_CertificationRequestInfo.c' || echo '$(srcdir)/'`asn1_CertificationRequestInfo.c
++
++libhx509_la-asn1_CertificationRequest.lo: asn1_CertificationRequest.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-asn1_CertificationRequest.lo -MD -MP -MF $(DEPDIR)/libhx509_la-asn1_CertificationRequest.Tpo -c -o libhx509_la-asn1_CertificationRequest.lo `test -f 'asn1_CertificationRequest.c' || echo '$(srcdir)/'`asn1_CertificationRequest.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-asn1_CertificationRequest.Tpo $(DEPDIR)/libhx509_la-asn1_CertificationRequest.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_CertificationRequest.c' object='libhx509_la-asn1_CertificationRequest.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-asn1_CertificationRequest.lo `test -f 'asn1_CertificationRequest.c' || echo '$(srcdir)/'`asn1_CertificationRequest.c
++
++libhx509_la-hx509_err.lo: hx509_err.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libhx509_la-hx509_err.lo -MD -MP -MF $(DEPDIR)/libhx509_la-hx509_err.Tpo -c -o libhx509_la-hx509_err.lo `test -f 'hx509_err.c' || echo '$(srcdir)/'`hx509_err.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libhx509_la-hx509_err.Tpo $(DEPDIR)/libhx509_la-hx509_err.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='hx509_err.c' object='libhx509_la-hx509_err.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libhx509_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libhx509_la-hx509_err.lo `test -f 'hx509_err.c' || echo '$(srcdir)/'`hx509_err.c
++
++hxtool-hxtool.o: hxtool.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(hxtool_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT hxtool-hxtool.o -MD -MP -MF $(DEPDIR)/hxtool-hxtool.Tpo -c -o hxtool-hxtool.o `test -f 'hxtool.c' || echo '$(srcdir)/'`hxtool.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/hxtool-hxtool.Tpo $(DEPDIR)/hxtool-hxtool.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='hxtool.c' object='hxtool-hxtool.o' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(hxtool_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o hxtool-hxtool.o `test -f 'hxtool.c' || echo '$(srcdir)/'`hxtool.c
++
++hxtool-hxtool.obj: hxtool.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(hxtool_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT hxtool-hxtool.obj -MD -MP -MF $(DEPDIR)/hxtool-hxtool.Tpo -c -o hxtool-hxtool.obj `if test -f 'hxtool.c'; then $(CYGPATH_W) 'hxtool.c'; else $(CYGPATH_W) '$(srcdir)/hxtool.c'; fi`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/hxtool-hxtool.Tpo $(DEPDIR)/hxtool-hxtool.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='hxtool.c' object='hxtool-hxtool.obj' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(hxtool_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o hxtool-hxtool.obj `if test -f 'hxtool.c'; then $(CYGPATH_W) 'hxtool.c'; else $(CYGPATH_W) '$(srcdir)/hxtool.c'; fi`
++
++hxtool-hxtool-commands.o: hxtool-commands.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(hxtool_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT hxtool-hxtool-commands.o -MD -MP -MF $(DEPDIR)/hxtool-hxtool-commands.Tpo -c -o hxtool-hxtool-commands.o `test -f 'hxtool-commands.c' || echo '$(srcdir)/'`hxtool-commands.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/hxtool-hxtool-commands.Tpo $(DEPDIR)/hxtool-hxtool-commands.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='hxtool-commands.c' object='hxtool-hxtool-commands.o' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(hxtool_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o hxtool-hxtool-commands.o `test -f 'hxtool-commands.c' || echo '$(srcdir)/'`hxtool-commands.c
++
++hxtool-hxtool-commands.obj: hxtool-commands.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(hxtool_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT hxtool-hxtool-commands.obj -MD -MP -MF $(DEPDIR)/hxtool-hxtool-commands.Tpo -c -o hxtool-hxtool-commands.obj `if test -f 'hxtool-commands.c'; then $(CYGPATH_W) 'hxtool-commands.c'; else $(CYGPATH_W) '$(srcdir)/hxtool-commands.c'; fi`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/hxtool-hxtool-commands.Tpo $(DEPDIR)/hxtool-hxtool-commands.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='hxtool-commands.c' object='hxtool-hxtool-commands.obj' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(hxtool_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o hxtool-hxtool-commands.obj `if test -f 'hxtool-commands.c'; then $(CYGPATH_W) 'hxtool-commands.c'; else $(CYGPATH_W) '$(srcdir)/hxtool-commands.c'; fi`
++
++test_soft_pkcs11-test_soft_pkcs11.o: test_soft_pkcs11.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(test_soft_pkcs11_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT test_soft_pkcs11-test_soft_pkcs11.o -MD -MP -MF $(DEPDIR)/test_soft_pkcs11-test_soft_pkcs11.Tpo -c -o test_soft_pkcs11-test_soft_pkcs11.o `test -f 'test_soft_pkcs11.c' || echo '$(srcdir)/'`test_soft_pkcs11.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/test_soft_pkcs11-test_soft_pkcs11.Tpo $(DEPDIR)/test_soft_pkcs11-test_soft_pkcs11.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='test_soft_pkcs11.c' object='test_soft_pkcs11-test_soft_pkcs11.o' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(test_soft_pkcs11_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o test_soft_pkcs11-test_soft_pkcs11.o `test -f 'test_soft_pkcs11.c' || echo '$(srcdir)/'`test_soft_pkcs11.c
++
++test_soft_pkcs11-test_soft_pkcs11.obj: test_soft_pkcs11.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(test_soft_pkcs11_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT test_soft_pkcs11-test_soft_pkcs11.obj -MD -MP -MF $(DEPDIR)/test_soft_pkcs11-test_soft_pkcs11.Tpo -c -o test_soft_pkcs11-test_soft_pkcs11.obj `if test -f 'test_soft_pkcs11.c'; then $(CYGPATH_W) 'test_soft_pkcs11.c'; else $(CYGPATH_W) '$(srcdir)/test_soft_pkcs11.c'; fi`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/test_soft_pkcs11-test_soft_pkcs11.Tpo $(DEPDIR)/test_soft_pkcs11-test_soft_pkcs11.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='test_soft_pkcs11.c' object='test_soft_pkcs11-test_soft_pkcs11.obj' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(test_soft_pkcs11_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o test_soft_pkcs11-test_soft_pkcs11.obj `if test -f 'test_soft_pkcs11.c'; then $(CYGPATH_W) 'test_soft_pkcs11.c'; else $(CYGPATH_W) '$(srcdir)/test_soft_pkcs11.c'; fi`
++
++.l.c:
++	$(am__skiplex) $(SHELL) $(YLWRAP) $< $(LEX_OUTPUT_ROOT).c $@ -- $(LEXCOMPILE)
++
++.y.c:
++	$(am__skipyacc) $(SHELL) $(YLWRAP) $< y.tab.c $@ y.tab.h $*.h y.output $*.output -- $(YACCCOMPILE)
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-dist_includeHEADERS: $(dist_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(dist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-dist_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(dist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++install-nodist_includeHEADERS: $(nodist_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-nodist_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS) $(check_SCRIPTS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(HEADERS) all-local
++install-binPROGRAMS: install-libLTLIBRARIES
++
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(bindir)" "$(DESTDIR)$(includedir)" "$(DESTDIR)$(includedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++	-rm -f sel-gram.c
++	-rm -f sel-gram.h
++	-rm -f sel-lex.c
++	-test -z "$(BUILT_SOURCES)" || rm -f $(BUILT_SOURCES)
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-checkPROGRAMS clean-generic \
++	clean-libLTLIBRARIES clean-libtool clean-local mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-dist_includeHEADERS \
++	install-nodist_includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-dist_includeHEADERS \
++	uninstall-libLTLIBRARIES uninstall-nodist_includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: all check check-am install install-am install-data-am \
++	install-exec-am install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-TESTS check-am \
++	check-local clean clean-binPROGRAMS clean-checkPROGRAMS \
++	clean-generic clean-libLTLIBRARIES clean-libtool clean-local \
++	ctags dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-binPROGRAMS \
++	install-data install-data-am install-data-hook \
++	install-dist_includeHEADERS install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am \
++	install-libLTLIBRARIES install-man \
++	install-nodist_includeHEADERS install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-binPROGRAMS \
++	uninstall-dist_includeHEADERS uninstall-hook \
++	uninstall-libLTLIBRARIES uninstall-nodist_includeHEADERS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++sel-lex.c: sel-gram.h
++$(libhx509_la_OBJECTS): $(srcdir)/version-script.map $(nodist_include_HEADERS) $(priv_headers)
++
++$(gen_files_ocsp) ocsp_asn1.hx ocsp_asn1-priv.hx: ocsp_asn1_files
++$(gen_files_pkcs10) pkcs10_asn1.hx pkcs10_asn1-priv.hx: pkcs10_asn1_files
++$(gen_files_crmf) crmf_asn1.hx crmf_asn1-priv.hx: crmf_asn1_files
++
++ocsp_asn1_files: $(ASN1_COMPILE_DEP) $(srcdir)/ocsp.asn1 $(srcdir)/ocsp.opt
++	$(ASN1_COMPILE) --option-file=$(srcdir)/ocsp.opt $(srcdir)/ocsp.asn1 ocsp_asn1 || (rm -f ocsp_asn1_files ; exit 1)
++
++pkcs10_asn1_files: $(ASN1_COMPILE_DEP) $(srcdir)/pkcs10.asn1 $(srcdir)/pkcs10.opt
++	$(ASN1_COMPILE) --option-file=$(srcdir)/pkcs10.opt $(srcdir)/pkcs10.asn1 pkcs10_asn1 || (rm -f pkcs10_asn1_files ; exit 1)
++
++crmf_asn1_files: $(ASN1_COMPILE_DEP) $(srcdir)/crmf.asn1
++	$(ASN1_COMPILE) $(srcdir)/crmf.asn1 crmf_asn1 || (rm -f crmf_asn1_files ; exit 1)
++
++$(libhx509_la_OBJECTS): $(srcdir)/hx509-protos.h $(srcdir)/hx509-private.h $(srcdir)/hx_locl.h
++$(libhx509_la_OBJECTS): ocsp_asn1.h pkcs10_asn1.h
++
++$(srcdir)/hx509-protos.h:
++	cd $(srcdir) && perl ../../cf/make-proto.pl -R '^(_|^C)' -E HX509_LIB -q -P comment -o hx509-protos.h $(dist_libhx509_la_SOURCES) || rm -f hx509-protos.h
++
++$(srcdir)/hx509-private.h:
++	cd $(srcdir) && perl ../../cf/make-proto.pl -q -P comment -p hx509-private.h $(dist_libhx509_la_SOURCES) || rm -f hx509-private.h
++
++hxtool-commands.c hxtool-commands.h: hxtool-commands.in $(SLC)
++	$(SLC) $(srcdir)/hxtool-commands.in
++
++$(hxtool_OBJECTS): hxtool-commands.h
++
++clean-local:
++	@echo "cleaning PKITS" ; rm -rf PKITS_data
++
++test_ca: test_ca.in Makefile
++	$(do_subst) < $(srcdir)/test_ca.in > test_ca.tmp
++	chmod +x test_ca.tmp
++	mv test_ca.tmp test_ca
++
++test_cert: test_cert.in Makefile
++	$(do_subst) < $(srcdir)/test_cert.in > test_cert.tmp
++	chmod +x test_cert.tmp
++	mv test_cert.tmp test_cert
++
++test_chain: test_chain.in Makefile
++	$(do_subst) < $(srcdir)/test_chain.in > test_chain.tmp
++	chmod +x test_chain.tmp
++	mv test_chain.tmp test_chain
++
++test_cms: test_cms.in Makefile
++	$(do_subst) < $(srcdir)/test_cms.in > test_cms.tmp
++	chmod +x test_cms.tmp
++	mv test_cms.tmp test_cms
++
++test_crypto: test_crypto.in Makefile
++	$(do_subst) < $(srcdir)/test_crypto.in > test_crypto.tmp
++	chmod +x test_crypto.tmp
++	mv test_crypto.tmp test_crypto
++
++test_nist: test_nist.in Makefile
++	$(do_subst) < $(srcdir)/test_nist.in > test_nist.tmp
++	chmod +x test_nist.tmp
++	mv test_nist.tmp test_nist
++
++test_nist2: test_nist2.in Makefile
++	$(do_subst) < $(srcdir)/test_nist2.in > test_nist2.tmp
++	chmod +x test_nist2.tmp
++	mv test_nist2.tmp test_nist2
++
++test_pkcs11: test_pkcs11.in Makefile
++	$(do_subst) < $(srcdir)/test_pkcs11.in > test_pkcs11.tmp
++	chmod +x test_pkcs11.tmp
++	mv test_pkcs11.tmp test_pkcs11
++
++test_java_pkcs11: test_java_pkcs11.in Makefile
++	$(do_subst) < $(srcdir)/test_java_pkcs11.in > test_java_pkcs11.tmp
++	chmod +x test_java_pkcs11.tmp
++	mv test_java_pkcs11.tmp test_java_pkcs11
++
++test_nist_cert: test_nist_cert.in Makefile
++	$(do_subst) < $(srcdir)/test_nist_cert.in > test_nist_cert.tmp
++	chmod +x test_nist_cert.tmp
++	mv test_nist_cert.tmp test_nist_cert
++
++test_nist_pkcs12: test_nist_pkcs12.in Makefile
++	$(do_subst) < $(srcdir)/test_nist_pkcs12.in > test_nist_pkcs12.tmp
++	chmod +x test_nist_pkcs12.tmp
++	mv test_nist_pkcs12.tmp test_nist_pkcs12
++
++test_req: test_req.in Makefile
++	$(do_subst) < $(srcdir)/test_req.in > test_req.tmp
++	chmod +x test_req.tmp
++	mv test_req.tmp test_req
++
++test_windows: test_windows.in Makefile
++	$(do_subst) < $(srcdir)/test_windows.in > test_windows.tmp
++	chmod +x test_windows.tmp
++	mv test_windows.tmp test_windows
++
++test_query: test_query.in Makefile
++	$(do_subst) < $(srcdir)/test_query.in > test_query.tmp
++	chmod +x test_query.tmp
++	mv test_query.tmp test_query
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/ipc/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/ipc/Makefile.in	2010-12-29 04:07:11.476777308 +0100
+@@ -0,0 +1,1066 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(include_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++TESTS =
++noinst_PROGRAMS = tc$(EXEEXT) ts$(EXEEXT) ts-http$(EXEEXT)
++@have_gcd_TRUE@am__append_1 = -lbsm
++subdir = lib/ipc
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++LTLIBRARIES = $(noinst_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++libheim_ipcc_la_DEPENDENCIES = $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++dist_libheim_ipcc_la_OBJECTS = client.lo common.lo
++@have_gcd_TRUE@am__objects_1 = heim_ipcUser.lo heim_ipc_asyncServer.lo
++@have_gcd_TRUE@nodist_libheim_ipcc_la_OBJECTS = $(am__objects_1)
++libheim_ipcc_la_OBJECTS = $(dist_libheim_ipcc_la_OBJECTS) \
++	$(nodist_libheim_ipcc_la_OBJECTS)
++am__DEPENDENCIES_2 = $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++libheim_ipcs_la_DEPENDENCIES = $(am__DEPENDENCIES_2) \
++	$(am__DEPENDENCIES_1)
++dist_libheim_ipcs_la_OBJECTS = server.lo common.lo
++@have_gcd_TRUE@am__objects_2 = heim_ipcServer.lo heim_ipc_asyncUser.lo \
++@have_gcd_TRUE@	heim_ipc_replyUser.lo
++@have_gcd_TRUE@nodist_libheim_ipcs_la_OBJECTS = $(am__objects_2)
++libheim_ipcs_la_OBJECTS = $(dist_libheim_ipcs_la_OBJECTS) \
++	$(nodist_libheim_ipcs_la_OBJECTS)
++PROGRAMS = $(noinst_PROGRAMS)
++tc_SOURCES = tc.c
++tc_OBJECTS = tc.$(OBJEXT)
++tc_DEPENDENCIES = libheim-ipcc.la $(am__DEPENDENCIES_1)
++ts_SOURCES = ts.c
++ts_OBJECTS = ts.$(OBJEXT)
++ts_DEPENDENCIES = libheim-ipcs.la $(am__DEPENDENCIES_1)
++ts_http_SOURCES = ts-http.c
++ts_http_OBJECTS = ts-http.$(OBJEXT)
++am__DEPENDENCIES_3 = libheim-ipcs.la $(am__DEPENDENCIES_1)
++ts_http_DEPENDENCIES = $(am__DEPENDENCIES_3)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(dist_libheim_ipcc_la_SOURCES) \
++	$(nodist_libheim_ipcc_la_SOURCES) \
++	$(dist_libheim_ipcs_la_SOURCES) \
++	$(nodist_libheim_ipcs_la_SOURCES) tc.c ts.c ts-http.c
++DIST_SOURCES = $(dist_libheim_ipcc_la_SOURCES) \
++	$(dist_libheim_ipcs_la_SOURCES) tc.c ts.c ts-http.c
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(includedir)"
++HEADERS = $(include_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++noinst_LTLIBRARIES = libheim-ipcc.la libheim-ipcs.la
++dist_libheim_ipcc_la_SOURCES = hi_locl.h heim_ipc_types.h client.c common.c
++dist_libheim_ipcs_la_SOURCES = hi_locl.h heim_ipc_types.h server.c common.c
++include_HEADERS = heim-ipc.h
++
++#libheim_ipcc_la_LDFLAGS = -version-info 0:0:0
++#libheim_ipcs_la_LDFLAGS = -version-info 0:0:0
++#
++#if versionscript
++#libheim_ipcc_la_LDFLAGS += $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-scriptc.map
++#libheim_ipcs_la_LDFLAGS += $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-scripts.map
++#endif
++libheim_ipcc_la_LIBADD = \
++	$(LIB_roken) \
++	$(PTHREAD_LIBADD)
++
++libheim_ipcs_la_LIBADD = $(libheim_ipcc_la_LIBADD) $(am__append_1)
++ts_LDADD = libheim-ipcs.la $(LIB_roken)
++ts_http_LDADD = $(ts_LDADD)
++tc_LDADD = libheim-ipcc.la $(LIB_roken)
++@have_gcd_TRUE@EXTRA_DIST = heim_ipc.defs heim_ipc_async.defs heim_ipc_reply.defs
++@have_gcd_TRUE@built_ipcc = heim_ipc.h heim_ipcUser.c \
++@have_gcd_TRUE@	heim_ipc_asyncServer.c heim_ipc_asyncServer.h
++@have_gcd_TRUE@nodist_libheim_ipcc_la_SOURCES = $(built_ipcc)
++@have_gcd_TRUE@built_ipcs = heim_ipcServer.c heim_ipcServer.h \
++@have_gcd_TRUE@	heim_ipc_asyncUser.c heim_ipc_async.h \
++@have_gcd_TRUE@	heim_ipc_reply.h heim_ipc_replyUser.c
++@have_gcd_TRUE@nodist_libheim_ipcs_la_SOURCES = $(built_ipcs)
++@have_gcd_TRUE@CLEANFILES = $(built_ipcc) $(built_ipcs)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/ipc/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/ipc/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++clean-noinstLTLIBRARIES:
++	-test -z "$(noinst_LTLIBRARIES)" || rm -f $(noinst_LTLIBRARIES)
++	@list='$(noinst_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libheim-ipcc.la: $(libheim_ipcc_la_OBJECTS) $(libheim_ipcc_la_DEPENDENCIES) 
++	$(LINK)  $(libheim_ipcc_la_OBJECTS) $(libheim_ipcc_la_LIBADD) $(LIBS)
++libheim-ipcs.la: $(libheim_ipcs_la_OBJECTS) $(libheim_ipcs_la_DEPENDENCIES) 
++	$(LINK)  $(libheim_ipcs_la_OBJECTS) $(libheim_ipcs_la_LIBADD) $(LIBS)
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++tc$(EXEEXT): $(tc_OBJECTS) $(tc_DEPENDENCIES) 
++	@rm -f tc$(EXEEXT)
++	$(LINK) $(tc_OBJECTS) $(tc_LDADD) $(LIBS)
++ts$(EXEEXT): $(ts_OBJECTS) $(ts_DEPENDENCIES) 
++	@rm -f ts$(EXEEXT)
++	$(LINK) $(ts_OBJECTS) $(ts_LDADD) $(LIBS)
++ts-http$(EXEEXT): $(ts_http_OBJECTS) $(ts_http_DEPENDENCIES) 
++	@rm -f ts-http$(EXEEXT)
++	$(LINK) $(ts_http_OBJECTS) $(ts_http_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/client.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/common.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/heim_ipcServer.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/heim_ipcUser.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/heim_ipc_asyncServer.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/heim_ipc_asyncUser.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/heim_ipc_replyUser.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/server.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/tc.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ts-http.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ts.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-includeHEADERS: $(include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(HEADERS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(includedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool clean-noinstLTLIBRARIES \
++	clean-noinstPROGRAMS mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-TESTS check-am \
++	check-local clean clean-generic clean-libtool \
++	clean-noinstLTLIBRARIES clean-noinstPROGRAMS ctags dist-hook \
++	distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-includeHEADERS install-info \
++	install-info-am install-man install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-hook \
++	uninstall-includeHEADERS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++@have_gcd_TRUE@heim_ipc.h heim_ipcUser.c heim_ipcServer.c heim_ipcServer.h: heim_ipc.defs
++@have_gcd_TRUE@	mig -header heim_ipc.h -user heim_ipcUser.c -sheader heim_ipcServer.h -server heim_ipcServer.c -I$(srcdir) $(srcdir)/heim_ipc.defs
++
++@have_gcd_TRUE@heim_ipc_async.h heim_ipc_asyncUser.c heim_ipc_asyncServer.c heim_ipc_asyncServer.h: heim_ipc_async.defs
++@have_gcd_TRUE@	mig -header heim_ipc_async.h -user heim_ipc_asyncUser.c -sheader heim_ipc_asyncServer.h -server heim_ipc_asyncServer.c -I$(srcdir) $(srcdir)/heim_ipc_async.defs
++
++@have_gcd_TRUE@heim_ipc_reply.h heim_ipc_replyUser.c: heim_ipc_reply.defs
++@have_gcd_TRUE@	mig -header heim_ipc_reply.h -user heim_ipc_replyUser.c -sheader /dev/null -server /dev/null -I$(srcdir) $(srcdir)/heim_ipc_reply.defs
++
++@have_gcd_TRUE@$(srcdir)/client.c: $(built_ipcc)
++@have_gcd_TRUE@$(srcdir)/server.c: $(built_ipcs)
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/kadm5/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/kadm5/Makefile.in	2010-12-29 04:07:11.806880308 +0100
+@@ -0,0 +1,1464 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(dist_kadm5include_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++@versionscript_TRUE@am__append_1 = $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-script.map
++sbin_PROGRAMS = iprop-log$(EXEEXT)
++check_PROGRAMS = default_keys$(EXEEXT)
++noinst_PROGRAMS = test_pw_quality$(EXEEXT)
++libexec_PROGRAMS = ipropd-master$(EXEEXT) ipropd-slave$(EXEEXT)
++subdir = lib/kadm5
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(libexecdir)" \
++	"$(DESTDIR)$(sbindir)" "$(DESTDIR)$(man3dir)" \
++	"$(DESTDIR)$(man8dir)" "$(DESTDIR)$(kadm5includedir)" \
++	"$(DESTDIR)$(kadm5includedir)"
++LTLIBRARIES = $(lib_LTLIBRARIES) $(noinst_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++libkadm5clnt_la_DEPENDENCIES = $(am__DEPENDENCIES_1) \
++	../krb5/libkrb5.la $(am__DEPENDENCIES_1)
++dist_libkadm5clnt_la_OBJECTS = ad.lo chpass_c.lo client_glue.lo \
++	common_glue.lo create_c.lo delete_c.lo destroy_c.lo flush_c.lo \
++	free.lo get_c.lo get_princs_c.lo init_c.lo marshall.lo \
++	modify_c.lo privs_c.lo randkey_c.lo rename_c.lo send_recv.lo
++nodist_libkadm5clnt_la_OBJECTS = kadm5_err.lo
++libkadm5clnt_la_OBJECTS = $(dist_libkadm5clnt_la_OBJECTS) \
++	$(nodist_libkadm5clnt_la_OBJECTS)
++libkadm5clnt_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libkadm5clnt_la_LDFLAGS) $(LDFLAGS) -o $@
++libkadm5srv_la_DEPENDENCIES = $(am__DEPENDENCIES_1) ../krb5/libkrb5.la \
++	../hdb/libhdb.la $(am__DEPENDENCIES_1)
++dist_libkadm5srv_la_OBJECTS = acl.lo bump_pw_expire.lo chpass_s.lo \
++	common_glue.lo context_s.lo create_s.lo delete_s.lo \
++	destroy_s.lo ent_setup.lo error.lo flush_s.lo free.lo \
++	get_princs_s.lo get_s.lo init_s.lo keys.lo log.lo marshall.lo \
++	modify_s.lo password_quality.lo privs_s.lo randkey_s.lo \
++	rename_s.lo server_glue.lo set_keys.lo set_modifier.lo
++nodist_libkadm5srv_la_OBJECTS = kadm5_err.lo
++libkadm5srv_la_OBJECTS = $(dist_libkadm5srv_la_OBJECTS) \
++	$(nodist_libkadm5srv_la_OBJECTS)
++libkadm5srv_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libkadm5srv_la_LDFLAGS) $(LDFLAGS) -o $@
++sample_passwd_check_la_LIBADD =
++am_sample_passwd_check_la_OBJECTS = sample_passwd_check.lo
++sample_passwd_check_la_OBJECTS = $(am_sample_passwd_check_la_OBJECTS)
++sample_passwd_check_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(sample_passwd_check_la_LDFLAGS) $(LDFLAGS) -o $@
++PROGRAMS = $(libexec_PROGRAMS) $(noinst_PROGRAMS) $(sbin_PROGRAMS)
++am_default_keys_OBJECTS = default_keys.$(OBJEXT)
++default_keys_OBJECTS = $(am_default_keys_OBJECTS)
++default_keys_LDADD = $(LDADD)
++default_keys_DEPENDENCIES = libkadm5srv.la \
++	$(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++dist_iprop_log_OBJECTS = iprop-log.$(OBJEXT)
++nodist_iprop_log_OBJECTS = iprop-commands.$(OBJEXT)
++iprop_log_OBJECTS = $(dist_iprop_log_OBJECTS) \
++	$(nodist_iprop_log_OBJECTS)
++iprop_log_DEPENDENCIES = libkadm5srv.la \
++	$(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/sl/libsl.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++am_ipropd_master_OBJECTS = ipropd_master.$(OBJEXT) \
++	ipropd_common.$(OBJEXT)
++ipropd_master_OBJECTS = $(am_ipropd_master_OBJECTS)
++ipropd_master_LDADD = $(LDADD)
++ipropd_master_DEPENDENCIES = libkadm5srv.la \
++	$(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++am_ipropd_slave_OBJECTS = ipropd_slave.$(OBJEXT) \
++	ipropd_common.$(OBJEXT)
++ipropd_slave_OBJECTS = $(am_ipropd_slave_OBJECTS)
++ipropd_slave_LDADD = $(LDADD)
++ipropd_slave_DEPENDENCIES = libkadm5srv.la \
++	$(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++test_pw_quality_SOURCES = test_pw_quality.c
++test_pw_quality_OBJECTS = test_pw_quality.$(OBJEXT)
++test_pw_quality_LDADD = $(LDADD)
++test_pw_quality_DEPENDENCIES = libkadm5srv.la \
++	$(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/asn1/libasn1.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(dist_libkadm5clnt_la_SOURCES) \
++	$(nodist_libkadm5clnt_la_SOURCES) \
++	$(dist_libkadm5srv_la_SOURCES) \
++	$(nodist_libkadm5srv_la_SOURCES) \
++	$(sample_passwd_check_la_SOURCES) $(default_keys_SOURCES) \
++	$(dist_iprop_log_SOURCES) $(nodist_iprop_log_SOURCES) \
++	$(ipropd_master_SOURCES) $(ipropd_slave_SOURCES) \
++	test_pw_quality.c
++DIST_SOURCES = $(dist_libkadm5clnt_la_SOURCES) \
++	$(dist_libkadm5srv_la_SOURCES) \
++	$(sample_passwd_check_la_SOURCES) $(default_keys_SOURCES) \
++	$(dist_iprop_log_SOURCES) $(ipropd_master_SOURCES) \
++	$(ipropd_slave_SOURCES) test_pw_quality.c
++man3dir = $(mandir)/man3
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++HEADERS = $(dist_kadm5include_HEADERS) $(nodist_kadm5include_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++lib_LTLIBRARIES = libkadm5srv.la libkadm5clnt.la
++libkadm5srv_la_LDFLAGS = -version-info 8:1:0 $(am__append_1)
++libkadm5clnt_la_LDFLAGS = -version-info 7:1:0
++noinst_LTLIBRARIES = sample_passwd_check.la
++sample_passwd_check_la_SOURCES = sample_passwd_check.c
++sample_passwd_check_la_LDFLAGS = -module
++libkadm5srv_la_LIBADD = \
++	$(LIB_com_err) ../krb5/libkrb5.la \
++	../hdb/libhdb.la $(LIBADD_roken)
++
++libkadm5clnt_la_LIBADD = \
++	$(LIB_com_err) ../krb5/libkrb5.la $(LIBADD_roken)
++
++default_keys_SOURCES = default_keys.c
++kadm5includedir = $(includedir)/kadm5
++buildkadm5include = $(buildinclude)/kadm5
++dist_kadm5include_HEADERS = admin.h private.h kadm5-pwcheck.h \
++	kadm5-protos.h kadm5-private.h
++nodist_kadm5include_HEADERS = kadm5_err.h
++dist_libkadm5clnt_la_SOURCES = \
++	ad.c					\
++	chpass_c.c				\
++	client_glue.c				\
++	common_glue.c				\
++	create_c.c				\
++	delete_c.c				\
++	destroy_c.c				\
++	flush_c.c				\
++	free.c					\
++	get_c.c					\
++	get_princs_c.c				\
++	init_c.c				\
++	kadm5_locl.h				\
++	marshall.c				\
++	modify_c.c				\
++	private.h				\
++	privs_c.c				\
++	randkey_c.c				\
++	rename_c.c				\
++	send_recv.c				\
++	admin.h
++
++nodist_libkadm5clnt_la_SOURCES = \
++	kadm5_err.c				\
++	kadm5_err.h
++
++dist_libkadm5srv_la_SOURCES = \
++	acl.c					\
++	admin.h					\
++	bump_pw_expire.c			\
++	chpass_s.c				\
++	common_glue.c				\
++	context_s.c				\
++	create_s.c				\
++	delete_s.c				\
++	destroy_s.c				\
++	ent_setup.c				\
++	error.c					\
++	flush_s.c				\
++	free.c					\
++	get_princs_s.c				\
++	get_s.c					\
++	init_s.c				\
++	kadm5_locl.h				\
++	keys.c					\
++	log.c					\
++	marshall.c				\
++	modify_s.c				\
++	password_quality.c			\
++	private.h				\
++	privs_s.c				\
++	randkey_s.c				\
++	rename_s.c				\
++	server_glue.c				\
++	set_keys.c				\
++	set_modifier.c				\
++	admin.h
++
++nodist_libkadm5srv_la_SOURCES = \
++	kadm5_err.c				\
++	kadm5_err.h
++
++dist_iprop_log_SOURCES = iprop-log.c
++nodist_iprop_log_SOURCES = iprop-commands.c
++ipropd_master_SOURCES = ipropd_master.c ipropd_common.c iprop.h kadm5_locl.h
++ipropd_slave_SOURCES = ipropd_slave.c ipropd_common.c iprop.h kadm5_locl.h
++man_MANS = kadm5_pwcheck.3 iprop.8 iprop-log.8
++LDADD = \
++	libkadm5srv.la \
++	$(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_hcrypto) \
++	$(LIB_roken) \
++	$(DBLIB) \
++	$(LIB_dlopen) \
++	$(LIB_pidfile)
++
++iprop_log_LDADD = \
++	libkadm5srv.la \
++	$(top_builddir)/lib/hdb/libhdb.la \
++	$(top_builddir)/lib/krb5/libkrb5.la \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/sl/libsl.la \
++	$(LIB_readline) \
++	$(LIB_roken) \
++	$(DBLIB) \
++	$(LIB_dlopen) \
++	$(LIB_pidfile)
++
++CLEANFILES = kadm5_err.c kadm5_err.h iprop-commands.h iprop-commands.c
++proto_opts = -q -R '^(_|kadm5_c_|kadm5_s_|kadm5_log)' -P comment
++EXTRA_DIST = \
++	kadm5_err.et \
++	iprop-commands.in \
++	$(man_MANS) \
++	check-cracklib.pl \
++	flush.c \
++	sample_passwd_check.c \
++	version-script.map
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/kadm5/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/kadm5/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++
++clean-noinstLTLIBRARIES:
++	-test -z "$(noinst_LTLIBRARIES)" || rm -f $(noinst_LTLIBRARIES)
++	@list='$(noinst_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libkadm5clnt.la: $(libkadm5clnt_la_OBJECTS) $(libkadm5clnt_la_DEPENDENCIES) 
++	$(libkadm5clnt_la_LINK) -rpath $(libdir) $(libkadm5clnt_la_OBJECTS) $(libkadm5clnt_la_LIBADD) $(LIBS)
++libkadm5srv.la: $(libkadm5srv_la_OBJECTS) $(libkadm5srv_la_DEPENDENCIES) 
++	$(libkadm5srv_la_LINK) -rpath $(libdir) $(libkadm5srv_la_OBJECTS) $(libkadm5srv_la_LIBADD) $(LIBS)
++sample_passwd_check.la: $(sample_passwd_check_la_OBJECTS) $(sample_passwd_check_la_DEPENDENCIES) 
++	$(sample_passwd_check_la_LINK)  $(sample_passwd_check_la_OBJECTS) $(sample_passwd_check_la_LIBADD) $(LIBS)
++
++clean-checkPROGRAMS:
++	@list='$(check_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++install-libexecPROGRAMS: $(libexec_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexecdir)" || $(MKDIR_P) "$(DESTDIR)$(libexecdir)"
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexecdir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexecdir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexecPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_PROGRAMS)'; test -n "$(libexecdir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexecdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexecdir)" && rm -f $$files
++
++clean-libexecPROGRAMS:
++	@list='$(libexec_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++install-sbinPROGRAMS: $(sbin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(sbindir)" || $(MKDIR_P) "$(DESTDIR)$(sbindir)"
++	@list='$(sbin_PROGRAMS)'; test -n "$(sbindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(sbindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(sbindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-sbinPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(sbin_PROGRAMS)'; test -n "$(sbindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(sbindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(sbindir)" && rm -f $$files
++
++clean-sbinPROGRAMS:
++	@list='$(sbin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++default_keys$(EXEEXT): $(default_keys_OBJECTS) $(default_keys_DEPENDENCIES) 
++	@rm -f default_keys$(EXEEXT)
++	$(LINK) $(default_keys_OBJECTS) $(default_keys_LDADD) $(LIBS)
++iprop-log$(EXEEXT): $(iprop_log_OBJECTS) $(iprop_log_DEPENDENCIES) 
++	@rm -f iprop-log$(EXEEXT)
++	$(LINK) $(iprop_log_OBJECTS) $(iprop_log_LDADD) $(LIBS)
++ipropd-master$(EXEEXT): $(ipropd_master_OBJECTS) $(ipropd_master_DEPENDENCIES) 
++	@rm -f ipropd-master$(EXEEXT)
++	$(LINK) $(ipropd_master_OBJECTS) $(ipropd_master_LDADD) $(LIBS)
++ipropd-slave$(EXEEXT): $(ipropd_slave_OBJECTS) $(ipropd_slave_DEPENDENCIES) 
++	@rm -f ipropd-slave$(EXEEXT)
++	$(LINK) $(ipropd_slave_OBJECTS) $(ipropd_slave_LDADD) $(LIBS)
++test_pw_quality$(EXEEXT): $(test_pw_quality_OBJECTS) $(test_pw_quality_DEPENDENCIES) 
++	@rm -f test_pw_quality$(EXEEXT)
++	$(LINK) $(test_pw_quality_OBJECTS) $(test_pw_quality_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/acl.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ad.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/bump_pw_expire.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/chpass_c.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/chpass_s.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/client_glue.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/common_glue.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/context_s.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/create_c.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/create_s.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/default_keys.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/delete_c.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/delete_s.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/destroy_c.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/destroy_s.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ent_setup.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/error.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/flush_c.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/flush_s.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/free.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/get_c.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/get_princs_c.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/get_princs_s.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/get_s.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/init_c.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/init_s.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/iprop-commands.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/iprop-log.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ipropd_common.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ipropd_master.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ipropd_slave.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/kadm5_err.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/keys.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/log.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/marshall.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/modify_c.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/modify_s.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/password_quality.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/privs_c.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/privs_s.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/randkey_c.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/randkey_s.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/rename_c.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/rename_s.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/sample_passwd_check.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/send_recv.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/server_glue.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/set_keys.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/set_modifier.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_pw_quality.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man3: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man3dir)" || $(MKDIR_P) "$(DESTDIR)$(man3dir)"
++	@list=''; test -n "$(man3dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.3[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^3][0-9a-z]*$$,3,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man3dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man3dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man3dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man3dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man3:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man3dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.3[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^3][0-9a-z]*$$,3,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man3dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man3dir)" && rm -f $$files; }
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++install-dist_kadm5includeHEADERS: $(dist_kadm5include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(kadm5includedir)" || $(MKDIR_P) "$(DESTDIR)$(kadm5includedir)"
++	@list='$(dist_kadm5include_HEADERS)'; test -n "$(kadm5includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(kadm5includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(kadm5includedir)" || exit $$?; \
++	done
++
++uninstall-dist_kadm5includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(dist_kadm5include_HEADERS)'; test -n "$(kadm5includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(kadm5includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(kadm5includedir)" && rm -f $$files
++install-nodist_kadm5includeHEADERS: $(nodist_kadm5include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(kadm5includedir)" || $(MKDIR_P) "$(DESTDIR)$(kadm5includedir)"
++	@list='$(nodist_kadm5include_HEADERS)'; test -n "$(kadm5includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(kadm5includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(kadm5includedir)" || exit $$?; \
++	done
++
++uninstall-nodist_kadm5includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(nodist_kadm5include_HEADERS)'; test -n "$(kadm5includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(kadm5includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(kadm5includedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(MANS) $(HEADERS) \
++		all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(libexecdir)" "$(DESTDIR)$(sbindir)" "$(DESTDIR)$(man3dir)" "$(DESTDIR)$(man8dir)" "$(DESTDIR)$(kadm5includedir)" "$(DESTDIR)$(kadm5includedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-checkPROGRAMS clean-generic clean-libLTLIBRARIES \
++	clean-libexecPROGRAMS clean-libtool clean-noinstLTLIBRARIES \
++	clean-noinstPROGRAMS clean-sbinPROGRAMS mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-dist_kadm5includeHEADERS install-man \
++	install-nodist_kadm5includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libLTLIBRARIES install-libexecPROGRAMS \
++	install-sbinPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man3 install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-dist_kadm5includeHEADERS \
++	uninstall-libLTLIBRARIES uninstall-libexecPROGRAMS \
++	uninstall-man uninstall-nodist_kadm5includeHEADERS \
++	uninstall-sbinPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man3 uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-checkPROGRAMS clean-generic clean-libLTLIBRARIES \
++	clean-libexecPROGRAMS clean-libtool clean-noinstLTLIBRARIES \
++	clean-noinstPROGRAMS clean-sbinPROGRAMS ctags dist-hook \
++	distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook \
++	install-dist_kadm5includeHEADERS install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am \
++	install-libLTLIBRARIES install-libexecPROGRAMS install-man \
++	install-man3 install-man8 install-nodist_kadm5includeHEADERS \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-sbinPROGRAMS install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-dist_kadm5includeHEADERS \
++	uninstall-hook uninstall-libLTLIBRARIES \
++	uninstall-libexecPROGRAMS uninstall-man uninstall-man3 \
++	uninstall-man8 uninstall-nodist_kadm5includeHEADERS \
++	uninstall-sbinPROGRAMS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++install-build-headers:: $(dist_kadm5include_HEADERS) $(nodist_kadm5include_HEADERS)
++	@foo='$(dist_kadm5include_HEADERS) $(nodist_kadm5include_HEADERS)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildkadm5include)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo "cp $$file $(buildkadm5include)/$$f";\
++			cp $$file $(buildkadm5include)/$$f; \
++		fi ; \
++	done
++
++iprop-commands.c iprop-commands.h: iprop-commands.in
++	$(SLC) $(srcdir)/iprop-commands.in
++
++$(libkadm5srv_la_OBJECTS): kadm5_err.h
++$(iprop_log_OBJECTS): iprop-commands.h
++
++client_glue.lo server_glue.lo: $(srcdir)/common_glue.c
++
++# to help stupid solaris make
++
++kadm5_err.h: kadm5_err.et
++
++$(libkadm5clnt_la_OBJECTS) $(libkadm5srv_la_OBJECTS): $(srcdir)/kadm5-protos.h $(srcdir)/kadm5-private.h
++$(srcdir)/kadm5-protos.h:
++	cd $(srcdir); perl ../../cf/make-proto.pl $(proto_opts) \
++		-o kadm5-protos.h \
++		$(dist_libkadm5clnt_la_SOURCES) \
++		$(dist_libkadm5srv_la_SOURCES) \
++		|| rm -f kadm5-protos.h
++
++$(srcdir)/kadm5-private.h:
++	cd $(srcdir); perl ../../cf/make-proto.pl $(proto_opts) \
++		-p kadm5-private.h \
++		$(dist_libkadm5clnt_la_SOURCES) \
++		$(dist_libkadm5srv_la_SOURCES) \
++		|| rm -f kadm5-private.h
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/kafs/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/kafs/Makefile.in	2010-12-29 04:07:12.046955201 +0100
+@@ -0,0 +1,1050 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(include_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++subdir = lib/kafs
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(man3dir)" \
++	"$(DESTDIR)$(foodir)" "$(DESTDIR)$(includedir)"
++LTLIBRARIES = $(lib_LTLIBRARIES)
++@KRB5_TRUE@am__DEPENDENCIES_1 = ../krb5/libkrb5.la
++am__DEPENDENCIES_2 =
++libkafs_la_DEPENDENCIES = $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_2)
++am__dist_libkafs_la_SOURCES_DIST = afssys.c afskrb5.c common.c \
++	afslib.c kafs_locl.h afssysdefs.h roken_rename.h
++@AIX_DYNAMIC_AFS_FALSE@@AIX_TRUE@am__objects_1 = afslib.lo
++dist_libkafs_la_OBJECTS = afssys.lo afskrb5.lo common.lo \
++	$(am__objects_1)
++@do_roken_rename_TRUE@am__objects_2 = resolve.lo strtok_r.lo \
++@do_roken_rename_TRUE@	strlcpy.lo strsep.lo
++nodist_libkafs_la_OBJECTS = $(am__objects_2)
++libkafs_la_OBJECTS = $(dist_libkafs_la_OBJECTS) \
++	$(nodist_libkafs_la_OBJECTS)
++libkafs_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libkafs_la_LDFLAGS) $(LDFLAGS) -o $@
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(EXTRA_libkafs_la_SOURCES) $(dist_libkafs_la_SOURCES) \
++	$(nodist_libkafs_la_SOURCES)
++DIST_SOURCES = $(EXTRA_libkafs_la_SOURCES) \
++	$(am__dist_libkafs_la_SOURCES_DIST)
++man3dir = $(mandir)/man3
++MANS = $(man_MANS)
++DATA = $(foo_DATA)
++HEADERS = $(include_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(AFS_EXTRA_DEFS) $(ROKEN_RENAME) \
++	$(krb5_am_workaround)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++@KRB5_FALSE@DEPLIB_krb5 = 
++@KRB5_TRUE@DEPLIB_krb5 = ../krb5/libkrb5.la 
++@KRB5_FALSE@krb5_am_workaround = 
++@KRB5_TRUE@krb5_am_workaround = $(INCLUDE_hcrypto) -I$(top_srcdir)/lib/krb5
++@AIX_FALSE@AFSL_EXP = 
++@AIX_TRUE@AFSL_EXP = $(srcdir)/afsl.exp
++@AIX4_FALSE@@AIX_TRUE@AFS_EXTRA_LD = -e _nostart
++@AIX4_TRUE@@AIX_TRUE@AFS_EXTRA_LD = -bnoentry
++@AIX_DYNAMIC_AFS_FALSE@@AIX_TRUE@AIX_SRC = afslib.c
++@AIX_DYNAMIC_AFS_TRUE@@AIX_TRUE@AIX_SRC = 
++@AIX_FALSE@AIX_SRC = 
++@AIX_DYNAMIC_AFS_FALSE@@AIX_TRUE@AFS_EXTRA_LIBS = 
++@AIX_DYNAMIC_AFS_TRUE@@AIX_TRUE@AFS_EXTRA_LIBS = afslib.so
++@AIX_DYNAMIC_AFS_FALSE@@AIX_TRUE@AFS_EXTRA_DEFS = -DSTATIC_AFS
++@AIX_DYNAMIC_AFS_TRUE@@AIX_TRUE@AFS_EXTRA_DEFS = 
++libkafs_la_LIBADD = $(DEPLIB_krb5) $(LIBADD_roken)
++lib_LTLIBRARIES = libkafs.la
++libkafs_la_LDFLAGS = -version-info 5:1:5
++foodir = $(libdir)
++foo_DATA = $(AFS_EXTRA_LIBS)
++# EXTRA_DATA = afslib.so
++CLEANFILES = $(AFS_EXTRA_LIBS) $(ROKEN_SRCS)
++include_HEADERS = kafs.h
++@KRB5_TRUE@afskrb5_c = 
++@do_roken_rename_TRUE@ROKEN_SRCS = resolve.c strtok_r.c strlcpy.c strsep.c
++dist_libkafs_la_SOURCES = \
++	afssys.c				\
++	afskrb5.c				\
++	common.c				\
++	$(AIX_SRC)				\
++	kafs_locl.h				\
++	afssysdefs.h				\
++	roken_rename.h
++
++nodist_libkafs_la_SOURCES = $(ROKEN_SRCS)
++EXTRA_libkafs_la_SOURCES = afskrb5.c afslib.c
++EXTRA_DIST = afsl.exp afslib.exp $(man_MANS)
++man_MANS = kafs.3
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/kafs/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/kafs/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libkafs.la: $(libkafs_la_OBJECTS) $(libkafs_la_DEPENDENCIES) 
++	$(libkafs_la_LINK) -rpath $(libdir) $(libkafs_la_OBJECTS) $(libkafs_la_LIBADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/afskrb5.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/afslib.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/afssys.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/common.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/resolve.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/strlcpy.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/strsep.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/strtok_r.Plo@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man3: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man3dir)" || $(MKDIR_P) "$(DESTDIR)$(man3dir)"
++	@list=''; test -n "$(man3dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.3[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^3][0-9a-z]*$$,3,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man3dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man3dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man3dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man3dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man3:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man3dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.3[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^3][0-9a-z]*$$,3,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man3dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man3dir)" && rm -f $$files; }
++install-fooDATA: $(foo_DATA)
++	@$(NORMAL_INSTALL)
++	test -z "$(foodir)" || $(MKDIR_P) "$(DESTDIR)$(foodir)"
++	@list='$(foo_DATA)'; test -n "$(foodir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(foodir)'"; \
++	  $(INSTALL_DATA) $$files "$(DESTDIR)$(foodir)" || exit $$?; \
++	done
++
++uninstall-fooDATA:
++	@$(NORMAL_UNINSTALL)
++	@list='$(foo_DATA)'; test -n "$(foodir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(foodir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(foodir)" && rm -f $$files
++install-includeHEADERS: $(include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) $(MANS) $(DATA) $(HEADERS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(man3dir)" "$(DESTDIR)$(foodir)" "$(DESTDIR)$(includedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libLTLIBRARIES clean-libtool \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-fooDATA install-includeHEADERS install-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man3
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-fooDATA uninstall-includeHEADERS \
++	uninstall-libLTLIBRARIES uninstall-man
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man3
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libLTLIBRARIES clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-fooDATA \
++	install-html install-html-am install-includeHEADERS \
++	install-info install-info-am install-libLTLIBRARIES \
++	install-man install-man3 install-pdf install-pdf-am install-ps \
++	install-ps-am install-strip installcheck installcheck-am \
++	installdirs maintainer-clean maintainer-clean-generic \
++	mostlyclean mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags uninstall \
++	uninstall-am uninstall-fooDATA uninstall-hook \
++	uninstall-includeHEADERS uninstall-libLTLIBRARIES \
++	uninstall-man uninstall-man3
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# AIX: this almost works with gcc, but somehow it fails to use the
++# correct ld, use ld instead
++afslib.so: afslib.o
++	ld -o $@ -bM:SRE -bI:$(srcdir)/afsl.exp -bE:$(srcdir)/afslib.exp $(AFS_EXTRA_LD) afslib.o -lc
++
++resolve.c:
++	$(LN_S) $(srcdir)/../roken/resolve.c .
++
++strtok_r.c:
++	$(LN_S) $(srcdir)/../roken/strtok_r.c .
++
++strlcpy.c:
++	$(LN_S) $(srcdir)/../roken/strlcpy.c .
++
++strsep.c:
++	$(LN_S) $(srcdir)/../roken/strsep.c .
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/kdfs/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/kdfs/Makefile.in	2010-12-29 04:07:12.247017547 +0100
+@@ -0,0 +1,876 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++subdir = lib/kdfs
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)"
++LTLIBRARIES = $(lib_LTLIBRARIES)
++libkdfs_la_LIBADD =
++am_libkdfs_la_OBJECTS = k5dfspag.lo
++libkdfs_la_OBJECTS = $(am_libkdfs_la_OBJECTS)
++libkdfs_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libkdfs_la_LDFLAGS) $(LDFLAGS) -o $@
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(libkdfs_la_SOURCES)
++DIST_SOURCES = $(libkdfs_la_SOURCES)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++lib_LTLIBRARIES = libkdfs.la
++libkdfs_la_SOURCES = \
++	k5dfspag.c
++
++libkdfs_la_LDFLAGS = -version-info 0:3:0
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/kdfs/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/kdfs/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libkdfs.la: $(libkdfs_la_OBJECTS) $(libkdfs_la_DEPENDENCIES) 
++	$(libkdfs_la_LINK) -rpath $(libdir) $(libkdfs_la_OBJECTS) $(libkdfs_la_LIBADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/k5dfspag.Plo@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libLTLIBRARIES clean-libtool \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libLTLIBRARIES clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am \
++	install-libLTLIBRARIES install-man install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-hook \
++	uninstall-libLTLIBRARIES
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/krb5/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/krb5/Makefile.in	2010-12-29 04:07:13.657456843 +0100
+@@ -0,0 +1,3199 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(dist_include_HEADERS) $(krb5_HEADERS) \
++	$(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++bin_PROGRAMS = verify_krb5_conf$(EXEEXT)
++noinst_PROGRAMS = krbhst-test$(EXEEXT) test_gic$(EXEEXT) \
++	test_alname$(EXEEXT) test_crypto$(EXEEXT) \
++	test_rfc3961$(EXEEXT) test_get_addrs$(EXEEXT) \
++	test_kuserok$(EXEEXT) test_renew$(EXEEXT) \
++	test_forward$(EXEEXT)
++TESTS = aes-test$(EXEEXT) derived-key-test$(EXEEXT) \
++	n-fold-test$(EXEEXT) parse-name-test$(EXEEXT) \
++	store-test$(EXEEXT) string-to-key-test$(EXEEXT) \
++	test_acl$(EXEEXT) test_addr$(EXEEXT) test_cc$(EXEEXT) \
++	test_config$(EXEEXT) test_fx$(EXEEXT) test_prf$(EXEEXT) \
++	test_store$(EXEEXT) test_crypto_wrapping$(EXEEXT) \
++	test_keytab$(EXEEXT) test_mem$(EXEEXT) test_pac$(EXEEXT) \
++	test_plugin$(EXEEXT) test_princ$(EXEEXT) \
++	test_pkinit_dh2key$(EXEEXT) test_pknistkdf$(EXEEXT) \
++	test_time$(EXEEXT)
++check_PROGRAMS = $(am__EXEEXT_1) test_hostname$(EXEEXT) \
++	test_ap-req$(EXEEXT)
++@versionscript_TRUE@am__append_1 = $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-script.map
++subdir = lib/krb5
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(bindir)" \
++	"$(DESTDIR)$(man3dir)" "$(DESTDIR)$(man5dir)" \
++	"$(DESTDIR)$(man8dir)" "$(DESTDIR)$(includedir)" \
++	"$(DESTDIR)$(krb5dir)" "$(DESTDIR)$(includedir)"
++LTLIBRARIES = $(lib_LTLIBRARIES) $(noinst_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++@have_scc_TRUE@am__DEPENDENCIES_2 = $(am__DEPENDENCIES_1)
++libkrb5_la_DEPENDENCIES = $(LIB_pkinit) $(am__DEPENDENCIES_2) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la ../ipc/libheim-ipcc.la \
++	../wind/libwind.la $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	../../base/libheimbase.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++dist_libkrb5_la_OBJECTS = libkrb5_la-acache.lo libkrb5_la-acl.lo \
++	libkrb5_la-add_et_list.lo libkrb5_la-addr_families.lo \
++	libkrb5_la-aname_to_localname.lo libkrb5_la-appdefault.lo \
++	libkrb5_la-asn1_glue.lo libkrb5_la-auth_context.lo \
++	libkrb5_la-build_ap_req.lo libkrb5_la-build_auth.lo \
++	libkrb5_la-cache.lo libkrb5_la-changepw.lo libkrb5_la-codec.lo \
++	libkrb5_la-config_file.lo libkrb5_la-convert_creds.lo \
++	libkrb5_la-constants.lo libkrb5_la-context.lo \
++	libkrb5_la-copy_host_realm.lo libkrb5_la-crc.lo \
++	libkrb5_la-creds.lo libkrb5_la-crypto.lo \
++	libkrb5_la-crypto-aes.lo libkrb5_la-crypto-algs.lo \
++	libkrb5_la-crypto-arcfour.lo libkrb5_la-crypto-des.lo \
++	libkrb5_la-crypto-des-common.lo libkrb5_la-crypto-des3.lo \
++	libkrb5_la-crypto-evp.lo libkrb5_la-crypto-null.lo \
++	libkrb5_la-crypto-pk.lo libkrb5_la-crypto-rand.lo \
++	libkrb5_la-doxygen.lo libkrb5_la-data.lo \
++	libkrb5_la-deprecated.lo libkrb5_la-digest.lo \
++	libkrb5_la-eai_to_heim_errno.lo libkrb5_la-error_string.lo \
++	libkrb5_la-expand_hostname.lo libkrb5_la-expand_path.lo \
++	libkrb5_la-fcache.lo libkrb5_la-free.lo \
++	libkrb5_la-free_host_realm.lo \
++	libkrb5_la-generate_seq_number.lo \
++	libkrb5_la-generate_subkey.lo libkrb5_la-get_addrs.lo \
++	libkrb5_la-get_cred.lo libkrb5_la-get_default_principal.lo \
++	libkrb5_la-get_default_realm.lo libkrb5_la-get_for_creds.lo \
++	libkrb5_la-get_host_realm.lo libkrb5_la-get_in_tkt.lo \
++	libkrb5_la-get_port.lo libkrb5_la-init_creds.lo \
++	libkrb5_la-init_creds_pw.lo libkrb5_la-kcm.lo \
++	libkrb5_la-keyblock.lo libkrb5_la-keytab.lo \
++	libkrb5_la-keytab_any.lo libkrb5_la-keytab_file.lo \
++	libkrb5_la-keytab_keyfile.lo libkrb5_la-keytab_memory.lo \
++	libkrb5_la-krbhst.lo libkrb5_la-kuserok.lo libkrb5_la-log.lo \
++	libkrb5_la-mcache.lo libkrb5_la-misc.lo libkrb5_la-mk_error.lo \
++	libkrb5_la-mk_priv.lo libkrb5_la-mk_rep.lo \
++	libkrb5_la-mk_req.lo libkrb5_la-mk_req_ext.lo \
++	libkrb5_la-mk_safe.lo libkrb5_la-mit_glue.lo \
++	libkrb5_la-net_read.lo libkrb5_la-net_write.lo \
++	libkrb5_la-n-fold.lo libkrb5_la-pac.lo libkrb5_la-padata.lo \
++	libkrb5_la-pcache.lo libkrb5_la-pkinit.lo \
++	libkrb5_la-principal.lo libkrb5_la-prog_setup.lo \
++	libkrb5_la-prompter_posix.lo libkrb5_la-rd_cred.lo \
++	libkrb5_la-rd_error.lo libkrb5_la-rd_priv.lo \
++	libkrb5_la-rd_rep.lo libkrb5_la-rd_req.lo \
++	libkrb5_la-rd_safe.lo libkrb5_la-read_message.lo \
++	libkrb5_la-recvauth.lo libkrb5_la-replay.lo libkrb5_la-salt.lo \
++	libkrb5_la-salt-aes.lo libkrb5_la-salt-arcfour.lo \
++	libkrb5_la-salt-des.lo libkrb5_la-salt-des3.lo \
++	libkrb5_la-scache.lo libkrb5_la-send_to_kdc.lo \
++	libkrb5_la-sendauth.lo libkrb5_la-set_default_realm.lo \
++	libkrb5_la-sock_principal.lo libkrb5_la-store.lo \
++	libkrb5_la-store-int.lo libkrb5_la-store_emem.lo \
++	libkrb5_la-store_fd.lo libkrb5_la-store_mem.lo \
++	libkrb5_la-plugin.lo libkrb5_la-ticket.lo libkrb5_la-time.lo \
++	libkrb5_la-transited.lo libkrb5_la-verify_init.lo \
++	libkrb5_la-verify_user.lo libkrb5_la-version.lo \
++	libkrb5_la-warn.lo libkrb5_la-write_message.lo
++am__objects_1 = libkrb5_la-krb5_err.lo libkrb5_la-krb_err.lo \
++	libkrb5_la-heim_err.lo libkrb5_la-k524_err.lo
++nodist_libkrb5_la_OBJECTS = $(am__objects_1)
++libkrb5_la_OBJECTS = $(dist_libkrb5_la_OBJECTS) \
++	$(nodist_libkrb5_la_OBJECTS)
++libkrb5_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libkrb5_la_LDFLAGS) $(LDFLAGS) -o $@
++librfc3961_la_DEPENDENCIES = $(LIB_pkinit) $(am__DEPENDENCIES_2) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la ../ipc/libheim-ipcc.la \
++	../wind/libwind.la $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++am_librfc3961_la_OBJECTS = librfc3961_la-crc.lo \
++	librfc3961_la-crypto.lo librfc3961_la-crypto-aes.lo \
++	librfc3961_la-crypto-algs.lo librfc3961_la-crypto-arcfour.lo \
++	librfc3961_la-crypto-des.lo librfc3961_la-crypto-des-common.lo \
++	librfc3961_la-crypto-des3.lo librfc3961_la-crypto-evp.lo \
++	librfc3961_la-crypto-null.lo librfc3961_la-crypto-pk.lo \
++	librfc3961_la-crypto-rand.lo librfc3961_la-crypto-stubs.lo \
++	librfc3961_la-data.lo librfc3961_la-error_string.lo \
++	librfc3961_la-keyblock.lo librfc3961_la-n-fold.lo \
++	librfc3961_la-salt.lo librfc3961_la-salt-aes.lo \
++	librfc3961_la-salt-arcfour.lo librfc3961_la-salt-des.lo \
++	librfc3961_la-salt-des3.lo librfc3961_la-store-int.lo \
++	librfc3961_la-warn.lo
++librfc3961_la_OBJECTS = $(am_librfc3961_la_OBJECTS)
++am__EXEEXT_1 = aes-test$(EXEEXT) derived-key-test$(EXEEXT) \
++	n-fold-test$(EXEEXT) parse-name-test$(EXEEXT) \
++	store-test$(EXEEXT) string-to-key-test$(EXEEXT) \
++	test_acl$(EXEEXT) test_addr$(EXEEXT) test_cc$(EXEEXT) \
++	test_config$(EXEEXT) test_fx$(EXEEXT) test_prf$(EXEEXT) \
++	test_store$(EXEEXT) test_crypto_wrapping$(EXEEXT) \
++	test_keytab$(EXEEXT) test_mem$(EXEEXT) test_pac$(EXEEXT) \
++	test_plugin$(EXEEXT) test_princ$(EXEEXT) \
++	test_pkinit_dh2key$(EXEEXT) test_pknistkdf$(EXEEXT) \
++	test_time$(EXEEXT)
++PROGRAMS = $(bin_PROGRAMS) $(noinst_PROGRAMS)
++aes_test_SOURCES = aes-test.c
++aes_test_OBJECTS = aes-test.$(OBJEXT)
++aes_test_LDADD = $(LDADD)
++aes_test_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++derived_key_test_SOURCES = derived-key-test.c
++derived_key_test_OBJECTS = derived-key-test.$(OBJEXT)
++derived_key_test_LDADD = $(LDADD)
++derived_key_test_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++krbhst_test_SOURCES = krbhst-test.c
++krbhst_test_OBJECTS = krbhst-test.$(OBJEXT)
++krbhst_test_LDADD = $(LDADD)
++krbhst_test_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++n_fold_test_SOURCES = n-fold-test.c
++n_fold_test_OBJECTS = n-fold-test.$(OBJEXT)
++n_fold_test_LDADD = $(LDADD)
++n_fold_test_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++parse_name_test_SOURCES = parse-name-test.c
++parse_name_test_OBJECTS = parse-name-test.$(OBJEXT)
++parse_name_test_LDADD = $(LDADD)
++parse_name_test_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++store_test_SOURCES = store-test.c
++store_test_OBJECTS = store-test.$(OBJEXT)
++store_test_LDADD = $(LDADD)
++store_test_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++string_to_key_test_SOURCES = string-to-key-test.c
++string_to_key_test_OBJECTS = string-to-key-test.$(OBJEXT)
++string_to_key_test_LDADD = $(LDADD)
++string_to_key_test_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_acl_SOURCES = test_acl.c
++test_acl_OBJECTS = test_acl.$(OBJEXT)
++test_acl_LDADD = $(LDADD)
++test_acl_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_addr_SOURCES = test_addr.c
++test_addr_OBJECTS = test_addr.$(OBJEXT)
++test_addr_LDADD = $(LDADD)
++test_addr_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_alname_SOURCES = test_alname.c
++test_alname_OBJECTS = test_alname.$(OBJEXT)
++test_alname_LDADD = $(LDADD)
++test_alname_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_ap_req_SOURCES = test_ap-req.c
++test_ap_req_OBJECTS = test_ap-req.$(OBJEXT)
++test_ap_req_LDADD = $(LDADD)
++test_ap_req_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_cc_SOURCES = test_cc.c
++test_cc_OBJECTS = test_cc.$(OBJEXT)
++test_cc_LDADD = $(LDADD)
++test_cc_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_config_SOURCES = test_config.c
++test_config_OBJECTS = test_config.$(OBJEXT)
++test_config_LDADD = $(LDADD)
++test_config_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_crypto_SOURCES = test_crypto.c
++test_crypto_OBJECTS = test_crypto.$(OBJEXT)
++test_crypto_LDADD = $(LDADD)
++test_crypto_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_crypto_wrapping_SOURCES = test_crypto_wrapping.c
++test_crypto_wrapping_OBJECTS = test_crypto_wrapping.$(OBJEXT)
++test_crypto_wrapping_LDADD = $(LDADD)
++test_crypto_wrapping_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_forward_SOURCES = test_forward.c
++test_forward_OBJECTS = test_forward.$(OBJEXT)
++test_forward_LDADD = $(LDADD)
++test_forward_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_fx_SOURCES = test_fx.c
++test_fx_OBJECTS = test_fx.$(OBJEXT)
++test_fx_LDADD = $(LDADD)
++test_fx_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_get_addrs_SOURCES = test_get_addrs.c
++test_get_addrs_OBJECTS = test_get_addrs.$(OBJEXT)
++test_get_addrs_LDADD = $(LDADD)
++test_get_addrs_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_gic_SOURCES = test_gic.c
++test_gic_OBJECTS = test_gic.$(OBJEXT)
++test_gic_LDADD = $(LDADD)
++test_gic_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_hostname_SOURCES = test_hostname.c
++test_hostname_OBJECTS = test_hostname.$(OBJEXT)
++test_hostname_LDADD = $(LDADD)
++test_hostname_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_keytab_SOURCES = test_keytab.c
++test_keytab_OBJECTS = test_keytab.$(OBJEXT)
++test_keytab_LDADD = $(LDADD)
++test_keytab_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_kuserok_SOURCES = test_kuserok.c
++test_kuserok_OBJECTS = test_kuserok.$(OBJEXT)
++test_kuserok_LDADD = $(LDADD)
++test_kuserok_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_mem_SOURCES = test_mem.c
++test_mem_OBJECTS = test_mem.$(OBJEXT)
++test_mem_LDADD = $(LDADD)
++test_mem_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_pac_SOURCES = test_pac.c
++test_pac_OBJECTS = test_pac.$(OBJEXT)
++test_pac_LDADD = $(LDADD)
++test_pac_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_pkinit_dh2key_SOURCES = test_pkinit_dh2key.c
++test_pkinit_dh2key_OBJECTS = test_pkinit_dh2key.$(OBJEXT)
++test_pkinit_dh2key_LDADD = $(LDADD)
++test_pkinit_dh2key_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_pknistkdf_SOURCES = test_pknistkdf.c
++test_pknistkdf_OBJECTS = test_pknistkdf.$(OBJEXT)
++test_pknistkdf_LDADD = $(LDADD)
++test_pknistkdf_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_plugin_SOURCES = test_plugin.c
++test_plugin_OBJECTS = test_plugin.$(OBJEXT)
++test_plugin_LDADD = $(LDADD)
++test_plugin_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_prf_SOURCES = test_prf.c
++test_prf_OBJECTS = test_prf.$(OBJEXT)
++test_prf_LDADD = $(LDADD)
++test_prf_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_princ_SOURCES = test_princ.c
++test_princ_OBJECTS = test_princ.$(OBJEXT)
++test_princ_LDADD = $(LDADD)
++test_princ_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_renew_SOURCES = test_renew.c
++test_renew_OBJECTS = test_renew.$(OBJEXT)
++test_renew_LDADD = $(LDADD)
++test_renew_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_rfc3961_SOURCES = test_rfc3961.c
++test_rfc3961_OBJECTS = test_rfc3961.$(OBJEXT)
++test_rfc3961_DEPENDENCIES = librfc3961.la \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++test_store_SOURCES = test_store.c
++test_store_OBJECTS = test_store.$(OBJEXT)
++test_store_LDADD = $(LDADD)
++test_store_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++test_time_SOURCES = test_time.c
++test_time_OBJECTS = test_time.$(OBJEXT)
++test_time_LDADD = $(LDADD)
++test_time_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++verify_krb5_conf_SOURCES = verify_krb5_conf.c
++verify_krb5_conf_OBJECTS = verify_krb5_conf.$(OBJEXT)
++verify_krb5_conf_LDADD = $(LDADD)
++verify_krb5_conf_DEPENDENCIES = libkrb5.la $(am__DEPENDENCIES_1) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(dist_libkrb5_la_SOURCES) $(nodist_libkrb5_la_SOURCES) \
++	$(librfc3961_la_SOURCES) aes-test.c derived-key-test.c \
++	krbhst-test.c n-fold-test.c parse-name-test.c store-test.c \
++	string-to-key-test.c test_acl.c test_addr.c test_alname.c \
++	test_ap-req.c test_cc.c test_config.c test_crypto.c \
++	test_crypto_wrapping.c test_forward.c test_fx.c \
++	test_get_addrs.c test_gic.c test_hostname.c test_keytab.c \
++	test_kuserok.c test_mem.c test_pac.c test_pkinit_dh2key.c \
++	test_pknistkdf.c test_plugin.c test_prf.c test_princ.c \
++	test_renew.c test_rfc3961.c test_store.c test_time.c \
++	verify_krb5_conf.c
++DIST_SOURCES = $(dist_libkrb5_la_SOURCES) $(librfc3961_la_SOURCES) \
++	aes-test.c derived-key-test.c krbhst-test.c n-fold-test.c \
++	parse-name-test.c store-test.c string-to-key-test.c test_acl.c \
++	test_addr.c test_alname.c test_ap-req.c test_cc.c \
++	test_config.c test_crypto.c test_crypto_wrapping.c \
++	test_forward.c test_fx.c test_get_addrs.c test_gic.c \
++	test_hostname.c test_keytab.c test_kuserok.c test_mem.c \
++	test_pac.c test_pkinit_dh2key.c test_pknistkdf.c test_plugin.c \
++	test_prf.c test_princ.c test_renew.c test_rfc3961.c \
++	test_store.c test_time.c verify_krb5_conf.c
++man3dir = $(mandir)/man3
++man5dir = $(mandir)/man5
++man8dir = $(mandir)/man8
++MANS = $(man_MANS)
++HEADERS = $(dist_include_HEADERS) $(krb5_HEADERS) \
++	$(nodist_include_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_krb4) $(INCLUDE_hcrypto) \
++	-I../com_err -I$(srcdir)/../com_err $(INCLUDE_sqlite3) \
++	$(INCLUDE_libintl)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++noinst_LTLIBRARIES = \
++	librfc3961.la
++
++check_DATA = test_config_strings.out
++LDADD = libkrb5.la \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	$(top_builddir)/lib/wind/libwind.la \
++	$(LIB_roken)
++
++@PKINIT_TRUE@LIB_pkinit = ../hx509/libhx509.la
++@have_scc_TRUE@use_sqlite = $(LIB_sqlite3)
++libkrb5_la_LIBADD = \
++	$(LIB_pkinit) \
++	$(use_sqlite) \
++	$(LIB_com_err) \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	../ipc/libheim-ipcc.la \
++	../wind/libwind.la \
++	$(LIB_libintl) \
++	$(LIBADD_roken) \
++	../../base/libheimbase.la \
++	$(PTHREAD_LIBADD) \
++	$(LIB_door_create) \
++	$(LIB_dlopen)
++
++librfc3961_la_LIBADD = \
++	$(LIB_pkinit) \
++	$(use_sqlite) \
++	$(LIB_com_err) \
++	$(LIB_hcrypto) \
++	$(top_builddir)/lib/asn1/libasn1.la \
++	../ipc/libheim-ipcc.la \
++	../wind/libwind.la \
++	$(LIB_libintl) \
++	$(LIBADD_roken) \
++	$(PTHREAD_LIBADD) \
++	$(LIB_door_create) \
++	$(LIB_dlopen)
++
++lib_LTLIBRARIES = libkrb5.la
++ERR_FILES = krb5_err.c krb_err.c heim_err.c k524_err.c
++libkrb5_la_CPPFLAGS = \
++	-DBUILD_KRB5_LIB \
++	$(AM_CPPFLAGS) \
++	-DHEIMDAL_LOCALEDIR='"$(localedir)"'
++
++librfc3961_la_CPPFLAGS = \
++	-DBUILD_KRB5_LIB \
++	$(AM_CPPFLAGS)
++
++dist_libkrb5_la_SOURCES = \
++	acache.c				\
++	acl.c					\
++	add_et_list.c				\
++	addr_families.c				\
++	aname_to_localname.c			\
++	appdefault.c				\
++	asn1_glue.c				\
++	auth_context.c				\
++	build_ap_req.c				\
++	build_auth.c				\
++	cache.c					\
++	changepw.c				\
++	codec.c					\
++	config_file.c				\
++	convert_creds.c				\
++	constants.c				\
++	context.c				\
++	copy_host_realm.c			\
++	crc.c					\
++	creds.c					\
++	crypto.c				\
++	crypto.h				\
++	crypto-aes.c				\
++	crypto-algs.c				\
++	crypto-arcfour.c			\
++	crypto-des.c				\
++	crypto-des-common.c			\
++	crypto-des3.c				\
++	crypto-evp.c				\
++	crypto-null.c				\
++	crypto-pk.c				\
++	crypto-rand.c				\
++	doxygen.c				\
++	data.c					\
++	deprecated.c				\
++	digest.c				\
++	eai_to_heim_errno.c			\
++	error_string.c				\
++	expand_hostname.c			\
++	expand_path.c				\
++	fcache.c				\
++	free.c					\
++	free_host_realm.c			\
++	generate_seq_number.c			\
++	generate_subkey.c			\
++	get_addrs.c				\
++	get_cred.c				\
++	get_default_principal.c			\
++	get_default_realm.c			\
++	get_for_creds.c				\
++	get_host_realm.c			\
++	get_in_tkt.c				\
++	get_port.c				\
++	init_creds.c				\
++	init_creds_pw.c				\
++	kcm.c					\
++	kcm.h					\
++	keyblock.c				\
++	keytab.c				\
++	keytab_any.c				\
++	keytab_file.c				\
++	keytab_keyfile.c			\
++	keytab_memory.c				\
++	krb5_locl.h				\
++	krb5-v4compat.h				\
++	krbhst.c				\
++	kuserok.c				\
++	log.c					\
++	mcache.c				\
++	misc.c					\
++	mk_error.c				\
++	mk_priv.c				\
++	mk_rep.c				\
++	mk_req.c				\
++	mk_req_ext.c				\
++	mk_safe.c				\
++	mit_glue.c				\
++	net_read.c				\
++	net_write.c				\
++	n-fold.c				\
++	pac.c					\
++	padata.c				\
++	pcache.c				\
++	pkinit.c				\
++	principal.c				\
++	prog_setup.c				\
++	prompter_posix.c			\
++	rd_cred.c				\
++	rd_error.c				\
++	rd_priv.c				\
++	rd_rep.c				\
++	rd_req.c				\
++	rd_safe.c				\
++	read_message.c				\
++	recvauth.c				\
++	replay.c				\
++	salt.c					\
++	salt-aes.c				\
++	salt-arcfour.c				\
++	salt-des.c				\
++	salt-des3.c				\
++	scache.c				\
++	send_to_kdc.c				\
++	sendauth.c				\
++	set_default_realm.c			\
++	sock_principal.c			\
++	store.c					\
++	store-int.c				\
++	store-int.h				\
++	store_emem.c				\
++	store_fd.c				\
++	store_mem.c				\
++	plugin.c				\
++	ticket.c				\
++	time.c					\
++	transited.c				\
++	verify_init.c				\
++	verify_user.c				\
++	version.c				\
++	warn.c					\
++	write_message.c
++
++nodist_libkrb5_la_SOURCES = \
++	$(ERR_FILES)
++
++libkrb5_la_LDFLAGS = -version-info 26:0:0 $(am__append_1)
++librfc3961_la_SOURCES = \
++	crc.c					\
++	crypto.c				\
++	crypto.h				\
++	crypto-aes.c				\
++	crypto-algs.c				\
++	crypto-arcfour.c			\
++	crypto-des.c				\
++	crypto-des-common.c			\
++	crypto-des3.c				\
++	crypto-evp.c				\
++	crypto-null.c				\
++	crypto-pk.c				\
++	crypto-rand.c				\
++	crypto-stubs.c				\
++	data.c					\
++	error_string.c				\
++	keyblock.c				\
++	n-fold.c				\
++	salt.c					\
++	salt-aes.c				\
++	salt-arcfour.c				\
++	salt-des.c				\
++	salt-des3.c				\
++	store-int.c				\
++	warn.c
++
++test_rfc3961_LDADD = \
++	librfc3961.la 				\
++	$(top_builddir)/lib/asn1/libasn1.la	\
++	$(top_builddir)/lib/wind/libwind.la 	\
++	$(LIB_hcrypto)				\
++	$(LIB_roken)
++
++man_MANS = \
++	kerberos.8				\
++	krb5.conf.5				\
++	krb524_convert_creds_kdc.3		\
++	krb5_425_conv_principal.3		\
++	krb5_acl_match_file.3			\
++	krb5_aname_to_localname.3		\
++	krb5_appdefault.3			\
++	krb5_auth_context.3			\
++	krb5_c_make_checksum.3			\
++	krb5_check_transited.3			\
++	krb5_create_checksum.3			\
++	krb5_creds.3				\
++	krb5_digest.3				\
++	krb5_eai_to_heim_errno.3		\
++	krb5_encrypt.3				\
++	krb5_find_padata.3			\
++	krb5_generate_random_block.3		\
++	krb5_get_all_client_addrs.3		\
++	krb5_get_credentials.3			\
++	krb5_get_creds.3			\
++	krb5_get_forwarded_creds.3		\
++	krb5_get_in_cred.3			\
++	krb5_get_init_creds.3			\
++	krb5_get_krbhst.3			\
++	krb5_getportbyname.3			\
++	krb5_init_context.3			\
++	krb5_is_thread_safe.3			\
++	krb5_krbhst_init.3			\
++	krb5_mk_req.3				\
++	krb5_mk_safe.3				\
++	krb5_openlog.3				\
++	krb5_parse_name.3			\
++	krb5_principal.3			\
++	krb5_rcache.3				\
++	krb5_rd_error.3				\
++	krb5_rd_safe.3				\
++	krb5_set_default_realm.3		\
++	krb5_set_password.3			\
++	krb5_string_to_key.3			\
++	krb5_timeofday.3			\
++	krb5_verify_init_creds.3		\
++	krb5_verify_user.3			\
++	verify_krb5_conf.8
++
++dist_include_HEADERS = \
++	krb5.h \
++	krb5-protos.h \
++	krb5-private.h \
++	krb5_ccapi.h
++
++nodist_include_HEADERS = krb5_err.h heim_err.h k524_err.h 
++
++# XXX use nobase_include_HEADERS = krb5/locate_plugin.h
++krb5dir = $(includedir)/krb5
++krb5_HEADERS = locate_plugin.h send_to_kdc_plugin.h ccache_plugin.h
++build_HEADERZ = \
++	$(krb5_HEADERS) \
++	krb_err.h
++
++CLEANFILES = \
++	test_config_strings.out \
++	test-store-data \
++	krb5_err.c krb5_err.h \
++	krb_err.c krb_err.h \
++	heim_err.c heim_err.h \
++	k524_err.c k524_err.h
++
++EXTRA_DIST = \
++	krb5_err.et \
++	krb_err.et \
++	heim_err.et \
++	k524_err.et \
++	$(man_MANS) \
++	version-script.map \
++	test_config_strings.cfg \
++	krb5.moduli
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/krb5/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/krb5/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++
++clean-noinstLTLIBRARIES:
++	-test -z "$(noinst_LTLIBRARIES)" || rm -f $(noinst_LTLIBRARIES)
++	@list='$(noinst_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libkrb5.la: $(libkrb5_la_OBJECTS) $(libkrb5_la_DEPENDENCIES) 
++	$(libkrb5_la_LINK) -rpath $(libdir) $(libkrb5_la_OBJECTS) $(libkrb5_la_LIBADD) $(LIBS)
++librfc3961.la: $(librfc3961_la_OBJECTS) $(librfc3961_la_DEPENDENCIES) 
++	$(LINK)  $(librfc3961_la_OBJECTS) $(librfc3961_la_LIBADD) $(LIBS)
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-checkPROGRAMS:
++	@list='$(check_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++aes-test$(EXEEXT): $(aes_test_OBJECTS) $(aes_test_DEPENDENCIES) 
++	@rm -f aes-test$(EXEEXT)
++	$(LINK) $(aes_test_OBJECTS) $(aes_test_LDADD) $(LIBS)
++derived-key-test$(EXEEXT): $(derived_key_test_OBJECTS) $(derived_key_test_DEPENDENCIES) 
++	@rm -f derived-key-test$(EXEEXT)
++	$(LINK) $(derived_key_test_OBJECTS) $(derived_key_test_LDADD) $(LIBS)
++krbhst-test$(EXEEXT): $(krbhst_test_OBJECTS) $(krbhst_test_DEPENDENCIES) 
++	@rm -f krbhst-test$(EXEEXT)
++	$(LINK) $(krbhst_test_OBJECTS) $(krbhst_test_LDADD) $(LIBS)
++n-fold-test$(EXEEXT): $(n_fold_test_OBJECTS) $(n_fold_test_DEPENDENCIES) 
++	@rm -f n-fold-test$(EXEEXT)
++	$(LINK) $(n_fold_test_OBJECTS) $(n_fold_test_LDADD) $(LIBS)
++parse-name-test$(EXEEXT): $(parse_name_test_OBJECTS) $(parse_name_test_DEPENDENCIES) 
++	@rm -f parse-name-test$(EXEEXT)
++	$(LINK) $(parse_name_test_OBJECTS) $(parse_name_test_LDADD) $(LIBS)
++store-test$(EXEEXT): $(store_test_OBJECTS) $(store_test_DEPENDENCIES) 
++	@rm -f store-test$(EXEEXT)
++	$(LINK) $(store_test_OBJECTS) $(store_test_LDADD) $(LIBS)
++string-to-key-test$(EXEEXT): $(string_to_key_test_OBJECTS) $(string_to_key_test_DEPENDENCIES) 
++	@rm -f string-to-key-test$(EXEEXT)
++	$(LINK) $(string_to_key_test_OBJECTS) $(string_to_key_test_LDADD) $(LIBS)
++test_acl$(EXEEXT): $(test_acl_OBJECTS) $(test_acl_DEPENDENCIES) 
++	@rm -f test_acl$(EXEEXT)
++	$(LINK) $(test_acl_OBJECTS) $(test_acl_LDADD) $(LIBS)
++test_addr$(EXEEXT): $(test_addr_OBJECTS) $(test_addr_DEPENDENCIES) 
++	@rm -f test_addr$(EXEEXT)
++	$(LINK) $(test_addr_OBJECTS) $(test_addr_LDADD) $(LIBS)
++test_alname$(EXEEXT): $(test_alname_OBJECTS) $(test_alname_DEPENDENCIES) 
++	@rm -f test_alname$(EXEEXT)
++	$(LINK) $(test_alname_OBJECTS) $(test_alname_LDADD) $(LIBS)
++test_ap-req$(EXEEXT): $(test_ap_req_OBJECTS) $(test_ap_req_DEPENDENCIES) 
++	@rm -f test_ap-req$(EXEEXT)
++	$(LINK) $(test_ap_req_OBJECTS) $(test_ap_req_LDADD) $(LIBS)
++test_cc$(EXEEXT): $(test_cc_OBJECTS) $(test_cc_DEPENDENCIES) 
++	@rm -f test_cc$(EXEEXT)
++	$(LINK) $(test_cc_OBJECTS) $(test_cc_LDADD) $(LIBS)
++test_config$(EXEEXT): $(test_config_OBJECTS) $(test_config_DEPENDENCIES) 
++	@rm -f test_config$(EXEEXT)
++	$(LINK) $(test_config_OBJECTS) $(test_config_LDADD) $(LIBS)
++test_crypto$(EXEEXT): $(test_crypto_OBJECTS) $(test_crypto_DEPENDENCIES) 
++	@rm -f test_crypto$(EXEEXT)
++	$(LINK) $(test_crypto_OBJECTS) $(test_crypto_LDADD) $(LIBS)
++test_crypto_wrapping$(EXEEXT): $(test_crypto_wrapping_OBJECTS) $(test_crypto_wrapping_DEPENDENCIES) 
++	@rm -f test_crypto_wrapping$(EXEEXT)
++	$(LINK) $(test_crypto_wrapping_OBJECTS) $(test_crypto_wrapping_LDADD) $(LIBS)
++test_forward$(EXEEXT): $(test_forward_OBJECTS) $(test_forward_DEPENDENCIES) 
++	@rm -f test_forward$(EXEEXT)
++	$(LINK) $(test_forward_OBJECTS) $(test_forward_LDADD) $(LIBS)
++test_fx$(EXEEXT): $(test_fx_OBJECTS) $(test_fx_DEPENDENCIES) 
++	@rm -f test_fx$(EXEEXT)
++	$(LINK) $(test_fx_OBJECTS) $(test_fx_LDADD) $(LIBS)
++test_get_addrs$(EXEEXT): $(test_get_addrs_OBJECTS) $(test_get_addrs_DEPENDENCIES) 
++	@rm -f test_get_addrs$(EXEEXT)
++	$(LINK) $(test_get_addrs_OBJECTS) $(test_get_addrs_LDADD) $(LIBS)
++test_gic$(EXEEXT): $(test_gic_OBJECTS) $(test_gic_DEPENDENCIES) 
++	@rm -f test_gic$(EXEEXT)
++	$(LINK) $(test_gic_OBJECTS) $(test_gic_LDADD) $(LIBS)
++test_hostname$(EXEEXT): $(test_hostname_OBJECTS) $(test_hostname_DEPENDENCIES) 
++	@rm -f test_hostname$(EXEEXT)
++	$(LINK) $(test_hostname_OBJECTS) $(test_hostname_LDADD) $(LIBS)
++test_keytab$(EXEEXT): $(test_keytab_OBJECTS) $(test_keytab_DEPENDENCIES) 
++	@rm -f test_keytab$(EXEEXT)
++	$(LINK) $(test_keytab_OBJECTS) $(test_keytab_LDADD) $(LIBS)
++test_kuserok$(EXEEXT): $(test_kuserok_OBJECTS) $(test_kuserok_DEPENDENCIES) 
++	@rm -f test_kuserok$(EXEEXT)
++	$(LINK) $(test_kuserok_OBJECTS) $(test_kuserok_LDADD) $(LIBS)
++test_mem$(EXEEXT): $(test_mem_OBJECTS) $(test_mem_DEPENDENCIES) 
++	@rm -f test_mem$(EXEEXT)
++	$(LINK) $(test_mem_OBJECTS) $(test_mem_LDADD) $(LIBS)
++test_pac$(EXEEXT): $(test_pac_OBJECTS) $(test_pac_DEPENDENCIES) 
++	@rm -f test_pac$(EXEEXT)
++	$(LINK) $(test_pac_OBJECTS) $(test_pac_LDADD) $(LIBS)
++test_pkinit_dh2key$(EXEEXT): $(test_pkinit_dh2key_OBJECTS) $(test_pkinit_dh2key_DEPENDENCIES) 
++	@rm -f test_pkinit_dh2key$(EXEEXT)
++	$(LINK) $(test_pkinit_dh2key_OBJECTS) $(test_pkinit_dh2key_LDADD) $(LIBS)
++test_pknistkdf$(EXEEXT): $(test_pknistkdf_OBJECTS) $(test_pknistkdf_DEPENDENCIES) 
++	@rm -f test_pknistkdf$(EXEEXT)
++	$(LINK) $(test_pknistkdf_OBJECTS) $(test_pknistkdf_LDADD) $(LIBS)
++test_plugin$(EXEEXT): $(test_plugin_OBJECTS) $(test_plugin_DEPENDENCIES) 
++	@rm -f test_plugin$(EXEEXT)
++	$(LINK) $(test_plugin_OBJECTS) $(test_plugin_LDADD) $(LIBS)
++test_prf$(EXEEXT): $(test_prf_OBJECTS) $(test_prf_DEPENDENCIES) 
++	@rm -f test_prf$(EXEEXT)
++	$(LINK) $(test_prf_OBJECTS) $(test_prf_LDADD) $(LIBS)
++test_princ$(EXEEXT): $(test_princ_OBJECTS) $(test_princ_DEPENDENCIES) 
++	@rm -f test_princ$(EXEEXT)
++	$(LINK) $(test_princ_OBJECTS) $(test_princ_LDADD) $(LIBS)
++test_renew$(EXEEXT): $(test_renew_OBJECTS) $(test_renew_DEPENDENCIES) 
++	@rm -f test_renew$(EXEEXT)
++	$(LINK) $(test_renew_OBJECTS) $(test_renew_LDADD) $(LIBS)
++test_rfc3961$(EXEEXT): $(test_rfc3961_OBJECTS) $(test_rfc3961_DEPENDENCIES) 
++	@rm -f test_rfc3961$(EXEEXT)
++	$(LINK) $(test_rfc3961_OBJECTS) $(test_rfc3961_LDADD) $(LIBS)
++test_store$(EXEEXT): $(test_store_OBJECTS) $(test_store_DEPENDENCIES) 
++	@rm -f test_store$(EXEEXT)
++	$(LINK) $(test_store_OBJECTS) $(test_store_LDADD) $(LIBS)
++test_time$(EXEEXT): $(test_time_OBJECTS) $(test_time_DEPENDENCIES) 
++	@rm -f test_time$(EXEEXT)
++	$(LINK) $(test_time_OBJECTS) $(test_time_LDADD) $(LIBS)
++verify_krb5_conf$(EXEEXT): $(verify_krb5_conf_OBJECTS) $(verify_krb5_conf_DEPENDENCIES) 
++	@rm -f verify_krb5_conf$(EXEEXT)
++	$(LINK) $(verify_krb5_conf_OBJECTS) $(verify_krb5_conf_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/aes-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/derived-key-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/krbhst-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-acache.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-acl.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-add_et_list.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-addr_families.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-aname_to_localname.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-appdefault.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-asn1_glue.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-auth_context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-build_ap_req.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-build_auth.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-cache.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-changepw.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-codec.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-config_file.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-constants.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-context.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-convert_creds.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-copy_host_realm.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-crc.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-creds.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-crypto-aes.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-crypto-algs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-crypto-arcfour.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-crypto-des-common.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-crypto-des.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-crypto-des3.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-crypto-evp.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-crypto-null.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-crypto-pk.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-crypto-rand.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-crypto.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-data.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-deprecated.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-digest.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-doxygen.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-eai_to_heim_errno.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-error_string.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-expand_hostname.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-expand_path.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-fcache.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-free.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-free_host_realm.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-generate_seq_number.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-generate_subkey.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-get_addrs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-get_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-get_default_principal.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-get_default_realm.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-get_for_creds.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-get_host_realm.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-get_in_tkt.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-get_port.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-heim_err.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-init_creds.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-init_creds_pw.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-k524_err.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-kcm.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-keyblock.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-keytab.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-keytab_any.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-keytab_file.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-keytab_keyfile.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-keytab_memory.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-krb5_err.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-krb_err.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-krbhst.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-kuserok.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-log.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-mcache.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-misc.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-mit_glue.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-mk_error.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-mk_priv.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-mk_rep.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-mk_req.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-mk_req_ext.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-mk_safe.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-n-fold.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-net_read.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-net_write.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-pac.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-padata.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-pcache.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-pkinit.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-plugin.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-principal.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-prog_setup.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-prompter_posix.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-rd_cred.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-rd_error.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-rd_priv.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-rd_rep.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-rd_req.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-rd_safe.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-read_message.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-recvauth.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-replay.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-salt-aes.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-salt-arcfour.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-salt-des.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-salt-des3.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-salt.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-scache.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-send_to_kdc.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-sendauth.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-set_default_realm.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-sock_principal.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-store-int.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-store.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-store_emem.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-store_fd.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-store_mem.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-ticket.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-time.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-transited.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-verify_init.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-verify_user.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-version.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-warn.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libkrb5_la-write_message.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-crc.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-crypto-aes.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-crypto-algs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-crypto-arcfour.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-crypto-des-common.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-crypto-des.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-crypto-des3.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-crypto-evp.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-crypto-null.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-crypto-pk.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-crypto-rand.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-crypto-stubs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-crypto.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-data.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-error_string.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-keyblock.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-n-fold.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-salt-aes.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-salt-arcfour.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-salt-des.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-salt-des3.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-salt.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-store-int.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/librfc3961_la-warn.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/n-fold-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/parse-name-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/store-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/string-to-key-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_acl.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_addr.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_alname.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_ap-req.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_cc.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_config.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_crypto.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_crypto_wrapping.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_forward.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_fx.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_get_addrs.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_gic.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_hostname.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_keytab.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_kuserok.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_mem.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_pac.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_pkinit_dh2key.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_pknistkdf.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_plugin.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_prf.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_princ.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_renew.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_rfc3961.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_store.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_time.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/verify_krb5_conf.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++libkrb5_la-acache.lo: acache.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-acache.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-acache.Tpo -c -o libkrb5_la-acache.lo `test -f 'acache.c' || echo '$(srcdir)/'`acache.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-acache.Tpo $(DEPDIR)/libkrb5_la-acache.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='acache.c' object='libkrb5_la-acache.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-acache.lo `test -f 'acache.c' || echo '$(srcdir)/'`acache.c
++
++libkrb5_la-acl.lo: acl.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-acl.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-acl.Tpo -c -o libkrb5_la-acl.lo `test -f 'acl.c' || echo '$(srcdir)/'`acl.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-acl.Tpo $(DEPDIR)/libkrb5_la-acl.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='acl.c' object='libkrb5_la-acl.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-acl.lo `test -f 'acl.c' || echo '$(srcdir)/'`acl.c
++
++libkrb5_la-add_et_list.lo: add_et_list.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-add_et_list.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-add_et_list.Tpo -c -o libkrb5_la-add_et_list.lo `test -f 'add_et_list.c' || echo '$(srcdir)/'`add_et_list.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-add_et_list.Tpo $(DEPDIR)/libkrb5_la-add_et_list.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='add_et_list.c' object='libkrb5_la-add_et_list.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-add_et_list.lo `test -f 'add_et_list.c' || echo '$(srcdir)/'`add_et_list.c
++
++libkrb5_la-addr_families.lo: addr_families.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-addr_families.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-addr_families.Tpo -c -o libkrb5_la-addr_families.lo `test -f 'addr_families.c' || echo '$(srcdir)/'`addr_families.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-addr_families.Tpo $(DEPDIR)/libkrb5_la-addr_families.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='addr_families.c' object='libkrb5_la-addr_families.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-addr_families.lo `test -f 'addr_families.c' || echo '$(srcdir)/'`addr_families.c
++
++libkrb5_la-aname_to_localname.lo: aname_to_localname.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-aname_to_localname.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-aname_to_localname.Tpo -c -o libkrb5_la-aname_to_localname.lo `test -f 'aname_to_localname.c' || echo '$(srcdir)/'`aname_to_localname.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-aname_to_localname.Tpo $(DEPDIR)/libkrb5_la-aname_to_localname.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='aname_to_localname.c' object='libkrb5_la-aname_to_localname.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-aname_to_localname.lo `test -f 'aname_to_localname.c' || echo '$(srcdir)/'`aname_to_localname.c
++
++libkrb5_la-appdefault.lo: appdefault.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-appdefault.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-appdefault.Tpo -c -o libkrb5_la-appdefault.lo `test -f 'appdefault.c' || echo '$(srcdir)/'`appdefault.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-appdefault.Tpo $(DEPDIR)/libkrb5_la-appdefault.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='appdefault.c' object='libkrb5_la-appdefault.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-appdefault.lo `test -f 'appdefault.c' || echo '$(srcdir)/'`appdefault.c
++
++libkrb5_la-asn1_glue.lo: asn1_glue.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-asn1_glue.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-asn1_glue.Tpo -c -o libkrb5_la-asn1_glue.lo `test -f 'asn1_glue.c' || echo '$(srcdir)/'`asn1_glue.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-asn1_glue.Tpo $(DEPDIR)/libkrb5_la-asn1_glue.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='asn1_glue.c' object='libkrb5_la-asn1_glue.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-asn1_glue.lo `test -f 'asn1_glue.c' || echo '$(srcdir)/'`asn1_glue.c
++
++libkrb5_la-auth_context.lo: auth_context.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-auth_context.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-auth_context.Tpo -c -o libkrb5_la-auth_context.lo `test -f 'auth_context.c' || echo '$(srcdir)/'`auth_context.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-auth_context.Tpo $(DEPDIR)/libkrb5_la-auth_context.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='auth_context.c' object='libkrb5_la-auth_context.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-auth_context.lo `test -f 'auth_context.c' || echo '$(srcdir)/'`auth_context.c
++
++libkrb5_la-build_ap_req.lo: build_ap_req.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-build_ap_req.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-build_ap_req.Tpo -c -o libkrb5_la-build_ap_req.lo `test -f 'build_ap_req.c' || echo '$(srcdir)/'`build_ap_req.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-build_ap_req.Tpo $(DEPDIR)/libkrb5_la-build_ap_req.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='build_ap_req.c' object='libkrb5_la-build_ap_req.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-build_ap_req.lo `test -f 'build_ap_req.c' || echo '$(srcdir)/'`build_ap_req.c
++
++libkrb5_la-build_auth.lo: build_auth.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-build_auth.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-build_auth.Tpo -c -o libkrb5_la-build_auth.lo `test -f 'build_auth.c' || echo '$(srcdir)/'`build_auth.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-build_auth.Tpo $(DEPDIR)/libkrb5_la-build_auth.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='build_auth.c' object='libkrb5_la-build_auth.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-build_auth.lo `test -f 'build_auth.c' || echo '$(srcdir)/'`build_auth.c
++
++libkrb5_la-cache.lo: cache.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-cache.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-cache.Tpo -c -o libkrb5_la-cache.lo `test -f 'cache.c' || echo '$(srcdir)/'`cache.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-cache.Tpo $(DEPDIR)/libkrb5_la-cache.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='cache.c' object='libkrb5_la-cache.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-cache.lo `test -f 'cache.c' || echo '$(srcdir)/'`cache.c
++
++libkrb5_la-changepw.lo: changepw.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-changepw.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-changepw.Tpo -c -o libkrb5_la-changepw.lo `test -f 'changepw.c' || echo '$(srcdir)/'`changepw.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-changepw.Tpo $(DEPDIR)/libkrb5_la-changepw.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='changepw.c' object='libkrb5_la-changepw.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-changepw.lo `test -f 'changepw.c' || echo '$(srcdir)/'`changepw.c
++
++libkrb5_la-codec.lo: codec.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-codec.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-codec.Tpo -c -o libkrb5_la-codec.lo `test -f 'codec.c' || echo '$(srcdir)/'`codec.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-codec.Tpo $(DEPDIR)/libkrb5_la-codec.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='codec.c' object='libkrb5_la-codec.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-codec.lo `test -f 'codec.c' || echo '$(srcdir)/'`codec.c
++
++libkrb5_la-config_file.lo: config_file.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-config_file.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-config_file.Tpo -c -o libkrb5_la-config_file.lo `test -f 'config_file.c' || echo '$(srcdir)/'`config_file.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-config_file.Tpo $(DEPDIR)/libkrb5_la-config_file.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='config_file.c' object='libkrb5_la-config_file.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-config_file.lo `test -f 'config_file.c' || echo '$(srcdir)/'`config_file.c
++
++libkrb5_la-convert_creds.lo: convert_creds.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-convert_creds.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-convert_creds.Tpo -c -o libkrb5_la-convert_creds.lo `test -f 'convert_creds.c' || echo '$(srcdir)/'`convert_creds.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-convert_creds.Tpo $(DEPDIR)/libkrb5_la-convert_creds.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='convert_creds.c' object='libkrb5_la-convert_creds.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-convert_creds.lo `test -f 'convert_creds.c' || echo '$(srcdir)/'`convert_creds.c
++
++libkrb5_la-constants.lo: constants.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-constants.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-constants.Tpo -c -o libkrb5_la-constants.lo `test -f 'constants.c' || echo '$(srcdir)/'`constants.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-constants.Tpo $(DEPDIR)/libkrb5_la-constants.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='constants.c' object='libkrb5_la-constants.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-constants.lo `test -f 'constants.c' || echo '$(srcdir)/'`constants.c
++
++libkrb5_la-context.lo: context.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-context.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-context.Tpo -c -o libkrb5_la-context.lo `test -f 'context.c' || echo '$(srcdir)/'`context.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-context.Tpo $(DEPDIR)/libkrb5_la-context.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='context.c' object='libkrb5_la-context.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-context.lo `test -f 'context.c' || echo '$(srcdir)/'`context.c
++
++libkrb5_la-copy_host_realm.lo: copy_host_realm.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-copy_host_realm.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-copy_host_realm.Tpo -c -o libkrb5_la-copy_host_realm.lo `test -f 'copy_host_realm.c' || echo '$(srcdir)/'`copy_host_realm.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-copy_host_realm.Tpo $(DEPDIR)/libkrb5_la-copy_host_realm.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='copy_host_realm.c' object='libkrb5_la-copy_host_realm.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-copy_host_realm.lo `test -f 'copy_host_realm.c' || echo '$(srcdir)/'`copy_host_realm.c
++
++libkrb5_la-crc.lo: crc.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-crc.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-crc.Tpo -c -o libkrb5_la-crc.lo `test -f 'crc.c' || echo '$(srcdir)/'`crc.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-crc.Tpo $(DEPDIR)/libkrb5_la-crc.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crc.c' object='libkrb5_la-crc.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-crc.lo `test -f 'crc.c' || echo '$(srcdir)/'`crc.c
++
++libkrb5_la-creds.lo: creds.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-creds.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-creds.Tpo -c -o libkrb5_la-creds.lo `test -f 'creds.c' || echo '$(srcdir)/'`creds.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-creds.Tpo $(DEPDIR)/libkrb5_la-creds.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='creds.c' object='libkrb5_la-creds.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-creds.lo `test -f 'creds.c' || echo '$(srcdir)/'`creds.c
++
++libkrb5_la-crypto.lo: crypto.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-crypto.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-crypto.Tpo -c -o libkrb5_la-crypto.lo `test -f 'crypto.c' || echo '$(srcdir)/'`crypto.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-crypto.Tpo $(DEPDIR)/libkrb5_la-crypto.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto.c' object='libkrb5_la-crypto.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-crypto.lo `test -f 'crypto.c' || echo '$(srcdir)/'`crypto.c
++
++libkrb5_la-crypto-aes.lo: crypto-aes.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-crypto-aes.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-crypto-aes.Tpo -c -o libkrb5_la-crypto-aes.lo `test -f 'crypto-aes.c' || echo '$(srcdir)/'`crypto-aes.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-crypto-aes.Tpo $(DEPDIR)/libkrb5_la-crypto-aes.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-aes.c' object='libkrb5_la-crypto-aes.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-crypto-aes.lo `test -f 'crypto-aes.c' || echo '$(srcdir)/'`crypto-aes.c
++
++libkrb5_la-crypto-algs.lo: crypto-algs.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-crypto-algs.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-crypto-algs.Tpo -c -o libkrb5_la-crypto-algs.lo `test -f 'crypto-algs.c' || echo '$(srcdir)/'`crypto-algs.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-crypto-algs.Tpo $(DEPDIR)/libkrb5_la-crypto-algs.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-algs.c' object='libkrb5_la-crypto-algs.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-crypto-algs.lo `test -f 'crypto-algs.c' || echo '$(srcdir)/'`crypto-algs.c
++
++libkrb5_la-crypto-arcfour.lo: crypto-arcfour.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-crypto-arcfour.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-crypto-arcfour.Tpo -c -o libkrb5_la-crypto-arcfour.lo `test -f 'crypto-arcfour.c' || echo '$(srcdir)/'`crypto-arcfour.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-crypto-arcfour.Tpo $(DEPDIR)/libkrb5_la-crypto-arcfour.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-arcfour.c' object='libkrb5_la-crypto-arcfour.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-crypto-arcfour.lo `test -f 'crypto-arcfour.c' || echo '$(srcdir)/'`crypto-arcfour.c
++
++libkrb5_la-crypto-des.lo: crypto-des.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-crypto-des.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-crypto-des.Tpo -c -o libkrb5_la-crypto-des.lo `test -f 'crypto-des.c' || echo '$(srcdir)/'`crypto-des.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-crypto-des.Tpo $(DEPDIR)/libkrb5_la-crypto-des.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-des.c' object='libkrb5_la-crypto-des.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-crypto-des.lo `test -f 'crypto-des.c' || echo '$(srcdir)/'`crypto-des.c
++
++libkrb5_la-crypto-des-common.lo: crypto-des-common.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-crypto-des-common.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-crypto-des-common.Tpo -c -o libkrb5_la-crypto-des-common.lo `test -f 'crypto-des-common.c' || echo '$(srcdir)/'`crypto-des-common.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-crypto-des-common.Tpo $(DEPDIR)/libkrb5_la-crypto-des-common.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-des-common.c' object='libkrb5_la-crypto-des-common.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-crypto-des-common.lo `test -f 'crypto-des-common.c' || echo '$(srcdir)/'`crypto-des-common.c
++
++libkrb5_la-crypto-des3.lo: crypto-des3.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-crypto-des3.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-crypto-des3.Tpo -c -o libkrb5_la-crypto-des3.lo `test -f 'crypto-des3.c' || echo '$(srcdir)/'`crypto-des3.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-crypto-des3.Tpo $(DEPDIR)/libkrb5_la-crypto-des3.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-des3.c' object='libkrb5_la-crypto-des3.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-crypto-des3.lo `test -f 'crypto-des3.c' || echo '$(srcdir)/'`crypto-des3.c
++
++libkrb5_la-crypto-evp.lo: crypto-evp.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-crypto-evp.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-crypto-evp.Tpo -c -o libkrb5_la-crypto-evp.lo `test -f 'crypto-evp.c' || echo '$(srcdir)/'`crypto-evp.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-crypto-evp.Tpo $(DEPDIR)/libkrb5_la-crypto-evp.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-evp.c' object='libkrb5_la-crypto-evp.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-crypto-evp.lo `test -f 'crypto-evp.c' || echo '$(srcdir)/'`crypto-evp.c
++
++libkrb5_la-crypto-null.lo: crypto-null.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-crypto-null.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-crypto-null.Tpo -c -o libkrb5_la-crypto-null.lo `test -f 'crypto-null.c' || echo '$(srcdir)/'`crypto-null.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-crypto-null.Tpo $(DEPDIR)/libkrb5_la-crypto-null.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-null.c' object='libkrb5_la-crypto-null.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-crypto-null.lo `test -f 'crypto-null.c' || echo '$(srcdir)/'`crypto-null.c
++
++libkrb5_la-crypto-pk.lo: crypto-pk.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-crypto-pk.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-crypto-pk.Tpo -c -o libkrb5_la-crypto-pk.lo `test -f 'crypto-pk.c' || echo '$(srcdir)/'`crypto-pk.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-crypto-pk.Tpo $(DEPDIR)/libkrb5_la-crypto-pk.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-pk.c' object='libkrb5_la-crypto-pk.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-crypto-pk.lo `test -f 'crypto-pk.c' || echo '$(srcdir)/'`crypto-pk.c
++
++libkrb5_la-crypto-rand.lo: crypto-rand.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-crypto-rand.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-crypto-rand.Tpo -c -o libkrb5_la-crypto-rand.lo `test -f 'crypto-rand.c' || echo '$(srcdir)/'`crypto-rand.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-crypto-rand.Tpo $(DEPDIR)/libkrb5_la-crypto-rand.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-rand.c' object='libkrb5_la-crypto-rand.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-crypto-rand.lo `test -f 'crypto-rand.c' || echo '$(srcdir)/'`crypto-rand.c
++
++libkrb5_la-doxygen.lo: doxygen.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-doxygen.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-doxygen.Tpo -c -o libkrb5_la-doxygen.lo `test -f 'doxygen.c' || echo '$(srcdir)/'`doxygen.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-doxygen.Tpo $(DEPDIR)/libkrb5_la-doxygen.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='doxygen.c' object='libkrb5_la-doxygen.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-doxygen.lo `test -f 'doxygen.c' || echo '$(srcdir)/'`doxygen.c
++
++libkrb5_la-data.lo: data.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-data.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-data.Tpo -c -o libkrb5_la-data.lo `test -f 'data.c' || echo '$(srcdir)/'`data.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-data.Tpo $(DEPDIR)/libkrb5_la-data.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='data.c' object='libkrb5_la-data.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-data.lo `test -f 'data.c' || echo '$(srcdir)/'`data.c
++
++libkrb5_la-deprecated.lo: deprecated.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-deprecated.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-deprecated.Tpo -c -o libkrb5_la-deprecated.lo `test -f 'deprecated.c' || echo '$(srcdir)/'`deprecated.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-deprecated.Tpo $(DEPDIR)/libkrb5_la-deprecated.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='deprecated.c' object='libkrb5_la-deprecated.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-deprecated.lo `test -f 'deprecated.c' || echo '$(srcdir)/'`deprecated.c
++
++libkrb5_la-digest.lo: digest.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-digest.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-digest.Tpo -c -o libkrb5_la-digest.lo `test -f 'digest.c' || echo '$(srcdir)/'`digest.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-digest.Tpo $(DEPDIR)/libkrb5_la-digest.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='digest.c' object='libkrb5_la-digest.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-digest.lo `test -f 'digest.c' || echo '$(srcdir)/'`digest.c
++
++libkrb5_la-eai_to_heim_errno.lo: eai_to_heim_errno.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-eai_to_heim_errno.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-eai_to_heim_errno.Tpo -c -o libkrb5_la-eai_to_heim_errno.lo `test -f 'eai_to_heim_errno.c' || echo '$(srcdir)/'`eai_to_heim_errno.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-eai_to_heim_errno.Tpo $(DEPDIR)/libkrb5_la-eai_to_heim_errno.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='eai_to_heim_errno.c' object='libkrb5_la-eai_to_heim_errno.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-eai_to_heim_errno.lo `test -f 'eai_to_heim_errno.c' || echo '$(srcdir)/'`eai_to_heim_errno.c
++
++libkrb5_la-error_string.lo: error_string.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-error_string.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-error_string.Tpo -c -o libkrb5_la-error_string.lo `test -f 'error_string.c' || echo '$(srcdir)/'`error_string.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-error_string.Tpo $(DEPDIR)/libkrb5_la-error_string.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='error_string.c' object='libkrb5_la-error_string.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-error_string.lo `test -f 'error_string.c' || echo '$(srcdir)/'`error_string.c
++
++libkrb5_la-expand_hostname.lo: expand_hostname.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-expand_hostname.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-expand_hostname.Tpo -c -o libkrb5_la-expand_hostname.lo `test -f 'expand_hostname.c' || echo '$(srcdir)/'`expand_hostname.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-expand_hostname.Tpo $(DEPDIR)/libkrb5_la-expand_hostname.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='expand_hostname.c' object='libkrb5_la-expand_hostname.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-expand_hostname.lo `test -f 'expand_hostname.c' || echo '$(srcdir)/'`expand_hostname.c
++
++libkrb5_la-expand_path.lo: expand_path.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-expand_path.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-expand_path.Tpo -c -o libkrb5_la-expand_path.lo `test -f 'expand_path.c' || echo '$(srcdir)/'`expand_path.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-expand_path.Tpo $(DEPDIR)/libkrb5_la-expand_path.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='expand_path.c' object='libkrb5_la-expand_path.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-expand_path.lo `test -f 'expand_path.c' || echo '$(srcdir)/'`expand_path.c
++
++libkrb5_la-fcache.lo: fcache.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-fcache.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-fcache.Tpo -c -o libkrb5_la-fcache.lo `test -f 'fcache.c' || echo '$(srcdir)/'`fcache.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-fcache.Tpo $(DEPDIR)/libkrb5_la-fcache.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='fcache.c' object='libkrb5_la-fcache.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-fcache.lo `test -f 'fcache.c' || echo '$(srcdir)/'`fcache.c
++
++libkrb5_la-free.lo: free.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-free.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-free.Tpo -c -o libkrb5_la-free.lo `test -f 'free.c' || echo '$(srcdir)/'`free.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-free.Tpo $(DEPDIR)/libkrb5_la-free.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='free.c' object='libkrb5_la-free.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-free.lo `test -f 'free.c' || echo '$(srcdir)/'`free.c
++
++libkrb5_la-free_host_realm.lo: free_host_realm.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-free_host_realm.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-free_host_realm.Tpo -c -o libkrb5_la-free_host_realm.lo `test -f 'free_host_realm.c' || echo '$(srcdir)/'`free_host_realm.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-free_host_realm.Tpo $(DEPDIR)/libkrb5_la-free_host_realm.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='free_host_realm.c' object='libkrb5_la-free_host_realm.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-free_host_realm.lo `test -f 'free_host_realm.c' || echo '$(srcdir)/'`free_host_realm.c
++
++libkrb5_la-generate_seq_number.lo: generate_seq_number.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-generate_seq_number.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-generate_seq_number.Tpo -c -o libkrb5_la-generate_seq_number.lo `test -f 'generate_seq_number.c' || echo '$(srcdir)/'`generate_seq_number.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-generate_seq_number.Tpo $(DEPDIR)/libkrb5_la-generate_seq_number.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='generate_seq_number.c' object='libkrb5_la-generate_seq_number.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-generate_seq_number.lo `test -f 'generate_seq_number.c' || echo '$(srcdir)/'`generate_seq_number.c
++
++libkrb5_la-generate_subkey.lo: generate_subkey.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-generate_subkey.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-generate_subkey.Tpo -c -o libkrb5_la-generate_subkey.lo `test -f 'generate_subkey.c' || echo '$(srcdir)/'`generate_subkey.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-generate_subkey.Tpo $(DEPDIR)/libkrb5_la-generate_subkey.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='generate_subkey.c' object='libkrb5_la-generate_subkey.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-generate_subkey.lo `test -f 'generate_subkey.c' || echo '$(srcdir)/'`generate_subkey.c
++
++libkrb5_la-get_addrs.lo: get_addrs.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-get_addrs.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-get_addrs.Tpo -c -o libkrb5_la-get_addrs.lo `test -f 'get_addrs.c' || echo '$(srcdir)/'`get_addrs.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-get_addrs.Tpo $(DEPDIR)/libkrb5_la-get_addrs.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='get_addrs.c' object='libkrb5_la-get_addrs.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-get_addrs.lo `test -f 'get_addrs.c' || echo '$(srcdir)/'`get_addrs.c
++
++libkrb5_la-get_cred.lo: get_cred.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-get_cred.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-get_cred.Tpo -c -o libkrb5_la-get_cred.lo `test -f 'get_cred.c' || echo '$(srcdir)/'`get_cred.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-get_cred.Tpo $(DEPDIR)/libkrb5_la-get_cred.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='get_cred.c' object='libkrb5_la-get_cred.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-get_cred.lo `test -f 'get_cred.c' || echo '$(srcdir)/'`get_cred.c
++
++libkrb5_la-get_default_principal.lo: get_default_principal.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-get_default_principal.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-get_default_principal.Tpo -c -o libkrb5_la-get_default_principal.lo `test -f 'get_default_principal.c' || echo '$(srcdir)/'`get_default_principal.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-get_default_principal.Tpo $(DEPDIR)/libkrb5_la-get_default_principal.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='get_default_principal.c' object='libkrb5_la-get_default_principal.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-get_default_principal.lo `test -f 'get_default_principal.c' || echo '$(srcdir)/'`get_default_principal.c
++
++libkrb5_la-get_default_realm.lo: get_default_realm.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-get_default_realm.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-get_default_realm.Tpo -c -o libkrb5_la-get_default_realm.lo `test -f 'get_default_realm.c' || echo '$(srcdir)/'`get_default_realm.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-get_default_realm.Tpo $(DEPDIR)/libkrb5_la-get_default_realm.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='get_default_realm.c' object='libkrb5_la-get_default_realm.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-get_default_realm.lo `test -f 'get_default_realm.c' || echo '$(srcdir)/'`get_default_realm.c
++
++libkrb5_la-get_for_creds.lo: get_for_creds.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-get_for_creds.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-get_for_creds.Tpo -c -o libkrb5_la-get_for_creds.lo `test -f 'get_for_creds.c' || echo '$(srcdir)/'`get_for_creds.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-get_for_creds.Tpo $(DEPDIR)/libkrb5_la-get_for_creds.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='get_for_creds.c' object='libkrb5_la-get_for_creds.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-get_for_creds.lo `test -f 'get_for_creds.c' || echo '$(srcdir)/'`get_for_creds.c
++
++libkrb5_la-get_host_realm.lo: get_host_realm.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-get_host_realm.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-get_host_realm.Tpo -c -o libkrb5_la-get_host_realm.lo `test -f 'get_host_realm.c' || echo '$(srcdir)/'`get_host_realm.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-get_host_realm.Tpo $(DEPDIR)/libkrb5_la-get_host_realm.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='get_host_realm.c' object='libkrb5_la-get_host_realm.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-get_host_realm.lo `test -f 'get_host_realm.c' || echo '$(srcdir)/'`get_host_realm.c
++
++libkrb5_la-get_in_tkt.lo: get_in_tkt.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-get_in_tkt.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-get_in_tkt.Tpo -c -o libkrb5_la-get_in_tkt.lo `test -f 'get_in_tkt.c' || echo '$(srcdir)/'`get_in_tkt.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-get_in_tkt.Tpo $(DEPDIR)/libkrb5_la-get_in_tkt.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='get_in_tkt.c' object='libkrb5_la-get_in_tkt.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-get_in_tkt.lo `test -f 'get_in_tkt.c' || echo '$(srcdir)/'`get_in_tkt.c
++
++libkrb5_la-get_port.lo: get_port.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-get_port.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-get_port.Tpo -c -o libkrb5_la-get_port.lo `test -f 'get_port.c' || echo '$(srcdir)/'`get_port.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-get_port.Tpo $(DEPDIR)/libkrb5_la-get_port.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='get_port.c' object='libkrb5_la-get_port.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-get_port.lo `test -f 'get_port.c' || echo '$(srcdir)/'`get_port.c
++
++libkrb5_la-init_creds.lo: init_creds.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-init_creds.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-init_creds.Tpo -c -o libkrb5_la-init_creds.lo `test -f 'init_creds.c' || echo '$(srcdir)/'`init_creds.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-init_creds.Tpo $(DEPDIR)/libkrb5_la-init_creds.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='init_creds.c' object='libkrb5_la-init_creds.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-init_creds.lo `test -f 'init_creds.c' || echo '$(srcdir)/'`init_creds.c
++
++libkrb5_la-init_creds_pw.lo: init_creds_pw.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-init_creds_pw.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-init_creds_pw.Tpo -c -o libkrb5_la-init_creds_pw.lo `test -f 'init_creds_pw.c' || echo '$(srcdir)/'`init_creds_pw.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-init_creds_pw.Tpo $(DEPDIR)/libkrb5_la-init_creds_pw.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='init_creds_pw.c' object='libkrb5_la-init_creds_pw.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-init_creds_pw.lo `test -f 'init_creds_pw.c' || echo '$(srcdir)/'`init_creds_pw.c
++
++libkrb5_la-kcm.lo: kcm.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-kcm.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-kcm.Tpo -c -o libkrb5_la-kcm.lo `test -f 'kcm.c' || echo '$(srcdir)/'`kcm.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-kcm.Tpo $(DEPDIR)/libkrb5_la-kcm.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='kcm.c' object='libkrb5_la-kcm.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-kcm.lo `test -f 'kcm.c' || echo '$(srcdir)/'`kcm.c
++
++libkrb5_la-keyblock.lo: keyblock.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-keyblock.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-keyblock.Tpo -c -o libkrb5_la-keyblock.lo `test -f 'keyblock.c' || echo '$(srcdir)/'`keyblock.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-keyblock.Tpo $(DEPDIR)/libkrb5_la-keyblock.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='keyblock.c' object='libkrb5_la-keyblock.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-keyblock.lo `test -f 'keyblock.c' || echo '$(srcdir)/'`keyblock.c
++
++libkrb5_la-keytab.lo: keytab.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-keytab.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-keytab.Tpo -c -o libkrb5_la-keytab.lo `test -f 'keytab.c' || echo '$(srcdir)/'`keytab.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-keytab.Tpo $(DEPDIR)/libkrb5_la-keytab.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='keytab.c' object='libkrb5_la-keytab.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-keytab.lo `test -f 'keytab.c' || echo '$(srcdir)/'`keytab.c
++
++libkrb5_la-keytab_any.lo: keytab_any.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-keytab_any.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-keytab_any.Tpo -c -o libkrb5_la-keytab_any.lo `test -f 'keytab_any.c' || echo '$(srcdir)/'`keytab_any.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-keytab_any.Tpo $(DEPDIR)/libkrb5_la-keytab_any.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='keytab_any.c' object='libkrb5_la-keytab_any.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-keytab_any.lo `test -f 'keytab_any.c' || echo '$(srcdir)/'`keytab_any.c
++
++libkrb5_la-keytab_file.lo: keytab_file.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-keytab_file.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-keytab_file.Tpo -c -o libkrb5_la-keytab_file.lo `test -f 'keytab_file.c' || echo '$(srcdir)/'`keytab_file.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-keytab_file.Tpo $(DEPDIR)/libkrb5_la-keytab_file.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='keytab_file.c' object='libkrb5_la-keytab_file.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-keytab_file.lo `test -f 'keytab_file.c' || echo '$(srcdir)/'`keytab_file.c
++
++libkrb5_la-keytab_keyfile.lo: keytab_keyfile.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-keytab_keyfile.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-keytab_keyfile.Tpo -c -o libkrb5_la-keytab_keyfile.lo `test -f 'keytab_keyfile.c' || echo '$(srcdir)/'`keytab_keyfile.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-keytab_keyfile.Tpo $(DEPDIR)/libkrb5_la-keytab_keyfile.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='keytab_keyfile.c' object='libkrb5_la-keytab_keyfile.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-keytab_keyfile.lo `test -f 'keytab_keyfile.c' || echo '$(srcdir)/'`keytab_keyfile.c
++
++libkrb5_la-keytab_memory.lo: keytab_memory.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-keytab_memory.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-keytab_memory.Tpo -c -o libkrb5_la-keytab_memory.lo `test -f 'keytab_memory.c' || echo '$(srcdir)/'`keytab_memory.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-keytab_memory.Tpo $(DEPDIR)/libkrb5_la-keytab_memory.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='keytab_memory.c' object='libkrb5_la-keytab_memory.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-keytab_memory.lo `test -f 'keytab_memory.c' || echo '$(srcdir)/'`keytab_memory.c
++
++libkrb5_la-krbhst.lo: krbhst.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-krbhst.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-krbhst.Tpo -c -o libkrb5_la-krbhst.lo `test -f 'krbhst.c' || echo '$(srcdir)/'`krbhst.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-krbhst.Tpo $(DEPDIR)/libkrb5_la-krbhst.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='krbhst.c' object='libkrb5_la-krbhst.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-krbhst.lo `test -f 'krbhst.c' || echo '$(srcdir)/'`krbhst.c
++
++libkrb5_la-kuserok.lo: kuserok.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-kuserok.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-kuserok.Tpo -c -o libkrb5_la-kuserok.lo `test -f 'kuserok.c' || echo '$(srcdir)/'`kuserok.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-kuserok.Tpo $(DEPDIR)/libkrb5_la-kuserok.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='kuserok.c' object='libkrb5_la-kuserok.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-kuserok.lo `test -f 'kuserok.c' || echo '$(srcdir)/'`kuserok.c
++
++libkrb5_la-log.lo: log.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-log.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-log.Tpo -c -o libkrb5_la-log.lo `test -f 'log.c' || echo '$(srcdir)/'`log.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-log.Tpo $(DEPDIR)/libkrb5_la-log.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='log.c' object='libkrb5_la-log.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-log.lo `test -f 'log.c' || echo '$(srcdir)/'`log.c
++
++libkrb5_la-mcache.lo: mcache.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-mcache.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-mcache.Tpo -c -o libkrb5_la-mcache.lo `test -f 'mcache.c' || echo '$(srcdir)/'`mcache.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-mcache.Tpo $(DEPDIR)/libkrb5_la-mcache.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='mcache.c' object='libkrb5_la-mcache.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-mcache.lo `test -f 'mcache.c' || echo '$(srcdir)/'`mcache.c
++
++libkrb5_la-misc.lo: misc.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-misc.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-misc.Tpo -c -o libkrb5_la-misc.lo `test -f 'misc.c' || echo '$(srcdir)/'`misc.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-misc.Tpo $(DEPDIR)/libkrb5_la-misc.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='misc.c' object='libkrb5_la-misc.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-misc.lo `test -f 'misc.c' || echo '$(srcdir)/'`misc.c
++
++libkrb5_la-mk_error.lo: mk_error.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-mk_error.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-mk_error.Tpo -c -o libkrb5_la-mk_error.lo `test -f 'mk_error.c' || echo '$(srcdir)/'`mk_error.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-mk_error.Tpo $(DEPDIR)/libkrb5_la-mk_error.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='mk_error.c' object='libkrb5_la-mk_error.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-mk_error.lo `test -f 'mk_error.c' || echo '$(srcdir)/'`mk_error.c
++
++libkrb5_la-mk_priv.lo: mk_priv.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-mk_priv.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-mk_priv.Tpo -c -o libkrb5_la-mk_priv.lo `test -f 'mk_priv.c' || echo '$(srcdir)/'`mk_priv.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-mk_priv.Tpo $(DEPDIR)/libkrb5_la-mk_priv.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='mk_priv.c' object='libkrb5_la-mk_priv.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-mk_priv.lo `test -f 'mk_priv.c' || echo '$(srcdir)/'`mk_priv.c
++
++libkrb5_la-mk_rep.lo: mk_rep.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-mk_rep.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-mk_rep.Tpo -c -o libkrb5_la-mk_rep.lo `test -f 'mk_rep.c' || echo '$(srcdir)/'`mk_rep.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-mk_rep.Tpo $(DEPDIR)/libkrb5_la-mk_rep.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='mk_rep.c' object='libkrb5_la-mk_rep.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-mk_rep.lo `test -f 'mk_rep.c' || echo '$(srcdir)/'`mk_rep.c
++
++libkrb5_la-mk_req.lo: mk_req.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-mk_req.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-mk_req.Tpo -c -o libkrb5_la-mk_req.lo `test -f 'mk_req.c' || echo '$(srcdir)/'`mk_req.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-mk_req.Tpo $(DEPDIR)/libkrb5_la-mk_req.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='mk_req.c' object='libkrb5_la-mk_req.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-mk_req.lo `test -f 'mk_req.c' || echo '$(srcdir)/'`mk_req.c
++
++libkrb5_la-mk_req_ext.lo: mk_req_ext.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-mk_req_ext.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-mk_req_ext.Tpo -c -o libkrb5_la-mk_req_ext.lo `test -f 'mk_req_ext.c' || echo '$(srcdir)/'`mk_req_ext.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-mk_req_ext.Tpo $(DEPDIR)/libkrb5_la-mk_req_ext.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='mk_req_ext.c' object='libkrb5_la-mk_req_ext.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-mk_req_ext.lo `test -f 'mk_req_ext.c' || echo '$(srcdir)/'`mk_req_ext.c
++
++libkrb5_la-mk_safe.lo: mk_safe.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-mk_safe.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-mk_safe.Tpo -c -o libkrb5_la-mk_safe.lo `test -f 'mk_safe.c' || echo '$(srcdir)/'`mk_safe.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-mk_safe.Tpo $(DEPDIR)/libkrb5_la-mk_safe.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='mk_safe.c' object='libkrb5_la-mk_safe.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-mk_safe.lo `test -f 'mk_safe.c' || echo '$(srcdir)/'`mk_safe.c
++
++libkrb5_la-mit_glue.lo: mit_glue.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-mit_glue.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-mit_glue.Tpo -c -o libkrb5_la-mit_glue.lo `test -f 'mit_glue.c' || echo '$(srcdir)/'`mit_glue.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-mit_glue.Tpo $(DEPDIR)/libkrb5_la-mit_glue.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='mit_glue.c' object='libkrb5_la-mit_glue.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-mit_glue.lo `test -f 'mit_glue.c' || echo '$(srcdir)/'`mit_glue.c
++
++libkrb5_la-net_read.lo: net_read.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-net_read.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-net_read.Tpo -c -o libkrb5_la-net_read.lo `test -f 'net_read.c' || echo '$(srcdir)/'`net_read.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-net_read.Tpo $(DEPDIR)/libkrb5_la-net_read.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='net_read.c' object='libkrb5_la-net_read.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-net_read.lo `test -f 'net_read.c' || echo '$(srcdir)/'`net_read.c
++
++libkrb5_la-net_write.lo: net_write.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-net_write.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-net_write.Tpo -c -o libkrb5_la-net_write.lo `test -f 'net_write.c' || echo '$(srcdir)/'`net_write.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-net_write.Tpo $(DEPDIR)/libkrb5_la-net_write.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='net_write.c' object='libkrb5_la-net_write.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-net_write.lo `test -f 'net_write.c' || echo '$(srcdir)/'`net_write.c
++
++libkrb5_la-n-fold.lo: n-fold.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-n-fold.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-n-fold.Tpo -c -o libkrb5_la-n-fold.lo `test -f 'n-fold.c' || echo '$(srcdir)/'`n-fold.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-n-fold.Tpo $(DEPDIR)/libkrb5_la-n-fold.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='n-fold.c' object='libkrb5_la-n-fold.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-n-fold.lo `test -f 'n-fold.c' || echo '$(srcdir)/'`n-fold.c
++
++libkrb5_la-pac.lo: pac.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-pac.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-pac.Tpo -c -o libkrb5_la-pac.lo `test -f 'pac.c' || echo '$(srcdir)/'`pac.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-pac.Tpo $(DEPDIR)/libkrb5_la-pac.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='pac.c' object='libkrb5_la-pac.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-pac.lo `test -f 'pac.c' || echo '$(srcdir)/'`pac.c
++
++libkrb5_la-padata.lo: padata.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-padata.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-padata.Tpo -c -o libkrb5_la-padata.lo `test -f 'padata.c' || echo '$(srcdir)/'`padata.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-padata.Tpo $(DEPDIR)/libkrb5_la-padata.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='padata.c' object='libkrb5_la-padata.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-padata.lo `test -f 'padata.c' || echo '$(srcdir)/'`padata.c
++
++libkrb5_la-pcache.lo: pcache.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-pcache.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-pcache.Tpo -c -o libkrb5_la-pcache.lo `test -f 'pcache.c' || echo '$(srcdir)/'`pcache.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-pcache.Tpo $(DEPDIR)/libkrb5_la-pcache.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='pcache.c' object='libkrb5_la-pcache.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-pcache.lo `test -f 'pcache.c' || echo '$(srcdir)/'`pcache.c
++
++libkrb5_la-pkinit.lo: pkinit.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-pkinit.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-pkinit.Tpo -c -o libkrb5_la-pkinit.lo `test -f 'pkinit.c' || echo '$(srcdir)/'`pkinit.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-pkinit.Tpo $(DEPDIR)/libkrb5_la-pkinit.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='pkinit.c' object='libkrb5_la-pkinit.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-pkinit.lo `test -f 'pkinit.c' || echo '$(srcdir)/'`pkinit.c
++
++libkrb5_la-principal.lo: principal.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-principal.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-principal.Tpo -c -o libkrb5_la-principal.lo `test -f 'principal.c' || echo '$(srcdir)/'`principal.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-principal.Tpo $(DEPDIR)/libkrb5_la-principal.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='principal.c' object='libkrb5_la-principal.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-principal.lo `test -f 'principal.c' || echo '$(srcdir)/'`principal.c
++
++libkrb5_la-prog_setup.lo: prog_setup.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-prog_setup.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-prog_setup.Tpo -c -o libkrb5_la-prog_setup.lo `test -f 'prog_setup.c' || echo '$(srcdir)/'`prog_setup.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-prog_setup.Tpo $(DEPDIR)/libkrb5_la-prog_setup.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='prog_setup.c' object='libkrb5_la-prog_setup.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-prog_setup.lo `test -f 'prog_setup.c' || echo '$(srcdir)/'`prog_setup.c
++
++libkrb5_la-prompter_posix.lo: prompter_posix.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-prompter_posix.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-prompter_posix.Tpo -c -o libkrb5_la-prompter_posix.lo `test -f 'prompter_posix.c' || echo '$(srcdir)/'`prompter_posix.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-prompter_posix.Tpo $(DEPDIR)/libkrb5_la-prompter_posix.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='prompter_posix.c' object='libkrb5_la-prompter_posix.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-prompter_posix.lo `test -f 'prompter_posix.c' || echo '$(srcdir)/'`prompter_posix.c
++
++libkrb5_la-rd_cred.lo: rd_cred.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-rd_cred.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-rd_cred.Tpo -c -o libkrb5_la-rd_cred.lo `test -f 'rd_cred.c' || echo '$(srcdir)/'`rd_cred.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-rd_cred.Tpo $(DEPDIR)/libkrb5_la-rd_cred.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rd_cred.c' object='libkrb5_la-rd_cred.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-rd_cred.lo `test -f 'rd_cred.c' || echo '$(srcdir)/'`rd_cred.c
++
++libkrb5_la-rd_error.lo: rd_error.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-rd_error.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-rd_error.Tpo -c -o libkrb5_la-rd_error.lo `test -f 'rd_error.c' || echo '$(srcdir)/'`rd_error.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-rd_error.Tpo $(DEPDIR)/libkrb5_la-rd_error.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rd_error.c' object='libkrb5_la-rd_error.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-rd_error.lo `test -f 'rd_error.c' || echo '$(srcdir)/'`rd_error.c
++
++libkrb5_la-rd_priv.lo: rd_priv.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-rd_priv.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-rd_priv.Tpo -c -o libkrb5_la-rd_priv.lo `test -f 'rd_priv.c' || echo '$(srcdir)/'`rd_priv.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-rd_priv.Tpo $(DEPDIR)/libkrb5_la-rd_priv.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rd_priv.c' object='libkrb5_la-rd_priv.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-rd_priv.lo `test -f 'rd_priv.c' || echo '$(srcdir)/'`rd_priv.c
++
++libkrb5_la-rd_rep.lo: rd_rep.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-rd_rep.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-rd_rep.Tpo -c -o libkrb5_la-rd_rep.lo `test -f 'rd_rep.c' || echo '$(srcdir)/'`rd_rep.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-rd_rep.Tpo $(DEPDIR)/libkrb5_la-rd_rep.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rd_rep.c' object='libkrb5_la-rd_rep.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-rd_rep.lo `test -f 'rd_rep.c' || echo '$(srcdir)/'`rd_rep.c
++
++libkrb5_la-rd_req.lo: rd_req.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-rd_req.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-rd_req.Tpo -c -o libkrb5_la-rd_req.lo `test -f 'rd_req.c' || echo '$(srcdir)/'`rd_req.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-rd_req.Tpo $(DEPDIR)/libkrb5_la-rd_req.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rd_req.c' object='libkrb5_la-rd_req.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-rd_req.lo `test -f 'rd_req.c' || echo '$(srcdir)/'`rd_req.c
++
++libkrb5_la-rd_safe.lo: rd_safe.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-rd_safe.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-rd_safe.Tpo -c -o libkrb5_la-rd_safe.lo `test -f 'rd_safe.c' || echo '$(srcdir)/'`rd_safe.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-rd_safe.Tpo $(DEPDIR)/libkrb5_la-rd_safe.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rd_safe.c' object='libkrb5_la-rd_safe.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-rd_safe.lo `test -f 'rd_safe.c' || echo '$(srcdir)/'`rd_safe.c
++
++libkrb5_la-read_message.lo: read_message.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-read_message.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-read_message.Tpo -c -o libkrb5_la-read_message.lo `test -f 'read_message.c' || echo '$(srcdir)/'`read_message.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-read_message.Tpo $(DEPDIR)/libkrb5_la-read_message.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='read_message.c' object='libkrb5_la-read_message.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-read_message.lo `test -f 'read_message.c' || echo '$(srcdir)/'`read_message.c
++
++libkrb5_la-recvauth.lo: recvauth.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-recvauth.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-recvauth.Tpo -c -o libkrb5_la-recvauth.lo `test -f 'recvauth.c' || echo '$(srcdir)/'`recvauth.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-recvauth.Tpo $(DEPDIR)/libkrb5_la-recvauth.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='recvauth.c' object='libkrb5_la-recvauth.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-recvauth.lo `test -f 'recvauth.c' || echo '$(srcdir)/'`recvauth.c
++
++libkrb5_la-replay.lo: replay.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-replay.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-replay.Tpo -c -o libkrb5_la-replay.lo `test -f 'replay.c' || echo '$(srcdir)/'`replay.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-replay.Tpo $(DEPDIR)/libkrb5_la-replay.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='replay.c' object='libkrb5_la-replay.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-replay.lo `test -f 'replay.c' || echo '$(srcdir)/'`replay.c
++
++libkrb5_la-salt.lo: salt.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-salt.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-salt.Tpo -c -o libkrb5_la-salt.lo `test -f 'salt.c' || echo '$(srcdir)/'`salt.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-salt.Tpo $(DEPDIR)/libkrb5_la-salt.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='salt.c' object='libkrb5_la-salt.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-salt.lo `test -f 'salt.c' || echo '$(srcdir)/'`salt.c
++
++libkrb5_la-salt-aes.lo: salt-aes.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-salt-aes.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-salt-aes.Tpo -c -o libkrb5_la-salt-aes.lo `test -f 'salt-aes.c' || echo '$(srcdir)/'`salt-aes.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-salt-aes.Tpo $(DEPDIR)/libkrb5_la-salt-aes.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='salt-aes.c' object='libkrb5_la-salt-aes.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-salt-aes.lo `test -f 'salt-aes.c' || echo '$(srcdir)/'`salt-aes.c
++
++libkrb5_la-salt-arcfour.lo: salt-arcfour.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-salt-arcfour.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-salt-arcfour.Tpo -c -o libkrb5_la-salt-arcfour.lo `test -f 'salt-arcfour.c' || echo '$(srcdir)/'`salt-arcfour.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-salt-arcfour.Tpo $(DEPDIR)/libkrb5_la-salt-arcfour.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='salt-arcfour.c' object='libkrb5_la-salt-arcfour.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-salt-arcfour.lo `test -f 'salt-arcfour.c' || echo '$(srcdir)/'`salt-arcfour.c
++
++libkrb5_la-salt-des.lo: salt-des.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-salt-des.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-salt-des.Tpo -c -o libkrb5_la-salt-des.lo `test -f 'salt-des.c' || echo '$(srcdir)/'`salt-des.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-salt-des.Tpo $(DEPDIR)/libkrb5_la-salt-des.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='salt-des.c' object='libkrb5_la-salt-des.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-salt-des.lo `test -f 'salt-des.c' || echo '$(srcdir)/'`salt-des.c
++
++libkrb5_la-salt-des3.lo: salt-des3.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-salt-des3.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-salt-des3.Tpo -c -o libkrb5_la-salt-des3.lo `test -f 'salt-des3.c' || echo '$(srcdir)/'`salt-des3.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-salt-des3.Tpo $(DEPDIR)/libkrb5_la-salt-des3.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='salt-des3.c' object='libkrb5_la-salt-des3.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-salt-des3.lo `test -f 'salt-des3.c' || echo '$(srcdir)/'`salt-des3.c
++
++libkrb5_la-scache.lo: scache.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-scache.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-scache.Tpo -c -o libkrb5_la-scache.lo `test -f 'scache.c' || echo '$(srcdir)/'`scache.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-scache.Tpo $(DEPDIR)/libkrb5_la-scache.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='scache.c' object='libkrb5_la-scache.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-scache.lo `test -f 'scache.c' || echo '$(srcdir)/'`scache.c
++
++libkrb5_la-send_to_kdc.lo: send_to_kdc.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-send_to_kdc.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-send_to_kdc.Tpo -c -o libkrb5_la-send_to_kdc.lo `test -f 'send_to_kdc.c' || echo '$(srcdir)/'`send_to_kdc.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-send_to_kdc.Tpo $(DEPDIR)/libkrb5_la-send_to_kdc.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='send_to_kdc.c' object='libkrb5_la-send_to_kdc.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-send_to_kdc.lo `test -f 'send_to_kdc.c' || echo '$(srcdir)/'`send_to_kdc.c
++
++libkrb5_la-sendauth.lo: sendauth.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-sendauth.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-sendauth.Tpo -c -o libkrb5_la-sendauth.lo `test -f 'sendauth.c' || echo '$(srcdir)/'`sendauth.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-sendauth.Tpo $(DEPDIR)/libkrb5_la-sendauth.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='sendauth.c' object='libkrb5_la-sendauth.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-sendauth.lo `test -f 'sendauth.c' || echo '$(srcdir)/'`sendauth.c
++
++libkrb5_la-set_default_realm.lo: set_default_realm.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-set_default_realm.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-set_default_realm.Tpo -c -o libkrb5_la-set_default_realm.lo `test -f 'set_default_realm.c' || echo '$(srcdir)/'`set_default_realm.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-set_default_realm.Tpo $(DEPDIR)/libkrb5_la-set_default_realm.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='set_default_realm.c' object='libkrb5_la-set_default_realm.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-set_default_realm.lo `test -f 'set_default_realm.c' || echo '$(srcdir)/'`set_default_realm.c
++
++libkrb5_la-sock_principal.lo: sock_principal.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-sock_principal.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-sock_principal.Tpo -c -o libkrb5_la-sock_principal.lo `test -f 'sock_principal.c' || echo '$(srcdir)/'`sock_principal.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-sock_principal.Tpo $(DEPDIR)/libkrb5_la-sock_principal.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='sock_principal.c' object='libkrb5_la-sock_principal.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-sock_principal.lo `test -f 'sock_principal.c' || echo '$(srcdir)/'`sock_principal.c
++
++libkrb5_la-store.lo: store.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-store.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-store.Tpo -c -o libkrb5_la-store.lo `test -f 'store.c' || echo '$(srcdir)/'`store.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-store.Tpo $(DEPDIR)/libkrb5_la-store.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='store.c' object='libkrb5_la-store.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-store.lo `test -f 'store.c' || echo '$(srcdir)/'`store.c
++
++libkrb5_la-store-int.lo: store-int.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-store-int.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-store-int.Tpo -c -o libkrb5_la-store-int.lo `test -f 'store-int.c' || echo '$(srcdir)/'`store-int.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-store-int.Tpo $(DEPDIR)/libkrb5_la-store-int.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='store-int.c' object='libkrb5_la-store-int.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-store-int.lo `test -f 'store-int.c' || echo '$(srcdir)/'`store-int.c
++
++libkrb5_la-store_emem.lo: store_emem.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-store_emem.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-store_emem.Tpo -c -o libkrb5_la-store_emem.lo `test -f 'store_emem.c' || echo '$(srcdir)/'`store_emem.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-store_emem.Tpo $(DEPDIR)/libkrb5_la-store_emem.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='store_emem.c' object='libkrb5_la-store_emem.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-store_emem.lo `test -f 'store_emem.c' || echo '$(srcdir)/'`store_emem.c
++
++libkrb5_la-store_fd.lo: store_fd.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-store_fd.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-store_fd.Tpo -c -o libkrb5_la-store_fd.lo `test -f 'store_fd.c' || echo '$(srcdir)/'`store_fd.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-store_fd.Tpo $(DEPDIR)/libkrb5_la-store_fd.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='store_fd.c' object='libkrb5_la-store_fd.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-store_fd.lo `test -f 'store_fd.c' || echo '$(srcdir)/'`store_fd.c
++
++libkrb5_la-store_mem.lo: store_mem.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-store_mem.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-store_mem.Tpo -c -o libkrb5_la-store_mem.lo `test -f 'store_mem.c' || echo '$(srcdir)/'`store_mem.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-store_mem.Tpo $(DEPDIR)/libkrb5_la-store_mem.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='store_mem.c' object='libkrb5_la-store_mem.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-store_mem.lo `test -f 'store_mem.c' || echo '$(srcdir)/'`store_mem.c
++
++libkrb5_la-plugin.lo: plugin.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-plugin.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-plugin.Tpo -c -o libkrb5_la-plugin.lo `test -f 'plugin.c' || echo '$(srcdir)/'`plugin.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-plugin.Tpo $(DEPDIR)/libkrb5_la-plugin.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='plugin.c' object='libkrb5_la-plugin.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-plugin.lo `test -f 'plugin.c' || echo '$(srcdir)/'`plugin.c
++
++libkrb5_la-ticket.lo: ticket.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-ticket.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-ticket.Tpo -c -o libkrb5_la-ticket.lo `test -f 'ticket.c' || echo '$(srcdir)/'`ticket.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-ticket.Tpo $(DEPDIR)/libkrb5_la-ticket.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='ticket.c' object='libkrb5_la-ticket.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-ticket.lo `test -f 'ticket.c' || echo '$(srcdir)/'`ticket.c
++
++libkrb5_la-time.lo: time.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-time.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-time.Tpo -c -o libkrb5_la-time.lo `test -f 'time.c' || echo '$(srcdir)/'`time.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-time.Tpo $(DEPDIR)/libkrb5_la-time.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='time.c' object='libkrb5_la-time.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-time.lo `test -f 'time.c' || echo '$(srcdir)/'`time.c
++
++libkrb5_la-transited.lo: transited.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-transited.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-transited.Tpo -c -o libkrb5_la-transited.lo `test -f 'transited.c' || echo '$(srcdir)/'`transited.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-transited.Tpo $(DEPDIR)/libkrb5_la-transited.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='transited.c' object='libkrb5_la-transited.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-transited.lo `test -f 'transited.c' || echo '$(srcdir)/'`transited.c
++
++libkrb5_la-verify_init.lo: verify_init.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-verify_init.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-verify_init.Tpo -c -o libkrb5_la-verify_init.lo `test -f 'verify_init.c' || echo '$(srcdir)/'`verify_init.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-verify_init.Tpo $(DEPDIR)/libkrb5_la-verify_init.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='verify_init.c' object='libkrb5_la-verify_init.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-verify_init.lo `test -f 'verify_init.c' || echo '$(srcdir)/'`verify_init.c
++
++libkrb5_la-verify_user.lo: verify_user.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-verify_user.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-verify_user.Tpo -c -o libkrb5_la-verify_user.lo `test -f 'verify_user.c' || echo '$(srcdir)/'`verify_user.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-verify_user.Tpo $(DEPDIR)/libkrb5_la-verify_user.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='verify_user.c' object='libkrb5_la-verify_user.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-verify_user.lo `test -f 'verify_user.c' || echo '$(srcdir)/'`verify_user.c
++
++libkrb5_la-version.lo: version.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-version.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-version.Tpo -c -o libkrb5_la-version.lo `test -f 'version.c' || echo '$(srcdir)/'`version.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-version.Tpo $(DEPDIR)/libkrb5_la-version.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='version.c' object='libkrb5_la-version.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-version.lo `test -f 'version.c' || echo '$(srcdir)/'`version.c
++
++libkrb5_la-warn.lo: warn.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-warn.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-warn.Tpo -c -o libkrb5_la-warn.lo `test -f 'warn.c' || echo '$(srcdir)/'`warn.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-warn.Tpo $(DEPDIR)/libkrb5_la-warn.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='warn.c' object='libkrb5_la-warn.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-warn.lo `test -f 'warn.c' || echo '$(srcdir)/'`warn.c
++
++libkrb5_la-write_message.lo: write_message.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-write_message.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-write_message.Tpo -c -o libkrb5_la-write_message.lo `test -f 'write_message.c' || echo '$(srcdir)/'`write_message.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-write_message.Tpo $(DEPDIR)/libkrb5_la-write_message.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='write_message.c' object='libkrb5_la-write_message.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-write_message.lo `test -f 'write_message.c' || echo '$(srcdir)/'`write_message.c
++
++libkrb5_la-krb5_err.lo: krb5_err.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-krb5_err.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-krb5_err.Tpo -c -o libkrb5_la-krb5_err.lo `test -f 'krb5_err.c' || echo '$(srcdir)/'`krb5_err.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-krb5_err.Tpo $(DEPDIR)/libkrb5_la-krb5_err.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='krb5_err.c' object='libkrb5_la-krb5_err.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-krb5_err.lo `test -f 'krb5_err.c' || echo '$(srcdir)/'`krb5_err.c
++
++libkrb5_la-krb_err.lo: krb_err.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-krb_err.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-krb_err.Tpo -c -o libkrb5_la-krb_err.lo `test -f 'krb_err.c' || echo '$(srcdir)/'`krb_err.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-krb_err.Tpo $(DEPDIR)/libkrb5_la-krb_err.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='krb_err.c' object='libkrb5_la-krb_err.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-krb_err.lo `test -f 'krb_err.c' || echo '$(srcdir)/'`krb_err.c
++
++libkrb5_la-heim_err.lo: heim_err.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-heim_err.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-heim_err.Tpo -c -o libkrb5_la-heim_err.lo `test -f 'heim_err.c' || echo '$(srcdir)/'`heim_err.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-heim_err.Tpo $(DEPDIR)/libkrb5_la-heim_err.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='heim_err.c' object='libkrb5_la-heim_err.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-heim_err.lo `test -f 'heim_err.c' || echo '$(srcdir)/'`heim_err.c
++
++libkrb5_la-k524_err.lo: k524_err.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libkrb5_la-k524_err.lo -MD -MP -MF $(DEPDIR)/libkrb5_la-k524_err.Tpo -c -o libkrb5_la-k524_err.lo `test -f 'k524_err.c' || echo '$(srcdir)/'`k524_err.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libkrb5_la-k524_err.Tpo $(DEPDIR)/libkrb5_la-k524_err.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='k524_err.c' object='libkrb5_la-k524_err.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libkrb5_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libkrb5_la-k524_err.lo `test -f 'k524_err.c' || echo '$(srcdir)/'`k524_err.c
++
++librfc3961_la-crc.lo: crc.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-crc.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-crc.Tpo -c -o librfc3961_la-crc.lo `test -f 'crc.c' || echo '$(srcdir)/'`crc.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-crc.Tpo $(DEPDIR)/librfc3961_la-crc.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crc.c' object='librfc3961_la-crc.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-crc.lo `test -f 'crc.c' || echo '$(srcdir)/'`crc.c
++
++librfc3961_la-crypto.lo: crypto.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-crypto.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-crypto.Tpo -c -o librfc3961_la-crypto.lo `test -f 'crypto.c' || echo '$(srcdir)/'`crypto.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-crypto.Tpo $(DEPDIR)/librfc3961_la-crypto.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto.c' object='librfc3961_la-crypto.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-crypto.lo `test -f 'crypto.c' || echo '$(srcdir)/'`crypto.c
++
++librfc3961_la-crypto-aes.lo: crypto-aes.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-crypto-aes.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-crypto-aes.Tpo -c -o librfc3961_la-crypto-aes.lo `test -f 'crypto-aes.c' || echo '$(srcdir)/'`crypto-aes.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-crypto-aes.Tpo $(DEPDIR)/librfc3961_la-crypto-aes.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-aes.c' object='librfc3961_la-crypto-aes.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-crypto-aes.lo `test -f 'crypto-aes.c' || echo '$(srcdir)/'`crypto-aes.c
++
++librfc3961_la-crypto-algs.lo: crypto-algs.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-crypto-algs.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-crypto-algs.Tpo -c -o librfc3961_la-crypto-algs.lo `test -f 'crypto-algs.c' || echo '$(srcdir)/'`crypto-algs.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-crypto-algs.Tpo $(DEPDIR)/librfc3961_la-crypto-algs.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-algs.c' object='librfc3961_la-crypto-algs.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-crypto-algs.lo `test -f 'crypto-algs.c' || echo '$(srcdir)/'`crypto-algs.c
++
++librfc3961_la-crypto-arcfour.lo: crypto-arcfour.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-crypto-arcfour.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-crypto-arcfour.Tpo -c -o librfc3961_la-crypto-arcfour.lo `test -f 'crypto-arcfour.c' || echo '$(srcdir)/'`crypto-arcfour.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-crypto-arcfour.Tpo $(DEPDIR)/librfc3961_la-crypto-arcfour.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-arcfour.c' object='librfc3961_la-crypto-arcfour.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-crypto-arcfour.lo `test -f 'crypto-arcfour.c' || echo '$(srcdir)/'`crypto-arcfour.c
++
++librfc3961_la-crypto-des.lo: crypto-des.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-crypto-des.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-crypto-des.Tpo -c -o librfc3961_la-crypto-des.lo `test -f 'crypto-des.c' || echo '$(srcdir)/'`crypto-des.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-crypto-des.Tpo $(DEPDIR)/librfc3961_la-crypto-des.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-des.c' object='librfc3961_la-crypto-des.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-crypto-des.lo `test -f 'crypto-des.c' || echo '$(srcdir)/'`crypto-des.c
++
++librfc3961_la-crypto-des-common.lo: crypto-des-common.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-crypto-des-common.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-crypto-des-common.Tpo -c -o librfc3961_la-crypto-des-common.lo `test -f 'crypto-des-common.c' || echo '$(srcdir)/'`crypto-des-common.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-crypto-des-common.Tpo $(DEPDIR)/librfc3961_la-crypto-des-common.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-des-common.c' object='librfc3961_la-crypto-des-common.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-crypto-des-common.lo `test -f 'crypto-des-common.c' || echo '$(srcdir)/'`crypto-des-common.c
++
++librfc3961_la-crypto-des3.lo: crypto-des3.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-crypto-des3.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-crypto-des3.Tpo -c -o librfc3961_la-crypto-des3.lo `test -f 'crypto-des3.c' || echo '$(srcdir)/'`crypto-des3.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-crypto-des3.Tpo $(DEPDIR)/librfc3961_la-crypto-des3.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-des3.c' object='librfc3961_la-crypto-des3.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-crypto-des3.lo `test -f 'crypto-des3.c' || echo '$(srcdir)/'`crypto-des3.c
++
++librfc3961_la-crypto-evp.lo: crypto-evp.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-crypto-evp.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-crypto-evp.Tpo -c -o librfc3961_la-crypto-evp.lo `test -f 'crypto-evp.c' || echo '$(srcdir)/'`crypto-evp.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-crypto-evp.Tpo $(DEPDIR)/librfc3961_la-crypto-evp.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-evp.c' object='librfc3961_la-crypto-evp.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-crypto-evp.lo `test -f 'crypto-evp.c' || echo '$(srcdir)/'`crypto-evp.c
++
++librfc3961_la-crypto-null.lo: crypto-null.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-crypto-null.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-crypto-null.Tpo -c -o librfc3961_la-crypto-null.lo `test -f 'crypto-null.c' || echo '$(srcdir)/'`crypto-null.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-crypto-null.Tpo $(DEPDIR)/librfc3961_la-crypto-null.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-null.c' object='librfc3961_la-crypto-null.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-crypto-null.lo `test -f 'crypto-null.c' || echo '$(srcdir)/'`crypto-null.c
++
++librfc3961_la-crypto-pk.lo: crypto-pk.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-crypto-pk.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-crypto-pk.Tpo -c -o librfc3961_la-crypto-pk.lo `test -f 'crypto-pk.c' || echo '$(srcdir)/'`crypto-pk.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-crypto-pk.Tpo $(DEPDIR)/librfc3961_la-crypto-pk.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-pk.c' object='librfc3961_la-crypto-pk.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-crypto-pk.lo `test -f 'crypto-pk.c' || echo '$(srcdir)/'`crypto-pk.c
++
++librfc3961_la-crypto-rand.lo: crypto-rand.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-crypto-rand.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-crypto-rand.Tpo -c -o librfc3961_la-crypto-rand.lo `test -f 'crypto-rand.c' || echo '$(srcdir)/'`crypto-rand.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-crypto-rand.Tpo $(DEPDIR)/librfc3961_la-crypto-rand.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-rand.c' object='librfc3961_la-crypto-rand.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-crypto-rand.lo `test -f 'crypto-rand.c' || echo '$(srcdir)/'`crypto-rand.c
++
++librfc3961_la-crypto-stubs.lo: crypto-stubs.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-crypto-stubs.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-crypto-stubs.Tpo -c -o librfc3961_la-crypto-stubs.lo `test -f 'crypto-stubs.c' || echo '$(srcdir)/'`crypto-stubs.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-crypto-stubs.Tpo $(DEPDIR)/librfc3961_la-crypto-stubs.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='crypto-stubs.c' object='librfc3961_la-crypto-stubs.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-crypto-stubs.lo `test -f 'crypto-stubs.c' || echo '$(srcdir)/'`crypto-stubs.c
++
++librfc3961_la-data.lo: data.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-data.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-data.Tpo -c -o librfc3961_la-data.lo `test -f 'data.c' || echo '$(srcdir)/'`data.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-data.Tpo $(DEPDIR)/librfc3961_la-data.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='data.c' object='librfc3961_la-data.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-data.lo `test -f 'data.c' || echo '$(srcdir)/'`data.c
++
++librfc3961_la-error_string.lo: error_string.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-error_string.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-error_string.Tpo -c -o librfc3961_la-error_string.lo `test -f 'error_string.c' || echo '$(srcdir)/'`error_string.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-error_string.Tpo $(DEPDIR)/librfc3961_la-error_string.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='error_string.c' object='librfc3961_la-error_string.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-error_string.lo `test -f 'error_string.c' || echo '$(srcdir)/'`error_string.c
++
++librfc3961_la-keyblock.lo: keyblock.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-keyblock.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-keyblock.Tpo -c -o librfc3961_la-keyblock.lo `test -f 'keyblock.c' || echo '$(srcdir)/'`keyblock.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-keyblock.Tpo $(DEPDIR)/librfc3961_la-keyblock.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='keyblock.c' object='librfc3961_la-keyblock.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-keyblock.lo `test -f 'keyblock.c' || echo '$(srcdir)/'`keyblock.c
++
++librfc3961_la-n-fold.lo: n-fold.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-n-fold.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-n-fold.Tpo -c -o librfc3961_la-n-fold.lo `test -f 'n-fold.c' || echo '$(srcdir)/'`n-fold.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-n-fold.Tpo $(DEPDIR)/librfc3961_la-n-fold.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='n-fold.c' object='librfc3961_la-n-fold.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-n-fold.lo `test -f 'n-fold.c' || echo '$(srcdir)/'`n-fold.c
++
++librfc3961_la-salt.lo: salt.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-salt.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-salt.Tpo -c -o librfc3961_la-salt.lo `test -f 'salt.c' || echo '$(srcdir)/'`salt.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-salt.Tpo $(DEPDIR)/librfc3961_la-salt.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='salt.c' object='librfc3961_la-salt.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-salt.lo `test -f 'salt.c' || echo '$(srcdir)/'`salt.c
++
++librfc3961_la-salt-aes.lo: salt-aes.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-salt-aes.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-salt-aes.Tpo -c -o librfc3961_la-salt-aes.lo `test -f 'salt-aes.c' || echo '$(srcdir)/'`salt-aes.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-salt-aes.Tpo $(DEPDIR)/librfc3961_la-salt-aes.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='salt-aes.c' object='librfc3961_la-salt-aes.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-salt-aes.lo `test -f 'salt-aes.c' || echo '$(srcdir)/'`salt-aes.c
++
++librfc3961_la-salt-arcfour.lo: salt-arcfour.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-salt-arcfour.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-salt-arcfour.Tpo -c -o librfc3961_la-salt-arcfour.lo `test -f 'salt-arcfour.c' || echo '$(srcdir)/'`salt-arcfour.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-salt-arcfour.Tpo $(DEPDIR)/librfc3961_la-salt-arcfour.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='salt-arcfour.c' object='librfc3961_la-salt-arcfour.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-salt-arcfour.lo `test -f 'salt-arcfour.c' || echo '$(srcdir)/'`salt-arcfour.c
++
++librfc3961_la-salt-des.lo: salt-des.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-salt-des.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-salt-des.Tpo -c -o librfc3961_la-salt-des.lo `test -f 'salt-des.c' || echo '$(srcdir)/'`salt-des.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-salt-des.Tpo $(DEPDIR)/librfc3961_la-salt-des.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='salt-des.c' object='librfc3961_la-salt-des.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-salt-des.lo `test -f 'salt-des.c' || echo '$(srcdir)/'`salt-des.c
++
++librfc3961_la-salt-des3.lo: salt-des3.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-salt-des3.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-salt-des3.Tpo -c -o librfc3961_la-salt-des3.lo `test -f 'salt-des3.c' || echo '$(srcdir)/'`salt-des3.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-salt-des3.Tpo $(DEPDIR)/librfc3961_la-salt-des3.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='salt-des3.c' object='librfc3961_la-salt-des3.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-salt-des3.lo `test -f 'salt-des3.c' || echo '$(srcdir)/'`salt-des3.c
++
++librfc3961_la-store-int.lo: store-int.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-store-int.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-store-int.Tpo -c -o librfc3961_la-store-int.lo `test -f 'store-int.c' || echo '$(srcdir)/'`store-int.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-store-int.Tpo $(DEPDIR)/librfc3961_la-store-int.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='store-int.c' object='librfc3961_la-store-int.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-store-int.lo `test -f 'store-int.c' || echo '$(srcdir)/'`store-int.c
++
++librfc3961_la-warn.lo: warn.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT librfc3961_la-warn.lo -MD -MP -MF $(DEPDIR)/librfc3961_la-warn.Tpo -c -o librfc3961_la-warn.lo `test -f 'warn.c' || echo '$(srcdir)/'`warn.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/librfc3961_la-warn.Tpo $(DEPDIR)/librfc3961_la-warn.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='warn.c' object='librfc3961_la-warn.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(librfc3961_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o librfc3961_la-warn.lo `test -f 'warn.c' || echo '$(srcdir)/'`warn.c
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man3: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man3dir)" || $(MKDIR_P) "$(DESTDIR)$(man3dir)"
++	@list=''; test -n "$(man3dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.3[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^3][0-9a-z]*$$,3,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man3dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man3dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man3dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man3dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man3:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man3dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.3[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^3][0-9a-z]*$$,3,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man3dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man3dir)" && rm -f $$files; }
++install-man5: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man5dir)" || $(MKDIR_P) "$(DESTDIR)$(man5dir)"
++	@list=''; test -n "$(man5dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.5[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^5][0-9a-z]*$$,5,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man5dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man5dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man5dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man5dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man5:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man5dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.5[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^5][0-9a-z]*$$,5,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man5dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man5dir)" && rm -f $$files; }
++install-man8: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man8dir)" || $(MKDIR_P) "$(DESTDIR)$(man8dir)"
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man8dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man8dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man8dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man8dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man8:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man8dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.8[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^8][0-9a-z]*$$,8,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man8dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man8dir)" && rm -f $$files; }
++install-dist_includeHEADERS: $(dist_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(dist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-dist_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(dist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++install-krb5HEADERS: $(krb5_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(krb5dir)" || $(MKDIR_P) "$(DESTDIR)$(krb5dir)"
++	@list='$(krb5_HEADERS)'; test -n "$(krb5dir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(krb5dir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(krb5dir)" || exit $$?; \
++	done
++
++uninstall-krb5HEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(krb5_HEADERS)'; test -n "$(krb5dir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(krb5dir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(krb5dir)" && rm -f $$files
++install-nodist_includeHEADERS: $(nodist_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-nodist_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS) $(check_DATA)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(MANS) $(HEADERS) \
++		all-local
++install-binPROGRAMS: install-libLTLIBRARIES
++
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man3dir)" "$(DESTDIR)$(man5dir)" "$(DESTDIR)$(man8dir)" "$(DESTDIR)$(includedir)" "$(DESTDIR)$(krb5dir)" "$(DESTDIR)$(includedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-checkPROGRAMS clean-generic \
++	clean-libLTLIBRARIES clean-libtool clean-noinstLTLIBRARIES \
++	clean-noinstPROGRAMS mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-dist_includeHEADERS install-krb5HEADERS \
++	install-man install-nodist_includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man3 install-man5 install-man8
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-dist_includeHEADERS \
++	uninstall-krb5HEADERS uninstall-libLTLIBRARIES uninstall-man \
++	uninstall-nodist_includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man3 uninstall-man5 uninstall-man8
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-TESTS check-am \
++	check-local clean clean-binPROGRAMS clean-checkPROGRAMS \
++	clean-generic clean-libLTLIBRARIES clean-libtool \
++	clean-noinstLTLIBRARIES clean-noinstPROGRAMS ctags dist-hook \
++	distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-binPROGRAMS \
++	install-data install-data-am install-data-hook \
++	install-dist_includeHEADERS install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am \
++	install-krb5HEADERS install-libLTLIBRARIES install-man \
++	install-man3 install-man5 install-man8 \
++	install-nodist_includeHEADERS install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-binPROGRAMS \
++	uninstall-dist_includeHEADERS uninstall-hook \
++	uninstall-krb5HEADERS uninstall-libLTLIBRARIES uninstall-man \
++	uninstall-man3 uninstall-man5 uninstall-man8 \
++	uninstall-nodist_includeHEADERS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(libkrb5_la_OBJECTS) $(verify_krb5_conf_OBJECTS): $(srcdir)/krb5-protos.h $(srcdir)/krb5-private.h
++
++$(srcdir)/krb5-protos.h:
++	cd $(srcdir) && perl ../../cf/make-proto.pl -E KRB5_LIB -q -P comment -o krb5-protos.h $(dist_libkrb5_la_SOURCES) || rm -f krb5-protos.h
++
++$(srcdir)/krb5-private.h:
++	cd $(srcdir) && perl ../../cf/make-proto.pl -q -P comment -p krb5-private.h $(dist_libkrb5_la_SOURCES) || rm -f krb5-private.h
++
++$(libkrb5_la_OBJECTS): krb5_err.h krb_err.h heim_err.h k524_err.h crypto.h
++
++test_config_strings.out: test_config_strings.cfg
++	$(CP) $(srcdir)/test_config_strings.cfg test_config_strings.out
++
++#sysconf_DATA = krb5.moduli
++
++# to help stupid solaris make
++
++krb5_err.h: krb5_err.et
++
++krb_err.h: krb_err.et
++
++heim_err.h: heim_err.et
++
++k524_err.h: k524_err.et
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/ntlm/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/ntlm/Makefile.in	2010-12-29 04:07:13.887528454 +0100
+@@ -0,0 +1,1065 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(dist_include_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++@versionscript_TRUE@am__append_1 = $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-script.map
++TESTS = test_ntlm$(EXEEXT)
++check_PROGRAMS = test_ntlm$(EXEEXT)
++subdir = lib/ntlm
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(includedir)" \
++	"$(DESTDIR)$(includedir)"
++LTLIBRARIES = $(lib_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++libheimntlm_la_DEPENDENCIES = ../krb5/libkrb5.la $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++dist_libheimntlm_la_OBJECTS = ntlm.lo
++nodist_libheimntlm_la_OBJECTS = ntlm_err.lo
++libheimntlm_la_OBJECTS = $(dist_libheimntlm_la_OBJECTS) \
++	$(nodist_libheimntlm_la_OBJECTS)
++libheimntlm_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libheimntlm_la_LDFLAGS) $(LDFLAGS) -o $@
++test_ntlm_SOURCES = test_ntlm.c
++test_ntlm_OBJECTS = test_ntlm.$(OBJEXT)
++test_ntlm_LDADD = $(LDADD)
++test_ntlm_DEPENDENCIES = libheimntlm.la $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(dist_libheimntlm_la_SOURCES) \
++	$(nodist_libheimntlm_la_SOURCES) test_ntlm.c
++DIST_SOURCES = $(dist_libheimntlm_la_SOURCES) test_ntlm.c
++HEADERS = $(dist_include_HEADERS) $(nodist_include_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_hcrypto)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++lib_LTLIBRARIES = libheimntlm.la
++dist_include_HEADERS = heimntlm.h heimntlm-protos.h
++nodist_include_HEADERS = ntlm_err.h
++dist_libheimntlm_la_SOURCES = ntlm.c heimntlm.h
++nodist_libheimntlm_la_SOURCES = ntlm_err.c
++libheimntlm_la_LDFLAGS = -version-info 1:0:1 $(am__append_1)
++libheimntlm_la_LIBADD = \
++	../krb5/libkrb5.la \
++	$(LIB_hcrypto) \
++	$(LIBADD_roken)
++
++LDADD = libheimntlm.la $(LIB_roken)
++EXTRA_DIST = version-script.map ntlm_err.et
++CLEANFILES = \
++	ntlm_err.c ntlm_err.h
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/ntlm/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/ntlm/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libheimntlm.la: $(libheimntlm_la_OBJECTS) $(libheimntlm_la_DEPENDENCIES) 
++	$(libheimntlm_la_LINK) -rpath $(libdir) $(libheimntlm_la_OBJECTS) $(libheimntlm_la_LIBADD) $(LIBS)
++
++clean-checkPROGRAMS:
++	@list='$(check_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++test_ntlm$(EXEEXT): $(test_ntlm_OBJECTS) $(test_ntlm_DEPENDENCIES) 
++	@rm -f test_ntlm$(EXEEXT)
++	$(LINK) $(test_ntlm_OBJECTS) $(test_ntlm_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ntlm.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ntlm_err.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_ntlm.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-dist_includeHEADERS: $(dist_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(dist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-dist_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(dist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++install-nodist_includeHEADERS: $(nodist_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-nodist_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) $(HEADERS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(includedir)" "$(DESTDIR)$(includedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-checkPROGRAMS clean-generic clean-libLTLIBRARIES \
++	clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-dist_includeHEADERS \
++	install-nodist_includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-dist_includeHEADERS uninstall-libLTLIBRARIES \
++	uninstall-nodist_includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-TESTS check-am \
++	check-local clean clean-checkPROGRAMS clean-generic \
++	clean-libLTLIBRARIES clean-libtool ctags dist-hook distclean \
++	distclean-compile distclean-generic distclean-libtool \
++	distclean-tags distdir dvi dvi-am html html-am info info-am \
++	install install-am install-data install-data-am \
++	install-data-hook install-dist_includeHEADERS install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-libLTLIBRARIES install-man \
++	install-nodist_includeHEADERS install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-dist_includeHEADERS \
++	uninstall-hook uninstall-libLTLIBRARIES \
++	uninstall-nodist_includeHEADERS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++$(libheimntlm_la_OBJECTS): $(srcdir)/version-script.map
++
++$(srcdir)/heimntlm-protos.h:
++	cd $(srcdir) && perl ../../cf/make-proto.pl -q -P comment -o heimntlm-protos.h $(dist_libheimntlm_la_SOURCES) || rm -f heimntlm-protos.h
++
++$(libheimntlm_la_OBJECTS): $(srcdir)/heimntlm-protos.h ntlm_err.h
++
++ntlm_err.h: ntlm_err.et
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/otp/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/otp/Makefile.in	2010-12-29 04:07:14.117600021 +0100
+@@ -0,0 +1,1001 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(include_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++noinst_PROGRAMS = otptest$(EXEEXT)
++check_PROGRAMS = otptest$(EXEEXT)
++@versionscript_TRUE@am__append_1 = $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-script.map
++subdir = lib/otp
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(includedir)"
++LTLIBRARIES = $(lib_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++libotp_la_DEPENDENCIES = $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1) \
++	$(am__DEPENDENCIES_1)
++dist_libotp_la_OBJECTS = otp.lo otp_challenge.lo otp_db.lo otp_md.lo \
++	otp_parse.lo otp_print.lo otp_verify.lo
++@HAVE_DB3_TRUE@am__objects_1 = ndbm_wrap.lo
++@do_roken_rename_TRUE@am__objects_2 = snprintf.lo strcasecmp.lo \
++@do_roken_rename_TRUE@	strncasecmp.lo strlwr.lo strlcpy.lo \
++@do_roken_rename_TRUE@	strlcat.lo
++nodist_libotp_la_OBJECTS = $(am__objects_1) $(am__objects_2)
++libotp_la_OBJECTS = $(dist_libotp_la_OBJECTS) \
++	$(nodist_libotp_la_OBJECTS)
++libotp_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libotp_la_LDFLAGS) $(LDFLAGS) -o $@
++PROGRAMS = $(noinst_PROGRAMS)
++otptest_SOURCES = otptest.c
++otptest_OBJECTS = otptest.$(OBJEXT)
++otptest_DEPENDENCIES = libotp.la
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(dist_libotp_la_SOURCES) $(nodist_libotp_la_SOURCES) \
++	otptest.c
++DIST_SOURCES = $(dist_libotp_la_SOURCES) otptest.c
++HEADERS = $(include_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(INCLUDE_hcrypto) $(ROKEN_RENAME)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++otptest_LDADD = libotp.la
++include_HEADERS = otp.h
++lib_LTLIBRARIES = libotp.la
++libotp_la_LDFLAGS = -version-info 1:5:1 $(am__append_1)
++libotp_la_LIBADD = $(LIB_hcrypto) $(LIB_roken) $(LIB_NDBM)
++@HAVE_DB3_FALSE@ndbm_wrap = 
++@HAVE_DB3_TRUE@ndbm_wrap = ndbm_wrap.c ndbm_wrap.h
++dist_libotp_la_SOURCES = \
++	otp.c \
++	otp_challenge.c \
++	otp_db.c \
++	otp_md.c \
++	otp_parse.c \
++	otp_print.c \
++	otp_verify.c \
++	otp_locl.h \
++	otp_md.h \
++	roken_rename.h
++
++nodist_libotp_la_SOURCES = $(ndbm_wrap) $(ROKEN_SRCS)
++@do_roken_rename_TRUE@ROKEN_SRCS = snprintf.c strcasecmp.c strncasecmp.c strlwr.c strlcpy.c strlcat.c
++CLEANFILES = \
++	ndbm_wrap.c \
++	ndbm_wrap.h \
++	snprintf.c \
++	strcasecmp.c \
++	strlcat.c \
++	strlcpy.c \
++	strlwr.c \
++	strncasecmp.c
++
++EXTRA_DIST = version-script.map
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/otp/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/otp/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libotp.la: $(libotp_la_OBJECTS) $(libotp_la_DEPENDENCIES) 
++	$(libotp_la_LINK) -rpath $(libdir) $(libotp_la_OBJECTS) $(libotp_la_LIBADD) $(LIBS)
++
++clean-checkPROGRAMS:
++	@list='$(check_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++otptest$(EXEEXT): $(otptest_OBJECTS) $(otptest_DEPENDENCIES) 
++	@rm -f otptest$(EXEEXT)
++	$(LINK) $(otptest_OBJECTS) $(otptest_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ndbm_wrap.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/otp.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/otp_challenge.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/otp_db.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/otp_md.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/otp_parse.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/otp_print.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/otp_verify.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/otptest.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/snprintf.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/strcasecmp.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/strlcat.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/strlcpy.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/strlwr.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/strncasecmp.Plo@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-includeHEADERS: $(include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(HEADERS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(includedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-checkPROGRAMS clean-generic clean-libLTLIBRARIES \
++	clean-libtool clean-noinstPROGRAMS mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-includeHEADERS uninstall-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-checkPROGRAMS clean-generic clean-libLTLIBRARIES \
++	clean-libtool clean-noinstPROGRAMS ctags dist-hook distclean \
++	distclean-compile distclean-generic distclean-libtool \
++	distclean-tags distdir dvi dvi-am html html-am info info-am \
++	install install-am install-data install-data-am \
++	install-data-hook install-dvi install-dvi-am install-exec \
++	install-exec-am install-exec-hook install-html install-html-am \
++	install-includeHEADERS install-info install-info-am \
++	install-libLTLIBRARIES install-man install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-hook \
++	uninstall-includeHEADERS uninstall-libLTLIBRARIES
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(libotp_la_OBJECTS): $(ndbm_wrap)
++
++ndbm_wrap.c:
++	$(LN_S) $(srcdir)/../roken/ndbm_wrap.c .
++ndbm_wrap.h:
++	(echo '#define dbm_rename(X) __otp_ ## X'; cat $(srcdir)/../roken/ndbm_wrap.h) > ndbm_wrap.h
++
++snprintf.c:
++	$(LN_S) $(srcdir)/../roken/snprintf.c .
++strcasecmp.c:
++	$(LN_S) $(srcdir)/../roken/strcasecmp.c .
++strncasecmp.c:
++	$(LN_S) $(srcdir)/../roken/strncasecmp.c .
++strlwr.c:
++	$(LN_S) $(srcdir)/../roken/strlwr.c .
++strlcpy.c:
++	$(LN_S) $(srcdir)/../roken/strlcpy.c .
++strlcat.c:
++	$(LN_S) $(srcdir)/../roken/strlcat.c .
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/roken/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/roken/Makefile.in	2010-12-29 04:07:14.877836355 +0100
+@@ -0,0 +1,2005 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(am__dist_include_HEADERS_DIST) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog chown.c \
++	closefrom.c copyhostent.c daemon.c ecalloc.c emalloc.c \
++	erealloc.c err.c errx.c estrdup.c fchown.c flock.c fnmatch.c \
++	freeaddrinfo.c freehostent.c gai_strerror.c getaddrinfo.c \
++	getcap.c getcwd.c getdtablesize.c getegid.c geteuid.c getgid.c \
++	gethostname.c getifaddrs.c getipnodebyaddr.c getipnodebyname.c \
++	getnameinfo.c getopt.c gettimeofday.c getuid.c getusershell.c \
++	glob.c hstrerror.c inet_aton.c inet_ntop.c inet_pton.c \
++	initgroups.c innetgr.c install-sh iruserok.c localtime_r.c \
++	lstat.c memmove.c missing mkinstalldirs mkstemp.c putenv.c \
++	rcmd.c readv.c recvmsg.c sendmsg.c setegid.c setenv.c \
++	seteuid.c strcasecmp.c strdup.c strerror.c strftime.c \
++	strlcat.c strlcpy.c strlwr.c strncasecmp.c strndup.c strnlen.c \
++	strptime.c strsep.c strsep_copy.c strtok_r.c strupr.c swab.c \
++	timegm.c unsetenv.c verr.c verrx.c vsyslog.c vwarn.c vwarnx.c \
++	warn.c warnx.c writev.c
++@versionscript_TRUE@am__append_1 = $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-script.map
++@HAVE_DBHEADER_TRUE@am__append_2 = -I$(DBHEADER)
++noinst_PROGRAMS = snprintf-test$(EXEEXT) resolve-test$(EXEEXT) \
++	rkpty$(EXEEXT) $(am__EXEEXT_1)
++check_PROGRAMS = base64-test$(EXEEXT) getaddrinfo-test$(EXEEXT) \
++	getifaddrs-test$(EXEEXT) hex-test$(EXEEXT) \
++	test-readenv$(EXEEXT) parse_bytes-test$(EXEEXT) \
++	parse_reply-test$(EXEEXT) parse_time-test$(EXEEXT) \
++	snprintf-test$(EXEEXT) strpftime-test$(EXEEXT)
++@have_socket_wrapper_TRUE@am__append_3 = socket_wrapper.c socket_wrapper.h
++@have_socket_wrapper_TRUE@am__append_4 = socket_wrapper.h
++
++# Make make-roken deprecated in 1.4 when we know that roken-h-process.pl works
++@CROSS_COMPILE_FALSE@am__append_5 = make-roken
++@CROSS_COMPILE_FALSE@am__append_6 = make-roken.c
++subdir = lib/roken
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(man3dir)" \
++	"$(DESTDIR)$(includedir)" "$(DESTDIR)$(includedir)" \
++	"$(DESTDIR)$(rokenincludedir)"
++LTLIBRARIES = $(lib_LTLIBRARIES) $(noinst_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++libroken_la_DEPENDENCIES = @LTLIBOBJS@ $(am__DEPENDENCIES_1)
++am__libroken_la_SOURCES_DIST = base64.c bswap.c concat.c cloexec.c \
++	ct.c doxygen.c dumpdata.c environment.c eread.c esetenv.c \
++	ewrite.c getaddrinfo_hostspec.c get_default_username.c \
++	get_window_size.c getarg.c getnameinfo_verified.c \
++	getprogname.c h_errno.c hex.c hostent_find_fqdn.c issuid.c \
++	k_getpwnam.c k_getpwuid.c mini_inetd.c net_read.c net_write.c \
++	parse_bytes.c parse_time.c parse_units.c qsort.c rand.c \
++	realloc.c resolve.c roken_gethostby.c rtbl.c rtbl.h \
++	setprogname.c signal.c simple_exec.c snprintf.c socket.c \
++	strcollect.c strerror_r.c strpool.c timeval.c tm2time.c \
++	unvis.c verify.c vis.c warnerr.c write_pid.c xfree.c xdbm.h \
++	socket_wrapper.c socket_wrapper.h
++@have_socket_wrapper_TRUE@am__objects_1 =  \
++@have_socket_wrapper_TRUE@	libroken_la-socket_wrapper.lo
++am_libroken_la_OBJECTS = libroken_la-base64.lo libroken_la-bswap.lo \
++	libroken_la-concat.lo libroken_la-cloexec.lo libroken_la-ct.lo \
++	libroken_la-doxygen.lo libroken_la-dumpdata.lo \
++	libroken_la-environment.lo libroken_la-eread.lo \
++	libroken_la-esetenv.lo libroken_la-ewrite.lo \
++	libroken_la-getaddrinfo_hostspec.lo \
++	libroken_la-get_default_username.lo \
++	libroken_la-get_window_size.lo libroken_la-getarg.lo \
++	libroken_la-getnameinfo_verified.lo libroken_la-getprogname.lo \
++	libroken_la-h_errno.lo libroken_la-hex.lo \
++	libroken_la-hostent_find_fqdn.lo libroken_la-issuid.lo \
++	libroken_la-k_getpwnam.lo libroken_la-k_getpwuid.lo \
++	libroken_la-mini_inetd.lo libroken_la-net_read.lo \
++	libroken_la-net_write.lo libroken_la-parse_bytes.lo \
++	libroken_la-parse_time.lo libroken_la-parse_units.lo \
++	libroken_la-qsort.lo libroken_la-rand.lo \
++	libroken_la-realloc.lo libroken_la-resolve.lo \
++	libroken_la-roken_gethostby.lo libroken_la-rtbl.lo \
++	libroken_la-setprogname.lo libroken_la-signal.lo \
++	libroken_la-simple_exec.lo libroken_la-snprintf.lo \
++	libroken_la-socket.lo libroken_la-strcollect.lo \
++	libroken_la-strerror_r.lo libroken_la-strpool.lo \
++	libroken_la-timeval.lo libroken_la-tm2time.lo \
++	libroken_la-unvis.lo libroken_la-verify.lo libroken_la-vis.lo \
++	libroken_la-warnerr.lo libroken_la-write_pid.lo \
++	libroken_la-xfree.lo $(am__objects_1)
++libroken_la_OBJECTS = $(am_libroken_la_OBJECTS)
++libroken_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libroken_la_LDFLAGS) $(LDFLAGS) -o $@
++libtest_la_LIBADD =
++am_libtest_la_OBJECTS = libtest_la-strftime.lo libtest_la-strptime.lo \
++	libtest_la-snprintf.lo
++libtest_la_OBJECTS = $(am_libtest_la_OBJECTS)
++libtest_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(libtest_la_CFLAGS) \
++	$(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
++@CROSS_COMPILE_FALSE@am__EXEEXT_1 = make-roken$(EXEEXT)
++PROGRAMS = $(noinst_PROGRAMS)
++base64_test_SOURCES = base64-test.c
++base64_test_OBJECTS = base64-test.$(OBJEXT)
++base64_test_LDADD = $(LDADD)
++base64_test_DEPENDENCIES = libroken.la
++getaddrinfo_test_SOURCES = getaddrinfo-test.c
++getaddrinfo_test_OBJECTS = getaddrinfo-test.$(OBJEXT)
++getaddrinfo_test_LDADD = $(LDADD)
++getaddrinfo_test_DEPENDENCIES = libroken.la
++getifaddrs_test_SOURCES = getifaddrs-test.c
++getifaddrs_test_OBJECTS = getifaddrs-test.$(OBJEXT)
++getifaddrs_test_LDADD = $(LDADD)
++getifaddrs_test_DEPENDENCIES = libroken.la
++hex_test_SOURCES = hex-test.c
++hex_test_OBJECTS = hex-test.$(OBJEXT)
++hex_test_LDADD = $(LDADD)
++hex_test_DEPENDENCIES = libroken.la
++@CROSS_COMPILE_FALSE@nodist_make_roken_OBJECTS = make-roken.$(OBJEXT)
++make_roken_OBJECTS = $(nodist_make_roken_OBJECTS)
++make_roken_DEPENDENCIES =
++parse_bytes_test_SOURCES = parse_bytes-test.c
++parse_bytes_test_OBJECTS = parse_bytes-test.$(OBJEXT)
++parse_bytes_test_LDADD = $(LDADD)
++parse_bytes_test_DEPENDENCIES = libroken.la
++am_parse_reply_test_OBJECTS =  \
++	parse_reply_test-parse_reply-test.$(OBJEXT) \
++	parse_reply_test-resolve.$(OBJEXT)
++parse_reply_test_OBJECTS = $(am_parse_reply_test_OBJECTS)
++parse_reply_test_LDADD = $(LDADD)
++parse_reply_test_DEPENDENCIES = libroken.la
++parse_reply_test_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(parse_reply_test_CFLAGS) \
++	$(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
++am_parse_time_test_OBJECTS = parse_time-test.$(OBJEXT) \
++	test-mem.$(OBJEXT)
++parse_time_test_OBJECTS = $(am_parse_time_test_OBJECTS)
++parse_time_test_LDADD = $(LDADD)
++parse_time_test_DEPENDENCIES = libroken.la
++am_resolve_test_OBJECTS = resolve-test.$(OBJEXT)
++resolve_test_OBJECTS = $(am_resolve_test_OBJECTS)
++resolve_test_LDADD = $(LDADD)
++resolve_test_DEPENDENCIES = libroken.la
++rkpty_SOURCES = rkpty.c
++rkpty_OBJECTS = rkpty.$(OBJEXT)
++rkpty_DEPENDENCIES = $(am__DEPENDENCIES_1) $(LDADD)
++am_snprintf_test_OBJECTS = snprintf_test-snprintf-test.$(OBJEXT)
++snprintf_test_OBJECTS = $(am_snprintf_test_OBJECTS)
++snprintf_test_DEPENDENCIES = libtest.la $(LDADD)
++snprintf_test_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(snprintf_test_CFLAGS) \
++	$(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
++am_strpftime_test_OBJECTS = strpftime_test-strpftime-test.$(OBJEXT)
++strpftime_test_OBJECTS = $(am_strpftime_test_OBJECTS)
++strpftime_test_DEPENDENCIES = libtest.la $(LDADD)
++strpftime_test_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(strpftime_test_CFLAGS) \
++	$(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
++am_test_readenv_OBJECTS = test-readenv.$(OBJEXT) test-mem.$(OBJEXT)
++test_readenv_OBJECTS = $(am_test_readenv_OBJECTS)
++test_readenv_LDADD = $(LDADD)
++test_readenv_DEPENDENCIES = libroken.la
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(libroken_la_SOURCES) $(EXTRA_libroken_la_SOURCES) \
++	$(libtest_la_SOURCES) base64-test.c getaddrinfo-test.c \
++	getifaddrs-test.c hex-test.c $(nodist_make_roken_SOURCES) \
++	parse_bytes-test.c $(parse_reply_test_SOURCES) \
++	$(parse_time_test_SOURCES) $(resolve_test_SOURCES) rkpty.c \
++	$(snprintf_test_SOURCES) $(strpftime_test_SOURCES) \
++	$(test_readenv_SOURCES)
++DIST_SOURCES = $(am__libroken_la_SOURCES_DIST) \
++	$(EXTRA_libroken_la_SOURCES) $(libtest_la_SOURCES) \
++	base64-test.c getaddrinfo-test.c getifaddrs-test.c hex-test.c \
++	parse_bytes-test.c $(parse_reply_test_SOURCES) \
++	$(parse_time_test_SOURCES) $(resolve_test_SOURCES) rkpty.c \
++	$(snprintf_test_SOURCES) $(strpftime_test_SOURCES) \
++	$(test_readenv_SOURCES)
++man3dir = $(mandir)/man3
++MANS = $(man_MANS)
++am__dist_include_HEADERS_DIST = base64.h getarg.h hex.h parse_bytes.h \
++	parse_time.h parse_units.h resolve.h roken-common.h rtbl.h \
++	xdbm.h socket_wrapper.h
++HEADERS = $(dist_include_HEADERS) $(nodist_include_HEADERS) \
++	$(nodist_rokeninclude_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .hin
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(libroken_la_CPPFLAGS) \
++	$(am__append_2)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++ACLOCAL_AMFLAGS = -I ../../cf
++CLEANFILES = roken.h make-roken.c $(XHEADERS) err.h fnmatch.h glob.h \
++	ifaddrs.h vis.h
++lib_LTLIBRARIES = libroken.la
++libroken_la_LDFLAGS = -version-info 19:0:1 $(am__append_1)
++libroken_la_CPPFLAGS = -DBUILD_ROKEN_LIB
++TESTS = $(check_PROGRAMS)
++LDADD = libroken.la
++make_roken_LDADD = 
++noinst_LTLIBRARIES = libtest.la
++libtest_la_SOURCES = strftime.c strptime.c snprintf.c
++libtest_la_CFLAGS = -DTEST_SNPRINTF -DTEST_STRPFTIME
++parse_reply_test_SOURCES = parse_reply-test.c resolve.c
++parse_reply_test_CFLAGS = -DTEST_RESOLVE
++test_readenv_SOURCES = test-readenv.c test-mem.c
++rkpty_LDADD = $(LIB_openpty) $(LDADD)
++parse_time_test_SOURCES = parse_time-test.c test-mem.c
++strpftime_test_SOURCES = strpftime-test.c strpftime-test.h
++strpftime_test_LDADD = libtest.la $(LDADD)
++strpftime_test_CFLAGS = -DTEST_STRPFTIME
++snprintf_test_SOURCES = snprintf-test.c
++snprintf_test_LDADD = libtest.la $(LDADD)
++snprintf_test_CFLAGS = -DTEST_SNPRINTF
++resolve_test_SOURCES = resolve-test.c
++libroken_la_SOURCES = base64.c bswap.c concat.c cloexec.c ct.c \
++	doxygen.c dumpdata.c environment.c eread.c esetenv.c ewrite.c \
++	getaddrinfo_hostspec.c get_default_username.c \
++	get_window_size.c getarg.c getnameinfo_verified.c \
++	getprogname.c h_errno.c hex.c hostent_find_fqdn.c issuid.c \
++	k_getpwnam.c k_getpwuid.c mini_inetd.c net_read.c net_write.c \
++	parse_bytes.c parse_time.c parse_units.c qsort.c rand.c \
++	realloc.c resolve.c roken_gethostby.c rtbl.c rtbl.h \
++	setprogname.c signal.c simple_exec.c snprintf.c socket.c \
++	strcollect.c strerror_r.c strpool.c timeval.c tm2time.c \
++	unvis.c verify.c vis.c warnerr.c write_pid.c xfree.c xdbm.h \
++	$(am__append_3)
++EXTRA_libroken_la_SOURCES = \
++	err.hin			\
++	glob.hin		\
++	fnmatch.hin		\
++	ifaddrs.hin		\
++	vis.hin	
++
++libroken_la_LIBADD = @LTLIBOBJS@ $(LIB_crypt)
++BUILT_SOURCES = roken.h $(am__append_6)
++@have_err_h_FALSE@err_h = err.h
++@have_err_h_TRUE@err_h = 
++@have_fnmatch_h_FALSE@fnmatch_h = fnmatch.h
++@have_fnmatch_h_TRUE@fnmatch_h = 
++@have_glob_h_FALSE@glob_h = glob.h
++@have_glob_h_TRUE@glob_h = 
++@have_ifaddrs_h_FALSE@ifaddrs_h = ifaddrs.h
++@have_ifaddrs_h_TRUE@ifaddrs_h = 
++@have_vis_h_FALSE@vis_h = vis.h
++@have_vis_h_TRUE@vis_h = 
++XHEADERS = $(err_h) $(fnmatch_h) $(glob_h) $(ifaddrs_h) $(vis_h)
++dist_include_HEADERS = base64.h getarg.h hex.h parse_bytes.h \
++	parse_time.h parse_units.h resolve.h roken-common.h rtbl.h \
++	xdbm.h $(am__append_4)
++build_HEADERZ = test-mem.h $(XHEADERS)
++nodist_include_HEADERS = roken.h
++rokenincludedir = $(includedir)/roken
++nodist_rokeninclude_HEADERS = $(XHEADERS)
++man_MANS = getarg.3 parse_time.3 rtbl.3 ecalloc.3
++@CROSS_COMPILE_FALSE@nodist_make_roken_SOURCES = make-roken.c
++EXTRA_DIST = \
++	roken.awk roken.h.in \
++	$(man_MANS) \
++	test-mem.h \
++	ndbm_wrap.c \
++	ndbm_wrap.h \
++	version-script.map
++
++all: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .hin .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/roken/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/roken/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++
++clean-noinstLTLIBRARIES:
++	-test -z "$(noinst_LTLIBRARIES)" || rm -f $(noinst_LTLIBRARIES)
++	@list='$(noinst_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libroken.la: $(libroken_la_OBJECTS) $(libroken_la_DEPENDENCIES) 
++	$(libroken_la_LINK) -rpath $(libdir) $(libroken_la_OBJECTS) $(libroken_la_LIBADD) $(LIBS)
++libtest.la: $(libtest_la_OBJECTS) $(libtest_la_DEPENDENCIES) 
++	$(libtest_la_LINK)  $(libtest_la_OBJECTS) $(libtest_la_LIBADD) $(LIBS)
++
++clean-checkPROGRAMS:
++	@list='$(check_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-noinstPROGRAMS:
++	@list='$(noinst_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++base64-test$(EXEEXT): $(base64_test_OBJECTS) $(base64_test_DEPENDENCIES) 
++	@rm -f base64-test$(EXEEXT)
++	$(LINK) $(base64_test_OBJECTS) $(base64_test_LDADD) $(LIBS)
++getaddrinfo-test$(EXEEXT): $(getaddrinfo_test_OBJECTS) $(getaddrinfo_test_DEPENDENCIES) 
++	@rm -f getaddrinfo-test$(EXEEXT)
++	$(LINK) $(getaddrinfo_test_OBJECTS) $(getaddrinfo_test_LDADD) $(LIBS)
++getifaddrs-test$(EXEEXT): $(getifaddrs_test_OBJECTS) $(getifaddrs_test_DEPENDENCIES) 
++	@rm -f getifaddrs-test$(EXEEXT)
++	$(LINK) $(getifaddrs_test_OBJECTS) $(getifaddrs_test_LDADD) $(LIBS)
++hex-test$(EXEEXT): $(hex_test_OBJECTS) $(hex_test_DEPENDENCIES) 
++	@rm -f hex-test$(EXEEXT)
++	$(LINK) $(hex_test_OBJECTS) $(hex_test_LDADD) $(LIBS)
++make-roken$(EXEEXT): $(make_roken_OBJECTS) $(make_roken_DEPENDENCIES) 
++	@rm -f make-roken$(EXEEXT)
++	$(LINK) $(make_roken_OBJECTS) $(make_roken_LDADD) $(LIBS)
++parse_bytes-test$(EXEEXT): $(parse_bytes_test_OBJECTS) $(parse_bytes_test_DEPENDENCIES) 
++	@rm -f parse_bytes-test$(EXEEXT)
++	$(LINK) $(parse_bytes_test_OBJECTS) $(parse_bytes_test_LDADD) $(LIBS)
++parse_reply-test$(EXEEXT): $(parse_reply_test_OBJECTS) $(parse_reply_test_DEPENDENCIES) 
++	@rm -f parse_reply-test$(EXEEXT)
++	$(parse_reply_test_LINK) $(parse_reply_test_OBJECTS) $(parse_reply_test_LDADD) $(LIBS)
++parse_time-test$(EXEEXT): $(parse_time_test_OBJECTS) $(parse_time_test_DEPENDENCIES) 
++	@rm -f parse_time-test$(EXEEXT)
++	$(LINK) $(parse_time_test_OBJECTS) $(parse_time_test_LDADD) $(LIBS)
++resolve-test$(EXEEXT): $(resolve_test_OBJECTS) $(resolve_test_DEPENDENCIES) 
++	@rm -f resolve-test$(EXEEXT)
++	$(LINK) $(resolve_test_OBJECTS) $(resolve_test_LDADD) $(LIBS)
++rkpty$(EXEEXT): $(rkpty_OBJECTS) $(rkpty_DEPENDENCIES) 
++	@rm -f rkpty$(EXEEXT)
++	$(LINK) $(rkpty_OBJECTS) $(rkpty_LDADD) $(LIBS)
++snprintf-test$(EXEEXT): $(snprintf_test_OBJECTS) $(snprintf_test_DEPENDENCIES) 
++	@rm -f snprintf-test$(EXEEXT)
++	$(snprintf_test_LINK) $(snprintf_test_OBJECTS) $(snprintf_test_LDADD) $(LIBS)
++strpftime-test$(EXEEXT): $(strpftime_test_OBJECTS) $(strpftime_test_DEPENDENCIES) 
++	@rm -f strpftime-test$(EXEEXT)
++	$(strpftime_test_LINK) $(strpftime_test_OBJECTS) $(strpftime_test_LDADD) $(LIBS)
++test-readenv$(EXEEXT): $(test_readenv_OBJECTS) $(test_readenv_DEPENDENCIES) 
++	@rm -f test-readenv$(EXEEXT)
++	$(LINK) $(test_readenv_OBJECTS) $(test_readenv_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/chown.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/closefrom.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/copyhostent.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/daemon.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/ecalloc.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/emalloc.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/erealloc.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/err.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/errx.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/estrdup.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/fchown.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/flock.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/fnmatch.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/freeaddrinfo.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/freehostent.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/gai_strerror.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/getaddrinfo.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/getcap.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/getcwd.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/getdtablesize.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/getegid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/geteuid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/getgid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/gethostname.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/getifaddrs.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/getipnodebyaddr.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/getipnodebyname.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/getnameinfo.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/getopt.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/gettimeofday.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/getuid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/getusershell.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/glob.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/hstrerror.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/inet_aton.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/inet_ntop.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/inet_pton.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/initgroups.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/innetgr.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/iruserok.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/localtime_r.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/lstat.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/memmove.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/mkstemp.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/putenv.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/rcmd.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/readv.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/recvmsg.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/sendmsg.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/setegid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/setenv.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/seteuid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strcasecmp.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strdup.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strerror.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strftime.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strlcat.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strlcpy.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strlwr.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strncasecmp.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strndup.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strnlen.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strptime.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strsep.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strsep_copy.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strtok_r.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/strupr.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/swab.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/timegm.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/unsetenv.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/verr.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/verrx.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/vsyslog.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/vwarn.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/vwarnx.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/warn.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/warnx.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@$(DEPDIR)/writev.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/base64-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/getaddrinfo-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/getifaddrs-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/hex-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-base64.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-bswap.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-cloexec.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-concat.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-ct.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-doxygen.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-dumpdata.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-environment.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-eread.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-esetenv.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-ewrite.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-get_default_username.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-get_window_size.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-getaddrinfo_hostspec.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-getarg.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-getnameinfo_verified.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-getprogname.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-h_errno.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-hex.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-hostent_find_fqdn.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-issuid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-k_getpwnam.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-k_getpwuid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-mini_inetd.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-net_read.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-net_write.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-parse_bytes.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-parse_time.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-parse_units.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-qsort.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-rand.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-realloc.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-resolve.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-roken_gethostby.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-rtbl.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-setprogname.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-signal.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-simple_exec.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-snprintf.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-socket.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-socket_wrapper.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-strcollect.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-strerror_r.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-strpool.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-timeval.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-tm2time.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-unvis.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-verify.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-vis.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-warnerr.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-write_pid.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libroken_la-xfree.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libtest_la-snprintf.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libtest_la-strftime.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/libtest_la-strptime.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/make-roken.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/parse_bytes-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/parse_reply_test-parse_reply-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/parse_reply_test-resolve.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/parse_time-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/resolve-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/rkpty.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/snprintf_test-snprintf-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/strpftime_test-strpftime-test.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test-mem.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test-readenv.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++libroken_la-base64.lo: base64.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-base64.lo -MD -MP -MF $(DEPDIR)/libroken_la-base64.Tpo -c -o libroken_la-base64.lo `test -f 'base64.c' || echo '$(srcdir)/'`base64.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-base64.Tpo $(DEPDIR)/libroken_la-base64.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='base64.c' object='libroken_la-base64.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-base64.lo `test -f 'base64.c' || echo '$(srcdir)/'`base64.c
++
++libroken_la-bswap.lo: bswap.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-bswap.lo -MD -MP -MF $(DEPDIR)/libroken_la-bswap.Tpo -c -o libroken_la-bswap.lo `test -f 'bswap.c' || echo '$(srcdir)/'`bswap.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-bswap.Tpo $(DEPDIR)/libroken_la-bswap.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='bswap.c' object='libroken_la-bswap.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-bswap.lo `test -f 'bswap.c' || echo '$(srcdir)/'`bswap.c
++
++libroken_la-concat.lo: concat.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-concat.lo -MD -MP -MF $(DEPDIR)/libroken_la-concat.Tpo -c -o libroken_la-concat.lo `test -f 'concat.c' || echo '$(srcdir)/'`concat.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-concat.Tpo $(DEPDIR)/libroken_la-concat.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='concat.c' object='libroken_la-concat.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-concat.lo `test -f 'concat.c' || echo '$(srcdir)/'`concat.c
++
++libroken_la-cloexec.lo: cloexec.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-cloexec.lo -MD -MP -MF $(DEPDIR)/libroken_la-cloexec.Tpo -c -o libroken_la-cloexec.lo `test -f 'cloexec.c' || echo '$(srcdir)/'`cloexec.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-cloexec.Tpo $(DEPDIR)/libroken_la-cloexec.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='cloexec.c' object='libroken_la-cloexec.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-cloexec.lo `test -f 'cloexec.c' || echo '$(srcdir)/'`cloexec.c
++
++libroken_la-ct.lo: ct.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-ct.lo -MD -MP -MF $(DEPDIR)/libroken_la-ct.Tpo -c -o libroken_la-ct.lo `test -f 'ct.c' || echo '$(srcdir)/'`ct.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-ct.Tpo $(DEPDIR)/libroken_la-ct.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='ct.c' object='libroken_la-ct.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-ct.lo `test -f 'ct.c' || echo '$(srcdir)/'`ct.c
++
++libroken_la-doxygen.lo: doxygen.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-doxygen.lo -MD -MP -MF $(DEPDIR)/libroken_la-doxygen.Tpo -c -o libroken_la-doxygen.lo `test -f 'doxygen.c' || echo '$(srcdir)/'`doxygen.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-doxygen.Tpo $(DEPDIR)/libroken_la-doxygen.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='doxygen.c' object='libroken_la-doxygen.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-doxygen.lo `test -f 'doxygen.c' || echo '$(srcdir)/'`doxygen.c
++
++libroken_la-dumpdata.lo: dumpdata.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-dumpdata.lo -MD -MP -MF $(DEPDIR)/libroken_la-dumpdata.Tpo -c -o libroken_la-dumpdata.lo `test -f 'dumpdata.c' || echo '$(srcdir)/'`dumpdata.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-dumpdata.Tpo $(DEPDIR)/libroken_la-dumpdata.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='dumpdata.c' object='libroken_la-dumpdata.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-dumpdata.lo `test -f 'dumpdata.c' || echo '$(srcdir)/'`dumpdata.c
++
++libroken_la-environment.lo: environment.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-environment.lo -MD -MP -MF $(DEPDIR)/libroken_la-environment.Tpo -c -o libroken_la-environment.lo `test -f 'environment.c' || echo '$(srcdir)/'`environment.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-environment.Tpo $(DEPDIR)/libroken_la-environment.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='environment.c' object='libroken_la-environment.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-environment.lo `test -f 'environment.c' || echo '$(srcdir)/'`environment.c
++
++libroken_la-eread.lo: eread.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-eread.lo -MD -MP -MF $(DEPDIR)/libroken_la-eread.Tpo -c -o libroken_la-eread.lo `test -f 'eread.c' || echo '$(srcdir)/'`eread.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-eread.Tpo $(DEPDIR)/libroken_la-eread.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='eread.c' object='libroken_la-eread.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-eread.lo `test -f 'eread.c' || echo '$(srcdir)/'`eread.c
++
++libroken_la-esetenv.lo: esetenv.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-esetenv.lo -MD -MP -MF $(DEPDIR)/libroken_la-esetenv.Tpo -c -o libroken_la-esetenv.lo `test -f 'esetenv.c' || echo '$(srcdir)/'`esetenv.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-esetenv.Tpo $(DEPDIR)/libroken_la-esetenv.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='esetenv.c' object='libroken_la-esetenv.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-esetenv.lo `test -f 'esetenv.c' || echo '$(srcdir)/'`esetenv.c
++
++libroken_la-ewrite.lo: ewrite.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-ewrite.lo -MD -MP -MF $(DEPDIR)/libroken_la-ewrite.Tpo -c -o libroken_la-ewrite.lo `test -f 'ewrite.c' || echo '$(srcdir)/'`ewrite.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-ewrite.Tpo $(DEPDIR)/libroken_la-ewrite.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='ewrite.c' object='libroken_la-ewrite.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-ewrite.lo `test -f 'ewrite.c' || echo '$(srcdir)/'`ewrite.c
++
++libroken_la-getaddrinfo_hostspec.lo: getaddrinfo_hostspec.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-getaddrinfo_hostspec.lo -MD -MP -MF $(DEPDIR)/libroken_la-getaddrinfo_hostspec.Tpo -c -o libroken_la-getaddrinfo_hostspec.lo `test -f 'getaddrinfo_hostspec.c' || echo '$(srcdir)/'`getaddrinfo_hostspec.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-getaddrinfo_hostspec.Tpo $(DEPDIR)/libroken_la-getaddrinfo_hostspec.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='getaddrinfo_hostspec.c' object='libroken_la-getaddrinfo_hostspec.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-getaddrinfo_hostspec.lo `test -f 'getaddrinfo_hostspec.c' || echo '$(srcdir)/'`getaddrinfo_hostspec.c
++
++libroken_la-get_default_username.lo: get_default_username.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-get_default_username.lo -MD -MP -MF $(DEPDIR)/libroken_la-get_default_username.Tpo -c -o libroken_la-get_default_username.lo `test -f 'get_default_username.c' || echo '$(srcdir)/'`get_default_username.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-get_default_username.Tpo $(DEPDIR)/libroken_la-get_default_username.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='get_default_username.c' object='libroken_la-get_default_username.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-get_default_username.lo `test -f 'get_default_username.c' || echo '$(srcdir)/'`get_default_username.c
++
++libroken_la-get_window_size.lo: get_window_size.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-get_window_size.lo -MD -MP -MF $(DEPDIR)/libroken_la-get_window_size.Tpo -c -o libroken_la-get_window_size.lo `test -f 'get_window_size.c' || echo '$(srcdir)/'`get_window_size.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-get_window_size.Tpo $(DEPDIR)/libroken_la-get_window_size.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='get_window_size.c' object='libroken_la-get_window_size.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-get_window_size.lo `test -f 'get_window_size.c' || echo '$(srcdir)/'`get_window_size.c
++
++libroken_la-getarg.lo: getarg.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-getarg.lo -MD -MP -MF $(DEPDIR)/libroken_la-getarg.Tpo -c -o libroken_la-getarg.lo `test -f 'getarg.c' || echo '$(srcdir)/'`getarg.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-getarg.Tpo $(DEPDIR)/libroken_la-getarg.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='getarg.c' object='libroken_la-getarg.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-getarg.lo `test -f 'getarg.c' || echo '$(srcdir)/'`getarg.c
++
++libroken_la-getnameinfo_verified.lo: getnameinfo_verified.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-getnameinfo_verified.lo -MD -MP -MF $(DEPDIR)/libroken_la-getnameinfo_verified.Tpo -c -o libroken_la-getnameinfo_verified.lo `test -f 'getnameinfo_verified.c' || echo '$(srcdir)/'`getnameinfo_verified.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-getnameinfo_verified.Tpo $(DEPDIR)/libroken_la-getnameinfo_verified.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='getnameinfo_verified.c' object='libroken_la-getnameinfo_verified.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-getnameinfo_verified.lo `test -f 'getnameinfo_verified.c' || echo '$(srcdir)/'`getnameinfo_verified.c
++
++libroken_la-getprogname.lo: getprogname.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-getprogname.lo -MD -MP -MF $(DEPDIR)/libroken_la-getprogname.Tpo -c -o libroken_la-getprogname.lo `test -f 'getprogname.c' || echo '$(srcdir)/'`getprogname.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-getprogname.Tpo $(DEPDIR)/libroken_la-getprogname.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='getprogname.c' object='libroken_la-getprogname.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-getprogname.lo `test -f 'getprogname.c' || echo '$(srcdir)/'`getprogname.c
++
++libroken_la-h_errno.lo: h_errno.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-h_errno.lo -MD -MP -MF $(DEPDIR)/libroken_la-h_errno.Tpo -c -o libroken_la-h_errno.lo `test -f 'h_errno.c' || echo '$(srcdir)/'`h_errno.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-h_errno.Tpo $(DEPDIR)/libroken_la-h_errno.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='h_errno.c' object='libroken_la-h_errno.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-h_errno.lo `test -f 'h_errno.c' || echo '$(srcdir)/'`h_errno.c
++
++libroken_la-hex.lo: hex.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-hex.lo -MD -MP -MF $(DEPDIR)/libroken_la-hex.Tpo -c -o libroken_la-hex.lo `test -f 'hex.c' || echo '$(srcdir)/'`hex.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-hex.Tpo $(DEPDIR)/libroken_la-hex.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='hex.c' object='libroken_la-hex.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-hex.lo `test -f 'hex.c' || echo '$(srcdir)/'`hex.c
++
++libroken_la-hostent_find_fqdn.lo: hostent_find_fqdn.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-hostent_find_fqdn.lo -MD -MP -MF $(DEPDIR)/libroken_la-hostent_find_fqdn.Tpo -c -o libroken_la-hostent_find_fqdn.lo `test -f 'hostent_find_fqdn.c' || echo '$(srcdir)/'`hostent_find_fqdn.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-hostent_find_fqdn.Tpo $(DEPDIR)/libroken_la-hostent_find_fqdn.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='hostent_find_fqdn.c' object='libroken_la-hostent_find_fqdn.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-hostent_find_fqdn.lo `test -f 'hostent_find_fqdn.c' || echo '$(srcdir)/'`hostent_find_fqdn.c
++
++libroken_la-issuid.lo: issuid.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-issuid.lo -MD -MP -MF $(DEPDIR)/libroken_la-issuid.Tpo -c -o libroken_la-issuid.lo `test -f 'issuid.c' || echo '$(srcdir)/'`issuid.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-issuid.Tpo $(DEPDIR)/libroken_la-issuid.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='issuid.c' object='libroken_la-issuid.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-issuid.lo `test -f 'issuid.c' || echo '$(srcdir)/'`issuid.c
++
++libroken_la-k_getpwnam.lo: k_getpwnam.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-k_getpwnam.lo -MD -MP -MF $(DEPDIR)/libroken_la-k_getpwnam.Tpo -c -o libroken_la-k_getpwnam.lo `test -f 'k_getpwnam.c' || echo '$(srcdir)/'`k_getpwnam.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-k_getpwnam.Tpo $(DEPDIR)/libroken_la-k_getpwnam.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='k_getpwnam.c' object='libroken_la-k_getpwnam.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-k_getpwnam.lo `test -f 'k_getpwnam.c' || echo '$(srcdir)/'`k_getpwnam.c
++
++libroken_la-k_getpwuid.lo: k_getpwuid.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-k_getpwuid.lo -MD -MP -MF $(DEPDIR)/libroken_la-k_getpwuid.Tpo -c -o libroken_la-k_getpwuid.lo `test -f 'k_getpwuid.c' || echo '$(srcdir)/'`k_getpwuid.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-k_getpwuid.Tpo $(DEPDIR)/libroken_la-k_getpwuid.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='k_getpwuid.c' object='libroken_la-k_getpwuid.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-k_getpwuid.lo `test -f 'k_getpwuid.c' || echo '$(srcdir)/'`k_getpwuid.c
++
++libroken_la-mini_inetd.lo: mini_inetd.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-mini_inetd.lo -MD -MP -MF $(DEPDIR)/libroken_la-mini_inetd.Tpo -c -o libroken_la-mini_inetd.lo `test -f 'mini_inetd.c' || echo '$(srcdir)/'`mini_inetd.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-mini_inetd.Tpo $(DEPDIR)/libroken_la-mini_inetd.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='mini_inetd.c' object='libroken_la-mini_inetd.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-mini_inetd.lo `test -f 'mini_inetd.c' || echo '$(srcdir)/'`mini_inetd.c
++
++libroken_la-net_read.lo: net_read.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-net_read.lo -MD -MP -MF $(DEPDIR)/libroken_la-net_read.Tpo -c -o libroken_la-net_read.lo `test -f 'net_read.c' || echo '$(srcdir)/'`net_read.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-net_read.Tpo $(DEPDIR)/libroken_la-net_read.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='net_read.c' object='libroken_la-net_read.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-net_read.lo `test -f 'net_read.c' || echo '$(srcdir)/'`net_read.c
++
++libroken_la-net_write.lo: net_write.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-net_write.lo -MD -MP -MF $(DEPDIR)/libroken_la-net_write.Tpo -c -o libroken_la-net_write.lo `test -f 'net_write.c' || echo '$(srcdir)/'`net_write.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-net_write.Tpo $(DEPDIR)/libroken_la-net_write.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='net_write.c' object='libroken_la-net_write.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-net_write.lo `test -f 'net_write.c' || echo '$(srcdir)/'`net_write.c
++
++libroken_la-parse_bytes.lo: parse_bytes.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-parse_bytes.lo -MD -MP -MF $(DEPDIR)/libroken_la-parse_bytes.Tpo -c -o libroken_la-parse_bytes.lo `test -f 'parse_bytes.c' || echo '$(srcdir)/'`parse_bytes.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-parse_bytes.Tpo $(DEPDIR)/libroken_la-parse_bytes.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='parse_bytes.c' object='libroken_la-parse_bytes.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-parse_bytes.lo `test -f 'parse_bytes.c' || echo '$(srcdir)/'`parse_bytes.c
++
++libroken_la-parse_time.lo: parse_time.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-parse_time.lo -MD -MP -MF $(DEPDIR)/libroken_la-parse_time.Tpo -c -o libroken_la-parse_time.lo `test -f 'parse_time.c' || echo '$(srcdir)/'`parse_time.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-parse_time.Tpo $(DEPDIR)/libroken_la-parse_time.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='parse_time.c' object='libroken_la-parse_time.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-parse_time.lo `test -f 'parse_time.c' || echo '$(srcdir)/'`parse_time.c
++
++libroken_la-parse_units.lo: parse_units.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-parse_units.lo -MD -MP -MF $(DEPDIR)/libroken_la-parse_units.Tpo -c -o libroken_la-parse_units.lo `test -f 'parse_units.c' || echo '$(srcdir)/'`parse_units.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-parse_units.Tpo $(DEPDIR)/libroken_la-parse_units.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='parse_units.c' object='libroken_la-parse_units.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-parse_units.lo `test -f 'parse_units.c' || echo '$(srcdir)/'`parse_units.c
++
++libroken_la-qsort.lo: qsort.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-qsort.lo -MD -MP -MF $(DEPDIR)/libroken_la-qsort.Tpo -c -o libroken_la-qsort.lo `test -f 'qsort.c' || echo '$(srcdir)/'`qsort.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-qsort.Tpo $(DEPDIR)/libroken_la-qsort.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='qsort.c' object='libroken_la-qsort.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-qsort.lo `test -f 'qsort.c' || echo '$(srcdir)/'`qsort.c
++
++libroken_la-rand.lo: rand.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-rand.lo -MD -MP -MF $(DEPDIR)/libroken_la-rand.Tpo -c -o libroken_la-rand.lo `test -f 'rand.c' || echo '$(srcdir)/'`rand.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-rand.Tpo $(DEPDIR)/libroken_la-rand.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rand.c' object='libroken_la-rand.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-rand.lo `test -f 'rand.c' || echo '$(srcdir)/'`rand.c
++
++libroken_la-realloc.lo: realloc.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-realloc.lo -MD -MP -MF $(DEPDIR)/libroken_la-realloc.Tpo -c -o libroken_la-realloc.lo `test -f 'realloc.c' || echo '$(srcdir)/'`realloc.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-realloc.Tpo $(DEPDIR)/libroken_la-realloc.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='realloc.c' object='libroken_la-realloc.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-realloc.lo `test -f 'realloc.c' || echo '$(srcdir)/'`realloc.c
++
++libroken_la-resolve.lo: resolve.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-resolve.lo -MD -MP -MF $(DEPDIR)/libroken_la-resolve.Tpo -c -o libroken_la-resolve.lo `test -f 'resolve.c' || echo '$(srcdir)/'`resolve.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-resolve.Tpo $(DEPDIR)/libroken_la-resolve.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='resolve.c' object='libroken_la-resolve.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-resolve.lo `test -f 'resolve.c' || echo '$(srcdir)/'`resolve.c
++
++libroken_la-roken_gethostby.lo: roken_gethostby.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-roken_gethostby.lo -MD -MP -MF $(DEPDIR)/libroken_la-roken_gethostby.Tpo -c -o libroken_la-roken_gethostby.lo `test -f 'roken_gethostby.c' || echo '$(srcdir)/'`roken_gethostby.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-roken_gethostby.Tpo $(DEPDIR)/libroken_la-roken_gethostby.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='roken_gethostby.c' object='libroken_la-roken_gethostby.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-roken_gethostby.lo `test -f 'roken_gethostby.c' || echo '$(srcdir)/'`roken_gethostby.c
++
++libroken_la-rtbl.lo: rtbl.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-rtbl.lo -MD -MP -MF $(DEPDIR)/libroken_la-rtbl.Tpo -c -o libroken_la-rtbl.lo `test -f 'rtbl.c' || echo '$(srcdir)/'`rtbl.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-rtbl.Tpo $(DEPDIR)/libroken_la-rtbl.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='rtbl.c' object='libroken_la-rtbl.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-rtbl.lo `test -f 'rtbl.c' || echo '$(srcdir)/'`rtbl.c
++
++libroken_la-setprogname.lo: setprogname.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-setprogname.lo -MD -MP -MF $(DEPDIR)/libroken_la-setprogname.Tpo -c -o libroken_la-setprogname.lo `test -f 'setprogname.c' || echo '$(srcdir)/'`setprogname.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-setprogname.Tpo $(DEPDIR)/libroken_la-setprogname.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='setprogname.c' object='libroken_la-setprogname.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-setprogname.lo `test -f 'setprogname.c' || echo '$(srcdir)/'`setprogname.c
++
++libroken_la-signal.lo: signal.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-signal.lo -MD -MP -MF $(DEPDIR)/libroken_la-signal.Tpo -c -o libroken_la-signal.lo `test -f 'signal.c' || echo '$(srcdir)/'`signal.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-signal.Tpo $(DEPDIR)/libroken_la-signal.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='signal.c' object='libroken_la-signal.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-signal.lo `test -f 'signal.c' || echo '$(srcdir)/'`signal.c
++
++libroken_la-simple_exec.lo: simple_exec.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-simple_exec.lo -MD -MP -MF $(DEPDIR)/libroken_la-simple_exec.Tpo -c -o libroken_la-simple_exec.lo `test -f 'simple_exec.c' || echo '$(srcdir)/'`simple_exec.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-simple_exec.Tpo $(DEPDIR)/libroken_la-simple_exec.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='simple_exec.c' object='libroken_la-simple_exec.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-simple_exec.lo `test -f 'simple_exec.c' || echo '$(srcdir)/'`simple_exec.c
++
++libroken_la-snprintf.lo: snprintf.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-snprintf.lo -MD -MP -MF $(DEPDIR)/libroken_la-snprintf.Tpo -c -o libroken_la-snprintf.lo `test -f 'snprintf.c' || echo '$(srcdir)/'`snprintf.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-snprintf.Tpo $(DEPDIR)/libroken_la-snprintf.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='snprintf.c' object='libroken_la-snprintf.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-snprintf.lo `test -f 'snprintf.c' || echo '$(srcdir)/'`snprintf.c
++
++libroken_la-socket.lo: socket.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-socket.lo -MD -MP -MF $(DEPDIR)/libroken_la-socket.Tpo -c -o libroken_la-socket.lo `test -f 'socket.c' || echo '$(srcdir)/'`socket.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-socket.Tpo $(DEPDIR)/libroken_la-socket.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='socket.c' object='libroken_la-socket.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-socket.lo `test -f 'socket.c' || echo '$(srcdir)/'`socket.c
++
++libroken_la-strcollect.lo: strcollect.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-strcollect.lo -MD -MP -MF $(DEPDIR)/libroken_la-strcollect.Tpo -c -o libroken_la-strcollect.lo `test -f 'strcollect.c' || echo '$(srcdir)/'`strcollect.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-strcollect.Tpo $(DEPDIR)/libroken_la-strcollect.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='strcollect.c' object='libroken_la-strcollect.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-strcollect.lo `test -f 'strcollect.c' || echo '$(srcdir)/'`strcollect.c
++
++libroken_la-strerror_r.lo: strerror_r.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-strerror_r.lo -MD -MP -MF $(DEPDIR)/libroken_la-strerror_r.Tpo -c -o libroken_la-strerror_r.lo `test -f 'strerror_r.c' || echo '$(srcdir)/'`strerror_r.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-strerror_r.Tpo $(DEPDIR)/libroken_la-strerror_r.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='strerror_r.c' object='libroken_la-strerror_r.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-strerror_r.lo `test -f 'strerror_r.c' || echo '$(srcdir)/'`strerror_r.c
++
++libroken_la-strpool.lo: strpool.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-strpool.lo -MD -MP -MF $(DEPDIR)/libroken_la-strpool.Tpo -c -o libroken_la-strpool.lo `test -f 'strpool.c' || echo '$(srcdir)/'`strpool.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-strpool.Tpo $(DEPDIR)/libroken_la-strpool.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='strpool.c' object='libroken_la-strpool.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-strpool.lo `test -f 'strpool.c' || echo '$(srcdir)/'`strpool.c
++
++libroken_la-timeval.lo: timeval.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-timeval.lo -MD -MP -MF $(DEPDIR)/libroken_la-timeval.Tpo -c -o libroken_la-timeval.lo `test -f 'timeval.c' || echo '$(srcdir)/'`timeval.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-timeval.Tpo $(DEPDIR)/libroken_la-timeval.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='timeval.c' object='libroken_la-timeval.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-timeval.lo `test -f 'timeval.c' || echo '$(srcdir)/'`timeval.c
++
++libroken_la-tm2time.lo: tm2time.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-tm2time.lo -MD -MP -MF $(DEPDIR)/libroken_la-tm2time.Tpo -c -o libroken_la-tm2time.lo `test -f 'tm2time.c' || echo '$(srcdir)/'`tm2time.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-tm2time.Tpo $(DEPDIR)/libroken_la-tm2time.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='tm2time.c' object='libroken_la-tm2time.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-tm2time.lo `test -f 'tm2time.c' || echo '$(srcdir)/'`tm2time.c
++
++libroken_la-unvis.lo: unvis.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-unvis.lo -MD -MP -MF $(DEPDIR)/libroken_la-unvis.Tpo -c -o libroken_la-unvis.lo `test -f 'unvis.c' || echo '$(srcdir)/'`unvis.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-unvis.Tpo $(DEPDIR)/libroken_la-unvis.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='unvis.c' object='libroken_la-unvis.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-unvis.lo `test -f 'unvis.c' || echo '$(srcdir)/'`unvis.c
++
++libroken_la-verify.lo: verify.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-verify.lo -MD -MP -MF $(DEPDIR)/libroken_la-verify.Tpo -c -o libroken_la-verify.lo `test -f 'verify.c' || echo '$(srcdir)/'`verify.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-verify.Tpo $(DEPDIR)/libroken_la-verify.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='verify.c' object='libroken_la-verify.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-verify.lo `test -f 'verify.c' || echo '$(srcdir)/'`verify.c
++
++libroken_la-vis.lo: vis.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-vis.lo -MD -MP -MF $(DEPDIR)/libroken_la-vis.Tpo -c -o libroken_la-vis.lo `test -f 'vis.c' || echo '$(srcdir)/'`vis.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-vis.Tpo $(DEPDIR)/libroken_la-vis.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='vis.c' object='libroken_la-vis.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-vis.lo `test -f 'vis.c' || echo '$(srcdir)/'`vis.c
++
++libroken_la-warnerr.lo: warnerr.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-warnerr.lo -MD -MP -MF $(DEPDIR)/libroken_la-warnerr.Tpo -c -o libroken_la-warnerr.lo `test -f 'warnerr.c' || echo '$(srcdir)/'`warnerr.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-warnerr.Tpo $(DEPDIR)/libroken_la-warnerr.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='warnerr.c' object='libroken_la-warnerr.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-warnerr.lo `test -f 'warnerr.c' || echo '$(srcdir)/'`warnerr.c
++
++libroken_la-write_pid.lo: write_pid.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-write_pid.lo -MD -MP -MF $(DEPDIR)/libroken_la-write_pid.Tpo -c -o libroken_la-write_pid.lo `test -f 'write_pid.c' || echo '$(srcdir)/'`write_pid.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-write_pid.Tpo $(DEPDIR)/libroken_la-write_pid.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='write_pid.c' object='libroken_la-write_pid.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-write_pid.lo `test -f 'write_pid.c' || echo '$(srcdir)/'`write_pid.c
++
++libroken_la-xfree.lo: xfree.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-xfree.lo -MD -MP -MF $(DEPDIR)/libroken_la-xfree.Tpo -c -o libroken_la-xfree.lo `test -f 'xfree.c' || echo '$(srcdir)/'`xfree.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-xfree.Tpo $(DEPDIR)/libroken_la-xfree.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='xfree.c' object='libroken_la-xfree.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-xfree.lo `test -f 'xfree.c' || echo '$(srcdir)/'`xfree.c
++
++libroken_la-socket_wrapper.lo: socket_wrapper.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libroken_la-socket_wrapper.lo -MD -MP -MF $(DEPDIR)/libroken_la-socket_wrapper.Tpo -c -o libroken_la-socket_wrapper.lo `test -f 'socket_wrapper.c' || echo '$(srcdir)/'`socket_wrapper.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libroken_la-socket_wrapper.Tpo $(DEPDIR)/libroken_la-socket_wrapper.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='socket_wrapper.c' object='libroken_la-socket_wrapper.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libroken_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libroken_la-socket_wrapper.lo `test -f 'socket_wrapper.c' || echo '$(srcdir)/'`socket_wrapper.c
++
++libtest_la-strftime.lo: strftime.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libtest_la_CFLAGS) $(CFLAGS) -MT libtest_la-strftime.lo -MD -MP -MF $(DEPDIR)/libtest_la-strftime.Tpo -c -o libtest_la-strftime.lo `test -f 'strftime.c' || echo '$(srcdir)/'`strftime.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libtest_la-strftime.Tpo $(DEPDIR)/libtest_la-strftime.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='strftime.c' object='libtest_la-strftime.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libtest_la_CFLAGS) $(CFLAGS) -c -o libtest_la-strftime.lo `test -f 'strftime.c' || echo '$(srcdir)/'`strftime.c
++
++libtest_la-strptime.lo: strptime.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libtest_la_CFLAGS) $(CFLAGS) -MT libtest_la-strptime.lo -MD -MP -MF $(DEPDIR)/libtest_la-strptime.Tpo -c -o libtest_la-strptime.lo `test -f 'strptime.c' || echo '$(srcdir)/'`strptime.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libtest_la-strptime.Tpo $(DEPDIR)/libtest_la-strptime.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='strptime.c' object='libtest_la-strptime.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libtest_la_CFLAGS) $(CFLAGS) -c -o libtest_la-strptime.lo `test -f 'strptime.c' || echo '$(srcdir)/'`strptime.c
++
++libtest_la-snprintf.lo: snprintf.c
++@am__fastdepCC_TRUE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libtest_la_CFLAGS) $(CFLAGS) -MT libtest_la-snprintf.lo -MD -MP -MF $(DEPDIR)/libtest_la-snprintf.Tpo -c -o libtest_la-snprintf.lo `test -f 'snprintf.c' || echo '$(srcdir)/'`snprintf.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/libtest_la-snprintf.Tpo $(DEPDIR)/libtest_la-snprintf.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='snprintf.c' object='libtest_la-snprintf.lo' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LIBTOOL)  --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(libtest_la_CFLAGS) $(CFLAGS) -c -o libtest_la-snprintf.lo `test -f 'snprintf.c' || echo '$(srcdir)/'`snprintf.c
++
++parse_reply_test-parse_reply-test.o: parse_reply-test.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(parse_reply_test_CFLAGS) $(CFLAGS) -MT parse_reply_test-parse_reply-test.o -MD -MP -MF $(DEPDIR)/parse_reply_test-parse_reply-test.Tpo -c -o parse_reply_test-parse_reply-test.o `test -f 'parse_reply-test.c' || echo '$(srcdir)/'`parse_reply-test.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/parse_reply_test-parse_reply-test.Tpo $(DEPDIR)/parse_reply_test-parse_reply-test.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='parse_reply-test.c' object='parse_reply_test-parse_reply-test.o' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(parse_reply_test_CFLAGS) $(CFLAGS) -c -o parse_reply_test-parse_reply-test.o `test -f 'parse_reply-test.c' || echo '$(srcdir)/'`parse_reply-test.c
++
++parse_reply_test-parse_reply-test.obj: parse_reply-test.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(parse_reply_test_CFLAGS) $(CFLAGS) -MT parse_reply_test-parse_reply-test.obj -MD -MP -MF $(DEPDIR)/parse_reply_test-parse_reply-test.Tpo -c -o parse_reply_test-parse_reply-test.obj `if test -f 'parse_reply-test.c'; then $(CYGPATH_W) 'parse_reply-test.c'; else $(CYGPATH_W) '$(srcdir)/parse_reply-test.c'; fi`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/parse_reply_test-parse_reply-test.Tpo $(DEPDIR)/parse_reply_test-parse_reply-test.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='parse_reply-test.c' object='parse_reply_test-parse_reply-test.obj' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(parse_reply_test_CFLAGS) $(CFLAGS) -c -o parse_reply_test-parse_reply-test.obj `if test -f 'parse_reply-test.c'; then $(CYGPATH_W) 'parse_reply-test.c'; else $(CYGPATH_W) '$(srcdir)/parse_reply-test.c'; fi`
++
++parse_reply_test-resolve.o: resolve.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(parse_reply_test_CFLAGS) $(CFLAGS) -MT parse_reply_test-resolve.o -MD -MP -MF $(DEPDIR)/parse_reply_test-resolve.Tpo -c -o parse_reply_test-resolve.o `test -f 'resolve.c' || echo '$(srcdir)/'`resolve.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/parse_reply_test-resolve.Tpo $(DEPDIR)/parse_reply_test-resolve.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='resolve.c' object='parse_reply_test-resolve.o' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(parse_reply_test_CFLAGS) $(CFLAGS) -c -o parse_reply_test-resolve.o `test -f 'resolve.c' || echo '$(srcdir)/'`resolve.c
++
++parse_reply_test-resolve.obj: resolve.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(parse_reply_test_CFLAGS) $(CFLAGS) -MT parse_reply_test-resolve.obj -MD -MP -MF $(DEPDIR)/parse_reply_test-resolve.Tpo -c -o parse_reply_test-resolve.obj `if test -f 'resolve.c'; then $(CYGPATH_W) 'resolve.c'; else $(CYGPATH_W) '$(srcdir)/resolve.c'; fi`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/parse_reply_test-resolve.Tpo $(DEPDIR)/parse_reply_test-resolve.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='resolve.c' object='parse_reply_test-resolve.obj' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(parse_reply_test_CFLAGS) $(CFLAGS) -c -o parse_reply_test-resolve.obj `if test -f 'resolve.c'; then $(CYGPATH_W) 'resolve.c'; else $(CYGPATH_W) '$(srcdir)/resolve.c'; fi`
++
++snprintf_test-snprintf-test.o: snprintf-test.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(snprintf_test_CFLAGS) $(CFLAGS) -MT snprintf_test-snprintf-test.o -MD -MP -MF $(DEPDIR)/snprintf_test-snprintf-test.Tpo -c -o snprintf_test-snprintf-test.o `test -f 'snprintf-test.c' || echo '$(srcdir)/'`snprintf-test.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/snprintf_test-snprintf-test.Tpo $(DEPDIR)/snprintf_test-snprintf-test.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='snprintf-test.c' object='snprintf_test-snprintf-test.o' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(snprintf_test_CFLAGS) $(CFLAGS) -c -o snprintf_test-snprintf-test.o `test -f 'snprintf-test.c' || echo '$(srcdir)/'`snprintf-test.c
++
++snprintf_test-snprintf-test.obj: snprintf-test.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(snprintf_test_CFLAGS) $(CFLAGS) -MT snprintf_test-snprintf-test.obj -MD -MP -MF $(DEPDIR)/snprintf_test-snprintf-test.Tpo -c -o snprintf_test-snprintf-test.obj `if test -f 'snprintf-test.c'; then $(CYGPATH_W) 'snprintf-test.c'; else $(CYGPATH_W) '$(srcdir)/snprintf-test.c'; fi`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/snprintf_test-snprintf-test.Tpo $(DEPDIR)/snprintf_test-snprintf-test.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='snprintf-test.c' object='snprintf_test-snprintf-test.obj' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(snprintf_test_CFLAGS) $(CFLAGS) -c -o snprintf_test-snprintf-test.obj `if test -f 'snprintf-test.c'; then $(CYGPATH_W) 'snprintf-test.c'; else $(CYGPATH_W) '$(srcdir)/snprintf-test.c'; fi`
++
++strpftime_test-strpftime-test.o: strpftime-test.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(strpftime_test_CFLAGS) $(CFLAGS) -MT strpftime_test-strpftime-test.o -MD -MP -MF $(DEPDIR)/strpftime_test-strpftime-test.Tpo -c -o strpftime_test-strpftime-test.o `test -f 'strpftime-test.c' || echo '$(srcdir)/'`strpftime-test.c
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/strpftime_test-strpftime-test.Tpo $(DEPDIR)/strpftime_test-strpftime-test.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='strpftime-test.c' object='strpftime_test-strpftime-test.o' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(strpftime_test_CFLAGS) $(CFLAGS) -c -o strpftime_test-strpftime-test.o `test -f 'strpftime-test.c' || echo '$(srcdir)/'`strpftime-test.c
++
++strpftime_test-strpftime-test.obj: strpftime-test.c
++@am__fastdepCC_TRUE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(strpftime_test_CFLAGS) $(CFLAGS) -MT strpftime_test-strpftime-test.obj -MD -MP -MF $(DEPDIR)/strpftime_test-strpftime-test.Tpo -c -o strpftime_test-strpftime-test.obj `if test -f 'strpftime-test.c'; then $(CYGPATH_W) 'strpftime-test.c'; else $(CYGPATH_W) '$(srcdir)/strpftime-test.c'; fi`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/strpftime_test-strpftime-test.Tpo $(DEPDIR)/strpftime_test-strpftime-test.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='strpftime-test.c' object='strpftime_test-strpftime-test.obj' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(strpftime_test_CFLAGS) $(CFLAGS) -c -o strpftime_test-strpftime-test.obj `if test -f 'strpftime-test.c'; then $(CYGPATH_W) 'strpftime-test.c'; else $(CYGPATH_W) '$(srcdir)/strpftime-test.c'; fi`
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man3: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man3dir)" || $(MKDIR_P) "$(DESTDIR)$(man3dir)"
++	@list=''; test -n "$(man3dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.3[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^3][0-9a-z]*$$,3,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man3dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man3dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man3dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man3dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man3:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man3dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.3[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^3][0-9a-z]*$$,3,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man3dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man3dir)" && rm -f $$files; }
++install-dist_includeHEADERS: $(dist_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(dist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-dist_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(dist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++install-nodist_includeHEADERS: $(nodist_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-nodist_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++install-nodist_rokenincludeHEADERS: $(nodist_rokeninclude_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(rokenincludedir)" || $(MKDIR_P) "$(DESTDIR)$(rokenincludedir)"
++	@list='$(nodist_rokeninclude_HEADERS)'; test -n "$(rokenincludedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(rokenincludedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(rokenincludedir)" || exit $$?; \
++	done
++
++uninstall-nodist_rokenincludeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(nodist_rokeninclude_HEADERS)'; test -n "$(rokenincludedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(rokenincludedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(rokenincludedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(MANS) $(HEADERS) \
++		all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(man3dir)" "$(DESTDIR)$(includedir)" "$(DESTDIR)$(includedir)" "$(DESTDIR)$(rokenincludedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++	-test -z "$(BUILT_SOURCES)" || rm -f $(BUILT_SOURCES)
++clean: clean-am
++
++clean-am: clean-checkPROGRAMS clean-generic clean-libLTLIBRARIES \
++	clean-libtool clean-noinstLTLIBRARIES clean-noinstPROGRAMS \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf $(DEPDIR) ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-dist_includeHEADERS install-man \
++	install-nodist_includeHEADERS \
++	install-nodist_rokenincludeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man3
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf $(DEPDIR) ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-dist_includeHEADERS uninstall-libLTLIBRARIES \
++	uninstall-man uninstall-nodist_includeHEADERS \
++	uninstall-nodist_rokenincludeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man3
++
++.MAKE: all check check-am install install-am install-data-am \
++	install-exec-am install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-TESTS check-am \
++	check-local clean clean-checkPROGRAMS clean-generic \
++	clean-libLTLIBRARIES clean-libtool clean-noinstLTLIBRARIES \
++	clean-noinstPROGRAMS ctags dist-hook distclean \
++	distclean-compile distclean-generic distclean-libtool \
++	distclean-tags distdir dvi dvi-am html html-am info info-am \
++	install install-am install-data install-data-am \
++	install-data-hook install-dist_includeHEADERS install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-libLTLIBRARIES install-man install-man3 \
++	install-nodist_includeHEADERS \
++	install-nodist_rokenincludeHEADERS install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-dist_includeHEADERS \
++	uninstall-hook uninstall-libLTLIBRARIES uninstall-man \
++	uninstall-man3 uninstall-nodist_includeHEADERS \
++	uninstall-nodist_rokenincludeHEADERS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(LTLIBOBJS) $(libroken_la_OBJECTS): roken.h $(XHEADERS)
++.hin.h:
++	cp $< $@
++
++@CROSS_COMPILE_FALSE@roken.h: make-roken$(EXEEXT)
++@CROSS_COMPILE_FALSE@	@./make-roken$(EXEEXT) > tmp.h ;\
++@CROSS_COMPILE_FALSE@	if [ -f roken.h ] && cmp -s tmp.h roken.h ; then rm -f tmp.h ; \
++@CROSS_COMPILE_FALSE@	else rm -f roken.h; mv tmp.h roken.h; fi
++
++@CROSS_COMPILE_FALSE@make-roken.c: roken.h.in roken.awk
++@CROSS_COMPILE_FALSE@	$(AWK) -f $(srcdir)/roken.awk $(srcdir)/roken.h.in > make-roken.c
++
++@CROSS_COMPILE_TRUE@roken.h: $(top_srcdir)/cf/roken-h-process.pl roken.h.in
++@CROSS_COMPILE_TRUE@	perl $(top_srcdir)/cf/roken-h-process.pl \
++@CROSS_COMPILE_TRUE@	-c $(top_builddir)/include/config.h  \
++@CROSS_COMPILE_TRUE@	-p $(srcdir)/roken.h.in -o roken.h
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/sl/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/sl/Makefile.in	2010-12-29 04:07:15.127914051 +0100
+@@ -0,0 +1,1128 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(include_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog slc-gram.c \
++	slc-gram.h slc-lex.c
++TESTS = test_sl$(EXEEXT)
++check_PROGRAMS = $(am__EXEEXT_1)
++libexec_heimdal_PROGRAMS = slc$(EXEEXT)
++subdir = lib/sl
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" \
++	"$(DESTDIR)$(libexec_heimdaldir)" "$(DESTDIR)$(includedir)"
++LTLIBRARIES = $(lib_LTLIBRARIES)
++libsl_la_DEPENDENCIES =
++dist_libsl_la_OBJECTS = sl.lo
++@do_roken_rename_TRUE@am__objects_1 = strtok_r.lo snprintf.lo \
++@do_roken_rename_TRUE@	strdup.lo strupr.lo getprogname.lo
++nodist_libsl_la_OBJECTS = $(am__objects_1)
++libsl_la_OBJECTS = $(dist_libsl_la_OBJECTS) $(nodist_libsl_la_OBJECTS)
++libsl_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(libsl_la_LDFLAGS) \
++	$(LDFLAGS) -o $@
++am__EXEEXT_1 = test_sl$(EXEEXT)
++PROGRAMS = $(libexec_heimdal_PROGRAMS)
++am_slc_OBJECTS = slc-gram.$(OBJEXT) slc-lex.$(OBJEXT)
++slc_OBJECTS = $(am_slc_OBJECTS)
++am__DEPENDENCIES_1 =
++am__DEPENDENCIES_2 = libsl.la $(am__DEPENDENCIES_1)
++slc_DEPENDENCIES = $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_2)
++test_sl_SOURCES = test_sl.c
++test_sl_OBJECTS = test_sl.$(OBJEXT)
++test_sl_LDADD = $(LDADD)
++test_sl_DEPENDENCIES = libsl.la $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++@MAINTAINER_MODE_FALSE@am__skiplex = test -f $@ ||
++LEXCOMPILE = $(LEX) $(LFLAGS) $(AM_LFLAGS)
++LTLEXCOMPILE = $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(LEX) $(LFLAGS) $(AM_LFLAGS)
++YLWRAP = $(top_srcdir)/ylwrap
++@MAINTAINER_MODE_FALSE@am__skipyacc = test -f $@ ||
++YACCCOMPILE = $(YACC) $(YFLAGS) $(AM_YFLAGS)
++LTYACCCOMPILE = $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(YACC) $(YFLAGS) $(AM_YFLAGS)
++SOURCES = $(dist_libsl_la_SOURCES) $(nodist_libsl_la_SOURCES) \
++	$(slc_SOURCES) test_sl.c
++DIST_SOURCES = $(dist_libsl_la_SOURCES) $(slc_SOURCES) test_sl.c
++HEADERS = $(include_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = -d
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken) $(ROKEN_RENAME)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++@do_roken_rename_TRUE@ES = strtok_r.c snprintf.c strdup.c strupr.c getprogname.c
++include_HEADERS = sl.h
++lib_LTLIBRARIES = libsl.la
++libsl_la_LDFLAGS = -version-info 2:1:2
++libsl_la_LIBADD = @LIB_readline@
++dist_libsl_la_SOURCES = sl_locl.h sl.c roken_rename.h
++nodist_libsl_la_SOURCES = $(ES)
++slc_SOURCES = slc-gram.y slc-lex.l slc.h
++CLEANFILES = snprintf.c strtok_r.c strdup.c strupr.c getprogname.c
++LDADD = libsl.la $(LIB_roken)
++slc_LDADD = $(LEXLIB) $(LDADD)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .l .lo .o .obj .y
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/sl/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/sl/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libsl.la: $(libsl_la_OBJECTS) $(libsl_la_DEPENDENCIES) 
++	$(libsl_la_LINK) -rpath $(libdir) $(libsl_la_OBJECTS) $(libsl_la_LIBADD) $(LIBS)
++
++clean-checkPROGRAMS:
++	@list='$(check_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++install-libexec_heimdalPROGRAMS: $(libexec_heimdal_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(libexec_heimdaldir)" || $(MKDIR_P) "$(DESTDIR)$(libexec_heimdaldir)"
++	@list='$(libexec_heimdal_PROGRAMS)'; test -n "$(libexec_heimdaldir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(libexec_heimdaldir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(libexec_heimdaldir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-libexec_heimdalPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(libexec_heimdal_PROGRAMS)'; test -n "$(libexec_heimdaldir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(libexec_heimdaldir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(libexec_heimdaldir)" && rm -f $$files
++
++clean-libexec_heimdalPROGRAMS:
++	@list='$(libexec_heimdal_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++slc-gram.h: slc-gram.c
++	@if test ! -f $@; then \
++	  rm -f slc-gram.c; \
++	  $(MAKE) $(AM_MAKEFLAGS) slc-gram.c; \
++	else :; fi
++slc$(EXEEXT): $(slc_OBJECTS) $(slc_DEPENDENCIES) 
++	@rm -f slc$(EXEEXT)
++	$(LINK) $(slc_OBJECTS) $(slc_LDADD) $(LIBS)
++test_sl$(EXEEXT): $(test_sl_OBJECTS) $(test_sl_DEPENDENCIES) 
++	@rm -f test_sl$(EXEEXT)
++	$(LINK) $(test_sl_OBJECTS) $(test_sl_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/getprogname.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/sl.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/slc-gram.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/slc-lex.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/snprintf.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/strdup.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/strtok_r.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/strupr.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test_sl.Po@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++.l.c:
++	$(am__skiplex) $(SHELL) $(YLWRAP) $< $(LEX_OUTPUT_ROOT).c $@ -- $(LEXCOMPILE)
++
++.y.c:
++	$(am__skipyacc) $(SHELL) $(YLWRAP) $< y.tab.c $@ y.tab.h $*.h y.output $*.output -- $(YACCCOMPILE)
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-includeHEADERS: $(include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(HEADERS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(libexec_heimdaldir)" "$(DESTDIR)$(includedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++	-rm -f slc-gram.c
++	-rm -f slc-gram.h
++	-rm -f slc-lex.c
++clean: clean-am
++
++clean-am: clean-checkPROGRAMS clean-generic clean-libLTLIBRARIES \
++	clean-libexec_heimdalPROGRAMS clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libLTLIBRARIES \
++	install-libexec_heimdalPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-includeHEADERS uninstall-libLTLIBRARIES \
++	uninstall-libexec_heimdalPROGRAMS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-TESTS check-am \
++	check-local clean clean-checkPROGRAMS clean-generic \
++	clean-libLTLIBRARIES clean-libexec_heimdalPROGRAMS \
++	clean-libtool ctags dist-hook distclean distclean-compile \
++	distclean-generic distclean-libtool distclean-tags distdir dvi \
++	dvi-am html html-am info info-am install install-am \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-includeHEADERS \
++	install-info install-info-am install-libLTLIBRARIES \
++	install-libexec_heimdalPROGRAMS install-man install-pdf \
++	install-pdf-am install-ps install-ps-am install-strip \
++	installcheck installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-hook \
++	uninstall-includeHEADERS uninstall-libLTLIBRARIES \
++	uninstall-libexec_heimdalPROGRAMS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++strtok_r.c:
++	$(LN_S) $(srcdir)/../roken/strtok_r.c .
++snprintf.c:
++	$(LN_S) $(srcdir)/../roken/snprintf.c .
++strdup.c:
++	$(LN_S) $(srcdir)/../roken/strdup.c .
++strupr.c:
++	$(LN_S) $(srcdir)/../roken/strupr.c .
++getprogname.c:
++	$(LN_S) $(srcdir)/../roken/getprogname.c .
++
++slc-lex.c: slc-gram.h
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/sqlite/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/sqlite/Makefile.in	2010-12-29 04:07:15.337979274 +0100
+@@ -0,0 +1,875 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(noinst_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = lib/sqlite
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)"
++LTLIBRARIES = $(lib_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++libheimsqlite_la_DEPENDENCIES = $(am__DEPENDENCIES_1)
++am_libheimsqlite_la_OBJECTS = sqlite3.lo
++libheimsqlite_la_OBJECTS = $(am_libheimsqlite_la_OBJECTS)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(libheimsqlite_la_SOURCES)
++DIST_SOURCES = $(libheimsqlite_la_SOURCES)
++HEADERS = $(noinst_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++lib_LTLIBRARIES = libheimsqlite.la
++noinst_HEADERS = sqlite3.h sqlite3ext.h
++libheimsqlite_la_SOURCES = sqlite3.c
++libheimsqlite_la_LIBADD = $(PTHREAD_LIBADD)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/sqlite/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/sqlite/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libheimsqlite.la: $(libheimsqlite_la_OBJECTS) $(libheimsqlite_la_DEPENDENCIES) 
++	$(LINK) -rpath $(libdir) $(libheimsqlite_la_OBJECTS) $(libheimsqlite_la_LIBADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/sqlite3.Plo@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) $(HEADERS) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libLTLIBRARIES clean-libtool \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libLTLIBRARIES clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am \
++	install-libLTLIBRARIES install-man install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-hook \
++	uninstall-libLTLIBRARIES
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/vers/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/vers/Makefile.in	2010-12-29 04:07:15.538041390 +0100
+@@ -0,0 +1,824 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++subdir = lib/vers
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++LTLIBRARIES = $(noinst_LTLIBRARIES)
++libvers_la_LIBADD =
++am_libvers_la_OBJECTS = print_version.lo
++libvers_la_OBJECTS = $(am_libvers_la_OBJECTS)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(libvers_la_SOURCES)
++DIST_SOURCES = $(libvers_la_SOURCES)
++ETAGS = etags
++CTAGS = ctags
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++noinst_LTLIBRARIES = libvers.la
++build_HEADERZ = vers.h
++CHECK_LOCAL = no-check-local
++libvers_la_SOURCES = print_version.c
++EXTRA_DIST = $(build_HEADERZ)
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/vers/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/vers/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++clean-noinstLTLIBRARIES:
++	-test -z "$(noinst_LTLIBRARIES)" || rm -f $(noinst_LTLIBRARIES)
++	@list='$(noinst_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libvers.la: $(libvers_la_OBJECTS) $(libvers_la_DEPENDENCIES) 
++	$(LINK)  $(libvers_la_OBJECTS) $(libvers_la_LIBADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/print_version.Plo@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool clean-noinstLTLIBRARIES \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-am check-local \
++	clean clean-generic clean-libtool clean-noinstLTLIBRARIES \
++	ctags dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-compile mostlyclean-generic mostlyclean-libtool \
++	pdf pdf-am ps ps-am tags uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/lib/wind/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/lib/wind/Makefile.in	2010-12-29 04:07:15.818128354 +0100
+@@ -0,0 +1,1298 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id: Makefile.am,v 1.1 2004/12/20 08:31:45 assar Exp $
++
++# $Id$
++
++# $Id$
++
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(dist_include_HEADERS) $(srcdir)/Makefile.am \
++	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++@versionscript_TRUE@am__append_1 = $(LDFLAGS_VERSION_SCRIPT)$(srcdir)/version-script.map
++check_PROGRAMS = test-bidi$(EXEEXT) test-map$(EXEEXT) test-rw$(EXEEXT) \
++	test-normalize$(EXEEXT) test-prohibited$(EXEEXT) \
++	test-punycode$(EXEEXT) test-ldap$(EXEEXT) test-utf8$(EXEEXT)
++bin_PROGRAMS = idn-lookup$(EXEEXT)
++subdir = lib/wind
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)" "$(DESTDIR)$(bindir)" \
++	"$(DESTDIR)$(includedir)" "$(DESTDIR)$(includedir)"
++LTLIBRARIES = $(lib_LTLIBRARIES)
++am__DEPENDENCIES_1 =
++libwind_la_DEPENDENCIES = $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
++am__objects_1 = bidi.lo combining.lo doxygen.lo errorlist.lo map.lo \
++	ldap.lo normalize.lo punycode.lo stringprep.lo utf8.lo
++am__objects_2 = bidi_table.lo combining_table.lo errorlist_table.lo \
++	map_table.lo normalize_table.lo
++dist_libwind_la_OBJECTS = $(am__objects_1) $(am__objects_2)
++nodist_libwind_la_OBJECTS = wind_err.lo
++libwind_la_OBJECTS = $(dist_libwind_la_OBJECTS) \
++	$(nodist_libwind_la_OBJECTS)
++libwind_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
++	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
++	$(libwind_la_LDFLAGS) $(LDFLAGS) -o $@
++PROGRAMS = $(bin_PROGRAMS)
++am_idn_lookup_OBJECTS = idn-lookup.$(OBJEXT)
++idn_lookup_OBJECTS = $(am_idn_lookup_OBJECTS)
++idn_lookup_LDADD = $(LDADD)
++idn_lookup_DEPENDENCIES = libwind.la $(am__DEPENDENCIES_1)
++test_bidi_SOURCES = test-bidi.c
++test_bidi_OBJECTS = test-bidi.$(OBJEXT)
++test_bidi_LDADD = $(LDADD)
++test_bidi_DEPENDENCIES = libwind.la $(am__DEPENDENCIES_1)
++test_ldap_SOURCES = test-ldap.c
++test_ldap_OBJECTS = test-ldap.$(OBJEXT)
++test_ldap_LDADD = $(LDADD)
++test_ldap_DEPENDENCIES = libwind.la $(am__DEPENDENCIES_1)
++test_map_SOURCES = test-map.c
++test_map_OBJECTS = test-map.$(OBJEXT)
++test_map_LDADD = $(LDADD)
++test_map_DEPENDENCIES = libwind.la $(am__DEPENDENCIES_1)
++test_normalize_SOURCES = test-normalize.c
++test_normalize_OBJECTS = test-normalize.$(OBJEXT)
++test_normalize_LDADD = $(LDADD)
++test_normalize_DEPENDENCIES = libwind.la $(am__DEPENDENCIES_1)
++test_prohibited_SOURCES = test-prohibited.c
++test_prohibited_OBJECTS = test-prohibited.$(OBJEXT)
++test_prohibited_LDADD = $(LDADD)
++test_prohibited_DEPENDENCIES = libwind.la $(am__DEPENDENCIES_1)
++am_test_punycode_OBJECTS = test-punycode.$(OBJEXT) \
++	punycode_examples.$(OBJEXT)
++test_punycode_OBJECTS = $(am_test_punycode_OBJECTS)
++test_punycode_LDADD = $(LDADD)
++test_punycode_DEPENDENCIES = libwind.la $(am__DEPENDENCIES_1)
++test_rw_SOURCES = test-rw.c
++test_rw_OBJECTS = test-rw.$(OBJEXT)
++test_rw_LDADD = $(LDADD)
++test_rw_DEPENDENCIES = libwind.la $(am__DEPENDENCIES_1)
++test_utf8_SOURCES = test-utf8.c
++test_utf8_OBJECTS = test-utf8.$(OBJEXT)
++test_utf8_LDADD = $(LDADD)
++test_utf8_DEPENDENCIES = libwind.la $(am__DEPENDENCIES_1)
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(dist_libwind_la_SOURCES) $(nodist_libwind_la_SOURCES) \
++	$(idn_lookup_SOURCES) test-bidi.c test-ldap.c test-map.c \
++	test-normalize.c test-prohibited.c $(test_punycode_SOURCES) \
++	test-rw.c test-utf8.c
++DIST_SOURCES = $(dist_libwind_la_SOURCES) $(idn_lookup_SOURCES) \
++	test-bidi.c test-ldap.c test-map.c test-normalize.c \
++	test-prohibited.c $(test_punycode_SOURCES) test-rw.c \
++	test-utf8.c
++HEADERS = $(dist_include_HEADERS) $(nodist_include_HEADERS)
++ETAGS = etags
++CTAGS = ctags
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++lib_LTLIBRARIES = libwind.la
++built = \
++	bidi_table.c				\
++	bidi_table.h				\
++	combining_table.c			\
++	combining_table.h			\
++	errorlist_table.c			\
++	errorlist_table.h			\
++	map_table.c				\
++	map_table.h				\
++	normalize_table.c			\
++	normalize_table.h
++
++built_tests = \
++	punycode_examples.h			\
++	punycode_examples.c
++
++MAINTAINERCLEANFILES = $(built) $(built_tests)
++code = \
++	bidi.c					\
++	combining.c				\
++	doxygen.c				\
++	errorlist.c				\
++	map.c					\
++	ldap.c					\
++	normalize.c				\
++	punycode.c				\
++	stringprep.c				\
++	wind.h					\
++	windlocl.h				\
++	utf8.c
++
++dist_libwind_la_SOURCES = $(code) $(built)
++nodist_libwind_la_SOURCES = wind_err.c wind_err.h
++dist_include_HEADERS = wind.h
++nodist_include_HEADERS = wind_err.h
++libwind_la_LDFLAGS = -version-info 0:0:0 $(am__append_1)
++libwind_la_LIBADD = \
++	$(LIB_roken) \
++	$(LIB_com_err)
++
++BUILT_SOURCES = \
++	wind_err.c				\
++	wind_err.h
++
++TESTS = \
++	$(check_PROGRAMS)
++
++test_punycode_SOURCES = \
++	test-punycode.c				\
++	punycode_examples.c			\
++	punycode_examples.h
++
++idn_lookup_SOURCES = idn-lookup.c
++LDADD = libwind.la $(LIB_roken)
++PYTHON = python
++@MAINTAINER_MODE_FALSE@skip_python = test -f $@ ||
++EXTRA_DIST = \
++	CompositionExclusions-3.2.0.txt \
++	DerivedNormalizationProps.txt \
++	NormalizationCorrections.txt \
++	NormalizationTest.txt \
++	UnicodeData.py \
++	UnicodeData.txt \
++	gen-bidi.py \
++	gen-combining.py \
++	gen-errorlist.py \
++	gen-map.py \
++	gen-normalize.py \
++	gen-punycode-examples.py \
++	generate.py \
++	rfc3454.py \
++	rfc3454.txt \
++	rfc3490.txt \
++	rfc3491.txt \
++	rfc3492.txt \
++	rfc4013.txt \
++	rfc4518.py \
++	rfc4518.txt \
++	stringprep.py \
++	util.py \
++	version-script.map \
++	wind_err.et
++
++CLEANFILES = \
++	wind_err.c  \
++	wind_err.h
++
++all: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign lib/wind/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign lib/wind/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++libwind.la: $(libwind_la_OBJECTS) $(libwind_la_DEPENDENCIES) 
++	$(libwind_la_LINK) -rpath $(libdir) $(libwind_la_OBJECTS) $(libwind_la_LIBADD) $(LIBS)
++install-binPROGRAMS: $(bin_PROGRAMS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do echo "$$p $$p"; done | \
++	sed 's/$(EXEEXT)$$//' | \
++	while read p p1; do if test -f $$p || test -f $$p1; \
++	  then echo "$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n;h' -e 's|.*|.|' \
++	    -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
++	sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) files[d] = files[d] " " $$1; \
++	    else { print "f", $$3 "/" $$4, $$1; } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	    if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	    test -z "$$files" || { \
++	    echo " $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	    $(INSTALL_PROGRAM_ENV) $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL_PROGRAM) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	    } \
++	; done
++
++uninstall-binPROGRAMS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	  sed -e 'h;s,^.*/,,;s/$(EXEEXT)$$//;$(transform)' \
++	      -e 's/$$/$(EXEEXT)/' `; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++clean-binPROGRAMS:
++	@list='$(bin_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++
++clean-checkPROGRAMS:
++	@list='$(check_PROGRAMS)'; test -n "$$list" || exit 0; \
++	echo " rm -f" $$list; \
++	rm -f $$list || exit $$?; \
++	test -n "$(EXEEXT)" || exit 0; \
++	list=`for p in $$list; do echo "$$p"; done | sed 's/$(EXEEXT)$$//'`; \
++	echo " rm -f" $$list; \
++	rm -f $$list
++idn-lookup$(EXEEXT): $(idn_lookup_OBJECTS) $(idn_lookup_DEPENDENCIES) 
++	@rm -f idn-lookup$(EXEEXT)
++	$(LINK) $(idn_lookup_OBJECTS) $(idn_lookup_LDADD) $(LIBS)
++test-bidi$(EXEEXT): $(test_bidi_OBJECTS) $(test_bidi_DEPENDENCIES) 
++	@rm -f test-bidi$(EXEEXT)
++	$(LINK) $(test_bidi_OBJECTS) $(test_bidi_LDADD) $(LIBS)
++test-ldap$(EXEEXT): $(test_ldap_OBJECTS) $(test_ldap_DEPENDENCIES) 
++	@rm -f test-ldap$(EXEEXT)
++	$(LINK) $(test_ldap_OBJECTS) $(test_ldap_LDADD) $(LIBS)
++test-map$(EXEEXT): $(test_map_OBJECTS) $(test_map_DEPENDENCIES) 
++	@rm -f test-map$(EXEEXT)
++	$(LINK) $(test_map_OBJECTS) $(test_map_LDADD) $(LIBS)
++test-normalize$(EXEEXT): $(test_normalize_OBJECTS) $(test_normalize_DEPENDENCIES) 
++	@rm -f test-normalize$(EXEEXT)
++	$(LINK) $(test_normalize_OBJECTS) $(test_normalize_LDADD) $(LIBS)
++test-prohibited$(EXEEXT): $(test_prohibited_OBJECTS) $(test_prohibited_DEPENDENCIES) 
++	@rm -f test-prohibited$(EXEEXT)
++	$(LINK) $(test_prohibited_OBJECTS) $(test_prohibited_LDADD) $(LIBS)
++test-punycode$(EXEEXT): $(test_punycode_OBJECTS) $(test_punycode_DEPENDENCIES) 
++	@rm -f test-punycode$(EXEEXT)
++	$(LINK) $(test_punycode_OBJECTS) $(test_punycode_LDADD) $(LIBS)
++test-rw$(EXEEXT): $(test_rw_OBJECTS) $(test_rw_DEPENDENCIES) 
++	@rm -f test-rw$(EXEEXT)
++	$(LINK) $(test_rw_OBJECTS) $(test_rw_LDADD) $(LIBS)
++test-utf8$(EXEEXT): $(test_utf8_OBJECTS) $(test_utf8_DEPENDENCIES) 
++	@rm -f test-utf8$(EXEEXT)
++	$(LINK) $(test_utf8_OBJECTS) $(test_utf8_LDADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/bidi.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/bidi_table.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/combining.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/combining_table.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/doxygen.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/errorlist.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/errorlist_table.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/idn-lookup.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/ldap.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/map.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/map_table.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/normalize.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/normalize_table.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/punycode.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/punycode_examples.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/stringprep.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test-bidi.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test-ldap.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test-map.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test-normalize.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test-prohibited.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test-punycode.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test-rw.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/test-utf8.Po@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/utf8.Plo@am__quote@
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/wind_err.Plo@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-dist_includeHEADERS: $(dist_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(dist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-dist_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(dist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++install-nodist_includeHEADERS: $(nodist_include_HEADERS)
++	@$(NORMAL_INSTALL)
++	test -z "$(includedir)" || $(MKDIR_P) "$(DESTDIR)$(includedir)"
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(includedir)'"; \
++	  $(INSTALL_HEADER) $$files "$(DESTDIR)$(includedir)" || exit $$?; \
++	done
++
++uninstall-nodist_includeHEADERS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(nodist_include_HEADERS)'; test -n "$(includedir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(includedir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(includedir)" && rm -f $$files
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) check-am
++all-am: Makefile $(LTLIBRARIES) $(PROGRAMS) $(HEADERS) all-local
++install-binPROGRAMS: install-libLTLIBRARIES
++
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)" "$(DESTDIR)$(bindir)" "$(DESTDIR)$(includedir)" "$(DESTDIR)$(includedir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: $(BUILT_SOURCES)
++	$(MAKE) $(AM_MAKEFLAGS) install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++	-test -z "$(BUILT_SOURCES)" || rm -f $(BUILT_SOURCES)
++	-test -z "$(MAINTAINERCLEANFILES)" || rm -f $(MAINTAINERCLEANFILES)
++clean: clean-am
++
++clean-am: clean-binPROGRAMS clean-checkPROGRAMS clean-generic \
++	clean-libLTLIBRARIES clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-dist_includeHEADERS \
++	install-nodist_includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binPROGRAMS install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binPROGRAMS uninstall-dist_includeHEADERS \
++	uninstall-libLTLIBRARIES uninstall-nodist_includeHEADERS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: all check check-am install install-am install-data-am \
++	install-exec-am install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-TESTS check-am \
++	check-local clean clean-binPROGRAMS clean-checkPROGRAMS \
++	clean-generic clean-libLTLIBRARIES clean-libtool ctags \
++	dist-hook distclean distclean-compile distclean-generic \
++	distclean-libtool distclean-tags distdir dvi dvi-am html \
++	html-am info info-am install install-am install-binPROGRAMS \
++	install-data install-data-am install-data-hook \
++	install-dist_includeHEADERS install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am \
++	install-libLTLIBRARIES install-man \
++	install-nodist_includeHEADERS install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-binPROGRAMS \
++	uninstall-dist_includeHEADERS uninstall-hook \
++	uninstall-libLTLIBRARIES uninstall-nodist_includeHEADERS
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++$(code:.c=.lo): $(built)
++
++$(libwind_la_OBJECTS): wind_err.h
++
++$(test_punycode_OBJECTS): $(built_tests)
++
++map_table.h map_table.c: rfc3454.txt gen-map.py stringprep.py
++	$(skip_python) $(PYTHON) $(srcdir)/gen-map.py $(srcdir)/rfc3454.txt $(builddir)
++
++errorlist_table.h errorlist_table.c: rfc3454.txt gen-errorlist.py stringprep.py
++	$(skip_python) $(PYTHON) $(srcdir)/gen-errorlist.py $(srcdir)/rfc3454.txt $(builddir)
++
++normalize_table.h normalize_table.c: UnicodeData.txt CompositionExclusions-3.2.0.txt gen-normalize.py
++	$(skip_python) $(PYTHON) $(srcdir)/gen-normalize.py $(srcdir)/UnicodeData.txt $(srcdir)/CompositionExclusions-3.2.0.txt $(builddir)
++
++combining_table.h combining_table.c: UnicodeData.txt gen-combining.py
++	$(skip_python) $(PYTHON) $(srcdir)/gen-combining.py $(srcdir)/UnicodeData.txt $(builddir)
++
++bidi_table.h bidi_table.c: rfc3454.txt gen-bidi.py
++	$(skip_python) $(PYTHON) $(srcdir)/gen-bidi.py $(srcdir)/rfc3454.txt $(builddir)
++
++punycode_examples.h punycode_examples.c: gen-punycode-examples.py rfc3492.txt
++	$(PYTHON) $(srcdir)/gen-punycode-examples.py $(srcdir)/rfc3492.txt $(builddir)
++
++wind_err.h: wind_err.et
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/ltmain.sh
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/ltmain.sh	2010-12-29 04:06:55.801838414 +0100
+@@ -0,0 +1,8413 @@
++# Generated from ltmain.m4sh.
++
++# ltmain.sh (GNU libtool) 2.2.6b
++# Written by Gordon Matzigkeit <gord@gnu.ai.mit.edu>, 1996
++
++# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007 2008 Free Software Foundation, Inc.
++# This is free software; see the source for copying conditions.  There is NO
++# warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
++
++# GNU Libtool is free software; you can redistribute it and/or modify
++# it under the terms of the GNU General Public License as published by
++# the Free Software Foundation; either version 2 of the License, or
++# (at your option) any later version.
++#
++# As a special exception to the GNU General Public License,
++# if you distribute this file as part of a program or library that
++# is built using GNU Libtool, you may include this file under the
++# same distribution terms that you use for the rest of that program.
++#
++# GNU Libtool is distributed in the hope that it will be useful, but
++# WITHOUT ANY WARRANTY; without even the implied warranty of
++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
++# General Public License for more details.
++#
++# You should have received a copy of the GNU General Public License
++# along with GNU Libtool; see the file COPYING.  If not, a copy
++# can be downloaded from http://www.gnu.org/licenses/gpl.html,
++# or obtained by writing to the Free Software Foundation, Inc.,
++# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
++
++# Usage: $progname [OPTION]... [MODE-ARG]...
++#
++# Provide generalized library-building support services.
++#
++#     --config             show all configuration variables
++#     --debug              enable verbose shell tracing
++# -n, --dry-run            display commands without modifying any files
++#     --features           display basic configuration information and exit
++#     --mode=MODE          use operation mode MODE
++#     --preserve-dup-deps  don't remove duplicate dependency libraries
++#     --quiet, --silent    don't print informational messages
++#     --tag=TAG            use configuration variables from tag TAG
++# -v, --verbose            print informational messages (default)
++#     --version            print version information
++# -h, --help               print short or long help message
++#
++# MODE must be one of the following:
++#
++#       clean              remove files from the build directory
++#       compile            compile a source file into a libtool object
++#       execute            automatically set library path, then run a program
++#       finish             complete the installation of libtool libraries
++#       install            install libraries or executables
++#       link               create a library or an executable
++#       uninstall          remove libraries from an installed directory
++#
++# MODE-ARGS vary depending on the MODE.
++# Try `$progname --help --mode=MODE' for a more detailed description of MODE.
++#
++# When reporting a bug, please describe a test case to reproduce it and
++# include the following information:
++#
++#       host-triplet:	$host
++#       shell:		$SHELL
++#       compiler:		$LTCC
++#       compiler flags:		$LTCFLAGS
++#       linker:		$LD (gnu? $with_gnu_ld)
++#       $progname:		(GNU libtool) 2.2.6b Debian-2.2.6b-2ubuntu1
++#       automake:		$automake_version
++#       autoconf:		$autoconf_version
++#
++# Report bugs to <bug-libtool@gnu.org>.
++
++PROGRAM=ltmain.sh
++PACKAGE=libtool
++VERSION="2.2.6b Debian-2.2.6b-2ubuntu1"
++TIMESTAMP=""
++package_revision=1.3017
++
++# Be Bourne compatible
++if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
++  emulate sh
++  NULLCMD=:
++  # Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which
++  # is contrary to our usage.  Disable this feature.
++  alias -g '${1+"$@"}'='"$@"'
++  setopt NO_GLOB_SUBST
++else
++  case `(set -o) 2>/dev/null` in *posix*) set -o posix;; esac
++fi
++BIN_SH=xpg4; export BIN_SH # for Tru64
++DUALCASE=1; export DUALCASE # for MKS sh
++
++# NLS nuisances: We save the old values to restore during execute mode.
++# Only set LANG and LC_ALL to C if already set.
++# These must not be set unconditionally because not all systems understand
++# e.g. LANG=C (notably SCO).
++lt_user_locale=
++lt_safe_locale=
++for lt_var in LANG LANGUAGE LC_ALL LC_CTYPE LC_COLLATE LC_MESSAGES
++do
++  eval "if test \"\${$lt_var+set}\" = set; then
++          save_$lt_var=\$$lt_var
++          $lt_var=C
++	  export $lt_var
++	  lt_user_locale=\"$lt_var=\\\$save_\$lt_var; \$lt_user_locale\"
++	  lt_safe_locale=\"$lt_var=C; \$lt_safe_locale\"
++	fi"
++done
++
++$lt_unset CDPATH
++
++
++
++
++
++: ${CP="cp -f"}
++: ${ECHO="echo"}
++: ${EGREP="/bin/grep -E"}
++: ${FGREP="/bin/grep -F"}
++: ${GREP="/bin/grep"}
++: ${LN_S="ln -s"}
++: ${MAKE="make"}
++: ${MKDIR="mkdir"}
++: ${MV="mv -f"}
++: ${RM="rm -f"}
++: ${SED="/bin/sed"}
++: ${SHELL="${CONFIG_SHELL-/bin/sh}"}
++: ${Xsed="$SED -e 1s/^X//"}
++
++# Global variables:
++EXIT_SUCCESS=0
++EXIT_FAILURE=1
++EXIT_MISMATCH=63  # $? = 63 is used to indicate version mismatch to missing.
++EXIT_SKIP=77	  # $? = 77 is used to indicate a skipped test to automake.
++
++exit_status=$EXIT_SUCCESS
++
++# Make sure IFS has a sensible default
++lt_nl='
++'
++IFS=" 	$lt_nl"
++
++dirname="s,/[^/]*$,,"
++basename="s,^.*/,,"
++
++# func_dirname_and_basename file append nondir_replacement
++# perform func_basename and func_dirname in a single function
++# call:
++#   dirname:  Compute the dirname of FILE.  If nonempty,
++#             add APPEND to the result, otherwise set result
++#             to NONDIR_REPLACEMENT.
++#             value returned in "$func_dirname_result"
++#   basename: Compute filename of FILE.
++#             value retuned in "$func_basename_result"
++# Implementation must be kept synchronized with func_dirname
++# and func_basename. For efficiency, we do not delegate to
++# those functions but instead duplicate the functionality here.
++func_dirname_and_basename ()
++{
++  # Extract subdirectory from the argument.
++  func_dirname_result=`$ECHO "X${1}" | $Xsed -e "$dirname"`
++  if test "X$func_dirname_result" = "X${1}"; then
++    func_dirname_result="${3}"
++  else
++    func_dirname_result="$func_dirname_result${2}"
++  fi
++  func_basename_result=`$ECHO "X${1}" | $Xsed -e "$basename"`
++}
++
++# Generated shell functions inserted here.
++
++# Work around backward compatibility issue on IRIX 6.5. On IRIX 6.4+, sh
++# is ksh but when the shell is invoked as "sh" and the current value of
++# the _XPG environment variable is not equal to 1 (one), the special
++# positional parameter $0, within a function call, is the name of the
++# function.
++progpath="$0"
++
++# The name of this program:
++# In the unlikely event $progname began with a '-', it would play havoc with
++# func_echo (imagine progname=-n), so we prepend ./ in that case:
++func_dirname_and_basename "$progpath"
++progname=$func_basename_result
++case $progname in
++  -*) progname=./$progname ;;
++esac
++
++# Make sure we have an absolute path for reexecution:
++case $progpath in
++  [\\/]*|[A-Za-z]:\\*) ;;
++  *[\\/]*)
++     progdir=$func_dirname_result
++     progdir=`cd "$progdir" && pwd`
++     progpath="$progdir/$progname"
++     ;;
++  *)
++     save_IFS="$IFS"
++     IFS=:
++     for progdir in $PATH; do
++       IFS="$save_IFS"
++       test -x "$progdir/$progname" && break
++     done
++     IFS="$save_IFS"
++     test -n "$progdir" || progdir=`pwd`
++     progpath="$progdir/$progname"
++     ;;
++esac
++
++# Sed substitution that helps us do robust quoting.  It backslashifies
++# metacharacters that are still active within double-quoted strings.
++Xsed="${SED}"' -e 1s/^X//'
++sed_quote_subst='s/\([`"$\\]\)/\\\1/g'
++
++# Same as above, but do not quote variable references.
++double_quote_subst='s/\(["`\\]\)/\\\1/g'
++
++# Re-`\' parameter expansions in output of double_quote_subst that were
++# `\'-ed in input to the same.  If an odd number of `\' preceded a '$'
++# in input to double_quote_subst, that '$' was protected from expansion.
++# Since each input `\' is now two `\'s, look for any number of runs of
++# four `\'s followed by two `\'s and then a '$'.  `\' that '$'.
++bs='\\'
++bs2='\\\\'
++bs4='\\\\\\\\'
++dollar='\$'
++sed_double_backslash="\
++  s/$bs4/&\\
++/g
++  s/^$bs2$dollar/$bs&/
++  s/\\([^$bs]\\)$bs2$dollar/\\1$bs2$bs$dollar/g
++  s/\n//g"
++
++# Standard options:
++opt_dry_run=false
++opt_help=false
++opt_quiet=false
++opt_verbose=false
++opt_warning=:
++
++# func_echo arg...
++# Echo program name prefixed message, along with the current mode
++# name if it has been set yet.
++func_echo ()
++{
++    $ECHO "$progname${mode+: }$mode: $*"
++}
++
++# func_verbose arg...
++# Echo program name prefixed message in verbose mode only.
++func_verbose ()
++{
++    $opt_verbose && func_echo ${1+"$@"}
++
++    # A bug in bash halts the script if the last line of a function
++    # fails when set -e is in force, so we need another command to
++    # work around that:
++    :
++}
++
++# func_error arg...
++# Echo program name prefixed message to standard error.
++func_error ()
++{
++    $ECHO "$progname${mode+: }$mode: "${1+"$@"} 1>&2
++}
++
++# func_warning arg...
++# Echo program name prefixed warning message to standard error.
++func_warning ()
++{
++    $opt_warning && $ECHO "$progname${mode+: }$mode: warning: "${1+"$@"} 1>&2
++
++    # bash bug again:
++    :
++}
++
++# func_fatal_error arg...
++# Echo program name prefixed message to standard error, and exit.
++func_fatal_error ()
++{
++    func_error ${1+"$@"}
++    exit $EXIT_FAILURE
++}
++
++# func_fatal_help arg...
++# Echo program name prefixed message to standard error, followed by
++# a help hint, and exit.
++func_fatal_help ()
++{
++    func_error ${1+"$@"}
++    func_fatal_error "$help"
++}
++help="Try \`$progname --help' for more information."  ## default
++
++
++# func_grep expression filename
++# Check whether EXPRESSION matches any line of FILENAME, without output.
++func_grep ()
++{
++    $GREP "$1" "$2" >/dev/null 2>&1
++}
++
++
++# func_mkdir_p directory-path
++# Make sure the entire path to DIRECTORY-PATH is available.
++func_mkdir_p ()
++{
++    my_directory_path="$1"
++    my_dir_list=
++
++    if test -n "$my_directory_path" && test "$opt_dry_run" != ":"; then
++
++      # Protect directory names starting with `-'
++      case $my_directory_path in
++        -*) my_directory_path="./$my_directory_path" ;;
++      esac
++
++      # While some portion of DIR does not yet exist...
++      while test ! -d "$my_directory_path"; do
++        # ...make a list in topmost first order.  Use a colon delimited
++	# list incase some portion of path contains whitespace.
++        my_dir_list="$my_directory_path:$my_dir_list"
++
++        # If the last portion added has no slash in it, the list is done
++        case $my_directory_path in */*) ;; *) break ;; esac
++
++        # ...otherwise throw away the child directory and loop
++        my_directory_path=`$ECHO "X$my_directory_path" | $Xsed -e "$dirname"`
++      done
++      my_dir_list=`$ECHO "X$my_dir_list" | $Xsed -e 's,:*$,,'`
++
++      save_mkdir_p_IFS="$IFS"; IFS=':'
++      for my_dir in $my_dir_list; do
++	IFS="$save_mkdir_p_IFS"
++        # mkdir can fail with a `File exist' error if two processes
++        # try to create one of the directories concurrently.  Don't
++        # stop in that case!
++        $MKDIR "$my_dir" 2>/dev/null || :
++      done
++      IFS="$save_mkdir_p_IFS"
++
++      # Bail out if we (or some other process) failed to create a directory.
++      test -d "$my_directory_path" || \
++        func_fatal_error "Failed to create \`$1'"
++    fi
++}
++
++
++# func_mktempdir [string]
++# Make a temporary directory that won't clash with other running
++# libtool processes, and avoids race conditions if possible.  If
++# given, STRING is the basename for that directory.
++func_mktempdir ()
++{
++    my_template="${TMPDIR-/tmp}/${1-$progname}"
++
++    if test "$opt_dry_run" = ":"; then
++      # Return a directory name, but don't create it in dry-run mode
++      my_tmpdir="${my_template}-$$"
++    else
++
++      # If mktemp works, use that first and foremost
++      my_tmpdir=`mktemp -d "${my_template}-XXXXXXXX" 2>/dev/null`
++
++      if test ! -d "$my_tmpdir"; then
++        # Failing that, at least try and use $RANDOM to avoid a race
++        my_tmpdir="${my_template}-${RANDOM-0}$$"
++
++        save_mktempdir_umask=`umask`
++        umask 0077
++        $MKDIR "$my_tmpdir"
++        umask $save_mktempdir_umask
++      fi
++
++      # If we're not in dry-run mode, bomb out on failure
++      test -d "$my_tmpdir" || \
++        func_fatal_error "cannot create temporary directory \`$my_tmpdir'"
++    fi
++
++    $ECHO "X$my_tmpdir" | $Xsed
++}
++
++
++# func_quote_for_eval arg
++# Aesthetically quote ARG to be evaled later.
++# This function returns two values: FUNC_QUOTE_FOR_EVAL_RESULT
++# is double-quoted, suitable for a subsequent eval, whereas
++# FUNC_QUOTE_FOR_EVAL_UNQUOTED_RESULT has merely all characters
++# which are still active within double quotes backslashified.
++func_quote_for_eval ()
++{
++    case $1 in
++      *[\\\`\"\$]*)
++	func_quote_for_eval_unquoted_result=`$ECHO "X$1" | $Xsed -e "$sed_quote_subst"` ;;
++      *)
++        func_quote_for_eval_unquoted_result="$1" ;;
++    esac
++
++    case $func_quote_for_eval_unquoted_result in
++      # Double-quote args containing shell metacharacters to delay
++      # word splitting, command substitution and and variable
++      # expansion for a subsequent eval.
++      # Many Bourne shells cannot handle close brackets correctly
++      # in scan sets, so we specify it separately.
++      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*|"")
++        func_quote_for_eval_result="\"$func_quote_for_eval_unquoted_result\""
++        ;;
++      *)
++        func_quote_for_eval_result="$func_quote_for_eval_unquoted_result"
++    esac
++}
++
++
++# func_quote_for_expand arg
++# Aesthetically quote ARG to be evaled later; same as above,
++# but do not quote variable references.
++func_quote_for_expand ()
++{
++    case $1 in
++      *[\\\`\"]*)
++	my_arg=`$ECHO "X$1" | $Xsed \
++	    -e "$double_quote_subst" -e "$sed_double_backslash"` ;;
++      *)
++        my_arg="$1" ;;
++    esac
++
++    case $my_arg in
++      # Double-quote args containing shell metacharacters to delay
++      # word splitting and command substitution for a subsequent eval.
++      # Many Bourne shells cannot handle close brackets correctly
++      # in scan sets, so we specify it separately.
++      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*|"")
++        my_arg="\"$my_arg\""
++        ;;
++    esac
++
++    func_quote_for_expand_result="$my_arg"
++}
++
++
++# func_show_eval cmd [fail_exp]
++# Unless opt_silent is true, then output CMD.  Then, if opt_dryrun is
++# not true, evaluate CMD.  If the evaluation of CMD fails, and FAIL_EXP
++# is given, then evaluate it.
++func_show_eval ()
++{
++    my_cmd="$1"
++    my_fail_exp="${2-:}"
++
++    ${opt_silent-false} || {
++      func_quote_for_expand "$my_cmd"
++      eval "func_echo $func_quote_for_expand_result"
++    }
++
++    if ${opt_dry_run-false}; then :; else
++      eval "$my_cmd"
++      my_status=$?
++      if test "$my_status" -eq 0; then :; else
++	eval "(exit $my_status); $my_fail_exp"
++      fi
++    fi
++}
++
++
++# func_show_eval_locale cmd [fail_exp]
++# Unless opt_silent is true, then output CMD.  Then, if opt_dryrun is
++# not true, evaluate CMD.  If the evaluation of CMD fails, and FAIL_EXP
++# is given, then evaluate it.  Use the saved locale for evaluation.
++func_show_eval_locale ()
++{
++    my_cmd="$1"
++    my_fail_exp="${2-:}"
++
++    ${opt_silent-false} || {
++      func_quote_for_expand "$my_cmd"
++      eval "func_echo $func_quote_for_expand_result"
++    }
++
++    if ${opt_dry_run-false}; then :; else
++      eval "$lt_user_locale
++	    $my_cmd"
++      my_status=$?
++      eval "$lt_safe_locale"
++      if test "$my_status" -eq 0; then :; else
++	eval "(exit $my_status); $my_fail_exp"
++      fi
++    fi
++}
++
++
++
++
++
++# func_version
++# Echo version message to standard output and exit.
++func_version ()
++{
++    $SED -n '/^# '$PROGRAM' (GNU /,/# warranty; / {
++        s/^# //
++	s/^# *$//
++        s/\((C)\)[ 0-9,-]*\( [1-9][0-9]*\)/\1\2/
++        p
++     }' < "$progpath"
++     exit $?
++}
++
++# func_usage
++# Echo short help message to standard output and exit.
++func_usage ()
++{
++    $SED -n '/^# Usage:/,/# -h/ {
++        s/^# //
++	s/^# *$//
++	s/\$progname/'$progname'/
++	p
++    }' < "$progpath"
++    $ECHO
++    $ECHO "run \`$progname --help | more' for full usage"
++    exit $?
++}
++
++# func_help
++# Echo long help message to standard output and exit.
++func_help ()
++{
++    $SED -n '/^# Usage:/,/# Report bugs to/ {
++        s/^# //
++	s/^# *$//
++	s*\$progname*'$progname'*
++	s*\$host*'"$host"'*
++	s*\$SHELL*'"$SHELL"'*
++	s*\$LTCC*'"$LTCC"'*
++	s*\$LTCFLAGS*'"$LTCFLAGS"'*
++	s*\$LD*'"$LD"'*
++	s/\$with_gnu_ld/'"$with_gnu_ld"'/
++	s/\$automake_version/'"`(automake --version) 2>/dev/null |$SED 1q`"'/
++	s/\$autoconf_version/'"`(autoconf --version) 2>/dev/null |$SED 1q`"'/
++	p
++     }' < "$progpath"
++    exit $?
++}
++
++# func_missing_arg argname
++# Echo program name prefixed message to standard error and set global
++# exit_cmd.
++func_missing_arg ()
++{
++    func_error "missing argument for $1"
++    exit_cmd=exit
++}
++
++exit_cmd=:
++
++
++
++
++
++# Check that we have a working $ECHO.
++if test "X$1" = X--no-reexec; then
++  # Discard the --no-reexec flag, and continue.
++  shift
++elif test "X$1" = X--fallback-echo; then
++  # Avoid inline document here, it may be left over
++  :
++elif test "X`{ $ECHO '\t'; } 2>/dev/null`" = 'X\t'; then
++  # Yippee, $ECHO works!
++  :
++else
++  # Restart under the correct shell, and then maybe $ECHO will work.
++  exec $SHELL "$progpath" --no-reexec ${1+"$@"}
++fi
++
++if test "X$1" = X--fallback-echo; then
++  # used as fallback echo
++  shift
++  cat <<EOF
++$*
++EOF
++  exit $EXIT_SUCCESS
++fi
++
++magic="%%%MAGIC variable%%%"
++magic_exe="%%%MAGIC EXE variable%%%"
++
++# Global variables.
++# $mode is unset
++nonopt=
++execute_dlfiles=
++preserve_args=
++lo2o="s/\\.lo\$/.${objext}/"
++o2lo="s/\\.${objext}\$/.lo/"
++extracted_archives=
++extracted_serial=0
++
++opt_dry_run=false
++opt_duplicate_deps=false
++opt_silent=false
++opt_debug=:
++
++# If this variable is set in any of the actions, the command in it
++# will be execed at the end.  This prevents here-documents from being
++# left over by shells.
++exec_cmd=
++
++# func_fatal_configuration arg...
++# Echo program name prefixed message to standard error, followed by
++# a configuration failure hint, and exit.
++func_fatal_configuration ()
++{
++    func_error ${1+"$@"}
++    func_error "See the $PACKAGE documentation for more information."
++    func_fatal_error "Fatal configuration error."
++}
++
++
++# func_config
++# Display the configuration for all the tags in this script.
++func_config ()
++{
++    re_begincf='^# ### BEGIN LIBTOOL'
++    re_endcf='^# ### END LIBTOOL'
++
++    # Default configuration.
++    $SED "1,/$re_begincf CONFIG/d;/$re_endcf CONFIG/,\$d" < "$progpath"
++
++    # Now print the configurations for the tags.
++    for tagname in $taglist; do
++      $SED -n "/$re_begincf TAG CONFIG: $tagname\$/,/$re_endcf TAG CONFIG: $tagname\$/p" < "$progpath"
++    done
++
++    exit $?
++}
++
++# func_features
++# Display the features supported by this script.
++func_features ()
++{
++    $ECHO "host: $host"
++    if test "$build_libtool_libs" = yes; then
++      $ECHO "enable shared libraries"
++    else
++      $ECHO "disable shared libraries"
++    fi
++    if test "$build_old_libs" = yes; then
++      $ECHO "enable static libraries"
++    else
++      $ECHO "disable static libraries"
++    fi
++
++    exit $?
++}
++
++# func_enable_tag tagname
++# Verify that TAGNAME is valid, and either flag an error and exit, or
++# enable the TAGNAME tag.  We also add TAGNAME to the global $taglist
++# variable here.
++func_enable_tag ()
++{
++  # Global variable:
++  tagname="$1"
++
++  re_begincf="^# ### BEGIN LIBTOOL TAG CONFIG: $tagname\$"
++  re_endcf="^# ### END LIBTOOL TAG CONFIG: $tagname\$"
++  sed_extractcf="/$re_begincf/,/$re_endcf/p"
++
++  # Validate tagname.
++  case $tagname in
++    *[!-_A-Za-z0-9,/]*)
++      func_fatal_error "invalid tag name: $tagname"
++      ;;
++  esac
++
++  # Don't test for the "default" C tag, as we know it's
++  # there but not specially marked.
++  case $tagname in
++    CC) ;;
++    *)
++      if $GREP "$re_begincf" "$progpath" >/dev/null 2>&1; then
++	taglist="$taglist $tagname"
++
++	# Evaluate the configuration.  Be careful to quote the path
++	# and the sed script, to avoid splitting on whitespace, but
++	# also don't use non-portable quotes within backquotes within
++	# quotes we have to do it in 2 steps:
++	extractedcf=`$SED -n -e "$sed_extractcf" < "$progpath"`
++	eval "$extractedcf"
++      else
++	func_error "ignoring unknown tag $tagname"
++      fi
++      ;;
++  esac
++}
++
++# Parse options once, thoroughly.  This comes as soon as possible in
++# the script to make things like `libtool --version' happen quickly.
++{
++
++  # Shorthand for --mode=foo, only valid as the first argument
++  case $1 in
++  clean|clea|cle|cl)
++    shift; set dummy --mode clean ${1+"$@"}; shift
++    ;;
++  compile|compil|compi|comp|com|co|c)
++    shift; set dummy --mode compile ${1+"$@"}; shift
++    ;;
++  execute|execut|execu|exec|exe|ex|e)
++    shift; set dummy --mode execute ${1+"$@"}; shift
++    ;;
++  finish|finis|fini|fin|fi|f)
++    shift; set dummy --mode finish ${1+"$@"}; shift
++    ;;
++  install|instal|insta|inst|ins|in|i)
++    shift; set dummy --mode install ${1+"$@"}; shift
++    ;;
++  link|lin|li|l)
++    shift; set dummy --mode link ${1+"$@"}; shift
++    ;;
++  uninstall|uninstal|uninsta|uninst|unins|unin|uni|un|u)
++    shift; set dummy --mode uninstall ${1+"$@"}; shift
++    ;;
++  esac
++
++  # Parse non-mode specific arguments:
++  while test "$#" -gt 0; do
++    opt="$1"
++    shift
++
++    case $opt in
++      --config)		func_config					;;
++
++      --debug)		preserve_args="$preserve_args $opt"
++			func_echo "enabling shell trace mode"
++			opt_debug='set -x'
++			$opt_debug
++			;;
++
++      -dlopen)		test "$#" -eq 0 && func_missing_arg "$opt" && break
++			execute_dlfiles="$execute_dlfiles $1"
++			shift
++			;;
++
++      --dry-run | -n)	opt_dry_run=:					;;
++      --features)       func_features					;;
++      --finish)		mode="finish"					;;
++
++      --mode)		test "$#" -eq 0 && func_missing_arg "$opt" && break
++			case $1 in
++			  # Valid mode arguments:
++			  clean)	;;
++			  compile)	;;
++			  execute)	;;
++			  finish)	;;
++			  install)	;;
++			  link)		;;
++			  relink)	;;
++			  uninstall)	;;
++
++			  # Catch anything else as an error
++			  *) func_error "invalid argument for $opt"
++			     exit_cmd=exit
++			     break
++			     ;;
++		        esac
++
++			mode="$1"
++			shift
++			;;
++
++      --preserve-dup-deps)
++			opt_duplicate_deps=:				;;
++
++      --quiet|--silent)	preserve_args="$preserve_args $opt"
++			opt_silent=:
++			;;
++
++      --verbose| -v)	preserve_args="$preserve_args $opt"
++			opt_silent=false
++			;;
++
++      --tag)		test "$#" -eq 0 && func_missing_arg "$opt" && break
++			preserve_args="$preserve_args $opt $1"
++			func_enable_tag "$1"	# tagname is set here
++			shift
++			;;
++
++      # Separate optargs to long options:
++      -dlopen=*|--mode=*|--tag=*)
++			func_opt_split "$opt"
++			set dummy "$func_opt_split_opt" "$func_opt_split_arg" ${1+"$@"}
++			shift
++			;;
++
++      -\?|-h)		func_usage					;;
++      --help)		opt_help=:					;;
++      --version)	func_version					;;
++
++      -*)		func_fatal_help "unrecognized option \`$opt'"	;;
++
++      *)		nonopt="$opt"
++			break
++			;;
++    esac
++  done
++
++
++  case $host in
++    *cygwin* | *mingw* | *pw32* | *cegcc*)
++      # don't eliminate duplications in $postdeps and $predeps
++      opt_duplicate_compiler_generated_deps=:
++      ;;
++    *)
++      opt_duplicate_compiler_generated_deps=$opt_duplicate_deps
++      ;;
++  esac
++
++  # Having warned about all mis-specified options, bail out if
++  # anything was wrong.
++  $exit_cmd $EXIT_FAILURE
++}
++
++# func_check_version_match
++# Ensure that we are using m4 macros, and libtool script from the same
++# release of libtool.
++func_check_version_match ()
++{
++  if test "$package_revision" != "$macro_revision"; then
++    if test "$VERSION" != "$macro_version"; then
++      if test -z "$macro_version"; then
++        cat >&2 <<_LT_EOF
++$progname: Version mismatch error.  This is $PACKAGE $VERSION, but the
++$progname: definition of this LT_INIT comes from an older release.
++$progname: You should recreate aclocal.m4 with macros from $PACKAGE $VERSION
++$progname: and run autoconf again.
++_LT_EOF
++      else
++        cat >&2 <<_LT_EOF
++$progname: Version mismatch error.  This is $PACKAGE $VERSION, but the
++$progname: definition of this LT_INIT comes from $PACKAGE $macro_version.
++$progname: You should recreate aclocal.m4 with macros from $PACKAGE $VERSION
++$progname: and run autoconf again.
++_LT_EOF
++      fi
++    else
++      cat >&2 <<_LT_EOF
++$progname: Version mismatch error.  This is $PACKAGE $VERSION, revision $package_revision,
++$progname: but the definition of this LT_INIT comes from revision $macro_revision.
++$progname: You should recreate aclocal.m4 with macros from revision $package_revision
++$progname: of $PACKAGE $VERSION and run autoconf again.
++_LT_EOF
++    fi
++
++    exit $EXIT_MISMATCH
++  fi
++}
++
++
++## ----------- ##
++##    Main.    ##
++## ----------- ##
++
++$opt_help || {
++  # Sanity checks first:
++  func_check_version_match
++
++  if test "$build_libtool_libs" != yes && test "$build_old_libs" != yes; then
++    func_fatal_configuration "not configured to build any kind of library"
++  fi
++
++  test -z "$mode" && func_fatal_error "error: you must specify a MODE."
++
++
++  # Darwin sucks
++  eval std_shrext=\"$shrext_cmds\"
++
++
++  # Only execute mode is allowed to have -dlopen flags.
++  if test -n "$execute_dlfiles" && test "$mode" != execute; then
++    func_error "unrecognized option \`-dlopen'"
++    $ECHO "$help" 1>&2
++    exit $EXIT_FAILURE
++  fi
++
++  # Change the help message to a mode-specific one.
++  generic_help="$help"
++  help="Try \`$progname --help --mode=$mode' for more information."
++}
++
++
++# func_lalib_p file
++# True iff FILE is a libtool `.la' library or `.lo' object file.
++# This function is only a basic sanity check; it will hardly flush out
++# determined imposters.
++func_lalib_p ()
++{
++    test -f "$1" &&
++      $SED -e 4q "$1" 2>/dev/null \
++        | $GREP "^# Generated by .*$PACKAGE" > /dev/null 2>&1
++}
++
++# func_lalib_unsafe_p file
++# True iff FILE is a libtool `.la' library or `.lo' object file.
++# This function implements the same check as func_lalib_p without
++# resorting to external programs.  To this end, it redirects stdin and
++# closes it afterwards, without saving the original file descriptor.
++# As a safety measure, use it only where a negative result would be
++# fatal anyway.  Works if `file' does not exist.
++func_lalib_unsafe_p ()
++{
++    lalib_p=no
++    if test -f "$1" && test -r "$1" && exec 5<&0 <"$1"; then
++	for lalib_p_l in 1 2 3 4
++	do
++	    read lalib_p_line
++	    case "$lalib_p_line" in
++		\#\ Generated\ by\ *$PACKAGE* ) lalib_p=yes; break;;
++	    esac
++	done
++	exec 0<&5 5<&-
++    fi
++    test "$lalib_p" = yes
++}
++
++# func_ltwrapper_script_p file
++# True iff FILE is a libtool wrapper script
++# This function is only a basic sanity check; it will hardly flush out
++# determined imposters.
++func_ltwrapper_script_p ()
++{
++    func_lalib_p "$1"
++}
++
++# func_ltwrapper_executable_p file
++# True iff FILE is a libtool wrapper executable
++# This function is only a basic sanity check; it will hardly flush out
++# determined imposters.
++func_ltwrapper_executable_p ()
++{
++    func_ltwrapper_exec_suffix=
++    case $1 in
++    *.exe) ;;
++    *) func_ltwrapper_exec_suffix=.exe ;;
++    esac
++    $GREP "$magic_exe" "$1$func_ltwrapper_exec_suffix" >/dev/null 2>&1
++}
++
++# func_ltwrapper_scriptname file
++# Assumes file is an ltwrapper_executable
++# uses $file to determine the appropriate filename for a
++# temporary ltwrapper_script.
++func_ltwrapper_scriptname ()
++{
++    func_ltwrapper_scriptname_result=""
++    if func_ltwrapper_executable_p "$1"; then
++	func_dirname_and_basename "$1" "" "."
++	func_stripname '' '.exe' "$func_basename_result"
++	func_ltwrapper_scriptname_result="$func_dirname_result/$objdir/${func_stripname_result}_ltshwrapper"
++    fi
++}
++
++# func_ltwrapper_p file
++# True iff FILE is a libtool wrapper script or wrapper executable
++# This function is only a basic sanity check; it will hardly flush out
++# determined imposters.
++func_ltwrapper_p ()
++{
++    func_ltwrapper_script_p "$1" || func_ltwrapper_executable_p "$1"
++}
++
++
++# func_execute_cmds commands fail_cmd
++# Execute tilde-delimited COMMANDS.
++# If FAIL_CMD is given, eval that upon failure.
++# FAIL_CMD may read-access the current command in variable CMD!
++func_execute_cmds ()
++{
++    $opt_debug
++    save_ifs=$IFS; IFS='~'
++    for cmd in $1; do
++      IFS=$save_ifs
++      eval cmd=\"$cmd\"
++      func_show_eval "$cmd" "${2-:}"
++    done
++    IFS=$save_ifs
++}
++
++
++# func_source file
++# Source FILE, adding directory component if necessary.
++# Note that it is not necessary on cygwin/mingw to append a dot to
++# FILE even if both FILE and FILE.exe exist: automatic-append-.exe
++# behavior happens only for exec(3), not for open(2)!  Also, sourcing
++# `FILE.' does not work on cygwin managed mounts.
++func_source ()
++{
++    $opt_debug
++    case $1 in
++    */* | *\\*)	. "$1" ;;
++    *)		. "./$1" ;;
++    esac
++}
++
++
++# func_infer_tag arg
++# Infer tagged configuration to use if any are available and
++# if one wasn't chosen via the "--tag" command line option.
++# Only attempt this if the compiler in the base compile
++# command doesn't match the default compiler.
++# arg is usually of the form 'gcc ...'
++func_infer_tag ()
++{
++    $opt_debug
++    if test -n "$available_tags" && test -z "$tagname"; then
++      CC_quoted=
++      for arg in $CC; do
++        func_quote_for_eval "$arg"
++	CC_quoted="$CC_quoted $func_quote_for_eval_result"
++      done
++      case $@ in
++      # Blanks in the command may have been stripped by the calling shell,
++      # but not from the CC environment variable when configure was run.
++      " $CC "* | "$CC "* | " `$ECHO $CC` "* | "`$ECHO $CC` "* | " $CC_quoted"* | "$CC_quoted "* | " `$ECHO $CC_quoted` "* | "`$ECHO $CC_quoted` "*) ;;
++      # Blanks at the start of $base_compile will cause this to fail
++      # if we don't check for them as well.
++      *)
++	for z in $available_tags; do
++	  if $GREP "^# ### BEGIN LIBTOOL TAG CONFIG: $z$" < "$progpath" > /dev/null; then
++	    # Evaluate the configuration.
++	    eval "`${SED} -n -e '/^# ### BEGIN LIBTOOL TAG CONFIG: '$z'$/,/^# ### END LIBTOOL TAG CONFIG: '$z'$/p' < $progpath`"
++	    CC_quoted=
++	    for arg in $CC; do
++	      # Double-quote args containing other shell metacharacters.
++	      func_quote_for_eval "$arg"
++	      CC_quoted="$CC_quoted $func_quote_for_eval_result"
++	    done
++	    case "$@ " in
++	      " $CC "* | "$CC "* | " `$ECHO $CC` "* | "`$ECHO $CC` "* | " $CC_quoted"* | "$CC_quoted "* | " `$ECHO $CC_quoted` "* | "`$ECHO $CC_quoted` "*)
++	      # The compiler in the base compile command matches
++	      # the one in the tagged configuration.
++	      # Assume this is the tagged configuration we want.
++	      tagname=$z
++	      break
++	      ;;
++	    esac
++	  fi
++	done
++	# If $tagname still isn't set, then no tagged configuration
++	# was found and let the user know that the "--tag" command
++	# line option must be used.
++	if test -z "$tagname"; then
++	  func_echo "unable to infer tagged configuration"
++	  func_fatal_error "specify a tag with \`--tag'"
++#	else
++#	  func_verbose "using $tagname tagged configuration"
++	fi
++	;;
++      esac
++    fi
++}
++
++
++
++# func_write_libtool_object output_name pic_name nonpic_name
++# Create a libtool object file (analogous to a ".la" file),
++# but don't create it if we're doing a dry run.
++func_write_libtool_object ()
++{
++    write_libobj=${1}
++    if test "$build_libtool_libs" = yes; then
++      write_lobj=\'${2}\'
++    else
++      write_lobj=none
++    fi
++
++    if test "$build_old_libs" = yes; then
++      write_oldobj=\'${3}\'
++    else
++      write_oldobj=none
++    fi
++
++    $opt_dry_run || {
++      cat >${write_libobj}T <<EOF
++# $write_libobj - a libtool object file
++# Generated by $PROGRAM (GNU $PACKAGE$TIMESTAMP) $VERSION
++#
++# Please DO NOT delete this file!
++# It is necessary for linking the library.
++
++# Name of the PIC object.
++pic_object=$write_lobj
++
++# Name of the non-PIC object
++non_pic_object=$write_oldobj
++
++EOF
++      $MV "${write_libobj}T" "${write_libobj}"
++    }
++}
++
++# func_mode_compile arg...
++func_mode_compile ()
++{
++    $opt_debug
++    # Get the compilation command and the source file.
++    base_compile=
++    srcfile="$nonopt"  #  always keep a non-empty value in "srcfile"
++    suppress_opt=yes
++    suppress_output=
++    arg_mode=normal
++    libobj=
++    later=
++    pie_flag=
++
++    for arg
++    do
++      case $arg_mode in
++      arg  )
++	# do not "continue".  Instead, add this to base_compile
++	lastarg="$arg"
++	arg_mode=normal
++	;;
++
++      target )
++	libobj="$arg"
++	arg_mode=normal
++	continue
++	;;
++
++      normal )
++	# Accept any command-line options.
++	case $arg in
++	-o)
++	  test -n "$libobj" && \
++	    func_fatal_error "you cannot specify \`-o' more than once"
++	  arg_mode=target
++	  continue
++	  ;;
++
++	-pie | -fpie | -fPIE)
++          pie_flag="$pie_flag $arg"
++	  continue
++	  ;;
++
++	-shared | -static | -prefer-pic | -prefer-non-pic)
++	  later="$later $arg"
++	  continue
++	  ;;
++
++	-no-suppress)
++	  suppress_opt=no
++	  continue
++	  ;;
++
++	-Xcompiler)
++	  arg_mode=arg  #  the next one goes into the "base_compile" arg list
++	  continue      #  The current "srcfile" will either be retained or
++	  ;;            #  replaced later.  I would guess that would be a bug.
++
++	-Wc,*)
++	  func_stripname '-Wc,' '' "$arg"
++	  args=$func_stripname_result
++	  lastarg=
++	  save_ifs="$IFS"; IFS=','
++	  for arg in $args; do
++	    IFS="$save_ifs"
++	    func_quote_for_eval "$arg"
++	    lastarg="$lastarg $func_quote_for_eval_result"
++	  done
++	  IFS="$save_ifs"
++	  func_stripname ' ' '' "$lastarg"
++	  lastarg=$func_stripname_result
++
++	  # Add the arguments to base_compile.
++	  base_compile="$base_compile $lastarg"
++	  continue
++	  ;;
++
++	*)
++	  # Accept the current argument as the source file.
++	  # The previous "srcfile" becomes the current argument.
++	  #
++	  lastarg="$srcfile"
++	  srcfile="$arg"
++	  ;;
++	esac  #  case $arg
++	;;
++      esac    #  case $arg_mode
++
++      # Aesthetically quote the previous argument.
++      func_quote_for_eval "$lastarg"
++      base_compile="$base_compile $func_quote_for_eval_result"
++    done # for arg
++
++    case $arg_mode in
++    arg)
++      func_fatal_error "you must specify an argument for -Xcompile"
++      ;;
++    target)
++      func_fatal_error "you must specify a target with \`-o'"
++      ;;
++    *)
++      # Get the name of the library object.
++      test -z "$libobj" && {
++	func_basename "$srcfile"
++	libobj="$func_basename_result"
++      }
++      ;;
++    esac
++
++    # Recognize several different file suffixes.
++    # If the user specifies -o file.o, it is replaced with file.lo
++    case $libobj in
++    *.[cCFSifmso] | \
++    *.ada | *.adb | *.ads | *.asm | \
++    *.c++ | *.cc | *.ii | *.class | *.cpp | *.cxx | \
++    *.[fF][09]? | *.for | *.java | *.obj | *.sx)
++      func_xform "$libobj"
++      libobj=$func_xform_result
++      ;;
++    esac
++
++    case $libobj in
++    *.lo) func_lo2o "$libobj"; obj=$func_lo2o_result ;;
++    *)
++      func_fatal_error "cannot determine name of library object from \`$libobj'"
++      ;;
++    esac
++
++    func_infer_tag $base_compile
++
++    for arg in $later; do
++      case $arg in
++      -shared)
++	test "$build_libtool_libs" != yes && \
++	  func_fatal_configuration "can not build a shared library"
++	build_old_libs=no
++	continue
++	;;
++
++      -static)
++	build_libtool_libs=no
++	build_old_libs=yes
++	continue
++	;;
++
++      -prefer-pic)
++	pic_mode=yes
++	continue
++	;;
++
++      -prefer-non-pic)
++	pic_mode=no
++	continue
++	;;
++      esac
++    done
++
++    func_quote_for_eval "$libobj"
++    test "X$libobj" != "X$func_quote_for_eval_result" \
++      && $ECHO "X$libobj" | $GREP '[]~#^*{};<>?"'"'"'	 &()|`$[]' \
++      && func_warning "libobj name \`$libobj' may not contain shell special characters."
++    func_dirname_and_basename "$obj" "/" ""
++    objname="$func_basename_result"
++    xdir="$func_dirname_result"
++    lobj=${xdir}$objdir/$objname
++
++    test -z "$base_compile" && \
++      func_fatal_help "you must specify a compilation command"
++
++    # Delete any leftover library objects.
++    if test "$build_old_libs" = yes; then
++      removelist="$obj $lobj $libobj ${libobj}T"
++    else
++      removelist="$lobj $libobj ${libobj}T"
++    fi
++
++    # On Cygwin there's no "real" PIC flag so we must build both object types
++    case $host_os in
++    cygwin* | mingw* | pw32* | os2* | cegcc*)
++      pic_mode=default
++      ;;
++    esac
++    if test "$pic_mode" = no && test "$deplibs_check_method" != pass_all; then
++      # non-PIC code in shared libraries is not supported
++      pic_mode=default
++    fi
++
++    # Calculate the filename of the output object if compiler does
++    # not support -o with -c
++    if test "$compiler_c_o" = no; then
++      output_obj=`$ECHO "X$srcfile" | $Xsed -e 's%^.*/%%' -e 's%\.[^.]*$%%'`.${objext}
++      lockfile="$output_obj.lock"
++    else
++      output_obj=
++      need_locks=no
++      lockfile=
++    fi
++
++    # Lock this critical section if it is needed
++    # We use this script file to make the link, it avoids creating a new file
++    if test "$need_locks" = yes; then
++      until $opt_dry_run || ln "$progpath" "$lockfile" 2>/dev/null; do
++	func_echo "Waiting for $lockfile to be removed"
++	sleep 2
++      done
++    elif test "$need_locks" = warn; then
++      if test -f "$lockfile"; then
++	$ECHO "\
++*** ERROR, $lockfile exists and contains:
++`cat $lockfile 2>/dev/null`
++
++This indicates that another process is trying to use the same
++temporary object file, and libtool could not work around it because
++your compiler does not support \`-c' and \`-o' together.  If you
++repeat this compilation, it may succeed, by chance, but you had better
++avoid parallel builds (make -j) in this platform, or get a better
++compiler."
++
++	$opt_dry_run || $RM $removelist
++	exit $EXIT_FAILURE
++      fi
++      removelist="$removelist $output_obj"
++      $ECHO "$srcfile" > "$lockfile"
++    fi
++
++    $opt_dry_run || $RM $removelist
++    removelist="$removelist $lockfile"
++    trap '$opt_dry_run || $RM $removelist; exit $EXIT_FAILURE' 1 2 15
++
++    if test -n "$fix_srcfile_path"; then
++      eval srcfile=\"$fix_srcfile_path\"
++    fi
++    func_quote_for_eval "$srcfile"
++    qsrcfile=$func_quote_for_eval_result
++
++    # Only build a PIC object if we are building libtool libraries.
++    if test "$build_libtool_libs" = yes; then
++      # Without this assignment, base_compile gets emptied.
++      fbsd_hideous_sh_bug=$base_compile
++
++      if test "$pic_mode" != no; then
++	command="$base_compile $qsrcfile $pic_flag"
++      else
++	# Don't build PIC code
++	command="$base_compile $qsrcfile"
++      fi
++
++      func_mkdir_p "$xdir$objdir"
++
++      if test -z "$output_obj"; then
++	# Place PIC objects in $objdir
++	command="$command -o $lobj"
++      fi
++
++      func_show_eval_locale "$command"	\
++          'test -n "$output_obj" && $RM $removelist; exit $EXIT_FAILURE'
++
++      if test "$need_locks" = warn &&
++	 test "X`cat $lockfile 2>/dev/null`" != "X$srcfile"; then
++	$ECHO "\
++*** ERROR, $lockfile contains:
++`cat $lockfile 2>/dev/null`
++
++but it should contain:
++$srcfile
++
++This indicates that another process is trying to use the same
++temporary object file, and libtool could not work around it because
++your compiler does not support \`-c' and \`-o' together.  If you
++repeat this compilation, it may succeed, by chance, but you had better
++avoid parallel builds (make -j) in this platform, or get a better
++compiler."
++
++	$opt_dry_run || $RM $removelist
++	exit $EXIT_FAILURE
++      fi
++
++      # Just move the object if needed, then go on to compile the next one
++      if test -n "$output_obj" && test "X$output_obj" != "X$lobj"; then
++	func_show_eval '$MV "$output_obj" "$lobj"' \
++	  'error=$?; $opt_dry_run || $RM $removelist; exit $error'
++      fi
++
++      # Allow error messages only from the first compilation.
++      if test "$suppress_opt" = yes; then
++	suppress_output=' >/dev/null 2>&1'
++      fi
++    fi
++
++    # Only build a position-dependent object if we build old libraries.
++    if test "$build_old_libs" = yes; then
++      if test "$pic_mode" != yes; then
++	# Don't build PIC code
++	command="$base_compile $qsrcfile$pie_flag"
++      else
++	command="$base_compile $qsrcfile $pic_flag"
++      fi
++      if test "$compiler_c_o" = yes; then
++	command="$command -o $obj"
++      fi
++
++      # Suppress compiler output if we already did a PIC compilation.
++      command="$command$suppress_output"
++      func_show_eval_locale "$command" \
++        '$opt_dry_run || $RM $removelist; exit $EXIT_FAILURE'
++
++      if test "$need_locks" = warn &&
++	 test "X`cat $lockfile 2>/dev/null`" != "X$srcfile"; then
++	$ECHO "\
++*** ERROR, $lockfile contains:
++`cat $lockfile 2>/dev/null`
++
++but it should contain:
++$srcfile
++
++This indicates that another process is trying to use the same
++temporary object file, and libtool could not work around it because
++your compiler does not support \`-c' and \`-o' together.  If you
++repeat this compilation, it may succeed, by chance, but you had better
++avoid parallel builds (make -j) in this platform, or get a better
++compiler."
++
++	$opt_dry_run || $RM $removelist
++	exit $EXIT_FAILURE
++      fi
++
++      # Just move the object if needed
++      if test -n "$output_obj" && test "X$output_obj" != "X$obj"; then
++	func_show_eval '$MV "$output_obj" "$obj"' \
++	  'error=$?; $opt_dry_run || $RM $removelist; exit $error'
++      fi
++    fi
++
++    $opt_dry_run || {
++      func_write_libtool_object "$libobj" "$objdir/$objname" "$objname"
++
++      # Unlock the critical section if it was locked
++      if test "$need_locks" != no; then
++	removelist=$lockfile
++        $RM "$lockfile"
++      fi
++    }
++
++    exit $EXIT_SUCCESS
++}
++
++$opt_help || {
++test "$mode" = compile && func_mode_compile ${1+"$@"}
++}
++
++func_mode_help ()
++{
++    # We need to display help for each of the modes.
++    case $mode in
++      "")
++        # Generic help is extracted from the usage comments
++        # at the start of this file.
++        func_help
++        ;;
++
++      clean)
++        $ECHO \
++"Usage: $progname [OPTION]... --mode=clean RM [RM-OPTION]... FILE...
++
++Remove files from the build directory.
++
++RM is the name of the program to use to delete files associated with each FILE
++(typically \`/bin/rm').  RM-OPTIONS are options (such as \`-f') to be passed
++to RM.
++
++If FILE is a libtool library, object or program, all the files associated
++with it are deleted. Otherwise, only FILE itself is deleted using RM."
++        ;;
++
++      compile)
++      $ECHO \
++"Usage: $progname [OPTION]... --mode=compile COMPILE-COMMAND... SOURCEFILE
++
++Compile a source file into a libtool library object.
++
++This mode accepts the following additional options:
++
++  -o OUTPUT-FILE    set the output file name to OUTPUT-FILE
++  -no-suppress      do not suppress compiler output for multiple passes
++  -prefer-pic       try to building PIC objects only
++  -prefer-non-pic   try to building non-PIC objects only
++  -shared           do not build a \`.o' file suitable for static linking
++  -static           only build a \`.o' file suitable for static linking
++
++COMPILE-COMMAND is a command to be used in creating a \`standard' object file
++from the given SOURCEFILE.
++
++The output file name is determined by removing the directory component from
++SOURCEFILE, then substituting the C source code suffix \`.c' with the
++library object suffix, \`.lo'."
++        ;;
++
++      execute)
++        $ECHO \
++"Usage: $progname [OPTION]... --mode=execute COMMAND [ARGS]...
++
++Automatically set library path, then run a program.
++
++This mode accepts the following additional options:
++
++  -dlopen FILE      add the directory containing FILE to the library path
++
++This mode sets the library path environment variable according to \`-dlopen'
++flags.
++
++If any of the ARGS are libtool executable wrappers, then they are translated
++into their corresponding uninstalled binary, and any of their required library
++directories are added to the library path.
++
++Then, COMMAND is executed, with ARGS as arguments."
++        ;;
++
++      finish)
++        $ECHO \
++"Usage: $progname [OPTION]... --mode=finish [LIBDIR]...
++
++Complete the installation of libtool libraries.
++
++Each LIBDIR is a directory that contains libtool libraries.
++
++The commands that this mode executes may require superuser privileges.  Use
++the \`--dry-run' option if you just want to see what would be executed."
++        ;;
++
++      install)
++        $ECHO \
++"Usage: $progname [OPTION]... --mode=install INSTALL-COMMAND...
++
++Install executables or libraries.
++
++INSTALL-COMMAND is the installation command.  The first component should be
++either the \`install' or \`cp' program.
++
++The following components of INSTALL-COMMAND are treated specially:
++
++  -inst-prefix PREFIX-DIR  Use PREFIX-DIR as a staging area for installation
++
++The rest of the components are interpreted as arguments to that command (only
++BSD-compatible install options are recognized)."
++        ;;
++
++      link)
++        $ECHO \
++"Usage: $progname [OPTION]... --mode=link LINK-COMMAND...
++
++Link object files or libraries together to form another library, or to
++create an executable program.
++
++LINK-COMMAND is a command using the C compiler that you would use to create
++a program from several object files.
++
++The following components of LINK-COMMAND are treated specially:
++
++  -all-static       do not do any dynamic linking at all
++  -avoid-version    do not add a version suffix if possible
++  -dlopen FILE      \`-dlpreopen' FILE if it cannot be dlopened at runtime
++  -dlpreopen FILE   link in FILE and add its symbols to lt_preloaded_symbols
++  -export-dynamic   allow symbols from OUTPUT-FILE to be resolved with dlsym(3)
++  -export-symbols SYMFILE
++                    try to export only the symbols listed in SYMFILE
++  -export-symbols-regex REGEX
++                    try to export only the symbols matching REGEX
++  -LLIBDIR          search LIBDIR for required installed libraries
++  -lNAME            OUTPUT-FILE requires the installed library libNAME
++  -module           build a library that can dlopened
++  -no-fast-install  disable the fast-install mode
++  -no-install       link a not-installable executable
++  -no-undefined     declare that a library does not refer to external symbols
++  -o OUTPUT-FILE    create OUTPUT-FILE from the specified objects
++  -objectlist FILE  Use a list of object files found in FILE to specify objects
++  -precious-files-regex REGEX
++                    don't remove output files matching REGEX
++  -release RELEASE  specify package release information
++  -rpath LIBDIR     the created library will eventually be installed in LIBDIR
++  -R[ ]LIBDIR       add LIBDIR to the runtime path of programs and libraries
++  -shared           only do dynamic linking of libtool libraries
++  -shrext SUFFIX    override the standard shared library file extension
++  -static           do not do any dynamic linking of uninstalled libtool libraries
++  -static-libtool-libs
++                    do not do any dynamic linking of libtool libraries
++  -version-info CURRENT[:REVISION[:AGE]]
++                    specify library version info [each variable defaults to 0]
++  -weak LIBNAME     declare that the target provides the LIBNAME interface
++
++All other options (arguments beginning with \`-') are ignored.
++
++Every other argument is treated as a filename.  Files ending in \`.la' are
++treated as uninstalled libtool libraries, other files are standard or library
++object files.
++
++If the OUTPUT-FILE ends in \`.la', then a libtool library is created,
++only library objects (\`.lo' files) may be specified, and \`-rpath' is
++required, except when creating a convenience library.
++
++If OUTPUT-FILE ends in \`.a' or \`.lib', then a standard library is created
++using \`ar' and \`ranlib', or on Windows using \`lib'.
++
++If OUTPUT-FILE ends in \`.lo' or \`.${objext}', then a reloadable object file
++is created, otherwise an executable program is created."
++        ;;
++
++      uninstall)
++        $ECHO \
++"Usage: $progname [OPTION]... --mode=uninstall RM [RM-OPTION]... FILE...
++
++Remove libraries from an installation directory.
++
++RM is the name of the program to use to delete files associated with each FILE
++(typically \`/bin/rm').  RM-OPTIONS are options (such as \`-f') to be passed
++to RM.
++
++If FILE is a libtool library, all the files associated with it are deleted.
++Otherwise, only FILE itself is deleted using RM."
++        ;;
++
++      *)
++        func_fatal_help "invalid operation mode \`$mode'"
++        ;;
++    esac
++
++    $ECHO
++    $ECHO "Try \`$progname --help' for more information about other modes."
++
++    exit $?
++}
++
++  # Now that we've collected a possible --mode arg, show help if necessary
++  $opt_help && func_mode_help
++
++
++# func_mode_execute arg...
++func_mode_execute ()
++{
++    $opt_debug
++    # The first argument is the command name.
++    cmd="$nonopt"
++    test -z "$cmd" && \
++      func_fatal_help "you must specify a COMMAND"
++
++    # Handle -dlopen flags immediately.
++    for file in $execute_dlfiles; do
++      test -f "$file" \
++	|| func_fatal_help "\`$file' is not a file"
++
++      dir=
++      case $file in
++      *.la)
++	# Check to see that this really is a libtool archive.
++	func_lalib_unsafe_p "$file" \
++	  || func_fatal_help "\`$lib' is not a valid libtool archive"
++
++	# Read the libtool library.
++	dlname=
++	library_names=
++	func_source "$file"
++
++	# Skip this library if it cannot be dlopened.
++	if test -z "$dlname"; then
++	  # Warn if it was a shared library.
++	  test -n "$library_names" && \
++	    func_warning "\`$file' was not linked with \`-export-dynamic'"
++	  continue
++	fi
++
++	func_dirname "$file" "" "."
++	dir="$func_dirname_result"
++
++	if test -f "$dir/$objdir/$dlname"; then
++	  dir="$dir/$objdir"
++	else
++	  if test ! -f "$dir/$dlname"; then
++	    func_fatal_error "cannot find \`$dlname' in \`$dir' or \`$dir/$objdir'"
++	  fi
++	fi
++	;;
++
++      *.lo)
++	# Just add the directory containing the .lo file.
++	func_dirname "$file" "" "."
++	dir="$func_dirname_result"
++	;;
++
++      *)
++	func_warning "\`-dlopen' is ignored for non-libtool libraries and objects"
++	continue
++	;;
++      esac
++
++      # Get the absolute pathname.
++      absdir=`cd "$dir" && pwd`
++      test -n "$absdir" && dir="$absdir"
++
++      # Now add the directory to shlibpath_var.
++      if eval "test -z \"\$$shlibpath_var\""; then
++	eval "$shlibpath_var=\"\$dir\""
++      else
++	eval "$shlibpath_var=\"\$dir:\$$shlibpath_var\""
++      fi
++    done
++
++    # This variable tells wrapper scripts just to set shlibpath_var
++    # rather than running their programs.
++    libtool_execute_magic="$magic"
++
++    # Check if any of the arguments is a wrapper script.
++    args=
++    for file
++    do
++      case $file in
++      -*) ;;
++      *)
++	# Do a test to see if this is really a libtool program.
++	if func_ltwrapper_script_p "$file"; then
++	  func_source "$file"
++	  # Transform arg to wrapped name.
++	  file="$progdir/$program"
++	elif func_ltwrapper_executable_p "$file"; then
++	  func_ltwrapper_scriptname "$file"
++	  func_source "$func_ltwrapper_scriptname_result"
++	  # Transform arg to wrapped name.
++	  file="$progdir/$program"
++	fi
++	;;
++      esac
++      # Quote arguments (to preserve shell metacharacters).
++      func_quote_for_eval "$file"
++      args="$args $func_quote_for_eval_result"
++    done
++
++    if test "X$opt_dry_run" = Xfalse; then
++      if test -n "$shlibpath_var"; then
++	# Export the shlibpath_var.
++	eval "export $shlibpath_var"
++      fi
++
++      # Restore saved environment variables
++      for lt_var in LANG LANGUAGE LC_ALL LC_CTYPE LC_COLLATE LC_MESSAGES
++      do
++	eval "if test \"\${save_$lt_var+set}\" = set; then
++                $lt_var=\$save_$lt_var; export $lt_var
++	      else
++		$lt_unset $lt_var
++	      fi"
++      done
++
++      # Now prepare to actually exec the command.
++      exec_cmd="\$cmd$args"
++    else
++      # Display what would be done.
++      if test -n "$shlibpath_var"; then
++	eval "\$ECHO \"\$shlibpath_var=\$$shlibpath_var\""
++	$ECHO "export $shlibpath_var"
++      fi
++      $ECHO "$cmd$args"
++      exit $EXIT_SUCCESS
++    fi
++}
++
++test "$mode" = execute && func_mode_execute ${1+"$@"}
++
++
++# func_mode_finish arg...
++func_mode_finish ()
++{
++    $opt_debug
++    libdirs="$nonopt"
++    admincmds=
++
++    if test -n "$finish_cmds$finish_eval" && test -n "$libdirs"; then
++      for dir
++      do
++	libdirs="$libdirs $dir"
++      done
++
++      for libdir in $libdirs; do
++	if test -n "$finish_cmds"; then
++	  # Do each command in the finish commands.
++	  func_execute_cmds "$finish_cmds" 'admincmds="$admincmds
++'"$cmd"'"'
++	fi
++	if test -n "$finish_eval"; then
++	  # Do the single finish_eval.
++	  eval cmds=\"$finish_eval\"
++	  $opt_dry_run || eval "$cmds" || admincmds="$admincmds
++       $cmds"
++	fi
++      done
++    fi
++
++    # Exit here if they wanted silent mode.
++    $opt_silent && exit $EXIT_SUCCESS
++
++    $ECHO "X----------------------------------------------------------------------" | $Xsed
++    $ECHO "Libraries have been installed in:"
++    for libdir in $libdirs; do
++      $ECHO "   $libdir"
++    done
++    $ECHO
++    $ECHO "If you ever happen to want to link against installed libraries"
++    $ECHO "in a given directory, LIBDIR, you must either use libtool, and"
++    $ECHO "specify the full pathname of the library, or use the \`-LLIBDIR'"
++    $ECHO "flag during linking and do at least one of the following:"
++    if test -n "$shlibpath_var"; then
++      $ECHO "   - add LIBDIR to the \`$shlibpath_var' environment variable"
++      $ECHO "     during execution"
++    fi
++    if test -n "$runpath_var"; then
++      $ECHO "   - add LIBDIR to the \`$runpath_var' environment variable"
++      $ECHO "     during linking"
++    fi
++    if test -n "$hardcode_libdir_flag_spec"; then
++      libdir=LIBDIR
++      eval flag=\"$hardcode_libdir_flag_spec\"
++
++      $ECHO "   - use the \`$flag' linker flag"
++    fi
++    if test -n "$admincmds"; then
++      $ECHO "   - have your system administrator run these commands:$admincmds"
++    fi
++    if test -f /etc/ld.so.conf; then
++      $ECHO "   - have your system administrator add LIBDIR to \`/etc/ld.so.conf'"
++    fi
++    $ECHO
++
++    $ECHO "See any operating system documentation about shared libraries for"
++    case $host in
++      solaris2.[6789]|solaris2.1[0-9])
++        $ECHO "more information, such as the ld(1), crle(1) and ld.so(8) manual"
++	$ECHO "pages."
++	;;
++      *)
++        $ECHO "more information, such as the ld(1) and ld.so(8) manual pages."
++        ;;
++    esac
++    $ECHO "X----------------------------------------------------------------------" | $Xsed
++    exit $EXIT_SUCCESS
++}
++
++test "$mode" = finish && func_mode_finish ${1+"$@"}
++
++
++# func_mode_install arg...
++func_mode_install ()
++{
++    $opt_debug
++    # There may be an optional sh(1) argument at the beginning of
++    # install_prog (especially on Windows NT).
++    if test "$nonopt" = "$SHELL" || test "$nonopt" = /bin/sh ||
++       # Allow the use of GNU shtool's install command.
++       $ECHO "X$nonopt" | $GREP shtool >/dev/null; then
++      # Aesthetically quote it.
++      func_quote_for_eval "$nonopt"
++      install_prog="$func_quote_for_eval_result "
++      arg=$1
++      shift
++    else
++      install_prog=
++      arg=$nonopt
++    fi
++
++    # The real first argument should be the name of the installation program.
++    # Aesthetically quote it.
++    func_quote_for_eval "$arg"
++    install_prog="$install_prog$func_quote_for_eval_result"
++
++    # We need to accept at least all the BSD install flags.
++    dest=
++    files=
++    opts=
++    prev=
++    install_type=
++    isdir=no
++    stripme=
++    for arg
++    do
++      if test -n "$dest"; then
++	files="$files $dest"
++	dest=$arg
++	continue
++      fi
++
++      case $arg in
++      -d) isdir=yes ;;
++      -f)
++	case " $install_prog " in
++	*[\\\ /]cp\ *) ;;
++	*) prev=$arg ;;
++	esac
++	;;
++      -g | -m | -o)
++	prev=$arg
++	;;
++      -s)
++	stripme=" -s"
++	continue
++	;;
++      -*)
++	;;
++      *)
++	# If the previous option needed an argument, then skip it.
++	if test -n "$prev"; then
++	  prev=
++	else
++	  dest=$arg
++	  continue
++	fi
++	;;
++      esac
++
++      # Aesthetically quote the argument.
++      func_quote_for_eval "$arg"
++      install_prog="$install_prog $func_quote_for_eval_result"
++    done
++
++    test -z "$install_prog" && \
++      func_fatal_help "you must specify an install program"
++
++    test -n "$prev" && \
++      func_fatal_help "the \`$prev' option requires an argument"
++
++    if test -z "$files"; then
++      if test -z "$dest"; then
++	func_fatal_help "no file or destination specified"
++      else
++	func_fatal_help "you must specify a destination"
++      fi
++    fi
++
++    # Strip any trailing slash from the destination.
++    func_stripname '' '/' "$dest"
++    dest=$func_stripname_result
++
++    # Check to see that the destination is a directory.
++    test -d "$dest" && isdir=yes
++    if test "$isdir" = yes; then
++      destdir="$dest"
++      destname=
++    else
++      func_dirname_and_basename "$dest" "" "."
++      destdir="$func_dirname_result"
++      destname="$func_basename_result"
++
++      # Not a directory, so check to see that there is only one file specified.
++      set dummy $files; shift
++      test "$#" -gt 1 && \
++	func_fatal_help "\`$dest' is not a directory"
++    fi
++    case $destdir in
++    [\\/]* | [A-Za-z]:[\\/]*) ;;
++    *)
++      for file in $files; do
++	case $file in
++	*.lo) ;;
++	*)
++	  func_fatal_help "\`$destdir' must be an absolute directory name"
++	  ;;
++	esac
++      done
++      ;;
++    esac
++
++    # This variable tells wrapper scripts just to set variables rather
++    # than running their programs.
++    libtool_install_magic="$magic"
++
++    staticlibs=
++    future_libdirs=
++    current_libdirs=
++    for file in $files; do
++
++      # Do each installation.
++      case $file in
++      *.$libext)
++	# Do the static libraries later.
++	staticlibs="$staticlibs $file"
++	;;
++
++      *.la)
++	# Check to see that this really is a libtool archive.
++	func_lalib_unsafe_p "$file" \
++	  || func_fatal_help "\`$file' is not a valid libtool archive"
++
++	library_names=
++	old_library=
++	relink_command=
++	func_source "$file"
++
++	# Add the libdir to current_libdirs if it is the destination.
++	if test "X$destdir" = "X$libdir"; then
++	  case "$current_libdirs " in
++	  *" $libdir "*) ;;
++	  *) current_libdirs="$current_libdirs $libdir" ;;
++	  esac
++	else
++	  # Note the libdir as a future libdir.
++	  case "$future_libdirs " in
++	  *" $libdir "*) ;;
++	  *) future_libdirs="$future_libdirs $libdir" ;;
++	  esac
++	fi
++
++	func_dirname "$file" "/" ""
++	dir="$func_dirname_result"
++	dir="$dir$objdir"
++
++	if test -n "$relink_command"; then
++	  # Determine the prefix the user has applied to our future dir.
++	  inst_prefix_dir=`$ECHO "X$destdir" | $Xsed -e "s%$libdir\$%%"`
++
++	  # Don't allow the user to place us outside of our expected
++	  # location b/c this prevents finding dependent libraries that
++	  # are installed to the same prefix.
++	  # At present, this check doesn't affect windows .dll's that
++	  # are installed into $libdir/../bin (currently, that works fine)
++	  # but it's something to keep an eye on.
++	  test "$inst_prefix_dir" = "$destdir" && \
++	    func_fatal_error "error: cannot install \`$file' to a directory not ending in $libdir"
++
++	  if test -n "$inst_prefix_dir"; then
++	    # Stick the inst_prefix_dir data into the link command.
++	    relink_command=`$ECHO "X$relink_command" | $Xsed -e "s%@inst_prefix_dir@%-inst-prefix-dir $inst_prefix_dir%"`
++	  else
++	    relink_command=`$ECHO "X$relink_command" | $Xsed -e "s%@inst_prefix_dir@%%"`
++	  fi
++
++	  func_warning "relinking \`$file'"
++	  func_show_eval "$relink_command" \
++	    'func_fatal_error "error: relink \`$file'\'' with the above command before installing it"'
++	fi
++
++	# See the names of the shared library.
++	set dummy $library_names; shift
++	if test -n "$1"; then
++	  realname="$1"
++	  shift
++
++	  srcname="$realname"
++	  test -n "$relink_command" && srcname="$realname"T
++
++	  # Install the shared library and build the symlinks.
++	  func_show_eval "$install_prog $dir/$srcname $destdir/$realname" \
++	      'exit $?'
++	  tstripme="$stripme"
++	  case $host_os in
++	  cygwin* | mingw* | pw32* | cegcc*)
++	    case $realname in
++	    *.dll.a)
++	      tstripme=""
++	      ;;
++	    esac
++	    ;;
++	  esac
++	  if test -n "$tstripme" && test -n "$striplib"; then
++	    func_show_eval "$striplib $destdir/$realname" 'exit $?'
++	  fi
++
++	  if test "$#" -gt 0; then
++	    # Delete the old symlinks, and create new ones.
++	    # Try `ln -sf' first, because the `ln' binary might depend on
++	    # the symlink we replace!  Solaris /bin/ln does not understand -f,
++	    # so we also need to try rm && ln -s.
++	    for linkname
++	    do
++	      test "$linkname" != "$realname" \
++		&& func_show_eval "(cd $destdir && { $LN_S -f $realname $linkname || { $RM $linkname && $LN_S $realname $linkname; }; })"
++	    done
++	  fi
++
++	  # Do each command in the postinstall commands.
++	  lib="$destdir/$realname"
++	  func_execute_cmds "$postinstall_cmds" 'exit $?'
++	fi
++
++	# Install the pseudo-library for information purposes.
++	func_basename "$file"
++	name="$func_basename_result"
++	instname="$dir/$name"i
++	func_show_eval "$install_prog $instname $destdir/$name" 'exit $?'
++
++	# Maybe install the static library, too.
++	test -n "$old_library" && staticlibs="$staticlibs $dir/$old_library"
++	;;
++
++      *.lo)
++	# Install (i.e. copy) a libtool object.
++
++	# Figure out destination file name, if it wasn't already specified.
++	if test -n "$destname"; then
++	  destfile="$destdir/$destname"
++	else
++	  func_basename "$file"
++	  destfile="$func_basename_result"
++	  destfile="$destdir/$destfile"
++	fi
++
++	# Deduce the name of the destination old-style object file.
++	case $destfile in
++	*.lo)
++	  func_lo2o "$destfile"
++	  staticdest=$func_lo2o_result
++	  ;;
++	*.$objext)
++	  staticdest="$destfile"
++	  destfile=
++	  ;;
++	*)
++	  func_fatal_help "cannot copy a libtool object to \`$destfile'"
++	  ;;
++	esac
++
++	# Install the libtool object if requested.
++	test -n "$destfile" && \
++	  func_show_eval "$install_prog $file $destfile" 'exit $?'
++
++	# Install the old object if enabled.
++	if test "$build_old_libs" = yes; then
++	  # Deduce the name of the old-style object file.
++	  func_lo2o "$file"
++	  staticobj=$func_lo2o_result
++	  func_show_eval "$install_prog \$staticobj \$staticdest" 'exit $?'
++	fi
++	exit $EXIT_SUCCESS
++	;;
++
++      *)
++	# Figure out destination file name, if it wasn't already specified.
++	if test -n "$destname"; then
++	  destfile="$destdir/$destname"
++	else
++	  func_basename "$file"
++	  destfile="$func_basename_result"
++	  destfile="$destdir/$destfile"
++	fi
++
++	# If the file is missing, and there is a .exe on the end, strip it
++	# because it is most likely a libtool script we actually want to
++	# install
++	stripped_ext=""
++	case $file in
++	  *.exe)
++	    if test ! -f "$file"; then
++	      func_stripname '' '.exe' "$file"
++	      file=$func_stripname_result
++	      stripped_ext=".exe"
++	    fi
++	    ;;
++	esac
++
++	# Do a test to see if this is really a libtool program.
++	case $host in
++	*cygwin* | *mingw*)
++	    if func_ltwrapper_executable_p "$file"; then
++	      func_ltwrapper_scriptname "$file"
++	      wrapper=$func_ltwrapper_scriptname_result
++	    else
++	      func_stripname '' '.exe' "$file"
++	      wrapper=$func_stripname_result
++	    fi
++	    ;;
++	*)
++	    wrapper=$file
++	    ;;
++	esac
++	if func_ltwrapper_script_p "$wrapper"; then
++	  notinst_deplibs=
++	  relink_command=
++
++	  func_source "$wrapper"
++
++	  # Check the variables that should have been set.
++	  test -z "$generated_by_libtool_version" && \
++	    func_fatal_error "invalid libtool wrapper script \`$wrapper'"
++
++	  finalize=yes
++	  for lib in $notinst_deplibs; do
++	    # Check to see that each library is installed.
++	    libdir=
++	    if test -f "$lib"; then
++	      func_source "$lib"
++	    fi
++	    libfile="$libdir/"`$ECHO "X$lib" | $Xsed -e 's%^.*/%%g'` ### testsuite: skip nested quoting test
++	    if test -n "$libdir" && test ! -f "$libfile"; then
++	      func_warning "\`$lib' has not been installed in \`$libdir'"
++	      finalize=no
++	    fi
++	  done
++
++	  relink_command=
++	  func_source "$wrapper"
++
++	  outputname=
++	  if test "$fast_install" = no && test -n "$relink_command"; then
++	    $opt_dry_run || {
++	      if test "$finalize" = yes; then
++	        tmpdir=`func_mktempdir`
++		func_basename "$file$stripped_ext"
++		file="$func_basename_result"
++	        outputname="$tmpdir/$file"
++	        # Replace the output file specification.
++	        relink_command=`$ECHO "X$relink_command" | $Xsed -e 's%@OUTPUT@%'"$outputname"'%g'`
++
++	        $opt_silent || {
++	          func_quote_for_expand "$relink_command"
++		  eval "func_echo $func_quote_for_expand_result"
++	        }
++	        if eval "$relink_command"; then :
++	          else
++		  func_error "error: relink \`$file' with the above command before installing it"
++		  $opt_dry_run || ${RM}r "$tmpdir"
++		  continue
++	        fi
++	        file="$outputname"
++	      else
++	        func_warning "cannot relink \`$file'"
++	      fi
++	    }
++	  else
++	    # Install the binary that we compiled earlier.
++	    file=`$ECHO "X$file$stripped_ext" | $Xsed -e "s%\([^/]*\)$%$objdir/\1%"`
++	  fi
++	fi
++
++	# remove .exe since cygwin /usr/bin/install will append another
++	# one anyway
++	case $install_prog,$host in
++	*/usr/bin/install*,*cygwin*)
++	  case $file:$destfile in
++	  *.exe:*.exe)
++	    # this is ok
++	    ;;
++	  *.exe:*)
++	    destfile=$destfile.exe
++	    ;;
++	  *:*.exe)
++	    func_stripname '' '.exe' "$destfile"
++	    destfile=$func_stripname_result
++	    ;;
++	  esac
++	  ;;
++	esac
++	func_show_eval "$install_prog\$stripme \$file \$destfile" 'exit $?'
++	$opt_dry_run || if test -n "$outputname"; then
++	  ${RM}r "$tmpdir"
++	fi
++	;;
++      esac
++    done
++
++    for file in $staticlibs; do
++      func_basename "$file"
++      name="$func_basename_result"
++
++      # Set up the ranlib parameters.
++      oldlib="$destdir/$name"
++
++      func_show_eval "$install_prog \$file \$oldlib" 'exit $?'
++
++      if test -n "$stripme" && test -n "$old_striplib"; then
++	func_show_eval "$old_striplib $oldlib" 'exit $?'
++      fi
++
++      # Do each command in the postinstall commands.
++      func_execute_cmds "$old_postinstall_cmds" 'exit $?'
++    done
++
++    test -n "$future_libdirs" && \
++      func_warning "remember to run \`$progname --finish$future_libdirs'"
++
++    if test -n "$current_libdirs"; then
++      # Maybe just do a dry run.
++      $opt_dry_run && current_libdirs=" -n$current_libdirs"
++      exec_cmd='$SHELL $progpath $preserve_args --finish$current_libdirs'
++    else
++      exit $EXIT_SUCCESS
++    fi
++}
++
++test "$mode" = install && func_mode_install ${1+"$@"}
++
++
++# func_generate_dlsyms outputname originator pic_p
++# Extract symbols from dlprefiles and create ${outputname}S.o with
++# a dlpreopen symbol table.
++func_generate_dlsyms ()
++{
++    $opt_debug
++    my_outputname="$1"
++    my_originator="$2"
++    my_pic_p="${3-no}"
++    my_prefix=`$ECHO "$my_originator" | sed 's%[^a-zA-Z0-9]%_%g'`
++    my_dlsyms=
++
++    if test -n "$dlfiles$dlprefiles" || test "$dlself" != no; then
++      if test -n "$NM" && test -n "$global_symbol_pipe"; then
++	my_dlsyms="${my_outputname}S.c"
++      else
++	func_error "not configured to extract global symbols from dlpreopened files"
++      fi
++    fi
++
++    if test -n "$my_dlsyms"; then
++      case $my_dlsyms in
++      "") ;;
++      *.c)
++	# Discover the nlist of each of the dlfiles.
++	nlist="$output_objdir/${my_outputname}.nm"
++
++	func_show_eval "$RM $nlist ${nlist}S ${nlist}T"
++
++	# Parse the name list into a source file.
++	func_verbose "creating $output_objdir/$my_dlsyms"
++
++	$opt_dry_run || $ECHO > "$output_objdir/$my_dlsyms" "\
++/* $my_dlsyms - symbol resolution table for \`$my_outputname' dlsym emulation. */
++/* Generated by $PROGRAM (GNU $PACKAGE$TIMESTAMP) $VERSION */
++
++#ifdef __cplusplus
++extern \"C\" {
++#endif
++
++/* External symbol declarations for the compiler. */\
++"
++
++	if test "$dlself" = yes; then
++	  func_verbose "generating symbol list for \`$output'"
++
++	  $opt_dry_run || echo ': @PROGRAM@ ' > "$nlist"
++
++	  # Add our own program objects to the symbol list.
++	  progfiles=`$ECHO "X$objs$old_deplibs" | $SP2NL | $Xsed -e "$lo2o" | $NL2SP`
++	  for progfile in $progfiles; do
++	    func_verbose "extracting global C symbols from \`$progfile'"
++	    $opt_dry_run || eval "$NM $progfile | $global_symbol_pipe >> '$nlist'"
++	  done
++
++	  if test -n "$exclude_expsyms"; then
++	    $opt_dry_run || {
++	      eval '$EGREP -v " ($exclude_expsyms)$" "$nlist" > "$nlist"T'
++	      eval '$MV "$nlist"T "$nlist"'
++	    }
++	  fi
++
++	  if test -n "$export_symbols_regex"; then
++	    $opt_dry_run || {
++	      eval '$EGREP -e "$export_symbols_regex" "$nlist" > "$nlist"T'
++	      eval '$MV "$nlist"T "$nlist"'
++	    }
++	  fi
++
++	  # Prepare the list of exported symbols
++	  if test -z "$export_symbols"; then
++	    export_symbols="$output_objdir/$outputname.exp"
++	    $opt_dry_run || {
++	      $RM $export_symbols
++	      eval "${SED} -n -e '/^: @PROGRAM@ $/d' -e 's/^.* \(.*\)$/\1/p' "'< "$nlist" > "$export_symbols"'
++	      case $host in
++	      *cygwin* | *mingw* | *cegcc* )
++                eval "echo EXPORTS "'> "$output_objdir/$outputname.def"'
++                eval 'cat "$export_symbols" >> "$output_objdir/$outputname.def"'
++	        ;;
++	      esac
++	    }
++	  else
++	    $opt_dry_run || {
++	      eval "${SED} -e 's/\([].[*^$]\)/\\\\\1/g' -e 's/^/ /' -e 's/$/$/'"' < "$export_symbols" > "$output_objdir/$outputname.exp"'
++	      eval '$GREP -f "$output_objdir/$outputname.exp" < "$nlist" > "$nlist"T'
++	      eval '$MV "$nlist"T "$nlist"'
++	      case $host in
++	        *cygwin | *mingw* | *cegcc* )
++	          eval "echo EXPORTS "'> "$output_objdir/$outputname.def"'
++	          eval 'cat "$nlist" >> "$output_objdir/$outputname.def"'
++	          ;;
++	      esac
++	    }
++	  fi
++	fi
++
++	for dlprefile in $dlprefiles; do
++	  func_verbose "extracting global C symbols from \`$dlprefile'"
++	  func_basename "$dlprefile"
++	  name="$func_basename_result"
++	  $opt_dry_run || {
++	    eval '$ECHO ": $name " >> "$nlist"'
++	    eval "$NM $dlprefile 2>/dev/null | $global_symbol_pipe >> '$nlist'"
++	  }
++	done
++
++	$opt_dry_run || {
++	  # Make sure we have at least an empty file.
++	  test -f "$nlist" || : > "$nlist"
++
++	  if test -n "$exclude_expsyms"; then
++	    $EGREP -v " ($exclude_expsyms)$" "$nlist" > "$nlist"T
++	    $MV "$nlist"T "$nlist"
++	  fi
++
++	  # Try sorting and uniquifying the output.
++	  if $GREP -v "^: " < "$nlist" |
++	      if sort -k 3 </dev/null >/dev/null 2>&1; then
++		sort -k 3
++	      else
++		sort +2
++	      fi |
++	      uniq > "$nlist"S; then
++	    :
++	  else
++	    $GREP -v "^: " < "$nlist" > "$nlist"S
++	  fi
++
++	  if test -f "$nlist"S; then
++	    eval "$global_symbol_to_cdecl"' < "$nlist"S >> "$output_objdir/$my_dlsyms"'
++	  else
++	    $ECHO '/* NONE */' >> "$output_objdir/$my_dlsyms"
++	  fi
++
++	  $ECHO >> "$output_objdir/$my_dlsyms" "\
++
++/* The mapping between symbol names and symbols.  */
++typedef struct {
++  const char *name;
++  void *address;
++} lt_dlsymlist;
++"
++	  case $host in
++	  *cygwin* | *mingw* | *cegcc* )
++	    $ECHO >> "$output_objdir/$my_dlsyms" "\
++/* DATA imports from DLLs on WIN32 con't be const, because
++   runtime relocations are performed -- see ld's documentation
++   on pseudo-relocs.  */"
++	    lt_dlsym_const= ;;
++	  *osf5*)
++	    echo >> "$output_objdir/$my_dlsyms" "\
++/* This system does not cope well with relocations in const data */"
++	    lt_dlsym_const= ;;
++	  *)
++	    lt_dlsym_const=const ;;
++	  esac
++
++	  $ECHO >> "$output_objdir/$my_dlsyms" "\
++extern $lt_dlsym_const lt_dlsymlist
++lt_${my_prefix}_LTX_preloaded_symbols[];
++$lt_dlsym_const lt_dlsymlist
++lt_${my_prefix}_LTX_preloaded_symbols[] =
++{\
++  { \"$my_originator\", (void *) 0 },"
++
++	  case $need_lib_prefix in
++	  no)
++	    eval "$global_symbol_to_c_name_address" < "$nlist" >> "$output_objdir/$my_dlsyms"
++	    ;;
++	  *)
++	    eval "$global_symbol_to_c_name_address_lib_prefix" < "$nlist" >> "$output_objdir/$my_dlsyms"
++	    ;;
++	  esac
++	  $ECHO >> "$output_objdir/$my_dlsyms" "\
++  {0, (void *) 0}
++};
++
++/* This works around a problem in FreeBSD linker */
++#ifdef FREEBSD_WORKAROUND
++static const void *lt_preloaded_setup() {
++  return lt_${my_prefix}_LTX_preloaded_symbols;
++}
++#endif
++
++#ifdef __cplusplus
++}
++#endif\
++"
++	} # !$opt_dry_run
++
++	pic_flag_for_symtable=
++	case "$compile_command " in
++	*" -static "*) ;;
++	*)
++	  case $host in
++	  # compiling the symbol table file with pic_flag works around
++	  # a FreeBSD bug that causes programs to crash when -lm is
++	  # linked before any other PIC object.  But we must not use
++	  # pic_flag when linking with -static.  The problem exists in
++	  # FreeBSD 2.2.6 and is fixed in FreeBSD 3.1.
++	  *-*-freebsd2*|*-*-freebsd3.0*|*-*-freebsdelf3.0*)
++	    pic_flag_for_symtable=" $pic_flag -DFREEBSD_WORKAROUND" ;;
++	  *-*-hpux*)
++	    pic_flag_for_symtable=" $pic_flag"  ;;
++	  *)
++	    if test "X$my_pic_p" != Xno; then
++	      pic_flag_for_symtable=" $pic_flag"
++	    fi
++	    ;;
++	  esac
++	  ;;
++	esac
++	symtab_cflags=
++	for arg in $LTCFLAGS; do
++	  case $arg in
++	  -pie | -fpie | -fPIE) ;;
++	  *) symtab_cflags="$symtab_cflags $arg" ;;
++	  esac
++	done
++
++	# Now compile the dynamic symbol file.
++	func_show_eval '(cd $output_objdir && $LTCC$symtab_cflags -c$no_builtin_flag$pic_flag_for_symtable "$my_dlsyms")' 'exit $?'
++
++	# Clean up the generated files.
++	func_show_eval '$RM "$output_objdir/$my_dlsyms" "$nlist" "${nlist}S" "${nlist}T"'
++
++	# Transform the symbol file into the correct name.
++	symfileobj="$output_objdir/${my_outputname}S.$objext"
++	case $host in
++	*cygwin* | *mingw* | *cegcc* )
++	  if test -f "$output_objdir/$my_outputname.def"; then
++	    compile_command=`$ECHO "X$compile_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/$my_outputname.def $symfileobj%"`
++	    finalize_command=`$ECHO "X$finalize_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/$my_outputname.def $symfileobj%"`
++	  else
++	    compile_command=`$ECHO "X$compile_command" | $Xsed -e "s%@SYMFILE@%$symfileobj%"`
++	    finalize_command=`$ECHO "X$finalize_command" | $Xsed -e "s%@SYMFILE@%$symfileobj%"`
++	  fi
++	  ;;
++	*)
++	  compile_command=`$ECHO "X$compile_command" | $Xsed -e "s%@SYMFILE@%$symfileobj%"`
++	  finalize_command=`$ECHO "X$finalize_command" | $Xsed -e "s%@SYMFILE@%$symfileobj%"`
++	  ;;
++	esac
++	;;
++      *)
++	func_fatal_error "unknown suffix for \`$my_dlsyms'"
++	;;
++      esac
++    else
++      # We keep going just in case the user didn't refer to
++      # lt_preloaded_symbols.  The linker will fail if global_symbol_pipe
++      # really was required.
++
++      # Nullify the symbol file.
++      compile_command=`$ECHO "X$compile_command" | $Xsed -e "s% @SYMFILE@%%"`
++      finalize_command=`$ECHO "X$finalize_command" | $Xsed -e "s% @SYMFILE@%%"`
++    fi
++}
++
++# func_win32_libid arg
++# return the library type of file 'arg'
++#
++# Need a lot of goo to handle *both* DLLs and import libs
++# Has to be a shell function in order to 'eat' the argument
++# that is supplied when $file_magic_command is called.
++func_win32_libid ()
++{
++  $opt_debug
++  win32_libid_type="unknown"
++  win32_fileres=`file -L $1 2>/dev/null`
++  case $win32_fileres in
++  *ar\ archive\ import\ library*) # definitely import
++    win32_libid_type="x86 archive import"
++    ;;
++  *ar\ archive*) # could be an import, or static
++    if eval $OBJDUMP -f $1 | $SED -e '10q' 2>/dev/null |
++       $EGREP 'file format pe-i386(.*architecture: i386)?' >/dev/null ; then
++      win32_nmres=`eval $NM -f posix -A $1 |
++	$SED -n -e '
++	    1,100{
++		/ I /{
++		    s,.*,import,
++		    p
++		    q
++		}
++	    }'`
++      case $win32_nmres in
++      import*)  win32_libid_type="x86 archive import";;
++      *)        win32_libid_type="x86 archive static";;
++      esac
++    fi
++    ;;
++  *DLL*)
++    win32_libid_type="x86 DLL"
++    ;;
++  *executable*) # but shell scripts are "executable" too...
++    case $win32_fileres in
++    *MS\ Windows\ PE\ Intel*)
++      win32_libid_type="x86 DLL"
++      ;;
++    esac
++    ;;
++  esac
++  $ECHO "$win32_libid_type"
++}
++
++
++
++# func_extract_an_archive dir oldlib
++func_extract_an_archive ()
++{
++    $opt_debug
++    f_ex_an_ar_dir="$1"; shift
++    f_ex_an_ar_oldlib="$1"
++    func_show_eval "(cd \$f_ex_an_ar_dir && $AR x \"\$f_ex_an_ar_oldlib\")" 'exit $?'
++    if ($AR t "$f_ex_an_ar_oldlib" | sort | sort -uc >/dev/null 2>&1); then
++     :
++    else
++      func_fatal_error "object name conflicts in archive: $f_ex_an_ar_dir/$f_ex_an_ar_oldlib"
++    fi
++}
++
++
++# func_extract_archives gentop oldlib ...
++func_extract_archives ()
++{
++    $opt_debug
++    my_gentop="$1"; shift
++    my_oldlibs=${1+"$@"}
++    my_oldobjs=""
++    my_xlib=""
++    my_xabs=""
++    my_xdir=""
++
++    for my_xlib in $my_oldlibs; do
++      # Extract the objects.
++      case $my_xlib in
++	[\\/]* | [A-Za-z]:[\\/]*) my_xabs="$my_xlib" ;;
++	*) my_xabs=`pwd`"/$my_xlib" ;;
++      esac
++      func_basename "$my_xlib"
++      my_xlib="$func_basename_result"
++      my_xlib_u=$my_xlib
++      while :; do
++        case " $extracted_archives " in
++	*" $my_xlib_u "*)
++	  func_arith $extracted_serial + 1
++	  extracted_serial=$func_arith_result
++	  my_xlib_u=lt$extracted_serial-$my_xlib ;;
++	*) break ;;
++	esac
++      done
++      extracted_archives="$extracted_archives $my_xlib_u"
++      my_xdir="$my_gentop/$my_xlib_u"
++
++      func_mkdir_p "$my_xdir"
++
++      case $host in
++      *-darwin*)
++	func_verbose "Extracting $my_xabs"
++	# Do not bother doing anything if just a dry run
++	$opt_dry_run || {
++	  darwin_orig_dir=`pwd`
++	  cd $my_xdir || exit $?
++	  darwin_archive=$my_xabs
++	  darwin_curdir=`pwd`
++	  darwin_base_archive=`basename "$darwin_archive"`
++	  darwin_arches=`$LIPO -info "$darwin_archive" 2>/dev/null | $GREP Architectures 2>/dev/null || true`
++	  if test -n "$darwin_arches"; then
++	    darwin_arches=`$ECHO "$darwin_arches" | $SED -e 's/.*are://'`
++	    darwin_arch=
++	    func_verbose "$darwin_base_archive has multiple architectures $darwin_arches"
++	    for darwin_arch in  $darwin_arches ; do
++	      func_mkdir_p "unfat-$$/${darwin_base_archive}-${darwin_arch}"
++	      $LIPO -thin $darwin_arch -output "unfat-$$/${darwin_base_archive}-${darwin_arch}/${darwin_base_archive}" "${darwin_archive}"
++	      cd "unfat-$$/${darwin_base_archive}-${darwin_arch}"
++	      func_extract_an_archive "`pwd`" "${darwin_base_archive}"
++	      cd "$darwin_curdir"
++	      $RM "unfat-$$/${darwin_base_archive}-${darwin_arch}/${darwin_base_archive}"
++	    done # $darwin_arches
++            ## Okay now we've a bunch of thin objects, gotta fatten them up :)
++	    darwin_filelist=`find unfat-$$ -type f -name \*.o -print -o -name \*.lo -print | $SED -e "$basename" | sort -u`
++	    darwin_file=
++	    darwin_files=
++	    for darwin_file in $darwin_filelist; do
++	      darwin_files=`find unfat-$$ -name $darwin_file -print | $NL2SP`
++	      $LIPO -create -output "$darwin_file" $darwin_files
++	    done # $darwin_filelist
++	    $RM -rf unfat-$$
++	    cd "$darwin_orig_dir"
++	  else
++	    cd $darwin_orig_dir
++	    func_extract_an_archive "$my_xdir" "$my_xabs"
++	  fi # $darwin_arches
++	} # !$opt_dry_run
++	;;
++      *)
++        func_extract_an_archive "$my_xdir" "$my_xabs"
++	;;
++      esac
++      my_oldobjs="$my_oldobjs "`find $my_xdir -name \*.$objext -print -o -name \*.lo -print | $NL2SP`
++    done
++
++    func_extract_archives_result="$my_oldobjs"
++}
++
++
++
++# func_emit_wrapper_part1 [arg=no]
++#
++# Emit the first part of a libtool wrapper script on stdout.
++# For more information, see the description associated with
++# func_emit_wrapper(), below.
++func_emit_wrapper_part1 ()
++{
++	func_emit_wrapper_part1_arg1=no
++	if test -n "$1" ; then
++	  func_emit_wrapper_part1_arg1=$1
++	fi
++
++	$ECHO "\
++#! $SHELL
++
++# $output - temporary wrapper script for $objdir/$outputname
++# Generated by $PROGRAM (GNU $PACKAGE$TIMESTAMP) $VERSION
++#
++# The $output program cannot be directly executed until all the libtool
++# libraries that it depends on are installed.
++#
++# This wrapper script should never be moved out of the build directory.
++# If it is, it will not operate correctly.
++
++# Sed substitution that helps us do robust quoting.  It backslashifies
++# metacharacters that are still active within double-quoted strings.
++Xsed='${SED} -e 1s/^X//'
++sed_quote_subst='$sed_quote_subst'
++
++# Be Bourne compatible
++if test -n \"\${ZSH_VERSION+set}\" && (emulate sh) >/dev/null 2>&1; then
++  emulate sh
++  NULLCMD=:
++  # Zsh 3.x and 4.x performs word splitting on \${1+\"\$@\"}, which
++  # is contrary to our usage.  Disable this feature.
++  alias -g '\${1+\"\$@\"}'='\"\$@\"'
++  setopt NO_GLOB_SUBST
++else
++  case \`(set -o) 2>/dev/null\` in *posix*) set -o posix;; esac
++fi
++BIN_SH=xpg4; export BIN_SH # for Tru64
++DUALCASE=1; export DUALCASE # for MKS sh
++
++# The HP-UX ksh and POSIX shell print the target directory to stdout
++# if CDPATH is set.
++(unset CDPATH) >/dev/null 2>&1 && unset CDPATH
++
++relink_command=\"$relink_command\"
++
++# This environment variable determines our operation mode.
++if test \"\$libtool_install_magic\" = \"$magic\"; then
++  # install mode needs the following variables:
++  generated_by_libtool_version='$macro_version'
++  notinst_deplibs='$notinst_deplibs'
++else
++  # When we are sourced in execute mode, \$file and \$ECHO are already set.
++  if test \"\$libtool_execute_magic\" != \"$magic\"; then
++    ECHO=\"$qecho\"
++    file=\"\$0\"
++    # Make sure echo works.
++    if test \"X\$1\" = X--no-reexec; then
++      # Discard the --no-reexec flag, and continue.
++      shift
++    elif test \"X\`{ \$ECHO '\t'; } 2>/dev/null\`\" = 'X\t'; then
++      # Yippee, \$ECHO works!
++      :
++    else
++      # Restart under the correct shell, and then maybe \$ECHO will work.
++      exec $SHELL \"\$0\" --no-reexec \${1+\"\$@\"}
++    fi
++  fi\
++"
++	$ECHO "\
++
++  # Find the directory that this script lives in.
++  thisdir=\`\$ECHO \"X\$file\" | \$Xsed -e 's%/[^/]*$%%'\`
++  test \"x\$thisdir\" = \"x\$file\" && thisdir=.
++
++  # Follow symbolic links until we get to the real thisdir.
++  file=\`ls -ld \"\$file\" | ${SED} -n 's/.*-> //p'\`
++  while test -n \"\$file\"; do
++    destdir=\`\$ECHO \"X\$file\" | \$Xsed -e 's%/[^/]*\$%%'\`
++
++    # If there was a directory component, then change thisdir.
++    if test \"x\$destdir\" != \"x\$file\"; then
++      case \"\$destdir\" in
++      [\\\\/]* | [A-Za-z]:[\\\\/]*) thisdir=\"\$destdir\" ;;
++      *) thisdir=\"\$thisdir/\$destdir\" ;;
++      esac
++    fi
++
++    file=\`\$ECHO \"X\$file\" | \$Xsed -e 's%^.*/%%'\`
++    file=\`ls -ld \"\$thisdir/\$file\" | ${SED} -n 's/.*-> //p'\`
++  done
++"
++}
++# end: func_emit_wrapper_part1
++
++# func_emit_wrapper_part2 [arg=no]
++#
++# Emit the second part of a libtool wrapper script on stdout.
++# For more information, see the description associated with
++# func_emit_wrapper(), below.
++func_emit_wrapper_part2 ()
++{
++	func_emit_wrapper_part2_arg1=no
++	if test -n "$1" ; then
++	  func_emit_wrapper_part2_arg1=$1
++	fi
++
++	$ECHO "\
++
++  # Usually 'no', except on cygwin/mingw when embedded into
++  # the cwrapper.
++  WRAPPER_SCRIPT_BELONGS_IN_OBJDIR=$func_emit_wrapper_part2_arg1
++  if test \"\$WRAPPER_SCRIPT_BELONGS_IN_OBJDIR\" = \"yes\"; then
++    # special case for '.'
++    if test \"\$thisdir\" = \".\"; then
++      thisdir=\`pwd\`
++    fi
++    # remove .libs from thisdir
++    case \"\$thisdir\" in
++    *[\\\\/]$objdir ) thisdir=\`\$ECHO \"X\$thisdir\" | \$Xsed -e 's%[\\\\/][^\\\\/]*$%%'\` ;;
++    $objdir )   thisdir=. ;;
++    esac
++  fi
++
++  # Try to get the absolute directory name.
++  absdir=\`cd \"\$thisdir\" && pwd\`
++  test -n \"\$absdir\" && thisdir=\"\$absdir\"
++"
++
++	if test "$fast_install" = yes; then
++	  $ECHO "\
++  program=lt-'$outputname'$exeext
++  progdir=\"\$thisdir/$objdir\"
++
++  if test ! -f \"\$progdir/\$program\" ||
++     { file=\`ls -1dt \"\$progdir/\$program\" \"\$progdir/../\$program\" 2>/dev/null | ${SED} 1q\`; \\
++       test \"X\$file\" != \"X\$progdir/\$program\"; }; then
++
++    file=\"\$\$-\$program\"
++
++    if test ! -d \"\$progdir\"; then
++      $MKDIR \"\$progdir\"
++    else
++      $RM \"\$progdir/\$file\"
++    fi"
++
++	  $ECHO "\
++
++    # relink executable if necessary
++    if test -n \"\$relink_command\"; then
++      if relink_command_output=\`eval \$relink_command 2>&1\`; then :
++      else
++	$ECHO \"\$relink_command_output\" >&2
++	$RM \"\$progdir/\$file\"
++	exit 1
++      fi
++    fi
++
++    $MV \"\$progdir/\$file\" \"\$progdir/\$program\" 2>/dev/null ||
++    { $RM \"\$progdir/\$program\";
++      $MV \"\$progdir/\$file\" \"\$progdir/\$program\"; }
++    $RM \"\$progdir/\$file\"
++  fi"
++	else
++	  $ECHO "\
++  program='$outputname'
++  progdir=\"\$thisdir/$objdir\"
++"
++	fi
++
++	$ECHO "\
++
++  if test -f \"\$progdir/\$program\"; then"
++
++	# Export our shlibpath_var if we have one.
++	if test "$shlibpath_overrides_runpath" = yes && test -n "$shlibpath_var" && test -n "$temp_rpath"; then
++	  $ECHO "\
++    # Add our own library path to $shlibpath_var
++    $shlibpath_var=\"$temp_rpath\$$shlibpath_var\"
++
++    # Some systems cannot cope with colon-terminated $shlibpath_var
++    # The second colon is a workaround for a bug in BeOS R4 sed
++    $shlibpath_var=\`\$ECHO \"X\$$shlibpath_var\" | \$Xsed -e 's/::*\$//'\`
++
++    export $shlibpath_var
++"
++	fi
++
++	# fixup the dll searchpath if we need to.
++	if test -n "$dllsearchpath"; then
++	  $ECHO "\
++    # Add the dll search path components to the executable PATH
++    PATH=$dllsearchpath:\$PATH
++"
++	fi
++
++	$ECHO "\
++    if test \"\$libtool_execute_magic\" != \"$magic\"; then
++      # Run the actual program with our arguments.
++"
++	case $host in
++	# Backslashes separate directories on plain windows
++	*-*-mingw | *-*-os2* | *-cegcc*)
++	  $ECHO "\
++      exec \"\$progdir\\\\\$program\" \${1+\"\$@\"}
++"
++	  ;;
++
++	*)
++	  $ECHO "\
++      exec \"\$progdir/\$program\" \${1+\"\$@\"}
++"
++	  ;;
++	esac
++	$ECHO "\
++      \$ECHO \"\$0: cannot exec \$program \$*\" 1>&2
++      exit 1
++    fi
++  else
++    # The program doesn't exist.
++    \$ECHO \"\$0: error: \\\`\$progdir/\$program' does not exist\" 1>&2
++    \$ECHO \"This script is just a wrapper for \$program.\" 1>&2
++    $ECHO \"See the $PACKAGE documentation for more information.\" 1>&2
++    exit 1
++  fi
++fi\
++"
++}
++# end: func_emit_wrapper_part2
++
++
++# func_emit_wrapper [arg=no]
++#
++# Emit a libtool wrapper script on stdout.
++# Don't directly open a file because we may want to
++# incorporate the script contents within a cygwin/mingw
++# wrapper executable.  Must ONLY be called from within
++# func_mode_link because it depends on a number of variables
++# set therein.
++#
++# ARG is the value that the WRAPPER_SCRIPT_BELONGS_IN_OBJDIR
++# variable will take.  If 'yes', then the emitted script
++# will assume that the directory in which it is stored is
++# the $objdir directory.  This is a cygwin/mingw-specific
++# behavior.
++func_emit_wrapper ()
++{
++	func_emit_wrapper_arg1=no
++	if test -n "$1" ; then
++	  func_emit_wrapper_arg1=$1
++	fi
++
++	# split this up so that func_emit_cwrapperexe_src
++	# can call each part independently.
++	func_emit_wrapper_part1 "${func_emit_wrapper_arg1}"
++	func_emit_wrapper_part2 "${func_emit_wrapper_arg1}"
++}
++
++
++# func_to_host_path arg
++#
++# Convert paths to host format when used with build tools.
++# Intended for use with "native" mingw (where libtool itself
++# is running under the msys shell), or in the following cross-
++# build environments:
++#    $build          $host
++#    mingw (msys)    mingw  [e.g. native]
++#    cygwin          mingw
++#    *nix + wine     mingw
++# where wine is equipped with the `winepath' executable.
++# In the native mingw case, the (msys) shell automatically
++# converts paths for any non-msys applications it launches,
++# but that facility isn't available from inside the cwrapper.
++# Similar accommodations are necessary for $host mingw and
++# $build cygwin.  Calling this function does no harm for other
++# $host/$build combinations not listed above.
++#
++# ARG is the path (on $build) that should be converted to
++# the proper representation for $host. The result is stored
++# in $func_to_host_path_result.
++func_to_host_path ()
++{
++  func_to_host_path_result="$1"
++  if test -n "$1" ; then
++    case $host in
++      *mingw* )
++        lt_sed_naive_backslashify='s|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g'
++        case $build in
++          *mingw* ) # actually, msys
++            # awkward: cmd appends spaces to result
++            lt_sed_strip_trailing_spaces="s/[ ]*\$//"
++            func_to_host_path_tmp1=`( cmd //c echo "$1" |\
++              $SED -e "$lt_sed_strip_trailing_spaces" ) 2>/dev/null || echo ""`
++            func_to_host_path_result=`echo "$func_to_host_path_tmp1" |\
++              $SED -e "$lt_sed_naive_backslashify"`
++            ;;
++          *cygwin* )
++            func_to_host_path_tmp1=`cygpath -w "$1"`
++            func_to_host_path_result=`echo "$func_to_host_path_tmp1" |\
++              $SED -e "$lt_sed_naive_backslashify"`
++            ;;
++          * )
++            # Unfortunately, winepath does not exit with a non-zero
++            # error code, so we are forced to check the contents of
++            # stdout. On the other hand, if the command is not
++            # found, the shell will set an exit code of 127 and print
++            # *an error message* to stdout. So we must check for both
++            # error code of zero AND non-empty stdout, which explains
++            # the odd construction:
++            func_to_host_path_tmp1=`winepath -w "$1" 2>/dev/null`
++            if test "$?" -eq 0 && test -n "${func_to_host_path_tmp1}"; then
++              func_to_host_path_result=`echo "$func_to_host_path_tmp1" |\
++                $SED -e "$lt_sed_naive_backslashify"`
++            else
++              # Allow warning below.
++              func_to_host_path_result=""
++            fi
++            ;;
++        esac
++        if test -z "$func_to_host_path_result" ; then
++          func_error "Could not determine host path corresponding to"
++          func_error "  '$1'"
++          func_error "Continuing, but uninstalled executables may not work."
++          # Fallback:
++          func_to_host_path_result="$1"
++        fi
++        ;;
++    esac
++  fi
++}
++# end: func_to_host_path
++
++# func_to_host_pathlist arg
++#
++# Convert pathlists to host format when used with build tools.
++# See func_to_host_path(), above. This function supports the
++# following $build/$host combinations (but does no harm for
++# combinations not listed here):
++#    $build          $host
++#    mingw (msys)    mingw  [e.g. native]
++#    cygwin          mingw
++#    *nix + wine     mingw
++#
++# Path separators are also converted from $build format to
++# $host format. If ARG begins or ends with a path separator
++# character, it is preserved (but converted to $host format)
++# on output.
++#
++# ARG is a pathlist (on $build) that should be converted to
++# the proper representation on $host. The result is stored
++# in $func_to_host_pathlist_result.
++func_to_host_pathlist ()
++{
++  func_to_host_pathlist_result="$1"
++  if test -n "$1" ; then
++    case $host in
++      *mingw* )
++        lt_sed_naive_backslashify='s|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g'
++        # Remove leading and trailing path separator characters from
++        # ARG. msys behavior is inconsistent here, cygpath turns them
++        # into '.;' and ';.', and winepath ignores them completely.
++        func_to_host_pathlist_tmp2="$1"
++        # Once set for this call, this variable should not be
++        # reassigned. It is used in tha fallback case.
++        func_to_host_pathlist_tmp1=`echo "$func_to_host_pathlist_tmp2" |\
++          $SED -e 's|^:*||' -e 's|:*$||'`
++        case $build in
++          *mingw* ) # Actually, msys.
++            # Awkward: cmd appends spaces to result.
++            lt_sed_strip_trailing_spaces="s/[ ]*\$//"
++            func_to_host_pathlist_tmp2=`( cmd //c echo "$func_to_host_pathlist_tmp1" |\
++              $SED -e "$lt_sed_strip_trailing_spaces" ) 2>/dev/null || echo ""`
++            func_to_host_pathlist_result=`echo "$func_to_host_pathlist_tmp2" |\
++              $SED -e "$lt_sed_naive_backslashify"`
++            ;;
++          *cygwin* )
++            func_to_host_pathlist_tmp2=`cygpath -w -p "$func_to_host_pathlist_tmp1"`
++            func_to_host_pathlist_result=`echo "$func_to_host_pathlist_tmp2" |\
++              $SED -e "$lt_sed_naive_backslashify"`
++            ;;
++          * )
++            # unfortunately, winepath doesn't convert pathlists
++            func_to_host_pathlist_result=""
++            func_to_host_pathlist_oldIFS=$IFS
++            IFS=:
++            for func_to_host_pathlist_f in $func_to_host_pathlist_tmp1 ; do
++              IFS=$func_to_host_pathlist_oldIFS
++              if test -n "$func_to_host_pathlist_f" ; then
++                func_to_host_path "$func_to_host_pathlist_f"
++                if test -n "$func_to_host_path_result" ; then
++                  if test -z "$func_to_host_pathlist_result" ; then
++                    func_to_host_pathlist_result="$func_to_host_path_result"
++                  else
++                    func_to_host_pathlist_result="$func_to_host_pathlist_result;$func_to_host_path_result"
++                  fi
++                fi
++              fi
++              IFS=:
++            done
++            IFS=$func_to_host_pathlist_oldIFS
++            ;;
++        esac
++        if test -z "$func_to_host_pathlist_result" ; then
++          func_error "Could not determine the host path(s) corresponding to"
++          func_error "  '$1'"
++          func_error "Continuing, but uninstalled executables may not work."
++          # Fallback. This may break if $1 contains DOS-style drive
++          # specifications. The fix is not to complicate the expression
++          # below, but for the user to provide a working wine installation
++          # with winepath so that path translation in the cross-to-mingw
++          # case works properly.
++          lt_replace_pathsep_nix_to_dos="s|:|;|g"
++          func_to_host_pathlist_result=`echo "$func_to_host_pathlist_tmp1" |\
++            $SED -e "$lt_replace_pathsep_nix_to_dos"`
++        fi
++        # Now, add the leading and trailing path separators back
++        case "$1" in
++          :* ) func_to_host_pathlist_result=";$func_to_host_pathlist_result"
++            ;;
++        esac
++        case "$1" in
++          *: ) func_to_host_pathlist_result="$func_to_host_pathlist_result;"
++            ;;
++        esac
++        ;;
++    esac
++  fi
++}
++# end: func_to_host_pathlist
++
++# func_emit_cwrapperexe_src
++# emit the source code for a wrapper executable on stdout
++# Must ONLY be called from within func_mode_link because
++# it depends on a number of variable set therein.
++func_emit_cwrapperexe_src ()
++{
++	cat <<EOF
++
++/* $cwrappersource - temporary wrapper executable for $objdir/$outputname
++   Generated by $PROGRAM (GNU $PACKAGE$TIMESTAMP) $VERSION
++
++   The $output program cannot be directly executed until all the libtool
++   libraries that it depends on are installed.
++
++   This wrapper executable should never be moved out of the build directory.
++   If it is, it will not operate correctly.
++
++   Currently, it simply execs the wrapper *script* "$SHELL $output",
++   but could eventually absorb all of the scripts functionality and
++   exec $objdir/$outputname directly.
++*/
++EOF
++	    cat <<"EOF"
++#include <stdio.h>
++#include <stdlib.h>
++#ifdef _MSC_VER
++# include <direct.h>
++# include <process.h>
++# include <io.h>
++# define setmode _setmode
++#else
++# include <unistd.h>
++# include <stdint.h>
++# ifdef __CYGWIN__
++#  include <io.h>
++#  define HAVE_SETENV
++#  ifdef __STRICT_ANSI__
++char *realpath (const char *, char *);
++int putenv (char *);
++int setenv (const char *, const char *, int);
++#  endif
++# endif
++#endif
++#include <malloc.h>
++#include <stdarg.h>
++#include <assert.h>
++#include <string.h>
++#include <ctype.h>
++#include <errno.h>
++#include <fcntl.h>
++#include <sys/stat.h>
++
++#if defined(PATH_MAX)
++# define LT_PATHMAX PATH_MAX
++#elif defined(MAXPATHLEN)
++# define LT_PATHMAX MAXPATHLEN
++#else
++# define LT_PATHMAX 1024
++#endif
++
++#ifndef S_IXOTH
++# define S_IXOTH 0
++#endif
++#ifndef S_IXGRP
++# define S_IXGRP 0
++#endif
++
++#ifdef _MSC_VER
++# define S_IXUSR _S_IEXEC
++# define stat _stat
++# ifndef _INTPTR_T_DEFINED
++#  define intptr_t int
++# endif
++#endif
++
++#ifndef DIR_SEPARATOR
++# define DIR_SEPARATOR '/'
++# define PATH_SEPARATOR ':'
++#endif
++
++#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
++  defined (__OS2__)
++# define HAVE_DOS_BASED_FILE_SYSTEM
++# define FOPEN_WB "wb"
++# ifndef DIR_SEPARATOR_2
++#  define DIR_SEPARATOR_2 '\\'
++# endif
++# ifndef PATH_SEPARATOR_2
++#  define PATH_SEPARATOR_2 ';'
++# endif
++#endif
++
++#ifndef DIR_SEPARATOR_2
++# define IS_DIR_SEPARATOR(ch) ((ch) == DIR_SEPARATOR)
++#else /* DIR_SEPARATOR_2 */
++# define IS_DIR_SEPARATOR(ch) \
++	(((ch) == DIR_SEPARATOR) || ((ch) == DIR_SEPARATOR_2))
++#endif /* DIR_SEPARATOR_2 */
++
++#ifndef PATH_SEPARATOR_2
++# define IS_PATH_SEPARATOR(ch) ((ch) == PATH_SEPARATOR)
++#else /* PATH_SEPARATOR_2 */
++# define IS_PATH_SEPARATOR(ch) ((ch) == PATH_SEPARATOR_2)
++#endif /* PATH_SEPARATOR_2 */
++
++#ifdef __CYGWIN__
++# define FOPEN_WB "wb"
++#endif
++
++#ifndef FOPEN_WB
++# define FOPEN_WB "w"
++#endif
++#ifndef _O_BINARY
++# define _O_BINARY 0
++#endif
++
++#define XMALLOC(type, num)      ((type *) xmalloc ((num) * sizeof(type)))
++#define XFREE(stale) do { \
++  if (stale) { free ((void *) stale); stale = 0; } \
++} while (0)
++
++#undef LTWRAPPER_DEBUGPRINTF
++#if defined DEBUGWRAPPER
++# define LTWRAPPER_DEBUGPRINTF(args) ltwrapper_debugprintf args
++static void
++ltwrapper_debugprintf (const char *fmt, ...)
++{
++    va_list args;
++    va_start (args, fmt);
++    (void) vfprintf (stderr, fmt, args);
++    va_end (args);
++}
++#else
++# define LTWRAPPER_DEBUGPRINTF(args)
++#endif
++
++const char *program_name = NULL;
++
++void *xmalloc (size_t num);
++char *xstrdup (const char *string);
++const char *base_name (const char *name);
++char *find_executable (const char *wrapper);
++char *chase_symlinks (const char *pathspec);
++int make_executable (const char *path);
++int check_executable (const char *path);
++char *strendzap (char *str, const char *pat);
++void lt_fatal (const char *message, ...);
++void lt_setenv (const char *name, const char *value);
++char *lt_extend_str (const char *orig_value, const char *add, int to_end);
++void lt_opt_process_env_set (const char *arg);
++void lt_opt_process_env_prepend (const char *arg);
++void lt_opt_process_env_append (const char *arg);
++int lt_split_name_value (const char *arg, char** name, char** value);
++void lt_update_exe_path (const char *name, const char *value);
++void lt_update_lib_path (const char *name, const char *value);
++
++static const char *script_text_part1 =
++EOF
++
++	    func_emit_wrapper_part1 yes |
++	        $SED -e 's/\([\\"]\)/\\\1/g' \
++	             -e 's/^/  "/' -e 's/$/\\n"/'
++	    echo ";"
++	    cat <<EOF
++
++static const char *script_text_part2 =
++EOF
++	    func_emit_wrapper_part2 yes |
++	        $SED -e 's/\([\\"]\)/\\\1/g' \
++	             -e 's/^/  "/' -e 's/$/\\n"/'
++	    echo ";"
++
++	    cat <<EOF
++const char * MAGIC_EXE = "$magic_exe";
++const char * LIB_PATH_VARNAME = "$shlibpath_var";
++EOF
++
++	    if test "$shlibpath_overrides_runpath" = yes && test -n "$shlibpath_var" && test -n "$temp_rpath"; then
++              func_to_host_pathlist "$temp_rpath"
++	      cat <<EOF
++const char * LIB_PATH_VALUE   = "$func_to_host_pathlist_result";
++EOF
++	    else
++	      cat <<"EOF"
++const char * LIB_PATH_VALUE   = "";
++EOF
++	    fi
++
++	    if test -n "$dllsearchpath"; then
++              func_to_host_pathlist "$dllsearchpath:"
++	      cat <<EOF
++const char * EXE_PATH_VARNAME = "PATH";
++const char * EXE_PATH_VALUE   = "$func_to_host_pathlist_result";
++EOF
++	    else
++	      cat <<"EOF"
++const char * EXE_PATH_VARNAME = "";
++const char * EXE_PATH_VALUE   = "";
++EOF
++	    fi
++
++	    if test "$fast_install" = yes; then
++	      cat <<EOF
++const char * TARGET_PROGRAM_NAME = "lt-$outputname"; /* hopefully, no .exe */
++EOF
++	    else
++	      cat <<EOF
++const char * TARGET_PROGRAM_NAME = "$outputname"; /* hopefully, no .exe */
++EOF
++	    fi
++
++
++	    cat <<"EOF"
++
++#define LTWRAPPER_OPTION_PREFIX         "--lt-"
++#define LTWRAPPER_OPTION_PREFIX_LENGTH  5
++
++static const size_t opt_prefix_len         = LTWRAPPER_OPTION_PREFIX_LENGTH;
++static const char *ltwrapper_option_prefix = LTWRAPPER_OPTION_PREFIX;
++
++static const char *dumpscript_opt       = LTWRAPPER_OPTION_PREFIX "dump-script";
++
++static const size_t env_set_opt_len     = LTWRAPPER_OPTION_PREFIX_LENGTH + 7;
++static const char *env_set_opt          = LTWRAPPER_OPTION_PREFIX "env-set";
++  /* argument is putenv-style "foo=bar", value of foo is set to bar */
++
++static const size_t env_prepend_opt_len = LTWRAPPER_OPTION_PREFIX_LENGTH + 11;
++static const char *env_prepend_opt      = LTWRAPPER_OPTION_PREFIX "env-prepend";
++  /* argument is putenv-style "foo=bar", new value of foo is bar${foo} */
++
++static const size_t env_append_opt_len  = LTWRAPPER_OPTION_PREFIX_LENGTH + 10;
++static const char *env_append_opt       = LTWRAPPER_OPTION_PREFIX "env-append";
++  /* argument is putenv-style "foo=bar", new value of foo is ${foo}bar */
++
++int
++main (int argc, char *argv[])
++{
++  char **newargz;
++  int  newargc;
++  char *tmp_pathspec;
++  char *actual_cwrapper_path;
++  char *actual_cwrapper_name;
++  char *target_name;
++  char *lt_argv_zero;
++  intptr_t rval = 127;
++
++  int i;
++
++  program_name = (char *) xstrdup (base_name (argv[0]));
++  LTWRAPPER_DEBUGPRINTF (("(main) argv[0]      : %s\n", argv[0]));
++  LTWRAPPER_DEBUGPRINTF (("(main) program_name : %s\n", program_name));
++
++  /* very simple arg parsing; don't want to rely on getopt */
++  for (i = 1; i < argc; i++)
++    {
++      if (strcmp (argv[i], dumpscript_opt) == 0)
++	{
++EOF
++	    case "$host" in
++	      *mingw* | *cygwin* )
++		# make stdout use "unix" line endings
++		echo "          setmode(1,_O_BINARY);"
++		;;
++	      esac
++
++	    cat <<"EOF"
++	  printf ("%s", script_text_part1);
++	  printf ("%s", script_text_part2);
++	  return 0;
++	}
++    }
++
++  newargz = XMALLOC (char *, argc + 1);
++  tmp_pathspec = find_executable (argv[0]);
++  if (tmp_pathspec == NULL)
++    lt_fatal ("Couldn't find %s", argv[0]);
++  LTWRAPPER_DEBUGPRINTF (("(main) found exe (before symlink chase) at : %s\n",
++			  tmp_pathspec));
++
++  actual_cwrapper_path = chase_symlinks (tmp_pathspec);
++  LTWRAPPER_DEBUGPRINTF (("(main) found exe (after symlink chase) at : %s\n",
++			  actual_cwrapper_path));
++  XFREE (tmp_pathspec);
++
++  actual_cwrapper_name = xstrdup( base_name (actual_cwrapper_path));
++  strendzap (actual_cwrapper_path, actual_cwrapper_name);
++
++  /* wrapper name transforms */
++  strendzap (actual_cwrapper_name, ".exe");
++  tmp_pathspec = lt_extend_str (actual_cwrapper_name, ".exe", 1);
++  XFREE (actual_cwrapper_name);
++  actual_cwrapper_name = tmp_pathspec;
++  tmp_pathspec = 0;
++
++  /* target_name transforms -- use actual target program name; might have lt- prefix */
++  target_name = xstrdup (base_name (TARGET_PROGRAM_NAME));
++  strendzap (target_name, ".exe");
++  tmp_pathspec = lt_extend_str (target_name, ".exe", 1);
++  XFREE (target_name);
++  target_name = tmp_pathspec;
++  tmp_pathspec = 0;
++
++  LTWRAPPER_DEBUGPRINTF (("(main) libtool target name: %s\n",
++			  target_name));
++EOF
++
++	    cat <<EOF
++  newargz[0] =
++    XMALLOC (char, (strlen (actual_cwrapper_path) +
++		    strlen ("$objdir") + 1 + strlen (actual_cwrapper_name) + 1));
++  strcpy (newargz[0], actual_cwrapper_path);
++  strcat (newargz[0], "$objdir");
++  strcat (newargz[0], "/");
++EOF
++
++	    cat <<"EOF"
++  /* stop here, and copy so we don't have to do this twice */
++  tmp_pathspec = xstrdup (newargz[0]);
++
++  /* do NOT want the lt- prefix here, so use actual_cwrapper_name */
++  strcat (newargz[0], actual_cwrapper_name);
++
++  /* DO want the lt- prefix here if it exists, so use target_name */
++  lt_argv_zero = lt_extend_str (tmp_pathspec, target_name, 1);
++  XFREE (tmp_pathspec);
++  tmp_pathspec = NULL;
++EOF
++
++	    case $host_os in
++	      mingw*)
++	    cat <<"EOF"
++  {
++    char* p;
++    while ((p = strchr (newargz[0], '\\')) != NULL)
++      {
++	*p = '/';
++      }
++    while ((p = strchr (lt_argv_zero, '\\')) != NULL)
++      {
++	*p = '/';
++      }
++  }
++EOF
++	    ;;
++	    esac
++
++	    cat <<"EOF"
++  XFREE (target_name);
++  XFREE (actual_cwrapper_path);
++  XFREE (actual_cwrapper_name);
++
++  lt_setenv ("BIN_SH", "xpg4"); /* for Tru64 */
++  lt_setenv ("DUALCASE", "1");  /* for MSK sh */
++  lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE);
++  lt_update_exe_path (EXE_PATH_VARNAME, EXE_PATH_VALUE);
++
++  newargc=0;
++  for (i = 1; i < argc; i++)
++    {
++      if (strncmp (argv[i], env_set_opt, env_set_opt_len) == 0)
++        {
++          if (argv[i][env_set_opt_len] == '=')
++            {
++              const char *p = argv[i] + env_set_opt_len + 1;
++              lt_opt_process_env_set (p);
++            }
++          else if (argv[i][env_set_opt_len] == '\0' && i + 1 < argc)
++            {
++              lt_opt_process_env_set (argv[++i]); /* don't copy */
++            }
++          else
++            lt_fatal ("%s missing required argument", env_set_opt);
++          continue;
++        }
++      if (strncmp (argv[i], env_prepend_opt, env_prepend_opt_len) == 0)
++        {
++          if (argv[i][env_prepend_opt_len] == '=')
++            {
++              const char *p = argv[i] + env_prepend_opt_len + 1;
++              lt_opt_process_env_prepend (p);
++            }
++          else if (argv[i][env_prepend_opt_len] == '\0' && i + 1 < argc)
++            {
++              lt_opt_process_env_prepend (argv[++i]); /* don't copy */
++            }
++          else
++            lt_fatal ("%s missing required argument", env_prepend_opt);
++          continue;
++        }
++      if (strncmp (argv[i], env_append_opt, env_append_opt_len) == 0)
++        {
++          if (argv[i][env_append_opt_len] == '=')
++            {
++              const char *p = argv[i] + env_append_opt_len + 1;
++              lt_opt_process_env_append (p);
++            }
++          else if (argv[i][env_append_opt_len] == '\0' && i + 1 < argc)
++            {
++              lt_opt_process_env_append (argv[++i]); /* don't copy */
++            }
++          else
++            lt_fatal ("%s missing required argument", env_append_opt);
++          continue;
++        }
++      if (strncmp (argv[i], ltwrapper_option_prefix, opt_prefix_len) == 0)
++        {
++          /* however, if there is an option in the LTWRAPPER_OPTION_PREFIX
++             namespace, but it is not one of the ones we know about and
++             have already dealt with, above (inluding dump-script), then
++             report an error. Otherwise, targets might begin to believe
++             they are allowed to use options in the LTWRAPPER_OPTION_PREFIX
++             namespace. The first time any user complains about this, we'll
++             need to make LTWRAPPER_OPTION_PREFIX a configure-time option
++             or a configure.ac-settable value.
++           */
++          lt_fatal ("Unrecognized option in %s namespace: '%s'",
++                    ltwrapper_option_prefix, argv[i]);
++        }
++      /* otherwise ... */
++      newargz[++newargc] = xstrdup (argv[i]);
++    }
++  newargz[++newargc] = NULL;
++
++  LTWRAPPER_DEBUGPRINTF     (("(main) lt_argv_zero : %s\n", (lt_argv_zero ? lt_argv_zero : "<NULL>")));
++  for (i = 0; i < newargc; i++)
++    {
++      LTWRAPPER_DEBUGPRINTF (("(main) newargz[%d]   : %s\n", i, (newargz[i] ? newargz[i] : "<NULL>")));
++    }
++
++EOF
++
++	    case $host_os in
++	      mingw*)
++		cat <<"EOF"
++  /* execv doesn't actually work on mingw as expected on unix */
++  rval = _spawnv (_P_WAIT, lt_argv_zero, (const char * const *) newargz);
++  if (rval == -1)
++    {
++      /* failed to start process */
++      LTWRAPPER_DEBUGPRINTF (("(main) failed to launch target \"%s\": errno = %d\n", lt_argv_zero, errno));
++      return 127;
++    }
++  return rval;
++EOF
++		;;
++	      *)
++		cat <<"EOF"
++  execv (lt_argv_zero, newargz);
++  return rval; /* =127, but avoids unused variable warning */
++EOF
++		;;
++	    esac
++
++	    cat <<"EOF"
++}
++
++void *
++xmalloc (size_t num)
++{
++  void *p = (void *) malloc (num);
++  if (!p)
++    lt_fatal ("Memory exhausted");
++
++  return p;
++}
++
++char *
++xstrdup (const char *string)
++{
++  return string ? strcpy ((char *) xmalloc (strlen (string) + 1),
++			  string) : NULL;
++}
++
++const char *
++base_name (const char *name)
++{
++  const char *base;
++
++#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
++  /* Skip over the disk name in MSDOS pathnames. */
++  if (isalpha ((unsigned char) name[0]) && name[1] == ':')
++    name += 2;
++#endif
++
++  for (base = name; *name; name++)
++    if (IS_DIR_SEPARATOR (*name))
++      base = name + 1;
++  return base;
++}
++
++int
++check_executable (const char *path)
++{
++  struct stat st;
++
++  LTWRAPPER_DEBUGPRINTF (("(check_executable)  : %s\n",
++			  path ? (*path ? path : "EMPTY!") : "NULL!"));
++  if ((!path) || (!*path))
++    return 0;
++
++  if ((stat (path, &st) >= 0)
++      && (st.st_mode & (S_IXUSR | S_IXGRP | S_IXOTH)))
++    return 1;
++  else
++    return 0;
++}
++
++int
++make_executable (const char *path)
++{
++  int rval = 0;
++  struct stat st;
++
++  LTWRAPPER_DEBUGPRINTF (("(make_executable)   : %s\n",
++			  path ? (*path ? path : "EMPTY!") : "NULL!"));
++  if ((!path) || (!*path))
++    return 0;
++
++  if (stat (path, &st) >= 0)
++    {
++      rval = chmod (path, st.st_mode | S_IXOTH | S_IXGRP | S_IXUSR);
++    }
++  return rval;
++}
++
++/* Searches for the full path of the wrapper.  Returns
++   newly allocated full path name if found, NULL otherwise
++   Does not chase symlinks, even on platforms that support them.
++*/
++char *
++find_executable (const char *wrapper)
++{
++  int has_slash = 0;
++  const char *p;
++  const char *p_next;
++  /* static buffer for getcwd */
++  char tmp[LT_PATHMAX + 1];
++  int tmp_len;
++  char *concat_name;
++
++  LTWRAPPER_DEBUGPRINTF (("(find_executable)   : %s\n",
++			  wrapper ? (*wrapper ? wrapper : "EMPTY!") : "NULL!"));
++
++  if ((wrapper == NULL) || (*wrapper == '\0'))
++    return NULL;
++
++  /* Absolute path? */
++#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
++  if (isalpha ((unsigned char) wrapper[0]) && wrapper[1] == ':')
++    {
++      concat_name = xstrdup (wrapper);
++      if (check_executable (concat_name))
++	return concat_name;
++      XFREE (concat_name);
++    }
++  else
++    {
++#endif
++      if (IS_DIR_SEPARATOR (wrapper[0]))
++	{
++	  concat_name = xstrdup (wrapper);
++	  if (check_executable (concat_name))
++	    return concat_name;
++	  XFREE (concat_name);
++	}
++#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
++    }
++#endif
++
++  for (p = wrapper; *p; p++)
++    if (*p == '/')
++      {
++	has_slash = 1;
++	break;
++      }
++  if (!has_slash)
++    {
++      /* no slashes; search PATH */
++      const char *path = getenv ("PATH");
++      if (path != NULL)
++	{
++	  for (p = path; *p; p = p_next)
++	    {
++	      const char *q;
++	      size_t p_len;
++	      for (q = p; *q; q++)
++		if (IS_PATH_SEPARATOR (*q))
++		  break;
++	      p_len = q - p;
++	      p_next = (*q == '\0' ? q : q + 1);
++	      if (p_len == 0)
++		{
++		  /* empty path: current directory */
++		  if (getcwd (tmp, LT_PATHMAX) == NULL)
++		    lt_fatal ("getcwd failed");
++		  tmp_len = strlen (tmp);
++		  concat_name =
++		    XMALLOC (char, tmp_len + 1 + strlen (wrapper) + 1);
++		  memcpy (concat_name, tmp, tmp_len);
++		  concat_name[tmp_len] = '/';
++		  strcpy (concat_name + tmp_len + 1, wrapper);
++		}
++	      else
++		{
++		  concat_name =
++		    XMALLOC (char, p_len + 1 + strlen (wrapper) + 1);
++		  memcpy (concat_name, p, p_len);
++		  concat_name[p_len] = '/';
++		  strcpy (concat_name + p_len + 1, wrapper);
++		}
++	      if (check_executable (concat_name))
++		return concat_name;
++	      XFREE (concat_name);
++	    }
++	}
++      /* not found in PATH; assume curdir */
++    }
++  /* Relative path | not found in path: prepend cwd */
++  if (getcwd (tmp, LT_PATHMAX) == NULL)
++    lt_fatal ("getcwd failed");
++  tmp_len = strlen (tmp);
++  concat_name = XMALLOC (char, tmp_len + 1 + strlen (wrapper) + 1);
++  memcpy (concat_name, tmp, tmp_len);
++  concat_name[tmp_len] = '/';
++  strcpy (concat_name + tmp_len + 1, wrapper);
++
++  if (check_executable (concat_name))
++    return concat_name;
++  XFREE (concat_name);
++  return NULL;
++}
++
++char *
++chase_symlinks (const char *pathspec)
++{
++#ifndef S_ISLNK
++  return xstrdup (pathspec);
++#else
++  char buf[LT_PATHMAX];
++  struct stat s;
++  char *tmp_pathspec = xstrdup (pathspec);
++  char *p;
++  int has_symlinks = 0;
++  while (strlen (tmp_pathspec) && !has_symlinks)
++    {
++      LTWRAPPER_DEBUGPRINTF (("checking path component for symlinks: %s\n",
++			      tmp_pathspec));
++      if (lstat (tmp_pathspec, &s) == 0)
++	{
++	  if (S_ISLNK (s.st_mode) != 0)
++	    {
++	      has_symlinks = 1;
++	      break;
++	    }
++
++	  /* search backwards for last DIR_SEPARATOR */
++	  p = tmp_pathspec + strlen (tmp_pathspec) - 1;
++	  while ((p > tmp_pathspec) && (!IS_DIR_SEPARATOR (*p)))
++	    p--;
++	  if ((p == tmp_pathspec) && (!IS_DIR_SEPARATOR (*p)))
++	    {
++	      /* no more DIR_SEPARATORS left */
++	      break;
++	    }
++	  *p = '\0';
++	}
++      else
++	{
++	  char *errstr = strerror (errno);
++	  lt_fatal ("Error accessing file %s (%s)", tmp_pathspec, errstr);
++	}
++    }
++  XFREE (tmp_pathspec);
++
++  if (!has_symlinks)
++    {
++      return xstrdup (pathspec);
++    }
++
++  tmp_pathspec = realpath (pathspec, buf);
++  if (tmp_pathspec == 0)
++    {
++      lt_fatal ("Could not follow symlinks for %s", pathspec);
++    }
++  return xstrdup (tmp_pathspec);
++#endif
++}
++
++char *
++strendzap (char *str, const char *pat)
++{
++  size_t len, patlen;
++
++  assert (str != NULL);
++  assert (pat != NULL);
++
++  len = strlen (str);
++  patlen = strlen (pat);
++
++  if (patlen <= len)
++    {
++      str += len - patlen;
++      if (strcmp (str, pat) == 0)
++	*str = '\0';
++    }
++  return str;
++}
++
++static void
++lt_error_core (int exit_status, const char *mode,
++	       const char *message, va_list ap)
++{
++  fprintf (stderr, "%s: %s: ", program_name, mode);
++  vfprintf (stderr, message, ap);
++  fprintf (stderr, ".\n");
++
++  if (exit_status >= 0)
++    exit (exit_status);
++}
++
++void
++lt_fatal (const char *message, ...)
++{
++  va_list ap;
++  va_start (ap, message);
++  lt_error_core (EXIT_FAILURE, "FATAL", message, ap);
++  va_end (ap);
++}
++
++void
++lt_setenv (const char *name, const char *value)
++{
++  LTWRAPPER_DEBUGPRINTF (("(lt_setenv) setting '%s' to '%s'\n",
++                          (name ? name : "<NULL>"),
++                          (value ? value : "<NULL>")));
++  {
++#ifdef HAVE_SETENV
++    /* always make a copy, for consistency with !HAVE_SETENV */
++    char *str = xstrdup (value);
++    setenv (name, str, 1);
++#else
++    int len = strlen (name) + 1 + strlen (value) + 1;
++    char *str = XMALLOC (char, len);
++    sprintf (str, "%s=%s", name, value);
++    if (putenv (str) != EXIT_SUCCESS)
++      {
++        XFREE (str);
++      }
++#endif
++  }
++}
++
++char *
++lt_extend_str (const char *orig_value, const char *add, int to_end)
++{
++  char *new_value;
++  if (orig_value && *orig_value)
++    {
++      int orig_value_len = strlen (orig_value);
++      int add_len = strlen (add);
++      new_value = XMALLOC (char, add_len + orig_value_len + 1);
++      if (to_end)
++        {
++          strcpy (new_value, orig_value);
++          strcpy (new_value + orig_value_len, add);
++        }
++      else
++        {
++          strcpy (new_value, add);
++          strcpy (new_value + add_len, orig_value);
++        }
++    }
++  else
++    {
++      new_value = xstrdup (add);
++    }
++  return new_value;
++}
++
++int
++lt_split_name_value (const char *arg, char** name, char** value)
++{
++  const char *p;
++  int len;
++  if (!arg || !*arg)
++    return 1;
++
++  p = strchr (arg, (int)'=');
++
++  if (!p)
++    return 1;
++
++  *value = xstrdup (++p);
++
++  len = strlen (arg) - strlen (*value);
++  *name = XMALLOC (char, len);
++  strncpy (*name, arg, len-1);
++  (*name)[len - 1] = '\0';
++
++  return 0;
++}
++
++void
++lt_opt_process_env_set (const char *arg)
++{
++  char *name = NULL;
++  char *value = NULL;
++
++  if (lt_split_name_value (arg, &name, &value) != 0)
++    {
++      XFREE (name);
++      XFREE (value);
++      lt_fatal ("bad argument for %s: '%s'", env_set_opt, arg);
++    }
++
++  lt_setenv (name, value);
++  XFREE (name);
++  XFREE (value);
++}
++
++void
++lt_opt_process_env_prepend (const char *arg)
++{
++  char *name = NULL;
++  char *value = NULL;
++  char *new_value = NULL;
++
++  if (lt_split_name_value (arg, &name, &value) != 0)
++    {
++      XFREE (name);
++      XFREE (value);
++      lt_fatal ("bad argument for %s: '%s'", env_prepend_opt, arg);
++    }
++
++  new_value = lt_extend_str (getenv (name), value, 0);
++  lt_setenv (name, new_value);
++  XFREE (new_value);
++  XFREE (name);
++  XFREE (value);
++}
++
++void
++lt_opt_process_env_append (const char *arg)
++{
++  char *name = NULL;
++  char *value = NULL;
++  char *new_value = NULL;
++
++  if (lt_split_name_value (arg, &name, &value) != 0)
++    {
++      XFREE (name);
++      XFREE (value);
++      lt_fatal ("bad argument for %s: '%s'", env_append_opt, arg);
++    }
++
++  new_value = lt_extend_str (getenv (name), value, 1);
++  lt_setenv (name, new_value);
++  XFREE (new_value);
++  XFREE (name);
++  XFREE (value);
++}
++
++void
++lt_update_exe_path (const char *name, const char *value)
++{
++  LTWRAPPER_DEBUGPRINTF (("(lt_update_exe_path) modifying '%s' by prepending '%s'\n",
++                          (name ? name : "<NULL>"),
++                          (value ? value : "<NULL>")));
++
++  if (name && *name && value && *value)
++    {
++      char *new_value = lt_extend_str (getenv (name), value, 0);
++      /* some systems can't cope with a ':'-terminated path #' */
++      int len = strlen (new_value);
++      while (((len = strlen (new_value)) > 0) && IS_PATH_SEPARATOR (new_value[len-1]))
++        {
++          new_value[len-1] = '\0';
++        }
++      lt_setenv (name, new_value);
++      XFREE (new_value);
++    }
++}
++
++void
++lt_update_lib_path (const char *name, const char *value)
++{
++  LTWRAPPER_DEBUGPRINTF (("(lt_update_lib_path) modifying '%s' by prepending '%s'\n",
++                          (name ? name : "<NULL>"),
++                          (value ? value : "<NULL>")));
++
++  if (name && *name && value && *value)
++    {
++      char *new_value = lt_extend_str (getenv (name), value, 0);
++      lt_setenv (name, new_value);
++      XFREE (new_value);
++    }
++}
++
++
++EOF
++}
++# end: func_emit_cwrapperexe_src
++
++# func_mode_link arg...
++func_mode_link ()
++{
++    $opt_debug
++    case $host in
++    *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-cegcc*)
++      # It is impossible to link a dll without this setting, and
++      # we shouldn't force the makefile maintainer to figure out
++      # which system we are compiling for in order to pass an extra
++      # flag for every libtool invocation.
++      # allow_undefined=no
++
++      # FIXME: Unfortunately, there are problems with the above when trying
++      # to make a dll which has undefined symbols, in which case not
++      # even a static library is built.  For now, we need to specify
++      # -no-undefined on the libtool link line when we can be certain
++      # that all symbols are satisfied, otherwise we get a static library.
++      allow_undefined=yes
++      ;;
++    *)
++      allow_undefined=yes
++      ;;
++    esac
++    libtool_args=$nonopt
++    base_compile="$nonopt $@"
++    compile_command=$nonopt
++    finalize_command=$nonopt
++
++    compile_rpath=
++    finalize_rpath=
++    compile_shlibpath=
++    finalize_shlibpath=
++    convenience=
++    old_convenience=
++    deplibs=
++    old_deplibs=
++    compiler_flags=
++    linker_flags=
++    dllsearchpath=
++    lib_search_path=`pwd`
++    inst_prefix_dir=
++    new_inherited_linker_flags=
++
++    avoid_version=no
++    dlfiles=
++    dlprefiles=
++    dlself=no
++    export_dynamic=no
++    export_symbols=
++    export_symbols_regex=
++    generated=
++    libobjs=
++    ltlibs=
++    module=no
++    no_install=no
++    objs=
++    non_pic_objects=
++    precious_files_regex=
++    prefer_static_libs=no
++    preload=no
++    prev=
++    prevarg=
++    release=
++    rpath=
++    xrpath=
++    perm_rpath=
++    temp_rpath=
++    thread_safe=no
++    vinfo=
++    vinfo_number=no
++    weak_libs=
++    single_module="${wl}-single_module"
++    func_infer_tag $base_compile
++
++    # We need to know -static, to get the right output filenames.
++    for arg
++    do
++      case $arg in
++      -shared)
++	test "$build_libtool_libs" != yes && \
++	  func_fatal_configuration "can not build a shared library"
++	build_old_libs=no
++	break
++	;;
++      -all-static | -static | -static-libtool-libs)
++	case $arg in
++	-all-static)
++	  if test "$build_libtool_libs" = yes && test -z "$link_static_flag"; then
++	    func_warning "complete static linking is impossible in this configuration"
++	  fi
++	  if test -n "$link_static_flag"; then
++	    dlopen_self=$dlopen_self_static
++	  fi
++	  prefer_static_libs=yes
++	  ;;
++	-static)
++	  if test -z "$pic_flag" && test -n "$link_static_flag"; then
++	    dlopen_self=$dlopen_self_static
++	  fi
++	  prefer_static_libs=built
++	  ;;
++	-static-libtool-libs)
++	  if test -z "$pic_flag" && test -n "$link_static_flag"; then
++	    dlopen_self=$dlopen_self_static
++	  fi
++	  prefer_static_libs=yes
++	  ;;
++	esac
++	build_libtool_libs=no
++	build_old_libs=yes
++	break
++	;;
++      esac
++    done
++
++    # See if our shared archives depend on static archives.
++    test -n "$old_archive_from_new_cmds" && build_old_libs=yes
++
++    # Go through the arguments, transforming them on the way.
++    while test "$#" -gt 0; do
++      arg="$1"
++      shift
++      func_quote_for_eval "$arg"
++      qarg=$func_quote_for_eval_unquoted_result
++      func_append libtool_args " $func_quote_for_eval_result"
++
++      # If the previous option needs an argument, assign it.
++      if test -n "$prev"; then
++	case $prev in
++	output)
++	  func_append compile_command " @OUTPUT@"
++	  func_append finalize_command " @OUTPUT@"
++	  ;;
++	esac
++
++	case $prev in
++	dlfiles|dlprefiles)
++	  if test "$preload" = no; then
++	    # Add the symbol object into the linking commands.
++	    func_append compile_command " @SYMFILE@"
++	    func_append finalize_command " @SYMFILE@"
++	    preload=yes
++	  fi
++	  case $arg in
++	  *.la | *.lo) ;;  # We handle these cases below.
++	  force)
++	    if test "$dlself" = no; then
++	      dlself=needless
++	      export_dynamic=yes
++	    fi
++	    prev=
++	    continue
++	    ;;
++	  self)
++	    if test "$prev" = dlprefiles; then
++	      dlself=yes
++	    elif test "$prev" = dlfiles && test "$dlopen_self" != yes; then
++	      dlself=yes
++	    else
++	      dlself=needless
++	      export_dynamic=yes
++	    fi
++	    prev=
++	    continue
++	    ;;
++	  *)
++	    if test "$prev" = dlfiles; then
++	      dlfiles="$dlfiles $arg"
++	    else
++	      dlprefiles="$dlprefiles $arg"
++	    fi
++	    prev=
++	    continue
++	    ;;
++	  esac
++	  ;;
++	expsyms)
++	  export_symbols="$arg"
++	  test -f "$arg" \
++	    || func_fatal_error "symbol file \`$arg' does not exist"
++	  prev=
++	  continue
++	  ;;
++	expsyms_regex)
++	  export_symbols_regex="$arg"
++	  prev=
++	  continue
++	  ;;
++	framework)
++	  case $host in
++	    *-*-darwin*)
++	      case "$deplibs " in
++		*" $qarg.ltframework "*) ;;
++		*) deplibs="$deplibs $qarg.ltframework" # this is fixed later
++		   ;;
++	      esac
++	      ;;
++	  esac
++	  prev=
++	  continue
++	  ;;
++	inst_prefix)
++	  inst_prefix_dir="$arg"
++	  prev=
++	  continue
++	  ;;
++	objectlist)
++	  if test -f "$arg"; then
++	    save_arg=$arg
++	    moreargs=
++	    for fil in `cat "$save_arg"`
++	    do
++#	      moreargs="$moreargs $fil"
++	      arg=$fil
++	      # A libtool-controlled object.
++
++	      # Check to see that this really is a libtool object.
++	      if func_lalib_unsafe_p "$arg"; then
++		pic_object=
++		non_pic_object=
++
++		# Read the .lo file
++		func_source "$arg"
++
++		if test -z "$pic_object" ||
++		   test -z "$non_pic_object" ||
++		   test "$pic_object" = none &&
++		   test "$non_pic_object" = none; then
++		  func_fatal_error "cannot find name of object for \`$arg'"
++		fi
++
++		# Extract subdirectory from the argument.
++		func_dirname "$arg" "/" ""
++		xdir="$func_dirname_result"
++
++		if test "$pic_object" != none; then
++		  # Prepend the subdirectory the object is found in.
++		  pic_object="$xdir$pic_object"
++
++		  if test "$prev" = dlfiles; then
++		    if test "$build_libtool_libs" = yes && test "$dlopen_support" = yes; then
++		      dlfiles="$dlfiles $pic_object"
++		      prev=
++		      continue
++		    else
++		      # If libtool objects are unsupported, then we need to preload.
++		      prev=dlprefiles
++		    fi
++		  fi
++
++		  # CHECK ME:  I think I busted this.  -Ossama
++		  if test "$prev" = dlprefiles; then
++		    # Preload the old-style object.
++		    dlprefiles="$dlprefiles $pic_object"
++		    prev=
++		  fi
++
++		  # A PIC object.
++		  func_append libobjs " $pic_object"
++		  arg="$pic_object"
++		fi
++
++		# Non-PIC object.
++		if test "$non_pic_object" != none; then
++		  # Prepend the subdirectory the object is found in.
++		  non_pic_object="$xdir$non_pic_object"
++
++		  # A standard non-PIC object
++		  func_append non_pic_objects " $non_pic_object"
++		  if test -z "$pic_object" || test "$pic_object" = none ; then
++		    arg="$non_pic_object"
++		  fi
++		else
++		  # If the PIC object exists, use it instead.
++		  # $xdir was prepended to $pic_object above.
++		  non_pic_object="$pic_object"
++		  func_append non_pic_objects " $non_pic_object"
++		fi
++	      else
++		# Only an error if not doing a dry-run.
++		if $opt_dry_run; then
++		  # Extract subdirectory from the argument.
++		  func_dirname "$arg" "/" ""
++		  xdir="$func_dirname_result"
++
++		  func_lo2o "$arg"
++		  pic_object=$xdir$objdir/$func_lo2o_result
++		  non_pic_object=$xdir$func_lo2o_result
++		  func_append libobjs " $pic_object"
++		  func_append non_pic_objects " $non_pic_object"
++	        else
++		  func_fatal_error "\`$arg' is not a valid libtool object"
++		fi
++	      fi
++	    done
++	  else
++	    func_fatal_error "link input file \`$arg' does not exist"
++	  fi
++	  arg=$save_arg
++	  prev=
++	  continue
++	  ;;
++	precious_regex)
++	  precious_files_regex="$arg"
++	  prev=
++	  continue
++	  ;;
++	release)
++	  release="-$arg"
++	  prev=
++	  continue
++	  ;;
++	rpath | xrpath)
++	  # We need an absolute path.
++	  case $arg in
++	  [\\/]* | [A-Za-z]:[\\/]*) ;;
++	  *)
++	    func_fatal_error "only absolute run-paths are allowed"
++	    ;;
++	  esac
++	  if test "$prev" = rpath; then
++	    case "$rpath " in
++	    *" $arg "*) ;;
++	    *) rpath="$rpath $arg" ;;
++	    esac
++	  else
++	    case "$xrpath " in
++	    *" $arg "*) ;;
++	    *) xrpath="$xrpath $arg" ;;
++	    esac
++	  fi
++	  prev=
++	  continue
++	  ;;
++	shrext)
++	  shrext_cmds="$arg"
++	  prev=
++	  continue
++	  ;;
++	weak)
++	  weak_libs="$weak_libs $arg"
++	  prev=
++	  continue
++	  ;;
++	xcclinker)
++	  linker_flags="$linker_flags $qarg"
++	  compiler_flags="$compiler_flags $qarg"
++	  prev=
++	  func_append compile_command " $qarg"
++	  func_append finalize_command " $qarg"
++	  continue
++	  ;;
++	xcompiler)
++	  compiler_flags="$compiler_flags $qarg"
++	  prev=
++	  func_append compile_command " $qarg"
++	  func_append finalize_command " $qarg"
++	  continue
++	  ;;
++	xlinker)
++	  linker_flags="$linker_flags $qarg"
++	  compiler_flags="$compiler_flags $wl$qarg"
++	  prev=
++	  func_append compile_command " $wl$qarg"
++	  func_append finalize_command " $wl$qarg"
++	  continue
++	  ;;
++	*)
++	  eval "$prev=\"\$arg\""
++	  prev=
++	  continue
++	  ;;
++	esac
++      fi # test -n "$prev"
++
++      prevarg="$arg"
++
++      case $arg in
++      -all-static)
++	if test -n "$link_static_flag"; then
++	  # See comment for -static flag below, for more details.
++	  func_append compile_command " $link_static_flag"
++	  func_append finalize_command " $link_static_flag"
++	fi
++	continue
++	;;
++
++      -allow-undefined)
++	# FIXME: remove this flag sometime in the future.
++	func_fatal_error "\`-allow-undefined' must not be used because it is the default"
++	;;
++
++      -avoid-version)
++	avoid_version=yes
++	continue
++	;;
++
++      -dlopen)
++	prev=dlfiles
++	continue
++	;;
++
++      -dlpreopen)
++	prev=dlprefiles
++	continue
++	;;
++
++      -export-dynamic)
++	export_dynamic=yes
++	continue
++	;;
++
++      -export-symbols | -export-symbols-regex)
++	if test -n "$export_symbols" || test -n "$export_symbols_regex"; then
++	  func_fatal_error "more than one -exported-symbols argument is not allowed"
++	fi
++	if test "X$arg" = "X-export-symbols"; then
++	  prev=expsyms
++	else
++	  prev=expsyms_regex
++	fi
++	continue
++	;;
++
++      -framework)
++	prev=framework
++	continue
++	;;
++
++      -inst-prefix-dir)
++	prev=inst_prefix
++	continue
++	;;
++
++      # The native IRIX linker understands -LANG:*, -LIST:* and -LNO:*
++      # so, if we see these flags be careful not to treat them like -L
++      -L[A-Z][A-Z]*:*)
++	case $with_gcc/$host in
++	no/*-*-irix* | /*-*-irix*)
++	  func_append compile_command " $arg"
++	  func_append finalize_command " $arg"
++	  ;;
++	esac
++	continue
++	;;
++
++      -L*)
++	func_stripname '-L' '' "$arg"
++	dir=$func_stripname_result
++	if test -z "$dir"; then
++	  if test "$#" -gt 0; then
++	    func_fatal_error "require no space between \`-L' and \`$1'"
++	  else
++	    func_fatal_error "need path for \`-L' option"
++	  fi
++	fi
++	# We need an absolute path.
++	case $dir in
++	[\\/]* | [A-Za-z]:[\\/]*) ;;
++	*)
++	  absdir=`cd "$dir" && pwd`
++	  test -z "$absdir" && \
++	    func_fatal_error "cannot determine absolute directory name of \`$dir'"
++	  dir="$absdir"
++	  ;;
++	esac
++	case "$deplibs " in
++	*" -L$dir "*) ;;
++	*)
++	  deplibs="$deplibs -L$dir"
++	  lib_search_path="$lib_search_path $dir"
++	  ;;
++	esac
++	case $host in
++	*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-cegcc*)
++	  testbindir=`$ECHO "X$dir" | $Xsed -e 's*/lib$*/bin*'`
++	  case :$dllsearchpath: in
++	  *":$dir:"*) ;;
++	  ::) dllsearchpath=$dir;;
++	  *) dllsearchpath="$dllsearchpath:$dir";;
++	  esac
++	  case :$dllsearchpath: in
++	  *":$testbindir:"*) ;;
++	  ::) dllsearchpath=$testbindir;;
++	  *) dllsearchpath="$dllsearchpath:$testbindir";;
++	  esac
++	  ;;
++	esac
++	continue
++	;;
++
++      -l*)
++	if test "X$arg" = "X-lc" || test "X$arg" = "X-lm"; then
++	  case $host in
++	  *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-beos* | *-cegcc*)
++	    # These systems don't actually have a C or math library (as such)
++	    continue
++	    ;;
++	  *-*-os2*)
++	    # These systems don't actually have a C library (as such)
++	    test "X$arg" = "X-lc" && continue
++	    ;;
++	  *-*-openbsd* | *-*-freebsd* | *-*-dragonfly*)
++	    # Do not include libc due to us having libc/libc_r.
++	    test "X$arg" = "X-lc" && continue
++	    ;;
++	  *-*-rhapsody* | *-*-darwin1.[012])
++	    # Rhapsody C and math libraries are in the System framework
++	    deplibs="$deplibs System.ltframework"
++	    continue
++	    ;;
++	  *-*-sco3.2v5* | *-*-sco5v6*)
++	    # Causes problems with __ctype
++	    test "X$arg" = "X-lc" && continue
++	    ;;
++	  *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*)
++	    # Compiler inserts libc in the correct place for threads to work
++	    test "X$arg" = "X-lc" && continue
++	    ;;
++	  esac
++	elif test "X$arg" = "X-lc_r"; then
++	 case $host in
++	 *-*-openbsd* | *-*-freebsd* | *-*-dragonfly*)
++	   # Do not include libc_r directly, use -pthread flag.
++	   continue
++	   ;;
++	 esac
++	fi
++	deplibs="$deplibs $arg"
++	continue
++	;;
++
++      -module)
++	module=yes
++	continue
++	;;
++
++      # Tru64 UNIX uses -model [arg] to determine the layout of C++
++      # classes, name mangling, and exception handling.
++      # Darwin uses the -arch flag to determine output architecture.
++      -model|-arch|-isysroot)
++	compiler_flags="$compiler_flags $arg"
++	func_append compile_command " $arg"
++	func_append finalize_command " $arg"
++	prev=xcompiler
++	continue
++	;;
++
++      -mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe|-threads)
++	compiler_flags="$compiler_flags $arg"
++	func_append compile_command " $arg"
++	func_append finalize_command " $arg"
++	case "$new_inherited_linker_flags " in
++	    *" $arg "*) ;;
++	    * ) new_inherited_linker_flags="$new_inherited_linker_flags $arg" ;;
++	esac
++	continue
++	;;
++
++      -multi_module)
++	single_module="${wl}-multi_module"
++	continue
++	;;
++
++      -no-fast-install)
++	fast_install=no
++	continue
++	;;
++
++      -no-install)
++	case $host in
++	*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-*-darwin* | *-cegcc*)
++	  # The PATH hackery in wrapper scripts is required on Windows
++	  # and Darwin in order for the loader to find any dlls it needs.
++	  func_warning "\`-no-install' is ignored for $host"
++	  func_warning "assuming \`-no-fast-install' instead"
++	  fast_install=no
++	  ;;
++	*) no_install=yes ;;
++	esac
++	continue
++	;;
++
++      -no-undefined)
++	allow_undefined=no
++	continue
++	;;
++
++      -objectlist)
++	prev=objectlist
++	continue
++	;;
++
++      -o) prev=output ;;
++
++      -precious-files-regex)
++	prev=precious_regex
++	continue
++	;;
++
++      -release)
++	prev=release
++	continue
++	;;
++
++      -rpath)
++	prev=rpath
++	continue
++	;;
++
++      -R)
++	prev=xrpath
++	continue
++	;;
++
++      -R*)
++	func_stripname '-R' '' "$arg"
++	dir=$func_stripname_result
++	# We need an absolute path.
++	case $dir in
++	[\\/]* | [A-Za-z]:[\\/]*) ;;
++	*)
++	  func_fatal_error "only absolute run-paths are allowed"
++	  ;;
++	esac
++	case "$xrpath " in
++	*" $dir "*) ;;
++	*) xrpath="$xrpath $dir" ;;
++	esac
++	continue
++	;;
++
++      -shared)
++	# The effects of -shared are defined in a previous loop.
++	continue
++	;;
++
++      -shrext)
++	prev=shrext
++	continue
++	;;
++
++      -static | -static-libtool-libs)
++	# The effects of -static are defined in a previous loop.
++	# We used to do the same as -all-static on platforms that
++	# didn't have a PIC flag, but the assumption that the effects
++	# would be equivalent was wrong.  It would break on at least
++	# Digital Unix and AIX.
++	continue
++	;;
++
++      -thread-safe)
++	thread_safe=yes
++	continue
++	;;
++
++      -version-info)
++	prev=vinfo
++	continue
++	;;
++
++      -version-number)
++	prev=vinfo
++	vinfo_number=yes
++	continue
++	;;
++
++      -weak)
++        prev=weak
++	continue
++	;;
++
++      -Wc,*)
++	func_stripname '-Wc,' '' "$arg"
++	args=$func_stripname_result
++	arg=
++	save_ifs="$IFS"; IFS=','
++	for flag in $args; do
++	  IFS="$save_ifs"
++          func_quote_for_eval "$flag"
++	  arg="$arg $wl$func_quote_for_eval_result"
++	  compiler_flags="$compiler_flags $func_quote_for_eval_result"
++	done
++	IFS="$save_ifs"
++	func_stripname ' ' '' "$arg"
++	arg=$func_stripname_result
++	;;
++
++      -Wl,*)
++	func_stripname '-Wl,' '' "$arg"
++	args=$func_stripname_result
++	arg=
++	save_ifs="$IFS"; IFS=','
++	for flag in $args; do
++	  IFS="$save_ifs"
++          func_quote_for_eval "$flag"
++	  arg="$arg $wl$func_quote_for_eval_result"
++	  compiler_flags="$compiler_flags $wl$func_quote_for_eval_result"
++	  linker_flags="$linker_flags $func_quote_for_eval_result"
++	done
++	IFS="$save_ifs"
++	func_stripname ' ' '' "$arg"
++	arg=$func_stripname_result
++	;;
++
++      -Xcompiler)
++	prev=xcompiler
++	continue
++	;;
++
++      -Xlinker)
++	prev=xlinker
++	continue
++	;;
++
++      -XCClinker)
++	prev=xcclinker
++	continue
++	;;
++
++      # -msg_* for osf cc
++      -msg_*)
++	func_quote_for_eval "$arg"
++	arg="$func_quote_for_eval_result"
++	;;
++
++      # -64, -mips[0-9] enable 64-bit mode on the SGI compiler
++      # -r[0-9][0-9]* specifies the processor on the SGI compiler
++      # -xarch=*, -xtarget=* enable 64-bit mode on the Sun compiler
++      # +DA*, +DD* enable 64-bit mode on the HP compiler
++      # -q* pass through compiler args for the IBM compiler
++      # -m*, -t[45]*, -txscale* pass through architecture-specific
++      # compiler args for GCC
++      # -F/path gives path to uninstalled frameworks, gcc on darwin
++      # -p, -pg, --coverage, -fprofile-* pass through profiling flag for GCC
++      # @file GCC response files
++      -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
++      -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*)
++        func_quote_for_eval "$arg"
++	arg="$func_quote_for_eval_result"
++        func_append compile_command " $arg"
++        func_append finalize_command " $arg"
++        compiler_flags="$compiler_flags $arg"
++        continue
++        ;;
++
++      # Some other compiler flag.
++      -* | +*)
++        func_quote_for_eval "$arg"
++	arg="$func_quote_for_eval_result"
++	;;
++
++      *.$objext)
++	# A standard object.
++	objs="$objs $arg"
++	;;
++
++      *.lo)
++	# A libtool-controlled object.
++
++	# Check to see that this really is a libtool object.
++	if func_lalib_unsafe_p "$arg"; then
++	  pic_object=
++	  non_pic_object=
++
++	  # Read the .lo file
++	  func_source "$arg"
++
++	  if test -z "$pic_object" ||
++	     test -z "$non_pic_object" ||
++	     test "$pic_object" = none &&
++	     test "$non_pic_object" = none; then
++	    func_fatal_error "cannot find name of object for \`$arg'"
++	  fi
++
++	  # Extract subdirectory from the argument.
++	  func_dirname "$arg" "/" ""
++	  xdir="$func_dirname_result"
++
++	  if test "$pic_object" != none; then
++	    # Prepend the subdirectory the object is found in.
++	    pic_object="$xdir$pic_object"
++
++	    if test "$prev" = dlfiles; then
++	      if test "$build_libtool_libs" = yes && test "$dlopen_support" = yes; then
++		dlfiles="$dlfiles $pic_object"
++		prev=
++		continue
++	      else
++		# If libtool objects are unsupported, then we need to preload.
++		prev=dlprefiles
++	      fi
++	    fi
++
++	    # CHECK ME:  I think I busted this.  -Ossama
++	    if test "$prev" = dlprefiles; then
++	      # Preload the old-style object.
++	      dlprefiles="$dlprefiles $pic_object"
++	      prev=
++	    fi
++
++	    # A PIC object.
++	    func_append libobjs " $pic_object"
++	    arg="$pic_object"
++	  fi
++
++	  # Non-PIC object.
++	  if test "$non_pic_object" != none; then
++	    # Prepend the subdirectory the object is found in.
++	    non_pic_object="$xdir$non_pic_object"
++
++	    # A standard non-PIC object
++	    func_append non_pic_objects " $non_pic_object"
++	    if test -z "$pic_object" || test "$pic_object" = none ; then
++	      arg="$non_pic_object"
++	    fi
++	  else
++	    # If the PIC object exists, use it instead.
++	    # $xdir was prepended to $pic_object above.
++	    non_pic_object="$pic_object"
++	    func_append non_pic_objects " $non_pic_object"
++	  fi
++	else
++	  # Only an error if not doing a dry-run.
++	  if $opt_dry_run; then
++	    # Extract subdirectory from the argument.
++	    func_dirname "$arg" "/" ""
++	    xdir="$func_dirname_result"
++
++	    func_lo2o "$arg"
++	    pic_object=$xdir$objdir/$func_lo2o_result
++	    non_pic_object=$xdir$func_lo2o_result
++	    func_append libobjs " $pic_object"
++	    func_append non_pic_objects " $non_pic_object"
++	  else
++	    func_fatal_error "\`$arg' is not a valid libtool object"
++	  fi
++	fi
++	;;
++
++      *.$libext)
++	# An archive.
++	deplibs="$deplibs $arg"
++	old_deplibs="$old_deplibs $arg"
++	continue
++	;;
++
++      *.la)
++	# A libtool-controlled library.
++
++	if test "$prev" = dlfiles; then
++	  # This library was specified with -dlopen.
++	  dlfiles="$dlfiles $arg"
++	  prev=
++	elif test "$prev" = dlprefiles; then
++	  # The library was specified with -dlpreopen.
++	  dlprefiles="$dlprefiles $arg"
++	  prev=
++	else
++	  deplibs="$deplibs $arg"
++	fi
++	continue
++	;;
++
++      # Some other compiler argument.
++      *)
++	# Unknown arguments in both finalize_command and compile_command need
++	# to be aesthetically quoted because they are evaled later.
++	func_quote_for_eval "$arg"
++	arg="$func_quote_for_eval_result"
++	;;
++      esac # arg
++
++      # Now actually substitute the argument into the commands.
++      if test -n "$arg"; then
++	func_append compile_command " $arg"
++	func_append finalize_command " $arg"
++      fi
++    done # argument parsing loop
++
++    test -n "$prev" && \
++      func_fatal_help "the \`$prevarg' option requires an argument"
++
++    if test "$export_dynamic" = yes && test -n "$export_dynamic_flag_spec"; then
++      eval arg=\"$export_dynamic_flag_spec\"
++      func_append compile_command " $arg"
++      func_append finalize_command " $arg"
++    fi
++
++    oldlibs=
++    # calculate the name of the file, without its directory
++    func_basename "$output"
++    outputname="$func_basename_result"
++    libobjs_save="$libobjs"
++
++    if test -n "$shlibpath_var"; then
++      # get the directories listed in $shlibpath_var
++      eval shlib_search_path=\`\$ECHO \"X\${$shlibpath_var}\" \| \$Xsed -e \'s/:/ /g\'\`
++    else
++      shlib_search_path=
++    fi
++    eval sys_lib_search_path=\"$sys_lib_search_path_spec\"
++    eval sys_lib_dlsearch_path=\"$sys_lib_dlsearch_path_spec\"
++
++    func_dirname "$output" "/" ""
++    output_objdir="$func_dirname_result$objdir"
++    # Create the object directory.
++    func_mkdir_p "$output_objdir"
++
++    # Determine the type of output
++    case $output in
++    "")
++      func_fatal_help "you must specify an output file"
++      ;;
++    *.$libext) linkmode=oldlib ;;
++    *.lo | *.$objext) linkmode=obj ;;
++    *.la) linkmode=lib ;;
++    *) linkmode=prog ;; # Anything else should be a program.
++    esac
++
++    specialdeplibs=
++
++    libs=
++    # Find all interdependent deplibs by searching for libraries
++    # that are linked more than once (e.g. -la -lb -la)
++    for deplib in $deplibs; do
++      if $opt_duplicate_deps ; then
++	case "$libs " in
++	*" $deplib "*) specialdeplibs="$specialdeplibs $deplib" ;;
++	esac
++      fi
++      libs="$libs $deplib"
++    done
++
++    if test "$linkmode" = lib; then
++      libs="$predeps $libs $compiler_lib_search_path $postdeps"
++
++      # Compute libraries that are listed more than once in $predeps
++      # $postdeps and mark them as special (i.e., whose duplicates are
++      # not to be eliminated).
++      pre_post_deps=
++      if $opt_duplicate_compiler_generated_deps; then
++	for pre_post_dep in $predeps $postdeps; do
++	  case "$pre_post_deps " in
++	  *" $pre_post_dep "*) specialdeplibs="$specialdeplibs $pre_post_deps" ;;
++	  esac
++	  pre_post_deps="$pre_post_deps $pre_post_dep"
++	done
++      fi
++      pre_post_deps=
++    fi
++
++    deplibs=
++    newdependency_libs=
++    newlib_search_path=
++    need_relink=no # whether we're linking any uninstalled libtool libraries
++    notinst_deplibs= # not-installed libtool libraries
++    notinst_path= # paths that contain not-installed libtool libraries
++
++    case $linkmode in
++    lib)
++	passes="conv dlpreopen link"
++	for file in $dlfiles $dlprefiles; do
++	  case $file in
++	  *.la) ;;
++	  *)
++	    func_fatal_help "libraries can \`-dlopen' only libtool libraries: $file"
++	    ;;
++	  esac
++	done
++	;;
++    prog)
++	compile_deplibs=
++	finalize_deplibs=
++	alldeplibs=no
++	newdlfiles=
++	newdlprefiles=
++	passes="conv scan dlopen dlpreopen link"
++	;;
++    *)  passes="conv"
++	;;
++    esac
++
++    for pass in $passes; do
++      # The preopen pass in lib mode reverses $deplibs; put it back here
++      # so that -L comes before libs that need it for instance...
++      if test "$linkmode,$pass" = "lib,link"; then
++	## FIXME: Find the place where the list is rebuilt in the wrong
++	##        order, and fix it there properly
++        tmp_deplibs=
++	for deplib in $deplibs; do
++	  tmp_deplibs="$deplib $tmp_deplibs"
++	done
++	deplibs="$tmp_deplibs"
++      fi
++
++      if test "$linkmode,$pass" = "lib,link" ||
++	 test "$linkmode,$pass" = "prog,scan"; then
++	libs="$deplibs"
++	deplibs=
++      fi
++      if test "$linkmode" = prog; then
++	case $pass in
++	dlopen) libs="$dlfiles" ;;
++	dlpreopen) libs="$dlprefiles" ;;
++	link)
++	  libs="$deplibs %DEPLIBS%"
++	  test "X$link_all_deplibs" != Xno && libs="$libs $dependency_libs"
++	  ;;
++	esac
++      fi
++      if test "$linkmode,$pass" = "lib,dlpreopen"; then
++	# Collect and forward deplibs of preopened libtool libs
++	for lib in $dlprefiles; do
++	  # Ignore non-libtool-libs
++	  dependency_libs=
++	  case $lib in
++	  *.la)	func_source "$lib" ;;
++	  esac
++
++	  # Collect preopened libtool deplibs, except any this library
++	  # has declared as weak libs
++	  for deplib in $dependency_libs; do
++            deplib_base=`$ECHO "X$deplib" | $Xsed -e "$basename"`
++	    case " $weak_libs " in
++	    *" $deplib_base "*) ;;
++	    *) deplibs="$deplibs $deplib" ;;
++	    esac
++	  done
++	done
++	libs="$dlprefiles"
++      fi
++      if test "$pass" = dlopen; then
++	# Collect dlpreopened libraries
++	save_deplibs="$deplibs"
++	deplibs=
++      fi
++
++      for deplib in $libs; do
++	lib=
++	found=no
++	case $deplib in
++	-mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe|-threads)
++	  if test "$linkmode,$pass" = "prog,link"; then
++	    compile_deplibs="$deplib $compile_deplibs"
++	    finalize_deplibs="$deplib $finalize_deplibs"
++	  else
++	    compiler_flags="$compiler_flags $deplib"
++	    if test "$linkmode" = lib ; then
++		case "$new_inherited_linker_flags " in
++		    *" $deplib "*) ;;
++		    * ) new_inherited_linker_flags="$new_inherited_linker_flags $deplib" ;;
++		esac
++	    fi
++	  fi
++	  continue
++	  ;;
++	-l*)
++	  if test "$linkmode" != lib && test "$linkmode" != prog; then
++	    func_warning "\`-l' is ignored for archives/objects"
++	    continue
++	  fi
++	  func_stripname '-l' '' "$deplib"
++	  name=$func_stripname_result
++	  if test "$linkmode" = lib; then
++	    searchdirs="$newlib_search_path $lib_search_path $compiler_lib_search_dirs $sys_lib_search_path $shlib_search_path"
++	  else
++	    searchdirs="$newlib_search_path $lib_search_path $sys_lib_search_path $shlib_search_path"
++	  fi
++	  for searchdir in $searchdirs; do
++	    for search_ext in .la $std_shrext .so .a; do
++	      # Search the libtool library
++	      lib="$searchdir/lib${name}${search_ext}"
++	      if test -f "$lib"; then
++		if test "$search_ext" = ".la"; then
++		  found=yes
++		else
++		  found=no
++		fi
++		break 2
++	      fi
++	    done
++	  done
++	  if test "$found" != yes; then
++	    # deplib doesn't seem to be a libtool library
++	    if test "$linkmode,$pass" = "prog,link"; then
++	      compile_deplibs="$deplib $compile_deplibs"
++	      finalize_deplibs="$deplib $finalize_deplibs"
++	    else
++	      deplibs="$deplib $deplibs"
++	      test "$linkmode" = lib && newdependency_libs="$deplib $newdependency_libs"
++	    fi
++	    continue
++	  else # deplib is a libtool library
++	    # If $allow_libtool_libs_with_static_runtimes && $deplib is a stdlib,
++	    # We need to do some special things here, and not later.
++	    if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
++	      case " $predeps $postdeps " in
++	      *" $deplib "*)
++		if func_lalib_p "$lib"; then
++		  library_names=
++		  old_library=
++		  func_source "$lib"
++		  for l in $old_library $library_names; do
++		    ll="$l"
++		  done
++		  if test "X$ll" = "X$old_library" ; then # only static version available
++		    found=no
++		    func_dirname "$lib" "" "."
++		    ladir="$func_dirname_result"
++		    lib=$ladir/$old_library
++		    if test "$linkmode,$pass" = "prog,link"; then
++		      compile_deplibs="$deplib $compile_deplibs"
++		      finalize_deplibs="$deplib $finalize_deplibs"
++		    else
++		      deplibs="$deplib $deplibs"
++		      test "$linkmode" = lib && newdependency_libs="$deplib $newdependency_libs"
++		    fi
++		    continue
++		  fi
++		fi
++		;;
++	      *) ;;
++	      esac
++	    fi
++	  fi
++	  ;; # -l
++	*.ltframework)
++	  if test "$linkmode,$pass" = "prog,link"; then
++	    compile_deplibs="$deplib $compile_deplibs"
++	    finalize_deplibs="$deplib $finalize_deplibs"
++	  else
++	    deplibs="$deplib $deplibs"
++	    if test "$linkmode" = lib ; then
++		case "$new_inherited_linker_flags " in
++		    *" $deplib "*) ;;
++		    * ) new_inherited_linker_flags="$new_inherited_linker_flags $deplib" ;;
++		esac
++	    fi
++	  fi
++	  continue
++	  ;;
++	-L*)
++	  case $linkmode in
++	  lib)
++	    deplibs="$deplib $deplibs"
++	    test "$pass" = conv && continue
++	    newdependency_libs="$deplib $newdependency_libs"
++	    func_stripname '-L' '' "$deplib"
++	    newlib_search_path="$newlib_search_path $func_stripname_result"
++	    ;;
++	  prog)
++	    if test "$pass" = conv; then
++	      deplibs="$deplib $deplibs"
++	      continue
++	    fi
++	    if test "$pass" = scan; then
++	      deplibs="$deplib $deplibs"
++	    else
++	      compile_deplibs="$deplib $compile_deplibs"
++	      finalize_deplibs="$deplib $finalize_deplibs"
++	    fi
++	    func_stripname '-L' '' "$deplib"
++	    newlib_search_path="$newlib_search_path $func_stripname_result"
++	    ;;
++	  *)
++	    func_warning "\`-L' is ignored for archives/objects"
++	    ;;
++	  esac # linkmode
++	  continue
++	  ;; # -L
++	-R*)
++	  if test "$pass" = link; then
++	    func_stripname '-R' '' "$deplib"
++	    dir=$func_stripname_result
++	    # Make sure the xrpath contains only unique directories.
++	    case "$xrpath " in
++	    *" $dir "*) ;;
++	    *) xrpath="$xrpath $dir" ;;
++	    esac
++	  fi
++	  deplibs="$deplib $deplibs"
++	  continue
++	  ;;
++	*.la) lib="$deplib" ;;
++	*.$libext)
++	  if test "$pass" = conv; then
++	    deplibs="$deplib $deplibs"
++	    continue
++	  fi
++	  case $linkmode in
++	  lib)
++	    # Linking convenience modules into shared libraries is allowed,
++	    # but linking other static libraries is non-portable.
++	    case " $dlpreconveniencelibs " in
++	    *" $deplib "*) ;;
++	    *)
++	      valid_a_lib=no
++	      case $deplibs_check_method in
++		match_pattern*)
++		  set dummy $deplibs_check_method; shift
++		  match_pattern_regex=`expr "$deplibs_check_method" : "$1 \(.*\)"`
++		  if eval "\$ECHO \"X$deplib\"" 2>/dev/null | $Xsed -e 10q \
++		    | $EGREP "$match_pattern_regex" > /dev/null; then
++		    valid_a_lib=yes
++		  fi
++		;;
++		pass_all)
++		  valid_a_lib=yes
++		;;
++	      esac
++	      if test "$valid_a_lib" != yes; then
++		$ECHO
++		$ECHO "*** Warning: Trying to link with static lib archive $deplib."
++		$ECHO "*** I have the capability to make that library automatically link in when"
++		$ECHO "*** you link to this library.  But I can only do this if you have a"
++		$ECHO "*** shared version of the library, which you do not appear to have"
++		$ECHO "*** because the file extensions .$libext of this argument makes me believe"
++		$ECHO "*** that it is just a static archive that I should not use here."
++	      else
++		$ECHO
++		$ECHO "*** Warning: Linking the shared library $output against the"
++		$ECHO "*** static library $deplib is not portable!"
++		deplibs="$deplib $deplibs"
++	      fi
++	      ;;
++	    esac
++	    continue
++	    ;;
++	  prog)
++	    if test "$pass" != link; then
++	      deplibs="$deplib $deplibs"
++	    else
++	      compile_deplibs="$deplib $compile_deplibs"
++	      finalize_deplibs="$deplib $finalize_deplibs"
++	    fi
++	    continue
++	    ;;
++	  esac # linkmode
++	  ;; # *.$libext
++	*.lo | *.$objext)
++	  if test "$pass" = conv; then
++	    deplibs="$deplib $deplibs"
++	  elif test "$linkmode" = prog; then
++	    if test "$pass" = dlpreopen || test "$dlopen_support" != yes || test "$build_libtool_libs" = no; then
++	      # If there is no dlopen support or we're linking statically,
++	      # we need to preload.
++	      newdlprefiles="$newdlprefiles $deplib"
++	      compile_deplibs="$deplib $compile_deplibs"
++	      finalize_deplibs="$deplib $finalize_deplibs"
++	    else
++	      newdlfiles="$newdlfiles $deplib"
++	    fi
++	  fi
++	  continue
++	  ;;
++	%DEPLIBS%)
++	  alldeplibs=yes
++	  continue
++	  ;;
++	esac # case $deplib
++
++	if test "$found" = yes || test -f "$lib"; then :
++	else
++	  func_fatal_error "cannot find the library \`$lib' or unhandled argument \`$deplib'"
++	fi
++
++	# Check to see that this really is a libtool archive.
++	func_lalib_unsafe_p "$lib" \
++	  || func_fatal_error "\`$lib' is not a valid libtool archive"
++
++	func_dirname "$lib" "" "."
++	ladir="$func_dirname_result"
++
++	dlname=
++	dlopen=
++	dlpreopen=
++	libdir=
++	library_names=
++	old_library=
++	inherited_linker_flags=
++	# If the library was installed with an old release of libtool,
++	# it will not redefine variables installed, or shouldnotlink
++	installed=yes
++	shouldnotlink=no
++	avoidtemprpath=
++
++
++	# Read the .la file
++	func_source "$lib"
++
++	# Convert "-framework foo" to "foo.ltframework"
++	if test -n "$inherited_linker_flags"; then
++	  tmp_inherited_linker_flags=`$ECHO "X$inherited_linker_flags" | $Xsed -e 's/-framework \([^ $]*\)/\1.ltframework/g'`
++	  for tmp_inherited_linker_flag in $tmp_inherited_linker_flags; do
++	    case " $new_inherited_linker_flags " in
++	      *" $tmp_inherited_linker_flag "*) ;;
++	      *) new_inherited_linker_flags="$new_inherited_linker_flags $tmp_inherited_linker_flag";;
++	    esac
++	  done
++	fi
++	dependency_libs=`$ECHO "X $dependency_libs" | $Xsed -e 's% \([^ $]*\).ltframework% -framework \1%g'`
++	if test "$linkmode,$pass" = "lib,link" ||
++	   test "$linkmode,$pass" = "prog,scan" ||
++	   { test "$linkmode" != prog && test "$linkmode" != lib; }; then
++	  test -n "$dlopen" && dlfiles="$dlfiles $dlopen"
++	  test -n "$dlpreopen" && dlprefiles="$dlprefiles $dlpreopen"
++	fi
++
++	if test "$pass" = conv; then
++	  # Only check for convenience libraries
++	  deplibs="$lib $deplibs"
++	  if test -z "$libdir"; then
++	    if test -z "$old_library"; then
++	      func_fatal_error "cannot find name of link library for \`$lib'"
++	    fi
++	    # It is a libtool convenience library, so add in its objects.
++	    convenience="$convenience $ladir/$objdir/$old_library"
++	    old_convenience="$old_convenience $ladir/$objdir/$old_library"
++	    tmp_libs=
++	    for deplib in $dependency_libs; do
++	      deplibs="$deplib $deplibs"
++	      if $opt_duplicate_deps ; then
++		case "$tmp_libs " in
++		*" $deplib "*) specialdeplibs="$specialdeplibs $deplib" ;;
++		esac
++	      fi
++	      tmp_libs="$tmp_libs $deplib"
++	    done
++	  elif test "$linkmode" != prog && test "$linkmode" != lib; then
++	    func_fatal_error "\`$lib' is not a convenience library"
++	  fi
++	  continue
++	fi # $pass = conv
++
++
++	# Get the name of the library we link against.
++	linklib=
++	for l in $old_library $library_names; do
++	  linklib="$l"
++	done
++	if test -z "$linklib"; then
++	  func_fatal_error "cannot find name of link library for \`$lib'"
++	fi
++
++	# This library was specified with -dlopen.
++	if test "$pass" = dlopen; then
++	  if test -z "$libdir"; then
++	    func_fatal_error "cannot -dlopen a convenience library: \`$lib'"
++	  fi
++	  if test -z "$dlname" ||
++	     test "$dlopen_support" != yes ||
++	     test "$build_libtool_libs" = no; then
++	    # If there is no dlname, no dlopen support or we're linking
++	    # statically, we need to preload.  We also need to preload any
++	    # dependent libraries so libltdl's deplib preloader doesn't
++	    # bomb out in the load deplibs phase.
++	    dlprefiles="$dlprefiles $lib $dependency_libs"
++	  else
++	    newdlfiles="$newdlfiles $lib"
++	  fi
++	  continue
++	fi # $pass = dlopen
++
++	# We need an absolute path.
++	case $ladir in
++	[\\/]* | [A-Za-z]:[\\/]*) abs_ladir="$ladir" ;;
++	*)
++	  abs_ladir=`cd "$ladir" && pwd`
++	  if test -z "$abs_ladir"; then
++	    func_warning "cannot determine absolute directory name of \`$ladir'"
++	    func_warning "passing it literally to the linker, although it might fail"
++	    abs_ladir="$ladir"
++	  fi
++	  ;;
++	esac
++	func_basename "$lib"
++	laname="$func_basename_result"
++
++	# Find the relevant object directory and library name.
++	if test "X$installed" = Xyes; then
++	  if test ! -f "$libdir/$linklib" && test -f "$abs_ladir/$linklib"; then
++	    func_warning "library \`$lib' was moved."
++	    dir="$ladir"
++	    absdir="$abs_ladir"
++	    libdir="$abs_ladir"
++	  else
++	    dir="$libdir"
++	    absdir="$libdir"
++	  fi
++	  test "X$hardcode_automatic" = Xyes && avoidtemprpath=yes
++	else
++	  if test ! -f "$ladir/$objdir/$linklib" && test -f "$abs_ladir/$linklib"; then
++	    dir="$ladir"
++	    absdir="$abs_ladir"
++	    # Remove this search path later
++	    notinst_path="$notinst_path $abs_ladir"
++	  else
++	    dir="$ladir/$objdir"
++	    absdir="$abs_ladir/$objdir"
++	    # Remove this search path later
++	    notinst_path="$notinst_path $abs_ladir"
++	  fi
++	fi # $installed = yes
++	func_stripname 'lib' '.la' "$laname"
++	name=$func_stripname_result
++
++	# This library was specified with -dlpreopen.
++	if test "$pass" = dlpreopen; then
++	  if test -z "$libdir" && test "$linkmode" = prog; then
++	    func_fatal_error "only libraries may -dlpreopen a convenience library: \`$lib'"
++	  fi
++	  # Prefer using a static library (so that no silly _DYNAMIC symbols
++	  # are required to link).
++	  if test -n "$old_library"; then
++	    newdlprefiles="$newdlprefiles $dir/$old_library"
++	    # Keep a list of preopened convenience libraries to check
++	    # that they are being used correctly in the link pass.
++	    test -z "$libdir" && \
++		dlpreconveniencelibs="$dlpreconveniencelibs $dir/$old_library"
++	  # Otherwise, use the dlname, so that lt_dlopen finds it.
++	  elif test -n "$dlname"; then
++	    newdlprefiles="$newdlprefiles $dir/$dlname"
++	  else
++	    newdlprefiles="$newdlprefiles $dir/$linklib"
++	  fi
++	fi # $pass = dlpreopen
++
++	if test -z "$libdir"; then
++	  # Link the convenience library
++	  if test "$linkmode" = lib; then
++	    deplibs="$dir/$old_library $deplibs"
++	  elif test "$linkmode,$pass" = "prog,link"; then
++	    compile_deplibs="$dir/$old_library $compile_deplibs"
++	    finalize_deplibs="$dir/$old_library $finalize_deplibs"
++	  else
++	    deplibs="$lib $deplibs" # used for prog,scan pass
++	  fi
++	  continue
++	fi
++
++
++	if test "$linkmode" = prog && test "$pass" != link; then
++	  newlib_search_path="$newlib_search_path $ladir"
++	  deplibs="$lib $deplibs"
++
++	  linkalldeplibs=no
++	  if test "$link_all_deplibs" != no || test -z "$library_names" ||
++	     test "$build_libtool_libs" = no; then
++	    linkalldeplibs=yes
++	  fi
++
++	  tmp_libs=
++	  for deplib in $dependency_libs; do
++	    case $deplib in
++	    -L*) func_stripname '-L' '' "$deplib"
++	         newlib_search_path="$newlib_search_path $func_stripname_result"
++		 ;;
++	    esac
++	    # Need to link against all dependency_libs?
++	    if test "$linkalldeplibs" = yes; then
++	      deplibs="$deplib $deplibs"
++	    else
++	      # Need to hardcode shared library paths
++	      # or/and link against static libraries
++	      newdependency_libs="$deplib $newdependency_libs"
++	    fi
++	    if $opt_duplicate_deps ; then
++	      case "$tmp_libs " in
++	      *" $deplib "*) specialdeplibs="$specialdeplibs $deplib" ;;
++	      esac
++	    fi
++	    tmp_libs="$tmp_libs $deplib"
++	  done # for deplib
++	  continue
++	fi # $linkmode = prog...
++
++	if test "$linkmode,$pass" = "prog,link"; then
++	  if test -n "$library_names" &&
++	     { { test "$prefer_static_libs" = no ||
++	         test "$prefer_static_libs,$installed" = "built,yes"; } ||
++	       test -z "$old_library"; }; then
++	    # We need to hardcode the library path
++	    if test -n "$shlibpath_var" && test -z "$avoidtemprpath" ; then
++	      # Make sure the rpath contains only unique directories.
++	      case "$temp_rpath:" in
++	      *"$absdir:"*) ;;
++	      *) temp_rpath="$temp_rpath$absdir:" ;;
++	      esac
++	    fi
++
++	    # Hardcode the library path.
++	    # Skip directories that are in the system default run-time
++	    # search path.
++	    case " $sys_lib_dlsearch_path " in
++	    *" $absdir "*) ;;
++	    *)
++	      case "$compile_rpath " in
++	      *" $absdir "*) ;;
++	      *) compile_rpath="$compile_rpath $absdir"
++	      esac
++	      ;;
++	    esac
++	    case " $sys_lib_dlsearch_path " in
++	    *" $libdir "*) ;;
++	    *)
++	      case "$finalize_rpath " in
++	      *" $libdir "*) ;;
++	      *) finalize_rpath="$finalize_rpath $libdir"
++	      esac
++	      ;;
++	    esac
++	  fi # $linkmode,$pass = prog,link...
++
++	  if test "$alldeplibs" = yes &&
++	     { test "$deplibs_check_method" = pass_all ||
++	       { test "$build_libtool_libs" = yes &&
++		 test -n "$library_names"; }; }; then
++	    # We only need to search for static libraries
++	    continue
++	  fi
++	fi
++
++	link_static=no # Whether the deplib will be linked statically
++	use_static_libs=$prefer_static_libs
++	if test "$use_static_libs" = built && test "$installed" = yes; then
++	  use_static_libs=no
++	fi
++	if test -n "$library_names" &&
++	   { test "$use_static_libs" = no || test -z "$old_library"; }; then
++	  case $host in
++	  *cygwin* | *mingw* | *cegcc*)
++	      # No point in relinking DLLs because paths are not encoded
++	      notinst_deplibs="$notinst_deplibs $lib"
++	      need_relink=no
++	    ;;
++	  *)
++	    if test "$installed" = no; then
++	      notinst_deplibs="$notinst_deplibs $lib"
++	      need_relink=yes
++	    fi
++	    ;;
++	  esac
++	  # This is a shared library
++
++	  # Warn about portability, can't link against -module's on some
++	  # systems (darwin).  Don't bleat about dlopened modules though!
++	  dlopenmodule=""
++	  for dlpremoduletest in $dlprefiles; do
++	    if test "X$dlpremoduletest" = "X$lib"; then
++	      dlopenmodule="$dlpremoduletest"
++	      break
++	    fi
++	  done
++	  if test -z "$dlopenmodule" && test "$shouldnotlink" = yes && test "$pass" = link; then
++	    $ECHO
++	    if test "$linkmode" = prog; then
++	      $ECHO "*** Warning: Linking the executable $output against the loadable module"
++	    else
++	      $ECHO "*** Warning: Linking the shared library $output against the loadable module"
++	    fi
++	    $ECHO "*** $linklib is not portable!"
++	  fi
++	  if test "$linkmode" = lib &&
++	     test "$hardcode_into_libs" = yes; then
++	    # Hardcode the library path.
++	    # Skip directories that are in the system default run-time
++	    # search path.
++	    case " $sys_lib_dlsearch_path " in
++	    *" $absdir "*) ;;
++	    *)
++	      case "$compile_rpath " in
++	      *" $absdir "*) ;;
++	      *) compile_rpath="$compile_rpath $absdir"
++	      esac
++	      ;;
++	    esac
++	    case " $sys_lib_dlsearch_path " in
++	    *" $libdir "*) ;;
++	    *)
++	      case "$finalize_rpath " in
++	      *" $libdir "*) ;;
++	      *) finalize_rpath="$finalize_rpath $libdir"
++	      esac
++	      ;;
++	    esac
++	  fi
++
++	  if test -n "$old_archive_from_expsyms_cmds"; then
++	    # figure out the soname
++	    set dummy $library_names
++	    shift
++	    realname="$1"
++	    shift
++	    libname=`eval "\\$ECHO \"$libname_spec\""`
++	    # use dlname if we got it. it's perfectly good, no?
++	    if test -n "$dlname"; then
++	      soname="$dlname"
++	    elif test -n "$soname_spec"; then
++	      # bleh windows
++	      case $host in
++	      *cygwin* | mingw* | *cegcc*)
++	        func_arith $current - $age
++		major=$func_arith_result
++		versuffix="-$major"
++		;;
++	      esac
++	      eval soname=\"$soname_spec\"
++	    else
++	      soname="$realname"
++	    fi
++
++	    # Make a new name for the extract_expsyms_cmds to use
++	    soroot="$soname"
++	    func_basename "$soroot"
++	    soname="$func_basename_result"
++	    func_stripname 'lib' '.dll' "$soname"
++	    newlib=libimp-$func_stripname_result.a
++
++	    # If the library has no export list, then create one now
++	    if test -f "$output_objdir/$soname-def"; then :
++	    else
++	      func_verbose "extracting exported symbol list from \`$soname'"
++	      func_execute_cmds "$extract_expsyms_cmds" 'exit $?'
++	    fi
++
++	    # Create $newlib
++	    if test -f "$output_objdir/$newlib"; then :; else
++	      func_verbose "generating import library for \`$soname'"
++	      func_execute_cmds "$old_archive_from_expsyms_cmds" 'exit $?'
++	    fi
++	    # make sure the library variables are pointing to the new library
++	    dir=$output_objdir
++	    linklib=$newlib
++	  fi # test -n "$old_archive_from_expsyms_cmds"
++
++	  if test "$linkmode" = prog || test "$mode" != relink; then
++	    add_shlibpath=
++	    add_dir=
++	    add=
++	    lib_linked=yes
++	    case $hardcode_action in
++	    immediate | unsupported)
++	      if test "$hardcode_direct" = no; then
++		add="$dir/$linklib"
++		case $host in
++		  *-*-sco3.2v5.0.[024]*) add_dir="-L$dir" ;;
++		  *-*-sysv4*uw2*) add_dir="-L$dir" ;;
++		  *-*-sysv5OpenUNIX* | *-*-sysv5UnixWare7.[01].[10]* | \
++		    *-*-unixware7*) add_dir="-L$dir" ;;
++		  *-*-darwin* )
++		    # if the lib is a (non-dlopened) module then we can not
++		    # link against it, someone is ignoring the earlier warnings
++		    if /usr/bin/file -L $add 2> /dev/null |
++			 $GREP ": [^:]* bundle" >/dev/null ; then
++		      if test "X$dlopenmodule" != "X$lib"; then
++			$ECHO "*** Warning: lib $linklib is a module, not a shared library"
++			if test -z "$old_library" ; then
++			  $ECHO
++			  $ECHO "*** And there doesn't seem to be a static archive available"
++			  $ECHO "*** The link will probably fail, sorry"
++			else
++			  add="$dir/$old_library"
++			fi
++		      elif test -n "$old_library"; then
++			add="$dir/$old_library"
++		      fi
++		    fi
++		esac
++	      elif test "$hardcode_minus_L" = no; then
++		case $host in
++		*-*-sunos*) add_shlibpath="$dir" ;;
++		esac
++		add_dir="-L$dir"
++		add="-l$name"
++	      elif test "$hardcode_shlibpath_var" = no; then
++		add_shlibpath="$dir"
++		add="-l$name"
++	      else
++		lib_linked=no
++	      fi
++	      ;;
++	    relink)
++	      if test "$hardcode_direct" = yes &&
++	         test "$hardcode_direct_absolute" = no; then
++		add="$dir/$linklib"
++	      elif test "$hardcode_minus_L" = yes; then
++		add_dir="-L$dir"
++		# Try looking first in the location we're being installed to.
++		if test -n "$inst_prefix_dir"; then
++		  case $libdir in
++		    [\\/]*)
++		      add_dir="$add_dir -L$inst_prefix_dir$libdir"
++		      ;;
++		  esac
++		fi
++		add="-l$name"
++	      elif test "$hardcode_shlibpath_var" = yes; then
++		add_shlibpath="$dir"
++		add="-l$name"
++	      else
++		lib_linked=no
++	      fi
++	      ;;
++	    *) lib_linked=no ;;
++	    esac
++
++	    if test "$lib_linked" != yes; then
++	      func_fatal_configuration "unsupported hardcode properties"
++	    fi
++
++	    if test -n "$add_shlibpath"; then
++	      case :$compile_shlibpath: in
++	      *":$add_shlibpath:"*) ;;
++	      *) compile_shlibpath="$compile_shlibpath$add_shlibpath:" ;;
++	      esac
++	    fi
++	    if test "$linkmode" = prog; then
++	      test -n "$add_dir" && compile_deplibs="$add_dir $compile_deplibs"
++	      test -n "$add" && compile_deplibs="$add $compile_deplibs"
++	    else
++	      test -n "$add_dir" && deplibs="$add_dir $deplibs"
++	      test -n "$add" && deplibs="$add $deplibs"
++	      if test "$hardcode_direct" != yes &&
++		 test "$hardcode_minus_L" != yes &&
++		 test "$hardcode_shlibpath_var" = yes; then
++		case :$finalize_shlibpath: in
++		*":$libdir:"*) ;;
++		*) finalize_shlibpath="$finalize_shlibpath$libdir:" ;;
++		esac
++	      fi
++	    fi
++	  fi
++
++	  if test "$linkmode" = prog || test "$mode" = relink; then
++	    add_shlibpath=
++	    add_dir=
++	    add=
++	    # Finalize command for both is simple: just hardcode it.
++	    if test "$hardcode_direct" = yes &&
++	       test "$hardcode_direct_absolute" = no; then
++	      add="$libdir/$linklib"
++	    elif test "$hardcode_minus_L" = yes; then
++	      add_dir="-L$libdir"
++	      add="-l$name"
++	    elif test "$hardcode_shlibpath_var" = yes; then
++	      case :$finalize_shlibpath: in
++	      *":$libdir:"*) ;;
++	      *) finalize_shlibpath="$finalize_shlibpath$libdir:" ;;
++	      esac
++	      add="-l$name"
++	    elif test "$hardcode_automatic" = yes; then
++	      if test -n "$inst_prefix_dir" &&
++		 test -f "$inst_prefix_dir$libdir/$linklib" ; then
++		add="$inst_prefix_dir$libdir/$linklib"
++	      else
++		add="$libdir/$linklib"
++	      fi
++	    else
++	      # We cannot seem to hardcode it, guess we'll fake it.
++	      add_dir="-L$libdir"
++	      # Try looking first in the location we're being installed to.
++	      if test -n "$inst_prefix_dir"; then
++		case $libdir in
++		  [\\/]*)
++		    add_dir="$add_dir -L$inst_prefix_dir$libdir"
++		    ;;
++		esac
++	      fi
++	      add="-l$name"
++	    fi
++
++	    if test "$linkmode" = prog; then
++	      test -n "$add_dir" && finalize_deplibs="$add_dir $finalize_deplibs"
++	      test -n "$add" && finalize_deplibs="$add $finalize_deplibs"
++	    else
++	      test -n "$add_dir" && deplibs="$add_dir $deplibs"
++	      test -n "$add" && deplibs="$add $deplibs"
++	    fi
++	  fi
++	elif test "$linkmode" = prog; then
++	  # Here we assume that one of hardcode_direct or hardcode_minus_L
++	  # is not unsupported.  This is valid on all known static and
++	  # shared platforms.
++	  if test "$hardcode_direct" != unsupported; then
++	    test -n "$old_library" && linklib="$old_library"
++	    compile_deplibs="$dir/$linklib $compile_deplibs"
++	    finalize_deplibs="$dir/$linklib $finalize_deplibs"
++	  else
++	    compile_deplibs="-l$name -L$dir $compile_deplibs"
++	    finalize_deplibs="-l$name -L$dir $finalize_deplibs"
++	  fi
++	elif test "$build_libtool_libs" = yes; then
++	  # Not a shared library
++	  if test "$deplibs_check_method" != pass_all; then
++	    # We're trying link a shared library against a static one
++	    # but the system doesn't support it.
++
++	    # Just print a warning and add the library to dependency_libs so
++	    # that the program can be linked against the static library.
++	    $ECHO
++	    $ECHO "*** Warning: This system can not link to static lib archive $lib."
++	    $ECHO "*** I have the capability to make that library automatically link in when"
++	    $ECHO "*** you link to this library.  But I can only do this if you have a"
++	    $ECHO "*** shared version of the library, which you do not appear to have."
++	    if test "$module" = yes; then
++	      $ECHO "*** But as you try to build a module library, libtool will still create "
++	      $ECHO "*** a static module, that should work as long as the dlopening application"
++	      $ECHO "*** is linked with the -dlopen flag to resolve symbols at runtime."
++	      if test -z "$global_symbol_pipe"; then
++		$ECHO
++		$ECHO "*** However, this would only work if libtool was able to extract symbol"
++		$ECHO "*** lists from a program, using \`nm' or equivalent, but libtool could"
++		$ECHO "*** not find such a program.  So, this module is probably useless."
++		$ECHO "*** \`nm' from GNU binutils and a full rebuild may help."
++	      fi
++	      if test "$build_old_libs" = no; then
++		build_libtool_libs=module
++		build_old_libs=yes
++	      else
++		build_libtool_libs=no
++	      fi
++	    fi
++	  else
++	    deplibs="$dir/$old_library $deplibs"
++	    link_static=yes
++	  fi
++	fi # link shared/static library?
++
++	if test "$linkmode" = lib; then
++	  if test -n "$dependency_libs" &&
++	     { test "$hardcode_into_libs" != yes ||
++	       test "$build_old_libs" = yes ||
++	       test "$link_static" = yes; }; then
++	    # Extract -R from dependency_libs
++	    temp_deplibs=
++	    for libdir in $dependency_libs; do
++	      case $libdir in
++	      -R*) func_stripname '-R' '' "$libdir"
++	           temp_xrpath=$func_stripname_result
++		   case " $xrpath " in
++		   *" $temp_xrpath "*) ;;
++		   *) xrpath="$xrpath $temp_xrpath";;
++		   esac;;
++	      *) temp_deplibs="$temp_deplibs $libdir";;
++	      esac
++	    done
++	    dependency_libs="$temp_deplibs"
++	  fi
++
++	  newlib_search_path="$newlib_search_path $absdir"
++	  # Link against this library
++	  test "$link_static" = no && newdependency_libs="$abs_ladir/$laname $newdependency_libs"
++	  # ... and its dependency_libs
++	  tmp_libs=
++	  for deplib in $dependency_libs; do
++	    newdependency_libs="$deplib $newdependency_libs"
++	    if $opt_duplicate_deps ; then
++	      case "$tmp_libs " in
++	      *" $deplib "*) specialdeplibs="$specialdeplibs $deplib" ;;
++	      esac
++	    fi
++	    tmp_libs="$tmp_libs $deplib"
++	  done
++
++	  if test "$link_all_deplibs" != no; then
++	    # Add the search paths of all dependency libraries
++	    for deplib in $dependency_libs; do
++	      path=
++	      case $deplib in
++	      -L*) path="$deplib" ;;
++	      *.la)
++	        func_dirname "$deplib" "" "."
++		dir="$func_dirname_result"
++		# We need an absolute path.
++		case $dir in
++		[\\/]* | [A-Za-z]:[\\/]*) absdir="$dir" ;;
++		*)
++		  absdir=`cd "$dir" && pwd`
++		  if test -z "$absdir"; then
++		    func_warning "cannot determine absolute directory name of \`$dir'"
++		    absdir="$dir"
++		  fi
++		  ;;
++		esac
++		if $GREP "^installed=no" $deplib > /dev/null; then
++		case $host in
++		*-*-darwin*)
++		  depdepl=
++		  eval deplibrary_names=`${SED} -n -e 's/^library_names=\(.*\)$/\1/p' $deplib`
++		  if test -n "$deplibrary_names" ; then
++		    for tmp in $deplibrary_names ; do
++		      depdepl=$tmp
++		    done
++		    if test -f "$absdir/$objdir/$depdepl" ; then
++		      depdepl="$absdir/$objdir/$depdepl"
++		      darwin_install_name=`${OTOOL} -L $depdepl | awk '{if (NR == 2) {print $1;exit}}'`
++                      if test -z "$darwin_install_name"; then
++                          darwin_install_name=`${OTOOL64} -L $depdepl  | awk '{if (NR == 2) {print $1;exit}}'`
++                      fi
++		      compiler_flags="$compiler_flags ${wl}-dylib_file ${wl}${darwin_install_name}:${depdepl}"
++		      linker_flags="$linker_flags -dylib_file ${darwin_install_name}:${depdepl}"
++		      path=
++		    fi
++		  fi
++		  ;;
++		*)
++		  path="-L$absdir/$objdir"
++		  ;;
++		esac
++		else
++		  eval libdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $deplib`
++		  test -z "$libdir" && \
++		    func_fatal_error "\`$deplib' is not a valid libtool archive"
++		  test "$absdir" != "$libdir" && \
++		    func_warning "\`$deplib' seems to be moved"
++
++		  path="-L$absdir"
++		fi
++		;;
++	      esac
++	      case " $deplibs " in
++	      *" $path "*) ;;
++	      *) deplibs="$path $deplibs" ;;
++	      esac
++	    done
++	  fi # link_all_deplibs != no
++	fi # linkmode = lib
++      done # for deplib in $libs
++      if test "$pass" = link; then
++	if test "$linkmode" = "prog"; then
++	  compile_deplibs="$new_inherited_linker_flags $compile_deplibs"
++	  finalize_deplibs="$new_inherited_linker_flags $finalize_deplibs"
++	else
++	  compiler_flags="$compiler_flags "`$ECHO "X $new_inherited_linker_flags" | $Xsed -e 's% \([^ $]*\).ltframework% -framework \1%g'`
++	fi
++      fi
++      dependency_libs="$newdependency_libs"
++      if test "$pass" = dlpreopen; then
++	# Link the dlpreopened libraries before other libraries
++	for deplib in $save_deplibs; do
++	  deplibs="$deplib $deplibs"
++	done
++      fi
++      if test "$pass" != dlopen; then
++	if test "$pass" != conv; then
++	  # Make sure lib_search_path contains only unique directories.
++	  lib_search_path=
++	  for dir in $newlib_search_path; do
++	    case "$lib_search_path " in
++	    *" $dir "*) ;;
++	    *) lib_search_path="$lib_search_path $dir" ;;
++	    esac
++	  done
++	  newlib_search_path=
++	fi
++
++	if test "$linkmode,$pass" != "prog,link"; then
++	  vars="deplibs"
++	else
++	  vars="compile_deplibs finalize_deplibs"
++	fi
++	for var in $vars dependency_libs; do
++	  # Add libraries to $var in reverse order
++	  eval tmp_libs=\"\$$var\"
++	  new_libs=
++	  for deplib in $tmp_libs; do
++	    # FIXME: Pedantically, this is the right thing to do, so
++	    #        that some nasty dependency loop isn't accidentally
++	    #        broken:
++	    #new_libs="$deplib $new_libs"
++	    # Pragmatically, this seems to cause very few problems in
++	    # practice:
++	    case $deplib in
++	    -L*) new_libs="$deplib $new_libs" ;;
++	    -R*) ;;
++	    *)
++	      # And here is the reason: when a library appears more
++	      # than once as an explicit dependence of a library, or
++	      # is implicitly linked in more than once by the
++	      # compiler, it is considered special, and multiple
++	      # occurrences thereof are not removed.  Compare this
++	      # with having the same library being listed as a
++	      # dependency of multiple other libraries: in this case,
++	      # we know (pedantically, we assume) the library does not
++	      # need to be listed more than once, so we keep only the
++	      # last copy.  This is not always right, but it is rare
++	      # enough that we require users that really mean to play
++	      # such unportable linking tricks to link the library
++	      # using -Wl,-lname, so that libtool does not consider it
++	      # for duplicate removal.
++	      case " $specialdeplibs " in
++	      *" $deplib "*) new_libs="$deplib $new_libs" ;;
++	      *)
++		case " $new_libs " in
++		*" $deplib "*) ;;
++		*) new_libs="$deplib $new_libs" ;;
++		esac
++		;;
++	      esac
++	      ;;
++	    esac
++	  done
++	  tmp_libs=
++	  for deplib in $new_libs; do
++	    case $deplib in
++	    -L*)
++	      case " $tmp_libs " in
++	      *" $deplib "*) ;;
++	      *) tmp_libs="$tmp_libs $deplib" ;;
++	      esac
++	      ;;
++	    *) tmp_libs="$tmp_libs $deplib" ;;
++	    esac
++	  done
++	  eval $var=\"$tmp_libs\"
++	done # for var
++      fi
++      # Last step: remove runtime libs from dependency_libs
++      # (they stay in deplibs)
++      tmp_libs=
++      for i in $dependency_libs ; do
++	case " $predeps $postdeps $compiler_lib_search_path " in
++	*" $i "*)
++	  i=""
++	  ;;
++	esac
++	if test -n "$i" ; then
++	  tmp_libs="$tmp_libs $i"
++	fi
++      done
++      dependency_libs=$tmp_libs
++    done # for pass
++    if test "$linkmode" = prog; then
++      dlfiles="$newdlfiles"
++    fi
++    if test "$linkmode" = prog || test "$linkmode" = lib; then
++      dlprefiles="$newdlprefiles"
++    fi
++
++    case $linkmode in
++    oldlib)
++      if test -n "$dlfiles$dlprefiles" || test "$dlself" != no; then
++	func_warning "\`-dlopen' is ignored for archives"
++      fi
++
++      case " $deplibs" in
++      *\ -l* | *\ -L*)
++	func_warning "\`-l' and \`-L' are ignored for archives" ;;
++      esac
++
++      test -n "$rpath" && \
++	func_warning "\`-rpath' is ignored for archives"
++
++      test -n "$xrpath" && \
++	func_warning "\`-R' is ignored for archives"
++
++      test -n "$vinfo" && \
++	func_warning "\`-version-info/-version-number' is ignored for archives"
++
++      test -n "$release" && \
++	func_warning "\`-release' is ignored for archives"
++
++      test -n "$export_symbols$export_symbols_regex" && \
++	func_warning "\`-export-symbols' is ignored for archives"
++
++      # Now set the variables for building old libraries.
++      build_libtool_libs=no
++      oldlibs="$output"
++      objs="$objs$old_deplibs"
++      ;;
++
++    lib)
++      # Make sure we only generate libraries of the form `libNAME.la'.
++      case $outputname in
++      lib*)
++	func_stripname 'lib' '.la' "$outputname"
++	name=$func_stripname_result
++	eval shared_ext=\"$shrext_cmds\"
++	eval libname=\"$libname_spec\"
++	;;
++      *)
++	test "$module" = no && \
++	  func_fatal_help "libtool library \`$output' must begin with \`lib'"
++
++	if test "$need_lib_prefix" != no; then
++	  # Add the "lib" prefix for modules if required
++	  func_stripname '' '.la' "$outputname"
++	  name=$func_stripname_result
++	  eval shared_ext=\"$shrext_cmds\"
++	  eval libname=\"$libname_spec\"
++	else
++	  func_stripname '' '.la' "$outputname"
++	  libname=$func_stripname_result
++	fi
++	;;
++      esac
++
++      if test -n "$objs"; then
++	if test "$deplibs_check_method" != pass_all; then
++	  func_fatal_error "cannot build libtool library \`$output' from non-libtool objects on this host:$objs"
++	else
++	  $ECHO
++	  $ECHO "*** Warning: Linking the shared library $output against the non-libtool"
++	  $ECHO "*** objects $objs is not portable!"
++	  libobjs="$libobjs $objs"
++	fi
++      fi
++
++      test "$dlself" != no && \
++	func_warning "\`-dlopen self' is ignored for libtool libraries"
++
++      set dummy $rpath
++      shift
++      test "$#" -gt 1 && \
++	func_warning "ignoring multiple \`-rpath's for a libtool library"
++
++      install_libdir="$1"
++
++      oldlibs=
++      if test -z "$rpath"; then
++	if test "$build_libtool_libs" = yes; then
++	  # Building a libtool convenience library.
++	  # Some compilers have problems with a `.al' extension so
++	  # convenience libraries should have the same extension an
++	  # archive normally would.
++	  oldlibs="$output_objdir/$libname.$libext $oldlibs"
++	  build_libtool_libs=convenience
++	  build_old_libs=yes
++	fi
++
++	test -n "$vinfo" && \
++	  func_warning "\`-version-info/-version-number' is ignored for convenience libraries"
++
++	test -n "$release" && \
++	  func_warning "\`-release' is ignored for convenience libraries"
++      else
++
++	# Parse the version information argument.
++	save_ifs="$IFS"; IFS=':'
++	set dummy $vinfo 0 0 0
++	shift
++	IFS="$save_ifs"
++
++	test -n "$7" && \
++	  func_fatal_help "too many parameters to \`-version-info'"
++
++	# convert absolute version numbers to libtool ages
++	# this retains compatibility with .la files and attempts
++	# to make the code below a bit more comprehensible
++
++	case $vinfo_number in
++	yes)
++	  number_major="$1"
++	  number_minor="$2"
++	  number_revision="$3"
++	  #
++	  # There are really only two kinds -- those that
++	  # use the current revision as the major version
++	  # and those that subtract age and use age as
++	  # a minor version.  But, then there is irix
++	  # which has an extra 1 added just for fun
++	  #
++	  case $version_type in
++	  darwin|linux|osf|windows|none)
++	    func_arith $number_major + $number_minor
++	    current=$func_arith_result
++	    age="$number_minor"
++	    revision="$number_revision"
++	    ;;
++	  freebsd-aout|freebsd-elf|sunos)
++	    current="$number_major"
++	    revision="$number_minor"
++	    age="0"
++	    ;;
++	  irix|nonstopux)
++	    func_arith $number_major + $number_minor
++	    current=$func_arith_result
++	    age="$number_minor"
++	    revision="$number_minor"
++	    lt_irix_increment=no
++	    ;;
++	  *)
++	    func_fatal_configuration "$modename: unknown library version type \`$version_type'"
++	    ;;
++	  esac
++	  ;;
++	no)
++	  current="$1"
++	  revision="$2"
++	  age="$3"
++	  ;;
++	esac
++
++	# Check that each of the things are valid numbers.
++	case $current in
++	0|[1-9]|[1-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9][0-9][0-9]|[1-9][0-9][0-9][0-9][0-9]) ;;
++	*)
++	  func_error "CURRENT \`$current' must be a nonnegative integer"
++	  func_fatal_error "\`$vinfo' is not valid version information"
++	  ;;
++	esac
++
++	case $revision in
++	0|[1-9]|[1-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9][0-9][0-9]|[1-9][0-9][0-9][0-9][0-9]) ;;
++	*)
++	  func_error "REVISION \`$revision' must be a nonnegative integer"
++	  func_fatal_error "\`$vinfo' is not valid version information"
++	  ;;
++	esac
++
++	case $age in
++	0|[1-9]|[1-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9][0-9][0-9]|[1-9][0-9][0-9][0-9][0-9]) ;;
++	*)
++	  func_error "AGE \`$age' must be a nonnegative integer"
++	  func_fatal_error "\`$vinfo' is not valid version information"
++	  ;;
++	esac
++
++	if test "$age" -gt "$current"; then
++	  func_error "AGE \`$age' is greater than the current interface number \`$current'"
++	  func_fatal_error "\`$vinfo' is not valid version information"
++	fi
++
++	# Calculate the version variables.
++	major=
++	versuffix=
++	verstring=
++	case $version_type in
++	none) ;;
++
++	darwin)
++	  # Like Linux, but with the current version available in
++	  # verstring for coding it into the library header
++	  func_arith $current - $age
++	  major=.$func_arith_result
++	  versuffix="$major.$age.$revision"
++	  # Darwin ld doesn't like 0 for these options...
++	  func_arith $current + 1
++	  minor_current=$func_arith_result
++	  xlcverstring="${wl}-compatibility_version ${wl}$minor_current ${wl}-current_version ${wl}$minor_current.$revision"
++	  verstring="-compatibility_version $minor_current -current_version $minor_current.$revision"
++	  ;;
++
++	freebsd-aout)
++	  major=".$current"
++	  versuffix=".$current.$revision";
++	  ;;
++
++	freebsd-elf)
++	  major=".$current"
++	  versuffix=".$current"
++	  ;;
++
++	irix | nonstopux)
++	  if test "X$lt_irix_increment" = "Xno"; then
++	    func_arith $current - $age
++	  else
++	    func_arith $current - $age + 1
++	  fi
++	  major=$func_arith_result
++
++	  case $version_type in
++	    nonstopux) verstring_prefix=nonstopux ;;
++	    *)         verstring_prefix=sgi ;;
++	  esac
++	  verstring="$verstring_prefix$major.$revision"
++
++	  # Add in all the interfaces that we are compatible with.
++	  loop=$revision
++	  while test "$loop" -ne 0; do
++	    func_arith $revision - $loop
++	    iface=$func_arith_result
++	    func_arith $loop - 1
++	    loop=$func_arith_result
++	    verstring="$verstring_prefix$major.$iface:$verstring"
++	  done
++
++	  # Before this point, $major must not contain `.'.
++	  major=.$major
++	  versuffix="$major.$revision"
++	  ;;
++
++	linux)
++	  func_arith $current - $age
++	  major=.$func_arith_result
++	  versuffix="$major.$age.$revision"
++	  ;;
++
++	osf)
++	  func_arith $current - $age
++	  major=.$func_arith_result
++	  versuffix=".$current.$age.$revision"
++	  verstring="$current.$age.$revision"
++
++	  # Add in all the interfaces that we are compatible with.
++	  loop=$age
++	  while test "$loop" -ne 0; do
++	    func_arith $current - $loop
++	    iface=$func_arith_result
++	    func_arith $loop - 1
++	    loop=$func_arith_result
++	    verstring="$verstring:${iface}.0"
++	  done
++
++	  # Make executables depend on our current version.
++	  verstring="$verstring:${current}.0"
++	  ;;
++
++	qnx)
++	  major=".$current"
++	  versuffix=".$current"
++	  ;;
++
++	sunos)
++	  major=".$current"
++	  versuffix=".$current.$revision"
++	  ;;
++
++	windows)
++	  # Use '-' rather than '.', since we only want one
++	  # extension on DOS 8.3 filesystems.
++	  func_arith $current - $age
++	  major=$func_arith_result
++	  versuffix="-$major"
++	  ;;
++
++	*)
++	  func_fatal_configuration "unknown library version type \`$version_type'"
++	  ;;
++	esac
++
++	# Clear the version info if we defaulted, and they specified a release.
++	if test -z "$vinfo" && test -n "$release"; then
++	  major=
++	  case $version_type in
++	  darwin)
++	    # we can't check for "0.0" in archive_cmds due to quoting
++	    # problems, so we reset it completely
++	    verstring=
++	    ;;
++	  *)
++	    verstring="0.0"
++	    ;;
++	  esac
++	  if test "$need_version" = no; then
++	    versuffix=
++	  else
++	    versuffix=".0.0"
++	  fi
++	fi
++
++	# Remove version info from name if versioning should be avoided
++	if test "$avoid_version" = yes && test "$need_version" = no; then
++	  major=
++	  versuffix=
++	  verstring=""
++	fi
++
++	# Check to see if the archive will have undefined symbols.
++	if test "$allow_undefined" = yes; then
++	  if test "$allow_undefined_flag" = unsupported; then
++	    func_warning "undefined symbols not allowed in $host shared libraries"
++	    build_libtool_libs=no
++	    build_old_libs=yes
++	  fi
++	else
++	  # Don't allow undefined symbols.
++	  allow_undefined_flag="$no_undefined_flag"
++	fi
++
++      fi
++
++      func_generate_dlsyms "$libname" "$libname" "yes"
++      libobjs="$libobjs $symfileobj"
++      test "X$libobjs" = "X " && libobjs=
++
++      if test "$mode" != relink; then
++	# Remove our outputs, but don't remove object files since they
++	# may have been created when compiling PIC objects.
++	removelist=
++	tempremovelist=`$ECHO "$output_objdir/*"`
++	for p in $tempremovelist; do
++	  case $p in
++	    *.$objext | *.gcno)
++	       ;;
++	    $output_objdir/$outputname | $output_objdir/$libname.* | $output_objdir/${libname}${release}.*)
++	       if test "X$precious_files_regex" != "X"; then
++		 if $ECHO "$p" | $EGREP -e "$precious_files_regex" >/dev/null 2>&1
++		 then
++		   continue
++		 fi
++	       fi
++	       removelist="$removelist $p"
++	       ;;
++	    *) ;;
++	  esac
++	done
++	test -n "$removelist" && \
++	  func_show_eval "${RM}r \$removelist"
++      fi
++
++      # Now set the variables for building old libraries.
++      if test "$build_old_libs" = yes && test "$build_libtool_libs" != convenience ; then
++	oldlibs="$oldlibs $output_objdir/$libname.$libext"
++
++	# Transform .lo files to .o files.
++	oldobjs="$objs "`$ECHO "X$libobjs" | $SP2NL | $Xsed -e '/\.'${libext}'$/d' -e "$lo2o" | $NL2SP`
++      fi
++
++      # Eliminate all temporary directories.
++      #for path in $notinst_path; do
++      #	lib_search_path=`$ECHO "X$lib_search_path " | $Xsed -e "s% $path % %g"`
++      #	deplibs=`$ECHO "X$deplibs " | $Xsed -e "s% -L$path % %g"`
++      #	dependency_libs=`$ECHO "X$dependency_libs " | $Xsed -e "s% -L$path % %g"`
++      #done
++
++      if test -n "$xrpath"; then
++	# If the user specified any rpath flags, then add them.
++	temp_xrpath=
++	for libdir in $xrpath; do
++	  temp_xrpath="$temp_xrpath -R$libdir"
++	  case "$finalize_rpath " in
++	  *" $libdir "*) ;;
++	  *) finalize_rpath="$finalize_rpath $libdir" ;;
++	  esac
++	done
++	if test "$hardcode_into_libs" != yes || test "$build_old_libs" = yes; then
++	  dependency_libs="$temp_xrpath $dependency_libs"
++	fi
++      fi
++
++      # Make sure dlfiles contains only unique files that won't be dlpreopened
++      old_dlfiles="$dlfiles"
++      dlfiles=
++      for lib in $old_dlfiles; do
++	case " $dlprefiles $dlfiles " in
++	*" $lib "*) ;;
++	*) dlfiles="$dlfiles $lib" ;;
++	esac
++      done
++
++      # Make sure dlprefiles contains only unique files
++      old_dlprefiles="$dlprefiles"
++      dlprefiles=
++      for lib in $old_dlprefiles; do
++	case "$dlprefiles " in
++	*" $lib "*) ;;
++	*) dlprefiles="$dlprefiles $lib" ;;
++	esac
++      done
++
++      if test "$build_libtool_libs" = yes; then
++	if test -n "$rpath"; then
++	  case $host in
++	  *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-*-beos* | *-cegcc*)
++	    # these systems don't actually have a c library (as such)!
++	    ;;
++	  *-*-rhapsody* | *-*-darwin1.[012])
++	    # Rhapsody C library is in the System framework
++	    deplibs="$deplibs System.ltframework"
++	    ;;
++	  *-*-netbsd*)
++	    # Don't link with libc until the a.out ld.so is fixed.
++	    ;;
++	  *-*-openbsd* | *-*-freebsd* | *-*-dragonfly*)
++	    # Do not include libc due to us having libc/libc_r.
++	    ;;
++	  *-*-sco3.2v5* | *-*-sco5v6*)
++	    # Causes problems with __ctype
++	    ;;
++	  *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*)
++	    # Compiler inserts libc in the correct place for threads to work
++	    ;;
++	  *)
++	    # Add libc to deplibs on all other systems if necessary.
++	    if test "$build_libtool_need_lc" = "yes"; then
++	      deplibs="$deplibs -lc"
++	    fi
++	    ;;
++	  esac
++	fi
++
++	# Transform deplibs into only deplibs that can be linked in shared.
++	name_save=$name
++	libname_save=$libname
++	release_save=$release
++	versuffix_save=$versuffix
++	major_save=$major
++	# I'm not sure if I'm treating the release correctly.  I think
++	# release should show up in the -l (ie -lgmp5) so we don't want to
++	# add it in twice.  Is that correct?
++	release=""
++	versuffix=""
++	major=""
++	newdeplibs=
++	droppeddeps=no
++	case $deplibs_check_method in
++	pass_all)
++	  # Don't check for shared/static.  Everything works.
++	  # This might be a little naive.  We might want to check
++	  # whether the library exists or not.  But this is on
++	  # osf3 & osf4 and I'm not really sure... Just
++	  # implementing what was already the behavior.
++	  newdeplibs=$deplibs
++	  ;;
++	test_compile)
++	  # This code stresses the "libraries are programs" paradigm to its
++	  # limits. Maybe even breaks it.  We compile a program, linking it
++	  # against the deplibs as a proxy for the library.  Then we can check
++	  # whether they linked in statically or dynamically with ldd.
++	  $opt_dry_run || $RM conftest.c
++	  cat > conftest.c <<EOF
++	  int main() { return 0; }
++EOF
++	  $opt_dry_run || $RM conftest
++	  if $LTCC $LTCFLAGS -o conftest conftest.c $deplibs; then
++	    ldd_output=`ldd conftest`
++	    for i in $deplibs; do
++	      case $i in
++	      -l*)
++		func_stripname -l '' "$i"
++		name=$func_stripname_result
++		if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
++		  case " $predeps $postdeps " in
++		  *" $i "*)
++		    newdeplibs="$newdeplibs $i"
++		    i=""
++		    ;;
++		  esac
++		fi
++		if test -n "$i" ; then
++		  libname=`eval "\\$ECHO \"$libname_spec\""`
++		  deplib_matches=`eval "\\$ECHO \"$library_names_spec\""`
++		  set dummy $deplib_matches; shift
++		  deplib_match=$1
++		  if test `expr "$ldd_output" : ".*$deplib_match"` -ne 0 ; then
++		    newdeplibs="$newdeplibs $i"
++		  else
++		    droppeddeps=yes
++		    $ECHO
++		    $ECHO "*** Warning: dynamic linker does not accept needed library $i."
++		    $ECHO "*** I have the capability to make that library automatically link in when"
++		    $ECHO "*** you link to this library.  But I can only do this if you have a"
++		    $ECHO "*** shared version of the library, which I believe you do not have"
++		    $ECHO "*** because a test_compile did reveal that the linker did not use it for"
++		    $ECHO "*** its dynamic dependency list that programs get resolved with at runtime."
++		  fi
++		fi
++		;;
++	      *)
++		newdeplibs="$newdeplibs $i"
++		;;
++	      esac
++	    done
++	  else
++	    # Error occurred in the first compile.  Let's try to salvage
++	    # the situation: Compile a separate program for each library.
++	    for i in $deplibs; do
++	      case $i in
++	      -l*)
++		func_stripname -l '' "$i"
++		name=$func_stripname_result
++		$opt_dry_run || $RM conftest
++		if $LTCC $LTCFLAGS -o conftest conftest.c $i; then
++		  ldd_output=`ldd conftest`
++		  if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
++		    case " $predeps $postdeps " in
++		    *" $i "*)
++		      newdeplibs="$newdeplibs $i"
++		      i=""
++		      ;;
++		    esac
++		  fi
++		  if test -n "$i" ; then
++		    libname=`eval "\\$ECHO \"$libname_spec\""`
++		    deplib_matches=`eval "\\$ECHO \"$library_names_spec\""`
++		    set dummy $deplib_matches; shift
++		    deplib_match=$1
++		    if test `expr "$ldd_output" : ".*$deplib_match"` -ne 0 ; then
++		      newdeplibs="$newdeplibs $i"
++		    else
++		      droppeddeps=yes
++		      $ECHO
++		      $ECHO "*** Warning: dynamic linker does not accept needed library $i."
++		      $ECHO "*** I have the capability to make that library automatically link in when"
++		      $ECHO "*** you link to this library.  But I can only do this if you have a"
++		      $ECHO "*** shared version of the library, which you do not appear to have"
++		      $ECHO "*** because a test_compile did reveal that the linker did not use this one"
++		      $ECHO "*** as a dynamic dependency that programs can get resolved with at runtime."
++		    fi
++		  fi
++		else
++		  droppeddeps=yes
++		  $ECHO
++		  $ECHO "*** Warning!  Library $i is needed by this library but I was not able to"
++		  $ECHO "*** make it link in!  You will probably need to install it or some"
++		  $ECHO "*** library that it depends on before this library will be fully"
++		  $ECHO "*** functional.  Installing it before continuing would be even better."
++		fi
++		;;
++	      *)
++		newdeplibs="$newdeplibs $i"
++		;;
++	      esac
++	    done
++	  fi
++	  ;;
++	file_magic*)
++	  set dummy $deplibs_check_method; shift
++	  file_magic_regex=`expr "$deplibs_check_method" : "$1 \(.*\)"`
++	  for a_deplib in $deplibs; do
++	    case $a_deplib in
++	    -l*)
++	      func_stripname -l '' "$a_deplib"
++	      name=$func_stripname_result
++	      if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
++		case " $predeps $postdeps " in
++		*" $a_deplib "*)
++		  newdeplibs="$newdeplibs $a_deplib"
++		  a_deplib=""
++		  ;;
++		esac
++	      fi
++	      if test -n "$a_deplib" ; then
++		libname=`eval "\\$ECHO \"$libname_spec\""`
++		for i in $lib_search_path $sys_lib_search_path $shlib_search_path; do
++		  potential_libs=`ls $i/$libname[.-]* 2>/dev/null`
++		  for potent_lib in $potential_libs; do
++		      # Follow soft links.
++		      if ls -lLd "$potent_lib" 2>/dev/null |
++			 $GREP " -> " >/dev/null; then
++			continue
++		      fi
++		      # The statement above tries to avoid entering an
++		      # endless loop below, in case of cyclic links.
++		      # We might still enter an endless loop, since a link
++		      # loop can be closed while we follow links,
++		      # but so what?
++		      potlib="$potent_lib"
++		      while test -h "$potlib" 2>/dev/null; do
++			potliblink=`ls -ld $potlib | ${SED} 's/.* -> //'`
++			case $potliblink in
++			[\\/]* | [A-Za-z]:[\\/]*) potlib="$potliblink";;
++			*) potlib=`$ECHO "X$potlib" | $Xsed -e 's,[^/]*$,,'`"$potliblink";;
++			esac
++		      done
++		      if eval $file_magic_cmd \"\$potlib\" 2>/dev/null |
++			 $SED -e 10q |
++			 $EGREP "$file_magic_regex" > /dev/null; then
++			newdeplibs="$newdeplibs $a_deplib"
++			a_deplib=""
++			break 2
++		      fi
++		  done
++		done
++	      fi
++	      if test -n "$a_deplib" ; then
++		droppeddeps=yes
++		$ECHO
++		$ECHO "*** Warning: linker path does not have real file for library $a_deplib."
++		$ECHO "*** I have the capability to make that library automatically link in when"
++		$ECHO "*** you link to this library.  But I can only do this if you have a"
++		$ECHO "*** shared version of the library, which you do not appear to have"
++		$ECHO "*** because I did check the linker path looking for a file starting"
++		if test -z "$potlib" ; then
++		  $ECHO "*** with $libname but no candidates were found. (...for file magic test)"
++		else
++		  $ECHO "*** with $libname and none of the candidates passed a file format test"
++		  $ECHO "*** using a file magic. Last file checked: $potlib"
++		fi
++	      fi
++	      ;;
++	    *)
++	      # Add a -L argument.
++	      newdeplibs="$newdeplibs $a_deplib"
++	      ;;
++	    esac
++	  done # Gone through all deplibs.
++	  ;;
++	match_pattern*)
++	  set dummy $deplibs_check_method; shift
++	  match_pattern_regex=`expr "$deplibs_check_method" : "$1 \(.*\)"`
++	  for a_deplib in $deplibs; do
++	    case $a_deplib in
++	    -l*)
++	      func_stripname -l '' "$a_deplib"
++	      name=$func_stripname_result
++	      if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
++		case " $predeps $postdeps " in
++		*" $a_deplib "*)
++		  newdeplibs="$newdeplibs $a_deplib"
++		  a_deplib=""
++		  ;;
++		esac
++	      fi
++	      if test -n "$a_deplib" ; then
++		libname=`eval "\\$ECHO \"$libname_spec\""`
++		for i in $lib_search_path $sys_lib_search_path $shlib_search_path; do
++		  potential_libs=`ls $i/$libname[.-]* 2>/dev/null`
++		  for potent_lib in $potential_libs; do
++		    potlib="$potent_lib" # see symlink-check above in file_magic test
++		    if eval "\$ECHO \"X$potent_lib\"" 2>/dev/null | $Xsed -e 10q | \
++		       $EGREP "$match_pattern_regex" > /dev/null; then
++		      newdeplibs="$newdeplibs $a_deplib"
++		      a_deplib=""
++		      break 2
++		    fi
++		  done
++		done
++	      fi
++	      if test -n "$a_deplib" ; then
++		droppeddeps=yes
++		$ECHO
++		$ECHO "*** Warning: linker path does not have real file for library $a_deplib."
++		$ECHO "*** I have the capability to make that library automatically link in when"
++		$ECHO "*** you link to this library.  But I can only do this if you have a"
++		$ECHO "*** shared version of the library, which you do not appear to have"
++		$ECHO "*** because I did check the linker path looking for a file starting"
++		if test -z "$potlib" ; then
++		  $ECHO "*** with $libname but no candidates were found. (...for regex pattern test)"
++		else
++		  $ECHO "*** with $libname and none of the candidates passed a file format test"
++		  $ECHO "*** using a regex pattern. Last file checked: $potlib"
++		fi
++	      fi
++	      ;;
++	    *)
++	      # Add a -L argument.
++	      newdeplibs="$newdeplibs $a_deplib"
++	      ;;
++	    esac
++	  done # Gone through all deplibs.
++	  ;;
++	none | unknown | *)
++	  newdeplibs=""
++	  tmp_deplibs=`$ECHO "X $deplibs" | $Xsed \
++	      -e 's/ -lc$//' -e 's/ -[LR][^ ]*//g'`
++	  if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
++	    for i in $predeps $postdeps ; do
++	      # can't use Xsed below, because $i might contain '/'
++	      tmp_deplibs=`$ECHO "X $tmp_deplibs" | $Xsed -e "s,$i,,"`
++	    done
++	  fi
++	  if $ECHO "X $tmp_deplibs" | $Xsed -e 's/[	 ]//g' |
++	     $GREP . >/dev/null; then
++	    $ECHO
++	    if test "X$deplibs_check_method" = "Xnone"; then
++	      $ECHO "*** Warning: inter-library dependencies are not supported in this platform."
++	    else
++	      $ECHO "*** Warning: inter-library dependencies are not known to be supported."
++	    fi
++	    $ECHO "*** All declared inter-library dependencies are being dropped."
++	    droppeddeps=yes
++	  fi
++	  ;;
++	esac
++	versuffix=$versuffix_save
++	major=$major_save
++	release=$release_save
++	libname=$libname_save
++	name=$name_save
++
++	case $host in
++	*-*-rhapsody* | *-*-darwin1.[012])
++	  # On Rhapsody replace the C library with the System framework
++	  newdeplibs=`$ECHO "X $newdeplibs" | $Xsed -e 's/ -lc / System.ltframework /'`
++	  ;;
++	esac
++
++	if test "$droppeddeps" = yes; then
++	  if test "$module" = yes; then
++	    $ECHO
++	    $ECHO "*** Warning: libtool could not satisfy all declared inter-library"
++	    $ECHO "*** dependencies of module $libname.  Therefore, libtool will create"
++	    $ECHO "*** a static module, that should work as long as the dlopening"
++	    $ECHO "*** application is linked with the -dlopen flag."
++	    if test -z "$global_symbol_pipe"; then
++	      $ECHO
++	      $ECHO "*** However, this would only work if libtool was able to extract symbol"
++	      $ECHO "*** lists from a program, using \`nm' or equivalent, but libtool could"
++	      $ECHO "*** not find such a program.  So, this module is probably useless."
++	      $ECHO "*** \`nm' from GNU binutils and a full rebuild may help."
++	    fi
++	    if test "$build_old_libs" = no; then
++	      oldlibs="$output_objdir/$libname.$libext"
++	      build_libtool_libs=module
++	      build_old_libs=yes
++	    else
++	      build_libtool_libs=no
++	    fi
++	  else
++	    $ECHO "*** The inter-library dependencies that have been dropped here will be"
++	    $ECHO "*** automatically added whenever a program is linked with this library"
++	    $ECHO "*** or is declared to -dlopen it."
++
++	    if test "$allow_undefined" = no; then
++	      $ECHO
++	      $ECHO "*** Since this library must not contain undefined symbols,"
++	      $ECHO "*** because either the platform does not support them or"
++	      $ECHO "*** it was explicitly requested with -no-undefined,"
++	      $ECHO "*** libtool will only create a static version of it."
++	      if test "$build_old_libs" = no; then
++		oldlibs="$output_objdir/$libname.$libext"
++		build_libtool_libs=module
++		build_old_libs=yes
++	      else
++		build_libtool_libs=no
++	      fi
++	    fi
++	  fi
++	fi
++	# Done checking deplibs!
++	deplibs=$newdeplibs
++      fi
++      # Time to change all our "foo.ltframework" stuff back to "-framework foo"
++      case $host in
++	*-*-darwin*)
++	  newdeplibs=`$ECHO "X $newdeplibs" | $Xsed -e 's% \([^ $]*\).ltframework% -framework \1%g'`
++	  new_inherited_linker_flags=`$ECHO "X $new_inherited_linker_flags" | $Xsed -e 's% \([^ $]*\).ltframework% -framework \1%g'`
++	  deplibs=`$ECHO "X $deplibs" | $Xsed -e 's% \([^ $]*\).ltframework% -framework \1%g'`
++	  ;;
++      esac
++
++      # move library search paths that coincide with paths to not yet
++      # installed libraries to the beginning of the library search list
++      new_libs=
++      for path in $notinst_path; do
++	case " $new_libs " in
++	*" -L$path/$objdir "*) ;;
++	*)
++	  case " $deplibs " in
++	  *" -L$path/$objdir "*)
++	    new_libs="$new_libs -L$path/$objdir" ;;
++	  esac
++	  ;;
++	esac
++      done
++      for deplib in $deplibs; do
++	case $deplib in
++	-L*)
++	  case " $new_libs " in
++	  *" $deplib "*) ;;
++	  *) new_libs="$new_libs $deplib" ;;
++	  esac
++	  ;;
++	*) new_libs="$new_libs $deplib" ;;
++	esac
++      done
++      deplibs="$new_libs"
++
++      # All the library-specific variables (install_libdir is set above).
++      library_names=
++      old_library=
++      dlname=
++
++      # Test again, we may have decided not to build it any more
++      if test "$build_libtool_libs" = yes; then
++	if test "$hardcode_into_libs" = yes; then
++	  # Hardcode the library paths
++	  hardcode_libdirs=
++	  dep_rpath=
++	  rpath="$finalize_rpath"
++	  test "$mode" != relink && rpath="$compile_rpath$rpath"
++	  for libdir in $rpath; do
++	    if test -n "$hardcode_libdir_flag_spec"; then
++	      if test -n "$hardcode_libdir_separator"; then
++		if test -z "$hardcode_libdirs"; then
++		  hardcode_libdirs="$libdir"
++		else
++		  # Just accumulate the unique libdirs.
++		  case $hardcode_libdir_separator$hardcode_libdirs$hardcode_libdir_separator in
++		  *"$hardcode_libdir_separator$libdir$hardcode_libdir_separator"*)
++		    ;;
++		  *)
++		    hardcode_libdirs="$hardcode_libdirs$hardcode_libdir_separator$libdir"
++		    ;;
++		  esac
++		fi
++	      else
++		eval flag=\"$hardcode_libdir_flag_spec\"
++		dep_rpath="$dep_rpath $flag"
++	      fi
++	    elif test -n "$runpath_var"; then
++	      case "$perm_rpath " in
++	      *" $libdir "*) ;;
++	      *) perm_rpath="$perm_rpath $libdir" ;;
++	      esac
++	    fi
++	  done
++	  # Substitute the hardcoded libdirs into the rpath.
++	  if test -n "$hardcode_libdir_separator" &&
++	     test -n "$hardcode_libdirs"; then
++	    libdir="$hardcode_libdirs"
++	    if test -n "$hardcode_libdir_flag_spec_ld"; then
++	      eval dep_rpath=\"$hardcode_libdir_flag_spec_ld\"
++	    else
++	      eval dep_rpath=\"$hardcode_libdir_flag_spec\"
++	    fi
++	  fi
++	  if test -n "$runpath_var" && test -n "$perm_rpath"; then
++	    # We should set the runpath_var.
++	    rpath=
++	    for dir in $perm_rpath; do
++	      rpath="$rpath$dir:"
++	    done
++	    eval "$runpath_var='$rpath\$$runpath_var'; export $runpath_var"
++	  fi
++	  test -n "$dep_rpath" && deplibs="$dep_rpath $deplibs"
++	fi
++
++	shlibpath="$finalize_shlibpath"
++	test "$mode" != relink && shlibpath="$compile_shlibpath$shlibpath"
++	if test -n "$shlibpath"; then
++	  eval "$shlibpath_var='$shlibpath\$$shlibpath_var'; export $shlibpath_var"
++	fi
++
++	# Get the real and link names of the library.
++	eval shared_ext=\"$shrext_cmds\"
++	eval library_names=\"$library_names_spec\"
++	set dummy $library_names
++	shift
++	realname="$1"
++	shift
++
++	if test -n "$soname_spec"; then
++	  eval soname=\"$soname_spec\"
++	else
++	  soname="$realname"
++	fi
++	if test -z "$dlname"; then
++	  dlname=$soname
++	fi
++
++	lib="$output_objdir/$realname"
++	linknames=
++	for link
++	do
++	  linknames="$linknames $link"
++	done
++
++	# Use standard objects if they are pic
++	test -z "$pic_flag" && libobjs=`$ECHO "X$libobjs" | $SP2NL | $Xsed -e "$lo2o" | $NL2SP`
++	test "X$libobjs" = "X " && libobjs=
++
++	delfiles=
++	if test -n "$export_symbols" && test -n "$include_expsyms"; then
++	  $opt_dry_run || cp "$export_symbols" "$output_objdir/$libname.uexp"
++	  export_symbols="$output_objdir/$libname.uexp"
++	  delfiles="$delfiles $export_symbols"
++	fi
++
++	orig_export_symbols=
++	case $host_os in
++	cygwin* | mingw* | cegcc*)
++	  if test -n "$export_symbols" && test -z "$export_symbols_regex"; then
++	    # exporting using user supplied symfile
++	    if test "x`$SED 1q $export_symbols`" != xEXPORTS; then
++	      # and it's NOT already a .def file. Must figure out
++	      # which of the given symbols are data symbols and tag
++	      # them as such. So, trigger use of export_symbols_cmds.
++	      # export_symbols gets reassigned inside the "prepare
++	      # the list of exported symbols" if statement, so the
++	      # include_expsyms logic still works.
++	      orig_export_symbols="$export_symbols"
++	      export_symbols=
++	      always_export_symbols=yes
++	    fi
++	  fi
++	  ;;
++	esac
++
++	# Prepare the list of exported symbols
++	if test -z "$export_symbols"; then
++	  if test "$always_export_symbols" = yes || test -n "$export_symbols_regex"; then
++	    func_verbose "generating symbol list for \`$libname.la'"
++	    export_symbols="$output_objdir/$libname.exp"
++	    $opt_dry_run || $RM $export_symbols
++	    cmds=$export_symbols_cmds
++	    save_ifs="$IFS"; IFS='~'
++	    for cmd in $cmds; do
++	      IFS="$save_ifs"
++	      eval cmd=\"$cmd\"
++	      func_len " $cmd"
++	      len=$func_len_result
++	      if test "$len" -lt "$max_cmd_len" || test "$max_cmd_len" -le -1; then
++		func_show_eval "$cmd" 'exit $?'
++		skipped_export=false
++	      else
++		# The command line is too long to execute in one step.
++		func_verbose "using reloadable object file for export list..."
++		skipped_export=:
++		# Break out early, otherwise skipped_export may be
++		# set to false by a later but shorter cmd.
++		break
++	      fi
++	    done
++	    IFS="$save_ifs"
++	    if test -n "$export_symbols_regex" && test "X$skipped_export" != "X:"; then
++	      func_show_eval '$EGREP -e "$export_symbols_regex" "$export_symbols" > "${export_symbols}T"'
++	      func_show_eval '$MV "${export_symbols}T" "$export_symbols"'
++	    fi
++	  fi
++	fi
++
++	if test -n "$export_symbols" && test -n "$include_expsyms"; then
++	  tmp_export_symbols="$export_symbols"
++	  test -n "$orig_export_symbols" && tmp_export_symbols="$orig_export_symbols"
++	  $opt_dry_run || eval '$ECHO "X$include_expsyms" | $Xsed | $SP2NL >> "$tmp_export_symbols"'
++	fi
++
++	if test "X$skipped_export" != "X:" && test -n "$orig_export_symbols"; then
++	  # The given exports_symbols file has to be filtered, so filter it.
++	  func_verbose "filter symbol list for \`$libname.la' to tag DATA exports"
++	  # FIXME: $output_objdir/$libname.filter potentially contains lots of
++	  # 's' commands which not all seds can handle. GNU sed should be fine
++	  # though. Also, the filter scales superlinearly with the number of
++	  # global variables. join(1) would be nice here, but unfortunately
++	  # isn't a blessed tool.
++	  $opt_dry_run || $SED -e '/[ ,]DATA/!d;s,\(.*\)\([ \,].*\),s|^\1$|\1\2|,' < $export_symbols > $output_objdir/$libname.filter
++	  delfiles="$delfiles $export_symbols $output_objdir/$libname.filter"
++	  export_symbols=$output_objdir/$libname.def
++	  $opt_dry_run || $SED -f $output_objdir/$libname.filter < $orig_export_symbols > $export_symbols
++	fi
++
++	tmp_deplibs=
++	for test_deplib in $deplibs; do
++	  case " $convenience " in
++	  *" $test_deplib "*) ;;
++	  *)
++	    tmp_deplibs="$tmp_deplibs $test_deplib"
++	    ;;
++	  esac
++	done
++	deplibs="$tmp_deplibs"
++
++	if test -n "$convenience"; then
++	  if test -n "$whole_archive_flag_spec" &&
++	    test "$compiler_needs_object" = yes &&
++	    test -z "$libobjs"; then
++	    # extract the archives, so we have objects to list.
++	    # TODO: could optimize this to just extract one archive.
++	    whole_archive_flag_spec=
++	  fi
++	  if test -n "$whole_archive_flag_spec"; then
++	    save_libobjs=$libobjs
++	    eval libobjs=\"\$libobjs $whole_archive_flag_spec\"
++	    test "X$libobjs" = "X " && libobjs=
++	  else
++	    gentop="$output_objdir/${outputname}x"
++	    generated="$generated $gentop"
++
++	    func_extract_archives $gentop $convenience
++	    libobjs="$libobjs $func_extract_archives_result"
++	    test "X$libobjs" = "X " && libobjs=
++	  fi
++	fi
++
++	if test "$thread_safe" = yes && test -n "$thread_safe_flag_spec"; then
++	  eval flag=\"$thread_safe_flag_spec\"
++	  linker_flags="$linker_flags $flag"
++	fi
++
++	# Make a backup of the uninstalled library when relinking
++	if test "$mode" = relink; then
++	  $opt_dry_run || eval '(cd $output_objdir && $RM ${realname}U && $MV $realname ${realname}U)' || exit $?
++	fi
++
++	# Do each of the archive commands.
++	if test "$module" = yes && test -n "$module_cmds" ; then
++	  if test -n "$export_symbols" && test -n "$module_expsym_cmds"; then
++	    eval test_cmds=\"$module_expsym_cmds\"
++	    cmds=$module_expsym_cmds
++	  else
++	    eval test_cmds=\"$module_cmds\"
++	    cmds=$module_cmds
++	  fi
++	else
++	  if test -n "$export_symbols" && test -n "$archive_expsym_cmds"; then
++	    eval test_cmds=\"$archive_expsym_cmds\"
++	    cmds=$archive_expsym_cmds
++	  else
++	    eval test_cmds=\"$archive_cmds\"
++	    cmds=$archive_cmds
++	  fi
++	fi
++
++	if test "X$skipped_export" != "X:" &&
++	   func_len " $test_cmds" &&
++	   len=$func_len_result &&
++	   test "$len" -lt "$max_cmd_len" || test "$max_cmd_len" -le -1; then
++	  :
++	else
++	  # The command line is too long to link in one step, link piecewise
++	  # or, if using GNU ld and skipped_export is not :, use a linker
++	  # script.
++
++	  # Save the value of $output and $libobjs because we want to
++	  # use them later.  If we have whole_archive_flag_spec, we
++	  # want to use save_libobjs as it was before
++	  # whole_archive_flag_spec was expanded, because we can't
++	  # assume the linker understands whole_archive_flag_spec.
++	  # This may have to be revisited, in case too many
++	  # convenience libraries get linked in and end up exceeding
++	  # the spec.
++	  if test -z "$convenience" || test -z "$whole_archive_flag_spec"; then
++	    save_libobjs=$libobjs
++	  fi
++	  save_output=$output
++	  output_la=`$ECHO "X$output" | $Xsed -e "$basename"`
++
++	  # Clear the reloadable object creation command queue and
++	  # initialize k to one.
++	  test_cmds=
++	  concat_cmds=
++	  objlist=
++	  last_robj=
++	  k=1
++
++	  if test -n "$save_libobjs" && test "X$skipped_export" != "X:" && test "$with_gnu_ld" = yes; then
++	    output=${output_objdir}/${output_la}.lnkscript
++	    func_verbose "creating GNU ld script: $output"
++	    $ECHO 'INPUT (' > $output
++	    for obj in $save_libobjs
++	    do
++	      $ECHO "$obj" >> $output
++	    done
++	    $ECHO ')' >> $output
++	    delfiles="$delfiles $output"
++	  elif test -n "$save_libobjs" && test "X$skipped_export" != "X:" && test "X$file_list_spec" != X; then
++	    output=${output_objdir}/${output_la}.lnk
++	    func_verbose "creating linker input file list: $output"
++	    : > $output
++	    set x $save_libobjs
++	    shift
++	    firstobj=
++	    if test "$compiler_needs_object" = yes; then
++	      firstobj="$1 "
++	      shift
++	    fi
++	    for obj
++	    do
++	      $ECHO "$obj" >> $output
++	    done
++	    delfiles="$delfiles $output"
++	    output=$firstobj\"$file_list_spec$output\"
++	  else
++	    if test -n "$save_libobjs"; then
++	      func_verbose "creating reloadable object files..."
++	      output=$output_objdir/$output_la-${k}.$objext
++	      eval test_cmds=\"$reload_cmds\"
++	      func_len " $test_cmds"
++	      len0=$func_len_result
++	      len=$len0
++
++	      # Loop over the list of objects to be linked.
++	      for obj in $save_libobjs
++	      do
++		func_len " $obj"
++		func_arith $len + $func_len_result
++		len=$func_arith_result
++		if test "X$objlist" = X ||
++		   test "$len" -lt "$max_cmd_len"; then
++		  func_append objlist " $obj"
++		else
++		  # The command $test_cmds is almost too long, add a
++		  # command to the queue.
++		  if test "$k" -eq 1 ; then
++		    # The first file doesn't have a previous command to add.
++		    eval concat_cmds=\"$reload_cmds $objlist $last_robj\"
++		  else
++		    # All subsequent reloadable object files will link in
++		    # the last one created.
++		    eval concat_cmds=\"\$concat_cmds~$reload_cmds $objlist $last_robj~\$RM $last_robj\"
++		  fi
++		  last_robj=$output_objdir/$output_la-${k}.$objext
++		  func_arith $k + 1
++		  k=$func_arith_result
++		  output=$output_objdir/$output_la-${k}.$objext
++		  objlist=$obj
++		  func_len " $last_robj"
++		  func_arith $len0 + $func_len_result
++		  len=$func_arith_result
++		fi
++	      done
++	      # Handle the remaining objects by creating one last
++	      # reloadable object file.  All subsequent reloadable object
++	      # files will link in the last one created.
++	      test -z "$concat_cmds" || concat_cmds=$concat_cmds~
++	      eval concat_cmds=\"\${concat_cmds}$reload_cmds $objlist $last_robj\"
++	      if test -n "$last_robj"; then
++	        eval concat_cmds=\"\${concat_cmds}~\$RM $last_robj\"
++	      fi
++	      delfiles="$delfiles $output"
++
++	    else
++	      output=
++	    fi
++
++	    if ${skipped_export-false}; then
++	      func_verbose "generating symbol list for \`$libname.la'"
++	      export_symbols="$output_objdir/$libname.exp"
++	      $opt_dry_run || $RM $export_symbols
++	      libobjs=$output
++	      # Append the command to create the export file.
++	      test -z "$concat_cmds" || concat_cmds=$concat_cmds~
++	      eval concat_cmds=\"\$concat_cmds$export_symbols_cmds\"
++	      if test -n "$last_robj"; then
++		eval concat_cmds=\"\$concat_cmds~\$RM $last_robj\"
++	      fi
++	    fi
++
++	    test -n "$save_libobjs" &&
++	      func_verbose "creating a temporary reloadable object file: $output"
++
++	    # Loop through the commands generated above and execute them.
++	    save_ifs="$IFS"; IFS='~'
++	    for cmd in $concat_cmds; do
++	      IFS="$save_ifs"
++	      $opt_silent || {
++		  func_quote_for_expand "$cmd"
++		  eval "func_echo $func_quote_for_expand_result"
++	      }
++	      $opt_dry_run || eval "$cmd" || {
++		lt_exit=$?
++
++		# Restore the uninstalled library and exit
++		if test "$mode" = relink; then
++		  ( cd "$output_objdir" && \
++		    $RM "${realname}T" && \
++		    $MV "${realname}U" "$realname" )
++		fi
++
++		exit $lt_exit
++	      }
++	    done
++	    IFS="$save_ifs"
++
++	    if test -n "$export_symbols_regex" && ${skipped_export-false}; then
++	      func_show_eval '$EGREP -e "$export_symbols_regex" "$export_symbols" > "${export_symbols}T"'
++	      func_show_eval '$MV "${export_symbols}T" "$export_symbols"'
++	    fi
++	  fi
++
++          if ${skipped_export-false}; then
++	    if test -n "$export_symbols" && test -n "$include_expsyms"; then
++	      tmp_export_symbols="$export_symbols"
++	      test -n "$orig_export_symbols" && tmp_export_symbols="$orig_export_symbols"
++	      $opt_dry_run || eval '$ECHO "X$include_expsyms" | $Xsed | $SP2NL >> "$tmp_export_symbols"'
++	    fi
++
++	    if test -n "$orig_export_symbols"; then
++	      # The given exports_symbols file has to be filtered, so filter it.
++	      func_verbose "filter symbol list for \`$libname.la' to tag DATA exports"
++	      # FIXME: $output_objdir/$libname.filter potentially contains lots of
++	      # 's' commands which not all seds can handle. GNU sed should be fine
++	      # though. Also, the filter scales superlinearly with the number of
++	      # global variables. join(1) would be nice here, but unfortunately
++	      # isn't a blessed tool.
++	      $opt_dry_run || $SED -e '/[ ,]DATA/!d;s,\(.*\)\([ \,].*\),s|^\1$|\1\2|,' < $export_symbols > $output_objdir/$libname.filter
++	      delfiles="$delfiles $export_symbols $output_objdir/$libname.filter"
++	      export_symbols=$output_objdir/$libname.def
++	      $opt_dry_run || $SED -f $output_objdir/$libname.filter < $orig_export_symbols > $export_symbols
++	    fi
++	  fi
++
++	  libobjs=$output
++	  # Restore the value of output.
++	  output=$save_output
++
++	  if test -n "$convenience" && test -n "$whole_archive_flag_spec"; then
++	    eval libobjs=\"\$libobjs $whole_archive_flag_spec\"
++	    test "X$libobjs" = "X " && libobjs=
++	  fi
++	  # Expand the library linking commands again to reset the
++	  # value of $libobjs for piecewise linking.
++
++	  # Do each of the archive commands.
++	  if test "$module" = yes && test -n "$module_cmds" ; then
++	    if test -n "$export_symbols" && test -n "$module_expsym_cmds"; then
++	      cmds=$module_expsym_cmds
++	    else
++	      cmds=$module_cmds
++	    fi
++	  else
++	    if test -n "$export_symbols" && test -n "$archive_expsym_cmds"; then
++	      cmds=$archive_expsym_cmds
++	    else
++	      cmds=$archive_cmds
++	    fi
++	  fi
++	fi
++
++	if test -n "$delfiles"; then
++	  # Append the command to remove temporary files to $cmds.
++	  eval cmds=\"\$cmds~\$RM $delfiles\"
++	fi
++
++	# Add any objects from preloaded convenience libraries
++	if test -n "$dlprefiles"; then
++	  gentop="$output_objdir/${outputname}x"
++	  generated="$generated $gentop"
++
++	  func_extract_archives $gentop $dlprefiles
++	  libobjs="$libobjs $func_extract_archives_result"
++	  test "X$libobjs" = "X " && libobjs=
++	fi
++
++	save_ifs="$IFS"; IFS='~'
++	for cmd in $cmds; do
++	  IFS="$save_ifs"
++	  eval cmd=\"$cmd\"
++	  $opt_silent || {
++	    func_quote_for_expand "$cmd"
++	    eval "func_echo $func_quote_for_expand_result"
++	  }
++	  $opt_dry_run || eval "$cmd" || {
++	    lt_exit=$?
++
++	    # Restore the uninstalled library and exit
++	    if test "$mode" = relink; then
++	      ( cd "$output_objdir" && \
++	        $RM "${realname}T" && \
++		$MV "${realname}U" "$realname" )
++	    fi
++
++	    exit $lt_exit
++	  }
++	done
++	IFS="$save_ifs"
++
++	# Restore the uninstalled library and exit
++	if test "$mode" = relink; then
++	  $opt_dry_run || eval '(cd $output_objdir && $RM ${realname}T && $MV $realname ${realname}T && $MV ${realname}U $realname)' || exit $?
++
++	  if test -n "$convenience"; then
++	    if test -z "$whole_archive_flag_spec"; then
++	      func_show_eval '${RM}r "$gentop"'
++	    fi
++	  fi
++
++	  exit $EXIT_SUCCESS
++	fi
++
++	# Create links to the real library.
++	for linkname in $linknames; do
++	  if test "$realname" != "$linkname"; then
++	    func_show_eval '(cd "$output_objdir" && $RM "$linkname" && $LN_S "$realname" "$linkname")' 'exit $?'
++	  fi
++	done
++
++	# If -module or -export-dynamic was specified, set the dlname.
++	if test "$module" = yes || test "$export_dynamic" = yes; then
++	  # On all known operating systems, these are identical.
++	  dlname="$soname"
++	fi
++      fi
++      ;;
++
++    obj)
++      if test -n "$dlfiles$dlprefiles" || test "$dlself" != no; then
++	func_warning "\`-dlopen' is ignored for objects"
++      fi
++
++      case " $deplibs" in
++      *\ -l* | *\ -L*)
++	func_warning "\`-l' and \`-L' are ignored for objects" ;;
++      esac
++
++      test -n "$rpath" && \
++	func_warning "\`-rpath' is ignored for objects"
++
++      test -n "$xrpath" && \
++	func_warning "\`-R' is ignored for objects"
++
++      test -n "$vinfo" && \
++	func_warning "\`-version-info' is ignored for objects"
++
++      test -n "$release" && \
++	func_warning "\`-release' is ignored for objects"
++
++      case $output in
++      *.lo)
++	test -n "$objs$old_deplibs" && \
++	  func_fatal_error "cannot build library object \`$output' from non-libtool objects"
++
++	libobj=$output
++	func_lo2o "$libobj"
++	obj=$func_lo2o_result
++	;;
++      *)
++	libobj=
++	obj="$output"
++	;;
++      esac
++
++      # Delete the old objects.
++      $opt_dry_run || $RM $obj $libobj
++
++      # Objects from convenience libraries.  This assumes
++      # single-version convenience libraries.  Whenever we create
++      # different ones for PIC/non-PIC, this we'll have to duplicate
++      # the extraction.
++      reload_conv_objs=
++      gentop=
++      # reload_cmds runs $LD directly, so let us get rid of
++      # -Wl from whole_archive_flag_spec and hope we can get by with
++      # turning comma into space..
++      wl=
++
++      if test -n "$convenience"; then
++	if test -n "$whole_archive_flag_spec"; then
++	  eval tmp_whole_archive_flags=\"$whole_archive_flag_spec\"
++	  reload_conv_objs=$reload_objs\ `$ECHO "X$tmp_whole_archive_flags" | $Xsed -e 's|,| |g'`
++	else
++	  gentop="$output_objdir/${obj}x"
++	  generated="$generated $gentop"
++
++	  func_extract_archives $gentop $convenience
++	  reload_conv_objs="$reload_objs $func_extract_archives_result"
++	fi
++      fi
++
++      # Create the old-style object.
++      reload_objs="$objs$old_deplibs "`$ECHO "X$libobjs" | $SP2NL | $Xsed -e '/\.'${libext}$'/d' -e '/\.lib$/d' -e "$lo2o" | $NL2SP`" $reload_conv_objs" ### testsuite: skip nested quoting test
++
++      output="$obj"
++      func_execute_cmds "$reload_cmds" 'exit $?'
++
++      # Exit if we aren't doing a library object file.
++      if test -z "$libobj"; then
++	if test -n "$gentop"; then
++	  func_show_eval '${RM}r "$gentop"'
++	fi
++
++	exit $EXIT_SUCCESS
++      fi
++
++      if test "$build_libtool_libs" != yes; then
++	if test -n "$gentop"; then
++	  func_show_eval '${RM}r "$gentop"'
++	fi
++
++	# Create an invalid libtool object if no PIC, so that we don't
++	# accidentally link it into a program.
++	# $show "echo timestamp > $libobj"
++	# $opt_dry_run || eval "echo timestamp > $libobj" || exit $?
++	exit $EXIT_SUCCESS
++      fi
++
++      if test -n "$pic_flag" || test "$pic_mode" != default; then
++	# Only do commands if we really have different PIC objects.
++	reload_objs="$libobjs $reload_conv_objs"
++	output="$libobj"
++	func_execute_cmds "$reload_cmds" 'exit $?'
++      fi
++
++      if test -n "$gentop"; then
++	func_show_eval '${RM}r "$gentop"'
++      fi
++
++      exit $EXIT_SUCCESS
++      ;;
++
++    prog)
++      case $host in
++	*cygwin*) func_stripname '' '.exe' "$output"
++	          output=$func_stripname_result.exe;;
++      esac
++      test -n "$vinfo" && \
++	func_warning "\`-version-info' is ignored for programs"
++
++      test -n "$release" && \
++	func_warning "\`-release' is ignored for programs"
++
++      test "$preload" = yes \
++        && test "$dlopen_support" = unknown \
++	&& test "$dlopen_self" = unknown \
++	&& test "$dlopen_self_static" = unknown && \
++	  func_warning "\`LT_INIT([dlopen])' not used. Assuming no dlopen support."
++
++      case $host in
++      *-*-rhapsody* | *-*-darwin1.[012])
++	# On Rhapsody replace the C library is the System framework
++	compile_deplibs=`$ECHO "X $compile_deplibs" | $Xsed -e 's/ -lc / System.ltframework /'`
++	finalize_deplibs=`$ECHO "X $finalize_deplibs" | $Xsed -e 's/ -lc / System.ltframework /'`
++	;;
++      esac
++
++      case $host in
++      *-*-darwin*)
++	# Don't allow lazy linking, it breaks C++ global constructors
++	# But is supposedly fixed on 10.4 or later (yay!).
++	if test "$tagname" = CXX ; then
++	  case ${MACOSX_DEPLOYMENT_TARGET-10.0} in
++	    10.[0123])
++	      compile_command="$compile_command ${wl}-bind_at_load"
++	      finalize_command="$finalize_command ${wl}-bind_at_load"
++	    ;;
++	  esac
++	fi
++	# Time to change all our "foo.ltframework" stuff back to "-framework foo"
++	compile_deplibs=`$ECHO "X $compile_deplibs" | $Xsed -e 's% \([^ $]*\).ltframework% -framework \1%g'`
++	finalize_deplibs=`$ECHO "X $finalize_deplibs" | $Xsed -e 's% \([^ $]*\).ltframework% -framework \1%g'`
++	;;
++      esac
++
++
++      # move library search paths that coincide with paths to not yet
++      # installed libraries to the beginning of the library search list
++      new_libs=
++      for path in $notinst_path; do
++	case " $new_libs " in
++	*" -L$path/$objdir "*) ;;
++	*)
++	  case " $compile_deplibs " in
++	  *" -L$path/$objdir "*)
++	    new_libs="$new_libs -L$path/$objdir" ;;
++	  esac
++	  ;;
++	esac
++      done
++      for deplib in $compile_deplibs; do
++	case $deplib in
++	-L*)
++	  case " $new_libs " in
++	  *" $deplib "*) ;;
++	  *) new_libs="$new_libs $deplib" ;;
++	  esac
++	  ;;
++	*) new_libs="$new_libs $deplib" ;;
++	esac
++      done
++      compile_deplibs="$new_libs"
++
++
++      compile_command="$compile_command $compile_deplibs"
++      finalize_command="$finalize_command $finalize_deplibs"
++
++      if test -n "$rpath$xrpath"; then
++	# If the user specified any rpath flags, then add them.
++	for libdir in $rpath $xrpath; do
++	  # This is the magic to use -rpath.
++	  case "$finalize_rpath " in
++	  *" $libdir "*) ;;
++	  *) finalize_rpath="$finalize_rpath $libdir" ;;
++	  esac
++	done
++      fi
++
++      # Now hardcode the library paths
++      rpath=
++      hardcode_libdirs=
++      for libdir in $compile_rpath $finalize_rpath; do
++	if test -n "$hardcode_libdir_flag_spec"; then
++	  if test -n "$hardcode_libdir_separator"; then
++	    if test -z "$hardcode_libdirs"; then
++	      hardcode_libdirs="$libdir"
++	    else
++	      # Just accumulate the unique libdirs.
++	      case $hardcode_libdir_separator$hardcode_libdirs$hardcode_libdir_separator in
++	      *"$hardcode_libdir_separator$libdir$hardcode_libdir_separator"*)
++		;;
++	      *)
++		hardcode_libdirs="$hardcode_libdirs$hardcode_libdir_separator$libdir"
++		;;
++	      esac
++	    fi
++	  else
++	    eval flag=\"$hardcode_libdir_flag_spec\"
++	    rpath="$rpath $flag"
++	  fi
++	elif test -n "$runpath_var"; then
++	  case "$perm_rpath " in
++	  *" $libdir "*) ;;
++	  *) perm_rpath="$perm_rpath $libdir" ;;
++	  esac
++	fi
++	case $host in
++	*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-cegcc*)
++	  testbindir=`${ECHO} "$libdir" | ${SED} -e 's*/lib$*/bin*'`
++	  case :$dllsearchpath: in
++	  *":$libdir:"*) ;;
++	  ::) dllsearchpath=$libdir;;
++	  *) dllsearchpath="$dllsearchpath:$libdir";;
++	  esac
++	  case :$dllsearchpath: in
++	  *":$testbindir:"*) ;;
++	  ::) dllsearchpath=$testbindir;;
++	  *) dllsearchpath="$dllsearchpath:$testbindir";;
++	  esac
++	  ;;
++	esac
++      done
++      # Substitute the hardcoded libdirs into the rpath.
++      if test -n "$hardcode_libdir_separator" &&
++	 test -n "$hardcode_libdirs"; then
++	libdir="$hardcode_libdirs"
++	eval rpath=\" $hardcode_libdir_flag_spec\"
++      fi
++      compile_rpath="$rpath"
++
++      rpath=
++      hardcode_libdirs=
++      for libdir in $finalize_rpath; do
++	if test -n "$hardcode_libdir_flag_spec"; then
++	  if test -n "$hardcode_libdir_separator"; then
++	    if test -z "$hardcode_libdirs"; then
++	      hardcode_libdirs="$libdir"
++	    else
++	      # Just accumulate the unique libdirs.
++	      case $hardcode_libdir_separator$hardcode_libdirs$hardcode_libdir_separator in
++	      *"$hardcode_libdir_separator$libdir$hardcode_libdir_separator"*)
++		;;
++	      *)
++		hardcode_libdirs="$hardcode_libdirs$hardcode_libdir_separator$libdir"
++		;;
++	      esac
++	    fi
++	  else
++	    eval flag=\"$hardcode_libdir_flag_spec\"
++	    rpath="$rpath $flag"
++	  fi
++	elif test -n "$runpath_var"; then
++	  case "$finalize_perm_rpath " in
++	  *" $libdir "*) ;;
++	  *) finalize_perm_rpath="$finalize_perm_rpath $libdir" ;;
++	  esac
++	fi
++      done
++      # Substitute the hardcoded libdirs into the rpath.
++      if test -n "$hardcode_libdir_separator" &&
++	 test -n "$hardcode_libdirs"; then
++	libdir="$hardcode_libdirs"
++	eval rpath=\" $hardcode_libdir_flag_spec\"
++      fi
++      finalize_rpath="$rpath"
++
++      if test -n "$libobjs" && test "$build_old_libs" = yes; then
++	# Transform all the library objects into standard objects.
++	compile_command=`$ECHO "X$compile_command" | $SP2NL | $Xsed -e "$lo2o" | $NL2SP`
++	finalize_command=`$ECHO "X$finalize_command" | $SP2NL | $Xsed -e "$lo2o" | $NL2SP`
++      fi
++
++      func_generate_dlsyms "$outputname" "@PROGRAM@" "no"
++
++      # template prelinking step
++      if test -n "$prelink_cmds"; then
++	func_execute_cmds "$prelink_cmds" 'exit $?'
++      fi
++
++      wrappers_required=yes
++      case $host in
++      *cygwin* | *mingw* )
++        if test "$build_libtool_libs" != yes; then
++          wrappers_required=no
++        fi
++        ;;
++      *cegcc)
++        # Disable wrappers for cegcc, we are cross compiling anyway.
++        wrappers_required=no
++        ;;
++      *)
++        if test "$need_relink" = no || test "$build_libtool_libs" != yes; then
++          wrappers_required=no
++        fi
++        ;;
++      esac
++      if test "$wrappers_required" = no; then
++	# Replace the output file specification.
++	compile_command=`$ECHO "X$compile_command" | $Xsed -e 's%@OUTPUT@%'"$output"'%g'`
++	link_command="$compile_command$compile_rpath"
++
++	# We have no uninstalled library dependencies, so finalize right now.
++	exit_status=0
++	func_show_eval "$link_command" 'exit_status=$?'
++
++	# Delete the generated files.
++	if test -f "$output_objdir/${outputname}S.${objext}"; then
++	  func_show_eval '$RM "$output_objdir/${outputname}S.${objext}"'
++	fi
++
++	exit $exit_status
++      fi
++
++      if test -n "$compile_shlibpath$finalize_shlibpath"; then
++	compile_command="$shlibpath_var=\"$compile_shlibpath$finalize_shlibpath\$$shlibpath_var\" $compile_command"
++      fi
++      if test -n "$finalize_shlibpath"; then
++	finalize_command="$shlibpath_var=\"$finalize_shlibpath\$$shlibpath_var\" $finalize_command"
++      fi
++
++      compile_var=
++      finalize_var=
++      if test -n "$runpath_var"; then
++	if test -n "$perm_rpath"; then
++	  # We should set the runpath_var.
++	  rpath=
++	  for dir in $perm_rpath; do
++	    rpath="$rpath$dir:"
++	  done
++	  compile_var="$runpath_var=\"$rpath\$$runpath_var\" "
++	fi
++	if test -n "$finalize_perm_rpath"; then
++	  # We should set the runpath_var.
++	  rpath=
++	  for dir in $finalize_perm_rpath; do
++	    rpath="$rpath$dir:"
++	  done
++	  finalize_var="$runpath_var=\"$rpath\$$runpath_var\" "
++	fi
++      fi
++
++      if test "$no_install" = yes; then
++	# We don't need to create a wrapper script.
++	link_command="$compile_var$compile_command$compile_rpath"
++	# Replace the output file specification.
++	link_command=`$ECHO "X$link_command" | $Xsed -e 's%@OUTPUT@%'"$output"'%g'`
++	# Delete the old output file.
++	$opt_dry_run || $RM $output
++	# Link the executable and exit
++	func_show_eval "$link_command" 'exit $?'
++	exit $EXIT_SUCCESS
++      fi
++
++      if test "$hardcode_action" = relink; then
++	# Fast installation is not supported
++	link_command="$compile_var$compile_command$compile_rpath"
++	relink_command="$finalize_var$finalize_command$finalize_rpath"
++
++	func_warning "this platform does not like uninstalled shared libraries"
++	func_warning "\`$output' will be relinked during installation"
++      else
++	if test "$fast_install" != no; then
++	  link_command="$finalize_var$compile_command$finalize_rpath"
++	  if test "$fast_install" = yes; then
++	    relink_command=`$ECHO "X$compile_var$compile_command$compile_rpath" | $Xsed -e 's%@OUTPUT@%\$progdir/\$file%g'`
++	  else
++	    # fast_install is set to needless
++	    relink_command=
++	  fi
++	else
++	  link_command="$compile_var$compile_command$compile_rpath"
++	  relink_command="$finalize_var$finalize_command$finalize_rpath"
++	fi
++      fi
++
++      # Replace the output file specification.
++      link_command=`$ECHO "X$link_command" | $Xsed -e 's%@OUTPUT@%'"$output_objdir/$outputname"'%g'`
++
++      # Delete the old output files.
++      $opt_dry_run || $RM $output $output_objdir/$outputname $output_objdir/lt-$outputname
++
++      func_show_eval "$link_command" 'exit $?'
++
++      # Now create the wrapper script.
++      func_verbose "creating $output"
++
++      # Quote the relink command for shipping.
++      if test -n "$relink_command"; then
++	# Preserve any variables that may affect compiler behavior
++	for var in $variables_saved_for_relink; do
++	  if eval test -z \"\${$var+set}\"; then
++	    relink_command="{ test -z \"\${$var+set}\" || $lt_unset $var || { $var=; export $var; }; }; $relink_command"
++	  elif eval var_value=\$$var; test -z "$var_value"; then
++	    relink_command="$var=; export $var; $relink_command"
++	  else
++	    func_quote_for_eval "$var_value"
++	    relink_command="$var=$func_quote_for_eval_result; export $var; $relink_command"
++	  fi
++	done
++	relink_command="(cd `pwd`; $relink_command)"
++	relink_command=`$ECHO "X$relink_command" | $Xsed -e "$sed_quote_subst"`
++      fi
++
++      # Quote $ECHO for shipping.
++      if test "X$ECHO" = "X$SHELL $progpath --fallback-echo"; then
++	case $progpath in
++	[\\/]* | [A-Za-z]:[\\/]*) qecho="$SHELL $progpath --fallback-echo";;
++	*) qecho="$SHELL `pwd`/$progpath --fallback-echo";;
++	esac
++	qecho=`$ECHO "X$qecho" | $Xsed -e "$sed_quote_subst"`
++      else
++	qecho=`$ECHO "X$ECHO" | $Xsed -e "$sed_quote_subst"`
++      fi
++
++      # Only actually do things if not in dry run mode.
++      $opt_dry_run || {
++	# win32 will think the script is a binary if it has
++	# a .exe suffix, so we strip it off here.
++	case $output in
++	  *.exe) func_stripname '' '.exe' "$output"
++	         output=$func_stripname_result ;;
++	esac
++	# test for cygwin because mv fails w/o .exe extensions
++	case $host in
++	  *cygwin*)
++	    exeext=.exe
++	    func_stripname '' '.exe' "$outputname"
++	    outputname=$func_stripname_result ;;
++	  *) exeext= ;;
++	esac
++	case $host in
++	  *cygwin* | *mingw* )
++	    func_dirname_and_basename "$output" "" "."
++	    output_name=$func_basename_result
++	    output_path=$func_dirname_result
++	    cwrappersource="$output_path/$objdir/lt-$output_name.c"
++	    cwrapper="$output_path/$output_name.exe"
++	    $RM $cwrappersource $cwrapper
++	    trap "$RM $cwrappersource $cwrapper; exit $EXIT_FAILURE" 1 2 15
++
++	    func_emit_cwrapperexe_src > $cwrappersource
++
++	    # The wrapper executable is built using the $host compiler,
++	    # because it contains $host paths and files. If cross-
++	    # compiling, it, like the target executable, must be
++	    # executed on the $host or under an emulation environment.
++	    $opt_dry_run || {
++	      $LTCC $LTCFLAGS -o $cwrapper $cwrappersource
++	      $STRIP $cwrapper
++	    }
++
++	    # Now, create the wrapper script for func_source use:
++	    func_ltwrapper_scriptname $cwrapper
++	    $RM $func_ltwrapper_scriptname_result
++	    trap "$RM $func_ltwrapper_scriptname_result; exit $EXIT_FAILURE" 1 2 15
++	    $opt_dry_run || {
++	      # note: this script will not be executed, so do not chmod.
++	      if test "x$build" = "x$host" ; then
++		$cwrapper --lt-dump-script > $func_ltwrapper_scriptname_result
++	      else
++		func_emit_wrapper no > $func_ltwrapper_scriptname_result
++	      fi
++	    }
++	  ;;
++	  * )
++	    $RM $output
++	    trap "$RM $output; exit $EXIT_FAILURE" 1 2 15
++
++	    func_emit_wrapper no > $output
++	    chmod +x $output
++	  ;;
++	esac
++      }
++      exit $EXIT_SUCCESS
++      ;;
++    esac
++
++    # See if we need to build an old-fashioned archive.
++    for oldlib in $oldlibs; do
++
++      if test "$build_libtool_libs" = convenience; then
++	oldobjs="$libobjs_save $symfileobj"
++	addlibs="$convenience"
++	build_libtool_libs=no
++      else
++	if test "$build_libtool_libs" = module; then
++	  oldobjs="$libobjs_save"
++	  build_libtool_libs=no
++	else
++	  oldobjs="$old_deplibs $non_pic_objects"
++	  if test "$preload" = yes && test -f "$symfileobj"; then
++	    oldobjs="$oldobjs $symfileobj"
++	  fi
++	fi
++	addlibs="$old_convenience"
++      fi
++
++      if test -n "$addlibs"; then
++	gentop="$output_objdir/${outputname}x"
++	generated="$generated $gentop"
++
++	func_extract_archives $gentop $addlibs
++	oldobjs="$oldobjs $func_extract_archives_result"
++      fi
++
++      # Do each command in the archive commands.
++      if test -n "$old_archive_from_new_cmds" && test "$build_libtool_libs" = yes; then
++	cmds=$old_archive_from_new_cmds
++      else
++
++	# Add any objects from preloaded convenience libraries
++	if test -n "$dlprefiles"; then
++	  gentop="$output_objdir/${outputname}x"
++	  generated="$generated $gentop"
++
++	  func_extract_archives $gentop $dlprefiles
++	  oldobjs="$oldobjs $func_extract_archives_result"
++	fi
++
++	# POSIX demands no paths to be encoded in archives.  We have
++	# to avoid creating archives with duplicate basenames if we
++	# might have to extract them afterwards, e.g., when creating a
++	# static archive out of a convenience library, or when linking
++	# the entirety of a libtool archive into another (currently
++	# not supported by libtool).
++	if (for obj in $oldobjs
++	    do
++	      func_basename "$obj"
++	      $ECHO "$func_basename_result"
++	    done | sort | sort -uc >/dev/null 2>&1); then
++	  :
++	else
++	  $ECHO "copying selected object files to avoid basename conflicts..."
++	  gentop="$output_objdir/${outputname}x"
++	  generated="$generated $gentop"
++	  func_mkdir_p "$gentop"
++	  save_oldobjs=$oldobjs
++	  oldobjs=
++	  counter=1
++	  for obj in $save_oldobjs
++	  do
++	    func_basename "$obj"
++	    objbase="$func_basename_result"
++	    case " $oldobjs " in
++	    " ") oldobjs=$obj ;;
++	    *[\ /]"$objbase "*)
++	      while :; do
++		# Make sure we don't pick an alternate name that also
++		# overlaps.
++		newobj=lt$counter-$objbase
++		func_arith $counter + 1
++		counter=$func_arith_result
++		case " $oldobjs " in
++		*[\ /]"$newobj "*) ;;
++		*) if test ! -f "$gentop/$newobj"; then break; fi ;;
++		esac
++	      done
++	      func_show_eval "ln $obj $gentop/$newobj || cp $obj $gentop/$newobj"
++	      oldobjs="$oldobjs $gentop/$newobj"
++	      ;;
++	    *) oldobjs="$oldobjs $obj" ;;
++	    esac
++	  done
++	fi
++	eval cmds=\"$old_archive_cmds\"
++
++	func_len " $cmds"
++	len=$func_len_result
++	if test "$len" -lt "$max_cmd_len" || test "$max_cmd_len" -le -1; then
++	  cmds=$old_archive_cmds
++	else
++	  # the command line is too long to link in one step, link in parts
++	  func_verbose "using piecewise archive linking..."
++	  save_RANLIB=$RANLIB
++	  RANLIB=:
++	  objlist=
++	  concat_cmds=
++	  save_oldobjs=$oldobjs
++	  oldobjs=
++	  # Is there a better way of finding the last object in the list?
++	  for obj in $save_oldobjs
++	  do
++	    last_oldobj=$obj
++	  done
++	  eval test_cmds=\"$old_archive_cmds\"
++	  func_len " $test_cmds"
++	  len0=$func_len_result
++	  len=$len0
++	  for obj in $save_oldobjs
++	  do
++	    func_len " $obj"
++	    func_arith $len + $func_len_result
++	    len=$func_arith_result
++	    func_append objlist " $obj"
++	    if test "$len" -lt "$max_cmd_len"; then
++	      :
++	    else
++	      # the above command should be used before it gets too long
++	      oldobjs=$objlist
++	      if test "$obj" = "$last_oldobj" ; then
++		RANLIB=$save_RANLIB
++	      fi
++	      test -z "$concat_cmds" || concat_cmds=$concat_cmds~
++	      eval concat_cmds=\"\${concat_cmds}$old_archive_cmds\"
++	      objlist=
++	      len=$len0
++	    fi
++	  done
++	  RANLIB=$save_RANLIB
++	  oldobjs=$objlist
++	  if test "X$oldobjs" = "X" ; then
++	    eval cmds=\"\$concat_cmds\"
++	  else
++	    eval cmds=\"\$concat_cmds~\$old_archive_cmds\"
++	  fi
++	fi
++      fi
++      func_execute_cmds "$cmds" 'exit $?'
++    done
++
++    test -n "$generated" && \
++      func_show_eval "${RM}r$generated"
++
++    # Now create the libtool archive.
++    case $output in
++    *.la)
++      old_library=
++      test "$build_old_libs" = yes && old_library="$libname.$libext"
++      func_verbose "creating $output"
++
++      # Preserve any variables that may affect compiler behavior
++      for var in $variables_saved_for_relink; do
++	if eval test -z \"\${$var+set}\"; then
++	  relink_command="{ test -z \"\${$var+set}\" || $lt_unset $var || { $var=; export $var; }; }; $relink_command"
++	elif eval var_value=\$$var; test -z "$var_value"; then
++	  relink_command="$var=; export $var; $relink_command"
++	else
++	  func_quote_for_eval "$var_value"
++	  relink_command="$var=$func_quote_for_eval_result; export $var; $relink_command"
++	fi
++      done
++      # Quote the link command for shipping.
++      relink_command="(cd `pwd`; $SHELL $progpath $preserve_args --mode=relink $libtool_args @inst_prefix_dir@)"
++      relink_command=`$ECHO "X$relink_command" | $Xsed -e "$sed_quote_subst"`
++      if test "$hardcode_automatic" = yes ; then
++	relink_command=
++      fi
++
++      # Only create the output if not a dry run.
++      $opt_dry_run || {
++	for installed in no yes; do
++	  if test "$installed" = yes; then
++	    if test -z "$install_libdir"; then
++	      break
++	    fi
++	    output="$output_objdir/$outputname"i
++	    # Replace all uninstalled libtool libraries with the installed ones
++	    newdependency_libs=
++	    for deplib in $dependency_libs; do
++	      case $deplib in
++	      *.la)
++		func_basename "$deplib"
++		name="$func_basename_result"
++		eval libdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $deplib`
++		test -z "$libdir" && \
++		  func_fatal_error "\`$deplib' is not a valid libtool archive"
++		newdependency_libs="$newdependency_libs $libdir/$name"
++		;;
++	      *) newdependency_libs="$newdependency_libs $deplib" ;;
++	      esac
++	    done
++	    dependency_libs="$newdependency_libs"
++	    newdlfiles=
++
++	    for lib in $dlfiles; do
++	      case $lib in
++	      *.la)
++	        func_basename "$lib"
++		name="$func_basename_result"
++		eval libdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $lib`
++		test -z "$libdir" && \
++		  func_fatal_error "\`$lib' is not a valid libtool archive"
++		newdlfiles="$newdlfiles $libdir/$name"
++		;;
++	      *) newdlfiles="$newdlfiles $lib" ;;
++	      esac
++	    done
++	    dlfiles="$newdlfiles"
++	    newdlprefiles=
++	    for lib in $dlprefiles; do
++	      case $lib in
++	      *.la)
++		# Only pass preopened files to the pseudo-archive (for
++		# eventual linking with the app. that links it) if we
++		# didn't already link the preopened objects directly into
++		# the library:
++		func_basename "$lib"
++		name="$func_basename_result"
++		eval libdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $lib`
++		test -z "$libdir" && \
++		  func_fatal_error "\`$lib' is not a valid libtool archive"
++		newdlprefiles="$newdlprefiles $libdir/$name"
++		;;
++	      esac
++	    done
++	    dlprefiles="$newdlprefiles"
++	  else
++	    newdlfiles=
++	    for lib in $dlfiles; do
++	      case $lib in
++		[\\/]* | [A-Za-z]:[\\/]*) abs="$lib" ;;
++		*) abs=`pwd`"/$lib" ;;
++	      esac
++	      newdlfiles="$newdlfiles $abs"
++	    done
++	    dlfiles="$newdlfiles"
++	    newdlprefiles=
++	    for lib in $dlprefiles; do
++	      case $lib in
++		[\\/]* | [A-Za-z]:[\\/]*) abs="$lib" ;;
++		*) abs=`pwd`"/$lib" ;;
++	      esac
++	      newdlprefiles="$newdlprefiles $abs"
++	    done
++	    dlprefiles="$newdlprefiles"
++	  fi
++	  $RM $output
++	  # place dlname in correct position for cygwin
++	  tdlname=$dlname
++	  case $host,$output,$installed,$module,$dlname in
++	    *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) tdlname=../bin/$dlname ;;
++	  esac
++	  $ECHO > $output "\
++# $outputname - a libtool library file
++# Generated by $PROGRAM (GNU $PACKAGE$TIMESTAMP) $VERSION
++#
++# Please DO NOT delete this file!
++# It is necessary for linking the library.
++
++# The name that we can dlopen(3).
++dlname='$tdlname'
++
++# Names of this library.
++library_names='$library_names'
++
++# The name of the static archive.
++old_library='$old_library'
++
++# Linker flags that can not go in dependency_libs.
++inherited_linker_flags='$new_inherited_linker_flags'
++
++# Libraries that this one depends upon.
++dependency_libs='$dependency_libs'
++
++# Names of additional weak libraries provided by this library
++weak_library_names='$weak_libs'
++
++# Version information for $libname.
++current=$current
++age=$age
++revision=$revision
++
++# Is this an already installed library?
++installed=$installed
++
++# Should we warn about portability when linking against -modules?
++shouldnotlink=$module
++
++# Files to dlopen/dlpreopen
++dlopen='$dlfiles'
++dlpreopen='$dlprefiles'
++
++# Directory that this library needs to be installed in:
++libdir='$install_libdir'"
++	  if test "$installed" = no && test "$need_relink" = yes; then
++	    $ECHO >> $output "\
++relink_command=\"$relink_command\""
++	  fi
++	done
++      }
++
++      # Do a symbolic link so that the libtool archive can be found in
++      # LD_LIBRARY_PATH before the program is installed.
++      func_show_eval '( cd "$output_objdir" && $RM "$outputname" && $LN_S "../$outputname" "$outputname" )' 'exit $?'
++      ;;
++    esac
++    exit $EXIT_SUCCESS
++}
++
++{ test "$mode" = link || test "$mode" = relink; } &&
++    func_mode_link ${1+"$@"}
++
++
++# func_mode_uninstall arg...
++func_mode_uninstall ()
++{
++    $opt_debug
++    RM="$nonopt"
++    files=
++    rmforce=
++    exit_status=0
++
++    # This variable tells wrapper scripts just to set variables rather
++    # than running their programs.
++    libtool_install_magic="$magic"
++
++    for arg
++    do
++      case $arg in
++      -f) RM="$RM $arg"; rmforce=yes ;;
++      -*) RM="$RM $arg" ;;
++      *) files="$files $arg" ;;
++      esac
++    done
++
++    test -z "$RM" && \
++      func_fatal_help "you must specify an RM program"
++
++    rmdirs=
++
++    origobjdir="$objdir"
++    for file in $files; do
++      func_dirname "$file" "" "."
++      dir="$func_dirname_result"
++      if test "X$dir" = X.; then
++	objdir="$origobjdir"
++      else
++	objdir="$dir/$origobjdir"
++      fi
++      func_basename "$file"
++      name="$func_basename_result"
++      test "$mode" = uninstall && objdir="$dir"
++
++      # Remember objdir for removal later, being careful to avoid duplicates
++      if test "$mode" = clean; then
++	case " $rmdirs " in
++	  *" $objdir "*) ;;
++	  *) rmdirs="$rmdirs $objdir" ;;
++	esac
++      fi
++
++      # Don't error if the file doesn't exist and rm -f was used.
++      if { test -L "$file"; } >/dev/null 2>&1 ||
++	 { test -h "$file"; } >/dev/null 2>&1 ||
++	 test -f "$file"; then
++	:
++      elif test -d "$file"; then
++	exit_status=1
++	continue
++      elif test "$rmforce" = yes; then
++	continue
++      fi
++
++      rmfiles="$file"
++
++      case $name in
++      *.la)
++	# Possibly a libtool archive, so verify it.
++	if func_lalib_p "$file"; then
++	  func_source $dir/$name
++
++	  # Delete the libtool libraries and symlinks.
++	  for n in $library_names; do
++	    rmfiles="$rmfiles $objdir/$n"
++	  done
++	  test -n "$old_library" && rmfiles="$rmfiles $objdir/$old_library"
++
++	  case "$mode" in
++	  clean)
++	    case "  $library_names " in
++	    # "  " in the beginning catches empty $dlname
++	    *" $dlname "*) ;;
++	    *) rmfiles="$rmfiles $objdir/$dlname" ;;
++	    esac
++	    test -n "$libdir" && rmfiles="$rmfiles $objdir/$name $objdir/${name}i"
++	    ;;
++	  uninstall)
++	    if test -n "$library_names"; then
++	      # Do each command in the postuninstall commands.
++	      func_execute_cmds "$postuninstall_cmds" 'test "$rmforce" = yes || exit_status=1'
++	    fi
++
++	    if test -n "$old_library"; then
++	      # Do each command in the old_postuninstall commands.
++	      func_execute_cmds "$old_postuninstall_cmds" 'test "$rmforce" = yes || exit_status=1'
++	    fi
++	    # FIXME: should reinstall the best remaining shared library.
++	    ;;
++	  esac
++	fi
++	;;
++
++      *.lo)
++	# Possibly a libtool object, so verify it.
++	if func_lalib_p "$file"; then
++
++	  # Read the .lo file
++	  func_source $dir/$name
++
++	  # Add PIC object to the list of files to remove.
++	  if test -n "$pic_object" &&
++	     test "$pic_object" != none; then
++	    rmfiles="$rmfiles $dir/$pic_object"
++	  fi
++
++	  # Add non-PIC object to the list of files to remove.
++	  if test -n "$non_pic_object" &&
++	     test "$non_pic_object" != none; then
++	    rmfiles="$rmfiles $dir/$non_pic_object"
++	  fi
++	fi
++	;;
++
++      *)
++	if test "$mode" = clean ; then
++	  noexename=$name
++	  case $file in
++	  *.exe)
++	    func_stripname '' '.exe' "$file"
++	    file=$func_stripname_result
++	    func_stripname '' '.exe' "$name"
++	    noexename=$func_stripname_result
++	    # $file with .exe has already been added to rmfiles,
++	    # add $file without .exe
++	    rmfiles="$rmfiles $file"
++	    ;;
++	  esac
++	  # Do a test to see if this is a libtool program.
++	  if func_ltwrapper_p "$file"; then
++	    if func_ltwrapper_executable_p "$file"; then
++	      func_ltwrapper_scriptname "$file"
++	      relink_command=
++	      func_source $func_ltwrapper_scriptname_result
++	      rmfiles="$rmfiles $func_ltwrapper_scriptname_result"
++	    else
++	      relink_command=
++	      func_source $dir/$noexename
++	    fi
++
++	    # note $name still contains .exe if it was in $file originally
++	    # as does the version of $file that was added into $rmfiles
++	    rmfiles="$rmfiles $objdir/$name $objdir/${name}S.${objext}"
++	    if test "$fast_install" = yes && test -n "$relink_command"; then
++	      rmfiles="$rmfiles $objdir/lt-$name"
++	    fi
++	    if test "X$noexename" != "X$name" ; then
++	      rmfiles="$rmfiles $objdir/lt-${noexename}.c"
++	    fi
++	  fi
++	fi
++	;;
++      esac
++      func_show_eval "$RM $rmfiles" 'exit_status=1'
++    done
++    objdir="$origobjdir"
++
++    # Try to remove the ${objdir}s in the directories where we deleted files
++    for dir in $rmdirs; do
++      if test -d "$dir"; then
++	func_show_eval "rmdir $dir >/dev/null 2>&1"
++      fi
++    done
++
++    exit $exit_status
++}
++
++{ test "$mode" = uninstall || test "$mode" = clean; } &&
++    func_mode_uninstall ${1+"$@"}
++
++test -z "$mode" && {
++  help="$generic_help"
++  func_fatal_help "you must specify a MODE"
++}
++
++test -z "$exec_cmd" && \
++  func_fatal_help "invalid operation mode \`$mode'"
++
++if test -n "$exec_cmd"; then
++  eval exec "$exec_cmd"
++  exit $EXIT_FAILURE
++fi
++
++exit $exit_status
++
++
++# The TAGs below are defined such that we never get into a situation
++# in which we disable both kinds of libraries.  Given conflicting
++# choices, we go for a static library, that is the most portable,
++# since we can't tell whether shared libraries were disabled because
++# the user asked for that or because the platform doesn't support
++# them.  This is particularly important on AIX, because we don't
++# support having both static and shared libraries enabled at the same
++# time on that platform, so we default to a shared-only configuration.
++# If a disable-shared tag is given, we'll fallback to a static-only
++# configuration.  But we'll never go from static-only to shared-only.
++
++# ### BEGIN LIBTOOL TAG CONFIG: disable-shared
++build_libtool_libs=no
++build_old_libs=yes
++# ### END LIBTOOL TAG CONFIG: disable-shared
++
++# ### BEGIN LIBTOOL TAG CONFIG: disable-static
++build_old_libs=`case $build_libtool_libs in yes) echo no;; *) echo yes;; esac`
++# ### END LIBTOOL TAG CONFIG: disable-static
++
++# Local Variables:
++# mode:shell-script
++# sh-indentation:2
++# End:
++# vi:sw=2
++
+Index: git/missing
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/missing	2010-12-29 04:04:06.000000000 +0100
+@@ -0,0 +1,376 @@
++#! /bin/sh
++# Common stub for a few missing GNU programs while installing.
++
++scriptversion=2009-04-28.21; # UTC
++
++# Copyright (C) 1996, 1997, 1999, 2000, 2002, 2003, 2004, 2005, 2006,
++# 2008, 2009 Free Software Foundation, Inc.
++# Originally by Fran,cois Pinard <pinard@iro.umontreal.ca>, 1996.
++
++# This program is free software; you can redistribute it and/or modify
++# it under the terms of the GNU General Public License as published by
++# the Free Software Foundation; either version 2, or (at your option)
++# any later version.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY; without even the implied warranty of
++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++# GNU General Public License for more details.
++
++# You should have received a copy of the GNU General Public License
++# along with this program.  If not, see <http://www.gnu.org/licenses/>.
++
++# As a special exception to the GNU General Public License, if you
++# distribute this file as part of a program that contains a
++# configuration script generated by Autoconf, you may include it under
++# the same distribution terms that you use for the rest of that program.
++
++if test $# -eq 0; then
++  echo 1>&2 "Try \`$0 --help' for more information"
++  exit 1
++fi
++
++run=:
++sed_output='s/.* --output[ =]\([^ ]*\).*/\1/p'
++sed_minuso='s/.* -o \([^ ]*\).*/\1/p'
++
++# In the cases where this matters, `missing' is being run in the
++# srcdir already.
++if test -f configure.ac; then
++  configure_ac=configure.ac
++else
++  configure_ac=configure.in
++fi
++
++msg="missing on your system"
++
++case $1 in
++--run)
++  # Try to run requested program, and just exit if it succeeds.
++  run=
++  shift
++  "$@" && exit 0
++  # Exit code 63 means version mismatch.  This often happens
++  # when the user try to use an ancient version of a tool on
++  # a file that requires a minimum version.  In this case we
++  # we should proceed has if the program had been absent, or
++  # if --run hadn't been passed.
++  if test $? = 63; then
++    run=:
++    msg="probably too old"
++  fi
++  ;;
++
++  -h|--h|--he|--hel|--help)
++    echo "\
++$0 [OPTION]... PROGRAM [ARGUMENT]...
++
++Handle \`PROGRAM [ARGUMENT]...' for when PROGRAM is missing, or return an
++error status if there is no known handling for PROGRAM.
++
++Options:
++  -h, --help      display this help and exit
++  -v, --version   output version information and exit
++  --run           try to run the given command, and emulate it if it fails
++
++Supported PROGRAM values:
++  aclocal      touch file \`aclocal.m4'
++  autoconf     touch file \`configure'
++  autoheader   touch file \`config.h.in'
++  autom4te     touch the output file, or create a stub one
++  automake     touch all \`Makefile.in' files
++  bison        create \`y.tab.[ch]', if possible, from existing .[ch]
++  flex         create \`lex.yy.c', if possible, from existing .c
++  help2man     touch the output file
++  lex          create \`lex.yy.c', if possible, from existing .c
++  makeinfo     touch the output file
++  tar          try tar, gnutar, gtar, then tar without non-portable flags
++  yacc         create \`y.tab.[ch]', if possible, from existing .[ch]
++
++Version suffixes to PROGRAM as well as the prefixes \`gnu-', \`gnu', and
++\`g' are ignored when checking the name.
++
++Send bug reports to <bug-automake@gnu.org>."
++    exit $?
++    ;;
++
++  -v|--v|--ve|--ver|--vers|--versi|--versio|--version)
++    echo "missing $scriptversion (GNU Automake)"
++    exit $?
++    ;;
++
++  -*)
++    echo 1>&2 "$0: Unknown \`$1' option"
++    echo 1>&2 "Try \`$0 --help' for more information"
++    exit 1
++    ;;
++
++esac
++
++# normalize program name to check for.
++program=`echo "$1" | sed '
++  s/^gnu-//; t
++  s/^gnu//; t
++  s/^g//; t'`
++
++# Now exit if we have it, but it failed.  Also exit now if we
++# don't have it and --version was passed (most likely to detect
++# the program).  This is about non-GNU programs, so use $1 not
++# $program.
++case $1 in
++  lex*|yacc*)
++    # Not GNU programs, they don't have --version.
++    ;;
++
++  tar*)
++    if test -n "$run"; then
++       echo 1>&2 "ERROR: \`tar' requires --run"
++       exit 1
++    elif test "x$2" = "x--version" || test "x$2" = "x--help"; then
++       exit 1
++    fi
++    ;;
++
++  *)
++    if test -z "$run" && ($1 --version) > /dev/null 2>&1; then
++       # We have it, but it failed.
++       exit 1
++    elif test "x$2" = "x--version" || test "x$2" = "x--help"; then
++       # Could not run --version or --help.  This is probably someone
++       # running `$TOOL --version' or `$TOOL --help' to check whether
++       # $TOOL exists and not knowing $TOOL uses missing.
++       exit 1
++    fi
++    ;;
++esac
++
++# If it does not exist, or fails to run (possibly an outdated version),
++# try to emulate it.
++case $program in
++  aclocal*)
++    echo 1>&2 "\
++WARNING: \`$1' is $msg.  You should only need it if
++         you modified \`acinclude.m4' or \`${configure_ac}'.  You might want
++         to install the \`Automake' and \`Perl' packages.  Grab them from
++         any GNU archive site."
++    touch aclocal.m4
++    ;;
++
++  autoconf*)
++    echo 1>&2 "\
++WARNING: \`$1' is $msg.  You should only need it if
++         you modified \`${configure_ac}'.  You might want to install the
++         \`Autoconf' and \`GNU m4' packages.  Grab them from any GNU
++         archive site."
++    touch configure
++    ;;
++
++  autoheader*)
++    echo 1>&2 "\
++WARNING: \`$1' is $msg.  You should only need it if
++         you modified \`acconfig.h' or \`${configure_ac}'.  You might want
++         to install the \`Autoconf' and \`GNU m4' packages.  Grab them
++         from any GNU archive site."
++    files=`sed -n 's/^[ ]*A[CM]_CONFIG_HEADER(\([^)]*\)).*/\1/p' ${configure_ac}`
++    test -z "$files" && files="config.h"
++    touch_files=
++    for f in $files; do
++      case $f in
++      *:*) touch_files="$touch_files "`echo "$f" |
++				       sed -e 's/^[^:]*://' -e 's/:.*//'`;;
++      *) touch_files="$touch_files $f.in";;
++      esac
++    done
++    touch $touch_files
++    ;;
++
++  automake*)
++    echo 1>&2 "\
++WARNING: \`$1' is $msg.  You should only need it if
++         you modified \`Makefile.am', \`acinclude.m4' or \`${configure_ac}'.
++         You might want to install the \`Automake' and \`Perl' packages.
++         Grab them from any GNU archive site."
++    find . -type f -name Makefile.am -print |
++	   sed 's/\.am$/.in/' |
++	   while read f; do touch "$f"; done
++    ;;
++
++  autom4te*)
++    echo 1>&2 "\
++WARNING: \`$1' is needed, but is $msg.
++         You might have modified some files without having the
++         proper tools for further handling them.
++         You can get \`$1' as part of \`Autoconf' from any GNU
++         archive site."
++
++    file=`echo "$*" | sed -n "$sed_output"`
++    test -z "$file" && file=`echo "$*" | sed -n "$sed_minuso"`
++    if test -f "$file"; then
++	touch $file
++    else
++	test -z "$file" || exec >$file
++	echo "#! /bin/sh"
++	echo "# Created by GNU Automake missing as a replacement of"
++	echo "#  $ $@"
++	echo "exit 0"
++	chmod +x $file
++	exit 1
++    fi
++    ;;
++
++  bison*|yacc*)
++    echo 1>&2 "\
++WARNING: \`$1' $msg.  You should only need it if
++         you modified a \`.y' file.  You may need the \`Bison' package
++         in order for those modifications to take effect.  You can get
++         \`Bison' from any GNU archive site."
++    rm -f y.tab.c y.tab.h
++    if test $# -ne 1; then
++        eval LASTARG="\${$#}"
++	case $LASTARG in
++	*.y)
++	    SRCFILE=`echo "$LASTARG" | sed 's/y$/c/'`
++	    if test -f "$SRCFILE"; then
++	         cp "$SRCFILE" y.tab.c
++	    fi
++	    SRCFILE=`echo "$LASTARG" | sed 's/y$/h/'`
++	    if test -f "$SRCFILE"; then
++	         cp "$SRCFILE" y.tab.h
++	    fi
++	  ;;
++	esac
++    fi
++    if test ! -f y.tab.h; then
++	echo >y.tab.h
++    fi
++    if test ! -f y.tab.c; then
++	echo 'main() { return 0; }' >y.tab.c
++    fi
++    ;;
++
++  lex*|flex*)
++    echo 1>&2 "\
++WARNING: \`$1' is $msg.  You should only need it if
++         you modified a \`.l' file.  You may need the \`Flex' package
++         in order for those modifications to take effect.  You can get
++         \`Flex' from any GNU archive site."
++    rm -f lex.yy.c
++    if test $# -ne 1; then
++        eval LASTARG="\${$#}"
++	case $LASTARG in
++	*.l)
++	    SRCFILE=`echo "$LASTARG" | sed 's/l$/c/'`
++	    if test -f "$SRCFILE"; then
++	         cp "$SRCFILE" lex.yy.c
++	    fi
++	  ;;
++	esac
++    fi
++    if test ! -f lex.yy.c; then
++	echo 'main() { return 0; }' >lex.yy.c
++    fi
++    ;;
++
++  help2man*)
++    echo 1>&2 "\
++WARNING: \`$1' is $msg.  You should only need it if
++	 you modified a dependency of a manual page.  You may need the
++	 \`Help2man' package in order for those modifications to take
++	 effect.  You can get \`Help2man' from any GNU archive site."
++
++    file=`echo "$*" | sed -n "$sed_output"`
++    test -z "$file" && file=`echo "$*" | sed -n "$sed_minuso"`
++    if test -f "$file"; then
++	touch $file
++    else
++	test -z "$file" || exec >$file
++	echo ".ab help2man is required to generate this page"
++	exit $?
++    fi
++    ;;
++
++  makeinfo*)
++    echo 1>&2 "\
++WARNING: \`$1' is $msg.  You should only need it if
++         you modified a \`.texi' or \`.texinfo' file, or any other file
++         indirectly affecting the aspect of the manual.  The spurious
++         call might also be the consequence of using a buggy \`make' (AIX,
++         DU, IRIX).  You might want to install the \`Texinfo' package or
++         the \`GNU make' package.  Grab either from any GNU archive site."
++    # The file to touch is that specified with -o ...
++    file=`echo "$*" | sed -n "$sed_output"`
++    test -z "$file" && file=`echo "$*" | sed -n "$sed_minuso"`
++    if test -z "$file"; then
++      # ... or it is the one specified with @setfilename ...
++      infile=`echo "$*" | sed 's/.* \([^ ]*\) *$/\1/'`
++      file=`sed -n '
++	/^@setfilename/{
++	  s/.* \([^ ]*\) *$/\1/
++	  p
++	  q
++	}' $infile`
++      # ... or it is derived from the source name (dir/f.texi becomes f.info)
++      test -z "$file" && file=`echo "$infile" | sed 's,.*/,,;s,.[^.]*$,,'`.info
++    fi
++    # If the file does not exist, the user really needs makeinfo;
++    # let's fail without touching anything.
++    test -f $file || exit 1
++    touch $file
++    ;;
++
++  tar*)
++    shift
++
++    # We have already tried tar in the generic part.
++    # Look for gnutar/gtar before invocation to avoid ugly error
++    # messages.
++    if (gnutar --version > /dev/null 2>&1); then
++       gnutar "$@" && exit 0
++    fi
++    if (gtar --version > /dev/null 2>&1); then
++       gtar "$@" && exit 0
++    fi
++    firstarg="$1"
++    if shift; then
++	case $firstarg in
++	*o*)
++	    firstarg=`echo "$firstarg" | sed s/o//`
++	    tar "$firstarg" "$@" && exit 0
++	    ;;
++	esac
++	case $firstarg in
++	*h*)
++	    firstarg=`echo "$firstarg" | sed s/h//`
++	    tar "$firstarg" "$@" && exit 0
++	    ;;
++	esac
++    fi
++
++    echo 1>&2 "\
++WARNING: I can't seem to be able to run \`tar' with the given arguments.
++         You may want to install GNU tar or Free paxutils, or check the
++         command line arguments."
++    exit 1
++    ;;
++
++  *)
++    echo 1>&2 "\
++WARNING: \`$1' is needed, and is $msg.
++         You might have modified some files without having the
++         proper tools for further handling them.  Check the \`README' file,
++         it often tells you about the needed prerequisites for installing
++         this package.  You may also peek at any GNU archive site, in case
++         some other package would contain this missing \`$1' program."
++    exit 1
++    ;;
++esac
++
++exit 0
++
++# Local variables:
++# eval: (add-hook 'write-file-hooks 'time-stamp)
++# time-stamp-start: "scriptversion="
++# time-stamp-format: "%:y-%02m-%02d.%02H"
++# time-stamp-time-zone: "UTC"
++# time-stamp-end: "; # UTC"
++# End:
+Index: git/packages/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/packages/Makefile.in	2010-12-29 04:07:15.988181152 +0100
+@@ -0,0 +1,910 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++subdir = packages
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \
++	html-recursive info-recursive install-data-recursive \
++	install-dvi-recursive install-exec-recursive \
++	install-html-recursive install-info-recursive \
++	install-pdf-recursive install-ps-recursive install-recursive \
++	installcheck-recursive installdirs-recursive pdf-recursive \
++	ps-recursive uninstall-recursive
++RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive	\
++  distclean-recursive maintainer-clean-recursive
++AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \
++	$(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS \
++	distdir
++ETAGS = etags
++CTAGS = ctags
++DIST_SUBDIRS = $(SUBDIRS)
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++am__relativize = \
++  dir0=`pwd`; \
++  sed_first='s,^\([^/]*\)/.*$$,\1,'; \
++  sed_rest='s,^[^/]*/*,,'; \
++  sed_last='s,^.*/\([^/]*\)$$,\1,'; \
++  sed_butlast='s,/*[^/]*$$,,'; \
++  while test -n "$$dir1"; do \
++    first=`echo "$$dir1" | sed -e "$$sed_first"`; \
++    if test "$$first" != "."; then \
++      if test "$$first" = ".."; then \
++        dir2=`echo "$$dir0" | sed -e "$$sed_last"`/"$$dir2"; \
++        dir0=`echo "$$dir0" | sed -e "$$sed_butlast"`; \
++      else \
++        first2=`echo "$$dir2" | sed -e "$$sed_first"`; \
++        if test "$$first2" = "$$first"; then \
++          dir2=`echo "$$dir2" | sed -e "$$sed_rest"`; \
++        else \
++          dir2="../$$dir2"; \
++        fi; \
++        dir0="$$dir0"/"$$first"; \
++      fi; \
++    fi; \
++    dir1=`echo "$$dir1" | sed -e "$$sed_rest"`; \
++  done; \
++  reldir="$$dir2"
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++SUBDIRS = mac
++all: all-recursive
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign packages/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign packages/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++# This directory's subdirectories are mostly independent; you can cd
++# into them and run `make' without going through this Makefile.
++# To change the values of `make' variables: instead of editing Makefiles,
++# (1) if the variable is set in `config.status', edit `config.status'
++#     (which will cause the Makefiles to be regenerated when you run `make');
++# (2) otherwise, pass the desired values on the `make' command line.
++$(RECURSIVE_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	target=`echo $@ | sed s/-recursive//`; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    dot_seen=yes; \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done; \
++	if test "$$dot_seen" = "no"; then \
++	  $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
++	fi; test -z "$$fail"
++
++$(RECURSIVE_CLEAN_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	case "$@" in \
++	  distclean-* | maintainer-clean-*) list='$(DIST_SUBDIRS)' ;; \
++	  *) list='$(SUBDIRS)' ;; \
++	esac; \
++	rev=''; for subdir in $$list; do \
++	  if test "$$subdir" = "."; then :; else \
++	    rev="$$subdir $$rev"; \
++	  fi; \
++	done; \
++	rev="$$rev ."; \
++	target=`echo $@ | sed s/-recursive//`; \
++	for subdir in $$rev; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done && test -z "$$fail"
++tags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
++	done
++ctags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) ctags); \
++	done
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS: tags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	if ($(ETAGS) --etags-include --version) >/dev/null 2>&1; then \
++	  include_option=--etags-include; \
++	  empty_fix=.; \
++	else \
++	  include_option=--include; \
++	  empty_fix=; \
++	fi; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test ! -f $$subdir/TAGS || \
++	      set "$$@" "$$include_option=$$here/$$subdir/TAGS"; \
++	  fi; \
++	done; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS: ctags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test -d "$(distdir)/$$subdir" \
++	    || $(MKDIR_P) "$(distdir)/$$subdir" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    dir1=$$subdir; dir2="$(distdir)/$$subdir"; \
++	    $(am__relativize); \
++	    new_distdir=$$reldir; \
++	    dir1=$$subdir; dir2="$(top_distdir)"; \
++	    $(am__relativize); \
++	    new_top_distdir=$$reldir; \
++	    echo " (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir="$$new_top_distdir" distdir="$$new_distdir" \\"; \
++	    echo "     am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)"; \
++	    ($(am__cd) $$subdir && \
++	      $(MAKE) $(AM_MAKEFLAGS) \
++	        top_distdir="$$new_top_distdir" \
++	        distdir="$$new_distdir" \
++		am__remove_distdir=: \
++		am__skip_length_check=: \
++		am__skip_mode_fix=: \
++	        distdir) \
++	      || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-recursive
++all-am: Makefile all-local
++installdirs: installdirs-recursive
++installdirs-am:
++install: install-recursive
++install-exec: install-exec-recursive
++install-data: install-data-recursive
++uninstall: uninstall-recursive
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-recursive
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-recursive
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-recursive
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic distclean-tags
++
++dvi: dvi-recursive
++
++dvi-am:
++
++html: html-recursive
++
++html-am:
++
++info: info-recursive
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-recursive
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-recursive
++
++install-html-am:
++
++install-info: install-info-recursive
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-recursive
++
++install-pdf-am:
++
++install-ps: install-ps-recursive
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-recursive
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-recursive
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-recursive
++
++pdf-am:
++
++ps: ps-recursive
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) check-am \
++	ctags-recursive install-am install-data-am install-exec-am \
++	install-strip tags-recursive uninstall-am
++
++.PHONY: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) CTAGS GTAGS \
++	all all-am all-local check check-am check-local clean \
++	clean-generic clean-libtool ctags ctags-recursive dist-hook \
++	distclean distclean-generic distclean-libtool distclean-tags \
++	distdir dvi dvi-am html html-am info info-am install \
++	install-am install-data install-data-am install-data-hook \
++	install-dvi install-dvi-am install-exec install-exec-am \
++	install-exec-hook install-html install-html-am install-info \
++	install-info-am install-man install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs installdirs-am maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags tags-recursive \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/packages/mac/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/packages/mac/Makefile.in	2010-12-29 04:07:16.148230791 +0100
+@@ -0,0 +1,714 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = packages/mac
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++EXTRA_DIST = \
++	Info.plist \
++	mac.sh \
++	Resources/Description.plist \
++	Resources/English.lproj/Welcome.rtf
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign packages/mac/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign packages/mac/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: all all-am all-local check check-am check-local clean \
++	clean-generic clean-libtool dist-hook distclean \
++	distclean-generic distclean-libtool distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/po/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/po/Makefile.in	2010-12-29 04:07:16.278271117 +0100
+@@ -0,0 +1,576 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++subdir = po
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SCRIPTS = $(noinst_SCRIPTS)
++SOURCES =
++DIST_SOURCES =
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++noinst_SCRIPTS = gen-po.sh
++ceprefix = heim_com_err
++
++#find . -name '*.po' -or -name '*.pot' -or -name '*.mo' | sed 's/^../    /' | sed 's/$/ \\/'
++FILES = \
++    heim_com_err-1750206208/heim_com_err-1750206208.pot \
++    heim_com_err-1765328384/heim_com_err-1765328384.pot \
++    heim_com_err-1765328384/sv_SE.mo \
++    heim_com_err-1765328384/sv_SE.po \
++    heim_com_err-1980176640/heim_com_err-1980176640.pot \
++    heim_com_err-969269760/heim_com_err-969269760.pot \
++    heim_com_err1859794432/heim_com_err1859794432.pot \
++    heim_com_err35224064/heim_com_err35224064.pot \
++    heim_com_err36150272/heim_com_err36150272.pot \
++    heim_com_err39525376/heim_com_err39525376.pot \
++    heim_com_err43787520/heim_com_err43787520.pot \
++    heim_com_err569856/heim_com_err569856.pot \
++    heimdal_kuser/heimdal_kuser.pot \
++    heimdal_krb5/heimdal_krb5.pot \
++    heimdal_krb5/sv_SE.mo \
++    heimdal_krb5/sv_SE.po
++
++EXTRA_DIST = gen-po.in $(FILES)
++CLEANFILES = gen-po.tmp $(noinst_SCRIPTS) heimdal-pot.tar.gz
++all: all-am
++
++.SUFFIXES:
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am  $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign po/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign po/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++check-am: all-am
++check: check-am
++all-am: Makefile $(SCRIPTS)
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++
++.MAKE: install-am install-data-am install-strip
++
++.PHONY: all all-am check check-am clean clean-generic clean-libtool \
++	distclean distclean-generic distclean-libtool distdir dvi \
++	dvi-am html html-am info info-am install install-am \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	uninstall uninstall-am
++
++
++gen-po.sh: gen-po.in
++	sed \
++	  -e 's,[@]top_srcdir[@],$(top_srcdir),' \
++	  -e 's,[@]PACKAGE_NAME[@],$(PACKAGE_NAME),' \
++	  -e 's,[@]PACKAGE_VERSION[@],$(PACKAGE_VERSION),' \
++	  < $(srcdir)/gen-po.in > gen-po.tmp
++	chmod +x gen-po.tmp
++	mv gen-po.tmp gen-po.sh
++
++po: gen-po.sh
++	./gen-po.sh heimdal_krb5 $(top_srcdir)/lib/krb5/*.[chly]
++	./gen-po.sh heimdal_kuser $(top_srcdir)/kuser/*.[ch]
++	find $(top_srcdir) -name *.et | while read x; do \
++		y=$$(basename $$x); \
++		echo $$y ; \
++		z=$$(echo $$y | sed 's/\.et$$//') ; \
++		t=$$(find $(top_builddir) -name $$z.c) ; \
++		t=$$(echo $$t | sed 's/\.c$$//') ; \
++		base=$$(grep 'ERROR_TABLE_BASE_' $${t}.h | cut -f3 -d' ') ; \
++		./gen-po.sh $(ceprefix)$$base $${t}.c ; \
++		test -f $(top_srcdir)/po/$(ceprefix)$$base/$(ceprefix)$$base.pot || { echo "$$y missing" ; exit 1; } \
++	done
++
++mo:
++	cd $(srcdir) ; \
++	rm localefiles ; \
++	touch localefiles ; \
++	find . -name '*.po' | while read s ; do \
++	   t=$$(echo $$s | sed -e 's/\.po$$/.mo/') ; \
++	   msgfmt -o $$t $$s ; \
++	   echo $$t | sed 's@\./@@' >> localefiles ; \
++	done
++
++install-data-hook:
++	@for x in `cat $(srcdir)/localefiles` ; do \
++	    domain=`echo $$x | sed 's@/.*@@'`; \
++	    lang=`echo $$x | sed 's@.*/\(.*\)\\.mo$$@\1@'`; \
++	    echo "installing lang $$domain $$lang" ; \
++	    sh $(top_srcdir)/install-sh -d \
++		"$(DESTDIR)$(localedir)/$$lang/LC_MESSAGES" ; \
++	    sh $(top_srcdir)/install-sh $(srcdir)/$$x \
++	        "$(DESTDIR)$(localedir)/$$lang/LC_MESSAGES/$$domain.mo" ; \
++	done
++
++launchpad:
++	tar czCf \
++		$(top_srcdir) \
++		$(top_builddir)/po/heimdal-pot.tar.gz \
++		$$(cd $(top_srcdir) && find . -name '*.pot')
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/tests/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/tests/Makefile.in	2010-12-29 04:07:16.448323851 +0100
+@@ -0,0 +1,911 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common ChangeLog
++@ENABLE_SHARED_TRUE@@HAVE_DLOPEN_TRUE@am__append_1 = plugin
++subdir = tests
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \
++	html-recursive info-recursive install-data-recursive \
++	install-dvi-recursive install-exec-recursive \
++	install-html-recursive install-info-recursive \
++	install-pdf-recursive install-ps-recursive install-recursive \
++	installcheck-recursive installdirs-recursive pdf-recursive \
++	ps-recursive uninstall-recursive
++RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive	\
++  distclean-recursive maintainer-clean-recursive
++AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \
++	$(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS \
++	distdir
++ETAGS = etags
++CTAGS = ctags
++DIST_SUBDIRS = bin db kdc gss ldap can java plugin
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++am__relativize = \
++  dir0=`pwd`; \
++  sed_first='s,^\([^/]*\)/.*$$,\1,'; \
++  sed_rest='s,^[^/]*/*,,'; \
++  sed_last='s,^.*/\([^/]*\)$$,\1,'; \
++  sed_butlast='s,/*[^/]*$$,,'; \
++  while test -n "$$dir1"; do \
++    first=`echo "$$dir1" | sed -e "$$sed_first"`; \
++    if test "$$first" != "."; then \
++      if test "$$first" = ".."; then \
++        dir2=`echo "$$dir0" | sed -e "$$sed_last"`/"$$dir2"; \
++        dir0=`echo "$$dir0" | sed -e "$$sed_butlast"`; \
++      else \
++        first2=`echo "$$dir2" | sed -e "$$sed_first"`; \
++        if test "$$first2" = "$$first"; then \
++          dir2=`echo "$$dir2" | sed -e "$$sed_rest"`; \
++        else \
++          dir2="../$$dir2"; \
++        fi; \
++        dir0="$$dir0"/"$$first"; \
++      fi; \
++    fi; \
++    dir1=`echo "$$dir1" | sed -e "$$sed_rest"`; \
++  done; \
++  reldir="$$dir2"
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++SUBDIRS = bin db kdc gss ldap can java $(am__append_1)
++all: all-recursive
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign tests/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign tests/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++# This directory's subdirectories are mostly independent; you can cd
++# into them and run `make' without going through this Makefile.
++# To change the values of `make' variables: instead of editing Makefiles,
++# (1) if the variable is set in `config.status', edit `config.status'
++#     (which will cause the Makefiles to be regenerated when you run `make');
++# (2) otherwise, pass the desired values on the `make' command line.
++$(RECURSIVE_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	target=`echo $@ | sed s/-recursive//`; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    dot_seen=yes; \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done; \
++	if test "$$dot_seen" = "no"; then \
++	  $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
++	fi; test -z "$$fail"
++
++$(RECURSIVE_CLEAN_TARGETS):
++	@fail= failcom='exit 1'; \
++	for f in x $$MAKEFLAGS; do \
++	  case $$f in \
++	    *=* | --[!k]*);; \
++	    *k*) failcom='fail=yes';; \
++	  esac; \
++	done; \
++	dot_seen=no; \
++	case "$@" in \
++	  distclean-* | maintainer-clean-*) list='$(DIST_SUBDIRS)' ;; \
++	  *) list='$(SUBDIRS)' ;; \
++	esac; \
++	rev=''; for subdir in $$list; do \
++	  if test "$$subdir" = "."; then :; else \
++	    rev="$$subdir $$rev"; \
++	  fi; \
++	done; \
++	rev="$$rev ."; \
++	target=`echo $@ | sed s/-recursive//`; \
++	for subdir in $$rev; do \
++	  echo "Making $$target in $$subdir"; \
++	  if test "$$subdir" = "."; then \
++	    local_target="$$target-am"; \
++	  else \
++	    local_target="$$target"; \
++	  fi; \
++	  ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
++	  || eval $$failcom; \
++	done && test -z "$$fail"
++tags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
++	done
++ctags-recursive:
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  test "$$subdir" = . || ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) ctags); \
++	done
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS: tags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	if ($(ETAGS) --etags-include --version) >/dev/null 2>&1; then \
++	  include_option=--etags-include; \
++	  empty_fix=.; \
++	else \
++	  include_option=--include; \
++	  empty_fix=; \
++	fi; \
++	list='$(SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test ! -f $$subdir/TAGS || \
++	      set "$$@" "$$include_option=$$here/$$subdir/TAGS"; \
++	  fi; \
++	done; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS: ctags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    test -d "$(distdir)/$$subdir" \
++	    || $(MKDIR_P) "$(distdir)/$$subdir" \
++	    || exit 1; \
++	  fi; \
++	done
++	@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" = .; then :; else \
++	    dir1=$$subdir; dir2="$(distdir)/$$subdir"; \
++	    $(am__relativize); \
++	    new_distdir=$$reldir; \
++	    dir1=$$subdir; dir2="$(top_distdir)"; \
++	    $(am__relativize); \
++	    new_top_distdir=$$reldir; \
++	    echo " (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir="$$new_top_distdir" distdir="$$new_distdir" \\"; \
++	    echo "     am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)"; \
++	    ($(am__cd) $$subdir && \
++	      $(MAKE) $(AM_MAKEFLAGS) \
++	        top_distdir="$$new_top_distdir" \
++	        distdir="$$new_distdir" \
++		am__remove_distdir=: \
++		am__skip_length_check=: \
++		am__skip_mode_fix=: \
++	        distdir) \
++	      || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-recursive
++all-am: Makefile all-local
++installdirs: installdirs-recursive
++installdirs-am:
++install: install-recursive
++install-exec: install-exec-recursive
++install-data: install-data-recursive
++uninstall: uninstall-recursive
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-recursive
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-recursive
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-recursive
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic distclean-tags
++
++dvi: dvi-recursive
++
++dvi-am:
++
++html: html-recursive
++
++html-am:
++
++info: info-recursive
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-recursive
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-recursive
++
++install-html-am:
++
++install-info: install-info-recursive
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-recursive
++
++install-pdf-am:
++
++install-ps: install-ps-recursive
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-recursive
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-recursive
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-recursive
++
++pdf-am:
++
++ps: ps-recursive
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) check-am \
++	ctags-recursive install-am install-data-am install-exec-am \
++	install-strip tags-recursive uninstall-am
++
++.PHONY: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) CTAGS GTAGS \
++	all all-am all-local check check-am check-local clean \
++	clean-generic clean-libtool ctags ctags-recursive dist-hook \
++	distclean distclean-generic distclean-libtool distclean-tags \
++	distdir dvi dvi-am html html-am info info-am install \
++	install-am install-data install-data-am install-data-hook \
++	install-dvi install-dvi-am install-exec install-exec-am \
++	install-exec-hook install-html install-html-am install-info \
++	install-info-am install-man install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs installdirs-am maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am tags tags-recursive \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/tests/bin/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/tests/bin/Makefile.in	2010-12-29 04:07:16.618376585 +0100
+@@ -0,0 +1,726 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = tests/bin
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SCRIPTS = $(noinst_SCRIPTS)
++SOURCES =
++DIST_SOURCES =
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++noinst_SCRIPTS = setup-env
++do_subst = \
++	top_srcdir="$$(cd ${top_srcdir} && pwd)" ; \
++	top_builddir="$$(cd ${top_builddir} && pwd)" ; \
++	sed $(do_dlopen) \
++	-e "s,[@]EGREP[@],$(EGREP),g" \
++	-e "s,[@]top_srcdir[@],$${top_srcdir},g" \
++	-e "s,[@]top_builddir[@],$${top_builddir},g" \
++	-e "s,[@]NO_AFS[@],$(NO_AFS),g"
++
++EXTRA_DIST = setup-env.in
++CLEANFILES = setup-env setup-env.tmp
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign tests/bin/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign tests/bin/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(SCRIPTS) all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: all all-am all-local check check-am check-local clean \
++	clean-generic clean-libtool dist-hook distclean \
++	distclean-generic distclean-libtool distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++setup-env: setup-env.in Makefile
++	$(do_subst) < $(srcdir)/setup-env.in > setup-env.tmp
++	chmod +x setup-env.tmp
++	mv setup-env.tmp setup-env
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/tests/can/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/tests/can/Makefile.in	2010-12-29 04:07:16.798432421 +0100
+@@ -0,0 +1,855 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = tests/can
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++DATA = $(noinst_DATA)
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .xf \
++	.cf
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++noinst_DATA = krb5.conf mit-pkinit-20070607.cf
++check_SCRIPTS = $(SCRIPT_TESTS) test_can
++SCRIPT_TESTS = check-can
++TESTS = $(SCRIPT_TESTS)
++port = 49188
++do_subst = sed -e 's,[@]srcdir[@],$(srcdir),g' \
++	-e 's,[@]port[@],$(port),g' \
++	-e 's,[@]objdir[@],$(top_builddir)/tests/can,g' \
++	-e 's,[@]EGREP[@],$(EGREP),g' \
++	-e 's,[@]env_setup[@],$(top_builddir)/tests/bin/setup-env,g'
++
++CLEANFILES = $(TESTS) *.tmp *.cf \
++	current-db* \
++	krb5.conf \
++	messages.log \
++	test_can
++
++EXTRA_DIST = \
++	apple-10.4.kadm \
++	apple-10.4.req \
++	check-can.in \
++	heim-0.8.kadm \
++	heim-0.8.req \
++	krb5.conf.in \
++	mit-pkinit-20070607.ca.crt \
++	mit-pkinit-20070607.kadm \
++	mit-pkinit-20070607.req \
++	mit-pkinit-20070607.xf \
++	test_can.in
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .xf .cf .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign tests/can/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign tests/can/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_SCRIPTS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: check-am
++all-am: Makefile $(DATA) all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: all all-am all-local check check-TESTS check-am check-local \
++	clean clean-generic clean-libtool dist-hook distclean \
++	distclean-generic distclean-libtool distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++test_can: test_can.in Makefile
++	$(do_subst) < $(srcdir)/test_can.in > test_can.tmp
++	chmod +x test_can.tmp
++	mv test_can.tmp test_can
++
++check-can: check-can.in Makefile
++	$(do_subst) < $(srcdir)/check-can.in > check-can.tmp
++	chmod +x check-can.tmp
++	mv check-can.tmp check-can
++
++krb5.conf: krb5.conf.in Makefile
++	$(do_subst) < $(srcdir)/krb5.conf.in > krb5.conf.tmp
++	mv krb5.conf.tmp krb5.conf
++
++.xf.cf:
++	$(do_subst) < $< > $@.tmp
++	mv $@.tmp $@
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/tests/db/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/tests/db/Makefile.in	2010-12-29 04:07:16.978488257 +0100
+@@ -0,0 +1,884 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = tests/db
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SCRIPTS = $(noinst_SCRIPTS)
++SOURCES =
++DIST_SOURCES =
++DATA = $(noinst_DATA)
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++noinst_DATA = krb5.conf krb5.conf-sqlite
++noinst_SCRIPTS = have-db
++check_SCRIPTS = loaddump-db add-modify-delete check-dbinfo check-aliases
++TESTS = $(check_SCRIPTS) 
++do_subst = sed -e 's,[@]srcdir[@],$(srcdir),g' \
++	-e 's,[@]top_builddir[@],$(top_builddir),g' \
++	-e 's,[@]objdir[@],$(top_builddir)/tests/db,g' \
++	-e 's,[@]EGREP[@],$(EGREP),g' 
++
++CLEANFILES = \
++	$(TESTS) \
++	have-db \
++	db-dump* \
++	dbinfo.out \
++	current-db* \
++	out-text-dump* \
++	out-current-* \
++	mkey.file* \
++	krb5.conf krb5.conf.tmp \
++	krb5.conf-sqlite krb5.conf-sqlite.tmp \
++	krb5-mit.conf krb5-mit.conf.tmp \
++	tempfile \
++	log.current-db* \
++	heimdal-db* \
++	messages.log
++
++EXTRA_DIST = \
++	check-aliases.in \
++	check-dbinfo.in \
++	loaddump-db.in \
++	add-modify-delete.in \
++	have-db.in \
++	krb5.conf.in \
++	krb5-mit.conf.in \
++	text-dump-0.7 \
++	text-dump-known-ext \
++	text-dump-no-ext \
++	text-dump-unknown-ext
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign tests/db/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign tests/db/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_SCRIPTS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: check-am
++all-am: Makefile $(SCRIPTS) $(DATA) all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: all all-am all-local check check-TESTS check-am check-local \
++	clean clean-generic clean-libtool dist-hook distclean \
++	distclean-generic distclean-libtool distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++loaddump-db: loaddump-db.in Makefile
++	$(do_subst) < $(srcdir)/loaddump-db.in > loaddump-db.tmp
++	chmod +x loaddump-db.tmp
++	mv loaddump-db.tmp loaddump-db
++
++add-modify-delete: add-modify-delete.in Makefile
++	$(do_subst) < $(srcdir)/add-modify-delete.in > add-modify-delete.tmp
++	chmod +x add-modify-delete.tmp
++	mv add-modify-delete.tmp add-modify-delete
++
++check-dbinfo: check-dbinfo.in Makefile
++	$(do_subst) < $(srcdir)/check-dbinfo.in > check-dbinfo.tmp
++	chmod +x check-dbinfo.tmp
++	mv check-dbinfo.tmp check-dbinfo
++
++check-aliases: check-aliases.in Makefile
++	$(do_subst) < $(srcdir)/check-aliases.in > check-aliases.tmp
++	chmod +x check-aliases.tmp
++	mv check-aliases.tmp check-aliases
++
++have-db: have-db.in Makefile
++	$(do_subst) < $(srcdir)/have-db.in > have-db.tmp
++	chmod +x have-db.tmp
++	mv have-db.tmp have-db
++
++krb5.conf: krb5.conf.in Makefile
++	$(do_subst) -e 's,[@]type[@],,g' < $(srcdir)/krb5.conf.in > krb5.conf.tmp
++	mv krb5.conf.tmp krb5.conf
++
++krb5.conf-sqlite: krb5.conf.in Makefile
++	$(do_subst) -e 's,[@]type[@],sqlite:,g' < $(srcdir)/krb5.conf.in > krb5.conf-sqlite.tmp
++	mv krb5.conf-sqlite.tmp krb5.conf-sqlite
++
++krb5-mit.conf: krb5-mit.conf.in Makefile
++	$(do_subst) < $(srcdir)/krb5-mit.conf.in > krb5-mit.conf.tmp
++	mv krb5-mit.conf.tmp krb5-mit.conf
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/tests/gss/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/tests/gss/Makefile.in	2010-12-29 04:07:17.158544036 +0100
+@@ -0,0 +1,878 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = tests/gss
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++DATA = $(noinst_DATA)
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++noinst_DATA = krb5.conf
++SCRIPT_TESTS = check-gss check-gssmask check-context check-spnego check-ntlm
++TESTS = $(SCRIPT_TESTS)
++check_SCRIPTS = $(SCRIPT_TESTS)
++port = 49188
++do_subst = sed -e 's,[@]srcdir[@],$(srcdir),g' \
++	-e 's,[@]env_setup[@],$(top_builddir)/tests/bin/setup-env,g' \
++	-e 's,[@]port[@],$(port),g' \
++	-e 's,[@]objdir[@],$(top_builddir)/tests/gss,g'
++
++CLEANFILES = \
++	$(TESTS) \
++	foopassword \
++	barpassword \
++	krb5ccfile \
++	krb5ccfile-ds \
++	server.keytab \
++	krb5.conf \
++	current-db* \
++	*.log \
++	tempfile \
++	check-basic.tmp \
++	check-gss.tmp \
++	check-gssmask.tmp \
++	check-spnego.tmp \
++	check-ntlm.tmp \
++	check-context.tmp
++
++EXTRA_DIST = \
++	check-basic.in \
++	check-gss.in \
++	check-gssmask.in \
++	check-spnego.in \
++	check-ntlm.in \
++	check-context.in \
++	ntlm-user-file.txt \
++	krb5.conf.in
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign tests/gss/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign tests/gss/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_SCRIPTS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: check-am
++all-am: Makefile $(DATA) all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: all all-am all-local check check-TESTS check-am check-local \
++	clean clean-generic clean-libtool dist-hook distclean \
++	distclean-generic distclean-libtool distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++check-gss: check-gss.in Makefile
++	$(do_subst) < $(srcdir)/check-gss.in > check-gss.tmp
++	chmod +x check-gss.tmp
++	mv check-gss.tmp check-gss
++
++check-gssmask: check-gssmask.in Makefile
++	$(do_subst) < $(srcdir)/check-gssmask.in > check-gssmask.tmp
++	chmod +x check-gssmask.tmp
++	mv check-gssmask.tmp check-gssmask
++
++check-context: check-context.in Makefile
++	$(do_subst) < $(srcdir)/check-context.in > check-context.tmp
++	chmod +x check-context.tmp
++	mv check-context.tmp check-context
++
++check-spnego: check-spnego.in Makefile
++	$(do_subst) < $(srcdir)/check-spnego.in > check-spnego.tmp
++	chmod +x check-spnego.tmp
++	mv check-spnego.tmp check-spnego
++
++check-basic: check-basic.in Makefile
++	$(do_subst) < $(srcdir)/check-basic.in > check-basic.tmp
++	chmod +x check-basic.tmp
++	mv check-basic.tmp check-basic
++
++check-ntlm: check-ntlm.in Makefile
++	$(do_subst) < $(srcdir)/check-ntlm.in > check-ntlm.tmp
++	chmod +x check-ntlm.tmp
++	mv check-ntlm.tmp check-ntlm
++
++krb5.conf: krb5.conf.in Makefile
++	$(do_subst) < $(srcdir)/krb5.conf.in > krb5.conf.tmp
++	mv krb5.conf.tmp krb5.conf
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/tests/java/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/tests/java/Makefile.in	2010-12-29 04:07:17.348602902 +0100
+@@ -0,0 +1,840 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id: Makefile.am 20739 2007-05-31 16:53:21Z lha $
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = tests/java
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++DATA = $(noinst_DATA)
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++noinst_DATA = krb5.conf
++check_SCRIPTS = $(SCRIPT_TESTS) 
++SCRIPT_TESTS = check-kinit
++TESTS = $(SCRIPT_TESTS)
++port = 49188
++do_subst = sed -e 's,[@]srcdir[@],$(srcdir),g' \
++	-e 's,[@]port[@],$(port),g' \
++	-e 's,[@]objdir[@],$(top_builddir)/tests/java,g'
++
++LDADD = ../../lib/krb5/libkrb5.la $(LIB_roken)
++CLEANFILES = \
++	$(TESTS) \
++	*.tmp \
++	*.class \
++	current-db* \
++	krb5.conf \
++	messages.log
++
++EXTRA_DIST = \
++	KerberosInit.java \
++	jaas.conf \
++	check-kinit.in \
++	have-java.sh \
++	krb5.conf.in
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign tests/java/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign tests/java/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_SCRIPTS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: check-am
++all-am: Makefile $(DATA) all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: all all-am all-local check check-TESTS check-am check-local \
++	clean clean-generic clean-libtool dist-hook distclean \
++	distclean-generic distclean-libtool distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++check-kinit: check-kinit.in Makefile
++	$(do_subst) < $(srcdir)/check-kinit.in > check-kinit.tmp
++	chmod +x check-kinit.tmp
++	mv check-kinit.tmp check-kinit
++
++krb5.conf: krb5.conf.in Makefile
++	$(do_subst) < $(srcdir)/krb5.conf.in > krb5.conf.tmp
++	mv krb5.conf.tmp krb5.conf
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/tests/kdc/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/tests/kdc/Makefile.in	2010-12-29 04:07:17.538661768 +0100
+@@ -0,0 +1,1010 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = tests/kdc
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++DATA = $(noinst_DATA)
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++noinst_DATA = \
++	krb5.conf \
++	krb5-weak.conf \
++	krb5-pkinit.conf \
++	krb5-pkinit-win.conf \
++	krb5-slave.conf
++
++check_SCRIPTS = $(SCRIPT_TESTS) 
++SCRIPT_TESTS = \
++	check-cc \
++	check-delegation \
++	check-des \
++	check-digest \
++	check-kadmin \
++	check-kdc \
++	check-kdc-weak \
++	check-keys \
++	check-kpasswdd \
++	check-pkinit \
++	check-iprop \
++	check-referral \
++	check-uu
++
++TESTS = $(SCRIPT_TESTS)
++port = 49188
++admport = 49189
++pwport = 49190
++@HAVE_DLOPEN_FALSE@do_dlopen = -e 's,[@]DLOPEN[@],false,g'
++@HAVE_DLOPEN_TRUE@do_dlopen = -e 's,[@]DLOPEN[@],true,g'
++do_subst = sed $(do_dlopen) \
++	-e 's,[@]env_setup[@],$(top_builddir)/tests/bin/setup-env,g' \
++	-e 's,[@]srcdir[@],$(srcdir),g' \
++	-e 's,[@]port[@],$(port),g' \
++	-e 's,[@]admport[@],$(admport),g' \
++	-e 's,[@]pwport[@],$(pwport),g' \
++	-e 's,[@]objdir[@],$(top_builddir)/tests/kdc,g' \
++	-e 's,[@]top_builddir[@],$(top_builddir),g' \
++	-e 's,[@]EGREP[@],$(EGREP),g' 
++
++LDADD = ../../lib/krb5/libkrb5.la $(LIB_roken)
++CLEANFILES = \
++	$(TESTS) \
++	iprop-stats \
++	barpassword \
++	cache.krb5 \
++	cdigest-reply \
++	*.tmp \
++	client-cache \
++	current-db* \
++	current*.log \
++	iprop.keytab \
++	digest-reply \
++	foopassword \
++	krb5.conf \
++	krb5-weak.conf \
++	krb5.conf.keys \
++	krb5-cc.conf \
++	krb5-slave.conf \
++	krb5-pkinit.conf \
++	krb5-pkinit-win.conf \
++	signal \
++	leaks-log \
++	malloc-log \
++	malloc-log-master \
++	malloc-log-slave \
++	messages.log \
++	o2cache.krb5 \
++	o2digest-reply \
++	ocache.krb5 \
++	s2digest-reply \
++	sdigest-init \
++	sdigest-reply \
++	server.keytab \
++	req-pkinit.der \
++	req-pkinit2.der \
++	req-kdc.der \
++	pkinit.crt \
++	pkinit2.crt \
++	pkinit3.crt \
++	pkinit4.crt \
++	kdc.crt \
++	ca.crt \
++	uuserver.log \
++	tempfile \
++	test-rc-file.rc
++
++EXTRA_DIST = \
++	check-cc.in \
++	check-delegation.in \
++	check-des.in \
++	check-digest.in \
++	check-iprop.in \
++	check-kadmin.in \
++	check-kdc.in \
++	check-kdc-weak.in \
++	check-keys.in \
++	check-kpasswdd.in \
++	check-pkinit.in \
++	check-referral.in \
++	check-uu.in \
++	donotexists.txt \
++	heimdal.acl \
++	iprop-acl \
++	krb5-pkinit.conf.in \
++	krb5.conf.in \
++	krb5.conf.keys.in \
++	ntlm-user-file.txt \
++	leaks-kill.sh \
++	pki-mapping \
++	uuserver.txt \
++	wait-kdc.sh
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign tests/kdc/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign tests/kdc/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_SCRIPTS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: check-am
++all-am: Makefile $(DATA) all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: all all-am all-local check check-TESTS check-am check-local \
++	clean clean-generic clean-libtool dist-hook distclean \
++	distclean-generic distclean-libtool distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++check-cc: check-cc.in Makefile
++	$(do_subst) < $(srcdir)/check-cc.in > check-cc.tmp
++	chmod +x check-cc.tmp
++	mv check-cc.tmp check-cc
++
++check-delegation: check-delegation.in Makefile
++	$(do_subst) < $(srcdir)/check-delegation.in > check-delegation.tmp
++	chmod +x check-delegation.tmp
++	mv check-delegation.tmp check-delegation
++
++check-des: check-des.in Makefile krb5.conf
++	$(do_subst) < $(srcdir)/check-des.in > check-des.tmp
++	chmod +x check-des.tmp
++	mv check-des.tmp check-des
++
++check-kdc: check-kdc.in Makefile
++	$(do_subst) < $(srcdir)/check-kdc.in > check-kdc.tmp
++	chmod +x check-kdc.tmp
++	mv check-kdc.tmp check-kdc
++
++check-kdc-weak: check-kdc-weak.in Makefile
++	$(do_subst) < $(srcdir)/check-kdc-weak.in > check-kdc-weak.tmp
++	chmod +x check-kdc-weak.tmp
++	mv check-kdc-weak.tmp check-kdc-weak
++
++check-keys: check-keys.in Makefile
++	$(do_subst) < $(srcdir)/check-keys.in > check-keys.tmp
++	chmod +x check-keys.tmp
++	mv check-keys.tmp check-keys
++
++check-kadmin: check-kadmin.in Makefile
++	$(do_subst) < $(srcdir)/check-kadmin.in > check-kadmin.tmp
++	chmod +x check-kadmin.tmp
++	mv check-kadmin.tmp check-kadmin
++
++check-uu: check-uu.in Makefile
++	$(do_subst) < $(srcdir)/check-uu.in > check-uu.tmp
++	chmod +x check-uu.tmp
++	mv check-uu.tmp check-uu
++
++check-pkinit: check-pkinit.in Makefile krb5-pkinit.conf
++	$(do_subst) < $(srcdir)/check-pkinit.in > check-pkinit.tmp
++	chmod +x check-pkinit.tmp
++	mv check-pkinit.tmp check-pkinit
++
++check-iprop: check-iprop.in Makefile krb5.conf krb5-slave.conf
++	$(do_subst) < $(srcdir)/check-iprop.in > check-iprop.tmp
++	chmod +x check-iprop.tmp
++	mv check-iprop.tmp check-iprop
++
++check-digest: check-digest.in Makefile
++	$(do_subst) < $(srcdir)/check-digest.in > check-digest.tmp
++	chmod +x check-digest.tmp
++	mv check-digest.tmp check-digest
++
++check-referral: check-referral.in Makefile
++	$(do_subst) < $(srcdir)/check-referral.in > check-referral.tmp
++	chmod +x check-referral.tmp
++	mv check-referral.tmp check-referral
++
++check-kpasswdd: check-kpasswdd.in Makefile
++	$(do_subst) < $(srcdir)/check-kpasswdd.in > check-kpasswdd.tmp
++	chmod +x check-kpasswdd.tmp
++	mv check-kpasswdd.tmp check-kpasswdd
++
++krb5.conf: krb5.conf.in Makefile
++	$(do_subst) \
++	   -e 's,[@]WEAK[@],false,g' \
++	   -e 's,[@]dk[@],,g' \
++	   -e 's,[@]kdc[@],,g' < $(srcdir)/krb5.conf.in > krb5.conf.tmp
++	mv krb5.conf.tmp krb5.conf
++
++krb5-weak.conf: krb5.conf.in Makefile
++	$(do_subst) \
++	   -e 's,[@]WEAK[@],true,g' \
++	   -e 's,[@]dk[@],default_keys = aes256-cts-hmac-sha1-96:pw-salt arcfour-hmac-md5:pw-salt des3-cbc-sha1:pw-salt des:pw-salt,g' \
++	   -e 's,[@]kdc[@],,g' < $(srcdir)/krb5.conf.in > krb5-weak.conf.tmp
++	mv krb5-weak.conf.tmp krb5-weak.conf
++
++krb5-slave.conf: krb5.conf.in Makefile
++	$(do_subst) \
++	   -e 's,[@]WEAK[@],true,g' \
++	   -e 's,[@]dk[@],,g' \
++	   -e 's,[@]kdc[@],.slave,g' < $(srcdir)/krb5.conf.in > krb5-slave.conf.tmp
++	mv krb5-slave.conf.tmp krb5-slave.conf
++
++krb5-pkinit.conf: krb5-pkinit.conf.in Makefile
++	$(do_subst) -e 's,[@]w2k[@],no,g' < $(srcdir)/krb5-pkinit.conf.in > krb5-pkinit.conf.tmp
++	mv krb5-pkinit.conf.tmp krb5-pkinit.conf
++
++krb5-pkinit-win.conf: krb5-pkinit.conf.in Makefile
++	$(do_subst) -e 's,[@]w2k[@],yes,g' < $(srcdir)/krb5-pkinit.conf.in > krb5-pkinit-win.conf.tmp
++	mv krb5-pkinit-win.conf.tmp krb5-pkinit-win.conf
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/tests/ldap/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/tests/ldap/Makefile.in	2010-12-29 04:07:17.718717536 +0100
+@@ -0,0 +1,851 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = tests/ldap
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++SOURCES =
++DIST_SOURCES =
++DATA = $(noinst_DATA)
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++noinst_DATA = krb5.conf
++check_SCRIPTS = $(TESTS) slapd-init
++TESTS = check-ldap
++port = 49188
++do_subst = sed -e 's,[@]srcdir[@],$(srcdir),g' \
++	-e 's,[@]port[@],$(port),g' \
++	-e 's,[@]objdir[@],$(top_builddir)/tests/ldap,g' \
++	-e 's,[@]EGREP[@],$(EGREP),g' 
++
++CLEANFILES = \
++	$(TESTS) \
++	check-ldap.tmp \
++	slapd-init.tmp \
++	current-db* \
++	krb5.conf krb5.conf.tmp \
++	modules.conf \
++	cache.krb5 \
++	slapd-init \
++	foopassword \
++	messages.log \
++	slapd.pid
++
++EXTRA_DIST = \
++	samba.schema \
++	slapd.conf \
++	slapd-stop \
++	check-ldap.in \
++	init.ldif \
++	krb5.conf.in \
++	slapd-init.in
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign tests/ldap/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign tests/ldap/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) $(check_SCRIPTS)
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: check-am
++all-am: Makefile $(DATA) all-local
++installdirs:
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: all all-am all-local check check-TESTS check-am check-local \
++	clean clean-generic clean-libtool dist-hook distclean \
++	distclean-generic distclean-libtool distdir dvi dvi-am html \
++	html-am info info-am install install-am install-data \
++	install-data-am install-data-hook install-dvi install-dvi-am \
++	install-exec install-exec-am install-exec-hook install-html \
++	install-html-am install-info install-info-am install-man \
++	install-pdf install-pdf-am install-ps install-ps-am \
++	install-strip installcheck installcheck-am installdirs \
++	maintainer-clean maintainer-clean-generic mostlyclean \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	uninstall uninstall-am uninstall-hook
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++check-ldap: check-ldap.in Makefile
++	$(do_subst) < $(srcdir)/check-ldap.in > check-ldap.tmp
++	chmod +x check-ldap.tmp
++	mv check-ldap.tmp check-ldap
++
++slapd-init: slapd-init.in Makefile
++	$(do_subst) < $(srcdir)/slapd-init.in > slapd-init.tmp
++	chmod +x slapd-init.tmp
++	mv slapd-init.tmp slapd-init
++
++krb5.conf: krb5.conf.in Makefile
++	$(do_subst) < $(srcdir)/krb5.conf.in > krb5.conf.tmp
++	mv krb5.conf.tmp krb5.conf
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/tests/plugin/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/tests/plugin/Makefile.in	2010-12-29 04:07:17.938785696 +0100
+@@ -0,0 +1,1002 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = tests/plugin
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(libdir)"
++LTLIBRARIES = $(lib_LTLIBRARIES)
++windc_la_LIBADD =
++am_windc_la_OBJECTS = windc.lo
++windc_la_OBJECTS = $(am_windc_la_OBJECTS)
++windc_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(windc_la_LDFLAGS) \
++	$(LDFLAGS) -o $@
++depcomp = $(SHELL) $(top_srcdir)/depcomp
++am__depfiles_maybe = depfiles
++am__mv = mv -f
++COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
++	$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
++	$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
++CCLD = $(CC)
++LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
++	--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
++	$(LDFLAGS) -o $@
++SOURCES = $(windc_la_SOURCES)
++DIST_SOURCES = $(windc_la_SOURCES)
++DATA = $(noinst_DATA)
++ETAGS = etags
++CTAGS = ctags
++am__tty_colors = \
++red=; grn=; lgn=; blu=; std=
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++noinst_DATA = krb5.conf
++SCRIPT_TESTS = check-pac
++TESTS = $(SCRIPT_TESTS)
++port = 49188
++do_subst = sed -e 's,[@]srcdir[@],$(srcdir),g' \
++	-e 's,[@]port[@],$(port),g' \
++	-e 's,[@]objdir[@],$(top_builddir)/tests/plugin,g' \
++	-e 's,[@]EGREP[@],$(EGREP),g' 
++
++LDADD = ../../lib/krb5/libkrb5.la $(LIB_roken)
++lib_LTLIBRARIES = windc.la
++windc_la_SOURCES = windc.c
++windc_la_LDFLAGS = -module
++CLEANFILES = \
++	$(TESTS) \
++	server.keytab \
++	current-db* \
++	foopassword \
++	krb5.conf krb5.conf.tmp \
++	messages.log
++
++EXTRA_DIST = \
++	check-pac.in \
++	krb5.conf.in
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .lo .o .obj
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign tests/plugin/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign tests/plugin/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-libLTLIBRARIES: $(lib_LTLIBRARIES)
++	@$(NORMAL_INSTALL)
++	test -z "$(libdir)" || $(MKDIR_P) "$(DESTDIR)$(libdir)"
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	list2=; for p in $$list; do \
++	  if test -f $$p; then \
++	    list2="$$list2 $$p"; \
++	  else :; fi; \
++	done; \
++	test -z "$$list2" || { \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 '$(DESTDIR)$(libdir)'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=install $(INSTALL) $(INSTALL_STRIP_FLAG) $$list2 "$(DESTDIR)$(libdir)"; \
++	}
++
++uninstall-libLTLIBRARIES:
++	@$(NORMAL_UNINSTALL)
++	@list='$(lib_LTLIBRARIES)'; test -n "$(libdir)" || list=; \
++	for p in $$list; do \
++	  $(am__strip_dir) \
++	  echo " $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f '$(DESTDIR)$(libdir)/$$f'"; \
++	  $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=uninstall rm -f "$(DESTDIR)$(libdir)/$$f"; \
++	done
++
++clean-libLTLIBRARIES:
++	-test -z "$(lib_LTLIBRARIES)" || rm -f $(lib_LTLIBRARIES)
++	@list='$(lib_LTLIBRARIES)'; for p in $$list; do \
++	  dir="`echo $$p | sed -e 's|/[^/]*$$||'`"; \
++	  test "$$dir" != "$$p" || dir=.; \
++	  echo "rm -f \"$${dir}/so_locations\""; \
++	  rm -f "$${dir}/so_locations"; \
++	done
++windc.la: $(windc_la_OBJECTS) $(windc_la_DEPENDENCIES) 
++	$(windc_la_LINK) -rpath $(libdir) $(windc_la_OBJECTS) $(windc_la_LIBADD) $(LIBS)
++
++mostlyclean-compile:
++	-rm -f *.$(OBJEXT)
++
++distclean-compile:
++	-rm -f *.tab.c
++
++@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/windc.Plo@am__quote@
++
++.c.o:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c $<
++
++.c.obj:
++@am__fastdepCC_TRUE@	$(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ `$(CYGPATH_W) '$<'`
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=no @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(COMPILE) -c `$(CYGPATH_W) '$<'`
++
++.c.lo:
++@am__fastdepCC_TRUE@	$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
++@am__fastdepCC_TRUE@	$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
++@AMDEP_TRUE@@am__fastdepCC_FALSE@	DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++@am__fastdepCC_FALSE@	$(LTCOMPILE) -c -o $@ $<
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++
++ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
++	list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	mkid -fID $$unique
++tags: TAGS
++
++TAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	set x; \
++	here=`pwd`; \
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	shift; \
++	if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
++	  test -n "$$unique" || unique=$$empty_fix; \
++	  if test $$# -gt 0; then \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      "$$@" $$unique; \
++	  else \
++	    $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
++	      $$unique; \
++	  fi; \
++	fi
++ctags: CTAGS
++CTAGS:  $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
++		$(TAGS_FILES) $(LISP)
++	list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
++	unique=`for i in $$list; do \
++	    if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
++	  done | \
++	  $(AWK) '{ files[$$0] = 1; nonempty = 1; } \
++	      END { if (nonempty) { for (i in files) print i; }; }'`; \
++	test -z "$(CTAGS_ARGS)$$unique" \
++	  || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
++	     $$unique
++
++GTAGS:
++	here=`$(am__cd) $(top_builddir) && pwd` \
++	  && $(am__cd) $(top_srcdir) \
++	  && gtags -i $(GTAGS_ARGS) "$$here"
++
++distclean-tags:
++	-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
++
++check-TESTS: $(TESTS)
++	@failed=0; all=0; xfail=0; xpass=0; skip=0; \
++	srcdir=$(srcdir); export srcdir; \
++	list=' $(TESTS) '; \
++	$(am__tty_colors); \
++	if test -n "$$list"; then \
++	  for tst in $$list; do \
++	    if test -f ./$$tst; then dir=./; \
++	    elif test -f $$tst; then dir=; \
++	    else dir="$(srcdir)/"; fi; \
++	    if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xpass=`expr $$xpass + 1`; \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=XPASS; \
++	      ;; \
++	      *) \
++		col=$$grn; res=PASS; \
++	      ;; \
++	      esac; \
++	    elif test $$? -ne 77; then \
++	      all=`expr $$all + 1`; \
++	      case " $(XFAIL_TESTS) " in \
++	      *[\ \	]$$tst[\ \	]*) \
++		xfail=`expr $$xfail + 1`; \
++		col=$$lgn; res=XFAIL; \
++	      ;; \
++	      *) \
++		failed=`expr $$failed + 1`; \
++		col=$$red; res=FAIL; \
++	      ;; \
++	      esac; \
++	    else \
++	      skip=`expr $$skip + 1`; \
++	      col=$$blu; res=SKIP; \
++	    fi; \
++	    echo "$${col}$$res$${std}: $$tst"; \
++	  done; \
++	  if test "$$all" -eq 1; then \
++	    tests="test"; \
++	    All=""; \
++	  else \
++	    tests="tests"; \
++	    All="All "; \
++	  fi; \
++	  if test "$$failed" -eq 0; then \
++	    if test "$$xfail" -eq 0; then \
++	      banner="$$All$$all $$tests passed"; \
++	    else \
++	      if test "$$xfail" -eq 1; then failures=failure; else failures=failures; fi; \
++	      banner="$$All$$all $$tests behaved as expected ($$xfail expected $$failures)"; \
++	    fi; \
++	  else \
++	    if test "$$xpass" -eq 0; then \
++	      banner="$$failed of $$all $$tests failed"; \
++	    else \
++	      if test "$$xpass" -eq 1; then passes=pass; else passes=passes; fi; \
++	      banner="$$failed of $$all $$tests did not behave as expected ($$xpass unexpected $$passes)"; \
++	    fi; \
++	  fi; \
++	  dashes="$$banner"; \
++	  skipped=""; \
++	  if test "$$skip" -ne 0; then \
++	    if test "$$skip" -eq 1; then \
++	      skipped="($$skip test was not run)"; \
++	    else \
++	      skipped="($$skip tests were not run)"; \
++	    fi; \
++	    test `echo "$$skipped" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$skipped"; \
++	  fi; \
++	  report=""; \
++	  if test "$$failed" -ne 0 && test -n "$(PACKAGE_BUGREPORT)"; then \
++	    report="Please report to $(PACKAGE_BUGREPORT)"; \
++	    test `echo "$$report" | wc -c` -le `echo "$$banner" | wc -c` || \
++	      dashes="$$report"; \
++	  fi; \
++	  dashes=`echo "$$dashes" | sed s/./=/g`; \
++	  if test "$$failed" -eq 0; then \
++	    echo "$$grn$$dashes"; \
++	  else \
++	    echo "$$red$$dashes"; \
++	  fi; \
++	  echo "$$banner"; \
++	  test -z "$$skipped" || echo "$$skipped"; \
++	  test -z "$$report" || echo "$$report"; \
++	  echo "$$dashes$$std"; \
++	  test "$$failed" -eq 0; \
++	else :; fi
++
++distdir: $(DISTFILES)
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-TESTS check-local
++check: check-am
++all-am: Makefile $(LTLIBRARIES) $(DATA) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(libdir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libLTLIBRARIES clean-libtool \
++	mostlyclean-am
++
++distclean: distclean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++distclean-am: clean-am distclean-compile distclean-generic \
++	distclean-tags
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am:
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man:
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -rf ./$(DEPDIR)
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-compile mostlyclean-generic \
++	mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-libLTLIBRARIES
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: CTAGS GTAGS all all-am all-local check check-TESTS check-am \
++	check-local clean clean-generic clean-libLTLIBRARIES \
++	clean-libtool ctags dist-hook distclean distclean-compile \
++	distclean-generic distclean-libtool distclean-tags distdir dvi \
++	dvi-am html html-am info info-am install install-am \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-libLTLIBRARIES install-man install-pdf install-pdf-am \
++	install-ps install-ps-am install-strip installcheck \
++	installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-compile \
++	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
++	tags uninstall uninstall-am uninstall-hook \
++	uninstall-libLTLIBRARIES
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++check-pac: check-pac.in Makefile
++	$(do_subst) < $(srcdir)/check-pac.in > check-pac.tmp
++	chmod +x check-pac.tmp
++	mv check-pac.tmp check-pac
++
++krb5.conf: krb5.conf.in Makefile
++	$(do_subst) < $(srcdir)/krb5.conf.in > krb5.conf.tmp
++	mv krb5.conf.tmp krb5.conf
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/tools/Makefile.in
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/tools/Makefile.in	2010-12-29 04:07:18.118841422 +0100
+@@ -0,0 +1,893 @@
++# Makefile.in generated by automake 1.11.1 from Makefile.am.
++# @configure_input@
++
++# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
++# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
++# Inc.
++# This Makefile.in is free software; the Free Software Foundation
++# gives unlimited permission to copy and/or distribute it,
++# with or without modifications, as long as this notice is preserved.
++
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
++# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
++# PARTICULAR PURPOSE.
++
++@SET_MAKE@
++
++# $Id$
++
++# $Id$
++
++# $Id$
++
++
++VPATH = @srcdir@
++pkgdatadir = $(datadir)/@PACKAGE@
++pkgincludedir = $(includedir)/@PACKAGE@
++pkglibdir = $(libdir)/@PACKAGE@
++pkglibexecdir = $(libexecdir)/@PACKAGE@
++am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
++install_sh_DATA = $(install_sh) -c -m 644
++install_sh_PROGRAM = $(install_sh) -c
++install_sh_SCRIPT = $(install_sh) -c
++INSTALL_HEADER = $(INSTALL_DATA)
++transform = $(program_transform_name)
++NORMAL_INSTALL = :
++PRE_INSTALL = :
++POST_INSTALL = :
++NORMAL_UNINSTALL = :
++PRE_UNINSTALL = :
++POST_UNINSTALL = :
++build_triplet = @build@
++host_triplet = @host@
++DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
++	$(top_srcdir)/Makefile.am.common \
++	$(top_srcdir)/cf/Makefile.am.common
++subdir = tools
++ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
++am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
++	$(top_srcdir)/cf/auth-modules.m4 \
++	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
++	$(top_srcdir)/cf/broken-glob.m4 \
++	$(top_srcdir)/cf/broken-realloc.m4 \
++	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
++	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
++	$(top_srcdir)/cf/capabilities.m4 \
++	$(top_srcdir)/cf/check-compile-et.m4 \
++	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
++	$(top_srcdir)/cf/check-man.m4 \
++	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
++	$(top_srcdir)/cf/check-type-extra.m4 \
++	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
++	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
++	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
++	$(top_srcdir)/cf/dispatch.m4 $(top_srcdir)/cf/dlopen.m4 \
++	$(top_srcdir)/cf/find-func-no-libs.m4 \
++	$(top_srcdir)/cf/find-func-no-libs2.m4 \
++	$(top_srcdir)/cf/find-func.m4 \
++	$(top_srcdir)/cf/find-if-not-broken.m4 \
++	$(top_srcdir)/cf/framework-security.m4 \
++	$(top_srcdir)/cf/have-struct-field.m4 \
++	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
++	$(top_srcdir)/cf/krb-bigendian.m4 \
++	$(top_srcdir)/cf/krb-func-getlogin.m4 \
++	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
++	$(top_srcdir)/cf/krb-readline.m4 \
++	$(top_srcdir)/cf/krb-struct-spwd.m4 \
++	$(top_srcdir)/cf/krb-struct-winsize.m4 \
++	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/libtool.m4 \
++	$(top_srcdir)/cf/ltoptions.m4 $(top_srcdir)/cf/ltsugar.m4 \
++	$(top_srcdir)/cf/ltversion.m4 $(top_srcdir)/cf/lt~obsolete.m4 \
++	$(top_srcdir)/cf/mips-abi.m4 $(top_srcdir)/cf/misc.m4 \
++	$(top_srcdir)/cf/need-proto.m4 $(top_srcdir)/cf/osfc2.m4 \
++	$(top_srcdir)/cf/otp.m4 $(top_srcdir)/cf/pkg.m4 \
++	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
++	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
++	$(top_srcdir)/cf/roken-frag.m4 \
++	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
++	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
++	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
++	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
++	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.ac
++am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
++	$(ACLOCAL_M4)
++mkinstalldirs = $(install_sh) -d
++CONFIG_HEADER = $(top_builddir)/include/config.h
++CONFIG_CLEAN_FILES =
++CONFIG_CLEAN_VPATH_FILES =
++am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
++am__vpath_adj = case $$p in \
++    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
++    *) f=$$p;; \
++  esac;
++am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
++am__install_max = 40
++am__nobase_strip_setup = \
++  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
++am__nobase_strip = \
++  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
++am__nobase_list = $(am__nobase_strip_setup); \
++  for p in $$list; do echo "$$p $$p"; done | \
++  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
++  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
++    if (++n[$$2] == $(am__install_max)) \
++      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
++    END { for (dir in files) print dir, files[dir] }'
++am__base_list = \
++  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
++  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
++am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)" \
++	"$(DESTDIR)$(pkgconfigdir)"
++SCRIPTS = $(bin_SCRIPTS)
++SOURCES =
++DIST_SOURCES =
++man1dir = $(mandir)/man1
++MANS = $(man_MANS)
++DATA = $(pkgconfig_DATA)
++DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
++ACLOCAL = @ACLOCAL@
++AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
++AMTAR = @AMTAR@
++AR = @AR@
++ASN1_COMPILE = @ASN1_COMPILE@
++ASN1_COMPILE_DEP = @ASN1_COMPILE_DEP@
++AUTOCONF = @AUTOCONF@
++AUTOHEADER = @AUTOHEADER@
++AUTOMAKE = @AUTOMAKE@
++AWK = @AWK@
++CANONICAL_HOST = @CANONICAL_HOST@
++CAPNG_CFLAGS = @CAPNG_CFLAGS@
++CAPNG_LIBS = @CAPNG_LIBS@
++CATMAN = @CATMAN@
++CATMANEXT = @CATMANEXT@
++CC = @CC@
++CCDEPMODE = @CCDEPMODE@
++CFLAGS = @CFLAGS@
++COMPILE_ET = @COMPILE_ET@
++CPP = @CPP@
++CPPFLAGS = @CPPFLAGS@
++CYGPATH_W = @CYGPATH_W@
++DBHEADER = @DBHEADER@
++DBLIB = @DBLIB@
++DEFS = @DEFS@
++DEPDIR = @DEPDIR@
++DIR_com_err = @DIR_com_err@
++DIR_hcrypto = @DIR_hcrypto@
++DIR_hdbdir = @DIR_hdbdir@
++DIR_roken = @DIR_roken@
++DSYMUTIL = @DSYMUTIL@
++DUMPBIN = @DUMPBIN@
++ECHO_C = @ECHO_C@
++ECHO_N = @ECHO_N@
++ECHO_T = @ECHO_T@
++EGREP = @EGREP@
++EXEEXT = @EXEEXT@
++FGREP = @FGREP@
++GREP = @GREP@
++GROFF = @GROFF@
++INCLUDES_roken = @INCLUDES_roken@
++INCLUDE_hcrypto = @INCLUDE_hcrypto@
++INCLUDE_hesiod = @INCLUDE_hesiod@
++INCLUDE_krb4 = @INCLUDE_krb4@
++INCLUDE_libintl = @INCLUDE_libintl@
++INCLUDE_openldap = @INCLUDE_openldap@
++INCLUDE_readline = @INCLUDE_readline@
++INCLUDE_sqlite3 = @INCLUDE_sqlite3@
++INSTALL = @INSTALL@
++INSTALL_DATA = @INSTALL_DATA@
++INSTALL_PROGRAM = @INSTALL_PROGRAM@
++INSTALL_SCRIPT = @INSTALL_SCRIPT@
++INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
++LD = @LD@
++LDFLAGS = @LDFLAGS@
++LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
++LEX = @LEX@
++LEXLIB = @LEXLIB@
++LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
++LIBADD_roken = @LIBADD_roken@
++LIBOBJS = @LIBOBJS@
++LIBS = @LIBS@
++LIBTOOL = @LIBTOOL@
++LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
++LIB_NDBM = @LIB_NDBM@
++LIB_XauFileName = @LIB_XauFileName@
++LIB_XauReadAuth = @LIB_XauReadAuth@
++LIB_XauWriteAuth = @LIB_XauWriteAuth@
++LIB_bswap16 = @LIB_bswap16@
++LIB_bswap32 = @LIB_bswap32@
++LIB_com_err = @LIB_com_err@
++LIB_com_err_a = @LIB_com_err_a@
++LIB_com_err_so = @LIB_com_err_so@
++LIB_crypt = @LIB_crypt@
++LIB_db_create = @LIB_db_create@
++LIB_dbm_firstkey = @LIB_dbm_firstkey@
++LIB_dbopen = @LIB_dbopen@
++LIB_dispatch_async_f = @LIB_dispatch_async_f@
++LIB_dlopen = @LIB_dlopen@
++LIB_dn_expand = @LIB_dn_expand@
++LIB_dns_search = @LIB_dns_search@
++LIB_door_create = @LIB_door_create@
++LIB_el_init = @LIB_el_init@
++LIB_freeaddrinfo = @LIB_freeaddrinfo@
++LIB_gai_strerror = @LIB_gai_strerror@
++LIB_getaddrinfo = @LIB_getaddrinfo@
++LIB_gethostbyname = @LIB_gethostbyname@
++LIB_gethostbyname2 = @LIB_gethostbyname2@
++LIB_getnameinfo = @LIB_getnameinfo@
++LIB_getpwnam_r = @LIB_getpwnam_r@
++LIB_getsockopt = @LIB_getsockopt@
++LIB_hcrypto = @LIB_hcrypto@
++LIB_hcrypto_a = @LIB_hcrypto_a@
++LIB_hcrypto_appl = @LIB_hcrypto_appl@
++LIB_hcrypto_so = @LIB_hcrypto_so@
++LIB_hesiod = @LIB_hesiod@
++LIB_hstrerror = @LIB_hstrerror@
++LIB_kdb = @LIB_kdb@
++LIB_krb4 = @LIB_krb4@
++LIB_libintl = @LIB_libintl@
++LIB_loadquery = @LIB_loadquery@
++LIB_logout = @LIB_logout@
++LIB_logwtmp = @LIB_logwtmp@
++LIB_openldap = @LIB_openldap@
++LIB_openpty = @LIB_openpty@
++LIB_otp = @LIB_otp@
++LIB_pidfile = @LIB_pidfile@
++LIB_readline = @LIB_readline@
++LIB_res_ndestroy = @LIB_res_ndestroy@
++LIB_res_nsearch = @LIB_res_nsearch@
++LIB_res_search = @LIB_res_search@
++LIB_roken = @LIB_roken@
++LIB_security = @LIB_security@
++LIB_setsockopt = @LIB_setsockopt@
++LIB_socket = @LIB_socket@
++LIB_sqlite3 = @LIB_sqlite3@
++LIB_syslog = @LIB_syslog@
++LIB_tgetent = @LIB_tgetent@
++LIPO = @LIPO@
++LN_S = @LN_S@
++LTLIBOBJS = @LTLIBOBJS@
++MAINT = @MAINT@
++MAKEINFO = @MAKEINFO@
++MKDIR_P = @MKDIR_P@
++NM = @NM@
++NMEDIT = @NMEDIT@
++NO_AFS = @NO_AFS@
++NROFF = @NROFF@
++OBJDUMP = @OBJDUMP@
++OBJEXT = @OBJEXT@
++OTOOL = @OTOOL@
++OTOOL64 = @OTOOL64@
++PACKAGE = @PACKAGE@
++PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
++PACKAGE_NAME = @PACKAGE_NAME@
++PACKAGE_STRING = @PACKAGE_STRING@
++PACKAGE_TARNAME = @PACKAGE_TARNAME@
++PACKAGE_URL = @PACKAGE_URL@
++PACKAGE_VERSION = @PACKAGE_VERSION@
++PATH_SEPARATOR = @PATH_SEPARATOR@
++PKG_CONFIG = @PKG_CONFIG@
++PTHREAD_CFLAGS = @PTHREAD_CFLAGS@
++PTHREAD_LDADD = @PTHREAD_LDADD@
++PTHREAD_LIBADD = @PTHREAD_LIBADD@
++RANLIB = @RANLIB@
++SED = @SED@
++SET_MAKE = @SET_MAKE@
++SHELL = @SHELL@
++SLC = @SLC@
++SLC_DEP = @SLC_DEP@
++STRIP = @STRIP@
++VERSION = @VERSION@
++VERSIONING = @VERSIONING@
++WFLAGS = @WFLAGS@
++WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
++WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
++XMKMF = @XMKMF@
++X_CFLAGS = @X_CFLAGS@
++X_EXTRA_LIBS = @X_EXTRA_LIBS@
++X_LIBS = @X_LIBS@
++X_PRE_LIBS = @X_PRE_LIBS@
++YACC = @YACC@
++YFLAGS = @YFLAGS@
++abs_builddir = @abs_builddir@
++abs_srcdir = @abs_srcdir@
++abs_top_builddir = @abs_top_builddir@
++abs_top_srcdir = @abs_top_srcdir@
++ac_ct_CC = @ac_ct_CC@
++ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
++am__include = @am__include@
++am__leading_dot = @am__leading_dot@
++am__quote = @am__quote@
++am__tar = @am__tar@
++am__untar = @am__untar@
++bindir = @bindir@
++build = @build@
++build_alias = @build_alias@
++build_cpu = @build_cpu@
++build_os = @build_os@
++build_vendor = @build_vendor@
++builddir = @builddir@
++datadir = @datadir@
++datarootdir = @datarootdir@
++docdir = @docdir@
++dpagaix_cflags = @dpagaix_cflags@
++dpagaix_ldadd = @dpagaix_ldadd@
++dpagaix_ldflags = @dpagaix_ldflags@
++dvidir = @dvidir@
++exec_prefix = @exec_prefix@
++host = @host@
++host_alias = @host_alias@
++host_cpu = @host_cpu@
++host_os = @host_os@
++host_vendor = @host_vendor@
++htmldir = @htmldir@
++includedir = @includedir@
++infodir = @infodir@
++install_sh = @install_sh@
++libdir = @libdir@
++libexecdir = @libexecdir@
++localedir = @localedir@
++localstatedir = @localstatedir@
++lt_ECHO = @lt_ECHO@
++mandir = @mandir@
++mkdir_p = @mkdir_p@
++oldincludedir = @oldincludedir@
++pdfdir = @pdfdir@
++prefix = @prefix@
++program_transform_name = @program_transform_name@
++psdir = @psdir@
++sbindir = @sbindir@
++sharedstatedir = @sharedstatedir@
++srcdir = @srcdir@
++sysconfdir = @sysconfdir@
++target_alias = @target_alias@
++top_build_prefix = @top_build_prefix@
++top_builddir = @top_builddir@
++top_srcdir = @top_srcdir@
++SUFFIXES = .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
++DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/include -I$(top_srcdir)/include
++AM_CPPFLAGS = $(INCLUDES_roken)
++@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
++AM_CFLAGS = $(WFLAGS)
++CP = cp
++buildinclude = $(top_builddir)/include
++LIB_getattr = @LIB_getattr@
++LIB_getpwent_r = @LIB_getpwent_r@
++LIB_odm_initialize = @LIB_odm_initialize@
++LIB_setpcred = @LIB_setpcred@
++HESIODLIB = @HESIODLIB@
++HESIODINCLUDE = @HESIODINCLUDE@
++libexec_heimdaldir = $(libexecdir)/heimdal
++NROFF_MAN = groff -mandoc -Tascii
++LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
++@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
++@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
++
++@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
++LIB_heimbase = $(top_builddir)/base/libheimbase.la
++@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
++bin_SCRIPTS = krb5-config
++pkgconfigdir = $(libdir)/pkgconfig
++pkgconfig_DATA = heimdal-gssapi.pc
++man_MANS = krb5-config.1
++@PKINIT_TRUE@LIB_pkinit = -lhx509
++subst = sed	-e "s!@PACKAGE\@!$(PACKAGE)!g" \
++		-e "s!@VERSION\@!$(VERSION)!g" \
++		-e "s!@prefix\@!$(prefix)!g" \
++		-e "s!@exec_prefix\@!$(exec_prefix)!g" \
++		-e "s!@libdir\@!$(libdir)!g" \
++		-e "s!@includedir\@!$(includedir)!g" \
++		-e "s!@PTHREAD_LIBADD\@!$(PTHREAD_LIBADD)!g" \
++		-e "s!@LIB_crypt\@!$(LIB_crypt)!g" \
++		-e "s!@LIB_dbopen\@!$(LIB_dbopen)!g" \
++		-e "s!@INCLUDE_hcrypto\@!$(INCLUDE_hcrypto)!g" \
++		-e "s!@LIB_hcrypto_appl\@!$(LIB_hcrypto_appl)!g" \
++		-e "s!@LIB_dlopen\@!$(LIB_dlopen)!g" \
++		-e "s!@LIB_door_create\@!$(LIB_door_create)!g" \
++		-e "s!@LIB_pkinit\@!$(LIB_pkinit)!g" \
++		-e "s!@LIBS\@!$(LIBS)!g"
++
++EXTRA_DIST = \
++	$(man_MANS) \
++	krb5-config.in \
++	heimdal-gssapi.pc.in \
++	kdc-log-analyze.pl
++
++CLEANFILES = \
++	krb5-config \
++	krb5-config.new \
++	heimdal-gssapi.pc \
++	heimdal-gssapi.pc.new
++
++all: all-am
++
++.SUFFIXES:
++.SUFFIXES: .et .h .x .z .hx .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c
++$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
++	@for dep in $?; do \
++	  case '$(am__configure_deps)' in \
++	    *$$dep*) \
++	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
++	        && { if test -f $@; then exit 0; else break; fi; }; \
++	      exit 1;; \
++	  esac; \
++	done; \
++	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign tools/Makefile'; \
++	$(am__cd) $(top_srcdir) && \
++	  $(AUTOMAKE) --foreign tools/Makefile
++.PRECIOUS: Makefile
++Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
++	@case '$?' in \
++	  *config.status*) \
++	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
++	  *) \
++	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
++	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
++	esac;
++
++$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++
++$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
++	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
++$(am__aclocal_m4_deps):
++install-binSCRIPTS: $(bin_SCRIPTS)
++	@$(NORMAL_INSTALL)
++	test -z "$(bindir)" || $(MKDIR_P) "$(DESTDIR)$(bindir)"
++	@list='$(bin_SCRIPTS)'; test -n "$(bindir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  if test -f "$$d$$p"; then echo "$$d$$p"; echo "$$p"; else :; fi; \
++	done | \
++	sed -e 'p;s,.*/,,;n' \
++	    -e 'h;s|.*|.|' \
++	    -e 'p;x;s,.*/,,;$(transform)' | sed 'N;N;N;s,\n, ,g' | \
++	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1; } \
++	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
++	    if ($$2 == $$4) { files[d] = files[d] " " $$1; \
++	      if (++n[d] == $(am__install_max)) { \
++		print "f", d, files[d]; n[d] = 0; files[d] = "" } } \
++	    else { print "f", d "/" $$4, $$1 } } \
++	  END { for (d in files) print "f", d, files[d] }' | \
++	while read type dir files; do \
++	     if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
++	     test -z "$$files" || { \
++	       echo " $(INSTALL_SCRIPT) $$files '$(DESTDIR)$(bindir)$$dir'"; \
++	       $(INSTALL_SCRIPT) $$files "$(DESTDIR)$(bindir)$$dir" || exit $$?; \
++	     } \
++	; done
++
++uninstall-binSCRIPTS:
++	@$(NORMAL_UNINSTALL)
++	@list='$(bin_SCRIPTS)'; test -n "$(bindir)" || exit 0; \
++	files=`for p in $$list; do echo "$$p"; done | \
++	       sed -e 's,.*/,,;$(transform)'`; \
++	test -n "$$list" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(bindir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(bindir)" && rm -f $$files
++
++mostlyclean-libtool:
++	-rm -f *.lo
++
++clean-libtool:
++	-rm -rf .libs _libs
++install-man1: $(man_MANS)
++	@$(NORMAL_INSTALL)
++	test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)"
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | while read p; do \
++	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; echo "$$p"; \
++	done | \
++	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
++	sed 'N;N;s,\n, ,g' | { \
++	list=; while read file base inst; do \
++	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
++	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \
++	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \
++	  fi; \
++	done; \
++	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
++	while read files; do \
++	  test -z "$$files" || { \
++	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \
++	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \
++	done; }
++
++uninstall-man1:
++	@$(NORMAL_UNINSTALL)
++	@list=''; test -n "$(man1dir)" || exit 0; \
++	files=`{ for i in $$list; do echo "$$i"; done; \
++	l2='$(man_MANS)'; for i in $$l2; do echo "$$i"; done | \
++	  sed -n '/\.1[a-z]*$$/p'; \
++	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \
++	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
++	test -z "$$files" || { \
++	  echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \
++	  cd "$(DESTDIR)$(man1dir)" && rm -f $$files; }
++install-pkgconfigDATA: $(pkgconfig_DATA)
++	@$(NORMAL_INSTALL)
++	test -z "$(pkgconfigdir)" || $(MKDIR_P) "$(DESTDIR)$(pkgconfigdir)"
++	@list='$(pkgconfig_DATA)'; test -n "$(pkgconfigdir)" || list=; \
++	for p in $$list; do \
++	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
++	  echo "$$d$$p"; \
++	done | $(am__base_list) | \
++	while read files; do \
++	  echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(pkgconfigdir)'"; \
++	  $(INSTALL_DATA) $$files "$(DESTDIR)$(pkgconfigdir)" || exit $$?; \
++	done
++
++uninstall-pkgconfigDATA:
++	@$(NORMAL_UNINSTALL)
++	@list='$(pkgconfig_DATA)'; test -n "$(pkgconfigdir)" || list=; \
++	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
++	test -n "$$files" || exit 0; \
++	echo " ( cd '$(DESTDIR)$(pkgconfigdir)' && rm -f" $$files ")"; \
++	cd "$(DESTDIR)$(pkgconfigdir)" && rm -f $$files
++tags: TAGS
++TAGS:
++
++ctags: CTAGS
++CTAGS:
++
++
++distdir: $(DISTFILES)
++	@list='$(MANS)'; if test -n "$$list"; then \
++	  list=`for p in $$list; do \
++	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
++	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
++	  if test -n "$$list" && \
++	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
++	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
++	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
++	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
++	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
++	    exit 1; \
++	  else :; fi; \
++	else :; fi
++	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
++	list='$(DISTFILES)'; \
++	  dist_files=`for file in $$list; do echo $$file; done | \
++	  sed -e "s|^$$srcdirstrip/||;t" \
++	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
++	case $$dist_files in \
++	  */*) $(MKDIR_P) `echo "$$dist_files" | \
++			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
++			   sort -u` ;; \
++	esac; \
++	for file in $$dist_files; do \
++	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
++	  if test -d $$d/$$file; then \
++	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
++	    if test -d "$(distdir)/$$file"; then \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
++	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
++	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
++	    fi; \
++	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
++	  else \
++	    test -f "$(distdir)/$$file" \
++	    || cp -p $$d/$$file "$(distdir)/$$file" \
++	    || exit 1; \
++	  fi; \
++	done
++	$(MAKE) $(AM_MAKEFLAGS) \
++	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
++	  dist-hook
++check-am: all-am
++	$(MAKE) $(AM_MAKEFLAGS) check-local
++check: check-am
++all-am: Makefile $(SCRIPTS) $(MANS) $(DATA) all-local
++installdirs:
++	for dir in "$(DESTDIR)$(bindir)" "$(DESTDIR)$(man1dir)" "$(DESTDIR)$(pkgconfigdir)"; do \
++	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
++	done
++install: install-am
++install-exec: install-exec-am
++install-data: install-data-am
++uninstall: uninstall-am
++
++install-am: all-am
++	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
++
++installcheck: installcheck-am
++install-strip:
++	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
++	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
++	  `test -z '$(STRIP)' || \
++	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
++mostlyclean-generic:
++
++clean-generic:
++	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
++
++distclean-generic:
++	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
++	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
++
++maintainer-clean-generic:
++	@echo "This command is intended for maintainers to use"
++	@echo "it deletes files that may require special tools to rebuild."
++clean: clean-am
++
++clean-am: clean-generic clean-libtool mostlyclean-am
++
++distclean: distclean-am
++	-rm -f Makefile
++distclean-am: clean-am distclean-generic
++
++dvi: dvi-am
++
++dvi-am:
++
++html: html-am
++
++html-am:
++
++info: info-am
++
++info-am:
++
++install-data-am: install-man install-pkgconfigDATA
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
++install-dvi: install-dvi-am
++
++install-dvi-am:
++
++install-exec-am: install-binSCRIPTS
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
++install-html: install-html-am
++
++install-html-am:
++
++install-info: install-info-am
++
++install-info-am:
++
++install-man: install-man1
++
++install-pdf: install-pdf-am
++
++install-pdf-am:
++
++install-ps: install-ps-am
++
++install-ps-am:
++
++installcheck-am:
++
++maintainer-clean: maintainer-clean-am
++	-rm -f Makefile
++maintainer-clean-am: distclean-am maintainer-clean-generic
++
++mostlyclean: mostlyclean-am
++
++mostlyclean-am: mostlyclean-generic mostlyclean-libtool
++
++pdf: pdf-am
++
++pdf-am:
++
++ps: ps-am
++
++ps-am:
++
++uninstall-am: uninstall-binSCRIPTS uninstall-man \
++	uninstall-pkgconfigDATA
++	@$(NORMAL_INSTALL)
++	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
++uninstall-man: uninstall-man1
++
++.MAKE: check-am install-am install-data-am install-exec-am \
++	install-strip uninstall-am
++
++.PHONY: all all-am all-local check check-am check-local clean \
++	clean-generic clean-libtool dist-hook distclean \
++	distclean-generic distclean-libtool distdir dvi dvi-am html \
++	html-am info info-am install install-am install-binSCRIPTS \
++	install-data install-data-am install-data-hook install-dvi \
++	install-dvi-am install-exec install-exec-am install-exec-hook \
++	install-html install-html-am install-info install-info-am \
++	install-man install-man1 install-pdf install-pdf-am \
++	install-pkgconfigDATA install-ps install-ps-am install-strip \
++	installcheck installcheck-am installdirs maintainer-clean \
++	maintainer-clean-generic mostlyclean mostlyclean-generic \
++	mostlyclean-libtool pdf pdf-am ps ps-am uninstall uninstall-am \
++	uninstall-binSCRIPTS uninstall-hook uninstall-man \
++	uninstall-man1 uninstall-pkgconfigDATA
++
++
++install-suid-programs:
++	@foo='$(bin_SUIDS)'; \
++	for file in $$foo; do \
++	x=$(DESTDIR)$(bindir)/$$file; \
++	if chown 0:0 $$x && chmod u+s $$x; then :; else \
++	echo "*"; \
++	echo "* Failed to install $$x setuid root"; \
++	echo "*"; \
++	fi; done
++
++install-exec-hook: install-suid-programs
++
++install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
++	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
++	for f in $$foo; do \
++		f=`basename $$f`; \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done ; \
++	foo='$(nobase_include_HEADERS)'; \
++	for f in $$foo; do \
++		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
++		else file="$$f"; fi; \
++		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
++		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
++		: ; else \
++			echo " $(CP) $$file $(buildinclude)/$$f"; \
++			$(CP) $$file $(buildinclude)/$$f; \
++		fi ; \
++	done
++
++all-local: install-build-headers
++
++check-local::
++	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
++	  foo=''; elif test '$(CHECK_LOCAL)'; then \
++	  foo='$(CHECK_LOCAL)'; else \
++	  foo='$(PROGRAMS)'; fi; \
++	  if test "$$foo"; then \
++	  failed=0; all=0; \
++	  for i in $$foo; do \
++	    all=`expr $$all + 1`; \
++	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
++	      echo "PASS: $$i"; \
++	    else \
++	      echo "FAIL: $$i"; \
++	      failed=`expr $$failed + 1`; \
++	    fi; \
++	  done; \
++	  if test "$$failed" -eq 0; then \
++	    banner="All $$all tests passed"; \
++	  else \
++	    banner="$$failed of $$all tests failed"; \
++	  fi; \
++	  dashes=`echo "$$banner" | sed s/./=/g`; \
++	  echo "$$dashes"; \
++	  echo "$$banner"; \
++	  echo "$$dashes"; \
++	  test "$$failed" -eq 0 || exit 1; \
++	fi
++
++.x.c:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++
++.hx.h:
++	@cmp -s $< $@ 2> /dev/null || cp $< $@
++#NROFF_MAN = nroff -man
++.1.cat1:
++	$(NROFF_MAN) $< > $@
++.3.cat3:
++	$(NROFF_MAN) $< > $@
++.5.cat5:
++	$(NROFF_MAN) $< > $@
++.8.cat8:
++	$(NROFF_MAN) $< > $@
++
++dist-cat1-mans:
++	@foo='$(man1_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.1) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat3-mans:
++	@foo='$(man3_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.3) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat5-mans:
++	@foo='$(man5_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.5) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-cat8-mans:
++	@foo='$(man8_MANS)'; \
++	bar='$(man_MANS)'; \
++	for i in $$bar; do \
++	case $$i in \
++	*.8) foo="$$foo $$i";; \
++	esac; done ;\
++	for i in $$foo; do \
++		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
++		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
++		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
++	done
++
++dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
++
++install-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++uninstall-cat-mans:
++	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
++
++install-data-hook: install-cat-mans
++uninstall-hook: uninstall-cat-mans
++
++.et.h:
++	$(COMPILE_ET) $<
++.et.c:
++	$(COMPILE_ET) $<
++
++#
++# Useful target for debugging
++#
++
++check-valgrind:
++	tobjdir=`cd $(top_builddir) && pwd` ; \
++	tsrcdir=`cd $(top_srcdir) && pwd` ; \
++	env TESTS_ENVIRONMENT="$${tsrcdir}/cf/maybe-valgrind.sh -s $${tsrcdir} -o $${tobjdir}" make check
++
++#
++# Target to please samba build farm, builds distfiles in-tree.
++# Will break when automake changes...
++#
++
++distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
++	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
++	  if test "$$subdir" != .; then \
++	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
++	  fi ; \
++	done
++
++krb5-config: krb5-config.in
++	$(subst) $(srcdir)/krb5-config.in > $@.new
++	mv $@.new $@
++	chmod +x $@
++
++heimdal-gssapi.pc: heimdal-gssapi.pc.in
++	$(subst) $(srcdir)/heimdal-gssapi.pc.in > $@.new
++	mv $@.new $@
++
++# Tell versions [3.59,3.63) of GNU make to not export all variables.
++# Otherwise a system limit (for SysV at least) may be exceeded.
++.NOEXPORT:
+Index: git/ylwrap
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ git/ylwrap	2010-12-29 04:04:06.000000000 +0100
+@@ -0,0 +1,222 @@
++#! /bin/sh
++# ylwrap - wrapper for lex/yacc invocations.
++
++scriptversion=2009-04-28.21; # UTC
++
++# Copyright (C) 1996, 1997, 1998, 1999, 2001, 2002, 2003, 2004, 2005,
++# 2007, 2009 Free Software Foundation, Inc.
++#
++# Written by Tom Tromey <tromey@cygnus.com>.
++#
++# This program is free software; you can redistribute it and/or modify
++# it under the terms of the GNU General Public License as published by
++# the Free Software Foundation; either version 2, or (at your option)
++# any later version.
++#
++# This program is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY; without even the implied warranty of
++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++# GNU General Public License for more details.
++#
++# You should have received a copy of the GNU General Public License
++# along with this program.  If not, see <http://www.gnu.org/licenses/>.
++
++# As a special exception to the GNU General Public License, if you
++# distribute this file as part of a program that contains a
++# configuration script generated by Autoconf, you may include it under
++# the same distribution terms that you use for the rest of that program.
++
++# This file is maintained in Automake, please report
++# bugs to <bug-automake@gnu.org> or send patches to
++# <automake-patches@gnu.org>.
++
++case "$1" in
++  '')
++    echo "$0: No files given.  Try \`$0 --help' for more information." 1>&2
++    exit 1
++    ;;
++  --basedir)
++    basedir=$2
++    shift 2
++    ;;
++  -h|--h*)
++    cat <<\EOF
++Usage: ylwrap [--help|--version] INPUT [OUTPUT DESIRED]... -- PROGRAM [ARGS]...
++
++Wrapper for lex/yacc invocations, renaming files as desired.
++
++  INPUT is the input file
++  OUTPUT is one file PROG generates
++  DESIRED is the file we actually want instead of OUTPUT
++  PROGRAM is program to run
++  ARGS are passed to PROG
++
++Any number of OUTPUT,DESIRED pairs may be used.
++
++Report bugs to <bug-automake@gnu.org>.
++EOF
++    exit $?
++    ;;
++  -v|--v*)
++    echo "ylwrap $scriptversion"
++    exit $?
++    ;;
++esac
++
++
++# The input.
++input="$1"
++shift
++case "$input" in
++  [\\/]* | ?:[\\/]*)
++    # Absolute path; do nothing.
++    ;;
++  *)
++    # Relative path.  Make it absolute.
++    input="`pwd`/$input"
++    ;;
++esac
++
++pairlist=
++while test "$#" -ne 0; do
++  if test "$1" = "--"; then
++    shift
++    break
++  fi
++  pairlist="$pairlist $1"
++  shift
++done
++
++# The program to run.
++prog="$1"
++shift
++# Make any relative path in $prog absolute.
++case "$prog" in
++  [\\/]* | ?:[\\/]*) ;;
++  *[\\/]*) prog="`pwd`/$prog" ;;
++esac
++
++# FIXME: add hostname here for parallel makes that run commands on
++# other machines.  But that might take us over the 14-char limit.
++dirname=ylwrap$$
++trap "cd '`pwd`'; rm -rf $dirname > /dev/null 2>&1" 1 2 3 15
++mkdir $dirname || exit 1
++
++cd $dirname
++
++case $# in
++  0) "$prog" "$input" ;;
++  *) "$prog" "$@" "$input" ;;
++esac
++ret=$?
++
++if test $ret -eq 0; then
++  set X $pairlist
++  shift
++  first=yes
++  # Since DOS filename conventions don't allow two dots,
++  # the DOS version of Bison writes out y_tab.c instead of y.tab.c
++  # and y_tab.h instead of y.tab.h. Test to see if this is the case.
++  y_tab_nodot="no"
++  if test -f y_tab.c || test -f y_tab.h; then
++    y_tab_nodot="yes"
++  fi
++
++  # The directory holding the input.
++  input_dir=`echo "$input" | sed -e 's,\([\\/]\)[^\\/]*$,\1,'`
++  # Quote $INPUT_DIR so we can use it in a regexp.
++  # FIXME: really we should care about more than `.' and `\'.
++  input_rx=`echo "$input_dir" | sed 's,\\\\,\\\\\\\\,g;s,\\.,\\\\.,g'`
++
++  while test "$#" -ne 0; do
++    from="$1"
++    # Handle y_tab.c and y_tab.h output by DOS
++    if test $y_tab_nodot = "yes"; then
++      if test $from = "y.tab.c"; then
++    	from="y_tab.c"
++      else
++    	if test $from = "y.tab.h"; then
++    	  from="y_tab.h"
++    	fi
++      fi
++    fi
++    if test -f "$from"; then
++      # If $2 is an absolute path name, then just use that,
++      # otherwise prepend `../'.
++      case "$2" in
++    	[\\/]* | ?:[\\/]*) target="$2";;
++    	*) target="../$2";;
++      esac
++
++      # We do not want to overwrite a header file if it hasn't
++      # changed.  This avoid useless recompilations.  However the
++      # parser itself (the first file) should always be updated,
++      # because it is the destination of the .y.c rule in the
++      # Makefile.  Divert the output of all other files to a temporary
++      # file so we can compare them to existing versions.
++      if test $first = no; then
++	realtarget="$target"
++	target="tmp-`echo $target | sed s/.*[\\/]//g`"
++      fi
++      # Edit out `#line' or `#' directives.
++      #
++      # We don't want the resulting debug information to point at
++      # an absolute srcdir; it is better for it to just mention the
++      # .y file with no path.
++      #
++      # We want to use the real output file name, not yy.lex.c for
++      # instance.
++      #
++      # We want the include guards to be adjusted too.
++      FROM=`echo "$from" | sed \
++            -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/'\
++            -e 's/[^ABCDEFGHIJKLMNOPQRSTUVWXYZ]/_/g'`
++      TARGET=`echo "$2" | sed \
++            -e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/'\
++            -e 's/[^ABCDEFGHIJKLMNOPQRSTUVWXYZ]/_/g'`
++
++      sed -e "/^#/!b" -e "s,$input_rx,," -e "s,$from,$2," \
++          -e "s,$FROM,$TARGET," "$from" >"$target" || ret=$?
++
++      # Check whether header files must be updated.
++      if test $first = no; then
++	if test -f "$realtarget" && cmp -s "$realtarget" "$target"; then
++	  echo "$2" is unchanged
++	  rm -f "$target"
++	else
++          echo updating "$2"
++          mv -f "$target" "$realtarget"
++        fi
++      fi
++    else
++      # A missing file is only an error for the first file.  This
++      # is a blatant hack to let us support using "yacc -d".  If -d
++      # is not specified, we don't want an error when the header
++      # file is "missing".
++      if test $first = yes; then
++        ret=1
++      fi
++    fi
++    shift
++    shift
++    first=no
++  done
++else
++  ret=$?
++fi
++
++# Remove the directory.
++cd ..
++rm -rf $dirname
++
++exit $ret
++
++# Local Variables:
++# mode: shell-script
++# sh-indentation: 2
++# eval: (add-hook 'write-file-hooks 'time-stamp)
++# time-stamp-start: "scriptversion="
++# time-stamp-format: "%:y-%02m-%02d.%02H"
++# time-stamp-time-zone: "UTC"
++# time-stamp-end: "; # UTC"
++# End:
diff --git a/debian/patches/debug b/debian/patches/debug
new file mode 100644
index 000000000..4025d5210
--- /dev/null
+++ b/debian/patches/debug
@@ -0,0 +1,14 @@
+Index: heimdal-1.4.0~git20100322/po/Makefile.am
+===================================================================
+--- heimdal-1.4.0~git20100322.orig/po/Makefile.am	2010-03-22 14:51:15.895792153 +1100
++++ heimdal-1.4.0~git20100322/po/Makefile.am	2010-03-22 15:02:26.845167021 +1100
+@@ -40,7 +40,8 @@
+ 	@for x in `cat $(srcdir)/localefiles` ; do \
+ 	    domain=`echo $$x | sed 's@/.*@@'`; \
+ 	    lang=`echo $$x | sed 's@.*/\(.*\)\\.mo$$@\1@'`; \
+-	    echo "installing lang $$domain $$lang" ; \
++	    echo "installing lang $$domain $$lang to $(DESTDIR) at $(localedir)" ; \
++        ls -l $(top_srcdir)/install-sh ; \
+ 	    $(top_srcdir)/install-sh -d \
+ 		"$(DESTDIR)$(localedir)/$$lang/LC_MESSAGES" ; \
+ 	    $(top_srcdir)/install-sh $(srcdir)/$$x \
diff --git a/debian/patches/installsh b/debian/patches/installsh
new file mode 100644
index 000000000..566923503
--- /dev/null
+++ b/debian/patches/installsh
@@ -0,0 +1,16 @@
+Index: heimdal-1.4.0~git20100322/po/Makefile.am
+===================================================================
+--- heimdal-1.4.0~git20100322.orig/po/Makefile.am	2010-03-22 15:12:40.005792886 +1100
++++ heimdal-1.4.0~git20100322/po/Makefile.am	2010-03-22 15:13:21.295167102 +1100
+@@ -41,9 +41,9 @@
+ 	    domain=`echo $$x | sed 's@/.*@@'`; \
+ 	    lang=`echo $$x | sed 's@.*/\(.*\)\\.mo$$@\1@'`; \
+ 	    echo "installing lang $$domain $$lang" ; \
+-	    $(top_srcdir)/install-sh -d \
++	    sh $(top_srcdir)/install-sh -d \
+ 		"$(DESTDIR)$(localedir)/$$lang/LC_MESSAGES" ; \
+-	    $(top_srcdir)/install-sh $(srcdir)/$$x \
++	    sh $(top_srcdir)/install-sh $(srcdir)/$$x \
+ 	        "$(DESTDIR)$(localedir)/$$lang/LC_MESSAGES/$$domain.mo" ; \
+ 	done
+ 
diff --git a/debian/patches/libedit b/debian/patches/libedit
new file mode 100644
index 000000000..072a5d015
--- /dev/null
+++ b/debian/patches/libedit
@@ -0,0 +1,13 @@
+Index: heimdal-1.3.1.dfsg.1/configure.ac
+===================================================================
+--- heimdal-1.3.1.dfsg.1.orig/configure.ac	2009-12-08 14:10:26.303036790 +1100
++++ heimdal-1.3.1.dfsg.1/configure.ac	2009-12-08 14:10:49.395035272 +1100
+@@ -254,7 +254,7 @@
+ 
+ rk_TEST_PACKAGE(readline,
+ [#include <stdio.h>
+- #include <readline.h>],-lreadline,,, READLINE)
++ #include <readline.h>],-ledit,,, READLINE)
+ 
+ rk_TEST_PACKAGE(hesiod,[#include <hesiod.h>],-lhesiod,,, HESIOD)
+ 
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000000000..325d9d7c1
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1,10 @@
+011_sharedlibs
+020_maintainermode
+021_debian
+022_openafs
+024_rxtelnet
+025_pthreads
+027_rsh_use_ktelnet
+libedit
+installsh
+030_autotools
diff --git a/debian/po/POTFILES.in b/debian/po/POTFILES.in
new file mode 100644
index 000000000..1fea3242b
--- /dev/null
+++ b/debian/po/POTFILES.in
@@ -0,0 +1 @@
+[type: gettext/rfc822deb] heimdal-kdc.templates
diff --git a/debian/po/cs.po b/debian/po/cs.po
new file mode 100644
index 000000000..2f0a93275
--- /dev/null
+++ b/debian/po/cs.po
@@ -0,0 +1,76 @@
+#
+#    Translators, if you are not familiar with the PO format, gettext
+#    documentation is worth reading, especially sections dedicated to
+#    this format, e.g. by running:
+#         info -n '(gettext)PO Files'
+#         info -n '(gettext)Header Entry'
+#
+#    Some information specific to po-debconf are available at
+#            /usr/share/doc/po-debconf/README-trans
+#         or http://www.debian.org/intl/l10n/po-debconf/README-trans
+#
+#    Developers do not need to manually edit POT or PO files.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: heimdal 0.7.2.dfsg.1-11\n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: 2007-11-25 22:02+0100\n"
+"Last-Translator: Martin Sin <martin.sin@zshk.cz>\n"
+"Language-Team: Czech <debian-l10n-czech@lists.debian.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr "Místní název oblasti:"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr "Zadejte prosím jméno místní oblasti Kerberos."
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+#| msgid ""
+#| "Heimdal requires the name of your local realm. This is typically your "
+#| "domain name in uppercase. eg if your hostname is host.org.com, then your "
+#| "realm will become ORG.COM. The default for your host is ${default_realm}."
+msgid ""
+"Using the uppercase domain name is common. For instance, if the host name is "
+"host.example.org, then the realm will become EXAMPLE.ORG. The default for "
+"this host is ${default_realm}."
+msgstr ""
+"Heimdal požaduje jméno místní oblasti. Tím je obvykle vaše doménové jméno "
+"zadané velkými písmeny. Např.: pokud je název vašeho po�íta�e: "
+"host.example.com, pak se vaší oblastí stane EXAMPLE.COM. Výchozí hodnotou "
+"pro váš po�íta� je: ${default_realm}."
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr "Heslo KDC:"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+#| msgid ""
+#| "Heimdal can encrypt the KDC data with a password. A hashed representation "
+#| "will be stored in /var/lib/heimdal-kdc/m-key."
+msgid ""
+"Heimdal can encrypt the key distribution center (KDC) data with a password. "
+"A hashed representation of this password will be stored in /var/lib/heimdal-"
+"kdc/m-key."
+msgstr ""
+"Heimdal může šifrovat data KDC (key distribution center) pomocí hesla. "
+"Hashovaná verze hesla bude uložena ve /var/lib/heimdal-kdc/m-key."
+
+#~ msgid "Password for KDC:"
+#~ msgstr "Heslo pro KDC:"
diff --git a/debian/po/da.po b/debian/po/da.po
new file mode 100644
index 000000000..8ab2eceb3
--- /dev/null
+++ b/debian/po/da.po
@@ -0,0 +1,60 @@
+# Danish translation Heimdal.
+# Copyright (C) 2010 pdns & nedenstående oversættere.
+# This file is distributed under the same license as the Heimdal package.
+# Claus Hindsgaul <claus_h@image.dk>, 2005.
+# Joe Hansen <joedalton2@yahoo.dk>, 2010.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: heimdal debconf\n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: 2010-06-11 17:30+01:00\n"
+"Last-Translator: Joe Hansen <joedalton2@yahoo.dk>\n"
+"Language-Team: Danish <debian-l10n-danish@lists.debian.org> \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr "Lokalt områdenavn:"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr "Indtast venligst navnet på det lokale Kerberos-rige."
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid ""
+"Using the uppercase domain name is common. For instance, if the host name is "
+"host.example.org, then the realm will become EXAMPLE.ORG. The default for "
+"this host is ${default_realm}."
+msgstr ""
+"Brug af store bogstaver i domænenavnet er udbredt. Hvis dit værtsnavn for "
+"eksempel er maskine.org.dk, vil dit område blive til ORG.DK. Standardværdien "
+"for denne vært er ${default_realm}."
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr "KDC-adgangskode:"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid ""
+"Heimdal can encrypt the key distribution center (KDC) data with a password. "
+"A hashed representation of this password will be stored in /var/lib/heimdal-"
+"kdc/m-key."
+msgstr ""
+"Heimdal kan kryptere KDC-dataene (Key Distribution Center) med en adgangskode. "
+"En sløret udgave af denne adgangskode vil blive gemt i /var/lib/heimdal-kdc/m-key."
+
+
diff --git a/debian/po/de.po b/debian/po/de.po
new file mode 100644
index 000000000..74fbed911
--- /dev/null
+++ b/debian/po/de.po
@@ -0,0 +1,68 @@
+# translation of heimdal_0.7.2.dfsg.1-11_de.po to German
+#
+#    Translators, if you are not familiar with the PO format, gettext
+#    documentation is worth reading, especially sections dedicated to
+#    this format, e.g. by running:
+#         info -n '(gettext)PO Files'
+#         info -n '(gettext)Header Entry'
+#    Some information specific to po-debconf are available at
+#            /usr/share/doc/po-debconf/README-trans
+#         or http://www.debian.org/intl/l10n/po-debconf/README-trans#
+#    Developers do not need to manually edit POT or PO files.
+#
+# Erik Schanze <eriks@debian.org>, 2004-2007.
+msgid ""
+msgstr ""
+"Project-Id-Version: heimdal_0.7.2.dfsg.1-11_de\n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: 2007-10-05 22:39+0200\n"
+"Last-Translator: Erik Schanze <eriks@debian.org>\n"
+"Language-Team: German <debian-l10n-german@lists.debian.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: KBabel 1.11.4\n"
+"Plural-Forms:  nplurals=2; plural=(n != 1);\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr "Ihr lokaler Realm-Name:"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr "Bitte geben Sie den Namen des lokalen Kerberos-Realms ein."
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid ""
+"Using the uppercase domain name is common. For instance, if the host name is "
+"host.example.org, then the realm will become EXAMPLE.ORG. The default for "
+"this host is ${default_realm}."
+msgstr ""
+"Es ist üblich, den großgeschriebenen Domänennamen zu verwenden. Wenn z. B. "
+"der Rechnername »host.example.org« lautet, dann ist Ihr Realm-Name »EXAMPLE."
+"ORG«. Die Standardeinstellung für diesen Rechner ist ${default_realm}."
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr "KDC-Passwort:"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid ""
+"Heimdal can encrypt the key distribution center (KDC) data with a password. "
+"A hashed representation of this password will be stored in /var/lib/heimdal-"
+"kdc/m-key."
+msgstr ""
+"Heimdal kann die Daten des zentralen Schlüsselverteilers (key distribution "
+"center - KDC) mit einem Passwort verschlüsseln. Ein Hash-Wert davon wird in "
+"der Datei /var/lib/heimdal-kdc/m-key abgelegt."
diff --git a/debian/po/es.po b/debian/po/es.po
new file mode 100644
index 000000000..53ed32f4b
--- /dev/null
+++ b/debian/po/es.po
@@ -0,0 +1,74 @@
+# heimdal po-debconf translation to Spanish

+# Copyright (C) 2005, 2008 Software in the Public Interest

+# This file is distributed under the same license as the heimdal package.

+#

+# Changes:

+#  - Initial translation

+#       César Gómez Martín <cesar.gomez@gmail.com>, 2005

+#
+#  - Updates
+#       Francisco Javier Cuadrado <fcocuadrado@gmail.com>, 2008
+#
+#   Traductores, si no conoce el formato PO, merece la pena leer la
+#   documentación de gettext, especialmente las secciones dedicadas a este
+#   formato, por ejemplo ejecutando:
+#          info -n '(gettext)PO Files'
+#          info -n '(gettext)Header Entry'
+#
+#   Equipo de traducción al español, por favor, lean antes de traducir
+#   los siguientes documentos:
+#
+#       - El proyecto de traducción de Debian al español
+#         http://www.debian.org/intl/spanish/
+#         especialmente las notas de traducción en
+#         http://www.debian.org/intl/spanish/notas
+#
+#       - La guía de traducción de po's de debconf:
+#         /usr/share/doc/po-debconf/README-trans
+#         o http://www.debian.org/intl/l10n/po-debconf/README-trans
+#

+msgid ""

+msgstr ""

+"Project-Id-Version: heimdal 1.2.dfsg.1-2.1\n"

+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"

+"POT-Creation-Date: 2007-09-26 07:26+0200\n"

+"PO-Revision-Date: 2008-11-21 23:16+0100\n"

+"Last-Translator: Francisco Javier Cuadrado <fcocuadrado@gmail.com>\n"

+"Language-Team: Debian l10n spanish <debian-l10n-spanish@lists.debian.org>\n"

+"MIME-Version: 1.0\n"

+"Content-Type: text/plain; charset=utf-8\n"

+"Content-Transfer-Encoding: 8bit\n"

+

+#. Type: string

+#. Description

+#: ../heimdal-kdc.templates:2001

+msgid "Local realm name:"

+msgstr "Nombre del reino local:"

+

+#. Type: string

+#. Description

+#: ../heimdal-kdc.templates:2001

+msgid "Please enter the name of the local Kerberos realm."

+msgstr "Por favor, introduzca el nombre del reino local de Kerberos."

+

+#. Type: string

+#. Description

+#: ../heimdal-kdc.templates:2001

+msgid "Using the uppercase domain name is common. For instance, if the host name is host.example.org, then the realm will become EXAMPLE.ORG. The default for this host is ${default_realm}."

+msgstr "El nombre del dominio suele estar en mayúsculas. Por ejemplo. si el nombre de su máquina es maquina.ejemplo.org, entonces su dominio será EJEMPLO.ORG. El dominio predeterminado para su máquina es ${default_realm}."

+

+#. Type: password

+#. Description

+#: ../heimdal-kdc.templates:3001

+msgid "KDC password:"

+msgstr "Contraseña de KDC:"

+

+#. Type: password

+#. Description

+#: ../heimdal-kdc.templates:3001

+msgid "Heimdal can encrypt the key distribution center (KDC) data with a password. A hashed representation of this password will be stored in /var/lib/heimdal-kdc/m-key."

+msgstr "Heimdal puede cifrar los datos de la clave de distribución central (KDC) con una contraseña. El resultado de una función resumen se almacenará en «/var/lib/heimdal-kdc/m-key»."

+

+#~ msgid "Password for KDC:"

+#~ msgstr "Contraseña para KDC:"

+

diff --git a/debian/po/fi.po b/debian/po/fi.po
new file mode 100644
index 000000000..4c1ce4fc6
--- /dev/null
+++ b/debian/po/fi.po
@@ -0,0 +1,55 @@
+msgid ""
+msgstr ""
+"Project-Id-Version: heimdal\n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: 2007-09-27 10:55+0200\n"
+"Last-Translator: Esko Arajärvi <edu@iki.fi>\n"
+"Language-Team: Finnish <debian-l10n-finnish@lists.debian.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"X-Poedit-Language: Finnish\n"
+"X-Poedit-Country: FINLAND\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr "Paikallinen aluenimi:"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr "Anna paikallinen Kerberos-aluenimi."
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid ""
+"Using the uppercase domain name is common. For instance, if the host name is "
+"host.example.org, then the realm will become EXAMPLE.ORG. The default for "
+"this host is ${default_realm}."
+msgstr ""
+"Verkkoaluenimen kirjoittaminen isolla on yleistä. Jos koneen verkkonimi on "
+"esimerkiksi kone.esimerkki.org, tulee aluenimeksi ESIMERKKI.ORG. Oletusarvo "
+"tälle koneelle on ${default_realm}."
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr "KDC-salasana:"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid ""
+"Heimdal can encrypt the key distribution center (KDC) data with a password. "
+"A hashed representation of this password will be stored in /var/lib/heimdal-"
+"kdc/m-key."
+msgstr ""
+"Heimdal voi salata avaintenjakokeskuksen (KDC) tiedot salasanalla. Tämän "
+"salasanan tiivistetty esitys tallennetaan tiedostoon /var/lib/heimdal-kdc/m-"
+"key."
diff --git a/debian/po/fr.po b/debian/po/fr.po
new file mode 100644
index 000000000..1a1817b1e
--- /dev/null
+++ b/debian/po/fr.po
@@ -0,0 +1,61 @@
+# Translation of heimdal debconf templates to French
+# Copyright (C) 2007 Christian Perrier <bubulle@debian.org>
+# Copyright (C) 2004-2006 Rémi Pannequin <remi.pannequin@laposte.net>
+# This file is distributed under the same license as the heimdal package.
+#
+# Christian Perrier <bubulle@debian.org>, 2007.
+msgid ""
+msgstr ""
+"Project-Id-Version: \n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: 2007-09-30 19:33+0200\n"
+"Last-Translator: Christian Perrier <bubulle@debian.org>\n"
+"Language-Team: French <debian-l10n-french@lists.debian.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: KBabel 1.11.4\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr "Nom de l'aire (« realm ») locale :"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr "Veuillez indiquer le nom de l'aire Kerberos locale."
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid ""
+"Using the uppercase domain name is common. For instance, if the host name is "
+"host.example.org, then the realm will become EXAMPLE.ORG. The default for "
+"this host is ${default_realm}."
+msgstr ""
+"Le nom de l'aire (« realm ») est généralement le nom de domaine, en lettres "
+"majuscules. Par exemple, si le nom d'hôte est « host.example.com », alors le "
+"nom de l'aire sera « EXAMPLE.COM ». La valeur par défaut pour cet hôte est "
+"« ${default_realm} »."
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr "Mot de passe de centre de distribution de clés (KDC) :"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid ""
+"Heimdal can encrypt the key distribution center (KDC) data with a password. "
+"A hashed representation of this password will be stored in /var/lib/heimdal-"
+"kdc/m-key."
+msgstr ""
+"Heimdal peut chiffrer les données du centre de distribution de clés (KDC : "
+"« Key Distribution Center ») avec un mot de passe. Une représentation hachée "
+"de ce mot de passe sera enregistrée dans « /var/lib/heimdal-kdc/m-key »."
diff --git a/debian/po/gl.po b/debian/po/gl.po
new file mode 100644
index 000000000..f08aa173a
--- /dev/null
+++ b/debian/po/gl.po
@@ -0,0 +1,57 @@
+# Galician translation of heimdal's debconf templates
+# This file is distributed under the same license as the heimdal package.
+# Jacobo Tarrio <jtarrio@debian.org>, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: heimdal\n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: 2007-09-30 18:53+0100\n"
+"Last-Translator: Jacobo Tarrio <jtarrio@debian.org>\n"
+"Language-Team: Galician <proxecto@trasno.net>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr "Nome do reino local:"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr "Introduza o nome do reino Kerberos local."
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid ""
+"Using the uppercase domain name is common. For instance, if the host name is "
+"host.example.org, then the realm will become EXAMPLE.ORG. The default for "
+"this host is ${default_realm}."
+msgstr ""
+"Adóitase empregar o nome de dominio en maiúsculas. Por exemplo, se o nome da "
+"máquina é host.example.org, o reino ha ser EXAMPLE.ORG. O valor por defecto "
+"para esta máquina é ${default_realm}."
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr "Contrasinal do KDC:"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid ""
+"Heimdal can encrypt the key distribution center (KDC) data with a password. "
+"A hashed representation of this password will be stored in /var/lib/heimdal-"
+"kdc/m-key."
+msgstr ""
+"Heimdal pode cifrar os datos do centro de distribución de claves (KDC) cun "
+"contrasinal. Hase gardar unha representación numérica deste contrasinal en /"
+"var/lib/heimdal-kdc/m-key."
diff --git a/debian/po/it.po b/debian/po/it.po
new file mode 100644
index 000000000..fd6f327c5
--- /dev/null
+++ b/debian/po/it.po
@@ -0,0 +1,58 @@
+# Italian (it) translation of debconf templates for heimdal
+# Copyright (C) 2007 Free Software Foundation, Inc.
+# This file is distributed under the same license as the heimdal package.
+# Luca Monducci <luca.mo@tiscali.it>, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: heimdal debconf templates\n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: 2007-10-04 21:06+0200\n"
+"Last-Translator: Luca Monducci <luca.mo@tiscali.it>\n"
+"Language-Team: Italian <debian-l10n-italian@lists.debian.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr "Nome del realm locale:"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr "Inserire il nome del realm Kerberos locale."
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid ""
+"Using the uppercase domain name is common. For instance, if the host name is "
+"host.example.org, then the realm will become EXAMPLE.ORG. The default for "
+"this host is ${default_realm}."
+msgstr ""
+"L'uso di nomi di dominio in maiuscolo è molto comune. Per esempio, se il "
+"nome host è host.esempio.org allora il realm diventa ESEMPIO.ORG. Il valore "
+"predefinito per questo host è ${default_realm}."
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr "Password per KDC:"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid ""
+"Heimdal can encrypt the key distribution center (KDC) data with a password. "
+"A hashed representation of this password will be stored in /var/lib/heimdal-"
+"kdc/m-key."
+msgstr ""
+"Heimdal può cifrare i dati del centro di distribuzione delle chiavi (KDC) "
+"con una password. In /var/lib/heimdal-kdc/m-key viene memorizzato un hash "
+"della password."
diff --git a/debian/po/ja.po b/debian/po/ja.po
new file mode 100644
index 000000000..def2bb467
--- /dev/null
+++ b/debian/po/ja.po
@@ -0,0 +1,65 @@
+#
+#    Translators, if you are not familiar with the PO format, gettext
+#    documentation is worth reading, especially sections dedicated to
+#    this format, e.g. by running:
+#         info -n '(gettext)PO Files'
+#         info -n '(gettext)Header Entry'
+#
+#    Some information specific to po-debconf are available at
+#            /usr/share/doc/po-debconf/README-trans
+#         or http://www.debian.org/intl/l10n/po-debconf/README-trans
+#
+#    Developers do not need to manually edit POT or PO files.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: heimdal\n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: 2007-09-27 21:11+0900\n"
+"Last-Translator: Kenshi Muto <kmuto@debian.org>\n"
+"Language-Team: Japanese <debian-japanese@lists.debian.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr "ローカルレルム�:"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr "ローカル� Kerberos レルム�を入力������。"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid ""
+"Using the uppercase domain name is common. For instance, if the host name is "
+"host.example.org, then the realm will become EXAMPLE.ORG. The default for "
+"this host is ${default_realm}."
+msgstr ""
+"大文字�ドメイン�を使���一般的��。����も�ホスト�� host.example."
+"org �ら�レルム� EXAMPLE.ORG ��り��。��ホスト�デフォルト��"
+"${default_realm} ��。"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr "KDC �パスワード:"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid ""
+"Heimdal can encrypt the key distribution center (KDC) data with a password. "
+"A hashed representation of this password will be stored in /var/lib/heimdal-"
+"kdc/m-key."
+msgstr ""
+"Heimdal ���布センター (KDC) データをパスワード�暗�化����。��パス"
+"ワード��ッシュ化�れ�表�� /var/lib/heimdal-kdc/m-key �格��れ��。"
diff --git a/debian/po/nl.po b/debian/po/nl.po
new file mode 100644
index 000000000..c29beb4c9
--- /dev/null
+++ b/debian/po/nl.po
@@ -0,0 +1,62 @@
+# Dutch heimdal po-debconf translation,
+# Copyright (C) 2008 THE PACKAGE'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the heimdal package.
+# Vincent Zweije <zweije@xs4all.nl>, 2008.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: heimdal 1.0.1-5\n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: 2008-02-18 22:27+0000\n"
+"Last-Translator: Vincent Zweije <zweije@xs4all.nl>\n"
+"Language-Team: Debian-Dutch <debian-l10n-dutch@lists.debian.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=ISO-8859-15\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr ""
+"Naam van het lokale autoriteitsgebied:"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr ""
+"Gelieve de naam van het locale autoriteitsgebeid (realm) aan te geven."
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid ""
+"Using the uppercase domain name is common. For instance, if the host name is "
+"host.example.org, then the realm will become EXAMPLE.ORG. The default for "
+"this host is ${default_realm}."
+msgstr ""
+"Het is gebruikelijk om uw domeinnaam in hoofdletters te gebruiken. Als uw "
+"computernaam bijvoorbeeld host.example.org is, dan zal uw autoriteitsgebied "
+"EXAMPLE.ORG zijn. De standaardwaarde voor uw computer is ${default_realm}."
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr ""
+"KDC-wachtwoord:"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid ""
+"Heimdal can encrypt the key distribution center (KDC) data with a password. "
+"A hashed representation of this password will be stored in /var/lib/heimdal-"
+"kdc/m-key."
+msgstr ""
+"Heimdal kan de gegevens van het KDC (key distribution center; "
+"sleuteldistributiecentrum) versleutelen met een wachtwoord. Een "
+"gehashte representatie van dit wachtwoord zal worden bewaard in "
+"/var/lib/heimdal-kdc/m-key."
diff --git a/debian/po/pt.po b/debian/po/pt.po
new file mode 100644
index 000000000..b6e816d4b
--- /dev/null
+++ b/debian/po/pt.po
@@ -0,0 +1,58 @@
+# Portuguese translation of heimdal debconf messages.
+# Copyright (C) 2007 Carlos Lisboa
+# This file is distributed under the same license as the heimdal package.
+# Carlos Lisboa <carloslisboa@gmail.com>, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: heimdal\n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: 2007-10-13 21:09+0000\n"
+"Last-Translator: Carlos Lisboa <carloslisboa@gmail.com>\n"
+"Language-Team: Portuguese <traduz@debianpt.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr "Nome local do realm:"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr "Introduza o nome do realm Kerberos local."
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid ""
+"Using the uppercase domain name is common. For instance, if the host name is "
+"host.example.org, then the realm will become EXAMPLE.ORG. The default for "
+"this host is ${default_realm}."
+msgstr ""
+"O nome do domínio em maiúsculas é prática usual. Assim, se o nome for host."
+"example.org, então o realm será EXAMPLE.ORG. O valor por omissão para este "
+"host é ${default_realm}."
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr "Password KDC:"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid ""
+"Heimdal can encrypt the key distribution center (KDC) data with a password. "
+"A hashed representation of this password will be stored in /var/lib/heimdal-"
+"kdc/m-key."
+msgstr ""
+"O Heimdal pode encriptar os dados do centro de distribuição de chaves (KDC) "
+"com uma palavra-chave. A representação hash será armazenada em /var/lib/"
+"heimdal-kdc/m-key."
diff --git a/debian/po/pt_BR.po b/debian/po/pt_BR.po
new file mode 100644
index 000000000..9e35659a0
--- /dev/null
+++ b/debian/po/pt_BR.po
@@ -0,0 +1,62 @@
+# heimdal Brazilian Portuguese translation 
+# Copyright (C) 2007 THE heimdal'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the heimdal package.
+# Felipe Augusto van de Wiel (faw) <faw@debian.org>, 2007.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: heimdal\n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: 2007-09-28 01:35-0300\n"
+"Last-Translator: Felipe Augusto van de Wiel (faw) <faw@debian.org>\n"
+"Language-Team: l10n portuguese <debian-l10n-portuguese@lists.debian.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"pt_BR utf-8\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr "Nome do realm local:"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr "Por favor, informe o nome do realm Kerberos local."
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid ""
+"Using the uppercase domain name is common. For instance, if the host name is "
+"host.example.org, then the realm will become EXAMPLE.ORG. The default for "
+"this host is ${default_realm}."
+msgstr ""
+"Usar o nome do domínio em letras maiúsculas é comum. Por exemplo, se o nome "
+"da máquina é host.example.org, então o realm será EXAMPLE.ORG. O padrão para "
+"este host é ${default_realm}."
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr "Senha KDC:"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid ""
+"Heimdal can encrypt the key distribution center (KDC) data with a password. "
+"A hashed representation of this password will be stored in /var/lib/heimdal-"
+"kdc/m-key."
+msgstr ""
+"Heimdal pode criptografar os dados do centro de distribuição de chaves (KDC "
+"-- key distribution center) com uma senha. Uma representação em hash desta "
+"senha será armazenada em /var/lib/heimdal-kdc/m-key."
+
+#~ msgid "Password for KDC:"
+#~ msgstr "Senha para o KDC : "
diff --git a/debian/po/ru.po b/debian/po/ru.po
new file mode 100644
index 000000000..bc73119e8
--- /dev/null
+++ b/debian/po/ru.po
@@ -0,0 +1,70 @@
+# translation of ru.po to Russian
+#
+#    Translators, if you are not familiar with the PO format, gettext
+#    documentation is worth reading, especially sections dedicated to
+#    this format, e.g. by running:
+#         info -n '(gettext)PO Files'
+#         info -n '(gettext)Header Entry'
+#    Some information specific to po-debconf are available at
+#            /usr/share/doc/po-debconf/README-trans
+#         or http://www.debian.org/intl/l10n/po-debconf/README-trans#
+#    Developers do not need to manually edit POT or PO files.
+#
+# Ilgiz Kalmetev <ilgiz@bashtelecom.ru>, 2002.
+# Yuri Kozlov <kozlov.y@gmail.com>, 2007.
+msgid ""
+msgstr ""
+"Project-Id-Version: 0.7.2.dfsg.1-10\n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: 2007-09-26 21:34+0400\n"
+"Last-Translator: Yuri Kozlov <kozlov.y@gmail.com>\n"
+"Language-Team: Russian <debian-l10n-russian@lists.debian.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: KBabel 1.11.4\n"
+"Plural-Forms:  nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%"
+"10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr "Им� локальной обла�ти:"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr "Введите им� локальной обла�ти Kerberos."
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid ""
+"Using the uppercase domain name is common. For instance, if the host name is "
+"host.example.org, then the realm will become EXAMPLE.ORG. The default for "
+"this host is ${default_realm}."
+msgstr ""
+"Обычно и�пользует�� доменное им�, напи�анное пропи�ными буквами. �апример, "
+"е�ли им� хо�та host.example.org, то обла�тью будет EXAMPLE.ORG. Обла�тью по "
+"умолчанию дл� �того хо�та �вл�ет�� ${default_realm}."
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr "Пароль KDC:"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid ""
+"Heimdal can encrypt the key distribution center (KDC) data with a password. "
+"A hashed representation of this password will be stored in /var/lib/heimdal-"
+"kdc/m-key."
+msgstr ""
+"Heimdal может зашифровать данные центра ра�пределени� ключей (KDC) � помощью "
+"парол�. Хешированное пред�тавление �того парол� будет �охранено в файле /var/"
+"lib/heimdal-kdc/m-key."
diff --git a/debian/po/sv.po b/debian/po/sv.po
new file mode 100644
index 000000000..f40888f3b
--- /dev/null
+++ b/debian/po/sv.po
@@ -0,0 +1,58 @@
+#
+#    Translators, if you are not familiar with the PO format, gettext
+#    documentation is worth reading, especially sections dedicated to
+#    this format, e.g. by running:
+#         info -n '(gettext)PO Files'
+#         info -n '(gettext)Header Entry'
+#
+#    Some information specific to po-debconf are available at
+#            /usr/share/doc/po-debconf/README-trans
+#         or http://www.debian.org/intl/l10n/po-debconf/README-trans
+#
+#    Developers do not need to manually edit POT or PO files.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: heimdal 0.7.1-2\n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: 2008-07-21 18:44+0100\n"
+"Last-Translator: Martin Bagge <brother@bsnet.se>\n"
+"Language-Team: Swedish <tp-sv@listor.tp-sv.se>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=iso-8859-1\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr "Namn på lokala sfären:"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr "Ange namnet på den lokala Kerberos-sfären."
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Using the uppercase domain name is common. For instance, if the host name is host.example.org, then the realm will become EXAMPLE.ORG. The default for this host is ${default_realm}."
+msgstr "Vanligen används versala domännamn. Exempelvis om ditt värdnamn är example.com, då är din sfär EXAMPLE.COM. Som standard är det ${default_realm} för ditt värdnamn."
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr "Lösenord för KDC:"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "Heimdal can encrypt the key distribution center (KDC) data with a password. A hashed representation of this password will be stored in /var/lib/heimdal-kdc/m-key."
+msgstr "Heimdal kan kryptera KDC-datan med ett lösenord. En hashad variant kommer att lagras i /var/lib/heimdal-kdc/m-key."
+
+#~ msgid "Password for KDC:"
+#~ msgstr "Lösenord för KDC:"
+
diff --git a/debian/po/templates.pot b/debian/po/templates.pot
new file mode 100644
index 000000000..fb5d8dd37
--- /dev/null
+++ b/debian/po/templates.pot
@@ -0,0 +1,53 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the PACKAGE package.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=CHARSET\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr ""
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr ""
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid ""
+"Using the uppercase domain name is common. For instance, if the host name is "
+"host.example.org, then the realm will become EXAMPLE.ORG. The default for "
+"this host is ${default_realm}."
+msgstr ""
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr ""
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid ""
+"Heimdal can encrypt the key distribution center (KDC) data with a password. "
+"A hashed representation of this password will be stored in /var/lib/heimdal-"
+"kdc/m-key."
+msgstr ""
diff --git a/debian/po/vi.po b/debian/po/vi.po
new file mode 100644
index 000000000..0765a9fb8
--- /dev/null
+++ b/debian/po/vi.po
@@ -0,0 +1,62 @@
+# Vietnamese translation for heimdal.
+# Copyright © 2005 Free Software Foundation, Inc.
+# Clytie Siddall <clytie@riverland.net.au>, 2005.
+# 
+msgid ""
+msgstr ""
+"Project-Id-Version: heimdal 0.7.2.dfsg.1-11\n"
+"Report-Msgid-Bugs-To: bam@snoopy.debian.net\n"
+"POT-Creation-Date: 2007-09-26 07:26+0200\n"
+"PO-Revision-Date: 2007-09-27 00:02+0930\n"
+"Last-Translator: Clytie Siddall <clytie@riverland.net.au>\n"
+"Language-Team: Vietnamese <vi-VN@googlegroups.com>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=1; plural=0;\n"
+"X-Generator: LocFactoryEditor 1.7b1\n"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Local realm name:"
+msgstr "Tên địa hạt cục bộ :"
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid "Please enter the name of the local Kerberos realm."
+msgstr "Hãy gõ tên của địa hạt (realm) Kerberos cục bộ."
+
+#. Type: string
+#. Description
+#: ../heimdal-kdc.templates:2001
+msgid ""
+"Using the uppercase domain name is common. For instance, if the host name is "
+"host.example.org, then the realm will become EXAMPLE.ORG. The default for "
+"this host is ${default_realm}."
+msgstr ""
+"Thư�ng là tên mi�n (domain name) theo chữ hoa. Chẳng hạn, nếu tên máy là « "
+"máy.vnoss.org » thì địa hạt là « VNOSS.ORG ». Giá trị mặc định cho máy này "
+"là « ${default_realm} »."
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid "KDC password:"
+msgstr "Mật khẩu KDC:"
+
+#. Type: password
+#. Description
+#: ../heimdal-kdc.templates:3001
+msgid ""
+"Heimdal can encrypt the key distribution center (KDC) data with a password. "
+"A hashed representation of this password will be stored in /var/lib/heimdal-"
+"kdc/m-key."
+msgstr ""
+"Trình heimdal có thể mật mã hóa dư liệu KDC (trung tâm phát hành khoá) bằng "
+"mật khẩu. Sự đại diện băm của mật khẩu này sẽ được lưu vào « /var/lib/"
+"heimdal-kdc/m-key »."
+
+#~ msgid "Password for KDC:"
+#~ msgstr "Mật khẩu cho KDC:"
diff --git a/debian/rules b/debian/rules
new file mode 100755
index 000000000..db632c5b7
--- /dev/null
+++ b/debian/rules
@@ -0,0 +1,170 @@
+#!/usr/bin/make -f
+
+include /usr/share/cdbs/1/rules/debhelper.mk
+include /usr/share/cdbs/1/class/autotools.mk
+
+DEB_INSTALL_DOCS_ALL =
+DEB_INSTALL_DOCS_heimdal-docs = $(filter-out $(DEB_INSTALL_CHANGELOGS_ALL),$(shell for f in README NEWS TODO BUGS AUTHORS THANKS; do if test -s $(DEB_SRCDIR)/$$f; then echo $(DEB_SRCDIR)/$$f; fi; done)) \
+	NEWS TODO
+
+DEB_DH_MAKESHLIBS_ARGS_libkdc2-heimdal = -V"libkdc2-heimdal (>= 1.4.0~git20100221.dfsg.2-1)"
+DEB_DH_MAKESHLIBS_ARGS_libasn1-8-heimdal = -V"libasn1-8-heimdal (>= 1.4.0~git20100221.dfsg.2-1)"
+DEB_DH_MAKESHLIBS_ARGS_libheimbase1-heimdal = -V"libheimbase1-heimdal (>= 1.4.0~git20100221.dfsg.2-1)"
+DEB_DH_MAKESHLIBS_ARGS_libhcrypto4-heimdal = -V"libhcrypto4-heimdal (>= 1.4.0~git20100221.dfsg.2-1)"
+DEB_DH_MAKESHLIBS_ARGS_libgssapi2-heimdal = -V"libgssapi2-heimdal (>= 1.4.0~git20100221.dfsg.2-1)"
+DEB_DH_MAKESHLIBS_ARGS_libhdb9-heimdal = -V"libhdb9-heimdal (>= 1.4.0~git20100221.dfsg.2-1)"
+DEB_DH_MAKESHLIBS_ARGS_libhx509-5-heimdal = -V"libhx509-5-heimdal (>= 1.4.0~git20100221.dfsg.2-1)"
+DEB_DH_MAKESHLIBS_ARGS_libkadm5srv8-heimdal = -V"libkadm5srv8-heimdal (>= 1.4.0~git20100221.dfsg.2-1)"
+DEB_DH_MAKESHLIBS_ARGS_libkadm5clnt7-heimdal = -V"libkadm5clnt7-heimdal (>= 1.4.0~git20100221.dfsg.2-1)"
+DEB_DH_MAKESHLIBS_ARGS_libkrb5-26-heimdal = -V"libkrb5-26-heimdal (>= 1.4.0~git20100221.dfsg.2-1)"
+DEB_DH_MAKESHLIBS_ARGS_libheimntlm0-heimdal = -V"libheimntlm0-heimdal (>= 1.4.0~git20100221.dfsg.2-1)"
+DEB_DH_MAKESHLIBS_ARGS_libroken18-heimdal = -V"libroken18-heimdal (>= 1.4.0~git20100221.dfsg.2-1)"
+DEB_DH_MAKESHLIBS_ARGS_libwind0-heimdal = -V"libwind0-heimdal (>= 1.4.0~git20100221.dfsg.2-1)"
+
+DEB_DH_INSTALL_SOURCEDIR = debian/tmp
+
+DEB_CONFIGURE_LIBEXECDIR ="\$${prefix}/sbin"
+
+DEB_CONFIGURE_EXTRA_FLAGS := \
+	--enable-shared \
+	--with-kaserver \
+	--with-roken=/usr \
+	--without-des \
+	--with-openldap=/usr \
+	--with-sqlite3=/usr \
+	--enable-kcm \
+	--with-readline-include=/usr/include/editline \
+	--with-readline-lib=/usr/lib \
+	--with-hdbdir=/var/lib/heimdal-kdc \
+	--without-openssl
+
+# /var/lib/heimdal-kdc is 700
+DEB_FIXPERMS_EXCLUDE = heimdal-kdc
+
+clean::
+	# clean files not cleaned by make file
+	rm -f appl/ftp/ftpd/ftpcmd.c
+	rm -f appl/login/login-protos.h
+	rm -f appl/rsh/limits_conf.c
+	rm -f appl/rsh/login_access.c
+	rm -f doc/heimdal.info
+	rm -f doc/hx509.info
+	rm -f kcm/kcm-protos.h
+	rm -f kdc/kdc-private.h
+	rm -f kdc/kdc-protos.h
+	rm -f lib/asn1/asn1parse.c
+	rm -f lib/asn1/asn1parse.h
+	rm -f lib/asn1/der-private.h
+	rm -f lib/asn1/der-protos.h
+	rm -f lib/asn1/lex.c
+	rm -f lib/com_err/snprintf.c
+	rm -f lib/com_err/strlcpy.c
+	rm -f lib/gssapi/krb5/gsskrb5-private.h
+	rm -f lib/gssapi/ntlm/ntlm-private.h
+	rm -f lib/gssapi/spnego/spnego-private.h
+	rm -f lib/hdb/hdb-private.h
+	rm -f lib/hdb/hdb-protos.h
+	rm -f lib/hx509/hx509-private.h
+	rm -f lib/hx509/hx509-protos.h
+	rm -f lib/hx509/sel-gram.c
+	rm -f lib/kadm5/kadm5-private.h
+	rm -f lib/kadm5/kadm5-protos.h
+	rm -f lib/krb5/krb5-private.h
+	rm -f lib/krb5/krb5-protos.h
+	rm -f lib/ntlm/heimntlm-protos.h
+	rm -f lib/sl/slc-gram.c
+	rm -f lib/sl/slc-gram.h
+	rm -f lib/sl/slc-lex.c
+	rm -f lib/wind/bidi_table.c
+	rm -f lib/wind/bidi_table.h
+	rm -f lib/wind/combining_table.c
+	rm -f lib/wind/combining_table.h
+	rm -f lib/wind/errorlist_table.c
+	rm -f lib/wind/errorlist_table.h
+	rm -f lib/wind/map_table.c
+	rm -f lib/wind/map_table.h
+	rm -f lib/wind/normalize_table.c
+	rm -f lib/wind/normalize_table.h
+	rm -f lib/wind/*.pyc
+
+binary-post-install/heimdal-dev::
+	for l in `find debian/tmp/usr/include -type d -printf "%P\n"`; do \
+		mkdir "debian/heimdal-dev/usr/include/$$l"; \
+		done
+	for l in `find debian/tmp/usr/include -mindepth 1 -maxdepth 1 -type f -printf "%P\n"`; do \
+		ln -s "heimdal/$$l" "debian/heimdal-dev/usr/include/$$l"; \
+		done
+	for l in `find debian/tmp/usr/include -mindepth 2 -maxdepth 2 -type f -printf "%P\n"`; do \
+		ln -s "../heimdal/$$l" "debian/heimdal-dev/usr/include/$$l"; \
+		done
+
+	# remove conflicting files
+	rm -rf debian/heimdal-dev/usr/include/ss
+	rm -f debian/heimdal-dev/usr/bin/mk_cmds
+	rm -f debian/heimdal-dev/usr/include/fnmatch.h
+	# remove unwanted files
+	rm -f debian/heimdal-dev/usr/lib/libss.a
+	rm -f debian/heimdal-dev/usr/lib/libss.la
+	rm -f debian/heimdal-dev/usr/lib/libss.so
+	rm -f debian/heimdal-dev/usr/lib/windc.la
+	# remove libtool recursive linking mess
+	sed -i "/dependency_libs/ s/'.*'/''/" debian/heimdal-dev/usr/lib/*.la
+
+binary-post-install/heimdal-multidev::
+	# remove conflicting files
+	rm -rf debian/heimdal-multidev/usr/include/heimdal/ss
+	rm -f debian/heimdal-multidev/usr/include/heimdal/fnmatch.h
+	# remove unwanted files
+	rm -f debian/heimdal-multidev/usr/lib/heimdal/libss.a
+	rm -f debian/heimdal-multidev/usr/lib/heimdal/libss.so
+	rm -f debian/heimdal-multidev/usr/lib/heimdal/windc.so
+	rm -f debian/heimdal-multidev/usr/lib/heimdal/windc.a
+	# rewrite symlinks to symlinks to point directly to file
+	for l in debian/heimdal-multidev/usr/lib/heimdal/*.so; do \
+		ln -s  -f ../`readlink $$l` $$l ; \
+		done
+
+
+binary-post-install/heimdal-servers::
+	mv debian/heimdal-servers/usr/sbin/kfd debian/heimdal-servers/usr/lib/heimdal-servers
+	mv debian/heimdal-servers/usr/sbin/ftpd debian/heimdal-servers/usr/lib/heimdal-servers
+	mv debian/heimdal-servers/usr/sbin/rshd debian/heimdal-servers/usr/lib/heimdal-servers
+	mv debian/heimdal-servers/usr/sbin/telnetd debian/heimdal-servers/usr/lib/heimdal-servers
+	mv debian/heimdal-servers/usr/sbin/popper debian/heimdal-servers/usr/lib/heimdal-servers
+	mv debian/heimdal-servers/usr/bin/login debian/heimdal-servers/usr/lib/heimdal-servers
+	rmdir debian/heimdal-servers/usr/sbin
+	rmdir debian/heimdal-servers/usr/bin
+
+binary-post-install/heimdal-servers-x::
+	mv debian/heimdal-servers-x/usr/sbin/kxd debian/heimdal-servers-x/usr/lib/heimdal-servers
+	rmdir debian/heimdal-servers-x/usr/sbin
+
+binary-post-install/heimdal-kdc::
+	mv debian/heimdal-kdc/usr/sbin/kdc debian/heimdal-kdc/usr/lib/heimdal-servers
+	mv debian/heimdal-kdc/usr/sbin/kadmind debian/heimdal-kdc/usr/lib/heimdal-servers
+	mv debian/heimdal-kdc/usr/sbin/kpasswdd debian/heimdal-kdc/usr/lib/heimdal-servers
+	install -m644 debian/extras/default debian/heimdal-kdc/etc/default/heimdal-kdc
+	install -m644 lib/hdb/hdb.schema debian/heimdal-kdc/etc/ldap/schema/hdb.schema
+	dh_fixperms -pheimdal-kdc
+	chmod 700 debian/heimdal-kdc/var/lib/heimdal-kdc
+
+binary-post-install/heimdal-clients::
+	mv debian/heimdal-clients/usr/bin/telnet debian/heimdal-clients/usr/bin/ktelnet
+	mv debian/heimdal-clients/usr/bin/ftp debian/heimdal-clients/usr/bin/kftp
+	mv debian/heimdal-clients/usr/share/man/man1/telnet.1 debian/heimdal-clients/usr/share/man/man1/ktelnet.1
+	mv debian/heimdal-clients/usr/share/man/man1/ftp.1 debian/heimdal-clients/usr/share/man/man1/kftp.1
+	mv debian/heimdal-clients/usr/bin/rsh debian/heimdal-clients/usr/bin/krsh
+	mv debian/heimdal-clients/usr/bin/rcp debian/heimdal-clients/usr/bin/krcp
+	mv debian/heimdal-clients/usr/bin/pagsh debian/heimdal-clients/usr/bin/kpagsh
+	mv debian/heimdal-clients/usr/bin/su debian/heimdal-clients/usr/bin/ksu
+	mv debian/heimdal-clients/usr/share/man/man1/rsh.1 debian/heimdal-clients/usr/share/man/man1/krsh.1
+	mv debian/heimdal-clients/usr/share/man/man1/rcp.1 debian/heimdal-clients/usr/share/man/man1/krcp.1
+	mv debian/heimdal-clients/usr/share/man/man1/pagsh.1 debian/heimdal-clients/usr/share/man/man1/kpagsh.1
+	mv debian/heimdal-clients/usr/share/man/man1/su.1 debian/heimdal-clients/usr/share/man/man1/ksu.1
+
+binary-post-install/heimdal-docs::
+	mv debian/heimdal-docs/usr/share/man/man5/krb5.conf.5 debian/heimdal-docs/usr/share/man/man5/krb5.conf.5heimdal
+	rm -f debian/heimdal-docs/usr/share/info/dir
+
+get-orig-source::
+	./debian/scripts/build-git-orig
diff --git a/debian/scripts/autotools b/debian/scripts/autotools
new file mode 100755
index 000000000..84f9f903c
--- /dev/null
+++ b/debian/scripts/autotools
@@ -0,0 +1,126 @@
+#!/bin/sh -ex
+# script to automate building of 030_autotools patch file
+
+export QUILT_PATCHES=$PWD/debian/patches
+
+
+if ! quilt applied | grep 030_autotools
+then
+    : > debian/patches/030_autotools
+    quilt push 030_autotools
+else
+    quilt pop 030_autotools || true
+fi
+
+if [ `quilt top` != "030_autotools" ]
+then
+    echo "Top patch is not 030_autotools" >&2
+    exit 1
+fi
+
+set +e
+
+quilt add cf/*
+quilt add acinclude.m4
+quilt add aclocal.m4
+quilt add cf/ltversion.m4
+quilt add cf/libtool.m4
+quilt add cf/ltoptions.m4
+quilt add cf/ltsugar.m4
+quilt add cf/ltversion.m4
+quilt add cf/lt~obsolete.m4
+quilt add compile
+quilt add config.guess
+quilt add config.sub
+quilt add configure
+quilt add depcomp
+quilt add include/config.h.in
+quilt add install-sh
+quilt add ltmain.sh
+quilt add missing
+quilt add ylwrap
+
+quilt add admin/Makefile.in
+quilt add base/Makefile.in
+quilt add appl/afsutil/Makefile.in
+quilt add appl/dceutils/Makefile.in
+quilt add appl/ftp/common/Makefile.in
+quilt add appl/ftp/ftpd/Makefile.in
+quilt add appl/ftp/ftp/Makefile.in
+quilt add appl/ftp/Makefile.in
+quilt add appl/gssmask/Makefile.in
+quilt add appl/kf/Makefile.in
+quilt add appl/kx/Makefile.in
+quilt add appl/login/Makefile.in
+quilt add appl/Makefile.in
+quilt add appl/otp/Makefile.in
+quilt add appl/popper/Makefile.in
+quilt add appl/push/Makefile.in
+quilt add appl/rcp/Makefile.in
+quilt add appl/rsh/Makefile.in
+quilt add appl/su/Makefile.in
+quilt add appl/telnet/libtelnet/Makefile.in
+quilt add appl/telnet/Makefile.in
+quilt add appl/telnet/telnetd/Makefile.in
+quilt add appl/telnet/telnet/Makefile.in
+quilt add appl/test/Makefile.in
+quilt add appl/xnlock/Makefile.in
+quilt add configure.ac
+quilt add doc/Makefile.in
+quilt add etc/Makefile.in
+quilt add include/config.h.in
+quilt add include/gssapi/Makefile.in
+quilt add include/hcrypto/Makefile.in
+quilt add include/kadm5/Makefile.in
+quilt add include/Makefile.in
+quilt add kadmin/Makefile.in
+quilt add kcm/Makefile.in
+quilt add kdc/Makefile.in
+quilt add kpasswd/Makefile.in
+quilt add kuser/Makefile.in
+quilt add lib/asn1/Makefile.in
+quilt add lib/auth/afskauthlib/Makefile.in
+quilt add lib/auth/Makefile.in
+quilt add lib/auth/pam/Makefile.in
+quilt add lib/auth/sia/Makefile.in
+quilt add lib/com_err/Makefile.in
+quilt add lib/editline/Makefile.in
+quilt add lib/gssapi/Makefile.in
+quilt add lib/hcrypto/Makefile.in
+quilt add lib/hdb/Makefile.in
+quilt add lib/hx509/Makefile.in
+quilt add lib/ipc/Makefile.in
+quilt add lib/kadm5/Makefile.in
+quilt add lib/kafs/Makefile.in
+quilt add lib/kdfs/Makefile.in
+quilt add lib/krb5/Makefile.in
+quilt add lib/Makefile.in
+quilt add lib/ntlm/Makefile.in
+quilt add lib/otp/Makefile.in
+quilt add lib/roken/Makefile.in
+quilt add lib/sl/Makefile.in
+quilt add lib/sqlite/Makefile.in
+quilt add lib/vers/Makefile.in
+quilt add lib/wind/Makefile.in
+quilt add Makefile.in
+quilt add packages/mac/Makefile.in
+quilt add packages/Makefile.in
+quilt add po/Makefile.in
+quilt add tests/bin/Makefile.in
+quilt add tests/can/Makefile.in
+quilt add tests/db/Makefile.in
+quilt add tests/gss/Makefile.in
+quilt add tests/java/Makefile.in
+quilt add tests/kdc/Makefile.in
+quilt add tests/ldap/Makefile.in
+quilt add tests/Makefile.in
+quilt add tests/plugin/Makefile.in
+quilt add tools/Makefile.in
+
+set -e
+
+autoreconf --install
+libtoolize -c -f
+automake -a || true
+
+quilt refresh
diff --git a/debian/scripts/build-git-orig b/debian/scripts/build-git-orig
new file mode 100755
index 000000000..af5aea538
--- /dev/null
+++ b/debian/scripts/build-git-orig
@@ -0,0 +1,13 @@
+#!/bin/bash -e
+# Build an orig.tar.gz file from a git snapshot
+# See also http://www.h5l.org/sources.html
+
+version=$( dpkg-parsechangelog -l`dirname $0`/../changelog | sed -n 's/^Version: \(.*:\|\)//p' | sed 's/-[0-9.]\+$//' )
+scriptdir=`dirname $0`
+
+CHECKOUT_DIR="heimdal-$version"
+git clone --depth 1 -l git://github.com/heimdal/heimdal "$CHECKOUT_DIR"
+`dirname $0`/fix_git_source "$CHECKOUT_DIR"
+rm -rf "$CHECKOUT_DIR/.git"
+tar cz "$CHECKOUT_DIR" > "heimdal_$version.orig.tar.gz"
+rm -rf "$CHECKOUT_DIR"
diff --git a/debian/scripts/convert_source b/debian/scripts/convert_source
new file mode 100755
index 000000000..a9b18c61f
--- /dev/null
+++ b/debian/scripts/convert_source
@@ -0,0 +1,121 @@
+#!/bin/sh -ex
+
+VERSION="$1"
+
+if [ -z "$VERSION" ]
+then
+    echo "Version number not supplied" >&2
+fi
+
+# configuration
+
+# for tarball import
+#SRC="../heimdal-$VERSION.tar.gz"
+#SRC_NAME="heimdal-$VERSION"
+#SRC_DIR=""
+# for git import
+SRC=""
+SRC_DIR="$PWD"
+DEBIAN_DIR=""
+
+DST="../heimdal_$VERSION.dfsg.1.orig.tar.gz"
+DST_NAME="heimdal-$VERSION.dfsg.1"
+DEBIAN_DIR="preserve"
+
+# unpack directory
+MYTMP=""
+trap 'if [ -n "$MYTMP" ]; then rm -rf $MYTMP; fi' EXIT
+MYTMP=`mktemp -td heimdal.XXXXXX` || exit 1
+
+# Do not change below
+
+make_dfsg_dir() {
+    local DST_DIR="$1"
+    local PYTHON=python
+
+    local OPWD="$PWD"
+    cd "$srcdir"
+    quilt pop -a || true
+    cd "$OPWD"
+
+    #OPWD="$PWD"
+    #cd "$srcdir"
+    #$PYTHON "$dstdir/gen-map.py" "$dstdir/rfc3454.txt"
+    #$PYTHON "$dstdir/gen-errorlist.py" "$dstdir/rfc3454.txt"
+    #$PYTHON "$dstdir/gen-normalize.py" "$dstdir/UnicodeData.txt" "$srcdir/CompositionExclusions-3.2.0.txt"
+    #$PYTHON "$dstdir/gen-combining.py" "$dstdir/UnicodeData.txt"
+    #$PYTHON "$dstdir/gen-bidi.py" "$dstdir/rfc3454.txt"
+    #$PYTHON "$dstdir/gen-punycode-examples.py" "$dstdir/rfc3492.txt"
+    #cd "$OPWD"
+
+    dstdir="$DST_DIR/lib/wind"
+    python debian/scripts/rfc3454.py "$dstdir/rfc3454.txt" > "$dstdir/rfc3454.txt.tmp"
+    mv "$dstdir/rfc3454.txt.tmp" "$dstdir/rfc3454.txt"
+
+    rm -f "$dstdir/rfc3490.txt"
+    rm -f "$dstdir/rfc3491.txt"
+    rm -f "$dstdir/rfc4013.txt"
+    rm -f "$dstdir/rfc4518.txt"
+
+    rm -rf "$DST_DIR/doc/standardisation"
+    rm -f "$DST_DIR/heimdal-1.3.99.tar.gz"
+    rm -f "$DST_DIR/heimdal-1.3.99.tar.gz.cdbs-config_list"
+    rm -f "$DST_DIR/appl/popper/pop3.rfc1081"
+    rm -f "$DST_DIR/appl/popper/pop3e.rfc1082"
+}
+
+# GO GO GO
+
+# Pick a good directory name that will cause tar to create tar.gz file with
+# appropriate top level name
+DST_DIR="$MYTMP/$DST_NAME"
+
+# move or extract source into $DST_DIR
+if [ -n "$SRC" ]
+then
+    tar -xzf "$SRC" -C "$MYTMP"
+    SRC_DIR="$MYTMP/$SRC_NAME"
+    mv "$SRC_DIR" "$DST_DIR"
+else
+    cp -a "$SRC_DIR" "$DST_DIR"
+fi
+
+# Do our hacking to $DST_DIR
+make_dfsg_dir "$DST_DIR"
+
+# Do we need to preseve the debian directory?
+if [ "$DEBIAN_DIR" = "preserve" ]
+then
+    # Yes => move it out of the way
+    if [ -e "$MYTMP/debian" ]
+    then
+        echo "Oops. Temp debian directory exists already. Not overwriting."
+        exit 1
+    fi
+    mv "$DST_DIR/debian" "$MYTMP/debian"
+else
+    if [ -e "$DST_DIR/debian" ]
+    then
+        echo "Ooops. Debian directory exists, and we don't know what to do."
+        exit 1
+    fi
+fi
+
+# Create tar.gz file
+tar -czf "$DST" -C "$MYTMP" "$DST_NAME"
+
+# Do we need to restore the debian directory?
+if [ "$DEBIAN_DIR" = "preserve" ]
+then
+    mv "$MYTMP/debian" "$DST_DIR/debian"
+fi
+
+# Move source, if required, to where it won't get deleted
+if [ -e "../$DST_NAME" ]
+then
+    echo "Oops. Destination directory exists already. Not overwriting."
+    exit 1
+fi
+mv "$DST_DIR" "../$DST_NAME"
+
+exit 0
diff --git a/debian/scripts/fix_git_source b/debian/scripts/fix_git_source
new file mode 100755
index 000000000..46e6bede6
--- /dev/null
+++ b/debian/scripts/fix_git_source
@@ -0,0 +1,35 @@
+#!/bin/bash -ex
+
+DST_DIR="$1"
+PYTHON=python
+
+if [ -z "$DST_DIR" ]
+then
+    DST_DIR="."
+fi
+
+OPWD="$PWD"
+cd "$DST_DIR"
+quilt pop -a || true
+cd "$OPWD"
+
+dstdir="$DST_DIR/lib/wind"
+python debian/scripts/rfc3454.py "$dstdir/rfc3454.txt" > "$dstdir/rfc3454.txt.tmp"
+mv "$dstdir/rfc3454.txt.tmp" "$dstdir/rfc3454.txt"
+pushd "$dstdir"
+git add "rfc3454.txt"
+
+git rm "rfc3490.txt"
+git rm "rfc3491.txt"
+git rm "rfc4013.txt"
+git rm "rfc4518.txt"
+
+popd
+
+pushd "$DST_DIR"
+
+git rm -r "doc/standardisation"
+git rm "appl/popper/pop3.rfc1081"
+git rm "appl/popper/pop3e.rfc1082"
+
+popd
diff --git a/debian/scripts/rfc3454.py b/debian/scripts/rfc3454.py
new file mode 100755
index 000000000..edd975702
--- /dev/null
+++ b/debian/scripts/rfc3454.py
@@ -0,0 +1,69 @@
+#!/usr/local/bin/python
+# -*- coding: iso-8859-1 -*-
+
+# $Id: rfc3454.py 22551 2008-02-01 16:22:22Z lha $
+
+# Copyright (c) 2004 Kungliga Tekniska Högskolan
+# (Royal Institute of Technology, Stockholm, Sweden). 
+# All rights reserved. 
+# 
+# Redistribution and use in source and binary forms, with or without 
+# modification, are permitted provided that the following conditions 
+# are met: 
+# 
+# 1. Redistributions of source code must retain the above copyright 
+#    notice, this list of conditions and the following disclaimer. 
+# 
+# 2. Redistributions in binary form must reproduce the above copyright 
+#    notice, this list of conditions and the following disclaimer in the 
+#    documentation and/or other materials provided with the distribution. 
+# 
+# 3. Neither the name of the Institute nor the names of its contributors 
+#    may be used to endorse or promote products derived from this software 
+#    without specific prior written permission. 
+# 
+# THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND 
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE 
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 
+# SUCH DAMAGE. 
+
+import re
+import string
+
+def read(filename):
+    """return a dict of tables from rfc3454"""
+    f = open(filename, 'r')
+    inTable = False
+    while True:
+        l = f.readline()
+        if not l:
+            break
+        if inTable:
+            m = re.search('^[a-zA-Z]', l)
+            if not m:
+                    print l
+
+            m = re.search('^ *----- End Table ([A-Z0-9\.]+) ----- *$', l)
+            if m:
+                inTable = False
+
+        if re.search('^ *----- Start Table ([A-Z0-9\.]+) ----- *$', l):
+            print l
+            inTable = True
+    f.close()
+    return
+
+import sys
+
+if len(sys.argv) != 2:
+    print "usage: %s rfc3454.txt" % sys.argv[0]
+    sys.exit(1)
+
+tables = read(sys.argv[1])
diff --git a/debian/source/format b/debian/source/format
new file mode 100644
index 000000000..163aaf8d8
--- /dev/null
+++ b/debian/source/format
@@ -0,0 +1 @@
+3.0 (quilt)
diff --git a/debian/watch b/debian/watch
new file mode 100644
index 000000000..1c4114857
--- /dev/null
+++ b/debian/watch
@@ -0,0 +1,3 @@
+version=3
+opts=dversionmangle=s/\.dfsg\.\d+$//,uversionmangle=s/(rc\d)/~$1/ \
+  http://www.h5l.org/dist/src/heimdal-(.*)\.tar\.gz
diff --git a/doc/standardisation/draft-brezak-kerberos-http-00.txt b/doc/standardisation/draft-brezak-kerberos-http-00.txt
deleted file mode 100644
index 0b8dcd730..000000000
--- a/doc/standardisation/draft-brezak-kerberos-http-00.txt
+++ /dev/null
@@ -1,347 +0,0 @@
-
-                                                               J.Brezak 
-Internet Draft                                                Microsoft 
-Document: draft-brezak-kerberos-http-00.txt                             
-Category: Informational                                November 17,2003 
-                                                   Expires: May 17,2003 
- 
- 
-              HTTP Authentication: Kerberos Authentication 
-                 As implemented in Microsoft Windows 2000 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is subject to all provisions  
-   of Section 10 of RFC2026 [1] except that the right to create 
-   derivative works is not granted. 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." 
-     
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-    
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   This document describes how the Microsoft Internet Explorer (MSIE) 
-   and Internet Information Services (IIS) incorporated in Microsoft 
-   Windows 2000 use Kerberos for security enhancements of web 
-   transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of 
-   "negotiate" is defined here; when the negotiation results in the 
-   selection of Kerberos, the security services of authentication and 
-   optionally impersonation are performed. 
-    
-   This document explains how HTTP authentication utilizes the Simple 
-   and Protected GSS-API Negotiation mechanism. Details of SPNEGO 
-   implementation are not provided in this document. 
-    
-    
-2. Conventions used in this document 
-    
-   In examples, "C:" and "S:" indicate lines sent by the client and 
-   server respectively. 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [1]. 
-    
-  
-Brezak                 Category - Informational                      1 
-                 HTTP Kerberos Access Authentication    November 2003 
-
-3. Introduction 
-   Microsoft has provided support for Kerberos authentication in MSIE 
-   and IIS in addition to other mechanisms. This provides the benefits 
-   of the Kerberos v5 protocol for Web applications.  
-   Support for Kerberos authentication is based on other previously 
-   defined mechanisms such as SPNEGO and the Generic Security Services 
-   Application Program Interface(GSSAPI).  
-    
-3. Access Authentication 
-    
-3.1 Reliance on the HTTP/1.1 Specification 
- 
-   This specification is a companion to the HTTP/1.1 specification [1] 
-   and builds on the authentication mechanisms defined in [2]. It uses 
-   the augmented BNF section 2.1 of that document, and relies on both 
-   the non-terminals defined in that document and other aspects of the 
-   HTTP/1.1 specification. 
-    
-    
-4. HTTP Negotiate Authentication Scheme 
-    
-   Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate".  
-   The auth-params exchanged use data formats defined for use with the 
-   GSS-API [3].  In particular, they follow the formats set for the 
-   SPNEGO [4] and Kerberos [5] mechanisms for GSSAPI.  The "Negotiate" 
-   auth-scheme calls for the use of SPNEGO GSSAPI tokens which the 
-   specific mechanism type specifies. 
-    
-   The current implementation of this protocol is limited to the use of 
-   SPNEGO with the Kerberos and Microsoft(NT Lan Manager) NTLM 
-   protocols. 
-    
-4.1 The WWW-Authenticate Response Header 
-    
-   If the server receives a request for an access-protected object, and 
-   an acceptable Authorization header has not been sent, the server 
-   responds with a "401 Unauthorized" status code, and a "WWW-
-   Authenticate:" header as per the framework described in [1]. The 
-   initial WWW-Authenticate header will not carry any gssapi-data. 
-    
-   The negotiate scheme will operate as follows: 
-    
-        challenge       = "Negotiate" auth-data 
-        auth-data       = 1#( [gssapi-data] ) 
-         
-   The meanings of the values of the directives used above are as 
-   follows: 
-    
-   gssapi-data 
-        If the gss_accept_security_context return a token for the 
-        client, this directive contains the base64 encoding of an 
-        InitialContextToken as defined in [3]. This is not present in 
-        the initial response from the server. 
-  
-  
-Brezak                 Category - Informational                      2 
-                 HTTP Kerberos Access Authentication    November 2003 
-
-   A status code 200 status response can also carry a "WWW-
-   Authenticate" response header containing the final leg of an 
-   authentication. In this case, the gssapi-data will be present. 
-   Before using the contents of the response, the gssapi-data should be 
-   processed by gss_init_security_context to determine the state of the 
-   security context. If this function indicates success, the response 
-   can be used by the application. Otherwise an appropriate action 
-   based on the authentication status should be. 
-    
-   For example the authentication could have failed on the final leg if 
-   mutual authentication was requested and the server was not able to 
-   prove its identity. In this case, the returned results are suspect. 
-   It is not always possible to mutually authenticate the server before 
-   the HTTP operation. POST methods are in this category. 
-    
-   When the Kerberos Version 5 GSSAPI mechanism [5] is being used, the 
-   HTTP server will be using a principal name of the form of 
-   "HTTP/<hostname>". 
-    
-4.2 The Authorization Request Header 
- 
-   Upon receipt of the response containing a "WWW-Authenticate" header 
-   from the server, the client is expected to retry the HTTP request, 
-   passing a HTTP "Authorization" header line. This is defined 
-   according to the framework described in [1] utilized as follows: 
-    
-        credentials             = "Negotiate" auth-data2 
-        auth-data2              = 1#( gssapi-data ) 
-                                 
-   gssapi-data 
-        This directive contains is the base64 encoding of an 
-        InitialContextToken as defined in [3]. 
-    
-   Any returned code other than a success 2xx code represents an 
-   authentication error. If a 401 containing a "WWW-Authenticate" 
-   header with "Negotiate" and gssapi-data is returned from the server, 
-   it is a continuation of the authentication request. 
-    
-   A client may initiate a connection to the server with an 
-   "Authorization" header containing the initial token for the server. 
-   This form will bypass the initial 401 error from the server when the 
-   client knows that the server will accept the Negotiate HTTP 
-   authentication type. 
-    
-5. Negotiate Operation Example 
-    
-   The client requests an access-protected document from server via a 
-   GET method request. The URI of the document is 
-   "http://www.nowhere.org/dir/index.html". 
-    
-        C: GET dir/index.html 
-    
-   The first time the client requests the document, no Authorization 
-   header is sent, so the server responds with: 
-  
-Brezak                 Category - Informational                      3 
-                 HTTP Kerberos Access Authentication    November 2003 
-
-    
-        S: HTTP/1.1 401 Unauthorized 
-        S: WWW-Authenticate: Negotiate 
-         
-   The client will obtain the user credentials using the SPNEGO GSSAPI 
-   mechanism type to identify generate a GSSAPI message to be sent to 
-   the server with a new request, including the following Authorization 
-   header: 
-    
-        C: GET dir/index.html 
-        C: Authorization: Negotiate a87421000492aa874209af8bc028 
-         
-   The server will decode the gssapi-data and pass this to the SPNEGO 
-   GSSAPI mechanism in the gss_accept_security_context function. If the 
-   context is not complete, the server will respond with a 401 status 
-   code with a WWW-Authenticate header containing the gssapi-data. 
-    
-        S: HTTP/1.1 401 Unauthorized 
-        S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356 
-    
-   The client will decode the gssapi-data and pass this into 
-   gss_init_security_context and return the new gssapi-data to the 
-   server. 
-    
-        C: GET dir/index.html 
-        C: Authorization: Negotiate 89a8742aa8729a8b028 
-    
-   This cycle can continue until the security context is complete. 
-    
-   When the return value from the gss_accept_security_context function 
-   indicates that the security context is complete, it may supply final 
-   authentication data to be returned to the client. If the server has 
-   more gssapi data to send to the client to complete the context it is 
-   to be carried in WWW-Authenticate header with the final response 
-   containing the HTTP body. 
-    
-        S: HTTP/1.1 200 Success 
-        S: WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca 
-         
-   The client will decode the gssapi-data and supply it to 
-   gss_init_security_context using the context for this server. If the 
-   status is successful from the final gss_init_security_context, the 
-   response can be used by the application. 
- 
-7. Security Considerations 
- 
-   The SPNEGO HTTP authentication facility is only used to provide 
-   authentication of a user to server. It provides no facilities for 
-   protecting the HTTP headers or data including the Authorization and 
-   WWW-Authenticate headers that are used to implement this mechanism. 
-    
-   This mechanism is not used for HTTP authentication to HTTP proxies. 
-    
-
-  
-Brezak                 Category - Informational                      4 
-                 HTTP Kerberos Access Authentication    November 2003 
-
-   If an HTTP proxy is used between the client and server, it must take 
-   care to not share authenticated connections between different 
-   authenticated clients to the same server. If this is not honored, 
-   then the server can easily lose track of security context 
-   associations. A proxy that correctly honors client to server 
-   authentication integrity will supply the "Proxy-support: Session-
-   Based-Authentication" HTTP header to the client in HTTP responses 
-   from the proxy. The client MUST NOT utilize the SPNEGO HTTP 
-   authentication mechanism through a proxy unless the proxy supplies 
-   this header with the "401 Unauthorized" response from the server. 
-    
-   When using the SPNEGO HTTP authentication facility with client 
-   supplied data such as PUT and POST, the authentication should be 
-   complete between the client and server before sending the user data. 
-   The return status from the gss_init_security_context will indicate 
-   with the security context is complete. At this point the data can be 
-   sent to the server. 
-    
-    
-8. References 
- 
-    
-    
-10. Author's Addresses 
-    
-   John Brezak 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@microsoft.com 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Brezak                 Category - Informational                      5 
-                 HTTP Kerberos Access Authentication    November 2003 
-
-    
-Full Copyright Statement 
- 
-   Copyright (C) The Internet Society (2001).  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this   
-   document itself may not be modified in any way, such as by removing   
-   the copyright notice or references to the Internet Society or other   
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
-    
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Brezak                 Category - Informational                      6 
diff --git a/doc/standardisation/draft-brezak-spnego-http-00.txt b/doc/standardisation/draft-brezak-spnego-http-00.txt
deleted file mode 100644
index 96f157a5f..000000000
--- a/doc/standardisation/draft-brezak-spnego-http-00.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-Kerberos working group                                         J.Brezak 
-Internet Draft                                                Microsoft 
-Document: draft-brezak-spnego-http-00.txt                                      
-Category: Informational                                                 
-                                                         September 2001 
- 
- 
-           HTTP Authentication: SPNEGO Access Authentication 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1]. 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." 
-     
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-    
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   This document describes how MicrosoftÆs Internet Explorer 5.0 and 
-   Internet Information Services 5.0 use Kerberos for security 
-   enhancements of web transactions. The HTTP auth-scheme of 
-   'negotiate' is defined here; when the negotiation results in the 
-   selection of Kerberos, the security services of authentication and 
-   optionally impersonation are performed. 
-    
-    
-2. Conventions used in this document 
-    
-   In examples, "C:" and "S:" indicate lines sent by the client and 
-   server respectively. 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [3]. 
-    
-    
-3. Access Authentication 
-    
-3.1 Reliance on the HTTP/1.1 Specification 
- 
-   This specification is a companion to the HTTP/1.1 specification [4] 
-   and builds on the authentication mechanisms defined in [5]. It uses 
-  
-Brezak                 Category û Informational                      1 
-
-
-
-
-
-
-
-
-                     SPNEGO Access Authentication       September 2001 
-
-   the augmented BNF section 2.1 of that document, and relies on both 
-   the non-terminals defined in that document and other aspects of the 
-   HTTP/1.1 specification. 
-    
-    
-4. HTTP Negotiate Authentication Scheme 
-    
-   Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate".  
-   The auth-params exchanged use data formats defined for use with the 
-   GSS-API [6].  In particular, they follow the formats set for the 
-   SPNEGO [7] and Kerberos [8] "mechanisms" for GSSAPI.  The 
-   "Negotiate" auth-scheme calls for the use of SPNEGO GSSAPI tokens 
-   which the specific mechanism type specifies. 
-    
-4.1 The WWW-Authenticate Response Header 
-    
-   If the server receives a request for an access-protected object, and 
-   an acceptable Authorization header is not sent, the server responds 
-   with a "401 Unauthorized" status code, and a WWW-Authenticate header 
-   as per the framework described in [4]. The negotiate scheme will 
-   operate as follows: 
-    
-    
-        challenge       = "Negotiate" auth-data 
-        auth-data       = 1#( [gssapi-data] ) 
-         
-   The meanings of the values of the directives used above are as 
-   follows: 
-    
-   gssapi-data 
-        If the gss_accept_security_context return a token for the 
-        client, this directive contains is the base64 encoding of an 
-        InitialContextToken as defined in [6]. 
-  
-   A status code 200 response can also carry a WWW-Authenticate 
-   response header containing the final leg of a authentication. Before 
-   using the contents of the response, the gssapi-data should be 
-   processed by gss_init_security_context to determine the state of the 
-   security context. If this function indicates success, the response 
-   can be used by the application. Otherwise an appropriate action 
-   based on the authentication status should be. 
-    
-   For example the authentication could have failed on the final leg if 
-   mutual authentication was requested and the server was not able to 
-   prove its identity. In this case, the returned results are suspect. 
-   It is not always possible to mutually authenticate the server before 
-   the HTTP operation. POST methods are in this category. 
-    
-   When the Kerberos Version 5 GSSAPI mechanism [RFC-1964] is being 
-   used, the HTTP server will be using a principal name of the form of 
-   "http/<hostname>". 
-    
-4.2 The Authorization Request Header 
- 
-  
-Brezak                 Category û Informational                      2 
-
-
-
-
-
-
-
-
-                     SPNEGO Access Authentication       September 2001 
-
-   The client is expected to retry the request, passing an 
-   Authorization header line, which is defined according to the 
-   framework described in [4] utilized as follow: 
-    
-        credentials             = "Negotiate" auth-data2 
-        auth-data2              = 1#( gssapi-data ) 
-                                 
-   gssapi-data 
-        This directive contains is the base64 encoding of an 
-        InitialContextToken as defined in [6]. 
-    
-   If a directive or its value is improper, or required directives are 
-   missing, the propose response is 400 Bad Request. If a 401 
-   Unauthorized status code is returned, the contents of the WWW-
-   Authenticate response header is used to continue the authentication 
-   as long as the opaque value is the same. 
-    
-5. Negotiate Operation Example 
-    
-   The user is logged onto realm A.COM as user@A.COM. The web server is 
-   in realm B using the principal http/server@B.COM. Realm B.COM trusts 
-   Realm A.COM  
-    
-   The client requests an access-protected document from server via a 
-   GET method request. The URI of the document is 
-   "http://www.nowhere.org/dir/index.html". 
-    
-   The first time the client requests the document, no Authorization 
-   header is sent, so the server responds with: 
-    
-        HTTP/1.1 401 Unauthorized 
-        WWW-Authenticate: Negotiate 
-         
-   The client will obtain the user credentials using the SPNEGO GSSAPI 
-   mechanism type to identify generate a GSSAPI message to be sent to 
-   the server with a new request, including the following Authorization 
-   header: 
-    
-        Authorization: Negotiate 
-        2a87421000492ade0234568ac0289eca874209af8bc028 
-         
-   The server will decode the gssapi-data and pass this to the SPNEGO 
-   GSSAPI mechanism in the gss_accept_security_context function. The 
-   return value from the gss_accept_security_context function can 
-   indicate the security context is complete and supply final 
-   authentication data to be returned to the client. If the server has 
-   more gssapi data to send to the client to complete the context it is 
-   to be carried in WWW-Authenticate header with the final response. 
-   The response will be sent to the client, including the following 
-   header: 
-    
-        HTTP/1.1 200 Success 
-        WWW-Authenticate: Negotiate ade0234568ac874209af8bc0280289eca 
-         
-  
-Brezak                 Category û Informational                      3 
-
-
-
-
-
-
-
-
-                     SPNEGO Access Authentication       September 2001 
-
-   The client will decode the gssapi-data and supply it to 
-   gss_init_security_context using the context for this server. If the 
-   status is successful from the final gss_init_security_context, the 
-   response can be used by the application. 
- 
-7. Security Considerations 
- 
-   The SPNEGO HTTP authentication facility is only used to provide 
-   authentication of a user to server. It provides no facilities for 
-   protecting the HTTP headers or data including the Authorization and 
-   WWW-Authenticate headers that are used to implement this mechanism. 
-    
-   This mechanism is not used for HTTP authentication to HTTP proxies. 
-    
-   If an HTTP proxy is used between the client and server, it must take 
-   care to not share authenticated connections between different 
-   authenticated clients to the same server. If this is not honored, 
-   then the server can easily lose track of security context 
-   associations. A proxy that correctly honors client to server 
-   authentication integrity will supply the "Proxy-support: Session-
-   Based-Authentication" HTTP header to the client in HTTP responses 
-   from the proxy. The client MUST NOT utilize the SPNEGO HTTP 
-   authentication mechanism through a proxy unless the proxy supplies 
-   this header with the 401 Unauthorized response from the server. 
-    
-    
-8. References 
-    
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   3  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   4 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 
-      Leach, P. and T. Berners-Lee,  "Hypertext Transfer Protocol -- 
-      HTTP/1.1", RFC 2616, June 1999. 
-     
-   5 Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, 
-      P., Luotonen, A., Stewart, L., "HTTP Authentication: Basic and 
-      Digest Access Authentication", RFC 2617, June 1999. 
-    
-   6 Linn, J., "Generic Security Service Application Program Interface, 
-      Version 2", RFC 2078, January 1997. 
-    
-   7 Baize, E., Pinkas, D., "The Simple and Protected GSS-API 
-      Negotiation Mechanism", RFC 2478, December 1998. 
-    
-   8 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 
-      June 1996. 
-    
- 
-    
-  
-Brezak                 Category û Informational                      4 
-
-
-
-
-
-
-
-
-                     SPNEGO Access Authentication       September 2001 
-
-    
-10. Author's Addresses 
-    
-   John Brezak 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@microsoft.com 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Brezak                 Category û Informational                      5 
-
-
-
-
-
-
-
-
-                     SPNEGO Access Authentication       September 2001 
-
-    
-Full Copyright Statement 
- 
-   Copyright (C) The Internet Society (2001).  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this   
-   document itself may not be modified in any way, such as by removing   
-   the copyright notice or references to the Internet Society or other   
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
-    
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Brezak                 Category û Informational                      6 
-
-
-
-
-
-
-
diff --git a/doc/standardisation/draft-brezak-spnego-http-01.txt b/doc/standardisation/draft-brezak-spnego-http-01.txt
deleted file mode 100644
index 5d27f9a0c..000000000
--- a/doc/standardisation/draft-brezak-spnego-http-01.txt
+++ /dev/null
@@ -1,190 +0,0 @@
-
-
-Kerberos working group                                         J.Brezak 
-Internet Draft                                                Microsoft 
-Document: draft-brezak-spnego-http-01.txt                                      
-Category: Informational                                                 
-                                                         September 2001 
- 
- 
-           HTTP Authentication: SPNEGO Access Authentication 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1]. 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." 
-     
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-    
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   This document describes how Microsoft's Internet Explorer 5.0 and 
-   Internet Information Services 5.0 use Kerberos for security 
-   enhancements of web transactions. The HTTP auth-scheme of 
-   "negotiate" is defined here; when the negotiation results in the 
-   selection of Kerberos, the security services of authentication and 
-   optionally impersonation are performed. 
-    
-    
-2. Conventions used in this document 
-    
-   In examples, "C:" and "S:" indicate lines sent by the client and 
-   server respectively. 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [3]. 
-    
-    
-3. Access Authentication 
-    
-3.1 Reliance on the HTTP/1.1 Specification 
- 
-   This specification is a companion to the HTTP/1.1 specification [4] 
-   and builds on the authentication mechanisms defined in [5]. It uses 
-  
-Brezak                 Category - Informational                      1 
-
-
-
-
-
-
-
-
-                     SPNEGO Access Authentication       September 2001 
-
-   the augmented BNF section 2.1 of that document, and relies on both 
-   the non-terminals defined in that document and other aspects of the 
-   HTTP/1.1 specification. 
-    
-    
-4. HTTP Negotiate Authentication Scheme 
-    
-   Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate".  
-   The auth-params exchanged use data formats defined for use with the 
-   GSS-API [6].  In particular, they follow the formats set for the 
-   SPNEGO [7] and Kerberos [8] "mechanisms" for GSSAPI.  The 
-   "Negotiate" auth-scheme calls for the use of SPNEGO GSSAPI tokens 
-   which the specific mechanism type specifies. 
-    
-4.1 The WWW-Authenticate Response Header 
-    
-   If the server receives a request for an access-protected object, and 
-   an acceptable Authorization header is not sent, the server responds 
-   with a "401 Unauthorized" status code, and a WWW-Authenticate header 
-   as per the framework described in [4]. The negotiate scheme will 
-   operate as follows: 
-    
-    
-        challenge       = "Negotiate" auth-data 
-        auth-data       = 1#( [gssapi-data] ) 
-         
-   The meanings of the values of the directives used above are as 
-   follows: 
-    
-   gssapi-data 
-        If the gss_accept_security_context return a token for the 
-        client, this directive contains is the base64 encoding of an 
-        InitialContextToken as defined in [6]. 
-  
-   A status code 200 response can also carry a WWW-Authenticate 
-   response header containing the final leg of a authentication. Before 
-   using the contents of the response, the gssapi-data should be 
-   processed by gss_init_security_context to determine the state of the 
-   security context. If this function indicates success, the response 
-   can be used by the application. Otherwise an appropriate action 
-   based on the authentication status should be. 
-    
-   For example the authentication could have failed on the final leg if 
-   mutual authentication was requested and the server was not able to 
-   prove its identity. In this case, the returned results are suspect. 
-   It is not always possible to mutually authenticate the server before 
-   the HTTP operation. POST methods are in this category. 
-    
-   When the Kerberos Version 5 GSSAPI mechanism [RFC-1964] is being 
-   used, the HTTP server will be using a principal name of the form of 
-   "http/<hostname>". 
-    
-4.2 The Authorization Request Header 
- 
-  
-Brezak                 Category - Informational                      2 
-
-
-
-
-
-
-
-
-                     SPNEGO Access Authentication       September 2001 
-
-   The client is expected to retry the request, passing an 
-   Authorization header line, which is defined according to the 
-   framework described in [4] utilized as follow: 
-    
-        credentials             = "Negotiate" auth-data2 
-        auth-data2              = 1#( gssapi-data ) 
-                                 
-   gssapi-data 
-        This directive contains is the base64 encoding of an 
-        InitialContextToken as defined in [6]. 
-    
-   If a directive or its value is improper, or required directives are 
-   missing, the propose response is 400 Bad Request. If a 401 
-   Unauthorized status code is returned, the contents of the WWW-
-   Authenticate response header is used to continue the authentication 
-   as long as the opaque value is the same. 
-    
-5. Negotiate Operation Example 
-    
-   The user is logged onto realm A.COM as user@A.COM. The web server is 
-   in realm B using the principal http/server@B.COM. Realm B.COM trusts 
-   Realm A.COM  
-    
-   The client requests an access-protected document from server via a 
-   GET method request. The URI of the document is 
-   "http://www.nowhere.org/dir/index.html". 
-    
-   The first time the client requests the document, no Authorization 
-   header is sent, so the server responds with: 
-    
-        HTTP/1.1 401 Unauthorized 
-        WWW-Authenticate: Negotiate 
-         
-   The client will obtain the user credentials using the SPNEGO GSSAPI 
-   mechanism type to identify generate a GSSAPI message to be sent to 
-   the server with a new request, including the following Authorization 
-   header: 
-    
-        Authorization: Negotiate 
-        2a87421000492ade0234568ac0289eca874209af8bc028 
-         
-   The server will decode the gssapi-data and pass this to the SPNEGO 
-   GSSAPI mechanism in the gss_accept_security_context function. The 
-   return value from the gss_accept_security_context function can 
-   indicate the security context is complete and supply final 
-   authentication data to be returned to the client. If the server has 
-   more gssapi data to send to the client to complete the context it is 
-   to be carried in WWW-Authenticate header with the final response. 
-   The response will be sent to the client, including the following 
-   header: 
-    
-        HTTP/1.1 200 Success 
-        WWW-Authenticate: Negotiate ade0234568ac874209af8bc0280289eca 
-         
-  
-Brezak                 Category - Informational                     
\ No newline at end of file
diff --git a/doc/standardisation/draft-brezak-spnego-http-02.txt b/doc/standardisation/draft-brezak-spnego-http-02.txt
deleted file mode 100644
index 3eb8d7fce..000000000
--- a/doc/standardisation/draft-brezak-spnego-http-02.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-Kerberos working group                                         J.Brezak 
-Internet Draft                                                Microsoft 
-Document: draft-brezak-spnego-http-02.txt                               
-Category: Informational                                                 
-                                                          November 2001 
- 
- 
-           HTTP Authentication: SPNEGO Access Authentication 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1]. 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." 
-     
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-    
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   This document describes how Microsoft's Internet Explorer (MSIE) and 
-   Internet Information Services (IIS) incorporated in Windows 2000 use 
-   Kerberos for security enhancements of web transactions. The HTTP 
-   auth-scheme of "negotiate" is defined here; when the negotiation 
-   results in the selection of Kerberos, the security services of 
-   authentication and optionally impersonation are performed. 
-    
-   This document explains how HTTP authentication utilizes the SPNEGO 
-   [7] GSSAPI mechanism. Details of SPNEGO implementation are not 
-   provided in this document. 
-    
-    
-2. Conventions used in this document 
-    
-   In examples, "C:" and "S:" indicate lines sent by the client and 
-   server respectively. 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [3]. 
-    
-    
-3. Access Authentication 
-    
-  
-Brezak                 Category - Informational                      1 
-
-
-
-
-
-
-
-
-                  HTTP SPNEGO Access Authentication     November 2001 
-
-3.1 Reliance on the HTTP/1.1 Specification 
- 
-   This specification is a companion to the HTTP/1.1 specification [4] 
-   and builds on the authentication mechanisms defined in [5]. It uses 
-   the augmented BNF section 2.1 of that document, and relies on both 
-   the non-terminals defined in that document and other aspects of the 
-   HTTP/1.1 specification. 
-    
-    
-4. HTTP Negotiate Authentication Scheme 
-    
-   Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate".  
-   The auth-params exchanged use data formats defined for use with the 
-   GSS-API [6].  In particular, they follow the formats set for the 
-   SPNEGO [7] and Kerberos [8] mechanisms for GSSAPI.  The "Negotiate" 
-   auth-scheme calls for the use of SPNEGO GSSAPI tokens which the 
-   specific mechanism type specifies. 
-    
-   The current implementation of this protocol is limited to the use of 
-   SPNEGO with the Kerberos and Microsoft NTLM protocols. 
-    
-4.1 The WWW-Authenticate Response Header 
-    
-   If the server receives a request for an access-protected object, and 
-   an acceptable Authorization header has not been sent, the server 
-   responds with a "401 Unauthorized" status code, and a "WWW-
-   Authenticate:" header as per the framework described in [4]. The 
-   initial WWW-Authenticate header will not carry any gssapi-data. 
-    
-   The negotiate scheme will operate as follows: 
-    
-        challenge       = "Negotiate" auth-data 
-        auth-data       = 1#( [gssapi-data] ) 
-         
-   The meanings of the values of the directives used above are as 
-   follows: 
-    
-   gssapi-data 
-        If the gss_accept_security_context return a token for the 
-        client, this directive contains the base64 encoding of an 
-        InitialContextToken as defined in [6]. This is not present in 
-        the initial response from the server. 
-  
-   A status code 200 status response can also carry a "WWW-
-   Authenticate" response header containing the final leg of an 
-   authentication. In this case, the gssapi-data will be present. 
-   Before using the contents of the response, the gssapi-data should be 
-   processed by gss_init_security_context to determine the state of the 
-   security context. If this function indicates success, the response 
-   can be used by the application. Otherwise an appropriate action 
-   based on the authentication status should be. 
-    
-   For example the authentication could have failed on the final leg if 
-   mutual authentication was requested and the server was not able to 
-  
-Brezak                 Category - Informational                      2 
-
-
-
-
-
-
-
-
-                  HTTP SPNEGO Access Authentication     November 2001 
-
-   prove its identity. In this case, the returned results are suspect. 
-   It is not always possible to mutually authenticate the server before 
-   the HTTP operation. POST methods are in this category. 
-    
-   When the Kerberos Version 5 GSSAPI mechanism [RFC-1964] is being 
-   used, the HTTP server will be using a principal name of the form of 
-   "http/<hostname>". 
-    
-4.2 The Authorization Request Header 
- 
-   Upon receipt of the response containing a "WWW-Authenticate" header 
-   from the server, the client is expected to retry the HTTP request, 
-   passing a HTTP "Authorization" header line. This is defined 
-   according to the framework described in [4] utilized as follows: 
-    
-        credentials             = "Negotiate" auth-data2 
-        auth-data2              = 1#( gssapi-data ) 
-                                 
-   gssapi-data 
-        This directive contains is the base64 encoding of an 
-        InitialContextToken as defined in [6]. 
-    
-   Any returned code other than a success 2xx code represents an 
-   authentication error. If a 401 containing a "WWW-Authenticate" 
-   header with "Negotiate" and gssapi-data is returned from the server, 
-   it is a continuation of the authentication request. 
-    
-   A client may initiate a connection to the server with an 
-   "Authorization" header containing the initial token for the server. 
-   This form will bypass the initial 401 error from the server when the 
-   client knows that the server will accept the Negotiate HTTP 
-   authentication type. 
-    
-5. Negotiate Operation Example 
-    
-   The client requests an access-protected document from server via a 
-   GET method request. The URI of the document is 
-   "http://www.nowhere.org/dir/index.html". 
-    
-        C: GET dir/index.html 
-    
-   The first time the client requests the document, no Authorization 
-   header is sent, so the server responds with: 
-    
-        S: HTTP/1.1 401 Unauthorized 
-        S: WWW-Authenticate: Negotiate 
-         
-   The client will obtain the user credentials using the SPNEGO GSSAPI 
-   mechanism type to identify generate a GSSAPI message to be sent to 
-   the server with a new request, including the following Authorization 
-   header: 
-    
-        C: GET dir/index.html 
-        C: Authorization: Negotiate a87421000492aa874209af8bc028 
-  
-Brezak                 Category - Informational                      3 
-
-
-
-
-
-
-
-
-                  HTTP SPNEGO Access Authentication     November 2001 
-
-         
-   The server will decode the gssapi-data and pass this to the SPNEGO 
-   GSSAPI mechanism in the gss_accept_security_context function. If the 
-   context is not complete, the server will respond with a 401 status 
-   code with a WWW-Authenticate header containing the gssapi-data. 
-    
-        S: HTTP/1.1 401 Unauthorized 
-        S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356 
-    
-   The client will decode the gssapi-data and pass this into 
-   gss_init_security_context and return the new gssapi-data to the 
-   server. 
-    
-        C: GET dir/index.html 
-        C: Authorization: Negotiate 89a8742aa8729a8b028 
-    
-   This cycle can continue until the security context is complete. 
-    
-   When the return value from the gss_accept_security_context function 
-   indicates that the security context is complete, it may supply final 
-   authentication data to be returned to the client. If the server has 
-   more gssapi data to send to the client to complete the context it is 
-   to be carried in WWW-Authenticate header with the final response 
-   containing the HTTP body. 
-    
-        S: HTTP/1.1 200 Success 
-        S: WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca 
-         
-   The client will decode the gssapi-data and supply it to 
-   gss_init_security_context using the context for this server. If the 
-   status is successful from the final gss_init_security_context, the 
-   response can be used by the application. 
- 
-7. Security Considerations 
- 
-   The SPNEGO HTTP authentication facility is only used to provide 
-   authentication of a user to server. It provides no facilities for 
-   protecting the HTTP headers or data including the Authorization and 
-   WWW-Authenticate headers that are used to implement this mechanism. 
-    
-   This mechanism is not used for HTTP authentication to HTTP proxies. 
-    
-   If an HTTP proxy is used between the client and server, it must take 
-   care to not share authenticated connections between different 
-   authenticated clients to the same server. If this is not honored, 
-   then the server can easily lose track of security context 
-   associations. A proxy that correctly honors client to server 
-   authentication integrity will supply the "Proxy-support: Session-
-   Based-Authentication" HTTP header to the client in HTTP responses 
-   from the proxy. The client MUST NOT utilize the SPNEGO HTTP 
-   authentication mechanism through a proxy unless the proxy supplies 
-   this header with the "401 Unauthorized" response from the server. 
-    
-
-  
-Brezak                 Category - Informational                      4 
-
-
-
-
-
-
-
-
-                  HTTP SPNEGO Access Authentication     November 2001 
-
-   When using the SPNEGO HTTP authentication facility with client 
-   supplied data such as PUT and POST, the authentication should be 
-   complete between the client and server before sending the user data. 
-   The return status from the gss_init_security_context will indicate 
-   with the security context is complete. At this point the data can be 
-   sent to the server. 
-    
-    
-8. References 
-    
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   3  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   4 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 
-      Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 
-      HTTP/1.1", RFC 2616, June 1999. 
-     
-   5 Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, 
-      P., Luotonen, A., Stewart, L., "HTTP Authentication: Basic and 
-      Digest Access Authentication", RFC 2617, June 1999. 
-    
-   6 Linn, J., "Generic Security Service Application Program Interface, 
-      Version 2", RFC 2078, January 1997. 
-    
-   7 Baize, E., Pinkas, D., "The Simple and Protected GSS-API 
-      Negotiation Mechanism", RFC 2478, December 1998. 
-    
-   8 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 
-      June 1996. 
-    
- 
-    
-    
-10. Author's Addresses 
-    
-   John Brezak 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@microsoft.com 
-
-
-
-
-
-
-
-
-
-
-  
-Brezak                 Category - Informational                      5 
-
-
-
-
-
-
-
-
-                  HTTP SPNEGO Access Authentication     November 2001 
-
-    
-Full Copyright Statement 
- 
-   Copyright (C) The Internet Society (2001).  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this   
-   document itself may not be modified in any way, such as by removing   
-   the copyright notice or references to the Internet Society or other   
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
-    
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Brezak                 Category - Informational                      6 
-
-
-
-
-
-
-
diff --git a/doc/standardisation/draft-brezak-spnego-http-04.txt b/doc/standardisation/draft-brezak-spnego-http-04.txt
deleted file mode 100644
index 9f75bbbf4..000000000
--- a/doc/standardisation/draft-brezak-spnego-http-04.txt
+++ /dev/null
@@ -1,349 +0,0 @@
-
-
-
-Kerberos working group                                         J.Brezak 
-Internet Draft                                                Microsoft 
-Document: draft-brezak-spnego-http-04.txt                               
-Category: Informational                                                 
-                                                           October 2002 
- 
- 
-           HTTP Authentication: SPNEGO Access Authentication 
-                 As implemented in Microsoft Windows 2000 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1]. 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." 
-     
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-    
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   This document describes how the Microsoft Internet Explorer (MSIE) 
-   and Internet Information Services (IIS) incorporated in Microsoft 
-   Windows 2000 use Kerberos for security enhancements of web 
-   transactions. The HTTP auth-scheme of "negotiate" is defined here; 
-   when the negotiation results in the selection of Kerberos, the 
-   security services of authentication and optionally impersonation are 
-   performed. 
-    
-   This document explains how HTTP authentication utilizes the SPNEGO 
-   [7] GSSAPI mechanism. Details of SPNEGO implementation are not 
-   provided in this document. 
-    
-    
-2. Conventions used in this document 
-    
-   In examples, "C:" and "S:" indicate lines sent by the client and 
-   server respectively. 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [3]. 
-    
-    
-  
-Brezak                 Category - Informational                      1 
-                  HTTP SPNEGO Access Authentication      October 2002 
-
-3. Access Authentication 
-    
-3.1 Reliance on the HTTP/1.1 Specification 
- 
-   This specification is a companion to the HTTP/1.1 specification [4] 
-   and builds on the authentication mechanisms defined in [5]. It uses 
-   the augmented BNF section 2.1 of that document, and relies on both 
-   the non-terminals defined in that document and other aspects of the 
-   HTTP/1.1 specification. 
-    
-    
-4. HTTP Negotiate Authentication Scheme 
-    
-   Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate".  
-   The auth-params exchanged use data formats defined for use with the 
-   GSS-API [6].  In particular, they follow the formats set for the 
-   SPNEGO [7] and Kerberos [8] mechanisms for GSSAPI.  The "Negotiate" 
-   auth-scheme calls for the use of SPNEGO GSSAPI tokens which the 
-   specific mechanism type specifies. 
-    
-   The current implementation of this protocol is limited to the use of 
-   SPNEGO with the Kerberos and Microsoft NTLM protocols. 
-    
-4.1 The WWW-Authenticate Response Header 
-    
-   If the server receives a request for an access-protected object, and 
-   an acceptable Authorization header has not been sent, the server 
-   responds with a "401 Unauthorized" status code, and a "WWW-
-   Authenticate:" header as per the framework described in [4]. The 
-   initial WWW-Authenticate header will not carry any gssapi-data. 
-    
-   The negotiate scheme will operate as follows: 
-    
-        challenge       = "Negotiate" auth-data 
-        auth-data       = 1#( [gssapi-data] ) 
-         
-   The meanings of the values of the directives used above are as 
-   follows: 
-    
-   gssapi-data 
-        If the gss_accept_security_context return a token for the 
-        client, this directive contains the base64 encoding of an 
-        InitialContextToken as defined in [6]. This is not present in 
-        the initial response from the server. 
-  
-   A status code 200 status response can also carry a "WWW-
-   Authenticate" response header containing the final leg of an 
-   authentication. In this case, the gssapi-data will be present. 
-   Before using the contents of the response, the gssapi-data should be 
-   processed by gss_init_security_context to determine the state of the 
-   security context. If this function indicates success, the response 
-   can be used by the application. Otherwise an appropriate action 
-   based on the authentication status should be. 
-    
-  
-Brezak                 Category - Informational                      2 
-                  HTTP SPNEGO Access Authentication      October 2002 
-
-   For example the authentication could have failed on the final leg if 
-   mutual authentication was requested and the server was not able to 
-   prove its identity. In this case, the returned results are suspect. 
-   It is not always possible to mutually authenticate the server before 
-   the HTTP operation. POST methods are in this category. 
-    
-   When the Kerberos Version 5 GSSAPI mechanism [RFC-1964] is being 
-   used, the HTTP server will be using a principal name of the form of 
-   "HTTP/<hostname>". 
-    
-4.2 The Authorization Request Header 
- 
-   Upon receipt of the response containing a "WWW-Authenticate" header 
-   from the server, the client is expected to retry the HTTP request, 
-   passing a HTTP "Authorization" header line. This is defined 
-   according to the framework described in [4] utilized as follows: 
-    
-        credentials             = "Negotiate" auth-data2 
-        auth-data2              = 1#( gssapi-data ) 
-                                 
-   gssapi-data 
-        This directive contains is the base64 encoding of an 
-        InitialContextToken as defined in [6]. 
-    
-   Any returned code other than a success 2xx code represents an 
-   authentication error. If a 401 containing a "WWW-Authenticate" 
-   header with "Negotiate" and gssapi-data is returned from the server, 
-   it is a continuation of the authentication request. 
-    
-   A client may initiate a connection to the server with an 
-   "Authorization" header containing the initial token for the server. 
-   This form will bypass the initial 401 error from the server when the 
-   client knows that the server will accept the Negotiate HTTP 
-   authentication type. 
-    
-5. Negotiate Operation Example 
-    
-   The client requests an access-protected document from server via a 
-   GET method request. The URI of the document is 
-   "http://www.nowhere.org/dir/index.html". 
-    
-        C: GET dir/index.html 
-    
-   The first time the client requests the document, no Authorization 
-   header is sent, so the server responds with: 
-    
-        S: HTTP/1.1 401 Unauthorized 
-        S: WWW-Authenticate: Negotiate 
-         
-   The client will obtain the user credentials using the SPNEGO GSSAPI 
-   mechanism type to identify generate a GSSAPI message to be sent to 
-   the server with a new request, including the following Authorization 
-   header: 
-    
-  
-Brezak                 Category - Informational                      3 
-                  HTTP SPNEGO Access Authentication      October 2002 
-
-        C: GET dir/index.html 
-        C: Authorization: Negotiate a87421000492aa874209af8bc028 
-         
-   The server will decode the gssapi-data and pass this to the SPNEGO 
-   GSSAPI mechanism in the gss_accept_security_context function. If the 
-   context is not complete, the server will respond with a 401 status 
-   code with a WWW-Authenticate header containing the gssapi-data. 
-    
-        S: HTTP/1.1 401 Unauthorized 
-        S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356 
-    
-   The client will decode the gssapi-data and pass this into 
-   gss_init_security_context and return the new gssapi-data to the 
-   server. 
-    
-        C: GET dir/index.html 
-        C: Authorization: Negotiate 89a8742aa8729a8b028 
-    
-   This cycle can continue until the security context is complete. 
-    
-   When the return value from the gss_accept_security_context function 
-   indicates that the security context is complete, it may supply final 
-   authentication data to be returned to the client. If the server has 
-   more gssapi data to send to the client to complete the context it is 
-   to be carried in WWW-Authenticate header with the final response 
-   containing the HTTP body. 
-    
-        S: HTTP/1.1 200 Success 
-        S: WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca 
-         
-   The client will decode the gssapi-data and supply it to 
-   gss_init_security_context using the context for this server. If the 
-   status is successful from the final gss_init_security_context, the 
-   response can be used by the application. 
- 
-7. Security Considerations 
- 
-   The SPNEGO HTTP authentication facility is only used to provide 
-   authentication of a user to server. It provides no facilities for 
-   protecting the HTTP headers or data including the Authorization and 
-   WWW-Authenticate headers that are used to implement this mechanism. 
-    
-   This mechanism is not used for HTTP authentication to HTTP proxies. 
-    
-   If an HTTP proxy is used between the client and server, it must take 
-   care to not share authenticated connections between different 
-   authenticated clients to the same server. If this is not honored, 
-   then the server can easily lose track of security context 
-   associations. A proxy that correctly honors client to server 
-   authentication integrity will supply the "Proxy-support: Session-
-   Based-Authentication" HTTP header to the client in HTTP responses 
-   from the proxy. The client MUST NOT utilize the SPNEGO HTTP 
-   authentication mechanism through a proxy unless the proxy supplies 
-   this header with the "401 Unauthorized" response from the server. 
-  
-Brezak                 Category - Informational                      4 
-                  HTTP SPNEGO Access Authentication      October 2002 
-
-    
-   When using the SPNEGO HTTP authentication facility with client 
-   supplied data such as PUT and POST, the authentication should be 
-   complete between the client and server before sending the user data. 
-   The return status from the gss_init_security_context will indicate 
-   with the security context is complete. At this point the data can be 
-   sent to the server. 
-    
-    
-8. References 
-    
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   3  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   4 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 
-      Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 
-      HTTP/1.1", RFC 2616, June 1999. 
-     
-   5 Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, 
-      P., Luotonen, A., Stewart, L., "HTTP Authentication: Basic and 
-      Digest Access Authentication", RFC 2617, June 1999. 
-    
-   6 Linn, J., "Generic Security Service Application Program Interface, 
-      Version 2", RFC 2078, January 1997. 
-    
-   7 Baize, E., Pinkas, D., "The Simple and Protected GSS-API 
-      Negotiation Mechanism", RFC 2478, December 1998. 
-    
-   8 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 
-      June 1996. 
-    
- 
-    
-    
-10. Author's Addresses 
-    
-   John Brezak 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@microsoft.com 
-
-
-
-
-
-
-
-
-
-  
-Brezak                 Category - Informational                      5 
-                  HTTP SPNEGO Access Authentication      October 2002 
-
-    
-Full Copyright Statement 
- 
-   Copyright (C) The Internet Society (2001).  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this   
-   document itself may not be modified in any way, such as by removing   
-   the copyright notice or references to the Internet Society or other   
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
-    
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Brezak                 Category - Informational                      6 
\ No newline at end of file
diff --git a/doc/standardisation/draft-brezak-win2k-krb-authz-01.txt b/doc/standardisation/draft-brezak-win2k-krb-authz-01.txt
deleted file mode 100644
index 172776118..000000000
--- a/doc/standardisation/draft-brezak-win2k-krb-authz-01.txt
+++ /dev/null
@@ -1,523 +0,0 @@
-
-
-
-Kerberos working group                                      John Brezak 
-Internet Draft                                                Microsoft 
-Document: draft-brezak-win2k-krb-authz-01.txt                           
-Category: Informational                                   October, 2002 
- 
- 
- Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for 
-                      Access Control to Resources 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is subject to all provisions  
-   of Section 10 of RFC2026 [1] except that the right to create 
-   derivative works is not granted. 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." 
-     
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-    
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   Microsoft Windows 2000 includes operating system specific data in 
-   the Kerberos V5 [1] authorization data field that is used for access 
-   control. This data is used to create an NT access token. The access 
-   token is used by the system to enforce access checking when 
-   attempting to access objects. This document describes the structure 
-   of the Windows 2000 specific authorization data that is carried in 
-   that field for use by servers in performing access control. 
-    
-    
-2. Conventions used in this document 
-    
-   All defined data structures are defined using "C" style constructs 
-   unless otherwise stated. All data is encoded as little-endian. 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-    
-    
-3. Top-Level PAC Structure 
-    
-   The PAC is generated by the KDC under the following conditions: 
-
-  
-Brezak                 Category - Informational                      1 
-               Windows 2000 Kerberos Authorization Data   October 2002 
- 
- 
-     o during an AS request that has been validated with pre-
-        authentication 
-     o during a TGS request when the client has no PAC and the target 
-        is a service in the domain or a ticket granting service 
-        (referral ticket). 
-    
-   The PAC itself is included in the IF-RELEVANT (ID 1) portion of the 
-   authorization data in a ticket. Within the IF-RELEVANT portion, it 
-   is encoded KERB_AUTH_DATA_PAC with ID 128. 
-    
-   The PAC is defined as a C data type, with integers encoded in 
-   little-endian order. The PAC itself is made up of several layers. 
-   The outer structure, contained directly in the authorization data, 
-   is as follows. The top-level structure is the PACTYPE structure: 
-    
-        typedef unsigned long ULONG; 
-        typedef unsigned short USHORT; 
-        typedef unsigned long64 ULONG64; 
-        typedef unsigned char UCHAR; 
-         
-        typedef struct _PACTYPE { 
-            ULONG cBuffers; 
-            ULONG Version;                          
-            PAC_INFO_BUFFER Buffers[1]; 
-        } PACTYPE; 
-    
-   The fields are defined as follows: 
-   cBuffers - contains the number of entries in the array Buffers 
-   Version - this is version zero 
-   Buffers - contains a conformant array of PAC_INFO_BUFFER structures 
-    
-   The PAC_INFO_BUFFER structure contains information about each piece 
-   of the PAC.  
-    
-        typedef struct _PAC_INFO_BUFFER { 
-            ULONG ulType; 
-            ULONG cbBufferSize; 
-            ULONG64 Offset; 
-        } PAC_INFO_BUFFER; 
-    
-   Type fields are defined as follows: 
-    
-   ulType - contains the type of data contained in this buffer. For 
-           Windows 2000 access control, it may be one of the following, 
-           which are explained further below: 
-            
-           #define PAC_LOGON_INFO               1 
-           #define PAC_SERVER_CHECKSUM          6 
-           #define PAC_PRIVSVR_CHECKSUM         7 
-            
-   Offset - contains the offset to the beginning of the data, in bytes, 
-           from the beginning of the PACTYPE structure. The data offset 
-           must by a multiple of 8. If the data pointed to by this 
-  
-Brezak                 Category - Informational                      2 
-               Windows 2000 Kerberos Authorization Data   October 2002 
- 
- 
-           field is complex, the data is typically NDR encoded. If the 
-           data is simple (indicating it includes no pointer types or 
-           complex structures) it is a little-endian format data 
-           structure. 
-    
-4. PAC Credential Information (PAC_LOGON_INFO) 
- 
-   PAC_INFO_BUFFERs of type PAC_LOGON_INFO contain the credential 
-   information for the client of the Kerberos ticket. The data itself 
-   is contained in a KERB_VALIDATION_INFO structure, which is NDR 
-   encoded. The output of the NDR encoding is placed in the 
-   PAC_INFO_BUFFER structure of type PAC_LOGON_INFO. 
-    
-        typedef struct _KERB_VALIDATION_INFO { 
-            FILETIME Reserved0; 
-            FILETIME Reserved1; 
-            FILETIME KickOffTime; 
-            FILETIME Reserved2; 
-            FILETIME Reserved3; 
-            FILETIME Reserved4; 
-            UNICODE_STRING Reserved5; 
-            UNICODE_STRING Reserved6; 
-            UNICODE_STRING Reserved7; 
-            UNICODE_STRING Reserved8; 
-            UNICODE_STRING Reserved9; 
-            UNICODE_STRING Reserved10; 
-            USHORT Reserved11; 
-            USHORT Reserved12; 
-            ULONG UserId; 
-            ULONG PrimaryGroupId; 
-            ULONG GroupCount; 
-            [size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds; 
-            ULONG UserFlags; 
-            ULONG Reserved13[4]; 
-            UNICODE_STRING Reserved14; 
-            UNICODE_STRING Reserved15; 
-            PSID LogonDomainId; 
-            ULONG Reserved16[2]; 
-            ULONG Reserved17; 
-            ULONG Reserved18[7]; 
-            ULONG SidCount; 
-            [size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids; 
-            PSID ResourceGroupDomainSid; 
-            ULONG ResourceGroupCount; 
-            [size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP 
-        ResourceGroupIds; 
-        } KERB_VALIDATION_INFO; 
-    
-   Reserved fields are not defined in this document and are not used in 
-   the construction of access control tokens. 
-    
-   The fields are defined as follows: 
-    
-  
-Brezak                 Category - Informational                      3 
-               Windows 2000 Kerberos Authorization Data   October 2002 
- 
- 
-   KickOffTime - the time at which the server should forcibly logoff 
-           the client. If the client should not be forced off, this 
-           field should be set to (0x7fffffff,0xffffffff). If a kickoff 
-           time is to be enforced, the service ticket lifetime will 
-           never exceed this value. 
-   UserId - This field contains the relative Id for the client. If 
-           zero, then the User ID is the first SID in the ExtraSids 
-           field. 
-   PrimaryGroupId - This field contains the relative ID for this 
-           clientÆs primary group. 
-   GroupCount - This field contains the number of groups, within the 
-           clientÆs domain, to which the client is a member. 
-   GroupIds - This field contains an array of the relative Ids and 
-           attributes of the groups in the clientÆs domain of which the 
-           client is a member. 
-   UserFlags - This field contains information about which fields in 
-           this structure are valid. The two bits that may be set are 
-           indicated below. Having these flags set indicates that the 
-           corresponding fields in the KERB_VALIDATION_INFO structure 
-           are present and valid. 
-            
-           #define LOGON_EXTRA_SIDS             0x0020 
-           #define LOGON_RESOURCE_GROUPS        0x0200 
-            
-   LogonDomainId - This field contains the SID of the clientÆs domain. 
-           This field is used in conjunction with the UserId, 
-           PrimaryGroupId,and GroupIds fields to create the user and 
-           group SIDs for the client. 
-   SidCount - This field contains the number of SIDs present in the 
-           ExtraSids field. This field is only valid if the 
-           LOGON_EXTRA_SIDS flag has been set in the UserFlags field. 
-   ExtraSids - This field contains a list of SIDs for groups to which 
-           the user is a member. This field is only valid if the 
-           LOGON_EXTRA_SIDS flag has been set in the UserFlags field. 
-   ResouceGroupCount - This field contains the number of resource 
-           groups in the ResourceGroupIds field. This field is only 
-           valid if the LOGON RESOURCE_GROUPS flag has been set in the 
-           UserFlags field._  
-   ResourceGroupDomainSid - This field contains the SID of the resource 
-           domain. This field is used in conjunction with the 
-           ResourceGroupIds field to create the group SIDs for the 
-           client. 
-   ResourceGroupIds - This field contains an array of the relative Ids 
-           and attributes of the groups in the resource domain of which 
-           the resource is a member. 
-    
-   When used in the KERB_VALIDATION_INFO, this is NDR encoded. The 
-   FILETIME type is defined as follows: 
-    
-        typedef unsigned int DWORD; 
-         
-        typedef struct _FILETIME { 
-            DWORD dwLowDateTime; 
-  
-Brezak                 Category - Informational                      4 
-               Windows 2000 Kerberos Authorization Data   October 2002 
- 
- 
-            DWORD dwHighDateTime; 
-        } FILETIME; 
-    
-   Times are encoded as the number of 100 nanosecond increments since 
-   January 1, 1601, in UTC time. 
-    
-   When used in the KERB_VALIDATION_INFO, this is NDR encoded. The 
-   UNICODE_STRING structure is defined as: 
-    
-        typedef struct _UNICODE_STRING 
-            USHORT Length; 
-            USHORT MaximumLength; 
-            [size_is(MaximumLength / 2), length_is((Length) / 2) ] 
-        USHORT *  Buffer; 
-        } UNICODE_STRING; 
-    
-   The Length field contains the number of bytes in the string, not 
-   including the null terminator, and the MaximumLength field contains 
-   the total number of bytes in the buffer containing the string. 
-    
-   The GROUP_MEMBERSHIP structure contains the relative ID of a group 
-   and the corresponding attributes for the group. 
-    
-        typedef struct _GROUP_MEMBERSHIP { 
-            ULONG RelativeId; 
-            ULONG Attributes; 
-        } *PGROUP_MEMBERSHIP; 
-    
-   The group attributes must be: 
-    
-        #define SE_GROUP_MANDATORY              (0x00000001L) 
-        #define SE_GROUP_ENABLED_BY_DEFAULT     (0x00000002L) 
-        #define SE_GROUP_ENABLED                (0x00000004L) 
-    
-   The SID structure is defined as follows: 
-    
-         
-        typedef struct _SID_IDENTIFIER_AUTHORITY { 
-            UCHAR Value[6]; 
-        } SID_IDENTIFIER_AUTHORITY, *PSID_IDENTIFIER_AUTHORITY; 
-         
-   The constant value for the NT Authority is  
-    
-        #define SECURITY_NT_AUTHORITY           {0,0,0,0,0,5} 
-         
-        typedef struct _SID { 
-           UCHAR Revision; 
-           UCHAR SubAuthorityCount; 
-           SID_IDENTIFIER_AUTHORITY IdentifierAuthority; 
-           [size_is(SubAuthorityCount)] ULONG SubAuthority[*]; 
-        } SID, *PSID; 
-    
-    
-  
-Brezak                 Category - Informational                      5 
-               Windows 2000 Kerberos Authorization Data   October 2002 
- 
- 
-   Other authorities are defined in the Microsoft Developer Network 
-   Development Kit 3. 
-   The SubAuthorityCount field contains the number of elements in the 
-   actual SubAuthority conformant array. The maximum number of 
-   subauthorities allowed is 15. 
-    
-   The KERB_SID_AND_ATTRIBUTES structure contains entire group SIDs and 
-   their corresponding attributes: 
-    
-        typedef struct _KERB_SID_AND_ATTRIBUTES { 
-            PSID Sid; 
-            ULONG Attributes; 
-        } KERB_SID_AND_ATTRIBUTES, *PKERB_SID_AND_ATTRIBUTES; 
-         
-   The attributes are the same as the group attributes defined above. 
-   
-5. Signatures (PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM) 
- 
-   The PAC contains two digital signatures: one using the key of the 
-   server, and one using the key of the KDC. The signatures are present 
-   for two reasons. First, the signature with the serverÆs key is 
-   present to prevent a client from generating their own PAC and 
-   sending it to the KDC as encrypted authorization data to be included 
-   in tickets. Second, the signature with the KDCÆs key is present to 
-   prevent an untrusted service from forging a ticket to itself with an 
-   invalid PAC. The two signatures are sent in PAC_INFO_BUFFERs of type 
-   PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM respectively. 
-    
-    
-   The signatures are contained in the following structure: 
-    
-        typedef struct _PAC_SIGNATURE_DATA { 
-            ULONG SignatureType; 
-            UCHAR Signature[1];      
-        } PAC_SIGNATURE_DATA, *PPAC_SIGNATURE_DATA; 
-    
-   The fields are defined as follows: 
-    
-   SignatureType - This field contains the type of checksum used to 
-           create a signature. The checksum must be a keyed checksum. 
-    
-   Signature - This field consists of an array of bytes containing the 
-           checksum data. The length of bytes may be determined by the 
-           wrapping PAC_INFO_BUFFER structure. 
-    
-   For the serverÆs checksum, the key used to generate the signature 
-   should be the same key used to encrypt the ticket. Thus, if the 
-   enc_tkt_in_skey option is used, the session key from the serverÆs 
-   TGT should be used. The Key used to encrypt ticket granting tickets 
-   is used to generate the KDCÆs checksum. 
-    
-   The checksums are computed as follows: 
-    
-  
-Brezak                 Category - Informational                      6 
-               Windows 2000 Kerberos Authorization Data   October 2002 
- 
- 
-     1. The complete PAC is built, including space for both checksums 
-     2. The data portion of both checksums is zeroed. 
-     3. The entire PAC structure is checksummed with the serverÆs key, 
-        and the result is stored in the serverÆs checksum structure. 
-     4. The serverÆs checksum is then checksummed with the KDC's key. 
-     5. The checksum with the KDC key is stored in the KDC's checksum 
-        structure. 
- 
-6. PAC Request Pre-Auth Data 
-    
-   Normally, the PAC is included in every pre-authenticated ticket 
-   received from an AS request. However, a client may also explicitly 
-   request either to include or to not include the PAC. This is done by 
-   sending the PAC-REQUEST preauth data. 
-    
-   This is an ASN.1 encoded structure. 
-    
-        KERB-PA-PAC-REQUEST     ::= SEQUENCE { 
-                include-pac[0] BOOLEAN -- if TRUE, and no pac present, 
-                                       -- include PAC. 
-                                       ---If FALSE, and pac 
-                                       -- PAC present, remove PAC 
-        }  
-    
-   The fields are defined as follows: 
-    
-   include-pac - This field indicates whether a PAC should be included 
-           or not. If the value is TRUE, a PAC will be included 
-           independent of other preauth data. If the value is FALSE, 
-           then no PAC will be included, even if other preauth data is 
-           present. 
-    
-   The preauth ID is: 
-        #define KRB5_PADATA_PAC_REQUEST         128 
-    
-7. Security Considerations 
- 
-   Before the PAC data is used for access control, the 
-   PAC_SERVER_CHECKSUM signature MUST be checked. This will verify that 
-   the provider of the PAC data knows the server's secret key.  
-   Validation of the PAC_PRIVSVR_CHECKSUM is OPTIONAL. It is used to 
-   verify that the PAC was issued from the KDC and not placed in the 
-   ticket by someone other than the KDC with access to the service key. 
-    
-   Caution must be used with accepting the SIDs present in the logon-
-   info part of the PAC. Only SIDs from a domain that is authoritative 
-   for a particular domain's SIDs should be used in the construction of 
-   access tokens. If a SID is found to be from outside of a domain's 
-   authoritative SID namespace, it MUST be ignored for purposes of 
-   access control. 
-    
-8. References 
-    
-  
-Brezak                 Category - Informational                      7 
-               Windows 2000 Kerberos Authorization Data   October 2002 
- 
- 
- 
-   1 Kohl, J., Neuman, C., "The Kerberos Network Authentication Service 
-      (V5)", RFC 1510, September 1993 
-    
-   2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-     Levels", BCP 14, RFC 2119, March 1997 
-    
-   3 Microsoft Developer's Network - http://msdn.microsoft.com 
-    
- 
-9. Author's Addresses 
-    
-   John Brezak 
-   Microsoft Corporation 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@microsoft.com 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Brezak                 Category - Informational                      8 
-               Windows 2000 Kerberos Authorization Data   October 2002 
- 
- 
-    
-Full Copyright Statement 
- 
-   Copyright (C) The Internet Society (1999).  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this   
-   document itself may not be modified in any way, such as by removing   
-   the copyright notice or references to the Internet Society or other   
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
-    
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Brezak                 Category - Informational                      9 
\ No newline at end of file
diff --git a/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-00.txt b/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-00.txt
deleted file mode 100644
index a29c1ca76..000000000
--- a/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-00.txt
+++ /dev/null
@@ -1,412 +0,0 @@
-CAT working group                                              M. Swift 
-Internet Draft                                                J. Brezak 
-Document: draft-brezak-win2k-krb-rc4-hmac-00.txt              Microsoft 
-Category: Informational                                 September, 1999 
- 
- 
-           The Windows 2000 RC4-HMAC Kerberos encryption type 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1]. 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." 
-     
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt 
- 
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   The Windows 2000 implementation of Kerberos introduces a new 
-   encryption type based on the RC4 encryption algorithm and using an 
-   MD5 HMAC for checksum. This is offered as an alternative to using 
-   the existing DES based encryption types. 
-    
-   The RC4-HMAC encryption types are used to ease upgrade of existing 
-   Windows NT environments, provide strong crypto (128-bit key 
-   lengths), and provide exportable (meet United States government 
-   export restriction requirements) encryption. 
-    
-   The Windows 2000 implementation of Kerberos contains new encryption 
-   and checksum types for two reasons: for export reasons early in the 
-   development process, 56 bit DES encryption could not be exported, 
-   and because upon upgrade from Windows NT 4.0 to Windows 2000, 
-   accounts will not have the appropriate DES keying material to do the 
-   standard DES encryption. Furthermore, 3DES is not available for 
-   export, and there was a desired to use a single flavor of encryption 
-   in the product for both US and international products. 
-    
-   As a result, there are two new encryption types and one new checksum 
-   type introduced in Windows 2000. 
-    
-    
-2. Conventions used in this document 
-    
-
-  
-Swift                  Category - Informational                      1 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       July 1999 
- 
- 
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-    
-3. Key Generation 
-    
-   On upgrade from existing Windows NT domains, the user accounts would 
-   not have a DES based key available to enable the use of DES base 
-   encryption types specified in RFC 1510. The key used for RC4-HMAC is 
-   the same as the existing Windows NT key for compatibility reasons. 
-   Once the account password is changed, the DES based keys are created 
-   and maintained. Once the DES keys are available DES based encryption 
-   types can be used with Kerberos.  
-    
-   The RC4-HMAC String to key function is defined as follow: 
-    
-   String2Key(password) 
-    
-        K = MD4(UNICODE(password)) 
-         
-   The RC4-HMAC keys are generated by using the Windows UNICODE version 
-   of the password. Each Windows UNICODE character is encoded in 
-   little-endian format of 2 octets each. Then performing an MD4 [6] 
-   hash operation on just the UNICODE characters of the password (not 
-   including the terminating zero octets). 
-    
-4. Basic Operations 
-    
-   The MD5 HMAC function is defined in [3]. It is used in this 
-   encryption type for checksum operations. Refer to [3] for details on 
-   its operation. In this document this function is referred to as 
-   HMAC(Key, Data) returning the checksum using the specified key on 
-   the data. 
-    
-   The basic MD5 hash operation is used in this encryption type and 
-   defined in [7]. In this document this function is referred to as 
-   MD5(Key, Data) returning the checksum using the specified key on the 
-   data. 
-    
-   The basic RC4 encryption operation is used in this encryption type 
-   and defined in [8]. In this document the function is referred to as 
-   RC4(Key, Data) returning the encrypted data using the specified key 
-   on the data. 
-    
-   These encryption types use key derivation as defined in [9] (RFC-
-   1510BIS) in Section titled "Key Derivation". With each message, the 
-   message type (T) is used as a component of the keying material. 
-    
-   The lengths of ASCII encoded character strings include the trailing 
-   terminator character (0). 
-    
-   The concat(a,b,c,...) function will return the logical concatenation 
-   (left to right) of the values of the arguments. 
-  
-Swift                  Category - Informational                      2 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       July 1999 
- 
- 
-    
-   The nonce(n) function returns a pseudo-random number of "n" octets. 
-    
-5. Checksum Types 
-    
-   There is one checksum type used in this encryption type. The 
-   Kerberos constant for this type is: 
-        #define KERB_CHECKSUM_HMAC_MD5 (-138) 
-    
-   The function is defined as follows: 
-    
-   K - is the Key 
-   T - the message type, encoded as a little-endian four byte integer 
-    
-   CHKSUM(K, T, data) 
-    
-        Ksign = HMAC(K, "signature key")  //includes zero octet at end 
-        tmp = MD5(Ksign, concat(T, data)) 
-        CHKSUM = HMAC(K, tmp) 
-    
-    
-6. Encryption Types 
-    
-   There are two encryption types used in these encryption types. The 
-   Kerberos constants for these types are: 
-        #define KERB_ETYPE_RC4_HMAC             23 
-        #define KERB_ETYPE_RC4_HMAC_EXP         24 
-    
-   The basic encryption function is defined as follow: 
-    
-   T = the message type, encoded as a little-endian four byte integer. 
-    
-   ENCRYPT(K, T, data) 
-        if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 
-                L = "fiftysixbits" //includes zero octet at end 
-        Else 
-                L = ""  // one octet of zero 
-        Ksign = HMAC(K, concat(L, T)) 
-        Confounder = nonce(8) // get an 8 octet nonce for a confounder 
-        Checksum = HMAC(Ksign, concat(Confounder, data)) 
-        Ke = Ksign 
-        if (L == "fiftysixbits") memset(&Ke[7], 0x0ab, 9) 
-        Ke2 = HMAC(Ke, Checksum) 
-        data = RC4(Ke2, data) 
-    
-   The header field on the encrypted data in KDC messages is: 
-    
-        typedef struct _RC4_MDx_HEADER { 
-            UCHAR Checksum[16]; 
-            UCHAR Confounder[8]; 
-        } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 
-    
-
-  
-Swift                  Category - Informational                      3 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       July 1999 
- 
- 
-   The character constant "fiftysixbits" evolved from the time when a 
-   56-bit key length was all that was exportable from the United 
-   States. It is now used to recognize that the key length is of 
-   "exportable" length. 
-    
-7. Key Strength Negotiation 
-    
-   A Kerberos client and server can negotiate over key length if they 
-   are using mutual authentication. If the client is unable to perform 
-   full strength encryption, it may propose a key in the "subkey" field 
-   of the authenticator, using a weaker encryption type. The server 
-   must then either return the same key or suggest its own key in the 
-   subkey field of the AP reply message. The key used to encrypt data 
-   is derived from the key returned by the server. If the client is 
-   able to perform strong encryption but the server is not, it may 
-   propose a subkey in the AP reply without first being sent a subkey 
-   in the authenticator. 
- 
-8. GSSAPI Kerberos V5 Mechanism Type  
- 
-8.1 Mechanism Specific Changes 
-    
-   The GSSAPI per-message tokens also require new checksum and 
-   encryption types. The GSS-API per-message tokens must be changed to 
-   support these new encryption types (See [5] Section 1.2.2). The 
-   sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption 
-   is: 
-        Byte 4..5 SEAL_ALG      0x10 0x00 - RC4 
-    
-   The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: 
-        Byte 2..3 SGN ALG       0x11 0x00 - HMAC 
-    
-   The only support quality of protection is: 
-        #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0 
-    
-   In addition, when using an RC4 based encryption type, the sequence 
-   number is sent in big-endian rather than little-endian order. 
-    
-8.2 GSSAPI Checksum Type 
-    
-   The GSSAPI checksum type and algorithm is defined in Section 5. Only 
-   the first 8 octets of the checksum are used. The resulting checksum 
-   is stored in the SGN_CKSUM field (See [5] Section 1.2) for 
-   GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). 
-    
-8.3 GSSAPI Encryption Types 
-    
-   There are two encryption types for GSSAPI message tokens, one that 
-   is 128 bits in strength, and one that is 56 bits in strength as 
-   defined in Section 6. 
-    
-
-
-  
-Swift                  Category - Informational                      4 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       July 1999 
- 
- 
-   All padding is rounded up to 1 byte. One byte is needed to say that 
-   there is 1 byte of padding. The DES based mechanism type uses 8 byte 
-   padding. See [5] Section 1.2.2.3. 
-    
-   The encryption mechanism used for GSS based messages is as follow: 
-    
-   GSS-ENCRYPT(K, T, data) 
-        IV = SND_SEQ 
-        K = XOR(K, 0xf0f0f0f0f0f0f0f0f0f0f0f0f0f0f0) 
-        if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 
-                L = "fortybits" //includes zero octet at end 
-        else 
-                L = "" // one octet of zero 
-        Ksign = HMAC(K, concat(L, T)) 
-        Ke = Ksign 
-        if (L == "fortybits") memset(&Ke[7], 0x0ab, 9) 
-        Ke2 = HMAC(Ke, IV) 
-        Data = RC4(Ke2, data) 
-        SND_SEQ = RC4(Ke, seq#) 
-         
-   The sequence number (SND_SEQ) and IV are used as defined in [5] 
-   Section 1.2.2. 
-    
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States. 
-   It is now used to recognize that the key length is of "exportable" 
-   length. 
-    
-8. Security Considerations 
- 
-   Care must be taken in implementing this encryption type because it 
-   uses a stream cipher. If a different IV isnÆt used in each direction 
-   when using a session key, the encryption is weak. By using the 
-   sequence number as an IV, this is avoided. 
-    
-9. References 
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   3  Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for 
-      Message Authentication", RFC 2104, February 1997 
-    
-   4  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
-      Service (V5)", RFC 1510, September 1993 
- 
-   5  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, 
-      June 1996 
- 
- 
-  
-Swift                  Category - Informational                      5 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       July 1999 
- 
- 
- 
-   6  R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 
-      1992 
- 
-   7  R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April 
-      1992 
- 
-   8  RC4 is a proprietary encryption algorithm available under license 
-             from RSA Data Security Inc.  For licensing information, 
-      contact: 
-             RSA Data Security, Inc. 
-             100 Marine Parkway 
-             Redwood City, CA 94065-1031 
- 
-   9  Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 
-      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
-      04.txt, June 25, 1999 
- 
-    
-10. Author's Addresses 
-    
-   Mike Swift 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: mikesw@microsoft.com  
-    
-   John Brezak 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@microsoft.com 
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                      6 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       July 1999 
- 
- 
-    
-11. Full Copyright Statement 
- 
-   Copyright (C) The Internet Society (1999).  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this   
-   document itself may not be modified in any way, such as by removing   
-   the copyright notice or references to the Internet Society or other   
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                      7 
-
\ No newline at end of file
diff --git a/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-01.txt b/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-01.txt
deleted file mode 100644
index a97ef9d19..000000000
--- a/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-01.txt
+++ /dev/null
@@ -1,412 +0,0 @@
-CAT working group                                              M. Swift 
-Internet Draft                                                J. Brezak 
-Document: draft-brezak-win2k-krb-rc4-hmac-01.txt              Microsoft 
-Category: Informational                                    October 1999 
- 
- 
-           The Windows 2000 RC4-HMAC Kerberos encryption type 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1]. 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." 
-     
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   The Windows 2000 implementation of Kerberos introduces a new 
-   encryption type based on the RC4 encryption algorithm and using an 
-   MD5 HMAC for checksum. This is offered as an alternative to using 
-   the existing DES based encryption types. 
-    
-   The RC4-HMAC encryption types are used to ease upgrade of existing 
-   Windows NT environments, provide strong crypto (128-bit key 
-   lengths), and provide exportable (meet United States government 
-   export restriction requirements) encryption. 
-    
-   The Windows 2000 implementation of Kerberos contains new encryption 
-   and checksum types for two reasons: for export reasons early in the 
-   development process, 56 bit DES encryption could not be exported, 
-   and because upon upgrade from Windows NT 4.0 to Windows 2000, 
-   accounts will not have the appropriate DES keying material to do the 
-   standard DES encryption. Furthermore, 3DES is not available for 
-   export, and there was a desire to use a single flavor of encryption 
-   in the product for both US and international products. 
-    
-   As a result, there are two new encryption types and one new checksum 
-   type introduced in Windows 2000. 
-    
-    
-2. Conventions used in this document 
-    
-
-  
-Swift                  Category - Informational                      1 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
- 
- 
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-    
-3. Key Generation 
-    
-   On upgrade from existing Windows NT domains, the user accounts would 
-   not have a DES based key available to enable the use of DES base 
-   encryption types specified in RFC 1510. The key used for RC4-HMAC is 
-   the same as the existing Windows NT key (NT Password Hash) for 
-   compatibility reasons. Once the account password is changed, the DES 
-   based keys are created and maintained. Once the DES keys are 
-   available DES based encryption types can be used with Kerberos.  
-    
-   The RC4-HMAC String to key function is defined as follow: 
-    
-   String2Key(password) 
-    
-        K = MD4(UNICODE(password)) 
-         
-   The RC4-HMAC keys are generated by using the Windows UNICODE version 
-   of the password. Each Windows UNICODE character is encoded in 
-   little-endian format of 2 octets each. Then performing an MD4 [6] 
-   hash operation on just the UNICODE characters of the password (not 
-   including the terminating zero octets). 
-    
-4. Basic Operations 
-    
-   The MD5 HMAC function is defined in [3]. It is used in this 
-   encryption type for checksum operations. Refer to [3] for details on 
-   its operation. In this document this function is referred to as 
-   HMAC(Key, Data) returning the checksum using the specified key on 
-   the data. 
-    
-   The basic MD5 hash operation is used in this encryption type and 
-   defined in [7]. In this document this function is referred to as 
-   MD5(Data) returning the checksum of the data. 
-    
-   The basic RC4 encryption operation is used in this encryption type 
-   and defined in [8]. In this document the function is referred to as 
-   RC4(Key, Data) returning the encrypted data using the specified key 
-   on the data. 
-    
-   These encryption types use key derivation as defined in [9] (RFC-
-   1510BIS) in Section titled "Key Derivation". With each message, the 
-   message type (T) is used as a component of the keying material. 
-    
-   All strings in this document are ASCII unless otherwise specified. 
-   The lengths of ASCII encoded character strings include the trailing 
-   terminator character (0). 
-    
-   The concat(a,b,c,...) function will return the logical concatenation 
-   (left to right) of the values of the arguments. 
-  
-Swift                  Category - Informational                      2 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
- 
- 
-    
-   The nonce(n) function returns a pseudo-random number of "n" octets. 
-    
-5. Checksum Types 
-    
-   There is one checksum type used in this encryption type. The 
-   Kerberos constant for this type is: 
-        #define KERB_CHECKSUM_HMAC_MD5 (-138) 
-    
-   The function is defined as follows: 
-    
-   K - is the Key 
-   T - the message type, encoded as a little-endian four byte integer 
-    
-   CHKSUM(K, T, data) 
-    
-        Ksign = HMAC(K, "signature key")  //includes zero octet at end 
-        tmp = MD5(concat(T, data)) 
-        CHKSUM = HMAC(Ksign, tmp) 
-    
-    
-6. Encryption Types 
-    
-   There are two encryption types used in these encryption types. The 
-   Kerberos constants for these types are: 
-        #define KERB_ETYPE_RC4_HMAC             23 
-        #define KERB_ETYPE_RC4_HMAC_EXP         24 
-    
-   The basic encryption function is defined as follow: 
-    
-   T = the message type, encoded as a little-endian four byte integer. 
-    
-   ENCRYPT(K, T, data) 
-        if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 
-                L = concat("fortybits", T) //includes zero octet at 
-                                           //end of string constant 
-        Else 
-                L = T 
-        Ksign = HMAC(K,L) 
-        Confounder = nonce(8) // get an 8 octet nonce for a confounder 
-        Checksum = HMAC(Ksign, concat(Confounder, data)) 
-        Ke = Ksign 
-        if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 
-                memset(&Ke[7], 0x0ab, 9) 
-        Ke2 = HMAC(Ke, Checksum) 
-        data = RC4(Ke2, data) 
-    
-   The header field on the encrypted data in KDC messages is: 
-    
-        typedef struct _RC4_MDx_HEADER { 
-            UCHAR Checksum[16]; 
-            UCHAR Confounder[8]; 
-        } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 
-  
-Swift                  Category - Informational                      3 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
- 
- 
-    
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States. 
-   It is now used to recognize that the key length is of "exportable" 
-   length. In this description, the key size is actually 56-bits. 
-    
-7. Key Strength Negotiation 
-    
-   A Kerberos client and server can negotiate over key length if they 
-   are using mutual authentication. If the client is unable to perform 
-   full strength encryption, it may propose a key in the "subkey" field 
-   of the authenticator, using a weaker encryption type. The server 
-   must then either return the same key or suggest its own key in the 
-   subkey field of the AP reply message. The key used to encrypt data 
-   is derived from the key returned by the server. If the client is 
-   able to perform strong encryption but the server is not, it may 
-   propose a subkey in the AP reply without first being sent a subkey 
-   in the authenticator. 
- 
-8. GSSAPI Kerberos V5 Mechanism Type  
- 
-8.1 Mechanism Specific Changes 
-    
-   The GSSAPI per-message tokens also require new checksum and 
-   encryption types. The GSS-API per-message tokens must be changed to 
-   support these new encryption types (See [5] Section 1.2.2). The 
-   sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption 
-   is: 
-        Byte 4..5 SEAL_ALG      0x10 0x00 - RC4 
-    
-   The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: 
-        Byte 2..3 SGN ALG       0x11 0x00 - HMAC 
-    
-   The only support quality of protection is: 
-        #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0 
-    
-   In addition, when using an RC4 based encryption type, the sequence 
-   number is sent in big-endian rather than little-endian order. 
-    
-8.2 GSSAPI Checksum Type 
-    
-   The GSSAPI checksum type and algorithm is defined in Section 5. Only 
-   the first 8 octets of the checksum are used. The resulting checksum 
-   is stored in the SGN_CKSUM field (See [5] Section 1.2) for 
-   GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). 
-    
-8.3 GSSAPI Encryption Types 
-    
-   There are two encryption types for GSSAPI message tokens, one that 
-   is 128 bits in strength, and one that is 56 bits in strength as 
-   defined in Section 6. 
-    
-
-  
-Swift                  Category - Informational                      4 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
- 
- 
-   All padding is rounded up to 1 byte. One byte is needed to say that 
-   there is 1 byte of padding. The DES based mechanism type uses 8 byte 
-   padding. See [5] Section 1.2.2.3. 
-    
-   The encryption mechanism used for GSS based messages is as follow: 
-    
-   T = the message type, encoded as a little-endian four byte integer. 
-    
-   GSS-ENCRYPT(K, T, data) 
-        IV = SND_SEQ 
-        K = XOR(K, 0xf0f0f0f0f0f0f0f0f0f0f0f0f0f0f0) 
-        if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 
-                L = concat("fortybits", T) //includes zero octet at end 
-        else 
-                L = T 
-        Ksign = HMAC(K, L) 
-        Ke = Ksign 
-        if (K.enctype == KERB_ETYPE_RC4_HMAC_EXP) 
-                memset(&Ke[7], 0x0ab, 9) 
-        Ke2 = HMAC(Ke, IV) 
-        Data = RC4(Ke2, data) 
-        SND_SEQ = RC4(Ke, seq#) 
-         
-   The sequence number (SND_SEQ) and IV are used as defined in [5] 
-   Section 1.2.2. 
-    
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States. 
-   It is now used to recognize that the key length is of "exportable" 
-   length. In this description, the key size is actually 56-bits. 
-    
-8. Security Considerations 
- 
-   Care must be taken in implementing this encryption type because it 
-   uses a stream cipher. If a different IV isnÆt used in each direction 
-   when using a session key, the encryption is weak. By using the 
-   sequence number as an IV, this is avoided. 
-    
-9. References 
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   3  Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for 
-      Message Authentication", RFC 2104, February 1997 
-    
-   4  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
-      Service (V5)", RFC 1510, September 1993 
- 
- 
-  
-Swift                  Category - Informational                      5 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
- 
- 
- 
-   5  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, 
-      June 1996 
- 
-   6  R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 
-      1992 
- 
-   7  R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April 
-      1992 
- 
-   8  RC4 is a proprietary encryption algorithm available under license 
-             from RSA Data Security Inc.  For licensing information, 
-      contact: 
-             RSA Data Security, Inc. 
-             100 Marine Parkway 
-             Redwood City, CA 94065-1031 
- 
-   9  Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 
-      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
-      04.txt, June 25, 1999 
- 
-    
-10. Author's Addresses 
-    
-   Mike Swift 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: mikesw@microsoft.com  
-    
-   John Brezak 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@microsoft.com 
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                      6 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
- 
- 
-    
-11. Full Copyright Statement 
- 
-   Copyright (C) The Internet Society (1999).  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this   
-   document itself may not be modified in any way, such as by removing   
-   the copyright notice or references to the Internet Society or other   
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                      7 
-
\ No newline at end of file
diff --git a/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt b/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt
deleted file mode 100644
index 1fc9927de..000000000
--- a/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-02.txt
+++ /dev/null
@@ -1,589 +0,0 @@
-
-
-CAT working group                                              M. Swift 
-Internet Draft                                                J. Brezak 
-Document: draft-brezak-win2k-krb-rc4-hmac-02.txt              Microsoft 
-Category: Informational                                   November 2000 
-
-
-           The Windows 2000 RC4-HMAC Kerberos encryption type 
-
-
-tatus of this Memo 
-
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1]. 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." 
-     
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-. Abstract 
-    
-   The Windows 2000 implementation of Kerberos introduces a new 
-   encryption type based on the RC4 encryption algorithm and using an 
-   MD5 HMAC for checksum. This is offered as an alternative to using 
-   the existing DES based encryption types. 
-    
-   The RC4-HMAC encryption types are used to ease upgrade of existing 
-   Windows NT environments, provide strong crypto (128-bit key 
-   lengths), and provide exportable (meet United States government 
-   export restriction requirements) encryption. 
-    
-   The Windows 2000 implementation of Kerberos contains new encryption 
-   and checksum types for two reasons: for export reasons early in the 
-   development process, 56 bit DES encryption could not be exported, 
-   and because upon upgrade from Windows NT 4.0 to Windows 2000, 
-   accounts will not have the appropriate DES keying material to do the 
-   standard DES encryption. Furthermore, 3DES is not available for 
-   export, and there was a desire to use a single flavor of encryption 
-   in the product for both US and international products. 
-    
-   As a result, there are two new encryption types and one new checksum 
-   type introduced in Windows 2000. 
-    
-    
-. Conventions used in this document 
-    
-
- 
-wift                  Category - Informational                      1 
-
-               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-    
-. Key Generation 
-    
-   On upgrade from existing Windows NT domains, the user accounts would 
-   not have a DES based key available to enable the use of DES base 
-   encryption types specified in RFC 1510. The key used for RC4-HMAC is 
-   the same as the existing Windows NT key (NT Password Hash) for 
-   compatibility reasons. Once the account password is changed, the DES 
-   based keys are created and maintained. Once the DES keys are 
-   available DES based encryption types can be used with Kerberos.  
-    
-   The RC4-HMAC String to key function is defined as follow: 
-    
-   String2Key(password) 
-    
-        K = MD4(UNICODE(password)) 
-         
-   The RC4-HMAC keys are generated by using the Windows UNICODE version 
-   of the password. Each Windows UNICODE character is encoded in 
-   little-endian format of 2 octets each. Then performing an MD4 [6] 
-   hash operation on just the UNICODE characters of the password (not 
-   including the terminating zero octets). 
-    
-   For an account with a password of "foo", this String2Key("foo") will 
-   return: 
-    
-        0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, 
-        0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc 
-    
-. Basic Operations 
-    
-   The MD5 HMAC function is defined in [3]. It is used in this 
-   encryption type for checksum operations. Refer to [3] for details on 
-   its operation. In this document this function is referred to as 
-   HMAC(Key, Data) returning the checksum using the specified key on 
-   the data. 
-    
-   The basic MD5 hash operation is used in this encryption type and 
-   defined in [7]. In this document this function is referred to as 
-   MD5(Data) returning the checksum of the data. 
-    
-   RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A       
-   compatible cipher is described in [8]. In this document the function 
-   is referred to as RC4(Key, Data) returning the encrypted data using 
-   the specified key on the data. 
-    
-   These encryption types use key derivation as defined in [9] (RFC-
-   1510BIS) in Section titled "Key Derivation". With each message, the 
-   message type (T) is used as a component of the keying material. This 
-   summarizes the different key derivation values used in the various 
- 
-wift                  Category - Informational                      2 
-
-               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
-
-
-   operations. Note that these differ from the key derivations used in 
-   other Kerberos encryption types. 
-    
-        T = 1 for TS-ENC-TS in the AS-Request 
-        T = 8 for the AS-Reply  
-        T = 7 for the Authenticator in the TGS-Request 
-        T = 8 for the TGS-Reply  
-        T = 2 for the Server Ticket in the AP-Request 
-        T = 11 for the Authenticator in the AP-Request 
-        T = 12 for the Server returned AP-Reply 
-        T = 15 in the generation of checksum for the MIC token 
-        T = 0 in the generation of sequence number for the MIC token  
-        T = 13 in the generation of checksum for the WRAP token 
-        T = 0 in the generation of sequence number for the WRAP token  
-        T = 0 in the generation of encrypted data for the WRAPPED token 
-    
-   All strings in this document are ASCII unless otherwise specified. 
-   The lengths of ASCII encoded character strings include the trailing 
-   terminator character (0). 
-    
-   The concat(a,b,c,...) function will return the logical concatenation 
-   (left to right) of the values of the arguments. 
-    
-   The nonce(n) function returns a pseudo-random number of "n" octets. 
-    
-. Checksum Types 
-    
-   There is one checksum type used in this encryption type. The 
-   Kerberos constant for this type is: 
-        #define KERB_CHECKSUM_HMAC_MD5 (-138) 
-    
-   The function is defined as follows: 
-    
-   K - is the Key 
-   T - the message type, encoded as a little-endian four byte integer 
-    
-   CHKSUM(K, T, data) 
-    
-        Ksign = HMAC(K, "signaturekey")  //includes zero octet at end 
-        tmp = MD5(concat(T, data)) 
-        CHKSUM = HMAC(Ksign, tmp) 
-    
-    
-. Encryption Types 
-    
-   There are two encryption types used in these encryption types. The 
-   Kerberos constants for these types are: 
-        #define KERB_ETYPE_RC4_HMAC             23 
-        #define KERB_ETYPE_RC4_HMAC_EXP         24 
-    
-   The basic encryption function is defined as follow: 
-    
-   T = the message type, encoded as a little-endian four byte integer. 
- 
-wift                  Category - Informational                      3 
-
-               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
-
-
-    
-        BYTE L40[14] = "fortybits"; 
-        BYTE SK = "signaturekey"; 
-         
-        ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len) 
-        { 
-            if (fRC4_EXP){ 
-                *((DWORD *)(L40+10)) = T; 
-                HMAC (K, L40, 10 + 4, K1); 
-            }else{ 
-                HMAC (K, &T, 4, K1); 
-            } 
-            memcpy (K2, K1, 16); 
-            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
-            add_8_random_bytes(data, data_len, conf_plus_data); 
-            HMAC (K2, conf_plus_data, 8 + data_len, checksum); 
-            HMAC (K1, checksum, 16, K3); 
-            RC4(K3, conf_plus_data, 8 + data_len, edata + 16); 
-            memcpy (edata, checksum, 16); 
-            edata_len = 16 + 8 + data_len; 
-        }         
-         
-        DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len) 
-        { 
-            if (fRC4_EXP){ 
-                *((DWORD *)(L40+10)) = T; 
-                HMAC (K, L40, 14, K1); 
-            }else{ 
-                HMAC (K, &T, 4, K1); 
-            } 
-            memcpy (K2, K1, 16); 
-            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
-            HMAC (K1, edata, 16, K3); // checksum is at edata 
-            RC4(K3, edata + 16, edata_len - 16, edata + 16); 
-            data_len = edata_len - 16 - 8; 
-            memcpy (data, edata + 16 + 8, data_len); 
-             
-            // verify generated and received checksums 
-            HMAC (K2, edata + 16, edata_len - 16, checksum); 
-            if (memcmp(edata, checksum, 16) != 0)  
-                printf("CHECKSUM ERROR  !!!!!!\n"); 
-        } 
-    
-   The header field on the encrypted data in KDC messages is: 
-    
-        typedef struct _RC4_MDx_HEADER { 
-            UCHAR Checksum[16]; 
-            UCHAR Confounder[8]; 
-        } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 
-         
-   The KDC message is encrypted using the ENCRYPT function not 
-   including the Checksum in the RC4_MDx_HEADER. 
-    
- 
-wift                  Category - Informational                      4 
-
-               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
-
-
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States. 
-   It is now used to recognize that the key length is of "exportable" 
-   length. In this description, the key size is actually 56-bits. 
-    
-. Key Strength Negotiation 
-    
-   A Kerberos client and server can negotiate over key length if they 
-   are using mutual authentication. If the client is unable to perform 
-   full strength encryption, it may propose a key in the "subkey" field 
-   of the authenticator, using a weaker encryption type. The server 
-   must then either return the same key or suggest its own key in the 
-   subkey field of the AP reply message. The key used to encrypt data 
-   is derived from the key returned by the server. If the client is 
-   able to perform strong encryption but the server is not, it may 
-   propose a subkey in the AP reply without first being sent a subkey 
-   in the authenticator. 
-
-. GSSAPI Kerberos V5 Mechanism Type  
-
-.1 Mechanism Specific Changes 
-    
-   The GSSAPI per-message tokens also require new checksum and 
-   encryption types. The GSS-API per-message tokens must be changed to 
-   support these new encryption types (See [5] Section 1.2.2). The 
-   sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption 
-   is: 
-        Byte 4..5 SEAL_ALG      0x10 0x00 - RC4 
-    
-   The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: 
-        Byte 2..3 SGN ALG       0x11 0x00 - HMAC 
-    
-   The only support quality of protection is: 
-        #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0 
-    
-   In addition, when using an RC4 based encryption type, the sequence 
-   number is sent in big-endian rather than little-endian order. 
-    
-   The Windows 2000 implementation also defines new GSSAPI flags in the 
-   initial token passed when initializing a security context. These 
-   flags are passed in the checksum field of the authenticator (See [5] 
-   Section 1.1.1). 
-    
-   GSS_C_DCE_STYLE - This flag was added for use with MicrosoftÆs 
-   implementation of DCE RPC, which initially expected three legs of 
-   authentication. Setting this flag causes an extra AP reply to be 
-   sent from the client back to the server after receiving the serverÆs 
-   AP reply. In addition, the context negotiation tokens do not have 
-   GSSAPI framing - they are raw AP message and do not include object 
-   identifiers. 
-        #define GSS_C_DCE_STYLE                 0x1000 
-    
-
- 
-wift                  Category - Informational                      5 
-
-               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
-
-
-   GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the 
-   server that it should only allow the server application to identify 
-   the client by name and ID, but not to impersonate the client. 
-        #define GSS_C_IDENTIFY_FLAG             0x2000 
-         
-   GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the 
-   client wants to be informed of extended error information. In 
-   particular, Windows 2000 status codes may be returned in the data 
-   field of a Kerberos error message. This allows the client to 
-   understand a server failure more precisely. In addition, the server 
-   may return errors to the client that are normally handled at the 
-   application layer in the server, in order to let the client try to 
-   recover. After receiving an error message, the client may attempt to 
-   resubmit an AP request. 
-        #define GSS_C_EXTENDED_ERROR_FLAG       0x4000 
-    
-   These flags are only used if a client is aware of these conventions 
-   when using the SSPI on the Windows platform, they are not generally 
-   used by default. 
-    
-   When NetBIOS addresses are used in the GSSAPI, they are identified 
-   by the GSS_C_AF_NETBIOS value. This value is defined as: 
-        #define GSS_C_AF_NETBIOS                0x14 
-   NetBios addresses are 16-octet addresses typically composed of 1 to                                                                  th   15 characters, trailing blank (ascii char 20) filled, with a 16  
-   octet of 0x0. 
-    
-.2 GSSAPI Checksum Type 
-    
-   The GSSAPI checksum type and algorithm is defined in Section 5. Only 
-   the first 8 octets of the checksum are used. The resulting checksum 
-   is stored in the SGN_CKSUM field (See [5] Section 1.2) for 
-   GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). 
-    
-        MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len, 
-             MIC_seq, MIC_checksum) 
-        { 
-            HMAC (K, SK, 13, K4); 
-            T = 15; 
-            memcpy (T_plus_hdr_plus_msg + 00, &T, 4); 
-            memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8);  
-                                                // 0101 1100 FFFFFFFF 
-            memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len); 
-            MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg); 
-            HMAC (K4, MD5_of_T_hdr_msg, CHKSUM); 
-            memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes 
-          
-            T = 0; 
-            if (fRC4_EXP){  
-                *((DWORD *)(L40+10)) = T; 
-                HMAC (K, L40, 14, K5); 
-            }else{ 
-                HMAC (K, &T, 4, K5); 
- 
-wift                  Category - Informational                      6 
-
-               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
-
-
-            } 
-            if (fRC4_EXP) memset(K5+7, 0xAB, 9); 
-            HMAC(K5, MIT_checksum, 8, K6); 
-            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
-        //0x12345678 
-            copy_direction_flag (direction_flag, seq_plus_direction + 
-        4); //0x12345678FFFFFFFF 
-            RC4(K6, seq_plus_direction, 8, MIC_seq); 
-        } 
-    
-.3 GSSAPI Encryption Types 
-    
-   There are two encryption types for GSSAPI message tokens, one that 
-   is 128 bits in strength, and one that is 56 bits in strength as 
-   defined in Section 6. 
-    
-   All padding is rounded up to 1 byte. One byte is needed to say that 
-   there is 1 byte of padding. The DES based mechanism type uses 8 byte 
-   padding. See [5] Section 1.2.2.3. 
-    
-   The encryption mechanism used for GSS wrap based messages is as 
-   follow: 
-    
-    
-        WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len, 
-              WRAP_seq, WRAP_checksum, edata, edata_len) 
-        { 
-            HMAC (K, SK, 13, K7); 
-            T = 13; 
-            PAD = 1; 
-            memcpy (T_hdr_conf_msg_pad + 00, &T, 4); 
-            memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100 
-        FFFFFFFF 
-            memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len); 
-            memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1); 
-            MD5 (T_hdr_conf_msg_pad, 
-                 4 + 8 + 8 + msg_len + 1, 
-                 MD5_of_T_hdr_conf_msg_pad); 
-            HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM); 
-            memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8 
-        bytes 
-          
-            T = 0; 
-            if (fRC4_EXP){  
-                *((DWORD *)(L40+10)) = T; 
-                HMAC (K, L40, 14, K8); 
-            }else{ 
-                HMAC (K, &T, 4, K8); 
-            } 
-            if (fRC4_EXP) memset(K8+7, 0xAB, 9); 
-            HMAC(K8, WRAP_checksum, 8, K9); 
-            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
-        //0x12345678 
- 
-wift                  Category - Informational                      7 
-
-               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
-
-
-            copy_direction_flag (direction_flag, seq_plus_direction + 
-        4); //0x12345678FFFFFFFF 
-            RC4(K9, seq_plus_direction, 8, WRAP_seq); 
-          
-            for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte 
-        of key with 0xF0 
-            T = 0; 
-            if (fRC4_EXP){ 
-                *(DWORD *)(L40+10) = T; 
-                HMAC(K10, L40, 14, K11); 
-                memset(K11+7, 0xAB, 9); 
-            }else{ 
-                HMAC(K10, &T, 4, K11);  
-            } 
-            HMAC(K11, seq_num, 4, K12); 
-            RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1, 
-        edata); /* skip T & hdr */ 
-            edata_len = 8 + msg_len + 1; // conf + msg_len + pad 
-         } 
-          
-    
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States. 
-   It is now used to recognize that the key length is of "exportable" 
-   length. In this description, the key size is actually 56-bits. 
-    
-. Security Considerations 
-
-   Care must be taken in implementing this encryption type because it 
-   uses a stream cipher. If a different IV isnÆt used in each direction 
-   when using a session key, the encryption is weak. By using the 
-   sequence number as an IV, this is avoided. 
-    
-0. Acknowledgements 
-    
-   We would like to thank Salil Dangi for the valuable input in 
-   refining the descriptions of the functions and review input. 
-     
-1. References 
-
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   3  Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for 
-      Message Authentication", RFC 2104, February 1997 
-    
-   4  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
-      Service (V5)", RFC 1510, September 1993 
-
-
- 
-wift                  Category - Informational                      8 
-
-               Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
-
-
-
-   5  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, 
-      June 1996 
-
-   6  R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 
-      1992 
-
-   7  R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April 
-      1992 
-
-   8  Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption             
-      Algorithm", Work in Progress. 
-
-   9  RC4 is a proprietary encryption algorithm available under license 
-      from RSA Data Security Inc.  For licensing information, contact: 
-       
-         RSA Data Security, Inc. 
-         100 Marine Parkway 
-         Redwood City, CA 94065-1031 
-
-   10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 
-      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
-      04.txt, June 25, 1999 
-
-    
-2. Author's Addresses 
-    
-   Mike Swift 
-   Dept. of Computer Science 
-   Sieg Hall 
-   University of Washington 
-   Seattle, WA 98105 
-   Email: mikesw@cs.washington.edu  
-    
-   John Brezak 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@microsoft.com 
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
- 
-wift                  Category - Informational                      9 
-
-               Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
-
-
-    
-3. Full Copyright Statement 
-
-   "Copyright (C) The Internet Society (2000). All Rights Reserved. 
-    
-   This document and translations of it may be copied and          
-   furnished to others, and derivative works that comment on or          
-   otherwise explain it or assist in its implementation may be          
-   prepared, copied, published and distributed, in whole or in          
-   part, without restriction of any kind, provided that the above          
-   copyright notice and this paragraph are included on all such          
-   copies and derivative works.  However, this document itself may          
-   not be modified in any way, such as by removing the copyright          
-   notice or references to the Internet Society or other Internet          
-   organizations, except as needed for the purpose of developing          
-   Internet standards in which case the procedures for copyrights          
-   defined in the Internet Standards process must be followed, or          
-   as required to translate it into languages other than English. 
-    
-   The limited permissions granted above are perpetual and will          
-   not be revoked by the Internet Society or its successors or          
-   assigns. 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
-wift                  Category - Informational                     10 
-
diff --git a/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt b/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt
deleted file mode 100644
index 9ebe39e0a..000000000
--- a/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-03.txt
+++ /dev/null
@@ -1,589 +0,0 @@
-CAT working group                                              M. Swift 
-Internet Draft                                                J. Brezak 
-Document: draft-brezak-win2k-krb-rc4-hmac-03.txt              Microsoft 
-Category: Informational                                       June 2000 
- 
- 
-           The Windows 2000 RC4-HMAC Kerberos encryption type 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1]. 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." 
-     
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   The Windows 2000 implementation of Kerberos introduces a new 
-   encryption type based on the RC4 encryption algorithm and using an 
-   MD5 HMAC for checksum. This is offered as an alternative to using 
-   the existing DES based encryption types. 
-    
-   The RC4-HMAC encryption types are used to ease upgrade of existing 
-   Windows NT environments, provide strong crypto (128-bit key 
-   lengths), and provide exportable (meet United States government 
-   export restriction requirements) encryption. 
-    
-   The Windows 2000 implementation of Kerberos contains new encryption 
-   and checksum types for two reasons: for export reasons early in the 
-   development process, 56 bit DES encryption could not be exported, 
-   and because upon upgrade from Windows NT 4.0 to Windows 2000, 
-   accounts will not have the appropriate DES keying material to do the 
-   standard DES encryption. Furthermore, 3DES is not available for 
-   export, and there was a desire to use a single flavor of encryption 
-   in the product for both US and international products. 
-    
-   As a result, there are two new encryption types and one new checksum 
-   type introduced in Windows 2000. 
-    
-    
-2. Conventions used in this document 
-    
-
-  
-Swift                  Category - Informational                      1 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-    
-3. Key Generation 
-    
-   On upgrade from existing Windows NT domains, the user accounts would 
-   not have a DES based key available to enable the use of DES base 
-   encryption types specified in RFC 1510. The key used for RC4-HMAC is 
-   the same as the existing Windows NT key (NT Password Hash) for 
-   compatibility reasons. Once the account password is changed, the DES 
-   based keys are created and maintained. Once the DES keys are 
-   available DES based encryption types can be used with Kerberos.  
-    
-   The RC4-HMAC String to key function is defined as follow: 
-    
-   String2Key(password) 
-    
-        K = MD4(UNICODE(password)) 
-         
-   The RC4-HMAC keys are generated by using the Windows UNICODE version 
-   of the password. Each Windows UNICODE character is encoded in 
-   little-endian format of 2 octets each. Then performing an MD4 [6] 
-   hash operation on just the UNICODE characters of the password (not 
-   including the terminating zero octets). 
-    
-   For an account with a password of "foo", this String2Key("foo") will 
-   return: 
-    
-        0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, 
-        0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc 
-    
-4. Basic Operations 
-    
-   The MD5 HMAC function is defined in [3]. It is used in this 
-   encryption type for checksum operations. Refer to [3] for details on 
-   its operation. In this document this function is referred to as 
-   HMAC(Key, Data) returning the checksum using the specified key on 
-   the data. 
-    
-   The basic MD5 hash operation is used in this encryption type and 
-   defined in [7]. In this document this function is referred to as 
-   MD5(Data) returning the checksum of the data. 
-    
-   RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A       
-   compatible cipher is described in [8]. In this document the function 
-   is referred to as RC4(Key, Data) returning the encrypted data using 
-   the specified key on the data. 
-    
-   These encryption types use key derivation as defined in [9] (RFC-
-   1510BIS) in Section titled "Key Derivation". With each message, the 
-   message type (T) is used as a component of the keying material. This 
-   summarizes the different key derivation values used in the various 
-  
-Swift                  Category - Informational                      2 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
-   operations. Note that these differ from the key derivations used in 
-   other Kerberos encryption types. 
-    
-        T = 1 for TS-ENC-TS in the AS-Request 
-        T = 8 for the AS-Reply  
-        T = 7 for the Authenticator in the TGS-Request 
-        T = 8 for the TGS-Reply  
-        T = 2 for the Server Ticket in the AP-Request 
-        T = 11 for the Authenticator in the AP-Request 
-        T = 12 for the Server returned AP-Reply 
-        T = 15 in the generation of checksum for the MIC token 
-        T = 0 in the generation of sequence number for the MIC token  
-        T = 13 in the generation of checksum for the WRAP token 
-        T = 0 in the generation of sequence number for the WRAP token  
-        T = 0 in the generation of encrypted data for the WRAPPED token 
-    
-   All strings in this document are ASCII unless otherwise specified. 
-   The lengths of ASCII encoded character strings include the trailing 
-   terminator character (0). 
-    
-   The concat(a,b,c,...) function will return the logical concatenation 
-   (left to right) of the values of the arguments. 
-    
-   The nonce(n) function returns a pseudo-random number of "n" octets. 
-    
-5. Checksum Types 
-    
-   There is one checksum type used in this encryption type. The 
-   Kerberos constant for this type is: 
-        #define KERB_CHECKSUM_HMAC_MD5 (-138) 
-    
-   The function is defined as follows: 
-    
-   K - is the Key 
-   T - the message type, encoded as a little-endian four byte integer 
-    
-   CHKSUM(K, T, data) 
-    
-        Ksign = HMAC(K, "signaturekey")  //includes zero octet at end 
-        tmp = MD5(concat(T, data)) 
-        CHKSUM = HMAC(Ksign, tmp) 
-    
-    
-6. Encryption Types 
-    
-   There are two encryption types used in these encryption types. The 
-   Kerberos constants for these types are: 
-        #define KERB_ETYPE_RC4_HMAC             23 
-        #define KERB_ETYPE_RC4_HMAC_EXP         24 
-    
-   The basic encryption function is defined as follow: 
-    
-   T = the message type, encoded as a little-endian four byte integer. 
-  
-Swift                  Category - Informational                      3 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
-    
-        BYTE L40[14] = "fortybits"; 
-        BYTE SK = "signaturekey"; 
-         
-        ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len) 
-        { 
-            if (fRC4_EXP){ 
-                *((DWORD *)(L40+10)) = T; 
-                HMAC (K, L40, 10 + 4, K1); 
-            }else{ 
-                HMAC (K, &T, 4, K1); 
-            } 
-            memcpy (K2, K1, 16); 
-            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
-            add_8_random_bytes(data, data_len, conf_plus_data); 
-            HMAC (K2, conf_plus_data, 8 + data_len, checksum); 
-            HMAC (K1, checksum, 16, K3); 
-            RC4(K3, conf_plus_data, 8 + data_len, edata + 16); 
-            memcpy (edata, checksum, 16); 
-            edata_len = 16 + 8 + data_len; 
-        }         
-         
-        DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len) 
-        { 
-            if (fRC4_EXP){ 
-                *((DWORD *)(L40+10)) = T; 
-                HMAC (K, L40, 14, K1); 
-            }else{ 
-                HMAC (K, &T, 4, K1); 
-            } 
-            memcpy (K2, K1, 16); 
-            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
-            HMAC (K1, edata, 16, K3); // checksum is at edata 
-            RC4(K3, edata + 16, edata_len - 16, edata + 16); 
-            data_len = edata_len - 16 - 8; 
-            memcpy (data, edata + 16 + 8, data_len); 
-             
-            // verify generated and received checksums 
-            HMAC (K2, edata + 16, edata_len - 16, checksum); 
-            if (memcmp(edata, checksum, 16) != 0)  
-                printf("CHECKSUM ERROR  !!!!!!\n"); 
-        } 
-    
-   The header field on the encrypted data in KDC messages is: 
-    
-        typedef struct _RC4_MDx_HEADER { 
-            UCHAR Checksum[16]; 
-            UCHAR Confounder[8]; 
-        } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 
-         
-   The KDC message is encrypted using the ENCRYPT function not 
-   including the Checksum in the RC4_MDx_HEADER. 
-    
-  
-Swift                  Category - Informational                      4 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States. 
-   It is now used to recognize that the key length is of "exportable" 
-   length. In this description, the key size is actually 56-bits. 
-    
-7. Key Strength Negotiation 
-    
-   A Kerberos client and server can negotiate over key length if they 
-   are using mutual authentication. If the client is unable to perform 
-   full strength encryption, it may propose a key in the "subkey" field 
-   of the authenticator, using a weaker encryption type. The server 
-   must then either return the same key or suggest its own key in the 
-   subkey field of the AP reply message. The key used to encrypt data 
-   is derived from the key returned by the server. If the client is 
-   able to perform strong encryption but the server is not, it may 
-   propose a subkey in the AP reply without first being sent a subkey 
-   in the authenticator. 
- 
-8. GSSAPI Kerberos V5 Mechanism Type  
- 
-8.1 Mechanism Specific Changes 
-    
-   The GSSAPI per-message tokens also require new checksum and 
-   encryption types. The GSS-API per-message tokens must be changed to 
-   support these new encryption types (See [5] Section 1.2.2). The 
-   sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption 
-   is: 
-        Byte 4..5 SEAL_ALG      0x10 0x00 - RC4 
-    
-   The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: 
-        Byte 2..3 SGN ALG       0x11 0x00 - HMAC 
-    
-   The only support quality of protection is: 
-        #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0 
-    
-   In addition, when using an RC4 based encryption type, the sequence 
-   number is sent in big-endian rather than little-endian order. 
-    
-   The Windows 2000 implementation also defines new GSSAPI flags in the 
-   initial token passed when initializing a security context. These 
-   flags are passed in the checksum field of the authenticator (See [5] 
-   Section 1.1.1). 
-    
-   GSS_C_DCE_STYLE - This flag was added for use with Microsoft’s 
-   implementation of DCE RPC, which initially expected three legs of 
-   authentication. Setting this flag causes an extra AP reply to be 
-   sent from the client back to the server after receiving the server’s 
-   AP reply. In addition, the context negotiation tokens do not have 
-   GSSAPI framing - they are raw AP message and do not include object 
-   identifiers. 
-        #define GSS_C_DCE_STYLE                 0x1000 
-    
-
-  
-Swift                  Category - Informational                      5 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
-   GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the 
-   server that it should only allow the server application to identify 
-   the client by name and ID, but not to impersonate the client. 
-        #define GSS_C_IDENTIFY_FLAG             0x2000 
-         
-   GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the 
-   client wants to be informed of extended error information. In 
-   particular, Windows 2000 status codes may be returned in the data 
-   field of a Kerberos error message. This allows the client to 
-   understand a server failure more precisely. In addition, the server 
-   may return errors to the client that are normally handled at the 
-   application layer in the server, in order to let the client try to 
-   recover. After receiving an error message, the client may attempt to 
-   resubmit an AP request. 
-        #define GSS_C_EXTENDED_ERROR_FLAG       0x4000 
-    
-   These flags are only used if a client is aware of these conventions 
-   when using the SSPI on the Windows platform, they are not generally 
-   used by default. 
-    
-   When NetBIOS addresses are used in the GSSAPI, they are identified 
-   by the GSS_C_AF_NETBIOS value. This value is defined as: 
-        #define GSS_C_AF_NETBIOS                0x14 
-   NetBios addresses are 16-octet addresses typically composed of 1 to 
-                                                                 th
-   15 characters, trailing blank (ascii char 20) filled, with a 16  
-   octet of 0x0. 
-    
-8.2 GSSAPI Checksum Type 
-    
-   The GSSAPI checksum type and algorithm is defined in Section 5. Only 
-   the first 8 octets of the checksum are used. The resulting checksum 
-   is stored in the SGN_CKSUM field (See [5] Section 1.2) for 
-   GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). 
-    
-        MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len, 
-             MIC_seq, MIC_checksum) 
-        { 
-            HMAC (K, SK, 13, K4); 
-            T = 15; 
-            memcpy (T_plus_hdr_plus_msg + 00, &T, 4); 
-            memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8);  
-                                                // 0101 1100 FFFFFFFF 
-            memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len); 
-            MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg); 
-            HMAC (K4, MD5_of_T_hdr_msg, CHKSUM); 
-            memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes 
-          
-            T = 0; 
-            if (fRC4_EXP){  
-                *((DWORD *)(L40+10)) = T; 
-                HMAC (K, L40, 14, K5); 
-            }else{ 
-                HMAC (K, &T, 4, K5); 
-  
-Swift                  Category - Informational                      6 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
-            } 
-            if (fRC4_EXP) memset(K5+7, 0xAB, 9); 
-            HMAC(K5, MIT_checksum, 8, K6); 
-            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
-        //0x12345678 
-            copy_direction_flag (direction_flag, seq_plus_direction + 
-        4); //0x12345678FFFFFFFF 
-            RC4(K6, seq_plus_direction, 8, MIC_seq); 
-        } 
-    
-8.3 GSSAPI Encryption Types 
-    
-   There are two encryption types for GSSAPI message tokens, one that 
-   is 128 bits in strength, and one that is 56 bits in strength as 
-   defined in Section 6. 
-    
-   All padding is rounded up to 1 byte. One byte is needed to say that 
-   there is 1 byte of padding. The DES based mechanism type uses 8 byte 
-   padding. See [5] Section 1.2.2.3. 
-    
-   The encryption mechanism used for GSS wrap based messages is as 
-   follow: 
-    
-    
-        WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len, 
-              WRAP_seq, WRAP_checksum, edata, edata_len) 
-        { 
-            HMAC (K, SK, 13, K7); 
-            T = 13; 
-            PAD = 1; 
-            memcpy (T_hdr_conf_msg_pad + 00, &T, 4); 
-            memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100 
-        FFFFFFFF 
-            memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len); 
-            memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1); 
-            MD5 (T_hdr_conf_msg_pad, 
-                 4 + 8 + 8 + msg_len + 1, 
-                 MD5_of_T_hdr_conf_msg_pad); 
-            HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM); 
-            memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8 
-        bytes 
-          
-            T = 0; 
-            if (fRC4_EXP){  
-                *((DWORD *)(L40+10)) = T; 
-                HMAC (K, L40, 14, K8); 
-            }else{ 
-                HMAC (K, &T, 4, K8); 
-            } 
-            if (fRC4_EXP) memset(K8+7, 0xAB, 9); 
-            HMAC(K8, WRAP_checksum, 8, K9); 
-            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
-        //0x12345678 
-  
-Swift                  Category - Informational                      7 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
-            copy_direction_flag (direction_flag, seq_plus_direction + 
-        4); //0x12345678FFFFFFFF 
-            RC4(K9, seq_plus_direction, 8, WRAP_seq); 
-          
-            for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte 
-        of key with 0xF0 
-            T = 0; 
-            if (fRC4_EXP){ 
-                *(DWORD *)(L40+10) = T; 
-                HMAC(K10, L40, 14, K11); 
-                memset(K11+7, 0xAB, 9); 
-            }else{ 
-                HMAC(K10, &T, 4, K11);  
-            } 
-            HMAC(K11, seq_num, 4, K12); 
-            RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1, 
-        edata); /* skip T & hdr */ 
-            edata_len = 8 + msg_len + 1; // conf + msg_len + pad 
-         } 
-          
-    
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States. 
-   It is now used to recognize that the key length is of "exportable" 
-   length. In this description, the key size is actually 56-bits. 
-    
-9. Security Considerations 
- 
-   Care must be taken in implementing this encryption type because it 
-   uses a stream cipher. If a different IV isn’t used in each direction 
-   when using a session key, the encryption is weak. By using the 
-   sequence number as an IV, this is avoided. 
-    
-10. Acknowledgements 
-    
-   We would like to thank Salil Dangi for the valuable input in 
-   refining the descriptions of the functions and review input. 
-     
-11. References 
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   3  Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for 
-      Message Authentication", RFC 2104, February 1997 
-    
-   4  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
-      Service (V5)", RFC 1510, September 1993 
- 
- 
-  
-Swift                  Category - Informational                      8 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
- 
-   5  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, 
-      June 1996 
- 
-   6  R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 
-      1992 
- 
-   7  R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April 
-      1992 
- 
-   8  Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption             
-      Algorithm", Work in Progress. 
- 
-   9  RC4 is a proprietary encryption algorithm available under license 
-      from RSA Data Security Inc.  For licensing information, contact: 
-       
-         RSA Data Security, Inc. 
-         100 Marine Parkway 
-         Redwood City, CA 94065-1031 
- 
-   10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 
-      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
-      04.txt, June 25, 1999 
- 
-    
-12. Author's Addresses 
-    
-   Mike Swift 
-   Dept. of Computer Science 
-   Sieg Hall 
-   University of Washington 
-   Seattle, WA 98105 
-   Email: mikesw@cs.washington.edu  
-    
-   John Brezak 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@microsoft.com 
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                      9 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
- 
- 
-    
-13. Full Copyright Statement 
- 
-   "Copyright (C) The Internet Society (2000). All Rights Reserved. 
-    
-   This document and translations of it may be copied and          
-   furnished to others, and derivative works that comment on or          
-   otherwise explain it or assist in its implementation may be          
-   prepared, copied, published and distributed, in whole or in          
-   part, without restriction of any kind, provided that the above          
-   copyright notice and this paragraph are included on all such          
-   copies and derivative works.  However, this document itself may          
-   not be modified in any way, such as by removing the copyright          
-   notice or references to the Internet Society or other Internet          
-   organizations, except as needed for the purpose of developing          
-   Internet standards in which case the procedures for copyrights          
-   defined in the Internet Standards process must be followed, or          
-   as required to translate it into languages other than English. 
-    
-   The limited permissions granted above are perpetual and will          
-   not be revoked by the Internet Society or its successors or          
-   assigns. 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                     10 
-
diff --git a/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-04.txt b/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-04.txt
deleted file mode 100644
index 9887873ef..000000000
--- a/doc/standardisation/draft-brezak-win2k-krb-rc4-hmac-04.txt
+++ /dev/null
@@ -1,923 +0,0 @@
-
-
-Kerberos working group                                         M. Swift 
-                                                           U.Washington 
-Internet Draft                                                J. Brezak 
-Document: draft-brezak-win2k-krb-rc4-hmac-04.txt              Microsoft 
-Category: Informational                                        May 2002 
- 
- 
-      The Microsoft Windows 2000 RC4-HMAC Kerberos encryption type 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1]. 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." 
-     
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-    
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   The Microsoft Windows 2000 implementation of Kerberos introduces a 
-   new encryption type based on the RC4 encryption algorithm and using 
-   an MD5 HMAC for checksum. This is offered as an alternative to using 
-   the existing DES based encryption types. 
-    
-   The RC4-HMAC encryption types are used to ease upgrade of existing 
-   Windows NT environments, provide strong crypto (128-bit key 
-   lengths), and provide exportable (meet United States government 
-   export restriction requirements) encryption. 
-    
-   The Microsoft Windows 2000 implementation of Kerberos contains new 
-   encryption and checksum types for two reasons: for export reasons 
-   early in the development process, 56 bit DES encryption could not be 
-   exported, and because upon upgrade from Windows NT 4.0 to Windows 
-   2000, accounts will not have the appropriate DES keying material to 
-   do the standard DES encryption. Furthermore, 3DES is not available 
-   for export, and there was a desire to use a single flavor of 
-   encryption in the product for both US and international products. 
-    
-   As a result, there are two new encryption types and one new checksum 
-   type introduced in Microsoft Windows 2000. 
-    
-    
-2. Conventions used in this document 
-  
-Swift                  Category - Informational                      1 
-
-
-
-
-
-
-
-
-                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
- 
- 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-    
-3. Key Generation 
-    
-   On upgrade from existing Windows NT domains, the user accounts would 
-   not have a DES based key available to enable the use of DES base 
-   encryption types specified in RFC 1510. The key used for RC4-HMAC is 
-   the same as the existing Windows NT key (NT Password Hash) for 
-   compatibility reasons. Once the account password is changed, the DES 
-   based keys are created and maintained. Once the DES keys are 
-   available DES based encryption types can be used with Kerberos.  
-    
-   The RC4-HMAC String to key function is defined as follow: 
-    
-   String2Key(password) 
-    
-        K = MD4(UNICODE(password)) 
-         
-   The RC4-HMAC keys are generated by using the Windows UNICODE version 
-   of the password. Each Windows UNICODE character is encoded in 
-   little-endian format of 2 octets each. Then performing an MD4 [6] 
-   hash operation on just the UNICODE characters of the password (not 
-   including the terminating zero octets). 
-    
-   For an account with a password of "foo", this String2Key("foo") will 
-   return: 
-    
-        0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, 
-        0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc 
-    
-4. Basic Operations 
-    
-   The MD5 HMAC function is defined in [3]. It is used in this 
-   encryption type for checksum operations. Refer to [3] for details on 
-   its operation. In this document this function is referred to as 
-   HMAC(Key, Data) returning the checksum using the specified key on 
-   the data. 
-    
-   The basic MD5 hash operation is used in this encryption type and 
-   defined in [7]. In this document this function is referred to as 
-   MD5(Data) returning the checksum of the data. 
-    
-   RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A       
-   compatible cipher is described in [8]. In this document the function 
-   is referred to as RC4(Key, Data) returning the encrypted data using 
-   the specified key on the data. 
-    
-   These encryption types use key derivation. With each message, the 
-   message type (T) is used as a component of the keying material. This 
-   table summarizes the different key derivation values used in the 
-  
-Swift                  Category - Informational                      2 
-
-
-
-
-
-
-
-
-                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
- 
- 
-   various operations. Note that these differ from the key derivations 
-   used in other Kerberos encryption types. T = the message type, 
-   encoded as a little-endian four byte integer. 
-    
-    
-        1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with 
-        the client key (T=1) 
-        2.  AS-REP Ticket and TGS-REP Ticket (includes TGS session key 
-        or application session key), encrypted with the service key 
-        (T=2) 
-        3.  AS-REP encrypted part (includes TGS session key or 
-        application session key), encrypted with the client key (T=8) 
-        4.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the 
-        TGS session key (T=4) 
-        5.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the 
-        TGS authenticator subkey (T=5) 
-        6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed 
-        with the TGS session key (T=6) 
-        7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes 
-        TGS authenticator subkey), encrypted with the TGS session key 
-        (T=7) 
-        8.  TGS-REP encrypted part (includes application session key), 
-        encrypted with the TGS session key (T=8) 
-        9.  TGS-REP encrypted part (includes application session key), 
-        encrypted with the TGS authenticator subkey (T=8) 
-        10.  AP-REQ Authenticator cksum, keyed with the application 
-        session key (T=10) 
-        11.  AP-REQ Authenticator (includes application authenticator 
-        subkey), encrypted with the application session key (T=11) 
-        12.  AP-REP encrypted part (includes application session 
-        subkey), encrypted with the application session key (T=12) 
-        13.  KRB-PRIV encrypted part, encrypted with a key chosen by 
-        the application. Also for data encrypted with GSS Wrap (T=13) 
-        14.  KRB-CRED encrypted part, encrypted with a key chosen by 
-        the application (T=14) 
-        15.  KRB-SAFE cksum, keyed with a key chosen by the 
-        application. Also for data signed in GSS MIC (T=15) 
-    
-        Relative to RFC-1964 key uses: 
-         
-        T = 0 in the generation of sequence number for the MIC token  
-        T = 0 in the generation of sequence number for the WRAP token  
-        T = 0 in the generation of encrypted data for the WRAPPED token 
-    
-   All strings in this document are ASCII unless otherwise specified. 
-   The lengths of ASCII encoded character strings include the trailing 
-   terminator character (0). 
-    
-   The concat(a,b,c,...) function will return the logical concatenation 
-   (left to right) of the values of the arguments. 
-    
-   The nonce(n) function returns a pseudo-random number of "n" octets. 
-    
-  
-Swift                  Category - Informational                      3 
-
-
-
-
-
-
-
-
-                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
- 
- 
-5. Checksum Types 
-    
-   There is one checksum type used in this encryption type. The 
-   Kerberos constant for this type is: 
-        #define KERB_CHECKSUM_HMAC_MD5 (-138) 
-    
-   The function is defined as follows: 
-    
-   K - is the Key 
-   T - the message type, encoded as a little-endian four byte integer 
-    
-   CHKSUM(K, T, data) 
-    
-        Ksign = HMAC(K, "signaturekey")  //includes zero octet at end 
-        tmp = MD5(concat(T, data)) 
-        CHKSUM = HMAC(Ksign, tmp) 
-    
-    
-6. Encryption Types 
-    
-   There are two encryption types used in these encryption types. The 
-   Kerberos constants for these types are: 
-        #define KERB_ETYPE_RC4_HMAC             23 
-        #define KERB_ETYPE_RC4_HMAC_EXP         24 
-    
-   The basic encryption function is defined as follow: 
-    
-   T = the message type, encoded as a little-endian four byte integer. 
-    
-        OCTET L40[14] = "fortybits"; 
-        OCTET SK = "signaturekey"; 
-         
-   The header field on the encrypted data in KDC messages is: 
-    
-        typedef struct _RC4_MDx_HEADER { 
-            OCTET Checksum[16]; 
-            OCTET Confounder[8]; 
-        } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 
-         
-         
-        ENCRYPT (K, export, T, data) 
-        { 
-            struct EDATA { 
-                struct HEADER { 
-                        OCTET Checksum[16]; 
-                        OCTET Confounder[8]; 
-                } Header; 
-                OCTET Data[0]; 
-            } edata; 
-         
-            if (export){ 
-                *((DWORD *)(L40+10)) = T; 
-                HMAC (K, L40, 10 + 4, K1); 
-  
-Swift                  Category - Informational                      4 
-
-
-
-
-
-
-
-
-                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
- 
- 
-            } 
-            else 
-            { 
-                HMAC (K, &T, 4, K1); 
-            } 
-            memcpy (K2, K1, 16); 
-            if (export) memset (K1+7, 0xAB, 9); 
-         
-            nonce (edata.Confounder, 8); 
-            memcpy (edata.Data, data); 
-         
-            edata.Checksum = HMAC (K2, edata); 
-            K3 = HMAC (K1, edata.Checksum); 
-         
-            RC4 (K3, edata.Confounder); 
-            RC4 (K3, data.Data); 
-        }         
-         
-        DECRYPT (K, export, T, edata) 
-        { 
-            // edata looks like 
-            struct EDATA { 
-                struct HEADER { 
-                        OCTET Checksum[16]; 
-                        OCTET Confounder[8]; 
-                } Header; 
-                OCTET Data[0]; 
-            } edata; 
-         
-            if (export){ 
-                *((DWORD *)(L40+10)) = T; 
-                HMAC (K, L40, 14, K1); 
-            } 
-            else 
-            { 
-                HMAC (K, &T, 4, K1); 
-            } 
-            memcpy (K2, K1, 16); 
-            if (export) memset (K1+7, 0xAB, 9); 
-         
-            K3 = HMAC (K1, edata.Checksum); 
-         
-            RC4 (K3, edata.Confounder); 
-            RC4 (K3, edata.Data); 
-         
-                
-            // verify generated and received checksums 
-            checksum = HMAC (K2, concat(edata.Confounder, edata.Data)); 
-            if (checksum != edata.Checksum)  
-                printf("CHECKSUM ERROR  !!!!!!\n"); 
-        } 
-    
-
-  
-Swift                  Category - Informational                      5 
-
-
-
-
-
-
-
-
-                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
- 
- 
-   The KDC message is encrypted using the ENCRYPT function not 
-   including the Checksum in the RC4_MDx_HEADER. 
-    
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States. 
-   It is now used to recognize that the key length is of "exportable" 
-   length. In this description, the key size is actually 56-bits. 
-    
-7. Key Strength Negotiation 
-    
-   A Kerberos client and server can negotiate over key length if they 
-   are using mutual authentication. If the client is unable to perform 
-   full strength encryption, it may propose a key in the "subkey" field 
-   of the authenticator, using a weaker encryption type. The server 
-   must then either return the same key or suggest its own key in the 
-   subkey field of the AP reply message. The key used to encrypt data 
-   is derived from the key returned by the server. If the client is 
-   able to perform strong encryption but the server is not, it may 
-   propose a subkey in the AP reply without first being sent a subkey 
-   in the authenticator. 
- 
-8. GSSAPI Kerberos V5 Mechanism Type  
- 
-8.1 Mechanism Specific Changes 
-    
-   The GSSAPI per-message tokens also require new checksum and 
-   encryption types. The GSS-API per-message tokens are adapted to 
-   support these new encryption types (See [5] Section 1.2.2). 
-    
-   The only support quality of protection is: 
-        #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0 
-    
-   When using this RC4 based encryption type, the sequence number is 
-   always sent in big-endian rather than little-endian order. 
-    
-   The Windows 2000 implementation also defines new GSSAPI flags in the 
-   initial token passed when initializing a security context. These 
-   flags are passed in the checksum field of the authenticator (See [5] 
-   Section 1.1.1). 
-    
-   GSS_C_DCE_STYLE - This flag was added for use with Microsoft's 
-   implementation of DCE RPC, which initially expected three legs of 
-   authentication. Setting this flag causes an extra AP reply to be 
-   sent from the client back to the server after receiving the serverÆs 
-   AP reply. In addition, the context negotiation tokens do not have 
-   GSSAPI per message tokens - they are raw AP messages that do not 
-   include object identifiers. 
-        #define GSS_C_DCE_STYLE                 0x1000 
-    
-   GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the 
-   server that it should only allow the server application to identify 
-   the client by name and ID, but not to impersonate the client. 
-        #define GSS_C_IDENTIFY_FLAG             0x2000 
-  
-Swift                  Category - Informational                      6 
-
-
-
-
-
-
-
-
-                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
- 
- 
-         
-   GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the 
-   client wants to be informed of extended error information. In 
-   particular, Windows 2000 status codes may be returned in the data 
-   field of a Kerberos error message. This allows the client to 
-   understand a server failure more precisely. In addition, the server 
-   may return errors to the client that are normally handled at the 
-   application layer in the server, in order to let the client try to 
-   recover. After receiving an error message, the client may attempt to 
-   resubmit an AP request. 
-        #define GSS_C_EXTENDED_ERROR_FLAG       0x4000 
-    
-   These flags are only used if a client is aware of these conventions 
-   when using the SSPI on the Windows platform; they are not generally 
-   used by default. 
-    
-   When NetBIOS addresses are used in the GSSAPI, they are identified 
-   by the GSS_C_AF_NETBIOS value. This value is defined as: 
-        #define GSS_C_AF_NETBIOS                0x14 
-   NetBios addresses are 16-octet addresses typically composed of 1 to 
-   15 characters, trailing blank (ASCII char 20) filled, with a 16-th 
-   octet of 0x0. 
-    
-8.2 GSSAPI MIC Semantics 
-    
-   The GSSAPI checksum type and algorithm is defined in Section 5. Only 
-   the first 8 octets of the checksum are used. The resulting checksum 
-   is stored in the SGN_CKSUM field (See [5] Section 1.2) for 
-   GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). 
-    
-   The GSS_GetMIC token has the following format: 
-    
-      Byte no         Name       Description 
-       0..1           TOK_ID     Identification field. 
-                                 Tokens emitted by GSS_GetMIC() contain 
-                                 the hex value 01 01 in this field. 
-       2..3           SGN_ALG    Integrity algorithm indicator. 
-                                 11 00 - HMAC 
-       4..7           Filler     Contains ff ff ff ff 
-       8..15          SND_SEQ    Sequence number field. 
-       16..23         SGN_CKSUM  Checksum of "to-be-signed data", 
-                                 calculated according to algorithm 
-                                 specified in SGN_ALG field. 
-    
-   The MIC mechanism used for GSS MIC based messages is as follow: 
-    
-        GetMIC(Kss, direction, export, seq_num, data) 
-        { 
-                struct Token { 
-                       struct Header { 
-                              OCTET TOK_ID[2]; 
-                              OCTET SGN_ALG[2]; 
-                              OCTET Filler[4]; 
-  
-Swift                  Category - Informational                      7 
-
-
-
-
-
-
-
-
-                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
- 
- 
-                       }; 
-                       OCTET SND_SEQ[8]; 
-                       OCTET SGN_CKSUM[8]; 
-                } Token; 
-         
-         
-                Token.TOK_ID = 01 01; 
-                Token.SGN_SLG = 11 00; 
-                Token.Filler = ff ff ff ff; 
-         
-                // Create the sequence number 
-         
-                if (direction == sender_is_initiator) 
-                { 
-                        memset(Token.SEND_SEQ+4, 0xff, 4) 
-                } 
-                else if (direction == sender_is_acceptor) 
-                { 
-                        memset(Token.SEND_SEQ+4, 0, 4) 
-                } 
-                Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24; 
-                Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16; 
-                Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8; 
-                Token.SEND_SEQ[3] = (seq_num & 0x000000ff); 
-         
-                // Derive signing key from session key 
-         
-                Ksign = HMAC(Kss, "signaturekey"); 
-                                  // length includes terminating null 
-         
-                // Generate checksum of message - SGN_CKSUM 
-                //   Key derivation salt = 15 
-         
-                Sgn_Cksum = MD5((int32)15, Token.Header, data); 
-         
-                // Save first 8 octets of HMAC Sgn_Cksum 
-         
-                Sgn_Cksum = HMAC(Ksign, Sgn_Cksum); 
-                memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8); 
-         
-                // Encrypt the sequence number 
-         
-                // Derive encryption key for the sequence number 
-                //   Key derivation salt = 0 
-         
-                if (exportable) 
-                { 
-                        Kseq = HMAC(Kss, "fortybits", (int32)0); 
-                                     // len includes terminating null 
-                        memset(Kseq+7, 0xab, 7) 
-                } 
-                else 
-                { 
-  
-Swift                  Category - Informational                      8 
-
-
-
-
-
-
-
-
-                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
- 
- 
-                        Kseq = HMAC(Kss, (int32)0); 
-                } 
-                Kseq = HMAC(Kseq, Token.SGN_CKSUM); 
-         
-                // Encrypt the sequence number 
-         
-                RC4(Kseq, Token.SND_SEQ); 
-        } 
-    
-8.3 GSSAPI WRAP Semantics 
-    
-   There are two encryption keys for GSSAPI message tokens, one that is 
-   128 bits in strength, and one that is 56 bits in strength as defined 
-   in Section 6. 
-    
-   All padding is rounded up to 1 byte. One byte is needed to say that 
-   there is 1 byte of padding. The DES based mechanism type uses 8 byte 
-   padding. See [5] Section 1.2.2.3. 
-    
-   The RC4-HMAC GSS_Wrap() token has the following format: 
-    
-   Byte no            Name         Description 
-       0..1           TOK_ID       Identification field. 
-                                   Tokens emitted by GSS_Wrap() contain 
-                                   the hex value 02 01 in this field. 
-       2..3           SGN_ALG      Checksum algorithm indicator. 
-                                   11 00 - HMAC 
-       4..5           SEAL_ALG     ff ff - none 
-                                   00 00 - DES-CBC 
-                                   10 00 - RC4 
-       6..7           Filler       Contains ff ff 
-       8..15          SND_SEQ      Encrypted sequence number field. 
-       16..23         SGN_CKSUM    Checksum of plaintext padded data, 
-                                   calculated according to algorithm 
-                                   specified in SGN_ALG field. 
-       24..31         Confounder   Random confounder 
-       32..last       Data         encrypted or plaintext padded data 
-    
-   The encryption mechanism used for GSS wrap based messages is as 
-   follow: 
-    
-    
-        WRAP(Kss, encrypt, direction, export, seq_num, data) 
-        { 
-                struct Token {          // 32 octets 
-                       struct Header { 
-                              OCTET TOK_ID[2]; 
-                              OCTET SGN_ALG[2]; 
-                              OCTET SEAL_ALG[2]; 
-                              OCTET Filler[2]; 
-                       }; 
-                       OCTET SND_SEQ[8]; 
-                       OCTET SGN_CKSUM[8]; 
-  
-Swift                  Category - Informational                      9 
-
-
-
-
-
-
-
-
-                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
- 
- 
-                       OCTET Confounder[8]; 
-                } Token; 
-         
-         
-                Token.TOK_ID = 02 01; 
-                Token.SGN_SLG = 11 00; 
-                Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00; 
-                Token.Filler = ff ff; 
-         
-                // Create the sequence number 
-         
-                if (direction == sender_is_initiator) 
-                { 
-                        memset(&Token.SEND_SEQ[4], 0xff, 4) 
-                } 
-                else if (direction == sender_is_acceptor) 
-                { 
-                        memset(&Token.SEND_SEQ[4], 0, 4) 
-                } 
-                Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24; 
-                Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16; 
-                Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8; 
-                Token.SEND_SEQ[3] = (seq_num & 0x000000ff); 
-                         
-                // Generate random confounder 
-         
-                nonce(&Token.Confounder, 8); 
-         
-                // Derive signing key from session key 
-         
-                Ksign = HMAC(Kss, "signaturekey"); 
-         
-                // Generate checksum of message -  
-                //  SGN_CKSUM + Token.Confounder 
-                //   Key derivation salt = 15 
-         
-                Sgn_Cksum = MD5((int32)15, Token.Header, 
-                                Token.Confounder); 
-         
-                // Derive encryption key for data 
-                //   Key derivation salt = 0 
-         
-                for (i = 0; i < 16; i++) Klocal[i] = Kss[i] ^ 0xF0;     
-        // XOR 
-                if (exportable) 
-                { 
-                        Kcrypt = HMAC(Klocal, "fortybits", (int32)0); 
-                                    // len includes terminating null 
-                        memset(Kcrypt+7, 0xab, 7); 
-                } 
-                else 
-                { 
-                        Kcrypt = HMAC(Klocal, (int32)0); 
-  
-Swift                  Category - Informational                     10 
-
-
-
-
-
-
-
-
-                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
- 
- 
-                } 
-         
-                // new encryption key salted with seq 
-         
-                Kcrypt = HMAC(Kcrypt, (int32)seq); 
-         
-                // Encrypt confounder (if encrypting) 
-         
-                if (encrypt) 
-                        RC4(Kcrypt, Token.Confounder); 
-         
-                // Sum the data buffer 
-         
-                Sgn_Cksum += MD5(data);         // Append to checksum 
-         
-                // Encrypt the data (if encrypting) 
-         
-                if (encrypt) 
-                        RC4(Kcrypt, data); 
-         
-                // Save first 8 octets of HMAC Sgn_Cksum 
-         
-                Sgn_Cksum = HMAC(Ksign, Sgn_Cksum); 
-                memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8); 
-         
-                // Derive encryption key for the sequence number 
-                //   Key derivation salt = 0 
-         
-                if (exportable) 
-                { 
-                        Kseq = HMAC(Kss, "fortybits", (int32)0); 
-                                      // len includes terminating null 
-                        memset(Kseq+7, 0xab, 7) 
-                } 
-                else 
-                { 
-                        Kseq = HMAC(Kss, (int32)0); 
-                } 
-                Kseq = HMAC(Kseq, Token.SGN_CKSUM); 
-         
-                // Encrypt the sequence number 
-         
-                RC4(Kseq, Token.SND_SEQ); 
-         
-                // Encrypted message = Token + Data 
-        } 
-    
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States. 
-   It is now used to recognize that the key length is of "exportable" 
-   length. In this description, the key size is actually 56-bits. 
-    
-9. Security Considerations 
-  
-Swift                  Category - Informational                     11 
-
-
-
-
-
-
-
-
-                Windows 2000 RC4-HMAC Kerberos E-Type        May 2002 
- 
- 
- 
-   Care must be taken in implementing this encryption type because it 
-   uses a stream cipher. If a different IV isn't used in each direction 
-   when using a session key, the encryption is weak. By using the 
-   sequence number as an IV, this is avoided. 
-    
-10. Acknowledgements 
-    
-   We would like to thank Salil Dangi and Sam Hartman for the valuable 
-   input in refining the descriptions of the functions and their input. 
-     
-11. References 
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   3  Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for 
-      Message Authentication", RFC 2104, February 1997 
-    
-   4  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
-      Service (V5)", RFC 1510, September 1993 
- 
-   5  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, 
-      June 1996 
- 
-   6  R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 
-      1992 
- 
-   7  R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April 
-      1992 
- 
-   8  Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption             
-      Algorithm", Work in Progress. 
- 
-   9  RC4 is a proprietary encryption algorithm available under license 
-      from RSA Data Security Inc.  For licensing information, contact: 
-       
-         RSA Data Security, Inc. 
-         100 Marine Parkway 
-         Redwood City, CA 94065-1031 
- 
-   10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 
-      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
-      04.txt, June 25, 1999 
- 
-    
-12. Author's Addresses 
-    
-   Mike Swift 
-   Dept. of Computer Science 
-  
-Swift                  Category - Informational                     12 
-
-
-
-
-
-
-
-
-                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
- 
- 
-   Sieg Hall 
-   University of Washington 
-   Seattle, WA 98105 
-   Email: mikesw@cs.washington.edu  
-    
-   John Brezak 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@microsoft.com 
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                     13 
-
-
-
-
-
-
-
-
-                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
- 
- 
-    
-13. Full Copyright Statement 
- 
-   "Copyright (C) The Internet Society (2000). All Rights Reserved. 
-    
-   This document and translations of it may be copied and          
-   furnished to others, and derivative works that comment on or          
-   otherwise explain it or assist in its implementation may be          
-   prepared, copied, published and distributed, in whole or in          
-   part, without restriction of any kind, provided that the above          
-   copyright notice and this paragraph are included on all such          
-   copies and derivative works.  However, this document itself may          
-   not be modified in any way, such as by removing the copyright          
-   notice or references to the Internet Society or other Internet          
-   organizations, except as needed for the purpose of developing          
-   Internet standards in which case the procedures for copyrights          
-   defined in the Internet Standards process must be followed, or          
-   as required to translate it into languages other than English. 
-    
-   The limited permissions granted above are perpetual and will          
-   not be revoked by the Internet Society or its successors or          
-   assigns. 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                     14 
-
-
-
-
-
-
-
diff --git a/doc/standardisation/draft-foo b/doc/standardisation/draft-foo
deleted file mode 100644
index 8174d4678..000000000
--- a/doc/standardisation/draft-foo
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   Assar Westerlund
-<draft-ietf-cat-krb5-ipv6.txt>                                      SICS
-Internet-Draft                                             October, 1997
-Expire in six months
-
-                           Kerberos over IPv6
-
-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 (Europe),
-   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-   ftp.isi.edu (US West Coast).
-
-   Distribution of this memo is unlimited.  Please send comments to the
-   <cat-ietf@mit.edu> mailing list.
-
-Abstract
-
-   This document specifies the address types and transport types
-   necessary for using Kerberos [RFC1510] over IPv6 [RFC1883].
-
-Specification
-
-   IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB
-   order.  The type of IPv6 addresses is twenty-four (24).
-
-   The following addresses (see [RFC1884]) MUST not appear in any
-   Kerberos packet:
-
-   the Unspecified Address
-   the Loopback Address
-   Link-Local addresses
-
-   IPv4-mapped IPv6 addresses MUST be represented as addresses of type
-   2.
-
-
-
-
-Westerlund                                                      [Page 1]
-
-Internet Draft             Kerberos over IPv6              October, 1997
-
-
-   Communication with the KDC over IPv6 MUST be done as in section 8.2.1
-   of [RFC1510].
-
-Discussion
-
-   [RFC1510] suggests using the address family constants in
-   <sys/socket.h> from BSD.  This cannot be done for IPv6 as these
-   numbers have diverged and are different on different BSD-derived
-   systems.  [RFC2133] does not either specify a value for AF_INET6.
-   Thus a value has to be decided and the implementations have to
-   convert between the value used in Kerberos HostAddress and the local
-   AF_INET6.
-
-   There are a few different address types in IPv6, see [RFC1884].  Some
-   of these are used for quite special purposes and it makes no sense to
-   include them in Kerberos packets.
-
-   It is necessary to represent IPv4-mapped addresses as Internet
-   addresses (type 2) to be compatible with Kerberos implementations
-   that only support IPv4.
-
-Security considerations
-
-   This memo does not introduce any known security considerations in
-   addition to those mentioned in [RFC1510].
-
-References
-
-   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
-   Authentication Service (V5)", RFC 1510, September 1993.
-
-   [RFC1883] Deering, S., Hinden, R., "Internet Protocol, Version 6
-   (IPv6) Specification", RFC 1883, December 1995.
-
-   [RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing
-   Architecture", RFC 1884, December 1995.
-
-   [RFC2133] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic
-   Socket Interface Extensions for IPv6", RFC2133, April 1997.
-
-Author's Address
-
-   Assar Westerlund
-   Swedish Institute of Computer Science
-   Box 1263
-   S-164 29  KISTA
-   Sweden
-
-
-
-
-Westerlund                                                      [Page 2]
-
-Internet Draft             Kerberos over IPv6              October, 1997
-
-
-   Phone: +46-8-7521526
-   Fax:   +46-8-7517230
-   EMail: assar@sics.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Westerlund                                                      [Page 3]
-
diff --git a/doc/standardisation/draft-foo.ms b/doc/standardisation/draft-foo.ms
deleted file mode 100644
index 62b109afa..000000000
--- a/doc/standardisation/draft-foo.ms
+++ /dev/null
@@ -1,136 +0,0 @@
-.pl 10.0i
-.po 0
-.ll 7.2i
-.lt 7.2i
-.nr LL 7.2i
-.nr LT 7.2i
-.ds LF Westerlund
-.ds RF [Page %]
-.ds CF
-.ds LH Internet Draft
-.ds RH October, 1997
-.ds CH Kerberos over IPv6
-.hy 0
-.ad l
-.in 0
-.ta \n(.luR
-Network Working Group	Assar Westerlund
-<draft-ietf-cat-krb5-ipv6.txt>	SICS
-Internet-Draft	October, 1997
-Expire in six months
-
-.ce
-Kerberos over IPv6
-
-.ti 0
-Status of this Memo
-
-.in 3
-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
-(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
-Coast), or ftp.isi.edu (US West Coast).
-
-Distribution of this memo is unlimited.  Please send comments to the
-<cat-ietf@mit.edu> mailing list.
-
-.ti 0
-Abstract
-
-.in 3
-This document specifies the address types and transport types
-necessary for using Kerberos [RFC1510] over IPv6 [RFC1883].
-
-.ti 0
-Specification
-
-.in 3
-IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB
-order.  The type of IPv6 addresses is twenty-four (24).
-
-The following addresses (see [RFC1884]) MUST not appear in any
-Kerberos packet:
-
-the Unspecified Address
-.br
-the Loopback Address
-.br
-Link-Local addresses
-
-IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
-
-Communication with the KDC over IPv6 MUST be done as in section
-8.2.1 of [RFC1510].
-
-.ti 0
-Discussion
-
-.in 3
-[RFC1510] suggests using the address family constants in
-<sys/socket.h> from BSD.  This cannot be done for IPv6 as these
-numbers have diverged and are different on different BSD-derived
-systems.  [RFC2133] does not either specify a value for AF_INET6.
-Thus a value has to be decided and the implementations have to convert
-between the value used in Kerberos HostAddress and the local AF_INET6.
-
-There are a few different address types in IPv6, see [RFC1884].  Some
-of these are used for quite special purposes and it makes no sense to
-include them in Kerberos packets.
-
-It is necessary to represent IPv4-mapped addresses as Internet
-addresses (type 2) to be compatible with Kerberos implementations that
-only support IPv4.
-
-.ti 0
-Security considerations
-
-.in 3
-This memo does not introduce any known security considerations in
-addition to those mentioned in [RFC1510].
-
-.ti 0
-References
-
-.in 3
-[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
-Authentication Service (V5)", RFC 1510, September 1993.
-
-[RFC1883] Deering, S., Hinden, R., "Internet Protocol, Version 6
-(IPv6) Specification", RFC 1883, December 1995.
-
-[RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing
-Architecture", RFC 1884, December 1995.
-
-[RFC2133] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic
-Socket Interface Extensions for IPv6", RFC2133, April 1997.
-
-.ti 0
-Author's Address
-
-Assar Westerlund
-.br
-Swedish Institute of Computer Science
-.br
-Box 1263
-.br
-S-164 29  KISTA
-.br
-Sweden
-
-Phone: +46-8-7521526
-.br
-Fax:   +46-8-7517230
-.br
-EMail: assar@sics.se
diff --git a/doc/standardisation/draft-foo2 b/doc/standardisation/draft-foo2
deleted file mode 100644
index 0fa695f64..000000000
--- a/doc/standardisation/draft-foo2
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   Assar Westerlund
-<draft-ietf-cat-krb5-tcp.txt>                                       SICS
-Internet-Draft                                          Johan Danielsson
-November, 1997                                                  PDC, KTH
-Expire in six months
-
-                           Kerberos over TCP
-
-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 (Europe),
-   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-   ftp.isi.edu (US West Coast).
-
-   Distribution of this memo is unlimited.  Please send comments to the
-   <cat-ietf@mit.edu> mailing list.
-
-Abstract
-
-   This document specifies how the communication should be done between
-   a client and a KDC using Kerberos [RFC1510] with TCP as the transport
-   protocol.
-
-Specification
-
-   This draft specifies an extension to section 8.2.1 of RFC1510.
-
-   A Kerberos server MAY accept requests on TCP port 88 (decimal).
-
-   The data sent from the client to the KDC should consist of 4 bytes
-   containing the length, in network byte order, of the Kerberos
-   request, followed by the request (AS-REQ or TGS-REQ) itself.  The
-   reply from the KDC should consist of the length of the reply packet
-   (4 bytes, network byte order) followed by the packet itself (AS-REP,
-   TGS-REP, or KRB-ERROR).
-
-
-
-
-Westerlund, Danielsson                                          [Page 1]
-
-Internet Draft             Kerberos over TCP              November, 1997
-
-
-   C->S: Open connection to TCP port 88 at the server
-   C->S: length of request
-   C->S: AS-REQ or TGS-REQ
-   S->C: length of reply
-   S->C: AS-REP, TGS-REP, or KRB-ERROR
-
-Discussion
-
-   Even though the preferred way of sending kerberos packets is over UDP
-   there are several occasions when it's more practical to use TCP.
-
-   Mainly, it's usually much less cumbersome to get TCP through
-   firewalls than UDP.
-
-   In theory, there's no reason for having explicit length fields, that
-   information is already encoded in the ASN1 encoding of the Kerberos
-   packets.  But having explicit lengths makes it unnecessary to have to
-   decode the ASN.1 encoding just to know how much data has to be read.
-
-   Another way of signaling the end of the request of the reply would be
-   to do a half-close after the request and a full-close after the
-   reply.  This does not work well with all kinds of firewalls.
-
-Security considerations
-
-   This memo does not introduce any known security considerations in
-   addition to those mentioned in [RFC1510].
-
-References
-
-   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
-   Authentication Service (V5)", RFC 1510, September 1993.
-
-Authors' Addresses
-
-   Assar Westerlund
-   Swedish Institute of Computer Science
-   Box 1263
-   S-164 29  KISTA
-   Sweden
-
-   Phone: +46-8-7521526
-   Fax:   +46-8-7517230
-   EMail: assar@sics.se
-
-   Johan Danielsson
-   PDC, KTH
-   S-100 44  STOCKHOLM
-
-
-
-Westerlund, Danielsson                                          [Page 2]
-
-Internet Draft             Kerberos over TCP              November, 1997
-
-
-   Sweden
-
-   Phone: +46-8-7907885
-   Fax:   +46-8-247784
-   EMail: joda@pdc.kth.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Westerlund, Danielsson                                          [Page 3]
-
diff --git a/doc/standardisation/draft-foo2.ms b/doc/standardisation/draft-foo2.ms
deleted file mode 100644
index 7e0fa0a62..000000000
--- a/doc/standardisation/draft-foo2.ms
+++ /dev/null
@@ -1,145 +0,0 @@
-.pl 10.0i
-.po 0
-.ll 7.2i
-.lt 7.2i
-.nr LL 7.2i
-.nr LT 7.2i
-.ds LF Westerlund, Danielsson
-.ds RF [Page %]
-.ds CF
-.ds LH Internet Draft
-.ds RH November, 1997
-.ds CH Kerberos over TCP
-.hy 0
-.ad l
-.in 0
-.ta \n(.luR
-.nf
-Network Working Group	Assar Westerlund
-<draft-ietf-cat-krb5-tcp.txt>	SICS
-Internet-Draft	Johan Danielsson
-November, 1997	PDC, KTH
-Expire in six months
-.fi
-
-.ce
-Kerberos over TCP
-
-.ti 0
-Status of this Memo
-
-.in 3
-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
-(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
-Coast), or ftp.isi.edu (US West Coast).
-
-Distribution of this memo is unlimited.  Please send comments to the
-<cat-ietf@mit.edu> mailing list.
-
-.ti 0
-Abstract
-
-.in 3
-This document specifies how the communication should be done between a
-client and a KDC using Kerberos [RFC1510] with TCP as the transport
-protocol.
-
-.ti 0
-Specification
-
-This draft specifies an extension to section 8.2.1 of RFC1510. 
-
-A Kerberos server MAY accept requests on TCP port 88 (decimal).
-
-The data sent from the client to the KDC should consist of 4 bytes
-containing the length, in network byte order, of the Kerberos request,
-followed by the request (AS-REQ or TGS-REQ) itself.  The reply from
-the KDC should consist of the length of the reply packet (4 bytes,
-network byte order) followed by the packet itself (AS-REP, TGS-REP, or
-KRB-ERROR).
-
-.nf
-C->S: Open connection to TCP port 88 at the server
-C->S: length of request
-C->S: AS-REQ or TGS-REQ
-S->C: length of reply
-S->C: AS-REP, TGS-REP, or KRB-ERROR
-.fi
-
-.ti 0
-Discussion
-
-Even though the preferred way of sending kerberos packets is over UDP
-there are several occasions when it's more practical to use TCP.
-
-Mainly, it's usually much less cumbersome to get TCP through firewalls
-than UDP.
-
-In theory, there's no reason for having explicit length fields, that
-information is already encoded in the ASN1 encoding of the Kerberos
-packets.  But having explicit lengths makes it unnecessary to have to
-decode the ASN.1 encoding just to know how much data has to be read.
-
-Another way of signaling the end of the request of the reply would be
-to do a half-close after the request and a full-close after the reply.
-This does not work well with all kinds of firewalls.
-
-.ti 0
-Security considerations
-
-.in 3
-This memo does not introduce any known security considerations in
-addition to those mentioned in [RFC1510].
-
-.ti 0
-References
-
-.in 3
-[RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
-Authentication Service (V5)", RFC 1510, September 1993.
-
-.ti 0
-Authors' Addresses
-
-Assar Westerlund
-.br
-Swedish Institute of Computer Science
-.br
-Box 1263
-.br
-S-164 29  KISTA
-.br
-Sweden
-
-Phone: +46-8-7521526
-.br
-Fax:   +46-8-7517230
-.br
-EMail: assar@sics.se
-
-Johan Danielsson
-.br
-PDC, KTH
-.br
-S-100 44  STOCKHOLM
-.br
-Sweden
-
-Phone: +46-8-7907885
-.br
-Fax:   +46-8-247784
-.br
-EMail: joda@pdc.kth.se
diff --git a/doc/standardisation/draft-foo3 b/doc/standardisation/draft-foo3
deleted file mode 100644
index 2b8b7bb57..000000000
--- a/doc/standardisation/draft-foo3
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   Assar Westerlund
-<draft-ietf-cat-krb5-firewalls.txt>                                 SICS
-Internet-Draft                                          Johan Danielsson
-November, 1997                                                  PDC, KTH
-Expire in six months
-
-                         Kerberos vs firewalls
-
-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 (Europe),
-   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-   ftp.isi.edu (US West Coast).
-
-   Distribution of this memo is unlimited.  Please send comments to the
-   <cat-ietf@mit.edu> mailing list.
-
-Abstract
-
-Introduction
-
-   Kerberos[RFC1510] is a protocol for authenticating parties
-   communicating over insecure networks.
-
-   Firewalling is a technique for achieving an illusion of security by
-   putting restrictions on what kinds of packets and how these are sent
-   between the internal (so called "secure") network and the global (or
-   "insecure") Internet.
-
-Definitions
-
-   client: the user, process, and host acquiring tickets from the KDC
-   and authenticating itself to the kerberised server.
-
-   KDC: the Kerberos Key Distribution Center
-
-
-
-
-Westerlund, Danielsson                                          [Page 1]
-
-Internet Draft           Kerberos vs firewalls            November, 1997
-
-
-   Kerberised server: the server using Kerberos to authenticate the
-   client, for example telnetd.
-
-Firewalls
-
-   A firewall is usually placed between the "inside" and the "outside"
-   networks, and is supposed to protect the inside from the evils on the
-   outside.  There are different kinds of firewalls.  The main
-   differences are in the way they forward packets.
-
-   o+  The most straight forward type is the one that just imposes
-      restrictions on incoming packets. Such a firewall could be
-      described as a router that filters packets that match some
-      criteria.
-
-   o+  They may also "hide" some or all addresses on the inside of the
-      firewall, replacing the addresses in the outgoing packets with the
-      address of the firewall (aka network address translation, or NAT).
-      NAT can also be used without any packet filtering, for instance
-      when you have more than one host sharing a single address (for
-      example, with a dialed-in PPP connection).
-
-   There are also firewalls that does NAT both on the inside and the
-   outside (a server on the inside will see this as a connection from
-   the firewall).
-
-   o+  A third type is the proxy type firewall, that parses the contents
-      of the packets, basically acting as a server to the client, and as
-      a client to the server (man-in-the-middle). If Kerberos is to be
-      used with this kind of firewall, a protocol module that handles
-      KDC requests has to be written.
-
-   This type of firewall might also cause extra trouble when used with
-   kerberised versions of protocols that the proxy understands, in
-   addition to the ones mentioned below. This is the case with the FTP
-   Security Extensions [RFC2228], that adds a new set of commands to the
-   FTP protocol [RFC959], for integrity, confidentiality, and privacy
-   protecting commands. When transferring data, the FTP protocol uses a
-   separate data channel, and an FTP proxy will have to look out for
-   commands that start a data transfer. If all commands are encrypted,
-   this is impossible. A protocol that doesn't suffer from this is the
-   Telnet Authentication Option [RFC1416] that does all authentication
-   and encryption in-bound.
-
-Scenarios
-
-   Here the different scenarios we have considered are described, the
-   problems they introduce and the proposed ways of solving them.
-
-
-
-Westerlund, Danielsson                                          [Page 2]
-
-Internet Draft           Kerberos vs firewalls            November, 1997
-
-
-   Combinations of these can also occur.
-
- Client behind firewall
-
-   This is the most typical and common scenario.  First of all the
-   client needs some way of communicating with the KDC.  This can be
-   done with whatever means and is usually much simpler when the KDC is
-   able to communicate over TCP.
-
-   Apart from that, the client needs to be sure that the ticket it will
-   acquire from the KDC can be used to authenticate to a server outside
-   its firewall.  For this, it needs to add the address(es) of potential
-   firewalls between itself and the KDC/server, to the list of its own
-   addresses when requesting the ticket.  We are not aware of any
-   protocol for determining this set of addresses, thus this will have
-   to be manually configured in the client.
-
-   The client could also request a ticket with no addresses, but some
-   KDCs and servers might not accept such a ticket.
-
-   With the ticket in possession, communication with the kerberised
-   server will not need to be any different from communicating between a
-   non-kerberised client and server.
-
- Kerberised server behind firewall
-
-   The kerberised server does not talk to the KDC at all so nothing
-   beyond normal firewall-traversal techniques for reaching the server
-   itself needs to be applied.
-
-   The kerberised server needs to be able to retrieve the original
-   address (before its firewall) that the request was sent for.  If this
-   is done via some out-of-band mechanism or it's directly able to see
-   it doesn't matter.
-
- KDC behind firewall
-
-   The same restrictions applies for a KDC as for any other server.
-
-Specification
-
-Security considerations
-
-   This memo does not introduce any known security considerations in
-   addition to those mentioned in [RFC1510].
-
-References
-
-
-
-
-Westerlund, Danielsson                                          [Page 3]
-
-Internet Draft           Kerberos vs firewalls            November, 1997
-
-
-   [RFC959] Postel, J. and Reynolds, J., "File Transfer Protocol (FTP)",
-   RFC 969, October 1985
-
-   [RFC1416] Borman, D., "Telnet Authentication Option", RFC 1416,
-   February 1993.
-
-   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
-   Authentication Service (V5)", RFC 1510, September 1993.
-
-   [RFC2228] Horowitz, M. and Lunt, S., "FTP Security Extensions",
-   RFC2228, October 1997.
-
-Authors' Addresses
-
-   Assar Westerlund
-   Swedish Institute of Computer Science
-   Box 1263
-   S-164 29  KISTA
-   Sweden
-
-   Phone: +46-8-7521526
-   Fax:   +46-8-7517230
-   EMail: assar@sics.se
-
-   Johan Danielsson
-   PDC, KTH
-   S-100 44  STOCKHOLM
-   Sweden
-
-   Phone: +46-8-7907885
-   Fax:   +46-8-247784
-   EMail: joda@pdc.kth.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Westerlund, Danielsson                                          [Page 4]
-
diff --git a/doc/standardisation/draft-foo3.ms b/doc/standardisation/draft-foo3.ms
deleted file mode 100644
index c024ca355..000000000
--- a/doc/standardisation/draft-foo3.ms
+++ /dev/null
@@ -1,260 +0,0 @@
-.\" even if this file is called .ms, it's using the me macros.
-.\" to format try something like `nroff -me'
-.\" level 2 heading
-.de HH
-.$p "\\$2" "" "\\$1"
-.$0 "\\$2"
-..
-.\" make sure footnotes produce the right thing with nroff
-.ie t \
-\{\
-.ds { \v'-0.4m'\x'\\n(0x=0*-0.2m'\s-3
-.ds } \s0\v'0.4m'
-.\}
-.el \
-\{\
-.ds { [
-.ds } ]
-.\}
-.ds * \\*{\\n($f\\*}\k*
-.\" page footer
-.fo 'Westerlund, Danielsson''[Page %]'
-.\" date
-.ds RH \*(mo, 19\n(yr
-.\" left margin
-.nr lm 6
-.\" heading indent per level
-.nr si 3n
-.\" footnote indent
-.nr fi 0
-.\" paragraph indent
-.nr po 0
-.\" don't hyphenate
-.hy 0
-.\" left adjustment
-.ad l
-.\" indent 0
-.in 0
-.\" line length 16cm and page length 25cm (~10 inches)
-.ll 16c
-.pl 25c
-.ta \n(.luR
-.nf
-Network Working Group	Assar Westerlund
-<draft-ietf-cat-krb5-firewalls.txt>	SICS
-Internet-Draft	Johan Danielsson
-\*(RH	PDC, KTH
-Expire in six months	
-.fi
-
-.\" page header, has to be set here so it won't appear on page 1
-.he 'Internet Draft'Kerberos vs firewalls'\*(RH'
-.ce
-.b "Kerberos vs firewalls"
-
-.HH 1 "Status of this Memo"
-.lp
-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.
-.lp
-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 \*(lqwork in progress.\*(rq
-.lp
-To view the entire list of current Internet-Drafts, please check the
-\*(lq1id-abstracts.txt\*(rq listing contained in the Internet-Drafts
-Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
-munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
-ftp.isi.edu (US West Coast).
-.lp
-Distribution of this memo is unlimited.  Please send comments to the
-<cat-ietf@mit.edu> mailing list.
-.HH 1 "Abstract"
-.lp
-Kerberos and firewalls both deal with security, but doesn't get along
-very well. This memo discusses ways to use Kerberos in a firewalled
-environment.
-.HH 1 "Introduction"
-.lp
-Kerberos[RFC1510]
-.(d
-[RFC1510]
-Kohl, J. and Neuman, C., \*(lqThe Kerberos Network Authentication
-Service (V5)\*(rq, RFC 1510, September 1993.
-.)d
-is a protocol for authenticating parties communicating over insecure
-networks.  Firewalling is a technique for achieving an illusion of
-security by putting restrictions on what kinds of packets and how
-these are sent between the internal (so called \*(lqsecure\*(rq)
-network and the global (or \*(lqinsecure\*(rq) Internet.  The problems
-with firewalls are many, but to name a few:
-.np
-Firewalls usually doesn't allow people to use UDP. The reason for this
-is that UDP is (by firewall advocates) considered insecure. This
-belief is probably based on the fact that many \*(lqinsecure\*(rq
-protocols (like NFS) use UDP. UDP packets are also considered easy to
-fake.
-.np
-Firewalls usually doesn't allow people to connect to arbitrary ports,
-such as the ports used when talking to the KDC.
-.np
-In many non-computer organisations, the computer staff isn't what
-you'd call \*(lqwizards\*(rq; a typical case is an academic
-institution, where someone is taking care of the computers part time,
-and is doing research the rest of the time. Adding a complex device
-like a firewall to an environment like this, often leads to poorly run
-systems that is more a hindrance for the legitimate users than to
-possible crackers.
-.lp
-The easiest way to deal with firewalls is to ignore them, however in
-some cases this just isn't possible. You might have users that are
-stuck behind a firewall, but also has to access your system, or you
-might find yourself behind a firewall, for instance when out
-travelling.
-.lp
-To make it possible for people to use Kerberos from behind a firewall,
-there are several things to consider.
-.(q
-.i
-Add things to do when stuck behind a firewall, like talking about the
-problem with local staff, making them open some port in the firewall,
-using some other port, or proxy.
-.r
-.)q
-.HH 1 "Firewalls"
-.lp
-A firewall is usually placed between the \*(lqinside\*(rq and the
-\*(lqoutside\*(rq networks, and is supposed to protect the inside from the
-evils on the outside.  There are different kinds of firewalls.  The
-main differences are in the way they forward (or doesn't) packets.
-.ip \(bu
-The most straight forward type is the one that just imposes
-restrictions on incoming packets. Such a firewall could be described
-as a router that filters packets that match some criteria.
-.ip \(bu
-They may also \*(lqhide\*(rq some or all addresses on the inside of the
-firewall, replacing the addresses in the outgoing packets with the
-address of the firewall (aka network address translation, or NAT). NAT
-can also be used without any packet filtering, for instance when you
-have more than one host sharing a single address (e.g with a dialed-in
-PPP connection).
-.ip
-There are also firewalls that does NAT both on the inside and the
-outside (a server on the inside will see this as a connection from the
-firewall).
-.ip \(bu
-A third type is the proxy type firewall, that parses the contents of
-the packets, basically acting as a server to the client, and as a
-client to the server (man-in-the-middle). If Kerberos is to be used
-with this kind of firewall, a protocol module that handles KDC
-requests has to be written\**.
-.(f
-\**Instead of writing a new module for Kerberos, it can be possible to
-hitch a ride on some other protocol, that's already beeing handled by
-the proxy.
-.)f
-.lp
-The last type of firewall might also cause extra trouble when used
-with kerberised versions of protocols that the proxy understands, in
-addition to the ones mentioned below. This is the case with the FTP
-Security Extensions [RFC2228],
-.(d
-[RFC2228]
-Horowitz, M. and Lunt, S., \*(lqFTP Security Extensions\*(rq, RFC2228,
-October 1997.
-.)d
-that adds a new set of commands to the FTP protocol [RFC959],
-.(d
-[RFC959] Postel, J. and Reynolds, J., \*(lqFile Transfer Protocol
-(FTP)\*(rq, RFC 969, October 1985
-.)d
-for integrity, confidentiality, and privacy protecting commands, and
-data. When transferring data, the FTP protocol uses a separate data
-channel, and an FTP proxy will have to look out for commands that
-start a data transfer. If all commands are encrypted, this is
-impossible. A protocol that doesn't suffer from this is the Telnet
-Authentication Option [RFC1416]
-.(d
-[RFC1416]
-Borman, D., \*(lqTelnet Authentication Option\*(rq, RFC 1416, February
-1993.
-.)d
-that does all
-authentication and encryption in-bound.
-.HH 1 "Scenarios"
-.lp
-Here the different scenarios we have considered are described, the
-problems they introduce and the proposed ways of solving them.
-Combinations of these can also occur.
-.HH 2 "Client behind firewall"
-.lp
-This is the most typical and common scenario.  First of all the client
-needs some way of communicating with the KDC.  This can be done with
-whatever means and is usually much simpler when the KDC is able to
-communicate over TCP.
-.lp
-Apart from that, the client needs to be sure that the ticket it will
-acquire from the KDC can be used to authenticate to a server outside
-its firewall.  For this, it needs to add the address(es) of potential
-firewalls between itself and the KDC/server, to the list of its own
-addresses when requesting the ticket.  We are not aware of any
-protocol for determining this set of addresses, thus this will have to
-be manually configured in the client.
-.lp
-The client could also request a ticket with no addresses. This is not
-a recommended way to solve this problem. The address was put into the
-ticket to make it harder to use a stolen ticket.  A ticket without
-addresses will therefore be less \*(lqsecure.\*(rq RFC1510 also says that
-the KDC may refuse to issue, and the server may refuse to accept an
-address-less ticket.
-.lp
-With the ticket in possession, communication with the kerberised
-server will not need to be any different from communicating between a
-non-kerberised client and server.
-.HH 2 "Kerberised server behind firewall"
-.lp
-The kerberised server does not talk to the KDC at all, so nothing
-beyond normal firewall-traversal techniques for reaching the server
-itself needs to be applied.
-.lp
-If the firewall rewrites the clients address, the server will have to
-use some other (possibly firewall specific) protocol to retrieve the
-original address. If this is not possible, the address field will have
-to be ignored. This has the same effect as if there were no addresses
-in the ticket (see the discussion above).
-.HH 2 "KDC behind firewall"
-.lp
-The KDC is in this respect basically just like any other server.
-.\" .uh "Specification"
-.HH 1 "Security considerations"
-.lp
-Since the whole network behind a NAT-type firewall looks like one
-computer from the outside, any security added by the addresses in the
-ticket will be lost.
-.HH 1 "References"
-.lp
-.pd
-.HH 1 "Authors' Addresses"
-.lp
-.nf
-Assar Westerlund
-Swedish Institute of Computer Science
-Box 1263
-S-164 29 KISTA
-.sp
-Phone: +46-8-7521526
-Fax: +46-8-7517230
-EMail: assar@sics.se
-.sp 2
-Johan Danielsson
-Center for Parallel Computers
-KTH
-S-100 44 STOCKHOLM
-.sp
-Phone: +46-8-7906356
-Fax: +46-8-247784
-EMail: joda@pdc.kth.se
-.fi
\ No newline at end of file
diff --git a/doc/standardisation/draft-hartman-gss-naming-00.txt b/doc/standardisation/draft-hartman-gss-naming-00.txt
deleted file mode 100644
index 9141e339d..000000000
--- a/doc/standardisation/draft-hartman-gss-naming-00.txt
+++ /dev/null
@@ -1,561 +0,0 @@
-
-
-Network Working Group                                         S. Hartman
-Internet-Draft                                                       MIT
-Expires: January 10, 2005                                  July 12, 2004
-
-
-           GSSAPI Mechanisms without a Single Canonical Name
-                    draft-hartman-gss-naming-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at http://
-   www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 10, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
-   The Generic Security Services API (GSSAPI) uses name-based
-   authorization.  GSSAPI authenticates two named parties to each other.
-   Names can be stored on access control lists to make authorization
-   decisions.  Advances in security mechanisms require this model to be
-   extended.  Some mechanisms such as public-key mechanisms do not have
-   a single name to be used. Other mechanisms such as Kerberos allow
-   names to change as people move around organizations.  This document
-   proposes expanding the definition of GSSAPI names to deal with these
-   situations.
-
-
-
-
-
-Hartman                 Expires January 10, 2005                [Page 1]
-
-Internet-Draft            GSS Name Attributes                  July 2004
-
-
-1.  Introduction
-
-   The Generic  Security Services API [1] provides a function called
-   gss_export_name that will flatten a GSSAPI name  into a binary blob
-   suitable for comparisons.   This binary blob can be stored on ACLs
-   and then authorization decisions can be made simply by comparing the
-   name exported from a newly accepted context to the name on the ACL.
-
-   As a side effect of this name-based authorization model, each
-   mechanism name needs to be able to be represented in a single
-   canonical form and anyone importing that name needs to be able to
-   retrieve the canonical form.
-
-   Several security mechanisms have been proposed for which this naming
-   architecture is too restrictive.  In some cases it is not always
-   possible to canonicalize any name that is imported.  In other cases
-   there is no single canonical name.  In addition, there is a desire to
-   have more complex authorization models  in GSSAPI than the current
-   name based authorization model.
-
-   This draft discusses two different cases where the current GSSAPI
-   naming seems inadequate.  Then, an extension to GSSAPI naming to meet
-   these concerns is sketched.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 10, 2005                [Page 2]
-
-Internet-Draft            GSS Name Attributes                  July 2004
-
-
-2.  Kerberos Naming
-
-   The Kerberos Referals draft [2] proposes a new type of Kerberos name
-   called an enterprise name. The intent is that the enterprise name is
-   an alias that the user knows for themselves and can use to login.
-   The Kerberos KDC translates this name into a normal Kerberos
-   principal and gives the user tickets for this principal.  This normal
-   principal is used for authorization.  The intent is that the
-   enterprise name tracks the user as they move throughout the
-   organization, even if they move to parts of the organization that
-   have different naming policies.    The name they type at login
-   remains constant, but the Kerberos principal used to authenticate
-   them to services changes.
-
-   Performing a mapping from enterprise  name to principal name is not
-   generally possible for unauthenticated services.  So in order to
-   canonicalize an enterprise name to get a principal, a service must
-   have credentials.    However it may not be desirable to allow
-   services to map enterprise names to principal names in the general
-   case.   Also, Kerberos does not (and does not plan to) provide a
-   mechanism for mapping enterprise names to principals besides
-   authentication as the enterprise name.  So any such mapping would be
-   vendor-specific.  With this feature in Kerberos, it is not possible
-   to implement gss_canonicalize_name for enterprise name types.
-
-   Another issue arises with enterprise names.  IN some cases it would
-   be desirable to put   the enterprise name on the ACL instead of a
-   principal name.  Thus, it would be desirable to include the
-   enterprise name in the name exported by gss_export_name.  However
-   then the exported name would change whenever the mapping changed,
-   defeating the purpose  of including the enterprise name.  So in some
-   cases it would be desirable to have the exported name be based on the
-   enterprise name and in others based on the principal name, but this
-   is not currently possible.
-
-   Another development also complicates GSSAPI naming for Kerberos.
-   Several vendors have been looking at mechanisms to include group
-   membership information in Kerberos authorization data.   Then it is
-   desirable to put these group names on ACLs.  Again, GSSAPI currently
-   has no mechanism to use this information.
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 10, 2005                [Page 3]
-
-Internet-Draft            GSS Name Attributes                  July 2004
-
-
-3.  X.509 Names
-
-   X.509 names are at least as complex as Kerberos names.  It seems like
-   you might want to use the subject name as the name to be exported in
-   a GSSAPI mechanism.  However RFC 3280 [3] does not even require the
-   subject name to be a non-empty sequence.  Instead there are cases
-   where the subjectAltName extension is the only thing to identify the
-   subject of the certificate.  As in the case of Kerberos group
-   memberships, there may be many subjectAltName extensions available in
-   a certificate.  Different applications will care about different
-   extensions.   Thus there is no single value that can be  defined as
-   the exported GSSAPI name that will be generally useful.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 10, 2005                [Page 4]
-
-Internet-Draft            GSS Name Attributes                  July 2004
-
-
-4.  Composite Names
-
-   I propose extending the concept of a GSSAPI name  to include a
-   collection of attributes.  Each attribute would be an octet-string
-   labeled by an OID.  Examples of attributes would include Kerberos
-   enterprise names, group memberships in an authorization
-   infrastructure, Kerberos authorization data attributes and
-   subjectAltName attributes in a certificate.  Several new operations
-   would be needed:
-   1.  Add attribute to name
-   2.  Query attributes of name
-   3.  Query values of an attribute
-   4.  Delete an attribute from a name
-
-4.1  Usage of Name Attributes
-
-   Since attributes are part of GSSAPI names, the acceptor can retrieve
-   the attributes of the initiator's name from the context.   These
-   attributes can then be used for authorization.
-
-   Most name attributes will probably not come from explicit operations
-   to add attributes to a name.   Instead, name attributes will probably
-   come from mechanism specific credentials.    Mechanism specific
-   naming and group membership can be  mapped into name attributes by
-   the mechanism implementation.    The specific form of this mapping
-   will general require protocol specification for each mechanism.
-
-4.2  Open issues
-
-   This section describes parts of the proposal to add attributes to
-   names that will need to be explored before the proposal can become a
-   protocol specification.
-
-   Are mechanisms expected to be able to carry arbitrary name attributes
-   as part of a context establishment?   At first it seems like this
-   would be desirable.  However the point of GSSAPI is to establish an
-   authenticated context between two peers.   In particular, a context
-   authenticates two named entities to each other.  The names of these
-   entities and attributes associated with these names will be used for
-   authorization decisions.  If an initiator or acceptor is allowed to
-   assert name attributes and the authenticity of these assertions is
-   not validated by the mechanisms, then security problems may result.
-   On the other hand, requiring that name attributes be mechanism
-   specific and only be carried by mechanisms that understand the name
-   attributes and can validate them compromises GSSAPI's place as a
-   generic API. Application authors would be forced to understand
-   mechanism-specific attributes to make authorization decisions.   In
-   addition if mechanisms are not required to transport arbitrary
-
-
-
-Hartman                 Expires January 10, 2005                [Page 5]
-
-Internet-Draft            GSS Name Attributes                  July 2004
-
-
-   attributes, then application authors will need to deal with different
-   implementations of the same mechanism that support different sets of
-   name attributes.
-
-   Another related question is how will name attributes be mapped into
-   their mechanism-specific forms.  For example it would be desirable to
-   map many  Kerberos authorization data elements into name attributes.
-   For example in the case of the Microsoft PAC, it would be desirable
-   for some applications to get the entire PAC.  However in many cases,
-   the specific lists of security IDs contained in the PAC would be more
-   directly useful to an application.  So there may not be a good
-   one-to-one mapping between the mechanism-specific elements and the
-   representation desirable at the GSSAPI layer.
-
-   Specific name matching rules need to be developed.  How do names with
-   attributes compare?  What is the effect of a name attribute on a
-   target name in gss_accept_sec_context?
-
-4.3  Name Attributes Instead of Credential Extensions
-
-   An alternative to this proposal is to extend GSSAPI credentials  with
-   extensions labeled by OIDs.  Interfaces would be needed to manipulate
-   these credential extensions and to retrieve the credential extensions
-   for credentials used to establish a context.  Even if name attributes
-   are used, credential extensions may be useful for other unrelated
-   purposes.
-
-   It is possible to solve problems discussed in this document using
-   some credential extension mechanism.  Doing so will have many of the
-   same open issues as discussed in this name attributes proposal.  The
-   main advantage of a credential extensions proposal is that  it avoids
-   specifying how name attributes interact with name comparison or
-   target names.
-
-   The primary advantage of the name attributes proposal over credential
-   extensions is that name attributes seem to fit better into the GSSAPI
-   authorization model.    Names are already available at all points
-   when authorization decisions are made.  In addition, for many
-   mechanisms the sort of information carried as name attributes will
-   also be carried as part of the name in the mechanism
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 10, 2005                [Page 6]
-
-Internet-Draft            GSS Name Attributes                  July 2004
-
-
-5.  Handling gss_export_name
-
-   For many mechanisms, there will be  an obvious choice to use for the
-   name exported by gss_export_name.  For example in the case of
-   Kerberos, the principal name can continue to be used as the exported
-   name.  This will allow applications depending on existing GSSAPI
-   name-based authorization to continue to work. However it is probably
-   desirable to allow GSSAPI mechanisms for which gss_export_name cannot
-   meaningfully be defined.  The behavior of gss_export_name in such
-   cases should probably be to return some error.  Such mechanisms may
-   not work with existing applications and cannot conform to the current
-   version of the GSSAPI.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 10, 2005                [Page 7]
-
-Internet-Draft            GSS Name Attributes                  July 2004
-
-
-6.  Security Considerations
-
-   GSSAPI sets up a security context between two named parties. The
-   GSSAPI names are security assertions that are authenticated by the
-   context establishment process.  As such  the GSS naming architecture
-   is critical to the security of GSSAPI.
-
-   Currently GSSAPI uses a simplistic naming model for authorization.
-   Names can be compared  against a set of names on an access control
-   list.  This architecture is relatively simple and its security
-   properties are well understood.  However it does not provide the
-   flexibility and feature set for future deployments of GSSAPI.
-
-   This proposal will significantly increase the complexity of the GSS
-   naming architecture.  As this proposal is fleshed out, we need to
-   consider ways of managing security exposures created by this
-   increased complexity.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 10, 2005                [Page 8]
-
-Internet-Draft            GSS Name Attributes                  July 2004
-
-
-7.  Acknowledgements
-
-   John Brezak, Paul Leach and Nicolas Williams all participated in
-   discussions that defined the problem this proposal attempts to solve.
-   Nicolas Williams and I discussed details of proposals to solve this
-   problem.   However the details and open issues presented here have
-   only been reviewed by me and so I am responsible for their errors.
-
-8  Informative References
-
-   [1]  Linn, J., "Generic Security Service Application Program
-        Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [2]  Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating
-        KDC Referrals to locate Kerberos realms",
-        draft-ietf-krb-wg-kerberos-referals-03.txt (work in progress),
-        2004.
-
-   [3]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
-        Public Key Infrastructure Certificate and Certificate Revocation
-        List (CRL) Profile", rfc 3280, April 2002.
-
-
-Author's Address
-
-   Sam Hartman
-   MIT
-
-   EMail: hartmans@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 10, 2005                [Page 9]
-
-Internet-Draft            GSS Name Attributes                  July 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights. Information
-   on the IETF's procedures with respect to rights in IETF Documents can
-   be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard. Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Hartman                 Expires January 10, 2005               [Page 10]
-
-
diff --git a/doc/standardisation/draft-hartman-gss-naming-01.txt b/doc/standardisation/draft-hartman-gss-naming-01.txt
deleted file mode 100644
index 544eba284..000000000
--- a/doc/standardisation/draft-hartman-gss-naming-01.txt
+++ /dev/null
@@ -1,674 +0,0 @@
-
-
-
-Network Working Group                                         S. Hartman
-Internet-Draft                                                       MIT
-Expires: April 24, 2005                                 October 24, 2004
-
-
-           GSSAPI Mechanisms without a Single Canonical Name
-                    draft-hartman-gss-naming-01.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 24, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   The Generic Security Services API (GSSAPI) provides a naming
-   architecture that supports  name-based authorization.  GSSAPI
-   authenticates two named parties to each other.  Names can be stored
-   on access control lists to make authorization decisions.  Advances in
-   security mechanisms and the way implementers wish to use GSSAPI
-   require this model to be extended.  Some mechanisms such as
-   public-key mechanisms do not have a single name to be used.  Other
-   mechanisms such as Kerberos allow names to change as people move
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 1]
-
-Internet-Draft            GSS Name Attributes               October 2004
-
-
-   around organizations.  This document proposes expanding the
-   definition of GSSAPI names to deal with these situations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 2]
-
-Internet-Draft            GSS Name Attributes               October 2004
-
-
-1.  Introduction
-
-   The Generic  Security Services API [1] provides a function called
-   gss_export_name that will flatten a GSSAPI name  into a binary blob
-   suitable for comparisons.  This binary blob can be stored on ACLs and
-   then authorization decisions can be made simply by comparing the name
-   exported from a newly accepted context to the name on the ACL.
-
-   As a side effect of this model, each mechanism name needs to be able
-   to be represented in a single canonical form and anyone importing
-   that name needs to be able to retrieve the canonical form.
-
-   Several security mechanisms have been proposed for which this naming
-   architecture is too restrictive.  In some cases it is not always
-   possible to canonicalize any name that is imported.  In other cases
-   there is no single canonical name.  In addition, there is a desire to
-   have more complex authorization models  in GSSAPI than the current
-   name based authorization model.
-
-   This draft discusses two different cases where the current GSSAPI
-   naming seems inadequate.  Two proposals that have been discussed
-   within the IETF Kitten community are discussed.  Finally, the
-   problems that need to be resolved to adopt either of these proposals
-   are discussed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 3]
-
-Internet-Draft            GSS Name Attributes               October 2004
-
-
-2.  Kerberos Naming
-
-   The Kerberos Referrals draft [2] proposes a new type of Kerberos name
-   called an enterprise name.  The intent is that the enterprise name is
-   an alias that the user knows for themselves and can use to login.
-   The Kerberos KDC translates this name into a normal Kerberos
-   principal and gives the user tickets for this principal.  This normal
-   principal is used for authorization.  The intent is that the
-   enterprise name tracks the user as they move throughout the
-   organization, even if they move to parts of the organization that
-   have different naming policies.  The name they type at login remains
-   constant, but the Kerberos principal used to authenticate them to
-   services changes.
-
-   Performing a mapping from enterprise  name to principal name is not
-   generally possible for unauthenticated services.  So in order to
-   canonicalize an enterprise name to get a principal, a service must
-   have credentials.  However it may not be desirable to allow services
-   to map enterprise names to principal names in the general case.
-   Also, Kerberos does not (and does not plan to) provide a mechanism
-   for mapping enterprise names to principals besides authentication as
-   the enterprise name.  So any such mapping would be vendor-specific.
-   With this feature in Kerberos, it is not possible to implement
-   gss_canonicalize_name for enterprise name types.
-
-   Another issue arises with enterprise names.  IN some cases it would
-   be desirable to put   the enterprise name on the ACL instead of a
-   principal name.  Thus, it would be desirable to include the
-   enterprise name in the name exported by gss_export_name.  However
-   then the exported name would change whenever the mapping changed,
-   defeating the purpose  of including the enterprise name.  So in some
-   cases it would be desirable to have the exported name be based on the
-   enterprise name and in others based on the principal name, but this
-   is not currently possible.
-
-   Another development also complicates GSSAPI naming for Kerberos.
-   Several vendors have been looking at mechanisms to include group
-   membership information in Kerberos authorization data.  It is
-   desirable to put these group names on ACLs.  Again, GSSAPI currently
-   has no mechanism to use this information.
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 4]
-
-Internet-Draft            GSS Name Attributes               October 2004
-
-
-3.  X.509 Names
-
-   X.509 names are at least as complex as Kerberos names.  It seems like
-   you might want to use the subject name as the name to be exported in
-   a GSSAPI mechanism.  However RFC 3280 [3] does not even require the
-   subject name to be a non-empty sequence.  Instead there are cases
-   where the subjectAltName extension is the only thing to identify the
-   subject of the certificate.  As in the case of Kerberos group
-   memberships, there may be many subjectAltName extensions available in
-   a certificate.  Different applications will care about different
-   extensions.  Thus there is no single value that can be  defined as
-   the exported GSSAPI name that will be generally useful.
-
-   A profile of a particular X.509  GSSAPI mechanism could require a
-   specific name be used.  However this would limit that mechanism to
-   require a particular type of certificate.  There is interest in being
-   able to use arbitrary X.509 certificates with GSSAPI for some
-   applications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 5]
-
-Internet-Draft            GSS Name Attributes               October 2004
-
-
-4.  Composite Names
-
-   One proposal to solve these problems is to extend the concept of a
-   GSSAPI name to include a set of name attributes.  Each attribute
-   would be an octet-string labeled by an OID.  Examples of attributes
-   would include Kerberos enterprise names, group memberships in an
-   authorization infrastructure, Kerberos authorization data attributes
-   and subjectAltName attributes in a certificate.  Several new
-   operations would be needed:
-   1.  Add attribute to name
-   2.  Query attributes of name
-   3.  Query values of an attribute
-   4.  Delete an attribute from a name
-
-4.1  Usage of Name Attributes
-
-   Since attributes are part of GSSAPI names, the acceptor can retrieve
-   the attributes of the initiator's name from the context.  These
-   attributes can then be used for authorization.
-
-   Most name attributes will probably not come from explicit operations
-   to add attributes to a name.  Instead, name attributes will probably
-   come from mechanism specific credentials.  Mechanism specific naming
-   and group membership can be  mapped into name attributes by the
-   mechanism implementation.  The specific form of this mapping will
-   general require protocol specification for each mechanism.
-
-4.2  Open issues
-
-   This section describes parts of the proposal to add attributes to
-   names that will need to be explored before the proposal can become a
-   protocol specification.
-
-   Are mechanisms expected to be able to carry arbitrary name attributes
-   as part of a context establishment?   At first it seems like this
-   would be desirable.  However the point of GSSAPI is to establish an
-   authenticated context between two peers.  In particular, a context
-   authenticates two named entities to each other.  The names of these
-   entities and attributes associated with these names will be used for
-   authorization decisions.  If an initiator or acceptor is allowed to
-   assert name attributes and the authenticity of these assertions is
-   not validated by the mechanisms, then security problems may result.
-   On the other hand, requiring that name attributes be mechanism
-   specific and only be carried by mechanisms that understand the name
-   attributes and can validate them compromises GSSAPI's place as a
-   generic API.  Application authors would be forced to understand
-   mechanism-specific attributes to make authorization decisions.  In
-   addition if mechanisms are not required to transport arbitrary
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 6]
-
-Internet-Draft            GSS Name Attributes               October 2004
-
-
-   attributes, then application authors will need to deal with different
-   implementations of the same mechanism that support different sets of
-   name attributes.  One possible solution is to carry a source along
-   with each name attribute; this source could indicate whether the
-   attribute comes from a mechanism data structure or from the other
-   party in the authentication.
-
-   Another related question is how will name attributes be mapped into
-   their mechanism-specific forms.  For example it would be desirable to
-   map many  Kerberos authorization data elements into name attributes.
-   In the case of the Microsoft PAC, it would be desirable for some
-   applications to get the entire PAC.  However in many cases, the
-   specific lists of security IDs contained in the PAC would be more
-   directly useful to an application.  So there may not be a good
-   one-to-one mapping between the mechanism-specific elements and the
-   representation desirable at the GSSAPI layer.
-
-   Specific name matching rules need to be developed.  How do names with
-   attributes compare?  What is the effect of a name attribute on a
-   target name in gss_accept_sec_context?
-
-4.3  Handling gss_export_name
-
-   For many mechanisms, there will be  an obvious choice to use for the
-   name exported by gss_export_name.  For example in the case of
-   Kerberos, the principal name can continue to be used as the exported
-   name.  This will allow applications depending on existing GSSAPI
-   name-based authorization to continue to work.  However it is probably
-   desirable to allow GSSAPI mechanisms for which gss_export_name cannot
-   meaningfully be defined.  The behavior of gss_export_name in such
-   cases should probably be to return some error.  Such mechanisms may
-   not work with existing applications and cannot conform to the current
-   version of the GSSAPI.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 7]
-
-Internet-Draft            GSS Name Attributes               October 2004
-
-
-5.  Credential Extensions
-
-   An alternative to the name attributes proposal  is to extend GSSAPI
-   credentials  with extensions labeled by OIDs.  Interfaces would be
-   needed to manipulate these credential extensions and to retrieve the
-   credential extensions for credentials used to establish a context.
-   Even if name attributes are used, credential extensions may be useful
-   for other unrelated purposes.
-
-   It is possible to solve problems discussed in this document using
-   some credential extension mechanism.  Doing so will have many of the
-   same open issues as discussed in the  name attributes proposal.  The
-   main advantage of a credential extensions proposal is that  it avoids
-   specifying how name attributes interact with name comparison or
-   target names.
-
-   The primary advantage of the name attributes proposal over credential
-   extensions is that name attributes seem to fit better into the GSSAPI
-   authorization model.  Names are already available at all points when
-   authorization decisions are made.  In addition, for many mechanisms
-   the sort of information carried as name attributes will also be
-   carried as part of the name in the mechanism
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 8]
-
-Internet-Draft            GSS Name Attributes               October 2004
-
-
-6.  Mechanisms for Export Name
-
-   Another proposal is to define some GSSAPI mechanisms whose only
-   purpose is to have an exportable name form that is useful.  For
-   example, you might be able to export a name as a local machine user
-   ID with such a mechanism.
-
-   This solution works well especially for name information that can be
-   looked up in a directory.  It was unclear from the discussion whether
-   this solution would allow mechanism-specific name information to be
-   extracted from a context.  If so, then this solution would meet many
-   of the goals of this document.
-
-   One advantage of this solution is that it requires few if any changes
-   to GSSAPI semantics.  It is not as flexible as other solutions.
-   Also, it is not clear how to handle mechanisms that do not have a
-   well defined name to export with this solution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 9]
-
-Internet-Draft            GSS Name Attributes               October 2004
-
-
-7.  Security Considerations
-
-   GSSAPI sets up a security context between two named parties.  The
-   GSSAPI names are security assertions that are authenticated by the
-   context establishment process.  As such  the GSS naming architecture
-   is critical to the security of GSSAPI.
-
-   Currently GSSAPI uses a simplistic naming model for authorization.
-   Names can be compared  against a set of names on an access control
-   list.  This architecture is relatively simple and its security
-   properties are well understood.  However it does not provide the
-   flexibility and feature set for future deployments of GSSAPI.
-
-   This proposal will significantly increase the complexity of the GSS
-   naming architecture.  As this proposal is fleshed out, we need to
-   consider ways of managing security exposures created by this
-   increased complexity.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                [Page 10]
-
-Internet-Draft            GSS Name Attributes               October 2004
-
-
-8.  Acknowledgements
-
-   John Brezak, Paul Leach and Nicolas Williams all participated in
-   discussions that defined the problem this proposal attempts to solve.
-   Nicolas Williams and I discussed details of proposals to solve this
-   problem.  However the details and open issues presented here have
-   only been reviewed by me and so I am responsible for their errors.
-
-9  Informative References
-
-   [1]  Linn, J., "Generic Security Service Application Program
-        Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [2]  Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating
-        KDC Referrals to locate Kerberos realms",
-        draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress),
-        2004.
-
-   [3]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
-        Public Key Infrastructure Certificate and Certificate Revocation
-        List (CRL) Profile", rfc 3280, April 2002.
-
-
-Author's Address
-
-   Sam Hartman
-   MIT
-
-   EMail: hartmans@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                [Page 11]
-
-Internet-Draft            GSS Name Attributes               October 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Hartman                  Expires April 24, 2005                [Page 12]
-
-
diff --git a/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt b/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt
deleted file mode 100644
index 89e64524c..000000000
--- a/doc/standardisation/draft-hornstein-dhc-kerbauth-02.txt
+++ /dev/null
@@ -1,1594 +0,0 @@
-
-DHC Working Group                                          Ken Hornstein
-INTERNET-DRAFT                                                       NRL
-Category: Standards Track                                      Ted Lemon
-<draft-hornstein-dhc-kerbauth-02.txt>             Internet Engines, Inc.
-20 February 2000                                           Bernard Aboba
-Expires: September 1, 2000                                     Microsoft
-                                                        Jonathan Trostle
-                                                           Cisco Systems
-
-                   DHCP Authentication Via Kerberos V
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-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."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-The distribution of this memo is unlimited.
-
-1.  Copyright Notice
-
-Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-2.  Abstract
-
-The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for
-host configuration. In some circumstances, it is useful for the DHCP
-client and server to be able to mutually authenticate as well as to
-guarantee the integrity of DHCP packets in transit.  This document
-describes how Kerberos V may be used in order to allow a DHCP client and
-server to mutually authenticate as well as to protect the integrity of
-the DHCP exchange. The protocol described in this document is capable of
-handling both intra-realm and inter-realm authentication.
-
-
-
-
-
-
-Hornstein, et al.            Standards Track                    [Page 1]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-3.  Introduction
-
-The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for
-host configuration. In some circumstances, it is useful for the DHCP
-client and server to be able to mutually authenticate as well as to
-guarantee the integrity of DHCP packets in transit.  This document
-describes how Kerberos V may be used in order to allow a DHCP client and
-server to mutually authenticate as well as to protect the integrity of
-the DHCP exchange.  The protocol described in this document is capable
-of handling both intra-realm and inter-realm authentication.
-
-3.1.  Terminology
-
-This document uses the following terms:
-
-DHCP client
-          A DHCP client or "client" is an Internet host using DHCP to
-          obtain configuration parameters such as a network address.
-
-DHCP server
-          A DHCP server or "server" is an Internet host that returns
-          configuration parameters to DHCP clients.
-
-Home KDC  The KDC corresponding to the DHCP client's realm.
-
-Local KDC The KDC corresponding to the DHCP server's realm.
-
-3.2.  Requirements language
-
-In this document, the key words "MAY", "MUST,  "MUST  NOT",  "optional",
-"recommended",  "SHOULD",  and  "SHOULD  NOT",  are to be interpreted as
-described in [1].
-
-4.  Protocol overview
-
-In DHCP authentication via Kerberos V, DHCP clients and servers utilize
-a Kerberos session key in order to compute a message integrity check
-value included within the DHCP authentication option. The message
-integrity check serves to authenticate as well as integrity protect the
-messages, while remaining compatible with the operation of a DHCP relay.
-Replay protection is also provided by a replay counter within the
-authentication option, as described in [3].
-
-Each server maintains a list of session keys and identifiers for
-clients, so that the server can retrieve the session key and identifier
-used by a client to which the server has provided previous configuration
-information.  Each server MUST save the replay counter from the previous
-authenticated message. To avoid replay attacks, the server MUST discard
-
-
-
-Hornstein, et al.            Standards Track                    [Page 2]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-any incoming message whose replay counter is not strictly greater than
-the replay counter from the previous message.
-
-DHCP authentication, described in [3], must work within the existing
-DHCP state machine described in [4].  For a client in INIT state, this
-means that the client must obtain a valid TGT, as well as a session key,
-within the two round-trips provided by the
-DHCPDISCOVER/OFFER/REQUEST/ACK sequence.
-
-In INIT state, the DHCP client submits an incomplete AS_REQ to the DHCP
-server within the DHCPDISCOVER message.  The DHCP server then completes
-the AS_REQ using the IP address to be assigned to the client, and
-submits this to the client's home KDC in order to obtain a TGT on the
-client's behalf. Once the home KDC responds with an AS_REP, the DHCP
-server extracts the client TGT and submits this along with its own TGT
-to the home KDC, in order to obtain a user-to-user ticket to the DHCP
-client. The AS_REP as well as the AP_REQ are included by the DHCP server
-in the DHCPOFFER. The DHCP client can then decrypt the AS_REP to obtain
-a home realm TGT and TGT session key, using the latter to decrypt the
-user-to-user ticket to obtain the user-to-user session key. It is the
-user-to-user session key that is used to authenticate and integrity
-protect the client's DHCPREQUEST, and DHCPDECLINE messages. Similarly,
-this same session key is used to compute the integrity attribute in the
-server's DHCPOFFER, DHCPACK and DHCPNAK messages, as described in [3].
-
-In the INIT-REBOOT, REBINDING, or RENEWING states, the server can submit
-the home realm TGT in the DHCPREQUEST, along with authenticating and
-integrity protecting the message using an integrity attribute within the
-authentication option. The integrity attribute is computed using the
-existing session key.  The DHCP server can then return a renewed user-
-to-user ticket within the DHCPACK message. The authenticated DHCPREQUEST
-message from a client in INIT-REBOOT state can only be validated by
-servers that used the same session key to compute the integrity
-attribute in their DHCPOFFER messages.
-
-Other servers will discard the DHCPREQUEST messages. Thus, only servers
-that used the user-to-user session key selected by the client will be
-able to determine that their offered configuration information was not
-selected, returning the offered network address to the server's pool of
-available addresses.  The servers that cannot validate the DHCPREQUEST
-message will eventually return their offered network addresses to their
-pool of available addresses as described in section 3.1 of the DHCP
-specification [4].
-
-When sending a DHCPINFORM, there are two possible procedures.  If the
-client knows the DHCP server it will be interacting with, then it can
-obtain a ticket to the DHCP server from the local realm KDC. This will
-require obtaining a TGT to its home realm, as well as possibly a cross-
-
-
-
-Hornstein, et al.            Standards Track                    [Page 3]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-realm TGT to the local realm if the local and home realms differ. Once
-the DHCP client has a local realm TGT, it can then request a DHCP server
-ticket in a TGS_REQ. The DHCP client can then include AP_REQ and
-integrity attributes within the DHCPINFORM. The integrity attribute is
-computed as described in [3], using the session key obtained from the
-TGS_REP. The DHCP server replies with a DHCPACK/DHCPNAK, authenticated
-using the same session key.
-
-If the DHCP client does not know the DHCP server it is interacting with
-then it will not be able to obtain a ticket to it and a different
-procedure is needed.  In this case, the client will include in the
-DHCPINFORM an authentication option with a ticket attribute containing
-its home realm TGT. The DHCP server will then use this TGT in order to
-request a user-to-user ticket from the home KDC in a TGS_REQ.  The DHCP
-server will return the user-to-user ticket and will authenticate and
-integrity protect the DHCPACK/DHCPNAK message. This is accomplished by
-including AP_REQ and integrity attributes within the authentication
-option included with the DHCPACK/DHCPNAK messages.
-
-In order to support the DHCP client's ability to authenticate the DHCP
-server in the case where the server name is unknown, the Kerberos
-principal name for the DHCP server must be of type KRB_NT_SRV_HST with
-the service name component equal to 'dhcp'. For example, the DHCP server
-principal name for the host srv.foo.org would be of the form
-dhcp/srv.foo.org.  The client MUST validate that the DHCP server
-principal name has the above format. This convention requires that the
-administrator ensure that non-DHCP server principals do not have names
-that match the above format.
-
-4.1.  Authentication Option Format
-
-A summary of the authentication option  format for DHCP authentication
-via Kerberos V is shown below.  The fields are transmitted from left to
-right.
-
-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
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|     Code      |     Length    |   Protocol    | Algorithm     |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                      Global Replay Counter                    |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                      Global Replay Counter                    |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                           Attributes...
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-Code
-
-
-
-Hornstein, et al.            Standards Track                    [Page 4]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-   TBD - DHCP Authentication
-
-Length
-
-   The length field is a single octet and indicates the length of the
-   Protocol, Algorith, and Authentication Information fields.  Octets
-   outside the range of the length field should be ignored on reception.
-
-Protocol
-
-   TBD - DHCP Kerberos V authentication
-
-Algorithm
-
-   The algorithm field is a single octet and defines the specific
-   algorithm to be used for computation of the authentication option.
-   Values for the field are as follows:
-
-   0 - reserved
-   1 - HMAC-MD5
-   2 - HMAC-SHA
-   3 - 255 reserved
-
-Global Replay Counter
-
-   As described in [3], the global replay counter field is 8 octets in
-   length. It MUST be set to the value of a monotonically increasing
-   counter. Using a counter value such as the current time of day (e.g.,
-   an NTP-format timestamp [10]) can reduce the danger of replay
-   attacks.
-
-Attributes
-
-   The attributes field consists of type-length-value attributes of the
-   following format:
-
-   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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |     Type      |  Reserved     |       Payload Length          |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                           Attribute value...
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-Type
-   The type field is a single octet and is defined as follows:
-
-   0  - Integrity check
-
-
-
-Hornstein, et al.            Standards Track                    [Page 5]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-   1  - TICKET
-   2  - Authenticator
-   3  - EncTicketPart
-   10 - AS_REQ
-   11 - AS_REP
-   12 - TGS_REQ
-   13 - TGS_REP
-   14 - AP_REQ
-   15 - AP_REP
-   20 - KRB_SAFE
-   21 - KRB_PRIV
-   22 - KRB_CRED
-   25 - EncASRepPart
-   26 - EncTGSRepPart
-   27 - EncAPRepPart
-   28 - EncKrbPrvPart
-   29 - EncKrbCredPart
-   30 - KRB_ERROR
-
-   Note that the values of the Type field are the same as in the
-   Kerberos MSG-TYPE field. As a result, no new number spaces are
-   created for IANA administration.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornstein, et al.            Standards Track                    [Page 6]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-   The following attribute types are allowed within the following
-   messages:
-
-   DISCOVER  OFFER  REQUEST  DECLINE   #    Attribute
-   --------------------------------------------------------
-      0        1       1        1      0    Integrity check
-      0        0      0-1       0      1    Ticket
-      1        0       0        0     10    AS_REQ
-      0        1       0        0     11    AS_REP
-      0        1       0        0     14    AP_REQ
-      0       0-1      0        0     30    KRB_ERROR
-
-   RELEASE   ACK   NAK    INFORM   INFORM      #    Attribute
-                          w/known  w/unknown
-                          server   server
-   ---------------------------------------------------------------
-      1       1     1        1        0        0    Integrity check
-      0       0     0        0        1        1    Ticket
-      0       0     0        0        0       10    AS_REQ
-      0       0     0        0        0       11    AS_REP
-      0      0-1    0        1        0       14    AP_REQ
-      0       0    0-1       0        0       30    KRB_ERROR
-
-4.2.  Client behavior
-
-The following section, which incorporates material from [3], describes
-client behavior in detail.
-
-4.2.1.  INIT state
-
-When in INIT state, the client behaves as follows:
-
-
-[1]  As described in [3], the client MUST include the authentication
-     request option in its DHCPDISCOVER message along with option 61
-     [11] to identify itself uniquely to the server. An AS_REQ attribute
-     MUST be included within the authentication request option. This
-     (incomplete) AS_REQ will set the FORWARDABLE and RENEWABLE flags
-     and MAY include pre-authentication data (PADATA) if the client
-     knows what PADATA its home KDC will require. The ADDRESSES field in
-     the AS_REQ will be ommitted since the client does not yet know its
-     IP address. The ETYPE field will be set to an encryption type that
-     the client can accept.
-
-[2]  The client MUST validate DHCPOFFER messages that include an
-     authentication option. Messages including an authentication option
-     with a KRB_ERROR attribute and no integrity attribute are treated
-     as though they are unauthenticated. More typically, authentication
-
-
-
-Hornstein, et al.            Standards Track                    [Page 7]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-     options within the DHCPOFFER message will include AS_REP, AP_REQ,
-     and integrity attributes. To validate the authentication option,
-     the client decrypts the enc-part of the AS_REP in order to obtain
-     the TGT session key. This is used to decrypt the enc-part of the
-     AP_REQ in order to obtain the user-to-user session key. The user-
-     to-user session key is then used to compute the message integrity
-     check as described in [3], and the computed value is compared to
-     the value within the integrity attribute. The client MUST discard
-     any messages which fail to pass validation and MAY log the
-     validation failure.
-
-     As described in [3], the client selects one DHCPOFFER message as
-     its selected configuration. If none of the DHCPOFFER messages
-     received by the client include an authentication option, the client
-     MAY choose an unauthenticated message as its selected
-     configuration.  DHCPOFFER messages including an authentication
-     option with a KRB_ERROR attribute and no integrity attribute are
-     treated as though they are unauthenticated.  The client SHOULD be
-     configurable to accept or reject unauthenticated DHCPOFFER
-     messages.
-
-[3]  The client replies with a DHCPREQUEST message that MUST include an
-     authentication option. The authentication option MUST include an
-     integrity attribute, computed as described in [3], using the user
-     to user session key recovered in step 2.
-
-[4]  As noted in [3], the client MUST validate a DHCPACK message from
-     the server that includes an authentication option. DHCPACK or
-     DHCPNAK messages including an authentication option with a
-     KRB_ERROR attribute and no integrity attribute are treated as
-     though they are unauthenticated. The client MUST silently discard
-     the DHCPACK if the message fails to pass validation and MAY log the
-     validation failure. If the DHCPACK fails to pass validation, the
-     client MUST revert to the INIT state and return to step 1. The
-     client MAY choose to remember which server replied with an invalid
-     DHCPACK message and discard subsequent messages from that server.
-
-4.2.2.  INIT-REBOOT state
-
-When in INIT-REBOOT state, if the user-to-user ticket is still valid,
-the client MUST re-use the session key from the DHCP server user-to-user
-ticket in its DHCPREQUEST message. This is used to generate the
-integrity attribute contained within the authentication option, as
-described in [3]. In the DHCPREQUEST, the DHCP client also includes its
-home realm TGT in a ticket attribute in the authentication option in
-order to assist the DHCP server in renewing the user-to-user ticket.  To
-ensure that the user-to-user ticket remains valid throughout the DHCP
-lease period so that the renewal process can proceed, the Kerberos
-
-
-
-Hornstein, et al.            Standards Track                    [Page 8]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-ticket lifetime SHOULD be set to exceed the DHCP lease time.  If the
-user-to-user ticket is expired, then the client MUST return to the INIT
-state.
-
-The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages
-if no authenticated messages were received. DHCPACK/DHCPNAK messages
-with an authentication option containing a KRB_ERROR attribute and no
-integrity attribute are treated as though they are unauthenticated. The
-client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
-messages as specified in section 3.2 of the DHCP specification [4].
-
-4.2.3.  RENEWING state
-
-When in RENEWING state, the DHCP client can be assumed to have a valid
-IP address, as well as a TGT to the home realm, a user-to-user ticket
-provided by the DHCP server, and a session key with the DHCP server, all
-obtained during the original DHCP conversation.  If the user-to-user
-ticket is still valid, the client MUST re-use the session key from the
-user-to-user ticket in its DHCPREQUEST message to generate the integrity
-attribute contained within the authentication option.
-
-Since the DHCP client can renew the TGT to the home realm, it is
-possible for it to continue to hold a valid home realm TGT.  However,
-since the DHCP client did not obtain the user-to-user ticket on its own,
-it will need to rely on the DHCP server to renew this ticket. In the
-DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket
-attribute in the authentication option in order to assist the DHCP
-server in renewing the user-to-user ticket.
-
-If the DHCP server user-to-user ticket is expired, then the client MUST
-return to INIT state.  To ensure that the user-to-user ticket remains
-valid throughout the DHCP lease period so that the renewal process can
-proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP
-lease time.  If client receives no DHCPACK messages or none of the
-DHCPACK messages pass validation, the client behaves as if it had not
-received a DHCPACK message in section 4.4.5 of the DHCP specification
-[4].
-
-4.2.4.  REBINDING state
-
-When in REBINDING state, the DHCP client can be assumed to have a valid
-IP address, as well as a TGT to the home realm, a user-to-user ticket
-and a session key with the DHCP server, all obtained during the original
-DHCP conversation.  If the user-to-user ticket is still valid, the
-client MUST re-use the session key from the user-to-user ticket in its
-DHCPREQUEST message to generate the integrity attribute contained within
-the authentication option, as described in [3].
-
-
-
-
-Hornstein, et al.            Standards Track                    [Page 9]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-Since the DHCP client can renew the TGT to the home realm, it is
-possible for it to continue to hold a valid home realm TGT.  However,
-since the DHCP client did not obtain the user-to-user ticket on its own,
-it will need to rely on the DHCP server to renew this ticket. In the
-DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket
-attribute in the authentication option in order to assist the DHCP
-server in renewing the user-to-user ticket.
-
-If the user-to-user ticket is expired, then the client MUST return to
-INIT state.  To ensure that the user-to-user ticket remains valid
-throughout the DHCP lease period so that the renewal process can
-proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP
-lease time.  If client receives no DHCPACK messages or none of the
-DHCPACK messages pass validation, the client behaves as if it had not
-received a DHCPACK message in section 4.4.5 of the DHCP specification
-[4].
-
-4.2.5.  DHCPRELEASE message
-
-Clients sending a DHCPRELEASE MUST include an authentication option. The
-authentication option MUST include an integrity attribute, computed as
-described in [3], using the user to user session key.
-
-4.2.6.  DHCPDECLINE message
-
-Clients sending a DHCPDECLINE MUST include an authentication option. The
-authentication option MUST include an integrity attribute, computed as
-described in [3], using the user to user session key.
-
-4.2.7.  DHCPINFORM message
-
-Since the client already has some configuration information, it can be
-assumed that it has the ability to obtain a home or local realm TGT
-prior to sending the DHCPINFORM.
-
-If the DHCP client knows which DHCP server it will be interacting with,
-then it SHOULD include an authentication option containing AP_REQ and
-integrity attributes within the DHCPINFORM.  The DHCP client first
-requests a TGT to the local realm via an AS_REQ and then using the TGT
-returned in the AS_REP to request a ticket to the DHCP server from the
-local KDC in a TGS_REQ. The session key obtained from the TGS_REP will
-be used to generate the integrity attribute as described in [3].
-
-If the DHCP client does not know what DHCP server it will be talking to,
-then it cannot obtain a ticket to the DHCP server. In this case, the
-DHCP client MAY send an unauthenticated DHCPINFORM or it MAY include an
-authentication option including a ticket attribute only.  The ticket
-attribute includes a TGT for the home realm. The client MUST validate
-
-
-
-Hornstein, et al.            Standards Track                   [Page 10]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-that the DHCP server name in the received Kerberos AP_REQ message is of
-the form dhcp/.... as described in section 4.
-
-The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages
-if no authenticated messages were received. DHCPACK/DHCPNAK messages
-with an authentication option containing a KRB_ERROR attribute and no
-integrity attribute are treated as though they are unauthenticated. The
-client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
-messages as specified in section 3.2 of the DHCP specification [4].
-
-4.3.  Server behavior
-
-This section, which relies on material from [3], describes the behavior
-of a server in response to client messages.
-
-4.3.1.  After receiving a DHCPDISCOVER message
-
-For installations where IP addresses are required within tickets, the
-DHCP server MAY complete the AS_REQ by filling in the ADDRESSES field
-based on the IP address that it will include in the DHCPOFFER.  The DHCP
-server sends the AS_REQ to the home KDC with the FORWARDABLE flag set.
-The home KDC then replies to the DHCP server with an AS_REP.  The DHCP
-server extracts the client TGT from the AS_REP and forms a TGS_REQ,
-which it sends to  the home KDC.
-
-If the DHCP server and client are in different realms, then the DHCP
-server will need to obtain a TGT to the home realm from the KDC of its
-own (local) realm prior to sending the TGS_REQ. The TGS_REQ includes the
-DHCP server's TGT within the home realm, has the ENC-TKT-IN-SKEY flag
-set and includes the client home realm TGT in the ADDITIONAL-TICKETS
-field, thus requesting a user-to ticket to the DHCP client.  The home
-KDC then returns a user-to-user ticket in a TGS_REP. The user-to-user
-ticket is encrypted in the client's home realm TGT session key.
-
-In order to recover the user-to-user session key, the DHCP server
-decrypts the enc-part of the TGS_REP. To accomplish this, the DHCP
-server uses the session key that it shares with the home realm, obtained
-in the AS_REQ/AS_REP conversation that it used to obtain its own TGT to
-the home realm.
-
-The DHCP server then sends a DHCPOFFER to the client, including AS_REP,
-AP_REQ and integrity attributes within the authentication option.  The
-AS_REP attribute encapsulates the AS_REP sent to the DHCP server by the
-home KDC. The AP_REQ attribute includes an AP_REQ constructed by the
-DHCP server based on the TGS_REP sent to it by the home KDC. The server
-also includes an integrity attribute generated as specified in [3] from
-the user-to-user session key.  The server MUST record the user-to-user
-session key selected for the client and use that session key for
-
-
-
-Hornstein, et al.            Standards Track                   [Page 11]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-validating subsequent messages with the client.
-
-4.3.2.  After receiving a DHCPREQUEST message
-
-The DHCP server uses the user-to-user session key in order to validate
-the integrity attribute contained within the authentication option,
-using the method specified in [3]. If the message fails to pass
-validation, it MUST discard the message and MAY choose to log the
-validation failure.
-
-If the message passes the validation procedure, the server responds as
-described in [4], including an integrity attribute computed as specified
-in [3] within the DHCPACK or DHCPNAK message.
-
-If the authentication option included within the DHCPREQUEST message
-contains a ticket attribute then the DHCP server will use the home realm
-TGT included in the ticket attribute in order to renew the user-to-user
-ticket, which it returns in an AP_REQ attribute within the DHCPACK.
-DHCPACK or DHCPNAK messages then include an integrity attribute
-generated as specified in [3], using the new user-to-user session key
-included within the AP_REQ.
-
-4.3.3.  After receiving a DHCPINFORM message
-
-The server MAY choose to accept unauthenticated DHCPINFORM messages, or
-only accept authenticated DHCPINFORM messages based on a site policy.
-
-When a client includes an authentication option in a DHCPINFORM message,
-the server MUST respond with an authenticated DHCPACK or DHCPNAK
-message. If the DHCPINFORM message includes an authentication option
-including AP_REQ and integrity attributes, the DHCP server decrypts the
-AP_REQ attribute and then recovers the session key. The DHCP server than
-validates the integrity attribute included in the authentication option
-using the session key. If the integrity attribute is invalid then the
-DHCP server MUST silently discard the DHCPINFORM message.
-
-If the authentication option only includes a ticket attribute and no
-integrity or AP_REQ attributes, then the DHCP server should assume that
-the client needs the server to obtain a user-to-user ticket from the
-home realm KDC.  In this case, the DHCP server includes the client home
-realm TGT and its own home realm TGT in a TGS_REQ to the home realm KDC.
-It then receives a user-to-user ticket from the home realm KDC in a
-TGS_REP. The DHCP server will then include AP_REQ and integrity
-attributes within the DHCPACK/DHCPNAK.
-
-If the client does not include an authentication option in the
-DHCPINFORM, the server can either respond with an unauthenticated
-DHCPACK message, or a DHCPNAK if the server does not accept
-
-
-
-Hornstein, et al.            Standards Track                   [Page 12]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-unauthenticated clients.
-
-4.3.4.  After receiving a DHCPRELEASE message
-
-The DHCP server uses the session key in order to validate the integrity
-attribute contained within the authentication option, using the method
-specified in [3]. If the message fails to pass validation, it MUST
-discard the message and MAY choose to log the validation failure.
-
-If the message passes the validation procedure, the server responds as
-described in [4], marking the client's network address as not allocated.
-
-4.3.5.  After receiving a DHCPDECLINE message
-
-The DHCP server uses the session key in order to validate the integrity
-attribute contained within the authentication option, using the method
-specified in [3]. If the message fails to pass validation, it MUST
-discard the message and MAY choose to log the validation failure.
-
-If the message passes the validation procedure, the server proceeds as
-described in [4].
-
-4.4.  Error handling
-
-When an error condition occurs during a Kerberos exchange, Kerberos
-error messages can be returned by either side.  These Kerberos error
-messages MAY be logged by the receiving and sending parties.
-
-In some cases, it may be possible for these error messages to be
-included within the authentication option via the KRB_ERROR attribute.
-However, in most cases, errors will result in messages being silently
-discarded and so no response will be returned.
-
-For example, if the home KDC returns a KRB_ERROR in response to the
-AS_REQ submitted by the DHCP server on the client's behalf, then the
-DHCP server will conclude that the DHCPDISCOVER was not authentic, and
-will silently discard it.
-
-However, if the AS_REQ included PADATA and the home KDC responds with an
-AS_REP, then the DHCP server can conclude that the client is authentic.
-If the subsequent TGS_REQ is unsuccessful, with a KRB_ERROR returned by
-the home KDC in the TGS_REP, then the fault may lie with the DHCP server
-rather than with the client. In this case, the DHCP server MAY choose to
-return a KRB_ERROR within the authentication option included in the
-DHCPOFFER. The client will then treat this as an unauthenticated
-DHCPOFFER.
-
-
-
-
-
-Hornstein, et al.            Standards Track                   [Page 13]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-Similarly, if the integrity attribute contained in the DHCPOFFER proves
-invalid, the client will silently discard the DHCPOFFER and instead
-accept an offer from another server if one is available. If the
-integrity attribute included in the DHCPACK/DHCPNAK proves invalid, then
-the client behaves as if it did not receive a DHCPACK/DHCPNAK.
-
-When in INIT-REBOOT, REBINDING or RENEWING state, the client will
-include a ticket attribute and integrity attribute within the
-authentication option of the DHCPREQUEST, in order to assist the DHCP
-server in renewing the user-to-user ticket.  If the integrity attribute
-is invalid, then the DHCP server MUST silently discard the DHCPREQUEST.
-
-However, if the integrity attribute is successfully validated by the
-DHCP server, but the home realm TGT included in the ticket attribute is
-invalid (e.g. expired), then the DHCP server will receive a KRB_ERROR in
-response to its TGS_REQ to the home KDC.  In this case, the DHCP server
-MAY respond with a DHCPNAK including a KRB_ERROR attribute and no
-integrity attribute within the authentication option. This will force
-the client back to the INIT state, where it can receive a valid home
-realm TGT.
-
-Where the client included PADATA in the AS_REQ attribute of the
-authentication option within the DHCPDISCOVER and the AS_REQ was
-successfully validated by the KDC, the DHCP server will conclude that
-the DHCP client is authentic. In this case if the client successfully
-validates the integrity attribute in the DHCPOFFER, but the server does
-not validate the integrity attribute in the client's DHCPREQUEST, the
-server MAY choose to respond with an authenticated DHCPNAK containing a
-KRB_ERROR attribute.
-
-4.5.  PKINIT issues
-
-When public key authentication is supported with Kerberos as described
-in [8], the client certificate and a signature accompany the initial
-request in the preauthentication fields.  As a result, it is conceivable
-that the incomplete AS_REQ included in the DHCPDISCOVER packet may
-exceed the size of a single DHCP option, or even the MTU size.  As noted
-in [4], a single option may be as large as 255 octets. If the value to
-be passed is larger than this the client concatenates together the
-values of multiple instances of the same option.
-
-4.6.  Examples
-
-4.6.1.  INIT state
-
-In the intra-realm case where the DHCP Kerberos mutual authentication is
-successful, the conversation will appear as follows:
-
-
-
-
-Hornstein, et al.            Standards Track                   [Page 14]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-   DHCP               DHCP
-   Client             Server            KDC
---------------     -------------     ---------
-DHCPDISCOVER
- (Incomplete
- AS_REQ)  ->
-                   AS_REQ ->
-                                      <- AS_REP
-                   TGS_REQ
-                    U-2-U ->
-                                      <- TGS_REP
-                <- DHCPOFFER,
-                    (AS_REP,
-                    AP_REQ,
-                    Integrity)
-DHCPREQUEST
- (Integrity) ->
-                <- DHCPACK
-                    (Integrity)
-
-In the case where the KDC returns a KRB_ERROR in response to the AS_REQ,
-the server will silently discard the DHCPDISCOVER and the conversation
-will appear as follows:
-
-   DHCP               DHCP
-   Client             Server            KDC
---------------     -------------     ---------
-DHCPDISCOVER
- (Incomplete
- AS_REQ)  ->
-                   AS_REQ ->
-                                     <- KRB_ERROR
-
-In the inter-realm case where the DHCP Kerberos mutual authentication is
-successful, the conversation will appear as follows:
-
-   DHCP            DHCP           Home      Local
-   Client          Server         KDC        KDC
---------------  -------------  ---------  ---------
-DHCPDISCOVER
-(Incomplete
- AS_REQ)  ->
-                   AS_REQ ->
-                                <- AS_REP
-                   TGS_REQ ->
-                   (cross realm,
-                   for home
-                   KDC)
-
-
-
-Hornstein, et al.            Standards Track                   [Page 15]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-                                           <- TGS_REP
-
-                   TGS_REQ
-                    U-2-U ->
-                                <- TGS_REP
-                <- DHCPOFFER,
-                    (AS_REP,
-                    AP_REQ,
-                    Integrity)
-DHCPREQUEST
- (Integrity) ->
-                <- DHCPACK
-                    (Integrity)
-
-In the case where the client includes PADATA in the AS_REQ attribute
-within the authentication option of the DHCPDISCOVER and the KDC returns
-an error-free AS_REP indicating successful validation of the PADATA, the
-DHCP server will conclude that the DHCP client is authentic.  If the KDC
-then returns a KRB_ERROR in response to the TGS_REQ, indicating a fault
-that lies with the DHCP server, the server MAY choose not to silently
-discard the DHCPDISCOVER.  Instead it MAY respond with a DHCPOFFER
-including a KRB_ERROR attribute within the authentication option. The
-client will then treat this as an unauthenticated DHCPOFFER.  The
-conversation will appear as follows:
-
-   DHCP               DHCP
-   Client             Server            KDC
---------------     -------------     ---------
-DHCPDISCOVER
- (Incomplete
- AS_REQ
- w/PADATA)  ->
-                   AS_REQ ->
-                                     <- AS_REP
-                   TGS_REQ
-                    U-2-U ->
-                                     <- KRB_ERROR
-                <- DHCPOFFER,
-                    (KRB_ERROR)
-DHCPREQUEST ->
-                <- DHCPACK
-
-In the intra-realm case where the client included PADATA in the AS_REQ
-attribute of the authentication option and the AS_REQ was successfully
-validated by the KDC, the DHCP server will conclude that the DHCP client
-is authentic. In this case if the client successfully validates the
-integrity attribute in the DHCPOFFER, but the server does not validate
-the integrity attribute in the client's DHCPREQUEST, the server MAY
-
-
-
-Hornstein, et al.            Standards Track                   [Page 16]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-choose to respond with an authenticated DHCPNAK containing a KRB_ERROR
-attribute.  The conversation will appear as follows:
-
-   DHCP               DHCP
-   Client             Server            KDC
---------------     -------------     ---------
-DHCPDISCOVER
- (Incomplete
- AS_REQ
- w/PADATA)  ->
-                   AS_REQ ->
-                                     <- AS_REP
-                   TGS_REQ
-                    U-2-U ->
-                                     <- TGS_REP
-                <- DHCPOFFER,
-                    (AS_REP,
-                    AP_REQ,
-                    Integrity)
-DHCPREQUEST
- (Integrity) ->
-                <- DHCNAK
-                    (KRB_ERROR,
-                     Integrity)
-DHCPDISCOVER
- (Incomplete
- AS_REQ)  ->
-
-In the intra-realm case where the DHCP client cannot validate the
-integrity attribute in the DHCPOFFER, the client silently discards the
-DHCPOFFER. The conversation will appear as follows:
-
-   DHCP               DHCP
-   Client             Server            KDC
---------------     -------------     ---------
-DHCPDISCOVER
- (Incomplete
- AS_REQ)  ->
-                   AS_REQ ->
-                                     <- AS_REP
-                   TGS_REQ
-                    U-2-U ->
-                                     <- TGS_REP
-                <- DHCPOFFER,
-                   (AS_REP,
-                   AP_REQ,
-                   Integrity)
-DHCPREQUEST
-
-
-
-Hornstein, et al.            Standards Track                   [Page 17]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
- [To another server]
- (Integrity) ->
-
-In the intra-realm case where the DHCP client cannot validate the
-integrity attribute in the DHCPACK, the client reverts to INIT state.
-The conversation will appear as follows:
-
-   DHCP               DHCP
-   Client             Server            KDC
---------------     -------------     ---------
-DHCPDISCOVER
-(Incomplete
- AS_REQ)  ->
-                   AS_REQ ->
-                                     <- AS_REP
-                   TGS_REQ
-                    U-2-U ->
-                                     <- TGS_REP
-                <- DHCPOFFER,
-                    (AS_REP,
-                    AP_REQ,
-                    Integrity)
-DHCPREQUEST
- (Integrity) ->
-                <- DHCPACK
-                    (Integrity)
-DHCPDISCOVER
- (Incomplete
- AS_REQ)  ->
-
-4.6.2.  INIT-REBOOT, RENEWING or REBINDING
-
-In the intra-realm or inter-realm case where the original user-to-user
-ticket is still valid, and the DHCP server still has a valid TGT to the
-home realm, the conversation will appear as follows:
-
-   DHCP               DHCP             Home
-   Client             Server            KDC
---------------     -------------     ---------
-
-DHCPREQUEST
- (TGT,
- Integrity)  ->
-                   TGS_REQ
-                    U-2-U ->
-                                     <- TGS_REP
-                <- DHCPACK
-                    (AP_REQ,
-
-
-
-Hornstein, et al.            Standards Track                   [Page 18]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-                    Integrity)
-
-In the intra-realm or inter-realm case where the DHCP server validates
-the integrity attribute in the DHCPREQUEST, but receives a KRB_ERROR in
-response to the TGS_REQ to the KDC, the DHCP sever MAY choose not to
-silently discard the DHCPREQUEST and MAY return an authenticated DHCPNAK
-to the client instead, using the user-to-user session key previously
-established with the client. The conversation appears as follows:
-
-   DHCP               DHCP             Home
-   Client             Server            KDC
---------------     -------------     ---------
-
-DHCPREQUEST
- (TGT,
- Integrity)  ->
-                   TGS_REQ
-                    U-2-U ->
-                                     <- KRB_ERROR
-                <- DHCPNAK
-                    (KRB_ERROR,
-                    Integrity)
-DHCPDISCOVER
- (Incomplete
- AS_REQ)  ->
-
-In the intra-realm or inter-realm case where the DHCP server cannot
-validate the integrity attribute in the DHCPREQUEST, the DHCP server
-MUST silently discard the DHCPREQUEST and the conversation will appear
-as follows:
-
-   DHCP               DHCP
-   Client             Server            KDC
---------------     -------------     ---------
-
-DHCPREQUEST
- (TGT,
- Integrity)  ->
-                   Silent discard
-[Sequence repeats
- until timeout]
-
-DHCPDISCOVER
- (Incomplete
- AS_REQ)  ->
-
-In the intra-realm or inter-realm case where the original user-to-user
-ticket is still valid, the server validates the integrity attribute in
-
-
-
-Hornstein, et al.            Standards Track                   [Page 19]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-the DHCPREQUEST, but the client fails to validate the integrity
-attribute in the DHCPACK, the client will silently discard the DHCPACK.
-The conversation will appear as follows:
-
-   DHCP               DHCP
-   Client             Server            KDC
---------------     -------------     ---------
-
-DHCPREQUEST
- (TGT,
- Integrity)  ->
-
-                <- DHCPACK
-                    (AP_REQ,
-                    Integrity)
-DHCPDISCOVER
- (Incomplete
- AS_REQ)  ->
-
-4.6.3.  DHCPINFORM (with known DHCP server)
-
-In the case where the DHCP client knows the DHCP server it will be
-interacting with, the DHCP client will obtain a ticket to the DHCP
-server and will include AP_REQ and integrity attributes within the
-DHCPINFORM.
-
-Where the DHCP Kerberos mutual authentication is successful, the
-conversation will appear as follows:
-
-   DHCP               DHCP
-   Client             Server            KDC
---------------     -------------     ---------
-AS_REQ ->
-                                     <- AS_REP
-TGS_REQ ->
-                                     <- TGS_REP
-DHCPINFORM
- (AP_REQ,
- Integrity) ->
-                <- DHCPACK
-                    (Integrity)
-
-In the inter-realm case where the DHCP Kerberos mutual authentication is
-successful, the conversation will appear as follows:
-
-   DHCP            DHCP           Home      Local
-   Client          Server         KDC        KDC
---------------  -------------  ---------  ---------
-
-
-
-Hornstein, et al.            Standards Track                   [Page 20]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-AS_REQ ->
-                                          <- AS_REP
-TGS_REQ ->
-                                          <- TGS_REP
-TGS_REQ ->
-                               <- TGS_REP
-DHCPINFORM
- (AP_REQ,
- Integrity) ->
-                <- DHCPACK
-                    (Integrity)
-
-In the inter-realm case where the DHCP server fails to validate the
-integrity attribute in the DHCPINFORM, the server MUST silently discard
-the DHCPINFORM. The conversation will appear as follows:
-
-   DHCP            DHCP           Home      Local
-   Client          Server         KDC        KDC
---------------  -------------  ---------  ---------
-AS_REQ ->
-                                          <- AS_REP
-TGS_REQ ->
-                                          <- TGS_REP
-TGS_REQ ->
-                               <- TGS_REP
-DHCPINFORM
- (AP_REQ,
- Integrity) ->
-                <- DHCPACK
-                    (Integrity)
-DHCPINFORM
- (AP_REQ,
- Integrity) ->
-
-In the inter-realm case where the DHCP client fails to validate the
-integrity attribute in the DHCPACK, the client MUST silently discard the
-DHCPACK.  The conversation will appear as follows:
-
-   DHCP            DHCP           Home      Local
-   Client          Server         KDC        KDC
---------------  -------------  ---------  ---------
-AS_REQ ->
-                                          <- AS_REP
-TGS_REQ ->
-                                          <- TGS_REP
-TGS_REQ ->
-                               <- TGS_REP
-DHCPINFORM
-
-
-
-Hornstein, et al.            Standards Track                   [Page 21]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
- (AP_REQ,
- Integrity) ->
-
-4.6.4.  DHCPINFORM (with unknown DHCP server)
-
-In the case where the DHCP client does not know the DHCP server it will
-be interacting with, the DHCP client will only include a ticket
-attribute within the DHCPINFORM.  Thus the DHCP server will not be able
-to validate the authentication option.
-
-Where the DHCP client is able to validate the DHCPACK and no error
-occur, the onversation will appear as follows:
-
-   DHCP               DHCP
-   Client             Server            KDC
---------------     -------------     ---------
-AS_REQ ->
-                                     <- AS_REP
-DHCPINFORM
- (Ticket) ->
-                   TGS_REQ
-                    U-2-U ->
-                                     <- TGS_REP
-                <- DHCPACK
-                    (AP_REQ,
-                    Integrity)
-
-In the inter-realm case where the DHCP server needs to obtain a TGT to
-the home realm, and where the client successfully validates the DHCPACK,
-the conversation will appear as follows:
-
-   DHCP            DHCP           Home      Local
-   Client          Server         KDC        KDC
---------------  -------------  ---------  ---------
-AS_REQ ->
-                                          <- AS_REP
-DHCPINFORM
- (Ticket) ->
-                   AS_REQ ->
-                                <- AS_REP
-                   TGS_REQ ->
-                   (cross realm,
-                   for home
-                   KDC)
-                                           <- TGS_REP
-
-                   TGS_REQ
-                    U-2-U ->
-
-
-
-Hornstein, et al.            Standards Track                   [Page 22]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-                                <- TGS_REP
-                <- DHCPACK
-                    (AP_REQ,
-                    Integrity)
-
-In the inter-realm case where the local KDC returns a KRB_ERROR in
-response to the TGS_REQ from the DHCP server, the DHCP server MAY return
-a KRB_ERROR within the DHCP authentication option included in a DHCPNAK.
-The conversation will appear as follows:
-
-   DHCP            DHCP           Home      Local
-   Client          Server         KDC        KDC
---------------  -------------  ---------  ---------
-AS_REQ ->
-                                          <- AS_REP
-DHCPINFORM
- (Ticket) ->
-                   AS_REQ ->
-                                <- AS_REP
-                   TGS_REQ ->
-                   (cross realm,
-                   for home
-                   KDC)
-                                           <- KRB_ERROR
-                <- DHCPNAK
-                    (KRB_ERROR)
-
-
-In the inter-realm case where the DHCP client fails to validate the
-integrity attribute in the DHCPACK, the client MUST silently discard the
-DHCPACK.  The conversation will appear as follows:
-
-   DHCP            DHCP           Home      Local
-   Client          Server         KDC        KDC
---------------  -------------  ---------  ---------
-AS_REQ ->
-                                          <- AS_REP
-DHCPINFORM
- (Ticket) ->
-                   AS_REQ ->
-                                <- AS_REP
-                   TGS_REQ ->
-                   (cross realm,
-                   for home
-                   KDC)
-                                           <- TGS_REP
-
-                   TGS_REQ
-
-
-
-Hornstein, et al.            Standards Track                   [Page 23]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-                    U-2-U ->
-                                <- TGS_REP
-                <- DHCPACK
-                    (AP_REQ,
-                    Integrity)
-DHCPINFORM
- (Ticket) ->
-
-5.  References
-
-
-[1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-     Levels", BCP 14, RFC 2119, March 1997.
-
-[2]  Kohl, J., Neuman, C., "The Kerberos Network Authentication Service
-     (V5)", RFC 1510, September 1993.
-
-[3]  Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
-     Internet draft (work in progress), draft-ietf-dhc-
-     authentication-11.txt, June 1999.
-
-[4]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
-     1997.
-
-[5]  Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
-     Extensions", RFC 2132, March 1997.
-
-[6]  Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
-
-[7]  Jain, V., Congdon, P., Roese, J., "Network Port Authentication",
-     IEEE 802.1 PAR submission, June 1999.
-
-[8]  Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray,
-     J., Trostle, J., "Public Key Cryptography for Initial
-     Authentication in Kerberos", Internet draft (work in progress),
-     draft-ietf-cat-kerberos-pk-init-09.txt, June 1999.
-
-[9]  Tung, B., Ryutov, T., Neuman, C., Tsudik, G., Sommerfeld, B.,
-     Medvinsky, A., Hur, M.,  "Public Key Cryptography for Cross-Realm
-     Authentication in Kerberos", Internet draft (work in progress),
-     draft-ietf-cat-kerberos-pk-cross-04.txt, June 1999.
-
-[10] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March
-     1992.
-
-[11] Henry, M., "DHCP Option 61 UUID Type Definition", Internet draft
-     (work in progress), draft-henry-DHCP-opt61-UUID-type-00.txt,
-     November 1998.
-
-
-
-Hornstein, et al.            Standards Track                   [Page 24]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-6.  Security Considerations
-
-DHCP authentication, described in [3], addresses the following threats:
-
-     Modification of messages
-     Rogue servers
-     Unauthorized clients
-
-This section describes how DHCP authentication via Kerberos V addresses
-each of these threats.
-
-6.1.  Client security
-
-As noted in [3], it may be desirable to ensure that IP addresses are
-only allocated to authorized clients. This can serve to protect against
-denial of service attacks. To address this issue it is necessary for
-DHCP client messages to be authenticated. In order to guard against
-message modification, it is also necessary for DHCP client messages to
-be integrity protected.
-
-Note that this protocol does not make use of KRB_SAFE, so as to allow
-modification of mutable fields by the DHCP relay. Replay protection is
-therefore provided within the DHCP authentication option itself.
-
-In DHCP authentication via Kerberos V the DHCP client will authenticate,
-integrity and replay-protect the DHCPREQUEST, DHCPDECLINE and
-DHCPRELEASE messages using a user-to-user session key obtained by the
-DHCP server from the home KDC. If the DHCP client knows the DHCP server
-it will be interacting with, then the DHCP client MAY also authenticate,
-integrity and replay-protect the DHCPINFORM message using a session key
-obtained from the local realm KDC for the DHCP server it expects to
-converse with.
-
-Since the client has not yet obtained a session key, DHCPDISCOVER
-packets cannot be authenticated using the session key. However, the
-client MAY include pre-authentication data in the PADATA field included
-in the DHCPDISCOVER packet. Since the PADATA will then be used by the
-DHCP server to request a ticket on the client's behalf, the DHCP server
-will learn from the AS_REP whether the PADATA was acceptable or not.
-Therefore in this case, the DHCPDISCOVER will be authenticated but not
-integrity protected.
-
-Where the DHCP client does not know the DHCP server it will be
-interacting with ahead of time, the DHCPINFORM message will not be
-authenticated, integrity or replay protected.
-
-Note that snooping of PADATA and TGTs on the wire may provide an
-attacker with a means of mounting a dictionary attack, since these items
-
-
-
-Hornstein, et al.            Standards Track                   [Page 25]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-are typically encrypted with a key derived from the user's password.
-Thus use of strong passwords and/or pre-authentication methods utilizing
-strong cryptography (see [8]) are recommended.
-
-6.2.  Network access control
-
-DHCP authentication has been proposed as a method of limiting access to
-network media that are not physically secured such as wireless LANs and
-ports in college residence halls.  However, it is not particularly well
-suited to this purpose since even if address allocation is denied an
-inauthentic client may use a statically assigned IP address instead, or
-may attempt to access the network using non-IP protocols.  As a result,
-other methods, described in [6]-[7], have been proposed for controlling
-access to wireless media and switched LANs.
-
-6.3.  Server security
-
-As noted in [3], it may be desirable to protect against rogue DHCP
-servers put on the network either intentionally or by accident.  To
-address this issue it is necessary for DHCP server messages to be
-authenticated. In order to guard against message modification, it is
-also necessary for DHCP server messages to be integrity protected.
-Replay protection is also provided within the DHCP authentication
-option.
-
-All messages sent by the DHCP server are authenticated and integrity and
-replaly protected using a session key.  This includes the DHCPOFFER,
-DHCPACK, and DHCPNAK messages.  The session key is used to compute the
-DHCP authentication option, which is verified by the client.
-
-In order to provide protection against rogue servers it is necessary to
-prevent rogue servers from obtaining the credentials necessary to act as
-a DHCP server. As noted in Section 4, the Kerberos principal name for
-the DHCP server  must be of type KRB_NT_SRV_HST with  the service name
-component equal to 'dhcp'. The client MUST validate that the DHCP server
-principal name has the above  format. This convention requires that the
-administrator ensure that non-DHCP  server principals do not have names
-that match the above format.
-
-7.  IANA Considerations
-
-This draft does not create any new number spaces for IANA
-administration.
-
-8.  Acknowledgements
-
-The authors would like to acknowledge Ralph Droms and William Arbaugh,
-authors of the DHCP authentication draft [3]. This draft incorporates
-
-
-
-Hornstein, et al.            Standards Track                   [Page 26]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-material from their work; however, any mistakes in this document are
-solely the responsibility of the authors.
-
-9.  Authors' Addresses
-
-Ken Hornstein
-US Naval Research Laboratory
-Bldg A-49, Room 2
-4555 Overlook Avenue
-Washington DC  20375 USA
-
-Phone: +1 (202) 404-4765
-EMail: kenh@cmf.nrl.navy.mil
-
-Ted Lemon
-Internet Engines, Inc.
-950 Charter Street
-Redwood City, CA 94063
-
-Phone: +1 (650) 779 6031
-Email: mellon@iengines.net
-
-Bernard Aboba
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-
-Phone: +1 (425) 936-6605
-EMail: bernarda@microsoft.com
-
-Jonathan Trostle
-170 W. Tasman Dr.
-San Jose, CA 95134, U.S.A.
-
-Email: jtrostle@cisco.com
-Phone: +1 (408) 527-6201
-
-
-10.  Intellectual Property Statement
-
-The IETF takes no position regarding the validity or scope of any
-intellectual property or other rights that might be claimed to  pertain
-to the implementation or use of the technology described in this
-document or the extent to which any license under such rights might or
-might not be available; neither does it represent that it has made any
-effort to identify any such rights.  Information on the IETF's
-procedures with respect to rights in standards-track and standards-
-related documentation can be found in BCP-11.  Copies of claims of
-
-
-
-Hornstein, et al.            Standards Track                   [Page 27]
-
-
-INTERNET-DRAFT     DHCP Authentication Via Kerberos V   20 February 2000
-
-
-rights made available for publication and any assurances of licenses to
-be made available, or the result of an attempt made to obtain a general
-license or permission for the use of such proprietary rights by
-implementors or users of this specification can be obtained from the
-IETF Secretariat.
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary rights
-which may cover technology that may be required to practice this
-standard.  Please address the information to the IETF Executive
-Director.
-
-11.  Full Copyright Statement
-
-Copyright (C) The Internet Society (2000).  All Rights Reserved.
-This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it or
-assist in its implmentation may be prepared, copied, published and
-distributed, in whole or in part, without restriction of any kind,
-provided that the above copyright notice and this paragraph are included
-on all such copies and derivative works.  However, this document itself
-may not be modified in any way, such as by removing the copyright notice
-or references to the Internet Society or other Internet organizations,
-except as needed for the purpose of developing Internet standards in
-which case the procedures for copyrights defined in the Internet
-Standards process must be followed, or as required to translate it into
-languages other than English.  The limited permissions granted above are
-perpetual and will not be revoked by the Internet Society or its
-successors or assigns.  This document and the information contained
-herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
-INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-12.  Expiration Date
-
-This memo is filed as <draft-hornstein-dhc-kerbauth-02.txt>,  and
-expires October 1, 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-Hornstein, et al.            Standards Track                   [Page 28]
-
-
diff --git a/doc/standardisation/draft-horowitz-key-derivation-01.txt b/doc/standardisation/draft-horowitz-key-derivation-01.txt
deleted file mode 100644
index 4dcff486b..000000000
--- a/doc/standardisation/draft-horowitz-key-derivation-01.txt
+++ /dev/null
@@ -1,244 +0,0 @@
-Network Working Group                                        M. Horowitz
-<draft-horowitz-key-derivation-01.txt>                  Cygnus Solutions
-Internet-Draft                                               March, 1997
-
-
-       Key Derivation for Authentication, Integrity, and Privacy
-
-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 learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
-   Directories on ds.internic.net (US East Coast), nic.nordu.net
-   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
-   Rim).
-
-   Distribution of this memo is unlimited.  Please send comments to the
-   author.
-
-Abstract
-
-   Recent advances in cryptography have made it desirable to use longer
-   cryptographic keys, and to make more careful use of these keys.  In
-   particular, it is considered unwise by some cryptographers to use the
-   same key for multiple purposes.  Since most cryptographic-based
-   systems perform a range of functions, such as authentication, key
-   exchange, integrity, and encryption, it is desirable to use different
-   cryptographic keys for these purposes.
-
-   This RFC does not define a particular protocol, but defines a set of
-   cryptographic transformations for use with arbitrary network
-   protocols and block cryptographic algorithm.
-
-
-Deriving Keys
-
-   In order to use multiple keys for different functions, there are two
-   possibilities:
-
-    - Each protocol ``key'' contains multiple cryptographic keys.  The
-      implementation would know how to break up the protocol ``key'' for
-      use by the underlying cryptographic routines.
-
-    - The protocol ``key'' is used to derive the cryptographic keys.
-      The implementation would perform this derivation before calling
-
-
-
-Horowitz                                                        [Page 1]
-
-Internet Draft               Key Derivation                  March, 1997
-
-
-      the underlying cryptographic routines.
-
-   In the first solution, the system has the opportunity to provide
-   separate keys for different functions.  This has the advantage that
-   if one of these keys is broken, the others remain secret.  However,
-   this comes at the cost of larger ``keys'' at the protocol layer.  In
-   addition, since these ``keys'' may be encrypted, compromising the
-   cryptographic key which is used to encrypt them compromises all the
-   component keys.  Also, the not all ``keys'' are used for all possible
-   functions.  Some ``keys'', especially those derived from passwords,
-   are generated from limited amounts of entropy.  Wasting some of this
-   entropy on cryptographic keys which are never used is unwise.
-
-   The second solution uses keys derived from a base key to perform
-   cryptographic operations.  By carefully specifying how this key is
-   used, all of the advantages of the first solution can be kept, while
-   eliminating some disadvantages.  In particular, the base key must be
-   used only for generating the derived keys, and this derivation must
-   be non-invertible and entropy-preserving.  Given these restrictions,
-   compromise of one derived keys does not compromise the other subkeys.
-   Attack of the base key is limited, since it is only used for
-   derivation, and is not exposed to any user data.
-
-   Since the derived key has as much entropy as the base keys (if the
-   cryptosystem is good), password-derived keys have the full benefit of
-   all the entropy in the password.
-
-   To generate a derived key from a base key:
-
-      Derived Key = DK(Base Key, Well-Known Constant)
-
-   where
-
-      DK(Key, Constant) = n-truncate(E(Key, Constant))
-
-   In this construction, E(Key, Plaintext) is a block cipher, Constant
-   is a well-known constant defined by the protocol, and n-truncate
-   truncates its argument by taking the first n bits; here, n is the key
-   size of E.
-
-   If the output of E is is shorter than n bits, then some entropy in
-   the key will be lost.  If the Constant is smaller than the block size
-   of E, then it must be padded so it may be encrypted.  If the Constant
-   is larger than the block size, then it must be folded down to the
-   block size to avoid chaining, which affects the distribution of
-   entropy.
-
-   In any of these situations, a variation of the above construction is
-   used, where the folded Constant is encrypted, and the resulting
-   output is fed back into the encryption as necessary (the | indicates
-   concatentation):
-
-      K1 = E(Key, n-fold(Constant))
-      K2 = E(Key, K1)
-
-
-
-Horowitz                                                        [Page 2]
-
-Internet Draft               Key Derivation                  March, 1997
-
-
-      K3 = E(Key, K2)
-      K4 = ...
-
-      DK(Key, Constant) = n-truncate(K1 | K2 | K3 | K4 ...)
-
-   n-fold is an algorithm which takes m input bits and ``stretches''
-   them to form n output bits with no loss of entropy, as described in
-   [Blumenthal96].  In this document, n-fold is always used to produce n
-   bits of output, where n is the key size of E.
-
-   If the size of the Constant is not equal to the block size of E, then
-   the Constant must be n-folded to the block size of E.  This number is
-   used as input to E.  If the block size of E is less than the key
-   size, then the output from E is taken as input to a second invocation
-   of E.  This process is repeated until the number of bits accumulated
-   is greater than or equal to the key size of E.  When enough bits have
-   been computed, the first n are taken as the derived key.
-
-   Since the derived key is the result of one or more encryptions in the
-   base key, deriving the base key from the derived key is equivalent to
-   determining the key from a very small number of plaintext/ciphertext
-   pairs.  Thus, this construction is as strong as the cryptosystem
-   itself.
-
-
-Deriving Keys from Passwords
-
-   When protecting information with a password or other user data, it is
-   necessary to convert an arbitrary bit string into an encryption key.
-   In addition, it is sometimes desirable that the transformation from
-   password to key be difficult to reverse.  A simple variation on the
-   construction in the prior section can be used:
-
-      Key = DK(n-fold(Password), Well-Known Constant)
-
-   The n-fold algorithm is reversible, so recovery of the n-fold output
-   is equivalent to recovery of Password.  However, recovering the n-
-   fold output is difficult for the same reason recovering the base key
-   from a derived key is difficult.
-
-
-
-   Traditionally, the transformation from plaintext to ciphertext, or
-   vice versa, is determined by the cryptographic algorithm and the key.
-   A simple way to think of derived keys is that the transformation is
-   determined by the cryptographic algorithm, the constant, and the key.
-
-   For interoperability, the constants used to derive keys for different
-   purposes must be specified in the protocol specification.  The
-   constants must not be specified on the wire, or else an attacker who
-   determined one derived key could provide the associated constant and
-   spoof data using that derived key, rather than the one the protocol
-   designer intended.
-
-
-
-
-Horowitz                                                        [Page 3]
-
-Internet Draft               Key Derivation                  March, 1997
-
-
-   Determining which parts of a protocol require their own constants is
-   an issue for the designer of protocol using derived keys.
-
-
-Security Considerations
-
-   This entire document deals with security considerations relating to
-   the use of cryptography in network protocols.
-
-
-Acknowledgements
-
-   I would like to thank Uri Blumenthal, Hugo Krawczyk, and Bill
-   Sommerfeld for their contributions to this document.
-
-
-References
-
-   [Blumenthal96] Blumenthal, U., "A Better Key Schedule for DES-Like
-      Ciphers", Proceedings of PRAGOCRYPT '96, 1996.
-
-
-Author's Address
-
-   Marc Horowitz
-   Cygnus Solutions
-   955 Massachusetts Avenue
-   Cambridge, MA 02139
-
-   Phone: +1 617 354 7688
-   Email: marc@cygnus.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Horowitz                                                        [Page 4]
diff --git a/doc/standardisation/draft-ietf-cat-iakerb-04.txt b/doc/standardisation/draft-ietf-cat-iakerb-04.txt
deleted file mode 100644
index 208d057f2..000000000
--- a/doc/standardisation/draft-ietf-cat-iakerb-04.txt
+++ /dev/null
@@ -1,301 +0,0 @@
-INTERNET-DRAFT                                        Mike Swift
-draft-ietf-cat-iakerb-04.txt                          Microsoft
-Updates: RFC 1510                                     Jonathan Trostle
-July 2000					      Cisco Systems
-                                  
-
-         Initial Authentication and Pass Through Authentication 
-                Using Kerberos V5 and the GSS-API (IAKERB)
-
-
-0. Status Of This Memo
-
-   This document is an Internet-Draft and is in full conformance
-   with all provisions of Section 10 of RFC2026.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This draft expires on January 31st, 2001.
-
-
-1. Abstract
-
-   This document defines an extension to the Kerberos protocol
-   specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC 
-   1964 [2]) that enables a client to obtain Kerberos tickets for 
-   services where:
-
-   (1) The client knows its principal name and password, but not
-   its realm name (applicable in the situation where a user is already 
-   on the network but needs to authenticate to an ISP, and the user  
-   does not know his ISP realm name).
-   (2) The client is able to obtain the IP address of the service in 
-   a realm which it wants to send a request to, but is otherwise unable 
-   to locate or communicate with a KDC in the service realm or one of 
-   the intermediate realms. (One example would be a dial up user who 
-   does not have direct IP connectivity).
-   (3) The client does not know the realm name of the service.
-
-
-2. Motivation
-
-   When authenticating using Kerberos V5, clients obtain tickets from
-   a KDC and present them to services. This method of operation works
-
-   well in many situations, but is not always applicable since it
-   requires the client to know its own realm, the realm of the target 
-   service, the names of the KDC's, and to be able to connect to the 
-   KDC's. 
-  
-   This document defines an extension to the Kerberos protocol
-   specification (RFC 1510) [1] that enables a client to obtain
-   Kerberos tickets for services where:
-
-   (1) The client knows its principal name and password, but not
-   its realm name (applicable in the situation where a user is already 
-   on the network but needs to authenticate to an ISP, and the user 
-   does not know his ISP realm name).
-   (2) The client is able to obtain the IP address of the service in 
-   a realm which it wants to send a request to, but is otherwise unable 
-   to locate or communicate with a KDC in the service realm or one of 
-   the intermediate realms. (One example would be a dial up user who 
-   does not have direct IP connectivity).
-   (3) The client does not know the realm name of the service.
-
-   In this proposal, the client sends KDC request messages directly 
-   to application servers if one of the above failure cases develops. 
-   The application server acts as a proxy, forwarding messages back
-   and forth between the client and various KDC's (see Figure 1).
-
-
-           Client <---------> App Server <----------> KDC
-                               proxies
-
-
-                     Figure 1: IAKERB proxying
-
-
-   In the case where the client has sent a TGS_REQ message to the 
-   application server without a realm name in the request, the 
-   application server will forward an error message to the client 
-   with its realm name in the e-data field of the error message. 
-   The client will attempt to proceed using conventional Kerberos. 
-
-3. When Clients Should Use IAKERB
-
-   We list several, but possibly not all, cases where the client
-   should use IAKERB. In general, the existing Kerberos paradigm
-   where clients contact the KDC to obtain service tickets should
-   be preserved where possible.
-
-   (a) AS_REQ cases:
-
-   (i) The client is unable to locate the user's KDC or the KDC's
-   in the user's realm are not responding, or
-   (ii) The user has not entered a name which can be converted 
-   into a realm name (and the realm name cannot be derived from
-   a certificate). 
-
-   (b) TGS_REQ cases:
-
-   (i) the client determines that the KDC(s) in either an 
-   intermediate realm or the service realm are not responding or
-
-   the client is unable to locate a KDC, 
-
-   (ii) the client is not able to generate the application server 
-   realm name. 
-
-
-4. GSSAPI Encapsulation
-
-   The mechanism ID for IAKERB GSS-API Kerberos, in accordance with the 
-   mechanism proposed by SPNEGO for negotiating protocol variations, is:
-   {iso(1) member-body(2) United States(840) mit(113554) infosys(1) 
-   gssapi(2) krb5(2) initialauth(4)}
-
-   The AS request, AS reply, TGS request, and TGS reply messages are all 
-   encapsulated using the format defined by RFC1964 [2].  This consists 
-   of the GSS-API token framing defined in appendix B of RFC1508 [3]: 
-
-   InitialContextToken ::= 
-   [APPLICATION 0] IMPLICIT SEQUENCE { 
-           thisMech        MechType 
-                   -- MechType is OBJECT IDENTIFIER 
-                   -- representing "Kerberos V5" 
-           innerContextToken ANY DEFINED BY thisMech
-                   -- contents mechanism-specific;
-                   -- ASN.1 usage within innerContextToken
-                   -- is not required
-           }
-
-   The innerContextToken consists of a 2-byte TOK_ID field (defined 
-   below), followed by the Kerberos V5 KRB-AS-REQ, KRB-AS-REP, 
-   KRB-TGS-REQ, or KRB-TGS-REP messages, as appropriate. The TOK_ID field
-   shall be one of the following values, to denote that the message is 
-   either a request to the KDC or a response from the KDC.
-
-   Message         TOK_ID
-   KRB-KDC-REQ      00 03
-   KRB-KDC-REP      01 03
-   
-
-5. The Protocol
-
-   a. The user supplies a password (AS_REQ): Here the Kerberos client
-      will send an AS_REQ message to the application server if it cannot
-      locate a KDC for the user's realm, or such KDC's do not respond,
-      or the user does not enter a name from which the client can derive
-      the user's realm name. The client sets the realm field of the 
-      request equal to its own realm if the realm name is known, 
-      otherwise the realm length is set to 0. Upon receipt of the AS_REQ 
-      message, the application server checks if the client has included 
-      a realm. 
-
-      If the realm was not included in the original request, the 
-      application server must determine the realm and add it to the 
-      AS_REQ message before forwarding it. If the application server 
-      cannot determine the client realm, it returns the 
-      KRB_AP_ERR_REALM_REQUIRED error-code in an error message to 
-      the client:
-
-            KRB_AP_ERR_REALM_REQUIRED         77  
-
-      The error message can be sent in response to either an AS_REQ
-      message, or in response to a TGS_REQ message, in which case the 
-      realm and principal name of the application server are placed
-      into the realm and sname fields respectively, of the KRB-ERROR 
-      message. In the AS_REQ case, once the realm is filled in, the 
-      application server forwards the request to a KDC in the user's 
-      realm. It will retry the request if necessary, and forward the 
-      KDC response back to the client.
-
-      At the time the user enters a username and password, the client
-      should create a new credential with an INTERNAL NAME [3] that can
-      be used as an input into the GSS_Acquire_cred function call.
-
-      This functionality is useful when there is no trust relationship
-      between the user's logon realm and the target realm (Figure 2).
-
-
-                                     User Realm KDC        
-                                      /                
-                                     /                
-                                    /                
-                                   / 2,3   
-                      1,4         /      
-           Client<-------------->App Server
-
-
-      1 Client sends AS_REQ to App Server
-      2 App server forwards AS_REQ to User Realm KDC
-      3 App server receives AS_REP from User Realm KDC
-      4 App server sends AS_REP back to Client
-
-
-                      Figure 2: IAKERB AS_REQ
-
-
-
-   b. The user does not supply a password (TGS_REQ): The user includes a 
-      TGT targetted at the user's realm, or an intermediate realm, in a 
-      TGS_REQ message. The TGS_REQ message is sent to the application 
-      server. 
-
-      If the client has included the realm name in the TGS request, then
-      the application server will forward the request to a KDC in the
-      request TGT srealm. It will forward the response back to the client.
-
-      If the client has not included the realm name in the TGS request,
-      then the application server will return its realm name and principal 
-      name to the client using the KRB_AP_ERR_REALM_REQUIRED error 
-      described above. Sending a TGS_REQ message to the application server 
-      without a realm name in the request, followed by a TGS request using 
-      the returned realm name and then sending an AP request with a mutual 
-      authentication flag should be subject to a local policy decision 
-      (see security considerations below). Using the returned server 
-      principal name in a TGS request followed by sending an AP request 
-      message using the received ticket MUST NOT set any mutual 
-      authentication flags.
-
-
-6. Addresses in Tickets
-
-   In IAKERB, the machine sending requests to the KDC is the server and 
-   not the client. As a result, the client should not include its 
-   addresses in any KDC requests for two reasons. First, the KDC may
-   reject the forwarded request as being from the wrong client. Second,
-   in the case of initial authentication for a dial-up client, the client
-   machine may not yet possess a network address. Hence, as allowed by 
-   RFC1510 [1], the addresses field of the AS and TGS requests should be
-   blank and the caddr field of the ticket should similarly be left blank. 
-
-
-7. Combining IAKERB with Other Kerberos Extensions
-   
-   This protocol is usable with other proposed Kerberos extensions such as 
-   PKINIT (Public Key Cryptography for Initial Authentication in Kerberos 
-   [4]). In such cases, the messages which would normally be sent to the 
-   KDC by the GSS runtime are instead sent by the client application to the 
-   server, which then forwards them to a KDC.
-
-
-8. Security Considerations
-
-   A principal is identified by its principal name and realm. A client
-   that sends a TGS request to an application server without the request
-   realm name will only be able to mutually authenticate the server
-   up to its principal name. Thus when requesting mutual authentication, 
-   it is preferable if clients can either determine the server realm name 
-   beforehand, or apply some policy checks to the realm name obtained from 
-   the returned error message.
-   
-
-9. Bibliography
- 
-   [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
-   Service (V5). Request for Comments 1510.
-
-   [2]  J. Linn.  The Kerberos Version 5 GSS-API Mechanism. Request 
-   for Comments 1964 
-
-   [3]  J. Linn. Generic Security Service Application Program Interface.  
-   Request for Comments 1508 
-
-   [4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, 
-   J. Trostle, Public Key Cryptography for Initial Authentication in 
-   Kerberos, http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-
-   pkinit-10.txt.
-
-
-10. This draft expires on January 31st, 2001. 
-
-
-11. Authors' Addresses
-
-   Michael Swift
-   Microsoft
-   One Microsoft Way
-   Redmond, Washington, 98052, U.S.A.
-   Email: mikesw@microsoft.com
-
-   Jonathan Trostle
-   170 W. Tasman Dr. 
-   San Jose, CA 95134, U.S.A.
-   Email: jtrostle@cisco.com
-   Phone: (408) 527-6201
diff --git a/doc/standardisation/draft-ietf-cat-iakerb-09.txt b/doc/standardisation/draft-ietf-cat-iakerb-09.txt
deleted file mode 100644
index ee2ca5f7e..000000000
--- a/doc/standardisation/draft-ietf-cat-iakerb-09.txt
+++ /dev/null
@@ -1,809 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                        Jonathan Trostle
-draft-ietf-cat-iakerb-09.txt                          Cisco Systems
-Updates: RFC 1510, 1964                               Michael Swift
-October   2002                                        University of WA
-                                                      Bernard Aboba
-                                                      Microsoft
-                                                      Glen Zorn
-                                                      Cisco Systems
-
-
-Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API
-(IAKERB)
-                     <draft-ietf-cat-iakerb-09.txt>
-
-
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026 [5].
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This draft expires in March 2003. Please send comments to the
-   authors.
-
-1. Abstract
-
-   This document defines extensions to the Kerberos protocol
-   specification (RFC 1510 [1]) and GSSAPI Kerberos protocol mechanism
-   (RFC 1964 [2]) that enables a client to obtain Kerberos tickets for
-   services where the KDC is not accessible to the client, but is
-   accessible to the application server. Some common scenarios where
-   lack of accessibility would occur are when the client does not have
-   an IP address prior to authenticating to an access point, the client
-   is unable to locate a KDC, or a KDC is behind a firewall. The
-   document specifies two protocols to allow a client to exchange KDC
-   messages (which are GSS encapsulated) with an IAKERB proxy instead of
-   a KDC.
-
-
-
-Trostle, Swift, Aboba, Zorn                                     [Page 1]
-
-INTERNET DRAFT                  October 2002           Expires March 2003
-
-
-2. Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC2119 [6].
-
-3. Motivation
-
-   When authenticating using Kerberos V5, clients obtain tickets from a
-   KDC and present them to services. This method of operation works well
-   in many situations, but is not always applicable. The following is a
-   list of some of the scenarios that this proposal addresses:
-
-   (1) The client must initially authenticate to an access point in
-   order to gain full access to the network. Here the client may be
-   unable to directly contact the KDC either because it does not have an
-   IP address, or the access point packet filter does not allow the
-   client to send packets to the Internet before it authenticates to the
-   access point [8].
-
-   (2) A KDC is behind a firewall so the client will send Kerberos
-   messages to the IAKERB proxy which will transmit the KDC request and
-   reply messages between the client and the KDC. (The IAKERB proxy is a
-   special type of Kerberos application server that also relays KDC
-   request and reply messages between a client and the KDC).
-
-4. Overview
-
-   This proposal specifies two protocols that address the above
-   scenarios: the IAKERB proxy option and the IAKERB minimal messages
-   option. In the IAKERB proxy option (see Figure 1) an application
-   server called the IAKERB proxy acts as a protocol gateway and proxies
-   Kerberos messages back and forth between the client and the KDC. The
-   IAKERB proxy is also responsible for locating the KDC and may
-   additionally perform other application proxy level functions such as
-   auditing. A compliant IAKERB proxy MUST implement the IAKERB proxy
-   protocol.
-
-
-            Client <---------> IAKERB proxy <----------> KDC
-
-
-                      Figure 1: IAKERB proxying
-
-   The second protocol is the minimal messages protocol which is based
-   on user-user authentication [4]; this protocol is targetted at
-   environments where the number of messages, prior to key
-   establishment, needs to be minimized. In the normal minimal messages
-   protocol, the client sends its ticket granting ticket (TGT) to the
-   IAKERB proxy (in a KRB_TKT_PUSH message) for the TGS case. The IAKERB
-   proxy then sends a TGS_REQ to the KDC with the client's TGT in the
-   additional tickets field of the TGS_REQ message. The returned ticket
-   will list the client as the ticket's server principal, and will be
-   encrypted with the session key from the client's TGT. The IAKERB
-
-
-
-Trostle, Swift, Aboba, Zorn                                     [Page 2]
-
-INTERNET DRAFT                  October 2002           Expires March 2003
-
-
-   proxy then uses this ticket to generate an AP request that is sent to
-   the client (see Figure 2). Thus mutual authentication is accomplished
-   with three messages between the client and the IAKERB proxy versus
-   four or more (the difference is larger if crossrealm operations are
-   involved).
-
-   Subsequent to mutual authentication and key establishment, the IAKERB
-   proxy sends a ticket to the client (in a KRB_TKT_PUSH message).  This
-   ticket is created by the IAKERB proxy and contains the same fields as
-   the original service ticket that the proxy sent in the AP_REQ
-   message, except the client and server names are reversed and it is
-   encrypted in a long term key known to the IAKERB proxy. Its purpose
-   is to enable fast subsequent re-authentication by the client to the
-   application server (using the conventional AP request AP reply
-   exchange) for subsequent sessions. In addition to minimizing the
-   number of messages, a secondary goal is to minimize the number of
-   bytes transferred between the client and the IAKERB proxy prior to
-   mutual authentication and key establishment. Therefore, the final
-   service ticket (the reverse ticket) is sent after mutual
-   authentication and key establishment is complete, rather than as part
-   of the initial AP_REQ from the IAKERB proxy to the client. Thus
-   protected application data (e.g., GSS signed and wrapped messages)
-   can flow before this final message is sent.
-
-   The AS_REQ case for the minimal messages option is similar, where the
-   client sends up the AS_REQ message and the IAKERB proxy forwards it
-   to the KDC. The IAKERB proxy pulls the client TGT out of the AS_REP
-   message; the protocol now proceeds as in the TGS_REQ case described
-   above with the IAKERB proxy including the client's TGT in the
-   additional tickets field of the TGS_REQ message.
-
-   A compliant IAKERB proxy MUST implement the IAKERB proxy protocol,
-   and MAY implement the IAKERB minimal message protocol. In general,
-   the existing Kerberos paradigm where clients contact the KDC to
-   obtain service tickets should be preserved where possible.
-
-   For most IAKERB scenarios, such as when the client does not have an
-   IP address, or cannot directly contact a KDC, the IAKERB proxy
-   protocol should be adequate. If the client needs to obtain a
-   crossrealm TGT (and the conventional Kerberos protocol cannot be
-   used), then the IAKERB proxy protocol must be used.  In a scenario
-   where the client does not have a service ticket for the target
-   server, it is crucial that the number of messages between the client
-   and the target server be minimized (especially if the client and
-   target server are in different realms), and/or it is crucial that the
-   number of bytes transferred between the client and the target server
-   be minimized, then the client should consider using the minimal
-   messages protocol. The reader should see the security considerations
-   section regarding the minimal messages protocol.
-
-
-
-
-
-
-
-
-Trostle, Swift, Aboba, Zorn                                     [Page 3]
-
-INTERNET DRAFT                  October 2002           Expires March 2003
-
-
-                Client  --------> IAKERB proxy
-                        TKT_PUSH (w/ TGT)
-
-                Client            IAKERB proxy --------------------> KDC
-                                                TGS_REQ with client
-                                                TGT as additional TGT
-
-                Client            IAKERB proxy <-------------------- KDC
-                                                TGS_REP with service
-                                                ticket
-
-                Client <--------  IAKERB proxy                       KDC
-                         AP_REQ
-
-                Client -------->  IAKERB proxy                       KDC
-                         AP_REP
-
-           -------------------------------------------------------------
-            post-key establishment and application data flow phase:
-
-                Client <--------  IAKERB proxy                       KDC
-                        TKT_PUSH (w/ticket targetted at IAKERB proxy
-                               to enable fast subsequent authentication)
-
-
-                 Figure 2: IAKERB Minimal Messages Option: TGS case
-
-
-
-5.  GSSAPI Encapsulation
-
-   The mechanism ID for IAKERB proxy GSS-API Kerberos, in accordance
-   with the mechanism proposed by SPNEGO [7] for negotiating protocol
-   variations, is:  {iso(1) org(3) dod(6) internet(1) security(5)
-   mechanisms(5) iakerb(10) iakerbProxyProtocol(1)}.  The proposed
-   mechanism ID for IAKERB minimum messages GSS-API Kerberos, in
-   accordance with the mechanism proposed by SPNEGO for negotiating
-   protocol variations, is: {iso(1) org(3) dod(6) internet(1)
-   security(5) mechanisms(5) iakerb(10)
-   iakerbMinimumMessagesProtocol(2)}.
-
-   NOTE: An IAKERB implementation does not require SPNEGO in order to
-   achieve interoperability with other IAKERB peers. Two IAKERB
-   implementations may interoperate in the same way that any two peers
-   can interoperate using a pre-established GSSAPI mechanism.  The above
-   OID's allow two SPNEGO peers to securely negotiate IAKERB from among
-   a set of GSS mechanisms.
-
-   The AS request, AS reply, TGS request, and TGS reply messages are all
-   encapsulated using the format defined by RFC1964 [2].  This consists
-   of the GSS-API token framing defined in appendix B of [3]:
-
-
-
-
-
-
-Trostle, Swift, Aboba, Zorn                                     [Page 4]
-
-INTERNET DRAFT                  October 2002           Expires March 2003
-
-
-   InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
-           thisMech        MechType
-                   -- MechType is OBJECT IDENTIFIER
-                   -- representing iakerb proxy or iakerb min messages
-           innerContextToken ANY DEFINED BY thisMech
-                   -- contents mechanism-specific;
-                   -- ASN.1 usage within innerContextToken
-                   -- is not required
-        }
-
-   The innerContextToken consists of a 2-byte TOK_ID field (defined
-   below), followed by the Kerberos V5 KRB_AS_REQ, KRB_AS_REP,
-   KRB_TGS_REQ, or KRB_TGS_REP messages, as appropriate. The TOK_ID
-   field shall be one of the following values, to denote that the
-   message is either a request to the KDC or a response from the KDC.
-
-
-
-   Message          TOK_ID
-
-   KRB_KDC_REQ      00 03
-
-   KRB_KDC_REP      01 03
-
-   We also define the token ID for the KRB_TKT_PUSH token (defined below
-   and used in the minimal messages variation):
-
-   Message          TOK_ID
-
-   KRB_TKT_PUSH     02 03
-
-   For completeness, we list the other RFC 1964 defined token ID's here:
-
-   Message          TOK_ID
-
-   AP_REQ           01 00
-
-   AP_REP           02 00
-
-   KRB_ERROR        03 00
-
-6.  The IAKERB proxy protocol
-
-   The IAKERB proxy will proxy Kerberos KDC request, KDC reply, and
-   KRB_ERROR messages back and forth between the client and the KDC as
-   illustrated in Figure 1. Messages received from the client must first
-   have the Kerberos GSS header (RFC1964 [2]) stripped off. The
-   unencapsulated message will then be forwarded to a KDC. The IAKERB
-   proxy is responsible for locating an appropriate KDC using the realm
-   information in the KDC request message it received from the client.
-   In addition, the IAKERB proxy SHOULD implement a retry algorithm for
-   KDC requests over UDP (including selection of alternate KDC's if the
-   initial KDC does not respond to its requests). For messages sent by
-   the KDC, the IAKERB proxy encapsulates them with a Kerberos GSS
-
-
-
-Trostle, Swift, Aboba, Zorn                                     [Page 5]
-
-INTERNET DRAFT                  October 2002           Expires March 2003
-
-
-   header before sending them to the client.
-
-   We define two new Kerberos error codes that allow the proxy to
-   indicate the following error conditions to the client:
-
-   (a) when the proxy is unable to obtain an IP address for a KDC in the
-   client's realm, it sends the KRB_IAKERB_ERR_KDC_NOT_FOUND KRB_ERROR
-   (80) message to the client.
-
-   (b) when the proxy has an IP address for a KDC in the client realm,
-   but does not receive a response from any KDC in the realm (including
-   in response to retries), it sends the KRB_IAKERB_ERR_KDC_NO_RESPONSE
-   KRB_ERROR (81) message to the client.
-
-   To summarize, the sequence of steps for processing is as follows:
-
-   Servers:
-
-   1. For received KDC_REQ messages (with token ID 00 03)
-      - process GSS framing (check OID)
-        if the OID is not one of the two OID's specified in the GSSAPI
-        Encapsulation section above, then process according to mechanism
-        defined by that OID (if the OID is recognized). The processing
-        is outside the scope of this specification. Otherwise, strip
-        off GSS framing.
-      - find KDC for specified realm (if KDC IP address cannot be
-        obtained, send a KRB_ERROR message with error code
-        KRB_IAKERB_ERR_KDC_NOT_FOUND to the client).
-      - send to KDC (storing client IP address, port, and indication
-        whether IAKERB proxy option or minimal messages option is
-        being used)
-      - retry with same or another KDC if no response is received. If
-        the retries also fail, send an error message with error code
-        KRB_IAKERB_ERR_KDC_NO_RESPONSE to the client.
-
-   2. For received KDC_REP messages
-      - encapsulate with GSS framing, using token ID 01 03 and the OID
-        that corresponds to the stored protocol option
-      - send to client (using the stored client IP address and port)
-
-   3. For KRB_ERROR messages received from the KDC
-      - encapsulate with GSS framing, using token ID 03 00 and the OID
-        that corresponds to the stored protocol option
-      - send to client (using the stored client IP address and port)
-        (one possible exception is the KRB_ERR_RESPONSE_TOO_BIG error
-        which can lead to a retry of the KDC_REQ message over the TCP
-        transport by the server, instead of simply proxying the error
-        to the client).
-
-   4. For sending/receiving AP_REQ and AP_REP messages
-      - process per RFC 1510 and RFC 1964; the created AP_REP message
-        SHOULD include the subkey (with same etype as the session key)
-        to facilitate use with other key derivation algorithms outside
-        of [2]. The subkey SHOULD be created using locally generated
-
-
-
-Trostle, Swift, Aboba, Zorn                                     [Page 6]
-
-INTERNET DRAFT                 October 2002           Expires March 2003
-
-
-        entropy as one of the inputs (in addition to other inputs
-        such as the session key).
-
-   Clients:
-
-   1. For sending KDC_REQ messages
-      - create AS_REQ or TGS_REQ message
-      - encapsulate with GSS framing (token ID 00 03 and OID
-        corresponding to the protocol option).
-      - send to server
-
-   2. For received KDC_REP messages
-      - decapsulate by removing GSS framing (token ID 01 03)
-      - process inner Kerberos message according to RFC 1510
-
-   3. For received KRB_ERROR messages
-      - decapsulate by removing GSS framing (token ID 03 00)
-      - process inner Kerberos message according to RFC 1510
-        and possibly retry the request (time skew errors lead
-        to retries in most existing Kerberos implementations)
-
-   4. For sending/receiving AP_REQ and AP_REP messages
-      - process per RFC 1510 and RFC 1964; the created AP_REQ
-        message SHOULD include the subsession key in the
-        authenticator field.
-
-7. The IAKERB minimal messages protocol
-
-   The client MAY initiate the IAKERB minimal messages variation when
-   the number of messages must be minimized (the most significant
-   reduction in the number of messages can occur when the client and the
-   IAKERB proxy are in different realms). SPNEGO [7] MAY be used to
-   securely negotiate between the protocols (and amongst other GSS
-   mechanism protocols). A compliant IAKERB server MAY support the
-   IAKERB minimal messages protocol.
-
-   (a) AS_REQ case: (used when the client does not have a TGT)
-
-   We apply the Kerberos user-user authentication protocol [4] in this
-   scenario (other work in this area includes the IETF work in progress
-   effort to apply Kerberos user user authentication to DHCP
-   authentication).
-
-   The client indicates that the minimal message sub-protocol will be
-   used by using the appropriate OID as described above. The client
-   sends the GSS encapsulated AS_REQ message to the IAKERB proxy, and
-   the IAKERB proxy processes the GSS framing (as described above for
-   the IAKERB proxy option) and forwards the AS_REQ message to the KDC.
-
-   The IAKERB proxy will either send a KRB_ERROR message back to the
-   client, or it will send an initial context token consisting of the
-   GSS header (minimal messages OID with a two byte token header 01 03),
-   followed by an AS_REP message. The AS_REP message will contain the
-   AP_REQ message in a padata field; the ticket in the AP_REQ is a
-
-
-
-Trostle, Swift, Aboba, Zorn                                     [Page 7]
-
-INTERNET DRAFT                  October 2002           Expires March 2003
-
-
-   user-user ticket encrypted in the session key from the client's
-   original TGT. We define the padata type PA-AP-REQ with type number
-   25.  The corresponding padata value is the AP_REQ message without any
-   GSS framing. For the IAKERB minimal messages AS option, the AP_REQ
-   message authenticator MUST include the RFC 1964 [2] checksum.  The
-   mutual-required and use-session-key flags are set in the ap-options
-   field of the AP_REQ message.
-
-   The protocol is complete in the KRB_ERROR case (from the server
-   perspective, but the client should retry depending on the error
-   type). If the IAKERB proxy receives an AS_REP message from the KDC,
-   the IAKERB proxy will then obtain the client's TGT from the AS_REP
-   message. The IAKERB proxy then sends a TGS_REQ message with the
-   client's TGT in the additional tickets field to the client's KDC
-   (ENC-TKT-IN-SKEY option).
-
-   The IAKERB proxy MAY handle returned KRB_ERROR messages and retry the
-   TGS request message (e.g. on a KRB_ERR_RESPONSE_TOO_BIG error,
-   switching to TCP from UDP). Ultimately, the IAKERB proxy either
-   proxies a KRB_ERROR message to the client (after adding the GSS
-   framing), sends one of the new GSS framed KRB_ERROR messages defined
-   above, or it receives the TGS_REP message from the KDC and then
-   creates the AP_REQ message according to RFC 1964 [2]. The IAKERB
-   proxy then sends a GSS token containing the AS_REP message with the
-   AP_REQ message in the padata field as described above. (Note:
-   although the server sends the context token with the AP_REQ, the
-   client is the initiator.) The IAKERB proxy MUST set both the mutual-
-   required and use-session-key flags in the AP_REQ message in order to
-   cause the client to authenticate as well. The authenticator SHOULD
-   include the subsession key (containing locally added entropy).  The
-   client will reply with the GSSAPI enscapsulated AP_REP message, if
-   the IAKERB proxy's authentication succeeds (which SHOULD include the
-   subkey field to facilitate use with other key derivation algorithms
-   outside of [2]). If all goes well, then, in order to enable
-   subsequent efficient client authentications, the IAKERB proxy will
-   then send a final message of type KRB_TKT_PUSH containing a Kerberos
-   ticket (the reverse ticket) that has the IAKERB client principal
-   identifier in the client identifier field of the ticket and its own
-   principal identity in the server identifier field of the ticket (see
-   Figure 3):
-
-     KRB_TKT_PUSH :: = [APPLICATION 17] SEQUENCE {
-       pvno[0]             INTEGER,  -- 5 (protocol version)
-       msg-type[1]         INTEGER,  -- 17 (message type)
-       ticket[2]           Ticket
-     }
-
-   NOTE: The KRB_TKT_PUSH message must be encoded using ASN.1 DER.  The
-   key used to encrypt the reverse ticket is a long term secret key
-   chosen by the IAKERB proxy. The fields are identical to the AP_REQ
-   ticket, except the client name will be switched with the server name,
-   and the server realm will be switched with the client realm. (The one
-   other exception is that addresses should not be copied from the
-   AP_REQ ticket to the reverse ticket). Sending the reverse ticket
-
-
-
-Trostle, Swift, Aboba, Zorn                                     [Page 8]
-
-INTERNET DRAFT                  October 2002           Expires March 2003
-
-
-   allows the client to efficiently initiate subsequent reauthentication
-   attempts with a RFC1964 AP_REQ message. Note that the TKT_PUSH
-   message is sent after mutual authentication and key establishment are
-   complete.
-
-
-                Client  --------> IAKERB proxy --------------------> KDC
-                        AS_REQ                  AS_REQ
-
-                Client            IAKERB proxy <-------------------- KDC
-                                                AS_REP w/ client TGT
-
-                Client            IAKERB proxy --------------------> KDC
-                                                TGS_REQ with client
-                                                TGT as additional TGT
-
-                Client            IAKERB proxy <-------------------- KDC
-                                                TGS_REP with service
-                                                ticket
-
-                Client <--------  IAKERB proxy                       KDC
-                         AS_REP w/ AP_REQ in padata field
-
-                Client -------->  IAKERB proxy                       KDC
-                         AP_REP
-
-           -------------------------------------------------------------
-            post-key establishment and application data flow phase:
-
-                Client <--------  IAKERB proxy                       KDC
-                        TKT_PUSH (w/ticket targetted at IAKERB proxy
-                               to enable fast subsequent authentication)
-
-
-                 Figure 3: IAKERB Minimal Messages Option: AS case
-
-
-
-   (b) TGS_REQ case: (used when the client has a TGT)
-
-   The client indicates that the minimal messages sub-protocol will be
-   used by using the appropriate OID as described above. The client
-   initially sends a KRB_TKT_PUSH message (with the GSS header) to the
-   IAKERB proxy in order to send it a TGT. The IAKERB proxy will obtain
-   the client's TGT from the KRB_TKT_PUSH message and then proceed to
-   send a TGS_REQ message to a KDC where the realm of the KDC is equal
-   to the realm from the server realm field in the TGT sent by the
-   client in the KRB_TKT_PUSH message. NOTE: this realm could be the
-   client's home realm, the proxy's realm, or an intermediate realm. The
-   protocol then continues as in the minimal messages AS_REQ case
-   described above (see Figure 2); the IAKERB proxy's TGS_REQ message
-   contains the client's TGT in the additional tickets field (ENC-TKT-
-   IN-SKEY option). The IAKERB proxy then receives the TGS_REP message
-   from the KDC and then sends a RFC 1964 AP_REQ message to the client
-
-
-
-Trostle, Swift, Aboba, Zorn                                     [Page 9]
-
-INTERNET DRAFT                 October 2002           Expires March 2003
-
-
-   (with the MUTUAL AUTH flag set - see AS_REQ case).
-
-   To summarize, here are the steps for the minimal messages TGS
-   protocol:
-
-   Client:
-          (has TGT already for, or targetted at, realm X.ORG)
-          sends TKT_PUSH message to server containing client's ticket
-          for X.ORG (which could be a crossrealm TGT)
-
-   Server:
-          (has TGT already targetted at realm X.ORG)
-          sends to KDC (where KDC has principal id = server name,
-            server realm from client ticket) a TGS_REQ:
-          TGT in TGS_REQ is server's TGT
-          Additional ticket in TGS_REQ is client's TGT from TKT_PUSH
-            message
-          Server name in TGS_REQ (optional by rfc1510) is not present
-          Server realm in TGS_REQ is realm in server's TGT - X.ORG
-
-   KDC:
-          Builds a ticket:
-             Server name = client's name
-             Client name = server's name, Client realm = server's realm
-             Server realm = client's realm
-             Encrypted with: session key from client's TGT (passed in
-                additional tickets field)
-          Build a TGS_REP
-             Encrypted with session key from server's TGT
-          Sends TGS_REP and ticket to server
-
-   Server:
-          Decrypts TGS_REP from KDC using session key from its TGT
-          Constructs AP_REQ
-              Ticket = ticket from KDC (which was encrypted with
-                       client's TGT session key)
-              authenticator clientname = server's name (matches
-                clientname in AP-REQ ticket)
-              authenticator clientrealm = server's realm
-              subsession key in authenticator is present (same
-              etype as the etype of the session key in the ticket)
-              checksum in authenticator is the RFC 1964 checksum
-              sequence number in authenticator is present (RFC 1964)
-              ap-options has both use-session-key and mutual-required
-              flags set
-          Sends AP_REQ (with GSS-API framing) to client
-
-   Client:
-          Receives AP_REQ
-          Decrypts ticket using session key from its TGT
-          Verifies AP_REQ
-          Builds AP_REP and sends to server (AP_REP SHOULD include
-          subkey field to facilitate use with other key derivation
-          algorithms outside of [2] e.g., [8] and its successors.
-
-
-
-Trostle, Swift, Aboba, Zorn                                    [Page 10]
-
-INTERNET DRAFT                 October 2002           Expires March 2003
-
-
-          Some apps may have their own message protection key
-          derivation algorithm and protected message format.
-          AP_REP includes the sequence number per RFC 1964.)
-
-   Server:
-          Verifies AP-REP. Builds reverse ticket as described above
-          and sends reverse ticket to client using the KRB_TKT_PUSH
-          message. The reverse ticket is the same as the AP_REQ
-          ticket except the client name, realm are switched with the
-          server name, realm fields and it is encrypted in a secret
-          key known to the IAKERB proxy.
-
-8. Addresses in Tickets
-
-   In IAKERB, the machine sending requests to the KDC is the server and
-   not the client. As a result, the client should not include its
-   addresses in any KDC requests for two reasons. First, the KDC may
-   reject the forwarded request as being from the wrong client. Second,
-   in the case of initial authentication for a dial-up client, the
-   client machine may not yet possess a network address. Hence, as
-   allowed by RFC1510 [1], the addresses field of the AS and TGS
-   requests SHOULD be blank and the caddr field of the ticket SHOULD
-   similarly be left blank.
-
-9. Security Considerations
-
-   Similar to other network access protocols, IAKERB allows an
-   unauthenticated client (possibly outside the security perimeter of an
-   organization) to send messages that are proxied to interior servers.
-   When combined with DNS SRV RR's for KDC lookup, there is the
-   possibility that an attacker can send an arbitrary message to an
-   interior server. There are several aspects to note here:
-
-   (1) in many scenarios, compromise of the DNS lookup will require the
-   attacker to already have access to the internal network. Thus the
-   attacker would already be able to send arbitrary messages to interior
-   servers. No new vulnerabilities are added in these scenarios.
-
-   (2) in a scenario where DNS SRV RR's are being used to locate the
-   KDC, IAKERB is being used, and an external attacker can modify DNS
-   responses to the IAKERB proxy, there are several countermeasures to
-   prevent arbitrary messages from being sent to internal servers:
-
-   (a) KDC port numbers can be statically configured on the IAKERB
-   proxy. In this case, the messages will always be sent to KDC's. For
-   an organization that runs KDC's on a static port (usually port 88)
-   and does not run any other servers on the same port, this
-   countermeasure would be easy to administer and should be effective.
-
-   (b) the proxy can do application level sanity checking and filtering.
-   This countermeasure should eliminate many of the above attacks.
-
-   (c) DNS security can be deployed. This countermeasure is probably
-   overkill for this particular problem, but if an organization has
-
-
-
-Trostle, Swift, Aboba, Zorn                                    [Page 11]
-
-INTERNET DRAFT                 October 2002           Expires March 2003
-
-
-   already deployed DNS security for other reasons, then it might make
-   sense to leverage it here. Note that Kerberos could be used to
-   protect the DNS exchanges.  The initial DNS SRV KDC lookup by the
-   proxy will be unprotected, but an attack here is at most a denial of
-   service (the initial lookup will be for the proxy's KDC to facilitate
-   Kerberos protection of subsequent DNS exchanges between itself and
-   the DNS server).
-
-   In the minimal messages protocol option, the application server sends
-   an AP_REQ message to the client. The ticket in the AP_REQ message
-   SHOULD NOT contain authorization data since some operating systems
-   may allow the client to impersonate the server and increase its own
-   privileges. If the ticket from the server connotes any authorization,
-   then the minimal messages protocol should not be used. Also, the
-   minimal messages protocol may facilitate denial of service attacks in
-   some environments; to prevent these attacks, it may make sense for
-   the minimal messages protocol server to only accept a KRB_TGT_PUSH
-   message on a local network interface (to ensure that the message was
-   not sent from a remote malicious host).
-
-10. Acknowledgements
-
-   We thank the Kerberos Working Group chair, Doug Engert, for his
-   efforts in helping to progress this specification. We also thank Ken
-   Raeburn for his comments and the other working group participants for
-   their input.
-
-11.  References
-
-   [1] J. Kohl, C. Neuman, "The Kerberos Network Authentication
-       Service (V5)", RFC 1510.
-
-   [2] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964.
-
-   [3] J. Linn, "Generic Security Service Application Program
-       Interface Version 2, Update 1", RFC 2743.
-
-   [4] D. Davis, R. Swick, "Workstation Services and Kerberos
-       Authentication at Project Athena", Technical Memorandum TM-424,
-       MIT Laboratory for Computer Science, February 1990.
-
-   [5] S. Bradner, "The Internet Standards Process -- Revision 3", BCP
-       9, RFC 2026, October 1996.
-
-   [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
-       Levels", BCP 14, RFC 2119, March 1997.
-
-   [7] E. Baize, D. Pinkas, "The Simple and Protected GSS-API Negotiation
-       Mechanism," RFC 2478, December 1998.
-
-   [8] Part 11: Wireless LAN Medium Access Control (MAC) and Physical
-       Layer (PHY) Specifications, ANSI/IEEE Std. 802.11, 1999 Edition.
-
-
-
-
-
-Trostle, Swift, Aboba, Zorn                                    [Page 12]
-
-INTERNET DRAFT               October 2002             Expires March 2003
-
-
-12.  Author's Addresses
-
-   Jonathan Trostle
-   Cisco Systems
-   170 W. Tasman Dr.
-   San Jose, CA 95134, U.S.A.
-   Email: jtrostle@cisco.com
-   Phone: (408) 527-6201
-
-   Michael Swift
-   University of Washington
-   Seattle, WA
-   Email: mikesw@cs.washington.edu
-
-   Bernard Aboba
-   Microsoft
-   One Microsoft Way
-   Redmond, Washington, 98052, U.S.A.
-   Email: bernarda@microsoft.com
-   Phone: (425) 706-6605
-
-   Glen Zorn
-   Cisco Systems
-   Bellevue, WA U.S.A.
-   Email: gwz@cisco.com
-   Phone: (425) 468-0955
-
-   This draft expires on March 31st, 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Trostle, Swift, Aboba, Zorn                                    [Page 13]
-
diff --git a/doc/standardisation/draft-ietf-cat-kerb-chg-password-02.txt b/doc/standardisation/draft-ietf-cat-kerb-chg-password-02.txt
deleted file mode 100644
index e235bec58..000000000
--- a/doc/standardisation/draft-ietf-cat-kerb-chg-password-02.txt
+++ /dev/null
@@ -1,311 +0,0 @@
-
-
-
-
-Network Working Group                                        M. Horowitz
-<draft-ietf-cat-kerb-chg-password-02.txt>                Stonecast, Inc.
-Internet-Draft                                              August, 1998
-
-                   Kerberos Change Password Protocol
-
-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 learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
-   Directories on ftp.ietf.org (US East Coast), nic.nordu.net
-   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
-   Rim).
-
-   Distribution of this memo is unlimited.  Please send comments to the
-   <cat-ietf@mit.edu> mailing list.
-
-Abstract
-
-   The Kerberos V5 protocol [RFC1510] does not describe any mechanism
-   for users to change their own passwords.  In order to promote
-   interoperability between workstations, personal computers, terminal
-   servers, routers, and KDC's from multiple vendors, a common password
-   changing protocol is required.
-
-
-
-Overview
-
-   When a user wishes to change his own password, or is required to by
-   local policy, a simple request of a password changing service is
-   necessary.  This service must be implemented on at least one host for
-   each Kerberos realm, probably on one of the kdc's for that realm.
-   The service must accept requests on UDP port 464 (kpasswd), and may
-   accept requests on TCP port 464 as well.
-
-   The protocol itself consists of a single request message followed by
-   a single reply message.  For UDP transport, each message must be
-   fully contained in a single UDP packet.
-
-
-
-
-
-
-
-
-Horowitz                                                        [Page 1]
-
-Internet Draft      Kerberos Change Password Protocol       August, 1998
-
-
-Request Message
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |         message length        |    protocol version number    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |          AP_REQ length        |         AP-REQ data           /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      /                        KRB-PRIV message                       /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   message length (16 bits)
-      Contains the length of the message, including this field, in bytes
-      (big-endian integer)
-   protocol version number (16 bits)
-      Contains the hex constant 0x0001 (big-endian integer)
-   AP-REQ length (16 bits)
-      length (big-endian integer) of AP-REQ data, in bytes.
-   AP-REQ data, as described in RFC1510 (variable length)
-      This AP-REQ must be for the service principal
-      kadmin/changepw@REALM, where REALM is the REALM of the user who
-      wishes to change his password.  The Ticket in the AP-REQ must be
-      derived from an AS request (thus having the INITIAL flag set), and
-      must include a subkey in the Authenticator.
-   KRB-PRIV message, as described in RFC1510 (variable length)
-      This KRB-PRIV message must be generated using the subkey in the
-      Authenticator in the AP-REQ data.  The user-data component of the
-      message must consist of the user's new password.
-
-   The server must verify the AP-REQ message, decrypt the new password,
-   perform any local policy checks (such as password quality, history,
-   authorization, etc.) required, then set the password to the new value
-   specified.
-
-   The principal whose password is to be changed is the principal which
-   authenticated to the password changing service.  This protocol does
-   not address administrators who want to change passwords of principal
-   besides their own.
-
-
-Reply Message
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |         message length        |    protocol version number    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |          AP_REP length        |         AP-REP data           /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      /                KRB-PRIV or KRB-ERROR message                  /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   message length (16 bits)
-
-
-
-Horowitz                                                        [Page 2]
-
-Internet Draft      Kerberos Change Password Protocol       August, 1998
-
-
-      Contains the length of the message, including this field, in bytes
-      (big-endian integer),
-   protocol version number (16 bits)
-      Contains the hex constant 0x0001 (big-endian integer)
-   AP-REP length (16 bits)
-      length of AP-REP data, in bytes.  If the the length is zero, then
-      the last field will contain a KRB-ERROR message instead of a KRB-
-      PRIV message.
-   AP-REP data, as described in RFC1510 (variable length)
-      The AP-REP corresponding to the AP-REQ in the request packet.
-   KRB-PRIV or KRB-ERROR message, as described in RFC1510 (variable
-      length)
-      If the AP-REP length is zero, then this field contains a KRB-ERROR
-      message.  Otherwise, it contains a KRB-PRIV message.  This KRB-
-      PRIV message must be generated using the subkey in the
-      Authenticator in the AP-REQ data.
-
-      The user-data component of the KRB-PRIV message, or e-data
-      component of the KRB-ERROR message, must consist of the following
-      data:
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |          result code          |        result string          /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-      result code (16 bits)
-         The result code must have one of the following values (big-
-         endian integer):
-         0x0000 if the request succeeds.  (This value is not permitted
-            in a KRB-ERROR message.)
-         0x0001 if the request fails due to being malformed
-         0x0002 if the request fails due to a "hard" error processing
-            the request (for example, there is a resource or other
-            problem causing the request to fail)
-         0x0003 if the request fails due to an error in authentication
-            processing
-         0x0004 if the request fails due to a "soft" error processing
-            the request (for example, some policy or other similar
-            consideration is causing the request to be rejected).
-         0xFFFF if the request fails for some other reason.
-         Although only a few non-zero result codes are specified here,
-         the client should accept any non-zero result code as indicating
-         failure.
-      result string (variable length)
-         This field should contain information which the server thinks
-         might be useful to the user, such as feedback about policy
-         failures.  The string must be encoded in UTF-8.  It may be
-         omitted if the server does not wish to include it.  If it is
-         present, the client should display the string to the user.
-         This field is analogous to the string which follows the numeric
-         code in SMTP, FTP, and similar protocols.
-
-
-
-
-Horowitz                                                        [Page 3]
-
-Internet Draft      Kerberos Change Password Protocol       August, 1998
-
-
-Dropped and Modified Messages
-
-   An attacker (or simply a lossy network) could cause either the
-   request or reply to be dropped, or modified by substituting a KRB-
-   ERROR message in the reply.
-
-   If a request is dropped, no modification of the password/key database
-   will take place.  If a reply is dropped, the server will (assuming a
-   valid request) make the password change.  However, the client cannot
-   distinguish between these two cases.
-
-   In this situation, the client should construct a new authenticator,
-   re-encrypt the request, and retransmit.  If the original request was
-   lost, the server will treat this as a valid request, and the password
-   will be changed normally.  If the reply was lost, then the server
-   should take care to notice that the request was a duplicate of the
-   prior request, because the "new" password is the current password,
-   and the password change time is within some implementation-defined
-   replay time window.  The server should then return a success reply
-   (an AP-REP message with result code == 0x0000) without actually
-   changing the password or any other information (such as modification
-   timestamps).
-
-   If a success reply was replaced with an error reply, then the
-   application performing the request would return an error to the user.
-   In this state, the user's password has been changed, but the user
-   believes that it has not.  If the user attempts to change the
-   password again, this will probably fail, because the user cannot
-   successfully provide the old password to get an INITIAL ticket to
-   make the request.  This situation requires administrative
-   intervention as if a password was lost.  This situation is,
-   unfortunately, impossible to prevent.
-
-
-Security Considerations
-
-   This document deals with changing passwords for Kerberos.  Because
-   Kerberos is used for authentication and key distribution, it is
-   important that this protocol use the highest level of security
-   services available to a particular installation.  Mutual
-   authentication is performed, so that the server knows the request is
-   valid, and the client knows that the request has been received and
-   processed by the server.
-
-   There are also security issues relating to dropped or modified
-   messages which are addressed explicitly.
-
-
-References
-
-   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
-      Authentication Service (V5)", RFC 1510, September 1993.
-
-
-
-
-
-Horowitz                                                        [Page 4]
-
-Internet Draft      Kerberos Change Password Protocol       August, 1998
-
-
-Author's Address
-
-   Marc Horowitz
-   Stonecast, Inc.
-   108 Stow Road
-   Harvard, MA 01451
-
-   Phone: +1 978 456 9103
-   Email: marc@stonecast.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Horowitz                                                        [Page 5]
-
diff --git a/doc/standardisation/draft-ietf-cat-kerb-des3-hmac-sha1-00.txt b/doc/standardisation/draft-ietf-cat-kerb-des3-hmac-sha1-00.txt
deleted file mode 100644
index 2583a84da..000000000
--- a/doc/standardisation/draft-ietf-cat-kerb-des3-hmac-sha1-00.txt
+++ /dev/null
@@ -1,127 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        M. Horowitz
-<draft-ietf-cat-kerb-des3-hmac-sha1-00.txt>             Cygnus Solutions
-Internet-Draft                                            November, 1996
-
-
-           Triple DES with HMAC-SHA1 Kerberos Encryption Type
-
-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 learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
-   Directories on ds.internic.net (US East Coast), nic.nordu.net
-   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
-   Rim).
-
-   Distribution of this memo is unlimited.  Please send comments to the
-   <cat-ietf@mit.edu> mailing list.
-
-Abstract
-
-   This document defines a new encryption type and a new checksum type
-   for use with Kerberos V5 [RFC1510].  This encryption type is based on
-   the Triple DES cryptosystem and the HMAC-SHA1 [Krawczyk96] message
-   authentication algorithm.
-
-   The des3-cbc-hmac-sha1 encryption type has been assigned the value 7.
-   The hmac-sha1-des3 checksum type has been assigned the value 12.
-
-
-Encryption Type des3-cbc-hmac-sha1
-
-   EncryptedData using this type must be generated as described in
-   [Horowitz96].  The encryption algorithm is Triple DES in Outer-CBC
-   mode.  The keyed hash algorithm is HMAC-SHA1.  Unless otherwise
-   specified, a zero IV must be used.  If the length of the input data
-   is not a multiple of the block size, zero octets must be used to pad
-   the plaintext to the next eight-octet boundary.  The counfounder must
-   be eight random octets (one block).
-
-
-Checksum Type hmac-sha1-des3
-
-   Checksums using this type must be generated as described in
-   [Horowitz96].  The keyed hash algorithm is HMAC-SHA1.
-
-
-
-Horowitz                                                        [Page 1]
-
-Internet Draft     Kerberos Triple DES with HMAC-SHA1     November, 1996
-
-
-Common Requirements
-
-   Where the Triple DES key is represented as an EncryptionKey, it shall
-   be represented as three DES keys, with parity bits, concatenated
-   together.  The key shall be represented with the most significant bit
-   first.
-
-   When keys are generated by the derivation function, a key length of
-   168 bits shall be used.  The output bit string will be converted to a
-   valid Triple DES key by inserting DES parity bits after every seventh
-   bit.
-
-   Any implementation which implements either of the encryption or
-   checksum types in this document must support both.
-
-
-Security Considerations
-
-   This entire document defines encryption and checksum types for use
-   with Kerberos V5.
-
-
-References
-
-   [Horowitz96] Horowitz, M., "Key Derivation for Kerberos V5", draft-
-      horowitz-kerb-key-derivation-00.txt, November 1996.
-   [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC:
-      Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac-
-      md5-01.txt, August, 1996.
-   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
-      Authentication Service (V5)", RFC 1510, September 1993.
-
-
-Author's Address
-
-   Marc Horowitz
-   Cygnus Solutions
-   955 Massachusetts Avenue
-   Cambridge, MA 02139
-
-   Phone: +1 617 354 7688
-   Email: marc@cygnus.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Horowitz                                                        [Page 2]
-
diff --git a/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt b/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt
deleted file mode 100644
index 46a415852..000000000
--- a/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt
+++ /dev/null
@@ -1,250 +0,0 @@
-
-
-
-
-
-Network Working Group                                        M. Horowitz
-<draft-ietf-cat-kerb-key-derivation-00.txt>             Cygnus Solutions
-Internet-Draft                                            November, 1996
-
-
-                     Key Derivation for Kerberos V5
-
-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 learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
-   Directories on ds.internic.net (US East Coast), nic.nordu.net
-   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
-   Rim).
-
-   Distribution of this memo is unlimited.  Please send comments to the
-   <cat-ietf@mit.edu> mailing list.
-
-Abstract
-
-   In the Kerberos protocol [RFC1510], cryptographic keys are used in a
-   number of places.  In order to minimize the effect of compromising a
-   key, it is desirable to use a different key for each of these places.
-   Key derivation [Horowitz96] can be used to construct different keys
-   for each operation from the keys transported on the network.  For
-   this to be possible, a small change to the specification is
-   necessary.
-
-
-Overview
-
-   Under RFC1510 as stated, key derivation could be specified as a set
-   of encryption types which share the same key type.  The constant for
-   each derivation would be a function of the encryption type.  However,
-   it is generally accepted that, for interoperability, key types and
-   encryption types must map one-to-one onto each other.  (RFC 1510 is
-   being revised to address this issue.)  Therefore, to use key
-   derivcation with Kerberos V5 requires a small change to the
-   specification.
-
-   For each place where a key is used in Kerberos, a ``key usage'' must
-   be specified for that purpose.  The key, key usage, and
-   encryption/checksum type together describe the transformation from
-   plaintext to ciphertext, or plaintext to checksum.  For backward
-
-
-
-Horowitz                                                        [Page 1]
-
-Internet Draft       Key Derivation for Kerberos V5       November, 1996
-
-
-   compatibility, old encryption types would be defined independently of
-   the key usage.
-
-
-Key Usage Values
-
-   This is a complete list of places keys are used in the kerberos
-   protocol, with key usage values and RFC 1510 section numbers:
-
-      1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
-          client key (section 5.4.1)
-      2.  AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
-          application session key), encrypted with the service key
-          (section 5.4.2)
-      3.  AS-REP encrypted part (includes tgs session key or application
-          session key), encrypted with the client key (section 5.4.2)
-
-      4.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
-          session key (section 5.4.1)
-      5.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
-          authenticator subkey (section 5.4.1)
-      6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
-          with the tgs session key (sections 5.3.2, 5.4.1)
-      7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
-          authenticator subkey), encrypted with the tgs session key
-          (section 5.3.2)
-      8.  TGS-REP encrypted part (includes application session key),
-          encrypted with the tgs session key (section 5.4.2)
-      9.  TGS-REP encrypted part (includes application session key),
-          encrypted with the tgs authenticator subkey (section 5.4.2)
-
-      10. AP-REQ Authenticator cksum, keyed with the application session
-          key (section 5.3.2)
-      11. AP-REQ Authenticator (includes application authenticator
-          subkey), encrypted with the application session key (section
-          5.3.2)
-      12. AP-REP encrypted part (includes application session subkey),
-          encrypted with the application session key (section 5.5.2)
-
-      13. KRB-PRIV encrypted part, encrypted with a key chosen by the
-          application (section 5.7.1)
-      14. KRB-CRED encrypted part, encrypted with a key chosen by the
-          application (section 5.6.1)
-      15. KRB-SAVE cksum, keyed with a key chosen by the application
-          (section 5.8.1)
-
-      16. Data which is defined in some specification outside of
-          Kerberos to be encrypted using an RFC1510 encryption type.
-      17. Data which is defined in some specification outside of
-          Kerberos to be checksummed using an RFC1510 checksum type.
-
-   A few of these key usages need a little clarification.  A service
-   which receives an AP-REQ has no way to know if the enclosed Ticket
-   was part of an AS-REP or TGS-REP.  Therefore, key usage 2 must always
-
-
-
-Horowitz                                                        [Page 2]
-
-Internet Draft       Key Derivation for Kerberos V5       November, 1996
-
-
-   be used for generating a Ticket, whether it is in response to an AS-
-   REQ or TGS-REQ.
-
-   There might exist other documents which define protocols in terms of
-   the RFC1510 encryption types or checksum types.  Such documents would
-   not know about key usages.  In order that these documents continue to
-   be meaningful until they are updated, key usages 16 and 17 must be
-   used to derive keys for encryption and checksums, respectively.  New
-   protocols defined in terms of the Kerberos encryption and checksum
-   types should use their own key usages.  Key usages may be registered
-   with IANA to avoid conflicts.  Key usages shall be unsigned 32 bit
-   integers.  Zero is not permitted.
-
-
-Defining Cryptosystems Using Key Derivation
-
-   Kerberos requires that the ciphertext component of EncryptedData be
-   tamper-resistant as well as confidential.  This implies encryption
-   and integrity functions, which must each use their own separate keys.
-   So, for each key usage, two keys must be generated, one for
-   encryption (Ke), and one for integrity (Ki):
-
-      Ke = DK(protocol key, key usage | 0xAA)
-      Ki = DK(protocol key, key usage | 0x55)
-
-   where the key usage is represented as a 32 bit integer in network
-   byte order.  The ciphertest must be generated from the plaintext as
-   follows:
-
-      ciphertext = E(Ke, confounder | length | plaintext | padding) |
-                   H(Ki, confounder | length | plaintext | padding)
-
-   The confounder and padding are specific to the encryption algorithm
-   E.
-
-   When generating a checksum only, there is no need for a confounder or
-   padding.  Again, a new key (Kc) must be used.  Checksums must be
-   generated from the plaintext as follows:
-
-      Kc = DK(protocol key, key usage | 0x99)
-
-      MAC = H(Kc, length | plaintext)
-
-   Note that each enctype is described by an encryption algorithm E and
-   a keyed hash algorithm H, and each checksum type is described by a
-   keyed hash algorithm H.  HMAC, with an appropriate hash, is
-   recommended for use as H.
-
-
-Security Considerations
-
-   This entire document addresses shortcomings in the use of
-   cryptographic keys in Kerberos V5.
-
-
-
-
-Horowitz                                                        [Page 3]
-
-Internet Draft       Key Derivation for Kerberos V5       November, 1996
-
-
-Acknowledgements
-
-   I would like to thank Uri Blumenthal, Sam Hartman, and Bill
-   Sommerfeld for their contributions to this document.
-
-
-References
-
-   [Horowitz96] Horowitz, M., "Key Derivation for Authentication,
-      Integrity, and Privacy", draft-horowitz-key-derivation-00.txt,
-      November 1996.  [RFC1510] Kohl, J. and Neuman, C., "The Kerberos
-      Network Authentication Service (V5)", RFC 1510, September 1993.
-
-
-Author's Address
-
-   Marc Horowitz
-   Cygnus Solutions
-   955 Massachusetts Avenue
-   Cambridge, MA 02139
-
-   Phone: +1 617 354 7688
-   Email: marc@cygnus.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Horowitz                                                        [Page 4]
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt b/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt
deleted file mode 100644
index c5e4d05e7..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-err-msg-00.txt
+++ /dev/null
@@ -1,252 +0,0 @@
-
-INTERNET-DRAFT                                           Ari Medvinsky
-draft-ietf-cat-kerberos-err-msg-00.txt                        Matt Hur
-Updates: RFC 1510                                  Dominique Brezinski
-expires September 30, 1997                       CyberSafe Corporation
-                                                           Gene Tsudik
-                                                            Brian Tung
-                                                                   ISI
-
-Integrity Protection for the Kerberos Error Message
-
-0.  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 learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ds.internic.net (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-03.txt, and expires June xx, 1997.
-    Please send comments to the authors.
-
-1.  Abstract
-
-    The Kerberos error message, as defined in RFC 1510, is transmitted 
-    to the client without any integrity assurance.  Therefore, the 
-    client has no means to distinguish between a valid error message 
-    sent from the KDC and one sent by an attacker.  This draft describes 
-    a method for assuring the integrity of Kerberos error messages, and 
-    proposes a consistent format for the e-data field in the KRB_ERROR 
-    message.  This e-data format enables the storage of cryptographic 
-    checksums by providing an extensible mechanism for specifying e-data 
-    types.
-
-
-2.  Motivation      
-
-    In the Kerberos protocol [1], if an error occurs for AS_REQ,
-    TGS_REQ, or AP_REQ, a clear text error message is returned to the
-    client.  An attacker may exploit this vulnerability by sending a
-    false error message as a reply to any of the above requests.  For
-    example, an attacker may send the KDC_ERR_KEY_EXPIRED error message
-    in order to force a user to change their password in hope that the
-    new key will not be as strong as the current key, and thus, easier
-    to break.
-
-    Since false error messages may be utilized by an attacker, a
-    Kerberos client should have a means for determining how much trust
-    to place in a given error message.  The rest of this draft
-    describes a method for assuring the integrity of Kerberos error
-    messages.
-
-
-3.  Approach
-
-    We propose taking a cryptographic checksum over the entire KRB-ERROR
-    message.  This checksum would be returned as part of the error
-    message and would enable the client to verify the integrity of the
-    error message.  For interoperability reasons, no new fields are
-    added to the KRB-ERROR message.  Instead, the e-data field (see
-    figure 1) is utilized to carry the cryptographic checksum.
-
-
-3.1 Cryptographic checksums in error messages for AS_REQ,
-    TGS_REQ & AP_REQ
-
-    If an error occurs for the AS request, the only key that is
-    available to the KDC is the shared secret (the key derived from the
-    clients password) registered in the KDCs database.  The KDC will
-    use this key to sign the error message, if and only if, the client
-    already proved knowledge of the shared secret in the AS request
-    (e.g. via PA-ENC-TIMESTAMP in preauth data).  This policy is needed
-    to prevent an attacker from getting the KDC to send a signed error
-    message and then launching an off-line attack in order to obtain a
-    key of a given principal. 
-
-    If an error occurs for a TGS or an AP request, the server will use
-    the session key sealed in the clients ticket granting ticket to
-    compute the checksum over the error message.  If the checksum could
-    not be computed (e.g. error while decrypting the ticket) the error
-    message is returned to the client without the checksum.  The client
-    then has the option to treat unprotected error messages differently.
-
-
-    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
-    }
-    Figure 1
-
-
-3.2 Format of the e-data field
-
-    We propose to place the cryptographic checksum in the e-data field.
-    First, we review the format of the e-data field, as specified in
-    RFC 1510.  The format of e-data is specified only in two cases [2].
-    "If the error code is KDC_ERR_PREAUTH_REQUIRED, then the e-data
-    field will contain an encoding of a sequence of padata fields":
-
-    METHOD-DATA ::=  SEQUENCE of PA-DATA
-    PA-DATA ::= SEQUENCE {
-                padata-type    [1] INTEGER,
-                padata-value   [2] OCTET STRING
-    }
-
-    The second case deals with the KRB_AP_ERR_METHOD error code.  The
-    e-data field will contain an encoding of the following sequence:
-
-    METHOD-DATA ::=  SEQUENCE {
-                     method-type    [0] INTEGER,
-                     method-data    [1] OCTET STRING OPTIONAL
-    }
-
-    method-type indicates the required alternate authentication method.
-
-    It should be noted that, in the case of KRB_AP_ERR_METHOD, a signed
-    checksum is not returned as part of the error message, since the
-    error code indicates that the Kerberos credentials provided in the
-    AP_REQ message are unacceptable.
-
-    We propose that the e-data field have the following format for all
-    error-codes (except KRB_AP_ERR_METHOD):
-
-    E-DATA ::=  SEQUENCE {
-                data-type    [1] INTEGER,
-                data-value   [2] OCTET STRING,
-    }
-
-    The data-type field specifies the type of information that is
-    carried in the data-value field.  Thus, to send a cryptographic
-    checksum back to the client, the data-type is set to CHECKSUM, the
-    data-value is set to the ASN.1 encoding of the following sequence:
-
-    Checksum  ::=  SEQUENCE {
-                   cksumtype  [0] INTEGER,
-                   checksum   [1] OCTET STRING
-    }
-
-
-3.3 Computing the checksum 
-
-    After the error message is filled out, the error structure is
-    converted into ASN.1 representation.  A cryptographic checksum is
-    then taken over the encoded error message; the result is placed in
-    the error message structure, as the last item in the e-data field.
-    To send the error message, ASN.1 encoding is again performed over
-    the error message, which now includes the cryptographic checksum.
-
-
-3.4 Verifying the integrity of the error message
-
-    In addition to verifying the cryptographic checksum for the error
-    message, the client must verify that the error message is bound to
-    its request.  This is done by comparing the ctime field in the
-    error message to its counterpart in the request message.
-
-
-4.  E-DATA types
-
-    Since the e-data types must not conflict with preauthentication data
-    types, we propose that the preauthentication data types in the range
-    of 2048 and above be reserved for use as e-data types.
-
-    We define the following e-data type in support of integrity checking
-    for the Kerberos error message:
-
-    CHECKSUM = 2048 -- the keyed checksum described above
-
-
-5.  Discussion
-
-
-5.1 e-data types
-
-    The extension for Kerberos error messages, as outlined above, is
-    extensible to allow for definition of other error data types. 
-    We propose that the following e-data types be reserved:
-
-    KDCTIME = 2049
-    The error data would consist of the KDCs time in KerberosTime.
-    This data would be used by the client to adjust for clock skew.
-
-    REDIRECT = 2050
-    The error data would consist of a hostname.  The hostname would
-    indicate the authoritative KDC from which to obtain a TGT.
-
-
-5.2 e-data types vs. error code specific data formats
-
-    Since RFC 1510 does not define an error data type, the data format
-    must be explicitly specified for each error code.  This draft has
-    proposed an extension to RFC 1510 that would introduce the concept
-    of error data types.  This would allow for a manageable set of data
-    types to be used for any error message.  The authors assume that
-    the introduction of this e-data structure will not break any
-    existing Kerberos implementations.
-
-
-6.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication
-        Service (V5).  Request for Comments: 1510
-    [2] J. Kohl, C. Neuman.  The Kerberos Network Authentication
-        Service (V5).  Request for Comments: 1510 p.67
-
-
-7.  Authors
-
-    Ari Medvinsky       <ari.medvinsky@cybersafe.com>
-    Matthew Hur         <matt.hur@cybersafe.com>
-    Dominique Brezinski <dominique.brezinski@cybersafe.com>
-
-    CyberSafe Corporation 
-    1605 NW Sammamish Road
-    Suite 310
-    Issaquah, WA 98027-5378
-    Phone: (206) 391-6000
-    Fax:   (206) 391-0508
-    http:/www.cybersafe.com
-
-
-    Brian Tung  <brian@isi.edu>
-    Gene Tsudik <gts@isi.edu>
-
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: (310) 822-1511
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt b/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt
deleted file mode 100644
index b3ec336b6..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-02.txt
+++ /dev/null
@@ -1,174 +0,0 @@
-INTERNET-DRAFT                                        Jonathan Trostle
-draft-ietf-cat-kerberos-extra-tgt-02.txt              Cisco Systems
-Updates: RFC 1510                                     Michael M. Swift
-expires January 30, 2000                              University of WA
-
-
-    Extension to Kerberos V5 For Additional Initial Encryption
-
-0. Status Of This Memo
-
-   This document is an Internet-Draft and is in full conformance
-   with all provisions of Section 10 of RFC2026.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-1. Abstract
-
-   This document defines an extension to the Kerberos protocol
-   specification (RFC 1510) [1] to enable a preauthentication field in
-   the AS_REQ message to carry a ticket granting ticket. The session
-   key from this ticket granting ticket will be used to
-   cryptographically strengthen the initial exchange in either the
-   conventional Kerberos V5 case or in the case the user stores their
-   encrypted private key on the KDC [2].
-
-
-2. Motivation
-
-   In Kerberos V5, the initial exchange with the KDC consists of the
-   AS_REQ and AS_REP messages. For users, the encrypted part of the
-   AS_REP message is encrypted in a key derived from a password.
-   Although a password policy may be in place to prevent dictionary
-   attacks, brute force attacks may still be a concern due to
-   insufficient key length.
-
-   This draft specifies an extension to the Kerberos V5 protocol to
-   allow a ticket granting ticket to be included in an AS_REQ message
-   preauthentication field. The session key from this ticket granting
-   ticket will be used to cryptographically strengthen the initial
-
-   exchange in either the conventional Kerberos V5 case or in the case
-   the user stores their encrypted private key on the KDC [2]. The
-   session key from the ticket granting ticket is combined with the
-   user password key (key K2 in the encrypted private key on KDC
-   option) using HMAC to obtain a new triple des key that is used in
-   place of the user key in the initial exchange. The ticket granting
-   ticket could be obtained by the workstation using its host key.
-
-3. The Extension
-
-   The following new preauthentication type is proposed:
-
-      PA-EXTRA-TGT                         22
-
-   The preauthentication-data field contains a ticket granting ticket
-   encoded as an ASN.1 octet string. The server realm of the ticket
-   granting ticket must be equal to the realm in the KDC-REQ-BODY of
-   the AS_REQ message. In the absence of a trust relationship, the
-   local Kerberos client should send the AS_REQ message without this
-   extension.
-
-   In the conventional (non-pkinit) case, we require the RFC 1510
-   PA-ENC-TIMESTAMP preauthentication field in the AS_REQ message.
-   If neither it or the PA-PK-KEY-REQ preauthentication field is
-   included in the AS_REQ message, the KDC will reply with a
-   KDC_ERR_PREAUTH_FAILED error message.
-
-   We propose the following new etypes:
-
-     des3-cbc-md5-xor                              16
-     des3-cbc-sha1-xor                             17
-
-   The encryption key is obtained by:
-
-   (1) Obtaining an output M from the HMAC-SHA1 function [3] using
-       the user password key (the key K2 in the encrypted private
-       key on KDC option of pkinit) as the text and the triple des
-       session key as the K input in HMAC:
-
-       M = H(K XOR opad, H(K XOR ipad, text)) where H = SHA1.
-
-       The session key from the accompanying ticket granting ticket
-       must be a triple des key when one of the triple des xor
-       encryption types is used.
-   (2) Concatenate the output M (20 bytes) with the first 8 non-parity
-       bits of the triple-des ticket granting ticket session key to
-       get 168 bits that will be used for the new triple-des encryption
-       key.
-   (3) Set the parity bits of the resulting key.
-
-   The resulting triple des key is used to encrypt the timestamp
-   for the PA-ENC-TIMESTAMP preauthentication value (or in the
-   encrypted private key on KDC option of pkinit, it is used in
-   place of the key K2 to both sign in the PA-PK-KEY-REQ and for
-   encryption in the PA-PK-KEY-REP preauthentication types).
-
-   If the KDC decrypts the encrypted timestamp and it is not within
-   the appropriate clock skew period, the KDC will reply with the
-   KDC_ERR_PREAUTH_FAILED error. The same error will also be sent if
-   the above ticket granting ticket fails to decrypt properly, or if
-   it is not a valid ticket.
-
-   The KDC will create the shared triple des key from the ticket
-   granting ticket session key and the user password key (the key K2
-   in the encrypted private key on KDC case) using HMAC as specified
-   above and use it to validate the AS_REQ message and then to
-   encrypt the encrypted part of the AS_REP message (use it in place
-   of the key K2 for encryption in the PA-PK-KEY-REP preauthentication
-   field).
-
-   Local workstation policy will determine the exact behaviour of
-   the Kerberos client with respect to the extension protocol. For
-   example, the client should consult policy to decide when to use
-   use the extension. This policy could be dependent on the user
-   identity, or whether the workstation is in the same realm as the
-   user. One possibility is for the workstation logon to fail if
-   the extension is not used. Another possibility is for the KDC
-   to set a flag in tickets issued when this extension is used.
-
-   A similar idea was proposed in OSF DCE RFC 26.0 [4]; there a
-   preauthentication field containing a ticket granting ticket,
-   a randomly generated subkey encrypted in the session key from
-   the ticket, and a timestamp structure encrypted in the user
-   password and then the randomly generated subkey was proposed.
-   Some advantages of the current proposal are that the KDC has two
-   fewer decryptions to perform per request and the client does not
-   have to generate a random key.
-
-4. Bibliography
-
-   [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
-   Service (V5). Request for Comments 1510.
-
-   [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle.
-   Public Key Cryptography for Initial Authentication in Kerberos.
-   ftp://ds.internic.net/internet-drafts/
-   draft-ietf-cat-kerberos-pkinit-08.txt
-
-   [3] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for
-   Message Authentication. Request for Comments 2104.
-
-   [4] J. Pato. Using Pre-authentication to Avoid Password Guessing
-   Attacks. OSF DCE SIG Request for Comments 26.0.
-
-5. Acknowledgement: We thank Ken Hornstein for some helpful comments.
-
-6. Expires January 30, 2000.
-
-7. Authors' Addresses
-
-   Jonathan Trostle
-   170 W. Tasman Dr.
-   San Jose, CA 95134, U.S.A.
-
-   Email: jtrostle@cisco.com
-   Phone: (408) 527-6201
-
-   Michael Swift
-   Email: mikesw@cs.washington.edu
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt b/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt
deleted file mode 100644
index d09a2ded5..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-extra-tgt-03.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-This Internet-Draft has expired and is no longer available.
-
-Unrevised documents placed in the Internet-Drafts directories have a
-maximum life of six months. After that time, they must be updated, or
-they will be deleted. This document was deleted on March 20, 2000.
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt
deleted file mode 100644
index 4b193c573..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-01.txt
+++ /dev/null
@@ -1,282 +0,0 @@
-INTERNET-DRAFT                                              Brian Tung
-draft-ietf-cat-kerberos-pk-cross-01.txt                 Tatyana Ryutov
-Updates: RFC 1510                                      Clifford Neuman
-expires September 30, 1997                                 Gene Tsudik
-                                                                   ISI
-                                                       Bill Sommerfeld
-                                                       Hewlett-Packard
-                                                         Ari Medvinsky
-                                                           Matthew Hur
-                                                 CyberSafe Corporation
-
-
-    Public Key Cryptography for Cross-Realm Authentication in Kerberos
-
-
-0.  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 learn the current status of any Internet-Draft, please check
-    the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
-    Shadow Directories on ds.internic.net (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-cross-01.txt, and expires September 30,
-    1997.  Please send comments to the authors.
-
-
-1.  Abstract
-
-    This document defines extensions to the Kerberos protocol
-    specification (RFC 1510, "The Kerberos Network Authentication
-    Service (V5)", September 1993) to provide a method for using
-    public key cryptography during cross-realm authentication.  The
-    methods defined here specify the way in which message exchanges
-    are to be used to transport cross-realm secret keys protected by
-    encryption under public keys certified as belonging to KDCs.
-
-
-2.  Motivation
-
-    The advantages provided by public key cryptography--ease of
-    recoverability in the event of a compromise, the possibility of
-    an autonomous authentication infrastructure, to name a few--have
-    produced a demand for use by Kerberos authentication protocol.  A
-    draft describing the use of public key cryptography in the initial
-    authentication exchange in Kerberos has already been submitted.
-    This draft describes its use in cross-realm authentication.
-
-    The principal advantage provided by public key cryptography in
-    cross-realm authentication lies in the ability to leverage the
-    existing public key infrastructure.  It frees the Kerberos realm
-    administrator from having to maintain separate keys for each other
-    realm with which it wishes to exchange authentication information,
-    or to utilize a hierarchical arrangement, which may pose problems
-    of trust.
-
-    Even with the multi-hop cross-realm authentication, there must be
-    some way to locate the path by which separate realms are to be
-    transited.  The current method, which makes use of the DNS-like
-    realm names typical to Kerberos, requires trust of the intermediate
-    KDCs.
-
-    The methods described in this draft allow a realm to specify, at
-    the time of authentication, which certification paths it will
-    trust.  A shared key for cross-realm authentication can be
-    established, for a period of time.  Furthermore, these methods are
-    transparent to the client, so that only the KDC's need to be
-    modified to use them.
-
-    It is not necessary to implement the changes described in the
-    "Public Key Cryptography for Initial Authentication" draft to make
-    use of the changes in this draft.  We solicit comments about the
-    interaction between the two protocol changes, but as of this
-    writing, the authors do not perceive any obstacles to using both.
-
-
-3.  Protocol Amendments
-
-    We assume that the user has already obtained a TGT.  To perform
-    cross-realm authentication, the user sends a request to the local
-    KDC as per RFC 1510.  If the two realms share a secret key, then
-    cross-realm authentication proceeds as usual.  Otherwise, the
-    local KDC may attempt to establish a shared key with the remote
-    KDC using public key cryptography, and exchange this key through
-    the cross-realm ticket granting ticket.
-
-    We will consider the specific channel on which the message
-    exchanges take place in Section 5 below.
-
-
-3.1.  Changes to the Cross-Realm Ticket Granting Ticket
-
-    In order to avoid the need for changes to the "installed base" of
-    Kerberos application clients and servers, the only protocol change
-    is to the way in which cross-realm ticket granting tickets (TGTs)
-    are encrypted; as these tickets are opaque to clients and servers,
-    the only change visible to them will be the increased size of the
-    tickets.
-
-    Cross-realm TGTs are granted by a local KDC to authenticate a user
-    to a remote KDC's ticket granting service.  In standard Kerberos,
-    they are encrypted using a shared secret key manually configured
-    into each KDC.
-
-    In order to incorporate public key cryptography, we define a new
-    encryption type, "ENCTYPE_PK_CROSS".  Operationally, this encryption
-    type transforms an OCTET STRING of plaintext (normally an EncTktPart)
-    into the following SEQUENCE:
-
-        PKCrossOutput ::= SEQUENCE {
-            certificate [0]     OCTET STRING OPTIONAL,
-                                    -- public key certificate
-                                    -- of local KDC
-            encSharedKey [1]    EncryptedData,
-                                    -- of type EncryptionKey
-                                    -- containing random symmetric key
-                                    -- encrypted using public key
-                                    -- of remote KDC
-            sigSharedKey [2]    Signature,
-                                    -- of encSharedKey
-                                    -- using signature key
-                                    -- of local KDC
-            pkEncData [3]       EncryptedData,
-                                    -- (normally) of type EncTktPart
-                                    -- encrypted using encryption key
-                                    -- found in encSharedKey
-        }
-
-    PKCROSS operates as follows: when a client submits a request for
-    cross-realm authentication, the local KDC checks to see if it has
-    a long-term shared key established for that realm.  If so, it uses
-    this key as per RFC 1510.
-
-    If not, it sends a request for information to the remote KDC.  The
-    content of this message is immaterial, as it does not need to be
-    processed by the remote KDC; for the sake of consistency, we define
-    it as follows:
-
-        RemoteRequest ::= [APPLICATION 41] SEQUENCE {
-            nonce [0]                   INTEGER
-        }
-
-    The remote KDC replies with a list of all trusted certifiers and
-    all its (the remote KDC's) certificates.  We note that this response
-    is universal and does not depend on which KDC makes the request:
-
-        RemoteReply ::= [APPLICATION 42] SEQUENCE {
-            trustedCertifiers [0]       SEQUENCE OF PrincipalName,
-            certificates[1]             SEQUENCE OF Certificate,
-            encTypeToUse [1]            SEQUENCE OF INTEGER
-                                            -- encryption types usable
-                                            -- for encrypting pkEncData
-        }
-
-        Certificate ::= SEQUENCE {
-            CertType                [0] INTEGER,
-                                        -- type of certificate
-                                        -- 1 = X.509v3 (DER encoding)
-                                        -- 2 = PGP (per PGP draft)
-            CertData                [1] OCTET STRING
-                                        -- actual certificate
-                                        -- type determined by CertType
-        } -- from pk-init draft
-
-    Upon receiving this reply, the local KDC determines whether it has
-    a certificate the remote KDC trusts, and whether the remote KDC has
-    a certificate the local KDC trusts.  If so, it issues a ticket
-    encrypted using the ENCTYPE_PK_CROSS encryption type defined above.
-
-
-3.2.  Profile Caches
-
-    We observe that using PKCROSS as specified above requires two
-    private key operations: a signature generation by the local KDC and
-    a decryption by the remote KDC.  This cost can be reduced in the
-    long term by judicious caching of the encSharedKey and the
-    sigSharedKey.
-
-    Let us define a "profile" as the encSharedKey and sigSharedKey, in
-    conjunction with the associated remote realm name and decrypted
-    shared key (the key encrypted in the encSharedKey).
-
-    To optimize these interactions, each KDC maintains two caches, one
-    for outbound profiles and one for inbound profiles.  When generating
-    an outbound TGT for another realm, the local KDC first checks to see
-    if the corresponding entry exists in the outbound profile cache; if
-    so, it uses its contents to form the first three fields of the
-    PKCrossOutput; the shared key is used to encrypt the data for the
-    fourth field.  If not, the components are generated fresh and stored
-    in the outbound profile cache.
-
-    Upon receipt of the TGT, the remote realm checks its inbound profile
-    cache for the corresponding entry.  If it exists, then it uses the
-    contents of the entry to decrypt the data encrypted in the pkEncData.
-    If not, then it goes through the full process of verifying and
-    extracting the shared key; if this is successful, then a new entry
-    is created in the inbound profile cache.
-
-    The inbound profile cache should support multiple entries per realm,
-    in the event that the initiating realm is replicated.
-
-
-4.  Finding Realms Supporting PKCROSS
-
-    If either the local realm or the destination realm does not support
-    PKCROSS, or both do not, the mechanism specified in Section 3 can
-    still be used in obtaining the desired remote TGT.
-
-    In the reference Kerberos implementations, the default behavior is
-    to traverse a path up and down the realm name hierarchy, if the
-    two realms do not share a key.  There is, however, the possibility
-    of using cross links--i.e., keys shared between two realms that
-    are non-contiguous in the realm name hierarchy--to shorten the
-    path, both to minimize delay and the number of intermediate realms
-    that need to be trusted.
-
-    PKCROSS can be used as a way to provide cross-links even in the
-    absence of shared keys.  If the client is aware that one or two
-    intermediate realms support PKCROSS, then a combination of
-    PKCROSS and conventional cross-realm authentication can be used
-    to reach the final destination realm.
-
-    We solicit discussion on the best methods for clients and KDCs to
-    determine or advertise support for PKCROSS.
-
-
-5.  Message Ports
-
-    We have not specified the port on which KDCs supporting PKCROSS
-    should listen to receive the request for information messages noted
-    above.  We solicit discussion on which port should be used.  We
-    propose to use the standard Kerberos ports (well-known 88 or 750),
-    but another possibility is to use a completely different port.
-
-    We also solicit discussion on what other approaches can be taken to
-    obtain the information in the RemoteReply (e.g., secure DNS or some
-    other repository).
-
-
-6.  Expiration Date
-
-    This Internet-Draft will expire on September 30, 1997.
-
-
-7.  Authors' Addresses
-
-    Brian Tung
-    Tatyana Ryutov
-    Clifford Neuman
-    Gene Tsudik
-    USC/Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey, CA 90292-6695
-    Phone: +1 310 822 1511
-    E-Mail: {brian, tryutov, bcn, gts}@isi.edu
-
-    Bill Sommerfeld
-    Hewlett Packard
-    300 Apollo Drive
-    Chelmsford MA 01824
-    Phone: +1 508 436 4352
-    E-Mail: sommerfeld@apollo.hp.com
-
-    Ari Medvinsky
-    Matthew Hur
-    CyberSafe Corporation
-    1605 NW Sammamish Road Suite 310
-    Issaquah WA 98027-5378
-    Phone: +1 206 391 6000
-    E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt
deleted file mode 100644
index 1ab2b03e0..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-06.txt
+++ /dev/null
@@ -1,523 +0,0 @@
-
-INTERNET-DRAFT                                               Matthew Hur
-draft-ietf-cat-kerberos-pk-cross-06.txt            CyberSafe Corporation
-Updates: RFC 1510                                             Brian Tung
-expires October 10, 2000                                  Tatyana Ryutov
-                                                         Clifford Neuman
-                                                             Gene Tsudik
-                                                                     ISI
-                                                           Ari Medvinsky
-                                                                Keen.com
-                                                         Bill Sommerfeld
-                                                         Hewlett-Packard
-
-
-    Public Key Cryptography for Cross-Realm Authentication in Kerberos
-
-
-0.  Status Of this Memo
-
-    This document is an Internet-Draft and is in full conformance with
-    all provisions of Section 10 of RFC 2026.  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.''
-
-     The list of current Internet-Drafts can be accessed at
-     http://www.ietf.org/ietf/1id-abstracts.txt
-
-     The list of Internet-Draft Shadow Directories can be accessed at
-     http://www.ietf.org/shadow.html.
-
-
-
-    To learn the current status of any Internet-Draft, please check
-    the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
-    Shadow Directories on ftp.ietf.org (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-cross-06.txt, and expires May 15, 1999.
-    Please send comments to the authors.
-
-
-1.  Abstract
-
-    This document defines extensions to the Kerberos protocol 
-    specification [1] to provide a method for using public key 
-    cryptography to enable cross-realm authentication.  The methods 
-    defined here specify the way in which message exchanges are to be 
-    used to transport cross-realm secret keys protected by encryption 
-    under public keys certified as belonging to KDCs.
-
-
-2.  Introduction
-
-    The Kerberos authentication protocol [2]  can leverage the 
-    advantages provided by public key cryptography.  PKINIT [3] 
-    describes the use of public key cryptography in the initial 
-    authentication exchange in Kerberos.  PKTAPP [4] describes how an 
-    application service can essentially issue a kerberos ticket to 
-    itself after utilizing public key cryptography for authentication. 
-    Another informational document species the use of public key 
-    crypography for anonymous authentication in Kerberos [5].  This 
-    specification describes the use of public key crpytography in cross- 
-    realm authentication.
-
-    Without the use of public key cryptography, administrators must 
-    maintain separate keys for every realm which wishes to exchange 
-    authentication information with another realm (which implies n(n-1) 
-    keys), or they must utilize a hierachichal arrangement of realms, 
-    which may complicate the trust model by requiring evaluation of 
-    transited realms.
-
-    Even with the multi-hop cross-realm authentication, there must be 
-    some way to locate the path by which separate realms are to be 
-    transited.  The current method, which makes use of the DNS-like 
-    realm names typical to Kerberos, requires trust of the intermediate 
-    KDCs.
-
-    PKCROSS utilizes a public key infrastructure (PKI) [6] to simplify 
-    the administrative burden of maintaining cross-realm keys.  Such 
-    usage leverages a PKI for a non-centrally-administratable environment 
-    (namely, inter-realm).  Thus, a shared key for cross-realm 
-    authentication can be established for a set period of time, and a 
-    remote realm is able to issue policy information that is returned to 
-    itself when a client requests cross-realm authentication. Such policy 
-    information may be in the form of restrictions [7].  Furthermore, 
-    these methods are transparent to the client; therefore, only the KDCs 
-    need to be modified to use them.  In this way, we take advantage of 
-    the the distributed trust management capabilities of public key 
-    crypography while maintaining the advantages of localized trust 
-    management provided by Kerberos.
-
-
-    Although this specification utilizes the protocol specfied in the 
-    PKINIT specification, it is not necessary to implement client 
-    changes in order to make use of the changes in this document.
-
-
-3.  Objectives
-
-    The objectives of this specification are as follows:
-    
-      1.  Simplify the administration required to establish Kerberos
-          cross-realm keys.
-          
-      2.  Avoid modification of clients and application servers.
-
-      3.  Allow remote KDC to control its policy on cross-realm
-          keys shared between KDCs, and on cross-realm tickets
-          presented by clients.
-
-      4.  Remove any need for KDCs to maintain state about keys
-          shared with other KDCs.
-
-      5.  Leverage the work done for PKINIT to provide the public key
-          protocol for establishing symmetric cross realm keys.
-
-
-4.  Definitions
-
-    The following notation is used throughout this specification:
-    KDC_l ........... local KDC
-    KDC_r ........... remote KDC
-    XTKT_(l,r) ...... PKCROSS ticket that the remote KDC issues to the
-                      local KDC
-    TGT_(c,r) ....... cross-realm TGT that the local KDC issues to the
-                      client for presentation to the remote KDC
-
-    This specification defines the following new types to be added to the 
-    Kerberos specification:
-      PKCROSS kdc-options field in the AS_REQ is bit 9
-      TE-TYPE-PKCROSS-KDC       2
-      TE-TYPE-PKCROSS-CLIENT    3
-
-    This specification defines the following ASN.1 type for conveying
-    policy information:
-    CrossRealmTktData ::= SEQUENCE OF TypedData
-
-    This specification defines the following types for policy information 
-    conveyed in CrossRealmTktData:
-      PLC_LIFETIME              1
-      PLC_SET_TKT_FLAGS         2
-      PLC_NOSET_TKT_FLAGS       3
-
-    TicketExtensions are defined per the Kerberos specification [8]:
-    TicketExtensions ::= SEQUENCE OF TypedData
-      Where
-        TypedData ::=   SEQUENCE {
-            data-type[0]   INTEGER,
-            data-value[1]  OCTET STRING OPTIONAL
-        }
-
-
-5.  Protocol Specification
-
-    We assume that the client has already obtained a TGT.  To perform
-    cross-realm authentication, the client does exactly what it does
-    with ordinary (i.e. non-public-key-enabled) Kerberos; the only
-    changes are in the KDC; although the ticket which the client
-    forwards to the remote realm may be changed.  This is acceptable
-    since the client treats the ticket as opaque.
-
-
-5.1.  Overview of Protocol
-
-    The basic operation of the PKCROSS protocol is as follows:
-
-        1.  The client submits a request to the local KDC for
-            credentials for the remote realm.  This is just a typical
-            cross realm request that may occur with or without PKCROSS. 
-
-        2.  The local KDC submits a PKINIT request to the remote KDC to
-            obtain a "special" PKCROSS ticket.  This is a standard
-            PKINIT request, except that PKCROSS flag (bit 9) is set in
-            the kdc-options field in the AS_REQ.
-
-        3.  The remote KDC responds as per PKINIT, except that
-            the ticket contains a TicketExtension, which contains
-            policy information such as lifetime of cross realm tickets
-            issued by KDC_l to a client.  The local KDC must reflect
-            this policy information in the credentials it forwards to
-            the client.  Call this ticket XTKT_(l,r) to indicate that
-            this ticket is used to authenticate the local KDC to the
-            remote KDC.
-
-        4.  The local KDC passes a ticket, TGT_(c,r) (the cross realm
-            TGT between the client and remote KDC), to the client.
-            This ticket contains in its TicketExtension field the
-            ticket, XTKT_(l,r), which contains the cross-realm key.
-            The TGT_(c,r) ticket is encrypted using the key sealed in
-            XTKT_(l,r).  (The TicketExtension field is not encrypted.)
-            The local KDC may optionally include another TicketExtension
-            type that indicates the hostname and/or IP address for the
-            remote KDC.
-
-        5.  The client submits the request directly to the remote
-            KDC, as before.
-            
-        6.  The remote KDC extracts XTKT_(l,r) from the TicketExtension
-            in order to decrypt the encrypted part of TGT_(c,r).
-
-    --------------------------------------------------------------------
-    
-    Client                Local KDC (KDC_l)           Remote KDC (KDC_r)
-    ------                -----------------           ------------------
-    Normal Kerberos
-    request for
-    cross-realm
-    ticket for KDC_r
-    ---------------------->
-    
-                          PKINIT request for
-                          XTKT(l,r) - PKCROSS flag
-                          set in the AS-REQ
-                          * ------------------------->
-                          
-                                                      PKINIT reply with
-                                                      XTKT_(l,r) and
-                                                      policy info in
-                                                      ticket extension
-                                           <-------------------------- *
-
-                          Normal Kerberos reply
-                          with TGT_(c,r) and
-                          XTKT(l,r) in ticket
-                          extension
-         <--------------------------------- 
-
-    Normal Kerberos
-    cross-realm TGS-REQ
-    for remote
-    application
-    service with
-    TGT_(c,r) and
-    XTKT(l,r) in ticket
-    extension
-    ------------------------------------------------->
-
-                                                      Normal Kerberos
-                                                      cross-realm
-                                                      TGS-REP
-        <---------------------------------------------------------------
-
-    * Note that the KDC to KDC messages occur only periodically, since
-      the local KDC caches the XTKT_(l,r).
-    --------------------------------------------------------------------
-    
-
-    Sections 5.2 through 5.4 describe in detail steps 2 through 4
-    above.  Section 5.6 describes the conditions under which steps
-    2 and 3 may be skipped.
-
-    Note that the mechanism presented above requires infrequent KDC to 
-    KDC communication (as dictated by policy - this is discussed
-    later).  Without such an exchange, there are the following issues:
-    1) KDC_l would have to issue a ticket with the expectation that
-       KDC_r will accept it.
-    2) In the message that the client sends to KDC_r, KDC_l would have
-       to authenticate KDC_r with credentials that KDC_r trusts.
-    3) There is no way for KDC_r to convey policy information to KDC_l.
-    4) If, based on local policy, KDC_r does not accept a ticket from
-       KDC_l, then the client gets stuck in the middle.  To address such
-       an issue would require modifications to standard client
-       processing behavior.
-    Therefore, the infreqeunt use of KDC to KDC communication assures
-    that inter-realm KDC keys may be established in accordance with local
-    policies and that clients may continue to operate without
-    modification.
-
-
-5.2.  Local KDC's Request to Remote KDC
-
-    When the local KDC receives a request for cross-realm authentication, 
-    it first checks its ticket cache to see if it has a valid PKCROSS 
-    ticket, XTKT_(l,r).  If it has a valid XTKT_(l,r), then it does not 
-    need to send a request to the remote KDC (see section 5.5).
-
-    If the local KDC does not have a valid XTKT_(l,r), it sends a     
-    request to the remote KDC in order to establish a cross realm key and 
-    obtain the XTKT_(l,r).  This request is in fact a PKINIT request as 
-    described in the PKINIT specification; i.e., it consists of an AS-REQ 
-    with a PA-PK-AS-REQ included as a preauthentication field.  Note, 
-    that the AS-REQ MUST have the PKCROSS flag (bit 9) set in the 
-    kdc_options field of the AS-REQ.  Otherwise, this exchange exactly 
-    follows the description given in the PKINIT specification.  In 
-    addition, the naming
-
-
-5.3.  Remote KDC's Response to Local KDC
-
-    When the remote KDC receives the PKINIT/PKCROSS request from the
-    local KDC, it sends back a PKINIT response as described in
-    the PKINIT specification with the following exception: the encrypted
-    part of the Kerberos ticket is not encrypted with the krbtgt key;
-    instead, it is encrypted with the ticket granting server's PKCROSS
-    key.  This key, rather than the krbtgt key, is used because it
-    encrypts a ticket used for verifying a cross realm request rather
-    than for issuing an application service ticket.  Note that, as a
-    matter of policy, the session key for the XTKT_(l,r) MAY be of
-    greater strength than that of a session key for a normal PKINIT
-    reply, since the XTKT_(l,r) SHOULD be much longer lived than a
-    normal application service ticket.
-
-    In addition, the remote KDC SHOULD include policy information in the 
-    XTKT_(l,r).  This policy information would then be reflected in the 
-    cross-realm TGT, TGT_(c,r).  Otherwise, the policy for TGT_(c,r) 
-    would be dictated by KDC_l rather than by KDC_r.  The local KDC MAY 
-    enforce a more restrictive local policy when creating a cross-realm 
-    ticket, TGT_(c,r).  For example, KDC_r  may dictate a lifetime 
-    policy of eight hours, but KDC_l may create TKT_(c,r) with a 
-    lifetime of four hours, as dictated by local policy.  Also, the 
-    remote KDC MAY include other information about itself along with the 
-    PKCROSS ticket.  These items are further discussed in section 6 
-    below.
-
-
-5.4.  Local KDC's Response to Client
-
-    Upon receipt of the PKINIT/CROSS response from the remote KDC,
-    the local KDC formulates a response to the client.  This reply
-    is constructed exactly as in the Kerberos specification, except
-    for the following:
-
-    A) The local KDC places XTKT_(l,r) in the TicketExtension field of
-       the client's cross-realm, ticket, TGT_(c,r), for the remote realm.
-       Where
-          data-type   equals 3 for TE-TYPE-PKCROSS-CLIENT
-          data-value  is ASN.1 encoding of XTKT_(l,r)
-     
-    B) The local KDC adds the name of its CA to the transited field of
-       TGT_(c,r).
-
-
-5.5   Remote KDC's Processing of Client Request
-
-    When the remote KDC, KDC_r, receives a cross-realm ticket, 
-    TGT_(c,r), and it detects that the ticket contains a ticket 
-    extension of type TE-TYPE-PKCROSS-CLIENT, KDC_r must first decrypt 
-    the ticket, XTKT_(l,r), that is encoded in the ticket extension.  
-    KDC_r uses its PKCROSS key in order to decrypt XTKT_(l,r).  KDC_r 
-    then uses the key obtained from XTKT_(l,r) in order to decrypt the 
-    cross-realm ticket, TGT_(c,r).
-
-    KDC_r MUST verify that the cross-realm ticket, TGT_(c,r) is in 
-    compliance with any policy information contained in XTKT_(l,r) (see 
-    section 6).  If the TGT_(c,r) is not in compliance with policy, then 
-    the KDC_r responds to the client with a KRB-ERROR message of type 
-    KDC_ERR_POLICY.
-
-    
-5.6.  Short-Circuiting the KDC-to-KDC Exchange
-
-    As we described earlier, the KDC to KDC exchange is required only 
-    for establishing a symmetric, inter-realm key.  Once this key is 
-    established (via the PKINIT exchange), no KDC to KDC communication 
-    is required until that key needs to be renewed.  This section 
-    describes the circumstances under which the KDC to KDC exchange 
-    described in Sections 5.2 and 5.3 may be skipped.
-
-    The local KDC has a known lifetime for TGT_(c,r).  This lifetime may 
-    be determined by policy information included in XTKT_(l,r), and/or 
-    it may be determined by local KDC policy.  If the local KDC already 
-    has a ticket XTKT(l,r), and the start time plus the lifetime for 
-    TGT_(c,r) does not exceed the expiration time for XTGT_(l,r), then 
-    the local KDC may skip the exchange with the remote KDC, and issue a 
-    cross-realm ticket to the client as described in Section 5.4.
-
-    Since the remote KDC may change its PKCROSS key (referred to in 
-    Section 5.2) while there are PKCROSS tickets still active, it SHOULD 
-    cache the old PKCROSS keys until the last issued PKCROSS ticket 
-    expires.  Otherwise, the remote KDC will respond to a client with a 
-    KRB-ERROR message of type KDC_ERR_TGT_REVOKED.
-
-
-6.  Extensions for the PKCROSS Ticket
-
-    As stated in section 5.3, the remote KDC SHOULD include policy 
-    information in XTKT_(l,r).  This policy information is contained in 
-    a TicketExtension, as defined by the Kerberos specification, and the 
-    authorization data of the ticket will contain an authorization 
-    record of type AD-IN-Ticket-Extensions.  The TicketExtension defined 
-    for use by PKCROSS is TE-TYPE-PKCROSS-KDC.
-      Where
-        data-type   equals 2 for TE-TYPE-PKCROSS-KDC
-        data-value  is ASN.1 encoding of CrossRealmTktData
-
-      CrossRealmTktData ::= SEQUENCE OF TypedData
-
-
-      ------------------------------------------------------------------
-      CrossRealmTktData types and the corresponding data are interpreted 
-      as follows:
-
-                                                            ASN.1 data
-      type                value   interpretation            encoding
-      ----------------    -----   --------------            ----------
-      PLC_LIFETIME          1     lifetime (in seconds)     INTEGER
-                                  for TGT_(c,r) 
-                                  - cross-realm tickets
-                                    issued for clients by
-                                    TGT_l
-
-      PLC_SET_TKT_FLAGS     2     TicketFlags that must     BITSTRING
-                                  be set
-                                  - format defined by
-                                    Kerberos specification
-
-      PLC_NOSET_TKT_FLAGS   3     TicketFlags that must     BITSTRING
-                                  not be set
-                                  - format defined by
-                                    Kerberos specification
-
-      Further types may be added to this table.
-      ------------------------------------------------------------------
-
-
-7.  Usage of Certificates
-
-    In the cases of PKINIT and PKCROSS, the trust in a certification 
-    authority is equivalent to Kerberos cross realm trust.  For this 
-    reason, an implementation MAY choose to use the same KDC certificate 
-    when the KDC is acting in any of the following three roles:
-      1) KDC is authenticating clients via PKINIT
-      2) KDC is authenticating another KDC for PKCROSS 
-      3) KDC is the client in a PKCROSS exchange with another KDC
-
-    Note that per PKINIT, the KDC X.509 certificate (the server in a 
-    PKINIT exchange) MUST contain the principal name of the KDC in the 
-    subjectAltName field.
-
-
-8.  Transport Issues
-
-    Because the messages between the KDCs involve PKINIT exchanges, and 
-    PKINIT recommends TCP as a transport mechanism (due to the length of 
-    the messages and the likelihood that they will fragment), the same 
-    recommendation for TCP applies to PKCROSS as well.
-
-    
-9. Security Considerations
-
-   Since PKCROSS utilizes PKINIT, it is subject to the same security
-   considerations as PKINIT.  Administrators should assure adherence 
-   to security policy - for example, this affects the PKCROSS policies
-   for cross realm key lifetime and for policy propogation from the 
-   PKCROSS ticket, issued from a remote KDC to a local KDC, to
-   cross realm tickets that are issued by a local KDC to a client.
-
-
-10. Bibliography
-
-  [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service 
-  (V5).  Request for Comments 1510.
-
-  [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-  for Computer Networks, IEEE Communications, 32(9):33-38.  September
-  1994.
-
-  [3] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S.Medvinsky, J. Wray
-  J. Trostle.  Public Key Cryptography for Initial Authentication
-  in Kerberos.
-  draft-ietf-cat-kerberos-pk-init-11.txt
-
-  [4] A. Medvinsky, M. Hur, S. Medvinsky, B. Clifford Neuman.  Public 
-  Key Utilizing Tickets for Application Servers (PKTAPP). draft-ietf-
-  cat-pktapp-02.txt
-
-  [5] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
-  Kerberos. draft-ietf-cat-kerberos-anoncred-01.txt
-
-  [6] ITU-T (formerly CCITT) Information technology - Open Systems
-  Interconnection - The Directory: Authentication Framework
-  Recommendation X.509 ISO/IEC 9594-8
-    
-  [7] B.C. Neuman, Proxy-Based Authorization and Accounting for 
-  Distributed Systems.  In Proceedings of the 13th International 
-  Conference on Distributed Computing Systems, May 1993.
-
-  [8] C.Neuman, J. Kohl, T. Ts'o.  The Kerberos Network Authentication 
-  Service (V5). draft-ietf-cat-kerberos-revisions-05.txt
-
-
-11. Authors' Addresses
-
-    Matthew Hur
-    CyberSafe Corporation
-    1605 NW Sammamish Road
-    Issaquah WA 98027-5378
-    Phone: +1 425 391 6000
-    E-mail: matt.hur@cybersafe.com
-
-    Brian Tung
-    Tatyana Ryutov
-    Clifford Neuman
-    Gene Tsudik
-    USC/Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey, CA 90292-6695
-    Phone: +1 310 822 1511
-    E-Mail: {brian, tryutov, bcn, gts}@isi.edu
-
-    Ari Medvinsky
-    Keen.com
-    2480 Sand Hill Road, Suite 200
-    Menlo Park, CA 94025
-    Phone +1 650 289 3134
-    E-mail: ari@keen.com
-
-    Bill Sommerfeld
-    Hewlett Packard
-    300 Apollo Drive
-    Chelmsford MA 01824
-    Phone: +1 508 436 4352
-    E-Mail: sommerfeld@apollo.hp.com
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-08.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-08.txt
deleted file mode 100644
index 41b8e8e5f..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-cross-08.txt
+++ /dev/null
@@ -1,542 +0,0 @@
-INTERNET-DRAFT                                               Matthew Hur
-draft-ietf-cat-kerberos-pk-cross-08.txt                    Cisco Systems
-Updates: RFC 1510                                             Brian Tung
-November 8, 2001 (Expires May 8, 2001)                    Tatyana Ryutov
-                                                         Clifford Neuman
-                                                                     ISI
-                                                           Ari Medvinsky
-                                                                Liberate
-                                                             Gene Tsudik
-                                                               UC Irvine
-                                                         Bill Sommerfeld
-                                                        Sun Microsystems
-
-
-    Public Key Cryptography for Cross-Realm Authentication in Kerberos
-
-
-0.  Status Of this Memo
-
-    This document is an Internet-Draft and is in full conformance with
-    all provisions of Section 10 of RFC 2026.  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 learn the current status of any Internet-Draft, please check
-    the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
-    Shadow Directories on ftp.ietf.org (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-     The list of current Internet-Drafts can be accessed at
-     http://www.ietf.org/1id-abstracts.html
-
-     The list of Internet-Draft Shadow Directories can be accessed at
-     http://www.ietf.org/shadow.html
-
-
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-cross-07.txt, and expires May 15, 2001.
-    Please send comments to the authors.
-
-
-1.  Abstract
-
-    This document defines extensions to the Kerberos protocol 
-    specification [KERB] to provide a method for using public key 
-    cryptography to enable cross-realm authentication.  The methods 
-    defined here specify the way in which message exchanges are to be 
-    used to transport cross-realm secret keys protected by encryption 
-    under public keys certified as belonging to KDCs.
-
-
-2.  Introduction
-
-    Symmetric and asymmetric key systems may co-exist within hybrid 
-    architectures in order to leverage the advantages and mitigiate 
-    issues within the respective systems.  An example of a hybrid 
-    solution that may employ both symmetric and asymmetric technologies 
-    is Kerberos ciphersuires in TLS [KERBTLS] which utilizes the 
-    Kerberos protocol [KERB] [KERB94] in conjunction with TLS [TLS] 
-    which has commonly been thought of as a public key protocol.
-
-    The Kerberos can leverage the advantages provided by public key 
-    cryptography.  PKINIT [PKINIT] describes the use of public key 
-    cryptography in the initial authentication exchange in Kerberos.  
-    PKTAPP [PKTAPP] describes how an application service can essentially 
-    issue a kerberos ticket to itself after utilizing public key 
-    cryptography for authentication.  This specification describes the 
-    use of public key crpytography in cross-realm authentication.
-
-    Without the use of public key cryptography, administrators must 
-    maintain separate keys for every realm which wishes to exchange 
-    authentication information with another realm (which implies n(n-1) 
-    keys), or they must utilize a hierachichal arrangement of realms, 
-    which may increase network traffic and complicate the trust model by 
-    requiring evaluation of transited realms.
-
-    Even with the multi-hop cross-realm authentication, there must be 
-    some way to locate the path by which separate realms are to be 
-    transited.  The current method, which makes use of the DNS-like 
-    realm names typical to Kerberos, requires trust of the intermediate 
-    KDCs.
-
-    PKCROSS utilizes a public key infrastructure (PKI) [X509] to 
-    simplify the administrative burden of maintaining cross-realm keys.  
-    Such usage leverages a PKI for a non-centrally-administratable 
-    environment (namely, inter-realm).  Thus, a shared key for cross- 
-    realm authentication can be established for a set period of time, 
-    and a remote realm is able to issue policy information that is 
-    returned to itself when a client requests cross-realm 
-    authentication. Such policy information may be in the form of 
-    restrictions [NEUMAN].  Furthermore, these methods are transparent 
-    to the client; therefore, only the KDCs need to be modified to use 
-    them.  In this way, we take advantage of the the distributed trust 
-    management capabilities of public key crypography while maintaining 
-    the advantages of localized trust management provided by Kerberos.
-
-
-    Although this specification utilizes the protocol specfied in the 
-    PKINIT specification, it is not necessary to implement client 
-    changes in order to make use of the changes in this document.
-
-
-3.  Objectives
-
-    The objectives of this specification are as follows:
-    
-      1.  Simplify the administration required to establish Kerberos
-          cross-realm keys.
-          
-      2.  Avoid modification of clients and application servers.
-
-      3.  Allow remote KDC to control its policy on cross-realm
-          keys shared between KDCs, and on cross-realm tickets
-          presented by clients.
-
-      4.  Remove any need for KDCs to maintain state about keys
-          shared with other KDCs.
-
-      5.  Leverage the work done for PKINIT to provide the public key
-          protocol for establishing symmetric cross realm keys.
-
-
-4.  Definitions
-
-    The following notation is used throughout this specification:
-    KDC_l ........... local KDC
-    KDC_r ........... remote KDC
-    XTKT_(l,r) ...... PKCROSS ticket that the remote KDC issues to the
-                      local KDC
-    TGT_(c,r) ....... cross-realm TGT that the local KDC issues to the
-                      client for presentation to the remote KDC
-
-    This specification defines the following new types to be added to
-    the Kerberos specification:
-      PKCROSS kdc-options field in the AS_REQ is bit 9
-      TE-TYPE-PKCROSS-KDC       2
-      TE-TYPE-PKCROSS-CLIENT    3
-
-    This specification defines the following ASN.1 type for conveying
-    policy information:
-    CrossRealmTktData ::= SEQUENCE OF TypedData
-
-    This specification defines the following types for policy
-    information conveyed in CrossRealmTktData:
-      PLC_LIFETIME              1
-      PLC_SET_TKT_FLAGS         2
-      PLC_NOSET_TKT_FLAGS       3
-
-    TicketExtensions are defined per the Kerberos specification
-    [KERB-REV]:
-    TicketExtensions ::= SEQUENCE OF TypedData
-      Where
-        TypedData ::=   SEQUENCE {
-            data-type[0]   INTEGER,
-            data-value[1]  OCTET STRING OPTIONAL
-        }
-
-
-5.  Protocol Specification
-
-    We assume that the client has already obtained a TGT.  To perform
-    cross-realm authentication, the client does exactly what it does
-    with ordinary (i.e. non-public-key-enabled) Kerberos; the only
-    changes are in the KDC; although the ticket which the client
-    forwards to the remote realm may be changed.  This is acceptable
-    since the client treats the ticket as opaque.
-
-
-5.1.  Overview of Protocol
-
-    The basic operation of the PKCROSS protocol is as follows:
-
-        1.  The client submits a request to the local KDC for
-            credentials for the remote realm.  This is just a typical
-            cross realm request that may occur with or without PKCROSS. 
-
-        2.  The local KDC submits a PKINIT request to the remote KDC to
-            obtain a "special" PKCROSS ticket.  This is a standard
-            PKINIT request, except that PKCROSS flag (bit 9) is set in
-            the kdc-options field in the AS_REQ.  Note that the service
-            name in the request is for pkcross/realm@REALM instead of
-            krbtgt/realm@REALM.
-
-        3.  The remote KDC responds as per PKINIT, except that
-            the ticket contains a TicketExtension, which contains
-            policy information such as lifetime of cross realm tickets
-            issued by KDC_l to a client.  The local KDC must reflect
-            this policy information in the credentials it forwards to
-            the client.  Call this ticket XTKT_(l,r) to indicate that
-            this ticket is used to authenticate the local KDC to the
-            remote KDC.
-
-        4.  The local KDC passes a ticket, TGT_(c,r) (the cross realm
-            TGT between the client and remote KDC), to the client.
-            This ticket contains in its TicketExtension field the
-            ticket, XTKT_(l,r), which contains the cross-realm key.
-            The TGT_(c,r) ticket is encrypted using the key sealed in
-            XTKT_(l,r).  (The TicketExtension field is not encrypted.)
-            The local KDC may optionally include another TicketExtension
-            type that indicates the hostname and/or IP address for the
-            remote KDC.
-
-        5.  The client submits the request directly to the remote
-            KDC, as before.
-            
-        6.  The remote KDC extracts XTKT_(l,r) from the TicketExtension
-            in order to decrypt the encrypted part of TGT_(c,r).
-
-    --------------------------------------------------------------------
-    
-    Client                Local KDC (KDC_l)           Remote KDC (KDC_r)
-    ------                -----------------           ------------------
-    Normal Kerberos
-    request for
-    cross-realm
-    ticket for KDC_r
-    ---------------------->
-    
-                          PKINIT request for
-                          XTKT(l,r) - PKCROSS flag
-                          set in the AS-REQ
-                          * ------------------------->
-                          
-                                                      PKINIT reply with
-                                                      XTKT_(l,r) and
-                                                      policy info in
-                                                      ticket extension
-                                           <-------------------------- *
-
-                          Normal Kerberos reply
-                          with TGT_(c,r) and
-                          XTKT(l,r) in ticket
-                          extension
-         <--------------------------------- 
-
-    Normal Kerberos
-    cross-realm TGS-REQ
-    for remote
-    application
-    service with
-    TGT_(c,r) and
-    XTKT(l,r) in ticket
-    extension
-    ------------------------------------------------->
-
-                                                      Normal Kerberos
-                                                      cross-realm
-                                                      TGS-REP
-        <---------------------------------------------------------------
-
-    * Note that the KDC to KDC messages occur only periodically, since
-      the local KDC caches the XTKT_(l,r).
-    --------------------------------------------------------------------
-    
-
-    Sections 5.2 through 5.4 describe in detail steps 2 through 4
-    above.  Section 5.6 describes the conditions under which steps
-    2 and 3 may be skipped.
-
-    Note that the mechanism presented above requires infrequent KDC to 
-    KDC communication (as dictated by policy - this is discussed
-    later).  Without such an exchange, there are the following issues:
-    1) KDC_l would have to issue a ticket with the expectation that
-       KDC_r will accept it.
-    2) In the message that the client sends to KDC_r, KDC_l would have
-       to authenticate KDC_r with credentials that KDC_r trusts.
-    3) There is no way for KDC_r to convey policy information to KDC_l.
-    4) If, based on local policy, KDC_r does not accept a ticket from
-       KDC_l, then the client gets stuck in the middle.  To address such
-       an issue would require modifications to standard client
-       processing behavior.
-    Therefore, the infreqeunt use of KDC to KDC communication assures
-    that inter-realm KDC keys may be established in accordance with local
-    policies and that clients may continue to operate without
-    modification.
-
-
-5.2.  Local KDC's Request to Remote KDC
-
-    When the local KDC receives a request for cross-realm 
-    authentication, it first checks its ticket cache to see if it has a 
-    valid PKCROSS ticket, XTKT_(l,r).  If it has a valid XTKT_(l,r), 
-    then it does not need to send a request to the remote KDC (see 
-    section 5.5).
-
-    If the local KDC does not have a valid XTKT_(l,r), it sends a     
-    request to the remote KDC (for pkcross/realm@REALM) in order to
-    establish a cross realm key and obtain the XTKT_(l,r).  This request
-    is in fact a PKINIT request as described in the PKINIT specification;
-    i.e., it consists of an AS-REQ with a PA-PK-AS-REQ included as a
-    preauthentication field.  Note, that the AS-REQ MUST have the PKCROSS
-    flag (bit 9) set in the kdc_options field of the AS-REQ.  Otherwise,
-    this exchange exactly follows the description given in the PKINIT
-    specification.
-
-
-5.3.  Remote KDC's Response to Local KDC
-
-    When the remote KDC receives the PKINIT/PKCROSS request from the
-    local KDC, it sends back a PKINIT response as described in
-    the PKINIT specification with the following exception: the encrypted
-    part of the Kerberos ticket is not encrypted with the krbtgt key;
-    instead, it is encrypted with the ticket granting server's PKCROSS
-    key.  This key, rather than the krbtgt key, is used because it
-    encrypts a ticket used for verifying a cross realm request rather
-    than for issuing an application service ticket.  This is the reason
-    that the name pkcross/realm@REALM is used instead of
-    krbtgt/realm@REALM.  Note that, as a matter of policy, the session
-    key for the XTKT_(l,r) MAY be of greater strength than that of a
-    session key for a normal PKINIT reply, since the XTKT_(l,r) SHOULD
-    be much longer lived than a normal application service ticket.
-
-    In addition, the remote KDC SHOULD include policy information in the 
-    XTKT_(l,r).  This policy information would then be reflected in the 
-    cross-realm TGT, TGT_(c,r).  Otherwise, the policy for TGT_(c,r) 
-    would be dictated by KDC_l rather than by KDC_r.  The local KDC MAY 
-    enforce a more restrictive local policy when creating a cross-realm 
-    ticket, TGT_(c,r).  For example, KDC_r  may dictate a lifetime 
-    policy of eight hours, but KDC_l may create TKT_(c,r) with a 
-    lifetime of four hours, as dictated by local policy.  Also, the 
-    remote KDC MAY include other information about itself along with the 
-    PKCROSS ticket.  These items are further discussed in section 6 
-    below.
-
-
-5.4.  Local KDC's Response to Client
-
-    Upon receipt of the PKINIT/CROSS response from the remote KDC,
-    the local KDC formulates a response to the client.  This reply
-    is constructed exactly as in the Kerberos specification, except
-    for the following:
-
-    A) The local KDC places XTKT_(l,r) in the TicketExtension field of
-       the client's cross-realm, ticket, TGT_(c,r), for the remote
-       realm.
-       Where
-          data-type   equals 3 for TE-TYPE-PKCROSS-CLIENT
-          data-value  is ASN.1 encoding of XTKT_(l,r)
-     
-    B) The local KDC adds the name of its CA to the transited field of
-       TGT_(c,r).
-
-
-5.5   Remote KDC's Processing of Client Request
-
-    When the remote KDC, KDC_r, receives a cross-realm ticket, 
-    TGT_(c,r), and it detects that the ticket contains a ticket 
-    extension of type TE-TYPE-PKCROSS-CLIENT, KDC_r must first decrypt 
-    the ticket, XTKT_(l,r), that is encoded in the ticket extension.  
-    KDC_r uses its PKCROSS key in order to decrypt XTKT_(l,r).  KDC_r 
-    then uses the key obtained from XTKT_(l,r) in order to decrypt the 
-    cross-realm ticket, TGT_(c,r).
-
-    KDC_r MUST verify that the cross-realm ticket, TGT_(c,r) is in 
-    compliance with any policy information contained in XTKT_(l,r) (see 
-    section 6).  If the TGT_(c,r) is not in compliance with policy, then 
-    the KDC_r responds to the client with a KRB-ERROR message of type 
-    KDC_ERR_POLICY.
-
-    
-5.6.  Short-Circuiting the KDC-to-KDC Exchange
-
-    As we described earlier, the KDC to KDC exchange is required only 
-    for establishing a symmetric, inter-realm key.  Once this key is 
-    established (via the PKINIT exchange), no KDC to KDC communication 
-    is required until that key needs to be renewed.  This section 
-    describes the circumstances under which the KDC to KDC exchange 
-    described in Sections 5.2 and 5.3 may be skipped.
-
-    The local KDC has a known lifetime for TGT_(c,r).  This lifetime may 
-    be determined by policy information included in XTKT_(l,r), and/or 
-    it may be determined by local KDC policy.  If the local KDC already 
-    has a ticket XTKT(l,r), and the start time plus the lifetime for 
-    TGT_(c,r) does not exceed the expiration time for XTGT_(l,r), then 
-    the local KDC may skip the exchange with the remote KDC, and issue a 
-    cross-realm ticket to the client as described in Section 5.4.
-
-    Since the remote KDC may change its PKCROSS key (referred to in 
-    Section 5.2) while there are PKCROSS tickets still active, it SHOULD 
-    cache the old PKCROSS keys until the last issued PKCROSS ticket 
-    expires.  Otherwise, the remote KDC will respond to a client with a 
-    KRB-ERROR message of type KDC_ERR_TGT_REVOKED.
-
-
-6.  Extensions for the PKCROSS Ticket
-
-    As stated in section 5.3, the remote KDC SHOULD include policy 
-    information in XTKT_(l,r).  This policy information is contained in 
-    a TicketExtension, as defined by the Kerberos specification, and the 
-    authorization data of the ticket will contain an authorization 
-    record of type AD-IN-Ticket-Extensions.  The TicketExtension defined 
-    for use by PKCROSS is TE-TYPE-PKCROSS-KDC.
-      Where
-        data-type   equals 2 for TE-TYPE-PKCROSS-KDC
-        data-value  is ASN.1 encoding of CrossRealmTktData
-
-      CrossRealmTktData ::= SEQUENCE OF TypedData
-
-
-      ------------------------------------------------------------------
-      CrossRealmTktData types and the corresponding data are interpreted 
-      as follows:
-
-                                                            ASN.1 data
-      type                value   interpretation            encoding
-      ----------------    -----   --------------            ----------
-      PLC_LIFETIME          1     lifetime (in seconds)     INTEGER
-                                  for TGT_(c,r) 
-                                  - cross-realm tickets
-                                    issued for clients by
-                                    TGT_l
-
-      PLC_SET_TKT_FLAGS     2     TicketFlags that must     BITSTRING
-                                  be set
-                                  - format defined by
-                                    Kerberos specification
-
-      PLC_NOSET_TKT_FLAGS   3     TicketFlags that must     BITSTRING
-                                  not be set
-                                  - format defined by
-                                    Kerberos specification
-
-      Further types may be added to this table.
-      ------------------------------------------------------------------
-
-
-7.  Usage of Certificates
-
-    In the cases of PKINIT and PKCROSS, the trust in a certification 
-    authority is equivalent to Kerberos cross realm trust.  For this 
-    reason, an implementation MAY choose to use the same KDC certificate 
-    when the KDC is acting in any of the following three roles:
-      1) KDC is authenticating clients via PKINIT
-      2) KDC is authenticating another KDC for PKCROSS 
-      3) KDC is the client in a PKCROSS exchange with another KDC
-
-    Note that per PKINIT, the KDC X.509 certificate (the server in a 
-    PKINIT exchange) MUST contain the principal name of the KDC in the 
-    subjectAltName field.
-
-
-8.  Transport Issues
-
-    Because the messages between the KDCs involve PKINIT exchanges, and 
-    PKINIT recommends TCP as a transport mechanism (due to the length of 
-    the messages and the likelihood that they will fragment), the same 
-    recommendation for TCP applies to PKCROSS as well.
-
-    
-9. Security Considerations
-
-   Since PKCROSS utilizes PKINIT, it is subject to the same security
-   considerations as PKINIT.  Administrators should assure adherence 
-   to security policy - for example, this affects the PKCROSS policies
-   for cross realm key lifetime and for policy propogation from the 
-   PKCROSS ticket, issued from a remote KDC to a local KDC, to
-   cross realm tickets that are issued by a local KDC to a client.
-
-
-10. Bibliography
-
-  [KERBTLS]  A. Medvinsky and M. Hur, "Addition of Kerberos Cipher
-             Suites to Transport Layer Security (TLS)", RFC 2712,
-             October 1999.
-
-  [KERB]     J. Kohl and C. Neuman, "The Kerberos Network
-             Authentication Service (V5)", RFC 1510, September 1993.
-
-  [TLS]      T. Dierks and C. Allen, "The TLS Protocol, Version 1.0",
-             RFC 2246, January 1999.
-
-  [PKINIT]   B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky,
-             J. Wray, J. Trostle.  Public Key Cryptography for Initial
-             Authentication in Kerberos.
-             draft-ietf-cat-kerberos-pk-init-14.txt
-
-  [PKTAPP]   A. Medvinsky, M. Hur, S. Medvinsky, C. Neuman.
-             Public Key Utilizing Tickets for Application
-             Servers (PKTAPP).  draft-ietf-cat-kerberos-pk-tapp-03.txt
-
-  [X509]     ITU-T (formerly CCITT) Information technology - Open
-             Systems Interconnection - The Directory: Authentication
-             Framework Recommendation X.509 ISO/IEC 9594-8
-
-  [NEUMAN]   B.C. Neuman, "Proxy-Based Authorization and Accounting for
-             Distributed Systems".  Proceedings of the 13th
-             International Conference on Distributed Computing Systems,
-             May 1993
-
-  [KERB94]   B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication
-             Service for Computer Networks, IEEE Communications,
-             32(9):33-38.  September 1994.
-
-  [KERB-REV] C.Neuman, J. Kohl, T. Ts'o.  The Kerberos Network
-             Authentication Service (V5).
-             draft-ietf-cat-kerberos-revisions-08.txt
-
-
-11. Authors' Addresses
-
-    Matthew Hur
-    Cisco Systems
-    2901 Third Avenue
-    Seattle, WA 98121
-    Phone: +1 206 256 3197
-    E-Mail: mhur@cisco.com
- 
-    Brian Tung
-    Tatyana Ryutov
-    Clifford Neuman
-    USC/Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey, CA 90292-6695
-    Phone: +1 310 822 1511
-    E-Mail: {brian, tryutov, bcn}@isi.edu
-
-    Ari Medvinsky
-    Liberate
-    2 Circle Star Way
-    San Carlos, CA 94070-6200
-    Phone: +1 650 701 4000
-    EMail: ari@liberate.com
-
-    Gene Tsudik
-    ICS Dept, 458 CS Building 
-    Irvine CA 92697-3425
-    Phone: +1 310 448 9329
-    E-Mail: gts@ics.uci.edu
-
-    Bill Sommerfeld
-    Sun Microsystems
-    E-Mail: sommerfeld@east.sun.com
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-00.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-00.txt
deleted file mode 100644
index 704c7caf2..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-00.txt
+++ /dev/null
@@ -1,373 +0,0 @@
-
-INTERNET-DRAFT                                         Clifford Neuman
-draft-ietf-cat-kerberos-pk-init-00.txt                      Brian Tung
-Updates: RFC 1510                                                  ISI
-expires September 3, 1995                                    John Wray
-                                         Digital Equipment Corporation
-
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-
-0. 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 docu-
-   ments at any time.  It is inappropriate to use  Internet-Drafts  as
-   reference  material  or  to  cite them other than as ``work in pro-
-   gress.''
-
-   To learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
-   dow Directories on ds.internic.net (US East  Coast),  nic.nordu.net
-   (Europe),  ftp.isi.edu  (US  West Coast), or munnari.oz.au (Pacific
-   Rim).
-
-   The distribution of  this  memo  is  unlimited.   It  is  filed  as
-   draft-ietf-cat-kerberos-pk-init-00.txt, and expires August 6, 1995.
-   Please send comments to the authors.
-
-
-1. Abstract
-
-   This document defines extensions to the Kerberos protocol  specifi-
-   cation  (RFC  1510,  "The  Kerberos  Network Authentication Service
-   (V5)", September 1993) to provide a method for using public key
-   cryptography during initial authentication.  The method defined 
-   specifies the way in which preauthentication data fields and error
-   data fields in Kerberos messages are to be used to transport public
-   key data. 
-
-2. Motivation
-
-   Public key cryptography provides a means by which a principal may
-   demonstrate possession of a key, without ever having divulged this
-   key to anyone else.  In conventional cryptography, the encryption key
-   and decryption key are either identical or can easily be derived from
-   each other.  In public key cryptography, however, neither key can be
-   derived easily from the other; hence, the ability to encrypt a message
-   does not imply the ability to decrypt it in turn.  Additionally, each
-   key is a full inverse of the other, so that either key can be used
-   for encryption or decryption.
-
-   The advantages provided by public key cryptography have produced a
-   demand for its integration into the Kerberos authentication protocol.
-   There are two important areas where public key cryptography will have
-   immediate use: in the initial authentication of users registered with
-   the KDC or using public key certificates from outside authorities,
-   and to establish inter-realm keys for cross-realm authentication.
-   This memo describes a method by which the first of these can be done.
-   The second case will be the topic for a separate proposal.
-
-   Some of the ideas on which this proposal is based arose during
-   discussions over several years between members of the SAAG, the
-   IETF-CAT working group, and the PSRG, regarding integration of
-   Kerberos and SPX.  Some ideas are drawn from the DASS system, and
-   similar extensions have been discussed for use in DCE.  These changes
-   are by no means endorsed by these groups.  This is an attempt to
-   revive some of the goals of that group, and the proposal approaches
-   those goals primarily from the Kerberos perspective.
-
-   This proposal will allow users with keys already registered for use
-   with X.509, PEM, or PGP, to use those keys to obtain Kerberos
-   credentials which can then be used for authentication with application
-   servers supporting Kerberos.
-
-   Use of public-key will not be a requirement for Kerberos, but if one's
-   organization runs a KDC supporting public key, then users may choose
-   to be registered with public keys instead of the current secret key.
-   The application request and response, between Kerberos clients and
-   application servers, will continue to be based on conventional
-   cryptography, and the application servers will continue to be
-   registered with conventional keys.
-
-
-3. Initial authentication of users with public keys
-
-   This section proposes extensions to Version 5 of the Kerberos
-   protocol that will support the use of public key cryptography 
-   by users in the initial request for a ticket granting ticket.
-
-   The advantage of registering public keys with the KDC lies in the
-   ease of recovery in case the KDC is compromised.  With Kerberos as it
-   currently stands, compromise of the security KDC is disastrous.  All
-   keys become known by the attacker and all keys must be changed.  
-
-   If users register public keys, compromise of the KDC does not divulge
-   their private key.  Compromise of security on the KDC is still
-   disastrous, since the attacker can impersonate any user.  An
-   attacker with the private key of the KDC can use it to certify a
-   bogus nonce key, and impersonate a user.  Changing this key
-   invalidates all bogus certifications.  Legitimate users must
-   re-certify their keys with the new KDC key, but users' public
-   keys do not have to be changed.  (Users who store their private
-   keys in an encrypted form on the KDC do have to change their
-   keys, since the encryption key is a symmetric key derived from
-   a password (as described below) and hence vulnerable to dictionary
-   attacks.  The difference is that, assuming good password policy,
-   site policy may allow the use of the old password only for the
-   purpose of key change for a time after the compromise, which means
-   that users can change their own passwords, rather than forcing the
-   administrator to re-key everyone.)
-
-   In the event of compromise of the KDC, recovery is simple since only
-   the KDC's key, keys for application servers, and users' private keys
-   stored in the KDC (as described above) must be changed.
-   Since there are usually fewer servers than users, and since an
-   organization usually has better procedures for updating servers,
-   changing these keys is much easier than having to individually
-   contact every user.
-
-   This proposed extension will not require users to register with
-   public keys.  It is intended to allow them to do so, but we recognize
-   that there are many reasons, including licensing terms, that users or
-   an organization as a whole will choose not to use the public key
-   option.  Users registered will public keys will only be able to
-   perform initial authentication from a client that support public key,
-   and must be registered in a realm that supports public key.  But they
-   will be able to use services registered in realms that support only
-   conventional Kerberos.  Further, users registered with conventional
-   Kerberos keys will be able to use all clients.
-
-   This proposal specifically does not address the registration of
-   public keys for services.  The application request and response,
-   between Kerberos clients and application servers, will continue to be
-   based on conventional cryptography, and the application servers will
-   continue to be registered with conventional keys. There are
-   performance issues and other reasons that servers may be better off
-   using conventional cryptography.  There are also reasons that they
-   may want to use public key.  For this proposal, however, we feel that
-   80 percent of the benefits of integrating public key with Kerberos
-   can be attained for 20 percent of the effort, by addressing only
-   initial authentication. This proposal does not preclude separate
-   extensions.
-
-   This proposal address two ways in which users may use public key
-   cryptography for initial authentication with Kerberos.  In both
-   cases, the end result is that the user obtains a conventional ticket
-   granting ticket, or conventional server ticket, that may be used for
-   subsequent authentication, with such subsequent authentication using
-   only conventional cryptography.
-
-   Users may register keys directly with the KDC, or they may present
-   certificates by outside certification authorities (or certifications
-   by other users) attesting to the association of the public key with
-   the named user.  We first consider the case where the user's key is
-   registered with the KDC.
-
-
-3.1 Initial request for user registered with public key on KDC 
-
-   In this scenario it is assumed that the user is registered with a public
-   key on the KDC.  The user's private key may be known to the user, or
-   may be stored on the KDC, encrypted so that it can not be used by the KDC.
-
-   We consider first the case where the user knows the private key, then
-   add support for retrieving the private key from the KDC.
-
-   The initial request to the KDC for a ticket granting ticket proceeds
-   according to RFC 1510.  Typically, preauthentication using a secret
-   key would not be included, but if included it may be ignored by the
-   KDC.  (This may introduce a problem: even if the KDC should ignore
-   the preauthentication, an attacker may not, and use an
-   intercepted message to guess the password off-line.)
-   If the private key is known to the client in advance, the
-   response from the KDC would be identical to the response in RFC1510,
-   except that instead of being encrypted in the secret key shared by the
-   client and the KDC, it is encrypted in a random key freshly generated
-   by the KDC.  A preauthentication field (specified below)
-   accompanies the response, containing a certificate with the public
-   key for the KDC, and a package containing the secret key in which the
-   rest of the response is encrypted, itself encrypted in the private key
-   of the KDC, and the public key of the user.  This package also contains
-   the same nonce used in the rest of the response, in order to prevent
-   replays of this part of the message, accompanied by a reconstructed
-   response.
-
-   PA-PK-AS-REP ::= SEQUENCE {
-	   kdc-cert	SEQUENCE OF OCTET STRING,
-           encryptPack  EncryptedData -- EncPaPkAsRepPart
-   }
-
-   EncPaPkAsRepPart ::= SEQUENCE {
-           enc-sess-key INTEGER,
-           nonce        INTEGER
-   }
-
-   Upon receipt of the response from the KDC, the client will verify the
-   public key for the KDC from PA-PK-AS-REP preauthentication data field,
-   The certificate must certify the key as belonging to a principal whose
-   name can be derived from the realm name.  We solicit discussion on the
-   form of the kdc-cert.  If client systems are expected to know (by
-   being hard-coded, for example) at least one public key, and to verify
-   certificates from that key, then there should be at least some policy
-   about which key that is, or alternatively some way to inform the KDC
-   which key the client possesses.
-
-   If the certificate checks
-   out, the client then extracts the message key for the rest of the
-   response by decrypting the field in the PA-PK-AS-REP with the public
-   key of the KDC and the private key of the user.  The client then uses
-   the message key to decrypt the rest of the response, and continues as
-   per RFC1510[1].
-
-
-3.1.1. Private key held by KDC
-
-   When the user's private key is not carried with the user, the user may
-   encrypt the private key using conventional cryptography, and register
-   the encrypted private key with the KDC.
-
-   When the user's private key is registered with the KDC, the KDC record
-   will also indicate whether preauthentication is required before
-   returning the record (we recommend that it be required).  If such
-   preauthentication is required, when the initial request is received
-   the KDC will respond with a KRB_ERROR message of type
-   KDC_ERR_PREAUTH_REQUIRED and with an error data field set to:
-
-   PA-PK-AS-INFO ::= SEQUENCE {
-	   kdc-cert	OCTET STRING}
-   }
-
-   The kdc-cert field is identical to that in the PA-PK-AS-REP
-   preauthentication data field returned with the KDC response, and must
-   be validated as belonging to the KDC in the same manner.
-
-   Upon receipt of the KRB_ERROR message with a PA-PK-AS-INFO field, the
-   client will prompt the user for the password that will be used to
-   decrypt the private key when returned, calculate a one way hash H1 of the
-   key, and send a request to the KDC, including a timestamp and a
-   client-generated nonce secret key that will be used to super-encrypt
-   the encrypted private key before it is returned to the client.  This
-   information is sent to the KDC in a subsequent AS_REQ message in a
-   preauthentication data field:
-
-   PA-PK-AS-REQ ::= SEQUENCE {
-	   enc-part	EncryptedData -- EncPaPkAsReqPart
-   }
-
-   EncPaPkAsReqPart ::= SEQUENCE {
-           tstamp       KerberosTime,
-           noncekey	INTEGER
-   }
-
-   encrypted first with the hash H1, then the public key of the KDC from
-   the certificate in the PA-PK-AS-INFO field of the error response.
-
-   Upon receipt of the authentication request with the PA-PK-AS-REQ the
-   KDC verifies the hash of the user's DES encryption key by comparing it
-   to the hash stored in the users database record.  If valid, it
-   generates the AS response as defined in RFC1510, but additionally
-   includes a preauthentication field of type PA-PK-USER KEY.  This
-   response will also be included in response to the initial request
-   without preauthentication if preauthentication is not required for the
-   user and the user's encrypted private key is stored on the KDC.  The
-   KDC generates a preauthentication data field of type PA-PK-USER-KEY
-   which will be returned with the KDC reply (together with the
-   PA-PK-AS-REP that is already returned).
-
-   PA-PK-USER-KEY ::= SEQUENCE {
-           enc-priv-key         OCTET STRING OPTIONAL
-   }
-
-   This message contains the encrypted private key that has been
-   registered with the KDC by the user, as encrypted by the user,
-   super-encrypted with the noncekey from the PA-PK-AS-REQ message if
-   preauthentication using that method was provided.  Note that since
-   H1 is a one-way hash, it is not possible for one to decrypt the
-   message if one possesses H1 but not the noncekey that H1 is derived
-   from.
-
-
-3.2. Clients with a public key certified by an outside authority
-
-   In the case where the client is not registered with the current KDC,
-   the client is responsible for obtaining the private key on its own.
-   The client will request initial tickets from the KDC using the TGS
-   exchange, but instead of performing pre-authentication using a
-   Kerberos ticket granting ticket, or with the PA-PK-AS-REQ that is used
-   when the public key is known to the KDC, the client performs
-   preauthentication using the preauthentication data field of type
-   PA-PK-AS-EXT-CERT:
-
-   PA-PK-AS-EXT-CERT ::= SEQUENCE {
-           user-cert	SEQUENCE OF OCTET STRING,
-	   authent	EncryptedData -- PKAuthenticator
-   }
-
-   PKAuthenticator ::= SEQUENCE {
-	   cksum	Checksum OPTIONAL,
-	   cusec	INTEGER,
-	   ctime	KerberosTime,
-   }
-
-   The fields in the encrypted authenticator are the same as those
-   in the Kerberos authenticator.  The structure is itself signed using
-   the user's private key corresponding to the public key in the
-   certificate. 
-
-   The KDC will verify the preauthentication authenticator, and check the
-   certification path against its own policy of legitimate certifiers.
-   This may be based on a certification hierarchy, or simply a list of
-   recognized certifiers in a system like PGP.
-
-   If all checks out, the KDC will issue Kerberos credentials, as in 3.1,
-   but with the names of all the certifiers in the certification path
-   added to the transited field of the ticket, with a principal name
-   taken from the certificate (this might be a long path for X.509, or a
-   string like "John Q. Public <jqpublic@company.com>" if the certificate
-   was a PGP certificate.  The realm will identify the kind of
-   certificate and the final certifier (e.g. PGP:<endorser@company.com>)[2].
-
-
-4. Compatibility with One-Time Passcodes
-
-   We solicit discussion on how the use of public key crytpgraphy for
-   intial authentication will interact with the proposed use of one time
-   passwords discussed in Internet Draft
-   draft-ietf-cat-kerberos-passwords-00.txt 
-
-5. Expiration
-
-   This Internet-Draft expires on August 6, 1995.
-
-
-6. Authors' Addresses
-
-   B. Clifford Neuman
-   USC/Information Sciences Institute
-   4676 Admiralty Way #1001
-   Marina del Rey, CA 90292-6695
-
-   Phone: 310-822-1511
-   EMail: bcn@isi.edu
-
-
-   Brian Tung
-   USC/Information Sciences Institute
-   4676 Admiralty Way #1001
-   Marina del Rey, CA 90292-6695
-
-   Phone: 310-822-1511
-   EMail: brian@isi.edu
-
-
-   John Wray
-   Digital Equipment Corporation
-   550 King Street, LKG2-2/Z7
-   Littleton, MA 01460
-
-   Phone: 508-486-5210
-   EMail: wray@tuxedo.enet.dec.com
-
-[1] Note: We have not yet defined the public key encryption method for
-encrypting the enc-sess-key field in the PA-PK-AS-REP.
-
-[2] Note: We are soliciting input on the form of the name.  We believe the
-name part must be taken without modification from the certificate, but the
-realm part is open for discussion.
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-01.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-01.txt
deleted file mode 100644
index e6ae54d97..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-01.txt
+++ /dev/null
@@ -1,614 +0,0 @@
-INTERNET-DRAFT                                         Clifford Neuman
-draft-ietf-cat-kerberos-pk-init-01.txt                      Brian Tung
-Updates: RFC 1510                                                  ISI
-expires December 7, 1996                                     John Wray
-                                         Digital Equipment Corporation
-
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-
-0. 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 docu-
-   ments at any time.  It is inappropriate to use  Internet-Drafts  as
-   reference  material  or  to  cite them other than as ``work in pro-
-   gress.''
-
-   To learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
-   dow Directories on ds.internic.net (US East  Coast),  nic.nordu.net
-   (Europe),  ftp.isi.edu  (US  West Coast), or munnari.oz.au (Pacific
-   Rim).
-
-   The distribution of  this  memo  is  unlimited.   It  is  filed  as
-   draft-ietf-cat-kerberos-pk-init-01.txt, and expires December 7, 1996.
-   Please send comments to the authors.
-
-
-1. Abstract
-
-   This document defines extensions to the Kerberos protocol  specifi-
-   cation  (RFC  1510,  "The  Kerberos  Network Authentication Service
-   (V5)", September 1993) to provide a method for using public key
-   cryptography during initial authentication.  The method defined 
-   specifies the way in which preauthentication data fields and error
-   data fields in Kerberos messages are to be used to transport public
-   key data. 
-
-2. Motivation
-
-   Public key cryptography presents a means by which a principal may
-   demonstrate possession of a key, without ever having divulged this
-   key to anyone else.  In conventional cryptography, the encryption key
-   and decryption key are either identical or can easily be derived from
-   one another.  In public key cryptography, however, neither the public
-   key nor the private key can be derived from the other (although the
-   private key RECORD may include the information required to generate
-   BOTH keys).  Hence, a message encrypted with a public key is private,
-   since only the person possessing the private key can decrypt it;
-   similarly, someone possessing the private key can also encrypt a
-   message, thus providing a digital signature.
-
-   Furthermore, conventional keys are often derived from passwords, so
-   messages encrypted with these keys are susceptible to dictionary
-   attacks, whereas public key pairs are generated from a pseudo-random
-   number sequence.  While it is true that messages encrypted using
-   public key cryptography are actually encrypted with a conventional
-   secret key, which is in turn encrypted using the public key pair,
-   the secret key is also randomly generated and is hence not vulnerable
-   to a dictionary attack.
-
-   The advantages provided by public key cryptography have produced a
-   demand for its integration into the Kerberos authentication protocol.
-   The primary advantage of registering public keys with the KDC lies in
-   the ease of recovery in case the KDC is compromised.  With Kerberos as
-   it currently stands, compromise of the KDC is disastrous.  All
-   keys become known by the attacker and all keys must be changed.  
-
-   If users register public keys, compromise of the KDC does not divulge
-   their private key.  Compromise of security on the KDC is still a
-   problem, since an attacker can impersonate any user by certifying a
-   bogus key with the KDC's private key.  However, all bogus
-   certificates can be invalidated by revoking and changing the
-   KDC's public key.  Legitimate users have to re-certify their public
-   keys with the new KDC key, but the users's keys themselves do not
-   need to be changed.  Keys for application servers are conventional
-   symmetric keys and must be changed.
-
-   Note: If a user stores his private key, in an encrypted form, on the
-   KDC, then he does have to change the key pair, since the private key
-   is encrypted using a symmetric key derived from a password (as
-   described below), and is therefore vulnerable to dictionary attack.
-   Assuming good password policy, however, legitimate users may be
-   allowed to use the old password for a limited time, solely for the
-   purpose of changing the key pair.  The realm administrator is then
-   not forced to re-key all users.
-
-   There are two important areas where public key cryptography will have
-   immediate use: in the initial authentication of users registered with
-   the KDC or using public key certificates from outside authorities,
-   and to establish inter-realm keys for cross-realm authentication.
-   This memo describes a method by which the first of these can be done.
-   The second case will be the topic for a separate proposal.
-
-   Some of the ideas on which this proposal is based arose during
-   discussions over several years between members of the SAAG, the
-   IETF-CAT working group, and the PSRG, regarding integration of
-   Kerberos and SPX.  Some ideas are drawn from the DASS system, and
-   similar extensions have been discussed for use in DCE.  These changes
-   are by no means endorsed by these groups.  This is an attempt to
-   revive some of the goals of that group, and the proposal approaches
-   those goals primarily from the Kerberos perspective.
-
-
-3. Initial authentication of users with public keys
-
-   This section describes the extensions to Version 5 of the Kerberos
-   protocol that will support the use of public key cryptography by
-   users in the initial request for a ticket granting ticket.  This
-   proposal is based on the implementation already made available;
-   nevertheless, we solicit any comments on modifications or additions
-   to the protocol description below.
-
-   Roughly speaking, the following changes to RFC 1510 are proposed:
-       a.  The KDC's response is encrypted using a random nonce key,
-           rather than the user's secret key.
-       b.  This random key accompanies the response in a
-           preauthentication field, encrypted and signed using the
-           public key pairs of the user and the KDC.
-   Certificate and message formats are also defined in this section.
-
-   This proposal will allow users either to use keys registered directly
-   with the KDC, or to use keys already registered for use with X.509,
-   PEM, or PGP, to obtain Kerberos credentials.  These credentials can
-   then be used, as before, with application servers supporting Kerberos.
-   Use of public key cryptography will not be a requirement for Kerberos,
-   but if one's organization runs a KDC supporting public key, then users
-   may choose to be registered with a public key pair, instead of the
-   current secret key.
-
-   The application request and response between Kerberos clients and
-   application servers will continue to be based on conventional
-   cryptography, or will be converted to use user-to-user
-   authentication.  There are performance issues and other reasons
-   that servers may be better off using conventional cryptography.
-   For this proposal, we feel that 80 percent of the benefits of
-   integrating public key with Kerberos can be attained for 20 percent
-   of the effort, by addressing only initial authentication. This
-   proposal does not preclude separate extensions.
-
-   With these changes, users will be able to register public keys, only
-   in realms that support public key, and they will then only be able
-   to perform initial authentication from a client that supports public key,
-   although they will be able to use services registered in any realm.
-   Furthermore, users registered with conventional keys will be able
-   to use any client.
-
-   This proposal addresses three ways in which users may use public key
-   cryptography for initial authentication with Kerberos, with minimal
-   change to the existing protocol.  Users may register keys directly
-   with the KDC, or they may present certificates by outside certification
-   authorities (or certifications by other users) attesting to the
-   association of the public key with the named user.  In both cases,
-   the end result is that the user obtains a conventional ticket
-   granting ticket or conventional server ticket that may be used for
-   subsequent authentication, with such subsequent authentication using
-   only conventional cryptography.
-
-   Additionally, users may also register a digital signature key with
-   the KDC.  We provide this option for the licensing benefits, as well
-   as a simpler variant of the initial authentication exchange.  However,
-   this option relies on the client to generate random keys.
-
-   We first consider the case where the user's key is registered with
-   the KDC.
-
-
-3.1 Definitions
-
-   Before we proceed, we will lay some groundwork definitions for
-   encryption and signatures.  We propose the following definitions
-   of signature and encryption modes (and their corresponding values
-   on the wire):
-
-       #define ENCTYPE_SIGN_MD5_RSA      0x0011
-
-       #define ENCTYPE_ENCRYPT_RSA_PRIV  0x0021
-       #define ENCTYPE_ENCRYPT_RSA_PUB   0x0022
-
-   allowing further modes to be defined accordingly.
-
-   In the exposition below, we will use the notation E (T, K) to denote
-   the encryption of data T, with key (or parameters) K.
-
-   If E is ENCTYPE_SIGN_MD5_RSA, then
-
-       E (T, K) = {T, RSAEncryptPrivate (MD5Hash (T), K)}
-
-   If E is ENCTYPE_ENCRYPT_RSA_PRIV, then
-
-       E (T, K) = RSAEncryptPrivate (T, K)
-
-   Correspondingly, if E is ENCTYPE_ENCRYPT_RSA_PUB, then
-
-       E (T, K) = RSAEncryptPublic (T, K)
-
-
-3.2 Initial request for user registered with public key on KDC 
-
-   In this scenario it is assumed that the user is registered with a
-   public key on the KDC.  The user's private key may be held by the
-   user, or it may be stored on the KDC, encrypted so that it cannot be
-   used by the KDC.
-
-3.2.1 User's private key is stored locally
-
-   If the user stores his private key locally, the initial request to
-   the KDC for a ticket granting ticket proceeds according to RFC 1510,
-   except that a preauthentication field containing a nonce signed by
-   the user's private key is included.  The preauthentication field
-   may also include a list of the root certifiers trusted by the user.
-
-   PA-PK-AS-ROOT ::= SEQUENCE {
-           rootCert[0]         SEQUENCE OF OCTET STRING,
-           signedAuth[1]       SignedPKAuthenticator
-   }
-
-   SignedPKAuthenticator ::= SEQUENCE {
-           authent[0]          PKAuthenticator,
-           authentSig[1]       Signature
-   }
-
-   PKAuthenticator ::= SEQUENCE {
-           cksum[0]            Checksum OPTIONAL,
-           cusec[1]            INTEGER,
-           ctime[2]            KerberosTime,
-           nonce[3]            INTEGER,
-           kdcRealm[4]         Realm,
-           kdcName[5]          PrincipalName
-   }
-
-   Signature ::= SEQUENCE {
-           sigType[0]          INTEGER,
-           kvno[1]             INTEGER OPTIONAL,
-           sigHash[2]          OCTET STRING
-   }
-
-   Notationally, sigHash is then
-
-       sigType (authent, userPrivateKey)
-
-   where userPrivateKey is the user's private key (corresponding to the
-   public key held in the user's database record).  Valid sigTypes are
-   thus far limited to the above-listed ENCTYPE_SIGN_MD5_RSA; we expect
-   that other types may be listed (and given on-the-wire values between
-   0x0011 and 0x001f).
-
-   The format of each certificate depends on the particular
-   service used.  (Alternatively, the KDC could send, with its reply,
-   a sequence of certifications (see below), but since the KDC is likely
-   to have more certifications than users have trusted root certifiers,
-   we have chosen the first method.)  In the event that the client
-   believes it already possesses the current public key of the KDC,
-   a zero-length root-cert field is sent.
-
-   The fields in the signed authenticator are the same as those
-   in the Kerberos authenticator; in addition, we include a client-
-   generated nonce, and the name of the KDC.  The structure is itself
-   signed using the user's private key corresponding to the public key
-   registered with the KDC.
-
-   Typically, preauthentication using a secret key would not be included,
-   but if included it may be ignored by the KDC.  (We recommend that it
-   not be included: even if the KDC should ignore the preauthentication,
-   an attacker may not, and use an intercepted message to guess the
-   password off-line.)
-
-   The response from the KDC would be identical to the response in RFC 1510,
-   except that instead of being encrypted in the secret key shared by the
-   client and the KDC, it is encrypted in a random key freshly generated
-   by the KDC (of type ENCTYPE_ENC_CBC_CRC).  A preauthentication field
-   (specified below) accompanies the response, optionally containing a
-   certificate with the public key for the KDC (since we do not assume
-   that the client knows this public key), and a package containing the
-   secret key in which the rest of the response is encrypted, along with
-   the same nonce used in the rest of the response, in order to prevent
-   replays.  This package is itself encrypted with the private key of the
-   KDC, then encrypted with the public key of the user.
-
-   PA-PK-AS-REP ::= SEQUENCE {
-           kdcCert[0]          SEQUENCE OF Certificate,
-           encryptShell[1]     EncryptedData, -- EncPaPkAsRepPartShell
-                                              -- encrypted by encReplyTmpKey
-           encryptKey[2]       EncryptedData  -- EncPaPkAsRepTmpKey
-                                              -- encrypted by userPubliKey
-   }
-
-   EncPaPkAsRepPartShell ::= SEQUENCE {
-           encReplyPart[0]     EncPaPkAsRepPart,
-           encReplyPartSig[1]  Signature -- encReplyPart
-                                         -- signed by kdcPrivateKey
-   }
-
-   EncPaPkAsRepPart ::= SEQUENCE {
-           encReplyKey[0]      EncryptionKey,
-           nonce[1]            INTEGER
-   }
-
-   EncPaPkAsRepTmpKey ::= SEQUENCE {
-           encReplyTmpKey[0]   EncryptionKey
-   }
-
-   Notationally, assume that encryptPack is encrypted (or signed) with
-   algorithm Ak, and that encryptShell is encrypted with algorithm Au.
-   Then, encryptShell is
-
-       Au (Ak ({encReplyKey, nonce}, kdcPrivateKey), userPublicKey)
-
-   where kdcPrivateKey is the KDC's private key, and userPublicKey is the
-   user's public key.
-
-   The kdc-cert specification is lifted, with slight modifications,
-   from v3 of the X.509 certificate specification:
-
-   Certificate ::= SEQUENCE {
-           version[0]          Version DEFAULT v1 (1),
-           serialNumber[1]     CertificateSerialNumber,
-           signature[2]        AlgorithmIdentifier,
-           issuer[3]           PrincipalName,
-           validity[4]         Validity,
-           subjectRealm[5]     Realm,
-           subject[6]          PrincipalName,
-           subjectPublicKeyInfo[7] SubjectPublicKeyInfo,
-           issuerUniqueID[8]   IMPLICIT UniqueIdentifier OPTIONAL,
-           subjectUniqueID[9]  IMPLICIT UniqueIdentifier OPTIONAL,
-           authentSig[10]      Signature
-   }
-
-   The kdc-cert must have as its root certification one of the certifiers
-   sent to the KDC with the original request.  If the KDC has no such
-   certification, then it will instead reply with a KRB_ERROR of type
-   KDC_ERROR_PREAUTH_FAILED.  If a zero-length root-cert was sent by the
-   client as part of the PA-PK-AS-ROOT, then a correspondingly zero-length
-   kdc-cert may be absent, in which case the client uses its copy of the
-   KDC's public key.
-
-   Upon receipt of the response from the KDC, the client will verify the
-   public key for the KDC from PA-PK-AS-REP preauthentication data field,
-   The certificate must certify the key as belonging to a principal whose
-   name can be derived from the realm name.  If the certificate checks
-   out, the client then decrypts the EncPaPkAsRepPart using the private
-   key of the user, and verifies the signature of the KDC.  It then uses
-   the random key contained therein to decrypt the rest of the response,
-   and continues as per RFC 1510.  Because there is direct trust between
-   the user and the KDC, the transited field of the ticket returned by
-   the KDC should remain empty. (Cf. Section 3.3.)
-
-
-3.2.2. Private key held by KDC
-
-   Implementation of the changes in this section is OPTIONAL.
-
-   When the user's private key is not carried with the user, the user may
-   encrypt the private key using conventional cryptography, and register
-   the encrypted private key with the KDC.  The MD5 hash of the DES key
-   used to encrypt the private key must also be registered with the KDC.
-
-   We provide this option with the warning that storing the private key
-   on the KDC carries the risk of exposure in case the KDC is compromised.
-   If a suffiently good password is chosen to encrypt the key, then this
-   password can be used for a limited time to change the private key.
-   If the user wishes to authenticate himself without storing the private
-   key on each local disk, then a safer, albeit possibly less practical,
-   alternative is to use a smart card to store the keys.
-
-   When the user's private key is stored on the KDC, the KDC record
-   will also indicate whether preauthentication is required before
-   returning the key (we recommend that it be required).  If such
-   preauthentication is required, when the initial request is received,
-   the KDC will respond with a KRB_ERROR message, with msg-type set
-   to KDC_ERR_PREAUTH_REQUIRED, and e-data set to:
-
-   PA-PK-AS-INFO ::= SEQUENCE {
-           kdcCert[0]          SEQUENCE OF Certificate
-   }
-
-   The kdc-cert field is identical to that in the PA-PK-AS-REP
-   preauthentication data field returned with the KDC response, and must
-   be validated as belonging to the KDC in the same manner.
-
-   Upon receipt of the KRB_ERROR message with a PA-PK-AS-INFO field, the
-   client will prompt the user for the password that was used to
-   encrypt the private key, derive the DES key from that password,
-   and calculate the MD5 hash H1 of the DES key.  The client then sends
-   a request to the KDC, which includes a timestamp and a
-   client-generated random secret key that will be used by the KDC
-   to super-encrypt the encrypted private key before it is returned
-   to the client.  This information is sent to the KDC in a subsequent
-   AS_REQ message in a preauthentication data field:
-
-   PA-PK-AS-REQ ::= SEQUENCE {
-           encHashShell[0]     EncryptedData -- EncPaPkAsReqShell
-   }
-
-   EncPaPkAsReqShell ::= SEQUENCE {
-           encHashPart[0]      EncryptedData -- EncPaPkAsReqPart
-   }
-
-   EncPaPkAsReqPart ::= SEQUENCE {
-           encHashKey[0]       EncryptionKey,
-           nonce[1]            INTEGER
-   }
-
-   The EncPaPkAsReqPart is first encrypted with a DES key K1, derived
-   by string_to_key from the hash H1 (with null salt), then encrypted
-   again with the KDC's public key from the certificate in the
-   PA-PK-AS-INFO field of the error response.
-
-   Notationally, if encryption algorithm A is used for DES encryption,
-   and Ak is used for the public key encryption, then enc-shell is
-
-       Ak (A ({encHashKey, nonce}, K1), kdcPublicKey)
-
-   Upon receipt of the authentication request with the PA-PK-AS-REQ, the
-   KDC verifies the hash of the user's DES encryption key by attempting
-   to decrypt the EncPaPkAsReqPart of the PA-PK-AS-REQ.  If decryption
-   is successful, the KDC generates the AS response as defined in
-   RFC 1510, but additionally includes a preauthentication field of type
-   PA-PK-USER-KEY.  (This response will also be included in response to
-   the initial request without preauthentication if preauthentication is
-   not required for the user and the user's encrypted private key is
-   stored on the KDC.)
-
-   PA-PK-USER-KEY ::= SEQUENCE {
-           encUserKeyPart[0]   EncryptedData -- EncPaPkUserKeyPart
-   }
-
-   EncPaPkUserKeyPart ::= SEQUENCE {
-           encUserKey[0]       OCTET STRING,
-           nonce[1]            INTEGER
-   }
-
-   Notationally, if encryption algorithm A is used, then enc-key-part is
-
-       A ({encUserKey, nonce}, enc-hash-key)
-
-   (where A could be null encryption).
-
-   This message contains the encrypted private key that has been
-   registered with the KDC by the user, as encrypted by the user,
-   optionally super-encrypted with the enc-hash-key from the PA-PK-AS-REQ
-   message if preauthentication using that method was provided (otherwise,
-   the EncryptedData should denote null encryption).  Note that since
-   H1 is a one-way hash, it is not possible for one to decrypt the
-   message if one possesses H1 but not the DES key that H1 is derived
-   from.  Because there is direct trust between the user and the
-   KDC, the transited field of the ticket returned by the KDC should
-   remain empty.  (Cf. Section 3.3.)
-
-
-3.3. Clients with a public key certified by an outside authority
-
-   Implementation of the changes in this section is OPTIONAL.
-
-   In the case where the client is not registered with the current KDC,
-   the client is responsible for obtaining the private key on its own.
-   The client will request initial tickets from the KDC using the TGS
-   exchange, but instead of performing pre-authentication using a
-   Kerberos ticket granting ticket, or with the PA-PK-AS-REQ that is used
-   when the public key is known to the KDC, the client performs
-   preauthentication using the preauthentication data field of type
-   PA-PK-AS-EXT-CERT:
-
-   PA-PK-AS-EXT-CERT ::= SEQUENCE {
-           userCert[0]         SEQUENCE OF OCTET STRING,
-           signedAuth[1]       SignedPKAuthenticator
-   }
-
-   where the user-cert specification depends on the type of certificate
-   that the user possesses.  In cases where the service has separate
-   key pairs for digital signature and for encryption, we recommend
-   that the signature keys be used for the purposes of sending the
-   preauthentication (and deciphering the response).
-
-   The authenticator is the one used from the exchange in section 3.2.1,
-   except that it is signed using the private key corresponding to
-   the public key in the user-cert.
-
-   The KDC will verify the preauthentication authenticator, and check the
-   certification path against its own policy of legitimate certifiers.
-   This may be based on a certification hierarchy, or simply a list of
-   recognized certifiers in a system like PGP.
-
-   If all checks out, the KDC will issue Kerberos credentials, as in 3.2,
-   but with the names of all the certifiers in the certification path
-   added to the transited field of the ticket, with a principal name
-   taken from the certificate (this might be a long path for X.509, or a
-   string like "John Q. Public <jqpublic@company.com>" if the certificate
-   was a PGP certificate.  The realm will identify the kind of
-   certificate and the final certifier as follows:
-
-       cert_type/final_certifier
-
-   as in PGP/<endorser@company.com>.
-
-
-3.4. Digital Signature
-
-   Implementation of the changes in this section is OPTIONAL.
-
-   We offer this option with the warning that it requires the client
-   process to generate a random DES key; this generation may not
-   be able to guarantee the same level of randomness as the KDC.
-
-   If a user registered a digital signature key pair with the KDC,
-   a separate exchange may be used.  The client sends a KRB_AS_REQ as
-   described in section 3.2.2.  If the user's database record
-   indicates that a digital signature key is to be used, then the
-   KDC sends back a KRB_ERROR as in section 3.2.2.
-
-   It is assumed here that the signature key is stored on local disk.
-   The client generates a random key of enctype ENCTYPE_DES_CBC_CRC,
-   signs it using the signature key (otherwise the signature is
-   performed as described in section 3.2.1), then encrypts the whole with
-   the public key of the KDC.  This is returned with a separate KRB_AS_REQ
-   in a preauthentication of type
-
-   PA-PK-AS-SIGNED ::= SEQUENCE {
-           signedKey[0]        EncryptedData -- PaPkAsSignedData
-   }
-
-   PaPkAsSignedData ::= SEQUENCE {
-           signedKeyPart[0]    SignedKeyPart,
-           signedKeyAuth[1]    PKAuthenticator
-   }
-
-   SignedKeyPart ::= SEQUENCE {
-           encSignedKey[0]     EncryptionKey,
-           nonce[1]            INTEGER
-   }
-
-   where the nonce is the one from the request.  Upon receipt of the
-   request, the KDC decrypts, then verifies the random key.  It then
-   replies as per RFC 1510, except that instead of being encrypted
-   with the password-derived DES key, the reply is encrypted using
-   the randomKey sent by the client.  Since the client already knows
-   this key, there is no need to accompany the reply with an extra
-   preauthentication field.  Because there is direct trust between
-   the user and the KDC, the transited field of the ticket returned
-   by the KDC should remain empty.  (Cf. Section 3.3.)
-
-
-4. Preauthentication Data Types
-
-   We propose that the following preauthentication types be allocated
-   for the preauthentication data packages described in this draft:
-
-       #define KRB5_PADATA_ROOT_CERT     17  /* PA-PK-AS-ROOT */
-       #define KRB5_PADATA_PUBLIC_REP    18  /* PA-PK-AS-REP */
-       #define KRB5_PADATA_PUBLIC_REQ    19  /* PA-PK-AS-REQ */
-       #define KRB5_PADATA_PRIVATE_REP   20  /* PA-PK-USER-KEY */
-       #define KRB5_PADATA_PUBLIC_EXT    21  /* PA-PK-AS-EXT-CERT */
-       #define KRB5_PADATA_PUBLIC_SIGN   22  /* PA-PK-AS-SIGNED */
-
-
-5. Encryption Information
-
-   For the public key cryptography used in direct registration, we used
-   (in our implementation) the RSAREF library supplied with the PGP 2.6.2
-   release.  Encryption and decryption functions were implemented directly
-   on top of the primitives made available therein, rather than the
-   fully sealing operations in the API.
-
-
-6. Compatibility with One-Time Passcodes
-
-   We solicit discussion on how the use of public key cryptography for initial
-   authentication will interact with the proposed use of one time passwords
-   discussed in Internet Draft <draft-ietf-cat-kerberos-passwords-00.txt>.
-
-
-7. Strength of Encryption and Signature Mechanisms
-
-   In light of recent findings on the strengths of MD5 and various DES
-   modes, we solicit discussion on which modes to incorporate into the
-   protocol changes.
-
-
-8. Expiration
-
-   This Internet-Draft expires on December 7, 1996.
-
-
-9. Authors' Addresses
-
-   B. Clifford Neuman
-   USC/Information Sciences Institute
-   4676 Admiralty Way Suite 1001
-   Marina del Rey, CA 90292-6695
-
-   Phone: 310-822-1511
-   EMail: bcn@isi.edu
-
-   Brian Tung
-   USC/Information Sciences Institute
-   4676 Admiralty Way Suite 1001
-   Marina del Rey, CA 90292-6695
-
-   Phone: 310-822-1511
-   EMail: brian@isi.edu
-
-   John Wray
-   Digital Equipment Corporation
-   550 King Street, LKG2-2/Z7
-   Littleton, MA 01460
-
-   Phone: 508-486-5210
-   EMail: wray@tuxedo.enet.dec.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt
deleted file mode 100644
index 1a15ae33e..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-02.txt
+++ /dev/null
@@ -1,1120 +0,0 @@
-INTERNET-DRAFT                                         Clifford Neuman
-draft-ietf-cat-kerberos-pk-init-02.txt                      Brian Tung
-Updates: RFC 1510                                                  ISI
-expires April 19, 1997                                       John Wray
-                                         Digital Equipment Corporation
-						      Jonathan Trostle
-						 CyberSafe Corporation
-
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-
-0. 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 docu-
-   ments at any time.  It is inappropriate to use  Internet-Drafts  as
-   reference  material  or  to  cite them other than as ``work in pro-
-   gress.''
-
-   To learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
-   dow Directories on ds.internic.net (US East  Coast),  nic.nordu.net
-   (Europe),  ftp.isi.edu  (US  West Coast), or munnari.oz.au (Pacific
-   Rim).
-
-   The distribution of  this  memo  is  unlimited.   It  is  filed  as
-   draft-ietf-cat-kerberos-pk-init-02.txt, and expires April 19, 1997.
-   Please send comments to the authors.
-
-
-1. Abstract
-
-   This document defines extensions to the Kerberos protocol
-   specification (RFC 1510, "The Kerberos Network Authentication
-   Service (V5)", September 1993) to provide a method for using public
-   key cryptography during initial authentication.  The method defined
-   specifies the way in which preauthentication data fields and error
-   data fields in Kerberos messages are to be used to transport public
-   key data. 
-
-2. Motivation
-
-   Public key cryptography presents a means by which a principal may
-   demonstrate possession of a key, without ever having divulged this
-   key to anyone else.  In conventional cryptography, the encryption
-   key and decryption key are either identical or can easily be
-   derived from one another. In public key cryptography, however,
-   neither the public key nor the private key can be derived from the
-   other (although the private key RECORD may include the information
-   required to generate BOTH keys). Hence, a message encrypted with a
-   public key is private, since only the person possessing the private
-   key can decrypt it; similarly, someone possessing the private key
-   can also encrypt a message, thus providing a digital signature.
-
-   Furthermore, conventional keys are often derived from passwords, so
-   messages encrypted with these keys are susceptible to dictionary
-   attacks, whereas public key pairs are generated from a
-   pseudo-random number sequence.  While it is true that messages
-   encrypted using public key cryptography are actually encrypted with
-   a conventional secret key, which is in turn encrypted using the
-   public key pair, the secret key is also randomly generated and is
-   hence not vulnerable to a dictionary attack.
-
-   The advantages provided by public key cryptography have produced a
-   demand for its integration into the Kerberos authentication
-   protocol. The public key integration into Kerberos described in
-   this document has three goals. 
-
-   First, by allowing users to register public keys with the KDC, the
-   KDC can be recovered much more easily in the event it is
-   compromised. With Kerberos as it currently stands, compromise of
-   the KDC is disastrous. All keys become known by the attacker and
-   all keys must be changed. Second, we allow users that have public
-   key certificates signed by outside authorities to obtain Kerberos
-   credentials for access to Kerberized services. Third, we obtain the
-   above benefits while maintaining the performance advantages of
-   Kerberos over protocols that use only public key authentication. 
-
-   If users register public keys, compromise of the KDC does not
-   divulge their private key.  Compromise of security on the KDC is
-   still a problem, since an attacker can impersonate any user by
-   creating a ticket granting ticket for the user. When the compromise
-   is detected, the KDC can be cleaned up and restored from backup
-   media and loaded with a backup private/public key pair. Keys for
-   application servers are conventional symmetric keys and must be
-   changed.
-
-   Note: If a user stores his private key, in an encrypted form, on
-   the KDC, then it may be desirable to change the key pair, since the
-   private key is encrypted using a symmetric key derived from a
-   password (as described below), and can therefore be vulnerable to
-   dictionary attack if a good password policy is not used. 
-   Alternatively, if the encrypting symmetric key has 56 bits, then it
-   may also be desirable to change the key pair after a short period
-   due to the short key length. The KDC does not have access to the
-   user's unencrypted private key.
-
-   There are two important areas where public key cryptography will
-   have immediate use: in the initial authentication of users
-   registered with the KDC or using public key certificates from
-   outside authorities, and to establish inter-realm keys for
-   cross-realm authentication. This memo describes a method by which
-   the first of these can be done. The second case will be the topic
-   for a separate proposal.
-
-   Some of the ideas on which this proposal is based arose during
-   discussions over several years between members of the SAAG, the
-   IETF-CAT working group, and the PSRG, regarding integration of
-   Kerberos and SPX.  Some ideas are drawn from the DASS system, and
-   similar extensions have been discussed for use in DCE.  These
-   changes are by no means endorsed by these groups.  This is an
-   attempt to revive some of the goals of that group, and the
-   proposal approaches those goals primarily from the Kerberos
-   perspective.
-
-3. Initial authentication of users with public keys
-
-   This section describes the extensions to Version 5 of the Kerberos
-   protocol that will support the use of public key cryptography by
-   users in the initial request for a ticket granting ticket.  
-
-   Roughly speaking, the following changes to RFC 1510 are proposed:
-   Users can initially authenticate using public key or conventional
-   (symmetric key) cryptography. After a KDC compromise, the KDC
-   replies with an error message that informs the client of the new
-   KDC public backup key. Users must authenticate using public key 
-   cryptography in response to the error message. If applicable, the 
-   client generates the new user secret key at this point as well. 
-
-   Public key initial authentication is performed using either the 
-   RSA encryption or Diffie Hellman public key algorithms. There is 
-   also an option to allow the user to store his/her private key 
-   encrypted in the user password in the KDC database; this option 
-   solves the problem of transporting the user private key to
-   different workstations. The combination of this option and the
-   provision for conventional symmetric key authentication allows
-   organizations to smoothly migrate to public key cryptography.
-
-   This proposal will allow users either to use keys registered
-   directly with the KDC, or to use keys already registered for use
-   with X.509, PEM, or PGP, to obtain Kerberos credentials.  These
-   credentials can then be used, as before, with application servers
-   supporting Kerberos. Use of public key cryptography will not be a
-   requirement for Kerberos, but if one's organization runs a KDC
-   supporting public key, then users may choose to be registered with
-   a public key pair, instead of or in addition to the current secret
-   key.
-
-   The application request and response between Kerberos clients and
-   application servers will continue to be based on conventional
-   cryptography, or will be converted to use user-to-user
-   authentication.  There are performance issues and other reasons
-   that servers may be better off using conventional cryptography.
-   For this proposal, we feel that 80 percent of the benefits of
-   integrating public key with Kerberos can be attained for 20 percent
-   of the effort, by addressing only initial authentication. This
-   proposal does not preclude separate extensions.
-
-   With these changes, users will be able to register public keys,
-   only in realms that support public key, but they will still be able
-   to perform initial authentication from a client that does not
-   support public key. They will be able to use services registered in
-   any realm. Furthermore, users registered with conventional keys
-   will be able to use any client.
-
-   This proposal addresses three ways in which users may use public
-   key cryptography for initial authentication with Kerberos, with
-   minimal change to the existing protocol.  Users may register keys
-   directly with the KDC, or they may present certificates by outside
-   certification authorities (or certifications by other users)
-   attesting to the association of the public key with the named user.
-   In both cases, the end result is that the user obtains a
-   conventional ticket granting ticket or conventional server ticket
-   that may be used for subsequent authentication, with such
-   subsequent authentication using only conventional cryptography.
-
-   Additionally, users may also register a digital signature
-   verification key with the KDC.  We provide this option for the
-   licensing benefits, as well as a simpler variant of the initial
-   authentication exchange. However, this option relies on the client
-   to generate random keys.
-
-   We first consider the case where the user's key is registered with
-   the KDC.
-
-3.1 Definitions
-
-   Before we proceed, we will lay some groundwork definitions for
-   encryption and signatures.  We propose the following definitions
-   of signature and encryption modes (and their corresponding values
-   on the wire):
-
-       #define ENCTYPE_SIGN_MD5_RSA      0x0011
-
-       #define ENCTYPE_ENCRYPT_RSA_PRIV  0x0021
-       #define ENCTYPE_ENCRYPT_RSA_PUB   0x0022
-
-   allowing further modes to be defined accordingly.
-
-   In the exposition below, we will use the notation E (T, K) to
-   denote the encryption of data T, with key (or parameters) K.
-
-   If E is ENCTYPE_SIGN_MD5_RSA, then
-
-       E (T, K) = {T, RSAEncryptPrivate (MD5Hash (T), K)}
-
-   If E is ENCTYPE_ENCRYPT_RSA_PRIV, then
-
-       E (T, K) = RSAEncryptPrivate (T, K)
-
-   Correspondingly, if E is ENCTYPE_ENCRYPT_RSA_PUB, then
-
-       E (T, K) = RSAEncryptPublic (T, K)
-
-
-3.2 Initial request for user registered with public key on KDC 
-
-   In this scenario it is assumed that the user is registered with a
-   public key on the KDC.  The user's private key may be held by the
-   user, or it may be stored on the KDC, encrypted so that it cannot
-   be used by the KDC.
-
-3.2.1 User's private key is stored locally
-
-   Implementation of the changes in this section is REQUIRED.
-
-   In this section, we present the basic Kerberos V5 pk-init protocol
-   that all conforming implementations must support. The key features 
-   of the protocol are: (1) easy, automatic (for the clients) recovery 
-   after a KDC compromise, (2) the ability for a realm to support a
-   mix of old and new Kerberos V5 clients with the new clients being a
-   mix of both public key and symmetric key configured clients, and
-   (3) support for Diffie-Hellman (DH) key exchange as well as RSA
-   public key encryption. The benefit of having new clients being able
-   to use either symmetric key or public key initial authentication is
-   that it allows an organization to roll out the new clients as
-   rapidly as possible without having to be concerned about the need
-   to purchase additional hardware to support the CPU intensive public
-   key cryptographic operations. 
-
-   In order to give a brief overview of the four protocols in this
-   section, we now give diagrams of the protocols. We denote
-   encryption of message M with key K by {M}K and the signature of
-   message M with key K by [M]K. All messages from the KDC to the
-   client are AS_REP messages unless denoted otherwise; similarly, all
-   messages from the client to the KDC are AS_REQ messages unless
-   denoted otherwise. Since only the padata fields are affected by
-   this specification in the AS_REQ and AS_REP messages, we do not
-   show the other fields. We first show the RSA encryption option in
-   normal mode:
-       
-      certifier list, [cksum, time, nonce, kdcRealm, 
-      kdcName]User PrivateKey
-   C ------------------------------------------------------> KDC
-
-      list of cert's, {[encReplyKey, nonce]KDC privkey}
-      EncReplyTmpKey, {EncReplyTmpKey}Userpubkey
-   C <------------------------------------------------------ KDC
-
-
-   We now show RSA encryption in recovery mode:
-
-      certifier list, [cksum, time, nonce, kdcRealm, 
-      kdcName]User PrivateKey
-   C ------------------------------------------------------> KDC
-
-
-      KRB_ERROR (error code KDC_RECOVERY_NEEDED) 
-                 error data: [nonce, algID (RSA), 
-                 KDC PublicKey Kvno and PublicKey, KDC Salt]
-                 Signed with KDC PrivateKey
-   C <------------------------------------------------------ KDC
-
-
-      certifier list, [cksum, time, nonce, kdcRealm, kdcName, 
-      {newUserSymmKey, nonce}KDC public key]User PrivateKey
-   C ------------------------------------------------------> KDC
-
-
-      list of cert's, {[encReplyKey, nonce]KDC privkey}
-      EncReplyTmpKey, {EncReplyTmpKey}Userpubkey
-   C <------------------------------------------------------ KDC
-
-   Next, we show Diffie Hellman in normal mode:
-
-      certifier list, [cksum, time, nonce, kdcRealm, kdcName, 
-      User DH public parameter]User PrivateKey
-   C ------------------------------------------------------> KDC
-
-
-      list of cert's, {encReplyKey, nonce}DH shared symmetric 
-      key, [KDC DH public parameter]KDC Private Key
-   C <------------------------------------------------------ KDC
-
-
-   Finally, we show Diffie Hellman in recovery mode:
-
-      certifier list, [cksum, time, nonce, kdcRealm, kdcName, 
-      User DH public parameter]User PrivateKey
-   C ------------------------------------------------------> KDC
-
-
-      KRB_ERROR (error code KDC_RECOVERY_NEEDED)
-                error data: [nonce, algID (DH), KDC DH public 
-                             parameter, KDC DH ID, KDC PublicKey 
-                             Kvno and PublicKey, KDC Salt]
-                             Signed with KDC PrivateKey
-   C <------------------------------------------------------ KDC
-
-
-      certifier list, [cksum, time, nonce, kdcRealm, 
-      kdcName, User DH public parameter, {newUserSymmKey, 
-      nonce}DH shared key, KDC DH ID]User PrivateKey
-   C ------------------------------------------------------> KDC
-
-
-      list of cert's, {encReplyKey, nonce}DH shared 
-      symmetric key
-   C <------------------------------------------------------ KDC
-
-
-
-   If the user stores his private key locally, the initial request 
-   to the KDC for a ticket granting ticket proceeds according to 
-   RFC 1510, except that a preauthentication field containing a 
-   nonce signed by the user's private key is included.  The 
-   preauthentication field may also include a list of the root 
-   certifiers trusted by the user.
-
-   PA-PK-AS-ROOT ::= SEQUENCE {
-           rootCert[0]         SEQUENCE OF OCTET STRING,
-           signedAuth[1]       SignedPKAuthenticator
-   }
-
-   SignedPKAuthenticator ::= SEQUENCE {
-           authent[0]          PKAuthenticator,
-           authentSig[1]       Signature
-   }
-
-   PKAuthenticator ::= SEQUENCE {
-           cksum[0]            Checksum OPTIONAL,
-           cusec[1]            INTEGER,
-           ctime[2]            KerberosTime,
-           nonce[3]            INTEGER,
-           kdcRealm[4]         Realm,
-           kdcName[5]          PrincipalName,
-	   clientPubValue[6]   SubjectPublicKeyInfo OPTIONAL, 
-                                  -- DH algorithm
-	   recoveryData[7]     RecoveryData OPTIONAL          
-                                  -- Recovery Alg.
-   }
-
-   RecoveryData ::= SEQUENCE {
-           clientRecovData[0]  ClientRecovData, 
-	   kdcPubValueId[1]    INTEGER OPTIONAL 
-                                   -- DH algorithm, copied
-                                   -- from KDC response     
-   }
-
-   ClientRecovData ::= CHOICE {
-           newPrincKey[0]      EncryptedData, -- EncPaPkAsRoot
-					      -- encrypted with 
-                                              -- either KDC 
-					      -- public key or 
-                                              -- DH shared key   
-           recovDoneFlag[1]    INTEGER        -- let KDC know that
-                                              -- recovery is done
-                                              -- when user uses a
-                                              -- mix of clients or
-                                              -- does not want to
-                                              -- keep a symmetric
-                                              -- key in the database
-   }
-
-   EncPaPkAsRoot ::= SEQUENCE {
-           newSymmKey[0]       EncryptionKey  -- the principal's new 
-                                              -- symmetric key
-           nonce[1]            INTEGER        -- the same nonce as
-                                              -- the one in the 
-                                              -- PKAuthenticator  
-   }
-
-   Signature ::= SEQUENCE {
-           sigType[0]          INTEGER,
-           kvno[1]             INTEGER OPTIONAL,
-           sigHash[2]          OCTET STRING
-   }
-
-   Notationally, sigHash is then
-
-       sigType (authent, userPrivateKey)
-
-   where userPrivateKey is the user's private key (corresponding to the
-   public key held in the user's database record). Valid sigTypes are
-   thus far limited to the above-listed ENCTYPE_SIGN_MD5_RSA; we expect
-   that other types may be listed (and given on-the-wire values between
-   0x0011 and 0x001f).
-
-   The format of each certificate depends on the particular service
-   used.  (Alternatively, the KDC could send, with its reply, a
-   sequence of certifications (see below), but since the KDC is likely
-   to have more certifications than users have trusted root certifiers,
-   we have chosen the first method.)  In the event that the client
-   believes it already possesses the current public key of the KDC, a
-   zero-length root-cert field is sent.
-
-   The fields in the signed authenticator are the same as those in the
-   Kerberos authenticator; in addition, we include a client-generated
-   nonce, and the name of the KDC.  The structure is itself signed
-   using the user's private key corresponding to the public key 
-   registered with the KDC. We include the newSymmKey field so clients
-   can generate a new symmetric key (for users, this key is based on
-   a password and a salt value generated by the KDC) and
-   confidentially send this key to the KDC during the recovery phase. 
-
-   We now describe the recovery phase of the protocol. There is a bit
-   associated with each principal in the database indicating whether
-   recovery for that principal is necessary. After a KDC compromise,
-   the KDC software is reloaded from backup media and a new backup
-   KDC public/private pair is generated. The public half of this pair
-   is then either made available to the KDC, or given to the
-   appropriate certification authorities for certification. The private
-   half is not made available to the KDC until after the next
-   compromise clean-up. If clients are maintaining a copy of the KDC
-   public key, they also have a copy of the backup public key.
-
-   After the reload of KDC software, the bits associated with
-   recovery of each principal are all set. The KDC clears the bit
-   for each principal that undergoes the recovery phase. In addition,
-   there is a bit associated with each principal to indicate whether
-   there is a valid symmetric key in the database for the principal.
-   These bits are all cleared after the reload of the KDC software
-   (the old symmetric keys are no longer valid). Finally, there is a
-   bit associated with each principal indicating whether that
-   principal still uses non-public key capable clients. If a user
-   principal falls into this category, a public key capable client
-   cannot transparently re-establish a symmetric key for that user,
-   since the older clients would not be able to compute the new
-   symmetric key that includes hashing the password with a KDC
-   supplied salt value. The re-establishment of the symmetric key 
-   in this case is outside the scope of this protocol. 
-
-   One method of re-establishing a symmetric key for public key
-   capable clients is to generate a hash of the user password and a
-   KDC supplied salt value. The KDC salt is changed after every
-   compromise of the KDC. In the recovery protocol, if the principal
-   does not still use old clients, the KDC supplied salt is sent to
-   the client principal in a KRB_ERROR message with error code
-   KDC_RECOVERY_NEEDED. The error data field of the message contains
-   the following structure which is encoded into an octet string.
-
-   PA-PK-KDC-ERR ::= CHOICE {
-           recoveryDhErr      SignedDHError,   -- Used during recovery   
-                                               -- when algorithm is DH 
-                                               -- based
-           recoveryPKEncErr   SignedPKEncError -- Used during recovery
-                                               -- for PK encryption 
-                                               -- (RSA,...)
-   }
-
-   SignedDHError ::= SEQUENCE {
-           dhErr              DHError,
-           dhErrSig           Signature
-   }
-
-   SignedPKEncError ::= SEQUENCE {
-           pkEncErr           PKEncryptError,
-           pkEncErrSig        Signature
-   }
-
-   DHError ::= SEQUENCE {
-           nonce	      INTEGER,		     -- From AS_REQ
-           algorithmId        INTEGER,               -- DH algorithm
-           kdcPubValue        SubjectPublicKeyInfo,  -- DH algorithm
-           kdcPubValueId      INTEGER,               -- DH algorithm
-           kdcPublicKeyKvno   INTEGER OPTIONAL,      -- New KDC public
-                                                     -- key kvno
-           kdcPublicKey       OCTET STRING OPTIONAL, -- New KDC pubkey
-	   kdcSalt            OCTET STRING OPTIONAL  -- If user uses 
-                                                     -- only new
-                                                     -- clients
-   }
-
-   PKEncryptError ::= SEQUENCE {
-           nonce              INTEGER,               -- From AS_REQ
-           algorithmId        INTEGER,               -- Public Key
-                                                     -- encryption alg
-           kdcPublicKeyKvno   INTEGER OPTIONAL,      -- New KDC public 
-                                                     -- key kvno
-           kdcPublicKey       OCTET STRING OPTIONAL, -- New KDC public
-                                                     -- key
-	   kdcSalt            OCTET STRING OPTIONAL  -- If user uses 
-                                                     -- only new
-                                                     -- clients
-   }
-
-   The KDC_RECOVERY_NEEDED error message is sent in response to a 
-   client AS_REQ message if the client principal needs to be 
-   recovered, unless the client AS_REQ contains the PKAuthenticator
-   with a nonempty RecoveryData field (in this case the client has
-   already received the KDC_RECOVERY_NEEDED error message. We will
-   also see in section 3.2.2 that a different error response is
-   sent by the KDC if the encrypted user private key is stored in
-   the KDC database.) If the client principal uses only new clients, 
-   then the kdcSalt field is returned; otherwise, the kdcSalt field
-   is absent. 
-
-   If the client uses the Diffie Hellman algorithm during the recovery
-   phase then the DHError field contains the public Diffie Hellman 
-   parameter (kdcPubValue) for the KDC along with an identifier 
-   (kdcPubValueID). The client will then send this identifier to 
-   the KDC in an AS_REQ message; the identifier allows the KDC to 
-   look up the Diffie Hellman private value corresponding to the
-   identifier. Depending on how often the KDC updates its private
-   Diffie Hellman parameters, it will have to store anywhere between a
-   handful and several dozen of these identifiers and their parameters.
-   The KDC must send its Diffie Hellman public value to the client
-   first so the client can encrypt its new symmetric key.
-
-   In the case where the user principal does not need to be recovered
-   and the user still uses old clients as well as new clients, the 
-   KDC_ERR_NULL_KEY error is sent in response to symmetric AS_REQ 
-   messages when there is no valid symmetric key in the KDC database. 
-   This situation can occur if the user principal has been recovered 
-   but no new symmetric key has been established in the database.
- 
-   In addition, the two error messages with error codes 
-   KDC_ERR_PREAUTH_FAILED and KDC_ERR_PREAUTH_REQUIRED are modified 
-   so the error data contains the kdcSalt encoded as an OCTET STRING. 
-   The reason for the modification is to allow principals that use 
-   new clients only to have their symmetric key transparently updated
-   by the client software during the recovery phase. The kdcSalt is
-   used to create the new symmetric key. As a performance optimization,
-   the kdcSalt is stored in the /krb5/salt file along with the realm.
-   Thus the /krb5/salt file consists of realm-salt pairs. If the file
-   is missing, or the salt is not correct, the above error messages
-   allow the client to find out the correct salt. New clients which 
-   are configured for symmetric key authentication attempt to 
-   preauthenticate with the salt from the /krb5/salt file as an 
-   input into their key, and if the file is not present, the new client
-   does not use preauthentication. The error messages above return
-   either the correct salt to use, or no salt at all which indicates
-   that the principal is still using old clients (the client software
-   should use the existing mapping from the user password to the
-   symmetric key).
-
-   In order to assure interoperability between clients from different
-   vendors and organizations, a standard algorithm is needed for
-   creating the symmetric key from the principal password and kdcSalt.
-   The algorithm for creating the symmetric key is as follows: take the
-   SHA-1 hash of the kdcSalt concatenated with the principal password
-   and use the 20 byte output as the input into the existing key
-   generation process (string to key function). After a compromise, the
-   KDC changes the kdcSalt; thus, the recovery algorithm allows users
-   to obtain a new symmetric key without actually changing their
-   password.
-
-   The response from the KDC would be identical to the response in RFC
-   1510, except that instead of being encrypted in the secret key
-   shared by the client and the KDC, it is encrypted in a random key
-   freshly generated by the KDC (of type ENCTYPE_ENC_CBC_CRC). A 
-   preauthentication field (specified below) accompanies the response, 
-   optionally containing a certificate with the public key for the KDC 
-   (since we do not assume that the client knows this public key), and
-   a package containing the secret key in which the rest of the 
-   response is encrypted, along with the same nonce used in the rest
-   of the response, in order to prevent replays. This package is itself
-   signed with the private key of the KDC, then encrypted with the
-   symmetric key that is returned encrypted in the public key of the
-   user (or for Diffie Hellman, encrypted in the shared secret Diffie
-   Hellman symmetric key). 
-
-   Pictorially, in the public key encryption case we have:
-
-   kdcCert, {[encReplyKey, nonce] Sig w/KDC 
-   privkey}EncReplyTmpKey, {EncReplyTmpKey}Userpubkey
-
-   Pictorially, in the Diffie Hellman case we have:
-
-   kdcCert, {encReplyKey, nonce}DH shared symmetric key,
-   [DH public value]Sig w/KDC privkey
-
-   PA-PK-AS-REP ::= SEQUENCE {
-           kdcCert[0]          SEQUENCE OF Certificate,
-           encryptShell[1]     EncryptedData, 
-                                           -- EncPaPkAsRepPartShell
-                                           -- encrypted by 
-                                           -- encReplyTmpKey or DH 
-                                           -- shared symmetric key
-           pubKeyExchange[2]   PubKeyExchange OPTIONAL, 
-                                           -- a choice between 
-                                           -- a KDC signed DH 
-                                           -- value and a public 
-                                           -- key encrypted 
-                                           -- symmetric key.
-                                           -- Not needed after
-                                           -- recovery when
-                                           -- DH is used.
-   }                                         
-
-   PubKeyExchange ::= CHOICE {
-           signedDHPubVal      SignedDHPublicValue, 
-           encryptKey          EncryptedData  
-                                           -- EncPaPkAsRepTmpKey
-                                           -- encrypted by 
-                                           -- userPublicKey
-   }
-
-   SignedDHPublicValue ::= SEQUENCE {
-           dhPublic[0]         SubjectPublicKeyInfo,
-           dhPublicSig[1]      Signature
-   }
-
-   EncPaPkAsRepPartShell ::= SEQUENCE {
-           encReplyPart[0]     EncPaPkAsRepPart,
-           encReplyPartSig[1]  Signature OPTIONAL 
-                                    -- encReplyPart
-                                    -- signed by kdcPrivateKey
-                                    -- except not present in 
-                                    -- DH case
-   }
-
-   EncPaPkAsRepPart ::= SEQUENCE {
-           encReplyKey[0]      EncryptionKey,
-           nonce[1]            INTEGER,
-   }
-
-   EncPaPkAsRepTmpKey ::= SEQUENCE {
-           encReplyTmpKey[0]   EncryptionKey
-   }
-
-   The kdc-cert specification is lifted, with slight modifications,
-   from v3 of the X.509 certificate specification:
-
-   Certificate ::= SEQUENCE {
-           version[0]          Version DEFAULT v1 (1),
-           serialNumber[1]     CertificateSerialNumber,
-           signature[2]        AlgorithmIdentifier,
-           issuer[3]           PrincipalName,
-           validity[4]         Validity,
-           subjectRealm[5]     Realm,
-           subject[6]          PrincipalName,
-           subjectPublicKeyInfo[7] SubjectPublicKeyInfo,
-           issuerUniqueID[8]   IMPLICIT UniqueIdentifier OPTIONAL,
-           subjectUniqueID[9]  IMPLICIT UniqueIdentifier OPTIONAL,
-           authentSig[10]      Signature
-   }
-
-   The kdc-cert must have as its root certification one of the
-   certifiers sent to the KDC with the original request.  If the KDC
-   has no such certification, then it will instead reply with a
-   KRB_ERROR of type KDC_ERROR_PREAUTH_FAILED.  If a zero-length
-   root-cert was sent by the client as part of the PA-PK-AS-ROOT, then
-   a correspondingly zero-length kdc-cert may be absent, in which case
-   the client uses its copy of the KDC's public key. In the case of
-   recovery, the client uses its copy of the backup KDC public key. 
-
-   Upon receipt of the response from the KDC, the client will verify 
-   the public key for the KDC from PA-PK-AS-REP preauthentication data 
-   field. The certificate must certify the key as belonging to a
-   principal whose name can be derived from the realm name.  If the
-   certificate checks out, the client then decrypts the EncPaPkAsRepPart
-   and verifies the signature of the KDC.  It then uses the random key
-   contained therein to decrypt the rest of the response, and continues
-   as per RFC 1510. Because there is direct trust between the user and
-   the KDC, the transited field of the ticket returned by the KDC should
-   remain empty. (Cf. Section 3.3.)
-
-   Examples
-
-   We now give several examples illustrating the protocols in this 
-   section. Encryption of message M with key K is denoted {M}K and
-   the signature of message M with key K is denoted [M]K.
-
-   Example 1: The requesting user principal needs to be recovered and
-   uses only new clients. The recovery algorithm is Diffie Hellman (DH).
-   Then the exchange sequence between the user principal and the KDC is:
-
-   
-   Client  --------> AS_REQ (with or without preauth) --------> KDC
-
-   Client  <--- KRB_ERROR (error code KDC_RECOVERY_NEEDED) <--- KDC
-                error data: [nonce, algID (DH), KDC DH public parameter,
-                            KDC DH ID, KDC PublicKey Kvno and PublicKey,
-                            KDC Salt]Signed with KDC PrivateKey
-
-   At this point, the client validates the KDC signature, checks to 
-   see if the nonce is the same as the one in the AS_REQ, and stores
-   the new KDC public key and public key version number. The client 
-   then generates a Diffie Hellman private parameter and computes
-   the corresponding Diffie Hellman public parameter; the client
-   also computes the shared Diffie Hellman symmetric key using the
-   KDC Diffie Hellman public parameter and its own Diffie Hellman 
-   private parameter. Next, the client prompts the user for his/her
-   password (if it does not already have the password). The password
-   is concatenated with the KDC Salt and then SHA1 hashed; the 
-   result is fed into the string to key function to obtain the new
-   user DES key.
-
-   The new user DES key will be encrypted (along with the AS_REQ
-   nonce) using the Diffie Hellman symmetric key and sent to the 
-   KDC in the new AS_REQ message:
-
-   Client -> AS_REQ with preauth: rootCert, [PKAuthenticator with
-             user DH public parameter, {newUser DES key, nonce}DH 
-             symmetric key, KDC DH ID]Signed with User PrivateKey 
-                                                        -> KDC
-
-   The KDC DH ID is copied by the client from the KDC_ERROR message
-   received above. Upon receipt and validation of this message, the
-   KDC first uses the KDC DH ID as an index to locate its
-   private Diffie Hellman parameter; it uses this parameter in 
-   combination with the user public Diffie Hellman parameter
-   to compute the symmetric Diffie Hellman key. The KDC checks
-   if the encrypted nonce is the same as the one in the 
-   PKAuthenticator and the AS_REQ part. The KDC then enters
-   the new user DES key into the database, resets the recovery 
-   needed bit, and sets the valid symmetric key in database
-   bit. The KDC then creates the AS_REP message:
-
-   Client <-- AS_REP with preauth: kdcCert, {encReplyKey,
-              nonce}DH symmetric key <-------------------- KDC
-
-   
-   The AS_REP encrypted part is encrypted with the encReplyKey
-   that is generated on the KDC. The nonces are copied from the
-   client AS_REQ. The kdcCert is a sequence of certificates
-   that have been certified by certifiers listed in the client
-   rootCert field, unless a zero length rootCert field was sent.
-   In the last case, the kdcCert will also have zero length.   
-
-3.2.2. Private key held by KDC
-
-   Implementation of the changes in this section is RECOMMENDED.
-
-   When the user's private key is not carried with the user, the 
-   user may encrypt the private key using conventional cryptography, 
-   and register the encrypted private key with the KDC.  As
-   described in the previous section, the SHA1 hash of the password
-   concatenated with the kdcSalt is also stored in the KDC database
-   if the user only uses new clients. We restrict users of this
-   protocol to using new clients only. The reason for this restriction
-   is that it is not secure to store both the user private key 
-   encrypted in the user's password and the user password on the KDC 
-   simultaneously.
-
-   There are several options for storing private keys. If the 
-   user stores their private key on a removable disk, it is 
-   less convenient since they need to always carry the disk 
-   around with them; in addition, the procedures for extracting 
-   the key may vary between different operating systems. 
-   Alternatively, the user can store a private key on the hard
-   disks of systems that he/she uses; besides limiting the 
-   systems that the user can login from there is also a 
-   greater security risk to the private key. If smart card 
-   readers or slots are deployed in an organization, then the 
-   user can store his/her private key on a smart card. Finally, 
-   the user can store his/her private key encrypted in a password 
-   on the KDC. This last option is probably the most practical
-   option currently; it is important that a good password policy 
-   be used.
-
-   When the user's private key is stored on the KDC, 
-   preauthentication is required. There are two cases depending on 
-   whether the requesting user principal needs to be recovered. 
-
-   In order to obtain its private key, a user principal includes the
-   padata type PA-PK-AS-REQ in the preauthentication data
-   field of the AS_REQ message. The accompanying pa-data field is:
-
-   PA-PK-AS-REQ ::= SEQUENCE {
-           algorithmId[0]       INTEGER,      -- Public Key Alg.
-           encClientPubVal[1]   EncryptedData -- EncPaPkAsReqDH
-                                              -- (encrypted with key
-                                              -- K1)
-   }
-
-   EncPaPkAsReqDH ::= SEQUENCE {
-           clientPubValue[0]    SubjectPublicKeyInfo 
-   }
-
-   Pictorially, PA-PK-AS-REQ is algorithmID, {clientPubValue}K1.
-
-   The user principal sends its Diffie-Hellman public value encrypted
-   in the key K1. The key K1 is derived by performing string to key on
-   the SHA1 hash of the user password concatenated with the kdcSalt 
-   which is stored in the /krb5/salt file. If the file is absent, 
-   the concatenation step is skipped in the above algorithm. The 
-   Diffie Hellman parameters g and p are implied by the algorithmID
-   field. By choosing g and p correctly, dictionary attacks against
-   the key K1 can be made more difficult [Jaspan].
-
-   If the requesting user principal needs recovery, the encrypted 
-   user private key is stored in the KDC database, and the AS_REQ 
-   RecoveryData field is not present in the PKAuthenticator, then 
-   the KDC replies with a KRB_ERROR message, with msg-type set to 
-   KDC_ERR_PREAUTH_REQUIRED, and e-data set to:
-
-   PA-PK-AS-INFO ::= SEQUENCE {
-           signedDHErr         SignedDHError,         -- signed by KDC
-           encUserKey          OCTET STRING OPTIONAL  -- encrypted by
-                                                      -- user password 
-                                                      -- key; (recovery
-                                                      -- response)
-
-   }
-
-   The user principal should then continue with the section 3.2.1.1
-   protocol using the Diffie Hellman algorithm. 
-
-   We now assume that the requesting user principal does not need
-   recovery. 
-
-   Upon receipt of the authentication request with the PA-PK-AS-REQ, 
-   the KDC generates the AS response as defined in RFC 1510, but 
-   additionally includes a preauthentication field of type 
-   PA-PK-USER-KEY. 
-
-   PA-PK-USER-KEY ::= SEQUENCE {
-           kdcCert            SEQUENCE OF Certificate,
-           encUserKeyPart     EncryptedData, -- EncPaPkUserKeyPart           
-           kdcPrivKey         KDCPrivKey,
-           kdcPrivKeySig      Signature
-   }
-
-   The kdc-cert field is identical to that in the PA-PK-AS-REP
-   preauthentication data field returned with the KDC response, and 
-   must be validated as belonging to the KDC in the same manner.
-
-   KDCPrivKey ::= SEQUENCE {
-           nonce	      INTEGER,		     -- From AS_REQ
-           algorithmId        INTEGER,               -- DH algorithm
-           kdcPubValue        SubjectPublicKeyInfo,  -- DH algorithm
-	   kdcSalt            OCTET STRING           -- Since user
-                                                     -- uses only new
-                                                     -- clients
-   }
-
-   The KDCPrivKey field is signed using the KDC private key.
-   The encrypted part of the AS_REP message is encrypted using the 
-   Diffie Hellman derived symmetric key, as is the EncPaPkUserKeyPart.
-
-   EncPaPkUserKeyPart ::= SEQUENCE {
-           encUserKey         OCTET STRING,
-           nonce              INTEGER                -- From AS_REQ
-   }
-
-   Notationally, if encryption algorithm A is used, then enc-key-part
-   is
-
-       A ({encUserKey, nonce}, Diffie-Hellman-symmetric-key).
-
-   If the client has used an incorrect kdcSalt to compute the
-   key K1, then the client needs to resubmit the above AS_REQ
-   message using the correct kdcSalt field from the KDCPrivKey
-   field. 
-
-   This message contains the encrypted private key that has been
-   registered with the KDC by the user, as encrypted by the user,
-   super-encrypted with the Diffie Hellman derived symmetric key.
-   Because there is direct trust between the user and the KDC, the 
-   transited field of the ticket returned by the KDC should remain 
-   empty.  (Cf. Section 3.3.)
-
-   Examples
-
-   We now give several examples illustrating the protocols in this 
-   section.
-
-   Example 1: The requesting user principal needs to be recovered
-   and stores his/her encrypted private key on the KDC. Then the 
-   exchange sequence between the user principal and the KDC is:
-
-   Client  --------> AS_REQ (with or without preauth) -----> KDC
-
-   Client  <--- KRB_ERROR (error code KDC_ERR_PREAUTH_REQUIRED)
-                error data: [nonce, algID (DH), KDC DH public 
-                            parameter, KDC DH ID, KDC PublicKey 
-                            Kvno and PublicKey, KDC Salt]Signed 
-                            with KDC PrivateKey, {user private 
-                            key}user password <------------- KDC
-
-   The protocol now continues with the second AS_REQ as in Example
-   1 of section 3.2.1.1.
-   
-   Example 2: The requesting user principal does not need to be 
-   recovered and stores his/her encrypted private key on the KDC. 
-   Then the exchange sequence between the user principal and the KDC 
-   when the user principal wants to obtain his/her private key is:
-
-   Client  -> AS_REQ with preauth: algID, 
-              {DH public parameter}K1 -> KDC
-
-   The key K1 is generated by using the string to key function 
-   on the SHA1 hash of the password concatenated with the kdcSalt
-   from the /krb5/salt file. If the file is absent, then 
-   the concatenation step is skipped, and the client will learn 
-   the correct kdcSalt in the following AS_REP message from the
-   KDC. The algID should indicate some type of Diffie Hellman
-   algorithm.
-
-   The KDC replies with the AS_REP message with a preauthentication
-   data field:
-
-   Client <-- AS_REP with preauth: kdcCert, {encUserKey, <-- KDC
-              nonce}DH symmetric key, [nonce, algID, DH
-              public parameter, kdcSalt]KDC privateKey
-
-   The client validates the KDC's signature and checks that
-   the nonce matches the nonce in its AS_REQ message.
-   If the kdcSalt does not match what the client used, it
-   starts the protocol over. The client then uses the KDC
-   Diffie Hellman public parameter along with its own Diffie
-   Hellman private parameter to compute the Diffie Hellman 
-   symmetric key. This key is used to decrypt the encUserKey
-   field; the client checks if the nonce matches its AS_REQ
-   nonce. At this point, the initial authentication protocol
-   is complete.  
-
-   Example 3: The requesting user principal does not need to be 
-   recovered and stores his/her encrypted private key on the KDC.
-   In this example, the user principal uses the conventional
-   symmetric key Kerberos V5 initial authentication protocol
-   exchange. 
-
-   We note that the conventional protocol exposes the user 
-   password to dictionary attacks; therefore, the user password 
-   must be changed more often. An example of when this protocol 
-   would be used is when new clients have been installed but an 
-   organization has not phased in public key authentication for 
-   all clients due to performance concerns.
-
-   Client ----> AS_REQ with preauthentication: {time}K1 --> KDC
-
-   Client <--------------------  AS_REP <------------------ KDC
-
-   The key K1 is derived as in the preceding two examples. 
-
-
-3.3. Clients with a public key certified by an outside authority
-
-   Implementation of the changes in this section is OPTIONAL.
-
-   In the case where the client is not registered with the current
-   KDC, the client is responsible for obtaining the private key on
-   its own. The client will request initial tickets from the KDC
-   using the TGS exchange, but instead of performing
-   preauthentication using a Kerberos ticket granting ticket, or
-   with the PA-PK-AS-REQ that is used when the public key is known
-   to the KDC, the client performs preauthentication using the
-   preauthentication data field of type PA-PK-AS-EXT-CERT:
-
-   PA-PK-AS-EXT-CERT ::= SEQUENCE {
-           userCert[0]         SEQUENCE OF OCTET STRING,
-           signedAuth[1]       SignedPKAuthenticator
-   }
-
-   where the user-cert specification depends on the type of
-   certificate that the user possesses.  In cases where the service
-   has separate key pairs for digital signature and for encryption,
-   we recommend that the signature keys be used for the purposes of
-   sending the preauthentication (and deciphering the response).
-
-   The authenticator is the one used from the exchange in section
-   3.2.1, except that it is signed using the private key corresponding
-   to the public key in the user-cert.
-
-   The KDC will verify the preauthentication authenticator, and check the
-   certification path against its own policy of legitimate certifiers.
-   This may be based on a certification hierarchy, or simply a list of
-   recognized certifiers in a system like PGP.
-
-   If all checks out, the KDC will issue Kerberos credentials, as in 3.2,
-   but with the names of all the certifiers in the certification path
-   added to the transited field of the ticket, with a principal name
-   taken from the certificate (this might be a long path for X.509, or a
-   string like "John Q. Public <jqpublic@company.com>" if the certificate
-   was a PGP certificate.  The realm will identify the kind of
-   certificate and the final certifier as follows:
-
-       cert_type/final_certifier
-
-   as in PGP/<endorser@company.com>.
-
-
-3.4. Digital Signature
-
-   Implementation of the changes in this section is OPTIONAL.
-
-   We offer this option with the warning that it requires the client
-   process to generate a random DES key; this generation may not
-   be able to guarantee the same level of randomness as the KDC.
-
-   If a user registered a digital signature key pair with the KDC,
-   a separate exchange may be used.  The client sends a KRB_AS_REQ 
-   as described in section 3.2.2.  If the user's database record
-   indicates that a digital signature key is to be used, then the
-   KDC sends back a KRB_ERROR as in section 3.2.2.
-
-   It is assumed here that the signature key is stored on local disk.
-   The client generates a random key of enctype ENCTYPE_DES_CBC_CRC,
-   signs it using the signature key (otherwise the signature is
-   performed as described in section 3.2.1), then encrypts the whole
-   with the public key of the KDC.  This is returned with a separate
-   KRB_AS_REQ in a preauthentication of type
-
-   PA-PK-AS-SIGNED ::= SEQUENCE {
-           signedKey[0]        EncryptedData -- PaPkAsSignedData
-   }
-
-   PaPkAsSignedData ::= SEQUENCE {
-           signedKeyPart[0]    SignedKeyPart,
-           signedKeyAuth[1]    PKAuthenticator,
-           sig[2]              Signature
-   }
-
-   SignedKeyPart ::= SEQUENCE {
-           encSignedKey[0]     EncryptionKey,
-           nonce[1]            INTEGER
-   }
-
-   where the nonce is the one from the request.  Upon receipt of the
-   request, the KDC decrypts, then verifies the random key.  It then
-   replies as per RFC 1510, except that instead of being encrypted
-   with the password-derived DES key, the reply is encrypted using
-   the randomKey sent by the client.  Since the client already knows
-   this key, there is no need to accompany the reply with an extra
-   preauthentication field.  Because there is direct trust between
-   the user and the KDC, the transited field of the ticket returned
-   by the KDC should remain empty.  (Cf. Section 3.3.)
-
-   In the event that the KDC database indicates that the user 
-   principal must be recovered, and the PKAuthenticator does not 
-   contain the RecoveryData field, the KDC will reply with the
-   KDC_RECOVERY_NEEDED error. The user principal then sends
-   another AS_REQ message that includes the RecoveryData field
-   in the PKAuthenticator. The AS_REP message is the same as
-   in the basic Kerberos V5 protocol. 
-
-
-4. Preauthentication Data Types
-
-   We propose that the following preauthentication types be allocated
-   for the preauthentication data packages described in this draft:
-
-       #define KRB5_PADATA_ROOT_CERT     17  /* PA-PK-AS-ROOT */
-       #define KRB5_PADATA_PUBLIC_REP    18  /* PA-PK-AS-REP */
-       #define KRB5_PADATA_PUBLIC_REQ    19  /* PA-PK-AS-REQ */
-       #define KRB5_PADATA_PRIVATE_REP   20  /* PA-PK-USER-KEY */
-       #define KRB5_PADATA_PUBLIC_EXT    21  /* PA-PK-AS-EXT-CERT */
-       #define KRB5_PADATA_PUBLIC_SIGN   22  /* PA-PK-AS-SIGNED */
-
-
-5. Encryption Information
-
-   For the public key cryptography used in direct registration, we
-   used (in our implementation) the RSAREF library supplied with the
-   PGP 2.6.2 release.  Encryption and decryption functions were
-   implemented directly on top of the primitives made available
-   therein, rather than the fully sealing operations in the API.
-
-
-6. Compatibility with One-Time Passcodes
-
-   We solicit discussion on how the use of public key cryptography
-   for initial authentication will interact with the proposed use of
-   one time passwords discussed in Internet Draft
-   <draft-ietf-cat-kerberos-passwords-00.txt>.
-
-7. Strength of Encryption and Signature Mechanisms
-
-   In light of recent findings on the strengths of MD5 and various DES
-   modes, we solicit discussion on which modes to incorporate into the
-   protocol changes.
-
-
-8. Expiration
-
-   This Internet-Draft expires on April 19, 1997.
-
-
-9. Authors' Addresses
-
-   B. Clifford Neuman
-   USC/Information Sciences Institute
-   4676 Admiralty Way Suite 1001
-   Marina del Rey, CA 90292-6695
-
-   Phone: 310-822-1511
-   EMail: bcn@isi.edu
-
-   Brian Tung
-   USC/Information Sciences Institute
-   4676 Admiralty Way Suite 1001
-   Marina del Rey, CA 90292-6695
-
-   Phone: 310-822-1511
-   EMail: brian@isi.edu
-
-   John Wray
-   Digital Equipment Corporation
-   550 King Street, LKG2-2/Z7
-   Littleton, MA 01460
-
-   Phone: 508-486-5210
-   EMail: wray@tuxedo.enet.dec.com
-
-   Jonathan Trostle
-   CyberSafe Corporation
-   1605 NW Sammamish Rd., Suite 310
-   Issaquah, WA 98027-5378
-
-   Phone: 206-391-6000
-   EMail: jonathan.trostle@cybersafe.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt
deleted file mode 100644
index c59aa3c0e..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-03.txt
+++ /dev/null
@@ -1,588 +0,0 @@
-INTERNET-DRAFT                                         Clifford Neuman
-draft-ietf-cat-kerberos-pk-init-03.txt                      Brian Tung
-Updates: RFC 1510                                                  ISI
-expires September 30, 1997                                   John Wray
-                                         Digital Equipment Corporation
-                                                         Ari Medvinsky
-                                                           Matthew Hur
-                                                 CyberSafe Corporation
-                                                      Jonathan Trostle
-                                                                Novell
-
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-
-0.  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 learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ds.internic.net (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-03.txt, and expires September 30,
-    1997.  Please send comments to the authors.
-
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510 [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to to associate a key pair with each realm, which
-    can then be used to facilitate cross-realm authentication; this is
-    the topic of another draft proposal.  Another way is to allow users
-    with public key certificates to use them in initial authentication.
-    This is the concern of the current document.
-
-    One of the guiding principles in the design of PKINIT is that
-    changes should be as minimal as possible.  As a result, the basic
-    mechanism of PKINIT is as follows:  The user sends a request to the
-    KDC as before, except that if that user is to use public key
-    cryptography in the initial authentication step, his certificate
-    accompanies the initial request, in the preauthentication fields.
-
-    Upon receipt of this request, the KDC verifies the certificate and
-    issues a ticket granting ticket (TGT) as before, except that instead
-    of being encrypted in the user's long-term key (which is derived
-    from a password), it is encrypted in a randomly-generated key.  This
-    random key is in turn encrypted using the public key certificate
-    that came with the request and signed using the KDC's signature key,
-    and accompanies the reply, in the preauthentication fields.
-
-    PKINIT also allows for users with only digital signature keys to
-    authenticate using those keys, and for users to store and retrieve
-    private keys on the KDC.
-
-    The PKINIT specification may also be used for direct peer to peer
-    authentication without contacting a central KDC. This application
-    of PKINIT is described in PKTAPP [4] and is based on concepts
-    introduced in [5, 6]. For direct client-to-server authentication,
-    the client uses PKINIT to authenticate to the end server (instead
-    of a central KDC), which then issues a ticket for itself.  This
-    approach has an advantage over SSL [7] in that the server does not
-    need to save state (cache session keys).  Furthermore, an
-    additional benefit is that Kerberos tickets can facilitate
-    delegation (see [8]).
-
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510 for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following changes to RFC 1510 are proposed:
-
-        --> Users may authenticate using either a public key pair or a
-            conventional (symmetric) key.  If public key cryptography is
-            used, public key data is transported in preauthentication
-            data fields to help establish identity.
-        --> Users may store private keys on the KDC for retrieval during
-            Kerberos initial authentication.
-
-    This proposal addresses two ways that users may use public key
-    cryptography for initial authentication.  Users may present public
-    key certificates, or they may generate their own session key,
-    signed by their digital signature key.  In either case, the end
-    result is that the user obtains an ordinary TGT that may be used for
-    subsequent authentication, with such authentication using only
-    conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 and 3.3 describe the extensions for the two initial
-    authentication methods.  Section 3.3 describes a way for the user to
-    store and retrieve his private key on the KDC.
-
-
-3.1.  Definitions
-
-    Hash and encryption types will be specified using ENCTYPE tags; we
-    propose the addition of the following types:
-
-        #define ENCTYPE_SIGN_DSA_GENERATE   0x0011
-        #define ENCTYPE_SIGN_DSA_VERIFY     0x0012
-        #define ENCTYPE_ENCRYPT_RSA_PRIV    0x0021
-        #define ENCTYPE_ENCRYPT_RSA_PUB     0x0022
-
-    allowing further signature types to be defined in the range 0x0011
-    through 0x001f, and further encryption types to be defined in the
-    range 0x0021 through 0x002f.
-
-    The extensions involve new preauthentication fields.  The
-    preauthentication data types are in the range 17 through 21.
-    These values are also specified along with their corresponding
-    ASN.1 definition.
-
-        #define PA-PK-AS-REQ                17
-        #define PA-PK-AS-REP                18
-        #define PA-PK-AS-SIGN               19
-        #define PA-PK-KEY-REQ               20
-        #define PA-PK-KEY-REP               21
-
-    The extensions also involve new error types.  The new error types
-    are in the range 227 through 229.  They are:
-
-        #define KDC_ERROR_CLIENT_NOT_TRUSTED    227
-        #define KDC_ERROR_KDC_NOT_TRUSTED       228
-        #define KDC_ERROR_INVALID_SIG           229
-
-    In the exposition below, we use the following terms: encryption key,
-    decryption key, signature key, verification key.  It should be
-    understood that encryption and verification keys are essentially
-    public keys, and decryption and signature keys are essentially
-    private keys.  The fact that they are logically distinct does
-    not preclude the assignment of bitwise identical keys.
-
-
-3.2.  Standard Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with pk-init.
-
-    It is assumed that all public keys are signed by some certification
-    authority (CA).  The initial authentication request is sent as per
-    RFC 1510, except that a preauthentication field containing data
-    signed by the user's signature key accompanies the request:
-
-    PA-PK-AS-REQ ::- SEQUENCE {
-                                -- PA TYPE 17
-        signedPKAuth            [0] SignedPKAuthenticator,
-        userCert                [1] SEQUENCE OF Certificate OPTIONAL,
-                                    -- the user's certificate
-                                    -- optionally followed by that
-                                    -- certificate's certifier chain
-        trustedCertifiers       [2] SEQUENCE OF PrincipalName OPTIONAL
-                                    -- CAs that the client trusts
-    }
-
-    SignedPKAuthenticator ::= SEQUENCE {
-        pkAuth                  [0] PKAuthenticator,
-        pkAuthSig               [1] Signature,
-                                    -- of pkAuth
-                                    -- using user's signature key
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER,
-                                    -- for replay prevention
-        ctime                   [1] KerberosTime,
-                                    -- for replay prevention
-        nonce                   [2] INTEGER,
-                                    -- binds response to this request
-        kdcName                 [3] PrincipalName,
-        clientPubValue          [4] SubjectPublicKeyInfo OPTIONAL,
-                                    -- for Diffie-Hellman algorithm
-    }
-
-    Signature ::= SEQUENCE {
-        signedHash              [0] EncryptedData
-                                    -- of type Checksum
-                                    -- encrypted under signature key
-    }
-
-    Checksum ::=   SEQUENCE {
-        cksumtype               [0] INTEGER,
-        checksum                [1] OCTET STRING
-    }   -- as specified by RFC 1510
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm               [0] algorithmIdentifier,
-        subjectPublicKey        [1] BIT STRING
-    }   -- as specified by the X.509 recommendation [9]
-
-    Certificate ::= SEQUENCE {
-        CertType                [0] INTEGER,
-                                    -- type of certificate
-                                    -- 1 = X.509v3 (DER encoding)
-                                    -- 2 = PGP (per PGP draft)
-        CertData                [1] OCTET STRING
-                                    -- actual certificate
-                                    -- type determined by CertType
-    }
-
-    Note: If the signature uses RSA keys, then it is to be performed
-    as per PKCS #1.
-
-    The PKAuthenticator carries information to foil replay attacks,
-    to bind the request and response, and to optionally pass the
-    client's Diffie-Hellman public value (i.e. for using DSA in
-    combination with Diffie-Hellman).  The PKAuthenticator is signed
-    with the private key corresponding to the public key in the
-    certificate found in userCert (or cached by the KDC).
-
-    In the PKAuthenticator, the client may specify the KDC name in one
-    of two ways: 1) a Kerberos principal name, or 2) the name in the
-    KDC's certificate (e.g., an X.500 name, or a PGP name).  Note that
-    case #1 requires that the certificate name and the Kerberos principal
-    name be bound together (e.g., via an X.509v3 extension).
-
-    The userCert field is a sequence of certificates, the first of which
-    must be the user's public key certificate. Any subsequent
-    certificates will be certificates of the certifiers of the user's
-    certificate.  These cerificates may be used by the KDC to verify the
-    user's public key.  This field is empty if the KDC already has the
-    user's certifcate.
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.  This may be based on a certification
-    hierarchy, or it may be simply a list of recognized certifiers in a
-    system like PGP.  If the certification path does not match one of
-    the KDC's trusted certifiers, the KDC sends back an error message of
-    type KDC_ERROR_CLIENT_NOT_TRUSTED, and it includes in the error data
-    field a list of its own trusted certifiers, upon which the client
-    resends the request.
-
-    If  trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
-    verifies that it has a certificate issued by one of the certifiers
-    trusted by the client.  If it does not have a suitable certificate,
-    the KDC returns an error message of type KDC_ERROR_KDC_NOT_TRUSTED
-    to the client. 
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on PKAuthenticator.  If that fails, the KDC returns an
-    error message of type KDC_ERROR_INVALID_SIG.  Otherwise, the KDC
-    uses the timestamp in the PKAuthenticator to assure that the request
-    is not a replay.   The KDC also verifies that its name is specified
-    in PKAuthenticator.
-
-    Assuming no errors, the KDC replies as per RFC 1510, except that it
-    encrypts the reply not with the user's key, but with a random key
-    generated only for this particular response.  This random key
-    is sealed in the preauthentication field:
-
-    PA-PK-AS-REP ::= SEQUENCE {
-                               -- PA TYPE 18
-        kdcCert                 [0] SEQUENCE OF Certificate OPTIONAL,
-                                    -- the KDC's certificate
-                                    -- optionally followed by that
-                                    -- certificate's certifier chain
-        encPaReply              [1] EncryptedData,
-                                    -- of type PaReply
-                                    -- using either the client public
-                                    -- key or the Diffie-Hellman key
-                                    -- specified by SignedDHPublicValue
-        signedDHPublicValue     [2] SignedDHPublicValue OPTIONAL
-    }
-
-
-    PaReply ::= SEQUENCE {
-        replyEncKeyPack         [0] ReplyEncKeyPack,
-        replyEncKeyPackSig      [1] Signature,
-                                    -- of replyEncKeyPack
-                                    -- using KDC's signature key
-    }
-
-    ReplyEncKeyPack ::= SEQUENCE {
-        replyEncKey             [0] EncryptionKey,
-                                    -- used to encrypt main reply
-        nonce                   [1] INTEGER
-                                    -- binds response to the request
-                                    -- passed in the PKAuthenticator
-    }
-
-    SignedDHPublicValue ::= SEQUENCE {
-        dhPublicValue           [0] SubjectPublicKeyInfo,
-        dhPublicValueSig        [1] Signature
-                                    -- of dhPublicValue
-                                    -- using KDC's signature key
-    }
-
-    The kdcCert field is a sequence of certificates, the first of which
-    must have as its root certifier one of the certifiers sent to the
-    KDC in the PA-PK-AS-REQ. Any subsequent certificates will be 
-    certificates of the certifiers of the KDC's certificate.  These
-    cerificates may be used by the client to verify the KDC's public
-    key.  This field is empty if the client did not send to the KDC a
-    list of trusted certifiers (the trustedCertifiers field was empty).
-    
-    Since each certifier in the certification path of a user's
-    certificate is essentially a separate realm, the name of each
-    certifier shall be added to the transited field of the ticket.  The
-    format of these realm names shall follow the naming constraints set
-    forth in RFC 1510 (sections 7.1 and 3.3.3.1).  Note that this will
-    require new nametypes to be defined for PGP certifiers and other
-    types of realms as they arise.
-
-    The KDC's certificate must bind the public key to a name derivable
-    from the name of the realm for that KDC.  The client then extracts
-    the random key used to encrypt the main reply.  This random key (in
-    encPaReply) is encrypted with either the client's public key or
-    with a key derived from the DH values exchanged between the client
-    and the KDC.
-
-
-3.3.  Digital Signature
-
-    Implementation of the changes in this section are OPTIONAL for
-    compliance with pk-init.
-
-    We offer this option with the warning that it requires the client to
-    generate a random key; the client may not be able to guarantee the
-    same level of randomness as the KDC.
-
-    If the user registered a digital signature key with the KDC instead
-    of an encryption key, then a separate exchange must be used.  The
-    client sends a request for a TGT as usual, except that it (rather
-    than the KDC) generates the random key that will be used to encrypt
-    the KDC response.  This key is sent to the KDC along with the
-    request in a preauthentication field:
-
-    PA-PK-AS-SIGN ::= SEQUENCE {
-                                -- PA TYPE 19
-        encSignedKeyPack        [0] EncryptedData
-                                    -- of SignedKeyPack
-                                    -- using the KDC's public key
-    }
-
-    SignedKeyPack ::= SEQUENCE {
-        signedKey               [0] KeyPack,
-        signedKeyAuth           [1] PKAuthenticator,
-        signedKeySig            [2] Signature
-                                    -- of signedKey.signedKeyAuth
-                                    -- using user's signature key
-    }
-
-    KeyPack ::= SEQUENCE {
-        randomKey               [0] EncryptionKey,
-                                    -- will be used to encrypt reply
-        nonce                   [1] INTEGER
-    }
-
-    where the nonce is copied from the request.
-
-    Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
-    the randomKey.  It then replies as per RFC 1510, except that the
-    reply is encrypted not with a password-derived user key, but with
-    the randomKey sent in the request.  Since the client already knows
-    this key, there is no need to accompany the reply with an extra
-    preauthentication field.  The transited field of the ticket should
-    specify the certification path as described in Section 3.2.
-
-
-3.4.  Retrieving the Private Key From the KDC
-
-    Implementation of the changes in this section is RECOMMENDED for
-    compliance with pk-init.
-
-    When the user's private key is not stored local to the user, he may
-    choose to store the private key (normally encrypted using a
-    password-derived key) on the KDC.  We provide this option to present
-    the user with an alternative to storing the private key on local
-    disk at each machine where he expects to authenticate himself using
-    pk-init.  It should be noted that it replaces the added risk of
-    long-term storage of the private key on possibly many workstations
-    with the added risk of storing the private key on the KDC in a
-    form vulnerable to brute-force attack.
-
-    In order to obtain a private key, the client includes a
-    preauthentication field with the AS-REQ message:
-
-    PA-PK-KEY-REQ ::= SEQUENCE {
-                                -- PA TYPE 20
-        patimestamp             [0] KerberosTime OPTIONAL, 
-                                    -- used to address replay attacks.
-        pausec                  [1] INTEGER OPTIONAL,
-                                    -- used to address replay attacks.
-        nonce                   [2] INTEGER,
-                                    -- binds the reply to this request
-        privkeyID               [3] SEQUENCE OF KeyID OPTIONAL
-                                    -- constructed as a hash of
-                                    -- public key corresponding to
-                                    -- desired private key
-    }
-
-    KeyID ::= SEQUENCE {
-        KeyIdentifier           [0] OCTET STRING
-    }
-
-    The client may request a specific private key by sending the
-    corresponding ID.  If this field is left empty, then all
-    private keys are returned.
-
-    If all checks out, the KDC responds as described in the above
-    sections, except that an additional preauthentication field,
-    containing the user's private key, accompanies the reply:
-
-    PA-PK-KEY-REP ::= SEQUENCE {
-                                -- PA TYPE 21
-        nonce                   [0] INTEGER,
-                                    -- binds the reply to the request
-        KeyData                 [1] SEQUENCE OF KeyPair
-    }
-
-    KeyPair ::= SEQUENCE {
-        privKeyID               [0] OCTET STRING,
-                                    -- corresponding to encPrivKey
-        encPrivKey              [1] OCTET STRING
-    }
-
-
-3.4.1.  Additional Protection of Retrieved Private Keys
-
-    We solicit discussion on the following proposal: that the client may
-    optionally include in its request additional data to encrypt the
-    private key, which is currently only protected by the user's
-    password.  One possibility is that the client might generate a
-    random string of bits, encrypt it with the public key of the KDC (as
-    in the SignedKeyPack, but with an ordinary OCTET STRING in place of
-    an EncryptionKey), and include this with the request.  The KDC then
-    XORs each returned key with this random bit string.  (If the bit
-    string is too short, the KDC could either return an error, or XOR
-    the returned key with a repetition of the bit string.)
-
-    In order to make this work, additional means of preauthentication
-    need to be devised in order to prevent attackers from simply
-    inserting their own bit string.  One way to do this is to store
-    a hash of the password-derived key (the one used to encrypt the
-    private key).  This hash is then used in turn to derive a second
-    key (called the hash-key); the hash-key is used to encrypt an ASN.1
-    structure containing the generated bit string and a nonce value
-    that binds it to the request.
-
-    Since the KDC possesses the hash, it can generate the hash-key and
-    verify this (weaker) preauthentication, and yet cannot reproduce
-    the private key itself, since the hash is a one-way function.
-
-
-4.  Logistics and Policy Issues
-
-    We solicit discussion on how clients and KDCs should be configured
-    in order to determine which of the options described above (if any)
-    should be used.  One possibility is to set the user's database
-    record to indicate that authentication is to use public key
-    cryptography; this will not work, however, in the event that the
-    client needs to know before making the initial request.
-
-5.  Compatibility with One-Time Passcodes
-
-    We solicit discussion on how the protocol changes proposed in this
-    draft will interact with the proposed use of one-time passcodes
-    discussed in draft-ietf-cat-kerberos-passwords-00.txt.
-
-
-6.  Strength of Cryptographic Schemes
-
-    In light of recent findings on the strength of MD5 and DES,
-    we solicit discussion on which encryption types to incorporate
-    into the protocol changes.
-
-
-7.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication
-    Service (V5).  Request for Comments: 1510
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.
-    September 1994.
-
-    [3] A. Medvinsky, M. Hur.  Addition of Kerberos Cipher Suites to
-    Transport Layer Security (TLS).
-    draft-ietf-tls-kerb-cipher-suites-00.txt
-
-    [4] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
-    Tickets for Application Servers (PKTAPP).
-    draft-ietf-cat-pktapp-00.txt
-
-    [5] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos Using 
-    Public Key Cryptography.  Symposium On Network and Distributed System 
-    Security, 1997.
-
-    [6] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction 
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic Commerce,
-    July 1995.
-
-    [7] Alan O. Freier, Philip Karlton and Paul C. Kocher.
-    The SSL Protocol, Version 3.0 - IETF Draft. 
-
-    [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 
-    Distributed Systems.  In Proceedings of the 13th International 
-    Conference on Distributed Computing Systems, May 1993
-
-    [9] ITU-T (formerly CCITT)
-    Information technology - Open Systems Interconnection -
-    The Directory: Authentication Framework Recommendation X.509
-    ISO/IEC 9594-8
-
-
-8.  Acknowledgements
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-
-9.  Expiration Date
-
-    This draft expires September 30, 1997.
-
-
-10.  Authors
-
-    Clifford Neuman
-    Brian Tung
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {bcn, brian}@isi.edu
-
-    John Wray
-    Digital Equipment Corporation
-    550 King Street, LKG2-2/Z7
-    Littleton, MA 01460
-    Phone: +1 508 486 5210
-    E-mail: wray@tuxedo.enet.dec.com
-
-    Ari Medvinsky
-    Matthew Hur
-    CyberSafe Corporation
-    1605 NW Sammamish Road Suite 310
-    Issaquah WA 98027-5378
-    Phone: +1 206 391 6000
-    E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
-
-    Jonathan Trostle
-    Novell
-    E-mail: jonathan.trostle@novell.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-04.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-04.txt
deleted file mode 100644
index f26cc722d..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-04.txt
+++ /dev/null
@@ -1,868 +0,0 @@
-INTERNET-DRAFT                                              Brian Tung
-draft-ietf-cat-kerberos-pk-init-04.txt                 Clifford Neuman
-Updates: RFC 1510                                                  ISI
-expires January 31, 1998                                     John Wray
-                                         Digital Equipment Corporation
-                                                         Ari Medvinsky
-                                                           Matthew Hur
-                                                 CyberSafe Corporation
-                                                      Jonathan Trostle
-                                                                Novell
-
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-
-0.  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 learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ds.internic.net (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-04.txt, and expires January 31,
-    1998.  Please send comments to the authors.
-
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510 [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to associate a key pair with each realm, which can
-    then be used to facilitate cross-realm authentication; this is the
-    topic of another draft proposal.  Another way is to allow users with
-    public key certificates to use them in initial authentication.  This
-    is the concern of the current document.
-
-    One of the guiding principles in the design of PKINIT is that
-    changes should be as minimal as possible.  As a result, the basic
-    mechanism of PKINIT is as follows:  The user sends a request to the
-    KDC as before, except that if that user is to use public key
-    cryptography in the initial authentication step, his certificate
-    accompanies the initial request, in the preauthentication fields.
-
-    Upon receipt of this request, the KDC verifies the certificate and
-    issues a ticket granting ticket (TGT) as before, except that instead
-    of being encrypted in the user's long-term key (which is derived
-    from a password), it is encrypted in a randomly-generated key.  This
-    random key is in turn encrypted using the public key from the
-    certificate that came with the request and signed using the KDC's
-    private key, and accompanies the reply, in the preauthentication
-    fields.
-
-    PKINIT also allows for users with only digital signature keys to
-    authenticate using those keys, and for users to store and retrieve
-    private keys on the KDC.
-
-    The PKINIT specification may also be used for direct peer to peer
-    authentication without contacting a central KDC. This application
-    of PKINIT is described in PKTAPP [4] and is based on concepts
-    introduced in [5, 6]. For direct client-to-server authentication,
-    the client uses PKINIT to authenticate to the end server (instead
-    of a central KDC), which then issues a ticket for itself.  This
-    approach has an advantage over SSL [7] in that the server does not
-    need to save state (cache session keys).  Furthermore, an
-    additional benefit is that Kerberos tickets can facilitate
-    delegation (see [8]).
-
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510 for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following changes to RFC 1510 are proposed:
-
-        --> Users may authenticate using either a public key pair or a
-            conventional (symmetric) key.  If public key cryptography is
-            used, public key data is transported in preauthentication
-            data fields to help establish identity.
-        --> Users may store private keys on the KDC for retrieval during
-            Kerberos initial authentication.
-
-    This proposal addresses two ways that users may use public key
-    cryptography for initial authentication.  Users may present public
-    key certificates, or they may generate their own session key,
-    signed by their digital signature key.  In either case, the end
-    result is that the user obtains an ordinary TGT that may be used for
-    subsequent authentication, with such authentication using only
-    conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 and 3.3 describe the extensions for the two initial
-    authentication methods.  Section 3.4 describes a way for the user to
-    store and retrieve his private key on the KDC, as an adjunct to the
-    initial authentication.
-
-
-3.1.  Definitions
-
-    The extensions involve new encryption methods; we propose the
-    addition of the following types:
-
-        dsa-sign                                8
-        rsa-priv                                9
-        rsa-pub                                 10
-        rsa-pub-md5                             11
-        rsa-pub-sha1                            12
-
-    The proposal of these encryption types notwithstanding, we do not
-    mandate the use of any particular public key encryption method.
-
-    The extensions involve new preauthentication fields; we propose the
-    addition of the following types:
-
-        PA-PK-AS-REQ                            14
-        PA-PK-AS-REP                            15
-        PA-PK-AS-SIGN                           16
-        PA-PK-KEY-REQ                           17
-        PA-PK-KEY-REP                           18
-
-    The extensions also involve new error types; we propose the addition
-    of the following types:
-
-        KDC_ERR_CLIENT_NOT_TRUSTED              62
-        KDC_ERR_KDC_NOT_TRUSTED                 63
-        KDC_ERR_INVALID_SIG                     64
-        KDC_ERR_KEY_TOO_WEAK                    65
-
-    In many cases, PKINIT requires the encoding of an X.500 name as a
-    Realm.  In these cases, the realm will be represented using a
-    different style, specified in RFC 1510 with the following example:
-
-        NAMETYPE:rest/of.name=without-restrictions
-
-    For a realm derived from an X.500 name, NAMETYPE will have the value
-    X500-ASN1-BASE64.  The full realm name will appear as follows:
-
-        X500-ASN1-BASE64:Base64Encode(DistinguishedName)
-
-    where Base64 is an ASCII encoding of binary data as per RFC 1521,
-    and DistinguishedName is the ASN.1 encoding of the X.500
-    Distinguished Name from the X.509 certificate.
-
-    Similarly, PKINIT may require the encoding of an X.500 name as a
-    PrincipalName.  In these cases, the name-type of the principal name
-    shall be set to NT-X500-PRINCIPAL, and the name-string shall be set
-    as follows:
-
-        Base64Encode(DistinguishedName)
-
-    as described above.
-
-    [Similar description needed on how realm names and principal names
-    are to be derived from PGP names.]
-
-
-3.1.1.  Encryption and Key Formats
-
-    In the exposition below, we use the terms public key and private
-    key generically.  It should be understood that the term "public
-    key" may be used to refer to either a public encryption key or a
-    signature verification key, and that the term "private key" may be
-    used to refer to either a private decryption key or a signature
-    generation key.  The fact that these are logically distinct does
-    not preclude the assignment of bitwise identical keys.
-
-    All additional symmetric keys specified in this draft shall use the
-    same encryption type as the session key in the response from the
-    KDC.  These include the temporary keys used to encrypt the signed
-    random key encrypting the response, as well as the key derived from
-    Diffie-Hellman agreement.  In the case of Diffie-Hellman, the key
-    shall be produced from the agreed bit string as follows:
-
-        * Truncate the bit string to the appropriate length.
-        * Rectify parity in each byte (if necessary) to obtain the key.
-
-    For instance, in the case of a DES key, we take the first eight
-    bytes of the bit stream, and then adjust the least significant bit
-    of each byte to ensure that each byte has odd parity.
-
-    RFC 1510, Section 6.1, defines EncryptedData as follows:
-
-        EncryptedData ::= SEQUENCE {
-            etype               [0] INTEGER,
-            kvno                [1] INTEGER OPTIONAL,
-            cipher              [2] OCTET STRING
-                                    -- is CipherText
-        }
-
-    RFC 1510 suggests that ciphertext is coded as follows:
-
-        CipherText ::= ENCRYPTED SEQUENCE {
-            confounder          [0] UNTAGGED OCTET STRING(conf_length)
-                                    OPTIONAL,
-            check               [1] UNTAGGED OCTET STRING(checksum_length)
-                                    OPTIONAL,
-            msg-seq             [2] MsgSequence,
-            pad                 [3] UNTAGGED OCTET STRING(pad_length)
-                                    OPTIONAL
-        }
-
-    The PKINIT protocol introduces several new types of encryption.
-    Data that is encrypted with a public key will allow only the check
-    optional field, as it is defined above. This type of the checksum
-    will be specified in the etype field, together with the encryption
-    type.
-
-    In order to identify the checksum type, etype will have the
-    following values:
-
-                rsa-pub-MD5
-                rsa-pub-SHA1
-
-    In the case that etype is set to rsa-pub, the optional 'check'
-    field will not be provided.
-
-    Data that is encrypted with a private key will not use any optional
-    fields. PKINIT uses private key encryption only for signatures,
-    which are encrypted checksums. Therefore, the optional check field
-    is not needed.
-
-
-3.2.  Standard Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with PKINIT.
-
-    It is assumed that all public keys are signed by some certification
-    authority (CA).  The initial authentication request is sent as per
-    RFC 1510, except that a preauthentication field containing data
-    signed by the user's private key accompanies the request:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                -- PA TYPE 14
-        signedAuthPack          [0] SignedAuthPack
-        userCert                [1] SEQUENCE OF Certificate OPTIONAL,
-                                    -- the user's certificate chain
-        trustedCertifiers       [2] SEQUENCE OF PrincipalName OPTIONAL
-                                    -- CAs that the client trusts
-    }
-
-    SignedAuthPack ::= SEQUENCE {
-        authPack                [0] AuthPack,
-        authPackSig             [1] Signature,
-                                    -- of authPack
-                                    -- using user's private key
-    }
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- if client is using Diffie-Hellman
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        kdcName                 [0] PrincipalName,
-        kdcRealm                [1] Realm,
-        cusec                   [2] INTEGER,
-                                    -- for replay prevention
-        ctime                   [3] KerberosTime,
-                                    -- for replay prevention
-        nonce                   [4] INTEGER
-    }
-
-    Signature ::= SEQUENCE {
-        signedHash              [0] EncryptedData
-                                    -- of type Checksum
-    }
-
-    Checksum ::= SEQUENCE {
-        cksumtype               [0] INTEGER,
-        checksum                [1] OCTET STRING
-    }   -- as specified by RFC 1510
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm               [0] AlgorithmIdentifier,
-        subjectPublicKey        [1] BIT STRING
-                                    -- for DH, equals
-                                    -- public exponent (INTEGER encoded
-                                    -- as payload of BIT STRING)
-    }   -- as specified by the X.509 recommendation [9]
-
-    AlgorithmIdentifier ::= SEQUENCE {
-        algorithm               [0] ALGORITHM.&id,
-                                    -- for DH, equals
-                                    -- dhKeyAgreement
-                                    -- ({iso(1) member-body(2) US(840)
-                                    -- rsadsi(113549) pkcs(1) pkcs-3(3)
-                                    -- 1})
-        parameters              [1] ALGORITHM.&type
-                                    -- for DH, is DHParameter 
-    }   -- as specified by the X.509 recommendation [9]
-
-    DHParameter ::= SEQUENCE {
-        prime                   [0] INTEGER,
-                                    -- p
-        base                    [1] INTEGER,
-                                    -- g
-        privateValueLength      [2] INTEGER OPTIONAL
-    }
-
-    Certificate ::= SEQUENCE {
-        certType                [0] INTEGER,
-                                    -- type of certificate
-                                    -- 1 = X.509v3 (DER encoding)
-                                    -- 2 = PGP (per PGP specification)
-        certData                [1] OCTET STRING
-                                    -- actual certificate
-                                    -- type determined by certType
-    }
-
-    The PKAuthenticator carries information to foil replay attacks,
-    to bind the request and response, and to optionally pass the
-    client's Diffie-Hellman public value (i.e. for using DSA in
-    combination with Diffie-Hellman).  The PKAuthenticator is signed
-    with the private key corresponding to the public key in the
-    certificate found in userCert (or cached by the KDC).
-
-    In the PKAuthenticator, the client may specify the KDC name in one
-    of two ways:
-
-        * The Kerberos principal name krbtgt/<realm_name>@<realm_name>,
-          where <realm_name> is replaced by the applicable realm name.
-        * The name in the KDC's certificate (e.g., an X.500 name, or a
-          PGP name).
-
-    Note that the first case requires that the certificate name and the
-    Kerberos principal name be bound together (e.g., via an X.509v3
-    extension).
-
-    The userCert field is a sequence of certificates, the first of which
-    must be the user's public key certificate. Any subsequent
-    certificates will be certificates of the certifiers of the user's
-    certificate.  These cerificates may be used by the KDC to verify the
-    user's public key.  This field may be left empty if the KDC already
-    has the user's certificate.
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.  This may be based on a certification
-    hierarchy, or it may be simply a list of recognized certifiers in a
-    system like PGP.
-
-    If verification of the user's certificate fails, the KDC sends back
-    an error message of type KDC_ERR_CLIENT_NOT_TRUSTED.  The e-data
-    field contains additional information pertaining to this error, and
-    is formatted as follows:
-
-        METHOD-DATA ::= SEQUENCE {
-            method-type         [0] INTEGER,
-                                    -- 1 = cannot verify public key
-                                    -- 2 = invalid certificate
-                                    -- 3 = revoked certificate
-                                    -- 4 = invalid KDC name
-            method-data         [1] OCTET STRING OPTIONAL
-        } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
-
-    The values for the method-type and method-data fields are described
-    in Section 3.2.1.
-
-    If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
-    verifies that it has a certificate issued by one of the certifiers
-    trusted by the client.  If it does not have a suitable certificate,
-    the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
-    the client. 
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on PKAuthenticator.  If that fails, the KDC returns an
-    error message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses
-    the timestamp in the PKAuthenticator to assure that the request is
-    not a replay.   The KDC also verifies that its name is specified in
-    the PKAuthenticator.
-
-    If the clientPublicValue field is filled in, indicating that the
-    client wishes to use Diffie-Hellman key agreement, then the KDC
-    checks to see that the parameters satisfy its policy.  If they do
-    not (e.g., the prime size is insufficient for the expected
-    encryption type), then the KDC sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
-    private values for the response.
-
-    The KDC also checks that the timestamp in the PKAuthenticator is
-    within the allowable window.  If the local (server) time and the
-    client time in the authenticator differ by more than the allowable
-    clock skew, then the KDC returns an error message of type
-    KRB_AP_ERR_SKEW.
-
-    Assuming no errors, the KDC replies as per RFC 1510, except as
-    follows:  The user's name in the ticket is as represented in the
-    certificate, unless a Kerberos principal name is bound to the name
-    in the certificate (e.g., via an X.509v3 extension).  The user's
-    realm in the ticket shall be the name of the Certification
-    Authority that issued the user's public key certificate.
-
-    The KDC encrypts the reply not with the user's long-term key, but
-    with a random key generated only for this particular response.  This
-    random key is sealed in the preauthentication field:
-
-    PA-PK-AS-REP ::= SEQUENCE {
-                                -- PA TYPE 15
-        encSignedReplyKeyPack   [0] EncryptedData,
-                                    -- of type SignedReplyKeyPack
-                                    -- using the temporary key
-                                    -- in encTmpKey
-        encTmpKeyPack           [1] EncryptedData,
-                                    -- of type TmpKeyPack
-                                    -- using either the client public
-                                    -- key or the Diffie-Hellman key
-                                    -- specified by SignedDHPublicValue
-        signedKDCPublicValue    [2] SignedKDCPublicValue OPTIONAL
-                                    -- if one was passed in the request
-        kdcCert                 [3] SEQUENCE OF Certificate OPTIONAL,
-                                    -- the KDC's certificate chain
-    }
-
-    SignedReplyKeyPack ::= SEQUENCE {
-        replyKeyPack            [0] ReplyKeyPack,
-        replyKeyPackSig         [1] Signature,
-                                    -- of replyEncKeyPack
-                                    -- using KDC's private key
-    }
-
-    ReplyKeyPack ::= SEQUENCE {
-        replyKey                [0] EncryptionKey,
-                                    -- used to encrypt main reply
-        nonce                   [1] INTEGER
-                                    -- binds response to the request
-                                    -- must be same as the nonce
-                                    -- passed in the PKAuthenticator
-    }
-
-    TmpKeyPack ::= SEQUENCE {
-        tmpKey                  [0] EncryptionKey,
-                                    -- used to encrypt the
-                                    -- SignedReplyKeyPack
-    }
-        
-    SignedKDCPublicValue ::= SEQUENCE {
-        kdcPublicValue          [0] SubjectPublicKeyInfo,
-                                    -- as described above
-        kdcPublicValueSig       [1] Signature
-                                    -- of kdcPublicValue
-                                    -- using KDC's private key
-    }
-
-    The kdcCert field is a sequence of certificates, the first of which
-    must be the KDC's public key certificate.  Any subsequent
-    certificates will be certificates of the certifiers of the KDC's
-    certificate.  The last of these must have as its certifier one of
-    the certifiers sent to the KDC in the PA-PK-AS-REQ.  These
-    cerificates may be used by the client to verify the KDC's public
-    key.  This field is empty if the client did not send to the KDC a
-    list of trusted certifiers (the trustedCertifiers field was empty).
-    
-    Since each certifier in the certification path of a user's
-    certificate is essentially a separate realm, the name of each
-    certifier shall be added to the transited field of the ticket.  The
-    format of these realm names is defined in Section 3.1 of this
-    document.  If applicable, the transit-policy-checked flag should be
-    set in the issued ticket.
-
-    The KDC's certificate must bind the public key to a name derivable
-    from the name of the realm for that KDC.  For an X.509 certificate,
-    this is done as follows.  The certificate will contain a
-    distinguished X.500 name contains, in addition to other attributes,
-    an extended attribute, called principalName, with the KDC's
-    principal name as its value (as the text string
-    krbtgt/<realm_name>@<realm_name>, where <realm_name> is the realm
-    name of the KDC):
-
-        principalName ATTRIBUTE ::= {
-            WITH SYNTAX PrintableString(SIZE(1..ub-prinicipalName))
-            EQUALITY MATCHING RULE  caseExactMatch
-            ORDERING MATCHING RULE  caseExactOrderingMatch
-            SINGLE VALUE            TRUE
-            ID                      id-at-principalName
-        }
-
-        ub-principalName INTEGER ::= 1024
-
-        id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4}
-
-        id-at-principalName OBJECT IDENTIFIER ::= {id-at 60}
-
-    where ATTRIBUTE is as defined in X.501, and the matching rules are
-    as defined in X.520.
-
-    [Still need to register principalName.]
-
-    [Still need to discuss what is done for a PGP certificate.]
-
-    The client then extracts the random key used to encrypt the main
-    reply.  This random key (in encPaReply) is encrypted with either the
-    client's public key or with a key derived from the DH values
-    exchanged between the client and the KDC.
-
-
-3.2.1.  Additional Information for Errors
-
-    This section describes the interpretation of the method-type and
-    method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
-
-    If method-type=1, the client's public key certificate chain does not
-    contain a certificate that is signed by a certification authority
-    trusted by the KDC.  The format of the method-data field will be an
-    ASN.1 encoding of a list of trusted certifiers, as defined above:
-
-        TrustedCertifiers ::= SEQUENCE OF PrincipalName
-
-    If method-type=2, the signature on one of the certificates in the
-    chain cannot be verified.  The format of the method-data field will
-    be an ASN.1 encoding of the integer index of the certificate in
-    question:
-
-        CertificateIndex ::= INTEGER
-                             -- 0 = 1st certificate,
-                             -- 1 = 2nd certificate, etc
-
-    If method-type=3, one of the certificates in the chain has been
-    revoked.  The format of the method-data field will be an ASN.1
-    encoding of the integer index of the certificate in question:
-
-        CertificateIndex ::= INTEGER
-                             -- 0 = 1st certificate,
-                             -- 1 = 2nd certificate, etc
-
-    If method-type=4, the KDC name or realm in the PKAuthenticator does
-    not match the principal name of the KDC.  There is no method-data
-    field in this case.
-
-
-3.3.  Digital Signature
-
-    Implementation of the changes in this section are OPTIONAL for
-    compliance with PKINIT.
-
-    We offer this option with the warning that it requires the client to
-    generate a random key; the client may not be able to guarantee the
-    same level of randomness as the KDC.
-
-    If the user registered, or presents a certificate for, a digital
-    signature key with the KDC instead of an encryption key, then a
-    separate exchange must be used.  The client sends a request for a
-    TGT as usual, except that it (rather than the KDC) generates the
-    random key that will be used to encrypt the KDC response.  This key
-    is sent to the KDC along with the request in a preauthentication
-    field, encrypted with the KDC's public key:
-
-    PA-PK-AS-SIGN ::= SEQUENCE {
-                                -- PA TYPE 16
-        encSignedRandomKeyPack  [0] EncryptedData,
-                                    -- of type SignedRandomKeyPack
-                                    -- using the key in encTmpKeyPack
-        encTmpKeyPack           [1] EncryptedData,
-                                    -- of type TmpKeyPack
-                                    -- using the KDC's public key
-        userCert                [2] SEQUENCE OF Certificate OPTIONAL
-                                    -- the user's certificate chain
-    }
-
-    SignedRandomKeyPack ::= SEQUENCE {
-        randomkeyPack           [0] RandomKeyPack,
-        randomkeyPackSig        [1] Signature
-                                    -- of keyPack
-                                    -- using user's private key
-    }
-
-    RandomKeyPack ::= SEQUENCE {
-        randomKey               [0] EncryptionKey,
-                                    -- will be used to encrypt reply
-        randomKeyAuth           [1] PKAuthenticator
-                                    -- nonce copied from AS-REQ
-    }
-
-    If the KDC does not accept client-generated random keys as a matter
-    of policy, then it sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it extracts the random key as
-    follows.
-
-    Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
-    the randomKey.  It then replies as per RFC 1510, except that the
-    reply is encrypted not with a password-derived user key, but with
-    the randomKey sent in the request.  Since the client already knows
-    this key, there is no need to accompany the reply with an extra
-    preauthentication field.  The transited field of the ticket should
-    specify the certification path as described in Section 3.2.
-
-
-3.4.  Retrieving the User's Private Key from the KDC
-
-    Implementation of the changes described in this section are OPTIONAL
-    for compliance with PKINIT.
-
-    When the user's private key is not stored local to the user, he may
-    choose to store the private key (normally encrypted using a
-    password-derived key) on the KDC.  In this case, the client makes a
-    request as described above, except that instead of preauthenticating
-    with his private key, he uses a symmetric key shared with the KDC.
-
-    For simplicity's sake, this shared key is derived from the password-
-    derived key used to encrypt the private key, in such a way that the
-    KDC can authenticate the user with the shared key without being able
-    to extract the private key.
-
-    We provide this option to present the user with an alternative to
-    storing the private key on local disk at each machine where he
-    expects to authenticate himself using PKINIT.  It should be noted
-    that it replaces the added risk of long-term storage of the private
-    key on possibly many workstations with the added risk of storing the
-    private key on the KDC in a form vulnerable to brute-force attack.
-
-    Denote by K1 the symmetric key used to encrypt the private key.
-    Then construct symmetric key K2 as follows:
-
-        * Perform a hash on K1.
-        * Truncate the digest to Length(K1) bytes.
-        * Rectify parity in each byte (if necessary) to obtain K2.
-
-    The KDC stores K2, the public key, and the encrypted private key.
-    This key pair is designated as the "primary" key pair for that user.
-    This primary key pair is the one used to perform initial
-    authentication using the PA-PK-AS-REP preauthentication field.  If
-    he desires, he may also store additional key pairs on the KDC; these
-    may be requested in addition to the primary.  When the client
-    requests initial authentication using public key cryptography, it
-    must then include in its request, instead of a PA-PK-AS-REQ, the
-    following preauthentication sequence:
-
-    PA-PK-KEY-REQ ::= SEQUENCE {
-                                -- PA TYPE 17
-        signedPKAuth            [0] SignedPKAuth,
-        trustedCertifiers       [1] SEQUENCE OF PrincipalName OPTIONAL,
-                                    -- CAs that the client trusts
-        keyIDList               [2] SEQUENCE OF Checksum OPTIONAL
-                                    -- payload is hash of public key
-                                    -- corresponding to desired
-                                    -- private key
-                                    -- if absent, KDC will return all
-                                    -- stored private keys
-    }
-
-    SignedPKAuth ::= SEQUENCE {
-        pkAuth                  [0] PKAuthenticator,
-        pkAuthSig               [1] Signature
-                                    -- of pkAuth
-                                    -- using the symmetric key K2
-    }
-
-    If a keyIDList is present, the first identifier should indicate
-    the primary private key.  No public key certificate is required,
-    since the KDC stores the public key along with the private key.
-    If there is no keyIDList, all the user's private keys are returned.
-
-    Upon receipt, the KDC verifies the signature using K2.  If the
-    verification fails, the KDC sends back an error of type
-    KDC_ERR_INVALID_SIG.  If the signature verifies, but the requested
-    keys are not found on the KDC, then the KDC sends back an error of
-    type KDC_ERR_PREAUTH_FAILED.  If all checks out, the KDC responds as
-    described in Section 3.2, except that in addition, the KDC appends
-    the following preauthentication sequence:
-
-    PA-PK-KEY-REP ::= SEQUENCE {
-                                -- PA TYPE 18
-        encKeyRep               [0] EncryptedData
-                                    -- of type EncKeyReply
-                                    -- using the symmetric key K2
-    }
-
-    EncKeyReply ::= SEQUENCE {
-        keyPackList             [0] SEQUENCE OF KeyPack,
-                                    -- the first KeyPair is
-                                    -- the primary key pair
-        nonce                   [1] INTEGER
-                                    -- binds reply to request
-                                    -- must be identical to the nonce
-                                    -- sent in the SignedAuthPack
-    }
-
-    KeyPack ::= SEQUENCE {
-        keyID                   [0] Checksum,
-        encPrivKey              [1] OCTET STRING
-    }
-
-    Upon receipt of the reply, the client extracts the encrypted private
-    keys (and may store them, at the client's option).  The primary
-    private key, which must be the first private key in the keyPack
-    SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;
-    this key in turn is used to decrypt the main reply as described in
-    Section 3.2.
-
-
-4.  Logistics and Policy
-
-    This section describes a way to define the policy on the use of
-    PKINIT for each principal and request.
-
-    The KDC is not required to contain a database record for users
-    that use either the Standard Public Key Authentication or Public Key
-    Authentication with a Digital Signature.  However, if these users
-    are registered with the KDC, it is recommended that the database
-    record for these users be modified to include three additional flags
-    in the attributes field.
-
-    The first flag, use_standard_pk_init, indicates that the user should
-    authenticate using standard PKINIT as described in Section 3.2.  The
-    second flag, use_digital_signature, indicates that the user should
-    authenticate using digital signature PKINIT as described in Section
-    3.3.  The third flag, store_private_key, indicates that the user
-    has stored his private key on the KDC and should retrieve it using
-    the exchange described in Section 3.4.
-
-    If one of the preauthentication fields defined above is included in
-    the request, then the KDC shall respond as described in Sections 3.2
-    through 3.4, ignoring the aforementioned database flags.  If more
-    than one of the preauthentication fields is present, the KDC shall
-    respond with an error of type KDC_ERR_PREAUTH_FAILED.
-
-    In the event that none of the preauthentication fields defined above
-    are included in the request, the KDC checks to see if any of the
-    above flags are set.  If the first flag is set, then it sends back
-    an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
-    preauthentication field of type PA-PK-AS-REQ must be included in the
-    request.
-
-    Otherwise, if the first flag is clear, but the second flag is set,
-    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
-    indicating that a preauthentication field of type PA-PK-AS-SIGN must
-    be included in the request.
-
-    Lastly, if the first two flags are clear, but the third flag is set,
-    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
-    indicating that a preauthentication field of type PA-PK-KEY-REQ must
-    be included in the request.
-
-
-5.  Dependence on Transport Mechanisms
-
-    Certificate chains can potentially grow quite large and span several
-    UDP packets; this in turn increases the probability that a Kerberos
-    message involving PKINIT extensions will be broken in transit.  In
-    light of the possibility that the Kerberos specification will
-    allow TCP as a transport mechanism, we solicit discussion on whether
-    using PKINIT should encourage the use of TCP.
-
-
-6.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-    (V5).  Request for Comments 1510.
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.  September
-    1994.
-
-    [3] A. Medvinsky, M. Hur.  Addition of Kerberos Cipher Suites to
-    Transport Layer Security (TLS).
-    draft-ietf-tls-kerb-cipher-suites-00.txt
-
-    [4] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
-    Tickets for Application Servers (PKTAPP).
-    draft-ietf-cat-pktapp-00.txt
-
-    [5] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-    Using Public Key Cryptography.  Symposium On Network and Distributed
-    System Security, 1997.
-
-    [6] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction 
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic
-    Commerce, July 1995.
-
-    [7] Alan O. Freier, Philip Karlton and Paul C. Kocher.  The SSL
-    Protocol, Version 3.0 - IETF Draft. 
-
-    [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 
-    Distributed Systems.  In Proceedings of the 13th International 
-    Conference on Distributed Computing Systems, May 1993.
-
-    [9] ITU-T (formerly CCITT) Information technology - Open Systems
-    Interconnection - The Directory: Authentication Framework
-    Recommendation X.509 ISO/IEC 9594-8
-
-
-7.  Acknowledgements
-
-    Sasha Medvinsky contributed several ideas to the protocol changes
-    and specifications in this document.  His additions have been most
-    appreciated.
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-
-8.  Expiration Date
-
-    This draft expires January 31, 1997.
-
-
-9.  Authors
-
-    Brian Tung
-    Clifford Neuman
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {brian, bcn}@isi.edu
-
-    John Wray
-    Digital Equipment Corporation
-    550 King Street, LKG2-2/Z7
-    Littleton, MA 01460
-    Phone: +1 508 486 5210
-    E-mail: wray@tuxedo.enet.dec.com
-
-    Ari Medvinsky
-    Matthew Hur
-    CyberSafe Corporation
-    1605 NW Sammamish Road Suite 310
-    Issaquah WA 98027-5378
-    Phone: +1 206 391 6000
-    E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
-
-    Jonathan Trostle
-    Novell Corporation
-    Provo UT
-    E-mail: jtrostle@novell.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-05.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-05.txt
deleted file mode 100644
index 068edc2c0..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-05.txt
+++ /dev/null
@@ -1,916 +0,0 @@
-INTERNET-DRAFT                                              Brian Tung
-draft-ietf-cat-kerberos-pk-init-05.txt                 Clifford Neuman
-Updates: RFC 1510                                                  ISI
-expires May 26, 1998                                         John Wray
-                                         Digital Equipment Corporation
-                                                         Ari Medvinsky
-                                                           Matthew Hur
-                                                 CyberSafe Corporation
-                                                      Jonathan Trostle
-                                                                Novell
-
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-
-0.  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 learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ds.internic.net (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-05.txt, and expires May 26, 1998.
-    Please send comments to the authors.
-
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510 [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to associate a key pair with each realm, which can
-    then be used to facilitate cross-realm authentication; this is the
-    topic of another draft proposal.  Another way is to allow users with
-    public key certificates to use them in initial authentication.  This
-    is the concern of the current document.
-
-    One of the guiding principles in the design of PKINIT is that
-    changes should be as minimal as possible.  As a result, the basic
-    mechanism of PKINIT is as follows:  The user sends a request to the
-    KDC as before, except that if that user is to use public key
-    cryptography in the initial authentication step, his certificate
-    accompanies the initial request, in the preauthentication fields.
-
-    Upon receipt of this request, the KDC verifies the certificate and
-    issues a ticket granting ticket (TGT) as before, except that
-    the encPart from the AS-REP message carrying the TGT is now
-    encrypted in a randomly-generated key, instead of the user's
-    long-term key (which is derived from a password).  This
-    random key is in turn encrypted using the public key from the
-    certificate that came with the request and signed using the KDC's
-    private key, and accompanies the reply, in the preauthentication
-    fields.
-
-    PKINIT also allows for users with only digital signature keys to
-    authenticate using those keys, and for users to store and retrieve
-    private keys on the KDC.
-
-    The PKINIT specification may also be used for direct peer to peer
-    authentication without contacting a central KDC. This application
-    of PKINIT is described in PKTAPP [4] and is based on concepts
-    introduced in [5, 6]. For direct client-to-server authentication,
-    the client uses PKINIT to authenticate to the end server (instead
-    of a central KDC), which then issues a ticket for itself.  This
-    approach has an advantage over SSL [7] in that the server does not
-    need to save state (cache session keys).  Furthermore, an
-    additional benefit is that Kerberos tickets can facilitate
-    delegation (see [8]).
-
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510 for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following changes to RFC 1510 are proposed:
-
-        * Users may authenticate using either a public key pair or a
-          conventional (symmetric) key.  If public key cryptography is
-          used, public key data is transported in preauthentication
-          data fields to help establish identity.
-        * Users may store private keys on the KDC for retrieval during
-          Kerberos initial authentication.
-
-    This proposal addresses two ways that users may use public key
-    cryptography for initial authentication.  Users may present public
-    key certificates, or they may generate their own session key,
-    signed by their digital signature key.  In either case, the end
-    result is that the user obtains an ordinary TGT that may be used for
-    subsequent authentication, with such authentication using only
-    conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 and 3.3 describe the extensions for the two initial
-    authentication methods.  Section 3.4 describes a way for the user to
-    store and retrieve his private key on the KDC, as an adjunct to the
-    initial authentication.
-
-
-3.1.  Definitions
-
-    The extensions involve new encryption methods; we propose the
-    addition of the following types:
-
-        dsa-sign                                8
-        rsa-priv                                9
-        rsa-pub                                 10
-        rsa-pub-md5                             11
-        rsa-pub-sha1                            12
-
-    The proposal of these encryption types notwithstanding, we do not
-    mandate the use of any particular public key encryption method.
-
-    The extensions involve new preauthentication fields; we propose the
-    addition of the following types:
-
-        PA-PK-AS-REQ                            14
-        PA-PK-AS-REP                            15
-        PA-PK-AS-SIGN                           16
-        PA-PK-KEY-REQ                           17
-        PA-PK-KEY-REP                           18
-
-    The extensions also involve new error types; we propose the addition
-    of the following types:
-
-        KDC_ERR_CLIENT_NOT_TRUSTED              62
-        KDC_ERR_KDC_NOT_TRUSTED                 63
-        KDC_ERR_INVALID_SIG                     64
-        KDC_ERR_KEY_TOO_WEAK                    65
-        KDC_ERR_CERTIFICATE_MISMATCH            66
-
-    In many cases, PKINIT requires the encoding of an X.500 name as a
-    Realm.  In these cases, the realm will be represented using a
-    different style, specified in RFC 1510 with the following example:
-
-        NAMETYPE:rest/of.name=without-restrictions
-
-    For a realm derived from an X.500 name, NAMETYPE will have the value
-    X500-RFC1779.  The full realm name will appear as follows:
-
-        X500-RFC1779:RFC1779Encode(DistinguishedName)
-
-    where DistinguishedName is an X.500 name, and RFC1779Encode is a
-    readable ASCII encoding of an X.500 name, as defined by RFC 1779.
-    To ensure that this encoding is unique, we add the following rules
-    to those specified by RFC 1779:
-
-        * The optional spaces specified in RFC 1779 are not allowed.
-        * The character that separates relative distinguished names
-          must be ',' (i.e., it must never be ';').
-        * Attribute values must not be enclosed in double quotes.
-        * Attribute values must not be specified as hexadecimal
-          numbers.
-        * When an attribute name is specified in the form of an OID,
-          it must start with the 'OID.' prefix, and not the 'oid.'
-          prefix.
-        * The order in which the attributes appear in the RFC 1779
-          encoding must be the reverse of the order in the ASN.1
-          encoding of the X.500 name that appears in the public key
-          certificate, because RFC 1779 requires that the least
-          significant relative distinguished name appear first.  The
-          order of the relative distinguished names, as well as the
-          order of the attributes within each relative distinguished
-          name, will be reversed.
-
-    Similarly, PKINIT may require the encoding of an X.500 name as a
-    PrincipalName.  In these cases, the name-type of the principal name
-    shall be set to NT-X500-PRINCIPAL.  This new name type is defined
-    as:
-        #define CSFC5c_NT_X500_PRINCIPAL    6
-
-    The name-string shall be set as follows:
-
-        RFC1779Encode(DistinguishedName)
-
-    as described above.
-
-
-3.1.1.  Encryption and Key Formats
-
-    In the exposition below, we use the terms public key and private
-    key generically.  It should be understood that the term "public
-    key" may be used to refer to either a public encryption key or a
-    signature verification key, and that the term "private key" may be
-    used to refer to either a private decryption key or a signature
-    generation key.  The fact that these are logically distinct does
-    not preclude the assignment of bitwise identical keys.
-
-    All additional symmetric keys specified in this draft shall use the
-    same encryption type as the session key in the response from the
-    KDC.  These include the temporary keys used to encrypt the signed
-    random key encrypting the response, as well as the key derived from
-    Diffie-Hellman agreement.  In the case of Diffie-Hellman, the key
-    shall be produced from the agreed bit string as follows:
-
-        * Truncate the bit string to the appropriate length.
-        * Rectify parity in each byte (if necessary) to obtain the key.
-
-    For instance, in the case of a DES key, we take the first eight
-    bytes of the bit stream, and then adjust the least significant bit
-    of each byte to ensure that each byte has odd parity.
-
-    RFC 1510, Section 6.1, defines EncryptedData as follows:
-
-        EncryptedData ::= SEQUENCE {
-            etype               [0] INTEGER,
-            kvno                [1] INTEGER OPTIONAL,
-            cipher              [2] OCTET STRING
-                                    -- is CipherText
-        }
-
-    RFC 1510 also defines how CipherText is to be composed.  It is not
-    an ASN.1 data structure, but rather an octet string which is the
-    encryption of a plaintext string.  This plaintext string is in turn
-    a concatenation of the following octet strings: a confounder, a
-    checksum, the message, and padding.  Details of how these components
-    are arranged can be found in RFC 1510.
-
-    The PKINIT protocol introduces several new types of encryption.
-    Data that is encrypted with a public key will allow only the check
-    optional field, as it is defined above. This type of the checksum
-    will be specified in the etype field, together with the encryption
-    type.
-
-    In order to identify the checksum type, etype will have the
-    following values:
-
-                rsa-pub-MD5
-                rsa-pub-SHA1
-
-    In the case that etype is set to rsa-pub, the optional 'check'
-    field will not be provided.
-
-    Data that is encrypted with a private key will not use any optional
-    fields. PKINIT uses private key encryption only for signatures,
-    which are encrypted checksums. Therefore, the optional check field
-    is not needed.
-
-
-3.2.  Standard Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with PKINIT.
-
-    It is assumed that all public keys are signed by some certification
-    authority (CA).  The initial authentication request is sent as per
-    RFC 1510, except that a preauthentication field containing data
-    signed by the user's private key accompanies the request:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                -- PA TYPE 14
-        signedAuthPack          [0] SignedAuthPack
-        userCert                [1] SEQUENCE OF Certificate OPTIONAL,
-                                    -- the user's certificate chain
-        trustedCertifiers       [2] SEQUENCE OF PrincipalName OPTIONAL,
-                                    -- CAs that the client trusts
-        serialNumber            [3] CertificateSerialNumber OPTIONAL
-                                    -- specifying a particular
-                                    -- certificate if the client
-                                    -- already has it;
-                                    -- must be accompanied by
-                                    -- a single trustedCertifier
-    }
-
-    CertificateSerialNumber ::= INTEGER
-                                -- as specified by PKCS 6
-
-    SignedAuthPack ::= SEQUENCE {
-        authPack                [0] AuthPack,
-        authPackSig             [1] Signature,
-                                    -- of authPack
-                                    -- using user's private key
-    }
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- if client is using Diffie-Hellman
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        kdcName                 [0] PrincipalName,
-        kdcRealm                [1] Realm,
-        cusec                   [2] INTEGER,
-                                    -- for replay prevention
-        ctime                   [3] KerberosTime,
-                                    -- for replay prevention
-        nonce                   [4] INTEGER
-    }
-
-    Signature ::= SEQUENCE {
-        signedHash              [0] EncryptedData
-                                    -- of type Checksum
-    }
-
-    Checksum ::= SEQUENCE {
-        cksumtype               [0] INTEGER,
-        checksum                [1] OCTET STRING
-    }   -- as specified by RFC 1510
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm               [0] AlgorithmIdentifier,
-        subjectPublicKey        [1] BIT STRING
-                                    -- for DH, equals
-                                    -- public exponent (INTEGER encoded
-                                    -- as payload of BIT STRING)
-    }   -- as specified by the X.509 recommendation [9]
-
-    AlgorithmIdentifier ::= SEQUENCE {
-        algorithm               [0] ALGORITHM.&id,
-                                    -- for DH, equals
-                                    -- dhKeyAgreement
-                                    -- ({iso(1) member-body(2) US(840)
-                                    -- rsadsi(113549) pkcs(1) pkcs-3(3)
-                                    -- 1})
-        parameters              [1] ALGORITHM.&type
-                                    -- for DH, is DHParameter 
-    }   -- as specified by the X.509 recommendation [9]
-
-    DHParameter ::= SEQUENCE {
-        prime                   [0] INTEGER,
-                                    -- p
-        base                    [1] INTEGER,
-                                    -- g
-        privateValueLength      [2] INTEGER OPTIONAL
-    }
-
-    Certificate ::= SEQUENCE {
-        certType                [0] INTEGER,
-                                    -- type of certificate
-                                    -- 1 = X.509v3 (DER encoding)
-                                    -- 2 = PGP (per PGP specification)
-        certData                [1] OCTET STRING
-                                    -- actual certificate
-                                    -- type determined by certType
-    }
-
-    If the client passes a certificate serial number in the request,
-    the KDC is requested to use the referred-to certificate.  If none
-    exists, then the KDC returns an error of type
-    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
-    other hand, the client does not pass any trustedCertifiers,
-    believing that it has the KDC's certificate, but the KDC has more
-    than one certificate.
-
-    The PKAuthenticator carries information to foil replay attacks,
-    to bind the request and response, and to optionally pass the
-    client's Diffie-Hellman public value (i.e. for using DSA in
-    combination with Diffie-Hellman).  The PKAuthenticator is signed
-    with the private key corresponding to the public key in the
-    certificate found in userCert (or cached by the KDC).
-
-    In the PKAuthenticator, the client may specify the KDC name in one
-    of two ways:
-
-        * The Kerberos principal name krbtgt/<realm_name>@<realm_name>,
-          where <realm_name> is replaced by the applicable realm name.
-        * The name in the KDC's certificate (e.g., an X.500 name, or a
-          PGP name).
-
-    Note that the first case requires that the certificate name and the
-    Kerberos principal name be bound together (e.g., via an X.509v3
-    extension).
-
-    The userCert field is a sequence of certificates, the first of which
-    must be the user's public key certificate. Any subsequent
-    certificates will be certificates of the certifiers of the user's
-    certificate.  These cerificates may be used by the KDC to verify the
-    user's public key.  This field may be left empty if the KDC already
-    has the user's certificate.
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.  If the KDC has no
-    certificate signed by any of the trustedCertifiers, then it returns
-    an error of type KDC_ERR_CERTIFICATE_MISMATCH.
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.  This may be based on a certification
-    hierarchy, or it may be simply a list of recognized certifiers in a
-    system like PGP.
-
-    If verification of the user's certificate fails, the KDC sends back
-    an error message of type KDC_ERR_CLIENT_NOT_TRUSTED.  The e-data
-    field contains additional information pertaining to this error, and
-    is formatted as follows:
-
-        METHOD-DATA ::= SEQUENCE {
-            method-type         [0] INTEGER,
-                                    -- 1 = cannot verify public key
-                                    -- 2 = invalid certificate
-                                    -- 3 = revoked certificate
-                                    -- 4 = invalid KDC name
-                                    -- 5 = client name mismatch
-            method-data         [1] OCTET STRING OPTIONAL
-        } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
-
-    The values for the method-type and method-data fields are described
-    in Section 3.2.1.
-
-    If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
-    verifies that it has a certificate issued by one of the certifiers
-    trusted by the client.  If it does not have a suitable certificate,
-    the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
-    the client. 
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on AuthPack.  If that fails, the KDC returns an error
-    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
-    timestamp in the PKAuthenticator to assure that the request is not a
-    replay.   The KDC also verifies that its name is specified in the
-    PKAuthenticator.
-
-    If the clientPublicValue field is filled in, indicating that the
-    client wishes to use Diffie-Hellman key agreement, then the KDC
-    checks to see that the parameters satisfy its policy.  If they do
-    not (e.g., the prime size is insufficient for the expected
-    encryption type), then the KDC sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
-    private values for the response.
-
-    The KDC also checks that the timestamp in the PKAuthenticator is
-    within the allowable window.  If the local (server) time and the
-    client time in the authenticator differ by more than the allowable
-    clock skew, then the KDC returns an error message of type
-    KRB_AP_ERR_SKEW.
-
-    Assuming no errors, the KDC replies as per RFC 1510, except as
-    follows:  The user's name in the ticket is as represented in the
-    certificate, unless a Kerberos principal name is bound to the name
-    in the certificate (e.g., via an X.509v3 extension).  The user's
-    realm in the ticket shall be the name of the Certification
-    Authority that issued the user's public key certificate.
-
-    The KDC encrypts the reply not with the user's long-term key, but
-    with a random key generated only for this particular response.  This
-    random key is sealed in the preauthentication field:
-
-    PA-PK-AS-REP ::= SEQUENCE {
-                                -- PA TYPE 15
-        encSignedReplyKeyPack   [0] EncryptedData,
-                                    -- of type SignedReplyKeyPack
-                                    -- using the temporary key
-                                    -- in encTmpKey
-        encTmpKeyPack           [1] EncryptedData,
-                                    -- of type TmpKeyPack
-                                    -- using either the client public
-                                    -- key or the Diffie-Hellman key
-                                    -- specified by SignedDHPublicValue
-        signedKDCPublicValue    [2] SignedKDCPublicValue OPTIONAL
-                                    -- if one was passed in the request
-        kdcCert                 [3] SEQUENCE OF Certificate OPTIONAL,
-                                    -- the KDC's certificate chain
-    }
-
-    SignedReplyKeyPack ::= SEQUENCE {
-        replyKeyPack            [0] ReplyKeyPack,
-        replyKeyPackSig         [1] Signature,
-                                    -- of replyEncKeyPack
-                                    -- using KDC's private key
-    }
-
-    ReplyKeyPack ::= SEQUENCE {
-        replyKey                [0] EncryptionKey,
-                                    -- used to encrypt main reply
-                                    -- of same ENCTYPE as session key
-        nonce                   [1] INTEGER
-                                    -- binds response to the request
-                                    -- must be same as the nonce
-                                    -- passed in the PKAuthenticator
-    }
-
-    TmpKeyPack ::= SEQUENCE {
-        tmpKey                  [0] EncryptionKey,
-                                    -- used to encrypt the
-                                    -- SignedReplyKeyPack
-                                    -- of same ENCTYPE as session key
-    }
-        
-    SignedKDCPublicValue ::= SEQUENCE {
-        kdcPublicValue          [0] SubjectPublicKeyInfo,
-                                    -- as described above
-        kdcPublicValueSig       [1] Signature
-                                    -- of kdcPublicValue
-                                    -- using KDC's private key
-    }
-
-    The kdcCert field is a sequence of certificates, the first of which
-    must be the KDC's public key certificate.  Any subsequent
-    certificates will be certificates of the certifiers of the KDC's
-    certificate.  The last of these must have as its certifier one of
-    the certifiers sent to the KDC in the PA-PK-AS-REQ.  These
-    cerificates may be used by the client to verify the KDC's public
-    key.  This field is empty if the client did not send to the KDC a
-    list of trusted certifiers (the trustedCertifiers field was empty).
-    
-    Since each certifier in the certification path of a user's
-    certificate is essentially a separate realm, the name of each
-    certifier shall be added to the transited field of the ticket.  The
-    format of these realm names is defined in Section 3.1 of this
-    document.  If applicable, the transit-policy-checked flag should be
-    set in the issued ticket.
-
-    The KDC's certificate must bind the public key to a name derivable
-    from the name of the realm for that KDC.  For an X.509 certificate,
-    this is done as follows.  The name of the KDC will be represented
-    as an OtherName, encoded as a GeneralString:
-
-        GeneralName ::= CHOICE {
-            otherName       [0] KDCPrincipalName,
-            ...
-        }
-
-        KDCPrincipalNameTypes OTHER-NAME ::= {
-            { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
-        }
-
-        KDCPrincipalName ::= SEQUENCE {
-            nameType        OTHER-NAME.&id ( { KDCPrincipalNameTypes } ),
-            name            OTHER-NAME.&type ( { KDCPrincipalNameTypes }
-                               { @nameType } )
-        }
-
-        PrincipalNameSrvInst ::= GeneralString
-
-    where (from the Kerberos specification) we have
-
-        krb5 OBJECT IDENTIFIER ::= { iso (1)
-                                     org (3)
-                                     dod (6)
-                                     internet (1)
-                                     security (5)
-                                     kerberosv5 (2) }
-
-        principalName OBJECT IDENTIFIER ::= { krb5 2 }
-
-        principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }
-
-    The client then extracts the random key used to encrypt the main
-    reply.  This random key (in encPaReply) is encrypted with either the
-    client's public key or with a key derived from the DH values
-    exchanged between the client and the KDC.
-
-
-3.2.1.  Additional Information for Errors
-
-    This section describes the interpretation of the method-type and
-    method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
-
-    If method-type=1, the client's public key certificate chain does not
-    contain a certificate that is signed by a certification authority
-    trusted by the KDC.  The format of the method-data field will be an
-    ASN.1 encoding of a list of trusted certifiers, as defined above:
-
-        TrustedCertifiers ::= SEQUENCE OF PrincipalName
-
-    If method-type=2, the signature on one of the certificates in the
-    chain cannot be verified.  The format of the method-data field will
-    be an ASN.1 encoding of the integer index of the certificate in
-    question:
-
-        CertificateIndex ::= INTEGER
-                             -- 0 = 1st certificate,
-                             -- 1 = 2nd certificate, etc
-
-    If method-type=3, one of the certificates in the chain has been
-    revoked.  The format of the method-data field will be an ASN.1
-    encoding of the integer index of the certificate in question:
-
-        CertificateIndex ::= INTEGER
-                             -- 0 = 1st certificate,
-                             -- 1 = 2nd certificate, etc
-
-    If method-type=4, the KDC name or realm in the PKAuthenticator does
-    not match the principal name of the KDC.  There is no method-data
-    field in this case.
-
-    If method-type=5, the client name or realm in the certificate does
-    not match the principal name of the client.  There is no
-    method-data field in this case.
-
-
-3.3.  Digital Signature
-
-    Implementation of the changes in this section are OPTIONAL for
-    compliance with PKINIT.
-
-    We offer this option with the warning that it requires the client to
-    generate a random key; the client may not be able to guarantee the
-    same level of randomness as the KDC.
-
-    If the user registered, or presents a certificate for, a digital
-    signature key with the KDC instead of an encryption key, then a
-    separate exchange must be used.  The client sends a request for a
-    TGT as usual, except that it (rather than the KDC) generates the
-    random key that will be used to encrypt the KDC response.  This key
-    is sent to the KDC along with the request in a preauthentication
-    field, encrypted with the KDC's public key:
-
-    PA-PK-AS-SIGN ::= SEQUENCE {
-                                -- PA TYPE 16
-        encSignedRandomKeyPack  [0] EncryptedData,
-                                    -- of type SignedRandomKeyPack
-                                    -- using the key in encTmpKeyPack
-        encTmpKeyPack           [1] EncryptedData,
-                                    -- of type TmpKeyPack
-                                    -- using the KDC's public key
-        userCert                [2] SEQUENCE OF Certificate OPTIONAL
-                                    -- the user's certificate chain
-    }
-
-    SignedRandomKeyPack ::= SEQUENCE {
-        randomkeyPack           [0] RandomKeyPack,
-        randomkeyPackSig        [1] Signature
-                                    -- of keyPack
-                                    -- using user's private key
-    }
-
-    RandomKeyPack ::= SEQUENCE {
-        randomKey               [0] EncryptionKey,
-                                    -- will be used to encrypt reply
-        randomKeyAuth           [1] PKAuthenticator
-                                    -- nonce copied from AS-REQ
-    }
-
-    If the KDC does not accept client-generated random keys as a matter
-    of policy, then it sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it extracts the random key as
-    follows.
-
-    Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
-    the randomKey.  It then replies as per RFC 1510, except that the
-    reply is encrypted not with a password-derived user key, but with
-    the randomKey sent in the request.  Since the client already knows
-    this key, there is no need to accompany the reply with an extra
-    preauthentication field.  The transited field of the ticket should
-    specify the certification path as described in Section 3.2.
-
-
-3.4.  Retrieving the User's Private Key from the KDC
-
-    Implementation of the changes described in this section are OPTIONAL
-    for compliance with PKINIT.
-
-    When the user's private key is not stored local to the user, he may
-    choose to store the private key (normally encrypted using a
-    password-derived key) on the KDC.  In this case, the client makes a
-    request as described above, except that instead of preauthenticating
-    with his private key, he uses a symmetric key shared with the KDC.
-
-    For simplicity's sake, this shared key is derived from the password-
-    derived key used to encrypt the private key, in such a way that the
-    KDC can authenticate the user with the shared key without being able
-    to extract the private key.
-
-    We provide this option to present the user with an alternative to
-    storing the private key on local disk at each machine where he
-    expects to authenticate himself using PKINIT.  It should be noted
-    that it replaces the added risk of long-term storage of the private
-    key on possibly many workstations with the added risk of storing the
-    private key on the KDC in a form vulnerable to brute-force attack.
-
-    Denote by K1 the symmetric key used to encrypt the private key.
-    Then construct symmetric key K2 as follows:
-
-        * Perform a hash on K1.
-        * Truncate the digest to Length(K1) bytes.
-        * Rectify parity in each byte (if necessary) to obtain K2.
-
-    The KDC stores K2, the public key, and the encrypted private key.
-    This key pair is designated as the "primary" key pair for that user.
-    This primary key pair is the one used to perform initial
-    authentication using the PA-PK-AS-REP preauthentication field.  If
-    he desires, he may also store additional key pairs on the KDC; these
-    may be requested in addition to the primary.  When the client
-    requests initial authentication using public key cryptography, it
-    must then include in its request, instead of a PA-PK-AS-REQ, the
-    following preauthentication sequence:
-
-    PA-PK-KEY-REQ ::= SEQUENCE {
-                                -- PA TYPE 17
-        signedPKAuth            [0] SignedPKAuth,
-        trustedCertifiers       [1] SEQUENCE OF PrincipalName OPTIONAL,
-                                    -- CAs that the client trusts
-        keyIDList               [2] SEQUENCE OF Checksum OPTIONAL
-                                    -- payload is hash of public key
-                                    -- corresponding to desired
-                                    -- private key
-                                    -- if absent, KDC will return all
-                                    -- stored private keys
-    }
-
-    SignedPKAuth ::= SEQUENCE {
-        pkAuth                  [0] PKAuthenticator,
-        pkAuthSig               [1] Signature
-                                    -- of pkAuth
-                                    -- using the symmetric key K2
-    }
-
-    If a keyIDList is present, the first identifier should indicate
-    the primary private key.  No public key certificate is required,
-    since the KDC stores the public key along with the private key.
-    If there is no keyIDList, all the user's private keys are returned.
-
-    Upon receipt, the KDC verifies the signature using K2.  If the
-    verification fails, the KDC sends back an error of type
-    KDC_ERR_INVALID_SIG.  If the signature verifies, but the requested
-    keys are not found on the KDC, then the KDC sends back an error of
-    type KDC_ERR_PREAUTH_FAILED.  If all checks out, the KDC responds as
-    described in Section 3.2, except that in addition, the KDC appends
-    the following preauthentication sequence:
-
-    PA-PK-KEY-REP ::= SEQUENCE {
-                                -- PA TYPE 18
-        encKeyRep               [0] EncryptedData
-                                    -- of type EncKeyReply
-                                    -- using the symmetric key K2
-    }
-
-    EncKeyReply ::= SEQUENCE {
-        keyPackList             [0] SEQUENCE OF KeyPack,
-                                    -- the first KeyPair is
-                                    -- the primary key pair
-        nonce                   [1] INTEGER
-                                    -- binds reply to request
-                                    -- must be identical to the nonce
-                                    -- sent in the SignedAuthPack
-    }
-
-    KeyPack ::= SEQUENCE {
-        keyID                   [0] Checksum,
-        encPrivKey              [1] OCTET STRING
-    }
-
-    Upon receipt of the reply, the client extracts the encrypted private
-    keys (and may store them, at the client's option).  The primary
-    private key, which must be the first private key in the keyPack
-    SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;
-    this key in turn is used to decrypt the main reply as described in
-    Section 3.2.
-
-
-4.  Logistics and Policy
-
-    This section describes a way to define the policy on the use of
-    PKINIT for each principal and request.
-
-    The KDC is not required to contain a database record for users
-    that use either the Standard Public Key Authentication or Public Key
-    Authentication with a Digital Signature.  However, if these users
-    are registered with the KDC, it is recommended that the database
-    record for these users be modified to include three additional flags
-    in the attributes field.
-
-    The first flag, use_standard_pk_init, indicates that the user should
-    authenticate using standard PKINIT as described in Section 3.2.  The
-    second flag, use_digital_signature, indicates that the user should
-    authenticate using digital signature PKINIT as described in Section
-    3.3.  The third flag, store_private_key, indicates that the user
-    has stored his private key on the KDC and should retrieve it using
-    the exchange described in Section 3.4.
-
-    If one of the preauthentication fields defined above is included in
-    the request, then the KDC shall respond as described in Sections 3.2
-    through 3.4, ignoring the aforementioned database flags.  If more
-    than one of the preauthentication fields is present, the KDC shall
-    respond with an error of type KDC_ERR_PREAUTH_FAILED.
-
-    In the event that none of the preauthentication fields defined above
-    are included in the request, the KDC checks to see if any of the
-    above flags are set.  If the first flag is set, then it sends back
-    an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
-    preauthentication field of type PA-PK-AS-REQ must be included in the
-    request.
-
-    Otherwise, if the first flag is clear, but the second flag is set,
-    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
-    indicating that a preauthentication field of type PA-PK-AS-SIGN must
-    be included in the request.
-
-    Lastly, if the first two flags are clear, but the third flag is set,
-    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
-    indicating that a preauthentication field of type PA-PK-KEY-REQ must
-    be included in the request.
-
-
-5.  Transport Issues
-
-    Certificate chains can potentially grow quite large and span several
-    UDP packets; this in turn increases the probability that a Kerberos
-    message involving PKINIT extensions will be broken in transit.  In
-    light of the possibility that the Kerberos specification will
-    require KDCs to accept requests using TCP as a transport mechanism,
-    we make the same recommendation with respect to the PKINIT
-    extensions as well.
-
-
-6.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-    (V5).  Request for Comments 1510.
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.  September
-    1994.
-
-    [3] A. Medvinsky, M. Hur.  Addition of Kerberos Cipher Suites to
-    Transport Layer Security (TLS).
-    draft-ietf-tls-kerb-cipher-suites-00.txt
-
-    [4] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
-    Tickets for Application Servers (PKTAPP).
-    draft-ietf-cat-pktapp-00.txt
-
-    [5] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-    Using Public Key Cryptography.  Symposium On Network and Distributed
-    System Security, 1997.
-
-    [6] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction 
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic
-    Commerce, July 1995.
-
-    [7] Alan O. Freier, Philip Karlton and Paul C. Kocher.  The SSL
-    Protocol, Version 3.0 - IETF Draft. 
-
-    [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 
-    Distributed Systems.  In Proceedings of the 13th International 
-    Conference on Distributed Computing Systems, May 1993.
-
-    [9] ITU-T (formerly CCITT) Information technology - Open Systems
-    Interconnection - The Directory: Authentication Framework
-    Recommendation X.509 ISO/IEC 9594-8
-
-
-7.  Acknowledgements
-
-    Sasha Medvinsky contributed several ideas to the protocol changes
-    and specifications in this document.  His additions have been most
-    appreciated.
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-
-8.  Expiration Date
-
-    This draft expires May 26, 1998.
-
-
-9.  Authors
-
-    Brian Tung
-    Clifford Neuman
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {brian, bcn}@isi.edu
-
-    John Wray
-    Digital Equipment Corporation
-    550 King Street, LKG2-2/Z7
-    Littleton, MA 01460
-    Phone: +1 508 486 5210
-    E-mail: wray@tuxedo.enet.dec.com
-
-    Ari Medvinsky
-    Matthew Hur
-    CyberSafe Corporation
-    1605 NW Sammamish Road Suite 310
-    Issaquah WA 98027-5378
-    Phone: +1 206 391 6000
-    E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
-
-    Jonathan Trostle
-    Novell Corporation
-    Provo UT
-    E-mail: jtrostle@novell.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-06.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-06.txt
deleted file mode 100644
index cb18eb5ca..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-06.txt
+++ /dev/null
@@ -1,959 +0,0 @@
-INTERNET-DRAFT                                              Brian Tung
-draft-ietf-cat-kerberos-pk-init-06.txt                 Clifford Neuman
-Updates: RFC 1510                                                  ISI
-expires September 15, 1998                                   John Wray
-                                         Digital Equipment Corporation
-                                                         Ari Medvinsky
-                                                           Matthew Hur
-                                                 CyberSafe Corporation
-                                                      Jonathan Trostle
-                                                                Novell
-
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-
-0.  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 learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ds.internic.net (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-05.txt, and expires September 15,
-    1998.  Please send comments to the authors.
-
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510 [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to associate a key pair with each realm, which can
-    then be used to facilitate cross-realm authentication; this is the
-    topic of another draft proposal.  Another way is to allow users with
-    public key certificates to use them in initial authentication.  This
-    is the concern of the current document.
-
-    One of the guiding principles in the design of PKINIT is that
-    changes should be as minimal as possible.  As a result, the basic
-    mechanism of PKINIT is as follows:  The user sends a request to the
-    KDC as before, except that if that user is to use public key
-    cryptography in the initial authentication step, his certificate
-    accompanies the initial request, in the preauthentication fields.
-
-    Upon receipt of this request, the KDC verifies the certificate and
-    issues a ticket granting ticket (TGT) as before, except that
-    the encPart from the AS-REP message carrying the TGT is now
-    encrypted in a randomly-generated key, instead of the user's
-    long-term key (which is derived from a password).  This
-    random key is in turn encrypted using the public key from the
-    certificate that came with the request and signed using the KDC's
-    private key, and accompanies the reply, in the preauthentication
-    fields.
-
-    PKINIT also allows for users with only digital signature keys to
-    authenticate using those keys, and for users to store and retrieve
-    private keys on the KDC.
-
-    The PKINIT specification may also be used for direct peer to peer
-    authentication without contacting a central KDC. This application
-    of PKINIT is described in PKTAPP [4] and is based on concepts
-    introduced in [5, 6]. For direct client-to-server authentication,
-    the client uses PKINIT to authenticate to the end server (instead
-    of a central KDC), which then issues a ticket for itself.  This
-    approach has an advantage over SSL [7] in that the server does not
-    need to save state (cache session keys).  Furthermore, an
-    additional benefit is that Kerberos tickets can facilitate
-    delegation (see [8]).
-
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510 for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following changes to RFC 1510 are proposed:
-
-        * Users may authenticate using either a public key pair or a
-          conventional (symmetric) key.  If public key cryptography is
-          used, public key data is transported in preauthentication
-          data fields to help establish identity.
-        * Users may store private keys on the KDC for retrieval during
-          Kerberos initial authentication.
-
-    This proposal addresses two ways that users may use public key
-    cryptography for initial authentication.  Users may present public
-    key certificates, or they may generate their own session key,
-    signed by their digital signature key.  In either case, the end
-    result is that the user obtains an ordinary TGT that may be used for
-    subsequent authentication, with such authentication using only
-    conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 and 3.3 describe the extensions for the two initial
-    authentication methods.  Section 3.4 describes a way for the user to
-    store and retrieve his private key on the KDC, as an adjunct to the
-    initial authentication.
-
-
-3.1.  Definitions
-
-    The extensions involve new encryption methods; we propose the
-    addition of the following types:
-
-        dsa-sign                                8
-        rsa-priv                                9
-        rsa-pub                                 10
-        rsa-pub-md5                             11
-        rsa-pub-sha1                            12
-
-    The proposal of these encryption types notwithstanding, we do not
-    mandate the use of any particular public key encryption method.
-
-    The extensions involve new preauthentication fields; we propose the
-    addition of the following types:
-
-        PA-PK-AS-REQ                            14
-        PA-PK-AS-REP                            15
-        PA-PK-AS-SIGN                           16
-        PA-PK-KEY-REQ                           17
-        PA-PK-KEY-REP                           18
-
-    The extensions also involve new error types; we propose the addition
-    of the following types:
-
-        KDC_ERR_CLIENT_NOT_TRUSTED              62
-        KDC_ERR_KDC_NOT_TRUSTED                 63
-        KDC_ERR_INVALID_SIG                     64
-        KDC_ERR_KEY_TOO_WEAK                    65
-        KDC_ERR_CERTIFICATE_MISMATCH            66
-
-    In addition, PKINIT does not define, but does permit, the following
-    algorithm identifiers for use with the Signature data structure:
-
-        md4WithRSAEncryption (as defined in PKCS 1)
-        md5WithRSAEncryption (as defined in PKCS 1)
-        sha-1WithRSAEncryption ::= { iso(1) member-body(2) us(840)
-                                     rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
-        dsaWithSHA1 ::= { OIW oIWSecSig(3) oIWSecAlgorithm(2)
-                          dsaWithSHA1(27) }
-
-    where
-
-        OIW ::= iso(1) identifiedOrganization(3) oIW(14)
-
-    In many cases, PKINIT requires the encoding of an X.500 name as a
-    Realm.  In these cases, the realm will be represented using a
-    different style, specified in RFC 1510 with the following example:
-
-        NAMETYPE:rest/of.name=without-restrictions
-
-    For a realm derived from an X.500 name, NAMETYPE will have the value
-    X500-RFC1779.  The full realm name will appear as follows:
-
-        X500-RFC1779:RFC1779Encode(DistinguishedName)
-
-    where DistinguishedName is an X.500 name, and RFC1779Encode is a
-    readable ASCII encoding of an X.500 name, as defined by RFC 1779.
-    To ensure that this encoding is unique, we add the following rules
-    to those specified by RFC 1779:
-
-        * The optional spaces specified in RFC 1779 are not allowed.
-        * The character that separates relative distinguished names
-          must be ',' (i.e., it must never be ';').
-        * Attribute values must not be enclosed in double quotes.
-        * Attribute values must not be specified as hexadecimal
-          numbers.
-        * When an attribute name is specified in the form of an OID,
-          it must start with the 'OID.' prefix, and not the 'oid.'
-          prefix.
-        * The order in which the attributes appear in the RFC 1779
-          encoding must be the reverse of the order in the ASN.1
-          encoding of the X.500 name that appears in the public key
-          certificate, because RFC 1779 requires that the least
-          significant relative distinguished name appear first.  The
-          order of the relative distinguished names, as well as the
-          order of the attributes within each relative distinguished
-          name, will be reversed.
-
-    Similarly, PKINIT may require the encoding of an X.500 name as a
-    PrincipalName.  In these cases, the name-type of the principal name
-    shall be set to NT-X500-PRINCIPAL.  This new name type is defined
-    as:
-
-        #define CSFC5c_NT_X500_PRINCIPAL    6
-
-    The name-string shall be set as follows:
-
-        RFC1779Encode(DistinguishedName)
-
-    as described above.
-
-
-3.1.1.  Encryption and Key Formats
-
-    In the exposition below, we use the terms public key and private
-    key generically.  It should be understood that the term "public
-    key" may be used to refer to either a public encryption key or a
-    signature verification key, and that the term "private key" may be
-    used to refer to either a private decryption key or a signature
-    generation key.  The fact that these are logically distinct does
-    not preclude the assignment of bitwise identical keys.
-
-    All additional symmetric keys specified in this draft shall use the
-    same encryption type as the session key in the response from the
-    KDC.  These include the temporary keys used to encrypt the signed
-    random key encrypting the response, as well as the key derived from
-    Diffie-Hellman agreement.  In the case of Diffie-Hellman, the key
-    shall be produced from the agreed bit string as follows:
-
-        * Truncate the bit string to the appropriate length.
-        * Rectify parity in each byte (if necessary) to obtain the key.
-
-    For instance, in the case of a DES key, we take the first eight
-    bytes of the bit stream, and then adjust the least significant bit
-    of each byte to ensure that each byte has odd parity.
-
-    RFC 1510, Section 6.1, defines EncryptedData as follows:
-
-        EncryptedData ::= SEQUENCE {
-            etype               [0] INTEGER,
-            kvno                [1] INTEGER OPTIONAL,
-            cipher              [2] OCTET STRING
-                                    -- is CipherText
-        }
-
-    RFC 1510 also defines how CipherText is to be composed.  It is not
-    an ASN.1 data structure, but rather an octet string which is the
-    encryption of a plaintext string.  This plaintext string is in turn
-    a concatenation of the following octet strings: a confounder, a
-    checksum, the message, and padding.  Details of how these components
-    are arranged can be found in RFC 1510.
-
-    The PKINIT protocol introduces several new types of encryption.
-    Data that is encrypted with a public key will allow only the check
-    optional field, as it is defined above. This type of the checksum
-    will be specified in the etype field, together with the encryption
-    type.
-
-    In order to identify the checksum type, etype will have the
-    following values:
-
-                rsa-pub-MD5
-                rsa-pub-SHA1
-
-    In the case that etype is set to rsa-pub, the optional 'check'
-    field will not be provided.
-
-    Data that is encrypted with a private key will not use any optional
-    fields. PKINIT uses private key encryption only for signatures,
-    which are encrypted checksums. Therefore, the optional check field
-    is not needed.
-
-
-3.2.  Standard Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with PKINIT.
-
-    It is assumed that all public keys are signed by some certification
-    authority (CA).  The initial authentication request is sent as per
-    RFC 1510, except that a preauthentication field containing data
-    signed by the user's private key accompanies the request:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                -- PA TYPE 14
-        signedAuthPack          [0] SignedAuthPack
-        userCert                [1] SEQUENCE OF Certificate OPTIONAL,
-                                    -- the user's certificate chain
-        trustedCertifiers       [2] SEQUENCE OF PrincipalName OPTIONAL,
-                                    -- CAs that the client trusts
-        serialNumber            [3] CertificateSerialNumber OPTIONAL
-                                    -- specifying a particular
-                                    -- certificate if the client
-                                    -- already has it;
-                                    -- must be accompanied by
-                                    -- a single trustedCertifier
-    }
-
-    CertificateSerialNumber ::= INTEGER
-                                -- as specified by PKCS 6
-
-    SignedAuthPack ::= SEQUENCE {
-        authPack                [0] AuthPack,
-        authPackSig             [1] Signature,
-                                    -- of authPack
-                                    -- using user's private key
-    }
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- if client is using Diffie-Hellman
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        kdcName                 [0] PrincipalName,
-        kdcRealm                [1] Realm,
-        cusec                   [2] INTEGER,
-                                    -- for replay prevention
-        ctime                   [3] KerberosTime,
-                                    -- for replay prevention
-        nonce                   [4] INTEGER
-    }
-
-    Signature ::= SEQUENCE {
-        signatureAlgorithm      [0] SignatureAlgorithmIdentifier,
-        pkcsSignature           [1] BIT STRING
-                                    -- octet-aligned big-endian bit
-                                    -- string (encrypted with signer's
-                                    -- private key)
-    }
-
-    SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
-
-    AlgorithmIdentifier ::= SEQUENCE {
-        algorithm                   ALGORITHM.&id,
-                                    -- for DH, equals
-                                    -- dhKeyAgreement
-                                    -- ({iso(1) member-body(2) US(840)
-                                    -- rsadsi(113549) pkcs(1) pkcs-3(3)
-                                    -- 1})
-        parameters                  ALGORITHM.&type
-                                    -- for DH, is DHParameter 
-    }   -- as specified by the X.509 recommendation [9]
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm                   AlgorithmIdentifier,
-        subjectPublicKey            BIT STRING
-                                    -- for DH, equals
-                                    -- public exponent (INTEGER encoded
-                                    -- as payload of BIT STRING)
-    }   -- as specified by the X.509 recommendation [9]
-
-    DHParameter ::= SEQUENCE {
-        prime                       INTEGER,
-                                    -- p
-        base                        INTEGER,
-                                    -- g
-        privateValueLength          INTEGER OPTIONAL
-    }   -- as specified by the X.509 recommendation [9]
-
-    Certificate ::= SEQUENCE {
-        certType                [0] INTEGER,
-                                    -- type of certificate
-                                    -- 1 = X.509v3 (DER encoding)
-                                    -- 2 = PGP (per PGP specification)
-        certData                [1] OCTET STRING
-                                    -- actual certificate
-                                    -- type determined by certType
-    }
-
-    If the client passes a certificate serial number in the request,
-    the KDC is requested to use the referred-to certificate.  If none
-    exists, then the KDC returns an error of type
-    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
-    other hand, the client does not pass any trustedCertifiers,
-    believing that it has the KDC's certificate, but the KDC has more
-    than one certificate.
-
-    The PKAuthenticator carries information to foil replay attacks,
-    to bind the request and response, and to optionally pass the
-    client's Diffie-Hellman public value (i.e. for using DSA in
-    combination with Diffie-Hellman).  The PKAuthenticator is signed
-    with the private key corresponding to the public key in the
-    certificate found in userCert (or cached by the KDC).
-
-    In the PKAuthenticator, the client may specify the KDC name in one
-    of two ways:
-
-        * The Kerberos principal name krbtgt/<realm_name>@<realm_name>,
-          where <realm_name> is replaced by the applicable realm name.
-        * The name in the KDC's certificate (e.g., an X.500 name, or a
-          PGP name).
-
-    Note that the first case requires that the certificate name and the
-    Kerberos principal name be bound together (e.g., via an X.509v3
-    extension).
-
-    The userCert field is a sequence of certificates, the first of which
-    must be the user's public key certificate. Any subsequent
-    certificates will be certificates of the certifiers of the user's
-    certificate.  These cerificates may be used by the KDC to verify the
-    user's public key.  This field may be left empty if the KDC already
-    has the user's certificate.
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.  If the KDC has no
-    certificate signed by any of the trustedCertifiers, then it returns
-    an error of type KDC_ERR_CERTIFICATE_MISMATCH.
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.  This may be based on a certification
-    hierarchy, or it may be simply a list of recognized certifiers in a
-    system like PGP.
-
-    If verification of the user's certificate fails, the KDC sends back
-    an error message of type KDC_ERR_CLIENT_NOT_TRUSTED.  The e-data
-    field contains additional information pertaining to this error, and
-    is formatted as follows:
-
-        METHOD-DATA ::= SEQUENCE {
-            method-type         [0] INTEGER,
-                                    -- 1 = cannot verify public key
-                                    -- 2 = invalid certificate
-                                    -- 3 = revoked certificate
-                                    -- 4 = invalid KDC name
-                                    -- 5 = client name mismatch
-            method-data         [1] OCTET STRING OPTIONAL
-        } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
-
-    The values for the method-type and method-data fields are described
-    in Section 3.2.1.
-
-    If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
-    verifies that it has a certificate issued by one of the certifiers
-    trusted by the client.  If it does not have a suitable certificate,
-    the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
-    the client. 
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on AuthPack.  If that fails, the KDC returns an error
-    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
-    timestamp in the PKAuthenticator to assure that the request is not a
-    replay.   The KDC also verifies that its name is specified in the
-    PKAuthenticator.
-
-    If the clientPublicValue field is filled in, indicating that the
-    client wishes to use Diffie-Hellman key agreement, then the KDC
-    checks to see that the parameters satisfy its policy.  If they do
-    not (e.g., the prime size is insufficient for the expected
-    encryption type), then the KDC sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
-    private values for the response.
-
-    The KDC also checks that the timestamp in the PKAuthenticator is
-    within the allowable window.  If the local (server) time and the
-    client time in the authenticator differ by more than the allowable
-    clock skew, then the KDC returns an error message of type
-    KRB_AP_ERR_SKEW.
-
-    Assuming no errors, the KDC replies as per RFC 1510, except as
-    follows:  The user's name in the ticket is as represented in the
-    certificate, unless a Kerberos principal name is bound to the name
-    in the certificate (e.g., via an X.509v3 extension).  The user's
-    realm in the ticket shall be the name of the Certification
-    Authority that issued the user's public key certificate.
-
-    The KDC encrypts the reply not with the user's long-term key, but
-    with a random key generated only for this particular response.  This
-    random key is sealed in the preauthentication field:
-
-    PA-PK-AS-REP ::= SEQUENCE {
-                                -- PA TYPE 15
-        encSignedReplyKeyPack   [0] EncryptedData,
-                                    -- of type SignedReplyKeyPack
-                                    -- using the temporary key
-                                    -- in encTmpKey
-        encTmpKeyPack           [1] EncryptedData,
-                                    -- of type TmpKeyPack
-                                    -- using either the client public
-                                    -- key or the Diffie-Hellman key
-                                    -- specified by SignedDHPublicValue
-        signedKDCPublicValue    [2] SignedKDCPublicValue OPTIONAL
-                                    -- if one was passed in the request
-        kdcCert                 [3] SEQUENCE OF Certificate OPTIONAL,
-                                    -- the KDC's certificate chain
-    }
-
-    SignedReplyKeyPack ::= SEQUENCE {
-        replyKeyPack            [0] ReplyKeyPack,
-        replyKeyPackSig         [1] Signature,
-                                    -- of replyEncKeyPack
-                                    -- using KDC's private key
-    }
-
-    ReplyKeyPack ::= SEQUENCE {
-        replyKey                [0] EncryptionKey,
-                                    -- used to encrypt main reply
-                                    -- of same ENCTYPE as session key
-        nonce                   [1] INTEGER
-                                    -- binds response to the request
-                                    -- must be same as the nonce
-                                    -- passed in the PKAuthenticator
-    }
-
-    TmpKeyPack ::= SEQUENCE {
-        tmpKey                  [0] EncryptionKey,
-                                    -- used to encrypt the
-                                    -- SignedReplyKeyPack
-                                    -- of same ENCTYPE as session key
-    }
-        
-    SignedKDCPublicValue ::= SEQUENCE {
-        kdcPublicValue          [0] SubjectPublicKeyInfo,
-                                    -- as described above
-        kdcPublicValueSig       [1] Signature
-                                    -- of kdcPublicValue
-                                    -- using KDC's private key
-    }
-
-    The kdcCert field is a sequence of certificates, the first of which
-    must be the KDC's public key certificate.  Any subsequent
-    certificates will be certificates of the certifiers of the KDC's
-    certificate.  The last of these must have as its certifier one of
-    the certifiers sent to the KDC in the PA-PK-AS-REQ.  These
-    cerificates may be used by the client to verify the KDC's public
-    key.  This field is empty if the client did not send to the KDC a
-    list of trusted certifiers (the trustedCertifiers field was empty).
-    
-    Since each certifier in the certification path of a user's
-    certificate is essentially a separate realm, the name of each
-    certifier shall be added to the transited field of the ticket.  The
-    format of these realm names is defined in Section 3.1 of this
-    document.  If applicable, the transit-policy-checked flag should be
-    set in the issued ticket.
-
-    The KDC's certificate must bind the public key to a name derivable
-    from the name of the realm for that KDC.  For an X.509 certificate,
-    this is done as follows.  The name of the KDC will be represented
-    as an OtherName, encoded as a GeneralString:
-
-        GeneralName ::= CHOICE {
-            otherName       [0] KDCPrincipalName,
-            ...
-        }
-
-        KDCPrincipalNameTypes OTHER-NAME ::= {
-            { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
-        }
-
-        KDCPrincipalName ::= SEQUENCE {
-            nameType        [0] OTHER-NAME.&id ( { KDCPrincipalNameTypes } ),
-            name            [1] OTHER-NAME.&type ( { KDCPrincipalNameTypes }
-                               { @nameType } )
-        }
-
-        PrincipalNameSrvInst ::= GeneralString
-
-    where (from the Kerberos specification) we have
-
-        krb5 OBJECT IDENTIFIER ::= { iso (1)
-                                     org (3)
-                                     dod (6)
-                                     internet (1)
-                                     security (5)
-                                     kerberosv5 (2) }
-
-        principalName OBJECT IDENTIFIER ::= { krb5 2 }
-
-        principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }
-
-    The client then extracts the random key used to encrypt the main
-    reply.  This random key (in encPaReply) is encrypted with either the
-    client's public key or with a key derived from the DH values
-    exchanged between the client and the KDC.
-
-
-3.2.1.  Additional Information for Errors
-
-    This section describes the interpretation of the method-type and
-    method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
-
-    If method-type=1, the client's public key certificate chain does not
-    contain a certificate that is signed by a certification authority
-    trusted by the KDC.  The format of the method-data field will be an
-    ASN.1 encoding of a list of trusted certifiers, as defined above:
-
-        TrustedCertifiers ::= SEQUENCE OF PrincipalName
-
-    If method-type=2, the signature on one of the certificates in the
-    chain cannot be verified.  The format of the method-data field will
-    be an ASN.1 encoding of the integer index of the certificate in
-    question:
-
-        CertificateIndex ::= INTEGER
-                             -- 0 = 1st certificate,
-                             -- 1 = 2nd certificate, etc
-
-    If method-type=3, one of the certificates in the chain has been
-    revoked.  The format of the method-data field will be an ASN.1
-    encoding of the integer index of the certificate in question:
-
-        CertificateIndex ::= INTEGER
-                             -- 0 = 1st certificate,
-                             -- 1 = 2nd certificate, etc
-
-    If method-type=4, the KDC name or realm in the PKAuthenticator does
-    not match the principal name of the KDC.  There is no method-data
-    field in this case.
-
-    If method-type=5, the client name or realm in the certificate does
-    not match the principal name of the client.  There is no
-    method-data field in this case.
-
-
-3.3.  Digital Signature
-
-    Implementation of the changes in this section are OPTIONAL for
-    compliance with PKINIT.
-
-    We offer this option with the warning that it requires the client to
-    generate a random key; the client may not be able to guarantee the
-    same level of randomness as the KDC.
-
-    If the user registered, or presents a certificate for, a digital
-    signature key with the KDC instead of an encryption key, then a
-    separate exchange must be used.  The client sends a request for a
-    TGT as usual, except that it (rather than the KDC) generates the
-    random key that will be used to encrypt the KDC response.  This key
-    is sent to the KDC along with the request in a preauthentication
-    field, encrypted with the KDC's public key:
-
-    PA-PK-AS-SIGN ::= SEQUENCE {
-                                -- PA TYPE 16
-        encSignedRandomKeyPack  [0] EncryptedData,
-                                    -- of type SignedRandomKeyPack
-                                    -- using the key in encTmpKeyPack
-        encTmpKeyPack           [1] EncryptedData,
-                                    -- of type TmpKeyPack
-                                    -- using the KDC's public key
-        userCert                [2] SEQUENCE OF Certificate OPTIONAL
-                                    -- the user's certificate chain
-    }
-
-    SignedRandomKeyPack ::= SEQUENCE {
-        randomkeyPack           [0] RandomKeyPack,
-        randomkeyPackSig        [1] Signature
-                                    -- of keyPack
-                                    -- using user's private key
-    }
-
-    RandomKeyPack ::= SEQUENCE {
-        randomKey               [0] EncryptionKey,
-                                    -- will be used to encrypt reply
-        randomKeyAuth           [1] PKAuthenticator
-                                    -- nonce copied from AS-REQ
-    }
-
-    If the KDC does not accept client-generated random keys as a matter
-    of policy, then it sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it extracts the random key as
-    follows.
-
-    Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
-    the randomKey.  It then replies as per RFC 1510, except that the
-    reply is encrypted not with a password-derived user key, but with
-    the randomKey sent in the request.  Since the client already knows
-    this key, there is no need to accompany the reply with an extra
-    preauthentication field.  The transited field of the ticket should
-    specify the certification path as described in Section 3.2.
-
-
-3.4.  Retrieving the User's Private Key from the KDC
-
-    Implementation of the changes described in this section are OPTIONAL
-    for compliance with PKINIT.
-
-    When the user's private key is not stored local to the user, he may
-    choose to store the private key (normally encrypted using a
-    password-derived key) on the KDC.  In this case, the client makes a
-    request as described above, except that instead of preauthenticating
-    with his private key, he uses a symmetric key shared with the KDC.
-
-    For simplicity's sake, this shared key is derived from the password-
-    derived key used to encrypt the private key, in such a way that the
-    KDC can authenticate the user with the shared key without being able
-    to extract the private key.
-
-    We provide this option to present the user with an alternative to
-    storing the private key on local disk at each machine where he
-    expects to authenticate himself using PKINIT.  It should be noted
-    that it replaces the added risk of long-term storage of the private
-    key on possibly many workstations with the added risk of storing the
-    private key on the KDC in a form vulnerable to brute-force attack.
-
-    Denote by K1 the symmetric key used to encrypt the private key.
-    Then construct symmetric key K2 as follows:
-
-        * Perform a hash on K1.
-        * Truncate the digest to Length(K1) bytes.
-        * Rectify parity in each byte (if necessary) to obtain K2.
-
-    The KDC stores K2, the public key, and the encrypted private key.
-    This key pair is designated as the "primary" key pair for that user.
-    This primary key pair is the one used to perform initial
-    authentication using the PA-PK-AS-REP preauthentication field.  If
-    he desires, he may also store additional key pairs on the KDC; these
-    may be requested in addition to the primary.  When the client
-    requests initial authentication using public key cryptography, it
-    must then include in its request, instead of a PA-PK-AS-REQ, the
-    following preauthentication sequence:
-
-    PA-PK-KEY-REQ ::= SEQUENCE {
-                                -- PA TYPE 17
-        signedPKAuth            [0] SignedPKAuth,
-        trustedCertifiers       [1] SEQUENCE OF PrincipalName OPTIONAL,
-                                    -- CAs that the client trusts
-        keyIDList               [2] SEQUENCE OF Checksum OPTIONAL
-                                    -- payload is hash of public key
-                                    -- corresponding to desired
-                                    -- private key
-                                    -- if absent, KDC will return all
-                                    -- stored private keys
-    }
-
-    Checksum ::= SEQUENCE {
-        cksumtype               [0] INTEGER,
-        checksum                [1] OCTET STRING
-    }   -- as specified by RFC 1510
-
-    SignedPKAuth ::= SEQUENCE {
-        pkAuth                  [0] PKAuthenticator,
-        pkAuthSig               [1] Signature
-                                    -- of pkAuth
-                                    -- using the symmetric key K2
-    }
-
-    If a keyIDList is present, the first identifier should indicate
-    the primary private key.  No public key certificate is required,
-    since the KDC stores the public key along with the private key.
-    If there is no keyIDList, all the user's private keys are returned.
-
-    Upon receipt, the KDC verifies the signature using K2.  If the
-    verification fails, the KDC sends back an error of type
-    KDC_ERR_INVALID_SIG.  If the signature verifies, but the requested
-    keys are not found on the KDC, then the KDC sends back an error of
-    type KDC_ERR_PREAUTH_FAILED.  If all checks out, the KDC responds as
-    described in Section 3.2, except that in addition, the KDC appends
-    the following preauthentication sequence:
-
-    PA-PK-KEY-REP ::= SEQUENCE {
-                                -- PA TYPE 18
-        encKeyRep               [0] EncryptedData
-                                    -- of type EncKeyReply
-                                    -- using the symmetric key K2
-    }
-
-    EncKeyReply ::= SEQUENCE {
-        keyPackList             [0] SEQUENCE OF KeyPack,
-                                    -- the first KeyPair is
-                                    -- the primary key pair
-        nonce                   [1] INTEGER
-                                    -- binds reply to request
-                                    -- must be identical to the nonce
-                                    -- sent in the SignedAuthPack
-    }
-
-    KeyPack ::= SEQUENCE {
-        keyID                   [0] Checksum,
-        encPrivKey              [1] OCTET STRING
-    }
-
-    Upon receipt of the reply, the client extracts the encrypted private
-    keys (and may store them, at the client's option).  The primary
-    private key, which must be the first private key in the keyPack
-    SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;
-    this key in turn is used to decrypt the main reply as described in
-    Section 3.2.
-
-
-4.  Logistics and Policy
-
-    This section describes a way to define the policy on the use of
-    PKINIT for each principal and request.
-
-    The KDC is not required to contain a database record for users
-    that use either the Standard Public Key Authentication or Public Key
-    Authentication with a Digital Signature.  However, if these users
-    are registered with the KDC, it is recommended that the database
-    record for these users be modified to include three additional flags
-    in the attributes field.
-
-    The first flag, use_standard_pk_init, indicates that the user should
-    authenticate using standard PKINIT as described in Section 3.2.  The
-    second flag, use_digital_signature, indicates that the user should
-    authenticate using digital signature PKINIT as described in Section
-    3.3.  The third flag, store_private_key, indicates that the user
-    has stored his private key on the KDC and should retrieve it using
-    the exchange described in Section 3.4.
-
-    If one of the preauthentication fields defined above is included in
-    the request, then the KDC shall respond as described in Sections 3.2
-    through 3.4, ignoring the aforementioned database flags.  If more
-    than one of the preauthentication fields is present, the KDC shall
-    respond with an error of type KDC_ERR_PREAUTH_FAILED.
-
-    In the event that none of the preauthentication fields defined above
-    are included in the request, the KDC checks to see if any of the
-    above flags are set.  If the first flag is set, then it sends back
-    an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
-    preauthentication field of type PA-PK-AS-REQ must be included in the
-    request.
-
-    Otherwise, if the first flag is clear, but the second flag is set,
-    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
-    indicating that a preauthentication field of type PA-PK-AS-SIGN must
-    be included in the request.
-
-    Lastly, if the first two flags are clear, but the third flag is set,
-    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
-    indicating that a preauthentication field of type PA-PK-KEY-REQ must
-    be included in the request.
-
-
-5.  Security Considerations
-
-    PKINIT raises a few security considerations, which we will address
-    in this section.
-
-    First of all, PKINIT introduces a new trust model, where KDCs do not
-    (necessarily) certify the identity of those for whom they issue
-    tickets.  PKINIT does allow KDCs to act as their own CAs, in order
-    to simplify key management, but one of the additional benefits is to
-    align Kerberos authentication with a global public key
-    infrastructure.  Anyone using PKINIT in this way must be aware of
-    how the certification infrastructure they are linking to works.
-
-    Secondly, PKINIT also introduces the possibility of interactions
-    between different cryptosystems, which may be of widely varying
-    strengths.  Many systems, for instance, allow the use of 512-bit
-    public keys.  Using such keys to wrap data encrypted under strong
-    conventional cryptosystems, such as triple-DES, is inappropriate;
-    it adds a weak link to a strong one at extra cost.  Implementors
-    and administrators should take care to avoid such wasteful and
-    deceptive interactions.
-
-
-5.  Transport Issues
-
-    Certificate chains can potentially grow quite large and span several
-    UDP packets; this in turn increases the probability that a Kerberos
-    message involving PKINIT extensions will be broken in transit.  In
-    light of the possibility that the Kerberos specification will
-    require KDCs to accept requests using TCP as a transport mechanism,
-    we make the same recommendation with respect to the PKINIT
-    extensions as well.
-
-
-6.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-    (V5).  Request for Comments 1510.
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.  September
-    1994.
-
-    [3] A. Medvinsky, M. Hur.  Addition of Kerberos Cipher Suites to
-    Transport Layer Security (TLS).
-    draft-ietf-tls-kerb-cipher-suites-00.txt
-
-    [4] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
-    Tickets for Application Servers (PKTAPP).
-    draft-ietf-cat-pktapp-00.txt
-
-    [5] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-    Using Public Key Cryptography.  Symposium On Network and Distributed
-    System Security, 1997.
-
-    [6] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction 
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic
-    Commerce, July 1995.
-
-    [7] Alan O. Freier, Philip Karlton and Paul C. Kocher.  The SSL
-    Protocol, Version 3.0 - IETF Draft. 
-
-    [8] B.C. Neuman, Proxy-Based Authorization and Accounting for 
-    Distributed Systems.  In Proceedings of the 13th International 
-    Conference on Distributed Computing Systems, May 1993.
-
-    [9] ITU-T (formerly CCITT) Information technology - Open Systems
-    Interconnection - The Directory: Authentication Framework
-    Recommendation X.509 ISO/IEC 9594-8
-
-
-7.  Acknowledgements
-
-    Sasha Medvinsky contributed several ideas to the protocol changes
-    and specifications in this document.  His additions have been most
-    appreciated.
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-
-8.  Expiration Date
-
-    This draft expires September 15, 1998.
-
-
-9.  Authors
-
-    Brian Tung
-    Clifford Neuman
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {brian, bcn}@isi.edu
-
-    John Wray
-    Digital Equipment Corporation
-    550 King Street, LKG2-2/Z7
-    Littleton, MA 01460
-    Phone: +1 508 486 5210
-    E-mail: wray@tuxedo.enet.dec.com
-
-    Ari Medvinsky
-    Matthew Hur
-    CyberSafe Corporation
-    1605 NW Sammamish Road Suite 310
-    Issaquah WA 98027-5378
-    Phone: +1 206 391 6000
-    E-mail: {ari.medvinsky, matt.hur}@cybersafe.com
-
-    Jonathan Trostle
-    Novell Corporation
-    Provo UT
-    E-mail: jtrostle@novell.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-07.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-07.txt
deleted file mode 100644
index 9609440b9..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-07.txt
+++ /dev/null
@@ -1,1181 +0,0 @@
-INTERNET-DRAFT                                              Brian Tung
-draft-ietf-cat-kerberos-pk-init-07.txt                 Clifford Neuman
-Updates: RFC 1510                                                  ISI
-expires May 15, 1999                                         John Wray
-                                         Digital Equipment Corporation
-                                                         Ari Medvinsky
-                                                           Matthew Hur
-                                                       Sasha Medvinsky
-                                                 CyberSafe Corporation
-                                                      Jonathan Trostle
-                                                                 Cisco
-
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-
-0.  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 learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ftp.ietf.org (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-07.txt, and expires May 15, 1999.
-    Please send comments to the authors.
-
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510 [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to associate a key pair with each realm, which can
-    then be used to facilitate cross-realm authentication; this is the
-    topic of another draft proposal.  Another way is to allow users with
-    public key certificates to use them in initial authentication.  This
-    is the concern of the current document.
-
-    One of the guiding principles in the design of PKINIT is that
-    changes should be as minimal as possible.  As a result, the basic
-    mechanism of PKINIT is as follows:  The user sends a request to the
-    KDC as before, except that if that user is to use public key
-    cryptography in the initial authentication step, his certificate
-    accompanies the initial request, in the preauthentication fields.
-
-    Upon receipt of this request, the KDC verifies the certificate and
-    issues a ticket granting ticket (TGT) as before, except that
-    the encPart from the AS-REP message carrying the TGT is now
-    encrypted in a randomly-generated key, instead of the user's
-    long-term key (which is derived from a password).  This
-    random key is in turn encrypted using the public key from the
-    certificate that came with the request and signed using the KDC's
-    private key, and accompanies the reply, in the preauthentication
-    fields.
-
-    PKINIT also allows for users with only digital signature keys to
-    authenticate using those keys, and for users to store and retrieve
-    private keys on the KDC.
-
-    The PKINIT specification may also be used as a building block for
-    other specifications.  PKCROSS [3] utilizes PKINIT for establishing
-    the inter-realm key and associated inter-realm policy to be applied
-    in issuing cross realm service tickets.  As specified in [4], anonymous
-    Kerberos tickets can be issued by applying a NULL signature in
-    combination with Diffie-Hellman in the PKINIT exchange.  Additionally,
-    The PKINIT specification may be used for direct peer to peer
-    authentication without contacting a central KDC. This application
-    of PKINIT is described in PKTAPP [5] and is based on concepts
-    introduced in [6, 7]. For direct client-to-server authentication,
-    the client uses PKINIT to authenticate to the end server (instead
-    of a central KDC), which then issues a ticket for itself.  This
-    approach has an advantage over SSL [8] in that the server does not
-    need to save state (cache session keys).  Furthermore, an
-    additional benefit is that Kerberos tickets can facilitate
-    delegation (see [9]).
-
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510 for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following changes to RFC 1510 are proposed:
-
-        * Users may authenticate using either a public key pair or a
-          conventional (symmetric) key.  If public key cryptography is
-          used, public key data is transported in preauthentication
-          data fields to help establish identity.
-        * Users may store private keys on the KDC for retrieval during
-          Kerberos initial authentication.
-
-    This proposal addresses two ways that users may use public key
-    cryptography for initial authentication.  Users may present public
-    key certificates, or they may generate their own session key,
-    signed by their digital signature key.  In either case, the end
-    result is that the user obtains an ordinary TGT that may be used for
-    subsequent authentication, with such authentication using only
-    conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 and 3.3 describe the extensions for the two initial
-    authentication methods.  Section 3.4 describes a way for the user to
-    store and retrieve his private key on the KDC, as an adjunct to the
-    initial authentication.
-
-
-3.1.  Definitions
-
-    The extensions involve new preauthentication fields; we propose the
-    addition of the following types:
-
-        PA-PK-AS-REQ                            14
-        PA-PK-AS-REP                            15
-        PA-PK-AS-SIGN                           16
-        PA-PK-KEY-REQ                           17
-        PA-PK-KEY-REP                           18
-
-    The extensions also involve new error types; we propose the addition
-    of the following types:
-
-        KDC_ERR_CLIENT_NOT_TRUSTED              62
-        KDC_ERR_KDC_NOT_TRUSTED                 63
-        KDC_ERR_INVALID_SIG                     64
-        KDC_ERR_KEY_TOO_WEAK                    65
-        KDC_ERR_CERTIFICATE_MISMATCH            66
-
-    In many cases, PKINIT requires the encoding of an X.500 name as a
-    Realm.  In these cases, the realm will be represented using a
-    different style, specified in RFC 1510 with the following example:
-
-        NAMETYPE:rest/of.name=without-restrictions
-
-    For a realm derived from an X.500 name, NAMETYPE will have the value
-    X500-RFC2253.  The full realm name will appear as follows:
-
-        X500-RFC2253:RFC2253Encode(DistinguishedName)
-
-    where DistinguishedName is an X.500 name, and RFC2253Encode is a
-    readable ASCII encoding of an X.500 name, as defined by
-    RFC 2253 [14] (part of LDAPv3). (RFC 2253 obsoleted RFC 1779, which
-    is not supported by this version of PKINIT.)
-
-    To ensure that this encoding is unique, we add the following rule
-    to those specified by RFC 2253:
-
-        The order in which the attributes appear in the RFC 2253
-        encoding must be the reverse of the order in the ASN.1
-        encoding of the X.500 name that appears in the public key
-        certificate. The order of the relative distinguished names
-        (RDNs), as well as the order of the AttributeTypeAndValues
-        within each RDN, will be reversed. (This is despite the fact
-        that an RDN is defined as a SET of AttributeTypeAndValues, where
-        an order is normally not important.)
-
-    Similarly, PKINIT may require the encoding of an X.500 name as a
-    PrincipalName.  In these cases, the name-type of the principal name
-    shall be set to NT-X500-PRINCIPAL.  This new name type is defined
-    as:
-
-        #define CSFC5c_NT_X500_PRINCIPAL    6
-
-    The name-string shall be set as follows:
-
-        RFC2253Encode(DistinguishedName)
-
-    as described above.
-
-
-3.1.1.  Encryption and Key Formats
-
-    In the exposition below, we use the terms public key and private
-    key generically.  It should be understood that the term "public
-    key" may be used to refer to either a public encryption key or a
-    signature verification key, and that the term "private key" may be
-    used to refer to either a private decryption key or a signature
-    generation key.  The fact that these are logically distinct does
-    not preclude the assignment of bitwise identical keys.
-
-    All additional symmetric keys specified in this draft shall use the
-    same encryption type as the session key in the response from the
-    KDC.  These include the temporary keys used to encrypt the signed
-    random key encrypting the response, as well as the key derived from
-    Diffie-Hellman agreement.  In the case of Diffie-Hellman, the key
-    shall be produced from the agreed bit string as follows:
-
-        * Truncate the bit string to the appropriate length.
-        * Rectify parity in each byte (if necessary) to obtain the key.
-
-    For instance, in the case of a DES key, we take the first eight
-    bytes of the bit stream, and then adjust the least significant bit
-    of each byte to ensure that each byte has odd parity.
-
-
-3.1.2. Algorithm Identifiers
-
-    PKINIT does not define, but does permit, the algorithm identifiers
-    listed below.
-
-3.1.2.1. Signature Algorithm Identifiers
-
-    These are the algorithm identifiers for use in the Signature data
-    structure:
-  
-    sha-1WithRSAEncryption ALGORITHM PARAMETER NULL
-         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-               pkcs-1(1) 5 }
-    
-    dsaWithSHA1 ALGORITHM PARAMETER NULL
-         ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
-               oIWSecAlgorithm(2) dsaWithSHA1(27) }
-    
-    md4WithRsaEncryption ALGORITHM PARAMETER NULL
-         ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
-               oIWSecAlgorithm(2) md4WithRSAEncryption(4) }
-    
-    md5WithRSAEncryption ALGORITHM PARAMETER NULL
-         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-               pkcs-1(1) md5WithRSAEncryption(4) }
-
-
-3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
-
-    This algorithm identifier is used inside the SubjectPublicKeyInfo
-    data structure:
-
-    dhKeyAgreement ALGORITHM PARAMETER DHParameters
-         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-               pkcs-3(3) dhKeyAgreement(1) }
-
-    DHParameters ::= SEQUENCE {
-        prime                       INTEGER,
-                                    -- p
-        base                        INTEGER,
-                                    -- g
-        privateValueLength          INTEGER OPTIONAL
-    }   -- as specified by the X.509 recommendation [9]
-
-
-3.1.2.3. Algorithm Identifiers for RSA Encryption
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure, for encrypting the temporary key with a public key:
-
-    rsaEncryption ALGORITHM PARAMETER NULL
-         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-               pkcs-1(1) rsaEncryption(1)
-
-
-3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure, for encrypting the temporary key with a Diffie-Hellman-
-    derived key, or for encrypting the reply key:
-
-    desCBC ALGORITHM PARAMETER IV8
-         ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
-               oIWSecAlgorithm(2) desCBC(7) }
-
-    DES-EDE3-CBC ALGORITHM PARAMETER IV8
-         ::= { iso(1) member-body(2) US(840) rsadsi(113549)
-               encryptionAlgorithm(3) desEDE3(7) }
-
-    IV8 ::= OCTET STRING (SIZE(8))        -- initialization vector
-
-    rc2CBC ALGORITHM PARAMETER RC2-CBCParameter
-         ::= { iso(1) member-body(2) US(840) rsadsi(113549)
-               encryptionAlgorithm(3) rc2CBC(2) }
-
-    The rc2CBC algorithm parameters (RC2-CBCParameter) are defined
-    in the following section.
-
-    rc4 ALGORITHM PARAMETER NULL
-         ::= { iso(1) member-body(2) US(840) rsadsi(113549)
-               encryptionAlgorithm(3) rc4(4) }
-
-    The rc4 algorithm cannot be used with the Diffie-Hellman-derived
-    keys, because its parameters do not specify the size of the key.
-
-
-3.1.2.5. rc2CBC Algorithm Parameters
-
-    This definition of the RC2 parameters is taken from a paper by
-    Ron Rivest [13]. Refer to [13] for the complete description of the
-    RC2 algorithm.
-
-    RC2-CBCParameter ::= CHOICE {
-        iv IV,
-        params SEQUENCE {
-            version RC2Version,
-            iv IV
-        }
-    }
-
-    where
-
-    IV ::= OCTET STRING -- 8 octets
-    RC2Version ::= INTEGER -- 1-1024
-
-    RC2 in CBC mode has two parameters: an 8-byte initialization 
-    vector (IV) and a version number in the range 1-1024 which 
-    specifies in a roundabout manner the number of effective key bits 
-    to be used for the RC2 encryption/decryption.
-
-    The correspondence between effective key bits and version number 
-    is as follows:
-
-    1. If the number EKB of effective key bits is in the range 1-255, 
-       then the version number is given by Table[EKB], where the 
-       256-byte translation table is specified below. It specifies a
-       permutation on the numbers 0-255.
-
-    2. If the number EKB of effective key bits is in the range 
-       256-1024, then the version number is simply EKB.
-
-       The default number of effective key bits for RC2 is 32.  
-       If RC2-CBC is being performed with 32 effective key bits, the 
-       parameters should be supplied as a simple IV, rather than as a
-       SEQUENCE containing a version and an IV.
-
-         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
-
-    00: bd 56 ea f2 a2 f1 ac 2a b0 93 d1 9c 1b 33 fd d0
-    10: 30 04 b6 dc 7d df 32 4b f7 cb 45 9b 31 bb 21 5a
-    20: 41 9f e1 d9 4a 4d 9e da a0 68 2c c3 27 5f 80 36
-    30: 3e ee fb 95 1a fe ce a8 34 a9 13 f0 a6 3f d8 0c
-    40: 78 24 af 23 52 c1 67 17 f5 66 90 e7 e8 07 b8 60
-    50: 48 e6 1e 53 f3 92 a4 72 8c 08 15 6e 86 00 84 fa
-    60: f4 7f 8a 42 19 f6 db cd 14 8d 50 12 ba 3c 06 4e
-    70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf
-    80: 3a de 96 0e bc 0a ed 77 fc 37 6b 03 79 89 62 c6
-    90: d7 c0 d2 7c 6a 8b 22 a3 5b 05 5d 02 75 d5 61 e3
-    a0: 18 8f 55 51 ad 1f 0b 5e 85 e5 c2 57 63 ca 3d 6c
-    b0: b4 c5 cc 70 b2 91 59 0d 47 20 c8 4f 58 e0 01 e2
-    c0: 16 38 c4 6f 3b 0f 65 46 be 7e 2d 7b 82 f9 40 b5
-    d0: 1d 73 f8 eb 26 c7 87 97 25 54 b1 28 aa 98 9d a5
-    e0: 64 6d 7a d4 10 81 44 ef 49 d6 ae 2e dd 76 5c 2f
-    f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab
-
-    
-3.2.  Standard Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with PKINIT.
-
-    It is assumed that all public keys are signed by some certification
-    authority (CA).  The initial authentication request is sent as per
-    RFC 1510, except that a preauthentication field containing data
-    signed by the user's private key accompanies the request:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                -- PA TYPE 14
-        signedAuthPack          [0] SignedAuthPack
-        userCert                [1] SEQUENCE OF Certificate OPTIONAL,
-                                    -- the user's certificate chain;
-				    -- if present, the KDC must use
-				    -- the public key from this
-				    -- particular certificate chain to
-				    -- verify the signature in the
-				    -- request
-        trustedCertifiers       [2] SEQUENCE OF PrincipalName OPTIONAL,
-                                    -- CAs that the client trusts
-        serialNumber            [3] CertificateSerialNumber OPTIONAL
-                                    -- specifying a particular KDC
-                                    -- certificate if the client
-                                    -- already has it;
-                                    -- must be accompanied by
-                                    -- a single trustedCertifier
-    }
-
-    CertificateSerialNumber ::= INTEGER
-                                -- as specified by PKCS #6 [15]
-
-    SignedAuthPack ::= SEQUENCE {
-        authPack                [0] AuthPack,
-        authPackSig             [1] Signature,
-                                    -- of authPack
-                                    -- using user's private key
-    }
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- if client is using Diffie-Hellman
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        kdcName                 [0] PrincipalName,
-        kdcRealm                [1] Realm,
-        cusec                   [2] INTEGER,
-                                    -- for replay prevention
-        ctime                   [3] KerberosTime,
-                                    -- for replay prevention
-        nonce                   [4] INTEGER
-    }
-
-    Signature ::= SEQUENCE {
-        signatureAlgorithm      [0] SignatureAlgorithmIdentifier,
-        pkcsSignature           [1] BIT STRING
-                                    -- octet-aligned big-endian bit
-                                    -- string (encrypted with signer's
-                                    -- private key)
-    }
-
-    SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
-
-    AlgorithmIdentifier ::= SEQUENCE {
-        algorithm                   ALGORITHM.&id,
-        parameters                  ALGORITHM.&type 
-    }   -- as specified by the X.509 recommendation [10]
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm                   AlgorithmIdentifier,
-                                    -- dhKeyAgreement
-        subjectPublicKey            BIT STRING
-                                    -- for DH, equals
-                                    -- public exponent (INTEGER encoded
-                                    -- as payload of BIT STRING)
-    }   -- as specified by the X.509 recommendation [9]
-
-    Certificate ::= SEQUENCE {
-        certType                [0] INTEGER,
-                                    -- type of certificate
-                                    -- 1 = X.509v3 (DER encoding)
-                                    -- 2 = PGP (per PGP specification)
-                                    -- 3 = PKIX (per PKCS #6 [15])
-        certData                [1] OCTET STRING
-                                    -- actual certificate
-                                    -- type determined by certType
-    }
-
-    If the client passes a certificate serial number in the request,
-    the KDC is requested to use the referred-to certificate.  If none
-    exists, then the KDC returns an error of type
-    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
-    other hand, the client does not pass any trustedCertifiers,
-    believing that it has the KDC's certificate, but the KDC has more
-    than one certificate.
-
-    The PKAuthenticator carries information to foil replay attacks,
-    to bind the request and response, and to optionally pass the
-    client's Diffie-Hellman public value (i.e. for using DSA in
-    combination with Diffie-Hellman).  The PKAuthenticator is signed
-    with the private key corresponding to the public key in the
-    certificate found in userCert (or cached by the KDC).
-
-    The userCert field is a sequence of certificates, the first of which
-    must be the user's public key certificate. Any subsequent
-    certificates will be certificates of the certifiers of the user's
-    certificate.  These cerificates may be used by the KDC to verify the
-    user's public key.  This field may be left empty if the KDC already
-    has the user's certificate.
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.  If the KDC has no
-    certificate signed by any of the trustedCertifiers, then it returns
-    an error of type KDC_ERR_CERTIFICATE_MISMATCH.
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.  This may be based on a certification
-    hierarchy, or it may be simply a list of recognized certifiers in a
-    system like PGP.
-
-    If verification of the user's certificate fails, the KDC sends back
-    an error message of type KDC_ERR_CLIENT_NOT_TRUSTED.  The e-data
-    field contains additional information pertaining to this error, and
-    is formatted as follows:
-
-        METHOD-DATA ::= SEQUENCE {
-            method-type         [0] INTEGER,
-                                    -- 1 = cannot verify public key
-                                    -- 2 = invalid certificate
-                                    -- 3 = revoked certificate
-                                    -- 4 = invalid KDC name
-                                    -- 5 = client name mismatch
-            method-data         [1] OCTET STRING OPTIONAL
-        } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
-
-    The values for the method-type and method-data fields are described
-    in Section 3.2.1.
-
-    If trustedCertifiers is provided in the PA-PK-AS-REQ, the KDC
-    verifies that it has a certificate issued by one of the certifiers
-    trusted by the client.  If it does not have a suitable certificate,
-    the KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to
-    the client. 
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on AuthPack.  If that fails, the KDC returns an error
-    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
-    timestamp in the PKAuthenticator to assure that the request is not a
-    replay.   The KDC also verifies that its name is specified in the
-    PKAuthenticator.
-
-    If the clientPublicValue field is filled in, indicating that the
-    client wishes to use Diffie-Hellman key agreement, then the KDC
-    checks to see that the parameters satisfy its policy.  If they do
-    not (e.g., the prime size is insufficient for the expected
-    encryption type), then the KDC sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
-    private values for the response.
-
-    The KDC also checks that the timestamp in the PKAuthenticator is
-    within the allowable window.  If the local (server) time and the
-    client time in the authenticator differ by more than the allowable
-    clock skew, then the KDC returns an error message of type
-    KRB_AP_ERR_SKEW.
-
-    Assuming no errors, the KDC replies as per RFC 1510, except as
-    follows.  The user's name in the ticket is determined by the
-    following decision algorithm:
-
-        1.  If the KDC has a mapping from the name in the certificate
-            to a Kerberos name, then use that name.  Else
-        2.  If the certificate contains a Kerberos name in an extension
-            field, and local KDC policy allows, then use that name.
-            Else
-        3.  Use the name as represented in the certificate, mapping
-            as necessary (e.g., as per RFC 2253 for X.500 names).  In
-            this case the realm in the ticket shall be the name of the
-            certification authority that issued the user's certificate.
-
-    The KDC encrypts the reply not with the user's long-term key, but
-    with a random key generated only for this particular response.  This
-    random key is sealed in the preauthentication field:
-
-    PA-PK-AS-REP ::= SEQUENCE {
-                                -- PA TYPE 15
-        encKeyPack		[1] EnvelopedKeyPack,
-                                    -- temporary key is encrypted
-                                    -- using either the client public
-                                    -- key or the Diffie-Hellman key
-                                    -- specified by SignedKDCPublicValue.
-				    -- SignedReplyKeyPack, encrypted
-				    -- with the temporary key, is also
-				    -- included.
-        signedKDCPublicValue    [2] SignedKDCPublicValue OPTIONAL,
-                                    -- if one was passed in the request
-        kdcCert                 [3] SEQUENCE OF Certificate OPTIONAL
-                                    -- the KDC's certificate chain
-    }
-  
-        
-    The EnvelopedKeyPack data type below contains an encrypted
-    temporary key (either with the PKINIT client's public key or with a
-    symmetric key, resulting from the Diffie-Hellman exchange). It also
-    contains a signed and encrypted reply key. This data structure is
-    similar to EnvelopedData, defined in CMS [11] and PKCS #7 [12].
-    
-    EnvelopedKeyPack ::= SEQUENCE {
-        version                     Version,
-                                    -- Always set to 0.
-        recipientInfos              RecipientInfos,
-                                    -- This is a SET, which must contain
-                                    -- exactly one member. Contains a
-                                    -- temporary key, encrypted with the
-                                    -- client's public key. This
-				    -- temporary key is used to encrypt
-				    -- the reply key.
-        encryptedContentInfo        EncryptedContentInfo
-                                    -- contains the signed and encrypted
-				    -- reply key
-    }
-
-    Version ::= INTEGER
-
-    RecipientInfos ::= SET OF RecipientInfo
-
-    RecipientInfo ::= SEQUENCE {
-        version                     Version,
-                                    -- shall be 0
-        rid                         RecipientIdentifier,
-                                    -- Since this is an optional field, 
-				    -- it supports both CMS and PKCS #7
-        keyEncryptionAlgorithm      KeyEncryptionAlgorithmIdentifier,
-        EncryptedKey                OCTET STRING
-                                    -- the temporary key, encrypted with
-                                    -- the PKINIT client's public key        
-    }
-
-    KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
-
-    RecipientIdentifier ::= IssuerAndSerialNumber
-                            -- Corresponds to the X.509 V3 extension
-                            -- SubjectKeyIdentifier.
-
-    IssuerAndSerialNumber ::= SEQUENCE {
-	issuer			Name,
-				    -- a distinguished name, as defined
-				    -- by X.509
-	serialNumber		CertificateSerialNumber
-    }
-
-    CertificateSerialNumber ::= INTEGER
-	
-    EncryptedContentInfo ::= SEQUENCE {
-	contentType		ContentType,
-				    -- shall be:
-				    -- 	iso(1) member-body(2) us(840)
-				    --  rsadsi(113549) pkcs(1) pkcs7(7)
-				    --  EnvelopedData(3)
-	contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier
-				    -- Algorithm used to encrypt the
-				    -- SignedReplyKeyPack.
-        encryptedContent           OCTET STRING
-				    -- The encrypted data is of the type
-				    -- SignedReplyKeyPack.
-    }
-
-    ContentType ::= OBJECT IDENTIFIER
-
-    ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
-
-    SignedReplyKeyPack ::= SEQUENCE {
-        replyKeyPack            [0] ReplyKeyPack,
-        replyKeyPackSig         [1] Signature,
-                                    -- of replyKeyPack
-                                    -- using KDC's private key
-    }
-
-    ReplyKeyPack ::= SEQUENCE {
-        replyKey                [0] EncryptionKey,
-                                    -- used to encrypt main reply
-                                    -- of same ENCTYPE as session key
-        nonce                   [1] INTEGER
-                                    -- binds response to the request
-                                    -- must be same as the nonce
-                                    -- passed in the PKAuthenticator
-    }
-       
-    SignedKDCPublicValue ::= SEQUENCE {
-        kdcPublicValue          [0] SubjectPublicKeyInfo,
-                                    -- as described above
-        kdcPublicValueSig       [1] Signature
-                                    -- of kdcPublicValue
-                                    -- using KDC's private key
-    }
-
-
-    The kdcCert field is a sequence of certificates, the first of which
-    must be the KDC's public key certificate.  Any subsequent
-    certificates will be certificates of the certifiers of the KDC's
-    certificate.  The last of these must have as its certifier one of
-    the certifiers sent to the KDC in the PA-PK-AS-REQ.  These
-    cerificates may be used by the client to verify the KDC's public
-    key.  This field is empty if the client did not send to the KDC a
-    list of trusted certifiers (the trustedCertifiers field was empty).
-    
-    Since each certifier in the certification path of a user's
-    certificate is essentially a separate realm, the name of each
-    certifier shall be added to the transited field of the ticket.  The
-    format of these realm names is defined in Section 3.1 of this
-    document.  If applicable, the transit-policy-checked flag should be
-    set in the issued ticket.
-
-    The KDC's certificate must bind the public key to a name derivable
-    from the name of the realm for that KDC.  X.509 certificates shall
-    contain the principal name of the KDC as the SubjectAltName version
-    3 extension. Below is the definition of this version 3 extension, as
-    specified by the X.509 standard:
-
-	subjectAltName EXTENSION ::= {
-	    SYNTAX GeneralNames
-	    IDENTIFIED BY id-ce-subjectAltName
-	}
-
-	GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
-
-	GeneralName ::= CHOICE {
-	    otherName 	    [0] INSTANCE OF OTHER-NAME,
-	    ...
-	}
-
-	OTHER-NAME ::= TYPE-IDENTIFIER
-
-    In this definition, otherName is a name of any form defined as an
-    instance of the OTHER-NAME information object class. For the purpose
-    of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
-    be replaced by the type KerberosPrincipalName:
-
-	KerberosPrincipalName ::= SEQUENCE {
-            nameType        [0] OTHER-NAME.&id ( { PrincipalNameTypes } ),
-            name            [1] OTHER-NAME.&type ( { PrincipalNameTypes }
-                               { @nameType } )
-        }
-
-        PrincipalNameTypes OTHER-NAME ::= {
-            { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
-        }  
-
-        PrincipalNameSrvInst ::= GeneralString
-
-    where (from the Kerberos specification) we have
-
-        krb5 OBJECT IDENTIFIER ::= { iso (1)
-                                     org (3)
-                                     dod (6)
-                                     internet (1)
-                                     security (5)
-                                     kerberosv5 (2) }
-
-        principalName OBJECT IDENTIFIER ::= { krb5 2 }
-
-        principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }
-
-    (This specification can also be used to specify a Kerberos name
-    within the user's certificate.)
-
-    The client then extracts the random key used to encrypt the main
-    reply.  This random key (in encPaReply) is encrypted with either the
-    client's public key or with a key derived from the DH values
-    exchanged between the client and the KDC.
-
-
-3.2.1.  Additional Information for Errors
-
-    This section describes the interpretation of the method-type and
-    method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
-
-    If method-type=1, the client's public key certificate chain does not
-    contain a certificate that is signed by a certification authority
-    trusted by the KDC.  The format of the method-data field will be an
-    ASN.1 encoding of a list of trusted certifiers, as defined above:
-
-        TrustedCertifiers ::= SEQUENCE OF PrincipalName
-
-    If method-type=2, the signature on one of the certificates in the
-    chain cannot be verified.  The format of the method-data field will
-    be an ASN.1 encoding of the integer index of the certificate in
-    question:
-
-        CertificateIndex ::= INTEGER
-                             -- 0 = 1st certificate,
-                             -- 1 = 2nd certificate, etc
-
-    If method-type=3, one of the certificates in the chain has been
-    revoked.  The format of the method-data field will be an ASN.1
-    encoding of the integer index of the certificate in question:
-
-        CertificateIndex ::= INTEGER
-                             -- 0 = 1st certificate,
-                             -- 1 = 2nd certificate, etc
-
-    If method-type=4, the KDC name or realm in the PKAuthenticator does
-    not match the principal name of the KDC.  There is no method-data
-    field in this case.
-
-    If method-type=5, the client name or realm in the certificate does
-    not match the principal name of the client.  There is no
-    method-data field in this case.
-
-
-3.2.2. Required Algorithms and Data Formats
-
-    Not all of the algorithms in the PKINIT protocol specification have
-    to be implemented in order to comply with the proposed standard.
-    Below is a list of the required algorithms and data formats:
-
-	- Diffie-Hellman public/private key pairs
-	- SHA1 digest and DSA for signatures
-	- X.509 version 3 certificates
-	- 3-key triple DES keys derived from the Diffie-Hellman Exchange
-	- 3-key triple DES Temporary and Reply keys
-
-	
-3.3.  Digital Signature
-
-    Implementation of the changes in this section are OPTIONAL for
-    compliance with PKINIT.
-
-    We offer this option with the warning that it requires the client to
-    generate a random key; the client may not be able to guarantee the
-    same level of randomness as the KDC.
-
-    If the user registered, or presents a certificate for, a digital
-    signature key with the KDC instead of an encryption key, then a
-    separate exchange must be used.  The client sends a request for a
-    TGT as usual, except that it (rather than the KDC) generates the
-    random key that will be used to encrypt the KDC response.  This key
-    is sent to the KDC along with the request in a preauthentication
-    field, encrypted with the KDC's public key:
-
-    PA-PK-AS-SIGN ::= SEQUENCE {
-                                -- PA TYPE 16
-        encKeyPack		[1] EnvelopedKeyPack,
-                                    -- temporary key is encrypted
-                                    -- using the KDC public
-                                    -- key.
-				    -- SignedRandomKeyPack, encrypted
-				    -- with the temporary key, is also
-				    -- included.
-        userCert                [2] SEQUENCE OF Certificate OPTIONAL
-                                    -- the user's certificate chain;
-				    -- if present, the KDC must use
-				    -- the public key from this
-				    -- particular certificate chain to
-				    -- verify the signature in the
-				    -- request
-    }
-
-    In the above message, the content of the encKeyPack is similar to
-    the content of the encKeyPack field in the PA-PK-AS-REP message,
-    except that it is the KDC's public key and not the client's public
-    key that is used to encrypt the temporary key. And, the
-    encryptedContentInfo field inside the EnvelopedKeyPack contains
-    encrypted data of the type SignedRandomKeyPack instead of the
-    SignedReplyKeyPack.
-
-    SignedRandomKeyPack ::= SEQUENCE {
-        randomkeyPack           [0] RandomKeyPack,
-        randomkeyPackSig        [1] Signature
-                                    -- of keyPack
-                                    -- using user's private key
-    }
-
-    RandomKeyPack ::= SEQUENCE {
-        randomKey               [0] EncryptionKey,
-                                    -- will be used to encrypt reply
-        randomKeyAuth           [1] PKAuthenticator
-    }
-
-    If the KDC does not accept client-generated random keys as a matter
-    of policy, then it sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it extracts the random key as
-    follows.
-
-    Upon receipt of the PA-PK-AS-SIGN, the KDC decrypts then verifies
-    the randomKey.  It then replies as per RFC 1510, except that the
-    reply is encrypted not with a password-derived user key, but with
-    the randomKey sent in the request.  Since the client already knows
-    this key, there is no need to accompany the reply with an extra
-    preauthentication field.  The transited field of the ticket should
-    specify the certification path as described in Section 3.2.
-
-
-3.4.  Retrieving the User's Private Key from the KDC
-
-    Implementation of the changes described in this section are OPTIONAL
-    for compliance with PKINIT.  (This section may or may not fall under
-    the purview of a patent for private key storage; please see Section
-    8 for more information.)
-
-    When the user's private key is not stored local to the user, he may
-    choose to store the private key (normally encrypted using a
-    password-derived key) on the KDC.  In this case, the client makes a
-    request as described above, except that instead of preauthenticating
-    with his private key, he uses a symmetric key shared with the KDC.
-
-    For simplicity's sake, this shared key is derived from the password-
-    derived key used to encrypt the private key, in such a way that the
-    KDC can authenticate the user with the shared key without being able
-    to extract the private key.
-
-    We provide this option to present the user with an alternative to
-    storing the private key on local disk at each machine where he
-    expects to authenticate himself using PKINIT.  It should be noted
-    that it replaces the added risk of long-term storage of the private
-    key on possibly many workstations with the added risk of storing the
-    private key on the KDC in a form vulnerable to brute-force attack.
-
-    Denote by K1 the symmetric key used to encrypt the private key.
-    Then construct symmetric key K2 as follows:
-
-        * Perform a hash on K1.
-        * Truncate the digest to Length(K1) bytes.
-        * Rectify parity in each byte (if necessary) to obtain K2.
-
-    The KDC stores K2, the public key, and the encrypted private key.
-    This key pair is designated as the "primary" key pair for that user.
-    This primary key pair is the one used to perform initial
-    authentication using the PA-PK-AS-REP preauthentication field.  If
-    he desires, he may also store additional key pairs on the KDC; these
-    may be requested in addition to the primary.  When the client
-    requests initial authentication using public key cryptography, it
-    must then include in its request, instead of a PA-PK-AS-REQ, the
-    following preauthentication sequence:
-
-    PA-PK-KEY-REQ ::= SEQUENCE {
-                                -- PA TYPE 17
-        signedPKAuth            [0] SignedPKAuth,
-        trustedCertifiers       [1] SEQUENCE OF PrincipalName OPTIONAL,
-                                    -- CAs that the client trusts
-        keyIDList               [2] SEQUENCE OF Checksum OPTIONAL
-                                    -- payload is hash of public key
-                                    -- corresponding to desired
-                                    -- private key
-                                    -- if absent, KDC will return all
-                                    -- stored private keys
-    }
-
-    Checksum ::= SEQUENCE {
-        cksumtype               [0] INTEGER,
-        checksum                [1] OCTET STRING
-    }   -- as specified by RFC 1510
-
-    SignedPKAuth ::= SEQUENCE {
-        pkAuth                  [0] PKAuthenticator,
-        pkAuthSig               [1] Signature
-                                    -- of pkAuth
-                                    -- using the symmetric key K2
-    }
-
-    If a keyIDList is present, the first identifier should indicate
-    the primary private key.  No public key certificate is required,
-    since the KDC stores the public key along with the private key.
-    If there is no keyIDList, all the user's private keys are returned.
-
-    Upon receipt, the KDC verifies the signature using K2.  If the
-    verification fails, the KDC sends back an error of type
-    KDC_ERR_INVALID_SIG.  If the signature verifies, but the requested
-    keys are not found on the KDC, then the KDC sends back an error of
-    type KDC_ERR_PREAUTH_FAILED.  If all checks out, the KDC responds as
-    described in Section 3.2, except that in addition, the KDC appends
-    the following preauthentication sequence:
-
-    PA-PK-KEY-REP ::= SEQUENCE {
-                                -- PA TYPE 18
-        encKeyRep               [0] EncryptedData
-                                    -- of type EncKeyReply
-                                    -- using the symmetric key K2
-    }
-
-    EncKeyReply ::= SEQUENCE {
-        keyPackList             [0] SEQUENCE OF KeyPack,
-                                    -- the first KeyPair is
-                                    -- the primary key pair
-        nonce                   [1] INTEGER
-                                    -- binds reply to request
-                                    -- must be identical to the nonce
-                                    -- sent in the SignedAuthPack
-    }
-
-    KeyPack ::= SEQUENCE {
-        keyID                   [0] Checksum,
-        encPrivKey              [1] OCTET STRING
-    }
-
-    Upon receipt of the reply, the client extracts the encrypted private
-    keys (and may store them, at the client's option).  The primary
-    private key, which must be the first private key in the keyPack
-    SEQUENCE, is used to decrypt the random key in the PA-PK-AS-REP;
-    this key in turn is used to decrypt the main reply as described in
-    Section 3.2.
-
-
-4.  Logistics and Policy
-
-    This section describes a way to define the policy on the use of
-    PKINIT for each principal and request.
-
-    The KDC is not required to contain a database record for users
-    that use either the Standard Public Key Authentication or Public Key
-    Authentication with a Digital Signature.  However, if these users
-    are registered with the KDC, it is recommended that the database
-    record for these users be modified to include three additional flags
-    in the attributes field.
-
-    The first flag, use_standard_pk_init, indicates that the user should
-    authenticate using standard PKINIT as described in Section 3.2.  The
-    second flag, use_digital_signature, indicates that the user should
-    authenticate using digital signature PKINIT as described in Section
-    3.3.  The third flag, store_private_key, indicates that the user
-    has stored his private key on the KDC and should retrieve it using
-    the exchange described in Section 3.4.
-
-    If one of the preauthentication fields defined above is included in
-    the request, then the KDC shall respond as described in Sections 3.2
-    through 3.4, ignoring the aforementioned database flags.  If more
-    than one of the preauthentication fields is present, the KDC shall
-    respond with an error of type KDC_ERR_PREAUTH_FAILED.
-
-    In the event that none of the preauthentication fields defined above
-    are included in the request, the KDC checks to see if any of the
-    above flags are set.  If the first flag is set, then it sends back
-    an error of type KDC_ERR_PREAUTH_REQUIRED indicating that a
-    preauthentication field of type PA-PK-AS-REQ must be included in the
-    request.
-
-    Otherwise, if the first flag is clear, but the second flag is set,
-    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
-    indicating that a preauthentication field of type PA-PK-AS-SIGN must
-    be included in the request.
-
-    Lastly, if the first two flags are clear, but the third flag is set,
-    then the KDC sends back an error of type KDC_ERR_PREAUTH_REQUIRED
-    indicating that a preauthentication field of type PA-PK-KEY-REQ must
-    be included in the request.
-
-
-5.  Security Considerations
-
-    PKINIT raises a few security considerations, which we will address
-    in this section.
-
-    First of all, PKINIT introduces a new trust model, where KDCs do not
-    (necessarily) certify the identity of those for whom they issue
-    tickets.  PKINIT does allow KDCs to act as their own CAs, in order
-    to simplify key management, but one of the additional benefits is to
-    align Kerberos authentication with a global public key
-    infrastructure.  Anyone using PKINIT in this way must be aware of
-    how the certification infrastructure they are linking to works.
-
-    Secondly, PKINIT also introduces the possibility of interactions
-    between different cryptosystems, which may be of widely varying
-    strengths.  Many systems, for instance, allow the use of 512-bit
-    public keys.  Using such keys to wrap data encrypted under strong
-    conventional cryptosystems, such as triple-DES, is inappropriate;
-    it adds a weak link to a strong one at extra cost.  Implementors
-    and administrators should take care to avoid such wasteful and
-    deceptive interactions.
-
-    Lastly, PKINIT calls for randomly generated keys for conventional
-    cryptosystems.  Many such systems contain systematically "weak"
-    keys.  PKINIT implementations MUST avoid use of these keys, either
-    by discarding those keys when they are generated, or by fixing them
-    in some way (e.g., by XORing them with a given mask).  These
-    precautions vary from system to system; it is not our intention to
-    give an explicit recipe for them here.
-
-
-5.  Transport Issues
-
-    Certificate chains can potentially grow quite large and span several
-    UDP packets; this in turn increases the probability that a Kerberos
-    message involving PKINIT extensions will be broken in transit.  In
-    light of the possibility that the Kerberos specification will
-    require KDCs to accept requests using TCP as a transport mechanism,
-    we make the same recommendation with respect to the PKINIT
-    extensions as well.
-
-
-6.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-    (V5).  Request for Comments 1510.
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.  September
-    1994.
-
-    [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
-    A. Medvinsky, M. Hur.  Public Key Cryptography for Cross-Realm
-    Authentication in Kerberos.
-    draft-ietf-cat-kerberos-pk-cross-04.txt
-
-    [4] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
-    Kerberos.
-    draft-ietf-cat-kerberos-anoncred-00.txt
-
-    [5] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
-    Tickets for Application Servers (PKTAPP).
-    draft-ietf-cat-pktapp-00.txt
-
-    [6] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-    Using Public Key Cryptography.  Symposium On Network and Distributed
-    System Security, 1997.
-
-    [7] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction 
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic
-    Commerce, July 1995.
-
-    [8] Alan O. Freier, Philip Karlton and Paul C. Kocher.  The SSL
-    Protocol, Version 3.0 - IETF Draft. 
-
-    [9] B.C. Neuman, Proxy-Based Authorization and Accounting for 
-    Distributed Systems.  In Proceedings of the 13th International 
-    Conference on Distributed Computing Systems, May 1993.
-
-    [10] ITU-T (formerly CCITT) Information technology - Open Systems
-    Interconnection - The Directory: Authentication Framework
-    Recommendation X.509 ISO/IEC 9594-8
-
-    [11] R. Hously. Cryptographic Message Syntax. 
-    draft-ietf-smime-cms-04.txt, March 1998.
-
-    [12] PKCS #7: Cryptographic Message Syntax Standard,
-    An RSA Laboratories Technical Note Version 1.5
-    Revised November 1, 1993
-
-    [13] Ron Rivest, MIT Laboratory for Computer Science and
-    RSA Data Security, Inc. A Description of the RC2(r) Encryption
-    Algorithm, November 1997.
-
-    [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
-    Protocol (v3): UTF-8 String Representation of Distinguished Names.
-    Request for Comments 2253.
-
-    [15] PKCS #6: Cryptographic Message Syntax Standard,
-    An RSA Laboratories Technical Note Version 1.5
-    Revised November 1, 1993
-
-
-7.  Patent Issues
-
-    The private key storage and retrieval process described in Section
-    3.4 may be covered by U.S. Patent 5,418,854 (Charles Kaufman, Morrie
-    Gasser, Butler Lampson, Joseph Tardo, Kannan Alagappan, all then of
-    Digital Corporation).  At this time, inquiries into this patent are
-    inconclusive.  We solicit discussion from any party who can illuminate
-    the coverage of this particular patent.
-
-
-8.  Acknowledgements
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-
-9.  Expiration Date
-
-    This draft expires May 15, 1999.
-
-
-10. Authors
-
-    Brian Tung
-    Clifford Neuman
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {brian, bcn}@isi.edu
-
-    John Wray
-    Digital Equipment Corporation
-    550 King Street, LKG2-2/Z7
-    Littleton, MA 01460
-    Phone: +1 508 486 5210
-    E-mail: wray@tuxedo.enet.dec.com
-
-    Ari Medvinsky
-    Matthew Hur
-    Sasha Medvinsky
-    CyberSafe Corporation
-    1605 NW Sammamish Road Suite 310
-    Issaquah WA 98027-5378
-    Phone: +1 206 391 6000
-    E-mail: {ari.medvinsky, matt.hur, sasha.medvinsky}@cybersafe.com
-
-    Jonathan Trostle
-    170 W. Tasman Dr.
-    San Jose, CA 95134
-    E-mail: jtrostle@cisco.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-08.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-08.txt
deleted file mode 100644
index 51e252acf..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-08.txt
+++ /dev/null
@@ -1,944 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-08.txt                   Clifford Neuman
-Updates: RFC 1510                                                    ISI
-expires November 12, 1999                                    Matthew Hur
-                                                   CyberSafe Corporation
-                                                           Ari Medvinsky
-                                                                  Excite
-                                                         Sasha Medvinsky
-                                                      General Instrument
-                                                               John Wray
-                                                   Iris Associates, Inc.
-                                                        Jonathan Trostle
-                                                                   Cisco
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-0.  Status Of This Memo
-
-    This document is an Internet-Draft and is in full conformance with
-    all provisions of Section 10 of RFC 2026.  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."
-
-    The list of current Internet-Drafts can be accessed at
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-    The list of Internet-Draft Shadow Directories can be accessed at
-    http://www.ietf.org/shadow.html.
-
-    To learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ftp.ietf.org (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-09.txt, and expires November 12,
-    1999.  Please send comments to the authors.
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510 [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to associate a key pair with each realm, which can
-    then be used to facilitate cross-realm authentication; this is the
-    topic of another draft proposal.  Another way is to allow users with
-    public key certificates to use them in initial authentication.  This
-    is the concern of the current document.
-
-    PKINIT utilizes Diffie-Hellman keys in combination with digital
-    signature keys as the primary, required mechanism.  It also allows
-    for the use of RSA keys.  Note that PKINIT supports the use of
-    separate signature and encryption keys.
-
-    PKINIT enables access to Kerberos-secured services based on initial
-    authentication utilizing public key cryptography.  PKINIT utilizes
-    standard public key signature and encryption data formats within the
-    standard Kerberos messages.  The basic mechanism is as follows:  The
-    user sends a request to the KDC as before, except that if that user
-    is to use public key cryptography in the initial authentication
-    step, his certificate and a signature accompany the initial request
-    in the preauthentication fields.  Upon receipt of this request, the
-    KDC verifies the certificate and issues a ticket granting ticket
-    (TGT) as before, except that the encPart from the AS-REP message
-    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
-    derived key or the user's public key.  This message is authenticated
-    utilizing the public key signature of the KDC.
-
-    The PKINIT specification may also be used as a building block for
-    other specifications.  PKCROSS [3] utilizes PKINIT for establishing
-    the inter-realm key and associated inter-realm policy to be applied
-    in issuing cross realm service tickets.  As specified in [4],
-    anonymous Kerberos tickets can be issued by applying a NULL
-    signature in combination with Diffie-Hellman in the PKINIT exchange.
-    Additionally, the PKINIT specification may be used for direct peer
-    to peer authentication without contacting a central KDC. This
-    application of PKINIT is described in PKTAPP [5] and is based on
-    concepts introduced in [6, 7]. For direct client-to-server
-    authentication, the client uses PKINIT to authenticate to the end
-    server (instead of a central KDC), which then issues a ticket for
-    itself.  This approach has an advantage over TLS [8] in that the
-    server does not need to save state (cache session keys).
-    Furthermore, an additional benefit is that Kerberos tickets can
-    facilitate delegation (see [9]).
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510 for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following change to RFC 1510 is proposed:
-
-        * Users may authenticate using either a public key pair or a
-          conventional (symmetric) key.  If public key cryptography is
-          used, public key data is transported in preauthentication
-          data fields to help establish identity.  The user presents
-          a public key certificate and obtains an ordinary TGT that may
-          be used for subsequent authentication, with such
-          authentication using only conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 describes the extensions for the initial authentication
-    method.
-
-3.1.  Definitions
-
-    The extensions involve new preauthentication fields; we introduce
-    the following preauthentication types:
-
-        PA-PK-AS-REQ                            14
-        PA-PK-AS-REP                            15
-        PA-PK-KEY-REQ                           18
-        PA-PK-KEY-REP                           19
-
-    The extensions also involve new error types; we introduce the
-    following types:
-
-        KDC_ERR_CLIENT_NOT_TRUSTED              62
-        KDC_ERR_KDC_NOT_TRUSTED                 63
-        KDC_ERR_INVALID_SIG                     64
-        KDC_ERR_KEY_TOO_WEAK                    65
-        KDC_ERR_CERTIFICATE_MISMATCH            66
-
-    We utilize the following typed data for errors:
-
-        ETD-PKINIT-CMS-CERTIFICATES            101
-        ETD-KRB-PRINCIPAL                      102
-        ETD-KRB-REALM                          103
-
-    We utilize the following encryption types (which map directly to
-    OIDs):
-        sha1WithRSAEncryption-CmsOID             8
-        dsaWithSHA1-CmsOID                       9
-        md4WithRsaEncryption-CmsOID             10
-        md5WithRSAEncryption-CmsOID             11
-        rc2CBC-EnvOID                           12
-        rc4-EnvOID                              13
-
-    In many cases, PKINIT requires the encoding of an X.500 name as a
-    Realm.  In these cases, the realm will be represented using a
-    different style, specified in RFC 1510 with the following example:
-
-        NAMETYPE:rest/of.name=without-restrictions
-
-    For a realm derived from an X.500 name, NAMETYPE will have the value
-    X500-RFC2253.  The full realm name will appear as follows:
-
-        X500-RFC2253:RFC2253Encode(DistinguishedName)
-
-    where DistinguishedName is an X.500 name, and RFC2253Encode is a
-    readable ASCII encoding of an X.500 name, as defined by
-    RFC 2253 [14] (part of LDAPv3).
-
-    To ensure that this encoding is unique, we add the following rule
-    to those specified by RFC 2253:
-
-        The order in which the attributes appear in the RFC 2253
-        encoding must be the reverse of the order in the ASN.1
-        encoding of the X.500 name that appears in the public key
-        certificate. The order of the relative distinguished names
-        (RDNs), as well as the order of the AttributeTypeAndValues
-        within each RDN, will be reversed. (This is despite the fact
-        that an RDN is defined as a SET of AttributeTypeAndValues, where
-        an order is normally not important.)
-
-    Similarly, PKINIT may require the encoding of an X.500 name as a
-    PrincipalName.  In these cases, the name-type of the principal name
-    shall be set to KRB_NT-X500-PRINCIPAL.  This new name type is
-    defined as:
-
-        KRB_NT_X500_PRINCIPAL    6
-
-    The name-string shall be set as follows:
-
-        RFC2253Encode(DistinguishedName)
-
-    as described above.
-
-    Note that name mapping may be required or optional based on policy.
-
-3.1.1.  Encryption and Key Formats
-
-    In the exposition below, we use the terms public key and private
-    key generically.  It should be understood that the term "public
-    key" may be used to refer to either a public encryption key or a
-    signature verification key, and that the term "private key" may be
-    used to refer to either a private decryption key or a signature
-    generation key.  The fact that these are logically distinct does
-    not preclude the assignment of bitwise identical keys.
-
-    In the case of Diffie-Hellman, the key shall be produced from the
-    agreed bit string as follows:
-
-        * Truncate the bit string to the appropriate length.
-        * Rectify parity in each byte (if necessary) to obtain the key.
-
-    For instance, in the case of a DES key, we take the first eight
-    bytes of the bit stream, and then adjust the least significant bit
-    of each byte to ensure that each byte has odd parity.
-
-3.1.2. Algorithm Identifiers
-
-    PKINIT does not define, but does permit, the algorithm identifiers
-    listed below.
-
-3.1.2.1. Signature Algorithm Identifiers
-
-    These are the algorithm identifiers for use in the Signature data
-    structure as specified in CMS [11]:
-
-    sha-1WithRSAEncryption ALGORITHM PARAMETER NULL
-         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-               pkcs-1(1) 5 }
-
-    dsaWithSHA1 ALGORITHM PARAMETER NULL
-         ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
-               oIWSecAlgorithm(2) dsaWithSHA1(27) }
-
-    md4WithRsaEncryption ALGORITHM PARAMETER NULL
-         ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
-               oIWSecAlgorithm(2) md4WithRSAEncryption(4) }
-
-    md5WithRSAEncryption ALGORITHM PARAMETER NULL
-         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-               pkcs-1(1) md5WithRSAEncryption(4) }
-
-3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
-
-    This algorithm identifier is used inside the SubjectPublicKeyInfo
-    data structure:
-
-    dhKeyAgreement ALGORITHM PARAMETER DHParameters
-         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-               pkcs-3(3) dhKeyAgreement(1) }
-
-    DHParameters ::= SEQUENCE {
-        prime                       INTEGER,
-                                    -- p
-        base                        INTEGER,
-                                    -- g
-        privateValueLength          INTEGER OPTIONAL
-    }   -- as specified by the X.509 recommendation [9]
-
-3.1.2.3. Algorithm Identifiers for RSA Encryption
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure, for encrypting the temporary key with a public key:
-
-    id-RSAES-OAEP OBJECT IDENTIFIER
-         ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-               pkcs-1(1) 7 }
-
-3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure, for encrypting the temporary key with a Diffie-Hellman-
-    derived key, or for encrypting the reply key:
-
-    desCBC ALGORITHM PARAMETER IV8
-         ::= { iso(1) identifiedOrganization(3) oIW(14) oIWSecSig(3)
-               oIWSecAlgorithm(2) desCBC(7) }
-
-    DES-EDE3-CBC ALGORITHM PARAMETER IV8
-         ::= { iso(1) member-body(2) US(840) rsadsi(113549)
-               encryptionAlgorithm(3) desEDE3(7) }
-
-    IV8 ::= OCTET STRING (SIZE(8))        -- initialization vector
-
-    rc2CBC ALGORITHM PARAMETER RC2-CBCParameter
-         ::= { iso(1) member-body(2) US(840) rsadsi(113549)
-               encryptionAlgorithm(3) rc2CBC(2) }
-
-    The rc2CBC algorithm parameters (RC2-CBCParameter) are defined
-    in the following section.
-
-    rc4 ALGORITHM PARAMETER NULL
-         ::= { iso(1) member-body(2) US(840) rsadsi(113549)
-               encryptionAlgorithm(3) rc4(4) }
-
-    The rc4 algorithm cannot be used with the Diffie-Hellman-derived
-    keys, because its parameters do not specify the size of the key.
-
-3.1.2.5. rc2CBC Algorithm Parameters
-
-    This definition of the RC2 parameters is taken from a paper by
-    Ron Rivest [13]. Refer to [13] for the complete description of the
-    RC2 algorithm.
-
-    RC2-CBCParameter ::= CHOICE {
-        iv IV,
-        params SEQUENCE {
-            version RC2Version,
-            iv IV
-        }
-    }
-
-    where
-
-    IV ::= OCTET STRING -- 8 octets
-    RC2Version ::= INTEGER -- 1-1024
-
-    RC2 in CBC mode has two parameters: an 8-byte initialization
-    vector (IV) and a version number in the range 1-1024 which
-    specifies in a roundabout manner the number of effective key bits
-    to be used for the RC2 encryption/decryption.
-
-    The correspondence between effective key bits and version number
-    is as follows:
-
-    1. If the number EKB of effective key bits is in the range 1-255,
-       then the version number is given by Table[EKB], where the
-       256-byte translation table is specified below. It specifies a
-       permutation on the numbers 0-255.
-
-    2. If the number EKB of effective key bits is in the range
-       256-1024, then the version number is simply EKB.
-
-       The default number of effective key bits for RC2 is 32.
-       If RC2-CBC is being performed with 32 effective key bits, the
-       parameters should be supplied as a simple IV, rather than as a
-       SEQUENCE containing a version and an IV.
-
-         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
-
-    00: bd 56 ea f2 a2 f1 ac 2a b0 93 d1 9c 1b 33 fd d0
-    10: 30 04 b6 dc 7d df 32 4b f7 cb 45 9b 31 bb 21 5a
-    20: 41 9f e1 d9 4a 4d 9e da a0 68 2c c3 27 5f 80 36
-    30: 3e ee fb 95 1a fe ce a8 34 a9 13 f0 a6 3f d8 0c
-    40: 78 24 af 23 52 c1 67 17 f5 66 90 e7 e8 07 b8 60
-    50: 48 e6 1e 53 f3 92 a4 72 8c 08 15 6e 86 00 84 fa
-    60: f4 7f 8a 42 19 f6 db cd 14 8d 50 12 ba 3c 06 4e
-    70: ec b3 35 11 a1 88 8e 2b 94 99 b7 71 74 d3 e4 bf
-    80: 3a de 96 0e bc 0a ed 77 fc 37 6b 03 79 89 62 c6
-    90: d7 c0 d2 7c 6a 8b 22 a3 5b 05 5d 02 75 d5 61 e3
-    a0: 18 8f 55 51 ad 1f 0b 5e 85 e5 c2 57 63 ca 3d 6c
-    b0: b4 c5 cc 70 b2 91 59 0d 47 20 c8 4f 58 e0 01 e2
-    c0: 16 38 c4 6f 3b 0f 65 46 be 7e 2d 7b 82 f9 40 b5
-    d0: 1d 73 f8 eb 26 c7 87 97 25 54 b1 28 aa 98 9d a5
-    e0: 64 6d 7a d4 10 81 44 ef 49 d6 ae 2e dd 76 5c 2f
-    f0: a7 1c c9 09 69 9a 83 cf 29 39 b9 e9 4c ff 43 ab
-
-
-3.2.  Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with PKINIT.
-
-    It is assumed that all public keys are signed by some certification
-    authority (CA).  The initial authentication request is sent as per
-    RFC 1510, except that a preauthentication field containing data
-    signed by the user's private key accompanies the request:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                -- PA TYPE 14
-        signedAuthPack          [0] SignedData
-                                    -- defined in CMS [11]
-                                    -- AuthPack (below) defines the data
-                                    -- that is signed
-        trustedCertifiers       [1] SEQUENCE OF PrincipalName OPTIONAL,
-                                    -- CAs that the client trusts
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
-                                    -- as defined in CMS [11]
-                                    -- specifies a particular KDC
-                                    -- certificate if the client
-                                    -- already has it;
-                                    -- must be accompanied by
-                                    -- a single trustedCertifier
-    }
-
-    Usage of SignedData:
-    The SignedData data type is specified in the Cryptographic
-    Message Syntax, a product of the S/MIME working group of the IETF.
-    - The encapContentInfo field must contain the PKAuthenticator
-      and, optionally, the client's Diffie Hellman public value.
-      - The eContentType field shall contain the OID value for
-        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
-        pkcs(1) pkcs7(7) data(1)
-      - The eContent field is data of the type AuthPack (below).
-    - The signerInfos field is a SET of SignerInfo that is required by
-      CMS; however, the set may contain zero elements.  When non-empty,
-      this field contains the client's certificate chain.  If present,
-      the KDC uses the public key from the client's certificate to
-      verify the signature in the request.  Note that the client may
-      pass different certificates that are used for signing or for
-      encrypting.  Thus, the KDC may utilize a different client
-      certificate for signature verification than the one it uses to
-      encrypt the reply to the client.
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- if client is using Diffie-Hellman
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        kdcName                 [0] PrincipalName,
-        kdcRealm                [1] Realm,
-        cusec                   [2] INTEGER,
-                                    -- for replay prevention
-        ctime                   [3] KerberosTime,
-                                    -- for replay prevention
-        nonce                   [4] INTEGER
-    }
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm                   AlgorithmIdentifier,
-                                    -- dhKeyAgreement
-        subjectPublicKey            BIT STRING
-                                    -- for DH, equals
-                                    -- public exponent (INTEGER encoded
-                                    -- as payload of BIT STRING)
-    }   -- as specified by the X.509 recommendation [9]
-
-    AlgorithmIdentifier ::= SEQUENCE {
-        algorithm                   ALGORITHM.&id,
-        parameters                  ALGORITHM.&type
-    }   -- as specified by the X.509 recommendation [10]
-
-    If the client passes an issuer and serial number in the request,
-    the KDC is requested to use the referred-to certificate.  If none
-    exists, then the KDC returns an error of type
-    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
-    other hand, the client does not pass any trustedCertifiers,
-    believing that it has the KDC's certificate, but the KDC has more
-    than one certificate.  The KDC should include information in the
-    KRB-ERROR message that indicates the KDC certificate(s) that a
-    client may utilize.  This data is specified in the e-typed-data
-    type as follows:
-
-    ETypedData ::=  SEQUENCE {
-                    e-data-type    [1] INTEGER,
-                    e-data-value   [2] OCTET STRING,
-    } -- per Kerberos RFC 1510 revisions
-
-    where:
-    e-data-type = ETD-PKINIT-CMS-CERTIFICATES = 101
-    e-data-value = CertificateSet // as specified by CMS [11]
-
-    The PKAuthenticator carries information to foil replay attacks,
-    to bind the request and response.  The PKAuthenticator is signed
-    with the private key corresponding to the public key in the
-    certificate found in userCert (or cached by the KDC).
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.  If the KDC has no
-    certificate signed by any of the trustedCertifiers, then it returns
-    an error of type KDC_ERR_KDC_NOT_TRUSTED.
-
-    KDCs should try to (in order of preference):
-    1. Use the KDC certificate identified by the serialNumber included
-       in the client's request.
-    2. Use a certificate issued to the KDC by the client's CA (if in the
-       middle of a CA key roll-over, use the KDC cert issued under same
-       CA key as user cert used to verify request).
-    3. Use a certificate issued to the KDC by one of the client's
-       trustedCertifier(s);
-    If the KDC is unable to comply with any of these options, then the
-    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
-    client.
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.  This may be based on a certification
-    hierarchy, or it may be simply a list of recognized certifiers in a
-    system like PGP.
-
-    If verification of the user's certificate fails, the KDC sends back
-    an error message of type KDC_ERR_CLIENT_NOT_TRUSTED.  The e-data
-    field contains additional information pertaining to this error, and
-    is formatted as follows:
-
-        METHOD-DATA ::= SEQUENCE {
-            method-type         [0] INTEGER,
-                                    -- 0 = not specified
-                                    -- 1 = cannot verify public key
-                                    -- 2 = invalid certificate
-                                    -- 3 = revoked certificate
-                                    -- 4 = invalid KDC name
-                                    -- 5 = client name mismatch
-            method-data         [1] OCTET STRING OPTIONAL
-        } -- syntax as for KRB_AP_ERR_METHOD (RFC 1510)
-
-    The values for the method-type and method-data fields are described
-    in Section 3.2.1.
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on AuthPack.  If that fails, the KDC returns an error
-    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
-    timestamp (ctime and cusec) in the PKAuthenticator to assure that
-    the request is not a replay.  The KDC also verifies that its name
-    is specified in the PKAuthenticator.
-
-    If the clientPublicValue field is filled in, indicating that the
-    client wishes to use Diffie-Hellman key agreement, then the KDC
-    checks to see that the parameters satisfy its policy.  If they do
-    not (e.g., the prime size is insufficient for the expected
-    encryption type), then the KDC sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
-    private values for the response.
-
-    The KDC also checks that the timestamp in the PKAuthenticator is
-    within the allowable window and that the principal name and realm
-    are correct.  If the local (server) time and the client time in the
-    authenticator differ by more than the allowable clock skew, then the
-    KDC returns an error message of type KRB_AP_ERR_SKEW.  If the
-    principal name or realm do not match the KDC, then the KDC returns
-    an error message of type KDC_ERR_NAME_MISMATCH for which the
-    e-typed-data may contain the correct name to use
-    (EDT-KRB-PRINCIPAL=102 or EDT-KRB-REALM=103 where
-    e-data-value = PrincipalName or Realm as defined by RFC 1510).
-
-    Assuming no errors, the KDC replies as per RFC 1510, except as
-    follows.  The user's name in the ticket is determined by the
-    following decision algorithm:
-
-        1.  If the KDC has a mapping from the name in the certificate
-            to a Kerberos name, then use that name.
-            Else
-        2.  If the certificate contains a Kerberos name in an extension
-            field, and local KDC policy allows, then use that name.
-            Else
-        3.  Use the name as represented in the certificate, mapping
-            as necessary (e.g., as per RFC 2253 for X.500 names).  In
-            this case the realm in the ticket shall be the name of the
-            certification authority that issued the user's certificate.
-
-    The KDC encrypts the reply not with the user's long-term key, but
-    with a random key generated only for this particular response.  This
-    random key is sealed in the preauthentication field:
-
-    PA-PK-AS-REP ::= CHOICE {
-                            -- PA TYPE 15
-        dhSignedData       [0] SignedData,
-                            -- Defined in CMS and used only with
-                            -- Diffie-Helman key exchange
-        encKeyPack         [1] EnvelopedData,
-                            -- Defined in CMS
-                            -- The temporary key is encrypted
-                            -- using the client public key
-                            -- key
-                            -- SignedReplyKeyPack, encrypted
-                            -- with the temporary key, is also
-                            -- included.
-    }
-
-    Usage of SignedData:
-    If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP
-    provides authenticated Diffie-Hellman parameters of the KDC.  The
-    reply key used to encrypt part of the KDC reply message is derived
-    from the Diffie-Hellman exchange:
-    - Both the KDC and the client calculate a secret value (g^ab mod p),
-      where a is the client's private exponent and b is the KDC's
-      private exponent.
-    - Both the KDC and the client take the first N bits of this secret
-      value and convert it into a reply key.  N depends on the reply key
-      type.
-    - If the reply key is DES, N=64 bits, where some of the bits are
-      replaced with parity bits, according to FIPS PUB 74.
-    - If the reply key is (3-key) 3-DES, N=192 bits, where some of the
-      bits are replaced with parity bits, according to FIPS PUB 74.
-    - The encapContentInfo field must contain the KdcDHKeyInfo as
-      defined below.
-      - The eContentType field shall contain the OID value for
-        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
-        pkcs(1) pkcs7(7) data(1)
-    - The certificates field must contain the certificates necessary
-      for the client to establish trust in the KDC's certificate
-      based on the list of trusted certifiers sent by the client in
-      the PA-PK-AS-REQ.  This field may be empty if the client did
-      not send to the KDC a list of trusted certifiers (the
-      trustedCertifiers field was empty, meaning that the client
-      already possesses the KDC's certificate).
-    - The signerInfos field is a SET that must contain at least one
-      member, since it contains the actual signature.
-
-    Usage of EnvelopedData:
-    The EnvelopedData data type is specified in the Cryptographic
-    Message Syntax, a product of the S/MIME working group of the IETF.
-    It contains an temporary key encrypted with the PKINIT
-    client's public key.  It also contains a signed and encrypted
-    reply key.
-    - The originatorInfo field is not required, since that information
-      may be presented in the signedData structure that is encrypted
-      within the encryptedContentInfo field.
-    - The optional unprotectedAttrs field is not required for PKINIT.
-    - The recipientInfos field is a SET which must contain exactly one
-      member of the KeyTransRecipientInfo type for encryption
-      with an RSA public key.
-         - The encryptedKey field (in KeyTransRecipientInfo) contains
-           the temporary key which is encrypted with the PKINIT client's
-           public key.
-    - The encryptedContentInfo field contains the signed and encrypted
-      reply key.
-      - The contentType field shall contain the OID value for
-        id-signedData: iso(1) member-body(2) us(840) rsadsi(113549)
-        pkcs(1) pkcs7(7) signedData(2)
-      - The encryptedContent field is encrypted data of the CMS type
-        signedData as specified below.
-        - The encapContentInfo field must contains the ReplyKeyPack.
-          - The eContentType field shall contain the OID value for
-            id-data: iso(1) member-body(2) us(840) rsadsi(113549)
-            pkcs(1) pkcs7(7) data(1)
-          - The eContent field is data of the type ReplyKeyPack (below).
-        - The certificates field must contain the certificates necessary
-          for the client to establish trust in the KDC's certificate
-          based on the list of trusted certifiers sent by the client in
-          the PA-PK-AS-REQ.  This field may be empty if the client did
-          not send to the KDC a list of trusted certifiers (the
-          trustedCertifiers field was empty, meaning that the client
-          already possesses the KDC's certificate).
-        - The signerInfos field is a SET that must contain at least one
-          member, since it contains the actual signature.
-
-    KdcDHKeyInfo ::= SEQUENCE {
-                              -- used only when utilizing Diffie-Hellman
-      nonce                 [0] INTEGER,
-                                -- binds responce to the request
-      subjectPublicKey      [2] BIT STRING
-                                -- Equals public exponent (g^a mod p)
-                                -- INTEGER encoded as payload of
-                                -- BIT STRING
-    }
-
-    ReplyKeyPack ::= SEQUENCE {
-                              -- not used for Diffie-Hellman
-        replyKey             [0] EncryptionKey,
-                                 -- used to encrypt main reply
-                                 -- ENCTYPE is at least as strong as
-                                 -- ENCTYPE of session key
-        nonce                [1] INTEGER,
-                                 -- binds response to the request
-                                 -- must be same as the nonce
-                                 -- passed in the PKAuthenticator
-    }
-
-
-    Since each certifier in the certification path of a user's
-    certificate is essentially a separate realm, the name of each
-    certifier must be added to the transited field of the ticket.  The
-    format of these realm names is defined in Section 3.1 of this
-    document.  If applicable, the transit-policy-checked flag should be
-    set in the issued ticket.
-
-    The KDC's certificate must bind the public key to a name derivable
-    from the name of the realm for that KDC.  X.509 certificates shall
-    contain the principal name of the KDC as the SubjectAltName version
-    3 extension. Below is the definition of this version 3 extension, as
-    specified by the X.509 standard:
-
-        subjectAltName EXTENSION ::= {
-            SYNTAX GeneralNames
-            IDENTIFIED BY id-ce-subjectAltName
-        }
-
-        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
-
-        GeneralName ::= CHOICE {
-            otherName       [0] INSTANCE OF OTHER-NAME,
-            ...
-        }
-
-        OTHER-NAME ::= TYPE-IDENTIFIER
-
-    In this definition, otherName is a name of any form defined as an
-    instance of the OTHER-NAME information object class. For the purpose
-    of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
-    be replaced by the type KerberosPrincipalName:
-
-        KerberosPrincipalName ::= SEQUENCE {
-            nameType      [0] OTHER-NAME.&id ( { PrincipalNameTypes } ),
-            name          [1] OTHER-NAME.&type ( { PrincipalNameTypes }
-                              { @nameType } )
-        }
-
-        PrincipalNameTypes OTHER-NAME ::= {
-            { PrincipalNameSrvInst IDENTIFIED BY principalNameSrvInst }
-        }
-
-        PrincipalNameSrvInst ::= GeneralString
-
-    where (from the Kerberos specification) we have
-
-        krb5 OBJECT IDENTIFIER ::= { iso (1)
-                                     org (3)
-                                     dod (6)
-                                     internet (1)
-                                     security (5)
-                                     kerberosv5 (2) }
-
-        principalName OBJECT IDENTIFIER ::= { krb5 2 }
-
-        principalNameSrvInst OBJECT IDENTIFIER ::= { principalName 2 }
-
-    (This specification can also be used to specify a Kerberos name
-    within the user's certificate.)
-
-    The client then extracts the random key used to encrypt the main
-    reply.  This random key (in encPaReply) is encrypted with either the
-    client's public key or with a key derived from the DH values
-    exchanged between the client and the KDC.
-
-3.2.1.  Additional Information for Errors
-
-    This section describes the interpretation of the method-type and
-    method-data fields of the KDC_ERR_CLIENT_NOT_TRUSTED error.
-
-    If method-type=1, the client's public key certificate chain does not
-    contain a certificate that is signed by a certification authority
-    trusted by the KDC.  The format of the method-data field will be an
-    ASN.1 encoding of a list of trusted certifiers, as defined above:
-
-        TrustedCertifiers ::= SEQUENCE OF PrincipalName
-
-    If method-type=2, the signature on one of the certificates in the
-    chain cannot be verified.  The format of the method-data field will
-    be an ASN.1 encoding of the integer index of the certificate in
-    question:
-
-        CertificateIndex ::= INTEGER
-                             -- 0 = 1st certificate,
-                             -- 1 = 2nd certificate, etc
-
-    If method-type=3, one of the certificates in the chain has been
-    revoked.  The format of the method-data field will be an ASN.1
-    encoding of the integer index of the certificate in question:
-
-        CertificateIndex ::= INTEGER
-                             -- 0 = 1st certificate,
-                             -- 1 = 2nd certificate, etc
-
-    If method-type=4, the KDC name or realm in the PKAuthenticator does
-    not match the principal name of the KDC.  There is no method-data
-    field in this case.
-
-    If method-type=5, the client name or realm in the certificate does
-    not match the principal name of the client.  There is no
-    method-data field in this case.
-
-3.2.2. Required Algorithms
-
-    Not all of the algorithms in the PKINIT protocol specification have
-    to be implemented in order to comply with the proposed standard.
-    Below is a list of the required algorithms:
-
-    - Diffie-Hellman public/private key pairs
-    - SHA1 digest and DSA for signatures
-    - 3-key triple DES keys derived from the Diffie-Hellman Exchange
-    - 3-key triple DES Temporary and Reply keys
-
-4.  Logistics and Policy
-
-    This section describes a way to define the policy on the use of
-    PKINIT for each principal and request.
-
-    The KDC is not required to contain a database record for users
-    that use either the Standard Public Key Authentication.  However,
-    if these users are registered with the KDC, it is recommended that
-    the database record for these users be modified to an additional
-    flag in the attributes field to indicate that the user should
-    authenticate using PKINIT.  If this flag is set and a request
-    message does not contain the PKINIT preauthentication field, then
-    the KDC sends back as error of type KDC_ERR_PREAUTH_REQUIRED
-    indicating that a preauthentication field of type PA-PK-AS-REQ must
-    be included in the request.
-
-5.  Security Considerations
-
-    PKINIT raises a few security considerations, which we will address
-    in this section.
-
-    First of all, PKINIT introduces a new trust model, where KDCs do not
-    (necessarily) certify the identity of those for whom they issue
-    tickets.  PKINIT does allow KDCs to act as their own CAs, in order
-    to simplify key management, but one of the additional benefits is to
-    align Kerberos authentication with a global public key
-    infrastructure.  Anyone using PKINIT in this way must be aware of
-    how the certification infrastructure they are linking to works.
-
-    Secondly, PKINIT also introduces the possibility of interactions
-    between different cryptosystems, which may be of widely varying
-    strengths.  Many systems, for instance, allow the use of 512-bit
-    public keys.  Using such keys to wrap data encrypted under strong
-    conventional cryptosystems, such as triple-DES, is inappropriate;
-    it adds a weak link to a strong one at extra cost.  Implementors
-    and administrators should take care to avoid such wasteful and
-    deceptive interactions.
-
-    Lastly, PKINIT calls for randomly generated keys for conventional
-    cryptosystems.  Many such systems contain systematically "weak"
-    keys.  PKINIT implementations MUST avoid use of these keys, either
-    by discarding those keys when they are generated, or by fixing them
-    in some way (e.g., by XORing them with a given mask).  These
-    precautions vary from system to system; it is not our intention to
-    give an explicit recipe for them here.
-
-6.  Transport Issues
-
-    Certificate chains can potentially grow quite large and span several
-    UDP packets; this in turn increases the probability that a Kerberos
-    message involving PKINIT extensions will be broken in transit.  In
-    light of the possibility that the Kerberos specification will
-    require KDCs to accept requests using TCP as a transport mechanism,
-    we make the same recommendation with respect to the PKINIT
-    extensions as well.
-
-7.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-    (V5).  Request for Comments 1510.
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.  September
-    1994.
-
-    [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
-    A. Medvinsky, M. Hur.  Public Key Cryptography for Cross-Realm
-    Authentication in Kerberos.
-    draft-ietf-cat-kerberos-pk-cross-04.txt
-
-    [4] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
-    Kerberos.
-    draft-ietf-cat-kerberos-anoncred-00.txt
-
-    [5] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
-    Tickets for Application Servers (PKTAPP).
-    draft-ietf-cat-pktapp-00.txt
-
-    [6] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-    Using Public Key Cryptography.  Symposium On Network and Distributed
-    System Security, 1997.
-
-    [7] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic
-    Commerce, July 1995.
-
-    [8] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
-    Request for Comments 2246, January 1999.
-
-    [9] B.C. Neuman, Proxy-Based Authorization and Accounting for
-    Distributed Systems.  In Proceedings of the 13th International
-    Conference on Distributed Computing Systems, May 1993.
-
-    [10] ITU-T (formerly CCITT) Information technology - Open Systems
-    Interconnection - The Directory: Authentication Framework
-    Recommendation X.509 ISO/IEC 9594-8
-
-    [11] R. Housley. Cryptographic Message Syntax.
-    draft-ietf-smime-cms-10.txt, December 1998.
-
-    [12] PKCS #7: Cryptographic Message Syntax Standard,
-    An RSA Laboratories Technical Note Version 1.5
-    Revised November 1, 1993
-
-    [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
-    Security, Inc. A Description of the RC2(r) Encryption Algorithm
-    March 1998.
-    Request for Comments 2268.
-
-    [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
-    Protocol (v3): UTF-8 String Representation of Distinguished Names.
-    Request for Comments 2253.
-
-8.  Acknowledgements
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-9.  Expiration Date
-
-    This draft expires November 12, 1999.
-
-10. Authors
-
-    Brian Tung
-    Clifford Neuman
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {brian, bcn}@isi.edu
-
-    Matthew Hur
-    CyberSafe Corporation
-    1605 NW Sammamish Road
-    Issaquah WA 98027-5378
-    Phone: +1 425 391 6000
-    E-mail: matt.hur@cybersafe.com
-
-    Ari Medvinsky
-    Excite
-    555 Broadway
-    Redwood City, CA 94063
-    Phone +1 650 569 2119
-    E-mail: amedvins@excitecorp.com
-
-    Sasha Medvinsky
-    General Instrument
-    6450 Sequence Drive
-    San Diego, CA 92121
-    Phone +1 619 404 2825
-    E-mail: smedvinsky@gi.com
-
-    John Wray
-    Iris Associates, Inc.
-    5 Technology Park Dr.
-    Westford, MA 01886
-    E-mail: John_Wray@iris.com
-
-    Jonathan Trostle
-    170 W. Tasman Dr.
-    San Jose, CA 95134
-    E-mail: jtrostle@cisco.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-09.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-09.txt
deleted file mode 100644
index 748f08954..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-09.txt
+++ /dev/null
@@ -1,908 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-09.txt                   Clifford Neuman
-Updates: RFC 1510                                                    ISI
-expires December 1, 1999                                     Matthew Hur
-                                                   CyberSafe Corporation
-                                                           Ari Medvinsky
-                                                                  Excite
-                                                         Sasha Medvinsky
-                                                      General Instrument
-                                                               John Wray
-                                                   Iris Associates, Inc.
-                                                        Jonathan Trostle
-                                                                   Cisco
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-0.  Status Of This Memo
-
-    This document is an Internet-Draft and is in full conformance with
-    all provisions of Section 10 of RFC 2026.  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."
-
-
-    The list of current Internet-Drafts can be accessed at
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-    The list of Internet-Draft Shadow Directories can be accessed at
-    http://www.ietf.org/shadow.html.
-
-    To learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ftp.ietf.org (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-09.txt, and expires December 1,
-    1999.  Please send comments to the authors.
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510 [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to associate a key pair with each realm, which can
-    then be used to facilitate cross-realm authentication; this is the
-    topic of another draft proposal.  Another way is to allow users with
-    public key certificates to use them in initial authentication.  This
-    is the concern of the current document.
-
-    PKINIT utilizes Diffie-Hellman keys in combination with digital
-    signature keys as the primary, required mechanism.  It also allows
-    for the use of RSA keys.  Note that PKINIT supports the use of
-    separate signature and encryption keys.
-
-    PKINIT enables access to Kerberos-secured services based on initial
-    authentication utilizing public key cryptography.  PKINIT utilizes
-    standard public key signature and encryption data formats within the
-    standard Kerberos messages.  The basic mechanism is as follows:  The
-    user sends a request to the KDC as before, except that if that user
-    is to use public key cryptography in the initial authentication
-    step, his certificate and a signature accompany the initial request
-    in the preauthentication fields.  Upon receipt of this request, the
-    KDC verifies the certificate and issues a ticket granting ticket
-    (TGT) as before, except that the encPart from the AS-REP message
-    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
-    derived key or the user's public key.  This message is authenticated
-    utilizing the public key signature of the KDC.
-
-    The PKINIT specification may also be used as a building block for
-    other specifications.  PKCROSS [3] utilizes PKINIT for establishing
-    the inter-realm key and associated inter-realm policy to be applied
-    in issuing cross realm service tickets.  As specified in [4],
-    anonymous Kerberos tickets can be issued by applying a NULL
-    signature in combination with Diffie-Hellman in the PKINIT exchange.
-    Additionally, the PKINIT specification may be used for direct peer
-    to peer authentication without contacting a central KDC. This
-    application of PKINIT is described in PKTAPP [5] and is based on
-    concepts introduced in [6, 7]. For direct client-to-server
-    authentication, the client uses PKINIT to authenticate to the end
-    server (instead of a central KDC), which then issues a ticket for
-    itself.  This approach has an advantage over TLS [8] in that the
-    server does not need to save state (cache session keys).
-    Furthermore, an additional benefit is that Kerberos tickets can
-    facilitate delegation (see [9]).
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510 for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following change to RFC 1510 is proposed:
-
-        * Users may authenticate using either a public key pair or a
-          conventional (symmetric) key.  If public key cryptography is
-          used, public key data is transported in preauthentication
-          data fields to help establish identity.  The user presents
-          a public key certificate and obtains an ordinary TGT that may
-          be used for subsequent authentication, with such
-          authentication using only conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 describes the extensions for the initial authentication
-    method.
-
-3.1.  Definitions
-
-    The extensions involve new preauthentication fields; we introduce
-    the following preauthentication types:
-
-        PA-PK-AS-REQ                            14
-        PA-PK-AS-REP                            15
-
-    The extensions also involve new error types; we introduce the
-    following types:
-
-        KDC_ERR_CLIENT_NOT_TRUSTED              62
-        KDC_ERR_KDC_NOT_TRUSTED                 63
-        KDC_ERR_INVALID_SIG                     64
-        KDC_ERR_KEY_TOO_WEAK                    65
-        KDC_ERR_CERTIFICATE_MISMATCH            66
-        KDC_ERR_CANT_VERIFY_CERTIFICATE         70
-        KDC_ERR_INVALID_CERTIFICATE             71
-        KDC_ERR_REVOKED_CERTIFICATE             72
-        KDC_ERR_REVOCATION_STATUS_UNKNOWN       73
-        KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74
-        KDC_ERR_CLIENT_NAME_MISMATCH            75
-        KDC_ERR_KDC_NAME_MISMATCH               76
-
-    We utilize the following typed data for errors:
-
-        TD-PKINIT-CMS-CERTIFICATES             101
-        TD-KRB-PRINCIPAL                       102
-        TD-KRB-REALM                           103
-        TD-TRUSTED-CERTIFIERS                  104
-        TD-CERTIFICATE-INDEX                   105
-
-    We utilize the following encryption types (which map directly to
-    OIDs):
-
-        dsaWithSHA1-CmsOID                       9
-        md5WithRSAEncryption-CmsOID             10
-        sha1WithRSAEncryption-CmsOID            11
-        rc2CBC-EnvOID                           12
-        rsaEncryption-EnvOID (PKCS#1 v1.5)      13
-        rsaES-OAEP-ENV-OID   (PKCS#1 v2.0)      14
-        des-ede3-cbc-Env-OID                    15
-
-    These mappings are provided so that a client may send the
-    appropriate enctypes in the AS-REQ message in order to indicate
-    support for the corresponding OIDs (for performing PKINIT).
-
-    In many cases, PKINIT requires the encoding of an X.500 name as a
-    Realm.  In these cases, the realm will be represented using a
-    different style, specified in RFC 1510 with the following example:
-
-        NAMETYPE:rest/of.name=without-restrictions
-
-    For a realm derived from an X.500 name, NAMETYPE will have the value
-    X500-RFC2253.  The full realm name will appear as follows:
-
-        X500-RFC2253:RFC2253Encode(DistinguishedName)
-
-    where DistinguishedName is an X.500 name, and RFC2253Encode is a
-    readable UTF encoding of an X.500 name, as defined by
-    RFC 2253 [14] (part of LDAPv3).
-
-    To ensure that this encoding is unique, we add the following rule
-    to those specified by RFC 2253:
-
-        The order in which the attributes appear in the RFC 2253
-        encoding must be the reverse of the order in the ASN.1
-        encoding of the X.500 name that appears in the public key
-        certificate. The order of the relative distinguished names
-        (RDNs), as well as the order of the AttributeTypeAndValues
-        within each RDN, will be reversed. (This is despite the fact
-        that an RDN is defined as a SET of AttributeTypeAndValues, where
-        an order is normally not important.)
-
-    Similarly, PKINIT may require the encoding of an X.500 name as a
-    PrincipalName.  In these cases, the name-type of the principal name
-    shall be set to KRB_NT-X500-PRINCIPAL.  This new name type is
-    defined as:
-
-        KRB_NT_X500_PRINCIPAL    6
-
-    The name-string shall be set as follows:
-
-        RFC2253Encode(DistinguishedName)
-
-    as described above.
-
-    RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
-
-        PrincipalName ::=   SEQUENCE {
-                        name-type[0]     INTEGER,
-                        name-string[1]   SEQUENCE OF GeneralString
-        }
-
-    For the purposes of encoding an X.500 name within this structure,
-    the name-string shall be encoded as a single GeneralString.
-
-    Note that name mapping may be required or optional based on
-    policy.
-
-3.1.1.  Encryption and Key Formats
-
-    In the exposition below, we use the terms public key and private
-    key generically.  It should be understood that the term "public
-    key" may be used to refer to either a public encryption key or a
-    signature verification key, and that the term "private key" may be
-    used to refer to either a private decryption key or a signature
-    generation key.  The fact that these are logically distinct does
-    not preclude the assignment of bitwise identical keys.
-
-    In the case of Diffie-Hellman, the key shall be produced from the
-    agreed bit string as follows:
-
-        * Truncate the bit string to the appropriate length.
-        * Rectify parity in each byte (if necessary) to obtain the key.
-
-    For instance, in the case of a DES key, we take the first eight
-    bytes of the bit stream, and then adjust the least significant bit
-    of each byte to ensure that each byte has odd parity.
-
-3.1.2. Algorithm Identifiers
-
-    PKINIT does not define, but does permit, the algorithm identifiers
-    listed below.
-
-3.1.2.1. Signature Algorithm Identifiers
-
-    The following signature algorithm identifiers specified in [11] and
-    in [15] shall be used with PKINIT:
-
-    id-dsa-with-sha1       (DSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    sha-1WithRSAEncryption (RSA with SHA1)
-
-3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
-
-    The following algorithm identifier shall be used within the
-    SubjectPublicKeyInfo data structure: dhpublicnumber
-
-    This identifier and the associated algorithm parameters are
-    specified in RFC 2459 [15].
-
-3.1.2.3. Algorithm Identifiers for RSA Encryption
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure, for encrypting the temporary key with a public key:
-
-        rsaEncryption (RSA encryption, PKCS#1 v1.5)
-        id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
-
-    Both of the above RSA encryption schemes are specified in [16].
-    Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
-    CMS specification says that it will likely include PKCS#1 v2.0 in
-    the future.  (PKCS#1 v2.0 addresses adaptive chosen ciphertext
-    vulnerability discovered in PKCS#1 v1.5.)
-
-3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure in the PKINIT Reply, for encrypting the reply key with the
-    temporary key:
-        des-ede3-cbc (3-key 3-DES, CBC mode)
-        rc2-cbc      (RC2, CBC mode)
-
-    The full definition of the above algorithm identifiers and their
-    corresponding parameters (an IV for block chaining) is provided in
-    the CMS specification [11].
-
-3.2.  Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with PKINIT.
-
-    It is assumed that all public keys are signed by some certification
-    authority (CA).  The initial authentication request is sent as per
-    RFC 1510, except that a preauthentication field containing data
-    signed by the user's private key accompanies the request:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                -- PA TYPE 14
-        signedAuthPack          [0] SignedData
-                                    -- defined in CMS [11]
-                                    -- AuthPack (below) defines the data
-                                    -- that is signed
-        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
-                                    -- CAs that the client trusts
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
-                                    -- as defined in CMS [11]
-                                    -- specifies a particular KDC
-                                    -- certificate if the client
-                                    -- already has it;
-                                    -- must be accompanied by
-                                    -- a single trustedCertifier
-        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
-                                    -- For example, this may be the
-                                    -- client's Diffie-Hellman
-                                    -- certificate, or it may be the
-                                    -- client's RSA encryption
-                                    -- certificate.
-    }
-
-    TrustedCas ::= CHOICE {
-        principalName         [0] KerberosName,
-                                  -- as defined below
-        caName                [1] Name
-                                  -- fully qualified X.500 name
-                                  -- as defined by X.509
-        issuerAndSerial       [2] IssuerAndSerialNumber OPTIONAL
-                                  -- Since a CA may have a number of
-                                  -- certificates, only one of which
-                                  -- a client trusts
-    }
-
-    Usage of SignedData:
-    The SignedData data type is specified in the Cryptographic
-    Message Syntax, a product of the S/MIME working group of the IETF.
-    - The encapContentInfo field must contain the PKAuthenticator
-      and, optionally, the client's Diffie Hellman public value.
-      - The eContentType field shall contain the OID value for
-        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
-        pkcs(1) pkcs7(7) data(1)
-      - The eContent field is data of the type AuthPack (below).
-    - The signerInfos field contains the signature of AuthPack.
-    - The Certificates field, when non-empty, contains the client's
-      certificate chain.  If present, the KDC uses the public key from
-      the client's certificate to verify the signature in the request.
-      Note that the client may pass different certificates that are used
-      for signing or for encrypting.  Thus, the KDC may utilize a
-      different client certificate for signature verification than the
-      one it uses to encrypt the reply to the client.  For example, the
-      client may place a Diffie-Hellman certificate in this field in
-      order to convey its static Diffie Hellman certificate to the KDC
-      enable static-ephemeral Diffie-Hellman mode for the reply.  As
-      another example, the client may place an RSA encryption
-      certificate in this field.
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- if client is using Diffie-Hellman
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        kdcName                 [0] PrincipalName,
-        kdcRealm                [1] Realm,
-        cusec                   [2] INTEGER,
-                                    -- for replay prevention
-        ctime                   [3] KerberosTime,
-                                    -- for replay prevention
-        nonce                   [4] INTEGER
-    }
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm                   AlgorithmIdentifier,
-                                    -- dhKeyAgreement
-        subjectPublicKey            BIT STRING
-                                    -- for DH, equals
-                                    -- public exponent (INTEGER encoded
-                                    -- as payload of BIT STRING)
-    }   -- as specified by the X.509 recommendation [10]
-
-    AlgorithmIdentifier ::= SEQUENCE {
-        algorithm                   ALGORITHM.&id,
-        parameters                  ALGORITHM.&type
-    }   -- as specified by the X.509 recommendation [10]
-
-    If the client passes an issuer and serial number in the request,
-    the KDC is requested to use the referred-to certificate.  If none
-    exists, then the KDC returns an error of type
-    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
-    other hand, the client does not pass any trustedCertifiers,
-    believing that it has the KDC's certificate, but the KDC has more
-    than one certificate.  The KDC should include information in the
-    KRB-ERROR message that indicates the KDC certificate(s) that a
-    client may utilize.  This data is specified in the e-data, which
-    is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
-
-    TypedData ::=  SEQUENCE {
-                    data-type      [0] INTEGER,
-                    data-value     [1] OCTET STRING,
-    } -- per Kerberos RFC 1510 revisions
-
-    where:
-    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
-    data-value = CertificateSet // as specified by CMS [11]
-
-    The PKAuthenticator carries information to foil replay attacks,
-    to bind the request and response.  The PKAuthenticator is signed
-    with the private key corresponding to the public key in the
-    certificate found in userCert (or cached by the KDC).
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.  If the KDC has no
-    certificate signed by any of the trustedCertifiers, then it returns
-    an error of type KDC_ERR_KDC_NOT_TRUSTED.
-
-    KDCs should try to (in order of preference):
-    1. Use the KDC certificate identified by the serialNumber included
-       in the client's request.
-    2. Use a certificate issued to the KDC by the client's CA (if in the
-       middle of a CA key roll-over, use the KDC cert issued under same
-       CA key as user cert used to verify request).
-    3. Use a certificate issued to the KDC by one of the client's
-       trustedCertifier(s);
-    If the KDC is unable to comply with any of these options, then the
-    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
-    client.
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.  This may be based on a certification
-    hierarchy, or it may be simply a list of recognized certifiers in a
-    system like PGP.
-
-    If the client's certificate chain contains no certificate signed by
-    a CA trusted by the KDC, then the KDC sends back an error message
-    of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data
-    is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
-    whose data-value is an OCTET STRING which is the DER encoding of
-
-        TrustedCertifiers ::= SEQUENCE OF PrincipalName
-                              -- X.500 name encoded as a principal name
-                              -- see Section 3.1
-
-    If the signature on one of the certificates in the client's chain
-    fails verification, then the KDC returns an error of type
-    KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data is a SEQUENCE
-    of one TypedData (with type TD-CERTIFICATE-INDEX=105) whose
-    data-value is an OCTET STRING which is the DER encoding of
-
-        CertificateIndex  ::= INTEGER
-                              -- 0 = 1st certificate,
-                              --     (in order of encoding)
-                              -- 1 = 2nd certificate, etc
-
-    The KDC may also check whether any of the certificates in the
-    client's chain has been revoked.  If one of the certificates has
-    been revoked, then the KDC returns an error of type
-    KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that the
-    certificate's revocation status is unknown, the KDC returns an
-    error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN; if the revocation
-    status is unavailable, the KDC returns an error of type
-    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE.  In any of these three
-    cases, the affected certificate is identified by the accompanying
-    e-data, which contains a CertificateIndex as described for
-    KDC_ERR_INVALID_CERTIFICATE.
-
-    If the certificate chain can be verified, but the name of the
-    client in the certificate does not match the client's name in the
-    request, then the KDC returns an error of type
-    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
-    field in this case.
-
-    Finally, if the certificate chain is verified, but the KDC's name
-    or realm as given in the PKAuthenticator does not match the KDC's
-    actual principal name, then the KDC returns an error of type
-    KDC_ERR_KDC_NAME_MISMATCH.  The accompanying e-data field is again
-    a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
-    TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
-    STRING whose data-value is the DER encoding of a PrincipalName or
-    Realm as defined in RFC 1510 revisions.
-
-    Even if all succeeds, the KDC may--for policy reasons--decide not
-    to trust the client.  In this case, the KDC returns an error message
-    of type KDC_ERR_CLIENT_NOT_TRUSTED.
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on AuthPack.  If that fails, the KDC returns an error
-    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
-    timestamp (ctime and cusec) in the PKAuthenticator to assure that
-    the request is not a replay.  The KDC also verifies that its name
-    is specified in the PKAuthenticator.
-
-    If the clientPublicValue field is filled in, indicating that the
-    client wishes to use Diffie-Hellman key agreement, then the KDC
-    checks to see that the parameters satisfy its policy.  If they do
-    not (e.g., the prime size is insufficient for the expected
-    encryption type), then the KDC sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
-    private values for the response.
-
-    The KDC also checks that the timestamp in the PKAuthenticator is
-    within the allowable window and that the principal name and realm
-    are correct.  If the local (server) time and the client time in the
-    authenticator differ by more than the allowable clock skew, then the
-    KDC returns an error message of type KRB_AP_ERR_SKEW.
-
-    Assuming no errors, the KDC replies as per RFC 1510, except as
-    follows.  The user's name in the ticket is determined by the
-    following decision algorithm:
-
-        1.  If the KDC has a mapping from the name in the certificate
-            to a Kerberos name, then use that name.
-            Else
-        2.  If the certificate contains a Kerberos name in an extension
-            field, and local KDC policy allows, then use that name.
-            Else
-        3.  Use the name as represented in the certificate, mapping
-            as necessary (e.g., as per RFC 2253 for X.500 names).  In
-            this case the realm in the ticket shall be the name of the
-            certification authority that issued the user's certificate.
-
-    The KDC encrypts the reply not with the user's long-term key, but
-    with a random key generated only for this particular response.  This
-    random key is sealed in the preauthentication field:
-
-    PA-PK-AS-REP ::= CHOICE {
-                            -- PA TYPE 15
-        dhSignedData       [0] SignedData,
-                            -- Defined in CMS and used only with
-                            -- Diffie-Helman key exchange
-                            -- This choice MUST be supported
-                            -- by compliant implementations.
-        encKeyPack         [1] EnvelopedData,
-                            -- Defined in CMS
-                            -- The temporary key is encrypted
-                            -- using the client public key
-                            -- key
-                            -- SignedReplyKeyPack, encrypted
-                            -- with the temporary key, is also
-                            -- included.
-    }
-
-    Usage of SignedData:
-    If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP
-    provides authenticated Diffie-Hellman parameters of the KDC.  The
-    reply key used to encrypt part of the KDC reply message is derived
-    from the Diffie-Hellman exchange:
-    - Both the KDC and the client calculate a secret value (g^ab mod p),
-      where a is the client's private exponent and b is the KDC's
-      private exponent.
-    - Both the KDC and the client take the first N bits of this secret
-      value and convert it into a reply key.  N depends on the reply key
-      type.
-    - If the reply key is DES, N=64 bits, where some of the bits are
-      replaced with parity bits, according to FIPS PUB 74.
-    - If the reply key is (3-key) 3-DES, N=192 bits, where some of the
-      bits are replaced with parity bits, according to FIPS PUB 74.
-    - The encapContentInfo field must contain the KdcDHKeyInfo as
-      defined below.
-      - The eContentType field shall contain the OID value for
-        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
-        pkcs(1) pkcs7(7) data(1)
-    - The certificates field must contain the certificates necessary
-      for the client to establish trust in the KDC's certificate
-      based on the list of trusted certifiers sent by the client in
-      the PA-PK-AS-REQ.  This field may be empty if the client did
-      not send to the KDC a list of trusted certifiers (the
-      trustedCertifiers field was empty, meaning that the client
-      already possesses the KDC's certificate).
-    - The signerInfos field is a SET that must contain at least one
-      member, since it contains the actual signature.
-
-    Usage of EnvelopedData:
-    The EnvelopedData data type is specified in the Cryptographic
-    Message Syntax, a product of the S/MIME working group of the IETF.
-    It contains an temporary key encrypted with the PKINIT
-    client's public key.  It also contains a signed and encrypted
-    reply key.
-    - The originatorInfo field is not required, since that information
-      may be presented in the signedData structure that is encrypted
-      within the encryptedContentInfo field.
-    - The optional unprotectedAttrs field is not required for PKINIT.
-    - The recipientInfos field is a SET which must contain exactly one
-      member of the KeyTransRecipientInfo type for encryption
-      with an RSA public key.
-         - The encryptedKey field (in KeyTransRecipientInfo) contains
-           the temporary key which is encrypted with the PKINIT client's
-           public key.
-    - The encryptedContentInfo field contains the signed and encrypted
-      reply key.
-      - The contentType field shall contain the OID value for
-        id-signedData: iso(1) member-body(2) us(840) rsadsi(113549)
-        pkcs(1) pkcs7(7) signedData(2)
-      - The encryptedContent field is encrypted data of the CMS type
-        signedData as specified below.
-        - The encapContentInfo field must contains the ReplyKeyPack.
-          - The eContentType field shall contain the OID value for
-            id-data: iso(1) member-body(2) us(840) rsadsi(113549)
-            pkcs(1) pkcs7(7) data(1)
-          - The eContent field is data of the type ReplyKeyPack (below).
-        - The certificates field must contain the certificates necessary
-          for the client to establish trust in the KDC's certificate
-          based on the list of trusted certifiers sent by the client in
-          the PA-PK-AS-REQ.  This field may be empty if the client did
-          not send to the KDC a list of trusted certifiers (the
-          trustedCertifiers field was empty, meaning that the client
-          already possesses the KDC's certificate).
-        - The signerInfos field is a SET that must contain at least one
-          member, since it contains the actual signature.
-
-    KdcDHKeyInfo ::= SEQUENCE {
-                              -- used only when utilizing Diffie-Hellman
-      nonce                 [0] INTEGER,
-                                -- binds responce to the request
-      subjectPublicKey      [2] BIT STRING
-                                -- Equals public exponent (g^a mod p)
-                                -- INTEGER encoded as payload of
-                                -- BIT STRING
-    }
-
-    ReplyKeyPack ::= SEQUENCE {
-                              -- not used for Diffie-Hellman
-        replyKey             [0] EncryptionKey,
-                                 -- used to encrypt main reply
-                                 -- ENCTYPE is at least as strong as
-                                 -- ENCTYPE of session key
-        nonce                [1] INTEGER,
-                                 -- binds response to the request
-                                 -- must be same as the nonce
-                                 -- passed in the PKAuthenticator
-    }
-
-
-    Since each certifier in the certification path of a user's
-    certificate is essentially a separate realm, the name of each
-    certifier must be added to the transited field of the ticket.  The
-    format of these realm names is defined in Section 3.1 of this
-    document.  If applicable, the transit-policy-checked flag should be
-    set in the issued ticket.
-
-    The KDC's certificate must bind the public key to a name derivable
-    from the name of the realm for that KDC.  X.509 certificates shall
-    contain the principal name of the KDC as the SubjectAltName version
-    3 extension. Below is the definition of this version 3 extension, as
-    specified by the X.509 standard:
-
-        subjectAltName EXTENSION ::= {
-            SYNTAX GeneralNames
-            IDENTIFIED BY id-ce-subjectAltName
-        }
-
-        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
-
-        GeneralName ::= CHOICE {
-            otherName       [0] INSTANCE OF OTHER-NAME,
-            ...
-        }
-
-        OTHER-NAME ::= TYPE-IDENTIFIER
-
-    In this definition, otherName is a name of any form defined as an
-    instance of the OTHER-NAME information object class. For the purpose
-    of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
-    be chosen and replaced by the type KerberosName:
-
-        KerberosName ::= SEQUENCE {
-          realm           [0] Realm,
-                              -- as define in RFC 1510
-          principalName   [1] PrincipalName,
-                              -- as define in RFC 1510
-        }
-
-    This specific syntax is identified within subjectAltName by setting
-    the OID id-ce-subjectAltName to krb5PrincipalName, where (from the
-    Kerberos specification) we have
-
-        krb5 OBJECT IDENTIFIER ::= { iso (1)
-                                     org (3)
-                                     dod (6)
-                                     internet (1)
-                                     security (5)
-                                     kerberosv5 (2) }
-
-        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
-
-    This specification may also be used to specify a Kerberos name
-    within the user's certificate.
-
-    If a non-KDC X.509 certificate contains the principal name within
-    the subjectAltName version 3 extension , that name may utilize
-    KerberosName as defined below, or, in the case of an S/MIME
-    certificate [17], may utilize the email address.  If the KDC
-    is presented with as S/MIME certificate, then the email address
-    within subjectAltName will be interpreted as a principal and realm
-    separated by the "@" sign, or as a name that needs to be
-    canonicalized.  If the resulting name does not correspond to a
-    registered principal name, then the principal name is formed as
-    defined in section 3.1.
-
-    The client then extracts the random key used to encrypt the main
-    reply.  This random key (in encPaReply) is encrypted with either the
-    client's public key or with a key derived from the DH values
-    exchanged between the client and the KDC.
-
-3.2.2. Required Algorithms
-
-    Not all of the algorithms in the PKINIT protocol specification have
-    to be implemented in order to comply with the proposed standard.
-    Below is a list of the required algorithms:
-
-    - Diffie-Hellman public/private key pairs
-      - utilizing Diffie-Hellman ephemeral-ephemeral mode
-    - SHA1 digest and DSA for signatures
-    - 3-key triple DES keys derived from the Diffie-Hellman Exchange
-    - 3-key triple DES Temporary and Reply keys
-
-4.  Logistics and Policy
-
-    This section describes a way to define the policy on the use of
-    PKINIT for each principal and request.
-
-    The KDC is not required to contain a database record for users
-    who use public key authentication.  However, if these users are
-    registered with the KDC, it is recommended that the database record
-    for these users be modified to an additional flag in the attributes
-    field to indicate that the user should authenticate using PKINIT.
-    If this flag is set and a request message does not contain the
-    PKINIT preauthentication field, then the KDC sends back as error of
-    type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
-    field of type PA-PK-AS-REQ must be included in the request.
-
-5.  Security Considerations
-
-    PKINIT raises a few security considerations, which we will address
-    in this section.
-
-    First of all, PKINIT introduces a new trust model, where KDCs do not
-    (necessarily) certify the identity of those for whom they issue
-    tickets.  PKINIT does allow KDCs to act as their own CAs, in order
-    to simplify key management, but one of the additional benefits is to
-    align Kerberos authentication with a global public key
-    infrastructure.  Anyone using PKINIT in this way must be aware of
-    how the certification infrastructure they are linking to works.
-
-    Secondly, PKINIT also introduces the possibility of interactions
-    between different cryptosystems, which may be of widely varying
-    strengths.  Many systems, for instance, allow the use of 512-bit
-    public keys.  Using such keys to wrap data encrypted under strong
-    conventional cryptosystems, such as triple-DES, is inappropriate;
-    it adds a weak link to a strong one at extra cost.  Implementors
-    and administrators should take care to avoid such wasteful and
-    deceptive interactions.
-
-    Lastly, PKINIT calls for randomly generated keys for conventional
-    cryptosystems.  Many such systems contain systematically "weak"
-    keys.  PKINIT implementations MUST avoid use of these keys, either
-    by discarding those keys when they are generated, or by fixing them
-    in some way (e.g., by XORing them with a given mask).  These
-    precautions vary from system to system; it is not our intention to
-    give an explicit recipe for them here.
-
-6.  Transport Issues
-
-    Certificate chains can potentially grow quite large and span several
-    UDP packets; this in turn increases the probability that a Kerberos
-    message involving PKINIT extensions will be broken in transit.  In
-    light of the possibility that the Kerberos specification will
-    require KDCs to accept requests using TCP as a transport mechanism,
-    we make the same recommendation with respect to the PKINIT
-    extensions as well.
-
-7.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-    (V5).  Request for Comments 1510.
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.  September
-    1994.
-
-    [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
-    A. Medvinsky, M. Hur.  Public Key Cryptography for Cross-Realm
-    Authentication in Kerberos.
-    draft-ietf-cat-kerberos-pk-cross-04.txt
-
-    [4] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
-    Kerberos.
-    draft-ietf-cat-kerberos-anoncred-00.txt
-
-    [5] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
-    Tickets for Application Servers (PKTAPP).
-    draft-ietf-cat-pktapp-00.txt
-
-    [6] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-    Using Public Key Cryptography.  Symposium On Network and Distributed
-    System Security, 1997.
-
-    [7] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic
-    Commerce, July 1995.
-
-    [8] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
-    Request for Comments 2246, January 1999.
-
-    [9] B.C. Neuman, Proxy-Based Authorization and Accounting for
-    Distributed Systems.  In Proceedings of the 13th International
-    Conference on Distributed Computing Systems, May 1993.
-
-    [10] ITU-T (formerly CCITT) Information technology - Open Systems
-    Interconnection - The Directory: Authentication Framework
-    Recommendation X.509 ISO/IEC 9594-8
-
-    [11] R. Housley. Cryptographic Message Syntax.
-    draft-ietf-smime-cms-13.txt, April 1999.
-
-    [12] PKCS #7: Cryptographic Message Syntax Standard,
-    An RSA Laboratories Technical Note Version 1.5
-    Revised November 1, 1993
-
-    [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
-    Security, Inc. A Description of the RC2(r) Encryption Algorithm
-    March 1998.
-    Request for Comments 2268.
-
-    [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
-    Protocol (v3): UTF-8 String Representation of Distinguished Names.
-    Request for Comments 2253.
-
-    [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
-    Key Infrastructure, Certificate and CRL Profile, January 1999.
-    Request for Comments 2459.
-
-    [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-    Specifications, October 1998.
-    Request for Comments 2437.
-
-    [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.
-    S/MIME Version 2 Certificate Handling, March 1998.
-    Request for Comments 2312
-
-8.  Acknowledgements
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-9.  Expiration Date
-
-    This draft expires December 1, 1999.
-
-10. Authors
-
-    Brian Tung
-    Clifford Neuman
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {brian, bcn}@isi.edu
-
-    Matthew Hur
-    CyberSafe Corporation
-    1605 NW Sammamish Road
-    Issaquah WA 98027-5378
-    Phone: +1 425 391 6000
-    E-mail: matt.hur@cybersafe.com
-
-    Ari Medvinsky
-    Excite
-    555 Broadway
-    Redwood City, CA 94063
-    Phone +1 650 569 2119
-    E-mail: amedvins@excitecorp.com
-
-    Sasha Medvinsky
-    General Instrument
-    6450 Sequence Drive
-    San Diego, CA 92121
-    Phone +1 619 404 2825
-    E-mail: smedvinsky@gi.com
-
-    John Wray
-    Iris Associates, Inc.
-    5 Technology Park Dr.
-    Westford, MA 01886
-    E-mail: John_Wray@iris.com
-
-    Jonathan Trostle
-    170 W. Tasman Dr.
-    San Jose, CA 95134
-    E-mail: jtrostle@cisco.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt
deleted file mode 100644
index 7dcb06a60..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-10.txt
+++ /dev/null
@@ -1,957 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-10.txt                   Clifford Neuman
-Updates: RFC 1510                                                    ISI
-expires April 30, 2000                                       Matthew Hur
-                                                   CyberSafe Corporation
-                                                           Ari Medvinsky
-                                                                  Excite
-                                                         Sasha Medvinsky
-                                                      General Instrument
-                                                               John Wray
-                                                   Iris Associates, Inc.
-                                                        Jonathan Trostle
-                                                                   Cisco
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-0.  Status Of This Memo
-
-    This document is an Internet-Draft and is in full conformance with
-    all provisions of Section 10 of RFC 2026.  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."
-
-    The list of current Internet-Drafts can be accessed at
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-    The list of Internet-Draft Shadow Directories can be accessed at
-    http://www.ietf.org/shadow.html.
-
-    To learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ftp.ietf.org (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30,
-    2000.  Please send comments to the authors.
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510 [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to associate a key pair with each realm, which can
-    then be used to facilitate cross-realm authentication; this is the
-    topic of another draft proposal.  Another way is to allow users with
-    public key certificates to use them in initial authentication.  This
-    is the concern of the current document.
-
-    PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
-    combination with digital signature keys as the primary, required
-    mechanism.  It also allows for the use of RSA keys and/or (static)
-    Diffie-Hellman certificates.  Note in particular that PKINIT supports
-    the use of separate signature and encryption keys.
-
-    PKINIT enables access to Kerberos-secured services based on initial
-    authentication utilizing public key cryptography.  PKINIT utilizes
-    standard public key signature and encryption data formats within the
-    standard Kerberos messages.  The basic mechanism is as follows:  The
-    user sends an AS-REQ message to the KDC as before, except that if that
-    user is to use public key cryptography in the initial authentication
-    step, his certificate and a signature accompany the initial request
-    in the preauthentication fields.  Upon receipt of this request, the
-    KDC verifies the certificate and issues a ticket granting ticket
-    (TGT) as before, except that the encPart from the AS-REP message
-    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
-    derived key or the user's public key.  This message is authenticated
-    utilizing the public key signature of the KDC.
-
-    Note that PKINIT does not require the use of certificates.  A KDC
-    may store the public key of a principal as part of that principal's
-    record.  In this scenario, the KDC is the trusted party that vouches
-    for the principal (as in a standard, non-cross realm, Kerberos
-    environment).  Thus, for any principal, the KDC may maintain a
-    secret key, a public key, or both.
-
-    The PKINIT specification may also be used as a building block for
-    other specifications.  PKCROSS [3] utilizes PKINIT for establishing
-    the inter-realm key and associated inter-realm policy to be applied
-    in issuing cross realm service tickets.  As specified in [4],
-    anonymous Kerberos tickets can be issued by applying a NULL
-    signature in combination with Diffie-Hellman in the PKINIT exchange.
-    Additionally, the PKINIT specification may be used for direct peer
-    to peer authentication without contacting a central KDC. This
-    application of PKINIT is described in PKTAPP [5] and is based on
-    concepts introduced in [6, 7]. For direct client-to-server
-    authentication, the client uses PKINIT to authenticate to the end
-    server (instead of a central KDC), which then issues a ticket for
-    itself.  This approach has an advantage over TLS [8] in that the
-    server does not need to save state (cache session keys).
-    Furthermore, an additional benefit is that Kerberos tickets can
-    facilitate delegation (see [9]).
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510 for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following change to RFC 1510 is proposed:
-
-        * Users may authenticate using either a public key pair or a
-          conventional (symmetric) key.  If public key cryptography is
-          used, public key data is transported in preauthentication
-          data fields to help establish identity.  The user presents
-          a public key certificate and obtains an ordinary TGT that may
-          be used for subsequent authentication, with such
-          authentication using only conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 describes the extensions for the initial authentication
-    method.
-
-3.1.  Definitions
-
-    The extensions involve new preauthentication fields; we introduce
-    the following preauthentication types:
-
-        PA-PK-AS-REQ                            14
-        PA-PK-AS-REP                            15
-
-    The extensions also involve new error types; we introduce the
-    following types:
-
-        KDC_ERR_CLIENT_NOT_TRUSTED              62
-        KDC_ERR_KDC_NOT_TRUSTED                 63
-        KDC_ERR_INVALID_SIG                     64
-        KDC_ERR_KEY_TOO_WEAK                    65
-        KDC_ERR_CERTIFICATE_MISMATCH            66
-        KDC_ERR_CANT_VERIFY_CERTIFICATE         70
-        KDC_ERR_INVALID_CERTIFICATE             71
-        KDC_ERR_REVOKED_CERTIFICATE             72
-        KDC_ERR_REVOCATION_STATUS_UNKNOWN       73
-        KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74
-        KDC_ERR_CLIENT_NAME_MISMATCH            75
-        KDC_ERR_KDC_NAME_MISMATCH               76
-
-    We utilize the following typed data for errors:
-
-        TD-PKINIT-CMS-CERTIFICATES             101
-        TD-KRB-PRINCIPAL                       102
-        TD-KRB-REALM                           103
-        TD-TRUSTED-CERTIFIERS                  104
-        TD-CERTIFICATE-INDEX                   105
-
-    We utilize the following encryption types (which map directly to
-    OIDs):
-
-        dsaWithSHA1-CmsOID                       9
-        md5WithRSAEncryption-CmsOID             10
-        sha1WithRSAEncryption-CmsOID            11
-        rc2CBC-EnvOID                           12
-        rsaEncryption-EnvOID (PKCS#1 v1.5)      13
-        rsaES-OAEP-ENV-OID   (PKCS#1 v2.0)      14
-        des-ede3-cbc-Env-OID                    15
-
-    These mappings are provided so that a client may send the
-    appropriate enctypes in the AS-REQ message in order to indicate
-    support for the corresponding OIDs (for performing PKINIT).
-
-    In many cases, PKINIT requires the encoding of the X.500 name of a
-    certificate authority as a Realm.  When such a name appears as
-    a ream it will be represented using the "other" form of the realm
-    name as specified in the naming constraints section of RFC1510.
-    For a realm derived from an X.500 name, NAMETYPE will have the value
-    X500-RFC2253.  The full realm name will appear as follows:
-
-        <nametype> + ":" + <string>
-
-    where nametype is "X500-RFC2253" and string is the result of doing
-    an RFC2253 encoding of the distinguished name, i.e.
-
-        "X500-RFC2253:" + RFC2253Encode(DistinguishedName)
-
-    where DistinguishedName is an X.500 name, and RFC2253Encode is a
-    function returing a readable UTF encoding of an X.500 name, as
-    defined by RFC 2253 [14] (part of LDAPv3 [18]).
-
-    To ensure that this encoding is unique, we add the following rule
-    to those specified by RFC 2253:
-
-        The order in which the attributes appear in the RFC 2253
-        encoding must be the reverse of the order in the ASN.1
-        encoding of the X.500 name that appears in the public key
-        certificate. The order of the relative distinguished names
-        (RDNs), as well as the order of the AttributeTypeAndValues
-        within each RDN, will be reversed. (This is despite the fact
-        that an RDN is defined as a SET of AttributeTypeAndValues, where
-        an order is normally not important.)
-
-    Similarly, in cases where the KDC does not provide a specific
-    policy based mapping from the X.500 name or X.509 Version 3
-    SubjectAltName extension in the user's certificate to a Kerberos
-    principal name, PKINIT requires the direct encoding of the X.500
-    name as a PrincipalName.  In this case, the name-type of the
-    principal name shall be set to KRB_NT-X500-PRINCIPAL.  This new
-    name type is defined in RFC 1510 as:
-
-        KRB_NT_X500_PRINCIPAL    6
-
-    The name-string shall be set as follows:
-
-        RFC2253Encode(DistinguishedName)
-
-    as described above.  When this name type is used, the principal's
-    realm shall be set to the certificate authority's distinguished
-    name using the X500-RFC2253 realm name format described earlier in
-    this section
-
-    RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
-
-        PrincipalName ::=   SEQUENCE {
-                        name-type[0]     INTEGER,
-                        name-string[1]   SEQUENCE OF GeneralString
-        }
-
-    For the purposes of encoding an X.500 name within this structure,
-    the name-string shall be encoded as a single GeneralString.
-
-    Note that name mapping may be required or optional based on
-    policy.  All names must conform to validity requirements as given
-    in RFC 1510.
-
-3.1.1.  Encryption and Key Formats
-
-    In the exposition below, we use the terms public key and private
-    key generically.  It should be understood that the term "public
-    key" may be used to refer to either a public encryption key or a
-    signature verification key, and that the term "private key" may be
-    used to refer to either a private decryption key or a signature
-    generation key.  The fact that these are logically distinct does
-    not preclude the assignment of bitwise identical keys for RSA
-    keys.
-
-    In the case of Diffie-Hellman, the key shall be produced from the
-    agreed bit string as follows:
-
-        * Truncate the bit string to the appropriate length.
-        * Rectify parity in each byte (if necessary) to obtain the key.
-
-    For instance, in the case of a DES key, we take the first eight
-    bytes of the bit stream, and then adjust the least significant bit
-    of each byte to ensure that each byte has odd parity.
-
-3.1.2. Algorithm Identifiers
-
-    PKINIT does not define, but does permit, the algorithm identifiers
-    listed below.
-
-3.1.2.1. Signature Algorithm Identifiers
-
-    The following signature algorithm identifiers specified in [11] and
-    in [15] shall be used with PKINIT:
-
-    id-dsa-with-sha1       (DSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    sha-1WithRSAEncryption (RSA with SHA1)
-
-3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
-
-    The following algorithm identifier shall be used within the
-    SubjectPublicKeyInfo data structure: dhpublicnumber
-
-    This identifier and the associated algorithm parameters are
-    specified in RFC 2459 [15].
-
-3.1.2.3. Algorithm Identifiers for RSA Encryption
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure, for encrypting the temporary key with a public key:
-
-        rsaEncryption (RSA encryption, PKCS#1 v1.5)
-        id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
-
-    Both of the above RSA encryption schemes are specified in [16].
-    Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
-    CMS specification says that it will likely include PKCS#1 v2.0 in
-    the future.  (PKCS#1 v2.0 addresses adaptive chosen ciphertext
-    vulnerability discovered in PKCS#1 v1.5.)
-
-3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure in the PKINIT Reply, for encrypting the reply key with the
-    temporary key:
-        des-ede3-cbc (3-key 3-DES, CBC mode)
-        rc2-cbc      (RC2, CBC mode)
-
-    The full definition of the above algorithm identifiers and their
-    corresponding parameters (an IV for block chaining) is provided in
-    the CMS specification [11].
-
-3.2.  Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with PKINIT.
-
-3.2.1.  Client Request
-
-    Public keys may be signed by some certification authority (CA), or
-    they may be maintained by the KDC in which case the KDC is the
-    trusted authority.  Note that the latter mode does not require the
-    use of certificates.
-
-    The initial authentication request is sent as per RFC 1510, except
-    that a preauthentication field containing data signed by the user's
-    private key accompanies the request:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                -- PA TYPE 14
-        signedAuthPack          [0] SignedData
-                                    -- defined in CMS [11]
-                                    -- AuthPack (below) defines the data
-                                    -- that is signed
-        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
-                                    -- CAs that the client trusts
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
-                                    -- as defined in CMS [11]
-                                    -- specifies a particular KDC
-                                    -- certificate if the client
-                                    -- already has it;
-        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
-                                    -- For example, this may be the
-                                    -- client's Diffie-Hellman
-                                    -- certificate, or it may be the
-                                    -- client's RSA encryption
-                                    -- certificate.
-    }
-
-    TrustedCas ::= CHOICE {
-        principalName         [0] KerberosName,
-                                  -- as defined below
-        caName                [1] Name
-                                  -- fully qualified X.500 name
-                                  -- as defined by X.509
-        issuerAndSerial       [2] IssuerAndSerialNumber
-                                  -- Since a CA may have a number of
-                                  -- certificates, only one of which
-                                  -- a client trusts
-    }
-
-    Usage of SignedData:
-    The SignedData data type is specified in the Cryptographic
-    Message Syntax, a product of the S/MIME working group of the IETF.
-    - The encapContentInfo field must contain the PKAuthenticator
-      and, optionally, the client's Diffie Hellman public value.
-      - The eContentType field shall contain the OID value for
-        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
-        pkcs(1) pkcs7(7) data(1)
-      - The eContent field is data of the type AuthPack (below).
-    - The signerInfos field contains the signature of AuthPack.
-    - The Certificates field, when non-empty, contains the client's
-      certificate chain.  If present, the KDC uses the public key from
-      the client's certificate to verify the signature in the request.
-      Note that the client may pass different certificates that are used
-      for signing or for encrypting.  Thus, the KDC may utilize a
-      different client certificate for signature verification than the
-      one it uses to encrypt the reply to the client.  For example, the
-      client may place a Diffie-Hellman certificate in this field in
-      order to convey its static Diffie Hellman certificate to the KDC to
-      enable static-ephemeral Diffie-Hellman mode for the reply; in this
-      case, the client does NOT place its public value in the AuthPack
-      (defined below).  As another example, the client may place an RSA
-      encryption certificate in this field.  However, there must always
-      be (at least) a signature certificate.
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- if client is using Diffie-Hellman
-                                    -- (ephemeral-ephemeral only)
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        kdcName                 [0] PrincipalName,
-        kdcRealm                [1] Realm,
-        cusec                   [2] INTEGER,
-                                    -- for replay prevention as in RFC1510
-        ctime                   [3] KerberosTime,
-                                    -- for replay prevention as in RFC1510
-        nonce                   [4] INTEGER
-    }
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm                   AlgorithmIdentifier,
-                                    -- dhKeyAgreement
-        subjectPublicKey            BIT STRING
-                                    -- for DH, equals
-                                    -- public exponent (INTEGER encoded
-                                    -- as payload of BIT STRING)
-    }   -- as specified by the X.509 recommendation [10]
-
-    AlgorithmIdentifier ::= SEQUENCE {
-        algorithm                   ALGORITHM.&id,
-        parameters                  ALGORITHM.&type
-    }   -- as specified by the X.509 recommendation [10]
-
-    If the client passes an issuer and serial number in the request,
-    the KDC is requested to use the referred-to certificate.  If none
-    exists, then the KDC returns an error of type
-    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
-    other hand, the client does not pass any trustedCertifiers,
-    believing that it has the KDC's certificate, but the KDC has more
-    than one certificate.  The KDC should include information in the
-    KRB-ERROR message that indicates the KDC certificate(s) that a
-    client may utilize.  This data is specified in the e-data, which
-    is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
-
-    TypedData ::=  SEQUENCE {
-                    data-type      [0] INTEGER,
-                    data-value     [1] OCTET STRING,
-    } -- per Kerberos RFC 1510 revisions
-
-    where:
-    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
-    data-value = CertificateSet // as specified by CMS [11]
-
-    The PKAuthenticator carries information to foil replay attacks, and
-    to bind the request and response.  The PKAuthenticator is signed
-    with the client's signature key.
-
-3.2.2.  KDC Response
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.  This may be based on a certification
-    hierarchy, or it may be simply a list of recognized certifiers in a
-    system like PGP.
-
-    If the client's certificate chain contains no certificate signed by
-    a CA trusted by the KDC, then the KDC sends back an error message
-    of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data
-    is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
-    whose data-value is an OCTET STRING which is the DER encoding of
-
-        TrustedCertifiers ::= SEQUENCE OF PrincipalName
-                              -- X.500 name encoded as a principal name
-                              -- see Section 3.1
-
-    If while verifying a certificate chain the KDC determines that the
-    signature on one of the certificates in the CertificateSet from
-    the signedAuthPack fails verification, then the KDC returns an
-    error of type KDC_ERR_INVALID_CERTIFICATE.  The accompanying
-    e-data is a SEQUENCE of one TypedData (with type
-    TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
-    which is the DER encoding of the index into the CertificateSet
-    ordered as sent by the client.
-
-        CertificateIndex  ::= INTEGER
-                              -- 0 = 1st certificate,
-                              --     (in order of encoding)
-                              -- 1 = 2nd certificate, etc
-
-    The KDC may also check whether any of the certificates in the
-    client's chain has been revoked.  If one of the certificates has
-    been revoked, then the KDC returns an error of type
-    KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
-    the certificate's revocation status is unknown or not
-    available, then if required by policy, the KDC returns the
-    appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
-    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE.  In any of these three
-    cases, the affected certificate is identified by the accompanying
-    e-data, which contains a CertificateIndex as described for
-    KDC_ERR_INVALID_CERTIFICATE.
-
-    If the certificate chain can be verified, but the name of the
-    client in the certificate does not match the client's name in the
-    request, then the KDC returns an error of type
-    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
-    field in this case.
-
-    Finally, if the certificate chain is verified, but the KDC's name
-    or realm as given in the PKAuthenticator does not match the KDC's
-    actual principal name, then the KDC returns an error of type
-    KDC_ERR_KDC_NAME_MISMATCH.  The accompanying e-data field is again
-    a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
-    TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
-    STRING whose data-value is the DER encoding of a PrincipalName or
-    Realm as defined in RFC 1510 revisions.
-
-    Even if all succeeds, the KDC may--for policy reasons--decide not
-    to trust the client.  In this case, the KDC returns an error message
-    of type KDC_ERR_CLIENT_NOT_TRUSTED.
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on AuthPack.  If that fails, the KDC returns an error
-    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
-    timestamp (ctime and cusec) in the PKAuthenticator to assure that
-    the request is not a replay.  The KDC also verifies that its name
-    is specified in the PKAuthenticator.
-
-    If the clientPublicValue field is filled in, indicating that the
-    client wishes to use Diffie-Hellman key agreement, then the KDC
-    checks to see that the parameters satisfy its policy.  If they do
-    not (e.g., the prime size is insufficient for the expected
-    encryption type), then the KDC sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
-    private values for the response.
-
-    The KDC also checks that the timestamp in the PKAuthenticator is
-    within the allowable window and that the principal name and realm
-    are correct.  If the local (server) time and the client time in the
-    authenticator differ by more than the allowable clock skew, then the
-    KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510.
-
-    Assuming no errors, the KDC replies as per RFC 1510, except as
-    follows.  The user's name in the ticket is determined by the
-    following decision algorithm:
-
-        1.  If the KDC has a mapping from the name in the certificate
-            to a Kerberos name, then use that name.
-            Else
-        2.  If the certificate contains the SubjectAltName extention
-            and the local KDC policy defines a mapping from the
-            SubjectAltName to a Kerberos name, then use that name.
-            Else
-        3.  Use the name as represented in the certificate, mapping
-            mapping as necessary (e.g., as per RFC 2253 for X.500
-            names).  In this case the realm in the ticket shall be the
-            name of the certifier that issued the user's certificate.
-
-    Note that a principal name may be carried in the subject alt name
-    field of a certificate. This name may be mapped to a principal
-    record in a security database based on local policy, for example
-    the subject alt name may be kerberos/principal@realm format.  In
-    this case the realm name is not that of the CA but that of the
-    local realm doing the mapping (or some realm name chosen by that
-    realm).
-
-    If a non-KDC X.509 certificate contains the principal name within
-    the subjectAltName version 3 extension , that name may utilize
-    KerberosName as defined below, or, in the case of an S/MIME
-    certificate [17], may utilize the email address.  If the KDC
-    is presented with as S/MIME certificate, then the email address
-    within subjectAltName will be interpreted as a principal and realm
-    separated by the "@" sign, or as a name that needs to be
-    canonicalized.  If the resulting name does not correspond to a
-    registered principal name, then the principal name is formed as
-    defined in section 3.1.
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.  If the KDC has no
-    certificate signed by any of the trustedCertifiers, then it returns
-    an error of type KDC_ERR_KDC_NOT_TRUSTED.
-
-    KDCs should try to (in order of preference):
-    1. Use the KDC certificate identified by the serialNumber included
-       in the client's request.
-    2. Use a certificate issued to the KDC by the client's CA (if in the
-       middle of a CA key roll-over, use the KDC cert issued under same
-       CA key as user cert used to verify request).
-    3. Use a certificate issued to the KDC by one of the client's
-       trustedCertifier(s);
-    If the KDC is unable to comply with any of these options, then the
-    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
-    client.
-
-    The KDC encrypts the reply not with the user's long-term key, but
-    with the Diffie Hellman derived key or a random key generated
-    for this particular response which is carried in the padata field of
-    the TGS-REP message.
-
-    PA-PK-AS-REP ::= CHOICE {
-                            -- PA TYPE 15
-        dhSignedData       [0] SignedData,
-                            -- Defined in CMS and used only with
-                            -- Diffie-Hellman key exchange (if the
-                            -- client public value was present in the
-                            -- request).
-                            -- This choice MUST be supported
-                            -- by compliant implementations.
-        encKeyPack         [1] EnvelopedData,
-                            -- Defined in CMS
-                            -- The temporary key is encrypted
-                            -- using the client public key
-                            -- key
-                            -- SignedReplyKeyPack, encrypted
-                            -- with the temporary key, is also
-                            -- included.
-    }
-
-    Usage of SignedData:
-    If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP
-    provides authenticated Diffie-Hellman parameters of the KDC.  The
-    reply key used to encrypt part of the KDC reply message is derived
-    from the Diffie-Hellman exchange:
-    - Both the KDC and the client calculate a secret value (g^ab mod p),
-      where a is the client's private exponent and b is the KDC's
-      private exponent.
-    - Both the KDC and the client take the first N bits of this secret
-      value and convert it into a reply key.  N depends on the reply key
-      type.
-    - If the reply key is DES, N=64 bits, where some of the bits are
-      replaced with parity bits, according to FIPS PUB 74.
-    - If the reply key is (3-key) 3-DES, N=192 bits, where some of the
-      bits are replaced with parity bits, according to FIPS PUB 74.
-    - The encapContentInfo field must contain the KdcDHKeyInfo as
-      defined below.
-      - The eContentType field shall contain the OID value for
-        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
-        pkcs(1) pkcs7(7) data(1)
-    - The certificates field must contain the certificates necessary
-      for the client to establish trust in the KDC's certificate
-      based on the list of trusted certifiers sent by the client in
-      the PA-PK-AS-REQ.  This field may be empty if the client did
-      not send to the KDC a list of trusted certifiers (the
-      trustedCertifiers field was empty, meaning that the client
-      already possesses the KDC's certificate).
-    - The signerInfos field is a SET that must contain at least one
-      member, since it contains the actual signature.
-
-    KdcDHKeyInfo ::= SEQUENCE {
-                              -- used only when utilizing Diffie-Hellman
-      nonce                 [0] INTEGER,
-                                -- binds responce to the request
-      subjectPublicKey      [2] BIT STRING
-                                -- Equals public exponent (g^a mod p)
-                                -- INTEGER encoded as payload of
-                                -- BIT STRING
-    }
-
-    Usage of EnvelopedData:
-    The EnvelopedData data type is specified in the Cryptographic
-    Message Syntax, a product of the S/MIME working group of the IETF.
-    It contains an temporary key encrypted with the PKINIT
-    client's public key.  It also contains a signed and encrypted
-    reply key.
-    - The originatorInfo field is not required, since that information
-      may be presented in the signedData structure that is encrypted
-      within the encryptedContentInfo field.
-    - The optional unprotectedAttrs field is not required for PKINIT.
-    - The recipientInfos field is a SET which must contain exactly one
-      member of the KeyTransRecipientInfo type for encryption
-      with an RSA public key.
-         - The encryptedKey field (in KeyTransRecipientInfo) contains
-           the temporary key which is encrypted with the PKINIT client's
-           public key.
-    - The encryptedContentInfo field contains the signed and encrypted
-      reply key.
-      - The contentType field shall contain the OID value for
-        id-signedData: iso(1) member-body(2) us(840) rsadsi(113549)
-        pkcs(1) pkcs7(7) signedData(2)
-      - The encryptedContent field is encrypted data of the CMS type
-        signedData as specified below.
-        - The encapContentInfo field must contains the ReplyKeyPack.
-          - The eContentType field shall contain the OID value for
-            id-data: iso(1) member-body(2) us(840) rsadsi(113549)
-            pkcs(1) pkcs7(7) data(1)
-          - The eContent field is data of the type ReplyKeyPack (below).
-        - The certificates field must contain the certificates necessary
-          for the client to establish trust in the KDC's certificate
-          based on the list of trusted certifiers sent by the client in
-          the PA-PK-AS-REQ.  This field may be empty if the client did
-          not send to the KDC a list of trusted certifiers (the
-          trustedCertifiers field was empty, meaning that the client
-          already possesses the KDC's certificate).
-        - The signerInfos field is a SET that must contain at least one
-          member, since it contains the actual signature.
-
-    ReplyKeyPack ::= SEQUENCE {
-                              -- not used for Diffie-Hellman
-        replyKey             [0] EncryptionKey,
-                                 -- used to encrypt main reply
-                                 -- ENCTYPE is at least as strong as
-                                 -- ENCTYPE of session key
-        nonce                [1] INTEGER,
-                                 -- binds response to the request
-                                 -- must be same as the nonce
-                                 -- passed in the PKAuthenticator
-    }
-
-    Since each certifier in the certification path of a user's
-    certificate is equivalent to a separate Kerberos realm, the name
-    of each certifier in the certificate chain must be added to the
-    transited field of the ticket.  The format of these realm names is
-    defined in Section 3.1 of this document.  If applicable, the
-    transit-policy-checked flag should be set in the issued ticket.
-
-    The KDC's certificate(s) must bind the public key(s) of the KDC to
-    a name derivable from the name of the realm for that KDC.  X.509
-    certificates shall contain the principal name of the KDC
-    (defined in section 8.2 of RFC 1510) as the SubjectAltName version
-    3 extension. Below is the definition of this version 3 extension,
-    as specified by the X.509 standard:
-
-        subjectAltName EXTENSION ::= {
-            SYNTAX GeneralNames
-            IDENTIFIED BY id-ce-subjectAltName
-        }
-
-        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
-
-        GeneralName ::= CHOICE {
-            otherName       [0] INSTANCE OF OTHER-NAME,
-            ...
-        }
-
-        OTHER-NAME ::= TYPE-IDENTIFIER
-
-    In this definition, otherName is a name of any form defined as an
-    instance of the OTHER-NAME information object class. For the purpose
-    of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
-    be chosen and replaced by the type KerberosName:
-
-        KerberosName ::= SEQUENCE {
-          realm           [0] Realm,
-                              -- as defined in RFC 1510
-          principalName   [1] PrincipalName,
-                              -- as defined in RFC 1510
-        }
-
-    This specific syntax is identified within subjectAltName by setting
-    the OID id-ce-subjectAltName to krb5PrincipalName, where (from the
-    Kerberos specification) we have
-
-        krb5 OBJECT IDENTIFIER ::= { iso (1)
-                                     org (3)
-                                     dod (6)
-                                     internet (1)
-                                     security (5)
-                                     kerberosv5 (2) }
-
-        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
-
-    (This specification may also be used to specify a Kerberos name
-    within the user's certificate.)  The KDC's certificate may be signed
-    directly by a CA, or there may be intermediaries if the server resides
-    within a large organization, or it may be unsigned if the client
-    indicates possession (and trust) of the KDC's certificate.
-
-    The client then extracts the random key used to encrypt the main
-    reply.  This random key (in encPaReply) is encrypted with either the
-    client's public key or with a key derived from the DH values
-    exchanged between the client and the KDC.  The client uses this
-    random key to decrypt the main reply, and subsequently proceeds as
-    described in RFC 1510.
-
-3.2.3. Required Algorithms
-
-    Not all of the algorithms in the PKINIT protocol specification have
-    to be implemented in order to comply with the proposed standard.
-    Below is a list of the required algorithms:
-
-    - Diffie-Hellman public/private key pairs
-      - utilizing Diffie-Hellman ephemeral-ephemeral mode
-    - SHA1 digest and DSA for signatures
-    - 3-key triple DES keys derived from the Diffie-Hellman Exchange
-    - 3-key triple DES Temporary and Reply keys
-
-4.  Logistics and Policy
-
-    This section describes a way to define the policy on the use of
-    PKINIT for each principal and request.
-
-    The KDC is not required to contain a database record for users
-    who use public key authentication.  However, if these users are
-    registered with the KDC, it is recommended that the database record
-    for these users be modified to an additional flag in the attributes
-    field to indicate that the user should authenticate using PKINIT.
-    If this flag is set and a request message does not contain the
-    PKINIT preauthentication field, then the KDC sends back as error of
-    type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
-    field of type PA-PK-AS-REQ must be included in the request.
-
-5.  Security Considerations
-
-    PKINIT raises a few security considerations, which we will address
-    in this section.
-
-    First of all, PKINIT introduces a new trust model, where KDCs do not
-    (necessarily) certify the identity of those for whom they issue
-    tickets.  PKINIT does allow KDCs to act as their own CAs, in order
-    to simplify key management, but one of the additional benefits is to
-    align Kerberos authentication with a global public key
-    infrastructure.  Anyone using PKINIT in this way must be aware of
-    how the certification infrastructure they are linking to works.
-
-    Secondly, PKINIT also introduces the possibility of interactions
-    between different cryptosystems, which may be of widely varying
-    strengths.  Many systems, for instance, allow the use of 512-bit
-    public keys.  Using such keys to wrap data encrypted under strong
-    conventional cryptosystems, such as triple-DES, is inappropriate;
-    it adds a weak link to a strong one at extra cost.  Implementors
-    and administrators should take care to avoid such wasteful and
-    deceptive interactions.
-
-    Lastly, PKINIT calls for randomly generated keys for conventional
-    cryptosystems.  Many such systems contain systematically "weak"
-    keys.  PKINIT implementations MUST avoid use of these keys, either
-    by discarding those keys when they are generated, or by fixing them
-    in some way (e.g., by XORing them with a given mask).  These
-    precautions vary from system to system; it is not our intention to
-    give an explicit recipe for them here.
-
-6.  Transport Issues
-
-    Certificate chains can potentially grow quite large and span several
-    UDP packets; this in turn increases the probability that a Kerberos
-    message involving PKINIT extensions will be broken in transit.  In
-    light of the possibility that the Kerberos specification will
-    require KDCs to accept requests using TCP as a transport mechanism,
-    we make the same recommendation with respect to the PKINIT
-    extensions as well.
-
-7.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-    (V5).  Request for Comments 1510.
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.  September
-    1994.
-
-    [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
-    A. Medvinsky, M. Hur.  Public Key Cryptography for Cross-Realm
-    Authentication in Kerberos.
-    draft-ietf-cat-kerberos-pk-cross-04.txt
-
-    [4] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
-    Kerberos.
-    draft-ietf-cat-kerberos-anoncred-00.txt
-
-    [5] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
-    Tickets for Application Servers (PKTAPP).
-    draft-ietf-cat-pktapp-00.txt
-
-    [6] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-    Using Public Key Cryptography.  Symposium On Network and Distributed
-    System Security, 1997.
-
-    [7] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic
-    Commerce, July 1995.
-
-    [8] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
-    Request for Comments 2246, January 1999.
-
-    [9] B.C. Neuman, Proxy-Based Authorization and Accounting for
-    Distributed Systems.  In Proceedings of the 13th International
-    Conference on Distributed Computing Systems, May 1993.
-
-    [10] ITU-T (formerly CCITT) Information technology - Open Systems
-    Interconnection - The Directory: Authentication Framework
-    Recommendation X.509 ISO/IEC 9594-8
-
-    [11] R. Housley. Cryptographic Message Syntax.
-    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
-    as RFC.
-
-    [12] PKCS #7: Cryptographic Message Syntax Standard,
-    An RSA Laboratories Technical Note Version 1.5
-    Revised November 1, 1993
-
-    [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
-    Security, Inc. A Description of the RC2(r) Encryption Algorithm
-    March 1998.
-    Request for Comments 2268.
-
-    [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
-    Protocol (v3): UTF-8 String Representation of Distinguished Names.
-    Request for Comments 2253.
-
-    [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
-    Key Infrastructure, Certificate and CRL Profile, January 1999.
-    Request for Comments 2459.
-
-    [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-    Specifications, October 1998.  Request for Comments 2437.
-
-    [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
-    Version 2 Certificate Handling, March 1998.  Request for
-    Comments 2312.
-
-    [18] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
-    Protocol (v3), December 1997.  Request for Comments 2251.
-
-8.  Acknowledgements
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-9.  Expiration Date
-
-    This draft expires April 30, 2000.
-
-10. Authors
-
-    Brian Tung
-    Clifford Neuman
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {brian, bcn}@isi.edu
-
-    Matthew Hur
-    CyberSafe Corporation
-    1605 NW Sammamish Road
-    Issaquah WA 98027-5378
-    Phone: +1 425 391 6000
-    E-mail: matt.hur@cybersafe.com
-
-    Ari Medvinsky
-    Excite
-    555 Broadway
-    Redwood City, CA 94063
-    Phone +1 650 569 2119
-    E-mail: amedvins@excitecorp.com
-
-    Sasha Medvinsky
-    General Instrument
-    6450 Sequence Drive
-    San Diego, CA 92121
-    Phone +1 619 404 2825
-    E-mail: smedvinsky@gi.com
-
-    John Wray
-    Iris Associates, Inc.
-    5 Technology Park Dr.
-    Westford, MA 01886
-    E-mail: John_Wray@iris.com
-
-    Jonathan Trostle
-    170 W. Tasman Dr.
-    San Jose, CA 95134
-    E-mail: jtrostle@cisco.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt
deleted file mode 100644
index 9b0e76ada..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-11.txt
+++ /dev/null
@@ -1,1059 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-11.txt                   Clifford Neuman
-Updates: RFC 1510                                                USC/ISI
-expires September 15, 2000                                   Matthew Hur
-                                                   CyberSafe Corporation
-                                                           Ari Medvinsky
-                                                          Keen.com, Inc.
-                                                         Sasha Medvinsky
-                                                                Motorola
-                                                               John Wray
-                                                   Iris Associates, Inc.
-                                                        Jonathan Trostle
-                                                                   Cisco
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-0.  Status Of This Memo
-
-    This document is an Internet-Draft and is in full conformance with
-    all provisions of Section 10 of RFC 2026.  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."
-
-    The list of current Internet-Drafts can be accessed at
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-    The list of Internet-Draft Shadow Directories can be accessed at
-    http://www.ietf.org/shadow.html.
-
-    To learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ftp.ietf.org (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-11.txt, and expires September 15,
-    2000.  Please send comments to the authors.
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510 [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to associate a key pair with each realm, which can
-    then be used to facilitate cross-realm authentication; this is the
-    topic of another draft proposal.  Another way is to allow users with
-    public key certificates to use them in initial authentication.  This
-    is the concern of the current document.
-
-    PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
-    combination with digital signature keys as the primary, required
-    mechanism.  It also allows for the use of RSA keys and/or (static)
-    Diffie-Hellman certificates.  Note in particular that PKINIT supports
-    the use of separate signature and encryption keys.
-
-    PKINIT enables access to Kerberos-secured services based on initial
-    authentication utilizing public key cryptography.  PKINIT utilizes
-    standard public key signature and encryption data formats within the
-    standard Kerberos messages.  The basic mechanism is as follows:  The
-    user sends an AS-REQ message to the KDC as before, except that if that
-    user is to use public key cryptography in the initial authentication
-    step, his certificate and a signature accompany the initial request
-    in the preauthentication fields.  Upon receipt of this request, the
-    KDC verifies the certificate and issues a ticket granting ticket
-    (TGT) as before, except that the encPart from the AS-REP message
-    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
-    derived key or the user's public key.  This message is authenticated
-    utilizing the public key signature of the KDC.
-
-    Note that PKINIT does not require the use of certificates.  A KDC
-    may store the public key of a principal as part of that principal's
-    record.  In this scenario, the KDC is the trusted party that vouches
-    for the principal (as in a standard, non-cross realm, Kerberos
-    environment).  Thus, for any principal, the KDC may maintain a
-    secret key, a public key, or both.
-
-    The PKINIT specification may also be used as a building block for
-    other specifications.  PKCROSS [3] utilizes PKINIT for establishing
-    the inter-realm key and associated inter-realm policy to be applied
-    in issuing cross realm service tickets.  As specified in [4],
-    anonymous Kerberos tickets can be issued by applying a NULL
-    signature in combination with Diffie-Hellman in the PKINIT exchange.
-    Additionally, the PKINIT specification may be used for direct peer
-    to peer authentication without contacting a central KDC. This
-    application of PKINIT is described in PKTAPP [5] and is based on
-    concepts introduced in [6, 7]. For direct client-to-server
-    authentication, the client uses PKINIT to authenticate to the end
-    server (instead of a central KDC), which then issues a ticket for
-    itself.  This approach has an advantage over TLS [8] in that the
-    server does not need to save state (cache session keys).
-    Furthermore, an additional benefit is that Kerberos tickets can
-    facilitate delegation (see [9]).
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510 for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following change to RFC 1510 is proposed:
-
-        * Users may authenticate using either a public key pair or a
-          conventional (symmetric) key.  If public key cryptography is
-          used, public key data is transported in preauthentication
-          data fields to help establish identity.  The user presents
-          a public key certificate and obtains an ordinary TGT that may
-          be used for subsequent authentication, with such
-          authentication using only conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 describes the extensions for the initial authentication
-    method.
-
-3.1.  Definitions
-
-    The extensions involve new preauthentication fields; we introduce
-    the following preauthentication types:
-
-        PA-PK-AS-REQ                            14
-        PA-PK-AS-REP                            15
-
-    The extensions also involve new error types; we introduce the
-    following types:
-
-        KDC_ERR_CLIENT_NOT_TRUSTED              62
-        KDC_ERR_KDC_NOT_TRUSTED                 63
-        KDC_ERR_INVALID_SIG                     64
-        KDC_ERR_KEY_TOO_WEAK                    65
-        KDC_ERR_CERTIFICATE_MISMATCH            66
-        KDC_ERR_CANT_VERIFY_CERTIFICATE         70
-        KDC_ERR_INVALID_CERTIFICATE             71
-        KDC_ERR_REVOKED_CERTIFICATE             72
-        KDC_ERR_REVOCATION_STATUS_UNKNOWN       73
-        KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74
-        KDC_ERR_CLIENT_NAME_MISMATCH            75
-        KDC_ERR_KDC_NAME_MISMATCH               76
-
-    We utilize the following typed data for errors:
-
-        TD-PKINIT-CMS-CERTIFICATES             101
-        TD-KRB-PRINCIPAL                       102
-        TD-KRB-REALM                           103
-        TD-TRUSTED-CERTIFIERS                  104
-        TD-CERTIFICATE-INDEX                   105
-
-    We utilize the following encryption types (which map directly to
-    OIDs):
-
-        dsaWithSHA1-CmsOID                       9
-        md5WithRSAEncryption-CmsOID             10
-        sha1WithRSAEncryption-CmsOID            11
-        rc2CBC-EnvOID                           12
-        rsaEncryption-EnvOID (PKCS#1 v1.5)      13
-        rsaES-OAEP-ENV-OID   (PKCS#1 v2.0)      14
-        des-ede3-cbc-Env-OID                    15
-
-    These mappings are provided so that a client may send the
-    appropriate enctypes in the AS-REQ message in order to indicate
-    support for the corresponding OIDs (for performing PKINIT).
-
-    In many cases, PKINIT requires the encoding of the X.500 name of a
-    certificate authority as a Realm.  When such a name appears as
-    a realm it will be represented using the "other" form of the realm
-    name as specified in the naming constraints section of RFC1510.
-    For a realm derived from an X.500 name, NAMETYPE will have the value
-    X500-RFC2253.  The full realm name will appear as follows:
-
-        <nametype> + ":" + <string>
-
-    where nametype is "X500-RFC2253" and string is the result of doing
-    an RFC2253 encoding of the distinguished name, i.e.
-
-        "X500-RFC2253:" + RFC2253Encode(DistinguishedName)
-
-    where DistinguishedName is an X.500 name, and RFC2253Encode is a
-    function returing a readable UTF encoding of an X.500 name, as
-    defined by RFC 2253 [14] (part of LDAPv3 [18]).
-
-    To ensure that this encoding is unique, we add the following rule
-    to those specified by RFC 2253:
-
-        The order in which the attributes appear in the RFC 2253
-        encoding must be the reverse of the order in the ASN.1
-        encoding of the X.500 name that appears in the public key
-        certificate. The order of the relative distinguished names
-        (RDNs), as well as the order of the AttributeTypeAndValues
-        within each RDN, will be reversed. (This is despite the fact
-        that an RDN is defined as a SET of AttributeTypeAndValues, where
-        an order is normally not important.)
-
-    Similarly, in cases where the KDC does not provide a specific
-    policy based mapping from the X.500 name or X.509 Version 3
-    SubjectAltName extension in the user's certificate to a Kerberos
-    principal name, PKINIT requires the direct encoding of the X.500
-    name as a PrincipalName.  In this case, the name-type of the
-    principal name shall be set to KRB_NT-X500-PRINCIPAL.  This new
-    name type is defined in RFC 1510 as:
-
-        KRB_NT_X500_PRINCIPAL    6
-
-    The name-string shall be set as follows:
-
-        RFC2253Encode(DistinguishedName)
-
-    as described above.  When this name type is used, the principal's
-    realm shall be set to the certificate authority's distinguished
-    name using the X500-RFC2253 realm name format described earlier in
-    this section
-
-    RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
-
-        PrincipalName ::=   SEQUENCE {
-                        name-type[0]     INTEGER,
-                        name-string[1]   SEQUENCE OF GeneralString
-        }
-
-    For the purposes of encoding an X.500 name as a Kerberos name for
-    use in Kerberos structures, the name-string shall be encoded as a
-    single GeneralString.  The name-type should be KRB_NT_X500_PRINCIPAL,
-    as noted above.  All Kerberos names must conform to validity
-    requirements as given in RFC 1510.  Note that name mapping may be
-    required or optional, based on policy.
-
-    We also define the following similar ASN.1 structure:
-
-        CertPrincipalName ::= SEQUENCE {
-                        name-type[0]     INTEGER,
-                        name-string[1]   SEQUENCE OF UTF8String
-        }
-
-    When a Kerberos PrincipalName is to be placed within an X.509 data
-    structure, the CertPrincipalName structure is to be used, with the
-    name-string encoded as a single UTF8String.  The name-type should be
-    as identified in the original PrincipalName structure.  The mapping
-    between the GeneralString and UTF8String formats can be found in
-    [19].
-
-    The following rules relate to the the matching of PrincipalNames (or
-    corresponding CertPrincipalNames) with regard to the PKI name
-    constraints for CAs as laid out in RFC 2459 [15].  In order to be
-    regarded as a match (for permitted and excluded name trees), the
-    following must be satisfied.
-
-        1.  If the constraint is given as a user plus realm name, or
-            as a user plus instance plus realm name (as specified in
-            RFC 1510), the realm name must be valid (see 2.a-d below)
-            and the match must be exact, byte for byte.
-
-        2.  If the constraint is given only as a realm name, matching
-            depends on the type of the realm:
-
-            a.  If the realm contains a colon (':') before any equal
-                sign ('='), it is treated as a realm of type Other,
-                and must match exactly, byte for byte.
-
-            b.  Otherwise, if the realm contains an equal sign, it
-                is treated as an X.500 name.  In order to match, every
-                component in the constraint MUST be in the principal
-                name, and have the same value.  For example, 'C=US'
-                matches 'C=US/O=ISI' but not 'C=UK'.
-
-            c.  Otherwise, if the realm name conforms to rules regarding
-                the format of DNS names, it is considered a realm name of
-                type Domain.  The constraint may be given as a realm
-                name 'FOO.BAR', which matches any PrincipalName within
-                the realm 'FOO.BAR' but not those in subrealms such as
-                'CAR.FOO.BAR'.  A constraint of the form '.FOO.BAR'
-                matches PrincipalNames in subrealms of the form
-                'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
-
-            d.  Otherwise, the realm name is invalid and does not match
-                under any conditions.
-
-3.1.1.  Encryption and Key Formats
-
-    In the exposition below, we use the terms public key and private
-    key generically.  It should be understood that the term "public
-    key" may be used to refer to either a public encryption key or a
-    signature verification key, and that the term "private key" may be
-    used to refer to either a private decryption key or a signature
-    generation key.  The fact that these are logically distinct does
-    not preclude the assignment of bitwise identical keys for RSA
-    keys.
-
-    In the case of Diffie-Hellman, the key shall be produced from the
-    agreed bit string as follows:
-
-        * Truncate the bit string to the appropriate length.
-        * Rectify parity in each byte (if necessary) to obtain the key.
-
-    For instance, in the case of a DES key, we take the first eight
-    bytes of the bit stream, and then adjust the least significant bit
-    of each byte to ensure that each byte has odd parity.
-
-3.1.2. Algorithm Identifiers
-
-    PKINIT does not define, but does permit, the algorithm identifiers
-    listed below.
-
-3.1.2.1. Signature Algorithm Identifiers
-
-    The following signature algorithm identifiers specified in [11] and
-    in [15] shall be used with PKINIT:
-
-    id-dsa-with-sha1       (DSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    sha-1WithRSAEncryption (RSA with SHA1)
-
-3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
-
-    The following algorithm identifier shall be used within the
-    SubjectPublicKeyInfo data structure: dhpublicnumber
-
-    This identifier and the associated algorithm parameters are
-    specified in RFC 2459 [15].
-
-3.1.2.3. Algorithm Identifiers for RSA Encryption
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure, for encrypting the temporary key with a public key:
-
-        rsaEncryption (RSA encryption, PKCS#1 v1.5)
-        id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
-
-    Both of the above RSA encryption schemes are specified in [16].
-    Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
-    CMS specification says that it will likely include PKCS#1 v2.0 in
-    the future.  (PKCS#1 v2.0 addresses adaptive chosen ciphertext
-    vulnerability discovered in PKCS#1 v1.5.)
-
-3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure in the PKINIT Reply, for encrypting the reply key with the
-    temporary key:
-        des-ede3-cbc (3-key 3-DES, CBC mode)
-        rc2-cbc      (RC2, CBC mode)
-
-    The full definition of the above algorithm identifiers and their
-    corresponding parameters (an IV for block chaining) is provided in
-    the CMS specification [11].
-
-3.2.  Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with PKINIT.
-
-3.2.1.  Client Request
-
-    Public keys may be signed by some certification authority (CA), or
-    they may be maintained by the KDC in which case the KDC is the
-    trusted authority.  Note that the latter mode does not require the
-    use of certificates.
-
-    The initial authentication request is sent as per RFC 1510, except
-    that a preauthentication field containing data signed by the user's
-    private key accompanies the request:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                -- PA TYPE 14
-        signedAuthPack          [0] SignedData
-                                    -- Defined in CMS [11];
-                                    -- AuthPack (below) defines the
-                                    -- data that is signed.
-        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
-                                    -- This is a list of CAs that the
-                                    -- client trusts and that certify
-                                    -- KDCs.
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
-                                    -- As defined in CMS [11];
-                                    -- specifies a particular KDC
-                                    -- certificate if the client
-                                    -- already has it.
-        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
-                                    -- For example, this may be the
-                                    -- client's Diffie-Hellman
-                                    -- certificate, or it may be the
-                                    -- client's RSA encryption
-                                    -- certificate.
-    }
-
-    TrustedCas ::= CHOICE {
-        principalName         [0] KerberosName,
-                                  -- as defined below
-        caName                [1] Name
-                                  -- fully qualified X.500 name
-                                  -- as defined by X.509
-        issuerAndSerial       [2] IssuerAndSerialNumber
-                                  -- Since a CA may have a number of
-                                  -- certificates, only one of which
-                                  -- a client trusts
-    }
-
-    Usage of SignedData:
-
-        The SignedData data type is specified in the Cryptographic
-        Message Syntax, a product of the S/MIME working group of the
-        IETF.  The following describes how to fill in the fields of
-        this data:
-
-        1.  The encapContentInfo field must contain the PKAuthenticator
-            and, optionally, the client's Diffie Hellman public value.
-
-            a.  The eContentType field shall contain the OID value for
-                pkdata: iso (1) org (3) dod (6) internet (1) security (5)
-                kerberosv5 (2) pkinit (3) pkdata (1)
-
-            b.  The eContent field is data of the type AuthPack (below).
-
-        2.  The signerInfos field contains the signature of AuthPack.
-
-        3.  The Certificates field, when non-empty, contains the client's
-            certificate chain.  If present, the KDC uses the public key
-            from the client's certificate to verify the signature in the
-            request.  Note that the client may pass different certificate
-            chains that are used for signing or for encrypting.  Thus,
-            the KDC may utilize a different client certificate for
-            signature verification than the one it uses to encrypt the
-            reply to the client.  For example, the client may place a
-            Diffie-Hellman certificate in this field in order to convey
-            its static Diffie Hellman certificate to the KDC to enable
-            static-ephemeral Diffie-Hellman mode for the reply; in this
-            case, the client does NOT place its public value in the
-            AuthPack (defined below).  As another example, the client may
-            place an RSA encryption certificate in this field.  However,
-            there must always be (at least) a signature certificate.
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- if client is using Diffie-Hellman
-                                    -- (ephemeral-ephemeral only)
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        kdcName                 [0] PrincipalName,
-        kdcRealm                [1] Realm,
-        cusec                   [2] INTEGER,
-                                    -- for replay prevention as in RFC1510
-        ctime                   [3] KerberosTime,
-                                    -- for replay prevention as in RFC1510
-        nonce                   [4] INTEGER
-    }
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm                   AlgorithmIdentifier,
-                                    -- dhKeyAgreement
-        subjectPublicKey            BIT STRING
-                                    -- for DH, equals
-                                    -- public exponent (INTEGER encoded
-                                    -- as payload of BIT STRING)
-    }   -- as specified by the X.509 recommendation [10]
-
-    AlgorithmIdentifier ::= SEQUENCE {
-        algorithm                   ALGORITHM.&id,
-        parameters                  ALGORITHM.&type
-    }   -- as specified by the X.509 recommendation [10]
-
-    If the client passes an issuer and serial number in the request,
-    the KDC is requested to use the referred-to certificate.  If none
-    exists, then the KDC returns an error of type
-    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
-    other hand, the client does not pass any trustedCertifiers,
-    believing that it has the KDC's certificate, but the KDC has more
-    than one certificate.  The KDC should include information in the
-    KRB-ERROR message that indicates the KDC certificate(s) that a
-    client may utilize.  This data is specified in the e-data, which
-    is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
-
-    TypedData ::=  SEQUENCE {
-                    data-type      [0] INTEGER,
-                    data-value     [1] OCTET STRING,
-    } -- per Kerberos RFC 1510 revisions
-
-    where:
-    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
-    data-value = CertificateSet // as specified by CMS [11]
-
-    The PKAuthenticator carries information to foil replay attacks, and
-    to bind the request and response.  The PKAuthenticator is signed
-    with the client's signature key.
-
-3.2.2.  KDC Response
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.  This may be based on a certification
-    hierarchy, or it may be simply a list of recognized certifiers in a
-    system like PGP.
-
-    If the client's certificate chain contains no certificate signed by
-    a CA trusted by the KDC, then the KDC sends back an error message
-    of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data
-    is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
-    whose data-value is an OCTET STRING which is the DER encoding of
-
-        TrustedCertifiers ::= SEQUENCE OF PrincipalName
-                              -- X.500 name encoded as a principal name
-                              -- see Section 3.1
-
-    If while verifying a certificate chain the KDC determines that the
-    signature on one of the certificates in the CertificateSet from
-    the signedAuthPack fails verification, then the KDC returns an
-    error of type KDC_ERR_INVALID_CERTIFICATE.  The accompanying
-    e-data is a SEQUENCE of one TypedData (with type
-    TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
-    which is the DER encoding of the index into the CertificateSet
-    ordered as sent by the client.
-
-        CertificateIndex  ::= INTEGER
-                              -- 0 = 1st certificate,
-                              --     (in order of encoding)
-                              -- 1 = 2nd certificate, etc
-
-    The KDC may also check whether any of the certificates in the
-    client's chain has been revoked.  If one of the certificates has
-    been revoked, then the KDC returns an error of type
-    KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
-    the certificate's revocation status is unknown or not
-    available, then if required by policy, the KDC returns the
-    appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
-    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE.  In any of these three
-    cases, the affected certificate is identified by the accompanying
-    e-data, which contains a CertificateIndex as described for
-    KDC_ERR_INVALID_CERTIFICATE.
-
-    If the certificate chain can be verified, but the name of the
-    client in the certificate does not match the client's name in the
-    request, then the KDC returns an error of type
-    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
-    field in this case.
-
-    Finally, if the certificate chain is verified, but the KDC's name
-    or realm as given in the PKAuthenticator does not match the KDC's
-    actual principal name, then the KDC returns an error of type
-    KDC_ERR_KDC_NAME_MISMATCH.  The accompanying e-data field is again
-    a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
-    TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
-    STRING whose data-value is the DER encoding of a PrincipalName or
-    Realm as defined in RFC 1510 revisions.
-
-    Even if all succeeds, the KDC may--for policy reasons--decide not
-    to trust the client.  In this case, the KDC returns an error message
-    of type KDC_ERR_CLIENT_NOT_TRUSTED.  One specific case of this is
-    the presence or absence of an Enhanced Key Usage (EKU) OID within
-    the certificate extensions.  The rules regarding acceptability of
-    an EKU sequence (or the absence of any sequence) are a matter of
-    local policy.  For the benefit of implementers, we define a PKINIT
-    EKU OID as the following: iso (1) org (3) dod (6) internet (1)
-    security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on AuthPack.  If that fails, the KDC returns an error
-    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
-    timestamp (ctime and cusec) in the PKAuthenticator to assure that
-    the request is not a replay.  The KDC also verifies that its name
-    is specified in the PKAuthenticator.
-
-    If the clientPublicValue field is filled in, indicating that the
-    client wishes to use Diffie-Hellman key agreement, then the KDC
-    checks to see that the parameters satisfy its policy.  If they do
-    not (e.g., the prime size is insufficient for the expected
-    encryption type), then the KDC sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
-    private values for the response.
-
-    The KDC also checks that the timestamp in the PKAuthenticator is
-    within the allowable window and that the principal name and realm
-    are correct.  If the local (server) time and the client time in the
-    authenticator differ by more than the allowable clock skew, then the
-    KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510.
-
-    Assuming no errors, the KDC replies as per RFC 1510, except as
-    follows.  The user's name in the ticket is determined by the
-    following decision algorithm:
-
-        1.  If the KDC has a mapping from the name in the certificate
-            to a Kerberos name, then use that name.
-            Else
-        2.  If the certificate contains the SubjectAltName extention
-            and the local KDC policy defines a mapping from the
-            SubjectAltName to a Kerberos name, then use that name.
-            Else
-        3.  Use the name as represented in the certificate, mapping
-            mapping as necessary (e.g., as per RFC 2253 for X.500
-            names).  In this case the realm in the ticket shall be the
-            name of the certifier that issued the user's certificate.
-
-    Note that a principal name may be carried in the subject alt name
-    field of a certificate. This name may be mapped to a principal
-    record in a security database based on local policy, for example
-    the subject alt name may be kerberos/principal@realm format.  In
-    this case the realm name is not that of the CA but that of the
-    local realm doing the mapping (or some realm name chosen by that
-    realm).
-
-    If a non-KDC X.509 certificate contains the principal name within
-    the subjectAltName version 3 extension , that name may utilize
-    KerberosName as defined below, or, in the case of an S/MIME
-    certificate [17], may utilize the email address.  If the KDC
-    is presented with an S/MIME certificate, then the email address
-    within subjectAltName will be interpreted as a principal and realm
-    separated by the "@" sign, or as a name that needs to be
-    canonicalized.  If the resulting name does not correspond to a
-    registered principal name, then the principal name is formed as
-    defined in section 3.1.
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.  If the KDC has no
-    certificate signed by any of the trustedCertifiers, then it returns
-    an error of type KDC_ERR_KDC_NOT_TRUSTED.
-
-    KDCs should try to (in order of preference):
-    1. Use the KDC certificate identified by the serialNumber included
-       in the client's request.
-    2. Use a certificate issued to the KDC by the client's CA (if in the
-       middle of a CA key roll-over, use the KDC cert issued under same
-       CA key as user cert used to verify request).
-    3. Use a certificate issued to the KDC by one of the client's
-       trustedCertifier(s);
-    If the KDC is unable to comply with any of these options, then the
-    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
-    client.
-
-    The KDC encrypts the reply not with the user's long-term key, but
-    with the Diffie Hellman derived key or a random key generated
-    for this particular response which is carried in the padata field of
-    the TGS-REP message.
-
-    PA-PK-AS-REP ::= CHOICE {
-                            -- PA TYPE 15
-        dhSignedData       [0] SignedData,
-                            -- Defined in CMS and used only with
-                            -- Diffie-Hellman key exchange (if the
-                            -- client public value was present in the
-                            -- request).
-                            -- This choice MUST be supported
-                            -- by compliant implementations.
-        encKeyPack         [1] EnvelopedData,
-                            -- Defined in CMS
-                            -- The temporary key is encrypted
-                            -- using the client public key
-                            -- key
-                            -- SignedReplyKeyPack, encrypted
-                            -- with the temporary key, is also
-                            -- included.
-    }
-
-    Usage of SignedData:
-
-        When the Diffie-Hellman option is used, dhSignedData in
-        PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
-        of the KDC.  The reply key used to encrypt part of the KDC reply
-        message is derived from the Diffie-Hellman exchange:
-
-        1.  Both the KDC and the client calculate a secret value
-            (g^ab mod p), where a is the client's private exponent and
-            b is the KDC's private exponent.
-
-        2.  Both the KDC and the client take the first N bits of this
-            secret value and convert it into a reply key.  N depends on
-            the reply key type.
-
-        3.  If the reply key is DES, N=64 bits, where some of the bits
-            are replaced with parity bits, according to FIPS PUB 74.
-
-        4.  If the reply key is (3-key) 3-DES, N=192 bits, where some
-            of the bits are replaced with parity bits, according to
-            FIPS PUB 74.
-
-        5.  The encapContentInfo field must contain the KdcDHKeyInfo as
-            defined below.
-
-            a.  The eContentType field shall contain the OID value for
-                pkdata: iso (1) org (3) dod (6) internet (1) security (5)
-                kerberosv5 (2) pkinit (3) pkdata (1)
-
-            b.  The eContent field is data of the type KdcDHKeyInfo
-                (below).
-
-        6.  The certificates field must contain the certificates
-            necessary for the client to establish trust in the KDC's
-            certificate based on the list of trusted certifiers sent by
-            the client in the PA-PK-AS-REQ.  This field may be empty if
-            the client did not send to the KDC a list of trusted
-            certifiers (the trustedCertifiers field was empty, meaning
-            that the client already possesses the KDC's certificate).
-
-        7.  The signerInfos field is a SET that must contain at least
-            one member, since it contains the actual signature.
-
-    KdcDHKeyInfo ::= SEQUENCE {
-                              -- used only when utilizing Diffie-Hellman
-      nonce                 [0] INTEGER,
-                                -- binds responce to the request
-      subjectPublicKey      [2] BIT STRING
-                                -- Equals public exponent (g^a mod p)
-                                -- INTEGER encoded as payload of
-                                -- BIT STRING
-    }
-
-    Usage of EnvelopedData:
-
-        The EnvelopedData data type is specified in the Cryptographic
-        Message Syntax, a product of the S/MIME working group of the
-        IETF.  It contains a temporary key encrypted with the PKINIT
-        client's public key.  It also contains a signed and encrypted
-        reply key.
-
-        1.  The originatorInfo field is not required, since that
-            information may be presented in the signedData structure
-            that is encrypted within the encryptedContentInfo field.
-
-        2.  The optional unprotectedAttrs field is not required for
-            PKINIT.
-
-        3.  The recipientInfos field is a SET which must contain exactly
-            one member of the KeyTransRecipientInfo type for encryption
-            with an RSA public key.
-
-            a.  The encryptedKey field (in KeyTransRecipientInfo)
-                contains the temporary key which is encrypted with the
-                PKINIT client's public key.
-
-        4.  The encryptedContentInfo field contains the signed and
-            encrypted reply key.
-
-            a.  The contentType field shall contain the OID value for
-                id-signedData: iso (1) member-body (2) us (840)
-                rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
-
-            b.  The encryptedContent field is encrypted data of the CMS
-                type signedData as specified below.
-
-                i.  The encapContentInfo field must contains the
-                    ReplyKeyPack.
-
-                    * The eContentType field shall contain the OID value
-                      for pkdata: iso (1) org (3) dod (6) internet (1)
-                      security (5) kerberosv5 (2) pkinit (3) pkdata (1)
-
-                    * The eContent field is data of the type ReplyKeyPack
-                      (below).
-
-                ii.  The certificates field must contain the certificates
-                     necessary for the client to establish trust in the
-                     KDC's certificate based on the list of trusted
-                     certifiers sent by the client in the PA-PK-AS-REQ.
-                     This field may be empty if the client did not send
-                     to the KDC a list of trusted certifiers (the
-                     trustedCertifiers field was empty, meaning that the
-                     client already possesses the KDC's certificate).
-
-                iii.  The signerInfos field is a SET that must contain at
-                      least one member, since it contains the actual
-                      signature.
-
-    ReplyKeyPack ::= SEQUENCE {
-                              -- not used for Diffie-Hellman
-        replyKey             [0] EncryptionKey,
-                                 -- used to encrypt main reply
-                                 -- ENCTYPE is at least as strong as
-                                 -- ENCTYPE of session key
-        nonce                [1] INTEGER,
-                                 -- binds response to the request
-                                 -- must be same as the nonce
-                                 -- passed in the PKAuthenticator
-    }
-
-    Since each certifier in the certification path of a user's
-    certificate is equivalent to a separate Kerberos realm, the name
-    of each certifier in the certificate chain must be added to the
-    transited field of the ticket.  The format of these realm names is
-    defined in Section 3.1 of this document.  If applicable, the
-    transit-policy-checked flag should be set in the issued ticket.
-
-    The KDC's certificate(s) must bind the public key(s) of the KDC to
-    a name derivable from the name of the realm for that KDC.  X.509
-    certificates shall contain the principal name of the KDC
-    (defined in section 8.2 of RFC 1510) as the SubjectAltName version
-    3 extension. Below is the definition of this version 3 extension,
-    as specified by the X.509 standard:
-
-        subjectAltName EXTENSION ::= {
-            SYNTAX GeneralNames
-            IDENTIFIED BY id-ce-subjectAltName
-        }
-
-        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
-
-        GeneralName ::= CHOICE {
-            otherName       [0] OtherName,
-            ...
-        }
-
-        OtherName ::= SEQUENCE {
-            type-id         OBJECT IDENTIFIER,
-            value           [0] EXPLICIT ANY DEFINED BY type-id
-        }
-
-    For the purpose of specifying a Kerberos principal name, the value
-    in OtherName shall be a KerberosName as defined in RFC 1510, but with
-    the PrincipalName replaced by CertPrincipalName as mentioned in
-    Section 3.1:
-
-        KerberosName ::= SEQUENCE {
-            realm           [0] Realm,
-            principalName   [1] CertPrincipalName  -- defined above
-        }
-
-    This specific syntax is identified within subjectAltName by setting
-    the type-id in OtherName to krb5PrincipalName, where (from the
-    Kerberos specification) we have
-
-        krb5 OBJECT IDENTIFIER ::= { iso (1)
-                                     org (3)
-                                     dod (6)
-                                     internet (1)
-                                     security (5)
-                                     kerberosv5 (2) }
-
-        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
-
-    (This specification may also be used to specify a Kerberos name
-    within the user's certificate.)  The KDC's certificate may be signed
-    directly by a CA, or there may be intermediaries if the server resides
-    within a large organization, or it may be unsigned if the client
-    indicates possession (and trust) of the KDC's certificate.
-
-    The client then extracts the random key used to encrypt the main
-    reply.  This random key (in encPaReply) is encrypted with either the
-    client's public key or with a key derived from the DH values
-    exchanged between the client and the KDC.  The client uses this
-    random key to decrypt the main reply, and subsequently proceeds as
-    described in RFC 1510.
-
-3.2.3. Required Algorithms
-
-    Not all of the algorithms in the PKINIT protocol specification have
-    to be implemented in order to comply with the proposed standard.
-    Below is a list of the required algorithms:
-
-    * Diffie-Hellman public/private key pairs
-        * utilizing Diffie-Hellman ephemeral-ephemeral mode
-    * SHA1 digest and DSA for signatures
-    * 3-key triple DES keys derived from the Diffie-Hellman Exchange
-    * 3-key triple DES Temporary and Reply keys
-
-4.  Logistics and Policy
-
-    This section describes a way to define the policy on the use of
-    PKINIT for each principal and request.
-
-    The KDC is not required to contain a database record for users
-    who use public key authentication.  However, if these users are
-    registered with the KDC, it is recommended that the database record
-    for these users be modified to an additional flag in the attributes
-    field to indicate that the user should authenticate using PKINIT.
-    If this flag is set and a request message does not contain the
-    PKINIT preauthentication field, then the KDC sends back as error of
-    type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
-    field of type PA-PK-AS-REQ must be included in the request.
-
-5.  Security Considerations
-
-    PKINIT raises a few security considerations, which we will address
-    in this section.
-
-    First of all, PKINIT introduces a new trust model, where KDCs do not
-    (necessarily) certify the identity of those for whom they issue
-    tickets.  PKINIT does allow KDCs to act as their own CAs, in the
-    limited capacity of self-signing their certificates, but one of the
-    additional benefits is to align Kerberos authentication with a global
-    public key infrastructure.  Anyone using PKINIT in this way must be
-    aware of how the certification infrastructure they are linking to
-    works.
-
-    Secondly, PKINIT also introduces the possibility of interactions
-    between different cryptosystems, which may be of widely varying
-    strengths.  Many systems, for instance, allow the use of 512-bit
-    public keys.  Using such keys to wrap data encrypted under strong
-    conventional cryptosystems, such as triple-DES, is inappropriate;
-    it adds a weak link to a strong one at extra cost.  Implementors
-    and administrators should take care to avoid such wasteful and
-    deceptive interactions.
-
-    Lastly, PKINIT calls for randomly generated keys for conventional
-    cryptosystems.  Many such systems contain systematically "weak"
-    keys.  PKINIT implementations MUST avoid use of these keys, either
-    by discarding those keys when they are generated, or by fixing them
-    in some way (e.g., by XORing them with a given mask).  These
-    precautions vary from system to system; it is not our intention to
-    give an explicit recipe for them here.
-
-6.  Transport Issues
-
-    Certificate chains can potentially grow quite large and span several
-    UDP packets; this in turn increases the probability that a Kerberos
-    message involving PKINIT extensions will be broken in transit.  In
-    light of the possibility that the Kerberos specification will
-    require KDCs to accept requests using TCP as a transport mechanism,
-    we make the same recommendation with respect to the PKINIT
-    extensions as well.
-
-7.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-    (V5).  Request for Comments 1510.
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.  September
-    1994.
-
-    [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
-    A. Medvinsky, M. Hur.  Public Key Cryptography for Cross-Realm
-    Authentication in Kerberos.  draft-ietf-cat-kerberos-pk-cross-04.txt
-
-    [4] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
-    Kerberos.  draft-ietf-cat-kerberos-anoncred-00.txt
-
-    [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman.
-    Public Key Utilizing Tickets for Application Servers (PKTAPP).
-    draft-ietf-cat-pktapp-02.txt
-
-    [6] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-    Using Public Key Cryptography.  Symposium On Network and Distributed
-    System Security, 1997.
-
-    [7] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic
-    Commerce, July 1995.
-
-    [8] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
-    Request for Comments 2246, January 1999.
-
-    [9] B.C. Neuman, Proxy-Based Authorization and Accounting for
-    Distributed Systems.  In Proceedings of the 13th International
-    Conference on Distributed Computing Systems, May 1993.
-
-    [10] ITU-T (formerly CCITT) Information technology - Open Systems
-    Interconnection - The Directory: Authentication Framework
-    Recommendation X.509 ISO/IEC 9594-8
-
-    [11] R. Housley. Cryptographic Message Syntax.
-    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
-    as RFC.
-
-    [12] PKCS #7: Cryptographic Message Syntax Standard,
-    An RSA Laboratories Technical Note Version 1.5
-    Revised November 1, 1993
-
-    [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
-    Security, Inc. A Description of the RC2(r) Encryption Algorithm
-    March 1998.
-    Request for Comments 2268.
-
-    [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
-    Protocol (v3): UTF-8 String Representation of Distinguished Names.
-    Request for Comments 2253.
-
-    [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
-    Key Infrastructure, Certificate and CRL Profile, January 1999.
-    Request for Comments 2459.
-
-    [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-    Specifications, October 1998.  Request for Comments 2437.
-
-    [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
-    Version 2 Certificate Handling, March 1998.  Request for
-    Comments 2312.
-
-    [18] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
-    Protocol (v3), December 1997.  Request for Comments 2251.
-
-    [19] ITU-T (formerly CCITT) Information Processing Systems - Open
-    Systems Interconnection - Specification of Abstract Syntax Notation
-    One (ASN.1) Rec. X.680 ISO/IEC 8824-1
-
-8.  Acknowledgements
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-9.  Expiration Date
-
-    This draft expires September 15, 2000.
-
-10. Authors
-
-    Brian Tung
-    Clifford Neuman
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {brian, bcn}@isi.edu
-
-    Matthew Hur
-    CyberSafe Corporation
-    1605 NW Sammamish Road
-    Issaquah WA 98027-5378
-    Phone: +1 425 391 6000
-    E-mail: matt.hur@cybersafe.com
-
-    Ari Medvinsky
-    Keen.com, Inc.
-    150 Independence Drive
-    Menlo Park CA 94025
-    Phone: +1 650 289 3134
-    E-mail: ari@keen.com
-
-    Sasha Medvinsky
-    Motorola
-    6450 Sequence Drive
-    San Diego, CA 92121
-    Phone +1 619 404 2825
-    E-mail: smedvinsky@gi.com
-
-    John Wray
-    Iris Associates, Inc.
-    5 Technology Park Dr.
-    Westford, MA 01886
-    E-mail: John_Wray@iris.com
-
-    Jonathan Trostle
-    170 W. Tasman Dr.
-    San Jose, CA 95134
-    E-mail: jtrostle@cisco.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt
deleted file mode 100644
index b1e596836..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-12.txt
+++ /dev/null
@@ -1,1080 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-12.txt                   Clifford Neuman
-Updates: RFC 1510                                                USC/ISI
-expires January 15, 2001                                     Matthew Hur
-                                                   CyberSafe Corporation
-                                                           Ari Medvinsky
-                                                          Keen.com, Inc.
-                                                         Sasha Medvinsky
-                                                                Motorola
-                                                               John Wray
-                                                   Iris Associates, Inc.
-                                                        Jonathan Trostle
-                                                                   Cisco
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-0.  Status Of This Memo
-
-    This document is an Internet-Draft and is in full conformance with
-    all provisions of Section 10 of RFC 2026.  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."
-
-    The list of current Internet-Drafts can be accessed at
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-    The list of Internet-Draft Shadow Directories can be accessed at
-    http://www.ietf.org/shadow.html.
-
-    To learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ftp.ietf.org (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-11.txt, and expires January 15,
-    2001.  Please send comments to the authors.
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510 [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to associate a key pair with each realm, which can
-    then be used to facilitate cross-realm authentication; this is the
-    topic of another draft proposal.  Another way is to allow users with
-    public key certificates to use them in initial authentication.  This
-    is the concern of the current document.
-
-    PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
-    combination with digital signature keys as the primary, required
-    mechanism.  It also allows for the use of RSA keys and/or (static)
-    Diffie-Hellman certificates.  Note in particular that PKINIT supports
-    the use of separate signature and encryption keys.
-
-    PKINIT enables access to Kerberos-secured services based on initial
-    authentication utilizing public key cryptography.  PKINIT utilizes
-    standard public key signature and encryption data formats within the
-    standard Kerberos messages.  The basic mechanism is as follows:  The
-    user sends an AS-REQ message to the KDC as before, except that if that
-    user is to use public key cryptography in the initial authentication
-    step, his certificate and a signature accompany the initial request
-    in the preauthentication fields.  Upon receipt of this request, the
-    KDC verifies the certificate and issues a ticket granting ticket
-    (TGT) as before, except that the encPart from the AS-REP message
-    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
-    derived key or the user's public key.  This message is authenticated
-    utilizing the public key signature of the KDC.
-
-    Note that PKINIT does not require the use of certificates.  A KDC
-    may store the public key of a principal as part of that principal's
-    record.  In this scenario, the KDC is the trusted party that vouches
-    for the principal (as in a standard, non-cross realm, Kerberos
-    environment).  Thus, for any principal, the KDC may maintain a
-    secret key, a public key, or both.
-
-    The PKINIT specification may also be used as a building block for
-    other specifications.  PKCROSS [3] utilizes PKINIT for establishing
-    the inter-realm key and associated inter-realm policy to be applied
-    in issuing cross realm service tickets.  As specified in [4],
-    anonymous Kerberos tickets can be issued by applying a NULL
-    signature in combination with Diffie-Hellman in the PKINIT exchange.
-    Additionally, the PKINIT specification may be used for direct peer
-    to peer authentication without contacting a central KDC. This
-    application of PKINIT is described in PKTAPP [5] and is based on
-    concepts introduced in [6, 7]. For direct client-to-server
-    authentication, the client uses PKINIT to authenticate to the end
-    server (instead of a central KDC), which then issues a ticket for
-    itself.  This approach has an advantage over TLS [8] in that the
-    server does not need to save state (cache session keys).
-    Furthermore, an additional benefit is that Kerberos tickets can
-    facilitate delegation (see [9]).
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510 for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following change to RFC 1510 is proposed:
-
-        * Users may authenticate using either a public key pair or a
-          conventional (symmetric) key.  If public key cryptography is
-          used, public key data is transported in preauthentication
-          data fields to help establish identity.  The user presents
-          a public key certificate and obtains an ordinary TGT that may
-          be used for subsequent authentication, with such
-          authentication using only conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 describes the extensions for the initial authentication
-    method.
-
-3.1.  Definitions
-
-    The extensions involve new preauthentication fields; we introduce
-    the following preauthentication types:
-
-        PA-PK-AS-REQ                            14
-        PA-PK-AS-REP                            15
-
-    The extensions also involve new error types; we introduce the
-    following types:
-
-        KDC_ERR_CLIENT_NOT_TRUSTED              62
-        KDC_ERR_KDC_NOT_TRUSTED                 63
-        KDC_ERR_INVALID_SIG                     64
-        KDC_ERR_KEY_TOO_WEAK                    65
-        KDC_ERR_CERTIFICATE_MISMATCH            66
-        KDC_ERR_CANT_VERIFY_CERTIFICATE         70
-        KDC_ERR_INVALID_CERTIFICATE             71
-        KDC_ERR_REVOKED_CERTIFICATE             72
-        KDC_ERR_REVOCATION_STATUS_UNKNOWN       73
-        KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74
-        KDC_ERR_CLIENT_NAME_MISMATCH            75
-        KDC_ERR_KDC_NAME_MISMATCH               76
-
-    We utilize the following typed data for errors:
-
-        TD-PKINIT-CMS-CERTIFICATES             101
-        TD-KRB-PRINCIPAL                       102
-        TD-KRB-REALM                           103
-        TD-TRUSTED-CERTIFIERS                  104
-        TD-CERTIFICATE-INDEX                   105
-
-    We utilize the following encryption types (which map directly to
-    OIDs):
-
-        dsaWithSHA1-CmsOID                       9
-        md5WithRSAEncryption-CmsOID             10
-        sha1WithRSAEncryption-CmsOID            11
-        rc2CBC-EnvOID                           12
-        rsaEncryption-EnvOID (PKCS#1 v1.5)      13
-        rsaES-OAEP-ENV-OID   (PKCS#1 v2.0)      14
-        des-ede3-cbc-Env-OID                    15
-
-    These mappings are provided so that a client may send the
-    appropriate enctypes in the AS-REQ message in order to indicate
-    support for the corresponding OIDs (for performing PKINIT).
-
-    In many cases, PKINIT requires the encoding of the X.500 name of a
-    certificate authority as a Realm.  When such a name appears as
-    a realm it will be represented using the "other" form of the realm
-    name as specified in the naming constraints section of RFC1510.
-    For a realm derived from an X.500 name, NAMETYPE will have the value
-    X500-RFC2253.  The full realm name will appear as follows:
-
-        <nametype> + ":" + <string>
-
-    where nametype is "X500-RFC2253" and string is the result of doing
-    an RFC2253 encoding of the distinguished name, i.e.
-
-        "X500-RFC2253:" + RFC2253Encode(DistinguishedName)
-
-    where DistinguishedName is an X.500 name, and RFC2253Encode is a
-    function returing a readable UTF encoding of an X.500 name, as
-    defined by RFC 2253 [14] (part of LDAPv3 [18]).
-
-    To ensure that this encoding is unique, we add the following rule
-    to those specified by RFC 2253:
-
-        The order in which the attributes appear in the RFC 2253
-        encoding must be the reverse of the order in the ASN.1
-        encoding of the X.500 name that appears in the public key
-        certificate. The order of the relative distinguished names
-        (RDNs), as well as the order of the AttributeTypeAndValues
-        within each RDN, will be reversed. (This is despite the fact
-        that an RDN is defined as a SET of AttributeTypeAndValues, where
-        an order is normally not important.)
-
-    Similarly, in cases where the KDC does not provide a specific
-    policy based mapping from the X.500 name or X.509 Version 3
-    SubjectAltName extension in the user's certificate to a Kerberos
-    principal name, PKINIT requires the direct encoding of the X.500
-    name as a PrincipalName.  In this case, the name-type of the
-    principal name shall be set to KRB_NT-X500-PRINCIPAL.  This new
-    name type is defined in RFC 1510 as:
-
-        KRB_NT_X500_PRINCIPAL    6
-
-    The name-string shall be set as follows:
-
-        RFC2253Encode(DistinguishedName)
-
-    as described above.  When this name type is used, the principal's
-    realm shall be set to the certificate authority's distinguished
-    name using the X500-RFC2253 realm name format described earlier in
-    this section
-
-    RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
-
-        PrincipalName ::=   SEQUENCE {
-                        name-type[0]     INTEGER,
-                        name-string[1]   SEQUENCE OF GeneralString
-        }
-
-    For the purposes of encoding an X.500 name as a Kerberos name for
-    use in Kerberos structures, the name-string shall be encoded as a
-    single GeneralString.  The name-type should be KRB_NT_X500_PRINCIPAL,
-    as noted above.  All Kerberos names must conform to validity
-    requirements as given in RFC 1510.  Note that name mapping may be
-    required or optional, based on policy.
-
-    We also define the following similar ASN.1 structure:
-
-        CertPrincipalName ::= SEQUENCE {
-                        name-type[0]     INTEGER,
-                        name-string[1]   SEQUENCE OF UTF8String
-        }
-
-    When a Kerberos PrincipalName is to be placed within an X.509 data
-    structure, the CertPrincipalName structure is to be used, with the
-    name-string encoded as a single UTF8String.  The name-type should be
-    as identified in the original PrincipalName structure.  The mapping
-    between the GeneralString and UTF8String formats can be found in
-    [19].
-
-    The following rules relate to the the matching of PrincipalNames (or
-    corresponding CertPrincipalNames) with regard to the PKI name
-    constraints for CAs as laid out in RFC 2459 [15].  In order to be
-    regarded as a match (for permitted and excluded name trees), the
-    following must be satisfied.
-
-        1.  If the constraint is given as a user plus realm name, or
-            as a user plus instance plus realm name (as specified in
-            RFC 1510), the realm name must be valid (see 2.a-d below)
-            and the match must be exact, byte for byte.
-
-        2.  If the constraint is given only as a realm name, matching
-            depends on the type of the realm:
-
-            a.  If the realm contains a colon (':') before any equal
-                sign ('='), it is treated as a realm of type Other,
-                and must match exactly, byte for byte.
-
-            b.  Otherwise, if the realm contains an equal sign, it
-                is treated as an X.500 name.  In order to match, every
-                component in the constraint MUST be in the principal
-                name, and have the same value.  For example, 'C=US'
-                matches 'C=US/O=ISI' but not 'C=UK'.
-
-            c.  Otherwise, if the realm name conforms to rules regarding
-                the format of DNS names, it is considered a realm name of
-                type Domain.  The constraint may be given as a realm
-                name 'FOO.BAR', which matches any PrincipalName within
-                the realm 'FOO.BAR' but not those in subrealms such as
-                'CAR.FOO.BAR'.  A constraint of the form '.FOO.BAR'
-                matches PrincipalNames in subrealms of the form
-                'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
-
-            d.  Otherwise, the realm name is invalid and does not match
-                under any conditions.
-
-3.1.1.  Encryption and Key Formats
-
-    In the exposition below, we use the terms public key and private
-    key generically.  It should be understood that the term "public
-    key" may be used to refer to either a public encryption key or a
-    signature verification key, and that the term "private key" may be
-    used to refer to either a private decryption key or a signature
-    generation key.  The fact that these are logically distinct does
-    not preclude the assignment of bitwise identical keys for RSA
-    keys.
-
-    In the case of Diffie-Hellman, the key shall be produced from the
-    agreed bit string as follows:
-
-        * Truncate the bit string to the appropriate length.
-        * Rectify parity in each byte (if necessary) to obtain the key.
-
-    For instance, in the case of a DES key, we take the first eight
-    bytes of the bit stream, and then adjust the least significant bit
-    of each byte to ensure that each byte has odd parity.
-
-3.1.2. Algorithm Identifiers
-
-    PKINIT does not define, but does permit, the algorithm identifiers
-    listed below.
-
-3.1.2.1. Signature Algorithm Identifiers
-
-    The following signature algorithm identifiers specified in [11] and
-    in [15] shall be used with PKINIT:
-
-    id-dsa-with-sha1       (DSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    sha-1WithRSAEncryption (RSA with SHA1)
-
-3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
-
-    The following algorithm identifier shall be used within the
-    SubjectPublicKeyInfo data structure: dhpublicnumber
-
-    This identifier and the associated algorithm parameters are
-    specified in RFC 2459 [15].
-
-3.1.2.3. Algorithm Identifiers for RSA Encryption
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure, for encrypting the temporary key with a public key:
-
-        rsaEncryption (RSA encryption, PKCS#1 v1.5)
-        id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
-
-    Both of the above RSA encryption schemes are specified in [16].
-    Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
-    CMS specification says that it will likely include PKCS#1 v2.0 in
-    the future.  (PKCS#1 v2.0 addresses adaptive chosen ciphertext
-    vulnerability discovered in PKCS#1 v1.5.)
-
-3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure in the PKINIT Reply, for encrypting the reply key with the
-    temporary key:
-        des-ede3-cbc (3-key 3-DES, CBC mode)
-        rc2-cbc      (RC2, CBC mode)
-
-    The full definition of the above algorithm identifiers and their
-    corresponding parameters (an IV for block chaining) is provided in
-    the CMS specification [11].
-
-3.2.  Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with PKINIT.
-
-3.2.1.  Client Request
-
-    Public keys may be signed by some certification authority (CA), or
-    they may be maintained by the KDC in which case the KDC is the
-    trusted authority.  Note that the latter mode does not require the
-    use of certificates.
-
-    The initial authentication request is sent as per RFC 1510, except
-    that a preauthentication field containing data signed by the user's
-    private key accompanies the request:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                -- PA TYPE 14
-        signedAuthPack          [0] SignedData
-                                    -- Defined in CMS [11];
-                                    -- AuthPack (below) defines the
-                                    -- data that is signed.
-        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
-                                    -- This is a list of CAs that the
-                                    -- client trusts and that certify
-                                    -- KDCs.
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
-                                    -- As defined in CMS [11];
-                                    -- specifies a particular KDC
-                                    -- certificate if the client
-                                    -- already has it.
-        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
-                                    -- For example, this may be the
-                                    -- client's Diffie-Hellman
-                                    -- certificate, or it may be the
-                                    -- client's RSA encryption
-                                    -- certificate.
-    }
-
-    TrustedCas ::= CHOICE {
-        principalName         [0] KerberosName,
-                                  -- as defined below
-        caName                [1] Name
-                                  -- fully qualified X.500 name
-                                  -- as defined by X.509
-        issuerAndSerial       [2] IssuerAndSerialNumber
-                                  -- Since a CA may have a number of
-                                  -- certificates, only one of which
-                                  -- a client trusts
-    }
-
-    Usage of SignedData:
-
-        The SignedData data type is specified in the Cryptographic
-        Message Syntax, a product of the S/MIME working group of the
-        IETF.  The following describes how to fill in the fields of
-        this data:
-
-        1.  The encapContentInfo field must contain the PKAuthenticator
-            and, optionally, the client's Diffie Hellman public value.
-
-            a.  The eContentType field shall contain the OID value for
-                pkauthdata: iso (1) org (3) dod (6) internet (1)
-                security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)
-
-            b.  The eContent field is data of the type AuthPack (below).
-
-        2.  The signerInfos field contains the signature of AuthPack.
-
-        3.  The Certificates field, when non-empty, contains the client's
-            certificate chain.  If present, the KDC uses the public key
-            from the client's certificate to verify the signature in the
-            request.  Note that the client may pass different certificate
-            chains that are used for signing or for encrypting.  Thus,
-            the KDC may utilize a different client certificate for
-            signature verification than the one it uses to encrypt the
-            reply to the client.  For example, the client may place a
-            Diffie-Hellman certificate in this field in order to convey
-            its static Diffie Hellman certificate to the KDC to enable
-            static-ephemeral Diffie-Hellman mode for the reply; in this
-            case, the client does NOT place its public value in the
-            AuthPack (defined below).  As another example, the client may
-            place an RSA encryption certificate in this field.  However,
-            there must always be (at least) a signature certificate.
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- if client is using Diffie-Hellman
-                                    -- (ephemeral-ephemeral only)
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER,
-                                    -- for replay prevention as in RFC1510
-        ctime                   [1] KerberosTime,
-                                    -- for replay prevention as in RFC1510
-        nonce                   [2] INTEGER,
-        pachecksum              [3] Checksum
-                                    -- Checksum over KDC-REQ-BODY
-                                    -- Defined by Kerberos spec
-    }
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm                   AlgorithmIdentifier,
-                                    -- dhKeyAgreement
-        subjectPublicKey            BIT STRING
-                                    -- for DH, equals
-                                    -- public exponent (INTEGER encoded
-                                    -- as payload of BIT STRING)
-    }   -- as specified by the X.509 recommendation [10]
-
-    AlgorithmIdentifier ::= SEQUENCE {
-        algorithm                   OBJECT IDENTIFIER,
-                                    -- for dhKeyAgreement, this is
-                                    -- { iso (1) member-body (2) US (840)
-                                    -- rsadsi (113459) pkcs (1) 3 1 }
-                                    -- from PKCS #3 [20]
-        parameters                  ANY DEFINED by algorithm OPTIONAL
-                                    -- for dhKeyAgreement, this is
-                                    -- DHParameter
-    }   -- as specified by the X.509 recommendation [10]
-
-    DHParameter ::= SEQUENCE {
-        prime                       INTEGER,
-                                    -- p
-        base                        INTEGER,
-                                    -- g
-        privateValueLength          INTEGER OPTIONAL
-                                    -- l
-    }   -- as defined in PKCS #3 [20]
-
-    If the client passes an issuer and serial number in the request,
-    the KDC is requested to use the referred-to certificate.  If none
-    exists, then the KDC returns an error of type
-    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
-    other hand, the client does not pass any trustedCertifiers,
-    believing that it has the KDC's certificate, but the KDC has more
-    than one certificate.  The KDC should include information in the
-    KRB-ERROR message that indicates the KDC certificate(s) that a
-    client may utilize.  This data is specified in the e-data, which
-    is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
-
-    TypedData ::=  SEQUENCE {
-                    data-type      [0] INTEGER,
-                    data-value     [1] OCTET STRING,
-    } -- per Kerberos RFC 1510 revisions
-
-    where:
-    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
-    data-value = CertificateSet // as specified by CMS [11]
-
-    The PKAuthenticator carries information to foil replay attacks, to
-    bind the pre-authentication data to the KDC-REQ-BODY, and to bind the
-    request and response.  The PKAuthenticator is signed with the client's
-    signature key.
-
-3.2.2.  KDC Response
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.  This may be based on a certification
-    hierarchy, or it may be simply a list of recognized certifiers in a
-    system like PGP.
-
-    If the client's certificate chain contains no certificate signed by
-    a CA trusted by the KDC, then the KDC sends back an error message
-    of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data
-    is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
-    whose data-value is an OCTET STRING which is the DER encoding of
-
-        TrustedCertifiers ::= SEQUENCE OF PrincipalName
-                              -- X.500 name encoded as a principal name
-                              -- see Section 3.1
-
-    If while verifying a certificate chain the KDC determines that the
-    signature on one of the certificates in the CertificateSet from
-    the signedAuthPack fails verification, then the KDC returns an
-    error of type KDC_ERR_INVALID_CERTIFICATE.  The accompanying
-    e-data is a SEQUENCE of one TypedData (with type
-    TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
-    which is the DER encoding of the index into the CertificateSet
-    ordered as sent by the client.
-
-        CertificateIndex  ::= INTEGER
-                              -- 0 = 1st certificate,
-                              --     (in order of encoding)
-                              -- 1 = 2nd certificate, etc
-
-    The KDC may also check whether any of the certificates in the
-    client's chain has been revoked.  If one of the certificates has
-    been revoked, then the KDC returns an error of type
-    KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
-    the certificate's revocation status is unknown or not
-    available, then if required by policy, the KDC returns the
-    appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
-    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE.  In any of these three
-    cases, the affected certificate is identified by the accompanying
-    e-data, which contains a CertificateIndex as described for
-    KDC_ERR_INVALID_CERTIFICATE.
-
-    If the certificate chain can be verified, but the name of the
-    client in the certificate does not match the client's name in the
-    request, then the KDC returns an error of type
-    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
-    field in this case.
-
-    Finally, if the certificate chain is verified, but the KDC's name
-    or realm as given in the PKAuthenticator does not match the KDC's
-    actual principal name, then the KDC returns an error of type
-    KDC_ERR_KDC_NAME_MISMATCH.  The accompanying e-data field is again
-    a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
-    TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
-    STRING whose data-value is the DER encoding of a PrincipalName or
-    Realm as defined in RFC 1510 revisions.
-
-    Even if all succeeds, the KDC may--for policy reasons--decide not
-    to trust the client.  In this case, the KDC returns an error message
-    of type KDC_ERR_CLIENT_NOT_TRUSTED.  One specific case of this is
-    the presence or absence of an Enhanced Key Usage (EKU) OID within
-    the certificate extensions.  The rules regarding acceptability of
-    an EKU sequence (or the absence of any sequence) are a matter of
-    local policy.  For the benefit of implementers, we define a PKINIT
-    EKU OID as the following: iso (1) org (3) dod (6) internet (1)
-    security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on AuthPack.  If that fails, the KDC returns an error
-    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
-    timestamp (ctime and cusec) in the PKAuthenticator to assure that
-    the request is not a replay.  The KDC also verifies that its name
-    is specified in the PKAuthenticator.
-
-    If the clientPublicValue field is filled in, indicating that the
-    client wishes to use Diffie-Hellman key agreement, then the KDC
-    checks to see that the parameters satisfy its policy.  If they do
-    not (e.g., the prime size is insufficient for the expected
-    encryption type), then the KDC sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
-    private values for the response.
-
-    The KDC also checks that the timestamp in the PKAuthenticator is
-    within the allowable window and that the principal name and realm
-    are correct.  If the local (server) time and the client time in the
-    authenticator differ by more than the allowable clock skew, then the
-    KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510.
-
-    Assuming no errors, the KDC replies as per RFC 1510, except as
-    follows.  The user's name in the ticket is determined by the
-    following decision algorithm:
-
-        1.  If the KDC has a mapping from the name in the certificate
-            to a Kerberos name, then use that name.
-            Else
-        2.  If the certificate contains the SubjectAltName extention
-            and the local KDC policy defines a mapping from the
-            SubjectAltName to a Kerberos name, then use that name.
-            Else
-        3.  Use the name as represented in the certificate, mapping
-            mapping as necessary (e.g., as per RFC 2253 for X.500
-            names).  In this case the realm in the ticket shall be the
-            name of the certifier that issued the user's certificate.
-
-    Note that a principal name may be carried in the subject alt name
-    field of a certificate. This name may be mapped to a principal
-    record in a security database based on local policy, for example
-    the subject alt name may be kerberos/principal@realm format.  In
-    this case the realm name is not that of the CA but that of the
-    local realm doing the mapping (or some realm name chosen by that
-    realm).
-
-    If a non-KDC X.509 certificate contains the principal name within
-    the subjectAltName version 3 extension , that name may utilize
-    KerberosName as defined below, or, in the case of an S/MIME
-    certificate [17], may utilize the email address.  If the KDC
-    is presented with an S/MIME certificate, then the email address
-    within subjectAltName will be interpreted as a principal and realm
-    separated by the "@" sign, or as a name that needs to be
-    canonicalized.  If the resulting name does not correspond to a
-    registered principal name, then the principal name is formed as
-    defined in section 3.1.
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.  If the KDC has no
-    certificate signed by any of the trustedCertifiers, then it returns
-    an error of type KDC_ERR_KDC_NOT_TRUSTED.
-
-    KDCs should try to (in order of preference):
-    1. Use the KDC certificate identified by the serialNumber included
-       in the client's request.
-    2. Use a certificate issued to the KDC by the client's CA (if in the
-       middle of a CA key roll-over, use the KDC cert issued under same
-       CA key as user cert used to verify request).
-    3. Use a certificate issued to the KDC by one of the client's
-       trustedCertifier(s);
-    If the KDC is unable to comply with any of these options, then the
-    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
-    client.
-
-    The KDC encrypts the reply not with the user's long-term key, but
-    with the Diffie Hellman derived key or a random key generated
-    for this particular response which is carried in the padata field of
-    the TGS-REP message.
-
-    PA-PK-AS-REP ::= CHOICE {
-                            -- PA TYPE 15
-        dhSignedData       [0] SignedData,
-                            -- Defined in CMS and used only with
-                            -- Diffie-Hellman key exchange (if the
-                            -- client public value was present in the
-                            -- request).
-                            -- This choice MUST be supported
-                            -- by compliant implementations.
-        encKeyPack         [1] EnvelopedData,
-                            -- Defined in CMS
-                            -- The temporary key is encrypted
-                            -- using the client public key
-                            -- key
-                            -- SignedReplyKeyPack, encrypted
-                            -- with the temporary key, is also
-                            -- included.
-    }
-
-    Usage of SignedData:
-
-        When the Diffie-Hellman option is used, dhSignedData in
-        PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
-        of the KDC.  The reply key used to encrypt part of the KDC reply
-        message is derived from the Diffie-Hellman exchange:
-
-        1.  Both the KDC and the client calculate a secret value
-            (g^ab mod p), where a is the client's private exponent and
-            b is the KDC's private exponent.
-
-        2.  Both the KDC and the client take the first N bits of this
-            secret value and convert it into a reply key.  N depends on
-            the reply key type.
-
-        3.  If the reply key is DES, N=64 bits, where some of the bits
-            are replaced with parity bits, according to FIPS PUB 74.
-
-        4.  If the reply key is (3-key) 3-DES, N=192 bits, where some
-            of the bits are replaced with parity bits, according to
-            FIPS PUB 74.
-
-        5.  The encapContentInfo field must contain the KdcDHKeyInfo as
-            defined below.
-
-            a.  The eContentType field shall contain the OID value for
-                pkdhkeydata: iso (1) org (3) dod (6) internet (1)
-                security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)
-
-            b.  The eContent field is data of the type KdcDHKeyInfo
-                (below).
-
-        6.  The certificates field must contain the certificates
-            necessary for the client to establish trust in the KDC's
-            certificate based on the list of trusted certifiers sent by
-            the client in the PA-PK-AS-REQ.  This field may be empty if
-            the client did not send to the KDC a list of trusted
-            certifiers (the trustedCertifiers field was empty, meaning
-            that the client already possesses the KDC's certificate).
-
-        7.  The signerInfos field is a SET that must contain at least
-            one member, since it contains the actual signature.
-
-    KdcDHKeyInfo ::= SEQUENCE {
-                              -- used only when utilizing Diffie-Hellman
-      nonce                 [0] INTEGER,
-                                -- binds responce to the request
-      subjectPublicKey      [2] BIT STRING
-                                -- Equals public exponent (g^a mod p)
-                                -- INTEGER encoded as payload of
-                                -- BIT STRING
-    }
-
-    Usage of EnvelopedData:
-
-        The EnvelopedData data type is specified in the Cryptographic
-        Message Syntax, a product of the S/MIME working group of the
-        IETF.  It contains a temporary key encrypted with the PKINIT
-        client's public key.  It also contains a signed and encrypted
-        reply key.
-
-        1.  The originatorInfo field is not required, since that
-            information may be presented in the signedData structure
-            that is encrypted within the encryptedContentInfo field.
-
-        2.  The optional unprotectedAttrs field is not required for
-            PKINIT.
-
-        3.  The recipientInfos field is a SET which must contain exactly
-            one member of the KeyTransRecipientInfo type for encryption
-            with an RSA public key.
-
-            a.  The encryptedKey field (in KeyTransRecipientInfo)
-                contains the temporary key which is encrypted with the
-                PKINIT client's public key.
-
-        4.  The encryptedContentInfo field contains the signed and
-            encrypted reply key.
-
-            a.  The contentType field shall contain the OID value for
-                id-signedData: iso (1) member-body (2) us (840)
-                rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
-
-            b.  The encryptedContent field is encrypted data of the CMS
-                type signedData as specified below.
-
-                i.  The encapContentInfo field must contains the
-                    ReplyKeyPack.
-
-                    * The eContentType field shall contain the OID value
-                      for pkrkeydata: iso (1) org (3) dod (6) internet (1)
-                      security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3)
-
-                    * The eContent field is data of the type ReplyKeyPack
-                      (below).
-
-                ii.  The certificates field must contain the certificates
-                     necessary for the client to establish trust in the
-                     KDC's certificate based on the list of trusted
-                     certifiers sent by the client in the PA-PK-AS-REQ.
-                     This field may be empty if the client did not send
-                     to the KDC a list of trusted certifiers (the
-                     trustedCertifiers field was empty, meaning that the
-                     client already possesses the KDC's certificate).
-
-                iii.  The signerInfos field is a SET that must contain at
-                      least one member, since it contains the actual
-                      signature.
-
-    ReplyKeyPack ::= SEQUENCE {
-                              -- not used for Diffie-Hellman
-        replyKey             [0] EncryptionKey,
-                                 -- used to encrypt main reply
-                                 -- ENCTYPE is at least as strong as
-                                 -- ENCTYPE of session key
-        nonce                [1] INTEGER,
-                                 -- binds response to the request
-                                 -- must be same as the nonce
-                                 -- passed in the PKAuthenticator
-    }
-
-    Since each certifier in the certification path of a user's
-    certificate is equivalent to a separate Kerberos realm, the name
-    of each certifier in the certificate chain must be added to the
-    transited field of the ticket.  The format of these realm names is
-    defined in Section 3.1 of this document.  If applicable, the
-    transit-policy-checked flag should be set in the issued ticket.
-
-    The KDC's certificate(s) must bind the public key(s) of the KDC to
-    a name derivable from the name of the realm for that KDC.  X.509
-    certificates shall contain the principal name of the KDC
-    (defined in section 8.2 of RFC 1510) as the SubjectAltName version
-    3 extension. Below is the definition of this version 3 extension,
-    as specified by the X.509 standard:
-
-        subjectAltName EXTENSION ::= {
-            SYNTAX GeneralNames
-            IDENTIFIED BY id-ce-subjectAltName
-        }
-
-        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
-
-        GeneralName ::= CHOICE {
-            otherName       [0] OtherName,
-            ...
-        }
-
-        OtherName ::= SEQUENCE {
-            type-id         OBJECT IDENTIFIER,
-            value           [0] EXPLICIT ANY DEFINED BY type-id
-        }
-
-    For the purpose of specifying a Kerberos principal name, the value
-    in OtherName shall be a KerberosName as defined in RFC 1510, but with
-    the PrincipalName replaced by CertPrincipalName as mentioned in
-    Section 3.1:
-
-        KerberosName ::= SEQUENCE {
-            realm           [0] Realm,
-            principalName   [1] CertPrincipalName  -- defined above
-        }
-
-    This specific syntax is identified within subjectAltName by setting
-    the type-id in OtherName to krb5PrincipalName, where (from the
-    Kerberos specification) we have
-
-        krb5 OBJECT IDENTIFIER ::= { iso (1)
-                                     org (3)
-                                     dod (6)
-                                     internet (1)
-                                     security (5)
-                                     kerberosv5 (2) }
-
-        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
-
-    (This specification may also be used to specify a Kerberos name
-    within the user's certificate.)  The KDC's certificate may be signed
-    directly by a CA, or there may be intermediaries if the server resides
-    within a large organization, or it may be unsigned if the client
-    indicates possession (and trust) of the KDC's certificate.
-
-    The client then extracts the random key used to encrypt the main
-    reply.  This random key (in encPaReply) is encrypted with either the
-    client's public key or with a key derived from the DH values
-    exchanged between the client and the KDC.  The client uses this
-    random key to decrypt the main reply, and subsequently proceeds as
-    described in RFC 1510.
-
-3.2.3. Required Algorithms
-
-    Not all of the algorithms in the PKINIT protocol specification have
-    to be implemented in order to comply with the proposed standard.
-    Below is a list of the required algorithms:
-
-    * Diffie-Hellman public/private key pairs
-        * utilizing Diffie-Hellman ephemeral-ephemeral mode
-    * SHA1 digest and DSA for signatures
-    * SHA1 digest also for the Checksum in the PKAuthenticator
-    * 3-key triple DES keys derived from the Diffie-Hellman Exchange
-    * 3-key triple DES Temporary and Reply keys
-
-4.  Logistics and Policy
-
-    This section describes a way to define the policy on the use of
-    PKINIT for each principal and request.
-
-    The KDC is not required to contain a database record for users
-    who use public key authentication.  However, if these users are
-    registered with the KDC, it is recommended that the database record
-    for these users be modified to an additional flag in the attributes
-    field to indicate that the user should authenticate using PKINIT.
-    If this flag is set and a request message does not contain the
-    PKINIT preauthentication field, then the KDC sends back as error of
-    type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
-    field of type PA-PK-AS-REQ must be included in the request.
-
-5.  Security Considerations
-
-    PKINIT raises a few security considerations, which we will address
-    in this section.
-
-    First of all, PKINIT introduces a new trust model, where KDCs do not
-    (necessarily) certify the identity of those for whom they issue
-    tickets.  PKINIT does allow KDCs to act as their own CAs, in the
-    limited capacity of self-signing their certificates, but one of the
-    additional benefits is to align Kerberos authentication with a global
-    public key infrastructure.  Anyone using PKINIT in this way must be
-    aware of how the certification infrastructure they are linking to
-    works.
-
-    Secondly, PKINIT also introduces the possibility of interactions
-    between different cryptosystems, which may be of widely varying
-    strengths.  Many systems, for instance, allow the use of 512-bit
-    public keys.  Using such keys to wrap data encrypted under strong
-    conventional cryptosystems, such as triple-DES, is inappropriate;
-    it adds a weak link to a strong one at extra cost.  Implementors
-    and administrators should take care to avoid such wasteful and
-    deceptive interactions.
-
-    Lastly, PKINIT calls for randomly generated keys for conventional
-    cryptosystems.  Many such systems contain systematically "weak"
-    keys.  PKINIT implementations MUST avoid use of these keys, either
-    by discarding those keys when they are generated, or by fixing them
-    in some way (e.g., by XORing them with a given mask).  These
-    precautions vary from system to system; it is not our intention to
-    give an explicit recipe for them here.
-
-6.  Transport Issues
-
-    Certificate chains can potentially grow quite large and span several
-    UDP packets; this in turn increases the probability that a Kerberos
-    message involving PKINIT extensions will be broken in transit.  In
-    light of the possibility that the Kerberos specification will
-    require KDCs to accept requests using TCP as a transport mechanism,
-    we make the same recommendation with respect to the PKINIT
-    extensions as well.
-
-7.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-    (V5).  Request for Comments 1510.
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.  September
-    1994.
-
-    [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
-    A. Medvinsky, M. Hur.  Public Key Cryptography for Cross-Realm
-    Authentication in Kerberos.  draft-ietf-cat-kerberos-pk-cross-04.txt
-
-    [4] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
-    Kerberos.  draft-ietf-cat-kerberos-anoncred-00.txt
-
-    [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman.
-    Public Key Utilizing Tickets for Application Servers (PKTAPP).
-    draft-ietf-cat-pktapp-02.txt
-
-    [6] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-    Using Public Key Cryptography.  Symposium On Network and Distributed
-    System Security, 1997.
-
-    [7] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic
-    Commerce, July 1995.
-
-    [8] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
-    Request for Comments 2246, January 1999.
-
-    [9] B.C. Neuman, Proxy-Based Authorization and Accounting for
-    Distributed Systems.  In Proceedings of the 13th International
-    Conference on Distributed Computing Systems, May 1993.
-
-    [10] ITU-T (formerly CCITT) Information technology - Open Systems
-    Interconnection - The Directory: Authentication Framework
-    Recommendation X.509 ISO/IEC 9594-8
-
-    [11] R. Housley. Cryptographic Message Syntax.
-    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
-    as RFC.
-
-    [12] PKCS #7: Cryptographic Message Syntax Standard,
-    An RSA Laboratories Technical Note Version 1.5
-    Revised November 1, 1993
-
-    [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
-    Security, Inc. A Description of the RC2(r) Encryption Algorithm
-    March 1998.
-    Request for Comments 2268.
-
-    [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
-    Protocol (v3): UTF-8 String Representation of Distinguished Names.
-    Request for Comments 2253.
-
-    [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
-    Key Infrastructure, Certificate and CRL Profile, January 1999.
-    Request for Comments 2459.
-
-    [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-    Specifications, October 1998.  Request for Comments 2437.
-
-    [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
-    Version 2 Certificate Handling, March 1998.  Request for
-    Comments 2312.
-
-    [18] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
-    Protocol (v3), December 1997.  Request for Comments 2251.
-
-    [19] ITU-T (formerly CCITT) Information Processing Systems - Open
-    Systems Interconnection - Specification of Abstract Syntax Notation
-    One (ASN.1) Rec. X.680 ISO/IEC 8824-1
-
-    [20] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
-    Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
-
-8.  Acknowledgements
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-9.  Expiration Date
-
-    This draft expires January 15, 2001.
-
-10. Authors
-
-    Brian Tung
-    Clifford Neuman
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {brian, bcn}@isi.edu
-
-    Matthew Hur
-    CyberSafe Corporation
-    1605 NW Sammamish Road
-    Issaquah WA 98027-5378
-    Phone: +1 425 391 6000
-    E-mail: matt.hur@cybersafe.com
-
-    Ari Medvinsky
-    Keen.com, Inc.
-    150 Independence Drive
-    Menlo Park CA 94025
-    Phone: +1 650 289 3134
-    E-mail: ari@keen.com
-
-    Sasha Medvinsky
-    Motorola
-    6450 Sequence Drive
-    San Diego, CA 92121
-    +1 858 404 2367
-    E-mail: smedvinsky@gi.com
-
-    John Wray
-    Iris Associates, Inc.
-    5 Technology Park Dr.
-    Westford, MA 01886
-    E-mail: John_Wray@iris.com
-
-    Jonathan Trostle
-    170 W. Tasman Dr.
-    San Jose, CA 95134
-    E-mail: jtrostle@cisco.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-13.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-13.txt
deleted file mode 100644
index 1bcc2ad45..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-13.txt
+++ /dev/null
@@ -1,1062 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-13.txt                   Clifford Neuman
-Updates: RFC 1510                                                USC/ISI
-expires August 31, 2001                                      Matthew Hur
-                                                                   Cisco
-                                                           Ari Medvinsky
-                                                          Keen.com, Inc.
-                                                         Sasha Medvinsky
-                                                                Motorola
-                                                               John Wray
-                                                   Iris Associates, Inc.
-                                                        Jonathan Trostle
-                                                                   Cisco
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-0.  Status Of This Memo
-
-    This document is an Internet-Draft and is in full conformance with
-    all provisions of Section 10 of RFC 2026.  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."
-
-    The list of current Internet-Drafts can be accessed at
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-    The list of Internet-Draft Shadow Directories can be accessed at
-    http://www.ietf.org/shadow.html.
-
-    To learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ftp.ietf.org (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-11.txt, and expires August 31,
-    2001.  Please send comments to the authors.
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510 [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to associate a key pair with each realm, which can
-    then be used to facilitate cross-realm authentication; this is the
-    topic of another draft proposal.  Another way is to allow users with
-    public key certificates to use them in initial authentication.  This
-    is the concern of the current document.
-
-    PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
-    combination with DSA keys as the primary, required mechanism.  Note
-    that PKINIT supports the use of separate signature and encryption
-    keys.
-
-    PKINIT enables access to Kerberos-secured services based on initial
-    authentication utilizing public key cryptography.  PKINIT utilizes
-    standard public key signature and encryption data formats within the
-    standard Kerberos messages.  The basic mechanism is as follows:  The
-    user sends an AS-REQ message to the KDC as before, except that if that
-    user is to use public key cryptography in the initial authentication
-    step, his certificate and a signature accompany the initial request
-    in the preauthentication fields.  Upon receipt of this request, the
-    KDC verifies the certificate and issues a ticket granting ticket
-    (TGT) as before, except that the encPart from the AS-REP message
-    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
-    derived key or the user's public key.  This message is authenticated
-    utilizing the public key signature of the KDC.
-
-    Note that PKINIT does not require the use of certificates.  A KDC
-    may store the public key of a principal as part of that principal's
-    record.  In this scenario, the KDC is the trusted party that vouches
-    for the principal (as in a standard, non-cross realm, Kerberos
-    environment).  Thus, for any principal, the KDC may maintain a
-    symmetric key, a public key, or both.
-
-    The PKINIT specification may also be used as a building block for
-    other specifications.  PKINIT may be utilized to establish
-    inter-realm keys for the purposes of issuing cross-realm service
-    tickets.  It may also be used to issue anonymous Kerberos tickets
-    using the Diffie-Hellman option.  Efforts are under way to draft
-    specifications for these two application protocols.
-
-    Additionally, the PKINIT specification may be used for direct peer
-    to peer authentication without contacting a central KDC. This
-    application of PKINIT is described in PKTAPP [5] and is based on
-    concepts introduced in [6, 7]. For direct client-to-server
-    authentication, the client uses PKINIT to authenticate to the end
-    server (instead of a central KDC), which then issues a ticket for
-    itself.  This approach has an advantage over TLS [8] in that the
-    server does not need to save state (cache session keys).
-    Furthermore, an additional benefit is that Kerberos tickets can
-    facilitate delegation (see [9]).
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510 for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following change to RFC 1510 is proposed:
-
-        * Users may authenticate using either a public key pair or a
-          conventional (symmetric) key.  If public key cryptography is
-          used, public key data is transported in preauthentication
-          data fields to help establish identity.  The user presents
-          a public key certificate and obtains an ordinary TGT that may
-          be used for subsequent authentication, with such
-          authentication using only conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 describes the extensions for the initial authentication
-    method.
-
-3.1.  Definitions
-
-    The extensions involve new preauthentication fields; we introduce
-    the following preauthentication types:
-
-        PA-PK-AS-REQ                            14
-        PA-PK-AS-REP                            15
-
-    The extensions also involve new error types; we introduce the
-    following types:
-
-        KDC_ERR_CLIENT_NOT_TRUSTED              62
-        KDC_ERR_KDC_NOT_TRUSTED                 63
-        KDC_ERR_INVALID_SIG                     64
-        KDC_ERR_KEY_TOO_WEAK                    65
-        KDC_ERR_CERTIFICATE_MISMATCH            66
-        KDC_ERR_CANT_VERIFY_CERTIFICATE         70
-        KDC_ERR_INVALID_CERTIFICATE             71
-        KDC_ERR_REVOKED_CERTIFICATE             72
-        KDC_ERR_REVOCATION_STATUS_UNKNOWN       73
-        KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74
-        KDC_ERR_CLIENT_NAME_MISMATCH            75
-        KDC_ERR_KDC_NAME_MISMATCH               76
-
-    We utilize the following typed data for errors:
-
-        TD-PKINIT-CMS-CERTIFICATES             101
-        TD-KRB-PRINCIPAL                       102
-        TD-KRB-REALM                           103
-        TD-TRUSTED-CERTIFIERS                  104
-        TD-CERTIFICATE-INDEX                   105
-
-    We utilize the following encryption types (which map directly to
-    OIDs):
-
-        dsaWithSHA1-CmsOID                       9
-        md5WithRSAEncryption-CmsOID             10
-        sha1WithRSAEncryption-CmsOID            11
-        rc2CBC-EnvOID                           12
-        rsaEncryption-EnvOID (PKCS#1 v1.5)      13
-        rsaES-OAEP-ENV-OID   (PKCS#1 v2.0)      14
-        des-ede3-cbc-Env-OID                    15
-
-    These mappings are provided so that a client may send the
-    appropriate enctypes in the AS-REQ message in order to indicate
-    support for the corresponding OIDs (for performing PKINIT).
-
-    In many cases, PKINIT requires the encoding of the X.500 name of a
-    certificate authority as a Realm.  When such a name appears as
-    a realm it will be represented using the "Other" form of the realm
-    name as specified in the naming constraints section of RFC1510.
-    For a realm derived from an X.500 name, NAMETYPE will have the value
-    X500-RFC2253.  The full realm name will appear as follows:
-
-        <nametype> + ":" + <string>
-
-    where nametype is "X500-RFC2253" and string is the result of doing
-    an RFC2253 encoding of the distinguished name, i.e.
-
-        "X500-RFC2253:" + RFC2253Encode(DistinguishedName)
-
-    where DistinguishedName is an X.500 name, and RFC2253Encode is a
-    function returing a readable UTF encoding of an X.500 name, as
-    defined by RFC 2253 [14] (part of LDAPv3 [18]).
-
-    To ensure that this encoding is unique, we add the following rule
-    to those specified by RFC 2253:
-
-        The order in which the attributes appear in the RFC 2253
-        encoding MUST be the reverse of the order in the ASN.1
-        encoding of the X.500 name that appears in the public key
-        certificate. The order of the relative distinguished names
-        (RDNs), as well as the order of the AttributeTypeAndValues
-        within each RDN, will be reversed. (This is despite the fact
-        that an RDN is defined as a SET of AttributeTypeAndValues, where
-        an order is normally not important.)
-
-    Similarly, in cases where the KDC does not provide a specific
-    policy-based mapping from the X.500 name or X.509 Version 3
-    SubjectAltName extension in the user's certificate to a Kerberos
-    principal name, PKINIT requires the direct encoding of the X.500
-    name as a PrincipalName.  In this case, the name-type of the
-    principal name MUST be set to KRB_NT-X500-PRINCIPAL.  This new
-    name type is defined in RFC 1510 as:
-
-        KRB_NT_X500_PRINCIPAL    6
-
-    For this type, the name-string MUST be set as follows:
-
-        RFC2253Encode(DistinguishedName)
-
-    as described above.  When this name type is used, the principal's
-    realm MUST be set to the certificate authority's distinguished
-    name using the X500-RFC2253 realm name format described earlier in
-    this section.
-
-    RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
-
-        PrincipalName ::=   SEQUENCE {
-                        name-type[0]     INTEGER,
-                        name-string[1]   SEQUENCE OF GeneralString
-        }
-
-    The following rules relate to the the matching of PrincipalNames
-    with regard to the PKI name constraints for CAs as laid out in RFC
-    2459 [15].  In order to be regarded as a match (for permitted and
-    excluded name trees), the following MUST be satisfied.
-
-        1.  If the constraint is given as a user plus realm name, or
-            as a client principal name plus realm name (as specified in
-            RFC 1510), the realm name MUST be valid (see 2.a-d below)
-            and the match MUST be exact, byte for byte.
-
-        2.  If the constraint is given only as a realm name, matching
-            depends on the type of the realm:
-
-            a.  If the realm contains a colon (':') before any equal
-                sign ('='), it is treated as a realm of type Other,
-                and MUST match exactly, byte for byte.
-
-            b.  Otherwise, if the realm name conforms to rules regarding
-                the format of DNS names, it is considered a realm name of
-                type Domain.  The constraint may be given as a realm
-                name 'FOO.BAR', which matches any PrincipalName within
-                the realm 'FOO.BAR' but not those in subrealms such as
-                'CAR.FOO.BAR'.  A constraint of the form '.FOO.BAR'
-                matches PrincipalNames in subrealms of the form
-                'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
-
-            c.  Otherwise, the realm name is invalid and does not match
-                under any conditions.
-
-3.1.1.  Encryption and Key Formats
-
-    In the exposition below, we use the terms public key and private
-    key generically.  It should be understood that the term "public
-    key" may be used to refer to either a public encryption key or a
-    signature verification key, and that the term "private key" may be
-    used to refer to either a private decryption key or a signature
-    generation key.  The fact that these are logically distinct does
-    not preclude the assignment of bitwise identical keys for RSA
-    keys.
-
-    In the case of Diffie-Hellman, the key is produced from the agreed
-    bit string as follows:
-
-        * Truncate the bit string to the appropriate length.
-        * Rectify parity in each byte (if necessary) to obtain the key.
-
-    For instance, in the case of a DES key, we take the first eight
-    bytes of the bit stream, and then adjust the least significant bit
-    of each byte to ensure that each byte has odd parity.
-
-3.1.2. Algorithm Identifiers
-
-    PKINIT does not define, but does permit, the algorithm identifiers
-    listed below.
-
-3.1.2.1. Signature Algorithm Identifiers
-
-    The following signature algorithm identifiers specified in [11] and
-    in [15] are used with PKINIT:
-
-    id-dsa-with-sha1       (DSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    sha-1WithRSAEncryption (RSA with SHA1)
-
-3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
-
-    The following algorithm identifier shall be used within the
-    SubjectPublicKeyInfo data structure: dhpublicnumber
-
-    This identifier and the associated algorithm parameters are
-    specified in RFC 2459 [15].
-
-3.1.2.3. Algorithm Identifiers for RSA Encryption
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure, for encrypting the temporary key with a public key:
-
-        rsaEncryption (RSA encryption, PKCS#1 v1.5)
-        id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
-
-    Both of the above RSA encryption schemes are specified in [16].
-    Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
-    CMS specification says that it will likely include PKCS#1 v2.0 in
-    the future.  (PKCS#1 v2.0 addresses adaptive chosen ciphertext
-    vulnerability discovered in PKCS#1 v1.5.)
-
-3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure in the PKINIT Reply, for encrypting the reply key with the
-    temporary key:
-        des-ede3-cbc (3-key 3-DES, CBC mode)
-        rc2-cbc      (RC2, CBC mode)
-
-    The full definition of the above algorithm identifiers and their
-    corresponding parameters (an IV for block chaining) is provided in
-    the CMS specification [11].
-
-3.2.  Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with PKINIT.
-
-3.2.1.  Client Request
-
-    Public keys may be signed by some certification authority (CA), or
-    they may be maintained by the KDC in which case the KDC is the
-    trusted authority.  Note that the latter mode does not require the
-    use of certificates.
-
-    The initial authentication request is sent as per RFC 1510, except
-    that a preauthentication field containing data signed by the user's
-    private key accompanies the request:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                -- PA TYPE 14
-        signedAuthPack          [0] SignedData
-                                    -- Defined in CMS [11];
-                                    -- AuthPack (below) defines the
-                                    -- data that is signed.
-        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
-                                    -- This is a list of CAs that the
-                                    -- client trusts and that certify
-                                    -- KDCs.
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
-                                    -- As defined in CMS [11];
-                                    -- specifies a particular KDC
-                                    -- certificate if the client
-                                    -- already has it.
-        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
-                                    -- For example, this may be the
-                                    -- client's Diffie-Hellman
-                                    -- certificate, or it may be the
-                                    -- client's RSA encryption
-                                    -- certificate.
-    }
-
-    TrustedCas ::= CHOICE {
-        principalName         [0] KerberosName,
-                                  -- as defined below
-        caName                [1] Name
-                                  -- fully qualified X.500 name
-                                  -- as defined by X.509
-        issuerAndSerial       [2] IssuerAndSerialNumber
-                                  -- Since a CA may have a number of
-                                  -- certificates, only one of which
-                                  -- a client trusts
-    }
-
-    Usage of SignedData:
-
-        The SignedData data type is specified in the Cryptographic
-        Message Syntax, a product of the S/MIME working group of the
-        IETF.  The following describes how to fill in the fields of
-        this data:
-
-        1.  The encapContentInfo field MUST contain the PKAuthenticator
-            and, optionally, the client's Diffie Hellman public value.
-
-            a.  The eContentType field MUST contain the OID value for
-                pkauthdata: iso (1) org (3) dod (6) internet (1)
-                security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)
-
-            b.  The eContent field is data of the type AuthPack (below).
-
-        2.  The signerInfos field contains the signature of AuthPack.
-
-        3.  The Certificates field, when non-empty, contains the client's
-            certificate chain.  If present, the KDC uses the public key
-            from the client's certificate to verify the signature in the
-            request.  Note that the client may pass different certificate
-            chains that are used for signing or for encrypting.  Thus,
-            the KDC may utilize a different client certificate for
-            signature verification than the one it uses to encrypt the
-            reply to the client.  For example, the client may place a
-            Diffie-Hellman certificate in this field in order to convey
-            its static Diffie Hellman certificate to the KDC to enable
-            static-ephemeral Diffie-Hellman mode for the reply; in this
-            case, the client does NOT place its public value in the
-            AuthPack (defined below).  As another example, the client may
-            place an RSA encryption certificate in this field.  However,
-            there MUST always be (at least) a signature certificate.
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- if client is using Diffie-Hellman
-                                    -- (ephemeral-ephemeral only)
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER,
-                                    -- for replay prevention as in RFC1510
-        ctime                   [1] KerberosTime,
-                                    -- for replay prevention as in RFC1510
-        nonce                   [2] INTEGER,
-        pachecksum              [3] Checksum
-                                    -- Checksum over KDC-REQ-BODY
-                                    -- Defined by Kerberos spec
-    }
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm                   AlgorithmIdentifier,
-                                    -- dhKeyAgreement
-        subjectPublicKey            BIT STRING
-                                    -- for DH, equals
-                                    -- public exponent (INTEGER encoded
-                                    -- as payload of BIT STRING)
-    }   -- as specified by the X.509 recommendation [10]
-
-    AlgorithmIdentifier ::= SEQUENCE {
-        algorithm                   OBJECT IDENTIFIER,
-                                    -- for dhKeyAgreement, this is
-                                    -- { iso (1) member-body (2) US (840)
-                                    -- rsadsi (113459) pkcs (1) 3 1 }
-                                    -- from PKCS #3 [20]
-        parameters                  ANY DEFINED by algorithm OPTIONAL
-                                    -- for dhKeyAgreement, this is
-                                    -- DHParameter
-    }   -- as specified by the X.509 recommendation [10]
-
-    DHParameter ::= SEQUENCE {
-        prime                       INTEGER,
-                                    -- p
-        base                        INTEGER,
-                                    -- g
-        privateValueLength          INTEGER OPTIONAL
-                                    -- l
-    }   -- as defined in PKCS #3 [20]
-
-    If the client passes an issuer and serial number in the request,
-    the KDC is requested to use the referred-to certificate.  If none
-    exists, then the KDC returns an error of type
-    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
-    other hand, the client does not pass any trustedCertifiers,
-    believing that it has the KDC's certificate, but the KDC has more
-    than one certificate.  The KDC should include information in the
-    KRB-ERROR message that indicates the KDC certificate(s) that a
-    client may utilize.  This data is specified in the e-data, which
-    is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
-
-    TypedData ::=  SEQUENCE {
-                    data-type      [0] INTEGER,
-                    data-value     [1] OCTET STRING,
-    } -- per Kerberos RFC 1510 revisions
-
-    where:
-    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
-    data-value = CertificateSet // as specified by CMS [11]
-
-    The PKAuthenticator carries information to foil replay attacks, to
-    bind the pre-authentication data to the KDC-REQ-BODY, and to bind the
-    request and response.  The PKAuthenticator is signed with the client's
-    signature key.
-
-3.2.2.  KDC Response
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.
-
-    If the client's certificate chain contains no certificate signed by
-    a CA trusted by the KDC, then the KDC sends back an error message
-    of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data
-    is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
-    whose data-value is an OCTET STRING which is the DER encoding of
-
-        TrustedCertifiers ::= SEQUENCE OF PrincipalName
-                              -- X.500 name encoded as a principal name
-                              -- see Section 3.1
-
-    If while verifying a certificate chain the KDC determines that the
-    signature on one of the certificates in the CertificateSet from
-    the signedAuthPack fails verification, then the KDC returns an
-    error of type KDC_ERR_INVALID_CERTIFICATE.  The accompanying
-    e-data is a SEQUENCE of one TypedData (with type
-    TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
-    which is the DER encoding of the index into the CertificateSet
-    ordered as sent by the client.
-
-        CertificateIndex  ::= INTEGER
-                              -- 0 = 1st certificate,
-                              --     (in order of encoding)
-                              -- 1 = 2nd certificate, etc
-
-    The KDC may also check whether any of the certificates in the
-    client's chain has been revoked.  If one of the certificates has
-    been revoked, then the KDC returns an error of type
-    KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
-    the certificate's revocation status is unknown or not
-    available, then if required by policy, the KDC returns the
-    appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
-    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE.  In any of these three
-    cases, the affected certificate is identified by the accompanying
-    e-data, which contains a CertificateIndex as described for
-    KDC_ERR_INVALID_CERTIFICATE.
-
-    If the certificate chain can be verified, but the name of the
-    client in the certificate does not match the client's name in the
-    request, then the KDC returns an error of type
-    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
-    field in this case.
-
-    Finally, if the certificate chain is verified, but the KDC's name
-    or realm as given in the PKAuthenticator does not match the KDC's
-    actual principal name, then the KDC returns an error of type
-    KDC_ERR_KDC_NAME_MISMATCH.  The accompanying e-data field is again
-    a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
-    TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
-    STRING whose data-value is the DER encoding of a PrincipalName or
-    Realm as defined in RFC 1510 revisions.
-
-    Even if all succeeds, the KDC may--for policy reasons--decide not
-    to trust the client.  In this case, the KDC returns an error message
-    of type KDC_ERR_CLIENT_NOT_TRUSTED.  One specific case of this is
-    the presence or absence of an Enhanced Key Usage (EKU) OID within
-    the certificate extensions.  The rules regarding acceptability of
-    an EKU sequence (or the absence of any sequence) are a matter of
-    local policy.  For the benefit of implementers, we define a PKINIT
-    EKU OID as the following: iso (1) org (3) dod (6) internet (1)
-    security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on AuthPack.  If that fails, the KDC returns an error
-    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
-    timestamp (ctime and cusec) in the PKAuthenticator to assure that
-    the request is not a replay.  The KDC also verifies that its name
-    is specified in the PKAuthenticator.
-
-    If the clientPublicValue field is filled in, indicating that the
-    client wishes to use Diffie-Hellman key agreement, then the KDC
-    checks to see that the parameters satisfy its policy.  If they do
-    not (e.g., the prime size is insufficient for the expected
-    encryption type), then the KDC sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
-    private values for the response.
-
-    The KDC also checks that the timestamp in the PKAuthenticator is
-    within the allowable window and that the principal name and realm
-    are correct.  If the local (server) time and the client time in the
-    authenticator differ by more than the allowable clock skew, then the
-    KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 1510.
-
-    Assuming no errors, the KDC replies as per RFC 1510, except as
-    follows.  The user's name in the ticket is determined by the
-    following decision algorithm:
-
-        1.  If the KDC has a mapping from the name in the certificate
-            to a Kerberos name, then use that name.
-            Else
-        2.  If the certificate contains the SubjectAltName extention
-            and the local KDC policy defines a mapping from the
-            SubjectAltName to a Kerberos name, then use that name.
-            Else
-        3.  Use the name as represented in the certificate, mapping
-            as necessary (e.g., as per RFC 2253 for X.500 names).  In
-            this case the realm in the ticket MUST be the name of the
-            certifier that issued the user's certificate.
-
-    Note that a principal name may be carried in the subjectAltName
-    field of a certificate. This name may be mapped to a principal
-    record in a security database based on local policy, for example
-    the subjectAltName may be kerberos/principal@realm format.  In
-    this case the realm name is not that of the CA but that of the
-    local realm doing the mapping (or some realm name chosen by that
-    realm).
-
-    If a non-KDC X.509 certificate contains the principal name within
-    the subjectAltName version 3 extension, that name may utilize
-    KerberosName as defined below, or, in the case of an S/MIME
-    certificate [17], may utilize the email address.  If the KDC
-    is presented with an S/MIME certificate, then the email address
-    within subjectAltName will be interpreted as a principal and realm
-    separated by the "@" sign, or as a name that needs to be mapped
-    according to local policy.  If the resulting name does not correspond
-    to a registered principal name, then the principal name is formed as
-    defined in section 3.1.
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.  If the KDC has no
-    certificate signed by any of the trustedCertifiers, then it returns
-    an error of type KDC_ERR_KDC_NOT_TRUSTED.
-
-    KDCs should try to (in order of preference):
-    1. Use the KDC certificate identified by the serialNumber included
-       in the client's request.
-    2. Use a certificate issued to the KDC by one of the client's
-       trustedCertifier(s);
-    If the KDC is unable to comply with any of these options, then the
-    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
-    client.
-
-    The KDC encrypts the reply not with the user's long-term key, but
-    with the Diffie Hellman derived key or a random key generated
-    for this particular response which is carried in the padata field of
-    the TGS-REP message.
-
-    PA-PK-AS-REP ::= CHOICE {
-                            -- PA TYPE 15
-        dhSignedData       [0] SignedData,
-                            -- Defined in CMS and used only with
-                            -- Diffie-Hellman key exchange (if the
-                            -- client public value was present in the
-                            -- request).
-                            -- This choice MUST be supported
-                            -- by compliant implementations.
-        encKeyPack         [1] EnvelopedData,
-                            -- Defined in CMS
-                            -- The temporary key is encrypted
-                            -- using the client public key
-                            -- key
-                            -- SignedReplyKeyPack, encrypted
-                            -- with the temporary key, is also
-                            -- included.
-    }
-
-    Usage of SignedData:
-
-        When the Diffie-Hellman option is used, dhSignedData in
-        PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
-        of the KDC.  The reply key used to encrypt part of the KDC reply
-        message is derived from the Diffie-Hellman exchange:
-
-        1.  Both the KDC and the client calculate a secret value
-            (g^ab mod p), where a is the client's private exponent and
-            b is the KDC's private exponent.
-
-        2.  Both the KDC and the client take the first N bits of this
-            secret value and convert it into a reply key.  N depends on
-            the reply key type.
-
-            a.  For example, if the reply key is DES, N=64 bits, where
-                some of the bits are replaced with parity bits, according
-                to FIPS PUB 74.
-
-            b.  As another example, if the reply key is (3-key) 3-DES,
-                N=192 bits, where some of the bits are replaced with
-                parity bits, according to FIPS PUB 74.
-
-        3.  The encapContentInfo field MUST contain the KdcDHKeyInfo as
-            defined below.
-
-            a.  The eContentType field MUST contain the OID value for
-                pkdhkeydata: iso (1) org (3) dod (6) internet (1)
-                security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)
-
-            b.  The eContent field is data of the type KdcDHKeyInfo
-                (below).
-
-        4.  The certificates field MUST contain the certificates
-            necessary for the client to establish trust in the KDC's
-            certificate based on the list of trusted certifiers sent by
-            the client in the PA-PK-AS-REQ.  This field may be empty if
-            the client did not send to the KDC a list of trusted
-            certifiers (the trustedCertifiers field was empty, meaning
-            that the client already possesses the KDC's certificate).
-
-        5.  The signerInfos field is a SET that MUST contain at least
-            one member, since it contains the actual signature.
-
-    KdcDHKeyInfo ::= SEQUENCE {
-                              -- used only when utilizing Diffie-Hellman
-      nonce                 [0] INTEGER,
-                                -- binds responce to the request
-      subjectPublicKey      [2] BIT STRING
-                                -- Equals public exponent (g^a mod p)
-                                -- INTEGER encoded as payload of
-                                -- BIT STRING
-    }
-
-    Usage of EnvelopedData:
-
-        The EnvelopedData data type is specified in the Cryptographic
-        Message Syntax, a product of the S/MIME working group of the
-        IETF.  It contains a temporary key encrypted with the PKINIT
-        client's public key.  It also contains a signed and encrypted
-        reply key.
-
-        1.  The originatorInfo field is not required, since that
-            information may be presented in the signedData structure
-            that is encrypted within the encryptedContentInfo field.
-
-        2.  The optional unprotectedAttrs field is not required for
-            PKINIT.
-
-        3.  The recipientInfos field is a SET which MUST contain exactly
-            one member of the KeyTransRecipientInfo type for encryption
-            with a public key.
-
-            a.  The encryptedKey field (in KeyTransRecipientInfo)
-                contains the temporary key which is encrypted with the
-                PKINIT client's public key.
-
-        4.  The encryptedContentInfo field contains the signed and
-            encrypted reply key.
-
-            a.  The contentType field MUST contain the OID value for
-                id-signedData: iso (1) member-body (2) us (840)
-                rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
-
-            b.  The encryptedContent field is encrypted data of the CMS
-                type signedData as specified below.
-
-                i.  The encapContentInfo field MUST contains the
-                    ReplyKeyPack.
-
-                    * The eContentType field MUST contain the OID value
-                      for pkrkeydata: iso (1) org (3) dod (6) internet (1)
-                      security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3)
-
-                    * The eContent field is data of the type ReplyKeyPack
-                      (below).
-
-                ii.  The certificates field MUST contain the certificates
-                     necessary for the client to establish trust in the
-                     KDC's certificate based on the list of trusted
-                     certifiers sent by the client in the PA-PK-AS-REQ.
-                     This field may be empty if the client did not send
-                     to the KDC a list of trusted certifiers (the
-                     trustedCertifiers field was empty, meaning that the
-                     client already possesses the KDC's certificate).
-
-                iii.  The signerInfos field is a SET that MUST contain at
-                      least one member, since it contains the actual
-                      signature.
-
-    ReplyKeyPack ::= SEQUENCE {
-                              -- not used for Diffie-Hellman
-        replyKey             [0] EncryptionKey,
-                                 -- from RFC 1510bis
-                                 -- used to encrypt main reply
-                                 -- ENCTYPE is at least as strong as
-                                 -- ENCTYPE of session key
-        nonce                [1] INTEGER,
-                                 -- binds response to the request
-                                 -- must be same as the nonce
-                                 -- passed in the PKAuthenticator
-    }
-
-
-3.2.2.1. Use of transited Field
-
-    Since each certifier in the certification path of a user's
-    certificate is equivalent to a separate Kerberos realm, the name
-    of each certifier in the certificate chain MUST be added to the
-    transited field of the ticket.  The format of these realm names is
-    defined in Section 3.1 of this document.  If applicable, the
-    transit-policy-checked flag should be set in the issued ticket.
-
-
-3.2.2.2. Kerberos Names in Certificates
-
-    The KDC's certificate(s) MUST bind the public key(s) of the KDC to
-    a name derivable from the name of the realm for that KDC.  X.509
-    certificates MUST contain the principal name of the KDC
-    (defined in section 8.2 of RFC 1510) as the SubjectAltName version
-    3 extension. Below is the definition of this version 3 extension,
-    as specified by the X.509 standard:
-
-        subjectAltName EXTENSION ::= {
-            SYNTAX GeneralNames
-            IDENTIFIED BY id-ce-subjectAltName
-        }
-
-        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
-
-        GeneralName ::= CHOICE {
-            otherName       [0] OtherName,
-            ...
-        }
-
-        OtherName ::= SEQUENCE {
-            type-id         OBJECT IDENTIFIER,
-            value           [0] EXPLICIT ANY DEFINED BY type-id
-        }
-
-    For the purpose of specifying a Kerberos principal name, the value
-    in OtherName MUST be a KerberosName as defined in RFC 1510:
-
-        KerberosName ::= SEQUENCE {
-            realm           [0] Realm,
-            principalName   [1] PrincipalName
-        }
-
-    This specific syntax is identified within subjectAltName by setting
-    the type-id in OtherName to krb5PrincipalName, where (from the
-    Kerberos specification) we have
-
-        krb5 OBJECT IDENTIFIER ::= { iso (1)
-                                     org (3)
-                                     dod (6)
-                                     internet (1)
-                                     security (5)
-                                     kerberosv5 (2) }
-
-        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
-
-    (This specification may also be used to specify a Kerberos name
-    within the user's certificate.)  The KDC's certificate may be signed
-    directly by a CA, or there may be intermediaries if the server resides
-    within a large organization, or it may be unsigned if the client
-    indicates possession (and trust) of the KDC's certificate.
-
-    Note that the KDC's principal name has the instance equal to the
-    realm, and those fields should be appropriately set in the realm
-    and principalName fields of the KerberosName.  This is the case
-    even when obtaining a cross-realm ticket using PKINIT.
-
-
-3.2.3. Client Extraction of Reply
-
-    The client then extracts the random key used to encrypt the main
-    reply.  This random key (in encPaReply) is encrypted with either the
-    client's public key or with a key derived from the DH values
-    exchanged between the client and the KDC.  The client uses this
-    random key to decrypt the main reply, and subsequently proceeds as
-    described in RFC 1510.
-
-3.2.4. Required Algorithms
-
-    Not all of the algorithms in the PKINIT protocol specification have
-    to be implemented in order to comply with the proposed standard.
-    Below is a list of the required algorithms:
-
-    * Diffie-Hellman public/private key pairs
-        * utilizing Diffie-Hellman ephemeral-ephemeral mode
-    * SHA1 digest and DSA for signatures
-    * SHA1 digest also for the Checksum in the PKAuthenticator
-    * 3-key triple DES keys derived from the Diffie-Hellman Exchange
-    * 3-key triple DES Temporary and Reply keys
-
-4.  Logistics and Policy
-
-    This section describes a way to define the policy on the use of
-    PKINIT for each principal and request.
-
-    The KDC is not required to contain a database record for users
-    who use public key authentication.  However, if these users are
-    registered with the KDC, it is recommended that the database record
-    for these users be modified to an additional flag in the attributes
-    field to indicate that the user should authenticate using PKINIT.
-    If this flag is set and a request message does not contain the
-    PKINIT preauthentication field, then the KDC sends back as error of
-    type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
-    field of type PA-PK-AS-REQ must be included in the request.
-
-5.  Security Considerations
-
-    PKINIT raises a few security considerations, which we will address
-    in this section.
-
-    First of all, PKINIT introduces a new trust model, where KDCs do not
-    (necessarily) certify the identity of those for whom they issue
-    tickets.  PKINIT does allow KDCs to act as their own CAs, in the
-    limited capacity of self-signing their certificates, but one of the
-    additional benefits is to align Kerberos authentication with a global
-    public key infrastructure.  Anyone using PKINIT in this way must be
-    aware of how the certification infrastructure they are linking to
-    works.
-
-    Secondly, PKINIT also introduces the possibility of interactions
-    between different cryptosystems, which may be of widely varying
-    strengths.  Many systems, for instance, allow the use of 512-bit
-    public keys.  Using such keys to wrap data encrypted under strong
-    conventional cryptosystems, such as triple-DES, is inappropriate;
-    it adds a weak link to a strong one at extra cost.  Implementors
-    and administrators should take care to avoid such wasteful and
-    deceptive interactions.
-
-    Lastly, PKINIT calls for randomly generated keys for conventional
-    cryptosystems.  Many such systems contain systematically "weak"
-    keys.  PKINIT implementations MUST avoid use of these keys, either
-    by discarding those keys when they are generated, or by fixing them
-    in some way (e.g., by XORing them with a given mask).  These
-    precautions vary from system to system; it is not our intention to
-    give an explicit recipe for them here.
-
-6.  Transport Issues
-
-    Certificate chains can potentially grow quite large and span several
-    UDP packets; this in turn increases the probability that a Kerberos
-    message involving PKINIT extensions will be broken in transit.  In
-    light of the possibility that the Kerberos specification will
-    require KDCs to accept requests using TCP as a transport mechanism,
-    we make the same recommendation with respect to the PKINIT
-    extensions as well.
-
-7.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-    (V5).  Request for Comments 1510.
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.  September
-    1994.
-
-    [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
-    A. Medvinsky, M. Hur.  Public Key Cryptography for Cross-Realm
-    Authentication in Kerberos.  draft-ietf-cat-kerberos-pk-cross-04.txt
-
-    [4] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
-    Kerberos.  draft-ietf-cat-kerberos-anoncred-00.txt
-
-    [5] Ari Medvinsky, M. Hur, Alexander Medvinsky, B. Clifford Neuman.
-    Public Key Utilizing Tickets for Application Servers (PKTAPP).
-    draft-ietf-cat-pktapp-02.txt
-
-    [6] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-    Using Public Key Cryptography.  Symposium On Network and Distributed
-    System Security, 1997.
-
-    [7] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic
-    Commerce, July 1995.
-
-    [8] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
-    Request for Comments 2246, January 1999.
-
-    [9] B.C. Neuman, Proxy-Based Authorization and Accounting for
-    Distributed Systems.  In Proceedings of the 13th International
-    Conference on Distributed Computing Systems, May 1993.
-
-    [10] ITU-T (formerly CCITT) Information technology - Open Systems
-    Interconnection - The Directory: Authentication Framework
-    Recommendation X.509 ISO/IEC 9594-8
-
-    [11] R. Housley. Cryptographic Message Syntax.
-    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
-    as RFC.
-
-    [12] PKCS #7: Cryptographic Message Syntax Standard,
-    An RSA Laboratories Technical Note Version 1.5
-    Revised November 1, 1993
-
-    [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
-    Security, Inc. A Description of the RC2(r) Encryption Algorithm
-    March 1998.
-    Request for Comments 2268.
-
-    [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
-    Protocol (v3): UTF-8 String Representation of Distinguished Names.
-    Request for Comments 2253.
-
-    [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
-    Key Infrastructure, Certificate and CRL Profile, January 1999.
-    Request for Comments 2459.
-
-    [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-    Specifications, October 1998.  Request for Comments 2437.
-
-    [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
-    Version 2 Certificate Handling, March 1998.  Request for
-    Comments 2312.
-
-    [18] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
-    Protocol (v3), December 1997.  Request for Comments 2251.
-
-    [19] ITU-T (formerly CCITT) Information Processing Systems - Open
-    Systems Interconnection - Specification of Abstract Syntax Notation
-    One (ASN.1) Rec. X.680 ISO/IEC 8824-1
-
-    [20] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
-    Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
-
-8.  Acknowledgements
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-9.  Expiration Date
-
-    This draft expires August 31, 2001.
-
-10. Authors
-
-    Brian Tung
-    Clifford Neuman
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {brian, bcn}@isi.edu
-
-    Matthew Hur
-    Cisco Systems
-    500 108th Ave. NE, Suite 500
-    Bellevue, WA 98004
-    Phone: (408) 525-0034
-    EMail: mhur@cisco.com
-
-    Ari Medvinsky
-    Keen.com, Inc.
-    150 Independence Drive
-    Menlo Park CA 94025
-    Phone: +1 650 289 3134
-    E-mail: ari@keen.com
-
-    Sasha Medvinsky
-    Motorola
-    6450 Sequence Drive
-    San Diego, CA 92121
-    +1 858 404 2367
-    E-mail: smedvinsky@gi.com
-
-    John Wray
-    Iris Associates, Inc.
-    5 Technology Park Dr.
-    Westford, MA 01886
-    E-mail: John_Wray@iris.com
-
-    Jonathan Trostle
-    Cisco Systems
-    170 W. Tasman Dr.
-    San Jose, CA 95134
-    E-mail: jtrostle@cisco.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-14.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-14.txt
deleted file mode 100644
index 49ea9de8e..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-14.txt
+++ /dev/null
@@ -1,1104 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-14.txt                   Clifford Neuman
-Updates: RFC 1510bis                                             USC/ISI
-expires January 15, 2002                                     Matthew Hur
-                                                                   Cisco
-                                                           Ari Medvinsky
-                                                          Keen.com, Inc.
-                                                         Sasha Medvinsky
-                                                                Motorola
-                                                               John Wray
-                                                   Iris Associates, Inc.
-                                                        Jonathan Trostle
-                                                                   Cisco
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-0.  Status Of This Memo
-
-    This document is an Internet-Draft and is in full conformance with
-    all provisions of Section 10 of RFC 2026.  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."
-
-    The list of current Internet-Drafts can be accessed at
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-    The list of Internet-Draft Shadow Directories can be accessed at
-    http://www.ietf.org/shadow.html.
-
-    To learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ftp.ietf.org (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-14.txt, and expires January 15,
-    2002.  Please send comments to the authors.
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510bis [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to associate a key pair with each realm, which can
-    then be used to facilitate cross-realm authentication; this is the
-    topic of another draft proposal.  Another way is to allow users with
-    public key certificates to use them in initial authentication.  This
-    is the concern of the current document.
-
-    PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
-    combination with DSA keys as the primary, required mechanism.  Note
-    that PKINIT supports the use of separate signature and encryption
-    keys.
-
-    PKINIT enables access to Kerberos-secured services based on initial
-    authentication utilizing public key cryptography.  PKINIT utilizes
-    standard public key signature and encryption data formats within the
-    standard Kerberos messages.  The basic mechanism is as follows:  The
-    user sends an AS-REQ message to the KDC as before, except that if that
-    user is to use public key cryptography in the initial authentication
-    step, his certificate and a signature accompany the initial request
-    in the preauthentication fields.  Upon receipt of this request, the
-    KDC verifies the certificate and issues a ticket granting ticket
-    (TGT) as before, except that the encPart from the AS-REP message
-    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
-    derived key or the user's public key.  This message is authenticated
-    utilizing the public key signature of the KDC.
-
-    Note that PKINIT does not require the use of certificates.  A KDC
-    may store the public key of a principal as part of that principal's
-    record.  In this scenario, the KDC is the trusted party that vouches
-    for the principal (as in a standard, non-cross realm, Kerberos
-    environment).  Thus, for any principal, the KDC may maintain a
-    symmetric key, a public key, or both.
-
-    The PKINIT specification may also be used as a building block for
-    other specifications.  PKINIT may be utilized to establish
-    inter-realm keys for the purposes of issuing cross-realm service
-    tickets.  It may also be used to issue anonymous Kerberos tickets
-    using the Diffie-Hellman option.  Efforts are under way to draft
-    specifications for these two application protocols.
-
-    Additionally, the PKINIT specification may be used for direct peer
-    to peer authentication without contacting a central KDC. This
-    application of PKINIT is based on concepts introduced in [6, 7].
-    For direct client-to-server authentication, the client uses PKINIT
-    to authenticate to the end server (instead of a central KDC), which
-    then issues a ticket for itself.  This approach has an advantage
-    over TLS [5] in that the server does not need to save state (cache
-    session keys).  Furthermore, an additional benefit is that Kerberos
-    tickets can facilitate delegation (see [6]).
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510bis for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following change to RFC 1510bis is proposed:
-
-        * Users may authenticate using either a public key pair or a
-          conventional (symmetric) key.  If public key cryptography is
-          used, public key data is transported in preauthentication
-          data fields to help establish identity.  The user presents
-          a public key certificate and obtains an ordinary TGT that may
-          be used for subsequent authentication, with such
-          authentication using only conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 describes the extensions for the initial authentication
-    method.
-
-3.1.  Definitions
-
-    The extensions involve new preauthentication fields; we introduce
-    the following preauthentication types:
-
-        PA-PK-AS-REQ                            14
-        PA-PK-AS-REP                            15
-
-    The extensions also involve new error types; we introduce the
-    following types:
-
-        KDC_ERR_CLIENT_NOT_TRUSTED              62
-        KDC_ERR_KDC_NOT_TRUSTED                 63
-        KDC_ERR_INVALID_SIG                     64
-        KDC_ERR_KEY_TOO_WEAK                    65
-        KDC_ERR_CERTIFICATE_MISMATCH            66
-        KDC_ERR_CANT_VERIFY_CERTIFICATE         70
-        KDC_ERR_INVALID_CERTIFICATE             71
-        KDC_ERR_REVOKED_CERTIFICATE             72
-        KDC_ERR_REVOCATION_STATUS_UNKNOWN       73
-        KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74
-        KDC_ERR_CLIENT_NAME_MISMATCH            75
-        KDC_ERR_KDC_NAME_MISMATCH               76
-
-    We utilize the following typed data for errors:
-
-        TD-PKINIT-CMS-CERTIFICATES             101
-        TD-KRB-PRINCIPAL                       102
-        TD-KRB-REALM                           103
-        TD-TRUSTED-CERTIFIERS                  104
-        TD-CERTIFICATE-INDEX                   105
-
-    We utilize the following encryption types (which map directly to
-    OIDs):
-
-        dsaWithSHA1-CmsOID                       9
-        md5WithRSAEncryption-CmsOID             10
-        sha1WithRSAEncryption-CmsOID            11
-        rc2CBC-EnvOID                           12
-        rsaEncryption-EnvOID (PKCS#1 v1.5)      13
-        rsaES-OAEP-ENV-OID   (PKCS#1 v2.0)      14
-        des-ede3-cbc-Env-OID                    15
-
-    These mappings are provided so that a client may send the
-    appropriate enctypes in the AS-REQ message in order to indicate
-    support for the corresponding OIDs (for performing PKINIT).
-
-    In many cases, PKINIT requires the encoding of the X.500 name of a
-    certificate authority as a Realm.  When such a name appears as
-    a realm it will be represented using the "Other" form of the realm
-    name as specified in the naming constraints section of RFC 1510bis.
-    For a realm derived from an X.500 name, NAMETYPE will have the value
-    X500-RFC2253.  The full realm name will appear as follows:
-
-        <nametype> + ":" + <string>
-
-    where nametype is "X500-RFC2253" and string is the result of doing
-    an RFC2253 encoding of the distinguished name, i.e.
-
-        "X500-RFC2253:" + RFC2253Encode(DistinguishedName)
-
-    where DistinguishedName is an X.500 name, and RFC2253Encode is a
-    function returing a readable UTF encoding of an X.500 name, as
-    defined by RFC 2253 [11] (part of LDAPv3 [15]).
-
-    To ensure that this encoding is unique, we add the following rule
-    to those specified by RFC 2253:
-
-        The order in which the attributes appear in the RFC 2253
-        encoding MUST be the reverse of the order in the ASN.1
-        encoding of the X.500 name that appears in the public key
-        certificate. The order of the relative distinguished names
-        (RDNs), as well as the order of the AttributeTypeAndValues
-        within each RDN, will be reversed. (This is despite the fact
-        that an RDN is defined as a SET of AttributeTypeAndValues, where
-        an order is normally not important.)
-
-    Similarly, in cases where the KDC does not provide a specific
-    policy-based mapping from the X.500 name or X.509 Version 3
-    SubjectAltName extension in the user's certificate to a Kerberos
-    principal name, PKINIT requires the direct encoding of the X.500
-    name as a PrincipalName.  In this case, the name-type of the
-    principal name MUST be set to KRB_NT-X500-PRINCIPAL.  This new
-    name type is defined in RFC 1510bis as:
-
-        KRB_NT_X500_PRINCIPAL    6
-
-    For this type, the name-string MUST be set as follows:
-
-        RFC2253Encode(DistinguishedName)
-
-    as described above.  When this name type is used, the principal's
-    realm MUST be set to the certificate authority's distinguished
-    name using the X500-RFC2253 realm name format described earlier in
-    this section.
-
-    RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows:
-
-        PrincipalName ::=   SEQUENCE {
-                        name-type[0]     INTEGER,
-                        name-string[1]   SEQUENCE OF GeneralString
-        }
-
-    The following rules relate to the the matching of PrincipalNames
-    with regard to the PKI name constraints for CAs as laid out in RFC
-    2459 [12].  In order to be regarded as a match (for permitted and
-    excluded name trees), the following MUST be satisfied.
-
-        1.  If the constraint is given as a user plus realm name, or
-            as a client principal name plus realm name (as specified in
-            RFC 1510bis), the realm name MUST be valid (see 2.a-d below)
-            and the match MUST be exact, byte for byte.
-
-        2.  If the constraint is given only as a realm name, matching
-            depends on the type of the realm:
-
-            a.  If the realm contains a colon (':') before any equal
-                sign ('='), it is treated as a realm of type Other,
-                and MUST match exactly, byte for byte.
-
-            b.  Otherwise, if the realm name conforms to rules regarding
-                the format of DNS names, it is considered a realm name of
-                type Domain.  The constraint may be given as a realm
-                name 'FOO.BAR', which matches any PrincipalName within
-                the realm 'FOO.BAR' but not those in subrealms such as
-                'CAR.FOO.BAR'.  A constraint of the form '.FOO.BAR'
-                matches PrincipalNames in subrealms of the form
-                'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
-
-            c.  Otherwise, the realm name is invalid and does not match
-                under any conditions.
-
-3.1.1.  Encryption and Key Formats
-
-    In the exposition below, we use the terms public key and private
-    key generically.  It should be understood that the term "public
-    key" may be used to refer to either a public encryption key or a
-    signature verification key, and that the term "private key" may be
-    used to refer to either a private decryption key or a signature
-    generation key.  The fact that these are logically distinct does
-    not preclude the assignment of bitwise identical keys for RSA
-    keys.
-
-    In the case of Diffie-Hellman, the key is produced from the agreed
-    bit string as follows:
-
-        * Truncate the bit string to the appropriate length.
-        * Rectify parity in each byte (if necessary) to obtain the key.
-
-    For instance, in the case of a DES key, we take the first eight
-    bytes of the bit stream, and then adjust the least significant bit
-    of each byte to ensure that each byte has odd parity.  Appropriate
-    key constraints for each valid cryptosystem are given in RFC
-    1510bis.
-
-3.1.2. Algorithm Identifiers
-
-    PKINIT does not define, but does permit, the algorithm identifiers
-    listed below.
-
-3.1.2.1. Signature Algorithm Identifiers
-
-    The following signature algorithm identifiers specified in [8] and
-    in [12] are used with PKINIT:
-
-    id-dsa-with-sha1       (DSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    sha-1WithRSAEncryption (RSA with SHA1)
-
-3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
-
-    The following algorithm identifier shall be used within the
-    SubjectPublicKeyInfo data structure: dhpublicnumber
-
-    This identifier and the associated algorithm parameters are
-    specified in RFC 2459 [12].
-
-3.1.2.3. Algorithm Identifiers for RSA Encryption
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure, for encrypting the temporary key with a public key:
-
-        rsaEncryption (RSA encryption, PKCS#1 v1.5)
-        id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
-
-    Both of the above RSA encryption schemes are specified in [13].
-    Currently, only PKCS#1 v1.5 is specified by CMS [8], although the
-    CMS specification says that it will likely include PKCS#1 v2.0 in
-    the future.  (PKCS#1 v2.0 addresses adaptive chosen ciphertext
-    vulnerability discovered in PKCS#1 v1.5.)
-
-3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure in the PKINIT Reply, for encrypting the reply key with the
-    temporary key:
-        des-ede3-cbc (3-key 3-DES, CBC mode)
-        rc2-cbc      (RC2, CBC mode)
-
-    The full definition of the above algorithm identifiers and their
-    corresponding parameters (an IV for block chaining) is provided in
-    the CMS specification [8].
-
-3.2.  Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with PKINIT.
-
-3.2.1.  Client Request
-
-    Public keys may be signed by some certification authority (CA), or
-    they may be maintained by the KDC in which case the KDC is the
-    trusted authority.  Note that the latter mode does not require the
-    use of certificates.
-
-    The initial authentication request is sent as per RFC 1510bis, except
-    that a preauthentication field containing data signed by the user's
-    private key accompanies the request:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                -- PA TYPE 14
-        signedAuthPack          [0] SignedData
-                                    -- Defined in CMS [8];
-                                    -- AuthPack (below) defines the
-                                    -- data that is signed.
-        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
-                                    -- This is a list of CAs that the
-                                    -- client trusts and that certify
-                                    -- KDCs.
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
-                                    -- As defined in CMS [8];
-                                    -- specifies a particular KDC
-                                    -- certificate if the client
-                                    -- already has it.
-        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
-                                    -- For example, this may be the
-                                    -- client's Diffie-Hellman
-                                    -- certificate, or it may be the
-                                    -- client's RSA encryption
-                                    -- certificate.
-    }
-
-    TrustedCas ::= CHOICE {
-        principalName         [0] KerberosName,
-                                  -- as defined below
-        caName                [1] Name
-                                  -- fully qualified X.500 name
-                                  -- as defined by X.509
-        issuerAndSerial       [2] IssuerAndSerialNumber
-                                  -- Since a CA may have a number of
-                                  -- certificates, only one of which
-                                  -- a client trusts
-    }
-
-    Usage of SignedData:
-
-        The SignedData data type is specified in the Cryptographic
-        Message Syntax, a product of the S/MIME working group of the
-        IETF.  The following describes how to fill in the fields of
-        this data:
-
-        1.  The encapContentInfo field MUST contain the PKAuthenticator
-            and, optionally, the client's Diffie Hellman public value.
-
-            a.  The eContentType field MUST contain the OID value for
-                pkauthdata: iso (1) org (3) dod (6) internet (1)
-                security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)
-
-            b.  The eContent field is data of the type AuthPack (below).
-
-        2.  The signerInfos field contains the signature of AuthPack.
-
-        3.  The Certificates field, when non-empty, contains the client's
-            certificate chain.  If present, the KDC uses the public key
-            from the client's certificate to verify the signature in the
-            request.  Note that the client may pass different certificate
-            chains that are used for signing or for encrypting.  Thus,
-            the KDC may utilize a different client certificate for
-            signature verification than the one it uses to encrypt the
-            reply to the client.  For example, the client may place a
-            Diffie-Hellman certificate in this field in order to convey
-            its static Diffie Hellman certificate to the KDC to enable
-            static-ephemeral Diffie-Hellman mode for the reply; in this
-            case, the client does NOT place its public value in the
-            AuthPack (defined below).  As another example, the client may
-            place an RSA encryption certificate in this field.  However,
-            there MUST always be (at least) a signature certificate.
-
-        4.  When a DH key is being used, the public exponent is provided
-            in the subjectPublicKey field of the SubjectPublicKeyInfo and
-            the DH parameters are supplied as a DHParameter in the
-            AlgorithmIdentitfier parameters.  The DH paramters SHOULD be
-            chosen from the First and Second defined Oakley Groups [The
-            Internet Key Exchange (IKE) RFC-2409], if a server will not
-            accept either of these groups, it will respond with a krb-error
-            of KDC_ERR_KEY_TOO_WEAK and the e_data will contain a
-            DHParameter with appropriate parameters for the client to use.
-
-        5.  The KDC may wish to use cached Diffie-Hellman parameters
-            (see Section 3.2.2, KDC Response).  To indicate acceptance
-            of cached parameters, the client sends zero in the nonce
-            field of the PKAuthenticator.  Zero is not a valid value
-            for this field under any other circumstances.  If cached
-            parameters are used, the client and the KDC MUST perform
-            key derivation (for the appropriate cryptosystem) on the
-            resulting encryption key, as specified in RFC 1510bis.  (With
-            a zero nonce, message binding is performed using the nonce
-            in the main request, which must be encrypted using the
-            encapsulated reply key.)
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- if client is using Diffie-Hellman
-                                    -- (ephemeral-ephemeral only)
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER,
-                                    -- for replay prevention as in RFC 1510bis
-        ctime                   [1] KerberosTime,
-                                    -- for replay prevention as in RFC 1510bis
-        nonce                   [2] INTEGER,
-                                    -- zero only if client will accept
-                                    -- cached DH parameters from KDC;
-                                    -- must be non-zero otherwise
-        pachecksum              [3] Checksum
-                                    -- Checksum over KDC-REQ-BODY
-                                    -- Defined by Kerberos spec
-    }
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm                   AlgorithmIdentifier,
-                                    -- dhKeyAgreement
-        subjectPublicKey            BIT STRING
-                                    -- for DH, equals
-                                    -- public exponent (INTEGER encoded
-                                    -- as payload of BIT STRING)
-    }   -- as specified by the X.509 recommendation [7]
-
-    AlgorithmIdentifier ::= SEQUENCE {
-        algorithm                   OBJECT IDENTIFIER,
-                                    -- for dhKeyAgreement, this is
-                                    -- { iso (1) member-body (2) US (840)
-                                    -- rsadsi (113459) pkcs (1) 3 1 }
-                                    -- from PKCS #3 [17]
-        parameters                  ANY DEFINED by algorithm OPTIONAL
-                                    -- for dhKeyAgreement, this is
-                                    -- DHParameter
-    }   -- as specified by the X.509 recommendation [7]
-
-    DHParameter ::= SEQUENCE {
-        prime                       INTEGER,
-                                    -- p
-        base                        INTEGER,
-                                    -- g
-        privateValueLength          INTEGER OPTIONAL
-                                    -- l
-    }   -- as defined in PKCS #3 [17]
-
-    If the client passes an issuer and serial number in the request,
-    the KDC is requested to use the referred-to certificate.  If none
-    exists, then the KDC returns an error of type
-    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
-    other hand, the client does not pass any trustedCertifiers,
-    believing that it has the KDC's certificate, but the KDC has more
-    than one certificate.  The KDC should include information in the
-    KRB-ERROR message that indicates the KDC certificate(s) that a
-    client may utilize.  This data is specified in the e-data, which
-    is defined in RFC 1510bis revisions as a SEQUENCE of TypedData:
-
-    TypedData ::=  SEQUENCE {
-                    data-type      [0] INTEGER,
-                    data-value     [1] OCTET STRING,
-    } -- per Kerberos RFC 1510bis
-
-    where:
-    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
-    data-value = CertificateSet // as specified by CMS [8]
-
-    The PKAuthenticator carries information to foil replay attacks, to
-    bind the pre-authentication data to the KDC-REQ-BODY, and to bind the
-    request and response.  The PKAuthenticator is signed with the client's
-    signature key.
-
-3.2.2.  KDC Response
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.
-
-    If the client's certificate chain contains no certificate signed by
-    a CA trusted by the KDC, then the KDC sends back an error message
-    of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data
-    is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
-    whose data-value is an OCTET STRING which is the DER encoding of
-
-        TrustedCertifiers ::= SEQUENCE OF PrincipalName
-                              -- X.500 name encoded as a principal name
-                              -- see Section 3.1
-
-    If while verifying a certificate chain the KDC determines that the
-    signature on one of the certificates in the CertificateSet from
-    the signedAuthPack fails verification, then the KDC returns an
-    error of type KDC_ERR_INVALID_CERTIFICATE.  The accompanying
-    e-data is a SEQUENCE of one TypedData (with type
-    TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
-    which is the DER encoding of the index into the CertificateSet
-    ordered as sent by the client.
-
-        CertificateIndex  ::= INTEGER
-                              -- 0 = 1st certificate,
-                              --     (in order of encoding)
-                              -- 1 = 2nd certificate, etc
-
-    The KDC may also check whether any of the certificates in the
-    client's chain has been revoked.  If one of the certificates has
-    been revoked, then the KDC returns an error of type
-    KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
-    the certificate's revocation status is unknown or not
-    available, then if required by policy, the KDC returns the
-    appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
-    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE.  In any of these three
-    cases, the affected certificate is identified by the accompanying
-    e-data, which contains a CertificateIndex as described for
-    KDC_ERR_INVALID_CERTIFICATE.
-
-    If the certificate chain can be verified, but the name of the
-    client in the certificate does not match the client's name in the
-    request, then the KDC returns an error of type
-    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
-    field in this case.
-
-    Even if all succeeds, the KDC may--for policy reasons--decide not
-    to trust the client.  In this case, the KDC returns an error message
-    of type KDC_ERR_CLIENT_NOT_TRUSTED.  One specific case of this is
-    the presence or absence of an Enhanced Key Usage (EKU) OID within
-    the certificate extensions.  The rules regarding acceptability of
-    an EKU sequence (or the absence of any sequence) are a matter of
-    local policy.  For the benefit of implementers, we define a PKINIT
-    EKU OID as the following: iso (1) org (3) dod (6) internet (1)
-    security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on AuthPack.  If that fails, the KDC returns an error
-    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
-    timestamp (ctime and cusec) in the PKAuthenticator to assure that
-    the request is not a replay.  The KDC also verifies that its name
-    is specified in the PKAuthenticator.
-
-    If the clientPublicValue field is filled in, indicating that the
-    client wishes to use Diffie-Hellman key agreement, then the KDC
-    checks to see that the parameters satisfy its policy.  If they do
-    not (e.g., the prime size is insufficient for the expected
-    encryption type), then the KDC sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK, with an e-data containing a structure of
-    type DHParameter with appropriate DH parameters for the client to
-    retry the request.  Otherwise, it generates its own public and
-    private values for the response.
-
-    The KDC also checks that the timestamp in the PKAuthenticator is
-    within the allowable window and that the principal name and realm
-    are correct.  If the local (server) time and the client time in the
-    authenticator differ by more than the allowable clock skew, then the
-    KDC returns an error message of type KRB_AP_ERR_SKEW as defined in
-    RFC 1510bis.
-
-    Assuming no errors, the KDC replies as per RFC 1510bis, except as
-    follows.  The user's name in the ticket is determined by the
-    following decision algorithm:
-
-        1.  If the KDC has a mapping from the name in the certificate
-            to a Kerberos name, then use that name.
-            Else
-        2.  If the certificate contains the SubjectAltName extention
-            and the local KDC policy defines a mapping from the
-            SubjectAltName to a Kerberos name, then use that name.
-            Else
-        3.  Use the name as represented in the certificate, mapping
-            as necessary (e.g., as per RFC 2253 for X.500 names).  In
-            this case the realm in the ticket MUST be the name of the
-            certifier that issued the user's certificate.
-
-    Note that a principal name may be carried in the subjectAltName
-    field of a certificate. This name may be mapped to a principal
-    record in a security database based on local policy, for example
-    the subjectAltName may be kerberos/principal@realm format.  In
-    this case the realm name is not that of the CA but that of the
-    local realm doing the mapping (or some realm name chosen by that
-    realm).
-
-    If a non-KDC X.509 certificate contains the principal name within
-    the subjectAltName version 3 extension, that name may utilize
-    KerberosName as defined below, or, in the case of an S/MIME
-    certificate [14], may utilize the email address.  If the KDC
-    is presented with an S/MIME certificate, then the email address
-    within subjectAltName will be interpreted as a principal and realm
-    separated by the "@" sign, or as a name that needs to be mapped
-    according to local policy.  If the resulting name does not correspond
-    to a registered principal name, then the principal name is formed as
-    defined in section 3.1.
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.  If the KDC has no
-    certificate signed by any of the trustedCertifiers, then it returns
-    an error of type KDC_ERR_KDC_NOT_TRUSTED.
-
-    KDCs should try to (in order of preference):
-    1. Use the KDC certificate identified by the serialNumber included
-       in the client's request.
-    2. Use a certificate issued to the KDC by one of the client's
-       trustedCertifier(s);
-    If the KDC is unable to comply with any of these options, then the
-    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
-    client.
-
-    The KDC encrypts the reply not with the user's long-term key, but
-    with the Diffie Hellman derived key or a random key generated
-    for this particular response which is carried in the padata field of
-    the TGS-REP message.
-
-    PA-PK-AS-REP ::= CHOICE {
-                            -- PA TYPE 15
-        dhSignedData       [0] SignedData,
-                            -- Defined in CMS and used only with
-                            -- Diffie-Hellman key exchange (if the
-                            -- client public value was present in the
-                            -- request).
-                            -- This choice MUST be supported
-                            -- by compliant implementations.
-        encKeyPack         [1] EnvelopedData,
-                            -- Defined in CMS
-                            -- The temporary key is encrypted
-                            -- using the client public key
-                            -- key
-                            -- SignedReplyKeyPack, encrypted
-                            -- with the temporary key, is also
-                            -- included.
-    }
-
-    Usage of SignedData:
-
-        When the Diffie-Hellman option is used, dhSignedData in
-        PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
-        of the KDC.  The reply key used to encrypt part of the KDC reply
-        message is derived from the Diffie-Hellman exchange:
-
-        1.  Both the KDC and the client calculate a secret value
-            (g^ab mod p), where a is the client's private exponent and
-            b is the KDC's private exponent.
-
-        2.  Both the KDC and the client take the first N bits of this
-            secret value and convert it into a reply key.  N depends on
-            the reply key type.
-
-            a.  For example, if the reply key is DES, N=64 bits, where
-                some of the bits are replaced with parity bits, according
-                to FIPS PUB 74.
-
-            b.  As another example, if the reply key is (3-key) 3-DES,
-                N=192 bits, where some of the bits are replaced with
-                parity bits, according to FIPS PUB 74.
-
-        3.  The encapContentInfo field MUST contain the KdcDHKeyInfo as
-            defined below.
-
-            a.  The eContentType field MUST contain the OID value for
-                pkdhkeydata: iso (1) org (3) dod (6) internet (1)
-                security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)
-
-            b.  The eContent field is data of the type KdcDHKeyInfo
-                (below).
-
-        4.  The certificates field MUST contain the certificates
-            necessary for the client to establish trust in the KDC's
-            certificate based on the list of trusted certifiers sent by
-            the client in the PA-PK-AS-REQ.  This field may be empty if
-            the client did not send to the KDC a list of trusted
-            certifiers (the trustedCertifiers field was empty, meaning
-            that the client already possesses the KDC's certificate).
-
-        5.  The signerInfos field is a SET that MUST contain at least
-            one member, since it contains the actual signature.
-
-        6.  If the client indicated acceptance of cached Diffie-Hellman
-            parameters from the KDC, and the KDC supports such an option
-            (for performance reasons), the KDC should return a zero in
-            the nonce field and include the expiration time of the
-            parameters in the dhKeyExpiration field.  If this time is
-            exceeded, the client SHOULD NOT use the reply.  If the time
-            is absent, the client SHOULD NOT use the reply and MAY
-            resubmit a request with a non-zero nonce (thus indicating
-            non-acceptance of cached Diffie-Hellman parameters).  As
-            indicated above in Section 3.2.1, Client Request, when the
-            KDC uses cached parameters, the client and the KDC MUST
-            perform key derivation (for the appropriate cryptosystem)
-            on the resulting encryption key, as specified in RFC 1510bis.
-
-    KdcDHKeyInfo ::= SEQUENCE {
-                              -- used only when utilizing Diffie-Hellman
-      subjectPublicKey      [0] BIT STRING,
-                                -- Equals public exponent (g^a mod p)
-                                -- INTEGER encoded as payload of
-                                -- BIT STRING
-      nonce                 [1] INTEGER,
-                                -- Binds response to the request
-                                -- Exception: Set to zero when KDC
-                                -- is using a cached DH value
-      dhKeyExpiration       [2] KerberosTime OPTIONAL
-                                -- Expiration time for KDC's cached
-                                -- DH value
-    }
-
-    Usage of EnvelopedData:
-
-        The EnvelopedData data type is specified in the Cryptographic
-        Message Syntax, a product of the S/MIME working group of the
-        IETF.  It contains a temporary key encrypted with the PKINIT
-        client's public key.  It also contains a signed and encrypted
-        reply key.
-
-        1.  The originatorInfo field is not required, since that
-            information may be presented in the signedData structure
-            that is encrypted within the encryptedContentInfo field.
-
-        2.  The optional unprotectedAttrs field is not required for
-            PKINIT.
-
-        3.  The recipientInfos field is a SET which MUST contain exactly
-            one member of the KeyTransRecipientInfo type for encryption
-            with a public key.
-
-            a.  The encryptedKey field (in KeyTransRecipientInfo)
-                contains the temporary key which is encrypted with the
-                PKINIT client's public key.
-
-        4.  The encryptedContentInfo field contains the signed and
-            encrypted reply key.
-
-            a.  The contentType field MUST contain the OID value for
-                id-signedData: iso (1) member-body (2) us (840)
-                rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
-
-            b.  The encryptedContent field is encrypted data of the CMS
-                type signedData as specified below.
-
-                i.  The encapContentInfo field MUST contains the
-                    ReplyKeyPack.
-
-                    * The eContentType field MUST contain the OID value
-                      for pkrkeydata: iso (1) org (3) dod (6) internet (1)
-                      security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3)
-
-                    * The eContent field is data of the type ReplyKeyPack
-                      (below).
-
-                ii.  The certificates field MUST contain the certificates
-                     necessary for the client to establish trust in the
-                     KDC's certificate based on the list of trusted
-                     certifiers sent by the client in the PA-PK-AS-REQ.
-                     This field may be empty if the client did not send
-                     to the KDC a list of trusted certifiers (the
-                     trustedCertifiers field was empty, meaning that the
-                     client already possesses the KDC's certificate).
-
-                iii.  The signerInfos field is a SET that MUST contain at
-                      least one member, since it contains the actual
-                      signature.
-
-    ReplyKeyPack ::= SEQUENCE {
-                              -- not used for Diffie-Hellman
-        replyKey             [0] EncryptionKey,
-                                 -- from RFC 1510bis
-                                 -- used to encrypt main reply
-                                 -- ENCTYPE is at least as strong as
-                                 -- ENCTYPE of session key
-        nonce                [1] INTEGER,
-                                 -- binds response to the request
-                                 -- must be same as the nonce
-                                 -- passed in the PKAuthenticator
-    }
-
-
-3.2.2.1. Use of transited Field
-
-    Since each certifier in the certification path of a user's
-    certificate is equivalent to a separate Kerberos realm, the name
-    of each certifier in the certificate chain MUST be added to the
-    transited field of the ticket.  The format of these realm names is
-    defined in Section 3.1 of this document.  If applicable, the
-    transit-policy-checked flag should be set in the issued ticket.
-
-
-3.2.2.2. Kerberos Names in Certificates
-
-    The KDC's certificate(s) MUST bind the public key(s) of the KDC to
-    a name derivable from the name of the realm for that KDC.  X.509
-    certificates MUST contain the principal name of the KDC (defined in
-    RFC 1510bis) as the SubjectAltName version 3 extension.  Below is
-    the definition of this version 3 extension, as specified by the
-    X.509 standard:
-
-        subjectAltName EXTENSION ::= {
-            SYNTAX GeneralNames
-            IDENTIFIED BY id-ce-subjectAltName
-        }
-
-        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
-
-        GeneralName ::= CHOICE {
-            otherName       [0] OtherName,
-            ...
-        }
-
-        OtherName ::= SEQUENCE {
-            type-id         OBJECT IDENTIFIER,
-            value           [0] EXPLICIT ANY DEFINED BY type-id
-        }
-
-    For the purpose of specifying a Kerberos principal name, the value
-    in OtherName MUST be a KerberosName as defined in RFC 1510bis:
-
-        KerberosName ::= SEQUENCE {
-            realm           [0] Realm,
-            principalName   [1] PrincipalName
-        }
-
-    This specific syntax is identified within subjectAltName by setting
-    the type-id in OtherName to krb5PrincipalName, where (from the
-    Kerberos specification) we have
-
-        krb5 OBJECT IDENTIFIER ::= { iso (1)
-                                     org (3)
-                                     dod (6)
-                                     internet (1)
-                                     security (5)
-                                     kerberosv5 (2) }
-
-        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
-
-    (This specification may also be used to specify a Kerberos name
-    within the user's certificate.)  The KDC's certificate may be signed
-    directly by a CA, or there may be intermediaries if the server resides
-    within a large organization, or it may be unsigned if the client
-    indicates possession (and trust) of the KDC's certificate.
-
-    Note that the KDC's principal name has the instance equal to the
-    realm, and those fields should be appropriately set in the realm
-    and principalName fields of the KerberosName.  This is the case
-    even when obtaining a cross-realm ticket using PKINIT.
-
-
-3.2.3. Client Extraction of Reply
-
-    The client then extracts the random key used to encrypt the main
-    reply.  This random key (in encPaReply) is encrypted with either the
-    client's public key or with a key derived from the DH values
-    exchanged between the client and the KDC.  The client uses this
-    random key to decrypt the main reply, and subsequently proceeds as
-    described in RFC 1510bis.
-
-3.2.4. Required Algorithms
-
-    Not all of the algorithms in the PKINIT protocol specification have
-    to be implemented in order to comply with the proposed standard.
-    Below is a list of the required algorithms:
-
-    * Diffie-Hellman public/private key pairs
-        * utilizing Diffie-Hellman ephemeral-ephemeral mode
-    * SHA1 digest and DSA for signatures
-    * SHA1 digest also for the Checksum in the PKAuthenticator
-    * 3-key triple DES keys derived from the Diffie-Hellman Exchange
-    * 3-key triple DES Temporary and Reply keys
-
-4.  Logistics and Policy
-
-    This section describes a way to define the policy on the use of
-    PKINIT for each principal and request.
-
-    The KDC is not required to contain a database record for users
-    who use public key authentication.  However, if these users are
-    registered with the KDC, it is recommended that the database record
-    for these users be modified to an additional flag in the attributes
-    field to indicate that the user should authenticate using PKINIT.
-    If this flag is set and a request message does not contain the
-    PKINIT preauthentication field, then the KDC sends back as error of
-    type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
-    field of type PA-PK-AS-REQ must be included in the request.
-
-5.  Security Considerations
-
-    PKINIT raises a few security considerations, which we will address
-    in this section.
-
-    First of all, PKINIT introduces a new trust model, where KDCs do not
-    (necessarily) certify the identity of those for whom they issue
-    tickets.  PKINIT does allow KDCs to act as their own CAs, in the
-    limited capacity of self-signing their certificates, but one of the
-    additional benefits is to align Kerberos authentication with a global
-    public key infrastructure.  Anyone using PKINIT in this way must be
-    aware of how the certification infrastructure they are linking to
-    works.
-
-    Also, PKINIT introduces the possibility of interactions between
-    different cryptosystems, which may be of widely varying strengths.
-    Many systems, for instance, allow the use of 512-bit public keys.
-    Using such keys to wrap data encrypted under strong conventional
-    cryptosystems, such as triple-DES, is inappropriate; it adds a
-    weak link to a strong one at extra cost.  Implementors and
-    administrators should take care to avoid such wasteful and
-    deceptive interactions.
-
-    Care should be taken in how certificates are choosen for the purposes
-    of authentication using PKINIT. Some local policies require that key
-    escrow be applied for certain certificate types. People deploying
-    PKINIT should be aware of the implications of using certificates that
-    have escrowed keys for the purposes of authentication.
-
-    As described in Section 3.2, PKINIT allows for the caching of the
-    Diffie-Hellman parameters on the KDC side, for performance reasons.
-    For similar reasons, the signed data in this case does not vary from
-    message to message, until the cached parameters expire.  Because of
-    the persistence of these parameters, the client and the KDC are to
-    use the appropriate key derivation measures (as described in RFC
-    1510bis) when using cached DH parameters.
-
-    Lastly, PKINIT calls for randomly generated keys for conventional
-    cryptosystems.  Many such systems contain systematically "weak"
-    keys.  PKINIT implementations MUST avoid use of these keys, either
-    by discarding those keys when they are generated, or by fixing them
-    in some way (e.g., by XORing them with a given mask).  These
-    precautions vary from system to system; it is not our intention to
-    give an explicit recipe for them here.
-
-6.  Transport Issues
-
-    Certificate chains can potentially grow quite large and span several
-    UDP packets; this in turn increases the probability that a Kerberos
-    message involving PKINIT extensions will be broken in transit.  In
-    light of the possibility that the Kerberos specification will
-    require KDCs to accept requests using TCP as a transport mechanism,
-    we make the same recommendation with respect to the PKINIT
-    extensions as well.
-
-7.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-    (V5).  Request for Comments 1510.
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.  September
-    1994.
-
-    [3] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-    Using Public Key Cryptography.  Symposium On Network and Distributed
-    System Security, 1997.
-
-    [4] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic
-    Commerce, July 1995.
-
-    [5] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
-    Request for Comments 2246, January 1999.
-
-    [6] B.C. Neuman, Proxy-Based Authorization and Accounting for
-    Distributed Systems.  In Proceedings of the 13th International
-    Conference on Distributed Computing Systems, May 1993.
-
-    [7] ITU-T (formerly CCITT) Information technology - Open Systems
-    Interconnection - The Directory: Authentication Framework
-    Recommendation X.509 ISO/IEC 9594-8
-
-    [8] R. Housley. Cryptographic Message Syntax.
-    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
-    as RFC.
-
-    [9] PKCS #7: Cryptographic Message Syntax Standard,
-    An RSA Laboratories Technical Note Version 1.5
-    Revised November 1, 1993
-
-    [10] R. Rivest, MIT Laboratory for Computer Science and RSA Data
-    Security, Inc. A Description of the RC2(r) Encryption Algorithm
-    March 1998.
-    Request for Comments 2268.
-
-    [11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
-    Protocol (v3): UTF-8 String Representation of Distinguished Names.
-    Request for Comments 2253.
-
-    [12] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
-    Key Infrastructure, Certificate and CRL Profile, January 1999.
-    Request for Comments 2459.
-
-    [13] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-    Specifications, October 1998.  Request for Comments 2437.
-
-    [14] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
-    Version 2 Certificate Handling, March 1998.  Request for
-    Comments 2312.
-
-    [15] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
-    Protocol (v3), December 1997.  Request for Comments 2251.
-
-    [16] ITU-T (formerly CCITT) Information Processing Systems - Open
-    Systems Interconnection - Specification of Abstract Syntax Notation
-    One (ASN.1) Rec. X.680 ISO/IEC 8824-1
-
-    [17] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
-    Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
-
-8.  Acknowledgements
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-9.  Expiration Date
-
-    This draft expires January 15, 2002.
-
-10. Authors
-
-    Brian Tung
-    Clifford Neuman
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {brian, bcn}@isi.edu
-
-    Matthew Hur
-    Cisco Systems
-    500 108th Ave. NE, Suite 500
-    Bellevue, WA 98004
-    Phone: (408) 525-0034
-    E-Mail: mhur@cisco.com
-
-    Ari Medvinsky
-    Keen.com, Inc.
-    150 Independence Drive
-    Menlo Park CA 94025
-    Phone: +1 650 289 3134
-    E-mail: ari@keen.com
-
-    Sasha Medvinsky
-    Motorola
-    6450 Sequence Drive
-    San Diego, CA 92121
-    +1 858 404 2367
-    E-mail: smedvinsky@gi.com
-
-    John Wray
-    Iris Associates, Inc.
-    5 Technology Park Dr.
-    Westford, MA 01886
-    E-mail: John_Wray@iris.com
-
-    Jonathan Trostle
-    Cisco Systems
-    170 W. Tasman Dr.
-    San Jose, CA 95134
-    E-mail: jtrostle@cisco.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-15.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-15.txt
deleted file mode 100644
index 7d5a223eb..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-15.txt
+++ /dev/null
@@ -1,1116 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-15.txt                   Clifford Neuman
-Updates: RFC 1510bis                                             USC/ISI
-expires May 25, 2002                                         Matthew Hur
-                                                                   Cisco
-                                                           Ari Medvinsky
-                                                          Keen.com, Inc.
-                                                         Sasha Medvinsky
-                                                                Motorola
-                                                               John Wray
-                                                   Iris Associates, Inc.
-                                                        Jonathan Trostle
-                                                                   Cisco
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-0.  Status Of This Memo
-
-    This document is an Internet-Draft and is in full conformance with
-    all provisions of Section 10 of RFC 2026.  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."
-
-    The list of current Internet-Drafts can be accessed at
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-    The list of Internet-Draft Shadow Directories can be accessed at
-    http://www.ietf.org/shadow.html.
-
-    To learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ftp.ietf.org (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-15.txt, and expires May 25, 2002.
-    Please send comments to the authors.
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510bis [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to associate a key pair with each realm, which can
-    then be used to facilitate cross-realm authentication; this is the
-    topic of another draft proposal.  Another way is to allow users with
-    public key certificates to use them in initial authentication.  This
-    is the concern of the current document.
-
-    PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
-    combination with DSA keys as the primary, required mechanism.  Note
-    that PKINIT supports the use of separate signature and encryption
-    keys.
-
-    PKINIT enables access to Kerberos-secured services based on initial
-    authentication utilizing public key cryptography.  PKINIT utilizes
-    standard public key signature and encryption data formats within the
-    standard Kerberos messages.  The basic mechanism is as follows:  The
-    user sends an AS-REQ message to the KDC as before, except that if that
-    user is to use public key cryptography in the initial authentication
-    step, his certificate and a signature accompany the initial request
-    in the preauthentication fields.  Upon receipt of this request, the
-    KDC verifies the certificate and issues a ticket granting ticket
-    (TGT) as before, except that the encPart from the AS-REP message
-    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
-    derived key or the user's public key.  This message is authenticated
-    utilizing the public key signature of the KDC.
-
-    Note that PKINIT does not require the use of certificates.  A KDC
-    may store the public key of a principal as part of that principal's
-    record.  In this scenario, the KDC is the trusted party that vouches
-    for the principal (as in a standard, non-cross realm, Kerberos
-    environment).  Thus, for any principal, the KDC may maintain a
-    symmetric key, a public key, or both.
-
-    The PKINIT specification may also be used as a building block for
-    other specifications.  PKINIT may be utilized to establish
-    inter-realm keys for the purposes of issuing cross-realm service
-    tickets.  It may also be used to issue anonymous Kerberos tickets
-    using the Diffie-Hellman option.  Efforts are under way to draft
-    specifications for these two application protocols.
-
-    Additionally, the PKINIT specification may be used for direct peer
-    to peer authentication without contacting a central KDC. This
-    application of PKINIT is based on concepts introduced in [6, 7].
-    For direct client-to-server authentication, the client uses PKINIT
-    to authenticate to the end server (instead of a central KDC), which
-    then issues a ticket for itself.  This approach has an advantage
-    over TLS [5] in that the server does not need to save state (cache
-    session keys).  Furthermore, an additional benefit is that Kerberos
-    tickets can facilitate delegation (see [6]).
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510bis for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following change to RFC 1510bis is proposed:
-
-        * Users may authenticate using either a public key pair or a
-          conventional (symmetric) key.  If public key cryptography is
-          used, public key data is transported in preauthentication
-          data fields to help establish identity.  The user presents
-          a public key certificate and obtains an ordinary TGT that may
-          be used for subsequent authentication, with such
-          authentication using only conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 describes the extensions for the initial authentication
-    method.
-
-3.1.  Definitions
-
-    The extensions involve new preauthentication fields; we introduce
-    the following preauthentication types:
-
-        PA-PK-AS-REQ                            14
-        PA-PK-AS-REP                            15
-
-    The extensions also involve new error types; we introduce the
-    following types:
-
-        KDC_ERR_CLIENT_NOT_TRUSTED              62
-        KDC_ERR_KDC_NOT_TRUSTED                 63
-        KDC_ERR_INVALID_SIG                     64
-        KDC_ERR_KEY_TOO_WEAK                    65
-        KDC_ERR_CERTIFICATE_MISMATCH            66
-        KDC_ERR_CANT_VERIFY_CERTIFICATE         70
-        KDC_ERR_INVALID_CERTIFICATE             71
-        KDC_ERR_REVOKED_CERTIFICATE             72
-        KDC_ERR_REVOCATION_STATUS_UNKNOWN       73
-        KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74
-        KDC_ERR_CLIENT_NAME_MISMATCH            75
-        KDC_ERR_KDC_NAME_MISMATCH               76
-
-    We utilize the following typed data for errors:
-
-        TD-PKINIT-CMS-CERTIFICATES             101
-        TD-KRB-PRINCIPAL                       102
-        TD-KRB-REALM                           103
-        TD-TRUSTED-CERTIFIERS                  104
-        TD-CERTIFICATE-INDEX                   105
-
-    We utilize the following encryption types (which map directly to
-    OIDs):
-
-        dsaWithSHA1-CmsOID                       9
-        md5WithRSAEncryption-CmsOID             10
-        sha1WithRSAEncryption-CmsOID            11
-        rc2CBC-EnvOID                           12
-        rsaEncryption-EnvOID (PKCS#1 v1.5)      13
-        rsaES-OAEP-ENV-OID   (PKCS#1 v2.0)      14
-        des-ede3-cbc-Env-OID                    15
-
-    These mappings are provided so that a client may send the
-    appropriate enctypes in the AS-REQ message in order to indicate
-    support for the corresponding OIDs (for performing PKINIT).  The
-    above encryption types are utilized only within CMS structures
-    within the PKINIT preauthentication fields. Their use within
-    the Kerberos EncryptedData structure is unspecified.
-
-    In many cases, PKINIT requires the encoding of the X.500 name of a
-    certificate authority as a Realm.  When such a name appears as
-    a realm it will be represented using the "Other" form of the realm
-    name as specified in the naming constraints section of RFC 1510bis.
-    For a realm derived from an X.500 name, NAMETYPE will have the value
-    X500-RFC2253.  The full realm name will appear as follows:
-
-        <nametype> + ":" + <string>
-
-    where nametype is "X500-RFC2253" and string is the result of doing
-    an RFC2253 encoding of the distinguished name, i.e.
-
-        "X500-RFC2253:" + RFC2253Encode(DistinguishedName)
-
-    where DistinguishedName is an X.500 name, and RFC2253Encode is a
-    function returing a readable UTF encoding of an X.500 name, as
-    defined by RFC 2253 [11] (part of LDAPv3 [15]).
-
-    Each component of a DistinguishedName is called a
-    RelativeDistinguishedName, where a RelativeDistinguishedName is a
-    SET OF AttributeTypeAndValue.  RFC 2253 does not specify the order
-    in which to encode the elements of the RelativeDistinguishedName and
-    so to ensure that this encoding is unique, we add the following rule
-    to those specified by RFC 2253:
-     
-	When converting a multi-valued RelativeDistinguishedName
-        to a string, the output consists of the string encodings
-        of each AttributeTypeAndValue, in the same order as
-	specified by the DER encoding.    
-
-    Similarly, in cases where the KDC does not provide a specific
-    policy-based mapping from the X.500 name or X.509 Version 3
-    SubjectAltName extension in the user's certificate to a Kerberos
-    principal name, PKINIT requires the direct encoding of the X.500
-    name as a PrincipalName.  In this case, the name-type of the
-    principal name MUST be set to KRB_NT-X500-PRINCIPAL.  This new
-    name type is defined in RFC 1510bis as:
-
-        KRB_NT_X500_PRINCIPAL    6
-
-    For this type, the name-string MUST be set as follows:
-
-        RFC2253Encode(DistinguishedName)
-
-    as described above.  When this name type is used, the principal's
-    realm MUST be set to the certificate authority's distinguished
-    name using the X500-RFC2253 realm name format described earlier in
-    this section.
-
-    Note that the same string may be represented using several different
-    ASN.1 data types.  As the result, the reverse conversion from an
-    RFC2253-encoded principal name back to an X.500 name may not be
-    unique and may result in an X.500 name that is not the same as the
-    original X.500 name found in the client certificate.
-
-    RFC 1510bis describes an alternate encoding of an X.500 name into a
-    realm name.  However, as described in RFC 1510bis, the alternate
-    encoding does not guarantee a unique mapping from a
-    DistinguishedName inside a certificate into a realm name and
-    similarly cannot be used to produce a unique principal name.  PKINIT
-    therefore uses an RFC 2253-based name mapping approach, as specified
-    above.
-
-    RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows:
-
-        PrincipalName ::=   SEQUENCE {
-                        name-type[0]     INTEGER,
-                        name-string[1]   SEQUENCE OF GeneralString
-        }
-
-    The following rules relate to the the matching of PrincipalNames
-    with regard to the PKI name constraints for CAs as laid out in RFC
-    2459 [12].  In order to be regarded as a match (for permitted and
-    excluded name trees), the following MUST be satisfied.
-
-        1.  If the constraint is given as a user plus realm name, or
-            as a client principal name plus realm name (as specified in
-            RFC 1510bis), the realm name MUST be valid (see 2.a-d below)
-            and the match MUST be exact, byte for byte.
-
-        2.  If the constraint is given only as a realm name, matching
-            depends on the type of the realm:
-
-            a.  If the realm contains a colon (':') before any equal
-                sign ('='), it is treated as a realm of type Other,
-                and MUST match exactly, byte for byte.
-
-            b.  Otherwise, if the realm name conforms to rules regarding
-                the format of DNS names, it is considered a realm name of
-                type Domain.  The constraint may be given as a realm
-                name 'FOO.BAR', which matches any PrincipalName within
-                the realm 'FOO.BAR' but not those in subrealms such as
-                'CAR.FOO.BAR'.  A constraint of the form '.FOO.BAR'
-                matches PrincipalNames in subrealms of the form
-                'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
-
-            c.  Otherwise, the realm name is invalid and does not match
-                under any conditions.
-
-3.1.1.  Encryption and Key Formats
-
-    In the exposition below, we use the terms public key and private
-    key generically.  It should be understood that the term "public
-    key" may be used to refer to either a public encryption key or a
-    signature verification key, and that the term "private key" may be
-    used to refer to either a private decryption key or a signature
-    generation key.  The fact that these are logically distinct does
-    not preclude the assignment of bitwise identical keys for RSA
-    keys.
-
-    In the case of Diffie-Hellman, the key is produced from the agreed
-    bit string as follows:
-
-        * Truncate the bit string to the required length.
-        * Apply the specific cryptosystem's random-to-key function.
-
-    Appropriate key constraints for each valid cryptosystem are given
-    in RFC 1510bis.
-
-3.1.2. Algorithm Identifiers
-
-    PKINIT does not define, but does permit, the algorithm identifiers
-    listed below.
-
-3.1.2.1. Signature Algorithm Identifiers
-
-    The following signature algorithm identifiers specified in [8] and
-    in [12] are used with PKINIT:
-
-    id-dsa-with-sha1       (DSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    sha-1WithRSAEncryption (RSA with SHA1)
-
-3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
-
-    The following algorithm identifier shall be used within the
-    SubjectPublicKeyInfo data structure: dhpublicnumber
-
-    This identifier and the associated algorithm parameters are
-    specified in RFC 2459 [12].
-
-3.1.2.3. Algorithm Identifiers for RSA Encryption
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure, for encrypting the temporary key with a public key:
-
-        rsaEncryption (RSA encryption, PKCS#1 v1.5)
-        id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
-
-    Both of the above RSA encryption schemes are specified in [13].
-    Currently, only PKCS#1 v1.5 is specified by CMS [8], although the
-    CMS specification says that it will likely include PKCS#1 v2.0 in
-    the future.  (PKCS#1 v2.0 addresses adaptive chosen ciphertext
-    vulnerability discovered in PKCS#1 v1.5.)
-
-3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure in the PKINIT Reply, for encrypting the reply key with the
-    temporary key:
-        des-ede3-cbc (3-key 3-DES, CBC mode)
-        rc2-cbc      (RC2, CBC mode)
-
-    The full definition of the above algorithm identifiers and their
-    corresponding parameters (an IV for block chaining) is provided in
-    the CMS specification [8].
-
-3.2.  Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with PKINIT.
-
-3.2.1.  Client Request
-
-    Public keys may be signed by some certification authority (CA), or
-    they may be maintained by the KDC in which case the KDC is the
-    trusted authority.  Note that the latter mode does not require the
-    use of certificates.
-
-    The initial authentication request is sent as per RFC 1510bis, except
-    that a preauthentication field containing data signed by the user's
-    private key accompanies the request:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                -- PA TYPE 14
-        signedAuthPack          [0] ContentInfo,
-                                    -- Defined in CMS [8];
-                                    -- SignedData OID is {pkcs7 2}
-                                    -- AuthPack (below) defines the
-                                    -- data that is signed.
-        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
-                                    -- This is a list of CAs that the
-                                    -- client trusts and that certify
-                                    -- KDCs.
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
-                                    -- As defined in CMS [8];
-                                    -- specifies a particular KDC
-                                    -- certificate if the client
-                                    -- already has it.
-        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
-                                    -- For example, this may be the
-                                    -- client's Diffie-Hellman
-                                    -- certificate, or it may be the
-                                    -- client's RSA encryption
-                                    -- certificate.
-    }
-
-    TrustedCas ::= CHOICE {
-        principalName         [0] KerberosName,
-                                  -- as defined below
-        caName                [1] Name
-                                  -- fully qualified X.500 name
-                                  -- as defined by X.509
-        issuerAndSerial       [2] IssuerAndSerialNumber
-                                  -- Since a CA may have a number of
-                                  -- certificates, only one of which
-                                  -- a client trusts
-    }
-
-    The type of the ContentInfo in the signedAuthPack is SignedData.
-    Its usage is as follows:
-
-        The SignedData data type is specified in the Cryptographic
-        Message Syntax, a product of the S/MIME working group of the
-        IETF.  The following describes how to fill in the fields of
-        this data:
-
-        1.  The encapContentInfo field MUST contain the PKAuthenticator
-            and, optionally, the client's Diffie Hellman public value.
-
-            a.  The eContentType field MUST contain the OID value for
-                pkauthdata: iso (1) org (3) dod (6) internet (1)
-                security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)
-
-            b.  The eContent field is data of the type AuthPack (below).
-
-        2.  The signerInfos field contains the signature of AuthPack.
-
-        3.  The Certificates field, when non-empty, contains the client's
-            certificate chain.  If present, the KDC uses the public key
-            from the client's certificate to verify the signature in the
-            request.  Note that the client may pass different certificate
-            chains that are used for signing or for encrypting.  Thus,
-            the KDC may utilize a different client certificate for
-            signature verification than the one it uses to encrypt the
-            reply to the client.  For example, the client may place a
-            Diffie-Hellman certificate in this field in order to convey
-            its static Diffie Hellman certificate to the KDC to enable
-            static-ephemeral Diffie-Hellman mode for the reply; in this
-            case, the client does NOT place its public value in the
-            AuthPack (defined below).  As another example, the client may
-            place an RSA encryption certificate in this field.  However,
-            there MUST always be (at least) a signature certificate.
-
-        4.  When a DH key is being used, the public exponent is provided
-            in the subjectPublicKey field of the SubjectPublicKeyInfo and
-            the DH parameters are supplied as a DHParameter in the
-            AlgorithmIdentitfier parameters.  The DH paramters SHOULD be
-            chosen from the First and Second defined Oakley Groups [The
-            Internet Key Exchange (IKE) RFC-2409], if a server will not
-            accept either of these groups, it will respond with a krb-error
-            of KDC_ERR_KEY_TOO_WEAK and the e_data will contain a
-            DHParameter with appropriate parameters for the client to use.
-
-        5.  The KDC may wish to use cached Diffie-Hellman parameters
-            (see Section 3.2.2, KDC Response).  To indicate acceptance
-            of cached parameters, the client sends zero in the nonce
-            field of the PKAuthenticator.  Zero is not a valid value
-            for this field under any other circumstances.  If cached
-            parameters are used, the client and the KDC MUST perform
-            key derivation (for the appropriate cryptosystem) on the
-            resulting encryption key, as specified in RFC 1510bis.  (With
-            a zero nonce, message binding is performed using the nonce
-            in the main request, which must be encrypted using the
-            encapsulated reply key.)
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- if client is using Diffie-Hellman
-                                    -- (ephemeral-ephemeral only)
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER,
-                                    -- for replay prevention as in RFC 1510bis
-        ctime                   [1] KerberosTime,
-                                    -- for replay prevention as in RFC 1510bis
-        nonce                   [2] INTEGER,
-                                    -- zero only if client will accept
-                                    -- cached DH parameters from KDC;
-                                    -- must be non-zero otherwise
-        pachecksum              [3] Checksum
-                                    -- Checksum over KDC-REQ-BODY
-                                    -- Defined by Kerberos spec;
-				    -- must be unkeyed, e.g. sha1 or rsa-md5
-    }
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm                   AlgorithmIdentifier,
-                                    -- dhKeyAgreement
-        subjectPublicKey            BIT STRING
-                                    -- for DH, equals
-                                    -- public exponent (INTEGER encoded
-                                    -- as payload of BIT STRING)
-    }   -- as specified by the X.509 recommendation [7]
-
-    AlgorithmIdentifier ::= SEQUENCE {
-        algorithm                   OBJECT IDENTIFIER,
-                                    -- for dhKeyAgreement, this is
-                                    -- { iso (1) member-body (2) US (840)
-                                    -- rsadsi (113459) pkcs (1) 3 1 }
-                                    -- from PKCS #3 [17]
-        parameters                  ANY DEFINED by algorithm OPTIONAL
-                                    -- for dhKeyAgreement, this is
-                                    -- DHParameter
-    }   -- as specified by the X.509 recommendation [7]
-
-    DHParameter ::= SEQUENCE {
-        prime                       INTEGER,
-                                    -- p
-        base                        INTEGER,
-                                    -- g
-        privateValueLength          INTEGER OPTIONAL
-                                    -- l
-    }   -- as defined in PKCS #3 [17]
-
-    If the client passes an issuer and serial number in the request,
-    the KDC is requested to use the referred-to certificate.  If none
-    exists, then the KDC returns an error of type
-    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
-    other hand, the client does not pass any trustedCertifiers,
-    believing that it has the KDC's certificate, but the KDC has more
-    than one certificate.  The KDC should include information in the
-    KRB-ERROR message that indicates the KDC certificate(s) that a
-    client may utilize.  This data is specified in the e-data, which
-    is defined in RFC 1510bis revisions as a SEQUENCE of TypedData:
-
-    TypedData ::=  SEQUENCE {
-                    data-type      [0] INTEGER,
-                    data-value     [1] OCTET STRING,
-    } -- per Kerberos RFC 1510bis
-
-    where:
-    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
-    data-value = CertificateSet // as specified by CMS [8]
-
-    The PKAuthenticator carries information to foil replay attacks, to
-    bind the pre-authentication data to the KDC-REQ-BODY, and to bind the
-    request and response.  The PKAuthenticator is signed with the client's
-    signature key.
-
-3.2.2.  KDC Response
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.
-
-    If the client's certificate chain contains no certificate signed by
-    a CA trusted by the KDC, then the KDC sends back an error message
-    of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data
-    is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
-    whose data-value is an OCTET STRING which is the DER encoding of
-
-        TrustedCertifiers ::= SEQUENCE OF PrincipalName
-                              -- X.500 name encoded as a principal name
-                              -- see Section 3.1
-
-    If while verifying a certificate chain the KDC determines that the
-    signature on one of the certificates in the CertificateSet from
-    the signedAuthPack fails verification, then the KDC returns an
-    error of type KDC_ERR_INVALID_CERTIFICATE.  The accompanying
-    e-data is a SEQUENCE of one TypedData (with type
-    TD-CERTIFICATE-INDEX=105) whose data-value is an OCTET STRING
-    which is the DER encoding of the index into the CertificateSet
-    ordered as sent by the client.
-
-        CertificateIndex  ::= INTEGER
-                              -- 0 = 1st certificate,
-                              --     (in order of encoding)
-                              -- 1 = 2nd certificate, etc
-
-    The KDC may also check whether any of the certificates in the
-    client's chain has been revoked.  If one of the certificates has
-    been revoked, then the KDC returns an error of type
-    KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
-    the certificate's revocation status is unknown or not
-    available, then if required by policy, the KDC returns the
-    appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
-    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE.  In any of these three
-    cases, the affected certificate is identified by the accompanying
-    e-data, which contains a CertificateIndex as described for
-    KDC_ERR_INVALID_CERTIFICATE.
-
-    If the certificate chain can be verified, but the name of the
-    client in the certificate does not match the client's name in the
-    request, then the KDC returns an error of type
-    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
-    field in this case.
-
-    Even if all succeeds, the KDC may--for policy reasons--decide not
-    to trust the client.  In this case, the KDC returns an error message
-    of type KDC_ERR_CLIENT_NOT_TRUSTED.  One specific case of this is
-    the presence or absence of an Enhanced Key Usage (EKU) OID within
-    the certificate extensions.  The rules regarding acceptability of
-    an EKU sequence (or the absence of any sequence) are a matter of
-    local policy.  For the benefit of implementers, we define a PKINIT
-    EKU OID as the following: iso (1) org (3) dod (6) internet (1)
-    security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on AuthPack.  If that fails, the KDC returns an error
-    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
-    timestamp (ctime and cusec) in the PKAuthenticator to assure that
-    the request is not a replay.  The KDC also verifies that its name
-    is specified in the PKAuthenticator.
-
-    If the clientPublicValue field is filled in, indicating that the
-    client wishes to use Diffie-Hellman key agreement, then the KDC
-    checks to see that the parameters satisfy its policy.  If they do
-    not (e.g., the prime size is insufficient for the expected
-    encryption type), then the KDC sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK, with an e-data containing a structure of
-    type DHParameter with appropriate DH parameters for the client to
-    retry the request.  Otherwise, it generates its own public and
-    private values for the response.
-
-    The KDC also checks that the timestamp in the PKAuthenticator is
-    within the allowable window and that the principal name and realm
-    are correct.  If the local (server) time and the client time in the
-    authenticator differ by more than the allowable clock skew, then the
-    KDC returns an error message of type KRB_AP_ERR_SKEW as defined in
-    RFC 1510bis.
-
-    Assuming no errors, the KDC replies as per RFC 1510bis, except as
-    follows.  The user's name in the ticket is determined by the
-    following decision algorithm:
-
-        1.  If the KDC has a mapping from the name in the certificate
-            to a Kerberos name, then use that name.
-            Else
-        2.  If the certificate contains the SubjectAltName extention
-            and the local KDC policy defines a mapping from the
-            SubjectAltName to a Kerberos name, then use that name.
-            Else
-        3.  Use the name as represented in the certificate, mapping
-            as necessary (e.g., as per RFC 2253 for X.500 names).  In
-            this case the realm in the ticket MUST be the name of the
-            certifier that issued the user's certificate.
-
-    Note that a principal name may be carried in the subjectAltName
-    field of a certificate. This name may be mapped to a principal
-    record in a security database based on local policy, for example
-    the subjectAltName may be kerberos/principal@realm format.  In
-    this case the realm name is not that of the CA but that of the
-    local realm doing the mapping (or some realm name chosen by that
-    realm).
-
-    If a non-KDC X.509 certificate contains the principal name within
-    the subjectAltName version 3 extension, that name may utilize
-    KerberosName as defined below, or, in the case of an S/MIME
-    certificate [14], may utilize the email address.  If the KDC
-    is presented with an S/MIME certificate, then the email address
-    within subjectAltName will be interpreted as a principal and realm
-    separated by the "@" sign, or as a name that needs to be mapped
-    according to local policy.  If the resulting name does not correspond
-    to a registered principal name, then the principal name is formed as
-    defined in section 3.1.
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.  If the KDC has no
-    certificate signed by any of the trustedCertifiers, then it returns
-    an error of type KDC_ERR_KDC_NOT_TRUSTED.
-
-    KDCs should try to (in order of preference):
-    1. Use the KDC certificate identified by the serialNumber included
-       in the client's request.
-    2. Use a certificate issued to the KDC by one of the client's
-       trustedCertifier(s);
-    If the KDC is unable to comply with any of these options, then the
-    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
-    client.
-
-    The KDC encrypts the reply not with the user's long-term key, but
-    with the Diffie Hellman derived key or a random key generated
-    for this particular response which is carried in the padata field of
-    the TGS-REP message.
-
-    PA-PK-AS-REP ::= CHOICE {
-                            -- PA TYPE 15
-        dhSignedData       [0] ContentInfo,
-                            -- Defined in CMS [8] and used only with
-                            -- Diffie-Hellman key exchange (if the
-                            -- client public value was present in the
-                            -- request).
-                            -- SignedData OID is {pkcs7 2}
-                            -- This choice MUST be supported
-                            -- by compliant implementations.
-        encKeyPack         [1] ContentInfo
-                            -- Defined in CMS [8].
-                            -- The temporary key is encrypted
-                            -- using the client public key
-                            -- key.
-                            -- EnvelopedData OID is {pkcs7 3}
-                            -- SignedReplyKeyPack, encrypted
-                            -- with the temporary key, is also
-                            -- included.
-    }
-
-    The type of the ContentInfo in the dhSignedData is SignedData.
-    Its usage is as follows:
-
-        When the Diffie-Hellman option is used, dhSignedData in
-        PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
-        of the KDC.  The reply key used to encrypt part of the KDC reply
-        message is derived from the Diffie-Hellman exchange:
-
-        1.  Both the KDC and the client calculate a secret value
-            (g^ab mod p), where a is the client's private exponent and
-            b is the KDC's private exponent.
-
-        2.  Both the KDC and the client take the first N bits of this
-            secret value and convert it into a reply key.  N depends on
-            the reply key type.
-
-            a.  For example, if the reply key is DES, N=64 bits, where
-                some of the bits are replaced with parity bits, according
-                to FIPS PUB 74.
-
-            b.  As another example, if the reply key is (3-key) 3-DES,
-                N=192 bits, where some of the bits are replaced with
-                parity bits, according to FIPS PUB 74.
-
-        3.  The encapContentInfo field MUST contain the KdcDHKeyInfo as
-            defined below.
-
-            a.  The eContentType field MUST contain the OID value for
-                pkdhkeydata: iso (1) org (3) dod (6) internet (1)
-                security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)
-
-            b.  The eContent field is data of the type KdcDHKeyInfo
-                (below).
-
-        4.  The certificates field MUST contain the certificates
-            necessary for the client to establish trust in the KDC's
-            certificate based on the list of trusted certifiers sent by
-            the client in the PA-PK-AS-REQ.  This field may be empty if
-            the client did not send to the KDC a list of trusted
-            certifiers (the trustedCertifiers field was empty, meaning
-            that the client already possesses the KDC's certificate).
-
-        5.  The signerInfos field is a SET that MUST contain at least
-            one member, since it contains the actual signature.
-
-        6.  If the client indicated acceptance of cached Diffie-Hellman
-            parameters from the KDC, and the KDC supports such an option
-            (for performance reasons), the KDC should return a zero in
-            the nonce field and include the expiration time of the
-            parameters in the dhKeyExpiration field.  If this time is
-            exceeded, the client SHOULD NOT use the reply.  If the time
-            is absent, the client SHOULD NOT use the reply and MAY
-            resubmit a request with a non-zero nonce (thus indicating
-            non-acceptance of cached Diffie-Hellman parameters).  As
-            indicated above in Section 3.2.1, Client Request, when the
-            KDC uses cached parameters, the client and the KDC MUST
-            perform key derivation (for the appropriate cryptosystem)
-            on the resulting encryption key, as specified in RFC 1510bis.
-
-    KdcDHKeyInfo ::= SEQUENCE {
-                              -- used only when utilizing Diffie-Hellman
-      subjectPublicKey      [0] BIT STRING,
-                                -- Equals public exponent (g^a mod p)
-                                -- INTEGER encoded as payload of
-                                -- BIT STRING
-      nonce                 [1] INTEGER,
-                                -- Binds response to the request
-                                -- Exception: Set to zero when KDC
-                                -- is using a cached DH value
-      dhKeyExpiration       [2] KerberosTime OPTIONAL
-                                -- Expiration time for KDC's cached
-                                -- DH value
-    }
-
-    The type of the ContentInfo in the encKeyPack is EnvelopedData.  Its
-    usage is as follows:
-
-        The EnvelopedData data type is specified in the Cryptographic
-        Message Syntax, a product of the S/MIME working group of the
-        IETF.  It contains a temporary key encrypted with the PKINIT
-        client's public key.  It also contains a signed and encrypted
-        reply key.
-
-        1.  The originatorInfo field is not required, since that
-            information may be presented in the signedData structure
-            that is encrypted within the encryptedContentInfo field.
-
-        2.  The optional unprotectedAttrs field is not required for
-            PKINIT.
-
-        3.  The recipientInfos field is a SET which MUST contain exactly
-            one member of the KeyTransRecipientInfo type for encryption
-            with a public key.
-
-            a.  The encryptedKey field (in KeyTransRecipientInfo)
-                contains the temporary key which is encrypted with the
-                PKINIT client's public key.
-
-        4.  The encryptedContentInfo field contains the signed and
-            encrypted reply key.
-
-            a.  The contentType field MUST contain the OID value for
-                id-signedData: iso (1) member-body (2) us (840)
-                rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
-
-            b.  The encryptedContent field is encrypted data of the CMS
-                type signedData as specified below.
-
-                i.  The encapContentInfo field MUST contains the
-                    ReplyKeyPack.
-
-                    * The eContentType field MUST contain the OID value
-                      for pkrkeydata: iso (1) org (3) dod (6) internet (1)
-                      security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3)
-
-                    * The eContent field is data of the type ReplyKeyPack
-                      (below).
-
-                ii.  The certificates field MUST contain the certificates
-                     necessary for the client to establish trust in the
-                     KDC's certificate based on the list of trusted
-                     certifiers sent by the client in the PA-PK-AS-REQ.
-                     This field may be empty if the client did not send
-                     to the KDC a list of trusted certifiers (the
-                     trustedCertifiers field was empty, meaning that the
-                     client already possesses the KDC's certificate).
-
-                iii.  The signerInfos field is a SET that MUST contain at
-                      least one member, since it contains the actual
-                      signature.
-
-    ReplyKeyPack ::= SEQUENCE {
-                              -- not used for Diffie-Hellman
-        replyKey             [0] EncryptionKey,
-                                 -- from RFC 1510bis
-                                 -- used to encrypt main reply
-                                 -- ENCTYPE is at least as strong as
-                                 -- ENCTYPE of session key
-        nonce                [1] INTEGER,
-                                 -- binds response to the request
-                                 -- must be same as the nonce
-                                 -- passed in the PKAuthenticator
-    }
-
-
-3.2.2.1. Use of transited Field
-
-    Since each certifier in the certification path of a user's
-    certificate is equivalent to a separate Kerberos realm, the name
-    of each certifier in the certificate chain MUST be added to the
-    transited field of the ticket.  The format of these realm names is
-    defined in Section 3.1 of this document.  If applicable, the
-    transit-policy-checked flag should be set in the issued ticket.
-
-
-3.2.2.2. Kerberos Names in Certificates
-
-    The KDC's certificate(s) MUST bind the public key(s) of the KDC to
-    a name derivable from the name of the realm for that KDC.  X.509
-    certificates MUST contain the principal name of the KDC (defined in
-    RFC 1510bis) as the SubjectAltName version 3 extension.  Below is
-    the definition of this version 3 extension, as specified by the
-    X.509 standard:
-
-        subjectAltName EXTENSION ::= {
-            SYNTAX GeneralNames
-            IDENTIFIED BY id-ce-subjectAltName
-        }
-
-        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
-
-        GeneralName ::= CHOICE {
-            otherName       [0] OtherName,
-            ...
-        }
-
-        OtherName ::= SEQUENCE {
-            type-id         OBJECT IDENTIFIER,
-            value           [0] EXPLICIT ANY DEFINED BY type-id
-        }
-
-    For the purpose of specifying a Kerberos principal name, the value
-    in OtherName MUST be a KerberosName, defined as follows:
-
-        KerberosName ::= SEQUENCE {
-            realm           [0] Realm,
-            principalName   [1] PrincipalName
-        }
-
-    This specific syntax is identified within subjectAltName by setting
-    the type-id in OtherName to krb5PrincipalName, where (from the
-    Kerberos specification) we have
-
-        krb5 OBJECT IDENTIFIER ::= { iso (1)
-                                     org (3)
-                                     dod (6)
-                                     internet (1)
-                                     security (5)
-                                     kerberosv5 (2) }
-
-        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
-
-    (This specification may also be used to specify a Kerberos name
-    within the user's certificate.)  The KDC's certificate may be signed
-    directly by a CA, or there may be intermediaries if the server resides
-    within a large organization, or it may be unsigned if the client
-    indicates possession (and trust) of the KDC's certificate.
-
-    Note that the KDC's principal name has the instance equal to the
-    realm, and those fields should be appropriately set in the realm
-    and principalName fields of the KerberosName.  This is the case
-    even when obtaining a cross-realm ticket using PKINIT.
-
-
-3.2.3. Client Extraction of Reply
-
-    The client then extracts the random key used to encrypt the main
-    reply.  This random key (in encPaReply) is encrypted with either the
-    client's public key or with a key derived from the DH values
-    exchanged between the client and the KDC.  The client uses this
-    random key to decrypt the main reply, and subsequently proceeds as
-    described in RFC 1510bis.
-
-3.2.4. Required Algorithms
-
-    Not all of the algorithms in the PKINIT protocol specification have
-    to be implemented in order to comply with the proposed standard.
-    Below is a list of the required algorithms:
-
-    * Diffie-Hellman public/private key pairs
-        * utilizing Diffie-Hellman ephemeral-ephemeral mode
-    * SHA1 digest and DSA for signatures
-    * SHA1 digest for the Checksum in the PKAuthenticator
-        * using Kerberos checksum type 'sha1'
-    * 3-key triple DES keys derived from the Diffie-Hellman Exchange
-    * 3-key triple DES Temporary and Reply keys
-
-4.  Logistics and Policy
-
-    This section describes a way to define the policy on the use of
-    PKINIT for each principal and request.
-
-    The KDC is not required to contain a database record for users
-    who use public key authentication.  However, if these users are
-    registered with the KDC, it is recommended that the database record
-    for these users be modified to an additional flag in the attributes
-    field to indicate that the user should authenticate using PKINIT.
-    If this flag is set and a request message does not contain the
-    PKINIT preauthentication field, then the KDC sends back as error of
-    type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
-    field of type PA-PK-AS-REQ must be included in the request.
-
-5.  Security Considerations
-
-    PKINIT raises a few security considerations, which we will address
-    in this section.
-
-    First of all, PKINIT extends the cross-realm model to the public
-    key infrastructure.  Anyone using PKINIT must be aware of how the
-    certification infrastructure they are linking to works.
-
-    Also, as in standard Kerberos, PKINIT presents the possibility of
-    interactions between different cryptosystems of varying strengths,
-    and this now includes public-key cryptosystems.  Many systems, for
-    instance, allow the use of 512-bit public keys.  Using such keys
-    to wrap data encrypted under strong conventional cryptosystems,
-    such as triple-DES, may be inappropriate.
-
-    Care should be taken in how certificates are choosen for the purposes
-    of authentication using PKINIT. Some local policies require that key
-    escrow be applied for certain certificate types. People deploying
-    PKINIT should be aware of the implications of using certificates that
-    have escrowed keys for the purposes of authentication.
-
-    As described in Section 3.2, PKINIT allows for the caching of the
-    Diffie-Hellman parameters on the KDC side, for performance reasons.
-    For similar reasons, the signed data in this case does not vary from
-    message to message, until the cached parameters expire.  Because of
-    the persistence of these parameters, the client and the KDC are to
-    use the appropriate key derivation measures (as described in RFC
-    1510bis) when using cached DH parameters.
-
-    Lastly, PKINIT calls for randomly generated keys for conventional
-    cryptosystems.  Many such systems contain systematically "weak"
-    keys.  For recommendations regarding these weak keys, see RFC
-    1510bis.
-
-6.  Transport Issues
-
-    Certificate chains can potentially grow quite large and span several
-    UDP packets; this in turn increases the probability that a Kerberos
-    message involving PKINIT extensions will be broken in transit.  In
-    light of the possibility that the Kerberos specification will
-    require KDCs to accept requests using TCP as a transport mechanism,
-    we make the same recommendation with respect to the PKINIT
-    extensions as well.
-
-7.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-    (V5).  Request for Comments 1510.
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.  September
-    1994.
-
-    [3] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-    Using Public Key Cryptography.  Symposium On Network and Distributed
-    System Security, 1997.
-
-    [4] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic
-    Commerce, July 1995.
-
-    [5] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
-    Request for Comments 2246, January 1999.
-
-    [6] B.C. Neuman, Proxy-Based Authorization and Accounting for
-    Distributed Systems.  In Proceedings of the 13th International
-    Conference on Distributed Computing Systems, May 1993.
-
-    [7] ITU-T (formerly CCITT) Information technology - Open Systems
-    Interconnection - The Directory: Authentication Framework
-    Recommendation X.509 ISO/IEC 9594-8
-
-    [8] R. Housley. Cryptographic Message Syntax.
-    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
-    as RFC.
-
-    [9] PKCS #7: Cryptographic Message Syntax Standard,
-    An RSA Laboratories Technical Note Version 1.5
-    Revised November 1, 1993
-
-    [10] R. Rivest, MIT Laboratory for Computer Science and RSA Data
-    Security, Inc. A Description of the RC2(r) Encryption Algorithm
-    March 1998.
-    Request for Comments 2268.
-
-    [11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
-    Protocol (v3): UTF-8 String Representation of Distinguished Names.
-    Request for Comments 2253.
-
-    [12] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
-    Key Infrastructure, Certificate and CRL Profile, January 1999.
-    Request for Comments 2459.
-
-    [13] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-    Specifications, October 1998.  Request for Comments 2437.
-
-    [14] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
-    Version 2 Certificate Handling, March 1998.  Request for
-    Comments 2312.
-
-    [15] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
-    Protocol (v3), December 1997.  Request for Comments 2251.
-
-    [16] ITU-T (formerly CCITT) Information Processing Systems - Open
-    Systems Interconnection - Specification of Abstract Syntax Notation
-    One (ASN.1) Rec. X.680 ISO/IEC 8824-1
-
-    [17] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
-    Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
-
-8.  Acknowledgements
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-9.  Expiration Date
-
-    This draft expires May 25, 2002.
-
-10. Authors
-
-    Brian Tung
-    Clifford Neuman
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {brian, bcn}@isi.edu
-
-    Matthew Hur
-    Cisco Systems
-    2901 Third Avenue
-    Seattle WA 98121
-    Phone: (206) 256-3197
-    E-Mail: mhur@cisco.com
-
-    Ari Medvinsky
-    Keen.com, Inc.
-    150 Independence Drive
-    Menlo Park CA 94025
-    Phone: +1 650 289 3134
-    E-mail: ari@keen.com
-
-    Sasha Medvinsky
-    Motorola
-    6450 Sequence Drive
-    San Diego, CA 92121
-    +1 858 404 2367
-    E-mail: smedvinsky@gi.com
-
-    John Wray
-    Iris Associates, Inc.
-    5 Technology Park Dr.
-    Westford, MA 01886
-    E-mail: John_Wray@iris.com
-
-    Jonathan Trostle
-    Cisco Systems
-    170 W. Tasman Dr.
-    San Jose, CA 95134
-    E-mail: jtrostle@cisco.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-16.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-16.txt
deleted file mode 100644
index 10dd60299..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-16.txt
+++ /dev/null
@@ -1,1132 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-16.txt                   Clifford Neuman
-Updates: RFC 1510bis                                             USC/ISI
-expires March 12, 2002                                       Matthew Hur
-                                                   Microsoft Corporation
-                                                           Ari Medvinsky
-                                                   Liberate Technologies
-                                                         Sasha Medvinsky
-                                                          Motorola, Inc.
-                                                               John Wray
-                                                   Iris Associates, Inc.
-                                                        Jonathan Trostle
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-0.  Status Of This Memo
-
-    This document is an Internet-Draft and is in full conformance with
-    all provisions of Section 10 of RFC 2026.  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."
-
-    The list of current Internet-Drafts can be accessed at
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-    The list of Internet-Draft Shadow Directories can be accessed at
-    http://www.ietf.org/shadow.html.
-
-    To learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ftp.ietf.org (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-16.txt, and expires March 12,
-    2002.  Please send comments to the authors.
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510bis [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to associate a key pair with each realm, which can
-    then be used to facilitate cross-realm authentication; this is the
-    topic of another draft proposal.  Another way is to allow users with
-    public key certificates to use them in initial authentication.  This
-    is the concern of the current document.
-
-    PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in
-    combination with RSA keys as the primary, required mechanism.  Note
-    that PKINIT supports the use of separate signature and encryption
-    keys.
-
-    PKINIT enables access to Kerberos-secured services based on initial
-    authentication utilizing public key cryptography.  PKINIT utilizes
-    standard public key signature and encryption data formats within the
-    standard Kerberos messages.  The basic mechanism is as follows:  The
-    user sends an AS-REQ message to the KDC as before, except that if that
-    user is to use public key cryptography in the initial authentication
-    step, his certificate and a signature accompany the initial request
-    in the preauthentication fields.  Upon receipt of this request, the
-    KDC verifies the certificate and issues a ticket granting ticket
-    (TGT) as before, except that the encPart from the AS-REP message
-    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
-    derived key or the user's public key.  This message is authenticated
-    utilizing the public key signature of the KDC.
-
-    Note that PKINIT does not require the use of certificates.  A KDC
-    may store the public key of a principal as part of that principal's
-    record.  In this scenario, the KDC is the trusted party that vouches
-    for the principal (as in a standard, non-cross realm, Kerberos
-    environment).  Thus, for any principal, the KDC may maintain a
-    symmetric key, a public key, or both.
-
-    The PKINIT specification may also be used as a building block for
-    other specifications.  PKINIT may be utilized to establish
-    inter-realm keys for the purposes of issuing cross-realm service
-    tickets.  It may also be used to issue anonymous Kerberos tickets
-    using the Diffie-Hellman option.  Efforts are under way to draft
-    specifications for these two application protocols.
-
-    Additionally, the PKINIT specification may be used for direct peer
-    to peer authentication without contacting a central KDC. This
-    application of PKINIT is based on concepts introduced in [6, 7].
-    For direct client-to-server authentication, the client uses PKINIT
-    to authenticate to the end server (instead of a central KDC), which
-    then issues a ticket for itself.  This approach has an advantage
-    over TLS [5] in that the server does not need to save state (cache
-    session keys).  Furthermore, an additional benefit is that Kerberos
-    tickets can facilitate delegation (see [6]).
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510bis for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following change to RFC 1510bis is proposed:
-
-        * Users may authenticate using either a public key pair or a
-          conventional (symmetric) key.  If public key cryptography is
-          used, public key data is transported in preauthentication
-          data fields to help establish identity.  The user presents
-          a public key certificate and obtains an ordinary TGT that may
-          be used for subsequent authentication, with such
-          authentication using only conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 describes the extensions for the initial authentication
-    method.
-
-3.1.  Definitions
-
-    The extensions involve new preauthentication fields; we introduce
-    the following preauthentication types:
-
-        PA-PK-AS-REQ                            14
-        PA-PK-AS-REP                            15
-
-    The extensions also involve new error types; we introduce the
-    following types:
-
-        KDC_ERR_CLIENT_NOT_TRUSTED              62
-        KDC_ERR_KDC_NOT_TRUSTED                 63
-        KDC_ERR_INVALID_SIG                     64
-        KDC_ERR_KEY_TOO_WEAK                    65
-        KDC_ERR_CERTIFICATE_MISMATCH            66
-        KDC_ERR_CANT_VERIFY_CERTIFICATE         70
-        KDC_ERR_INVALID_CERTIFICATE             71
-        KDC_ERR_REVOKED_CERTIFICATE             72
-        KDC_ERR_REVOCATION_STATUS_UNKNOWN       73
-        KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74
-        KDC_ERR_CLIENT_NAME_MISMATCH            75
-        KDC_ERR_KDC_NAME_MISMATCH               76
-
-    We utilize the following typed data for errors:
-
-        TD-PKINIT-CMS-CERTIFICATES             101
-        TD-DH-PARAMETERS                       102
-        TD-TRUSTED-CERTIFIERS                  104
-        TD-CERTIFICATE-INDEX                   105
-
-    We utilize the following encryption types (which map directly to
-    OIDs):
-
-        dsaWithSHA1-CmsOID                       9
-        md5WithRSAEncryption-CmsOID             10
-        sha1WithRSAEncryption-CmsOID            11
-        rc2CBC-EnvOID                           12
-        rsaEncryption-EnvOID (PKCS#1 v1.5)      13
-        rsaES-OAEP-ENV-OID   (PKCS#1 v2.0)      14
-        des-ede3-cbc-Env-OID                    15
-
-    These mappings are provided so that a client may send the
-    appropriate enctypes in the AS-REQ message in order to indicate
-    support for the corresponding OIDs (for performing PKINIT).  The
-    above encryption types are utilized only within CMS structures
-    within the PKINIT preauthentication fields. Their use within
-    the Kerberos EncryptedData structure is unspecified.
-
-    In many cases, PKINIT requires the encoding of the X.500 name of a
-    certificate authority as a Realm.  When such a name appears as
-    a realm it will be represented using the "Other" form of the realm
-    name as specified in the naming constraints section of RFC 1510bis.
-    For a realm derived from an X.500 name, NAMETYPE will have the value
-    X500-RFC2253.  The full realm name will appear as follows:
-
-        <nametype> + ":" + <string>
-
-    where nametype is "X500-RFC2253" and string is the result of doing
-    an RFC2253 encoding of the distinguished name, i.e.
-
-        "X500-RFC2253:" + RFC2253Encode(DistinguishedName)
-
-    where DistinguishedName is an X.500 name, and RFC2253Encode is a
-    function returing a readable UTF encoding of an X.500 name, as
-    defined by RFC 2253 [11] (part of LDAPv3 [15]).
-
-    Each component of a DistinguishedName is called a
-    RelativeDistinguishedName, where a RelativeDistinguishedName is a
-    SET OF AttributeTypeAndValue.  RFC 2253 does not specify the order
-    in which to encode the elements of the RelativeDistinguishedName and
-    so to ensure that this encoding is unique, we add the following rule
-    to those specified by RFC 2253:
-     
-	When converting a multi-valued RelativeDistinguishedName
-        to a string, the output consists of the string encodings
-        of each AttributeTypeAndValue, in the same order as
-	specified by the DER encoding.    
-
-    Similarly, in cases where the KDC does not provide a specific
-    policy-based mapping from the X.500 name or X.509 Version 3
-    SubjectAltName extension in the user's certificate to a Kerberos
-    principal name, PKINIT requires the direct encoding of the X.500
-    name as a PrincipalName.  In this case, the name-type of the
-    principal name MUST be set to KRB_NT-X500-PRINCIPAL.  This new
-    name type is defined in RFC 1510bis as:
-
-        KRB_NT_X500_PRINCIPAL    6
-
-    For this type, the name-string MUST be set as follows:
-
-        RFC2253Encode(DistinguishedName)
-
-    as described above.  When this name type is used, the principal's
-    realm MUST be set to the certificate authority's distinguished
-    name using the X500-RFC2253 realm name format described earlier in
-    this section.
-
-    Note that the same string may be represented using several different
-    ASN.1 data types.  As the result, the reverse conversion from an
-    RFC2253-encoded principal name back to an X.500 name may not be
-    unique and may result in an X.500 name that is not the same as the
-    original X.500 name found in the client certificate.
-
-    RFC 1510bis describes an alternate encoding of an X.500 name into a
-    realm name.  However, as described in RFC 1510bis, the alternate
-    encoding does not guarantee a unique mapping from a
-    DistinguishedName inside a certificate into a realm name and
-    similarly cannot be used to produce a unique principal name.  PKINIT
-    therefore uses an RFC 2253-based name mapping approach, as specified
-    above.
-
-    RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows:
-
-        PrincipalName ::=   SEQUENCE {
-                        name-type[0]     INTEGER,
-                        name-string[1]   SEQUENCE OF GeneralString
-        }
-
-    The following rules relate to the the matching of PrincipalNames
-    with regard to the PKI name constraints for CAs as laid out in RFC
-    2459 [12].  In order to be regarded as a match (for permitted and
-    excluded name trees), the following MUST be satisfied.
-
-        1.  If the constraint is given as a user plus realm name, or
-            as a client principal name plus realm name (as specified in
-            RFC 1510bis), the realm name MUST be valid (see 2.a-d below)
-            and the match MUST be exact, byte for byte.
-
-        2.  If the constraint is given only as a realm name, matching
-            depends on the type of the realm:
-
-            a.  If the realm contains a colon (':') before any equal
-                sign ('='), it is treated as a realm of type Other,
-                and MUST match exactly, byte for byte.
-
-            b.  Otherwise, if the realm name conforms to rules regarding
-                the format of DNS names, it is considered a realm name of
-                type Domain.  The constraint may be given as a realm
-                name 'FOO.BAR', which matches any PrincipalName within
-                the realm 'FOO.BAR' but not those in subrealms such as
-                'CAR.FOO.BAR'.  A constraint of the form '.FOO.BAR'
-                matches PrincipalNames in subrealms of the form
-                'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself.
-
-            c.  Otherwise, the realm name is invalid and does not match
-                under any conditions.
-
-3.1.1.  Encryption and Key Formats
-
-    In the exposition below, we use the terms public key and private
-    key generically.  It should be understood that the term "public
-    key" may be used to refer to either a public encryption key or a
-    signature verification key, and that the term "private key" may be
-    used to refer to either a private decryption key or a signature
-    generation key.  The fact that these are logically distinct does
-    not preclude the assignment of bitwise identical keys for RSA
-    keys.
-
-    In the case of Diffie-Hellman, the key is produced from the agreed
-    bit string as follows:
-
-        * Truncate the bit string to the required length.
-        * Apply the specific cryptosystem's random-to-key function.
-
-    Appropriate key constraints for each valid cryptosystem are given
-    in RFC 1510bis.
-
-3.1.2. Algorithm Identifiers
-
-    PKINIT does not define, but does permit, the algorithm identifiers
-    listed below.
-
-3.1.2.1. Signature Algorithm Identifiers
-
-    The following signature algorithm identifiers specified in [8] and
-    in [12] are used with PKINIT:
-
-    sha-1WithRSAEncryption (RSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    id-dsa-with-sha1       (DSA with SHA1)
-
-3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
-
-    The following algorithm identifier shall be used within the
-    SubjectPublicKeyInfo data structure: dhpublicnumber
-
-    This identifier and the associated algorithm parameters are
-    specified in RFC 2459 [12].
-
-3.1.2.3. Algorithm Identifiers for RSA Encryption
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure, for encrypting the temporary key with a public key:
-
-        rsaEncryption (RSA encryption, PKCS#1 v1.5)
-        id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
-
-    Both of the above RSA encryption schemes are specified in [13].
-    Currently, only PKCS#1 v1.5 is specified by CMS [8], although the
-    CMS specification says that it will likely include PKCS#1 v2.0 in
-    the future.  (PKCS#1 v2.0 addresses adaptive chosen ciphertext
-    vulnerability discovered in PKCS#1 v1.5.)
-
-3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure in the PKINIT Reply, for encrypting the reply key with the
-    temporary key:
-        des-ede3-cbc (3-key 3-DES, CBC mode)
-        rc2-cbc      (RC2, CBC mode)
-
-    The full definition of the above algorithm identifiers and their
-    corresponding parameters (an IV for block chaining) is provided in
-    the CMS specification [8].
-
-3.2.  Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with PKINIT.
-
-3.2.1.  Client Request
-
-    Public keys may be signed by some certification authority (CA), or
-    they may be maintained by the KDC in which case the KDC is the
-    trusted authority.  Note that the latter mode does not require the
-    use of certificates.
-
-    The initial authentication request is sent as per RFC 1510bis, except
-    that a preauthentication field containing data signed by the user's
-    private key accompanies the request:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                -- PA TYPE 14
-        signedAuthPack          [0] ContentInfo,
-                                    -- Defined in CMS [8];
-                                    -- SignedData OID is {pkcs7 2}
-                                    -- AuthPack (below) defines the
-                                    -- data that is signed.
-        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
-                                    -- This is a list of CAs that the
-                                    -- client trusts and that certify
-                                    -- KDCs.
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
-                                    -- As defined in CMS [8];
-                                    -- specifies a particular KDC
-                                    -- certificate if the client
-                                    -- already has it.
-        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
-                                    -- For example, this may be the
-                                    -- client's Diffie-Hellman
-                                    -- certificate, or it may be the
-                                    -- client's RSA encryption
-                                    -- certificate.
-    }
-
-    TrustedCas ::= CHOICE {
-        principalName         [0] KerberosName,
-                                  -- as defined below
-        caName                [1] Name
-                                  -- fully qualified X.500 name
-                                  -- as defined by X.509
-        issuerAndSerial       [2] IssuerAndSerialNumber
-                                  -- Since a CA may have a number of
-                                  -- certificates, only one of which
-                                  -- a client trusts
-    }
-
-    The type of the ContentInfo in the signedAuthPack is SignedData.
-    Its usage is as follows:
-
-        The SignedData data type is specified in the Cryptographic
-        Message Syntax, a product of the S/MIME working group of the
-        IETF.  The following describes how to fill in the fields of
-        this data:
-
-        1.  The encapContentInfo field MUST contain the PKAuthenticator
-            and, optionally, the client's Diffie Hellman public value.
-
-            a.  The eContentType field MUST contain the OID value for
-                pkauthdata: iso (1) org (3) dod (6) internet (1)
-                security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)
-
-            b.  The eContent field is data of the type AuthPack (below).
-
-        2.  The signerInfos field contains the signature of AuthPack.
-
-        3.  The Certificates field, when non-empty, contains the client's
-            certificate chain.  If present, the KDC uses the public key
-            from the client's certificate to verify the signature in the
-            request.  Note that the client may pass different certificate
-            chains that are used for signing or for encrypting.  Thus,
-            the KDC may utilize a different client certificate for
-            signature verification than the one it uses to encrypt the
-            reply to the client.  For example, the client may place a
-            Diffie-Hellman certificate in this field in order to convey
-            its static Diffie Hellman certificate to the KDC to enable
-            static-ephemeral Diffie-Hellman mode for the reply; in this
-            case, the client does NOT place its public value in the
-            AuthPack (defined below).  As another example, the client may
-            place an RSA encryption certificate in this field.  However,
-            there MUST always be (at least) a signature certificate.
-
-        4.  When a DH key is being used, the public exponent is provided
-            in the subjectPublicKey field of the SubjectPublicKeyInfo and
-            the DH parameters are supplied as a DomainParameters in the
-            AlgorithmIdentitfier parameters.  The DH paramters SHOULD be
-            chosen from the First and Second defined Oakley Groups [The
-            Internet Key Exchange (IKE) RFC-2409], if a server will not
-            accept either of these groups, it will respond with a krb-
-            error of KDC_ERR_KEY_TOO_WEAK.  The accompanying e-data is
-            a SEQUENCE of TypedData that includes type 
-            TD-DH-PARAMETERS (102) whose data-value is DomainParameters
-            with appropriate Diffie-Hellman parameters for the client to
-            use.
-
-        5.  The KDC may wish to use cached Diffie-Hellman parameters
-            (see Section 3.2.2, KDC Response).  To indicate acceptance
-            of cached parameters, the client sends zero in the nonce
-            field of the PKAuthenticator.  Zero is not a valid value
-            for this field under any other circumstances.  If cached
-            parameters are used, the client and the KDC MUST perform
-            key derivation (for the appropriate cryptosystem) on the
-            resulting encryption key, as specified in RFC 1510bis.  (With
-            a zero nonce, message binding is performed using the nonce
-            in the main request, which must be encrypted using the
-            encapsulated reply key.)
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- if client is using Diffie-Hellman
-                                    -- (ephemeral-ephemeral only)
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER,
-                                    -- for replay prevention as in RFC 1510bis
-        ctime                   [1] KerberosTime,
-                                    -- for replay prevention as in RFC 1510bis
-        nonce                   [2] INTEGER,
-                                    -- zero only if client will accept
-                                    -- cached DH parameters from KDC;
-                                    -- must be non-zero otherwise
-        pachecksum              [3] Checksum
-                                    -- Checksum over KDC-REQ-BODY
-                                    -- Defined by Kerberos spec;
-				    -- must be unkeyed, e.g. sha1 or rsa-md5
-    }
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm                   AlgorithmIdentifier,
-                                    -- dhPublicNumber
-        subjectPublicKey            BIT STRING
-                                    -- for DH, equals
-                                    -- public exponent (INTEGER encoded
-                                    -- as payload of BIT STRING)
-    }   -- as specified by the X.509 recommendation [7]
-
-    AlgorithmIdentifier ::= SEQUENCE {
-        algorithm                   OBJECT IDENTIFIER,
-                                    -- for dhPublicNumber, this is
-                                    -- { iso (1) member-body (2) US (840)
-                                    -- ansi-x942(10046) number-type(2) 1 }
-                                    -- from RFC 2459 [12]
-        parameters                  ANY DEFINED by algorithm OPTIONAL
-                                    -- for dhPublicNumber, this is
-                                    -- DomainParameters
-    }   -- as specified by the X.509 recommendation [7]
-
-    DomainParameters ::= SEQUENCE {
-        p                           INTEGER, -- odd prime, p=jq +1
-        g                           INTEGER, -- generator, g
-        q                           INTEGER, -- factor of p-1
-        j                           INTEGER OPTIONAL, -- subgroup factor
-        validationParms             ValidationParms OPTIONAL
-    }   -- as defined in RFC 2459 [12]
-
-    ValidationParms ::= SEQUENCE {
-        seed                        BIT STRING,
-                                    -- seed for the system parameter
-                                    -- generation process
-        pgenCounter                 INTEGER
-                                    -- integer value output as part
-                                    -- of the of the system parameter
-                                    -- prime generation process
-    }   -- as defined in RFC 2459 [12]
-
-    If the client passes an issuer and serial number in the request,
-    the KDC is requested to use the referred-to certificate.  If none
-    exists, then the KDC returns an error of type
-    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
-    other hand, the client does not pass any trustedCertifiers,
-    believing that it has the KDC's certificate, but the KDC has more
-    than one certificate.  The KDC should include information in the
-    KRB-ERROR message that indicates the KDC certificate(s) that a
-    client may utilize.  This data is specified in the e-data, which
-    is defined in RFC 1510bis revisions as a SEQUENCE of TypedData:
-
-    TypedData ::=  SEQUENCE {
-                    data-type      [0] INTEGER,
-                    data-value     [1] OCTET STRING,
-    } -- per Kerberos RFC 1510bis
-
-    where one of the TypedData elements is:
-    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
-    data-value = CertificateSet // as specified by CMS [8]
-
-    The PKAuthenticator carries information to foil replay attacks, to
-    bind the pre-authentication data to the KDC-REQ-BODY, and to bind the
-    request and response.  The PKAuthenticator is signed with the client's
-    signature key.
-
-3.2.2.  KDC Response
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the client's certificate chain, if
-    one is provided in the request.  This is done by verifying the
-    certification path against the KDC's policy of legitimate
-    certifiers.
-
-    If the KDC cannot find a trusted client certificate chain within
-    the PA-PK-AS-REQ, then the KDC sends back an error message of type
-    KDC_ERR_CANT_VERIFY_CERTIFICATE.  Certificate chain validation is
-    defined in RFC 2459 [12].  The accompanying e-data for this error
-    code is a SEQUENCE of TypedData that includes type
-    TD-TRUSTED-CERTIFIERS (104) whose data-value is an OCTET STRING
-    which is the DER encoding of
-
-        TrustedCertifiers ::= SEQUENCE OF PrincipalName
-                              -- X.500 name encoded as a principal name
-                              -- see Section 3.1
-
-    If while verifying a certificate chain the KDC determines that the
-    signature on one of the certificates in the CertificateSet from
-    the signedAuthPack fails verification, then the KDC returns an
-    error of type KDC_ERR_INVALID_CERTIFICATE.  The accompanying
-    e-data is a SEQUENCE of TypedData that includes type
-    TD-CERTIFICATE-INDEX (105) whose data-value is an OCTET STRING
-    which is the DER encoding of the index into the CertificateSet
-    ordered as sent by the client.
-
-        CertificateIndex  ::= INTEGER
-                              -- 0 = 1st certificate,
-                              --     (in order of encoding)
-                              -- 1 = 2nd certificate, etc
-
-    The KDC may also check whether any of the certificates in the
-    client's chain has been revoked.  If one of the certificates has
-    been revoked, then the KDC returns an error of type
-    KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that
-    the certificate's revocation status is unknown or not
-    available, then if required by policy, the KDC returns the
-    appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or
-    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE.  In any of these three
-    cases, the affected certificate is identified by the accompanying
-    e-data, which contains a CertificateIndex as described for
-    KDC_ERR_INVALID_CERTIFICATE.
-
-    If the certificate chain can be verified, but the name of the
-    client in the certificate does not match the client's name in the
-    request, then the KDC returns an error of type
-    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
-    field in this case.
-
-    Even if all succeeds, the KDC may--for policy reasons--decide not
-    to trust the client.  In this case, the KDC returns an error message
-    of type KDC_ERR_CLIENT_NOT_TRUSTED.  One specific case of this is
-    the presence or absence of an Enhanced Key Usage (EKU) OID within
-    the certificate extensions.  The rules regarding acceptability of
-    an EKU sequence (or the absence of any sequence) are a matter of
-    local policy.  For the benefit of implementers, we define a PKINIT
-    EKU OID as the following: iso (1) org (3) dod (6) internet (1)
-    security (5) kerberosv5 (2) pkinit (3) pkekuoid (2).
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on AuthPack.  If that fails, the KDC returns an error
-    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
-    timestamp (ctime and cusec) in the PKAuthenticator to assure that
-    the request is not a replay.  The KDC also verifies that its name
-    is specified in the PKAuthenticator.
-
-    If the clientPublicValue field is filled in, indicating that the
-    client wishes to use Diffie-Hellman key agreement, then the KDC
-    checks to see that the parameters satisfy its policy.  If they do
-    not (e.g., the prime size is insufficient for the expected
-    encryption type), then the KDC sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  The accompanying e-data is a SEQUENCE of
-    TypedData that includes type TD-DH-PARAMETERS (102) whose data-value
-    is DomainParameters with appropriate Diffie-Hellman parameters for
-    the client to retry the request.  Otherwise, it generates its own
-    public and private values for the response.
-
-    The KDC also checks that the timestamp in the PKAuthenticator is
-    within the allowable window and that the principal name and realm
-    are correct.  If the local (server) time and the client time in the
-    authenticator differ by more than the allowable clock skew, then the
-    KDC returns an error message of type KRB_AP_ERR_SKEW as defined in
-    RFC 1510bis.
-
-    Assuming no errors, the KDC replies as per RFC 1510bis, except as
-    follows.  The user's name in the ticket is determined by the
-    following decision algorithm:
-
-        1.  If the KDC has a mapping from the name in the certificate
-            to a Kerberos name, then use that name.
-            Else
-        2.  If the certificate contains the SubjectAltName extention
-            and the local KDC policy defines a mapping from the
-            SubjectAltName to a Kerberos name, then use that name.
-            Else
-        3.  Use the name as represented in the certificate, mapping
-            as necessary (e.g., as per RFC 2253 for X.500 names).  In
-            this case the realm in the ticket MUST be the name of the
-            certifier that issued the user's certificate.
-
-    Note that a principal name may be carried in the subjectAltName
-    field of a certificate. This name may be mapped to a principal
-    record in a security database based on local policy, for example
-    the subjectAltName may be kerberos/principal@realm format.  In
-    this case the realm name is not that of the CA but that of the
-    local realm doing the mapping (or some realm name chosen by that
-    realm).
-
-    If a non-KDC X.509 certificate contains the principal name within
-    the subjectAltName version 3 extension, that name may utilize
-    KerberosName as defined below, or, in the case of an S/MIME
-    certificate [14], may utilize the email address.  If the KDC
-    is presented with an S/MIME certificate, then the email address
-    within subjectAltName will be interpreted as a principal and realm
-    separated by the "@" sign, or as a name that needs to be mapped
-    according to local policy.  If the resulting name does not correspond
-    to a registered principal name, then the principal name is formed as
-    defined in section 3.1.
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.  If the KDC has no
-    certificate signed by any of the trustedCertifiers, then it returns
-    an error of type KDC_ERR_KDC_NOT_TRUSTED.
-
-    KDCs should try to (in order of preference):
-    1. Use the KDC certificate identified by the serialNumber included
-       in the client's request.
-    2. Use a certificate issued to the KDC by one of the client's
-       trustedCertifier(s);
-    If the KDC is unable to comply with any of these options, then the
-    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
-    client.
-
-    The KDC encrypts the reply not with the user's long-term key, but
-    with the Diffie Hellman derived key or a random key generated
-    for this particular response which is carried in the padata field of
-    the TGS-REP message.
-
-    PA-PK-AS-REP ::= CHOICE {
-                            -- PA TYPE 15
-        dhSignedData       [0] ContentInfo,
-                            -- Defined in CMS [8] and used only with
-                            -- Diffie-Hellman key exchange (if the
-                            -- client public value was present in the
-                            -- request).
-                            -- SignedData OID is {pkcs7 2}
-                            -- This choice MUST be supported
-                            -- by compliant implementations.
-        encKeyPack         [1] ContentInfo
-                            -- Defined in CMS [8].
-                            -- The temporary key is encrypted
-                            -- using the client public key
-                            -- key.
-                            -- EnvelopedData OID is {pkcs7 3}
-                            -- SignedReplyKeyPack, encrypted
-                            -- with the temporary key, is also
-                            -- included.
-    }
-
-    The type of the ContentInfo in the dhSignedData is SignedData.
-    Its usage is as follows:
-
-        When the Diffie-Hellman option is used, dhSignedData in
-        PA-PK-AS-REP provides authenticated Diffie-Hellman parameters
-        of the KDC.  The reply key used to encrypt part of the KDC reply
-        message is derived from the Diffie-Hellman exchange:
-
-        1.  Both the KDC and the client calculate a secret value
-            (g^ab mod p), where a is the client's private exponent and
-            b is the KDC's private exponent.
-
-        2.  Both the KDC and the client take the first N bits of this
-            secret value and convert it into a reply key.  N depends on
-            the reply key type.
-
-            a.  For example, if the reply key is DES, N=64 bits, where
-                some of the bits are replaced with parity bits, according
-                to FIPS PUB 74.
-
-            b.  As another example, if the reply key is (3-key) 3-DES,
-                N=192 bits, where some of the bits are replaced with
-                parity bits, according to FIPS PUB 74.
-
-        3.  The encapContentInfo field MUST contain the KdcDHKeyInfo as
-            defined below.
-
-            a.  The eContentType field MUST contain the OID value for
-                pkdhkeydata: iso (1) org (3) dod (6) internet (1)
-                security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2)
-
-            b.  The eContent field is data of the type KdcDHKeyInfo
-                (below).
-
-        4.  The certificates field MUST contain the certificates
-            necessary for the client to establish trust in the KDC's
-            certificate based on the list of trusted certifiers sent by
-            the client in the PA-PK-AS-REQ.  This field may be empty if
-            the client did not send to the KDC a list of trusted
-            certifiers (the trustedCertifiers field was empty, meaning
-            that the client already possesses the KDC's certificate).
-
-        5.  The signerInfos field is a SET that MUST contain at least
-            one member, since it contains the actual signature.
-
-        6.  If the client indicated acceptance of cached Diffie-Hellman
-            parameters from the KDC, and the KDC supports such an option
-            (for performance reasons), the KDC should return a zero in
-            the nonce field and include the expiration time of the
-            parameters in the dhKeyExpiration field.  If this time is
-            exceeded, the client SHOULD NOT use the reply.  If the time
-            is absent, the client SHOULD NOT use the reply and MAY
-            resubmit a request with a non-zero nonce (thus indicating
-            non-acceptance of cached Diffie-Hellman parameters).  As
-            indicated above in Section 3.2.1, Client Request, when the
-            KDC uses cached parameters, the client and the KDC MUST
-            perform key derivation (for the appropriate cryptosystem)
-            on the resulting encryption key, as specified in RFC 1510bis.
-
-    KdcDHKeyInfo ::= SEQUENCE {
-                              -- used only when utilizing Diffie-Hellman
-      subjectPublicKey      [0] BIT STRING,
-                                -- Equals public exponent (g^a mod p)
-                                -- INTEGER encoded as payload of
-                                -- BIT STRING
-      nonce                 [1] INTEGER,
-                                -- Binds response to the request
-                                -- Exception: Set to zero when KDC
-                                -- is using a cached DH value
-      dhKeyExpiration       [2] KerberosTime OPTIONAL
-                                -- Expiration time for KDC's cached
-                                -- DH value
-    }
-
-    The type of the ContentInfo in the encKeyPack is EnvelopedData.  Its
-    usage is as follows:
-
-        The EnvelopedData data type is specified in the Cryptographic
-        Message Syntax, a product of the S/MIME working group of the
-        IETF.  It contains a temporary key encrypted with the PKINIT
-        client's public key.  It also contains a signed and encrypted
-        reply key.
-
-        1.  The originatorInfo field is not required, since that
-            information may be presented in the signedData structure
-            that is encrypted within the encryptedContentInfo field.
-
-        2.  The optional unprotectedAttrs field is not required for
-            PKINIT.
-
-        3.  The recipientInfos field is a SET which MUST contain exactly
-            one member of the KeyTransRecipientInfo type for encryption
-            with a public key.
-
-            a.  The encryptedKey field (in KeyTransRecipientInfo)
-                contains the temporary key which is encrypted with the
-                PKINIT client's public key.
-
-        4.  The encryptedContentInfo field contains the signed and
-            encrypted reply key.
-
-            a.  The contentType field MUST contain the OID value for
-                id-signedData: iso (1) member-body (2) us (840)
-                rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2)
-
-            b.  The encryptedContent field is encrypted data of the CMS
-                type signedData as specified below.
-
-                i.  The encapContentInfo field MUST contains the
-                    ReplyKeyPack.
-
-                    * The eContentType field MUST contain the OID value
-                      for pkrkeydata: iso (1) org (3) dod (6) internet (1)
-                      security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3)
-
-                    * The eContent field is data of the type ReplyKeyPack
-                      (below).
-
-                ii.  The certificates field MUST contain the certificates
-                     necessary for the client to establish trust in the
-                     KDC's certificate based on the list of trusted
-                     certifiers sent by the client in the PA-PK-AS-REQ.
-                     This field may be empty if the client did not send
-                     to the KDC a list of trusted certifiers (the
-                     trustedCertifiers field was empty, meaning that the
-                     client already possesses the KDC's certificate).
-
-                iii.  The signerInfos field is a SET that MUST contain at
-                      least one member, since it contains the actual
-                      signature.
-
-    ReplyKeyPack ::= SEQUENCE {
-                              -- not used for Diffie-Hellman
-        replyKey             [0] EncryptionKey,
-                                 -- from RFC 1510bis
-                                 -- used to encrypt main reply
-                                 -- ENCTYPE is at least as strong as
-                                 -- ENCTYPE of session key
-        nonce                [1] INTEGER,
-                                 -- binds response to the request
-                                 -- must be same as the nonce
-                                 -- passed in the PKAuthenticator
-    }
-
-
-3.2.2.1. Use of transited Field
-
-    Since each certifier in the certification path of a user's
-    certificate is equivalent to a separate Kerberos realm, the name
-    of each certifier in the certificate chain MUST be added to the
-    transited field of the ticket.  The format of these realm names is
-    defined in Section 3.1 of this document.  If applicable, the
-    transit-policy-checked flag should be set in the issued ticket.
-
-
-3.2.2.2. Kerberos Names in Certificates
-
-    The KDC's certificate(s) MUST bind the public key(s) of the KDC to
-    a name derivable from the name of the realm for that KDC.  X.509
-    certificates MUST contain the principal name of the KDC (defined in
-    RFC 1510bis) as the SubjectAltName version 3 extension.  Below is
-    the definition of this version 3 extension, as specified by the
-    X.509 standard:
-
-        subjectAltName EXTENSION ::= {
-            SYNTAX GeneralNames
-            IDENTIFIED BY id-ce-subjectAltName
-        }
-
-        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
-
-        GeneralName ::= CHOICE {
-            otherName       [0] OtherName,
-            ...
-        }
-
-        OtherName ::= SEQUENCE {
-            type-id         OBJECT IDENTIFIER,
-            value           [0] EXPLICIT ANY DEFINED BY type-id
-        }
-
-    For the purpose of specifying a Kerberos principal name, the value
-    in OtherName MUST be a KerberosName, defined as follows:
-
-        KerberosName ::= SEQUENCE {
-            realm           [0] Realm,
-            principalName   [1] PrincipalName
-        }
-
-    This specific syntax is identified within subjectAltName by setting
-    the type-id in OtherName to krb5PrincipalName, where (from the
-    Kerberos specification) we have
-
-        krb5 OBJECT IDENTIFIER ::= { iso (1)
-                                     org (3)
-                                     dod (6)
-                                     internet (1)
-                                     security (5)
-                                     kerberosv5 (2) }
-
-        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
-
-    (This specification may also be used to specify a Kerberos name
-    within the user's certificate.)  The KDC's certificate may be signed
-    directly by a CA, or there may be intermediaries if the server resides
-    within a large organization, or it may be unsigned if the client
-    indicates possession (and trust) of the KDC's certificate.
-
-    Note that the KDC's principal name has the instance equal to the
-    realm, and those fields should be appropriately set in the realm
-    and principalName fields of the KerberosName.  This is the case
-    even when obtaining a cross-realm ticket using PKINIT.
-
-
-3.2.3. Client Extraction of Reply
-
-    The client then extracts the random key used to encrypt the main
-    reply.  This random key (in encPaReply) is encrypted with either the
-    client's public key or with a key derived from the DH values
-    exchanged between the client and the KDC.  The client uses this
-    random key to decrypt the main reply, and subsequently proceeds as
-    described in RFC 1510bis.
-
-3.2.4. Required Algorithms
-
-    Not all of the algorithms in the PKINIT protocol specification have
-    to be implemented in order to comply with the proposed standard.
-    Below is a list of the required algorithms:
-
-    * Diffie-Hellman public/private key pairs
-        * utilizing Diffie-Hellman ephemeral-ephemeral mode
-    * SHA1 digest and RSA for signatures
-    * SHA1 digest for the Checksum in the PKAuthenticator
-        * using Kerberos checksum type 'sha1'
-    * 3-key triple DES keys derived from the Diffie-Hellman Exchange
-    * 3-key triple DES Temporary and Reply keys
-
-4.  Logistics and Policy
-
-    This section describes a way to define the policy on the use of
-    PKINIT for each principal and request.
-
-    The KDC is not required to contain a database record for users
-    who use public key authentication.  However, if these users are
-    registered with the KDC, it is recommended that the database record
-    for these users be modified to an additional flag in the attributes
-    field to indicate that the user should authenticate using PKINIT.
-    If this flag is set and a request message does not contain the
-    PKINIT preauthentication field, then the KDC sends back as error of
-    type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
-    field of type PA-PK-AS-REQ must be included in the request.
-
-5.  Security Considerations
-
-    PKINIT raises a few security considerations, which we will address
-    in this section.
-
-    First of all, PKINIT extends the cross-realm model to the public
-    key infrastructure.  Anyone using PKINIT must be aware of how the
-    certification infrastructure they are linking to works.
-
-    Also, as in standard Kerberos, PKINIT presents the possibility of
-    interactions between different cryptosystems of varying strengths,
-    and this now includes public-key cryptosystems.  Many systems, for
-    instance, allow the use of 512-bit public keys.  Using such keys
-    to wrap data encrypted under strong conventional cryptosystems,
-    such as triple-DES, may be inappropriate.
-
-    Care should be taken in how certificates are choosen for the purposes
-    of authentication using PKINIT. Some local policies require that key
-    escrow be applied for certain certificate types. People deploying
-    PKINIT should be aware of the implications of using certificates that
-    have escrowed keys for the purposes of authentication.
-
-    As described in Section 3.2, PKINIT allows for the caching of the
-    Diffie-Hellman parameters on the KDC side, for performance reasons.
-    For similar reasons, the signed data in this case does not vary from
-    message to message, until the cached parameters expire.  Because of
-    the persistence of these parameters, the client and the KDC are to
-    use the appropriate key derivation measures (as described in RFC
-    1510bis) when using cached DH parameters.
-
-    PKINIT does not provide for a "return routability test" to prevent
-    attackers from mounting a denial of service attack on the KDC by
-    causing it to perform needless expensive cryptographic operations.
-    Strictly speaking, this is also true of base Kerberos, although the
-    potential cost is not as great in base Kerberos, because it does
-    not make use of public key cryptography.
-
-    Lastly, PKINIT calls for randomly generated keys for conventional
-    cryptosystems.  Many such systems contain systematically "weak"
-    keys.  For recommendations regarding these weak keys, see RFC
-    1510bis.
-
-6.  Transport Issues
-
-    Certificate chains can potentially grow quite large and span several
-    UDP packets; this in turn increases the probability that a Kerberos
-    message involving PKINIT extensions will be broken in transit.  In
-    light of the possibility that the Kerberos specification will
-    require KDCs to accept requests using TCP as a transport mechanism,
-    we make the same recommendation with respect to the PKINIT
-    extensions as well.
-
-7.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-    (V5).  Request for Comments 1510.
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.  September
-    1994.
-
-    [3] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-    Using Public Key Cryptography.  Symposium On Network and Distributed
-    System Security, 1997.
-
-    [4] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic
-    Commerce, July 1995.
-
-    [5] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
-    Request for Comments 2246, January 1999.
-
-    [6] B.C. Neuman, Proxy-Based Authorization and Accounting for
-    Distributed Systems.  In Proceedings of the 13th International
-    Conference on Distributed Computing Systems, May 1993.
-
-    [7] ITU-T (formerly CCITT) Information technology - Open Systems
-    Interconnection - The Directory: Authentication Framework
-    Recommendation X.509 ISO/IEC 9594-8
-
-    [8] R. Housley. Cryptographic Message Syntax.
-    draft-ietf-smime-cms-13.txt, April 1999, approved for publication
-    as RFC.
-
-    [9] PKCS #7: Cryptographic Message Syntax Standard,
-    An RSA Laboratories Technical Note Version 1.5
-    Revised November 1, 1993
-
-    [10] R. Rivest, MIT Laboratory for Computer Science and RSA Data
-    Security, Inc. A Description of the RC2(r) Encryption Algorithm
-    March 1998.
-    Request for Comments 2268.
-
-    [11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
-    Protocol (v3): UTF-8 String Representation of Distinguished Names.
-    Request for Comments 2253.
-
-    [12] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
-    Key Infrastructure, Certificate and CRL Profile, January 1999.
-    Request for Comments 2459.
-
-    [13] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-    Specifications, October 1998.  Request for Comments 2437.
-
-    [14] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.  S/MIME
-    Version 2 Certificate Handling, March 1998.  Request for
-    Comments 2312.
-
-    [15] M. Wahl, T. Howes, S. Kille.  Lightweight Directory Access
-    Protocol (v3), December 1997.  Request for Comments 2251.
-
-    [16] ITU-T (formerly CCITT) Information Processing Systems - Open
-    Systems Interconnection - Specification of Abstract Syntax Notation
-    One (ASN.1) Rec. X.680 ISO/IEC 8824-1
-
-    [17] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
-    Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
-
-8.  Acknowledgements
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-9.  Expiration Date
-
-    This draft expires March 12, 2002.
-
-10. Authors
-
-    Brian Tung
-    Clifford Neuman
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {brian, bcn}@isi.edu
-
-    Matthew Hur
-    Microsoft Corporation
-    One Microsoft Way
-    Redmond WA 98052
-    Phone: +1 425 707 3336
-    E-mail: matthur@microsoft.com
-
-    Ari Medvinsky
-    Liberate Technologies
-    2 Circle Star Way
-    San Carlos CA 94070
-    E-mail: ari@liberate.com
-
-    Sasha Medvinsky
-    Motorola, Inc.
-    6450 Sequence Drive
-    San Diego, CA 92121
-    +1 858 404 2367
-    E-mail: smedvinsky@gi.com
-
-    John Wray
-    Iris Associates, Inc.
-    5 Technology Park Dr.
-    Westford, MA 01886
-    E-mail: John_Wray@iris.com
-
-    Jonathan Trostle
-    E-mail: jtrostle@world.std.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt
deleted file mode 100644
index 174d0502f..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-17.txt
+++ /dev/null
@@ -1,805 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-17.txt                   Clifford Neuman
-Updates: RFC 1510bis                                             USC/ISI
-expires May 31, 2004                                         Matthew Hur
-                                                           Ari Medvinsky
-                                                   Microsoft Corporation
-                                                         Sasha Medvinsky
-                                                          Motorola, Inc.
-                                                               John Wray
-                                                   Iris Associates, Inc.
-                                                        Jonathan Trostle
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-0.  Status Of This Memo
-
-This document is an Internet-Draft and is in full conformance with
-all provision of Section 10 of RFC 2026.  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."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-The distribution of this memo is unlimited.  It is filed as
-draft-ietf-cat-kerberos-pk-init-17.txt and expires May 31, 2004.
-Please send comments to the authors.
-
-
-1.  Abstract
-
-This draft describes protocol extensions (hereafter called PKINIT)
-to the Kerberos protocol specification (RFC 1510bis [1]).  These
-extensions provide a method for integrating public key cryptography
-into the initial authentication exchange, by passing cryptographic
-certificates and associated authenticators in preauthentication data
-fields.
-
-
-2.  Introduction
-
-A client typically authenticates itself to a service in Kerberos
-using three distinct though related exchanges.  First, the client
-requests a ticket-granting ticket (TGT) from the Kerberos
-authentication server (AS).  Then, it uses the TGT to request a
-service ticket from the Kerberos ticket-granting server (TGS).
-Usually, the AS and TGS are integrated in a single device known as
-a Kerberos Key Distribution Center, or KDC.  (In this draft, we will
-refer to both the AS and the TGS as the KDC.) Finally, the client
-uses the service ticket to authenticate itself to the service.
-
-The advantage afforded by the TGT is that the user need only
-explicitly request a ticket and expose his credentials once.  The
-TGT and its associated session key can then be used for any
-subsequent requests.  One implication of this is that all further
-authentication is independent of the method by which the initial
-authentication was performed.  Consequently, initial authentication
-provides a convenient place to integrate public-key cryptography
-into Kerberos authentication.
-
-As defined, Kerberos authentication exchanges use symmetric-key
-cryptography, in part for performance.  (Symmetric-key cryptography
-is typically 10-100 times faster than public-key cryptography,
-depending on the public-key operations. [c])  One cost of using
-symmetric-key cryptography is that the keys must be shared, so that
-before a user can authentication himself, he must already be
-registered with the KDC.
-
-Conversely, public-key cryptography--in conjunction with an
-established certification infrastructure--permits authentication
-without prior registration.  Adding it to Kerberos allows the
-widespread use of Kerberized applications by users without requiring
-them to register first--a requirement that has no inherent security
-benefit.
-
-As noted above, a convenient and efficient place to introduce
-public-key cryptography into Kerberos is in the initial
-authentication exchange.  This document describes the methods and
-data formats for integrating public-key cryptography into Kerberos
-initial authentication.  Another document (PKCROSS) describes a
-similar protocol for Kerberos cross-realm authentication.
-
-
-3.  Extensions
-
-This section describes extensions to RFC 1510bis for supporting the
-use of public-key cryptography in the initial request for a ticket
-granting ticket (TGT).
-
-Briefly, the following changes to RFC 1510bis are proposed:
-
-    1.  If public-key authentication is indicated, the client sends
-        the user's public-key data and an authenticator in a
-        preauthentication field accompanying the usual request.
-        This authenticator is signed by the user's private
-        signature key.
-
-    2.  The KDC verifies the client's request against its own
-        policy and certification authorities.
-
-    3.  If the request passes the verification tests, the KDC
-        replies as usual, but the reply is encrypted using either:
-
-        a.  a randomly generated key, signed using the KDC's
-            signature key and encrypted using the user's encryption
-            key; or
-
-        b.  a key generated through a Diffie-Hellman exchange with
-            the client, signed using the KDC's signature key.
-
-        Any key data required by the client to obtain the encryption
-        key is returned in a preauthentication field accompanying
-        the usual reply.
-
-    4.  The client obtains the encryption key, decrypts the reply,
-        and then proceeds as usual.
-
-Section 3.1 of this document defines the necessary message formats.
-Section 3.2 describes their syntax and use in greater detail.
-Implementation of all specified formats and uses in these sections
-is REQUIRED for compliance with PKINIT.
-
-
-3.1.  Definitions
-
-
-3.1.1.  Required Algorithms
-
-[What is the current list of required algorithm? --brian]
-
-
-3.1.2.  Defined Message and Encryption Types
-
-PKINIT makes use of the following new preauthentication types:
-
-    PA-PK-AS-REQ                             TBD
-    PA-PK-AS-REP                             TBD
-
-PKINIT introduces the following new error types:
-
-    KDC_ERR_CLIENT_NOT_TRUSTED                62
-    KDC_ERR_KDC_NOT_TRUSTED                   63
-    KDC_ERR_INVALID_SIG                       64
-    KDC_ERR_KEY_TOO_WEAK                      65
-    KDC_ERR_CERTIFICATE_MISMATCH              66
-    KDC_ERR_CANT_VERIFY_CERTIFICATE           70
-    KDC_ERR_INVALID_CERTIFICATE               71
-    KDC_ERR_REVOKED_CERTIFICATE               72
-    KDC_ERR_REVOCATION_STATUS_UNKNOWN         73
-    KDC_ERR_CLIENT_NAME_MISMATCH              75
-
-PKINIT uses the following typed data types for errors:
-
-    TD-DH-PARAMETERS                         102
-    TD-TRUSTED-CERTIFIERS                    104
-    TD-CERTIFICATE-INDEX                     105
-
-PKINIT defines the following encryption types, for use in the AS-REQ
-message (to indicate acceptance of the corresponding encryption OIDs
-in PKINIT):
-
-    dsaWithSHA1-CmsOID                         9
-    md5WithRSAEncryption-CmsOID               10
-    sha1WithRSAEncryption-CmsOID              11
-    rc2CBC-EnvOID                             12
-    rsaEncryption-EnvOID   (PKCS1 v1.5)       13
-    rsaES-OAEP-ENV-OID     (PKCS1 v2.0)       14
-    des-ede3-cbc-Env-OID                      15
-
-The above encryption types are used (in PKINIT) only within CMS [8]
-structures within the PKINIT preauthentication fields.  Their use
-within Kerberos EncryptedData structures is unspecified.
-
-
-3.1.3.  Algorithm Identifiers
-
-PKINIT does not define, but does make use of, the following
-algorithm identifiers.
-
-PKINIT uses the following algorithm identifier for Diffie-Hellman
-key agreement [11]:
-
-    dhpublicnumber
-
-PKINIT uses the following signature algorithm identifiers [8, 12]:
-
-    sha-1WithRSAEncryption (RSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    id-dsa-with-sha1       (DSA with SHA1)
-
-PKINIT uses the following encryption algorithm identifiers [12] for
-encrypting the temporary key with a public key:
-
-    rsaEncryption          (PKCS1 v1.5)
-    id-RSAES-OAEP          (PKCS1 v2.0)
-
-These OIDs are not to be confused with the encryption types listed
-above.
-
-PKINIT uses the following algorithm identifiers [8] for encrypting
-the reply key with the temporary key:
-
-    des-ede3-cbc           (three-key 3DES, CBC mode)
-    rc2-cbc                (RC2, CBC mode)
-
-Again, these OIDs are not to be confused with the encryption types
-listed above.
-
-
-3.2.  PKINIT Preauthentication Syntax and Use
-
-In this section, we describe the syntax and use of the various
-preauthentication fields employed to implement PKINIT.
-
-
-3.2.1.  Client Request
-
-The initial authentication request (AS-REQ) is sent as per RFC
-1510bis, except that a preauthentication field containing data
-signed by the user's private signature key accompanies the request,
-as follows:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                    -- PAType TBD
-        signedAuthPack          [0] ContentInfo,
-                                    -- Defined in CMS.
-                                    -- Type is SignedData.
-                                    -- Content is AuthPack
-                                    -- (defined below).
-        trustedCertifiers       [1] SEQUENCE OF TrustedCAs OPTIONAL,
-                                    -- A list of CAs, trusted by
-                                    -- the client, used to certify
-                                    -- KDCs.
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL,
-                                    -- Defined in CMS.
-                                    -- Identifies a particular KDC
-                                    -- certificate, if the client
-                                    -- already has it.
-        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL,
-                                    -- May identify the user's
-                                    -- Diffie-Hellman certificate,
-                                    -- or an RSA encryption key
-                                    -- certificate.
-        ...
-    }
-
-    TrustedCAs ::= CHOICE {
-        caName                  [0] Name,
-                                    -- Fully qualified X.500 name
-                                    -- as defined in X.509 [11].
-        issuerAndSerial         [1] IssuerAndSerialNumber,
-                                    -- Identifies a specific CA
-                                    -- certificate, if the client
-                                    -- only trusts one.
-        ...
-    }
-
-[Should we even allow principalName as a choice? --brian]
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- Defined in X.509,
-                                    -- reproduced below.
-                                    -- Present only if the client
-                                    -- is using ephemeral-ephemeral
-                                    -- Diffie-Hellman.
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER,
-        ctime                   [1] KerberosTime,
-                                    -- cusec and ctime are used as
-                                    -- in RFC 1510bis, for replay
-                                    -- prevention.
-        nonce                   [2] INTEGER,
-                                    -- Binds reply to request,
-                                    -- except is zero when client
-                                    -- will accept cached
-                                    -- Diffie-Hellman parameters
-                                    -- from KDC and MUST NOT be
-                                    -- zero otherwise.
-        paChecksum              [3] Checksum,
-                                    -- Defined in RFC 1510bis.
-                                    -- Performed over KDC-REQ-BODY,
-                                    -- must be unkeyed.
-        ...
-    }
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-                                    -- As defined in X.509.
-        algorithm                   AlgorithmIdentifier,
-                                    -- Equals dhpublicnumber (see
-                                    -- AlgorithmIdentifier, below)
-                                    -- for PKINIT.
-        subjectPublicKey            BIT STRING
-                                    -- Equals public exponent
-                                    -- (INTEGER encoded as payload
-                                    -- of BIT STRING) for PKINIT.
-    }
-
-    AlgorithmIdentifier ::= SEQUENCE {
-                                    -- As defined in X.509.
-        algorithm                   OBJECT IDENTIFIER,
-                                    -- dhpublicnumber is
-                                    -- { iso (1) member-body (2)
-                                    -- US (840) ansi-x942 (10046)
-                                    -- number-type (2) 1 }
-                                    -- From RFC 2459 [11].
-        parameters                  ANY DEFINED BY algorithm OPTIONAL
-                                    -- Content is DomainParameters
-                                    -- (see below) for PKINIT.
-    }
-
-    DomainParameters ::= SEQUENCE {
-                                    -- As defined in RFC 2459.
-        p                           INTEGER,
-                                    -- p is the odd prime, equals
-                                    -- jq+1.
-        g                           INTEGER,
-                                    -- Generator.
-        q                           INTEGER,
-                                    -- Divides p-1.
-        j                           INTEGER OPTIONAL,
-                                    -- Subgroup factor.
-        validationParms             ValidationParms OPTIONAL
-    }
-
-    ValidationParms ::= SEQUENCE {
-                                    -- As defined in RFC 2459.
-        seed                        BIT STRING,
-                                    -- Seed for the system parameter
-                                    -- generation process.
-        pgenCounter                 INTEGER
-                                    -- Integer value output as part
-                                    -- of the system parameter
-                                    -- generation process.
-    }
-
-The ContentInfo in the signedAuthPack is filled out as follows:
-
-    1.  The eContent field contains data of type AuthPack.  It MUST
-        contain the pkAuthenticator, and MAY also contain the
-        user's Diffie-Hellman public value (clientPublicValue).
-
-    2.  The eContentType field MUST contain the OID value for
-        pkauthdata: { iso (1) org (3) dod (6) internet (1)
-        security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)}
-
-    3.  The signerInfos field MUST contain the signature of the
-        AuthPack.
-
-    4.  The certificates field MUST contain at least a signature
-        verification certificate chain that the KDC can use to
-        verify the signature on the AuthPack.  Additionally, the
-        client may also insert an encryption certificate chain, if
-        (for example) the client is not using ephemeral-ephemeral
-        Diffie-Hellman.
-
-    5.  If a Diffie-Hellman key is being used, the parameters SHOULD
-        be chosen from the First or Second defined Oakley Groups.
-        (See RFC 2409 [c].)
-
-    6.  The KDC may wish to use cached Diffie-Hellman parameters.
-        To indicate acceptance of caching, the client sends zero in
-        the nonce field of the pkAuthenticator.  Zero is not a valid
-        value for this field under any other circumstances.  Since
-        zero is used to indicate acceptance of cached parameters,
-        message binding in this case is performed instead using the
-        nonce in the main request.
-
-
-3.2.2.  Validation of Client Request
-
-Upon receiving the client's request, the KDC validates it.  This
-section describes the steps that the KDC MUST (unless otherwise
-noted) take in validating the request.
-
-The KDC must look for a user certificate in the signedAuthPack.
-If it cannot find one signed by a CA it trusts, it sends back an
-error of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying
-e-data for this error is a SEQUENCE OF TypedData:
-
-    TypedData ::= SEQUENCE {
-                                    -- As defined in RFC 1510bis.
-        data-type               [0] INTEGER,
-        data-value              [1] OCTET STRING
-    }
-
-For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the
-data-value is an OCTET STRING containing the DER encoding of
-
-    TrustedCertifiers ::= SEQUENCE OF Name
-
-If, while verifying the certificate chain, the KDC determines that
-the signature on one of the certificates in the signedAuthPack is
-invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
-The accompanying e-data for this error is a SEQUENCE OF TypedData,
-whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an
-OCTET STRING containing the DER encoding of the index into the
-CertificateSet field, ordered as sent by the client:
-
-    CertificateIndex ::= INTEGER
-                                    -- 0 = first certificate (in
-                                    --     order of encoding),
-                                    -- 1 = second certificate, etc.
-
-If more than one signature is invalid, the KDC sends one TypedData
-per invalid signature.
-
-The KDC MAY also check whether any of the certificates in the user's
-chain have been revoked.  If any of them have been revoked, the KDC
-returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
-attempts to determine the revocation status but is unable to do so,
-it returns an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.  In
-either case, the certificate or certificates affected are identified
-exactly as for an error of type KDC_ERR_INVALID_CERTIFICATE (see
-above).
-
-If the certificate chain is successfully validated, but the name in
-the user's certificate does not match the name given in the request,
-the KDC returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH.  There
-is no accompanying e-data for this error.
-
-Even if the chain is validated, and the names in the certificate and
-the request match, the KDC may decide not to trust the client.  For
-example, the certificate may include (or not include) an Enhanced
-Key Usage (EKU) OID in the extensions field.  As a matter of local
-policy, the KDC may decide to reject requests on the basis of the
-absence or presence of specific EKU OIDs.  In this case, the KDC
-returns an error of type KDC_ERR_CLIENT_NOT_TRUSTED.  For the
-benefit of implementors, we define a PKINIT EKU OID as follows:
-{ iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2)
-pkinit (3) pkekuoid (2) }.
-
-If the certificate chain and usage check out, but the client's
-signature on the signedAuthPack fails to verify, the KDC returns an
-error of type KDC_ERR_INVALID_SIG.  There is no accompanying e-data
-for this error.
-
-[What about the case when all this checks out but one or more
-certificates is rejected for other reasons?  For example, perhaps
-the key is too short for local policy. --DRE]
-
-The KDC must check the timestamp to ensure that the request is not
-a replay, and that the time skew falls within acceptable limits.  If
-the check fails, the KDC returns an error of type KRB_AP_ERR_REPEAT
-or KRB_AP_ERR_SKEW, respectively.
-
-Finally, if the clientPublicValue is filled in, indicating that the
-client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC
-checks to see if the parameters satisfy its policy.  If they do not,
-it returns an error of type KDC_ERR_KEY_TOO_WEAK.  The accompanying
-e-data is a SEQUENCE OF TypedData, whose data-type is
-TD-DH-PARAMETERS, and whose data-value is an OCTET STRING containing
-the DER encoding of a DomainParameters (see above), including
-appropriate Diffie-Hellman parameters with which to retry the
-request.
-
-[This makes no sense.  For example, maybe the key is too strong for
-local policy. --DRE]
-
-In order to establish authenticity of the reply, the KDC will sign
-some key data (either the random key used to encrypt the reply in
-the case of a KDCDHKeyInfo, or the Diffie-Hellman parameters used to
-generate the reply-encrypting key in the case of a ReplyKeyPack).
-The signature certificate to be used is to be selected as follows:
-
-    1.  If the client included a kdcCert field in the PA-PK-AS-REQ,
-        use the referred-to certificate, if the KDC has it.  If it
-        does not, the KDC returns an error of type
-        KDC_ERR_CERTIFICATE_MISMATCH.
-       
-    2.  Otherwise, if the client did not include a kdcCert field,
-        but did include a trustedCertifiers field, and the KDC
-        possesses a certificate issued by one of the listed
-        certifiers, use that certificate.  if it does not possess
-        one, it returns an error of type KDC_ERR_KDC_NOT_TRUSTED.
-
-    3.  Otherwise, if the client included neither a kdcCert field
-        nor a trustedCertifiers field, and the KDC has only one
-        signature certificate, use that certificate.  If it has
-        more than one certificate, it returns an error of type
-        KDC_ERR_CERTIFICATE_MISMATCH.
-
-
-3.2.3.  KDC Reply
-
-Assuming that the client's request has been properly validated, the
-KDC proceeds as per RFC 1510bis, except as follows.
-
-The user's name as represented in the AS-REP must be derived from
-the certificate provided in the client's request.  If the KDC has
-its own mapping from the name in the certificate to a Kerberos name,
-it uses that Kerberos name.
-
-Otherwise, if the certificate contains a subjectAltName extension
-with PrincipalName, it uses that name.  In this case, the realm in
-the ticket is that of the local realm (or some other realm name
-chosen by that realm).  (OID and syntax for this extension to be
-specified here.)  Otherwise, the KDC returns an error of type
-KDC_ERR_CLIENT_NAME_MISMATCH.
-
-In addition, the certifiers in the certification path of the user's
-certificate MUST be added to an authdata (to be specified at a later
-time).
-
-The AS-REP is otherwise unchanged from RFC 1510bis.  The KDC then
-encrypts the reply as usual, but not with the user's long-term key.
-Instead, it encrypts it with either a random encryption key, or a
-key derived through a Diffie-Hellman exchange.  Which is the case is
-indicated by the contents of the PA-PK-AS-REP (note tags):
-
-    PA-PK-AS-REP ::= CHOICE {
-                                    -- PAType YY (TBD)
-        dhSignedData            [0] ContentInfo,
-                                    -- Type is SignedData.
-                                    -- Content is KDCDHKeyInfo
-                                    -- (defined below).
-        encKeyPack              [1] ContentInfo,
-                                    -- Type is EnvelopedData.
-                                    -- Content is ReplyKeyPack
-                                    -- (defined below).
-        ...
-    }
-
-Note that PA-PK-AS-REP is a CHOICE: either a dhSignedData, or an
-encKeyPack, but not both.  The former contains data of type
-KDCDHKeyInfo, and is used only when the reply is encrypted using a
-Diffie-Hellman derived key:
-
-    KDCDHKeyInfo ::= SEQUENCE {
-        subjectPublicKey        [0] BIT STRING,
-                                    -- Equals public exponent
-                                    -- (g^a mod p).
-                                    -- INTEGER encoded as payload
-                                    -- of BIT STRING.
-        nonce                   [1] INTEGER,
-                                    -- Binds reply to request.
-                                    -- Exception: A value of zero
-                                    -- indicates that the KDC is
-                                    -- using cached values.
-        dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                                    -- Expiration time for KDC's
-                                    -- cached values.
-        ...
-    }
-
-The fields of the ContentInfo for dhSignedData are to be filled in
-as follows:
-
-    1.  The eContent field contains data of type KDCDHKeyInfo.
-
-    2.  The eContentType field contains the OID value for
-        pkdhkeydata: { iso (1) org (3) dod (6) internet (1)
-        security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) }
-
-    3.  The signerInfos field contains a single signerInfo, which is
-        the signature of the KDCDHKeyInfo.
-
-    4.  The certificates field contains a signature verification
-        certificate chain that the client may use to verify the
-        KDC's signature over the KDCDHKeyInfo.)  It may only be left
-        empty if the client did not include a trustedCertifiers
-        field in the PA-PK-AS-REQ, indicating that it has the KDC's
-        certificate.
-
-    5.  If the client and KDC agree to use cached parameters, the
-        KDC SHOULD return a zero in the nonce field and include the
-        expiration time of the cached values in the dhKeyExpiration
-        field.  If this time is exceeded, the client SHOULD NOT use
-        the reply.  If the time is absent, the client SHOULD NOT use
-        the reply and MAY resubmit a request with a non-zero nonce,
-        thus indicating non-acceptance of the cached parameters.
-
-The key is derived as follows: Both the KDC and the client calculate
-the value g^(ab) mod p, where a and b are the client and KDC's
-private exponents, respectively.  They both take the first N bits of
-this secret value and convert it into a reply key, where N depends
-on the key type.
-
-    1.  For example, if the key type is DES, N = 64 bits, where some
-        of the bits are replaced with parity bits, according to FIPS
-        PUB 74 [c].
-
-    2.  If the key type is (three-key) 3DES, N = 192 bits, where
-        some of the bits are replaced with parity bits, again
-        according to FIPS PUB 74.
-
-If the KDC and client are not using Diffie-Hellman, the KDC encrypts
-the reply with an encryption key, packed in the encKeyPack, which
-contains data of type ReplyKeyPack:
-
-    ReplyKeyPack ::= SEQUENCE {
-        replyKey                [0] EncryptionKey,
-                                    -- Defined in RFC 1510bis.
-                                    -- Used to encrypt main reply.
-                                    -- MUST be at least as strong as
-                                    -- enctype of session key.
-        nonce                   [1] INTEGER,
-                                    -- Binds reply to request.
-        ...
-    }
-
-[What exactly does "at least as strong" mean? --DRE]
-
-The fields of the ContentInfo for encKeyPack MUST be filled in as
-follows:
-
-    1.  The innermost data is of type SignedData.  The eContent for
-        this data is of type ReplyKeyPack.
-
-    2.  The eContentType for this data contains the OID value for
-        pkrkeydata: { iso (1) org (3) dod (6) internet (1)
-        security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) }
-
-    3.  The signerInfos field contains a single signerInfo, which is
-        the signature of the ReplyKeyPack.
-
-    4.  The certificates field contains a signature verification
-        certificate chain, which the client may use to verify the
-        KDC's signature over the ReplyKeyPack.)  It may only be left
-        empty if the client did not include a trustedCertifiers
-        field in the PA-PK-AS-REQ, indicating that it has the KDC's
-        certificate.
-
-    5.  The outer data is of type EnvelopedData.  The
-        encryptedContent for this data is the SignedData described
-        in items 1 through 4, above.
-
-    6.  The encryptedContentType for this data contains the OID
-        value for id-signedData: { iso (1) member-body (2) us (840)
-        rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }
-
-    7.  The recipientInfos field is a SET which MUST contain exactly
-        one member of type KeyTransRecipientInfo.  The encryptedKey
-        for this member contains the temporary key which is
-        encrypted using the client's public key.
-
-    8.  Neither the unprotectedAttrs field nor the originatorInfo
-        field is required for PKINIT.
-
-
-3.2.4.  Validation of KDC Reply
-
-Upon receipt of the KDC's reply, the client proceeds as follows.  If
-the PA-PK-AS-REP contains a dhSignedData, the client obtains and
-verifies the Diffie-Hellman parameters, and obtains the shared key
-as described above.  Otherwise, the message contains an encKeyPack,
-and the client decrypts and verifies the temporary encryption key.
-In either case, the client then decrypts the main reply with the
-resulting key, and then proceeds as described in RFC 1510bis.
-
-
-4.  Security Considerations
-
-PKINIT raises certain security considerations beyond those that can
-be regulated strictly in protocol definitions.  We will address them
-in this section.
-
-PKINIT extends the cross-realm model to the public-key
-infrastructure.  Anyone using PKINIT must be aware of how the
-certification infrastructure they are linking to works.
-
-Also, as in standard Kerberos, PKINIT presents the possibility of
-interactions between cryptosystems of varying strengths, and this
-now includes public-key cryptosystems.  Many systems, for example,
-allow the use of 512-bit public keys.  Using such keys to wrap data
-encrypted under strong conventional cryptosystems, such as 3DES, may
-be inappropriate.
-
-PKINIT calls for randomly generated keys for conventional
-cryptosystems.  Many such systems contain systematically "weak"
-keys.  For recommendations regarding these weak keys, see RFC
-1510bis.
-
-Care should be taken in how certificates are chosen for the purposes
-of authentication using PKINIT.  Some local policies may require
-that key escrow be applied for certain certificate types.  People
-deploying PKINIT should be aware of the implications of using
-certificates that have escrowed keys for the purposes of
-authentication.
-
-PKINIT does not provide for a "return routability" test to prevent
-attackers from mounting a denial-of-service attack on the KDC by
-causing it to perform unnecessary and expensive public-key
-operations.  Strictly speaking, this is also true of standard
-Kerberos, although the potential cost is not as great, because
-standard Kerberos does not make use of public-key cryptography.
-
-
-5.  Acknowledgements
-
-Some of the ideas on which this proposal is based arose during
-discussions over several years between members of the SAAG, the IETF
-CAT working group, and the PSRG, regarding integration of Kerberos
-and SPX.  Some ideas have also been drawn from the DASS system.
-These changes are by no means endorsed by these groups.  This is an
-attempt to revive some of the goals of those groups, and this
-proposal approaches those goals primarily from the Kerberos
-perspective.  Lastly, comments from groups working on similar ideas
-in DCE have been invaluable.
-
-
-6.  Expiration Date
-
-This draft expires May 31, 2004.
-
-
-7.  Bibliography
-
-[1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-(V5).  Request for Comments 1510.
-
-[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-for Computer Networks, IEEE Communications, 32(9):33-38.  September
-1994.
-
-[3] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-Using Public Key Cryptography.  Symposium On Network and Distributed
-System Security, 1997.
-
-[4] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
-Protocol.  In Proceedings of the USENIX Workshop on Electronic
-Commerce, July 1995.
-
-[5] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0.  Request
-for Comments 2246, January 1999.
-
-[6] B.C. Neuman, Proxy-Based Authorization and Accounting for
-Distributed Systems.  In Proceedings of the 13th International
-Conference on Distributed Computing Systems, May 1993.
-
-[7] ITU-T (formerly CCITT) Information technology - Open Systems
-Interconnection - The Directory: Authentication Framework
-Recommendation X.509 ISO/IEC 9594-8
-
-[8] R. Housley. Cryptographic Message Syntax.
-draft-ietf-smime-cms-13.txt, April 1999, approved for publication as
-RFC.
-
-[9] PKCS #7: Cryptographic Message Syntax Standard. An RSA
-Laboratories Technical Note Version 1.5. Revised November 1, 1993
-
-[10] R. Rivest, MIT Laboratory for Computer Science and RSA Data
-Security, Inc. A Description of the RC2(r) Encryption Algorithm.
-March 1998.  Request for Comments 2268.
-
-[11] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
-Key Infrastructure, Certificate and CRL Profile, January 1999.
-Request for Comments 2459.
-
-[12] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-Specifications, October 1998.  Request for Comments 2437.
-
-[13] ITU-T (formerly CCITT) Information Processing Systems - Open
-Systems Interconnection - Specification of Abstract Syntax Notation
-One (ASN.1) Rec. X.680 ISO/IEC 8824-1
-
-[14] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
-Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
-
-
-8.  Authors
-
-Brian Tung
-Clifford Neuman
-USC Information Sciences Institute
-4676 Admiralty Way Suite 1001
-Marina del Rey CA 90292-6695
-Phone: +1 310 822 1511
-E-mail: {brian,bcn}@isi.edu
-
-Matthew Hur
-Ari Medvinsky
-Microsoft Corporation
-One Microsoft Way
-Redmond WA 98052
-Phone: +1 425 707 3336
-E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
-
-Sasha Medvinsky
-Motorola, Inc.
-6450 Sequence Drive
-San Diego, CA 92121
-+1 858 404 2367
-E-mail: smedvinsky@motorola.com
-
-John Wray
-Iris Associates, Inc.
-5 Technology Park Dr.
-Westford, MA 01886
-E-mail: John_Wray@iris.com
-
-Jonathan Trostle
-E-mail: jtrostle@world.std.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-18.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-18.txt
deleted file mode 100644
index f3c795f28..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-18.txt
+++ /dev/null
@@ -1,893 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-18.txt                   Clifford Neuman
-Updates: RFC 1510bis                                             USC/ISI
-expires August 20, 2004                                      Matthew Hur
-                                                           Ari Medvinsky
-                                                   Microsoft Corporation
-                                                         Sasha Medvinsky
-                                                          Motorola, Inc.
-                                                               John Wray
-                                                   Iris Associates, Inc.
-                                                        Jonathan Trostle
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-0.  Status Of This Memo
-
-This document is an Internet-Draft and is in full conformance with
-all provision of Section 10 of RFC 2026.  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."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-The distribution of this memo is unlimited.  It is filed as
-draft-ietf-cat-kerberos-pk-init-18.txt and expires August 20, 2004.
-Please send comments to the authors.
-
-
-1.  Abstract
-
-This draft describes protocol extensions (hereafter called PKINIT)
-to the Kerberos protocol specification (RFC 1510bis [1]).  These
-extensions provide a method for integrating public key cryptography
-into the initial authentication exchange, by passing cryptographic
-certificates and associated authenticators in preauthentication data
-fields.
-
-
-2.  Introduction
-
-A client typically authenticates itself to a service in Kerberos
-using three distinct though related exchanges.  First, the client
-requests a ticket-granting ticket (TGT) from the Kerberos
-authentication server (AS).  Then, it uses the TGT to request a
-service ticket from the Kerberos ticket-granting server (TGS).
-Usually, the AS and TGS are integrated in a single device known as
-a Kerberos Key Distribution Center, or KDC.  (In this draft, we will
-refer to both the AS and the TGS as the KDC.) Finally, the client
-uses the service ticket to authenticate itself to the service.
-
-The advantage afforded by the TGT is that the user need only
-explicitly request a ticket and expose his credentials once.  The
-TGT and its associated session key can then be used for any
-subsequent requests.  One implication of this is that all further
-authentication is independent of the method by which the initial
-authentication was performed.  Consequently, initial authentication
-provides a convenient place to integrate public-key cryptography
-into Kerberos authentication.
-
-As defined, Kerberos authentication exchanges use symmetric-key
-cryptography, in part for performance.  (Symmetric-key cryptography
-is typically 10-100 times faster than public-key cryptography,
-depending on the public-key operations. [cite])  One cost of using
-symmetric-key cryptography is that the keys must be shared, so that
-before a user can authentication himself, he must already be
-registered with the KDC.
-
-Conversely, public-key cryptography--in conjunction with an
-established certification infrastructure--permits authentication
-without prior registration.  Adding it to Kerberos allows the
-widespread use of Kerberized applications by users without requiring
-them to register first--a requirement that has no inherent security
-benefit.
-
-As noted above, a convenient and efficient place to introduce
-public-key cryptography into Kerberos is in the initial
-authentication exchange.  This document describes the methods and
-data formats for integrating public-key cryptography into Kerberos
-initial authentication.  Another document (PKCROSS) describes a
-similar protocol for Kerberos cross-realm authentication.
-
-
-3.  Extensions
-
-This section describes extensions to RFC 1510bis for supporting the
-use of public-key cryptography in the initial request for a ticket
-granting ticket (TGT).
-
-Briefly, the following changes to RFC 1510bis are proposed:
-
-    1.  If public-key authentication is indicated, the client sends
-        the user's public-key data and an authenticator in a
-        preauthentication field accompanying the usual request.
-        This authenticator is signed by the user's private
-        signature key.
-
-    2.  The KDC verifies the client's request against its own
-        policy and certification authorities.
-
-    3.  If the request passes the verification tests, the KDC
-        replies as usual, but the reply is encrypted using either:
-
-        a.  a randomly generated key, signed using the KDC's
-            signature key and encrypted using the user's encryption
-            key; or
-
-        b.  a key generated through a Diffie-Hellman exchange with
-            the client, signed using the KDC's signature key.
-
-        Any key data required by the client to obtain the encryption
-        key is returned in a preauthentication field accompanying
-        the usual reply.
-
-    4.  The client obtains the encryption key, decrypts the reply,
-        and then proceeds as usual.
-
-Section 3.1 of this document defines the necessary message formats.
-Section 3.2 describes their syntax and use in greater detail.
-Implementation of all specified formats and uses in these sections
-is REQUIRED for compliance with PKINIT.
-
-
-3.1.  Definitions
-
-
-3.1.1.  Required Algorithms
-
-At minimum, PKINIT must be able to use the following algorithms:
-
-    Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype
-      (as required by clarifications).
-    Signature algorithm: SHA-1 digest and RSA.
-    Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
-      with a non-zero nonce.
-    Unkeyed checksum type for the paChecksum member of
-      PKAuthenticator: SHA1 (unkeyed).
-
-
-3.1.2.  Defined Message and Encryption Types
-
-PKINIT makes use of the following new preauthentication types:
-
-    PA-PK-AS-REQ                             TBD
-    PA-PK-AS-REP                             TBD
-    PA-PK-OCSP-REQ                           TBD
-    PA-PK-OCSP-REP                           TBD
-
-PKINIT also makes use of the following new authorization data type:
-
-    AD-INITIAL-VERIFIED-CAS                  TBD
-
-PKINIT introduces the following new error types:
-
-    KDC_ERR_CLIENT_NOT_TRUSTED                62
-    KDC_ERR_KDC_NOT_TRUSTED                   63
-    KDC_ERR_INVALID_SIG                       64
-    KDC_ERR_KEY_TOO_WEAK                      65
-    KDC_ERR_CERTIFICATE_MISMATCH              66
-    KDC_ERR_CANT_VERIFY_CERTIFICATE           70
-    KDC_ERR_INVALID_CERTIFICATE               71
-    KDC_ERR_REVOKED_CERTIFICATE               72
-    KDC_ERR_REVOCATION_STATUS_UNKNOWN         73
-    KDC_ERR_CLIENT_NAME_MISMATCH              75
-
-PKINIT uses the following typed data types for errors:
-
-    TD-DH-PARAMETERS                         102
-    TD-TRUSTED-CERTIFIERS                    104
-    TD-CERTIFICATE-INDEX                     105
-
-PKINIT defines the following encryption types, for use in the AS-REQ
-message (to indicate acceptance of the corresponding encryption OIDs
-in PKINIT):
-
-    dsaWithSHA1-CmsOID                         9
-    md5WithRSAEncryption-CmsOID               10
-    sha1WithRSAEncryption-CmsOID              11
-    rc2CBC-EnvOID                             12
-    rsaEncryption-EnvOID   (PKCS1 v1.5)       13
-    rsaES-OAEP-ENV-OID     (PKCS1 v2.0)       14
-    des-ede3-cbc-Env-OID                      15
-
-The above encryption types are used (in PKINIT) only within CMS [8]
-structures within the PKINIT preauthentication fields.  Their use
-within Kerberos EncryptedData structures is unspecified.
-
-
-3.1.3.  Algorithm Identifiers
-
-PKINIT does not define, but does make use of, the following
-algorithm identifiers.
-
-PKINIT uses the following algorithm identifier for Diffie-Hellman
-key agreement [11]:
-
-    dhpublicnumber
-
-PKINIT uses the following signature algorithm identifiers [8, 12]:
-
-    sha-1WithRSAEncryption (RSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    id-dsa-with-sha1       (DSA with SHA1)
-
-PKINIT uses the following encryption algorithm identifiers [12] for
-encrypting the temporary key with a public key:
-
-    rsaEncryption          (PKCS1 v1.5)
-    id-RSAES-OAEP          (PKCS1 v2.0)
-
-These OIDs are not to be confused with the encryption types listed
-above.
-
-PKINIT uses the following algorithm identifiers [8] for encrypting
-the reply key with the temporary key:
-
-    des-ede3-cbc           (three-key 3DES, CBC mode)
-    rc2-cbc                (RC2, CBC mode)
-
-Again, these OIDs are not to be confused with the encryption types
-listed above.
-
-
-3.2.  PKINIT Preauthentication Syntax and Use
-
-In this section, we describe the syntax and use of the various
-preauthentication fields employed to implement PKINIT.
-
-
-3.2.1.  Client Request
-
-The initial authentication request (AS-REQ) is sent as per RFC
-1510bis, except that a preauthentication field containing data
-signed by the user's private signature key accompanies the request,
-as follows:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                    -- PAType TBD
-        signedAuthPack          [0] ContentInfo,
-                                    -- Defined in CMS.
-                                    -- Type is SignedData.
-                                    -- Content is AuthPack
-                                    -- (defined below).
-        trustedCertifiers       [1] SEQUENCE OF TrustedCAs OPTIONAL,
-                                    -- A list of CAs, trusted by
-                                    -- the client, used to certify
-                                    -- KDCs.
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL,
-                                    -- Defined in CMS.
-                                    -- Identifies a particular KDC
-                                    -- certificate, if the client
-                                    -- already has it.
-        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL,
-                                    -- May identify the user's
-                                    -- Diffie-Hellman certificate,
-                                    -- or an RSA encryption key
-                                    -- certificate.
-        ...
-    }
-
-    TrustedCAs ::= CHOICE {
-        caName                  [0] Name,
-                                    -- Fully qualified X.500 name
-                                    -- as defined in X.509 [11].
-        issuerAndSerial         [1] IssuerAndSerialNumber,
-                                    -- Identifies a specific CA
-                                    -- certificate, if the client
-                                    -- only trusts one.
-        ...
-    }
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- Defined in X.509,
-                                    -- reproduced below.
-                                    -- Present only if the client
-                                    -- is using ephemeral-ephemeral
-                                    -- Diffie-Hellman.
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER,
-        ctime                   [1] KerberosTime,
-                                    -- cusec and ctime are used as
-                                    -- in RFC 1510bis, for replay
-                                    -- prevention.
-        nonce                   [2] INTEGER,
-                                    -- Binds reply to request,
-                                    -- except is zero when client
-                                    -- will accept cached
-                                    -- Diffie-Hellman parameters
-                                    -- from KDC and MUST NOT be
-                                    -- zero otherwise.
-                                    -- MUST be < 2^32.
-        paChecksum              [3] Checksum,
-                                    -- Defined in [15].
-                                    -- Performed over KDC-REQ-BODY,
-                                    -- must be unkeyed.
-        ...
-    }
-
-    IMPORTS
-        -- from X.509
-        SubjectPublicKeyInfo, AlgorithmIdentifier, DomainParameters,
-          ValidationParms
-            FROM PKIX1Explicit88 { iso (1) identified-organization (3)
-              dod (6) internet (1) security (5) mechanisms (5)
-              pkix (7) id-mod (0) id-pkix1-explicit-88 (1) }
-
-The ContentInfo in the signedAuthPack is filled out as follows:
-
-    1.  The eContent field contains data of type AuthPack.  It MUST
-        contain the pkAuthenticator, and MAY also contain the
-        user's Diffie-Hellman public value (clientPublicValue).
-
-    2.  The eContentType field MUST contain the OID value for
-        pkauthdata: { iso (1) org (3) dod (6) internet (1)
-        security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)}
-
-    3.  The signerInfos field MUST contain the signature of the
-        AuthPack.
-
-    4.  The certificates field MUST contain at least a signature
-        verification certificate chain that the KDC can use to
-        verify the signature on the AuthPack.  Additionally, the
-        client may also insert an encryption certificate chain, if
-        (for example) the client is not using ephemeral-ephemeral
-        Diffie-Hellman.
-
-    5.  If a Diffie-Hellman key is being used, the parameters SHOULD
-        be chosen from the First or Second defined Oakley Groups.
-        (See RFC 2409 [c].)
-
-    6.  The KDC may wish to use cached Diffie-Hellman parameters.
-        To indicate acceptance of caching, the client sends zero in
-        the nonce field of the pkAuthenticator.  Zero is not a valid
-        value for this field under any other circumstances.  Since
-        zero is used to indicate acceptance of cached parameters,
-        message binding in this case is performed instead using the
-        nonce in the main request.
-
-
-3.2.2.  Validation of Client Request
-
-Upon receiving the client's request, the KDC validates it.  This
-section describes the steps that the KDC MUST (unless otherwise
-noted) take in validating the request.
-
-The KDC must look for a user certificate in the signedAuthPack.
-If it cannot find one signed by a CA it trusts, it sends back an
-error of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying
-e-data for this error is a SEQUENCE OF TypedData:
-
-    TypedData ::= SEQUENCE {
-                                    -- As defined in RFC 1510bis.
-        data-type               [0] INTEGER,
-        data-value              [1] OCTET STRING
-    }
-
-For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the
-data-value is an OCTET STRING containing the DER encoding of
-
-    TrustedCertifiers ::= SEQUENCE OF Name
-
-If, while verifying the certificate chain, the KDC determines that
-the signature on one of the certificates in the signedAuthPack is
-invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
-The accompanying e-data for this error is a SEQUENCE OF TypedData,
-whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an
-OCTET STRING containing the DER encoding of the index into the
-CertificateSet field, ordered as sent by the client:
-
-    CertificateIndex ::= INTEGER
-                                    -- 0 = first certificate (in
-                                    --     order of encoding),
-                                    -- 1 = second certificate, etc.
-
-If more than one signature is invalid, the KDC sends one TypedData
-per invalid signature.
-
-The KDC MAY also check whether any of the certificates in the user's
-chain have been revoked.  If any of them have been revoked, the KDC
-returns an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
-attempts to determine the revocation status but is unable to do so,
-it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
-The certificate or certificates affected are identified exactly as
-for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
-
-If the certificate chain is successfully validated, but the user's
-certificate is not authorized to the client's principal name in the
-AS-REQ (when present), the KDC MUST return an error of type
-KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
-this error.
-
-Even if the chain is validated, and the names in the certificate and
-the request match, the KDC may decide not to trust the client.  For
-example, the certificate may include (or not include) an Enhanced
-Key Usage (EKU) OID in the extensions field.  As a matter of local
-policy, the KDC may decide to reject requests on the basis of the
-absence or presence of specific EKU OIDs.  In this case, the KDC
-returns an error of type KDC_ERR_CLIENT_NOT_TRUSTED.  For the
-benefit of implementors, we define a PKINIT EKU OID as follows:
-{ iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2)
-pkinit (3) pkekuoid (4) }.
-
-If the certificate chain and usage check out, but the client's
-signature on the signedAuthPack fails to verify, the KDC returns an
-error of type KDC_ERR_INVALID_SIG.  There is no accompanying e-data
-for this error.
-
-The KDC must check the timestamp to ensure that the request is not
-a replay, and that the time skew falls within acceptable limits.
-The recommendations for ordinary (that is, non-PKINIT) skew times
-apply here.  If the check fails, the KDC returns an error of type
-KRB_AP_ERR_REPEAT or KRB_AP_ERR_SKEW, respectively.
-
-Finally, if the clientPublicValue is filled in, indicating that the
-client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC
-checks to see if the parameters satisfy its policy.  If they do not,
-it returns an error of type KDC_ERR_KEY_TOO_WEAK.  The accompanying
-e-data is a SEQUENCE OF TypedData, whose data-type is
-TD-DH-PARAMETERS, and whose data-value is an OCTET STRING containing
-the DER encoding of a DomainParameters (see above), including
-appropriate Diffie-Hellman parameters with which to retry the
-request.
-
-In order to establish authenticity of the reply, the KDC will sign
-some key data (either the random key used to encrypt the reply in
-the case of a KDCDHKeyInfo, or the Diffie-Hellman parameters used to
-generate the reply-encrypting key in the case of a ReplyKeyPack).
-The signature certificate to be used is to be selected as follows:
-
-    1.  If the client included a kdcCert field in the PA-PK-AS-REQ,
-        use the referred-to certificate, if the KDC has it.  If it
-        does not, the KDC returns an error of type
-        KDC_ERR_CERTIFICATE_MISMATCH.
-       
-    2.  Otherwise, if the client did not include a kdcCert field,
-        but did include a trustedCertifiers field, and the KDC
-        possesses a certificate issued by one of the listed
-        certifiers, use that certificate.  if it does not possess
-        one, it returns an error of type KDC_ERR_KDC_NOT_TRUSTED.
-
-    3.  Otherwise, if the client included neither a kdcCert field
-        nor a trustedCertifiers field, and the KDC has only one
-        signature certificate, use that certificate.  If it has
-        more than one certificate, it returns an error of type
-        KDC_ERR_CERTIFICATE_MISMATCH.
-
-
-3.2.3.  KDC Reply
-
-Assuming that the client's request has been properly validated, the
-KDC proceeds as per RFC 1510bis, except as follows.
-
-The user's name as represented in the AS-REP must be derived from
-the certificate provided in the client's request.  If the KDC has
-its own mapping from the name in the certificate to a Kerberos name,
-it uses that Kerberos name.
-
-Otherwise, if the certificate contains a SubjectAltName extension
-with a KerberosName in the otherName field, it uses that name.
-
-    AnotherName ::= SEQUENCE {
-                                    -- Defined in [11].
-        type-id                     OBJECT IDENTIFIER,
-        value                   [0] EXPLICIT ANY DEFINED BY type-id
-    }
-
-    KerberosName ::= SEQUENCE {
-        realm                   [0] Realm,
-        principalName           [1] PrincipalName
-    }
-
-with OID
-
-    krb5 OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6) internet (1)
-                                 security (5) kerberosv5 (2) }
-
-    krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
-
-In this case, the realm in the ticket is that of the local realm (or
-some other realm name chosen by that realm).  Otherwise, the KDC
-returns an error of type KDC_ERR_CLIENT_NAME_MISMATCH.
-
-In addition, the KDC MUST set the initial flag in the issued TGT
-*and* add an authorization data of type AD-INITIAL-VERIFIED-CAS to
-the TGT.  The value is an OCTET STRING containing the DER encoding
-of InitialVerifiedCAs:
-
-    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
-        ca                      [0] Name,
-        ocspValidated           [1] BOOLEAN,
-        ...
-    }
-
-The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-containers if the list of CAs satisfies the KDC's realm's policy.
-(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.)
-Furthermore, any TGS must copy such authorization data from tickets
-used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
-including the AD-IF-RELEVANT container, if present.
-
-AP servers that understand this authorization data type SHOULD apply
-local policy to determine whether a given ticket bearing such a type
-(not contained within an AD-IF-RELEVANT container) is acceptable.
-(This corresponds to the AP server checking the transited field when
-the TRANSITED-POLICY-CHECKED flag has not been set.)  If such a data
-type *is* contained within an AD-IF-RELEVANT container, AP servers
-still MAY apply local policy to determine whether the authorization
-data is acceptable.
-
-The AS-REP is otherwise unchanged from RFC 1510bis.  The KDC then
-encrypts the reply as usual, but not with the user's long-term key.
-Instead, it encrypts it with either a random encryption key, or a
-key derived from a Diffie-Hellman exchange.  Which is the case is
-indicated by the contents of the PA-PK-AS-REP (note tags):
-
-    PA-PK-AS-REP ::= CHOICE {
-                                    -- PAType YY (TBD)
-        dhSignedData            [0] ContentInfo,
-                                    -- Type is SignedData.
-                                    -- Content is KDCDHKeyInfo
-                                    -- (defined below).
-        encKeyPack              [1] ContentInfo,
-                                    -- Type is EnvelopedData.
-                                    -- Content is ReplyKeyPack
-                                    -- (defined below).
-        ...
-    }
-
-Note that PA-PK-AS-REP is a CHOICE: either a dhSignedData, or an
-encKeyPack, but not both.  The former contains data of type
-KDCDHKeyInfo, and is used only when the reply is encrypted using a
-Diffie-Hellman derived key:
-
-    KDCDHKeyInfo ::= SEQUENCE {
-        subjectPublicKey        [0] BIT STRING,
-                                    -- Equals public exponent
-                                    -- (g^a mod p).
-                                    -- INTEGER encoded as payload
-                                    -- of BIT STRING.
-        nonce                   [1] INTEGER,
-                                    -- Binds reply to request.
-                                    -- Exception: A value of zero
-                                    -- indicates that the KDC is
-                                    -- using cached values.
-        dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                                    -- Expiration time for KDC's
-                                    -- cached values.
-        ...
-    }
-
-The fields of the ContentInfo for dhSignedData are to be filled in
-as follows:
-
-    1.  The eContent field contains data of type KDCDHKeyInfo.
-
-    2.  The eContentType field contains the OID value for
-        pkdhkeydata: { iso (1) org (3) dod (6) internet (1)
-        security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) }
-
-    3.  The signerInfos field contains a single signerInfo, which is
-        the signature of the KDCDHKeyInfo.
-
-    4.  The certificates field contains a signature verification
-        certificate chain that the client may use to verify the
-        KDC's signature over the KDCDHKeyInfo.)  It may only be left
-        empty if the client did not include a trustedCertifiers
-        field in the PA-PK-AS-REQ, indicating that it has the KDC's
-        certificate.
-
-    5.  If the client and KDC agree to use cached parameters, the
-        KDC SHOULD return a zero in the nonce field and include the
-        expiration time of the cached values in the dhKeyExpiration
-        field.  If this time is exceeded, the client SHOULD NOT use
-        the reply.  If the time is absent, the client SHOULD NOT use
-        the reply and MAY resubmit a request with a non-zero nonce,
-        thus indicating non-acceptance of the cached parameters.
-
-The key is derived as follows: Both the KDC and the client calculate
-the value g^(ab) mod p, where a and b are the client's and KDC's
-private exponents, respectively.  They both take the first k bits of
-this secret value as a key generation seed, where the parameter k
-(the size of the seed) is dependent on the selected key type, as
-specified in the Kerberos crypto draft [15].  The seed is then
-converted into a protocol key by applying to it a random-to-key
-function, which is also dependent on key type.
-
-The protocol key is used to derive the integrity key Ki and the
-encryption key Ke according to [15].  Ke and Ki are used to generate
-the encrypted part of the AS-REP.
-
-    1.  For example, if the encryption type is DES with MD4, k = 64
-        bits and the random-to-key function consists of replacing
-        some of the bits with parity bits, according to FIPS PUB 74
-        [cite].  In this case, the key derivation function for Ke is
-        the identity function, and Ki is not needed because the
-        checksum in the EncryptedData is not keyed.
-
-    2.  If the encryption type is three-key 3DES with HMAC-SHA1,
-        k = 168 bits and the random-to-key function is
-        DES3random-to-key as defined in [15].  This function inserts
-        parity bits to create a 192-bit 3DES protocol key that is
-        compliant with FIPS PUB 74 [cite].  Ke and Ki are derived
-        from this protocol key according to [15] with the key usage
-        number set to 3 (AS-REP encrypted part).
-
-If the KDC and client are not using Diffie-Hellman, the KDC encrypts
-the reply with an encryption key, packed in the encKeyPack, which
-contains data of type ReplyKeyPack:
-
-    ReplyKeyPack ::= SEQUENCE {
-        replyKey                [0] EncryptionKey,
-                                    -- Defined in RFC 1510bis.
-                                    -- Used to encrypt main reply.
-                                    -- MUST be at least as large
-                                    -- as session key.
-        nonce                   [1] INTEGER,
-                                    -- Binds reply to request.
-                                    -- MUST be < 2^32.
-        ...
-    }
-
-The fields of the ContentInfo for encKeyPack MUST be filled in as
-follows:
-
-    1.  The innermost data is of type SignedData.  The eContent for
-        this data is of type ReplyKeyPack.
-
-    2.  The eContentType for this data contains the OID value for
-        pkrkeydata: { iso (1) org (3) dod (6) internet (1)
-        security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) }
-
-    3.  The signerInfos field contains a single signerInfo, which is
-        the signature of the ReplyKeyPack.
-
-    4.  The certificates field contains a signature verification
-        certificate chain, which the client may use to verify the
-        KDC's signature over the ReplyKeyPack.)  It may only be left
-        empty if the client did not include a trustedCertifiers
-        field in the PA-PK-AS-REQ, indicating that it has the KDC's
-        certificate.
-
-    5.  The outer data is of type EnvelopedData.  The
-        encryptedContent for this data is the SignedData described
-        in items 1 through 4, above.
-
-    6.  The encryptedContentType for this data contains the OID
-        value for id-signedData: { iso (1) member-body (2) us (840)
-        rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }
-
-    7.  The recipientInfos field is a SET which MUST contain exactly
-        one member of type KeyTransRecipientInfo.  The encryptedKey
-        for this member contains the temporary key which is
-        encrypted using the client's public key.
-
-    8.  Neither the unprotectedAttrs field nor the originatorInfo
-        field is required for PKINIT.
-
-
-3.2.4.  Validation of KDC Reply
-
-Upon receipt of the KDC's reply, the client proceeds as follows.  If
-the PA-PK-AS-REP contains a dhSignedData, the client obtains and
-verifies the Diffie-Hellman parameters, and obtains the shared key
-as described above.  Otherwise, the message contains an encKeyPack,
-and the client decrypts and verifies the temporary encryption key.
-In either case, the client then decrypts the main reply with the
-resulting key, and then proceeds as described in RFC 1510bis.
-
-
-3.2.5.  Support for OCSP
-
-OCSP (Online Certificate Status Protocol) [cite] allows the use of
-on-line requests for a client or server to determine the validity of
-each other's certificates.  It is particularly useful for clients
-authenticating each other across a constrained network.  These
-clients will not have to download the entire CRL to check for the
-validity of the KDC's certificate.
-
-In these cases, the KDC generally has better connectivity to the
-OCSP server, and it therefore processes the OCSP request and
-response and sends the results to the client.  The changes proposed
-in this section allow a client to request an OCSP response from the
-KDC when using PKINIT.  This is similar to the way that OCSP is
-handled in [cite].
-
-OCSP support is provided in PKINIT through the use of additional
-preauthentication data.  The following new preauthentication types
-are defined:
-
-    PA-PK-OCSP-REQ ::= SEQUENCE {
-                                    -- PAType TBD
-        responderIDList         [0] SEQUENCE of ResponderID OPTIONAL,
-                                    -- ResponderID is a DER-encoded
-                                    -- ASN.1 type defined in [cite]
-        requestExtensions       [1] Extensions OPTIONAL
-                                    -- Extensions is a DER-encoded
-                                    -- ASN.1 type defined in [cite]
-    }
-
-    PA-PK-OCSP-REP ::= SEQUENCE of OCSPResponse
-                                    -- OCSPResponse is a DER-encoded
-                                    -- ASN.1 type defined in [cite]
-
-A KDC that receives a PA-PK-OCSP-REQ MAY send a PA-PK-OCSP-REP.
-KDCs MUST NOT send a PA-PK-OCSP-REP if they do not first receive a
-PA-PK-OCSP-REQ from the client.  The KDC may either send a cached
-OCSP response or send an on-line request to the OCSP server.
-
-When using OCSP, the response is signed by the OCSP server, which is
-trusted by the client.  Depending on local policy, further
-verification of the validity of the OCSP server may need to be done.
-
-
-4.  Security Considerations
-
-PKINIT raises certain security considerations beyond those that can
-be regulated strictly in protocol definitions.  We will address them
-in this section.
-
-PKINIT extends the cross-realm model to the public-key
-infrastructure.  Anyone using PKINIT must be aware of how the
-certification infrastructure they are linking to works.
-
-Also, as in standard Kerberos, PKINIT presents the possibility of
-interactions between cryptosystems of varying strengths, and this
-now includes public-key cryptosystems.  Many systems, for example,
-allow the use of 512-bit public keys.  Using such keys to wrap data
-encrypted under strong conventional cryptosystems, such as 3DES, may
-be inappropriate.
-
-PKINIT calls for randomly generated keys for conventional
-cryptosystems.  Many such systems contain systematically "weak"
-keys.  For recommendations regarding these weak keys, see RFC
-1510bis.
-
-PKINIT allows the use of a zero nonce in the PKAuthenticator when
-cached Diffie-Hellman parameters are used.  In this case, message
-binding is performed using the nonce in the main request in the same
-way as it is done for ordinary (that is, non-PKINIT) AS-REQs.  The
-nonce field in the KDC request body is signed through the checksum
-in the PKAuthenticator, and it therefore cryptographically binds the
-AS-REQ with the AS-REP.  If cached parameters are also used on the
-client side, the generated session key will be the same, and a
-compromised session key could lead to the compromise of future
-cached exchanges.  It is desirable to limit the use of cached
-parameters to just the KDC, in order to eliminate this exposure.
-
-Care should be taken in how certificates are chosen for the purposes
-of authentication using PKINIT.  Some local policies may require
-that key escrow be applied for certain certificate types.  People
-deploying PKINIT should be aware of the implications of using
-certificates that have escrowed keys for the purposes of
-authentication.
-
-PKINIT does not provide for a "return routability" test to prevent
-attackers from mounting a denial-of-service attack on the KDC by
-causing it to perform unnecessary and expensive public-key
-operations.  Strictly speaking, this is also true of standard
-Kerberos, although the potential cost is not as great, because
-standard Kerberos does not make use of public-key cryptography.
-It might be possible to address this using a preauthentication field
-as part of the proposed Kerberos preauthenticatino framework.
-
-
-5.  Acknowledgements
-
-Some of the ideas on which this proposal is based arose during
-discussions over several years between members of the SAAG, the IETF
-CAT working group, and the PSRG, regarding integration of Kerberos
-and SPX.  Some ideas have also been drawn from the DASS system.
-These changes are by no means endorsed by these groups.  This is an
-attempt to revive some of the goals of those groups, and this
-proposal approaches those goals primarily from the Kerberos
-perspective.  Lastly, comments from groups working on similar ideas
-in DCE have been invaluable.
-
-
-6.  Expiration Date
-
-This draft expires August 20, 2004.
-
-
-7.  Bibliography
-
-[1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-(V5).  Request for Comments 1510.
-
-[2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-for Computer Networks, IEEE Communications, 32(9):33-38.  September
-1994.
-
-[3] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-Using Public Key Cryptography.  Symposium On Network and Distributed
-System Security, 1997.
-
-[4] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
-Protocol.  In Proceedings of the USENIX Workshop on Electronic
-Commerce, July 1995.
-
-[5] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0.  Request
-for Comments 2246, January 1999.
-
-[6] B.C. Neuman, Proxy-Based Authorization and Accounting for
-Distributed Systems.  In Proceedings of the 13th International
-Conference on Distributed Computing Systems, May 1993.
-
-[7] ITU-T (formerly CCITT) Information technology - Open Systems
-Interconnection - The Directory: Authentication Framework
-Recommendation X.509 ISO/IEC 9594-8
-
-[8] R. Housley. Cryptographic Message Syntax.
-draft-ietf-smime-cms-13.txt, April 1999, approved for publication as
-RFC.
-
-[9] PKCS #7: Cryptographic Message Syntax Standard. An RSA
-Laboratories Technical Note Version 1.5. Revised November 1, 1993
-
-[10] R. Rivest, MIT Laboratory for Computer Science and RSA Data
-Security, Inc. A Description of the RC2(r) Encryption Algorithm.
-March 1998.  Request for Comments 2268.
-
-[11] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
-Key Infrastructure, Certificate and CRL Profile, April 2002.
-Request for Comments 3280.
-
-[12] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-Specifications, October 1998.  Request for Comments 2437.
-
-[13] ITU-T (formerly CCITT) Information Processing Systems - Open
-Systems Interconnection - Specification of Abstract Syntax Notation
-One (ASN.1) Rec. X.680 ISO/IEC 8824-1.
-
-[14] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
-Laboratories Technical Note, Version 1.4, Revised November 1, 1993.
-
-[15] K. Raeburn.  Encryption and Checksum Specifications for
-Kerberos 5, October 2003. draft-ietf-krb-wg-crypto-06.txt.
-
-[16] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
-T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
-Request for Comments 3546.
-
-[17] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.
-Internet X.509 Public Key Infrastructure: Online Certificate Status
-Protocol - OCSP, June 1999.  Request for Comments 2560.
-
-
-8.  Authors
-
-Brian Tung
-Clifford Neuman
-USC Information Sciences Institute
-4676 Admiralty Way Suite 1001
-Marina del Rey CA 90292-6695
-Phone: +1 310 822 1511
-E-mail: {brian,bcn}@isi.edu
-
-Matthew Hur
-Ari Medvinsky
-Microsoft Corporation
-One Microsoft Way
-Redmond WA 98052
-Phone: +1 425 707 3336
-E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
-
-Sasha Medvinsky
-Motorola, Inc.
-6450 Sequence Drive
-San Diego, CA 92121
-+1 858 404 2367
-E-mail: smedvinsky@motorola.com
-
-John Wray
-Iris Associates, Inc.
-5 Technology Park Dr.
-Westford, MA 01886
-E-mail: John_Wray@iris.com
-
-Jonathan Trostle
-E-mail: jtrostle@world.std.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-19.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-19.txt
deleted file mode 100644
index f86b9f622..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-19.txt
+++ /dev/null
@@ -1,1055 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-19.txt                   Clifford Neuman
-Updates: RFC 1510bis                                             USC/ISI
-expires September 30, 2004                                   Matthew Hur
-                                                           Ari Medvinsky
-                                                   Microsoft Corporation
-                                                         Sasha Medvinsky
-                                                          Motorola, Inc.
-                                                               John Wray
-                                                   Iris Associates, Inc.
-                                                        Jonathan Trostle
-
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-
-0.  Status Of This Memo
-
-
-This document is an Internet-Draft and is in full conformance with
-all provision of Section 10 of RFC 2026.  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."
-
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-
-The distribution of this memo is unlimited.  It is filed as
-draft-ietf-cat-kerberos-pk-init-19.txt and expires September 30,
-2004.  Please send comments to the authors.
-
-
-
-1.  Abstract
-
-
-This document describes protocol extensions (hereafter called PKINIT)
-to the Kerberos protocol specification (RFC 1510bis [1]).  These
-extensions provide a method for integrating public key cryptography
-into the initial authentication exchange, by passing digital
-certificates and associated authenticators in preauthentication data
-fields.
-
-
-
-2.  Introduction
-
-
-A client typically authenticates itself to a service in Kerberos
-using three distinct though related exchanges.  First, the client
-requests a ticket-granting ticket (TGT) from the Kerberos
-authentication server (AS).  Then, it uses the TGT to request a
-service ticket from the Kerberos ticket-granting server (TGS).
-Usually, the AS and TGS are integrated in a single device known as
-a Kerberos Key Distribution Center, or KDC.  (In this document, we will
-refer to both the AS and the TGS as the KDC.) Finally, the client
-uses the service ticket to authenticate itself to the service.
-
-
-The advantage afforded by the TGT is that the client need
-explicitly request a ticket and expose his credentials only once.  The
-TGT and its associated session key can then be used for any
-subsequent requests.  One result of this is that all further
-authentication is independent of the method by which the initial
-authentication was performed.  Consequently, initial authentication
-provides a convenient place to integrate public-key cryptography
-into Kerberos authentication.
-
-
-As defined, Kerberos authentication exchanges use symmetric-key
-cryptography, in part for performance.  One cost of using
-symmetric-key cryptography is that the keys must be shared, so that
-before a client can authenticate itself, he must already be
-registered with the KDC.
-
-
-Conversely, public-key cryptography (in conjunction with an
-established Public Key Infrastructure) permits authentication
-without prior registration with a KDC.  Adding it to Kerberos allows the
-widespread use of Kerberized applications by clients without requiring
-them to register first with a KDC: a requirement that has no inherent 
-security benefit.
-
-
-As noted above, a convenient and efficient place to introduce
-public-key cryptography into Kerberos is in the initial
-authentication exchange.  This document describes the methods and
-data formats for integrating public-key cryptography into Kerberos
-initial authentication.
-
-
-
-3.  Extensions
-
-
-This section describes extensions to RFC 1510bis for supporting the
-use of public-key cryptography in the initial request for a ticket.
-
-
-Briefly, this document defines the following extensions to RFC 1510bis:
-
-
-    1.  The client indicates the use of public-key authentication by
-        including a special preauthenticator in the initial request. 
-        This preauthenticator contains the client's public-key data 
-        and a signature.
-
-
-2.     2.  The KDC tests the client's request against its policy and
-        trusted Certification Authorities (CAs).
-
-
-    3.  If the request passes the verification tests, the KDC
-        replies as usual, but the reply is encrypted using either:
-
-
-        a.  a symmetric encryption key, signed using the KDC?s
-            signature key and encrypted using the client?s encryption
-            key; or
-
-
-        b.  a key generated through a Diffie-Hellman exchange with
-            the client, signed using the KDC's signature key.
-
-
-        Any keying material required by the client to obtain the 
-        Encryption key is returned in a preauthentication field in 
-        the usual reply.
-
-
-    4.  The client obtains the encryption key, decrypts the reply,
-        and then proceeds as usual.
-
-
-Section 3.1 of this document defines the necessary message formats.
-Section 3.2 describes their syntax and use in greater detail.
-
-
-
-3.1.  Definitions
-
-
-
-3.1.1.  Required Algorithms
-
-
-All PKINIT implementations MUST support the following algorithms:
-
-
-    - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype;
-    
-    - Signature algorithm: SHA-1 digest and RSA;
-
-
-    - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
-      with a non-zero nonce;
-
-
-    - Unkeyed checksum type for the paChecksum member of
-      PKAuthenticator: SHA1 (unkeyed).
-
-
-
-3.1.2.  Defined Message and Encryption Types
-
-
-PKINIT makes use of the following new preauthentication types:
-
-
-    PA-PK-AS-REQ                             TBD
-    PA-PK-AS-REP                             TBD
-    PA-PK-OCSP-REQ                           TBD
-    PA-PK-OCSP-REP                           TBD
-
-
-PKINIT also makes use of the following new authorization data type:
-
-
-    AD-INITIAL-VERIFIED-CAS                  TBD
-
-
-PKINIT introduces the following new error codes:
-
-
-    KDC_ERR_CLIENT_NOT_TRUSTED                62
-    KDC_ERR_KDC_NOT_TRUSTED                   63
-    KDC_ERR_INVALID_SIG                       64
-    KDC_ERR_KEY_SIZE                          65
-    KDC_ERR_CERTIFICATE_MISMATCH              66
-    KDC_ERR_CANT_VERIFY_CERTIFICATE           70
-    KDC_ERR_INVALID_CERTIFICATE               71
-    KDC_ERR_REVOKED_CERTIFICATE               72
-    KDC_ERR_REVOCATION_STATUS_UNKNOWN         73
-    KDC_ERR_CLIENT_NAME_MISMATCH              75
-
-
-PKINIT uses the following typed data types for errors:
-
-
-    TD-DH-PARAMETERS                         TBD
-    TD-TRUSTED-CERTIFIERS                    104
-    TD-CERTIFICATE-INDEX                     105
-
-
-PKINIT defines the following encryption types, for use in the AS-REQ
-message (to indicate acceptance of the corresponding encryption OIDs
-in PKINIT):
-
-
-    dsaWithSHA1-CmsOID                         9
-    md5WithRSAEncryption-CmsOID               10
-    sha1WithRSAEncryption-CmsOID              11
-    rc2CBC-EnvOID                             12
-    rsaEncryption-EnvOID   (PKCS1 v1.5)       13
-    rsaES-OAEP-EnvOID      (PKCS1 v2.0)       14
-    des-ede3-cbc-EnvOID                       15
-
-
-The above encryption types are used by the client only within the 
-KDC-REQ-BODY to indicate which CMS [2] algorithms it supports.  Their 
-use within Kerberos EncryptedData structures is not specified by this 
-document.
-
-
-
-3.1.3.  Algorithm Identifiers
-
-
-PKINIT does not define, but does make use of, the following
-algorithm identifiers.
-
-
-PKINIT uses the following algorithm identifier for Diffie-Hellman
-key agreement [9]:
-
-
-    dhpublicnumber
-
-
-PKINIT uses the following signature algorithm identifiers [8, 12]:
-
-
-    sha-1WithRSAEncryption (RSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    id-dsa-with-sha1       (DSA with SHA1)
-
-
-PKINIT uses the following encryption algorithm identifiers [5] for
-encrypting the temporary key with a public key:
-
-
-    rsaEncryption          (PKCS1 v1.5)
-    id-RSAES-OAEP          (PKCS1 v2.0)
-
-
-PKINIT uses the following algorithm identifiers [2] for encrypting
-the reply key with the temporary key:
-
-
-    des-ede3-cbc           (three-key 3DES, CBC mode)
-    rc2-cbc                (RC2, CBC mode)
-
-
-Kerberos data structures require the use of integer etypes, while CMS 
-objects use OIDs. Therefore, each cryptographic algorithm supported 
-by PKINIT is identified both by a CMS OID and by an equivalent 
-Kerberos etype (defined in section 3.1.2).
-
-
-3.2.  PKINIT Preauthentication Syntax and Use
-
-
-This section defines the syntax and use of the various
-preauthentication fields employed by PKINIT.
-
-
-
-3.2.1.  Client Request
-
-
-The initial authentication request (AS-REQ) is sent as per RFC
-1510bis; the preauthentication field contains data signed by the
-client's private signature key as follows:
-
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-        signedAuthPack          [0] ContentInfo,
-                                    -- Defined in CMS [2].
-                                    -- Type is SignedData.
-                                    -- Content is AuthPack
-                                    -- (defined below).
-        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-                                    -- A list of CAs, trusted by
-                                    -- the client, used to certify
-                                    -- KDCs.
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL,
-                                    -- Defined in CMS [2].
-                                    -- Identifies a particular KDC
-                                    -- certificate, if the client
-                                    -- already has it.
-        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL,
-                                    -- May identify the client's
-                                    -- Diffie-Hellman certificate,
-                                    -- or an RSA encryption key
-                                    -- certificate.
-        ...
-    }
-
-
-    TrustedCA ::= CHOICE {
-        caName                  [0] Name,
-                                    -- Fully qualified X.500 name
-                                    -- as defined in RFC 3280 [4].
-        issuerAndSerial         [1] IssuerAndSerialNumber,
-                                    -- Identifies a specific CA
-                                    -- certificate.
-        ...
-    }
-
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                                    -- Defined in RFC 3280 [4].
-                                    -- Present only if the client
-                                    -- is using ephemeral-ephemeral
-                                    -- Diffie-Hellman.
-        ...
-    }
-
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER,
-        ctime                   [1] KerberosTime,
-                                    -- cusec and ctime are used as
-                                    -- in RFC 1510bis, for replay
-                                    -- prevention.
-        nonce                   [2] INTEGER,
-                                    -- Binds reply to request,
-                                    -- MUST be zero when client
-                                    -- will accept cached
-                                    -- Diffie-Hellman parameters
-                                    -- from KDC. MUST NOT be
-                                    -- zero otherwise.
-                                    -- MUST be 0 <= nonce < 2^32.
-        paChecksum              [3] Checksum,
-                                    -- Defined in RFC 1510bis [1].
-                                    -- Performed over KDC-REQ-BODY,
-                                    -- MUST be unkeyed.
-        ...
-    }
-
-
-    IMPORTS
-        -- from RFC 3280 [4]
-        SubjectPublicKeyInfo, AlgorithmIdentifier, Name
-            FROM PKIX1Explicit88 { iso (1) identified-organization (3)
-              dod (6) internet (1) security (5) mechanisms (5)
-              pkix (7) id-mod (0) id-pkix1-explicit (18) }
-
-
-    IMPORTS
-        -- from RFC 2630 [2]
-        ContentInfo, IssuerAndSerialNumber
-            FROM CryptographicMessageSyntax { iso(1) member-body(2)
-              us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
-              modules(0) cms(1) }
-
-
-    IMPORTS
-        -- from RFC 1510bis [1]
-        KerberosTime, Checksum
-            FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-              dod(6) internet(1) security(5) kerberosV5(2) modules(4)
-              krb5spec2(2) }
-
-
-The ContentInfo in the signedAuthPack is filled out as follows:
-
-
-    1.  The eContent field contains data of type AuthPack.  It MUST
-        contain the pkAuthenticator, and MAY also contain the
-        client's Diffie-Hellman public value (clientPublicValue).
-
-
-    2.  The eContentType field MUST contain the OID value for
-        pkauthdata: { iso (1) org (3) dod (6) internet (1)
-        security (5) kerberosv5 (2) pkinit (3) pkauthdata (1)}
-
-
-    3.  The signerInfos field MUST contain the signature over the
-        AuthPack.
-
-
-    4.  The certificates field MUST contain at least a signature
-        verification certificate chain that the KDC can use to
-        verify the signature over the AuthPack.  Additionally, the
-        client MAY insert an encryption certificate chain, if
-        (for example) the client is not using ephemeral-ephemeral
-        Diffie-Hellman.
-
-
-    5.  If a Diffie-Hellman key is being used, the parameters SHOULD
-        be chosen from the First or Second defined Oakley Groups.
-        (See RFC 2409 [10].)
-
-
-    6.  The KDC may wish to use cached Diffie-Hellman parameters.
-        To indicate acceptance of caching, the client sends zero in
-        the nonce field of the pkAuthenticator.  Zero is not a valid
-        value for this field under any other circumstances.  Since
-        zero is used to indicate acceptance of cached parameters,
-        message binding in this case is performed using only the
-        nonce in the main request.
-
-
-
-3.2.2.  Validation of Client Request
-
-
-Upon receiving the client's request, the KDC validates it.  This
-section describes the steps that the KDC MUST (unless otherwise
-noted) take in validating the request.
-
-
-The KDC must look for a client certificate in the signedAuthPack.
-If it cannot find one signed by a CA it trusts, it sends back an
-error of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying
-e-data for this error is a SEQUENCE OF TYPED-DATA:
-
-
-    TYPED-DATA ::= SEQUENCE {
-                                    -- As defined in RFC 1510bis.
-        data-type               [0] INTEGER,
-        data-value              [1] OCTET STRING
-    }
-
-
-    IMPORTS
-        -- from RFC 1510bis [1]
-        TYPED-DATA, Checksum
-            FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-              dod(6) internet(1) security(5) kerberosV5(2) modules(4)
-              krb5spec2(2) }
-
-
-For this error, the data-type is TD-TRUSTED-CERTIFIERS, and the
-data-value is an OCTET STRING containing the DER encoding of
-
-
-    TrustedCertifiers ::= SEQUENCE OF Name
-
-
-If, while verifying the certificate chain, the KDC determines that
-the signature on one of the certificates in the signedAuthPack is
-invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
-The accompanying e-data for this error is a SEQUENCE OF TYPED-DATA,
-whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an
-OCTET STRING containing the DER encoding of the index into the
-CertificateSet field, ordered as sent by the client:
-
-
-    CertificateIndex ::= IssuerAndSerialNumber
-                                    -- IssuerAndSerialNumber of
-                                    -- certificate with invalid signature
-
-
-If more than one certificate signature is invalid, the KDC MAY send one
-TYPED-DATA per invalid signature.
-
-
-The KDC MAY also check whether any of the certificates in the client's
-chain have been revoked.  If any of them have been revoked, the KDC
-MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
-attempts to determine the revocation status but is unable to do so,
-it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
-The certificate or certificates affected are identified exactly as
-for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
-
-
-In addition to validating the certificate chain, the KDC MUST also
-check that the certificate properly maps to the client's principal name
-as specified in the AS-REQ as follows:
-
-
-    1.  If the KDC has its own mapping from the name in the
-        certificate to a Kerberos name, it uses that Kerberos
-        name.
-
-
-    2.  Otherwise, if the certificate contains a SubjectAltName
-        extension with a Kerberos name in the otherName field,
-        it uses that name. The otherName field (of type AnotherName) in
-        the SubjectAltName extension MUST contain the following:
-
-
-        The type-id is:
-
-
-        krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6)
-        internet (1) security (5) kerberosv5 (2) 2 }
-
-
-        The value is:
-
-
-        KRB5PrincipalName ::= SEQUENCE {
-            realm                   [0] Realm,
-            principalName           [1] PrincipalName
-        }
-
-
-        IMPORTS
-            -- from RFC 3280 [4]
-            GeneralName
-                FROM PKIX1Explicit88 { iso (1) identified-organization (3)
-                  dod (6) internet (1) security (5) mechanisms (5)
-                  pkix (7) id-mod (0) id-pkix1-explicit (18) }
-
-
-        IMPORTS
-            -- from RFC 1510bis [1]
-            PrincipalName, Realm
-                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                  dod(6) internet(1) security(5) kerberosV5(2) modules(4)
-                  krb5spec2(2) }
-
-
-If the KDC does not have its own mapping and there is no Kerberos
-name present in the certificate, or if the name in the request does
-not match the name in the certificate (including the realm name), or
-if there is no name in the request, the KDC MUST return error code
-KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
-for this error.  If the name in the request is [special "blank"
-name], the KDC MAY insert a different name in the reply.
-
-
-Even if the chain is validated, and the names in the certificate and
-the request match, the KDC may decide not to trust the client.  For
-example, the certificate may include an Enxtended Key Usage (EKU) OID 
-in the extensions field.  As a matter of local policy, the KDC may 
-decide to reject requests on the basis of the absence or presence of 
-specific EKU OIDs.  In this case, the KDC MUST return error code 
-KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as:
-
-
-      { iso (1) org (3) dod (6) internet (1) security (5)
-        kerberosv5 (2) pkinit (3) pkekuoid (4) }
-
-
-If the client's signature on the signedAuthPack fails to verify, the KDC
-MUST return error KDC_ERR_INVALID_SIG.  There is no accompanying
-e-data for this error.
-
-
-The KDC MUST check the timestamp to ensure that the request is not
-a replay, and that the time skew falls within acceptable limits.
-The recommendations clock skew times in RFC 1510bis [1] apply here.
-If the check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT 
-or KRB_AP_ERR_SKEW, respectively.
-
-
-If the clientPublicValue is filled in, indicating that the
-client wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC
-checks to see if the parameters satisfy its policy.  If they do not,
-it MUST return error code KDC_ERR_KEY_SIZE.  The accompanying e-data is 
-a SEQUENCE OF TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose 
-data-value is an OCTET STRING containing the DER encoding of a 
-DomainParameters (see [3]), including appropriate Diffie-Hellman 
-parameters with which to retry the request.
-
-
-The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the 
-client included a kdcCert field in the PA-PK-AS-REQ and the KDC does not 
-have the corresponding certificate.
-
-
-The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client did 
-not include a kdcCert field, but did include a trustedCertifiers field, 
-and the KDC does not possesses a certificate issued by one of the listed 
-certifiers.
-
-
-
-3.2.3.  KDC Reply
-
-
-Assuming that the client's request has been properly validated, the
-KDC proceeds as per RFC 1510bis, except as follows.
-
-
-The KDC MUST set the initial flag and include an authorization data of 
-type AD-INITIAL-VERIFIED-CAS in the issued ticket.  The value is an 
-OCTET STRING containing the DER encoding of InitialVerifiedCAs:
-
-
-    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
-        ca                      [0] Name,
-        Validated               [1] BOOLEAN,
-        ...
-    }
-
-
-The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT 
-containers if the list of CAs satisfies the KDC's realm's policy. 
-(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.) 
-Furthermore, any TGS must copy such authorization data from tickets 
-used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket, 
-including the AD-IF-RELEVANT container, if present. 
-
-
-AP servers that understand this authorization data type SHOULD apply 
-local policy to determine whether a given ticket bearing such a type 
-(not contained within an AD-IF-RELEVANT container) is acceptable. 
-(This corresponds to the AP server checking the transited field when 
-the TRANSITED-POLICY-CHECKED flag has not been set.)  If such a data 
-type is contained within an AD-IF-RELEVANT container, AP servers 
-MAY apply local policy to determine whether the authorization 
-data is acceptable.
-
-
-The AS-REP is otherwise unchanged from RFC 1510bis.  The KDC encrypts 
-the reply as usual, but not with the client's long-term key.
-Instead, it encrypts it with either a generated encryption key, or a 
-key derived from a Diffie-Hellman exchange. The contents of the 
-PA-PK-AS-REP indicate the type of encryption key that was used:
-
-
-    PA-PK-AS-REP ::= CHOICE {
-        dhSignedData            [0] ContentInfo,
-                                    -- Type is SignedData.
-                                    -- Content is KDCDHKeyInfo
-                                    -- (defined below).
-        encKeyPack              [1] ContentInfo,
-                                    -- Type is SignedData.
-                                    -- Content is ReplyKeyPack
-                                    -- (defined below).
-        ...
-    }
-
-
-    KDCDHKeyInfo ::= SEQUENCE {
-        subjectPublicKey        [0] BIT STRING,
-                                    -- Equals public exponent
-                                    -- (g^a mod p).
-                                    -- INTEGER encoded as payload
-                                    -- of BIT STRING.
-        nonce                   [1] INTEGER,
-                                    -- Binds reply to request.
-                                    -- Exception: A value of zero
-                                    -- indicates that the KDC is
-                                    -- using cached values.
-        dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                                    -- Expiration time for KDC's
-                                    -- cached values.
-        ...
-    }
-
-
-The fields of the ContentInfo for dhSignedData are to be filled in
-as follows:
-
-
-    1.  The eContent field contains data of type KDCDHKeyInfo.
-
-
-    2.  The eContentType field contains the OID value for
-        pkdhkeydata: { iso (1) org (3) dod (6) internet (1)
-        security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) }
-
-
-    3.  The signerInfos field contains a single signerInfo, which is
-        the signature of the KDCDHKeyInfo.
-
-
-    4.  The certificates field contains a signature verification
-        certificate chain that the client will use to verify the
-        KDC's signature over the KDCDHKeyInfo.  This field may only 
-        be left empty if the client did include a kdcCert field in 
-        the PA-PK-AS-REQ, indicating that it has the KDC's certificate.
-
-
-    5.  If the client and KDC agree to use cached parameters, the
-        KDC MUST return a zero in the nonce field and include the
-        expiration time of the cached values in the dhKeyExpiration
-        field.  If this time is exceeded, the client MUST NOT use
-        the reply.  If the time is absent, the client MUST NOT use
-        the reply and MAY resubmit a request with a non-zero nonce,
-        thus indicating non-acceptance of the cached parameters.
-
-
-The key is derived as follows: Both the KDC and the client calculate
-the value g^(ab) mod p, where a and b are the client's and KDC's
-private exponents, respectively.  They both take the first k bits of
-this secret value as a key generation seed, where the parameter k
-(the size of the seed) is dependent on the selected key type, as
-specified in [6].  The seed is then converted into a protocol key by 
-applying to it a random-to-key function, which is also dependent on 
-key type.
-
-
-    1.  For example, if the encryption type is DES with MD4, k = 64
-        bits and the random-to-key function consists of replacing
-        some of the bits with parity bits, according to FIPS PUB 74
-        [9].
-
-
-    2.  If the encryption type is three-key 3DES with HMAC-SHA1,
-        k = 168 bits and the random-to-key function is
-        DES3random-to-key as defined in [6].  This function inserts
-        parity bits to create a 192-bit 3DES protocol key that is
-        compliant with FIPS PUB 74 [9].  This key is used to
-        generate additional keys Ke and Ki, for encryption and
-        integrity protection, respectively, using the key usage
-        value of 3, as per [6] for the handling of the encrypted
-        part of the AS-REP.
-
-
-If the KDC and client are not using Diffie-Hellman, the KDC encrypts
-the reply with an encryption key, packed in the encKeyPack, which
-contains data of type ReplyKeyPack:
-
-
-    ReplyKeyPack ::= SEQUENCE {
-        replyKey                [0] EncryptionKey,
-                                    -- Defined in RFC 1510bis.
-                                    -- Used to encrypt main reply.
-                                    -- MUST be at least as strong
-                                    -- as session key.  (Using the
-                                    -- same enctype and a strong
-                                    -- prng should suffice, if no
-                                    -- stronger encryption system
-                                    -- is available.)
-        nonce                   [1] INTEGER,
-                                    -- Binds reply to request.
-                                    -- MUST be 0 < nonce < 2^32.
-        ...
-    }
-
-
-    IMPORTS
-        -- from RFC 1510bis [1]
-        EncryptionKey
-            FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-              dod(6) internet(1) security(5) kerberosV5(2) modules(4)
-              krb5spec2(2) }
-
-
-The fields of the ContentInfo for encKeyPack MUST be filled in as
-follows:
-
-
-    1.  The content is of type SignedData.  The eContent for
-        the SignedData is of type ReplyKeyPack.
-
-
-    2.  The eContentType for the SignedData contains the OID value for
-        pkrkeydata: { iso (1) org (3) dod (6) internet (1)
-        security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) }
-
-
-    3.  The signerInfos field contains a single signerInfo, which is
-        the signature of the ReplyKeyPack.
-
-
-    4.  The certificates field contains a signature verification
-        certificate chain that the client will use to verify the
-        KDC's signature over the ReplyKeyPack.  This field may only 
-        be left empty if the client did include a kdcCert field in 
-        the PA-PK-AS-REQ, indicating that it has the KDC's certificate.
-
-
-    5.  The encryptedContentType for the EnvelopedData contains the OID
-        value for id-signedData: { iso (1) member-body (2) us (840)
-        rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) }
-
-
-    6.  The recipientInfos field is a SET which MUST contain exactly
-        one member of type KeyTransRecipientInfo.  The encryptedKey
-        for this member contains the temporary key which is
-        encrypted using the client's public key.
-
-
-    7.  The unprotectedAttrs or originatorInfo fields MAY be present.
-
-
-
-3.2.4.  Validation of KDC Reply
-
-
-Upon receipt of the KDC's reply, the client proceeds as follows.  If
-the PA-PK-AS-REP contains a dhSignedData, the client obtains and
-verifies the Diffie-Hellman parameters, and obtains the shared key
-as described above.  Otherwise, the message contains an encKeyPack,
-and the client decrypts and verifies the temporary encryption key.
-In either case, the client then decrypts the main reply with the
-resulting key, and then proceeds as described in RFC 1510bis.
-
-
-
-3.2.5.  Support for OCSP
-
-
-OCSP (Online Certificate Status Protocol) [8] allows the use of
-on-line requests for a client or server to determine the validity of
-each other's certificates.  It is particularly useful for clients
-authenticating each other across a constrained network.  These
-clients will not have to download the entire CRL to check for the
-validity of the KDC's certificate.
-
-
-In these cases, the KDC generally has better connectivity to the
-OCSP server, and it therefore processes the OCSP request and
-response and sends the results to the client.  The mechanism defined
-in this section allow a client to request an OCSP response from the
-KDC when using PKINIT.  This is similar to the way that OCSP is
-handled in [7].
-
-
-OCSP support is provided in PKINIT through the use of additional
-preauthentication data.  The following new preauthentication types
-are defined:
-
-
-    PA-PK-OCSP-REQ ::= SEQUENCE {
-                                    -- PAType TBD
-        responderIDList         [0] SEQUENCE of ResponderID OPTIONAL,
-                                    -- ResponderID is a DER-encoded
-                                    -- ASN.1 type defined in [8]
-        requestExtensions       [1] Extensions OPTIONAL
-                                    -- Extensions is a DER-encoded
-                                    -- ASN.1 type defined in [8]
-    }
-
-
-    PA-PK-OCSP-REP ::= SEQUENCE of OCSPResponse
-                                    -- OCSPResponse is a DER-encoded
-                                    -- ASN.1 type defined in [8]
-
-
-A KDC that receives a PA-PK-OCSP-REQ MAY send a PA-PK-OCSP-REP.
-KDCs MUST NOT send a PA-PK-OCSP-REP if they do not first receive a
-PA-PK-OCSP-REQ from the client.  The KDC MAY either send a cached
-OCSP response or send an on-line request to the OCSP server.
-
-
-In the case that a responderIDList is not sent or is empty, the OCSP
-response must be signed by the authority that issued the
-certificate, unless specified otherwise by a mutually agreed policy
-between the client and the KDC.
-
-
-When using OCSP, the response is signed by the OCSP server, which is
-trusted by the client.  Depending on local policy, further
-verification of the validity of the OCSP server may need to be done.
-
-
-
-4.  Security Considerations
-
-
-PKINIT raises certain security considerations beyond those that can
-be regulated strictly in protocol definitions.  We will address them
-in this section.
-
-
-PKINIT extends the cross-realm model to the public-key
-infrastructure.  Users of PKINIT must understand security policies 
-and procedures appropriate to the use of Public Key Infrastructures.
-
-
-Standard Kerberos allows the possibility of interactions between 
-cryptosystems of varying strengths; this document adds interactions 
-with public-key cryptosystems to Kerberos.  Some administrative 
-policies may allow the use of relatively weak public keys.  Using 
-such keys to wrap data encrypted under stronger conventional 
-cryptosystems may be inappropriate.
-
-
-PKINIT requires keys for symmetric cryptosystems to be generated. 
-Some such systems contain "weak" keys.  For recommendations regarding 
-these weak keys, see RFC 1510bis.
-
-
-PKINIT allows the use of a zero nonce in the PKAuthenticator when 
-cached Diffie-Hellman keys are used.  In this case, message binding 
-is performed using the nonce in the main request in the same way as 
-it is done for ordinary AS-REQs (without the PKINIT 
-pre-authenticator).  The nonce field in the KDC request body is 
-signed through the checksum in the PKAuthenticator, which 
-cryptographically binds the PKINIT pre-authenticator to the main body 
-of the AS Request and also provides message integrity for the full 
-AS Request.
-
-
-However, when a PKINIT pre-authenticator in the AS-REP has a 
-zero-nonce, and an attacker has somehow recorded this 
-pre-authenticator and discovered the corresponding Diffie-Hellman 
-private key (e.g., with a brute-force attack), the attacker will be 
-able to fabricate his own AS-REP messages that impersonate the KDC 
-with this same pre-authenticator.  This compromised pre-authenticator 
-will remain valid as long as its expiration time has not been reached 
-and it is therefore important for clients to check this expiration 
-time and for the expiration time to be reasonably short, which 
-depends on the size of the Diffie-Hellman group.
-
-
-If a client also caches its Diffie-Hellman keys, then the session key 
- could remain the same during multiple AS-REQ/AS-REP exchanges and an 
- attacker which compromised the session key could fabricate his own 
-AS-REP messages with a pre-recorded pre-authenticator until the 
-client starts using a new Diffie-Hellman key pair and while the KDC 
-pre-authenticator has not yet expired.  It is therefore not 
-recommended for KDC clients to also cache their Diffie-Hellman keys.
-
-
-Care should be taken in how certificates are chosen for the purposes
-of authentication using PKINIT.  Some local policies may require
-that key escrow be used for certain certificate types.  Deployers of 
-PKINIT should be aware of the implications of using certificates that 
-have escrowed keys for the purposes of authentication.
-
-
-PKINIT does not provide for a "return routability" test to prevent
-attackers from mounting a denial-of-service attack on the KDC by
-causing it to perform unnecessary and expensive public-key
-operations.  Strictly speaking, this is also true of standard
-Kerberos, although the potential cost is not as great, because
-standard Kerberos does not make use of public-key cryptography.
-
-
-
-
-5.  Acknowledgements
-
-
-Some of the ideas on which this document is based arose during
-discussions over several years between members of the SAAG, the IETF
-CAT working group, and the PSRG, regarding integration of Kerberos
-and SPX.  Some ideas have also been drawn from the DASS system.
-These changes are by no means endorsed by these groups.  This is an
-attempt to revive some of the goals of those groups, and this
-document approaches those goals primarily from the Kerberos
-perspective.  Lastly, comments from groups working on similar ideas
-in DCE have been invaluable.
-
-
-
-6.  Expiration Date
-
-
-This draft expires September 30, 2004.
-
-
-
-7.  Bibliography
-
-
-[1]  RFC-Editor: To be replaced by RFC number for 
-draft-ietf-krb-wg-kerberos-clarifications.
-
-
-[2] R. Housley. Cryptographic Message Syntax., April 1999. 
-Request For Comments 2630.
-
-
-[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers 
-for the Internet X.509 Public Key Infrastructure Certificate and 
-Certificate Revocation List (CRL) Profile, April 2002. Request For 
-Comments 3279.
-
-
-[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public
-Key Infrastructure Certificate and Certificate Revocation List 
-(CRL) Profile, April 2002. Request for Comments 3280.
-
-
-[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-Specifications, October 1998.  Request for Comments 2437.
-
-
-[6] RFC-Editor: To be replaced by RFC number for 
-draft-ietf-krb-wg-crypto.
-
-
-[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
-T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
-Request for Comments 3546.
-
-
-[8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.
-Internet X.509 Public Key Infrastructure: Online Certificate Status
-Protocol - OCSP, June 1999.  Request for Comments 2560.
-
-
-[9] NIST, Guidelines for Implementing and Using the NBS Encryption
-Standard, April 1981.  FIPS PUB 74.
-
-
-[10] D. Harkins and D. Carrel.  The Internet Key Exchange (IKE),
-November 1998.  Request for Comments 2409.
-
-
-
-8.  Authors
-
-
-Brian Tung
-Clifford Neuman
-USC Information Sciences Institute
-4676 Admiralty Way Suite 1001
-Marina del Rey CA 90292-6695
-Phone: +1 310 822 1511
-E-mail: {brian,bcn}@isi.edu
-
-
-Matthew Hur
-Ari Medvinsky
-Microsoft Corporation
-One Microsoft Way
-Redmond WA 98052
-Phone: +1 425 707 3336
-E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
-
-
-Sasha Medvinsky
-Motorola, Inc.
-6450 Sequence Drive
-San Diego, CA 92121
-+1 858 404 2367
-E-mail: smedvinsky@motorola.com
-
-
-John Wray
-Iris Associates, Inc.
-5 Technology Park Dr.
-Westford, MA 01886
-E-mail: John_Wray@iris.com
-
-
-Jonathan Trostle
-E-mail: jtrostle@world.std.com
\ No newline at end of file
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt
deleted file mode 100644
index 0504450b8..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-20.txt
+++ /dev/null
@@ -1,908 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-20.txt                   Clifford Neuman
-Updates: CLARIFICATIONS                                          USC/ISI
-expires January 25, 2005                                     Matthew Hur
-                                                           Ari Medvinsky
-                                                   Microsoft Corporation
-                                                         Sasha Medvinsky
-                                                          Motorola, Inc.
-                                                               John Wray
-                                                   Iris Associates, Inc.
-                                                        Jonathan Trostle
-
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-
-0.  Status Of This Memo
-
-This document is an Internet-Draft and is in full conformance with
-all provision of Section 10 of RFC 2026.  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."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-The distribution of this memo is unlimited.  It is filed as
-draft-ietf-cat-kerberos-pk-init-20.txt and expires January 25, 2005.
-Please send comments to the authors.
-
-
-1.  Abstract
-
-This document describes protocol extensions (hereafter called
-PKINIT) to the Kerberos protocol specification ([1], hereafter
-called CLARIFICATIONS).  These extensions provide a method for
-integrating public key cryptography into the initial authentication
-exchange, by passing digital certificates and associated
-authenticators in preauthentication data fields.
-
-
-2.  Introduction
-
-A client typically authenticates itself to a service in Kerberos
-using three distinct though related exchanges.  First, the client
-requests a ticket-granting ticket (TGT) from the Kerberos
-authentication server (AS).  Then, it uses the TGT to request a
-service ticket from the Kerberos ticket-granting server (TGS).
-Usually, the AS and TGS are integrated in a single device known as
-a Kerberos Key Distribution Center, or KDC.  (In this document, we
-will refer to both the AS and the TGS as the KDC.)  Finally, the
-client uses the service ticket to authenticate itself to the
-service.
-
-The advantage afforded by the TGT is that the client need explicitly
-request a ticket and expose his credentials only once.  The TGT and
-its associated session key can then be used for any subsequent
-requests.  One result of this is that all further authentication is
-independent of the method by which the initial authentication was
-performed.  Consequently, initial authentication provides a
-convenient place to integrate public-key cryptography into Kerberos
-authentication.
-
-As defined, Kerberos authentication exchanges use symmetric-key
-cryptography, in part for performance.  One cost of using
-symmetric-key cryptography is that the keys must be shared, so that
-before a client can authenticate itself, he must already be
-registered with the KDC.
-
-Conversely, public-key cryptography (in conjunction with an
-established Public Key Infrastructure) permits authentication
-without prior registration with a KDC.  Adding it to Kerberos allows
-the widespread use of Kerberized applications by clients without
-requiring them to register first with a KDC--a requirement that has
-no inherent security benefit.
-
-As noted above, a convenient and efficient place to introduce
-public-key cryptography into Kerberos is in the initial
-authentication exchange.  This document describes the methods and
-data formats for integrating public-key cryptography into Kerberos
-initial authentication.
-
-
-3.  Extensions
-
-This section describes extensions to CLARIFICATIONS for supporting
-the use of public-key cryptography in the initial request for a
-ticket.
-
-Briefly, this document defines the following extensions to
-CLARIFICATIONS:
-
-    1.  The client indicates the use of public-key authentication by
-        including a special preauthenticator in the initial request.
-        This preauthenticator contains the client's public-key data
-        and a signature.
-
-    2.  The KDC tests the client's request against its policy and
-        trusted Certification Authorities (CAs).
-
-    3.  If the request passes the verification tests, the KDC
-        replies as usual, but the reply is encrypted using either:
-
-        a.  a symmetric encryption key, signed using the KDC's
-            signature key and encrypted using the client's encryption
-            key; or
-
-        b.  a key generated through a Diffie-Hellman exchange with
-            the client, signed using the KDC's signature key.
-
-        Any keying material required by the client to obtain the
-        Encryption key is returned in a preauthentication field
-        accompanying the usual reply.
-
-    4.  The client obtains the encryption key, decrypts the reply,
-        and then proceeds as usual.
-
-Section 3.1 of this document defines the necessary message formats.
-Section 3.2 describes their syntax and use in greater detail.
-
-
-3.1.  Definitions
-
-
-3.1.1.  Required Algorithms
-
-All PKINIT implementations MUST support the following algorithms:
-
-    - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype.
-
-    - Signature algorithm: SHA-1 digest and RSA.
-
-    - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
-      with a non-zero nonce.
-
-    - Unkeyed checksum type for the paChecksum member of
-      PKAuthenticator: SHA1 (unkeyed).
-
-
-3.1.2.  Defined Message and Encryption Types
-
-PKINIT makes use of the following new preauthentication types:
-
-    PA-PK-AS-REQ                             TBD
-    PA-PK-AS-REP                             TBD
-
-PKINIT also makes use of the following new authorization data type:
-
-    AD-INITIAL-VERIFIED-CAS                  TBD
-
-PKINIT introduces the following new error codes:
-
-    KDC_ERR_CLIENT_NOT_TRUSTED                62
-    KDC_ERR_KDC_NOT_TRUSTED                   63
-    KDC_ERR_INVALID_SIG                       64
-    KDC_ERR_KEY_SIZE                          65
-    KDC_ERR_CERTIFICATE_MISMATCH              66
-    KDC_ERR_CANT_VERIFY_CERTIFICATE           70
-    KDC_ERR_INVALID_CERTIFICATE               71
-    KDC_ERR_REVOKED_CERTIFICATE               72
-    KDC_ERR_REVOCATION_STATUS_UNKNOWN         73
-    KDC_ERR_CLIENT_NAME_MISMATCH              75
-
-PKINIT uses the following typed data types for errors:
-
-    TD-DH-PARAMETERS                         TBD
-    TD-TRUSTED-CERTIFIERS                    104
-    TD-CERTIFICATE-INDEX                     105
-
-PKINIT defines the following encryption types, for use in the AS-REQ
-message (to indicate acceptance of the corresponding encryption OIDs
-in PKINIT):
-
-    dsaWithSHA1-CmsOID                         9
-    md5WithRSAEncryption-CmsOID               10
-    sha1WithRSAEncryption-CmsOID              11
-    rc2CBC-EnvOID                             12
-    rsaEncryption-EnvOID   (PKCS1 v1.5)       13
-    rsaES-OAEP-EnvOID      (PKCS1 v2.0)       14
-    des-ede3-cbc-EnvOID                       15
-
-The above encryption types are used by the client only within the
-KDC-REQ-BODY to indicate which CMS [2] algorithms it supports.  Their
-use within Kerberos EncryptedData structures is not specified by this
-document.
-
-The ASN.1 module for all structures defined in this document (plus
-IMPORT statements for all imported structures) are given in Appendix
-A.  All structures MUST be encoded using Distinguished Encoding
-Rules (DER).
-
-
-3.1.3.  Algorithm Identifiers
-
-PKINIT does not define, but does make use of, the following
-algorithm identifiers.
-
-PKINIT uses the following algorithm identifier for Diffie-Hellman
-key agreement [9]:
-
-    dhpublicnumber
-
-PKINIT uses the following signature algorithm identifiers [8, 12]:
-
-    sha-1WithRSAEncryption (RSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    id-dsa-with-sha1       (DSA with SHA1)
-
-PKINIT uses the following encryption algorithm identifiers [5] for
-encrypting the temporary key with a public key:
-
-    rsaEncryption          (PKCS1 v1.5)
-    id-RSAES-OAEP          (PKCS1 v2.0)
-
-PKINIT uses the following algorithm identifiers [2] for encrypting
-the reply key with the temporary key:
-
-    des-ede3-cbc           (three-key 3DES, CBC mode)
-    rc2-cbc                (RC2, CBC mode)
-
-Kerberos data structures require the use of integer etypes, while CMS
-objects use OIDs. Therefore, each cryptographic algorithm supported
-by PKINIT is identified both by a CMS OID and by an equivalent
-Kerberos etype (defined in section 3.1.2).
-
-
-3.2.  PKINIT Preauthentication Syntax and Use
-
-This section defines the syntax and use of the various
-preauthentication fields employed by PKINIT.
-
-
-3.2.1.  Client Request
-
-The initial authentication request (AS-REQ) is sent as per RFC
-1510bis; in addition, a preauthentication field contains data signed
-by the client's private signature key, as follows:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-        signedAuthPack          [0] ContentInfo,
-                                    -- Defined in CMS [2].
-                                    -- Type is SignedData.
-                                    -- Content is AuthPack
-                                    -- (defined below).
-        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-                                    -- A list of CAs, trusted by
-                                    -- the client, used to certify
-                                    -- KDCs.
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL,
-                                    -- Defined in CMS [2].
-                                    -- Identifies a particular KDC
-                                    -- certificate, if the client
-                                    -- already has it.
-        ...
-    }
-
-    TrustedCA ::= CHOICE {
-        caName                  [0] Name,
-                                    -- Fully qualified X.500 name
-                                    -- as defined in RFC 3280 [4].
-        issuerAndSerial         [2] IssuerAndSerialNumber,
-                                    -- Identifies a specific CA
-                                    -- certificate.
-        ...
-    }
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                                    -- Defined in RFC 3280 [4].
-                                    -- Present only if the client
-                                    -- is using ephemeral-ephemeral
-                                    -- Diffie-Hellman.
-        supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                    OPTIONAL,
-                                    -- List of CMS encryption types
-                                    -- supported by client in order
-                                    -- of (decreasing) preference.
-        ...
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER,
-        ctime                   [1] KerberosTime,
-                                    -- cusec and ctime are used as
-                                    -- in CLARIFICATIONS, for replay
-                                    -- prevention.
-        nonce                   [2] INTEGER (0..4294967295),
-                                    -- Binds reply to request,
-                                    -- MUST be zero when client
-                                    -- will accept cached
-                                    -- Diffie-Hellman parameters
-                                    -- from KDC. MUST NOT be
-                                    -- zero otherwise.
-        paChecksum              [3] Checksum,
-                                    -- Defined in CLARIFICATIONS.
-                                    -- Performed over KDC-REQ-BODY,
-                                    -- MUST be unkeyed.
-        ...
-    }
-
-The ContentInfo in the signedAuthPack is filled out as follows:
-
-    1.  The eContent field contains data of type AuthPack.  It MUST
-        contain the pkAuthenticator, and MAY also contain the
-        client's Diffie-Hellman public value (clientPublicValue).
-
-    2.  The eContentType field MUST contain the OID value for
-        id-pkauthdata: { iso(1) org(3) dod(6) internet(1)
-        security(5) kerberosv5(2) pkinit(3) pkauthdata(1)}
-
-    3.  The signerInfos field MUST contain the signature over the
-        AuthPack.
-
-    4.  The certificates field MUST contain at least a signature
-        verification certificate chain that the KDC can use to
-        verify the signature over the AuthPack.  Additionally, the
-        client MAY insert an encryption certificate chain, if
-        (for example) the client is not using ephemeral-ephemeral
-        Diffie-Hellman.
-
-    5.  If a Diffie-Hellman key is being used, the parameters SHOULD
-        be chosen from the First or Second defined Oakley Groups.
-        (See RFC 2409 [10].)
-
-    6.  The KDC may wish to use cached Diffie-Hellman parameters.
-        To indicate acceptance of caching, the client sends zero in
-        the nonce field of the pkAuthenticator.  Zero is not a valid
-        value for this field under any other circumstances.  Since
-        zero is used to indicate acceptance of cached parameters,
-        message binding in this case is performed using only the
-        nonce in the main request.
-
-
-3.2.2.  Validation of Client Request
-
-Upon receiving the client's request, the KDC validates it.  This
-section describes the steps that the KDC MUST (unless otherwise
-noted) take in validating the request.
-
-The KDC must look for a client certificate in the signedAuthPack.
-If it cannot find one signed by a CA it trusts, it sends back an
-error of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying
-e-data for this error is a SEQUENCE OF TYPED-DATA (as defined in RFC
-1510bis).  For this error, the data-type is TD-TRUSTED-CERTIFIERS,
-and the data-value is an OCTET STRING containing the DER encoding of
-
-    TrustedCertifiers ::= SEQUENCE OF Name
-
-If, while verifying the certificate chain, the KDC determines that
-the signature on one of the certificates in the signedAuthPack is
-invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
-The accompanying e-data for this error is a SEQUENCE OF TYPED-DATA,
-whose data-type is TD-CERTIFICATE-INDEX, and whose data-value is an
-OCTET STRING containing the DER encoding of the index into the
-CertificateSet field, ordered as sent by the client:
-
-    CertificateIndex ::= IssuerAndSerialNumber
-                                    -- IssuerAndSerialNumber of
-                                    -- certificate with invalid signature
-
-If more than one certificate signature is invalid, the KDC MAY send
-one TYPED-DATA per invalid signature.
-
-The KDC MAY also check whether any certificates in the client's
-chain have been revoked.  If any of them have been revoked, the KDC
-MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
-attempts to determine the revocation status but is unable to do so,
-it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
-The certificate or certificates affected are identified exactly as
-for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
-
-In addition to validating the certificate chain, the KDC MUST also
-check that the certificate properly maps to the client's principal name
-as specified in the AS-REQ as follows:
-
-    1.  If the KDC has its own mapping from the name in the
-        certificate to a Kerberos name, it uses that Kerberos
-        name.
-
-    2.  Otherwise, if the certificate contains a SubjectAltName
-        extension with a Kerberos name in the otherName field,
-        it uses that name. The otherName field (of type AnotherName)
-        in the SubjectAltName extension MUST contain the following:
-
-        The type-id is:
-
-        krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6)
-        internet (1) security (5) kerberosv5 (2) 2 }
-
-        The value is:
-
-        KRB5PrincipalName ::= SEQUENCE {
-            realm                   [0] Realm,
-            principalName           [1] PrincipalName
-        }
-
-If the KDC does not have its own mapping and there is no Kerberos
-name present in the certificate, or if the name in the request does
-not match the name in the certificate (including the realm name), or
-if there is no name in the request, the KDC MUST return error code
-KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
-for this error.
-
-Even if the chain is validated, and the names in the certificate and
-the request match, the KDC may decide not to trust the client.  For
-example, the certificate may include an Enxtended Key Usage (EKU) OID
-in the extensions field.  As a matter of local policy, the KDC may
-decide to reject requests on the basis of the absence or presence of
-specific EKU OIDs.  In this case, the KDC MUST return error code
-KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as:
-
-    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-      pkinit(3) pkekuoid(4) }
-
-If the client's signature on the signedAuthPack fails to verify, the KDC
-MUST return error KDC_ERR_INVALID_SIG.  There is no accompanying
-e-data for this error.
-
-The KDC MUST check the timestamp to ensure that the request is not
-a replay, and that the time skew falls within acceptable limits.
-The recommendations clock skew times in CLARIFICATIONS apply here.
-If the check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT
-or KRB_AP_ERR_SKEW, respectively.
-
-If the clientPublicValue is filled in, indicating that the client
-wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to
-see if the parameters satisfy its policy.  If they do not, it MUST
-return error code KDC_ERR_KEY_SIZE.  The accompanying e-data is a
-SEQUENCE OF TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and
-whose data-value is an OCTET STRING containing the DER encoding of a
-DomainParameters (see [3]), including appropriate Diffie-Hellman
-parameters with which to retry the request.
-
-The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
-client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
-not have the corresponding certificate.
-
-The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
-did not include a kdcCert field, but did include a trustedCertifiers
-field, and the KDC does not possesses a certificate issued by one of
-the listed certifiers.
-
-If there is a supportedCMSTypes field in the AuthPack, the KDC must
-check to see if it supports any of the listed types.  If it supports
-more than one of the types, the KDC SHOULD use the one listed first.
-If it does not support any of them, it MUST return an error of type
-KRB5KDC_ERR_ETYPE_NOSUPP.
-
-
-3.2.3.  KDC Reply
-
-Assuming that the client's request has been properly validated, the
-KDC proceeds as per CLARIFICATIONS, except as follows.
-
-The KDC MUST set the initial flag and include an authorization data
-of type AD-INITIAL-VERIFIED-CAS in the issued ticket.  The value is
-an OCTET STRING containing the DER encoding of InitialVerifiedCAs:
-
-    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
-        ca                      [0] Name,
-        Validated               [1] BOOLEAN,
-        ...
-    }
-
-The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-containers if the list of CAs satisfies the KDC's realm's policy.
-(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.)
-Furthermore, any TGS must copy such authorization data from tickets
-used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
-including the AD-IF-RELEVANT container, if present.
-
-Application servers that understand this authorization data type
-SHOULD apply local policy to determine whether a given ticket
-bearing such a type *not* contained within an AD-IF-RELEVANT
-container is acceptable.  (This corresponds to the AP server
-checking the transited field when the TRANSITED-POLICY-CHECKED flag
-has not been set.)  If such a data type is contained within an
-AD-IF-RELEVANT container, AP servers MAY apply local policy to
-determine whether the authorization data is acceptable.
-
-The AS-REP is otherwise unchanged from CLARIFICATIONS.  The KDC
-encrypts the reply as usual, but not with the client's long-term
-key.  Instead, it encrypts it with either a generated encryption
-key, or a key derived from a Diffie-Hellman exchange. The contents
-of the PA-PK-AS-REP indicate the type of encryption key that was
-used:
-
-    PA-PK-AS-REP ::= CHOICE {
-        dhSignedData            [0] ContentInfo,
-                                    -- Type is SignedData.
-                                    -- Content is KDCDHKeyInfo
-                                    -- (defined below).
-        encKeyPack              [1] ContentInfo,
-                                    -- Type is EnvelopedData.
-                                    -- Content is SignedData over
-                                    -- ReplyKeyPack (defined below).
-        ...
-    }
-
-    KDCDHKeyInfo ::= SEQUENCE {
-        subjectPublicKey        [0] BIT STRING,
-                                    -- Equals public exponent
-                                    -- (g^a mod p).
-                                    -- INTEGER encoded as payload
-                                    -- of BIT STRING.
-        nonce                   [1] INTEGER,
-                                    -- Binds reply to request.
-                                    -- Exception: A value of zero
-                                    -- indicates that the KDC is
-                                    -- using cached values.
-        dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                                    -- Expiration time for KDC's
-                                    -- cached values.
-        ...
-    }
-
-The fields of the ContentInfo for dhSignedData are to be filled in
-as follows:
-
-    1.  The eContent field contains data of type KDCDHKeyInfo.
-
-    2.  The eContentType field contains the OID value for
-        id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
-        security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }
-
-    3.  The signerInfos field contains a single signerInfo, which is
-        the signature of the KDCDHKeyInfo.
-
-    4.  The certificates field contains a signature verification
-        certificate chain that the client will use to verify the
-        KDC's signature over the KDCDHKeyInfo.  This field may only
-        be left empty if the client did include a kdcCert field in
-        the PA-PK-AS-REQ, indicating that it has the KDC's
-        certificate.
-
-    5.  If the client and KDC agree to use cached parameters, the
-        KDC MUST return a zero in the nonce field and include the
-        expiration time of the cached values in the dhKeyExpiration
-        field.  If this time is exceeded, the client MUST NOT use
-        the reply.  If the time is absent, the client MUST NOT use
-        the reply and MAY resubmit a request with a non-zero nonce,
-        thus indicating non-acceptance of the cached parameters.
-
-The key is derived as follows: Both the KDC and the client calculate
-the value g^(ab) mod p, where a and b are the client's and KDC's
-private exponents, respectively.  They both take the first k bits of
-this secret value as a key generation seed, where the parameter k
-(the size of the seed) is dependent on the selected key type, as
-specified in [6].  The seed is then converted into a protocol key by
-applying to it a random-to-key function, which is also dependent on
-key type.
-
-If the KDC and client are not using Diffie-Hellman, the KDC encrypts
-the reply with an encryption key, packed in the encKeyPack, which
-contains data of type ReplyKeyPack:
-
-    ReplyKeyPack ::= SEQUENCE {
-        replyKey                [0] EncryptionKey,
-                                    -- Defined in CLARIFICATIONS.
-                                    -- Used to encrypt main reply.
-                                    -- MUST be at least as strong
-                                    -- as session key.  (Using the
-                                    -- same enctype and a strong
-                                    -- prng should suffice, if no
-                                    -- stronger encryption system
-                                    -- is available.)
-        nonce                   [1] INTEGER (0..4294967295),
-                                    -- Binds reply to request.
-        ...
-    }
-
-The fields of the ContentInfo for encKeyPack MUST be filled in as
-follows:
-
-    1.  The content is of type SignedData.  The eContent for
-        the SignedData is of type ReplyKeyPack.
-
-    2.  The eContentType for the SignedData contains the OID value
-        for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1)
-        security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }
-
-    3.  The signerInfos field contains a single signerInfo, which is
-        the signature of the ReplyKeyPack.
-
-    4.  The certificates field contains a signature verification
-        certificate chain that the client will use to verify the
-        KDC's signature over the ReplyKeyPack.  This field may only
-        be left empty if the client included a kdcCert field in the
-        PA-PK-AS-REQ, indicating that it has the KDC's certificate.
-
-    5.  The contentType for the EnvelopedData contains the OID value
-        for id-signedData: { iso (1) member-body (2) us (840) rsadsi
-        (113549) pkcs (1) pkcs7 (7) signedData (2) }
-
-    6.  The recipientInfos field is a SET which MUST contain exactly
-        one member of type KeyTransRecipientInfo.  The encryptedKey
-        for this member contains the temporary key which is
-        encrypted using the client's public key.
-
-    7.  The unprotectedAttrs or originatorInfo fields MAY be
-        present.
-
-
-3.2.4.  Validation of KDC Reply
-
-Upon receipt of the KDC's reply, the client proceeds as follows.  If
-the PA-PK-AS-REP contains a dhSignedData, the client obtains and
-verifies the Diffie-Hellman parameters, and obtains the shared key
-as described above.  Otherwise, the message contains an encKeyPack,
-and the client decrypts and verifies the temporary encryption key.
-
-In either case, the client MUST check to see if the included
-certificate contains a subjectAltName extension of type dNSName or
-iPAddress (if the KDC is specified by IP address instead of name).
-If it does, it MUST check to see if that extension matches the KDC
-it believes it is communicating with, with matching rules specified
-in RFC 2459.  Exception: If the client has some external information
-as to the identity of the KDC, this check MAY be omitted.
-
-The client also MUST check that the KDC's certificate contains an
-extendedKeyUsage OID of id-pkkdcekuoid:
-
-    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-      pkinit(3) pkkdcekuoid(5) }
-
-If all applicable checks are satisfied, the client then decrypts the
-main reply with the resulting key, and then proceeds as described in
-CLARIFICATIONS.
-
-
-4.  Security Considerations
-
-PKINIT raises certain security considerations beyond those that can
-be regulated strictly in protocol definitions.  We will address them
-in this section.
-
-PKINIT extends the cross-realm model to the public-key
-infrastructure.  Users of PKINIT must understand security policies
-and procedures appropriate to the use of Public Key Infrastructures.
-
-Standard Kerberos allows the possibility of interactions between
-cryptosystems of varying strengths; this document adds interactions
-with public-key cryptosystems to Kerberos.  Some administrative
-policies may allow the use of relatively weak public keys.  Using
-such keys to wrap data encrypted under stronger conventional
-cryptosystems may be inappropriate.
-
-PKINIT requires keys for symmetric cryptosystems to be generated.
-Some such systems contain "weak" keys.  For recommendations regarding
-these weak keys, see CLARIFICATIONS.
-
-PKINIT allows the use of a zero nonce in the PKAuthenticator when
-cached Diffie-Hellman keys are used.  In this case, message binding
-is performed using the nonce in the main request in the same way as
-it is done for ordinary AS-REQs (without the PKINIT
-pre-authenticator).  The nonce field in the KDC request body is
-signed through the checksum in the PKAuthenticator, which
-cryptographically binds the PKINIT pre-authenticator to the main
-body of the AS Request and also provides message integrity for the
-full AS Request.
-
-However, when a PKINIT pre-authenticator in the AS-REP has a
-zero-nonce, and an attacker has somehow recorded this
-pre-authenticator and discovered the corresponding Diffie-Hellman
-private key (e.g., with a brute-force attack), the attacker will be
-able to fabricate his own AS-REP messages that impersonate the KDC
-with this same pre-authenticator.  This compromised pre-authenticator
-will remain valid as long as its expiration time has not been reached
-and it is therefore important for clients to check this expiration
-time and for the expiration time to be reasonably short, which
-depends on the size of the Diffie-Hellman group.
-
-If a client also caches its Diffie-Hellman keys, then the session key
-could remain the same during multiple AS-REQ/AS-REP exchanges and an
-attacker which compromised the session key could fabricate his own
-AS-REP messages with a pre-recorded pre-authenticator until the
-client starts using a new Diffie-Hellman key pair and while the KDC
-pre-authenticator has not yet expired.  It is therefore not
-recommended for KDC clients to also cache their Diffie-Hellman keys.
-
-Care should be taken in how certificates are chosen for the purposes
-of authentication using PKINIT.  Some local policies may require
-that key escrow be used for certain certificate types.  Deployers of
-PKINIT should be aware of the implications of using certificates that
-have escrowed keys for the purposes of authentication.
-
-PKINIT does not provide for a "return routability" test to prevent
-attackers from mounting a denial-of-service attack on the KDC by
-causing it to perform unnecessary and expensive public-key
-operations.  Strictly speaking, this is also true of standard
-Kerberos, although the potential cost is not as great, because
-standard Kerberos does not make use of public-key cryptography.
-
-The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
-permit empty SEQUENCEs to be encoded.  Such empty sequences may only
-be used if the KDC itself vouches for the user's certificate.  [This
-seems to reflect the consensus of the Kerberos working group.]
-
-
-5.  Acknowledgements
-
-Some of the ideas on which this document is based arose during
-discussions over several years between members of the SAAG, the IETF
-CAT working group, and the PSRG, regarding integration of Kerberos
-and SPX.  Some ideas have also been drawn from the DASS system.
-These changes are by no means endorsed by these groups.  This is an
-attempt to revive some of the goals of those groups, and this
-document approaches those goals primarily from the Kerberos
-perspective.  Lastly, comments from groups working on similar ideas
-in DCE have been invaluable.
-
-
-6.  Expiration Date
-
-This draft expires January 25, 2004.
-
-
-7.  Bibliography
-
-[1]  RFC-Editor: To be replaced by RFC number for
-draft-ietf-krb-wg-kerberos-clarifications.
-
-[2] R. Housley. Cryptographic Message Syntax., April 1999.
-Request For Comments 2630.
-
-[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers
-for the Internet X.509 Public Key Infrastructure Certificate and
-Certificate Revocation List (CRL) Profile, April 2002. Request For
-Comments 3279.
-
-[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public
-Key Infrastructure Certificate and Certificate Revocation List
-(CRL) Profile, April 2002. Request for Comments 3280.
-
-[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-Specifications, October 1998.  Request for Comments 2437.
-
-[6] RFC-Editor: To be replaced by RFC number for
-draft-ietf-krb-wg-crypto.
-
-[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
-T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
-Request for Comments 3546.
-
-[8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.
-Internet X.509 Public Key Infrastructure: Online Certificate Status
-Protocol - OCSP, June 1999.  Request for Comments 2560.
-
-[9] NIST, Guidelines for Implementing and Using the NBS Encryption
-Standard, April 1981.  FIPS PUB 74.
-
-[10] D. Harkins and D. Carrel.  The Internet Key Exchange (IKE),
-November 1998.  Request for Comments 2409.
-
-
-8.  Authors
-
-Brian Tung
-Clifford Neuman
-USC Information Sciences Institute
-4676 Admiralty Way Suite 1001
-Marina del Rey CA 90292-6695
-Phone: +1 310 822 1511
-E-mail: {brian,bcn}@isi.edu
-
-Matthew Hur
-Ari Medvinsky
-Microsoft Corporation
-One Microsoft Way
-Redmond WA 98052
-Phone: +1 425 707 3336
-E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
-
-Sasha Medvinsky
-Motorola, Inc.
-6450 Sequence Drive
-San Diego, CA 92121
-+1 858 404 2367
-E-mail: smedvinsky@motorola.com
-
-John Wray
-Iris Associates, Inc.
-5 Technology Park Dr.
-Westford, MA 01886
-E-mail: John_Wray@iris.com
-
-Jonathan Trostle
-E-mail: jtrostle@world.std.com
-
-
-Appendix A.  PKINIT ASN.1 Module
-
-KerberosV5-PK-INIT-SPEC {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2) modules(4) pkinit(TBD)
-} DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-    IMPORTS
-        SubjectPublicKeyInfo, AlgorithmIdentifier, Name
-            FROM PKIX1Explicit88 { iso (1) identified-organization (3)
-              dod (6) internet (1) security (5) mechanisms (5)
-              pkix (7) id-mod (0) id-pkix1-explicit (18) }
-
-        ContentInfo, IssuerAndSerialNumber
-            FROM CryptographicMessageSyntax { iso(1) member-body(2)
-              us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
-              modules(0) cms(1) }
-
-        KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey
-            FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-              dod(6) internet(1) security(5) kerberosV5(2) modules(4)
-              krb5spec2(2) } ;
-
-    id-pkinit  OBJECT IDENTIFIER ::=
-      { iso (1) org (3) dod (6) internet (1) security (5)
-        kerberosv5 (2) pkinit (3) }
-
-    id-pkdhkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-    id-pkdhkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-    id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-    id-pkekuoid  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-    id-pkkdcekuoid  OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-    pa-pk-as-req INTEGER ::=                 TBD
-    pa-pk-as-rep INTEGER ::=                 TBD
-    pa-pk-ocsp-req INTEGER ::=               TBD
-    pa-pk-ocsp-rep INTEGER ::=               TBD
-
-    ad-initial-verified-cas INTEGER ::=      TBD
-
-    td-dh-parameters INTEGER ::=             TBD
-    td-trusted-certifiers INTEGER ::=        104
-    td-certificate-index INTEGER ::=         105
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-        signedAuthPack          [0] ContentInfo,
-        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL,
-        ...
-    }
-
-    TrustedCA ::= CHOICE {
-        caName                  [0] Name,
-        issuerAndSerial         [2] IssuerAndSerialNumber,
-        ...
-    }
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-        supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                    OPTIONAL,
-        ...
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER,
-        ctime                   [1] KerberosTime,
-        nonce                   [2] INTEGER (0..4294967295),
-        paChecksum              [3] Checksum,
-        ...
-    }
-
-    TrustedCertifiers ::= SEQUENCE OF Name
-
-    CertificateIndex ::= IssuerAndSerialNumber
-
-    KRB5PrincipalName ::= SEQUENCE {
-        realm                   [0] Realm,
-        principalName           [1] PrincipalName
-    }
-
-    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
-        ca                      [0] Name,
-        validated               [1] BOOLEAN,
-        ...
-    }
-
-    PA-PK-AS-REP ::= CHOICE {
-        dhSignedData            [0] ContentInfo,
-        encKeyPack              [1] ContentInfo,
-        ...
-    }
-
-    KDCDHKeyInfo ::= SEQUENCE {
-        subjectPublicKey        [0] BIT STRING,
-        nonce                   [1] INTEGER,
-        dhKeyExpiration         [2] KerberosTime OPTIONAL,
-        ...
-    }
-
-    ReplyKeyPack ::= SEQUENCE {
-        replyKey                [0] EncryptionKey,
-        nonce                   [1] INTEGER (0..4294967295),
-        ...
-    }
-
-END
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt
deleted file mode 100644
index d2510b526..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt
+++ /dev/null
@@ -1,1036 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-21.txt                   Clifford Neuman
-expires April 25, 2005                                           USC/ISI
-                                                         Sasha Medvinsky
-                                                          Motorola, Inc.
-
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-
-0.  Status Of This Memo
-
-By submitting this Internet-Draft, I certify that any applicable
-patent or other IPR claims of which I am aware have been disclosed,
-or will be disclosed, and any of which I become aware will be
-disclosed, in accordance with RFC 3668.
-
-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."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-The distribution of this memo is unlimited.  It is filed as
-draft-ietf-cat-kerberos-pk-init-21.txt and expires April 25, 2005.
-Please send comments to the authors.
-
-
-1.  Abstract
-
-This document describes protocol extensions (hereafter called
-PKINIT) to the Kerberos protocol specification [1].  These
-extensions provide a method for integrating public key cryptography
-into the initial authentication exchange, by passing digital
-certificates and associated authenticators in preauthentication data
-fields.
-
-
-2.  Introduction
-
-A client typically authenticates itself to a service in Kerberos
-using three distinct though related exchanges.  First, the client
-requests a ticket-granting ticket (TGT) from the Kerberos
-authentication server (AS).  Then, it uses the TGT to request a
-service ticket from the Kerberos ticket-granting server (TGS).
-Usually, the AS and TGS are integrated in a single device known as
-a Kerberos Key Distribution Center, or KDC.  (In this document, we
-will refer to both the AS and the TGS as the KDC.)  Finally, the
-client uses the service ticket to authenticate itself to the
-service.
-
-The advantage afforded by the TGT is that the client need explicitly
-request a ticket and expose his credentials only once.  The TGT and
-its associated session key can then be used for any subsequent
-requests.  One result of this is that all further authentication is
-independent of the method by which the initial authentication was
-performed.  Consequently, initial authentication provides a
-convenient place to integrate public-key cryptography into Kerberos
-authentication.
-
-As defined, Kerberos authentication exchanges use symmetric-key
-cryptography, in part for performance.  One cost of using
-symmetric-key cryptography is that the keys must be shared, so that
-before a client can authenticate itself, he must already be
-registered with the KDC.
-
-Conversely, public-key cryptography (in conjunction with an
-established Public Key Infrastructure) permits authentication
-without prior registration with a KDC.  Adding it to Kerberos allows
-the widespread use of Kerberized applications by clients without
-requiring them to register first with a KDC--a requirement that has
-no inherent security benefit.
-
-As noted above, a convenient and efficient place to introduce
-public-key cryptography into Kerberos is in the initial
-authentication exchange.  This document describes the methods and
-data formats for integrating public-key cryptography into Kerberos
-initial authentication.
-
-
-3.  Extensions
-
-This section describes extensions to [1] for supporting the use of
-public-key cryptography in the initial request for a ticket.
-
-Briefly, this document defines the following extensions to [1]:
-
-    1.  The client indicates the use of public-key authentication by
-        including a special preauthenticator in the initial request.
-        This preauthenticator contains the client's public-key data
-        and a signature.
-
-    2.  The KDC tests the client's request against its policy and
-        trusted Certification Authorities (CAs).
-
-    3.  If the request passes the verification tests, the KDC
-        replies as usual, but the reply is encrypted using either:
-
-        a.  a symmetric encryption key, signed using the KDC's
-            signature key and encrypted using the client's encryption
-            key; or
-
-        b.  a key generated through a Diffie-Hellman exchange with
-            the client, signed using the KDC's signature key.
-
-        Any keying material required by the client to obtain the
-        Encryption key is returned in a preauthentication field
-        accompanying the usual reply.
-
-    4.  The client obtains the encryption key, decrypts the reply,
-        and then proceeds as usual.
-
-Section 3.1 of this document defines the necessary message formats.
-Section 3.2 describes their syntax and use in greater detail.
-
-
-3.1.  Definitions, Requirements, and Constants
-
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119 [12].
-
-
-3.1.1.  Required Algorithms
-
-All PKINIT implementations MUST support the following algorithms:
-
-    - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype.
-
-    - Signature algorithm: SHA-1 digest and RSA.
-
-    - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
-      with a non-zero nonce.
-
-    - Unkeyed checksum type for the paChecksum member of
-      PKAuthenticator: SHA1 (unkeyed), Kerberos checksum type 14
-      [11].
-
-
-3.1.2.  Defined Message and Encryption Types
-
-PKINIT makes use of the following new preauthentication types:
-
-    PA-PK-AS-REQ                             TBD
-    PA-PK-AS-REP                             TBD
-
-PKINIT also makes use of the following new authorization data type:
-
-    AD-INITIAL-VERIFIED-CAS                  TBD
-
-PKINIT introduces the following new error codes:
-
-    KDC_ERR_CLIENT_NOT_TRUSTED                62
-    KDC_ERR_KDC_NOT_TRUSTED                   63
-    KDC_ERR_INVALID_SIG                       64
-    KDC_ERR_KEY_SIZE                          65
-    KDC_ERR_CERTIFICATE_MISMATCH              66
-    KDC_ERR_CANT_VERIFY_CERTIFICATE           70
-    KDC_ERR_INVALID_CERTIFICATE               71
-    KDC_ERR_REVOKED_CERTIFICATE               72
-    KDC_ERR_REVOCATION_STATUS_UNKNOWN         73
-    KDC_ERR_CLIENT_NAME_MISMATCH              75
-
-PKINIT uses the following typed data types for errors:
-
-    TD-DH-PARAMETERS                         TBD
-    TD-TRUSTED-CERTIFIERS                    104
-    TD-CERTIFICATE-INDEX                     105
-    TD-UNKEYED-CHECKSUM-INFO                 109
-
-PKINIT defines the following encryption types, for use in the AS-REQ
-message (to indicate acceptance of the corresponding encryption OIDs
-in PKINIT):
-
-    dsaWithSHA1-CmsOID                         9
-    md5WithRSAEncryption-CmsOID               10
-    sha1WithRSAEncryption-CmsOID              11
-    rc2CBC-EnvOID                             12
-    rsaEncryption-EnvOID   (PKCS1 v1.5)       13
-    rsaES-OAEP-EnvOID      (PKCS1 v2.0)       14
-    des-ede3-cbc-EnvOID                       15
-
-The above encryption types are used by the client only within the
-KDC-REQ-BODY to indicate which CMS [2] algorithms it supports.  Their
-use within Kerberos EncryptedData structures is not specified by this
-document.
-
-The ASN.1 module for all structures defined in this document (plus
-IMPORT statements for all imported structures) are given in Appendix
-A.  In the event of a discrepancy between Appendix A and the portions
-of ASN.1 in the main text, the appendix is normative.
-
-All structures defined in this document MUST be encoded using
-Distinguished Encoding Rules (DER).  All imported data structures
-must be encoded according to the rules specified in Kerberos [1] or
-CMS [2] as appropriate.
-
-Interoperability note: Some implementations may not be able to
-decode CMS objects encoded with BER but not DER; specifically, they
-may not be able to decode infinite length encodings.  To maximize
-interoperability, implementers SHOULD encode CMS objects used in
-PKINIT with DER.
-
-
-3.1.3.  Algorithm Identifiers
-
-PKINIT does not define, but does make use of, the following
-algorithm identifiers.
-
-PKINIT uses the following algorithm identifier for Diffie-Hellman
-key agreement [9]:
-
-    dhpublicnumber
-
-PKINIT uses the following signature algorithm identifiers [8, 12]:
-
-    sha-1WithRSAEncryption (RSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    id-dsa-with-sha1       (DSA with SHA1)
-
-PKINIT uses the following encryption algorithm identifiers [5] for
-encrypting the temporary key with a public key:
-
-    rsaEncryption          (PKCS1 v1.5)
-    id-RSAES-OAEP          (PKCS1 v2.0)
-
-PKINIT uses the following algorithm identifiers [2] for encrypting
-the reply key with the temporary key:
-
-    des-ede3-cbc           (three-key 3DES, CBC mode)
-    rc2-cbc                (RC2, CBC mode)
-    aes256_CBC             (AES-256, CBC mode)
-
-
-3.2.  PKINIT Preauthentication Syntax and Use
-
-This section defines the syntax and use of the various
-preauthentication fields employed by PKINIT.
-
-
-3.2.1.  Client Request
-
-The initial authentication request (AS-REQ) is sent as per [1]; in
-addition, a preauthentication field contains data signed by the
-client's private signature key, as follows:
-
-    WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
-                                    -- Contains a BER encoding of
-                                    -- ContentInfo
-    })
-
-    WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
-                                    -- Contains a BER encoding of
-                                    -- IssuerAndSerialNumber
-    })
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-        signedAuthPack          [0] IMPLICIT WrapContentInfo,
-                                    -- Type is SignedData.
-                                    -- Content is AuthPack
-                                    -- (defined below).
-        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-                                    -- A list of CAs, trusted by
-                                    -- the client, used to certify
-                                    -- KDCs.
-        kdcCert                 [2] IMPLICIT WrapIssuerAndSerial
-                                    OPTIONAL,
-                                    -- Identifies a particular KDC
-                                    -- certificate, if the client
-                                    -- already has it.
-        ...
-    }
-
-    TrustedCA ::= CHOICE {
-        caName                  [1] Name,
-                                    -- Fully qualified X.500 name
-                                    -- as defined in RFC 3280 [4].
-        issuerAndSerial         [2] IMPLICIT WrapIssuerAndSerial,
-                                    -- Identifies a specific CA
-                                    -- certificate.
-        ...
-    }
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                                    -- Defined in RFC 3280 [4].
-                                    -- Present only if the client
-                                    -- is using ephemeral-ephemeral
-                                    -- Diffie-Hellman.
-        supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                    OPTIONAL,
-                                    -- List of CMS encryption types
-                                    -- supported by client in order
-                                    -- of (decreasing) preference.
-        ...
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER (0..999999),
-        ctime                   [1] KerberosTime,
-                                    -- cusec and ctime are used as
-                                    -- in [1], for replay
-                                    -- prevention.
-        nonce                   [2] INTEGER (0..4294967295),
-                                    -- Binds reply to request,
-                                    -- MUST be zero when client
-                                    -- will accept cached
-                                    -- Diffie-Hellman parameters
-                                    -- from KDC. MUST NOT be
-                                    -- zero otherwise.
-        paChecksum              [3] Checksum,
-                                    -- Defined in [1].
-                                    -- Performed over KDC-REQ-BODY,
-                                    -- MUST be unkeyed.
-        ...
-    }
-
-The ContentInfo in the signedAuthPack is filled out as follows:
-
-    1.  The eContent field contains data of type AuthPack.  It MUST
-        contain the pkAuthenticator, and MAY also contain the
-        client's Diffie-Hellman public value (clientPublicValue).
-
-    2.  The eContentType field MUST contain the OID value for
-        id-pkauthdata: { iso(1) org(3) dod(6) internet(1)
-        security(5) kerberosv5(2) pkinit(3) pkauthdata(1)}
-
-    3.  The signerInfos field MUST contain the signature over the
-        AuthPack.
-
-    4.  The certificates field MUST contain at least a signature
-        verification certificate chain that the KDC can use to
-        verify the signature over the AuthPack.  The certificate
-        chain(s) MUST NOT contain the root CA certificate.
-
-    5.  If a Diffie-Hellman key is being used, the parameters MUST
-        be chosen from Oakley Group 2 or 14.  Implementations MUST
-        support Group 2; they are RECOMMENDED to support Group 14.
-        (See RFC 2409 [10].)
-
-    6.  The KDC may wish to use cached Diffie-Hellman parameters.
-        To indicate acceptance of caching, the client sends zero in
-        the nonce field of the pkAuthenticator.  Zero is not a valid
-        value for this field under any other circumstances.  Since
-        zero is used to indicate acceptance of cached parameters,
-        message binding in this case is performed using only the
-        nonce in the main request.
-
-
-3.2.2.  Validation of Client Request
-
-Upon receiving the client's request, the KDC validates it.  This
-section describes the steps that the KDC MUST (unless otherwise
-noted) take in validating the request.
-
-The KDC must look for a client certificate in the signedAuthPack.
-If it cannot find one signed by a CA it trusts, it sends back an
-error of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying
-e-data for this error is a TYPED-DATA (as defined in [1]).  For this
-error, the data-type is TD-TRUSTED-CERTIFIERS, and the data-value is
-the DER encoding of
-
-    TrustedCertifiers ::= SEQUENCE OF Name
-
-If, while verifying the certificate chain, the KDC determines that
-the signature on one of the certificates in the signedAuthPack is
-invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
-The accompanying e-data for this error is a TYPED-DATA, whose
-data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER
-encoding of the index into the CertificateSet field, ordered as sent
-by the client:
-
-    CertificateIndex ::= IssuerAndSerialNumber
-                                    -- IssuerAndSerialNumber of
-                                    -- certificate with invalid signature
-
-If more than one certificate signature is invalid, the KDC MAY send
-one TYPED-DATA per invalid signature.
-
-The KDC MAY also check whether any certificates in the client's
-chain have been revoked.  If any of them have been revoked, the KDC
-MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
-attempts to determine the revocation status but is unable to do so,
-it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
-The certificate or certificates affected are identified exactly as
-for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
-
-In addition to validating the certificate chain, the KDC MUST also
-check that the certificate properly maps to the client's principal name
-as specified in the AS-REQ as follows:
-
-    1.  If the KDC has its own mapping from the name in the
-        certificate to a Kerberos name, it uses that Kerberos
-        name.
-
-    2.  Otherwise, if the certificate contains a SubjectAltName
-        extension with a Kerberos name in the otherName field,
-        it uses that name. The otherName field (of type AnotherName)
-        in the SubjectAltName extension MUST contain the following:
-
-        The type-id is:
-
-        krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6)
-        internet (1) security (5) kerberosv5 (2) 2 }
-
-        The value is:
-
-        KRB5PrincipalName ::= SEQUENCE {
-            realm                   [0] Realm,
-            principalName           [1] PrincipalName
-        }
-
-If the KDC does not have its own mapping and there is no Kerberos
-name present in the certificate, or if the name in the request does
-not match the name in the certificate (including the realm name), or
-if there is no name in the request, the KDC MUST return error code
-KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
-for this error.
-
-Even if the chain is validated, and the names in the certificate and
-the request match, the KDC may decide not to trust the client.  For
-example, the certificate may include an Extended Key Usage (EKU) OID
-in the extensions field.  As a matter of local policy, the KDC may
-decide to reject requests on the basis of the absence or presence of
-specific EKU OIDs.  In this case, the KDC MUST return error code
-KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as:
-
-    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-      pkinit(3) pkekuoid(4) }
-
-If the client's signature on the signedAuthPack fails to verify, the KDC
-MUST return error KDC_ERR_INVALID_SIG.  There is no accompanying
-e-data for this error.
-
-The KDC MUST check the timestamp to ensure that the request is not
-a replay, and that the time skew falls within acceptable limits.
-The recommendations clock skew times in [1] apply here.  If the
-check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT or
-KRB_AP_ERR_SKEW, respectively.
-
-If the clientPublicValue is filled in, indicating that the client
-wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to
-see if the parameters satisfy its policy.  If they do not, it MUST
-return error code KDC_ERR_KEY_SIZE.  The accompanying e-data is a
-TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose
-data-value is the DER encoding of a DomainParameters (see [3]),
-including appropriate Diffie-Hellman parameters with which to retry
-the request.
-
-The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
-client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
-not have the corresponding certificate.
-
-The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
-did not include a kdcCert field, but did include a trustedCertifiers
-field, and the KDC does not possesses a certificate issued by one of
-the listed certifiers.
-
-If there is a supportedCMSTypes field in the AuthPack, the KDC must
-check to see if it supports any of the listed types.  If it supports
-more than one of the types, the KDC SHOULD use the one listed first.
-If it does not support any of them, it MUST return an error of type
-KRB5KDC_ERR_ETYPE_NOSUPP.
-
-
-3.2.3.  KDC Reply
-
-Assuming that the client's request has been properly validated, the
-KDC proceeds as per [1], except as follows.
-
-The KDC MUST set the initial flag and include an authorization data
-of type AD-INITIAL-VERIFIED-CAS in the issued ticket.  The value is
-an OCTET STRING containing the DER encoding of InitialVerifiedCAs:
-
-    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
-        ca                      [0] Name,
-        Validated               [1] BOOLEAN,
-        ...
-    }
-
-The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-containers if the list of CAs satisfies the KDC's realm's policy.
-(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.)
-Furthermore, any TGS must copy such authorization data from tickets
-used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
-including the AD-IF-RELEVANT container, if present.
-
-Application servers that understand this authorization data type
-SHOULD apply local policy to determine whether a given ticket
-bearing such a type *not* contained within an AD-IF-RELEVANT
-container is acceptable.  (This corresponds to the AP server
-checking the transited field when the TRANSITED-POLICY-CHECKED flag
-has not been set.)  If such a data type is contained within an
-AD-IF-RELEVANT container, AP servers MAY apply local policy to
-determine whether the authorization data is acceptable.
-
-The AS-REP is otherwise unchanged from [1].  The KDC encrypts the
-reply as usual, but not with the client's long-term key.  Instead,
-it encrypts it with either a generated encryption key, or a key
-derived from a Diffie-Hellman exchange. The contents of the
-PA-PK-AS-REP indicate the type of encryption key that was used:
-
-    PA-PK-AS-REP ::= CHOICE {
-        dhSignedData            [0] IMPLICIT WrapContentInfo,
-                                    -- Type is SignedData.
-                                    -- Content is KDCDHKeyInfo
-                                    -- (defined below).
-        encKeyPack              [1] IMPLICIT WrapContentInfo,
-                                    -- Type is EnvelopedData.
-                                    -- Content is SignedData over
-                                    -- ReplyKeyPack (defined below).
-        ...
-    }
-
-    KDCDHKeyInfo ::= SEQUENCE {
-        subjectPublicKey        [0] BIT STRING,
-                                    -- Equals public exponent
-                                    -- (g^a mod p).
-                                    -- INTEGER encoded as payload
-                                    -- of BIT STRING.
-        nonce                   [1] INTEGER (0..4294967295),
-                                    -- Binds reply to request.
-                                    -- Exception: A value of zero
-                                    -- indicates that the KDC is
-                                    -- using cached values.
-        dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                                    -- Expiration time for KDC's
-                                    -- cached values.
-        ...
-    }
-
-The fields of the ContentInfo for dhSignedData are to be filled in
-as follows:
-
-    1.  The eContent field contains data of type KDCDHKeyInfo.
-
-    2.  The eContentType field contains the OID value for
-        id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
-        security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }
-
-    3.  The signerInfos field contains a single signerInfo, which is
-        the signature of the KDCDHKeyInfo.
-
-    4.  The certificates field contains a signature verification
-        certificate chain that the client will use to verify the
-        KDC's signature over the KDCDHKeyInfo.  This field may only
-        be left empty if the client did include a kdcCert field in
-        the PA-PK-AS-REQ, indicating that it has the KDC's
-        certificate.  The certificate chain MUST NOT contain the
-        root CA certificate.
-
-    5.  If the client and KDC agree to use cached parameters, the
-        KDC MUST return a zero in the nonce field and include the
-        expiration time of the cached values in the dhKeyExpiration
-        field.  If this time is exceeded, the client MUST NOT use
-        the reply.  If the time is absent, the client MUST NOT use
-        the reply and MAY resubmit a request with a non-zero nonce,
-        thus indicating non-acceptance of the cached parameters.
-
-The KDC reply key is derived as follows:
-
-    1.  Both the KDC and the client calculate the shared secret
-        value
-
-            DHKey = g^(ab) mod p
-
-        where a and b are the client's and KDC's private exponents,
-        respectively.  DHKey, padded first with leading zeros as
-        needed to make it as long as the modulus p, is represented
-        as a string of octets in big-endian order (such that the
-        size of DHKey in octets is the size of the modulus p).
-
-    2.  Let K be the key-generation seed length [6] of the reply key
-        whose enctype is selected according to [1].
-
-    3.  Define the function octetstring2key() as follows:
-
-            octetstring2key(h, x) == random-to-key(K-truncate(
-                                         h(0x00 | x) |
-                                         h(0x01 | x) |
-                                         h(0x02 | x) |
-                                         ...
-                                     ))
-
-        where x is an octet string; h:octet string -> octet string
-        is a cryptographically strong hash function; | is the
-        concatenation operator; 0x00, 0x01, 0x02, etc. are each
-        represented as a single octet; random-to-key() is an
-        operation that generates a protocolkey from a bitstring of
-        length K; and K-truncate truncates its input to K bits.
-        Both K and random-to-key() are defined in the kcrypto
-        profile [6] for the enctype of the reply key.
-
-        A good example of h() is SHA1.
-
-    4.  Define H to be a hash function based on operations of a
-        given checksum type [6], as follows:
-
-            H(x) = get_mic(dummy-key, x)
-
-        where x is an octet string.
-
-        H() MUST be a cryptographically strong hash, in order to be
-        suitable for use in the octetstring2key() operation above.
-
-    5.  The client specifies a checksum type to use in the
-        paChecksum of the PKAuthenticator.  If the H() operation
-        based on this checksum is not suitable for use in
-        octetstring2key(), or this checksum type is too weak or not
-        supported by the KDC, the KDC MUST return an error of type
-        KDC_ERR_PA_CKSUMTYPE_NOT_SUPPORTED.  The accompanying e-data
-        for this error is a TYPED-DATA: the data-type is
-        TD-UNKEYED-CHECKSUM-INFO, and the data-value is the DER
-        encoding of
-
-            UNKEYED-CHECKSUM-INFO ::= SEQUENCE OF SEQUENCE {
-                cksumtype       [0] Int32,
-                ...
-            }
-
-        This list is in the preference order (best choice first) of
-        the KDC, and the client SHOULD retry with the first
-        available checksum type.
-
-    6.  When cached DH parameters are used, let n_c be the
-        clientDHNonce, and n_k be the serverDHNonce; otherwise, let
-        both n_c and n_k be empty octet strings.  The reply key k is
-
-            k = octetstring2key(H, DHKey | n_c | n_k)
-
-        where H() is the hash function based on the checksum type
-        used in the paChecksum of the PKAuthenticator (as defined in
-        step 4).
-
-Both the KDC and the client calculate
-the value g^(ab) mod p, where a and b are the client's and KDC's
-private exponents, respectively.  They both take the first k bits of
-this secret value as a key generation seed, where the parameter k
-(the size of the seed) is dependent on the selected key type, as
-specified in [6].  The seed is then converted into a protocol key by
-applying to it a random-to-key function, which is also dependent on
-key type.
-
-If the KDC and client are not using Diffie-Hellman, the KDC encrypts
-the reply with an encryption key, packed in the encKeyPack, which
-contains data of type ReplyKeyPack:
-
-    ReplyKeyPack ::= SEQUENCE {
-        replyKey                [0] EncryptionKey,
-                                    -- Defined in [1].
-                                    -- Used to encrypt main reply.
-                                    -- MUST be at least as strong
-                                    -- as session key.  (Using the
-                                    -- same enctype and a strong
-                                    -- prng should suffice, if no
-                                    -- stronger encryption system
-                                    -- is available.)
-        nonce                   [1] INTEGER (0..4294967295),
-                                    -- Binds reply to request.
-        ...
-    }
-
-The fields of the ContentInfo for encKeyPack MUST be filled in as
-follows:
-
-    1.  The content is of type SignedData.  The eContent for
-        the SignedData is of type ReplyKeyPack.
-
-    2.  The eContentType for the SignedData contains the OID value
-        for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1)
-        security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }
-
-    3.  The signerInfos field contains a single signerInfo, which is
-        the signature of the ReplyKeyPack.
-
-    4.  The certificates field contains a signature verification
-        certificate chain that the client will use to verify the
-        KDC's signature over the ReplyKeyPack.  This field may only
-        be left empty if the client included a kdcCert field in the
-        PA-PK-AS-REQ, indicating that it has the KDC's certificate.
-        The certificate chain MUST NOT contain the root CA
-        certificate.
-
-    5.  The contentType for the EnvelopedData contains the OID value
-        for id-signedData: { iso (1) member-body (2) us (840) rsadsi
-        (113549) pkcs (1) pkcs7 (7) signedData (2) }
-
-    6.  The recipientInfos field is a SET which MUST contain exactly
-        one member of type KeyTransRecipientInfo.  The encryptedKey
-        for this member contains the temporary key which is
-        encrypted using the client's public key.
-
-    7.  The unprotectedAttrs or originatorInfo fields MAY be
-        present.
-
-
-3.2.4.  Validation of KDC Reply
-
-Upon receipt of the KDC's reply, the client proceeds as follows.  If
-the PA-PK-AS-REP contains a dhSignedData, the client obtains and
-verifies the Diffie-Hellman parameters, and obtains the shared key
-as described above.  Otherwise, the message contains an encKeyPack,
-and the client decrypts and verifies the temporary encryption key.
-
-In either case, the client MUST check to see if the included
-certificate contains a subjectAltName extension of type dNSName or
-iPAddress (if the KDC is specified by IP address instead of name).
-If it does, it MUST check to see if that extension matches the KDC
-it believes it is communicating with, with matching rules specified
-in RFC 2459.  Exception: If the client has some external information
-as to the identity of the KDC, this check MAY be omitted.
-
-The client also MUST check that the KDC's certificate contains an
-extendedKeyUsage OID of id-pkkdcekuoid:
-
-    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-      pkinit(3) pkkdcekuoid(5) }
-
-If all applicable checks are satisfied, the client then decrypts the
-main reply with the resulting key, and then proceeds as described in
-[1].
-
-
-4.  Security Considerations
-
-PKINIT raises certain security considerations beyond those that can
-be regulated strictly in protocol definitions.  We will address them
-in this section.
-
-PKINIT extends the cross-realm model to the public-key
-infrastructure.  Users of PKINIT must understand security policies
-and procedures appropriate to the use of Public Key Infrastructures.
-
-Standard Kerberos allows the possibility of interactions between
-cryptosystems of varying strengths; this document adds interactions
-with public-key cryptosystems to Kerberos.  Some administrative
-policies may allow the use of relatively weak public keys.  Using
-such keys to wrap data encrypted under stronger conventional
-cryptosystems may be inappropriate.
-
-PKINIT requires keys for symmetric cryptosystems to be generated.
-Some such systems contain "weak" keys.  For recommendations regarding
-these weak keys, see [1].
-
-PKINIT allows the use of a zero nonce in the PKAuthenticator when
-cached Diffie-Hellman keys are used.  In this case, message binding
-is performed using the nonce in the main request in the same way as
-it is done for ordinary AS-REQs (without the PKINIT
-pre-authenticator).  The nonce field in the KDC request body is
-signed through the checksum in the PKAuthenticator, which
-cryptographically binds the PKINIT pre-authenticator to the main
-body of the AS Request and also provides message integrity for the
-full AS Request.
-
-However, when a PKINIT pre-authenticator in the AS-REP has a
-zero-nonce, and an attacker has somehow recorded this
-pre-authenticator and discovered the corresponding Diffie-Hellman
-private key (e.g., with a brute-force attack), the attacker will be
-able to fabricate his own AS-REP messages that impersonate the KDC
-with this same pre-authenticator.  This compromised pre-authenticator
-will remain valid as long as its expiration time has not been reached
-and it is therefore important for clients to check this expiration
-time and for the expiration time to be reasonably short, which
-depends on the size of the Diffie-Hellman group.
-
-If a client also caches its Diffie-Hellman keys, then the session key
-could remain the same during multiple AS-REQ/AS-REP exchanges and an
-attacker which compromised the session key could fabricate his own
-AS-REP messages with a pre-recorded pre-authenticator until the
-client starts using a new Diffie-Hellman key pair and while the KDC
-pre-authenticator has not yet expired.  It is therefore not
-recommended for KDC clients to also cache their Diffie-Hellman keys.
-
-Care should be taken in how certificates are chosen for the purposes
-of authentication using PKINIT.  Some local policies may require
-that key escrow be used for certain certificate types.  Deployers of
-PKINIT should be aware of the implications of using certificates that
-have escrowed keys for the purposes of authentication.
-
-PKINIT does not provide for a "return routability" test to prevent
-attackers from mounting a denial-of-service attack on the KDC by
-causing it to perform unnecessary and expensive public-key
-operations.  Strictly speaking, this is also true of standard
-Kerberos, although the potential cost is not as great, because
-standard Kerberos does not make use of public-key cryptography.
-
-The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
-permit empty SEQUENCEs to be encoded.  Such empty sequences may only
-be used if the KDC itself vouches for the user's certificate.  [This
-seems to reflect the consensus of the Kerberos working group.]
-
-
-5.  Acknowledgements
-
-The following people have made significant contributions to this
-draft: Ari Medvinsky, Matt Hur, John Wray, Jonathan Trostle, Nicolas
-Williams, Tom Yu, Sam Hartman, and Jeff Hutzelman.
-
-Some of the ideas on which this document is based arose during
-discussions over several years between members of the SAAG, the IETF
-CAT working group, and the PSRG, regarding integration of Kerberos
-and SPX.  Some ideas have also been drawn from the DASS system.
-These changes are by no means endorsed by these groups.  This is an
-attempt to revive some of the goals of those groups, and this
-document approaches those goals primarily from the Kerberos
-perspective.  Lastly, comments from groups working on similar ideas
-in DCE have been invaluable.
-
-
-6.  Expiration Date
-
-This draft expires January 25, 2004.
-
-
-7.  Bibliography
-
-[1] RFC-Editor: To be replaced by RFC number for
-draft-ietf-krb-wg-kerberos-clarifications.
-
-[2] R. Housley. Cryptographic Message Syntax. April 1999.  Request
-For Comments 2630.
-
-[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers
-for the Internet X.509 Public Key Infrastructure Certificate and
-Certificate Revocation List (CRL) Profile, April 2002. Request For
-Comments 3279.
-
-[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public
-Key Infrastructure Certificate and Certificate Revocation List
-(CRL) Profile, April 2002. Request for Comments 3280.
-
-[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-Specifications, October 1998.  Request for Comments 2437.
-
-[6] RFC-Editor: To be replaced by RFC number for
-draft-ietf-krb-wg-crypto.
-
-[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
-T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
-Request for Comments 3546.
-
-[8] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams.
-Internet X.509 Public Key Infrastructure: Online Certificate Status
-Protocol - OCSP, June 1999.  Request for Comments 2560.
-
-[9] NIST, Guidelines for Implementing and Using the NBS Encryption
-Standard, April 1981.  FIPS PUB 74.
-
-[10] D. Harkins and D. Carrel.  The Internet Key Exchange (IKE),
-November 1998.  Request for Comments 2409.
-
-[11] K. Raeburn.  Unkeyed SHA-1 Checksum Specification for Kerberos
-5.  Internet-Draft, draft-ietf-krb-wg-sha1-00.txt.
-
-[12] S. Bradner.  Key Words for Use in RFCs to Indicate Requirement
-Levels.  March 1997.  Request for Comments 2119 (BCP 14).
-
-
-8.  Authors
-
-Brian Tung
-Clifford Neuman
-USC Information Sciences Institute
-4676 Admiralty Way Suite 1001
-Marina del Rey CA 90292-6695
-Phone: +1 310 822 1511
-E-mail: {brian,bcn}@isi.edu
-
-Matthew Hur
-Ari Medvinsky
-Microsoft Corporation
-One Microsoft Way
-Redmond WA 98052
-Phone: +1 425 707 3336
-E-mail: matthur@microsoft.com, arimed@windows.microsoft.com
-
-Sasha Medvinsky
-Motorola, Inc.
-6450 Sequence Drive
-San Diego, CA 92121
-+1 858 404 2367
-E-mail: smedvinsky@motorola.com
-
-John Wray
-Iris Associates, Inc.
-5 Technology Park Dr.
-Westford, MA 01886
-E-mail: John_Wray@iris.com
-
-Jonathan Trostle
-E-mail: jtrostle@world.std.com
-
-
-Appendix A.  PKINIT ASN.1 Module
-
-KerberosV5-PK-INIT-SPEC {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2) modules(4) pkinit(TBD)
-} DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-    IMPORTS
-        SubjectPublicKeyInfo, AlgorithmIdentifier, Name
-            FROM PKIX1Explicit88 { iso (1) identified-organization (3)
-              dod (6) internet (1) security (5) mechanisms (5)
-              pkix (7) id-mod (0) id-pkix1-explicit (18) }
-
-        ContentInfo, IssuerAndSerialNumber
-            FROM CryptographicMessageSyntax { iso(1) member-body(2)
-              us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
-              modules(0) cms(1) }
-
-        KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey
-            FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-              dod(6) internet(1) security(5) kerberosV5(2) modules(4)
-              krb5spec2(2) } ;
-
-    id-pkinit  OBJECT IDENTIFIER ::=
-      { iso (1) org (3) dod (6) internet (1) security (5)
-        kerberosv5 (2) pkinit (3) }
-
-    id-pkdhkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-    id-pkdhkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-    id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-    id-pkekuoid  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-    id-pkkdcekuoid  OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-    pa-pk-as-req INTEGER ::=                 TBD
-    pa-pk-as-rep INTEGER ::=                 TBD
-    pa-pk-ocsp-req INTEGER ::=               TBD
-    pa-pk-ocsp-rep INTEGER ::=               TBD
-
-    ad-initial-verified-cas INTEGER ::=      TBD
-
-    td-dh-parameters INTEGER ::=             TBD
-    td-trusted-certifiers INTEGER ::=        104
-    td-certificate-index INTEGER ::=         105
-
-    WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
-                                    -- Contains a BER encoding of
-                                    -- ContentInfo
-    })
-
-    WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
-                                    -- Contains a BER encoding of
-                                    -- IssuerAndSerialNumber
-    })
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-        signedAuthPack          [0] IMPLICIT WrapContentInfo,
-        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-        kdcCert                 [2] IMPLICIT WrapIssuerAndSerial
-                                    OPTIONAL,
-        ...
-    }
-
-    TrustedCA ::= CHOICE {
-        caName                  [1] Name,
-        issuerAndSerial         [2] IMPLICIT WrapIssuerAndSerial,
-        ...
-    }
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-        supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                    OPTIONAL,
-        ...
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER (0..999999),
-        ctime                   [1] KerberosTime,
-        nonce                   [2] INTEGER (0..4294967295),
-        paChecksum              [3] Checksum,
-        ...
-    }
-
-    TrustedCertifiers ::= SEQUENCE OF Name
-
-    CertificateIndex ::= IssuerAndSerialNumber
-
-    KRB5PrincipalName ::= SEQUENCE {
-        realm                   [0] Realm,
-        principalName           [1] PrincipalName
-    }
-
-    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
-        ca                      [0] Name,
-        validated               [1] BOOLEAN,
-        ...
-    }
-
-    PA-PK-AS-REP ::= CHOICE {
-        dhSignedData            [0] IMPLICIT WrapContentInfo,
-        encKeyPack              [1] IMPLICIT WrapContentInfo,
-        ...
-    }
-
-    KDCDHKeyInfo ::= SEQUENCE {
-        subjectPublicKey        [0] BIT STRING,
-        nonce                   [1] INTEGER (0..4294967295),
-        dhKeyExpiration         [2] KerberosTime OPTIONAL,
-        ...
-    }
-
-    ReplyKeyPack ::= SEQUENCE {
-        replyKey                [0] EncryptionKey,
-        nonce                   [1] INTEGER (0..4294967295),
-        ...
-    }
-
-END
-
-Copyright (C) The Internet Society 2004.  This document is subject
-to the rights, licenses and restrictions contained in BCP 78, and
-except as set forth therein, the authors retain all their rights.
-
-This document and the information contained herein are provided on
-an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
-REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
-INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-22.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-22.txt
deleted file mode 100644
index 7f9fe5df6..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-22.txt
+++ /dev/null
@@ -1,1016 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-22.txt                   Clifford Neuman
-expires May 15, 2005                                             USC/ISI
-                                                         Sasha Medvinsky
-                                                          Motorola, Inc.
-                                                               Larry Zhu
-                                                               Microsoft
-
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-
-0.  Status Of This Memo
-
-By submitting this Internet-Draft, I certify that any applicable
-patent or other IPR claims of which I am aware have been disclosed,
-or will be disclosed, and any of which I become aware will be
-disclosed, in accordance with RFC 3668.
-
-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."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-The distribution of this memo is unlimited.  It is filed as
-draft-ietf-cat-kerberos-pk-init-22.txt and expires May 15, 2005.
-Please send comments to the authors.
-
-
-1.  Abstract
-
-This document describes protocol extensions (hereafter called
-PKINIT) to the Kerberos protocol specification [1].  These
-extensions provide a method for integrating public key cryptography
-into the initial authentication exchange, by passing digital
-certificates and associated authenticators in preauthentication data
-fields.
-
-
-2.  Introduction
-
-A client typically authenticates itself to a service in Kerberos
-using three distinct though related exchanges.  First, the client
-requests a ticket-granting ticket (TGT) from the Kerberos
-authentication server (AS).  Then, it uses the TGT to request a
-service ticket from the Kerberos ticket-granting server (TGS).
-Usually, the AS and TGS are integrated in a single device known as
-a Kerberos Key Distribution Center, or KDC.  (In this document, we
-will refer to both the AS and the TGS as the KDC.)  Finally, the
-client uses the service ticket to authenticate itself to the
-service.
-
-The advantage afforded by the TGT is that the client need explicitly
-request a ticket and expose his credentials only once.  The TGT and
-its associated session key can then be used for any subsequent
-requests.  One result of this is that all further authentication is
-independent of the method by which the initial authentication was
-performed.  Consequently, initial authentication provides a
-convenient place to integrate public-key cryptography into Kerberos
-authentication.
-
-As defined, Kerberos authentication exchanges use symmetric-key
-cryptography, in part for performance.  One cost of using
-symmetric-key cryptography is that the keys must be shared, so that
-before a client can authenticate itself, he must already be
-registered with the KDC.
-
-Conversely, public-key cryptography (in conjunction with an
-established Public Key Infrastructure) permits authentication
-without prior registration with a KDC.  Adding it to Kerberos allows
-the widespread use of Kerberized applications by clients without
-requiring them to register first with a KDC--a requirement that has
-no inherent security benefit.
-
-As noted above, a convenient and efficient place to introduce
-public-key cryptography into Kerberos is in the initial
-authentication exchange.  This document describes the methods and
-data formats for integrating public-key cryptography into Kerberos
-initial authentication.
-
-
-3.  Extensions
-
-This section describes extensions to [1] for supporting the use of
-public-key cryptography in the initial request for a ticket.
-
-Briefly, this document defines the following extensions to [1]:
-
-    1.  The client indicates the use of public-key authentication by
-        including a special preauthenticator in the initial request.
-        This preauthenticator contains the client's public-key data
-        and a signature.
-
-    2.  The KDC tests the client's request against its policy and
-        trusted Certification Authorities (CAs).
-
-    3.  If the request passes the verification tests, the KDC
-        replies as usual, but the reply is encrypted using either:
-
-        a.  a symmetric encryption key, signed using the KDC's
-            signature key and encrypted using the client's encryption
-            key; or
-
-        b.  a key generated through a Diffie-Hellman exchange with
-            the client, signed using the KDC's signature key.
-
-        Any keying material required by the client to obtain the
-        Encryption key is returned in a preauthentication field
-        accompanying the usual reply.
-
-    4.  The client obtains the encryption key, decrypts the reply,
-        and then proceeds as usual.
-
-Section 3.1 of this document defines the necessary message formats.
-Section 3.2 describes their syntax and use in greater detail.
-
-
-3.1.  Definitions, Requirements, and Constants
-
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119 [12].
-
-
-3.1.1.  Required Algorithms
-
-All PKINIT implementations MUST support the following algorithms:
-
-    - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype.
-
-    - Signature algorithm: SHA-1 digest and RSA.
-
-    - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
-      with a non-zero nonce.
-
-    - Unkeyed checksum type for the paChecksum member of
-      PKAuthenticator: SHA1 (unkeyed), Kerberos checksum type 14
-      [11].
-
-
-3.1.2.  Defined Message and Encryption Types
-
-PKINIT makes use of the following new preauthentication types:
-
-    PA-PK-AS-REQ                             TBD
-    PA-PK-AS-REP                             TBD
-    PA-PK-AS-ERR                             TBD
-
-PKINIT also makes use of the following new authorization data type:
-
-    AD-INITIAL-VERIFIED-CAS                  TBD
-
-PKINIT introduces the following new error codes:
-
-    KDC_ERR_CLIENT_NOT_TRUSTED                62
-    KDC_ERR_KDC_NOT_TRUSTED                   63
-    KDC_ERR_INVALID_SIG                       64
-    KDC_ERR_KEY_SIZE                          65
-    KDC_ERR_CERTIFICATE_MISMATCH              66
-    KDC_ERR_CANT_VERIFY_CERTIFICATE           70
-    KDC_ERR_INVALID_CERTIFICATE               71
-    KDC_ERR_REVOKED_CERTIFICATE               72
-    KDC_ERR_REVOCATION_STATUS_UNKNOWN         73
-    KDC_ERR_CLIENT_NAME_MISMATCH              75
-
-PKINIT uses the following typed data types for errors:
-
-    TD-DH-PARAMETERS                         TBD
-    TD-TRUSTED-CERTIFIERS                    104
-    TD-CERTIFICATE-INDEX                     105
-    TD-UNKEYED-CHECKSUM-INFO                 109
-
-PKINIT defines the following encryption types, for use in the AS-REQ
-message (to indicate acceptance of the corresponding encryption OIDs
-in PKINIT):
-
-    dsaWithSHA1-CmsOID                         9
-    md5WithRSAEncryption-CmsOID               10
-    sha1WithRSAEncryption-CmsOID              11
-    rc2CBC-EnvOID                             12
-    rsaEncryption-EnvOID   (PKCS1 v1.5)       13
-    rsaES-OAEP-EnvOID      (PKCS1 v2.0)       14
-    des-ede3-cbc-EnvOID                       15
-
-The above encryption types are used by the client only within the
-KDC-REQ-BODY to indicate which CMS [14] algorithms it supports.  Their
-use within Kerberos EncryptedData structures is not specified by this
-document.
-
-The ASN.1 module for all structures defined in this document (plus
-IMPORT statements for all imported structures) are given in Appendix
-A.  In the event of a discrepancy between Appendix A and the portions
-of ASN.1 in the main text, the appendix is normative.
-
-All structures defined in this document MUST be encoded using
-Distinguished Encoding Rules (DER).  All imported data structures
-must be encoded according to the rules specified in Kerberos [1] or
-CMS [2] as appropriate.
-
-Interoperability note: Some implementations may not be able to
-decode CMS objects encoded with BER but not DER; specifically, they
-may not be able to decode infinite length encodings.  To maximize
-interoperability, implementers SHOULD encode CMS objects used in
-PKINIT with DER.
-
-
-3.1.3.  Algorithm Identifiers
-
-PKINIT does not define, but does make use of, the following
-algorithm identifiers.
-
-PKINIT uses the following algorithm identifier for Diffie-Hellman
-key agreement [9]:
-
-    dhpublicnumber
-
-PKINIT uses the following signature algorithm identifiers [8, 12]:
-
-    sha-1WithRSAEncryption (RSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    id-dsa-with-sha1       (DSA with SHA1)
-
-PKINIT uses the following encryption algorithm identifiers [5] for
-encrypting the temporary key with a public key:
-
-    rsaEncryption          (PKCS1 v1.5)
-    id-RSAES-OAEP          (PKCS1 v2.0)
-
-PKINIT uses the following algorithm identifiers [14, 8] for
-encrypting the reply key with the temporary key:
-
-    des-ede3-cbc           (three-key 3DES, CBC mode)
-    rc2-cbc                (RC2, CBC mode)
-    id-aes256-CBC          (AES-256, CBC mode)
-
-
-3.2.  PKINIT Preauthentication Syntax and Use
-
-This section defines the syntax and use of the various
-preauthentication fields employed by PKINIT.
-
-
-3.2.1.  Client Request
-
-The initial authentication request (AS-REQ) is sent as per [1]; in
-addition, a preauthentication field contains data signed by the
-client's private signature key, as follows:
-
-    WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
-                                    -- Contains a BER encoding of
-                                    -- ContentInfo
-    })
-
-    WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
-                                    -- Contains a BER encoding of
-                                    -- IssuerAndSerialNumber
-    })
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-        signedAuthPack          [0] IMPLICIT WrapContentInfo,
-                                    -- Type is SignedData.
-                                    -- Content is AuthPack
-                                    -- (defined below).
-        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-                                    -- A list of CAs, trusted by
-                                    -- the client, used to certify
-                                    -- KDCs.
-        kdcCert                 [2] IMPLICIT WrapIssuerAndSerial
-                                    OPTIONAL,
-                                    -- Identifies a particular KDC
-                                    -- certificate, if the client
-                                    -- already has it.
-        ...
-    }
-
-    TrustedCA ::= CHOICE {
-        caName                  [1] Name,
-                                    -- Fully qualified X.500 name
-                                    -- as defined in RFC 3280 [4].
-        issuerAndSerial         [2] IMPLICIT WrapIssuerAndSerial,
-                                    -- Identifies a specific CA
-                                    -- certificate.
-        ...
-    }
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                                    -- Defined in RFC 3280 [4].
-                                    -- Present only if the client
-                                    -- is using ephemeral-ephemeral
-                                    -- Diffie-Hellman.
-        supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                    OPTIONAL,
-                                    -- List of CMS encryption types
-                                    -- supported by client in order
-                                    -- of (decreasing) preference.
-        ...
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER (0..999999),
-        ctime                   [1] KerberosTime,
-                                    -- cusec and ctime are used as
-                                    -- in [1], for replay
-                                    -- prevention.
-        nonce                   [2] INTEGER (0..4294967295),
-                                    -- Binds reply to request,
-                                    -- MUST be zero when client
-                                    -- will accept cached
-                                    -- Diffie-Hellman parameters
-                                    -- from KDC. MUST NOT be
-                                    -- zero otherwise.
-        paChecksum              [3] OCTET STRING OPTIONAL,
-                                    -- Defined in [1].
-                                    -- Performed over KDC-REQ-BODY,
-                                    -- MUST be unkeyed.
-        ...
-    }
-
-The ContentInfo in the signedAuthPack is filled out as follows:
-
-    1.  The eContent field MUST contain data of type AuthPack.
-        The supportedCMSTypes field is filled with the algorithm
-        identifiers that the client supports, in order of
-        preference, with most preferred first.
-
-    2.  The eContentType field MUST contain the OID value for
-        id-pkauthdata: { iso(1) org(3) dod(6) internet(1)
-        security(5) kerberosv5(2) pkinit(3) pkauthdata(1)}
-
-    3.  The signerInfos field MUST contain the signature over the
-        AuthPack.
-
-    4.  The certificates field MUST contain at least a signature
-        verification certificate chain that the KDC can use to
-        verify the signature over the AuthPack.  The certificate
-        chain(s) MUST NOT contain the root CA certificate.
-
-    5.  If a Diffie-Hellman key is being used, the parameters MUST
-        be chosen from Oakley Group 2 or 14.  Implementations MUST
-        support Group 2; they are RECOMMENDED to support Group 14.
-        (See RFC 2409 [10] and RFC 3526 [13].)
-
-    6.  The KDC may wish to use cached Diffie-Hellman parameters.
-        To indicate acceptance of caching, the client sends zero in
-        the nonce field of the pkAuthenticator.  Zero is not a valid
-        value for this field under any other circumstances.  Since
-        zero is used to indicate acceptance of cached parameters,
-        message binding in this case is performed using only the
-        nonce in the main request.
-
-
-3.2.2.  Validation of Client Request
-
-Upon receiving the client's request, the KDC validates it.  This
-section describes the steps that the KDC MUST (unless otherwise
-noted) take in validating the request.
-
-The KDC must look for a client certificate in the signedAuthPack.
-If it cannot find one signed by a CA it trusts, it sends back an
-error of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying
-e-data for this error is a TYPED-DATA (as defined in [1]).  For this
-error, the data-type is TD-TRUSTED-CERTIFIERS, and the data-value is
-the DER encoding of
-
-    KDCTrustedCertifiers ::= SEQUENCE OF Name
-
-If, while verifying the certificate chain, the KDC determines that
-the signature on one of the certificates in the signedAuthPack is
-invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
-The accompanying e-data for this error is a TYPED-DATA, whose
-data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER
-encoding of the index into the CertificateSet field, ordered as sent
-by the client:
-
-    CertificateIndex ::= IssuerAndSerialNumber
-                                    -- IssuerAndSerialNumber of
-                                    -- certificate with invalid signature
-
-If more than one certificate signature is invalid, the KDC MAY send
-one TYPED-DATA per invalid signature.
-
-The KDC MAY also check whether any certificates in the client's
-chain have been revoked.  If any of them have been revoked, the KDC
-MUST return an error of type KDC_ERR_REVOKED_CERTIFICATE; if the KDC
-attempts to determine the revocation status but is unable to do so,
-it SHOULD return an error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.
-The certificate or certificates affected are identified exactly as
-for an error of type KDC_ERR_INVALID_CERTIFICATE (see above).
-
-In addition to validating the certificate chain, the KDC MUST also
-check that the certificate properly maps to the client's principal name
-as specified in the AS-REQ as follows:
-
-    1.  If the KDC has its own mapping from the name in the
-        certificate to a Kerberos name, it uses that Kerberos
-        name.
-
-    2.  Otherwise, if the certificate contains a SubjectAltName
-        extension with a Kerberos name in the otherName field,
-        it uses that name. The otherName field (of type AnotherName)
-        in the SubjectAltName extension MUST contain the following:
-
-        The type-id is:
-
-            krb5PrincipalName OBJECT IDENTIFIER ::= {
-                iso (1) org (3) dod (6) internet (1) security (5)
-                kerberosv5 (2) 2
-            }
-
-        The value is:
-
-            KRB5PrincipalName ::= SEQUENCE {
-                realm                   [0] Realm,
-                principalName           [1] PrincipalName
-            }
-
-If the KDC does not have its own mapping and there is no Kerberos
-name present in the certificate, or if the name in the request does
-not match the name in the certificate (including the realm name), or
-if there is no name in the request, the KDC MUST return error code
-KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
-for this error.
-
-Even if the chain is validated, and the names in the certificate and
-the request match, the KDC may decide not to trust the client.  For
-example, the certificate may include an Extended Key Usage (EKU) OID
-in the extensions field.  As a matter of local policy, the KDC may
-decide to reject requests on the basis of the absence or presence of
-specific EKU OIDs.  In this case, the KDC MUST return error code
-KDC_ERR_CLIENT_NOT_TRUSTED. The PKINIT EKU OID is defined as:
-
-    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-      pkinit(3) pkekuoid(4) }
-
-If the client's signature on the signedAuthPack fails to verify, or
-if there is no paChecksum field, the KDC MUST return error
-KDC_ERR_INVALID_SIG.  There is no accompanying e-data for this
-error.
-
-The KDC MUST check the timestamp to ensure that the request is not
-a replay, and that the time skew falls within acceptable limits.
-The recommendations clock skew times in [1] apply here.  If the
-check fails, the KDC MUSTreturn error code KRB_AP_ERR_REPEAT or
-KRB_AP_ERR_SKEW, respectively.
-
-If the clientPublicValue is filled in, indicating that the client
-wishes to use ephemeral-ephemeral Diffie-Hellman, the KDC checks to
-see if the parameters satisfy its policy.  If they do not, it MUST
-return error code KDC_ERR_KEY_SIZE.  The accompanying e-data is a
-TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and whose
-data-value is the DER encoding of a DomainParameters (see [3]),
-including appropriate Diffie-Hellman parameters with which to retry
-the request.
-
-The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
-client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
-not have the corresponding certificate.
-
-The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
-did not include a kdcCert field, but did include a trustedCertifiers
-field, and the KDC does not possesses a certificate issued by one of
-the listed certifiers.
-
-If there is a supportedCMSTypes field in the AuthPack, the KDC must
-check to see if it supports any of the listed types.  If it supports
-more than one of the types, the KDC SHOULD use the one listed first.
-If it does not support any of them, it MUST return an error of type
-KRB5KDC_ERR_ETYPE_NOSUPP.
-
-
-3.2.3.  KDC Reply
-
-Assuming that the client's request has been properly validated, the
-KDC proceeds as per [1], except as follows.
-
-The KDC MUST set the initial flag and include an authorization data
-of type AD-INITIAL-VERIFIED-CAS in the issued ticket.  The value is
-an OCTET STRING containing the DER encoding of InitialVerifiedCAs:
-
-    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
-        ca                      [0] Name,
-        Validated               [1] BOOLEAN,
-        ...
-    }
-
-The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-containers if the list of CAs satisfies the KDC's realm's policy.
-(This corresponds to the TRANSITED-POLICY-CHECKED ticket flag.)
-Furthermore, any TGS must copy such authorization data from tickets
-used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
-including the AD-IF-RELEVANT container, if present.
-
-Application servers that understand this authorization data type
-SHOULD apply local policy to determine whether a given ticket
-bearing such a type *not* contained within an AD-IF-RELEVANT
-container is acceptable.  (This corresponds to the AP server
-checking the transited field when the TRANSITED-POLICY-CHECKED flag
-has not been set.)  If such a data type is contained within an
-AD-IF-RELEVANT container, AP servers MAY apply local policy to
-determine whether the authorization data is acceptable.
-
-The AS-REP is otherwise unchanged from [1].  The KDC encrypts the
-reply as usual, but not with the client's long-term key.  Instead,
-it encrypts it with either a generated encryption key, or a key
-derived from a Diffie-Hellman exchange. The contents of the
-PA-PK-AS-REP indicate the type of encryption key that was used:
-
-    PA-PK-AS-REP ::= CHOICE {
-        dhSignedData            [0] IMPLICIT WrapContentInfo,
-                                    -- Type is SignedData.
-                                    -- Content is KDCDHKeyInfo
-                                    -- (defined below).
-        encKeyPack              [1] IMPLICIT WrapContentInfo,
-                                    -- Type is EnvelopedData.
-                                    -- Encrypted using client's
-                                    -- public key certificate.
-                                    -- Content is SignedData over
-                                    -- ReplyKeyPack (defined below).
-        ...
-    }
-
-    KDCDHKeyInfo ::= SEQUENCE {
-        subjectPublicKey        [0] BIT STRING,
-                                    -- Equals public exponent
-                                    -- (g^a mod p).
-                                    -- INTEGER encoded as payload
-                                    -- of BIT STRING.
-        nonce                   [1] INTEGER (0..4294967295),
-                                    -- Binds reply to request.
-                                    -- Exception: A value of zero
-                                    -- indicates that the KDC is
-                                    -- using cached values.
-        dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                                    -- Expiration time for KDC's
-                                    -- cached values.
-        ...
-    }
-
-The fields of the ContentInfo for dhSignedData are to be filled in
-as follows:
-
-    1.  The eContent field contains data of type KDCDHKeyInfo.
-
-    2.  The eContentType field contains the OID value for
-        id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
-        security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }
-
-    3.  The signerInfos field contains a single signerInfo, which is
-        the signature of the KDCDHKeyInfo.
-
-    4.  The certificates field contains a signature verification
-        certificate chain that the client will use to verify the
-        KDC's signature over the KDCDHKeyInfo.  This field may only
-        be left empty if the client did include a kdcCert field in
-        the PA-PK-AS-REQ, indicating that it has the KDC's
-        certificate.  The certificate chain MUST NOT contain the
-        root CA certificate.
-
-    5.  If the client and KDC agree to use cached parameters, the
-        KDC MUST return a zero in the nonce field and include the
-        expiration time of the cached values in the dhKeyExpiration
-        field.  If this time is exceeded, the client MUST NOT use
-        the reply.  If the time is absent, the client MUST NOT use
-        the reply and MAY resubmit a request with a non-zero nonce,
-        thus indicating non-acceptance of the cached parameters.
-
-The KDC reply key is derived as follows:
-
-    1.  Both the KDC and the client calculate the shared secret
-        value
-
-            DHKey = g^(ab) mod p
-
-        where a and b are the client's and KDC's private exponents,
-        respectively.  DHKey, padded first with leading zeros as
-        needed to make it as long as the modulus p, is represented
-        as a string of octets in big-endian order (such that the
-        size of DHKey in octets is the size of the modulus p).
-
-    2.  Let K be the key-generation seed length [6] of the reply key
-        whose enctype is selected according to [1].
-
-    3.  Define the function octetstring2key() as follows:
-
-            octetstring2key(x) == random-to-key(K-truncate(
-                                         sha1(0x00 | x) |
-                                         sha1(0x01 | x) |
-                                         sha1(0x02 | x) |
-                                         ...
-                                     ))
-
-        where x is an octet string; | is the concatenation operator;
-        0x00, 0x01, 0x02, etc. are each represented as a single
-        octet; random-to-key() is an operation that generates a
-        protocolkey from a bitstring of length K; and K-truncate
-        truncates its input to K bits.  Both K and random-to-key()
-        are defined in the kcrypto profile [6] for the enctype of
-        the reply key.
-
-    4.  When cached DH parameters are used, let n_c be the
-        clientDHNonce, and n_k be the serverDHNonce; otherwise, let
-        both n_c and n_k be empty octet strings.  The reply key k is
-
-            k = octetstring2key(DHKey | n_c | n_k)
-
-If the KDC and client are not using Diffie-Hellman, the KDC encrypts
-the reply with an encryption key, packed in the encKeyPack, which
-contains data of type ReplyKeyPack:
-
-    ReplyKeyPack ::= SEQUENCE {
-        replyKey                [0] EncryptionKey,
-                                    -- Defined in [1].
-                                    -- Used to encrypt main reply.
-                                    -- MUST be at least as strong
-                                    -- as session key.  (Using the
-                                    -- same enctype and a strong
-                                    -- prng should suffice, if no
-                                    -- stronger encryption system
-                                    -- is available.)
-        nonce                   [1] INTEGER (0..4294967295),
-                                    -- Binds reply to request.
-        ...
-    }
-
-The fields of the ContentInfo for encKeyPack MUST be filled in as
-follows:
-
-    1.  The content is of type SignedData.  The eContent for
-        the SignedData is of type ReplyKeyPack.
-
-    2.  The eContentType for the SignedData contains the OID value
-        for id-pkrkeydata: { iso(1) org(3) dod(6) internet(1)
-        security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }
-
-    3.  The signerInfos field contains a single signerInfo, which is
-        the signature of the ReplyKeyPack.
-
-    4.  The certificates field contains a signature verification
-        certificate chain that the client will use to verify the
-        KDC's signature over the ReplyKeyPack.  This field may only
-        be left empty if the client included a kdcCert field in the
-        PA-PK-AS-REQ, indicating that it has the KDC's certificate.
-        The certificate chain MUST NOT contain the root CA
-        certificate.
-
-    5.  The contentType for the EnvelopedData contains the OID value
-        for id-signedData: { iso (1) member-body (2) us (840) rsadsi
-        (113549) pkcs (1) pkcs7 (7) signedData (2) }
-
-    6.  The enveloped data MUST contain one KeyTransRecipientInfo,
-        which is targeted to the client's certificate (obtained in
-        the initial request).
-
-    7.  The unprotectedAttrs or originatorInfo fields MAY be
-        present.
-
-
-3.2.4.  Validation of KDC Reply
-
-Upon receipt of the KDC's reply, the client proceeds as follows.  If
-the PA-PK-AS-REP contains a dhSignedData, the client obtains and
-verifies the Diffie-Hellman parameters, and obtains the shared key
-as described above.  Otherwise, the message contains an encKeyPack,
-and the client decrypts and verifies the temporary encryption key.
-
-In either case, the client MUST check to see if the included
-certificate contains a subjectAltName extension of type dNSName or
-iPAddress (if the KDC is specified by IP address instead of name).
-If it does, it MUST check to see if that extension matches the KDC
-it believes it is communicating with, with matching rules specified
-in RFC 2459.  Exception: If the client has some external information
-as to the identity of the KDC, this check MAY be omitted.
-
-The client also MUST check that the KDC's certificate contains an
-extendedKeyUsage OID of id-pkkdcekuoid:
-
-    { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-      pkinit(3) pkkdcekuoid(5) }
-
-If all applicable checks are satisfied, the client then decrypts the
-main reply with the resulting key, and then proceeds as described in
-[1].
-
-
-3.2.5.  Indicating PKINIT Support
-
-A KDC that supports PKINIT SHOULD indicate support for PKINIT to
-clients that did not include any or acceptable pre-authentication in
-their AS requests.  As per [1], KDCs respond to such requests with a
-KRB-ERROR with KDC_ERR_PREAUTH_REQUIRED as the error code and with a
-list of pre-authentication data in the KRB-ERROR's e-data field.
-
-To indicate support for PKINIT, then, a KDC MUST include, in
-KDC_ERR_PREAUTH_REQUIRED KRB-ERROR messages, a padata element of
-type PA-PK-AS-ERR.  The padata-value field of this padata element
-MUST be set to the zero-length string; clients MUST ignore this and
-any other value.
-
-A client that receives a KRB-ERROR message, bearing a PA-PK-AS-ERR
-padata element, from a KDC in response to its AS-REQ should take the
-message as an indication of support by the KDC for PKINIT.  The
-client MAY respond by attempting a new AS exchange using its
-preferred pre-authentication mechanism for which the KDC has
-indicated support in its error message and for which the client has
-credentials, possibly including PKINIT.
-
-Future extensions to PKINIT may provide for the use of the value of
-PA-PK-AS-ERR padata elements to indicate such details as KDCs' PKI
-trust anchors, negotiation preferences, etc.
-
-
-4.  Security Considerations
-
-PKINIT raises certain security considerations beyond those that can
-be regulated strictly in protocol definitions.  We will address them
-in this section.
-
-PKINIT extends the cross-realm model to the public-key
-infrastructure.  Users of PKINIT must understand security policies
-and procedures appropriate to the use of Public Key Infrastructures.
-
-Standard Kerberos allows the possibility of interactions between
-cryptosystems of varying strengths; this document adds interactions
-with public-key cryptosystems to Kerberos.  Some administrative
-policies may allow the use of relatively weak public keys.  Using
-such keys to wrap data encrypted under stronger conventional
-cryptosystems may be inappropriate.
-
-PKINIT requires keys for symmetric cryptosystems to be generated.
-Some such systems contain "weak" keys.  For recommendations regarding
-these weak keys, see [1].
-
-PKINIT allows the use of a zero nonce in the PKAuthenticator when
-cached Diffie-Hellman keys are used.  In this case, message binding
-is performed using the nonce in the main request in the same way as
-it is done for ordinary AS-REQs (without the PKINIT
-pre-authenticator).  The nonce field in the KDC request body is
-signed through the checksum in the PKAuthenticator, which
-cryptographically binds the PKINIT pre-authenticator to the main
-body of the AS Request and also provides message integrity for the
-full AS Request.
-
-However, when a PKINIT pre-authenticator in the AS-REP has a
-zero-nonce, and an attacker has somehow recorded this
-pre-authenticator and discovered the corresponding Diffie-Hellman
-private key (e.g., with a brute-force attack), the attacker will be
-able to fabricate his own AS-REP messages that impersonate the KDC
-with this same pre-authenticator.  This compromised pre-authenticator
-will remain valid as long as its expiration time has not been reached
-and it is therefore important for clients to check this expiration
-time and for the expiration time to be reasonably short, which
-depends on the size of the Diffie-Hellman group.
-
-If a client also caches its Diffie-Hellman keys, then the session key
-could remain the same during multiple AS-REQ/AS-REP exchanges and an
-attacker which compromised the session key could fabricate his own
-AS-REP messages with a pre-recorded pre-authenticator until the
-client starts using a new Diffie-Hellman key pair and while the KDC
-pre-authenticator has not yet expired.  It is therefore not
-recommended for KDC clients to also cache their Diffie-Hellman keys.
-
-Care should be taken in how certificates are chosen for the purposes
-of authentication using PKINIT.  Some local policies may require
-that key escrow be used for certain certificate types.  Deployers of
-PKINIT should be aware of the implications of using certificates that
-have escrowed keys for the purposes of authentication.
-
-PKINIT does not provide for a "return routability" test to prevent
-attackers from mounting a denial-of-service attack on the KDC by
-causing it to perform unnecessary and expensive public-key
-operations.  Strictly speaking, this is also true of standard
-Kerberos, although the potential cost is not as great, because
-standard Kerberos does not make use of public-key cryptography.
-
-The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
-permit empty SEQUENCEs to be encoded.  Such empty sequences may only
-be used if the KDC itself vouches for the user's certificate.  [This
-seems to reflect the consensus of the Kerberos working group.]
-
-
-5.  Acknowledgements
-
-The following people have made significant contributions to this
-draft: Ari Medvinsky, Matt Hur, John Wray, Jonathan Trostle, Nicolas
-Williams, Tom Yu, Sam Hartman, and Jeff Hutzelman.
-
-Some of the ideas on which this document is based arose during
-discussions over several years between members of the SAAG, the IETF
-CAT working group, and the PSRG, regarding integration of Kerberos
-and SPX.  Some ideas have also been drawn from the DASS system.
-These changes are by no means endorsed by these groups.  This is an
-attempt to revive some of the goals of those groups, and this
-document approaches those goals primarily from the Kerberos
-perspective.  Lastly, comments from groups working on similar ideas
-in DCE have been invaluable.
-
-
-6.  Expiration Date
-
-This draft expires May 15, 2005.
-
-
-7.  Bibliography
-
-[1] RFC-Editor: To be replaced by RFC number for
-draft-ietf-krb-wg-kerberos-clarifications.
-
-[2] R. Housley. Cryptographic Message Syntax. August 2002.  Request
-For Comments 3369.
-
-[3] W. Polk, R. Housley, and L. Bassham. Algorithms and Identifiers
-for the Internet X.509 Public Key Infrastructure Certificate and
-Certificate Revocation List (CRL) Profile, April 2002. Request For
-Comments 3279.
-
-[4] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public
-Key Infrastructure Certificate and Certificate Revocation List
-(CRL) Profile, April 2002. Request for Comments 3280.
-
-[5] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-Specifications, October 1998.  Request for Comments 2437.
-
-[6] RFC-Editor: To be replaced by RFC number for
-draft-ietf-krb-wg-crypto.
-
-[7] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and
-T. Wright. Transport Layer Security (TLS) Extensions, June 2003.
-Request for Comments 3546.
-
-[8] J. Schaad.  Use of the Advanced Encryption Standard (AES)
-Encryption Algorithm in Cryptographic Message Syntax (CMS).  July
-2003.  Request for Comments 3565.
-
-[9] NIST, Guidelines for Implementing and Using the NBS Encryption
-Standard, April 1981.  FIPS PUB 74.
-
-[10] D. Harkins and D. Carrel.  The Internet Key Exchange (IKE),
-November 1998.  Request for Comments 2409.
-
-[11] K. Raeburn.  Unkeyed SHA-1 Checksum Specification for Kerberos
-5.  Internet-Draft, draft-ietf-krb-wg-sha1-00.txt.
-
-[12] S. Bradner.  Key Words for Use in RFCs to Indicate Requirement
-Levels.  March 1997.  Request for Comments 2119 (BCP 14).
-
-[13] T. Kivinen, M. Kojo.  More Modular Exponential (MODP) Diffie-
-Hellman Groups for Internet Key Exchange (IKE).  May 2003.  Request
-for Comments 3526.
-
-[14] R. Housley. Cryptographic Message Syntax (CMS) Algorithms.
-August 2002.  Request For Comments 3370.
-
-
-8.  Authors
-
-Brian Tung
-Clifford Neuman
-USC Information Sciences Institute
-4676 Admiralty Way Suite 1001
-Marina del Rey CA 90292-6695
-Phone: +1 310 822 1511
-E-mail: {brian,bcn}@isi.edu
-
-Sasha Medvinsky
-Motorola, Inc.
-6450 Sequence Drive
-San Diego, CA 92121
-+1 858 404 2367
-E-mail: smedvinsky@motorola.com
-
-
-Appendix A.  PKINIT ASN.1 Module
-
-KerberosV5-PK-INIT-SPEC {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2) modules(4) pkinit(TBD)
-} DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-    IMPORTS
-        SubjectPublicKeyInfo, AlgorithmIdentifier, Name
-            FROM PKIX1Explicit88 { iso (1) identified-organization (3)
-              dod (6) internet (1) security (5) mechanisms (5)
-              pkix (7) id-mod (0) id-pkix1-explicit (18) }
-
-        ContentInfo, IssuerAndSerialNumber
-            FROM CryptographicMessageSyntax { iso(1) member-body(2)
-              us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
-              modules(0) cms(1) }
-
-        KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey
-            FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-              dod(6) internet(1) security(5) kerberosV5(2) modules(4)
-              krb5spec2(2) } ;
-
-    id-pkinit  OBJECT IDENTIFIER ::=
-      { iso (1) org (3) dod (6) internet (1) security (5)
-        kerberosv5 (2) pkinit (3) }
-
-    id-pkdhkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-    id-pkdhkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-    id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-    id-pkekuoid  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-    id-pkkdcekuoid  OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-    pa-pk-as-req INTEGER ::=                 TBD
-    pa-pk-as-rep INTEGER ::=                 TBD
-    pa-pk-ocsp-req INTEGER ::=               TBD
-    pa-pk-ocsp-rep INTEGER ::=               TBD
-
-    ad-initial-verified-cas INTEGER ::=      TBD
-
-    td-dh-parameters INTEGER ::=             TBD
-    td-trusted-certifiers INTEGER ::=        104
-    td-certificate-index INTEGER ::=         105
-
-    WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
-                                    -- Contains a BER encoding of
-                                    -- ContentInfo
-    })
-
-    WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
-                                    -- Contains a BER encoding of
-                                    -- IssuerAndSerialNumber
-    })
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-        signedAuthPack          [0] IMPLICIT WrapContentInfo,
-        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-        kdcCert                 [2] IMPLICIT WrapIssuerAndSerial
-                                    OPTIONAL,
-        ...
-    }
-
-    TrustedCA ::= CHOICE {
-        caName                  [1] Name,
-        issuerAndSerial         [2] IMPLICIT WrapIssuerAndSerial,
-        ...
-    }
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-        supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                    OPTIONAL,
-        ...
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        cusec                   [0] INTEGER (0..999999),
-        ctime                   [1] KerberosTime,
-        nonce                   [2] INTEGER (0..4294967295),
-        paChecksum              [3] OCTET STRING OPTIONAL,
-        ...
-    }
-
-    KDCTrustedCertifiers ::= SEQUENCE OF Name
-
-    CertificateIndex ::= IssuerAndSerialNumber
-
-    KRB5PrincipalName ::= SEQUENCE {
-        realm                   [0] Realm,
-        principalName           [1] PrincipalName
-    }
-
-    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
-        ca                      [0] Name,
-        validated               [1] BOOLEAN,
-        ...
-    }
-
-    PA-PK-AS-REP ::= CHOICE {
-        dhSignedData            [0] IMPLICIT WrapContentInfo,
-        encKeyPack              [1] IMPLICIT WrapContentInfo,
-        ...
-    }
-
-    KDCDHKeyInfo ::= SEQUENCE {
-        subjectPublicKey        [0] BIT STRING,
-        nonce                   [1] INTEGER (0..4294967295),
-        dhKeyExpiration         [2] KerberosTime OPTIONAL,
-        ...
-    }
-
-    ReplyKeyPack ::= SEQUENCE {
-        replyKey                [0] EncryptionKey,
-        nonce                   [1] INTEGER (0..4294967295),
-        ...
-    }
-
-END
-
-Copyright (C) The Internet Society 2004.  This document is subject
-to the rights, licenses and restrictions contained in BCP 78, and
-except as set forth therein, the authors retain all their rights.
-
-This document and the information contained herein are provided on
-an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
-REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
-INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt
deleted file mode 100644
index f0cd9cac4..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-23.txt
+++ /dev/null
@@ -1,1511 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                            B. Tung
-Internet-Draft                        USC Information Sciences Institute
-Expires: August 4, 2005                                           L. Zhu
-                                                   Microsoft Corporation
-                                                        January 31, 2005
-
-
-     Public Key Cryptography for Initial Authentication in Kerberos
-                    draft-ietf-cat-kerberos-pk-init
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 4, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes protocol extensions (hereafter called PKINIT)
-   to the Kerberos protocol specification.  These extensions provide a
-   method for integrating public key cryptography into the initial
-   authentication exchange, by passing digital certificates and
-   associated authenticators in pre-authentication data fields.
-
-
-
-Tung & Zhu               Expires August 4, 2005                 [Page 1]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1   Definitions, Requirements, and Constants . . . . . . . . .  4
-       3.1.1   Required Algorithms  . . . . . . . . . . . . . . . . .  4
-       3.1.2   Defined Message and Encryption Types . . . . . . . . .  5
-       3.1.3   Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
-     3.2   PKINIT Pre-authentication Syntax and Use . . . . . . . . .  6
-       3.2.1   Generation of Client Request . . . . . . . . . . . . .  7
-       3.2.2   Receipt of Client Request  . . . . . . . . . . . . . .  9
-       3.2.3   Generation of KDC Reply  . . . . . . . . . . . . . . . 12
-       3.2.4   Receipt of KDC Reply . . . . . . . . . . . . . . . . . 17
-     3.3   KDC Indication of PKINIT Support . . . . . . . . . . . . . 18
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
-   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
-     7.1   Normative References . . . . . . . . . . . . . . . . . . . 20
-     7.2   Informative References . . . . . . . . . . . . . . . . . . 21
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
-   A.  PKINIT ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 21
-       Intellectual Property and Copyright Statements . . . . . . . . 27
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires August 4, 2005                 [Page 2]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-1.  Introduction
-
-   A client typically authenticates itself to a service in Kerberos
-   using three distinct though related exchanges.  First, the client
-   requests a ticket-granting ticket (TGT) from the Kerberos
-   authentication server (AS).  Then, it uses the TGT to request a
-   service ticket from the Kerberos ticket-granting server (TGS).
-   Usually, the AS and TGS are integrated in a single device known as a
-   Kerberos Key Distribution Center, or KDC.  (In this document, we will
-   refer to both the AS and the TGS as the KDC.)  Finally, the client
-   uses the service ticket to authenticate itself to the service.
-
-   The advantage afforded by the TGT is that the client exposes his
-   long-term secrets only once.  The TGT and its associated session key
-   can then be used for any subsequent service ticket requests.  One
-   result of this is that all further authentication is independent of
-   the method by which the initial authentication was performed.
-   Consequently, initial authentication provides a convenient place to
-   integrate public-key cryptography into Kerberos authentication.
-
-   As defined in [CLAR], Kerberos authentication exchanges use
-   symmetric-key cryptography, in part for performance.  One
-   disadvantage of using symmetric-key cryptography is that the keys
-   must be shared, so that before a client can authenticate itself, he
-   must already be registered with the KDC.
-
-   Conversely, public-key cryptography (in conjunction with an
-   established Public Key Infrastructure) permits authentication without
-   prior registration with a KDC.  Adding it to Kerberos allows the
-   widespread use of Kerberized applications by clients without
-   requiring them to register first with a KDC--a requirement that has
-   no inherent security benefit.
-
-   As noted above, a convenient and efficient place to introduce
-   public-key cryptography into Kerberos is in the initial
-   authentication exchange.  This document describes the methods and
-   data formats for integrating public-key cryptography into Kerberos
-   initial authentication.
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-Tung & Zhu               Expires August 4, 2005                 [Page 3]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-3.  Extensions
-
-   This section describes extensions to [CLAR] for supporting the use of
-   public-key cryptography in the initial request for a ticket.
-
-   Briefly, this document defines the following extensions to [CLAR]:
-
-   1.  The client indicates the use of public-key authentication by
-      including a special preauthenticator in the initial request.  This
-      preauthenticator contains the client's public-key data and a
-      signature.
-
-   2.  The KDC tests the client's request against its authentication
-      policy and trusted Certification Authorities (CAs).
-
-   3.  If the request passes the verification tests, the KDC replies as
-      usual, but the reply is encrypted using either:
-
-      a.  a key generated through a Diffie-Hellman (DH) key exchange
-         [RFC2631] with the client, signed using the KDC's signature
-         key; or
-
-      b.  a symmetric encryption key, signed using the KDC's signature
-         key and encrypted using the client's public key.
-
-      Any keying material required by the client to obtain the
-      encryption key for decrypting the KDC reply is returned in a
-      pre-authentication field accompanying the usual reply.
-
-   4.  The client obtains the encryption key, decrypts the reply, and
-      then proceeds as usual.
-
-   Section 3.1 of this document enumerates the required algorithms and
-   necessary extension message types.  Section 3.2 describes the
-   extension messages in greater detail.
-
-3.1  Definitions, Requirements, and Constants
-
-3.1.1  Required Algorithms
-
-   All PKINIT implementations MUST support the following algorithms:
-
-   o  AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO].
-
-   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
-
-   o  KDC AS reply key delivery method: ephemeral-ephemeral
-      Diffie-Hellman exchange (Diffie-Hellman keys are not cached).
-
-
-
-Tung & Zhu               Expires August 4, 2005                 [Page 4]
-
-
-
-3.1.2  Defined Message and Encryption Types
-
-   PKINIT makes use of the following new pre-authentication types:
-
-       PA-PK-AS-REQ                             16
-       PA-PK-AS-REP                             17
-
-   PKINIT also makes use of the following new authorization data type:
-
-       AD-INITIAL-VERIFIED-CAS                   9
-
-   PKINIT introduces the following new error codes:
-
-       KDC_ERR_CLIENT_NOT_TRUSTED                62
-       KDC_ERR_KDC_NOT_TRUSTED                   63
-       KDC_ERR_INVALID_SIG                       64
-       KDC_ERR_KEY_SIZE                          65
-       KDC_ERR_CERTIFICATE_MISMATCH              66
-       KDC_ERR_CANT_VERIFY_CERTIFICATE           70
-       KDC_ERR_INVALID_CERTIFICATE               71
-       KDC_ERR_REVOKED_CERTIFICATE               72
-       KDC_ERR_REVOCATION_STATUS_UNKNOWN         73
-       KDC_ERR_CLIENT_NAME_MISMATCH              75
-
-   PKINIT uses the following typed data types for errors:
-
-       TD-TRUSTED-CERTIFIERS                    104
-       TD-CERTIFICATE-INDEX                     105
-       TD-DH-PARAMETERS                         109
-
-   PKINIT defines the following encryption types, for use in the AS-REQ
-   message (to indicate acceptance of the corresponding encryption
-   Object Identifiers (OIDs) in PKINIT):
-
-       dsaWithSHA1-CmsOID                         9
-       md5WithRSAEncryption-CmsOID               10
-       sha1WithRSAEncryption-CmsOID              11
-       rc2CBC-EnvOID                             12
-       rsaEncryption-EnvOID   (PKCS1 v1.5)       13
-       rsaES-OAEP-EnvOID      (PKCS1 v2.0)       14
-       des-ede3-cbc-EnvOID                       15
-
-   The above encryption types are used by the client only within the
-   KDC-REQ-BODY to indicate which Cryptographic Message Syntax (CMS)
-   [RFC3852] algorithms it supports.  Their use within Kerberos
-   EncryptedData structures is not specified by this document.
-
-   The ASN.1 module for all structures defined in this document (plus
-   IMPORT statements for all imported structures) are given in
-
-
-
-Tung & Zhu               Expires August 4, 2005                 [Page 5]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-   Appendix A.
-
-   All structures defined in or imported into this document MUST be
-   encoded using Distinguished Encoding Rules (DER) [X690].  All data
-   structures wrapped in OCTET STRINGs must be encoded according to the
-   rules specified in corresponding specifications.
-
-   Interoperability note: Some implementations may not be able to decode
-   CMS objects encoded with BER but not DER; specifically, they may not
-   be able to decode infinite length encodings.  To maximize
-   interoperability, implementers SHOULD encode CMS objects used in
-   PKINIT with DER.
-
-3.1.3  Algorithm Identifiers
-
-   PKINIT does not define, but does make use of, the following algorithm
-   identifiers.
-
-   PKINIT uses the following algorithm identifier for Diffie-Hellman key
-   agreement [RFC3279]:
-
-        dhpublicnumber
-
-   PKINIT uses the following signature algorithm identifiers [RFC3279]:
-
-       sha-1WithRSAEncryption (RSA with SHA1)
-       md5WithRSAEncryption   (RSA with MD5)
-       id-dsa-with-sha1       (DSA with SHA1)
-
-   PKINIT uses the following encryption algorithm identifiers [RFC3447]
-   for encrypting the temporary key with a public key:
-
-       rsaEncryption          (PKCS1 v1.5)
-       id-RSAES-OAEP          (PKCS1 v2.0)
-
-   PKINIT uses the following algorithm identifiers [RFC3370][RFC3565]
-   for encrypting the reply key with the temporary key:
-
-       des-ede3-cbc           (three-key 3DES, CBC mode)
-       rc2-cbc                (RC2, CBC mode)
-       id-aes256-CBC          (AES-256, CBC mode)
-
-
-3.2  PKINIT Pre-authentication Syntax and Use
-
-   This section defines the syntax and use of the various
-   pre-authentication fields employed by PKINIT.
-
-
-
-
-Tung & Zhu               Expires August 4, 2005                 [Page 6]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-3.2.1  Generation of Client Request
-
-   The initial authentication request (AS-REQ) is sent as per [CLAR]; in
-   addition, a pre-authentication field contains data signed by the
-   client's private signature key, as follows:
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-                   -- A list of CAs, trusted by the client, that can
-                   -- be used to validate KDC certificates.
-          kdcCert                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a particular KDC certificate, if the
-                   -- client already has it.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       TrustedCA ::= CHOICE {
-          caName                  [1] IMPLICIT OCTET STRING,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-          issuerAndSerial         [2] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a specific CA certificate.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Defined in [RFC3280].
-                   -- Present only if the client wishes to use the
-
-
-
-Tung & Zhu               Expires August 4, 2005                 [Page 7]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-                   -- Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- List of CMS encryption types supported by
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to cache DH keys or to allow the KDC to
-                   -- do so.
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [CLAR], for replay
-                   -- prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure for the signedAuthPack field is
-   filled out as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is id-pkauthdata:
-       { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-       pkinit(3) pkauthdata(1) }.
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type AuthPack.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type AuthPack.
-
-   5.  The certificates field of the type SignedData contains the
-       client's certificate and additional certificates intended to
-       facilitate certification path construction, so that the KDC can
-       validate the client's certificate and verify the signature over
-       the type AuthPack.  The certificates field MUST NOT contain
-
-
-
-Tung & Zhu               Expires August 4, 2005                 [Page 8]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-       "root" CA certificates.
-
-   6.  The client's Diffie-Hellman public value (clientPublicValue) is
-       included if and only if the client wishes to use the
-       Diffie-Hellman key agreement method.  For the Diffie-Hellman key
-       agreement method, implementations MUST support Oakley 1024-bit
-       MODP well-known group 2 [RFC2412] and SHOULD support Oakley
-       2048-bit MODP well-known group 14 and Oakley 4096-bit MODP
-       well-known group 16 [RFC3526].  They MAY support Oakley 185-bit
-       EC2N group 4 [RFC2412].  The Diffie-Hellman group size should be
-       chosen so as to provide sufficient cryptographic security.  The
-       exponents should have at least twice as many bits as the
-       symmetric keys that will be derived from them [ODL99].
-
-   7.  The client may wish to cache DH keys or to allow the KDC to do
-       so.  If so, then the client includes the clientDHNonce field.
-       This nonce string needs to be as long as the longest key length
-       of the symmetric key types that the client supports.  This nonce
-       MUST be chosen randomly.
-
-
-3.2.2  Receipt of Client Request
-
-   Upon receiving the client's request, the KDC validates it.  This
-   section describes the steps that the KDC MUST (unless otherwise
-   noted) take in validating the request.
-
-   The KDC looks for the client's certificate in the signedAuthPack
-   (based on the signerInfo) and validate this certificate.
-
-   If the KDC cannot find a certification path to validate the client's
-   certificate, it sends back an error of type
-   KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for this
-   error is a TYPED-DATA (as defined in [CLAR]).  For this error, the
-   data-type is TD-TRUSTED-CERTIFIERS, and the data-value is the DER
-   encoding of
-
-       TrustedCertifiers ::= SEQUENCE OF OCTET STRING
-                   -- The OCTET STRING contains a PKIX type Name encoded
-                   -- according to [RFC3280].
-
-   If, while processing the certification path, the KDC determines that
-   the signature on one of the certificates in the signedAuthPack is
-   invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
-   The accompanying e-data for this error is a TYPED-DATA, whose
-   data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER
-   encoding of the index into the CertificateSet field, ordered as sent
-   by the client:
-
-
-
-Tung & Zhu               Expires August 4, 2005                 [Page 9]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-       CertificateIndex ::= OCTET STRING
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- IssuerAndSerialNumber of certificate with an
-                   -- invalid signature.
-
-   If more than one certificate signature is invalid, the KDC MAY send
-   one TYPED-DATA per invalid signature.
-
-   The KDC SHOULD also check whether any certificates in the client's
-   certification path have been revoked.  If any of them have been
-   revoked, the KDC MUST return an error of type
-   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
-   revocation status but is unable to do so, it SHOULD return an error
-   of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The certificate or
-   certificates affected are identified exactly as for an error of type
-   KDC_ERR_INVALID_CERTIFICATE (see above).
-
-   In addition to validating the client's certificate, the KDC MUST also
-   check that this certificate properly maps to the client's principal
-   name as specified in the AS-REQ as follows:
-
-   1.  If the KDC has its own mapping from the name in the client's
-      certificate to a Kerberos name, it uses that Kerberos name.
-
-   2.  Otherwise, if the client's certificate contains a SubjectAltName
-      extension with a Kerberos name in the otherName field, it uses
-      that name.
-
-      The otherName field (of type AnotherName) in the SubjectAltName
-      extension MUST contain KRB5PrincipalName as defined below.
-
-      The type-id field of the type AnotherName is id-pksan:
-
-       id-pksan OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509-sanan (2) }
-
-      The value field of the type AnotherName is the DER encoding of the
-      following ASN.1 type:
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-   If the KDC does not have its own mapping and there is no Kerberos
-   name present in the client's certificate, or if the name in the
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 10]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-   request does not match the name in the certificate (including the
-   realm name), the KDC MUST return error code
-   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
-   this error.
-
-   Even if the client's certificate is validated and it is mapped to the
-   client's principal name, the KDC may decide not to accept the
-   client's certificate, depending on local policy.
-
-   The KDC MAY require the presence of an Extended Key Usage (EKU)
-   KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
-   client's certificate:
-
-       id-pkekuoid OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) pkekuoid(4) }
-              -- PKINIT client authentication.
-              -- Key usage bits that may be consistent: digitalSignature
-              -- nonRepudiation, and (keyEncipherment or keyAgreement).
-
-   As a matter of local policy, the KDC may decide to reject requests on
-   the basis of the absence or presence of specific EKU OIDs.  KDCs
-   implementing this requirement SHOULD also accept the EKU KeyPurposeId
-   id-ms-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement,
-   as there are a large number of client certificates deployed for use
-   with PKINIT which have this EKU.
-
-   The KDC MUST return the error code KDC_ERR_CLIENT_NOT_TRUSTED if the
-   client's certificate is not accepted.
-
-   Once the client's certificate is accepted, the KDC can then verify
-   the client's signature over the type AuthPack according to [RFC3852].
-   If the signature fails to verify, the KDC MUST return error
-   KDC_ERR_INVALID_SIG.  There is no accompanying e-data for this error.
-
-   The KDC MUST check the timestamp to ensure that the request is not a
-   replay, and that the time skew falls within acceptable limits.  The
-   recommendations clock skew times in [CLAR] apply here.  If the check
-   fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
-   KRB_AP_ERR_SKEW, respectively.
-
-   If the clientPublicValue is filled in, indicating that the client
-   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
-   check to see if the key parameters satisfy its policy.  If they do
-   not, it MUST return error code KDC_ERR_KEY_SIZE.  The accompanying
-   e-data is a TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and
-   whose data-value is the DER encoding of the following:
-
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 11]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters
-                   -- Type DomainParameters is defined in [RFC3279].
-                   -- Contains a list of Diffie-Hellman group
-                   -- parameters in decreasing preference order.
-
-   TD-DH-PARAMETERS contains a list of Diffie-Hellman group parameters
-   that the KDC supports in decreasing preference order, from which the
-   client should pick one to retry the request.
-
-   The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
-   client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
-   not have the corresponding certificate.
-
-   The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
-   did not include a kdcCert field, but did include a trustedCertifiers
-   field, and the KDC does not possesses a certificate issued by one of
-   the listed certifiers.
-
-   If there is a supportedCMSTypes field in the AuthPack, the KDC must
-   check to see if it supports any of the listed types.  If it supports
-   more than one of the types, the KDC SHOULD use the one listed first.
-   If it does not support any of them, it MUST return an error of type
-   KRB5KDC_ERR_ETYPE_NOSUPP.
-
-3.2.3  Generation of KDC Reply
-
-   Assuming that the client's request has been properly validated, the
-   KDC proceeds as per [CLAR], except as follows.
-
-   The KDC MUST set the initial flag and include an authorization data
-   of type AD-INITIAL-VERIFIED-CAS in the issued ticket.  The value is
-   an OCTET STRING containing the DER encoding of InitialVerifiedCAs:
-
-       InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
-          ca                      [0] IMPLICIT OCTET STRING,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-          validated               [1] BOOLEAN,
-          ...
-       }
-
-   The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-   containers if the list of CAs satisfies the KDC's realm's policy
-   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
-   [CLAR]).  Furthermore, any TGS must copy such authorization data from
-   tickets used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
-   including the AD-IF-RELEVANT container, if present.
-
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 12]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-   Application servers that understand this authorization data type
-   SHOULD apply local policy to determine whether a given ticket bearing
-   such a type *not* contained within an AD-IF-RELEVANT container is
-   acceptable.  (This corresponds to the AP server checking the
-   transited field when the TRANSITED-POLICY-CHECKED flag has not been
-   set [CLAR].)  If such a data type is contained within an
-   AD-IF-RELEVANT container, AP servers MAY apply local policy to
-   determine whether the authorization data is acceptable.
-
-   The AS-REP is otherwise unchanged from [CLAR].  The KDC encrypts the
-   reply as usual, but not with the client's long-term key.  Instead, it
-   encrypts it with either a shared key derived from a Diffie-Hellman
-   exchange, or a generated encryption key.  The contents of the
-   PA-PK-AS-REP indicate which key delivery method is used:
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is id-pkrkeydata
-                   -- (1.2.840.113549.1.7.3) and the eContent field
-                   -- contains the DER encoding of the type
-                   -- ReplyKeyPack.
-                   -- ReplyKeyPack is defined below.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 13]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-                   -- present.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- KDC's public key, y = g^x mod p.
-                   -- MUST be ASN.1 encoded as an INTEGER;
-                   -- This encoding is then used as the contents
-                   -- (i.e., the value) of this BIT STRING field.
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request if cached DH keys are NOT used,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's cached values, present
-                   -- if and only if cached DH keys are used.  If this
-                   -- field is omitted then the serverDHNonce field
-                   -- MUST also be omitted.
-          ...
-       }
-
-
-3.2.3.1  Using Diffie-Hellman Key Exchange
-
-   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
-
-   The ContentInfo [RFC3852] structure for the dhSignedData field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is the OID value
-       for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
-       security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type KDCDHKeyInfo.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type
-       KDCDHKeyInfo.
-
-   5.  The certificates field of the type SignedData contains the KDC's
-       certificate and additional certificates intended to facilitate
-       certification path construction, so that the client can validate
-       the KDC's certificate and verify the KDC's signature over the
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 14]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-       type KDCDHKeyInfo.  This field may only be left empty if the
-       client did include a kdcCert field in the PA-PK-AS-REQ,
-       indicating that the client already has the KDC's certificate.
-       The certificates field MUST NOT contain "root" CA certificates.
-
-   6.  If the client included the clientDHNonce field, then the KDC may
-       choose to reuse its DH keys.  If the server reuses DH keys then
-       it MUST include an expiration time in the dhKeyExperiation field.
-       Past the point of the expiration time, the signature over the
-       type DHRepInfo is considered expired/invalid.  When the server
-       reuses DH keys then it MUST include a serverDHNonce at least as
-       long as the length of keys for the symmetric encryption system
-       used to encrypt the AS reply.  Note that including the
-       serverDHNonce changes how the client and server calculate the key
-       to use to encrypt the reply; see below for details.  The KDC
-       SHOULD NOT reuse DH keys unless the clientDHNonce field is
-       present in the request.
-
-   The reply key for use to decrypt the KDC reply [CLAR] is derived as
-   follows:
-
-   1.  Both the KDC and the client calculate the shared secret value
-      DHKey:
-
-           DHKey = g^(xb * xa) mod p
-
-      where xb and xa are the KDC's and client's private exponents,
-      respectively.  DHKey, padded first with leading zeros as needed to
-      make it as long as the modulus p, is represented as a string of
-      octets in big-endian order (such that the size of DHKey in octets
-      is the size of the modulus p).
-
-   2.  Let K be the key-generation seed length [KCRYPTO] of the reply
-      key whose enctype is selected according to [CLAR].
-
-   3.  Define the function octetstring2key() as follows:
-
-           octetstring2key(x) == random-to-key(K-truncate(
-                                    SHA1(0x00 | x) |
-                                    SHA1(0x01 | x) |
-                                    SHA1(0x02 | x) |
-                                    ...
-                                    ))
-
-      where x is an octet string; | is the concatenation operator; 0x00,
-      0x01, 0x02, etc., are each represented as a single octet;
-      random-to-key() is an operation that generates a protocol key from
-      a bitstring of length K; and K-truncate truncates its input to the
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 15]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-      first K bits.  Both K and random-to-key() are defined in the
-      kcrypto profile [KCRYPTO] for the enctype of the reply key.
-
-   4.  When cached DH keys are used, let n_c be the clientDHNonce, and
-      n_k be the serverDHNonce; otherwise, let both n_c and n_k be empty
-      octet strings.
-
-   5.  The reply key k is:
-
-           k = octetstring2key(DHKey | n_c | n_k)
-
-
-3.2.3.2  Using Public Key Encryption
-
-   In this case, the PA-PK-AS-REP contains a ContentInfo structure
-   wrapped in an OCTET STRING.  The reply key for use to decrypt the KDC
-   reply [CLAR] is encrypted in the encKeyPack field, which contains
-   data of type ReplyKeyPack:
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP.
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure for the encKeyPack field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-envelopedData
-       (as defined in [RFC3852]), and the content field is an
-       EnvelopedData (as defined in [RFC3852]).
-
-   2.  The contentType field for the type EnvelopedData is
-       id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
-       pkcs (1) pkcs7 (7) signedData (2) }.
-
-   3.  The eContentType field for the inner type SignedData (when
-       decrypted from the encryptedContent field for the type
-       EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
-       internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
-
-   4.  The eContent field for the inner type SignedData contains the DER
-       encoding of the type ReplyKeyPack.
-
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 16]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-   5.  The signerInfos field of the inner type SignedData contains a
-       single signerInfo, which contains the signature over the type
-       ReplyKeyPack.
-
-   6.  The certificates field of the inner type SignedData contains the
-       KDC's certificate and additional certificates intended to
-       facilitate certification path construction, so that the client
-       can validate the KDC's certificate and verify the KDC's signature
-       over the type ReplyKeyPack.  This field may only be left empty if
-       the client included a kdcCert field in the PA-PK-AS-REQ,
-       indicating that the client already has the KDC's certificate.
-       The certificates field MUST NOT contain "root" CA certificates.
-
-   7.  The recipientInfos field of the type EnvelopedData is a SET which
-       MUST contain exactly one member of type KeyTransRecipientInfo.
-       The encryptedKey of this member contains the temporary key which
-       is encrypted using the client's public key.
-
-   8.  The unprotectedAttrs or originatorInfo fields of the type
-       EnvelopedData MAY be present.
-
-3.2.4  Receipt of KDC Reply
-
-   Upon receipt of the KDC's reply, the client proceeds as follows.  If
-   the PA-PK-AS-REP contains the dhSignedData field, the client derives
-   the shared key using the same procedure used by the KDC as defined in
-   Section 3.2.3.1.  Otherwise, the message contains an encKeyPack, and
-   the client decrypts and verifies the temporary encryption key.
-
-   In either case, the client MUST validate the KDC's certificate and
-   verify the signature in the SignedData according to [RFC3852].
-   Unless the client can otherwise prove that the KDC's certificate is
-   for the target KDC (i.e., the subject distinguished name in the KDC
-   certificate is bound to the hostname or IP address of the KDC
-   authenticating the client), it MUST do the following to verify the
-   responder's identity:
-
-   1.  The client checks to see if the included certificate contains a
-      Subject Alternative Name extension [RFC3280] carrying a dNSName or
-      an iPAddress (if the KDC is specified by an IP address instead of
-      a name).  If it does, it MUST check to see if that name value
-      matches that of the KDC it believes it is communicating with, with
-      matching rules specified in [RFC3280].
-
-   2.  The client verifies that the KDC's certificate MUST contain the
-      EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
-
-
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 17]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-
-
-       id-pkkdcekuoid OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) pkkdcekuoid(5) }
-              -- Signing KDC responses.
-              -- Key usage bits that may be consistent:
-              -- digitalSignature.
-
-   If all applicable checks are satisfied, the client then decrypts the
-   enc-part of the KDC-REP in the AS_REP with the resulting key, and
-   then proceeds as described in [CLAR].
-
-3.3  KDC Indication of PKINIT Support
-
-   If pre-authentication is required, but was not present in the
-   request, per [CLAR] an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
-   stored in the e-data field of the KRB-ERROR message to specify which
-   pre-authentication mechanisms are acceptable.  The KDC can then
-   indicate the support of PKINIT by including a PA-PK-AS-REQ element in
-   that METHOD-DATA object.
-
-   Otherwise if it is required by the KDC's local policy that the client
-   must be pre-authenticated using the pre-authentication mechanism
-   specified in this document, but no PKINIT pre-authentication was
-   present in the request, an error message with the code
-   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
-
-   KDCs MUST leave the padata-value of PA-PK-AS-REQ entry in the
-   KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
-   STRING), and clients MUST ignore this and any other value.  Future
-   extensions to this protocol may specify other data to send instead of
-   an empty OCTET STRING.
-
-4.  Security Considerations
-
-   PKINIT raises certain security considerations beyond those that can
-   be regulated strictly in protocol definitions.  We will address them
-   in this section.
-
-   PKINIT extends the cross-realm model to the public-key
-   infrastructure.  Users of PKINIT must understand security policies
-   and procedures appropriate to the use of Public Key Infrastructures.
-
-   Standard Kerberos allows the possibility of interactions between
-   cryptosystems of varying strengths; this document adds interactions
-   with public-key cryptosystems to Kerberos.  Some administrative
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 18]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-   policies may allow the use of relatively weak public keys.  Using
-   such keys to wrap data encrypted under stronger conventional
-   cryptosystems may be inappropriate.
-
-   PKINIT requires keys for symmetric cryptosystems to be generated.
-   Some such systems contain "weak" keys.  For recommendations regarding
-   these weak keys, see [CLAR].
-
-   PKINIT uses the same RSA key pair for encryption and signing when
-   doing RSA encryption based key delivery.  This is not recommended
-   usage of RSA keys [RFC3447], by using DH based key delivery this is
-   avoided.
-
-   Care should be taken in how certificates are chosen for the purposes
-   of authentication using PKINIT.  Some local policies may require that
-   key escrow be used for certain certificate types.  Deployers of
-   PKINIT should be aware of the implications of using certificates that
-   have escrowed keys for the purposes of authentication.
-
-   PKINIT does not provide for a "return routability" test to prevent
-   attackers from mounting a denial-of-service attack on the KDC by
-   causing it to perform unnecessary and expensive public-key
-   operations.  Strictly speaking, this is also true of standard
-   Kerberos, although the potential cost is not as great, because
-   standard Kerberos does not make use of public-key cryptography.
-
-   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
-   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
-   be used if the KDC itself vouches for the user's certificate.
-
-5.  Acknowledgements
-
-   The following people have made significant contributions to this
-   draft: Paul Leach, Phil Hallin, Kelvin Yiu, Sam Hartman, Love
-   Hornquist Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan
-   Trostle, Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon and
-   Karthik Jaganathan.
-
-   Special thanks to Clifford Neuman, Mat Hur and Sasha Medvinsky who
-   wrote earlier versions of this document.
-
-   The authors are indebt to the Kerberos working group chair Jeffrey
-   Hutzelman who kept track of various issues and was enormously helpful
-   during the creation of this document.
-
-   Some of the ideas on which this document is based arose during
-   discussions over several years between members of the SAAG, the IETF
-   CAT working group, and the PSRG, regarding integration of Kerberos
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 19]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-   and SPX.  Some ideas have also been drawn from the DASS system.
-   These changes are by no means endorsed by these groups.  This is an
-   attempt to revive some of the goals of those groups, and this
-   document approaches those goals primarily from the Kerberos
-   perspective.
-
-   Lastly, comments from groups working on similar ideas in DCE have
-   been invaluable.
-
-6.  IANA Considerations
-
-   This document has no actions for IANA.
-
-7.  References
-
-7.1  Normative References
-       
-   [CLAR]     RFC-Editor: To be replaced by RFC number for draft-ietf-
-              krb-wg-kerberos-clarifications.  Work in Progress. 
-
-   [KCRYPTO]  RFC-Editor: To be replaced by RFC number for draft-ietf-
-              krb-wg-crypto.  Work in Progress. 
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
-              RFC 2412, November 1998.
-
-   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
-              RFC 2631, June 1999.
-
-   [RFC3279]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
-              Algorithms", RFC 3370, August 2002.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 20]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-              Version 2.1", RFC 3447, February 2003.
-
-   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
-              Encryption Algorithm in Cryptographic Message Syntax
-              (CMS)", RFC 3565, July 2003.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-             
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding  
-              Rules (BER), Canonical Encoding Rules (CER) and
-              Distinguished Encoding Rules (DER), ITU-T Recommendation
-              X.690 (1997) | ISO/IEC International Standard
-              8825-1:1998.
-
-7.2  Informative References
-   
-   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
-              future, Designs, Codes, and Cryptography (1999)". 
-
-Authors' Addresses
-
-   Brian Tung
-   USC Information Sciences Institute
-   4676 Admiralty Way Suite 1001, Marina del Rey CA
-   Marina del Rey, CA  90292
-   US
-
-   Email: brian@isi.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-Appendix A.  PKINIT ASN.1 Module
-
-       KerberosV5-PK-INIT-SPEC {
-               iso(1) identified-organization(3) dod(6) internet(1)
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 21]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-               security(5) kerberosV5(2) modules(4) pkinit(5)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       IMPORTS
-           SubjectPublicKeyInfo, AlgorithmIdentifier
-               FROM PKIX1Explicit88 { iso (1)
-                 identified-organization (3) dod (6) internet (1)
-                 security (5) mechanisms (5) pkix (7) id-mod (0)
-                 id-pkix1-explicit (18) }
-                 -- As defined in RFC 3280.
-
-           DomainParameters
-               FROM PKIX1Algorithms88 { iso(1)
-                 identified-organization(3) dod(6)
-                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-                 id-mod-pkix1-algorithms(17) }
-                 -- As defined in RFC 3279.
-
-           KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) } ;
-
-       id-pkinit OBJECT IDENTIFIER ::=
-         { iso (1) org (3) dod (6) internet (1) security (5)
-           kerberosv5 (2) pkinit (3) }
-
-       id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-       id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-       id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-       id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-       id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-       pa-pk-as-req INTEGER ::=                 16
-       pa-pk-as-rep INTEGER ::=                 17
-
-       ad-initial-verified-cas INTEGER ::=       9
-
-       td-trusted-certifiers INTEGER ::=        104
-       td-certificate-index INTEGER ::=         105
-       td-dh-parameters INTEGER ::=             109
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 22]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-                   -- A list of CAs, trusted by the client, that can
-                   -- be used to validate KDC certificates.
-          kdcCert                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a particular KDC certificate, if the
-                   -- client already has it.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       TrustedCA ::= CHOICE {
-          caName                  [1] IMPLICIT OCTET STRING,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-          issuerAndSerial         [2] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a specific CA certificate.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Defined in [RFC3280].
-                   -- Present only if the client wishes to use the
-                   -- Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- List of CMS encryption types supported by
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to cache DH keys or to allow the KDC to
-                   -- do so.
-          ...
-       }
-
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 23]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [CLAR], for replay
-                   -- prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-       TrustedCertifiers ::= SEQUENCE OF OCTET STRING
-                   -- The OCTET STRING contains a PKIX type Name encoded
-                   -- according to [RFC3280].
-
-       CertificateIndex ::= OCTET STRING
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-       InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
-          ca                      [0] IMPLICIT OCTET STRING,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-          validated               [1] BOOLEAN,
-          ...
-       }
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is id-pkrkeydata
-                   -- (1.2.840.113549.1.7.3) and the eContent field
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 24]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-                   -- contains the DER encoding of the type
-                   -- ReplyKeyPack.
-                   -- ReplyKeyPack is defined below.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-                   -- present.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- KDC's public key, y = g^x mod p.
-                   -- MUST be ASN.1 encoded as an INTEGER;
-                   -- This encoding is then used as the contents
-                   -- (i.e., the value) of this BIT STRING field.
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request if cached DH keys are NOT used,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's cached values, present
-                   -- if and only if cached DH keys are used.  If this
-                   -- field is omitted then the serverDHNonce field
-                   -- MUST also be omitted.
-          ...
-       }
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP.
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request.
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 25]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-          ...
-       }
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters
-                   -- Contains a list of Diffie-Hellman group
-                   -- parameters in decreasing preference order.
-       END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 26]
-
-Internet-Draft                   PKINIT                     January 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Tung & Zhu               Expires August 4, 2005                [Page 27]
-
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-24.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-24.txt
deleted file mode 100644
index 2aed744ce..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-24.txt
+++ /dev/null
@@ -1,1621 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                            B. Tung
-Internet-Draft                        USC Information Sciences Institute
-Expires: August 11, 2005                                          L. Zhu
-                                                   Microsoft Corporation
-                                                        February 7, 2005
-
-
-     Public Key Cryptography for Initial Authentication in Kerberos
-                    draft-ietf-cat-kerberos-pk-init
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 11, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes protocol extensions (hereafter called PKINIT)
-   to the Kerberos protocol specification.  These extensions provide a
-   method for integrating public key cryptography into the initial
-   authentication exchange, by using asymmetric-key signature and/or
-   encryption algorithms in pre-authentication data fields.
-
-
-
-Tung & Zhu               Expires August 11, 2005                [Page 1]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1   Definitions, Requirements, and Constants . . . . . . . . .  4
-       3.1.1   Required Algorithms  . . . . . . . . . . . . . . . . .  4
-       3.1.2   Defined Message and Encryption Types . . . . . . . . .  5
-       3.1.3   Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
-     3.2   PKINIT Pre-authentication Syntax and Use . . . . . . . . .  6
-       3.2.1   Generation of Client Request . . . . . . . . . . . . .  6
-       3.2.2   Receipt of Client Request  . . . . . . . . . . . . . . 10
-       3.2.3   Generation of KDC Reply  . . . . . . . . . . . . . . . 13
-       3.2.4   Receipt of KDC Reply . . . . . . . . . . . . . . . . . 18
-     3.3   KDC Indication of PKINIT Support . . . . . . . . . . . . . 20
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
-   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
-     7.1   Normative References . . . . . . . . . . . . . . . . . . . 22
-     7.2   Informative References . . . . . . . . . . . . . . . . . . 23
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
-   A.  PKINIT ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 24
-       Intellectual Property and Copyright Statements . . . . . . . . 29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires August 11, 2005                [Page 2]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-1.  Introduction
-
-   A client typically authenticates itself to a service in Kerberos
-   using three distinct though related exchanges.  First, the client
-   requests a ticket-granting ticket (TGT) from the Kerberos
-   authentication server (AS).  Then, it uses the TGT to request a
-   service ticket from the Kerberos ticket-granting server (TGS).
-   Usually, the AS and TGS are integrated in a single device known as a
-   Kerberos Key Distribution Center, or KDC.  (In this document, we will
-   refer to both the AS and the TGS as the KDC.)  Finally, the client
-   uses the service ticket to authenticate itself to the service.
-
-   The advantage afforded by the TGT is that the client exposes his
-   long-term secrets only once.  The TGT and its associated session key
-   can then be used for any subsequent service ticket requests.  One
-   result of this is that all further authentication is independent of
-   the method by which the initial authentication was performed.
-   Consequently, initial authentication provides a convenient place to
-   integrate public-key cryptography into Kerberos authentication.
-
-   As defined in [CLAR], Kerberos authentication exchanges use
-   symmetric-key cryptography, in part for performance.  One
-   disadvantage of using symmetric-key cryptography is that the keys
-   must be shared, so that before a client can authenticate itself, he
-   must already be registered with the KDC.
-
-   Conversely, public-key cryptography (in conjunction with an
-   established Public Key Infrastructure) permits authentication without
-   prior registration with a KDC.  Adding it to Kerberos allows the
-   widespread use of Kerberized applications by clients without
-   requiring them to register first with a KDC--a requirement that has
-   no inherent security benefit.
-
-   As noted above, a convenient and efficient place to introduce
-   public-key cryptography into Kerberos is in the initial
-   authentication exchange.  This document describes the methods and
-   data formats for integrating public-key cryptography into Kerberos
-   initial authentication.
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-Tung & Zhu               Expires August 11, 2005                [Page 3]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-3.  Extensions
-
-   This section describes extensions to [CLAR] for supporting the use of
-   public-key cryptography in the initial request for a ticket.
-
-   Briefly, this document defines the following extensions to [CLAR]:
-
-   1.  The client indicates the use of public-key authentication by
-      including a special preauthenticator in the initial request.  This
-      preauthenticator contains the client's public-key data and a
-      signature.
-
-   2.  The KDC tests the client's request against its authentication
-      policy and trusted Certification Authorities (CAs).
-
-   3.  If the request passes the verification tests, the KDC replies as
-      usual, but the reply is encrypted using either:
-
-      a.  a key generated through a Diffie-Hellman (DH) key exchange
-         [RFC2631][IEEE1363] with the client, signed using the KDC's
-         signature key; or
-
-      b.  a symmetric encryption key, signed using the KDC's signature
-         key and encrypted using the client's public key.
-
-      Any keying material required by the client to obtain the
-      encryption key for decrypting the KDC reply is returned in a
-      pre-authentication field accompanying the usual reply.
-
-   4.  The client validates the KDC's signature, obtains the encryption
-      key, decrypts the reply, and then proceeds as usual.
-
-   Section 3.1 of this document enumerates the required algorithms and
-   necessary extension message types.  Section 3.2 describes the
-   extension messages in greater detail.
-
-3.1  Definitions, Requirements, and Constants
-
-3.1.1  Required Algorithms
-
-   All PKINIT implementations MUST support the following algorithms:
-
-   o  AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO].
-
-   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
-
-   o  KDC AS reply key delivery method: Diffie-Hellman key exchange
-      [RFC2631].
-
-
-
-Tung & Zhu               Expires August 11, 2005                [Page 4]
-
-
-
-3.1.2  Defined Message and Encryption Types
-
-   PKINIT makes use of the following new pre-authentication types:
-
-       PA_PK_AS_REQ                             16
-       PA_PK_AS_REP                             17
-
-   PKINIT also makes use of the following new authorization data type:
-
-       AD_INITIAL_VERIFIED_CAS                   9
-
-   PKINIT introduces the following new error codes:
-
-       KDC_ERR_CLIENT_NOT_TRUSTED                   62
-       KDC_ERR_INVALID_SIG                          64
-       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
-       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
-       KDC_ERR_INVALID_CERTIFICATE                  71
-       KDC_ERR_REVOKED_CERTIFICATE                  72
-       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
-       KDC_ERR_CLIENT_NAME_MISMATCH                 75
-       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
-
-   PKINIT uses the following typed data types for errors:
-
-       TD_TRUSTED_CERTIFIERS                    104
-       TD_INVLID_CERTIFICATES                   105
-       TD_DH_PARAMETERS                         109
-
-   PKINIT defines the following encryption types, for use in the AS-REQ
-   message to indicate acceptance of the corresponding algorithms that
-   can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
-   the reply:
-
-       dsaWithSHA1-CmsOID                         9
-       md5WithRSAEncryption-CmsOID               10
-       sha1WithRSAEncryption-CmsOID              11
-       rc2CBC-EnvOID                             12
-       rsaEncryption-EnvOID   (PKCS1 v1.5)       13
-       rsaES-OAEP-EnvOID      (PKCS1 v2.0)       14
-       des-ede3-cbc-EnvOID                       15
-
-   The ASN.1 module for all structures defined in this document (plus
-   IMPORT statements for all imported structures) is given in
-   Appendix A.
-
-   All structures defined in or imported into this document MUST be
-   encoded using Distinguished Encoding Rules (DER) [X690] (unless
-   otherwise noted).  All data structures carried in OCTET STRINGs must
-
-
-
-Tung & Zhu               Expires August 11, 2005                [Page 5]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   be encoded according to the rules specified in corresponding
-   specifications.
-
-   Interoperability note: Some implementations may not be able to decode
-   wrapped CMS objects encoded with BER but not DER; specifically, they
-   may not be able to decode infinite length encodings.  To maximize
-   interoperability, implementers SHOULD encode CMS objects used in
-   PKINIT with DER.
-
-3.1.3  Algorithm Identifiers
-
-   PKINIT does not define, but does make use of, the following algorithm
-   identifiers.
-
-   PKINIT uses the following algorithm identifiers for Diffie-Hellman
-   key agreement [RFC3279]:
-
-        dhpublicnumber (Diffie-Hellman modulo a prime p [RFC2631])
-        id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
-
-   PKINIT uses the following signature algorithm identifiers [RFC3279]:
-
-       sha-1WithRSAEncryption (RSA with SHA1)
-       md5WithRSAEncryption   (RSA with MD5)
-       id-dsa-with-sha1       (DSA with SHA1)
-
-   PKINIT uses the following encryption algorithm identifiers [RFC3447]
-   for encrypting the temporary key with a public key:
-
-       rsaEncryption          (PKCS1 v1.5)
-       id-RSAES-OAEP          (PKCS1 v2.0)
-
-   PKINIT uses the following algorithm identifiers [RFC3370][RFC3565]
-   for encrypting the reply key with the temporary key:
-
-       des-ede3-cbc           (three-key 3DES, CBC mode)
-       rc2-cbc                (RC2, CBC mode)
-       id-aes256-CBC          (AES-256, CBC mode)
-
-
-3.2  PKINIT Pre-authentication Syntax and Use
-
-   This section defines the syntax and use of the various
-   pre-authentication fields employed by PKINIT.
-
-3.2.1  Generation of Client Request
-
-   The initial authentication request (AS-REQ) is sent as per [CLAR]; in
-
-
-
-Tung & Zhu               Expires August 11, 2005                [Page 6]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   addition, a pre-authentication data element, whose padata-type is
-   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
-   type PA-PK-AS-REQ, is included.
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-                   -- A list of CAs, trusted by the client, that can
-                   -- be used as the trust anchor to validate the KDC's
-                   -- signature.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       TrustedCA ::= CHOICE {
-          caName                  [1] IMPLICIT OCTET STRING,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies a CA.
-                   -- Prefer the sid field below if that is available.
-          sid                     [2] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies the trusted CA's certificate (and
-                   -- thereby the public key).
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-
-
-
-Tung & Zhu               Expires August 11, 2005                [Page 7]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Defined in [RFC3280].
-                   -- The pubic key value (the subjectPublicKey field
-                   -- of the type SubjectPublicKeyInfo) MUST be encoded
-                   -- according to [RFC3279].
-                   -- Present only if the client wishes to use the
-                   -- Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- List of CMS encryption types supported by
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so (see Section 3.2.3.1).
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [CLAR], for replay
-                   -- prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure for the signedAuthPack field is
-   filled out as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is id-pkauthdata:
-       { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-       pkinit(3) pkauthdata(1) }.
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type AuthPack.
-
-
-
-
-
-Tung & Zhu               Expires August 11, 2005                [Page 8]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type AuthPack.
-
-   5.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the KDC can verify the signature over the
-       type AuthPack.  For path validation, these certificates SHOULD be
-       sufficient to construct at least one certification path from the
-       client certificate to one trust anchor acceptable by the KDC
-       [CAPATH].  If the client sends all the X.509 certificates on a
-       certification path to a trust anchor acceptable by the KDC and
-       the KDC can not verify the client's public key otherwise, the KDC
-       MUST process path validation for the client's X.509 certificate
-       based on the certificates in the request.  The certificates field
-       MUST NOT contain "root" CA certificates.
-
-   6.  The client's Diffie-Hellman public value (clientPublicValue) is
-       included if and only if the client wishes to use the
-       Diffie-Hellman key agreement method.  For the Diffie-Hellman key
-       agreement method, implementations MUST support Oakley 1024-bit
-       MODP well-known group 2 [RFC2412] and SHOULD support Oakley
-       2048-bit MODP well-known group 14 and Oakley 4096-bit MODP
-       well-known group 16 [RFC3526].
-
-       The Diffie-Hellman field size should be chosen so as to provide
-       sufficient cryptographic security.  The following table, based on
-       [LENSTRA], gives approximate comparable key sizes for symmetric-
-       and asymmetric-key cryptosystems based on the best-known
-       algorithms for attacking them.
-
-                  Symmetric    |  ECC    |  DH/DSA/RSA
-                  -------------+---------+------------
-                     80        |  163    |  1024
-                    112        |  233    |  2048
-                    128        |  283    |  3072
-                    192        |  409    |  7680
-                    256        |  571    |  15360
-
-                 Table 1: Comparable key sizes (in bits)
-
-       When Diffie-Hellma modulo a prime p is used, the exponents should
-       have at least twice as many bits as the symmetric keys that will
-       be derived from them [ODL99].
-
-   7.  The client may wish to reuse DH keys or to allow the KDC to do so
-       (see Section 3.2.3.1).  If so, then the client includes the
-       clientDHNonce field.  This nonce string needs to be as long as
-       the longest key length of the symmetric key types that the client
-
-
-
-Tung & Zhu               Expires August 11, 2005                [Page 9]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-       supports.  This nonce MUST be chosen randomly.
-
-
-3.2.2  Receipt of Client Request
-
-   Upon receiving the client's request, the KDC validates it.  This
-   section describes the steps that the KDC MUST (unless otherwise
-   noted) take in validating the request.
-
-   The KDC verifies the client's signature in the signedAuthPack field
-   according to [RFC3852].
-
-   If, while validating the client's X.509 certificate [RFC3280], the
-   KDC cannot build a certification path to validate the client's
-   certificate, it sends back a KRB-ERROR [CLAR] message with the code
-   KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for this
-   error message is a TYPED-DATA (as defined in [CLAR]) that contains an
-   element whose data-type is TD_TRUSTED_CERTIFIERS, and whose
-   data-value contains the DER encoding of the type
-   TD-TRUSTED-CERTIFIERS:
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-
-   Upon receiving this error message, the client SHOULD retry only if it
-   has a different set of certificates (from those of the previous
-   requests) that form a certification path (or a partial path) from one
-   of the trust anchors selected by the KDC to its own certificate.
-
-   If, while processing the certification path, the KDC determines that
-   the signature on one of the certificates in the signedAuthPack field
-   is invalid, it returns a KRB-ERROR [CLAR] message with the code
-   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
-   message is a TYPED-DATA that contains an element whose data-type is
-   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
-   encoding of the type TD-INVALID-CERTIFICATES:
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
-                   -- Each OCTET STRING contains a CMS type
-                   -- IssuerAndSerialNumber encoded according to
-                   -- [RFC3852].
-                   -- Each IssuerAndSerialNumber indentifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-   If more than one X.509 certificate signature is invalid, the KDC MAY
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 10]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   send one TYPED-DATA element per invalid signature.
-
-   Based on local policy, the KDC may also check whether any X.509
-   certificates in the certification path validating the client's
-   certificate have been revoked.  If any of them have been revoked, the
-   KDC MUST return an error message with the code
-   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
-   revocation status but is unable to do so, it SHOULD return an error
-   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
-   certificate or certificates affected are identified exactly as for
-   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
-
-   The client's public key is then used to verify the signature.  If the
-   signature fails to verify, the KDC MUST return an error message with
-   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
-   this error message.
-
-   In addition to validating the client's signature, the KDC MUST also
-   check that the client's public key used to verify the client's
-   signature is bound to the client's principal name as specified in the
-   AS-REQ as follows:
-
-   1.  If the KDC has its own binding between either the client's
-      signature-verification public key or the client's certificate and
-      the client's Kerberos principal name, it uses that binding.
-
-   2.  Otherwise, if the client's X.509 certificate contains a
-      SubjectAltName extension with a KRB5PrincipalName (defined below)
-      in the otherName field, it binds the client's X.509 certificate to
-      that name.
-
-      The otherName field (of type AnotherName) in the SubjectAltName
-      extension MUST contain KRB5PrincipalName as defined below.
-
-      The type-id field of the type AnotherName is id-pksan:
-
-       id-pksan OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509-sanan (2) }
-
-      The value field of the type AnotherName is the DER encoding of the
-      following ASN.1 type:
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 11]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   If the KDC does not have its own binding and there is no
-   KRB5PrincipalName name present in the client's X.509 certificate, and
-   if the Kerberos name in the request does not match the
-   KRB5PrincipalName in the client's X.509 certificate (including the
-   realm name), the KDC MUST return an error message with the code
-   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
-   this error message.
-
-   The KDC MAY require the presence of an Extended Key Usage (EKU)
-   KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
-   client's X.509 certificate:
-
-       id-pkekuoid OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) pkekuoid(4) }
-              -- PKINIT client authentication.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature;
-              -- Key usage bits that MAY be consistent:
-              -- nonRepudiation, and (keyEncipherment or keyAgreement).
-
-   If this EKU is required but is missing, the KDC MUST return an error
-   message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There is no
-   accompanying e-data for this error message.  KDCs implementing this
-   requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-logon
-   (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there are a
-   large number of X.509 client certificates deployed for use with
-   PKINIT which have this EKU.
-
-   If for any other reasons, the client's public key is not accepted,
-   the KDC MUST return an error message with the code
-   KDC_ERR_CLIENT_NOT_TRUSTED.
-
-   The KDC MUST check the timestamp to ensure that the request is not a
-   replay, and that the time skew falls within acceptable limits.  The
-   recommendations for clock skew times in [CLAR] apply here.  If the
-   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
-   KRB_AP_ERR_SKEW, respectively.
-
-   If the clientPublicValue is filled in, indicating that the client
-   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
-   check to see if the key parameters satisfy its policy.  If they do
-   not, it MUST return an error message with the code
-   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
-   TYPED-DATA that contains an element whose data-type is
-   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
-   the type TD-DH-PARAMETERS:
-
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 12]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF DHDomainParameters
-                   -- Contains a list of Diffie-Hellman domain
-                   -- parameters in decreasing preference order.
-
-       DHDomainParameters ::= CHOICE {
-           modp                   [0] DomainParameters,
-                   -- Type DomainParameters is defined in [RFC3279].
-           ec                     [1] EcpkParameters,
-                   -- Type EcpkParameters is defined in [RFC3279].
-           ...
-       }
-
-   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
-   that the KDC supports in decreasing preference order, from which the
-   client SHOULD pick one to retry the request.
-
-   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
-   KDC does not have the corresponding key, the KDC MUST ignore the
-   kdcPkId field as if the client did not include one.
-
-   If the client included a trustedCertifiers field, and the KDC does
-   not possesses the private key for any one of the listed certifiers,
-   the KDC MUST ignore the trustedCertifiers field as if the client did
-   not include one.
-
-   If there is a supportedCMSTypes field in the AuthPack, the KDC must
-   check to see if it supports any of the listed types.  If it supports
-   more than one of the types, the KDC SHOULD use the one listed first.
-   If it does not support any of them, it MUST return an error message
-   with the code KDC_ERR_ETYPE_NOSUPP [CLAR].
-
-3.2.3  Generation of KDC Reply
-
-   Assuming that the client's request has been properly validated, the
-   KDC proceeds as per [CLAR], except as follows.
-
-   The KDC MUST set the initial flag and include an authorization data
-   element of ad-type [CLAR] AD_INITIAL_VERIFIED_CAS in the issued
-   ticket.  The ad-data [CLAR] field contains the DER encoding of the
-   type AD-INITIAL-VERIFIED-CAS:
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-
-   The KDC MUST wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 13]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   containers.  Furthermore, any TGS MUST copy such authorization data
-   from tickets used in a PA-TGS-REQ [CLAR] of the TGS-REQ to the
-   resulting ticket.  Upon receipt of a service ticket carrying the
-   AD-INITIAL-VERIFIED-CAS data, application servers MAY apply local
-   policy to determine whether the authorization data is acceptable.
-
-   The content of the AS-REP is otherwise unchanged from [CLAR].  The
-   KDC encrypts the reply as usual, but not with the client's long-term
-   key.  Instead, it encrypts it with either a shared key derived from a
-   Diffie-Hellman exchange, or a generated encryption key.  The contents
-   of the PA-PK-AS-REP indicate which key delivery method is used:
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is id-pkrkeydata
-                   -- (1.2.840.113549.1.7.3) and the eContent field
-                   -- contains the DER encoding of the type
-                   -- ReplyKeyPack.
-                   -- ReplyKeyPack is defined in Section 3.2.3.2.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 14]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-                   -- present in the KDCDHKeyInfo.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- KDC's DH public key.
-                   -- The DH pubic key value is mapped to a BIT STRING
-                   -- according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request if DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if DH keys are reused. If
-                   -- this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted. See Section 3.2.3.1.
-          ...
-       }
-
-
-3.2.3.1  Using Diffie-Hellman Key Exchange
-
-   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
-
-   The ContentInfo [RFC3852] structure for the dhSignedData field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is the OID value
-       for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
-       security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type KDCDHKeyInfo.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type
-       KDCDHKeyInfo.
-
-   5.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type KDCDHKeyInfo.  This field may only be left empty if
-       the KDC public key specified by the kdcPkId field in the
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 15]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-       PA-PK-AS-REQ was used for signing.  Otherwise, for path
-       validation, these certificates SHOULD be sufficient to construct
-       at least one certification path from the KDC certificate to one
-       trust anchor acceptable by the client [CAPATH].  If the KDC sends
-       all the X.509 certificates on a certification path to a trust
-       anchor acceptable by the client and the client can not verify the
-       KDC's public key otherwise, the client MUST process path
-       validation for the KDC's X.509 certificate based on the
-       certificates in the reply.  The certificates field MUST NOT
-       contain "root" CA certificates.
-
-   6.  If the client included the clientDHNonce field, then the KDC may
-       choose to reuse its DH keys (see Section 3.2.3.1).  If the server
-       reuses DH keys then it MUST include an expiration time in the
-       dhKeyExperiation field.  Past the point of the expiration time,
-       the signature over the type DHRepInfo is considered
-       expired/invalid.  When the server reuses DH keys then it MUST
-       include a serverDHNonce at least as long as the length of keys
-       for the symmetric encryption system used to encrypt the AS reply.
-       Note that including the serverDHNonce changes how the client and
-       server calculate the key to use to encrypt the reply; see below
-       for details.  The KDC SHOULD NOT reuse DH keys unless the
-       clientDHNonce field is present in the request.
-
-   The reply key for use to decrypt the KDC reply [CLAR] is derived as
-   follows:
-
-   1.  Both the KDC and the client calculate the shared secret value as
-      follows:
-
-      a) When Diffie-Hellman modulo a prime p ([RFC2631]) is used, let
-         DHSharedSecret be the shared secret value.
-
-      b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party
-         contributing one key pair) [IEEE1363] is used, let
-         DHSharedSecret be the x-coordinate of the shared secret value
-         (an elliptic curve point).
-
-      DHSharedSecret is first padded with leading zeros such that the
-      size of DHSharedSecret in octets is the same as that of the
-      modulus, then represented as a string of octets in big-endian
-      order.
-
-      Implementation note: Both the client and the KDC can cache the
-      triple (ya, yb, DHSharedSecret), where ya is the client's public
-      key and yb is the KDC's public key.  If both ya and yb are the
-      same in a later exchange, the cached DHSharedSecret can be used.
-
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 16]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   2.  Let K be the key-generation seed length [KCRYPTO] of the reply
-      key whose enctype is selected according to [CLAR].
-
-   3.  Define the function octetstring2key() as follows:
-
-           octetstring2key(x) == random-to-key(K-truncate(
-                                    SHA1(0x00 | x) |
-                                    SHA1(0x01 | x) |
-                                    SHA1(0x02 | x) |
-                                    ...
-                                    ))
-
-      where x is an octet string; | is the concatenation operator; 0x00,
-      0x01, 0x02, etc., are each represented as a single octet;
-      random-to-key() is an operation that generates a protocol key from
-      a bitstring of length K; and K-truncate truncates its input to the
-      first K bits.  Both K and random-to-key() are as defined in the
-      kcrypto profile [KCRYPTO] for the enctype of the reply key.
-
-   4.  When DH keys are reused, let n_c be the clientDHNonce, and n_k be
-      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
-      strings.
-
-   5.  The reply key k is:
-
-           k = octetstring2key(DHSharedSecret | n_c | n_k)
-
-
-3.2.3.2  Using Public Key Encryption
-
-   In this case, the PA-PK-AS-REP contains a ContentInfo structure
-   wrapped in an OCTET STRING.  The reply key for use to decrypt the KDC
-   reply [CLAR] is encrypted in the encKeyPack field, which contains
-   data of type ReplyKeyPack:
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP.
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure for the encKeyPack field is
-   filled in as follows:
-
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 17]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   1.  The contentType field of the type ContentInfo is id-envelopedData
-       (as defined in [RFC3852]), and the content field is an
-       EnvelopedData (as defined in [RFC3852]).
-
-   2.  The contentType field for the type EnvelopedData is
-       id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
-       pkcs (1) pkcs7 (7) signedData (2) }.
-
-   3.  The eContentType field for the inner type SignedData (when
-       decrypted from the encryptedContent field for the type
-       EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
-       internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
-
-   4.  The eContent field for the inner type SignedData contains the DER
-       encoding of the type ReplyKeyPack.
-
-   5.  The signerInfos field of the inner type SignedData contains a
-       single signerInfo, which contains the signature over the type
-       ReplyKeyPack.
-
-   6.  The certificates field of the inner type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type ReplyKeyPack.  This field may only be left empty if
-       the KDC public key specified by the kdcPkId field in the
-       PA-PK-AS-REQ was used for signing.  Otherwise, for path
-       validation, these certificates SHOULD be sufficient to construct
-       at least one certification path from the KDC certificate to one
-       trust anchor acceptable by the client [CAPATH].  If the KDC sends
-       all the X.509 certificates on a certification path to a trust
-       anchor acceptable by the client and the client can not verify the
-       KDC's public key otherwise, the client MUST process path
-       validation for the KDC's X.509 certificate based on the
-       certificates in the reply.  The certificates field MUST NOT
-       contain "root" CA certificates.
-
-   7.  The recipientInfos field of the type EnvelopedData is a SET which
-       MUST contain exactly one member of type KeyTransRecipientInfo.
-       The encryptedKey of this member contains the temporary key which
-       is encrypted using the client's public key.
-
-   8.  The unprotectedAttrs or originatorInfo fields of the type
-       EnvelopedData MAY be present.
-
-3.2.4  Receipt of KDC Reply
-
-   Upon receipt of the KDC's reply, the client proceeds as follows.  If
-   the PA-PK-AS-REP contains the dhSignedData field, the client derives
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 18]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   the reply key using the same procedure used by the KDC as defined in
-   Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
-   field, and the client decrypts and extracts the temporary key in the
-   encryptedKey field of the member KeyTransRecipientInfo, and then uses
-   that as the reply key.
-
-   In either case, the client MUST verify the signature in the
-   SignedData according to [RFC3852].  Unless the client can otherwise
-   prove that the public key used to verify the KDC's signature is bound
-   to the target KDC, it MUST verify the responder's identity as
-   follows:
-
-   1.  The KDC's X.509 certificate MUST contain the EKU KeyPurposeId
-      [RFC3280] id-pkkdcekuoid:
-
-       id-pkkdcekuoid OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) pkkdcekuoid(5) }
-              -- Signing KDC responses.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   2.  The KDC's X.509 certificate MUST contain a Subject Alternative
-      Name (SAN) extension [RFC3280] carrying an AnotherName whose
-      type-id is id-pksan (as defined in Section 3.2.2) and whose value
-      contains a KRB5PrincipalName name, and the realm name of that
-      KRB5PrincipalName matches the realm name of the target KDC.  If no
-      such SAN extension is present in the KDC's certificate, the client
-      SHOULD accept the KDC's certificate as meeting this requirement if
-      the KDC's X.509 certificate contains an SAN extension carrying a
-      dNSName and that name value matches the domain style realm name
-      [CLAR] of the target KDC.  The KDC's certificate SHOULD also be
-      accepted if it contains an SAN extension carrying a dNSName or an
-      iPAddress (if the KDC is specified by an IP address instead of a
-      name) and that name value matches the hostname or the IP address
-      of the KDC with which the client believes it is communicating.  If
-      the KDC's hostname or IP address is used to match the dNSName
-      value, it MUST have been obtained securely.  Matching rules used
-      for the dNSName value are specified in [RFC3280].
-
-      Implementation note: CAs issuing KDC certificates SHOULD place all
-      "short" and "fully-qualified" realm names of the KDC (one per SAN
-      id-pksan extension) into the KDC certificate to allow maximum
-      flexibility.
-
-   If all applicable checks are satisfied, the client then decrypts the
-   enc-part of the KDC-REP in the AS-REP with the reply key, and then
-   proceeds as described in [CLAR].
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 19]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-3.3  KDC Indication of PKINIT Support
-
-   If pre-authentication is required, but was not present in the
-   request, per [CLAR] an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
-   stored in the e-data field of the KRB-ERROR message to specify which
-   pre-authentication mechanisms are acceptable.  The KDC can then
-   indicate the support of PKINIT by including an element whose
-   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
-
-   Otherwise if it is required by the KDC's local policy that the client
-   must be pre-authenticated using the pre-authentication mechanism
-   specified in this document, but no PKINIT pre-authentication was
-   present in the request, an error message with the code
-   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
-
-   KDCs MUST leave the padata-value of PA_PK_AS_REQ entry in the
-   KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
-   STRING), and clients MUST ignore this and any other value.  Future
-   extensions to this protocol may specify other data to send instead of
-   an empty OCTET STRING.
-
-4.  Security Considerations
-
-   PKINIT raises certain security considerations beyond those that can
-   be regulated strictly in protocol definitions.  We will address them
-   in this section.
-
-   Users of PKINIT must understand security policies and procedures
-   appropriate to the use of Public Key Infrastructures [RFC3280].
-
-   Standard Kerberos allows the possibility of interactions between
-   cryptosystems of varying strengths; this document adds interactions
-   with public-key cryptosystems to Kerberos.  Some administrative
-   policies may allow the use of relatively weak public keys.  Using
-   such keys to wrap data encrypted under stronger conventional
-   cryptosystems may be inappropriate.
-
-   PKINIT requires keys for symmetric cryptosystems to be generated.
-   Some such systems contain "weak" keys.  For recommendations regarding
-   these weak keys, see [CLAR].
-
-   PKINIT allows the use of the same RSA key pair for encryption and
-   signing when doing RSA encryption based key delivery.  This is not
-   recommended usage of RSA keys [RFC3447], by using DH based key
-   delivery this is avoided.
-
-   Care should be taken in how certificates are chosen for the purposes
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 20]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   of authentication using PKINIT.  Some local policies may require that
-   key escrow be used for certain certificate types.  Deployers of
-   PKINIT should be aware of the implications of using certificates that
-   have escrowed keys for the purposes of authentication.  Because
-   signing only certificates are normally not escrowed, by using DH
-   based key delivery this is avoided.
-
-   PKINIT does not provide for a "return routability" test to prevent
-   attackers from mounting a denial-of-service attack on the KDC by
-   causing it to perform unnecessary and expensive public-key
-   operations.  Strictly speaking, this is also true of standard
-   Kerberos, although the potential cost is not as great, because
-   standard Kerberos does not make use of public-key cryptography.  By
-   using DH based key delivery and reusing DH keys, the necessary crypto
-   processing cost per request can be minimized.
-
-   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
-   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
-   be used if the KDC itself vouches for the user's certificate.
-
-5.  Acknowledgements
-
-   The following people have made significant contributions to this
-   draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
-   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
-   Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon and Karthik
-   Jaganathan.
-
-   Special thanks to Clifford Neuman, Matthew Hur and Sasha Medvinsky
-   who wrote earlier versions of this document.
-
-   The authors are indebt to the Kerberos working group chair Jeffrey
-   Hutzelman who kept track of various issues and was enormously helpful
-   during the creation of this document.
-
-   Some of the ideas on which this document is based arose during
-   discussions over several years between members of the SAAG, the IETF
-   CAT working group, and the PSRG, regarding integration of Kerberos
-   and SPX.  Some ideas have also been drawn from the DASS system.
-   These changes are by no means endorsed by these groups.  This is an
-   attempt to revive some of the goals of those groups, and this
-   document approaches those goals primarily from the Kerberos
-   perspective.
-
-   Lastly, comments from groups working on similar ideas in DCE have
-   been invaluable.
-
-
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 21]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-6.  IANA Considerations
-
-   This document has no actions for IANA.
-
-7.  References
-
-7.1  Normative References
-
-   [CLAR]     RFC-Editor: To be replaced by RFC number for draft-ietf-
-              krb-wg-kerberos-clarifications.  Work in Progress. 
-
-   [IEEE1363] 
-              IEEE, "Standard Specifications for Public Key 
-              Cryptography", IEEE 1363, 2000.
-
-   [KCRYPTO]  RFC-Editor: To be replaced by RFC number for draft-ietf-
-              krb-wg-crypto.  Work in Progress. 
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
-              RFC 2412, November 1998.
-
-   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
-              RFC 2631, June 1999.
-
-   [RFC3279]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
-              Algorithms", RFC 3370, August 2002.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 22]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
-              Encryption Algorithm in Cryptographic Message Syntax
-              (CMS)", RFC 3565, July 2003.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding  
-              Rules (BER), Canonical Encoding Rules (CER) and
-              Distinguished Encoding Rules (DER), ITU-T Recommendation
-              X.690 (1997) | ISO/IEC International Standard
-              8825-1:1998.
-
-7.2  Informative References
-
-   [CAPATH]   RFC-Editor: To be replaced by RFC number for draft-ietf-
-              pkix-certpathbuild.  Work in Progress. 
-
-   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
-              Sizes", Journal of Cryptology 14 (2001) 255-293.
-              
-   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
-              future, Designs, Codes, and Cryptography (1999)". 
-
-
-Authors' Addresses
-
-   Brian Tung
-   USC Information Sciences Institute
-   4676 Admiralty Way Suite 1001, Marina del Rey CA
-   Marina del Rey, CA  90292
-   US
-
-   Email: brian@isi.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-Appendix A.  PKINIT ASN.1 Module
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 23]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-       KerberosV5-PK-INIT-SPEC {
-               iso(1) identified-organization(3) dod(6) internet(1)
-               security(5) kerberosV5(2) modules(4) pkinit(5)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       IMPORTS
-           SubjectPublicKeyInfo, AlgorithmIdentifier
-               FROM PKIX1Explicit88 { iso (1)
-                 identified-organization (3) dod (6) internet (1)
-                 security (5) mechanisms (5) pkix (7) id-mod (0)
-                 id-pkix1-explicit (18) }
-                 -- As defined in RFC 3280.
-
-           DomainParameters, EcpkParameters
-               FROM PKIX1Algorithms88 { iso(1)
-                 identified-organization(3) dod(6)
-                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-                 id-mod-pkix1-algorithms(17) }
-                 -- As defined in RFC 3279.
-
-           KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) } ;
-
-       id-pkinit OBJECT IDENTIFIER ::=
-         { iso (1) org (3) dod (6) internet (1) security (5)
-           kerberosv5 (2) pkinit (3) }
-
-       id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-       id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-       id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-       id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-       id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-       pa-pk-as-req INTEGER ::=                 16
-       pa-pk-as-rep INTEGER ::=                 17
-
-       ad-initial-verified-cas INTEGER ::=       9
-
-       td-trusted-certifiers INTEGER ::=        104
-       td-invalid-certificates INTEGER ::=      105
-       td-dh-parameters INTEGER ::=             109
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 24]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-                   -- A list of CAs, trusted by the client, that can
-                   -- be used as the trust anchor to validate the KDC's
-                   -- signature.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       TrustedCA ::= CHOICE {
-          caName                  [1] IMPLICIT OCTET STRING,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies a CA.
-                   -- Prefer the sid field below if that is available.
-          sid                     [2] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies the trusted CA's certificate (and
-                   -- thereby the public key).
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Defined in [RFC3280].
-                   -- The pubic key value (the subjectPublicKey field
-                   -- of the type SubjectPublicKeyInfo) MUST be encoded
-                   -- according to [RFC3279].
-                   -- Present only if the client wishes to use the
-                   -- Diffie-Hellman key agreement method.
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 25]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- List of CMS encryption types supported by
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so.
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [CLAR], for replay
-                   -- prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
-                   -- Each OCTET STRING contains a CMS type
-                   -- IssuerAndSerialNumber encoded according to
-                   -- [RFC3852].
-                   -- Each IssuerAndSerialNumber indentifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 26]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is id-pkrkeydata
-                   -- (1.2.840.113549.1.7.3) and the eContent field
-                   -- contains the DER encoding of the type
-                   -- ReplyKeyPack.
-                   -- ReplyKeyPack is defined below.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-                   -- present.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- KDC's DH public key.
-                   -- The DH pubic key value is mapped to a BIT STRING
-                   -- according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request if DH keys are NOT reused,
-                   -- 0 otherwise.
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 27]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if DH keys are reused. If
-                   -- this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP.
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request.
-          ...
-       }
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF DHDomainParameters
-                   -- Contains a list of Diffie-Hellman domain
-                   -- parameters in decreasing preference order.
-
-       DHDomainParameters ::= CHOICE {
-           modp                   [0] DomainParameters,
-                   -- Type DomainParameters is defined in [RFC3279].
-           ec                     [1] EcpkParameters,
-                   -- Type EcpkParameters is defined in [RFC3279].
-           ...
-       }
-       END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 28]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Tung & Zhu               Expires August 11, 2005               [Page 29]
-
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-25.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-25.txt
deleted file mode 100644
index cb13ed0bb..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-25.txt
+++ /dev/null
@@ -1,1674 +0,0 @@
-
-
-NETWORK WORKING GROUP                                            B. Tung
-Internet-Draft                        USC Information Sciences Institute
-Expires: August 22, 2005                                          L. Zhu
-                                                   Microsoft Corporation
-                                                       February 18, 2005
-
-
-     Public Key Cryptography for Initial Authentication in Kerberos
-                    draft-ietf-cat-kerberos-pk-init-25
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 22, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes protocol extensions (hereafter called PKINIT)
-   to the Kerberos protocol specification.  These extensions provide a
-   method for integrating public key cryptography into the initial
-   authentication exchange, by using asymmetric-key signature and/or
-   encryption algorithms in pre-authentication data fields.
-
-
-
-Tung & Zhu               Expires August 22, 2005                [Page 1]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1   Definitions, Requirements, and Constants . . . . . . . . .  4
-       3.1.1   Required Algorithms  . . . . . . . . . . . . . . . . .  4
-       3.1.2   Defined Message and Encryption Types . . . . . . . . .  5
-       3.1.3   Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
-     3.2   PKINIT Pre-authentication Syntax and Use . . . . . . . . .  6
-       3.2.1   Generation of Client Request . . . . . . . . . . . . .  6
-       3.2.2   Receipt of Client Request  . . . . . . . . . . . . . . 10
-       3.2.3   Generation of KDC Reply  . . . . . . . . . . . . . . . 13
-       3.2.4   Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
-     3.3   Interoperability Requirements  . . . . . . . . . . . . . . 20
-     3.4   KDC Indication of PKINIT Support . . . . . . . . . . . . . 20
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
-   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
-     7.1   Normative References . . . . . . . . . . . . . . . . . . . 23
-     7.2   Informative References . . . . . . . . . . . . . . . . . . 24
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
-   A.  PKINIT ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 25
-       Intellectual Property and Copyright Statements . . . . . . . . 30
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires August 22, 2005                [Page 2]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-1.  Introduction
-
-   A client typically authenticates itself to a service in Kerberos
-   using three distinct though related exchanges.  First, the client
-   requests a ticket-granting ticket (TGT) from the Kerberos
-   authentication server (AS).  Then, it uses the TGT to request a
-   service ticket from the Kerberos ticket-granting server (TGS).
-   Usually, the AS and TGS are integrated in a single device known as a
-   Kerberos Key Distribution Center, or KDC.  (In this document, both
-   the AS and the TGS are referred to as the KDC.)  Finally, the client
-   uses the service ticket to authenticate itself to the service.
-
-   The advantage afforded by the TGT is that the client exposes his
-   long-term secrets only once.  The TGT and its associated session key
-   can then be used for any subsequent service ticket requests.  One
-   result of this is that all further authentication is independent of
-   the method by which the initial authentication was performed.
-   Consequently, initial authentication provides a convenient place to
-   integrate public-key cryptography into Kerberos authentication.
-
-   As defined in [CLAR], Kerberos authentication exchanges use
-   symmetric-key cryptography, in part for performance.  One
-   disadvantage of using symmetric-key cryptography is that the keys
-   must be shared, so that before a client can authenticate itself, he
-   must already be registered with the KDC.
-
-   Conversely, public-key cryptography (in conjunction with an
-   established Public Key Infrastructure) permits authentication without
-   prior registration with a KDC.  Adding it to Kerberos allows the
-   widespread use of Kerberized applications by clients without
-   requiring them to register first with a KDC--a requirement that has
-   no inherent security benefit.
-
-   As noted above, a convenient and efficient place to introduce
-   public-key cryptography into Kerberos is in the initial
-   authentication exchange.  This document describes the methods and
-   data formats for integrating public-key cryptography into Kerberos
-   initial authentication.
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   In this document, the encryption key used to encrypt the enc-part
-   field of the KDC-REP in the AS-REP [CLAR] is referred to as the KDC
-   AS reply key.
-
-
-
-Tung & Zhu               Expires August 22, 2005                [Page 3]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-3.  Extensions
-
-   This section describes extensions to [CLAR] for supporting the use of
-   public-key cryptography in the initial request for a ticket.
-
-   Briefly, this document defines the following extensions to [CLAR]:
-
-   1.  The client indicates the use of public-key authentication by
-      including a special preauthenticator in the initial request.  This
-      preauthenticator contains the client's public-key data and a
-      signature.
-
-   2.  The KDC tests the client's request against its authentication
-      policy and trusted Certification Authorities (CAs).
-
-   3.  If the request passes the verification tests, the KDC replies as
-      usual, but the reply is encrypted using either:
-
-      a.  a key generated through a Diffie-Hellman (DH) key exchange
-         [RFC2631][IEEE1363] with the client, signed using the KDC's
-         signature key; or
-
-      b.  a symmetric encryption key, signed using the KDC's signature
-         key and encrypted using the client's public key.
-
-      Any keying material required by the client to obtain the
-      encryption key for decrypting the KDC reply is returned in a
-      pre-authentication field accompanying the usual reply.
-
-   4.  The client validates the KDC's signature, obtains the encryption
-      key, decrypts the reply, and then proceeds as usual.
-
-   Section 3.1 of this document enumerates the required algorithms and
-   necessary extension message types.  Section 3.2 describes the
-   extension messages in greater detail.
-
-3.1  Definitions, Requirements, and Constants
-
-3.1.1  Required Algorithms
-
-   All PKINIT implementations MUST support the following algorithms:
-
-   o  KDC AS reply key enctype: AES256-CTS-HMAC-SHA1-96 etype [RFC3961].
-
-   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
-
-   o  KDC AS reply key delivery method: Diffie-Hellman key exchange
-      [RFC2631].
-
-
-
-Tung & Zhu               Expires August 22, 2005                [Page 4]
-
-
-
-3.1.2  Defined Message and Encryption Types
-
-   PKINIT makes use of the following new pre-authentication types:
-
-       PA_PK_AS_REQ                                 16
-       PA_PK_AS_REP                                 17
-
-   PKINIT also makes use of the following new authorization data type:
-
-       AD_INITIAL_VERIFIED_CAS                       9
-
-   PKINIT introduces the following new error codes:
-
-       KDC_ERR_CLIENT_NOT_TRUSTED                   62
-       KDC_ERR_INVALID_SIG                          64
-       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
-       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
-       KDC_ERR_INVALID_CERTIFICATE                  71
-       KDC_ERR_REVOKED_CERTIFICATE                  72
-       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
-       KDC_ERR_CLIENT_NAME_MISMATCH                 75
-       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
-
-   PKINIT uses the following typed data types for errors:
-
-       TD_TRUSTED_CERTIFIERS                       104
-       TD_INVLID_CERTIFICATES                      105
-       TD_DH_PARAMETERS                            109
-
-   PKINIT defines the following encryption types, for use in the AS-REQ
-   message to indicate acceptance of the corresponding algorithms that
-   can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
-   the reply:
-
-       dsaWithSHA1-CmsOID                            9
-       md5WithRSAEncryption-CmsOID                  10
-       sha1WithRSAEncryption-CmsOID                 11
-       rc2CBC-EnvOID                                12
-       rsaEncryption-EnvOID   (PKCS1 v1.5)          13
-       rsaES-OAEP-EnvOID      (PKCS1 v2.0)          14
-       des-ede3-cbc-EnvOID                          15
-
-   The ASN.1 module for all structures defined in this document (plus
-   IMPORT statements for all imported structures) is given in
-   Appendix A.
-
-   All structures defined in or imported into this document MUST be
-   encoded using Distinguished Encoding Rules (DER) [X690] (unless
-   otherwise noted).  All data structures carried in OCTET STRINGs must
-
-
-
-Tung & Zhu               Expires August 22, 2005                [Page 5]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   be encoded according to the rules specified in corresponding
-   specifications.
-
-   Interoperability note: Some implementations may not be able to decode
-   wrapped CMS objects encoded with BER but not DER; specifically, they
-   may not be able to decode infinite length encodings.  To maximize
-   interoperability, implementers SHOULD encode CMS objects used in
-   PKINIT with DER.
-
-3.1.3  Algorithm Identifiers
-
-   PKINIT does not define, but does make use of, the following algorithm
-   identifiers.
-
-   PKINIT uses the following algorithm identifiers for Diffie-Hellman
-   key agreement [RFC3279]:
-
-       dhpublicnumber (Diffie-Hellman modulo a prime p [RFC2631])
-       id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
-
-   PKINIT uses the following signature algorithm identifiers [RFC3279]:
-
-       sha-1WithRSAEncryption (RSA with SHA1)
-       md5WithRSAEncryption   (RSA with MD5)
-       id-dsa-with-sha1       (DSA with SHA1)
-
-   PKINIT uses the following encryption algorithm identifiers [RFC3447]
-   for encrypting the temporary key with a public key:
-
-       rsaEncryption          (PKCS1 v1.5)
-       id-RSAES-OAEP          (PKCS1 v2.0)
-
-   PKINIT uses the following algorithm identifiers [RFC3370][RFC3565]
-   for encrypting the KDC AS reply key with the temporary key:
-
-       des-ede3-cbc           (three-key 3DES, CBC mode)
-       rc2-cbc                (RC2, CBC mode)
-       id-aes256-CBC          (AES-256, CBC mode)
-
-
-3.2  PKINIT Pre-authentication Syntax and Use
-
-   This section defines the syntax and use of the various
-   pre-authentication fields employed by PKINIT.
-
-3.2.1  Generation of Client Request
-
-   The initial authentication request (AS-REQ) is sent as per [CLAR]; in
-
-
-
-Tung & Zhu               Expires August 22, 2005                [Page 6]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   addition, a pre-authentication data element, whose padata-type is
-   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
-   type PA-PK-AS-REQ, is included.
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-                   -- A list of CAs, trusted by the client, that can
-                   -- be used as the trust anchor to validate the KDC's
-                   -- signature.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       TrustedCA ::= SEQUENCE {
-          caName                  [0] IMPLICIT OCTET STRING,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies a CA by the CA's distinguished subject
-                   -- name.
-          certificateSerialNumber [1] INTEGER OPTIONAL,
-                   -- Specifies the CA certificate's serial number.
-                   -- The defintion of the certificate serial number
-                   -- is taken from X.509 [X.509-97].
-          subjectKeyIdentifier    [2] OCTET STRING OPTIONAL,
-                   -- Identifies the CA's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-
-
-
-Tung & Zhu               Expires August 22, 2005                [Page 7]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The public key value (the subjectPublicKey field
-                   -- of the type SubjectPublicKeyInfo) MUST be encoded
-                   -- according to [RFC3279].
-                   -- Present only if the client wishes to use the
-                   -- Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so (see Section 3.2.3.1).
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [CLAR], for replay
-                   -- prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure for the signedAuthPack field is
-
-
-
-Tung & Zhu               Expires August 22, 2005                [Page 8]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   filled out as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is id-pkauthdata:
-       { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-       pkinit(3) pkauthdata(1) }.
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type AuthPack.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type AuthPack.
-
-   5.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the KDC can verify the signature over the
-       type AuthPack.  For path validation, these certificates SHOULD be
-       sufficient to construct at least one certification path from the
-       client certificate to one trust anchor acceptable by the KDC
-       [CAPATH].  The certificates field MUST NOT contain "root" CA
-       certificates.
-
-   6.  The client's Diffie-Hellman public value (clientPublicValue) is
-       included if and only if the client wishes to use the
-       Diffie-Hellman key agreement method.  The Diffie-Hellman domain
-       parameters for the client's public key are specified in the
-       algorithm field of the type SubjectPublicKeyInfo
-       [IEEE1363][RFC3279] and the client's Diffie-Hellman public key
-       value is mapped to a subjectPublicKey (a BIT STRING) according to
-       [RFC3279].  When using the Diffie-Hellman key agreement method,
-       implementations MUST support Oakley 1024-bit MODP well-known
-       group 2 [RFC2412] and SHOULD support Oakley 2048-bit MODP
-       well-known group 14 and Oakley 4096-bit MODP well-known group 16
-       [RFC3526].
-
-       The Diffie-Hellman field size should be chosen so as to provide
-       sufficient cryptographic security.  The following table, based on
-       [LENSTRA], gives approximate comparable key sizes for symmetric-
-       and asymmetric-key cryptosystems based on the best-known
-       algorithms for attacking them.
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires August 22, 2005                [Page 9]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-                  Symmetric    |  ECC    |  DH/DSA/RSA
-                  -------------+---------+------------
-                     80        |  163    |  1024
-                    112        |  233    |  2048
-                    128        |  283    |  3072
-                    192        |  409    |  7680
-                    256        |  571    |  15360
-
-                 Table 1: Comparable key sizes (in bits)
-
-       When Diffie-Hellma modulo a prime p is used, the exponents should
-       have at least twice as many bits as the symmetric keys that will
-       be derived from them [ODL99].
-
-   7.  The client may wish to reuse DH keys or to allow the KDC to do so
-       (see Section 3.2.3.1).  If so, then the client includes the
-       clientDHNonce field.  This nonce string needs to be as long as
-       the longest key length of the symmetric key types that the client
-       supports.  This nonce MUST be chosen randomly.
-
-
-3.2.2  Receipt of Client Request
-
-   Upon receiving the client's request, the KDC validates it.  This
-   section describes the steps that the KDC MUST (unless otherwise
-   noted) take in validating the request.
-
-   The KDC verifies the client's signature in the signedAuthPack field
-   according to [RFC3852].
-
-   If, while validating the client's X.509 certificate [RFC3280], the
-   KDC cannot build a certification path to validate the client's
-   certificate, it sends back a KRB-ERROR [CLAR] message with the code
-   KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for this
-   error message is a TYPED-DATA (as defined in [CLAR]) that contains an
-   element whose data-type is TD_TRUSTED_CERTIFIERS, and whose
-   data-value contains the DER encoding of the type
-   TD-TRUSTED-CERTIFIERS:
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-
-   Upon receiving this error message, the client SHOULD retry only if it
-   has a different set of certificates (from those of the previous
-   requests) that form a certification path (or a partial path) from one
-   of the trust anchors selected by the KDC to its own certificate.
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 10]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   If, while processing the certification path, the KDC determines that
-   the signature on one of the certificates in the signedAuthPack field
-   is invalid, it returns a KRB-ERROR [CLAR] message with the code
-   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
-   message is a TYPED-DATA that contains an element whose data-type is
-   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
-   encoding of the type TD-INVALID-CERTIFICATES:
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
-                   -- Each OCTET STRING contains a CMS type
-                   -- IssuerAndSerialNumber encoded according to
-                   -- [RFC3852].
-                   -- Each IssuerAndSerialNumber indentifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-   If more than one X.509 certificate signature is invalid, the KDC MAY
-   send one TYPED-DATA element per invalid signature.
-
-   Based on local policy, the KDC may also check whether any X.509
-   certificates in the certification path validating the client's
-   certificate have been revoked.  If any of them have been revoked, the
-   KDC MUST return an error message with the code
-   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
-   revocation status but is unable to do so, it SHOULD return an error
-   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
-   certificate or certificates affected are identified exactly as for
-   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
-
-   The client's public key is then used to verify the signature.  If the
-   signature fails to verify, the KDC MUST return an error message with
-   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
-   this error message.
-
-   In addition to validating the client's signature, the KDC MUST also
-   check that the client's public key used to verify the client's
-   signature is bound to the client's principal name as specified in the
-   AS-REQ as follows:
-
-   1.  If the KDC has its own binding between either the client's
-      signature-verification public key or the client's certificate and
-      the client's Kerberos principal name, it uses that binding.
-
-   2.  Otherwise, if the client's X.509 certificate contains a Subject
-      Alternative Name (SAN) extension [RFC3280] with a
-      KRB5PrincipalName (defined below) in the otherName field, it binds
-      the client's X.509 certificate to that name.
-
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 11]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-      The otherName field (of type AnotherName) in the SAN extension
-      MUST contain KRB5PrincipalName as defined below.
-
-      The type-id field of the type AnotherName is id-pksan:
-
-       id-pksan OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509-sanan (2) }
-
-      The value field of the type AnotherName is the DER encoding of the
-      following ASN.1 type:
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-   If the KDC does not have its own binding and there is no
-   KRB5PrincipalName name present in the client's X.509 certificate, and
-   if the Kerberos name in the request does not match the
-   KRB5PrincipalName in the client's X.509 certificate (including the
-   realm name), the KDC MUST return an error message with the code
-   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
-   this error message.
-
-   The KDC MAY require the presence of an Extended Key Usage (EKU)
-   KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
-   client's X.509 certificate:
-
-       id-pkekuoid OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) pkekuoid(4) }
-              -- PKINIT client authentication.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature;
-              -- Key usage bits that MAY be consistent:
-              -- nonRepudiation, and (keyEncipherment or keyAgreement).
-
-   If this EKU is required but is missing, the KDC MUST return an error
-   message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There is no
-   accompanying e-data for this error message.  KDCs implementing this
-   requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-logon
-   (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there are a
-   large number of X.509 client certificates deployed for use with
-   PKINIT which have this EKU.
-
-   If for any other reasons, the client's public key is not accepted,
-   the KDC MUST return an error message with the code
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 12]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   KDC_ERR_CLIENT_NOT_TRUSTED.
-
-   The KDC MUST check the timestamp to ensure that the request is not a
-   replay, and that the time skew falls within acceptable limits.  The
-   recommendations for clock skew times in [CLAR] apply here.  If the
-   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
-   KRB_AP_ERR_SKEW, respectively.
-
-   If the clientPublicValue is filled in, indicating that the client
-   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
-   check to see if the key parameters satisfy its policy.  If they do
-   not, it MUST return an error message with the code
-   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
-   TYPED-DATA that contains an element whose data-type is
-   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
-   the type TD-DH-PARAMETERS:
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-
-   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
-   that the KDC supports in decreasing preference order, from which the
-   client SHOULD pick one to retry the request.
-
-   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
-   KDC does not possess the corresponding key, the KDC MUST ignore the
-   kdcPkId field as if the client did not include one.
-
-   If the client included a trustedCertifiers field, and the KDC does
-   not possesses the private key for any one of the listed certifiers,
-   the KDC MUST ignore the trustedCertifiers field as if the client did
-   not include any.
-
-   If there is a supportedCMSTypes field in the AuthPack, the KDC must
-   check to see if it supports any of the listed types.  If it supports
-   more than one of the types, the KDC SHOULD use the one listed first.
-   If it does not support any of them, it MUST return an error message
-   with the code KDC_ERR_ETYPE_NOSUPP [CLAR].
-
-3.2.3  Generation of KDC Reply
-
-   Assuming that the client's request has been properly validated, the
-   KDC proceeds as per [CLAR], except as follows.
-
-   The KDC MUST set the initial flag and include an authorization data
-   element of ad-type [CLAR] AD_INITIAL_VERIFIED_CAS in the issued
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 13]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   ticket.  The ad-data [CLAR] field contains the DER encoding of the
-   type AD-INITIAL-VERIFIED-CAS:
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-
-   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-   containers if the list of CAs satisfies the AS' realm's local policy
-   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
-   [CLAR]).  Furthermore, any TGS MUST copy such authorization data from
-   tickets used in a PA-TGS-REQ [CLAR] of the TGS-REQ to the resulting
-   ticket, and it can wrap or unwrap the data into or out-of the
-   AD-IF-RELEVANT container, depends on if the list of CAs satisfies the
-   TGS' realm's local policy.
-
-   Application servers that understand this authorization data type
-   SHOULD apply local policy to determine whether a given ticket bearing
-   such a type *not* contained within an AD-IF-RELEVANT container is
-   acceptable.  (This corresponds to the AP server checking the
-   transited field when the TRANSITED-POLICY-CHECKED flag has not been
-   set [CLAR].)  If such a data type is contained within an
-   AD-IF-RELEVANT container, AP servers MAY apply local policy to
-   determine whether the authorization data is acceptable.
-
-   The content of the AS-REP is otherwise unchanged from [CLAR].  The
-   KDC encrypts the reply as usual, but not with the client's long-term
-   key.  Instead, it encrypts it with either a shared key derived from a
-   Diffie-Hellman exchange, or a generated encryption key.  The contents
-   of the PA-PK-AS-REP indicate which key delivery method is used:
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is id-pkrkeydata
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 14]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-                   -- (1.2.840.113549.1.7.3) and the eContent field
-                   -- contains the DER encoding of the type
-                   -- ReplyKeyPack.
-                   -- ReplyKeyPack is defined in Section 3.2.3.2.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-                   -- present in the KDCDHKeyInfo.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- KDC's DH public key.
-                   -- The DH pubic key value is mapped to a BIT STRING
-                   -- according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request if DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if DH keys are reused. If
-                   -- this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted. See Section 3.2.3.1.
-          ...
-       }
-
-
-3.2.3.1  Using Diffie-Hellman Key Exchange
-
-   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
-
-   The ContentInfo [RFC3852] structure for the dhSignedData field is
-   filled in as follows:
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 15]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is the OID value
-       for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
-       security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type KDCDHKeyInfo.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type
-       KDCDHKeyInfo.
-
-   5.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type KDCDHKeyInfo.  This field may only be left empty if
-       the KDC public key specified by the kdcPkId field in the
-       PA-PK-AS-REQ was used for signing.  Otherwise, for path
-       validation, these certificates SHOULD be sufficient to construct
-       at least one certification path from the KDC certificate to one
-       trust anchor acceptable by the client [CAPATH].  The certificates
-       field MUST NOT contain "root" CA certificates.
-
-   6.  If the client included the clientDHNonce field, then the KDC may
-       choose to reuse its DH keys (see Section 3.2.3.1).  If the server
-       reuses DH keys then it MUST include an expiration time in the
-       dhKeyExperiation field.  Past the point of the expiration time,
-       the signature over the type DHRepInfo is considered
-       expired/invalid.  When the server reuses DH keys then it MUST
-       include a serverDHNonce at least as long as the length of keys
-       for the symmetric encryption system used to encrypt the AS reply.
-       Note that including the serverDHNonce changes how the client and
-       server calculate the key to use to encrypt the reply; see below
-       for details.  The KDC SHOULD NOT reuse DH keys unless the
-       clientDHNonce field is present in the request.
-
-   The KDC AS reply key is derived as follows:
-
-   1.  Both the KDC and the client calculate the shared secret value as
-      follows:
-
-      a) When Diffie-Hellman modulo a prime p ([RFC2631]) is used, let
-         DHSharedSecret be the shared secret value.
-
-
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 16]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-      b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party
-         contributing one key pair) [IEEE1363] is used, let
-         DHSharedSecret be the x-coordinate of the shared secret value
-         (an elliptic curve point).
-
-      DHSharedSecret is first padded with leading zeros such that the
-      size of DHSharedSecret in octets is the same as that of the
-      modulus, then represented as a string of octets in big-endian
-      order.
-
-      Implementation note: Both the client and the KDC can cache the
-      triple (ya, yb, DHSharedSecret), where ya is the client's public
-      key and yb is the KDC's public key.  If both ya and yb are the
-      same in a later exchange, the cached DHSharedSecret can be used.
-
-   2.  Let K be the key-generation seed length [RFC3961] of the KDC AS
-      reply key whose enctype is selected according to [CLAR].
-
-   3.  Define the function octetstring2key() as follows:
-
-           octetstring2key(x) == random-to-key(K-truncate(
-                                    SHA1(0x00 | x) |
-                                    SHA1(0x01 | x) |
-                                    SHA1(0x02 | x) |
-                                    ...
-                                    ))
-
-      where x is an octet string; | is the concatenation operator; 0x00,
-      0x01, 0x02, etc., are each represented as a single octet;
-      random-to-key() is an operation that generates a protocol key from
-      a bitstring of length K; and K-truncate truncates its input to the
-      first K bits.  Both K and random-to-key() are as defined in the
-      kcrypto profile [RFC3961] for the enctype of the KDC AS reply key.
-
-   4.  When DH keys are reused, let n_c be the clientDHNonce, and n_k be
-      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
-      strings.
-
-   5.  The KDC AS reply key k is:
-
-           k = octetstring2key(DHSharedSecret | n_c | n_k)
-
-
-3.2.3.2  Using Public Key Encryption
-
-   In this case, the PA-PK-AS-REP contains a ContentInfo structure
-   wrapped in an OCTET STRING.  The KDC AS reply key is encrypted in the
-   encKeyPack field, which contains data of type ReplyKeyPack:
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 17]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP.
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure for the encKeyPack field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-envelopedData
-       (as defined in [RFC3852]), and the content field is an
-       EnvelopedData (as defined in [RFC3852]).
-
-   2.  The contentType field for the type EnvelopedData is
-       id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
-       pkcs (1) pkcs7 (7) signedData (2) }.
-
-   3.  The eContentType field for the inner type SignedData (when
-       decrypted from the encryptedContent field for the type
-       EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
-       internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
-
-   4.  The eContent field for the inner type SignedData contains the DER
-       encoding of the type ReplyKeyPack.
-
-   5.  The signerInfos field of the inner type SignedData contains a
-       single signerInfo, which contains the signature over the type
-       ReplyKeyPack.
-
-   6.  The certificates field of the inner type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type ReplyKeyPack.  This field may only be left empty if
-       the KDC public key specified by the kdcPkId field in the
-       PA-PK-AS-REQ was used for signing.  Otherwise, for path
-       validation, these certificates SHOULD be sufficient to construct
-       at least one certification path from the KDC certificate to one
-       trust anchor acceptable by the client [CAPATH].  The certificates
-       field MUST NOT contain "root" CA certificates.
-
-   7.  The recipientInfos field of the type EnvelopedData is a SET which
-       MUST contain exactly one member of type KeyTransRecipientInfo.
-       The encryptedKey of this member contains the temporary key which
-       is encrypted using the client's public key.
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 18]
-
-
-   8.  The unprotectedAttrs or originatorInfo fields of the type
-       EnvelopedData MAY be present.
-
-3.2.4  Receipt of KDC Reply
-
-   Upon receipt of the KDC's reply, the client proceeds as follows.  If
-   the PA-PK-AS-REP contains the dhSignedData field, the client derives
-   the KDC AS reply key using the same procedure used by the KDC as
-   defined in Section 3.2.3.1.  Otherwise, the message contains the
-   encKeyPack field, and the client decrypts and extracts the temporary
-   key in the encryptedKey field of the member KeyTransRecipientInfo,
-   and then uses that as the KDC AS reply key.
-
-   In either case, the client MUST verify the signature in the
-   SignedData according to [RFC3852].  Unless the client can otherwise
-   prove that the public key used to verify the KDC's signature is bound
-   to the target KDC,  the KDC's X.509 certificate MUST satisfy at least
-   one of the following two requirements:
-
-   1.  The certificate contains a Subject Alternative Name (SAN)
-       extension [RFC3280] carrying a dNSName and that name value
-       matches the following name format:
-
-           _Service._Proto.Realm
-
-        Where the Service name is the string literal "kerberos", the
-       Proto can be "udp" or "tcp", and the Realm is the domain style
-       Kerberos realm name [CLAR] of the target KDC.  This name format
-       is identical to the owner label format used in the DNS SRV
-       records for specifying the KDC location as described in [CLAR].
-       For example, the X.509 certificate for the KDC of the Kerberos
-       realm "EXAMPLE.COM" would contain a dNSName value of
-       "_kerberos._tcp.EXAMPLE.COM" or "_kerberos._udp.EXAMPLE.COM".
-
-   2.  The certificate contains the EKU KeyPurposeId [RFC3280]
-       id-pkkdcekuoid (defined below) and an SAN extension [RFC3280]
-       carrying an AnotherName whose type-id is id-pksan (as defined in
-       Section 3.2.2) and whose value contains a KRB5PrincipalName name,
-       and the realm name of that KRB5PrincipalName matches the realm
-       name of the target KDC.
-
-       id-pkkdcekuoid OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) pkkdcekuoid(5) }
-              -- Signing KDC responses.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-        If no SAN id-pksan extension is present (but the id-pkkdcekuoid
-       EKU is) in the KDC's X.509 certificate, and the client has a
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 19]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-       priori knowledge of the KDC's hostname (or IP address), the
-       client SHOULD accept the KDC's X.509 certificate if that
-       certificate contains an SAN extension carrying a dNSName and the
-       dNSName value matches the hostname (or the IP address) of the KDC
-       with which the client believes it is communicating.
-
-   Matching rules used for the dNSName value are specified in [RFC3280].
-
-   If all applicable checks are satisfied, the client then decrypts the
-   enc-part field of the KDC-REP in the AS-REP using the KDC AS reply
-   key, and then proceeds as described in [CLAR].
-
-   Implementation note: CAs issuing KDC certificates SHOULD place all
-   "short" and "fully-qualified" Kerberos realm names of the KDC (one
-   per SAN extension) into the KDC certificate to allow maximum
-   flexibility.
-
-3.3  Interoperability Requirements
-
-   The client MUST be capable of sending a set of certificates
-   sufficient to allow the KDC to construct a certification path for the
-   client's certificate, if the correct set of certificates is provided
-   through configuration or policy.
-
-   If the client sends all the X.509 certificates on a certification
-   path to a trust anchor acceptable by the KDC, and the KDC can not
-   verify the client's public key otherwise, the KDC MUST be able to
-   process path validation for the client's certificate based on the
-   certificates in the request.
-
-   The KDC MUST be capable of sending a set of certificates sufficient
-   to allow the client to construct a certification path for the KDC's
-   certificate, if the correct set of certificates is provided through
-   configuration or policy.
-
-   If the KDC sends all the X.509 certificates on a certification path
-   to a trust anchor acceptable by the client, and the client can not
-   verify the KDC's public key otherwise, the client MUST be able to
-   process path validation for the KDC's certificate based on the
-   certificates in the reply.
-
-3.4  KDC Indication of PKINIT Support
-
-   If pre-authentication is required, but was not present in the
-   request, per [CLAR] an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
-   stored in the e-data field of the KRB-ERROR message to specify which
-   pre-authentication mechanisms are acceptable.  The KDC can then
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 20]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   indicate the support of PKINIT by including an empty element whose
-   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
-
-   Otherwise if it is required by the KDC's local policy that the client
-   must be pre-authenticated using the pre-authentication mechanism
-   specified in this document, but no PKINIT pre-authentication was
-   present in the request, an error message with the code
-   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
-
-   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
-   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
-   STRING), and clients MUST ignore this and any other value.  Future
-   extensions to this protocol may specify other data to send instead of
-   an empty OCTET STRING.
-
-4.  Security Considerations
-
-   PKINIT raises certain security considerations beyond those that can
-   be regulated strictly in protocol definitions.  We will address them
-   in this section.
-
-   PKINIT extends the cross-realm model to the public-key
-   infrastructure.  Users of PKINIT must understand security policies
-   and procedures appropriate to the use of Public Key Infrastructures
-   [RFC3280].
-
-   Standard Kerberos allows the possibility of interactions between
-   cryptosystems of varying strengths; this document adds interactions
-   with public-key cryptosystems to Kerberos.  Some administrative
-   policies may allow the use of relatively weak public keys.  Using
-   such keys to wrap data encrypted under stronger conventional
-   cryptosystems may be inappropriate.
-
-   PKINIT requires keys for symmetric cryptosystems to be generated.
-   Some such systems contain "weak" keys.  For recommendations regarding
-   these weak keys, see [CLAR].
-
-   PKINIT allows the use of the same RSA key pair for encryption and
-   signing when doing RSA encryption based key delivery.  This is not
-   recommended usage of RSA keys [RFC3447], by using DH based key
-   delivery this is avoided.
-
-   Care should be taken in how certificates are chosen for the purposes
-   of authentication using PKINIT.  Some local policies may require that
-   key escrow be used for certain certificate types.  Deployers of
-   PKINIT should be aware of the implications of using certificates that
-   have escrowed keys for the purposes of authentication.  Because
-   signing only certificates are normally not escrowed, by using DH
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 21]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   based key delivery this is avoided.
-
-   PKINIT does not provide for a "return routability" test to prevent
-   attackers from mounting a denial-of-service attack on the KDC by
-   causing it to perform unnecessary and expensive public-key
-   operations.  Strictly speaking, this is also true of standard
-   Kerberos, although the potential cost is not as great, because
-   standard Kerberos does not make use of public-key cryptography.  By
-   using DH based key delivery and reusing DH keys, the necessary crypto
-   processing cost per request can be minimized.
-
-   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
-   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
-   be used if the KDC itself vouches for the user's certificate.
-
-5.  Acknowledgements
-
-   The following people have made significant contributions to this
-   draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
-   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
-   Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik Jaganathan
-   and Chaskiel M Grundman.
-
-   Special thanks to Clifford Neuman, Matthew Hur and Sasha Medvinsky
-   who wrote earlier versions of this document.
-
-   The authors are indebt to the Kerberos working group chair Jeffrey
-   Hutzelman who kept track of various issues and was enormously helpful
-   during the creation of this document.
-
-   Some of the ideas on which this document is based arose during
-   discussions over several years between members of the SAAG, the IETF
-   CAT working group, and the PSRG, regarding integration of Kerberos
-   and SPX.  Some ideas have also been drawn from the DASS system.
-   These changes are by no means endorsed by these groups.  This is an
-   attempt to revive some of the goals of those groups, and this
-   document approaches those goals primarily from the Kerberos
-   perspective.
-
-   Lastly, comments from groups working on similar ideas in DCE have
-   been invaluable.
-
-6.  IANA Considerations
-
-   This document has no actions for IANA.
-
-
-
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 22]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-7.  References
-
-7.1  Normative References
-
-   [CLAR]     RFC-Editor: To be replaced by RFC number for draft-ietf-
-              krb-wg-kerberos-clarifications.  Work in Progress. 
-
-   [IEEE1363] 
-              IEEE, "Standard Specifications for Public Key 
-              Cryptography", IEEE 1363, 2000.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
-              RFC 2412, November 1998.
-
-   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
-              RFC 2631, June 1999.
-
-   [RFC3279]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
-              Algorithms", RFC 3370, August 2002.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
-              Encryption Algorithm in Cryptographic Message Syntax
-              (CMS)", RFC 3565, July 2003.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 23]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [X.509-97] ITU-T.  Recommendation X.509: The Directory - Authentication 
-              Framework.  1997.
-
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding  
-              Rules (BER), Canonical Encoding Rules (CER) and
-              Distinguished Encoding Rules (DER), ITU-T Recommendation
-              X.690 (1997) | ISO/IEC International Standard
-              8825-1:1998.
-
-7.2  Informative References
-
-   [CAPATH]   RFC-Editor: To be replaced by RFC number for draft-ietf-
-              pkix-certpathbuild.  Work in Progress. 
-
-   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
-              Sizes", Journal of Cryptology 14 (2001) 255-293.
-              
-   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
-              future, Designs, Codes, and Cryptography (1999)". 
-
-Authors' Addresses
-
-   Brian Tung
-   USC Information Sciences Institute
-   4676 Admiralty Way Suite 1001, Marina del Rey CA
-   Marina del Rey, CA  90292
-   US
-
-   Email: brian@isi.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-Appendix A.  PKINIT ASN.1 Module
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 24]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-       KerberosV5-PK-INIT-SPEC {
-               iso(1) identified-organization(3) dod(6) internet(1)
-               security(5) kerberosV5(2) modules(4) pkinit(5)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       IMPORTS
-           SubjectPublicKeyInfo, AlgorithmIdentifier
-               FROM PKIX1Explicit88 { iso (1)
-                 identified-organization (3) dod (6) internet (1)
-                 security (5) mechanisms (5) pkix (7) id-mod (0)
-                 id-pkix1-explicit (18) }
-                 -- As defined in RFC 3280.
-
-           DomainParameters, EcpkParameters
-               FROM PKIX1Algorithms88 { iso(1)
-                 identified-organization(3) dod(6)
-                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-                 id-mod-pkix1-algorithms(17) }
-                 -- As defined in RFC 3279.
-
-           KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) } ;
-
-       id-pkinit OBJECT IDENTIFIER ::=
-         { iso (1) org (3) dod (6) internet (1) security (5)
-           kerberosv5 (2) pkinit (3) }
-
-       id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-       id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-       id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-       id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-       id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-       pa-pk-as-req INTEGER ::=                  16
-       pa-pk-as-rep INTEGER ::=                  17
-
-       ad-initial-verified-cas INTEGER ::=        9
-
-       td-trusted-certifiers INTEGER ::=        104
-       td-invalid-certificates INTEGER ::=      105
-       td-dh-parameters INTEGER ::=             109
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 25]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-                   -- A list of CAs, trusted by the client, that can
-                   -- be used as the trust anchor to validate the KDC's
-                   -- signature.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       TrustedCA ::= SEQUENCE {
-          caName                  [0] IMPLICIT OCTET STRING,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies a CA by the CA's distinguished subject
-                   -- name.
-          certificateSerialNumber [1] INTEGER OPTIONAL,
-                   -- Specifies the CA certificate's serial number.
-                   -- The defintion of the certificate serial number
-                   -- is taken from X.509 [X.509-97].
-          subjectKeyIdentifier    [2] OCTET STRING OPTIONAL,
-                   -- Identifies the CA's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-          ...
-       }
-
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 26]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The public key value (the subjectPublicKey field
-                   -- of the type SubjectPublicKeyInfo) MUST be encoded
-                   -- according to [RFC3279].
-                   -- Present only if the client wishes to use the
-                   -- Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so.
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [CLAR], for replay
-                   -- prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
-                   -- Each OCTET STRING contains a CMS type
-                   -- IssuerAndSerialNumber encoded according to
-                   -- [RFC3852].
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 27]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-                   -- Each IssuerAndSerialNumber indentifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is id-pkrkeydata
-                   -- (1.2.840.113549.1.7.3) and the eContent field
-                   -- contains the DER encoding of the type
-                   -- ReplyKeyPack.
-                   -- ReplyKeyPack is defined below.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 28]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-                   -- present.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- KDC's DH public key.
-                   -- The DH pubic key value is mapped to a BIT STRING
-                   -- according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request if DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if DH keys are reused. If
-                   -- this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP.
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request.
-          ...
-       }
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-       END
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 29]
-
-Internet-Draft                   PKINIT                    February 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Tung & Zhu               Expires August 22, 2005               [Page 30]
-
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-26.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-26.txt
deleted file mode 100644
index 049330260..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-26.txt
+++ /dev/null
@@ -1,1674 +0,0 @@
-NETWORK WORKING GROUP                                            B. Tung
-Internet-Draft                        USC Information Sciences Institute
-Expires: November 24, 2005                                        L. Zhu
-                                                   Microsoft Corporation
-                                                            May 23, 2005
-
-
-     Public Key Cryptography for Initial Authentication in Kerberos
-                    draft-ietf-cat-kerberos-pk-init
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667.  
-   
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-     
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on November 24, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes protocol extensions (hereafter called PKINIT)
-   to the Kerberos protocol specification.  These extensions provide a
-   method for integrating public key cryptography into the initial
-   authentication exchange, by using asymmetric-key signature and/or
-   encryption algorithms in pre-authentication data fields.
-
-
-
-Tung & Zhu              Expires November 24, 2005               [Page 1]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1   Definitions, Requirements, and Constants . . . . . . . . .  4
-       3.1.1   Required Algorithms  . . . . . . . . . . . . . . . . .  4
-       3.1.2   Defined Message and Encryption Types . . . . . . . . .  5
-       3.1.3   Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
-     3.2   PKINIT Pre-authentication Syntax and Use . . . . . . . . .  7
-       3.2.1   Generation of Client Request . . . . . . . . . . . . .  7
-       3.2.2   Receipt of Client Request  . . . . . . . . . . . . . . 10
-       3.2.3   Generation of KDC Reply  . . . . . . . . . . . . . . . 13
-       3.2.4   Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
-     3.3   Interoperability Requirements  . . . . . . . . . . . . . . 20
-     3.4   KDC Indication of PKINIT Support . . . . . . . . . . . . . 20
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
-   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
-     7.1   Normative References . . . . . . . . . . . . . . . . . . . 22
-     7.2   Informative References . . . . . . . . . . . . . . . . . . 24
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
-   A.  PKINIT ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 25
-       Intellectual Property and Copyright Statements . . . . . . . . 30
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu              Expires November 24, 2005               [Page 2]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-1.  Introduction
-
-   A client typically authenticates itself to a service in Kerberos
-   using three distinct though related exchanges.  First, the client
-   requests a ticket-granting ticket (TGT) from the Kerberos
-   authentication server (AS).  Then, it uses the TGT to request a
-   service ticket from the Kerberos ticket-granting server (TGS).
-   Usually, the AS and TGS are integrated in a single device known as a
-   Kerberos Key Distribution Center, or KDC.  Finally, the client uses
-   the service ticket to authenticate itself to the service.
-
-   The advantage afforded by the TGT is that the client exposes his
-   long-term secrets only once.  The TGT and its associated session key
-   can then be used for any subsequent service ticket requests.  One
-   result of this is that all further authentication is independent of
-   the method by which the initial authentication was performed.
-   Consequently, initial authentication provides a convenient place to
-   integrate public-key cryptography into Kerberos authentication.
-
-   As defined in [CLAR], Kerberos authentication exchanges use
-   symmetric-key cryptography, in part for performance.  One
-   disadvantage of using symmetric-key cryptography is that the keys
-   must be shared, so that before a client can authenticate itself, he
-   must already be registered with the KDC.
-
-   Conversely, public-key cryptography (in conjunction with an
-   established Public Key Infrastructure) permits authentication without
-   prior registration with a KDC.  Adding it to Kerberos allows the
-   widespread use of Kerberized applications by clients without
-   requiring them to register first with a KDC--a requirement that has
-   no inherent security benefit.
-
-   As noted above, a convenient and efficient place to introduce public-
-   key cryptography into Kerberos is in the initial authentication
-   exchange.  This document describes the methods and data formats for
-   integrating public-key cryptography into Kerberos initial
-   authentication.
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   Both the AS and the TGS are referred to as the KDC.
-
-   In this document, the encryption key used to encrypt the enc-part
-   field of the KDC-REP in the AS-REP [CLAR] is referred to as the AS
-
-
-
-Tung & Zhu              Expires November 24, 2005               [Page 3]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-   reply key.
-
-3.  Extensions
-
-   This section describes extensions to [CLAR] for supporting the use of
-   public-key cryptography in the initial request for a ticket.
-
-   Briefly, this document defines the following extensions to [CLAR]:
-
-   1. The client indicates the use of public-key authentication by
-      including a special preauthenticator in the initial request.  This
-      preauthenticator contains the client's public-key data and a
-      signature.
-
-   2. The KDC tests the client's request against its authentication
-      policy and trusted Certification Authorities (CAs).
-
-   3. If the request passes the verification tests, the KDC replies as
-      usual, but the reply is encrypted using either:
-
-      a. a key generated through a Diffie-Hellman (DH) key exchange
-         [RFC2631] [IEEE1363] with the client, signed using the KDC's
-         signature key; or
-
-      b. a symmetric encryption key, signed using the KDC's signature
-         key and encrypted using the client's public key.
-
-      Any keying material required by the client to obtain the
-      encryption key for decrypting the KDC reply is returned in a pre-
-      authentication field accompanying the usual reply.
-
-   4. The client validates the KDC's signature, obtains the encryption
-      key, decrypts the reply, and then proceeds as usual.
-
-   Section 3.1 of this document enumerates the required algorithms and
-   necessary extension message types.  Section 3.2 describes the
-   extension messages in greater detail.
-
-3.1  Definitions, Requirements, and Constants
-
-3.1.1  Required Algorithms
-
-   All PKINIT implementations MUST support the following algorithms:
-
-   o  AS reply key enctype: AES256-CTS-HMAC-SHA1-96 etype [RFC3962].
-
-
-
-
-
-
-Tung & Zhu              Expires November 24, 2005               [Page 4]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
-
-   o  AS reply key delivery method: Diffie-Hellman key exchange
-      [RFC2631].
-
-
-3.1.2  Defined Message and Encryption Types
-
-   PKINIT makes use of the following new pre-authentication types:
-
-       PA_PK_AS_REQ                                 16
-       PA_PK_AS_REP                                 17
-
-   PKINIT also makes use of the following new authorization data type:
-
-       AD_INITIAL_VERIFIED_CAS                       9
-
-   PKINIT introduces the following new error codes:
-
-       KDC_ERR_CLIENT_NOT_TRUSTED                   62
-       KDC_ERR_INVALID_SIG                          64
-       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
-       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
-       KDC_ERR_INVALID_CERTIFICATE                  71
-       KDC_ERR_REVOKED_CERTIFICATE                  72
-       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
-       KDC_ERR_CLIENT_NAME_MISMATCH                 75
-       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
-
-   PKINIT uses the following typed data types for errors:
-
-       TD_TRUSTED_CERTIFIERS                       104
-       TD_INVALID_CERTIFICATES                     105
-       TD_DH_PARAMETERS                            109
-
-   PKINIT defines the following encryption types, for use in the AS-REQ
-   message to indicate acceptance of the corresponding algorithms that
-   can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
-   the reply:
-
-       dsaWithSHA1-CmsOID                            9
-       md5WithRSAEncryption-CmsOID                  10
-       sha1WithRSAEncryption-CmsOID                 11
-       rc2CBC-EnvOID                                12
-       rsaEncryption-EnvOID   (PKCS1 v1.5)          13
-       rsaES-OAEP-EnvOID      (PKCS1 v2.0)          14
-       des-ede3-cbc-EnvOID                          15
-
-
-
-
-Tung & Zhu              Expires November 24, 2005               [Page 5]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-   The ASN.1 module for all structures defined in this document (plus
-   IMPORT statements for all imported structures) is given in
-   Appendix A.
-
-   All structures defined in or imported into this document MUST be
-   encoded using Distinguished Encoding Rules (DER) [X690] (unless
-   otherwise noted).  All data structures carried in OCTET STRINGs must
-   be encoded according to the rules specified in corresponding
-   specifications.
-
-   Interoperability note: Some implementations may not be able to decode
-   wrapped CMS objects encoded with BER but not DER; specifically, they
-   may not be able to decode infinite length encodings.  To maximize
-   interoperability, implementers SHOULD encode CMS objects used in
-   PKINIT with DER.
-
-3.1.3  Algorithm Identifiers
-
-   PKINIT does not define, but does make use of, the following algorithm
-   identifiers.
-
-   PKINIT uses the following algorithm identifiers for Diffie-Hellman
-   key agreement [RFC3279]:
-
-       dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
-       id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
-
-   PKINIT uses the following signature algorithm identifiers [RFC3279]:
-
-       sha-1WithRSAEncryption (RSA with SHA1)
-       md5WithRSAEncryption   (RSA with MD5)
-       id-dsa-with-sha1       (DSA with SHA1)
-
-   PKINIT uses the following encryption algorithm identifiers [RFC3447]
-   for encrypting the temporary key with a public key:
-
-       rsaEncryption          (PKCS1 v1.5)
-       id-RSAES-OAEP          (PKCS1 v2.0)
-
-   PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
-   for encrypting the AS reply key with the temporary key:
-
-       des-ede3-cbc           (three-key 3DES, CBC mode)
-       rc2-cbc                (RC2, CBC mode)
-       id-aes256-CBC          (AES-256, CBC mode)
-
-
-
-
-
-
-Tung & Zhu              Expires November 24, 2005               [Page 6]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-3.2  PKINIT Pre-authentication Syntax and Use
-
-   This section defines the syntax and use of the various pre-
-   authentication fields employed by PKINIT.
-
-3.2.1  Generation of Client Request
-
-   The initial authentication request (AS-REQ) is sent as per [CLAR]; in
-   addition, a pre-authentication data element, whose padata-type is
-   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
-   type PA-PK-AS-REQ, is included.
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-                   -- A list of CAs, trusted by the client, that can
-                   -- be used to certify the KDC.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       TrustedCA ::= SEQUENCE {
-          caName                  [0] IMPLICIT OCTET STRING,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-
-
-
-Tung & Zhu              Expires November 24, 2005               [Page 7]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-                   -- Identifies a CA by the CA's distinguished subject
-                   -- name.
-          certificateSerialNumber [1] INTEGER OPTIONAL,
-                   -- Specifies the CA certificate's serial number.
-                   -- The defintion of the certificate serial number
-                   -- is taken from X.509 [X.509-97].
-          subjectKeyIdentifier    [2] OCTET STRING OPTIONAL,
-                   -- Identifies the CA's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING, as specified in Section 2.3.3 of
-                   -- [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so (see Section 3.2.3.1).
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [CLAR], for replay
-
-
-
-Tung & Zhu              Expires November 24, 2005               [Page 8]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-                   -- prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure for the signedAuthPack field is
-   filled out as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is id-pkauthdata:
-       { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-       pkinit(3) pkauthdata(1) }.
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type AuthPack.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type AuthPack.
-
-   5.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the KDC can verify the signature over the
-       type AuthPack.  For path validation, these certificates SHOULD be
-       sufficient to construct at least one certification path from the
-       client certificate to one trust anchor acceptable by the KDC
-       [CAPATH].  The client MUST be capable of including such a set of
-       certificates if configured to do so.  The certificates field MUST
-       NOT contain "root" CA certificates.
-
-   6.  The client's Diffie-Hellman public value (clientPublicValue) is
-       included if and only if the client wishes to use the Diffie-
-       Hellman key agreement method.  The Diffie-Hellman domain
-       parameters [IEEE1363] for the client's public key are specified
-       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
-       and the client's Diffie-Hellman public key value is mapped to a
-       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
-       using the Diffie-Hellman key agreement method, implementations
-       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
-       known group 2 [RFC2412] and SHOULD support Oakley 2048-bit MODP
-       well-known group 14 and Oakley 4096-bit MODP well-known group 16
-
-
-
-Tung & Zhu              Expires November 24, 2005               [Page 9]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-       [RFC3526].
-
-       The Diffie-Hellman field size should be chosen so as to provide
-       sufficient cryptographic security [RFC3766].
-
-       When MODP Diffie-Hellman is used, the exponents should have at
-       least twice as many bits as the symmetric keys that will be
-       derived from them [ODL99].
-
-   7.  The client may wish to reuse DH keys or to allow the KDC to do so
-       (see Section 3.2.3.1).  If so, then the client includes the
-       clientDHNonce field.  This nonce string needs to be as long as
-       the longest key length of the symmetric key types that the client
-       supports.  This nonce MUST be chosen randomly.
-
-
-3.2.2  Receipt of Client Request
-
-   Upon receiving the client's request, the KDC validates it.  This
-   section describes the steps that the KDC MUST (unless otherwise
-   noted) take in validating the request.
-
-   The KDC verifies the client's signature in the signedAuthPack field
-   according to [RFC3852].
-
-   If, while validating the client's X.509 certificate [RFC3280], the
-   KDC cannot build a certification path to validate the client's
-   certificate, it sends back a KRB-ERROR [CLAR] message with the code
-   KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for this
-   error message is a TYPED-DATA (as defined in [CLAR]) that contains an
-   element whose data-type is TD_TRUSTED_CERTIFIERS, and whose data-
-   value contains the DER encoding of the type TD-TRUSTED-CERTIFIERS:
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-
-   Upon receiving this error message, the client SHOULD retry only if it
-   has a different set of certificates (from those of the previous
-   requests) that form a certification path (or a partial path) from one
-   of the trust anchors acceptable by the KDC to its own certificate.
-
-   If, while processing the certification path, the KDC determines that
-   the signature on one of the certificates in the signedAuthPack field
-   is invalid, it returns a KRB-ERROR [CLAR] message with the code
-   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
-   message is a TYPED-DATA that contains an element whose data-type is
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 10]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
-   encoding of the type TD-INVALID-CERTIFICATES:
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
-                   -- Each OCTET STRING contains a CMS type
-                   -- IssuerAndSerialNumber encoded according to
-                   -- [RFC3852].
-                   -- Each IssuerAndSerialNumber identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-   If more than one X.509 certificate signature is invalid, the KDC MAY
-   include one IssuerAndSerialNumber per invalid signature within the
-   TD-INVALID-CERTIFICATES.
-
-   The client's X.509 certificate is validated according to [RFC3280].
-
-   Based on local policy, the KDC may also check whether any X.509
-   certificates in the certification path validating the client's
-   certificate have been revoked.  If any of them have been revoked, the
-   KDC MUST return an error message with the code
-   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
-   revocation status but is unable to do so, it SHOULD return an error
-   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
-   certificate or certificates affected are identified exactly as for
-   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
-
-   Note that the TD_INVALID_CERTIFICATES error data is only used to
-   identify invalid certificates sent by the client in the request.
-
-   The client's public key is then used to verify the signature.  If the
-   signature fails to verify, the KDC MUST return an error message with
-   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
-   this error message.
-
-   In addition to validating the client's signature, the KDC MUST also
-   check that the client's public key used to verify the client's
-   signature is bound to the client's principal name as specified in the
-   AS-REQ as follows:
-
-   1. If the KDC has its own binding between either the client's
-      signature-verification public key or the client's certificate and
-      the client's Kerberos principal name, it uses that binding.
-
-
-
-
-
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 11]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-   2. Otherwise, if the client's X.509 certificate contains a Subject
-      Alternative Name (SAN) extension carrying a KRB5PrincipalName
-      (defined below) in the otherName field of the type GeneralName
-      [RFC3280], it binds the client's X.509 certificate to that name.
-
-      The type of the otherName field is AnotherName.  The type-id field
-      of the type AnotherName is id-pksan:
-
-       id-pksan OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509-sanan (2) }
-
-      And the value field of the type AnotherName is a
-      KRB5PrincipalName.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-   If the KDC does not have its own binding and there is no
-   KRB5PrincipalName name present in the client's X.509 certificate, or
-   if the Kerberos name in the request does not match the
-   KRB5PrincipalName in the client's X.509 certificate (including the
-   realm name), the KDC MUST return an error message with the code
-   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
-   this error message.
-
-   The KDC MAY require the presence of an Extended Key Usage (EKU)
-   KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
-   client's X.509 certificate:
-
-       id-pkekuoid OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) pkekuoid(4) }
-              -- PKINIT client authentication.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   If this EKU KeyPurposeId is required but it is not present or if the
-   client certificate is restricted not to be used for PKINIT client
-   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
-   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
-   is no accompanying e-data for this error message.  KDCs implementing
-   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-
-   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
-   are a large number of X.509 client certificates deployed for use with
-   PKINIT which have this EKU.
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 12]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-   If for any other reasons, the client's public key is not accepted,
-   the KDC MUST return an error message with the code
-   KDC_ERR_CLIENT_NOT_TRUSTED.
-
-   The KDC MUST check the timestamp to ensure that the request is not a
-   replay, and that the time skew falls within acceptable limits.  The
-   recommendations for clock skew times in [CLAR] apply here.  If the
-   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
-   KRB_AP_ERR_SKEW, respectively.
-
-   If the clientPublicValue is filled in, indicating that the client
-   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
-   check to see if the key parameters satisfy its policy.  If they do
-   not, it MUST return an error message with the code
-   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
-   TYPED-DATA that contains an element whose data-type is
-   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
-   the type TD-DH-PARAMETERS:
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-
-   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
-   that the KDC supports in decreasing preference order, from which the
-   client SHOULD pick one to retry the request.
-
-   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
-   KDC does not possess the corresponding key, the KDC MUST ignore the
-   kdcPkId field as if the client did not include one.
-
-   If there is a supportedCMSTypes field in the AuthPack, the KDC must
-   check to see if it supports any of the listed types.  If it supports
-   more than one of the types, the KDC SHOULD use the one listed first.
-   If it does not support any of them, it MUST return an error message
-   with the code KDC_ERR_ETYPE_NOSUPP [CLAR].
-
-3.2.3  Generation of KDC Reply
-
-   Assuming that the client's request has been properly validated, the
-   KDC proceeds as per [CLAR], except as follows.
-
-   The KDC MUST set the initial flag and include an authorization data
-   element of ad-type [CLAR] AD_INITIAL_VERIFIED_CAS in the issued
-   ticket.  The ad-data [CLAR] field contains the DER encoding of the
-   type AD-INITIAL-VERIFIED-CAS:
-
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 13]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-
-   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-   containers if the list of CAs satisfies the AS' realm's local policy
-   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
-   [CLAR]).  Furthermore, any TGS MUST copy such authorization data from
-   tickets used within a PA-TGS-REQ of the TGS-REQ into the resulting
-   ticket.  If the list of CAs satisfies the local KDC's realm's policy,
-   the TGS MAY wrap the data into the AD-IF-RELEVANT container,
-   otherwise it MAY unwrap the authorization data out of the AD-IF-
-   RELEVANT container.
-
-   Application servers that understand this authorization data type
-   SHOULD apply local policy to determine whether a given ticket bearing
-   such a type *not* contained within an AD-IF-RELEVANT container is
-   acceptable.  (This corresponds to the AP server checking the
-   transited field when the TRANSITED-POLICY-CHECKED flag has not been
-   set [CLAR].)  If such a data type is contained within an AD-IF-
-   RELEVANT container, AP servers MAY apply local policy to determine
-   whether the authorization data is acceptable.
-
-   The content of the AS-REP is otherwise unchanged from [CLAR].  The
-   KDC encrypts the reply as usual, but not with the client's long-term
-   key.  Instead, it encrypts it with either a shared key derived from a
-   Diffie-Hellman exchange, or a generated encryption key.  The contents
-   of the PA-PK-AS-REP indicate which key delivery method is used:
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is id-pkrkeydata
-                   -- (1.2.840.113549.1.7.3) and the eContent field
-                   -- contains the DER encoding of the type
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 14]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-                   -- ReplyKeyPack.
-                   -- ReplyKeyPack is defined in Section 3.2.3.2.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-                   -- present in the KDCDHKeyInfo.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING, as specified in Section 2.3.3 of
-                   -- [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request if DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if DH keys are reused. If
-                   -- this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted. See Section 3.2.3.1.
-          ...
-       }
-
-
-3.2.3.1  Using Diffie-Hellman Key Exchange
-
-   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
-
-   The ContentInfo [RFC3852] structure for the dhSignedData field is
-   filled in as follows:
-
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 15]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is the OID value
-       for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
-       security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type KDCDHKeyInfo.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type
-       KDCDHKeyInfo.
-
-   5.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type KDCDHKeyInfo.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may only. be left empty if
-       the KDC public key specified by the kdcPkId field in the PA-PK-
-       AS-REQ was used for signing.  Otherwise, for path validation,
-       these certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [CAPATH].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   6.  If the client included the clientDHNonce field, then the KDC may
-       choose to reuse its DH keys (see Section 3.2.3.1).  If the server
-       reuses DH keys then it MUST include an expiration time in the
-       dhKeyExpiration field.  Past the point of the expiration time,
-       the signature over the type DHRepInfo is considered expired/
-       invalid.  When the server reuses DH keys then it MUST include a
-       serverDHNonce at least as long as the length of keys for the
-       symmetric encryption system used to encrypt the AS reply.  Note
-       that including the serverDHNonce changes how the client and
-       server calculate the key to use to encrypt the reply; see below
-       for details.  The KDC SHOULD NOT reuse DH keys unless the
-       clientDHNonce field is present in the request.
-
-   The AS reply key is derived as follows:
-
-
-
-
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 16]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-   1. Both the KDC and the client calculate the shared secret value as
-      follows:
-
-      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
-         shared secret value.  DHSharedSecret is the value ZZ as
-         described in Section 2.1.1 of [RFC2631].
-
-      b) When Elliptic Curve Diffie-Hellman (ECDH) (with each party
-         contributing one key pair) is used, let DHSharedSecret be the
-         x-coordinate of the shared secret value (an elliptic curve
-         point).  DHSharedSecret is the output of operation ECSVDP-DH as
-         described in Section 7.2.1 of [IEEE1363].
-
-      DHSharedSecret is first padded with leading zeros such that the
-      size of DHSharedSecret in octets is the same as that of the
-      modulus, then represented as a string of octets in big-endian
-      order.
-
-      Implementation note: Both the client and the KDC can cache the
-      triple (ya, yb, DHSharedSecret), where ya is the client's public
-      key and yb is the KDC's public key.  If both ya and yb are the
-      same in a later exchange, the cached DHSharedSecret can be used.
-
-   2. Let K be the key-generation seed length [RFC3961] of the AS reply
-      key whose enctype is selected according to [CLAR].
-
-   3. Define the function octetstring2key() as follows:
-
-           octetstring2key(x) == random-to-key(K-truncate(
-                                    SHA1(0x00 | x) |
-                                    SHA1(0x01 | x) |
-                                    SHA1(0x02 | x) |
-                                    ...
-                                    ))
-
-      where x is an octet string; | is the concatenation operator; 0x00,
-      0x01, 0x02, etc., are each represented as a single octet; random-
-      to-key() is an operation that generates a protocol key from a
-      bitstring of length K; and K-truncate truncates its input to the
-      first K bits.  Both K and random-to-key() are as defined in the
-      kcrypto profile [RFC3961] for the enctype of the AS reply key.
-
-   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
-      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
-      strings.
-
-
-
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 17]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-   5. The AS reply key k is:
-
-           k = octetstring2key(DHSharedSecret | n_c | n_k)
-
-
-3.2.3.2  Using Public Key Encryption
-
-   In this case, the PA-PK-AS-REP contains a ContentInfo structure
-   wrapped in an OCTET STRING.  The AS reply key is encrypted in the
-   encKeyPack field, which contains data of type ReplyKeyPack:
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP.
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure for the encKeyPack field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-envelopedData
-       (as defined in [RFC3852]), and the content field is an
-       EnvelopedData (as defined in [RFC3852]).
-
-   2.  The contentType field for the type EnvelopedData is id-
-       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
-       pkcs (1) pkcs7 (7) signedData (2) }.
-
-   3.  The eContentType field for the inner type SignedData (when
-       decrypted from the encryptedContent field for the type
-       EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
-       internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
-
-   4.  The eContent field for the inner type SignedData contains the DER
-       encoding of the type ReplyKeyPack.
-
-   5.  The signerInfos field of the inner type SignedData contains a
-       single signerInfo, which contains the signature over the type
-       ReplyKeyPack.
-
-   6.  The certificates field of the inner type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type ReplyKeyPack.  The information contained in the
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 18]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may only be left empty if
-       the KDC public key specified by the kdcPkId field in the PA-PK-
-       AS-REQ was used for signing.  Otherwise, for path validation,
-       these certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [CAPATH].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  The recipientInfos field of the type EnvelopedData is a SET which
-       MUST contain exactly one member of type KeyTransRecipientInfo.
-       The encryptedKey of this member contains the temporary key which
-       is encrypted using the client's public key.
-
-   8.  The unprotectedAttrs or originatorInfo fields of the type
-       EnvelopedData MAY be present.
-
-3.2.4  Receipt of KDC Reply
-
-   Upon receipt of the KDC's reply, the client proceeds as follows.  If
-   the PA-PK-AS-REP contains the dhSignedData field, the client derives
-   the AS reply key using the same procedure used by the KDC as defined
-   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
-   field, and the client decrypts and extracts the temporary key in the
-   encryptedKey field of the member KeyTransRecipientInfo, and then uses
-   that as the AS reply key.
-
-   In either case, the client MUST verify the signature in the
-   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
-   be validated according to [RFC3280].  In addition, unless the client
-   can otherwise verify that the public key used to verify the KDC's
-   signature is bound to the KDC of the target realm, the KDC's X.509
-   certificate MUST contain a Subject Alternative Name extension
-   [RFC3280] carrying an AnotherName whose type-id is id-pksan (as
-   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
-   matches the name of the TGS of the target realm (as defined in
-   Section 7.3 of [CLAR]).
-
-   Based on local policy, the client MAY require that the KDC
-   certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
-
-       id-pkkdcekuoid OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) pkkdcekuoid(5) }
-              -- Signing KDC responses.
-              -- Key usage bits that MUST be consistent:
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 19]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-              -- digitalSignature.
-
-   If all applicable checks are satisfied, the client then decrypts the
-   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
-   and then proceeds as described in [CLAR].
-
-   Implementation note: CAs issuing KDC certificates SHOULD place all
-   "short" and "fully-qualified" Kerberos realm names of the KDC (one
-   per GeneralName [RFC3280]) into the KDC certificate to allow maximum
-   flexibility.
-
-3.3  Interoperability Requirements
-
-   The client MUST be capable of sending a set of certificates
-   sufficient to allow the KDC to construct a certification path for the
-   client's certificate, if the correct set of certificates is provided
-   through configuration or policy.
-
-   If the client sends all the X.509 certificates on a certification
-   path to a trust anchor acceptable by the KDC, and the KDC can not
-   verify the client's public key otherwise, the KDC MUST be able to
-   process path validation for the client's certificate based on the
-   certificates in the request.
-
-   The KDC MUST be capable of sending a set of certificates sufficient
-   to allow the client to construct a certification path for the KDC's
-   certificate, if the correct set of certificates is provided through
-   configuration or policy.
-
-   If the KDC sends all the X.509 certificates on a certification path
-   to a trust anchor acceptable by the client, and the client can not
-   verify the KDC's public key otherwise, the client MUST be able to
-   process path validation for the KDC's certificate based on the
-   certificates in the reply.
-
-3.4  KDC Indication of PKINIT Support
-
-   If pre-authentication is required, but was not present in the
-   request, per [CLAR] an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
-   stored in the e-data field of the KRB-ERROR message to specify which
-   pre-authentication mechanisms are acceptable.  The KDC can then
-   indicate the support of PKINIT by including an empty element whose
-   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
-
-   Otherwise if it is required by the KDC's local policy that the client
-   must be pre-authenticated using the pre-authentication mechanism
-   specified in this document, but no PKINIT pre-authentication was
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 20]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-   present in the request, an error message with the code
-   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
-
-   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
-   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
-   STRING), and clients MUST ignore this and any other value.  Future
-   extensions to this protocol may specify other data to send instead of
-   an empty OCTET STRING.
-
-4.  Security Considerations
-
-   PKINIT raises certain security considerations beyond those that can
-   be regulated strictly in protocol definitions.  We will address them
-   in this section.
-
-   PKINIT extends the cross-realm model to the public-key
-   infrastructure.  Users of PKINIT must understand security policies
-   and procedures appropriate to the use of Public Key Infrastructures
-   [RFC3280].
-
-   Standard Kerberos allows the possibility of interactions between
-   cryptosystems of varying strengths; this document adds interactions
-   with public-key cryptosystems to Kerberos.  Some administrative
-   policies may allow the use of relatively weak public keys.  Using
-   such keys to wrap data encrypted under stronger conventional
-   cryptosystems may be inappropriate.
-
-   PKINIT requires keys for symmetric cryptosystems to be generated.
-   Some such systems contain "weak" keys.  For recommendations regarding
-   these weak keys, see [CLAR].
-
-   PKINIT allows the use of the same RSA key pair for encryption and
-   signing when doing RSA encryption based key delivery.  This is not
-   recommended usage of RSA keys [RFC3447], by using DH based key
-   delivery this is avoided.
-
-   Care should be taken in how certificates are chosen for the purposes
-   of authentication using PKINIT.  Some local policies may require that
-   key escrow be used for certain certificate types.  Deployers of
-   PKINIT should be aware of the implications of using certificates that
-   have escrowed keys for the purposes of authentication.  Because
-   signing only certificates are normally not escrowed, by using DH
-   based key delivery this is avoided.
-
-   PKINIT does not provide for a "return routability" test to prevent
-   attackers from mounting a denial-of-service attack on the KDC by
-   causing it to perform unnecessary and expensive public-key
-   operations.  Strictly speaking, this is also true of standard
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 21]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-   Kerberos, although the potential cost is not as great, because
-   standard Kerberos does not make use of public-key cryptography.  By
-   using DH based key delivery and reusing DH keys, the necessary crypto
-   processing cost per request can be minimized.
-
-   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
-   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
-   be used if the KDC itself vouches for the user's certificate.
-
-5.  Acknowledgements
-
-   The following people have made significant contributions to this
-   draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
-   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
-   Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
-   Jaganathan, Chaskiel M Grundman and Stefan Santesson.
-
-   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
-   Jonathan Trostle who wrote earlier versions of this document.
-
-   The authors are indebted to the Kerberos working group chair Jeffrey
-   Hutzelman who kept track of various issues and was enormously helpful
-   during the creation of this document.
-
-   Some of the ideas on which this document is based arose during
-   discussions over several years between members of the SAAG, the IETF
-   CAT working group, and the PSRG, regarding integration of Kerberos
-   and SPX.  Some ideas have also been drawn from the DASS system.
-   These changes are by no means endorsed by these groups.  This is an
-   attempt to revive some of the goals of those groups, and this
-   document approaches those goals primarily from the Kerberos
-   perspective.
-
-   Lastly, comments from groups working on similar ideas in DCE have
-   been invaluable.
-
-6.  IANA Considerations
-
-   This document has no actions for IANA.
-
-7.  References
-
-7.1  Normative References
-
-   [CLAR]     RFC-Editor: To be replaced by RFC number for draft-ietf-
-              krb-wg-kerberos-clarifications.  Work in Progress. 
-
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 22]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-   [IEEE1363] 
-              IEEE, "Standard Specifications for Public Key 
-              Cryptography", IEEE 1363, 2000.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
-              RFC 2412, November 1998.
-
-   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
-              RFC 2631, June 1999.
-
-   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
-              Algorithms", RFC 3370, August 2002.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
-              Encryption Algorithm in Cryptographic Message Syntax
-              (CMS)", RFC 3565, July 2003.
-
-   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
-              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
-              RFC 3766, April 2004.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 23]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
-              Encryption for Kerberos 5", RFC 3962, February 2005.
-
-   [X.509-97] ITU-T.  Recommendation X.509: The Directory - Authentication 
-              Framework.  1997.
-
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding  
-              Rules (BER), Canonical Encoding Rules (CER) and
-              Distinguished Encoding Rules (DER), ITU-T Recommendation
-              X.690 (1997) | ISO/IEC International Standard
-              8825-1:1998.
-
-7.2  Informative References
-
-   [CAPATH]   RFC-Editor: To be replaced by RFC number for draft-ietf-
-              pkix-certpathbuild.  Work in Progress. 
-
-   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
-              Sizes", Journal of Cryptology 14 (2001) 255-293.
-
-   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
-              future, Designs, Codes, and Cryptography (1999)". 
-
-
-Authors' Addresses
-
-   Brian Tung
-   USC Information Sciences Institute
-   4676 Admiralty Way Suite 1001, Marina del Rey CA
-   Marina del Rey, CA  90292
-   US
-
-   Email: brian@isi.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-Appendix A.  PKINIT ASN.1 Module
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 24]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-       KerberosV5-PK-INIT-SPEC {
-               iso(1) identified-organization(3) dod(6) internet(1)
-               security(5) kerberosV5(2) modules(4) pkinit(5)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       IMPORTS
-           SubjectPublicKeyInfo, AlgorithmIdentifier
-               FROM PKIX1Explicit88 { iso (1)
-                 identified-organization (3) dod (6) internet (1)
-                 security (5) mechanisms (5) pkix (7) id-mod (0)
-                 id-pkix1-explicit (18) }
-                 -- As defined in RFC 3280.
-
-           DomainParameters, EcpkParameters
-               FROM PKIX1Algorithms88 { iso(1)
-                 identified-organization(3) dod(6)
-                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-                 id-mod-pkix1-algorithms(17) }
-                 -- As defined in RFC 3279.
-
-           KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) } ;
-
-       id-pkinit OBJECT IDENTIFIER ::=
-         { iso (1) org (3) dod (6) internet (1) security (5)
-           kerberosv5 (2) pkinit (3) }
-
-       id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-       id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-       id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-       id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-       id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-       pa-pk-as-req INTEGER ::=                  16
-       pa-pk-as-rep INTEGER ::=                  17
-
-       ad-initial-verified-cas INTEGER ::=        9
-
-       td-trusted-certifiers INTEGER ::=        104
-       td-invalid-certificates INTEGER ::=      105
-       td-dh-parameters INTEGER ::=             109
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 25]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
-                   -- A list of CAs, trusted by the client, that can
-                   -- be used to certify the KDC.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       TrustedCA ::= SEQUENCE {
-          caName                  [0] IMPLICIT OCTET STRING,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies a CA by the CA's distinguished subject
-                   -- name.
-          certificateSerialNumber [1] INTEGER OPTIONAL,
-                   -- Specifies the CA certificate's serial number.
-                   -- The defintion of the certificate serial number
-                   -- is taken from X.509 [X.509-97].
-          subjectKeyIdentifier    [2] OCTET STRING OPTIONAL,
-                   -- Identifies the CA's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 26]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-          ...
-       }
-
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING, as specified in Section 2.3.3 of
-                   -- [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so.
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [CLAR], for replay
-                   -- prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF TrustedCA
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 27]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF OCTET STRING
-                   -- Each OCTET STRING contains a CMS type
-                   -- IssuerAndSerialNumber encoded according to
-                   -- [RFC3852].
-                   -- Each IssuerAndSerialNumber identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF TrustedCA
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each TrustedCA identifies a CA or a CA
-                   -- certificate (thereby its public key).
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is id-pkrkeydata
-                   -- (1.2.840.113549.1.7.3) and the eContent field
-                   -- contains the DER encoding of the type
-                   -- ReplyKeyPack.
-                   -- ReplyKeyPack is defined below.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 28]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-                   -- present.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING, as specified in Section 2.3.3 of
-                   -- [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request if DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if DH keys are reused. If
-                   -- this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP.
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request.
-          ...
-       }
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-       END
-
-
-
-
-
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 29]
-
-Internet-Draft                   PKINIT                         May 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Tung & Zhu              Expires November 24, 2005              [Page 30]
-
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-27.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-27.txt
deleted file mode 100644
index ab4aeb58c..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-27.txt
+++ /dev/null
@@ -1,1730 +0,0 @@
-NETWORK WORKING GROUP                                            B. Tung
-Internet-Draft                        USC Information Sciences Institute
-Expires: January 20, 2006                                         L. Zhu
-                                                   Microsoft Corporation
-                                                           July 19, 2005
-
-
-     Public Key Cryptography for Initial Authentication in Kerberos
-                   draft-ietf-cat-kerberos-pk-init-27
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 20, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes protocol extensions (hereafter called PKINIT)
-   to the Kerberos protocol specification.  These extensions provide a
-   method for integrating public key cryptography into the initial
-   authentication exchange, by using asymmetric-key signature and/or
-   encryption algorithms in pre-authentication data fields.
-
-
-
-
-
-Tung & Zhu              Expires January 20, 2006                [Page 1]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1   Definitions, Requirements, and Constants . . . . . . . . .  4
-       3.1.1   Required Algorithms  . . . . . . . . . . . . . . . . .  4
-       3.1.2   Defined Message and Encryption Types . . . . . . . . .  5
-       3.1.3   Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
-     3.2   PKINIT Pre-authentication Syntax and Use . . . . . . . . .  7
-       3.2.1   Generation of Client Request . . . . . . . . . . . . .  7
-       3.2.2   Receipt of Client Request  . . . . . . . . . . . . . . 10
-       3.2.3   Generation of KDC Reply  . . . . . . . . . . . . . . . 14
-       3.2.4   Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
-     3.3   Interoperability Requirements  . . . . . . . . . . . . . . 20
-     3.4   KDC Indication of PKINIT Support . . . . . . . . . . . . . 21
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
-   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
-     7.1   Normative References . . . . . . . . . . . . . . . . . . . 23
-     7.2   Informative References . . . . . . . . . . . . . . . . . . 24
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
-   A.  PKINIT ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 25
-       Intellectual Property and Copyright Statements . . . . . . . . 31
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu              Expires January 20, 2006                [Page 2]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-1.  Introduction
-
-   A client typically authenticates itself to a service in Kerberos
-   using three distinct though related exchanges.  First, the client
-   requests a ticket-granting ticket (TGT) from the Kerberos
-   authentication server (AS).  Then, it uses the TGT to request a
-   service ticket from the Kerberos ticket-granting server (TGS).
-   Usually, the AS and TGS are integrated in a single device known as a
-   Kerberos Key Distribution Center, or KDC.  Finally, the client uses
-   the service ticket to authenticate itself to the service.
-
-   The advantage afforded by the TGT is that the client exposes his
-   long-term secrets only once.  The TGT and its associated session key
-   can then be used for any subsequent service ticket requests.  One
-   result of this is that all further authentication is independent of
-   the method by which the initial authentication was performed.
-   Consequently, initial authentication provides a convenient place to
-   integrate public-key cryptography into Kerberos authentication.
-
-   As defined in [RFC4120], Kerberos authentication exchanges use
-   symmetric-key cryptography, in part for performance.  One
-   disadvantage of using symmetric-key cryptography is that the keys
-   must be shared, so that before a client can authenticate itself, he
-   must already be registered with the KDC.
-
-   Conversely, public-key cryptography (in conjunction with an
-   established Public Key Infrastructure) permits authentication without
-   prior registration with a KDC.  Adding it to Kerberos allows the
-   widespread use of Kerberized applications by clients without
-   requiring them to register first with a KDC--a requirement that has
-   no inherent security benefit.
-
-   As noted above, a convenient and efficient place to introduce public-
-   key cryptography into Kerberos is in the initial authentication
-   exchange.  This document describes the methods and data formats for
-   integrating public-key cryptography into Kerberos initial
-   authentication.
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   Both the AS and the TGS are referred to as the KDC.
-
-   In this document, the encryption key used to encrypt the enc-part
-   field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
-
-
-
-Tung & Zhu              Expires January 20, 2006                [Page 3]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-   reply key.
-
-3.  Extensions
-
-   This section describes extensions to [RFC4120] for supporting the use
-   of public-key cryptography in the initial request for a ticket.
-
-   Briefly, this document defines the following extensions to [RFC4120]:
-
-   1. The client indicates the use of public-key authentication by
-      including a special preauthenticator in the initial request.  This
-      preauthenticator contains the client's public-key data and a
-      signature.
-
-   2. The KDC tests the client's request against its authentication
-      policy and trusted Certification Authorities (CAs).
-
-   3. If the request passes the verification tests, the KDC replies as
-      usual, but the reply is encrypted using either:
-
-      a. a key generated through a Diffie-Hellman (DH) key exchange
-         [RFC2631] [IEEE1363] with the client, signed using the KDC's
-         signature key; or
-
-      b. a symmetric encryption key, signed using the KDC's signature
-         key and encrypted using the client's public key.
-
-      Any keying material required by the client to obtain the
-      encryption key for decrypting the KDC reply is returned in a pre-
-      authentication field accompanying the usual reply.
-
-   4. The client validates the KDC's signature, obtains the encryption
-      key, decrypts the reply, and then proceeds as usual.
-
-   Section 3.1 of this document enumerates the required algorithms and
-   necessary extension message types.  Section 3.2 describes the
-   extension messages in greater detail.
-
-3.1  Definitions, Requirements, and Constants
-
-3.1.1  Required Algorithms
-
-   All PKINIT implementations MUST support the following algorithms:
-
-   o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
-      sha1-96 [RFC3962].
-
-
-
-
-
-Tung & Zhu              Expires January 20, 2006                [Page 4]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
-
-   o  AS reply key delivery method: Diffie-Hellman key exchange
-      [RFC2631].
-
-
-3.1.2  Defined Message and Encryption Types
-
-   PKINIT makes use of the following new pre-authentication types:
-
-       PA_PK_AS_REQ                                 16
-       PA_PK_AS_REP                                 17
-
-   PKINIT also makes use of the following new authorization data type:
-
-       AD_INITIAL_VERIFIED_CAS                       9
-
-   PKINIT introduces the following new error codes:
-
-       KDC_ERR_CLIENT_NOT_TRUSTED                   62
-       KDC_ERR_INVALID_SIG                          64
-       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
-       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
-       KDC_ERR_INVALID_CERTIFICATE                  71
-       KDC_ERR_REVOKED_CERTIFICATE                  72
-       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
-       KDC_ERR_CLIENT_NAME_MISMATCH                 75
-       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
-
-   PKINIT uses the following typed data types for errors:
-
-       TD_TRUSTED_CERTIFIERS                       104
-       TD_INVALID_CERTIFICATES                     105
-       TD_DH_PARAMETERS                            109
-
-   PKINIT defines the following encryption types, for use in the AS-REQ
-   message to indicate acceptance of the corresponding algorithms that
-   can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
-   the reply:
-
-       dsaWithSHA1-CmsOID                            9
-       md5WithRSAEncryption-CmsOID                  10
-       sha1WithRSAEncryption-CmsOID                 11
-       rc2CBC-EnvOID                                12
-       rsaEncryption-EnvOID   (PKCS1 v1.5)          13
-       rsaES-OAEP-EnvOID      (PKCS1 v2.0)          14
-       des-ede3-cbc-EnvOID                          15
-
-
-
-
-Tung & Zhu              Expires January 20, 2006                [Page 5]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-   The ASN.1 module for all structures defined in this document (plus
-   IMPORT statements for all imported structures) is given in
-   Appendix A.
-
-   All structures defined in or imported into this document MUST be
-   encoded using Distinguished Encoding Rules (DER) [X690] (unless
-   otherwise noted).  All data structures carried in OCTET STRINGs must
-   be encoded according to the rules specified in corresponding
-   specifications.
-
-   Interoperability note: Some implementations may not be able to decode
-   wrapped CMS objects encoded with BER but not DER; specifically, they
-   may not be able to decode infinite length encodings.  To maximize
-   interoperability, implementers SHOULD encode CMS objects used in
-   PKINIT with DER.
-
-3.1.3  Algorithm Identifiers
-
-   PKINIT does not define, but does make use of, the following algorithm
-   identifiers.
-
-   PKINIT uses the following algorithm identifier(s) for Diffie-Hellman
-   key agreement [RFC3279]:
-
-       dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
-
-   PKINIT uses the following signature algorithm identifiers [RFC3279]:
-
-       sha-1WithRSAEncryption (RSA with SHA1)
-       md5WithRSAEncryption   (RSA with MD5)
-       id-dsa-with-sha1       (DSA with SHA1)
-
-   PKINIT uses the following encryption algorithm identifiers [RFC3447]
-   for encrypting the temporary key with a public key:
-
-       rsaEncryption          (PKCS1 v1.5)
-       id-RSAES-OAEP          (PKCS1 v2.0)
-
-   PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
-   for encrypting the AS reply key with the temporary key:
-
-       des-ede3-cbc           (three-key 3DES, CBC mode)
-       rc2-cbc                (RC2, CBC mode)
-       id-aes256-CBC          (AES-256, CBC mode)
-
-
-
-
-
-
-
-Tung & Zhu              Expires January 20, 2006                [Page 6]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-3.2  PKINIT Pre-authentication Syntax and Use
-
-   This section defines the syntax and use of the various pre-
-   authentication fields employed by PKINIT.
-
-3.2.1  Generation of Client Request
-
-   The initial authentication request (AS-REQ) is sent as per [RFC4120];
-   in addition, a pre-authentication data element, whose padata-type is
-   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
-   type PA-PK-AS-REQ, is included.
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- A list of CAs, trusted by the client, that can
-                   -- be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-
-
-
-Tung & Zhu              Expires January 20, 2006                [Page 7]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING, as specified in Section 2.3.3 of
-                   -- [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so (see Section 3.2.3.1).
-          ...
-
-
-
-Tung & Zhu              Expires January 20, 2006                [Page 8]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure for the signedAuthPack field is
-   filled out as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is id-pkauthdata:
-       { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-       pkinit(3) pkauthdata(1) }.
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type AuthPack.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type AuthPack.
-
-   5.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the KDC can verify the signature over the
-       type AuthPack.  For path validation, these certificates SHOULD be
-       sufficient to construct at least one certification path from the
-       client certificate to one trust anchor acceptable by the KDC
-       [CAPATH].  The client MUST be capable of including such a set of
-       certificates if configured to do so.  The certificates field MUST
-       NOT contain "root" CA certificates.
-
-   6.  The client's Diffie-Hellman public value (clientPublicValue) is
-       included if and only if the client wishes to use the Diffie-
-       Hellman key agreement method.  The Diffie-Hellman domain
-       parameters [IEEE1363] for the client's public key are specified
-       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
-
-
-
-Tung & Zhu              Expires January 20, 2006                [Page 9]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-       and the client's Diffie-Hellman public key value is mapped to a
-       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
-       using the Diffie-Hellman key agreement method, implementations
-       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
-       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
-       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
-       group 16 [RFC3526].
-
-       The Diffie-Hellman field size should be chosen so as to provide
-       sufficient cryptographic security [RFC3766].
-
-       When MODP Diffie-Hellman is used, the exponents should have at
-       least twice as many bits as the symmetric keys that will be
-       derived from them [ODL99].
-
-   7.  The client may wish to reuse DH keys or to allow the KDC to do so
-       (see Section 3.2.3.1).  If so, then the client includes the
-       clientDHNonce field.  This nonce string needs to be as long as
-       the longest key length of the symmetric key types that the client
-       supports.  This nonce MUST be chosen randomly.
-
-
-3.2.2  Receipt of Client Request
-
-   Upon receiving the client's request, the KDC validates it.  This
-   section describes the steps that the KDC MUST (unless otherwise
-   noted) take in validating the request.
-
-   The KDC verifies the client's signature in the signedAuthPack field
-   according to [RFC3852].
-
-   If, while validating the client's X.509 certificate [RFC3280], the
-   KDC cannot build a certification path to validate the client's
-   certificate, it sends back a KRB-ERROR [RFC4120] message with the
-   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
-   this error message is a TYPED-DATA (as defined in [RFC4120]) that
-   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
-   whose data-value contains the DER encoding of the type TD-TRUSTED-
-   CERTIFIERS:
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   Upon receiving this error message, the client SHOULD retry only if it
-   has a different set of certificates (from those of the previous
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 10]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-   requests) that form a certification path (or a partial path) from one
-   of the trust anchors acceptable by the KDC to its own certificate.
-
-   If, while processing the certification path, the KDC determines that
-   the signature on one of the certificates in the signedAuthPack field
-   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
-   message is a TYPED-DATA that contains an element whose data-type is
-   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
-   encoding of the type TD-INVALID-CERTIFICATES:
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-   If more than one X.509 certificate signature is invalid, the KDC MAY
-   include one IssuerAndSerialNumber per invalid signature within the
-   TD-INVALID-CERTIFICATES.
-
-   The client's X.509 certificate is validated according to [RFC3280].
-
-   Based on local policy, the KDC may also check whether any X.509
-   certificates in the certification path validating the client's
-   certificate have been revoked.  If any of them have been revoked, the
-   KDC MUST return an error message with the code
-   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
-   revocation status but is unable to do so, it SHOULD return an error
-   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
-   certificate or certificates affected are identified exactly as for
-   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
-
-   Note that the TD_INVALID_CERTIFICATES error data is only used to
-   identify invalid certificates sent by the client in the request.
-
-   The client's public key is then used to verify the signature.  If the
-   signature fails to verify, the KDC MUST return an error message with
-   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
-   this error message.
-
-   In addition to validating the client's signature, the KDC MUST also
-   check that the client's public key used to verify the client's
-   signature is bound to the client's principal name as specified in the
-   AS-REQ as follows:
-
-
-
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 11]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-   1. If the KDC has its own binding between either the client's
-      signature-verification public key or the client's certificate and
-      the client's Kerberos principal name, it uses that binding.
-
-   2. Otherwise, if the client's X.509 certificate contains a Subject
-      Alternative Name (SAN) extension carrying a KRB5PrincipalName
-      (defined below) in the otherName field of the type GeneralName
-      [RFC3280], it binds the client's X.509 certificate to that name.
-
-      The type of the otherName field is AnotherName.  The type-id field
-      of the type AnotherName is id-pksan:
-
-       id-pksan OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509-sanan (2) }
-
-      And the value field of the type AnotherName is a
-      KRB5PrincipalName.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-   If the KDC does not have its own binding and there is no
-   KRB5PrincipalName name present in the client's X.509 certificate, or
-   if the Kerberos name in the request does not match the
-   KRB5PrincipalName in the client's X.509 certificate (including the
-   realm name), the KDC MUST return an error message with the code
-   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
-   this error message.
-
-   Even if the certification path is validated and the certificate is
-   mapped to the client's principal name, the KDC may decide not to
-   accept the client's certificate, depending on local policy.
-
-   The KDC MAY require the presence of an Extended Key Usage (EKU)
-   KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
-   client's X.509 certificate:
-
-       id-pkekuoid OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) pkekuoid(4) }
-              -- PKINIT client authentication.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   If this EKU KeyPurposeId is required but it is not present or if the
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 12]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-   client certificate is restricted not to be used for PKINIT client
-   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
-   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
-   is no accompanying e-data for this error message.  KDCs implementing
-   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-
-   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
-   are a large number of X.509 client certificates deployed for use with
-   PKINIT which have this EKU.
-
-   As a matter of local policy, the KDC MAY decide to reject requests on
-   the basis of the absence or presence of other specific EKU OID's.
-
-   If the client's public key is not accepted, the KDC returns an error
-   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.
-
-   The KDC MUST check the timestamp to ensure that the request is not a
-   replay, and that the time skew falls within acceptable limits.  The
-   recommendations for clock skew times in [RFC4120] apply here.  If the
-   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
-   KRB_AP_ERR_SKEW, respectively.
-
-   If the clientPublicValue is filled in, indicating that the client
-   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
-   check to see if the key parameters satisfy its policy.  If they do
-   not, it MUST return an error message with the code
-   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
-   TYPED-DATA that contains an element whose data-type is
-   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
-   the type TD-DH-PARAMETERS:
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-
-   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
-   that the KDC supports in decreasing preference order, from which the
-   client SHOULD pick one to retry the request.
-
-   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
-   KDC does not possess the corresponding key, the KDC MUST ignore the
-   kdcPkId field as if the client did not include one.
-
-   If there is a supportedCMSTypes field in the AuthPack, the KDC must
-   check to see if it supports any of the listed types.  If it supports
-   more than one of the types, the KDC SHOULD use the one listed first.
-   If it does not support any of them, it MUST return an error message
-   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 13]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-3.2.3  Generation of KDC Reply
-
-   Assuming that the client's request has been properly validated, the
-   KDC proceeds as per [RFC4120], except as follows.
-
-   The KDC MUST set the initial flag and include an authorization data
-   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
-   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
-   type AD-INITIAL-VERIFIED-CAS:
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-   containers if the list of CAs satisfies the AS' realm's local policy
-   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
-   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
-   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
-   resulting ticket.  If the list of CAs satisfies the local KDC's
-   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
-   container, otherwise it MAY unwrap the authorization data out of the
-   AD-IF-RELEVANT container.
-
-   Application servers that understand this authorization data type
-   SHOULD apply local policy to determine whether a given ticket bearing
-   such a type *not* contained within an AD-IF-RELEVANT container is
-   acceptable.  (This corresponds to the AP server checking the
-   transited field when the TRANSITED-POLICY-CHECKED flag has not been
-   set [RFC4120].)  If such a data type is contained within an AD-IF-
-   RELEVANT container, AP servers MAY apply local policy to determine
-   whether the authorization data is acceptable.
-
-   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
-   KDC encrypts the reply as usual, but not with the client's long-term
-   key.  Instead, it encrypts it with either a shared key derived from a
-   Diffie-Hellman exchange, or a generated encryption key.  The contents
-   of the PA-PK-AS-REP indicate which key delivery method is used:
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 14]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is id-pkrkeydata
-                   -- (1.2.840.113549.1.7.3) and the eContent field
-                   -- contains the DER encoding of the type
-                   -- ReplyKeyPack.
-                   -- ReplyKeyPack is defined in Section 3.2.3.2.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-                   -- present in the KDCDHKeyInfo.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING, as specified in Section 2.3.3 of
-                   -- [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request if DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if DH keys are reused. If
-                   -- this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted. See Section 3.2.3.1.
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 15]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-          ...
-       }
-
-
-3.2.3.1  Using Diffie-Hellman Key Exchange
-
-   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
-
-   The ContentInfo [RFC3852] structure for the dhSignedData field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is the OID value
-       for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
-       security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type KDCDHKeyInfo.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type
-       KDCDHKeyInfo.
-
-   5.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type KDCDHKeyInfo.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may only. be left empty if
-       the KDC public key specified by the kdcPkId field in the PA-PK-
-       AS-REQ was used for signing.  Otherwise, for path validation,
-       these certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [CAPATH].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   6.  If the client included the clientDHNonce field, then the KDC may
-       choose to reuse its DH keys (see Section 3.2.3.1).  If the server
-       reuses DH keys then it MUST include an expiration time in the
-       dhKeyExpiration field.  Past the point of the expiration time,
-       the signature over the type DHRepInfo is considered expired/
-       invalid.  When the server reuses DH keys then it MUST include a
-       serverDHNonce at least as long as the length of keys for the
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 16]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-       symmetric encryption system used to encrypt the AS reply.  Note
-       that including the serverDHNonce changes how the client and
-       server calculate the key to use to encrypt the reply; see below
-       for details.  The KDC SHOULD NOT reuse DH keys unless the
-       clientDHNonce field is present in the request.
-
-   The AS reply key is derived as follows:
-
-   1. Both the KDC and the client calculate the shared secret value as
-      follows:
-
-      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
-         shared secret value.  DHSharedSecret is the value ZZ as
-         described in Section 2.1.1 of [RFC2631].
-
-      DHSharedSecret is first padded with leading zeros such that the
-      size of DHSharedSecret in octets is the same as that of the
-      modulus, then represented as a string of octets in big-endian
-      order.
-
-      Implementation note: Both the client and the KDC can cache the
-      triple (ya, yb, DHSharedSecret), where ya is the client's public
-      key and yb is the KDC's public key.  If both ya and yb are the
-      same in a later exchange, the cached DHSharedSecret can be used.
-
-   2. Let K be the key-generation seed length [RFC3961] of the AS reply
-      key whose enctype is selected according to [RFC4120].
-
-   3. Define the function octetstring2key() as follows:
-
-           octetstring2key(x) == random-to-key(K-truncate(
-                                    SHA1(0x00 | x) |
-                                    SHA1(0x01 | x) |
-                                    SHA1(0x02 | x) |
-                                    ...
-                                    ))
-
-      where x is an octet string; | is the concatenation operator; 0x00,
-      0x01, 0x02, etc., are each represented as a single octet; random-
-      to-key() is an operation that generates a protocol key from a
-      bitstring of length K; and K-truncate truncates its input to the
-      first K bits.  Both K and random-to-key() are as defined in the
-      kcrypto profile [RFC3961] for the enctype of the AS reply key.
-
-
-
-
-
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 17]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
-      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
-      strings.
-
-   5. The AS reply key k is:
-
-           k = octetstring2key(DHSharedSecret | n_c | n_k)
-
-
-3.2.3.2  Using Public Key Encryption
-
-   In this case, the PA-PK-AS-REP contains a ContentInfo structure
-   wrapped in an OCTET STRING.  The AS reply key is encrypted in the
-   encKeyPack field, which contains data of type ReplyKeyPack:
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure for the encKeyPack field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-envelopedData
-       (as defined in [RFC3852]), and the content field is an
-       EnvelopedData (as defined in [RFC3852]).
-
-   2.  The contentType field for the type EnvelopedData is id-
-       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
-       pkcs (1) pkcs7 (7) signedData (2) }.
-
-   3.  The eContentType field for the inner type SignedData (when
-       decrypted from the encryptedContent field for the type
-       EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
-       internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 18]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-   4.  The eContent field for the inner type SignedData contains the DER
-       encoding of the type ReplyKeyPack.
-
-   5.  The signerInfos field of the inner type SignedData contains a
-       single signerInfo, which contains the signature over the type
-       ReplyKeyPack.
-
-   6.  The certificates field of the inner type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type ReplyKeyPack.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may only be left empty if
-       the KDC public key specified by the kdcPkId field in the PA-PK-
-       AS-REQ was used for signing.  Otherwise, for path validation,
-       these certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [CAPATH].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  The recipientInfos field of the type EnvelopedData is a SET which
-       MUST contain exactly one member of type KeyTransRecipientInfo.
-       The encryptedKey of this member contains the temporary key which
-       is encrypted using the client's public key.
-
-   8.  The unprotectedAttrs or originatorInfo fields of the type
-       EnvelopedData MAY be present.
-
-   Implementations of this RSA encryption key delivery method are
-   RECOMMENDED to support for RSA keys at least 2048 bits in size.
-
-3.2.4  Receipt of KDC Reply
-
-   Upon receipt of the KDC's reply, the client proceeds as follows.  If
-   the PA-PK-AS-REP contains the dhSignedData field, the client derives
-   the AS reply key using the same procedure used by the KDC as defined
-   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
-   field, and the client decrypts and extracts the temporary key in the
-   encryptedKey field of the member KeyTransRecipientInfo, and then uses
-   that as the AS reply key.
-
-   In either case, the client MUST verify the signature in the
-   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
-   be validated according to [RFC3280].  In addition, unless the client
-   can otherwise verify that the public key used to verify the KDC's
-   signature is bound to the KDC of the target realm, the KDC's X.509
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 19]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-   certificate MUST contain a Subject Alternative Name extension
-   [RFC3280] carrying an AnotherName whose type-id is id-pksan (as
-   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
-   matches the name of the TGS of the target realm (as defined in
-   Section 7.3 of [RFC4120]).
-
-   Based on local policy, the client MAY require that the KDC
-   certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
-
-       id-pkkdcekuoid OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) pkkdcekuoid(5) }
-              -- Signing KDC responses.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   If all applicable checks are satisfied, the client then decrypts the
-   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
-   and then proceeds as described in [RFC4120].
-
-   Implementation note: CAs issuing KDC certificates SHOULD place all
-   "short" and "fully-qualified" Kerberos realm names of the KDC (one
-   per GeneralName [RFC3280]) into the KDC certificate to allow maximum
-   flexibility.
-
-3.3  Interoperability Requirements
-
-   The client MUST be capable of sending a set of certificates
-   sufficient to allow the KDC to construct a certification path for the
-   client's certificate, if the correct set of certificates is provided
-   through configuration or policy.
-
-   If the client sends all the X.509 certificates on a certification
-   path to a trust anchor acceptable by the KDC, and the KDC can not
-   verify the client's public key otherwise, the KDC MUST be able to
-   process path validation for the client's certificate based on the
-   certificates in the request.
-
-   The KDC MUST be capable of sending a set of certificates sufficient
-   to allow the client to construct a certification path for the KDC's
-   certificate, if the correct set of certificates is provided through
-   configuration or policy.
-
-   If the KDC sends all the X.509 certificates on a certification path
-   to a trust anchor acceptable by the client, and the client can not
-   verify the KDC's public key otherwise, the client MUST be able to
-   process path validation for the KDC's certificate based on the
-   certificates in the reply.
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 20]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-3.4  KDC Indication of PKINIT Support
-
-   If pre-authentication is required, but was not present in the
-   request, per [RFC4120] an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
-   stored in the e-data field of the KRB-ERROR message to specify which
-   pre-authentication mechanisms are acceptable.  The KDC can then
-   indicate the support of PKINIT by including an empty element whose
-   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
-
-   Otherwise if it is required by the KDC's local policy that the client
-   must be pre-authenticated using the pre-authentication mechanism
-   specified in this document, but no PKINIT pre-authentication was
-   present in the request, an error message with the code
-   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
-
-   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
-   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
-   STRING), and clients MUST ignore this and any other value.  Future
-   extensions to this protocol may specify other data to send instead of
-   an empty OCTET STRING.
-
-4.  Security Considerations
-
-   The symmetric reply key size and Diffie-Hellman field size or RSA
-   modulus size should be chosen so as to provide sufficient
-   cryptographic security [RFC3766].
-
-   When MODP Diffie-Hellman is used, the exponents should have at least
-   twice as many bits as the symmetric keys that will be derived from
-   them [ODL99].
-
-   PKINIT raises certain security considerations beyond those that can
-   be regulated strictly in protocol definitions.  We will address them
-   in this section.
-
-   PKINIT extends the cross-realm model to the public-key
-   infrastructure.  Users of PKINIT must understand security policies
-   and procedures appropriate to the use of Public Key Infrastructures
-   [RFC3280].
-
-   Standard Kerberos allows the possibility of interactions between
-   cryptosystems of varying strengths; this document adds interactions
-   with public-key cryptosystems to Kerberos.  Some administrative
-   policies may allow the use of relatively weak public keys.  Using
-   such keys to wrap data encrypted under stronger conventional
-   cryptosystems may be inappropriate.
-
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 21]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-   PKINIT requires keys for symmetric cryptosystems to be generated.
-   Some such systems contain "weak" keys.  For recommendations regarding
-   these weak keys, see [RFC4120].
-
-   PKINIT allows the use of the same RSA key pair for encryption and
-   signing when doing RSA encryption based key delivery.  This is not
-   recommended usage of RSA keys [RFC3447], by using DH based key
-   delivery this is avoided.
-
-   Care should be taken in how certificates are chosen for the purposes
-   of authentication using PKINIT.  Some local policies may require that
-   key escrow be used for certain certificate types.  Deployers of
-   PKINIT should be aware of the implications of using certificates that
-   have escrowed keys for the purposes of authentication.  Because
-   signing only certificates are normally not escrowed, by using DH
-   based key delivery this is avoided.
-
-   PKINIT does not provide for a "return routability" test to prevent
-   attackers from mounting a denial-of-service attack on the KDC by
-   causing it to perform unnecessary and expensive public-key
-   operations.  Strictly speaking, this is also true of standard
-   Kerberos, although the potential cost is not as great, because
-   standard Kerberos does not make use of public-key cryptography.  By
-   using DH based key delivery and reusing DH keys, the necessary crypto
-   processing cost per request can be minimized.
-
-   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
-   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
-   be used if the KDC itself vouches for the user's certificate.
-
-5.  Acknowledgements
-
-   The following people have made significant contributions to this
-   draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
-   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
-   Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
-   Jaganathan, Chaskiel M Grundman and Stefan Santesson.
-
-   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
-   Jonathan Trostle who wrote earlier versions of this document.
-
-   The authors are indebted to the Kerberos working group chair Jeffrey
-   Hutzelman who kept track of various issues and was enormously helpful
-   during the creation of this document.
-
-   Some of the ideas on which this document is based arose during
-   discussions over several years between members of the SAAG, the IETF
-   CAT working group, and the PSRG, regarding integration of Kerberos
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 22]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-   and SPX.  Some ideas have also been drawn from the DASS system.
-   These changes are by no means endorsed by these groups.  This is an
-   attempt to revive some of the goals of those groups, and this
-   document approaches those goals primarily from the Kerberos
-   perspective.
-
-   Lastly, comments from groups working on similar ideas in DCE have
-   been invaluable.
-
-6.  IANA Considerations
-
-   This document has no actions for IANA.
-
-7.  References
-
-7.1  Normative References
-
-   [IEEE1363]
-              IEEE, "Standard Specifications for Public Key 
-              Cryptography", IEEE 1363, 2000.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
-              RFC 2412, November 1998.
-
-   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
-              RFC 2631, June 1999.
-
-   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
-              Algorithms", RFC 3370, August 2002.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 23]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
-              Encryption Algorithm in Cryptographic Message Syntax
-              (CMS)", RFC 3565, July 2003.
-
-   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
-              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
-              RFC 3766, April 2004.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
-              Encryption for Kerberos 5", RFC 3962, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [X.509-97] ITU-T.  Recommendation X.509: The Directory - Authentication 
-              Framework.  1997.
-
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding  
-              Rules (BER), Canonical Encoding Rules (CER) and
-              Distinguished Encoding Rules (DER), ITU-T Recommendation
-              X.690 (1997) | ISO/IEC International Standard
-              8825-1:1998.
-
-7.2  Informative References
-
-   [CAPATH]   RFC-Editor: To be replaced by RFC number for draft-ietf-
-              pkix-certpathbuild.  Work in Progress. 
-
-   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
-              Sizes", Journal of Cryptology 14 (2001) 255-293.
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 24]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-   
-   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
-              future, Designs, Codes, and Cryptography (1999)". 
-
-
-Authors' Addresses
-
-   Brian Tung
-   USC Information Sciences Institute
-   4676 Admiralty Way Suite 1001, Marina del Rey CA
-   Marina del Rey, CA  90292
-   US
-
-   Email: brian@isi.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-Appendix A.  PKINIT ASN.1 Module
-
-       KerberosV5-PK-INIT-SPEC {
-               iso(1) identified-organization(3) dod(6) internet(1)
-               security(5) kerberosV5(2) modules(4) pkinit(5)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       IMPORTS
-           SubjectPublicKeyInfo, AlgorithmIdentifier
-               FROM PKIX1Explicit88 { iso (1)
-                 identified-organization (3) dod (6) internet (1)
-                 security (5) mechanisms (5) pkix (7) id-mod (0)
-                 id-pkix1-explicit (18) }
-                 -- As defined in RFC 3280.
-
-           DomainParameters
-               FROM PKIX1Algorithms88 { iso(1)
-                 identified-organization(3) dod(6)
-                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-                 id-mod-pkix1-algorithms(17) }
-                 -- As defined in RFC 3279.
-
-           KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 25]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) } ;
-
-       id-pkinit OBJECT IDENTIFIER ::=
-         { iso (1) org (3) dod (6) internet (1) security (5)
-           kerberosv5 (2) pkinit (3) }
-
-       id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-       id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-       id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-       id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-       id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-       pa-pk-as-req INTEGER ::=                  16
-       pa-pk-as-rep INTEGER ::=                  17
-
-       ad-initial-verified-cas INTEGER ::=        9
-
-       td-trusted-certifiers INTEGER ::=        104
-       td-invalid-certificates INTEGER ::=      105
-       td-dh-parameters INTEGER ::=             109
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- A list of CAs, trusted by the client, that can
-                   -- be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 26]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING, as specified in Section 2.3.3 of
-                   -- [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 27]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so.
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 28]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-                   -- or a CA certificate (thereby its public key).
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is id-pkrkeydata
-                   -- (1.2.840.113549.1.7.3) and the eContent field
-                   -- contains the DER encoding of the type
-                   -- ReplyKeyPack.
-                   -- ReplyKeyPack is defined below.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-                   -- present.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING, as specified in Section 2.3.3 of
-                   -- [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 29]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request if DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if DH keys are reused. If
-                   -- this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-       END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 30]
-
-Internet-Draft                   PKINIT                        July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Tung & Zhu              Expires January 20, 2006               [Page 31]
-
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-28.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-28.txt
deleted file mode 100644
index ae76eb8d2..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-28.txt
+++ /dev/null
@@ -1,1897 +0,0 @@
-NETWORK WORKING GROUP                                            B. Tung
-Internet-Draft                        USC Information Sciences Institute
-Expires: March 16, 2006                                           L. Zhu
-                                                   Microsoft Corporation
-                                                      September 12, 2005
-
-
-     Public Key Cryptography for Initial Authentication in Kerberos
-                   draft-ietf-cat-kerberos-pk-init-28
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on March 16, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes protocol extensions (hereafter called PKINIT)
-   to the Kerberos protocol specification.  These extensions provide a
-   method for integrating public key cryptography into the initial
-   authentication exchange, by using asymmetric-key signature and/or
-   encryption algorithms in pre-authentication data fields.
-
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                 [Page 1]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  Definitions, Requirements, and Constants . . . . . . . . .  4
-       3.1.1.  Required Algorithms  . . . . . . . . . . . . . . . . .  4
-       3.1.2.  Defined Message and Encryption Types . . . . . . . . .  5
-       3.1.3.  Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
-     3.2.  PKINIT Pre-authentication Syntax and Use . . . . . . . . .  7
-       3.2.1.  Generation of Client Request . . . . . . . . . . . . .  7
-       3.2.2.  Receipt of Client Request  . . . . . . . . . . . . . . 10
-       3.2.3.  Generation of KDC Reply  . . . . . . . . . . . . . . . 14
-       3.2.4.  Receipt of KDC Reply . . . . . . . . . . . . . . . . . 19
-     3.3.  Interoperability Requirements  . . . . . . . . . . . . . . 20
-     3.4.  KDC Indication of PKINIT Support . . . . . . . . . . . . . 21
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
-   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 25
-   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 25
-   Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 31
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
-   Intellectual Property and Copyright Statements . . . . . . . . . . 34
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                 [Page 2]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-1.  Introduction
-
-   A client typically authenticates itself to a service in Kerberos
-   using three distinct though related exchanges.  First, the client
-   requests a ticket-granting ticket (TGT) from the Kerberos
-   authentication server (AS).  Then, it uses the TGT to request a
-   service ticket from the Kerberos ticket-granting server (TGS).
-   Usually, the AS and TGS are integrated in a single device known as a
-   Kerberos Key Distribution Center, or KDC.  Finally, the client uses
-   the service ticket to authenticate itself to the service.
-
-   The advantage afforded by the TGT is that the client exposes his
-   long-term secrets only once.  The TGT and its associated session key
-   can then be used for any subsequent service ticket requests.  One
-   result of this is that all further authentication is independent of
-   the method by which the initial authentication was performed.
-   Consequently, initial authentication provides a convenient place to
-   integrate public-key cryptography into Kerberos authentication.
-
-   As defined in [RFC4120], Kerberos authentication exchanges use
-   symmetric-key cryptography, in part for performance.  One
-   disadvantage of using symmetric-key cryptography is that the keys
-   must be shared, so that before a client can authenticate itself, he
-   must already be registered with the KDC.
-
-   Conversely, public-key cryptography (in conjunction with an
-   established Public Key Infrastructure) permits authentication without
-   prior registration with a KDC.  Adding it to Kerberos allows the
-   widespread use of Kerberized applications by clients without
-   requiring them to register first with a KDC--a requirement that has
-   no inherent security benefit.
-
-   As noted above, a convenient and efficient place to introduce public-
-   key cryptography into Kerberos is in the initial authentication
-   exchange.  This document describes the methods and data formats for
-   integrating public-key cryptography into Kerberos initial
-   authentication.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   Both the AS and the TGS are referred to as the KDC.
-
-   In this document, the encryption key used to encrypt the enc-part
-
-
-
-Tung & Zhu               Expires March 16, 2006                 [Page 3]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-   field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
-   reply key.
-
-
-3.  Extensions
-
-   This section describes extensions to [RFC4120] for supporting the use
-   of public-key cryptography in the initial request for a ticket.
-
-   Briefly, this document defines the following extensions to [RFC4120]:
-
-   1. The client indicates the use of public-key authentication by
-      including a special preauthenticator in the initial request.  This
-      preauthenticator contains the client's public-key data and a
-      signature.
-
-   2. The KDC tests the client's request against its authentication
-      policy and trusted Certification Authorities (CAs).
-
-   3. If the request passes the verification tests, the KDC replies as
-      usual, but the reply is encrypted using either:
-
-      a. a key generated through a Diffie-Hellman (DH) key exchange
-         [RFC2631] [IEEE1363] with the client, signed using the KDC's
-         signature key; or
-
-      b. a symmetric encryption key, signed using the KDC's signature
-         key and encrypted using the client's public key.
-
-      Any keying material required by the client to obtain the
-      encryption key for decrypting the KDC reply is returned in a pre-
-      authentication field accompanying the usual reply.
-
-   4. The client validates the KDC's signature, obtains the encryption
-      key, decrypts the reply, and then proceeds as usual.
-
-   Section 3.1 of this document enumerates the required algorithms and
-   necessary extension message types.  Section 3.2 describes the
-   extension messages in greater detail.
-
-3.1.  Definitions, Requirements, and Constants
-
-3.1.1.  Required Algorithms
-
-   All PKINIT implementations MUST support the following algorithms:
-
-
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                 [Page 4]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-   o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
-      sha1-96 [RFC3962].
-
-   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
-
-   o  AS reply key delivery method: Diffie-Hellman key exchange
-      [RFC2631].
-
-   In addition, implementations of this specification MUST be capable of
-   processing the Extended Key Usage (EKU) extension and the id-pksan
-   (as defined in Section 3.2.2) otherName of the Subject Alternative
-   Name (SAN) extension in X.509 certificates [RFC3280], if present.
-
-3.1.2.  Defined Message and Encryption Types
-
-   PKINIT makes use of the following new pre-authentication types:
-
-       PA_PK_AS_REQ                                 16
-       PA_PK_AS_REP                                 17
-
-   PKINIT also makes use of the following new authorization data type:
-
-       AD_INITIAL_VERIFIED_CAS                       9
-
-   PKINIT introduces the following new error codes:
-
-       KDC_ERR_CLIENT_NOT_TRUSTED                   62
-       KDC_ERR_INVALID_SIG                          64
-       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
-       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
-       KDC_ERR_INVALID_CERTIFICATE                  71
-       KDC_ERR_REVOKED_CERTIFICATE                  72
-       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
-       KDC_ERR_CLIENT_NAME_MISMATCH                 75
-       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
-
-   PKINIT uses the following typed data types for errors:
-
-       TD_TRUSTED_CERTIFIERS                       104
-       TD_INVALID_CERTIFICATES                     105
-       TD_DH_PARAMETERS                            109
-
-   PKINIT defines the following encryption types, for use in the AS-REQ
-   message to indicate acceptance of the corresponding algorithms that
-   can used by Cryptographic Message Syntax (CMS) [RFC3852] messages in
-   the reply:
-
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                 [Page 5]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-       dsaWithSHA1-CmsOID                            9
-       md5WithRSAEncryption-CmsOID                  10
-       sha1WithRSAEncryption-CmsOID                 11
-       rc2CBC-EnvOID                                12
-       rsaEncryption-EnvOID   (PKCS1 v1.5)          13
-       rsaES-OAEP-EnvOID      (PKCS1 v2.0)          14
-       des-ede3-cbc-EnvOID                          15
-
-   The ASN.1 module for all structures defined in this document (plus
-   IMPORT statements for all imported structures) is given in
-   Appendix A.
-
-   All structures defined in or imported into this document MUST be
-   encoded using Distinguished Encoding Rules (DER) [X690] (unless
-   otherwise noted).  All data structures carried in OCTET STRINGs must
-   be encoded according to the rules specified in corresponding
-   specifications.
-
-   Interoperability note: Some implementations may not be able to decode
-   wrapped CMS objects encoded with BER but not DER; specifically, they
-   may not be able to decode infinite length encodings.  To maximize
-   interoperability, implementers SHOULD encode CMS objects used in
-   PKINIT with DER.
-
-3.1.3.  Algorithm Identifiers
-
-   PKINIT does not define, but does make use of, the following algorithm
-   identifiers.
-
-   PKINIT uses the following algorithm identifier(s) for Diffie-Hellman
-   key agreement [RFC3279]:
-
-       dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
-
-   PKINIT uses the following signature algorithm identifiers [RFC3279]:
-
-       sha-1WithRSAEncryption (RSA with SHA1)
-       md5WithRSAEncryption   (RSA with MD5)
-       id-dsa-with-sha1       (DSA with SHA1)
-
-   PKINIT uses the following encryption algorithm identifiers [RFC3447]
-   for encrypting the temporary key with a public key:
-
-       rsaEncryption          (PKCS1 v1.5)
-       id-RSAES-OAEP          (PKCS1 v2.0)
-
-   PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
-   for encrypting the AS reply key with the temporary key:
-
-
-
-Tung & Zhu               Expires March 16, 2006                 [Page 6]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-       des-ede3-cbc           (three-key 3DES, CBC mode)
-       rc2-cbc                (RC2, CBC mode)
-       id-aes256-CBC          (AES-256, CBC mode)
-
-3.2.  PKINIT Pre-authentication Syntax and Use
-
-   This section defines the syntax and use of the various pre-
-   authentication fields employed by PKINIT.
-
-3.2.1.  Generation of Client Request
-
-   The initial authentication request (AS-REQ) is sent as per [RFC4120];
-   in addition, a pre-authentication data element, whose padata-type is
-   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
-   type PA-PK-AS-REQ, is included.
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- A list of CAs, trusted by the client, that can
-                   -- be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-
-
-Tung & Zhu               Expires March 16, 2006                 [Page 7]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-
-
-
-Tung & Zhu               Expires March 16, 2006                 [Page 8]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-                   -- do so (see Section 3.2.3.1).
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure for the signedAuthPack field is
-   filled out as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is id-pkauthdata:
-       { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-       pkinit(3) pkauthdata(1) }.
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type AuthPack.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type AuthPack.
-
-   5.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the KDC can verify the signature over the
-       type AuthPack.  For path validation, these certificates SHOULD be
-       sufficient to construct at least one certification path from the
-       client certificate to one trust anchor acceptable by the KDC
-       [CAPATH].  The client MUST be capable of including such a set of
-       certificates if configured to do so.  The certificates field MUST
-       NOT contain "root" CA certificates.
-
-   6.  The client's Diffie-Hellman public value (clientPublicValue) is
-       included if and only if the client wishes to use the Diffie-
-       Hellman key agreement method.  The Diffie-Hellman domain
-
-
-
-Tung & Zhu               Expires March 16, 2006                 [Page 9]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-       parameters [IEEE1363] for the client's public key are specified
-       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
-       and the client's Diffie-Hellman public key value is mapped to a
-       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
-       using the Diffie-Hellman key agreement method, implementations
-       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
-       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
-       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
-       group 16 [RFC3526].
-
-       The Diffie-Hellman field size should be chosen so as to provide
-       sufficient cryptographic security [RFC3766].
-
-       When MODP Diffie-Hellman is used, the exponents should have at
-       least twice as many bits as the symmetric keys that will be
-       derived from them [ODL99].
-
-   7.  The client may wish to reuse DH keys or to allow the KDC to do so
-       (see Section 3.2.3.1).  If so, then the client includes the
-       clientDHNonce field.  This nonce string needs to be as long as
-       the longest key length of the symmetric key types that the client
-       supports.  This nonce MUST be chosen randomly.
-
-
-3.2.2.  Receipt of Client Request
-
-   Upon receiving the client's request, the KDC validates it.  This
-   section describes the steps that the KDC MUST (unless otherwise
-   noted) take in validating the request.
-
-   The KDC verifies the client's signature in the signedAuthPack field
-   according to [RFC3852].
-
-   If, while validating the client's X.509 certificate [RFC3280], the
-   KDC cannot build a certification path to validate the client's
-   certificate, it sends back a KRB-ERROR [RFC4120] message with the
-   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
-   this error message is a TYPED-DATA (as defined in [RFC4120]) that
-   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
-   whose data-value contains the DER encoding of the type TD-TRUSTED-
-   CERTIFIERS:
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 10]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-   Upon receiving this error message, the client SHOULD retry only if it
-   has a different set of certificates (from those of the previous
-   requests) that form a certification path (or a partial path) from one
-   of the trust anchors acceptable by the KDC to its own certificate.
-
-   If, while processing the certification path, the KDC determines that
-   the signature on one of the certificates in the signedAuthPack field
-   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
-   message is a TYPED-DATA that contains an element whose data-type is
-   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
-   encoding of the type TD-INVALID-CERTIFICATES:
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-   If more than one X.509 certificate signature is invalid, the KDC MAY
-   include one IssuerAndSerialNumber per invalid signature within the
-   TD-INVALID-CERTIFICATES.
-
-   The client's X.509 certificate is validated according to [RFC3280].
-
-   Based on local policy, the KDC may also check whether any X.509
-   certificates in the certification path validating the client's
-   certificate have been revoked.  If any of them have been revoked, the
-   KDC MUST return an error message with the code
-   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
-   revocation status but is unable to do so, it SHOULD return an error
-   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
-   certificate or certificates affected are identified exactly as for
-   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
-
-   Note that the TD_INVALID_CERTIFICATES error data is only used to
-   identify invalid certificates sent by the client in the request.
-
-   The client's public key is then used to verify the signature.  If the
-   signature fails to verify, the KDC MUST return an error message with
-   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
-   this error message.
-
-   In addition to validating the client's signature, the KDC MUST also
-   check that the client's public key used to verify the client's
-   signature is bound to the client's principal name as specified in the
-   AS-REQ as follows:
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 11]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-   1. If the KDC has its own binding between either the client's
-      signature-verification public key or the client's certificate and
-      the client's Kerberos principal name, it uses that binding.
-
-   2. Otherwise, if the client's X.509 certificate contains a Subject
-      Alternative Name (SAN) extension carrying a KRB5PrincipalName
-      (defined below) in the otherName field of the type GeneralName
-      [RFC3280], it binds the client's X.509 certificate to that name.
-
-      The type of the otherName field is AnotherName.  The type-id field
-      of the type AnotherName is id-pksan:
-
-       id-pksan OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509-sanan (2) }
-
-      And the value field of the type AnotherName is a
-      KRB5PrincipalName.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-   If the KDC does not have its own binding and there is no
-   KRB5PrincipalName name present in the client's X.509 certificate, or
-   if the Kerberos name in the request does not match the
-   KRB5PrincipalName in the client's X.509 certificate (including the
-   realm name), the KDC MUST return an error message with the code
-   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
-   this error message.
-
-   Even if the certification path is validated and the certificate is
-   mapped to the client's principal name, the KDC may decide not to
-   accept the client's certificate, depending on local policy.
-
-   The KDC MAY require the presence of an Extended Key Usage (EKU)
-   KeyPurposeId [RFC3280] id-pkekuoid in the extensions field of the
-   client's X.509 certificate:
-
-       id-pkekuoid OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) pkekuoid(4) }
-              -- PKINIT client authentication.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   If this EKU KeyPurposeId is required but it is not present or if the
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 12]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-   client certificate is restricted not to be used for PKINIT client
-   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
-   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
-   is no accompanying e-data for this error message.  KDCs implementing
-   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-sc-
-   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
-   are a large number of X.509 client certificates deployed for use with
-   PKINIT which have this EKU.
-
-   As a matter of local policy, the KDC MAY decide to reject requests on
-   the basis of the absence or presence of other specific EKU OID's.
-
-   If the client's public key is not accepted, the KDC returns an error
-   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.
-
-   The KDC MUST check the timestamp to ensure that the request is not a
-   replay, and that the time skew falls within acceptable limits.  The
-   recommendations for clock skew times in [RFC4120] apply here.  If the
-   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
-   KRB_AP_ERR_SKEW, respectively.
-
-   If the clientPublicValue is filled in, indicating that the client
-   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
-   check to see if the key parameters satisfy its policy.  If they do
-   not, it MUST return an error message with the code
-   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
-   TYPED-DATA that contains an element whose data-type is
-   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
-   the type TD-DH-PARAMETERS:
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-
-   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
-   that the KDC supports in decreasing preference order, from which the
-   client SHOULD pick one to retry the request.
-
-   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
-   KDC does not possess the corresponding key, the KDC MUST ignore the
-   kdcPkId field as if the client did not include one.
-
-   If there is a supportedCMSTypes field in the AuthPack, the KDC must
-   check to see if it supports any of the listed types.  If it supports
-   more than one of the types, the KDC SHOULD use the one listed first.
-   If it does not support any of them, it MUST return an error message
-   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 13]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-3.2.3.  Generation of KDC Reply
-
-   Assuming that the client's request has been properly validated, the
-   KDC proceeds as per [RFC4120], except as follows.
-
-   The KDC MUST set the initial flag and include an authorization data
-   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
-   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
-   type AD-INITIAL-VERIFIED-CAS:
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-   containers if the list of CAs satisfies the AS' realm's local policy
-   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
-   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
-   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
-   resulting ticket.  If the list of CAs satisfies the local KDC's
-   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
-   container, otherwise it MAY unwrap the authorization data out of the
-   AD-IF-RELEVANT container.
-
-   Application servers that understand this authorization data type
-   SHOULD apply local policy to determine whether a given ticket bearing
-   such a type *not* contained within an AD-IF-RELEVANT container is
-   acceptable.  (This corresponds to the AP server checking the
-   transited field when the TRANSITED-POLICY-CHECKED flag has not been
-   set [RFC4120].)  If such a data type is contained within an AD-IF-
-   RELEVANT container, AP servers MAY apply local policy to determine
-   whether the authorization data is acceptable.
-
-   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
-   KDC encrypts the reply as usual, but not with the client's long-term
-   key.  Instead, it encrypts it with either a shared key derived from a
-   Diffie-Hellman exchange, or a generated encryption key.  The contents
-   of the PA-PK-AS-REP indicate which key delivery method is used:
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 14]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is id-pkrkeydata
-                   -- (1.2.840.113549.1.7.3) and the eContent field
-                   -- contains the DER encoding of the type
-                   -- ReplyKeyPack.
-                   -- ReplyKeyPack is defined in Section 3.2.3.2.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-                   -- present in the KDCDHKeyInfo.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request if DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if DH keys are reused. If
-                   -- this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted. See Section 3.2.3.1.
-          ...
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 15]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-       }
-
-3.2.3.1.  Using Diffie-Hellman Key Exchange
-
-   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
-
-   The ContentInfo [RFC3852] structure for the dhSignedData field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is the OID value
-       for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
-       security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type KDCDHKeyInfo.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type
-       KDCDHKeyInfo.
-
-   5.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type KDCDHKeyInfo.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may only. be left empty if
-       the KDC public key specified by the kdcPkId field in the PA-PK-
-       AS-REQ was used for signing.  Otherwise, for path validation,
-       these certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [CAPATH].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   6.  If the client included the clientDHNonce field, then the KDC may
-       choose to reuse its DH keys (see Section 3.2.3.1).  If the server
-       reuses DH keys then it MUST include an expiration time in the
-       dhKeyExpiration field.  Past the point of the expiration time,
-       the signature over the type DHRepInfo is considered expired/
-       invalid.  When the server reuses DH keys then it MUST include a
-       serverDHNonce at least as long as the length of keys for the
-       symmetric encryption system used to encrypt the AS reply.  Note
-       that including the serverDHNonce changes how the client and
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 16]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-       server calculate the key to use to encrypt the reply; see below
-       for details.  The KDC SHOULD NOT reuse DH keys unless the
-       clientDHNonce field is present in the request.
-
-   The AS reply key is derived as follows:
-
-   1. Both the KDC and the client calculate the shared secret value as
-      follows:
-
-      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
-         shared secret value.  DHSharedSecret is the value ZZ as
-         described in Section 2.1.1 of [RFC2631].
-
-      DHSharedSecret is first padded with leading zeros such that the
-      size of DHSharedSecret in octets is the same as that of the
-      modulus, then represented as a string of octets in big-endian
-      order.
-
-      Implementation note: Both the client and the KDC can cache the
-      triple (ya, yb, DHSharedSecret), where ya is the client's public
-      key and yb is the KDC's public key.  If both ya and yb are the
-      same in a later exchange, the cached DHSharedSecret can be used.
-
-   2. Let K be the key-generation seed length [RFC3961] of the AS reply
-      key whose enctype is selected according to [RFC4120].
-
-   3. Define the function octetstring2key() as follows:
-
-           octetstring2key(x) == random-to-key(K-truncate(
-                                    SHA1(0x00 | x) |
-                                    SHA1(0x01 | x) |
-                                    SHA1(0x02 | x) |
-                                    ...
-                                    ))
-
-      where x is an octet string; | is the concatenation operator; 0x00,
-      0x01, 0x02, etc., are each represented as a single octet; random-
-      to-key() is an operation that generates a protocol key from a
-      bitstring of length K; and K-truncate truncates its input to the
-      first K bits.  Both K and random-to-key() are as defined in the
-      kcrypto profile [RFC3961] for the enctype of the AS reply key.
-
-   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
-      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
-      strings.
-
-
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 17]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-   5. The AS reply key k is:
-
-           k = octetstring2key(DHSharedSecret | n_c | n_k)
-
-3.2.3.2.  Using Public Key Encryption
-
-   In this case, the PA-PK-AS-REP contains a ContentInfo structure
-   wrapped in an OCTET STRING.  The AS reply key is encrypted in the
-   encKeyPack field, which contains data of type ReplyKeyPack:
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure for the encKeyPack field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-envelopedData
-       (as defined in [RFC3852]), and the content field is an
-       EnvelopedData (as defined in [RFC3852]).
-
-   2.  The contentType field for the type EnvelopedData is id-
-       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
-       pkcs (1) pkcs7 (7) signedData (2) }.
-
-   3.  The eContentType field for the inner type SignedData (when
-       decrypted from the encryptedContent field for the type
-       EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
-       internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.
-
-   4.  The eContent field for the inner type SignedData contains the DER
-       encoding of the type ReplyKeyPack.
-
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 18]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-   5.  The signerInfos field of the inner type SignedData contains a
-       single signerInfo, which contains the signature over the type
-       ReplyKeyPack.
-
-   6.  The certificates field of the inner type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type ReplyKeyPack.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may only be left empty if
-       the KDC public key specified by the kdcPkId field in the PA-PK-
-       AS-REQ was used for signing.  Otherwise, for path validation,
-       these certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [CAPATH].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  The recipientInfos field of the type EnvelopedData is a SET which
-       MUST contain exactly one member of type KeyTransRecipientInfo.
-       The encryptedKey of this member contains the temporary key which
-       is encrypted using the client's public key.
-
-   8.  The unprotectedAttrs or originatorInfo fields of the type
-       EnvelopedData MAY be present.
-
-   Implementations of this RSA encryption key delivery method are
-   RECOMMENDED to support for RSA keys at least 2048 bits in size.
-
-3.2.4.  Receipt of KDC Reply
-
-   Upon receipt of the KDC's reply, the client proceeds as follows.  If
-   the PA-PK-AS-REP contains the dhSignedData field, the client derives
-   the AS reply key using the same procedure used by the KDC as defined
-   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
-   field, and the client decrypts and extracts the temporary key in the
-   encryptedKey field of the member KeyTransRecipientInfo, and then uses
-   that as the AS reply key.
-
-   If the public key encrytion method is used, the client MUST verify
-   the asChecksum contained in the ReplyKeyPack.
-
-   In either case, the client MUST verify the signature in the
-   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
-   be validated according to [RFC3280].  In addition, unless the client
-   can otherwise verify that the public key used to verify the KDC's
-   signature is bound to the KDC of the target realm, the KDC's X.509
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 19]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-   certificate MUST contain a Subject Alternative Name extension
-   [RFC3280] carrying an AnotherName whose type-id is id-pksan (as
-   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
-   matches the name of the TGS of the target realm (as defined in
-   Section 7.3 of [RFC4120]).
-
-   Unless the client knows by some other means that the KDC certificate
-   is intended for a Kerberos KDC, the client MUST require that the KDC
-   certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
-
-       id-pkkdcekuoid OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) pkkdcekuoid(5) }
-              -- Signing KDC responses.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   If the KDC certificate contains the Kerberos TGS name encoded as an
-   id-pksan SAN, this certificate is certified by the issuing CA as a
-   KDC certificate, therefore the id-pkkdcekuoid EKU is not required.
-
-   If all applicable checks are satisfied, the client then decrypts the
-   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
-   and then proceeds as described in [RFC4120].
-
-   Implementation note: CAs issuing KDC certificates SHOULD place all
-   "short" and "fully-qualified" Kerberos realm names of the KDC (one
-   per GeneralName [RFC3280]) into the KDC certificate to allow maximum
-   flexibility.
-
-3.3.  Interoperability Requirements
-
-   The client MUST be capable of sending a set of certificates
-   sufficient to allow the KDC to construct a certification path for the
-   client's certificate, if the correct set of certificates is provided
-   through configuration or policy.
-
-   If the client sends all the X.509 certificates on a certification
-   path to a trust anchor acceptable by the KDC, and the KDC can not
-   verify the client's public key otherwise, the KDC MUST be able to
-   process path validation for the client's certificate based on the
-   certificates in the request.
-
-   The KDC MUST be capable of sending a set of certificates sufficient
-   to allow the client to construct a certification path for the KDC's
-   certificate, if the correct set of certificates is provided through
-   configuration or policy.
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 20]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-   If the KDC sends all the X.509 certificates on a certification path
-   to a trust anchor acceptable by the client, and the client can not
-   verify the KDC's public key otherwise, the client MUST be able to
-   process path validation for the KDC's certificate based on the
-   certificates in the reply.
-
-3.4.  KDC Indication of PKINIT Support
-
-   If pre-authentication is required, but was not present in the
-   request, per [RFC4120] an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
-   stored in the e-data field of the KRB-ERROR message to specify which
-   pre-authentication mechanisms are acceptable.  The KDC can then
-   indicate the support of PKINIT by including an empty element whose
-   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
-
-   Otherwise if it is required by the KDC's local policy that the client
-   must be pre-authenticated using the pre-authentication mechanism
-   specified in this document, but no PKINIT pre-authentication was
-   present in the request, an error message with the code
-   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
-
-   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
-   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
-   STRING), and clients MUST ignore this and any other value.  Future
-   extensions to this protocol may specify other data to send instead of
-   an empty OCTET STRING.
-
-
-4.  Security Considerations
-
-   The symmetric reply key size and Diffie-Hellman field size or RSA
-   modulus size should be chosen so as to provide sufficient
-   cryptographic security [RFC3766].
-
-   When MODP Diffie-Hellman is used, the exponents should have at least
-   twice as many bits as the symmetric keys that will be derived from
-   them [ODL99].
-
-   PKINIT raises certain security considerations beyond those that can
-   be regulated strictly in protocol definitions.  We will address them
-   in this section.
-
-   PKINIT extends the cross-realm model to the public-key
-   infrastructure.  Users of PKINIT must understand security policies
-   and procedures appropriate to the use of Public Key Infrastructures
-   [RFC3280].
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 21]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-   In order to trust a KDC certificate that is certified by a CA as a
-   KDC certificate for a target realm (for example, by asserting the TGS
-   name of that Kerberos realm as an id-pksan SAN and/or restricting the
-   certificate usage by using the id-pkkdcekuoid EKU, as described in
-   Section 3.2.4), the client MUST verify that the KDC certificate's
-   issuing CA is authorized to issue KDC certificates for that target
-   realm.  Otherwise, the binding between the KDC certificate and the
-   KDC of the target realm is not established.
-
-   How to validate this authorization is a matter of local policy.  A
-   way to achieve this is the configuration of specific sets of
-   intermediary CAs and trust anchors, one of which must be on the KDC
-   certificate's certification path [RFC3280]; and for each CA or trust
-   anchor the realms for which it is allowed to issue certificates.
-
-   In addition, if any CA is trusted to issue KDC certificates can also
-   issue other kinds of certificates, then local policy must be able to
-   distinguish between them: for example, it could require that KDC
-   certificates contain the id-pkkdcekuoid EKU or that the realm be
-   specified with the id-pksan SAN.
-
-   It is the responsibility of the PKI administrators for an
-   organization to ensure that KDC certificates are only issued to KDCs,
-   and that clients can ascertain this using their local policy.
-
-   Standard Kerberos allows the possibility of interactions between
-   cryptosystems of varying strengths; this document adds interactions
-   with public-key cryptosystems to Kerberos.  Some administrative
-   policies may allow the use of relatively weak public keys.  Using
-   such keys to wrap data encrypted under stronger conventional
-   cryptosystems may be inappropriate.
-
-   PKINIT requires keys for symmetric cryptosystems to be generated.
-   Some such systems contain "weak" keys.  For recommendations regarding
-   these weak keys, see [RFC4120].
-
-   PKINIT allows the use of the same RSA key pair for encryption and
-   signing when doing RSA encryption based key delivery.  This is not
-   recommended usage of RSA keys [RFC3447], by using DH based key
-   delivery this is avoided.
-
-   Care should be taken in how certificates are chosen for the purposes
-   of authentication using PKINIT.  Some local policies may require that
-   key escrow be used for certain certificate types.  Deployers of
-   PKINIT should be aware of the implications of using certificates that
-   have escrowed keys for the purposes of authentication.  Because
-   signing only certificates are normally not escrowed, by using DH
-   based key delivery this is avoided.
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 22]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-   PKINIT does not provide for a "return routability" test to prevent
-   attackers from mounting a denial-of-service attack on the KDC by
-   causing it to perform unnecessary and expensive public-key
-   operations.  Strictly speaking, this is also true of standard
-   Kerberos, although the potential cost is not as great, because
-   standard Kerberos does not make use of public-key cryptography.  By
-   using DH based key delivery and reusing DH keys, the necessary crypto
-   processing cost per request can be minimized.
-
-   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
-   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
-   be used if the KDC itself vouches for the user's certificate.
-
-
-5.  Acknowledgements
-
-   The following people have made significant contributions to this
-   draft: Paul Leach, Kristin Lauter, Sam Hartman, Love Hornquist
-   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
-   Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
-   Jaganathan, Chaskiel M Grundman, Stefan Santesson, Andre Scedrov and
-   Aaron D. Jaggard.
-
-   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
-   Jonathan Trostle who wrote earlier versions of this document.
-
-   The authors are indebted to the Kerberos working group chair Jeffrey
-   Hutzelman who kept track of various issues and was enormously helpful
-   during the creation of this document.
-
-   Some of the ideas on which this document is based arose during
-   discussions over several years between members of the SAAG, the IETF
-   CAT working group, and the PSRG, regarding integration of Kerberos
-   and SPX.  Some ideas have also been drawn from the DASS system.
-   These changes are by no means endorsed by these groups.  This is an
-   attempt to revive some of the goals of those groups, and this
-   document approaches those goals primarily from the Kerberos
-   perspective.
-
-   Lastly, comments from groups working on similar ideas in DCE have
-   been invaluable.
-
-
-6.  IANA Considerations
-
-   This document has no actions for IANA.
-
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 23]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-7.  References
-
-7.1.  Normative References
-
-   [IEEE1363]
-              IEEE, "Standard Specifications for Public Key 
-              Cryptography", IEEE 1363, 2000.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
-              RFC 2412, November 1998.
-
-   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
-              RFC 2631, June 1999.
-
-   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
-              Algorithms", RFC 3370, August 2002.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
-              Encryption Algorithm in Cryptographic Message Syntax
-              (CMS)", RFC 3565, July 2003.
-
-   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
-              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
-              RFC 3766, April 2004.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 24]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
-              Encryption for Kerberos 5", RFC 3962, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [X.509-97] ITU-T.  Recommendation X.509: The Directory - Authentication 
-              Framework.  1997.
-              
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding  
-              Rules (BER), Canonical Encoding Rules (CER) and
-              Distinguished Encoding Rules (DER), ITU-T Recommendation
-              X.690 (1997) | ISO/IEC International Standard
-              8825-1:1998.
-
-7.2.  Informative References
-
-   [CAPATH]   RFC-Editor: To be replaced by RFC number for draft-ietf-
-              pkix-certpathbuild.  Work in Progress. 
-
-   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
-              Sizes", Journal of Cryptology 14 (2001) 255-293.
-   
-   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
-              future, Designs, Codes, and Cryptography (1999)". 
-
-Appendix A.  PKINIT ASN.1 Module
-
-       KerberosV5-PK-INIT-SPEC {
-               iso(1) identified-organization(3) dod(6) internet(1)
-               security(5) kerberosV5(2) modules(4) pkinit(5)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       IMPORTS
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 25]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-           SubjectPublicKeyInfo, AlgorithmIdentifier
-               FROM PKIX1Explicit88 { iso (1)
-                 identified-organization (3) dod (6) internet (1)
-                 security (5) mechanisms (5) pkix (7) id-mod (0)
-                 id-pkix1-explicit (18) }
-                 -- As defined in RFC 3280.
-
-           KerberosTime, PrincipalName, Realm, EncryptionKey
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) } ;
-
-       id-pkinit OBJECT IDENTIFIER ::=
-         { iso (1) org (3) dod (6) internet (1) security (5)
-           kerberosv5 (2) pkinit (3) }
-
-       id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-       id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-       id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-       id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-       id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-       id-pksan OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509-sanan (2) }
-
-       pa-pk-as-req INTEGER ::=                  16
-       pa-pk-as-rep INTEGER ::=                  17
-
-       ad-initial-verified-cas INTEGER ::=        9
-
-       td-trusted-certifiers INTEGER ::=        104
-       td-invalid-certificates INTEGER ::=      105
-       td-dh-parameters INTEGER ::=             109
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkauthdata (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 26]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- A list of CAs, trusted by the client, that can
-                   -- be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 27]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so.
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 28]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-                   -- signature.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is id-pkrkeydata
-                   -- (1.2.840.113549.1.7.3) and the eContent field
-                   -- contains the DER encoding of the type
-                   -- ReplyKeyPack.
-                   -- ReplyKeyPack is defined below.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 29]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-                   -- present.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-           nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request if DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if DH keys are reused. If
-                   -- this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-       END
-
-
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 30]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-Appendix B.  Test Vectors
-
-   Function octetstring2key() is defined in Section 3.2.3.1.  This
-   section describes a few sets of test vectors that would be useful for
-   implementers of octetstring2key().
-
-
-   Set 1
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
-     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
-
-
-   Set 2:
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 31]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
-     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
-
-
-   Set 3:
-   ======
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
-     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
-     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
-     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
-     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
-
-
-   Set 4:
-   =====
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
-     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 32]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-Authors' Addresses
-
-   Brian Tung
-   USC Information Sciences Institute
-   4676 Admiralty Way Suite 1001, Marina del Rey CA
-   Marina del Rey, CA  90292
-   US
-
-   Email: brian@isi.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 33]
-
-Internet-Draft                   PKINIT                   September 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Tung & Zhu               Expires March 16, 2006                [Page 34]
-
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-29.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-29.txt
deleted file mode 100644
index 1c70b1804..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-29.txt
+++ /dev/null
@@ -1,2013 +0,0 @@
-NETWORK WORKING GROUP                                            B. Tung
-Internet-Draft                        USC Information Sciences Institute
-Expires: April 22, 2006                                           L. Zhu
-                                                   Microsoft Corporation
-                                                        October 19, 2005
-
-
-     Public Key Cryptography for Initial Authentication in Kerberos
-                   draft-ietf-cat-kerberos-pk-init-29
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 22, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes protocol extensions (hereafter called PKINIT)
-   to the Kerberos protocol specification.  These extensions provide a
-   method for integrating public key cryptography into the initial
-   authentication exchange, by using asymmetric-key signature and/or
-   encryption algorithms in pre-authentication data fields.
-
-
-
-
-
-Tung & Zhu               Expires April 22, 2006                 [Page 1]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  Definitions, Requirements, and Constants . . . . . . . . .  4
-       3.1.1.  Required Algorithms  . . . . . . . . . . . . . . . . .  4
-       3.1.2.  Defined Message and Encryption Types . . . . . . . . .  5
-       3.1.3.  Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
-     3.2.  PKINIT Pre-authentication Syntax and Use . . . . . . . . .  7
-       3.2.1.  Generation of Client Request . . . . . . . . . . . . .  7
-       3.2.2.  Receipt of Client Request  . . . . . . . . . . . . . . 10
-       3.2.3.  Generation of KDC Reply  . . . . . . . . . . . . . . . 14
-       3.2.4.  Receipt of KDC Reply . . . . . . . . . . . . . . . . . 20
-     3.3.  Interoperability Requirements  . . . . . . . . . . . . . . 21
-     3.4.  KDC Indication of PKINIT Support . . . . . . . . . . . . . 21
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
-   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 25
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 26
-   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 26
-   Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 32
-   Appendix C.  Miscellaneous Information about Microsoft Windows
-                PKINIT Implementations  . . . . . . . . . . . . . . . 33
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
-   Intellectual Property and Copyright Statements . . . . . . . . . . 36
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires April 22, 2006                 [Page 2]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-1.  Introduction
-
-   A client typically authenticates itself to a service in Kerberos
-   using three distinct though related exchanges.  First, the client
-   requests a ticket-granting ticket (TGT) from the Kerberos
-   authentication server (AS).  Then, it uses the TGT to request a
-   service ticket from the Kerberos ticket-granting server (TGS).
-   Usually, the AS and TGS are integrated in a single device known as a
-   Kerberos Key Distribution Center, or KDC.  Finally, the client uses
-   the service ticket to authenticate itself to the service.
-
-   The advantage afforded by the TGT is that the client exposes his
-   long-term secrets only once.  The TGT and its associated session key
-   can then be used for any subsequent service ticket requests.  One
-   result of this is that all further authentication is independent of
-   the method by which the initial authentication was performed.
-   Consequently, initial authentication provides a convenient place to
-   integrate public-key cryptography into Kerberos authentication.
-
-   As defined in [RFC4120], Kerberos authentication exchanges use
-   symmetric-key cryptography, in part for performance.  One
-   disadvantage of using symmetric-key cryptography is that the keys
-   must be shared, so that before a client can authenticate itself, he
-   must already be registered with the KDC.
-
-   Conversely, public-key cryptography (in conjunction with an
-   established Public Key Infrastructure) permits authentication without
-   prior registration with a KDC.  Adding it to Kerberos allows the
-   widespread use of Kerberized applications by clients without
-   requiring them to register first with a KDC--a requirement that has
-   no inherent security benefit.
-
-   As noted above, a convenient and efficient place to introduce public-
-   key cryptography into Kerberos is in the initial authentication
-   exchange.  This document describes the methods and data formats for
-   integrating public-key cryptography into Kerberos initial
-   authentication.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   Both the AS and the TGS are referred to as the KDC.
-
-   In this document, the encryption key used to encrypt the enc-part
-
-
-
-Tung & Zhu               Expires April 22, 2006                 [Page 3]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-   field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
-   reply key.
-
-
-3.  Extensions
-
-   This section describes extensions to [RFC4120] for supporting the use
-   of public-key cryptography in the initial request for a ticket.
-
-   Briefly, this document defines the following extensions to [RFC4120]:
-
-   1. The client indicates the use of public-key authentication by
-      including a special preauthenticator in the initial request.  This
-      preauthenticator contains the client's public-key data and a
-      signature.
-
-   2. The KDC tests the client's request against its authentication
-      policy and trusted Certification Authorities (CAs).
-
-   3. If the request passes the verification tests, the KDC replies as
-      usual, but the reply is encrypted using either:
-
-      a. a key generated through a Diffie-Hellman (DH) key exchange
-         [RFC2631] [IEEE1363] with the client, signed using the KDC's
-         signature key; or
-
-      b. a symmetric encryption key, signed using the KDC's signature
-         key and encrypted using the client's public key.
-
-      Any keying material required by the client to obtain the
-      encryption key for decrypting the KDC reply is returned in a pre-
-      authentication field accompanying the usual reply.
-
-   4. The client validates the KDC's signature, obtains the encryption
-      key, decrypts the reply, and then proceeds as usual.
-
-   Section 3.1 of this document enumerates the required algorithms and
-   necessary extension message types.  Section 3.2 describes the
-   extension messages in greater detail.
-
-3.1.  Definitions, Requirements, and Constants
-
-3.1.1.  Required Algorithms
-
-   All PKINIT implementations MUST support the following algorithms:
-
-
-
-
-
-
-Tung & Zhu               Expires April 22, 2006                 [Page 4]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-   o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
-      sha1-96 [RFC3962].
-
-   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
-
-   o  AS reply key delivery method: Diffie-Hellman key exchange
-      [RFC2631].
-
-   In addition, implementations of this specification MUST be capable of
-   processing the Extended Key Usage (EKU) extension and the id-pkinit-
-   san (as defined in Section 3.2.2) otherName of the Subject
-   Alternative Name (SAN) extension in X.509 certificates [RFC3280], if
-   present.
-
-3.1.2.  Defined Message and Encryption Types
-
-   PKINIT makes use of the following new pre-authentication types:
-
-       PA_PK_AS_REQ                                 16
-       PA_PK_AS_REP                                 17
-
-   PKINIT also makes use of the following new authorization data type:
-
-       AD_INITIAL_VERIFIED_CAS                       9
-
-   PKINIT introduces the following new error codes:
-
-       KDC_ERR_CLIENT_NOT_TRUSTED                   62
-       KDC_ERR_INVALID_SIG                          64
-       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
-       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
-       KDC_ERR_INVALID_CERTIFICATE                  71
-       KDC_ERR_REVOKED_CERTIFICATE                  72
-       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
-       KDC_ERR_CLIENT_NAME_MISMATCH                 75
-       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
-
-   PKINIT uses the following typed data types for errors:
-
-       TD_TRUSTED_CERTIFIERS                       104
-       TD_INVALID_CERTIFICATES                     105
-       TD_DH_PARAMETERS                            109
-
-   PKINIT defines the following encryption types, for use in the etype
-   field of the AS-REQ [RFC4120] message to indicate acceptance of the
-   corresponding algorithms that can used by Cryptographic Message
-   Syntax (CMS) [RFC3852] messages in the reply:
-
-
-
-
-Tung & Zhu               Expires April 22, 2006                 [Page 5]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-       dsaWithSHA1-CmsOID                            9
-          -- Indicates that the client supports dsaWithSHA1
-       md5WithRSAEncryption-CmsOID                  10
-          -- Indicates that the client supports md5WithRSAEncryption
-       sha1WithRSAEncryption-CmsOID                 11
-          -- Indicates that the client supports sha1WithRSAEncryption
-       rc2CBC-EnvOID                                12
-          -- Indicates that the client supports rc2CBC
-       rsaEncryption-EnvOID                         13
-          -- Indicates that the client supports
-          --  rsaEncryption (PKCS1 v2.1)
-       id-RSAES-OAEP-EnvOID                         14
-          -- Indicates that the client supports
-          -- id-RSAES-OAEP (PKCS1 v2.1)
-       des-ede3-cbc-EnvOID                          15
-          -- Indicates that the client supports des-ede3-cbc
-
-   The ASN.1 module for all structures defined in this document (plus
-   IMPORT statements for all imported structures) is given in
-   Appendix A.
-
-   All structures defined in or imported into this document MUST be
-   encoded using Distinguished Encoding Rules (DER) [X680] [X690]
-   (unless otherwise noted).  All data structures carried in OCTET
-   STRINGs must be encoded according to the rules specified in
-   corresponding specifications.
-
-   Interoperability note: Some implementations may not be able to decode
-   wrapped CMS objects encoded with BER but not DER; specifically, they
-   may not be able to decode infinite length encodings.  To maximize
-   interoperability, implementers SHOULD encode CMS objects used in
-   PKINIT with DER.
-
-3.1.3.  Algorithm Identifiers
-
-   PKINIT does not define, but does make use of, the following algorithm
-   identifiers.
-
-   PKINIT uses the following algorithm identifier(s) for Diffie-Hellman
-   key agreement [RFC3279]:
-
-       dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
-
-   PKINIT uses the following signature algorithm identifiers [RFC3279]:
-
-       sha-1WithRSAEncryption (RSA with SHA1)
-       md5WithRSAEncryption   (RSA with MD5)
-       id-dsa-with-sha1       (DSA with SHA1)
-
-
-
-Tung & Zhu               Expires April 22, 2006                 [Page 6]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-   PKINIT uses the following encryption algorithm identifiers [RFC3447]
-   for encrypting the temporary key with a public key:
-
-       rsaEncryption          (PKCS1 v2.1)
-       id-RSAES-OAEP          (PKCS1 v2.1)
-
-   PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
-   for encrypting the AS reply key with the temporary key:
-
-       des-ede3-cbc           (three-key 3DES, CBC mode)
-       rc2-cbc                (RC2, CBC mode)
-       id-aes256-CBC          (AES-256, CBC mode)
-
-3.2.  PKINIT Pre-authentication Syntax and Use
-
-   This section defines the syntax and use of the various pre-
-   authentication fields employed by PKINIT.
-
-3.2.1.  Generation of Client Request
-
-   The initial authentication request (AS-REQ) is sent as per [RFC4120];
-   in addition, a pre-authentication data element, whose padata-type is
-   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
-   type PA-PK-AS-REQ, is included.
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- A list of CAs, trusted by the client, that can
-                   -- be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-
-
-
-Tung & Zhu               Expires April 22, 2006                 [Page 7]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-
-
-
-Tung & Zhu               Expires April 22, 2006                 [Page 8]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so (see Section 3.2.3.1).
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure for the signedAuthPack field is
-   filled out as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is id-pkinit-
-       authData: { iso(1) org(3) dod(6) internet(1) security(5)
-       kerberosv5(2) pkinit(3) authData(1) }.
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type AuthPack.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type AuthPack.
-
-   5.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the KDC can verify the signature over the
-
-
-
-Tung & Zhu               Expires April 22, 2006                 [Page 9]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-       type AuthPack.  For path validation, these certificates SHOULD be
-       sufficient to construct at least one certification path from the
-       client certificate to one trust anchor acceptable by the KDC
-       [CAPATH].  The client MUST be capable of including such a set of
-       certificates if configured to do so.  The certificates field MUST
-       NOT contain "root" CA certificates.
-
-   6.  The client's Diffie-Hellman public value (clientPublicValue) is
-       included if and only if the client wishes to use the Diffie-
-       Hellman key agreement method.  The Diffie-Hellman domain
-       parameters [IEEE1363] for the client's public key are specified
-       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
-       and the client's Diffie-Hellman public key value is mapped to a
-       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
-       using the Diffie-Hellman key agreement method, implementations
-       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
-       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
-       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
-       group 16 [RFC3526].
-
-       The Diffie-Hellman field size should be chosen so as to provide
-       sufficient cryptographic security [RFC3766].
-
-       When MODP Diffie-Hellman is used, the exponents should have at
-       least twice as many bits as the symmetric keys that will be
-       derived from them [ODL99].
-
-   7.  The client may wish to reuse DH keys or to allow the KDC to do so
-       (see Section 3.2.3.1).  If so, then the client includes the
-       clientDHNonce field.  This nonce string needs to be as long as
-       the longest key length of the symmetric key types that the client
-       supports.  This nonce MUST be chosen randomly.
-
-
-3.2.2.  Receipt of Client Request
-
-   Upon receiving the client's request, the KDC validates it.  This
-   section describes the steps that the KDC MUST (unless otherwise
-   noted) take in validating the request.
-
-   The KDC verifies the client's signature in the signedAuthPack field
-   according to [RFC3852].
-
-   If, while validating the client's X.509 certificate [RFC3280], the
-   KDC cannot build a certification path to validate the client's
-   certificate, it sends back a KRB-ERROR [RFC4120] message with the
-   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
-   this error message is a TYPED-DATA (as defined in [RFC4120]) that
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 10]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
-   whose data-value contains the DER encoding of the type TD-TRUSTED-
-   CERTIFIERS:
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   Upon receiving this error message, the client SHOULD retry only if it
-   has a different set of certificates (from those of the previous
-   requests) that form a certification path (or a partial path) from one
-   of the trust anchors acceptable by the KDC to its own certificate.
-
-   If, while processing the certification path, the KDC determines that
-   the signature on one of the certificates in the signedAuthPack field
-   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
-   message is a TYPED-DATA that contains an element whose data-type is
-   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
-   encoding of the type TD-INVALID-CERTIFICATES:
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-   If more than one X.509 certificate signature is invalid, the KDC MAY
-   include one IssuerAndSerialNumber per invalid signature within the
-   TD-INVALID-CERTIFICATES.
-
-   The client's X.509 certificate is validated according to [RFC3280].
-
-   Based on local policy, the KDC may also check whether any X.509
-   certificates in the certification path validating the client's
-   certificate have been revoked.  If any of them have been revoked, the
-   KDC MUST return an error message with the code
-   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
-   revocation status but is unable to do so, it SHOULD return an error
-   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
-   certificate or certificates affected are identified exactly as for
-   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
-
-   Note that the TD_INVALID_CERTIFICATES error data is only used to
-   identify invalid certificates sent by the client in the request.
-
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 11]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-   The client's public key is then used to verify the signature.  If the
-   signature fails to verify, the KDC MUST return an error message with
-   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
-   this error message.
-
-   In addition to validating the client's signature, the KDC MUST also
-   check that the client's public key used to verify the client's
-   signature is bound to the client's principal name as specified in the
-   AS-REQ as follows:
-
-   1. If the KDC has its own binding between either the client's
-      signature-verification public key or the client's certificate and
-      the client's Kerberos principal name, it uses that binding.
-
-   2. Otherwise, if the client's X.509 certificate contains a Subject
-      Alternative Name (SAN) extension carrying a KRB5PrincipalName
-      (defined below) in the otherName field of the type GeneralName
-      [RFC3280], it binds the client's X.509 certificate to that name.
-
-      The type of the otherName field is AnotherName.  The type-id field
-      of the type AnotherName is id-pkinit-san:
-
-       id-pkinit-san OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509SanAN (2) }
-
-      And the value field of the type AnotherName is a
-      KRB5PrincipalName.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-   If the KDC does not have its own binding and there is no
-   KRB5PrincipalName name present in the client's X.509 certificate, or
-   if the Kerberos name in the request does not match the
-   KRB5PrincipalName in the client's X.509 certificate (including the
-   realm name), the KDC MUST return an error message with the code
-   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
-   this error message.
-
-   Even if the certification path is validated and the certificate is
-   mapped to the client's principal name, the KDC may decide not to
-   accept the client's certificate, depending on local policy.
-
-   The KDC MAY require the presence of an Extended Key Usage (EKU)
-   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 12]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-   of the client's X.509 certificate:
-
-       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) keyPurposeClientAuth(4) }
-              -- PKINIT client authentication.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   If this EKU KeyPurposeId is required but it is not present or if the
-   client certificate is restricted not to be used for PKINIT client
-   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
-   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
-   is no accompanying e-data for this error message.  KDCs implementing
-   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
-   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
-   are a large number of X.509 client certificates deployed for use with
-   PKINIT which have this EKU.
-
-   As a matter of local policy, the KDC MAY decide to reject requests on
-   the basis of the absence or presence of other specific EKU OID's.
-
-   If the client's public key is not accepted, the KDC returns an error
-   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.
-
-   The KDC MUST check the timestamp to ensure that the request is not a
-   replay, and that the time skew falls within acceptable limits.  The
-   recommendations for clock skew times in [RFC4120] apply here.  If the
-   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
-   KRB_AP_ERR_SKEW, respectively.
-
-   If the clientPublicValue is filled in, indicating that the client
-   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
-   check to see if the key parameters satisfy its policy.  If they do
-   not, it MUST return an error message with the code
-   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
-   TYPED-DATA that contains an element whose data-type is
-   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
-   the type TD-DH-PARAMETERS:
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-
-   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
-   that the KDC supports in decreasing preference order, from which the
-   client SHOULD pick one to retry the request.
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 13]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
-   KDC does not possess the corresponding key, the KDC MUST ignore the
-   kdcPkId field as if the client did not include one.
-
-   If there is a supportedCMSTypes field in the AuthPack, the KDC must
-   check to see if it supports any of the listed types.  If it supports
-   more than one of the types, the KDC SHOULD use the one listed first.
-   If it does not support any of them, it MUST return an error message
-   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
-
-3.2.3.  Generation of KDC Reply
-
-   Assuming that the client's request has been properly validated, the
-   KDC proceeds as per [RFC4120], except as follows.
-
-   The KDC MUST set the initial flag and include an authorization data
-   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
-   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
-   type AD-INITIAL-VERIFIED-CAS:
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-   containers if the list of CAs satisfies the AS' realm's local policy
-   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
-   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
-   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
-   resulting ticket.  If the list of CAs satisfies the local KDC's
-   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
-   container, otherwise it MAY unwrap the authorization data out of the
-   AD-IF-RELEVANT container.
-
-   Application servers that understand this authorization data type
-   SHOULD apply local policy to determine whether a given ticket bearing
-   such a type *not* contained within an AD-IF-RELEVANT container is
-   acceptable.  (This corresponds to the AP server checking the
-   transited field when the TRANSITED-POLICY-CHECKED flag has not been
-   set [RFC4120].)  If such a data type is contained within an AD-IF-
-   RELEVANT container, AP servers MAY apply local policy to determine
-   whether the authorization data is acceptable.
-
-   A pre-authentication data element, whose padata-type is PA_PK_AS_REP
-   and whose padata-value contains the DER encoding of the type PA-PK-
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 14]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-   AS-REP (defined below), is included in the AS-REP [RFC4120].
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is
-                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-                   -- eContent field contains the DER encoding of the
-                   -- type ReplyKeyPack.
-                   -- ReplyKeyPack is defined in Section 3.2.3.2.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-                   -- present in the KDCDHKeyInfo.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 15]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-                   -- request if DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if DH keys are reused. If
-                   -- this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted. See Section 3.2.3.1.
-          ...
-       }
-
-   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
-   KDC encrypts the reply as usual, but not with the client's long-term
-   key.  Instead, it encrypts it with either a shared key derived from a
-   Diffie-Hellman exchange, or a generated encryption key.  The contents
-   of the PA-PK-AS-REP indicate which key delivery method is used.
-
-   In addition, the lifetime of the ticket returned by the KDC MUST NOT
-   exceed that of the client's public-private key pair.  The ticket
-   lifetime, however, can be shorter than that of the client's public-
-   private key pair.  For the implementations of this specification, the
-   lifetime of the client's public-private key pair is the validity
-   period in X.509 certificates [RFC3280], unless configured otherwise.
-
-3.2.3.1.  Using Diffie-Hellman Key Exchange
-
-   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
-
-   The ContentInfo [RFC3852] structure for the dhSignedData field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is the OID value
-       for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
-       security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type KDCDHKeyInfo.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type
-       KDCDHKeyInfo.
-
-   5.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 16]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-       over the type KDCDHKeyInfo.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may only. be left empty if
-       the KDC public key specified by the kdcPkId field in the PA-PK-
-       AS-REQ was used for signing.  Otherwise, for path validation,
-       these certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [CAPATH].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   6.  If the client included the clientDHNonce field, then the KDC may
-       choose to reuse its DH keys (see Section 3.2.3.1).  If the server
-       reuses DH keys then it MUST include an expiration time in the
-       dhKeyExpiration field.  Past the point of the expiration time,
-       the signature over the type DHRepInfo is considered expired/
-       invalid.  When the server reuses DH keys then it MUST include a
-       serverDHNonce at least as long as the length of keys for the
-       symmetric encryption system used to encrypt the AS reply.  Note
-       that including the serverDHNonce changes how the client and
-       server calculate the key to use to encrypt the reply; see below
-       for details.  The KDC SHOULD NOT reuse DH keys unless the
-       clientDHNonce field is present in the request.
-
-   The AS reply key is derived as follows:
-
-   1. Both the KDC and the client calculate the shared secret value as
-      follows:
-
-      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
-         shared secret value.  DHSharedSecret is the value ZZ as
-         described in Section 2.1.1 of [RFC2631].
-
-      DHSharedSecret is first padded with leading zeros such that the
-      size of DHSharedSecret in octets is the same as that of the
-      modulus, then represented as a string of octets in big-endian
-      order.
-
-      Implementation note: Both the client and the KDC can cache the
-      triple (ya, yb, DHSharedSecret), where ya is the client's public
-      key and yb is the KDC's public key.  If both ya and yb are the
-      same in a later exchange, the cached DHSharedSecret can be used.
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 17]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-   2. Let K be the key-generation seed length [RFC3961] of the AS reply
-      key whose enctype is selected according to [RFC4120].
-
-   3. Define the function octetstring2key() as follows:
-
-           octetstring2key(x) == random-to-key(K-truncate(
-                                    SHA1(0x00 | x) |
-                                    SHA1(0x01 | x) |
-                                    SHA1(0x02 | x) |
-                                    ...
-                                    ))
-
-      where x is an octet string; | is the concatenation operator; 0x00,
-      0x01, 0x02, etc., are each represented as a single octet; random-
-      to-key() is an operation that generates a protocol key from a
-      bitstring of length K; and K-truncate truncates its input to the
-      first K bits.  Both K and random-to-key() are as defined in the
-      kcrypto profile [RFC3961] for the enctype of the AS reply key.
-
-   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
-      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
-      strings.
-
-   5. The AS reply key k is:
-
-           k = octetstring2key(DHSharedSecret | n_c | n_k)
-
-3.2.3.2.  Using Public Key Encryption
-
-   In this case, the PA-PK-AS-REP contains a ContentInfo structure
-   wrapped in an OCTET STRING.  The AS reply key is encrypted in the
-   encKeyPack field, which contains data of type ReplyKeyPack:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 18]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure for the encKeyPack field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-envelopedData
-       (as defined in [RFC3852]), and the content field is an
-       EnvelopedData (as defined in [RFC3852]).
-
-   2.  The contentType field for the type EnvelopedData is id-
-       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
-       pkcs (1) pkcs7 (7) signedData (2) }.
-
-   3.  The eContentType field for the inner type SignedData (when
-       decrypted from the encryptedContent field for the type
-       EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
-       internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
-
-   4.  The eContent field for the inner type SignedData contains the DER
-       encoding of the type ReplyKeyPack.
-
-   5.  The signerInfos field of the inner type SignedData contains a
-       single signerInfo, which contains the signature over the type
-       ReplyKeyPack.
-
-   6.  The certificates field of the inner type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type ReplyKeyPack.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may only be left empty if
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 19]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-       the KDC public key specified by the kdcPkId field in the PA-PK-
-       AS-REQ was used for signing.  Otherwise, for path validation,
-       these certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [CAPATH].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  The recipientInfos field of the type EnvelopedData is a SET which
-       MUST contain exactly one member of type KeyTransRecipientInfo.
-       The encryptedKey of this member contains the temporary key which
-       is encrypted using the client's public key.
-
-   8.  The unprotectedAttrs or originatorInfo fields of the type
-       EnvelopedData MAY be present.
-
-   Implementations of this RSA encryption key delivery method are
-   RECOMMENDED to support for RSA keys at least 2048 bits in size.
-
-3.2.4.  Receipt of KDC Reply
-
-   Upon receipt of the KDC's reply, the client proceeds as follows.  If
-   the PA-PK-AS-REP contains the dhSignedData field, the client derives
-   the AS reply key using the same procedure used by the KDC as defined
-   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
-   field, and the client decrypts and extracts the temporary key in the
-   encryptedKey field of the member KeyTransRecipientInfo, and then uses
-   that as the AS reply key.
-
-   If the public key encryption method is used, the client MUST verify
-   the asChecksum contained in the ReplyKeyPack.
-
-   In either case, the client MUST verify the signature in the
-   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
-   be validated according to [RFC3280].  In addition, unless the client
-   can otherwise verify that the public key used to verify the KDC's
-   signature is bound to the KDC of the target realm, the KDC's X.509
-   certificate MUST contain a Subject Alternative Name extension
-   [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
-   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
-   matches the name of the TGS of the target realm (as defined in
-   Section 7.3 of [RFC4120]).
-
-   Unless the client knows by some other means that the KDC certificate
-   is intended for a Kerberos KDC, the client MUST require that the KDC
-   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
-
-
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 20]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) keyPurposeKdc(5) }
-              -- Signing KDC responses.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   If the KDC certificate contains the Kerberos TGS name encoded as an
-   id-pkinit-san SAN, this certificate is certified by the issuing CA as
-   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
-
-   If all applicable checks are satisfied, the client then decrypts the
-   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
-   and then proceeds as described in [RFC4120].
-
-   Implementation note: CAs issuing KDC certificates SHOULD place all
-   "short" and "fully-qualified" Kerberos realm names of the KDC (one
-   per GeneralName [RFC3280]) into the KDC certificate to allow maximum
-   flexibility.
-
-3.3.  Interoperability Requirements
-
-   The client MUST be capable of sending a set of certificates
-   sufficient to allow the KDC to construct a certification path for the
-   client's certificate, if the correct set of certificates is provided
-   through configuration or policy.
-
-   If the client sends all the X.509 certificates on a certification
-   path to a trust anchor acceptable by the KDC, and the KDC can not
-   verify the client's public key otherwise, the KDC MUST be able to
-   process path validation for the client's certificate based on the
-   certificates in the request.
-
-   The KDC MUST be capable of sending a set of certificates sufficient
-   to allow the client to construct a certification path for the KDC's
-   certificate, if the correct set of certificates is provided through
-   configuration or policy.
-
-   If the KDC sends all the X.509 certificates on a certification path
-   to a trust anchor acceptable by the client, and the client can not
-   verify the KDC's public key otherwise, the client MUST be able to
-   process path validation for the KDC's certificate based on the
-   certificates in the reply.
-
-3.4.  KDC Indication of PKINIT Support
-
-   If pre-authentication is required, but was not present in the
-   request, per [RFC4120] an error message with the code
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 21]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
-   stored in the e-data field of the KRB-ERROR message to specify which
-   pre-authentication mechanisms are acceptable.  The KDC can then
-   indicate the support of PKINIT by including an empty element whose
-   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
-
-   Otherwise if it is required by the KDC's local policy that the client
-   must be pre-authenticated using the pre-authentication mechanism
-   specified in this document, but no PKINIT pre-authentication was
-   present in the request, an error message with the code
-   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
-
-   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
-   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
-   STRING), and clients MUST ignore this and any other value.  Future
-   extensions to this protocol may specify other data to send instead of
-   an empty OCTET STRING.
-
-
-4.  Security Considerations
-
-   Kerberos error messages are not integrity protected, as a result, the
-   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
-   with by an attacker so that the set of domain parameters selected
-   could be either weaker or not mutually preferred.  Local policy can
-   configure sets of domain parameters acceptable locally, or disallow
-   the negotiation of DH domain parameters.
-
-   The symmetric reply key size and Diffie-Hellman field size or RSA
-   modulus size should be chosen so as to provide sufficient
-   cryptographic security [RFC3766].
-
-   When MODP Diffie-Hellman is used, the exponents should have at least
-   twice as many bits as the symmetric keys that will be derived from
-   them [ODL99].
-
-   PKINIT raises certain security considerations beyond those that can
-   be regulated strictly in protocol definitions.  We will address them
-   in this section.
-
-   PKINIT extends the cross-realm model to the public-key
-   infrastructure.  Users of PKINIT must understand security policies
-   and procedures appropriate to the use of Public Key Infrastructures
-   [RFC3280].
-
-   In order to trust a KDC certificate that is certified by a CA as a
-   KDC certificate for a target realm (for example, by asserting the TGS
-   name of that Kerberos realm as an id-pkinit-san SAN and/or
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 22]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
-   as described in Section 3.2.4), the client MUST verify that the KDC
-   certificate's issuing CA is authorized to issue KDC certificates for
-   that target realm.  Otherwise, the binding between the KDC
-   certificate and the KDC of the target realm is not established.
-
-   How to validate this authorization is a matter of local policy.  A
-   way to achieve this is the configuration of specific sets of
-   intermediary CAs and trust anchors, one of which must be on the KDC
-   certificate's certification path [RFC3280]; and for each CA or trust
-   anchor the realms for which it is allowed to issue certificates.
-
-   In addition, if any CA is trusted to issue KDC certificates can also
-   issue other kinds of certificates, then local policy must be able to
-   distinguish between them: for example, it could require that KDC
-   certificates contain the id-pkinit-KPKdc EKU or that the realm be
-   specified with the id-pkinit-san SAN.
-
-   It is the responsibility of the PKI administrators for an
-   organization to ensure that KDC certificates are only issued to KDCs,
-   and that clients can ascertain this using their local policy.
-
-   Standard Kerberos allows the possibility of interactions between
-   cryptosystems of varying strengths; this document adds interactions
-   with public-key cryptosystems to Kerberos.  Some administrative
-   policies may allow the use of relatively weak public keys.  Using
-   such keys to wrap data encrypted under stronger conventional
-   cryptosystems may be inappropriate.
-
-   PKINIT requires keys for symmetric cryptosystems to be generated.
-   Some such systems contain "weak" keys.  For recommendations regarding
-   these weak keys, see [RFC4120].
-
-   PKINIT allows the use of the same RSA key pair for encryption and
-   signing when doing RSA encryption based key delivery.  This is not
-   recommended usage of RSA keys [RFC3447], by using DH based key
-   delivery this is avoided.
-
-   Care should be taken in how certificates are chosen for the purposes
-   of authentication using PKINIT.  Some local policies may require that
-   key escrow be used for certain certificate types.  Deployers of
-   PKINIT should be aware of the implications of using certificates that
-   have escrowed keys for the purposes of authentication.  Because
-   signing only certificates are normally not escrowed, by using DH
-   based key delivery this is avoided.
-
-   PKINIT does not provide for a "return routability" test to prevent
-   attackers from mounting a denial-of-service attack on the KDC by
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 23]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-   causing it to perform unnecessary and expensive public-key
-   operations.  Strictly speaking, this is also true of standard
-   Kerberos, although the potential cost is not as great, because
-   standard Kerberos does not make use of public-key cryptography.  By
-   using DH based key delivery and reusing DH keys, the necessary crypto
-   processing cost per request can be minimized.
-
-   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
-   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
-   be used if the KDC itself vouches for the user's certificate.
-
-
-5.  Acknowledgements
-
-   The following people have made significant contributions to this
-   draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
-   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
-   Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
-   Jaganathan, and Chaskiel M Grundman.
-
-   Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
-   Chris Walstad discovered a binding issue between the AS-REQ and AS-
-   REP in draft -26, the asChecksum field was added as the result.
-
-   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
-   Jonathan Trostle who wrote earlier versions of this document.
-
-   The authors are indebted to the Kerberos working group chair Jeffrey
-   Hutzelman who kept track of various issues and was enormously helpful
-   during the creation of this document.
-
-   Some of the ideas on which this document is based arose during
-   discussions over several years between members of the SAAG, the IETF
-   CAT working group, and the PSRG, regarding integration of Kerberos
-   and SPX.  Some ideas have also been drawn from the DASS system.
-   These changes are by no means endorsed by these groups.  This is an
-   attempt to revive some of the goals of those groups, and this
-   document approaches those goals primarily from the Kerberos
-   perspective.
-
-   Lastly, comments from groups working on similar ideas in DCE have
-   been invaluable.
-
-
-6.  IANA Considerations
-
-   This document has no actions for IANA.
-
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 24]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-7.  References
-
-7.1.  Normative References
-
-   [IEEE1363]
-              IEEE, "Standard Specifications for Public Key 
-              Cryptography", IEEE 1363, 2000.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
-              RFC 2412, November 1998.
-
-   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
-              RFC 2631, June 1999.
-
-   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
-              Algorithms", RFC 3370, August 2002.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
-              Encryption Algorithm in Cryptographic Message Syntax
-              (CMS)", RFC 3565, July 2003.
-
-   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
-              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
-              RFC 3766, April 2004.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 25]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
-              Encryption for Kerberos 5", RFC 3962, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [X.509-97] ITU-T Recommendation X.509: The Directory - Authentication 
-              Framework, 1997.
-                    
-   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 
-              Information technology - Abstract Syntax Notation One 
-              (ASN.1): Specification of basic notation.
-
-   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 
-              Information technology - ASN.1 encoding Rules: Specification 
-              of Basic Encoding Rules (BER), Canonical Encoding Rules 
-              (CER) and Distinguished Encoding Rules (DER).
-
-7.2.  Informative References
-
-   [CAPATH]   RFC-Editor: To be replaced by RFC number for draft-ietf-
-              pkix-certpathbuild.  Work in Progress. 
-
-   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
-              Sizes", Journal of Cryptology 14 (2001) 255-293.
-   
-   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
-              future, Designs, Codes, and Cryptography (1999)". 
-              
-
-Appendix A.  PKINIT ASN.1 Module
-
-       KerberosV5-PK-INIT-SPEC {
-               iso(1) identified-organization(3) dod(6) internet(1)
-               security(5) kerberosV5(2) modules(4) pkinit(5)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       IMPORTS
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 26]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-           SubjectPublicKeyInfo, AlgorithmIdentifier
-               FROM PKIX1Explicit88 { iso (1)
-                 identified-organization (3) dod (6) internet (1)
-                 security (5) mechanisms (5) pkix (7) id-mod (0)
-                 id-pkix1-explicit (18) }
-                 -- As defined in RFC 3280.
-
-           KerberosTime, PrincipalName, Realm, EncryptionKey
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) } ;
-
-       id-pkinit OBJECT IDENTIFIER ::=
-         { iso (1) org (3) dod (6) internet (1) security (5)
-           kerberosv5 (2) pkinit (3) }
-
-       id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-       id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-       id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-       id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-       id-pkinit-KPKdc         OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-       id-pkinit-san OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509SanAN (2) }
-
-       pa-pk-as-req INTEGER ::=                  16
-       pa-pk-as-rep INTEGER ::=                  17
-
-       ad-initial-verified-cas INTEGER ::=        9
-
-       td-trusted-certifiers INTEGER ::=        104
-       td-invalid-certificates INTEGER ::=      105
-       td-dh-parameters INTEGER ::=             109
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 27]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- A list of CAs, trusted by the client, that can
-                   -- be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 28]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so.
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 29]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-                   -- signature.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is
-                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-                   -- eContent field contains the DER encoding of the
-                   -- type ReplyKeyPack.
-                   -- ReplyKeyPack is defined below.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 30]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-                   -- present.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-           nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the PKAuthenticator of the
-                   -- request if DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if DH keys are reused. If
-                   -- this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-       END
-
-
-
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 31]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-Appendix B.  Test Vectors
-
-   Function octetstring2key() is defined in Section 3.2.3.1.  This
-   section describes a few sets of test vectors that would be useful for
-   implementers of octetstring2key().
-
-
-   Set 1
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
-     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
-
-
-   Set 2:
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 32]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
-     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
-
-
-   Set 3:
-   ======
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
-     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
-     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
-     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
-     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
-
-
-   Set 4:
-   =====
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
-     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
-
-
-Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
-             Implementations
-
-   Earlier revisions of the PKINIT I-D were implemented in various
-   releases of Microsoft Windows and deployed in fairly large numbers.
-   To enable the community to better interoperate with systems running
-   those releases, the following information may be useful.
-
-   KDC certificates issued by Windows 2000 Enterprise CAs contain a
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 33]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-   dNSName SAN with the DNS name of the host running the KDC, and the
-   id-kp-serverAuth EKU [RFC3280].
-
-   KDC certificates issued by Windows 2003 Enterprise CAs contain a
-   dNSName SAN with the DNS name of the host running the KDC, the id-kp-
-   serverAuth EKU and the id-ms-kp-sc-logon EKU.
-
-   It is anticipated that the next release of Windows is already too far
-   along to allow it to support the issuing KDC certificates with id-
-   pkinit-san SAN as specified in this RFC.  Instead, they will have a
-   dNSName SAN containing the domain name of the KDC and the intended
-   purpose of these KDC certificates be restricted by the presence of
-   the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
-
-   In addition to checking that the above are present in a KDC
-   certificate, Windows clients verify that the issuer of the KDC
-   certificate is one of a set of allowed issuers of such certificates,
-   so those wishing to issue KDC certificates need to configure their
-   Windows clients appropriately.
-
-   Client certificates accepted by Windows 2000 and Windows 2003 Server
-   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
-   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
-   contains a UTF8 encoded string whose value is that of the Directory
-   Service attribute UserPrincipalName of the client account object, and
-   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
-   certificate is to validate the client mapping (in other words, the
-   client's public key is bound to the account that has this
-   UserPrincipalName value).
-
-   It should be noted that all Microsoft Kerberos realm names are domain
-   style realm names and strictly in upper case.  In addition, the
-   UserPrincipalName attribute is globally unique in Windows 2000 and
-   Windows 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 34]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-Authors' Addresses
-
-   Brian Tung
-   USC Information Sciences Institute
-   4676 Admiralty Way Suite 1001
-   Marina del Rey, CA  90292
-   US
-
-   Email: brian@isi.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 35]
-
-Internet-Draft                   PKINIT                     October 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Tung & Zhu               Expires April 22, 2006                [Page 36]
-
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-30.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-30.txt
deleted file mode 100644
index ca5205a65..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-30.txt
+++ /dev/null
@@ -1,2183 +0,0 @@
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                     Microsoft Corporation
-Expires: June 2, 2006                                            B. Tung
-                                      USC Information Sciences Institute
-                                                       November 29, 2005
-
-
-     Public Key Cryptography for Initial Authentication in Kerberos
-                   draft-ietf-cat-kerberos-pk-init-30
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on June 2, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes protocol extensions (hereafter called PKINIT)
-   to the Kerberos protocol specification.  These extensions provide a
-   method for integrating public key cryptography into the initial
-   authentication exchange, by using asymmetric-key signature and/or
-   encryption algorithms in pre-authentication data fields.
-
-
-
-
-
-Zhu & Tung                Expires June 2, 2006                  [Page 1]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  Definitions, Requirements, and Constants . . . . . . . . .  5
-       3.1.1.  Required Algorithms  . . . . . . . . . . . . . . . . .  5
-       3.1.2.  Defined Message and Encryption Types . . . . . . . . .  5
-       3.1.3.  Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
-     3.2.  PKINIT Pre-authentication Syntax and Use . . . . . . . . .  7
-       3.2.1.  Generation of Client Request . . . . . . . . . . . . .  7
-       3.2.2.  Receipt of Client Request  . . . . . . . . . . . . . . 12
-       3.2.3.  Generation of KDC Reply  . . . . . . . . . . . . . . . 16
-       3.2.4.  Receipt of KDC Reply . . . . . . . . . . . . . . . . . 22
-     3.3.  Interoperability Requirements  . . . . . . . . . . . . . . 24
-     3.4.  KDC Indication of PKINIT Support . . . . . . . . . . . . . 24
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
-   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 28
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 29
-   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 29
-   Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 35
-   Appendix C.  Miscellaneous Information about Microsoft Windows
-                PKINIT Implementations  . . . . . . . . . . . . . . . 36
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
-   Intellectual Property and Copyright Statements . . . . . . . . . . 39
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                Expires June 2, 2006                  [Page 2]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-1.  Introduction
-
-   A client typically authenticates itself to a service in Kerberos
-   using three distinct though related exchanges.  First, the client
-   requests a ticket-granting ticket (TGT) from the Kerberos
-   authentication server (AS).  Then, it uses the TGT to request a
-   service ticket from the Kerberos ticket-granting server (TGS).
-   Usually, the AS and TGS are integrated in a single device known as a
-   Kerberos Key Distribution Center, or KDC.  Finally, the client uses
-   the service ticket to authenticate itself to the service.
-
-   The advantage afforded by the TGT is that the client exposes his
-   long-term secrets only once.  The TGT and its associated session key
-   can then be used for any subsequent service ticket requests.  One
-   result of this is that all further authentication is independent of
-   the method by which the initial authentication was performed.
-   Consequently, initial authentication provides a convenient place to
-   integrate public-key cryptography into Kerberos authentication.
-
-   As defined in [RFC4120], Kerberos authentication exchanges use
-   symmetric-key cryptography, in part for performance.  One
-   disadvantage of using symmetric-key cryptography is that the keys
-   must be shared, so that before a client can authenticate itself, he
-   must already be registered with the KDC.
-
-   Conversely, public-key cryptography (in conjunction with an
-   established Public Key Infrastructure) permits authentication without
-   prior registration with a KDC.  Adding it to Kerberos allows the
-   widespread use of Kerberized applications by clients without
-   requiring them to register first with a KDC--a requirement that has
-   no inherent security benefit.
-
-   As noted above, a convenient and efficient place to introduce public-
-   key cryptography into Kerberos is in the initial authentication
-   exchange.  This document describes the methods and data formats for
-   integrating public-key cryptography into Kerberos initial
-   authentication.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   Both the AS and the TGS are referred to as the KDC.
-
-   In this document, the encryption key used to encrypt the enc-part
-
-
-
-Zhu & Tung                Expires June 2, 2006                  [Page 3]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-   field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
-   reply key.
-
-   In this document, an empty sequence in an optional field can be
-   either included or omitted: both encodings are permitted and
-   considered equivalent.
-
-   In this document, the term "Modular Exponential Diffie-Hellman" is
-   used to refer to the Diffie-Hellman key exchange as described in
-   [RFC2631], in order to differentiate it from other equivalent
-   representations of the same key agreement algorithm.
-
-
-3.  Extensions
-
-   This section describes extensions to [RFC4120] for supporting the use
-   of public-key cryptography in the initial request for a ticket.
-
-   Briefly, this document defines the following extensions to [RFC4120]:
-
-   1. The client indicates the use of public-key authentication by
-      including a special preauthenticator in the initial request.  This
-      preauthenticator contains the client's public-key data and a
-      signature.
-
-   2. The KDC tests the client's request against its authentication
-      policy and trusted Certification Authorities (CAs).
-
-   3. If the request passes the verification tests, the KDC replies as
-      usual, but the reply is encrypted using either:
-
-      a. a key generated through a Diffie-Hellman (DH) key exchange
-         [RFC2631] [IEEE1363] with the client, signed using the KDC's
-         signature key; or
-
-      b. a symmetric encryption key, signed using the KDC's signature
-         key and encrypted using the client's public key.
-
-      Any keying material required by the client to obtain the
-      encryption key for decrypting the KDC reply is returned in a pre-
-      authentication field accompanying the usual reply.
-
-   4. The client validates the KDC's signature, obtains the encryption
-      key, decrypts the reply, and then proceeds as usual.
-
-   Section 3.1 of this document enumerates the required algorithms and
-   necessary extension message types.  Section 3.2 describes the
-   extension messages in greater detail.
-
-
-
-Zhu & Tung                Expires June 2, 2006                  [Page 4]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-3.1.  Definitions, Requirements, and Constants
-
-3.1.1.  Required Algorithms
-
-   All PKINIT implementations MUST support the following algorithms:
-
-   o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
-      sha1-96 [RFC3962].
-
-   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
-
-   o  AS reply key delivery method: Diffie-Hellman key exchange
-      [RFC2631].
-
-   In addition, implementations of this specification MUST be capable of
-   processing the Extended Key Usage (EKU) extension and the id-pkinit-
-   san (as defined in Section 3.2.2) otherName of the Subject
-   Alternative Name (SAN) extension in X.509 certificates [RFC3280], if
-   present.
-
-3.1.2.  Defined Message and Encryption Types
-
-   PKINIT makes use of the following new pre-authentication types:
-
-       PA_PK_AS_REQ                                 16
-       PA_PK_AS_REP                                 17
-
-   PKINIT also makes use of the following new authorization data type:
-
-       AD_INITIAL_VERIFIED_CAS                       9
-
-   PKINIT introduces the following new error codes:
-
-       KDC_ERR_CLIENT_NOT_TRUSTED                   62
-       KDC_ERR_INVALID_SIG                          64
-       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
-       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
-       KDC_ERR_INVALID_CERTIFICATE                  71
-       KDC_ERR_REVOKED_CERTIFICATE                  72
-       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
-       KDC_ERR_CLIENT_NAME_MISMATCH                 75
-       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
-       KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED          77
-       KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED             78
-       KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED   79
-
-   PKINIT uses the following typed data types for errors:
-
-
-
-
-Zhu & Tung                Expires June 2, 2006                  [Page 5]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-       TD_TRUSTED_CERTIFIERS                       104
-       TD_INVALID_CERTIFICATES                     105
-       TD_DH_PARAMETERS                            109
-
-   The ASN.1 module for all structures defined in this document (plus
-   IMPORT statements for all imported structures) is given in
-   Appendix A.
-
-   All structures defined in or imported into this document MUST be
-   encoded using Distinguished Encoding Rules (DER) [X680] [X690]
-   (unless otherwise noted).  All data structures carried in OCTET
-   STRINGs must be encoded according to the rules specified in
-   corresponding specifications.
-
-   Interoperability note: Some implementations may not be able to decode
-   wrapped CMS objects encoded with BER but not DER; specifically, they
-   may not be able to decode indefinite length encodings.  To maximize
-   interoperability, implementers SHOULD encode CMS objects used in
-   PKINIT with DER.
-
-3.1.3.  Algorithm Identifiers
-
-   PKINIT does not define, but does make use of, the following algorithm
-   identifiers.
-
-   PKINIT uses the following algorithm identifier(s) for Modular
-   Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]:
-
-       dhpublicnumber (as described in [RFC3279])
-
-   PKINIT uses the following signature algorithm identifiers as defined
-   in [RFC3279]:
-
-       sha-1WithRSAEncryption (RSA with SHA1)
-       md5WithRSAEncryption   (RSA with MD5)
-       id-dsa-with-sha1       (DSA with SHA1)
-
-   PKINIT uses the following encryption algorithm identifiers as defined
-   in [RFC3447] for encrypting the temporary key with a public key:
-
-       rsaEncryption
-       id-RSAES-OAEP
-
-   PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
-   for encrypting the AS reply key with the temporary key:
-
-       des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370])
-       rc2-cbc       (RC2, CBC mode, as defined in [RFC3370])
-
-
-
-Zhu & Tung                Expires June 2, 2006                  [Page 6]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-       id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565])
-
-   PKINIT defines the following encryption types, for use in the etype
-   field of the AS-REQ [RFC4120] message to indicate acceptance of the
-   corresponding algorithms that can used by Cryptographic Message
-   Syntax (CMS) [RFC3852] messages in the reply:
-
-       id-dsa-with-sha1-CmsOID                       9
-          -- Indicates that the client supports id-dsa-with-sha1.
-       md5WithRSAEncryption-CmsOID                  10
-          -- Indicates that the client supports md5WithRSAEncryption.
-       sha-1WithRSAEncryption-CmsOID                11
-          -- Indicates that the client supports sha-1WithRSAEncryption.
-       rc2-cbc-EnvOID                               12
-          -- Indicates that the client supports rc2-cbc.
-       rsaEncryption-EnvOID                         13
-          -- Indicates that the client supports rsaEncryption.
-       id-RSAES-OAEP-EnvOID                         14
-          -- Indicates that the client supports id-RSAES-OAEP.
-       des-ede3-cbc-EnvOID                          15
-          -- Indicates that the client supports des-ede3-cbc.
-
-3.2.  PKINIT Pre-authentication Syntax and Use
-
-   This section defines the syntax and use of the various pre-
-   authentication fields employed by PKINIT.
-
-3.2.1.  Generation of Client Request
-
-   The initial authentication request (AS-REQ) is sent as per [RFC4120];
-   in addition, a pre-authentication data element, whose padata-type is
-   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
-   type PA-PK-AS-REQ, is included.
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-
-
-
-Zhu & Tung                Expires June 2, 2006                  [Page 7]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-                   -- Contains a list of CAs, trusted by the client,
-                   -- that can be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-
-
-
-Zhu & Tung                Expires June 2, 2006                  [Page 8]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so (see Section 3.2.3.1).
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure contained in the signedAuthPack
-   field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
-   is filled out as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is id-pkinit-
-       authData: { iso(1) org(3) dod(6) internet(1) security(5)
-       kerberosv5(2) pkinit(3) authData(1) }.  Notes to CMS
-
-
-
-Zhu & Tung                Expires June 2, 2006                  [Page 9]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-       implementers: the signed attribute content-type MUST be present
-       in this SignedData instance and its value is id-pkinit-authData
-       according to [RFC3852].
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type AuthPack.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type AuthPack.
-
-   5.  The AuthPack structure contains a PKAuthenticator, the client
-       public key information, the CMS encryption types supported by the
-       client and a DHNonce.  The pkAuthenticator field certifies to the
-       KDC that the client has recent knowledge of the signing key that
-       authenticates the client.  The clientPublicValue field specifies
-       Diffie-Hellman domain parameters and the client's public key
-       value.  The DH public key value is encoded as a BIT STRING
-       according to [RFC3279].  The clientPublicValue field is present
-       only if the client wishes to use the Diffie-Hellman key agreement
-       method.  The supportedCMSTypes field specifies the list of CMS
-       encryption types supported by the client in order of (decreasing)
-       preference.  The clientDHNonce field is described later in this
-       section.
-
-   6.  The ctime field in the PKAuthenticator structure contains the
-       current time on the client's host, and the cusec field contains
-       the microsecond part of the client's timestamp.  The ctime and
-       cusec fields are used together to specify a reasonably accurate
-       timestamp [RFC4120].  The nonce field is chosen randomly.  The
-       paChecksum field contains a SHA1 checksum that is performed over
-       the KDC-REQ-BODY [RFC4120].
-
-   7.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the KDC can verify the signature over the
-       type AuthPack.  For path validation, these certificates SHOULD be
-       sufficient to construct at least one certification path from the
-       client certificate to one trust anchor acceptable by the KDC
-       [RFC4158].  The client MUST be capable of including such a set of
-       certificates if configured to do so.  The certificates field MUST
-       NOT contain "root" CA certificates.
-
-   8.  The client's Diffie-Hellman public value (clientPublicValue) is
-       included if and only if the client wishes to use the Diffie-
-       Hellman key agreement method.  The Diffie-Hellman domain
-       parameters [IEEE1363] for the client's public key are specified
-       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
-       and the client's Diffie-Hellman public key value is mapped to a
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 10]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
-       using the Diffie-Hellman key agreement method, implementations
-       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
-       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
-       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
-       group 16 [RFC3526].
-
-       The Diffie-Hellman field size should be chosen so as to provide
-       sufficient cryptographic security [RFC3766].
-
-       When MODP Diffie-Hellman is used, the exponents should have at
-       least twice as many bits as the symmetric keys that will be
-       derived from them [ODL99].
-
-   9.  The client may wish to reuse DH keys or to allow the KDC to do so
-       (see Section 3.2.3.1).  If so, then the client includes the
-       clientDHNonce field.  This nonce string MUST be as long as the
-       longest key length of the symmetric key types that the client
-       supports.  This nonce MUST be chosen randomly.
-
-   The ExternalPrincipalIdentifier structure is used in this document to
-   identify the subject's public key thereby the subject principal.
-   This structure is filled out as follows:
-
-   1.  The subjectName field contains a PKIX type Name encoded according
-       to [RFC3280].  This field identifies the certificate subject by
-       the distinguished subject name.  This field is REQUIRED when
-       there is a distinguished subject name present in the certificate
-       being used.
-
-   2.  The issuerAndSerialNumber field contains a CMS type
-       IssuerAndSerialNumber encoded according to [RFC3852].  This field
-       identifies a certificate of the subject.  This field is REQUIRED
-       for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
-       structures are defined in Section 3.2.2).
-
-   3.  The subjectKeyIdentifier [RFC3852] field identifies the subject's
-       public key by a key identifier.  When an X.509 certificate is
-       referenced, this key identifier matches the X.509
-       subjectKeyIdentifier extension value.  When other certificate
-       formats are referenced, the documents that specify the
-       certificate format and their use with the CMS must include
-       details on matching the key identifier to the appropriate
-       certificate field.  This field is RECOMMENDED for TD-TRUSTED-
-       CERTIFIERS (as defined in Section 3.2.2).
-
-   The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
-   of CAs, trusted by the client, that can be used to certify the KDC.
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 11]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-   Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
-   (thereby its public key).
-
-   The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
-   SignerIdentifier encoded according to [RFC3852].  This field
-   identifies, if present, a particular KDC public key that the client
-   already has.
-
-3.2.2.  Receipt of Client Request
-
-   Upon receiving the client's request, the KDC validates it.  This
-   section describes the steps that the KDC MUST (unless otherwise
-   noted) take in validating the request.
-
-   The KDC verifies the client's signature in the signedAuthPack field
-   according to [RFC3852].
-
-   If, while validating the client's X.509 certificate [RFC3280], the
-   KDC cannot build a certification path to validate the client's
-   certificate, it sends back a KRB-ERROR [RFC4120] message with the
-   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
-   this error message is a TYPED-DATA (as defined in [RFC4120]) that
-   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
-   whose data-value contains the DER encoding of the type TD-TRUSTED-
-   CERTIFIERS:
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
-   TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
-   (thereby its public key) trusted by the KDC.
-
-   Upon receiving this error message, the client SHOULD retry only if it
-   has a different set of certificates (from those of the previous
-   requests) that form a certification path (or a partial path) from one
-   of the trust anchors acceptable by the KDC to its own certificate.
-
-   If, while processing the certification path, the KDC determines that
-   the signature on one of the certificates in the signedAuthPack field
-   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
-   message is a TYPED-DATA that contains an element whose data-type is
-   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
-   encoding of the type TD-INVALID-CERTIFICATES:
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 12]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
-   TD-INVALID-CERTIFICATES structure identifies a certificate (that was
-   sent by the client) with an invalid signature.
-
-   If more than one X.509 certificate signature is invalid, the KDC MAY
-   include one IssuerAndSerialNumber per invalid signature within the
-   TD-INVALID-CERTIFICATES.
-
-   The client's X.509 certificate is validated according to [RFC3280].
-
-   Based on local policy, the KDC may also check whether any X.509
-   certificates in the certification path validating the client's
-   certificate have been revoked.  If any of them have been revoked, the
-   KDC MUST return an error message with the code
-   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
-   revocation status but is unable to do so, it SHOULD return an error
-   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
-   certificate or certificates affected are identified exactly as for
-   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
-
-   Note that the TD_INVALID_CERTIFICATES error data is only used to
-   identify invalid certificates sent by the client in the request.
-
-   The client's public key is then used to verify the signature.  If the
-   signature fails to verify, the KDC MUST return an error message with
-   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
-   this error message.
-
-   In addition to validating the client's signature, the KDC MUST also
-   check that the client's public key used to verify the client's
-   signature is bound to the client's principal name as specified in the
-   AS-REQ as follows:
-
-   1. If the KDC has its own binding between either the client's
-      signature-verification public key or the client's certificate and
-      the client's Kerberos principal name, it uses that binding.
-
-   2. Otherwise, if the client's X.509 certificate contains a Subject
-      Alternative Name (SAN) extension carrying a KRB5PrincipalName
-      (defined below) in the otherName field of the type GeneralName
-      [RFC3280], it binds the client's X.509 certificate to that name.
-
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 13]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-      The type of the otherName field is AnotherName.  The type-id field
-      of the type AnotherName is id-pkinit-san:
-
-       id-pkinit-san OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509SanAN (2) }
-
-      And the value field of the type AnotherName is a
-      KRB5PrincipalName.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-   If the KDC does not have its own binding and there is no
-   KRB5PrincipalName name present in the client's X.509 certificate, or
-   if the Kerberos name in the request does not match the
-   KRB5PrincipalName in the client's X.509 certificate (including the
-   realm name), the KDC MUST return an error message with the code
-   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
-   this error message.
-
-   Even if the certification path is validated and the certificate is
-   mapped to the client's principal name, the KDC may decide not to
-   accept the client's certificate, depending on local policy.
-
-   The KDC MAY require the presence of an Extended Key Usage (EKU)
-   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
-   of the client's X.509 certificate:
-
-       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) keyPurposeClientAuth(4) }
-              -- PKINIT client authentication.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   The digitalSignature key usage bit MUST be asserted when the intended
-   purpose of the client certificate is restricted with the id-pkinit-
-   KPClientAuth EKU.
-
-   If this EKU KeyPurposeId is required but it is not present or if the
-   client certificate is restricted not to be used for PKINIT client
-   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
-   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
-   is no accompanying e-data for this error message.  KDCs implementing
-   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 14]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
-   are a large number of X.509 client certificates deployed for use with
-   PKINIT which have this EKU.
-
-   As a matter of local policy, the KDC MAY decide to reject requests on
-   the basis of the absence or presence of other specific EKU OID's.
-
-   If the digest algorithm used in generating the CA signature for the
-   public key in any certificate of the request is not acceptable by the
-   KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED.  The accompanying e-data MUST be
-   encoded in TYPED-DATA although none is defined at this point.
-
-   If the client's public key is not accepted with reasons other than
-   what were specified above, the KDC returns a KRB-ERROR [RFC4120]
-   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.  There is no
-   accompanying e-data currently defined for this error message.
-
-   The KDC MUST check the timestamp to ensure that the request is not a
-   replay, and that the time skew falls within acceptable limits.  The
-   recommendations for clock skew times in [RFC4120] apply here.  If the
-   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
-   KRB_AP_ERR_SKEW, respectively.
-
-   If the clientPublicValue is filled in, indicating that the client
-   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
-   check to see if the key parameters satisfy its policy.  If they do
-   not, it MUST return an error message with the code
-   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
-   TYPED-DATA that contains an element whose data-type is
-   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
-   the type TD-DH-PARAMETERS:
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-
-   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
-   that the KDC supports in decreasing preference order, from which the
-   client SHOULD pick one to retry the request.
-
-   The AlgorithmIdentifier structure is defined in [RFC3280] and is
-   filled in according to [RFC3279].  More specifically Section 2.3.3 of
-   [RFC3279] describes how to fill in the AlgorithmIdentifier structure
-   in the case where MODP Diffie-Hellman key exchange is used.
-
-   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 15]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-   KDC does not possess the corresponding key, the KDC MUST ignore the
-   kdcPkId field as if the client did not include one.
-
-   If the digest algorithm used by the id-pkinit-authData is not
-   acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
-   message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
-   The accompanying e-data MUST be encoded in TYPED-DATA although none
-   is defined at this point.
-
-3.2.3.  Generation of KDC Reply
-
-   Assuming that the client's request has been properly validated, the
-   KDC proceeds as per [RFC4120], except as follows.
-
-   The KDC MUST set the initial flag and include an authorization data
-   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
-   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
-   type AD-INITIAL-VERIFIED-CAS:
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   The AD-INITIAL-VERIFIED-CAS structure identifies the certification
-   path based on which the client certificate was validated.  Each
-   ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
-   INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
-   (thereby its public key).
-
-   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-   containers if the list of CAs satisfies the AS' realm's local policy
-   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
-   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
-   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
-   resulting ticket.  If the list of CAs satisfies the local KDC's
-   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
-   container, otherwise it MAY unwrap the authorization data out of the
-   AD-IF-RELEVANT container.
-
-   Application servers that understand this authorization data type
-   SHOULD apply local policy to determine whether a given ticket bearing
-   such a type *not* contained within an AD-IF-RELEVANT container is
-   acceptable.  (This corresponds to the AP server checking the
-   transited field when the TRANSITED-POLICY-CHECKED flag has not been
-   set [RFC4120].)  If such a data type is contained within an AD-IF-
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 16]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-   RELEVANT container, AP servers MAY apply local policy to determine
-   whether the authorization data is acceptable.
-
-   A pre-authentication data element, whose padata-type is PA_PK_AS_REP
-   and whose padata-value contains the DER encoding of the type PA-PK-
-   AS-REP (defined below), is included in the AS-REP [RFC4120].
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is
-                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-                   -- eContent field contains the DER encoding of the
-                   -- type ReplyKeyPack.
-                   -- ReplyKeyPack is defined in Section 3.2.3.2.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-                   -- present in the KDCDHKeyInfo.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 17]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-                   -- The KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the pkAuthenticator field
-                   -- in the request if the DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if the DH keys are reused.
-                   -- If present, the KDC's DH public key MUST not be
-                   -- used past the point of this expiration time.
-                   -- If this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
-   KDC encrypts the reply as usual, but not with the client's long-term
-   key.  Instead, it encrypts it with either a shared key derived from a
-   Diffie-Hellman exchange, or a generated encryption key.  The contents
-   of the PA-PK-AS-REP indicate which key delivery method is used.
-
-   In addition, the lifetime of the ticket returned by the KDC MUST NOT
-   exceed that of the client's public-private key pair.  The ticket
-   lifetime, however, can be shorter than that of the client's public-
-   private key pair.  For the implementations of this specification, the
-   lifetime of the client's public-private key pair is the validity
-   period in X.509 certificates [RFC3280], unless configured otherwise.
-
-3.2.3.1.  Using Diffie-Hellman Key Exchange
-
-   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
-
-   The ContentInfo [RFC3852] structure for the dhSignedData field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is the OID value
-       for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
-       security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.  Notes to CMS
-       implementers: the signed attribute content-type MUST be present
-       in this SignedData instance and its value is id-pkinit-DHKeyData
-       according to [RFC3852].
-
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 18]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type KDCDHKeyInfo.
-
-   4.  The KDCDHKeyInfo structure contains the KDC's public key, a nonce
-       and optionally the expiration time of the KDC's DH key being
-       reused.  The subjectPublicKey field of the type KDCDHKeyInfo
-       field identifies KDC's DH public key.  This DH public key value
-       is encoded as a BIT STRING according to [RFC3279].  The nonce
-       field contains the nonce in the pkAuthenticator field in the
-       request if the DH keys are NOT reused.  The value of this nonce
-       field is 0 if the DH keys are reused.  The dhKeyExpiration field
-       is present if and only if the DH keys are reused.  If the
-       dhKeyExpiration field is present, the KDC's public key in this
-       KDCDHKeyInfo structure MUST NOT be used past the point of this
-       expiration time.  If this field is omitted then the serverDHNonce
-       field MUST also be omitted.
-
-   5.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type
-       KDCDHKeyInfo.
-
-   6.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type KDCDHKeyInfo.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may be left empty if the KDC
-       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
-       used for signing.  Otherwise, for path validation, these
-       certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [RFC4158].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  If the client included the clientDHNonce field, then the KDC may
-       choose to reuse its DH keys (see Section 3.2.3.1).  If the server
-       reuses DH keys then it MUST include an expiration time in the
-       dhKeyExpiration field.  Past the point of the expiration time,
-       the signature over the type DHRepInfo is considered expired/
-       invalid.  When the server reuses DH keys then it MUST include a
-       serverDHNonce at least as long as the length of keys for the
-       symmetric encryption system used to encrypt the AS reply.  Note
-       that including the serverDHNonce changes how the client and
-       server calculate the key to use to encrypt the reply; see below
-       for details.  The KDC SHOULD NOT reuse DH keys unless the
-       clientDHNonce field is present in the request.
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 19]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-   The AS reply key is derived as follows:
-
-   1. Both the KDC and the client calculate the shared secret value as
-      follows:
-
-      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
-         shared secret value.  DHSharedSecret is the value ZZ as
-         described in Section 2.1.1 of [RFC2631].
-
-      DHSharedSecret is first padded with leading zeros such that the
-      size of DHSharedSecret in octets is the same as that of the
-      modulus, then represented as a string of octets in big-endian
-      order.
-
-      Implementation note: Both the client and the KDC can cache the
-      triple (ya, yb, DHSharedSecret), where ya is the client's public
-      key and yb is the KDC's public key.  If both ya and yb are the
-      same in a later exchange, the cached DHSharedSecret can be used.
-
-   2. Let K be the key-generation seed length [RFC3961] of the AS reply
-      key whose enctype is selected according to [RFC4120].
-
-   3. Define the function octetstring2key() as follows:
-
-           octetstring2key(x) == random-to-key(K-truncate(
-                                    SHA1(0x00 | x) |
-                                    SHA1(0x01 | x) |
-                                    SHA1(0x02 | x) |
-                                    ...
-                                    ))
-
-      where x is an octet string; | is the concatenation operator; 0x00,
-      0x01, 0x02, etc., are each represented as a single octet; random-
-      to-key() is an operation that generates a protocol key from a
-      bitstring of length K; and K-truncate truncates its input to the
-      first K bits.  Both K and random-to-key() are as defined in the
-      kcrypto profile [RFC3961] for the enctype of the AS reply key.
-
-   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
-      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
-      strings.
-
-   5. The AS reply key k is:
-
-           k = octetstring2key(DHSharedSecret | n_c | n_k)
-
-   If the hash algorithm used in the key derivation function (currently
-   only octetstring2key() is defined) is not acceptable by the KDC, the
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 20]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-   KDC MUST return a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED.  The accompanying e-data MUST be
-   encoded in TYPED-DATA although none is defined at this point.
-
-3.2.3.2.  Using Public Key Encryption
-
-   In this case, the PA-PK-AS-REP contains an encKeyPack structure where
-   the AS reply key is encrypted.
-
-   The ContentInfo [RFC3852] structure for the encKeyPack field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-envelopedData
-       (as defined in [RFC3852]), and the content field is an
-       EnvelopedData (as defined in [RFC3852]).
-
-   2.  The contentType field for the type EnvelopedData is id-
-       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
-       pkcs (1) pkcs7 (7) signedData (2) }.
-
-   3.  The eContentType field for the inner type SignedData (when
-       decrypted from the encryptedContent field for the type
-       EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
-       internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
-       Notes to CMS implementers: the signed attribute content-type MUST
-       be present in this SignedData instance and its value is id-
-       pkinit-rkeyData according to [RFC3852].
-
-   4.  The eContent field for the inner type SignedData contains the DER
-       encoding of the type ReplyKeyPack (as described below).
-
-   5.  The signerInfos field of the inner type SignedData contains a
-       single signerInfo, which contains the signature for the type
-       ReplyKeyPack.
-
-   6.  The certificates field of the inner type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       for the type ReplyKeyPack.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may be left empty if the KDC
-       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
-       used for signing.  Otherwise, for path validation, these
-       certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [RFC4158].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 21]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  The recipientInfos field of the type EnvelopedData is a SET which
-       MUST contain exactly one member of type KeyTransRecipientInfo.
-       The encryptedKey of this member contains the temporary key which
-       is encrypted using the client's public key.
-
-   8.  The unprotectedAttrs or originatorInfo fields of the type
-       EnvelopedData MAY be present.
-
-   If there is a supportedCMSTypes field in the AuthPack, the KDC must
-   check to see if it supports any of the listed types.  If it supports
-   more than one of the types, the KDC SHOULD use the one listed first.
-   If it does not support any of them, it MUST return an error message
-   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
-
-   Furthermore the KDC computes the checksum of the AS-REQ in the client
-   request.  This checksum is performed over the type AS-REQ and the
-   protocol key [RFC3961] of the checksum operation is the replyKey and
-   the key usage number is 6.  If the replyKey's enctype is "newer"
-   [RFC4120] [RFC4121], the checksum operation is the required checksum
-   operation [RFC3961] of that enctype.
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP, i.e. the
-                   -- AS reply key.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-   Implementations of this RSA encryption key delivery method are
-   RECOMMENDED to support RSA keys at least 2048 bits in size.
-
-3.2.4.  Receipt of KDC Reply
-
-   Upon receipt of the KDC's reply, the client proceeds as follows.  If
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 22]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-   the PA-PK-AS-REP contains the dhSignedData field, the client derives
-   the AS reply key using the same procedure used by the KDC as defined
-   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
-   field, and the client decrypts and extracts the temporary key in the
-   encryptedKey field of the member KeyTransRecipientInfo, and then uses
-   that as the AS reply key.
-
-   If the public key encryption method is used, the client MUST verify
-   the asChecksum contained in the ReplyKeyPack.
-
-   In either case, the client MUST verify the signature in the
-   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
-   be validated according to [RFC3280].  In addition, unless the client
-   can otherwise verify that the public key used to verify the KDC's
-   signature is bound to the KDC of the target realm, the KDC's X.509
-   certificate MUST contain a Subject Alternative Name extension
-   [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
-   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
-   matches the name of the TGS of the target realm (as defined in
-   Section 7.3 of [RFC4120]).
-
-   Unless the client knows by some other means that the KDC certificate
-   is intended for a Kerberos KDC, the client MUST require that the KDC
-   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
-
-       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) keyPurposeKdc(5) }
-              -- Signing KDC responses.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   The digitalSignature key usage bit MUST be asserted when the intended
-   purpose of KDC certificate is restricted with the id-pkinit-KPKdc
-   EKU.
-
-   If the KDC certificate contains the Kerberos TGS name encoded as an
-   id-pkinit-san SAN, this certificate is certified by the issuing CA as
-   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
-
-   If all applicable checks are satisfied, the client then decrypts the
-   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
-   and then proceeds as described in [RFC4120].
-
-   Implementation note: CAs issuing KDC certificates SHOULD place all
-   "short" and "fully-qualified" Kerberos realm names of the KDC (one
-   per GeneralName [RFC3280]) into the KDC certificate to allow maximum
-   flexibility.
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 23]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-3.3.  Interoperability Requirements
-
-   The client MUST be capable of sending a set of certificates
-   sufficient to allow the KDC to construct a certification path for the
-   client's certificate, if the correct set of certificates is provided
-   through configuration or policy.
-
-   If the client sends all the X.509 certificates on a certification
-   path to a trust anchor acceptable by the KDC, and the KDC can not
-   verify the client's public key otherwise, the KDC MUST be able to
-   process path validation for the client's certificate based on the
-   certificates in the request.
-
-   The KDC MUST be capable of sending a set of certificates sufficient
-   to allow the client to construct a certification path for the KDC's
-   certificate, if the correct set of certificates is provided through
-   configuration or policy.
-
-   If the KDC sends all the X.509 certificates on a certification path
-   to a trust anchor acceptable by the client, and the client can not
-   verify the KDC's public key otherwise, the client MUST be able to
-   process path validation for the KDC's certificate based on the
-   certificates in the reply.
-
-3.4.  KDC Indication of PKINIT Support
-
-   If pre-authentication is required, but was not present in the
-   request, per [RFC4120] an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
-   stored in the e-data field of the KRB-ERROR message to specify which
-   pre-authentication mechanisms are acceptable.  The KDC can then
-   indicate the support of PKINIT by including an empty element whose
-   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
-
-   Otherwise if it is required by the KDC's local policy that the client
-   must be pre-authenticated using the pre-authentication mechanism
-   specified in this document, but no PKINIT pre-authentication was
-   present in the request, an error message with the code
-   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
-
-   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
-   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
-   STRING), and clients MUST ignore this and any other value.  Future
-   extensions to this protocol may specify other data to send instead of
-   an empty OCTET STRING.
-
-
-
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 24]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-4.  Security Considerations
-
-   Kerberos error messages are not integrity protected, as a result, the
-   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
-   with by an attacker so that the set of domain parameters selected
-   could be either weaker or not mutually preferred.  Local policy can
-   configure sets of domain parameters acceptable locally, or disallow
-   the negotiation of DH domain parameters.
-
-   The symmetric reply key size and Diffie-Hellman field size or RSA
-   modulus size should be chosen so as to provide sufficient
-   cryptographic security [RFC3766].
-
-   When MODP Diffie-Hellman is used, the exponents should have at least
-   twice as many bits as the symmetric keys that will be derived from
-   them [ODL99].
-
-   PKINIT raises certain security considerations beyond those that can
-   be regulated strictly in protocol definitions.  We will address them
-   in this section.
-
-   PKINIT extends the cross-realm model to the public-key
-   infrastructure.  Users of PKINIT must understand security policies
-   and procedures appropriate to the use of Public Key Infrastructures
-   [RFC3280].
-
-   In order to trust a KDC certificate that is certified by a CA as a
-   KDC certificate for a target realm (for example, by asserting the TGS
-   name of that Kerberos realm as an id-pkinit-san SAN and/or
-   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
-   as described in Section 3.2.4), the client MUST verify that the KDC
-   certificate's issuing CA is authorized to issue KDC certificates for
-   that target realm.  Otherwise, the binding between the KDC
-   certificate and the KDC of the target realm is not established.
-
-   How to validate this authorization is a matter of local policy.  A
-   way to achieve this is the configuration of specific sets of
-   intermediary CAs and trust anchors, one of which must be on the KDC
-   certificate's certification path [RFC3280]; and for each CA or trust
-   anchor the realms for which it is allowed to issue certificates.
-
-   In addition, if any CA is trusted to issue KDC certificates can also
-   issue other kinds of certificates, then local policy must be able to
-   distinguish between them: for example, it could require that KDC
-   certificates contain the id-pkinit-KPKdc EKU or that the realm be
-   specified with the id-pkinit-san SAN.
-
-   It is the responsibility of the PKI administrators for an
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 25]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-   organization to ensure that KDC certificates are only issued to KDCs,
-   and that clients can ascertain this using their local policy.
-
-   Standard Kerberos allows the possibility of interactions between
-   cryptosystems of varying strengths; this document adds interactions
-   with public-key cryptosystems to Kerberos.  Some administrative
-   policies may allow the use of relatively weak public keys.  Using
-   such keys to wrap data encrypted under stronger conventional
-   cryptosystems may be inappropriate.
-
-   PKINIT requires keys for symmetric cryptosystems to be generated.
-   Some such systems contain "weak" keys.  For recommendations regarding
-   these weak keys, see [RFC4120].
-
-   PKINIT allows the use of the same RSA key pair for encryption and
-   signing when doing RSA encryption based key delivery.  This is not
-   recommended usage of RSA keys [RFC3447], by using DH based key
-   delivery this is avoided.
-
-   Care should be taken in how certificates are chosen for the purposes
-   of authentication using PKINIT.  Some local policies may require that
-   key escrow be used for certain certificate types.  Deployers of
-   PKINIT should be aware of the implications of using certificates that
-   have escrowed keys for the purposes of authentication.  Because
-   signing only certificates are normally not escrowed, by using DH
-   based key delivery this is avoided.
-
-   PKINIT does not provide for a "return routability" test to prevent
-   attackers from mounting a denial-of-service attack on the KDC by
-   causing it to perform unnecessary and expensive public-key
-   operations.  Strictly speaking, this is also true of standard
-   Kerberos, although the potential cost is not as great, because
-   standard Kerberos does not make use of public-key cryptography.  By
-   using DH based key delivery and reusing DH keys, the necessary crypto
-   processing cost per request can be minimized.
-
-   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
-   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
-   be used if the KDC itself vouches for the user's certificate.
-
-   When the Diffie-Hellman key exchange method is used, additional pre-
-   authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as
-   defined in this specification) is not bound to the AS_REQ by the
-   mechanisms discussed in this specification (meaning it may be dropped
-   or added by attackers without being detected by either the client or
-   the KDC).  Designers of additional pre-authentication data should
-   take that into consideration if such additional pre-authentication
-   data can be used in conjunction with the PA_PK_AS_REQ.  The future
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 26]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-   work of the Kerberos working group is expected to update the hash
-   algorithms specified in this document and provide a generic mechanism
-   to bind additional pre-authentication data with the accompanying
-   AS_REQ.
-
-
-5.  Acknowledgements
-
-   The following people have made significant contributions to this
-   draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
-   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
-   Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
-   Grundman and Jeffrey Altman.
-
-   Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
-   Chris Walstad discovered a binding issue between the AS-REQ and AS-
-   REP in draft -26, the asChecksum field was added as the result.
-
-   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
-   Jonathan Trostle who wrote earlier versions of this document.
-
-   The authors are indebted to the Kerberos working group chair Jeffrey
-   Hutzelman who kept track of various issues and was enormously helpful
-   during the creation of this document.
-
-   Some of the ideas on which this document is based arose during
-   discussions over several years between members of the SAAG, the IETF
-   CAT working group, and the PSRG, regarding integration of Kerberos
-   and SPX.  Some ideas have also been drawn from the DASS system.
-   These changes are by no means endorsed by these groups.  This is an
-   attempt to revive some of the goals of those groups, and this
-   document approaches those goals primarily from the Kerberos
-   perspective.
-
-   Lastly, comments from groups working on similar ideas in DCE have
-   been invaluable.
-
-
-6.  IANA Considerations
-
-   This document has no actions for IANA.
-
-
-7.  References
-
-
-
-
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 27]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-7.1.  Normative References
-
-   [IEEE1363]
-              IEEE, "Standard Specifications for Public Key 
-              Cryptography", IEEE 1363, 2000.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
-              RFC 2412, November 1998.
-
-   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
-              RFC 2631, June 1999.
-
-   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
-              Algorithms", RFC 3370, August 2002.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
-              Encryption Algorithm in Cryptographic Message Syntax
-              (CMS)", RFC 3565, July 2003.
-
-   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
-              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
-              RFC 3766, April 2004.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 28]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
-              Encryption for Kerberos 5", RFC 3962, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 
-              Information technology - Abstract Syntax Notation One 
-              (ASN.1): Specification of basic notation.
-
-   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 
-              Information technology - ASN.1 encoding Rules: Specification 
-              of Basic Encoding Rules (BER), Canonical Encoding Rules 
-              (CER) and Distinguished Encoding Rules (DER).
-
-7.2.  Informative References
-
-   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
-              Sizes", Journal of Cryptology 14 (2001) 255-293.
-   
-   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
-              future, Designs, Codes, and Cryptography (1999)".
-
-
-Zhu & Tung                Expires June 1, 2006                 [Page 27]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-   [RFC4158]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
-              Nicholas, "Internet X.509 Public Key Infrastructure:
-              Certification Path Building", RFC 4158, September 2005.
-
-
-Appendix A.  PKINIT ASN.1 Module
-
-       KerberosV5-PK-INIT-SPEC {
-               iso(1) identified-organization(3) dod(6) internet(1)
-               security(5) kerberosV5(2) modules(4) pkinit(5)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       IMPORTS
-           SubjectPublicKeyInfo, AlgorithmIdentifier
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 29]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-               FROM PKIX1Explicit88 { iso (1)
-                 identified-organization (3) dod (6) internet (1)
-                 security (5) mechanisms (5) pkix (7) id-mod (0)
-                 id-pkix1-explicit (18) }
-                 -- As defined in RFC 3280.
-
-           KerberosTime, PrincipalName, Realm, EncryptionKey
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) } ;
-
-       id-pkinit OBJECT IDENTIFIER ::=
-         { iso (1) org (3) dod (6) internet (1) security (5)
-           kerberosv5 (2) pkinit (3) }
-
-       id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-       id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-       id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-       id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-       id-pkinit-KPKdc         OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-       id-pkinit-san OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509SanAN (2) }
-
-       pa-pk-as-req INTEGER ::=                  16
-       pa-pk-as-rep INTEGER ::=                  17
-
-       ad-initial-verified-cas INTEGER ::=        9
-
-       td-trusted-certifiers INTEGER ::=        104
-       td-invalid-certificates INTEGER ::=      105
-       td-dh-parameters INTEGER ::=             109
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 30]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-                   -- Contains a list of CAs, trusted by the client,
-                   -- that can be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 31]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so.
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 32]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is
-                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-                   -- eContent field contains the DER encoding of the
-                   -- type ReplyKeyPack.
-                   -- ReplyKeyPack is defined below.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL
-                   -- Present if and only if dhKeyExpiration is
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 33]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-                   -- present.
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- The KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the pkAuthenticator field
-                   -- in the request if the DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if the DH keys are reused.
-                   -- If present, the KDC's DH public key MUST not be
-                   -- used past the point of this expiration time.
-                   -- If this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP, i.e. the
-                   -- AS reply key.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-       END
-
-
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 34]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-Appendix B.  Test Vectors
-
-   Function octetstring2key() is defined in Section 3.2.3.1.  This
-   section describes a few sets of test vectors that would be useful for
-   implementers of octetstring2key().
-
-
-   Set 1
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
-     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
-
-
-   Set 2:
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 35]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
-     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
-
-
-   Set 3:
-   ======
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
-     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
-     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
-     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
-     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
-
-
-   Set 4:
-   =====
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
-     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
-
-
-Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
-             Implementations
-
-   Earlier revisions of the PKINIT I-D were implemented in various
-   releases of Microsoft Windows and deployed in fairly large numbers.
-   To enable the community to better interoperate with systems running
-   those releases, the following information may be useful.
-
-   KDC certificates issued by Windows 2000 Enterprise CAs contain a
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 36]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-   dNSName SAN with the DNS name of the host running the KDC, and the
-   id-kp-serverAuth EKU [RFC3280].
-
-   KDC certificates issued by Windows 2003 Enterprise CAs contain a
-   dNSName SAN with the DNS name of the host running the KDC, the id-kp-
-   serverAuth EKU and the id-ms-kp-sc-logon EKU.
-
-   It is anticipated that the next release of Windows is already too far
-   along to allow it to support the issuing KDC certificates with id-
-   pkinit-san SAN as specified in this RFC.  Instead, they will have a
-   dNSName SAN containing the domain name of the KDC and the intended
-   purpose of these KDC certificates be restricted by the presence of
-   the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
-
-   In addition to checking that the above are present in a KDC
-   certificate, Windows clients verify that the issuer of the KDC
-   certificate is one of a set of allowed issuers of such certificates,
-   so those wishing to issue KDC certificates need to configure their
-   Windows clients appropriately.
-
-   Client certificates accepted by Windows 2000 and Windows 2003 Server
-   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
-   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
-   contains a UTF8 encoded string whose value is that of the Directory
-   Service attribute UserPrincipalName of the client account object, and
-   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
-   certificate is to validate the client mapping (in other words, the
-   client's public key is bound to the account that has this
-   UserPrincipalName value).
-
-   It should be noted that all Microsoft Kerberos realm names are domain
-   style realm names and strictly in upper case.  In addition, the
-   UserPrincipalName attribute is globally unique in Windows 2000 and
-   Windows 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 37]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Brian Tung
-   USC Information Sciences Institute
-   4676 Admiralty Way Suite 1001
-   Marina del Rey, CA  90292
-   US
-
-   Email: brian@isi.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 38]
-
-Internet-Draft                   PKINIT                    November 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu & Tung                Expires June 2, 2006                 [Page 39]
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-31.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-31.txt
deleted file mode 100644
index 5a0799144..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-31.txt
+++ /dev/null
@@ -1,2237 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                     Microsoft Corporation
-Expires: June 15, 2006                                           B. Tung
-                                      USC Information Sciences Institute
-                                                       December 12, 2005
-
-
-     Public Key Cryptography for Initial Authentication in Kerberos
-                   draft-ietf-cat-kerberos-pk-init-31
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on June 15, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes protocol extensions (hereafter called PKINIT)
-   to the Kerberos protocol specification.  These extensions provide a
-   method for integrating public key cryptography into the initial
-   authentication exchange, by using asymmetric-key signature and/or
-   encryption algorithms in pre-authentication data fields.
-
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                 [Page 1]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  Definitions, Requirements, and Constants . . . . . . . . .  5
-       3.1.1.  Required Algorithms  . . . . . . . . . . . . . . . . .  5
-       3.1.2.  Defined Message and Encryption Types . . . . . . . . .  5
-       3.1.3.  Algorithm Identifiers  . . . . . . . . . . . . . . . .  6
-     3.2.  PKINIT Pre-authentication Syntax and Use . . . . . . . . .  7
-       3.2.1.  Generation of Client Request . . . . . . . . . . . . .  7
-       3.2.2.  Receipt of Client Request  . . . . . . . . . . . . . . 12
-       3.2.3.  Generation of KDC Reply  . . . . . . . . . . . . . . . 16
-       3.2.4.  Receipt of KDC Reply . . . . . . . . . . . . . . . . . 23
-     3.3.  Interoperability Requirements  . . . . . . . . . . . . . . 24
-     3.4.  KDC Indication of PKINIT Support . . . . . . . . . . . . . 25
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
-   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 28
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 30
-   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 30
-   Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 35
-   Appendix C.  Miscellaneous Information about Microsoft Windows
-                PKINIT Implementations  . . . . . . . . . . . . . . . 37
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
-   Intellectual Property and Copyright Statements . . . . . . . . . . 40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                 [Page 2]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-1.  Introduction
-
-   A client typically authenticates itself to a service in Kerberos
-   using three distinct though related exchanges.  First, the client
-   requests a ticket-granting ticket (TGT) from the Kerberos
-   authentication server (AS).  Then, it uses the TGT to request a
-   service ticket from the Kerberos ticket-granting server (TGS).
-   Usually, the AS and TGS are integrated in a single device known as a
-   Kerberos Key Distribution Center, or KDC.  Finally, the client uses
-   the service ticket to authenticate itself to the service.
-
-   The advantage afforded by the TGT is that the client exposes his
-   long-term secrets only once.  The TGT and its associated session key
-   can then be used for any subsequent service ticket requests.  One
-   result of this is that all further authentication is independent of
-   the method by which the initial authentication was performed.
-   Consequently, initial authentication provides a convenient place to
-   integrate public-key cryptography into Kerberos authentication.
-
-   As defined in [RFC4120], Kerberos authentication exchanges use
-   symmetric-key cryptography, in part for performance.  One
-   disadvantage of using symmetric-key cryptography is that the keys
-   must be shared, so that before a client can authenticate itself, he
-   must already be registered with the KDC.
-
-   Conversely, an established Public Key Infrastructure (PKI) already
-   provides key management and key distribution mechanisms that are
-   sufficient to establish authentication and secure communication.
-   Adding public-key cryptography to Kerberos allows Kerberized
-   applications to leverage these existing services.  In addition, human
-   users can avoid the inconvenience of managing strong passwords, by
-   using randomly generated strong public and private key pairs.
-
-   As noted above, a convenient and efficient place to introduce public-
-   key cryptography into Kerberos is in the initial authentication
-   exchange.  This document describes the methods and data formats for
-   integrating public-key cryptography into Kerberos initial
-   authentication.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   Both the AS and the TGS are referred to as the KDC.
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                 [Page 3]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   In this protocol, both the client and the KDC have a public-private
-   key pair in order to prove their identities to each other over the
-   open network.  The client's key pair is used to authenticate the
-   client to the KDC, and the KDC's key pair is used to authenticate the
-   KDC to the client.  The term "signature key" is used to refer to the
-   private key of the key pair being used.
-
-   In this document, the encryption key used to encrypt the enc-part
-   field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
-   reply key.
-
-   In this document, an empty sequence in an optional field can be
-   either included or omitted: both encodings are permitted and
-   considered equivalent.
-
-   In this document, the term "Modular Exponential Diffie-Hellman" is
-   used to refer to the Diffie-Hellman key exchange as described in
-   [RFC2631], in order to differentiate it from other equivalent
-   representations of the same key agreement algorithm.
-
-
-3.  Extensions
-
-   This section describes extensions to [RFC4120] for supporting the use
-   of public-key cryptography in the initial request for a ticket.
-
-   Briefly, this document defines the following extensions to [RFC4120]:
-
-   1. The client indicates the use of public-key authentication by
-      including a special preauthenticator in the initial request.  This
-      preauthenticator contains the client's public-key data and a
-      signature.
-
-   2. The KDC tests the client's request against its authentication
-      policy and trusted Certification Authorities (CAs).
-
-   3. If the request passes the verification tests, the KDC replies as
-      usual, but the reply is encrypted using either:
-
-      a. a key generated through a Diffie-Hellman (DH) key exchange
-         [RFC2631] [IEEE1363] with the client, signed using the KDC's
-         signature key; or
-
-      b. a symmetric encryption key, signed using the KDC's signature
-         key and encrypted using the client's public key.
-
-
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                 [Page 4]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-      Any keying material required by the client to obtain the
-      encryption key for decrypting the KDC reply is returned in a pre-
-      authentication field accompanying the usual reply.
-
-   4. The client validates the KDC's signature, obtains the encryption
-      key, decrypts the reply, and then proceeds as usual.
-
-   Section 3.1 of this document enumerates the required algorithms and
-   necessary extension message types.  Section 3.2 describes the
-   extension messages in greater detail.
-
-3.1.  Definitions, Requirements, and Constants
-
-3.1.1.  Required Algorithms
-
-   All PKINIT implementations MUST support the following algorithms:
-
-   o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
-      sha1-96 [RFC3962].
-
-   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
-
-   o  AS reply key delivery method: Diffie-Hellman key exchange
-      [RFC2631].
-
-   In addition, implementations of this specification MUST be capable of
-   processing the Extended Key Usage (EKU) extension and the id-pkinit-
-   san (as defined in Section 3.2.2) otherName of the Subject
-   Alternative Name (SAN) extension in X.509 certificates [RFC3280], if
-   present.
-
-3.1.2.  Defined Message and Encryption Types
-
-   PKINIT makes use of the following new pre-authentication types:
-
-       PA_PK_AS_REQ                                 16
-       PA_PK_AS_REP                                 17
-
-   PKINIT also makes use of the following new authorization data type:
-
-       AD_INITIAL_VERIFIED_CAS                       9
-
-   PKINIT introduces the following new error codes:
-
-
-
-
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                 [Page 5]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-       KDC_ERR_CLIENT_NOT_TRUSTED                   62
-       KDC_ERR_INVALID_SIG                          64
-       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
-       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
-       KDC_ERR_INVALID_CERTIFICATE                  71
-       KDC_ERR_REVOKED_CERTIFICATE                  72
-       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
-       KDC_ERR_CLIENT_NAME_MISMATCH                 75
-       KDC_ERR_INCONSISTENT_KEY_PURPOSE             76
-       KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED          77
-       KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED             78
-       KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED   79
-
-   PKINIT uses the following typed data types for errors:
-
-       TD_TRUSTED_CERTIFIERS                       104
-       TD_INVALID_CERTIFICATES                     105
-       TD_DH_PARAMETERS                            109
-
-   The ASN.1 module for all structures defined in this document (plus
-   IMPORT statements for all imported structures) is given in
-   Appendix A.
-
-   All structures defined in or imported into this document MUST be
-   encoded using Distinguished Encoding Rules (DER) [X680] [X690]
-   (unless otherwise noted).  All data structures carried in OCTET
-   STRINGs must be encoded according to the rules specified in
-   corresponding specifications.
-
-   Interoperability note: Some implementations may not be able to decode
-   wrapped CMS objects encoded with BER; specifically, they may not be
-   able to decode indefinite length encodings.  To maximize
-   interoperability, implementers SHOULD encode CMS objects used in
-   PKINIT with DER.
-
-3.1.3.  Algorithm Identifiers
-
-   PKINIT does not define, but does make use of, the following algorithm
-   identifiers.
-
-   PKINIT uses the following algorithm identifier(s) for Modular
-   Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]:
-
-       dhpublicnumber (as described in [RFC3279])
-
-   PKINIT uses the following signature algorithm identifiers as defined
-   in [RFC3279]:
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                 [Page 6]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-       sha-1WithRSAEncryption (RSA with SHA1)
-       md5WithRSAEncryption   (RSA with MD5)
-       id-dsa-with-sha1       (DSA with SHA1)
-
-   PKINIT uses the following encryption algorithm identifiers as defined
-   in [RFC3447] for encrypting the temporary key with a public key:
-
-       rsaEncryption
-       id-RSAES-OAEP
-
-   PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
-   for encrypting the AS reply key with the temporary key:
-
-       des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370])
-       rc2-cbc       (RC2, CBC mode, as defined in [RFC3370])
-       id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565])
-
-   PKINIT defines the following encryption types, for use in the etype
-   field of the AS-REQ [RFC4120] message to indicate acceptance of the
-   corresponding algorithms that can used by Cryptographic Message
-   Syntax (CMS) [RFC3852] messages in the reply:
-
-       id-dsa-with-sha1-CmsOID                       9
-          -- Indicates that the client supports id-dsa-with-sha1.
-       md5WithRSAEncryption-CmsOID                  10
-          -- Indicates that the client supports md5WithRSAEncryption.
-       sha-1WithRSAEncryption-CmsOID                11
-          -- Indicates that the client supports sha-1WithRSAEncryption.
-       rc2-cbc-EnvOID                               12
-          -- Indicates that the client supports rc2-cbc.
-       rsaEncryption-EnvOID                         13
-          -- Indicates that the client supports rsaEncryption.
-       id-RSAES-OAEP-EnvOID                         14
-          -- Indicates that the client supports id-RSAES-OAEP.
-       des-ede3-cbc-EnvOID                          15
-          -- Indicates that the client supports des-ede3-cbc.
-
-3.2.  PKINIT Pre-authentication Syntax and Use
-
-   This section defines the syntax and use of the various pre-
-   authentication fields employed by PKINIT.
-
-3.2.1.  Generation of Client Request
-
-   The initial authentication request (AS-REQ) is sent as per [RFC4120];
-   in addition, a pre-authentication data element, whose padata-type is
-   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
-   type PA-PK-AS-REQ, is included.
-
-
-
-Zhu & Tung                Expires June 15, 2006                 [Page 7]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- Contains a list of CAs, trusted by the client,
-                   -- that can be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-
-
-
-Zhu & Tung                Expires June 15, 2006                 [Page 8]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so (see Section 3.2.3.1).
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-
-
-
-Zhu & Tung                Expires June 15, 2006                 [Page 9]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure contained in the signedAuthPack
-   field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
-   is filled out as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is id-pkinit-
-       authData: { iso(1) org(3) dod(6) internet(1) security(5)
-       kerberosv5(2) pkinit(3) authData(1) }.  Notes to CMS
-       implementers: the signed attribute content-type MUST be present
-       in this SignedData instance and its value is id-pkinit-authData
-       according to [RFC3852].
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type AuthPack.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type AuthPack.
-
-   5.  The AuthPack structure contains a PKAuthenticator, the client
-       public key information, the CMS encryption types supported by the
-       client and a DHNonce.  The pkAuthenticator field certifies to the
-       KDC that the client has recent knowledge of the signing key that
-       authenticates the client.  The clientPublicValue field specifies
-       Diffie-Hellman domain parameters and the client's public key
-       value.  The DH public key value is encoded as a BIT STRING
-       according to [RFC3279].  The clientPublicValue field is present
-       only if the client wishes to use the Diffie-Hellman key agreement
-       method.  The supportedCMSTypes field specifies the list of CMS
-       encryption types supported by the client in order of (decreasing)
-       preference.  The clientDHNonce field is described later in this
-       section.
-
-   6.  The ctime field in the PKAuthenticator structure contains the
-       current time on the client's host, and the cusec field contains
-       the microsecond part of the client's timestamp.  The ctime and
-       cusec fields are used together to specify a reasonably accurate
-       timestamp [RFC4120].  The nonce field is chosen randomly.  The
-       paChecksum field contains a SHA1 checksum that is performed over
-       the KDC-REQ-BODY [RFC4120].
-
-
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 10]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   7.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the KDC can verify the signature over the
-       type AuthPack.  For path validation, these certificates SHOULD be
-       sufficient to construct at least one certification path from the
-       client certificate to one trust anchor acceptable by the KDC
-       [RFC4158].  The client MUST be capable of including such a set of
-       certificates if configured to do so.  The certificates field MUST
-       NOT contain "root" CA certificates.
-
-   8.  The client's Diffie-Hellman public value (clientPublicValue) is
-       included if and only if the client wishes to use the Diffie-
-       Hellman key agreement method.  The Diffie-Hellman domain
-       parameters [IEEE1363] for the client's public key are specified
-       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
-       and the client's Diffie-Hellman public key value is mapped to a
-       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
-       using the Diffie-Hellman key agreement method, implementations
-       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
-       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
-       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
-       group 16 [RFC3526].
-
-       The Diffie-Hellman field size should be chosen so as to provide
-       sufficient cryptographic security [RFC3766].
-
-       When MODP Diffie-Hellman is used, the exponents should have at
-       least twice as many bits as the symmetric keys that will be
-       derived from them [ODL99].
-
-   9.  The client may wish to reuse DH keys or to allow the KDC to do so
-       (see Section 3.2.3.1).  If so, then the client includes the
-       clientDHNonce field.  This nonce string MUST be as long as the
-       longest key length of the symmetric key types that the client
-       supports.  This nonce MUST be chosen randomly.
-
-   The ExternalPrincipalIdentifier structure is used in this document to
-   identify the subject's public key thereby the subject principal.
-   This structure is filled out as follows:
-
-   1.  The subjectName field contains a PKIX type Name encoded according
-       to [RFC3280].  This field identifies the certificate subject by
-       the distinguished subject name.  This field is REQUIRED when
-       there is a distinguished subject name present in the certificate
-       being used.
-
-
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 11]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   2.  The issuerAndSerialNumber field contains a CMS type
-       IssuerAndSerialNumber encoded according to [RFC3852].  This field
-       identifies a certificate of the subject.  This field is REQUIRED
-       for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
-       structures are defined in Section 3.2.2).
-
-   3.  The subjectKeyIdentifier [RFC3852] field identifies the subject's
-       public key by a key identifier.  When an X.509 certificate is
-       referenced, this key identifier matches the X.509
-       subjectKeyIdentifier extension value.  When other certificate
-       formats are referenced, the documents that specify the
-       certificate format and their use with the CMS must include
-       details on matching the key identifier to the appropriate
-       certificate field.  This field is RECOMMENDED for TD-TRUSTED-
-       CERTIFIERS (as defined in Section 3.2.2).
-
-   The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
-   of CAs, trusted by the client, that can be used to certify the KDC.
-   Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
-   (thereby its public key).
-
-   The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
-   SignerIdentifier encoded according to [RFC3852].  This field
-   identifies, if present, a particular KDC public key that the client
-   already has.
-
-3.2.2.  Receipt of Client Request
-
-   Upon receiving the client's request, the KDC validates it.  This
-   section describes the steps that the KDC MUST (unless otherwise
-   noted) take in validating the request.
-
-   The KDC verifies the client's signature in the signedAuthPack field
-   according to [RFC3852].
-
-   If, while validating the client's X.509 certificate [RFC3280], the
-   KDC cannot build a certification path to validate the client's
-   certificate, it sends back a KRB-ERROR [RFC4120] message with the
-   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
-   this error message is a TYPED-DATA (as defined in [RFC4120]) that
-   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
-   whose data-value contains the DER encoding of the type TD-TRUSTED-
-   CERTIFIERS:
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 12]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-                   -- or a CA certificate (thereby its public key).
-
-   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
-   TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
-   (thereby its public key) trusted by the KDC.
-
-   Upon receiving this error message, the client SHOULD retry only if it
-   has a different set of certificates (from those of the previous
-   requests) that form a certification path (or a partial path) from one
-   of the trust anchors acceptable by the KDC to its own certificate.
-
-   If, while processing the certification path, the KDC determines that
-   the signature on one of the certificates in the signedAuthPack field
-   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
-   message is a TYPED-DATA that contains an element whose data-type is
-   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
-   encoding of the type TD-INVALID-CERTIFICATES:
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
-   TD-INVALID-CERTIFICATES structure identifies a certificate (that was
-   sent by the client) with an invalid signature.
-
-   If more than one X.509 certificate signature is invalid, the KDC MAY
-   include one IssuerAndSerialNumber per invalid signature within the
-   TD-INVALID-CERTIFICATES.
-
-   The client's X.509 certificate is validated according to [RFC3280].
-
-   Based on local policy, the KDC may also check whether any X.509
-   certificates in the certification path validating the client's
-   certificate have been revoked.  If any of them have been revoked, the
-   KDC MUST return an error message with the code
-   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
-   revocation status but is unable to do so, it SHOULD return an error
-   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
-   certificate or certificates affected are identified exactly as for
-   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
-
-   Note that the TD_INVALID_CERTIFICATES error data is only used to
-   identify invalid certificates sent by the client in the request.
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 13]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   The client's public key is then used to verify the signature.  If the
-   signature fails to verify, the KDC MUST return an error message with
-   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
-   this error message.
-
-   In addition to validating the client's signature, the KDC MUST also
-   check that the client's public key used to verify the client's
-   signature is bound to the client's principal name as specified in the
-   AS-REQ as follows:
-
-   1. If the KDC has its own binding between either the client's
-      signature-verification public key or the client's certificate and
-      the client's Kerberos principal name, it uses that binding.
-
-   2. Otherwise, if the client's X.509 certificate contains a Subject
-      Alternative Name (SAN) extension carrying a KRB5PrincipalName
-      (defined below) in the otherName field of the type GeneralName
-      [RFC3280], it binds the client's X.509 certificate to that name.
-
-      The type of the otherName field is AnotherName.  The type-id field
-      of the type AnotherName is id-pkinit-san:
-
-       id-pkinit-san OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509SanAN (2) }
-
-      And the value field of the type AnotherName is a
-      KRB5PrincipalName.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-   If the KDC does not have its own binding and there is no
-   KRB5PrincipalName name present in the client's X.509 certificate, or
-   if the Kerberos name in the request does not match the
-   KRB5PrincipalName in the client's X.509 certificate (including the
-   realm name), the KDC MUST return an error message with the code
-   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
-   this error message.
-
-   Even if the certification path is validated and the certificate is
-   mapped to the client's principal name, the KDC may decide not to
-   accept the client's certificate, depending on local policy.
-
-   The KDC MAY require the presence of an Extended Key Usage (EKU)
-   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 14]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   of the client's X.509 certificate:
-
-       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) keyPurposeClientAuth(4) }
-              -- PKINIT client authentication.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   The digitalSignature key usage bit [RFC3280] MUST be asserted when
-   the intended purpose of the client's X.509 certificate is restricted
-   with the id-pkinit-KPClientAuth EKU.
-
-   If this EKU KeyPurposeId is required but it is not present or if the
-   client certificate is restricted not to be used for PKINIT client
-   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
-   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
-   is no accompanying e-data for this error message.  KDCs implementing
-   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
-   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
-   are a large number of X.509 client certificates deployed for use with
-   PKINIT which have this EKU.
-
-   As a matter of local policy, the KDC MAY decide to reject requests on
-   the basis of the absence or presence of other specific EKU OID's.
-
-   If the digest algorithm used in generating the CA signature for the
-   public key in any certificate of the request is not acceptable by the
-   KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED.  The accompanying e-data MUST be
-   encoded in TYPED-DATA although none is defined at this point.
-
-   If the client's public key is not accepted with reasons other than
-   what were specified above, the KDC returns a KRB-ERROR [RFC4120]
-   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.  There is no
-   accompanying e-data currently defined for this error message.
-
-   The KDC MUST check the timestamp to ensure that the request is not a
-   replay, and that the time skew falls within acceptable limits.  The
-   recommendations for clock skew times in [RFC4120] apply here.  If the
-   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
-   KRB_AP_ERR_SKEW, respectively.
-
-   If the clientPublicValue is filled in, indicating that the client
-   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
-   check to see if the key parameters satisfy its policy.  If they do
-   not, it MUST return an error message with the code
-   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 15]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   TYPED-DATA that contains an element whose data-type is
-   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
-   the type TD-DH-PARAMETERS:
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-
-   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
-   that the KDC supports in decreasing preference order, from which the
-   client SHOULD pick one to retry the request.
-
-   The AlgorithmIdentifier structure is defined in [RFC3280] and is
-   filled in according to [RFC3279].  More specifically Section 2.3.3 of
-   [RFC3279] describes how to fill in the AlgorithmIdentifier structure
-   in the case where MODP Diffie-Hellman key exchange is used.
-
-   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
-   KDC does not possess the corresponding key, the KDC MUST ignore the
-   kdcPkId field as if the client did not include one.
-
-   If the digest algorithm used by the id-pkinit-authData is not
-   acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
-   message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
-   The accompanying e-data MUST be encoded in TYPED-DATA although none
-   is defined at this point.
-
-3.2.3.  Generation of KDC Reply
-
-   Assuming that the client's request has been properly validated, the
-   KDC proceeds as per [RFC4120], except as follows.
-
-   The KDC MUST set the initial flag and include an authorization data
-   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
-   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
-   type AD-INITIAL-VERIFIED-CAS:
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   The AD-INITIAL-VERIFIED-CAS structure identifies the certification
-   path based on which the client certificate was validated.  Each
-   ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 16]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
-   (thereby its public key).
-
-   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-   containers if the list of CAs satisfies the AS' realm's local policy
-   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
-   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
-   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
-   resulting ticket.  If the list of CAs satisfies the local KDC's
-   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
-   container, otherwise it MAY unwrap the authorization data out of the
-   AD-IF-RELEVANT container.
-
-   Application servers that understand this authorization data type
-   SHOULD apply local policy to determine whether a given ticket bearing
-   such a type *not* contained within an AD-IF-RELEVANT container is
-   acceptable.  (This corresponds to the AP server checking the
-   transited field when the TRANSITED-POLICY-CHECKED flag has not been
-   set [RFC4120].)  If such a data type is contained within an AD-IF-
-   RELEVANT container, AP servers MAY apply local policy to determine
-   whether the authorization data is acceptable.
-
-   A pre-authentication data element, whose padata-type is PA_PK_AS_REP
-   and whose padata-value contains the DER encoding of the type PA-PK-
-   AS-REP (defined below), is included in the AS-REP [RFC4120].
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is
-                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-                   -- eContent field contains the DER encoding of the
-                   -- type ReplyKeyPack.
-                   -- ReplyKeyPack is defined in Section 3.2.3.2.
-          ...
-       }
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 17]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL,
-                   -- Present if and only if dhKeyExpiration is
-                   -- present in the KDCDHKeyInfo.
-          ...
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- The KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the pkAuthenticator field
-                   -- in the request if the DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if the DH keys are reused.
-                   -- If present, the KDC's DH public key MUST not be
-                   -- used past the point of this expiration time.
-                   -- If this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
-   KDC encrypts the reply as usual, but not with the client's long-term
-   key.  Instead, it encrypts it with either a shared key derived from a
-   Diffie-Hellman exchange, or a generated encryption key.  The contents
-   of the PA-PK-AS-REP indicate which key delivery method is used.
-
-   In addition, the lifetime of the ticket returned by the KDC MUST NOT
-   exceed that of the client's public-private key pair.  The ticket
-   lifetime, however, can be shorter than that of the client's public-
-   private key pair.  For the implementations of this specification, the
-   lifetime of the client's public-private key pair is the validity
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 18]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   period in X.509 certificates [RFC3280], unless configured otherwise.
-
-3.2.3.1.  Using Diffie-Hellman Key Exchange
-
-   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
-
-   The ContentInfo [RFC3852] structure for the dhSignedData field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is the OID value
-       for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
-       security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.  Notes to CMS
-       implementers: the signed attribute content-type MUST be present
-       in this SignedData instance and its value is id-pkinit-DHKeyData
-       according to [RFC3852].
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type KDCDHKeyInfo.
-
-   4.  The KDCDHKeyInfo structure contains the KDC's public key, a nonce
-       and optionally the expiration time of the KDC's DH key being
-       reused.  The subjectPublicKey field of the type KDCDHKeyInfo
-       field identifies KDC's DH public key.  This DH public key value
-       is encoded as a BIT STRING according to [RFC3279].  The nonce
-       field contains the nonce in the pkAuthenticator field in the
-       request if the DH keys are NOT reused.  The value of this nonce
-       field is 0 if the DH keys are reused.  The dhKeyExpiration field
-       is present if and only if the DH keys are reused.  If the
-       dhKeyExpiration field is present, the KDC's public key in this
-       KDCDHKeyInfo structure MUST NOT be used past the point of this
-       expiration time.  If this field is omitted then the serverDHNonce
-       field MUST also be omitted.
-
-   5.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type
-       KDCDHKeyInfo.
-
-   6.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type KDCDHKeyInfo.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may be left empty if the KDC
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 19]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
-       used for signing.  Otherwise, for path validation, these
-       certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [RFC4158].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  If the client included the clientDHNonce field, then the KDC may
-       choose to reuse its DH keys.  If the server reuses DH keys then
-       it MUST include an expiration time in the dhKeyExpiration field.
-       Past the point of the expiration time, the signature over the
-       type DHRepInfo is considered expired/invalid.  When the server
-       reuses DH keys then it MUST include a serverDHNonce at least as
-       long as the length of keys for the symmetric encryption system
-       used to encrypt the AS reply.  Note that including the
-       serverDHNonce changes how the client and server calculate the key
-       to use to encrypt the reply; see below for details.  The KDC
-       SHOULD NOT reuse DH keys unless the clientDHNonce field is
-       present in the request.
-
-   The AS reply key is derived as follows:
-
-   1. Both the KDC and the client calculate the shared secret value as
-      follows:
-
-      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
-         shared secret value.  DHSharedSecret is the value ZZ as
-         described in Section 2.1.1 of [RFC2631].
-
-      DHSharedSecret is first padded with leading zeros such that the
-      size of DHSharedSecret in octets is the same as that of the
-      modulus, then represented as a string of octets in big-endian
-      order.
-
-      Implementation note: Both the client and the KDC can cache the
-      triple (ya, yb, DHSharedSecret), where ya is the client's public
-      key and yb is the KDC's public key.  If both ya and yb are the
-      same in a later exchange, the cached DHSharedSecret can be used.
-
-   2. Let K be the key-generation seed length [RFC3961] of the AS reply
-      key whose enctype is selected according to [RFC4120].
-
-   3. Define the function octetstring2key() as follows:
-
-
-
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 20]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-           octetstring2key(x) == random-to-key(K-truncate(
-                                    SHA1(0x00 | x) |
-                                    SHA1(0x01 | x) |
-                                    SHA1(0x02 | x) |
-                                    ...
-                                    ))
-
-      where x is an octet string; | is the concatenation operator; 0x00,
-      0x01, 0x02, etc., are each represented as a single octet; random-
-      to-key() is an operation that generates a protocol key from a
-      bitstring of length K; and K-truncate truncates its input to the
-      first K bits.  Both K and random-to-key() are as defined in the
-      kcrypto profile [RFC3961] for the enctype of the AS reply key.
-
-   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
-      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
-      strings.
-
-   5. The AS reply key k is:
-
-           k = octetstring2key(DHSharedSecret | n_c | n_k)
-
-   If the hash algorithm used in the key derivation function (currently
-   only octetstring2key() is defined) is not acceptable by the KDC, the
-   KDC MUST return a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_HASH_IN_KDF_NOT_ACCEPTED.  The accompanying e-data MUST be
-   encoded in TYPED-DATA although none is defined at this point.
-
-3.2.3.2.  Using Public Key Encryption
-
-   In this case, the PA-PK-AS-REP contains the encKeyPack field where
-   the AS reply key is encrypted.
-
-   The ContentInfo [RFC3852] structure for the encKeyPack field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-envelopedData
-       (as defined in [RFC3852]), and the content field is an
-       EnvelopedData (as defined in [RFC3852]).
-
-   2.  The contentType field for the type EnvelopedData is id-
-       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
-       pkcs (1) pkcs7 (7) signedData (2) }.
-
-   3.  The eContentType field for the inner type SignedData (when
-       decrypted from the encryptedContent field for the type
-       EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
-       internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 21]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-       Notes to CMS implementers: the signed attribute content-type MUST
-       be present in this SignedData instance and its value is id-
-       pkinit-rkeyData according to [RFC3852].
-
-   4.  The eContent field for the inner type SignedData contains the DER
-       encoding of the type ReplyKeyPack (as described below).
-
-   5.  The signerInfos field of the inner type SignedData contains a
-       single signerInfo, which contains the signature for the type
-       ReplyKeyPack.
-
-   6.  The certificates field of the inner type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       for the type ReplyKeyPack.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may be left empty if the KDC
-       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
-       used for signing.  Otherwise, for path validation, these
-       certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [RFC4158].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  The recipientInfos field of the type EnvelopedData is a SET which
-       MUST contain exactly one member of type KeyTransRecipientInfo.
-       The encryptedKey of this member contains the temporary key which
-       is encrypted using the client's public key.
-
-   8.  The unprotectedAttrs or originatorInfo fields of the type
-       EnvelopedData MAY be present.
-
-   If there is a supportedCMSTypes field in the AuthPack, the KDC must
-   check to see if it supports any of the listed types.  If it supports
-   more than one of the types, the KDC SHOULD use the one listed first.
-   If it does not support any of them, it MUST return an error message
-   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
-
-   Furthermore the KDC computes the checksum of the AS-REQ in the client
-   request.  This checksum is performed over the type AS-REQ and the
-   protocol key [RFC3961] of the checksum operation is the replyKey and
-   the key usage number is 6.  If the replyKey's enctype is "newer"
-   [RFC4120] [RFC4121], the checksum operation is the required checksum
-   operation [RFC3961] of that enctype.
-
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 22]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP, i.e. the
-                   -- AS reply key.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-   Implementations of this RSA encryption key delivery method are
-   RECOMMENDED to support RSA keys at least 2048 bits in size.
-
-3.2.4.  Receipt of KDC Reply
-
-   Upon receipt of the KDC's reply, the client proceeds as follows.  If
-   the PA-PK-AS-REP contains the dhSignedData field, the client derives
-   the AS reply key using the same procedure used by the KDC as defined
-   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
-   field, and the client decrypts and extracts the temporary key in the
-   encryptedKey field of the member KeyTransRecipientInfo, and then uses
-   that as the AS reply key.
-
-   If the public key encryption method is used, the client MUST verify
-   the asChecksum contained in the ReplyKeyPack.
-
-   In either case, the client MUST verify the signature in the
-   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
-   be validated according to [RFC3280].  In addition, unless the client
-   can otherwise verify that the public key used to verify the KDC's
-   signature is bound to the KDC of the target realm, the KDC's X.509
-   certificate MUST contain a Subject Alternative Name extension
-   [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
-   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
-   matches the name of the TGS of the target realm (as defined in
-   Section 7.3 of [RFC4120]).
-
-   Unless the client knows by some other means that the KDC certificate
-   is intended for a Kerberos KDC, the client MUST require that the KDC
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 23]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
-
-       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) keyPurposeKdc(5) }
-              -- Signing KDC responses.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   The digitalSignature key usage bit [RFC3280] MUST be asserted when
-   the intended purpose of the KDC's X.509 certificate is restricted
-   with the id-pkinit-KPKdc EKU.
-
-   If the KDC certificate contains the Kerberos TGS name encoded as an
-   id-pkinit-san SAN, this certificate is certified by the issuing CA as
-   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
-
-   If all applicable checks are satisfied, the client then decrypts the
-   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
-   and then proceeds as described in [RFC4120].
-
-   Implementation note: CAs issuing KDC certificates SHOULD place all
-   "short" and "fully-qualified" Kerberos realm names of the KDC (one
-   per GeneralName [RFC3280]) into the KDC certificate to allow maximum
-   flexibility.
-
-3.3.  Interoperability Requirements
-
-   The client MUST be capable of sending a set of certificates
-   sufficient to allow the KDC to construct a certification path for the
-   client's certificate, if the correct set of certificates is provided
-   through configuration or policy.
-
-   If the client sends all the X.509 certificates on a certification
-   path to a trust anchor acceptable by the KDC, and the KDC can not
-   verify the client's public key otherwise, the KDC MUST be able to
-   process path validation for the client's certificate based on the
-   certificates in the request.
-
-   The KDC MUST be capable of sending a set of certificates sufficient
-   to allow the client to construct a certification path for the KDC's
-   certificate, if the correct set of certificates is provided through
-   configuration or policy.
-
-   If the KDC sends all the X.509 certificates on a certification path
-   to a trust anchor acceptable by the client, and the client can not
-   verify the KDC's public key otherwise, the client MUST be able to
-   process path validation for the KDC's certificate based on the
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 24]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   certificates in the reply.
-
-3.4.  KDC Indication of PKINIT Support
-
-   If pre-authentication is required, but was not present in the
-   request, per [RFC4120] an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
-   stored in the e-data field of the KRB-ERROR message to specify which
-   pre-authentication mechanisms are acceptable.  The KDC can then
-   indicate the support of PKINIT by including an empty element whose
-   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
-
-   Otherwise if it is required by the KDC's local policy that the client
-   must be pre-authenticated using the pre-authentication mechanism
-   specified in this document, but no PKINIT pre-authentication was
-   present in the request, an error message with the code
-   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
-
-   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
-   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
-   STRING), and clients MUST ignore this and any other value.  Future
-   extensions to this protocol may specify other data to send instead of
-   an empty OCTET STRING.
-
-
-4.  Security Considerations
-
-   Kerberos error messages are not integrity protected, as a result, the
-   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
-   with by an attacker so that the set of domain parameters selected
-   could be either weaker or not mutually preferred.  Local policy can
-   configure sets of domain parameters acceptable locally, or disallow
-   the negotiation of DH domain parameters.
-
-   The symmetric reply key size and Diffie-Hellman field size or RSA
-   modulus size should be chosen so as to provide sufficient
-   cryptographic security [RFC3766].
-
-   When MODP Diffie-Hellman is used, the exponents should have at least
-   twice as many bits as the symmetric keys that will be derived from
-   them [ODL99].
-
-   PKINIT raises certain security considerations beyond those that can
-   be regulated strictly in protocol definitions.  We will address them
-   in this section.
-
-   PKINIT extends the cross-realm model to the public-key
-   infrastructure.  Users of PKINIT must understand security policies
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 25]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   and procedures appropriate to the use of Public Key Infrastructures
-   [RFC3280].
-
-   In order to trust a KDC certificate that is certified by a CA as a
-   KDC certificate for a target realm (for example, by asserting the TGS
-   name of that Kerberos realm as an id-pkinit-san SAN and/or
-   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
-   as described in Section 3.2.4), the client MUST verify that the KDC
-   certificate's issuing CA is authorized to issue KDC certificates for
-   that target realm.  Otherwise, the binding between the KDC
-   certificate and the KDC of the target realm is not established.
-
-   How to validate this authorization is a matter of local policy.  A
-   way to achieve this is the configuration of specific sets of
-   intermediary CAs and trust anchors, one of which must be on the KDC
-   certificate's certification path [RFC3280]; and for each CA or trust
-   anchor the realms for which it is allowed to issue certificates.
-
-   In addition, if any CA is trusted to issue KDC certificates can also
-   issue other kinds of certificates, then local policy must be able to
-   distinguish between them: for example, it could require that KDC
-   certificates contain the id-pkinit-KPKdc EKU or that the realm be
-   specified with the id-pkinit-san SAN.
-
-   It is the responsibility of the PKI administrators for an
-   organization to ensure that KDC certificates are only issued to KDCs,
-   and that clients can ascertain this using their local policy.
-
-   Standard Kerberos allows the possibility of interactions between
-   cryptosystems of varying strengths; this document adds interactions
-   with public-key cryptosystems to Kerberos.  Some administrative
-   policies may allow the use of relatively weak public keys.  Using
-   such keys to wrap data encrypted under stronger conventional
-   cryptosystems may be inappropriate.
-
-   PKINIT requires keys for symmetric cryptosystems to be generated.
-   Some such systems contain "weak" keys.  For recommendations regarding
-   these weak keys, see [RFC4120].
-
-   PKINIT allows the use of the same RSA key pair for encryption and
-   signing when doing RSA encryption based key delivery.  This is not
-   recommended usage of RSA keys [RFC3447], by using DH based key
-   delivery this is avoided.
-
-   Care should be taken in how certificates are chosen for the purposes
-   of authentication using PKINIT.  Some local policies may require that
-   key escrow be used for certain certificate types.  Deployers of
-   PKINIT should be aware of the implications of using certificates that
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 26]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   have escrowed keys for the purposes of authentication.  Because
-   signing only certificates are normally not escrowed, by using DH
-   based key delivery this is avoided.
-
-   PKINIT does not provide for a "return routability" test to prevent
-   attackers from mounting a denial-of-service attack on the KDC by
-   causing it to perform unnecessary and expensive public-key
-   operations.  Strictly speaking, this is also true of standard
-   Kerberos, although the potential cost is not as great, because
-   standard Kerberos does not make use of public-key cryptography.  By
-   using DH based key delivery and reusing DH keys, the necessary crypto
-   processing cost per request can be minimized.
-
-   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
-   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
-   be used if the KDC itself vouches for the user's certificate.
-
-   When the Diffie-Hellman key exchange method is used, additional pre-
-   authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as
-   defined in this specification) is not bound to the AS_REQ by the
-   mechanisms discussed in this specification (meaning it may be dropped
-   or added by attackers without being detected by either the client or
-   the KDC).  Designers of additional pre-authentication data should
-   take that into consideration if such additional pre-authentication
-   data can be used in conjunction with the PA_PK_AS_REQ.  The future
-   work of the Kerberos working group is expected to update the hash
-   algorithms specified in this document and provide a generic mechanism
-   to bind additional pre-authentication data with the accompanying
-   AS_REQ.
-
-
-5.  Acknowledgements
-
-   The following people have made significant contributions to this
-   draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
-   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
-   Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
-   Grundman and Jeffrey Altman.
-
-   Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
-   Chris Walstad discovered a binding issue between the AS-REQ and AS-
-   REP in draft -26, the asChecksum field was added as the result.
-
-   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
-   Jonathan Trostle who wrote earlier versions of this document.
-
-   The authors are indebted to the Kerberos working group chair Jeffrey
-   Hutzelman who kept track of various issues and was enormously helpful
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 27]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   during the creation of this document.
-
-   Some of the ideas on which this document is based arose during
-   discussions over several years between members of the SAAG, the IETF
-   CAT working group, and the PSRG, regarding integration of Kerberos
-   and SPX.  Some ideas have also been drawn from the DASS system.
-   These changes are by no means endorsed by these groups.  This is an
-   attempt to revive some of the goals of those groups, and this
-   document approaches those goals primarily from the Kerberos
-   perspective.
-
-   Lastly, comments from groups working on similar ideas in DCE have
-   been invaluable.
-
-
-6.  IANA Considerations
-
-   This document has no actions for IANA.
-
-
-7.  References
-
-7.1.  Normative References
-
-   [IEEE1363]
-              IEEE, "Standard Specifications for Public Key 
-              Cryptography", IEEE 1363, 2000.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
-              RFC 2412, November 1998.
-
-   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
-              RFC 2631, June 1999.
-
-   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 28]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-              Algorithms", RFC 3370, August 2002.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
-              Encryption Algorithm in Cryptographic Message Syntax
-              (CMS)", RFC 3565, July 2003.
-
-   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
-              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
-              RFC 3766, April 2004.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
-              Encryption for Kerberos 5", RFC 3962, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 
-              Information technology - Abstract Syntax Notation One 
-              (ASN.1): Specification of basic notation.
-
-   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 
-              Information technology - ASN.1 encoding Rules: Specification 
-              of Basic Encoding Rules (BER), Canonical Encoding Rules 
-              (CER) and Distinguished Encoding Rules (DER).
-
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 29]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-7.2.  Informative References
-
-   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
-              Sizes", Journal of Cryptology 14 (2001) 255-293.
-   
-   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
-              future, Designs, Codes, and Cryptography (1999)".
-
-   [RFC4158]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
-              Nicholas, "Internet X.509 Public Key Infrastructure:
-              Certification Path Building", RFC 4158, September 2005.
-
-
-Appendix A.  PKINIT ASN.1 Module
-
-       KerberosV5-PK-INIT-SPEC {
-               iso(1) identified-organization(3) dod(6) internet(1)
-               security(5) kerberosV5(2) modules(4) pkinit(5)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       IMPORTS
-           SubjectPublicKeyInfo, AlgorithmIdentifier
-               FROM PKIX1Explicit88 { iso (1)
-                 identified-organization (3) dod (6) internet (1)
-                 security (5) mechanisms (5) pkix (7) id-mod (0)
-                 id-pkix1-explicit (18) }
-                 -- As defined in RFC 3280.
-
-           KerberosTime, PrincipalName, Realm, EncryptionKey
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) } ;
-
-       id-pkinit OBJECT IDENTIFIER ::=
-         { iso (1) org (3) dod (6) internet (1) security (5)
-           kerberosv5 (2) pkinit (3) }
-
-       id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-       id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-       id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-       id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-       id-pkinit-KPKdc         OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-       id-pkinit-san OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509SanAN (2) }
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 30]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-       pa-pk-as-req INTEGER ::=                  16
-       pa-pk-as-rep INTEGER ::=                  17
-
-       ad-initial-verified-cas INTEGER ::=        9
-
-       td-trusted-certifiers INTEGER ::=        104
-       td-invalid-certificates INTEGER ::=      105
-       td-dh-parameters INTEGER ::=             109
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- Contains a list of CAs, trusted by the client,
-                   -- that can be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 31]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so.
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 32]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING,
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 33]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is
-                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-                   -- eContent field contains the DER encoding of the
-                   -- type ReplyKeyPack.
-                   -- ReplyKeyPack is defined below.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL,
-                   -- Present if and only if dhKeyExpiration is
-                   -- present.
-          ...
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- The KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the pkAuthenticator field
-                   -- in the request if the DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if the DH keys are reused.
-                   -- If present, the KDC's DH public key MUST not be
-                   -- used past the point of this expiration time.
-                   -- If this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-       ReplyKeyPack ::= SEQUENCE {
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 34]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP, i.e. the
-                   -- AS reply key.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-       END
-
-
-Appendix B.  Test Vectors
-
-   Function octetstring2key() is defined in Section 3.2.3.1.  This
-   section describes a few sets of test vectors that would be useful for
-   implementers of octetstring2key().
-
-
-   Set 1
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 35]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
-     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
-
-
-   Set 2:
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
-     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
-
-
-   Set 3:
-   ======
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
-     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
-     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
-     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
-     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 36]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   Set 4:
-   =====
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
-     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
-
-
-Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
-             Implementations
-
-   Earlier revisions of the PKINIT I-D were implemented in various
-   releases of Microsoft Windows and deployed in fairly large numbers.
-   To enable the community to better interoperate with systems running
-   those releases, the following information may be useful.
-
-   KDC certificates issued by Windows 2000 Enterprise CAs contain a
-   dNSName SAN with the DNS name of the host running the KDC, and the
-   id-kp-serverAuth EKU [RFC3280].
-
-   KDC certificates issued by Windows 2003 Enterprise CAs contain a
-   dNSName SAN with the DNS name of the host running the KDC, the id-kp-
-   serverAuth EKU and the id-ms-kp-sc-logon EKU.
-
-   It is anticipated that the next release of Windows is already too far
-   along to allow it to support the issuing KDC certificates with id-
-   pkinit-san SAN as specified in this RFC.  Instead, they will have a
-   dNSName SAN containing the domain name of the KDC and the intended
-   purpose of these KDC certificates be restricted by the presence of
-   the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
-
-   In addition to checking that the above are present in a KDC
-   certificate, Windows clients verify that the issuer of the KDC
-   certificate is one of a set of allowed issuers of such certificates,
-   so those wishing to issue KDC certificates need to configure their
-   Windows clients appropriately.
-
-   Client certificates accepted by Windows 2000 and Windows 2003 Server
-   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
-   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 37]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-   contains a UTF8 encoded string whose value is that of the Directory
-   Service attribute UserPrincipalName of the client account object, and
-   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
-   certificate is to validate the client mapping (in other words, the
-   client's public key is bound to the account that has this
-   UserPrincipalName value).
-
-   It should be noted that all Microsoft Kerberos realm names are domain
-   style realm names and strictly in upper case.  In addition, the
-   UserPrincipalName attribute is globally unique in Windows 2000 and
-   Windows 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 38]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Brian Tung
-   USC Information Sciences Institute
-   4676 Admiralty Way Suite 1001
-   Marina del Rey, CA  90292
-   US
-
-   Email: brian@isi.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 39]
-
-Internet-Draft                   PKINIT                    December 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu & Tung                Expires June 15, 2006                [Page 40]
-
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-32.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-32.txt
deleted file mode 100644
index b575aaaed..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-32.txt
+++ /dev/null
@@ -1,2288 +0,0 @@
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                     Microsoft Corporation
-Expires: July 15, 2006                                           B. Tung
-                                      USC Information Sciences Institute
-                                                        January 11, 2006
-
-
-     Public Key Cryptography for Initial Authentication in Kerberos
-                   draft-ietf-cat-kerberos-pk-init-32
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 15, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes protocol extensions (hereafter called PKINIT)
-   to the Kerberos protocol specification.  These extensions provide a
-   method for integrating public key cryptography into the initial
-   authentication exchange, by using asymmetric-key signature and/or
-   encryption algorithms in pre-authentication data fields.
-
-
-
-
-
-Zhu & Tung                Expires July 15, 2006                 [Page 1]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
-   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  5
-     3.1.  Definitions, Requirements, and Constants . . . . . . . . .  6
-       3.1.1.  Required Algorithms  . . . . . . . . . . . . . . . . .  6
-       3.1.2.  Defined Message and Encryption Types . . . . . . . . .  6
-       3.1.3.  Algorithm Identifiers  . . . . . . . . . . . . . . . .  7
-     3.2.  PKINIT Pre-authentication Syntax and Use . . . . . . . . .  9
-       3.2.1.  Generation of Client Request . . . . . . . . . . . . .  9
-       3.2.2.  Receipt of Client Request  . . . . . . . . . . . . . . 13
-       3.2.3.  Generation of KDC Reply  . . . . . . . . . . . . . . . 17
-       3.2.4.  Receipt of KDC Reply . . . . . . . . . . . . . . . . . 24
-     3.3.  Interoperability Requirements  . . . . . . . . . . . . . . 25
-     3.4.  KDC Indication of PKINIT Support . . . . . . . . . . . . . 26
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
-   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 29
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 31
-   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 31
-   Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 36
-   Appendix C.  Miscellaneous Information about Microsoft Windows
-                PKINIT Implementations  . . . . . . . . . . . . . . . 38
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
-   Intellectual Property and Copyright Statements . . . . . . . . . . 41
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                Expires July 15, 2006                 [Page 2]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-1.  Introduction
-
-   The Kerberos V5 protocol [RFC4120] involves use of a trusted third
-   party known as the Key Distribution Center (KDC) to negotiate shared
-   session keys between clients and services and provide mutual
-   authentication between them.
-
-   The corner-stone of Kerberos V5 is the Ticket and the Authenticator.
-   A Ticket encapsulates a symmetric key (the ticket session key) in an
-   envelope (a public message) intended for a specific service.  The
-   contents of the Ticket are encrypted with a symmetric key shared
-   between the service principal and the issuing KDC.  The encrypted
-   part of the Ticket contains the client principal name, amongst other
-   items.  An Authenticator is a record that can be shown to have been
-   recently generated using the ticket session key in the associated
-   Ticket.  The ticket session key is known by the client who requested
-   the ticket.  The contents of the Authenticator are encrypted with the
-   associated ticket session key.  The encrypted part of an
-   Authenticator contains a timestamp and the client principal name,
-   amongst other items.
-
-   As shown in Figure 1 below, the Kerberos V5 protocol consists of the
-   following message exchanges between the client and the KDC, and the
-   client and the application service:
-
-    - The Authentication Service (AS) Exchange
-
-      The client obtains an "initial" ticket from the Kerberos
-      authentication server (AS), typically a Ticket Granting Ticket
-      (TGT).  The AS-REQ message and the AS-REP message are the request
-      and the reply message respectively between the client and the AS.
-
-    - The Ticket Granting Service (TGS) Exchange
-
-      The client subsequently uses the TGT to authenticate and request a
-      service ticket for a particular service, from the Kerberos ticket-
-      granting server (TGS).  The TGS-REQ message and the TGS-REP
-      message are the request and the reply message respectively between
-      the client and the TGS.
-
-    - The Client/Server Authentication Protocol (AP) Exchange
-
-      The client then makes a request with an AP-REQ message, consisting
-      of a service ticket and an authenticator that certifies the
-      client's possession of the ticket session key.  The server may
-      optionally reply with an AP-REP message.  AP exchanges typically
-      negotiate session specific symmetric keys.
-
-
-
-
-Zhu & Tung                Expires July 15, 2006                 [Page 3]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   Usually, the AS and TGS are integrated in a single device also known
-   as the KDC.
-
-      Figure 1:  The Message Exchanges in the Kerberos V5 Protocol
-
-                          +--------------+
-               +--------->|  KDC         |
-       AS-REQ /   +-------|              |
-             /   /        +--------------+
-            /   /          ^           |
-           /    |AS-REP   /            |
-          |     |        / TGS-REQ     + TGS-REP
-          |     |       /             /
-          |     |      /             /
-          |     |     /   +---------+
-          |     |    /   /
-          |     |   /   /
-          |     |  /   /
-          |     v /   v
-         ++-------+------+             +-----------------+
-         |  Client       +------------>|  Application    |
-         |               |    AP-REQ   |  Server         |
-         |               |<------------|                 |
-         +---------------+    AP-REP   +-----------------+
-
-   In the AS exchange, the KDC reply contains the ticket session key,
-   amongst other items, that is encrypted using a key (the AS reply key)
-   shared between the client and the KDC.  The AS reply key is typically
-   derived from the client's password for human users.  Therefore for
-   human users the attack resistance strength of the Kerberos protocol
-   is no stronger than the strength of their passwords.
-
-   The use of asymmetric cryptography in the form of X.509 certificates
-   [RFC3280] is popular for facilitating non-repudiation and perfect
-   secrecy.  An established Public Key Infrastructure (PKI) provides key
-   management and key distribution mechanisms that can be used to
-   establish authentication and secure communication.  Adding public-key
-   cryptography to Kerberos provides a nice congruence to public-key
-   protocols, obviates the human users' burden to manage strong
-   passwords, and allows Kerberized applications to take advantage of
-   existing key services and identity management.
-
-   The advantage afforded by the Kerberos TGT is that the client exposes
-   his long-term secrets only once.  The TGT and its associated session
-   key can then be used for any subsequent service ticket requests.  One
-   result of this is that all further authentication is independent of
-   the method by which the initial authentication was performed.
-   Consequently, initial authentication provides a convenient place to
-
-
-
-Zhu & Tung                Expires July 15, 2006                 [Page 4]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   integrate public-key cryptography into Kerberos authentication.  In
-   addition, the use of symmetric cryptography after the initial
-   exchange is preferred for performance.
-
-   This document describes the methods and data formats using which the
-   client and the KDC can use public and private key pairs to mutually
-   authenticate in the AS exchange and negotiate the AS reply key, known
-   only by the client and the KDC, to encrypt the AS-REP sent by the
-   KDC.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   In this protocol, both the client and the KDC have a public-private
-   key pair in order to prove their identities to each other over the
-   open network.  The term "signature key" is used to refer to the
-   private key of the key pair being used.
-
-   The encryption key used to encrypt the enc-part field of the KDC-REP
-   in the AS-REP [RFC4120] is referred to as the AS reply key.
-
-   An empty sequence in an optional field can be either included or
-   omitted: both encodings are permitted and considered equivalent.
-
-   The term "Modular Exponential Diffie-Hellman" is used to refer to the
-   Diffie-Hellman key exchange as described in [RFC2631], in order to
-   differentiate it from other equivalent representations of the same
-   key agreement algorithm.
-
-
-3.  Extensions
-
-   This section describes extensions to [RFC4120] for supporting the use
-   of public-key cryptography in the initial request for a ticket.
-
-   Briefly, this document defines the following extensions to [RFC4120]:
-
-   1. The client indicates the use of public-key authentication by
-      including a special preauthenticator in the initial request.  This
-      preauthenticator contains the client's public-key data and a
-      signature.
-
-
-
-
-
-
-Zhu & Tung                Expires July 15, 2006                 [Page 5]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   2. The KDC tests the client's request against its authentication
-      policy and trusted Certification Authorities (CAs).
-
-   3. If the request passes the verification tests, the KDC replies as
-      usual, but the reply is encrypted using either:
-
-      a. a key generated through a Diffie-Hellman (DH) key exchange
-         [RFC2631] [IEEE1363] with the client, signed using the KDC's
-         signature key; or
-
-      b. a symmetric encryption key, signed using the KDC's signature
-         key and encrypted using the client's public key.
-
-      Any keying material required by the client to obtain the
-      encryption key for decrypting the KDC reply is returned in a pre-
-      authentication field accompanying the usual reply.
-
-   4. The client validates the KDC's signature, obtains the encryption
-      key, decrypts the reply, and then proceeds as usual.
-
-   Section 3.1 of this document enumerates the required algorithms and
-   necessary extension message types.  Section 3.2 describes the
-   extension messages in greater detail.
-
-3.1.  Definitions, Requirements, and Constants
-
-3.1.1.  Required Algorithms
-
-   All PKINIT implementations MUST support the following algorithms:
-
-   o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
-      sha1-96 [RFC3962].
-
-   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
-
-   o  AS reply key delivery method: Diffie-Hellman key exchange
-      [RFC2631].
-
-   In addition, implementations of this specification MUST be capable of
-   processing the Extended Key Usage (EKU) extension and the id-pkinit-
-   san (as defined in Section 3.2.2) otherName of the Subject
-   Alternative Name (SAN) extension in X.509 certificates [RFC3280], if
-   present.
-
-3.1.2.  Defined Message and Encryption Types
-
-   PKINIT makes use of the following new pre-authentication types:
-
-
-
-
-Zhu & Tung                Expires July 15, 2006                 [Page 6]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-       PA_PK_AS_REQ                                 16
-       PA_PK_AS_REP                                 17
-
-   PKINIT also makes use of the following new authorization data type:
-
-       AD_INITIAL_VERIFIED_CAS                       9
-
-   PKINIT introduces the following new error codes:
-
-       KDC_ERR_CLIENT_NOT_TRUSTED                   62
-       KDC_ERR_INVALID_SIG                          64
-       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
-       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
-       KDC_ERR_INVALID_CERTIFICATE                  71
-       KDC_ERR_REVOKED_CERTIFICATE                  72
-       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
-       KDC_ERR_CLIENT_NAME_MISMATCH                 75
-       KDC_ERR_INCONSISTENT_KEY_PURPOSE             77
-       KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED          78
-       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED         79
-       KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED   80
-
-   PKINIT uses the following typed data types for errors:
-
-       TD_TRUSTED_CERTIFIERS                       104
-       TD_INVALID_CERTIFICATES                     105
-       TD_DH_PARAMETERS                            109
-
-   The ASN.1 module for all structures defined in this document (plus
-   IMPORT statements for all imported structures) is given in
-   Appendix A.
-
-   All structures defined in or imported into this document MUST be
-   encoded using Distinguished Encoding Rules (DER) [X680] [X690]
-   (unless otherwise noted).  All data structures carried in OCTET
-   STRINGs must be encoded according to the rules specified in
-   corresponding specifications.
-
-   Interoperability note: Some implementations may not be able to decode
-   wrapped CMS objects encoded with BER; specifically, they may not be
-   able to decode indefinite length encodings.  To maximize
-   interoperability, implementers SHOULD encode CMS objects used in
-   PKINIT with DER.
-
-3.1.3.  Algorithm Identifiers
-
-   PKINIT does not define, but does make use of, the following algorithm
-   identifiers.
-
-
-
-Zhu & Tung                Expires July 15, 2006                 [Page 7]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   PKINIT uses the following algorithm identifier(s) for Modular
-   Exponential Diffie-Hellman key agreement [RFC2631] [RFC3279]:
-
-       dhpublicnumber (as described in [RFC3279])
-
-   PKINIT uses the following signature algorithm identifiers as defined
-   in [RFC3279]:
-
-       sha-1WithRSAEncryption (RSA with SHA1)
-       md5WithRSAEncryption   (RSA with MD5)
-       id-dsa-with-sha1       (DSA with SHA1)
-
-   PKINIT uses the following encryption algorithm identifiers as defined
-   in [RFC3447] for encrypting the temporary key with a public key:
-
-       rsaEncryption
-       id-RSAES-OAEP
-
-   PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
-   for encrypting the AS reply key with the temporary key:
-
-       des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370])
-       rc2-cbc       (RC2, CBC mode, as defined in [RFC3370])
-       id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565])
-
-   PKINIT defines the following encryption types, for use in the etype
-   field of the AS-REQ [RFC4120] message to indicate acceptance of the
-   corresponding algorithms that can used by Cryptographic Message
-   Syntax (CMS) [RFC3852] messages in the reply:
-
-       id-dsa-with-sha1-CmsOID                       9
-          -- Indicates that the client supports id-dsa-with-sha1.
-       md5WithRSAEncryption-CmsOID                  10
-          -- Indicates that the client supports md5WithRSAEncryption.
-       sha-1WithRSAEncryption-CmsOID                11
-          -- Indicates that the client supports sha-1WithRSAEncryption.
-       rc2-cbc-EnvOID                               12
-          -- Indicates that the client supports rc2-cbc.
-       rsaEncryption-EnvOID                         13
-          -- Indicates that the client supports rsaEncryption.
-       id-RSAES-OAEP-EnvOID                         14
-          -- Indicates that the client supports id-RSAES-OAEP.
-       des-ede3-cbc-EnvOID                          15
-          -- Indicates that the client supports des-ede3-cbc.
-
-
-
-
-
-
-
-Zhu & Tung                Expires July 15, 2006                 [Page 8]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-3.2.  PKINIT Pre-authentication Syntax and Use
-
-   This section defines the syntax and use of the various pre-
-   authentication fields employed by PKINIT.
-
-3.2.1.  Generation of Client Request
-
-   The initial authentication request (AS-REQ) is sent as per [RFC4120];
-   in addition, a pre-authentication data element, whose padata-type is
-   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
-   type PA-PK-AS-REQ, is included.
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- Contains a list of CAs, trusted by the client,
-                   -- that can be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-
-
-
-Zhu & Tung                Expires July 15, 2006                 [Page 9]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so (see Section 3.2.3.1).
-          ...
-       }
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 10]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING OPTIONAL,
-                   -- MUST be present.
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure contained in the signedAuthPack
-   field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
-   is filled out as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is id-pkinit-
-       authData: { iso(1) org(3) dod(6) internet(1) security(5)
-       kerberosv5(2) pkinit(3) authData(1) }.  Notes to CMS
-       implementers: the signed attribute content-type MUST be present
-       in this SignedData instance and its value is id-pkinit-authData
-       according to [RFC3852].
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type AuthPack.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type AuthPack.
-
-   5.  The AuthPack structure contains a PKAuthenticator, the client
-       public key information, the CMS encryption types supported by the
-       client and a DHNonce.  The pkAuthenticator field certifies to the
-       KDC that the client has recent knowledge of the signing key that
-       authenticates the client.  The clientPublicValue field specifies
-       Diffie-Hellman domain parameters and the client's public key
-       value.  The DH public key value is encoded as a BIT STRING
-       according to [RFC3279].  The clientPublicValue field is present
-       only if the client wishes to use the Diffie-Hellman key agreement
-       method.  The supportedCMSTypes field specifies the list of CMS
-       encryption types supported by the client in order of (decreasing)
-       preference.  The clientDHNonce field is described later in this
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 11]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-       section.
-
-   6.  The ctime field in the PKAuthenticator structure contains the
-       current time on the client's host, and the cusec field contains
-       the microsecond part of the client's timestamp.  The ctime and
-       cusec fields are used together to specify a reasonably accurate
-       timestamp [RFC4120].  The nonce field is chosen randomly.  The
-       paChecksum field MUST be present and it contains a SHA1 checksum
-       that is performed over the KDC-REQ-BODY [RFC4120].  In order to
-       ease future migration from the use of SHA1, the paChecksum field
-       is made optional syntactically: when the request is extended to
-       negotiate hash algorithms, the new client wishing not to use SHA1
-       will send the request in the extended message syntax without the
-       paChecksum field.  The KDC conforming to this specification MUST
-       return a KRB-ERROR [RFC4120] message with the code
-       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3).  That
-       will allow a new client to retry with SHA1 if allowed by the
-       local policy.
-
-   7.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the KDC can verify the signature over the
-       type AuthPack.  For path validation, these certificates SHOULD be
-       sufficient to construct at least one certification path from the
-       client certificate to one trust anchor acceptable by the KDC
-       [RFC4158].  The client MUST be capable of including such a set of
-       certificates if configured to do so.  The certificates field MUST
-       NOT contain "root" CA certificates.
-
-   8.  The client's Diffie-Hellman public value (clientPublicValue) is
-       included if and only if the client wishes to use the Diffie-
-       Hellman key agreement method.  The Diffie-Hellman domain
-       parameters [IEEE1363] for the client's public key are specified
-       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
-       and the client's Diffie-Hellman public key value is mapped to a
-       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
-       using the Diffie-Hellman key agreement method, implementations
-       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
-       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
-       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
-       group 16 [RFC3526].
-
-       The Diffie-Hellman field size should be chosen so as to provide
-       sufficient cryptographic security [RFC3766].
-
-       When MODP Diffie-Hellman is used, the exponents should have at
-       least twice as many bits as the symmetric keys that will be
-       derived from them [ODL99].
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 12]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   9.  The client may wish to reuse DH keys or to allow the KDC to do so
-       (see Section 3.2.3.1).  If so, then the client includes the
-       clientDHNonce field.  This nonce string MUST be as long as the
-       longest key length of the symmetric key types that the client
-       supports.  This nonce MUST be chosen randomly.
-
-   The ExternalPrincipalIdentifier structure is used in this document to
-   identify the subject's public key thereby the subject principal.
-   This structure is filled out as follows:
-
-   1.  The subjectName field contains a PKIX type Name encoded according
-       to [RFC3280].  This field identifies the certificate subject by
-       the distinguished subject name.  This field is REQUIRED when
-       there is a distinguished subject name present in the certificate
-       being used.
-
-   2.  The issuerAndSerialNumber field contains a CMS type
-       IssuerAndSerialNumber encoded according to [RFC3852].  This field
-       identifies a certificate of the subject.  This field is REQUIRED
-       for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
-       structures are defined in Section 3.2.2).
-
-   3.  The subjectKeyIdentifier [RFC3852] field identifies the subject's
-       public key by a key identifier.  When an X.509 certificate is
-       referenced, this key identifier matches the X.509
-       subjectKeyIdentifier extension value.  When other certificate
-       formats are referenced, the documents that specify the
-       certificate format and their use with the CMS must include
-       details on matching the key identifier to the appropriate
-       certificate field.  This field is RECOMMENDED for TD-TRUSTED-
-       CERTIFIERS (as defined in Section 3.2.2).
-
-   The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
-   of CAs, trusted by the client, that can be used to certify the KDC.
-   Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
-   (thereby its public key).
-
-   The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
-   SignerIdentifier encoded according to [RFC3852].  This field
-   identifies, if present, a particular KDC public key that the client
-   already has.
-
-3.2.2.  Receipt of Client Request
-
-   Upon receiving the client's request, the KDC validates it.  This
-   section describes the steps that the KDC MUST (unless otherwise
-   noted) take in validating the request.
-
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 13]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   The KDC verifies the client's signature in the signedAuthPack field
-   according to [RFC3852].
-
-   If, while validating the client's X.509 certificate [RFC3280], the
-   KDC cannot build a certification path to validate the client's
-   certificate, it sends back a KRB-ERROR [RFC4120] message with the
-   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
-   this error message is a TYPED-DATA (as defined in [RFC4120]) that
-   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
-   whose data-value contains the DER encoding of the type TD-TRUSTED-
-   CERTIFIERS:
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
-   TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
-   (thereby its public key) trusted by the KDC.
-
-   Upon receiving this error message, the client SHOULD retry only if it
-   has a different set of certificates (from those of the previous
-   requests) that form a certification path (or a partial path) from one
-   of the trust anchors acceptable by the KDC to its own certificate.
-
-   If, while processing the certification path, the KDC determines that
-   the signature on one of the certificates in the signedAuthPack field
-   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
-   message is a TYPED-DATA that contains an element whose data-type is
-   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
-   encoding of the type TD-INVALID-CERTIFICATES:
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
-   TD-INVALID-CERTIFICATES structure identifies a certificate (that was
-   sent by the client) with an invalid signature.
-
-   If more than one X.509 certificate signature is invalid, the KDC MAY
-   include one IssuerAndSerialNumber per invalid signature within the
-   TD-INVALID-CERTIFICATES.
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 14]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   The client's X.509 certificate is validated according to [RFC3280].
-
-   Based on local policy, the KDC may also check whether any X.509
-   certificates in the certification path validating the client's
-   certificate have been revoked.  If any of them have been revoked, the
-   KDC MUST return an error message with the code
-   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
-   revocation status but is unable to do so, it SHOULD return an error
-   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
-   certificate or certificates affected are identified exactly as for
-   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
-
-   Note that the TD_INVALID_CERTIFICATES error data is only used to
-   identify invalid certificates sent by the client in the request.
-
-   The client's public key is then used to verify the signature.  If the
-   signature fails to verify, the KDC MUST return an error message with
-   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
-   this error message.
-
-   In addition to validating the client's signature, the KDC MUST also
-   check that the client's public key used to verify the client's
-   signature is bound to the client's principal name as specified in the
-   AS-REQ as follows:
-
-   1. If the KDC has its own binding between either the client's
-      signature-verification public key or the client's certificate and
-      the client's Kerberos principal name, it uses that binding.
-
-   2. Otherwise, if the client's X.509 certificate contains a Subject
-      Alternative Name (SAN) extension carrying a KRB5PrincipalName
-      (defined below) in the otherName field of the type GeneralName
-      [RFC3280], it binds the client's X.509 certificate to that name.
-
-      The type of the otherName field is AnotherName.  The type-id field
-      of the type AnotherName is id-pkinit-san:
-
-       id-pkinit-san OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509SanAN (2) }
-
-      And the value field of the type AnotherName is a
-      KRB5PrincipalName.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 15]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   If the KDC does not have its own binding and there is no
-   KRB5PrincipalName name present in the client's X.509 certificate, or
-   if the Kerberos name in the request does not match the
-   KRB5PrincipalName in the client's X.509 certificate (including the
-   realm name), the KDC MUST return an error message with the code
-   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
-   this error message.
-
-   Even if the certification path is validated and the certificate is
-   mapped to the client's principal name, the KDC may decide not to
-   accept the client's certificate, depending on local policy.
-
-   The KDC MAY require the presence of an Extended Key Usage (EKU)
-   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
-   of the client's X.509 certificate:
-
-       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) keyPurposeClientAuth(4) }
-              -- PKINIT client authentication.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   The digitalSignature key usage bit [RFC3280] MUST be asserted when
-   the intended purpose of the client's X.509 certificate is restricted
-   with the id-pkinit-KPClientAuth EKU.
-
-   If this EKU KeyPurposeId is required but it is not present or if the
-   client certificate is restricted not to be used for PKINIT client
-   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
-   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
-   is no accompanying e-data for this error message.  KDCs implementing
-   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
-   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
-   are a large number of X.509 client certificates deployed for use with
-   PKINIT which have this EKU.
-
-   As a matter of local policy, the KDC MAY decide to reject requests on
-   the basis of the absence or presence of other specific EKU OID's.
-
-   If the digest algorithm used in generating the CA signature for the
-   public key in any certificate of the request is not acceptable by the
-   KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED.  The accompanying e-data MUST be
-   encoded in TYPED-DATA although none is defined at this point.
-
-   If the client's public key is not accepted with reasons other than
-   what were specified above, the KDC returns a KRB-ERROR [RFC4120]
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 16]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.  There is no
-   accompanying e-data currently defined for this error message.
-
-   The KDC MUST check the timestamp to ensure that the request is not a
-   replay, and that the time skew falls within acceptable limits.  The
-   recommendations for clock skew times in [RFC4120] apply here.  If the
-   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
-   KRB_AP_ERR_SKEW, respectively.
-
-   If the clientPublicValue is filled in, indicating that the client
-   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
-   check to see if the key parameters satisfy its policy.  If they do
-   not, it MUST return an error message with the code
-   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
-   TYPED-DATA that contains an element whose data-type is
-   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
-   the type TD-DH-PARAMETERS:
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-
-   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
-   that the KDC supports in decreasing preference order, from which the
-   client SHOULD pick one to retry the request.
-
-   The AlgorithmIdentifier structure is defined in [RFC3280] and is
-   filled in according to [RFC3279].  More specifically Section 2.3.3 of
-   [RFC3279] describes how to fill in the AlgorithmIdentifier structure
-   in the case where MODP Diffie-Hellman key exchange is used.
-
-   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
-   KDC does not possess the corresponding key, the KDC MUST ignore the
-   kdcPkId field as if the client did not include one.
-
-   If the digest algorithm used by the id-pkinit-authData is not
-   acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
-   message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
-   The accompanying e-data MUST be encoded in TYPED-DATA although none
-   is defined at this point.
-
-3.2.3.  Generation of KDC Reply
-
-   If the paChecksum filed in the request is not present, the KDC
-   conforming to this specification MUST return a KRB-ERROR [RFC4120]
-   message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED.  The
-   accompanying e-data MUST be encoded in TYPED-DATA (no error data is
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 17]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   defined by this specification).
-
-   Assuming that the client's request has been properly validated, the
-   KDC proceeds as per [RFC4120], except as follows.
-
-   The KDC MUST set the initial flag and include an authorization data
-   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
-   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
-   type AD-INITIAL-VERIFIED-CAS:
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   The AD-INITIAL-VERIFIED-CAS structure identifies the certification
-   path based on which the client certificate was validated.  Each
-   ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
-   INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
-   (thereby its public key).
-
-   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-   containers if the list of CAs satisfies the AS' realm's local policy
-   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
-   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
-   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
-   resulting ticket.  If the list of CAs satisfies the local KDC's
-   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
-   container, otherwise it MAY unwrap the authorization data out of the
-   AD-IF-RELEVANT container.
-
-   Application servers that understand this authorization data type
-   SHOULD apply local policy to determine whether a given ticket bearing
-   such a type *not* contained within an AD-IF-RELEVANT container is
-   acceptable.  (This corresponds to the AP server checking the
-   transited field when the TRANSITED-POLICY-CHECKED flag has not been
-   set [RFC4120].)  If such a data type is contained within an AD-IF-
-   RELEVANT container, AP servers MAY apply local policy to determine
-   whether the authorization data is acceptable.
-
-   A pre-authentication data element, whose padata-type is PA_PK_AS_REP
-   and whose padata-value contains the DER encoding of the type PA-PK-
-   AS-REP (defined below), is included in the AS-REP [RFC4120].
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 18]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is
-                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-                   -- eContent field contains the DER encoding of the
-                   -- type ReplyKeyPack.
-                   -- ReplyKeyPack is defined in Section 3.2.3.2.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL,
-                   -- Present if and only if dhKeyExpiration is
-                   -- present in the KDCDHKeyInfo.
-          ...
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- The KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the pkAuthenticator field
-                   -- in the request if the DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 19]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if the DH keys are reused.
-                   -- If present, the KDC's DH public key MUST not be
-                   -- used past the point of this expiration time.
-                   -- If this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
-   KDC encrypts the reply as usual, but not with the client's long-term
-   key.  Instead, it encrypts it with either a shared key derived from a
-   Diffie-Hellman exchange, or a generated encryption key.  The contents
-   of the PA-PK-AS-REP indicate which key delivery method is used.
-
-   In addition, the lifetime of the ticket returned by the KDC MUST NOT
-   exceed that of the client's public-private key pair.  The ticket
-   lifetime, however, can be shorter than that of the client's public-
-   private key pair.  For the implementations of this specification, the
-   lifetime of the client's public-private key pair is the validity
-   period in X.509 certificates [RFC3280], unless configured otherwise.
-
-3.2.3.1.  Using Diffie-Hellman Key Exchange
-
-   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
-
-   The ContentInfo [RFC3852] structure for the dhSignedData field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is the OID value
-       for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
-       security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.  Notes to CMS
-       implementers: the signed attribute content-type MUST be present
-       in this SignedData instance and its value is id-pkinit-DHKeyData
-       according to [RFC3852].
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type KDCDHKeyInfo.
-
-   4.  The KDCDHKeyInfo structure contains the KDC's public key, a nonce
-       and optionally the expiration time of the KDC's DH key being
-       reused.  The subjectPublicKey field of the type KDCDHKeyInfo
-       field identifies KDC's DH public key.  This DH public key value
-       is encoded as a BIT STRING according to [RFC3279].  The nonce
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 20]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-       field contains the nonce in the pkAuthenticator field in the
-       request if the DH keys are NOT reused.  The value of this nonce
-       field is 0 if the DH keys are reused.  The dhKeyExpiration field
-       is present if and only if the DH keys are reused.  If the
-       dhKeyExpiration field is present, the KDC's public key in this
-       KDCDHKeyInfo structure MUST NOT be used past the point of this
-       expiration time.  If this field is omitted then the serverDHNonce
-       field MUST also be omitted.
-
-   5.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type
-       KDCDHKeyInfo.
-
-   6.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type KDCDHKeyInfo.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may be left empty if the KDC
-       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
-       used for signing.  Otherwise, for path validation, these
-       certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [RFC4158].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  If the client included the clientDHNonce field, then the KDC may
-       choose to reuse its DH keys.  If the server reuses DH keys then
-       it MUST include an expiration time in the dhKeyExpiration field.
-       Past the point of the expiration time, the signature over the
-       type DHRepInfo is considered expired/invalid.  When the server
-       reuses DH keys then it MUST include a serverDHNonce at least as
-       long as the length of keys for the symmetric encryption system
-       used to encrypt the AS reply.  Note that including the
-       serverDHNonce changes how the client and server calculate the key
-       to use to encrypt the reply; see below for details.  The KDC
-       SHOULD NOT reuse DH keys unless the clientDHNonce field is
-       present in the request.
-
-   The AS reply key is derived as follows:
-
-   1. Both the KDC and the client calculate the shared secret value as
-      follows:
-
-
-
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 21]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-
-      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
-         shared secret value.  DHSharedSecret is the value ZZ as
-         described in Section 2.1.1 of [RFC2631].
-
-      DHSharedSecret is first padded with leading zeros such that the
-      size of DHSharedSecret in octets is the same as that of the
-      modulus, then represented as a string of octets in big-endian
-      order.
-
-      Implementation note: Both the client and the KDC can cache the
-      triple (ya, yb, DHSharedSecret), where ya is the client's public
-      key and yb is the KDC's public key.  If both ya and yb are the
-      same in a later exchange, the cached DHSharedSecret can be used.
-
-   2. Let K be the key-generation seed length [RFC3961] of the AS reply
-      key whose enctype is selected according to [RFC4120].
-
-   3. Define the function octetstring2key() as follows:
-
-           octetstring2key(x) == random-to-key(K-truncate(
-                                    SHA1(0x00 | x) |
-                                    SHA1(0x01 | x) |
-                                    SHA1(0x02 | x) |
-                                    ...
-                                    ))
-
-      where x is an octet string; | is the concatenation operator; 0x00,
-      0x01, 0x02, etc., are each represented as a single octet; random-
-      to-key() is an operation that generates a protocol key from a
-      bitstring of length K; and K-truncate truncates its input to the
-      first K bits.  Both K and random-to-key() are as defined in the
-      kcrypto profile [RFC3961] for the enctype of the AS reply key.
-
-   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
-      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
-      strings.
-
-   5. The AS reply key k is:
-
-           k = octetstring2key(DHSharedSecret | n_c | n_k)
-
-3.2.3.2.  Using Public Key Encryption
-
-   In this case, the PA-PK-AS-REP contains the encKeyPack field where
-   the AS reply key is encrypted.
-
-   The ContentInfo [RFC3852] structure for the encKeyPack field is
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 22]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-envelopedData
-       (as defined in [RFC3852]), and the content field is an
-       EnvelopedData (as defined in [RFC3852]).
-
-   2.  The contentType field for the type EnvelopedData is id-
-       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
-       pkcs (1) pkcs7 (7) signedData (2) }.
-
-   3.  The eContentType field for the inner type SignedData (when
-       decrypted from the encryptedContent field for the type
-       EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
-       internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
-       Notes to CMS implementers: the signed attribute content-type MUST
-       be present in this SignedData instance and its value is id-
-       pkinit-rkeyData according to [RFC3852].
-
-   4.  The eContent field for the inner type SignedData contains the DER
-       encoding of the type ReplyKeyPack (as described below).
-
-   5.  The signerInfos field of the inner type SignedData contains a
-       single signerInfo, which contains the signature for the type
-       ReplyKeyPack.
-
-   6.  The certificates field of the inner type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       for the type ReplyKeyPack.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may be left empty if the KDC
-       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
-       used for signing.  Otherwise, for path validation, these
-       certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [RFC4158].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  The recipientInfos field of the type EnvelopedData is a SET which
-       MUST contain exactly one member of type KeyTransRecipientInfo.
-       The encryptedKey of this member contains the temporary key which
-       is encrypted using the client's public key.
-
-   8.  The unprotectedAttrs or originatorInfo fields of the type
-       EnvelopedData MAY be present.
-
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 23]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   If there is a supportedCMSTypes field in the AuthPack, the KDC must
-   check to see if it supports any of the listed types.  If it supports
-   more than one of the types, the KDC SHOULD use the one listed first.
-   If it does not support any of them, it MUST return an error message
-   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
-
-   Furthermore the KDC computes the checksum of the AS-REQ in the client
-   request.  This checksum is performed over the type AS-REQ and the
-   protocol key [RFC3961] of the checksum operation is the replyKey and
-   the key usage number is 6.  If the replyKey's enctype is "newer"
-   [RFC4120] [RFC4121], the checksum operation is the required checksum
-   operation [RFC3961] of that enctype.
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP, i.e. the
-                   -- AS reply key.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-   Implementations of this RSA encryption key delivery method are
-   RECOMMENDED to support RSA keys at least 2048 bits in size.
-
-3.2.4.  Receipt of KDC Reply
-
-   Upon receipt of the KDC's reply, the client proceeds as follows.  If
-   the PA-PK-AS-REP contains the dhSignedData field, the client derives
-   the AS reply key using the same procedure used by the KDC as defined
-   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
-   field, and the client decrypts and extracts the temporary key in the
-   encryptedKey field of the member KeyTransRecipientInfo, and then uses
-   that as the AS reply key.
-
-   If the public key encryption method is used, the client MUST verify
-   the asChecksum contained in the ReplyKeyPack.
-
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 24]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   In either case, the client MUST verify the signature in the
-   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
-   be validated according to [RFC3280].  In addition, unless the client
-   can otherwise verify that the public key used to verify the KDC's
-   signature is bound to the KDC of the target realm, the KDC's X.509
-   certificate MUST contain a Subject Alternative Name extension
-   [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
-   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
-   matches the name of the TGS of the target realm (as defined in
-   Section 7.3 of [RFC4120]).
-
-   Unless the client knows by some other means that the KDC certificate
-   is intended for a Kerberos KDC, the client MUST require that the KDC
-   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
-
-       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) keyPurposeKdc(5) }
-              -- Signing KDC responses.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   The digitalSignature key usage bit [RFC3280] MUST be asserted when
-   the intended purpose of the KDC's X.509 certificate is restricted
-   with the id-pkinit-KPKdc EKU.
-
-   If the KDC certificate contains the Kerberos TGS name encoded as an
-   id-pkinit-san SAN, this certificate is certified by the issuing CA as
-   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
-
-   If all applicable checks are satisfied, the client then decrypts the
-   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
-   and then proceeds as described in [RFC4120].
-
-   Implementation note: CAs issuing KDC certificates SHOULD place all
-   "short" and "fully-qualified" Kerberos realm names of the KDC (one
-   per GeneralName [RFC3280]) into the KDC certificate to allow maximum
-   flexibility.
-
-3.3.  Interoperability Requirements
-
-   The client MUST be capable of sending a set of certificates
-   sufficient to allow the KDC to construct a certification path for the
-   client's certificate, if the correct set of certificates is provided
-   through configuration or policy.
-
-   If the client sends all the X.509 certificates on a certification
-   path to a trust anchor acceptable by the KDC, and the KDC can not
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 25]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   verify the client's public key otherwise, the KDC MUST be able to
-   process path validation for the client's certificate based on the
-   certificates in the request.
-
-   The KDC MUST be capable of sending a set of certificates sufficient
-   to allow the client to construct a certification path for the KDC's
-   certificate, if the correct set of certificates is provided through
-   configuration or policy.
-
-   If the KDC sends all the X.509 certificates on a certification path
-   to a trust anchor acceptable by the client, and the client can not
-   verify the KDC's public key otherwise, the client MUST be able to
-   process path validation for the KDC's certificate based on the
-   certificates in the reply.
-
-3.4.  KDC Indication of PKINIT Support
-
-   If pre-authentication is required, but was not present in the
-   request, per [RFC4120] an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
-   stored in the e-data field of the KRB-ERROR message to specify which
-   pre-authentication mechanisms are acceptable.  The KDC can then
-   indicate the support of PKINIT by including an empty element whose
-   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
-
-   Otherwise if it is required by the KDC's local policy that the client
-   must be pre-authenticated using the pre-authentication mechanism
-   specified in this document, but no PKINIT pre-authentication was
-   present in the request, an error message with the code
-   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
-
-   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
-   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
-   STRING), and clients MUST ignore this and any other value.  Future
-   extensions to this protocol may specify other data to send instead of
-   an empty OCTET STRING.
-
-
-4.  Security Considerations
-
-   Kerberos error messages are not integrity protected, as a result, the
-   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
-   with by an attacker so that the set of domain parameters selected
-   could be either weaker or not mutually preferred.  Local policy can
-   configure sets of domain parameters acceptable locally, or disallow
-   the negotiation of DH domain parameters.
-
-   The symmetric reply key size and Diffie-Hellman field size or RSA
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 26]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   modulus size should be chosen so as to provide sufficient
-   cryptographic security [RFC3766].
-
-   When MODP Diffie-Hellman is used, the exponents should have at least
-   twice as many bits as the symmetric keys that will be derived from
-   them [ODL99].
-
-   PKINIT raises certain security considerations beyond those that can
-   be regulated strictly in protocol definitions.  We will address them
-   in this section.
-
-   PKINIT extends the cross-realm model to the public-key
-   infrastructure.  Users of PKINIT must understand security policies
-   and procedures appropriate to the use of Public Key Infrastructures
-   [RFC3280].
-
-   In order to trust a KDC certificate that is certified by a CA as a
-   KDC certificate for a target realm (for example, by asserting the TGS
-   name of that Kerberos realm as an id-pkinit-san SAN and/or
-   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
-   as described in Section 3.2.4), the client MUST verify that the KDC
-   certificate's issuing CA is authorized to issue KDC certificates for
-   that target realm.  Otherwise, the binding between the KDC
-   certificate and the KDC of the target realm is not established.
-
-   How to validate this authorization is a matter of local policy.  A
-   way to achieve this is the configuration of specific sets of
-   intermediary CAs and trust anchors, one of which must be on the KDC
-   certificate's certification path [RFC3280]; and for each CA or trust
-   anchor the realms for which it is allowed to issue certificates.
-
-   In addition, if any CA is trusted to issue KDC certificates can also
-   issue other kinds of certificates, then local policy must be able to
-   distinguish between them: for example, it could require that KDC
-   certificates contain the id-pkinit-KPKdc EKU or that the realm be
-   specified with the id-pkinit-san SAN.
-
-   It is the responsibility of the PKI administrators for an
-   organization to ensure that KDC certificates are only issued to KDCs,
-   and that clients can ascertain this using their local policy.
-
-   Standard Kerberos allows the possibility of interactions between
-   cryptosystems of varying strengths; this document adds interactions
-   with public-key cryptosystems to Kerberos.  Some administrative
-   policies may allow the use of relatively weak public keys.  Using
-   such keys to wrap data encrypted under stronger conventional
-   cryptosystems may be inappropriate.
-
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 27]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   PKINIT requires keys for symmetric cryptosystems to be generated.
-   Some such systems contain "weak" keys.  For recommendations regarding
-   these weak keys, see [RFC4120].
-
-   PKINIT allows the use of the same RSA key pair for encryption and
-   signing when doing RSA encryption based key delivery.  This is not
-   recommended usage of RSA keys [RFC3447], by using DH based key
-   delivery this is avoided.
-
-   Care should be taken in how certificates are chosen for the purposes
-   of authentication using PKINIT.  Some local policies may require that
-   key escrow be used for certain certificate types.  Deployers of
-   PKINIT should be aware of the implications of using certificates that
-   have escrowed keys for the purposes of authentication.  Because
-   signing only certificates are normally not escrowed, by using DH
-   based key delivery this is avoided.
-
-   PKINIT does not provide for a "return routability" test to prevent
-   attackers from mounting a denial-of-service attack on the KDC by
-   causing it to perform unnecessary and expensive public-key
-   operations.  Strictly speaking, this is also true of standard
-   Kerberos, although the potential cost is not as great, because
-   standard Kerberos does not make use of public-key cryptography.  By
-   using DH based key delivery and reusing DH keys, the necessary crypto
-   processing cost per request can be minimized.
-
-   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
-   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
-   be used if the KDC itself vouches for the user's certificate.
-
-   When the Diffie-Hellman key exchange method is used, additional pre-
-   authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as
-   defined in this specification) is not bound to the AS_REQ by the
-   mechanisms discussed in this specification (meaning it may be dropped
-   or added by attackers without being detected by either the client or
-   the KDC).  Designers of additional pre-authentication data should
-   take that into consideration if such additional pre-authentication
-   data can be used in conjunction with the PA_PK_AS_REQ.  The future
-   work of the Kerberos working group is expected to update the hash
-   algorithms specified in this document and provide a generic mechanism
-   to bind additional pre-authentication data with the accompanying
-   AS_REQ.
-
-
-5.  Acknowledgements
-
-   The following people have made significant contributions to this
-   draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 28]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
-   Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
-   Grundman and Jeffrey Altman.
-
-   Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
-   Chris Walstad discovered a binding issue between the AS-REQ and AS-
-   REP in draft -26, the asChecksum field was added as the result.
-
-   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
-   Jonathan Trostle who wrote earlier versions of this document.
-
-   The authors are indebted to the Kerberos working group chair Jeffrey
-   Hutzelman who kept track of various issues and was enormously helpful
-   during the creation of this document.
-
-   Some of the ideas on which this document is based arose during
-   discussions over several years between members of the SAAG, the IETF
-   CAT working group, and the PSRG, regarding integration of Kerberos
-   and SPX.  Some ideas have also been drawn from the DASS system.
-   These changes are by no means endorsed by these groups.  This is an
-   attempt to revive some of the goals of those groups, and this
-   document approaches those goals primarily from the Kerberos
-   perspective.
-
-   Lastly, comments from groups working on similar ideas in DCE have
-   been invaluable.
-
-
-6.  IANA Considerations
-
-   This document has no actions for IANA.
-
-
-7.  References
-
-7.1.  Normative References
-
-   [IEEE1363]
-              IEEE, "Standard Specifications for Public Key 
-              Cryptography", IEEE 1363, 2000.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
-              RFC 2412, November 1998.
-
-   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 29]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-              RFC 2631, June 1999.
-
-   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
-              Algorithms", RFC 3370, August 2002.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
-              Encryption Algorithm in Cryptographic Message Syntax
-              (CMS)", RFC 3565, July 2003.
-
-   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
-              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
-              RFC 3766, April 2004.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
-              Encryption for Kerberos 5", RFC 3962, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 30]
-
-Internet-Draft                   PKINIT                     January 2006
-
-   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 
-              Information technology - Abstract Syntax Notation One 
-              (ASN.1): Specification of basic notation.
-
-   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 
-              Information technology - ASN.1 encoding Rules: Specification 
-              of Basic Encoding Rules (BER), Canonical Encoding Rules 
-              (CER) and Distinguished Encoding Rules (DER).
-
-7.2.  Informative References
-
-   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
-              Sizes", Journal of Cryptology 14 (2001) 255-293.
-   
-   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
-              future, Designs, Codes, and Cryptography (1999)".
-
-   [RFC4158]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
-              Nicholas, "Internet X.509 Public Key Infrastructure:
-              Certification Path Building", RFC 4158, September 2005.
-
-
-Appendix A.  PKINIT ASN.1 Module
-
-       KerberosV5-PK-INIT-SPEC {
-               iso(1) identified-organization(3) dod(6) internet(1)
-               security(5) kerberosV5(2) modules(4) pkinit(5)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       IMPORTS
-           SubjectPublicKeyInfo, AlgorithmIdentifier
-               FROM PKIX1Explicit88 { iso (1)
-                 identified-organization (3) dod (6) internet (1)
-                 security (5) mechanisms (5) pkix (7) id-mod (0)
-                 id-pkix1-explicit (18) }
-                 -- As defined in RFC 3280.
-
-           KerberosTime, PrincipalName, Realm, EncryptionKey
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) } ;
-
-       id-pkinit OBJECT IDENTIFIER ::=
-         { iso (1) org (3) dod (6) internet (1) security (5)
-           kerberosv5 (2) pkinit (3) }
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 31]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-       id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-       id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-       id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-       id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-       id-pkinit-KPKdc         OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-       id-pkinit-san OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509SanAN (2) }
-
-       pa-pk-as-req INTEGER ::=                  16
-       pa-pk-as-rep INTEGER ::=                  17
-
-       ad-initial-verified-cas INTEGER ::=        9
-
-       td-trusted-certifiers INTEGER ::=        104
-       td-invalid-certificates INTEGER ::=      105
-       td-dh-parameters INTEGER ::=             109
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- Contains a list of CAs, trusted by the client,
-                   -- that can be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 32]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS encryption types supported by the
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 33]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-                   -- client in order of (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so.
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING OPTIONAL,
-                   -- MUST be present.
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       PA-PK-AS-REP ::= CHOICE {
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 34]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is
-                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-                   -- eContent field contains the DER encoding of the
-                   -- type ReplyKeyPack.
-                   -- ReplyKeyPack is defined below.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL,
-                   -- Present if and only if dhKeyExpiration is
-                   -- present.
-          ...
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- The KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the pkAuthenticator field
-                   -- in the request if the DH keys are NOT reused,
-                   -- 0 otherwise.
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 35]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if the DH keys are reused.
-                   -- If present, the KDC's DH public key MUST not be
-                   -- used past the point of this expiration time.
-                   -- If this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP, i.e. the
-                   -- AS reply key.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-       END
-
-
-Appendix B.  Test Vectors
-
-   Function octetstring2key() is defined in Section 3.2.3.1.  This
-   section describes a few sets of test vectors that would be useful for
-   implementers of octetstring2key().
-
-
-   Set 1
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 36]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
-     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
-
-
-   Set 2:
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
-     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
-
-
-   Set 3:
-   ======
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 37]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
-     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
-     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
-     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
-     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
-
-
-   Set 4:
-   =====
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
-     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
-
-
-Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
-             Implementations
-
-   Earlier revisions of the PKINIT I-D were implemented in various
-   releases of Microsoft Windows and deployed in fairly large numbers.
-   To enable the community to better interoperate with systems running
-   those releases, the following information may be useful.
-
-   KDC certificates issued by Windows 2000 Enterprise CAs contain a
-   dNSName SAN with the DNS name of the host running the KDC, and the
-   id-kp-serverAuth EKU [RFC3280].
-
-   KDC certificates issued by Windows 2003 Enterprise CAs contain a
-   dNSName SAN with the DNS name of the host running the KDC, the id-kp-
-   serverAuth EKU and the id-ms-kp-sc-logon EKU.
-
-   It is anticipated that the next release of Windows is already too far
-   along to allow it to support the issuing KDC certificates with id-
-   pkinit-san SAN as specified in this RFC.  Instead, they will have a
-   dNSName SAN containing the domain name of the KDC and the intended
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 38]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   purpose of these KDC certificates be restricted by the presence of
-   the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
-
-   In addition to checking that the above are present in a KDC
-   certificate, Windows clients verify that the issuer of the KDC
-   certificate is one of a set of allowed issuers of such certificates,
-   so those wishing to issue KDC certificates need to configure their
-   Windows clients appropriately.
-
-   Client certificates accepted by Windows 2000 and Windows 2003 Server
-   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
-   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
-   contains a UTF8 encoded string whose value is that of the Directory
-   Service attribute UserPrincipalName of the client account object, and
-   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
-   certificate is to validate the client mapping (in other words, the
-   client's public key is bound to the account that has this
-   UserPrincipalName value).
-
-   It should be noted that all Microsoft Kerberos realm names are domain
-   style realm names and strictly in upper case.  In addition, the
-   UserPrincipalName attribute is globally unique in Windows 2000 and
-   Windows 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 39]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Brian Tung
-   USC Information Sciences Institute
-   4676 Admiralty Way Suite 1001
-   Marina del Rey, CA  90292
-   US
-
-   Email: brian@isi.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 40]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu & Tung                Expires July 15, 2006                [Page 41]
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-33.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-33.txt
deleted file mode 100644
index 6f84c1a71..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-33.txt
+++ /dev/null
@@ -1,2335 +0,0 @@
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                     Microsoft Corporation
-Expires: July 28, 2006                                           B. Tung
-                                      USC Information Sciences Institute
-                                                        January 24, 2006
-
-
-     Public Key Cryptography for Initial Authentication in Kerberos
-                   draft-ietf-cat-kerberos-pk-init-33
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 28, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes protocol extensions (hereafter called PKINIT)
-   to the Kerberos protocol specification.  These extensions provide a
-   method for integrating public key cryptography into the initial
-   authentication exchange, by using asymmetric-key signature and/or
-   encryption algorithms in pre-authentication data fields.
-
-
-
-
-
-Zhu & Tung                Expires July 28, 2006                 [Page 1]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
-   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  5
-     3.1.  Definitions, Requirements, and Constants . . . . . . . . .  6
-       3.1.1.  Required Algorithms  . . . . . . . . . . . . . . . . .  6
-       3.1.2.  Defined Message and Encryption Types . . . . . . . . .  7
-       3.1.3.  Kerberos Encryption Types Defined for CMS
-               Algorithm Identifiers  . . . . . . . . . . . . . . . .  8
-     3.2.  PKINIT Pre-authentication Syntax and Use . . . . . . . . .  9
-       3.2.1.  Generation of Client Request . . . . . . . . . . . . .  9
-       3.2.2.  Receipt of Client Request  . . . . . . . . . . . . . . 14
-       3.2.3.  Generation of KDC Reply  . . . . . . . . . . . . . . . 18
-       3.2.4.  Receipt of KDC Reply . . . . . . . . . . . . . . . . . 25
-     3.3.  Interoperability Requirements  . . . . . . . . . . . . . . 26
-     3.4.  KDC Indication of PKINIT Support . . . . . . . . . . . . . 26
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
-   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 30
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 32
-   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 32
-   Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 37
-   Appendix C.  Miscellaneous Information about Microsoft Windows
-                PKINIT Implementations  . . . . . . . . . . . . . . . 39
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
-   Intellectual Property and Copyright Statements . . . . . . . . . . 42
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                Expires July 28, 2006                 [Page 2]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-1.  Introduction
-
-   The Kerberos V5 protocol [RFC4120] involves use of a trusted third
-   party known as the Key Distribution Center (KDC) to negotiate shared
-   session keys between clients and services and provide mutual
-   authentication between them.
-
-   The corner-stone of Kerberos V5 is the Ticket and the Authenticator.
-   A Ticket encapsulates a symmetric key (the ticket session key) in an
-   envelope (a public message) intended for a specific service.  The
-   contents of the Ticket are encrypted with a symmetric key shared
-   between the service principal and the issuing KDC.  The encrypted
-   part of the Ticket contains the client principal name, amongst other
-   items.  An Authenticator is a record that can be shown to have been
-   recently generated using the ticket session key in the associated
-   Ticket.  The ticket session key is known by the client who requested
-   the ticket.  The contents of the Authenticator are encrypted with the
-   associated ticket session key.  The encrypted part of an
-   Authenticator contains a timestamp and the client principal name,
-   amongst other items.
-
-   As shown in Figure 1 below, the Kerberos V5 protocol consists of the
-   following message exchanges between the client and the KDC, and the
-   client and the application service:
-
-    - The Authentication Service (AS) Exchange
-
-      The client obtains an "initial" ticket from the Kerberos
-      authentication server (AS), typically a Ticket Granting Ticket
-      (TGT).  The AS-REQ message and the AS-REP message are the request
-      and the reply message respectively between the client and the AS.
-
-    - The Ticket Granting Service (TGS) Exchange
-
-      The client subsequently uses the TGT to authenticate and request a
-      service ticket for a particular service, from the Kerberos ticket-
-      granting server (TGS).  The TGS-REQ message and the TGS-REP
-      message are the request and the reply message respectively between
-      the client and the TGS.
-
-    - The Client/Server Authentication Protocol (AP) Exchange
-
-      The client then makes a request with an AP-REQ message, consisting
-      of a service ticket and an authenticator that certifies the
-      client's possession of the ticket session key.  The server may
-      optionally reply with an AP-REP message.  AP exchanges typically
-      negotiate session specific symmetric keys.
-
-
-
-
-Zhu & Tung                Expires July 28, 2006                 [Page 3]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   Usually, the AS and TGS are integrated in a single device also known
-   as the KDC.
-
-      Figure 1:  The Message Exchanges in the Kerberos V5 Protocol
-
-                          +--------------+
-               +--------->|  KDC         |
-       AS-REQ /   +-------|              |
-             /   /        +--------------+
-            /   /          ^           |
-           /    |AS-REP   /            |
-          |     |        / TGS-REQ     + TGS-REP
-          |     |       /             /
-          |     |      /             /
-          |     |     /   +---------+
-          |     |    /   /
-          |     |   /   /
-          |     |  /   /
-          |     v /   v
-         ++-------+------+             +-----------------+
-         |  Client       +------------>|  Application    |
-         |               |    AP-REQ   |  Server         |
-         |               |<------------|                 |
-         +---------------+    AP-REP   +-----------------+
-
-   In the AS exchange, the KDC reply contains the ticket session key,
-   amongst other items, that is encrypted using a key (the AS reply key)
-   shared between the client and the KDC.  The AS reply key is typically
-   derived from the client's password for human users.  Therefore for
-   human users the attack resistance strength of the Kerberos protocol
-   is no stronger than the strength of their passwords.
-
-   The use of asymmetric cryptography in the form of X.509 certificates
-   [RFC3280] is popular for facilitating data origin authentication and
-   perfect secrecy.  An established Public Key Infrastructure (PKI)
-   provides key management and key distribution mechanisms that can be
-   used to establish authentication and secure communication.  Adding
-   public-key cryptography to Kerberos provides a nice congruence to
-   public-key protocols, obviates the human users' burden to manage
-   strong passwords, and allows Kerberized applications to take
-   advantage of existing key services and identity management.
-
-   The advantage afforded by the Kerberos TGT is that the client exposes
-   his long-term secrets only once.  The TGT and its associated session
-   key can then be used for any subsequent service ticket requests.  One
-   result of this is that all further authentication is independent of
-   the method by which the initial authentication was performed.
-   Consequently, initial authentication provides a convenient place to
-
-
-
-Zhu & Tung                Expires July 28, 2006                 [Page 4]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   integrate public-key cryptography into Kerberos authentication.  In
-   addition, the use of symmetric cryptography after the initial
-   exchange is preferred for performance.
-
-   This document describes the methods and data formats using which the
-   client and the KDC can use public and private key pairs to mutually
-   authenticate in the AS exchange and negotiate the AS reply key, known
-   only by the client and the KDC, to encrypt the AS-REP sent by the
-   KDC.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   In this protocol, both the client and the KDC have a public-private
-   key pair in order to prove their identities to each other over the
-   open network.  The term "signature key" is used to refer to the
-   private key of the key pair being used.
-
-   The encryption key used to encrypt the enc-part field of the KDC-REP
-   in the AS-REP [RFC4120] is referred to as the AS reply key.
-
-   An empty sequence in an optional field can be either included or
-   omitted: both encodings are permitted and considered equivalent.
-
-   The term "Modular Exponential Diffie-Hellman" is used to refer to the
-   Diffie-Hellman key exchange as described in [RFC2631], in order to
-   differentiate it from other equivalent representations of the same
-   key agreement algorithm.
-
-
-3.  Extensions
-
-   This section describes extensions to [RFC4120] for supporting the use
-   of public-key cryptography in the initial request for a ticket.
-
-   Briefly, this document defines the following extensions to [RFC4120]:
-
-   1. The client indicates the use of public-key authentication by
-      including a special preauthenticator in the initial request.  This
-      preauthenticator contains the client's public-key data and a
-      signature.
-
-
-
-
-
-
-Zhu & Tung                Expires July 28, 2006                 [Page 5]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   2. The KDC tests the client's request against its authentication
-      policy and trusted Certification Authorities (CAs).
-
-   3. If the request passes the verification tests, the KDC replies as
-      usual, but the reply is encrypted using either:
-
-      a. a key generated through a Diffie-Hellman (DH) key exchange
-         [RFC2631] [IEEE1363] with the client, signed using the KDC's
-         signature key; or
-
-      b. a symmetric encryption key, signed using the KDC's signature
-         key and encrypted using the client's public key.
-
-      Any keying material required by the client to obtain the
-      encryption key for decrypting the KDC reply is returned in a pre-
-      authentication field accompanying the usual reply.
-
-   4. The client validates the KDC's signature, obtains the encryption
-      key, decrypts the reply, and then proceeds as usual.
-
-   Section 3.1 of this document enumerates the required algorithms and
-   necessary extension message types.  Section 3.2 describes the
-   extension messages in greater detail.
-
-3.1.  Definitions, Requirements, and Constants
-
-3.1.1.  Required Algorithms
-
-   All PKINIT implementations MUST support the following algorithms:
-
-   o  AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
-      sha1-96 [RFC3962].
-
-   o  Signature algorithm: sha-1WithRSAEncryption [RFC3279].
-
-   o  AS reply key delivery method: Diffie-Hellman key exchange
-      [RFC2631].
-
-   o  Algorithms identified in the contentEncryptionAlgorithm field of
-      the type EncryptedContentInfo [RFC3852] for encrypting the
-      temporary key in the encryptedKey field of the type
-      KeyTransRecipientInfo [RFC3852] with a public key, as described in
-      Section 3.2.3.2: rsaEncryption [RFC3447] [RFC3279].
-
-   o  Algorithms identified in the contentEncryptionAlgorithm field of
-      the type EncryptedContentInfo [RFC3852] for encrypting the AS
-      reply key with the temporary key contained in the encryptedKey
-      field of the type KeyTransRecipientInfo [RFC3852], as described in
-
-
-
-Zhu & Tung                Expires July 28, 2006                 [Page 6]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-      Section 3.2.3.2: des-ede3-cbc (three-key 3DES, CBC mode)
-      [RFC3370].
-
-   In addition, implementations of this specification MUST be capable of
-   processing the Extended Key Usage (EKU) extension and the id-pkinit-
-   san (as defined in Section 3.2.2) otherName of the Subject
-   Alternative Name (SAN) extension in X.509 certificates [RFC3280].
-
-3.1.2.  Defined Message and Encryption Types
-
-   PKINIT makes use of the following new pre-authentication types:
-
-       PA_PK_AS_REQ                                 16
-       PA_PK_AS_REP                                 17
-
-   PKINIT also makes use of the following new authorization data type:
-
-       AD_INITIAL_VERIFIED_CAS                       9
-
-   PKINIT introduces the following new error codes:
-
-       KDC_ERR_CLIENT_NOT_TRUSTED                   62
-       KDC_ERR_INVALID_SIG                          64
-       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
-       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
-       KDC_ERR_INVALID_CERTIFICATE                  71
-       KDC_ERR_REVOKED_CERTIFICATE                  72
-       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
-       KDC_ERR_CLIENT_NAME_MISMATCH                 75
-       KDC_ERR_INCONSISTENT_KEY_PURPOSE             77
-       KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED          78
-       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED         79
-       KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED   80
-
-   PKINIT uses the following typed data types for errors:
-
-       TD_TRUSTED_CERTIFIERS                       104
-       TD_INVALID_CERTIFICATES                     105
-       TD_DH_PARAMETERS                            109
-
-   The ASN.1 module for all structures defined in this document (plus
-   IMPORT statements for all imported structures) is given in
-   Appendix A.
-
-   All structures defined in or imported into this document MUST be
-   encoded using Distinguished Encoding Rules (DER) [X680] [X690]
-   (unless otherwise noted).  All data structures carried in OCTET
-   STRINGs must be encoded according to the rules specified in
-
-
-
-Zhu & Tung                Expires July 28, 2006                 [Page 7]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   corresponding specifications.
-
-   Interoperability note: Some implementations may not be able to decode
-   wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects encoded
-   with BER; specifically, they may not be able to decode indefinite
-   length encodings.  To maximize interoperability, implementers SHOULD
-   encode CMS objects used in PKINIT with DER.
-
-3.1.3.  Kerberos Encryption Types Defined for CMS Algorithm Identifiers
-
-   PKINIT defines the following Kerberos encryption type numbers
-   [RFC3961], which can be used in the etype field of the AS-REQ
-   [RFC4120] message to indicate to the KDC the client's acceptance of
-   the corresponding algorithms (including public encryption algorithms,
-   bulk encryption algorithms, and signature algorithms) for use with
-   Cryptographic Message Syntax (CMS) [RFC3852].
-
-   Per [RFC4120], the encryption types in the etype field are in the
-   decreasing preference order of the client.  Note that there is no
-   significance in the relative order between any two of different types
-   of algorithms: public key encryption algorithms, bulk encryption
-   algorithms and signature algorithms.
-
-   The presence of each of these encryption types in the etype field is
-   equivalent to the presence of the corresponding algorithm Object
-   Identifier (OID) in the supportedCMSTypes field as described in
-   Section 3.2.1.  And the preference order expressed in the
-   supportedCMSTypes field would override the preference order listed in
-   the etype field.
-
-
-    Kerberos Encryption Type Name  Num  Corresponding Algorithm OID
-    ============================== === ===============================
-    id-dsa-with-sha1-CmsOID        9   id-dsa-with-sha1 [RFC3279]
-    md5WithRSAEncryption-CmsOID    10  md5WithRSAEncryption [RFC3279]
-    sha-1WithRSAEncryption-CmsOID  11  sha-1WithRSAEncryption [RFC3279]
-    rc2-cbc-EnvOID                 12  rc2-cbc [RFC3370]
-    rsaEncryption-EnvOID           13  rsaEncryption [RFC3447][RFC3279]
-    id-RSAES-OAEP-EnvOID           14  id-RSAES-OAEP [RFC3447][RFC3279]
-    des-ede3-cbc-EnvOID            15  des-ede3-cbc [RFC3370]
-
-   The above encryption type numbers are used only to indicate support
-   for the use of the corresponding algorithms in PKINIT; they do not
-   correspond to actual Kerberos encryption types [RFC3961] and MUST NOT
-   be used in the etype field of the Kerberos EncryptedData type
-   [RFC4120].  The practice of assigning Kerberos encryption type
-   numbers to indicate support for CMS algorithms is considered
-   deprecated, and new numbers should not be assigned for this purpose.
-
-
-
-Zhu & Tung                Expires July 28, 2006                 [Page 8]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   Instead, the supportedCMSTypes field should be used to identify the
-   algorithms supported by the client and the preference order of the
-   client.
-
-   For maximum interoperability, however, PKINIT clients wishing to
-   indicate to the KDC the support for one or more of the algorithms
-   listed above SHOULD include the corresponding encryption type numbers
-   in the etype field of the AS-REQ.
-
-3.2.  PKINIT Pre-authentication Syntax and Use
-
-   This section defines the syntax and use of the various pre-
-   authentication fields employed by PKINIT.
-
-3.2.1.  Generation of Client Request
-
-   The initial authentication request (AS-REQ) is sent as per [RFC4120];
-   in addition, a pre-authentication data element, whose padata-type is
-   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
-   type PA-PK-AS-REQ, is included.
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- Contains a list of CAs, trusted by the client,
-                   -- that can be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-
-
-
-Zhu & Tung                Expires July 28, 2006                 [Page 9]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 10]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-                   -- [RFC3280].
-                   -- List of CMS public key encryption algorithm
-                   -- identifiers, bulk encryption algorithm
-                   -- identifiers, or signature algorithm identifiers
-                   -- supported by the client in order of (decreasing)
-                   -- preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so (see Section 3.2.3.1).
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING OPTIONAL,
-                   -- MUST be present.
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure contained in the signedAuthPack
-   field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
-   is filled out as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is id-pkinit-
-       authData: { iso(1) org(3) dod(6) internet(1) security(5)
-       kerberosv5(2) pkinit(3) authData(1) }.  Notes to CMS
-       implementers: the signed attribute content-type MUST be present
-       in this SignedData instance and its value is id-pkinit-authData
-       according to [RFC3852].
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type AuthPack.
-
-
-
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 11]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type AuthPack.
-
-   5.  The AuthPack structure contains a PKAuthenticator, the client
-       public key information, the CMS encryption types supported by the
-       client and a DHNonce.  The pkAuthenticator field certifies to the
-       KDC that the client has recent knowledge of the signing key that
-       authenticates the client.  The clientPublicValue field specifies
-       Diffie-Hellman domain parameters and the client's public key
-       value.  The DH public key value is encoded as a BIT STRING
-       according to [RFC3279].  The clientPublicValue field is present
-       only if the client wishes to use the Diffie-Hellman key agreement
-       method.  The supportedCMSTypes field specifies the list of CMS
-       algorithm identifiers that are supported by the client in order
-       of (decreasing) preference, and can be used to identify a
-       signature algorithm or a public key encryption algorithm in the
-       keyEncryptionAlgorithm field of the type KeyTransRecipientInfo or
-       a bulk encryption algorithm in the contentEncryptionAlgorithm
-       field of the type EncryptedContentInfo [RFC3852] when encrypting
-       the AS reply key as described in Section 3.2.3.2.  However, there
-       is no significance in the relative order between any two of
-       different types of algorithms: public key encryption algorithms,
-       bulk encryption algorithms and signature algorithms.  The
-       clientDHNonce field is described later in this section.
-
-   6.  The ctime field in the PKAuthenticator structure contains the
-       current time on the client's host, and the cusec field contains
-       the microsecond part of the client's timestamp.  The ctime and
-       cusec fields are used together to specify a reasonably accurate
-       timestamp [RFC4120].  The nonce field is chosen randomly.  The
-       paChecksum field MUST be present and it contains a SHA1 checksum
-       that is performed over the KDC-REQ-BODY [RFC4120].  In order to
-       ease future migration from the use of SHA1, the paChecksum field
-       is made optional syntactically: when the request is extended to
-       negotiate hash algorithms, the new client wishing not to use SHA1
-       will send the request in the extended message syntax without the
-       paChecksum field.  The KDC conforming to this specification MUST
-       return a KRB-ERROR [RFC4120] message with the code
-       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3).  That
-       will allow a new client to retry with SHA1 if allowed by the
-       local policy.
-
-   7.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the KDC can verify the signature over the
-       type AuthPack.  For path validation, these certificates SHOULD be
-       sufficient to construct at least one certification path from the
-       client certificate to one trust anchor acceptable by the KDC
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 12]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-       [RFC4158].  The client MUST be capable of including such a set of
-       certificates if configured to do so.  The certificates field MUST
-       NOT contain "root" CA certificates.
-
-   8.  The client's Diffie-Hellman public value (clientPublicValue) is
-       included if and only if the client wishes to use the Diffie-
-       Hellman key agreement method.  The Diffie-Hellman domain
-       parameters [IEEE1363] for the client's public key are specified
-       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
-       and the client's Diffie-Hellman public key value is mapped to a
-       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
-       using the Diffie-Hellman key agreement method, implementations
-       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
-       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
-       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
-       group 16 [RFC3526].
-
-       The Diffie-Hellman field size should be chosen so as to provide
-       sufficient cryptographic security [RFC3766].
-
-       When MODP Diffie-Hellman is used, the exponents should have at
-       least twice as many bits as the symmetric keys that will be
-       derived from them [ODL99].
-
-   9.  The client may wish to reuse DH keys or to allow the KDC to do so
-       (see Section 3.2.3.1).  If so, then the client includes the
-       clientDHNonce field.  This nonce string MUST be as long as the
-       longest key length of the symmetric key types that the client
-       supports.  This nonce MUST be chosen randomly.
-
-   The ExternalPrincipalIdentifier structure is used in this document to
-   identify the subject's public key thereby the subject principal.
-   This structure is filled out as follows:
-
-   1.  The subjectName field contains a PKIX type Name encoded according
-       to [RFC3280].  This field identifies the certificate subject by
-       the distinguished subject name.  This field is REQUIRED when
-       there is a distinguished subject name present in the certificate
-       being used.
-
-   2.  The issuerAndSerialNumber field contains a CMS type
-       IssuerAndSerialNumber encoded according to [RFC3852].  This field
-       identifies a certificate of the subject.  This field is REQUIRED
-       for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
-       structures are defined in Section 3.2.2).
-
-
-
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 13]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   3.  The subjectKeyIdentifier [RFC3852] field identifies the subject's
-       public key by a key identifier.  When an X.509 certificate is
-       referenced, this key identifier matches the X.509
-       subjectKeyIdentifier extension value.  When other certificate
-       formats are referenced, the documents that specify the
-       certificate format and their use with the CMS must include
-       details on matching the key identifier to the appropriate
-       certificate field.  This field is RECOMMENDED for TD-TRUSTED-
-       CERTIFIERS (as defined in Section 3.2.2).
-
-   The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
-   of CAs, trusted by the client, that can be used to certify the KDC.
-   Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
-   (thereby its public key).
-
-   The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
-   SignerIdentifier encoded according to [RFC3852].  This field
-   identifies, if present, a particular KDC public key that the client
-   already has.
-
-3.2.2.  Receipt of Client Request
-
-   Upon receiving the client's request, the KDC validates it.  This
-   section describes the steps that the KDC MUST (unless otherwise
-   noted) take in validating the request.
-
-   The KDC verifies the client's signature in the signedAuthPack field
-   according to [RFC3852].
-
-   If, while validating the client's X.509 certificate [RFC3280], the
-   KDC cannot build a certification path to validate the client's
-   certificate, it sends back a KRB-ERROR [RFC4120] message with the
-   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
-   this error message is a TYPED-DATA (as defined in [RFC4120]) that
-   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
-   whose data-value contains the DER encoding of the type TD-TRUSTED-
-   CERTIFIERS:
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
-   TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
-   (thereby its public key) trusted by the KDC.
-
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 14]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   Upon receiving this error message, the client SHOULD retry only if it
-   has a different set of certificates (from those of the previous
-   requests) that form a certification path (or a partial path) from one
-   of the trust anchors acceptable by the KDC to its own certificate.
-
-   If, while processing the certification path, the KDC determines that
-   the signature on one of the certificates in the signedAuthPack field
-   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
-   message is a TYPED-DATA that contains an element whose data-type is
-   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
-   encoding of the type TD-INVALID-CERTIFICATES:
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
-   TD-INVALID-CERTIFICATES structure identifies a certificate (that was
-   sent by the client) with an invalid signature.
-
-   If more than one X.509 certificate signature is invalid, the KDC MAY
-   include one IssuerAndSerialNumber per invalid signature within the
-   TD-INVALID-CERTIFICATES.
-
-   The client's X.509 certificate is validated according to [RFC3280].
-
-   Based on local policy, the KDC may also check whether any X.509
-   certificates in the certification path validating the client's
-   certificate have been revoked.  If any of them have been revoked, the
-   KDC MUST return an error message with the code
-   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
-   revocation status but is unable to do so, it SHOULD return an error
-   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
-   certificate or certificates affected are identified exactly as for
-   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
-
-   Note that the TD_INVALID_CERTIFICATES error data is only used to
-   identify invalid certificates sent by the client in the request.
-
-   The client's public key is then used to verify the signature.  If the
-   signature fails to verify, the KDC MUST return an error message with
-   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
-   this error message.
-
-   In addition to validating the client's signature, the KDC MUST also
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 15]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   check that the client's public key used to verify the client's
-   signature is bound to the client's principal name as specified in the
-   AS-REQ as follows:
-
-   1. If the KDC has its own binding between either the client's
-      signature-verification public key or the client's certificate and
-      the client's Kerberos principal name, it uses that binding.
-
-   2. Otherwise, if the client's X.509 certificate contains a Subject
-      Alternative Name (SAN) extension carrying a KRB5PrincipalName
-      (defined below) in the otherName field of the type GeneralName
-      [RFC3280], it binds the client's X.509 certificate to that name.
-
-      The type of the otherName field is AnotherName.  The type-id field
-      of the type AnotherName is id-pkinit-san:
-
-       id-pkinit-san OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509SanAN (2) }
-
-      And the value field of the type AnotherName is a
-      KRB5PrincipalName.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-   If the Kerberos client name in the AS-REQ does not match a name bound
-   by the KDC (the binding can be in the certificate, for example as
-   described above), or if there is no binding found by the KDC, the KDC
-   MUST return an error message with the code
-   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
-   this error message.
-
-   Even if the certification path is validated and the certificate is
-   mapped to the client's principal name, the KDC may decide not to
-   accept the client's certificate, depending on local policy.
-
-   The KDC MAY require the presence of an Extended Key Usage (EKU)
-   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
-   of the client's X.509 certificate:
-
-       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) keyPurposeClientAuth(4) }
-              -- PKINIT client authentication.
-              -- Key usage bits that MUST be consistent:
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 16]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-              -- digitalSignature.
-
-   The digitalSignature key usage bit [RFC3280] MUST be asserted when
-   the intended purpose of the client's X.509 certificate is restricted
-   with the id-pkinit-KPClientAuth EKU.
-
-   If this EKU KeyPurposeId is required but it is not present or if the
-   client certificate is restricted not to be used for PKINIT client
-   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
-   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
-   is no accompanying e-data for this error message.  KDCs implementing
-   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
-   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
-   are a large number of X.509 client certificates deployed for use with
-   PKINIT which have this EKU.
-
-   As a matter of local policy, the KDC MAY decide to reject requests on
-   the basis of the absence or presence of other specific EKU OID's.
-
-   If the digest algorithm used in generating the CA signature for the
-   public key in any certificate of the request is not acceptable by the
-   KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED.  The accompanying e-data MUST be
-   encoded in TYPED-DATA although none is defined at this point.
-
-   If the client's public key is not accepted with reasons other than
-   what were specified above, the KDC returns a KRB-ERROR [RFC4120]
-   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.  There is no
-   accompanying e-data currently defined for this error message.
-
-   The KDC MUST check the timestamp to ensure that the request is not a
-   replay, and that the time skew falls within acceptable limits.  The
-   recommendations for clock skew times in [RFC4120] apply here.  If the
-   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
-   KRB_AP_ERR_SKEW, respectively.
-
-   If the clientPublicValue is filled in, indicating that the client
-   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
-   check to see if the key parameters satisfy its policy.  If they do
-   not, it MUST return an error message with the code
-   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
-   TYPED-DATA that contains an element whose data-type is
-   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
-   the type TD-DH-PARAMETERS:
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 17]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-                   -- This list is in decreasing preference order.
-
-   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
-   that the KDC supports in decreasing preference order, from which the
-   client SHOULD pick one to retry the request.
-
-   The AlgorithmIdentifier structure is defined in [RFC3280] and is
-   filled in according to [RFC3279].  More specifically Section 2.3.3 of
-   [RFC3279] describes how to fill in the AlgorithmIdentifier structure
-   in the case where MODP Diffie-Hellman key exchange is used.
-
-   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
-   KDC does not possess the corresponding key, the KDC MUST ignore the
-   kdcPkId field as if the client did not include one.
-
-   If the digest algorithm used by the id-pkinit-authData is not
-   acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
-   message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
-   The accompanying e-data MUST be encoded in TYPED-DATA although none
-   is defined at this point.
-
-3.2.3.  Generation of KDC Reply
-
-   If the paChecksum filed in the request is not present, the KDC
-   conforming to this specification MUST return a KRB-ERROR [RFC4120]
-   message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED.  The
-   accompanying e-data MUST be encoded in TYPED-DATA (no error data is
-   defined by this specification).
-
-   Assuming that the client's request has been properly validated, the
-   KDC proceeds as per [RFC4120], except as follows.
-
-   The KDC MUST set the initial flag and include an authorization data
-   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
-   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
-   type AD-INITIAL-VERIFIED-CAS:
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   The AD-INITIAL-VERIFIED-CAS structure identifies the certification
-   path based on which the client certificate was validated.  Each
-   ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
-   INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 18]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   (thereby its public key).
-
-   Note that the syntax for the AD-INITIAL-VERIFIED-CAS authorization
-   data does permit empty SEQUENCEs to be encoded.  Such empty sequences
-   may only be used if the KDC itself vouches for the user's
-   certificate.
-
-   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-   containers if the list of CAs satisfies the AS' realm's local policy
-   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
-   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
-   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
-   resulting ticket.  If the list of CAs satisfies the local KDC's
-   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
-   container, otherwise it MAY unwrap the authorization data out of the
-   AD-IF-RELEVANT container.
-
-   Application servers that understand this authorization data type
-   SHOULD apply local policy to determine whether a given ticket bearing
-   such a type *not* contained within an AD-IF-RELEVANT container is
-   acceptable.  (This corresponds to the AP server checking the
-   transited field when the TRANSITED-POLICY-CHECKED flag has not been
-   set [RFC4120].)  If such a data type is contained within an AD-IF-
-   RELEVANT container, AP servers MAY apply local policy to determine
-   whether the authorization data is acceptable.
-
-   A pre-authentication data element, whose padata-type is PA_PK_AS_REP
-   and whose padata-value contains the DER encoding of the type PA-PK-
-   AS-REP (defined below), is included in the AS-REP [RFC4120].
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is
-                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-                   -- eContent field contains the DER encoding of the
-                   -- type ReplyKeyPack.
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 19]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-                   -- ReplyKeyPack is defined in Section 3.2.3.2.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL,
-                   -- Present if and only if dhKeyExpiration is
-                   -- present in the KDCDHKeyInfo.
-          ...
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- The KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the pkAuthenticator field
-                   -- in the request if the DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if the DH keys are reused.
-                   -- If present, the KDC's DH public key MUST not be
-                   -- used past the point of this expiration time.
-                   -- If this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
-   KDC encrypts the reply as usual, but not with the client's long-term
-   key.  Instead, it encrypts it with either a shared key derived from a
-   Diffie-Hellman exchange, or a generated encryption key.  The contents
-   of the PA-PK-AS-REP indicate which key delivery method is used.
-
-   In addition, the lifetime of the ticket returned by the KDC MUST NOT
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 20]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   exceed that of the client's public-private key pair.  The ticket
-   lifetime, however, can be shorter than that of the client's public-
-   private key pair.  For the implementations of this specification, the
-   lifetime of the client's public-private key pair is the validity
-   period in X.509 certificates [RFC3280], unless configured otherwise.
-
-3.2.3.1.  Using Diffie-Hellman Key Exchange
-
-   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
-
-   The ContentInfo [RFC3852] structure for the dhSignedData field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is the OID value
-       for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
-       security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.  Notes to CMS
-       implementers: the signed attribute content-type MUST be present
-       in this SignedData instance and its value is id-pkinit-DHKeyData
-       according to [RFC3852].
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type KDCDHKeyInfo.
-
-   4.  The KDCDHKeyInfo structure contains the KDC's public key, a nonce
-       and optionally the expiration time of the KDC's DH key being
-       reused.  The subjectPublicKey field of the type KDCDHKeyInfo
-       field identifies KDC's DH public key.  This DH public key value
-       is encoded as a BIT STRING according to [RFC3279].  The nonce
-       field contains the nonce in the pkAuthenticator field in the
-       request if the DH keys are NOT reused.  The value of this nonce
-       field is 0 if the DH keys are reused.  The dhKeyExpiration field
-       is present if and only if the DH keys are reused.  If the
-       dhKeyExpiration field is present, the KDC's public key in this
-       KDCDHKeyInfo structure MUST NOT be used past the point of this
-       expiration time.  If this field is omitted then the serverDHNonce
-       field MUST also be omitted.
-
-   5.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type
-       KDCDHKeyInfo.
-
-   6.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 21]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-       over the type KDCDHKeyInfo.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may be left empty if the KDC
-       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
-       used for signing.  Otherwise, for path validation, these
-       certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [RFC4158].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  If the client included the clientDHNonce field, then the KDC may
-       choose to reuse its DH keys.  If the server reuses DH keys then
-       it MUST include an expiration time in the dhKeyExpiration field.
-       Past the point of the expiration time, the signature over the
-       type DHRepInfo is considered expired/invalid.  When the server
-       reuses DH keys then it MUST include a serverDHNonce at least as
-       long as the length of keys for the symmetric encryption system
-       used to encrypt the AS reply.  Note that including the
-       serverDHNonce changes how the client and server calculate the key
-       to use to encrypt the reply; see below for details.  The KDC
-       SHOULD NOT reuse DH keys unless the clientDHNonce field is
-       present in the request.
-
-   The AS reply key is derived as follows:
-
-   1. Both the KDC and the client calculate the shared secret value as
-      follows:
-
-      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
-         shared secret value.  DHSharedSecret is the value ZZ as
-         described in Section 2.1.1 of [RFC2631].
-
-      DHSharedSecret is first padded with leading zeros such that the
-      size of DHSharedSecret in octets is the same as that of the
-      modulus, then represented as a string of octets in big-endian
-      order.
-
-      Implementation note: Both the client and the KDC can cache the
-      triple (ya, yb, DHSharedSecret), where ya is the client's public
-      key and yb is the KDC's public key.  If both ya and yb are the
-      same in a later exchange, the cached DHSharedSecret can be used.
-
-
-
-
-
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 22]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   2. Let K be the key-generation seed length [RFC3961] of the AS reply
-      key whose enctype is selected according to [RFC4120].
-
-   3. Define the function octetstring2key() as follows:
-
-           octetstring2key(x) == random-to-key(K-truncate(
-                                    SHA1(0x00 | x) |
-                                    SHA1(0x01 | x) |
-                                    SHA1(0x02 | x) |
-                                    ...
-                                    ))
-
-      where x is an octet string; | is the concatenation operator; 0x00,
-      0x01, 0x02, etc., are each represented as a single octet; random-
-      to-key() is an operation that generates a protocol key from a
-      bitstring of length K; and K-truncate truncates its input to the
-      first K bits.  Both K and random-to-key() are as defined in the
-      kcrypto profile [RFC3961] for the enctype of the AS reply key.
-
-   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
-      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
-      strings.
-
-   5. The AS reply key k is:
-
-           k = octetstring2key(DHSharedSecret | n_c | n_k)
-
-3.2.3.2.  Using Public Key Encryption
-
-   In this case, the PA-PK-AS-REP contains the encKeyPack field where
-   the AS reply key is encrypted.
-
-   The ContentInfo [RFC3852] structure for the encKeyPack field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-envelopedData
-       (as defined in [RFC3852]), and the content field is an
-       EnvelopedData (as defined in [RFC3852]).
-
-   2.  The contentType field for the type EnvelopedData is id-
-       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
-       pkcs (1) pkcs7 (7) signedData (2) }.
-
-   3.  The eContentType field for the inner type SignedData (when
-       decrypted from the encryptedContent field for the type
-       EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
-       internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
-       Notes to CMS implementers: the signed attribute content-type MUST
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 23]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-       be present in this SignedData instance and its value is id-
-       pkinit-rkeyData according to [RFC3852].
-
-   4.  The eContent field for the inner type SignedData contains the DER
-       encoding of the type ReplyKeyPack (as described below).
-
-   5.  The signerInfos field of the inner type SignedData contains a
-       single signerInfo, which contains the signature for the type
-       ReplyKeyPack.
-
-   6.  The certificates field of the inner type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       for the type ReplyKeyPack.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may be left empty if the KDC
-       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
-       used for signing.  Otherwise, for path validation, these
-       certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [RFC4158].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  The recipientInfos field of the type EnvelopedData is a SET which
-       MUST contain exactly one member of type KeyTransRecipientInfo.
-       The encryptedKey of this member contains the temporary key which
-       is encrypted using the client's public key.
-
-   8.  The unprotectedAttrs or originatorInfo fields of the type
-       EnvelopedData MAY be present.
-
-   If there is a supportedCMSTypes field in the AuthPack, the KDC must
-   check to see if it supports any of the listed types.  If it supports
-   more than one of the types, the KDC SHOULD use the one listed first.
-   If it does not support any of them, it MUST return an error message
-   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
-
-   Furthermore the KDC computes the checksum of the AS-REQ in the client
-   request.  This checksum is performed over the type AS-REQ and the
-   protocol key [RFC3961] of the checksum operation is the replyKey and
-   the key usage number is 6.  If the replyKey's enctype is "newer"
-   [RFC4120] [RFC4121], the checksum operation is the required checksum
-   operation [RFC3961] of that enctype.
-
-
-
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 24]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP, i.e. the
-                   -- AS reply key.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-   Implementations of this RSA encryption key delivery method are
-   RECOMMENDED to support RSA keys at least 2048 bits in size.
-
-3.2.4.  Receipt of KDC Reply
-
-   Upon receipt of the KDC's reply, the client proceeds as follows.  If
-   the PA-PK-AS-REP contains the dhSignedData field, the client derives
-   the AS reply key using the same procedure used by the KDC as defined
-   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
-   field, and the client decrypts and extracts the temporary key in the
-   encryptedKey field of the member KeyTransRecipientInfo, and then uses
-   that as the AS reply key.
-
-   If the public key encryption method is used, the client MUST verify
-   the asChecksum contained in the ReplyKeyPack.
-
-   In either case, the client MUST verify the signature in the
-   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
-   be validated according to [RFC3280].  In addition, unless the client
-   can otherwise verify that the public key used to verify the KDC's
-   signature is bound to the KDC of the target realm, the KDC's X.509
-   certificate MUST contain a Subject Alternative Name extension
-   [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
-   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
-   matches the name of the TGS of the target realm (as defined in
-   Section 7.3 of [RFC4120]).
-
-   Unless the client knows by some other means that the KDC certificate
-   is intended for a Kerberos KDC, the client MUST require that the KDC
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 25]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
-
-       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) keyPurposeKdc(5) }
-              -- Signing KDC responses.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   The digitalSignature key usage bit [RFC3280] MUST be asserted when
-   the intended purpose of the KDC's X.509 certificate is restricted
-   with the id-pkinit-KPKdc EKU.
-
-   If the KDC certificate contains the Kerberos TGS name encoded as an
-   id-pkinit-san SAN, this certificate is certified by the issuing CA as
-   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
-
-   If all applicable checks are satisfied, the client then decrypts the
-   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
-   and then proceeds as described in [RFC4120].
-
-3.3.  Interoperability Requirements
-
-   The client MUST be capable of sending a set of certificates
-   sufficient to allow the KDC to construct a certification path for the
-   client's certificate, if the correct set of certificates is provided
-   through configuration or policy.
-
-   If the client sends all the X.509 certificates on a certification
-   path to a trust anchor acceptable by the KDC, and the KDC can not
-   verify the client's public key otherwise, the KDC MUST be able to
-   process path validation for the client's certificate based on the
-   certificates in the request.
-
-   The KDC MUST be capable of sending a set of certificates sufficient
-   to allow the client to construct a certification path for the KDC's
-   certificate, if the correct set of certificates is provided through
-   configuration or policy.
-
-   If the KDC sends all the X.509 certificates on a certification path
-   to a trust anchor acceptable by the client, and the client can not
-   verify the KDC's public key otherwise, the client MUST be able to
-   process path validation for the KDC's certificate based on the
-   certificates in the reply.
-
-3.4.  KDC Indication of PKINIT Support
-
-   If pre-authentication is required, but was not present in the
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 26]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   request, per [RFC4120] an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
-   stored in the e-data field of the KRB-ERROR message to specify which
-   pre-authentication mechanisms are acceptable.  The KDC can then
-   indicate the support of PKINIT by including an empty element whose
-   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
-
-   Otherwise if it is required by the KDC's local policy that the client
-   must be pre-authenticated using the pre-authentication mechanism
-   specified in this document, but no PKINIT pre-authentication was
-   present in the request, an error message with the code
-   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
-
-   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
-   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
-   STRING), and clients MUST ignore this and any other value.  Future
-   extensions to this protocol may specify other data to send instead of
-   an empty OCTET STRING.
-
-
-4.  Security Considerations
-
-   The security of cryptographic algorithms is dependent on generating
-   secret quantities [RFC4086].  The number of truly random bits is
-   extremely important to determining the attack resistance strength of
-   the cryptosystem, for example, the secret Diffie-Hellman exponents
-   must be chosen based on n truly random bits (where n is the system
-   security requirement).  The security of the overall system is
-   significantly weakened by using insufficient random inputs: a
-   sophisticated attacker may find it easier to reproduce the
-   environment that produced the secret quantities and to search the
-   resulting small set of possibilities than to locate the quantities in
-   the whole of the potential number space.
-
-   Kerberos error messages are not integrity protected, as a result, the
-   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
-   with by an attacker so that the set of domain parameters selected
-   could be either weaker or not mutually preferred.  Local policy can
-   configure sets of domain parameters acceptable locally, or disallow
-   the negotiation of DH domain parameters.
-
-   The symmetric reply key size and Diffie-Hellman field size or RSA
-   modulus size should be chosen so as to provide sufficient
-   cryptographic security [RFC3766].
-
-   When MODP Diffie-Hellman is used, the exponents should have at least
-   twice as many bits as the symmetric keys that will be derived from
-   them [ODL99].
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 27]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   PKINIT raises certain security considerations beyond those that can
-   be regulated strictly in protocol definitions.  We will address them
-   in this section.
-
-   PKINIT extends the cross-realm model to the public-key
-   infrastructure.  Users of PKINIT must understand security policies
-   and procedures appropriate to the use of Public Key Infrastructures
-   [RFC3280].
-
-   In order to trust a KDC certificate that is certified by a CA as a
-   KDC certificate for a target realm (for example, by asserting the TGS
-   name of that Kerberos realm as an id-pkinit-san SAN and/or
-   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
-   as described in Section 3.2.4), the client MUST verify that the KDC
-   certificate's issuing CA is authorized to issue KDC certificates for
-   that target realm.  Otherwise, the binding between the KDC
-   certificate and the KDC of the target realm is not established.
-
-   How to validate this authorization is a matter of local policy.  A
-   way to achieve this is the configuration of specific sets of
-   intermediary CAs and trust anchors, one of which must be on the KDC
-   certificate's certification path [RFC3280]; and for each CA or trust
-   anchor the realms for which it is allowed to issue certificates.
-
-   In addition, if any CA is trusted to issue KDC certificates can also
-   issue other kinds of certificates, then local policy must be able to
-   distinguish between them: for example, it could require that KDC
-   certificates contain the id-pkinit-KPKdc EKU or that the realm be
-   specified with the id-pkinit-san SAN.
-
-   It is the responsibility of the PKI administrators for an
-   organization to ensure that KDC certificates are only issued to KDCs,
-   and that clients can ascertain this using their local policy.
-
-   Standard Kerberos allows the possibility of interactions between
-   cryptosystems of varying strengths; this document adds interactions
-   with public-key cryptosystems to Kerberos.  Some administrative
-   policies may allow the use of relatively weak public keys.  When
-   using such weak asymmetric keys to protect/exchange stronger
-   symmetric Keys, the attack resistant strength of the overall system
-   is no better than that of these weak keys [RFC3766].
-
-   PKINIT requires keys for symmetric cryptosystems to be generated.
-   Some such systems contain "weak" keys.  For recommendations regarding
-   these weak keys, see [RFC4120].
-
-   PKINIT allows the use of the same RSA key pair for encryption and
-   signing when doing RSA encryption based key delivery.  This is not
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 28]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   recommended usage of RSA keys [RFC3447], by using DH based key
-   delivery this is avoided.
-
-   Care should be taken in how certificates are chosen for the purposes
-   of authentication using PKINIT.  Some local policies may require that
-   key escrow be used for certain certificate types.  Deployers of
-   PKINIT should be aware of the implications of using certificates that
-   have escrowed keys for the purposes of authentication.  Because
-   signing only certificates are normally not escrowed, by using DH
-   based key delivery this is avoided.
-
-   PKINIT does not provide for a "return routability" test to prevent
-   attackers from mounting a denial-of-service attack on the KDC by
-   causing it to perform unnecessary and expensive public-key
-   operations.  Strictly speaking, this is also true of standard
-   Kerberos, although the potential cost is not as great, because
-   standard Kerberos does not make use of public-key cryptography.  By
-   using DH based key delivery and reusing DH keys, the necessary crypto
-   processing cost per request can be minimized.
-
-   When the Diffie-Hellman key exchange method is used, additional pre-
-   authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as
-   defined in this specification) is not bound to the AS_REQ by the
-   mechanisms discussed in this specification (meaning it may be dropped
-   or added by attackers without being detected by either the client or
-   the KDC).  Designers of additional pre-authentication data should
-   take that into consideration if such additional pre-authentication
-   data can be used in conjunction with the PA_PK_AS_REQ.  The future
-   work of the Kerberos working group is expected to update the hash
-   algorithms specified in this document and provide a generic mechanism
-   to bind additional pre-authentication data with the accompanying
-   AS_REQ.
-
-
-5.  Acknowledgements
-
-   The following people have made significant contributions to this
-   draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
-   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
-   Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
-   Grundman and Jeffrey Altman.
-
-   Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
-   Chris Walstad discovered a binding issue between the AS-REQ and AS-
-   REP in draft -26, the asChecksum field was added as the result.
-
-   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
-   Jonathan Trostle who wrote earlier versions of this document.
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 29]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   The authors are indebted to the Kerberos working group chair Jeffrey
-   Hutzelman who kept track of various issues and was enormously helpful
-   during the creation of this document.
-
-   Some of the ideas on which this document is based arose during
-   discussions over several years between members of the SAAG, the IETF
-   CAT working group, and the PSRG, regarding integration of Kerberos
-   and SPX.  Some ideas have also been drawn from the DASS system.
-   These changes are by no means endorsed by these groups.  This is an
-   attempt to revive some of the goals of those groups, and this
-   document approaches those goals primarily from the Kerberos
-   perspective.
-
-   Lastly, comments from groups working on similar ideas in DCE have
-   been invaluable.
-
-
-6.  IANA Considerations
-
-   This document has no actions for IANA.
-
-
-7.  References
-
-7.1.  Normative References
-
-   [IEEE1363]
-              IEEE, "Standard Specifications for Public Key 
-              Cryptography", IEEE 1363, 2000.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
-              RFC 2412, November 1998.
-
-   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
-              RFC 2631, June 1999.
-
-   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 30]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
-              Algorithms", RFC 3370, August 2002.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
-              Encryption Algorithm in Cryptographic Message Syntax
-              (CMS)", RFC 3565, July 2003.
-
-   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
-              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
-              RFC 3766, April 2004.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
-              Encryption for Kerberos 5", RFC 3962, February 2005.
-
-   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-              Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 
-              Information technology - Abstract Syntax Notation One 
-              (ASN.1): Specification of basic notation.
-
-   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 
-              Information technology - ASN.1 encoding Rules: Specification 
-              of Basic Encoding Rules (BER), Canonical Encoding Rules 
-              (CER) and Distinguished Encoding Rules (DER).
-
-7.2.  Informative References
-
-   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
-              Sizes", Journal of Cryptology 14 (2001) 255-293.
-   
-   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
-              future, Designs, Codes, and Cryptography (1999)".
-              April 1999.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [RFC4158]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
-              Nicholas, "Internet X.509 Public Key Infrastructure:
-              Certification Path Building", RFC 4158, September 2005.
-
-
-Appendix A.  PKINIT ASN.1 Module
-
-       KerberosV5-PK-INIT-SPEC {
-               iso(1) identified-organization(3) dod(6) internet(1)
-               security(5) kerberosV5(2) modules(4) pkinit(5)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       IMPORTS
-           SubjectPublicKeyInfo, AlgorithmIdentifier
-               FROM PKIX1Explicit88 { iso (1)
-                 identified-organization (3) dod (6) internet (1)
-                 security (5) mechanisms (5) pkix (7) id-mod (0)
-                 id-pkix1-explicit (18) }
-                 -- As defined in RFC 3280.
-
-           KerberosTime, PrincipalName, Realm, EncryptionKey
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) } ;
-
-       id-pkinit OBJECT IDENTIFIER ::=
-         { iso (1) org (3) dod (6) internet (1) security (5)
-           kerberosv5 (2) pkinit (3) }
-
-       id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-       id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-       id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-       id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 32]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-       id-pkinit-KPKdc         OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-       id-pkinit-san OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509SanAN (2) }
-
-       pa-pk-as-req INTEGER ::=                  16
-       pa-pk-as-rep INTEGER ::=                  17
-
-       ad-initial-verified-cas INTEGER ::=        9
-
-       td-trusted-certifiers INTEGER ::=        104
-       td-invalid-certificates INTEGER ::=      105
-       td-dh-parameters INTEGER ::=             109
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- Contains a list of CAs, trusted by the client,
-                   -- that can be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 33]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS public key encryption algorithm
-                   -- identifiers, bulk encryption algorithm
-                   -- identifiers, or signature algorithm identifiers
-                   -- supported by the client in order of (decreasing)
-                   -- preference.
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 34]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so.
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING OPTIONAL,
-                   -- MUST be present.
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 35]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is
-                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-                   -- eContent field contains the DER encoding of the
-                   -- type ReplyKeyPack.
-                   -- ReplyKeyPack is defined below.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL,
-                   -- Present if and only if dhKeyExpiration is
-                   -- present.
-          ...
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- The KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the pkAuthenticator field
-                   -- in the request if the DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 36]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if the DH keys are reused.
-                   -- If present, the KDC's DH public key MUST not be
-                   -- used past the point of this expiration time.
-                   -- If this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP, i.e. the
-                   -- AS reply key.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-       END
-
-
-Appendix B.  Test Vectors
-
-   Function octetstring2key() is defined in Section 3.2.3.1.  This
-   section describes a few sets of test vectors that would be useful for
-   implementers of octetstring2key().
-
-
-   Set 1
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 37]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
-     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
-
-
-   Set 2:
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
-     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
-
-
-   Set 3:
-   ======
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 38]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
-     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
-     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
-     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
-     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
-
-
-   Set 4:
-   =====
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
-     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
-
-
-Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
-             Implementations
-
-   Earlier revisions of the PKINIT I-D were implemented in various
-   releases of Microsoft Windows and deployed in fairly large numbers.
-   To enable the community to better interoperate with systems running
-   those releases, the following information may be useful.
-
-   KDC certificates issued by Windows 2000 Enterprise CAs contain a
-   dNSName SAN with the DNS name of the host running the KDC, and the
-   id-kp-serverAuth EKU [RFC3280].
-
-   KDC certificates issued by Windows 2003 Enterprise CAs contain a
-   dNSName SAN with the DNS name of the host running the KDC, the id-kp-
-   serverAuth EKU and the id-ms-kp-sc-logon EKU.
-
-   It is anticipated that the next release of Windows is already too far
-   along to allow it to support the issuing KDC certificates with id-
-   pkinit-san SAN as specified in this RFC.  Instead, they will have a
-   dNSName SAN containing the domain name of the KDC and the intended
-   purpose of these KDC certificates be restricted by the presence of
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 39]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-   the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
-
-   In addition to checking that the above are present in a KDC
-   certificate, Windows clients verify that the issuer of the KDC
-   certificate is one of a set of allowed issuers of such certificates,
-   so those wishing to issue KDC certificates need to configure their
-   Windows clients appropriately.
-
-   Client certificates accepted by Windows 2000 and Windows 2003 Server
-   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
-   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
-   contains a UTF8 encoded string whose value is that of the Directory
-   Service attribute UserPrincipalName of the client account object, and
-   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
-   certificate is to validate the client mapping (in other words, the
-   client's public key is bound to the account that has this
-   UserPrincipalName value).
-
-   It should be noted that all Microsoft Kerberos realm names are domain
-   style realm names and strictly in upper case.  In addition, the
-   UserPrincipalName attribute is globally unique in Windows 2000 and
-   Windows 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 40]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Brian Tung
-   USC Information Sciences Institute
-   4676 Admiralty Way Suite 1001
-   Marina del Rey, CA  90292
-   US
-
-   Email: brian@isi.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 41]
-
-Internet-Draft                   PKINIT                     January 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu & Tung                Expires July 28, 2006                [Page 42]
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-34.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-34.txt
deleted file mode 100644
index af84a08ff..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-34.txt
+++ /dev/null
@@ -1,2346 +0,0 @@
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                     Microsoft Corporation
-Expires: August 11, 2006                                         B. Tung
-                                      USC Information Sciences Institute
-                                                        February 7, 2006
-
-
-     Public Key Cryptography for Initial Authentication in Kerberos
-                   draft-ietf-cat-kerberos-pk-init-34
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 11, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes protocol extensions (hereafter called PKINIT)
-   to the Kerberos protocol specification.  These extensions provide a
-   method for integrating public key cryptography into the initial
-   authentication exchange, by using asymmetric-key signature and/or
-   encryption algorithms in pre-authentication data fields.
-
-
-
-
-
-Zhu & Tung               Expires August 11, 2006                [Page 1]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
-   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  5
-     3.1.  Definitions, Requirements, and Constants . . . . . . . . .  6
-       3.1.1.  Required Algorithms  . . . . . . . . . . . . . . . . .  6
-       3.1.2.  Recommended Algorithms . . . . . . . . . . . . . . . .  6
-       3.1.3.  Defined Message and Encryption Types . . . . . . . . .  7
-       3.1.4.  Kerberos Encryption Types Defined for CMS
-               Algorithm Identifiers  . . . . . . . . . . . . . . . .  8
-     3.2.  PKINIT Pre-authentication Syntax and Use . . . . . . . . .  9
-       3.2.1.  Generation of Client Request . . . . . . . . . . . . .  9
-       3.2.2.  Receipt of Client Request  . . . . . . . . . . . . . . 14
-       3.2.3.  Generation of KDC Reply  . . . . . . . . . . . . . . . 18
-       3.2.4.  Receipt of KDC Reply . . . . . . . . . . . . . . . . . 25
-     3.3.  Interoperability Requirements  . . . . . . . . . . . . . . 26
-     3.4.  KDC Indication of PKINIT Support . . . . . . . . . . . . . 27
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
-   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 30
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 32
-   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 32
-   Appendix B.  Test Vectors  . . . . . . . . . . . . . . . . . . . . 38
-   Appendix C.  Miscellaneous Information about Microsoft Windows
-                PKINIT Implementations  . . . . . . . . . . . . . . . 40
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
-   Intellectual Property and Copyright Statements . . . . . . . . . . 42
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung               Expires August 11, 2006                [Page 2]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-1.  Introduction
-
-   The Kerberos V5 protocol [RFC4120] involves use of a trusted third
-   party known as the Key Distribution Center (KDC) to negotiate shared
-   session keys between clients and services and provide mutual
-   authentication between them.
-
-   The corner-stone of Kerberos V5 is the Ticket and the Authenticator.
-   A Ticket encapsulates a symmetric key (the ticket session key) in an
-   envelope (a public message) intended for a specific service.  The
-   contents of the Ticket are encrypted with a symmetric key shared
-   between the service principal and the issuing KDC.  The encrypted
-   part of the Ticket contains the client principal name, amongst other
-   items.  An Authenticator is a record that can be shown to have been
-   recently generated using the ticket session key in the associated
-   Ticket.  The ticket session key is known by the client who requested
-   the ticket.  The contents of the Authenticator are encrypted with the
-   associated ticket session key.  The encrypted part of an
-   Authenticator contains a timestamp and the client principal name,
-   amongst other items.
-
-   As shown in Figure 1 below, the Kerberos V5 protocol consists of the
-   following message exchanges between the client and the KDC, and the
-   client and the application service:
-
-    - The Authentication Service (AS) Exchange
-
-      The client obtains an "initial" ticket from the Kerberos
-      authentication server (AS), typically a Ticket Granting Ticket
-      (TGT).  The AS-REQ message and the AS-REP message are the request
-      and the reply message respectively between the client and the AS.
-
-    - The Ticket Granting Service (TGS) Exchange
-
-      The client subsequently uses the TGT to authenticate and request a
-      service ticket for a particular service, from the Kerberos ticket-
-      granting server (TGS).  The TGS-REQ message and the TGS-REP
-      message are the request and the reply message respectively between
-      the client and the TGS.
-
-    - The Client/Server Authentication Protocol (AP) Exchange
-
-      The client then makes a request with an AP-REQ message, consisting
-      of a service ticket and an authenticator that certifies the
-      client's possession of the ticket session key.  The server may
-      optionally reply with an AP-REP message.  AP exchanges typically
-      negotiate session specific symmetric keys.
-
-
-
-
-Zhu & Tung               Expires August 11, 2006                [Page 3]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   Usually, the AS and TGS are integrated in a single device also known
-   as the KDC.
-
-      Figure 1:  The Message Exchanges in the Kerberos V5 Protocol
-
-                          +--------------+
-               +--------->|  KDC         |
-       AS-REQ /   +-------|              |
-             /   /        +--------------+
-            /   /          ^           |
-           /    |AS-REP   /            |
-          |     |        / TGS-REQ     + TGS-REP
-          |     |       /             /
-          |     |      /             /
-          |     |     /   +---------+
-          |     |    /   /
-          |     |   /   /
-          |     |  /   /
-          |     v /   v
-         ++-------+------+             +-----------------+
-         |  Client       +------------>|  Application    |
-         |               |    AP-REQ   |  Server         |
-         |               |<------------|                 |
-         +---------------+    AP-REP   +-----------------+
-
-   In the AS exchange, the KDC reply contains the ticket session key,
-   amongst other items, that is encrypted using a key (the AS reply key)
-   shared between the client and the KDC.  The AS reply key is typically
-   derived from the client's password for human users.  Therefore for
-   human users the attack resistance strength of the Kerberos protocol
-   is no stronger than the strength of their passwords.
-
-   The use of asymmetric cryptography in the form of X.509 certificates
-   [RFC3280] is popular for facilitating data origin authentication and
-   perfect secrecy.  An established Public Key Infrastructure (PKI)
-   provides key management and key distribution mechanisms that can be
-   used to establish authentication and secure communication.  Adding
-   public-key cryptography to Kerberos provides a nice congruence to
-   public-key protocols, obviates the human users' burden to manage
-   strong passwords, and allows Kerberized applications to take
-   advantage of existing key services and identity management.
-
-   The advantage afforded by the Kerberos TGT is that the client exposes
-   his long-term secrets only once.  The TGT and its associated session
-   key can then be used for any subsequent service ticket requests.  One
-   result of this is that all further authentication is independent of
-   the method by which the initial authentication was performed.
-   Consequently, initial authentication provides a convenient place to
-
-
-
-Zhu & Tung               Expires August 11, 2006                [Page 4]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   integrate public-key cryptography into Kerberos authentication.  In
-   addition, the use of symmetric cryptography after the initial
-   exchange is preferred for performance.
-
-   This document describes the methods and data formats using which the
-   client and the KDC can use public and private key pairs to mutually
-   authenticate in the AS exchange and negotiate the AS reply key, known
-   only by the client and the KDC, to encrypt the AS-REP sent by the
-   KDC.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   In this protocol, both the client and the KDC have a public-private
-   key pair in order to prove their identities to each other over the
-   open network.  The term "signature key" is used to refer to the
-   private key of the key pair being used.
-
-   The encryption key used to encrypt the enc-part field of the KDC-REP
-   in the AS-REP [RFC4120] is referred to as the AS reply key.
-
-   An empty sequence in an optional field can be either included or
-   omitted: both encodings are permitted and considered equivalent.
-
-   The term "Modular Exponential Diffie-Hellman" is used to refer to the
-   Diffie-Hellman key exchange as described in [RFC2631], in order to
-   differentiate it from other equivalent representations of the same
-   key agreement algorithm.
-
-
-3.  Extensions
-
-   This section describes extensions to [RFC4120] for supporting the use
-   of public-key cryptography in the initial request for a ticket.
-
-   Briefly, this document defines the following extensions to [RFC4120]:
-
-   1. The client indicates the use of public-key authentication by
-      including a special preauthenticator in the initial request.  This
-      preauthenticator contains the client's public-key data and a
-      signature.
-
-
-
-
-
-
-Zhu & Tung               Expires August 11, 2006                [Page 5]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   2. The KDC tests the client's request against its authentication
-      policy and trusted Certification Authorities (CAs).
-
-   3. If the request passes the verification tests, the KDC replies as
-      usual, but the reply is encrypted using either:
-
-      a. a key generated through a Diffie-Hellman (DH) key exchange
-         [RFC2631] [IEEE1363] with the client, signed using the KDC's
-         signature key; or
-
-      b. a symmetric encryption key, signed using the KDC's signature
-         key and encrypted using the client's public key.
-
-      Any keying material required by the client to obtain the
-      encryption key for decrypting the KDC reply is returned in a pre-
-      authentication field accompanying the usual reply.
-
-   4. The client validates the KDC's signature, obtains the encryption
-      key, decrypts the reply, and then proceeds as usual.
-
-   Section 3.1 of this document enumerates the required algorithms and
-   necessary extension message types.  Section 3.2 describes the
-   extension messages in greater detail.
-
-3.1.  Definitions, Requirements, and Constants
-
-3.1.1.  Required Algorithms
-
-   All PKINIT implementations MUST support the following algorithms:
-
-   o  AS reply key enctype(s): aes128-cts-hmac-sha1-96 and aes256-cts-
-      hmac-sha1-96 [RFC3962].
-
-   o  Signature algorithm(s): sha-1WithRSAEncryption [RFC3370].
-
-   o  AS reply key delivery method(s): the Diffie-Hellman key delivery
-      method as described in Section 3.2.3.1.
-
-   In addition, implementations of this specification MUST be capable of
-   processing the Extended Key Usage (EKU) extension and the id-pkinit-
-   san (as defined in Section 3.2.2) otherName of the Subject
-   Alternative Name (SAN) extension in X.509 certificates [RFC3280].
-
-3.1.2.  Recommended Algorithms
-
-   All PKINIT implementations SHOULD support the following algorithms:
-
-
-
-
-
-Zhu & Tung               Expires August 11, 2006                [Page 6]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   o  AS reply key delivery method(s): the public key encryption key
-      delivery method as described in Section 3.2.3.2.
-
-   For implementations that support the public key encryption key
-   delivery method, the following algorithms MUST be supported:
-
-   a) Key transport algorithm(s) identified in the
-      keyEncryptionAlgorithm field of the type KeyTransRecipientInfo
-      [RFC3852] for encrypting the temporary key in the encryptedKey
-      field [RFC3852] with a public key, as described in
-      Section 3.2.3.2: rsaEncryption (this is the RSAES-PKCS1-v1_5
-      encryption scheme) [RFC3370] [RFC3447].
-
-   b) Content encryption algorithm(s) identified in the
-      contentEncryptionAlgorithm field of the type EncryptedContentInfo
-      [RFC3852] for encrypting the AS reply key with the temporary key
-      contained in the encryptedKey field of the type
-      KeyTransRecipientInfo [RFC3852], as described in Section 3.2.3.2:
-      des-ede3-cbc (three-key 3DES, CBC mode) [RFC3370].
-
-3.1.3.  Defined Message and Encryption Types
-
-   PKINIT makes use of the following new pre-authentication types:
-
-       PA_PK_AS_REQ                                 16
-       PA_PK_AS_REP                                 17
-
-   PKINIT also makes use of the following new authorization data type:
-
-       AD_INITIAL_VERIFIED_CAS                       9
-
-   PKINIT introduces the following new error codes:
-
-       KDC_ERR_CLIENT_NOT_TRUSTED                   62
-       KDC_ERR_INVALID_SIG                          64
-       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
-       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
-       KDC_ERR_INVALID_CERTIFICATE                  71
-       KDC_ERR_REVOKED_CERTIFICATE                  72
-       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
-       KDC_ERR_CLIENT_NAME_MISMATCH                 75
-       KDC_ERR_INCONSISTENT_KEY_PURPOSE             77
-       KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED          78
-       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED         79
-       KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED   80
-       KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED  81
-
-   PKINIT uses the following typed data types for errors:
-
-
-
-Zhu & Tung               Expires August 11, 2006                [Page 7]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-       TD_TRUSTED_CERTIFIERS                       104
-       TD_INVALID_CERTIFICATES                     105
-       TD_DH_PARAMETERS                            109
-
-   The ASN.1 module for all structures defined in this document (plus
-   IMPORT statements for all imported structures) is given in
-   Appendix A.
-
-   All structures defined in or imported into this document MUST be
-   encoded using Distinguished Encoding Rules (DER) [X680] [X690]
-   (unless otherwise noted).  All data structures carried in OCTET
-   STRINGs must be encoded according to the rules specified in
-   corresponding specifications.
-
-   Interoperability note: Some implementations may not be able to decode
-   wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects encoded
-   with BER; specifically, they may not be able to decode indefinite
-   length encodings.  To maximize interoperability, implementers SHOULD
-   encode CMS objects used in PKINIT with DER.
-
-3.1.4.  Kerberos Encryption Types Defined for CMS Algorithm Identifiers
-
-   PKINIT defines the following Kerberos encryption type numbers
-   [RFC3961], which can be used in the etype field of the AS-REQ
-   [RFC4120] message to indicate to the KDC the client's acceptance of
-   the corresponding algorithms (including key transport algorithms
-   [RFC3370], content encryption algorithms [RFC3370], and signature
-   algorithms) for use with Cryptographic Message Syntax (CMS) [RFC3852]
-   [RFC3370].
-
-   Per [RFC4120], the encryption types in the etype field are in the
-   decreasing preference order of the client.  Note that there is no
-   significance in the relative order between any two of different types
-   of algorithms: key transport algorithms, content encryption
-   algorithms and signature algorithms.
-
-   The presence of each of these encryption types in the etype field is
-   equivalent to the presence of the corresponding algorithm Object
-   Identifier (OID) in the supportedCMSTypes field as described in
-   Section 3.2.1.  And the preference order expressed in the
-   supportedCMSTypes field would override the preference order listed in
-   the etype field.
-
-
-
-
-
-
-
-
-
-Zhu & Tung               Expires August 11, 2006                [Page 8]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-    Kerberos Encryption Type Name  Num  Corresponding Algorithm OID
-    ============================== === ===============================
-    id-dsa-with-sha1-CmsOID         9  id-dsa-with-sha1 [RFC3370]
-    md5WithRSAEncryption-CmsOID    10  md5WithRSAEncryption [RFC3370]
-    sha-1WithRSAEncryption-CmsOID  11  sha-1WithRSAEncryption [RFC3370]
-    rc2-cbc-EnvOID                 12  rc2-cbc [RFC3370]
-    rsaEncryption-EnvOID           13  rsaEncryption [RFC3447][RFC3370]
-    id-RSAES-OAEP-EnvOID           14  id-RSAES-OAEP [RFC3447][RFC3560]
-    des-ede3-cbc-EnvOID            15  des-ede3-cbc [RFC3370]
-
-   The above encryption type numbers are used only to indicate support
-   for the use of the corresponding algorithms in PKINIT; they do not
-   correspond to actual Kerberos encryption types [RFC3961] and MUST NOT
-   be used in the etype field of the Kerberos EncryptedData type
-   [RFC4120].  The practice of assigning Kerberos encryption type
-   numbers to indicate support for CMS algorithms is considered
-   deprecated, and new numbers should not be assigned for this purpose.
-   Instead, the supportedCMSTypes field should be used to identify the
-   algorithms supported by the client and the preference order of the
-   client.
-
-   For maximum interoperability, however, PKINIT clients wishing to
-   indicate to the KDC the support for one or more of the algorithms
-   listed above SHOULD include the corresponding encryption type
-   number(s) in the etype field of the AS-REQ.
-
-3.2.  PKINIT Pre-authentication Syntax and Use
-
-   This section defines the syntax and use of the various pre-
-   authentication fields employed by PKINIT.
-
-3.2.1.  Generation of Client Request
-
-   The initial authentication request (AS-REQ) is sent as per [RFC4120];
-   in addition, a pre-authentication data element, whose padata-type is
-   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
-   type PA-PK-AS-REQ, is included.
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-
-
-
-Zhu & Tung               Expires August 11, 2006                [Page 9]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- Contains a list of CAs, trusted by the client,
-                   -- that can be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 10]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS algorithm [RFC3370] identifiers
-                   -- that identify key transport algorithms, or
-                   -- content encryption algorithms, or signature
-                   -- algorithms supported by the client in order of
-                   -- (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so (see Section 3.2.3.1).
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING OPTIONAL,
-                   -- MUST be present.
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure contained in the signedAuthPack
-   field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
-   is filled out as follows:
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 11]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is id-pkinit-
-       authData: { iso(1) org(3) dod(6) internet(1) security(5)
-       kerberosv5(2) pkinit(3) authData(1) }.  Notes to CMS
-       implementers: the signed attribute content-type MUST be present
-       in this SignedData instance and its value is id-pkinit-authData
-       according to [RFC3852].
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type AuthPack.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type AuthPack.
-
-   5.  The AuthPack structure contains a PKAuthenticator, the client
-       public key information, the CMS encryption types supported by the
-       client and a DHNonce.  The pkAuthenticator field certifies to the
-       KDC that the client has recent knowledge of the signing key that
-       authenticates the client.  The clientPublicValue field specifies
-       Diffie-Hellman domain parameters and the client's public key
-       value.  The DH public key value is encoded as a BIT STRING
-       according to [RFC3279].  The clientPublicValue field is present
-       only if the client wishes to use the Diffie-Hellman key agreement
-       method.  The supportedCMSTypes field specifies the list of CMS
-       algorithm identifiers that are supported by the client in order
-       of (decreasing) preference, and can be used to identify a
-       signature algorithm or a key transport algorithm [RFC3370] in the
-       keyEncryptionAlgorithm field of the type KeyTransRecipientInfo or
-       a content encryption algorithm [RFC3370] in the
-       contentEncryptionAlgorithm field of the type EncryptedContentInfo
-       [RFC3852] when encrypting the AS reply key as described in
-       Section 3.2.3.2.  However, there is no significance in the
-       relative order between any two of different types of algorithms:
-       key transport algorithms, content encryption algorithms, and
-       signature algorithms.  The clientDHNonce field is described later
-       in this section.
-
-   6.  The ctime field in the PKAuthenticator structure contains the
-       current time on the client's host, and the cusec field contains
-       the microsecond part of the client's timestamp.  The ctime and
-       cusec fields are used together to specify a reasonably accurate
-       timestamp [RFC4120].  The nonce field is chosen randomly.  The
-       paChecksum field MUST be present and it contains a SHA1 checksum
-       that is performed over the KDC-REQ-BODY [RFC4120].  In order to
-       ease future migration from the use of SHA1, the paChecksum field
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 12]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-       is made optional syntactically: when the request is extended to
-       negotiate hash algorithms, the new client wishing not to use SHA1
-       will send the request in the extended message syntax without the
-       paChecksum field.  The KDC conforming to this specification MUST
-       return a KRB-ERROR [RFC4120] message with the code
-       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3).  That
-       will allow a new client to retry with SHA1 if allowed by the
-       local policy.
-
-   7.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the KDC can verify the signature over the
-       type AuthPack.  For path validation, these certificates SHOULD be
-       sufficient to construct at least one certification path from the
-       client certificate to one trust anchor acceptable by the KDC
-       [RFC4158].  The client MUST be capable of including such a set of
-       certificates if configured to do so.  The certificates field MUST
-       NOT contain "root" CA certificates.
-
-   8.  The client's Diffie-Hellman public value (clientPublicValue) is
-       included if and only if the client wishes to use the Diffie-
-       Hellman key agreement method.  The Diffie-Hellman domain
-       parameters [IEEE1363] for the client's public key are specified
-       in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
-       and the client's Diffie-Hellman public key value is mapped to a
-       subjectPublicKey (a BIT STRING) according to [RFC3279].  When
-       using the Diffie-Hellman key agreement method, implementations
-       MUST support Oakley 1024-bit Modular Exponential (MODP) well-
-       known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
-       14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
-       group 16 [RFC3526].
-
-       The Diffie-Hellman field size should be chosen so as to provide
-       sufficient cryptographic security [RFC3766].
-
-       When MODP Diffie-Hellman is used, the exponents should have at
-       least twice as many bits as the symmetric keys that will be
-       derived from them [ODL99].
-
-   9.  The client may wish to reuse DH keys or to allow the KDC to do so
-       (see Section 3.2.3.1).  If so, then the client includes the
-       clientDHNonce field.  This nonce string MUST be as long as the
-       longest key length of the symmetric key types that the client
-       supports.  This nonce MUST be chosen randomly.
-
-   The ExternalPrincipalIdentifier structure is used in this document to
-   identify the subject's public key thereby the subject principal.
-   This structure is filled out as follows:
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 13]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   1.  The subjectName field contains a PKIX type Name encoded according
-       to [RFC3280].  This field identifies the certificate subject by
-       the distinguished subject name.  This field is REQUIRED when
-       there is a distinguished subject name present in the certificate
-       being used.
-
-   2.  The issuerAndSerialNumber field contains a CMS type
-       IssuerAndSerialNumber encoded according to [RFC3852].  This field
-       identifies a certificate of the subject.  This field is REQUIRED
-       for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
-       structures are defined in Section 3.2.2).
-
-   3.  The subjectKeyIdentifier [RFC3852] field identifies the subject's
-       public key by a key identifier.  When an X.509 certificate is
-       referenced, this key identifier matches the X.509
-       subjectKeyIdentifier extension value.  When other certificate
-       formats are referenced, the documents that specify the
-       certificate format and their use with the CMS must include
-       details on matching the key identifier to the appropriate
-       certificate field.  This field is RECOMMENDED for TD-TRUSTED-
-       CERTIFIERS (as defined in Section 3.2.2).
-
-   The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
-   of CAs, trusted by the client, that can be used to certify the KDC.
-   Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
-   (thereby its public key).
-
-   The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
-   SignerIdentifier encoded according to [RFC3852].  This field
-   identifies, if present, a particular KDC public key that the client
-   already has.
-
-3.2.2.  Receipt of Client Request
-
-   Upon receiving the client's request, the KDC validates it.  This
-   section describes the steps that the KDC MUST (unless otherwise
-   noted) take in validating the request.
-
-   The KDC verifies the client's signature in the signedAuthPack field
-   according to [RFC3852].
-
-   If, while validating the client's X.509 certificate [RFC3280], the
-   KDC cannot build a certification path to validate the client's
-   certificate, it sends back a KRB-ERROR [RFC4120] message with the
-   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
-   this error message is a TYPED-DATA (as defined in [RFC4120]) that
-   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
-   whose data-value contains the DER encoding of the type TD-TRUSTED-
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 14]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   CERTIFIERS:
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
-   TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
-   (thereby its public key) trusted by the KDC.
-
-   Upon receiving this error message, the client SHOULD retry only if it
-   has a different set of certificates (from those of the previous
-   requests) that form a certification path (or a partial path) from one
-   of the trust anchors acceptable by the KDC to its own certificate.
-
-   If, while processing the certification path, the KDC determines that
-   the signature on one of the certificates in the signedAuthPack field
-   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
-   message is a TYPED-DATA that contains an element whose data-type is
-   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
-   encoding of the type TD-INVALID-CERTIFICATES:
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
-   TD-INVALID-CERTIFICATES structure identifies a certificate (that was
-   sent by the client) with an invalid signature.
-
-   If more than one X.509 certificate signature is invalid, the KDC MAY
-   include one IssuerAndSerialNumber per invalid signature within the
-   TD-INVALID-CERTIFICATES.
-
-   The client's X.509 certificate is validated according to [RFC3280].
-
-   Based on local policy, the KDC may also check whether any X.509
-   certificates in the certification path validating the client's
-   certificate have been revoked.  If any of them have been revoked, the
-   KDC MUST return an error message with the code
-   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
-   revocation status but is unable to do so, it SHOULD return an error
-   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 15]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   certificate or certificates affected are identified exactly as for
-   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
-
-   Note that the TD_INVALID_CERTIFICATES error data is only used to
-   identify invalid certificates sent by the client in the request.
-
-   The client's public key is then used to verify the signature.  If the
-   signature fails to verify, the KDC MUST return an error message with
-   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
-   this error message.
-
-   In addition to validating the client's signature, the KDC MUST also
-   check that the client's public key used to verify the client's
-   signature is bound to the client's principal name as specified in the
-   AS-REQ as follows:
-
-   1. If the KDC has its own binding between either the client's
-      signature-verification public key or the client's certificate and
-      the client's Kerberos principal name, it uses that binding.
-
-   2. Otherwise, if the client's X.509 certificate contains a Subject
-      Alternative Name (SAN) extension carrying a KRB5PrincipalName
-      (defined below) in the otherName field of the type GeneralName
-      [RFC3280], it binds the client's X.509 certificate to that name.
-
-      The type of the otherName field is AnotherName.  The type-id field
-      of the type AnotherName is id-pkinit-san:
-
-       id-pkinit-san OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509SanAN (2) }
-
-      And the value field of the type AnotherName is a
-      KRB5PrincipalName.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-   If the Kerberos client name in the AS-REQ does not match a name bound
-   by the KDC (the binding can be in the certificate, for example as
-   described above), or if there is no binding found by the KDC, the KDC
-   MUST return an error message with the code
-   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
-   this error message.
-
-   Even if the certification path is validated and the certificate is
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 16]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   mapped to the client's principal name, the KDC may decide not to
-   accept the client's certificate, depending on local policy.
-
-   The KDC MAY require the presence of an Extended Key Usage (EKU)
-   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
-   of the client's X.509 certificate:
-
-       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) keyPurposeClientAuth(4) }
-              -- PKINIT client authentication.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   The digitalSignature key usage bit [RFC3280] MUST be asserted when
-   the intended purpose of the client's X.509 certificate is restricted
-   with the id-pkinit-KPClientAuth EKU.
-
-   If this EKU KeyPurposeId is required but it is not present or if the
-   client certificate is restricted not to be used for PKINIT client
-   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
-   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
-   is no accompanying e-data for this error message.  KDCs implementing
-   this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
-   logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
-   are a large number of X.509 client certificates deployed for use with
-   PKINIT which have this EKU.
-
-   As a matter of local policy, the KDC MAY decide to reject requests on
-   the basis of the absence or presence of other specific EKU OID's.
-
-   If the digest algorithm used in generating the CA signature for the
-   public key in any certificate of the request is not acceptable by the
-   KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED.  The accompanying e-data MUST be
-   encoded in TYPED-DATA although none is defined at this point.
-
-   If the client's public key is not accepted with reasons other than
-   what were specified above, the KDC returns a KRB-ERROR [RFC4120]
-   message with the code KDC_ERR_CLIENT_NOT_TRUSTED.  There is no
-   accompanying e-data currently defined for this error message.
-
-   The KDC MUST check the timestamp to ensure that the request is not a
-   replay, and that the time skew falls within acceptable limits.  The
-   recommendations for clock skew times in [RFC4120] apply here.  If the
-   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
-   KRB_AP_ERR_SKEW, respectively.
-
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 17]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   If the clientPublicValue is filled in, indicating that the client
-   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
-   check to see if the key parameters satisfy its policy.  If they do
-   not, it MUST return an error message with the code
-   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
-   TYPED-DATA that contains an element whose data-type is
-   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
-   the type TD-DH-PARAMETERS:
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-
-   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
-   that the KDC supports in decreasing preference order, from which the
-   client SHOULD pick one to retry the request.
-
-   The AlgorithmIdentifier structure is defined in [RFC3280] and is
-   filled in according to [RFC3279].  More specifically Section 2.3.3 of
-   [RFC3279] describes how to fill in the AlgorithmIdentifier structure
-   in the case where MODP Diffie-Hellman key exchange is used.
-
-   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
-   KDC does not possess the corresponding key, the KDC MUST ignore the
-   kdcPkId field as if the client did not include one.
-
-   If the digest algorithm used by the id-pkinit-authData is not
-   acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
-   message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
-   The accompanying e-data MUST be encoded in TYPED-DATA although none
-   is defined at this point.
-
-3.2.3.  Generation of KDC Reply
-
-   If the paChecksum filed in the request is not present, the KDC
-   conforming to this specification MUST return a KRB-ERROR [RFC4120]
-   message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED.  The
-   accompanying e-data MUST be encoded in TYPED-DATA (no error data is
-   defined by this specification).
-
-   Assuming that the client's request has been properly validated, the
-   KDC proceeds as per [RFC4120], except as follows.
-
-   The KDC MUST set the initial flag and include an authorization data
-   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
-   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
-   type AD-INITIAL-VERIFIED-CAS:
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 18]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   The AD-INITIAL-VERIFIED-CAS structure identifies the certification
-   path based on which the client certificate was validated.  Each
-   ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
-   INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
-   (thereby its public key).
-
-   Note that the syntax for the AD-INITIAL-VERIFIED-CAS authorization
-   data does permit empty SEQUENCEs to be encoded.  Such empty sequences
-   may only be used if the KDC itself vouches for the user's
-   certificate.
-
-   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-   containers if the list of CAs satisfies the AS' realm's local policy
-   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
-   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
-   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
-   resulting ticket.  If the list of CAs satisfies the local KDC's
-   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
-   container, otherwise it MAY unwrap the authorization data out of the
-   AD-IF-RELEVANT container.
-
-   Application servers that understand this authorization data type
-   SHOULD apply local policy to determine whether a given ticket bearing
-   such a type *not* contained within an AD-IF-RELEVANT container is
-   acceptable.  (This corresponds to the AP server checking the
-   transited field when the TRANSITED-POLICY-CHECKED flag has not been
-   set [RFC4120].)  If such a data type is contained within an AD-IF-
-   RELEVANT container, AP servers MAY apply local policy to determine
-   whether the authorization data is acceptable.
-
-   A pre-authentication data element, whose padata-type is PA_PK_AS_REP
-   and whose padata-value contains the DER encoding of the type PA-PK-
-   AS-REP (defined below), is included in the AS-REP [RFC4120].
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 19]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is
-                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-                   -- eContent field contains the DER encoding of the
-                   -- type ReplyKeyPack.
-                   -- ReplyKeyPack is defined in Section 3.2.3.2.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL,
-                   -- Present if and only if dhKeyExpiration is
-                   -- present in the KDCDHKeyInfo.
-          ...
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- The KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the pkAuthenticator field
-                   -- in the request if the DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if the DH keys are reused.
-                   -- If present, the KDC's DH public key MUST not be
-                   -- used past the point of this expiration time.
-                   -- If this field is omitted then the serverDHNonce
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 20]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-                   -- field MUST also be omitted.
-          ...
-       }
-
-   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
-   KDC encrypts the reply as usual, but not with the client's long-term
-   key.  Instead, it encrypts it with either a shared key derived from a
-   Diffie-Hellman exchange, or a generated encryption key.  The contents
-   of the PA-PK-AS-REP indicate which key delivery method is used.
-
-   If the client does not wish to use the Diffie-Hellman key delivery
-   method (the clientPublicValue field is not present in the request)
-   and the KDC does not support the public key encryption key delivery
-   method, the KDC MUST return an error message with the code
-   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED.  There is no
-   accompanying e-data for this error message.
-
-   In addition, the lifetime of the ticket returned by the KDC MUST NOT
-   exceed that of the client's public-private key pair.  The ticket
-   lifetime, however, can be shorter than that of the client's public-
-   private key pair.  For the implementations of this specification, the
-   lifetime of the client's public-private key pair is the validity
-   period in X.509 certificates [RFC3280], unless configured otherwise.
-
-3.2.3.1.  Using Diffie-Hellman Key Exchange
-
-   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
-
-   The ContentInfo [RFC3852] structure for the dhSignedData field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is the OID value
-       for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
-       security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.  Notes to CMS
-       implementers: the signed attribute content-type MUST be present
-       in this SignedData instance and its value is id-pkinit-DHKeyData
-       according to [RFC3852].
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type KDCDHKeyInfo.
-
-   4.  The KDCDHKeyInfo structure contains the KDC's public key, a nonce
-       and optionally the expiration time of the KDC's DH key being
-       reused.  The subjectPublicKey field of the type KDCDHKeyInfo
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 21]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-       field identifies KDC's DH public key.  This DH public key value
-       is encoded as a BIT STRING according to [RFC3279].  The nonce
-       field contains the nonce in the pkAuthenticator field in the
-       request if the DH keys are NOT reused.  The value of this nonce
-       field is 0 if the DH keys are reused.  The dhKeyExpiration field
-       is present if and only if the DH keys are reused.  If the
-       dhKeyExpiration field is present, the KDC's public key in this
-       KDCDHKeyInfo structure MUST NOT be used past the point of this
-       expiration time.  If this field is omitted then the serverDHNonce
-       field MUST also be omitted.
-
-   5.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type
-       KDCDHKeyInfo.
-
-   6.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type KDCDHKeyInfo.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may be left empty if the KDC
-       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
-       used for signing.  Otherwise, for path validation, these
-       certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [RFC4158].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  If the client included the clientDHNonce field, then the KDC may
-       choose to reuse its DH keys.  If the server reuses DH keys then
-       it MUST include an expiration time in the dhKeyExpiration field.
-       Past the point of the expiration time, the signature over the
-       type DHRepInfo is considered expired/invalid.  When the server
-       reuses DH keys then it MUST include a serverDHNonce at least as
-       long as the length of keys for the symmetric encryption system
-       used to encrypt the AS reply.  Note that including the
-       serverDHNonce changes how the client and server calculate the key
-       to use to encrypt the reply; see below for details.  The KDC
-       SHOULD NOT reuse DH keys unless the clientDHNonce field is
-       present in the request.
-
-   The AS reply key is derived as follows:
-
-
-
-
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 22]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   1. Both the KDC and the client calculate the shared secret value as
-      follows:
-
-      a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
-         shared secret value.  DHSharedSecret is the value ZZ as
-         described in Section 2.1.1 of [RFC2631].
-
-      DHSharedSecret is first padded with leading zeros such that the
-      size of DHSharedSecret in octets is the same as that of the
-      modulus, then represented as a string of octets in big-endian
-      order.
-
-      Implementation note: Both the client and the KDC can cache the
-      triple (ya, yb, DHSharedSecret), where ya is the client's public
-      key and yb is the KDC's public key.  If both ya and yb are the
-      same in a later exchange, the cached DHSharedSecret can be used.
-
-   2. Let K be the key-generation seed length [RFC3961] of the AS reply
-      key whose enctype is selected according to [RFC4120].
-
-   3. Define the function octetstring2key() as follows:
-
-           octetstring2key(x) == random-to-key(K-truncate(
-                                    SHA1(0x00 | x) |
-                                    SHA1(0x01 | x) |
-                                    SHA1(0x02 | x) |
-                                    ...
-                                    ))
-
-      where x is an octet string; | is the concatenation operator; 0x00,
-      0x01, 0x02, etc., are each represented as a single octet; random-
-      to-key() is an operation that generates a protocol key from a
-      bitstring of length K; and K-truncate truncates its input to the
-      first K bits.  Both K and random-to-key() are as defined in the
-      kcrypto profile [RFC3961] for the enctype of the AS reply key.
-
-   4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
-      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
-      strings.
-
-   5. The AS reply key k is:
-
-           k = octetstring2key(DHSharedSecret | n_c | n_k)
-
-3.2.3.2.  Using Public Key Encryption
-
-   In this case, the PA-PK-AS-REP contains the encKeyPack field where
-   the AS reply key is encrypted.
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 23]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   The ContentInfo [RFC3852] structure for the encKeyPack field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-envelopedData
-       (as defined in [RFC3852]), and the content field is an
-       EnvelopedData (as defined in [RFC3852]).
-
-   2.  The contentType field for the type EnvelopedData is id-
-       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
-       pkcs (1) pkcs7 (7) signedData (2) }.
-
-   3.  The eContentType field for the inner type SignedData (when
-       decrypted from the encryptedContent field for the type
-       EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
-       internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
-       Notes to CMS implementers: the signed attribute content-type MUST
-       be present in this SignedData instance and its value is id-
-       pkinit-rkeyData according to [RFC3852].
-
-   4.  The eContent field for the inner type SignedData contains the DER
-       encoding of the type ReplyKeyPack (as described below).
-
-   5.  The signerInfos field of the inner type SignedData contains a
-       single signerInfo, which contains the signature for the type
-       ReplyKeyPack.
-
-   6.  The certificates field of the inner type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       for the type ReplyKeyPack.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may be left empty if the KDC
-       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
-       used for signing.  Otherwise, for path validation, these
-       certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [RFC4158].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  The recipientInfos field of the type EnvelopedData is a SET which
-       MUST contain exactly one member of type KeyTransRecipientInfo.
-       The encryptedKey of this member contains the temporary key which
-       is encrypted using the client's public key.
-
-
-
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 24]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   8.  The unprotectedAttrs or originatorInfo fields of the type
-       EnvelopedData MAY be present.
-
-   If there is a supportedCMSTypes field in the AuthPack, the KDC must
-   check to see if it supports any of the listed types.  If it supports
-   more than one of the types, the KDC SHOULD use the one listed first.
-   If it does not support any of them, it MUST return an error message
-   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
-
-   Furthermore the KDC computes the checksum of the AS-REQ in the client
-   request.  This checksum is performed over the type AS-REQ and the
-   protocol key [RFC3961] of the checksum operation is the replyKey and
-   the key usage number is 6.  If the replyKey's enctype is "newer"
-   [RFC4120] [RFC4121], the checksum operation is the required checksum
-   operation [RFC3961] of that enctype.
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP, i.e. the
-                   -- AS reply key.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-   Implementations of this RSA encryption key delivery method are
-   RECOMMENDED to support RSA keys at least 2048 bits in size.
-
-3.2.4.  Receipt of KDC Reply
-
-   Upon receipt of the KDC's reply, the client proceeds as follows.  If
-   the PA-PK-AS-REP contains the dhSignedData field, the client derives
-   the AS reply key using the same procedure used by the KDC as defined
-   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
-   field, and the client decrypts and extracts the temporary key in the
-   encryptedKey field of the member KeyTransRecipientInfo, and then uses
-   that as the AS reply key.
-
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 25]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   If the public key encryption method is used, the client MUST verify
-   the asChecksum contained in the ReplyKeyPack.
-
-   In either case, the client MUST verify the signature in the
-   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
-   be validated according to [RFC3280].  In addition, unless the client
-   can otherwise verify that the public key used to verify the KDC's
-   signature is bound to the KDC of the target realm, the KDC's X.509
-   certificate MUST contain a Subject Alternative Name extension
-   [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
-   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
-   matches the name of the TGS of the target realm (as defined in
-   Section 7.3 of [RFC4120]).
-
-   Unless the client knows by some other means that the KDC certificate
-   is intended for a Kerberos KDC, the client MUST require that the KDC
-   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
-
-       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) keyPurposeKdc(5) }
-              -- Signing KDC responses.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   The digitalSignature key usage bit [RFC3280] MUST be asserted when
-   the intended purpose of the KDC's X.509 certificate is restricted
-   with the id-pkinit-KPKdc EKU.
-
-   If the KDC certificate contains the Kerberos TGS name encoded as an
-   id-pkinit-san SAN, this certificate is certified by the issuing CA as
-   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
-
-   If all applicable checks are satisfied, the client then decrypts the
-   enc-part field of the KDC-REP in the AS-REP using the AS reply key,
-   and then proceeds as described in [RFC4120].
-
-3.3.  Interoperability Requirements
-
-   The client MUST be capable of sending a set of certificates
-   sufficient to allow the KDC to construct a certification path for the
-   client's certificate, if the correct set of certificates is provided
-   through configuration or policy.
-
-   If the client sends all the X.509 certificates on a certification
-   path to a trust anchor acceptable by the KDC, and the KDC can not
-   verify the client's public key otherwise, the KDC MUST be able to
-   process path validation for the client's certificate based on the
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 26]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   certificates in the request.
-
-   The KDC MUST be capable of sending a set of certificates sufficient
-   to allow the client to construct a certification path for the KDC's
-   certificate, if the correct set of certificates is provided through
-   configuration or policy.
-
-   If the KDC sends all the X.509 certificates on a certification path
-   to a trust anchor acceptable by the client, and the client can not
-   verify the KDC's public key otherwise, the client MUST be able to
-   process path validation for the KDC's certificate based on the
-   certificates in the reply.
-
-3.4.  KDC Indication of PKINIT Support
-
-   If pre-authentication is required, but was not present in the
-   request, per [RFC4120] an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
-   stored in the e-data field of the KRB-ERROR message to specify which
-   pre-authentication mechanisms are acceptable.  The KDC can then
-   indicate the support of PKINIT by including an empty element whose
-   padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
-
-   Otherwise if it is required by the KDC's local policy that the client
-   must be pre-authenticated using the pre-authentication mechanism
-   specified in this document, but no PKINIT pre-authentication was
-   present in the request, an error message with the code
-   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
-
-   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
-   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
-   STRING), and clients MUST ignore this and any other value.  Future
-   extensions to this protocol may specify other data to send instead of
-   an empty OCTET STRING.
-
-
-4.  Security Considerations
-
-   The security of cryptographic algorithms is dependent on generating
-   secret quantities [RFC4086].  The number of truly random bits is
-   extremely important to determining the attack resistance strength of
-   the cryptosystem, for example, the secret Diffie-Hellman exponents
-   must be chosen based on n truly random bits (where n is the system
-   security requirement).  The security of the overall system is
-   significantly weakened by using insufficient random inputs: a
-   sophisticated attacker may find it easier to reproduce the
-   environment that produced the secret quantities and to search the
-   resulting small set of possibilities than to locate the quantities in
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 27]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   the whole of the potential number space.
-
-   Kerberos error messages are not integrity protected, as a result, the
-   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
-   with by an attacker so that the set of domain parameters selected
-   could be either weaker or not mutually preferred.  Local policy can
-   configure sets of domain parameters acceptable locally, or disallow
-   the negotiation of DH domain parameters.
-
-   The symmetric reply key size and Diffie-Hellman field size or RSA
-   modulus size should be chosen so as to provide sufficient
-   cryptographic security [RFC3766].
-
-   When MODP Diffie-Hellman is used, the exponents should have at least
-   twice as many bits as the symmetric keys that will be derived from
-   them [ODL99].
-
-   PKINIT raises certain security considerations beyond those that can
-   be regulated strictly in protocol definitions.  We will address them
-   in this section.
-
-   PKINIT extends the cross-realm model to the public-key
-   infrastructure.  Users of PKINIT must understand security policies
-   and procedures appropriate to the use of Public Key Infrastructures
-   [RFC3280].
-
-   In order to trust a KDC certificate that is certified by a CA as a
-   KDC certificate for a target realm (for example, by asserting the TGS
-   name of that Kerberos realm as an id-pkinit-san SAN and/or
-   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
-   as described in Section 3.2.4), the client MUST verify that the KDC
-   certificate's issuing CA is authorized to issue KDC certificates for
-   that target realm.  Otherwise, the binding between the KDC
-   certificate and the KDC of the target realm is not established.
-
-   How to validate this authorization is a matter of local policy.  A
-   way to achieve this is the configuration of specific sets of
-   intermediary CAs and trust anchors, one of which must be on the KDC
-   certificate's certification path [RFC3280]; and for each CA or trust
-   anchor the realms for which it is allowed to issue certificates.
-
-   In addition, if any CA is trusted to issue KDC certificates can also
-   issue other kinds of certificates, then local policy must be able to
-   distinguish between them: for example, it could require that KDC
-   certificates contain the id-pkinit-KPKdc EKU or that the realm be
-   specified with the id-pkinit-san SAN.
-
-   It is the responsibility of the PKI administrators for an
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 28]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   organization to ensure that KDC certificates are only issued to KDCs,
-   and that clients can ascertain this using their local policy.
-
-   Standard Kerberos allows the possibility of interactions between
-   cryptosystems of varying strengths; this document adds interactions
-   with public-key cryptosystems to Kerberos.  Some administrative
-   policies may allow the use of relatively weak public keys.  When
-   using such weak asymmetric keys to protect/exchange stronger
-   symmetric Keys, the attack resistant strength of the overall system
-   is no better than that of these weak keys [RFC3766].
-
-   PKINIT requires keys for symmetric cryptosystems to be generated.
-   Some such systems contain "weak" keys.  For recommendations regarding
-   these weak keys, see [RFC4120].
-
-   PKINIT allows the use of the same RSA key pair for encryption and
-   signing when doing RSA encryption based key delivery.  This is not
-   recommended usage of RSA keys [RFC3447], by using DH based key
-   delivery this is avoided.
-
-   Care should be taken in how certificates are chosen for the purposes
-   of authentication using PKINIT.  Some local policies may require that
-   key escrow be used for certain certificate types.  Deployers of
-   PKINIT should be aware of the implications of using certificates that
-   have escrowed keys for the purposes of authentication.  Because
-   signing only certificates are normally not escrowed, by using DH
-   based key delivery this is avoided.
-
-   PKINIT does not provide for a "return routability" test to prevent
-   attackers from mounting a denial-of-service attack on the KDC by
-   causing it to perform unnecessary and expensive public-key
-   operations.  Strictly speaking, this is also true of standard
-   Kerberos, although the potential cost is not as great, because
-   standard Kerberos does not make use of public-key cryptography.  By
-   using DH based key delivery and reusing DH keys, the necessary crypto
-   processing cost per request can be minimized.
-
-   When the Diffie-Hellman key exchange method is used, additional pre-
-   authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as
-   defined in this specification) is not bound to the AS_REQ by the
-   mechanisms discussed in this specification (meaning it may be dropped
-   or added by attackers without being detected by either the client or
-   the KDC).  Designers of additional pre-authentication data should
-   take that into consideration if such additional pre-authentication
-   data can be used in conjunction with the PA_PK_AS_REQ.  The future
-   work of the Kerberos working group is expected to update the hash
-   algorithms specified in this document and provide a generic mechanism
-   to bind additional pre-authentication data with the accompanying
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 29]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   AS_REQ.
-
-
-5.  Acknowledgements
-
-   The following people have made significant contributions to this
-   draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
-   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
-   Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
-   Grundman and Jeffrey Altman.
-
-   Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
-   Chris Walstad discovered a binding issue between the AS-REQ and AS-
-   REP in draft -26, the asChecksum field was added as the result.
-
-   Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
-   Jonathan Trostle who wrote earlier versions of this document.
-
-   The authors are indebted to the Kerberos working group chair Jeffrey
-   Hutzelman who kept track of various issues and was enormously helpful
-   during the creation of this document.
-
-   Some of the ideas on which this document is based arose during
-   discussions over several years between members of the SAAG, the IETF
-   CAT working group, and the PSRG, regarding integration of Kerberos
-   and SPX.  Some ideas have also been drawn from the DASS system.
-   These changes are by no means endorsed by these groups.  This is an
-   attempt to revive some of the goals of those groups, and this
-   document approaches those goals primarily from the Kerberos
-   perspective.
-
-   Lastly, comments from groups working on similar ideas in DCE have
-   been invaluable.
-
-
-6.  IANA Considerations
-
-   This document has no actions for IANA.
-
-
-7.  References
-
-7.1.  Normative References
-
-   [IEEE1363]
-              IEEE, "Standard Specifications for Public Key 
-              Cryptography", IEEE 1363, 2000.
-
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 30]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol",
-              RFC 2412, November 1998.
-
-   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
-              RFC 2631, June 1999.
-
-   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
-              Algorithms", RFC 3370, August 2002.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-   [RFC3560]  Housley, R., "Use of the RSAES-OAEP Key Transport
-              Algorithm in Cryptographic Message Syntax (CMS)",
-              RFC 3560, July 2003.
-
-   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
-              Encryption Algorithm in Cryptographic Message Syntax
-              (CMS)", RFC 3565, July 2003.
-
-   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
-              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
-              RFC 3766, April 2004.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 31]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
-              Encryption for Kerberos 5", RFC 3962, February 2005.
-
-   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-              Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 
-              Information technology - Abstract Syntax Notation One 
-              (ASN.1): Specification of basic notation.
-
-   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 
-              Information technology - ASN.1 encoding Rules: Specification 
-              of Basic Encoding Rules (BER), Canonical Encoding Rules 
-              (CER) and Distinguished Encoding Rules (DER).
-
-7.2.  Informative References
-
-   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
-              Sizes", Journal of Cryptology 14 (2001) 255-293.
-   
-   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
-              future, Designs, Codes, and Cryptography (1999)".
-              April 1999.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [RFC4158]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
-              Nicholas, "Internet X.509 Public Key Infrastructure:
-              Certification Path Building", RFC 4158, September 2005.
-
-
-Appendix A.  PKINIT ASN.1 Module
-
-       KerberosV5-PK-INIT-SPEC {
-               iso(1) identified-organization(3) dod(6) internet(1)
-               security(5) kerberosV5(2) modules(4) pkinit(5)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       IMPORTS
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 32]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-           SubjectPublicKeyInfo, AlgorithmIdentifier
-               FROM PKIX1Explicit88 { iso (1)
-                 identified-organization (3) dod (6) internet (1)
-                 security (5) mechanisms (5) pkix (7) id-mod (0)
-                 id-pkix1-explicit (18) }
-                 -- As defined in RFC 3280.
-
-           KerberosTime, PrincipalName, Realm, EncryptionKey
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) } ;
-
-       id-pkinit OBJECT IDENTIFIER ::=
-         { iso (1) org (3) dod (6) internet (1) security (5)
-           kerberosv5 (2) pkinit (3) }
-
-       id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-       id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-       id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-       id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-       id-pkinit-KPKdc         OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-       id-pkinit-san OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509SanAN (2) }
-
-       pa-pk-as-req INTEGER ::=                  16
-       pa-pk-as-rep INTEGER ::=                  17
-
-       ad-initial-verified-cas INTEGER ::=        9
-
-       td-trusted-certifiers INTEGER ::=        104
-       td-invalid-certificates INTEGER ::=      105
-       td-dh-parameters INTEGER ::=             109
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 33]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- Contains a list of CAs, trusted by the client,
-                   -- that can be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 34]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS algorithm [RFC3370] identifiers
-                   -- that identify key transport algorithms, or
-                   -- content encryption algorithms, or signature
-                   -- algorithms supported by the client in order of
-                   -- (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so.
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  This nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING OPTIONAL,
-                   -- MUST be present.
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 35]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is
-                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-                   -- eContent field contains the DER encoding of the
-                   -- type ReplyKeyPack.
-                   -- ReplyKeyPack is defined below.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 36]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL,
-                   -- Present if and only if dhKeyExpiration is
-                   -- present.
-          ...
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- The KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the pkAuthenticator field
-                   -- in the request if the DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if the DH keys are reused.
-                   -- If present, the KDC's DH public key MUST not be
-                   -- used past the point of this expiration time.
-                   -- If this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP, i.e. the
-                   -- AS reply key.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 37]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-       END
-
-
-Appendix B.  Test Vectors
-
-   Function octetstring2key() is defined in Section 3.2.3.1.  This
-   section describes a few sets of test vectors that would be useful for
-   implementers of octetstring2key().
-
-
-   Set 1
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
-     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
-
-
-   Set 2:
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 38]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
-     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
-
-
-   Set 3:
-   ======
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
-     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
-     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
-     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
-     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
-
-
-   Set 4:
-   =====
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
-     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
-
-
-
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 39]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
-             Implementations
-
-   Earlier revisions of the PKINIT I-D were implemented in various
-   releases of Microsoft Windows and deployed in fairly large numbers.
-   To enable the community to better interoperate with systems running
-   those releases, the following information may be useful.
-
-   KDC certificates issued by Windows 2000 Enterprise CAs contain a
-   dNSName SAN with the DNS name of the host running the KDC, and the
-   id-kp-serverAuth EKU [RFC3280].
-
-   KDC certificates issued by Windows 2003 Enterprise CAs contain a
-   dNSName SAN with the DNS name of the host running the KDC, the id-kp-
-   serverAuth EKU and the id-ms-kp-sc-logon EKU.
-
-   It is anticipated that the next release of Windows is already too far
-   along to allow it to support the issuing KDC certificates with id-
-   pkinit-san SAN as specified in this RFC.  Instead, they will have a
-   dNSName SAN containing the domain name of the KDC and the intended
-   purpose of these KDC certificates be restricted by the presence of
-   the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
-
-   In addition to checking that the above are present in a KDC
-   certificate, Windows clients verify that the issuer of the KDC
-   certificate is one of a set of allowed issuers of such certificates,
-   so those wishing to issue KDC certificates need to configure their
-   Windows clients appropriately.
-
-   Client certificates accepted by Windows 2000 and Windows 2003 Server
-   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
-   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
-   contains a UTF8 encoded string whose value is that of the Directory
-   Service attribute UserPrincipalName of the client account object, and
-   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
-   certificate is to validate the client mapping (in other words, the
-   client's public key is bound to the account that has this
-   UserPrincipalName value).
-
-   It should be noted that all Microsoft Kerberos realm names are domain
-   style realm names and strictly in upper case.  In addition, the
-   UserPrincipalName attribute is globally unique in Windows 2000 and
-   Windows 2003.
-
-
-
-
-
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 40]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Brian Tung
-   USC Information Sciences Institute
-   4676 Admiralty Way Suite 1001
-   Marina del Rey, CA  90292
-   US
-
-   Email: brian@isi.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 41]
-
-Internet-Draft                   PKINIT                    February 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu & Tung               Expires August 11, 2006               [Page 42]
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-9.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-init-9.txt
deleted file mode 100644
index 748f08954..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-init-9.txt
+++ /dev/null
@@ -1,908 +0,0 @@
-INTERNET-DRAFT                                                Brian Tung
-draft-ietf-cat-kerberos-pk-init-09.txt                   Clifford Neuman
-Updates: RFC 1510                                                    ISI
-expires December 1, 1999                                     Matthew Hur
-                                                   CyberSafe Corporation
-                                                           Ari Medvinsky
-                                                                  Excite
-                                                         Sasha Medvinsky
-                                                      General Instrument
-                                                               John Wray
-                                                   Iris Associates, Inc.
-                                                        Jonathan Trostle
-                                                                   Cisco
-
-    Public Key Cryptography for Initial Authentication in Kerberos
-
-0.  Status Of This Memo
-
-    This document is an Internet-Draft and is in full conformance with
-    all provisions of Section 10 of RFC 2026.  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."
-
-
-    The list of current Internet-Drafts can be accessed at
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-    The list of Internet-Draft Shadow Directories can be accessed at
-    http://www.ietf.org/shadow.html.
-
-    To learn the current status of any Internet-Draft, please check
-    the "1id-abstracts.txt" listing contained in the Internet-Drafts
-    Shadow Directories on ftp.ietf.org (US East Coast),
-    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-    munnari.oz.au (Pacific Rim).
-
-    The distribution of this memo is unlimited.  It is filed as
-    draft-ietf-cat-kerberos-pk-init-09.txt, and expires December 1,
-    1999.  Please send comments to the authors.
-
-1.  Abstract
-
-    This document defines extensions (PKINIT) to the Kerberos protocol
-    specification (RFC 1510 [1]) to provide a method for using public
-    key cryptography during initial authentication.  The methods
-    defined specify the ways in which preauthentication data fields and
-    error data fields in Kerberos messages are to be used to transport
-    public key data.
-
-2.  Introduction
-
-    The popularity of public key cryptography has produced a desire for
-    its support in Kerberos [2].  The advantages provided by public key
-    cryptography include simplified key management (from the Kerberos
-    perspective) and the ability to leverage existing and developing
-    public key certification infrastructures.
-
-    Public key cryptography can be integrated into Kerberos in a number
-    of ways.  One is to associate a key pair with each realm, which can
-    then be used to facilitate cross-realm authentication; this is the
-    topic of another draft proposal.  Another way is to allow users with
-    public key certificates to use them in initial authentication.  This
-    is the concern of the current document.
-
-    PKINIT utilizes Diffie-Hellman keys in combination with digital
-    signature keys as the primary, required mechanism.  It also allows
-    for the use of RSA keys.  Note that PKINIT supports the use of
-    separate signature and encryption keys.
-
-    PKINIT enables access to Kerberos-secured services based on initial
-    authentication utilizing public key cryptography.  PKINIT utilizes
-    standard public key signature and encryption data formats within the
-    standard Kerberos messages.  The basic mechanism is as follows:  The
-    user sends a request to the KDC as before, except that if that user
-    is to use public key cryptography in the initial authentication
-    step, his certificate and a signature accompany the initial request
-    in the preauthentication fields.  Upon receipt of this request, the
-    KDC verifies the certificate and issues a ticket granting ticket
-    (TGT) as before, except that the encPart from the AS-REP message
-    carrying the TGT is now encrypted utilizing either a Diffie-Hellman
-    derived key or the user's public key.  This message is authenticated
-    utilizing the public key signature of the KDC.
-
-    The PKINIT specification may also be used as a building block for
-    other specifications.  PKCROSS [3] utilizes PKINIT for establishing
-    the inter-realm key and associated inter-realm policy to be applied
-    in issuing cross realm service tickets.  As specified in [4],
-    anonymous Kerberos tickets can be issued by applying a NULL
-    signature in combination with Diffie-Hellman in the PKINIT exchange.
-    Additionally, the PKINIT specification may be used for direct peer
-    to peer authentication without contacting a central KDC. This
-    application of PKINIT is described in PKTAPP [5] and is based on
-    concepts introduced in [6, 7]. For direct client-to-server
-    authentication, the client uses PKINIT to authenticate to the end
-    server (instead of a central KDC), which then issues a ticket for
-    itself.  This approach has an advantage over TLS [8] in that the
-    server does not need to save state (cache session keys).
-    Furthermore, an additional benefit is that Kerberos tickets can
-    facilitate delegation (see [9]).
-
-3.  Proposed Extensions
-
-    This section describes extensions to RFC 1510 for supporting the
-    use of public key cryptography in the initial request for a ticket
-    granting ticket (TGT).
-
-    In summary, the following change to RFC 1510 is proposed:
-
-        * Users may authenticate using either a public key pair or a
-          conventional (symmetric) key.  If public key cryptography is
-          used, public key data is transported in preauthentication
-          data fields to help establish identity.  The user presents
-          a public key certificate and obtains an ordinary TGT that may
-          be used for subsequent authentication, with such
-          authentication using only conventional cryptography.
-
-    Section 3.1 provides definitions to help specify message formats.
-    Section 3.2 describes the extensions for the initial authentication
-    method.
-
-3.1.  Definitions
-
-    The extensions involve new preauthentication fields; we introduce
-    the following preauthentication types:
-
-        PA-PK-AS-REQ                            14
-        PA-PK-AS-REP                            15
-
-    The extensions also involve new error types; we introduce the
-    following types:
-
-        KDC_ERR_CLIENT_NOT_TRUSTED              62
-        KDC_ERR_KDC_NOT_TRUSTED                 63
-        KDC_ERR_INVALID_SIG                     64
-        KDC_ERR_KEY_TOO_WEAK                    65
-        KDC_ERR_CERTIFICATE_MISMATCH            66
-        KDC_ERR_CANT_VERIFY_CERTIFICATE         70
-        KDC_ERR_INVALID_CERTIFICATE             71
-        KDC_ERR_REVOKED_CERTIFICATE             72
-        KDC_ERR_REVOCATION_STATUS_UNKNOWN       73
-        KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74
-        KDC_ERR_CLIENT_NAME_MISMATCH            75
-        KDC_ERR_KDC_NAME_MISMATCH               76
-
-    We utilize the following typed data for errors:
-
-        TD-PKINIT-CMS-CERTIFICATES             101
-        TD-KRB-PRINCIPAL                       102
-        TD-KRB-REALM                           103
-        TD-TRUSTED-CERTIFIERS                  104
-        TD-CERTIFICATE-INDEX                   105
-
-    We utilize the following encryption types (which map directly to
-    OIDs):
-
-        dsaWithSHA1-CmsOID                       9
-        md5WithRSAEncryption-CmsOID             10
-        sha1WithRSAEncryption-CmsOID            11
-        rc2CBC-EnvOID                           12
-        rsaEncryption-EnvOID (PKCS#1 v1.5)      13
-        rsaES-OAEP-ENV-OID   (PKCS#1 v2.0)      14
-        des-ede3-cbc-Env-OID                    15
-
-    These mappings are provided so that a client may send the
-    appropriate enctypes in the AS-REQ message in order to indicate
-    support for the corresponding OIDs (for performing PKINIT).
-
-    In many cases, PKINIT requires the encoding of an X.500 name as a
-    Realm.  In these cases, the realm will be represented using a
-    different style, specified in RFC 1510 with the following example:
-
-        NAMETYPE:rest/of.name=without-restrictions
-
-    For a realm derived from an X.500 name, NAMETYPE will have the value
-    X500-RFC2253.  The full realm name will appear as follows:
-
-        X500-RFC2253:RFC2253Encode(DistinguishedName)
-
-    where DistinguishedName is an X.500 name, and RFC2253Encode is a
-    readable UTF encoding of an X.500 name, as defined by
-    RFC 2253 [14] (part of LDAPv3).
-
-    To ensure that this encoding is unique, we add the following rule
-    to those specified by RFC 2253:
-
-        The order in which the attributes appear in the RFC 2253
-        encoding must be the reverse of the order in the ASN.1
-        encoding of the X.500 name that appears in the public key
-        certificate. The order of the relative distinguished names
-        (RDNs), as well as the order of the AttributeTypeAndValues
-        within each RDN, will be reversed. (This is despite the fact
-        that an RDN is defined as a SET of AttributeTypeAndValues, where
-        an order is normally not important.)
-
-    Similarly, PKINIT may require the encoding of an X.500 name as a
-    PrincipalName.  In these cases, the name-type of the principal name
-    shall be set to KRB_NT-X500-PRINCIPAL.  This new name type is
-    defined as:
-
-        KRB_NT_X500_PRINCIPAL    6
-
-    The name-string shall be set as follows:
-
-        RFC2253Encode(DistinguishedName)
-
-    as described above.
-
-    RFC 1510 specifies the ASN.1 structure for PrincipalName as follows:
-
-        PrincipalName ::=   SEQUENCE {
-                        name-type[0]     INTEGER,
-                        name-string[1]   SEQUENCE OF GeneralString
-        }
-
-    For the purposes of encoding an X.500 name within this structure,
-    the name-string shall be encoded as a single GeneralString.
-
-    Note that name mapping may be required or optional based on
-    policy.
-
-3.1.1.  Encryption and Key Formats
-
-    In the exposition below, we use the terms public key and private
-    key generically.  It should be understood that the term "public
-    key" may be used to refer to either a public encryption key or a
-    signature verification key, and that the term "private key" may be
-    used to refer to either a private decryption key or a signature
-    generation key.  The fact that these are logically distinct does
-    not preclude the assignment of bitwise identical keys.
-
-    In the case of Diffie-Hellman, the key shall be produced from the
-    agreed bit string as follows:
-
-        * Truncate the bit string to the appropriate length.
-        * Rectify parity in each byte (if necessary) to obtain the key.
-
-    For instance, in the case of a DES key, we take the first eight
-    bytes of the bit stream, and then adjust the least significant bit
-    of each byte to ensure that each byte has odd parity.
-
-3.1.2. Algorithm Identifiers
-
-    PKINIT does not define, but does permit, the algorithm identifiers
-    listed below.
-
-3.1.2.1. Signature Algorithm Identifiers
-
-    The following signature algorithm identifiers specified in [11] and
-    in [15] shall be used with PKINIT:
-
-    id-dsa-with-sha1       (DSA with SHA1)
-    md5WithRSAEncryption   (RSA with MD5)
-    sha-1WithRSAEncryption (RSA with SHA1)
-
-3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier
-
-    The following algorithm identifier shall be used within the
-    SubjectPublicKeyInfo data structure: dhpublicnumber
-
-    This identifier and the associated algorithm parameters are
-    specified in RFC 2459 [15].
-
-3.1.2.3. Algorithm Identifiers for RSA Encryption
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure, for encrypting the temporary key with a public key:
-
-        rsaEncryption (RSA encryption, PKCS#1 v1.5)
-        id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0)
-
-    Both of the above RSA encryption schemes are specified in [16].
-    Currently, only PKCS#1 v1.5 is specified by CMS [11], although the
-    CMS specification says that it will likely include PKCS#1 v2.0 in
-    the future.  (PKCS#1 v2.0 addresses adaptive chosen ciphertext
-    vulnerability discovered in PKCS#1 v1.5.)
-
-3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys
-
-    These algorithm identifiers are used inside the EnvelopedData data
-    structure in the PKINIT Reply, for encrypting the reply key with the
-    temporary key:
-        des-ede3-cbc (3-key 3-DES, CBC mode)
-        rc2-cbc      (RC2, CBC mode)
-
-    The full definition of the above algorithm identifiers and their
-    corresponding parameters (an IV for block chaining) is provided in
-    the CMS specification [11].
-
-3.2.  Public Key Authentication
-
-    Implementation of the changes in this section is REQUIRED for
-    compliance with PKINIT.
-
-    It is assumed that all public keys are signed by some certification
-    authority (CA).  The initial authentication request is sent as per
-    RFC 1510, except that a preauthentication field containing data
-    signed by the user's private key accompanies the request:
-
-    PA-PK-AS-REQ ::= SEQUENCE {
-                                -- PA TYPE 14
-        signedAuthPack          [0] SignedData
-                                    -- defined in CMS [11]
-                                    -- AuthPack (below) defines the data
-                                    -- that is signed
-        trustedCertifiers       [1] SEQUENCE OF TrustedCas OPTIONAL,
-                                    -- CAs that the client trusts
-        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL
-                                    -- as defined in CMS [11]
-                                    -- specifies a particular KDC
-                                    -- certificate if the client
-                                    -- already has it;
-                                    -- must be accompanied by
-                                    -- a single trustedCertifier
-        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL
-                                    -- For example, this may be the
-                                    -- client's Diffie-Hellman
-                                    -- certificate, or it may be the
-                                    -- client's RSA encryption
-                                    -- certificate.
-    }
-
-    TrustedCas ::= CHOICE {
-        principalName         [0] KerberosName,
-                                  -- as defined below
-        caName                [1] Name
-                                  -- fully qualified X.500 name
-                                  -- as defined by X.509
-        issuerAndSerial       [2] IssuerAndSerialNumber OPTIONAL
-                                  -- Since a CA may have a number of
-                                  -- certificates, only one of which
-                                  -- a client trusts
-    }
-
-    Usage of SignedData:
-    The SignedData data type is specified in the Cryptographic
-    Message Syntax, a product of the S/MIME working group of the IETF.
-    - The encapContentInfo field must contain the PKAuthenticator
-      and, optionally, the client's Diffie Hellman public value.
-      - The eContentType field shall contain the OID value for
-        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
-        pkcs(1) pkcs7(7) data(1)
-      - The eContent field is data of the type AuthPack (below).
-    - The signerInfos field contains the signature of AuthPack.
-    - The Certificates field, when non-empty, contains the client's
-      certificate chain.  If present, the KDC uses the public key from
-      the client's certificate to verify the signature in the request.
-      Note that the client may pass different certificates that are used
-      for signing or for encrypting.  Thus, the KDC may utilize a
-      different client certificate for signature verification than the
-      one it uses to encrypt the reply to the client.  For example, the
-      client may place a Diffie-Hellman certificate in this field in
-      order to convey its static Diffie Hellman certificate to the KDC
-      enable static-ephemeral Diffie-Hellman mode for the reply.  As
-      another example, the client may place an RSA encryption
-      certificate in this field.
-
-    AuthPack ::= SEQUENCE {
-        pkAuthenticator         [0] PKAuthenticator,
-        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL
-                                    -- if client is using Diffie-Hellman
-    }
-
-    PKAuthenticator ::= SEQUENCE {
-        kdcName                 [0] PrincipalName,
-        kdcRealm                [1] Realm,
-        cusec                   [2] INTEGER,
-                                    -- for replay prevention
-        ctime                   [3] KerberosTime,
-                                    -- for replay prevention
-        nonce                   [4] INTEGER
-    }
-
-    SubjectPublicKeyInfo ::= SEQUENCE {
-        algorithm                   AlgorithmIdentifier,
-                                    -- dhKeyAgreement
-        subjectPublicKey            BIT STRING
-                                    -- for DH, equals
-                                    -- public exponent (INTEGER encoded
-                                    -- as payload of BIT STRING)
-    }   -- as specified by the X.509 recommendation [10]
-
-    AlgorithmIdentifier ::= SEQUENCE {
-        algorithm                   ALGORITHM.&id,
-        parameters                  ALGORITHM.&type
-    }   -- as specified by the X.509 recommendation [10]
-
-    If the client passes an issuer and serial number in the request,
-    the KDC is requested to use the referred-to certificate.  If none
-    exists, then the KDC returns an error of type
-    KDC_ERR_CERTIFICATE_MISMATCH.  It also returns this error if, on the
-    other hand, the client does not pass any trustedCertifiers,
-    believing that it has the KDC's certificate, but the KDC has more
-    than one certificate.  The KDC should include information in the
-    KRB-ERROR message that indicates the KDC certificate(s) that a
-    client may utilize.  This data is specified in the e-data, which
-    is defined in RFC 1510 revisions as a SEQUENCE of TypedData:
-
-    TypedData ::=  SEQUENCE {
-                    data-type      [0] INTEGER,
-                    data-value     [1] OCTET STRING,
-    } -- per Kerberos RFC 1510 revisions
-
-    where:
-    data-type = TD-PKINIT-CMS-CERTIFICATES = 101
-    data-value = CertificateSet // as specified by CMS [11]
-
-    The PKAuthenticator carries information to foil replay attacks,
-    to bind the request and response.  The PKAuthenticator is signed
-    with the private key corresponding to the public key in the
-    certificate found in userCert (or cached by the KDC).
-
-    The trustedCertifiers field contains a list of certification
-    authorities trusted by the client, in the case that the client does
-    not possess the KDC's public key certificate.  If the KDC has no
-    certificate signed by any of the trustedCertifiers, then it returns
-    an error of type KDC_ERR_KDC_NOT_TRUSTED.
-
-    KDCs should try to (in order of preference):
-    1. Use the KDC certificate identified by the serialNumber included
-       in the client's request.
-    2. Use a certificate issued to the KDC by the client's CA (if in the
-       middle of a CA key roll-over, use the KDC cert issued under same
-       CA key as user cert used to verify request).
-    3. Use a certificate issued to the KDC by one of the client's
-       trustedCertifier(s);
-    If the KDC is unable to comply with any of these options, then the
-    KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the
-    client.
-
-    Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication
-    type, the KDC attempts to verify the user's certificate chain
-    (userCert), if one is provided in the request.  This is done by
-    verifying the certification path against the KDC's policy of
-    legitimate certifiers.  This may be based on a certification
-    hierarchy, or it may be simply a list of recognized certifiers in a
-    system like PGP.
-
-    If the client's certificate chain contains no certificate signed by
-    a CA trusted by the KDC, then the KDC sends back an error message
-    of type KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data
-    is a SEQUENCE of one TypedData (with type TD-TRUSTED-CERTIFIERS=104)
-    whose data-value is an OCTET STRING which is the DER encoding of
-
-        TrustedCertifiers ::= SEQUENCE OF PrincipalName
-                              -- X.500 name encoded as a principal name
-                              -- see Section 3.1
-
-    If the signature on one of the certificates in the client's chain
-    fails verification, then the KDC returns an error of type
-    KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data is a SEQUENCE
-    of one TypedData (with type TD-CERTIFICATE-INDEX=105) whose
-    data-value is an OCTET STRING which is the DER encoding of
-
-        CertificateIndex  ::= INTEGER
-                              -- 0 = 1st certificate,
-                              --     (in order of encoding)
-                              -- 1 = 2nd certificate, etc
-
-    The KDC may also check whether any of the certificates in the
-    client's chain has been revoked.  If one of the certificates has
-    been revoked, then the KDC returns an error of type
-    KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that the
-    certificate's revocation status is unknown, the KDC returns an
-    error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN; if the revocation
-    status is unavailable, the KDC returns an error of type
-    KDC_ERR_REVOCATION_STATUS_UNAVAILABLE.  In any of these three
-    cases, the affected certificate is identified by the accompanying
-    e-data, which contains a CertificateIndex as described for
-    KDC_ERR_INVALID_CERTIFICATE.
-
-    If the certificate chain can be verified, but the name of the
-    client in the certificate does not match the client's name in the
-    request, then the KDC returns an error of type
-    KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
-    field in this case.
-
-    Finally, if the certificate chain is verified, but the KDC's name
-    or realm as given in the PKAuthenticator does not match the KDC's
-    actual principal name, then the KDC returns an error of type
-    KDC_ERR_KDC_NAME_MISMATCH.  The accompanying e-data field is again
-    a SEQUENCE of one TypedData (with type TD-KRB-PRINCIPAL=102 or
-    TD-KRB-REALM=103 as appropriate) whose data-value is an OCTET
-    STRING whose data-value is the DER encoding of a PrincipalName or
-    Realm as defined in RFC 1510 revisions.
-
-    Even if all succeeds, the KDC may--for policy reasons--decide not
-    to trust the client.  In this case, the KDC returns an error message
-    of type KDC_ERR_CLIENT_NOT_TRUSTED.
-
-    If a trust relationship exists, the KDC then verifies the client's
-    signature on AuthPack.  If that fails, the KDC returns an error
-    message of type KDC_ERR_INVALID_SIG.  Otherwise, the KDC uses the
-    timestamp (ctime and cusec) in the PKAuthenticator to assure that
-    the request is not a replay.  The KDC also verifies that its name
-    is specified in the PKAuthenticator.
-
-    If the clientPublicValue field is filled in, indicating that the
-    client wishes to use Diffie-Hellman key agreement, then the KDC
-    checks to see that the parameters satisfy its policy.  If they do
-    not (e.g., the prime size is insufficient for the expected
-    encryption type), then the KDC sends back an error message of type
-    KDC_ERR_KEY_TOO_WEAK.  Otherwise, it generates its own public and
-    private values for the response.
-
-    The KDC also checks that the timestamp in the PKAuthenticator is
-    within the allowable window and that the principal name and realm
-    are correct.  If the local (server) time and the client time in the
-    authenticator differ by more than the allowable clock skew, then the
-    KDC returns an error message of type KRB_AP_ERR_SKEW.
-
-    Assuming no errors, the KDC replies as per RFC 1510, except as
-    follows.  The user's name in the ticket is determined by the
-    following decision algorithm:
-
-        1.  If the KDC has a mapping from the name in the certificate
-            to a Kerberos name, then use that name.
-            Else
-        2.  If the certificate contains a Kerberos name in an extension
-            field, and local KDC policy allows, then use that name.
-            Else
-        3.  Use the name as represented in the certificate, mapping
-            as necessary (e.g., as per RFC 2253 for X.500 names).  In
-            this case the realm in the ticket shall be the name of the
-            certification authority that issued the user's certificate.
-
-    The KDC encrypts the reply not with the user's long-term key, but
-    with a random key generated only for this particular response.  This
-    random key is sealed in the preauthentication field:
-
-    PA-PK-AS-REP ::= CHOICE {
-                            -- PA TYPE 15
-        dhSignedData       [0] SignedData,
-                            -- Defined in CMS and used only with
-                            -- Diffie-Helman key exchange
-                            -- This choice MUST be supported
-                            -- by compliant implementations.
-        encKeyPack         [1] EnvelopedData,
-                            -- Defined in CMS
-                            -- The temporary key is encrypted
-                            -- using the client public key
-                            -- key
-                            -- SignedReplyKeyPack, encrypted
-                            -- with the temporary key, is also
-                            -- included.
-    }
-
-    Usage of SignedData:
-    If the Diffie-Hellman option is used, dhSignedData in PA-PK-AS-REP
-    provides authenticated Diffie-Hellman parameters of the KDC.  The
-    reply key used to encrypt part of the KDC reply message is derived
-    from the Diffie-Hellman exchange:
-    - Both the KDC and the client calculate a secret value (g^ab mod p),
-      where a is the client's private exponent and b is the KDC's
-      private exponent.
-    - Both the KDC and the client take the first N bits of this secret
-      value and convert it into a reply key.  N depends on the reply key
-      type.
-    - If the reply key is DES, N=64 bits, where some of the bits are
-      replaced with parity bits, according to FIPS PUB 74.
-    - If the reply key is (3-key) 3-DES, N=192 bits, where some of the
-      bits are replaced with parity bits, according to FIPS PUB 74.
-    - The encapContentInfo field must contain the KdcDHKeyInfo as
-      defined below.
-      - The eContentType field shall contain the OID value for
-        id-data: iso(1) member-body(2) us(840) rsadsi(113549)
-        pkcs(1) pkcs7(7) data(1)
-    - The certificates field must contain the certificates necessary
-      for the client to establish trust in the KDC's certificate
-      based on the list of trusted certifiers sent by the client in
-      the PA-PK-AS-REQ.  This field may be empty if the client did
-      not send to the KDC a list of trusted certifiers (the
-      trustedCertifiers field was empty, meaning that the client
-      already possesses the KDC's certificate).
-    - The signerInfos field is a SET that must contain at least one
-      member, since it contains the actual signature.
-
-    Usage of EnvelopedData:
-    The EnvelopedData data type is specified in the Cryptographic
-    Message Syntax, a product of the S/MIME working group of the IETF.
-    It contains an temporary key encrypted with the PKINIT
-    client's public key.  It also contains a signed and encrypted
-    reply key.
-    - The originatorInfo field is not required, since that information
-      may be presented in the signedData structure that is encrypted
-      within the encryptedContentInfo field.
-    - The optional unprotectedAttrs field is not required for PKINIT.
-    - The recipientInfos field is a SET which must contain exactly one
-      member of the KeyTransRecipientInfo type for encryption
-      with an RSA public key.
-         - The encryptedKey field (in KeyTransRecipientInfo) contains
-           the temporary key which is encrypted with the PKINIT client's
-           public key.
-    - The encryptedContentInfo field contains the signed and encrypted
-      reply key.
-      - The contentType field shall contain the OID value for
-        id-signedData: iso(1) member-body(2) us(840) rsadsi(113549)
-        pkcs(1) pkcs7(7) signedData(2)
-      - The encryptedContent field is encrypted data of the CMS type
-        signedData as specified below.
-        - The encapContentInfo field must contains the ReplyKeyPack.
-          - The eContentType field shall contain the OID value for
-            id-data: iso(1) member-body(2) us(840) rsadsi(113549)
-            pkcs(1) pkcs7(7) data(1)
-          - The eContent field is data of the type ReplyKeyPack (below).
-        - The certificates field must contain the certificates necessary
-          for the client to establish trust in the KDC's certificate
-          based on the list of trusted certifiers sent by the client in
-          the PA-PK-AS-REQ.  This field may be empty if the client did
-          not send to the KDC a list of trusted certifiers (the
-          trustedCertifiers field was empty, meaning that the client
-          already possesses the KDC's certificate).
-        - The signerInfos field is a SET that must contain at least one
-          member, since it contains the actual signature.
-
-    KdcDHKeyInfo ::= SEQUENCE {
-                              -- used only when utilizing Diffie-Hellman
-      nonce                 [0] INTEGER,
-                                -- binds responce to the request
-      subjectPublicKey      [2] BIT STRING
-                                -- Equals public exponent (g^a mod p)
-                                -- INTEGER encoded as payload of
-                                -- BIT STRING
-    }
-
-    ReplyKeyPack ::= SEQUENCE {
-                              -- not used for Diffie-Hellman
-        replyKey             [0] EncryptionKey,
-                                 -- used to encrypt main reply
-                                 -- ENCTYPE is at least as strong as
-                                 -- ENCTYPE of session key
-        nonce                [1] INTEGER,
-                                 -- binds response to the request
-                                 -- must be same as the nonce
-                                 -- passed in the PKAuthenticator
-    }
-
-
-    Since each certifier in the certification path of a user's
-    certificate is essentially a separate realm, the name of each
-    certifier must be added to the transited field of the ticket.  The
-    format of these realm names is defined in Section 3.1 of this
-    document.  If applicable, the transit-policy-checked flag should be
-    set in the issued ticket.
-
-    The KDC's certificate must bind the public key to a name derivable
-    from the name of the realm for that KDC.  X.509 certificates shall
-    contain the principal name of the KDC as the SubjectAltName version
-    3 extension. Below is the definition of this version 3 extension, as
-    specified by the X.509 standard:
-
-        subjectAltName EXTENSION ::= {
-            SYNTAX GeneralNames
-            IDENTIFIED BY id-ce-subjectAltName
-        }
-
-        GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName
-
-        GeneralName ::= CHOICE {
-            otherName       [0] INSTANCE OF OTHER-NAME,
-            ...
-        }
-
-        OTHER-NAME ::= TYPE-IDENTIFIER
-
-    In this definition, otherName is a name of any form defined as an
-    instance of the OTHER-NAME information object class. For the purpose
-    of specifying a Kerberos principal name, INSTANCE OF OTHER-NAME will
-    be chosen and replaced by the type KerberosName:
-
-        KerberosName ::= SEQUENCE {
-          realm           [0] Realm,
-                              -- as define in RFC 1510
-          principalName   [1] PrincipalName,
-                              -- as define in RFC 1510
-        }
-
-    This specific syntax is identified within subjectAltName by setting
-    the OID id-ce-subjectAltName to krb5PrincipalName, where (from the
-    Kerberos specification) we have
-
-        krb5 OBJECT IDENTIFIER ::= { iso (1)
-                                     org (3)
-                                     dod (6)
-                                     internet (1)
-                                     security (5)
-                                     kerberosv5 (2) }
-
-        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }
-
-    This specification may also be used to specify a Kerberos name
-    within the user's certificate.
-
-    If a non-KDC X.509 certificate contains the principal name within
-    the subjectAltName version 3 extension , that name may utilize
-    KerberosName as defined below, or, in the case of an S/MIME
-    certificate [17], may utilize the email address.  If the KDC
-    is presented with as S/MIME certificate, then the email address
-    within subjectAltName will be interpreted as a principal and realm
-    separated by the "@" sign, or as a name that needs to be
-    canonicalized.  If the resulting name does not correspond to a
-    registered principal name, then the principal name is formed as
-    defined in section 3.1.
-
-    The client then extracts the random key used to encrypt the main
-    reply.  This random key (in encPaReply) is encrypted with either the
-    client's public key or with a key derived from the DH values
-    exchanged between the client and the KDC.
-
-3.2.2. Required Algorithms
-
-    Not all of the algorithms in the PKINIT protocol specification have
-    to be implemented in order to comply with the proposed standard.
-    Below is a list of the required algorithms:
-
-    - Diffie-Hellman public/private key pairs
-      - utilizing Diffie-Hellman ephemeral-ephemeral mode
-    - SHA1 digest and DSA for signatures
-    - 3-key triple DES keys derived from the Diffie-Hellman Exchange
-    - 3-key triple DES Temporary and Reply keys
-
-4.  Logistics and Policy
-
-    This section describes a way to define the policy on the use of
-    PKINIT for each principal and request.
-
-    The KDC is not required to contain a database record for users
-    who use public key authentication.  However, if these users are
-    registered with the KDC, it is recommended that the database record
-    for these users be modified to an additional flag in the attributes
-    field to indicate that the user should authenticate using PKINIT.
-    If this flag is set and a request message does not contain the
-    PKINIT preauthentication field, then the KDC sends back as error of
-    type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication
-    field of type PA-PK-AS-REQ must be included in the request.
-
-5.  Security Considerations
-
-    PKINIT raises a few security considerations, which we will address
-    in this section.
-
-    First of all, PKINIT introduces a new trust model, where KDCs do not
-    (necessarily) certify the identity of those for whom they issue
-    tickets.  PKINIT does allow KDCs to act as their own CAs, in order
-    to simplify key management, but one of the additional benefits is to
-    align Kerberos authentication with a global public key
-    infrastructure.  Anyone using PKINIT in this way must be aware of
-    how the certification infrastructure they are linking to works.
-
-    Secondly, PKINIT also introduces the possibility of interactions
-    between different cryptosystems, which may be of widely varying
-    strengths.  Many systems, for instance, allow the use of 512-bit
-    public keys.  Using such keys to wrap data encrypted under strong
-    conventional cryptosystems, such as triple-DES, is inappropriate;
-    it adds a weak link to a strong one at extra cost.  Implementors
-    and administrators should take care to avoid such wasteful and
-    deceptive interactions.
-
-    Lastly, PKINIT calls for randomly generated keys for conventional
-    cryptosystems.  Many such systems contain systematically "weak"
-    keys.  PKINIT implementations MUST avoid use of these keys, either
-    by discarding those keys when they are generated, or by fixing them
-    in some way (e.g., by XORing them with a given mask).  These
-    precautions vary from system to system; it is not our intention to
-    give an explicit recipe for them here.
-
-6.  Transport Issues
-
-    Certificate chains can potentially grow quite large and span several
-    UDP packets; this in turn increases the probability that a Kerberos
-    message involving PKINIT extensions will be broken in transit.  In
-    light of the possibility that the Kerberos specification will
-    require KDCs to accept requests using TCP as a transport mechanism,
-    we make the same recommendation with respect to the PKINIT
-    extensions as well.
-
-7.  Bibliography
-
-    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-    (V5).  Request for Comments 1510.
-
-    [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
-    for Computer Networks, IEEE Communications, 32(9):33-38.  September
-    1994.
-
-    [3] B. Tung, T. Ryutov, C. Neuman, G. Tsudik, B. Sommerfeld,
-    A. Medvinsky, M. Hur.  Public Key Cryptography for Cross-Realm
-    Authentication in Kerberos.
-    draft-ietf-cat-kerberos-pk-cross-04.txt
-
-    [4] A. Medvinsky, J. Cargille, M. Hur.  Anonymous Credentials in
-    Kerberos.
-    draft-ietf-cat-kerberos-anoncred-00.txt
-
-    [5] A. Medvinsky, M. Hur, B. Clifford Neuman.  Public Key Utilizing
-    Tickets for Application Servers (PKTAPP).
-    draft-ietf-cat-pktapp-00.txt
-
-    [6] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos
-    Using Public Key Cryptography.  Symposium On Network and Distributed
-    System Security, 1997.
-
-    [7] B. Cox, J.D. Tygar, M. Sirbu.  NetBill Security and Transaction
-    Protocol.  In Proceedings of the USENIX Workshop on Electronic
-    Commerce, July 1995.
-
-    [8] T. Dierks, C. Allen.  The TLS Protocol, Version 1.0
-    Request for Comments 2246, January 1999.
-
-    [9] B.C. Neuman, Proxy-Based Authorization and Accounting for
-    Distributed Systems.  In Proceedings of the 13th International
-    Conference on Distributed Computing Systems, May 1993.
-
-    [10] ITU-T (formerly CCITT) Information technology - Open Systems
-    Interconnection - The Directory: Authentication Framework
-    Recommendation X.509 ISO/IEC 9594-8
-
-    [11] R. Housley. Cryptographic Message Syntax.
-    draft-ietf-smime-cms-13.txt, April 1999.
-
-    [12] PKCS #7: Cryptographic Message Syntax Standard,
-    An RSA Laboratories Technical Note Version 1.5
-    Revised November 1, 1993
-
-    [13] R. Rivest, MIT Laboratory for Computer Science and RSA Data
-    Security, Inc. A Description of the RC2(r) Encryption Algorithm
-    March 1998.
-    Request for Comments 2268.
-
-    [14] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access
-    Protocol (v3): UTF-8 String Representation of Distinguished Names.
-    Request for Comments 2253.
-
-    [15] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public
-    Key Infrastructure, Certificate and CRL Profile, January 1999.
-    Request for Comments 2459.
-
-    [16] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography
-    Specifications, October 1998.
-    Request for Comments 2437.
-
-    [17] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein.
-    S/MIME Version 2 Certificate Handling, March 1998.
-    Request for Comments 2312
-
-8.  Acknowledgements
-
-    Some of the ideas on which this proposal is based arose during
-    discussions over several years between members of the SAAG, the IETF
-    CAT working group, and the PSRG, regarding integration of Kerberos
-    and SPX.  Some ideas have also been drawn from the DASS system.
-    These changes are by no means endorsed by these groups.  This is an
-    attempt to revive some of the goals of those groups, and this
-    proposal approaches those goals primarily from the Kerberos
-    perspective.  Lastly, comments from groups working on similar ideas
-    in DCE have been invaluable.
-
-9.  Expiration Date
-
-    This draft expires December 1, 1999.
-
-10. Authors
-
-    Brian Tung
-    Clifford Neuman
-    USC Information Sciences Institute
-    4676 Admiralty Way Suite 1001
-    Marina del Rey CA 90292-6695
-    Phone: +1 310 822 1511
-    E-mail: {brian, bcn}@isi.edu
-
-    Matthew Hur
-    CyberSafe Corporation
-    1605 NW Sammamish Road
-    Issaquah WA 98027-5378
-    Phone: +1 425 391 6000
-    E-mail: matt.hur@cybersafe.com
-
-    Ari Medvinsky
-    Excite
-    555 Broadway
-    Redwood City, CA 94063
-    Phone +1 650 569 2119
-    E-mail: amedvins@excitecorp.com
-
-    Sasha Medvinsky
-    General Instrument
-    6450 Sequence Drive
-    San Diego, CA 92121
-    Phone +1 619 404 2825
-    E-mail: smedvinsky@gi.com
-
-    John Wray
-    Iris Associates, Inc.
-    5 Technology Park Dr.
-    Westford, MA 01886
-    E-mail: John_Wray@iris.com
-
-    Jonathan Trostle
-    170 W. Tasman Dr.
-    San Jose, CA 95134
-    E-mail: jtrostle@cisco.com
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt b/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt
deleted file mode 100644
index 6581dd581..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-pk-tapp-03.txt
+++ /dev/null
@@ -1,378 +0,0 @@
-INTERNET-DRAFT                                    Ari Medvinsky
-draft-ietf-cat-kerberos-pk-tapp-03.txt            Keen.com, Inc.
-Expires January 14, 2001                          Matthew Hur
-Informational					  CyberSafe Corporation
-						  Sasha Medvinsky
-						  Motorola
-                                                  Clifford Neuman
-                                                  USC/ISI
-
-Public Key Utilizing Tickets for Application Servers (PKTAPP)
-
-
-0. Status Of this Memo
-
-This document is an Internet-Draft and is in full conformance with
-all provisions of Section 10 of RFC 2026.  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."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-To learn the current status of any Internet-Draft, please check
-the "1id-abstracts.txt" listing contained in the Internet-Drafts
-Shadow Directories on ftp.ietf.org (US East Coast),
-nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
-munnari.oz.au (Pacific Rim).
-
-The distribution of this memo is unlimited.  It is filed as
-draft-ietf-cat-kerberos-pk-init-10.txt, and expires April 30,
-2000.  Please send comments to the authors.
-
-1. Abstract
-
-Public key based Kerberos for Distributed Authentication[1], (PKDA) 
-proposed by Sirbu & Chuang, describes PK based authentication that 
-eliminates the use of a centralized key distribution center while 
-retaining the advantages of Kerberos tickets.  This draft describes how, 
-without any modification, the PKINIT specification[2] may be used to 
-implement the ideas introduced in PKDA.  The benefit is that only a 
-single PK Kerberos extension is needed to address the goals of PKINIT & 
-PKDA.
-
-
-
-2. Introduction
-
-With the proliferation of public key cryptography, a number of public 
-key extensions to Kerberos have been proposed to provide 
-interoperability with the PK infrastructure and to improve the Kerberos 
-authentication system [4].  Among these are PKINIT[2] (under development
-in the CAT working group) and more recently PKDA [1] proposed by Sirbu & 
-Chuang of CMU.  One of the principal goals of PKINIT is to provide for 
-interoperability between a PK infrastructure and Kerberos.  Using 
-PKINIT, a user can authenticate to the KDC via a public key certificate.  
-A ticket granting ticket (TGT), returned by the KDC, enables a PK user 
-to obtain tickets and authenticate to kerberized services.  The PKDA 
-proposal goes a step further.  It supports direct client to server 
-authentication, eliminating the need for an online key distribution 
-center.  In this draft, we describe how, without any modification, the 
-PKINIT protocol may be applied to achieve the goals of PKDA. For direct 
-client to server authentication, the client will use PKINIT to 
-authenticate to the end server (instead of a central KDC), which then, 
-will issue a ticket for itself.  The benefit of this proposal, is that a 
-single PK extension to Kerberos can addresses the goals of PKINIT and 
-PKDA.
-
-
-3. PKDA background
-
-The PKDA proposal provides direct client to server authentication, thus 
-eliminating the need for an online key distribution center.  A client 
-and server take part in an initial PK based authentication exchange, 
-with an added caveat that the server acts as a Kerberos ticket granting 
-service and issues a traditional Kerberos ticket for itself.  In 
-subsequent communication, the client makes use of the Kerberos ticket, 
-thus eliminating the need for public key operations on the server.  This 
-approach has an advantage over SSL in that the server does not need to 
-save state (cache session keys).  Furthermore, an additional benefit, is 
-that Kerberos tickets can facilitate delegation (see Neuman[3]). 
-
-Below is a brief overview of the PKDA protocol.  For a more detailed 
-description see [1]. 
-
-SCERT_REQ: Client to Server
-The client requests a certificate from the server.  If the serverÆs 
-certificate is cached locally, SCERT_REQ and SCERT_REP are omitted.
-
-SCERT_REP:  Server to Client
-The server returns its certificate to the client.
-
-PKTGS_REQ: Client to Server
-The client sends a request for a service ticket to the server.  To 
-authenticate the request, the client signs, among other fields, a time 
-stamp and a newly generated symmetric key .  The time stamp is used to 
-foil replay attacks;  the symmetric key is used by the server to secure 
-the PKTGS_REP message. 
-The client provides a certificate in the request (the certificate 
-enables the server to verify the validity of the clientÆs signature) and 
-seals it along with the signed information using the serverÆs public 
-key.  
-
- 
-PKTGS_REP:  Server to Client
-The server returns a service ticket (which it issued for itself) along 
-with the session key for the ticket.  The session key is protected by 
-the client-generated key from the PKTGS_REQ message.  
-
-AP_REQ:  Client to Server
-After the above exchange, the client can proceed in a normal fashion, 
-using the conventional Kerberos ticket in an AP_REQ message.
-
-
-4. PKINIT background
-
-One of the principal goals of PKINIT is to provide for interoperability 
-between a public key infrastructure and Kerberos.  Using a public key 
-certificate, a client can authenticate to the KDC and receive a TGT 
-which enables the client to obtain service tickets to kerberized 
-services..  In PKINIT, the AS-REQ and AS-REP messages remain the same; 
-new preauthentication data types are used to conduct the PK exchange.  
-Client and server certificates are exchanged via the preauthentication 
-data.  Thus, the exchange of certificates , PK authentication, and 
-delivery of a TGT can occur in two messages.
-
-Below is a brief overview of the PKINIT protocol.  For a more detailed 
-description see [2]. 
-
-PreAuthentication data of AS-REQ:  Client to Server
-The client sends a list of trusted certifiers, a signed PK 
-authenticator, and its certificate.  The PK authenticator, based on the 
-Kerberos authenticator, contains the name of the KDC, a timestamp, and a 
-nonce.
-
-PreAuthentication data of AS-REP:  Server to Client
-The server responds with its certificate and the key used for decrypting 
-the encrypted part of the AS-REQ.  This key is encrypted with the 
-clientÆs public key.
-
-AP_REQ:  Client to Server
-After the above exchange, the client can proceed in a normal fashion, 
-using the conventional Kerberos ticket in an AP_REQ message.
-
-
-5. Application of PKINIT to achieve equivalence to PKDA
-
-While PKINIT is normally used to retrieve a ticket granting ticket 
-(TGT), it may also be used to request an end service ticket.  When used 
-in this fashion, PKINIT is functionally equivalent to PKDA.  We 
-introduce the concept of a local ticket granting server (LTGS) to 
-illustrate how PKINIT may be used for issuing end service tickets based 
-on public key authentication.  It is important to note that the LTGS may 
-be built into an application server, or it may be a stand-alone server 
-used for issuing tickets within a well-defined realm, such as a single 
-machine.  We will discuss both of these options.
-
-
-5.1. The LTGS
-
-The LTGS processes the Kerberos AS-REQ and AS-REP messages with PKINIT 
-preauthentication data.  When a client submits an AS-REQ to the LTGS, it
-specifies an application server, in order to receive an end service 
-ticket instead of a TGT.
-
-
-5.1.1. The LTGS as a standalone server
-
-The LTGS may run as a separate process that serves applications which 
-reside on the same machine. This serves to consolidate administrative 
-functions and provide an easier migration path for a heterogeneous 
-environment consisting of both public key and Kerberos.  The LTGS would 
-use one well-known port (port #88 - same as the KDC) for all message 
-traffic and would share a symmetric with each service.  After the client 
-receives a service ticket, it then contacts the application server 
-directly.  This approach is similar to the one suggested by Sirbu , et 
-al [1].
-
-5.1.1.1. Ticket Policy for PKTAPP Clients
-
-It is desirable for the LTGS to have access to a PKTAPP client ticket
-policy. This policy will contain information for each client, such as 
-the maximum lifetime of a ticket, whether or not a ticket can be 
-forwardable, etc. PKTAPP clients, however, use the PKINIT protocol for
-authentication and are not required to be registered as Kerberos 
-principals.
-
-As one possible solution, each public key Certification Authority could
-be registered in a secure database, along with the ticket policy 
-information for all PKTAPP clients that are certified by this
-Certification Authority.
-
-5.1.1.2. LTGS as a Kerberos Principal
-
-Since the LTGS serves only PKTAPP clients and returns only end service
-tickets for other services, it does not require a Kerberos service key 
-or a Kerberos principal identity. It is therefore not necessary for the
-LTGS to even be registered as a Kerberos principal.
-
-The LTGS still requires public key credentials for the PKINIT exchange,
-and it may be desired to have some global restrictions on the Kerberos
-tickets that it can issue. It is recommended (but not required) that
-this information be associated with a Kerberos principal entry for the
-LTGS.
-
-
-5.1.1.3. Kerberos Principal Database
-
-Since the LTGS issues tickets for Kerberos services, it will require
-access to a Kerberos principal database containing entries for at least
-the end services. Each entry must contain a service key and may also
-contain restrictions on the service tickets that are issued to clients.
-It is recommended that (for ease of administration) this principal
-database be centrally administered and distributed (replicated) to all
-hosts where an LTGS may be running.
-
-In the case that there are other clients that do not support PKINIT
-protocol, but still need access to the same Kerberos services, this
-principal database will also require entries for Kerberos clients and
-for the TGS entries.
-
-5.1.2. The LTGS as part of an application server
-
-The LTGS may be combined with an application server.  This accomplishes 
-direct client to application server authentication; however, it requires 
-that applications be modified to process AS-REQ and AS-REP messages.  
-The LTGS would communicate over the port assigned to the application 
-server or over the well known Kerberos port for that particular 
-application.
-
-5.1.2.2. Ticket Policy for PKTAPP Clients
-
-Application servers normally do not have access to a distributed 
-principal database. Therefore, they will have to find another means of
-keeping track of the ticket policy information for PKTAPP clients. It is
-recommended that this ticket policy be kept in a directory service (such
-as LDAP).  
-
-It is critical, however, that both read and write access to this ticket
-policy is restricted with strong authentication and encryption to only
-the correct application server.  An unauthorized party should not have
-the authority to modify the ticket policy. Disclosing the ticket policy
-to a 3rd party may aid an adversary in determining the best way to
-compromise the network.
-
-It is just as critical for the application server to authenticate the
-directory service. Otherwise an adversary could use a man-in-the-middle
-attack to substitute a false ticket policy with a false directory
-service.
-
-5.1.2.3. LTGS Credentials
-
-Each LTGS (combined with an application service) will require public key
-credentials in order to use the PKINIT protocol. These credentials can 
-be stored in a single file that is both encrypted with a password-
-derived symmetric key and also secured by an operating system. This
-symmetric key may be stashed somewhere on the machine for convenience,
-although such practice potentially weakens the overall system security
-and is strongly discouraged.
-
-For added security, it is recommended that the LTGS private keys are
-stored inside a temper-resistant hardware module that requires a pin
-code for access.
-
-
-5.1.2.4. Compatibility With Standard Kerberos
-
-Even though an application server is combined with the LTGS, for
-backward compatibility it should still accept service tickets that have
-been issued by the KDC. This will allow Kerberos clients that do not
-support PKTAPP to authenticate to the same application server (with the
-help of a KDC).
-
-5.1.3. Cross-Realm Authentication
-
-According to the PKINIT draft, the client's realm is the X.500 name of
-the Certification Authority that issued the client certificate. A 
-Kerberos application service will be in a standard Kerberos realm, which
-implies that the LTGS will need to issue cross-realm end service 
-tickets. This is the only case, where cross-realm end service tickets
-are issued. In a standard Kerberos model, a client first acquires a
-cross-realm TGT, and then gets an end service ticket from the KDC that
-is in the same realm as the application service.
-
-6. Protocol differences between PKINIT and PKDA
-
-Both PKINIT and PKDA will accomplish the same goal of issuing end 
-service tickets, based on initial public key authentication.  A PKINIT-
-based implementation and a PKDA implementation would be functionally 
-equivalent.  The primary differences are that 1)PKDA requires the client 
-to create the symmetric key while PKINIT requires the server to create 
-the key and 2)PKINIT accomplishes in two messages what PKDA accomplishes 
-in four messages.
-
-7. Summary
-
-The PKINIT protocol can be used, without modification to facilitate 
-client to server authentication without the use of a central KDC.  The 
-approach described in this draft  (and originally proposed in PKDA[1]) 
-is essentially a public key authentication protocol that retains the 
-advantages of Kerberos tickets.
-
-Given that PKINIT has progressed through the CAT working group of the 
-IETF, with plans for non-commercial distribution (via MITÆs v5 Kerberos)  
-as well as commercial support, it is worthwhile to provide PKDA 
-functionality, under the PKINIT umbrella.
-
-8. Security Considerations
-
-PKTAPP is based on the PKINIT protocol and all security considerations
-already listed in [2] apply here.
-
-When the LTGS is implemented as part of each application server, the
-secure storage of its public key credentials and of its ticket policy
-are both a concern.  The respective security considerations are already
-covered in sections 5.1.2.3 and 5.1.2.2 of this document.  
-
-
-9. Bibliography
-
-[1] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos Using 
-Public Key Cryptography.  Symposium On Network and Distributed System 
-Security, 1997.
-
-[2] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
-J. Trostle.  Public Key Cryptography for Initial Authentication in
-Kerberos.  Internet Draft, October 1999. 
-(ftp://ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-10.txt)
-
-[3] C. Neuman, Proxy-Based Authorization and Accounting for 
-Distributed Systems.  In Proceedings of the 13th International 
-Conference on Distributed Computing Systems, May 1993.
-
-[4] J. Kohl, C. Neuman.  The Kerberos Network Authentication Service
-(V5).  Request for Comments 1510.
-
-10.  Expiration Date
-
-This draft expires April 24, 2000.
-
-11. Authors
-
-Ari Medvinsky
-Keen.com, Inc.
-150 Independence Dr.
-Menlo Park, CA 94025
-Phone +1 650 289 3134
-E-mail: ari@keen.com
-
-Matthew Hur
-CyberSafe Corporation
-1605 NW Sammamish Road
-Issaquah, WA 98027-5378
-Phone: +1 425 391 6000
-E-mail: matt.hur@cybersafe.com
-
-Alexander Medvinsky
-Motorola
-6450 Sequence Dr.
-San Diego, CA 92121
-Phone: +1 858 404 2367
-E-mail: smedvinsky@gi.com
-
-Clifford Neuman
-USC Information Sciences Institute
-4676 Admiralty Way Suite 1001
-Marina del Rey CA 90292-6695
-Phone: +1 310 822 1511
-E-mail: bcn@isi.edu
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt b/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt
deleted file mode 100644
index 2284c3c6b..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-revisions-00.txt
+++ /dev/null
@@ -1,8277 +0,0 @@
-
-INTERNET-DRAFT                               Clifford Neuman
-                                                   John Kohl
-                                               Theodore Ts'o
-                                                11 July 1997
-
-
-
-     The Kerberos  Network Authentication Service (V5)
-
-
-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 learn the  current  status  of  any  Internet-Draft,
-please  check  the  "1id-abstracts.txt" listing contained in
-the Internet-Drafts Shadow  Directories  on  ds.internic.net
-(US  East  Coast),  nic.nordu.net  (Europe), ftp.isi.edu (US
-West Coast), or munnari.oz.au (Pacific Rim).
-
-     The distribution of this  memo  is  unlimited.   It  is
-filed  as  draft-ietf-cat-kerberos-revisions-00.txt,  and expires 
-11 January 1998.  Please send comments to:
-
-   krb-protocol@MIT.EDU
-
-ABSTRACT
-
-
-     This document provides an overview and specification of
-Version  5  of the Kerberos protocol, and updates RFC1510 to
-clarify aspects of the protocol and its  intended  use  that
-require  more  detailed or clearer explanation than was pro-
-vided in RFC1510.  This document is intended  to  provide  a
-detailed description of the protocol, suitable for implemen-
-tation, together with descriptions of the appropriate use of
-protocol messages and fields within those messages.
-
-     This document is not intended to describe  Kerberos  to
-__________________________
-Project Athena, Athena, and Kerberos are trademarks  of
-the  Massachusetts  Institute  of Technology (MIT).  No
-commercial use of these trademarks may be made  without
-prior written permission of MIT.
-
-
-
-Overview                   - 1 -     Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-the  end  user,   system   administrator,   or   application
-developer.   Higher level papers describing Version 5 of the
-Kerberos system [1] and documenting  version  4   [23],  are
-available elsewhere.
-
-OVERVIEW
-
-     This INTERNET-DRAFT describes the  concepts  and  model
-upon  which  the  Kerberos  network authentication system is
-based.  It also specifies Version 5 of the  Kerberos  proto-
-col.
-
-     The  motivations,  goals,  assumptions,  and  rationale
-behind most design decisions are treated cursorily; they are
-more fully described in a paper available in IEEE communica-
-tions  [1] and earlier in the Kerberos portion of the Athena
-Technical Plan [2].  The  protocols  have  been  a  proposed
-standard  and are being considered for advancement for draft
-standard through the IETF standard  process.   Comments  are
-encouraged  on  the presentation, but only minor refinements
-to the protocol as implemented or extensions that fit within
-current protocol framework will be considered at this time.
-
-     Requests for addition to an electronic mailing list for
-discussion  of  Kerberos, kerberos@MIT.EDU, may be addressed
-to kerberos-request@MIT.EDU.  This mailing list is gatewayed
-onto   the  Usenet  as  the  group  comp.protocols.kerberos.
-Requests for further information,  including  documents  and
-code availability, may be sent to info-kerberos@MIT.EDU.
-
-BACKGROUND
-
-     The Kerberos model is based  in  part  on  Needham  and
-Schroeder's  trusted third-party authentication protocol [4]
-and on modifications suggested by  Denning  and  Sacco  [5].
-The  original design and implementation of Kerberos Versions
-1 through 4 was the work of two former Project Athena  staff
-members,  Steve  Miller of Digital Equipment Corporation and
-Clifford Neuman (now at the Information  Sciences  Institute
-of the University of Southern California), along with Jerome
-Saltzer, Technical Director of Project Athena,  and  Jeffrey
-Schiller, MIT Campus Network Manager.  Many other members of
-Project Athena have also contributed to  the  work  on  Ker-
-beros.
-
-     Version 5 of the Kerberos protocol (described  in  this
-document)  has  evolved from Version 4 based on new require-
-ments and desires for features not available in  Version  4.
-The  design of Version 5 of the Kerberos protocol was led by
-Clifford Neuman and John Kohl with much input from the  com-
-munity.  The development of the MIT reference implementation
-was led at MIT by John Kohl and Theodore T'so, with help and
-contributed  code  from  many others.  Reference implementa-
-tions of both version 4 and version 5 of Kerberos  are  pub-
-licly  available  and  commercial  implementations have been
-
-Overview                   - 2 -     Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-developed and are widely used.
-
-     Details on the differences between Kerberos Versions  4
-and 5 can be found in [6].
-
-1.  Introduction
-
-     Kerberos provides a means of verifying  the  identities
-of principals, (e.g. a workstation user or a network server)
-on an open  (unprotected)  network.   This  is  accomplished
-without  relying on assertions by the host operating system,
-without basing trust on host  addresses,  without  requiring
-physical security of all the hosts on the network, and under
-the assumption that packets traveling along the network  can
-be read, modified, and inserted at will[1].   Kerberos  per-
-forms  authentication  under  these  conditions as a trusted
-third-party authentication  service  by  using  conventional
-(shared secret key[2])  cryptography.   Kerberos  extensions
-have  been proposed and implemented that provide for the use
-of public key cryptography  during  certain  phases  of  the
-authentication   protocol.   These  extensions  provide  for
-authentication of users registered with public key  certifi-
-cation  authorities, and allow the system to provide certain
-benefits of public key cryptography in situations where they
-are needed.
-
-     The basic Kerberos authentication process  proceeds  as
-follows:  A  client  sends  a  request to the authentication
-server (AS) requesting "credentials"  for  a  given  server.
-The  AS  responds  with  these credentials, encrypted in the
-client's key.  The credentials consist of 1) a "ticket"  for
-the server and 2) a temporary encryption key (often called a
-"session key").  The client transmits the ticket (which con-
-tains  the  client's identity and a copy of the session key,
-all encrypted in the server's key) to the server.  The  ses-
-sion  key  (now  shared by the client and server) is used to
-authenticate the client,  and  may  optionally  be  used  to
-__________________________
-[1] Note, however, that many applications use Kerberos'
-functions  only  upon  the initiation of a stream-based
-network connection.  Unless an application subsequently
-provides  integrity protection for the data stream, the
-identity verification applies only to the initiation of
-the  connection, and does not guarantee that subsequent
-messages on the  connection  originate  from  the  same
-principal.
-[2] Secret  and  private are often used interchangeably
-in the literature.  In our  usage,  it  takes  two  (or
-more)  to  share  a  secret, thus a shared DES key is a
-secret key.  Something is only private when no one  but
-its owner knows it.  Thus, in public key cryptosystems,
-one has a public and a private key.
-
-
-
-Section 1.                 - 3 -     Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-authenticate the server.  It may also  be  used  to  encrypt
-further communication between the two parties or to exchange
-a separate sub-session key to be  used  to  encrypt  further
-communication.
-
-     Implementation of the basic protocol consists of one or
-more  authentication  servers  running  on physically secure
-hosts.  The authentication servers maintain  a  database  of
-principals  (i.e., users and servers) and their secret keys.
-Code libraries provide encryption and implement the Kerberos
-protocol.   In  order  to add authentication to its transac-
-tions, a typical network application adds one or  two  calls
-to  the  Kerberos  library  directly  or through the Generic
-Security Services Application Programming Interface, GSSAPI,
-described  in  separate document.  These calls result in the
-transmission of the necessary messages to achieve  authenti-
-cation.
-
-     The Kerberos protocol consists of several sub-protocols
-(or  exchanges).   There  are  two  basic methods by which a
-client can ask a Kerberos server for  credentials.   In  the
-first  approach,  the client sends a cleartext request for a
-ticket for the desired server to the AS.  The reply is  sent
-encrypted  in the client's secret key.  Usually this request
-is for a ticket-granting ticket (TGT)  which  can  later  be
-used  with  the ticket-granting server (TGS).  In the second
-method, the client sends a request to the TGS.   The  client
-uses  the  TGT to authenticate itself to the TGS in the same
-manner as if it were contacting any other application server
-that   requires   Kerberos  authentication.   The  reply  is
-encrypted in the session key from the TGT.  Though the  pro-
-tocol specification describes the AS and the TGS as separate
-servers, they are implemented in practice as different  pro-
-tocol entry points within a single Kerberos server.
-
-     Once obtained, credentials may be used  to  verify  the
-identity  of  the principals in a transaction, to ensure the
-integrity of messages exchanged between them, or to preserve
-privacy  of the messages.  The application is free to choose
-whatever protection may be necessary.
-
-     To verify the identities of the principals in  a  tran-
-saction,  the client transmits the ticket to the application
-server.  Since the ticket is sent "in the clear"  (parts  of
-it are encrypted, but this encryption doesn't thwart replay)
-and might be intercepted and reused by  an  attacker,  addi-
-tional  information  is  sent to prove that the message ori-
-ginated with the principal to whom the  ticket  was  issued.
-This  information (called the authenticator) is encrypted in
-the session key, and includes a  timestamp.   The  timestamp
-proves  that the message was recently generated and is not a
-replay.  Encrypting the authenticator  in  the  session  key
-proves  that it was generated by a party possessing the ses-
-sion key.  Since no one except the requesting principal  and
-
-
-Section 1.                 - 4 -     Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-the  server  know the session key (it is never sent over the
-network in the clear) this guarantees the  identity  of  the
-client.
-
-     The integrity of the messages exchanged between princi-
-pals can also be guaranteed using the session key (passed in
-the ticket and contained in the credentials).  This approach
-provides detection of both replay attacks and message stream
-modification attacks.  It is accomplished by generating  and
-transmitting  a collision-proof checksum (elsewhere called a
-hash or digest function) of the client's message, keyed with
-the  session  key.   Privacy  and  integrity of the messages
-exchanged between principals can be  secured  by  encrypting
-the data to be passed using the session key contained in the
-ticket or the subsession key found in the authenticator.
-
-     The authentication exchanges  mentioned  above  require
-read-only  access to the Kerberos database.  Sometimes, how-
-ever, the entries in the database must be modified, such  as
-when  adding  new  principals or changing a principal's key.
-This is done using a protocol between a client and  a  third
-Kerberos  server, the Kerberos Administration Server (KADM).
-There is also a protocol for maintaining multiple copies  of
-the  Kerberos  database.   Neither  of  these  protocols are
-described in this document.
-
-1.1.  Cross-Realm Operation
-
-     The Kerberos protocol is  designed  to  operate  across
-organizational boundaries.  A client in one organization can
-be authenticated to a server in another.  Each  organization
-wishing  to  run  a  Kerberos  server  establishes  its  own
-"realm".  The name  of  the  realm  in  which  a  client  is
-registered  is part of the client's name, and can be used by
-the end-service to decide whether to honor a request.
-
-     By establishing "inter-realm" keys, the  administrators
-of  two realms can allow a client authenticated in the local
-realm to prove its identity to servers in  other  realms[3].
-The exchange of inter-realm keys (a separate key may be used
-for each direction) registers the ticket-granting service of
-each  realm  as a principal in the other realm.  A client is
-then able to obtain a ticket-granting ticket for the  remote
-realm's  ticket-granting service from its local realm.  When
-that ticket-granting ticket  is  used,  the  remote  ticket-
-granting  service  uses  the  inter-realm key (which usually
-__________________________
-[3] Of course, with appropriate permission  the  client
-could  arrange registration of a separately-named prin-
-cipal in a remote realm, and engage in normal exchanges
-with  that  realm's  services.  However, for even small
-numbers of clients this becomes  cumbersome,  and  more
-automatic methods as described here are necessary.
-
-
-Section 1.1.               - 5 -     Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-differs from its own normal TGS key) to decrypt the  ticket-
-granting  ticket,  and is thus certain that it was issued by
-the client's own TGS.  Tickets issued by the remote  ticket-
-granting  service  will indicate to the end-service that the
-client was authenticated from another realm.
-
-     A realm is said to communicate with  another  realm  if
-the  two  realms  share  an inter-realm key, or if the local
-realm shares an inter-realm key with an  intermediate  realm
-that  communicates with the remote realm.  An authentication
-path is the sequence of intermediate realms that  are  tran-
-sited in communicating from one realm to another.
-
-     Realms are typically  organized  hierarchically.   Each
-realm  shares a key with its parent and a different key with
-each child.  If an inter-realm key is not directly shared by
-two  realms, the hierarchical organization allows an authen-
-tication path to be easily constructed.  If  a  hierarchical
-organization  is  not used, it may be necessary to consult a
-database  in  order  to  construct  an  authentication  path
-between realms.
-
-     Although realms are typically hierarchical,  intermedi-
-ate  realms may be bypassed to achieve cross-realm authenti-
-cation through alternate authentication paths  (these  might
-be established to make communication between two realms more
-efficient).  It is important for  the  end-service  to  know
-which  realms were transited when deciding how much faith to
-place in the authentication  process.   To  facilitate  this
-decision,  a  field in each ticket contains the names of the
-realms that were involved in authenticating the client.
-
-1.2.  Authorization
-
-As an authentication service, Kerberos provides a  means  of
-verifying  the identity of principals on a network.  Authen-
-tication is usually useful primarily as a first step in  the
-process  of  authorization, determining whether a client may
-use a service,  which  objects  the  client  is  allowed  to
-access,  and  the type of access allowed for each.  Kerberos
-does not, by itself, provide authorization.  Possession of a
-client ticket for a service provides only for authentication
-of the client to that service,  and  in  the  absence  of  a
-separate  authorization  procedure,  it  should  not be con-
-sidered by an application as authorizing  the  use  of  that
-service.
-
-     Such separate authorization methods may be  implemented
-as  application specific access control functions and may be
-based on  files  such  as  the  application  server,  or  on
-separately  issued  authorization  credentials such as those
-based on proxies [7] , or on other authorization services.
-
-     Applications should  not  be  modified  to  accept  the
-issuance of a service ticket by the Kerberos server (even by
-
-Section 1.2.               - 6 -     Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-an modified Kerberos server) as granting  authority  to  use
-the  service,  since such applications may become vulnerable
-to the bypass of this authorization check in an  environment
-where  they  interoperate  with  other  KDCs  or where other
-options for application authentication (e.g. the PKTAPP pro-
-posal) are provided.
-
-1.3.  Environmental assumptions
-
-Kerberos imposes a few assumptions  on  the  environment  in
-which it can properly function:
-
-+    "Denial of service" attacks are not  solved  with  Ker-
-     beros.   There  are  places in these protocols where an
-     intruder can prevent an application from  participating
-     in  the  proper  authentication  steps.   Detection and
-     solution of such attacks (some of which can  appear  to
-     be  not-uncommon "normal" failure modes for the system)
-     is usually best left to the  human  administrators  and
-     users.
-
-+    Principals must keep their secret keys secret.   If  an
-     intruder  somehow  steals a principal's key, it will be
-     able to masquerade as that principal or impersonate any
-     server to the legitimate principal.
-
-+    "Password guessing" attacks are not solved by Kerberos.
-     If  a  user chooses a poor password, it is possible for
-     an attacker to successfully mount an offline dictionary
-     attack  by  repeatedly attempting to decrypt, with suc-
-     cessive entries from a  dictionary,  messages  obtained
-     which are encrypted under a key derived from the user's
-     password.
-
-+    Each host on the network must have  a  clock  which  is
-     "loosely  synchronized" to the time of the other hosts;
-     this synchronization is used to reduce the  bookkeeping
-     needs of application servers when they do replay detec-
-     tion.  The degree of "looseness" can be configured on a
-     per-server  basis,  but  is typically on the order of 5
-     minutes.  If the clocks are synchronized over the  net-
-     work, the clock synchronization protocol must itself be
-     secured from network attackers.
-
-+    Principal identifiers are not recycled on a  short-term
-     basis.   A  typical  mode  of  access  control will use
-     access control lists (ACLs)  to  grant  permissions  to
-     particular  principals.   If  a stale ACL entry remains
-     for a deleted principal and the principal identifier is
-     reused, the new principal will inherit rights specified
-     in the stale ACL  entry.   By  not  re-using  principal
-     identifiers,   the  danger  of  inadvertent  access  is
-     removed.
-
-
-
-Section 1.3.               - 7 -     Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-1.4.  Glossary of terms
-
-Below is a list of terms used throughout this document.
-
-
-Authentication      Verifying  the  claimed  identity  of  a
-                    principal.
-
-
-Authentication headerA record containing  a  Ticket  and  an
-                    Authenticator   to  be  presented  to  a
-                    server as  part  of  the  authentication
-                    process.
-
-
-Authentication path A sequence of intermediate realms  tran-
-                    sited in the authentication process when
-                    communicating from one realm to another.
-
-
-Authenticator       A record containing information that can
-                    be shown to have been recently generated
-                    using the session key known only by  the
-                    client and server.
-
-
-Authorization       The process  of  determining  whether  a
-                    client may use a service,  which objects
-                    the client is allowed to access, and the
-                    type of access allowed for each.
-
-
-Capability          A token that grants the  bearer  permis-
-                    sion to access an object or service.  In
-                    Kerberos, this might be a  ticket  whose
-                    use is restricted by the contents of the
-                    authorization  data  field,  but   which
-                    lists  no  network  addresses,  together
-                    with the session key  necessary  to  use
-                    the ticket.
-
-
-Ciphertext          The output of  an  encryption  function.
-                    Encryption   transforms  plaintext  into
-                    ciphertext.
-
-
-Client              A process that makes use  of  a  network
-                    service  on behalf of a user.  Note that
-                    in some cases a Server may itself  be  a
-                    client  of  some  other  server  (e.g. a
-                    print server may be a client of  a  file
-                    server).
-
-
-
-Section 1.4.               - 8 -     Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-Credentials         A ticket plus  the  secret  session  key
-                    necessary   to   successfully  use  that
-                    ticket in an authentication exchange.
-
-
-KDC                 Key Distribution Center, a network  ser-
-                    vice that supplies tickets and temporary
-                    session keys; or  an  instance  of  that
-                    service  or  the  host on which it runs.
-                    The KDC services both initial ticket and
-                    ticket-granting  ticket  requests.   The
-                    initial  ticket  portion  is   sometimes
-                    referred to as the Authentication Server
-                    (or   service).    The   ticket-granting
-                    ticket  portion is sometimes referred to
-                    as the ticket-granting server  (or  ser-
-                    vice).
-
-
-Kerberos            Aside from  the  3-headed  dog  guarding
-                    Hades,   the   name   given  to  Project
-                    Athena's  authentication  service,   the
-                    protocol  used  by  that service, or the
-                    code used to implement  the  authentica-
-                    tion service.
-
-
-Plaintext           The input to an encryption  function  or
-                    the  output  of  a  decryption function.
-                    Decryption  transforms  ciphertext  into
-                    plaintext.
-
-
-Principal           A  uniquely  named  client   or   server
-                    instance  that participates in a network
-                    communication.
-
-
-Principal identifierThe name used to uniquely identify  each
-                    different principal.
-
-
-Seal                To encipher a record containing  several
-                    fields  in  such  a  way that the fields
-                    cannot be individually replaced  without
-                    either  knowledge  of the encryption key
-                    or leaving evidence of tampering.
-
-
-Secret key          An encryption key shared by a  principal
-                    and  the  KDC,  distributed  outside the
-                    bounds of the system, with a long  life-
-                    time.   In  the  case  of a human user's
-                    principal, the  secret  key  is  derived
-
-
-Section 1.4.               - 9 -     Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-                    from a password.
-
-
-Server              A particular Principal which provides  a
-                    resource to network clients.  The server
-                    is sometimes refered to as the  Applica-
-                    tion Server.
-
-
-Service             A resource provided to network  clients;
-                    often  provided  by more than one server
-                    (for example, remote file service).
-
-
-Session key         A temporary encryption key used  between
-                    two  principals, with a lifetime limited
-                    to the duration of a single login  "ses-
-                    sion".
-
-
-Sub-session key     A temporary encryption key used  between
-                    two  principals,  selected and exchanged
-                    by the principals using the session key,
-                    and with a lifetime limited to the dura-
-                    tion of a single association.
-
-
-Ticket              A record that helps a  client  authenti-
-                    cate itself to a server; it contains the
-                    client's  identity,  a  session  key,  a
-                    timestamp,  and  other  information, all
-                    sealed using the  server's  secret  key.
-                    It  only serves to authenticate a client
-                    when  presented  along  with   a   fresh
-                    Authenticator.
-
-2.  Ticket flag uses and requests
-
-Each Kerberos ticket contains a set of flags which are  used
-to  indicate  various attributes of that ticket.  Most flags
-may be requested by a client when the  ticket  is  obtained;
-some  are  automatically  turned  on  and  off by a Kerberos
-server as required.  The following sections explain what the
-various  flags  mean,  and  gives examples of reasons to use
-such a flag.
-
-2.1.  Initial and pre-authenticated tickets
-
-     The INITIAL flag indicates that  a  ticket  was  issued
-using  the  AS  protocol  and  not issued based on a ticket-
-granting ticket.  Application servers that want  to  require
-the  demonstrated knowledge of a client's secret key (e.g. a
-password-changing program) can insist that this flag be  set
-in  any  tickets  they  accept, and thus be assured that the
-
-
-Section 2.1.               - 10 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-client's key  was  recently  presented  to  the  application
-client.
-
-     The PRE-AUTHENT and HW-AUTHENT flags  provide  addition
-information  about the initial authentication, regardless of
-whether the current ticket was  issued  directly  (in  which
-case  INITIAL  will also be set) or issued on the basis of a
-ticket-granting ticket (in which case the  INITIAL  flag  is
-clear,  but the PRE-AUTHENT and HW-AUTHENT flags are carried
-forward from the ticket-granting ticket).
-
-2.2.  Invalid tickets
-
-     The INVALID flag indicates that a  ticket  is  invalid.
-Application servers must reject tickets which have this flag
-set.  A postdated ticket will  usually  be  issued  in  this
-form.   Invalid  tickets must be validated by the KDC before
-use, by presenting them to the KDC in a TGS request with the
-VALIDATE option specified.  The KDC will only validate tick-
-ets after their starttime has  passed.   The  validation  is
-required  so  that  postdated tickets which have been stolen
-before their starttime can be rendered  permanently  invalid
-(through a hot-list mechanism) (see section 3.3.3.1).
-
-2.3.  Renewable tickets
-
-     Applications may desire to hold tickets  which  can  be
-valid  for  long  periods of time.  However, this can expose
-their  credentials  to  potential  theft  for  equally  long
-periods,  and  those stolen credentials would be valid until
-the expiration time of the ticket(s).  Simply  using  short-
-lived  tickets  and  obtaining  new  ones periodically would
-require the client to have long-term access  to  its  secret
-key, an even greater risk.  Renewable tickets can be used to
-mitigate the consequences of theft.  Renewable tickets  have
-two  "expiration  times":  the  first  is  when  the current
-instance of the ticket expires, and the second is the latest
-permissible  value  for  an  individual expiration time.  An
-application  client  must  periodically  (i.e.   before   it
-expires)  present  a  renewable  ticket to the KDC, with the
-RENEW option set in the KDC request.  The KDC will  issue  a
-new  ticket  with  a  new session key and a later expiration
-time.  All other fields of the ticket are left unmodified by
-the renewal process.  When the latest permissible expiration
-time arrives,  the  ticket  expires  permanently.   At  each
-renewal,  the KDC may consult a hot-list to determine if the
-ticket had been reported stolen since its last  renewal;  it
-will  refuse  to  renew  such  stolen  tickets, and thus the
-usable lifetime of stolen tickets is reduced.
-
-     The RENEWABLE flag in a ticket is normally only  inter-
-preted  by  the  ticket-granting service (discussed below in
-section 3.3).  It can  usually  be  ignored  by  application
-servers.   However,  some  particularly  careful application
-
-
-Section 2.3.               - 11 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-servers may wish to disallow renewable tickets.
-
-     If a renewable ticket is not renewed by its  expiration
-time, the KDC will not renew the ticket.  The RENEWABLE flag
-is reset by default, but a client may request it be  set  by
-setting  the RENEWABLE option in the KRB_AS_REQ message.  If
-it is set, then the renew-till field in the ticket  contains
-the time after which the ticket may not be renewed.
-
-2.4.  Postdated tickets
-
-     Applications may occasionally need  to  obtain  tickets
-for  use  much  later,  e.g. a batch submission system would
-need tickets to be valid at the time the batch job  is  ser-
-viced.   However, it is dangerous to hold valid tickets in a
-batch queue, since they will  be  on-line  longer  and  more
-prone  to  theft.  Postdated tickets provide a way to obtain
-these tickets from the KDC at job submission  time,  but  to
-leave  them "dormant" until they are activated and validated
-by a further request of the KDC.  If  a  ticket  theft  were
-reported  in  the  interim, the KDC would refuse to validate
-the ticket, and the thief would be foiled.
-
-     The MAY-POSTDATE flag in  a  ticket  is  normally  only
-interpreted  by  the  ticket-granting  service.  It  can  be
-ignored by application servers.  This flag must be set in  a
-ticket-granting  ticket in order to issue a postdated ticket
-based on the presented ticket.  It is reset by  default;  it
-may  be  requested by a client by setting the ALLOW-POSTDATE
-option in the KRB_AS_REQ message.  This flag does not  allow
-a client to obtain a postdated ticket-granting ticket; post-
-dated  ticket-granting  tickets  can  only  by  obtained  by
-requesting  the  postdating  in the KRB_AS_REQ message.  The
-life (endtime-starttime) of a postdated ticket will  be  the
-remaining  life of the ticket-granting ticket at the time of
-the request, unless the RENEWABLE option  is  also  set,  in
-which  case  it  can be the full life (endtime-starttime) of
-the ticket-granting ticket.  The KDC may limit  how  far  in
-the future a ticket may be postdated.
-
-     The POSTDATED flag indicates that  a  ticket  has  been
-postdated.   The  application  server can check the authtime
-field in the ticket to see when the original  authentication
-occurred.   Some  services  may  choose  to reject postdated
-tickets, or they may  only  accept  them  within  a  certain
-period  after  the  original  authentication.   When the KDC
-issues a  POSTDATED  ticket,  it  will  also  be  marked  as
-INVALID,  so  that  the  application client must present the
-ticket to the KDC to be validated before use.
-
-2.5.  Proxiable and proxy tickets
-
-     At times it may be necessary for a principal to allow a
-service  to perform an operation on its behalf.  The service
-
-
-Section 2.5.               - 12 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-must be able to take on the identity of the client, but only
-for  a  particular purpose.  A principal can allow a service
-to take on the principal's identity for a particular purpose
-by granting it a proxy.
-
-     The process of granting a proxy  using  the  proxy  and
-proxiable  flags is used to provide credentials for use with
-specific services.  Though conceptually also a proxy, user's
-wishing  to delegate their identity for ANY purpose must use
-the ticket forwarding mechanism described in the  next  sec-
-tion to forward a ticket granting ticket.
-
-     The PROXIABLE flag in a ticket is normally only  inter-
-preted  by the ticket-granting service. It can be ignored by
-application servers.  When set, this flag tells the  ticket-
-granting server that it is OK to issue a new ticket (but not
-a ticket-granting ticket) with a different  network  address
-based  on this ticket.  This flag is set if requested by the
-client on initial authentication.  By  default,  the  client
-will  request that it be set when requesting a ticket grant-
-ing ticket, and reset when requesting any other ticket.
-
-     This flag allows a client to pass a proxy to  a  server
-to perform a remote request on its behalf, e.g. a print ser-
-vice client can give the print server a proxy to access  the
-client's  files  on  a  particular  file  server in order to
-satisfy a print request.
-
-     In order to complicate the use of  stolen  credentials,
-Kerberos  tickets  are usually valid from only those network
-addresses specifically  included  in  the  ticket[4].   When
-granting  a  proxy,  the client must specify the new network
-address from which the proxy is to be used, or indicate that
-the proxy is to be issued for use from any address.
-
-     The PROXY flag is set in a ticket by the  TGS  when  it
-issues  a  proxy ticket.  Application servers may check this
-flag and at their option they may require additional authen-
-tication  from  the  agent  presenting the proxy in order to
-provide an audit trail.
-
-2.6.  Forwardable tickets
-
-     Authentication forwarding is an  instance  of  a  proxy
-where  the  service  is granted complete use of the client's
-identity.  An example where it might be used is when a  user
-logs  in to a remote system and wants authentication to work
-from that system as if the login were local.
-
-     The FORWARDABLE flag  in  a  ticket  is  normally  only
-__________________________
-[4] Though it is permissible to request or issue  tick-
-ets with no network addresses specified.
-
-
-Section 2.6.               - 13 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-interpreted by  the  ticket-granting  service.   It  can  be
-ignored by application servers.  The FORWARDABLE flag has an
-interpretation similar to that of the PROXIABLE flag, except
-ticket-granting  tickets  may  also be issued with different
-network addresses.  This flag is reset by default, but users
-may request that it be set by setting the FORWARDABLE option
-in the AS request when they request  their  initial  ticket-
-granting ticket.
-
-     This flag allows for authentication forwarding  without
-requiring  the  user to enter a password again.  If the flag
-is not set, then authentication forwarding is not permitted,
-but  the  same  result  can  still  be  achieved if the user
-engages in the AS exchange specifying the requested  network
-addresses and supplies a password.
-
-     The FORWARDED flag is set by  the  TGS  when  a  client
-presents a ticket with the FORWARDABLE flag set and requests
-a forwarded ticket by specifying the  FORWARDED  KDC  option
-and  supplying a set of addresses for the new ticket.  It is
-also set in all tickets issued based  on  tickets  with  the
-FORWARDED  flag set.  Application servers may choose to pro-
-cess FORWARDED tickets differently than non-FORWARDED  tick-
-ets.
-
-2.7.  Other KDC options
-
-     There are two additional options which may be set in  a
-client's  request of the KDC.  The RENEWABLE-OK option indi-
-cates that the client will accept a renewable  ticket  if  a
-ticket with the requested life cannot otherwise be provided.
-If a ticket with the requested life cannot be provided, then
-the KDC may issue a renewable ticket with a renew-till equal
-to the the requested endtime.  The value of  the  renew-till
-field  may  still  be  adjusted by site-determined limits or
-limits imposed by the individual principal or server.
-
-     The ENC-TKT-IN-SKEY  option  is  honored  only  by  the
-ticket-granting service.  It indicates that the ticket to be
-issued for the end server is to be encrypted in the  session
-key from the a additional second ticket-granting ticket pro-
-vided with the request.   See  section  3.3.3  for  specific
-details.
-
-__________________________
-[5] The password-changing request must not  be  honored
-unless  the requester can provide the old password (the
-user's current secret key).   Otherwise,  it  would  be
-possible  for  someone to walk up to an unattended ses-
-sion and change another user's password.
-[6] To authenticate a user logging on to a  local  sys-
-tem,  the  credentials  obtained in the AS exchange may
-first be used in a TGS exchange to  obtain  credentials
-
-
-Section 3.1.               - 14 -    Expires 11 January 1998
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-
-3.  Message Exchanges
-
-The following sections  describe  the  interactions  between
-network  clients  and  servers  and the messages involved in
-those exchanges.
-
-3.1.  The Authentication Service Exchange
-
-                          Summary
-      Message direction       Message type    Section
-      1. Client to Kerberos   KRB_AS_REQ      5.4.1
-      2. Kerberos to client   KRB_AS_REP or   5.4.2
-                              KRB_ERROR       5.9.1
-
-
-     The Authentication Service (AS)  Exchange  between  the
-client  and  the Kerberos Authentication Server is initiated
-by a client when it wishes to obtain authentication  creden-
-tials for a given server but currently holds no credentials.
-In its basic form, the client's secret key is used  for  en-
-cryption and decryption.  This exchange is typically used at
-the initiation of a login session to obtain credentials  for
-a  Ticket-Granting Server which will subsequently be used to
-obtain credentials  for  other  servers  (see  section  3.3)
-without  requiring  further  use of the client's secret key.
-This exchange is also used to request credentials  for  ser-
-vices which must not be mediated through the Ticket-Granting
-Service, but rather require a principal's secret  key,  such
-as the password-changing service[5].  This exchange does not
-by  itself  provide any assurance of the the identity of the
-user[6].
-
-     The exchange consists of two messages: KRB_AS_REQ  from
-the  client  to  Kerberos,  and  KRB_AS_REP  or KRB_ERROR in
-reply.  The formats for these messages are described in sec-
-tions 5.4.1, 5.4.2, and 5.9.1.
-
-     In the request, the client sends (in cleartext) its own
-identity  and  the  identity  of  the server for which it is
-requesting credentials.  The response, KRB_AS_REP,  contains
-a ticket for the client to present to the server, and a ses-
-sion key that will be shared by the client and  the  server.
-The  session key and additional information are encrypted in
-the client's secret key.  The  KRB_AS_REP  message  contains
-information  which  can  be  used  to detect replays, and to
-associate it with the message to which it replies.   Various
-errors  can  occur; these are indicated by an error response
-(KRB_ERROR) instead of the KRB_AS_REP response.   The  error
-__________________________
-for  a  local  server.   Those credentials must then be
-verified by a local server through  successful  comple-
-tion of the Client/Server exchange.
-
-
-
-Section 3.1.               - 15 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-message is not encrypted.  The  KRB_ERROR  message  contains
-information  which can be used to associate it with the mes-
-sage to which it replies.  The lack  of  encryption  in  the
-KRB_ERROR  message  precludes the ability to detect replays,
-fabrications, or modifications of such messages.
-
-     Without  preautentication,  the  authentication  server
-does  not  know whether the client is actually the principal
-named in the request.  It simply sends a reply without know-
-ing or caring whether they are the same.  This is acceptable
-because nobody but the principal whose identity was given in
-the  request  will  be  able  to use the reply. Its critical
-information is encrypted in that principal's key.  The  ini-
-tial  request supports an optional field that can be used to
-pass additional information that might  be  needed  for  the
-initial   exchange.    This  field  may  be  used  for  pre-
-authentication as described in section <<sec preauth>>.
-
-3.1.1.  Generation of KRB_AS_REQ message
-
-     The client may specify a number of options in the  ini-
-tial   request.    Among  these  options  are  whether  pre-
-authentication is to be  performed;  whether  the  requested
-ticket  is  to  be  renewable,  proxiable,  or  forwardable;
-whether it  should  be  postdated  or  allow  postdating  of
-derivative  tickets;  and whether a renewable ticket will be
-accepted in lieu of a non-renewable ticket if the  requested
-ticket  expiration  date  cannot  be  satisfied  by  a  non-
-renewable ticket (due to configuration constraints; see sec-
-tion 4).  See section A.1 for pseudocode.
-
-     The client prepares the KRB_AS_REQ message and sends it
-to the KDC.
-
-3.1.2.  Receipt of KRB_AS_REQ message
-
-     If all goes well,  processing  the  KRB_AS_REQ  message
-will  result  in  the creation of a ticket for the client to
-present to  the  server.   The  format  for  the  ticket  is
-described  in section 5.3.1.  The contents of the ticket are
-determined as follows.
-
-3.1.3.  Generation of KRB_AS_REP message
-
-     The authentication  server  looks  up  the  client  and
-server  principals  named in the KRB_AS_REQ in its database,
-extracting their respective keys.  If required,  the  server
-pre-authenticates the request, and if the pre-authentication
-check   fails,   an   error   message    with    the    code
-KDC_ERR_PREAUTH_FAILED  is  returned.   If the server cannot
-accommodate the requested encryption type, an error  message
-with  code  KDC_ERR_ETYPE_NOSUPP  is returned.  Otherwise it
-generates a "random" session key[7].
-__________________________
-
-
-Section 3.1.3.             - 16 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-     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 infor-
-mation  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.
-
-     If the requested start time is absent, indicates a time
-in  the  past,  or  is within the window of acceptable clock
-skew for the KDC and the POSTDATE option has not been speci-
-fied,  then  the  start  time  of  the  ticket is set to the
-authentication server's current time.   If  it  indicates  a
-time in the future beyond the acceptable clock skew, but the
-POSTDATED option has  not  been  specified  then  the  error
-KDC_ERR_CANNOT_POSTDATE    is   returned.    Otherwise   the
-requested start time is checked against the  policy  of  the
-local realm (the administrator might decide to prohibit cer-
-tain types or ranges of postdated tickets), and  if  accept-
-able,  the  ticket's  start time is set as requested and the
-INVALID flag is set in the new ticket. The postdated  ticket
-must  be  validated  before  use by presenting it to the KDC
-after the start time has been reached.
-
-
-
-
-
-
-
-
-
-__________________________
-[7] "Random" means that, among other things, it  should
-be  impossible  to  guess the next session key based on
-knowledge of past  session  keys.   This  can  only  be
-achieved  in  a pseudo-random number generator if it is
-based on cryptographic principles.  It is  more  desir-
-able  to  use  a truly random number generator, such as
-one based on measurements of random physical phenomena.
-
-
-
-Section 3.1.3.             - 17 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-The expiration time of the ticket will be set to the minimum
-of the following:
-
-+The expiration time (endtime) requested in  the  KRB_AS_REQ
- message.
-
-+The ticket's start time plus the maximum allowable lifetime
- associated  with  the  client principal (the authentication
- server's database includes a maximum ticket lifetime  field
- in each principal's record; see section 4).
-
-+The ticket's start time plus the maximum allowable lifetime
- associated with the server principal.
-
-+The ticket's start time plus the maximum  lifetime  set  by
- the policy of the local realm.
-
-     If the requested expiration time minus the  start  time
-(as determined above) is less than a site-determined minimum
-lifetime, an error message with code KDC_ERR_NEVER_VALID  is
-returned.   If  the requested expiration time for the ticket
-exceeds  what  was  determined  as   above,   and   if   the
-"RENEWABLE-OK"  option  was  requested, then the "RENEWABLE"
-flag is set in the new ticket, and the renew-till  value  is
-set  as  if the "RENEWABLE" option were requested (the field
-and option names are described fully in section 5.4.1).
-
-If the  RENEWABLE  option  has  been  requested  or  if  the
-RENEWABLE-OK  option  has been set and a renewable ticket is
-to be issued, then  the  renew-till  field  is  set  to  the
-minimum of:
-
-+Its requested value.
-
-+The start time of the ticket plus the minimum  of  the  two
- maximum renewable lifetimes associated with the principals'
- database entries.
-
-+The start time of the ticket  plus  the  maximum  renewable
- lifetime set by the policy of the local realm.
-
-     The flags field of the new ticket will have the follow-
-ing  options set if they have been requested and if the pol-
-icy of the local realm  allows:  FORWARDABLE,  MAY-POSTDATE,
-POSTDATED,  PROXIABLE, RENEWABLE. If the new ticket is post-
-dated (the start time is in the future),  its  INVALID  flag
-will also be set.
-
-     If all of the  above  succeed,  the  server  formats  a
-KRB_AS_REP   message   (see   section  5.4.2),  copying  the
-addresses in the request into the  caddr  of  the  response,
-placing any required pre-authentication data into the padata
-of the response, and encrypts the  ciphertext  part  in  the
-client's  key  using  the  requested  encryption method, and
-
-
-Section 3.1.3.             - 18 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-sends it to the client.  See section A.2 for pseudocode.
-
-3.1.4.  Generation of KRB_ERROR message
-
-     Several errors can occur, and the Authentication Server
-responds  by  returning  an error message, KRB_ERROR, to the
-client,  with  the  error-code  and  e-text  fields  set  to
-appropriate  values.  The error message contents and details
-are described in Section 5.9.1.
-
-3.1.5.  Receipt of KRB_AS_REP message
-
-     If the reply  message  type  is  KRB_AS_REP,  then  the
-client  verifies  that  the  cname  and crealm fields in the
-cleartext portion of the reply match what it requested.   If
-any  padata  fields  are present, they may be used to derive
-the proper secret key to decrypt the  message.   The  client
-decrypts the encrypted part of the response using its secret
-key, verifies that the nonce in the encrypted  part  matches
-the  nonce  it  supplied in its request (to detect replays).
-It also verifies that the sname and srealm in  the  response
-match  those  in  the  request  (or  are  otherwise expected
-values), and that the host address field  is  also  correct.
-It then stores the ticket, session key, start and expiration
-times, and  other  information  for  later  use.   The  key-
-expiration field from the encrypted part of the response may
-be checked to notify the user of  impending  key  expiration
-(the client program could then suggest remedial action, such
-as a password change).  See section A.3 for pseudocode.
-
-     Proper decryption of the KRB_AS_REP message is not suf-
-ficient  to verify the identity of the user; the user and an
-attacker could cooperate to  generate  a  KRB_AS_REP  format
-message  which  decrypts properly but is not from the proper
-KDC.  If the host wishes to verify the identity of the user,
-it  must require the user to present application credentials
-which can be verified using a securely-stored secret key for
-the  host.   If  those credentials can be verified, then the
-identity of the user can be assured.
-
-3.1.6.  Receipt of KRB_ERROR message
-
-     If the reply message type is KRB_ERROR, then the client
-interprets   it   as   an   error   and   performs  whatever
-application-specific tasks are necessary to recover.
-
-3.2.  The Client/Server Authentication Exchange
-
-                             Summary
-Message direction                         Message type    Section
-Client to Application server              KRB_AP_REQ      5.5.1
-[optional] Application server to client   KRB_AP_REP or   5.5.2
-                                          KRB_ERROR       5.9.1
-
-
-
-Section 3.2.               - 19 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-     The client/server authentication (CS) exchange is  used
-by  network  applications  to authenticate the client to the
-server  and  vice  versa.   The  client  must  have  already
-acquired  credentials  for  the  server  using the AS or TGS
-exchange.
-
-3.2.1.  The KRB_AP_REQ message
-
-     The  KRB_AP_REQ  contains  authentication   information
-which  should  be  part of the first message in an authenti-
-cated transaction.  It contains a ticket, an  authenticator,
-and  some  additional  bookkeeping  information (see section
-5.5.1 for the exact format).  The ticket by itself is insuf-
-ficient  to  authenticate a client, since tickets are passed
-across the network in cleartext[8], so the authenticator  is
-used  to prevent invalid replay of tickets by proving to the
-server that the client knows the session key of  the  ticket
-and thus is entitled to use the ticket.  The KRB_AP_REQ mes-
-sage  is  referred  to  elsewhere  as  the   "authentication
-header."
-
-3.2.2.  Generation of a KRB_AP_REQ message
-
-     When a client wishes to initiate  authentication  to  a
-server,  it obtains (either through a credentials cache, the
-AS exchange, or the TGS exchange) a ticket and  session  key
-for  the desired service.  The client may re-use any tickets
-it holds until they expire.  To use a ticket the client con-
-structs  a  new  Authenticator from the the system time, its
-name, and optionally an application  specific  checksum,  an
-initial  sequence  number to be used in KRB_SAFE or KRB_PRIV
-messages, and/or a session subkey to be used in negotiations
-for  a  session  key  unique  to  this  particular  session.
-Authenticators may not be re-used and will  be  rejected  if
-replayed to a server[9].  If a  sequence  number  is  to  be
-included,  it  should  be randomly chosen so that even after
-many messages have been exchanged it is not likely  to  col-
-lide with other sequence numbers in use.
-
-     The  client  may  indicate  a  requirement  of   mutual
-__________________________
-[8] Tickets contain both an encrypted  and  unencrypted
-portion,  so  cleartext here refers to the entire unit,
-which can be copied from one message  and  replayed  in
-another without any cryptographic skill.
-[9] Note  that  this can make applications based on un-
-reliable transports difficult to code correctly. If the
-transport  might  deliver duplicated messages, either a
-new authenticator must be generated for each retry,  or
-the  application server must match requests and replies
-and replay the first reply in response  to  a  detected
-duplicate.
-
-
-
-Section 3.2.2.             - 20 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-authentication or the use of a session-key based  ticket  by
-setting  the  appropriate flag(s) in the ap-options field of
-the message.
-
-     The Authenticator is encrypted in the session  key  and
-combined  with  the  ticket  to  form the KRB_AP_REQ message
-which is then sent to the end server along  with  any  addi-
-tional  application-specific  information.   See section A.9
-for pseudocode.
-
-3.2.3.  Receipt of KRB_AP_REQ message
-
-     Authentication is based on the server's current time of
-day  (clocks  must be loosely synchronized), the authentica-
-tor, and the ticket.  Several errors are  possible.   If  an
-error  occurs, the server is expected to reply to the client
-with a KRB_ERROR message.  This message may be  encapsulated
-in the application protocol if its "raw" form is not accept-
-able to the protocol.   The  format  of  error  messages  is
-described in section 5.9.1.
-
-     The algorithm for verifying authentication  information
-is  as  follows.  If the message type is not KRB_AP_REQ, the
-server returns the KRB_AP_ERR_MSG_TYPE error.   If  the  key
-version indicated by the Ticket in the KRB_AP_REQ is not one
-the server can use (e.g., it indicates an old key,  and  the
-server  no  longer  possesses  a  copy  of the old key), the
-KRB_AP_ERR_BADKEYVER  error  is  returned.   If   the   USE-
-SESSION-KEY  flag  is  set in the ap-options field, it indi-
-cates to the server that the ticket is encrypted in the ses-
-sion  key  from  the  server's ticket-granting ticket rather
-than its secret key[10].   Since  it  is  possible  for  the
-server  to  be registered in multiple realms, with different
-keys in each, the srealm field in the unencrypted portion of
-the ticket in the KRB_AP_REQ is used to specify which secret
-key the server should  use  to  decrypt  that  ticket.   The
-KRB_AP_ERR_NOKEY  error  code  is  returned  if  the  server
-doesn't have the proper key to decipher the ticket.
-
-     The ticket  is  decrypted  using  the  version  of  the
-server's  key  specified  by  the ticket.  If the decryption
-routines detect a modification of the ticket  (each  encryp-
-tion  system  must  provide  safeguards  to  detect modified
-ciphertext; see  section  6),  the  KRB_AP_ERR_BAD_INTEGRITY
-error is returned (chances are good that different keys were
-used to encrypt and decrypt).
-
-     The authenticator is decrypted using  the  session  key
-extracted from the decrypted ticket.  If decryption shows it
-to have been modified, the KRB_AP_ERR_BAD_INTEGRITY error is
-__________________________
-[10] This is used for  user-to-user  authentication  as
-described in  [8].
-
-
-Section 3.2.3.             - 21 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-returned.  The name and realm of the client from the  ticket
-are  compared  against the same fields in the authenticator.
-If  they  don't  match,  the  KRB_AP_ERR_BADMATCH  error  is
-returned  (they  might  not match, for example, if the wrong
-session key was used to  encrypt  the  authenticator).   The
-addresses  in  the  ticket (if any) are then searched for an
-address matching the operating-system  reported  address  of
-the  client.   If no match is found or the server insists on
-ticket addresses but none are present  in  the  ticket,  the
-KRB_AP_ERR_BADADDR error is returned.
-
-     If the local (server) time and the client time  in  the
-authenticator  differ  by more than the allowable clock skew
-(e.g., 5 minutes), the KRB_AP_ERR_SKEW  error  is  returned.
-If  the  server  name,  along with the client name, time and
-microsecond  fields  from  the   Authenticator   match   any
-recently-seen  such  tuples,  the KRB_AP_ERR_REPEAT error is
-returned[11].  The server must  remember  any  authenticator
-presented  within the allowable clock skew, so that a replay
-attempt is guaranteed to fail.  If a server loses  track  of
-any authenticator presented within the allowable clock skew,
-it must reject all requests until the  clock  skew  interval
-has passed.  This assures that any lost or re-played authen-
-ticators will fall outside the allowable clock skew and  can
-no  longer be successfully replayed (If this is not done, an
-attacker could conceivably record the ticket and authentica-
-tor  sent  over  the  network  to a server, then disable the
-client's host, pose as the disabled  host,  and  replay  the
-ticket  and  authenticator  to subvert the authentication.).
-If a sequence number is provided in the  authenticator,  the
-server  saves it for later use in processing KRB_SAFE and/or
-KRB_PRIV messages.  If  a  subkey  is  present,  the  server
-either  saves  it  for later use or uses it to help generate
-its own choice for a subkey to be returned in  a  KRB_AP_REP
-message.
-
-     The server  computes  the  age  of  the  ticket:  local
-(server)  time  minus  the start time inside the Ticket.  If
-the start time is later than the current time by  more  than
-the  allowable  clock  skew or if the INVALID flag is set in
-the ticket, the KRB_AP_ERR_TKT_NYV error is returned.   Oth-
-erwise,  if  the current time is later than end time by more
-than the allowable clock  skew,  the  KRB_AP_ERR_TKT_EXPIRED
-error is returned.
-
-     If all these  checks  succeed  without  an  error,  the
-__________________________
-[11] Note that the rejection here is restricted to  au-
-thenticators  from  the  same  principal  to  the  same
-server.  Other client principals communicating with the
-same  server principal should not be have their authen-
-ticators rejected if the time  and  microsecond  fields
-happen to match some other client's authenticator.
-
-
-Section 3.2.3.             - 22 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-server is assured that the client possesses the  credentials
-of  the  principal  named in the ticket and thus, the client
-has been authenticated to the server.  See section A.10  for
-pseudocode.
-
-     Passing these checks provides  only  authentication  of
-the  named principal; it does not imply authorization to use
-the  named  service.   Applications  must  make  a  separate
-authorization decisions based upon the authenticated name of
-the user,  the  requested  operation,  local  acces  control
-information such as that contained in a .k5login or .k5users
-file, and possibly a separate distributed authorization ser-
-vice.
-
-3.2.4.  Generation of a KRB_AP_REP message
-
-     Typically, a client's request  will  include  both  the
-authentication  information  and  its initial request in the
-same message, and the server need not  explicitly  reply  to
-the KRB_AP_REQ.  However, if mutual authentication (not only
-authenticating the client to the server, but also the server
-to  the  client)  is being performed, the KRB_AP_REQ message
-will have MUTUAL-REQUIRED set in its ap-options field, and a
-KRB_AP_REP  message  is  required  in response.  As with the
-error message, this  message  may  be  encapsulated  in  the
-application  protocol if its "raw" form is not acceptable to
-the application's protocol.  The timestamp  and  microsecond
-field  used  in the reply must be the client's timestamp and
-microsecond field (as provided  in  the  authenticator)[12].
-If  a  sequence  number is to be included, it should be ran-
-domly chosen as described above for  the  authenticator.   A
-subkey  may be included if the server desires to negotiate a
-different subkey.  The KRB_AP_REP message  is  encrypted  in
-the session key extracted from the ticket.  See section A.11
-for pseudocode.
-
-3.2.5.  Receipt of KRB_AP_REP message
-
-
-     If a KRB_AP_REP message is returned,  the  client  uses
-the  session  key  from  the  credentials  obtained  for the
-server[13] to decrypt the message,  and  verifies  that  the
-__________________________
-[12] In the Kerberos version 4 protocol, the  timestamp
-in the reply was the client's timestamp plus one.  This
-is not necessary in version 5 because  version  5  mes-
-sages are formatted in such a way that it is not possi-
-ble to create the reply by  judicious  message  surgery
-(even  in  encrypted form) without knowledge of the ap-
-propriate encryption keys.
-[13] Note that for encrypting the  KRB_AP_REP  message,
-the sub-session key is not used, even if present in the
-Authenticator.
-
-
-Section 3.2.5.             - 23 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-timestamp and microsecond fields match those in the  Authen-
-ticator  it  sent  to  the  server.  If they match, then the
-client is assured that the server is genuine.  The  sequence
-number  and  subkey (if present) are retained for later use.
-See section A.12 for pseudocode.
-
-
-3.2.6.  Using the encryption key
-
-     After the KRB_AP_REQ/KRB_AP_REP exchange has  occurred,
-the  client  and server share an encryption key which can be
-used by the application.  The "true session key" to be  used
-for  KRB_PRIV,  KRB_SAFE, or other application-specific uses
-may be chosen by the application based on the subkeys in the
-KRB_AP_REP  message  and  the  authenticator[14].   In  some
-cases,  the  use of this session key will be implicit in the
-protocol; in others the method of use must  be  chosen  from
-several alternatives.  We leave the protocol negotiations of
-how to use the key (e.g.  selecting an encryption or  check-
-sum type) to the application programmer; the Kerberos proto-
-col does not constrain the implementation  options,  but  an
-example of how this might be done follows.
-
-     One way that an application may choose to  negotiate  a
-key  to  be used for subequent integrity and privacy protec-
-tion is for the client to propose a key in the subkey  field
-of  the  authenticator.   The  server  can then choose a key
-using the proposed key from the client as  input,  returning
-the new subkey in the subkey field of the application reply.
-This key could then be used  for  subsequent  communication.
-To make this example more concrete, if the encryption method
-in use required a 56 bit key, and for whatever  reason,  one
-of the parties was prevented from using a key with more than
-40 unknown bits, this method would allow the the party which
-is  prevented from using more than 40 bits to either propose
-(if the client) an initial key with a known quantity for  16
-of  those  bits,  or  to mask 16 of the bits (if the server)
-with the known quantity.   The  application  implementor  is
-warned,  however,  that this is only an example, and that an
-analysis of the particular crytosystem to be used,  and  the
-reasons  for  limiting  the  key length, must be made before
-deciding whether it is acceptable to mask bits of the key.
-
-     With  both  the  one-way  and   mutual   authentication
-exchanges,  the peers should take care not to send sensitive
-information to each other  without  proper  assurances.   In
-particular,  applications  that require privacy or integrity
-should use the KRB_AP_REP response from the server to client
-__________________________
-[14] Implementations of the protocol may wish  to  pro-
-vide  routines  to choose subkeys based on session keys
-and random numbers and to generate a negotiated key  to
-be returned in the KRB_AP_REP message.
-
-
-Section 3.2.6.             - 24 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-to assure both client and server of their  peer's  identity.
-If an application protocol requires privacy of its messages,
-it can use the KRB_PRIV message (section 3.5).  The KRB_SAFE
-message (section 3.4) can be used to assure integrity.
-
-
-3.3.  The Ticket-Granting Service (TGS) Exchange
-
-                          Summary
-      Message direction       Message type     Section
-      1. Client to Kerberos   KRB_TGS_REQ      5.4.1
-      2. Kerberos to client   KRB_TGS_REP or   5.4.2
-                              KRB_ERROR        5.9.1
-
-
-     The TGS exchange between  a  client  and  the  Kerberos
-Ticket-Granting  Server  is  initiated  by  a client when it
-wishes to obtain  authentication  credentials  for  a  given
-server  (which  might be registered in a remote realm), when
-it wishes to renew or validate an existing ticket,  or  when
-it  wishes to obtain a proxy ticket.  In the first case, the
-client must already have acquired a ticket for  the  Ticket-
-Granting  Service using the AS exchange (the ticket-granting
-ticket is usually obtained when a client initially authenti-
-cates to the system, such as when a user logs in).  The mes-
-sage format for the TGS exchange is almost identical to that
-for the AS exchange.  The primary difference is that encryp-
-tion and decryption in the TGS exchange does not take  place
-under  the  client's key.  Instead, the session key from the
-ticket-granting ticket or renewable ticket,  or  sub-session
-key  from  an Authenticator is used.  As is the case for all
-application servers, expired tickets are not accepted by the
-TGS,  so once a renewable or ticket-granting ticket expires,
-the client must use a  separate  exchange  to  obtain  valid
-tickets.
-
-     The TGS exchange consists of two  messages:  A  request
-(KRB_TGS_REQ)  from  the  client  to  the  Kerberos  Ticket-
-Granting Server, and a  reply  (KRB_TGS_REP  or  KRB_ERROR).
-The  KRB_TGS_REQ message includes information authenticating
-the client plus a request for credentials.  The  authentica-
-tion  information  consists  of  the  authentication  header
-(KRB_AP_REQ) which includes the client's previously obtained
-ticket-granting,  renewable,  or  invalid  ticket.   In  the
-ticket-granting ticket and  proxy  cases,  the  request  may
-include  one or more of: a list of network addresses, a col-
-lection of typed authorization data  to  be  sealed  in  the
-ticket  for  authorization use by the application server, or
-additional tickets (the use of which are  described  later).
-The  TGS  reply (KRB_TGS_REP) contains the requested creden-
-tials, encrypted in the session key from the ticket-granting
-ticket  or  renewable  ticket,  or  if  present, in the sub-
-session key from the Authenticator (part of the  authentica-
-tion  header).  The KRB_ERROR message contains an error code
-
-
-Section 3.3.               - 25 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-and text explaining what went wrong.  The KRB_ERROR  message
-is not encrypted.  The KRB_TGS_REP message contains informa-
-tion which can be used to detect replays, and  to  associate
-it with the message to which it replies.  The KRB_ERROR mes-
-sage also contains information which can be used to  associ-
-ate it with the message to which it replies, but the lack of
-encryption in the KRB_ERROR message precludes the ability to
-detect replays or fabrications of such messages.
-
-3.3.1.  Generation of KRB_TGS_REQ message
-
-     Before sending a request to  the  ticket-granting  ser-
-vice,  the client must determine in which realm the applica-
-tion server is  registered[15].   If  the  client  does  not
-already possess a ticket-granting ticket for the appropriate
-realm, then one must be obtained.  This is  first  attempted
-by  requesting  a ticket-granting ticket for the destination
-realm from a Kerberos  server  for  which  the  client  does
-posess  a ticket-granting ticket (using the KRB_TGS_REQ mes-
-sage recursively).  The Kerberos server may return a TGT for
-the  desired  realm in which case one can proceed.  Alterna-
-tively, the Kerberos server may return a  TGT  for  a  realm
-which  is  "closer"  to the desired realm (further along the
-standard hierarchical path), in which case this step must be
-repeated  with  a  Kerberos server in the realm specified in
-the returned TGT.  If neither are returned, then the request
-must be retried with a Kerberos server for a realm higher in
-the hierarchy.  This request will itself require  a  ticket-
-granting  ticket for the higher realm which must be obtained
-by recursively applying these directions.
-
-
-     Once the client obtains a  ticket-granting  ticket  for
-the  appropriate realm, it determines which Kerberos servers
-serve that realm, and  contacts  one.   The  list  might  be
-obtained  through a configuration file or network service or
-it may be generated from the name of the realm; as  long  as
-the  secret  keys  exchanged by realms are kept secret, only
-denial of  service  results  from  using  a  false  Kerberos
-server.
-__________________________
-[15] This can be  accomplished  in  several  ways.   It
-might  be  known beforehand (since the realm is part of
-the principal identifier), it  might  be  stored  in  a
-nameserver,  or  it might be obtained from a configura-
-tion file.  If the realm to be used is obtained from  a
-nameserver,  there  is a danger of being spoofed if the
-nameservice providing the realm name is  not  authenti-
-cated.   This  might result in the use of a realm which
-has been compromised, and would result in an attacker's
-ability  to compromise the authentication of the appli-
-cation server to the client.
-
-
-
-Section 3.3.1.             - 26 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-     As in the AS exchange, the client may specify a  number
-of  options in the KRB_TGS_REQ message.  The client prepares
-the KRB_TGS_REQ message, providing an authentication  header
-as  an  element  of the padata field, and including the same
-fields as used in the KRB_AS_REQ message along with  several
-optional fields: the enc-authorization-data field for appli-
-cation server use and additional tickets  required  by  some
-options.
-
-     In preparing the authentication header, the client  can
-select  a  sub-session key under which the response from the
-Kerberos server will be encrypted[16].  If  the  sub-session
-key  is  not  specified,  the  session  key from the ticket-
-granting ticket will be used.  If the enc-authorization-data
-is  present, it must be encrypted in the sub-session key, if
-present, from the authenticator portion of  the  authentica-
-tion  header,  or if not present, using the session key from
-the ticket-granting ticket.
-
-     Once prepared, the message is sent to a Kerberos server
-for the destination realm.  See section A.5 for pseudocode.
-
-3.3.2.  Receipt of KRB_TGS_REQ message
-
-     The KRB_TGS_REQ message is processed in a manner  simi-
-lar to the KRB_AS_REQ message, but there are many additional
-checks to be performed.  First,  the  Kerberos  server  must
-determine which server the accompanying ticket is for and it
-must select the appropriate key to decrypt it.  For a normal
-KRB_TGS_REQ message, it will be for the ticket granting ser-
-vice, and the TGS's key will be used.  If the TGT was issued
-by  another realm, then the appropriate inter-realm key must
-be used.  If the accompanying ticket is not a ticket  grant-
-ing  ticket for the current realm, but is for an application
-server in the current realm, the RENEW, VALIDATE,  or  PROXY
-options  are  specified  in  the request, and the server for
-which a ticket is requested  is  the  server  named  in  the
-accompanying ticket, then the KDC will decrypt the ticket in
-the authentication header using the key of  the  server  for
-which  it  was  issued.   If  no  ticket can be found in the
-padata  field,  the  KDC_ERR_PADATA_TYPE_NOSUPP   error   is
-returned.
-
-     Once the accompanying ticket has  been  decrypted,  the
-user-supplied checksum in the Authenticator must be verified
-against  the  contents  of  the  request,  and  the  message
-rejected  if  the checksums do not match (with an error code
-__________________________
-[16] If the client selects a sub-session key, care must
-be  taken to ensure the randomness of the selected sub-
-session key.  One approach would be to generate a  ran-
-dom  number  and  XOR  it with the session key from the
-ticket-granting ticket.
-
-
-Section 3.3.2.             - 27 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-of KRB_AP_ERR_MODIFIED) or if the checksum is not  keyed  or
-not    collision-proof    (with    an    error    code    of
-KRB_AP_ERR_INAPP_CKSUM).  If the checksum type is  not  sup-
-ported,  the  KDC_ERR_SUMTYPE_NOSUPP  error is returned.  If
-the authorization-data are present, they are decrypted using
-the sub-session key from the Authenticator.
-
-     If any of the  decryptions  indicate  failed  integrity
-checks, the KRB_AP_ERR_BAD_INTEGRITY error is returned.
-
-3.3.3.  Generation of KRB_TGS_REP message
-
-     The KRB_TGS_REP message  shares  its  format  with  the
-KRB_AS_REP  (KRB_KDC_REP),  but  with  its type field set to
-KRB_TGS_REP.   The  detailed  specification  is  in  section
-5.4.2.
-
-     The response will include a ticket  for  the  requested
-server.   The  Kerberos  database is queried to retrieve the
-record for the requested  server  (including  the  key  with
-which  the ticket will be encrypted).  If the request is for
-a ticket granting ticket for a remote realm, and if  no  key
-is shared with the requested realm, then the Kerberos server
-will select the realm "closest" to the requested realm  with
-which it does share a key, and use that realm instead.  This
-is the only case where the response from the KDC will be for
-a different server than that requested by the client.
-
-     By default, the address field, the  client's  name  and
-realm,  the  list  of  transited realms, the time of initial
-authentication, the expiration time, and  the  authorization
-data  of  the  newly-issued  ticket  will be copied from the
-ticket-granting ticket (TGT) or renewable  ticket.   If  the
-transited  field needs to be updated, but the transited type
-is  not  supported,  the  KDC_ERR_TRTYPE_NOSUPP   error   is
-returned.
-
-     If the request specifies an endtime, then  the  endtime
-of the new ticket is set to the minimum of (a) that request,
-(b) the endtime from the TGT, and (c) the starttime  of  the
-TGT plus the minimum of the maximum life for the application
-server and the maximum life for the local realm (the maximum
-life  for  the requesting principal was already applied when
-the TGT was issued).  If the new ticket is to be a  renewal,
-then the endtime above is replaced by the minimum of (a) the
-value of the renew_till field of  the  ticket  and  (b)  the
-starttime  for  the  new  ticket  plus  the  life  (endtime-
-starttime) of the old ticket.
-
-     If the FORWARDED option has been  requested,  then  the
-resulting ticket will contain the addresses specified by the
-client.  This option will only be honored if the FORWARDABLE
-flag  is  set in the TGT.  The PROXY option is similar;  the
-resulting ticket will contain the addresses specified by the
-
-
-Section 3.3.3.             - 28 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-client.   It  will  be honored only if the PROXIABLE flag in
-the TGT is set.  The PROXY option will  not  be  honored  on
-requests for additional ticket-granting tickets.
-
-     If the requested start time is absent, indicates a time
-in  the  past,  or  is within the window of acceptable clock
-skew for the KDC and the POSTDATE option has not been speci-
-fied,  then  the  start  time  of  the  ticket is set to the
-authentication server's current time.   If  it  indicates  a
-time in the future beyond the acceptable clock skew, but the
-POSTDATED option has not been specified or the  MAY-POSTDATE
-flag   is   not   set   in   the   TGT,   then   the   error
-KDC_ERR_CANNOT_POSTDATE  is  returned.   Otherwise,  if  the
-ticket-granting  ticket  has the MAY-POSTDATE flag set, then
-the resulting ticket will be  postdated  and  the  requested
-starttime  is checked against the policy of the local realm.
-If acceptable, the ticket's start time is set as  requested,
-and  the  INVALID flag is set.  The postdated ticket must be
-validated before use by presenting it to the KDC  after  the
-starttime  has  been  reached.   However, in no case may the
-starttime, endtime, or renew-till  time  of  a  newly-issued
-postdated  ticket  extend  beyond the renew-till time of the
-ticket-granting ticket.
-
-     If the ENC-TKT-IN-SKEY option has been specified and an
-additional  ticket has been included in the request, the KDC
-will decrypt the additional ticket using  the  key  for  the
-server  to which the additional ticket was issued and verify
-that it is a ticket-granting ticket.  If  the  name  of  the
-requested  server  is  missing from the request, the name of
-the client in the additional ticket will be used.  Otherwise
-the  name  of  the  requested server will be compared to the
-name of the client in the  additional  ticket  and  if  dif-
-ferent,  the  request  will  be  rejected.   If  the request
-succeeds, the session key from the additional ticket will be
-used  to  encrypt  the  new ticket that is issued instead of
-using the key of the server for which the new ticket will be
-used[17].
-
-     If the name  of  the  server  in  the  ticket  that  is
-presented to the KDC as part of the authentication header is
-not that of the ticket-granting server itself, the server is
-registered  in the realm of the KDC, and the RENEW option is
-requested, then the KDC will verify that the RENEWABLE  flag
-is  set  in  the ticket, that the INVALID flag is not set in
-the ticket, and that the renew_till time  is  still  in  the
-future.   If  the VALIDATE option is rqeuested, the KDC will
-__________________________
-[17] This allows easy  implementation  of  user-to-user
-authentication  [8],  which uses ticket-granting ticket
-session keys in lieu of secret server  keys  in  situa-
-tions  where  such secret keys could be easily comprom-
-ised.
-
-
-Section 3.3.3.             - 29 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-check that the starttime has passed and the INVALID flag  is
-set.   If  the  PROXY option is requested, then the KDC will
-check that the PROXIABLE flag is set in the ticket.  If  the
-tests  succeed,  and  the  ticket  passes  the hotlist check
-described in the next paragraph,  the  KDC  will  issue  the
-appropriate new ticket.
-
-
-3.3.3.1.  Checking for revoked tickets
-
-     Whenever a  request  is  made  to  the  ticket-granting
-server,  the  presented  ticket(s) is(are) checked against a
-hot-list of tickets which have been canceled.  This hot-list
-might  be implemented by storing a range of issue timestamps
-for "suspect tickets"; if a presented ticket had an authtime
-in  that range, it would be rejected.  In this way, a stolen
-ticket-granting ticket or renewable ticket cannot be used to
-gain  additional  tickets  (renewals  or otherwise) once the
-theft has been reported.  Any normal ticket obtained  before
-it  was  reported  stolen  will still be valid (because they
-require no interaction with the KDC), but only  until  their
-normal expiration time.
-
-     The ciphertext part of the response in the  KRB_TGS_REP
-message is encrypted in the sub-session key from the Authen-
-ticator, if  present,  or  the  session  key  key  from  the
-ticket-granting  ticket.   It  is  not  encrypted  using the
-client's  secret  key.   Furthermore,  the  client's   key's
-expiration  date  and the key version number fields are left
-out since these values are stored along  with  the  client's
-database  record, and that record is not needed to satisfy a
-request based on a ticket-granting ticket.  See section  A.6
-for pseudocode.
-
-3.3.3.2.  Encoding the transited field
-
-     If the identity of  the  server  in  the  TGT  that  is
-presented to the KDC as part of the authentication header is
-that of the ticket-granting service, but the TGT was  issued
-from another realm, the KDC will look up the inter-realm key
-shared with that realm and  use  that  key  to  decrypt  the
-ticket.  If the ticket is valid, then the KDC will honor the
-request, subject to the constraints outlined  above  in  the
-section  describing  the AS exchange.  The realm part of the
-client's identity will be  taken  from  the  ticket-granting
-ticket.   The  name  of  the  realm  that issued the ticket-
-granting ticket will be added to the transited field of  the
-ticket  to  be  issued.  This is accomplished by reading the
-transited field from the ticket-granting  ticket  (which  is
-treated  as an unordered set of realm names), adding the new
-realm to the set, then  constructing  and  writing  out  its
-encoded  (shorthand)  form (this may involve a rearrangement
-of the existing encoding).
-
-
-
-Section 3.3.3.2.           - 30 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-     Note that the ticket-granting service does not add  the
-name  of  its  own realm.  Instead, its responsibility is to
-add the name of the previous realm.  This prevents  a  mali-
-cious Kerberos server from intentionally leaving out its own
-name (it could, however, omit other realms' names).
-
-     The  names  of  neither  the  local   realm   nor   the
-principal's realm are to be included in the transited field.
-They appear elsewhere in the ticket and both  are  known  to
-have  taken part in authenticating the principal.  Since the
-endpoints  are  not  included,  both  local  and  single-hop
-inter-realm  authentication result in a transited field that
-is empty.
-
-     Because the name of each realm transited  is  added  to
-this  field, it might potentially be very long.  To decrease
-the length of this field, its  contents  are  encoded.   The
-initially  supported  encoding  is  optimized for the normal
-case of inter-realm communication: a  hierarchical  arrange-
-ment  of  realms  using  either  domain or X.500 style realm
-names.  This encoding (called DOMAIN-X500-COMPRESS)  is  now
-described.
-
-     Realm names in the transited field are separated  by  a
-",".   The ",", "\", trailing "."s, and leading spaces (" ")
-are special characters, and if they  are  part  of  a  realm
-name,  they must be quoted in the transited field by preced-
-ing them with a "\".
-
-     A realm name ending with a "." is interpreted as  being
-prepended to the previous realm.  For example, we can encode
-traversal of EDU, MIT.EDU,  ATHENA.MIT.EDU,  WASHINGTON.EDU,
-and CS.WASHINGTON.EDU as:
-
-     "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
-
-Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were  end-
-points,  that  they would not be included in this field, and
-we would have:
-
-     "EDU,MIT.,WASHINGTON.EDU"
-
-A realm name beginning with a "/" is  interpreted  as  being
-appended to the previous realm[18].  If it is  to  stand  by
-itself,  then  it  should be preceded by a space (" ").  For
-example, we can encode traversal of /COM/HP/APOLLO, /COM/HP,
-/COM, and /COM/DEC as:
-
-     "/COM,/HP,/APOLLO, /COM/DEC".
-__________________________
-[18] For the purpose of appending, the realm  preceding
-the  first  listed  realm  is considered to be the null
-realm ("").
-
-
-Section 3.3.3.2.           - 31 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-Like the example above, if /COM/HP/APOLLO and  /COM/DEC  are
-endpoints,  they  they  would not be included in this field,
-and we would have:
-
-     "/COM,/HP"
-
-
-     A null subfield preceding or following a ","  indicates
-that  all  realms  between  the  previous realm and the next
-realm have been traversed[19].  Thus,  ","  means  that  all
-realms along the path between the client and the server have
-been traversed. ",EDU, /COM," means  that  that  all  realms
-from the client's realm up to EDU (in a domain style hierar-
-chy) have been traversed, and that everything from /COM down
-to  the  server's  realm  in  an  X.500  style has also been
-traversed.  This could occur if the EDU realm in one hierar-
-chy  shares  an inter-realm key directly with the /COM realm
-in another hierarchy.
-
-3.3.4.  Receipt of KRB_TGS_REP message
-
-When the KRB_TGS_REP is received by the client, it  is  pro-
-cessed  in  the  same  manner  as  the KRB_AS_REP processing
-described above.  The primary difference is that the cipher-
-text  part  of the response must be decrypted using the ses-
-sion key from the ticket-granting  ticket  rather  than  the
-client's secret key.  See section A.7 for pseudocode.
-
-
-3.4.  The KRB_SAFE Exchange
-
-     The KRB_SAFE message may be used by  clients  requiring
-the   ability  to  detect  modifications  of  messages  they
-exchange.  It achieves this by including a keyed  collision-
-proof  checksum  of  the user data and some control informa-
-tion.  The checksum is keyed with an encryption key (usually
-the  last  key negotiated via subkeys, or the session key if
-no negotiation has occured).
-
-3.4.1.  Generation of a KRB_SAFE message
-
-When an application wishes to send a  KRB_SAFE  message,  it
-collects  its  data  and the appropriate control information
-and computes a checksum over them.  The  checksum  algorithm
-should  be  a  keyed one-way hash function (such as the RSA-
-MD5-DES checksum algorithm specified in  section  6.4.5,  or
-the  DES  MAC),  generated  using  the  sub-session  key  if
-present, or the session key.  Different  algorithms  may  be
-__________________________
-[19] For the purpose of  interpreting  null  subfields,
-the  client's  realm  is considered to precede those in
-the transited field, and the  server's  realm  is  con-
-sidered to follow them.
-
-
-Section 3.4.1.             - 32 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-selected by changing  the  checksum  type  in  the  message.
-Unkeyed  or  non-collision-proof  checksums are not suitable
-for this use.
-
-     The  control  information  for  the  KRB_SAFE   message
-includes  both  a  timestamp  and  a  sequence  number.  The
-designer of an application using the KRB_SAFE  message  must
-choose  at  least  one  of  the two mechanisms.  This choice
-should be based on the needs of the application protocol.
-
-     Sequence numbers are useful when all messages sent will
-be  received  by  one's peer.  Connection state is presently
-required to maintain the session  key,  so  maintaining  the
-next  sequence number should not present an additional prob-
-lem.
-
-     If the application protocol  is  expected  to  tolerate
-lost  messages  without  them  being  resent, the use of the
-timestamp is the  appropriate  replay  detection  mechanism.
-Using  timestamps  is  also  the  appropriate  mechanism for
-multi-cast protocols where all of one's peers share a common
-sub-session  key, but some messages will be sent to a subset
-of one's peers.
-
-     After computing the checksum, the client then transmits
-the information and checksum to the recipient in the message
-format specified in section 5.6.1.
-
-3.4.2.  Receipt of KRB_SAFE message
-
-When an application receives a KRB_SAFE message, it verifies
-it  as  follows.   If  any  error  occurs,  an error code is
-reported for use by the application.
-
-     The message is first checked by verifying that the pro-
-tocol  version and type fields match the current version and
-KRB_SAFE,   respectively.    A    mismatch    generates    a
-KRB_AP_ERR_BADVERSION  or  KRB_AP_ERR_MSG_TYPE  error.   The
-application verifies that the checksum used is a  collision-
-proof    keyed    checksum,    and   if   it   is   not,   a
-KRB_AP_ERR_INAPP_CKSUM error is  generated.   The  recipient
-verifies  that the operating system's report of the sender's
-address matches the sender's address in the message, and (if
-a  recipient  address is specified or the recipient requires
-an address) that one of the recipient's addresses appears as
-the  recipient's address in the message.  A failed match for
-either case generates a KRB_AP_ERR_BADADDR error.  Then  the
-timestamp  and  usec  and/or  the sequence number fields are
-checked.   If  timestamp  and  usec  are  expected  and  not
-present,   or   they   are  present  but  not  current,  the
-KRB_AP_ERR_SKEW error is generated.   If  the  server  name,
-along with the client name, time and microsecond fields from
-the  Authenticator  match   any   recently-seen   (sent   or
-received[20] ) such tuples, the KRB_AP_ERR_REPEAT  error  is
-__________________________
-[20] This means that a client and server running on the
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-generated.  If an incorrect sequence number is included,  or
-a   sequence   number  is  expected  but  not  present,  the
-KRB_AP_ERR_BADORDER error is generated.  If neither a  time-
-stamp   and   usec  or  a  sequence  number  is  present,  a
-KRB_AP_ERR_MODIFIED error is generated.  Finally, the check-
-sum  is  computed over the data and control information, and
-if   it   doesn't   match   the   received    checksum,    a
-KRB_AP_ERR_MODIFIED error is generated.
-
-     If all the checks succeed, the application  is  assured
-that the message was generated by its peer and was not modi-
-fied in transit.
-
-3.5.  The KRB_PRIV Exchange
-
-     The KRB_PRIV message may be used by  clients  requiring
-confidentiality  and  the ability to detect modifications of
-exchanged messages.  It achieves this by encrypting the mes-
-sages and adding control information.
-
-3.5.1.  Generation of a KRB_PRIV message
-
-When an application wishes to send a  KRB_PRIV  message,  it
-collects  its  data  and the appropriate control information
-(specified in section 5.7.1)  and  encrypts  them  under  an
-encryption key (usually the last key negotiated via subkeys,
-or the session key if no negotiation has occured).  As  part
-of  the  control  information, the client must choose to use
-either a timestamp or a sequence number (or both);  see  the
-discussion  in section 3.4.1 for guidelines on which to use.
-After the user data and control information  are  encrypted,
-the  client  transmits  the  ciphertext  and some "envelope"
-information to the recipient.
-
-3.5.2.  Receipt of KRB_PRIV message
-
-When an application receives a KRB_PRIV message, it verifies
-it  as  follows.   If  any  error  occurs,  an error code is
-reported for use by the application.
-
-     The message is first checked by verifying that the pro-
-tocol  version and type fields match the current version and
-KRB_PRIV,   respectively.    A    mismatch    generates    a
-KRB_AP_ERR_BADVERSION  or  KRB_AP_ERR_MSG_TYPE  error.   The
-application then decrypts the ciphertext and  processes  the
-resultant  plaintext.   If decryption shows the data to have
-been modified,  a  KRB_AP_ERR_BAD_INTEGRITY  error  is  gen-
-erated.   The recipient verifies that the operating system's
-report of the sender's address matches the sender's  address
-__________________________
-same  host and communicating with one another using the
-KRB_SAFE messages should  not  share  a  common  replay
-cache to detect KRB_SAFE replays.
-
-
-
-Section 3.5.2.             - 34 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-in the message, and (if a recipient address is specified  or
-the   recipient   requires  an  address)  that  one  of  the
-recipient's addresses appears as the recipient's address  in
-the  message.   A  failed  match for either case generates a
-KRB_AP_ERR_BADADDR  error.   Then  the  timestamp  and  usec
-and/or the sequence number fields are checked.  If timestamp
-and usec are expected and not present, or they  are  present
-but  not current, the KRB_AP_ERR_SKEW error is generated. If
-the server name,  along  with  the  client  name,  time  and
-microsecond   fields   from   the  Authenticator  match  any
-recently-seen such tuples, the  KRB_AP_ERR_REPEAT  error  is
-generated.   If an incorrect sequence number is included, or
-a  sequence  number  is  expected  but  not   present,   the
-KRB_AP_ERR_BADORDER  error is generated.  If neither a time-
-stamp  and  usec  or  a  sequence  number  is   present,   a
-KRB_AP_ERR_MODIFIED error is generated.
-
-     If all the checks succeed, the application  can  assume
-the  message  was  generated  by  its peer, and was securely
-transmitted (without intruders able to see  the  unencrypted
-contents).
-
-3.6.  The KRB_CRED Exchange
-
-     The KRB_CRED message may be used by  clients  requiring
-the  ability  to  send Kerberos credentials from one host to
-another.  It achieves this by sending the  tickets  together
-with  encrypted  data  containing the session keys and other
-information associated with the tickets.
-
-3.6.1.  Generation of a KRB_CRED message
-
-When an application wishes to send  a  KRB_CRED  message  it
-first (using the KRB_TGS exchange) obtains credentials to be
-sent to the remote host.  It then constructs a KRB_CRED mes-
-sage  using  the  ticket or tickets so obtained, placing the
-session key needed to use each ticket in the  key  field  of
-the corresponding KrbCredInfo sequence of the encrypted part
-of the the KRB_CRED message.
-
-     Other  information  associated  with  each  ticket  and
-obtained  during  the KRB_TGS exchange is also placed in the
-corresponding KrbCredInfo sequence in the encrypted part  of
-the KRB_CRED message.  The current time and, if specifically
-required by the application the  nonce,  s-address,  and  r-
-address  fields,  are  placed  in  the encrypted part of the
-KRB_CRED message which is then encrypted under an encryption
-key previosuly exchanged in the KRB_AP exchange (usually the
-last key negotiated via subkeys, or the session  key  if  no
-negotiation has occured).
-
-3.6.2.  Receipt of KRB_CRED message
-
-When an application receives a KRB_CRED message, it verifies
-
-
-Section 3.6.2.             - 35 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-it.   If any error occurs, an error code is reported for use
-by the application.  The message  is  verified  by  checking
-that  the protocol version and type fields match the current
-version and KRB_CRED, respectively.  A mismatch generates  a
-KRB_AP_ERR_BADVERSION  or  KRB_AP_ERR_MSG_TYPE  error.   The
-application then decrypts the ciphertext and  processes  the
-resultant  plaintext.   If decryption shows the data to have
-been modified,  a  KRB_AP_ERR_BAD_INTEGRITY  error  is  gen-
-erated.
-
-     If present or required, the recipient verifies that the
-operating  system's  report  of the sender's address matches
-the sender's address in the message, and  that  one  of  the
-recipient's  addresses appears as the recipient's address in
-the message.  A failed match for  either  case  generates  a
-KRB_AP_ERR_BADADDR  error.   The  timestamp  and usec fields
-(and the nonce field if required) are checked next.  If  the
-timestamp  and usec are not present, or they are present but
-not current, the KRB_AP_ERR_SKEW error is generated.
-
-     If all the checks succeed, the application stores  each
-of  the  new  tickets  in its ticket cache together with the
-session key  and  other  information  in  the  corresponding
-KrbCredInfo sequence from the encrypted part of the KRB_CRED
-message.
-
-4.  The Kerberos Database
-
-The Kerberos server must have access to a database  contain-
-ing  the principal identifiers and secret keys of principals
-to be authenticated[21].
-
-4.1.  Database contents
-
-A database entry  should  contain  at  least  the  following
-fields:
-
-Field                Value
-
-name                 Principal's                    identif-
-ier
-key                  Principal's secret key
-p_kvno               Principal's key version
-max_life             Maximum lifetime for Tickets
-__________________________
-[21] The implementation of the Kerberos server need not
-combine  the  database  and  the  server  on  the  same
-machine; it is feasible to store the principal database
-in, say, a network name service, as long as the entries
-stored therein are protected  from  disclosure  to  and
-modification  by  unauthorized  parties.   However,  we
-recommend against such strategies,  as  they  can  make
-system management and threat analysis quite complex.
-
-
-Section 4.1.               - 36 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-max_renewable_life   Maximum total lifetime for renewable Tickets
-
-The name field is an encoding of the principal's identifier.
-The  key  field contains an encryption key.  This key is the
-principal's secret key.  (The key can  be  encrypted  before
-storage  under a Kerberos "master key" to protect it in case
-the database is compromised but the master key is  not.   In
-that case, an extra field must be added to indicate the mas-
-ter key version used, see below.) The p_kvno  field  is  the
-key  version  number  of  the  principal's  secret key.  The
-max_life field contains the maximum allowable lifetime (end-
-time  - starttime) for any Ticket issued for this principal.
-The max_renewable_life field contains the maximum  allowable
-total  lifetime  for  any  renewable  Ticket issued for this
-principal.  (See section 3.1 for a description of how  these
-lifetimes  are  used  in determining the lifetime of a given
-Ticket.)
-
-     A server may provide KDC service to several realms,  as
-long  as the database representation provides a mechanism to
-distinguish between principal records with identifiers which
-differ only in the realm name.
-
-     When an application server's key changes, if the change
-is  routine  (i.e.  not  the result of disclosure of the old
-key), the old key should be retained by the server until all
-tickets  that  had  been issued using that key have expired.
-Because of this, it is  possible  for  several  keys  to  be
-active  for  a  single principal.  Ciphertext encrypted in a
-principal's key is always tagged with the version of the key
-that was used for encryption, to help the recipient find the
-proper key for decryption.
-
-     When more than one key is active for a particular prin-
-cipal,  the  principal will have more than one record in the
-Kerberos database.  The keys and key  version  numbers  will
-differ  between  the  records (the rest of the fields may or
-may not be the same). Whenever Kerberos issues a ticket,  or
-responds  to  a request for initial authentication, the most
-recent key (known by the Kerberos server) will be  used  for
-encryption.   This  is  the key with the highest key version
-number.
-
-4.2.  Additional fields
-
-Project Athena's KDC implementation uses  additional  fields
-in its database:
-
-Field        Value
-
-K_kvno       Kerberos' key version
-expiration   Expiration date for entry
-attributes   Bit field of attributes
-mod_date     Timestamp of last modification
-
-
-Section 4.2.               - 37 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-mod_name     Modifying principal's identifier
-
-
-The K_kvno field indicates the key version of  the  Kerberos
-master  key  under  which  the  principal's  secret  key  is
-encrypted.
-
-     After an entry's expiration date has  passed,  the  KDC
-will  return an error to any client attempting to gain tick-
-ets as or for the principal.  (A database may want to  main-
-tain  two  expiration  dates: one for the principal, and one
-for the principal's current key.  This allows password aging
-to  work  independently  of the principal's expiration date.
-However, due to the limited space in the responses, the  KDC
-must  combine  the  key  expiration and principal expiration
-date into a single value called "key_exp", which is used  as
-a hint to the user to take administrative action.)
-
-     The attributes field is a bitfield used to  govern  the
-operations  involving  the  principal.   This field might be
-useful in conjunction with user registration procedures, for
-site-specific   policy   implementations   (Project   Athena
-currently uses it for their user registration  process  con-
-trolled  by the system-wide database service, Moira [9]), to
-identify whether a principal can play the role of  a  client
-or  server  or both, to note whether a server is appropriate
-trusted to recieve credentials delegated by a client, or  to
-identify the "string to key" conversion algorithm used for a
-principal's key[22].  Other bits are used to  indicate  that
-certain  ticket  options  should  not  be allowed in tickets
-encrypted under a principal's key (one bit each):   Disallow
-issuing  postdated  tickets,  disallow  issuing  forwardable
-tickets, disallow issuing tickets based on  TGT  authentica-
-tion,  disallow  issuing renewable tickets, disallow issuing
-proxiable tickets, and disallow issuing  tickets  for  which
-the principal is the server.
-
-     The mod_date field contains the time of last  modifica-
-tion  of the entry, and the mod_name field contains the name
-of the principal which last modified the entry.
-
-4.3.  Frequently Changing Fields
-
-     Some KDC implementations may wish to maintain the  last
-time  that  a  request  was  made by a particular principal.
-Information that might be maintained includes  the  time  of
-the  last  request,  the  time  of  the  last  request for a
-ticket-granting ticket, the  time  of  the  last  use  of  a
-ticket-granting  ticket,  or  other times.  This information
-can then be returned to the user in the last-req field  (see
-__________________________
-[22] See the discussion of the padata field in  section
-5.4.2 for details on why this can be useful.
-
-
-Section 4.3.               - 38 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-section 5.2).
-
-     Other frequently changing information that can be main-
-tained  is  the  latest expiration time for any tickets that
-have been issued using each key.  This field would  be  used
-to indicate how long old keys must remain valid to allow the
-continued use of outstanding tickets.
-
-4.4.  Site Constants
-
-     The KDC implementation should have the following confi-
-gurable  constants  or options, to allow an administrator to
-make and enforce policy decisions:
-
-+  The minimum supported lifetime (used to determine whether
-   the  KDC_ERR_NEVER_VALID error should be returned).  This
-   constant  should  reflect  reasonable   expectations   of
-   round-trip  time  to the KDC, encryption/decryption time,
-   and processing time by the client and target server,  and
-   it should allow for a minimum "useful" lifetime.
-
-+  The maximum allowable total  (renewable)  lifetime  of  a
-   ticket (renew_till - starttime).
-
-+  The maximum allowable lifetime of  a  ticket  (endtime  -
-   starttime).
-
-+  Whether to allow the issue of tickets with empty  address
-   fields  (including the ability to specify that such tick-
-   ets may only be issued  if  the  request  specifies  some
-   authorization_data).
-
-+  Whether proxiable, forwardable, renewable or post-datable
-   tickets are to be issued.
-
-
-5.  Message Specifications
-
-     The following sections describe the exact contents  and
-encoding  of  protocol messages and objects.  The ASN.1 base
-definitions are presented  in  the  first  subsection.   The
-remaining  subsections specify the protocol objects (tickets
-and authenticators) and messages.  Specification of  encryp-
-tion  and  checksum  techniques,  and  the fields related to
-them, appear in section 6.
-
-5.1.  ASN.1 Distinguished Encoding Representation
-
-     All uses of  ASN.1  in  Kerberos  shall  use  the  Dis-
-tinguished  Encoding  Representation of the data elements as
-described in the X.509 specification, section 8.7  [10].
-
-
-
-
-
-Section 5.1.               - 39 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-5.2.  ASN.1 Base Definitions
-
-     The following ASN.1 base definitions are  used  in  the
-rest  of this section.  Note that since the underscore char-
-acter (_) is not permitted in ASN.1 names, the hyphen (-) is
-used in its place for the purposes of ASN.1 names.
-
-Realm ::=           GeneralString
-PrincipalName ::=   SEQUENCE {
-                    name-type[0]     INTEGER,
-                    name-string[1]   SEQUENCE OF GeneralString
-}
-
-
-Kerberos realms are encoded as GeneralStrings.  Realms shall
-not  contain  a  character  with the code 0 (the ASCII NUL).
-Most realms  will  usually  consist  of  several  components
-separated  by  periods  (.), in the style of Internet Domain
-Names, or separated by slashes (/) in  the  style  of  X.500
-names.   Acceptable  forms  for realm names are specified in
-section 7.  A PrincipalName is  a  typed  sequence  of  com-
-ponents consisting of the following sub-fields:
-
-name-type This field specifies the type of  name  that  fol-
-          lows.   Pre-defined  values  for  this  field  are
-          specified in section 7.2.  The name-type should be
-          treated as a hint.  Ignoring the name type, no two
-          names can be the same (i.e. at least  one  of  the
-          components,  or  the  realm,  must  be different).
-          This constraint may be eliminated in the future.
-
-name-stringThis field encodes a sequence of components  that
-          form  a name, each component encoded as a General-
-          String.  Taken together,  a  PrincipalName  and  a
-          Realm  form  a principal identifier.  Most Princi-
-          palNames will have only a  few  components  (typi-
-          cally one or two).
-
-
-
-        KerberosTime ::=   GeneralizedTime
-                           -- Specifying UTC time zone (Z)
-
-
-     The timestamps used in Kerberos are encoded as General-
-izedTimes.   An encoding shall specify the UTC time zone (Z)
-and  shall  not  include  any  fractional  portions  of  the
-seconds.   It  further  shall  not  include  any separators.
-Example: The only valid format for UTC time  6  minutes,  27
-seconds after 9 pm on 6 November 1985 is 19851106210627Z.
-
- HostAddress ::=     SEQUENCE  {
-                     addr-type[0]             INTEGER,
-                     address[1]               OCTET STRING
-
-
-Section 5.2.               - 40 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
- }
-
- HostAddresses ::=   SEQUENCE OF SEQUENCE {
-                     addr-type[0]             INTEGER,
-                     address[1]               OCTET STRING
- }
-
-
-     The host adddress encodings consists of two fields:
-
-addr-type This field  specifies the  type  of  address  that
-          follows.   Pre-defined  values  for this field are
-          specified in section 8.1.
-
-
-address   This field encodes a single address of type  addr-
-          type.
-
-The two forms differ slightly. HostAddress contains  exactly
-one  address;  HostAddresses contains a sequence of possibly
-many addresses.
-
-AuthorizationData ::=   SEQUENCE OF SEQUENCE {
-                        ad-type[0]               INTEGER,
-                        ad-data[1]               OCTET STRING
-}
-
-
-ad-data   This  field  contains  authorization  data  to  be
-          interpreted   according   to   the  value  of  the
-          corresponding ad-type field.
-
-ad-type   This field specifies the format  for  the  ad-data
-          subfield.   All  negative  values are reserved for
-          local use.  Non-negative values are  reserved  for
-          registered use.
-
-                APOptions ::=   BIT STRING {
-                                reserved(0),
-                                use-session-key(1),
-                                mutual-required(2)
-                }
-
-
-          TicketFlags ::=   BIT STRING {
-                            reserved(0),
-                            forwardable(1),
-                            forwarded(2),
-                            proxiable(3),
-                            proxy(4),
-                            may-postdate(5),
-                            postdated(6),
-                            invalid(7),
-                            renewable(8),
-                            initial(9),
-
-
-Section 5.2.               - 41 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-                            pre-authent(10),
-                            hw-authent(11),
-                            transited-policy-checked(12),
-                            ok-as-delegate(13)
-          }
-
-
-           KDCOptions ::=   BIT STRING {
-                            reserved(0),
-                            forwardable(1),
-                            forwarded(2),
-                            proxiable(3),
-                            proxy(4),
-                            allow-postdate(5),
-                            postdated(6),
-                            unused7(7),
-                            renewable(8),
-                            unused9(9),
-                            unused10(10),
-                            unused11(11),
-                            unused12(12),
-                            unused13(13),
-                            disable-transited-check(26),
-                            renewable-ok(27),
-                            enc-tkt-in-skey(28),
-                            renew(30),
-                            validate(31)
-           }
-
-          ASN.1 Bit strings have a length and a value.  When
-          used  in  Kerberos for the APOptions, TicketFlags,
-          and KDCOptions, the length of the  bit  string  on
-          generated  values  should be the smallest multiple
-          of 32 bits needed to include the highest order bit
-          that is set (1), but in no case less than 32 bits.
-          Implementations  should  accept  values   of   bit
-          strings of any length and treat the value of flags
-          cooresponding to bits beyond the end  of  the  bit
-          string as if the bit were reset (0).  Comparisonof
-          bit strings of different length should  treat  the
-          smaller  string  as  if  it were padded with zeros
-          beyond the high order bits to the  length  of  the
-          longer string[23].
-
-__________________________
-[23] Warning for implementations that unpack and repack
-data  structures during the generation and verification
-of embedded checksums: Because any checksums applied to
-data  structures  must  be checked against the original
-data the length of bit strings must be preserved within
-a  data  structure  between the time that a checksum is
-generated through transmission to  the  time  that  the
-checksum is verified.
-
-
-
-Section 5.2.               - 42 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-         LastReq ::=   SEQUENCE OF SEQUENCE {
-                       lr-type[0]               INTEGER,
-                       lr-value[1]              KerberosTime
-         }
-
-
-lr-type   This field indicates how  the  following  lr-value
-          field is to be interpreted.  Negative values indi-
-          cate that the information  pertains  only  to  the
-          responding server.  Non-negative values pertain to
-          all servers for the realm.
-
-          If the lr-type field is zero (0), then no informa-
-          tion is conveyed by the lr-value subfield.  If the
-          absolute value of the lr-type field  is  one  (1),
-          then  the  lr-value  subfield  is the time of last
-          initial request for a TGT.  If it is two (2), then
-          the  lr-value subfield is the time of last initial
-          request.  If it is three (3),  then  the  lr-value
-          subfield  is  the  time  of  issue  for the newest
-          ticket-granting ticket used.  If it is  four  (4),
-          then the lr-value subfield is the time of the last
-          renewal.  If it is five  (5),  then  the  lr-value
-          subfield  is  the  time  of  last  request (of any
-          type).
-
-
-lr-value  This field contains the time of the last  request.
-          The time must be interpreted according to the con-
-          tents of the accompanying lr-type subfield.
-
-     See section 6 for the definitions of  Checksum,  Check-
-sumType,  EncryptedData,  EncryptionKey, EncryptionType, and
-KeyType.
-
-
-5.3.  Tickets and Authenticators
-
-     This section describes the format and encryption param-
-eters  for  tickets  and  authenticators.   When a ticket or
-authenticator is  included  in  a  protocol  message  it  is
-treated as an opaque object.
-
-5.3.1.  Tickets
-
-     A ticket is a record that helps a  client  authenticate
-to a service.  A Ticket contains the following information:
-
-Ticket ::=                    [APPLICATION 1] SEQUENCE {
-                              tkt-vno[0]                   INTEGER,
-                              realm[1]                     Realm,
-                              sname[2]                     PrincipalName,
-                              enc-part[3]                  EncryptedData
-}
-
-
-Section 5.3.1.             - 43 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
--- Encrypted part of ticket
-EncTicketPart ::= [APPLICATION 3] SEQUENCE {
-                  flags[0]                     TicketFlags,
-                  key[1]                       EncryptionKey,
-                  crealm[2]                    Realm,
-                  cname[3]                     PrincipalName,
-                  transited[4]                 TransitedEncoding,
-                  authtime[5]                  KerberosTime,
-                  starttime[6]                 KerberosTime OPTIONAL,
-                  endtime[7]                   KerberosTime,
-                  renew-till[8]                KerberosTime OPTIONAL,
-                  caddr[9]                     HostAddresses OPTIONAL,
-                  authorization-data[10]       AuthorizationData OPTIONAL
-}
--- encoded Transited field
-TransitedEncoding ::=   SEQUENCE {
-                        tr-type[0]             INTEGER, -- must be registered
-                        contents[1]            OCTET STRING
-}
-
-The encoding of EncTicketPart is encrypted in the key shared
-by  Kerberos  and  the end server (the server's secret key).
-See section 6 for the format of the ciphertext.
-
-tkt-vno   This field specifies the version  number  for  the
-          ticket  format.   This  document describes version
-          number 5.
-
-
-realm     This field  specifies  the  realm  that  issued  a
-          ticket.  It also serves to identify the realm part
-          of the server's  principal  identifier.   Since  a
-          Kerberos server can only issue tickets for servers
-          within its realm, the two will always  be  identi-
-          cal.
-
-
-sname     This field specifies the name part of the server's
-          identity.
-
-
-enc-part  This field holds the  encrypted  encoding  of  the
-          EncTicketPart sequence.
-
-
-flags     This field indicates which of various options were
-          used  or requested when the ticket was issued.  It
-          is a bit-field, where  the  selected  options  are
-          indicated  by  the  bit  being  set  (1),  and the
-          unselected options and reserved fields being reset
-          (0).   Bit  0  is  the  most significant bit.  The
-          encoding of the bits is specified in section  5.2.
-          The  flags  are  described in more detail above in
-          section 2.  The meanings of the flags are:
-
-
-Section 5.3.1.             - 44 -    Expires 11 January 1998
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-     Bit(s)      Name         Description
-
-     0           RESERVED
-                              Reserved for future  expansion  of  this
-                              field.
-
-     1           FORWARDABLE 
-                              The FORWARDABLE flag  is  normally  only
-                              interpreted  by  the  TGS,  and  can  be
-                              ignored by end servers.  When set,  this
-                              flag  tells  the  ticket-granting server
-                              that it is OK to  issue  a  new  ticket-
-                              granting ticket with a different network
-                              address based on the presented ticket.
-
-     2           FORWARDED   
-                              When set, this flag indicates  that  the
-                              ticket  has either been forwarded or was
-                              issued based on authentication involving
-                              a forwarded ticket-granting ticket.
-
-     3           PROXIABLE   
-                              The  PROXIABLE  flag  is  normally  only
-                              interpreted  by  the  TGS,  and  can  be
-                              ignored by end servers.   The  PROXIABLE
-                              flag  has an interpretation identical to
-                              that of  the  FORWARDABLE  flag,  except
-                              that   the   PROXIABLE  flag  tells  the
-                              ticket-granting server  that  only  non-
-                              ticket-granting  tickets  may  be issued
-                              with different network addresses.
-
-     4           PROXY       
-                              When set, this  flag  indicates  that  a
-                              ticket is a proxy.
-
-     5           MAY-POSTDATE 
-                              The MAY-POSTDATE flag is  normally  only
-                              interpreted  by  the  TGS,  and  can  be
-                              ignored by end servers.  This flag tells
-                              the  ticket-granting server that a post-
-                              dated ticket may be issued based on this
-                              ticket-granting ticket.
-
-     6           POSTDATED    
-                              This flag indicates that this ticket has
-                              been  postdated.   The  end-service  can
-                              check the authtime field to see when the
-                              original authentication occurred.
-
-     7           INVALID      
-                              This flag indicates  that  a  ticket  is
-                              invalid, and it must be validated by the
-                              KDC  before  use.   Application  servers
-                              must reject tickets which have this flag
-                              set.
-
-
-
-
-
-
-
-
-Section 5.3.1.             - 45 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-     8           RENEWABLE                        
-                              The  RENEWABLE  flag  is  normally  only
-                              interpreted  by the TGS, and can usually
-                              be ignored by end servers (some particu-
-                              larly careful servers may wish to disal-
-                              low  renewable  tickets).   A  renewable
-                              ticket  can be used to obtain a replace-
-                              ment ticket  that  expires  at  a  later
-                              date.
-
-     9           INITIAL                    
-                              This flag indicates that this ticket was
-                              issued  using  the  AS protocol, and not
-                              issued  based   on   a   ticket-granting
-                              ticket.
-
-     10          PRE-AUTHENT              
-                              This flag indicates that during  initial
-                              authentication, the client was authenti-
-                              cated by the KDC  before  a  ticket  was
-                              issued.    The   strength  of  the  pre-
-                              authentication method is not  indicated,
-                              but is acceptable to the KDC.
-
-     11          HW-AUTHENT                    
-                              This flag indicates  that  the  protocol
-                              employed   for   initial  authentication
-                              required the use of hardware expected to
-                              be possessed solely by the named client.
-                              The hardware  authentication  method  is
-                              selected  by the KDC and the strength of
-                              the method is not indicated.
-
-
-
-
-Section 5.3.1.             - 46 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-     12           TRANSITED   This flag indicates that the KDC for the
-             POLICY-CHECKED   realm has checked the transited field
-			      against a realm defined policy for
-			      trusted certifiers.  If this flag is
-			      reset (0), then the application server
-			      must check the transited field itself,
-			      and if unable to do so it must reject
-			      the authentication.  If the flag is set
-			      (1) then the application server may skip
-			      its own validation of the transited
-			      field, relying on the validation
-			      performed by the KDC.  At its option the
-			      application server may still apply its
-			      own validation based on a separate
-			      policy for acceptance.
-
-Section 5.3.1.             - 47 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-     13      OK-AS-DELEGATE   This flag indicates that the server (not
-			      the client) specified in the ticket has
-			      been determined by policy of the realm
-			      to be a suitable recipient of
-			      delegation.  A client can use the
-			      presence of this flag to help it make a
-			      decision whether to delegate credentials
-			      (either grant a proxy or a forwarded
-			      ticket granting ticket) to this server.
-			      The client is free to ignore the value
-			      of this flag.  When setting this flag,
-			      an administrator should consider the
-			      security and placement of the server on
-			      which the service will run, as well as
-			      whether the service requires the use of
-			      delegated credentials.
-
-
-
-
-Section 5.3.1.             - 48 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-     14          ANONYMOUS                
-                              This flag indicates that  the  principal
-                              named in the ticket is a generic princi-
-                              pal for the realm and does not  identify
-                              the  individual  using  the ticket.  The
-                              purpose  of  the  ticket  is   only   to
-                              securely  distribute  a session key, and
-                              not to identify  the  user.   Subsequent
-                              requests  using the same ticket and ses-
-                              sion may be  considered  as  originating
-                              from  the  same  user, but requests with
-                              the same username but a different ticket
-                              are  likely  to originate from different
-                              users.
-
-     15-31       RESERVED                
-                              Reserved for future use.
-
-
-
-key       This field  exists  in  the  ticket  and  the  KDC
-          response  and is used to pass the session key from
-          Kerberos to the application server and the client.
-          The field's encoding is described in section 6.2.
-
-crealm    This field contains the name of the realm in which
-          the  client  is  registered  and  in which initial
-          authentication took place.
-
-
-cname     This field contains the name part of the  client's
-          principal identifier.
-
-
-transited This field lists the names of the Kerberos  realms
-          that  took part in authenticating the user to whom
-          this ticket was issued.  It does not  specify  the
-          order  in  which  the  realms were transited.  See
-          section 3.3.3.2 for  details  on  how  this  field
-          encodes the traversed realms.
-
-
-authtime  This field indicates the time of initial authenti-
-          cation for the named principal.  It is the time of
-          issue for the original ticket on which this ticket
-          is based.  It is included in the ticket to provide
-          additional information to the end service, and  to
-          provide  the necessary information for implementa-
-          tion of a `hot list' service at the KDC.   An  end
-          service that is particularly paranoid could refuse
-          to accept tickets for which the initial  authenti-
-          cation occurred "too far" in the past.
-
-          This  field  is  also  returned  as  part  of  the
-          response  from  the KDC.  When returned as part of
-          the    response    to    initial    authentication
-
-
-Section 5.3.1.             - 49 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-          (KRB_AS_REP), this is the current time on the Ker-
-          beros server[24].
-
-
-starttime This field in the ticket specifies the time  after
-          which the ticket is valid.  Together with endtime,
-          this field specifies the life of the  ticket.   If
-          it  is absent from the ticket, its value should be
-          treated as that of the authtime field.
-
-
-endtime   This field  contains  the  time  after  which  the
-          ticket  will not be honored (its expiration time).
-          Note that individual services may place their  own
-          limits  on  the  life  of  a ticket and may reject
-          tickets which have not yet expired.  As such, this
-          is  really  an  upper bound on the expiration time
-          for the ticket.
-
-
-renew-tillThis field is only present in  tickets  that  have
-          the  RENEWABLE  flag  set  in the flags field.  It
-          indicates the maximum endtime that may be included
-          in  a  renewal.  It can be thought of as the abso-
-          lute expiration time for the ticket, including all
-          renewals.
-
-
-caddr     This field in a ticket contains zero (if  omitted)
-          or  more  (if  present) host addresses.  These are
-          the addresses from which the ticket can  be  used.
-          If  there are no addresses, the ticket can be used
-          from any location.  The decision  by  the  KDC  to
-          issue  or by the end server to accept zero-address
-          tickets is a policy decision and is  left  to  the
-          Kerberos  and end-service administrators; they may
-          refuse to issue or accept such tickets.  The  sug-
-          gested  and  default policy, however, is that such
-          tickets will only be issued or accepted when addi-
-          tional  information  that  can be used to restrict
-          the  use  of  the  ticket  is  included   in   the
-          authorization_data  field.   Such  a  ticket  is a
-          capability.
-
-          Network addresses are included in  the  ticket  to
-          make  it  harder  for  an  attacker  to use stolen
-          credentials.  Because the session key is not  sent
-          over  the  network in cleartext, credentials can't
-__________________________
-[24] It is NOT recommended that this time value be used
-to adjust the workstation's clock since the workstation
-cannot reliably determine that such a KRB_AS_REP  actu-
-ally came from the proper KDC in a timely manner.
-
-
-Section 5.3.1.             - 50 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-          be stolen simply by listening to the  network;  an
-          attacker  has  to  gain  access to the session key
-          (perhaps   through   operating   system   security
-          breaches  or a careless user's unattended session)
-          to make use of stolen tickets.
-
-          It is important to note that the  network  address
-          from  which  a  connection  is  received cannot be
-          reliably determined.  Even  if  it  could  be,  an
-          attacker who has compromised the client's worksta-
-          tion  could  use  the  credentials   from   there.
-          Including the network addresses only makes it more
-          difficult, not impossible, for an attacker to walk
-          off with stolen credentials and then use them from
-          a "safe" location.
-
-
-authorization-data
-          The  authorization-data  field  is  used  to  pass
-          authorization  data  from  the  principal on whose
-          behalf a ticket was issued to the application ser-
-          vice.   If no authorization data is included, this
-          field will be left out.  Experience has shown that
-          the  name  of  this field is confusing, and that a
-          better name for this field would be  restrictions.
-          Unfortunately,  it  is  not possible to change the
-          name of this field at this time.
-
-          This field contains restrictions on any  authority
-          obtained  on the bases of authentication using the
-          ticket.  It  is  possible  for  any  principal  in
-          posession  of  credentials  to  add entries to the
-          authorization  data  field  since  these   entries
-          further restrict what can be done with the ticket.
-          Such additions can be made by specifying the addi-
-          tional  entries when a new ticket is obtained dur-
-          ing the TGS exchange, or they may be added  during
-          chained  delegation  using  the authorization data
-          field of the authenticator.
-
-          Because entries may be added to this field by  the
-          holder of credentials, it is not allowable for the
-          presence of an entry  in  the  authorization  data
-          field  of  a  ticket to amplify the priveleges one
-          would obtain from using a ticket.
-
-          The data in this field may be specific to the  end
-          service;  the field will contain the names of ser-
-          vice specific objects, and  the  rights  to  those
-          objects.   The  format for this field is described
-          in section 5.2.  Although  Kerberos  is  not  con-
-          cerned with the format of the contents of the sub-
-          fields, it does carry type information (ad-type).
-
-
-
-Section 5.3.1.             - 51 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-          By using the authorization_data field, a principal
-          is  able  to  issue  a  proxy  that is valid for a
-          specific purpose.  For example, a  client  wishing
-          to  print a file can obtain a file server proxy to
-          be passed to the print server.  By specifying  the
-          name  of the file in the authorization_data field,
-          the file server knows that the  print  server  can
-          only  use  the  client's rights when accessing the
-          particular file to be printed.
-
-          A separate service providing providing  authoriza-
-          tion  or  certifying group membership may be built
-          using the authorization-data field.  In this case,
-          the entity granting authorization (not the author-
-          ized entity), obtains a ticket  in  its  own  name
-          (e.g.  the  ticket  is  issued  in  the  name of a
-          privelege server), and this entity  adds  restric-
-          tions  on its own authority and delegates the res-
-          tricted authority through a proxy to  the  client.
-          The  client  would then present this authorization
-          credential to the  application  server  separately
-          from the authentication exchange.
-
-          Similarly, if one specifies the authorization-data
-          field  of  a  proxy  and leaves the host addresses
-          blank, the resulting ticket and session key can be
-          treated  as  a  capability.  See [7] for some sug-
-          gested uses of this field.
-
-          The authorization-data field is optional and  does
-          not have to be included in a ticket.
-
-
-5.3.2.  Authenticators
-
-     An authenticator is a record sent with a  ticket  to  a
-server  to  certify the client's knowledge of the encryption
-key in the ticket, to help the server detect replays, and to
-help  choose a "true session key" to use with the particular
-session.  The encoding is encrypted in the ticket's  session
-key shared by the client and the server:
-
--- Unencrypted authenticator
-Authenticator ::= [APPLICATION 2] SEQUENCE  {
-                  authenticator-vno[0]          INTEGER,
-                  crealm[1]                     Realm,
-                  cname[2]                      PrincipalName,
-                  cksum[3]                      Checksum OPTIONAL,
-                  cusec[4]                      INTEGER,
-                  ctime[5]                      KerberosTime,
-                  subkey[6]                     EncryptionKey OPTIONAL,
-                  seq-number[7]                 INTEGER OPTIONAL,
-                  authorization-data[8]         AuthorizationData OPTIONAL
-}
-
-
-
-Section 5.3.2.             - 52 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-authenticator-vno
-          This field specifies the version  number  for  the
-          format of the authenticator.  This document speci-
-          fies version 5.
-
-
-crealm and cname
-          These fields are the same as those  described  for
-          the ticket in section 5.3.1.
-
-
-cksum     This field contains a checksum of the the applica-
-          tion data that accompanies the KRB_AP_REQ.
-
-
-cusec     This field contains the microsecond  part  of  the
-          client's timestamp.  Its value (before encryption)
-          ranges from 0 to 999999.  It often  appears  along
-          with  ctime.   The two fields are used together to
-          specify a reasonably accurate timestamp.
-
-
-ctime     This  field  contains  the  current  time  on  the
-          client's host.
-
-
-subkey    This field contains the  client's  choice  for  an
-          encryption key which is to be used to protect this
-          specific application session.  Unless an  applica-
-          tion  specifies  otherwise,  if this field is left
-          out the session key from the ticket will be used.
-
-seq-numberThis optional field includes the initial  sequence
-          number to be used by the KRB_PRIV or KRB_SAFE mes-
-          sages when sequence numbers  are  used  to  detect
-          replays  (It  may  also  be  used  by  application
-          specific messages).  When included in the  authen-
-          ticator  this field specifies the initial sequence
-          number for messages from the client to the server.
-          When  included  in the AP-REP message, the initial
-          sequence number is  that  for  messages  from  the
-          server  to  the  client.  When used in KRB_PRIV or
-          KRB_SAFE messages, it is incremented by one  after
-          each message is sent.
-
-          For sequence numbers  to  adequately  support  the
-          detection of replays they should be non-repeating,
-          even across connection  boundaries.   The  initial
-          sequence  number  should  be  random and uniformly
-          distributed across  the  full  space  of  possible
-          sequence  numbers, so that it cannot be guessed by
-          an attacker and so  that  it  and  the  successive
-          sequence numbers do not repeat other sequences.
-
-
-
-Section 5.3.2.             - 53 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-authorization-data
-          This field is the same as described for the ticket
-          in  section  5.3.1.   It is optional and will only
-          appear when  additional  restrictions  are  to  be
-          placed  on  the use of a ticket, beyond those car-
-          ried in the ticket itself.
-
-5.4.  Specifications for the AS and TGS exchanges
-
-     This section specifies the format of the messages  used
-in  the exchange between the client and the Kerberos server.
-The format of possible error  messages  appears  in  section
-5.9.1.
-
-5.4.1.  KRB_KDC_REQ definition
-
-     The  KRB_KDC_REQ  message  has  no  type  of  its  own.
-Instead,  its  type  is  one  of  KRB_AS_REQ  or KRB_TGS_REQ
-depending on whether the request is for an initial ticket or
-an  additional  ticket.  In either case, the message is sent
-from the client to  the  Authentication  Server  to  request
-credentials for a service.
-
-     The message fields are:
-
-AS-REQ ::=         [APPLICATION 10] KDC-REQ
-TGS-REQ ::=        [APPLICATION 12] KDC-REQ
-
-KDC-REQ ::=        SEQUENCE {
-                   pvno[1]            INTEGER,
-                   msg-type[2]        INTEGER,
-                   padata[3]          SEQUENCE OF PA-DATA OPTIONAL,
-                   req-body[4]        KDC-REQ-BODY
-}
-
-PA-DATA ::=        SEQUENCE {
-                   padata-type[1]     INTEGER,
-                   padata-value[2]    OCTET STRING,
-                                      -- might be encoded AP-REQ
-}
-
-KDC-REQ-BODY ::=   SEQUENCE {
-                    kdc-options[0]         KDCOptions,
-                    cname[1]               PrincipalName OPTIONAL,
-                                           -- Used only in AS-REQ
-                    realm[2]               Realm, -- Server's realm
-                                           -- Also client's in AS-REQ
-                    sname[3]               PrincipalName OPTIONAL,
-                    from[4]                KerberosTime OPTIONAL,
-                    till[5]                KerberosTime OPTIONAL,
-                    rtime[6]               KerberosTime OPTIONAL,
-                    nonce[7]               INTEGER,
-                    etype[8]               SEQUENCE OF INTEGER, 
-                                           -- EncryptionType,
-                                           -- in preference order
-
-
-Section 5.4.1.             - 54 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-                    addresses[9]           HostAddresses OPTIONAL,
-                enc-authorization-data[10] EncryptedData OPTIONAL,
-                                           -- Encrypted AuthorizationData 
-                                           -- encoding
-                    additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
-}
-
-The fields in this message are:
-
-
-pvno      This field is included in each message, and speci-
-          fies  the  protocol version number.  This document
-          specifies protocol version 5.
-
-
-msg-type  This field indicates the type of a  protocol  mes-
-          sage.   It  will  almost always be the same as the
-          application identifier associated with a  message.
-          It is included to make the identifier more readily
-          accessible to the application.   For  the  KDC-REQ
-          message,   this   type   will   be  KRB_AS_REQ  or
-          KRB_TGS_REQ.
-
-
-padata    The padata (pre-authentication  data)  field  con-
-          tains  a  sequence  of  authentication information
-          which may be  needed  before  credentials  can  be
-          issued  or decrypted.  In the case of requests for
-          additional tickets (KRB_TGS_REQ), this field  will
-          include  an element with padata-type of PA-TGS-REQ
-          and data  of  an  authentication  header  (ticket-
-          granting  ticket and authenticator).  The checksum
-          in the authenticator  (which  must  be  collision-
-          proof)  is  to  be  computed over the KDC-REQ-BODY
-          encoding.  In most requests for initial  authenti-
-          cation  (KRB_AS_REQ)  and  most replies (KDC-REP),
-          the padata field will be left out.
-
-          This field may also contain information needed  by
-          certain  extensions to the Kerberos protocol.  For
-          example, it might be used to initially verify  the
-          identity  of  a  client  before  any  response  is
-          returned.  This  is  accomplished  with  a  padata
-          field  with  padata-type equal to PA-ENC-TIMESTAMP
-          and padata-value defined as follows:
-
-padata-type     ::= PA-ENC-TIMESTAMP
-padata-value    ::= EncryptedData -- PA-ENC-TS-ENC
-
-PA-ENC-TS-ENC   ::= SEQUENCE {
-                patimestamp[0]     KerberosTime, -- client's time
-                pausec[1]          INTEGER OPTIONAL
-}
-
-          with patimestamp containing the client's time  and
-
-
-Section 5.4.1.             - 55 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-          pausec  containing  the  microseconds which may be
-          omitted if a client will not  generate  more  than
-          one  request  per second.  The ciphertext (padata-
-          value) consists  of  the  PA-ENC-TS-ENC  sequence,
-          encrypted using the client's secret key.
-
-          The padata  field  can  also  contain  information
-          needed  to  help  the KDC or the client select the
-          key  needed  for  generating  or  decrypting   the
-          response.   This  form of the padata is useful for
-          supporting the use of  certain  token  cards  with
-          Kerberos.   The  details  of  such  extensions are
-          specified in separate  documents.   See  [11]  for
-          additional uses of this field.
-
-padata-type
-          The padata-type element of the padata field  indi-
-          cates  the way that the padata-value element is to
-          be interpreted.  Negative  values  of  padata-type
-          are  reserved  for  unregistered use; non-negative
-          values are used for a registered interpretation of
-          the element type.
-
-
-req-body  This field is a placeholder delimiting the  extent
-          of  the  remaining fields.  If a checksum is to be
-          calculated over the request, it is calculated over
-          an  encoding of the KDC-REQ-BODY sequence which is
-          enclosed within the req-body field.
-
-
-kdc-options
-          This  field  appears   in   the   KRB_AS_REQ   and
-          KRB_TGS_REQ  requests to the KDC and indicates the
-          flags that the client wants set on the tickets  as
-          well  as  other  information that is to modify the
-          behavior of the KDC.  Where appropriate, the  name
-          of  an  option may be the same as the flag that is
-          set by that option.  Although in  most  case,  the
-          bit  in the options field will be the same as that
-          in the flags field, this is not guaranteed, so  it
-          is not acceptable to simply copy the options field
-          to the flags field.  There are various checks that
-          must be made before honoring an option anyway.
-
-          The kdc_options field is a  bit-field,  where  the
-          selected  options  are  indicated by the bit being
-          set (1), and the unselected options  and  reserved
-          fields  being reset (0).  The encoding of the bits
-          is specified in  section  5.2.   The  options  are
-          described  in more detail above in section 2.  The
-          meanings of the options are:
-
-
-
-
-Section 5.4.1.             - 56 -    Expires 11 January 1998
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-   Bit(s)    Name                Description
-    0        RESERVED
-                                 Reserved for future  expansion  of  this
-                                 field.
-
-    1        FORWARDABLE
-                                 The FORWARDABLE  option  indicates  that
-                                 the  ticket  to be issued is to have its
-                                 forwardable flag set.  It  may  only  be
-                                 set on the initial request, or in a sub-
-                                 sequent request if  the  ticket-granting
-                                 ticket on which it is based is also for-
-                                 wardable.
-
-    2        FORWARDED
-                                 The FORWARDED option is  only  specified
-                                 in  a  request  to  the  ticket-granting
-                                 server and will only be honored  if  the
-                                 ticket-granting  ticket  in  the request
-                                 has  its  FORWARDABLE  bit  set.    This
-                                 option  indicates that this is a request
-                                 for forwarding.  The address(es) of  the
-                                 host  from which the resulting ticket is
-                                 to  be  valid  are   included   in   the
-                                 addresses field of the request.
-
-    3        PROXIABLE
-                                 The PROXIABLE option indicates that  the
-                                 ticket to be issued is to have its prox-
-                                 iable flag set.  It may only be  set  on
-                                 the  initial request, or in a subsequent
-                                 request if the ticket-granting ticket on
-                                 which it is based is also proxiable.
-
-    4        PROXY
-                                 The PROXY option indicates that this  is
-                                 a request for a proxy.  This option will
-                                 only be honored if  the  ticket-granting
-                                 ticket  in the request has its PROXIABLE
-                                 bit set.  The address(es)  of  the  host
-                                 from which the resulting ticket is to be
-                                  valid  are  included  in  the  addresses
-                                 field of the request.
-
-    5        ALLOW-POSTDATE
-                                 The ALLOW-POSTDATE option indicates that
-                                 the  ticket  to be issued is to have its
-                                 MAY-POSTDATE flag set.  It may  only  be
-                                 set on the initial request, or in a sub-
-                                 sequent request if  the  ticket-granting
-                                 ticket on which it is based also has its
-                                 MAY-POSTDATE flag set.
-
-
-
-
-
-
-
-Section 5.4.1.             - 57 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-    6        POSTDATED
-                                 The POSTDATED option indicates that this
-                                 is  a  request  for  a postdated ticket.
-                                 This option will only be honored if  the
-                                 ticket-granting  ticket  on  which it is
-                                 based has  its  MAY-POSTDATE  flag  set.
-                                 The  resulting ticket will also have its
-                                 INVALID flag set, and that flag  may  be
-                                 reset by a subsequent request to the KDC
-                                 after the starttime in  the  ticket  has
-                                 been reached.
-
-    7        UNUSED
-                                 This option is presently unused.
-
-    8        RENEWABLE
-                                 The RENEWABLE option indicates that  the
-                                 ticket  to  be  issued  is  to  have its
-                                 RENEWABLE flag set.  It may only be  set
-                                 on  the  initial  request,  or  when the
-                                 ticket-granting  ticket  on  which   the
-                                 request  is based is also renewable.  If
-                                 this option is requested, then the rtime
-                                 field   in   the  request  contains  the
-                                 desired absolute expiration time for the
-                                 ticket.
-
-    9-13     UNUSED
-                                 These options are presently unused.
-
-    14       REQUEST-ANONYMOUS
-                                 The REQUEST-ANONYMOUS  option  indicates
-                                 that  the  ticket to be issued is not to
-                                 identify  the  user  to  which  it   was
-                                 issued.  Instead, the principal identif-
-                                 ier is to be generic,  as  specified  by
-                                 the  policy  of  the realm (e.g. usually
-                                 anonymous@realm).  The  purpose  of  the
-                                 ticket  is only to securely distribute a
-                                 session key, and  not  to  identify  the
-                                 user.   The ANONYMOUS flag on the ticket
-                                 to be returned should be  set.   If  the
-                                 local  realms  policy  does  not  permit
-                                 anonymous credentials, the request is to
-                                 be rejected.
-
-    15-25    RESERVED
-                                 Reserved for future use.
-
-    26       DISABLE-TRANSITED-CHECK
-				 By default the KDC will check the
-				 transited field of a ticket-granting-
-				 ticket against the policy of the local
-				 realm before it will issue derivative
-				 tickets based on the ticket granting
-				 ticket.  If this flag is set in the
-				 request, checking of the transited field
-				 is disabled.  Tickets issued without the
-				 performance of this check will be noted
-				 by the reset (0) value of the
-				 TRANSITED-POLICY-CHECKED flag,
-				 indicating to the application server
-				 that the tranisted field must be checked
-				 locally.  KDC's are encouraged but not
-				 required to honor the
-				 DISABLE-TRANSITED-CHECK option.
-
-
-
-Section 5.4.1.             - 58 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-    27       RENEWABLE-OK
-                                 The RENEWABLE-OK option indicates that a
-                                 renewable ticket will be acceptable if a
-                                 ticket with the  requested  life  cannot
-                                 otherwise be provided.  If a ticket with
-                                 the requested life cannot  be  provided,
-                                 then  a  renewable  ticket may be issued
-                                 with  a  renew-till  equal  to  the  the
-                                 requested  endtime.   The  value  of the
-                                 renew-till field may still be limited by
-                                 local  limits, or limits selected by the
-                                 individual principal or server.
-
-    28       ENC-TKT-IN-SKEY
-                                 This option is used only by the  ticket-
-                                 granting  service.   The ENC-TKT-IN-SKEY
-                                 option indicates that the ticket for the
-                                 end  server  is  to  be encrypted in the
-                                 session key from the additional  ticket-
-                                 granting ticket provided.
-
-    29       RESERVED
-                                 Reserved for future use.
-
-    30       RENEW
-                                 This option is used only by the  ticket-
-                                 granting   service.   The  RENEW  option
-                                 indicates that the  present  request  is
-                                 for  a  renewal.  The ticket provided is
-                                 encrypted in  the  secret  key  for  the
-                                 server  on  which  it  is  valid.   This
-                                 option  will  only  be  honored  if  the
-                                 ticket  to  be renewed has its RENEWABLE
-                                 flag set and if the time in  its  renew-
-                                 till  field  has not passed.  The ticket
-                                 to be renewed is passed  in  the  padata
-                                 field  as  part  of  the  authentication
-                                 header.
-
-    31       VALIDATE
-                                 This option is used only by the  ticket-
-                                 granting  service.   The VALIDATE option
-                                 indicates that the request is  to  vali-
-                                 date  a  postdated ticket.  It will only
-                                 be honored if the  ticket  presented  is
-                                 postdated,  presently  has  its  INVALID
-                                 flag set, and would be otherwise  usable
-                                 at  this time.  A ticket cannot be vali-
-                                 dated before its starttime.  The  ticket
-                                 presented for validation is encrypted in
-                                 the key of the server for  which  it  is
-                                 valid  and is passed in the padata field
-                                 as part of the authentication header.
-
-cname and sname
-          These fields are the same as those  described  for
-          the  ticket  in  section 5.3.1.  sname may only be
-
-
-Section 5.4.1.             - 59 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-          absent when the ENC-TKT-IN-SKEY option  is  speci-
-          fied.   If absent, the name of the server is taken
-          from the name of the client in the  ticket  passed
-          as additional-tickets.
-
-
-enc-authorization-data
-          The enc-authorization-data, if present (and it can
-          only be present in the TGS_REQ form), is an encod-
-          ing of the  desired  authorization-data  encrypted
-          under  the  sub-session  key  if  present  in  the
-          Authenticator, or alternatively from  the  session
-          key  in  the ticket-granting ticket, both from the
-          padata field in the KRB_AP_REQ.
-
-
-realm     This  field  specifies  the  realm  part  of   the
-          server's   principal   identifier.    In   the  AS
-          exchange, this is  also  the  realm  part  of  the
-          client's principal identifier.
-
-
-from      This field  is  included  in  the  KRB_AS_REQ  and
-          KRB_TGS_REQ  ticket  requests  when  the requested
-          ticket  is  to  be  postdated.  It  specifies  the
-          desired start time for the requested ticket.
-
-
-
-till      This field contains the expiration date  requested
-          by  the  client in a ticket request.  It is option
-          and if omitted the requested ticket is to have the
-          maximum  endtime permitted according to KDC policy
-          for the parties to the authentication exchange  as
-          limited  by expiration date of the ticket granting
-          ticket or other preauthentication credentials.
-
-
-rtime     This field is the requested renew-till  time  sent
-          from  a client to the KDC in a ticket request.  It
-          is optional.
-
-
-nonce     This  field  is  part  of  the  KDC  request   and
-          response.   It it intended to hold a random number
-          generated by the client.  If the  same  number  is
-          included  in  the encrypted response from the KDC,
-          it provides evidence that the  response  is  fresh
-          and  has not been replayed by an attacker.  Nonces
-          must never be re-used.  Ideally, it should be gen-
-          erated randomly, but if the correct time is known,
-          it may suffice[25].
-__________________________
-[25] Note, however, that if the time  is  used  as  the
-
-Section 5.4.1.             - 60 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-etype     This field specifies the desired encryption  algo-
-          rithm to be used in the response.
-
-
-addresses This field is included in the initial request  for
-          tickets,  and  optionally included in requests for
-          additional  tickets   from   the   ticket-granting
-          server.  It specifies the addresses from which the
-          requested ticket is  to  be  valid.   Normally  it
-          includes  the addresses for the client's host.  If
-          a proxy is  requested,  this  field  will  contain
-          other  addresses.   The contents of this field are
-          usually copied by the KDC into the caddr field  of
-          the resulting ticket.
-
-
-additional-tickets
-          Additional tickets may be optionally included in a
-          request  to  the  ticket-granting  server.  If the
-          ENC-TKT-IN-SKEY option has  been  specified,  then
-          the session key from the additional ticket will be
-          used in place of the server's key to  encrypt  the
-          new   ticket.   If  more  than  one  option  which
-          requires additional tickets  has  been  specified,
-          then  the additional tickets are used in the order
-          specified by the ordering of the options bits (see
-          kdc-options, above).
-
-
-     The application code will be either ten (10) or  twelve
-(12)  depending  on  whether  the  request is for an initial
-ticket (AS-REQ) or for an additional ticket (TGS-REQ).
-
-     The optional fields (addresses, authorization-data  and
-additional-tickets)  are  only included if necessary to per-
-form the operation specified in the kdc-options field.
-
-     It should be noted that in  KRB_TGS_REQ,  the  protocol
-version number appears twice and two different message types
-appear:  the KRB_TGS_REQ message contains  these  fields  as
-does  the  authentication header (KRB_AP_REQ) that is passed
-in the padata field.
-
-5.4.2.  KRB_KDC_REP definition
-
-     The KRB_KDC_REP message format is used  for  the  reply
-from  the KDC for either an initial (AS) request or a subse-
-quent  (TGS)  request.   There  is  no  message   type   for
-__________________________
-nonce,  one must make sure that the workstation time is
-monotonically increasing.  If the time  is  ever  reset
-backwards,  there  is  a small, but finite, probability
-that a nonce will be reused.
-
-
-
-Section 5.4.2.             - 61 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-KRB_KDC_REP.  Instead, the type will be either KRB_AS_REP or
-KRB_TGS_REP.  The key used to encrypt the ciphertext part of
-the reply depends on the message type.  For KRB_AS_REP,  the
-ciphertext  is encrypted in the client's secret key, and the
-client's key version number is included in the  key  version
-number for the encrypted data.  For KRB_TGS_REP, the cipher-
-text is encrypted in the sub-session key from the  Authenti-
-cator,  or  if  absent,  the  session  key  from the ticket-
-granting ticket used in the request.  In that case, no  ver-
-sion number will be present in the EncryptedData sequence.
-
-     The KRB_KDC_REP message contains the following fields:
-
-AS-REP ::=    [APPLICATION 11] KDC-REP
-TGS-REP ::=   [APPLICATION 13] KDC-REP
-
-KDC-REP ::=   SEQUENCE {
-              pvno[0]                    INTEGER,
-              msg-type[1]                INTEGER,
-              padata[2]                  SEQUENCE OF PA-DATA OPTIONAL,
-              crealm[3]                  Realm,
-              cname[4]                   PrincipalName,
-              ticket[5]                  Ticket,
-              enc-part[6]                EncryptedData
-}
-
-
-EncASRepPart ::=    [APPLICATION 25[27]] EncKDCRepPart
-EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart
-
-
-
-EncKDCRepPart ::=   SEQUENCE {
-                    key[0]               EncryptionKey,
-                    last-req[1]          LastReq,
-                    nonce[2]             INTEGER,
-                    key-expiration[3]    KerberosTime OPTIONAL,
-                    flags[4]             TicketFlags,
-                    authtime[5]          KerberosTime,
-                    starttime[6]         KerberosTime OPTIONAL,
-                    endtime[7]           KerberosTime,
-                    renew-till[8]        KerberosTime OPTIONAL,
-                    srealm[9]            Realm,
-                    sname[10]            PrincipalName,
-                    caddr[11]            HostAddresses OPTIONAL
-}
-
-
-pvno and msg-type
-          These fields are described above in section 5.4.1.
-          msg-type is either KRB_AS_REP or KRB_TGS_REP.
-__________________________
-[27] An application code in the  encrypted  part  of  a
-message  provides  an additional check that the message
-was decrypted properly.
-
-
-Section 5.4.2.             - 62 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-padata    This field  is  described  in  detail  in  section
-          5.4.1.   One  possible  use  for  this field is to
-          encode an alternate "mix-in"  string  to  be  used
-          with   a   string-to-key  algorithm  (such  as  is
-          described in section 6.3.2).  This ability is use-
-          ful  to  ease transitions if a realm name needs to
-          change (e.g. when a company is acquired); in  such
-          a  case  all  existing password-derived entries in
-          the KDC database would be  flagged  as  needing  a
-          special  mix-in  string  until  the  next password
-          change.
-
-
-crealm, cname, srealm and sname
-          These fields are the same as those  described  for
-          the ticket in section 5.3.1.
-
-
-ticket    The newly-issued ticket, from section 5.3.1.
-
-
-enc-part  This field is a place holder  for  the  ciphertext
-          and  related  information that forms the encrypted
-          part  of  a  message.   The  description  of   the
-          encrypted part of the message follows each appear-
-          ance of this field.  The encrypted part is encoded
-          as described in section 6.1.
-
-
-key       This field is the same as described for the ticket
-          in section 5.3.1.
-
-
-last-req  This field is returned by the  KDC  and  specifies
-          the  time(s)  of  the last request by a principal.
-          Depending on what information is  available,  this
-          might  be  the  last  time  that  a  request for a
-          ticket-granting ticket was made, or the last  time
-          that  a  request based on a ticket-granting ticket
-          was successful.  It also might cover  all  servers
-          for  a realm, or just the particular server.  Some
-          implementations may display  this  information  to
-          the user to aid in discovering unauthorized use of
-          one's identity.  It is similar in  spirit  to  the
-          last   login  time  displayed  when  logging  into
-          timesharing systems.
-
-
-nonce     This field is described above in section 5.4.1.
-
-
-key-expiration
-          The key-expiration field is part of  the  response
-          from  the  KDC  and  specifies  the  time that the
-
-
-Section 5.4.2.             - 63 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-          client's secret key is due to expire.  The expira-
-          tion  might  be the result of password aging or an
-          account expiration.  This field  will  usually  be
-          left  out  of  the TGS reply since the response to
-          the TGS request is encrypted in a session key  and
-          no  client  information need be retrieved from the
-          KDC database.  It is up to the application  client
-          (usually  the  login  program) to take appropriate
-          action (such as notifying the user) if the expira-
-          tion time is imminent.
-
-
-flags, authtime, starttime, endtime, renew-till and caddr
-          These fields are duplicates of those found in  the
-          encrypted portion of the attached ticket (see sec-
-          tion 5.3.1), provided so  the  client  may  verify
-          they  match  the intended request and to assist in
-          proper ticket caching.  If the message is of  type
-          KRB_TGS_REP,  the  caddr field will only be filled
-          in if the request was for  a  proxy  or  forwarded
-          ticket, or if the user is substituting a subset of
-          the addresses from the ticket granting ticket.  If
-          the  client-requested addresses are not present or
-          not used, then  the  addresses  contained  in  the
-          ticket  will  be the same as those included in the
-          ticket-granting ticket.
-
-
-5.5.  Client/Server (CS) message specifications
-
-     This section specifies the format of the messages  used
-for  the  authentication  of  the  client to the application
-server.
-
-5.5.1.  KRB_AP_REQ definition
-
-     The KRB_AP_REQ message contains the  Kerberos  protocol
-version  number,  the  message  type  KRB_AP_REQ, an options
-field to indicate any options in use,  and  the  ticket  and
-authenticator  themselves.   The KRB_AP_REQ message is often
-referred to as the "authentication header".
-
-AP-REQ ::=      [APPLICATION 14] SEQUENCE {
-                pvno[0]                       INTEGER,
-                msg-type[1]                   INTEGER,
-                ap-options[2]                 APOptions,
-                ticket[3]                     Ticket,
-                authenticator[4]              EncryptedData
-}
-
-APOptions ::=   BIT STRING {
-                reserved(0),
-                use-session-key(1),
-                mutual-required(2)
-
-
-Section 5.5.1.             - 64 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-}
-
-
-pvno and msg-type
-          These fields are described above in section 5.4.1.
-          msg-type is KRB_AP_REQ.
-
-
-ap-optionsThis field  appears  in  the  application  request
-          (KRB_AP_REQ)  and  affects  the way the request is
-          processed.  It is a bit-field, where the  selected
-          options  are  indicated  by the bit being set (1),
-          and the unselected  options  and  reserved  fields
-          being  reset  (0).   The  encoding  of the bits is
-          specified in section 5.2.   The  meanings  of  the
-          options are:
-
-          Bit(s)   Name              Description
-
-          0        RESERVED
-                                     Reserved for future  expansion  of  this
-                                     field.
-
-          1        USE-SESSION-KEY
-                                     The  USE-SESSION-KEY  option   indicates
-                                     that the ticket the client is presenting
-                                     to a server is encrypted in the  session
-                                     key  from  the  server's ticket-granting
-                                     ticket.  When this option is not  speci-
-                                     fied,  the  ticket  is  encrypted in the
-                                     server's secret key.
-
-          2        MUTUAL-REQUIRED
-                                     The  MUTUAL-REQUIRED  option  tells  the
-                                     server  that  the client requires mutual
-                                     authentication, and that it must respond
-                                     with a KRB_AP_REP message.
-
-          3-31     RESERVED
-                                     Reserved for future use.
-
-
-
-ticket    This field is a ticket authenticating  the  client
-          to the server.
-
-
-authenticator
-          This contains the  authenticator,  which  includes
-          the  client's choice of a subkey.  Its encoding is
-          described in section 5.3.2.
-
-5.5.2.  KRB_AP_REP definition
-
-     The KRB_AP_REP message contains the  Kerberos  protocol
-version  number,  the  message  type, and an encrypted time-
-stamp.  The message is sent in in response to an application
-request  (KRB_AP_REQ) where the mutual authentication option
-
-
-Section 5.5.2.             - 65 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-has been selected in the ap-options field.
-
-AP-REP ::=         [APPLICATION 15] SEQUENCE {
-                   pvno[0]                           INTEGER,
-                   msg-type[1]                       INTEGER,
-                   enc-part[2]                       EncryptedData
-}
-
-EncAPRepPart ::=   [APPLICATION 27[29]] SEQUENCE {
-                   ctime[0]                          KerberosTime,
-                   cusec[1]                          INTEGER,
-                   subkey[2]                         EncryptionKey OPTIONAL,
-                   seq-number[3]                     INTEGER OPTIONAL
-}
-
-The encoded EncAPRepPart is encrypted in the shared  session
-key of the ticket.  The optional subkey field can be used in
-an application-arranged negotiation to choose a per associa-
-tion session key.
-
-
-pvno and msg-type
-          These fields are described above in section 5.4.1.
-          msg-type is KRB_AP_REP.
-
-
-enc-part  This field is described above in section 5.4.2.
-
-
-ctime     This  field  contains  the  current  time  on  the
-          client's host.
-
-
-cusec     This field contains the microsecond  part  of  the
-          client's timestamp.
-
-
-subkey    This field contains an encryption key which is  to
-          be  used to protect this specific application ses-
-          sion.  See section 3.2.6 for specifics on how this
-          field  is  used  to  negotiate  a  key.  Unless an
-          application specifies otherwise, if this field  is
-          left out, the sub-session key from the authentica-
-          tor, or if also left out, the session key from the
-          ticket will be used.
-
-
-
-__________________________
-[29] An application code in the  encrypted  part  of  a
-message  provides  an additional check that the message
-was decrypted properly.
-
-
-
-Section 5.5.2.             - 66 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-5.5.3.  Error message reply
-
-     If an error occurs  while  processing  the  application
-request,  the  KRB_ERROR  message  will be sent in response.
-See section 5.9.1 for the format of the error message.   The
-cname and crealm fields may be left out if the server cannot
-determine their appropriate values  from  the  corresponding
-KRB_AP_REQ  message.  If the authenticator was decipherable,
-the ctime and cusec fields will contain the values from it.
-
-5.6.  KRB_SAFE message specification
-
-     This section specifies the format of a message that can
-be  used by either side (client or server) of an application
-to send a tamper-proof message to  its  peer.   It  presumes
-that  a session key has previously been exchanged (for exam-
-ple, by using the KRB_AP_REQ/KRB_AP_REP messages).
-
-5.6.1.  KRB_SAFE definition
-
-     The KRB_SAFE message contains user data  along  with  a
-collision-proof  checksum keyed with the last encryption key
-negotiated via subkeys, or the session key if no negotiation
-has occured.  The message fields are:
-
-KRB-SAFE ::=        [APPLICATION 20] SEQUENCE {
-                    pvno[0]                       INTEGER,
-                    msg-type[1]                   INTEGER,
-                    safe-body[2]                  KRB-SAFE-BODY,
-                    cksum[3]                      Checksum
-}
-
-KRB-SAFE-BODY ::=   SEQUENCE {
-                    user-data[0]                  OCTET STRING,
-                    timestamp[1]                  KerberosTime OPTIONAL,
-                    usec[2]                       INTEGER OPTIONAL,
-                    seq-number[3]                 INTEGER OPTIONAL,
-                    s-address[4]                  HostAddress OPTIONAL,
-                    r-address[5]                  HostAddress OPTIONAL
-}
-
-
-
-
-pvno and msg-type
-          These fields are described above in section 5.4.1.
-          msg-type is KRB_SAFE.
-
-
-safe-body This field is a placeholder for the  body  of  the
-          KRB-SAFE  message.  It is to be encoded separately
-          and then have the checksum computed over  it,  for
-          use in the cksum field.
-
-
-
-Section 5.6.1.             - 67 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-cksum     This field contains the checksum of  the  applica-
-          tion data.  Checksum details are described in sec-
-          tion 6.4.   The  checksum  is  computed  over  the
-          encoding of the KRB-SAFE-BODY sequence.
-
-
-user-data This field is part of the  KRB_SAFE  and  KRB_PRIV
-          messages and contain the application specific data
-          that is being passed from the sender to the  reci-
-          pient.
-
-
-timestamp This field is part of the  KRB_SAFE  and  KRB_PRIV
-          messages.   Its  contents  are the current time as
-          known by the sender of the message.   By  checking
-          the  timestamp,  the  recipient  of the message is
-          able to make sure that it was recently  generated,
-          and is not a replay.
-
-
-usec      This field is part of the  KRB_SAFE  and  KRB_PRIV
-          headers.   It contains the microsecond part of the
-          timestamp.
-
-
-seq-number
-          This field is described above in section 5.3.2.
-
-
-s-address This field specifies the address  in  use  by  the
-          sender of the message.
-
-
-r-address This field specifies the address  in  use  by  the
-          recipient  of  the message.  It may be omitted for
-          some uses (such as broadcast protocols),  but  the
-          recipient  may  arbitrarily  reject such messages.
-          This field along with s-address  can  be  used  to
-          help  detect  messages which have been incorrectly
-          or maliciously delivered to the wrong recipient.
-
-5.7.  KRB_PRIV message specification
-
-     This section specifies the format of a message that can
-be  used by either side (client or server) of an application
-to securely and privately send a message to  its  peer.   It
-presumes  that  a  session key has previously been exchanged
-(for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
-
-5.7.1.  KRB_PRIV definition
-
-     The KRB_PRIV message contains user  data  encrypted  in
-the Session Key.  The message fields are:
-
-__________________________
-[31] An application code in the  encrypted  part  of  a
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-
-KRB-PRIV ::=         [APPLICATION 21] SEQUENCE {
-                     pvno[0]                           INTEGER,
-                     msg-type[1]                       INTEGER,
-                     enc-part[3]                       EncryptedData
-}
-
-EncKrbPrivPart ::=   [APPLICATION 28[31]] SEQUENCE {
-                     user-data[0]        OCTET STRING,
-                     timestamp[1]        KerberosTime OPTIONAL,
-                     usec[2]             INTEGER OPTIONAL,
-                     seq-number[3]       INTEGER OPTIONAL,
-                     s-address[4]        HostAddress OPTIONAL, -- sender's addr
-                     r-address[5]        HostAddress OPTIONAL -- recip's addr
-}
-
-
-
-pvno and msg-type
-          These fields are described above in section 5.4.1.
-          msg-type is KRB_PRIV.
-
-
-enc-part  This field holds an encoding of the EncKrbPrivPart
-          sequence  encrypted  under  the  session  key[32].
-          This  encrypted  encoding is used for the enc-part
-          field of the KRB-PRIV message.  See section 6  for
-          the format of the ciphertext.
-
-
-user-data, timestamp, usec, s-address and r-address
-          These fields are described above in section 5.6.1.
-
-
-seq-number
-          This field is described above in section 5.3.2.
-
-5.8.  KRB_CRED message specification
-
-     This section specifies the format of a message that can
-be  used  to send Kerberos credentials from one principal to
-__________________________
-message  provides  an additional check that the message
-was decrypted properly.
-[32] If  supported  by the encryption method in use, an
-initialization vector may be passed to  the  encryption
-procedure,  in order to achieve proper cipher chaining.
-The initialization vector  might  come  from  the  last
-block of the ciphertext from the previous KRB_PRIV mes-
-sage, but it is the application's choice whether or not
-to use such an initialization vector.  If left out, the
-default initialization vector for the encryption  algo-
-rithm will be used.
-
-
-Section 5.8.               - 69 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-another.  It is presented here to encourage a common mechan-
-ism  to  be  used by applications when forwarding tickets or
-providing proxies to subordinate servers.  It presumes  that
-a  session  key  has already been exchanged perhaps by using
-the KRB_AP_REQ/KRB_AP_REP messages.
-
-5.8.1.  KRB_CRED definition
-
-     The KRB_CRED message contains a sequence of tickets  to
-be sent and information needed to use the tickets, including
-the session key from each.  The information  needed  to  use
-the  tickets is encrypted under an encryption key previously
-exchanged or transferred  alongside  the  KRB_CRED  message.
-The message fields are:
-
-KRB-CRED         ::= [APPLICATION 22]   SEQUENCE {
-                 pvno[0]                INTEGER,
-                 msg-type[1]            INTEGER, -- KRB_CRED
-                 tickets[2]             SEQUENCE OF Ticket,
-                 enc-part[3]            EncryptedData
-}
-
-EncKrbCredPart   ::= [APPLICATION 29]   SEQUENCE {
-                 ticket-info[0]         SEQUENCE OF KrbCredInfo,
-                 nonce[1]               INTEGER OPTIONAL,
-                 timestamp[2]           KerberosTime OPTIONAL,
-                 usec[3]                INTEGER OPTIONAL,
-                 s-address[4]           HostAddress OPTIONAL,
-                 r-address[5]           HostAddress OPTIONAL
-}
-
-KrbCredInfo      ::=                    SEQUENCE {
-                 key[0]                 EncryptionKey,
-                 prealm[1]              Realm OPTIONAL,
-                 pname[2]               PrincipalName OPTIONAL,
-                 flags[3]               TicketFlags OPTIONAL,
-                 authtime[4]            KerberosTime OPTIONAL,
-                 starttime[5]           KerberosTime OPTIONAL,
-                 endtime[6]             KerberosTime OPTIONAL
-                 renew-till[7]          KerberosTime OPTIONAL,
-                 srealm[8]              Realm OPTIONAL,
-                 sname[9]               PrincipalName OPTIONAL,
-                 caddr[10]              HostAddresses OPTIONAL
-}
-
-
-
-
-
-pvno and msg-type
-          These fields are described above in section 5.4.1.
-          msg-type is KRB_CRED.
-
-
-
-
-Section 5.8.1.             - 70 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-tickets
-          These  are  the  tickets  obtained  from  the  KDC
-          specifically  for  use  by the intended recipient.
-          Successive tickets are paired with the correspond-
-          ing  KrbCredInfo sequence from the enc-part of the
-          KRB-CRED message.
-
-
-enc-part  This field holds an encoding of the EncKrbCredPart
-          sequence  encrypted  under  the session key shared
-          between the sender  and  the  intended  recipient.
-          This  encrypted  encoding is used for the enc-part
-          field of the KRB-CRED message.  See section 6  for
-          the format of the ciphertext.
-
-
-nonce     If  practical,  an  application  may  require  the
-          inclusion of a nonce generated by the recipient of
-          the message.  If the same value is included as the
-          nonce  in  the  message, it provides evidence that
-          the message is fresh and has not been replayed  by
-          an  attacker.   A  nonce must never be re-used; it
-          should be generated randomly by the  recipient  of
-          the message and provided to the sender of the mes-
-          sage in an application specific manner.
-
-
-timestamp and usec
-
-          These fields specify the time  that  the  KRB-CRED
-          message  was  generated.  The time is used to pro-
-          vide assurance that the message is fresh.
-
-
-s-address and r-address
-          These fields are described above in section 5.6.1.
-          They  are  used  optionally  to provide additional
-          assurance of the integrity of  the  KRB-CRED  mes-
-          sage.
-
-
-key       This field  exists  in  the  corresponding  ticket
-          passed by the KRB-CRED message and is used to pass
-          the session key from the sender  to  the  intended
-          recipient.   The  field's encoding is described in
-          section 6.2.
-
-     The following fields are optional.   If  present,  they
-can  be associated with the credentials in the remote ticket
-file.  If left out, then it is assumed that the recipient of
-the credentials already knows their value.
-
-
-prealm and pname
-
-
-Section 5.8.1.             - 71 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-          The name and  realm  of  the  delegated  principal
-          identity.
-
-
-flags, authtime,  starttime,  endtime,  renew-till,  srealm,
-          sname, and caddr
-          These fields contain the values of the correspond-
-          ing  fields  from  the  ticket found in the ticket
-          field.  Descriptions of the fields  are  identical
-          to the descriptions in the KDC-REP message.
-
-5.9.  Error message specification
-
-     This section specifies the  format  for  the  KRB_ERROR
-message.  The fields included in the message are intended to
-return as much information as possible about an  error.   It
-is  not  expected  that  all the information required by the
-fields will be available for all types of  errors.   If  the
-appropriate information is not available when the message is
-composed, the corresponding field will be left  out  of  the
-message.
-
-     Note that since the KRB_ERROR message is not  protected
-by  any  encryption, it is quite possible for an intruder to
-synthesize or modify such a message.   In  particular,  this
-means that the client should not use any fields in this mes-
-sage for security-critical purposes, such as setting a  sys-
-tem  clock or generating a fresh authenticator.  The message
-can be useful, however, for advising a user  on  the  reason
-for some failure.
-
-5.9.1.  KRB_ERROR definition
-
-     The KRB_ERROR message consists of the following fields:
-
-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-cksum[13]                   Checksum OPTIONAL
-}
-
-
-
-
-
-Section 5.9.1.             - 72 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-pvno and msg-type
-          These fields are described above in section 5.4.1.
-          msg-type is KRB_ERROR.
-
-
-ctime     This field is described above in section 5.4.1.
-
-
-
-cusec     This field is described above in section 5.5.2.
-
-
-stime     This  field  contains  the  current  time  on  the
-          server.  It is of type KerberosTime.
-
-
-susec     This field contains the microsecond  part  of  the
-          server's  timestamp.   Its  value ranges from 0 to
-          999999.  It appears  along  with  stime.  The  two
-          fields  are  used in conjunction to specify a rea-
-          sonably accurate timestamp.
-
-
-error-codeThis field contains the  error  code  returned  by
-          Kerberos  or  the server when a request fails.  To
-          interpret the value of this field see the list  of
-          error  codes  in  section  8.  Implementations are
-          encouraged to provide for national  language  sup-
-          port in the display of error messages.
-
-
-crealm, cname, srealm and sname
-          These fields are described above in section 5.3.1.
-
-
-e-text    This  field  contains  additional  text  to   help
-          explain  the error code associated with the failed
-          request (for example, it might include a principal
-          name which was unknown).
-
-
-e-data     This field contains  additional  data  about  the
-          error  for  use  by  the  application  to  help it
-          recover from or handle the error.  If  the  error-
-          code  is KDC_ERR_PREAUTH_REQUIRED, then the e-data
-          field will contain an encoding of  a  sequence  of
-          padata fields, each corresponding to an acceptable
-          pre-authentication method and optionally  contain-
-          ing data for the method:
-
-
-e-cksum   This field contains an optional checksum  for  the
-          KRB-ERROR  message.   The  checksum  is calculated
-          over the Kerberos ASN.1 encoding of the  KRB-ERROR
-
-
-Section 5.9.1.             - 73 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-          message with the checksum absent.  The checksum is
-          then added to the KRB-ERROR structure and the mes-
-          sage is re-encoded.  The Checksum should be calcu-
-          lated using the session key from the ticket grant-
-          ing ticket or service ticket, where available.  If
-          the error is in response to a TGS or  AP  request,
-          the  checksum  should  be  calculated uing the the
-          session key from  the  client's  ticket.   If  the
-          error  is  in  response to an AS request, then the
-          checksum should be calulated  using  the  client's
-          secret  key ONLY if there has been suitable preau-
-          thentication to prove knowledge of the secret  key
-          by the client[33].  If a checksum can not be  com-
-          puted because the key to be used is not available,
-          no checksum will be included.
-
-               METHOD-DATA ::=   SEQUENCE of PA-DATA
-
-
-          If the error-code is KRB_AP_ERR_METHOD,  then  the
-          e-data  field will contain an encoding of the fol-
-          lowing sequence:
-
-       METHOD-DATA ::=   SEQUENCE {
-                         method-type[0]   INTEGER,
-                         method-data[1]   OCTET STRING OPTIONAL
-       }
-
-          method-type will indicate the  required  alternate
-          method;  method-data  will  contain  any  required
-          additional information.
-
-
-
-6.  Encryption and Checksum Specifications
-
-The  Kerberos  protocols  described  in  this  document  are
-designed  to  use  stream  encryption  ciphers, which can be
-simulated using commonly available block encryption ciphers,
-such  as  the  Data Encryption Standard, [12] in conjunction
-with block chaining and checksum methods  [13].   Encryption
-is used to prove the identities of the network entities par-
-ticipating  in  message  exchanges.   The  Key  Distribution
-Center   for   each  realm  is  trusted  by  all  principals
-registered in that realm to store a  secret  key  in  confi-
-dence.   Proof  of  knowledge  of this secret key is used to
-verify the authenticity of a principal.
-
-     The KDC uses the principal's  secret  key  (in  the  AS
-__________________________
-[33] This prevents an attacker  who  generates  an  in-
-correct  AS request from obtaining verifiable plaintext
-for use in an off-line password guessing attack.
-
-
-Section 6.                 - 74 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-exchange) or a shared session key (in the TGS  exchange)  to
-encrypt  responses to ticket requests; the ability to obtain
-the secret key or session key implies the knowledge  of  the
-appropriate  keys  and the identity of the KDC.  The ability
-of a principal to decrypt the KDC  response  and  present  a
-Ticket  and  a properly formed Authenticator (generated with
-the session key from the KDC response) to a service verifies
-the  identity  of the principal; likewise the ability of the
-service to extract the session key from the Ticket and prove
-its knowledge thereof in a response verifies the identity of
-the service.
-
-     The  Kerberos  protocols  generally  assume  that   the
-encryption  used  is  secure from cryptanalysis; however, in
-some cases, the order of fields in the encrypted portions of
-messages  are  arranged  to  minimize  the effects of poorly
-chosen keys.  It is still important to choose good keys.  If
-keys  are derived from user-typed passwords, those passwords
-need to be well chosen to make brute force attacks more dif-
-ficult.   Poorly  chosen  keys  still  make easy targets for
-intruders.
-
-     The  following  sections  specify  the  encryption  and
-checksum  mechanisms  currently  defined  for Kerberos.  The
-encodings, chaining, and padding requirements for  each  are
-described.  For encryption methods, it is often desirable to
-place random information (often referred to as a confounder)
-at  the  start  of the message.  The requirements for a con-
-founder are specified with each encryption mechanism.
-
-     Some encryption systems use a block-chaining method  to
-improve  the the security characteristics of the ciphertext.
-However, these  chaining  methods  often  don't  provide  an
-integrity  check upon decryption.  Such systems (such as DES
-in CBC mode) must be augmented with a checksum of the plain-
-text  which can be verified at decryption and used to detect
-any tampering or damage.  Such checksums should be  good  at
-detecting  burst  errors  in  the  input.   If any damage is
-detected, the decryption routine is expected  to  return  an
-error  indicating  the  failure of an integrity check.  Each
-encryption  type  is  expected  to  provide  and  verify  an
-appropriate  checksum.  The specification of each encryption
-method sets out its checksum requirements.
-
-     Finally, where a key is to be  derived  from  a  user's
-password,  an algorithm for converting the password to a key
-of the appropriate type is included.  It  is  desirable  for
-the  string  to key function to be one-way, and for the map-
-ping to be different in different realms.  This is important
-because users who are registered in more than one realm will
-often use the same password in each,  and  it  is  desirable
-that  an  attacker  compromising  the Kerberos server in one
-realm not obtain or derive the user's key in another.
-
-
-
-Section 6.                 - 75 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-     For an discussion of the integrity  characteristics  of
-the candidate encryption and checksum methods considered for
-Kerberos, the the reader is referred to [14].
-
-6.1.  Encryption Specifications
-
-     The following ASN.1 definition describes all  encrypted
-messages.   The  enc-part  field  which appears in the unen-
-crypted part of messages in section 5 is a sequence consist-
-ing  of  an encryption type, an optional key version number,
-and the ciphertext.
-
-
-EncryptedData ::=   SEQUENCE {
-                    etype[0]     INTEGER, -- EncryptionType
-                    kvno[1]      INTEGER OPTIONAL,
-                    cipher[2]    OCTET STRING -- ciphertext
-}
-
-
-etype     This field identifies which  encryption  algorithm
-          was used to encipher the cipher.  Detailed specif-
-          ications  for  selected  encryption  types  appear
-          later in this section.
-
-
-kvno      This field contains the version number of the  key
-          under which data is encrypted.  It is only present
-          in messages encrypted  under  long  lasting  keys,
-          such as principals' secret keys.
-
-
-cipher    This field contains the enciphered  text,  encoded
-          as an OCTET STRING.
-
-
-     The cipher field is generated by applying the specified
-encryption  algorithm  to  data  composed of the message and
-algorithm-specific inputs.   Encryption  mechanisms  defined
-for  use  with  Kerberos  must  take  sufficient measures to
-guarantee the integrity of the plaintext, and  we  recommend
-they  also take measures to protect against precomputed dic-
-tionary attacks.  If the encryption algorithm is not  itself
-capable  of  doing so, the protections can often be enhanced
-by adding a checksum and a confounder.
-
-     The suggested format  for  the  data  to  be  encrypted
-includes  a  confounder,  a checksum, the encoded plaintext,
-and any necessary padding.  The msg-seq field  contains  the
-part of the protocol message described in section 5 which is
-to be encrypted.  The confounder, checksum, and padding  are
-all untagged and untyped, and their length is exactly suffi-
-cient to hold the appropriate item.  The type and length  is
-implicit  and  specified  by  the particular encryption type
-
-
-Section 6.1.               - 76 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-being used (etype).  The format for the data to be encrypted
-is described in the following diagram:
-
-      +-----------+----------+-------------+-----+
-      |confounder |   check  |   msg-seq   | pad |
-      +-----------+----------+-------------+-----+
-
-The format cannot be described in ASN.1, but for  those  who
-prefer an ASN.1-like notation:
-
-CipherText ::=   ENCRYPTED       SEQUENCE {
-            confounder[0]   UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL,
-            check[1]        UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
-            msg-seq[2]      MsgSequence,
-            pad             UNTAGGED OCTET STRING(pad_length) OPTIONAL
-}
-
-
-     One generates a random confounder  of  the  appropriate
-length,  placing  it in confounder; zeroes out check; calcu-
-lates the appropriate checksum over confounder,  check,  and
-msg-seq,  placing  the  result  in check; adds the necessary
-padding; then encrypts using the specified  encryption  type
-and the appropriate key.
-
-     Unless otherwise specified, a definition of an  encryp-
-tion  algorithm  that specifies a checksum, a length for the
-confounder field, or an octet boundary for padding uses this
-ciphertext format[36].  Those fields which are not specified
-will be omitted.
-
-     In the interest of allowing all implementations using a
-__________________________
-[35] In  the  above   specification,   UNTAGGED   OCTET
-STRING(length) is the notation for an octet string with
-its tag and length removed.  It is not  a  valid  ASN.1
-type.  The tag bits and length must be removed from the
-confounder since the purpose of the  confounder  is  so
-that  the  message starts with random data, but the tag
-and its length are fixed.  For other fields, the length
-and  tag  would  be redundant if they were included be-
-cause they are specified by the encryption type.
-[36] The  ordering  of  the fields in the CipherText is
-important.  Additionally, messages encoded in this for-
-mat must include a length as part of the msg-seq field.
-This allows the recipient to verify  that  the  message
-has  not been truncated.  Without a length, an attacker
-could use a chosen plaintext attack to generate a  mes-
-sage which could be truncated, while leaving the check-
-sum intact.  Note that if the msg-seq is an encoding of
-an  ASN.1  SEQUENCE or OCTET STRING, then the length is
-part of that encoding.
-
-
-
-Section 6.1.               - 77 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-particular encryption type to communicate  with  all  others
-using  that  type,  the  specification of an encryption type
-defines any checksum that is needed as part of  the  encryp-
-tion  process.   If an alternative checksum is to be used, a
-new encryption type must be defined.
-
-     Some  cryptosystems  require   additional   information
-beyond  the  key and the data to be encrypted.  For example,
-DES, when used in cipher-block-chaining  mode,  requires  an
-initialization  vector.   If  required,  the description for
-each encryption type must specify the source of  such  addi-
-tional information.
-
-6.2.  Encryption Keys
-
-     The sequence below shows the encoding of an  encryption
-key:
-
-       EncryptionKey ::=   SEQUENCE {
-                           keytype[0]    INTEGER,
-                           keyvalue[1]   OCTET STRING
-       }
-
-
-keytype   This field specifies the type  of  encryption  key
-          that  follows  in  the  keyvalue  field.   It will
-          almost always correspond to the  encryption  algo-
-          rithm  used  to generate the EncryptedData, though
-          more than one algorithm may use the same  type  of
-          key (the mapping is many to one).  This might hap-
-          pen, for example, if the encryption algorithm uses
-          an  alternate  checksum algorithm for an integrity
-          check, or a different chaining mechanism.
-
-
-keyvalue  This field contains the key itself, encoded as  an
-          octet string.
-
-     All negative values for the  encryption  key  type  are
-reserved   for  local  use.   All  non-negative  values  are
-reserved for officially assigned type fields and interpreta-
-tions.
-
-6.3.  Encryption Systems
-
-6.3.1.  The NULL Encryption System (null)
-
-     If no encryption is in use, the  encryption  system  is
-said  to be the NULL encryption system.  In the NULL encryp-
-tion system there is no  checksum,  confounder  or  padding.
-The  ciphertext  is  simply  the plaintext.  The NULL Key is
-used by the null encryption system and  is  zero  octets  in
-length, with keytype zero (0).
-
-
-
-Section 6.3.1.             - 78 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-6.3.2.  DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
-
-     The des-cbc-crc encryption  mode  encrypts  information
-under  the  Data  Encryption Standard  [12] using the cipher
-block chaining mode [13].  A CRC-32 checksum  (described  in
-ISO  3309  [15])  is  applied  to the confounder and message
-sequence (msg-seq) and  placed  in  the  cksum  field.   DES
-blocks  are  8 bytes.  As a result, the data to be encrypted
-(the concatenation of  confounder,  checksum,  and  message)
-must be padded to an 8 byte boundary before encryption.  The
-details of the encryption of  this  data  are  identical  to
-those for the des-cbc-md5 encryption mode.
-
-     Note that, since the CRC-32 checksum is not  collision-
-proof,   an  attacker  could  use  a  probabilistic  chosen-
-plaintext attack to generate a valid message even if a  con-
-founder is used  [14].  The use of collision-proof checksums
-is recommended for environments where such attacks represent
-a significant threat.  The use of the CRC-32 as the checksum
-for ticket or authenticator is  no  longer  mandated  as  an
-interoperability requirement for Kerberos Version 5 Specifi-
-cation 1 (See section 9.1 for specific details).
-
-
-6.3.3.  DES in CBC mode with an MD4 checksum (des-cbc-md4)
-
-     The des-cbc-md4 encryption  mode  encrypts  information
-under  the  Data  Encryption Standard  [12] using the cipher
-block chaining mode [13].  An  MD4  checksum  (described  in
-[16])  is  applied  to  the  confounder and message sequence
-(msg-seq) and placed in the cksum field.  DES blocks  are  8
-bytes.   As a result, the data to be encrypted (the concate-
-nation of confounder, checksum, and message) must be  padded
-to an 8 byte boundary before encryption.  The details of the
-encryption of this data are identical to those for the  des-
-cbc-md5 encryption mode.
-
-
-6.3.4.  DES in CBC mode with an MD5 checksum (des-cbc-md5)
-
-     The des-cbc-md5 encryption  mode  encrypts  information
-under  the  Data  Encryption Standard  [12] using the cipher
-block chaining mode [13].  An MD5  checksum   (described  in
-[17].)  is  applied  to  the confounder and message sequence
-(msg-seq) and placed in the cksum field.  DES blocks  are  8
-bytes.   As a result, the data to be encrypted (the concate-
-nation of confounder, checksum, and message) must be  padded
-to an 8 byte boundary before encryption.
-
-     Plaintext and DES ciphtertext are  encoded  as  8-octet
-blocks  which are concatenated to make the 64-bit inputs for
-the DES algorithms.  The first octet  supplies  the  8  most
-significant  bits  (with  the  octet's MSbit used as the DES
-input block's MSbit, etc.), the  second  octet  the  next  8
-
-
-Section 6.3.4.             - 79 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-bits,  ..., and the eighth octet supplies the 8 least signi-
-ficant bits.
-
-     Encryption  under  DES  using  cipher  block   chaining
-requires  an  additional input in the form of an initializa-
-tion vector.  Unless otherwise  specified,  zero  should  be
-used  as  the  initialization  vector.  Kerberos' use of DES
-requires an 8-octet confounder.
-
-     The DES specifications identify some "weak" and  "semi-
-weak" keys; those keys shall not be used for encrypting mes-
-sages for use in Kerberos.  Additionally, because of the way
-that  keys are derived for the encryption of checksums, keys
-shall not be used that yield "weak" or "semi-weak" keys when
-eXclusive-ORed with the constant F0F0F0F0F0F0F0F0.
-
-     A DES key is 8 octets of data, with  keytype  one  (1).
-This  consists of 56 bits of key, and 8 parity bits (one per
-octet).  The key is encoded as a series of 8 octets  written
-in  MSB-first  order.   The  bits  within  the  key are also
-encoded in MSB order.  For example, if the encryption key is
-(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8)
-where B1,B2,...,B56 are the  key  bits  in  MSB  order,  and
-P1,P2,...,P8 are the parity bits, the first octet of the key
-would be B1,B2,...,B7,P1 (with B1 as the MSbit).   [See  the
-FIPS 81 introduction for reference.]
-
-     To generate a DES key from a  text  string  (password),
-the  text  string normally must have the realm and each com-
-ponent of the principal's  name  appended[37],  then  padded
-with ASCII nulls to an 8 byte boundary.  This string is then
-fan-folded and eXclusive-ORed with itself to form an 8  byte
-DES key.  The parity is corrected on the key, and it is used
-to generate a DES CBC checksum on the initial  string  (with
-the  realm and name appended).  Next, parity is corrected on
-the CBC checksum.  If the result matches a "weak" or  "semi-
-weak"  key  as  described  in  the  DES specification, it is
-eXclusive-ORed with the constant 00000000000000F0.  Finally,
-the result is returned as the key.  Pseudocode follows:
-
-     string_to_key(string,realm,name) {
-          odd = 1;
-          s = string + realm;
-          for(each component in name) {
-               s = s + component;
-          }
-          tempkey = NULL;
-          pad(s); /* with nulls to 8 byte boundary */
-          for(8byteblock in s) {
-__________________________
-[37] In some cases, it may be necessary to use  a  dif-
-ferent  "mix-in"  string for compatibility reasons; see
-the discussion of padata in section 5.4.2.
-
-
-Section 6.3.4.             - 80 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-               if(odd == 0)  {
-                   odd = 1;
-                   reverse(8byteblock)
-               }
-               else odd = 0;
-               tempkey = tempkey XOR 8byteblock;
-          }
-          fixparity(tempkey);
-          key = DES-CBC-check(s,tempkey);
-          fixparity(key);
-          if(is_weak_key_key(key))
-               key = key XOR 0xF0;
-          return(key);
-     }
-
-6.3.5.  Triple DES EDE in outer CBC mode with an SHA1 check-
-sum (des3-cbc-sha1)
-
-     The des3-cbc-sha1 encryption encodes information  using
-three  Data  Encryption  Standard transformations with three
-DES keys.  The first key  is  used  to  perform  a  DES  ECB
-encryption  on an eight-octet data block using the first DES
-key, followed by a DES ECB decryption of  the  result  using
-the  second  DES key, and a DES ECB encryption of the result
-using the third DES key.  Because DES blocks  are  8  bytes,
-the  data  to be encrypted (the concatenation of confounder,
-checksum, and message) must first be padded  to  an  8  byte
-boundary  before encryption.  To support the outer CBC mode,
-the input is padded an eight-octet boundary.   The  first  8
-octets  of  the  data  to  be  encrypted (the confounder) is
-exclusive-ored with an initialization  vector  of  zero  and
-then  ECB  encrypted  using  triple  DES as described above.
-Subsequent blocks of 8 octets are  exclusive-ored  with  the
-ciphertext  produced by the encryption on the previous block
-before ECB encryption.
-
-     An HMAC-SHA1 checksum  (described in  [18].) is applied
-to  the confounder and message sequence (msg-seq) and placed
-in the cksum field.
-
-     Plaintext  are encoded as 8-octet blocks which are con-
-catenated  to make the 64-bit inputs for the DES algorithms.
-The first octet supplies the 8 most significant  bits  (with
-the  octet's  MSbit  used  as  the  DES input block's MSbit,
-etc.), the second octet the next 8 bits, ..., and the eighth
-octet supplies the 8 least significant bits.
-
-     Encryption under Triple DES using cipher block chaining
-requires  an  additional input in the form of an initializa-
-tion vector.  Unless otherwise  specified,  zero  should  be
-used  as  the  initialization  vector.  Kerberos' use of DES
-requires an 8-octet confounder.
-
-     The DES specifications identify some "weak" and  "semi-
-
-
-Section 6.3.5.             - 81 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-weak" keys; those keys shall not be used for encrypting mes-
-sages for use in Kerberos.  Additionally, because of the way
-that  keys are derived for the encryption of checksums, keys
-shall not be used that yield "weak" or "semi-weak" keys when
-eXclusive-ORed with the constant F0F0F0F0F0F0F0F0.
-
-     A Triple DES key is 24 octets  of  data,  with  keytype
-seven  (7).  This consists of 168 bits of key, and 24 parity
-bits (one per octet).  The key is encoded as a series of  24
-octets  written  in MSB-first order, with the first 8 octets
-treated as the first DES key, the second  8  octets  as  the
-second  key,  and the third 8 octets the third DES key.  The
-bits within each key are also encoded  in  MSB  order.   For
-example,       if       the      encryption      key      is
-(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8)
-where  B1,B2,...,B56  are  the  key  bits  in MSB order, and
-P1,P2,...,P8 are the parity bits, the first octet of the key
-would  be  B1,B2,...,B7,P1 (with B1 as the MSbit).  [See the
-FIPS 81 introduction for reference.]
-
-     To generate a DES key from a  text  string  (password),
-the  text  string normally must have the realm and each com-
-ponent of the principal's name appended[38],
-
-     The input string (with any salt data appended to it) is
-n-folded  into  a  24  octet  (192 bit) string.  To n-fold a
-number X, replicate the input value to a length that is  the
-least common multiple of n and the length of X.  Before each
-repetition, the input X is rotated to the right  by  13  bit
-positions.   The  successive n-bit chunks are added together
-using  1's-complement  addition  (addition  with  end-around
-carry)  to  yield  a  n-bit result. (This transformation was
-proposed by Richard Basch)
-
-     Each successive set of 8 octets is taken as a DES  key,
-and  its parity is adjusted in the same manner as previously
-described.  If any of the three sets of  8  octets  match  a
-"weak" or "semi-weak" key as described in the DES specifica-
-tion,  that  chunk  is  eXclusive-ORed  with  the   constant
-00000000000000F0.   The  resulting DES keys are then used in
-sequence to perform a Triple-DES CBC encryption  of  the  n-
-folded  input  string (appended with any salt data), using a
-zero initial vector.  Parity, weak, and semi-weak  keys  are
-once  again  corrected  and the result is returned as the 24
-octet key.
-
-     Pseudocode follows:
-
-     string_to_key(string,realm,name) {
-__________________________
-[38] In some cases, it may be necessary to use  a  dif-
-ferent  "mix-in"  string for compatibility reasons; see
-the discussion of padata in section 5.4.2.
-
-
-Section 6.3.5.             - 82 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-          s = string + realm;
-          for(each component in name) {
-               s = s + component;
-          }
-          tkey[24] = fold(s);
-          fixparity(tkey);
-          if(isweak(tkey[0-7])) tkey[0-7] = tkey[0-7] XOR 0xF0;
-          if(isweak(tkey[8-15])) tkey[8-15] = tkey[8-15] XOR 0xF0;
-          if(is_weak(tkey[16-23])) tkey[16-23] = tkey[16-23] XOR 0xF0;
-          key[24] = 3DES-CBC(data=fold(s),key=tkey,iv=0);
-          fixparity(key);
-          if(is_weak(key[0-7])) key[0-7] = key[0-7] XOR 0xF0;
-          if(is_weak(key[8-15])) key[8-15] = key[8-15] XOR 0xF0;
-          if(is_weak(key[16-23])) key[16-23] = key[16-23] XOR 0xF0;
-          return(key);
-     }
-
-6.4.  Checksums
-
-     The following is the ASN.1 definition used for a check-
-sum:
-
-         Checksum ::=   SEQUENCE {
-                        cksumtype[0]   INTEGER,
-                        checksum[1]    OCTET STRING
-         }
-
-
-cksumtype This field indicates the algorithm  used  to  gen-
-          erate the accompanying checksum.
-
-checksum  This field contains the checksum  itself,  encoded
-          as an octet string.
-
-     Detailed  specification  of  selected  checksum   types
-appear  later  in  this  section.   Negative  values for the
-checksum type are reserved for local use.  All  non-negative
-values  are reserved for officially assigned type fields and
-interpretations.
-
-     Checksums used by Kerberos can  be  classified  by  two
-properties:   whether  they are collision-proof, and whether
-they are keyed.  It is infeasible  to  find  two  plaintexts
-which generate the same checksum value for a collision-proof
-checksum.  A key is required to perturb  or  initialize  the
-algorithm  in  a  keyed checksum.  To prevent message-stream
-modification by an active attacker, unkeyed checksums should
-only  be  used  when the checksum and message will be subse-
-quently encrypted (e.g. the checksums defined as part of the
-encryption algorithms covered earlier in this section).
-
-     Collision-proof checksums can be made  tamper-proof  if
-the  checksum  value is encrypted before inclusion in a mes-
-sage.  In such cases, the composition of  the  checksum  and
-
-
-Section 6.4.               - 83 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-the  encryption  algorithm  must  be  considered  a separate
-checksum algorithm (e.g. RSA-MD5 encrypted using  DES  is  a
-new checksum algorithm of type RSA-MD5-DES).  For most keyed
-checksums, as well as for the  encrypted  forms  of  unkeyed
-collision-proof  checksums,  Kerberos  prepends a confounder
-before the checksum is calculated.
-
-6.4.1.  The CRC-32 Checksum (crc32)
-
-     The CRC-32 checksum calculates a checksum  based  on  a
-cyclic  redundancy check as described in ISO 3309 [15].  The
-resulting checksum is four (4) octets in length.  The CRC-32
-is  neither  keyed  nor  collision-proof.   The  use of this
-checksum is not recommended.  An  attacker  using  a  proba-
-bilistic  chosen-plaintext attack as described in [14] might
-be able to generate an alternative  message  that  satisfies
-the  checksum.   The  use  of  collision-proof  checksums is
-recommended for environments where such attacks represent  a
-significant threat.
-
-6.4.2.  The RSA MD4 Checksum (rsa-md4)
-
-     The RSA-MD4 checksum calculates a  checksum  using  the
-RSA  MD4  algorithm  [16].   The algorithm takes as input an
-input message of arbitrary length and produces as  output  a
-128-bit  (16  octet)  checksum.   RSA-MD4  is believed to be
-collision-proof.
-
-6.4.3.  RSA MD4 Cryptographic Checksum Using  DES  (rsa-md4-
-des)
-
-     The RSA-MD4-DES checksum calculates a keyed  collision-
-proof  checksum  by  prepending an 8 octet confounder before
-the text, applying  the  RSA  MD4  checksum  algorithm,  and
-encrypting  the  confounder  and  the  checksum using DES in
-cipher-block-chaining (CBC) mode using a variant of the key,
-where  the  variant  is  computed by eXclusive-ORing the key
-with the constant F0F0F0F0F0F0F0F0[39].  The  initialization
-vector  should be zero.  The resulting checksum is 24 octets
-long (8 octets of which are redundant).   This  checksum  is
-tamper-proof and believed to be collision-proof.
-
-     The DES specifications identify some  "weak  keys"  and
-__________________________
-[39] A variant of the key is used to limit the use of a
-key  to a particular function, separating the functions
-of generating a checksum  from  other  encryption  per-
-formed   using   the   session   key.    The   constant
-F0F0F0F0F0F0F0F0 was chosen because  it  maintains  key
-parity.  The properties of DES precluded the use of the
-complement.  The same constant is used for similar pur-
-pose  in  the  Message  Integrity  Check in the Privacy
-Enhanced Mail standard.
-
-
-Section 6.4.3.             - 84 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-"semi-weak keys"; those keys shall not be used for  generat-
-ing RSA-MD4 checksums for use in Kerberos.
-
-     The format for the checksum is described in the follow-
-ing diagram:
-
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-|  des-cbc(confounder   +   rsa-md4(confounder+msg),key=var(key),iv=0)  |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The format cannot be described in ASN.1, but for  those  who
-prefer an ASN.1-like notation:
-
-rsa-md4-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                           confounder[0]   UNTAGGED OCTET STRING(8),
-                           check[1]        UNTAGGED OCTET STRING(16)
-}
-
-
-
-6.4.4.  The RSA MD5 Checksum (rsa-md5)
-
-     The RSA-MD5 checksum calculates a  checksum  using  the
-RSA  MD5  algorithm.  [17].  The algorithm takes as input an
-input message of arbitrary length and produces as  output  a
-128-bit  (16  octet)  checksum.   RSA-MD5  is believed to be
-collision-proof.
-
-6.4.5.  RSA MD5 Cryptographic Checksum Using  DES  (rsa-md5-
-des)
-
-     The RSA-MD5-DES checksum calculates a keyed  collision-
-proof  checksum  by  prepending an 8 octet confounder before
-the text, applying  the  RSA  MD5  checksum  algorithm,  and
-encrypting  the  confounder  and  the  checksum using DES in
-cipher-block-chaining (CBC) mode using a variant of the key,
-where  the  variant  is  computed by eXclusive-ORing the key
-with the constant F0F0F0F0F0F0F0F0.  The initialization vec-
-tor  should  be  zero.   The resulting checksum is 24 octets
-long (8 octets of which are redundant).   This  checksum  is
-tamper-proof and believed to be collision-proof.
-
-     The DES specifications identify some  "weak  keys"  and
-"semi-weak  keys"; those keys shall not be used for encrypt-
-ing RSA-MD5 checksums for use in Kerberos.
-
-     The format for the checksum is described in the follow-
-ing diagram:
-
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-|  des-cbc(confounder   +   rsa-md5(confounder+msg),key=var(key),iv=0)  |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The format cannot be described in ASN.1, but for  those  who
-
-
-Section 6.4.5.             - 85 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-prefer an ASN.1-like notation:
-
-rsa-md5-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                           confounder[0]   UNTAGGED OCTET STRING(8),
-                           check[1]        UNTAGGED OCTET STRING(16)
-}
-
-
-6.4.6.  DES cipher-block chained checksum (des-mac)
-
-     The DES-MAC checksum is computed  by  prepending  an  8
-octet confounder to the plaintext, performing a DES CBC-mode
-encryption on the result using the key and an initialization
-vector  of  zero,  taking  the last block of the ciphertext,
-prepending the same confounder and encrypting the pair using
-DES in cipher-block-chaining (CBC) mode using a a variant of
-the key, where the variant is  computed  by  eXclusive-ORing
-the key with the constant F0F0F0F0F0F0F0F0.  The initializa-
-tion vector should be zero.  The resulting checksum  is  128
-bits (16 octets) long, 64 bits of which are redundant.  This
-checksum is tamper-proof and collision-proof.
-
-     The format for the checksum is described in the follow-
-ing diagram:
-
-+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
-|   des-cbc(confounder  + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
-+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
-
-The format cannot be described in ASN.1, but for  those  who
-prefer an ASN.1-like notation:
-
-des-mac-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                       confounder[0]   UNTAGGED OCTET STRING(8),
-                       check[1]        UNTAGGED OCTET STRING(8)
-}
-
-
-     The DES specifications identify some "weak" and  "semi-
-weak"  keys;  those  keys  shall  not be used for generating
-DES-MAC checksums for use in Kerberos, nor shall  a  key  be
-used whose variant is "weak" or "semi-weak".
-
-6.4.7.  RSA MD4 Cryptographic Checksum Using DES alternative
-(rsa-md4-des-k)
-
-     The   RSA-MD4-DES-K   checksum   calculates   a   keyed
-collision-proof  checksum  by  applying the RSA MD4 checksum
-algorithm and encrypting the results using  DES  in  cipher-
-block-chaining  (CBC)  mode  using a DES key as both key and
-initialization vector.  The resulting checksum is 16  octets
-long.   This  checksum  is  tamper-proof  and believed to be
-collision-proof.  Note that this checksum type  is  the  old
-method  for  encoding  the RSA-MD4-DES checksum and it is no
-
-
-Section 6.4.7.             - 86 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-longer recommended.
-
-6.4.8.  DES cipher-block chained checksum alternative  (des-
-mac-k)
-
-     The DES-MAC-K checksum is computed by performing a  DES
-CBC-mode  encryption  of  the  plaintext, and using the last
-block of the ciphertext as the checksum value.  It is  keyed
-with  an  encryption  key  and an initialization vector; any
-uses which do not specify an additional initialization  vec-
-tor  will use the key as both key and initialization vector.
-The resulting checksum is 64 bits  (8  octets)  long.   This
-checksum  is  tamper-proof  and  collision-proof.  Note that
-this checksum type is the old method for encoding  the  DES-
-MAC checksum and it is no longer recommended.
-
-     The DES specifications identify some  "weak  keys"  and
-"semi-weak  keys"; those keys shall not be used for generat-
-ing DES-MAC checksums for use in Kerberos.
-
-7.  Naming Constraints
-
-
-7.1.  Realm Names
-
-     Although realm names are encoded as GeneralStrings  and
-although a realm can technically select any name it chooses,
-interoperability across realm boundaries requires  agreement
-on  how realm names are to be assigned, and what information
-they imply.
-
-     To enforce these conventions, each realm  must  conform
-to  the  conventions  itself,  and  it must require that any
-realms with which inter-realm keys are shared  also  conform
-to the conventions and require the same from its neighbors.
-
-     Kerberos realm names are case sensitive.   Realm  names
-that  differ  only  in  the  case  of the characters are not
-equivalent.  There are presently four styles of realm names:
-domain,  X500,  other, and reserved.  Examples of each style
-follow:
-
-     domain:   ATHENA.MIT.EDU (example)
-       X500:   C=US/O=OSF (example)
-      other:   NAMETYPE:rest/of.name=without-restrictions (example)
-   reserved:   reserved, but will not conflict with above
-
-
-Domain names must look like domain names:  they  consist  of
-components separated by periods (.) and they contain neither
-colons (:) nor slashes (/).  Domain names must be  converted
-to upper case when used as realm names.
-
-     X.500 names contain an equal (=) and cannot  contain  a
-
-
-Section 7.1.               - 87 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-colon (:) before the equal.  The realm names for X.500 names
-will be string representations of the names with  components
-separated by slashes.  Leading and trailing slashes will not
-be included.
-
-     Names that fall into the other category must begin with
-a  prefix  that  contains no equal (=) or period (.) and the
-prefix must be followed by a colon (:) and the rest  of  the
-name.   All  prefixes  must  be  assigned before they may be
-used.  Presently none are assigned.
-
-     The reserved category includes  strings  which  do  not
-fall  into  the  first  three categories.  All names in this
-category are reserved.  It is unlikely that  names  will  be
-assigned  to  this  category  unless  there is a very strong
-argument for not using the "other" category.
-
-     These rules guarantee that there will be  no  conflicts
-between  the  various name styles.  The following additional
-constraints apply to the assignment of realm  names  in  the
-domain  and  X.500  categories:  the name of a realm for the
-domain or X.500 formats must either be used by the organiza-
-tion  owning  (to  whom  it was assigned) an Internet domain
-name or X.500 name, or in the case that no  such  names  are
-registered,  authority  to  use  a realm name may be derived
-from the authority of the  parent  realm.  For  example,  if
-there  is  no domain name for E40.MIT.EDU, then the adminis-
-trator of the MIT.EDU realm can authorize the creation of  a
-realm with that name.
-
-     This is acceptable because the  organization  to  which
-the  parent  is  assigned  is  presumably  the  organization
-authorized to assign names to its children in the X.500  and
-domain  name systems as well.  If the parent assigns a realm
-name without also registering it in the domain name or X.500
-hierarchy,  it  is  the parent's responsibility to make sure
-that there will not in the future exists a name identical to
-the  realm  name  of  the child unless it is assigned to the
-same entity as the realm name.
-
-
-7.2.  Principal Names
-
-     As was the case for realm names, conventions are needed
-to ensure that all agree on what information is implied by a
-principal name.  The name-type field that  is  part  of  the
-principal  name indicates the kind of information implied by
-the name.  The  name-type  should  be  treated  as  a  hint.
-Ignoring  the  name type, no two names can be the same (i.e.
-at least one of the components, or the realm, must  be  dif-
-ferent).   This  constraint may be eliminated in the future.
-The following name types are defined:
-
-                    name-type      value   meaning
-
-
-Section 7.2.               - 88 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-   NT-UNKNOWN     0   Name type not known
-   NT-PRINCIPAL   1   General principal name (e.g. username, or DCE principal)
-   NT-SRV-INST    2   Service and other unique instance (krbtgt)
-   NT-SRV-HST     3   Service with host name as instance (telnet, rcommands)
-   NT-SRV-XHST    4   Service with slash-separated host name components
-   NT-UID         5   Unique ID
-
-
-When a name implies no information other than its uniqueness
-at a particular time the name type PRINCIPAL should be used.
-The principal name type should be used  for  users,  and  it
-might  also  be  used for a unique server.  If the name is a
-unique machine generated ID that is guaranteed never  to  be
-reassigned  then  the  name type of UID should be used (note
-that it is generally a bad idea to  reassign  names  of  any
-type  since  stale  entries  might  remain in access control
-lists).
-
-     If the first component of a name identifies  a  service
-and  the  remaining  components  identify an instance of the
-service in a server specified manner, then the name type  of
-SRV-INST  should  be  used.  An example of this name type is
-the Kerberos ticket-granting service whose name has a  first
-component  of  krbtgt and a second component identifying the
-realm for which the ticket is valid.
-
-     If instance is a single component following the service
-name  and  the  instance  identifies  the  host on which the
-server is running, then the  name  type  SRV-HST  should  be
-used.   This  type  is  typically used for Internet services
-such as telnet and the Berkeley R commands.  If the separate
-components  of the host name appear as successive components
-following the name of the service, then the name  type  SRV-
-XHST  should  be  used.  This type might be used to identify
-servers on hosts with X.500 names where the slash (/)  might
-otherwise be ambiguous.
-
-     A name type of UNKNOWN should be used when the form  of
-the name is not known.  When comparing names, a name of type
-UNKNOWN will match principals authenticated  with  names  of
-any  type.   A  principal  authenticated with a name of type
-UNKNOWN, however, will only match other names of  type  UNK-
-NOWN.
-
-     Names of any type with an initial component of "krbtgt"
-are  reserved for the Kerberos ticket granting service.  See
-section 8.2.3 for the form of such names.
-
-7.2.1.  Name of server principals
-
-     The principal identifier for a server on  a  host  will
-generally be composed of two parts: (1) the realm of the KDC
-with which the server is registered, and (2) a two-component
-
-
-Section 7.2.1.             - 89 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-name  of  type  NT-SRV-HST  if  the host name is an Internet
-domain name or a multi-component name of type NT-SRV-XHST if
-the  name of the host is of a form such as X.500 that allows
-slash (/) separators.  The first component of  the  two-  or
-multi-component  name  will  identify  the  service  and the
-latter components will identify the host.  Where the name of
-the  host  is not case sensitive (for example, with Internet
-domain names) the name of the host must be lower  case.   If
-specified  by  the application protocol for services such as
-telnet and the Berkeley R commands  which  run  with  system
-privileges,  the  first  component  may be the string "host"
-instead of a service specific identifier.  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.
-
-8.  Constants and other defined values
-
-
-8.1.  Host address types
-
-     All negative values  for  the  host  address  type  are
-reserved   for  local  use.   All  non-negative  values  are
-reserved for officially assigned type fields and interpreta-
-tions.
-
-     The values of the types for the following addresses are
-chosen  to match the defined address family constants in the
-Berkeley Standard Distributions of Unix.  They can be  found
-in  <sys/socket.h>  with symbolic names AF_xxx (where xxx is
-an abbreviation of the address family name).
-
-
-Internet addresses
-
-     Internet addresses  are  32-bit  (4-octet)  quantities,
-encoded in MSB order.  The type of internet addresses is two
-(2).
-
-CHAOSnet addresses
-
-     CHAOSnet addresses  are  16-bit  (2-octet)  quantities,
-encoded  in  MSB  order.   The type of CHAOSnet addresses is
-five (5).
-
-ISO addresses
-
-     ISO addresses are variable-length.   The  type  of  ISO
-addresses is seven (7).
-
-Xerox Network Services (XNS) addresses
-
-     XNS addresses are 48-bit (6-octet) quantities,  encoded
-in MSB order.  The type of XNS addresses is six (6).
-
-
-Section 8.1.               - 90 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-AppleTalk Datagram Delivery Protocol (DDP) addresses
-
-     AppleTalk DDP addresses consist of an 8-bit node number
-and a 16-bit network number.  The first octet of the address
-is the node number; the remaining two octets encode the net-
-work  number  in  MSB  order.   The  type  of  AppleTalk DDP
-addresses is sixteen (16).
-
-DECnet Phase IV addresses
-
-     DECnet Phase IV addresses are 16-bit addresses, encoded
-in  LSB  order.   The  type  of DECnet Phase IV addresses is
-twelve (12).
-
-8.2.  KDC messages
-
-8.2.1.  IP transport
-
-     When  contacting  a  Kerberos  server   (KDC)   for   a
-KRB_KDC_REQ request using UDP IP transport, the client shall
-send a UDP datagram  containing  only  an  encoding  of  the
-request  to  port  88 (decimal) at the KDC's IP address; the
-KDC will respond with a reply datagram  containing  only  an
-encoding  of  the  reply  message  (either  a KRB_ERROR or a
-KRB_KDC_REP) to the sending port at the sender's IP address.
-
-     Kerberos servers supporting IP  transport  must  accept
-UDP  requests on port 88 (decimal).  Servers may also accept
-TCP requests on port 88  (decimal).   When  the  KRB_KDC_REQ
-message  is sent to the KDC by TCP, a new connection will be
-established  for  each  authentication  exchange   and   the
-KRB_KDC_REP  or  KRB_ERROR  message  will be returned to the
-client on the  TCP  stream  that  was  established  for  the
-request.   The connection will be broken after the reply has
-been received (or upon time-out).  Care  must  be  taken  in
-managing  TCP/IP  connections with the KDC to prevent denial
-of service attacks based on the number of TCP/IP connections
-with the KDC that remain open.
-
-8.2.2.  OSI transport
-
-     During authentication  of  an  OSI  client  to  an  OSI
-server, the mutual authentication of an OSI server to an OSI
-client, the transfer of credentials from an OSI client to an
-OSI  server,  or  during  exchange  of  private or integrity
-checked messages, Kerberos protocol messages may be  treated
-as opaque objects and the type of the authentication mechan-
-ism will be:
-
-OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),
-                       kerberosv5(2)} 
-
-Depending on the situation, the opaque  object  will  be  an
-authentication  header (KRB_AP_REQ), an authentication reply
-(KRB_AP_REP), a safe message (KRB_SAFE), a  private  message
-
-
-Section 8.2.2.             - 91 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-(KRB_PRIV), or a credentials message (KRB_CRED).  The opaque
-data contains an application code as specified in the  ASN.1
-description  for  each message.  The application code may be
-used by Kerberos to determine the message type.
-
-8.2.3.  Name of the TGS
-
-     The principal identifier of the ticket-granting service
-shall  be  composed of three parts: (1) the realm of the KDC
-issuing the TGS ticket (2) a two-part name of  type  NT-SRV-
-INST,  with  the first part "krbtgt" and the second part the
-name of the realm  which  will  accept  the  ticket-granting
-ticket.  For example, a ticket-granting ticket issued by the
-ATHENA.MIT.EDU realm to be used  to  get  tickets  from  the
-ATHENA.MIT.EDU   KDC   has   a   principal   identifier   of
-"ATHENA.MIT.EDU"   (realm),   ("krbtgt",   "ATHENA.MIT.EDU")
-(name).     A   ticket-granting   ticket   issued   by   the
-ATHENA.MIT.EDU realm to be used  to  get  tickets  from  the
-MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU"
-(realm), ("krbtgt", "MIT.EDU") (name).
-
-
-8.3.  Protocol constants and associated values
-
-The following tables list constants used in the protocol and defines their
-meanings.
-
-Encryption type  etype value  block size    minimum pad size  confounder size
-NULL              0            1                 0                 0
-des-cbc-crc       1            8                 4                 8
-des-cbc-md4       2            8                 0                 8
-des-cbc-md5       3            8                 0                 8
-<reserved>        4
-des3-cbc-md5      5            8                 0                 8
-<reserved>        6
-des3-cbc-sha1     7            8                 0                 8
-sign-dsa-generate 8                                   (pkinit)
-encrypt-rsa-priv  9                                   (pkinit)
-encrypt-rsa-pub  10                                   (pkinit)
-ENCTYPE_PK_CROSS 48                                   (reserved for pkcross)
-<reserved>       0x8003
-
-Checksum type              sumtype value       checksum size
-CRC32                      1                   4
-rsa-md4                    2                   16
-rsa-md4-des                3                   24
-des-mac                    4                   16
-des-mac-k                  5                   8
-rsa-md4-des-k              6                   16
-rsa-md5                    7                   16
-rsa-md5-des                8                   24
-rsa-md5-des3               9                   24
-hmac-sha1-des3             10                  20  (I had this as 10, is it 12)
-
-
-Section 8.3.               - 92 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-padata type                     padata-type value
-
-PA-TGS-REQ                      1
-PA-ENC-TIMESTAMP                2
-PA-PW-SALT                      3
-<reserved>                      4
-PA-ENC-UNIX-TIME                5
-PA-SANDIA-SECUREID              6
-PA-SESAME                       7
-PA-OSF-DCE                      8
-PA-CYBERSAFE-SECUREID           9
-PA-AFS3-SALT                    10
-PA-ETYPE-INFO                   11
-SAM-CHALLENGE                   12                  (sam/otp)
-SAM-RESPONSE                    13                  (sam/otp)
-PA-PK-AS-REQ                    14                  (pkinit)
-PA-PK-AS-REP                    15                  (pkinit)
-PA-PK-AS-SIGN                   16                  (pkinit)
-PA-PK-KEY-REQ                   17                  (pkinit)
-PA-PK-KEY-REP                   18                  (pkinit)
-
-authorization data type         ad-type value
-reserved values                 0-63
-OSF-DCE                         64
-SESAME                          65
-
-alternate authentication type   method-type value
-reserved values                 0-63
-ATT-CHALLENGE-RESPONSE          64
-
-transited encoding type         tr-type value
-DOMAIN-X500-COMPRESS            1
-reserved values                 all others
-
-
-
-Label               Value   Meaning or MIT code
-
-pvno                    5   current Kerberos protocol version number
-
-message types
-
-KRB_AS_REQ             10   Request for initial authentication
-KRB_AS_REP             11   Response to KRB_AS_REQ request
-KRB_TGS_REQ            12   Request for authentication based on TGT
-KRB_TGS_REP            13   Response to KRB_TGS_REQ request
-KRB_AP_REQ             14   application request to server
-KRB_AP_REP             15   Response to KRB_AP_REQ_MUTUAL
-KRB_SAFE               20   Safe (checksummed) application message
-KRB_PRIV               21   Private (encrypted) application message
-KRB_CRED               22   Private (encrypted) message to forward credentials
-KRB_ERROR              30   Error response
-
-
-Section 8.3.               - 93 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-name types
-
-KRB_NT_UNKNOWN       0   Name type not known
-KRB_NT_PRINCIPAL     1   Just the name of the principal as in DCE, or for users
-KRB_NT_SRV_INST      2   Service and other unique instance (krbtgt)
-KRB_NT_SRV_HST       3   Service with host name as instance (telnet, rcommands)
-KRB_NT_SRV_XHST      4   Service with host as remaining components
-KRB_NT_UID           5   Unique ID
-
-error codes
-
-KDC_ERR_NONE                    0   No error
-KDC_ERR_NAME_EXP                1   Client's entry in database has expired
-KDC_ERR_SERVICE_EXP             2   Server's entry in database has expired
-KDC_ERR_BAD_PVNO                3   Requested protocol version number not supported
-KDC_ERR_C_OLD_MAST_KVNO         4   Client's key encrypted in old master key
-KDC_ERR_S_OLD_MAST_KVNO         5   Server's key encrypted in old master key
-KDC_ERR_C_PRINCIPAL_UNKNOWN     6   Client not found in Kerberos database
-KDC_ERR_S_PRINCIPAL_UNKNOWN     7   Server not found in Kerberos database
-KDC_ERR_PRINCIPAL_NOT_UNIQUE    8   Multiple principal entries in database
-KDC_ERR_NULL_KEY                9   The client or server has a null key
-KDC_ERR_CANNOT_POSTDATE        10   Ticket not eligible for postdating
-KDC_ERR_NEVER_VALID            11   Requested start time is later than end time
-KDC_ERR_POLICY                 12   KDC policy rejects request
-KDC_ERR_BADOPTION              13   KDC cannot accommodate requested option
-KDC_ERR_ETYPE_NOSUPP           14   KDC has no support for encryption type
-KDC_ERR_SUMTYPE_NOSUPP         15   KDC has no support for checksum type
-KDC_ERR_PADATA_TYPE_NOSUPP     16   KDC has no support for padata type
-KDC_ERR_TRTYPE_NOSUPP          17   KDC has no support for transited type
-KDC_ERR_CLIENT_REVOKED         18   Clients credentials have been revoked
-KDC_ERR_SERVICE_REVOKED        19   Credentials for server have been revoked
-KDC_ERR_TGT_REVOKED            20   TGT has been revoked
-KDC_ERR_CLIENT_NOTYET          21   Client not yet valid - try again later
-KDC_ERR_SERVICE_NOTYET         22   Server not yet valid - try again later
-KDC_ERR_KEY_EXPIRED            23   Password has expired - change password to reset
-KDC_ERR_PREAUTH_FAILED         24   Pre-authentication information was invalid
-KDC_ERR_PREAUTH_REQUIRED       25   Additional pre-authenticationrequired-
-KDC_ERR_SERVER_NOMATCH         26   Requested server and ticket don't match
-KDC_ERR_MUST_USE_USER2USER     27   Server principal valid for user2user only
-KDC_ERR_PATH_NOT_ACCPETED      28   KDC Policy rejects transited path
-KRB_AP_ERR_BAD_INTEGRITY       31   Integrity check on decrypted field failed
-KRB_AP_ERR_TKT_EXPIRED         32   Ticket expired
-KRB_AP_ERR_TKT_NYV             33   Ticket not yet valid
-KRB_AP_ERR_REPEAT              34   Request is a replay
-KRB_AP_ERR_NOT_US              35   The ticket isn't for us
-KRB_AP_ERR_BADMATCH            36   Ticket and authenticator don't match
-KRB_AP_ERR_SKEW                37   Clock skew too great
-KRB_AP_ERR_BADADDR             38   Incorrect net address
-KRB_AP_ERR_BADVERSION          39   Protocol version mismatch
-KRB_AP_ERR_MSG_TYPE            40   Invalid msg type
-KRB_AP_ERR_MODIFIED            41   Message stream modified
-KRB_AP_ERR_BADORDER            42   Message out of order
-KRB_AP_ERR_BADKEYVER           44   Specified version of key is not available
-KRB_AP_ERR_NOKEY               45   Service key not available
-KRB_AP_ERR_MUT_FAIL            46   Mutual authentication failed
-KRB_AP_ERR_BADDIRECTION        47   Incorrect message direction
-KRB_AP_ERR_METHOD              48   Alternative authentication method required
-KRB_AP_ERR_BADSEQ              49   Incorrect sequence number in message
-
-
-
-Section 8.3.               - 94 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-KRB_AP_ERR_INAPP_CKSUM         50   Inappropriate type of checksum in message
-KRB_ERR_GENERIC                60   Generic error (description in e-text)
-KRB_ERR_FIELD_TOOLONG          61   Field is too long for this implementation
-KDC_ERROR_CLIENT_NOT_TRUSTED   62   (pkinit)
-KDC_ERROR_KDC_NOT_TRUSTED      63   (pkinit)
-KDC_ERROR_INVALID_SIG          64   (pkinit)
-KDC_ERR_KEY_TOO_WEAK           65   (pkinit)
-
-
-9.  Interoperability requirements
-
-     Version 5 of the Kerberos protocol supports a myriad of
-options.   Among  these are multiple encryption and checksum
-types, alternative encoding schemes for the transited field,
-optional  mechanisms for pre-authentication, the handling of
-tickets with no addresses, options  for  mutual  authentica-
-tion, user to user authentication, support for proxies, for-
-warding, postdating, and renewing  tickets,  the  format  of
-realm names, and the handling of authorization data.
-
-     In order to ensure the interoperability of  realms,  it
-is necessary to define a minimal configuration which must be
-supported by all implementations.  This  minimal  configura-
-tion  is subject to change as technology does.  For example,
-if at some later date it  is  discovered  that  one  of  the
-required encryption or checksum algorithms is not secure, it
-will be replaced.
-
-9.1.  Specification 1
-
-     This section defines the first specification  of  these
-options.   Implementations  which are configured in this way
-can be said to support Kerberos Version  5  Specification  1
-(5.1).
-
-Encryption and checksum methods
-
-The following encryption and  checksum  mechanisms  must  be
-supported.   Implementations may support other mechanisms as
-well, but the additional mechanisms may only  be  used  when
-communicating with principals known to also support them:
-This list is to be determined.
-Encryption: DES-CBC-MD5
-Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
-
-
-__________________________
-- This error carries additional information in  the  e-
-data  field.  The contents of the e-data field for this
-message is described in section 5.9.1.
-
-
-
-Section 9.1.               - 95 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-Realm Names
-
-All implementations must understand hierarchical  realms  in
-both the Internet Domain and the X.500 style.  When a ticket
-granting ticket for an unknown realm is requested,  the  KDC
-must  be  able  to  determine  the names of the intermediate
-realms between the KDCs realm and the requested realm.
-
-Transited field encoding
-
-DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must  be
-supported.  Alternative encodings may be supported, but they
-may be used only when that  encoding  is  supported  by  ALL
-intermediate realms.
-
-Pre-authentication methods
-
-The TGS-REQ method must be supported.  The TGS-REQ method is
-not  used  on  the  initial  request.   The PA-ENC-TIMESTAMP
-method must be  supported  by  clients  but  whether  it  is
-enabled  by  default  may  be determined on a realm by realm
-basis.  If not used in the initial  request  and  the  error
-KDC_ERR_PREAUTH_REQUIRED   is  returned  specifying  PA-ENC-
-TIMESTAMP as an acceptable method, the client  should  retry
-the   initial   request   using  the  PA-ENC-TIMESTAMP  pre-
-authentication method.  Servers need  not  support  the  PA-
-ENC-TIMESTAMP method, but if not supported the server should
-ignore the presence of  PA-ENC-TIMESTAMP  pre-authentication
-in a request.
-
-Mutual authentication
-
-Mutual authentication (via the KRB_AP_REP message)  must  be
-supported.
-
-
-Ticket addresses and flags
-
-All KDC's must pass on tickets that carry no addresses (i.e.
-if  a TGT contains no addresses, the KDC will return deriva-
-tive tickets), but each realm may set  its  own  policy  for
-issuing  such  tickets, and each application server will set
-its own policy with respect to accepting them.
-
-     Proxies and forwarded tickets must be supported.  Indi-
-vidual realms and application servers can set their own pol-
-icy on when such tickets will be accepted.
-
-     All implementations must recognize renewable and  post-
-dated  tickets,  but  need  not actually implement them.  If
-these options are not supported, the starttime  and  endtime
-in  the  ticket shall specify a ticket's entire useful life.
-When a postdated ticket is decoded by a server,  all  imple-
-mentations  shall  make  the  presence of the postdated flag
-
-
-Section 9.1.               - 96 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-visible to the calling server.
-
-User-to-user authentication
-
-Support for user to user authentication  (via  the  ENC-TKT-
-IN-SKEY KDC option) must be provided by implementations, but
-individual realms may decide as a matter of policy to reject
-such requests on a per-principal or realm-wide basis.
-
-Authorization data
-
-Implementations must pass all authorization  data  subfields
-from  ticket-granting  tickets  to  any  derivative  tickets
-unless directed to suppress a subfield as part of the defin-
-ition   of  that  registered  subfield  type  (it  is  never
-incorrect to pass on a subfield, and no registered  subfield
-types presently specify suppression at the KDC).
-
-     Implementations must make the contents of any  authori-
-zation  data subfields available to the server when a ticket
-is used.  Implementations are not required to allow  clients
-to specify the contents of the authorization data fields.
-
-9.2.  Recommended KDC values
-
-Following is a list of recommended values for a  KDC  imple-
-mentation, based on the list of suggested configuration con-
-stants (see section 4.4).
-
-minimum lifetime    5 minutes
-
-maximum renewable lifetime1 week
-
-maximum ticket lifetime1 day
-
-empty addresses     only when suitable  restrictions  appear
-                    in authorization data
-
-proxiable, etc.     Allowed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Section 9.2.               - 97 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-10.  REFERENCES
-
-
-
-1.   B. Clifford Neuman and Theodore Y. Ts'o, "An  Authenti-
-     cation  Service for Computer Networks," IEEE Communica-
-     tions Magazine, Vol. 32(9), pp. 33-38 (September 1994).
-
-2.   S. P. Miller, B. C. Neuman, J. I. Schiller, and  J.  H.
-     Saltzer,  Section  E.2.1:  Kerberos  Authentication and
-     Authorization System, M.I.T. Project Athena, Cambridge,
-     Massachusetts (December 21, 1987).
-
-3.   J. G. Steiner, B. C. Neuman, and J. I. Schiller,  "Ker-
-     beros:  An Authentication Service for Open Network Sys-
-     tems," pp. 191-202 in  Usenix  Conference  Proceedings,
-     Dallas, Texas (February, 1988).
-
-4.   Roger M.  Needham  and  Michael  D.  Schroeder,  "Using
-     Encryption for Authentication in Large Networks of Com-
-     puters,"  Communications  of  the  ACM,  Vol.   21(12),
-     pp. 993-999 (December, 1978).
-
-5.   Dorothy E. Denning and  Giovanni  Maria  Sacco,  "Time-
-     stamps  in  Key Distribution Protocols," Communications
-     of the ACM, Vol. 24(8), pp. 533-536 (August 1981).
-
-6.   John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o,
-     "The Evolution of the Kerberos Authentication Service,"
-     in an IEEE Computer Society Text soon to  be  published
-     (June 1992).
-
-7.   B.  Clifford  Neuman,  "Proxy-Based  Authorization  and
-     Accounting  for Distributed Systems," in Proceedings of
-     the 13th International Conference on  Distributed  Com-
-     puting Systems, Pittsburgh, PA (May, 1993).
-
-8.   Don Davis and Ralph Swick,  "Workstation  Services  and
-     Kerberos  Authentication  at Project Athena," Technical
-     Memorandum TM-424,  MIT Laboratory for Computer Science
-     (February 1990).
-
-9.   P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E.  Som-
-     merfeld,  and  K. Raeburn, Section E.1: Service Manage-
-     ment System, M.I.T.  Project  Athena,  Cambridge,  Mas-
-     sachusetts (1987).
-
-10.  CCITT, Recommendation X.509: The Directory  Authentica-
-     tion Framework, December 1988.
-
-11.  J. Pato, Using  Pre-Authentication  to  Avoid  Password
-     Guessing  Attacks, Open Software Foundation DCE Request
-     for Comments 26 (December 1992).
-
-
-
-Section 10.                - 98 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-12.  National Bureau of Standards, U.S. Department  of  Com-
-     merce,  "Data Encryption Standard," Federal Information
-     Processing Standards Publication  46,   Washington,  DC
-     (1977).
-
-13.  National Bureau of Standards, U.S. Department  of  Com-
-     merce,  "DES  Modes  of Operation," Federal Information
-     Processing Standards Publication 81,   Springfield,  VA
-     (December 1980).
-
-14.  Stuart G. Stubblebine and Virgil D. Gligor, "On Message
-     Integrity  in  Cryptographic Protocols," in Proceedings
-     of the IEEE  Symposium  on  Research  in  Security  and
-     Privacy, Oakland, California (May 1992).
-
-15.  International Organization  for  Standardization,  "ISO
-     Information  Processing  Systems - Data Communication -
-     High-Level Data Link Control Procedure -  Frame  Struc-
-     ture," IS 3309 (October 1984).  3rd Edition.
-
-16.  R. Rivest, "The  MD4  Message  Digest  Algorithm,"  RFC
-     1320,   MIT  Laboratory  for  Computer  Science  (April
-     1992).
-
-17.  R. Rivest, "The  MD5  Message  Digest  Algorithm,"  RFC
-     1321,   MIT  Laboratory  for  Computer  Science  (April
-     1992).
-
-18.  H. Krawczyk, M. Bellare, and R. Canetti, "HMAC:  Keyed-
-     Hashing  for  Message  Authentication,"  Working  Draft
-     draft-ietf-ipsec-hmac-md5-01.txt,   (August 1996).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Section 10.                - 99 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-A.  Pseudo-code for protocol processing
-
-     This appendix provides pseudo-code describing  how  the
-messages  are  to  be constructed and interpreted by clients
-and servers.
-
-A.1.  KRB_AS_REQ generation
-        request.pvno := protocol version; /* pvno = 5 */
-        request.msg-type := message type; /* type = KRB_AS_REQ */
-
-        if(pa_enc_timestamp_required) then
-                request.padata.padata-type = PA-ENC-TIMESTAMP;
-                get system_time;
-                padata-body.patimestamp,pausec = system_time;
-                encrypt padata-body into request.padata.padata-value
-                        using client.key; /* derived from password */
-        endif
-
-        body.kdc-options := users's preferences;
-        body.cname := user's name;
-        body.realm := user's realm;
-        body.sname := service's name; /* usually "krbtgt",  "localrealm" */
-        if (body.kdc-options.POSTDATED is set) then
-                body.from := requested starting time;
-        else
-                omit body.from;
-        endif
-        body.till := requested end time;
-        if (body.kdc-options.RENEWABLE is set) then
-                body.rtime := requested final renewal time;
-        endif
-        body.nonce := random_nonce();
-        body.etype := requested etypes;
-        if (user supplied addresses) then
-                body.addresses := user's addresses;
-        else
-                omit body.addresses;
-        endif
-        omit body.enc-authorization-data;
-        request.req-body := body;
-
-        kerberos := lookup(name of local kerberos server (or servers));
-        send(packet,kerberos);
-
-        wait(for response);
-        if (timed_out) then
-                retry or use alternate server;
-        endif
-
-A.2.  KRB_AS_REQ verification and KRB_AS_REP generation
-        decode message into req;
-
-        client := lookup(req.cname,req.realm);
-        server := lookup(req.sname,req.realm);
-
-
-Section A.2.              - 100 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-
-        get system_time;
-        kdc_time := system_time.seconds;
-
-        if (!client) then
-                /* no client in Database */
-                error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
-        endif
-        if (!server) then
-                /* no server in Database */
-                error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
-        endif
-
-        if(client.pa_enc_timestamp_required and
-           pa_enc_timestamp not present) then
-                error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
-        endif
-
-        if(pa_enc_timestamp present) then
-                decrypt req.padata-value into decrypted_enc_timestamp
-                        using client.key;
-                        using auth_hdr.authenticator.subkey;
-                if (decrypt_error()) then
-                        error_out(KRB_AP_ERR_BAD_INTEGRITY);
-                if(decrypted_enc_timestamp is not within allowable skew) then
-                        error_out(KDC_ERR_PREAUTH_FAILED);
-                endif
-                if(decrypted_enc_timestamp and usec is replay)
-                        error_out(KDC_ERR_PREAUTH_FAILED);
-                endif
-                add decrypted_enc_timestamp and usec to replay cache;
-        endif
-
-        use_etype := first supported etype in req.etypes;
-
-        if (no support for req.etypes) then
-                error_out(KDC_ERR_ETYPE_NOSUPP);
-        endif
-
-        new_tkt.vno := ticket version; /* = 5 */
-        new_tkt.sname := req.sname;
-        new_tkt.srealm := req.srealm;
-        reset all flags in new_tkt.flags;
-
-        /* It should be noted that local policy may affect the  */
-        /* processing of any of these flags.  For example, some */
-        /* realms may refuse to issue renewable tickets         */
-
-        if (req.kdc-options.FORWARDABLE is set) then
-                set new_tkt.flags.FORWARDABLE;
-        endif
-        if (req.kdc-options.PROXIABLE is set) then
-                set new_tkt.flags.PROXIABLE;
-        endif
-
-
-Section A.2.              - 101 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-        if (req.kdc-options.ALLOW-POSTDATE is set) then
-                set new_tkt.flags.MAY-POSTDATE;
-        endif
-        if ((req.kdc-options.RENEW is set) or
-            (req.kdc-options.VALIDATE is set) or
-            (req.kdc-options.PROXY is set) or
-            (req.kdc-options.FORWARDED is set) or
-            (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
-                error_out(KDC_ERR_BADOPTION);
-        endif
-
-        new_tkt.session := random_session_key();
-        new_tkt.cname := req.cname;
-        new_tkt.crealm := req.crealm;
-        new_tkt.transited := empty_transited_field();
-
-        new_tkt.authtime := kdc_time;
-
-        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 omitted */
-        endif
-        if (req.till = 0) then
-                till := infinity;
-        else
-                till := req.till;
-        endif
-
-        new_tkt.endtime := min(till,
-                              new_tkt.starttime+client.max_life,
-                              new_tkt.starttime+server.max_life,
-                              new_tkt.starttime+max_life_for_realm);
-
-        if ((req.kdc-options.RENEWABLE-OK is set) and
-            (new_tkt.endtime < req.till)) then
-                /* we set the RENEWABLE option for later processing */
-                set req.kdc-options.RENEWABLE;
-                req.rtime := req.till;
-        endif
-
-        if (req.rtime = 0) then
-                rtime := infinity;
-        else
-                rtime := req.rtime;
-        endif
-
-        if (req.kdc-options.RENEWABLE is set) then
-                set new_tkt.flags.RENEWABLE;
-
-
-Section A.2.              - 102 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-                new_tkt.renew-till := min(rtime,
-                                          new_tkt.starttime+client.max_rlife,
-                                          new_tkt.starttime+server.max_rlife,
-                                          new_tkt.starttime+max_rlife_for_realm);
-        else
-                omit new_tkt.renew-till; /* only present if RENEWABLE */
-        endif
-
-        if (req.addresses) then
-                new_tkt.caddr := req.addresses;
-        else
-                omit new_tkt.caddr;
-        endif
-
-        new_tkt.authorization_data := empty_authorization_data();
-
-        encode to-be-encrypted part of ticket into OCTET STRING;
-        new_tkt.enc-part := encrypt OCTET STRING
-                using etype_for_key(server.key), server.key, server.p_kvno;
-
-
-        /* Start processing the response */
-
-        resp.pvno := 5;
-        resp.msg-type := KRB_AS_REP;
-        resp.cname := req.cname;
-        resp.crealm := req.realm;
-        resp.ticket := new_tkt;
-
-        resp.key := new_tkt.session;
-        resp.last-req := fetch_last_request_info(client);
-        resp.nonce := req.nonce;
-        resp.key-expiration := client.expiration;
-        resp.flags := new_tkt.flags;
-
-        resp.authtime := new_tkt.authtime;
-        resp.starttime := new_tkt.starttime;
-        resp.endtime := new_tkt.endtime;
-
-        if (new_tkt.flags.RENEWABLE) then
-                resp.renew-till := new_tkt.renew-till;
-        endif
-
-        resp.realm := new_tkt.realm;
-        resp.sname := new_tkt.sname;
-
-        resp.caddr := new_tkt.caddr;
-
-        encode body of reply into OCTET STRING;
-
-        resp.enc-part := encrypt OCTET STRING
-                         using use_etype, client.key, client.p_kvno;
-        send(resp);
-
-
-
-Section A.2.              - 103 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-A.3.  KRB_AS_REP verification
-        decode response into resp;
-
-        if (resp.msg-type = KRB_ERROR) then
-                if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then
-                        set pa_enc_timestamp_required;
-                        goto KRB_AS_REQ;
-                endif
-                process_error(resp);
-                return;
-        endif
-
-        /* On error, discard the response, and zero the session key */
-        /* from the response immediately */
-
-        key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
-                                 resp.padata);
-        unencrypted part of resp := decode of decrypt of resp.enc-part
-                                using resp.enc-part.etype and key;
-        zero(key);
-
-        if (common_as_rep_tgs_rep_checks fail) then
-                destroy resp.key;
-                return error;
-        endif
-
-        if near(resp.princ_exp) then
-                print(warning message);
-        endif
-        save_for_later(ticket,session,client,server,times,flags);
-
-A.4.  KRB_AS_REP and KRB_TGS_REP common checks
-        if (decryption_error() or
-            (req.cname != resp.cname) or
-            (req.realm != resp.crealm) or
-            (req.sname != resp.sname) or
-            (req.realm != resp.realm) or
-            (req.nonce != resp.nonce) or
-            (req.addresses != resp.caddr)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-        /* make sure no flags are set that shouldn't be, and that all that */
-        /* should be are set                                               */
-        if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-        if ((req.from = 0) and
-            (resp.starttime is not within allowable skew)) then
-                destroy resp.key;
-                return KRB_AP_ERR_SKEW;
-
-
-Section A.4.              - 104 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-        endif
-        if ((req.from != 0) and (req.from != resp.starttime)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-        if ((req.till != 0) and (resp.endtime > req.till)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-        if ((req.kdc-options.RENEWABLE is set) and
-            (req.rtime != 0) and (resp.renew-till > req.rtime)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-        if ((req.kdc-options.RENEWABLE-OK is set) and
-            (resp.flags.RENEWABLE) and
-            (req.till != 0) and
-            (resp.renew-till > req.till)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-A.5.  KRB_TGS_REQ generation
-        /* Note that make_application_request might have to recursivly     */
-        /* call this routine to get the appropriate ticket-granting ticket */
-
-        request.pvno := protocol version; /* pvno = 5 */
-        request.msg-type := message type; /* type = KRB_TGS_REQ */
-
-        body.kdc-options := users's preferences;
-        /* If the TGT is not for the realm of the end-server  */
-        /* then the sname will be for a TGT for the end-realm */
-        /* and the realm of the requested ticket (body.realm) */
-        /* will be that of the TGS to which the TGT we are    */
-        /* sending applies                                    */
-        body.sname := service's name;
-        body.realm := service's realm;
-
-        if (body.kdc-options.POSTDATED is set) then
-                body.from := requested starting time;
-        else
-                omit body.from;
-        endif
-        body.till := requested end time;
-        if (body.kdc-options.RENEWABLE is set) then
-                body.rtime := requested final renewal time;
-        endif
-        body.nonce := random_nonce();
-        body.etype := requested etypes;
-        if (user supplied addresses) then
-                body.addresses := user's addresses;
-        else
-                omit body.addresses;
-
-
-Section A.5.              - 105 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-        endif
-
-        body.enc-authorization-data := user-supplied data;
-        if (body.kdc-options.ENC-TKT-IN-SKEY) then
-                body.additional-tickets_ticket := second TGT;
-        endif
-
-        request.req-body := body;
-        check := generate_checksum (req.body,checksumtype);
-
-        request.padata[0].padata-type := PA-TGS-REQ;
-        request.padata[0].padata-value := create a KRB_AP_REQ using
-                                      the TGT and checksum
-
-        /* add in any other padata as required/supplied */
-
-        kerberos := lookup(name of local kerberose server (or servers));
-        send(packet,kerberos);
-
-        wait(for response);
-        if (timed_out) then
-                retry or use alternate server;
-        endif
-
-A.6.  KRB_TGS_REQ verification and KRB_TGS_REP generation
-        /* note that reading the application request requires first
-        determining the server for which a ticket was issued, and choosing the
-        correct key for decryption.  The name of the server appears in the
-        plaintext part of the ticket. */
-
-        if (no KRB_AP_REQ in req.padata) then
-                error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
-        endif
-        verify KRB_AP_REQ in req.padata;
-
-        /* Note that the realm in which the Kerberos server is operating is
-        determined by the instance from the ticket-granting ticket.  The realm
-        in the ticket-granting ticket is the realm under which the ticket
-        granting ticket was issued.  It is possible for a single Kerberos
-        server to support more than one realm. */
-
-        auth_hdr := KRB_AP_REQ;
-        tgt := auth_hdr.ticket;
-
-        if (tgt.sname is not a TGT for local realm and is not req.sname) then
-                error_out(KRB_AP_ERR_NOT_US);
-
-        realm := realm_tgt_is_for(tgt);
-
-        decode remainder of request;
-
-        if (auth_hdr.authenticator.cksum is missing) then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-
-
-Section A.6.              - 106 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-        if (auth_hdr.authenticator.cksum type is not supported) then
-                error_out(KDC_ERR_SUMTYPE_NOSUPP);
-        endif
-        if (auth_hdr.authenticator.cksum is not both collision-proof and keyed) then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-
-        set computed_checksum := checksum(req);
-        if (computed_checksum != auth_hdr.authenticatory.cksum) then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        server := lookup(req.sname,realm);
-
-        if (!server) then
-                if (is_foreign_tgt_name(server)) then
-                        server := best_intermediate_tgs(server);
-                else
-                        /* no server in Database */
-                        error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
-                endif
-        endif
-
-        session := generate_random_session_key();
-
-
-        use_etype := first supported etype in req.etypes;
-
-        if (no support for req.etypes) then
-                error_out(KDC_ERR_ETYPE_NOSUPP);
-        endif
-
-        new_tkt.vno := ticket version; /* = 5 */
-        new_tkt.sname := req.sname;
-        new_tkt.srealm := realm;
-        reset all flags in new_tkt.flags;
-
-        /* It should be noted that local policy may affect the  */
-        /* processing of any of these flags.  For example, some */
-        /* realms may refuse to issue renewable tickets         */
-
-        new_tkt.caddr := tgt.caddr;
-        resp.caddr := NULL; /* We only include this if they change */
-        if (req.kdc-options.FORWARDABLE is set) then
-                if (tgt.flags.FORWARDABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.FORWARDABLE;
-        endif
-        if (req.kdc-options.FORWARDED is set) then
-                if (tgt.flags.FORWARDABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.FORWARDED;
-
-
-Section A.6.              - 107 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-                new_tkt.caddr := req.addresses;
-                resp.caddr := req.addresses;
-        endif
-        if (tgt.flags.FORWARDED is set) then
-                set new_tkt.flags.FORWARDED;
-        endif
-
-        if (req.kdc-options.PROXIABLE is set) then
-                if (tgt.flags.PROXIABLE is reset)
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.PROXIABLE;
-        endif
-        if (req.kdc-options.PROXY is set) then
-                if (tgt.flags.PROXIABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.PROXY;
-                new_tkt.caddr := req.addresses;
-                resp.caddr := req.addresses;
-        endif
-
-        if (req.kdc-options.ALLOW-POSTDATE is set) then
-                if (tgt.flags.MAY-POSTDATE is reset)
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.MAY-POSTDATE;
-        endif
-        if (req.kdc-options.POSTDATED is set) then
-                if (tgt.flags.MAY-POSTDATE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.POSTDATED;
-                set new_tkt.flags.INVALID;
-                if (against_postdate_policy(req.from)) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-                new_tkt.starttime := req.from;
-        endif
-
-
-        if (req.kdc-options.VALIDATE is set) then
-                if (tgt.flags.INVALID is reset) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-                if (tgt.starttime > kdc_time) then
-                        error_out(KRB_AP_ERR_NYV);
-                endif
-                if (check_hot_list(tgt)) then
-                        error_out(KRB_AP_ERR_REPEAT);
-                endif
-                tkt := tgt;
-                reset new_tkt.flags.INVALID;
-        endif
-
-
-Section A.6.              - 108 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-        if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
-                             and those already processed) is set) then
-                error_out(KDC_ERR_BADOPTION);
-        endif
-
-        new_tkt.authtime := tgt.authtime;
-
-        if (req.kdc-options.RENEW is set) then
-          /* Note that if the endtime has already passed, the ticket would  */
-          /* have been rejected in the initial authentication stage, so     */
-          /* there is no need to check again here                           */
-                if (tgt.flags.RENEWABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                if (tgt.renew-till >= kdc_time) then
-                        error_out(KRB_AP_ERR_TKT_EXPIRED);
-                endif
-                tkt := tgt;
-                new_tkt.starttime := kdc_time;
-                old_life := tgt.endttime - tgt.starttime;
-                new_tkt.endtime := min(tgt.renew-till,
-                                       new_tkt.starttime + old_life);
-        else
-                new_tkt.starttime := kdc_time;
-                if (req.till = 0) then
-                        till := infinity;
-                else
-                        till := req.till;
-                endif
-                new_tkt.endtime := min(till,
-                                       new_tkt.starttime+client.max_life,
-                                       new_tkt.starttime+server.max_life,
-                                       new_tkt.starttime+max_life_for_realm,
-                                       tgt.endtime);
-
-                if ((req.kdc-options.RENEWABLE-OK is set) and
-                    (new_tkt.endtime < req.till) and
-                    (tgt.flags.RENEWABLE is set) then
-                        /* we set the RENEWABLE option for later processing */
-                        set req.kdc-options.RENEWABLE;
-                        req.rtime := min(req.till, tgt.renew-till);
-                endif
-        endif
-
-        if (req.rtime = 0) then
-                rtime := infinity;
-        else
-                rtime := req.rtime;
-        endif
-
-        if ((req.kdc-options.RENEWABLE is set) and
-            (tgt.flags.RENEWABLE is set)) then
-                set new_tkt.flags.RENEWABLE;
-                new_tkt.renew-till := min(rtime,
-
-
-Section A.6.              - 109 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-                                          new_tkt.starttime+client.max_rlife,
-                                          new_tkt.starttime+server.max_rlife,
-                                          new_tkt.starttime+max_rlife_for_realm,
-                                          tgt.renew-till);
-        else
-                new_tkt.renew-till := OMIT; /* leave the renew-till field out */
-        endif
-        if (req.enc-authorization-data is present) then
-                decrypt req.enc-authorization-data into decrypted_authorization_data
-                        using auth_hdr.authenticator.subkey;
-                if (decrypt_error()) then
-                        error_out(KRB_AP_ERR_BAD_INTEGRITY);
-                endif
-        endif
-        new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data +
-                                 decrypted_authorization_data;
-
-        new_tkt.key := session;
-        new_tkt.crealm := tgt.crealm;
-        new_tkt.cname := req.auth_hdr.ticket.cname;
-
-        if (realm_tgt_is_for(tgt) := tgt.realm) then
-                /* tgt issued by local realm */
-                new_tkt.transited := tgt.transited;
-        else
-                /* was issued for this realm by some other realm */
-                if (tgt.transited.tr-type not supported) then
-                        error_out(KDC_ERR_TRTYPE_NOSUPP);
-                endif
-                new_tkt.transited := compress_transited(tgt.transited + tgt.realm)
-        endif
-
-        encode encrypted part of new_tkt into OCTET STRING;
-        if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
-                if (server not specified) then
-                        server = req.second_ticket.client;
-                endif
-                if ((req.second_ticket is not a TGT) or
-                    (req.second_ticket.client != server)) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-
-                new_tkt.enc-part := encrypt OCTET STRING using
-                        using etype_for_key(second-ticket.key), second-ticket.key;
-        else
-                new_tkt.enc-part := encrypt OCTET STRING
-                        using etype_for_key(server.key), server.key, server.p_kvno;
-        endif
-
-        resp.pvno := 5;
-        resp.msg-type := KRB_TGS_REP;
-        resp.crealm := tgt.crealm;
-        resp.cname := tgt.cname;
-
-
-
-Section A.6.              - 110 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-        resp.ticket := new_tkt;
-
-        resp.key := session;
-        resp.nonce := req.nonce;
-        resp.last-req := fetch_last_request_info(client);
-        resp.flags := new_tkt.flags;
-
-        resp.authtime := new_tkt.authtime;
-        resp.starttime := new_tkt.starttime;
-        resp.endtime := new_tkt.endtime;
-
-        omit resp.key-expiration;
-
-        resp.sname := new_tkt.sname;
-        resp.realm := new_tkt.realm;
-
-        if (new_tkt.flags.RENEWABLE) then
-                resp.renew-till := new_tkt.renew-till;
-        endif
-
-
-        encode body of reply into OCTET STRING;
-
-        if (req.padata.authenticator.subkey)
-                resp.enc-part := encrypt OCTET STRING using use_etype,
-                        req.padata.authenticator.subkey;
-        else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key;
-
-        send(resp);
-
-A.7.  KRB_TGS_REP verification
-        decode response into resp;
-
-        if (resp.msg-type = KRB_ERROR) then
-                process_error(resp);
-                return;
-        endif
-
-        /* On error, discard the response, and zero the session key from
-        the response immediately */
-
-        if (req.padata.authenticator.subkey)
-                unencrypted part of resp := decode of decrypt of resp.enc-part
-                        using resp.enc-part.etype and subkey;
-        else unencrypted part of resp := decode of decrypt of resp.enc-part
-                                using resp.enc-part.etype and tgt's session key;
-        if (common_as_rep_tgs_rep_checks fail) then
-                destroy resp.key;
-                return error;
-        endif
-
-        check authorization_data as necessary;
-        save_for_later(ticket,session,client,server,times,flags);
-
-
-
-Section A.7.              - 111 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-A.8.  Authenticator generation
-        body.authenticator-vno := authenticator vno; /* = 5 */
-        body.cname, body.crealm := client name;
-        if (supplying checksum) then
-                body.cksum := checksum;
-        endif
-        get system_time;
-        body.ctime, body.cusec := system_time;
-        if (selecting sub-session key) then
-                select sub-session key;
-                body.subkey := sub-session key;
-        endif
-        if (using sequence numbers) then
-                select initial sequence number;
-                body.seq-number := initial sequence;
-        endif
-
-A.9.  KRB_AP_REQ generation
-        obtain ticket and session_key from cache;
-
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_AP_REQ */
-
-        if (desired(MUTUAL_AUTHENTICATION)) then
-                set packet.ap-options.MUTUAL-REQUIRED;
-        else
-                reset packet.ap-options.MUTUAL-REQUIRED;
-        endif
-        if (using session key for ticket) then
-                set packet.ap-options.USE-SESSION-KEY;
-        else
-                reset packet.ap-options.USE-SESSION-KEY;
-        endif
-        packet.ticket := ticket; /* ticket */
-        generate authenticator;
-        encode authenticator into OCTET STRING;
-        encrypt OCTET STRING into packet.authenticator using session_key;
-
-A.10.  KRB_AP_REQ verification
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_AP_REQ) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        if (packet.ticket.tkt_vno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.ap_options.USE-SESSION-KEY is set) then
-                retrieve session key from ticket-granting ticket for
-                 packet.ticket.{sname,srealm,enc-part.etype};
-
-
-Section A.10.             - 112 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-        else
-                retrieve service key for
-                 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
-        endif
-        if (no_key_available) then
-                if (cannot_find_specified_skvno) then
-                        error_out(KRB_AP_ERR_BADKEYVER);
-                else
-                        error_out(KRB_AP_ERR_NOKEY);
-                endif
-        endif
-        decrypt packet.ticket.enc-part into decr_ticket using retrieved key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        decrypt packet.authenticator into decr_authenticator
-                using decr_ticket.key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        if (decr_authenticator.{cname,crealm} !=
-            decr_ticket.{cname,crealm}) then
-                error_out(KRB_AP_ERR_BADMATCH);
-        endif
-        if (decr_ticket.caddr is present) then
-                if (sender_address(packet) is not in decr_ticket.caddr) then
-                        error_out(KRB_AP_ERR_BADADDR);
-                endif
-        elseif (application requires addresses) then
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if (not in_clock_skew(decr_authenticator.ctime,
-                              decr_authenticator.cusec)) then
-                error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then
-                error_out(KRB_AP_ERR_REPEAT);
-        endif
-        save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
-        get system_time;
-        if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
-            (decr_ticket.flags.INVALID is set)) then
-                /* it hasn't yet become valid */
-                error_out(KRB_AP_ERR_TKT_NYV);
-        endif
-        if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
-                error_out(KRB_AP_ERR_TKT_EXPIRED);
-        endif
-        /* caller must check decr_ticket.flags for any pertinent details */
-        return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
-
-A.11.  KRB_AP_REP generation
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_AP_REP */
-
-
-Section A.11.             - 113 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-        body.ctime := packet.ctime;
-        body.cusec := packet.cusec;
-        if (selecting sub-session key) then
-                select sub-session key;
-                body.subkey := sub-session key;
-        endif
-        if (using sequence numbers) then
-                select initial sequence number;
-                body.seq-number := initial sequence;
-        endif
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part;
-
-A.12.  KRB_AP_REP verification
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_AP_REP) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        cleartext := decrypt(packet.enc-part) using ticket's session key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        if (cleartext.ctime != authenticator.ctime) then
-                error_out(KRB_AP_ERR_MUT_FAIL);
-        endif
-        if (cleartext.cusec != authenticator.cusec) then
-                error_out(KRB_AP_ERR_MUT_FAIL);
-        endif
-        if (cleartext.subkey is present) then
-                save cleartext.subkey for future use;
-        endif
-        if (cleartext.seq-number is present) then
-                save cleartext.seq-number for future verifications;
-        endif
-        return(AUTHENTICATION_SUCCEEDED);
-
-A.13.  KRB_SAFE generation
-        collect user data in buffer;
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_SAFE */
-
-        body.user-data := buffer; /* DATA */
-        if (using timestamp) then
-                get system_time;
-                body.timestamp, body.usec := system_time;
-
-
-Section A.13.             - 114 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-        endif
-        if (using sequence numbers) then
-                body.seq-number := sequence number;
-        endif
-        body.s-address := sender host addresses;
-        if (only one recipient) then
-                body.r-address := recipient host address;
-        endif
-        checksum.cksumtype := checksum type;
-        compute checksum over body;
-        checksum.checksum := checksum value; /* checksum.checksum */
-        packet.cksum := checksum;
-        packet.safe-body := body;
-
-A.14.  KRB_SAFE verification
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_SAFE) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        if (packet.checksum.cksumtype is not both collision-proof and keyed) then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-        if (safe_priv_common_checks_ok(packet)) then
-                set computed_checksum := checksum(packet.body);
-                if (computed_checksum != packet.checksum) then
-                        error_out(KRB_AP_ERR_MODIFIED);
-                endif
-                return (packet, PACKET_IS_GENUINE);
-        else
-                return common_checks_error;
-        endif
-
-A.15.  KRB_SAFE and KRB_PRIV common checks
-        if (packet.s-address != O/S_sender(packet)) then
-                /* O/S report of sender not who claims to have sent it */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if ((packet.r-address is present) and
-            (packet.r-address != local_host_address)) then
-                /* was not sent to proper place */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if (((packet.timestamp is present) and
-             (not in_clock_skew(packet.timestamp,packet.usec))) or
-            (packet.timestamp is not present and timestamp expected)) then
-                error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
-                error_out(KRB_AP_ERR_REPEAT);
-        endif
-
-
-Section A.15.             - 115 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-        if (((packet.seq-number is present) and
-             ((not in_sequence(packet.seq-number)))) or
-            (packet.seq-number is not present and sequence expected)) then
-                error_out(KRB_AP_ERR_BADORDER);
-        endif
-        if (packet.timestamp not present and packet.seq-number not present) then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        save_identifier(packet.{timestamp,usec,s-address},
-                        sender_principal(packet));
-
-        return PACKET_IS_OK;
-
-A.16.  KRB_PRIV generation
-        collect user data in buffer;
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_PRIV */
-
-        packet.enc-part.etype := encryption type;
-
-        body.user-data := buffer;
-        if (using timestamp) then
-                get system_time;
-                body.timestamp, body.usec := system_time;
-        endif
-        if (using sequence numbers) then
-                body.seq-number := sequence number;
-        endif
-        body.s-address := sender host addresses;
-        if (only one recipient) then
-                body.r-address := recipient host address;
-        endif
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part.cipher;
-
-
-A.17.  KRB_PRIV verification
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_PRIV) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-
-        cleartext := decrypt(packet.enc-part) using negotiated key;
-        if (decryption_error()) then
-
-
-Section A.17.             - 116 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-
-        if (safe_priv_common_checks_ok(cleartext)) then
-                return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
-        else
-                return common_checks_error;
-        endif
-
-A.18.  KRB_CRED generation
-        invoke KRB_TGS; /* obtain tickets to be provided to peer */
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_CRED */
-
-        for (tickets[n] in tickets to be forwarded) do
-                packet.tickets[n] = tickets[n].ticket;
-        done
-
-        packet.enc-part.etype := encryption type;
-
-        for (ticket[n] in tickets to be forwarded) do
-                body.ticket-info[n].key = tickets[n].session;
-                body.ticket-info[n].prealm = tickets[n].crealm;
-                body.ticket-info[n].pname = tickets[n].cname;
-                body.ticket-info[n].flags = tickets[n].flags;
-                body.ticket-info[n].authtime = tickets[n].authtime;
-                body.ticket-info[n].starttime = tickets[n].starttime;
-                body.ticket-info[n].endtime = tickets[n].endtime;
-                body.ticket-info[n].renew-till = tickets[n].renew-till;
-                body.ticket-info[n].srealm = tickets[n].srealm;
-                body.ticket-info[n].sname = tickets[n].sname;
-                body.ticket-info[n].caddr = tickets[n].caddr;
-        done
-
-        get system_time;
-        body.timestamp, body.usec := system_time;
-
-        if (using nonce) then
-                body.nonce := nonce;
-        endif
-
-        if (using s-address) then
-                body.s-address := sender host addresses;
-        endif
-        if (limited recipients) then
-                body.r-address := recipient host address;
-        endif
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part.cipher
-
-
-Section A.18.             - 117 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-               using negotiated encryption key;
-
-
-A.19.  KRB_CRED verification
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_CRED) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-
-        cleartext := decrypt(packet.enc-part) using negotiated key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        if ((packet.r-address is present or required) and
-           (packet.s-address != O/S_sender(packet)) then
-                /* O/S report of sender not who claims to have sent it */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if ((packet.r-address is present) and
-            (packet.r-address != local_host_address)) then
-                /* was not sent to proper place */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if (not in_clock_skew(packet.timestamp,packet.usec)) then
-                error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
-                error_out(KRB_AP_ERR_REPEAT);
-        endif
-        if (packet.nonce is required or present) and
-           (packet.nonce != expected-nonce) then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        for (ticket[n] in tickets that were forwarded) do
-                save_for_later(ticket[n],key[n],principal[n],
-                               server[n],times[n],flags[n]);
-        return
-
-A.20.  KRB_ERROR generation
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_ERROR */
-
-        get system_time;
-        packet.stime, packet.susec := system_time;
-        packet.realm, packet.sname := server name;
-
-        if (client time available) then
-
-
-Section A.20.             - 118 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-                packet.ctime, packet.cusec := client_time;
-        endif
-        packet.error-code := error code;
-        if (client name available) then
-                packet.cname, packet.crealm := client name;
-        endif
-        if (error text available) then
-                packet.e-text := error text;
-        endif
-        if (error data available) then
-                packet.e-data := error data;
-        endif
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-                          - 119 -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-                          - cxx -    Expires 11 January 1998
-
-
-
-
-
-
-
-
-
-
-                     Table of Contents
-
-
-
-
-Overview ..............................................    2
-
-Background ............................................    2
-
-1. Introduction .......................................    3
-
-1.1. Cross-Realm Operation ............................    5
-
-1.2. Authorization ....................................    6
-
-1.3. Environmental assumptions ........................    7
-
-1.4. Glossary of terms ................................    8
-
-2. Ticket flag uses and requests ......................   10
-
-2.1. Initial and pre-authenticated tickets ............   10
-
-2.2. Invalid tickets ..................................   11
-
-2.3. Renewable tickets ................................   11
-
-2.4. Postdated tickets ................................   12
-
-2.5. Proxiable and proxy tickets ......................   12
-
-2.6. Forwardable tickets ..............................   13
-
-2.7. Other KDC options ................................   14
-
-3. Message Exchanges ..................................   14
-
-3.1. The Authentication Service Exchange ..............   14
-
-3.1.1. Generation of KRB_AS_REQ message ...............   16
-
-3.1.2. Receipt of KRB_AS_REQ message ..................   16
-
-3.1.3. Generation of KRB_AS_REP message ...............   16
-
-3.1.4. Generation of KRB_ERROR message ................   19
-
-3.1.5. Receipt of KRB_AS_REP message ..................   19
-
-3.1.6. Receipt of KRB_ERROR message ...................   19
-
-3.2. The Client/Server Authentication Exchange ........   19
-
-3.2.1. The KRB_AP_REQ message .........................   20
-
-
-                           - i -     Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-3.2.2. Generation of a KRB_AP_REQ message .............   20
-
-3.2.3. Receipt of KRB_AP_REQ message ..................   21
-
-3.2.4. Generation of a KRB_AP_REP message .............   23
-
-3.2.5. Receipt of KRB_AP_REP message ..................   23
-
-3.2.6. Using the encryption key .......................   24
-
-3.3. The Ticket-Granting Service (TGS) Exchange .......   25
-
-3.3.1. Generation of KRB_TGS_REQ message ..............   26
-
-3.3.2. Receipt of KRB_TGS_REQ message .................   27
-
-3.3.3. Generation of KRB_TGS_REP message ..............   28
-
-3.3.3.1. Checking for revoked tickets .................   30
-
-3.3.3.2. Encoding the transited field .................   30
-
-3.3.4. Receipt of KRB_TGS_REP message .................   32
-
-3.4. The KRB_SAFE Exchange ............................   32
-
-3.4.1. Generation of a KRB_SAFE message ...............   32
-
-3.4.2. Receipt of KRB_SAFE message ....................   33
-
-3.5. The KRB_PRIV Exchange ............................   34
-
-3.5.1. Generation of a KRB_PRIV message ...............   34
-
-3.5.2. Receipt of KRB_PRIV message ....................   34
-
-3.6. The KRB_CRED Exchange ............................   35
-
-3.6.1. Generation of a KRB_CRED message ...............   35
-
-3.6.2. Receipt of KRB_CRED message ....................   35
-
-4. The Kerberos Database ..............................   36
-
-4.1. Database contents ................................   36
-
-4.2. Additional fields ................................   37
-
-4.3. Frequently Changing Fields .......................   38
-
-4.4. Site Constants ...................................   39
-
-5. Message Specifications .............................   39
-
-
-
-                           - ii -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-5.1. ASN.1 Distinguished Encoding Representation ......   39
-
-5.2. ASN.1 Base Definitions ...........................   40
-
-5.3. Tickets and Authenticators .......................   43
-
-5.3.1. Tickets ........................................   43
-
-5.3.2. Authenticators .................................   52
-
-5.4. Specifications for the AS and TGS exchanges ......   54
-
-5.4.1. KRB_KDC_REQ definition .........................   54
-
-5.4.2. KRB_KDC_REP definition .........................   61
-
-5.5. Client/Server (CS) message specifications ........   64
-
-5.5.1. KRB_AP_REQ definition ..........................   64
-
-5.5.2. KRB_AP_REP definition ..........................   65
-
-5.5.3. Error message reply ............................   67
-
-5.6. KRB_SAFE message specification ...................   67
-
-5.6.1. KRB_SAFE definition ............................   67
-
-5.7. KRB_PRIV message specification ...................   68
-
-5.7.1. KRB_PRIV definition ............................   68
-
-5.8. KRB_CRED message specification ...................   69
-
-5.8.1. KRB_CRED definition ............................   70
-
-5.9. Error message specification ......................   72
-
-5.9.1. KRB_ERROR definition ...........................   72
-
-6. Encryption and Checksum Specifications .............   74
-
-6.1. Encryption Specifications ........................   76
-
-6.2. Encryption Keys ..................................   78
-
-6.3. Encryption Systems ...............................   78
-
-6.3.1. The NULL Encryption System (null) ..............   78
-
-6.3.2. DES in CBC mode with a CRC-32 checksum (des-
-cbc-crc) ..............................................   79
-
-6.3.3. DES in CBC mode with an MD4 checksum (des-
-
-
-                          - iii -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-cbc-md4) ..............................................   79
-
-6.3.4. DES in CBC mode with an MD5 checksum (des-
-cbc-md5) ..............................................   79
-
-6.3.5. Triple DES EDE in outer CBC mode with an SHA1
-checksum (des3-cbc-sha1) ..............................   81
-
-6.4. Checksums ........................................   83
-
-6.4.1. The CRC-32 Checksum (crc32) ....................   84
-
-6.4.2. The RSA MD4 Checksum (rsa-md4) .................   84
-
-6.4.3. RSA MD4 Cryptographic Checksum Using DES
-(rsa-md4-des) .........................................   84
-
-6.4.4. The RSA MD5 Checksum (rsa-md5) .................   85
-
-6.4.5. RSA MD5 Cryptographic Checksum Using DES
-(rsa-md5-des) .........................................   85
-
-6.4.6. DES cipher-block chained checksum (des-mac)
-
-6.4.7. RSA MD4 Cryptographic Checksum Using DES
-alternative (rsa-md4-des-k) ...........................   86
-
-6.4.8. DES cipher-block chained checksum alternative
-(des-mac-k) ...........................................   87
-
-7. Naming Constraints .................................   87
-
-7.1. Realm Names ......................................   87
-
-7.2. Principal Names ..................................   88
-
-7.2.1. Name of server principals ......................   89
-
-8. Constants and other defined values .................   90
-
-8.1. Host address types ...............................   90
-
-8.2. KDC messages .....................................   91
-
-8.2.1. IP transport ...................................   91
-
-8.2.2. OSI transport ..................................   91
-
-8.2.3. Name of the TGS ................................   92
-
-8.3. Protocol constants and associated values .........   92
-
-9. Interoperability requirements ......................   95
-
-
-
-                           - iv -    Expires 11 January 1998
-
-
-
-
-
-
-
-            Version 5 - Specification Revision 6
-
-
-9.1. Specification 1 ..................................   95
-
-9.2. Recommended KDC values ...........................   97
-
-10. REFERENCES ........................................   98
-
-A. Pseudo-code for protocol processing ................  100
-
-A.1. KRB_AS_REQ generation ............................  100
-
-A.2. KRB_AS_REQ verification and KRB_AS_REP genera-
-tion ..................................................  100
-
-A.3. KRB_AS_REP verification ..........................  104
-
-A.4. KRB_AS_REP and KRB_TGS_REP common checks .........  104
-
-A.5. KRB_TGS_REQ generation ...........................  105
-
-A.6. KRB_TGS_REQ verification and KRB_TGS_REP gen-
-eration ...............................................  106
-
-A.7. KRB_TGS_REP verification .........................  111
-
-A.8. Authenticator generation .........................  112
-
-A.9. KRB_AP_REQ generation ............................  112
-
-A.10. KRB_AP_REQ verification .........................  112
-
-A.11. KRB_AP_REP generation ...........................  113
-
-A.12. KRB_AP_REP verification .........................  114
-
-A.13. KRB_SAFE generation .............................  114
-
-A.14. KRB_SAFE verification ...........................  115
-
-A.15. KRB_SAFE and KRB_PRIV common checks .............  115
-
-A.16. KRB_PRIV generation .............................  116
-
-A.17. KRB_PRIV verification ...........................  116
-
-A.18. KRB_CRED generation .............................  117
-
-A.19. KRB_CRED verification ...........................  118
-
-A.20. KRB_ERROR generation ............................  118
-
-
-
-
-
-
-
-                           - v -     Expires 11 January 1998
-
-
-
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-revisions-01.txt b/doc/standardisation/draft-ietf-cat-kerberos-revisions-01.txt
deleted file mode 100644
index 78db9d78f..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-revisions-01.txt
+++ /dev/null
@@ -1,6214 +0,0 @@
-
-INTERNET-DRAFT                                          Clifford Neuman
-                                                              John Kohl
-                                                          Theodore Ts'o
-                                                       21 November 1997
-
-The Kerberos Network Authentication Service (V5)
-
-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 learn the current status of any Internet-Draft, please check the
-'1id-abstracts.txt' listing contained in the Internet-Drafts Shadow
-Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
-ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
-
-The distribution of this memo is unlimited. It is filed as
-draft-ietf-cat-kerberos-r-01.txt, and expires 21 May 1998. Please send
-comments to: krb-protocol@MIT.EDU
-
-ABSTRACT
-
-This document provides an overview and specification of Version 5 of the
-Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol
-and its intended use that require more detailed or clearer explanation than
-was provided in RFC1510. This document is intended to provide a detailed
-description of the protocol, suitable for implementation, together with
-descriptions of the appropriate use of protocol messages and fields within
-those messages.
-
-This document is not intended to describe Kerberos to the end user, system
-administrator, or application developer. Higher level papers describing
-Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88],
-are available elsewhere.
-
-OVERVIEW
-
-This INTERNET-DRAFT describes the concepts and model upon which the Kerberos
-network authentication system is based. It also specifies Version 5 of the
-Kerberos protocol.
-
-The motivations, goals, assumptions, and rationale behind most design
-decisions are treated cursorily; they are more fully described in a paper
-available in IEEE communications [NT94] and earlier in the Kerberos portion
-of the Athena Technical Plan [MNSS87]. The protocols have been a proposed
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-standard and are being considered for advancement for draft standard through
-the IETF standard process. Comments are encouraged on the presentation, but
-only minor refinements to the protocol as implemented or extensions that fit
-within current protocol framework will be considered at this time.
-
-Requests for addition to an electronic mailing list for discussion of
-Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU.
-This mailing list is gatewayed onto the Usenet as the group
-comp.protocols.kerberos. Requests for further information, including
-documents and code availability, may be sent to info-kerberos@MIT.EDU.
-
-BACKGROUND
-
-The Kerberos model is based in part on Needham and Schroeder's trusted
-third-party authentication protocol [NS78] and on modifications suggested by
-Denning and Sacco [DS81]. The original design and implementation of Kerberos
-Versions 1 through 4 was the work of two former Project Athena staff
-members, Steve Miller of Digital Equipment Corporation and Clifford Neuman
-(now at the Information Sciences Institute of the University of Southern
-California), along with Jerome Saltzer, Technical Director of Project
-Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members
-of Project Athena have also contributed to the work on Kerberos.
-
-Version 5 of the Kerberos protocol (described in this document) has evolved
-from Version 4 based on new requirements and desires for features not
-available in Version 4. The design of Version 5 of the Kerberos protocol was
-led by Clifford Neuman and John Kohl with much input from the community. The
-development of the MIT reference implementation was led at MIT by John Kohl
-and Theodore T'so, with help and contributed code from many others.
-Reference implementations of both version 4 and version 5 of Kerberos are
-publicly available and commercial implementations have been developed and
-are widely used.
-
-Details on the differences between Kerberos Versions 4 and 5 can be found in
-[KNT92].
-
-1. Introduction
-
-Kerberos provides a means of verifying the identities of principals, (e.g. a
-workstation user or a network server) on an open (unprotected) network. This
-is accomplished without relying on assertions by the host operating system,
-without basing trust on host addresses, without requiring physical security
-of all the hosts on the network, and under the assumption that packets
-traveling along the network can be read, modified, and inserted at will[1].
-Kerberos performs authentication under these conditions as a trusted
-third-party authentication service by using conventional (shared secret key
-[2] cryptography. Kerberos extensions have been proposed and implemented
-that provide for the use of public key cryptography during certain phases of
-the authentication protocol. These extensions provide for authentication of
-users registered with public key certification authorities, and allow the
-system to provide certain benefits of public key cryptography in situations
-where they are needed.
-
-The basic Kerberos authentication process proceeds as follows: A client
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-sends a request to the authentication server (AS) requesting 'credentials'
-for a given server. The AS responds with these credentials, encrypted in the
-client's key. The credentials consist of 1) a 'ticket' for the server and 2)
-a temporary encryption key (often called a "session key"). The client
-transmits the ticket (which contains the client's identity and a copy of the
-session key, all encrypted in the server's key) to the server. The session
-key (now shared by the client and server) is used to authenticate the
-client, and may optionally be used to authenticate the server. It may also
-be used to encrypt further communication between the two parties or to
-exchange a separate sub-session key to be used to encrypt further
-communication.
-
-Implementation of the basic protocol consists of one or more authentication
-servers running on physically secure hosts. The authentication servers
-maintain a database of principals (i.e., users and servers) and their secret
-keys. Code libraries provide encryption and implement the Kerberos protocol.
-In order to add authentication to its transactions, a typical network
-application adds one or two calls to the Kerberos library directly or
-through the Generic Security Services Application Programming Interface,
-GSSAPI, described in separate document. These calls result in the
-transmission of the necessary messages to achieve authentication.
-
-The Kerberos protocol consists of several sub-protocols (or exchanges).
-There are two basic methods by which a client can ask a Kerberos server for
-credentials. In the first approach, the client sends a cleartext request for
-a ticket for the desired server to the AS. The reply is sent encrypted in
-the client's secret key. Usually this request is for a ticket-granting
-ticket (TGT) which can later be used with the ticket-granting server (TGS).
-In the second method, the client sends a request to the TGS. The client uses
-the TGT to authenticate itself to the TGS in the same manner as if it were
-contacting any other application server that requires Kerberos
-authentication. The reply is encrypted in the session key from the TGT.
-Though the protocol specification describes the AS and the TGS as separate
-servers, they are implemented in practice as different protocol entry points
-within a single Kerberos server.
-
-Once obtained, credentials may be used to verify the identity of the
-principals in a transaction, to ensure the integrity of messages exchanged
-between them, or to preserve privacy of the messages. The application is
-free to choose whatever protection may be necessary.
-
-To verify the identities of the principals in a transaction, the client
-transmits the ticket to the application server. Since the ticket is sent "in
-the clear" (parts of it are encrypted, but this encryption doesn't thwart
-replay) and might be intercepted and reused by an attacker, additional
-information is sent to prove that the message originated with the principal
-to whom the ticket was issued. This information (called the authenticator)
-is encrypted in the session key, and includes a timestamp. The timestamp
-proves that the message was recently generated and is not a replay.
-Encrypting the authenticator in the session key proves that it was generated
-by a party possessing the session key. Since no one except the requesting
-principal and the server know the session key (it is never sent over the
-network in the clear) this guarantees the identity of the client.
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-The integrity of the messages exchanged between principals can also be
-guaranteed using the session key (passed in the ticket and contained in the
-credentials). This approach provides detection of both replay attacks and
-message stream modification attacks. It is accomplished by generating and
-transmitting a collision-proof checksum (elsewhere called a hash or digest
-function) of the client's message, keyed with the session key. Privacy and
-integrity of the messages exchanged between principals can be secured by
-encrypting the data to be passed using the session key contained in the
-ticket or the subsession key found in the authenticator.
-
-The authentication exchanges mentioned above require read-only access to the
-Kerberos database. Sometimes, however, the entries in the database must be
-modified, such as when adding new principals or changing a principal's key.
-This is done using a protocol between a client and a third Kerberos server,
-the Kerberos Administration Server (KADM). There is also a protocol for
-maintaining multiple copies of the Kerberos database. Neither of these
-protocols are described in this document.
-
-1.1. Cross-Realm Operation
-
-The Kerberos protocol is designed to operate across organizational
-boundaries. A client in one organization can be authenticated to a server in
-another. Each organization wishing to run a Kerberos server establishes its
-own 'realm'. The name of the realm in which a client is registered is part
-of the client's name, and can be used by the end-service to decide whether
-to honor a request.
-
-By establishing 'inter-realm' keys, the administrators of two realms can
-allow a client authenticated in the local realm to prove its identity to
-servers in other realms[3]. The exchange of inter-realm keys (a separate key
-may be used for each direction) registers the ticket-granting service of
-each realm as a principal in the other realm. A client is then able to
-obtain a ticket-granting ticket for the remote realm's ticket-granting
-service from its local realm. When that ticket-granting ticket is used, the
-remote ticket-granting service uses the inter-realm key (which usually
-differs from its own normal TGS key) to decrypt the ticket-granting ticket,
-and is thus certain that it was issued by the client's own TGS. Tickets
-issued by the remote ticket-granting service will indicate to the
-end-service that the client was authenticated from another realm.
-
-A realm is said to communicate with another realm if the two realms share an
-inter-realm key, or if the local realm shares an inter-realm key with an
-intermediate realm that communicates with the remote realm. An
-authentication path is the sequence of intermediate realms that are
-transited in communicating from one realm to another.
-
-Realms are typically organized hierarchically. Each realm shares a key with
-its parent and a different key with each child. If an inter-realm key is not
-directly shared by two realms, the hierarchical organization allows an
-authentication path to be easily constructed. If a hierarchical organization
-is not used, it may be necessary to consult a database in order to construct
-an authentication path between realms.
-
-Although realms are typically hierarchical, intermediate realms may be
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-bypassed to achieve cross-realm authentication through alternate
-authentication paths (these might be established to make communication
-between two realms more efficient). It is important for the end-service to
-know which realms were transited when deciding how much faith to place in
-the authentication process. To facilitate this decision, a field in each
-ticket contains the names of the realms that were involved in authenticating
-the client.
-
-The application server is ultimately responsible for accepting or rejecting
-authentication and should check the transited field. The application server
-may choose to rely on the KDC for the application server's realm to check
-the transited field. The application server's KDC will set the
-TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate
-realms may also check the transited field as they issue
-ticket-granting-tickets for other realms, but they are encouraged not to do
-so. A client may request that the KDC's not check the transited field by
-setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not
-required to honor this flag.
-
-1.2. Authorization
-
-As an authentication service, Kerberos provides a means of verifying the
-identity of principals on a network. Authentication is usually useful
-primarily as a first step in the process of authorization, determining
-whether a client may use a service, which objects the client is allowed to
-access, and the type of access allowed for each. Kerberos does not, by
-itself, provide authorization. Possession of a client ticket for a service
-provides only for authentication of the client to that service, and in the
-absence of a separate authorization procedure, it should not be considered
-by an application as authorizing the use of that service.
-
-Such separate authorization methods may be implemented as application
-specific access control functions and may be based on files such as the
-application server, or on separately issued authorization credentials such
-as those based on proxies [Neu93] , or on other authorization services.
-
-Applications should not be modified to accept the issuance of a service
-ticket by the Kerberos server (even by an modified Kerberos server) as
-granting authority to use the service, since such applications may become
-vulnerable to the bypass of this authorization check in an environment if
-they interoperate with other KDCs or where other options for application
-authentication (e.g. the PKTAPP proposal) are provided.
-
-1.3. Environmental assumptions
-
-Kerberos imposes a few assumptions on the environment in which it can
-properly function:
-
-   * 'Denial of service' attacks are not solved with Kerberos. There are
-     places in these protocols where an intruder can prevent an application
-     from participating in the proper authentication steps. Detection and
-     solution of such attacks (some of which can appear to be nnot-uncommon
-     'normal' failure modes for the system) is usually best left to the
-     human administrators and users.
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-   * Principals must keep their secret keys secret. If an intruder somehow
-     steals a principal's key, it will be able to masquerade as that
-     principal or impersonate any server to the legitimate principal.
-   * 'Password guessing' attacks are not solved by Kerberos. If a user
-     chooses a poor password, it is possible for an attacker to successfully
-     mount an offline dictionary attack by repeatedly attempting to decrypt,
-     with successive entries from a dictionary, messages obtained which are
-     encrypted under a key derived from the user's password.
-   * Each host on the network must have a clock which is 'loosely
-     synchronized' to the time of the other hosts; this synchronization is
-     used to reduce the bookkeeping needs of application servers when they
-     do replay detection. The degree of "looseness" can be configured on a
-     per-server basis, but is typically on the order of 5 minutes. If the
-     clocks are synchronized over the network, the clock synchronization
-     protocol must itself be secured from network attackers.
-   * Principal identifiers are not recycled on a short-term basis. A typical
-     mode of access control will use access control lists (ACLs) to grant
-     permissions to particular principals. If a stale ACL entry remains for
-     a deleted principal and the principal identifier is reused, the new
-     principal will inherit rights specified in the stale ACL entry. By not
-     re-using principal identifiers, the danger of inadvertent access is
-     removed.
-
-1.4. Glossary of terms
-
-Below is a list of terms used throughout this document.
-
-Authentication
-     Verifying the claimed identity of a principal.
-Authentication header
-     A record containing a Ticket and an Authenticator to be presented to a
-     server as part of the authentication process.
-Authentication path
-     A sequence of intermediate realms transited in the authentication
-     process when communicating from one realm to another.
-Authenticator
-     A record containing information that can be shown to have been recently
-     generated using the session key known only by the client and server.
-Authorization
-     The process of determining whether a client may use a service, which
-     objects the client is allowed to access, and the type of access allowed
-     for each.
-Capability
-     A token that grants the bearer permission to access an object or
-     service. In Kerberos, this might be a ticket whose use is restricted by
-     the contents of the authorization data field, but which lists no
-     network addresses, together with the session key necessary to use the
-     ticket.
-Ciphertext
-     The output of an encryption function. Encryption transforms plaintext
-     into ciphertext.
-Client
-     A process that makes use of a network service on behalf of a user. Note
-     that in some cases a Server may itself be a client of some other server
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-     (e.g. a print server may be a client of a file server).
-Credentials
-     A ticket plus the secret session key necessary to successfully use that
-     ticket in an authentication exchange.
-KDC
-     Key Distribution Center, a network service that supplies tickets and
-     temporary session keys; or an instance of that service or the host on
-     which it runs. The KDC services both initial ticket and ticket-granting
-     ticket requests. The initial ticket portion is sometimes referred to as
-     the Authentication Server (or service). The ticket-granting ticket
-     portion is sometimes referred to as the ticket-granting server (or
-     service).
-Kerberos
-     Aside from the 3-headed dog guarding Hades, the name given to Project
-     Athena's authentication service, the protocol used by that service, or
-     the code used to implement the authentication service.
-Plaintext
-     The input to an encryption function or the output of a decryption
-     function. Decryption transforms ciphertext into plaintext.
-Principal
-     A uniquely named client or server instance that participates in a
-     network communication.
-Principal identifier
-     The name used to uniquely identify each different principal.
-Seal
-     To encipher a record containing several fields in such a way that the
-     fields cannot be individually replaced without either knowledge of the
-     encryption key or leaving evidence of tampering.
-Secret key
-     An encryption key shared by a principal and the KDC, distributed
-     outside the bounds of the system, with a long lifetime. In the case of
-     a human user's principal, the secret key is derived from a password.
-Server
-     A particular Principal which provides a resource to network clients.
-     The server is sometimes refered to as the Application Server.
-Service
-     A resource provided to network clients; often provided by more than one
-     server (for example, remote file service).
-Session key
-     A temporary encryption key used between two principals, with a lifetime
-     limited to the duration of a single login "session".
-Sub-session key
-     A temporary encryption key used between two principals, selected and
-     exchanged by the principals using the session key, and with a lifetime
-     limited to the duration of a single association.
-Ticket
-     A record that helps a client authenticate itself to a server; it
-     contains the client's identity, a session key, a timestamp, and other
-     information, all sealed using the server's secret key. It only serves
-     to authenticate a client when presented along with a fresh
-     Authenticator.
-
-2. Ticket flag uses and requests
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-Each Kerberos ticket contains a set of flags which are used to indicate
-various attributes of that ticket. Most flags may be requested by a client
-when the ticket is obtained; some are automatically turned on and off by a
-Kerberos server as required. The following sections explain what the various
-flags mean, and gives examples of reasons to use such a flag.
-
-2.1. Initial and pre-authenticated tickets
-
-The INITIAL flag indicates that a ticket was issued using the AS protocol
-and not issued based on a ticket-granting ticket. Application servers that
-want to require the demonstrated knowledge of a client's secret key (e.g. a
-password-changing program) can insist that this flag be set in any tickets
-they accept, and thus be assured that the client's key was recently
-presented to the application client.
-
-The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the
-initial authentication, regardless of whether the current ticket was issued
-directly (in which case INITIAL will also be set) or issued on the basis of
-a ticket-granting ticket (in which case the INITIAL flag is clear, but the
-PRE-AUTHENT and HW-AUTHENT flags are carried forward from the
-ticket-granting ticket).
-
-2.2. Invalid tickets
-
-The INVALID flag indicates that a ticket is invalid. Application servers
-must reject tickets which have this flag set. A postdated ticket will
-usually be issued in this form. Invalid tickets must be validated by the KDC
-before use, by presenting them to the KDC in a TGS request with the VALIDATE
-option specified. The KDC will only validate tickets after their starttime
-has passed. The validation is required so that postdated tickets which have
-been stolen before their starttime can be rendered permanently invalid
-(through a hot-list mechanism) (see section 3.3.3.1).
-
-2.3. Renewable tickets
-
-Applications may desire to hold tickets which can be valid for long periods
-of time. However, this can expose their credentials to potential theft for
-equally long periods, and those stolen credentials would be valid until the
-expiration time of the ticket(s). Simply using short-lived tickets and
-obtaining new ones periodically would require the client to have long-term
-access to its secret key, an even greater risk. Renewable tickets can be
-used to mitigate the consequences of theft. Renewable tickets have two
-"expiration times": the first is when the current instance of the ticket
-expires, and the second is the latest permissible value for an individual
-expiration time. An application client must periodically (i.e. before it
-expires) present a renewable ticket to the KDC, with the RENEW option set in
-the KDC request. The KDC will issue a new ticket with a new session key and
-a later expiration time. All other fields of the ticket are left unmodified
-by the renewal process. When the latest permissible expiration time arrives,
-the ticket expires permanently. At each renewal, the KDC may consult a
-hot-list to determine if the ticket had been reported stolen since its last
-renewal; it will refuse to renew such stolen tickets, and thus the usable
-lifetime of stolen tickets is reduced.
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-The RENEWABLE flag in a ticket is normally only interpreted by the
-ticket-granting service (discussed below in section 3.3). It can usually be
-ignored by application servers. However, some particularly careful
-application servers may wish to disallow renewable tickets.
-
-If a renewable ticket is not renewed by its expiration time, the KDC will
-not renew the ticket. The RENEWABLE flag is reset by default, but a client
-may request it be set by setting the RENEWABLE option in the KRB_AS_REQ
-message. If it is set, then the renew-till field in the ticket contains the
-time after which the ticket may not be renewed.
-
-2.4. Postdated tickets
-
-Applications may occasionally need to obtain tickets for use much later,
-e.g. a batch submission system would need tickets to be valid at the time
-the batch job is serviced. However, it is dangerous to hold valid tickets in
-a batch queue, since they will be on-line longer and more prone to theft.
-Postdated tickets provide a way to obtain these tickets from the KDC at job
-submission time, but to leave them "dormant" until they are activated and
-validated by a further request of the KDC. If a ticket theft were reported
-in the interim, the KDC would refuse to validate the ticket, and the thief
-would be foiled.
-
-The MAY-POSTDATE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. This flag
-must be set in a ticket-granting ticket in order to issue a postdated ticket
-based on the presented ticket. It is reset by default; it may be requested
-by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message.
-This flag does not allow a client to obtain a postdated ticket-granting
-ticket; postdated ticket-granting tickets can only by obtained by requesting
-the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a
-postdated ticket will be the remaining life of the ticket-granting ticket at
-the time of the request, unless the RENEWABLE option is also set, in which
-case it can be the full life (endtime-starttime) of the ticket-granting
-ticket. The KDC may limit how far in the future a ticket may be postdated.
-
-The POSTDATED flag indicates that a ticket has been postdated. The
-application server can check the authtime field in the ticket to see when
-the original authentication occurred. Some services may choose to reject
-postdated tickets, or they may only accept them within a certain period
-after the original authentication. When the KDC issues a POSTDATED ticket,
-it will also be marked as INVALID, so that the application client must
-present the ticket to the KDC to be validated before use.
-
-2.5. Proxiable and proxy tickets
-
-At times it may be necessary for a principal to allow a service to perform
-an operation on its behalf. The service must be able to take on the identity
-of the client, but only for a particular purpose. A principal can allow a
-service to take on the principal's identity for a particular purpose by
-granting it a proxy.
-
-The process of granting a proxy using the proxy and proxiable flags is used
-to provide credentials for use with specific services. Though conceptually
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-also a proxy, user's wishing to delegate their identity for ANY purpose must
-use the ticket forwarding mechanism described in the next section to forward
-a ticket granting ticket.
-
-The PROXIABLE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. When set,
-this flag tells the ticket-granting server that it is OK to issue a new
-ticket (but not a ticket-granting ticket) with a different network address
-based on this ticket. This flag is set if requested by the client on initial
-authentication. By default, the client will request that it be set when
-requesting a ticket granting ticket, and reset when requesting any other
-ticket.
-
-This flag allows a client to pass a proxy to a server to perform a remote
-request on its behalf, e.g. a print service client can give the print server
-a proxy to access the client's files on a particular file server in order to
-satisfy a print request.
-
-In order to complicate the use of stolen credentials, Kerberos tickets are
-usually valid from only those network addresses specifically included in the
-ticket[4]. When granting a proxy, the client must specify the new network
-address from which the proxy is to be used, or indicate that the proxy is to
-be issued for use from any address.
-
-The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket.
-Application servers may check this flag and at their option they may require
-additional authentication from the agent presenting the proxy in order to
-provide an audit trail.
-
-2.6. Forwardable tickets
-
-Authentication forwarding is an instance of a proxy where the service is
-granted complete use of the client's identity. An example where it might be
-used is when a user logs in to a remote system and wants authentication to
-work from that system as if the login were local.
-
-The FORWARDABLE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. The
-FORWARDABLE flag has an interpretation similar to that of the PROXIABLE
-flag, except ticket-granting tickets may also be issued with different
-network addresses. This flag is reset by default, but users may request that
-it be set by setting the FORWARDABLE option in the AS request when they
-request their initial ticket- granting ticket.
-
-This flag allows for authentication forwarding without requiring the user to
-enter a password again. If the flag is not set, then authentication
-forwarding is not permitted, but the same result can still be achieved if
-the user engages in the AS exchange specifying the requested network
-addresses and supplies a password.
-
-The FORWARDED flag is set by the TGS when a client presents a ticket with
-the FORWARDABLE flag set and requests a forwarded ticket by specifying the
-FORWARDED KDC option and supplying a set of addresses for the new ticket. It
-is also set in all tickets issued based on tickets with the FORWARDED flag
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-set. Application servers may choose to process FORWARDED tickets differently
-than non-FORWARDED tickets.
-
-2.7. Other KDC options
-
-There are two additional options which may be set in a client's request of
-the KDC. The RENEWABLE-OK option indicates that the client will accept a
-renewable ticket if a ticket with the requested life cannot otherwise be
-provided. If a ticket with the requested life cannot be provided, then the
-KDC may issue a renewable ticket with a renew-till equal to the the
-requested endtime. The value of the renew-till field may still be adjusted
-by site-determined limits or limits imposed by the individual principal or
-server.
-
-The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service.
-It indicates that the ticket to be issued for the end server is to be
-encrypted in the session key from the a additional second ticket-granting
-ticket provided with the request. See section 3.3.3 for specific details.
-
-3. Message Exchanges
-
-The following sections describe the interactions between network clients and
-servers and the messages involved in those exchanges.
-
-3.1. The Authentication Service Exchange
-
-                          Summary
-      Message direction       Message type    Section
-      1. Client to Kerberos   KRB_AS_REQ      5.4.1
-      2. Kerberos to client   KRB_AS_REP or   5.4.2
-                              KRB_ERROR       5.9.1
-
-The Authentication Service (AS) Exchange between the client and the Kerberos
-Authentication Server is initiated by a client when it wishes to obtain
-authentication credentials for a given server but currently holds no
-credentials. In its basic form, the client's secret key is used for
-encryption and decryption. This exchange is typically used at the initiation
-of a login session to obtain credentials for a Ticket-Granting Server which
-will subsequently be used to obtain credentials for other servers (see
-section 3.3) without requiring further use of the client's secret key. This
-exchange is also used to request credentials for services which must not be
-mediated through the Ticket-Granting Service, but rather require a
-principal's secret key, such as the password-changing service[5]. This
-exchange does not by itself provide any assurance of the the identity of the
-user[6].
-
-The exchange consists of two messages: KRB_AS_REQ from the client to
-Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
-messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
-
-In the request, the client sends (in cleartext) its own identity and the
-identity of the server for which it is requesting credentials. The response,
-KRB_AS_REP, contains a ticket for the client to present to the server, and a
-session key that will be shared by the client and the server. The session
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-key and additional information are encrypted in the client's secret key. The
-KRB_AS_REP message contains information which can be used to detect replays,
-and to associate it with the message to which it replies. Various errors can
-occur; these are indicated by an error response (KRB_ERROR) instead of the
-KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR
-message contains information which can be used to associate it with the
-message to which it replies. The lack of encryption in the KRB_ERROR message
-precludes the ability to detect replays, fabrications, or modifications of
-such messages.
-
-Without preautentication, the authentication server does not know whether
-the client is actually the principal named in the request. It simply sends a
-reply without knowing or caring whether they are the same. This is
-acceptable because nobody but the principal whose identity was given in the
-request will be able to use the reply. Its critical information is encrypted
-in that principal's key. The initial request supports an optional field that
-can be used to pass additional information that might be needed for the
-initial exchange. This field may be used for preauthentication as described
-in section [hl<>].
-
-3.1.1. Generation of KRB_AS_REQ message
-
-The client may specify a number of options in the initial request. Among
-these options are whether pre-authentication is to be performed; whether the
-requested ticket is to be renewable, proxiable, or forwardable; whether it
-should be postdated or allow postdating of derivative tickets; and whether a
-renewable ticket will be accepted in lieu of a non-renewable ticket if the
-requested ticket expiration date cannot be satisfied by a non-renewable
-ticket (due to configuration constraints; see section 4). See section A.1
-for pseudocode.
-
-The client prepares the KRB_AS_REQ message and sends it to the KDC.
-
-3.1.2. Receipt of KRB_AS_REQ message
-
-If all goes well, processing the KRB_AS_REQ message will result in the
-creation of a ticket for the client to present to the server. The format for
-the ticket is described in section 5.3.1. The contents of the ticket are
-determined as follows.
-
-3.1.3. Generation of KRB_AS_REP message
-
-The authentication server looks up the client and server principals named in
-the KRB_AS_REQ in its database, extracting their respective keys. If
-required, the server pre-authenticates the request, and if the
-pre-authentication check fails, an error message with the code
-KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the
-requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP
-is returned. Otherwise it generates a 'random' session key[7].
-
-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
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-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.
-
-If the requested start time is absent, indicates a time in the past, or is
-within the window of acceptable clock skew for the KDC and the POSTDATE
-option has not been specified, then the start time of the ticket is set to
-the authentication server's current time. If it indicates a time in the
-future beyond the acceptable clock skew, but the POSTDATED option has not
-been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise
-the requested start time is checked against the policy of the local realm
-(the administrator might decide to prohibit certain types or ranges of
-postdated tickets), and if acceptable, the ticket's start time is set as
-requested and the INVALID flag is set in the new ticket. The postdated
-ticket must be validated before use by presenting it to the KDC after the
-start time has been reached.
-
-The expiration time of the ticket will be set to the minimum of the
-following:
-
-   * The expiration time (endtime) requested in the KRB_AS_REQ message.
-   * The ticket's start time plus the maximum allowable lifetime associated
-     with the client principal (the authentication server's database
-     includes a maximum ticket lifetime field in each principal's record;
-     see section 4).
-   * The ticket's start time plus the maximum allowable lifetime associated
-     with the server principal.
-   * The ticket's start time plus the maximum lifetime set by the policy of
-     the local realm.
-
-If the requested expiration time minus the start time (as determined above)
-is less than a site-determined minimum lifetime, an error message with code
-KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the
-ticket exceeds what was determined as above, and if the 'RENEWABLE-OK'
-option was requested, then the 'RENEWABLE' flag is set in the new ticket,
-and the renew-till value is set as if the 'RENEWABLE' option were requested
-(the field and option names are described fully in section 5.4.1).
-
-If the RENEWABLE option has been requested or if the RENEWABLE-OK option has
-been set and a renewable ticket is to be issued, then the renew-till field
-is set to the minimum of:
-
-   * Its requested value.
-   * The start time of the ticket plus the minimum of the two maximum
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-     renewable lifetimes associated with the principals' database entries.
-   * The start time of the ticket plus the maximum renewable lifetime set by
-     the policy of the local realm.
-
-The flags field of the new ticket will have the following options set if
-they have been requested and if the policy of the local realm allows:
-FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new
-ticket is post-dated (the start time is in the future), its INVALID flag
-will also be set.
-
-If all of the above succeed, the server formats a KRB_AS_REP message (see
-section 5.4.2), copying the addresses in the request into the caddr of the
-response, placing any required pre-authentication data into the padata of
-the response, and encrypts the ciphertext part in the client's key using the
-requested encryption method, and sends it to the client. See section A.2 for
-pseudocode.
-
-3.1.4. Generation of KRB_ERROR message
-
-Several errors can occur, and the Authentication Server responds by
-returning an error message, KRB_ERROR, to the client, with the error-code
-and e-text fields set to appropriate values. The error message contents and
-details are described in Section 5.9.1.
-
-3.1.5. Receipt of KRB_AS_REP message
-
-If the reply message type is KRB_AS_REP, then the client verifies that the
-cname and crealm fields in the cleartext portion of the reply match what it
-requested. If any padata fields are present, they may be used to derive the
-proper secret key to decrypt the message. The client decrypts the encrypted
-part of the response using its secret key, verifies that the nonce in the
-encrypted part matches the nonce it supplied in its request (to detect
-replays). It also verifies that the sname and srealm in the response match
-those in the request (or are otherwise expected values), and that the host
-address field is also correct. It then stores the ticket, session key, start
-and expiration times, and other information for later use. The
-key-expiration field from the encrypted part of the response may be checked
-to notify the user of impending key expiration (the client program could
-then suggest remedial action, such as a password change). See section A.3
-for pseudocode.
-
-Proper decryption of the KRB_AS_REP message is not sufficient to verify the
-identity of the user; the user and an attacker could cooperate to generate a
-KRB_AS_REP format message which decrypts properly but is not from the proper
-KDC. If the host wishes to verify the identity of the user, it must require
-the user to present application credentials which can be verified using a
-securely-stored secret key for the host. If those credentials can be
-verified, then the identity of the user can be assured.
-
-3.1.6. Receipt of KRB_ERROR message
-
-If the reply message type is KRB_ERROR, then the client interprets it as an
-error and performs whatever application-specific tasks are necessary to
-recover.
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-3.2. The Client/Server Authentication Exchange
-
-                             Summary
-Message direction                         Message type    Section
-Client to Application server              KRB_AP_REQ      5.5.1
-[optional] Application server to client   KRB_AP_REP or   5.5.2
-                                          KRB_ERROR       5.9.1
-
-The client/server authentication (CS) exchange is used by network
-applications to authenticate the client to the server and vice versa. The
-client must have already acquired credentials for the server using the AS or
-TGS exchange.
-
-3.2.1. The KRB_AP_REQ message
-
-The KRB_AP_REQ contains authentication information which should be part of
-the first message in an authenticated transaction. It contains a ticket, an
-authenticator, and some additional bookkeeping information (see section
-5.5.1 for the exact format). The ticket by itself is insufficient to
-authenticate a client, since tickets are passed across the network in
-cleartext[DS90], so the authenticator is used to prevent invalid replay of
-tickets by proving to the server that the client knows the session key of
-the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is
-referred to elsewhere as the 'authentication header.'
-
-3.2.2. Generation of a KRB_AP_REQ message
-
-When a client wishes to initiate authentication to a server, it obtains
-(either through a credentials cache, the AS exchange, or the TGS exchange) a
-ticket and session key for the desired service. The client may re-use any
-tickets it holds until they expire. To use a ticket the client constructs a
-new Authenticator from the the system time, its name, and optionally an
-application specific checksum, an initial sequence number to be used in
-KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in
-negotiations for a session key unique to this particular session.
-Authenticators may not be re-used and will be rejected if replayed to a
-server[LGDSR87]. If a sequence number is to be included, it should be
-randomly chosen so that even after many messages have been exchanged it is
-not likely to collide with other sequence numbers in use.
-
-The client may indicate a requirement of mutual authentication or the use of
-a session-key based ticket by setting the appropriate flag(s) in the
-ap-options field of the message.
-
-The Authenticator is encrypted in the session key and combined with the
-ticket to form the KRB_AP_REQ message which is then sent to the end server
-along with any additional application-specific information. See section A.9
-for pseudocode.
-
-3.2.3. Receipt of KRB_AP_REQ message
-
-Authentication is based on the server's current time of day (clocks must be
-loosely synchronized), the authenticator, and the ticket. Several errors are
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-possible. If an error occurs, the server is expected to reply to the client
-with a KRB_ERROR message. This message may be encapsulated in the
-application protocol if its 'raw' form is not acceptable to the protocol.
-The format of error messages is described in section 5.9.1.
-
-The algorithm for verifying authentication information is as follows. If the
-message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE
-error. If the key version indicated by the Ticket in the KRB_AP_REQ is not
-one the server can use (e.g., it indicates an old key, and the server no
-longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is
-returned. If the USE-SESSION-KEY flag is set in the ap-options field, it
-indicates to the server that the ticket is encrypted in the session key from
-the server's ticket-granting ticket rather than its secret key[10]. Since it
-is possible for the server to be registered in multiple realms, with
-different keys in each, the srealm field in the unencrypted portion of the
-ticket in the KRB_AP_REQ is used to specify which secret key the server
-should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is
-returned if the server doesn't have the proper key to decipher the ticket.
-
-The ticket is decrypted using the version of the server's key specified by
-the ticket. If the decryption routines detect a modification of the ticket
-(each encryption system must provide safeguards to detect modified
-ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned
-(chances are good that different keys were used to encrypt and decrypt).
-
-The authenticator is decrypted using the session key extracted from the
-decrypted ticket. If decryption shows it to have been modified, the
-KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client
-from the ticket are compared against the same fields in the authenticator.
-If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might
-not match, for example, if the wrong session key was used to encrypt the
-authenticator). The addresses in the ticket (if any) are then searched for
-an address matching the operating-system reported address of the client. If
-no match is found or the server insists on ticket addresses but none are
-present in the ticket, the KRB_AP_ERR_BADADDR error is returned.
-
-If the local (server) time and the client time in the authenticator differ
-by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW
-error is returned. If the server name, along with the client name, time and
-microsecond fields from the Authenticator match any recently-seen such
-tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The server must
-remember any authenticator presented within the allowable clock skew, so
-that a replay attempt is guaranteed to fail. If a server loses track of any
-authenticator presented within the allowable clock skew, it must reject all
-requests until the clock skew interval has passed. This assures that any
-lost or re-played authenticators will fall outside the allowable clock skew
-and can no longer be successfully replayed (If this is not done, an attacker
-could conceivably record the ticket and authenticator sent over the network
-to a server, then disable the client's host, pose as the disabled host, and
-replay the ticket and authenticator to subvert the authentication.). If a
-sequence number is provided in the authenticator, the server saves it for
-later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey is
-present, the server either saves it for later use or uses it to help
-generate its own choice for a subkey to be returned in a KRB_AP_REP message.
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-The server computes the age of the ticket: local (server) time minus the
-start time inside the Ticket. If the start time is later than the current
-time by more than the allowable clock skew or if the INVALID flag is set in
-the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the
-current time is later than end time by more than the allowable clock skew,
-the KRB_AP_ERR_TKT_EXPIRED error is returned.
-
-If all these checks succeed without an error, the server is assured that the
-client possesses the credentials of the principal named in the ticket and
-thus, the client has been authenticated to the server. See section A.10 for
-pseudocode.
-
-Passing these checks provides only authentication of the named principal; it
-does not imply authorization to use the named service. Applications must
-make a separate authorization decisions based upon the authenticated name of
-the user, the requested operation, local acces control information such as
-that contained in a .k5login or .k5users file, and possibly a separate
-distributed authorization service.
-
-3.2.4. Generation of a KRB_AP_REP message
-
-Typically, a client's request will include both the authentication
-information and its initial request in the same message, and the server need
-not explicitly reply to the KRB_AP_REQ. However, if mutual authentication
-(not only authenticating the client to the server, but also the server to
-the client) is being performed, the KRB_AP_REQ message will have
-MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is
-required in response. As with the error message, this message may be
-encapsulated in the application protocol if its "raw" form is not acceptable
-to the application's protocol. The timestamp and microsecond field used in
-the reply must be the client's timestamp and microsecond field (as provided
-in the authenticator)[12]. If a sequence number is to be included, it should
-be randomly chosen as described above for the authenticator. A subkey may be
-included if the server desires to negotiate a different subkey. The
-KRB_AP_REP message is encrypted in the session key extracted from the
-ticket. See section A.11 for pseudocode.
-
-3.2.5. Receipt of KRB_AP_REP message
-
-If a KRB_AP_REP message is returned, the client uses the session key from
-the credentials obtained for the server[13] to decrypt the message, and
-verifies that the timestamp and microsecond fields match those in the
-Authenticator it sent to the server. If they match, then the client is
-assured that the server is genuine. The sequence number and subkey (if
-present) are retained for later use. See section A.12 for pseudocode.
-
-3.2.6. Using the encryption key
-
-After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server
-share an encryption key which can be used by the application. The 'true
-session key' to be used for KRB_PRIV, KRB_SAFE, or other
-application-specific uses may be chosen by the application based on the
-subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases,
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-the use of this session key will be implicit in the protocol; in others the
-method of use must be chosen from several alternatives. We leave the
-protocol negotiations of how to use the key (e.g. selecting an encryption or
-checksum type) to the application programmer; the Kerberos protocol does not
-constrain the implementation options, but an example of how this might be
-done follows.
-
-One way that an application may choose to negotiate a key to be used for
-subequent integrity and privacy protection is for the client to propose a
-key in the subkey field of the authenticator. The server can then choose a
-key using the proposed key from the client as input, returning the new
-subkey in the subkey field of the application reply. This key could then be
-used for subsequent communication. To make this example more concrete, if
-the encryption method in use required a 56 bit key, and for whatever reason,
-one of the parties was prevented from using a key with more than 40 unknown
-bits, this method would allow the the party which is prevented from using
-more than 40 bits to either propose (if the client) an initial key with a
-known quantity for 16 of those bits, or to mask 16 of the bits (if the
-server) with the known quantity. The application implementor is warned,
-however, that this is only an example, and that an analysis of the
-particular crytosystem to be used, and the reasons for limiting the key
-length, must be made before deciding whether it is acceptable to mask bits
-of the key.
-
-With both the one-way and mutual authentication exchanges, the peers should
-take care not to send sensitive information to each other without proper
-assurances. In particular, applications that require privacy or integrity
-should use the KRB_AP_REP response from the server to client to assure both
-client and server of their peer's identity. If an application protocol
-requires privacy of its messages, it can use the KRB_PRIV message (section
-3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity.
-
-3.3. The Ticket-Granting Service (TGS) Exchange
-
-                          Summary
-      Message direction       Message type     Section
-      1. Client to Kerberos   KRB_TGS_REQ      5.4.1
-      2. Kerberos to client   KRB_TGS_REP or   5.4.2
-                              KRB_ERROR        5.9.1
-
-The TGS exchange between a client and the Kerberos Ticket-Granting Server is
-initiated by a client when it wishes to obtain authentication credentials
-for a given server (which might be registered in a remote realm), when it
-wishes to renew or validate an existing ticket, or when it wishes to obtain
-a proxy ticket. In the first case, the client must already have acquired a
-ticket for the Ticket-Granting Service using the AS exchange (the
-ticket-granting ticket is usually obtained when a client initially
-authenticates to the system, such as when a user logs in). The message
-format for the TGS exchange is almost identical to that for the AS exchange.
-The primary difference is that encryption and decryption in the TGS exchange
-does not take place under the client's key. Instead, the session key from
-the ticket-granting ticket or renewable ticket, or sub-session key from an
-Authenticator is used. As is the case for all application servers, expired
-tickets are not accepted by the TGS, so once a renewable or ticket-granting
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-ticket expires, the client must use a separate exchange to obtain valid
-tickets.
-
-The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the
-client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or
-KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the
-client plus a request for credentials. The authentication information
-consists of the authentication header (KRB_AP_REQ) which includes the
-client's previously obtained ticket-granting, renewable, or invalid ticket.
-In the ticket-granting ticket and proxy cases, the request may include one
-or more of: a list of network addresses, a collection of typed authorization
-data to be sealed in the ticket for authorization use by the application
-server, or additional tickets (the use of which are described later). The
-TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the
-session key from the ticket-granting ticket or renewable ticket, or if
-present, in the sub-session key from the Authenticator (part of the
-authentication header). The KRB_ERROR message contains an error code and
-text explaining what went wrong. The KRB_ERROR message is not encrypted. The
-KRB_TGS_REP message contains information which can be used to detect
-replays, and to associate it with the message to which it replies. The
-KRB_ERROR message also contains information which can be used to associate
-it with the message to which it replies, but the lack of encryption in the
-KRB_ERROR message precludes the ability to detect replays or fabrications of
-such messages.
-
-3.3.1. Generation of KRB_TGS_REQ message
-
-Before sending a request to the ticket-granting service, the client must
-determine in which realm the application server is registered[15]. If the
-client does not already possess a ticket-granting ticket for the appropriate
-realm, then one must be obtained. This is first attempted by requesting a
-ticket-granting ticket for the destination realm from a Kerberos server for
-which the client does posess a ticket-granting ticket (using the KRB_TGS_REQ
-message recursively). The Kerberos server may return a TGT for the desired
-realm in which case one can proceed. Alternatively, the Kerberos server may
-return a TGT for a realm which is 'closer' to the desired realm (further
-along the standard hierarchical path), in which case this step must be
-repeated with a Kerberos server in the realm specified in the returned TGT.
-If neither are returned, then the request must be retried with a Kerberos
-server for a realm higher in the hierarchy. This request will itself require
-a ticket-granting ticket for the higher realm which must be obtained by
-recursively applying these directions.
-
-Once the client obtains a ticket-granting ticket for the appropriate realm,
-it determines which Kerberos servers serve that realm, and contacts one. The
-list might be obtained through a configuration file or network service or it
-may be generated from the name of the realm; as long as the secret keys
-exchanged by realms are kept secret, only denial of service results from
-using a false Kerberos server.
-
-As in the AS exchange, the client may specify a number of options in the
-KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing
-an authentication header as an element of the padata field, and including
-the same fields as used in the KRB_AS_REQ message along with several
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-optional fields: the enc-authorization-data field for application server use
-and additional tickets required by some options.
-
-In preparing the authentication header, the client can select a sub-session
-key under which the response from the Kerberos server will be encrypted[16].
-If the sub-session key is not specified, the session key from the
-ticket-granting ticket will be used. If the enc-authorization-data is
-present, it must be encrypted in the sub-session key, if present, from the
-authenticator portion of the authentication header, or if not present, using
-the session key from the ticket-granting ticket.
-
-Once prepared, the message is sent to a Kerberos server for the destination
-realm. See section A.5 for pseudocode.
-
-3.3.2. Receipt of KRB_TGS_REQ message
-
-The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ
-message, but there are many additional checks to be performed. First, the
-Kerberos server must determine which server the accompanying ticket is for
-and it must select the appropriate key to decrypt it. For a normal
-KRB_TGS_REQ message, it will be for the ticket granting service, and the
-TGS's key will be used. If the TGT was issued by another realm, then the
-appropriate inter-realm key must be used. If the accompanying ticket is not
-a ticket granting ticket for the current realm, but is for an application
-server in the current realm, the RENEW, VALIDATE, or PROXY options are
-specified in the request, and the server for which a ticket is requested is
-the server named in the accompanying ticket, then the KDC will decrypt the
-ticket in the authentication header using the key of the server for which it
-was issued. If no ticket can be found in the padata field, the
-KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
-
-Once the accompanying ticket has been decrypted, the user-supplied checksum
-in the Authenticator must be verified against the contents of the request,
-and the message rejected if the checksums do not match (with an error code
-of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not
-collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the
-checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is
-returned. If the authorization-data are present, they are decrypted using
-the sub-session key from the Authenticator.
-
-If any of the decryptions indicate failed integrity checks, the
-KRB_AP_ERR_BAD_INTEGRITY error is returned.
-
-3.3.3. Generation of KRB_TGS_REP message
-
-The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP),
-but with its type field set to KRB_TGS_REP. The detailed specification is in
-section 5.4.2.
-
-The response will include a ticket for the requested server. The Kerberos
-database is queried to retrieve the record for the requested server
-(including the key with which the ticket will be encrypted). If the request
-is for a ticket granting ticket for a remote realm, and if no key is shared
-with the requested realm, then the Kerberos server will select the realm
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-"closest" to the requested realm with which it does share a key, and use
-that realm instead. This is the only case where the response from the KDC
-will be for a different server than that requested by the client.
-
-By default, the address field, the client's name and realm, the list of
-transited realms, the time of initial authentication, the expiration time,
-and the authorization data of the newly-issued ticket will be copied from
-the ticket-granting ticket (TGT) or renewable ticket. If the transited field
-needs to be updated, but the transited type is not supported, the
-KDC_ERR_TRTYPE_NOSUPP error is returned.
-
-If the request specifies an endtime, then the endtime of the new ticket is
-set to the minimum of (a) that request, (b) the endtime from the TGT, and
-(c) the starttime of the TGT plus the minimum of the maximum life for the
-application server and the maximum life for the local realm (the maximum
-life for the requesting principal was already applied when the TGT was
-issued). If the new ticket is to be a renewal, then the endtime above is
-replaced by the minimum of (a) the value of the renew_till field of the
-ticket and (b) the starttime for the new ticket plus the life
-(endtime-starttime) of the old ticket.
-
-If the FORWARDED option has been requested, then the resulting ticket will
-contain the addresses specified by the client. This option will only be
-honored if the FORWARDABLE flag is set in the TGT. The PROXY option is
-similar; the resulting ticket will contain the addresses specified by the
-client. It will be honored only if the PROXIABLE flag in the TGT is set. The
-PROXY option will not be honored on requests for additional ticket-granting
-tickets.
-
-If the requested start time is absent, indicates a time in the past, or is
-within the window of acceptable clock skew for the KDC and the POSTDATE
-option has not been specified, then the start time of the ticket is set to
-the authentication server's current time. If it indicates a time in the
-future beyond the acceptable clock skew, but the POSTDATED option has not
-been specified or the MAY-POSTDATE flag is not set in the TGT, then the
-error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting
-ticket has the MAY-POSTDATE flag set, then the resulting ticket will be
-postdated and the requested starttime is checked against the policy of the
-local realm. If acceptable, the ticket's start time is set as requested, and
-the INVALID flag is set. The postdated ticket must be validated before use
-by presenting it to the KDC after the starttime has been reached. However,
-in no case may the starttime, endtime, or renew-till time of a newly-issued
-postdated ticket extend beyond the renew-till time of the ticket-granting
-ticket.
-
-If the ENC-TKT-IN-SKEY option has been specified and an additional ticket
-has been included in the request, the KDC will decrypt the additional ticket
-using the key for the server to which the additional ticket was issued and
-verify that it is a ticket-granting ticket. If the name of the requested
-server is missing from the request, the name of the client in the additional
-ticket will be used. Otherwise the name of the requested server will be
-compared to the name of the client in the additional ticket and if
-different, the request will be rejected. If the request succeeds, the
-session key from the additional ticket will be used to encrypt the new
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-ticket that is issued instead of using the key of the server for which the
-new ticket will be used[17].
-
-If the name of the server in the ticket that is presented to the KDC as part
-of the authentication header is not that of the ticket-granting server
-itself, the server is registered in the realm of the KDC, and the RENEW
-option is requested, then the KDC will verify that the RENEWABLE flag is set
-in the ticket, that the INVALID flag is not set in the ticket, and that the
-renew_till time is still in the future. If the VALIDATE option is rqeuested,
-the KDC will check that the starttime has passed and the INVALID flag is
-set. If the PROXY option is requested, then the KDC will check that the
-PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket
-passes the hotlist check described in the next paragraph, the KDC will issue
-the appropriate new ticket.
-
-3.3.3.1. Checking for revoked tickets
-
-Whenever a request is made to the ticket-granting server, the presented
-ticket(s) is(are) checked against a hot-list of tickets which have been
-canceled. This hot-list might be implemented by storing a range of issue
-timestamps for 'suspect tickets'; if a presented ticket had an authtime in
-that range, it would be rejected. In this way, a stolen ticket-granting
-ticket or renewable ticket cannot be used to gain additional tickets
-(renewals or otherwise) once the theft has been reported. Any normal ticket
-obtained before it was reported stolen will still be valid (because they
-require no interaction with the KDC), but only until their normal expiration
-time.
-
-The ciphertext part of the response in the KRB_TGS_REP message is encrypted
-in the sub-session key from the Authenticator, if present, or the session
-key key from the ticket-granting ticket. It is not encrypted using the
-client's secret key. Furthermore, the client's key's expiration date and the
-key version number fields are left out since these values are stored along
-with the client's database record, and that record is not needed to satisfy
-a request based on a ticket-granting ticket. See section A.6 for pseudocode.
-
-3.3.3.2. Encoding the transited field
-
-If the identity of the server in the TGT that is presented to the KDC as
-part of the authentication header is that of the ticket-granting service,
-but the TGT was issued from another realm, the KDC will look up the
-inter-realm key shared with that realm and use that key to decrypt the
-ticket. If the ticket is valid, then the KDC will honor the request, subject
-to the constraints outlined above in the section describing the AS exchange.
-The realm part of the client's identity will be taken from the
-ticket-granting ticket. The name of the realm that issued the
-ticket-granting ticket will be added to the transited field of the ticket to
-be issued. This is accomplished by reading the transited field from the
-ticket-granting ticket (which is treated as an unordered set of realm
-names), adding the new realm to the set, then constructing and writing out
-its encoded (shorthand) form (this may involve a rearrangement of the
-existing encoding).
-
-Note that the ticket-granting service does not add the name of its own
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-realm. Instead, its responsibility is to add the name of the previous realm.
-This prevents a malicious Kerberos server from intentionally leaving out its
-own name (it could, however, omit other realms' names).
-
-The names of neither the local realm nor the principal's realm are to be
-included in the transited field. They appear elsewhere in the ticket and
-both are known to have taken part in authenticating the principal. Since the
-endpoints are not included, both local and single-hop inter-realm
-authentication result in a transited field that is empty.
-
-Because the name of each realm transited is added to this field, it might
-potentially be very long. To decrease the length of this field, its contents
-are encoded. The initially supported encoding is optimized for the normal
-case of inter-realm communication: a hierarchical arrangement of realms
-using either domain or X.500 style realm names. This encoding (called
-DOMAIN-X500-COMPRESS) is now described.
-
-Realm names in the transited field are separated by a ",". The ",", "\",
-trailing "."s, and leading spaces (" ") are special characters, and if they
-are part of a realm name, they must be quoted in the transited field by
-preced- ing them with a "\".
-
-A realm name ending with a "." is interpreted as being prepended to the
-previous realm. For example, we can encode traversal of EDU, MIT.EDU,
-ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
-
-     "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
-
-Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they
-would not be included in this field, and we would have:
-
-     "EDU,MIT.,WASHINGTON.EDU"
-
-A realm name beginning with a "/" is interpreted as being appended to the
-previous realm[18]. If it is to stand by itself, then it should be preceded
-by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO,
-/COM/HP, /COM, and /COM/DEC as:
-
-     "/COM,/HP,/APOLLO, /COM/DEC".
-
-Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they
-they would not be included in this field, and we would have:
-
-     "/COM,/HP"
-
-A null subfield preceding or following a "," indicates that all realms
-between the previous realm and the next realm have been traversed[19]. Thus,
-"," means that all realms along the path between the client and the server
-have been traversed. ",EDU, /COM," means that that all realms from the
-client's realm up to EDU (in a domain style hierarchy) have been traversed,
-and that everything from /COM down to the server's realm in an X.500 style
-has also been traversed. This could occur if the EDU realm in one hierarchy
-shares an inter-realm key directly with the /COM realm in another hierarchy.
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-3.3.4. Receipt of KRB_TGS_REP message
-
-When the KRB_TGS_REP is received by the client, it is processed in the same
-manner as the KRB_AS_REP processing described above. The primary difference
-is that the ciphertext part of the response must be decrypted using the
-session key from the ticket-granting ticket rather than the client's secret
-key. See section A.7 for pseudocode.
-
-3.4. The KRB_SAFE Exchange
-
-The KRB_SAFE message may be used by clients requiring the ability to detect
-modifications of messages they exchange. It achieves this by including a
-keyed collision-proof checksum of the user data and some control
-information. The checksum is keyed with an encryption key (usually the last
-key negotiated via subkeys, or the session key if no negotiation has
-occured).
-
-3.4.1. Generation of a KRB_SAFE message
-
-When an application wishes to send a KRB_SAFE message, it collects its data
-and the appropriate control information and computes a checksum over them.
-The checksum algorithm should be a keyed one-way hash function (such as the
-RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC),
-generated using the sub-session key if present, or the session key.
-Different algorithms may be selected by changing the checksum type in the
-message. Unkeyed or non-collision-proof checksums are not suitable for this
-use.
-
-The control information for the KRB_SAFE message includes both a timestamp
-and a sequence number. The designer of an application using the KRB_SAFE
-message must choose at least one of the two mechanisms. This choice should
-be based on the needs of the application protocol.
-
-Sequence numbers are useful when all messages sent will be received by one's
-peer. Connection state is presently required to maintain the session key, so
-maintaining the next sequence number should not present an additional
-problem.
-
-If the application protocol is expected to tolerate lost messages without
-them being resent, the use of the timestamp is the appropriate replay
-detection mechanism. Using timestamps is also the appropriate mechanism for
-multi-cast protocols where all of one's peers share a common sub-session
-key, but some messages will be sent to a subset of one's peers.
-
-After computing the checksum, the client then transmits the information and
-checksum to the recipient in the message format specified in section 5.6.1.
-
-3.4.2. Receipt of KRB_SAFE message
-
-When an application receives a KRB_SAFE message, it verifies it as follows.
-If any error occurs, an error code is reported for use by the application.
-
-The message is first checked by verifying that the protocol version and type
-fields match the current version and KRB_SAFE, respectively. A mismatch
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
-application verifies that the checksum used is a collision-proof keyed
-checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. The
-recipient verifies that the operating system's report of the sender's
-address matches the sender's address in the message, and (if a recipient
-address is specified or the recipient requires an address) that one of the
-recipient's addresses appears as the recipient's address in the message. A
-failed match for either case generates a KRB_AP_ERR_BADADDR error. Then the
-timestamp and usec and/or the sequence number fields are checked. If
-timestamp and usec are expected and not present, or they are present but not
-current, the KRB_AP_ERR_SKEW error is generated. If the server name, along
-with the client name, time and microsecond fields from the Authenticator
-match any recently-seen (sent or received[20] ) such tuples, the
-KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number is
-included, or a sequence number is expected but not present, the
-KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or
-a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated.
-Finally, the checksum is computed over the data and control information, and
-if it doesn't match the received checksum, a KRB_AP_ERR_MODIFIED error is
-generated.
-
-If all the checks succeed, the application is assured that the message was
-generated by its peer and was not modi- fied in transit.
-
-3.5. The KRB_PRIV Exchange
-
-The KRB_PRIV message may be used by clients requiring confidentiality and
-the ability to detect modifications of exchanged messages. It achieves this
-by encrypting the messages and adding control information.
-
-3.5.1. Generation of a KRB_PRIV message
-
-When an application wishes to send a KRB_PRIV message, it collects its data
-and the appropriate control information (specified in section 5.7.1) and
-encrypts them under an encryption key (usually the last key negotiated via
-subkeys, or the session key if no negotiation has occured). As part of the
-control information, the client must choose to use either a timestamp or a
-sequence number (or both); see the discussion in section 3.4.1 for
-guidelines on which to use. After the user data and control information are
-encrypted, the client transmits the ciphertext and some 'envelope'
-information to the recipient.
-
-3.5.2. Receipt of KRB_PRIV message
-
-When an application receives a KRB_PRIV message, it verifies it as follows.
-If any error occurs, an error code is reported for use by the application.
-
-The message is first checked by verifying that the protocol version and type
-fields match the current version and KRB_PRIV, respectively. A mismatch
-generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
-application then decrypts the ciphertext and processes the resultant
-plaintext. If decryption shows the data to have been modified, a
-KRB_AP_ERR_BAD_INTEGRITY error is generated. The recipient verifies that the
-operating system's report of the sender's address matches the sender's
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-address in the message, and (if a recipient address is specified or the
-recipient requires an address) that one of the recipient's addresses appears
-as the recipient's address in the message. A failed match for either case
-generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the
-sequence number fields are checked. If timestamp and usec are expected and
-not present, or they are present but not current, the KRB_AP_ERR_SKEW error
-is generated. If the server name, along with the client name, time and
-microsecond fields from the Authenticator match any recently-seen such
-tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence
-number is included, or a sequence number is expected but not present, the
-KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or
-a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated.
-
-If all the checks succeed, the application can assume the message was
-generated by its peer, and was securely transmitted (without intruders able
-to see the unencrypted contents).
-
-3.6. The KRB_CRED Exchange
-
-The KRB_CRED message may be used by clients requiring the ability to send
-Kerberos credentials from one host to another. It achieves this by sending
-the tickets together with encrypted data containing the session keys and
-other information associated with the tickets.
-
-3.6.1. Generation of a KRB_CRED message
-
-When an application wishes to send a KRB_CRED message it first (using the
-KRB_TGS exchange) obtains credentials to be sent to the remote host. It then
-constructs a KRB_CRED message using the ticket or tickets so obtained,
-placing the session key needed to use each ticket in the key field of the
-corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED
-message.
-
-Other information associated with each ticket and obtained during the
-KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in
-the encrypted part of the KRB_CRED message. The current time and, if
-specifically required by the application the nonce, s-address, and r-address
-fields, are placed in the encrypted part of the KRB_CRED message which is
-then encrypted under an encryption key previosuly exchanged in the KRB_AP
-exchange (usually the last key negotiated via subkeys, or the session key if
-no negotiation has occured).
-
-3.6.2. Receipt of KRB_CRED message
-
-When an application receives a KRB_CRED message, it verifies it. If any
-error occurs, an error code is reported for use by the application. The
-message is verified by checking that the protocol version and type fields
-match the current version and KRB_CRED, respectively. A mismatch generates a
-KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then
-decrypts the ciphertext and processes the resultant plaintext. If decryption
-shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
-generated.
-
-If present or required, the recipient verifies that the operating system's
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-report of the sender's address matches the sender's address in the message,
-and that one of the recipient's addresses appears as the recipient's address
-in the message. A failed match for either case generates a
-KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field
-if required) are checked next. If the timestamp and usec are not present, or
-they are present but not current, the KRB_AP_ERR_SKEW error is generated.
-
-If all the checks succeed, the application stores each of the new tickets in
-its ticket cache together with the session key and other information in the
-corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED
-message.
-
-4. The Kerberos Database
-
-The Kerberos server must have access to a database contain- ing the
-principal identifiers and secret keys of principals to be authenticated[21].
-
-4.1. Database contents
-
-A database entry should contain at least the following fields:
-
-Field                Value
-
-name                 Principal's identifier
-key                  Principal's secret key
-p_kvno               Principal's key version
-max_life             Maximum lifetime for Tickets
-max_renewable_life   Maximum total lifetime for renewable Tickets
-
-The name field is an encoding of the principal's identifier. The key field
-contains an encryption key. This key is the principal's secret key. (The key
-can be encrypted before storage under a Kerberos "master key" to protect it
-in case the database is compromised but the master key is not. In that case,
-an extra field must be added to indicate the master key version used, see
-below.) The p_kvno field is the key version number of the principal's secret
-key. The max_life field contains the maximum allowable lifetime (endtime -
-starttime) for any Ticket issued for this principal. The max_renewable_life
-field contains the maximum allowable total lifetime for any renewable Ticket
-issued for this principal. (See section 3.1 for a description of how these
-lifetimes are used in determining the lifetime of a given Ticket.)
-
-A server may provide KDC service to several realms, as long as the database
-representation provides a mechanism to distinguish between principal records
-with identifiers which differ only in the realm name.
-
-When an application server's key changes, if the change is routine (i.e. not
-the result of disclosure of the old key), the old key should be retained by
-the server until all tickets that had been issued using that key have
-expired. Because of this, it is possible for several keys to be active for a
-single principal. Ciphertext encrypted in a principal's key is always tagged
-with the version of the key that was used for encryption, to help the
-recipient find the proper key for decryption.
-
-When more than one key is active for a particular principal, the principal
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-will have more than one record in the Kerberos database. The keys and key
-version numbers will differ between the records (the rest of the fields may
-or may not be the same). Whenever Kerberos issues a ticket, or responds to a
-request for initial authentication, the most recent key (known by the
-Kerberos server) will be used for encryption. This is the key with the
-highest key version number.
-
-4.2. Additional fields
-
-Project Athena's KDC implementation uses additional fields in its database:
-
-Field        Value
-
-K_kvno       Kerberos' key version
-expiration   Expiration date for entry
-attributes   Bit field of attributes
-mod_date     Timestamp of last modification
-mod_name     Modifying principal's identifier
-
-The K_kvno field indicates the key version of the Kerberos master key under
-which the principal's secret key is encrypted.
-
-After an entry's expiration date has passed, the KDC will return an error to
-any client attempting to gain tickets as or for the principal. (A database
-may want to maintain two expiration dates: one for the principal, and one
-for the principal's current key. This allows password aging to work
-independently of the principal's expiration date. However, due to the
-limited space in the responses, the KDC must combine the key expiration and
-principal expiration date into a single value called 'key_exp', which is
-used as a hint to the user to take administrative action.)
-
-The attributes field is a bitfield used to govern the operations involving
-the principal. This field might be useful in conjunction with user
-registration procedures, for site-specific policy implementations (Project
-Athena currently uses it for their user registration process controlled by
-the system-wide database service, Moira [LGDSR87]), to identify whether a
-principal can play the role of a client or server or both, to note whether a
-server is appropriate trusted to recieve credentials delegated by a client,
-or to identify the 'string to key' conversion algorithm used for a
-principal's key[22]. Other bits are used to indicate that certain ticket
-options should not be allowed in tickets encrypted under a principal's key
-(one bit each): Disallow issuing postdated tickets, disallow issuing
-forwardable tickets, disallow issuing tickets based on TGT authentication,
-disallow issuing renewable tickets, disallow issuing proxiable tickets, and
-disallow issuing tickets for which the principal is the server.
-
-The mod_date field contains the time of last modification of the entry, and
-the mod_name field contains the name of the principal which last modified
-the entry.
-
-4.3. Frequently Changing Fields
-
-Some KDC implementations may wish to maintain the last time that a request
-was made by a particular principal. Information that might be maintained
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-includes the time of the last request, the time of the last request for a
-ticket-granting ticket, the time of the last use of a ticket-granting
-ticket, or other times. This information can then be returned to the user in
-the last-req field (see section 5.2).
-
-Other frequently changing information that can be maintained is the latest
-expiration time for any tickets that have been issued using each key. This
-field would be used to indicate how long old keys must remain valid to allow
-the continued use of outstanding tickets.
-
-4.4. Site Constants
-
-The KDC implementation should have the following configurable constants or
-options, to allow an administrator to make and enforce policy decisions:
-
-   * The minimum supported lifetime (used to determine whether the
-     KDC_ERR_NEVER_VALID error should be returned). This constant should
-     reflect reasonable expectations of round-trip time to the KDC,
-     encryption/decryption time, and processing time by the client and
-     target server, and it should allow for a minimum 'useful' lifetime.
-   * The maximum allowable total (renewable) lifetime of a ticket
-     (renew_till - starttime).
-   * The maximum allowable lifetime of a ticket (endtime - starttime).
-   * Whether to allow the issue of tickets with empty address fields
-     (including the ability to specify that such tickets may only be issued
-     if the request specifies some authorization_data).
-   * Whether proxiable, forwardable, renewable or post-datable tickets are
-     to be issued.
-
-5. Message Specifications
-
-The following sections describe the exact contents and encoding of protocol
-messages and objects. The ASN.1 base definitions are presented in the first
-subsection. The remaining subsections specify the protocol objects (tickets
-and authenticators) and messages. Specification of encryption and checksum
-techniques, and the fields related to them, appear in section 6.
-
-5.1. ASN.1 Distinguished Encoding Representation
-
-All uses of ASN.1 in Kerberos shall use the Distinguished Encoding
-Representation of the data elements as described in the X.509 specification,
-section 8.7 [X509-88].
-
-5.2. ASN.1 Base Definitions
-
-The following ASN.1 base definitions are used in the rest of this section.
-Note that since the underscore character (_) is not permitted in ASN.1
-names, the hyphen (-) is used in its place for the purposes of ASN.1 names.
-
-Realm ::=           GeneralString
-PrincipalName ::=   SEQUENCE {
-                    name-type[0]     INTEGER,
-                    name-string[1]   SEQUENCE OF GeneralString
-}
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-Kerberos realms are encoded as GeneralStrings. Realms shall not contain a
-character with the code 0 (the ASCII NUL). Most realms will usually consist
-of several components separated by periods (.), in the style of Internet
-Domain Names, or separated by slashes (/) in the style of X.500 names.
-Acceptable forms for realm names are specified in section 7. A PrincipalName
-is a typed sequence of components consisting of the following sub-fields:
-
-name-type
-     This field specifies the type of name that follows. Pre-defined values
-     for this field are specified in section 7.2. The name-type should be
-     treated as a hint. Ignoring the name type, no two names can be the same
-     (i.e. at least one of the components, or the realm, must be different).
-     This constraint may be eliminated in the future.
-name-string
-     This field encodes a sequence of components that form a name, each
-     component encoded as a GeneralString. Taken together, a PrincipalName
-     and a Realm form a principal identifier. Most PrincipalNames will have
-     only a few components (typically one or two).
-
-KerberosTime ::=   GeneralizedTime
-                   -- Specifying UTC time zone (Z)
-
-The timestamps used in Kerberos are encoded as GeneralizedTimes. An encoding
-shall specify the UTC time zone (Z) and shall not include any fractional
-portions of the seconds. It further shall not include any separators.
-Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 pm
-on 6 November 1985 is 19851106210627Z.
-
-HostAddress ::=     SEQUENCE  {
-                    addr-type[0]             INTEGER,
-                    address[1]               OCTET STRING
-}
-
-HostAddresses ::=   SEQUENCE OF HostAddress
-
-The host adddress encodings consists of two fields:
-
-addr-type
-     This field specifies the type of address that follows. Pre-defined
-     values for this field are specified in section 8.1.
-address
-     This field encodes a single address of type addr-type.
-
-The two forms differ slightly. HostAddress contains exactly one address;
-HostAddresses contains a sequence of possibly many addresses.
-
-AuthorizationData ::=   SEQUENCE OF SEQUENCE {
-                        ad-type[0]               INTEGER,
-                        ad-data[1]               OCTET STRING
-}
-
-ad-data
-     This field contains authorization data to be interpreted according to
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-     the value of the corresponding ad-type field.
-ad-type
-     This field specifies the format for the ad-data subfield. All negative
-     values are reserved for local use. Non-negative values are reserved for
-     registered use.
-
-Each sequence of type and data is refered to as an authorization element.
-Elements may be application specific, however, there is a common set of
-recursive elements that should be understood by all implementations. These
-elements contain other elements embedded within them, and the interpretation
-of the encapsulating element determines which of the embedded elements must
-be interpreted, and which may be ignored. Definitions for these common
-elements may be found in Appendix B.
-
-TicketExtensions ::= SEQUENCE OF SEQUENCE {
-           te-type[0]       INTEGER,
-           te-data[1]       OCTET STRING
-}
-
-
-
-te-data
-     This field contains opaque data that must be caried with the ticket to
-     support extensions to the Kerberos protocol including but not limited
-     to some forms of inter-realm key exchange and plaintext authorization
-     data. See appendix C for some common uses of this field.
-te-type
-     This field specifies the format for the te-data subfield. All negative
-     values are reserved for local use. Non-negative values are reserved for
-     registered use.
-
-APOptions ::=   BIT STRING {
-                  reserved(0),
-                  use-session-key(1),
-                  mutual-required(2)
-}
-
-TicketFlags ::= BIT STRING {
-                  reserved(0),
-                  forwardable(1),
-                  forwarded(2),
-                  proxiable(3),
-                  proxy(4),
-                  may-postdate(5),
-                  postdated(6),
-                  invalid(7),
-                  renewable(8),
-                  initial(9),
-                  pre-authent(10),
-                  hw-authent(11),
-                  transited-policy-checked(12),
-                  ok-as-delegate(13)
-}
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-KDCOptions ::=   BIT STRING {
-                  reserved(0),
-                  forwardable(1),
-                  forwarded(2),
-                  proxiable(3),
-                  proxy(4),
-                  allow-postdate(5),
-                  postdated(6),
-                  unused7(7),
-                  renewable(8),
-                  unused9(9),
-                  unused10(10),
-                  unused11(11),
-                  unused12(12),
-                  unused13(13),
-                  disable-transited-check(26),
-                  renewable-ok(27),
-                  enc-tkt-in-skey(28),
-                  renew(30),
-                  validate(31)
-}
-
-ASN.1 Bit strings have a length and a value. When used in Kerberos for the
-APOptions, TicketFlags, and KDCOptions, the length of the bit string on
-generated values should be the smallest multiple of 32 bits needed to
-include the highest order bit that is set (1), but in no case less than 32
-bits. Implementations should accept values of bit strings of any length and
-treat the value of flags cooresponding to bits beyond the end of the bit
-string as if the bit were reset (0). Comparisonof bit strings of different
-length should treat the smaller string as if it were padded with zeros
-beyond the high order bits to the length of the longer string[23].
-
-LastReq ::=   SEQUENCE OF SEQUENCE {
-               lr-type[0]               INTEGER,
-               lr-value[1]              KerberosTime
-}
-
-lr-type
-     This field indicates how the following lr-value field is to be
-     interpreted. Negative values indicate that the information pertains
-     only to the responding server. Non-negative values pertain to all
-     servers for the realm. If the lr-type field is zero (0), then no
-     information is conveyed by the lr-value subfield. If the absolute value
-     of the lr-type field is one (1), then the lr-value subfield is the time
-     of last initial request for a TGT. If it is two (2), then the lr-value
-     subfield is the time of last initial request. If it is three (3), then
-     the lr-value subfield is the time of issue for the newest
-     ticket-granting ticket used. If it is four (4), then the lr-value
-     subfield is the time of the last renewal. If it is five (5), then the
-     lr-value subfield is the time of last request (of any type).
-lr-value
-     This field contains the time of the last request. the time must be
-     interpreted according to the contents of the accompanying lr-type
-     subfield.
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-See section 6 for the definitions of Checksum, ChecksumType, EncryptedData,
-EncryptionKey, EncryptionType, and KeyType.
-
-5.3. Tickets and Authenticators
-
-This section describes the format and encryption parameters for tickets and
-authenticators. When a ticket or authenticator is included in a protocol
-message it is treated as an opaque object.
-
-5.3.1. Tickets
-
-A ticket is a record that helps a client authenticate to a service. A Ticket
-contains the following information:
-
-Ticket ::=        [APPLICATION 1] SEQUENCE {
-                  tkt-vno[0]                   INTEGER,
-                  realm[1]                     Realm,
-                  sname[2]                     PrincipalName,
-                  enc-part[3]                  EncryptedData,
-                  extensions[4]                TicketExtensions OPTIONAL
-}
-
--- Encrypted part of ticket
-EncTicketPart ::= [APPLICATION 3] SEQUENCE {
-                  flags[0]                     TicketFlags,
-                  key[1]                       EncryptionKey,
-                  crealm[2]                    Realm,
-                  cname[3]                     PrincipalName,
-                  transited[4]                 TransitedEncoding,
-                  authtime[5]                  KerberosTime,
-                  starttime[6]                 KerberosTime OPTIONAL,
-                  endtime[7]                   KerberosTime,
-                  renew-till[8]                KerberosTime OPTIONAL,
-                  caddr[9]                     HostAddresses OPTIONAL,
-                  authorization-data[10]       AuthorizationData OPTIONAL
-}
--- encoded Transited field
-TransitedEncoding ::=   SEQUENCE {
-                        tr-type[0]             INTEGER, -- must be registered
-                        contents[1]            OCTET STRING
-}
-
-The encoding of EncTicketPart is encrypted in the key shared by Kerberos and
-the end server (the server's secret key). See section 6 for the format of
-the ciphertext.
-
-tkt-vno
-     This field specifies the version number for the ticket format. This
-     document describes version number 5.
-realm
-     This field specifies the realm that issued a ticket. It also serves to
-     identify the realm part of the server's principal identifier. Since a
-     Kerberos server can only issue tickets for servers within its realm,
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-     the two will always be identical.
-sname
-     This field specifies the name part of the server's identity.
-enc-part
-     This field holds the encrypted encoding of the EncTicketPart sequence.
-extensions
-     This optional field contains a sequence of extentions that may be used
-     to carry information that must be carried with the ticket to support
-     several extensions, including but not limited to plaintext
-     authorization data, tokens for exchanging inter-realm keys, and other
-     information that must be associated with a ticket for use by the
-     application server. See Appendix C for definitions of some common
-     extensions.
-
-     Note that some older versions of Kerberos did not support this field.
-     Because this is an optional field it will not break older clients, but
-     older clients might strip this field from the ticket before sending it
-     to the application server. This limits the usefulness of this ticket
-     field to environments where the ticket will not be parsed and
-     reconstructed by these older Kerberos clients.
-
-     If it is known that the client will strip this field from the ticket,
-     as an interim measure the KDC may append this field to the end of the
-     enc-part of the ticket and append a traler indicating the lenght of the
-     appended extensions field. (this paragraph is open for discussion,
-     including the form of the traler).
-flags
-     This field indicates which of various options were used or requested
-     when the ticket was issued. It is a bit-field, where the selected
-     options are indicated by the bit being set (1), and the unselected
-     options and reserved fields being reset (0). Bit 0 is the most
-     significant bit. The encoding of the bits is specified in section 5.2.
-     The flags are described in more detail above in section 2. The meanings
-     of the flags are:
-
-          Bit(s)      Name         Description
-
-          0           RESERVED
-                                   Reserved for future  expansion  of  this
-                                   field.
-
-          1           FORWARDABLE
-                                   The FORWARDABLE flag  is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.  When set,  this
-                                   flag  tells  the  ticket-granting server
-                                   that it is OK to  issue  a  new  ticket-
-                                   granting ticket with a different network
-                                   address based on the presented ticket.
-
-          2           FORWARDED
-                                   When set, this flag indicates  that  the
-                                   ticket  has either been forwarded or was
-                                   issued based on authentication involving
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-                                   a forwarded ticket-granting ticket.
-
-          3           PROXIABLE
-                                   The  PROXIABLE  flag  is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.   The  PROXIABLE
-                                   flag  has an interpretation identical to
-                                   that of  the  FORWARDABLE  flag,  except
-                                   that   the   PROXIABLE  flag  tells  the
-                                   ticket-granting server  that  only  non-
-                                   ticket-granting  tickets  may  be issued
-                                   with different network addresses.
-
-          4           PROXY
-                                   When set, this  flag  indicates  that  a
-                                   ticket is a proxy.
-
-          5           MAY-POSTDATE
-                                   The MAY-POSTDATE flag is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.  This flag tells
-                                   the  ticket-granting server that a post-
-                                   dated ticket may be issued based on this
-                                   ticket-granting ticket.
-
-          6           POSTDATED
-                                   This flag indicates that this ticket has
-                                   been  postdated.   The  end-service  can
-                                   check the authtime field to see when the
-                                   original authentication occurred.
-
-          7           INVALID
-                                   This flag indicates  that  a  ticket  is
-                                   invalid, and it must be validated by the
-                                   KDC  before  use.   Application  servers
-                                   must reject tickets which have this flag
-                                   set.
-
-          8           RENEWABLE
-                                   The  RENEWABLE  flag  is  normally  only
-                                   interpreted  by the TGS, and can usually
-                                   be ignored by end servers (some particu-
-                                   larly careful servers may wish to disal-
-                                   low  renewable  tickets).   A  renewable
-                                   ticket  can be used to obtain a replace-
-                                   ment ticket  that  expires  at  a  later
-                                   date.
-
-          9           INITIAL
-                                   This flag indicates that this ticket was
-                                   issued  using  the  AS protocol, and not
-                                   issued  based   on   a   ticket-granting
-                                   ticket.
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-          10          PRE-AUTHENT
-                                   This flag indicates that during  initial
-                                   authentication, the client was authenti-
-                                   cated by the KDC  before  a  ticket  was
-                                   issued.    The   strength  of  the  pre-
-                                   authentication method is not  indicated,
-                                   but is acceptable to the KDC.
-
-          11          HW-AUTHENT
-                                   This flag indicates  that  the  protocol
-                                   employed   for   initial  authentication
-                                   required the use of hardware expected to
-                                   be possessed solely by the named client.
-                                   The hardware  authentication  method  is
-                                   selected  by the KDC and the strength of
-                                   the method is not indicated.
-
-          12           TRANSITED   This flag indicates that the KDC for the
-                  POLICY-CHECKED   realm has checked the transited field
-                                   against a realm defined policy for
-                                   trusted certifiers.  If this flag is
-                                   reset (0), then the application server
-                                   must check the transited field itself,
-                                   and if unable to do so it must reject
-                                   the authentication.  If the flag is set
-                                   (1) then the application server may skip
-                                   its own validation of the transited
-                                   field, relying on the validation
-                                   performed by the KDC.  At its option the
-                                   application server may still apply its
-                                   own validation based on a separate
-                                   policy for acceptance.
-
-          13      OK-AS-DELEGATE   This flag indicates that the server (not
-                                   the client) specified in the ticket has
-                                   been determined by policy of the realm
-                                   to be a suitable recipient of
-                                   delegation.  A client can use the
-                                   presence of this flag to help it make a
-                                   decision whether to delegate credentials
-                                   (either grant a proxy or a forwarded
-                                   ticket granting ticket) to this server.
-                                   The client is free to ignore the value
-                                   of this flag.  When setting this flag,
-                                   an administrator should consider the
-                                   Security and placement of the server on
-                                   which the service will run, as well as
-                                   whether the service requires the use of
-                                   delegated credentials.
-
-          14          ANONYMOUS
-                                   This flag indicates that  the  principal
-                                   named in the ticket is a generic princi-
-                                   pal for the realm and does not  identify
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-                                   the  individual  using  the ticket.  The
-                                   purpose  of  the  ticket  is   only   to
-                                   securely  distribute  a session key, and
-                                   not to identify  the  user.   Subsequent
-                                   requests  using the same ticket and ses-
-                                   sion may be  considered  as  originating
-                                   from  the  same  user, but requests with
-                                   the same username but a different ticket
-                                   are  likely  to originate from different
-                                   users.
-
-          15-31       RESERVED
-                                   Reserved for future use.
-
-key
-     This field exists in the ticket and the KDC response and is used to
-     pass the session key from Kerberos to the application server and the
-     client. The field's encoding is described in section 6.2.
-crealm
-     This field contains the name of the realm in which the client is
-     registered and in which initial authentication took place.
-cname
-     This field contains the name part of the client's principal identifier.
-transited
-     This field lists the names of the Kerberos realms that took part in
-     authenticating the user to whom this ticket was issued. It does not
-     specify the order in which the realms were transited. See section
-     3.3.3.2 for details on how this field encodes the traversed realms.
-authtime
-     This field indicates the time of initial authentication for the named
-     principal. It is the time of issue for the original ticket on which
-     this ticket is based. It is included in the ticket to provide
-     additional information to the end service, and to provide the necessary
-     information for implementation of a `hot list' service at the KDC. An
-     end service that is particularly paranoid could refuse to accept
-     tickets for which the initial authentication occurred "too far" in the
-     past. This field is also returned as part of the response from the KDC.
-     When returned as part of the response to initial authentication
-     (KRB_AS_REP), this is the current time on the Ker- beros server[24].
-starttime
-     This field in the ticket specifies the time after which the ticket is
-     valid. Together with endtime, this field specifies the life of the
-     ticket. If it is absent from the ticket, its value should be treated as
-     that of the authtime field.
-endtime
-     This field contains the time after which the ticket will not be honored
-     (its expiration time). Note that individual services may place their
-     own limits on the life of a ticket and may reject tickets which have
-     not yet expired. As such, this is really an upper bound on the
-     expiration time for the ticket.
-renew-till
-     This field is only present in tickets that have the RENEWABLE flag set
-     in the flags field. It indicates the maximum endtime that may be
-     included in a renewal. It can be thought of as the absolute expiration
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-     time for the ticket, including all renewals.
-caddr
-     This field in a ticket contains zero (if omitted) or more (if present)
-     host addresses. These are the addresses from which the ticket can be
-     used. If there are no addresses, the ticket can be used from any
-     location. The decision by the KDC to issue or by the end server to
-     accept zero-address tickets is a policy decision and is left to the
-     Kerberos and end-service administrators; they may refuse to issue or
-     accept such tickets. The suggested and default policy, however, is that
-     such tickets will only be issued or accepted when additional
-     information that can be used to restrict the use of the ticket is
-     included in the authorization_data field. Such a ticket is a
-     capability.
-
-     Network addresses are included in the ticket to make it harder for an
-     attacker to use stolen credentials. Because the session key is not sent
-     over the network in cleartext, credentials can't be stolen simply by
-     listening to the network; an attacker has to gain access to the session
-     key (perhaps through operating system security breaches or a careless
-     user's unattended session) to make use of stolen tickets.
-
-     It is important to note that the network address from which a
-     connection is received cannot be reliably determined. Even if it could
-     be, an attacker who has compromised the client's worksta- tion could
-     use the credentials from there. Including the network addresses only
-     makes it more difficult, not impossible, for an attacker to walk off
-     with stolen credentials and then use them from a "safe" location.
-authorization-data
-     The authorization-data field is used to pass authorization data from
-     the principal on whose behalf a ticket was issued to the application
-     service. If no authorization data is included, this field will be left
-     out. Experience has shown that the name of this field is confusing, and
-     that a better name for this field would be restrictions. Unfortunately,
-     it is not possible to change the name of this field at this time.
-
-     This field contains restrictions on any authority obtained on the basis
-     of authentication using the ticket. It is possible for any principal in
-     posession of credentials to add entries to the authorization data field
-     since these entries further restrict what can be done with the ticket.
-     Such additions can be made by specifying the additional entries when a
-     new ticket is obtained during the TGS exchange, or they may be added
-     during chained delegation using the authorization data field of the
-     authenticator.
-
-     Because entries may be added to this field by the holder of
-     credentials, it is not allowable for the presence of an entry in the
-     authorization data field of a ticket to amplify the priveleges one
-     would obtain from using a ticket.
-
-     The data in this field may be specific to the end service; the field
-     will contain the names of service specific objects, and the rights to
-     those objects. The format for this field is described in section 5.2.
-     Although Kerberos is not concerned with the format of the contents of
-     the sub-fields, it does carry type information (ad-type).
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-     By using the authorization_data field, a principal is able to issue a
-     proxy that is valid for a specific purpose. For example, a client
-     wishing to print a file can obtain a file server proxy to be passed to
-     the print server. By specifying the name of the file in the
-     authorization_data field, the file server knows that the print server
-     can only use the client's rights when accessing the particular file to
-     be printed.
-
-     A separate service providing authorization or certifying group
-     membership may be built using the authorization-data field. In this
-     case, the entity granting authorization (not the authorized entity),
-     obtains a ticket in its own name (e.g. the ticket is issued in the name
-     of a privelege server), and this entity adds restrictions on its own
-     authority and delegates the restricted authority through a proxy to the
-     client. The client would then present this authorization credential to
-     the application server separately from the authentication exchange.
-
-     Similarly, if one specifies the authorization-data field of a proxy and
-     leaves the host addresses blank, the resulting ticket and session key
-     can be treated as a capability. See [Neu93] for some suggested uses of
-     this field.
-
-     The authorization-data field is optional and does not have to be
-     included in a ticket.
-
-5.3.2. Authenticators
-
-An authenticator is a record sent with a ticket to a server to certify the
-client's knowledge of the encryption key in the ticket, to help the server
-detect replays, and to help choose a "true session key" to use with the
-particular session. The encoding is encrypted in the ticket's session key
-shared by the client and the server:
-
--- Unencrypted authenticator
-Authenticator ::= [APPLICATION 2] SEQUENCE  {
-                  authenticator-vno[0]          INTEGER,
-                  crealm[1]                     Realm,
-                  cname[2]                      PrincipalName,
-                  cksum[3]                      Checksum OPTIONAL,
-                  cusec[4]                      INTEGER,
-                  ctime[5]                      KerberosTime,
-                  subkey[6]                     EncryptionKey OPTIONAL,
-                  seq-number[7]                 INTEGER OPTIONAL,
-                  authorization-data[8]         AuthorizationData OPTIONAL
-}
-
-
-authenticator-vno
-     This field specifies the version number for the format of the
-     authenticator. This document specifies version 5.
-crealm and cname
-     These fields are the same as those described for the ticket in section
-     5.3.1.
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-cksum
-     This field contains a checksum of the the applica- tion data that
-     accompanies the KRB_AP_REQ.
-cusec
-     This field contains the microsecond part of the client's timestamp. Its
-     value (before encryption) ranges from 0 to 999999. It often appears
-     along with ctime. The two fields are used together to specify a
-     reasonably accurate timestamp.
-ctime
-     This field contains the current time on the client's host.
-subkey
-     This field contains the client's choice for an encryption key which is
-     to be used to protect this specific application session. Unless an
-     application specifies otherwise, if this field is left out the session
-     key from the ticket will be used.
-seq-number
-     This optional field includes the initial sequence number to be used by
-     the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to
-     detect replays (It may also be used by application specific messages).
-     When included in the authenticator this field specifies the initial
-     sequence number for messages from the client to the server. When
-     included in the AP-REP message, the initial sequence number is that for
-     messages from the server to the client. When used in KRB_PRIV or
-     KRB_SAFE messages, it is incremented by one after each message is sent.
-
-     For sequence numbers to adequately support the detection of replays
-     they should be non-repeating, even across connection boundaries. The
-     initial sequence number should be random and uniformly distributed
-     across the full space of possible sequence numbers, so that it cannot
-     be guessed by an attacker and so that it and the successive sequence
-     numbers do not repeat other sequences.
-authorization-data
-     This field is the same as described for the ticket in section 5.3.1. It
-     is optional and will only appear when additional restrictions are to be
-     placed on the use of a ticket, beyond those carried in the ticket
-     itself.
-
-5.4. Specifications for the AS and TGS exchanges
-
-This section specifies the format of the messages used in the exchange
-between the client and the Kerberos server. The format of possible error
-messages appears in section 5.9.1.
-
-5.4.1. KRB_KDC_REQ definition
-
-The KRB_KDC_REQ message has no type of its own. Instead, its type is one of
-KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial
-ticket or an additional ticket. In either case, the message is sent from the
-client to the Authentication Server to request credentials for a service.
-
-The message fields are:
-
-AS-REQ ::=         [APPLICATION 10] KDC-REQ
-TGS-REQ ::=        [APPLICATION 12] KDC-REQ
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-KDC-REQ ::=        SEQUENCE {
-                   pvno[1]            INTEGER,
-                   msg-type[2]        INTEGER,
-                   padata[3]          SEQUENCE OF PA-DATA OPTIONAL,
-                   req-body[4]        KDC-REQ-BODY
-}
-
-PA-DATA ::=        SEQUENCE {
-                   padata-type[1]     INTEGER,
-                   padata-value[2]    OCTET STRING,
-                                      -- might be encoded AP-REQ
-}
-
-KDC-REQ-BODY ::=   SEQUENCE {
-                    kdc-options[0]         KDCOptions,
-                    cname[1]               PrincipalName OPTIONAL,
-                                           -- Used only in AS-REQ
-                    realm[2]               Realm, -- Server's realm
-                                           -- Also client's in AS-REQ
-                    sname[3]               PrincipalName OPTIONAL,
-                    from[4]                KerberosTime OPTIONAL,
-                    till[5]                KerberosTime OPTIONAL,
-                    rtime[6]               KerberosTime OPTIONAL,
-                    nonce[7]               INTEGER,
-                    etype[8]               SEQUENCE OF INTEGER,
-                                           -- EncryptionType,
-                                           -- in preference order
-                    addresses[9]           HostAddresses OPTIONAL,
-                enc-authorization-data[10] EncryptedData OPTIONAL,
-                                           -- Encrypted AuthorizationData
-                                           -- encoding
-                    additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
-}
-
-The fields in this message are:
-
-pvno
-     This field is included in each message, and specifies the protocol
-     version number. This document specifies protocol version 5.
-msg-type
-     This field indicates the type of a protocol message. It will almost
-     always be the same as the application identifier associated with a
-     message. It is included to make the identifier more readily accessible
-     to the application. For the KDC-REQ message, this type will be
-     KRB_AS_REQ or KRB_TGS_REQ.
-padata
-     The padata (pre-authentication data) field contains a sequence of
-     authentication information which may be needed before credentials can
-     be issued or decrypted. In the case of requests for additional tickets
-     (KRB_TGS_REQ), this field will include an element with padata-type of
-     PA-TGS-REQ and data of an authentication header (ticket-granting ticket
-     and authenticator). The checksum in the authenticator (which must be
-     collision-proof) is to be computed over the KDC-REQ-BODY encoding. In
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-     most requests for initial authentication (KRB_AS_REQ) and most replies
-     (KDC-REP), the padata field will be left out.
-
-     This field may also contain information needed by certain extensions to
-     the Kerberos protocol. For example, it might be used to initially
-     verify the identity of a client before any response is returned. This
-     is accomplished with a padata field with padata-type equal to
-     PA-ENC-TIMESTAMP and padata-value defined as follows:
-
-     padata-type     ::= PA-ENC-TIMESTAMP
-     padata-value    ::= EncryptedData -- PA-ENC-TS-ENC
-
-     PA-ENC-TS-ENC   ::= SEQUENCE {
-                     patimestamp[0]     KerberosTime, -- client's time
-                     pausec[1]          INTEGER OPTIONAL
-     }
-
-     with patimestamp containing the client's time and pausec containing the
-     microseconds which may be omitted if a client will not generate more
-     than one request per second. The ciphertext (padata-value) consists of
-     the PA-ENC-TS-ENC sequence, encrypted using the client's secret key.
-
-     [use-specified-kvno item is here for discussion and may be removed] It
-     may also be used by the client to specify the version of a key that is
-     being used for accompanying preauthentication, and/or which should be
-     used to encrypt the reply from the KDC.
-
-     PA-USE-SPECIFIED-KVNO  ::=  Integer
-
-     The KDC should only accept and abide by the value of the
-     use-specified-kvno preauthentication data field when the specified key
-     is still valid and until use of a new key is confirmed. This situation
-     is likely to occur primarily during the period during which an updated
-     key is propagating to other KDC's in a realm.
-
-     The padata field can also contain information needed to help the KDC or
-     the client select the key needed for generating or decrypting the
-     response. This form of the padata is useful for supporting the use of
-     certain token cards with Kerberos. The details of such extensions are
-     specified in separate documents. See [Pat92] for additional uses of
-     this field.
-padata-type
-     The padata-type element of the padata field indicates the way that the
-     padata-value element is to be interpreted. Negative values of
-     padata-type are reserved for unregistered use; non-negative values are
-     used for a registered interpretation of the element type.
-req-body
-     This field is a placeholder delimiting the extent of the remaining
-     fields. If a checksum is to be calculated over the request, it is
-     calculated over an encoding of the KDC-REQ-BODY sequence which is
-     enclosed within the req-body field.
-kdc-options
-     This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the
-     KDC and indicates the flags that the client wants set on the tickets as
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-     well as other information that is to modify the behavior of the KDC.
-     Where appropriate, the name of an option may be the same as the flag
-     that is set by that option. Although in most case, the bit in the
-     options field will be the same as that in the flags field, this is not
-     guaranteed, so it is not acceptable to simply copy the options field to
-     the flags field. There are various checks that must be made before
-     honoring an option anyway.
-
-     The kdc_options field is a bit-field, where the selected options are
-     indicated by the bit being set (1), and the unselected options and
-     reserved fields being reset (0). The encoding of the bits is specified
-     in section 5.2. The options are described in more detail above in
-     section 2. The meanings of the options are:
-
-        Bit(s)    Name                Description
-         0        RESERVED
-                                      Reserved for future  expansion  of  this
-                                      field.
-
-         1        FORWARDABLE
-                                      The FORWARDABLE  option  indicates  that
-                                      the  ticket  to be issued is to have its
-                                      forwardable flag set.  It  may  only  be
-                                      set on the initial request, or in a sub-
-                                      sequent request if  the  ticket-granting
-                                      ticket on which it is based is also for-
-                                      wardable.
-
-         2        FORWARDED
-                                      The FORWARDED option is  only  specified
-                                      in  a  request  to  the  ticket-granting
-                                      server and will only be honored  if  the
-                                      ticket-granting  ticket  in  the request
-                                      has  its  FORWARDABLE  bit  set.    This
-                                      option  indicates that this is a request
-                                      for forwarding.  The address(es) of  the
-                                      host  from which the resulting ticket is
-                                      to  be  valid  are   included   in   the
-                                      addresses field of the request.
-
-         3        PROXIABLE
-                                      The PROXIABLE option indicates that  the
-                                      ticket to be issued is to have its prox-
-                                      iable flag set.  It may only be  set  on
-                                      the  initial request, or in a subsequent
-                                      request if the ticket-granting ticket on
-                                      which it is based is also proxiable.
-
-         4        PROXY
-                                      The PROXY option indicates that this  is
-                                      a request for a proxy.  This option will
-                                      only be honored if  the  ticket-granting
-                                      ticket  in the request has its PROXIABLE
-                                      bit set.  The address(es)  of  the  host
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-                                      from which the resulting ticket is to be
-                                       valid  are  included  in  the  addresses
-                                      field of the request.
-
-         5        ALLOW-POSTDATE
-                                      The ALLOW-POSTDATE option indicates that
-                                      the  ticket  to be issued is to have its
-                                      MAY-POSTDATE flag set.  It may  only  be
-                                      set on the initial request, or in a sub-
-                                      sequent request if  the  ticket-granting
-                                      ticket on which it is based also has its
-                                      MAY-POSTDATE flag set.
-
-         6        POSTDATED
-                                      The POSTDATED option indicates that this
-                                      is  a  request  for  a postdated ticket.
-                                      This option will only be honored if  the
-                                      ticket-granting  ticket  on  which it is
-                                      based has  its  MAY-POSTDATE  flag  set.
-                                      The  resulting ticket will also have its
-                                      INVALID flag set, and that flag  may  be
-                                      reset by a subsequent request to the KDC
-                                      after the starttime in  the  ticket  has
-                                      been reached.
-
-         7        UNUSED
-                                      This option is presently unused.
-
-         8        RENEWABLE
-                                      The RENEWABLE option indicates that  the
-                                      ticket  to  be  issued  is  to  have its
-                                      RENEWABLE flag set.  It may only be  set
-                                      on  the  initial  request,  or  when the
-                                      ticket-granting  ticket  on  which   the
-                                      request  is based is also renewable.  If
-                                      this option is requested, then the rtime
-                                      field   in   the  request  contains  the
-                                      desired absolute expiration time for the
-                                      ticket.
-
-         9-13     UNUSED
-                                      These options are presently unused.
-
-         14       REQUEST-ANONYMOUS
-                                      The REQUEST-ANONYMOUS  option  indicates
-                                      that  the  ticket to be issued is not to
-                                      identify  the  user  to  which  it   was
-                                      issued.  Instead, the principal identif-
-                                      ier is to be generic,  as  specified  by
-                                      the  policy  of  the realm (e.g. usually
-                                      anonymous@realm).  The  purpose  of  the
-                                      ticket  is only to securely distribute a
-                                      session key, and  not  to  identify  the
-                                      user.   The ANONYMOUS flag on the ticket
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-                                      to be returned should be  set.   If  the
-                                      local  realms  policy  does  not  permit
-                                      anonymous credentials, the request is to
-                                      be rejected.
-
-         15-25    RESERVED
-                                      Reserved for future use.
-
-         26       DISABLE-TRANSITED-CHECK
-                                      By default the KDC will check the
-                                      transited field of a ticket-granting-
-                                      ticket against the policy of the local
-                                      realm before it will issue derivative
-                                      tickets based on the ticket granting
-                                      ticket.  If this flag is set in the
-                                      request, checking of the transited field
-                                      is disabled.  Tickets issued without the
-                                      performance of this check will be noted
-                                      by the reset (0) value of the
-                                      TRANSITED-POLICY-CHECKED flag,
-                                      indicating to the application server
-                                      that the tranisted field must be checked
-                                      locally.  KDC's are encouraged but not
-                                      required to honor the
-                                      DISABLE-TRANSITED-CHECK option.
-
-         27       RENEWABLE-OK
-                                      The RENEWABLE-OK option indicates that a
-                                      renewable ticket will be acceptable if a
-                                      ticket with the  requested  life  cannot
-                                      otherwise be provided.  If a ticket with
-                                      the requested life cannot  be  provided,
-                                      then  a  renewable  ticket may be issued
-                                      with  a  renew-till  equal  to  the  the
-                                      requested  endtime.   The  value  of the
-                                      renew-till field may still be limited by
-                                      local  limits, or limits selected by the
-                                      individual principal or server.
-
-         28       ENC-TKT-IN-SKEY
-                                      This option is used only by the  ticket-
-                                      granting  service.   The ENC-TKT-IN-SKEY
-                                      option indicates that the ticket for the
-                                      end  server  is  to  be encrypted in the
-                                      session key from the additional  ticket-
-                                      granting ticket provided.
-
-         29       RESERVED
-                                      Reserved for future use.
-
-         30       RENEW
-                                      This option is used only by the  ticket-
-                                      granting   service.   The  RENEW  option
-                                      indicates that the  present  request  is
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-                                      for  a  renewal.  The ticket provided is
-                                      encrypted in  the  secret  key  for  the
-                                      server  on  which  it  is  valid.   This
-                                      option  will  only  be  honored  if  the
-                                      ticket  to  be renewed has its RENEWABLE
-                                      flag set and if the time in  its  renew-
-                                      till  field  has not passed.  The ticket
-                                      to be renewed is passed  in  the  padata
-                                      field  as  part  of  the  authentication
-                                      header.
-
-         31       VALIDATE
-                                      This option is used only by the  ticket-
-                                      granting  service.   The VALIDATE option
-                                      indicates that the request is  to  vali-
-                                      date  a  postdated ticket.  It will only
-                                      be honored if the  ticket  presented  is
-                                      postdated,  presently  has  its  INVALID
-                                      flag set, and would be otherwise  usable
-                                      at  this time.  A ticket cannot be vali-
-                                      dated before its starttime.  The  ticket
-                                      presented for validation is encrypted in
-                                      the key of the server for  which  it  is
-                                      valid  and is passed in the padata field
-                                      as part of the authentication header.
-
-cname and sname
-     These fields are the same as those described for the ticket in section
-     5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is
-     specified. If absent, the name of the server is taken from the name of
-     the client in the ticket passed as additional-tickets.
-enc-authorization-data
-     The enc-authorization-data, if present (and it can only be present in
-     the TGS_REQ form), is an encoding of the desired authorization-data
-     encrypted under the sub-session key if present in the Authenticator, or
-     alternatively from the session key in the ticket-granting ticket, both
-     from the padata field in the KRB_AP_REQ.
-realm
-     This field specifies the realm part of the server's principal
-     identifier. In the AS exchange, this is also the realm part of the
-     client's principal identifier.
-from
-     This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
-     requests when the requested ticket is to be postdated. It specifies the
-     desired start time for the requested ticket. If this field is omitted
-     then the KDC should use the current time instead.
-till
-     This field contains the expiration date requested by the client in a
-     ticket request. It is optional and if omitted the requested ticket is
-     to have the maximum endtime permitted according to KDC policy for the
-     parties to the authentication exchange as limited by expiration date of
-     the ticket granting ticket or other preauthentication credentials.
-rtime
-     This field is the requested renew-till time sent from a client to the
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-     KDC in a ticket request. It is optional.
-nonce
-     This field is part of the KDC request and response. It it intended to
-     hold a random number generated by the client. If the same number is
-     included in the encrypted response from the KDC, it provides evidence
-     that the response is fresh and has not been replayed by an attacker.
-     Nonces must never be re-used. Ideally, it should be generated randomly,
-     but if the correct time is known, it may suffice[25].
-etype
-     This field specifies the desired encryption algorithm to be used in the
-     response.
-addresses
-     This field is included in the initial request for tickets, and
-     optionally included in requests for additional tickets from the
-     ticket-granting server. It specifies the addresses from which the
-     requested ticket is to be valid. Normally it includes the addresses for
-     the client's host. If a proxy is requested, this field will contain
-     other addresses. The contents of this field are usually copied by the
-     KDC into the caddr field of the resulting ticket.
-additional-tickets
-     Additional tickets may be optionally included in a request to the
-     ticket-granting server. If the ENC-TKT-IN-SKEY option has been
-     specified, then the session key from the additional ticket will be used
-     in place of the server's key to encrypt the new ticket. If more than
-     one option which requires additional tickets has been specified, then
-     the additional tickets are used in the order specified by the ordering
-     of the options bits (see kdc-options, above).
-
-The application code will be either ten (10) or twelve (12) depending on
-whether the request is for an initial ticket (AS-REQ) or for an additional
-ticket (TGS-REQ).
-
-The optional fields (addresses, authorization-data and additional-tickets)
-are only included if necessary to perform the operation specified in the
-kdc-options field.
-
-It should be noted that in KRB_TGS_REQ, the protocol version number appears
-twice and two different message types appear: the KRB_TGS_REQ message
-contains these fields as does the authentication header (KRB_AP_REQ) that is
-passed in the padata field.
-
-5.4.2. KRB_KDC_REP definition
-
-The KRB_KDC_REP message format is used for the reply from the KDC for either
-an initial (AS) request or a subsequent (TGS) request. There is no message
-type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or
-KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply
-depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in
-the client's secret key, and the client's key version number is included in
-the key version number for the encrypted data. For KRB_TGS_REP, the
-ciphertext is encrypted in the sub-session key from the Authenticator, or if
-absent, the session key from the ticket-granting ticket used in the request.
-In that case, no version number will be present in the EncryptedData
-sequence.
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-The KRB_KDC_REP message contains the following fields:
-
-AS-REP ::=    [APPLICATION 11] KDC-REP
-TGS-REP ::=   [APPLICATION 13] KDC-REP
-
-KDC-REP ::=   SEQUENCE {
-              pvno[0]                    INTEGER,
-              msg-type[1]                INTEGER,
-              padata[2]                  SEQUENCE OF PA-DATA OPTIONAL,
-              crealm[3]                  Realm,
-              cname[4]                   PrincipalName,
-              ticket[5]                  Ticket,
-              enc-part[6]                EncryptedData
-}
-
-EncASRepPart ::=    [APPLICATION 25[27]] EncKDCRepPart
-EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart
-
-EncKDCRepPart ::=   SEQUENCE {
-                    key[0]               EncryptionKey,
-                    last-req[1]          LastReq,
-                    nonce[2]             INTEGER,
-                    key-expiration[3]    KerberosTime OPTIONAL,
-                    flags[4]             TicketFlags,
-                    authtime[5]          KerberosTime,
-                    starttime[6]         KerberosTime OPTIONAL,
-                    endtime[7]           KerberosTime,
-                    renew-till[8]        KerberosTime OPTIONAL,
-                    srealm[9]            Realm,
-                    sname[10]            PrincipalName,
-                    caddr[11]            HostAddresses OPTIONAL
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is either
-     KRB_AS_REP or KRB_TGS_REP.
-padata
-     This field is described in detail in section 5.4.1. One possible use
-     for this field is to encode an alternate "mix-in" string to be used
-     with a string-to-key algorithm (such as is described in section 6.3.2).
-     This ability is useful to ease transitions if a realm name needs to
-     change (e.g. when a company is acquired); in such a case all existing
-     password-derived entries in the KDC database would be flagged as
-     needing a special mix-in string until the next password change.
-crealm, cname, srealm and sname
-     These fields are the same as those described for the ticket in section
-     5.3.1.
-ticket
-     The newly-issued ticket, from section 5.3.1.
-enc-part
-     This field is a place holder for the ciphertext and related information
-     that forms the encrypted part of a message. The description of the
-     encrypted part of the message follows each appearance of this field.
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-     The encrypted part is encoded as described in section 6.1.
-key
-     This field is the same as described for the ticket in section 5.3.1.
-last-req
-     This field is returned by the KDC and specifies the time(s) of the last
-     request by a principal. Depending on what information is available,
-     this might be the last time that a request for a ticket-granting ticket
-     was made, or the last time that a request based on a ticket-granting
-     ticket was successful. It also might cover all servers for a realm, or
-     just the particular server. Some implementations may display this
-     information to the user to aid in discovering unauthorized use of one's
-     identity. It is similar in spirit to the last login time displayed when
-     logging into timesharing systems.
-nonce
-     This field is described above in section 5.4.1.
-key-expiration
-     The key-expiration field is part of the response from the KDC and
-     specifies the time that the client's secret key is due to expire. The
-     expiration might be the result of password aging or an account
-     expiration. This field will usually be left out of the TGS reply since
-     the response to the TGS request is encrypted in a session key and no
-     client information need be retrieved from the KDC database. It is up to
-     the application client (usually the login program) to take appropriate
-     action (such as notifying the user) if the expiration time is imminent.
-flags, authtime, starttime, endtime, renew-till and caddr
-     These fields are duplicates of those found in the encrypted portion of
-     the attached ticket (see section 5.3.1), provided so the client may
-     verify they match the intended request and to assist in proper ticket
-     caching. If the message is of type KRB_TGS_REP, the caddr field will
-     only be filled in if the request was for a proxy or forwarded ticket,
-     or if the user is substituting a subset of the addresses from the
-     ticket granting ticket. If the client-requested addresses are not
-     present or not used, then the addresses contained in the ticket will be
-     the same as those included in the ticket-granting ticket.
-
-5.5. Client/Server (CS) message specifications
-
-This section specifies the format of the messages used for the
-authentication of the client to the application server.
-
-5.5.1. KRB_AP_REQ definition
-
-The KRB_AP_REQ message contains the Kerberos protocol version number, the
-message type KRB_AP_REQ, an options field to indicate any options in use,
-and the ticket and authenticator themselves. The KRB_AP_REQ message is often
-referred to as the 'authentication header'.
-
-AP-REQ ::=      [APPLICATION 14] SEQUENCE {
-                pvno[0]                       INTEGER,
-                msg-type[1]                   INTEGER,
-                ap-options[2]                 APOptions,
-                ticket[3]                     Ticket,
-                authenticator[4]              EncryptedData
-}
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-APOptions ::=   BIT STRING {
-                reserved(0),
-                use-session-key(1),
-                mutual-required(2)
-}
-
-
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_AP_REQ.
-ap-options
-     This field appears in the application request (KRB_AP_REQ) and affects
-     the way the request is processed. It is a bit-field, where the selected
-     options are indicated by the bit being set (1), and the unselected
-     options and reserved fields being reset (0). The encoding of the bits
-     is specified in section 5.2. The meanings of the options are:
-
-          Bit(s)   Name              Description
-          0        RESERVED
-                                     Reserved for future  expansion  of  this
-                                     field.
-
-          1        USE-SESSION-KEY
-                                     The  USE-SESSION-KEY  option   indicates
-                                     that the ticket the client is presenting
-                                     to a server is encrypted in the  session
-                                     key  from  the  server's ticket-granting
-                                     ticket.  When this option is not  speci-
-                                     fied,  the  ticket  is  encrypted in the
-                                     server's secret key.
-
-          2        MUTUAL-REQUIRED
-                                     The  MUTUAL-REQUIRED  option  tells  the
-                                     server  that  the client requires mutual
-                                     authentication, and that it must respond
-                                     with a KRB_AP_REP message.
-
-          3-31     RESERVED
-                                          Reserved for future use.
-ticket
-     This field is a ticket authenticating the client to the server.
-authenticator
-     This contains the authenticator, which includes the client's choice of
-     a subkey. Its encoding is described in section 5.3.2.
-
-5.5.2. KRB_AP_REP definition
-
-The KRB_AP_REP message contains the Kerberos protocol version number, the
-message type, and an encrypted time- stamp. The message is sent in in
-response to an application request (KRB_AP_REQ) where the mutual
-authentication option has been selected in the ap-options field.
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-AP-REP ::=         [APPLICATION 15] SEQUENCE {
-                   pvno[0]                           INTEGER,
-                   msg-type[1]                       INTEGER,
-                   enc-part[2]                       EncryptedData
-}
-
-EncAPRepPart ::=   [APPLICATION 27[29]] SEQUENCE {
-                   ctime[0]                          KerberosTime,
-                   cusec[1]                          INTEGER,
-                   subkey[2]                         EncryptionKey OPTIONAL,
-                   seq-number[3]                     INTEGER OPTIONAL
-}
-
-The encoded EncAPRepPart is encrypted in the shared session key of the
-ticket. The optional subkey field can be used in an application-arranged
-negotiation to choose a per association session key.
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_AP_REP.
-enc-part
-     This field is described above in section 5.4.2.
-ctime
-     This field contains the current time on the client's host.
-cusec
-     This field contains the microsecond part of the client's timestamp.
-subkey
-     This field contains an encryption key which is to be used to protect
-     this specific application session. See section 3.2.6 for specifics on
-     how this field is used to negotiate a key. Unless an application
-     specifies otherwise, if this field is left out, the sub-session key
-     from the authenticator, or if also left out, the session key from the
-     ticket will be used.
-
-5.5.3. Error message reply
-
-If an error occurs while processing the application request, the KRB_ERROR
-message will be sent in response. See section 5.9.1 for the format of the
-error message. The cname and crealm fields may be left out if the server
-cannot determine their appropriate values from the corresponding KRB_AP_REQ
-message. If the authenticator was decipherable, the ctime and cusec fields
-will contain the values from it.
-
-5.6. KRB_SAFE message specification
-
-This section specifies the format of a message that can be used by either
-side (client or server) of an application to send a tamper-proof message to
-its peer. It presumes that a session key has previously been exchanged (for
-example, by using the KRB_AP_REQ/KRB_AP_REP messages).
-
-5.6.1. KRB_SAFE definition
-
-The KRB_SAFE message contains user data along with a collision-proof
-checksum keyed with the last encryption key negotiated via subkeys, or the
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-session key if no negotiation has occured. The message fields are:
-
-KRB-SAFE ::=        [APPLICATION 20] SEQUENCE {
-                    pvno[0]                       INTEGER,
-                    msg-type[1]                   INTEGER,
-                    safe-body[2]                  KRB-SAFE-BODY,
-                    cksum[3]                      Checksum
-}
-
-KRB-SAFE-BODY ::=   SEQUENCE {
-                    user-data[0]                  OCTET STRING,
-                    timestamp[1]                  KerberosTime OPTIONAL,
-                    usec[2]                       INTEGER OPTIONAL,
-                    seq-number[3]                 INTEGER OPTIONAL,
-                    s-address[4]                  HostAddress OPTIONAL,
-                    r-address[5]                  HostAddress OPTIONAL
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_SAFE.
-safe-body
-     This field is a placeholder for the body of the KRB-SAFE message. It is
-     to be encoded separately and then have the checksum computed over it,
-     for use in the cksum field.
-cksum
-     This field contains the checksum of the application data. Checksum
-     details are described in section 6.4. The checksum is computed over the
-     encoding of the KRB-SAFE-BODY sequence.
-user-data
-     This field is part of the KRB_SAFE and KRB_PRIV messages and contain
-     the application specific data that is being passed from the sender to
-     the recipient.
-timestamp
-     This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents
-     are the current time as known by the sender of the message. By checking
-     the timestamp, the recipient of the message is able to make sure that
-     it was recently generated, and is not a replay.
-usec
-     This field is part of the KRB_SAFE and KRB_PRIV headers. It contains
-     the microsecond part of the timestamp.
-seq-number
-     This field is described above in section 5.3.2.
-s-address
-     This field specifies the address in use by the sender of the message.
-r-address
-     This field specifies the address in use by the recipient of the
-     message. It may be omitted for some uses (such as broadcast protocols),
-     but the recipient may arbitrarily reject such messages. This field
-     along with s-address can be used to help detect messages which have
-     been incorrectly or maliciously delivered to the wrong recipient.
-
-5.7. KRB_PRIV message specification
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-This section specifies the format of a message that can be used by either
-side (client or server) of an application to securely and privately send a
-message to its peer. It presumes that a session key has previously been
-exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
-
-5.7.1. KRB_PRIV definition
-
-The KRB_PRIV message contains user data encrypted in the Session Key. The
-message fields are:
-
-KRB-PRIV ::=         [APPLICATION 21] SEQUENCE {
-                     pvno[0]                           INTEGER,
-                     msg-type[1]                       INTEGER,
-                     enc-part[3]                       EncryptedData
-}
-
-EncKrbPrivPart ::=   [APPLICATION 28[31]] SEQUENCE {
-                     user-data[0]        OCTET STRING,
-                     timestamp[1]        KerberosTime OPTIONAL,
-                     usec[2]             INTEGER OPTIONAL,
-                     seq-number[3]       INTEGER OPTIONAL,
-                     s-address[4]        HostAddress OPTIONAL, -- sender's addr
-                     r-address[5]        HostAddress OPTIONAL -- recip's addr
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_PRIV.
-enc-part
-     This field holds an encoding of the EncKrbPrivPart sequence encrypted
-     under the session key[32]. This encrypted encoding is used for the
-     enc-part field of the KRB-PRIV message. See section 6 for the format of
-     the ciphertext.
-user-data, timestamp, usec, s-address and r-address
-     These fields are described above in section 5.6.1.
-seq-number
-     This field is described above in section 5.3.2.
-
-5.8. KRB_CRED message specification
-
-This section specifies the format of a message that can be used to send
-Kerberos credentials from one principal to another. It is presented here to
-encourage a common mechanism to be used by applications when forwarding
-tickets or providing proxies to subordinate servers. It presumes that a
-session key has already been exchanged perhaps by using the
-KRB_AP_REQ/KRB_AP_REP messages.
-
-5.8.1. KRB_CRED definition
-
-The KRB_CRED message contains a sequence of tickets to be sent and
-information needed to use the tickets, including the session key from each.
-The information needed to use the tickets is encrypted under an encryption
-key previously exchanged or transferred alongside the KRB_CRED message. The
-message fields are:
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-KRB-CRED         ::= [APPLICATION 22]   SEQUENCE {
-                 pvno[0]                INTEGER,
-                 msg-type[1]            INTEGER, -- KRB_CRED
-                 tickets[2]             SEQUENCE OF Ticket,
-                 enc-part[3]            EncryptedData
-}
-
-EncKrbCredPart   ::= [APPLICATION 29]   SEQUENCE {
-                 ticket-info[0]         SEQUENCE OF KrbCredInfo,
-                 nonce[1]               INTEGER OPTIONAL,
-                 timestamp[2]           KerberosTime OPTIONAL,
-                 usec[3]                INTEGER OPTIONAL,
-                 s-address[4]           HostAddress OPTIONAL,
-                 r-address[5]           HostAddress OPTIONAL
-}
-
-KrbCredInfo      ::=                    SEQUENCE {
-                 key[0]                 EncryptionKey,
-                 prealm[1]              Realm OPTIONAL,
-                 pname[2]               PrincipalName OPTIONAL,
-                 flags[3]               TicketFlags OPTIONAL,
-                 authtime[4]            KerberosTime OPTIONAL,
-                 starttime[5]           KerberosTime OPTIONAL,
-                 endtime[6]             KerberosTime OPTIONAL
-                 renew-till[7]          KerberosTime OPTIONAL,
-                 srealm[8]              Realm OPTIONAL,
-                 sname[9]               PrincipalName OPTIONAL,
-                 caddr[10]              HostAddresses OPTIONAL
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_CRED.
-tickets
-     These are the tickets obtained from the KDC specifically for use by the
-     intended recipient. Successive tickets are paired with the
-     corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED
-     message.
-enc-part
-     This field holds an encoding of the EncKrbCredPart sequence encrypted
-     under the session key shared between the sender and the intended
-     recipient. This encrypted encoding is used for the enc-part field of
-     the KRB-CRED message. See section 6 for the format of the ciphertext.
-nonce
-     If practical, an application may require the inclusion of a nonce
-     generated by the recipient of the message. If the same value is
-     included as the nonce in the message, it provides evidence that the
-     message is fresh and has not been replayed by an attacker. A nonce must
-     never be re-used; it should be generated randomly by the recipient of
-     the message and provided to the sender of the message in an application
-     specific manner.
-timestamp and usec
-     These fields specify the time that the KRB-CRED message was generated.
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-     The time is used to provide assurance that the message is fresh.
-s-address and r-address
-     These fields are described above in section 5.6.1. They are used
-     optionally to provide additional assurance of the integrity of the
-     KRB-CRED message.
-key
-     This field exists in the corresponding ticket passed by the KRB-CRED
-     message and is used to pass the session key from the sender to the
-     intended recipient. The field's encoding is described in section 6.2.
-
-The following fields are optional. If present, they can be associated with
-the credentials in the remote ticket file. If left out, then it is assumed
-that the recipient of the credentials already knows their value.
-
-prealm and pname
-     The name and realm of the delegated principal identity.
-flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr
-     These fields contain the values of the correspond- ing fields from the
-     ticket found in the ticket field. Descriptions of the fields are
-     identical to the descriptions in the KDC-REP message.
-
-5.9. Error message specification
-
-This section specifies the format for the KRB_ERROR message. The fields
-included in the message are intended to return as much information as
-possible about an error. It is not expected that all the information
-required by the fields will be available for all types of errors. If the
-appropriate information is not available when the message is composed, the
-corresponding field will be left out of the message.
-
-Note that since the KRB_ERROR message is not protected by any encryption, it
-is quite possible for an intruder to synthesize or modify such a message. In
-particular, this means that the client should not use any fields in this
-message for security-critical purposes, such as setting a system clock or
-generating a fresh authenticator. The message can be useful, however, for
-advising a user on the reason for some failure.
-
-5.9.1. KRB_ERROR definition
-
-The KRB_ERROR message consists of the following fields:
-
-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,
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-                e-data[12]                    OCTET STRING OPTIONAL,
-                e-cksum[13]                   Checksum OPTIONAL,
-                e-typed-data[14]              SEQUENCE of ETypedData OPTIONAL
-}
-
-ETypedData ::=  SEQUENCE {
-                e-data-type    [1] INTEGER,
-                e-data-value   [2] OCTET STRING,
-}
-
-
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_ERROR.
-ctime
-     This field is described above in section 5.4.1.
-cusec
-     This field is described above in section 5.5.2.
-stime
-     This field contains the current time on the server. It is of type
-     KerberosTime.
-susec
-     This field contains the microsecond part of the server's timestamp. Its
-     value ranges from 0 to 999999. It appears along with stime. The two
-     fields are used in conjunction to specify a reasonably accurate
-     timestamp.
-error-code
-     This field contains the error code returned by Kerberos or the server
-     when a request fails. To interpret the value of this field see the list
-     of error codes in section 8. Implementations are encouraged to provide
-     for national language support in the display of error messages.
-crealm, cname, srealm and sname
-     These fields are described above in section 5.3.1.
-e-text
-     This field contains additional text to help explain the error code
-     associated with the failed request (for example, it might include a
-     principal name which was unknown).
-e-data
-     This field contains additional data about the error for use by the
-     application to help it recover from or handle the error. If the
-     errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
-     contain an encoding of a sequence of padata fields, each corresponding
-     to an acceptable pre-authentication method and optionally containing
-     data for the method:
-
-     METHOD-DATA ::=   SEQUENCE of PA-DATA
-
-     If the error-code is KRB_AP_ERR_METHOD, then the e-data field will
-     contain an encoding of the following sequence:
-
-     METHOD-DATA ::=   SEQUENCE {
-                         method-type[0]   INTEGER,
-                         method-data[1]   OCTET STRING OPTIONAL
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-     }
-
-     method-type will indicate the required alternate method; method-data
-     will contain any required additional information.
-e-cksum
-     This field contains an optional checksum for the KRB-ERROR message. The
-     checksum is calculated over the Kerberos ASN.1 encoding of the
-     KRB-ERROR message with the checksum absent. The checksum is then added
-     to the KRB-ERROR structure and the message is re-encoded. The Checksum
-     should be calculated using the session key from the ticket granting
-     ticket or service ticket, where available. If the error is in response
-     to a TGS or AP request, the checksum should be calculated uing the the
-     session key from the client's ticket. If the error is in response to an
-     AS request, then the checksum should be calulated using the client's
-     secret key ONLY if there has been suitable preauthentication to prove
-     knowledge of the secret key by the client[33]. If a checksum can not be
-     computed because the key to be used is not available, no checksum will
-     be included.
-e-typed-data
-     [This field for discussion, may be deleted from final spec] This field
-     contains optional data that may be used to help the client recover from
-     the indicated error. [This could contain the METHOD-DATA specified
-     since I don't think anyone actually uses it yet. It could also contain
-     the PA-DATA sequence for the preauth required error if we had a clear
-     way to transition to the use of this field from the use of the untype
-     e-data field.] For example, this field may specify the key version of
-     the key used to verify preauthentication:
-
-     e-data-type  := 20 -- Key version number
-     e-data-value := Integer -- Key version number used to verify
-                                preauthentication 
-
-6. Encryption and Checksum Specifications
-
-The Kerberos protocols described in this document are designed to use stream
-encryption ciphers, which can be simulated using commonly available block
-encryption ciphers, such as the Data Encryption Standard, [DES77] in
-conjunction with block chaining and checksum methods [DESM80]. Encryption is
-used to prove the identities of the network entities participating in
-message exchanges. The Key Distribution Center for each realm is trusted by
-all principals registered in that realm to store a secret key in confidence.
-Proof of knowledge of this secret key is used to verify the authenticity of
-a principal.
-
-The KDC uses the principal's secret key (in the AS exchange) or a shared
-session key (in the TGS exchange) to encrypt responses to ticket requests;
-the ability to obtain the secret key or session key implies the knowledge of
-the appropriate keys and the identity of the KDC. The ability of a principal
-to decrypt the KDC response and present a Ticket and a properly formed
-Authenticator (generated with the session key from the KDC response) to a
-service verifies the identity of the principal; likewise the ability of the
-service to extract the session key from the Ticket and prove its knowledge
-thereof in a response verifies the identity of the service.
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-The Kerberos protocols generally assume that the encryption used is secure
-from cryptanalysis; however, in some cases, the order of fields in the
-encrypted portions of messages are arranged to minimize the effects of
-poorly chosen keys. It is still important to choose good keys. If keys are
-derived from user-typed passwords, those passwords need to be well chosen to
-make brute force attacks more difficult. Poorly chosen keys still make easy
-targets for intruders.
-
-The following sections specify the encryption and checksum mechanisms
-currently defined for Kerberos. The encodings, chaining, and padding
-requirements for each are described. For encryption methods, it is often
-desirable to place random information (often referred to as a confounder) at
-the start of the message. The requirements for a confounder are specified
-with each encryption mechanism.
-
-Some encryption systems use a block-chaining method to improve the the
-security characteristics of the ciphertext. However, these chaining methods
-often don't provide an integrity check upon decryption. Such systems (such
-as DES in CBC mode) must be augmented with a checksum of the plain-text
-which can be verified at decryption and used to detect any tampering or
-damage. Such checksums should be good at detecting burst errors in the
-input. If any damage is detected, the decryption routine is expected to
-return an error indicating the failure of an integrity check. Each
-encryption type is expected to provide and verify an appropriate checksum.
-The specification of each encryption method sets out its checksum
-requirements.
-
-Finally, where a key is to be derived from a user's password, an algorithm
-for converting the password to a key of the appropriate type is included. It
-is desirable for the string to key function to be one-way, and for the
-mapping to be different in different realms. This is important because users
-who are registered in more than one realm will often use the same password
-in each, and it is desirable that an attacker compromising the Kerberos
-server in one realm not obtain or derive the user's key in another.
-
-For an discussion of the integrity characteristics of the candidate
-encryption and checksum methods considered for Kerberos, the the reader is
-referred to [SG92].
-
-6.1. Encryption Specifications
-
-The following ASN.1 definition describes all encrypted messages. The
-enc-part field which appears in the unencrypted part of messages in section
-5 is a sequence consisting of an encryption type, an optional key version
-number, and the ciphertext.
-
-EncryptedData ::=   SEQUENCE {
-                    etype[0]     INTEGER, -- EncryptionType
-                    kvno[1]      INTEGER OPTIONAL,
-                    cipher[2]    OCTET STRING -- ciphertext
-}
-
-
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-etype
-     This field identifies which encryption algorithm was used to encipher
-     the cipher. Detailed specifications for selected encryption types
-     appear later in this section.
-kvno
-     This field contains the version number of the key under which data is
-     encrypted. It is only present in messages encrypted under long lasting
-     keys, such as principals' secret keys.
-cipher
-     This field contains the enciphered text, encoded as an OCTET STRING.
-
-The cipher field is generated by applying the specified encryption algorithm
-to data composed of the message and algorithm-specific inputs. Encryption
-mechanisms defined for use with Kerberos must take sufficient measures to
-guarantee the integrity of the plaintext, and we recommend they also take
-measures to protect against precomputed dictionary attacks. If the
-encryption algorithm is not itself capable of doing so, the protections can
-often be enhanced by adding a checksum and a confounder.
-
-The suggested format for the data to be encrypted includes a confounder, a
-checksum, the encoded plaintext, and any necessary padding. The msg-seq
-field contains the part of the protocol message described in section 5 which
-is to be encrypted. The confounder, checksum, and padding are all untagged
-and untyped, and their length is exactly sufficient to hold the appropriate
-item. The type and length is implicit and specified by the particular
-encryption type being used (etype). The format for the data to be encrypted
-is described in the following diagram:
-
-      +-----------+----------+-------------+-----+
-      |confounder |   check  |   msg-seq   | pad |
-      +-----------+----------+-------------+-----+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-CipherText ::=   ENCRYPTED       SEQUENCE {
-            confounder[0]   UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL,
-            check[1]        UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
-            msg-seq[2]      MsgSequence,
-            pad             UNTAGGED OCTET STRING(pad_length) OPTIONAL
-}
-
-One generates a random confounder of the appropriate length, placing it in
-confounder; zeroes out check; calculates the appropriate checksum over
-confounder, check, and msg-seq, placing the result in check; adds the
-necessary padding; then encrypts using the specified encryption type and the
-appropriate key.
-
-Unless otherwise specified, a definition of an encryption algorithm that
-specifies a checksum, a length for the confounder field, or an octet
-boundary for padding uses this ciphertext format[36]. Those fields which are
-not specified will be omitted.
-
-In the interest of allowing all implementations using a particular
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-encryption type to communicate with all others using that type, the
-specification of an encryption type defines any checksum that is needed as
-part of the encryption process. If an alternative checksum is to be used, a
-new encryption type must be defined.
-
-Some cryptosystems require additional information beyond the key and the
-data to be encrypted. For example, DES, when used in cipher-block-chaining
-mode, requires an initialization vector. If required, the description for
-each encryption type must specify the source of such additional information.
-6.2. Encryption Keys
-
-The sequence below shows the encoding of an encryption key:
-
-       EncryptionKey ::=   SEQUENCE {
-                           keytype[0]    INTEGER,
-                           keyvalue[1]   OCTET STRING
-       }
-
-keytype
-     This field specifies the type of encryption key that follows in the
-     keyvalue field. It will almost always correspond to the encryption
-     algorithm used to generate the EncryptedData, though more than one
-     algorithm may use the same type of key (the mapping is many to one).
-     This might happen, for example, if the encryption algorithm uses an
-     alternate checksum algorithm for an integrity check, or a different
-     chaining mechanism.
-keyvalue
-     This field contains the key itself, encoded as an octet string.
-
-All negative values for the encryption key type are reserved for local use.
-All non-negative values are reserved for officially assigned type fields and
-interpreta- tions.
-
-6.3. Encryption Systems
-
-6.3.1. The NULL Encryption System (null)
-
-If no encryption is in use, the encryption system is said to be the NULL
-encryption system. In the NULL encryption system there is no checksum,
-confounder or padding. The ciphertext is simply the plaintext. The NULL Key
-is used by the null encryption system and is zero octets in length, with
-keytype zero (0).
-
-6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
-
-The des-cbc-crc encryption mode encrypts information under the Data
-Encryption Standard [DES77] using the cipher block chaining mode [DESM80]. A
-CRC-32 checksum (described in ISO 3309 [ISO3309]) is applied to the
-confounder and message sequence (msg-seq) and placed in the cksum field. DES
-blocks are 8 bytes. As a result, the data to be encrypted (the concatenation
-of confounder, checksum, and message) must be padded to an 8 byte boundary
-before encryption. The details of the encryption of this data are identical
-to those for the des-cbc-md5 encryption mode.
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-Note that, since the CRC-32 checksum is not collision-proof, an attacker
-could use a probabilistic chosen-plaintext attack to generate a valid
-message even if a confounder is used [SG92]. The use of collision-proof
-checksums is recommended for environments where such attacks represent a
-significant threat. The use of the CRC-32 as the checksum for ticket or
-authenticator is no longer mandated as an interoperability requirement for
-Kerberos Version 5 Specification 1 (See section 9.1 for specific details).
-
-6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
-
-The des-cbc-md4 encryption mode encrypts information under the Data
-Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
-An MD4 checksum (described in [MD492]) is applied to the confounder and
-message sequence (msg-seq) and placed in the cksum field. DES blocks are 8
-bytes. As a result, the data to be encrypted (the concatenation of
-confounder, checksum, and message) must be padded to an 8 byte boundary
-before encryption. The details of the encryption of this data are identical
-to those for the des-cbc-md5 encryption mode.
-
-6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
-
-The des-cbc-md5 encryption mode encrypts information under the Data
-Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
-An MD5 checksum (described in [MD5-92].) is applied to the confounder and
-message sequence (msg-seq) and placed in the cksum field. DES blocks are 8
-bytes. As a result, the data to be encrypted (the concatenation of
-confounder, checksum, and message) must be padded to an 8 byte boundary
-before encryption.
-
-Plaintext and DES ciphtertext are encoded as blocks of 8 octets which are
-concatenated to make the 64-bit inputs for the DES algorithms. The first
-octet supplies the 8 most significant bits (with the octet's MSbit used as
-the DES input block's MSbit, etc.), the second octet the next 8 bits, ...,
-and the eighth octet supplies the 8 least significant bits.
-
-Encryption under DES using cipher block chaining requires an additional
-input in the form of an initialization vector. Unless otherwise specified,
-zero should be used as the initialization vector. Kerberos' use of DES
-requires an 8 octet confounder.
-
-The DES specifications identify some 'weak' and 'semi-weak' keys; those keys
-shall not be used for encrypting messages for use in Kerberos. Additionally,
-because of the way that keys are derived for the encryption of checksums,
-keys shall not be used that yield 'weak' or 'semi-weak' keys when
-eXclusive-ORed with the hexadecimal constant F0F0F0F0F0F0F0F0.
-
-A DES key is 8 octets of data, with keytype one (1). This consists of 56
-bits of key, and 8 parity bits (one per octet). The key is encoded as a
-series of 8 octets written in MSB-first order. The bits within the key are
-also encoded in MSB order. For example, if the encryption key is
-(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
-B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity
-bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the
-MSbit). [See the FIPS 81 introduction for reference.]
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-String to key transformation
-
-To generate a DES key from a text string (password), the text string
-normally must have the realm and each component of the principal's name
-appended[37], then padded with ASCII nulls to an 8 byte boundary. This
-string is then fan-folded and eXclusive-ORed with itself to form an 8 byte
-DES key. The parity is corrected on the key, and it is used to generate a
-DES CBC checksum on the initial string (with the realm and name appended).
-Next, parity is corrected on the CBC checksum. If the result matches a
-'weak' or 'semi-weak' key as described in the DES specification, it is
-eXclusive-ORed with the constant 00000000000000F0. Finally, the result is
-returned as the key. Pseudocode follows:
-
-     string_to_key(string,realm,name) {
-          odd = 1;
-          s = string + realm;
-          for(each component in name) {
-               s = s + component;
-          }
-          tempkey = NULL;
-          pad(s); /* with nulls to 8 byte boundary */
-          for(8byteblock in s) {
-               if(odd == 0)  {
-                   odd = 1;
-                   reverse(8byteblock)
-               }
-               else odd = 0;
-               tempkey = tempkey XOR 8byteblock;
-          }
-          fixparity(tempkey);
-          key = DES-CBC-check(s,tempkey);
-          fixparity(key);
-          if(is_weak_key_key(key))
-               key = key XOR 0xF0;
-          return(key);
-     }
-
-6.3.5. Triple DES EDE in outer CBC mode with an SHA1 check-sum
-(des3-cbc-sha1)
-
-The des3-cbc-sha1 encryption encodes information using three Data Encryption
-Standard transformations with three DES keys. The first key is used to
-perform a DES ECB encryption on an eight-octet data block using the first
-DES key, followed by a DES ECB decryption of the result using the second DES
-key, and a DES ECB encryption of the result using the third DES key. Because
-DES blocks are 8 bytes, the data to be encrypted (the concatenation of
-confounder, checksum, and message) must first be padded to an 8 byte
-boundary before encryption. To support the outer CBC mode, the input is
-padded to an eight-octet boundary. The first 8 octets of the data to be
-encrypted (the confounder) is exclusive-ored with an initialization vector
-of zero and then ECB encrypted using triple DES as described above.
-Subsequent blocks of 8 octets are exclusive-ored with the ciphertext
-produced by the encryption on the previous block before ECB encryption.
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-An HMAC-SHA1 checksum (described in [KBC96].) is applied to the confounder
-and message sequence (msg-seq) and placed in the cksum field.
-
-Plaintext are encoded as blocks of 8 octets which are concatenated to make
-the 64-bit inputs for the DES algorithms. The first octet supplies the 8
-most significant bits (with the octet's MSbit used as the DES input block's
-MSbit, etc.), the second octet the next 8 bits, ..., and the eighth octet
-supplies the 8 least significant bits.
-
-Encryption under Triple DES using cipher block chaining requires an
-additional input in the form of an initialization vector. Unless otherwise
-specified, zero should be used as the initialization vector. Kerberos' use
-of DES requires an 8 octet confounder.
-
-The DES specifications identify some 'weak' and 'semi-weak' keys; those keys
-shall not be used for encrypting messages for use in Kerberos. Additionally,
-because of the way that keys are derived for the encryption of checksums,
-keys shall not be used that yield 'weak' or 'semi-weak' keys when
-eXclusive-ORed with the hexadecimal constant F0F0F0F0F0F0F0F0.
-
-A Triple DES key is 24 octets of data, with keytype seven (7). This consists
-of 168 bits of key, and 24 parity bits (one per octet). The key is encoded
-as a series of 24 octets written in MSB-first order, with the first 8 octets
-treated as the first DES key, the second 8 octets as the second key, and the
-third 8 octets the third DES key. The bits within each key are also encoded
-in MSB order. For example, if the encryption key is
-(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
-B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity
-bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the
-MSbit). [See the FIPS 81 introduction for reference.]
-
-Key derivation for specified operations (Horowitz)
-
-[Discussion is needed for this section, especially since it does not simply
-derive key generation, but also specifies encryption using triple DES in a
-manner that is different than the basic template that was specified for
-single DES and similar systems]
-
-In the Kerberos protocol cryptographic keys are used in a number of places.
-In order to minimize the effect of compromising a key, it is desirable to
-use a different key in each of these places. Key derivation [Horowitz96] can
-be used to construct different keys for each operation from the keys
-transported on the network or derived from the password specified by the
-user.
-
-For each place where a key is used in Kerberos, a ``key usage'' is specified
-for that purpose. The key, key usage, and encryption/checksum type together
-describe the transformation from plaintext to ciphertext. For backwards
-compatibility, this key derivation is only specified here for encryption
-methods based on triple DES. Encryption methods specified for use by
-Kerberos in the future should specify the key derivation function to be
-used.
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-Kerberos requires that the ciphertext component of EncryptedData be
-tamper-resistant as well as confidential. This implies encryption and
-integrity functions, which must each use their own separate keys. So, for
-each key usage, two keys must be generated, one for encryption (Ke), and one
-for integrity (Ki):
-
-      Ke = DK(protocol key, key usage | 0xAA)
-      Ki = DK(protocol key, key usage | 0x55)
-
-where the key usage is represented as a 32 bit integer in network byte
-order. The ciphertest must be generated from the plaintext as follows:
-
-      ciphertext = E(Ke, confounder | length | plaintext | padding) |
-                   H(Ki, confounder | length | plaintext | padding)
-
-The confounder and padding are specific to the encryption algorithm E.
-
-When generating a checksum only, there is no need for a confounder or
-padding. Again, a new key (Kc) must be used. Checksums must be generated
-from the plaintext as follows:
-
-      Kc = DK(protocol key, key usage | 0x99)
-      MAC = H(Kc, length | plaintext)
-
-
-Note that each enctype is described by an encryption algorithm E and a keyed
-hash algorithm H, and each checksum type is described by a keyed hash
-algorithm H. HMAC, with an appropriate hash, is recommended for use as H.
-
-The key usage value will be taken from the following list of places where
-keys are used in the Kerberos protocol, with key usage values and Kerberos
-specification section numbers:
-
-      1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
-          client key (section 5.4.1)
-      2.  AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
-          application session key), encrypted with the service key
-          (section 5.4.2)
-      3.  AS-REP encrypted part (includes tgs session key or application
-          session key), encrypted with the client key (section 5.4.2)
-
-      4.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
-          session key (section 5.4.1)
-      5.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
-          authenticator subkey (section 5.4.1)
-      6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
-          with the tgs session key (sections 5.3.2, 5.4.1)
-      7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
-          authenticator subkey), encrypted with the tgs session key
-          (section 5.3.2)
-      8.  TGS-REP encrypted part (includes application session key),
-          encrypted with the tgs session key (section 5.4.2)
-      9.  TGS-REP encrypted part (includes application session key),
-          encrypted with the tgs authenticator subkey (section 5.4.2)
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-      10. AP-REQ Authenticator cksum, keyed with the application session
-          key (section 5.3.2)
-      11. AP-REQ Authenticator (includes application authenticator
-          subkey), encrypted with the application session key (section
-          5.3.2)
-      12. AP-REP encrypted part (includes application session subkey),
-          encrypted with the application session key (section 5.5.2)
-
-      13. KRB-PRIV encrypted part, encrypted with a key chosen by the
-          application (section 5.7.1)
-      14. KRB-CRED encrypted part, encrypted with a key chosen by the
-          application (section 5.6.1)
-      15. KRB-SAFE cksum, keyed with a key chosen by the application
-          (section 5.8.1)
-
-      16. Data which is defined in some specification outside of
-          Kerberos to be encrypted using Kerberos encryption type.
-      17. Data which is defined in some specification outside of
-          Kerberos to be checksummed using Kerberos checksum type.
-
-      18. KRB-ERROR checksum (e-cksum in section 5.9.1)
-      19. AD-KDCIssued checksum (ad-checksum in appendix B.1)
-      20. Checksum for Mandatory Ticket Extensions (appendix B.6)
-      21. Checksum in Authorization Data in Ticket Extensions (appendix B.7)
-
-String to key transformation
-
-To generate a DES key from a text string (password), the text string
-normally must have the realm and each component of the principal's name
-appended[38].
-
-The input string (with any salt data appended to it) is n-folded into a 24
-octet (192 bit) string. To n-fold a number X, replicate the input value to a
-length that is the least common multiple of n and the length of X. Before
-each repetition, the input X is rotated to the right by 13 bit positions.
-The successive n-bit chunks are added together using 1's-complement addition
-(addition with end-around carry) to yield a n-bit result. (This
-transformation was proposed by Richard Basch)
-
-Each successive set of 8 octets is taken as a DES key, and its parity is
-adjusted in the same manner as previously described. If any of the three
-sets of 8 octets match a 'weak' or 'semi-weak key as described in the DES
-specification, that chunk is eXclusive-ORed with the hexadecimal constant
-00000000000000F0. The resulting DES keys are then used in sequence to
-perform a Triple-DES CBC encryption of the n-folded input string (appended
-with any salt data), using a zero initial vector. Parity, weak, and
-semi-weak keys are once again corrected and the result is returned as the 24
-octet key.
-
-Pseudocode follows:
-
-     string_to_key(string,realm,name) {
-          s = string + realm;
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-          for(each component in name) {
-               s = s + component;
-          }
-          tkey[24] = fold(s);
-          fixparity(tkey);
-          if(isweak(tkey[0-7])) tkey[0-7] = tkey[0-7] XOR 0xF0;
-          if(isweak(tkey[8-15])) tkey[8-15] = tkey[8-15] XOR 0xF0;
-          if(is_weak(tkey[16-23])) tkey[16-23] = tkey[16-23] XOR 0xF0;
-          key[24] = 3DES-CBC(data=fold(s),key=tkey,iv=0);
-          fixparity(key);
-          if(is_weak(key[0-7])) key[0-7] = key[0-7] XOR 0xF0;
-          if(is_weak(key[8-15])) key[8-15] = key[8-15] XOR 0xF0;
-          if(is_weak(key[16-23])) key[16-23] = key[16-23] XOR 0xF0;
-          return(key);
-     }
-
-6.4. Checksums
-
-The following is the ASN.1 definition used for a checksum:
-
-         Checksum ::=   SEQUENCE {
-                        cksumtype[0]   INTEGER,
-                        checksum[1]    OCTET STRING
-         }
-
-cksumtype
-     This field indicates the algorithm used to generate the accompanying
-     checksum.
-checksum
-     This field contains the checksum itself, encoded as an octet string.
-
-Detailed specification of selected checksum types appear later in this
-section. Negative values for the checksum type are reserved for local use.
-All non-negative values are reserved for officially assigned type fields and
-interpretations.
-
-Checksums used by Kerberos can be classified by two properties: whether they
-are collision-proof, and whether they are keyed. It is infeasible to find
-two plaintexts which generate the same checksum value for a collision-proof
-checksum. A key is required to perturb or initialize the algorithm in a
-keyed checksum. To prevent message-stream modification by an active
-attacker, unkeyed checksums should only be used when the checksum and
-message will be subsequently encrypted (e.g. the checksums defined as part
-of the encryption algorithms covered earlier in this section).
-
-Collision-proof checksums can be made tamper-proof if the checksum value is
-encrypted before inclusion in a message. In such cases, the composition of
-the checksum and the encryption algorithm must be considered a separate
-checksum algorithm (e.g. RSA-MD5 encrypted using DES is a new checksum
-algorithm of type RSA-MD5-DES). For most keyed checksums, as well as for the
-encrypted forms of unkeyed collision-proof checksums, Kerberos prepends a
-confounder before the checksum is calculated.
-
-6.4.1. The CRC-32 Checksum (crc32)
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-The CRC-32 checksum calculates a checksum based on a cyclic redundancy check
-as described in ISO 3309 [ISO3309]. The resulting checksum is four (4)
-octets in length. The CRC-32 is neither keyed nor collision-proof. The use
-of this checksum is not recommended. An attacker using a probabilistic
-chosen-plaintext attack as described in [SG92] might be able to generate an
-alternative message that satisfies the checksum. The use of collision-proof
-checksums is recommended for environments where such attacks represent a
-significant threat.
-
-6.4.2. The RSA MD4 Checksum (rsa-md4)
-
-The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm
-[MD4-92]. The algorithm takes as input an input message of arbitrary length
-and produces as output a 128-bit (16 octet) checksum. RSA-MD4 is believed to
-be collision-proof.
-
-6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des)
-
-The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by
-prepending an 8 octet confounder before the text, applying the RSA MD4
-checksum algorithm, and encrypting the confounder and the checksum using DES
-in cipher-block-chaining (CBC) mode using a variant of the key, where the
-variant is computed by eXclusive-ORing the key with the constant
-F0F0F0F0F0F0F0F0[39]. The initialization vector should be zero. The
-resulting checksum is 24 octets long (8 octets of which are redundant). This
-checksum is tamper-proof and believed to be collision-proof.
-
-The DES specifications identify some weak keys' and 'semi-weak keys'; those
-keys shall not be used for generating RSA-MD4 checksums for use in Kerberos.
-
-The format for the checksum is described in the follow- ing diagram:
-
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-|  des-cbc(confounder   +   rsa-md4(confounder+msg),key=var(key),iv=0)  |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-rsa-md4-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                           confounder[0]   UNTAGGED OCTET STRING(8),
-                           check[1]        UNTAGGED OCTET STRING(16)
-}
-
-6.4.4. The RSA MD5 Checksum (rsa-md5)
-
-The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm.
-[MD5-92]. The algorithm takes as input an input message of arbitrary length
-and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is believed to
-be collision-proof.
-
-6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des)
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by
-prepending an 8 octet confounder before the text, applying the RSA MD5
-checksum algorithm, and encrypting the confounder and the checksum using DES
-in cipher-block-chaining (CBC) mode using a variant of the key, where the
-variant is computed by eXclusive-ORing the key with the hexadecimal constant
-F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting
-checksum is 24 octets long (8 octets of which are redundant). This checksum
-is tamper-proof and believed to be collision-proof.
-
-The DES specifications identify some 'weak keys' and 'semi-weak keys'; those
-keys shall not be used for encrypting RSA-MD5 checksums for use in Kerberos.
-
-The format for the checksum is described in the following diagram:
-
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-|  des-cbc(confounder   +   rsa-md5(confounder+msg),key=var(key),iv=0)  |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-rsa-md5-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                           confounder[0]   UNTAGGED OCTET STRING(8),
-                           check[1]        UNTAGGED OCTET STRING(16)
-}
-
-6.4.6. DES cipher-block chained checksum (des-mac)
-
-The DES-MAC checksum is computed by prepending an 8 octet confounder to the
-plaintext, performing a DES CBC-mode encryption on the result using the key
-and an initialization vector of zero, taking the last block of the
-ciphertext, prepending the same confounder and encrypting the pair using DES
-in cipher-block-chaining (CBC) mode using a a variant of the key, where the
-variant is computed by eXclusive-ORing the key with the hexadecimal constant
-F0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting
-checksum is 128 bits (16 octets) long, 64 bits of which are redundant. This
-checksum is tamper-proof and collision-proof.
-
-The format for the checksum is described in the following diagram:
-
-+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
-|   des-cbc(confounder  + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
-+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-des-mac-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                       confounder[0]   UNTAGGED OCTET STRING(8),
-                       check[1]        UNTAGGED OCTET STRING(8)
-}
-
-The DES specifications identify some 'weak' and 'semi-weak' keys; those keys
-shall not be used for generating DES-MAC checksums for use in Kerberos, nor
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-shall a key be used whose variant is 'weak' or 'semi-weak'.
-
-6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative (rsa-md4-des-k)
-
-The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum by
-applying the RSA MD4 checksum algorithm and encrypting the results using DES
-in cipher-block-chaining (CBC) mode using a DES key as both key and
-initialization vector. The resulting checksum is 16 octets long. This
-checksum is tamper-proof and believed to be collision-proof. Note that this
-checksum type is the old method for encoding the RSA-MD4-DES checksum and it
-is no longer recommended.
-
-6.4.8. DES cipher-block chained checksum alternative (des-mac-k)
-
-The DES-MAC-K checksum is computed by performing a DES CBC-mode encryption
-of the plaintext, and using the last block of the ciphertext as the checksum
-value. It is keyed with an encryption key and an initialization vector; any
-uses which do not specify an additional initialization vector will use the
-key as both key and initialization vector. The resulting checksum is 64 bits
-(8 octets) long. This checksum is tamper-proof and collision-proof. Note
-that this checksum type is the old method for encoding the DES-MAC checksum
-and it is no longer recommended. The DES specifications identify some 'weak
-keys' and 'semi-weak keys'; those keys shall not be used for generating
-DES-MAC checksums for use in Kerberos.
-
-7. Naming Constraints
-
-7.1. Realm Names
-
-Although realm names are encoded as GeneralStrings and although a realm can
-technically select any name it chooses, interoperability across realm
-boundaries requires agreement on how realm names are to be assigned, and
-what information they imply.
-
-To enforce these conventions, each realm must conform to the conventions
-itself, and it must require that any realms with which inter-realm keys are
-shared also conform to the conventions and require the same from its
-neighbors.
-
-Kerberos realm names are case sensitive. Realm names that differ only in the
-case of the characters are not equivalent. There are presently four styles
-of realm names: domain, X500, other, and reserved. Examples of each style
-follow:
-
-     domain:   ATHENA.MIT.EDU (example)
-       X500:   C=US/O=OSF (example)
-      other:   NAMETYPE:rest/of.name=without-restrictions (example)
-   reserved:   reserved, but will not conflict with above
-
-Domain names must look like domain names: they consist of components
-separated by periods (.) and they contain neither colons (:) nor slashes
-(/). Domain names must be converted to upper case when used as realm names.
-
-X.500 names contain an equal (=) and cannot contain a colon (:) before the
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-equal. The realm names for X.500 names will be string representations of the
-names with components separated by slashes. Leading and trailing slashes
-will not be included.
-
-Names that fall into the other category must begin with a prefix that
-contains no equal (=) or period (.) and the prefix must be followed by a
-colon (:) and the rest of the name. All prefixes must be assigned before
-they may be used. Presently none are assigned.
-
-The reserved category includes strings which do not fall into the first
-three categories. All names in this category are reserved. It is unlikely
-that names will be assigned to this category unless there is a very strong
-argument for not using the 'other' category.
-
-These rules guarantee that there will be no conflicts between the various
-name styles. The following additional constraints apply to the assignment of
-realm names in the domain and X.500 categories: the name of a realm for the
-domain or X.500 formats must either be used by the organization owning (to
-whom it was assigned) an Internet domain name or X.500 name, or in the case
-that no such names are registered, authority to use a realm name may be
-derived from the authority of the parent realm. For example, if there is no
-domain name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
-authorize the creation of a realm with that name.
-
-This is acceptable because the organization to which the parent is assigned
-is presumably the organization authorized to assign names to its children in
-the X.500 and domain name systems as well. If the parent assigns a realm
-name without also registering it in the domain name or X.500 hierarchy, it
-is the parent's responsibility to make sure that there will not in the
-future exists a name identical to the realm name of the child unless it is
-assigned to the same entity as the realm name.
-
-7.2. Principal Names
-
-As was the case for realm names, conventions are needed to ensure that all
-agree on what information is implied by a principal name. The name-type
-field that is part of the principal name indicates the kind of information
-implied by the name. The name-type should be treated as a hint. Ignoring the
-name type, no two names can be the same (i.e. at least one of the
-components, or the realm, must be different). The following name types are
-defined:
-
-  name-type      value   meaning
-
-   NT-UNKNOWN        0   Name type not known
-   NT-PRINCIPAL      1   General principal name (e.g. username, or DCE principal)
-   NT-SRV-INST       2   Service and other unique instance (krbtgt)
-   NT-SRV-HST        3   Service with host name as instance (telnet, rcommands)
-   NT-SRV-XHST       4   Service with slash-separated host name components
-   NT-UID            5   Unique ID
-   NT-X500-PRINCIPAL 6   Encoded X.509 Distingished name [RFC 1779]
-
-When a name implies no information other than its uniqueness at a particular
-time the name type PRINCIPAL should be used. The principal name type should
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-be used for users, and it might also be used for a unique server. If the
-name is a unique machine generated ID that is guaranteed never to be
-reassigned then the name type of UID should be used (note that it is
-generally a bad idea to reassign names of any type since stale entries might
-remain in access control lists).
-
-If the first component of a name identifies a service and the remaining
-components identify an instance of the service in a server specified manner,
-then the name type of SRV-INST should be used. An example of this name type
-is the Kerberos ticket-granting service whose name has a first component of
-krbtgt and a second component identifying the realm for which the ticket is
-valid.
-
-If instance is a single component following the service name and the
-instance identifies the host on which the server is running, then the name
-type SRV-HST should be used. This type is typically used for Internet
-services such as telnet and the Berkeley R commands. If the separate
-components of the host name appear as successive components following the
-name of the service, then the name type SRV-XHST should be used. This type
-might be used to identify servers on hosts with X.500 names where the slash
-(/) might otherwise be ambiguous.
-
-A name type of NT-X500-PRINCIPAL should be used when a name from an X.509
-certificiate is translated into a Kerberos name. The encoding of the X.509
-name as a Kerberos principal shall conform to the encoding rules specified
-in RFC 1779.
-
-A name type of UNKNOWN should be used when the form of the name is not
-known. When comparing names, a name of type UNKNOWN will match principals
-authenticated with names of any type. A principal authenticated with a name
-of type UNKNOWN, however, will only match other names of type UNKNOWN.
-
-Names of any type with an initial component of 'krbtgt' are reserved for the
-Kerberos ticket granting service. See section 8.2.3 for the form of such
-names.
-
-7.2.1. Name of server principals
-
-The principal identifier for a server on a host will generally be composed
-of two parts: (1) the realm of the KDC with which the server is registered,
-and (2) a two-component name of type NT-SRV-HST if the host name is an
-Internet domain name or a multi-component name of type NT-SRV-XHST if the
-name of the host is of a form such as X.500 that allows slash (/)
-separators. The first component of the two- or multi-component name will
-identify the service and the latter components will identify the host. Where
-the name of the host is not case sensitive (for example, with Internet
-domain names) the name of the host must be lower case. If specified by the
-application protocol for services such as telnet and the Berkeley R commands
-which run with system privileges, the first component may be the string
-'host' instead of a service specific identifier. 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.
-
-8. Constants and other defined values
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-8.1. Host address types
-
-All negative values for the host address type are reserved for local use.
-All non-negative values are reserved for officially assigned type fields and
-interpretations.
-
-The values of the types for the following addresses are chosen to match the
-defined address family constants in the Berkeley Standard Distributions of
-Unix. They can be found in with symbolic names AF_xxx (where xxx is an
-abbreviation of the address family name).
-
-Internet (IPv4) Addresses
-
-Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in MSB
-order. The type of IPv4 addresses is two (2).
-
-Internet (IPv6) Addresses
-
-IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The
-type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. The
-following addresses (see [RFC1884]) MUST not appear in any Kerberos packet:
-
-   * the Unspecified Address
-   * the Loopback Address
-   * Link-Local addresses
-
-IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
-
-CHAOSnet addresses
-
-CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB order.
-The type of CHAOSnet addresses is five (5).
-
-ISO addresses
-
-ISO addresses are variable-length. The type of ISO addresses is seven (7).
-
-Xerox Network Services (XNS) addresses
-
-XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. The
-type of XNS addresses is six (6).
-
-AppleTalk Datagram Delivery Protocol (DDP) addresses
-
-AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit network
-number. The first octet of the address is the node number; the remaining two
-octets encode the network number in MSB order. The type of AppleTalk DDP
-addresses is sixteen (16).
-
-DECnet Phase IV addresses
-
-DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. The
-type of DECnet Phase IV addresses is twelve (12).
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-8.2. KDC messages
-
-8.2.1. UDP/IP transport
-
-When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using UDP
-IP transport, the client shall send a UDP datagram containing only an
-encoding of the request to port 88 (decimal) at the KDC's IP address; the
-KDC will respond with a reply datagram containing only an encoding of the
-reply message (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at
-the sender's IP address. Kerberos servers supporting IP transport must
-accept UDP requests on port 88 (decimal). The response to a request made
-through UDP/IP transport must also use UDP/IP transport.
-
-8.2.2. TCP/IP transport
-
-Kerberos servers (KDC's) must accept TCP requests on port 88 (decimal). When
-the KRB_KDC_REQ message is sent to the KDC over a TCP stream, a new
-connection will be established for each authentication exchange (request and
-response). The KRB_KDC_REP or KRB_ERROR message will be returned to the
-client on the same TCP stream that was established for the request. The
-connection will be broken after the reply has been received (or upon
-time-out). Care must be taken in managing TCP/IP connections with the KDC to
-prevent denial of service attacks based on the number of TCP/IP connections
-with the KDC that remain open. If multiple exchanges with the KDC are needed
-for certain forms of preauthentication, multiple TCP connections will be
-required. The response to a request made through TCP/IP transport must also
-use TCP/IP transport.
-
-The first four octets of the TCP stream used to transmit the request request
-will encode in network byte order the length of the request (KRB_KDC_REQ),
-and the length will be followed by the request itself. The response will
-similarly be preceeded by a 4 octet encoding in network byte order of the
-length of the KRB_KDC_REP or the KRB_ERROR message and will be followed by
-the KRB_KDC_REP or the KRB_ERROR response.
-
-8.2.3. OSI transport
-
-During authentication of an OSI client to an OSI server, the mutual
-authentication of an OSI server to an OSI client, the transfer of
-credentials from an OSI client to an OSI server, or during exchange of
-private or integrity checked messages, Kerberos protocol messages may be
-treated as opaque objects and the type of the authentication mechanism will
-be:
-
-OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),kerberosv5(2)}
-
-Depending on the situation, the opaque object will be an authentication
-header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe message
-(KRB_SAFE), a private message (KRB_PRIV), or a credentials message
-(KRB_CRED). The opaque data contains an application code as specified in the
-ASN.1 description for each message. The application code may be used by
-Kerberos to determine the message type.
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-8.2.3. Name of the TGS
-
-The principal identifier of the ticket-granting service shall be composed of
-three parts: (1) the realm of the KDC issuing the TGS ticket (2) a two-part
-name of type NT-SRV-INST, with the first part "krbtgt" and the second part
-the name of the realm which will accept the ticket-granting ticket. For
-example, a ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be
-used to get tickets from the ATHENA.MIT.EDU KDC has a principal identifier
-of "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A
-ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be used to get
-tickets from the MIT.EDU realm has a principal identifier of
-"ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU") (name).
-
-8.3. Protocol constants and associated values
-
-The following tables list constants used in the protocol and defines their
-meanings.
-
-Encryption type  etype value  block size    minimum pad size  confounder size
-NULL              0            1                 0                 0
-des-cbc-crc       1            8                 4                 8
-des-cbc-md4       2            8                 0                 8
-des-cbc-md5       3            8                 0                 8
-        4
-des3-cbc-md5      5            8                 0                 8
-        6
-des3-cbc-sha1     7            8                 0                 8
-sign-dsa-generate 8                                   (pkinit)
-encrypt-rsa-priv  9                                   (pkinit)
-encrypt-rsa-pub  10                                   (pkinit)
-rsa-pub-md5      11                                   (pkinit)
-rsa-pub-sha1     12                                   (pkinit)
-ENCTYPE_PK_CROSS 48                                   (reserved for pkcross)
-       0x8003
-
-Checksum type              sumtype value       checksum size
-CRC32                      1                   4
-rsa-md4                    2                   16
-rsa-md4-des                3                   24
-des-mac                    4                   16
-des-mac-k                  5                   8
-rsa-md4-des-k              6                   16
-rsa-md5                    7                   16
-rsa-md5-des                8                   24
-rsa-md5-des3               9                   24
-hmac-sha1-des3             10                  20  (I had this as 10, is it 12)
-
-padata type                     padata-type value
-
-PA-TGS-REQ                      1
-PA-ENC-TIMESTAMP                2
-PA-PW-SALT                      3
-                      4
-PA-ENC-UNIX-TIME                5
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-PA-SANDIA-SECUREID              6
-PA-SESAME                       7
-PA-OSF-DCE                      8
-PA-CYBERSAFE-SECUREID           9
-PA-AFS3-SALT                    10
-PA-ETYPE-INFO                   11
-SAM-CHALLENGE                   12                  (sam/otp)
-SAM-RESPONSE                    13                  (sam/otp)
-PA-PK-AS-REQ                    14                  (pkinit)
-PA-PK-AS-REP                    15                  (pkinit)
-PA-PK-AS-SIGN                   16                  (pkinit)
-PA-PK-KEY-REQ                   17                  (pkinit)
-PA-PK-KEY-REP                   18                  (pkinit)
-PA-USE-SPECIFIED-KVNO           20
-
-authorization data type         ad-type value
-AD-KDC-ISSUED                      1
-AD-INTENDED-FOR-SERVER             2
-AD-INTENDED-FOR-APPLICATION-CLASS  3
-AD-IF-RELEVANT                     4
-AD-OR                              5
-AD-MANDATORY-TICKET-EXTENSIONS     6
-AD-IN-TICKET-EXTENSIONS            7
-reserved values                    8-63
-OSF-DCE                            64
-SESAME                             65
-
-Ticket Extension Types
-
-TE-TYPE-NULL                  0      Null ticket extension
-TE-TYPE-EXTERNAL-ADATA        1      Integrity protected authorization data
-                    2      TE-TYPE-PKCROSS-KDC  (I have reservations)
-TE-TYPE-PKCROSS-CLIENT        3      PKCROSS cross realm key ticket
-TE-TYPE-CYBERSAFE-EXT         4      Assigned to CyberSafe Corp
-                    5      TE-TYPE-DEST-HOST (I have reservations)
-
-alternate authentication type   method-type value
-reserved values                 0-63
-ATT-CHALLENGE-RESPONSE          64
-
-transited encoding type         tr-type value
-DOMAIN-X500-COMPRESS            1
-reserved values                 all others
-
-Label               Value   Meaning or MIT code
-
-pvno                    5   current Kerberos protocol version number
-
-message types
-
-KRB_AS_REQ             10   Request for initial authentication
-KRB_AS_REP             11   Response to KRB_AS_REQ request
-KRB_TGS_REQ            12   Request for authentication based on TGT
-KRB_TGS_REP            13   Response to KRB_TGS_REQ request
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-KRB_AP_REQ             14   application request to server
-KRB_AP_REP             15   Response to KRB_AP_REQ_MUTUAL
-KRB_SAFE               20   Safe (checksummed) application message
-KRB_PRIV               21   Private (encrypted) application message
-KRB_CRED               22   Private (encrypted) message to forward credentials
-KRB_ERROR              30   Error response
-
-name types
-
-KRB_NT_UNKNOWN        0  Name type not known
-KRB_NT_PRINCIPAL      1  Just the name of the principal as in DCE, or for users
-KRB_NT_SRV_INST       2  Service and other unique instance (krbtgt)
-KRB_NT_SRV_HST        3  Service with host name as instance (telnet, rcommands)
-KRB_NT_SRV_XHST       4  Service with host as remaining components
-KRB_NT_UID            5  Unique ID
-KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 1779]
-
-error codes
-
-KDC_ERR_NONE                    0   No error
-KDC_ERR_NAME_EXP                1   Client's entry in database has expired
-KDC_ERR_SERVICE_EXP             2   Server's entry in database has expired
-KDC_ERR_BAD_PVNO                3   Requested protocol version number not 
-                                    supported
-KDC_ERR_C_OLD_MAST_KVNO         4   Client's key encrypted in old master key
-KDC_ERR_S_OLD_MAST_KVNO         5   Server's key encrypted in old master key
-KDC_ERR_C_PRINCIPAL_UNKNOWN     6   Client not found in Kerberos database
-KDC_ERR_S_PRINCIPAL_UNKNOWN     7   Server not found in Kerberos database
-KDC_ERR_PRINCIPAL_NOT_UNIQUE    8   Multiple principal entries in database
-KDC_ERR_NULL_KEY                9   The client or server has a null key
-KDC_ERR_CANNOT_POSTDATE        10   Ticket not eligible for postdating
-KDC_ERR_NEVER_VALID            11   Requested start time is later than end time
-KDC_ERR_POLICY                 12   KDC policy rejects request
-KDC_ERR_BADOPTION              13   KDC cannot accommodate requested option
-KDC_ERR_ETYPE_NOSUPP           14   KDC has no support for encryption type
-KDC_ERR_SUMTYPE_NOSUPP         15   KDC has no support for checksum type
-KDC_ERR_PADATA_TYPE_NOSUPP     16   KDC has no support for padata type
-KDC_ERR_TRTYPE_NOSUPP          17   KDC has no support for transited type
-KDC_ERR_CLIENT_REVOKED         18   Clients credentials have been revoked
-KDC_ERR_SERVICE_REVOKED        19   Credentials for server have been revoked
-KDC_ERR_TGT_REVOKED            20   TGT has been revoked
-KDC_ERR_CLIENT_NOTYET          21   Client not yet valid - try again later
-KDC_ERR_SERVICE_NOTYET         22   Server not yet valid - try again later
-KDC_ERR_KEY_EXPIRED            23   Password has expired - change password
-                                    to reset
-KDC_ERR_PREAUTH_FAILED         24   Pre-authentication information was invalid
-KDC_ERR_PREAUTH_REQUIRED       25   Additional pre-authenticationrequired [40]
-KDC_ERR_SERVER_NOMATCH         26   Requested server and ticket don't match
-KDC_ERR_MUST_USE_USER2USER     27   Server principal valid for user2user only
-KDC_ERR_PATH_NOT_ACCPETED      28   KDC Policy rejects transited path
-KRB_AP_ERR_BAD_INTEGRITY       31   Integrity check on decrypted field failed
-KRB_AP_ERR_TKT_EXPIRED         32   Ticket expired
-KRB_AP_ERR_TKT_NYV             33   Ticket not yet valid
-KRB_AP_ERR_REPEAT              34   Request is a replay
-KRB_AP_ERR_NOT_US              35   The ticket isn't for us
-KRB_AP_ERR_BADMATCH            36   Ticket and authenticator don't match
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-KRB_AP_ERR_SKEW                37   Clock skew too great
-KRB_AP_ERR_BADADDR             38   Incorrect net address
-KRB_AP_ERR_BADVERSION          39   Protocol version mismatch
-KRB_AP_ERR_MSG_TYPE            40   Invalid msg type
-KRB_AP_ERR_MODIFIED            41   Message stream modified
-KRB_AP_ERR_BADORDER            42   Message out of order
-KRB_AP_ERR_BADKEYVER           44   Specified version of key is not available
-KRB_AP_ERR_NOKEY               45   Service key not available
-KRB_AP_ERR_MUT_FAIL            46   Mutual authentication failed
-KRB_AP_ERR_BADDIRECTION        47   Incorrect message direction
-KRB_AP_ERR_METHOD              48   Alternative authentication method required
-KRB_AP_ERR_BADSEQ              49   Incorrect sequence number in message
-KRB_AP_ERR_INAPP_CKSUM         50   Inappropriate type of checksum in message
-KRB_AP_PATH_NOT_ACCEPTED       51   Policy rejects transited path
-KRB_ERR_GENERIC                60   Generic error (description in e-text)
-KRB_ERR_FIELD_TOOLONG          61   Field is too long for this implementation
-KDC_ERROR_CLIENT_NOT_TRUSTED   62   (pkinit)
-KDC_ERROR_KDC_NOT_TRUSTED      63   (pkinit)
-KDC_ERROR_INVALID_SIG          64   (pkinit)
-KDC_ERR_KEY_TOO_WEAK           65   (pkinit)
-KDC_ERR_CERTIFICATE_MISMATCH   66   (pkinit)
-
-9. Interoperability requirements
-
-Version 5 of the Kerberos protocol supports a myriad of options. Among these
-are multiple encryption and checksum types, alternative encoding schemes for
-the transited field, optional mechanisms for pre-authentication, the
-handling of tickets with no addresses, options for mutual authentication,
-user to user authentication, support for proxies, forwarding, postdating,
-and renewing tickets, the format of realm names, and the handling of
-authorization data.
-
-In order to ensure the interoperability of realms, it is necessary to define
-a minimal configuration which must be supported by all implementations. This
-minimal configuration is subject to change as technology does. For example,
-if at some later date it is discovered that one of the required encryption
-or checksum algorithms is not secure, it will be replaced.
-
-9.1. Specification 2
-
-This section defines the second specification of these options.
-Implementations which are configured in this way can be said to support
-Kerberos Version 5 Specification 2 (5.1). Specification 1 (depricated) may
-be found in RFC1510.
-
-Transport
-
-TCP/IP and UDP/IP transport must be supported by KDCs claiming conformance
-to specification 2. Kerberos clients claiming conformance to specification 2
-must support UDP/IP transport for messages with the KDC and may support
-TCP/IP transport.
-
-Encryption and checksum methods
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-The following encryption and checksum mechanisms must be supported.
-Implementations may support other mechanisms as well, but the additional
-mechanisms may only be used when communicating with principals known to also
-support them: This list is to be determined.
-
-Encryption: DES-CBC-MD5
-Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
-
-Realm Names
-
-All implementations must understand hierarchical realms in both the Internet
-Domain and the X.500 style. When a ticket granting ticket for an unknown
-realm is requested, the KDC must be able to determine the names of the
-intermediate realms between the KDCs realm and the requested realm.
-
-Transited field encoding
-
-DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported.
-Alternative encodings may be supported, but they may be used only when that
-encoding is supported by ALL intermediate realms.
-
-Pre-authentication methods
-
-The TGS-REQ method must be supported. The TGS-REQ method is not used on the
-initial request. The PA-ENC-TIMESTAMP method must be supported by clients
-but whether it is enabled by default may be determined on a realm by realm
-basis. If not used in the initial request and the error
-KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an
-acceptable method, the client should retry the initial request using the
-PA-ENC-TIMESTAMP preauthentication method. Servers need not support the
-PA-ENC-TIMESTAMP method, but if not supported the server should ignore the
-presence of PA-ENC-TIMESTAMP pre-authentication in a request.
-
-Mutual authentication
-
-Mutual authentication (via the KRB_AP_REP message) must be supported.
-
-Ticket addresses and flags
-
-All KDC's must pass on tickets that carry no addresses (i.e. if a TGT
-contains no addresses, the KDC will return derivative tickets), but each
-realm may set its own policy for issuing such tickets, and each application
-server will set its own policy with respect to accepting them.
-
-Proxies and forwarded tickets must be supported. Individual realms and
-application servers can set their own policy on when such tickets will be
-accepted.
-
-All implementations must recognize renewable and postdated tickets, but need
-not actually implement them. If these options are not supported, the
-starttime and endtime in the ticket shall specify a ticket's entire useful
-life. When a postdated ticket is decoded by a server, all implementations
-shall make the presence of the postdated flag visible to the calling server.
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-User-to-user authentication
-
-Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC option)
-must be provided by implementations, but individual realms may decide as a
-matter of policy to reject such requests on a per-principal or realm-wide
-basis.
-
-Authorization data
-
-Implementations must pass all authorization data subfields from
-ticket-granting tickets to any derivative tickets unless directed to
-suppress a subfield as part of the definition of that registered subfield
-type (it is never incorrect to pass on a subfield, and no registered
-subfield types presently specify suppression at the KDC).
-
-Implementations must make the contents of any authorization data subfields
-available to the server when a ticket is used. Implementations are not
-required to allow clients to specify the contents of the authorization data
-fields.
-
-9.2. Recommended KDC values
-
-Following is a list of recommended values for a KDC implementation, based on
-the list of suggested configuration constants (see section 4.4).
-
-minimum lifetime              5 minutes
-maximum renewable lifetime    1 week
-maximum ticket lifetime       1 day
-empty addresses               only when suitable  restrictions  appear
-                              in authorization data
-proxiable, etc.               Allowed.
-
-10. REFERENCES
-
-[NT94]    B. Clifford Neuman and Theodore Y. Ts'o, "An  Authenti-
-          cation  Service for Computer Networks," IEEE Communica-
-          tions Magazine, Vol. 32(9), pp. 33-38 (September 1994).
-
-[MNSS87]  S. P. Miller, B. C. Neuman, J. I. Schiller, and  J.  H.
-          Saltzer,  Section  E.2.1:  Kerberos  Authentication and
-          Authorization System, M.I.T. Project Athena, Cambridge,
-          Massachusetts (December 21, 1987).
-
-[SNS88]   J. G. Steiner, B. C. Neuman, and J. I. Schiller,  "Ker-
-          beros:  An Authentication Service for Open Network Sys-
-          tems," pp. 191-202 in  Usenix  Conference  Proceedings,
-          Dallas, Texas (February, 1988).
-
-[NS78]    Roger M.  Needham  and  Michael  D.  Schroeder,  "Using
-          Encryption for Authentication in Large Networks of Com-
-          puters,"  Communications  of  the  ACM,  Vol.   21(12),
-          pp. 993-999 (December, 1978).
-
-[DS81]    Dorothy E. Denning and  Giovanni  Maria  Sacco,  "Time-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-          stamps  in  Key Distribution Protocols," Communications
-          of the ACM, Vol. 24(8), pp. 533-536 (August 1981).
-
-[KNT92]   John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o,
-          "The Evolution of the Kerberos Authentication Service,"
-          in an IEEE Computer Society Text soon to  be  published
-          (June 1992).
-
-[Neu93]   B.  Clifford  Neuman,  "Proxy-Based  Authorization  and
-          Accounting  for Distributed Systems," in Proceedings of
-          the 13th International Conference on  Distributed  Com-
-          puting Systems, Pittsburgh, PA (May, 1993).
-
-[DS90]    Don Davis and Ralph Swick,  "Workstation  Services  and
-          Kerberos  Authentication  at Project Athena," Technical
-          Memorandum TM-424,  MIT Laboratory for Computer Science
-          (February 1990).
-
-[LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E.  Som-
-          merfeld,  and  K. Raeburn, Section E.1: Service Manage-
-          ment System, M.I.T.  Project  Athena,  Cambridge,  Mas-
-          sachusetts (1987).
-
-[X509-88] CCITT, Recommendation X.509: The Directory  Authentica-
-          tion Framework, December 1988.
-
-[Pat92].  J. Pato, Using  Pre-Authentication  to  Avoid  Password
-          Guessing  Attacks, Open Software Foundation DCE Request
-          for Comments 26 (December 1992).
-
-[DES77]   National Bureau of Standards, U.S. Department  of  Com-
-          merce,  "Data Encryption Standard," Federal Information
-          Processing Standards Publication  46,   Washington,  DC
-          (1977).
-
-[DESM80]  National Bureau of Standards, U.S. Department  of  Com-
-          merce,  "DES  Modes  of Operation," Federal Information
-          Processing Standards Publication 81,   Springfield,  VA
-          (December 1980).
-
-[SG92]    Stuart G. Stubblebine and Virgil D. Gligor, "On Message
-          Integrity  in  Cryptographic Protocols," in Proceedings
-          of the IEEE  Symposium  on  Research  in  Security  and
-          Privacy, Oakland, California (May 1992).
-
-[IS3309]  International Organization  for  Standardization,  "ISO
-          Information  Processing  Systems - Data Communication -
-          High-Level Data Link Control Procedure -  Frame  Struc-
-          ture," IS 3309 (October 1984).  3rd Edition.
-
-[MD4-92]  R. Rivest, "The  MD4  Message  Digest  Algorithm,"  RFC
-          1320,   MIT  Laboratory  for  Computer  Science  (April
-          1992).
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-[MD5-92]  R. Rivest, "The  MD5  Message  Digest  Algorithm,"  RFC
-          1321,   MIT  Laboratory  for  Computer  Science  (April
-          1992).
-
-[KBC96]   H. Krawczyk, M. Bellare, and R. Canetti, "HMAC:  Keyed-
-          Hashing  for  Message  Authentication,"  Working  Draft
-          draft-ietf-ipsec-hmac-md5-01.txt,   (August 1996).
-
-A. Pseudo-code for protocol processing
-
-This appendix provides pseudo-code describing how the messages are to be
-constructed and interpreted by clients and servers.
-
-A.1. KRB_AS_REQ generation
-
-        request.pvno := protocol version; /* pvno = 5 */
-        request.msg-type := message type; /* type = KRB_AS_REQ */
-
-        if(pa_enc_timestamp_required) then
-                request.padata.padata-type = PA-ENC-TIMESTAMP;
-                get system_time;
-                padata-body.patimestamp,pausec = system_time;
-                encrypt padata-body into request.padata.padata-value
-                        using client.key; /* derived from password */
-        endif
-
-        body.kdc-options := users's preferences;
-        body.cname := user's name;
-        body.realm := user's realm;
-        body.sname := service's name; /* usually "krbtgt",  "localrealm" */
-        if (body.kdc-options.POSTDATED is set) then
-                body.from := requested starting time;
-        else
-                omit body.from;
-        endif
-        body.till := requested end time;
-        if (body.kdc-options.RENEWABLE is set) then
-                body.rtime := requested final renewal time;
-        endif
-        body.nonce := random_nonce();
-        body.etype := requested etypes;
-        if (user supplied addresses) then
-                body.addresses := user's addresses;
-        else
-                omit body.addresses;
-        endif
-        omit body.enc-authorization-data;
-        request.req-body := body;
-
-        kerberos := lookup(name of local kerberos server (or servers));
-        send(packet,kerberos);
-
-        wait(for response);
-        if (timed_out) then
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-                retry or use alternate server;
-        endif
-
-A.2. KRB_AS_REQ verification and KRB_AS_REP generation
-
-        decode message into req;
-
-        client := lookup(req.cname,req.realm);
-        server := lookup(req.sname,req.realm);
-
-        get system_time;
-        kdc_time := system_time.seconds;
-
-        if (!client) then
-                /* no client in Database */
-                error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
-        endif
-        if (!server) then
-                /* no server in Database */
-                error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
-        endif
-
-        if(client.pa_enc_timestamp_required and
-           pa_enc_timestamp not present) then
-                error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
-        endif
-
-        if(pa_enc_timestamp present) then
-                decrypt req.padata-value into decrypted_enc_timestamp
-                        using client.key;
-                        using auth_hdr.authenticator.subkey;
-                if (decrypt_error()) then
-                        error_out(KRB_AP_ERR_BAD_INTEGRITY);
-                if(decrypted_enc_timestamp is not within allowable skew) then
-                        error_out(KDC_ERR_PREAUTH_FAILED);
-                endif
-                if(decrypted_enc_timestamp and usec is replay)
-                        error_out(KDC_ERR_PREAUTH_FAILED);
-                endif
-                add decrypted_enc_timestamp and usec to replay cache;
-        endif
-
-        use_etype := first supported etype in req.etypes;
-
-        if (no support for req.etypes) then
-                error_out(KDC_ERR_ETYPE_NOSUPP);
-        endif
-
-        new_tkt.vno := ticket version; /* = 5 */
-        new_tkt.sname := req.sname;
-        new_tkt.srealm := req.srealm;
-        reset all flags in new_tkt.flags;
-
-        /* It should be noted that local policy may affect the  */
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-        /* processing of any of these flags.  For example, some */
-        /* realms may refuse to issue renewable tickets         */
-
-        if (req.kdc-options.FORWARDABLE is set) then
-                set new_tkt.flags.FORWARDABLE;
-        endif
-        if (req.kdc-options.PROXIABLE is set) then
-                set new_tkt.flags.PROXIABLE;
-        endif
-
-        if (req.kdc-options.ALLOW-POSTDATE is set) then
-                set new_tkt.flags.MAY-POSTDATE;
-        endif
-        if ((req.kdc-options.RENEW is set) or
-            (req.kdc-options.VALIDATE is set) or
-            (req.kdc-options.PROXY is set) or
-            (req.kdc-options.FORWARDED is set) or
-            (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
-                error_out(KDC_ERR_BADOPTION);
-        endif
-
-        new_tkt.session := random_session_key();
-        new_tkt.cname := req.cname;
-        new_tkt.crealm := req.crealm;
-        new_tkt.transited := empty_transited_field();
-
-        new_tkt.authtime := kdc_time;
-
-        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 omitted */
-        endif
-        if (req.till = 0) then
-                till := infinity;
-        else
-                till := req.till;
-        endif
-
-        new_tkt.endtime := min(till,
-                              new_tkt.starttime+client.max_life,
-                              new_tkt.starttime+server.max_life,
-                              new_tkt.starttime+max_life_for_realm);
-
-        if ((req.kdc-options.RENEWABLE-OK is set) and
-            (new_tkt.endtime < req.till)) then
-                /* we set the RENEWABLE option for later processing */
-                set req.kdc-options.RENEWABLE;
-                req.rtime := req.till;
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-        endif
-
-        if (req.rtime = 0) then
-                rtime := infinity;
-        else
-                rtime := req.rtime;
-        endif
-
-        if (req.kdc-options.RENEWABLE is set) then
-                set new_tkt.flags.RENEWABLE;
-                new_tkt.renew-till := min(rtime,
-                                          new_tkt.starttime+client.max_rlife,
-                                          new_tkt.starttime+server.max_rlife,
-                                          new_tkt.starttime+max_rlife_for_realm);
-        else
-                omit new_tkt.renew-till; /* only present if RENEWABLE */
-        endif
-
-        if (req.addresses) then
-                new_tkt.caddr := req.addresses;
-        else
-                omit new_tkt.caddr;
-        endif
-
-        new_tkt.authorization_data := empty_authorization_data();
-
-        encode to-be-encrypted part of ticket into OCTET STRING;
-        new_tkt.enc-part := encrypt OCTET STRING
-                using etype_for_key(server.key), server.key, server.p_kvno;
-
-        /* Start processing the response */
-
-        resp.pvno := 5;
-        resp.msg-type := KRB_AS_REP;
-        resp.cname := req.cname;
-        resp.crealm := req.realm;
-        resp.ticket := new_tkt;
-
-        resp.key := new_tkt.session;
-        resp.last-req := fetch_last_request_info(client);
-        resp.nonce := req.nonce;
-        resp.key-expiration := client.expiration;
-        resp.flags := new_tkt.flags;
-
-        resp.authtime := new_tkt.authtime;
-        resp.starttime := new_tkt.starttime;
-        resp.endtime := new_tkt.endtime;
-
-        if (new_tkt.flags.RENEWABLE) then
-                resp.renew-till := new_tkt.renew-till;
-        endif
-
-        resp.realm := new_tkt.realm;
-        resp.sname := new_tkt.sname;
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-        resp.caddr := new_tkt.caddr;
-
-        encode body of reply into OCTET STRING;
-
-        resp.enc-part := encrypt OCTET STRING
-                         using use_etype, client.key, client.p_kvno;
-        send(resp);
-
-A.3. KRB_AS_REP verification
-
-        decode response into resp;
-
-        if (resp.msg-type = KRB_ERROR) then
-                if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then
-                        set pa_enc_timestamp_required;
-                        goto KRB_AS_REQ;
-                endif
-                process_error(resp);
-                return;
-        endif
-
-        /* On error, discard the response, and zero the session key */
-        /* from the response immediately */
-
-        key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
-                                 resp.padata);
-        unencrypted part of resp := decode of decrypt of resp.enc-part
-                                using resp.enc-part.etype and key;
-        zero(key);
-
-        if (common_as_rep_tgs_rep_checks fail) then
-                destroy resp.key;
-                return error;
-        endif
-
-        if near(resp.princ_exp) then
-                print(warning message);
-        endif
-        save_for_later(ticket,session,client,server,times,flags);
-
-A.4. KRB_AS_REP and KRB_TGS_REP common checks
-
-        if (decryption_error() or
-            (req.cname != resp.cname) or
-            (req.realm != resp.crealm) or
-            (req.sname != resp.sname) or
-            (req.realm != resp.realm) or
-            (req.nonce != resp.nonce) or
-            (req.addresses != resp.caddr)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-        /* make sure no flags are set that shouldn't be, and that all that */
-        /* should be are set                                               */
-        if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-        if ((req.from = 0) and
-            (resp.starttime is not within allowable skew)) then
-                destroy resp.key;
-                return KRB_AP_ERR_SKEW;
-        endif
-        if ((req.from != 0) and (req.from != resp.starttime)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-        if ((req.till != 0) and (resp.endtime > req.till)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-        if ((req.kdc-options.RENEWABLE is set) and
-            (req.rtime != 0) and (resp.renew-till > req.rtime)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-        if ((req.kdc-options.RENEWABLE-OK is set) and
-            (resp.flags.RENEWABLE) and
-            (req.till != 0) and
-            (resp.renew-till > req.till)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-A.5. KRB_TGS_REQ generation
-
-        /* Note that make_application_request might have to recursivly     */
-        /* call this routine to get the appropriate ticket-granting ticket */
-
-        request.pvno := protocol version; /* pvno = 5 */
-        request.msg-type := message type; /* type = KRB_TGS_REQ */
-
-        body.kdc-options := users's preferences;
-        /* If the TGT is not for the realm of the end-server  */
-        /* then the sname will be for a TGT for the end-realm */
-        /* and the realm of the requested ticket (body.realm) */
-        /* will be that of the TGS to which the TGT we are    */
-        /* sending applies                                    */
-        body.sname := service's name;
-        body.realm := service's realm;
-
-        if (body.kdc-options.POSTDATED is set) then
-                body.from := requested starting time;
-        else
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-                omit body.from;
-        endif
-        body.till := requested end time;
-        if (body.kdc-options.RENEWABLE is set) then
-                body.rtime := requested final renewal time;
-        endif
-        body.nonce := random_nonce();
-        body.etype := requested etypes;
-        if (user supplied addresses) then
-                body.addresses := user's addresses;
-        else
-                omit body.addresses;
-        endif
-
-        body.enc-authorization-data := user-supplied data;
-        if (body.kdc-options.ENC-TKT-IN-SKEY) then
-                body.additional-tickets_ticket := second TGT;
-        endif
-
-        request.req-body := body;
-        check := generate_checksum (req.body,checksumtype);
-
-        request.padata[0].padata-type := PA-TGS-REQ;
-        request.padata[0].padata-value := create a KRB_AP_REQ using
-                                      the TGT and checksum
-
-        /* add in any other padata as required/supplied */
-
-        kerberos := lookup(name of local kerberose server (or servers));
-        send(packet,kerberos);
-
-        wait(for response);
-        if (timed_out) then
-                retry or use alternate server;
-        endif
-
-A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation
-
-        /* note that reading the application request requires first
-        determining the server for which a ticket was issued, and choosing the
-        correct key for decryption.  The name of the server appears in the
-        plaintext part of the ticket. */
-
-        if (no KRB_AP_REQ in req.padata) then
-                error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
-        endif
-        verify KRB_AP_REQ in req.padata;
-
-        /* Note that the realm in which the Kerberos server is operating is
-        determined by the instance from the ticket-granting ticket.  The realm
-        in the ticket-granting ticket is the realm under which the ticket
-        granting ticket was issued.  It is possible for a single Kerberos
-        server to support more than one realm. */
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-        auth_hdr := KRB_AP_REQ;
-        tgt := auth_hdr.ticket;
-
-        if (tgt.sname is not a TGT for local realm and is not req.sname) then
-                error_out(KRB_AP_ERR_NOT_US);
-
-        realm := realm_tgt_is_for(tgt);
-
-        decode remainder of request;
-
-        if (auth_hdr.authenticator.cksum is missing) then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-
-        if (auth_hdr.authenticator.cksum type is not supported) then
-                error_out(KDC_ERR_SUMTYPE_NOSUPP);
-        endif
-        if (auth_hdr.authenticator.cksum is not both collision-proof and keyed) then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-
-        set computed_checksum := checksum(req);
-        if (computed_checksum != auth_hdr.authenticatory.cksum) then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        server := lookup(req.sname,realm);
-
-        if (!server) then
-                if (is_foreign_tgt_name(req.sname)) then
-                        server := best_intermediate_tgs(req.sname);
-                else
-                        /* no server in Database */
-                        error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
-                endif
-        endif
-
-        session := generate_random_session_key();
-
-        use_etype := first supported etype in req.etypes;
-
-        if (no support for req.etypes) then
-                error_out(KDC_ERR_ETYPE_NOSUPP);
-        endif
-
-        new_tkt.vno := ticket version; /* = 5 */
-        new_tkt.sname := req.sname;
-        new_tkt.srealm := realm;
-        reset all flags in new_tkt.flags;
-
-        /* It should be noted that local policy may affect the  */
-        /* processing of any of these flags.  For example, some */
-        /* realms may refuse to issue renewable tickets         */
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-        new_tkt.caddr := tgt.caddr;
-        resp.caddr := NULL; /* We only include this if they change */
-        if (req.kdc-options.FORWARDABLE is set) then
-                if (tgt.flags.FORWARDABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.FORWARDABLE;
-        endif
-        if (req.kdc-options.FORWARDED is set) then
-                if (tgt.flags.FORWARDABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.FORWARDED;
-                new_tkt.caddr := req.addresses;
-                resp.caddr := req.addresses;
-        endif
-        if (tgt.flags.FORWARDED is set) then
-                set new_tkt.flags.FORWARDED;
-        endif
-
-        if (req.kdc-options.PROXIABLE is set) then
-                if (tgt.flags.PROXIABLE is reset)
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.PROXIABLE;
-        endif
-        if (req.kdc-options.PROXY is set) then
-                if (tgt.flags.PROXIABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.PROXY;
-                new_tkt.caddr := req.addresses;
-                resp.caddr := req.addresses;
-        endif
-
-        if (req.kdc-options.ALLOW-POSTDATE is set) then
-                if (tgt.flags.MAY-POSTDATE is reset)
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.MAY-POSTDATE;
-        endif
-        if (req.kdc-options.POSTDATED is set) then
-                if (tgt.flags.MAY-POSTDATE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.POSTDATED;
-                set new_tkt.flags.INVALID;
-                if (against_postdate_policy(req.from)) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-                new_tkt.starttime := req.from;
-        endif
-
-        if (req.kdc-options.VALIDATE is set) then
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-                if (tgt.flags.INVALID is reset) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-                if (tgt.starttime > kdc_time) then
-                        error_out(KRB_AP_ERR_NYV);
-                endif
-                if (check_hot_list(tgt)) then
-                        error_out(KRB_AP_ERR_REPEAT);
-                endif
-                tkt := tgt;
-                reset new_tkt.flags.INVALID;
-        endif
-
-        if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
-                             and those already processed) is set) then
-                error_out(KDC_ERR_BADOPTION);
-        endif
-
-        new_tkt.authtime := tgt.authtime;
-
-        if (req.kdc-options.RENEW is set) then
-          /* Note that if the endtime has already passed, the ticket would  */
-          /* have been rejected in the initial authentication stage, so     */
-          /* there is no need to check again here                           */
-                if (tgt.flags.RENEWABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                if (tgt.renew-till < kdc_time) then
-                        error_out(KRB_AP_ERR_TKT_EXPIRED);
-                endif
-                tkt := tgt;
-                new_tkt.starttime := kdc_time;
-                old_life := tgt.endttime - tgt.starttime;
-                new_tkt.endtime := min(tgt.renew-till,
-                                       new_tkt.starttime + old_life);
-        else
-                new_tkt.starttime := kdc_time;
-                if (req.till = 0) then
-                        till := infinity;
-                else
-                        till := req.till;
-                endif
-                new_tkt.endtime := min(till,
-                                       new_tkt.starttime+client.max_life,
-                                       new_tkt.starttime+server.max_life,
-                                       new_tkt.starttime+max_life_for_realm,
-                                       tgt.endtime);
-
-                if ((req.kdc-options.RENEWABLE-OK is set) and
-                    (new_tkt.endtime < req.till) and
-                    (tgt.flags.RENEWABLE is set) then
-                        /* we set the RENEWABLE option for later processing */
-                        set req.kdc-options.RENEWABLE;
-                        req.rtime := min(req.till, tgt.renew-till);
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-                endif
-        endif
-
-        if (req.rtime = 0) then
-                rtime := infinity;
-        else
-                rtime := req.rtime;
-        endif
-
-        if ((req.kdc-options.RENEWABLE is set) and
-            (tgt.flags.RENEWABLE is set)) then
-                set new_tkt.flags.RENEWABLE;
-                new_tkt.renew-till := min(rtime,
-                                          new_tkt.starttime+client.max_rlife,
-                                          new_tkt.starttime+server.max_rlife,
-                                          new_tkt.starttime+max_rlife_for_realm,
-                                          tgt.renew-till);
-        else
-                new_tkt.renew-till := OMIT; /* leave the renew-till field out */
-        endif
-        if (req.enc-authorization-data is present) then
-                decrypt req.enc-authorization-data into decrypted_authorization_data
-                        using auth_hdr.authenticator.subkey;
-                if (decrypt_error()) then
-                        error_out(KRB_AP_ERR_BAD_INTEGRITY);
-                endif
-        endif
-        new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data +
-                                 decrypted_authorization_data;
-
-        new_tkt.key := session;
-        new_tkt.crealm := tgt.crealm;
-        new_tkt.cname := req.auth_hdr.ticket.cname;
-
-        if (realm_tgt_is_for(tgt) := tgt.realm) then
-                /* tgt issued by local realm */
-                new_tkt.transited := tgt.transited;
-        else
-                /* was issued for this realm by some other realm */
-                if (tgt.transited.tr-type not supported) then
-                        error_out(KDC_ERR_TRTYPE_NOSUPP);
-                endif
-                new_tkt.transited := compress_transited(tgt.transited + tgt.realm)
-                /* Don't check tranited field if TGT for foreign realm,
-                 * or requested not to check */
-                if (is_not_foreign_tgt_name(new_tkt.server)
-                   && req.kdc-options.DISABLE-TRANSITED-CHECK not set) then
-                        /* Check it, so end-server does not have to
-                         * but don't fail, end-server may still accept it */
-                        if (check_transited_field(new_tkt.transited) == OK)
-                              set new_tkt.flags.TRANSITED-POLICY-CHECKED;
-                        endif
-                endif
-        endif
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-        encode encrypted part of new_tkt into OCTET STRING;
-        if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
-                if (server not specified) then
-                        server = req.second_ticket.client;
-                endif
-                if ((req.second_ticket is not a TGT) or
-                    (req.second_ticket.client != server)) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-
-                new_tkt.enc-part := encrypt OCTET STRING using
-                        using etype_for_key(second-ticket.key), second-ticket.key;
-        else
-                new_tkt.enc-part := encrypt OCTET STRING
-                        using etype_for_key(server.key), server.key, server.p_kvno;
-        endif
-
-        resp.pvno := 5;
-        resp.msg-type := KRB_TGS_REP;
-        resp.crealm := tgt.crealm;
-        resp.cname := tgt.cname;
-        resp.ticket := new_tkt;
-
-        resp.key := session;
-        resp.nonce := req.nonce;
-        resp.last-req := fetch_last_request_info(client);
-        resp.flags := new_tkt.flags;
-
-        resp.authtime := new_tkt.authtime;
-        resp.starttime := new_tkt.starttime;
-        resp.endtime := new_tkt.endtime;
-
-        omit resp.key-expiration;
-
-        resp.sname := new_tkt.sname;
-        resp.realm := new_tkt.realm;
-
-        if (new_tkt.flags.RENEWABLE) then
-                resp.renew-till := new_tkt.renew-till;
-        endif
-
-        encode body of reply into OCTET STRING;
-
-        if (req.padata.authenticator.subkey)
-                resp.enc-part := encrypt OCTET STRING using use_etype,
-                        req.padata.authenticator.subkey;
-        else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key;
-
-        send(resp);
-
-A.7. KRB_TGS_REP verification
-
-        decode response into resp;
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-        if (resp.msg-type = KRB_ERROR) then
-                process_error(resp);
-                return;
-        endif
-
-        /* On error, discard the response, and zero the session key from
-        the response immediately */
-
-        if (req.padata.authenticator.subkey)
-                unencrypted part of resp := decode of decrypt of resp.enc-part
-                        using resp.enc-part.etype and subkey;
-        else unencrypted part of resp := decode of decrypt of resp.enc-part
-                                using resp.enc-part.etype and tgt's session key;
-        if (common_as_rep_tgs_rep_checks fail) then
-                destroy resp.key;
-                return error;
-        endif
-
-        check authorization_data as necessary;
-        save_for_later(ticket,session,client,server,times,flags);
-
-A.8. Authenticator generation
-
-        body.authenticator-vno := authenticator vno; /* = 5 */
-        body.cname, body.crealm := client name;
-        if (supplying checksum) then
-                body.cksum := checksum;
-        endif
-        get system_time;
-        body.ctime, body.cusec := system_time;
-        if (selecting sub-session key) then
-                select sub-session key;
-                body.subkey := sub-session key;
-        endif
-        if (using sequence numbers) then
-                select initial sequence number;
-                body.seq-number := initial sequence;
-        endif
-
-A.9. KRB_AP_REQ generation
-
-        obtain ticket and session_key from cache;
-
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_AP_REQ */
-
-        if (desired(MUTUAL_AUTHENTICATION)) then
-                set packet.ap-options.MUTUAL-REQUIRED;
-        else
-                reset packet.ap-options.MUTUAL-REQUIRED;
-        endif
-        if (using session key for ticket) then
-                set packet.ap-options.USE-SESSION-KEY;
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-        else
-                reset packet.ap-options.USE-SESSION-KEY;
-        endif
-        packet.ticket := ticket; /* ticket */
-        generate authenticator;
-        encode authenticator into OCTET STRING;
-        encrypt OCTET STRING into packet.authenticator using session_key;
-
-A.10. KRB_AP_REQ verification
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_AP_REQ) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        if (packet.ticket.tkt_vno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.ap_options.USE-SESSION-KEY is set) then
-                retrieve session key from ticket-granting ticket for
-                 packet.ticket.{sname,srealm,enc-part.etype};
-        else
-                retrieve service key for
-                 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
-        endif
-        if (no_key_available) then
-                if (cannot_find_specified_skvno) then
-                        error_out(KRB_AP_ERR_BADKEYVER);
-                else
-                        error_out(KRB_AP_ERR_NOKEY);
-                endif
-        endif
-        decrypt packet.ticket.enc-part into decr_ticket using retrieved key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        decrypt packet.authenticator into decr_authenticator
-                using decr_ticket.key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        if (decr_authenticator.{cname,crealm} !=
-            decr_ticket.{cname,crealm}) then
-                error_out(KRB_AP_ERR_BADMATCH);
-        endif
-        if (decr_ticket.caddr is present) then
-                if (sender_address(packet) is not in decr_ticket.caddr) then
-                        error_out(KRB_AP_ERR_BADADDR);
-                endif
-        elseif (application requires addresses) then
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if (not in_clock_skew(decr_authenticator.ctime,
-                              decr_authenticator.cusec)) then
-                error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then
-                error_out(KRB_AP_ERR_REPEAT);
-        endif
-        save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
-        get system_time;
-        if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
-            (decr_ticket.flags.INVALID is set)) then
-                /* it hasn't yet become valid */
-                error_out(KRB_AP_ERR_TKT_NYV);
-        endif
-        if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
-                error_out(KRB_AP_ERR_TKT_EXPIRED);
-        endif
-        if (decr_ticket.transited) then
-            /* caller may ignore the TRANSITED-POLICY-CHECKED and do
-             * check anyway */
-            if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then
-                 if (check_transited_field(decr_ticket.transited) then
-                      error_out(KDC_AP_PATH_NOT_ACCPETED);
-                 endif
-            endif
-        endif
-        /* caller must check decr_ticket.flags for any pertinent details */
-        return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
-
-A.11. KRB_AP_REP generation
-
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_AP_REP */
-
-        body.ctime := packet.ctime;
-        body.cusec := packet.cusec;
-        if (selecting sub-session key) then
-                select sub-session key;
-                body.subkey := sub-session key;
-        endif
-        if (using sequence numbers) then
-                select initial sequence number;
-                body.seq-number := initial sequence;
-        endif
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part;
-
-A.12. KRB_AP_REP verification
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_AP_REP) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        cleartext := decrypt(packet.enc-part) using ticket's session key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        if (cleartext.ctime != authenticator.ctime) then
-                error_out(KRB_AP_ERR_MUT_FAIL);
-        endif
-        if (cleartext.cusec != authenticator.cusec) then
-                error_out(KRB_AP_ERR_MUT_FAIL);
-        endif
-        if (cleartext.subkey is present) then
-                save cleartext.subkey for future use;
-        endif
-        if (cleartext.seq-number is present) then
-                save cleartext.seq-number for future verifications;
-        endif
-        return(AUTHENTICATION_SUCCEEDED);
-
-A.13. KRB_SAFE generation
-
-        collect user data in buffer;
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_SAFE */
-
-        body.user-data := buffer; /* DATA */
-        if (using timestamp) then
-                get system_time;
-                body.timestamp, body.usec := system_time;
-        endif
-        if (using sequence numbers) then
-                body.seq-number := sequence number;
-        endif
-        body.s-address := sender host addresses;
-        if (only one recipient) then
-                body.r-address := recipient host address;
-        endif
-        checksum.cksumtype := checksum type;
-        compute checksum over body;
-        checksum.checksum := checksum value; /* checksum.checksum */
-        packet.cksum := checksum;
-        packet.safe-body := body;
-
-A.14. KRB_SAFE verification
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_SAFE) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        if (packet.checksum.cksumtype is not both collision-proof and keyed) then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-        if (safe_priv_common_checks_ok(packet)) then
-                set computed_checksum := checksum(packet.body);
-                if (computed_checksum != packet.checksum) then
-                        error_out(KRB_AP_ERR_MODIFIED);
-                endif
-                return (packet, PACKET_IS_GENUINE);
-        else
-                return common_checks_error;
-        endif
-
-A.15. KRB_SAFE and KRB_PRIV common checks
-
-        if (packet.s-address != O/S_sender(packet)) then
-                /* O/S report of sender not who claims to have sent it */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if ((packet.r-address is present) and
-            (packet.r-address != local_host_address)) then
-                /* was not sent to proper place */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if (((packet.timestamp is present) and
-             (not in_clock_skew(packet.timestamp,packet.usec))) or
-            (packet.timestamp is not present and timestamp expected)) then
-                error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
-                error_out(KRB_AP_ERR_REPEAT);
-        endif
-
-        if (((packet.seq-number is present) and
-             ((not in_sequence(packet.seq-number)))) or
-            (packet.seq-number is not present and sequence expected)) then
-                error_out(KRB_AP_ERR_BADORDER);
-        endif
-        if (packet.timestamp not present and packet.seq-number not present)
-        then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        save_identifier(packet.{timestamp,usec,s-address},
-                        sender_principal(packet));
-
-        return PACKET_IS_OK;
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-A.16. KRB_PRIV generation
-
-        collect user data in buffer;
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_PRIV */
-
-        packet.enc-part.etype := encryption type;
-
-        body.user-data := buffer;
-        if (using timestamp) then
-                get system_time;
-                body.timestamp, body.usec := system_time;
-        endif
-        if (using sequence numbers) then
-                body.seq-number := sequence number;
-        endif
-        body.s-address := sender host addresses;
-        if (only one recipient) then
-                body.r-address := recipient host address;
-        endif
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part.cipher;
-
-A.17. KRB_PRIV verification
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_PRIV) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-
-        cleartext := decrypt(packet.enc-part) using negotiated key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-
-        if (safe_priv_common_checks_ok(cleartext)) then
-                return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
-        else
-                return common_checks_error;
-        endif
-
-A.18. KRB_CRED generation
-
-        invoke KRB_TGS; /* obtain tickets to be provided to peer */
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_CRED */
-
-        for (tickets[n] in tickets to be forwarded) do
-                packet.tickets[n] = tickets[n].ticket;
-        done
-
-        packet.enc-part.etype := encryption type;
-
-        for (ticket[n] in tickets to be forwarded) do
-                body.ticket-info[n].key = tickets[n].session;
-                body.ticket-info[n].prealm = tickets[n].crealm;
-                body.ticket-info[n].pname = tickets[n].cname;
-                body.ticket-info[n].flags = tickets[n].flags;
-                body.ticket-info[n].authtime = tickets[n].authtime;
-                body.ticket-info[n].starttime = tickets[n].starttime;
-                body.ticket-info[n].endtime = tickets[n].endtime;
-                body.ticket-info[n].renew-till = tickets[n].renew-till;
-                body.ticket-info[n].srealm = tickets[n].srealm;
-                body.ticket-info[n].sname = tickets[n].sname;
-                body.ticket-info[n].caddr = tickets[n].caddr;
-        done
-
-        get system_time;
-        body.timestamp, body.usec := system_time;
-
-        if (using nonce) then
-                body.nonce := nonce;
-        endif
-
-        if (using s-address) then
-                body.s-address := sender host addresses;
-        endif
-        if (limited recipients) then
-                body.r-address := recipient host address;
-        endif
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part.cipher
-               using negotiated encryption key;
-
-A.19. KRB_CRED verification
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_CRED) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-        endif
-
-        cleartext := decrypt(packet.enc-part) using negotiated key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        if ((packet.r-address is present or required) and
-           (packet.s-address != O/S_sender(packet)) then
-                /* O/S report of sender not who claims to have sent it */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if ((packet.r-address is present) and
-            (packet.r-address != local_host_address)) then
-                /* was not sent to proper place */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if (not in_clock_skew(packet.timestamp,packet.usec)) then
-                error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
-                error_out(KRB_AP_ERR_REPEAT);
-        endif
-        if (packet.nonce is required or present) and
-           (packet.nonce != expected-nonce) then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        for (ticket[n] in tickets that were forwarded) do
-                save_for_later(ticket[n],key[n],principal[n],
-                               server[n],times[n],flags[n]);
-        return
-
-A.20. KRB_ERROR generation
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_ERROR */
-
-        get system_time;
-        packet.stime, packet.susec := system_time;
-        packet.realm, packet.sname := server name;
-
-        if (client time available) then
-                packet.ctime, packet.cusec := client_time;
-        endif
-        packet.error-code := error code;
-        if (client name available) then
-                packet.cname, packet.crealm := client name;
-        endif
-        if (error text available) then
-                packet.e-text := error text;
-        endif
-        if (error data available) then
-                packet.e-data := error data;
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-        endif
-
-B. Definition of common authorization data elements
-
-This appendix contains the definitions of common authorization data
-elements. These common authorization data elements are recursivly defined,
-meaning the ad-data for these types will itself contain a sequence of
-authorization data whose interpretation is affected by the encapsulating
-element. Depending on the meaning of the encapsulating element, the
-encapsulated elements may be ignored, might be interpreted as issued
-directly by the KDC, or they might be stored in a separate plaintext part of
-the ticket. The types of the encapsulating elements are specified as part of
-the Kerberos specification ebcause the behavior based on these values should
-be understood across implementations whereas other elements need only be
-understood by the applications which they affect.
-
-In the definitions that follow, the value of the ad-type for the element
-will be specified in the subsection number, and the value of the ad-data
-will be as shown in the ASN.1 structure that follows the subsection heading.
-
-B.1. KDC Issued
-
-AD-KDCIssued   SEQUENCE {
-               ad-checksum[0]    Checksum,
-                i-realm[1]       Realm OPTIONAL,
-                i-sname[2]       PrincipalName OPTIONAL,
-               elements[3]       AuthorizationData.
-}
-
-ad-checksum
-     A checksum over the elements field using a cryptographic checksum
-     method that is identical to the checksum used to protect the ticket
-     itself (i.e. using the same hash function and the same encryption
-     algorithm used to encrypt the ticket) and using a key derived from the
-     same key used to protect the ticket.
-i-realm, i-sname
-     The name of the issuing principal if different from the KDC itself.
-     This field would be used when the KDC can verify the authenticity of
-     elements signed by the issuing principal and it allows this KDC to
-     notify the application server of the validity of those elements.
-elements
-     A sequence of authorization data elements issued by the KDC.
-
-The KDC-issued ad-data field is intended to provide a means for Kerberos
-principal credentials to embed within themselves privilege attributes and
-other mechanisms for positive authorization, amplifying the priveleges of
-the principal beyond what can be done using a credentials without such an
-a-data element.
-
-This can not be provided without this element because the definition of the
-authorization-data field allows elements to be added at will by the bearer
-of a TGT at the time that they request service tickets and elements may also
-be added to a delegated ticket by inclusion in the authenticator.
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-For KDC-issued elements this is prevented because the elements are signed by
-the KDC by including a checksum encrypted using the server's key (the same
-key used to encrypt the ticket - or a key derived from that key). Elements
-encapsulated with in the KDC-issued element will be ignored by the
-application server if this "signature" is not present. Further, elements
-encapsulated within this element from a ticket granting ticket may be
-interpreted by the KDC, and used as a basis according to policy for
-including new signed elements within derivative tickets, but they will not
-be copied to a derivative ticket directly. If they are copied directly to a
-derivative ticket by a KDC that is not aware of this element, the signature
-will not be correct for the application ticket elements, and the field will
-be ignored by the application server.
-
-This element and the elements it encapulates may be safely ignored by
-applications, application servers, and KDCs that do not implement this
-element.
-
-B.2. Intended for server
-
-AD-INTENDED-FOR-SERVER   SEQUENCE {
-         intended-server[0]     SEQUENCE OF PrincipalName
-         elements[1]            AuthorizationData
-}
-
-AD elements encapsulated within the intended-for-server element may be
-ignored if the application server is not in the list of principal names of
-intended servers. Further, a KDC issuing a ticket for an application server
-can remove this element if the application server is not in the list of
-intended servers.
-
-Application servers should check for their principal name in the
-intended-server field of this element. If their principal name is not found,
-this element should be ignored. If found, then the encapsulated elements
-should be evaluated in the same manner as if they were present in the top
-level authorization data field. Applications and application servers that do
-not implement this element should reject tickets that contain authorization
-data elements of this type.
-
-B.3. Intended for application class
-
-AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { intended-application-class[0]
-SEQUENCE OF GeneralString elements[1] AuthorizationData } AD elements
-encapsulated within the intended-for-application-class element may be
-ignored if the application server is not in one of the named classes of
-application servers. Examples of application server classes include
-"FILESYSTEM", and other kinds of servers.
-
-This element and the elements it encapulates may be safely ignored by
-applications, application servers, and KDCs that do not implement this
-element.
-
-B.4. If relevant
-
-AD-IF-RELEVANT   AuthorizationData
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-AD elements encapsulated within the if-relevant element are intended for
-interpretation only by application servers that understand the particular
-ad-type of the embedded element. Application servers that do not understand
-the type of an element embedded within the if-relevant element may ignore
-the uninterpretable element. This element promotes interoperability across
-implementations which may have local extensions for authorization.
-
-B.5. And-Or
-
-AD-AND-OR           SEQUENCE {
-                        condition-count[0]    INTEGER,
-                        elements[1]           AuthorizationData
-}
-
-When restrictive AD elements encapsulated within the and-or element are
-encountered, only the number specified in condition-count of the
-encapsulated conditions must be met in order to satisfy this element. This
-element may be used to implement an "or" operation by setting the
-condition-count field to 1, and it may specify an "and" operation by setting
-the condition count to the number of embedded elements. Application servers
-that do not implement this element must reject tickets that contain
-authorization data elements of this type.
-
-B.6. Mandatory ticket extensions
-
-AD-Mandatory-Ticket-Extensions   Checksum
-
-An authorization data element of type mandatory-ticket-extensions specifies
-a collision-proof checksum using the same has angorithm used to protect the
-integrity of the ticket itself. This checksum will be calculated over the
-entire extensions field. If there are more than one extension, all will be
-covered by the checksum. This restriction indicates that the ticket should
-not be accepted if the checksum does not match that calculated over the
-ticket extensions. Application servers that do not implement this element
-must reject tickets that contain authorization data elements of this type.
-
-B.7. Authorization Data in ticket extensions
-
-AD-IN-Ticket-Extensions   Checksum
-
-An authorization data element of type in-ticket-extensions specifies a
-collision-proof checksum using the same has angorithm used to protect the
-integrity of the ticket itself. This checksum is calculated over a separate
-external AuthorizationData field carried in the ticket extensions.
-Application servers that do not implement this element must reject tickets
-that contain authorization data elements of this type. Application servers
-that do implement this element will search the ticket extensions for
-authorization data fields, calculate the specified checksum over each
-authorization data field and look for one matching the checksum in this
-in-ticket-extensions element. If not found, then the ticket must be
-rejected. If found, the corresponding authorization data elements will be
-interpreted in the same manner as if they were contained in the top level
-authorization data field.
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-Note that if multiple external authorization data fields are present in a
-ticket, each will have a corresponding element of type in-ticket-extensions
-in the top level authorization data field, and the external entries will be
-linked to the corresponding element by their checksums.
-
-C. Definition of common ticket extensions
-
-This appendix contains the definitions of common ticket extensions. Support
-for these extensions is optional. However, certain extensions have
-associated authorization data elements that may require rejection of a
-ticket containing an extension by application servers that do not implement
-the particular extension. Other extensions have been defined beyond those
-described in this specification. Such extensions are described elswhere and
-for some of those extensions the reserved number may be found in the list of
-constants.
-
-It is known that older versions of Kerberos did not support this field, and
-that some clients will strip this field from a ticket when they parse and
-then reassemble a ticket as it is passed to the application servers. The
-presence of the extension will not break such clients, but any functionaly
-dependent on the extensions will not work when such tickets are handled by
-old clients. In such situations, some implementation may use alternate
-methods to transmit the information in the extensions field.
-
-C.1. Null ticket extension
-
-TE-NullExtension   OctetString -- The empty Octet String
-
-The te-data field in the null ticket extension is an octet string of lenght
-zero. This extension may be included in a ticket granting ticket so that the
-KDC can determine on presentation of the ticket granting ticket whether the
-client software will strip the extensions field.
-
-C.2. External Authorization Data
-
-TE-ExternalAuthorizationData   AuthorizationData
-
-The te-data field in the external authorization data ticket extension is
-field of type AuthorizationData containing one or more authorization data
-elements. If present, a corresponding authorization data element will be
-present in the primary authorization data for the ticket and that element
-will contain a checksum of the external authorization data ticket extension.
-----------------------------------------------------------------------------
-[TM] Project Athena, Athena, and Kerberos are trademarks of the
-Massachusetts Institute of Technology (MIT). No commercial use of these
-trademarks may be made without prior written permission of MIT.
-
-[1] Note, however, that many applications use Kerberos' functions only upon
-the initiation of a stream-based network connection. Unless an application
-subsequently provides integrity protection for the data stream, the identity
-verification applies only to the initiation of the connection, and does not
-guarantee that subsequent messages on the connection originate from the same
-principal.
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-[2] Secret and private are often used interchangeably in the literature. In
-our usage, it takes two (or more) to share a secret, thus a shared DES key
-is a secret key. Something is only private when no one but its owner knows
-it. Thus, in public key cryptosystems, one has a public and a private key.
-
-[3] Of course, with appropriate permission the client could arrange
-registration of a separately-named prin- cipal in a remote realm, and engage
-in normal exchanges with that realm's services. However, for even small
-numbers of clients this becomes cumbersome, and more automatic methods as
-described here are necessary.
-
-[4] Though it is permissible to request or issue tick- ets with no network
-addresses specified.
-
-[5] The password-changing request must not be honored unless the requester
-can provide the old password (the user's current secret key). Otherwise, it
-would be possible for someone to walk up to an unattended ses- sion and
-change another user's password.
-
-[6] To authenticate a user logging on to a local system, the credentials
-obtained in the AS exchange may first be used in a TGS exchange to obtain
-credentials for a local server. Those credentials must then be verified by a
-local server through successful completion of the Client/Server exchange.
-
-[7] "Random" means that, among other things, it should be impossible to
-guess the next session key based on knowledge of past session keys. This can
-only be achieved in a pseudo-random number generator if it is based on
-cryptographic principles. It is more desirable to use a truly random number
-generator, such as one based on measurements of random physical phenomena.
-
-[8] Tickets contain both an encrypted and unencrypted portion, so cleartext
-here refers to the entire unit, which can be copied from one message and
-replayed in another without any cryptographic skill.
-
-[9] Note that this can make applications based on unreliable transports
-difficult to code correctly. If the transport might deliver duplicated
-messages, either a new authenticator must be generated for each retry, or
-the application server must match requests and replies and replay the first
-reply in response to a detected duplicate.
-
-[10] This is used for user-to-user authentication as described in [8].
-
-[11] Note that the rejection here is restricted to authenticators from the
-same principal to the same server. Other client principals communicating
-with the same server principal should not be have their authenticators
-rejected if the time and microsecond fields happen to match some other
-client's authenticator.
-
-[12] In the Kerberos version 4 protocol, the timestamp in the reply was the
-client's timestamp plus one. This is not necessary in version 5 because
-version 5 messages are formatted in such a way that it is not possible to
-create the reply by judicious message surgery (even in encrypted form)
-without knowledge of the appropriate encryption keys.
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-
-[13] Note that for encrypting the KRB_AP_REP message, the sub-session key is
-not used, even if present in the Authenticator.
-
-[14] Implementations of the protocol may wish to provide routines to choose
-subkeys based on session keys and random numbers and to generate a
-negotiated key to be returned in the KRB_AP_REP message.
-
-[15]This can be accomplished in several ways. It might be known beforehand
-(since the realm is part of the principal identifier), it might be stored in
-a nameserver, or it might be obtained from a configura- tion file. If the
-realm to be used is obtained from a nameserver, there is a danger of being
-spoofed if the nameservice providing the realm name is not authenti- cated.
-This might result in the use of a realm which has been compromised, and
-would result in an attacker's ability to compromise the authentication of
-the application server to the client.
-
-[16] If the client selects a sub-session key, care must be taken to ensure
-the randomness of the selected sub- session key. One approach would be to
-generate a random number and XOR it with the session key from the
-ticket-granting ticket.
-
-[17] This allows easy implementation of user-to-user authentication [8],
-which uses ticket-granting ticket session keys in lieu of secret server keys
-in situa- tions where such secret keys could be easily comprom- ised.
-
-[18] For the purpose of appending, the realm preceding the first listed
-realm is considered to be the null realm ("").
-
-[19] For the purpose of interpreting null subfields, the client's realm is
-considered to precede those in the transited field, and the server's realm
-is considered to follow them.
-
-[20] This means that a client and server running on the same host and
-communicating with one another using the KRB_SAFE messages should not share
-a common replay cache to detect KRB_SAFE replays.
-
-[21] The implementation of the Kerberos server need not combine the database
-and the server on the same machine; it is feasible to store the principal
-database in, say, a network name service, as long as the entries stored
-therein are protected from disclosure to and modification by unauthorized
-parties. However, we recommend against such strategies, as they can make
-system management and threat analysis quite complex.
-
-[22] See the discussion of the padata field in section 5.4.2 for details on
-why this can be useful.
-
-[23] Warning for implementations that unpack and repack data structures
-during the generation and verification of embedded checksums: Because any
-checksums applied to data structures must be checked against the original
-data the length of bit strings must be preserved within a data structure
-between the time that a checksum is generated through transmission to the
-time that the checksum is verified.
-
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-[24] It is NOT recommended that this time value be used to adjust the
-workstation's clock since the workstation cannot reliably determine that
-such a KRB_AS_REP actually came from the proper KDC in a timely manner.
-
-[25] Note, however, that if the time is used as the nonce, one must make
-sure that the workstation time is monotonically increasing. If the time is
-ever reset backwards, there is a small, but finite, probability that a nonce
-will be reused.
-
-[27] An application code in the encrypted part of a message provides an
-additional check that the message was decrypted properly.
-
-[29] An application code in the encrypted part of a message provides an
-additional check that the message was decrypted properly.
-
-[31] An application code in the encrypted part of a message provides an
-additional check that the message was decrypted properly.
-
-[32] If supported by the encryption method in use, an initialization vector
-may be passed to the encryption procedure, in order to achieve proper cipher
-chaining. The initialization vector might come from the last block of the
-ciphertext from the previous KRB_PRIV message, but it is the application's
-choice whether or not to use such an initialization vector. If left out, the
-default initialization vector for the encryption algorithm will be used.
-
-[33] This prevents an attacker who generates an incorrect AS request from
-obtaining verifiable plaintext for use in an off-line password guessing
-attack.
-
-[35] In the above specification, UNTAGGED OCTET STRING(length) is the
-notation for an octet string with its tag and length removed. It is not a
-valid ASN.1 type. The tag bits and length must be removed from the
-confounder since the purpose of the confounder is so that the message starts
-with random data, but the tag and its length are fixed. For other fields,
-the length and tag would be redundant if they were included because they are
-specified by the encryption type. [36] The ordering of the fields in the
-CipherText is important. Additionally, messages encoded in this format must
-include a length as part of the msg-seq field. This allows the recipient to
-verify that the message has not been truncated. Without a length, an
-attacker could use a chosen plaintext attack to generate a message which
-could be truncated, while leaving the checksum intact. Note that if the
-msg-seq is an encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length
-is part of that encoding.
-
-[37] In some cases, it may be necessary to use a different "mix-in" string
-for compatibility reasons; see the discussion of padata in section 5.4.2.
-
-[38] In some cases, it may be necessary to use a different "mix-in" string
-for compatibility reasons; see the discussion of padata in section 5.4.2.
-
-[39] A variant of the key is used to limit the use of a key to a particular
-function, separating the functions of generating a checksum from other
-encryption performed using the session key. The constant F0F0F0F0F0F0F0F0
-was chosen because it maintains key parity. The properties of DES precluded
-
-
-draft-ietf-cat-kerberos-r-01                        Expires 21 May 1998
-
-the use of the complement. The same constant is used for similar purpose in
-the Message Integrity Check in the Privacy Enhanced Mail standard.
-
-[40] This error carries additional information in the e- data field. The
-contents of the e-data field for this message is described in section 5.9.1.
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-revisions-03.txt b/doc/standardisation/draft-ietf-cat-kerberos-revisions-03.txt
deleted file mode 100644
index 06d997d48..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-revisions-03.txt
+++ /dev/null
@@ -1,6766 +0,0 @@
-
-
-
-INTERNET-DRAFT                                          Clifford Neuman
-                                                              John Kohl
-                                                          Theodore Ts'o
-                                                    November 18th, 1998
-
-The Kerberos Network Authentication Service (V5)
-
-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 learn the current status of any Internet-Draft, please check the
-'1id-abstracts.txt' listing contained in the Internet-Drafts Shadow
-Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
-ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
-
-The distribution of this memo is unlimited. It is filed as
-draft-ietf-cat-kerberos-revisions-03.txt, and expires May 18th, 1999. 
-Please send comments to: krb-protocol@MIT.EDU
-
-ABSTRACT
-
-This document provides an overview and specification of Version 5 of the
-Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol
-and its intended use that require more detailed or clearer explanation than
-was provided in RFC1510. This document is intended to provide a detailed
-description of the protocol, suitable for implementation, together with
-descriptions of the appropriate use of protocol messages and fields within
-those messages.
-
-This document is not intended to describe Kerberos to the end user, system
-administrator, or application developer. Higher level papers describing
-Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88],
-are available elsewhere.
-
-OVERVIEW
-
-This INTERNET-DRAFT describes the concepts and model upon which the
-Kerberos network authentication system is based. It also specifies Version
-5 of the Kerberos protocol.
-
-The motivations, goals, assumptions, and rationale behind most design
-decisions are treated cursorily; they are more fully described in a paper
-available in IEEE communications [NT94] and earlier in the Kerberos portion
-of the Athena Technical Plan [MNSS87]. The protocols have been a proposed
-standard and are being considered for advancement for draft standard
-through the IETF standard process. Comments are encouraged on the
-presentation, but only minor refinements to the protocol as implemented or
-extensions that fit within current protocol framework will be considered at
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-this time.
-
-Requests for addition to an electronic mailing list for discussion of
-Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU.
-This mailing list is gatewayed onto the Usenet as the group
-comp.protocols.kerberos. Requests for further information, including
-documents and code availability, may be sent to info-kerberos@MIT.EDU.
-
-BACKGROUND
-
-The Kerberos model is based in part on Needham and Schroeder's trusted
-third-party authentication protocol [NS78] and on modifications suggested
-by Denning and Sacco [DS81]. The original design and implementation of
-Kerberos Versions 1 through 4 was the work of two former Project Athena
-staff members, Steve Miller of Digital Equipment Corporation and Clifford
-Neuman (now at the Information Sciences Institute of the University of
-Southern California), along with Jerome Saltzer, Technical Director of
-Project Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many
-other members of Project Athena have also contributed to the work on
-Kerberos.
-
-Version 5 of the Kerberos protocol (described in this document) has evolved
-from Version 4 based on new requirements and desires for features not
-available in Version 4. The design of Version 5 of the Kerberos protocol
-was led by Clifford Neuman and John Kohl with much input from the
-community. The development of the MIT reference implementation was led at
-MIT by John Kohl and Theodore T'so, with help and contributed code from
-many others. Since RFC1510 was issued, extensions and revisions to the
-protocol have been proposed by many individuals. Some of these proposals
-are reflected in this document. Where such changes involved significant
-effort, the document cites the contribution of the proposer.
-
-Reference implementations of both version 4 and version 5 of Kerberos are
-publicly available and commercial implementations have been developed and
-are widely used. Details on the differences between Kerberos Versions 4 and
-5 can be found in [KNT92].
-
-1. Introduction
-
-Kerberos provides a means of verifying the identities of principals, (e.g.
-a workstation user or a network server) on an open (unprotected) network.
-This is accomplished without relying on assertions by the host operating
-system, without basing trust on host addresses, without requiring physical
-security of all the hosts on the network, and under the assumption that
-packets traveling along the network can be read, modified, and inserted at
-will[1]. Kerberos performs authentication under these conditions as a
-trusted third-party authentication service by using conventional (shared
-secret key [2] cryptography. Kerberos extensions have been proposed and
-implemented that provide for the use of public key cryptography during
-certain phases of the authentication protocol. These extensions provide for
-authentication of users registered with public key certification
-authorities, and allow the system to provide certain benefits of public key
-cryptography in situations where they are needed.
-
-The basic Kerberos authentication process proceeds as follows: A client
-sends a request to the authentication server (AS) requesting 'credentials'
-for a given server. The AS responds with these credentials, encrypted in
-the client's key. The credentials consist of 1) a 'ticket' for the server
-and 2) a temporary encryption key (often called a "session key"). The
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-client transmits the ticket (which contains the client's identity and a
-copy of the session key, all encrypted in the server's key) to the server.
-The session key (now shared by the client and server) is used to
-authenticate the client, and may optionally be used to authenticate the
-server. It may also be used to encrypt further communication between the
-two parties or to exchange a separate sub-session key to be used to encrypt
-further communication.
-
-Implementation of the basic protocol consists of one or more authentication
-servers running on physically secure hosts. The authentication servers
-maintain a database of principals (i.e., users and servers) and their
-secret keys. Code libraries provide encryption and implement the Kerberos
-protocol. In order to add authentication to its transactions, a typical
-network application adds one or two calls to the Kerberos library directly
-or through the Generic Security Services Application Programming Interface,
-GSSAPI, described in separate document. These calls result in the
-transmission of the necessary messages to achieve authentication.
-
-The Kerberos protocol consists of several sub-protocols (or exchanges).
-There are two basic methods by which a client can ask a Kerberos server for
-credentials. In the first approach, the client sends a cleartext request
-for a ticket for the desired server to the AS. The reply is sent encrypted
-in the client's secret key. Usually this request is for a ticket-granting
-ticket (TGT) which can later be used with the ticket-granting server (TGS).
-In the second method, the client sends a request to the TGS. The client
-uses the TGT to authenticate itself to the TGS in the same manner as if it
-were contacting any other application server that requires Kerberos
-authentication. The reply is encrypted in the session key from the TGT.
-Though the protocol specification describes the AS and the TGS as separate
-servers, they are implemented in practice as different protocol entry
-points within a single Kerberos server.
-
-Once obtained, credentials may be used to verify the identity of the
-principals in a transaction, to ensure the integrity of messages exchanged
-between them, or to preserve privacy of the messages. The application is
-free to choose whatever protection may be necessary.
-
-To verify the identities of the principals in a transaction, the client
-transmits the ticket to the application server. Since the ticket is sent
-"in the clear" (parts of it are encrypted, but this encryption doesn't
-thwart replay) and might be intercepted and reused by an attacker,
-additional information is sent to prove that the message originated with
-the principal to whom the ticket was issued. This information (called the
-authenticator) is encrypted in the session key, and includes a timestamp.
-The timestamp proves that the message was recently generated and is not a
-replay. Encrypting the authenticator in the session key proves that it was
-generated by a party possessing the session key. Since no one except the
-requesting principal and the server know the session key (it is never sent
-over the network in the clear) this guarantees the identity of the client.
-
-The integrity of the messages exchanged between principals can also be
-guaranteed using the session key (passed in the ticket and contained in the
-credentials). This approach provides detection of both replay attacks and
-message stream modification attacks. It is accomplished by generating and
-transmitting a collision-proof checksum (elsewhere called a hash or digest
-function) of the client's message, keyed with the session key. Privacy and
-integrity of the messages exchanged between principals can be secured by
-encrypting the data to be passed using the session key contained in the
-ticket or the subsession key found in the authenticator.
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-The authentication exchanges mentioned above require read-only access to
-the Kerberos database. Sometimes, however, the entries in the database must
-be modified, such as when adding new principals or changing a principal's
-key. This is done using a protocol between a client and a third Kerberos
-server, the Kerberos Administration Server (KADM). There is also a protocol
-for maintaining multiple copies of the Kerberos database. Neither of these
-protocols are described in this document.
-
-1.1. Cross-Realm Operation
-
-The Kerberos protocol is designed to operate across organizational
-boundaries. A client in one organization can be authenticated to a server
-in another. Each organization wishing to run a Kerberos server establishes
-its own 'realm'. The name of the realm in which a client is registered is
-part of the client's name, and can be used by the end-service to decide
-whether to honor a request.
-
-By establishing 'inter-realm' keys, the administrators of two realms can
-allow a client authenticated in the local realm to prove its identity to
-servers in other realms[3]. The exchange of inter-realm keys (a separate
-key may be used for each direction) registers the ticket-granting service
-of each realm as a principal in the other realm. A client is then able to
-obtain a ticket-granting ticket for the remote realm's ticket-granting
-service from its local realm. When that ticket-granting ticket is used, the
-remote ticket-granting service uses the inter-realm key (which usually
-differs from its own normal TGS key) to decrypt the ticket-granting ticket,
-and is thus certain that it was issued by the client's own TGS. Tickets
-issued by the remote ticket-granting service will indicate to the
-end-service that the client was authenticated from another realm.
-
-A realm is said to communicate with another realm if the two realms share
-an inter-realm key, or if the local realm shares an inter-realm key with an
-intermediate realm that communicates with the remote realm. An
-authentication path is the sequence of intermediate realms that are
-transited in communicating from one realm to another.
-
-Realms are typically organized hierarchically. Each realm shares a key with
-its parent and a different key with each child. If an inter-realm key is
-not directly shared by two realms, the hierarchical organization allows an
-authentication path to be easily constructed. If a hierarchical
-organization is not used, it may be necessary to consult a database in
-order to construct an authentication path between realms.
-
-Although realms are typically hierarchical, intermediate realms may be
-bypassed to achieve cross-realm authentication through alternate
-authentication paths (these might be established to make communication
-between two realms more efficient). It is important for the end-service to
-know which realms were transited when deciding how much faith to place in
-the authentication process. To facilitate this decision, a field in each
-ticket contains the names of the realms that were involved in
-authenticating the client.
-
-The application server is ultimately responsible for accepting or rejecting
-authentication and should check the transited field. The application server
-may choose to rely on the KDC for the application server's realm to check
-the transited field. The application server's KDC will set the
-TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate
-realms may also check the transited field as they issue
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-ticket-granting-tickets for other realms, but they are encouraged not to do
-so. A client may request that the KDC's not check the transited field by
-setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not
-required to honor this flag.
-
-1.2. Authorization
-
-As an authentication service, Kerberos provides a means of verifying the
-identity of principals on a network. Authentication is usually useful
-primarily as a first step in the process of authorization, determining
-whether a client may use a service, which objects the client is allowed to
-access, and the type of access allowed for each. Kerberos does not, by
-itself, provide authorization. Possession of a client ticket for a service
-provides only for authentication of the client to that service, and in the
-absence of a separate authorization procedure, it should not be considered
-by an application as authorizing the use of that service.
-
-Such separate authorization methods may be implemented as application
-specific access control functions and may be based on files such as the
-application server, or on separately issued authorization credentials such
-as those based on proxies [Neu93] , or on other authorization services.
-
-Applications should not be modified to accept the issuance of a service
-ticket by the Kerberos server (even by an modified Kerberos server) as
-granting authority to use the service, since such applications may become
-vulnerable to the bypass of this authorization check in an environment if
-they interoperate with other KDCs or where other options for application
-authentication (e.g. the PKTAPP proposal) are provided.
-
-1.3. Environmental assumptions
-
-Kerberos imposes a few assumptions on the environment in which it can
-properly function:
-
-   * 'Denial of service' attacks are not solved with Kerberos. There are
-     places in these protocols where an intruder can prevent an application
-     from participating in the proper authentication steps. Detection and
-     solution of such attacks (some of which can appear to be nnot-uncommon
-     'normal' failure modes for the system) is usually best left to the
-     human administrators and users.
-   * Principals must keep their secret keys secret. If an intruder somehow
-     steals a principal's key, it will be able to masquerade as that
-     principal or impersonate any server to the legitimate principal.
-   * 'Password guessing' attacks are not solved by Kerberos. If a user
-     chooses a poor password, it is possible for an attacker to
-     successfully mount an offline dictionary attack by repeatedly
-     attempting to decrypt, with successive entries from a dictionary,
-     messages obtained which are encrypted under a key derived from the
-     user's password.
-   * Each host on the network must have a clock which is 'loosely
-     synchronized' to the time of the other hosts; this synchronization is
-     used to reduce the bookkeeping needs of application servers when they
-     do replay detection. The degree of "looseness" can be configured on a
-     per-server basis, but is typically on the order of 5 minutes. If the
-     clocks are synchronized over the network, the clock synchronization
-     protocol must itself be secured from network attackers.
-   * Principal identifiers are not recycled on a short-term basis. A
-     typical mode of access control will use access control lists (ACLs) to
-     grant permissions to particular principals. If a stale ACL entry
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-     remains for a deleted principal and the principal identifier is
-     reused, the new principal will inherit rights specified in the stale
-     ACL entry. By not re-using principal identifiers, the danger of
-     inadvertent access is removed.
-
-1.4. Glossary of terms
-
-Below is a list of terms used throughout this document.
-
-Authentication
-     Verifying the claimed identity of a principal.
-Authentication header
-     A record containing a Ticket and an Authenticator to be presented to a
-     server as part of the authentication process.
-Authentication path
-     A sequence of intermediate realms transited in the authentication
-     process when communicating from one realm to another.
-Authenticator
-     A record containing information that can be shown to have been
-     recently generated using the session key known only by the client and
-     server.
-Authorization
-     The process of determining whether a client may use a service, which
-     objects the client is allowed to access, and the type of access
-     allowed for each.
-Capability
-     A token that grants the bearer permission to access an object or
-     service. In Kerberos, this might be a ticket whose use is restricted
-     by the contents of the authorization data field, but which lists no
-     network addresses, together with the session key necessary to use the
-     ticket.
-Ciphertext
-     The output of an encryption function. Encryption transforms plaintext
-     into ciphertext.
-Client
-     A process that makes use of a network service on behalf of a user.
-     Note that in some cases a Server may itself be a client of some other
-     server (e.g. a print server may be a client of a file server).
-Credentials
-     A ticket plus the secret session key necessary to successfully use
-     that ticket in an authentication exchange.
-KDC
-     Key Distribution Center, a network service that supplies tickets and
-     temporary session keys; or an instance of that service or the host on
-     which it runs. The KDC services both initial ticket and
-     ticket-granting ticket requests. The initial ticket portion is
-     sometimes referred to as the Authentication Server (or service). The
-     ticket-granting ticket portion is sometimes referred to as the
-     ticket-granting server (or service).
-Kerberos
-     Aside from the 3-headed dog guarding Hades, the name given to Project
-     Athena's authentication service, the protocol used by that service, or
-     the code used to implement the authentication service.
-Plaintext
-     The input to an encryption function or the output of a decryption
-     function. Decryption transforms ciphertext into plaintext.
-Principal
-     A uniquely named client or server instance that participates in a
-     network communication.
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-Principal identifier
-     The name used to uniquely identify each different principal.
-Seal
-     To encipher a record containing several fields in such a way that the
-     fields cannot be individually replaced without either knowledge of the
-     encryption key or leaving evidence of tampering.
-Secret key
-     An encryption key shared by a principal and the KDC, distributed
-     outside the bounds of the system, with a long lifetime. In the case of
-     a human user's principal, the secret key is derived from a password.
-Server
-     A particular Principal which provides a resource to network clients.
-     The server is sometimes refered to as the Application Server.
-Service
-     A resource provided to network clients; often provided by more than
-     one server (for example, remote file service).
-Session key
-     A temporary encryption key used between two principals, with a
-     lifetime limited to the duration of a single login "session".
-Sub-session key
-     A temporary encryption key used between two principals, selected and
-     exchanged by the principals using the session key, and with a lifetime
-     limited to the duration of a single association.
-Ticket
-     A record that helps a client authenticate itself to a server; it
-     contains the client's identity, a session key, a timestamp, and other
-     information, all sealed using the server's secret key. It only serves
-     to authenticate a client when presented along with a fresh
-     Authenticator.
-
-2. Ticket flag uses and requests
-
-Each Kerberos ticket contains a set of flags which are used to indicate
-various attributes of that ticket. Most flags may be requested by a client
-when the ticket is obtained; some are automatically turned on and off by a
-Kerberos server as required. The following sections explain what the
-various flags mean, and gives examples of reasons to use such a flag.
-
-2.1. Initial and pre-authenticated tickets
-
-The INITIAL flag indicates that a ticket was issued using the AS protocol
-and not issued based on a ticket-granting ticket. Application servers that
-want to require the demonstrated knowledge of a client's secret key (e.g. a
-password-changing program) can insist that this flag be set in any tickets
-they accept, and thus be assured that the client's key was recently
-presented to the application client.
-
-The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the
-initial authentication, regardless of whether the current ticket was issued
-directly (in which case INITIAL will also be set) or issued on the basis of
-a ticket-granting ticket (in which case the INITIAL flag is clear, but the
-PRE-AUTHENT and HW-AUTHENT flags are carried forward from the
-ticket-granting ticket).
-
-2.2. Invalid tickets
-
-The INVALID flag indicates that a ticket is invalid. Application servers
-must reject tickets which have this flag set. A postdated ticket will
-usually be issued in this form. Invalid tickets must be validated by the
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-KDC before use, by presenting them to the KDC in a TGS request with the
-VALIDATE option specified. The KDC will only validate tickets after their
-starttime has passed. The validation is required so that postdated tickets
-which have been stolen before their starttime can be rendered permanently
-invalid (through a hot-list mechanism) (see section 3.3.3.1).
-
-2.3. Renewable tickets
-
-Applications may desire to hold tickets which can be valid for long periods
-of time. However, this can expose their credentials to potential theft for
-equally long periods, and those stolen credentials would be valid until the
-expiration time of the ticket(s). Simply using short-lived tickets and
-obtaining new ones periodically would require the client to have long-term
-access to its secret key, an even greater risk. Renewable tickets can be
-used to mitigate the consequences of theft. Renewable tickets have two
-"expiration times": the first is when the current instance of the ticket
-expires, and the second is the latest permissible value for an individual
-expiration time. An application client must periodically (i.e. before it
-expires) present a renewable ticket to the KDC, with the RENEW option set
-in the KDC request. The KDC will issue a new ticket with a new session key
-and a later expiration time. All other fields of the ticket are left
-unmodified by the renewal process. When the latest permissible expiration
-time arrives, the ticket expires permanently. At each renewal, the KDC may
-consult a hot-list to determine if the ticket had been reported stolen
-since its last renewal; it will refuse to renew such stolen tickets, and
-thus the usable lifetime of stolen tickets is reduced.
-
-The RENEWABLE flag in a ticket is normally only interpreted by the
-ticket-granting service (discussed below in section 3.3). It can usually be
-ignored by application servers. However, some particularly careful
-application servers may wish to disallow renewable tickets.
-
-If a renewable ticket is not renewed by its expiration time, the KDC will
-not renew the ticket. The RENEWABLE flag is reset by default, but a client
-may request it be set by setting the RENEWABLE option in the KRB_AS_REQ
-message. If it is set, then the renew-till field in the ticket contains the
-time after which the ticket may not be renewed.
-
-2.4. Postdated tickets
-
-Applications may occasionally need to obtain tickets for use much later,
-e.g. a batch submission system would need tickets to be valid at the time
-the batch job is serviced. However, it is dangerous to hold valid tickets
-in a batch queue, since they will be on-line longer and more prone to
-theft. Postdated tickets provide a way to obtain these tickets from the KDC
-at job submission time, but to leave them "dormant" until they are
-activated and validated by a further request of the KDC. If a ticket theft
-were reported in the interim, the KDC would refuse to validate the ticket,
-and the thief would be foiled.
-
-The MAY-POSTDATE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. This
-flag must be set in a ticket-granting ticket in order to issue a postdated
-ticket based on the presented ticket. It is reset by default; it may be
-requested by a client by setting the ALLOW-POSTDATE option in the
-KRB_AS_REQ message. This flag does not allow a client to obtain a postdated
-ticket-granting ticket; postdated ticket-granting tickets can only by
-obtained by requesting the postdating in the KRB_AS_REQ message. The life
-(endtime-starttime) of a postdated ticket will be the remaining life of the
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-ticket-granting ticket at the time of the request, unless the RENEWABLE
-option is also set, in which case it can be the full life
-(endtime-starttime) of the ticket-granting ticket. The KDC may limit how
-far in the future a ticket may be postdated.
-
-The POSTDATED flag indicates that a ticket has been postdated. The
-application server can check the authtime field in the ticket to see when
-the original authentication occurred. Some services may choose to reject
-postdated tickets, or they may only accept them within a certain period
-after the original authentication. When the KDC issues a POSTDATED ticket,
-it will also be marked as INVALID, so that the application client must
-present the ticket to the KDC to be validated before use.
-
-2.5. Proxiable and proxy tickets
-
-At times it may be necessary for a principal to allow a service to perform
-an operation on its behalf. The service must be able to take on the
-identity of the client, but only for a particular purpose. A principal can
-allow a service to take on the principal's identity for a particular
-purpose by granting it a proxy.
-
-The process of granting a proxy using the proxy and proxiable flags is used
-to provide credentials for use with specific services. Though conceptually
-also a proxy, user's wishing to delegate their identity for ANY purpose
-must use the ticket forwarding mechanism described in the next section to
-forward a ticket granting ticket.
-
-The PROXIABLE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. When
-set, this flag tells the ticket-granting server that it is OK to issue a
-new ticket (but not a ticket-granting ticket) with a different network
-address based on this ticket. This flag is set if requested by the client
-on initial authentication. By default, the client will request that it be
-set when requesting a ticket granting ticket, and reset when requesting any
-other ticket.
-
-This flag allows a client to pass a proxy to a server to perform a remote
-request on its behalf, e.g. a print service client can give the print
-server a proxy to access the client's files on a particular file server in
-order to satisfy a print request.
-
-In order to complicate the use of stolen credentials, Kerberos tickets are
-usually valid from only those network addresses specifically included in
-the ticket[4]. When granting a proxy, the client must specify the new
-network address from which the proxy is to be used, or indicate that the
-proxy is to be issued for use from any address.
-
-The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket.
-Application servers may check this flag and at their option they may
-require additional authentication from the agent presenting the proxy in
-order to provide an audit trail.
-
-2.6. Forwardable tickets
-
-Authentication forwarding is an instance of a proxy where the service is
-granted complete use of the client's identity. An example where it might be
-used is when a user logs in to a remote system and wants authentication to
-work from that system as if the login were local.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-The FORWARDABLE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. The
-FORWARDABLE flag has an interpretation similar to that of the PROXIABLE
-flag, except ticket-granting tickets may also be issued with different
-network addresses. This flag is reset by default, but users may request
-that it be set by setting the FORWARDABLE option in the AS request when
-they request their initial ticket- granting ticket.
-
-This flag allows for authentication forwarding without requiring the user
-to enter a password again. If the flag is not set, then authentication
-forwarding is not permitted, but the same result can still be achieved if
-the user engages in the AS exchange specifying the requested network
-addresses and supplies a password.
-
-The FORWARDED flag is set by the TGS when a client presents a ticket with
-the FORWARDABLE flag set and requests a forwarded ticket by specifying the
-FORWARDED KDC option and supplying a set of addresses for the new ticket.
-It is also set in all tickets issued based on tickets with the FORWARDED
-flag set. Application servers may choose to process FORWARDED tickets
-differently than non-FORWARDED tickets.
-
-2.7. Other KDC options
-
-There are two additional options which may be set in a client's request of
-the KDC. The RENEWABLE-OK option indicates that the client will accept a
-renewable ticket if a ticket with the requested life cannot otherwise be
-provided. If a ticket with the requested life cannot be provided, then the
-KDC may issue a renewable ticket with a renew-till equal to the the
-requested endtime. The value of the renew-till field may still be adjusted
-by site-determined limits or limits imposed by the individual principal or
-server.
-
-The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service.
-It indicates that the ticket to be issued for the end server is to be
-encrypted in the session key from the a additional second ticket-granting
-ticket provided with the request. See section 3.3.3 for specific details.
-
-3. Message Exchanges
-
-The following sections describe the interactions between network clients
-and servers and the messages involved in those exchanges.
-
-3.1. The Authentication Service Exchange
-
-                          Summary
-      Message direction       Message type    Section
-      1. Client to Kerberos   KRB_AS_REQ      5.4.1
-      2. Kerberos to client   KRB_AS_REP or   5.4.2
-                              KRB_ERROR       5.9.1
-
-The Authentication Service (AS) Exchange between the client and the
-Kerberos Authentication Server is initiated by a client when it wishes to
-obtain authentication credentials for a given server but currently holds no
-credentials. In its basic form, the client's secret key is used for
-encryption and decryption. This exchange is typically used at the
-initiation of a login session to obtain credentials for a Ticket-Granting
-Server which will subsequently be used to obtain credentials for other
-servers (see section 3.3) without requiring further use of the client's
-secret key. This exchange is also used to request credentials for services
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-which must not be mediated through the Ticket-Granting Service, but rather
-require a principal's secret key, such as the password-changing service[5].
-This exchange does not by itself provide any assurance of the the identity
-of the user[6].
-
-The exchange consists of two messages: KRB_AS_REQ from the client to
-Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
-messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
-
-In the request, the client sends (in cleartext) its own identity and the
-identity of the server for which it is requesting credentials. The
-response, KRB_AS_REP, contains a ticket for the client to present to the
-server, and a session key that will be shared by the client and the server.
-The session key and additional information are encrypted in the client's
-secret key. The KRB_AS_REP message contains information which can be used
-to detect replays, and to associate it with the message to which it
-replies. Various errors can occur; these are indicated by an error response
-(KRB_ERROR) instead of the KRB_AS_REP response. The error message is not
-encrypted. The KRB_ERROR message contains information which can be used to
-associate it with the message to which it replies. The lack of encryption
-in the KRB_ERROR message precludes the ability to detect replays,
-fabrications, or modifications of such messages.
-
-Without preautentication, the authentication server does not know whether
-the client is actually the principal named in the request. It simply sends
-a reply without knowing or caring whether they are the same. This is
-acceptable because nobody but the principal whose identity was given in the
-request will be able to use the reply. Its critical information is
-encrypted in that principal's key. The initial request supports an optional
-field that can be used to pass additional information that might be needed
-for the initial exchange. This field may be used for preauthentication as
-described in section [hl<>].
-
-3.1.1. Generation of KRB_AS_REQ message
-
-The client may specify a number of options in the initial request. Among
-these options are whether pre-authentication is to be performed; whether
-the requested ticket is to be renewable, proxiable, or forwardable; whether
-it should be postdated or allow postdating of derivative tickets; and
-whether a renewable ticket will be accepted in lieu of a non-renewable
-ticket if the requested ticket expiration date cannot be satisfied by a
-non-renewable ticket (due to configuration constraints; see section 4). See
-section A.1 for pseudocode.
-
-The client prepares the KRB_AS_REQ message and sends it to the KDC.
-
-3.1.2. Receipt of KRB_AS_REQ message
-
-If all goes well, processing the KRB_AS_REQ message will result in the
-creation of a ticket for the client to present to the server. The format
-for the ticket is described in section 5.3.1. The contents of the ticket
-are determined as follows.
-
-3.1.3. Generation of KRB_AS_REP message
-
-The authentication server looks up the client and server principals named
-in the KRB_AS_REQ in its database, extracting their respective keys. If
-required, the server pre-authenticates the request, and if the
-pre-authentication check fails, an error message with the code
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the
-requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP
-is returned. Otherwise it generates a 'random' session key[7].
-
-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.
-
-If the requested start time is absent, indicates a time in the past, or is
-within the window of acceptable clock skew for the KDC and the POSTDATE
-option has not been specified, then the start time of the ticket is set to
-the authentication server's current time. If it indicates a time in the
-future beyond the acceptable clock skew, but the POSTDATED option has not
-been specified then the error KDC_ERR_CANNOT_POSTDATE is returned.
-Otherwise the requested start time is checked against the policy of the
-local realm (the administrator might decide to prohibit certain types or
-ranges of postdated tickets), and if acceptable, the ticket's start time is
-set as requested and the INVALID flag is set in the new ticket. The
-postdated ticket must be validated before use by presenting it to the KDC
-after the start time has been reached.
-
-The expiration time of the ticket will be set to the minimum of the
-following:
-
-   * The expiration time (endtime) requested in the KRB_AS_REQ message.
-   * The ticket's start time plus the maximum allowable lifetime associated
-     with the client principal (the authentication server's database
-     includes a maximum ticket lifetime field in each principal's record;
-     see section 4).
-   * The ticket's start time plus the maximum allowable lifetime associated
-     with the server principal.
-   * The ticket's start time plus the maximum lifetime set by the policy of
-     the local realm.
-
-If the requested expiration time minus the start time (as determined above)
-is less than a site-determined minimum lifetime, an error message with code
-KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the
-ticket exceeds what was determined as above, and if the 'RENEWABLE-OK'
-option was requested, then the 'RENEWABLE' flag is set in the new ticket,
-and the renew-till value is set as if the 'RENEWABLE' option were requested
-(the field and option names are described fully in section 5.4.1).
-
-If the RENEWABLE option has been requested or if the RENEWABLE-OK option
-has been set and a renewable ticket is to be issued, then the renew-till
-field is set to the minimum of:
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-   * Its requested value.
-   * The start time of the ticket plus the minimum of the two maximum
-     renewable lifetimes associated with the principals' database entries.
-   * The start time of the ticket plus the maximum renewable lifetime set
-     by the policy of the local realm.
-
-The flags field of the new ticket will have the following options set if
-they have been requested and if the policy of the local realm allows:
-FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new
-ticket is post-dated (the start time is in the future), its INVALID flag
-will also be set.
-
-If all of the above succeed, the server formats a KRB_AS_REP message (see
-section 5.4.2), copying the addresses in the request into the caddr of the
-response, placing any required pre-authentication data into the padata of
-the response, and encrypts the ciphertext part in the client's key using
-the requested encryption method, and sends it to the client. See section
-A.2 for pseudocode.
-
-3.1.4. Generation of KRB_ERROR message
-
-Several errors can occur, and the Authentication Server responds by
-returning an error message, KRB_ERROR, to the client, with the error-code
-and e-text fields set to appropriate values. The error message contents and
-details are described in Section 5.9.1.
-
-3.1.5. Receipt of KRB_AS_REP message
-
-If the reply message type is KRB_AS_REP, then the client verifies that the
-cname and crealm fields in the cleartext portion of the reply match what it
-requested. If any padata fields are present, they may be used to derive the
-proper secret key to decrypt the message. The client decrypts the encrypted
-part of the response using its secret key, verifies that the nonce in the
-encrypted part matches the nonce it supplied in its request (to detect
-replays). It also verifies that the sname and srealm in the response match
-those in the request (or are otherwise expected values), and that the host
-address field is also correct. It then stores the ticket, session key,
-start and expiration times, and other information for later use. The
-key-expiration field from the encrypted part of the response may be checked
-to notify the user of impending key expiration (the client program could
-then suggest remedial action, such as a password change). See section A.3
-for pseudocode.
-
-Proper decryption of the KRB_AS_REP message is not sufficient to verify the
-identity of the user; the user and an attacker could cooperate to generate
-a KRB_AS_REP format message which decrypts properly but is not from the
-proper KDC. If the host wishes to verify the identity of the user, it must
-require the user to present application credentials which can be verified
-using a securely-stored secret key for the host. If those credentials can
-be verified, then the identity of the user can be assured.
-
-3.1.6. Receipt of KRB_ERROR message
-
-If the reply message type is KRB_ERROR, then the client interprets it as an
-error and performs whatever application-specific tasks are necessary to
-recover.
-
-3.2. The Client/Server Authentication Exchange
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-                             Summary
-Message direction                         Message type    Section
-Client to Application server              KRB_AP_REQ      5.5.1
-[optional] Application server to client   KRB_AP_REP or   5.5.2
-                                          KRB_ERROR       5.9.1
-
-The client/server authentication (CS) exchange is used by network
-applications to authenticate the client to the server and vice versa. The
-client must have already acquired credentials for the server using the AS
-or TGS exchange.
-
-3.2.1. The KRB_AP_REQ message
-
-The KRB_AP_REQ contains authentication information which should be part of
-the first message in an authenticated transaction. It contains a ticket, an
-authenticator, and some additional bookkeeping information (see section
-5.5.1 for the exact format). The ticket by itself is insufficient to
-authenticate a client, since tickets are passed across the network in
-cleartext[DS90], so the authenticator is used to prevent invalid replay of
-tickets by proving to the server that the client knows the session key of
-the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message
-is referred to elsewhere as the 'authentication header.'
-
-3.2.2. Generation of a KRB_AP_REQ message
-
-When a client wishes to initiate authentication to a server, it obtains
-(either through a credentials cache, the AS exchange, or the TGS exchange)
-a ticket and session key for the desired service. The client may re-use any
-tickets it holds until they expire. To use a ticket the client constructs a
-new Authenticator from the the system time, its name, and optionally an
-application specific checksum, an initial sequence number to be used in
-KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in
-negotiations for a session key unique to this particular session.
-Authenticators may not be re-used and will be rejected if replayed to a
-server[LGDSR87]. If a sequence number is to be included, it should be
-randomly chosen so that even after many messages have been exchanged it is
-not likely to collide with other sequence numbers in use.
-
-The client may indicate a requirement of mutual authentication or the use
-of a session-key based ticket by setting the appropriate flag(s) in the
-ap-options field of the message.
-
-The Authenticator is encrypted in the session key and combined with the
-ticket to form the KRB_AP_REQ message which is then sent to the end server
-along with any additional application-specific information. See section A.9
-for pseudocode.
-
-3.2.3. Receipt of KRB_AP_REQ message
-
-Authentication is based on the server's current time of day (clocks must be
-loosely synchronized), the authenticator, and the ticket. Several errors
-are possible. If an error occurs, the server is expected to reply to the
-client with a KRB_ERROR message. This message may be encapsulated in the
-application protocol if its 'raw' form is not acceptable to the protocol.
-The format of error messages is described in section 5.9.1.
-
-The algorithm for verifying authentication information is as follows. If
-the message type is not KRB_AP_REQ, the server returns the
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket in
-the KRB_AP_REQ is not one the server can use (e.g., it indicates an old
-key, and the server no longer possesses a copy of the old key), the
-KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION-KEY flag is set
-in the ap-options field, it indicates to the server that the ticket is
-encrypted in the session key from the server's ticket-granting ticket
-rather than its secret key[10]. Since it is possible for the server to be
-registered in multiple realms, with different keys in each, the srealm
-field in the unencrypted portion of the ticket in the KRB_AP_REQ is used to
-specify which secret key the server should use to decrypt that ticket. The
-KRB_AP_ERR_NOKEY error code is returned if the server doesn't have the
-proper key to decipher the ticket.
-
-The ticket is decrypted using the version of the server's key specified by
-the ticket. If the decryption routines detect a modification of the ticket
-(each encryption system must provide safeguards to detect modified
-ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned
-(chances are good that different keys were used to encrypt and decrypt).
-
-The authenticator is decrypted using the session key extracted from the
-decrypted ticket. If decryption shows it to have been modified, the
-KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the
-client from the ticket are compared against the same fields in the
-authenticator. If they don't match, the KRB_AP_ERR_BADMATCH error is
-returned (they might not match, for example, if the wrong session key was
-used to encrypt the authenticator). The addresses in the ticket (if any)
-are then searched for an address matching the operating-system reported
-address of the client. If no match is found or the server insists on ticket
-addresses but none are present in the ticket, the KRB_AP_ERR_BADADDR error
-is returned.
-
-If the local (server) time and the client time in the authenticator differ
-by more than the allowable clock skew (e.g., 5 minutes), the
-KRB_AP_ERR_SKEW error is returned. If the server name, along with the
-client name, time and microsecond fields from the Authenticator match any
-recently-seen such tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The
-server must remember any authenticator presented within the allowable clock
-skew, so that a replay attempt is guaranteed to fail. If a server loses
-track of any authenticator presented within the allowable clock skew, it
-must reject all requests until the clock skew interval has passed. This
-assures that any lost or re-played authenticators will fall outside the
-allowable clock skew and can no longer be successfully replayed (If this is
-not done, an attacker could conceivably record the ticket and authenticator
-sent over the network to a server, then disable the client's host, pose as
-the disabled host, and replay the ticket and authenticator to subvert the
-authentication.). If a sequence number is provided in the authenticator,
-the server saves it for later use in processing KRB_SAFE and/or KRB_PRIV
-messages. If a subkey is present, the server either saves it for later use
-or uses it to help generate its own choice for a subkey to be returned in a
-KRB_AP_REP message.
-
-The server computes the age of the ticket: local (server) time minus the
-start time inside the Ticket. If the start time is later than the current
-time by more than the allowable clock skew or if the INVALID flag is set in
-the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the
-current time is later than end time by more than the allowable clock skew,
-the KRB_AP_ERR_TKT_EXPIRED error is returned.
-
-If all these checks succeed without an error, the server is assured that
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-the client possesses the credentials of the principal named in the ticket
-and thus, the client has been authenticated to the server. See section A.10
-for pseudocode.
-
-Passing these checks provides only authentication of the named principal;
-it does not imply authorization to use the named service. Applications must
-make a separate authorization decisions based upon the authenticated name
-of the user, the requested operation, local acces control information such
-as that contained in a .k5login or .k5users file, and possibly a separate
-distributed authorization service.
-
-3.2.4. Generation of a KRB_AP_REP message
-
-Typically, a client's request will include both the authentication
-information and its initial request in the same message, and the server
-need not explicitly reply to the KRB_AP_REQ. However, if mutual
-authentication (not only authenticating the client to the server, but also
-the server to the client) is being performed, the KRB_AP_REQ message will
-have MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message
-is required in response. As with the error message, this message may be
-encapsulated in the application protocol if its "raw" form is not
-acceptable to the application's protocol. The timestamp and microsecond
-field used in the reply must be the client's timestamp and microsecond
-field (as provided in the authenticator)[12]. If a sequence number is to be
-included, it should be randomly chosen as described above for the
-authenticator. A subkey may be included if the server desires to negotiate
-a different subkey. The KRB_AP_REP message is encrypted in the session key
-extracted from the ticket. See section A.11 for pseudocode.
-
-3.2.5. Receipt of KRB_AP_REP message
-
-If a KRB_AP_REP message is returned, the client uses the session key from
-the credentials obtained for the server[13] to decrypt the message, and
-verifies that the timestamp and microsecond fields match those in the
-Authenticator it sent to the server. If they match, then the client is
-assured that the server is genuine. The sequence number and subkey (if
-present) are retained for later use. See section A.12 for pseudocode.
-
-3.2.6. Using the encryption key
-
-After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
-server share an encryption key which can be used by the application. The
-'true session key' to be used for KRB_PRIV, KRB_SAFE, or other
-application-specific uses may be chosen by the application based on the
-subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases,
-the use of this session key will be implicit in the protocol; in others the
-method of use must be chosen from several alternatives. We leave the
-protocol negotiations of how to use the key (e.g. selecting an encryption
-or checksum type) to the application programmer; the Kerberos protocol does
-not constrain the implementation options, but an example of how this might
-be done follows.
-
-One way that an application may choose to negotiate a key to be used for
-subequent integrity and privacy protection is for the client to propose a
-key in the subkey field of the authenticator. The server can then choose a
-key using the proposed key from the client as input, returning the new
-subkey in the subkey field of the application reply. This key could then be
-used for subsequent communication. To make this example more concrete, if
-the encryption method in use required a 56 bit key, and for whatever
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-reason, one of the parties was prevented from using a key with more than 40
-unknown bits, this method would allow the the party which is prevented from
-using more than 40 bits to either propose (if the client) an initial key
-with a known quantity for 16 of those bits, or to mask 16 of the bits (if
-the server) with the known quantity. The application implementor is warned,
-however, that this is only an example, and that an analysis of the
-particular crytosystem to be used, and the reasons for limiting the key
-length, must be made before deciding whether it is acceptable to mask bits
-of the key.
-
-With both the one-way and mutual authentication exchanges, the peers should
-take care not to send sensitive information to each other without proper
-assurances. In particular, applications that require privacy or integrity
-should use the KRB_AP_REP response from the server to client to assure both
-client and server of their peer's identity. If an application protocol
-requires privacy of its messages, it can use the KRB_PRIV message (section
-3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity.
-
-3.3. The Ticket-Granting Service (TGS) Exchange
-
-                          Summary
-      Message direction       Message type     Section
-      1. Client to Kerberos   KRB_TGS_REQ      5.4.1
-      2. Kerberos to client   KRB_TGS_REP or   5.4.2
-                              KRB_ERROR        5.9.1
-
-The TGS exchange between a client and the Kerberos Ticket-Granting Server
-is initiated by a client when it wishes to obtain authentication
-credentials for a given server (which might be registered in a remote
-realm), when it wishes to renew or validate an existing ticket, or when it
-wishes to obtain a proxy ticket. In the first case, the client must already
-have acquired a ticket for the Ticket-Granting Service using the AS
-exchange (the ticket-granting ticket is usually obtained when a client
-initially authenticates to the system, such as when a user logs in). The
-message format for the TGS exchange is almost identical to that for the AS
-exchange. The primary difference is that encryption and decryption in the
-TGS exchange does not take place under the client's key. Instead, the
-session key from the ticket-granting ticket or renewable ticket, or
-sub-session key from an Authenticator is used. As is the case for all
-application servers, expired tickets are not accepted by the TGS, so once a
-renewable or ticket-granting ticket expires, the client must use a separate
-exchange to obtain valid tickets.
-
-The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the
-client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or
-KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the
-client plus a request for credentials. The authentication information
-consists of the authentication header (KRB_AP_REQ) which includes the
-client's previously obtained ticket-granting, renewable, or invalid ticket.
-In the ticket-granting ticket and proxy cases, the request may include one
-or more of: a list of network addresses, a collection of typed
-authorization data to be sealed in the ticket for authorization use by the
-application server, or additional tickets (the use of which are described
-later). The TGS reply (KRB_TGS_REP) contains the requested credentials,
-encrypted in the session key from the ticket-granting ticket or renewable
-ticket, or if present, in the sub-session key from the Authenticator (part
-of the authentication header). The KRB_ERROR message contains an error code
-and text explaining what went wrong. The KRB_ERROR message is not
-encrypted. The KRB_TGS_REP message contains information which can be used
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-to detect replays, and to associate it with the message to which it
-replies. The KRB_ERROR message also contains information which can be used
-to associate it with the message to which it replies, but the lack of
-encryption in the KRB_ERROR message precludes the ability to detect replays
-or fabrications of such messages.
-
-3.3.1. Generation of KRB_TGS_REQ message
-
-Before sending a request to the ticket-granting service, the client must
-determine in which realm the application server is registered[15]. If the
-client does not already possess a ticket-granting ticket for the
-appropriate realm, then one must be obtained. This is first attempted by
-requesting a ticket-granting ticket for the destination realm from a
-Kerberos server for which the client does posess a ticket-granting ticket
-(using the KRB_TGS_REQ message recursively). The Kerberos server may return
-a TGT for the desired realm in which case one can proceed. Alternatively,
-the Kerberos server may return a TGT for a realm which is 'closer' to the
-desired realm (further along the standard hierarchical path), in which case
-this step must be repeated with a Kerberos server in the realm specified in
-the returned TGT. If neither are returned, then the request must be retried
-with a Kerberos server for a realm higher in the hierarchy. This request
-will itself require a ticket-granting ticket for the higher realm which
-must be obtained by recursively applying these directions.
-
-Once the client obtains a ticket-granting ticket for the appropriate realm,
-it determines which Kerberos servers serve that realm, and contacts one.
-The list might be obtained through a configuration file or network service
-or it may be generated from the name of the realm; as long as the secret
-keys exchanged by realms are kept secret, only denial of service results
-from using a false Kerberos server.
-
-As in the AS exchange, the client may specify a number of options in the
-KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing
-an authentication header as an element of the padata field, and including
-the same fields as used in the KRB_AS_REQ message along with several
-optional fields: the enc-authorization-data field for application server
-use and additional tickets required by some options.
-
-In preparing the authentication header, the client can select a sub-session
-key under which the response from the Kerberos server will be
-encrypted[16]. If the sub-session key is not specified, the session key
-from the ticket-granting ticket will be used. If the enc-authorization-data
-is present, it must be encrypted in the sub-session key, if present, from
-the authenticator portion of the authentication header, or if not present,
-using the session key from the ticket-granting ticket.
-
-Once prepared, the message is sent to a Kerberos server for the destination
-realm. See section A.5 for pseudocode.
-
-3.3.2. Receipt of KRB_TGS_REQ message
-
-The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ
-message, but there are many additional checks to be performed. First, the
-Kerberos server must determine which server the accompanying ticket is for
-and it must select the appropriate key to decrypt it. For a normal
-KRB_TGS_REQ message, it will be for the ticket granting service, and the
-TGS's key will be used. If the TGT was issued by another realm, then the
-appropriate inter-realm key must be used. If the accompanying ticket is not
-a ticket granting ticket for the current realm, but is for an application
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-server in the current realm, the RENEW, VALIDATE, or PROXY options are
-specified in the request, and the server for which a ticket is requested is
-the server named in the accompanying ticket, then the KDC will decrypt the
-ticket in the authentication header using the key of the server for which
-it was issued. If no ticket can be found in the padata field, the
-KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
-
-Once the accompanying ticket has been decrypted, the user-supplied checksum
-in the Authenticator must be verified against the contents of the request,
-and the message rejected if the checksums do not match (with an error code
-of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not
-collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the
-checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is
-returned. If the authorization-data are present, they are decrypted using
-the sub-session key from the Authenticator.
-
-If any of the decryptions indicate failed integrity checks, the
-KRB_AP_ERR_BAD_INTEGRITY error is returned.
-
-3.3.3. Generation of KRB_TGS_REP message
-
-The KRB_TGS_REP message shares its format with the KRB_AS_REP
-(KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The detailed
-specification is in section 5.4.2.
-
-The response will include a ticket for the requested server. The Kerberos
-database is queried to retrieve the record for the requested server
-(including the key with which the ticket will be encrypted). If the request
-is for a ticket granting ticket for a remote realm, and if no key is shared
-with the requested realm, then the Kerberos server will select the realm
-"closest" to the requested realm with which it does share a key, and use
-that realm instead. This is the only case where the response from the KDC
-will be for a different server than that requested by the client.
-
-By default, the address field, the client's name and realm, the list of
-transited realms, the time of initial authentication, the expiration time,
-and the authorization data of the newly-issued ticket will be copied from
-the ticket-granting ticket (TGT) or renewable ticket. If the transited
-field needs to be updated, but the transited type is not supported, the
-KDC_ERR_TRTYPE_NOSUPP error is returned.
-
-If the request specifies an endtime, then the endtime of the new ticket is
-set to the minimum of (a) that request, (b) the endtime from the TGT, and
-(c) the starttime of the TGT plus the minimum of the maximum life for the
-application server and the maximum life for the local realm (the maximum
-life for the requesting principal was already applied when the TGT was
-issued). If the new ticket is to be a renewal, then the endtime above is
-replaced by the minimum of (a) the value of the renew_till field of the
-ticket and (b) the starttime for the new ticket plus the life
-(endtime-starttime) of the old ticket.
-
-If the FORWARDED option has been requested, then the resulting ticket will
-contain the addresses specified by the client. This option will only be
-honored if the FORWARDABLE flag is set in the TGT. The PROXY option is
-similar; the resulting ticket will contain the addresses specified by the
-client. It will be honored only if the PROXIABLE flag in the TGT is set.
-The PROXY option will not be honored on requests for additional
-ticket-granting tickets.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-If the requested start time is absent, indicates a time in the past, or is
-within the window of acceptable clock skew for the KDC and the POSTDATE
-option has not been specified, then the start time of the ticket is set to
-the authentication server's current time. If it indicates a time in the
-future beyond the acceptable clock skew, but the POSTDATED option has not
-been specified or the MAY-POSTDATE flag is not set in the TGT, then the
-error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the
-ticket-granting ticket has the MAY-POSTDATE flag set, then the resulting
-ticket will be postdated and the requested starttime is checked against the
-policy of the local realm. If acceptable, the ticket's start time is set as
-requested, and the INVALID flag is set. The postdated ticket must be
-validated before use by presenting it to the KDC after the starttime has
-been reached. However, in no case may the starttime, endtime, or renew-till
-time of a newly-issued postdated ticket extend beyond the renew-till time
-of the ticket-granting ticket.
-
-If the ENC-TKT-IN-SKEY option has been specified and an additional ticket
-has been included in the request, the KDC will decrypt the additional
-ticket using the key for the server to which the additional ticket was
-issued and verify that it is a ticket-granting ticket. If the name of the
-requested server is missing from the request, the name of the client in the
-additional ticket will be used. Otherwise the name of the requested server
-will be compared to the name of the client in the additional ticket and if
-different, the request will be rejected. If the request succeeds, the
-session key from the additional ticket will be used to encrypt the new
-ticket that is issued instead of using the key of the server for which the
-new ticket will be used[17].
-
-If the name of the server in the ticket that is presented to the KDC as
-part of the authentication header is not that of the ticket-granting server
-itself, the server is registered in the realm of the KDC, and the RENEW
-option is requested, then the KDC will verify that the RENEWABLE flag is
-set in the ticket, that the INVALID flag is not set in the ticket, and that
-the renew_till time is still in the future. If the VALIDATE option is
-rqeuested, the KDC will check that the starttime has passed and the INVALID
-flag is set. If the PROXY option is requested, then the KDC will check that
-the PROXIABLE flag is set in the ticket. If the tests succeed, and the
-ticket passes the hotlist check described in the next paragraph, the KDC
-will issue the appropriate new ticket.
-
-3.3.3.1. Checking for revoked tickets
-
-Whenever a request is made to the ticket-granting server, the presented
-ticket(s) is(are) checked against a hot-list of tickets which have been
-canceled. This hot-list might be implemented by storing a range of issue
-timestamps for 'suspect tickets'; if a presented ticket had an authtime in
-that range, it would be rejected. In this way, a stolen ticket-granting
-ticket or renewable ticket cannot be used to gain additional tickets
-(renewals or otherwise) once the theft has been reported. Any normal ticket
-obtained before it was reported stolen will still be valid (because they
-require no interaction with the KDC), but only until their normal
-expiration time.
-
-The ciphertext part of the response in the KRB_TGS_REP message is encrypted
-in the sub-session key from the Authenticator, if present, or the session
-key key from the ticket-granting ticket. It is not encrypted using the
-client's secret key. Furthermore, the client's key's expiration date and
-the key version number fields are left out since these values are stored
-along with the client's database record, and that record is not needed to
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-satisfy a request based on a ticket-granting ticket. See section A.6 for
-pseudocode.
-
-3.3.3.2. Encoding the transited field
-
-If the identity of the server in the TGT that is presented to the KDC as
-part of the authentication header is that of the ticket-granting service,
-but the TGT was issued from another realm, the KDC will look up the
-inter-realm key shared with that realm and use that key to decrypt the
-ticket. If the ticket is valid, then the KDC will honor the request,
-subject to the constraints outlined above in the section describing the AS
-exchange. The realm part of the client's identity will be taken from the
-ticket-granting ticket. The name of the realm that issued the
-ticket-granting ticket will be added to the transited field of the ticket
-to be issued. This is accomplished by reading the transited field from the
-ticket-granting ticket (which is treated as an unordered set of realm
-names), adding the new realm to the set, then constructing and writing out
-its encoded (shorthand) form (this may involve a rearrangement of the
-existing encoding).
-
-Note that the ticket-granting service does not add the name of its own
-realm. Instead, its responsibility is to add the name of the previous
-realm. This prevents a malicious Kerberos server from intentionally leaving
-out its own name (it could, however, omit other realms' names).
-
-The names of neither the local realm nor the principal's realm are to be
-included in the transited field. They appear elsewhere in the ticket and
-both are known to have taken part in authenticating the principal. Since
-the endpoints are not included, both local and single-hop inter-realm
-authentication result in a transited field that is empty.
-
-Because the name of each realm transited is added to this field, it might
-potentially be very long. To decrease the length of this field, its
-contents are encoded. The initially supported encoding is optimized for the
-normal case of inter-realm communication: a hierarchical arrangement of
-realms using either domain or X.500 style realm names. This encoding
-(called DOMAIN-X500-COMPRESS) is now described.
-
-Realm names in the transited field are separated by a ",". The ",", "\",
-trailing "."s, and leading spaces (" ") are special characters, and if they
-are part of a realm name, they must be quoted in the transited field by
-preced- ing them with a "\".
-
-A realm name ending with a "." is interpreted as being prepended to the
-previous realm. For example, we can encode traversal of EDU, MIT.EDU,
-ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
-
-     "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
-
-Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that
-they would not be included in this field, and we would have:
-
-     "EDU,MIT.,WASHINGTON.EDU"
-
-A realm name beginning with a "/" is interpreted as being appended to the
-previous realm[18]. If it is to stand by itself, then it should be preceded
-by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO,
-/COM/HP, /COM, and /COM/DEC as:
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-     "/COM,/HP,/APOLLO, /COM/DEC".
-
-Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they
-they would not be included in this field, and we would have:
-
-     "/COM,/HP"
-
-A null subfield preceding or following a "," indicates that all realms
-between the previous realm and the next realm have been traversed[19].
-Thus, "," means that all realms along the path between the client and the
-server have been traversed. ",EDU, /COM," means that that all realms from
-the client's realm up to EDU (in a domain style hierarchy) have been
-traversed, and that everything from /COM down to the server's realm in an
-X.500 style has also been traversed. This could occur if the EDU realm in
-one hierarchy shares an inter-realm key directly with the /COM realm in
-another hierarchy.
-
-3.3.4. Receipt of KRB_TGS_REP message
-
-When the KRB_TGS_REP is received by the client, it is processed in the same
-manner as the KRB_AS_REP processing described above. The primary difference
-is that the ciphertext part of the response must be decrypted using the
-session key from the ticket-granting ticket rather than the client's secret
-key. See section A.7 for pseudocode.
-
-3.4. The KRB_SAFE Exchange
-
-The KRB_SAFE message may be used by clients requiring the ability to detect
-modifications of messages they exchange. It achieves this by including a
-keyed collision-proof checksum of the user data and some control
-information. The checksum is keyed with an encryption key (usually the last
-key negotiated via subkeys, or the session key if no negotiation has
-occured).
-
-3.4.1. Generation of a KRB_SAFE message
-
-When an application wishes to send a KRB_SAFE message, it collects its data
-and the appropriate control information and computes a checksum over them.
-The checksum algorithm should be a keyed one-way hash function (such as the
-RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES
-MAC), generated using the sub-session key if present, or the session key.
-Different algorithms may be selected by changing the checksum type in the
-message. Unkeyed or non-collision-proof checksums are not suitable for this
-use.
-
-The control information for the KRB_SAFE message includes both a timestamp
-and a sequence number. The designer of an application using the KRB_SAFE
-message must choose at least one of the two mechanisms. This choice should
-be based on the needs of the application protocol.
-
-Sequence numbers are useful when all messages sent will be received by
-one's peer. Connection state is presently required to maintain the session
-key, so maintaining the next sequence number should not present an
-additional problem.
-
-If the application protocol is expected to tolerate lost messages without
-them being resent, the use of the timestamp is the appropriate replay
-detection mechanism. Using timestamps is also the appropriate mechanism for
-multi-cast protocols where all of one's peers share a common sub-session
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-key, but some messages will be sent to a subset of one's peers.
-
-After computing the checksum, the client then transmits the information and
-checksum to the recipient in the message format specified in section 5.6.1.
-
-3.4.2. Receipt of KRB_SAFE message
-
-When an application receives a KRB_SAFE message, it verifies it as follows.
-If any error occurs, an error code is reported for use by the application.
-
-The message is first checked by verifying that the protocol version and
-type fields match the current version and KRB_SAFE, respectively. A
-mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error.
-The application verifies that the checksum used is a collision-proof keyed
-checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated.
-The recipient verifies that the operating system's report of the sender's
-address matches the sender's address in the message, and (if a recipient
-address is specified or the recipient requires an address) that one of the
-recipient's addresses appears as the recipient's address in the message. A
-failed match for either case generates a KRB_AP_ERR_BADADDR error. Then the
-timestamp and usec and/or the sequence number fields are checked. If
-timestamp and usec are expected and not present, or they are present but
-not current, the KRB_AP_ERR_SKEW error is generated. If the server name,
-along with the client name, time and microsecond fields from the
-Authenticator match any recently-seen (sent or received[20] ) such tuples,
-the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number
-is included, or a sequence number is expected but not present, the
-KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or
-a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated.
-Finally, the checksum is computed over the data and control information,
-and if it doesn't match the received checksum, a KRB_AP_ERR_MODIFIED error
-is generated.
-
-If all the checks succeed, the application is assured that the message was
-generated by its peer and was not modi- fied in transit.
-
-3.5. The KRB_PRIV Exchange
-
-The KRB_PRIV message may be used by clients requiring confidentiality and
-the ability to detect modifications of exchanged messages. It achieves this
-by encrypting the messages and adding control information.
-
-3.5.1. Generation of a KRB_PRIV message
-
-When an application wishes to send a KRB_PRIV message, it collects its data
-and the appropriate control information (specified in section 5.7.1) and
-encrypts them under an encryption key (usually the last key negotiated via
-subkeys, or the session key if no negotiation has occured). As part of the
-control information, the client must choose to use either a timestamp or a
-sequence number (or both); see the discussion in section 3.4.1 for
-guidelines on which to use. After the user data and control information are
-encrypted, the client transmits the ciphertext and some 'envelope'
-information to the recipient.
-
-3.5.2. Receipt of KRB_PRIV message
-
-When an application receives a KRB_PRIV message, it verifies it as follows.
-If any error occurs, an error code is reported for use by the application.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-The message is first checked by verifying that the protocol version and
-type fields match the current version and KRB_PRIV, respectively. A
-mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error.
-The application then decrypts the ciphertext and processes the resultant
-plaintext. If decryption shows the data to have been modified, a
-KRB_AP_ERR_BAD_INTEGRITY error is generated. The recipient verifies that
-the operating system's report of the sender's address matches the sender's
-address in the message, and (if a recipient address is specified or the
-recipient requires an address) that one of the recipient's addresses
-appears as the recipient's address in the message. A failed match for
-either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and
-usec and/or the sequence number fields are checked. If timestamp and usec
-are expected and not present, or they are present but not current, the
-KRB_AP_ERR_SKEW error is generated. If the server name, along with the
-client name, time and microsecond fields from the Authenticator match any
-recently-seen such tuples, the KRB_AP_ERR_REPEAT error is generated. If an
-incorrect sequence number is included, or a sequence number is expected but
-not present, the KRB_AP_ERR_BADORDER error is generated. If neither a
-time-stamp and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED
-error is generated.
-
-If all the checks succeed, the application can assume the message was
-generated by its peer, and was securely transmitted (without intruders able
-to see the unencrypted contents).
-
-3.6. The KRB_CRED Exchange
-
-The KRB_CRED message may be used by clients requiring the ability to send
-Kerberos credentials from one host to another. It achieves this by sending
-the tickets together with encrypted data containing the session keys and
-other information associated with the tickets.
-
-3.6.1. Generation of a KRB_CRED message
-
-When an application wishes to send a KRB_CRED message it first (using the
-KRB_TGS exchange) obtains credentials to be sent to the remote host. It
-then constructs a KRB_CRED message using the ticket or tickets so obtained,
-placing the session key needed to use each ticket in the key field of the
-corresponding KrbCredInfo sequence of the encrypted part of the the
-KRB_CRED message.
-
-Other information associated with each ticket and obtained during the
-KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence
-in the encrypted part of the KRB_CRED message. The current time and, if
-specifically required by the application the nonce, s-address, and
-r-address fields, are placed in the encrypted part of the KRB_CRED message
-which is then encrypted under an encryption key previosuly exchanged in the
-KRB_AP exchange (usually the last key negotiated via subkeys, or the
-session key if no negotiation has occured).
-
-3.6.2. Receipt of KRB_CRED message
-
-When an application receives a KRB_CRED message, it verifies it. If any
-error occurs, an error code is reported for use by the application. The
-message is verified by checking that the protocol version and type fields
-match the current version and KRB_CRED, respectively. A mismatch generates
-a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then
-decrypts the ciphertext and processes the resultant plaintext. If
-decryption shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-error is generated.
-
-If present or required, the recipient verifies that the operating system's
-report of the sender's address matches the sender's address in the message,
-and that one of the recipient's addresses appears as the recipient's
-address in the message. A failed match for either case generates a
-KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce
-field if required) are checked next. If the timestamp and usec are not
-present, or they are present but not current, the KRB_AP_ERR_SKEW error is
-generated.
-
-If all the checks succeed, the application stores each of the new tickets
-in its ticket cache together with the session key and other information in
-the corresponding KrbCredInfo sequence from the encrypted part of the
-KRB_CRED message.
-
-4. The Kerberos Database
-
-The Kerberos server must have access to a database contain- ing the
-principal identifiers and secret keys of principals to be
-authenticated[21].
-
-4.1. Database contents
-
-A database entry should contain at least the following fields:
-
-Field                Value
-
-name                 Principal's identifier
-key                  Principal's secret key
-p_kvno               Principal's key version
-max_life             Maximum lifetime for Tickets
-max_renewable_life   Maximum total lifetime for renewable Tickets
-
-The name field is an encoding of the principal's identifier. The key field
-contains an encryption key. This key is the principal's secret key. (The
-key can be encrypted before storage under a Kerberos "master key" to
-protect it in case the database is compromised but the master key is not.
-In that case, an extra field must be added to indicate the master key
-version used, see below.) The p_kvno field is the key version number of the
-principal's secret key. The max_life field contains the maximum allowable
-lifetime (endtime - starttime) for any Ticket issued for this principal.
-The max_renewable_life field contains the maximum allowable total lifetime
-for any renewable Ticket issued for this principal. (See section 3.1 for a
-description of how these lifetimes are used in determining the lifetime of
-a given Ticket.)
-
-A server may provide KDC service to several realms, as long as the database
-representation provides a mechanism to distinguish between principal
-records with identifiers which differ only in the realm name.
-
-When an application server's key changes, if the change is routine (i.e.
-not the result of disclosure of the old key), the old key should be
-retained by the server until all tickets that had been issued using that
-key have expired. Because of this, it is possible for several keys to be
-active for a single principal. Ciphertext encrypted in a principal's key is
-always tagged with the version of the key that was used for encryption, to
-help the recipient find the proper key for decryption.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-When more than one key is active for a particular principal, the principal
-will have more than one record in the Kerberos database. The keys and key
-version numbers will differ between the records (the rest of the fields may
-or may not be the same). Whenever Kerberos issues a ticket, or responds to
-a request for initial authentication, the most recent key (known by the
-Kerberos server) will be used for encryption. This is the key with the
-highest key version number.
-
-4.2. Additional fields
-
-Project Athena's KDC implementation uses additional fields in its database:
-
-Field        Value
-
-K_kvno       Kerberos' key version
-expiration   Expiration date for entry
-attributes   Bit field of attributes
-mod_date     Timestamp of last modification
-mod_name     Modifying principal's identifier
-
-The K_kvno field indicates the key version of the Kerberos master key under
-which the principal's secret key is encrypted.
-
-After an entry's expiration date has passed, the KDC will return an error
-to any client attempting to gain tickets as or for the principal. (A
-database may want to maintain two expiration dates: one for the principal,
-and one for the principal's current key. This allows password aging to work
-independently of the principal's expiration date. However, due to the
-limited space in the responses, the KDC must combine the key expiration and
-principal expiration date into a single value called 'key_exp', which is
-used as a hint to the user to take administrative action.)
-
-The attributes field is a bitfield used to govern the operations involving
-the principal. This field might be useful in conjunction with user
-registration procedures, for site-specific policy implementations (Project
-Athena currently uses it for their user registration process controlled by
-the system-wide database service, Moira [LGDSR87]), to identify whether a
-principal can play the role of a client or server or both, to note whether
-a server is appropriate trusted to recieve credentials delegated by a
-client, or to identify the 'string to key' conversion algorithm used for a
-principal's key[22]. Other bits are used to indicate that certain ticket
-options should not be allowed in tickets encrypted under a principal's key
-(one bit each): Disallow issuing postdated tickets, disallow issuing
-forwardable tickets, disallow issuing tickets based on TGT authentication,
-disallow issuing renewable tickets, disallow issuing proxiable tickets, and
-disallow issuing tickets for which the principal is the server.
-
-The mod_date field contains the time of last modification of the entry, and
-the mod_name field contains the name of the principal which last modified
-the entry.
-
-4.3. Frequently Changing Fields
-
-Some KDC implementations may wish to maintain the last time that a request
-was made by a particular principal. Information that might be maintained
-includes the time of the last request, the time of the last request for a
-ticket-granting ticket, the time of the last use of a ticket-granting
-ticket, or other times. This information can then be returned to the user
-in the last-req field (see section 5.2).
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-Other frequently changing information that can be maintained is the latest
-expiration time for any tickets that have been issued using each key. This
-field would be used to indicate how long old keys must remain valid to
-allow the continued use of outstanding tickets.
-
-4.4. Site Constants
-
-The KDC implementation should have the following configurable constants or
-options, to allow an administrator to make and enforce policy decisions:
-
-   * The minimum supported lifetime (used to determine whether the
-     KDC_ERR_NEVER_VALID error should be returned). This constant should
-     reflect reasonable expectations of round-trip time to the KDC,
-     encryption/decryption time, and processing time by the client and
-     target server, and it should allow for a minimum 'useful' lifetime.
-   * The maximum allowable total (renewable) lifetime of a ticket
-     (renew_till - starttime).
-   * The maximum allowable lifetime of a ticket (endtime - starttime).
-   * Whether to allow the issue of tickets with empty address fields
-     (including the ability to specify that such tickets may only be issued
-     if the request specifies some authorization_data).
-   * Whether proxiable, forwardable, renewable or post-datable tickets are
-     to be issued.
-
-5. Message Specifications
-
-The following sections describe the exact contents and encoding of protocol
-messages and objects. The ASN.1 base definitions are presented in the first
-subsection. The remaining subsections specify the protocol objects (tickets
-and authenticators) and messages. Specification of encryption and checksum
-techniques, and the fields related to them, appear in section 6.
-
-Optional field in ASN.1 sequences
-
-For optional integer value and date fields in ASN.1 sequences where a
-default value has been specified, certain default values will not be
-allowed in the encoding because these values will always be represented
-through defaulting by the absence of the optional field. For example, one
-will not send a microsecond zero value because one must make sure that
-there is only one way to encode this value.
-
-Additional fields in ASN.1 sequences
-
-Implementations receiving Kerberos messages with additional fields present
-in ASN.1 sequences should carry the those fields through unmodified when
-the message is forwarded. Implementation should drop such fields if the
-sequence is reencoded.
-
-5.1. ASN.1 Distinguished Encoding Representation
-
-All uses of ASN.1 in Kerberos shall use the Distinguished Encoding
-Representation of the data elements as described in the X.509
-specification, section 8.7 [X509-88].
-
-5.3. ASN.1 Base Definitions
-
-The following ASN.1 base definitions are used in the rest of this section.
-Note that since the underscore character (_) is not permitted in ASN.1
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-names, the hyphen (-) is used in its place for the purposes of ASN.1 names.
-
-Realm ::=           GeneralString
-PrincipalName ::=   SEQUENCE {
-                    name-type[0]     INTEGER,
-                    name-string[1]   SEQUENCE OF GeneralString
-}
-
-Kerberos realms are encoded as GeneralStrings. Realms shall not contain a
-character with the code 0 (the ASCII NUL). Most realms will usually consist
-of several components separated by periods (.), in the style of Internet
-Domain Names, or separated by slashes (/) in the style of X.500 names.
-Acceptable forms for realm names are specified in section 7. A
-PrincipalName is a typed sequence of components consisting of the following
-sub-fields:
-
-name-type
-     This field specifies the type of name that follows. Pre-defined values
-     for this field are specified in section 7.2. The name-type should be
-     treated as a hint. Ignoring the name type, no two names can be the
-     same (i.e. at least one of the components, or the realm, must be
-     different). This constraint may be eliminated in the future.
-name-string
-     This field encodes a sequence of components that form a name, each
-     component encoded as a GeneralString. Taken together, a PrincipalName
-     and a Realm form a principal identifier. Most PrincipalNames will have
-     only a few components (typically one or two).
-
-KerberosTime ::=   GeneralizedTime
-                   -- Specifying UTC time zone (Z)
-
-The timestamps used in Kerberos are encoded as GeneralizedTimes. An
-encoding shall specify the UTC time zone (Z) and shall not include any
-fractional portions of the seconds. It further shall not include any
-separators. Example: The only valid format for UTC time 6 minutes, 27
-seconds after 9 pm on 6 November 1985 is 19851106210627Z.
-
-HostAddress ::=     SEQUENCE  {
-                    addr-type[0]             INTEGER,
-                    address[1]               OCTET STRING
-}
-
-HostAddresses ::=   SEQUENCE OF HostAddress
-
-The host adddress encodings consists of two fields:
-
-addr-type
-     This field specifies the type of address that follows. Pre-defined
-     values for this field are specified in section 8.1.
-address
-     This field encodes a single address of type addr-type.
-
-The two forms differ slightly. HostAddress contains exactly one address;
-HostAddresses contains a sequence of possibly many addresses.
-
-AuthorizationData ::=   SEQUENCE OF SEQUENCE {
-                        ad-type[0]               INTEGER,
-                        ad-data[1]               OCTET STRING
-}
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-ad-data
-     This field contains authorization data to be interpreted according to
-     the value of the corresponding ad-type field.
-ad-type
-     This field specifies the format for the ad-data subfield. All negative
-     values are reserved for local use. Non-negative values are reserved
-     for registered use.
-
-Each sequence of type and data is refered to as an authorization element.
-Elements may be application specific, however, there is a common set of
-recursive elements that should be understood by all implementations. These
-elements contain other elements embedded within them, and the
-interpretation of the encapsulating element determines which of the
-embedded elements must be interpreted, and which may be ignored.
-Definitions for these common elements may be found in Appendix B.
-
-TicketExtensions ::= SEQUENCE OF SEQUENCE {
-           te-type[0]       INTEGER,
-           te-data[1]       OCTET STRING
-}
-
-
-
-te-data
-     This field contains opaque data that must be caried with the ticket to
-     support extensions to the Kerberos protocol including but not limited
-     to some forms of inter-realm key exchange and plaintext authorization
-     data. See appendix C for some common uses of this field.
-te-type
-     This field specifies the format for the te-data subfield. All negative
-     values are reserved for local use. Non-negative values are reserved
-     for registered use.
-
-APOptions ::=   BIT STRING
-                  -- reserved(0),
-                  -- use-session-key(1),
-                  -- mutual-required(2)
-
-TicketFlags ::= BIT STRING
-                  -- reserved(0),
-                  -- forwardable(1),
-                  -- forwarded(2),
-                  -- proxiable(3),
-                  -- proxy(4),
-                  -- may-postdate(5),
-                  -- postdated(6),
-                  -- invalid(7),
-                  -- renewable(8),
-                  -- initial(9),
-                  -- pre-authent(10),
-                  -- hw-authent(11),
-                  -- transited-policy-checked(12),
-                  -- ok-as-delegate(13)
-
-KDCOptions ::=   BIT STRING
-                  -- reserved(0),
-                  -- forwardable(1),
-                  -- forwarded(2),
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-                  -- proxiable(3),
-                  -- proxy(4),
-                  -- allow-postdate(5),
-                  -- postdated(6),
-                  -- unused7(7),
-                  -- renewable(8),
-                  -- unused9(9),
-                  -- unused10(10),
-                  -- unused11(11),
-                  -- unused12(12),
-                  -- unused13(13),
-                  -- disable-transited-check(26),
-                  -- renewable-ok(27),
-                  -- enc-tkt-in-skey(28),
-                  -- renew(30),
-                  -- validate(31)
-
-ASN.1 Bit strings have a length and a value. When used in Kerberos for the
-APOptions, TicketFlags, and KDCOptions, the length of the bit string on
-generated values should be the smallest number of bits needed to include
-the highest order bit that is set (1), but in no case less than 32 bits.
-The ASN.1 representation of the bit strings uses unnamed bits, with the
-meaning of the individual bits defined by the comments in the specification
-above. Implementations should accept values of bit strings of any length
-and treat the value of flags corresponding to bits beyond the end of the
-bit string as if the bit were reset (0). Comparison of bit strings of
-different length should treat the smaller string as if it were padded with
-zeros beyond the high order bits to the length of the longer string[23].
-
-LastReq ::=   SEQUENCE OF SEQUENCE {
-               lr-type[0]               INTEGER,
-               lr-value[1]              KerberosTime
-}
-
-lr-type
-     This field indicates how the following lr-value field is to be
-     interpreted. Negative values indicate that the information pertains
-     only to the responding server. Non-negative values pertain to all
-     servers for the realm. If the lr-type field is zero (0), then no
-     information is conveyed by the lr-value subfield. If the absolute
-     value of the lr-type field is one (1), then the lr-value subfield is
-     the time of last initial request for a TGT. If it is two (2), then the
-     lr-value subfield is the time of last initial request. If it is three
-     (3), then the lr-value subfield is the time of issue for the newest
-     ticket-granting ticket used. If it is four (4), then the lr-value
-     subfield is the time of the last renewal. If it is five (5), then the
-     lr-value subfield is the time of last request (of any type). If it is
-     (6), then the lr-value subfield is the time when the password will
-     expire.
-lr-value
-     This field contains the time of the last request. the time must be
-     interpreted according to the contents of the accompanying lr-type
-     subfield.
-
-See section 6 for the definitions of Checksum, ChecksumType, EncryptedData,
-EncryptionKey, EncryptionType, and KeyType.
-
-5.3. Tickets and Authenticators
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-This section describes the format and encryption parameters for tickets and
-authenticators. When a ticket or authenticator is included in a protocol
-message it is treated as an opaque object.
-
-5.3.1. Tickets
-
-A ticket is a record that helps a client authenticate to a service. A
-Ticket contains the following information:
-
-Ticket ::=        [APPLICATION 1] SEQUENCE {
-                  tkt-vno[0]                   INTEGER,
-                  realm[1]                     Realm,
-                  sname[2]                     PrincipalName,
-                  enc-part[3]                  EncryptedData,
-                  extensions[4]                TicketExtensions OPTIONAL
-}
-
--- Encrypted part of ticket
-EncTicketPart ::= [APPLICATION 3] SEQUENCE {
-                  flags[0]                     TicketFlags,
-                  key[1]                       EncryptionKey,
-                  crealm[2]                    Realm,
-                  cname[3]                     PrincipalName,
-                  transited[4]                 TransitedEncoding,
-                  authtime[5]                  KerberosTime,
-                  starttime[6]                 KerberosTime OPTIONAL,
-                  endtime[7]                   KerberosTime,
-                  renew-till[8]                KerberosTime OPTIONAL,
-                  caddr[9]                     HostAddresses OPTIONAL,
-                  authorization-data[10]       AuthorizationData OPTIONAL
-}
--- encoded Transited field
-TransitedEncoding ::=   SEQUENCE {
-                        tr-type[0]             INTEGER, -- must be
-registered
-                        contents[1]            OCTET STRING
-}
-
-The encoding of EncTicketPart is encrypted in the key shared by Kerberos
-and the end server (the server's secret key). See section 6 for the format
-of the ciphertext.
-
-tkt-vno
-     This field specifies the version number for the ticket format. This
-     document describes version number 5.
-realm
-     This field specifies the realm that issued a ticket. It also serves to
-     identify the realm part of the server's principal identifier. Since a
-     Kerberos server can only issue tickets for servers within its realm,
-     the two will always be identical.
-sname
-     This field specifies the name part of the server's identity.
-enc-part
-     This field holds the encrypted encoding of the EncTicketPart sequence.
-extensions
-     This optional field contains a sequence of extentions that may be used
-     to carry information that must be carried with the ticket to support
-     several extensions, including but not limited to plaintext
-     authorization data, tokens for exchanging inter-realm keys, and other
-     information that must be associated with a ticket for use by the
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-     application server. See Appendix C for definitions of some common
-     extensions.
-
-     Note that some older versions of Kerberos did not support this field.
-     Because this is an optional field it will not break older clients, but
-     older clients might strip this field from the ticket before sending it
-     to the application server. This limits the usefulness of this ticket
-     field to environments where the ticket will not be parsed and
-     reconstructed by these older Kerberos clients.
-
-     If it is known that the client will strip this field from the ticket,
-     as an interim measure the KDC may append this field to the end of the
-     enc-part of the ticket and append a traler indicating the lenght of
-     the appended extensions field. (this paragraph is open for discussion,
-     including the form of the traler).
-flags
-     This field indicates which of various options were used or requested
-     when the ticket was issued. It is a bit-field, where the selected
-     options are indicated by the bit being set (1), and the unselected
-     options and reserved fields being reset (0). Bit 0 is the most
-     significant bit. The encoding of the bits is specified in section 5.2.
-     The flags are described in more detail above in section 2. The
-     meanings of the flags are:
-
-          Bit(s)      Name         Description
-
-          0           RESERVED
-                                   Reserved for future  expansion  of  this
-                                   field.
-
-          1           FORWARDABLE
-                                   The FORWARDABLE flag  is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.  When set,  this
-                                   flag  tells  the  ticket-granting server
-                                   that it is OK to  issue  a  new  ticket-
-                                   granting ticket with a different network
-                                   address based on the presented ticket.
-
-          2           FORWARDED
-                                   When set, this flag indicates  that  the
-                                   ticket  has either been forwarded or was
-                                   issued based on authentication involving
-                                   a forwarded ticket-granting ticket.
-
-          3           PROXIABLE
-                                   The  PROXIABLE  flag  is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.   The  PROXIABLE
-                                   flag  has an interpretation identical to
-                                   that of  the  FORWARDABLE  flag,  except
-                                   that   the   PROXIABLE  flag  tells  the
-                                   ticket-granting server  that  only  non-
-                                   ticket-granting  tickets  may  be issued
-                                   with different network addresses.
-
-          4           PROXY
-                                   When set, this  flag  indicates  that  a
-                                   ticket is a proxy.
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-          5           MAY-POSTDATE
-                                   The MAY-POSTDATE flag is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.  This flag tells
-                                   the  ticket-granting server that a post-
-                                   dated ticket may be issued based on this
-                                   ticket-granting ticket.
-
-          6           POSTDATED
-                                   This flag indicates that this ticket has
-                                   been  postdated.   The  end-service  can
-                                   check the authtime field to see when the
-                                   original authentication occurred.
-
-          7           INVALID
-                                   This flag indicates  that  a  ticket  is
-                                   invalid, and it must be validated by the
-                                   KDC  before  use.   Application  servers
-                                   must reject tickets which have this flag
-                                   set.
-
-          8           RENEWABLE
-                                   The  RENEWABLE  flag  is  normally  only
-                                   interpreted  by the TGS, and can usually
-                                   be ignored by end servers (some particu-
-                                   larly careful servers may wish to disal-
-                                   low  renewable  tickets).   A  renewable
-                                   ticket  can be used to obtain a replace-
-                                   ment ticket  that  expires  at  a  later
-                                   date.
-
-          9           INITIAL
-                                   This flag indicates that this ticket was
-                                   issued  using  the  AS protocol, and not
-                                   issued  based   on   a   ticket-granting
-                                   ticket.
-
-          10          PRE-AUTHENT
-                                   This flag indicates that during  initial
-                                   authentication, the client was authenti-
-                                   cated by the KDC  before  a  ticket  was
-                                   issued.    The   strength  of  the  pre-
-                                   authentication method is not  indicated,
-                                   but is acceptable to the KDC.
-
-          11          HW-AUTHENT
-                                   This flag indicates  that  the  protocol
-                                   employed   for   initial  authentication
-                                   required the use of hardware expected to
-                                   be possessed solely by the named client.
-                                   The hardware  authentication  method  is
-                                   selected  by the KDC and the strength of
-                                   the method is not indicated.
-
-          12           TRANSITED   This flag indicates that the KDC for the
-                  POLICY-CHECKED   realm has checked the transited field
-                                   against a realm defined policy for
-                                   trusted certifiers.  If this flag is
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-                                   reset (0), then the application server
-                                   must check the transited field itself,
-                                   and if unable to do so it must reject
-                                   the authentication.  If the flag is set
-                                   (1) then the application server may skip
-                                   its own validation of the transited
-                                   field, relying on the validation
-                                   performed by the KDC.  At its option the
-                                   application server may still apply its
-                                   own validation based on a separate
-                                   policy for acceptance.
-
-          13      OK-AS-DELEGATE   This flag indicates that the server (not
-                                   the client) specified in the ticket has
-                                   been determined by policy of the realm
-                                   to be a suitable recipient of
-                                   delegation.  A client can use the
-                                   presence of this flag to help it make a
-                                   decision whether to delegate credentials
-                                   (either grant a proxy or a forwarded
-                                   ticket granting ticket) to this server.
-                                   The client is free to ignore the value
-                                   of this flag.  When setting this flag,
-                                   an administrator should consider the
-                                   Security and placement of the server on
-                                   which the service will run, as well as
-                                   whether the service requires the use of
-                                   delegated credentials.
-
-          14          ANONYMOUS
-                                   This flag indicates that  the  principal
-                                   named in the ticket is a generic princi-
-                                   pal for the realm and does not  identify
-                                   the  individual  using  the ticket.  The
-                                   purpose  of  the  ticket  is   only   to
-                                   securely  distribute  a session key, and
-                                   not to identify  the  user.   Subsequent
-                                   requests  using the same ticket and ses-
-                                   sion may be  considered  as  originating
-                                   from  the  same  user, but requests with
-                                   the same username but a different ticket
-                                   are  likely  to originate from different
-                                   users.
-
-          15-31       RESERVED
-                                   Reserved for future use.
-
-key
-     This field exists in the ticket and the KDC response and is used to
-     pass the session key from Kerberos to the application server and the
-     client. The field's encoding is described in section 6.2.
-crealm
-     This field contains the name of the realm in which the client is
-     registered and in which initial authentication took place.
-cname
-     This field contains the name part of the client's principal
-     identifier.
-transited
-     This field lists the names of the Kerberos realms that took part in
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-     authenticating the user to whom this ticket was issued. It does not
-     specify the order in which the realms were transited. See section
-     3.3.3.2 for details on how this field encodes the traversed realms.
-     When the names of CA's are to be embedded inthe transited field (as
-     specified for some extentions to the protocol), the X.500 names of the
-     CA's should be mapped into items in the transited field using the
-     mapping defined by RFC2253.
-authtime
-     This field indicates the time of initial authentication for the named
-     principal. It is the time of issue for the original ticket on which
-     this ticket is based. It is included in the ticket to provide
-     additional information to the end service, and to provide the
-     necessary information for implementation of a `hot list' service at
-     the KDC. An end service that is particularly paranoid could refuse to
-     accept tickets for which the initial authentication occurred "too far"
-     in the past. This field is also returned as part of the response from
-     the KDC. When returned as part of the response to initial
-     authentication (KRB_AS_REP), this is the current time on the Ker-
-     beros server[24].
-starttime
-     This field in the ticket specifies the time after which the ticket is
-     valid. Together with endtime, this field specifies the life of the
-     ticket. If it is absent from the ticket, its value should be treated
-     as that of the authtime field.
-endtime
-     This field contains the time after which the ticket will not be
-     honored (its expiration time). Note that individual services may place
-     their own limits on the life of a ticket and may reject tickets which
-     have not yet expired. As such, this is really an upper bound on the
-     expiration time for the ticket.
-renew-till
-     This field is only present in tickets that have the RENEWABLE flag set
-     in the flags field. It indicates the maximum endtime that may be
-     included in a renewal. It can be thought of as the absolute expiration
-     time for the ticket, including all renewals.
-caddr
-     This field in a ticket contains zero (if omitted) or more (if present)
-     host addresses. These are the addresses from which the ticket can be
-     used. If there are no addresses, the ticket can be used from any
-     location. The decision by the KDC to issue or by the end server to
-     accept zero-address tickets is a policy decision and is left to the
-     Kerberos and end-service administrators; they may refuse to issue or
-     accept such tickets. The suggested and default policy, however, is
-     that such tickets will only be issued or accepted when additional
-     information that can be used to restrict the use of the ticket is
-     included in the authorization_data field. Such a ticket is a
-     capability.
-
-     Network addresses are included in the ticket to make it harder for an
-     attacker to use stolen credentials. Because the session key is not
-     sent over the network in cleartext, credentials can't be stolen simply
-     by listening to the network; an attacker has to gain access to the
-     session key (perhaps through operating system security breaches or a
-     careless user's unattended session) to make use of stolen tickets.
-
-     It is important to note that the network address from which a
-     connection is received cannot be reliably determined. Even if it could
-     be, an attacker who has compromised the client's worksta- tion could
-     use the credentials from there. Including the network addresses only
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-     makes it more difficult, not impossible, for an attacker to walk off
-     with stolen credentials and then use them from a "safe" location.
-authorization-data
-     The authorization-data field is used to pass authorization data from
-     the principal on whose behalf a ticket was issued to the application
-     service. If no authorization data is included, this field will be left
-     out. Experience has shown that the name of this field is confusing,
-     and that a better name for this field would be restrictions.
-     Unfortunately, it is not possible to change the name of this field at
-     this time.
-
-     This field contains restrictions on any authority obtained on the
-     basis of authentication using the ticket. It is possible for any
-     principal in posession of credentials to add entries to the
-     authorization data field since these entries further restrict what can
-     be done with the ticket. Such additions can be made by specifying the
-     additional entries when a new ticket is obtained during the TGS
-     exchange, or they may be added during chained delegation using the
-     authorization data field of the authenticator.
-
-     Because entries may be added to this field by the holder of
-     credentials, it is not allowable for the presence of an entry in the
-     authorization data field of a ticket to amplify the priveleges one
-     would obtain from using a ticket.
-
-     The data in this field may be specific to the end service; the field
-     will contain the names of service specific objects, and the rights to
-     those objects. The format for this field is described in section 5.2.
-     Although Kerberos is not concerned with the format of the contents of
-     the sub-fields, it does carry type information (ad-type).
-
-     By using the authorization_data field, a principal is able to issue a
-     proxy that is valid for a specific purpose. For example, a client
-     wishing to print a file can obtain a file server proxy to be passed to
-     the print server. By specifying the name of the file in the
-     authorization_data field, the file server knows that the print server
-     can only use the client's rights when accessing the particular file to
-     be printed.
-
-     A separate service providing authorization or certifying group
-     membership may be built using the authorization-data field. In this
-     case, the entity granting authorization (not the authorized entity),
-     obtains a ticket in its own name (e.g. the ticket is issued in the
-     name of a privelege server), and this entity adds restrictions on its
-     own authority and delegates the restricted authority through a proxy
-     to the client. The client would then present this authorization
-     credential to the application server separately from the
-     authentication exchange.
-
-     Similarly, if one specifies the authorization-data field of a proxy
-     and leaves the host addresses blank, the resulting ticket and session
-     key can be treated as a capability. See [Neu93] for some suggested
-     uses of this field.
-
-     The authorization-data field is optional and does not have to be
-     included in a ticket.
-
-5.3.2. Authenticators
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-An authenticator is a record sent with a ticket to a server to certify the
-client's knowledge of the encryption key in the ticket, to help the server
-detect replays, and to help choose a "true session key" to use with the
-particular session. The encoding is encrypted in the ticket's session key
-shared by the client and the server:
-
--- Unencrypted authenticator
-Authenticator ::= [APPLICATION 2] SEQUENCE  {
-                  authenticator-vno[0]          INTEGER,
-                  crealm[1]                     Realm,
-                  cname[2]                      PrincipalName,
-                  cksum[3]                      Checksum OPTIONAL,
-                  cusec[4]                      INTEGER,
-                  ctime[5]                      KerberosTime,
-                  subkey[6]                     EncryptionKey OPTIONAL,
-                  seq-number[7]                 INTEGER OPTIONAL,
-                  authorization-data[8]         AuthorizationData OPTIONAL
-}
-
-
-authenticator-vno
-     This field specifies the version number for the format of the
-     authenticator. This document specifies version 5.
-crealm and cname
-     These fields are the same as those described for the ticket in section
-     5.3.1.
-cksum
-     This field contains a checksum of the the applica- tion data that
-     accompanies the KRB_AP_REQ.
-cusec
-     This field contains the microsecond part of the client's timestamp.
-     Its value (before encryption) ranges from 0 to 999999. It often
-     appears along with ctime. The two fields are used together to specify
-     a reasonably accurate timestamp.
-ctime
-     This field contains the current time on the client's host.
-subkey
-     This field contains the client's choice for an encryption key which is
-     to be used to protect this specific application session. Unless an
-     application specifies otherwise, if this field is left out the session
-     key from the ticket will be used.
-seq-number
-     This optional field includes the initial sequence number to be used by
-     the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to
-     detect replays (It may also be used by application specific messages).
-     When included in the authenticator this field specifies the initial
-     sequence number for messages from the client to the server. When
-     included in the AP-REP message, the initial sequence number is that
-     for messages from the server to the client. When used in KRB_PRIV or
-     KRB_SAFE messages, it is incremented by one after each message is
-     sent. Sequence numbers fall in the range of 0 through 2^32 - 1 and
-     wrap to zero following the value 2^32 - 1.
-
-     For sequence numbers to adequately support the detection of replays
-     they should be non-repeating, even across connection boundaries. The
-     initial sequence number should be random and uniformly distributed
-     across the full space of possible sequence numbers, so that it cannot
-     be guessed by an attacker and so that it and the successive sequence
-     numbers do not repeat other sequences.
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-authorization-data
-     This field is the same as described for the ticket in section 5.3.1.
-     It is optional and will only appear when additional restrictions are
-     to be placed on the use of a ticket, beyond those carried in the
-     ticket itself.
-
-5.4. Specifications for the AS and TGS exchanges
-
-This section specifies the format of the messages used in the exchange
-between the client and the Kerberos server. The format of possible error
-messages appears in section 5.9.1.
-
-5.4.1. KRB_KDC_REQ definition
-
-The KRB_KDC_REQ message has no type of its own. Instead, its type is one of
-KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an
-initial ticket or an additional ticket. In either case, the message is sent
-from the client to the Authentication Server to request credentials for a
-service.
-
-The message fields are:
-
-AS-REQ ::=         [APPLICATION 10] KDC-REQ
-TGS-REQ ::=        [APPLICATION 12] KDC-REQ
-
-KDC-REQ ::=        SEQUENCE {
-                   pvno[1]            INTEGER,
-                   msg-type[2]        INTEGER,
-                   padata[3]          SEQUENCE OF PA-DATA OPTIONAL,
-                   req-body[4]        KDC-REQ-BODY
-}
-
-PA-DATA ::=        SEQUENCE {
-                   padata-type[1]     INTEGER,
-                   padata-value[2]    OCTET STRING,
-                                      -- might be encoded AP-REQ
-}
-
-KDC-REQ-BODY ::=   SEQUENCE {
-                    kdc-options[0]         KDCOptions,
-                    cname[1]               PrincipalName OPTIONAL,
-                                           -- Used only in AS-REQ
-                    realm[2]               Realm, -- Server's realm
-                                           -- Also client's in AS-REQ
-                    sname[3]               PrincipalName OPTIONAL,
-                    from[4]                KerberosTime OPTIONAL,
-                    till[5]                KerberosTime OPTIONAL,
-                    rtime[6]               KerberosTime OPTIONAL,
-                    nonce[7]               INTEGER,
-                    etype[8]               SEQUENCE OF INTEGER,
-                                           -- EncryptionType,
-                                           -- in preference order
-                    addresses[9]           HostAddresses OPTIONAL,
-                enc-authorization-data[10] EncryptedData OPTIONAL,
-                                           -- Encrypted AuthorizationData
-                                           -- encoding
-                    additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
-}
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-The fields in this message are:
-
-pvno
-     This field is included in each message, and specifies the protocol
-     version number. This document specifies protocol version 5.
-msg-type
-     This field indicates the type of a protocol message. It will almost
-     always be the same as the application identifier associated with a
-     message. It is included to make the identifier more readily accessible
-     to the application. For the KDC-REQ message, this type will be
-     KRB_AS_REQ or KRB_TGS_REQ.
-padata
-     The padata (pre-authentication data) field contains a sequence of
-     authentication information which may be needed before credentials can
-     be issued or decrypted. In the case of requests for additional tickets
-     (KRB_TGS_REQ), this field will include an element with padata-type of
-     PA-TGS-REQ and data of an authentication header (ticket-granting
-     ticket and authenticator). The checksum in the authenticator (which
-     must be collision-proof) is to be computed over the KDC-REQ-BODY
-     encoding. In most requests for initial authentication (KRB_AS_REQ) and
-     most replies (KDC-REP), the padata field will be left out.
-
-     This field may also contain information needed by certain extensions
-     to the Kerberos protocol. For example, it might be used to initially
-     verify the identity of a client before any response is returned. This
-     is accomplished with a padata field with padata-type equal to
-     PA-ENC-TIMESTAMP and padata-value defined as follows:
-
-     padata-type     ::= PA-ENC-TIMESTAMP
-     padata-value    ::= EncryptedData -- PA-ENC-TS-ENC
-
-     PA-ENC-TS-ENC   ::= SEQUENCE {
-                     patimestamp[0]     KerberosTime, -- client's time
-                     pausec[1]          INTEGER OPTIONAL
-     }
-
-     with patimestamp containing the client's time and pausec containing
-     the microseconds which may be omitted if a client will not generate
-     more than one request per second. The ciphertext (padata-value)
-     consists of the PA-ENC-TS-ENC sequence, encrypted using the client's
-     secret key.
-
-     [use-specified-kvno item is here for discussion and may be removed] It
-     may also be used by the client to specify the version of a key that is
-     being used for accompanying preauthentication, and/or which should be
-     used to encrypt the reply from the KDC.
-
-     PA-USE-SPECIFIED-KVNO  ::=  Integer
-
-     The KDC should only accept and abide by the value of the
-     use-specified-kvno preauthentication data field when the specified key
-     is still valid and until use of a new key is confirmed. This situation
-     is likely to occur primarily during the period during which an updated
-     key is propagating to other KDC's in a realm.
-
-     The padata field can also contain information needed to help the KDC
-     or the client select the key needed for generating or decrypting the
-     response. This form of the padata is useful for supporting the use of
-     certain token cards with Kerberos. The details of such extensions are
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-     specified in separate documents. See [Pat92] for additional uses of
-     this field.
-padata-type
-     The padata-type element of the padata field indicates the way that the
-     padata-value element is to be interpreted. Negative values of
-     padata-type are reserved for unregistered use; non-negative values are
-     used for a registered interpretation of the element type.
-req-body
-     This field is a placeholder delimiting the extent of the remaining
-     fields. If a checksum is to be calculated over the request, it is
-     calculated over an encoding of the KDC-REQ-BODY sequence which is
-     enclosed within the req-body field.
-kdc-options
-     This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the
-     KDC and indicates the flags that the client wants set on the tickets
-     as well as other information that is to modify the behavior of the
-     KDC. Where appropriate, the name of an option may be the same as the
-     flag that is set by that option. Although in most case, the bit in the
-     options field will be the same as that in the flags field, this is not
-     guaranteed, so it is not acceptable to simply copy the options field
-     to the flags field. There are various checks that must be made before
-     honoring an option anyway.
-
-     The kdc_options field is a bit-field, where the selected options are
-     indicated by the bit being set (1), and the unselected options and
-     reserved fields being reset (0). The encoding of the bits is specified
-     in section 5.2. The options are described in more detail above in
-     section 2. The meanings of the options are:
-
-        Bit(s)    Name                Description
-         0        RESERVED
-                                      Reserved for future  expansion  of
-this
-                                      field.
-
-         1        FORWARDABLE
-                                      The FORWARDABLE  option  indicates
-that
-                                      the  ticket  to be issued is to have
-its
-                                      forwardable flag set.  It  may  only
-be
-                                      set on the initial request, or in a
-sub-
-                                      sequent request if  the
-ticket-granting
-                                      ticket on which it is based is also
-for-
-                                      wardable.
-
-         2        FORWARDED
-                                      The FORWARDED option is  only
-specified
-                                      in  a  request  to  the
-ticket-granting
-                                      server and will only be honored  if
-the
-                                      ticket-granting  ticket  in  the
-request
-                                      has  its  FORWARDABLE  bit  set.
-This
-                                      option  indicates that this is a
-request
-                                      for forwarding.  The address(es) of
-the
-                                      host  from which the resulting ticket
-is
-                                      to  be  valid  are   included   in
-the
-                                      addresses field of the request.
-
-         3        PROXIABLE
-                                      The PROXIABLE option indicates that
-the
-                                      ticket to be issued is to have its
-prox-
-                                      iable flag set.  It may only be  set
-on
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-                                      the  initial request, or in a
-subsequent
-                                      request if the ticket-granting ticket
-on
-                                      which it is based is also proxiable.
-
-         4        PROXY
-                                      The PROXY option indicates that this
-is
-                                      a request for a proxy.  This option
-will
-                                      only be honored if  the
-ticket-granting
-                                      ticket  in the request has its
-PROXIABLE
-                                      bit set.  The address(es)  of  the
-host
-                                      from which the resulting ticket is to
-be
-                                       valid  are  included  in  the
-addresses
-                                      field of the request.
-
-         5        ALLOW-POSTDATE
-                                      The ALLOW-POSTDATE option indicates
-that
-                                      the  ticket  to be issued is to have
-its
-                                      MAY-POSTDATE flag set.  It may  only
-be
-                                      set on the initial request, or in a
-sub-
-                                      sequent request if  the
-ticket-granting
-                                      ticket on which it is based also has
-its
-                                      MAY-POSTDATE flag set.
-
-         6        POSTDATED
-                                      The POSTDATED option indicates that
-this
-                                      is  a  request  for  a postdated
-ticket.
-                                      This option will only be honored if
-the
-                                      ticket-granting  ticket  on  which
-                                      it is based has  its  MAY-POSTDATE
-                                      flag set.
-                                      The  resulting ticket will also have
-its
-                                      INVALID flag set, and that flag  may
-be
-                                      reset by a subsequent request to the
-KDC
-                                      after the starttime in  the  ticket
-has
-                                      been reached.
-
-         7        UNUSED
-                                      This option is presently unused.
-
-         8        RENEWABLE
-                                      The RENEWABLE option indicates that
-the
-                                      ticket  to  be  issued  is  to  have
-its
-                                      RENEWABLE flag set.  It may only be
-set
-                                      on  the  initial  request,  or  when
-the
-                                      ticket-granting  ticket  on  which
-the
-                                      request  is based is also renewable.
-If
-                                      this option is requested, then the
-rtime
-                                      field   in   the  request  contains
-the
-                                      desired absolute expiration time for
-the
-                                      ticket.
-
-         9-13     UNUSED
-                                      These options are presently unused.
-
-         14       REQUEST-ANONYMOUS
-                                      The REQUEST-ANONYMOUS  option
-indicates
-                                      that  the  ticket to be issued is not
-to
-                                      identify  the  user  to  which  it
-was
-                                      issued.  Instead, the principal
-identif-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-                                      ier is to be generic,  as  specified
-by
-                                      the  policy  of  the realm (e.g.
-usually
-                                      anonymous@realm).  The  purpose  of
-the
-                                      ticket  is only to securely distribute
-a
-                                      session key, and  not  to  identify
-the
-                                      user.   The ANONYMOUS flag on the
-ticket
-                                      to be returned should be  set.   If
-the
-                                      local  realms  policy  does  not
-permit
-                                      anonymous credentials, the request is
-to
-                                      be rejected.
-
-         15-25    RESERVED
-                                      Reserved for future use.
-
-         26       DISABLE-TRANSITED-CHECK
-                                      By default the KDC will check the
-                                      transited field of a ticket-granting-
-                                      ticket against the policy of the local
-                                      realm before it will issue derivative
-                                      tickets based on the ticket granting
-                                      ticket.  If this flag is set in the
-                                      request, checking of the transited
-field
-                                      is disabled.  Tickets issued without
-the
-                                      performance of this check will be
-noted
-                                      by the reset (0) value of the
-                                      TRANSITED-POLICY-CHECKED flag,
-                                      indicating to the application server
-                                      that the tranisted field must be
-checked
-                                      locally.  KDC's are encouraged but not
-                                      required to honor the
-                                      DISABLE-TRANSITED-CHECK option.
-
-         27       RENEWABLE-OK
-                                      The RENEWABLE-OK option indicates that
-a
-                                      renewable ticket will be acceptable if
-a
-                                      ticket with the  requested  life
-cannot
-                                      otherwise be provided.  If a ticket
-with
-                                      the requested life cannot  be
-provided,
-                                      then  a  renewable  ticket may be
-issued
-                                      with  a  renew-till  equal  to  the
-the
-                                      requested  endtime.   The  value  of
-the
-                                      renew-till field may still be limited
-by
-                                      local  limits, or limits selected by
-the
-                                      individual principal or server.
-
-         28       ENC-TKT-IN-SKEY
-                                      This option is used only by the
-ticket-
-                                      granting  service.   The
-ENC-TKT-IN-SKEY
-                                      option indicates that the ticket for
-the
-                                      end  server  is  to  be encrypted in
-the
-                                      session key from the additional
-ticket-
-                                      granting ticket provided.
-
-         29       RESERVED
-                                      Reserved for future use.
-
-         30       RENEW
-                                      This option is used only by the
-ticket-
-                                      granting   service.   The  RENEW
-option
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-                                      indicates that the  present  request
-is
-                                      for  a  renewal.  The ticket provided
-is
-                                      encrypted in  the  secret  key  for
-the
-                                      server  on  which  it  is  valid.
-This
-                                      option  will  only  be  honored  if
-the
-                                      ticket  to  be renewed has its
-RENEWABLE
-                                      flag set and if the time in  its
-renew-
-                                      till  field  has not passed.  The
-ticket
-                                      to be renewed is passed  in  the
-padata
-                                      field  as  part  of  the
-authentication
-                                      header.
-
-         31       VALIDATE
-                                      This option is used only by the
-ticket-
-                                      granting  service.   The VALIDATE
-option
-                                      indicates that the request is  to
-vali-
-                                      date  a  postdated ticket.  It will
-only
-                                      be honored if the  ticket  presented
-is
-                                      postdated,  presently  has  its
-INVALID
-                                      flag set, and would be otherwise
-usable
-                                      at  this time.  A ticket cannot be
-vali-
-                                      dated before its starttime.  The
-ticket
-                                      presented for validation is encrypted
-in
-                                      the key of the server for  which  it
-is
-                                      valid  and is passed in the padata
-field
-                                      as part of the authentication header.
-
-cname and sname
-     These fields are the same as those described for the ticket in section
-     5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is
-     specified. If absent, the name of the server is taken from the name of
-     the client in the ticket passed as additional-tickets.
-enc-authorization-data
-     The enc-authorization-data, if present (and it can only be present in
-     the TGS_REQ form), is an encoding of the desired authorization-data
-     encrypted under the sub-session key if present in the Authenticator,
-     or alternatively from the session key in the ticket-granting ticket,
-     both from the padata field in the KRB_AP_REQ.
-realm
-     This field specifies the realm part of the server's principal
-     identifier. In the AS exchange, this is also the realm part of the
-     client's principal identifier.
-from
-     This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
-     requests when the requested ticket is to be postdated. It specifies
-     the desired start time for the requested ticket. If this field is
-     omitted then the KDC should use the current time instead.
-till
-     This field contains the expiration date requested by the client in a
-     ticket request. It is optional and if omitted the requested ticket is
-     to have the maximum endtime permitted according to KDC policy for the
-     parties to the authentication exchange as limited by expiration date
-     of the ticket granting ticket or other preauthentication credentials.
-rtime
-     This field is the requested renew-till time sent from a client to the
-     KDC in a ticket request. It is optional.
-nonce
-     This field is part of the KDC request and response. It it intended to
-     hold a random number generated by the client. If the same number is
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-     included in the encrypted response from the KDC, it provides evidence
-     that the response is fresh and has not been replayed by an attacker.
-     Nonces must never be re-used. Ideally, it should be generated
-     randomly, but if the correct time is known, it may suffice[25].
-etype
-     This field specifies the desired encryption algorithm to be used in
-     the response.
-addresses
-     This field is included in the initial request for tickets, and
-     optionally included in requests for additional tickets from the
-     ticket-granting server. It specifies the addresses from which the
-     requested ticket is to be valid. Normally it includes the addresses
-     for the client's host. If a proxy is requested, this field will
-     contain other addresses. The contents of this field are usually copied
-     by the KDC into the caddr field of the resulting ticket.
-additional-tickets
-     Additional tickets may be optionally included in a request to the
-     ticket-granting server. If the ENC-TKT-IN-SKEY option has been
-     specified, then the session key from the additional ticket will be
-     used in place of the server's key to encrypt the new ticket. If more
-     than one option which requires additional tickets has been specified,
-     then the additional tickets are used in the order specified by the
-     ordering of the options bits (see kdc-options, above).
-
-The application code will be either ten (10) or twelve (12) depending on
-whether the request is for an initial ticket (AS-REQ) or for an additional
-ticket (TGS-REQ).
-
-The optional fields (addresses, authorization-data and additional-tickets)
-are only included if necessary to perform the operation specified in the
-kdc-options field.
-
-It should be noted that in KRB_TGS_REQ, the protocol version number appears
-twice and two different message types appear: the KRB_TGS_REQ message
-contains these fields as does the authentication header (KRB_AP_REQ) that
-is passed in the padata field.
-
-5.4.2. KRB_KDC_REP definition
-
-The KRB_KDC_REP message format is used for the reply from the KDC for
-either an initial (AS) request or a subsequent (TGS) request. There is no
-message type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP
-or KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply
-depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in
-the client's secret key, and the client's key version number is included in
-the key version number for the encrypted data. For KRB_TGS_REP, the
-ciphertext is encrypted in the sub-session key from the Authenticator, or
-if absent, the session key from the ticket-granting ticket used in the
-request. In that case, no version number will be present in the
-EncryptedData sequence.
-
-The KRB_KDC_REP message contains the following fields:
-
-AS-REP ::=    [APPLICATION 11] KDC-REP
-TGS-REP ::=   [APPLICATION 13] KDC-REP
-
-KDC-REP ::=   SEQUENCE {
-              pvno[0]                    INTEGER,
-              msg-type[1]                INTEGER,
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-              padata[2]                  SEQUENCE OF PA-DATA OPTIONAL,
-              crealm[3]                  Realm,
-              cname[4]                   PrincipalName,
-              ticket[5]                  Ticket,
-              enc-part[6]                EncryptedData
-}
-
-EncASRepPart ::=    [APPLICATION 25[27]] EncKDCRepPart
-EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart
-
-EncKDCRepPart ::=   SEQUENCE {
-                    key[0]               EncryptionKey,
-                    last-req[1]          LastReq,
-                    nonce[2]             INTEGER,
-                    key-expiration[3]    KerberosTime OPTIONAL,
-                    flags[4]             TicketFlags,
-                    authtime[5]          KerberosTime,
-                    starttime[6]         KerberosTime OPTIONAL,
-                    endtime[7]           KerberosTime,
-                    renew-till[8]        KerberosTime OPTIONAL,
-                    srealm[9]            Realm,
-                    sname[10]            PrincipalName,
-                    caddr[11]            HostAddresses OPTIONAL
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is either
-     KRB_AS_REP or KRB_TGS_REP.
-padata
-     This field is described in detail in section 5.4.1. One possible use
-     for this field is to encode an alternate "mix-in" string to be used
-     with a string-to-key algorithm (such as is described in section
-     6.3.2). This ability is useful to ease transitions if a realm name
-     needs to change (e.g. when a company is acquired); in such a case all
-     existing password-derived entries in the KDC database would be flagged
-     as needing a special mix-in string until the next password change.
-crealm, cname, srealm and sname
-     These fields are the same as those described for the ticket in section
-     5.3.1.
-ticket
-     The newly-issued ticket, from section 5.3.1.
-enc-part
-     This field is a place holder for the ciphertext and related
-     information that forms the encrypted part of a message. The
-     description of the encrypted part of the message follows each
-     appearance of this field. The encrypted part is encoded as described
-     in section 6.1.
-key
-     This field is the same as described for the ticket in section 5.3.1.
-last-req
-     This field is returned by the KDC and specifies the time(s) of the
-     last request by a principal. Depending on what information is
-     available, this might be the last time that a request for a
-     ticket-granting ticket was made, or the last time that a request based
-     on a ticket-granting ticket was successful. It also might cover all
-     servers for a realm, or just the particular server. Some
-     implementations may display this information to the user to aid in
-     discovering unauthorized use of one's identity. It is similar in
-     spirit to the last login time displayed when logging into timesharing
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-     systems.
-nonce
-     This field is described above in section 5.4.1.
-key-expiration
-     The key-expiration field is part of the response from the KDC and
-     specifies the time that the client's secret key is due to expire. The
-     expiration might be the result of password aging or an account
-     expiration. This field will usually be left out of the TGS reply since
-     the response to the TGS request is encrypted in a session key and no
-     client information need be retrieved from the KDC database. It is up
-     to the application client (usually the login program) to take
-     appropriate action (such as notifying the user) if the expiration time
-     is imminent.
-flags, authtime, starttime, endtime, renew-till and caddr
-     These fields are duplicates of those found in the encrypted portion of
-     the attached ticket (see section 5.3.1), provided so the client may
-     verify they match the intended request and to assist in proper ticket
-     caching. If the message is of type KRB_TGS_REP, the caddr field will
-     only be filled in if the request was for a proxy or forwarded ticket,
-     or if the user is substituting a subset of the addresses from the
-     ticket granting ticket. If the client-requested addresses are not
-     present or not used, then the addresses contained in the ticket will
-     be the same as those included in the ticket-granting ticket.
-
-5.5. Client/Server (CS) message specifications
-
-This section specifies the format of the messages used for the
-authentication of the client to the application server.
-
-5.5.1. KRB_AP_REQ definition
-
-The KRB_AP_REQ message contains the Kerberos protocol version number, the
-message type KRB_AP_REQ, an options field to indicate any options in use,
-and the ticket and authenticator themselves. The KRB_AP_REQ message is
-often referred to as the 'authentication header'.
-
-AP-REQ ::=      [APPLICATION 14] SEQUENCE {
-                pvno[0]                       INTEGER,
-                msg-type[1]                   INTEGER,
-                ap-options[2]                 APOptions,
-                ticket[3]                     Ticket,
-                authenticator[4]              EncryptedData
-}
-
-APOptions ::=   BIT STRING {
-                reserved(0),
-                use-session-key(1),
-                mutual-required(2)
-}
-
-
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_AP_REQ.
-ap-options
-     This field appears in the application request (KRB_AP_REQ) and affects
-     the way the request is processed. It is a bit-field, where the
-     selected options are indicated by the bit being set (1), and the
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-     unselected options and reserved fields being reset (0). The encoding
-     of the bits is specified in section 5.2. The meanings of the options
-     are:
-
-          Bit(s)   Name              Description
-
-          0        RESERVED
-                                     Reserved for future  expansion  of
-this
-                                     field.
-
-          1        USE-SESSION-KEY
-                                     The  USE-SESSION-KEY  option
-indicates
-                                     that the ticket the client is
-presenting
-                                     to a server is encrypted in the
-session
-                                     key  from  the  server's
-ticket-granting
-                                     ticket.  When this option is not
-speci-
-                                     fied,  the  ticket  is  encrypted in
-the
-                                     server's secret key.
-
-          2        MUTUAL-REQUIRED
-                                     The  MUTUAL-REQUIRED  option  tells
-the
-                                     server  that  the client requires
-mutual
-                                     authentication, and that it must
-respond
-                                     with a KRB_AP_REP message.
-
-          3-31     RESERVED
-                                     Reserved for future use.
-
-ticket
-     This field is a ticket authenticating the client to the server.
-authenticator
-     This contains the authenticator, which includes the client's choice of
-     a subkey. Its encoding is described in section 5.3.2.
-
-5.5.2. KRB_AP_REP definition
-
-The KRB_AP_REP message contains the Kerberos protocol version number, the
-message type, and an encrypted time- stamp. The message is sent in in
-response to an application request (KRB_AP_REQ) where the mutual
-authentication option has been selected in the ap-options field.
-
-AP-REP ::=         [APPLICATION 15] SEQUENCE {
-                   pvno[0]                           INTEGER,
-                   msg-type[1]                       INTEGER,
-                   enc-part[2]                       EncryptedData
-}
-
-EncAPRepPart ::=   [APPLICATION 27[29]] SEQUENCE {
-                   ctime[0]                          KerberosTime,
-                   cusec[1]                          INTEGER,
-                   subkey[2]                         EncryptionKey OPTIONAL,
-                   seq-number[3]                     INTEGER OPTIONAL
-}
-
-The encoded EncAPRepPart is encrypted in the shared session key of the
-ticket. The optional subkey field can be used in an application-arranged
-negotiation to choose a per association session key.
-
-pvno and msg-type
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_AP_REP.
-enc-part
-     This field is described above in section 5.4.2.
-ctime
-     This field contains the current time on the client's host.
-cusec
-     This field contains the microsecond part of the client's timestamp.
-subkey
-     This field contains an encryption key which is to be used to protect
-     this specific application session. See section 3.2.6 for specifics on
-     how this field is used to negotiate a key. Unless an application
-     specifies otherwise, if this field is left out, the sub-session key
-     from the authenticator, or if also left out, the session key from the
-     ticket will be used.
-
-5.5.3. Error message reply
-
-If an error occurs while processing the application request, the KRB_ERROR
-message will be sent in response. See section 5.9.1 for the format of the
-error message. The cname and crealm fields may be left out if the server
-cannot determine their appropriate values from the corresponding KRB_AP_REQ
-message. If the authenticator was decipherable, the ctime and cusec fields
-will contain the values from it.
-
-5.6. KRB_SAFE message specification
-
-This section specifies the format of a message that can be used by either
-side (client or server) of an application to send a tamper-proof message to
-its peer. It presumes that a session key has previously been exchanged (for
-example, by using the KRB_AP_REQ/KRB_AP_REP messages).
-
-5.6.1. KRB_SAFE definition
-
-The KRB_SAFE message contains user data along with a collision-proof
-checksum keyed with the last encryption key negotiated via subkeys, or the
-session key if no negotiation has occured. The message fields are:
-
-KRB-SAFE ::=        [APPLICATION 20] SEQUENCE {
-                    pvno[0]                       INTEGER,
-                    msg-type[1]                   INTEGER,
-                    safe-body[2]                  KRB-SAFE-BODY,
-                    cksum[3]                      Checksum
-}
-
-KRB-SAFE-BODY ::=   SEQUENCE {
-                    user-data[0]                  OCTET STRING,
-                    timestamp[1]                  KerberosTime OPTIONAL,
-                    usec[2]                       INTEGER OPTIONAL,
-                    seq-number[3]                 INTEGER OPTIONAL,
-                    s-address[4]                  HostAddress OPTIONAL,
-                    r-address[5]                  HostAddress OPTIONAL
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_SAFE.
-safe-body
-     This field is a placeholder for the body of the KRB-SAFE message.
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-cksum
-     This field contains the checksum of the application data. Checksum
-     details are described in section 6.4. The checksum is computed over
-     the encoding of the KRB-SAFE sequence. First, the cksum is zeroed and
-     the checksum is computed over the encoding of the KRB-SAFE sequence,
-     then the checksum is set to the result of that computation, and
-     finally the KRB-SAFE sequence is encoded again.
-user-data
-     This field is part of the KRB_SAFE and KRB_PRIV messages and contain
-     the application specific data that is being passed from the sender to
-     the recipient.
-timestamp
-     This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents
-     are the current time as known by the sender of the message. By
-     checking the timestamp, the recipient of the message is able to make
-     sure that it was recently generated, and is not a replay.
-usec
-     This field is part of the KRB_SAFE and KRB_PRIV headers. It contains
-     the microsecond part of the timestamp.
-seq-number
-     This field is described above in section 5.3.2.
-s-address
-     This field specifies the address in use by the sender of the message.
-r-address
-     This field specifies the address in use by the recipient of the
-     message. It may be omitted for some uses (such as broadcast
-     protocols), but the recipient may arbitrarily reject such messages.
-     This field along with s-address can be used to help detect messages
-     which have been incorrectly or maliciously delivered to the wrong
-     recipient.
-
-5.7. KRB_PRIV message specification
-
-This section specifies the format of a message that can be used by either
-side (client or server) of an application to securely and privately send a
-message to its peer. It presumes that a session key has previously been
-exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
-
-5.7.1. KRB_PRIV definition
-
-The KRB_PRIV message contains user data encrypted in the Session Key. The
-message fields are:
-
-KRB-PRIV ::=         [APPLICATION 21] SEQUENCE {
-                     pvno[0]                           INTEGER,
-                     msg-type[1]                       INTEGER,
-                     enc-part[3]                       EncryptedData
-}
-
-EncKrbPrivPart ::=   [APPLICATION 28[31]] SEQUENCE {
-                     user-data[0]        OCTET STRING,
-                     timestamp[1]        KerberosTime OPTIONAL,
-                     usec[2]             INTEGER OPTIONAL,
-                     seq-number[3]       INTEGER OPTIONAL,
-                     s-address[4]        HostAddress OPTIONAL, -- sender's
-addr
-                     r-address[5]        HostAddress OPTIONAL -- recip's
-addr
-}
-
-pvno and msg-type
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_PRIV.
-enc-part
-     This field holds an encoding of the EncKrbPrivPart sequence encrypted
-     under the session key[32]. This encrypted encoding is used for the
-     enc-part field of the KRB-PRIV message. See section 6 for the format
-     of the ciphertext.
-user-data, timestamp, usec, s-address and r-address
-     These fields are described above in section 5.6.1.
-seq-number
-     This field is described above in section 5.3.2.
-
-5.8. KRB_CRED message specification
-
-This section specifies the format of a message that can be used to send
-Kerberos credentials from one principal to another. It is presented here to
-encourage a common mechanism to be used by applications when forwarding
-tickets or providing proxies to subordinate servers. It presumes that a
-session key has already been exchanged perhaps by using the
-KRB_AP_REQ/KRB_AP_REP messages.
-
-5.8.1. KRB_CRED definition
-
-The KRB_CRED message contains a sequence of tickets to be sent and
-information needed to use the tickets, including the session key from each.
-The information needed to use the tickets is encrypted under an encryption
-key previously exchanged or transferred alongside the KRB_CRED message. The
-message fields are:
-
-KRB-CRED         ::= [APPLICATION 22]   SEQUENCE {
-                 pvno[0]                INTEGER,
-                 msg-type[1]            INTEGER, -- KRB_CRED
-                 tickets[2]             SEQUENCE OF Ticket,
-                 enc-part[3]            EncryptedData
-}
-
-EncKrbCredPart   ::= [APPLICATION 29]   SEQUENCE {
-                 ticket-info[0]         SEQUENCE OF KrbCredInfo,
-                 nonce[1]               INTEGER OPTIONAL,
-                 timestamp[2]           KerberosTime OPTIONAL,
-                 usec[3]                INTEGER OPTIONAL,
-                 s-address[4]           HostAddress OPTIONAL,
-                 r-address[5]           HostAddress OPTIONAL
-}
-
-KrbCredInfo      ::=                    SEQUENCE {
-                 key[0]                 EncryptionKey,
-                 prealm[1]              Realm OPTIONAL,
-                 pname[2]               PrincipalName OPTIONAL,
-                 flags[3]               TicketFlags OPTIONAL,
-                 authtime[4]            KerberosTime OPTIONAL,
-                 starttime[5]           KerberosTime OPTIONAL,
-                 endtime[6]             KerberosTime OPTIONAL
-                 renew-till[7]          KerberosTime OPTIONAL,
-                 srealm[8]              Realm OPTIONAL,
-                 sname[9]               PrincipalName OPTIONAL,
-                 caddr[10]              HostAddresses OPTIONAL
-}
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_CRED.
-tickets
-     These are the tickets obtained from the KDC specifically for use by
-     the intended recipient. Successive tickets are paired with the
-     corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED
-     message.
-enc-part
-     This field holds an encoding of the EncKrbCredPart sequence encrypted
-     under the session key shared between the sender and the intended
-     recipient. This encrypted encoding is used for the enc-part field of
-     the KRB-CRED message. See section 6 for the format of the ciphertext.
-nonce
-     If practical, an application may require the inclusion of a nonce
-     generated by the recipient of the message. If the same value is
-     included as the nonce in the message, it provides evidence that the
-     message is fresh and has not been replayed by an attacker. A nonce
-     must never be re-used; it should be generated randomly by the
-     recipient of the message and provided to the sender of the message in
-     an application specific manner.
-timestamp and usec
-     These fields specify the time that the KRB-CRED message was generated.
-     The time is used to provide assurance that the message is fresh.
-s-address and r-address
-     These fields are described above in section 5.6.1. They are used
-     optionally to provide additional assurance of the integrity of the
-     KRB-CRED message.
-key
-     This field exists in the corresponding ticket passed by the KRB-CRED
-     message and is used to pass the session key from the sender to the
-     intended recipient. The field's encoding is described in section 6.2.
-
-The following fields are optional. If present, they can be associated with
-the credentials in the remote ticket file. If left out, then it is assumed
-that the recipient of the credentials already knows their value.
-
-prealm and pname
-     The name and realm of the delegated principal identity.
-flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr
-     These fields contain the values of the correspond- ing fields from the
-     ticket found in the ticket field. Descriptions of the fields are
-     identical to the descriptions in the KDC-REP message.
-
-5.9. Error message specification
-
-This section specifies the format for the KRB_ERROR message. The fields
-included in the message are intended to return as much information as
-possible about an error. It is not expected that all the information
-required by the fields will be available for all types of errors. If the
-appropriate information is not available when the message is composed, the
-corresponding field will be left out of the message.
-
-Note that since the KRB_ERROR message is not protected by any encryption,
-it is quite possible for an intruder to synthesize or modify such a
-message. In particular, this means that the client should not use any
-fields in this message for security-critical purposes, such as setting a
-system clock or generating a fresh authenticator. The message can be
-useful, however, for advising a user on the reason for some failure.
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-5.9.1. KRB_ERROR definition
-
-The KRB_ERROR message consists of the following fields:
-
-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-cksum[13]                   Checksum OPTIONAL,
-                e-typed-data[14]              SEQUENCE of ETypedData
-OPTIONAL
-}
-
-ETypedData ::=  SEQUENCE {
-                e-data-type    [1] INTEGER,
-                e-data-value   [2] OCTET STRING,
-}
-
-
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_ERROR.
-ctime
-     This field is described above in section 5.4.1.
-cusec
-     This field is described above in section 5.5.2.
-stime
-     This field contains the current time on the server. It is of type
-     KerberosTime.
-susec
-     This field contains the microsecond part of the server's timestamp.
-     Its value ranges from 0 to 999999. It appears along with stime. The
-     two fields are used in conjunction to specify a reasonably accurate
-     timestamp.
-error-code
-     This field contains the error code returned by Kerberos or the server
-     when a request fails. To interpret the value of this field see the
-     list of error codes in section 8. Implementations are encouraged to
-     provide for national language support in the display of error
-     messages.
-crealm, cname, srealm and sname
-     These fields are described above in section 5.3.1.
-e-text
-     This field contains additional text to help explain the error code
-     associated with the failed request (for example, it might include a
-     principal name which was unknown).
-e-data
-     This field contains additional data about the error for use by the
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-     application to help it recover from or handle the error. If the
-     errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
-     contain an encoding of a sequence of padata fields, each corresponding
-     to an acceptable pre-authentication method and optionally containing
-     data for the method:
-
-     METHOD-DATA ::=   SEQUENCE of PA-DATA
-
-     If the error-code is KRB_AP_ERR_METHOD, then the e-data field will
-     contain an encoding of the following sequence:
-
-     METHOD-DATA ::=   SEQUENCE {
-                         method-type[0]   INTEGER,
-                         method-data[1]   OCTET STRING OPTIONAL
-     }
-
-     method-type will indicate the required alternate method; method-data
-     will contain any required additional information.
-e-cksum
-     This field contains an optional checksum for the KRB-ERROR message.
-     The checksum is calculated over the Kerberos ASN.1 encoding of the
-     KRB-ERROR message with the checksum absent. The checksum is then added
-     to the KRB-ERROR structure and the message is re-encoded. The Checksum
-     should be calculated using the session key from the ticket granting
-     ticket or service ticket, where available. If the error is in response
-     to a TGS or AP request, the checksum should be calculated uing the the
-     session key from the client's ticket. If the error is in response to
-     an AS request, then the checksum should be calulated using the
-     client's secret key ONLY if there has been suitable preauthentication
-     to prove knowledge of the secret key by the client[33]. If a checksum
-     can not be computed because the key to be used is not available, no
-     checksum will be included.
-e-typed-data
-     [This field for discussion, may be deleted from final spec] This field
-     contains optional data that may be used to help the client recover
-     from the indicated error. [This could contain the METHOD-DATA
-     specified since I don't think anyone actually uses it yet. It could
-     also contain the PA-DATA sequence for the preauth required error if we
-     had a clear way to transition to the use of this field from the use of
-     the untype e-data field.] For example, this field may specify the key
-     version of the key used to verify preauthentication:
-
-     e-data-type  := 20 -- Key version number
-     e-data-value := Integer -- Key version number used to verify
-preauthentication
-
-6. Encryption and Checksum Specifications
-
-The Kerberos protocols described in this document are designed to use
-stream encryption ciphers, which can be simulated using commonly available
-block encryption ciphers, such as the Data Encryption Standard, [DES77] in
-conjunction with block chaining and checksum methods [DESM80]. Encryption
-is used to prove the identities of the network entities participating in
-message exchanges. The Key Distribution Center for each realm is trusted by
-all principals registered in that realm to store a secret key in
-confidence. Proof of knowledge of this secret key is used to verify the
-authenticity of a principal.
-
-The KDC uses the principal's secret key (in the AS exchange) or a shared
-session key (in the TGS exchange) to encrypt responses to ticket requests;
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-the ability to obtain the secret key or session key implies the knowledge
-of the appropriate keys and the identity of the KDC. The ability of a
-principal to decrypt the KDC response and present a Ticket and a properly
-formed Authenticator (generated with the session key from the KDC response)
-to a service verifies the identity of the principal; likewise the ability
-of the service to extract the session key from the Ticket and prove its
-knowledge thereof in a response verifies the identity of the service.
-
-The Kerberos protocols generally assume that the encryption used is secure
-from cryptanalysis; however, in some cases, the order of fields in the
-encrypted portions of messages are arranged to minimize the effects of
-poorly chosen keys. It is still important to choose good keys. If keys are
-derived from user-typed passwords, those passwords need to be well chosen
-to make brute force attacks more difficult. Poorly chosen keys still make
-easy targets for intruders.
-
-The following sections specify the encryption and checksum mechanisms
-currently defined for Kerberos. The encodings, chaining, and padding
-requirements for each are described. For encryption methods, it is often
-desirable to place random information (often referred to as a confounder)
-at the start of the message. The requirements for a confounder are
-specified with each encryption mechanism.
-
-Some encryption systems use a block-chaining method to improve the the
-security characteristics of the ciphertext. However, these chaining methods
-often don't provide an integrity check upon decryption. Such systems (such
-as DES in CBC mode) must be augmented with a checksum of the plain-text
-which can be verified at decryption and used to detect any tampering or
-damage. Such checksums should be good at detecting burst errors in the
-input. If any damage is detected, the decryption routine is expected to
-return an error indicating the failure of an integrity check. Each
-encryption type is expected to provide and verify an appropriate checksum.
-The specification of each encryption method sets out its checksum
-requirements.
-
-Finally, where a key is to be derived from a user's password, an algorithm
-for converting the password to a key of the appropriate type is included.
-It is desirable for the string to key function to be one-way, and for the
-mapping to be different in different realms. This is important because
-users who are registered in more than one realm will often use the same
-password in each, and it is desirable that an attacker compromising the
-Kerberos server in one realm not obtain or derive the user's key in
-another.
-
-For an discussion of the integrity characteristics of the candidate
-encryption and checksum methods considered for Kerberos, the the reader is
-referred to [SG92].
-
-6.1. Encryption Specifications
-
-The following ASN.1 definition describes all encrypted messages. The
-enc-part field which appears in the unencrypted part of messages in section
-5 is a sequence consisting of an encryption type, an optional key version
-number, and the ciphertext.
-
-EncryptedData ::=   SEQUENCE {
-                    etype[0]     INTEGER, -- EncryptionType
-                    kvno[1]      INTEGER OPTIONAL,
-                    cipher[2]    OCTET STRING -- ciphertext
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-}
-
-
-
-etype
-     This field identifies which encryption algorithm was used to encipher
-     the cipher. Detailed specifications for selected encryption types
-     appear later in this section.
-kvno
-     This field contains the version number of the key under which data is
-     encrypted. It is only present in messages encrypted under long lasting
-     keys, such as principals' secret keys.
-cipher
-     This field contains the enciphered text, encoded as an OCTET STRING.
-
-The cipher field is generated by applying the specified encryption
-algorithm to data composed of the message and algorithm-specific inputs.
-Encryption mechanisms defined for use with Kerberos must take sufficient
-measures to guarantee the integrity of the plaintext, and we recommend they
-also take measures to protect against precomputed dictionary attacks. If
-the encryption algorithm is not itself capable of doing so, the protections
-can often be enhanced by adding a checksum and a confounder.
-
-The suggested format for the data to be encrypted includes a confounder, a
-checksum, the encoded plaintext, and any necessary padding. The msg-seq
-field contains the part of the protocol message described in section 5
-which is to be encrypted. The confounder, checksum, and padding are all
-untagged and untyped, and their length is exactly sufficient to hold the
-appropriate item. The type and length is implicit and specified by the
-particular encryption type being used (etype). The format for the data to
-be encrypted is described in the following diagram:
-
-      +-----------+----------+-------------+-----+
-      |confounder |   check  |   msg-seq   | pad |
-      +-----------+----------+-------------+-----+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-CipherText ::=   ENCRYPTED       SEQUENCE {
-            confounder[0]   UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL,
-            check[1]        UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
-            msg-seq[2]      MsgSequence,
-            pad             UNTAGGED OCTET STRING(pad_length) OPTIONAL
-}
-
-One generates a random confounder of the appropriate length, placing it in
-confounder; zeroes out check; calculates the appropriate checksum over
-confounder, check, and msg-seq, placing the result in check; adds the
-necessary padding; then encrypts using the specified encryption type and
-the appropriate key.
-
-Unless otherwise specified, a definition of an encryption algorithm that
-specifies a checksum, a length for the confounder field, or an octet
-boundary for padding uses this ciphertext format[36]. Those fields which
-are not specified will be omitted.
-
-In the interest of allowing all implementations using a particular
-encryption type to communicate with all others using that type, the
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-specification of an encryption type defines any checksum that is needed as
-part of the encryption process. If an alternative checksum is to be used, a
-new encryption type must be defined.
-
-Some cryptosystems require additional information beyond the key and the
-data to be encrypted. For example, DES, when used in cipher-block-chaining
-mode, requires an initialization vector. If required, the description for
-each encryption type must specify the source of such additional
-information. 6.2. Encryption Keys
-
-The sequence below shows the encoding of an encryption key:
-
-       EncryptionKey ::=   SEQUENCE {
-                           keytype[0]    INTEGER,
-                           keyvalue[1]   OCTET STRING
-       }
-
-keytype
-     This field specifies the type of encryption key that follows in the
-     keyvalue field. It will almost always correspond to the encryption
-     algorithm used to generate the EncryptedData, though more than one
-     algorithm may use the same type of key (the mapping is many to one).
-     This might happen, for example, if the encryption algorithm uses an
-     alternate checksum algorithm for an integrity check, or a different
-     chaining mechanism.
-keyvalue
-     This field contains the key itself, encoded as an octet string.
-
-All negative values for the encryption key type are reserved for local use.
-All non-negative values are reserved for officially assigned type fields
-and interpreta- tions.
-
-6.3. Encryption Systems
-
-6.3.1. The NULL Encryption System (null)
-
-If no encryption is in use, the encryption system is said to be the NULL
-encryption system. In the NULL encryption system there is no checksum,
-confounder or padding. The ciphertext is simply the plaintext. The NULL Key
-is used by the null encryption system and is zero octets in length, with
-keytype zero (0).
-
-6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
-
-The des-cbc-crc encryption mode encrypts information under the Data
-Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
-A CRC-32 checksum (described in ISO 3309 [ISO3309]) is applied to the
-confounder and message sequence (msg-seq) and placed in the cksum field.
-DES blocks are 8 bytes. As a result, the data to be encrypted (the
-concatenation of confounder, checksum, and message) must be padded to an 8
-byte boundary before encryption. The details of the encryption of this data
-are identical to those for the des-cbc-md5 encryption mode.
-
-Note that, since the CRC-32 checksum is not collision-proof, an attacker
-could use a probabilistic chosen-plaintext attack to generate a valid
-message even if a confounder is used [SG92]. The use of collision-proof
-checksums is recommended for environments where such attacks represent a
-significant threat. The use of the CRC-32 as the checksum for ticket or
-authenticator is no longer mandated as an interoperability requirement for
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-Kerberos Version 5 Specification 1 (See section 9.1 for specific details).
-
-6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
-
-The des-cbc-md4 encryption mode encrypts information under the Data
-Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
-An MD4 checksum (described in [MD492]) is applied to the confounder and
-message sequence (msg-seq) and placed in the cksum field. DES blocks are 8
-bytes. As a result, the data to be encrypted (the concatenation of
-confounder, checksum, and message) must be padded to an 8 byte boundary
-before encryption. The details of the encryption of this data are identical
-to those for the des-cbc-md5 encryption mode.
-
-6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
-
-The des-cbc-md5 encryption mode encrypts information under the Data
-Encryption Standard [DES77] using the cipher block chaining mode [DESM80].
-An MD5 checksum (described in [MD5-92].) is applied to the confounder and
-message sequence (msg-seq) and placed in the cksum field. DES blocks are 8
-bytes. As a result, the data to be encrypted (the concatenation of
-confounder, checksum, and message) must be padded to an 8 byte boundary
-before encryption.
-
-Plaintext and DES ciphtertext are encoded as blocks of 8 octets which are
-concatenated to make the 64-bit inputs for the DES algorithms. The first
-octet supplies the 8 most significant bits (with the octet's MSbit used as
-the DES input block's MSbit, etc.), the second octet the next 8 bits, ...,
-and the eighth octet supplies the 8 least significant bits.
-
-Encryption under DES using cipher block chaining requires an additional
-input in the form of an initialization vector. Unless otherwise specified,
-zero should be used as the initialization vector. Kerberos' use of DES
-requires an 8 octet confounder.
-
-The DES specifications identify some 'weak' and 'semi-weak' keys; those
-keys shall not be used for encrypting messages for use in Kerberos.
-Additionally, because of the way that keys are derived for the encryption
-of checksums, keys shall not be used that yield 'weak' or 'semi-weak' keys
-when eXclusive-ORed with the hexadecimal constant F0F0F0F0F0F0F0F0.
-
-A DES key is 8 octets of data, with keytype one (1). This consists of 56
-bits of key, and 8 parity bits (one per octet). The key is encoded as a
-series of 8 octets written in MSB-first order. The bits within the key are
-also encoded in MSB order. For example, if the encryption key is
-(B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
-B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the
-parity bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1
-as the MSbit). [See the FIPS 81 introduction for reference.]
-
-String to key transformation
-
-To generate a DES key from a text string (password), a "salt" is
-concatenated to the text string, and then padded with ASCII nulls to an 8
-byte boundary. This "salt" is normally the realm and each component of the
-principal's name appended. However, sometimes different salts are used ---
-for example, when a realm is renamed, or if a user changes her username, or
-for compatibility with Kerberos V4 (whose string-to-key algorithm uses a
-null string for the salt). This string is then fan-folded and
-eXclusive-ORed with itself to form an 8 byte DES key. Before
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-eXclusive-ORing a block, every byte is shifted one bit to the left to leave
-the lowest bit zero. The key is the "corrected" by correcting the parity on
-the key, and if the key matches a 'weak' or 'semi-weak' key as described in
-the DES specification, it is eXclusive-ORed with the constant
-00000000000000F0. This key is then used to generate a DES CBC checksum on
-the initial string (with the salt appended). The result of the CBC checksum
-is the "corrected" as described above to form the result which is return as
-the key. Pseudocode follows:
-
-     name_to_default_salt(realm, name) {
-          s = realm
-          for(each component in name) {
-               s = s + component;
-          }
-          return s;
-     }
-
-     key_correction(key) {
-          fixparity(key);
-          if (is_weak_key_key(key))
-               key = key XOR 0xF0;
-          return(key);
-     }
-
-     string_to_key(string,salt) {
-
-          odd = 1;
-          s = string + salt;
-          tempkey = NULL;
-          pad(s); /* with nulls to 8 byte boundary */
-          for(8byteblock in s) {
-               if(odd == 0)  {
-                   odd = 1;
-                   reverse(8byteblock)
-               }
-               else odd = 0;
-               left shift every byte in 8byteblock one bit;
-               tempkey = tempkey XOR 8byteblock;
-          }
-          tempkey = key_correction(tempkey);
-          key = key_correction(DES-CBC-check(s,tempkey));
-          return(key);
-     }
-
-6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with Key
-Derivation [Horowitz]
-
-NOTE: This description currently refers to documents, the contents of which
-might be bettered included by value in this spec. The description below was
-provided by Marc Horowitz, and the form in which it will finally appear is
-yet to be determined. This description is included in this version of the
-draft because it does describe the implemenation ready for use with the MIT
-implementation. Note also that the encryption identifier has been left
-unspecified here because the value from Marc Horowitz's spec conflicted
-with some other impmenentations implemented based on perevious versions of
-the specification.
-
-This encryption type is based on the Triple DES cryptosystem, the HMAC-SHA1
-[Krawczyk96] message authentication algorithm, and key derivation for
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-Kerberos V5 [HorowitzB96].
-
-The des3-cbc-hmac-sha1 encryption type has been assigned the value ??. The
-hmac-sha1-des3 checksum type has been assigned the value 12.
-
-Encryption Type des3-cbc-hmac-sha1
-
-EncryptedData using this type must be generated as described in
-[Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC mode. The
-keyed hash algorithm is HMAC-SHA1. Unless otherwise specified, a zero IV
-must be used. If the length of the input data is not a multiple of the
-block size, zero octets must be used to pad the plaintext to the next
-eight-octet boundary. The counfounder must be eight random octets (one
-block).
-
-Checksum Type hmac-sha1-des3
-
-Checksums using this type must be generated as described in [Horowitz96].
-The keyed hash algorithm is HMAC-SHA1.
-
-Common Requirements
-
-The EncryptionKey value is 24 octets long. The 7 most significant bits of
-each octet contain key bits, and the least significant bit is the inverse
-of the xor of the key bits.
-
-For the purposes of key derivation, the block size is 64 bits, and the key
-size is 168 bits. The 168 bits output by key derivation are converted to an
-EncryptionKey value as follows. First, the 168 bits are divided into three
-groups of 56 bits, which are expanded individually into 64 bits as follows:
-
- 1  2  3  4  5  6  7  p
- 9 10 11 12 13 14 15  p
-17 18 19 20 21 22 23  p
-25 26 27 28 29 30 31  p
-33 34 35 36 37 38 39  p
-41 42 43 44 45 46 47  p
-49 50 51 52 53 54 55  p
-56 48 40 32 24 16  8  p
-
-The "p" bits are parity bits computed over the data bits. The output of the
-three expansions are concatenated to form the EncryptionKey value.
-
-When the HMAC-SHA1 of a string is computed, the key is used in the
-EncryptedKey form.
-
-Key Derivation
-
-In the Kerberos protocol, cryptographic keys are used in a number of
-places. In order to minimize the effect of compromising a key, it is
-desirable to use a different key for each of these places. Key derivation
-[Horowitz96] can be used to construct different keys for each operation
-from the keys transported on the network. For this to be possible, a small
-change to the specification is necessary.
-
-This section specifies a profile for the use of key derivation [Horowitz96]
-with Kerberos. For each place where a key is used, a ``key usage'' must is
-specified for that purpose. The key, key usage, and encryption/checksum
-type together describe the transformation from plaintext to ciphertext, or
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-plaintext to checksum.
-
-Key Usage Values
-
-This is a complete list of places keys are used in the kerberos protocol,
-with key usage values and RFC 1510 section numbers:
-
- 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
-    client key (section 5.4.1)
- 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
-    application session key), encrypted with the service key
-    (section 5.4.2)
- 3. AS-REP encrypted part (includes tgs session key or application
-    session key), encrypted with the client key (section 5.4.2)
- 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
-    session key (section 5.4.1)
- 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
-    authenticator subkey (section 5.4.1)
- 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
-    with the tgs session key (sections 5.3.2, 5.4.1)
- 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
-    authenticator subkey), encrypted with the tgs session key
-    (section 5.3.2)
- 8. TGS-REP encrypted part (includes application session key),
-    encrypted with the tgs session key (section 5.4.2)
- 9. TGS-REP encrypted part (includes application session key),
-    encrypted with the tgs authenticator subkey (section 5.4.2)
-10. AP-REQ Authenticator cksum, keyed with the application session
-    key (section 5.3.2)
-11. AP-REQ Authenticator (includes application authenticator
-    subkey), encrypted with the application session key (section
-    5.3.2)
-12. AP-REP encrypted part (includes application session subkey),
-    encrypted with the application session key (section 5.5.2)
-13. KRB-PRIV encrypted part, encrypted with a key chosen by the
-    application (section 5.7.1)
-14. KRB-CRED encrypted part, encrypted with a key chosen by the
-    application (section 5.6.1)
-15. KRB-SAVE cksum, keyed with a key chosen by the application
-    (section 5.8.1)
-18. KRB-ERROR checksum (e-cksum in section 5.9.1)
-19. AD-KDCIssued checksum (ad-checksum in appendix B.1)
-20. Checksum for Mandatory Ticket Extensions (appendix B.6)
-21. Checksum in Authorization Data in Ticket Extensions (appendix B.7)
-
-Key usage values between 1024 and 2047 (inclusive) are reserved for
-application use. Applications should use even values for encryption and odd
-values for checksums within this range.
-
-A few of these key usages need a little clarification. A service which
-receives an AP-REQ has no way to know if the enclosed Ticket was part of an
-AS-REP or TGS-REP. Therefore, key usage 2 must always be used for
-generating a Ticket, whether it is in response to an AS- REQ or TGS-REQ.
-
-There might exist other documents which define protocols in terms of the
-RFC1510 encryption types or checksum types. Such documents would not know
-about key usages. In order that these documents continue to be meaningful
-until they are updated, key usages 1024 and 1025 must be used to derive
-keys for encryption and checksums, respectively. New protocols defined in
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-terms of the Kerberos encryption and checksum types should use their own
-key usages. Key usages may be registered with IANA to avoid conflicts. Key
-usages must be unsigned 32 bit integers. Zero is not permitted.
-
-Defining Cryptosystems Using Key Derivation
-
-Kerberos requires that the ciphertext component of EncryptedData be
-tamper-resistant as well as confidential. This implies encryption and
-integrity functions, which must each use their own separate keys. So, for
-each key usage, two keys must be generated, one for encryption (Ke), and
-one for integrity (Ki):
-
-      Ke = DK(protocol key, key usage | 0xAA)
-      Ki = DK(protocol key, key usage | 0x55)
-
-where the protocol key is from the EncryptionKey from the wire protocol,
-and the key usage is represented as a 32 bit integer in network byte order.
-The ciphertest must be generated from the plaintext as follows:
-
-   ciphertext = E(Ke, confounder | plaintext | padding) |
-                H(Ki, confounder | plaintext | padding)
-
-The confounder and padding are specific to the encryption algorithm E.
-
-When generating a checksum only, there is no need for a confounder or
-padding. Again, a new key (Kc) must be used. Checksums must be generated
-from the plaintext as follows:
-
-      Kc = DK(protocol key, key usage | 0x99)
-
-      MAC = H(Kc, plaintext)
-
-Note that each enctype is described by an encryption algorithm E and a
-keyed hash algorithm H, and each checksum type is described by a keyed hash
-algorithm H. HMAC, with an appropriate hash, is recommended for use as H.
-
-Key Derivation from Passwords
-
-The well-known constant for password key derivation must be the byte string
-{0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the
-ASCII encoding for the string "kerberos".
-
-6.4. Checksums
-
-The following is the ASN.1 definition used for a checksum:
-
-         Checksum ::=   SEQUENCE {
-                        cksumtype[0]   INTEGER,
-                        checksum[1]    OCTET STRING
-         }
-
-cksumtype
-     This field indicates the algorithm used to generate the accompanying
-     checksum.
-checksum
-     This field contains the checksum itself, encoded as an octet string.
-
-Detailed specification of selected checksum types appear later in this
-section. Negative values for the checksum type are reserved for local use.
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-All non-negative values are reserved for officially assigned type fields
-and interpretations.
-
-Checksums used by Kerberos can be classified by two properties: whether
-they are collision-proof, and whether they are keyed. It is infeasible to
-find two plaintexts which generate the same checksum value for a
-collision-proof checksum. A key is required to perturb or initialize the
-algorithm in a keyed checksum. To prevent message-stream modification by an
-active attacker, unkeyed checksums should only be used when the checksum
-and message will be subsequently encrypted (e.g. the checksums defined as
-part of the encryption algorithms covered earlier in this section).
-
-Collision-proof checksums can be made tamper-proof if the checksum value is
-encrypted before inclusion in a message. In such cases, the composition of
-the checksum and the encryption algorithm must be considered a separate
-checksum algorithm (e.g. RSA-MD5 encrypted using DES is a new checksum
-algorithm of type RSA-MD5-DES). For most keyed checksums, as well as for
-the encrypted forms of unkeyed collision-proof checksums, Kerberos prepends
-a confounder before the checksum is calculated.
-
-6.4.1. The CRC-32 Checksum (crc32)
-
-The CRC-32 checksum calculates a checksum based on a cyclic redundancy
-check as described in ISO 3309 [ISO3309]. The resulting checksum is four
-(4) octets in length. The CRC-32 is neither keyed nor collision-proof. The
-use of this checksum is not recommended. An attacker using a probabilistic
-chosen-plaintext attack as described in [SG92] might be able to generate an
-alternative message that satisfies the checksum. The use of collision-proof
-checksums is recommended for environments where such attacks represent a
-significant threat.
-
-6.4.2. The RSA MD4 Checksum (rsa-md4)
-
-The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm
-[MD4-92]. The algorithm takes as input an input message of arbitrary length
-and produces as output a 128-bit (16 octet) checksum. RSA-MD4 is believed
-to be collision-proof.
-
-6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des)
-
-The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by
-prepending an 8 octet confounder before the text, applying the RSA MD4
-checksum algorithm, and encrypting the confounder and the checksum using
-DES in cipher-block-chaining (CBC) mode using a variant of the key, where
-the variant is computed by eXclusive-ORing the key with the constant
-F0F0F0F0F0F0F0F0[39]. The initialization vector should be zero. The
-resulting checksum is 24 octets long (8 octets of which are redundant).
-This checksum is tamper-proof and believed to be collision-proof.
-
-The DES specifications identify some weak keys' and 'semi-weak keys'; those
-keys shall not be used for generating RSA-MD4 checksums for use in
-Kerberos.
-
-The format for the checksum is described in the follow- ing diagram:
-
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-|  des-cbc(confounder   +   rsa-md4(confounder+msg),key=var(key),iv=0)  |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-rsa-md4-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                           confounder[0]   UNTAGGED OCTET STRING(8),
-                           check[1]        UNTAGGED OCTET STRING(16)
-}
-
-6.4.4. The RSA MD5 Checksum (rsa-md5)
-
-The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm.
-[MD5-92]. The algorithm takes as input an input message of arbitrary length
-and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is believed
-to be collision-proof.
-
-6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des)
-
-The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by
-prepending an 8 octet confounder before the text, applying the RSA MD5
-checksum algorithm, and encrypting the confounder and the checksum using
-DES in cipher-block-chaining (CBC) mode using a variant of the key, where
-the variant is computed by eXclusive-ORing the key with the hexadecimal
-constant F0F0F0F0F0F0F0F0. The initialization vector should be zero. The
-resulting checksum is 24 octets long (8 octets of which are redundant).
-This checksum is tamper-proof and believed to be collision-proof.
-
-The DES specifications identify some 'weak keys' and 'semi-weak keys';
-those keys shall not be used for encrypting RSA-MD5 checksums for use in
-Kerberos.
-
-The format for the checksum is described in the following diagram:
-
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-|  des-cbc(confounder   +   rsa-md5(confounder+msg),key=var(key),iv=0)  |
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-rsa-md5-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                           confounder[0]   UNTAGGED OCTET STRING(8),
-                           check[1]        UNTAGGED OCTET STRING(16)
-}
-
-6.4.6. DES cipher-block chained checksum (des-mac)
-
-The DES-MAC checksum is computed by prepending an 8 octet confounder to the
-plaintext, performing a DES CBC-mode encryption on the result using the key
-and an initialization vector of zero, taking the last block of the
-ciphertext, prepending the same confounder and encrypting the pair using
-DES in cipher-block-chaining (CBC) mode using a a variant of the key, where
-the variant is computed by eXclusive-ORing the key with the hexadecimal
-constant F0F0F0F0F0F0F0F0. The initialization vector should be zero. The
-resulting checksum is 128 bits (16 octets) long, 64 bits of which are
-redundant. This checksum is tamper-proof and collision-proof.
-
-The format for the checksum is described in the following diagram:
-
-+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-|   des-cbc(confounder  + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
-+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
-
-The format cannot be described in ASN.1, but for those who prefer an
-ASN.1-like notation:
-
-des-mac-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                       confounder[0]   UNTAGGED OCTET STRING(8),
-                       check[1]        UNTAGGED OCTET STRING(8)
-}
-
-The DES specifications identify some 'weak' and 'semi-weak' keys; those
-keys shall not be used for generating DES-MAC checksums for use in
-Kerberos, nor shall a key be used whose variant is 'weak' or 'semi-weak'.
-
-6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative (rsa-md4-des-k)
-
-The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum by
-applying the RSA MD4 checksum algorithm and encrypting the results using
-DES in cipher-block-chaining (CBC) mode using a DES key as both key and
-initialization vector. The resulting checksum is 16 octets long. This
-checksum is tamper-proof and believed to be collision-proof. Note that this
-checksum type is the old method for encoding the RSA-MD4-DES checksum and
-it is no longer recommended.
-
-6.4.8. DES cipher-block chained checksum alternative (des-mac-k)
-
-The DES-MAC-K checksum is computed by performing a DES CBC-mode encryption
-of the plaintext, and using the last block of the ciphertext as the
-checksum value. It is keyed with an encryption key and an initialization
-vector; any uses which do not specify an additional initialization vector
-will use the key as both key and initialization vector. The resulting
-checksum is 64 bits (8 octets) long. This checksum is tamper-proof and
-collision-proof. Note that this checksum type is the old method for
-encoding the DES-MAC checksum and it is no longer recommended. The DES
-specifications identify some 'weak keys' and 'semi-weak keys'; those keys
-shall not be used for generating DES-MAC checksums for use in Kerberos.
-
-7. Naming Constraints
-
-7.1. Realm Names
-
-Although realm names are encoded as GeneralStrings and although a realm can
-technically select any name it chooses, interoperability across realm
-boundaries requires agreement on how realm names are to be assigned, and
-what information they imply.
-
-To enforce these conventions, each realm must conform to the conventions
-itself, and it must require that any realms with which inter-realm keys are
-shared also conform to the conventions and require the same from its
-neighbors.
-
-Kerberos realm names are case sensitive. Realm names that differ only in
-the case of the characters are not equivalent. There are presently four
-styles of realm names: domain, X500, other, and reserved. Examples of each
-style follow:
-
-     domain:   ATHENA.MIT.EDU (example)
-       X500:   C=US/O=OSF (example)
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-      other:   NAMETYPE:rest/of.name=without-restrictions (example)
-   reserved:   reserved, but will not conflict with above
-
-Domain names must look like domain names: they consist of components
-separated by periods (.) and they contain neither colons (:) nor slashes
-(/). Domain names must be converted to upper case when used as realm names.
-
-X.500 names contain an equal (=) and cannot contain a colon (:) before the
-equal. The realm names for X.500 names will be string representations of
-the names with components separated by slashes. Leading and trailing
-slashes will not be included.
-
-Names that fall into the other category must begin with a prefix that
-contains no equal (=) or period (.) and the prefix must be followed by a
-colon (:) and the rest of the name. All prefixes must be assigned before
-they may be used. Presently none are assigned.
-
-The reserved category includes strings which do not fall into the first
-three categories. All names in this category are reserved. It is unlikely
-that names will be assigned to this category unless there is a very strong
-argument for not using the 'other' category.
-
-These rules guarantee that there will be no conflicts between the various
-name styles. The following additional constraints apply to the assignment
-of realm names in the domain and X.500 categories: the name of a realm for
-the domain or X.500 formats must either be used by the organization owning
-(to whom it was assigned) an Internet domain name or X.500 name, or in the
-case that no such names are registered, authority to use a realm name may
-be derived from the authority of the parent realm. For example, if there is
-no domain name for E40.MIT.EDU, then the administrator of the MIT.EDU realm
-can authorize the creation of a realm with that name.
-
-This is acceptable because the organization to which the parent is assigned
-is presumably the organization authorized to assign names to its children
-in the X.500 and domain name systems as well. If the parent assigns a realm
-name without also registering it in the domain name or X.500 hierarchy, it
-is the parent's responsibility to make sure that there will not in the
-future exists a name identical to the realm name of the child unless it is
-assigned to the same entity as the realm name.
-
-7.2. Principal Names
-
-As was the case for realm names, conventions are needed to ensure that all
-agree on what information is implied by a principal name. The name-type
-field that is part of the principal name indicates the kind of information
-implied by the name. The name-type should be treated as a hint. Ignoring
-the name type, no two names can be the same (i.e. at least one of the
-components, or the realm, must be different). The following name types are
-defined:
-
-  name-type      value   meaning
-
-   NT-UNKNOWN        0   Name type not known
-   NT-PRINCIPAL      1   General principal name (e.g. username, or DCE
-principal)
-   NT-SRV-INST       2   Service and other unique instance (krbtgt)
-   NT-SRV-HST        3   Service with host name as instance (telnet,
-rcommands)
-   NT-SRV-XHST       4   Service with slash-separated host name components
-   NT-UID            5   Unique ID
-   NT-X500-PRINCIPAL 6   Encoded X.509 Distingished name [RFC 1779]
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-When a name implies no information other than its uniqueness at a
-particular time the name type PRINCIPAL should be used. The principal name
-type should be used for users, and it might also be used for a unique
-server. If the name is a unique machine generated ID that is guaranteed
-never to be reassigned then the name type of UID should be used (note that
-it is generally a bad idea to reassign names of any type since stale
-entries might remain in access control lists).
-
-If the first component of a name identifies a service and the remaining
-components identify an instance of the service in a server specified
-manner, then the name type of SRV-INST should be used. An example of this
-name type is the Kerberos ticket-granting service whose name has a first
-component of krbtgt and a second component identifying the realm for which
-the ticket is valid.
-
-If instance is a single component following the service name and the
-instance identifies the host on which the server is running, then the name
-type SRV-HST should be used. This type is typically used for Internet
-services such as telnet and the Berkeley R commands. If the separate
-components of the host name appear as successive components following the
-name of the service, then the name type SRV-XHST should be used. This type
-might be used to identify servers on hosts with X.500 names where the slash
-(/) might otherwise be ambiguous.
-
-A name type of NT-X500-PRINCIPAL should be used when a name from an X.509
-certificiate is translated into a Kerberos name. The encoding of the X.509
-name as a Kerberos principal shall conform to the encoding rules specified
-in RFC 2253.
-
-A name type of UNKNOWN should be used when the form of the name is not
-known. When comparing names, a name of type UNKNOWN will match principals
-authenticated with names of any type. A principal authenticated with a name
-of type UNKNOWN, however, will only match other names of type UNKNOWN.
-
-Names of any type with an initial component of 'krbtgt' are reserved for
-the Kerberos ticket granting service. See section 8.2.3 for the form of
-such names.
-
-7.2.1. Name of server principals
-
-The principal identifier for a server on a host will generally be composed
-of two parts: (1) the realm of the KDC with which the server is registered,
-and (2) a two-component name of type NT-SRV-HST if the host name is an
-Internet domain name or a multi-component name of type NT-SRV-XHST if the
-name of the host is of a form such as X.500 that allows slash (/)
-separators. The first component of the two- or multi-component name will
-identify the service and the latter components will identify the host.
-Where the name of the host is not case sensitive (for example, with
-Internet domain names) the name of the host must be lower case. If
-specified by the application protocol for services such as telnet and the
-Berkeley R commands which run with system privileges, the first component
-may be the string 'host' instead of a service specific identifier. 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.
-
-8. Constants and other defined values
-
-8.1. Host address types
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-All negative values for the host address type are reserved for local use.
-All non-negative values are reserved for officially assigned type fields
-and interpretations.
-
-The values of the types for the following addresses are chosen to match the
-defined address family constants in the Berkeley Standard Distributions of
-Unix. They can be found in with symbolic names AF_xxx (where xxx is an
-abbreviation of the address family name).
-
-Internet (IPv4) Addresses
-
-Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in MSB
-order. The type of IPv4 addresses is two (2).
-
-Internet (IPv6) Addresses [Westerlund]
-
-IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order. The
-type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884]. The
-following addresses (see [RFC1884]) MUST not appear in any Kerberos packet:
-
-   * the Unspecified Address
-   * the Loopback Address
-   * Link-Local addresses
-
-IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
-
-CHAOSnet addresses
-
-CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB order.
-The type of CHAOSnet addresses is five (5).
-
-ISO addresses
-
-ISO addresses are variable-length. The type of ISO addresses is seven (7).
-
-Xerox Network Services (XNS) addresses
-
-XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order. The
-type of XNS addresses is six (6).
-
-AppleTalk Datagram Delivery Protocol (DDP) addresses
-
-AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit
-network number. The first octet of the address is the node number; the
-remaining two octets encode the network number in MSB order. The type of
-AppleTalk DDP addresses is sixteen (16).
-
-DECnet Phase IV addresses
-
-DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. The
-type of DECnet Phase IV addresses is twelve (12).
-
-Netbios addresses
-
-Netbios addresses are 16-octet addresses typically composed of 1 to 15
-characters, trailing blank (ascii char 20) filled, with a 16th octet of
-0x0. The type of Netbios addresses is 20 (0x14).
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-8.2. KDC messages
-
-8.2.1. UDP/IP transport
-
-When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using UDP
-IP transport, the client shall send a UDP datagram containing only an
-encoding of the request to port 88 (decimal) at the KDC's IP address; the
-KDC will respond with a reply datagram containing only an encoding of the
-reply message (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at
-the sender's IP address. Kerberos servers supporting IP transport must
-accept UDP requests on port 88 (decimal). The response to a request made
-through UDP/IP transport must also use UDP/IP transport.
-
-8.2.2. TCP/IP transport [Westerlund,Danielsson]
-
-Kerberos servers (KDC's) should accept TCP requests on port 88 (decimal)
-and clients should support the sending of TCP requests on port 88
-(decimal). When the KRB_KDC_REQ message is sent to the KDC over a TCP
-stream, a new connection will be established for each authentication
-exchange (request and response). The KRB_KDC_REP or KRB_ERROR message will
-be returned to the client on the same TCP stream that was established for
-the request. The response to a request made through TCP/IP transport must
-also use TCP/IP transport. Implementors should note that some extentions to
-the Kerberos protocol will not work if any implementation not supporting
-the TCP transport is involved (client or KDC). Implementors are strongly
-urged to support the TCP transport on both the client and server and are
-advised that the current notation of "should" support will likely change in
-the future to must support. The KDC may close the TCP stream after sending
-a response, but may leave the stream open if it expects a followup - in
-which case it may close the stream at any time if resource constratints or
-other factors make it desirable to do so. Care must be taken in managing
-TCP/IP connections with the KDC to prevent denial of service attacks based
-on the number of TCP/IP connections with the KDC that remain open. If
-multiple exchanges with the KDC are needed for certain forms of
-preauthentication, multiple TCP connections may be required. A client may
-close the stream after receiving response, and should close the stream if
-it does not expect to send followup messages. The client must be prepared
-to have the stream closed by the KDC at anytime, in which case it must
-simply connect again when it is ready to send subsequent messages.
-
-The first four octets of the TCP stream used to transmit the request
-request will encode in network byte order the length of the request
-(KRB_KDC_REQ), and the length will be followed by the request itself. The
-response will similarly be preceeded by a 4 octet encoding in network byte
-order of the length of the KRB_KDC_REP or the KRB_ERROR message and will be
-followed by the KRB_KDC_REP or the KRB_ERROR response. If the sign bit is
-set on integer represented by the first 4 octets, then the next 4 octets
-will be read, extending the length of the field by another 4 octets (less 1
-bit).
-
-8.2.3. OSI transport
-
-During authentication of an OSI client to an OSI server, the mutual
-authentication of an OSI server to an OSI client, the transfer of
-credentials from an OSI client to an OSI server, or during exchange of
-private or integrity checked messages, Kerberos protocol messages may be
-treated as opaque objects and the type of the authentication mechanism will
-be:
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1),
-security(5),kerberosv5(2)}
-
-Depending on the situation, the opaque object will be an authentication
-header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe message
-(KRB_SAFE), a private message (KRB_PRIV), or a credentials message
-(KRB_CRED). The opaque data contains an application code as specified in
-the ASN.1 description for each message. The application code may be used by
-Kerberos to determine the message type.
-
-8.2.3. Name of the TGS
-
-The principal identifier of the ticket-granting service shall be composed
-of three parts: (1) the realm of the KDC issuing the TGS ticket (2) a
-two-part name of type NT-SRV-INST, with the first part "krbtgt" and the
-second part the name of the realm which will accept the ticket-granting
-ticket. For example, a ticket-granting ticket issued by the ATHENA.MIT.EDU
-realm to be used to get tickets from the ATHENA.MIT.EDU KDC has a principal
-identifier of "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU")
-(name). A ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be
-used to get tickets from the MIT.EDU realm has a principal identifier of
-"ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU") (name).
-
-8.3. Protocol constants and associated values
-
-The following tables list constants used in the protocol and defines their
-meanings. Ranges are specified in the "specification" section that limit
-the values of constants for which values are defined here. This allows
-implementations to make assumptions about the maximum values that will be
-received for these constants. Implementation receiving values outside the
-range specified in the "specification" section may reject the request, but
-they must recover cleanly.
-
-Encryption type  etype value  block size    minimum pad size  confounder
-size
-NULL              0            1                 0                 0
-des-cbc-crc       1            8                 4                 8
-des-cbc-md4       2            8                 0                 8
-des-cbc-md5       3            8                 0                 8
-        4
-des3-cbc-md5      5            8                 0                 8
-        6
-des3-cbc-sha1     7            8                 0                 8
-sign-dsa-generate 8                                   (pkinit)
-encrypt-rsa-priv  9                                   (pkinit)
-encrypt-rsa-pub  10                                   (pkinit)
-rsa-pub-md5      11                                   (pkinit)
-rsa-pub-sha1     12                                   (pkinit)
-des3kd-cbc-sha1  ??            8                 0                 8
-ENCTYPE_PK_CROSS 48                                   (reserved for pkcross)
-       0x8003
-
-Checksum type              sumtype value       checksum size
-CRC32                      1                   4
-rsa-md4                    2                   16
-rsa-md4-des                3                   24
-des-mac                    4                   16
-des-mac-k                  5                   8
-rsa-md4-des-k              6                   16
-rsa-md5                    7                   16
-rsa-md5-des                8                   24
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-rsa-md5-des3               9                   24
-hmac-sha1-des3             12                  20  (I had this as 10, is it
-12)
-
-padata type                     padata-type value
-
-PA-TGS-REQ                      1
-PA-ENC-TIMESTAMP                2
-PA-PW-SALT                      3
-                      4
-PA-ENC-UNIX-TIME                5
-PA-SANDIA-SECUREID              6
-PA-SESAME                       7
-PA-OSF-DCE                      8
-PA-CYBERSAFE-SECUREID           9
-PA-AFS3-SALT                    10
-PA-ETYPE-INFO                   11
-SAM-CHALLENGE                   12                  (sam/otp)
-SAM-RESPONSE                    13                  (sam/otp)
-PA-PK-AS-REQ                    14                  (pkinit)
-PA-PK-AS-REP                    15                  (pkinit)
-PA-PK-AS-SIGN                   16                  (pkinit)
-PA-PK-KEY-REQ                   17                  (pkinit)
-PA-PK-KEY-REP                   18                  (pkinit)
-PA-USE-SPECIFIED-KVNO           20
-
-authorization data type         ad-type value
-AD-KDC-ISSUED                      1
-AD-INTENDED-FOR-SERVER             2
-AD-INTENDED-FOR-APPLICATION-CLASS  3
-AD-IF-RELEVANT                     4
-AD-OR                              5
-AD-MANDATORY-TICKET-EXTENSIONS     6
-AD-IN-TICKET-EXTENSIONS            7
-reserved values                    8-63
-OSF-DCE                            64
-SESAME                             65
-
-Ticket Extension Types
-
-TE-TYPE-NULL                  0      Null ticket extension
-TE-TYPE-EXTERNAL-ADATA        1      Integrity protected authorization data
-                    2      TE-TYPE-PKCROSS-KDC  (I have reservations)
-TE-TYPE-PKCROSS-CLIENT        3      PKCROSS cross realm key ticket
-TE-TYPE-CYBERSAFE-EXT         4      Assigned to CyberSafe Corp
-                    5      TE-TYPE-DEST-HOST (I have reservations)
-
-alternate authentication type   method-type value
-reserved values                 0-63
-ATT-CHALLENGE-RESPONSE          64
-
-transited encoding type         tr-type value
-DOMAIN-X500-COMPRESS            1
-reserved values                 all others
-
-Label               Value   Meaning or MIT code
-
-pvno                    5   current Kerberos protocol version number
-
-message types
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-KRB_AS_REQ             10   Request for initial authentication
-KRB_AS_REP             11   Response to KRB_AS_REQ request
-KRB_TGS_REQ            12   Request for authentication based on TGT
-KRB_TGS_REP            13   Response to KRB_TGS_REQ request
-KRB_AP_REQ             14   application request to server
-KRB_AP_REP             15   Response to KRB_AP_REQ_MUTUAL
-KRB_SAFE               20   Safe (checksummed) application message
-KRB_PRIV               21   Private (encrypted) application message
-KRB_CRED               22   Private (encrypted) message to forward
-credentials
-KRB_ERROR              30   Error response
-
-name types
-
-KRB_NT_UNKNOWN        0  Name type not known
-KRB_NT_PRINCIPAL      1  Just the name of the principal as in DCE, or for
-users
-KRB_NT_SRV_INST       2  Service and other unique instance (krbtgt)
-KRB_NT_SRV_HST        3  Service with host name as instance (telnet,
-rcommands)
-KRB_NT_SRV_XHST       4  Service with host as remaining components
-KRB_NT_UID            5  Unique ID
-KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
-
-error codes
-
-KDC_ERR_NONE                    0   No error
-KDC_ERR_NAME_EXP                1   Client's entry in database has expired
-KDC_ERR_SERVICE_EXP             2   Server's entry in database has expired
-KDC_ERR_BAD_PVNO                3   Requested protocol version number not
-supported
-KDC_ERR_C_OLD_MAST_KVNO         4   Client's key encrypted in old master key
-KDC_ERR_S_OLD_MAST_KVNO         5   Server's key encrypted in old master key
-KDC_ERR_C_PRINCIPAL_UNKNOWN     6   Client not found in Kerberos database
-KDC_ERR_S_PRINCIPAL_UNKNOWN     7   Server not found in Kerberos database
-KDC_ERR_PRINCIPAL_NOT_UNIQUE    8   Multiple principal entries in database
-KDC_ERR_NULL_KEY                9   The client or server has a null key
-KDC_ERR_CANNOT_POSTDATE        10   Ticket not eligible for postdating
-KDC_ERR_NEVER_VALID            11   Requested start time is later than end
-time
-KDC_ERR_POLICY                 12   KDC policy rejects request
-KDC_ERR_BADOPTION              13   KDC cannot accommodate requested option
-KDC_ERR_ETYPE_NOSUPP           14   KDC has no support for encryption type
-KDC_ERR_SUMTYPE_NOSUPP         15   KDC has no support for checksum type
-KDC_ERR_PADATA_TYPE_NOSUPP     16   KDC has no support for padata type
-KDC_ERR_TRTYPE_NOSUPP          17   KDC has no support for transited type
-KDC_ERR_CLIENT_REVOKED         18   Clients credentials have been revoked
-KDC_ERR_SERVICE_REVOKED        19   Credentials for server have been revoked
-KDC_ERR_TGT_REVOKED            20   TGT has been revoked
-KDC_ERR_CLIENT_NOTYET          21   Client not yet valid - try again later
-KDC_ERR_SERVICE_NOTYET         22   Server not yet valid - try again later
-KDC_ERR_KEY_EXPIRED            23   Password has expired - change password
-to reset
-KDC_ERR_PREAUTH_FAILED         24   Pre-authentication information was
-invalid
-KDC_ERR_PREAUTH_REQUIRED       25   Additional pre-authenticationrequired
-[40]
-KDC_ERR_SERVER_NOMATCH         26   Requested server and ticket don't match
-KDC_ERR_MUST_USE_USER2USER     27   Server principal valid for user2user
-only
-KDC_ERR_PATH_NOT_ACCPETED      28   KDC Policy rejects transited path
-KRB_AP_ERR_BAD_INTEGRITY       31   Integrity check on decrypted field
-failed
-KRB_AP_ERR_TKT_EXPIRED         32   Ticket expired
-KRB_AP_ERR_TKT_NYV             33   Ticket not yet valid
-KRB_AP_ERR_REPEAT              34   Request is a replay
-KRB_AP_ERR_NOT_US              35   The ticket isn't for us
-KRB_AP_ERR_BADMATCH            36   Ticket and authenticator don't match
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-KRB_AP_ERR_SKEW                37   Clock skew too great
-KRB_AP_ERR_BADADDR             38   Incorrect net address
-KRB_AP_ERR_BADVERSION          39   Protocol version mismatch
-KRB_AP_ERR_MSG_TYPE            40   Invalid msg type
-KRB_AP_ERR_MODIFIED            41   Message stream modified
-KRB_AP_ERR_BADORDER            42   Message out of order
-KRB_AP_ERR_BADKEYVER           44   Specified version of key is not
-available
-KRB_AP_ERR_NOKEY               45   Service key not available
-KRB_AP_ERR_MUT_FAIL            46   Mutual authentication failed
-KRB_AP_ERR_BADDIRECTION        47   Incorrect message direction
-KRB_AP_ERR_METHOD              48   Alternative authentication method
-required
-KRB_AP_ERR_BADSEQ              49   Incorrect sequence number in message
-KRB_AP_ERR_INAPP_CKSUM         50   Inappropriate type of checksum in
-message
-KRB_AP_PATH_NOT_ACCEPTED       51   Policy rejects transited path
-KRB_ERR_RESPONSE_TOO_BIG       52   Response too big for UDP, retry with TCP
-KRB_ERR_GENERIC                60   Generic error (description in e-text)
-KRB_ERR_FIELD_TOOLONG          61   Field is too long for this
-implementation
-KDC_ERROR_CLIENT_NOT_TRUSTED   62   (pkinit)
-KDC_ERROR_KDC_NOT_TRUSTED      63   (pkinit)
-KDC_ERROR_INVALID_SIG          64   (pkinit)
-KDC_ERR_KEY_TOO_WEAK           65   (pkinit)
-KDC_ERR_CERTIFICATE_MISMATCH   66   (pkinit)
-
-9. Interoperability requirements
-
-Version 5 of the Kerberos protocol supports a myriad of options. Among
-these are multiple encryption and checksum types, alternative encoding
-schemes for the transited field, optional mechanisms for
-pre-authentication, the handling of tickets with no addresses, options for
-mutual authentication, user to user authentication, support for proxies,
-forwarding, postdating, and renewing tickets, the format of realm names,
-and the handling of authorization data.
-
-In order to ensure the interoperability of realms, it is necessary to
-define a minimal configuration which must be supported by all
-implementations. This minimal configuration is subject to change as
-technology does. For example, if at some later date it is discovered that
-one of the required encryption or checksum algorithms is not secure, it
-will be replaced.
-
-9.1. Specification 2
-
-This section defines the second specification of these options.
-Implementations which are configured in this way can be said to support
-Kerberos Version 5 Specification 2 (5.1). Specification 1 (depricated) may
-be found in RFC1510.
-
-Transport
-
-TCP/IP and UDP/IP transport must be supported by KDCs claiming conformance
-to specification 2. Kerberos clients claiming conformance to specification
-2 must support UDP/IP transport for messages with the KDC and should
-support TCP/IP transport.
-
-Encryption and checksum methods
-
-The following encryption and checksum mechanisms must be supported.
-Implementations may support other mechanisms as well, but the additional
-mechanisms may only be used when communicating with principals known to
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-also support them: This list is to be determined.
-
-Encryption: DES-CBC-MD5
-Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
-
-Realm Names
-
-All implementations must understand hierarchical realms in both the
-Internet Domain and the X.500 style. When a ticket granting ticket for an
-unknown realm is requested, the KDC must be able to determine the names of
-the intermediate realms between the KDCs realm and the requested realm.
-
-Transited field encoding
-
-DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported.
-Alternative encodings may be supported, but they may be used only when that
-encoding is supported by ALL intermediate realms.
-
-Pre-authentication methods
-
-The TGS-REQ method must be supported. The TGS-REQ method is not used on the
-initial request. The PA-ENC-TIMESTAMP method must be supported by clients
-but whether it is enabled by default may be determined on a realm by realm
-basis. If not used in the initial request and the error
-KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an
-acceptable method, the client should retry the initial request using the
-PA-ENC-TIMESTAMP preauthentication method. Servers need not support the
-PA-ENC-TIMESTAMP method, but if not supported the server should ignore the
-presence of PA-ENC-TIMESTAMP pre-authentication in a request.
-
-Mutual authentication
-
-Mutual authentication (via the KRB_AP_REP message) must be supported.
-
-Ticket addresses and flags
-
-All KDC's must pass on tickets that carry no addresses (i.e. if a TGT
-contains no addresses, the KDC will return derivative tickets), but each
-realm may set its own policy for issuing such tickets, and each application
-server will set its own policy with respect to accepting them.
-
-Proxies and forwarded tickets must be supported. Individual realms and
-application servers can set their own policy on when such tickets will be
-accepted.
-
-All implementations must recognize renewable and postdated tickets, but
-need not actually implement them. If these options are not supported, the
-starttime and endtime in the ticket shall specify a ticket's entire useful
-life. When a postdated ticket is decoded by a server, all implementations
-shall make the presence of the postdated flag visible to the calling
-server.
-
-User-to-user authentication
-
-Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC
-option) must be provided by implementations, but individual realms may
-decide as a matter of policy to reject such requests on a per-principal or
-realm-wide basis.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-Authorization data
-
-Implementations must pass all authorization data subfields from
-ticket-granting tickets to any derivative tickets unless directed to
-suppress a subfield as part of the definition of that registered subfield
-type (it is never incorrect to pass on a subfield, and no registered
-subfield types presently specify suppression at the KDC).
-
-Implementations must make the contents of any authorization data subfields
-available to the server when a ticket is used. Implementations are not
-required to allow clients to specify the contents of the authorization data
-fields.
-
-Constant ranges
-
-All protocol constants are constrained to 32 bit (signed) values unless
-further constrained by the protocol definition. This limit is provided to
-allow implementations to make assumptions about the maximum values that
-will be received for these constants. Implementation receiving values
-outside this range may reject the request, but they must recover cleanly.
-
-9.2. Recommended KDC values
-
-Following is a list of recommended values for a KDC implementation, based
-on the list of suggested configuration constants (see section 4.4).
-
-minimum lifetime              5 minutes
-maximum renewable lifetime    1 week
-maximum ticket lifetime       1 day
-empty addresses               only when suitable  restrictions  appear
-                              in authorization data
-proxiable, etc.               Allowed.
-
-10. REFERENCES
-
-[NT94]    B. Clifford Neuman and Theodore Y. Ts'o, "An  Authenti-
-          cation  Service for Computer Networks," IEEE Communica-
-          tions Magazine, Vol. 32(9), pp. 33-38 (September 1994).
-
-[MNSS87]  S. P. Miller, B. C. Neuman, J. I. Schiller, and  J.  H.
-          Saltzer,  Section  E.2.1:  Kerberos  Authentication and
-          Authorization System, M.I.T. Project Athena, Cambridge,
-          Massachusetts (December 21, 1987).
-
-[SNS88]   J. G. Steiner, B. C. Neuman, and J. I. Schiller,  "Ker-
-          beros:  An Authentication Service for Open Network Sys-
-          tems," pp. 191-202 in  Usenix  Conference  Proceedings,
-          Dallas, Texas (February, 1988).
-
-[NS78]    Roger M.  Needham  and  Michael  D.  Schroeder,  "Using
-          Encryption for Authentication in Large Networks of Com-
-          puters,"  Communications  of  the  ACM,  Vol.   21(12),
-          pp. 993-999 (December, 1978).
-
-[DS81]    Dorothy E. Denning and  Giovanni  Maria  Sacco,  "Time-
-          stamps  in  Key Distribution Protocols," Communications
-          of the ACM, Vol. 24(8), pp. 533-536 (August 1981).
-
-[KNT92]   John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o,
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-          "The Evolution of the Kerberos Authentication Service,"
-          in an IEEE Computer Society Text soon to  be  published
-          (June 1992).
-
-[Neu93]   B.  Clifford  Neuman,  "Proxy-Based  Authorization  and
-          Accounting  for Distributed Systems," in Proceedings of
-          the 13th International Conference on  Distributed  Com-
-          puting Systems, Pittsburgh, PA (May, 1993).
-
-[DS90]    Don Davis and Ralph Swick,  "Workstation  Services  and
-          Kerberos  Authentication  at Project Athena," Technical
-          Memorandum TM-424,  MIT Laboratory for Computer Science
-          (February 1990).
-
-[LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E.  Som-
-          merfeld,  and  K. Raeburn, Section E.1: Service Manage-
-          ment System, M.I.T.  Project  Athena,  Cambridge,  Mas-
-          sachusetts (1987).
-
-[X509-88] CCITT, Recommendation X.509: The Directory  Authentica-
-          tion Framework, December 1988.
-
-[Pat92].  J. Pato, Using  Pre-Authentication  to  Avoid  Password
-          Guessing  Attacks, Open Software Foundation DCE Request
-          for Comments 26 (December 1992).
-
-[DES77]   National Bureau of Standards, U.S. Department  of  Com-
-          merce,  "Data Encryption Standard," Federal Information
-          Processing Standards Publication  46,   Washington,  DC
-          (1977).
-
-[DESM80]  National Bureau of Standards, U.S. Department  of  Com-
-          merce,  "DES  Modes  of Operation," Federal Information
-          Processing Standards Publication 81,   Springfield,  VA
-          (December 1980).
-
-[SG92]    Stuart G. Stubblebine and Virgil D. Gligor, "On Message
-          Integrity  in  Cryptographic Protocols," in Proceedings
-          of the IEEE  Symposium  on  Research  in  Security  and
-          Privacy, Oakland, California (May 1992).
-
-[IS3309]  International Organization  for  Standardization,  "ISO
-          Information  Processing  Systems - Data Communication -
-          High-Level Data Link Control Procedure -  Frame  Struc-
-          ture," IS 3309 (October 1984).  3rd Edition.
-
-[MD4-92]  R. Rivest, "The  MD4  Message  Digest  Algorithm,"  RFC
-          1320,   MIT  Laboratory  for  Computer  Science  (April
-          1992).
-
-[MD5-92]  R. Rivest, "The  MD5  Message  Digest  Algorithm,"  RFC
-          1321,   MIT  Laboratory  for  Computer  Science  (April
-          1992).
-
-[KBC96]   H. Krawczyk, M. Bellare, and R. Canetti, "HMAC:  Keyed-
-          Hashing  for  Message  Authentication,"  Working  Draft
-          draft-ietf-ipsec-hmac-md5-01.txt,   (August 1996).
-
-[Horowitz96] Horowitz, M., "Key Derivation for Authentication,
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-          Integrity, and Privacy", draft-horowitz-key-derivation-02.txt,
-          August 1998.
-
-[HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft-
-          horowitz-kerb-key-derivation-01.txt, September 1998.
-
-[Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC:
-          Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac-
-          md5-01.txt, August, 1996.
-
-A. Pseudo-code for protocol processing
-
-This appendix provides pseudo-code describing how the messages are to be
-constructed and interpreted by clients and servers.
-
-A.1. KRB_AS_REQ generation
-
-        request.pvno := protocol version; /* pvno = 5 */
-        request.msg-type := message type; /* type = KRB_AS_REQ */
-
-        if(pa_enc_timestamp_required) then
-                request.padata.padata-type = PA-ENC-TIMESTAMP;
-                get system_time;
-                padata-body.patimestamp,pausec = system_time;
-                encrypt padata-body into request.padata.padata-value
-                        using client.key; /* derived from password */
-        endif
-
-        body.kdc-options := users's preferences;
-        body.cname := user's name;
-        body.realm := user's realm;
-        body.sname := service's name; /* usually "krbtgt",  "localrealm" */
-        if (body.kdc-options.POSTDATED is set) then
-                body.from := requested starting time;
-        else
-                omit body.from;
-        endif
-        body.till := requested end time;
-        if (body.kdc-options.RENEWABLE is set) then
-                body.rtime := requested final renewal time;
-        endif
-        body.nonce := random_nonce();
-        body.etype := requested etypes;
-        if (user supplied addresses) then
-                body.addresses := user's addresses;
-        else
-                omit body.addresses;
-        endif
-        omit body.enc-authorization-data;
-        request.req-body := body;
-
-        kerberos := lookup(name of local kerberos server (or servers));
-        send(packet,kerberos);
-
-        wait(for response);
-        if (timed_out) then
-                retry or use alternate server;
-        endif
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-A.2. KRB_AS_REQ verification and KRB_AS_REP generation
-
-        decode message into req;
-
-        client := lookup(req.cname,req.realm);
-        server := lookup(req.sname,req.realm);
-
-        get system_time;
-        kdc_time := system_time.seconds;
-
-        if (!client) then
-                /* no client in Database */
-                error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
-        endif
-        if (!server) then
-                /* no server in Database */
-                error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
-        endif
-
-        if(client.pa_enc_timestamp_required and
-           pa_enc_timestamp not present) then
-                error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
-        endif
-
-        if(pa_enc_timestamp present) then
-                decrypt req.padata-value into decrypted_enc_timestamp
-                        using client.key;
-                        using auth_hdr.authenticator.subkey;
-                if (decrypt_error()) then
-                        error_out(KRB_AP_ERR_BAD_INTEGRITY);
-                if(decrypted_enc_timestamp is not within allowable skew)
-then
-                        error_out(KDC_ERR_PREAUTH_FAILED);
-                endif
-                if(decrypted_enc_timestamp and usec is replay)
-                        error_out(KDC_ERR_PREAUTH_FAILED);
-                endif
-                add decrypted_enc_timestamp and usec to replay cache;
-        endif
-
-        use_etype := first supported etype in req.etypes;
-
-        if (no support for req.etypes) then
-                error_out(KDC_ERR_ETYPE_NOSUPP);
-        endif
-
-        new_tkt.vno := ticket version; /* = 5 */
-        new_tkt.sname := req.sname;
-        new_tkt.srealm := req.srealm;
-        reset all flags in new_tkt.flags;
-
-        /* It should be noted that local policy may affect the  */
-        /* processing of any of these flags.  For example, some */
-        /* realms may refuse to issue renewable tickets         */
-
-        if (req.kdc-options.FORWARDABLE is set) then
-                set new_tkt.flags.FORWARDABLE;
-        endif
-        if (req.kdc-options.PROXIABLE is set) then
-                set new_tkt.flags.PROXIABLE;
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-        endif
-
-        if (req.kdc-options.ALLOW-POSTDATE is set) then
-                set new_tkt.flags.MAY-POSTDATE;
-        endif
-        if ((req.kdc-options.RENEW is set) or
-            (req.kdc-options.VALIDATE is set) or
-            (req.kdc-options.PROXY is set) or
-            (req.kdc-options.FORWARDED is set) or
-            (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
-                error_out(KDC_ERR_BADOPTION);
-        endif
-
-        new_tkt.session := random_session_key();
-        new_tkt.cname := req.cname;
-        new_tkt.crealm := req.crealm;
-        new_tkt.transited := empty_transited_field();
-
-        new_tkt.authtime := kdc_time;
-
-        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 omitted */
-        endif
-        if (req.till = 0) then
-                till := infinity;
-        else
-                till := req.till;
-        endif
-
-        new_tkt.endtime := min(till,
-                              new_tkt.starttime+client.max_life,
-                              new_tkt.starttime+server.max_life,
-                              new_tkt.starttime+max_life_for_realm);
-
-        if ((req.kdc-options.RENEWABLE-OK is set) and
-            (new_tkt.endtime < req.till)) then
-                /* we set the RENEWABLE option for later processing */
-                set req.kdc-options.RENEWABLE;
-                req.rtime := req.till;
-        endif
-
-        if (req.rtime = 0) then
-                rtime := infinity;
-        else
-                rtime := req.rtime;
-        endif
-
-        if (req.kdc-options.RENEWABLE is set) then
-                set new_tkt.flags.RENEWABLE;
-                new_tkt.renew-till := min(rtime,
-
-new_tkt.starttime+client.max_rlife,
-
-new_tkt.starttime+server.max_rlife,
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-new_tkt.starttime+max_rlife_for_realm);
-        else
-                omit new_tkt.renew-till; /* only present if RENEWABLE */
-        endif
-
-        if (req.addresses) then
-                new_tkt.caddr := req.addresses;
-        else
-                omit new_tkt.caddr;
-        endif
-
-        new_tkt.authorization_data := empty_authorization_data();
-
-        encode to-be-encrypted part of ticket into OCTET STRING;
-        new_tkt.enc-part := encrypt OCTET STRING
-                using etype_for_key(server.key), server.key, server.p_kvno;
-
-        /* Start processing the response */
-
-        resp.pvno := 5;
-        resp.msg-type := KRB_AS_REP;
-        resp.cname := req.cname;
-        resp.crealm := req.realm;
-        resp.ticket := new_tkt;
-
-        resp.key := new_tkt.session;
-        resp.last-req := fetch_last_request_info(client);
-        resp.nonce := req.nonce;
-        resp.key-expiration := client.expiration;
-        resp.flags := new_tkt.flags;
-
-        resp.authtime := new_tkt.authtime;
-        resp.starttime := new_tkt.starttime;
-        resp.endtime := new_tkt.endtime;
-
-        if (new_tkt.flags.RENEWABLE) then
-                resp.renew-till := new_tkt.renew-till;
-        endif
-
-        resp.realm := new_tkt.realm;
-        resp.sname := new_tkt.sname;
-
-        resp.caddr := new_tkt.caddr;
-
-        encode body of reply into OCTET STRING;
-
-        resp.enc-part := encrypt OCTET STRING
-                         using use_etype, client.key, client.p_kvno;
-        send(resp);
-
-A.3. KRB_AS_REP verification
-
-        decode response into resp;
-
-        if (resp.msg-type = KRB_ERROR) then
-                if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then
-                        set pa_enc_timestamp_required;
-                        goto KRB_AS_REQ;
-                endif
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-                process_error(resp);
-                return;
-        endif
-
-        /* On error, discard the response, and zero the session key */
-        /* from the response immediately */
-
-        key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
-                                 resp.padata);
-        unencrypted part of resp := decode of decrypt of resp.enc-part
-                                using resp.enc-part.etype and key;
-        zero(key);
-
-        if (common_as_rep_tgs_rep_checks fail) then
-                destroy resp.key;
-                return error;
-        endif
-
-        if near(resp.princ_exp) then
-                print(warning message);
-        endif
-        save_for_later(ticket,session,client,server,times,flags);
-
-A.4. KRB_AS_REP and KRB_TGS_REP common checks
-
-        if (decryption_error() or
-            (req.cname != resp.cname) or
-            (req.realm != resp.crealm) or
-            (req.sname != resp.sname) or
-            (req.realm != resp.realm) or
-            (req.nonce != resp.nonce) or
-            (req.addresses != resp.caddr)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-        /* make sure no flags are set that shouldn't be, and that all that
-*/
-        /* should be are set
-*/
-        if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-        if ((req.from = 0) and
-            (resp.starttime is not within allowable skew)) then
-                destroy resp.key;
-                return KRB_AP_ERR_SKEW;
-        endif
-        if ((req.from != 0) and (req.from != resp.starttime)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-        if ((req.till != 0) and (resp.endtime > req.till)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-        if ((req.kdc-options.RENEWABLE is set) and
-            (req.rtime != 0) and (resp.renew-till > req.rtime)) then
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-        if ((req.kdc-options.RENEWABLE-OK is set) and
-            (resp.flags.RENEWABLE) and
-            (req.till != 0) and
-            (resp.renew-till > req.till)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-A.5. KRB_TGS_REQ generation
-
-        /* Note that make_application_request might have to recursivly
-*/
-        /* call this routine to get the appropriate ticket-granting ticket
-*/
-
-        request.pvno := protocol version; /* pvno = 5 */
-        request.msg-type := message type; /* type = KRB_TGS_REQ */
-
-        body.kdc-options := users's preferences;
-        /* If the TGT is not for the realm of the end-server  */
-        /* then the sname will be for a TGT for the end-realm */
-        /* and the realm of the requested ticket (body.realm) */
-        /* will be that of the TGS to which the TGT we are    */
-        /* sending applies                                    */
-        body.sname := service's name;
-        body.realm := service's realm;
-
-        if (body.kdc-options.POSTDATED is set) then
-                body.from := requested starting time;
-        else
-                omit body.from;
-        endif
-        body.till := requested end time;
-        if (body.kdc-options.RENEWABLE is set) then
-                body.rtime := requested final renewal time;
-        endif
-        body.nonce := random_nonce();
-        body.etype := requested etypes;
-        if (user supplied addresses) then
-                body.addresses := user's addresses;
-        else
-                omit body.addresses;
-        endif
-
-        body.enc-authorization-data := user-supplied data;
-        if (body.kdc-options.ENC-TKT-IN-SKEY) then
-                body.additional-tickets_ticket := second TGT;
-        endif
-
-        request.req-body := body;
-        check := generate_checksum (req.body,checksumtype);
-
-        request.padata[0].padata-type := PA-TGS-REQ;
-        request.padata[0].padata-value := create a KRB_AP_REQ using
-                                      the TGT and checksum
-
-        /* add in any other padata as required/supplied */
-        kerberos := lookup(name of local kerberose server (or servers));
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-        send(packet,kerberos);
-
-        wait(for response);
-        if (timed_out) then
-                retry or use alternate server;
-        endif
-
-A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation
-
-        /* note that reading the application request requires first
-        determining the server for which a ticket was issued, and choosing
-the
-        correct key for decryption.  The name of the server appears in the
-        plaintext part of the ticket. */
-
-        if (no KRB_AP_REQ in req.padata) then
-                error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
-        endif
-        verify KRB_AP_REQ in req.padata;
-
-        /* Note that the realm in which the Kerberos server is operating is
-        determined by the instance from the ticket-granting ticket.  The
-realm
-        in the ticket-granting ticket is the realm under which the ticket
-        granting ticket was issued.  It is possible for a single Kerberos
-        server to support more than one realm. */
-
-        auth_hdr := KRB_AP_REQ;
-        tgt := auth_hdr.ticket;
-
-        if (tgt.sname is not a TGT for local realm and is not req.sname)
-then
-                error_out(KRB_AP_ERR_NOT_US);
-
-        realm := realm_tgt_is_for(tgt);
-
-        decode remainder of request;
-
-        if (auth_hdr.authenticator.cksum is missing) then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-
-        if (auth_hdr.authenticator.cksum type is not supported) then
-                error_out(KDC_ERR_SUMTYPE_NOSUPP);
-        endif
-        if (auth_hdr.authenticator.cksum is not both collision-proof and
-keyed) then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-
-        set computed_checksum := checksum(req);
-        if (computed_checksum != auth_hdr.authenticatory.cksum) then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        server := lookup(req.sname,realm);
-
-        if (!server) then
-                if (is_foreign_tgt_name(req.sname)) then
-                        server := best_intermediate_tgs(req.sname);
-                else
-                        /* no server in Database */
-                        error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-                endif
-        endif
-
-        session := generate_random_session_key();
-
-        use_etype := first supported etype in req.etypes;
-
-        if (no support for req.etypes) then
-                error_out(KDC_ERR_ETYPE_NOSUPP);
-        endif
-
-        new_tkt.vno := ticket version; /* = 5 */
-        new_tkt.sname := req.sname;
-        new_tkt.srealm := realm;
-        reset all flags in new_tkt.flags;
-
-        /* It should be noted that local policy may affect the  */
-        /* processing of any of these flags.  For example, some */
-        /* realms may refuse to issue renewable tickets         */
-
-        new_tkt.caddr := tgt.caddr;
-        resp.caddr := NULL; /* We only include this if they change */
-        if (req.kdc-options.FORWARDABLE is set) then
-                if (tgt.flags.FORWARDABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.FORWARDABLE;
-        endif
-        if (req.kdc-options.FORWARDED is set) then
-                if (tgt.flags.FORWARDABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.FORWARDED;
-                new_tkt.caddr := req.addresses;
-                resp.caddr := req.addresses;
-        endif
-        if (tgt.flags.FORWARDED is set) then
-                set new_tkt.flags.FORWARDED;
-        endif
-
-        if (req.kdc-options.PROXIABLE is set) then
-                if (tgt.flags.PROXIABLE is reset)
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.PROXIABLE;
-        endif
-        if (req.kdc-options.PROXY is set) then
-                if (tgt.flags.PROXIABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.PROXY;
-                new_tkt.caddr := req.addresses;
-                resp.caddr := req.addresses;
-        endif
-
-        if (req.kdc-options.ALLOW-POSTDATE is set) then
-                if (tgt.flags.MAY-POSTDATE is reset)
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-                set new_tkt.flags.MAY-POSTDATE;
-        endif
-        if (req.kdc-options.POSTDATED is set) then
-                if (tgt.flags.MAY-POSTDATE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.POSTDATED;
-                set new_tkt.flags.INVALID;
-                if (against_postdate_policy(req.from)) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-                new_tkt.starttime := req.from;
-        endif
-
-        if (req.kdc-options.VALIDATE is set) then
-                if (tgt.flags.INVALID is reset) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-                if (tgt.starttime > kdc_time) then
-                        error_out(KRB_AP_ERR_NYV);
-                endif
-                if (check_hot_list(tgt)) then
-                        error_out(KRB_AP_ERR_REPEAT);
-                endif
-                tkt := tgt;
-                reset new_tkt.flags.INVALID;
-        endif
-
-        if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
-                             and those already processed) is set) then
-                error_out(KDC_ERR_BADOPTION);
-        endif
-
-        new_tkt.authtime := tgt.authtime;
-
-        if (req.kdc-options.RENEW is set) then
-          /* Note that if the endtime has already passed, the ticket would
-*/
-          /* have been rejected in the initial authentication stage, so
-*/
-          /* there is no need to check again here
-*/
-                if (tgt.flags.RENEWABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                if (tgt.renew-till < kdc_time) then
-                        error_out(KRB_AP_ERR_TKT_EXPIRED);
-                endif
-                tkt := tgt;
-                new_tkt.starttime := kdc_time;
-                old_life := tgt.endttime - tgt.starttime;
-                new_tkt.endtime := min(tgt.renew-till,
-                                       new_tkt.starttime + old_life);
-        else
-                new_tkt.starttime := kdc_time;
-                if (req.till = 0) then
-                        till := infinity;
-                else
-                        till := req.till;
-                endif
-
-                new_tkt.endtime := min(till,
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-                                       new_tkt.starttime+client.max_life,
-                                       new_tkt.starttime+server.max_life,
-                                       new_tkt.starttime+max_life_for_realm,
-                                       tgt.endtime);
-
-                if ((req.kdc-options.RENEWABLE-OK is set) and
-                    (new_tkt.endtime < req.till) and
-                    (tgt.flags.RENEWABLE is set) then
-                        /* we set the RENEWABLE option for later processing
-*/
-                        set req.kdc-options.RENEWABLE;
-                        req.rtime := min(req.till, tgt.renew-till);
-                endif
-        endif
-
-        if (req.rtime = 0) then
-                rtime := infinity;
-        else
-                rtime := req.rtime;
-        endif
-
-        if ((req.kdc-options.RENEWABLE is set) and
-            (tgt.flags.RENEWABLE is set)) then
-                set new_tkt.flags.RENEWABLE;
-                new_tkt.renew-till := min(rtime,
-
-new_tkt.starttime+client.max_rlife,
-
-new_tkt.starttime+server.max_rlife,
-
-new_tkt.starttime+max_rlife_for_realm,
-                                          tgt.renew-till);
-        else
-                new_tkt.renew-till := OMIT; /* leave the renew-till field
-out */
-        endif
-        if (req.enc-authorization-data is present) then
-                decrypt req.enc-authorization-data into
-decrypted_authorization_data
-                        using auth_hdr.authenticator.subkey;
-                if (decrypt_error()) then
-                        error_out(KRB_AP_ERR_BAD_INTEGRITY);
-                endif
-        endif
-        new_tkt.authorization_data := req.auth_hdr.ticket.authorization_data
-+
-                                 decrypted_authorization_data;
-
-        new_tkt.key := session;
-        new_tkt.crealm := tgt.crealm;
-        new_tkt.cname := req.auth_hdr.ticket.cname;
-
-        if (realm_tgt_is_for(tgt) := tgt.realm) then
-                /* tgt issued by local realm */
-                new_tkt.transited := tgt.transited;
-        else
-                /* was issued for this realm by some other realm */
-                if (tgt.transited.tr-type not supported) then
-                        error_out(KDC_ERR_TRTYPE_NOSUPP);
-                endif
-                new_tkt.transited := compress_transited(tgt.transited +
-tgt.realm)
-                /* Don't check tranited field if TGT for foreign realm,
-                 * or requested not to check */
-                if (is_not_foreign_tgt_name(new_tkt.server)
-                   && req.kdc-options.DISABLE-TRANSITED-CHECK not set) then
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-                        /* Check it, so end-server does not have to
-                         * but don't fail, end-server may still accept it */
-                        if (check_transited_field(new_tkt.transited) == OK)
-                              set new_tkt.flags.TRANSITED-POLICY-CHECKED;
-                        endif
-                endif
-        endif
-
-        encode encrypted part of new_tkt into OCTET STRING;
-        if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
-                if (server not specified) then
-                        server = req.second_ticket.client;
-                endif
-                if ((req.second_ticket is not a TGT) or
-                    (req.second_ticket.client != server)) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-
-                new_tkt.enc-part := encrypt OCTET STRING using
-                        using etype_for_key(second-ticket.key),
-second-ticket.key;
-        else
-                new_tkt.enc-part := encrypt OCTET STRING
-                        using etype_for_key(server.key), server.key,
-server.p_kvno;
-        endif
-
-        resp.pvno := 5;
-        resp.msg-type := KRB_TGS_REP;
-        resp.crealm := tgt.crealm;
-        resp.cname := tgt.cname;
-        resp.ticket := new_tkt;
-
-        resp.key := session;
-        resp.nonce := req.nonce;
-        resp.last-req := fetch_last_request_info(client);
-        resp.flags := new_tkt.flags;
-
-        resp.authtime := new_tkt.authtime;
-        resp.starttime := new_tkt.starttime;
-        resp.endtime := new_tkt.endtime;
-
-        omit resp.key-expiration;
-
-        resp.sname := new_tkt.sname;
-        resp.realm := new_tkt.realm;
-
-        if (new_tkt.flags.RENEWABLE) then
-                resp.renew-till := new_tkt.renew-till;
-        endif
-
-        encode body of reply into OCTET STRING;
-
-        if (req.padata.authenticator.subkey)
-                resp.enc-part := encrypt OCTET STRING using use_etype,
-                        req.padata.authenticator.subkey;
-        else resp.enc-part := encrypt OCTET STRING using use_etype, tgt.key;
-
-        send(resp);
-
-A.7. KRB_TGS_REP verification
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-        decode response into resp;
-
-        if (resp.msg-type = KRB_ERROR) then
-                process_error(resp);
-                return;
-        endif
-
-        /* On error, discard the response, and zero the session key from
-        the response immediately */
-
-        if (req.padata.authenticator.subkey)
-                unencrypted part of resp := decode of decrypt of
-resp.enc-part
-                        using resp.enc-part.etype and subkey;
-        else unencrypted part of resp := decode of decrypt of resp.enc-part
-                                using resp.enc-part.etype and tgt's session
-key;
-        if (common_as_rep_tgs_rep_checks fail) then
-                destroy resp.key;
-                return error;
-        endif
-
-        check authorization_data as necessary;
-        save_for_later(ticket,session,client,server,times,flags);
-
-A.8. Authenticator generation
-
-        body.authenticator-vno := authenticator vno; /* = 5 */
-        body.cname, body.crealm := client name;
-        if (supplying checksum) then
-                body.cksum := checksum;
-        endif
-        get system_time;
-        body.ctime, body.cusec := system_time;
-        if (selecting sub-session key) then
-                select sub-session key;
-                body.subkey := sub-session key;
-        endif
-        if (using sequence numbers) then
-                select initial sequence number;
-                body.seq-number := initial sequence;
-        endif
-
-A.9. KRB_AP_REQ generation
-
-        obtain ticket and session_key from cache;
-
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_AP_REQ */
-
-        if (desired(MUTUAL_AUTHENTICATION)) then
-                set packet.ap-options.MUTUAL-REQUIRED;
-        else
-                reset packet.ap-options.MUTUAL-REQUIRED;
-        endif
-        if (using session key for ticket) then
-                set packet.ap-options.USE-SESSION-KEY;
-        else
-                reset packet.ap-options.USE-SESSION-KEY;
-        endif
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-        packet.ticket := ticket; /* ticket */
-        generate authenticator;
-        encode authenticator into OCTET STRING;
-        encrypt OCTET STRING into packet.authenticator using session_key;
-
-A.10. KRB_AP_REQ verification
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_AP_REQ) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        if (packet.ticket.tkt_vno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.ap_options.USE-SESSION-KEY is set) then
-                retrieve session key from ticket-granting ticket for
-                 packet.ticket.{sname,srealm,enc-part.etype};
-        else
-                retrieve service key for
-                 packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
-        endif
-        if (no_key_available) then
-                if (cannot_find_specified_skvno) then
-                        error_out(KRB_AP_ERR_BADKEYVER);
-                else
-                        error_out(KRB_AP_ERR_NOKEY);
-                endif
-        endif
-        decrypt packet.ticket.enc-part into decr_ticket using retrieved key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        decrypt packet.authenticator into decr_authenticator
-                using decr_ticket.key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        if (decr_authenticator.{cname,crealm} !=
-            decr_ticket.{cname,crealm}) then
-                error_out(KRB_AP_ERR_BADMATCH);
-        endif
-        if (decr_ticket.caddr is present) then
-                if (sender_address(packet) is not in decr_ticket.caddr) then
-                        error_out(KRB_AP_ERR_BADADDR);
-                endif
-        elseif (application requires addresses) then
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if (not in_clock_skew(decr_authenticator.ctime,
-                              decr_authenticator.cusec)) then
-                error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-                error_out(KRB_AP_ERR_REPEAT);
-        endif
-        save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
-        get system_time;
-        if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
-            (decr_ticket.flags.INVALID is set)) then
-                /* it hasn't yet become valid */
-                error_out(KRB_AP_ERR_TKT_NYV);
-        endif
-        if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
-                error_out(KRB_AP_ERR_TKT_EXPIRED);
-        endif
-        if (decr_ticket.transited) then
-            /* caller may ignore the TRANSITED-POLICY-CHECKED and do
-             * check anyway */
-            if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then
-                 if (check_transited_field(decr_ticket.transited) then
-                      error_out(KDC_AP_PATH_NOT_ACCPETED);
-                 endif
-            endif
-        endif
-        /* caller must check decr_ticket.flags for any pertinent details */
-        return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
-
-A.11. KRB_AP_REP generation
-
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_AP_REP */
-
-        body.ctime := packet.ctime;
-        body.cusec := packet.cusec;
-        if (selecting sub-session key) then
-                select sub-session key;
-                body.subkey := sub-session key;
-        endif
-        if (using sequence numbers) then
-                select initial sequence number;
-                body.seq-number := initial sequence;
-        endif
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part;
-
-A.12. KRB_AP_REP verification
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_AP_REP) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        cleartext := decrypt(packet.enc-part) using ticket's session key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-        if (cleartext.ctime != authenticator.ctime) then
-                error_out(KRB_AP_ERR_MUT_FAIL);
-        endif
-        if (cleartext.cusec != authenticator.cusec) then
-                error_out(KRB_AP_ERR_MUT_FAIL);
-        endif
-        if (cleartext.subkey is present) then
-                save cleartext.subkey for future use;
-        endif
-        if (cleartext.seq-number is present) then
-                save cleartext.seq-number for future verifications;
-        endif
-        return(AUTHENTICATION_SUCCEEDED);
-
-A.13. KRB_SAFE generation
-
-        collect user data in buffer;
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_SAFE */
-
-        body.user-data := buffer; /* DATA */
-        if (using timestamp) then
-                get system_time;
-                body.timestamp, body.usec := system_time;
-        endif
-        if (using sequence numbers) then
-                body.seq-number := sequence number;
-        endif
-        body.s-address := sender host addresses;
-        if (only one recipient) then
-                body.r-address := recipient host address;
-        endif
-        checksum.cksumtype := checksum type;
-        compute checksum over body;
-        checksum.checksum := checksum value; /* checksum.checksum */
-        packet.cksum := checksum;
-        packet.safe-body := body;
-
-A.14. KRB_SAFE verification
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_SAFE) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        if (packet.checksum.cksumtype is not both collision-proof and keyed)
-then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-        if (safe_priv_common_checks_ok(packet)) then
-                set computed_checksum := checksum(packet.body);
-                if (computed_checksum != packet.checksum) then
-                        error_out(KRB_AP_ERR_MODIFIED);
-                endif
-                return (packet, PACKET_IS_GENUINE);
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-        else
-                return common_checks_error;
-        endif
-
-A.15. KRB_SAFE and KRB_PRIV common checks
-
-        if (packet.s-address != O/S_sender(packet)) then
-                /* O/S report of sender not who claims to have sent it */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if ((packet.r-address is present) and
-            (packet.r-address != local_host_address)) then
-                /* was not sent to proper place */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if (((packet.timestamp is present) and
-             (not in_clock_skew(packet.timestamp,packet.usec))) or
-            (packet.timestamp is not present and timestamp expected)) then
-                error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
-                error_out(KRB_AP_ERR_REPEAT);
-        endif
-
-        if (((packet.seq-number is present) and
-             ((not in_sequence(packet.seq-number)))) or
-            (packet.seq-number is not present and sequence expected)) then
-                error_out(KRB_AP_ERR_BADORDER);
-        endif
-        if (packet.timestamp not present and packet.seq-number not present)
-then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        save_identifier(packet.{timestamp,usec,s-address},
-                        sender_principal(packet));
-
-        return PACKET_IS_OK;
-
-A.16. KRB_PRIV generation
-
-        collect user data in buffer;
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_PRIV */
-
-        packet.enc-part.etype := encryption type;
-
-        body.user-data := buffer;
-        if (using timestamp) then
-                get system_time;
-                body.timestamp, body.usec := system_time;
-        endif
-        if (using sequence numbers) then
-                body.seq-number := sequence number;
-        endif
-        body.s-address := sender host addresses;
-        if (only one recipient) then
-                body.r-address := recipient host address;
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-        endif
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part.cipher;
-
-A.17. KRB_PRIV verification
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_PRIV) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-
-        cleartext := decrypt(packet.enc-part) using negotiated key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-
-        if (safe_priv_common_checks_ok(cleartext)) then
-                return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
-        else
-                return common_checks_error;
-        endif
-
-A.18. KRB_CRED generation
-
-        invoke KRB_TGS; /* obtain tickets to be provided to peer */
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_CRED */
-
-        for (tickets[n] in tickets to be forwarded) do
-                packet.tickets[n] = tickets[n].ticket;
-        done
-
-        packet.enc-part.etype := encryption type;
-
-        for (ticket[n] in tickets to be forwarded) do
-                body.ticket-info[n].key = tickets[n].session;
-                body.ticket-info[n].prealm = tickets[n].crealm;
-                body.ticket-info[n].pname = tickets[n].cname;
-                body.ticket-info[n].flags = tickets[n].flags;
-                body.ticket-info[n].authtime = tickets[n].authtime;
-                body.ticket-info[n].starttime = tickets[n].starttime;
-                body.ticket-info[n].endtime = tickets[n].endtime;
-                body.ticket-info[n].renew-till = tickets[n].renew-till;
-                body.ticket-info[n].srealm = tickets[n].srealm;
-                body.ticket-info[n].sname = tickets[n].sname;
-                body.ticket-info[n].caddr = tickets[n].caddr;
-        done
-
-        get system_time;
-        body.timestamp, body.usec := system_time;
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-        if (using nonce) then
-                body.nonce := nonce;
-        endif
-
-        if (using s-address) then
-                body.s-address := sender host addresses;
-        endif
-        if (limited recipients) then
-                body.r-address := recipient host address;
-        endif
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part.cipher
-               using negotiated encryption key;
-
-A.19. KRB_CRED verification
-
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_CRED) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-
-        cleartext := decrypt(packet.enc-part) using negotiated key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        if ((packet.r-address is present or required) and
-           (packet.s-address != O/S_sender(packet)) then
-                /* O/S report of sender not who claims to have sent it */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if ((packet.r-address is present) and
-            (packet.r-address != local_host_address)) then
-                /* was not sent to proper place */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if (not in_clock_skew(packet.timestamp,packet.usec)) then
-                error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
-                error_out(KRB_AP_ERR_REPEAT);
-        endif
-        if (packet.nonce is required or present) and
-           (packet.nonce != expected-nonce) then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        for (ticket[n] in tickets that were forwarded) do
-                save_for_later(ticket[n],key[n],principal[n],
-                               server[n],times[n],flags[n]);
-        return
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-A.20. KRB_ERROR generation
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_ERROR */
-
-        get system_time;
-        packet.stime, packet.susec := system_time;
-        packet.realm, packet.sname := server name;
-
-        if (client time available) then
-                packet.ctime, packet.cusec := client_time;
-        endif
-        packet.error-code := error code;
-        if (client name available) then
-                packet.cname, packet.crealm := client name;
-        endif
-        if (error text available) then
-                packet.e-text := error text;
-        endif
-        if (error data available) then
-                packet.e-data := error data;
-        endif
-
-B. Definition of common authorization data elements
-
-This appendix contains the definitions of common authorization data
-elements. These common authorization data elements are recursivly defined,
-meaning the ad-data for these types will itself contain a sequence of
-authorization data whose interpretation is affected by the encapsulating
-element. Depending on the meaning of the encapsulating element, the
-encapsulated elements may be ignored, might be interpreted as issued
-directly by the KDC, or they might be stored in a separate plaintext part
-of the ticket. The types of the encapsulating elements are specified as
-part of the Kerberos specification because the behavior based on these
-values should be understood across implementations whereas other elements
-need only be understood by the applications which they affect.
-
-In the definitions that follow, the value of the ad-type for the element
-will be specified in the subsection number, and the value of the ad-data
-will be as shown in the ASN.1 structure that follows the subsection
-heading.
-
-B.1. KDC Issued
-
-AD-KDCIssued   SEQUENCE {
-               ad-checksum[0]    Checksum,
-                i-realm[1]       Realm OPTIONAL,
-                i-sname[2]       PrincipalName OPTIONAL,
-               elements[3]       AuthorizationData.
-}
-
-ad-checksum
-     A checksum over the elements field using a cryptographic checksum
-     method that is identical to the checksum used to protect the ticket
-     itself (i.e. using the same hash function and the same encryption
-     algorithm used to encrypt the ticket) and using a key derived from the
-     same key used to protect the ticket.
-i-realm, i-sname
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-     The name of the issuing principal if different from the KDC itself.
-     This field would be used when the KDC can verify the authenticity of
-     elements signed by the issuing principal and it allows this KDC to
-     notify the application server of the validity of those elements.
-elements
-     A sequence of authorization data elements issued by the KDC.
-
-The KDC-issued ad-data field is intended to provide a means for Kerberos
-principal credentials to embed within themselves privilege attributes and
-other mechanisms for positive authorization, amplifying the priveleges of
-the principal beyond what can be done using a credentials without such an
-a-data element.
-
-This can not be provided without this element because the definition of the
-authorization-data field allows elements to be added at will by the bearer
-of a TGT at the time that they request service tickets and elements may
-also be added to a delegated ticket by inclusion in the authenticator.
-
-For KDC-issued elements this is prevented because the elements are signed
-by the KDC by including a checksum encrypted using the server's key (the
-same key used to encrypt the ticket - or a key derived from that key).
-Elements encapsulated with in the KDC-issued element will be ignored by the
-application server if this "signature" is not present. Further, elements
-encapsulated within this element from a ticket granting ticket may be
-interpreted by the KDC, and used as a basis according to policy for
-including new signed elements within derivative tickets, but they will not
-be copied to a derivative ticket directly. If they are copied directly to a
-derivative ticket by a KDC that is not aware of this element, the signature
-will not be correct for the application ticket elements, and the field will
-be ignored by the application server.
-
-This element and the elements it encapulates may be safely ignored by
-applications, application servers, and KDCs that do not implement this
-element.
-
-B.2. Intended for server
-
-AD-INTENDED-FOR-SERVER   SEQUENCE {
-         intended-server[0]     SEQUENCE OF PrincipalName
-         elements[1]            AuthorizationData
-}
-
-AD elements encapsulated within the intended-for-server element may be
-ignored if the application server is not in the list of principal names of
-intended servers. Further, a KDC issuing a ticket for an application server
-can remove this element if the application server is not in the list of
-intended servers.
-
-Application servers should check for their principal name in the
-intended-server field of this element. If their principal name is not
-found, this element should be ignored. If found, then the encapsulated
-elements should be evaluated in the same manner as if they were present in
-the top level authorization data field. Applications and application
-servers that do not implement this element should reject tickets that
-contain authorization data elements of this type.
-
-B.3. Intended for application class
-
-AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE { intended-application-class[0]
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-SEQUENCE OF GeneralString elements[1] AuthorizationData } AD elements
-encapsulated within the intended-for-application-class element may be
-ignored if the application server is not in one of the named classes of
-application servers. Examples of application server classes include
-"FILESYSTEM", and other kinds of servers.
-
-This element and the elements it encapulates may be safely ignored by
-applications, application servers, and KDCs that do not implement this
-element.
-
-B.4. If relevant
-
-AD-IF-RELEVANT   AuthorizationData
-
-AD elements encapsulated within the if-relevant element are intended for
-interpretation only by application servers that understand the particular
-ad-type of the embedded element. Application servers that do not understand
-the type of an element embedded within the if-relevant element may ignore
-the uninterpretable element. This element promotes interoperability across
-implementations which may have local extensions for authorization.
-
-B.5. And-Or
-
-AD-AND-OR           SEQUENCE {
-                        condition-count[0]    INTEGER,
-                        elements[1]           AuthorizationData
-}
-
-When restrictive AD elements encapsulated within the and-or element are
-encountered, only the number specified in condition-count of the
-encapsulated conditions must be met in order to satisfy this element. This
-element may be used to implement an "or" operation by setting the
-condition-count field to 1, and it may specify an "and" operation by
-setting the condition count to the number of embedded elements. Application
-servers that do not implement this element must reject tickets that contain
-authorization data elements of this type.
-
-B.6. Mandatory ticket extensions
-
-AD-Mandatory-Ticket-Extensions   Checksum
-
-An authorization data element of type mandatory-ticket-extensions specifies
-a collision-proof checksum using the same hash algorithm used to protect
-the integrity of the ticket itself. This checksum will be calculated over
-an individual extension field. If there are more than one extension,
-multiple Mandatory-Ticket-Extensions authorization data elements may be
-present, each with a checksum for a different extension field. This
-restriction indicates that the ticket should not be accepted if a ticket
-extension is not present in the ticket for which the checksum does not
-match that checksum specified in the authorization data element.
-Application servers that do not implement this element must reject tickets
-that contain authorization data elements of this type.
-
-B.7. Authorization Data in ticket extensions
-
-AD-IN-Ticket-Extensions   Checksum
-
-An authorization data element of type in-ticket-extensions specifies a
-collision-proof checksum using the same hash algorithm used to protect the
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-integrity of the ticket itself. This checksum is calculated over a separate
-external AuthorizationData field carried in the ticket extensions.
-Application servers that do not implement this element must reject tickets
-that contain authorization data elements of this type. Application servers
-that do implement this element will search the ticket extensions for
-authorization data fields, calculate the specified checksum over each
-authorization data field and look for one matching the checksum in this
-in-ticket-extensions element. If not found, then the ticket must be
-rejected. If found, the corresponding authorization data elements will be
-interpreted in the same manner as if they were contained in the top level
-authorization data field.
-
-Note that if multiple external authorization data fields are present in a
-ticket, each will have a corresponding element of type in-ticket-extensions
-in the top level authorization data field, and the external entries will be
-linked to the corresponding element by their checksums.
-
-C. Definition of common ticket extensions
-
-This appendix contains the definitions of common ticket extensions. Support
-for these extensions is optional. However, certain extensions have
-associated authorization data elements that may require rejection of a
-ticket containing an extension by application servers that do not implement
-the particular extension. Other extensions have been defined beyond those
-described in this specification. Such extensions are described elswhere and
-for some of those extensions the reserved number may be found in the list
-of constants.
-
-It is known that older versions of Kerberos did not support this field, and
-that some clients will strip this field from a ticket when they parse and
-then reassemble a ticket as it is passed to the application servers. The
-presence of the extension will not break such clients, but any functionaly
-dependent on the extensions will not work when such tickets are handled by
-old clients. In such situations, some implementation may use alternate
-methods to transmit the information in the extensions field.
-
-C.1. Null ticket extension
-
-TE-NullExtension   OctetString -- The empty Octet String
-
-The te-data field in the null ticket extension is an octet string of lenght
-zero. This extension may be included in a ticket granting ticket so that
-the KDC can determine on presentation of the ticket granting ticket whether
-the client software will strip the extensions field.
-
-C.2. External Authorization Data
-
-TE-ExternalAuthorizationData   AuthorizationData
-
-The te-data field in the external authorization data ticket extension is
-field of type AuthorizationData containing one or more authorization data
-elements. If present, a corresponding authorization data element will be
-present in the primary authorization data for the ticket and that element
-will contain a checksum of the external authorization data ticket
-extension.
-  ------------------------------------------------------------------------
-[TM] Project Athena, Athena, and Kerberos are trademarks of the
-Massachusetts Institute of Technology (MIT). No commercial use of these
-trademarks may be made without prior written permission of MIT.
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-[1] Note, however, that many applications use Kerberos' functions only upon
-the initiation of a stream-based network connection. Unless an application
-subsequently provides integrity protection for the data stream, the
-identity verification applies only to the initiation of the connection, and
-does not guarantee that subsequent messages on the connection originate
-from the same principal.
-
-[2] Secret and private are often used interchangeably in the literature. In
-our usage, it takes two (or more) to share a secret, thus a shared DES key
-is a secret key. Something is only private when no one but its owner knows
-it. Thus, in public key cryptosystems, one has a public and a private key.
-
-[3] Of course, with appropriate permission the client could arrange
-registration of a separately-named prin- cipal in a remote realm, and
-engage in normal exchanges with that realm's services. However, for even
-small numbers of clients this becomes cumbersome, and more automatic
-methods as described here are necessary.
-
-[4] Though it is permissible to request or issue tick- ets with no network
-addresses specified.
-
-[5] The password-changing request must not be honored unless the requester
-can provide the old password (the user's current secret key). Otherwise, it
-would be possible for someone to walk up to an unattended ses- sion and
-change another user's password.
-
-[6] To authenticate a user logging on to a local system, the credentials
-obtained in the AS exchange may first be used in a TGS exchange to obtain
-credentials for a local server. Those credentials must then be verified by
-a local server through successful completion of the Client/Server exchange.
-
-[7] "Random" means that, among other things, it should be impossible to
-guess the next session key based on knowledge of past session keys. This
-can only be achieved in a pseudo-random number generator if it is based on
-cryptographic principles. It is more desirable to use a truly random number
-generator, such as one based on measurements of random physical phenomena.
-
-[8] Tickets contain both an encrypted and unencrypted portion, so cleartext
-here refers to the entire unit, which can be copied from one message and
-replayed in another without any cryptographic skill.
-
-[9] Note that this can make applications based on unreliable transports
-difficult to code correctly. If the transport might deliver duplicated
-messages, either a new authenticator must be generated for each retry, or
-the application server must match requests and replies and replay the first
-reply in response to a detected duplicate.
-
-[10] This is used for user-to-user authentication as described in [8].
-
-[11] Note that the rejection here is restricted to authenticators from the
-same principal to the same server. Other client principals communicating
-with the same server principal should not be have their authenticators
-rejected if the time and microsecond fields happen to match some other
-client's authenticator.
-
-[12] In the Kerberos version 4 protocol, the timestamp in the reply was the
-client's timestamp plus one. This is not necessary in version 5 because
-version 5 messages are formatted in such a way that it is not possible to
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-create the reply by judicious message surgery (even in encrypted form)
-without knowledge of the appropriate encryption keys.
-
-[13] Note that for encrypting the KRB_AP_REP message, the sub-session key
-is not used, even if present in the Authenticator.
-
-[14] Implementations of the protocol may wish to provide routines to choose
-subkeys based on session keys and random numbers and to generate a
-negotiated key to be returned in the KRB_AP_REP message.
-
-[15]This can be accomplished in several ways. It might be known beforehand
-(since the realm is part of the principal identifier), it might be stored
-in a nameserver, or it might be obtained from a configura- tion file. If
-the realm to be used is obtained from a nameserver, there is a danger of
-being spoofed if the nameservice providing the realm name is not authenti-
-cated. This might result in the use of a realm which has been compromised,
-and would result in an attacker's ability to compromise the authentication
-of the application server to the client.
-
-[16] If the client selects a sub-session key, care must be taken to ensure
-the randomness of the selected sub- session key. One approach would be to
-generate a random number and XOR it with the session key from the
-ticket-granting ticket.
-
-[17] This allows easy implementation of user-to-user authentication [8],
-which uses ticket-granting ticket session keys in lieu of secret server
-keys in situa- tions where such secret keys could be easily comprom- ised.
-
-[18] For the purpose of appending, the realm preceding the first listed
-realm is considered to be the null realm ("").
-
-[19] For the purpose of interpreting null subfields, the client's realm is
-considered to precede those in the transited field, and the server's realm
-is considered to follow them.
-
-[20] This means that a client and server running on the same host and
-communicating with one another using the KRB_SAFE messages should not share
-a common replay cache to detect KRB_SAFE replays.
-
-[21] The implementation of the Kerberos server need not combine the
-database and the server on the same machine; it is feasible to store the
-principal database in, say, a network name service, as long as the entries
-stored therein are protected from disclosure to and modification by
-unauthorized parties. However, we recommend against such strategies, as
-they can make system management and threat analysis quite complex.
-
-[22] See the discussion of the padata field in section 5.4.2 for details on
-why this can be useful.
-
-[23] Warning for implementations that unpack and repack data structures
-during the generation and verification of embedded checksums: Because any
-checksums applied to data structures must be checked against the original
-data the length of bit strings must be preserved within a data structure
-between the time that a checksum is generated through transmission to the
-time that the checksum is verified.
-
-[24] It is NOT recommended that this time value be used to adjust the
-workstation's clock since the workstation cannot reliably determine that
-such a KRB_AS_REP actually came from the proper KDC in a timely manner.
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-r-03        November 18 1998
-
-
-
-[25] Note, however, that if the time is used as the nonce, one must make
-sure that the workstation time is monotonically increasing. If the time is
-ever reset backwards, there is a small, but finite, probability that a
-nonce will be reused.
-
-[27] An application code in the encrypted part of a message provides an
-additional check that the message was decrypted properly.
-
-[29] An application code in the encrypted part of a message provides an
-additional check that the message was decrypted properly.
-
-[31] An application code in the encrypted part of a message provides an
-additional check that the message was decrypted properly.
-
-[32] If supported by the encryption method in use, an initialization vector
-may be passed to the encryption procedure, in order to achieve proper
-cipher chaining. The initialization vector might come from the last block
-of the ciphertext from the previous KRB_PRIV message, but it is the
-application's choice whether or not to use such an initialization vector.
-If left out, the default initialization vector for the encryption algorithm
-will be used.
-
-[33] This prevents an attacker who generates an incorrect AS request from
-obtaining verifiable plaintext for use in an off-line password guessing
-attack.
-
-[35] In the above specification, UNTAGGED OCTET STRING(length) is the
-notation for an octet string with its tag and length removed. It is not a
-valid ASN.1 type. The tag bits and length must be removed from the
-confounder since the purpose of the confounder is so that the message
-starts with random data, but the tag and its length are fixed. For other
-fields, the length and tag would be redundant if they were included because
-they are specified by the encryption type. [36] The ordering of the fields
-in the CipherText is important. Additionally, messages encoded in this
-format must include a length as part of the msg-seq field. This allows the
-recipient to verify that the message has not been truncated. Without a
-length, an attacker could use a chosen plaintext attack to generate a
-message which could be truncated, while leaving the checksum intact. Note
-that if the msg-seq is an encoding of an ASN.1 SEQUENCE or OCTET STRING,
-then the length is part of that encoding.
-
-[37] In some cases, it may be necessary to use a different "mix-in" string
-for compatibility reasons; see the discussion of padata in section 5.4.2.
-
-[38] In some cases, it may be necessary to use a different "mix-in" string
-for compatibility reasons; see the discussion of padata in section 5.4.2.
-
-[39] A variant of the key is used to limit the use of a key to a particular
-function, separating the functions of generating a checksum from other
-encryption performed using the session key. The constant F0F0F0F0F0F0F0F0
-was chosen because it maintains key parity. The properties of DES precluded
-the use of the complement. The same constant is used for similar purpose in
-the Message Integrity Check in the Privacy Enhanced Mail standard.
-
-[40] This error carries additional information in the e- data field. The
-contents of the e-data field for this message is described in section
-5.9.1.
-
-
-Neuman, Ts'o, Kohl                                 Expires: 18 May 1999
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt b/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt
deleted file mode 100644
index 15921248c..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-revisions-05.txt
+++ /dev/null
@@ -1,6866 +0,0 @@
-INTERNET-DRAFT                                           Clifford Neuman
-                                                               John Kohl
-                                                           Theodore Ts'o
-                                                          March 10, 2000
-                                              Expires September 10, 2000
-
-The Kerberos Network Authentication Service (V5)
-draft-ietf-cat-kerberos-revisions-05.txt
-
-STATUS OF THIS MEMO
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC 2026. 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."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-To learn the current status of any Internet-Draft, please check the
-"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
-Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
-ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
-
-The distribution of this memo is unlimited. It is filed as
-draft-ietf-cat-kerberos-revisions-05.txt, and expires September 10, 2000.
-Please send comments to: krb-protocol@MIT.EDU
-
-ABSTRACT
-
-This document provides an overview and specification of Version 5 of the
-Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol
-and its intended use that require more detailed or clearer explanation than
-was provided in RFC1510. This document is intended to provide a detailed
-description of the protocol, suitable for implementation, together with
-descriptions of the appropriate use of protocol messages and fields within
-those messages.
-
-This document is not intended to describe Kerberos to the end user, system
-administrator, or application developer. Higher level papers describing
-Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88],
-are available elsewhere.
-
-OVERVIEW
-
-This INTERNET-DRAFT describes the concepts and model upon which the Kerberos
-network authentication system is based. It also specifies Version 5 of the
-Kerberos protocol.
-
-The motivations, goals, assumptions, and rationale behind most design
-decisions are treated cursorily; they are more fully described in a paper
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-available in IEEE communications [NT94] and earlier in the Kerberos portion
-of the Athena Technical Plan [MNSS87]. The protocols have been a proposed
-standard and are being considered for advancement for draft standard through
-the IETF standard process. Comments are encouraged on the presentation, but
-only minor refinements to the protocol as implemented or extensions that fit
-within current protocol framework will be considered at this time.
-
-Requests for addition to an electronic mailing list for discussion of
-Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU.
-This mailing list is gatewayed onto the Usenet as the group
-comp.protocols.kerberos. Requests for further information, including
-documents and code availability, may be sent to info-kerberos@MIT.EDU.
-
-BACKGROUND
-
-The Kerberos model is based in part on Needham and Schroeder's trusted
-third-party authentication protocol [NS78] and on modifications suggested by
-Denning and Sacco [DS81]. The original design and implementation of Kerberos
-Versions 1 through 4 was the work of two former Project Athena staff
-members, Steve Miller of Digital Equipment Corporation and Clifford Neuman
-(now at the Information Sciences Institute of the University of Southern
-California), along with Jerome Saltzer, Technical Director of Project
-Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members
-of Project Athena have also contributed to the work on Kerberos.
-
-Version 5 of the Kerberos protocol (described in this document) has evolved
-from Version 4 based on new requirements and desires for features not
-available in Version 4. The design of Version 5 of the Kerberos protocol was
-led by Clifford Neuman and John Kohl with much input from the community. The
-development of the MIT reference implementation was led at MIT by John Kohl
-and Theodore T'so, with help and contributed code from many others. Since
-RFC1510 was issued, extensions and revisions to the protocol have been
-proposed by many individuals. Some of these proposals are reflected in this
-document. Where such changes involved significant effort, the document cites
-the contribution of the proposer.
-
-Reference implementations of both version 4 and version 5 of Kerberos are
-publicly available and commercial implementations have been developed and
-are widely used. Details on the differences between Kerberos Versions 4 and
-5 can be found in [KNT92].
-
-1. Introduction
-
-Kerberos provides a means of verifying the identities of principals, (e.g. a
-workstation user or a network server) on an open (unprotected) network. This
-is accomplished without relying on assertions by the host operating system,
-without basing trust on host addresses, without requiring physical security
-of all the hosts on the network, and under the assumption that packets
-traveling along the network can be read, modified, and inserted at will[1].
-Kerberos performs authentication under these conditions as a trusted
-third-party authentication service by using conventional (shared secret key
-[2] cryptography. Kerberos extensions have been proposed and implemented
-that provide for the use of public key cryptography during certain phases of
-the authentication protocol. These extensions provide for authentication of
-users registered with public key certification authorities, and allow the
-system to provide certain benefits of public key cryptography in situations
-where they are needed.
-
-The basic Kerberos authentication process proceeds as follows: A client
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-sends a request to the authentication server (AS) requesting 'credentials'
-for a given server. The AS responds with these credentials, encrypted in the
-client's key. The credentials consist of 1) a 'ticket' for the server and 2)
-a temporary encryption key (often called a "session key"). The client
-transmits the ticket (which contains the client's identity and a copy of the
-session key, all encrypted in the server's key) to the server. The session
-key (now shared by the client and server) is used to authenticate the
-client, and may optionally be used to authenticate the server. It may also
-be used to encrypt further communication between the two parties or to
-exchange a separate sub-session key to be used to encrypt further
-communication.
-
-Implementation of the basic protocol consists of one or more authentication
-servers running on physically secure hosts. The authentication servers
-maintain a database of principals (i.e., users and servers) and their secret
-keys. Code libraries provide encryption and implement the Kerberos protocol.
-In order to add authentication to its transactions, a typical network
-application adds one or two calls to the Kerberos library directly or
-through the Generic Security Services Application Programming Interface,
-GSSAPI, described in separate document. These calls result in the
-transmission of the necessary messages to achieve authentication.
-
-The Kerberos protocol consists of several sub-protocols (or exchanges).
-There are two basic methods by which a client can ask a Kerberos server for
-credentials. In the first approach, the client sends a cleartext request for
-a ticket for the desired server to the AS. The reply is sent encrypted in
-the client's secret key. Usually this request is for a ticket-granting
-ticket (TGT) which can later be used with the ticket-granting server (TGS).
-In the second method, the client sends a request to the TGS. The client uses
-the TGT to authenticate itself to the TGS in the same manner as if it were
-contacting any other application server that requires Kerberos
-authentication. The reply is encrypted in the session key from the TGT.
-Though the protocol specification describes the AS and the TGS as separate
-servers, they are implemented in practice as different protocol entry points
-within a single Kerberos server.
-
-Once obtained, credentials may be used to verify the identity of the
-principals in a transaction, to ensure the integrity of messages exchanged
-between them, or to preserve privacy of the messages. The application is
-free to choose whatever protection may be necessary.
-
-To verify the identities of the principals in a transaction, the client
-transmits the ticket to the application server. Since the ticket is sent "in
-the clear" (parts of it are encrypted, but this encryption doesn't thwart
-replay) and might be intercepted and reused by an attacker, additional
-information is sent to prove that the message originated with the principal
-to whom the ticket was issued. This information (called the authenticator)
-is encrypted in the session key, and includes a timestamp. The timestamp
-proves that the message was recently generated and is not a replay.
-Encrypting the authenticator in the session key proves that it was generated
-by a party possessing the session key. Since no one except the requesting
-principal and the server know the session key (it is never sent over the
-network in the clear) this guarantees the identity of the client.
-
-The integrity of the messages exchanged between principals can also be
-guaranteed using the session key (passed in the ticket and contained in the
-credentials). This approach provides detection of both replay attacks and
-message stream modification attacks. It is accomplished by generating and
-transmitting a collision-proof checksum (elsewhere called a hash or digest
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-function) of the client's message, keyed with the session key. Privacy and
-integrity of the messages exchanged between principals can be secured by
-encrypting the data to be passed using the session key contained in the
-ticket or the subsession key found in the authenticator.
-
-The authentication exchanges mentioned above require read-only access to the
-Kerberos database. Sometimes, however, the entries in the database must be
-modified, such as when adding new principals or changing a principal's key.
-This is done using a protocol between a client and a third Kerberos server,
-the Kerberos Administration Server (KADM). There is also a protocol for
-maintaining multiple copies of the Kerberos database. Neither of these
-protocols are described in this document.
-
-1.1. Cross-Realm Operation
-
-The Kerberos protocol is designed to operate across organizational
-boundaries. A client in one organization can be authenticated to a server in
-another. Each organization wishing to run a Kerberos server establishes its
-own 'realm'. The name of the realm in which a client is registered is part
-of the client's name, and can be used by the end-service to decide whether
-to honor a request.
-
-By establishing 'inter-realm' keys, the administrators of two realms can
-allow a client authenticated in the local realm to prove its identity to
-servers in other realms[3]. The exchange of inter-realm keys (a separate key
-may be used for each direction) registers the ticket-granting service of
-each realm as a principal in the other realm. A client is then able to
-obtain a ticket-granting ticket for the remote realm's ticket-granting
-service from its local realm. When that ticket-granting ticket is used, the
-remote ticket-granting service uses the inter-realm key (which usually
-differs from its own normal TGS key) to decrypt the ticket-granting ticket,
-and is thus certain that it was issued by the client's own TGS. Tickets
-issued by the remote ticket-granting service will indicate to the
-end-service that the client was authenticated from another realm.
-
-A realm is said to communicate with another realm if the two realms share an
-inter-realm key, or if the local realm shares an inter-realm key with an
-intermediate realm that communicates with the remote realm. An
-authentication path is the sequence of intermediate realms that are
-transited in communicating from one realm to another.
-
-Realms are typically organized hierarchically. Each realm shares a key with
-its parent and a different key with each child. If an inter-realm key is not
-directly shared by two realms, the hierarchical organization allows an
-authentication path to be easily constructed. If a hierarchical organization
-is not used, it may be necessary to consult a database in order to construct
-an authentication path between realms.
-
-Although realms are typically hierarchical, intermediate realms may be
-bypassed to achieve cross-realm authentication through alternate
-authentication paths (these might be established to make communication
-between two realms more efficient). It is important for the end-service to
-know which realms were transited when deciding how much faith to place in
-the authentication process. To facilitate this decision, a field in each
-ticket contains the names of the realms that were involved in authenticating
-the client.
-
-The application server is ultimately responsible for accepting or rejecting
-authentication and should check the transited field. The application server
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-may choose to rely on the KDC for the application server's realm to check
-the transited field. The application server's KDC will set the
-TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate
-realms may also check the transited field as they issue
-ticket-granting-tickets for other realms, but they are encouraged not to do
-so. A client may request that the KDC's not check the transited field by
-setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not
-required to honor this flag.
-
-1.2. Authorization
-
-As an authentication service, Kerberos provides a means of verifying the
-identity of principals on a network. Authentication is usually useful
-primarily as a first step in the process of authorization, determining
-whether a client may use a service, which objects the client is allowed to
-access, and the type of access allowed for each. Kerberos does not, by
-itself, provide authorization. Possession of a client ticket for a service
-provides only for authentication of the client to that service, and in the
-absence of a separate authorization procedure, it should not be considered
-by an application as authorizing the use of that service.
-
-Such separate authorization methods may be implemented as application
-specific access control functions and may be based on files such as the
-application server, or on separately issued authorization credentials such
-as those based on proxies [Neu93], or on other authorization services.
-Separately authenticated authorization credentials may be embedded in a
-tickets authorization data when encapsulated by the kdc-issued authorization
-data element.
-
-Applications should not be modified to accept the mere issuance of a service
-ticket by the Kerberos server (even by a modified Kerberos server) as
-granting authority to use the service, since such applications may become
-vulnerable to the bypass of this authorization check in an environment if
-they interoperate with other KDCs or where other options for application
-authentication (e.g. the PKTAPP proposal) are provided.
-
-1.3. Environmental assumptions
-
-Kerberos imposes a few assumptions on the environment in which it can
-properly function:
-
-   * 'Denial of service' attacks are not solved with Kerberos. There are
-     places in these protocols where an intruder can prevent an application
-     from participating in the proper authentication steps. Detection and
-     solution of such attacks (some of which can appear to be nnot-uncommon
-     'normal' failure modes for the system) is usually best left to the
-     human administrators and users.
-   * Principals must keep their secret keys secret. If an intruder somehow
-     steals a principal's key, it will be able to masquerade as that
-     principal or impersonate any server to the legitimate principal.
-   * 'Password guessing' attacks are not solved by Kerberos. If a user
-     chooses a poor password, it is possible for an attacker to successfully
-     mount an offline dictionary attack by repeatedly attempting to decrypt,
-     with successive entries from a dictionary, messages obtained which are
-     encrypted under a key derived from the user's password.
-   * Each host on the network must have a clock which is 'loosely
-     synchronized' to the time of the other hosts; this synchronization is
-     used to reduce the bookkeeping needs of application servers when they
-     do replay detection. The degree of "looseness" can be configured on a
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     per-server basis, but is typically on the order of 5 minutes. If the
-     clocks are synchronized over the network, the clock synchronization
-     protocol must itself be secured from network attackers.
-   * Principal identifiers are not recycled on a short-term basis. A typical
-     mode of access control will use access control lists (ACLs) to grant
-     permissions to particular principals. If a stale ACL entry remains for
-     a deleted principal and the principal identifier is reused, the new
-     principal will inherit rights specified in the stale ACL entry. By not
-     re-using principal identifiers, the danger of inadvertent access is
-     removed.
-
-1.4. Glossary of terms
-
-Below is a list of terms used throughout this document.
-
-Authentication
-     Verifying the claimed identity of a principal.
-Authentication header
-     A record containing a Ticket and an Authenticator to be presented to a
-     server as part of the authentication process.
-Authentication path
-     A sequence of intermediate realms transited in the authentication
-     process when communicating from one realm to another.
-Authenticator
-     A record containing information that can be shown to have been recently
-     generated using the session key known only by the client and server.
-Authorization
-     The process of determining whether a client may use a service, which
-     objects the client is allowed to access, and the type of access allowed
-     for each.
-Capability
-     A token that grants the bearer permission to access an object or
-     service. In Kerberos, this might be a ticket whose use is restricted by
-     the contents of the authorization data field, but which lists no
-     network addresses, together with the session key necessary to use the
-     ticket.
-Ciphertext
-     The output of an encryption function. Encryption transforms plaintext
-     into ciphertext.
-Client
-     A process that makes use of a network service on behalf of a user. Note
-     that in some cases a Server may itself be a client of some other server
-     (e.g. a print server may be a client of a file server).
-Credentials
-     A ticket plus the secret session key necessary to successfully use that
-     ticket in an authentication exchange.
-KDC
-     Key Distribution Center, a network service that supplies tickets and
-     temporary session keys; or an instance of that service or the host on
-     which it runs. The KDC services both initial ticket and ticket-granting
-     ticket requests. The initial ticket portion is sometimes referred to as
-     the Authentication Server (or service). The ticket-granting ticket
-     portion is sometimes referred to as the ticket-granting server (or
-     service).
-Kerberos
-     Aside from the 3-headed dog guarding Hades, the name given to Project
-     Athena's authentication service, the protocol used by that service, or
-     the code used to implement the authentication service.
-Plaintext
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     The input to an encryption function or the output of a decryption
-     function. Decryption transforms ciphertext into plaintext.
-Principal
-     A uniquely named client or server instance that participates in a
-     network communication.
-Principal identifier
-     The name used to uniquely identify each different principal.
-Seal
-     To encipher a record containing several fields in such a way that the
-     fields cannot be individually replaced without either knowledge of the
-     encryption key or leaving evidence of tampering.
-Secret key
-     An encryption key shared by a principal and the KDC, distributed
-     outside the bounds of the system, with a long lifetime. In the case of
-     a human user's principal, the secret key is derived from a password.
-Server
-     A particular Principal which provides a resource to network clients.
-     The server is sometimes refered to as the Application Server.
-Service
-     A resource provided to network clients; often provided by more than one
-     server (for example, remote file service).
-Session key
-     A temporary encryption key used between two principals, with a lifetime
-     limited to the duration of a single login "session".
-Sub-session key
-     A temporary encryption key used between two principals, selected and
-     exchanged by the principals using the session key, and with a lifetime
-     limited to the duration of a single association.
-Ticket
-     A record that helps a client authenticate itself to a server; it
-     contains the client's identity, a session key, a timestamp, and other
-     information, all sealed using the server's secret key. It only serves
-     to authenticate a client when presented along with a fresh
-     Authenticator.
-
-2. Ticket flag uses and requests
-
-Each Kerberos ticket contains a set of flags which are used to indicate
-various attributes of that ticket. Most flags may be requested by a client
-when the ticket is obtained; some are automatically turned on and off by a
-Kerberos server as required. The following sections explain what the various
-flags mean, and gives examples of reasons to use such a flag.
-
-2.1. Initial and pre-authenticated tickets
-
-The INITIAL flag indicates that a ticket was issued using the AS protocol
-and not issued based on a ticket-granting ticket. Application servers that
-want to require the demonstrated knowledge of a client's secret key (e.g. a
-password-changing program) can insist that this flag be set in any tickets
-they accept, and thus be assured that the client's key was recently
-presented to the application client.
-
-The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the
-initial authentication, regardless of whether the current ticket was issued
-directly (in which case INITIAL will also be set) or issued on the basis of
-a ticket-granting ticket (in which case the INITIAL flag is clear, but the
-PRE-AUTHENT and HW-AUTHENT flags are carried forward from the
-ticket-granting ticket).
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-2.2. Invalid tickets
-
-The INVALID flag indicates that a ticket is invalid. Application servers
-must reject tickets which have this flag set. A postdated ticket will
-usually be issued in this form. Invalid tickets must be validated by the KDC
-before use, by presenting them to the KDC in a TGS request with the VALIDATE
-option specified. The KDC will only validate tickets after their starttime
-has passed. The validation is required so that postdated tickets which have
-been stolen before their starttime can be rendered permanently invalid
-(through a hot-list mechanism) (see section 3.3.3.1).
-
-2.3. Renewable tickets
-
-Applications may desire to hold tickets which can be valid for long periods
-of time. However, this can expose their credentials to potential theft for
-equally long periods, and those stolen credentials would be valid until the
-expiration time of the ticket(s). Simply using short-lived tickets and
-obtaining new ones periodically would require the client to have long-term
-access to its secret key, an even greater risk. Renewable tickets can be
-used to mitigate the consequences of theft. Renewable tickets have two
-"expiration times": the first is when the current instance of the ticket
-expires, and the second is the latest permissible value for an individual
-expiration time. An application client must periodically (i.e. before it
-expires) present a renewable ticket to the KDC, with the RENEW option set in
-the KDC request. The KDC will issue a new ticket with a new session key and
-a later expiration time. All other fields of the ticket are left unmodified
-by the renewal process. When the latest permissible expiration time arrives,
-the ticket expires permanently. At each renewal, the KDC may consult a
-hot-list to determine if the ticket had been reported stolen since its last
-renewal; it will refuse to renew such stolen tickets, and thus the usable
-lifetime of stolen tickets is reduced.
-
-The RENEWABLE flag in a ticket is normally only interpreted by the
-ticket-granting service (discussed below in section 3.3). It can usually be
-ignored by application servers. However, some particularly careful
-application servers may wish to disallow renewable tickets.
-
-If a renewable ticket is not renewed by its expiration time, the KDC will
-not renew the ticket. The RENEWABLE flag is reset by default, but a client
-may request it be set by setting the RENEWABLE option in the KRB_AS_REQ
-message. If it is set, then the renew-till field in the ticket contains the
-time after which the ticket may not be renewed.
-
-2.4. Postdated tickets
-
-Applications may occasionally need to obtain tickets for use much later,
-e.g. a batch submission system would need tickets to be valid at the time
-the batch job is serviced. However, it is dangerous to hold valid tickets in
-a batch queue, since they will be on-line longer and more prone to theft.
-Postdated tickets provide a way to obtain these tickets from the KDC at job
-submission time, but to leave them "dormant" until they are activated and
-validated by a further request of the KDC. If a ticket theft were reported
-in the interim, the KDC would refuse to validate the ticket, and the thief
-would be foiled.
-
-The MAY-POSTDATE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. This flag
-must be set in a ticket-granting ticket in order to issue a postdated ticket
-based on the presented ticket. It is reset by default; it may be requested
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-by a client by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message.
-This flag does not allow a client to obtain a postdated ticket-granting
-ticket; postdated ticket-granting tickets can only by obtained by requesting
-the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a
-postdated ticket will be the remaining life of the ticket-granting ticket at
-the time of the request, unless the RENEWABLE option is also set, in which
-case it can be the full life (endtime-starttime) of the ticket-granting
-ticket. The KDC may limit how far in the future a ticket may be postdated.
-
-The POSTDATED flag indicates that a ticket has been postdated. The
-application server can check the authtime field in the ticket to see when
-the original authentication occurred. Some services may choose to reject
-postdated tickets, or they may only accept them within a certain period
-after the original authentication. When the KDC issues a POSTDATED ticket,
-it will also be marked as INVALID, so that the application client must
-present the ticket to the KDC to be validated before use.
-
-2.5. Proxiable and proxy tickets
-
-At times it may be necessary for a principal to allow a service to perform
-an operation on its behalf. The service must be able to take on the identity
-of the client, but only for a particular purpose. A principal can allow a
-service to take on the principal's identity for a particular purpose by
-granting it a proxy.
-
-The process of granting a proxy using the proxy and proxiable flags is used
-to provide credentials for use with specific services. Though conceptually
-also a proxy, user's wishing to delegate their identity for ANY purpose must
-use the ticket forwarding mechanism described in the next section to forward
-a ticket granting ticket.
-
-The PROXIABLE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. When set,
-this flag tells the ticket-granting server that it is OK to issue a new
-ticket (but not a ticket-granting ticket) with a different network address
-based on this ticket. This flag is set if requested by the client on initial
-authentication. By default, the client will request that it be set when
-requesting a ticket granting ticket, and reset when requesting any other
-ticket.
-
-This flag allows a client to pass a proxy to a server to perform a remote
-request on its behalf, e.g. a print service client can give the print server
-a proxy to access the client's files on a particular file server in order to
-satisfy a print request.
-
-In order to complicate the use of stolen credentials, Kerberos tickets are
-usually valid from only those network addresses specifically included in the
-ticket[4]. When granting a proxy, the client must specify the new network
-address from which the proxy is to be used, or indicate that the proxy is to
-be issued for use from any address.
-
-The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket.
-Application servers may check this flag and at their option they may require
-additional authentication from the agent presenting the proxy in order to
-provide an audit trail.
-
-2.6. Forwardable tickets
-
-Authentication forwarding is an instance of a proxy where the service is
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-granted complete use of the client's identity. An example where it might be
-used is when a user logs in to a remote system and wants authentication to
-work from that system as if the login were local.
-
-The FORWARDABLE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. The
-FORWARDABLE flag has an interpretation similar to that of the PROXIABLE
-flag, except ticket-granting tickets may also be issued with different
-network addresses. This flag is reset by default, but users may request that
-it be set by setting the FORWARDABLE option in the AS request when they
-request their initial ticket- granting ticket.
-
-This flag allows for authentication forwarding without requiring the user to
-enter a password again. If the flag is not set, then authentication
-forwarding is not permitted, but the same result can still be achieved if
-the user engages in the AS exchange specifying the requested network
-addresses and supplies a password.
-
-The FORWARDED flag is set by the TGS when a client presents a ticket with
-the FORWARDABLE flag set and requests a forwarded ticket by specifying the
-FORWARDED KDC option and supplying a set of addresses for the new ticket. It
-is also set in all tickets issued based on tickets with the FORWARDED flag
-set. Application servers may choose to process FORWARDED tickets differently
-than non-FORWARDED tickets.
-
-2.7. Other KDC options
-
-There are two additional options which may be set in a client's request of
-the KDC. The RENEWABLE-OK option indicates that the client will accept a
-renewable ticket if a ticket with the requested life cannot otherwise be
-provided. If a ticket with the requested life cannot be provided, then the
-KDC may issue a renewable ticket with a renew-till equal to the the
-requested endtime. The value of the renew-till field may still be adjusted
-by site-determined limits or limits imposed by the individual principal or
-server.
-
-The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service.
-It indicates that the ticket to be issued for the end server is to be
-encrypted in the session key from the a additional second ticket-granting
-ticket provided with the request. See section 3.3.3 for specific details.
-
-3. Message Exchanges
-
-The following sections describe the interactions between network clients and
-servers and the messages involved in those exchanges.
-
-3.1. The Authentication Service Exchange
-
-                          Summary
-      Message direction       Message type    Section
-      1. Client to Kerberos   KRB_AS_REQ      5.4.1
-      2. Kerberos to client   KRB_AS_REP or   5.4.2
-                              KRB_ERROR       5.9.1
-
-The Authentication Service (AS) Exchange between the client and the Kerberos
-Authentication Server is initiated by a client when it wishes to obtain
-authentication credentials for a given server but currently holds no
-credentials. In its basic form, the client's secret key is used for
-encryption and decryption. This exchange is typically used at the initiation
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-of a login session to obtain credentials for a Ticket-Granting Server which
-will subsequently be used to obtain credentials for other servers (see
-section 3.3) without requiring further use of the client's secret key. This
-exchange is also used to request credentials for services which must not be
-mediated through the Ticket-Granting Service, but rather require a
-principal's secret key, such as the password-changing service[5]. This
-exchange does not by itself provide any assurance of the the identity of the
-user[6].
-
-The exchange consists of two messages: KRB_AS_REQ from the client to
-Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
-messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
-
-In the request, the client sends (in cleartext) its own identity and the
-identity of the server for which it is requesting credentials. The response,
-KRB_AS_REP, contains a ticket for the client to present to the server, and a
-session key that will be shared by the client and the server. The session
-key and additional information are encrypted in the client's secret key. The
-KRB_AS_REP message contains information which can be used to detect replays,
-and to associate it with the message to which it replies. Various errors can
-occur; these are indicated by an error response (KRB_ERROR) instead of the
-KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR
-message contains information which can be used to associate it with the
-message to which it replies. The lack of encryption in the KRB_ERROR message
-precludes the ability to detect replays, fabrications, or modifications of
-such messages.
-
-Without preautentication, the authentication server does not know whether
-the client is actually the principal named in the request. It simply sends a
-reply without knowing or caring whether they are the same. This is
-acceptable because nobody but the principal whose identity was given in the
-request will be able to use the reply. Its critical information is encrypted
-in that principal's key. The initial request supports an optional field that
-can be used to pass additional information that might be needed for the
-initial exchange. This field may be used for preauthentication as described
-in section [hl<>].
-
-3.1.1. Generation of KRB_AS_REQ message
-
-The client may specify a number of options in the initial request. Among
-these options are whether pre-authentication is to be performed; whether the
-requested ticket is to be renewable, proxiable, or forwardable; whether it
-should be postdated or allow postdating of derivative tickets; and whether a
-renewable ticket will be accepted in lieu of a non-renewable ticket if the
-requested ticket expiration date cannot be satisfied by a non-renewable
-ticket (due to configuration constraints; see section 4). See section A.1
-for pseudocode.
-
-The client prepares the KRB_AS_REQ message and sends it to the KDC.
-
-3.1.2. Receipt of KRB_AS_REQ message
-
-If all goes well, processing the KRB_AS_REQ message will result in the
-creation of a ticket for the client to present to the server. The format for
-the ticket is described in section 5.3.1. The contents of the ticket are
-determined as follows.
-
-3.1.3. Generation of KRB_AS_REP message
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-The authentication server looks up the client and server principals named in
-the KRB_AS_REQ in its database, extracting their respective keys. If
-required, the server pre-authenticates the request, and if the
-pre-authentication check fails, an error message with the code
-KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the
-requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP
-is returned. Otherwise it generates a 'random' session key[7].
-
-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. [***I will change the example keytypes to be 3DES
-based examples 7/14***]
-
-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.
-
-If the requested start time is absent, indicates a time in the past, or is
-within the window of acceptable clock skew for the KDC and the POSTDATE
-option has not been specified, then the start time of the ticket is set to
-the authentication server's current time. If it indicates a time in the
-future beyond the acceptable clock skew, but the POSTDATED option has not
-been specified then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise
-the requested start time is checked against the policy of the local realm
-(the administrator might decide to prohibit certain types or ranges of
-postdated tickets), and if acceptable, the ticket's start time is set as
-requested and the INVALID flag is set in the new ticket. The postdated
-ticket must be validated before use by presenting it to the KDC after the
-start time has been reached.
-
-The expiration time of the ticket will be set to the minimum of the
-following:
-
-   * The expiration time (endtime) requested in the KRB_AS_REQ message.
-   * The ticket's start time plus the maximum allowable lifetime associated
-     with the client principal (the authentication server's database
-     includes a maximum ticket lifetime field in each principal's record;
-     see section 4).
-   * The ticket's start time plus the maximum allowable lifetime associated
-     with the server principal.
-   * The ticket's start time plus the maximum lifetime set by the policy of
-     the local realm.
-
-If the requested expiration time minus the start time (as determined above)
-is less than a site-determined minimum lifetime, an error message with code
-KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the
-ticket exceeds what was determined as above, and if the 'RENEWABLE-OK'
-option was requested, then the 'RENEWABLE' flag is set in the new ticket,
-and the renew-till value is set as if the 'RENEWABLE' option were requested
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-(the field and option names are described fully in section 5.4.1).
-
-If the RENEWABLE option has been requested or if the RENEWABLE-OK option has
-been set and a renewable ticket is to be issued, then the renew-till field
-is set to the minimum of:
-
-   * Its requested value.
-   * The start time of the ticket plus the minimum of the two maximum
-     renewable lifetimes associated with the principals' database entries.
-   * The start time of the ticket plus the maximum renewable lifetime set by
-     the policy of the local realm.
-
-The flags field of the new ticket will have the following options set if
-they have been requested and if the policy of the local realm allows:
-FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new
-ticket is post-dated (the start time is in the future), its INVALID flag
-will also be set.
-
-If all of the above succeed, the server formats a KRB_AS_REP message (see
-section 5.4.2), copying the addresses in the request into the caddr of the
-response, placing any required pre-authentication data into the padata of
-the response, and encrypts the ciphertext part in the client's key using the
-requested encryption method, and sends it to the client. See section A.2 for
-pseudocode.
-
-3.1.4. Generation of KRB_ERROR message
-
-Several errors can occur, and the Authentication Server responds by
-returning an error message, KRB_ERROR, to the client, with the error-code
-and e-text fields set to appropriate values. The error message contents and
-details are described in Section 5.9.1.
-
-3.1.5. Receipt of KRB_AS_REP message
-
-If the reply message type is KRB_AS_REP, then the client verifies that the
-cname and crealm fields in the cleartext portion of the reply match what it
-requested. If any padata fields are present, they may be used to derive the
-proper secret key to decrypt the message. The client decrypts the encrypted
-part of the response using its secret key, verifies that the nonce in the
-encrypted part matches the nonce it supplied in its request (to detect
-replays). It also verifies that the sname and srealm in the response match
-those in the request (or are otherwise expected values), and that the host
-address field is also correct. It then stores the ticket, session key, start
-and expiration times, and other information for later use. The
-key-expiration field from the encrypted part of the response may be checked
-to notify the user of impending key expiration (the client program could
-then suggest remedial action, such as a password change). See section A.3
-for pseudocode.
-
-Proper decryption of the KRB_AS_REP message is not sufficient to verify the
-identity of the user; the user and an attacker could cooperate to generate a
-KRB_AS_REP format message which decrypts properly but is not from the proper
-KDC. If the host wishes to verify the identity of the user, it must require
-the user to present application credentials which can be verified using a
-securely-stored secret key for the host. If those credentials can be
-verified, then the identity of the user can be assured.
-
-3.1.6. Receipt of KRB_ERROR message
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-If the reply message type is KRB_ERROR, then the client interprets it as an
-error and performs whatever application-specific tasks are necessary to
-recover.
-
-3.2. The Client/Server Authentication Exchange
-
-                             Summary
-Message direction                         Message type    Section
-Client to Application server              KRB_AP_REQ      5.5.1
-[optional] Application server to client   KRB_AP_REP or   5.5.2
-                                          KRB_ERROR       5.9.1
-
-The client/server authentication (CS) exchange is used by network
-applications to authenticate the client to the server and vice versa. The
-client must have already acquired credentials for the server using the AS or
-TGS exchange.
-
-3.2.1. The KRB_AP_REQ message
-
-The KRB_AP_REQ contains authentication information which should be part of
-the first message in an authenticated transaction. It contains a ticket, an
-authenticator, and some additional bookkeeping information (see section
-5.5.1 for the exact format). The ticket by itself is insufficient to
-authenticate a client, since tickets are passed across the network in
-cleartext[DS90], so the authenticator is used to prevent invalid replay of
-tickets by proving to the server that the client knows the session key of
-the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is
-referred to elsewhere as the 'authentication header.'
-
-3.2.2. Generation of a KRB_AP_REQ message
-
-When a client wishes to initiate authentication to a server, it obtains
-(either through a credentials cache, the AS exchange, or the TGS exchange) a
-ticket and session key for the desired service. The client may re-use any
-tickets it holds until they expire. To use a ticket the client constructs a
-new Authenticator from the the system time, its name, and optionally an
-application specific checksum, an initial sequence number to be used in
-KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in
-negotiations for a session key unique to this particular session.
-Authenticators may not be re-used and will be rejected if replayed to a
-server[LGDSR87]. If a sequence number is to be included, it should be
-randomly chosen so that even after many messages have been exchanged it is
-not likely to collide with other sequence numbers in use.
-
-The client may indicate a requirement of mutual authentication or the use of
-a session-key based ticket by setting the appropriate flag(s) in the
-ap-options field of the message.
-
-The Authenticator is encrypted in the session key and combined with the
-ticket to form the KRB_AP_REQ message which is then sent to the end server
-along with any additional application-specific information. See section A.9
-for pseudocode.
-
-3.2.3. Receipt of KRB_AP_REQ message
-
-Authentication is based on the server's current time of day (clocks must be
-loosely synchronized), the authenticator, and the ticket. Several errors are
-possible. If an error occurs, the server is expected to reply to the client
-with a KRB_ERROR message. This message may be encapsulated in the
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-application protocol if its 'raw' form is not acceptable to the protocol.
-The format of error messages is described in section 5.9.1.
-
-The algorithm for verifying authentication information is as follows. If the
-message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE
-error. If the key version indicated by the Ticket in the KRB_AP_REQ is not
-one the server can use (e.g., it indicates an old key, and the server no
-longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is
-returned. If the USE-SESSION-KEY flag is set in the ap-options field, it
-indicates to the server that the ticket is encrypted in the session key from
-the server's ticket-granting ticket rather than its secret key[10]. Since it
-is possible for the server to be registered in multiple realms, with
-different keys in each, the srealm field in the unencrypted portion of the
-ticket in the KRB_AP_REQ is used to specify which secret key the server
-should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is
-returned if the server doesn't have the proper key to decipher the ticket.
-
-The ticket is decrypted using the version of the server's key specified by
-the ticket. If the decryption routines detect a modification of the ticket
-(each encryption system must provide safeguards to detect modified
-ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned
-(chances are good that different keys were used to encrypt and decrypt).
-
-The authenticator is decrypted using the session key extracted from the
-decrypted ticket. If decryption shows it to have been modified, the
-KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client
-from the ticket are compared against the same fields in the authenticator.
-If they don't match, the KRB_AP_ERR_BADMATCH error is returned (they might
-not match, for example, if the wrong session key was used to encrypt the
-authenticator). The addresses in the ticket (if any) are then searched for
-an address matching the operating-system reported address of the client. If
-no match is found or the server insists on ticket addresses but none are
-present in the ticket, the KRB_AP_ERR_BADADDR error is returned.
-
-If the local (server) time and the client time in the authenticator differ
-by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW
-error is returned. If the server name, along with the client name, time and
-microsecond fields from the Authenticator match any recently-seen such
-tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The server must
-remember any authenticator presented within the allowable clock skew, so
-that a replay attempt is guaranteed to fail. If a server loses track of any
-authenticator presented within the allowable clock skew, it must reject all
-requests until the clock skew interval has passed. This assures that any
-lost or re-played authenticators will fall outside the allowable clock skew
-and can no longer be successfully replayed (If this is not done, an attacker
-could conceivably record the ticket and authenticator sent over the network
-to a server, then disable the client's host, pose as the disabled host, and
-replay the ticket and authenticator to subvert the authentication.). If a
-sequence number is provided in the authenticator, the server saves it for
-later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey is
-present, the server either saves it for later use or uses it to help
-generate its own choice for a subkey to be returned in a KRB_AP_REP message.
-
-The server computes the age of the ticket: local (server) time minus the
-start time inside the Ticket. If the start time is later than the current
-time by more than the allowable clock skew or if the INVALID flag is set in
-the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the
-current time is later than end time by more than the allowable clock skew,
-the KRB_AP_ERR_TKT_EXPIRED error is returned.
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-
-If all these checks succeed without an error, the server is assured that the
-client possesses the credentials of the principal named in the ticket and
-thus, the client has been authenticated to the server. See section A.10 for
-pseudocode.
-
-Passing these checks provides only authentication of the named principal; it
-does not imply authorization to use the named service. Applications must
-make a separate authorization decisions based upon the authenticated name of
-the user, the requested operation, local acces control information such as
-that contained in a .k5login or .k5users file, and possibly a separate
-distributed authorization service.
-
-3.2.4. Generation of a KRB_AP_REP message
-
-Typically, a client's request will include both the authentication
-information and its initial request in the same message, and the server need
-not explicitly reply to the KRB_AP_REQ. However, if mutual authentication
-(not only authenticating the client to the server, but also the server to
-the client) is being performed, the KRB_AP_REQ message will have
-MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is
-required in response. As with the error message, this message may be
-encapsulated in the application protocol if its "raw" form is not acceptable
-to the application's protocol. The timestamp and microsecond field used in
-the reply must be the client's timestamp and microsecond field (as provided
-in the authenticator)[12]. If a sequence number is to be included, it should
-be randomly chosen as described above for the authenticator. A subkey may be
-included if the server desires to negotiate a different subkey. The
-KRB_AP_REP message is encrypted in the session key extracted from the
-ticket. See section A.11 for pseudocode.
-
-3.2.5. Receipt of KRB_AP_REP message
-
-If a KRB_AP_REP message is returned, the client uses the session key from
-the credentials obtained for the server[13] to decrypt the message, and
-verifies that the timestamp and microsecond fields match those in the
-Authenticator it sent to the server. If they match, then the client is
-assured that the server is genuine. The sequence number and subkey (if
-present) are retained for later use. See section A.12 for pseudocode.
-
-3.2.6. Using the encryption key
-
-After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server
-share an encryption key which can be used by the application. The 'true
-session key' to be used for KRB_PRIV, KRB_SAFE, or other
-application-specific uses may be chosen by the application based on the
-subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases,
-the use of this session key will be implicit in the protocol; in others the
-method of use must be chosen from several alternatives. We leave the
-protocol negotiations of how to use the key (e.g. selecting an encryption or
-checksum type) to the application programmer; the Kerberos protocol does not
-constrain the implementation options, but an example of how this might be
-done follows.
-
-One way that an application may choose to negotiate a key to be used for
-subequent integrity and privacy protection is for the client to propose a
-key in the subkey field of the authenticator. The server can then choose a
-key using the proposed key from the client as input, returning the new
-subkey in the subkey field of the application reply. This key could then be
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-used for subsequent communication. To make this example more concrete, if
-the encryption method in use required a 56 bit key, and for whatever reason,
-one of the parties was prevented from using a key with more than 40 unknown
-bits, this method would allow the the party which is prevented from using
-more than 40 bits to either propose (if the client) an initial key with a
-known quantity for 16 of those bits, or to mask 16 of the bits (if the
-server) with the known quantity. The application implementor is warned,
-however, that this is only an example, and that an analysis of the
-particular crytosystem to be used, and the reasons for limiting the key
-length, must be made before deciding whether it is acceptable to mask bits
-of the key.
-
-With both the one-way and mutual authentication exchanges, the peers should
-take care not to send sensitive information to each other without proper
-assurances. In particular, applications that require privacy or integrity
-should use the KRB_AP_REP response from the server to client to assure both
-client and server of their peer's identity. If an application protocol
-requires privacy of its messages, it can use the KRB_PRIV message (section
-3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity.
-
-3.3. The Ticket-Granting Service (TGS) Exchange
-
-                          Summary
-      Message direction       Message type     Section
-      1. Client to Kerberos   KRB_TGS_REQ      5.4.1
-      2. Kerberos to client   KRB_TGS_REP or   5.4.2
-                              KRB_ERROR        5.9.1
-
-The TGS exchange between a client and the Kerberos Ticket-Granting Server is
-initiated by a client when it wishes to obtain authentication credentials
-for a given server (which might be registered in a remote realm), when it
-wishes to renew or validate an existing ticket, or when it wishes to obtain
-a proxy ticket. In the first case, the client must already have acquired a
-ticket for the Ticket-Granting Service using the AS exchange (the
-ticket-granting ticket is usually obtained when a client initially
-authenticates to the system, such as when a user logs in). The message
-format for the TGS exchange is almost identical to that for the AS exchange.
-The primary difference is that encryption and decryption in the TGS exchange
-does not take place under the client's key. Instead, the session key from
-the ticket-granting ticket or renewable ticket, or sub-session key from an
-Authenticator is used. As is the case for all application servers, expired
-tickets are not accepted by the TGS, so once a renewable or ticket-granting
-ticket expires, the client must use a separate exchange to obtain valid
-tickets.
-
-The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the
-client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or
-KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the
-client plus a request for credentials. The authentication information
-consists of the authentication header (KRB_AP_REQ) which includes the
-client's previously obtained ticket-granting, renewable, or invalid ticket.
-In the ticket-granting ticket and proxy cases, the request may include one
-or more of: a list of network addresses, a collection of typed authorization
-data to be sealed in the ticket for authorization use by the application
-server, or additional tickets (the use of which are described later). The
-TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the
-session key from the ticket-granting ticket or renewable ticket, or if
-present, in the sub-session key from the Authenticator (part of the
-authentication header). The KRB_ERROR message contains an error code and
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-text explaining what went wrong. The KRB_ERROR message is not encrypted. The
-KRB_TGS_REP message contains information which can be used to detect
-replays, and to associate it with the message to which it replies. The
-KRB_ERROR message also contains information which can be used to associate
-it with the message to which it replies, but the lack of encryption in the
-KRB_ERROR message precludes the ability to detect replays or fabrications of
-such messages.
-
-3.3.1. Generation of KRB_TGS_REQ message
-
-Before sending a request to the ticket-granting service, the client must
-determine in which realm the application server is registered[15]. If the
-client does not already possess a ticket-granting ticket for the appropriate
-realm, then one must be obtained. This is first attempted by requesting a
-ticket-granting ticket for the destination realm from a Kerberos server for
-which the client does posess a ticket-granting ticket (using the KRB_TGS_REQ
-message recursively). The Kerberos server may return a TGT for the desired
-realm in which case one can proceed. Alternatively, the Kerberos server may
-return a TGT for a realm which is 'closer' to the desired realm (further
-along the standard hierarchical path), in which case this step must be
-repeated with a Kerberos server in the realm specified in the returned TGT.
-If neither are returned, then the request must be retried with a Kerberos
-server for a realm higher in the hierarchy. This request will itself require
-a ticket-granting ticket for the higher realm which must be obtained by
-recursively applying these directions.
-
-Once the client obtains a ticket-granting ticket for the appropriate realm,
-it determines which Kerberos servers serve that realm, and contacts one. The
-list might be obtained through a configuration file or network service or it
-may be generated from the name of the realm; as long as the secret keys
-exchanged by realms are kept secret, only denial of service results from
-using a false Kerberos server.
-
-As in the AS exchange, the client may specify a number of options in the
-KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing
-an authentication header as an element of the padata field, and including
-the same fields as used in the KRB_AS_REQ message along with several
-optional fields: the enc-authorization-data field for application server use
-and additional tickets required by some options.
-
-In preparing the authentication header, the client can select a sub-session
-key under which the response from the Kerberos server will be encrypted[16].
-If the sub-session key is not specified, the session key from the
-ticket-granting ticket will be used. If the enc-authorization-data is
-present, it must be encrypted in the sub-session key, if present, from the
-authenticator portion of the authentication header, or if not present, using
-the session key from the ticket-granting ticket.
-
-Once prepared, the message is sent to a Kerberos server for the destination
-realm. See section A.5 for pseudocode.
-
-3.3.2. Receipt of KRB_TGS_REQ message
-
-The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ
-message, but there are many additional checks to be performed. First, the
-Kerberos server must determine which server the accompanying ticket is for
-and it must select the appropriate key to decrypt it. For a normal
-KRB_TGS_REQ message, it will be for the ticket granting service, and the
-TGS's key will be used. If the TGT was issued by another realm, then the
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-appropriate inter-realm key must be used. If the accompanying ticket is not
-a ticket granting ticket for the current realm, but is for an application
-server in the current realm, the RENEW, VALIDATE, or PROXY options are
-specified in the request, and the server for which a ticket is requested is
-the server named in the accompanying ticket, then the KDC will decrypt the
-ticket in the authentication header using the key of the server for which it
-was issued. If no ticket can be found in the padata field, the
-KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
-
-Once the accompanying ticket has been decrypted, the user-supplied checksum
-in the Authenticator must be verified against the contents of the request,
-and the message rejected if the checksums do not match (with an error code
-of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not
-collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the
-checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is
-returned. If the authorization-data are present, they are decrypted using
-the sub-session key from the Authenticator.
-
-If any of the decryptions indicate failed integrity checks, the
-KRB_AP_ERR_BAD_INTEGRITY error is returned.
-
-3.3.3. Generation of KRB_TGS_REP message
-
-The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP),
-but with its type field set to KRB_TGS_REP. The detailed specification is in
-section 5.4.2.
-
-The response will include a ticket for the requested server. The Kerberos
-database is queried to retrieve the record for the requested server
-(including the key with which the ticket will be encrypted). If the request
-is for a ticket granting ticket for a remote realm, and if no key is shared
-with the requested realm, then the Kerberos server will select the realm
-"closest" to the requested realm with which it does share a key, and use
-that realm instead. This is the only case where the response from the KDC
-will be for a different server than that requested by the client.
-
-By default, the address field, the client's name and realm, the list of
-transited realms, the time of initial authentication, the expiration time,
-and the authorization data of the newly-issued ticket will be copied from
-the ticket-granting ticket (TGT) or renewable ticket. If the transited field
-needs to be updated, but the transited type is not supported, the
-KDC_ERR_TRTYPE_NOSUPP error is returned.
-
-If the request specifies an endtime, then the endtime of the new ticket is
-set to the minimum of (a) that request, (b) the endtime from the TGT, and
-(c) the starttime of the TGT plus the minimum of the maximum life for the
-application server and the maximum life for the local realm (the maximum
-life for the requesting principal was already applied when the TGT was
-issued). If the new ticket is to be a renewal, then the endtime above is
-replaced by the minimum of (a) the value of the renew_till field of the
-ticket and (b) the starttime for the new ticket plus the life
-(endtime-starttime) of the old ticket.
-
-If the FORWARDED option has been requested, then the resulting ticket will
-contain the addresses specified by the client. This option will only be
-honored if the FORWARDABLE flag is set in the TGT. The PROXY option is
-similar; the resulting ticket will contain the addresses specified by the
-client. It will be honored only if the PROXIABLE flag in the TGT is set. The
-PROXY option will not be honored on requests for additional ticket-granting
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-tickets.
-
-If the requested start time is absent, indicates a time in the past, or is
-within the window of acceptable clock skew for the KDC and the POSTDATE
-option has not been specified, then the start time of the ticket is set to
-the authentication server's current time. If it indicates a time in the
-future beyond the acceptable clock skew, but the POSTDATED option has not
-been specified or the MAY-POSTDATE flag is not set in the TGT, then the
-error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-granting
-ticket has the MAY-POSTDATE flag set, then the resulting ticket will be
-postdated and the requested starttime is checked against the policy of the
-local realm. If acceptable, the ticket's start time is set as requested, and
-the INVALID flag is set. The postdated ticket must be validated before use
-by presenting it to the KDC after the starttime has been reached. However,
-in no case may the starttime, endtime, or renew-till time of a newly-issued
-postdated ticket extend beyond the renew-till time of the ticket-granting
-ticket.
-
-If the ENC-TKT-IN-SKEY option has been specified and an additional ticket
-has been included in the request, the KDC will decrypt the additional ticket
-using the key for the server to which the additional ticket was issued and
-verify that it is a ticket-granting ticket. If the name of the requested
-server is missing from the request, the name of the client in the additional
-ticket will be used. Otherwise the name of the requested server will be
-compared to the name of the client in the additional ticket and if
-different, the request will be rejected. If the request succeeds, the
-session key from the additional ticket will be used to encrypt the new
-ticket that is issued instead of using the key of the server for which the
-new ticket will be used[17].
-
-If the name of the server in the ticket that is presented to the KDC as part
-of the authentication header is not that of the ticket-granting server
-itself, the server is registered in the realm of the KDC, and the RENEW
-option is requested, then the KDC will verify that the RENEWABLE flag is set
-in the ticket, that the INVALID flag is not set in the ticket, and that the
-renew_till time is still in the future. If the VALIDATE option is rqeuested,
-the KDC will check that the starttime has passed and the INVALID flag is
-set. If the PROXY option is requested, then the KDC will check that the
-PROXIABLE flag is set in the ticket. If the tests succeed, and the ticket
-passes the hotlist check described in the next paragraph, the KDC will issue
-the appropriate new ticket.
-
-3.3.3.1. Checking for revoked tickets
-
-Whenever a request is made to the ticket-granting server, the presented
-ticket(s) is(are) checked against a hot-list of tickets which have been
-canceled. This hot-list might be implemented by storing a range of issue
-timestamps for 'suspect tickets'; if a presented ticket had an authtime in
-that range, it would be rejected. In this way, a stolen ticket-granting
-ticket or renewable ticket cannot be used to gain additional tickets
-(renewals or otherwise) once the theft has been reported. Any normal ticket
-obtained before it was reported stolen will still be valid (because they
-require no interaction with the KDC), but only until their normal expiration
-time.
-
-The ciphertext part of the response in the KRB_TGS_REP message is encrypted
-in the sub-session key from the Authenticator, if present, or the session
-key key from the ticket-granting ticket. It is not encrypted using the
-client's secret key. Furthermore, the client's key's expiration date and the
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-key version number fields are left out since these values are stored along
-with the client's database record, and that record is not needed to satisfy
-a request based on a ticket-granting ticket. See section A.6 for pseudocode.
-
-3.3.3.2. Encoding the transited field
-
-If the identity of the server in the TGT that is presented to the KDC as
-part of the authentication header is that of the ticket-granting service,
-but the TGT was issued from another realm, the KDC will look up the
-inter-realm key shared with that realm and use that key to decrypt the
-ticket. If the ticket is valid, then the KDC will honor the request, subject
-to the constraints outlined above in the section describing the AS exchange.
-The realm part of the client's identity will be taken from the
-ticket-granting ticket. The name of the realm that issued the
-ticket-granting ticket will be added to the transited field of the ticket to
-be issued. This is accomplished by reading the transited field from the
-ticket-granting ticket (which is treated as an unordered set of realm
-names), adding the new realm to the set, then constructing and writing out
-its encoded (shorthand) form (this may involve a rearrangement of the
-existing encoding).
-
-Note that the ticket-granting service does not add the name of its own
-realm. Instead, its responsibility is to add the name of the previous realm.
-This prevents a malicious Kerberos server from intentionally leaving out its
-own name (it could, however, omit other realms' names).
-
-The names of neither the local realm nor the principal's realm are to be
-included in the transited field. They appear elsewhere in the ticket and
-both are known to have taken part in authenticating the principal. Since the
-endpoints are not included, both local and single-hop inter-realm
-authentication result in a transited field that is empty.
-
-Because the name of each realm transited is added to this field, it might
-potentially be very long. To decrease the length of this field, its contents
-are encoded. The initially supported encoding is optimized for the normal
-case of inter-realm communication: a hierarchical arrangement of realms
-using either domain or X.500 style realm names. This encoding (called
-DOMAIN-X500-COMPRESS) is now described.
-
-Realm names in the transited field are separated by a ",". The ",", "\",
-trailing "."s, and leading spaces (" ") are special characters, and if they
-are part of a realm name, they must be quoted in the transited field by
-preced- ing them with a "\".
-
-A realm name ending with a "." is interpreted as being prepended to the
-previous realm. For example, we can encode traversal of EDU, MIT.EDU,
-ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
-
-     "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
-
-Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that they
-would not be included in this field, and we would have:
-
-     "EDU,MIT.,WASHINGTON.EDU"
-
-A realm name beginning with a "/" is interpreted as being appended to the
-previous realm[18]. If it is to stand by itself, then it should be preceded
-by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO,
-/COM/HP, /COM, and /COM/DEC as:
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-
-     "/COM,/HP,/APOLLO, /COM/DEC".
-
-Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they
-they would not be included in this field, and we would have:
-
-     "/COM,/HP"
-
-A null subfield preceding or following a "," indicates that all realms
-between the previous realm and the next realm have been traversed[19]. Thus,
-"," means that all realms along the path between the client and the server
-have been traversed. ",EDU, /COM," means that that all realms from the
-client's realm up to EDU (in a domain style hierarchy) have been traversed,
-and that everything from /COM down to the server's realm in an X.500 style
-has also been traversed. This could occur if the EDU realm in one hierarchy
-shares an inter-realm key directly with the /COM realm in another hierarchy.
-
-3.3.4. Receipt of KRB_TGS_REP message
-
-When the KRB_TGS_REP is received by the client, it is processed in the same
-manner as the KRB_AS_REP processing described above. The primary difference
-is that the ciphertext part of the response must be decrypted using the
-session key from the ticket-granting ticket rather than the client's secret
-key. See section A.7 for pseudocode.
-
-3.4. The KRB_SAFE Exchange
-
-The KRB_SAFE message may be used by clients requiring the ability to detect
-modifications of messages they exchange. It achieves this by including a
-keyed collision-proof checksum of the user data and some control
-information. The checksum is keyed with an encryption key (usually the last
-key negotiated via subkeys, or the session key if no negotiation has
-occured).
-
-3.4.1. Generation of a KRB_SAFE message
-
-When an application wishes to send a KRB_SAFE message, it collects its data
-and the appropriate control information and computes a checksum over them.
-The checksum algorithm should be a keyed one-way hash function (such as the
-RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES MAC),
-generated using the sub-session key if present, or the session key.
-Different algorithms may be selected by changing the checksum type in the
-message. Unkeyed or non-collision-proof checksums are not suitable for this
-use.
-
-The control information for the KRB_SAFE message includes both a timestamp
-and a sequence number. The designer of an application using the KRB_SAFE
-message must choose at least one of the two mechanisms. This choice should
-be based on the needs of the application protocol.
-
-Sequence numbers are useful when all messages sent will be received by one's
-peer. Connection state is presently required to maintain the session key, so
-maintaining the next sequence number should not present an additional
-problem.
-
-If the application protocol is expected to tolerate lost messages without
-them being resent, the use of the timestamp is the appropriate replay
-detection mechanism. Using timestamps is also the appropriate mechanism for
-multi-cast protocols where all of one's peers share a common sub-session
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-key, but some messages will be sent to a subset of one's peers.
-
-After computing the checksum, the client then transmits the information and
-checksum to the recipient in the message format specified in section 5.6.1.
-
-3.4.2. Receipt of KRB_SAFE message
-
-When an application receives a KRB_SAFE message, it verifies it as follows.
-If any error occurs, an error code is reported for use by the application.
-
-The message is first checked by verifying that the protocol version and type
-fields match the current version and KRB_SAFE, respectively. A mismatch
-generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
-application verifies that the checksum used is a collision-proof keyed
-checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If
-the sender's address was included in the control information, the recipient
-verifies that the operating system's report of the sender's address matches
-the sender's address in the message, and (if a recipient address is
-specified or the recipient requires an address) that one of the recipient's
-addresses appears as the recipient's address in the message. A failed match
-for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and
-usec and/or the sequence number fields are checked. If timestamp and usec
-are expected and not present, or they are present but not current, the
-KRB_AP_ERR_SKEW error is generated. If the server name, along with the
-client name, time and microsecond fields from the Authenticator match any
-recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT
-error is generated. If an incorrect sequence number is included, or a
-sequence number is expected but not present, the KRB_AP_ERR_BADORDER error
-is generated. If neither a time-stamp and usec or a sequence number is
-present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is
-computed over the data and control information, and if it doesn't match the
-received checksum, a KRB_AP_ERR_MODIFIED error is generated.
-
-If all the checks succeed, the application is assured that the message was
-generated by its peer and was not modi- fied in transit.
-
-3.5. The KRB_PRIV Exchange
-
-The KRB_PRIV message may be used by clients requiring confidentiality and
-the ability to detect modifications of exchanged messages. It achieves this
-by encrypting the messages and adding control information.
-
-3.5.1. Generation of a KRB_PRIV message
-
-When an application wishes to send a KRB_PRIV message, it collects its data
-and the appropriate control information (specified in section 5.7.1) and
-encrypts them under an encryption key (usually the last key negotiated via
-subkeys, or the session key if no negotiation has occured). As part of the
-control information, the client must choose to use either a timestamp or a
-sequence number (or both); see the discussion in section 3.4.1 for
-guidelines on which to use. After the user data and control information are
-encrypted, the client transmits the ciphertext and some 'envelope'
-information to the recipient.
-
-3.5.2. Receipt of KRB_PRIV message
-
-When an application receives a KRB_PRIV message, it verifies it as follows.
-If any error occurs, an error code is reported for use by the application.
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-The message is first checked by verifying that the protocol version and type
-fields match the current version and KRB_PRIV, respectively. A mismatch
-generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The
-application then decrypts the ciphertext and processes the resultant
-plaintext. If decryption shows the data to have been modified, a
-KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was
-included in the control information, the recipient verifies that the
-operating system's report of the sender's address matches the sender's
-address in the message, and (if a recipient address is specified or the
-recipient requires an address) that one of the recipient's addresses appears
-as the recipient's address in the message. A failed match for either case
-generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the
-sequence number fields are checked. If timestamp and usec are expected and
-not present, or they are present but not current, the KRB_AP_ERR_SKEW error
-is generated. If the server name, along with the client name, time and
-microsecond fields from the Authenticator match any recently-seen such
-tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence
-number is included, or a sequence number is expected but not present, the
-KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec or
-a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated.
-
-If all the checks succeed, the application can assume the message was
-generated by its peer, and was securely transmitted (without intruders able
-to see the unencrypted contents).
-
-3.6. The KRB_CRED Exchange
-
-The KRB_CRED message may be used by clients requiring the ability to send
-Kerberos credentials from one host to another. It achieves this by sending
-the tickets together with encrypted data containing the session keys and
-other information associated with the tickets.
-
-3.6.1. Generation of a KRB_CRED message
-
-When an application wishes to send a KRB_CRED message it first (using the
-KRB_TGS exchange) obtains credentials to be sent to the remote host. It then
-constructs a KRB_CRED message using the ticket or tickets so obtained,
-placing the session key needed to use each ticket in the key field of the
-corresponding KrbCredInfo sequence of the encrypted part of the the KRB_CRED
-message.
-
-Other information associated with each ticket and obtained during the
-KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in
-the encrypted part of the KRB_CRED message. The current time and, if
-specifically required by the application the nonce, s-address, and r-address
-fields, are placed in the encrypted part of the KRB_CRED message which is
-then encrypted under an encryption key previosuly exchanged in the KRB_AP
-exchange (usually the last key negotiated via subkeys, or the session key if
-no negotiation has occured).
-
-3.6.2. Receipt of KRB_CRED message
-
-When an application receives a KRB_CRED message, it verifies it. If any
-error occurs, an error code is reported for use by the application. The
-message is verified by checking that the protocol version and type fields
-match the current version and KRB_CRED, respectively. A mismatch generates a
-KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then
-decrypts the ciphertext and processes the resultant plaintext. If decryption
-shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-generated.
-
-If present or required, the recipient verifies that the operating system's
-report of the sender's address matches the sender's address in the message,
-and that one of the recipient's addresses appears as the recipient's address
-in the message. A failed match for either case generates a
-KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce field
-if required) are checked next. If the timestamp and usec are not present, or
-they are present but not current, the KRB_AP_ERR_SKEW error is generated.
-
-If all the checks succeed, the application stores each of the new tickets in
-its ticket cache together with the session key and other information in the
-corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED
-message.
-
-4. The Kerberos Database
-
-The Kerberos server must have access to a database containing the principal
-identifiers and secret keys of principals to be authenticated[21].
-
-4.1. Database contents
-
-A database entry should contain at least the following fields:
-
-Field                Value
-
-name                 Principal's identifier
-key                  Principal's secret key
-p_kvno               Principal's key version
-max_life             Maximum lifetime for Tickets
-max_renewable_life   Maximum total lifetime for renewable Tickets
-
-The name field is an encoding of the principal's identifier. The key field
-contains an encryption key. This key is the principal's secret key. (The key
-can be encrypted before storage under a Kerberos "master key" to protect it
-in case the database is compromised but the master key is not. In that case,
-an extra field must be added to indicate the master key version used, see
-below.) The p_kvno field is the key version number of the principal's secret
-key. The max_life field contains the maximum allowable lifetime (endtime -
-starttime) for any Ticket issued for this principal. The max_renewable_life
-field contains the maximum allowable total lifetime for any renewable Ticket
-issued for this principal. (See section 3.1 for a description of how these
-lifetimes are used in determining the lifetime of a given Ticket.)
-
-A server may provide KDC service to several realms, as long as the database
-representation provides a mechanism to distinguish between principal records
-with identifiers which differ only in the realm name.
-
-When an application server's key changes, if the change is routine (i.e. not
-the result of disclosure of the old key), the old key should be retained by
-the server until all tickets that had been issued using that key have
-expired. Because of this, it is possible for several keys to be active for a
-single principal. Ciphertext encrypted in a principal's key is always tagged
-with the version of the key that was used for encryption, to help the
-recipient find the proper key for decryption.
-
-When more than one key is active for a particular principal, the principal
-will have more than one record in the Kerberos database. The keys and key
-version numbers will differ between the records (the rest of the fields may
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-or may not be the same). Whenever Kerberos issues a ticket, or responds to a
-request for initial authentication, the most recent key (known by the
-Kerberos server) will be used for encryption. This is the key with the
-highest key version number.
-
-4.2. Additional fields
-
-Project Athena's KDC implementation uses additional fields in its database:
-
-Field        Value
-
-K_kvno       Kerberos' key version
-expiration   Expiration date for entry
-attributes   Bit field of attributes
-mod_date     Timestamp of last modification
-mod_name     Modifying principal's identifier
-
-The K_kvno field indicates the key version of the Kerberos master key under
-which the principal's secret key is encrypted.
-
-After an entry's expiration date has passed, the KDC will return an error to
-any client attempting to gain tickets as or for the principal. (A database
-may want to maintain two expiration dates: one for the principal, and one
-for the principal's current key. This allows password aging to work
-independently of the principal's expiration date. However, due to the
-limited space in the responses, the KDC must combine the key expiration and
-principal expiration date into a single value called 'key_exp', which is
-used as a hint to the user to take administrative action.)
-
-The attributes field is a bitfield used to govern the operations involving
-the principal. This field might be useful in conjunction with user
-registration procedures, for site-specific policy implementations (Project
-Athena currently uses it for their user registration process controlled by
-the system-wide database service, Moira [LGDSR87]), to identify whether a
-principal can play the role of a client or server or both, to note whether a
-server is appropriate trusted to recieve credentials delegated by a client,
-or to identify the 'string to key' conversion algorithm used for a
-principal's key[22]. Other bits are used to indicate that certain ticket
-options should not be allowed in tickets encrypted under a principal's key
-(one bit each): Disallow issuing postdated tickets, disallow issuing
-forwardable tickets, disallow issuing tickets based on TGT authentication,
-disallow issuing renewable tickets, disallow issuing proxiable tickets, and
-disallow issuing tickets for which the principal is the server.
-
-The mod_date field contains the time of last modification of the entry, and
-the mod_name field contains the name of the principal which last modified
-the entry.
-
-4.3. Frequently Changing Fields
-
-Some KDC implementations may wish to maintain the last time that a request
-was made by a particular principal. Information that might be maintained
-includes the time of the last request, the time of the last request for a
-ticket-granting ticket, the time of the last use of a ticket-granting
-ticket, or other times. This information can then be returned to the user in
-the last-req field (see section 5.2).
-
-Other frequently changing information that can be maintained is the latest
-expiration time for any tickets that have been issued using each key. This
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-field would be used to indicate how long old keys must remain valid to allow
-the continued use of outstanding tickets.
-
-4.4. Site Constants
-
-The KDC implementation should have the following configurable constants or
-options, to allow an administrator to make and enforce policy decisions:
-
-   * The minimum supported lifetime (used to determine whether the
-     KDC_ERR_NEVER_VALID error should be returned). This constant should
-     reflect reasonable expectations of round-trip time to the KDC,
-     encryption/decryption time, and processing time by the client and
-     target server, and it should allow for a minimum 'useful' lifetime.
-   * The maximum allowable total (renewable) lifetime of a ticket
-     (renew_till - starttime).
-   * The maximum allowable lifetime of a ticket (endtime - starttime).
-   * Whether to allow the issue of tickets with empty address fields
-     (including the ability to specify that such tickets may only be issued
-     if the request specifies some authorization_data).
-   * Whether proxiable, forwardable, renewable or post-datable tickets are
-     to be issued.
-
-5. Message Specifications
-
-The following sections describe the exact contents and encoding of protocol
-messages and objects. The ASN.1 base definitions are presented in the first
-subsection. The remaining subsections specify the protocol objects (tickets
-and authenticators) and messages. Specification of encryption and checksum
-techniques, and the fields related to them, appear in section 6.
-
-Optional field in ASN.1 sequences
-
-For optional integer value and date fields in ASN.1 sequences where a
-default value has been specified, certain default values will not be allowed
-in the encoding because these values will always be represented through
-defaulting by the absence of the optional field. For example, one will not
-send a microsecond zero value because one must make sure that there is only
-one way to encode this value.
-
-Additional fields in ASN.1 sequences
-
-Implementations receiving Kerberos messages with additional fields present
-in ASN.1 sequences should carry the those fields through, unmodified, when
-the message is forwarded. Implementations should not drop such fields if the
-sequence is reencoded.
-
-5.1. ASN.1 Distinguished Encoding Representation
-
-All uses of ASN.1 in Kerberos shall use the Distinguished Encoding
-Representation of the data elements as described in the X.509 specification,
-section 8.7 [X509-88].
-
-5.3. ASN.1 Base Definitions
-
-The following ASN.1 base definitions are used in the rest of this section.
-Note that since the underscore character (_) is not permitted in ASN.1
-names, the hyphen (-) is used in its place for the purposes of ASN.1 names.
-
-Realm ::=           GeneralString
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-PrincipalName ::=   SEQUENCE {
-                    name-type[0]     INTEGER,
-                    name-string[1]   SEQUENCE OF GeneralString
-}
-
-Kerberos realms are encoded as GeneralStrings. Realms shall not contain a
-character with the code 0 (the ASCII NUL). Most realms will usually consist
-of several components separated by periods (.), in the style of Internet
-Domain Names, or separated by slashes (/) in the style of X.500 names.
-Acceptable forms for realm names are specified in section 7. A PrincipalName
-is a typed sequence of components consisting of the following sub-fields:
-
-name-type
-     This field specifies the type of name that follows. Pre-defined values
-     for this field are specified in section 7.2. The name-type should be
-     treated as a hint. Ignoring the name type, no two names can be the same
-     (i.e. at least one of the components, or the realm, must be different).
-     This constraint may be eliminated in the future.
-name-string
-     This field encodes a sequence of components that form a name, each
-     component encoded as a GeneralString. Taken together, a PrincipalName
-     and a Realm form a principal identifier. Most PrincipalNames will have
-     only a few components (typically one or two).
-
-KerberosTime ::=   GeneralizedTime
-                   -- Specifying UTC time zone (Z)
-
-The timestamps used in Kerberos are encoded as GeneralizedTimes. An encoding
-shall specify the UTC time zone (Z) and shall not include any fractional
-portions of the seconds. It further shall not include any separators.
-Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 pm
-on 6 November 1985 is 19851106210627Z.
-
-HostAddress ::=     SEQUENCE  {
-                    addr-type[0]             INTEGER,
-                    address[1]               OCTET STRING
-}
-
-HostAddresses ::=   SEQUENCE OF HostAddress
-
-The host adddress encodings consists of two fields:
-
-addr-type
-     This field specifies the type of address that follows. Pre-defined
-     values for this field are specified in section 8.1.
-address
-     This field encodes a single address of type addr-type.
-
-The two forms differ slightly. HostAddress contains exactly one address;
-HostAddresses contains a sequence of possibly many addresses.
-
-AuthorizationData ::=   SEQUENCE OF SEQUENCE {
-                        ad-type[0]               INTEGER,
-                        ad-data[1]               OCTET STRING
-}
-
-ad-data
-     This field contains authorization data to be interpreted according to
-     the value of the corresponding ad-type field.
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-ad-type
-     This field specifies the format for the ad-data subfield. All negative
-     values are reserved for local use. Non-negative values are reserved for
-     registered use.
-
-Each sequence of type and data is refered to as an authorization element.
-Elements may be application specific, however, there is a common set of
-recursive elements that should be understood by all implementations. These
-elements contain other elements embedded within them, and the interpretation
-of the encapsulating element determines which of the embedded elements must
-be interpreted, and which may be ignored. Definitions for these common
-elements may be found in Appendix B.
-
-TicketExtensions ::= SEQUENCE OF SEQUENCE {
-           te-type[0]       INTEGER,
-           te-data[1]       OCTET STRING
-}
-
-
-
-te-data
-     This field contains opaque data that must be caried with the ticket to
-     support extensions to the Kerberos protocol including but not limited
-     to some forms of inter-realm key exchange and plaintext authorization
-     data. See appendix C for some common uses of this field.
-te-type
-     This field specifies the format for the te-data subfield. All negative
-     values are reserved for local use. Non-negative values are reserved for
-     registered use.
-
-APOptions ::=   BIT STRING
-                  -- reserved(0),
-                  -- use-session-key(1),
-                  -- mutual-required(2)
-
-TicketFlags ::= BIT STRING
-                  -- reserved(0),
-                  -- forwardable(1),
-                  -- forwarded(2),
-                  -- proxiable(3),
-                  -- proxy(4),
-                  -- may-postdate(5),
-                  -- postdated(6),
-                  -- invalid(7),
-                  -- renewable(8),
-                  -- initial(9),
-                  -- pre-authent(10),
-                  -- hw-authent(11),
-                  -- transited-policy-checked(12),
-                  -- ok-as-delegate(13)
-
-KDCOptions ::=   BIT STRING
-                  -- reserved(0),
-                  -- forwardable(1),
-                  -- forwarded(2),
-                  -- proxiable(3),
-                  -- proxy(4),
-                  -- allow-postdate(5),
-                  -- postdated(6),
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                  -- unused7(7),
-                  -- renewable(8),
-                  -- unused9(9),
-                  -- unused10(10),
-                  -- unused11(11),
-                  -- unused12(12),
-                  -- unused13(13),
-                  -- disable-transited-check(26),
-                  -- renewable-ok(27),
-                  -- enc-tkt-in-skey(28),
-                  -- renew(30),
-                  -- validate(31)
-
-ASN.1 Bit strings have a length and a value. When used in Kerberos for the
-APOptions, TicketFlags, and KDCOptions, the length of the bit string on
-generated values should be the smallest number of bits needed to include the
-highest order bit that is set (1), but in no case less than 32 bits. The
-ASN.1 representation of the bit strings uses unnamed bits, with the meaning
-of the individual bits defined by the comments in the specification above.
-Implementations should accept values of bit strings of any length and treat
-the value of flags corresponding to bits beyond the end of the bit string as
-if the bit were reset (0). Comparison of bit strings of different length
-should treat the smaller string as if it were padded with zeros beyond the
-high order bits to the length of the longer string[23].
-
-LastReq ::=   SEQUENCE OF SEQUENCE {
-               lr-type[0]               INTEGER,
-               lr-value[1]              KerberosTime
-}
-
-lr-type
-     This field indicates how the following lr-value field is to be
-     interpreted. Negative values indicate that the information pertains
-     only to the responding server. Non-negative values pertain to all
-     servers for the realm. If the lr-type field is zero (0), then no
-     information is conveyed by the lr-value subfield. If the absolute value
-     of the lr-type field is one (1), then the lr-value subfield is the time
-     of last initial request for a TGT. If it is two (2), then the lr-value
-     subfield is the time of last initial request. If it is three (3), then
-     the lr-value subfield is the time of issue for the newest
-     ticket-granting ticket used. If it is four (4), then the lr-value
-     subfield is the time of the last renewal. If it is five (5), then the
-     lr-value subfield is the time of last request (of any type). If it is
-     (6), then the lr-value subfield is the time when the password will
-     expire.
-lr-value
-     This field contains the time of the last request. the time must be
-     interpreted according to the contents of the accompanying lr-type
-     subfield.
-
-See section 6 for the definitions of Checksum, ChecksumType, EncryptedData,
-EncryptionKey, EncryptionType, and KeyType.
-
-5.3. Tickets and Authenticators
-
-This section describes the format and encryption parameters for tickets and
-authenticators. When a ticket or authenticator is included in a protocol
-message it is treated as an opaque object.
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-5.3.1. Tickets
-
-A ticket is a record that helps a client authenticate to a service. A Ticket
-contains the following information:
-
-Ticket ::=        [APPLICATION 1] SEQUENCE {
-                  tkt-vno[0]                   INTEGER,
-                  realm[1]                     Realm,
-                  sname[2]                     PrincipalName,
-                  enc-part[3]                  EncryptedData,
-                  extensions[4]                TicketExtensions OPTIONAL
-}
-
--- Encrypted part of ticket
-EncTicketPart ::= [APPLICATION 3] SEQUENCE {
-                  flags[0]                     TicketFlags,
-                  key[1]                       EncryptionKey,
-                  crealm[2]                    Realm,
-                  cname[3]                     PrincipalName,
-                  transited[4]                 TransitedEncoding,
-                  authtime[5]                  KerberosTime,
-                  starttime[6]                 KerberosTime OPTIONAL,
-                  endtime[7]                   KerberosTime,
-                  renew-till[8]                KerberosTime OPTIONAL,
-                  caddr[9]                     HostAddresses OPTIONAL,
-                  authorization-data[10]       AuthorizationData OPTIONAL
-}
--- encoded Transited field
-TransitedEncoding ::=   SEQUENCE {
-                        tr-type[0]             INTEGER, -- must be registered
-                        contents[1]            OCTET STRING
-}
-
-The encoding of EncTicketPart is encrypted in the key shared by Kerberos and
-the end server (the server's secret key). See section 6 for the format of
-the ciphertext.
-
-tkt-vno
-     This field specifies the version number for the ticket format. This
-     document describes version number 5.
-realm
-     This field specifies the realm that issued a ticket. It also serves to
-     identify the realm part of the server's principal identifier. Since a
-     Kerberos server can only issue tickets for servers within its realm,
-     the two will always be identical.
-sname
-     This field specifies all components of the name part of the server's
-     identity, including those parts that identify a specific instance of a
-     service.
-enc-part
-     This field holds the encrypted encoding of the EncTicketPart sequence.
-extensions
-     This optional field contains a sequence of extentions that may be used
-     to carry information that must be carried with the ticket to support
-     several extensions, including but not limited to plaintext
-     authorization data, tokens for exchanging inter-realm keys, and other
-     information that must be associated with a ticket for use by the
-     application server. See Appendix C for definitions of some common
-     extensions.
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-
-     Note that some older versions of Kerberos did not support this field.
-     Because this is an optional field it will not break older clients, but
-     older clients might strip this field from the ticket before sending it
-     to the application server. This limits the usefulness of this ticket
-     field to environments where the ticket will not be parsed and
-     reconstructed by these older Kerberos clients.
-
-     If it is known that the client will strip this field from the ticket,
-     as an interim measure the KDC may append this field to the end of the
-     enc-part of the ticket and append a traler indicating the lenght of the
-     appended extensions field. (this paragraph is open for discussion,
-     including the form of the traler).
-flags
-     This field indicates which of various options were used or requested
-     when the ticket was issued. It is a bit-field, where the selected
-     options are indicated by the bit being set (1), and the unselected
-     options and reserved fields being reset (0). Bit 0 is the most
-     significant bit. The encoding of the bits is specified in section 5.2.
-     The flags are described in more detail above in section 2. The meanings
-     of the flags are:
-
-          Bit(s)      Name         Description
-
-          0           RESERVED
-                                   Reserved for future  expansion  of  this
-                                   field.
-
-          1           FORWARDABLE
-                                   The FORWARDABLE flag  is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.  When set,  this
-                                   flag  tells  the  ticket-granting server
-                                   that it is OK to  issue  a  new  ticket-
-                                   granting ticket with a different network
-                                   address based on the presented ticket.
-
-          2           FORWARDED
-                                   When set, this flag indicates  that  the
-                                   ticket  has either been forwarded or was
-                                   issued based on authentication involving
-                                   a forwarded ticket-granting ticket.
-
-          3           PROXIABLE
-                                   The  PROXIABLE  flag  is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.   The  PROXIABLE
-                                   flag  has an interpretation identical to
-                                   that of  the  FORWARDABLE  flag,  except
-                                   that   the   PROXIABLE  flag  tells  the
-                                   ticket-granting server  that  only  non-
-                                   ticket-granting  tickets  may  be issued
-                                   with different network addresses.
-
-          4           PROXY
-                                   When set, this  flag  indicates  that  a
-                                   ticket is a proxy.
-
-          5           MAY-POSTDATE
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                                   The MAY-POSTDATE flag is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.  This flag tells
-                                   the  ticket-granting server that a post-
-                                   dated ticket may be issued based on this
-                                   ticket-granting ticket.
-
-          6           POSTDATED
-                                   This flag indicates that this ticket has
-                                   been  postdated.   The  end-service  can
-                                   check the authtime field to see when the
-                                   original authentication occurred.
-
-          7           INVALID
-                                   This flag indicates  that  a  ticket  is
-                                   invalid, and it must be validated by the
-                                   KDC  before  use.   Application  servers
-                                   must reject tickets which have this flag
-                                   set.
-
-          8           RENEWABLE
-                                   The  RENEWABLE  flag  is  normally  only
-                                   interpreted  by the TGS, and can usually
-                                   be ignored by end servers (some particu-
-                                   larly careful servers may wish to disal-
-                                   low  renewable  tickets).   A  renewable
-                                   ticket  can be used to obtain a replace-
-                                   ment ticket  that  expires  at  a  later
-                                   date.
-
-          9           INITIAL
-                                   This flag indicates that this ticket was
-                                   issued  using  the  AS protocol, and not
-                                   issued  based   on   a   ticket-granting
-                                   ticket.
-
-          10          PRE-AUTHENT
-                                   This flag indicates that during  initial
-                                   authentication, the client was authenti-
-                                   cated by the KDC  before  a  ticket  was
-                                   issued.    The   strength  of  the  pre-
-                                   authentication method is not  indicated,
-                                   but is acceptable to the KDC.
-
-          11          HW-AUTHENT
-                                   This flag indicates  that  the  protocol
-                                   employed   for   initial  authentication
-                                   required the use of hardware expected to
-                                   be possessed solely by the named client.
-                                   The hardware  authentication  method  is
-                                   selected  by the KDC and the strength of
-                                   the method is not indicated.
-
-          12           TRANSITED   This flag indicates that the KDC for the
-                  POLICY-CHECKED   realm has checked the transited field
-                                   against a realm defined policy for
-                                   trusted certifiers.  If this flag is
-                                   reset (0), then the application server
-                                   must check the transited field itself,
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                                   and if unable to do so it must reject
-                                   the authentication.  If the flag is set
-                                   (1) then the application server may skip
-                                   its own validation of the transited
-                                   field, relying on the validation
-                                   performed by the KDC.  At its option the
-                                   application server may still apply its
-                                   own validation based on a separate
-                                   policy for acceptance.
-
-          13      OK-AS-DELEGATE   This flag indicates that the server (not
-                                   the client) specified in the ticket has
-                                   been determined by policy of the realm
-                                   to be a suitable recipient of
-                                   delegation.  A client can use the
-                                   presence of this flag to help it make a
-                                   decision whether to delegate credentials
-                                   (either grant a proxy or a forwarded
-                                   ticket granting ticket) to this server.
-                                   The client is free to ignore the value
-                                   of this flag.  When setting this flag,
-                                   an administrator should consider the
-                                   Security and placement of the server on
-                                   which the service will run, as well as
-                                   whether the service requires the use of
-                                   delegated credentials.
-
-          14          ANONYMOUS
-                                   This flag indicates that  the  principal
-                                   named in the ticket is a generic princi-
-                                   pal for the realm and does not  identify
-                                   the  individual  using  the ticket.  The
-                                   purpose  of  the  ticket  is   only   to
-                                   securely  distribute  a session key, and
-                                   not to identify  the  user.   Subsequent
-                                   requests  using the same ticket and ses-
-                                   sion may be  considered  as  originating
-                                   from  the  same  user, but requests with
-                                   the same username but a different ticket
-                                   are  likely  to originate from different
-                                   users.
-
-          15-31       RESERVED
-                                   Reserved for future use.
-
-key
-     This field exists in the ticket and the KDC response and is used to
-     pass the session key from Kerberos to the application server and the
-     client. The field's encoding is described in section 6.2.
-crealm
-     This field contains the name of the realm in which the client is
-     registered and in which initial authentication took place.
-cname
-     This field contains the name part of the client's principal identifier.
-transited
-     This field lists the names of the Kerberos realms that took part in
-     authenticating the user to whom this ticket was issued. It does not
-     specify the order in which the realms were transited. See section
-     3.3.3.2 for details on how this field encodes the traversed realms.
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     When the names of CA's are to be embedded inthe transited field (as
-     specified for some extentions to the protocol), the X.500 names of the
-     CA's should be mapped into items in the transited field using the
-     mapping defined by RFC2253.
-authtime
-     This field indicates the time of initial authentication for the named
-     principal. It is the time of issue for the original ticket on which
-     this ticket is based. It is included in the ticket to provide
-     additional information to the end service, and to provide the necessary
-     information for implementation of a `hot list' service at the KDC. An
-     end service that is particularly paranoid could refuse to accept
-     tickets for which the initial authentication occurred "too far" in the
-     past. This field is also returned as part of the response from the KDC.
-     When returned as part of the response to initial authentication
-     (KRB_AS_REP), this is the current time on the Kerberos server[24].
-starttime
-     This field in the ticket specifies the time after which the ticket is
-     valid. Together with endtime, this field specifies the life of the
-     ticket. If it is absent from the ticket, its value should be treated as
-     that of the authtime field.
-endtime
-     This field contains the time after which the ticket will not be honored
-     (its expiration time). Note that individual services may place their
-     own limits on the life of a ticket and may reject tickets which have
-     not yet expired. As such, this is really an upper bound on the
-     expiration time for the ticket.
-renew-till
-     This field is only present in tickets that have the RENEWABLE flag set
-     in the flags field. It indicates the maximum endtime that may be
-     included in a renewal. It can be thought of as the absolute expiration
-     time for the ticket, including all renewals.
-caddr
-     This field in a ticket contains zero (if omitted) or more (if present)
-     host addresses. These are the addresses from which the ticket can be
-     used. If there are no addresses, the ticket can be used from any
-     location. The decision by the KDC to issue or by the end server to
-     accept zero-address tickets is a policy decision and is left to the
-     Kerberos and end-service administrators; they may refuse to issue or
-     accept such tickets. The suggested and default policy, however, is that
-     such tickets will only be issued or accepted when additional
-     information that can be used to restrict the use of the ticket is
-     included in the authorization_data field. Such a ticket is a
-     capability.
-
-     Network addresses are included in the ticket to make it harder for an
-     attacker to use stolen credentials. Because the session key is not sent
-     over the network in cleartext, credentials can't be stolen simply by
-     listening to the network; an attacker has to gain access to the session
-     key (perhaps through operating system security breaches or a careless
-     user's unattended session) to make use of stolen tickets.
-
-     It is important to note that the network address from which a
-     connection is received cannot be reliably determined. Even if it could
-     be, an attacker who has compromised the client's workstation could use
-     the credentials from there. Including the network addresses only makes
-     it more difficult, not impossible, for an attacker to walk off with
-     stolen credentials and then use them from a "safe" location.
-authorization-data
-     The authorization-data field is used to pass authorization data from
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     the principal on whose behalf a ticket was issued to the application
-     service. If no authorization data is included, this field will be left
-     out. Experience has shown that the name of this field is confusing, and
-     that a better name for this field would be restrictions. Unfortunately,
-     it is not possible to change the name of this field at this time.
-
-     This field contains restrictions on any authority obtained on the basis
-     of authentication using the ticket. It is possible for any principal in
-     posession of credentials to add entries to the authorization data field
-     since these entries further restrict what can be done with the ticket.
-     Such additions can be made by specifying the additional entries when a
-     new ticket is obtained during the TGS exchange, or they may be added
-     during chained delegation using the authorization data field of the
-     authenticator.
-
-     Because entries may be added to this field by the holder of
-     credentials, except when an entry is separately authenticated by
-     encapulation in the kdc-issued element, it is not allowable for the
-     presence of an entry in the authorization data field of a ticket to
-     amplify the priveleges one would obtain from using a ticket.
-
-     The data in this field may be specific to the end service; the field
-     will contain the names of service specific objects, and the rights to
-     those objects. The format for this field is described in section 5.2.
-     Although Kerberos is not concerned with the format of the contents of
-     the sub-fields, it does carry type information (ad-type).
-
-     By using the authorization_data field, a principal is able to issue a
-     proxy that is valid for a specific purpose. For example, a client
-     wishing to print a file can obtain a file server proxy to be passed to
-     the print server. By specifying the name of the file in the
-     authorization_data field, the file server knows that the print server
-     can only use the client's rights when accessing the particular file to
-     be printed.
-
-     A separate service providing authorization or certifying group
-     membership may be built using the authorization-data field. In this
-     case, the entity granting authorization (not the authorized entity),
-     may obtain a ticket in its own name (e.g. the ticket is issued in the
-     name of a privelege server), and this entity adds restrictions on its
-     own authority and delegates the restricted authority through a proxy to
-     the client. The client would then present this authorization credential
-     to the application server separately from the authentication exchange.
-     Alternatively, such authorization credentials may be embedded in the
-     ticket authenticating the authorized entity, when the authorization is
-     separately authenticated using the kdc-issued authorization data
-     element (see B.4).
-
-     Similarly, if one specifies the authorization-data field of a proxy and
-     leaves the host addresses blank, the resulting ticket and session key
-     can be treated as a capability. See [Neu93] for some suggested uses of
-     this field.
-
-     The authorization-data field is optional and does not have to be
-     included in a ticket.
-
-5.3.2. Authenticators
-
-An authenticator is a record sent with a ticket to a server to certify the
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-client's knowledge of the encryption key in the ticket, to help the server
-detect replays, and to help choose a "true session key" to use with the
-particular session. The encoding is encrypted in the ticket's session key
-shared by the client and the server:
-
--- Unencrypted authenticator
-Authenticator ::= [APPLICATION 2] SEQUENCE  {
-                  authenticator-vno[0]          INTEGER,
-                  crealm[1]                     Realm,
-                  cname[2]                      PrincipalName,
-                  cksum[3]                      Checksum OPTIONAL,
-                  cusec[4]                      INTEGER,
-                  ctime[5]                      KerberosTime,
-                  subkey[6]                     EncryptionKey OPTIONAL,
-                  seq-number[7]                 INTEGER OPTIONAL,
-                  authorization-data[8]         AuthorizationData OPTIONAL
-}
-
-
-authenticator-vno
-     This field specifies the version number for the format of the
-     authenticator. This document specifies version 5.
-crealm and cname
-     These fields are the same as those described for the ticket in section
-     5.3.1.
-cksum
-     This field contains a checksum of the the applica- tion data that
-     accompanies the KRB_AP_REQ.
-cusec
-     This field contains the microsecond part of the client's timestamp. Its
-     value (before encryption) ranges from 0 to 999999. It often appears
-     along with ctime. The two fields are used together to specify a
-     reasonably accurate timestamp.
-ctime
-     This field contains the current time on the client's host.
-subkey
-     This field contains the client's choice for an encryption key which is
-     to be used to protect this specific application session. Unless an
-     application specifies otherwise, if this field is left out the session
-     key from the ticket will be used.
-seq-number
-     This optional field includes the initial sequence number to be used by
-     the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to
-     detect replays (It may also be used by application specific messages).
-     When included in the authenticator this field specifies the initial
-     sequence number for messages from the client to the server. When
-     included in the AP-REP message, the initial sequence number is that for
-     messages from the server to the client. When used in KRB_PRIV or
-     KRB_SAFE messages, it is incremented by one after each message is sent.
-     Sequence numbers fall in the range of 0 through 2^32 - 1 and wrap to
-     zero following the value 2^32 - 1.
-
-     For sequence numbers to adequately support the detection of replays
-     they should be non-repeating, even across connection boundaries. The
-     initial sequence number should be random and uniformly distributed
-     across the full space of possible sequence numbers, so that it cannot
-     be guessed by an attacker and so that it and the successive sequence
-     numbers do not repeat other sequences.
-authorization-data
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     This field is the same as described for the ticket in section 5.3.1. It
-     is optional and will only appear when additional restrictions are to be
-     placed on the use of a ticket, beyond those carried in the ticket
-     itself.
-
-5.4. Specifications for the AS and TGS exchanges
-
-This section specifies the format of the messages used in the exchange
-between the client and the Kerberos server. The format of possible error
-messages appears in section 5.9.1.
-
-5.4.1. KRB_KDC_REQ definition
-
-The KRB_KDC_REQ message has no type of its own. Instead, its type is one of
-KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial
-ticket or an additional ticket. In either case, the message is sent from the
-client to the Authentication Server to request credentials for a service.
-
-The message fields are:
-
-AS-REQ ::=         [APPLICATION 10] KDC-REQ
-TGS-REQ ::=        [APPLICATION 12] KDC-REQ
-
-KDC-REQ ::=        SEQUENCE {
-                   pvno[1]            INTEGER,
-                   msg-type[2]        INTEGER,
-                   padata[3]          SEQUENCE OF PA-DATA OPTIONAL,
-                   req-body[4]        KDC-REQ-BODY
-}
-
-PA-DATA ::=        SEQUENCE {
-                   padata-type[1]     INTEGER,
-                   padata-value[2]    OCTET STRING,
-                                      -- might be encoded AP-REQ
-}
-
-KDC-REQ-BODY ::=   SEQUENCE {
-                    kdc-options[0]         KDCOptions,
-                    cname[1]               PrincipalName OPTIONAL,
-                                           -- Used only in AS-REQ
-                    realm[2]               Realm, -- Server's realm
-                                           -- Also client's in AS-REQ
-                    sname[3]               PrincipalName OPTIONAL,
-                    from[4]                KerberosTime OPTIONAL,
-                    till[5]                KerberosTime OPTIONAL,
-                    rtime[6]               KerberosTime OPTIONAL,
-                    nonce[7]               INTEGER,
-                    etype[8]               SEQUENCE OF INTEGER,
-                                           -- EncryptionType,
-                                           -- in preference order
-                    addresses[9]           HostAddresses OPTIONAL,
-                enc-authorization-data[10] EncryptedData OPTIONAL,
-                                           -- Encrypted AuthorizationData
-                                           -- encoding
-                    additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
-}
-
-The fields in this message are:
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-pvno
-     This field is included in each message, and specifies the protocol
-     version number. This document specifies protocol version 5.
-msg-type
-     This field indicates the type of a protocol message. It will almost
-     always be the same as the application identifier associated with a
-     message. It is included to make the identifier more readily accessible
-     to the application. For the KDC-REQ message, this type will be
-     KRB_AS_REQ or KRB_TGS_REQ.
-padata
-     The padata (pre-authentication data) field contains a sequence of
-     authentication information which may be needed before credentials can
-     be issued or decrypted. In the case of requests for additional tickets
-     (KRB_TGS_REQ), this field will include an element with padata-type of
-     PA-TGS-REQ and data of an authentication header (ticket-granting ticket
-     and authenticator). The checksum in the authenticator (which must be
-     collision-proof) is to be computed over the KDC-REQ-BODY encoding. In
-     most requests for initial authentication (KRB_AS_REQ) and most replies
-     (KDC-REP), the padata field will be left out.
-
-     This field may also contain information needed by certain extensions to
-     the Kerberos protocol. For example, it might be used to initially
-     verify the identity of a client before any response is returned. This
-     is accomplished with a padata field with padata-type equal to
-     PA-ENC-TIMESTAMP and padata-value defined as follows:
-
-     padata-type     ::= PA-ENC-TIMESTAMP
-     padata-value    ::= EncryptedData -- PA-ENC-TS-ENC
-
-     PA-ENC-TS-ENC   ::= SEQUENCE {
-                     patimestamp[0]     KerberosTime, -- client's time
-                     pausec[1]          INTEGER OPTIONAL
-     }
-
-     with patimestamp containing the client's time and pausec containing the
-     microseconds which may be omitted if a client will not generate more
-     than one request per second. The ciphertext (padata-value) consists of
-     the PA-ENC-TS-ENC sequence, encrypted using the client's secret key.
-
-     [use-specified-kvno item is here for discussion and may be removed] It
-     may also be used by the client to specify the version of a key that is
-     being used for accompanying preauthentication, and/or which should be
-     used to encrypt the reply from the KDC.
-
-     PA-USE-SPECIFIED-KVNO  ::=  Integer
-
-     The KDC should only accept and abide by the value of the
-     use-specified-kvno preauthentication data field when the specified key
-     is still valid and until use of a new key is confirmed. This situation
-     is likely to occur primarily during the period during which an updated
-     key is propagating to other KDC's in a realm.
-
-     The padata field can also contain information needed to help the KDC or
-     the client select the key needed for generating or decrypting the
-     response. This form of the padata is useful for supporting the use of
-     certain token cards with Kerberos. The details of such extensions are
-     specified in separate documents. See [Pat92] for additional uses of
-     this field.
-padata-type
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     The padata-type element of the padata field indicates the way that the
-     padata-value element is to be interpreted. Negative values of
-     padata-type are reserved for unregistered use; non-negative values are
-     used for a registered interpretation of the element type.
-req-body
-     This field is a placeholder delimiting the extent of the remaining
-     fields. If a checksum is to be calculated over the request, it is
-     calculated over an encoding of the KDC-REQ-BODY sequence which is
-     enclosed within the req-body field.
-kdc-options
-     This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the
-     KDC and indicates the flags that the client wants set on the tickets as
-     well as other information that is to modify the behavior of the KDC.
-     Where appropriate, the name of an option may be the same as the flag
-     that is set by that option. Although in most case, the bit in the
-     options field will be the same as that in the flags field, this is not
-     guaranteed, so it is not acceptable to simply copy the options field to
-     the flags field. There are various checks that must be made before
-     honoring an option anyway.
-
-     The kdc_options field is a bit-field, where the selected options are
-     indicated by the bit being set (1), and the unselected options and
-     reserved fields being reset (0). The encoding of the bits is specified
-     in section 5.2. The options are described in more detail above in
-     section 2. The meanings of the options are:
-
-        Bit(s)    Name                Description
-         0        RESERVED
-                                      Reserved for future  expansion  of  this
-                                      field.
-
-         1        FORWARDABLE
-                                      The FORWARDABLE  option  indicates  that
-                                      the  ticket  to be issued is to have its
-                                      forwardable flag set.  It  may  only  be
-                                      set on the initial request, or in a sub-
-                                      sequent request if  the  ticket-granting
-                                      ticket on which it is based is also for-
-                                      wardable.
-
-         2        FORWARDED
-                                      The FORWARDED option is  only  specified
-                                      in  a  request  to  the  ticket-granting
-                                      server and will only be honored  if  the
-                                      ticket-granting  ticket  in  the request
-                                      has  its  FORWARDABLE  bit  set.    This
-                                      option  indicates that this is a request
-                                      for forwarding.  The address(es) of  the
-                                      host  from which the resulting ticket is
-                                      to  be  valid  are   included   in   the
-                                      addresses field of the request.
-
-         3        PROXIABLE
-                                      The PROXIABLE option indicates that  the
-                                      ticket to be issued is to have its prox-
-                                      iable flag set.  It may only be  set  on
-                                      the  initial request, or in a subsequent
-                                      request if the ticket-granting ticket on
-                                      which it is based is also proxiable.
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-
-         4        PROXY
-                                      The PROXY option indicates that this  is
-                                      a request for a proxy.  This option will
-                                      only be honored if  the  ticket-granting
-                                      ticket  in the request has its PROXIABLE
-                                      bit set.  The address(es)  of  the  host
-                                      from which the resulting ticket is to be
-                                       valid  are  included  in  the  addresses
-                                      field of the request.
-
-         5        ALLOW-POSTDATE
-                                      The ALLOW-POSTDATE option indicates that
-                                      the  ticket  to be issued is to have its
-                                      MAY-POSTDATE flag set.  It may  only  be
-                                      set on the initial request, or in a sub-
-                                      sequent request if  the  ticket-granting
-                                      ticket on which it is based also has its
-                                      MAY-POSTDATE flag set.
-
-         6        POSTDATED
-                                      The POSTDATED option indicates that this
-                                      is  a  request  for  a postdated ticket.
-                                      This option will only be honored if  the
-                                      ticket-granting  ticket  on  which it is
-                                      based has  its  MAY-POSTDATE  flag  set.
-                                      The  resulting ticket will also have its
-                                      INVALID flag set, and that flag  may  be
-                                      reset by a subsequent request to the KDC
-                                      after the starttime in  the  ticket  has
-                                      been reached.
-
-         7        UNUSED
-                                      This option is presently unused.
-
-         8        RENEWABLE
-                                      The RENEWABLE option indicates that  the
-                                      ticket  to  be  issued  is  to  have its
-                                      RENEWABLE flag set.  It may only be  set
-                                      on  the  initial  request,  or  when the
-                                      ticket-granting  ticket  on  which   the
-                                      request  is based is also renewable.  If
-                                      this option is requested, then the rtime
-                                      field   in   the  request  contains  the
-                                      desired absolute expiration time for the
-                                      ticket.
-
-         9-13     UNUSED
-                                      These options are presently unused.
-
-         14       REQUEST-ANONYMOUS
-                                      The REQUEST-ANONYMOUS  option  indicates
-                                      that  the  ticket to be issued is not to
-                                      identify  the  user  to  which  it   was
-                                      issued.  Instead, the principal identif-
-                                      ier is to be generic,  as  specified  by
-                                      the  policy  of  the realm (e.g. usually
-                                      anonymous@realm).  The  purpose  of  the
-                                      ticket  is only to securely distribute a
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                                      session key, and  not  to  identify  the
-                                      user.   The ANONYMOUS flag on the ticket
-                                      to be returned should be  set.   If  the
-                                      local  realms  policy  does  not  permit
-                                      anonymous credentials, the request is to
-                                      be rejected.
-
-         15-25    RESERVED
-                                      Reserved for future use.
-
-         26       DISABLE-TRANSITED-CHECK
-                                      By default the KDC will check the
-                                      transited field of a ticket-granting-
-                                      ticket against the policy of the local
-                                      realm before it will issue derivative
-                                      tickets based on the ticket granting
-                                      ticket.  If this flag is set in the
-                                      request, checking of the transited field
-                                      is disabled.  Tickets issued without the
-                                      performance of this check will be noted
-                                      by the reset (0) value of the
-                                      TRANSITED-POLICY-CHECKED flag,
-                                      indicating to the application server
-                                      that the tranisted field must be checked
-                                      locally.  KDC's are encouraged but not
-                                      required to honor the
-                                      DISABLE-TRANSITED-CHECK option.
-
-         27       RENEWABLE-OK
-                                      The RENEWABLE-OK option indicates that a
-                                      renewable ticket will be acceptable if a
-                                      ticket with the  requested  life  cannot
-                                      otherwise be provided.  If a ticket with
-                                      the requested life cannot  be  provided,
-                                      then  a  renewable  ticket may be issued
-                                      with  a  renew-till  equal  to  the  the
-                                      requested  endtime.   The  value  of the
-                                      renew-till field may still be limited by
-                                      local  limits, or limits selected by the
-                                      individual principal or server.
-
-         28       ENC-TKT-IN-SKEY
-                                      This option is used only by the  ticket-
-                                      granting  service.   The ENC-TKT-IN-SKEY
-                                      option indicates that the ticket for the
-                                      end  server  is  to  be encrypted in the
-                                      session key from the additional  ticket-
-                                      granting ticket provided.
-
-         29       RESERVED
-                                      Reserved for future use.
-
-         30       RENEW
-                                      This option is used only by the  ticket-
-                                      granting   service.   The  RENEW  option
-                                      indicates that the  present  request  is
-                                      for  a  renewal.  The ticket provided is
-                                      encrypted in  the  secret  key  for  the
-                                      server  on  which  it  is  valid.   This
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                                      option  will  only  be  honored  if  the
-                                      ticket  to  be renewed has its RENEWABLE
-                                      flag set and if the time in  its  renew-
-                                      till  field  has not passed.  The ticket
-                                      to be renewed is passed  in  the  padata
-                                      field  as  part  of  the  authentication
-                                      header.
-
-         31       VALIDATE
-                                      This option is used only by the  ticket-
-                                      granting  service.   The VALIDATE option
-                                      indicates that the request is  to  vali-
-                                      date  a  postdated ticket.  It will only
-                                      be honored if the  ticket  presented  is
-                                      postdated,  presently  has  its  INVALID
-                                      flag set, and would be otherwise  usable
-                                      at  this time.  A ticket cannot be vali-
-                                      dated before its starttime.  The  ticket
-                                      presented for validation is encrypted in
-                                      the key of the server for  which  it  is
-                                      valid  and is passed in the padata field
-                                      as part of the authentication header.
-
-cname and sname
-     These fields are the same as those described for the ticket in section
-     5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is
-     specified. If absent, the name of the server is taken from the name of
-     the client in the ticket passed as additional-tickets.
-enc-authorization-data
-     The enc-authorization-data, if present (and it can only be present in
-     the TGS_REQ form), is an encoding of the desired authorization-data
-     encrypted under the sub-session key if present in the Authenticator, or
-     alternatively from the session key in the ticket-granting ticket, both
-     from the padata field in the KRB_AP_REQ.
-realm
-     This field specifies the realm part of the server's principal
-     identifier. In the AS exchange, this is also the realm part of the
-     client's principal identifier.
-from
-     This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
-     requests when the requested ticket is to be postdated. It specifies the
-     desired start time for the requested ticket. If this field is omitted
-     then the KDC should use the current time instead.
-till
-     This field contains the expiration date requested by the client in a
-     ticket request. It is optional and if omitted the requested ticket is
-     to have the maximum endtime permitted according to KDC policy for the
-     parties to the authentication exchange as limited by expiration date of
-     the ticket granting ticket or other preauthentication credentials.
-rtime
-     This field is the requested renew-till time sent from a client to the
-     KDC in a ticket request. It is optional.
-nonce
-     This field is part of the KDC request and response. It it intended to
-     hold a random number generated by the client. If the same number is
-     included in the encrypted response from the KDC, it provides evidence
-     that the response is fresh and has not been replayed by an attacker.
-     Nonces must never be re-used. Ideally, it should be generated randomly,
-     but if the correct time is known, it may suffice[25].
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-etype
-     This field specifies the desired encryption algorithm to be used in the
-     response.
-addresses
-     This field is included in the initial request for tickets, and
-     optionally included in requests for additional tickets from the
-     ticket-granting server. It specifies the addresses from which the
-     requested ticket is to be valid. Normally it includes the addresses for
-     the client's host. If a proxy is requested, this field will contain
-     other addresses. The contents of this field are usually copied by the
-     KDC into the caddr field of the resulting ticket.
-additional-tickets
-     Additional tickets may be optionally included in a request to the
-     ticket-granting server. If the ENC-TKT-IN-SKEY option has been
-     specified, then the session key from the additional ticket will be used
-     in place of the server's key to encrypt the new ticket. If more than
-     one option which requires additional tickets has been specified, then
-     the additional tickets are used in the order specified by the ordering
-     of the options bits (see kdc-options, above).
-
-The application code will be either ten (10) or twelve (12) depending on
-whether the request is for an initial ticket (AS-REQ) or for an additional
-ticket (TGS-REQ).
-
-The optional fields (addresses, authorization-data and additional-tickets)
-are only included if necessary to perform the operation specified in the
-kdc-options field.
-
-It should be noted that in KRB_TGS_REQ, the protocol version number appears
-twice and two different message types appear: the KRB_TGS_REQ message
-contains these fields as does the authentication header (KRB_AP_REQ) that is
-passed in the padata field.
-
-5.4.2. KRB_KDC_REP definition
-
-The KRB_KDC_REP message format is used for the reply from the KDC for either
-an initial (AS) request or a subsequent (TGS) request. There is no message
-type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or
-KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply
-depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in
-the client's secret key, and the client's key version number is included in
-the key version number for the encrypted data. For KRB_TGS_REP, the
-ciphertext is encrypted in the sub-session key from the Authenticator, or if
-absent, the session key from the ticket-granting ticket used in the request.
-In that case, no version number will be present in the EncryptedData
-sequence.
-
-The KRB_KDC_REP message contains the following fields:
-
-AS-REP ::=    [APPLICATION 11] KDC-REP
-TGS-REP ::=   [APPLICATION 13] KDC-REP
-
-KDC-REP ::=   SEQUENCE {
-              pvno[0]                    INTEGER,
-              msg-type[1]                INTEGER,
-              padata[2]                  SEQUENCE OF PA-DATA OPTIONAL,
-              crealm[3]                  Realm,
-              cname[4]                   PrincipalName,
-              ticket[5]                  Ticket,
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-              enc-part[6]                EncryptedData
-}
-
-EncASRepPart ::=    [APPLICATION 25[27]] EncKDCRepPart
-EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart
-
-EncKDCRepPart ::=   SEQUENCE {
-                    key[0]               EncryptionKey,
-                    last-req[1]          LastReq,
-                    nonce[2]             INTEGER,
-                    key-expiration[3]    KerberosTime OPTIONAL,
-                    flags[4]             TicketFlags,
-                    authtime[5]          KerberosTime,
-                    starttime[6]         KerberosTime OPTIONAL,
-                    endtime[7]           KerberosTime,
-                    renew-till[8]        KerberosTime OPTIONAL,
-                    srealm[9]            Realm,
-                    sname[10]            PrincipalName,
-                    caddr[11]            HostAddresses OPTIONAL
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is either
-     KRB_AS_REP or KRB_TGS_REP.
-padata
-     This field is described in detail in section 5.4.1. One possible use
-     for this field is to encode an alternate "mix-in" string to be used
-     with a string-to-key algorithm (such as is described in section 6.3.2).
-     This ability is useful to ease transitions if a realm name needs to
-     change (e.g. when a company is acquired); in such a case all existing
-     password-derived entries in the KDC database would be flagged as
-     needing a special mix-in string until the next password change.
-crealm, cname, srealm and sname
-     These fields are the same as those described for the ticket in section
-     5.3.1.
-ticket
-     The newly-issued ticket, from section 5.3.1.
-enc-part
-     This field is a place holder for the ciphertext and related information
-     that forms the encrypted part of a message. The description of the
-     encrypted part of the message follows each appearance of this field.
-     The encrypted part is encoded as described in section 6.1.
-key
-     This field is the same as described for the ticket in section 5.3.1.
-last-req
-     This field is returned by the KDC and specifies the time(s) of the last
-     request by a principal. Depending on what information is available,
-     this might be the last time that a request for a ticket-granting ticket
-     was made, or the last time that a request based on a ticket-granting
-     ticket was successful. It also might cover all servers for a realm, or
-     just the particular server. Some implementations may display this
-     information to the user to aid in discovering unauthorized use of one's
-     identity. It is similar in spirit to the last login time displayed when
-     logging into timesharing systems.
-nonce
-     This field is described above in section 5.4.1.
-key-expiration
-     The key-expiration field is part of the response from the KDC and
-     specifies the time that the client's secret key is due to expire. The
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     expiration might be the result of password aging or an account
-     expiration. This field will usually be left out of the TGS reply since
-     the response to the TGS request is encrypted in a session key and no
-     client information need be retrieved from the KDC database. It is up to
-     the application client (usually the login program) to take appropriate
-     action (such as notifying the user) if the expiration time is imminent.
-flags, authtime, starttime, endtime, renew-till and caddr
-     These fields are duplicates of those found in the encrypted portion of
-     the attached ticket (see section 5.3.1), provided so the client may
-     verify they match the intended request and to assist in proper ticket
-     caching. If the message is of type KRB_TGS_REP, the caddr field will
-     only be filled in if the request was for a proxy or forwarded ticket,
-     or if the user is substituting a subset of the addresses from the
-     ticket granting ticket. If the client-requested addresses are not
-     present or not used, then the addresses contained in the ticket will be
-     the same as those included in the ticket-granting ticket.
-
-5.5. Client/Server (CS) message specifications
-
-This section specifies the format of the messages used for the
-authentication of the client to the application server.
-
-5.5.1. KRB_AP_REQ definition
-
-The KRB_AP_REQ message contains the Kerberos protocol version number, the
-message type KRB_AP_REQ, an options field to indicate any options in use,
-and the ticket and authenticator themselves. The KRB_AP_REQ message is often
-referred to as the 'authentication header'.
-
-AP-REQ ::=      [APPLICATION 14] SEQUENCE {
-                pvno[0]                       INTEGER,
-                msg-type[1]                   INTEGER,
-                ap-options[2]                 APOptions,
-                ticket[3]                     Ticket,
-                authenticator[4]              EncryptedData
-}
-
-APOptions ::=   BIT STRING {
-                reserved(0),
-                use-session-key(1),
-                mutual-required(2)
-}
-
-
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_AP_REQ.
-ap-options
-     This field appears in the application request (KRB_AP_REQ) and affects
-     the way the request is processed. It is a bit-field, where the selected
-     options are indicated by the bit being set (1), and the unselected
-     options and reserved fields being reset (0). The encoding of the bits
-     is specified in section 5.2. The meanings of the options are:
-
-       Bit(s)   Name              Description
-
-       0        RESERVED
-                                  Reserved for future  expansion  of  this
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                                  field.
-
-       1        USE-SESSION-KEY
-                                  The  USE-SESSION-KEY  option   indicates
-                                  that the ticket the client is presenting
-                                  to a server is encrypted in the  session
-                                  key  from  the  server's ticket-granting
-                                  ticket.  When this option is not  speci-
-                                  fied,  the  ticket  is  encrypted in the
-                                  server's secret key.
-
-       2        MUTUAL-REQUIRED
-                                  The  MUTUAL-REQUIRED  option  tells  the
-                                  server  that  the client requires mutual
-                                  authentication, and that it must respond
-                                  with a KRB_AP_REP message.
-
-       3-31     RESERVED
-                                  Reserved for future use.
-
-ticket
-     This field is a ticket authenticating the client to the server.
-authenticator
-     This contains the authenticator, which includes the client's choice of
-     a subkey. Its encoding is described in section 5.3.2.
-
-5.5.2. KRB_AP_REP definition
-
-The KRB_AP_REP message contains the Kerberos protocol version number, the
-message type, and an encrypted time- stamp. The message is sent in in
-response to an application request (KRB_AP_REQ) where the mutual
-authentication option has been selected in the ap-options field.
-
-AP-REP ::=         [APPLICATION 15] SEQUENCE {
-                   pvno[0]                           INTEGER,
-                   msg-type[1]                       INTEGER,
-                   enc-part[2]                       EncryptedData
-}
-
-EncAPRepPart ::=   [APPLICATION 27[29]] SEQUENCE {
-                   ctime[0]                          KerberosTime,
-                   cusec[1]                          INTEGER,
-                   subkey[2]                         EncryptionKey OPTIONAL,
-                   seq-number[3]                     INTEGER OPTIONAL
-}
-
-The encoded EncAPRepPart is encrypted in the shared session key of the
-ticket. The optional subkey field can be used in an application-arranged
-negotiation to choose a per association session key.
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_AP_REP.
-enc-part
-     This field is described above in section 5.4.2.
-ctime
-     This field contains the current time on the client's host.
-cusec
-     This field contains the microsecond part of the client's timestamp.
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-subkey
-     This field contains an encryption key which is to be used to protect
-     this specific application session. See section 3.2.6 for specifics on
-     how this field is used to negotiate a key. Unless an application
-     specifies otherwise, if this field is left out, the sub-session key
-     from the authenticator, or if also left out, the session key from the
-     ticket will be used.
-
-5.5.3. Error message reply
-
-If an error occurs while processing the application request, the KRB_ERROR
-message will be sent in response. See section 5.9.1 for the format of the
-error message. The cname and crealm fields may be left out if the server
-cannot determine their appropriate values from the corresponding KRB_AP_REQ
-message. If the authenticator was decipherable, the ctime and cusec fields
-will contain the values from it.
-
-5.6. KRB_SAFE message specification
-
-This section specifies the format of a message that can be used by either
-side (client or server) of an application to send a tamper-proof message to
-its peer. It presumes that a session key has previously been exchanged (for
-example, by using the KRB_AP_REQ/KRB_AP_REP messages).
-
-5.6.1. KRB_SAFE definition
-
-The KRB_SAFE message contains user data along with a collision-proof
-checksum keyed with the last encryption key negotiated via subkeys, or the
-session key if no negotiation has occured. The message fields are:
-
-KRB-SAFE ::=        [APPLICATION 20] SEQUENCE {
-                    pvno[0]                       INTEGER,
-                    msg-type[1]                   INTEGER,
-                    safe-body[2]                  KRB-SAFE-BODY,
-                    cksum[3]                      Checksum
-}
-
-KRB-SAFE-BODY ::=   SEQUENCE {
-                    user-data[0]                  OCTET STRING,
-                    timestamp[1]                  KerberosTime OPTIONAL,
-                    usec[2]                       INTEGER OPTIONAL,
-                    seq-number[3]                 INTEGER OPTIONAL,
-                    s-address[4]                  HostAddress OPTIONAL,
-                    r-address[5]                  HostAddress OPTIONAL
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_SAFE.
-safe-body
-     This field is a placeholder for the body of the KRB-SAFE message.
-cksum
-     This field contains the checksum of the application data. Checksum
-     details are described in section 6.4. The checksum is computed over the
-     encoding of the KRB-SAFE sequence. First, the cksum is zeroed and the
-     checksum is computed over the encoding of the KRB-SAFE sequence, then
-     the checksum is set to the result of that computation, and finally the
-     KRB-SAFE sequence is encoded again.
-user-data
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     This field is part of the KRB_SAFE and KRB_PRIV messages and contain
-     the application specific data that is being passed from the sender to
-     the recipient.
-timestamp
-     This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents
-     are the current time as known by the sender of the message. By checking
-     the timestamp, the recipient of the message is able to make sure that
-     it was recently generated, and is not a replay.
-usec
-     This field is part of the KRB_SAFE and KRB_PRIV headers. It contains
-     the microsecond part of the timestamp.
-seq-number
-     This field is described above in section 5.3.2.
-s-address
-     This field specifies the address in use by the sender of the message.
-     It may be omitted if not required by the application protocol. The
-     application designer considering omission of this field is warned, that
-     the inclusion of this address prevents some kinds of replay attacks
-     (e.g., reflection attacks) and that it is only acceptable to omit this
-     address if there is sufficient information in the integrity protected
-     part of the application message for the recipient to unambiguously
-     determine if it was the intended recipient.
-r-address
-     This field specifies the address in use by the recipient of the
-     message. It may be omitted for some uses (such as broadcast protocols),
-     but the recipient may arbitrarily reject such messages. This field
-     along with s-address can be used to help detect messages which have
-     been incorrectly or maliciously delivered to the wrong recipient.
-
-5.7. KRB_PRIV message specification
-
-This section specifies the format of a message that can be used by either
-side (client or server) of an application to securely and privately send a
-message to its peer. It presumes that a session key has previously been
-exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
-
-5.7.1. KRB_PRIV definition
-
-The KRB_PRIV message contains user data encrypted in the Session Key. The
-message fields are:
-
-KRB-PRIV ::=         [APPLICATION 21] SEQUENCE {
-                     pvno[0]                           INTEGER,
-                     msg-type[1]                       INTEGER,
-                     enc-part[3]                       EncryptedData
-}
-
-EncKrbPrivPart ::=   [APPLICATION 28[31]] SEQUENCE {
-                     user-data[0]        OCTET STRING,
-                     timestamp[1]        KerberosTime OPTIONAL,
-                     usec[2]             INTEGER OPTIONAL,
-                     seq-number[3]       INTEGER OPTIONAL,
-                     s-address[4]        HostAddress OPTIONAL, -- sender's addr
-                     r-address[5]        HostAddress OPTIONAL -- recip's addr
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_PRIV.
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-enc-part
-     This field holds an encoding of the EncKrbPrivPart sequence encrypted
-     under the session key[32]. This encrypted encoding is used for the
-     enc-part field of the KRB-PRIV message. See section 6 for the format of
-     the ciphertext.
-user-data, timestamp, usec, s-address and r-address
-     These fields are described above in section 5.6.1.
-seq-number
-     This field is described above in section 5.3.2.
-
-5.8. KRB_CRED message specification
-
-This section specifies the format of a message that can be used to send
-Kerberos credentials from one principal to another. It is presented here to
-encourage a common mechanism to be used by applications when forwarding
-tickets or providing proxies to subordinate servers. It presumes that a
-session key has already been exchanged perhaps by using the
-KRB_AP_REQ/KRB_AP_REP messages.
-
-5.8.1. KRB_CRED definition
-
-The KRB_CRED message contains a sequence of tickets to be sent and
-information needed to use the tickets, including the session key from each.
-The information needed to use the tickets is encrypted under an encryption
-key previously exchanged or transferred alongside the KRB_CRED message. The
-message fields are:
-
-KRB-CRED         ::= [APPLICATION 22]   SEQUENCE {
-                 pvno[0]                INTEGER,
-                 msg-type[1]            INTEGER, -- KRB_CRED
-                 tickets[2]             SEQUENCE OF Ticket,
-                 enc-part[3]            EncryptedData
-}
-
-EncKrbCredPart   ::= [APPLICATION 29]   SEQUENCE {
-                 ticket-info[0]         SEQUENCE OF KrbCredInfo,
-                 nonce[1]               INTEGER OPTIONAL,
-                 timestamp[2]           KerberosTime OPTIONAL,
-                 usec[3]                INTEGER OPTIONAL,
-                 s-address[4]           HostAddress OPTIONAL,
-                 r-address[5]           HostAddress OPTIONAL
-}
-
-KrbCredInfo      ::=                    SEQUENCE {
-                 key[0]                 EncryptionKey,
-                 prealm[1]              Realm OPTIONAL,
-                 pname[2]               PrincipalName OPTIONAL,
-                 flags[3]               TicketFlags OPTIONAL,
-                 authtime[4]            KerberosTime OPTIONAL,
-                 starttime[5]           KerberosTime OPTIONAL,
-                 endtime[6]             KerberosTime OPTIONAL
-                 renew-till[7]          KerberosTime OPTIONAL,
-                 srealm[8]              Realm OPTIONAL,
-                 sname[9]               PrincipalName OPTIONAL,
-                 caddr[10]              HostAddresses OPTIONAL
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     KRB_CRED.
-tickets
-     These are the tickets obtained from the KDC specifically for use by the
-     intended recipient. Successive tickets are paired with the
-     corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED
-     message.
-enc-part
-     This field holds an encoding of the EncKrbCredPart sequence encrypted
-     under the session key shared between the sender and the intended
-     recipient. This encrypted encoding is used for the enc-part field of
-     the KRB-CRED message. See section 6 for the format of the ciphertext.
-nonce
-     If practical, an application may require the inclusion of a nonce
-     generated by the recipient of the message. If the same value is
-     included as the nonce in the message, it provides evidence that the
-     message is fresh and has not been replayed by an attacker. A nonce must
-     never be re-used; it should be generated randomly by the recipient of
-     the message and provided to the sender of the message in an application
-     specific manner.
-timestamp and usec
-     These fields specify the time that the KRB-CRED message was generated.
-     The time is used to provide assurance that the message is fresh.
-s-address and r-address
-     These fields are described above in section 5.6.1. They are used
-     optionally to provide additional assurance of the integrity of the
-     KRB-CRED message.
-key
-     This field exists in the corresponding ticket passed by the KRB-CRED
-     message and is used to pass the session key from the sender to the
-     intended recipient. The field's encoding is described in section 6.2.
-
-The following fields are optional. If present, they can be associated with
-the credentials in the remote ticket file. If left out, then it is assumed
-that the recipient of the credentials already knows their value.
-
-prealm and pname
-     The name and realm of the delegated principal identity.
-flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr
-     These fields contain the values of the correspond- ing fields from the
-     ticket found in the ticket field. Descriptions of the fields are
-     identical to the descriptions in the KDC-REP message.
-
-5.9. Error message specification
-
-This section specifies the format for the KRB_ERROR message. The fields
-included in the message are intended to return as much information as
-possible about an error. It is not expected that all the information
-required by the fields will be available for all types of errors. If the
-appropriate information is not available when the message is composed, the
-corresponding field will be left out of the message.
-
-Note that since the KRB_ERROR message is only optionally integrity
-protected, it is quite possible for an intruder to synthesize or modify such
-a message. In particular, this means that unless appropriate integrity
-protection mechanisms have been applied to the KRB_ERROR message, the client
-should not use any fields in this message for security-critical purposes,
-such as setting a system clock or generating a fresh authenticator. The
-message can be useful, however, for advising a user on the reason for some
-failure.
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-
-5.9.1. KRB_ERROR definition
-
-The KRB_ERROR message consists of the following fields:
-
-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-cksum[13]                   Checksum OPTIONAL,
-}
-
-
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_ERROR.
-ctime
-     This field is described above in section 5.4.1.
-cusec
-     This field is described above in section 5.5.2.
-stime
-     This field contains the current time on the server. It is of type
-     KerberosTime.
-susec
-     This field contains the microsecond part of the server's timestamp. Its
-     value ranges from 0 to 999999. It appears along with stime. The two
-     fields are used in conjunction to specify a reasonably accurate
-     timestamp.
-error-code
-     This field contains the error code returned by Kerberos or the server
-     when a request fails. To interpret the value of this field see the list
-     of error codes in section 8. Implementations are encouraged to provide
-     for national language support in the display of error messages.
-crealm, cname, srealm and sname
-     These fields are described above in section 5.3.1.
-e-text
-     This field contains additional text to help explain the error code
-     associated with the failed request (for example, it might include a
-     principal name which was unknown).
-e-data
-     This field contains additional data about the error for use by the
-     application to help it recover from or handle the error. If present,
-     this field will contain the encoding of a sequence of TypedData
-     (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED,
-     in which case it will contain the encoding of a sequence of of padata
-     fields (METHOD-DATA below), each corresponding to an acceptable
-     pre-authentication method and optionally containing data for the
-     method:
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-
-     TYPED-DATA   ::=   SEQUENCE of TypeData
-     METHOD-DATA  ::=   SEQUENCE of PA-DATA
-
-     TypedData ::=   SEQUENCE {
-                         data-type[0]   INTEGER,
-                         data-value[1]  OCTET STRING OPTIONAL
-     }
-
-     Note that e-data-types have been reserved for all PA data types defined
-     prior to July 1999. For the KDC_ERR_PREAUTH_REQUIRED message, when
-     using new PA data types defined in July 1999 or later, the METHOD-DATA
-     sequence must itself be encapsulated in an TypedData element of type
-     TD-PADATA. All new implementations interpreting the METHOD-DATA field
-     for the KDC_ERR_PREAUTH_REQUIRED message must accept a type of
-     TD-PADATA, extract the typed data field and interpret the use any
-     elements encapsulated in the TD-PADATA elements as if they were present
-     in the METHOD-DATA sequence.
-e-cksum
-     This field contains an optional checksum for the KRB-ERROR message. The
-     checksum is calculated over the Kerberos ASN.1 encoding of the
-     KRB-ERROR message with the checksum absent. The checksum is then added
-     to the KRB-ERROR structure and the message is re-encoded. The Checksum
-     should be calculated using the session key from the ticket granting
-     ticket or service ticket, where available. If the error is in response
-     to a TGS or AP request, the checksum should be calculated uing the the
-     session key from the client's ticket. If the error is in response to an
-     AS request, then the checksum should be calulated using the client's
-     secret key ONLY if there has been suitable preauthentication to prove
-     knowledge of the secret key by the client[33]. If a checksum can not be
-     computed because the key to be used is not available, no checksum will
-     be included.
-
-     6. Encryption and Checksum Specifications
-
-     The Kerberos protocols described in this document are designed to use
-     stream encryption ciphers, which can be simulated using commonly
-     available block encryption ciphers, such as the Data Encryption
-     Standard [DES77], and triple DES variants, in conjunction with block
-     chaining and checksum methods [DESM80]. Encryption is used to prove the
-     identities of the network entities participating in message exchanges.
-     The Key Distribution Center for each realm is trusted by all principals
-     registered in that realm to store a secret key in confidence. Proof of
-     knowledge of this secret key is used to verify the authenticity of a
-     principal.
-
-     The KDC uses the principal's secret key (in the AS exchange) or a
-     shared session key (in the TGS exchange) to encrypt responses to ticket
-     requests; the ability to obtain the secret key or session key implies
-     the knowledge of the appropriate keys and the identity of the KDC. The
-     ability of a principal to decrypt the KDC response and present a Ticket
-     and a properly formed Authenticator (generated with the session key
-     from the KDC response) to a service verifies the identity of the
-     principal; likewise the ability of the service to extract the session
-     key from the Ticket and prove its knowledge thereof in a response
-     verifies the identity of the service.
-
-     The Kerberos protocols generally assume that the encryption used is
-     secure from cryptanalysis; however, in some cases, the order of fields
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     in the encrypted portions of messages are arranged to minimize the
-     effects of poorly chosen keys. It is still important to choose good
-     keys. If keys are derived from user-typed passwords, those passwords
-     need to be well chosen to make brute force attacks more difficult.
-     Poorly chosen keys still make easy targets for intruders.
-
-     The following sections specify the encryption and checksum mechanisms
-     currently defined for Kerberos. The encodings, chaining, and padding
-     requirements for each are described. For encryption methods, it is
-     often desirable to place random information (often referred to as a
-     confounder) at the start of the message. The requirements for a
-     confounder are specified with each encryption mechanism.
-
-     Some encryption systems use a block-chaining method to improve the the
-     security characteristics of the ciphertext. However, these chaining
-     methods often don't provide an integrity check upon decryption. Such
-     systems (such as DES in CBC mode) must be augmented with a checksum of
-     the plain-text which can be verified at decryption and used to detect
-     any tampering or damage. Such checksums should be good at detecting
-     burst errors in the input. If any damage is detected, the decryption
-     routine is expected to return an error indicating the failure of an
-     integrity check. Each encryption type is expected to provide and verify
-     an appropriate checksum. The specification of each encryption method
-     sets out its checksum requirements.
-
-     Finally, where a key is to be derived from a user's password, an
-     algorithm for converting the password to a key of the appropriate type
-     is included. It is desirable for the string to key function to be
-     one-way, and for the mapping to be different in different realms. This
-     is important because users who are registered in more than one realm
-     will often use the same password in each, and it is desirable that an
-     attacker compromising the Kerberos server in one realm not obtain or
-     derive the user's key in another.
-
-     For an discussion of the integrity characteristics of the candidate
-     encryption and checksum methods considered for Kerberos, the reader is
-     referred to [SG92].
-
-     6.1. Encryption Specifications
-
-     The following ASN.1 definition describes all encrypted messages. The
-     enc-part field which appears in the unencrypted part of messages in
-     section 5 is a sequence consisting of an encryption type, an optional
-     key version number, and the ciphertext.
-
-     EncryptedData ::=   SEQUENCE {
-                         etype[0]     INTEGER, -- EncryptionType
-                         kvno[1]      INTEGER OPTIONAL,
-                         cipher[2]    OCTET STRING -- ciphertext
-     }
-
-
-
-     etype
-          This field identifies which encryption algorithm was used to
-          encipher the cipher. Detailed specifications for selected
-          encryption types appear later in this section.
-     kvno
-          This field contains the version number of the key under which data
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-          is encrypted. It is only present in messages encrypted under long
-          lasting keys, such as principals' secret keys.
-     cipher
-          This field contains the enciphered text, encoded as an OCTET
-          STRING.
-     The cipher field is generated by applying the specified encryption
-     algorithm to data composed of the message and algorithm-specific
-     inputs. Encryption mechanisms defined for use with Kerberos must take
-     sufficient measures to guarantee the integrity of the plaintext, and we
-     recommend they also take measures to protect against precomputed
-     dictionary attacks. If the encryption algorithm is not itself capable
-     of doing so, the protections can often be enhanced by adding a checksum
-     and a confounder.
-
-     The suggested format for the data to be encrypted includes a
-     confounder, a checksum, the encoded plaintext, and any necessary
-     padding. The msg-seq field contains the part of the protocol message
-     described in section 5 which is to be encrypted. The confounder,
-     checksum, and padding are all untagged and untyped, and their length is
-     exactly sufficient to hold the appropriate item. The type and length is
-     implicit and specified by the particular encryption type being used
-     (etype). The format for the data to be encrypted for some methods is
-     described in the following diagram, but other methods may deviate from
-     this layour - so long as the definition of the method defines the
-     layout actually in use.
-
-           +-----------+----------+-------------+-----+
-           |confounder |   check  |   msg-seq   | pad |
-           +-----------+----------+-------------+-----+
-
-     The format cannot be described in ASN.1, but for those who prefer an
-     ASN.1-like notation:
-
-     CipherText ::=   ENCRYPTED       SEQUENCE {
-          confounder[0]   UNTAGGED[35] OCTET STRING(conf_length) OPTIONAL,
-          check[1]        UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
-          msg-seq[2]      MsgSequence,
-          pad             UNTAGGED OCTET STRING(pad_length) OPTIONAL
-     }
-
-     One generates a random confounder of the appropriate length, placing it
-     in confounder; zeroes out check; calculates the appropriate checksum
-     over confounder, check, and msg-seq, placing the result in check; adds
-     the necessary padding; then encrypts using the specified encryption
-     type and the appropriate key.
-
-     Unless otherwise specified, a definition of an encryption algorithm
-     that specifies a checksum, a length for the confounder field, or an
-     octet boundary for padding uses this ciphertext format[36]. Those
-     fields which are not specified will be omitted.
-
-     In the interest of allowing all implementations using a particular
-     encryption type to communicate with all others using that type, the
-     specification of an encryption type defines any checksum that is needed
-     as part of the encryption process. If an alternative checksum is to be
-     used, a new encryption type must be defined.
-
-     Some cryptosystems require additional information beyond the key and
-     the data to be encrypted. For example, DES, when used in
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     cipher-block-chaining mode, requires an initialization vector. If
-     required, the description for each encryption type must specify the
-     source of such additional information. 6.2. Encryption Keys
-
-     The sequence below shows the encoding of an encryption key:
-
-            EncryptionKey ::=   SEQUENCE {
-                                keytype[0]    INTEGER,
-                                keyvalue[1]   OCTET STRING
-            }
-
-     keytype
-          This field specifies the type of encryption that is to be
-          performed using the key that follows in the keyvalue field. It
-          will always correspond to the etype to be used to generate or
-          decode the EncryptedData. In cases when multiple algorithms use a
-          common kind of key (e.g., if the encryption algorithm uses an
-          alternate checksum algorithm for an integrity check, or a
-          different chaining mechanism), the keytype provides information
-          needed to determine which algorithm is to be used.
-     keyvalue
-          This field contains the key itself, encoded as an octet string.
-     All negative values for the encryption key type are reserved for local
-     use. All non-negative values are reserved for officially assigned type
-     fields and interpreta- tions.
-
-     6.3. Encryption Systems
-
-     6.3.1. The NULL Encryption System (null)
-
-     If no encryption is in use, the encryption system is said to be the
-     NULL encryption system. In the NULL encryption system there is no
-     checksum, confounder or padding. The ciphertext is simply the
-     plaintext. The NULL Key is used by the null encryption system and is
-     zero octets in length, with keytype zero (0).
-
-     6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
-
-     The des-cbc-crc encryption mode encrypts information under the Data
-     Encryption Standard [DES77] using the cipher block chaining mode
-     [DESM80]. A CRC-32 checksum (described in ISO 3309 [ISO3309]) is
-     applied to the confounder and message sequence (msg-seq) and placed in
-     the cksum field. DES blocks are 8 bytes. As a result, the data to be
-     encrypted (the concatenation of confounder, checksum, and message) must
-     be padded to an 8 byte boundary before encryption. The details of the
-     encryption of this data are identical to those for the des-cbc-md5
-     encryption mode.
-
-     Note that, since the CRC-32 checksum is not collision-proof, an
-     attacker could use a probabilistic chosen-plaintext attack to generate
-     a valid message even if a confounder is used [SG92]. The use of
-     collision-proof checksums is recommended for environments where such
-     attacks represent a significant threat. The use of the CRC-32 as the
-     checksum for ticket or authenticator is no longer mandated as an
-     interoperability requirement for Kerberos Version 5 Specification 1
-     (See section 9.1 for specific details).
-
-     6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     The des-cbc-md4 encryption mode encrypts information under the Data
-     Encryption Standard [DES77] using the cipher block chaining mode
-     [DESM80]. An MD4 checksum (described in [MD492]) is applied to the
-     confounder and message sequence (msg-seq) and placed in the cksum
-     field. DES blocks are 8 bytes. As a result, the data to be encrypted
-     (the concatenation of confounder, checksum, and message) must be padded
-     to an 8 byte boundary before encryption. The details of the encryption
-     of this data are identical to those for the des-cbc-md5 encryption
-     mode.
-
-     6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
-
-     The des-cbc-md5 encryption mode encrypts information under the Data
-     Encryption Standard [DES77] using the cipher block chaining mode
-     [DESM80]. An MD5 checksum (described in [MD5-92].) is applied to the
-     confounder and message sequence (msg-seq) and placed in the cksum
-     field. DES blocks are 8 bytes. As a result, the data to be encrypted
-     (the concatenation of confounder, checksum, and message) must be padded
-     to an 8 byte boundary before encryption.
-
-     Plaintext and DES ciphtertext are encoded as blocks of 8 octets which
-     are concatenated to make the 64-bit inputs for the DES algorithms. The
-     first octet supplies the 8 most significant bits (with the octet's
-     MSbit used as the DES input block's MSbit, etc.), the second octet the
-     next 8 bits, ..., and the eighth octet supplies the 8 least significant
-     bits.
-
-     Encryption under DES using cipher block chaining requires an additional
-     input in the form of an initialization vector. Unless otherwise
-     specified, zero should be used as the initialization vector. Kerberos'
-     use of DES requires an 8 octet confounder.
-
-     The DES specifications identify some 'weak' and 'semi-weak' keys; those
-     keys shall not be used for encrypting messages for use in Kerberos.
-     Additionally, because of the way that keys are derived for the
-     encryption of checksums, keys shall not be used that yield 'weak' or
-     'semi-weak' keys when eXclusive-ORed with the hexadecimal constant
-     F0F0F0F0F0F0F0F0.
-
-     A DES key is 8 octets of data, with keytype one (1). This consists of
-     56 bits of key, and 8 parity bits (one per octet). The key is encoded
-     as a series of 8 octets written in MSB-first order. The bits within the
-     key are also encoded in MSB order. For example, if the encryption key
-     is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
-     B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the
-     parity bits, the first octet of the key would be B1,B2,...,B7,P1 (with
-     B1 as the MSbit). [See the FIPS 81 introduction for reference.]
-
-     String to key transformation
-
-     To generate a DES key from a text string (password), a "salt" is
-     concatenated to the text string, and then padded with ASCII nulls to an
-     8 byte boundary. This "salt" is normally the realm and each component
-     of the principal's name appended. However, sometimes different salts
-     are used --- for example, when a realm is renamed, or if a user changes
-     her username, or for compatibility with Kerberos V4 (whose
-     string-to-key algorithm uses a null string for the salt). This string
-     is then fan-folded and eXclusive-ORed with itself to form an 8 byte DES
-     key. Before eXclusive-ORing a block, every byte is shifted one bit to
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     the left to leave the lowest bit zero. The key is the "corrected" by
-     correcting the parity on the key, and if the key matches a 'weak' or
-     'semi-weak' key as described in the DES specification, it is
-     eXclusive-ORed with the constant 00000000000000F0. This key is then
-     used to generate a DES CBC checksum on the initial string (with the
-     salt appended). The result of the CBC checksum is the "corrected" as
-     described above to form the result which is return as the key.
-     Pseudocode follows:
-
-          name_to_default_salt(realm, name) {
-               s = realm
-               for(each component in name) {
-                    s = s + component;
-               }
-               return s;
-          }
-
-          key_correction(key) {
-               fixparity(key);
-               if (is_weak_key_key(key))
-                    key = key XOR 0xF0;
-               return(key);
-          }
-
-          string_to_key(string,salt) {
-
-               odd = 1;
-               s = string + salt;
-               tempkey = NULL;
-               pad(s); /* with nulls to 8 byte boundary */
-               for(8byteblock in s) {
-                    if(odd == 0)  {
-                        odd = 1;
-                        reverse(8byteblock)
-                    }
-                    else odd = 0;
-                    left shift every byte in 8byteblock one bit;
-                    tempkey = tempkey XOR 8byteblock;
-               }
-               tempkey = key_correction(tempkey);
-               key = key_correction(DES-CBC-check(s,tempkey));
-               return(key);
-          }
-
-     6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with and
-     without Key Derivation [Original draft by Marc Horowitz, revisions by
-     David Miller]
-
-     This encryption type is based on the Triple DES cryptosystem, the
-     HMAC-SHA1 [Krawczyk96] message authentication algorithm, and key
-     derivation for Kerberos V5 [HorowitzB96]. Key derivation may or may not
-     be used in conjunction with the use of Triple DES keys.
-
-     Algorithm Identifiers
-
-     The des3-cbc-hmac-sha1 encryption type has been assigned the value 7.
-     The des3-cbc-hmac-sha1-kd encryption type, specifying the key
-     derivation variant of the encryption type, has been assigned the value
-     16. The hmac-sha1-des3 checksum type has been assigned the value 13.
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     The hmac-sha1-des3-kd checksum type, specifying the key derivation
-     variant of the checksum, has been assigned the value 12.
-
-     Triple DES Key Production
-
-     The EncryptionKey value is 24 octets long. The 7 most significant bits
-     of each octet contain key bits, and the least significant bit is the
-     inverse of the xor of the key bits.
-
-     For the purposes of key derivation, the block size is 64 bits, and the
-     key size is 168 bits. The 168 bits output by key derivation are
-     converted to an EncryptionKey value as follows. First, the 168 bits are
-     divided into three groups of 56 bits, which are expanded individually
-     into 64 bits as follows:
-
-      1  2  3  4  5  6  7  p
-      9 10 11 12 13 14 15  p
-     17 18 19 20 21 22 23  p
-     25 26 27 28 29 30 31  p
-     33 34 35 36 37 38 39  p
-     41 42 43 44 45 46 47  p
-     49 50 51 52 53 54 55  p
-     56 48 40 32 24 16  8  p
-
-     The "p" bits are parity bits computed over the data bits. The output of
-     the three expansions are concatenated to form the EncryptionKey value.
-
-     When the HMAC-SHA1 of a string is computed, the key is used in the
-     EncryptedKey form.
-
-     The string-to-key function is used to tranform UNICODE passwords into
-     DES3 keys. The DES3 string-to-key function relies on the "N-fold"
-     algorithm, which is detailed in [9]. The description of the N-fold
-     algorithm in that document is as follows:
-        o To n-fold a number X, replicate the input value to a length that
-          is the least common multiple of n and the length of X. Before each
-          repetition, the input is rotated to the right by 13 bit positions.
-          The successive n-bit chunks are added together using
-          1's-complement addition (that is, addition with end-around carry)
-          to yield an n-bit result"
-        o The n-fold algorithm, as with DES string-to-key, is applied to the
-          password string concatenated with a salt value. The salt value is
-          derived in the same was as for the DES string-to-key algorithm.
-          For 3-key triple DES then, the operation will involve a 168-fold
-          of the input password string. The remainder of the string-to-key
-          function for DES3 is shown here in pseudocode:
-
-     DES3string-to-key(passwordString, key)
-
-         salt = name_to_default_salt(realm, name)
-         s = passwordString + salt
-         tmpKey1 = 168-fold(s)
-         parityFix(tmpKey1);
-         if not weakKey(tmpKey1)
-             /*
-              * Encrypt temp key in itself with a
-              * zero initialization vector
-              *
-              * Function signature is DES3encrypt(plain, key, iv)
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-              * with cipher as the return value
-              */
-             tmpKey2 = DES3encrypt(tmpKey1, tmpKey1, zeroIvec)
-             /*
-              * Encrypt resultant temp key in itself with third component
-              * of first temp key as initialization vector
-              */
-             key = DES3encrypt(tmpKey2, tmpKey1, tmpKey1[2])
-             parityFix(key)
-             if not weakKey(key)
-                  return SUCCESS
-             else
-                  return FAILURE
-         else
-             return FAILURE
-
-     The weakKey function above is the same weakKey function used with DES
-     keys, but applied to each of the three single DES keys that comprise
-     the triple DES key.
-
-     The lengths of UNICODE encoded character strings include the trailing
-     terminator character (0).
-
-     Encryption Types des3-cbc-hmac-sha1 and des3-cbc-hmac-sha1-kd
-
-     EncryptedData using this type must be generated as described in
-     [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC mode.
-     The checksum algorithm is HMAC-SHA1. If the key derivation variant of
-     the encryption type is used, encryption key values are modified
-     according to the method under the Key Derivation section below.
-
-     Unless otherwise specified, a zero IV must be used.
-
-     If the length of the input data is not a multiple of the block size,
-     zero octets must be used to pad the plaintext to the next eight-octet
-     boundary. The counfounder must be eight random octets (one block).
-
-     Checksum Types hmac-sha1-des3 and hmac-sha1-des3-kd
-
-     Checksums using this type must be generated as described in
-     [Horowitz96]. The keyed hash algorithm is HMAC-SHA1. If the key
-     derivation variant of the checksum type is used, checksum key values
-     are modified according to the method under the Key Derivation section
-     below.
-
-     Key Derivation
-
-     In the Kerberos protocol, cryptographic keys are used in a number of
-     places. In order to minimize the effect of compromising a key, it is
-     desirable to use a different key for each of these places. Key
-     derivation [Horowitz96] can be used to construct different keys for
-     each operation from the keys transported on the network. For this to be
-     possible, a small change to the specification is necessary.
-
-     This section specifies a profile for the use of key derivation
-     [Horowitz96] with Kerberos. For each place where a key is used, a ``key
-     usage'' must is specified for that purpose. The key, key usage, and
-     encryption/checksum type together describe the transformation from
-     plaintext to ciphertext, or plaintext to checksum.
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-
-     Key Usage Values
-
-     This is a complete list of places keys are used in the kerberos
-     protocol, with key usage values and RFC 1510 section numbers:
-
-      1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
-         client key (section 5.4.1)
-      2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
-         application session key), encrypted with the service key
-         (section 5.4.2)
-      3. AS-REP encrypted part (includes tgs session key or application
-         session key), encrypted with the client key (section 5.4.2)
-      4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
-         session key (section 5.4.1)
-      5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
-         authenticator subkey (section 5.4.1)
-      6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
-         with the tgs session key (sections 5.3.2, 5.4.1)
-      7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
-         authenticator subkey), encrypted with the tgs session key
-         (section 5.3.2)
-      8. TGS-REP encrypted part (includes application session key),
-         encrypted with the tgs session key (section 5.4.2)
-      9. TGS-REP encrypted part (includes application session key),
-         encrypted with the tgs authenticator subkey (section 5.4.2)
-     10. AP-REQ Authenticator cksum, keyed with the application session
-         key (section 5.3.2)
-     11. AP-REQ Authenticator (includes application authenticator
-         subkey), encrypted with the application session key (section
-         5.3.2)
-     12. AP-REP encrypted part (includes application session subkey),
-         encrypted with the application session key (section 5.5.2)
-     13. KRB-PRIV encrypted part, encrypted with a key chosen by the
-         application (section 5.7.1)
-     14. KRB-CRED encrypted part, encrypted with a key chosen by the
-         application (section 5.6.1)
-     15. KRB-SAVE cksum, keyed with a key chosen by the application
-         (section 5.8.1)
-     18. KRB-ERROR checksum (e-cksum in section 5.9.1)
-     19. AD-KDCIssued checksum (ad-checksum in appendix B.1)
-     20. Checksum for Mandatory Ticket Extensions (appendix B.6)
-     21. Checksum in Authorization Data in Ticket Extensions (appendix B.7)
-
-     Key usage values between 1024 and 2047 (inclusive) are reserved for
-     application use. Applications should use even values for encryption and
-     odd values for checksums within this range.
-
-     A few of these key usages need a little clarification. A service which
-     receives an AP-REQ has no way to know if the enclosed Ticket was part
-     of an AS-REP or TGS-REP. Therefore, key usage 2 must always be used for
-     generating a Ticket, whether it is in response to an AS- REQ or
-     TGS-REQ.
-
-     There might exist other documents which define protocols in terms of
-     the RFC1510 encryption types or checksum types. Such documents would
-     not know about key usages. In order that these documents continue to be
-     meaningful until they are updated, key usages 1024 and 1025 must be
-     used to derive keys for encryption and checksums, respectively. New
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     protocols defined in terms of the Kerberos encryption and checksum
-     types should use their own key usages. Key usages may be registered
-     with IANA to avoid conflicts. Key usages must be unsigned 32 bit
-     integers. Zero is not permitted.
-
-     Defining Cryptosystems Using Key Derivation
-
-     Kerberos requires that the ciphertext component of EncryptedData be
-     tamper-resistant as well as confidential. This implies encryption and
-     integrity functions, which must each use their own separate keys. So,
-     for each key usage, two keys must be generated, one for encryption
-     (Ke), and one for integrity (Ki):
-
-           Ke = DK(protocol key, key usage | 0xAA)
-           Ki = DK(protocol key, key usage | 0x55)
-
-     where the protocol key is from the EncryptionKey from the wire
-     protocol, and the key usage is represented as a 32 bit integer in
-     network byte order. The ciphertest must be generated from the plaintext
-     as follows:
-
-        ciphertext = E(Ke, confounder | plaintext | padding) |
-                     H(Ki, confounder | plaintext | padding)
-
-     The confounder and padding are specific to the encryption algorithm E.
-
-     When generating a checksum only, there is no need for a confounder or
-     padding. Again, a new key (Kc) must be used. Checksums must be
-     generated from the plaintext as follows:
-
-           Kc = DK(protocol key, key usage | 0x99)
-           MAC = H(Kc, plaintext)
-
-     Note that each enctype is described by an encryption algorithm E and a
-     keyed hash algorithm H, and each checksum type is described by a keyed
-     hash algorithm H. HMAC, with an appropriate hash, is required for use
-     as H.
-
-     Key Derivation from Passwords
-
-     The well-known constant for password key derivation must be the byte
-     string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values
-     correspond to the ASCII encoding for the string "kerberos".
-
-     6.4. Checksums
-
-     The following is the ASN.1 definition used for a checksum:
-
-              Checksum ::=   SEQUENCE {
-                             cksumtype[0]   INTEGER,
-                             checksum[1]    OCTET STRING
-              }
-
-     cksumtype
-          This field indicates the algorithm used to generate the
-          accompanying checksum.
-     checksum
-          This field contains the checksum itself, encoded as an octet
-          string.
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     Detailed specification of selected checksum types appear later in this
-     section. Negative values for the checksum type are reserved for local
-     use. All non-negative values are reserved for officially assigned type
-     fields and interpretations.
-
-     Checksums used by Kerberos can be classified by two properties: whether
-     they are collision-proof, and whether they are keyed. It is infeasible
-     to find two plaintexts which generate the same checksum value for a
-     collision-proof checksum. A key is required to perturb or initialize
-     the algorithm in a keyed checksum. To prevent message-stream
-     modification by an active attacker, unkeyed checksums should only be
-     used when the checksum and message will be subsequently encrypted (e.g.
-     the checksums defined as part of the encryption algorithms covered
-     earlier in this section).
-
-     Collision-proof checksums can be made tamper-proof if the checksum
-     value is encrypted before inclusion in a message. In such cases, the
-     composition of the checksum and the encryption algorithm must be
-     considered a separate checksum algorithm (e.g. RSA-MD5 encrypted using
-     DES is a new checksum algorithm of type RSA-MD5-DES). For most keyed
-     checksums, as well as for the encrypted forms of unkeyed
-     collision-proof checksums, Kerberos prepends a confounder before the
-     checksum is calculated.
-
-     6.4.1. The CRC-32 Checksum (crc32)
-
-     The CRC-32 checksum calculates a checksum based on a cyclic redundancy
-     check as described in ISO 3309 [ISO3309]. The resulting checksum is
-     four (4) octets in length. The CRC-32 is neither keyed nor
-     collision-proof. The use of this checksum is not recommended. An
-     attacker using a probabilistic chosen-plaintext attack as described in
-     [SG92] might be able to generate an alternative message that satisfies
-     the checksum. The use of collision-proof checksums is recommended for
-     environments where such attacks represent a significant threat.
-
-     6.4.2. The RSA MD4 Checksum (rsa-md4)
-
-     The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm
-     [MD4-92]. The algorithm takes as input an input message of arbitrary
-     length and produces as output a 128-bit (16 octet) checksum. RSA-MD4 is
-     believed to be collision-proof.
-
-     6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des)
-
-     The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by
-     prepending an 8 octet confounder before the text, applying the RSA MD4
-     checksum algorithm, and encrypting the confounder and the checksum
-     using DES in cipher-block-chaining (CBC) mode using a variant of the
-     key, where the variant is computed by eXclusive-ORing the key with the
-     constant F0F0F0F0F0F0F0F0[39]. The initialization vector should be
-     zero. The resulting checksum is 24 octets long (8 octets of which are
-     redundant). This checksum is tamper-proof and believed to be
-     collision-proof.
-
-     The DES specifications identify some weak keys' and 'semi-weak keys';
-     those keys shall not be used for generating RSA-MD4 checksums for use
-     in Kerberos.
-
-     The format for the checksum is described in the follow- ing diagram:
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-
-     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-     |  des-cbc(confounder   +   rsa-md4(confounder+msg),key=var(key),iv=0)  |
-     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-     The format cannot be described in ASN.1, but for those who prefer an
-     ASN.1-like notation:
-
-     rsa-md4-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                                confounder[0]   UNTAGGED OCTET STRING(8),
-                                check[1]        UNTAGGED OCTET STRING(16)
-     }
-
-     6.4.4. The RSA MD5 Checksum (rsa-md5)
-
-     The RSA-MD5 checksum calculates a checksum using the RSA MD5 algorithm.
-     [MD5-92]. The algorithm takes as input an input message of arbitrary
-     length and produces as output a 128-bit (16 octet) checksum. RSA-MD5 is
-     believed to be collision-proof.
-
-     6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des)
-
-     The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by
-     prepending an 8 octet confounder before the text, applying the RSA MD5
-     checksum algorithm, and encrypting the confounder and the checksum
-     using DES in cipher-block-chaining (CBC) mode using a variant of the
-     key, where the variant is computed by eXclusive-ORing the key with the
-     hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector should
-     be zero. The resulting checksum is 24 octets long (8 octets of which
-     are redundant). This checksum is tamper-proof and believed to be
-     collision-proof.
-
-     The DES specifications identify some 'weak keys' and 'semi-weak keys';
-     those keys shall not be used for encrypting RSA-MD5 checksums for use
-     in Kerberos.
-
-     The format for the checksum is described in the following diagram:
-
-     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-     |  des-cbc(confounder   +   rsa-md5(confounder+msg),key=var(key),iv=0)  |
-     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-     The format cannot be described in ASN.1, but for those who prefer an
-     ASN.1-like notation:
-
-     rsa-md5-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                                confounder[0]   UNTAGGED OCTET STRING(8),
-                                check[1]        UNTAGGED OCTET STRING(16)
-     }
-
-     6.4.6. DES cipher-block chained checksum (des-mac)
-
-     The DES-MAC checksum is computed by prepending an 8 octet confounder to
-     the plaintext, performing a DES CBC-mode encryption on the result using
-     the key and an initialization vector of zero, taking the last block of
-     the ciphertext, prepending the same confounder and encrypting the pair
-     using DES in cipher-block-chaining (CBC) mode using a a variant of the
-     key, where the variant is computed by eXclusive-ORing the key with the
-     hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector should
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     be zero. The resulting checksum is 128 bits (16 octets) long, 64 bits
-     of which are redundant. This checksum is tamper-proof and
-     collision-proof.
-
-     The format for the checksum is described in the following diagram:
-
-     +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
-     |   des-cbc(confounder  + des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
-     +--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
-
-     The format cannot be described in ASN.1, but for those who prefer an
-     ASN.1-like notation:
-
-     des-mac-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                            confounder[0]   UNTAGGED OCTET STRING(8),
-                            check[1]        UNTAGGED OCTET STRING(8)
-     }
-
-     The DES specifications identify some 'weak' and 'semi-weak' keys; those
-     keys shall not be used for generating DES-MAC checksums for use in
-     Kerberos, nor shall a key be used whose variant is 'weak' or
-     'semi-weak'.
-
-     6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative
-     (rsa-md4-des-k)
-
-     The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum
-     by applying the RSA MD4 checksum algorithm and encrypting the results
-     using DES in cipher-block-chaining (CBC) mode using a DES key as both
-     key and initialization vector. The resulting checksum is 16 octets
-     long. This checksum is tamper-proof and believed to be collision-proof.
-     Note that this checksum type is the old method for encoding the
-     RSA-MD4-DES checksum and it is no longer recommended.
-
-     6.4.8. DES cipher-block chained checksum alternative (des-mac-k)
-
-     The DES-MAC-K checksum is computed by performing a DES CBC-mode
-     encryption of the plaintext, and using the last block of the ciphertext
-     as the checksum value. It is keyed with an encryption key and an
-     initialization vector; any uses which do not specify an additional
-     initialization vector will use the key as both key and initialization
-     vector. The resulting checksum is 64 bits (8 octets) long. This
-     checksum is tamper-proof and collision-proof. Note that this checksum
-     type is the old method for encoding the DES-MAC checksum and it is no
-     longer recommended. The DES specifications identify some 'weak keys'
-     and 'semi-weak keys'; those keys shall not be used for generating
-     DES-MAC checksums for use in Kerberos.
-
-     7. Naming Constraints
-
-     7.1. Realm Names
-
-     Although realm names are encoded as GeneralStrings and although a realm
-     can technically select any name it chooses, interoperability across
-     realm boundaries requires agreement on how realm names are to be
-     assigned, and what information they imply.
-
-     To enforce these conventions, each realm must conform to the
-     conventions itself, and it must require that any realms with which
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     inter-realm keys are shared also conform to the conventions and require
-     the same from its neighbors.
-
-     Kerberos realm names are case sensitive. Realm names that differ only
-     in the case of the characters are not equivalent. There are presently
-     four styles of realm names: domain, X500, other, and reserved. Examples
-     of each style follow:
-
-          domain:   ATHENA.MIT.EDU (example)
-            X500:   C=US/O=OSF (example)
-           other:   NAMETYPE:rest/of.name=without-restrictions (example)
-        reserved:   reserved, but will not conflict with above
-
-     Domain names must look like domain names: they consist of components
-     separated by periods (.) and they contain neither colons (:) nor
-     slashes (/). Domain names must be converted to upper case when used as
-     realm names.
-
-     X.500 names contain an equal (=) and cannot contain a colon (:) before
-     the equal. The realm names for X.500 names will be string
-     representations of the names with components separated by slashes.
-     Leading and trailing slashes will not be included.
-
-     Names that fall into the other category must begin with a prefix that
-     contains no equal (=) or period (.) and the prefix must be followed by
-     a colon (:) and the rest of the name. All prefixes must be assigned
-     before they may be used. Presently none are assigned.
-
-     The reserved category includes strings which do not fall into the first
-     three categories. All names in this category are reserved. It is
-     unlikely that names will be assigned to this category unless there is a
-     very strong argument for not using the 'other' category.
-
-     These rules guarantee that there will be no conflicts between the
-     various name styles. The following additional constraints apply to the
-     assignment of realm names in the domain and X.500 categories: the name
-     of a realm for the domain or X.500 formats must either be used by the
-     organization owning (to whom it was assigned) an Internet domain name
-     or X.500 name, or in the case that no such names are registered,
-     authority to use a realm name may be derived from the authority of the
-     parent realm. For example, if there is no domain name for E40.MIT.EDU,
-     then the administrator of the MIT.EDU realm can authorize the creation
-     of a realm with that name.
-
-     This is acceptable because the organization to which the parent is
-     assigned is presumably the organization authorized to assign names to
-     its children in the X.500 and domain name systems as well. If the
-     parent assigns a realm name without also registering it in the domain
-     name or X.500 hierarchy, it is the parent's responsibility to make sure
-     that there will not in the future exists a name identical to the realm
-     name of the child unless it is assigned to the same entity as the realm
-     name.
-
-     7.2. Principal Names
-
-     As was the case for realm names, conventions are needed to ensure that
-     all agree on what information is implied by a principal name. The
-     name-type field that is part of the principal name indicates the kind
-     of information implied by the name. The name-type should be treated as
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     a hint. Ignoring the name type, no two names can be the same (i.e. at
-     least one of the components, or the realm, must be different). The
-     following name types are defined:
-
- name-type      value   meaning
-
-  NT-UNKNOWN        0  Name type not known
-  NT-PRINCIPAL      1  General principal name (e.g. username, or DCE principal)
-  NT-SRV-INST       2  Service and other unique instance (krbtgt)
-  NT-SRV-HST        3  Service with host name as instance (telnet, rcommands)
-  NT-SRV-XHST       4  Service with slash-separated host name components
-  NT-UID            5  Unique ID
-  NT-X500-PRINCIPAL 6  Encoded X.509 Distingished name [RFC 1779]
-
-     When a name implies no information other than its uniqueness at a
-     particular time the name type PRINCIPAL should be used. The principal
-     name type should be used for users, and it might also be used for a
-     unique server. If the name is a unique machine generated ID that is
-     guaranteed never to be reassigned then the name type of UID should be
-     used (note that it is generally a bad idea to reassign names of any
-     type since stale entries might remain in access control lists).
-
-     If the first component of a name identifies a service and the remaining
-     components identify an instance of the service in a server specified
-     manner, then the name type of SRV-INST should be used. An example of
-     this name type is the Kerberos ticket-granting service whose name has a
-     first component of krbtgt and a second component identifying the realm
-     for which the ticket is valid.
-
-     If instance is a single component following the service name and the
-     instance identifies the host on which the server is running, then the
-     name type SRV-HST should be used. This type is typically used for
-     Internet services such as telnet and the Berkeley R commands. If the
-     separate components of the host name appear as successive components
-     following the name of the service, then the name type SRV-XHST should
-     be used. This type might be used to identify servers on hosts with
-     X.500 names where the slash (/) might otherwise be ambiguous.
-
-     A name type of NT-X500-PRINCIPAL should be used when a name from an
-     X.509 certificiate is translated into a Kerberos name. The encoding of
-     the X.509 name as a Kerberos principal shall conform to the encoding
-     rules specified in RFC 2253.
-
-     A name type of UNKNOWN should be used when the form of the name is not
-     known. When comparing names, a name of type UNKNOWN will match
-     principals authenticated with names of any type. A principal
-     authenticated with a name of type UNKNOWN, however, will only match
-     other names of type UNKNOWN.
-
-     Names of any type with an initial component of 'krbtgt' are reserved
-     for the Kerberos ticket granting service. See section 8.2.3 for the
-     form of such names.
-
-     7.2.1. Name of server principals
-
-     The principal identifier for a server on a host will generally be
-     composed of two parts: (1) the realm of the KDC with which the server
-     is registered, and (2) a two-component name of type NT-SRV-HST if the
-     host name is an Internet domain name or a multi-component name of type
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     NT-SRV-XHST if the name of the host is of a form such as X.500 that
-     allows slash (/) separators. The first component of the two- or
-     multi-component name will identify the service and the latter
-     components will identify the host. Where the name of the host is not
-     case sensitive (for example, with Internet domain names) the name of
-     the host must be lower case. If specified by the application protocol
-     for services such as telnet and the Berkeley R commands which run with
-     system privileges, the first component may be the string 'host' instead
-     of a service specific identifier. 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.
-
-     8. Constants and other defined values
-
-     8.1. Host address types
-
-     All negative values for the host address type are reserved for local
-     use. All non-negative values are reserved for officially assigned type
-     fields and interpretations.
-
-     The values of the types for the following addresses are chosen to match
-     the defined address family constants in the Berkeley Standard
-     Distributions of Unix. They can be found in with symbolic names AF_xxx
-     (where xxx is an abbreviation of the address family name).
-
-     Internet (IPv4) Addresses
-
-     Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
-     MSB order. The type of IPv4 addresses is two (2).
-
-     Internet (IPv6) Addresses [Westerlund]
-
-     IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB order.
-     The type of IPv6 addresses is twenty-four (24). [RFC1883] [RFC1884].
-     The following addresses (see [RFC1884]) MUST not appear in any Kerberos
-     packet:
-        o the Unspecified Address
-        o the Loopback Address
-        o Link-Local addresses
-     IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
-
-     CHAOSnet addresses
-
-     CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB
-     order. The type of CHAOSnet addresses is five (5).
-
-     ISO addresses
-
-     ISO addresses are variable-length. The type of ISO addresses is seven
-     (7).
-
-     Xerox Network Services (XNS) addresses
-
-     XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order.
-     The type of XNS addresses is six (6).
-
-     AppleTalk Datagram Delivery Protocol (DDP) addresses
-
-     AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     network number. The first octet of the address is the node number; the
-     remaining two octets encode the network number in MSB order. The type
-     of AppleTalk DDP addresses is sixteen (16).
-
-     DECnet Phase IV addresses
-
-     DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order.
-     The type of DECnet Phase IV addresses is twelve (12).
-
-     Netbios addresses
-
-     Netbios addresses are 16-octet addresses typically composed of 1 to 15
-     characters, trailing blank (ascii char 20) filled, with a 16th octet of
-     0x0. The type of Netbios addresses is 20 (0x14).
-
-     8.2. KDC messages
-
-     8.2.1. UDP/IP transport
-
-     When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request using
-     UDP IP transport, the client shall send a UDP datagram containing only
-     an encoding of the request to port 88 (decimal) at the KDC's IP
-     address; the KDC will respond with a reply datagram containing only an
-     encoding of the reply message (either a KRB_ERROR or a KRB_KDC_REP) to
-     the sending port at the sender's IP address. Kerberos servers
-     supporting IP transport must accept UDP requests on port 88 (decimal).
-     The response to a request made through UDP/IP transport must also use
-     UDP/IP transport.
-
-     8.2.2. TCP/IP transport [Westerlund,Danielsson]
-
-     Kerberos servers (KDC's) should accept TCP requests on port 88
-     (decimal) and clients should support the sending of TCP requests on
-     port 88 (decimal). When the KRB_KDC_REQ message is sent to the KDC over
-     a TCP stream, a new connection will be established for each
-     authentication exchange (request and response). The KRB_KDC_REP or
-     KRB_ERROR message will be returned to the client on the same TCP stream
-     that was established for the request. The response to a request made
-     through TCP/IP transport must also use TCP/IP transport. Implementors
-     should note that some extentions to the Kerberos protocol will not work
-     if any implementation not supporting the TCP transport is involved
-     (client or KDC). Implementors are strongly urged to support the TCP
-     transport on both the client and server and are advised that the
-     current notation of "should" support will likely change in the future
-     to must support. The KDC may close the TCP stream after sending a
-     response, but may leave the stream open if it expects a followup - in
-     which case it may close the stream at any time if resource constratints
-     or other factors make it desirable to do so. Care must be taken in
-     managing TCP/IP connections with the KDC to prevent denial of service
-     attacks based on the number of TCP/IP connections with the KDC that
-     remain open. If multiple exchanges with the KDC are needed for certain
-     forms of preauthentication, multiple TCP connections may be required. A
-     client may close the stream after receiving response, and should close
-     the stream if it does not expect to send followup messages. The client
-     must be prepared to have the stream closed by the KDC at anytime, in
-     which case it must simply connect again when it is ready to send
-     subsequent messages.
-
-     The first four octets of the TCP stream used to transmit the request
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     request will encode in network byte order the length of the request
-     (KRB_KDC_REQ), and the length will be followed by the request itself.
-     The response will similarly be preceeded by a 4 octet encoding in
-     network byte order of the length of the KRB_KDC_REP or the KRB_ERROR
-     message and will be followed by the KRB_KDC_REP or the KRB_ERROR
-     response. If the sign bit is set on the integer represented by the
-     first 4 octets, then the next 4 octets will be read, extending the
-     length of the field by another 4 octets (less the sign bit which is
-     reserved for future expansion).
-
-     8.2.3. OSI transport
-
-     During authentication of an OSI client to an OSI server, the mutual
-     authentication of an OSI server to an OSI client, the transfer of
-     credentials from an OSI client to an OSI server, or during exchange of
-     private or integrity checked messages, Kerberos protocol messages may
-     be treated as opaque objects and the type of the authentication
-     mechanism will be:
-
-     OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),kerberosv5(2)}
-
-     Depending on the situation, the opaque object will be an authentication
-     header (KRB_AP_REQ), an authentication reply (KRB_AP_REP), a safe
-     message (KRB_SAFE), a private message (KRB_PRIV), or a credentials
-     message (KRB_CRED). The opaque data contains an application code as
-     specified in the ASN.1 description for each message. The application
-     code may be used by Kerberos to determine the message type.
-
-     8.2.3. Name of the TGS
-
-     The principal identifier of the ticket-granting service shall be
-     composed of three parts: (1) the realm of the KDC issuing the TGS
-     ticket (2) a two-part name of type NT-SRV-INST, with the first part
-     "krbtgt" and the second part the name of the realm which will accept
-     the ticket-granting ticket. For example, a ticket-granting ticket
-     issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
-     ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
-     (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting ticket
-     issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
-     MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm),
-     ("krbtgt", "MIT.EDU") (name).
-
-     8.3. Protocol constants and associated values
-
-     The following tables list constants used in the protocol and defines
-     their meanings. Ranges are specified in the "specification" section
-     that limit the values of constants for which values are defined here.
-     This allows implementations to make assumptions about the maximum
-     values that will be received for these constants. Implementation
-     receiving values outside the range specified in the "specification"
-     section may reject the request, but they must recover cleanly.
-
-  Encryption type       etype value block size  minimum pad size  confounder size
-  NULL                           0     1           0                 0
-  des-cbc-crc                    1     8           4                 8
-  des-cbc-md4                    2     8           0                 8
-  des-cbc-md5                    3     8           0                 8
-  <reserved>                     4
-  des3-cbc-md5                   5     8           0                 8
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-  <reserved>                     6
-  des3-cbc-sha1                  7     8           0                 8
-  dsaWithSHA1-CmsOID             9                                 (pkinit)
-  md5WithRSAEncryption-CmsOID   10                                 (pkinit)
-  sha1WithRSAEncryption-CmsOID  11                                 (pkinit)
-  rc2CBC-EnvOID                 12                                 (pkinit)
-  rsaEncryption-EnvOID          13                 (pkinit from PKCS#1 v1.5)
-  rsaES-OAEP-ENV-OID            14                 (pkinit from PKCS#1 v2.0)
-  des-ede3-cbc-Env-OID          15                                 (pkinit)
-  des3-cbc-sha1-kd              16                                 (Tom Yu)
-  rc4-hmac                      23                                 (swift)
-  rc4-hmac-exp                  24                                 (swift)
-
-  ENCTYPE_PK_CROSS              48                      (reserved for pkcross)
-  <reserved>                    0x8003
-
-  Checksum type              sumtype value       checksum size
-  CRC32                      1                   4
-  rsa-md4                    2                   16
-  rsa-md4-des                3                   24
-  des-mac                    4                   16
-  des-mac-k                  5                   8
-  rsa-md4-des-k              6                   16 (drop rsa ?)
-  rsa-md5                    7                   16 (drop rsa ?)
-  rsa-md5-des                8                   24 (drop rsa ?)
-  rsa-md5-des3               9                   24 (drop rsa ?)
-  hmac-sha1-des3-kd          12                  20
-  hmac-sha1-des3             13                  20
-
-  padata type                     padata-type value
-
-  PA-TGS-REQ                      1
-  PA-ENC-TIMESTAMP                2
-  PA-PW-SALT                      3
-  <reserved>                      4
-  PA-ENC-UNIX-TIME                5                  (depricated)
-  PA-SANDIA-SECUREID              6
-  PA-SESAME                       7
-  PA-OSF-DCE                      8
-  PA-CYBERSAFE-SECUREID           9
-  PA-AFS3-SALT                    10
-  PA-ETYPE-INFO                   11
-  PA-SAM-CHALLENGE                12                  (sam/otp)
-  PA-SAM-RESPONSE                 13                  (sam/otp)
-  PA-PK-AS-REQ                    14                  (pkinit)
-  PA-PK-AS-REP                    15                  (pkinit)
-  PA-USE-SPECIFIED-KVNO           20
-  PA-SAM-REDIRECT                 21                  (sam/otp)
-  PA-GET-FROM-TYPED-DATA          22
-  PA-SAM-ETYPE-INFO               23                  (sam/otp)
-
-data-type                     value    form of typed-data
-
-<reserved>                      1-21
-TD-PADATA                       22
-TD-PKINIT-CMS-CERTIFICATES      101      CertificateSet from CMS
-TD-KRB-PRINCIPAL                102
-TD-KRB-REALM                    103
-TD-TRUSTED-CERTIFIERS           104
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-TD-CERTIFICATE-INDEX            105
-
-authorization data type         ad-type value
-AD-IF-RELEVANT                     1
-AD-INTENDED-FOR-SERVER             2
-AD-INTENDED-FOR-APPLICATION-CLASS  3
-AD-KDC-ISSUED                      4
-AD-OR                              5
-AD-MANDATORY-TICKET-EXTENSIONS     6
-AD-IN-TICKET-EXTENSIONS            7
-reserved values                    8-63
-OSF-DCE                            64
-SESAME                             65
-AD-OSF-DCE-PKI-CERTID              66         (hemsath@us.ibm.com)
-
-Ticket Extension Types
-
-TE-TYPE-NULL                  0      Null ticket extension
-TE-TYPE-EXTERNAL-ADATA        1      Integrity protected authorization data
-<reserved>                    2      TE-TYPE-PKCROSS-KDC  (I have reservations)
-TE-TYPE-PKCROSS-CLIENT        3      PKCROSS cross realm key ticket
-TE-TYPE-CYBERSAFE-EXT         4      Assigned to CyberSafe Corp
-<reserved>                    5      TE-TYPE-DEST-HOST (I have reservations)
-
-alternate authentication type   method-type value
-reserved values                 0-63
-ATT-CHALLENGE-RESPONSE          64
-
-transited encoding type         tr-type value
-DOMAIN-X500-COMPRESS            1
-reserved values                 all others
-
-Label               Value   Meaning or MIT code
-
-pvno                    5   current Kerberos protocol version number
-
-message types
-
-KRB_AS_REQ             10   Request for initial authentication
-KRB_AS_REP             11   Response to KRB_AS_REQ request
-KRB_TGS_REQ            12   Request for authentication based on TGT
-KRB_TGS_REP            13   Response to KRB_TGS_REQ request
-KRB_AP_REQ             14   application request to server
-KRB_AP_REP             15   Response to KRB_AP_REQ_MUTUAL
-KRB_SAFE               20   Safe (checksummed) application message
-KRB_PRIV               21   Private (encrypted) application message
-KRB_CRED               22   Private (encrypted) message to forward credentials
-KRB_ERROR              30   Error response
-
-name types
-
-KRB_NT_UNKNOWN        0  Name type not known
-KRB_NT_PRINCIPAL      1  Just the name of the principal as in DCE, or for users
-KRB_NT_SRV_INST       2  Service and other unique instance (krbtgt)
-KRB_NT_SRV_HST        3  Service with host name as instance (telnet, rcommands)
-KRB_NT_SRV_XHST       4  Service with host as remaining components
-KRB_NT_UID            5  Unique ID
-KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-error codes
-
-KDC_ERR_NONE                    0   No error
-KDC_ERR_NAME_EXP                1   Client's entry in database has expired
-KDC_ERR_SERVICE_EXP             2   Server's entry in database has expired
-KDC_ERR_BAD_PVNO                3   Requested prot vers number not supported
-KDC_ERR_C_OLD_MAST_KVNO         4   Client's key encrypted in old master key
-KDC_ERR_S_OLD_MAST_KVNO         5   Server's key encrypted in old master key
-KDC_ERR_C_PRINCIPAL_UNKNOWN     6   Client not found in Kerberos database
-KDC_ERR_S_PRINCIPAL_UNKNOWN     7   Server not found in Kerberos database
-KDC_ERR_PRINCIPAL_NOT_UNIQUE    8   Multiple principal entries in database
-KDC_ERR_NULL_KEY                9   The client or server has a null key
-KDC_ERR_CANNOT_POSTDATE        10   Ticket not eligible for postdating
-KDC_ERR_NEVER_VALID            11   Requested start time is later than end time
-KDC_ERR_POLICY                 12   KDC policy rejects request
-KDC_ERR_BADOPTION              13   KDC cannot accommodate requested option
-KDC_ERR_ETYPE_NOSUPP           14   KDC has no support for encryption type
-KDC_ERR_SUMTYPE_NOSUPP         15   KDC has no support for checksum type
-KDC_ERR_PADATA_TYPE_NOSUPP     16   KDC has no support for padata type
-KDC_ERR_TRTYPE_NOSUPP          17   KDC has no support for transited type
-KDC_ERR_CLIENT_REVOKED         18   Clients credentials have been revoked
-KDC_ERR_SERVICE_REVOKED        19   Credentials for server have been revoked
-KDC_ERR_TGT_REVOKED            20   TGT has been revoked
-KDC_ERR_CLIENT_NOTYET          21   Client not yet valid - try again later
-KDC_ERR_SERVICE_NOTYET         22   Server not yet valid - try again later
-KDC_ERR_KEY_EXPIRED            23   Password has expired - change password
-KDC_ERR_PREAUTH_FAILED         24   Pre-authentication information was invalid
-KDC_ERR_PREAUTH_REQUIRED       25   Additional pre-authenticationrequired [40]
-KDC_ERR_SERVER_NOMATCH         26   Requested server and ticket don't match
-KDC_ERR_MUST_USE_USER2USER     27   Server principal valid for user2user only
-KDC_ERR_PATH_NOT_ACCPETED      28   KDC Policy rejects transited path
-KDC_ERR_SVC_UNAVAILABLE        29   A service is not available
-KRB_AP_ERR_BAD_INTEGRITY       31   Integrity check on decrypted field failed
-KRB_AP_ERR_TKT_EXPIRED         32   Ticket expired
-KRB_AP_ERR_TKT_NYV             33   Ticket not yet valid
-KRB_AP_ERR_REPEAT              34   Request is a replay
-KRB_AP_ERR_NOT_US              35   The ticket isn't for us
-KRB_AP_ERR_BADMATCH            36   Ticket and authenticator don't match
-KRB_AP_ERR_SKEW                37   Clock skew too great
-KRB_AP_ERR_BADADDR             38   Incorrect net address
-KRB_AP_ERR_BADVERSION          39   Protocol version mismatch
-KRB_AP_ERR_MSG_TYPE            40   Invalid msg type
-KRB_AP_ERR_MODIFIED            41   Message stream modified
-KRB_AP_ERR_BADORDER            42   Message out of order
-KRB_AP_ERR_BADKEYVER           44   Specified version of key is not available
-KRB_AP_ERR_NOKEY               45   Service key not available
-KRB_AP_ERR_MUT_FAIL            46   Mutual authentication failed
-KRB_AP_ERR_BADDIRECTION        47   Incorrect message direction
-KRB_AP_ERR_METHOD              48   Alternative authentication method required
-KRB_AP_ERR_BADSEQ              49   Incorrect sequence number in message
-KRB_AP_ERR_INAPP_CKSUM         50   Inappropriate type of checksum in message
-KRB_AP_PATH_NOT_ACCEPTED       51   Policy rejects transited path
-KRB_ERR_RESPONSE_TOO_BIG       52   Response too big for UDP, retry with TCP
-KRB_ERR_GENERIC                60   Generic error (description in e-text)
-KRB_ERR_FIELD_TOOLONG          61   Field is too long for this implementation
-KDC_ERROR_CLIENT_NOT_TRUSTED            62 (pkinit)
-KDC_ERROR_KDC_NOT_TRUSTED               63 (pkinit)
-KDC_ERROR_INVALID_SIG                   64 (pkinit)
-KDC_ERR_KEY_TOO_WEAK                    65 (pkinit)
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-KDC_ERR_CERTIFICATE_MISMATCH            66 (pkinit)
-KRB_AP_ERR_NO_TGT                       67 (user-to-user)
-KDC_ERR_WRONG_REALM                     68 (user-to-user)
-KRB_AP_ERR_USER_TO_USER_REQUIRED        69 (user-to-user)
-KDC_ERR_CANT_VERIFY_CERTIFICATE         70 (pkinit)
-KDC_ERR_INVALID_CERTIFICATE             71 (pkinit)
-KDC_ERR_REVOKED_CERTIFICATE             72 (pkinit)
-KDC_ERR_REVOCATION_STATUS_UNKNOWN       73 (pkinit)
-KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74 (pkinit)
-KDC_ERR_CLIENT_NAME_MISMATCH            75 (pkinit)
-KDC_ERR_KDC_NAME_MISMATCH               76 (pkinit)
-
-     9. Interoperability requirements
-
-     Version 5 of the Kerberos protocol supports a myriad of options. Among
-     these are multiple encryption and checksum types, alternative encoding
-     schemes for the transited field, optional mechanisms for
-     pre-authentication, the handling of tickets with no addresses, options
-     for mutual authentication, user to user authentication, support for
-     proxies, forwarding, postdating, and renewing tickets, the format of
-     realm names, and the handling of authorization data.
-
-     In order to ensure the interoperability of realms, it is necessary to
-     define a minimal configuration which must be supported by all
-     implementations. This minimal configuration is subject to change as
-     technology does. For example, if at some later date it is discovered
-     that one of the required encryption or checksum algorithms is not
-     secure, it will be replaced.
-
-     9.1. Specification 2
-
-     This section defines the second specification of these options.
-     Implementations which are configured in this way can be said to support
-     Kerberos Version 5 Specification 2 (5.1). Specification 1 (depricated)
-     may be found in RFC1510.
-
-     Transport
-
-     TCP/IP and UDP/IP transport must be supported by KDCs claiming
-     conformance to specification 2. Kerberos clients claiming conformance
-     to specification 2 must support UDP/IP transport for messages with the
-     KDC and should support TCP/IP transport.
-
-     Encryption and checksum methods
-
-     The following encryption and checksum mechanisms must be supported.
-     Implementations may support other mechanisms as well, but the
-     additional mechanisms may only be used when communicating with
-     principals known to also support them: This list is to be determined.
-
-     Encryption: DES-CBC-MD5, one triple des variant (tbd)
-     Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 (tbd)
-
-     Realm Names
-
-     All implementations must understand hierarchical realms in both the
-     Internet Domain and the X.500 style. When a ticket granting ticket for
-     an unknown realm is requested, the KDC must be able to determine the
-     names of the intermediate realms between the KDCs realm and the
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     requested realm.
-
-     Transited field encoding
-
-     DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported.
-     Alternative encodings may be supported, but they may be used only when
-     that encoding is supported by ALL intermediate realms.
-
-     Pre-authentication methods
-
-     The TGS-REQ method must be supported. The TGS-REQ method is not used on
-     the initial request. The PA-ENC-TIMESTAMP method must be supported by
-     clients but whether it is enabled by default may be determined on a
-     realm by realm basis. If not used in the initial request and the error
-     KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an
-     acceptable method, the client should retry the initial request using
-     the PA-ENC-TIMESTAMP preauthentication method. Servers need not support
-     the PA-ENC-TIMESTAMP method, but if not supported the server should
-     ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a
-     request.
-
-     Mutual authentication
-
-     Mutual authentication (via the KRB_AP_REP message) must be supported.
-
-     Ticket addresses and flags
-
-     All KDC's must pass on tickets that carry no addresses (i.e. if a TGT
-     contains no addresses, the KDC will return derivative tickets), but
-     each realm may set its own policy for issuing such tickets, and each
-     application server will set its own policy with respect to accepting
-     them.
-
-     Proxies and forwarded tickets must be supported. Individual realms and
-     application servers can set their own policy on when such tickets will
-     be accepted.
-
-     All implementations must recognize renewable and postdated tickets, but
-     need not actually implement them. If these options are not supported,
-     the starttime and endtime in the ticket shall specify a ticket's entire
-     useful life. When a postdated ticket is decoded by a server, all
-     implementations shall make the presence of the postdated flag visible
-     to the calling server.
-
-     User-to-user authentication
-
-     Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC
-     option) must be provided by implementations, but individual realms may
-     decide as a matter of policy to reject such requests on a per-principal
-     or realm-wide basis.
-
-     Authorization data
-
-     Implementations must pass all authorization data subfields from
-     ticket-granting tickets to any derivative tickets unless directed to
-     suppress a subfield as part of the definition of that registered
-     subfield type (it is never incorrect to pass on a subfield, and no
-     registered subfield types presently specify suppression at the KDC).
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     Implementations must make the contents of any authorization data
-     subfields available to the server when a ticket is used.
-     Implementations are not required to allow clients to specify the
-     contents of the authorization data fields.
-
-     Constant ranges
-
-     All protocol constants are constrained to 32 bit (signed) values unless
-     further constrained by the protocol definition. This limit is provided
-     to allow implementations to make assumptions about the maximum values
-     that will be received for these constants. Implementation receiving
-     values outside this range may reject the request, but they must recover
-     cleanly.
-
-     9.2. Recommended KDC values
-
-     Following is a list of recommended values for a KDC implementation,
-     based on the list of suggested configuration constants (see section
-     4.4).
-
-     minimum lifetime              5 minutes
-     maximum renewable lifetime    1 week
-     maximum ticket lifetime       1 day
-     empty addresses               only when suitable  restrictions  appear
-                                   in authorization data
-     proxiable, etc.               Allowed.
-
-     10. REFERENCES
-
-     [NT94]    B. Clifford Neuman and Theodore Y. Ts'o, "An  Authenti-
-               cation  Service for Computer Networks," IEEE Communica-
-               tions Magazine, Vol. 32(9), pp. 33-38 (September 1994).
-
-     [MNSS87]  S. P. Miller, B. C. Neuman, J. I. Schiller, and  J.  H.
-               Saltzer,  Section  E.2.1:  Kerberos  Authentication and
-               Authorization System, M.I.T. Project Athena, Cambridge,
-               Massachusetts (December 21, 1987).
-
-     [SNS88]   J. G. Steiner, B. C. Neuman, and J. I. Schiller,  "Ker-
-               beros:  An Authentication Service for Open Network Sys-
-               tems," pp. 191-202 in  Usenix  Conference  Proceedings,
-               Dallas, Texas (February, 1988).
-
-     [NS78]    Roger M.  Needham  and  Michael  D.  Schroeder,  "Using
-               Encryption for Authentication in Large Networks of Com-
-               puters,"  Communications  of  the  ACM,  Vol.   21(12),
-               pp. 993-999 (December, 1978).
-
-     [DS81]    Dorothy E. Denning and  Giovanni  Maria  Sacco,  "Time-
-               stamps  in  Key Distribution Protocols," Communications
-               of the ACM, Vol. 24(8), pp. 533-536 (August 1981).
-
-     [KNT92]   John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o,
-               "The Evolution of the Kerberos Authentication Service,"
-               in an IEEE Computer Society Text soon to  be  published
-               (June 1992).
-
-     [Neu93]   B.  Clifford  Neuman,  "Proxy-Based  Authorization  and
-               Accounting  for Distributed Systems," in Proceedings of
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-               the 13th International Conference on  Distributed  Com-
-               puting Systems, Pittsburgh, PA (May, 1993).
-
-     [DS90]    Don Davis and Ralph Swick,  "Workstation  Services  and
-               Kerberos  Authentication  at Project Athena," Technical
-               Memorandum TM-424,  MIT Laboratory for Computer Science
-               (February 1990).
-
-     [LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E.  Som-
-               merfeld,  and  K. Raeburn, Section E.1: Service Manage-
-               ment System, M.I.T.  Project  Athena,  Cambridge,  Mas-
-               sachusetts (1987).
-
-     [X509-88] CCITT, Recommendation X.509: The Directory  Authentica-
-               tion Framework, December 1988.
-
-     [Pat92].  J. Pato, Using  Pre-Authentication  to  Avoid  Password
-               Guessing  Attacks, Open Software Foundation DCE Request
-               for Comments 26 (December 1992).
-
-     [DES77]   National Bureau of Standards, U.S. Department  of  Com-
-               merce,  "Data Encryption Standard," Federal Information
-               Processing Standards Publication  46,   Washington,  DC
-               (1977).
-
-     [DESM80]  National Bureau of Standards, U.S. Department  of  Com-
-               merce,  "DES  Modes  of Operation," Federal Information
-               Processing Standards Publication 81,   Springfield,  VA
-               (December 1980).
-
-     [SG92]    Stuart G. Stubblebine and Virgil D. Gligor, "On Message
-               Integrity  in  Cryptographic Protocols," in Proceedings
-               of the IEEE  Symposium  on  Research  in  Security  and
-               Privacy, Oakland, California (May 1992).
-
-     [IS3309]  International Organization  for  Standardization,  "ISO
-               Information  Processing  Systems - Data Communication -
-               High-Level Data Link Control Procedure -  Frame  Struc-
-               ture," IS 3309 (October 1984).  3rd Edition.
-
-     [MD4-92]  R. Rivest, "The  MD4  Message  Digest  Algorithm,"  RFC
-               1320,   MIT  Laboratory  for  Computer  Science  (April
-               1992).
-
-     [MD5-92]  R. Rivest, "The  MD5  Message  Digest  Algorithm,"  RFC
-               1321,   MIT  Laboratory  for  Computer  Science  (April
-               1992).
-
-     [KBC96]   H. Krawczyk, M. Bellare, and R. Canetti, "HMAC:  Keyed-
-               Hashing  for  Message  Authentication,"  Working  Draft
-               draft-ietf-ipsec-hmac-md5-01.txt,   (August 1996).
-
-     [Horowitz96] Horowitz, M., "Key Derivation for Authentication,
-               Integrity, and Privacy", draft-horowitz-key-derivation-02.txt,
-               August 1998.
-
-     [HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft-
-               horowitz-kerb-key-derivation-01.txt, September 1998.
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC:
-               Keyed-Hashing for Message Authentication", draft-ietf-ipsec-hmac-
-               md5-01.txt, August, 1996.
-
-     A. Pseudo-code for protocol processing
-
-     This appendix provides pseudo-code describing how the messages are to
-     be constructed and interpreted by clients and servers.
-
-     A.1. KRB_AS_REQ generation
-
-             request.pvno := protocol version; /* pvno = 5 */
-             request.msg-type := message type; /* type = KRB_AS_REQ */
-
-             if(pa_enc_timestamp_required) then
-                     request.padata.padata-type = PA-ENC-TIMESTAMP;
-                     get system_time;
-                     padata-body.patimestamp,pausec = system_time;
-                     encrypt padata-body into request.padata.padata-value
-                             using client.key; /* derived from password */
-             endif
-
-             body.kdc-options := users's preferences;
-             body.cname := user's name;
-             body.realm := user's realm;
-             body.sname := service's name; /* usually "krbtgt", 
-                                              "localrealm" */
-
-             if (body.kdc-options.POSTDATED is set) then
-                     body.from := requested starting time;
-             else
-                     omit body.from;
-             endif
-             body.till := requested end time;
-             if (body.kdc-options.RENEWABLE is set) then
-                     body.rtime := requested final renewal time;
-             endif
-             body.nonce := random_nonce();
-             body.etype := requested etypes;
-             if (user supplied addresses) then
-                     body.addresses := user's addresses;
-             else
-                     omit body.addresses;
-             endif
-             omit body.enc-authorization-data;
-             request.req-body := body;
-
-             kerberos := lookup(name of local kerberos server (or servers));
-             send(packet,kerberos);
-
-             wait(for response);
-             if (timed_out) then
-                     retry or use alternate server;
-             endif
-
-     A.2. KRB_AS_REQ verification and KRB_AS_REP generation
-
-             decode message into req;
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-             client := lookup(req.cname,req.realm);
-             server := lookup(req.sname,req.realm);
-
-             get system_time;
-             kdc_time := system_time.seconds;
-
-             if (!client) then
-                     /* no client in Database */
-                     error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
-             endif
-             if (!server) then
-                     /* no server in Database */
-                     error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
-             endif
-
-             if(client.pa_enc_timestamp_required and
-                pa_enc_timestamp not present) then
-                     error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
-             endif
-
-             if(pa_enc_timestamp present) then
-                     decrypt req.padata-value into decrypted_enc_timestamp
-                             using client.key;
-                             using auth_hdr.authenticator.subkey;
-                     if (decrypt_error()) then
-                             error_out(KRB_AP_ERR_BAD_INTEGRITY);
-                     if(decrypted_enc_timestamp is not within allowable skew) 
-                         then
-                             error_out(KDC_ERR_PREAUTH_FAILED);
-                     endif
-                     if(decrypted_enc_timestamp and usec is replay)
-                             error_out(KDC_ERR_PREAUTH_FAILED);
-                     endif
-                     add decrypted_enc_timestamp and usec to replay cache;
-             endif
-
-             use_etype := first supported etype in req.etypes;
-
-             if (no support for req.etypes) then
-                     error_out(KDC_ERR_ETYPE_NOSUPP);
-             endif
-
-             new_tkt.vno := ticket version; /* = 5 */
-             new_tkt.sname := req.sname;
-             new_tkt.srealm := req.srealm;
-             reset all flags in new_tkt.flags;
-
-             /* It should be noted that local policy may affect the  */
-             /* processing of any of these flags.  For example, some */
-             /* realms may refuse to issue renewable tickets         */
-
-             if (req.kdc-options.FORWARDABLE is set) then
-                     set new_tkt.flags.FORWARDABLE;
-             endif
-             if (req.kdc-options.PROXIABLE is set) then
-                     set new_tkt.flags.PROXIABLE;
-             endif
-
-             if (req.kdc-options.ALLOW-POSTDATE is set) then
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                     set new_tkt.flags.MAY-POSTDATE;
-             endif
-             if ((req.kdc-options.RENEW is set) or
-                 (req.kdc-options.VALIDATE is set) or
-                 (req.kdc-options.PROXY is set) or
-                 (req.kdc-options.FORWARDED is set) or
-                 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
-                     error_out(KDC_ERR_BADOPTION);
-             endif
-
-             new_tkt.session := random_session_key();
-             new_tkt.cname := req.cname;
-             new_tkt.crealm := req.crealm;
-             new_tkt.transited := empty_transited_field();
-
-             new_tkt.authtime := kdc_time;
-
-             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 omitted */
-             endif
-             if (req.till = 0) then
-                     till := infinity;
-             else
-                     till := req.till;
-             endif
-
-             new_tkt.endtime := min(till,
-                                   new_tkt.starttime+client.max_life,
-                                   new_tkt.starttime+server.max_life,
-                                   new_tkt.starttime+max_life_for_realm);
-
-             if ((req.kdc-options.RENEWABLE-OK is set) and
-                 (new_tkt.endtime < req.till)) then
-                     /* we set the RENEWABLE option for later processing */
-                     set req.kdc-options.RENEWABLE;
-                     req.rtime := req.till;
-             endif
-
-             if (req.rtime = 0) then
-                     rtime := infinity;
-             else
-                     rtime := req.rtime;
-             endif
-
-             if (req.kdc-options.RENEWABLE is set) then
-                     set new_tkt.flags.RENEWABLE;
-                     new_tkt.renew-till := min(rtime,
-                                     new_tkt.starttime+client.max_rlife,
-                                     new_tkt.starttime+server.max_rlife,
-                                     new_tkt.starttime+max_rlife_for_realm);
-             else
-                     omit new_tkt.renew-till; /* only present if RENEWABLE */
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-             endif
-
-             if (req.addresses) then
-                     new_tkt.caddr := req.addresses;
-             else
-                     omit new_tkt.caddr;
-             endif
-
-             new_tkt.authorization_data := empty_authorization_data();
-
-             encode to-be-encrypted part of ticket into OCTET STRING;
-             new_tkt.enc-part := encrypt OCTET STRING
-                  using etype_for_key(server.key), server.key, server.p_kvno;
-
-             /* Start processing the response */
-
-             resp.pvno := 5;
-             resp.msg-type := KRB_AS_REP;
-             resp.cname := req.cname;
-             resp.crealm := req.realm;
-             resp.ticket := new_tkt;
-
-             resp.key := new_tkt.session;
-             resp.last-req := fetch_last_request_info(client);
-             resp.nonce := req.nonce;
-             resp.key-expiration := client.expiration;
-             resp.flags := new_tkt.flags;
-
-             resp.authtime := new_tkt.authtime;
-             resp.starttime := new_tkt.starttime;
-             resp.endtime := new_tkt.endtime;
-
-             if (new_tkt.flags.RENEWABLE) then
-                     resp.renew-till := new_tkt.renew-till;
-             endif
-
-             resp.realm := new_tkt.realm;
-             resp.sname := new_tkt.sname;
-
-             resp.caddr := new_tkt.caddr;
-
-             encode body of reply into OCTET STRING;
-
-             resp.enc-part := encrypt OCTET STRING
-                              using use_etype, client.key, client.p_kvno;
-             send(resp);
-
-     A.3. KRB_AS_REP verification
-
-             decode response into resp;
-
-             if (resp.msg-type = KRB_ERROR) then
-                  if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP)) then
-                             set pa_enc_timestamp_required;
-                             goto KRB_AS_REQ;
-                     endif
-                     process_error(resp);
-                     return;
-             endif
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-
-             /* On error, discard the response, and zero the session key */
-             /* from the response immediately */
-
-             key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
-                                      resp.padata);
-             unencrypted part of resp := decode of decrypt of resp.enc-part
-                                     using resp.enc-part.etype and key;
-             zero(key);
-
-             if (common_as_rep_tgs_rep_checks fail) then
-                     destroy resp.key;
-                     return error;
-             endif
-
-             if near(resp.princ_exp) then
-                     print(warning message);
-             endif
-             save_for_later(ticket,session,client,server,times,flags);
-
-     A.4. KRB_AS_REP and KRB_TGS_REP common checks
-
-             if (decryption_error() or
-                 (req.cname != resp.cname) or
-                 (req.realm != resp.crealm) or
-                 (req.sname != resp.sname) or
-                 (req.realm != resp.realm) or
-                 (req.nonce != resp.nonce) or
-                 (req.addresses != resp.caddr)) then
-                     destroy resp.key;
-                     return KRB_AP_ERR_MODIFIED;
-             endif
-
-      /* make sure no flags are set that shouldn't be, and that all that */
-      /* should be are set                                               */
-         if (!check_flags_for_compatability(req.kdc-options,resp.flags)) then
-                     destroy resp.key;
-                     return KRB_AP_ERR_MODIFIED;
-             endif
-
-             if ((req.from = 0) and
-                 (resp.starttime is not within allowable skew)) then
-                     destroy resp.key;
-                     return KRB_AP_ERR_SKEW;
-             endif
-             if ((req.from != 0) and (req.from != resp.starttime)) then
-                     destroy resp.key;
-                     return KRB_AP_ERR_MODIFIED;
-             endif
-             if ((req.till != 0) and (resp.endtime > req.till)) then
-                     destroy resp.key;
-                     return KRB_AP_ERR_MODIFIED;
-             endif
-
-             if ((req.kdc-options.RENEWABLE is set) and
-                 (req.rtime != 0) and (resp.renew-till > req.rtime)) then
-                     destroy resp.key;
-                     return KRB_AP_ERR_MODIFIED;
-             endif
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-             if ((req.kdc-options.RENEWABLE-OK is set) and
-                 (resp.flags.RENEWABLE) and
-                 (req.till != 0) and
-                 (resp.renew-till > req.till)) then
-                     destroy resp.key;
-                     return KRB_AP_ERR_MODIFIED;
-             endif
-
-     A.5. KRB_TGS_REQ generation
-
-       /* Note that make_application_request might have to recursivly     */
-       /* call this routine to get the appropriate ticket-granting ticket */
-
-             request.pvno := protocol version; /* pvno = 5 */
-             request.msg-type := message type; /* type = KRB_TGS_REQ */
-
-             body.kdc-options := users's preferences;
-             /* If the TGT is not for the realm of the end-server  */
-             /* then the sname will be for a TGT for the end-realm */
-             /* and the realm of the requested ticket (body.realm) */
-             /* will be that of the TGS to which the TGT we are    */
-             /* sending applies                                    */
-             body.sname := service's name;
-             body.realm := service's realm;
-
-             if (body.kdc-options.POSTDATED is set) then
-                     body.from := requested starting time;
-             else
-                     omit body.from;
-             endif
-             body.till := requested end time;
-             if (body.kdc-options.RENEWABLE is set) then
-                     body.rtime := requested final renewal time;
-             endif
-             body.nonce := random_nonce();
-             body.etype := requested etypes;
-             if (user supplied addresses) then
-                     body.addresses := user's addresses;
-             else
-                     omit body.addresses;
-             endif
-
-             body.enc-authorization-data := user-supplied data;
-             if (body.kdc-options.ENC-TKT-IN-SKEY) then
-                     body.additional-tickets_ticket := second TGT;
-             endif
-
-             request.req-body := body;
-             check := generate_checksum (req.body,checksumtype);
-
-             request.padata[0].padata-type := PA-TGS-REQ;
-             request.padata[0].padata-value := create a KRB_AP_REQ using
-                                           the TGT and checksum
-
-             /* add in any other padata as required/supplied */
-
-             kerberos := lookup(name of local kerberose server (or servers));
-             send(packet,kerberos);
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-             wait(for response);
-             if (timed_out) then
-                     retry or use alternate server;
-             endif
-
-     A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation
-
-             /* note that reading the application request requires first
-             determining the server for which a ticket was issued, and
-             choosing the correct key for decryption.  The name of the
-             server appears in the plaintext part of the ticket. */
-
-             if (no KRB_AP_REQ in req.padata) then
-                     error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
-             endif
-             verify KRB_AP_REQ in req.padata;
-
-             /* Note that the realm in which the Kerberos server is
-             operating is determined by the instance from the
-             ticket-granting ticket.  The realm in the ticket-granting
-             ticket is the realm under which the ticket granting
-             ticket was issued.  It is possible for a single Kerberos 
-             server to support more than one realm. */
-
-             auth_hdr := KRB_AP_REQ;
-             tgt := auth_hdr.ticket;
-
-             if (tgt.sname is not a TGT for local realm and is not req.sname) 
-                   then
-                     error_out(KRB_AP_ERR_NOT_US);
-
-             realm := realm_tgt_is_for(tgt);
-
-             decode remainder of request;
-
-             if (auth_hdr.authenticator.cksum is missing) then
-                     error_out(KRB_AP_ERR_INAPP_CKSUM);
-             endif
-
-             if (auth_hdr.authenticator.cksum type is not supported) then
-                     error_out(KDC_ERR_SUMTYPE_NOSUPP);
-             endif
-             if (auth_hdr.authenticator.cksum is not both collision-proof 
-                 and keyed) then
-                     error_out(KRB_AP_ERR_INAPP_CKSUM);
-             endif
-
-             set computed_checksum := checksum(req);
-             if (computed_checksum != auth_hdr.authenticatory.cksum) then
-                     error_out(KRB_AP_ERR_MODIFIED);
-             endif
-
-             server := lookup(req.sname,realm);
-
-             if (!server) then
-                     if (is_foreign_tgt_name(req.sname)) then
-                             server := best_intermediate_tgs(req.sname);
-                     else
-                             /* no server in Database */
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                             error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
-                     endif
-             endif
-
-             session := generate_random_session_key();
-
-             use_etype := first supported etype in req.etypes;
-
-             if (no support for req.etypes) then
-                     error_out(KDC_ERR_ETYPE_NOSUPP);
-             endif
-
-             new_tkt.vno := ticket version; /* = 5 */
-             new_tkt.sname := req.sname;
-             new_tkt.srealm := realm;
-             reset all flags in new_tkt.flags;
-
-             /* It should be noted that local policy may affect the  */
-             /* processing of any of these flags.  For example, some */
-             /* realms may refuse to issue renewable tickets         */
-
-             new_tkt.caddr := tgt.caddr;
-             resp.caddr := NULL; /* We only include this if they change */
-             if (req.kdc-options.FORWARDABLE is set) then
-                     if (tgt.flags.FORWARDABLE is reset) then
-                             error_out(KDC_ERR_BADOPTION);
-                     endif
-                     set new_tkt.flags.FORWARDABLE;
-             endif
-             if (req.kdc-options.FORWARDED is set) then
-                     if (tgt.flags.FORWARDABLE is reset) then
-                             error_out(KDC_ERR_BADOPTION);
-                     endif
-                     set new_tkt.flags.FORWARDED;
-                     new_tkt.caddr := req.addresses;
-                     resp.caddr := req.addresses;
-             endif
-             if (tgt.flags.FORWARDED is set) then
-                     set new_tkt.flags.FORWARDED;
-             endif
-
-             if (req.kdc-options.PROXIABLE is set) then
-                     if (tgt.flags.PROXIABLE is reset)
-                             error_out(KDC_ERR_BADOPTION);
-                     endif
-                     set new_tkt.flags.PROXIABLE;
-             endif
-             if (req.kdc-options.PROXY is set) then
-                     if (tgt.flags.PROXIABLE is reset) then
-                             error_out(KDC_ERR_BADOPTION);
-                     endif
-                     set new_tkt.flags.PROXY;
-                     new_tkt.caddr := req.addresses;
-                     resp.caddr := req.addresses;
-             endif
-
-             if (req.kdc-options.ALLOW-POSTDATE is set) then
-                     if (tgt.flags.MAY-POSTDATE is reset)
-                             error_out(KDC_ERR_BADOPTION);
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                     endif
-                     set new_tkt.flags.MAY-POSTDATE;
-             endif
-             if (req.kdc-options.POSTDATED is set) then
-                     if (tgt.flags.MAY-POSTDATE is reset) then
-                             error_out(KDC_ERR_BADOPTION);
-                     endif
-                     set new_tkt.flags.POSTDATED;
-                     set new_tkt.flags.INVALID;
-                     if (against_postdate_policy(req.from)) then
-                             error_out(KDC_ERR_POLICY);
-                     endif
-                     new_tkt.starttime := req.from;
-             endif
-
-             if (req.kdc-options.VALIDATE is set) then
-                     if (tgt.flags.INVALID is reset) then
-                             error_out(KDC_ERR_POLICY);
-                     endif
-                     if (tgt.starttime > kdc_time) then
-                             error_out(KRB_AP_ERR_NYV);
-                     endif
-                     if (check_hot_list(tgt)) then
-                             error_out(KRB_AP_ERR_REPEAT);
-                     endif
-                     tkt := tgt;
-                     reset new_tkt.flags.INVALID;
-             endif
-
-             if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
-                                  and those already processed) is set) then
-                     error_out(KDC_ERR_BADOPTION);
-             endif
-
-             new_tkt.authtime := tgt.authtime;
-
-             if (req.kdc-options.RENEW is set) then
-      /* Note that if the endtime has already passed, the ticket would  */
-      /* have been rejected in the initial authentication stage, so     */
-      /* there is no need to check again here                           */
-                     if (tgt.flags.RENEWABLE is reset) then
-                             error_out(KDC_ERR_BADOPTION);
-                     endif
-                     if (tgt.renew-till < kdc_time) then
-                             error_out(KRB_AP_ERR_TKT_EXPIRED);
-                     endif
-                     tkt := tgt;
-                     new_tkt.starttime := kdc_time;
-                     old_life := tgt.endttime - tgt.starttime;
-                     new_tkt.endtime := min(tgt.renew-till,
-                                            new_tkt.starttime + old_life);
-             else
-                     new_tkt.starttime := kdc_time;
-                     if (req.till = 0) then
-                             till := infinity;
-                     else
-                             till := req.till;
-                     endif
-                     new_tkt.endtime := min(till,
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                                            new_tkt.starttime+client.max_life,
-                                            new_tkt.starttime+server.max_life,
-                                            new_tkt.starttime+max_life_for_realm,
-                                            tgt.endtime);
-
-                     if ((req.kdc-options.RENEWABLE-OK is set) and
-                         (new_tkt.endtime < req.till) and
-                         (tgt.flags.RENEWABLE is set) then
-                             /* we set the RENEWABLE option for later processing */
-                             set req.kdc-options.RENEWABLE;
-                             req.rtime := min(req.till, tgt.renew-till);
-                     endif
-             endif
-
-             if (req.rtime = 0) then
-                     rtime := infinity;
-             else
-                     rtime := req.rtime;
-             endif
-
-             if ((req.kdc-options.RENEWABLE is set) and
-                 (tgt.flags.RENEWABLE is set)) then
-                     set new_tkt.flags.RENEWABLE;
-                     new_tkt.renew-till := min(rtime,
-                                       new_tkt.starttime+client.max_rlife,
-                                       new_tkt.starttime+server.max_rlife,
-                                       new_tkt.starttime+max_rlife_for_realm,
-                                       tgt.renew-till);
-             else
-                     new_tkt.renew-till := OMIT; /* leave the
-                                                   renew-till field out */ 
-             endif
-             if (req.enc-authorization-data is present) then
-                     decrypt req.enc-authorization-data into
-                                  decrypted_authorization_data
-                             using auth_hdr.authenticator.subkey;
-                     if (decrypt_error()) then
-                             error_out(KRB_AP_ERR_BAD_INTEGRITY);
-                     endif
-             endif
-             new_tkt.authorization_data :=
-                     req.auth_hdr.ticket.authorization_data + 
-                                      decrypted_authorization_data;
-
-             new_tkt.key := session;
-             new_tkt.crealm := tgt.crealm;
-             new_tkt.cname := req.auth_hdr.ticket.cname;
-
-             if (realm_tgt_is_for(tgt) := tgt.realm) then
-                     /* tgt issued by local realm */
-                     new_tkt.transited := tgt.transited;
-             else
-                     /* was issued for this realm by some other realm */
-                     if (tgt.transited.tr-type not supported) then
-                             error_out(KDC_ERR_TRTYPE_NOSUPP);
-                     endif
-                     new_tkt.transited :=
-                         compress_transited(tgt.transited + tgt.realm) 
-                     /* Don't check tranited field if TGT for foreign realm,
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                      * or requested not to check */
-                     if (is_not_foreign_tgt_name(new_tkt.server)
-                        && req.kdc-options.DISABLE-TRANSITED-CHECK not
-                             set) then 
-                          /* Check it, so end-server does not have to
-                           * but don't fail, end-server may still accept it */
-                          if (check_transited_field(new_tkt.transited) == OK)
-                                   set new_tkt.flags.TRANSITED-POLICY-CHECKED;
-                             endif
-                     endif
-             endif
-
-             encode encrypted part of new_tkt into OCTET STRING;
-             if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
-                     if (server not specified) then
-                             server = req.second_ticket.client;
-                     endif
-                     if ((req.second_ticket is not a TGT) or
-                         (req.second_ticket.client != server)) then
-                             error_out(KDC_ERR_POLICY);
-                     endif
-
-                     new_tkt.enc-part := encrypt OCTET STRING using
-                             using etype_for_key(second-ticket.key),
-                             second-ticket.key; 
-             else
-                     new_tkt.enc-part := encrypt OCTET STRING
-                             using etype_for_key(server.key),
-                             server.key, server.p_kvno; 
-             endif
-
-             resp.pvno := 5;
-             resp.msg-type := KRB_TGS_REP;
-             resp.crealm := tgt.crealm;
-             resp.cname := tgt.cname;
-             resp.ticket := new_tkt;
-
-             resp.key := session;
-             resp.nonce := req.nonce;
-             resp.last-req := fetch_last_request_info(client);
-             resp.flags := new_tkt.flags;
-
-             resp.authtime := new_tkt.authtime;
-             resp.starttime := new_tkt.starttime;
-             resp.endtime := new_tkt.endtime;
-
-             omit resp.key-expiration;
-
-             resp.sname := new_tkt.sname;
-             resp.realm := new_tkt.realm;
-
-             if (new_tkt.flags.RENEWABLE) then
-                     resp.renew-till := new_tkt.renew-till;
-             endif
-
-             encode body of reply into OCTET STRING;
-
-             if (req.padata.authenticator.subkey)
-                     resp.enc-part := encrypt OCTET STRING using use_etype,
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                             req.padata.authenticator.subkey;
-             else resp.enc-part := encrypt OCTET STRING using
-                                         use_etype, tgt.key; 
-
-             send(resp);
-
-     A.7. KRB_TGS_REP verification
-
-             decode response into resp;
-
-             if (resp.msg-type = KRB_ERROR) then
-                     process_error(resp);
-                     return;
-             endif
-
-             /* On error, discard the response, and zero the session key from
-             the response immediately */
-
-             if (req.padata.authenticator.subkey)
-                     unencrypted part of resp := decode of decrypt of
-                             resp.enc-part 
-                             using resp.enc-part.etype and subkey;
-             else unencrypted part of resp := decode of decrypt of
-                              resp.enc-part 
-                                     using resp.enc-part.etype and
-                                      tgt's session key; 
-             if (common_as_rep_tgs_rep_checks fail) then
-                     destroy resp.key;
-                     return error;
-             endif
-
-             check authorization_data as necessary;
-             save_for_later(ticket,session,client,server,times,flags);
-
-     A.8. Authenticator generation
-
-             body.authenticator-vno := authenticator vno; /* = 5 */
-             body.cname, body.crealm := client name;
-             if (supplying checksum) then
-                     body.cksum := checksum;
-             endif
-             get system_time;
-             body.ctime, body.cusec := system_time;
-             if (selecting sub-session key) then
-                     select sub-session key;
-                     body.subkey := sub-session key;
-             endif
-             if (using sequence numbers) then
-                     select initial sequence number;
-                     body.seq-number := initial sequence;
-             endif
-
-     A.9. KRB_AP_REQ generation
-
-             obtain ticket and session_key from cache;
-
-             packet.pvno := protocol version; /* 5 */
-             packet.msg-type := message type; /* KRB_AP_REQ */
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-             if (desired(MUTUAL_AUTHENTICATION)) then
-                     set packet.ap-options.MUTUAL-REQUIRED;
-             else
-                     reset packet.ap-options.MUTUAL-REQUIRED;
-             endif
-             if (using session key for ticket) then
-                     set packet.ap-options.USE-SESSION-KEY;
-             else
-                     reset packet.ap-options.USE-SESSION-KEY;
-             endif
-             packet.ticket := ticket; /* ticket */
-             generate authenticator;
-             encode authenticator into OCTET STRING;
-             encrypt OCTET STRING into packet.authenticator using session_key;
-
-     A.10. KRB_AP_REQ verification
-
-             receive packet;
-             if (packet.pvno != 5) then
-                     either process using other protocol spec
-                     or error_out(KRB_AP_ERR_BADVERSION);
-             endif
-             if (packet.msg-type != KRB_AP_REQ) then
-                     error_out(KRB_AP_ERR_MSG_TYPE);
-             endif
-             if (packet.ticket.tkt_vno != 5) then
-                     either process using other protocol spec
-                     or error_out(KRB_AP_ERR_BADVERSION);
-             endif
-             if (packet.ap_options.USE-SESSION-KEY is set) then
-                     retrieve session key from ticket-granting ticket for
-                      packet.ticket.{sname,srealm,enc-part.etype};
-             else
-                     retrieve service key for
-                   packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno}; 
-             endif
-             if (no_key_available) then
-                     if (cannot_find_specified_skvno) then
-                             error_out(KRB_AP_ERR_BADKEYVER);
-                     else
-                             error_out(KRB_AP_ERR_NOKEY);
-                     endif
-             endif
-             decrypt packet.ticket.enc-part into decr_ticket using
-                      retrieved key; 
-             if (decryption_error()) then
-                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
-             endif
-             decrypt packet.authenticator into decr_authenticator
-                     using decr_ticket.key;
-             if (decryption_error()) then
-                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
-             endif
-             if (decr_authenticator.{cname,crealm} !=
-                 decr_ticket.{cname,crealm}) then
-                     error_out(KRB_AP_ERR_BADMATCH);
-             endif
-             if (decr_ticket.caddr is present) then
-                     if (sender_address(packet) is not in
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                                    decr_ticket.caddr) then 
-                             error_out(KRB_AP_ERR_BADADDR);
-                     endif
-             elseif (application requires addresses) then
-                     error_out(KRB_AP_ERR_BADADDR);
-             endif
-             if (not in_clock_skew(decr_authenticator.ctime,
-                                   decr_authenticator.cusec)) then
-                     error_out(KRB_AP_ERR_SKEW);
-             endif
-             if (repeated(decr_authenticator.{ctime,cusec,cname,crealm})) then
-                     error_out(KRB_AP_ERR_REPEAT);
-             endif
-             save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
-             get system_time;
-             if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
-                 (decr_ticket.flags.INVALID is set)) then
-                     /* it hasn't yet become valid */
-                     error_out(KRB_AP_ERR_TKT_NYV);
-             endif
-             if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
-                     error_out(KRB_AP_ERR_TKT_EXPIRED);
-             endif
-             if (decr_ticket.transited) then
-                 /* caller may ignore the TRANSITED-POLICY-CHECKED and do
-                  * check anyway */
-                 if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set) then
-                      if (check_transited_field(decr_ticket.transited) then
-                           error_out(KDC_AP_PATH_NOT_ACCPETED);
-                      endif
-                 endif
-             endif
-           /* caller must check decr_ticket.flags for any pertinent details */
-           return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
-
-     A.11. KRB_AP_REP generation
-
-             packet.pvno := protocol version; /* 5 */
-             packet.msg-type := message type; /* KRB_AP_REP */
-
-             body.ctime := packet.ctime;
-             body.cusec := packet.cusec;
-             if (selecting sub-session key) then
-                     select sub-session key;
-                     body.subkey := sub-session key;
-             endif
-             if (using sequence numbers) then
-                     select initial sequence number;
-                     body.seq-number := initial sequence;
-             endif
-
-             encode body into OCTET STRING;
-
-             select encryption type;
-             encrypt OCTET STRING into packet.enc-part;
-
-     A.12. KRB_AP_REP verification
-
-             receive packet;
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-             if (packet.pvno != 5) then
-                     either process using other protocol spec
-                     or error_out(KRB_AP_ERR_BADVERSION);
-             endif
-             if (packet.msg-type != KRB_AP_REP) then
-                     error_out(KRB_AP_ERR_MSG_TYPE);
-             endif
-             cleartext := decrypt(packet.enc-part) using ticket's session key;
-             if (decryption_error()) then
-                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
-             endif
-             if (cleartext.ctime != authenticator.ctime) then
-                     error_out(KRB_AP_ERR_MUT_FAIL);
-             endif
-             if (cleartext.cusec != authenticator.cusec) then
-                     error_out(KRB_AP_ERR_MUT_FAIL);
-             endif
-             if (cleartext.subkey is present) then
-                     save cleartext.subkey for future use;
-             endif
-             if (cleartext.seq-number is present) then
-                     save cleartext.seq-number for future verifications;
-             endif
-             return(AUTHENTICATION_SUCCEEDED);
-
-     A.13. KRB_SAFE generation
-
-             collect user data in buffer;
-
-             /* assemble packet: */
-             packet.pvno := protocol version; /* 5 */
-             packet.msg-type := message type; /* KRB_SAFE */
-
-             body.user-data := buffer; /* DATA */
-             if (using timestamp) then
-                     get system_time;
-                     body.timestamp, body.usec := system_time;
-             endif
-             if (using sequence numbers) then
-                     body.seq-number := sequence number;
-             endif
-             body.s-address := sender host addresses;
-             if (only one recipient) then
-                     body.r-address := recipient host address;
-             endif
-             checksum.cksumtype := checksum type;
-             compute checksum over body;
-             checksum.checksum := checksum value; /* checksum.checksum */
-             packet.cksum := checksum;
-             packet.safe-body := body;
-
-     A.14. KRB_SAFE verification
-
-             receive packet;
-             if (packet.pvno != 5) then
-                     either process using other protocol spec
-                     or error_out(KRB_AP_ERR_BADVERSION);
-             endif
-             if (packet.msg-type != KRB_SAFE) then
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                     error_out(KRB_AP_ERR_MSG_TYPE);
-             endif
-             if (packet.checksum.cksumtype is not both collision-proof
-                 and keyed) then 
-                     error_out(KRB_AP_ERR_INAPP_CKSUM);
-             endif
-             if (safe_priv_common_checks_ok(packet)) then
-                     set computed_checksum := checksum(packet.body);
-                     if (computed_checksum != packet.checksum) then
-                             error_out(KRB_AP_ERR_MODIFIED);
-                     endif
-                     return (packet, PACKET_IS_GENUINE);
-             else
-                     return common_checks_error;
-             endif
-
-     A.15. KRB_SAFE and KRB_PRIV common checks
-
-             if (packet.s-address != O/S_sender(packet)) then
-                     /* O/S report of sender not who claims to have sent it */
-                     error_out(KRB_AP_ERR_BADADDR);
-             endif
-             if ((packet.r-address is present) and
-                 (packet.r-address != local_host_address)) then
-                     /* was not sent to proper place */
-                     error_out(KRB_AP_ERR_BADADDR);
-             endif
-             if (((packet.timestamp is present) and
-                  (not in_clock_skew(packet.timestamp,packet.usec))) or
-                 (packet.timestamp is not present and timestamp expected)) then
-                     error_out(KRB_AP_ERR_SKEW);
-             endif
-             if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
-                     error_out(KRB_AP_ERR_REPEAT);
-             endif
-
-             if (((packet.seq-number is present) and
-                  ((not in_sequence(packet.seq-number)))) or
-                 (packet.seq-number is not present and sequence expected)) then
-                     error_out(KRB_AP_ERR_BADORDER);
-             endif
-             if (packet.timestamp not present and packet.seq-number
-                   not present) then 
-                     error_out(KRB_AP_ERR_MODIFIED);
-             endif
-
-             save_identifier(packet.{timestamp,usec,s-address},
-                             sender_principal(packet));
-
-             return PACKET_IS_OK;
-
-     A.16. KRB_PRIV generation
-
-             collect user data in buffer;
-
-             /* assemble packet: */
-             packet.pvno := protocol version; /* 5 */
-             packet.msg-type := message type; /* KRB_PRIV */
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-             packet.enc-part.etype := encryption type;
-
-             body.user-data := buffer;
-             if (using timestamp) then
-                     get system_time;
-                     body.timestamp, body.usec := system_time;
-             endif
-             if (using sequence numbers) then
-                     body.seq-number := sequence number;
-             endif
-             body.s-address := sender host addresses;
-             if (only one recipient) then
-                     body.r-address := recipient host address;
-             endif
-
-             encode body into OCTET STRING;
-
-             select encryption type;
-             encrypt OCTET STRING into packet.enc-part.cipher;
-
-     A.17. KRB_PRIV verification
-
-             receive packet;
-             if (packet.pvno != 5) then
-                     either process using other protocol spec
-                     or error_out(KRB_AP_ERR_BADVERSION);
-             endif
-             if (packet.msg-type != KRB_PRIV) then
-                     error_out(KRB_AP_ERR_MSG_TYPE);
-             endif
-
-             cleartext := decrypt(packet.enc-part) using negotiated key;
-             if (decryption_error()) then
-                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
-             endif
-
-             if (safe_priv_common_checks_ok(cleartext)) then
-                     return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
-             else
-                     return common_checks_error;
-             endif
-
-     A.18. KRB_CRED generation
-
-             invoke KRB_TGS; /* obtain tickets to be provided to peer */
-
-             /* assemble packet: */
-             packet.pvno := protocol version; /* 5 */
-             packet.msg-type := message type; /* KRB_CRED */
-
-             for (tickets[n] in tickets to be forwarded) do
-                     packet.tickets[n] = tickets[n].ticket;
-             done
-
-             packet.enc-part.etype := encryption type;
-
-             for (ticket[n] in tickets to be forwarded) do
-                     body.ticket-info[n].key = tickets[n].session;
-                     body.ticket-info[n].prealm = tickets[n].crealm;
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-                     body.ticket-info[n].pname = tickets[n].cname;
-                     body.ticket-info[n].flags = tickets[n].flags;
-                     body.ticket-info[n].authtime = tickets[n].authtime;
-                     body.ticket-info[n].starttime = tickets[n].starttime;
-                     body.ticket-info[n].endtime = tickets[n].endtime;
-                     body.ticket-info[n].renew-till = tickets[n].renew-till;
-                     body.ticket-info[n].srealm = tickets[n].srealm;
-                     body.ticket-info[n].sname = tickets[n].sname;
-                     body.ticket-info[n].caddr = tickets[n].caddr;
-             done
-
-             get system_time;
-             body.timestamp, body.usec := system_time;
-
-             if (using nonce) then
-                     body.nonce := nonce;
-             endif
-
-             if (using s-address) then
-                     body.s-address := sender host addresses;
-             endif
-             if (limited recipients) then
-                     body.r-address := recipient host address;
-             endif
-
-             encode body into OCTET STRING;
-
-             select encryption type;
-             encrypt OCTET STRING into packet.enc-part.cipher
-                    using negotiated encryption key;
-
-     A.19. KRB_CRED verification
-
-             receive packet;
-             if (packet.pvno != 5) then
-                     either process using other protocol spec
-                     or error_out(KRB_AP_ERR_BADVERSION);
-             endif
-             if (packet.msg-type != KRB_CRED) then
-                     error_out(KRB_AP_ERR_MSG_TYPE);
-             endif
-
-             cleartext := decrypt(packet.enc-part) using negotiated key;
-             if (decryption_error()) then
-                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
-             endif
-             if ((packet.r-address is present or required) and
-                (packet.s-address != O/S_sender(packet)) then
-                     /* O/S report of sender not who claims to have sent it */
-                     error_out(KRB_AP_ERR_BADADDR);
-             endif
-             if ((packet.r-address is present) and
-                 (packet.r-address != local_host_address)) then
-                     /* was not sent to proper place */
-                     error_out(KRB_AP_ERR_BADADDR);
-             endif
-             if (not in_clock_skew(packet.timestamp,packet.usec)) then
-                     error_out(KRB_AP_ERR_SKEW);
-             endif
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-             if (repeated(packet.timestamp,packet.usec,packet.s-address)) then
-                     error_out(KRB_AP_ERR_REPEAT);
-             endif
-             if (packet.nonce is required or present) and
-                (packet.nonce != expected-nonce) then
-                     error_out(KRB_AP_ERR_MODIFIED);
-             endif
-
-             for (ticket[n] in tickets that were forwarded) do
-                     save_for_later(ticket[n],key[n],principal[n],
-                                    server[n],times[n],flags[n]);
-             return
-
-     A.20. KRB_ERROR generation
-
-             /* assemble packet: */
-             packet.pvno := protocol version; /* 5 */
-             packet.msg-type := message type; /* KRB_ERROR */
-
-             get system_time;
-             packet.stime, packet.susec := system_time;
-             packet.realm, packet.sname := server name;
-
-             if (client time available) then
-                     packet.ctime, packet.cusec := client_time;
-             endif
-             packet.error-code := error code;
-             if (client name available) then
-                     packet.cname, packet.crealm := client name;
-             endif
-             if (error text available) then
-                     packet.e-text := error text;
-             endif
-             if (error data available) then
-                     packet.e-data := error data;
-             endif
-
-     B. Definition of common authorization data elements
-
-     This appendix contains the definitions of common authorization data
-     elements. These common authorization data elements are recursivly
-     defined, meaning the ad-data for these types will itself contain a
-     sequence of authorization data whose interpretation is affected by the
-     encapsulating element. Depending on the meaning of the encapsulating
-     element, the encapsulated elements may be ignored, might be interpreted
-     as issued directly by the KDC, or they might be stored in a separate
-     plaintext part of the ticket. The types of the encapsulating elements
-     are specified as part of the Kerberos specification because the
-     behavior based on these values should be understood across
-     implementations whereas other elements need only be understood by the
-     applications which they affect.
-
-     In the definitions that follow, the value of the ad-type for the
-     element will be specified in the subsection number, and the value of
-     the ad-data will be as shown in the ASN.1 structure that follows the
-     subsection heading.
-
-     B.1. If relevant
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     AD-IF-RELEVANT   AuthorizationData
-
-     AD elements encapsulated within the if-relevant element are intended
-     for interpretation only by application servers that understand the
-     particular ad-type of the embedded element. Application servers that do
-     not understand the type of an element embedded within the if-relevant
-     element may ignore the uninterpretable element. This element promotes
-     interoperability across implementations which may have local extensions
-     for authorization.
-
-     B.2. Intended for server
-
-     AD-INTENDED-FOR-SERVER   SEQUENCE {
-              intended-server[0]     SEQUENCE OF PrincipalName
-              elements[1]            AuthorizationData
-     }
-
-     AD elements encapsulated within the intended-for-server element may be
-     ignored if the application server is not in the list of principal names
-     of intended servers. Further, a KDC issuing a ticket for an application
-     server can remove this element if the application server is not in the
-     list of intended servers.
-
-     Application servers should check for their principal name in the
-     intended-server field of this element. If their principal name is not
-     found, this element should be ignored. If found, then the encapsulated
-     elements should be evaluated in the same manner as if they were present
-     in the top level authorization data field. Applications and application
-     servers that do not implement this element should reject tickets that
-     contain authorization data elements of this type.
-
-     B.3. Intended for application class
-
-     AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE {
-     intended-application-class[0] SEQUENCE OF GeneralString elements[1]
-     AuthorizationData } AD elements encapsulated within the
-     intended-for-application-class element may be ignored if the
-     application server is not in one of the named classes of application
-     servers. Examples of application server classes include "FILESYSTEM",
-     and other kinds of servers.
-
-     This element and the elements it encapulates may be safely ignored by
-     applications, application servers, and KDCs that do not implement this
-     element.
-
-     B.4. KDC Issued
-
-     AD-KDCIssued   SEQUENCE {
-                    ad-checksum[0]    Checksum,
-                     i-realm[1]       Realm OPTIONAL,
-                     i-sname[2]       PrincipalName OPTIONAL,
-                    elements[3]       AuthorizationData.
-     }
-
-     ad-checksum
-          A checksum over the elements field using a cryptographic checksum
-          method that is identical to the checksum used to protect the
-          ticket itself (i.e. using the same hash function and the same
-          encryption algorithm used to encrypt the ticket) and using a key
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-          derived from the same key used to protect the ticket.
-     i-realm, i-sname
-          The name of the issuing principal if different from the KDC
-          itself. This field would be used when the KDC can verify the
-          authenticity of elements signed by the issuing principal and it
-          allows this KDC to notify the application server of the validity
-          of those elements.
-     elements
-          A sequence of authorization data elements issued by the KDC.
-     The KDC-issued ad-data field is intended to provide a means for
-     Kerberos principal credentials to embed within themselves privilege
-     attributes and other mechanisms for positive authorization, amplifying
-     the priveleges of the principal beyond what can be done using a
-     credentials without such an a-data element.
-
-     This can not be provided without this element because the definition of
-     the authorization-data field allows elements to be added at will by the
-     bearer of a TGT at the time that they request service tickets and
-     elements may also be added to a delegated ticket by inclusion in the
-     authenticator.
-
-     For KDC-issued elements this is prevented because the elements are
-     signed by the KDC by including a checksum encrypted using the server's
-     key (the same key used to encrypt the ticket - or a key derived from
-     that key). Elements encapsulated with in the KDC-issued element will be
-     ignored by the application server if this "signature" is not present.
-     Further, elements encapsulated within this element from a ticket
-     granting ticket may be interpreted by the KDC, and used as a basis
-     according to policy for including new signed elements within derivative
-     tickets, but they will not be copied to a derivative ticket directly.
-     If they are copied directly to a derivative ticket by a KDC that is not
-     aware of this element, the signature will not be correct for the
-     application ticket elements, and the field will be ignored by the
-     application server.
-
-     This element and the elements it encapulates may be safely ignored by
-     applications, application servers, and KDCs that do not implement this
-     element.
-
-     B.5. And-Or
-
-     AD-AND-OR           SEQUENCE {
-                             condition-count[0]    INTEGER,
-                             elements[1]           AuthorizationData
-     }
-
-     When restrictive AD elements encapsulated within the and-or element are
-     encountered, only the number specified in condition-count of the
-     encapsulated conditions must be met in order to satisfy this element.
-     This element may be used to implement an "or" operation by setting the
-     condition-count field to 1, and it may specify an "and" operation by
-     setting the condition count to the number of embedded elements.
-     Application servers that do not implement this element must reject
-     tickets that contain authorization data elements of this type.
-
-     B.6. Mandatory ticket extensions
-
-     AD-Mandatory-Ticket-Extensions   Checksum
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     An authorization data element of type mandatory-ticket-extensions
-     specifies a collision-proof checksum using the same hash algorithm used
-     to protect the integrity of the ticket itself. This checksum will be
-     calculated over an individual extension field. If there are more than
-     one extension, multiple Mandatory-Ticket-Extensions authorization data
-     elements may be present, each with a checksum for a different extension
-     field. This restriction indicates that the ticket should not be
-     accepted if a ticket extension is not present in the ticket for which
-     the checksum does not match that checksum specified in the
-     authorization data element. Application servers that do not implement
-     this element must reject tickets that contain authorization data
-     elements of this type.
-
-     B.7. Authorization Data in ticket extensions
-
-     AD-IN-Ticket-Extensions   Checksum
-
-     An authorization data element of type in-ticket-extensions specifies a
-     collision-proof checksum using the same hash algorithm used to protect
-     the integrity of the ticket itself. This checksum is calculated over a
-     separate external AuthorizationData field carried in the ticket
-     extensions. Application servers that do not implement this element must
-     reject tickets that contain authorization data elements of this type.
-     Application servers that do implement this element will search the
-     ticket extensions for authorization data fields, calculate the
-     specified checksum over each authorization data field and look for one
-     matching the checksum in this in-ticket-extensions element. If not
-     found, then the ticket must be rejected. If found, the corresponding
-     authorization data elements will be interpreted in the same manner as
-     if they were contained in the top level authorization data field.
-
-     Note that if multiple external authorization data fields are present in
-     a ticket, each will have a corresponding element of type
-     in-ticket-extensions in the top level authorization data field, and the
-     external entries will be linked to the corresponding element by their
-     checksums.
-
-     C. Definition of common ticket extensions
-
-     This appendix contains the definitions of common ticket extensions.
-     Support for these extensions is optional. However, certain extensions
-     have associated authorization data elements that may require rejection
-     of a ticket containing an extension by application servers that do not
-     implement the particular extension. Other extensions have been defined
-     beyond those described in this specification. Such extensions are
-     described elswhere and for some of those extensions the reserved number
-     may be found in the list of constants.
-
-     It is known that older versions of Kerberos did not support this field,
-     and that some clients will strip this field from a ticket when they
-     parse and then reassemble a ticket as it is passed to the application
-     servers. The presence of the extension will not break such clients, but
-     any functionaly dependent on the extensions will not work when such
-     tickets are handled by old clients. In such situations, some
-     implementation may use alternate methods to transmit the information in
-     the extensions field.
-
-     C.1. Null ticket extension
-
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     TE-NullExtension   OctetString -- The empty Octet String
-
-     The te-data field in the null ticket extension is an octet string of
-     lenght zero. This extension may be included in a ticket granting ticket
-     so that the KDC can determine on presentation of the ticket granting
-     ticket whether the client software will strip the extensions field.
-
-     C.2. External Authorization Data
-
-     TE-ExternalAuthorizationData   AuthorizationData
-
-     The te-data field in the external authorization data ticket extension
-     is field of type AuthorizationData containing one or more authorization
-     data elements. If present, a corresponding authorization data element
-     will be present in the primary authorization data for the ticket and
-     that element will contain a checksum of the external authorization data
-     ticket extension.
-     -----------------------------------------------------------------------
-     [TM] Project Athena, Athena, and Kerberos are trademarks of the
-     Massachusetts Institute of Technology (MIT). No commercial use of these
-     trademarks may be made without prior written permission of MIT.
-
-     [1] Note, however, that many applications use Kerberos' functions only
-     upon the initiation of a stream-based network connection. Unless an
-     application subsequently provides integrity protection for the data
-     stream, the identity verification applies only to the initiation of the
-     connection, and does not guarantee that subsequent messages on the
-     connection originate from the same principal.
-
-     [2] Secret and private are often used interchangeably in the
-     literature. In our usage, it takes two (or more) to share a secret,
-     thus a shared DES key is a secret key. Something is only private when
-     no one but its owner knows it. Thus, in public key cryptosystems, one
-     has a public and a private key.
-
-     [3] Of course, with appropriate permission the client could arrange
-     registration of a separately-named prin- cipal in a remote realm, and
-     engage in normal exchanges with that realm's services. However, for
-     even small numbers of clients this becomes cumbersome, and more
-     automatic methods as described here are necessary.
-
-     [4] Though it is permissible to request or issue tick- ets with no
-     network addresses specified.
-
-     [5] The password-changing request must not be honored unless the
-     requester can provide the old password (the user's current secret key).
-     Otherwise, it would be possible for someone to walk up to an unattended
-     ses- sion and change another user's password.
-
-     [6] To authenticate a user logging on to a local system, the
-     credentials obtained in the AS exchange may first be used in a TGS
-     exchange to obtain credentials for a local server. Those credentials
-     must then be verified by a local server through successful completion
-     of the Client/Server exchange.
-
-     [7] "Random" means that, among other things, it should be impossible to
-     guess the next session key based on knowledge of past session keys.
-     This can only be achieved in a pseudo-random number generator if it is
-     based on cryptographic principles. It is more desirable to use a truly
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     random number generator, such as one based on measurements of random
-     physical phenomena.
-
-     [8] Tickets contain both an encrypted and unencrypted portion, so
-     cleartext here refers to the entire unit, which can be copied from one
-     message and replayed in another without any cryptographic skill.
-
-     [9] Note that this can make applications based on unreliable transports
-     difficult to code correctly. If the transport might deliver duplicated
-     messages, either a new authenticator must be generated for each retry,
-     or the application server must match requests and replies and replay
-     the first reply in response to a detected duplicate.
-
-     [10] This is used for user-to-user authentication as described in [8].
-
-     [11] Note that the rejection here is restricted to authenticators from
-     the same principal to the same server. Other client principals
-     communicating with the same server principal should not be have their
-     authenticators rejected if the time and microsecond fields happen to
-     match some other client's authenticator.
-
-     [12] In the Kerberos version 4 protocol, the timestamp in the reply was
-     the client's timestamp plus one. This is not necessary in version 5
-     because version 5 messages are formatted in such a way that it is not
-     possible to create the reply by judicious message surgery (even in
-     encrypted form) without knowledge of the appropriate encryption keys.
-
-     [13] Note that for encrypting the KRB_AP_REP message, the sub-session
-     key is not used, even if present in the Authenticator.
-
-     [14] Implementations of the protocol may wish to provide routines to
-     choose subkeys based on session keys and random numbers and to generate
-     a negotiated key to be returned in the KRB_AP_REP message.
-
-     [15]This can be accomplished in several ways. It might be known
-     beforehand (since the realm is part of the principal identifier), it
-     might be stored in a nameserver, or it might be obtained from a
-     configura- tion file. If the realm to be used is obtained from a
-     nameserver, there is a danger of being spoofed if the nameservice
-     providing the realm name is not authenti- cated. This might result in
-     the use of a realm which has been compromised, and would result in an
-     attacker's ability to compromise the authentication of the application
-     server to the client.
-
-     [16] If the client selects a sub-session key, care must be taken to
-     ensure the randomness of the selected sub- session key. One approach
-     would be to generate a random number and XOR it with the session key
-     from the ticket-granting ticket.
-
-     [17] This allows easy implementation of user-to-user authentication
-     [8], which uses ticket-granting ticket session keys in lieu of secret
-     server keys in situa- tions where such secret keys could be easily
-     comprom- ised.
-
-     [18] For the purpose of appending, the realm preceding the first listed
-     realm is considered to be the null realm ("").
-
-     [19] For the purpose of interpreting null subfields, the client's realm
-     is considered to precede those in the transited field, and the server's
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     realm is considered to follow them.
-
-     [20] This means that a client and server running on the same host and
-     communicating with one another using the KRB_SAFE messages should not
-     share a common replay cache to detect KRB_SAFE replays.
-
-     [21] The implementation of the Kerberos server need not combine the
-     database and the server on the same machine; it is feasible to store
-     the principal database in, say, a network name service, as long as the
-     entries stored therein are protected from disclosure to and
-     modification by unauthorized parties. However, we recommend against
-     such strategies, as they can make system management and threat analysis
-     quite complex.
-
-     [22] See the discussion of the padata field in section 5.4.2 for
-     details on why this can be useful.
-
-     [23] Warning for implementations that unpack and repack data structures
-     during the generation and verification of embedded checksums: Because
-     any checksums applied to data structures must be checked against the
-     original data the length of bit strings must be preserved within a data
-     structure between the time that a checksum is generated through
-     transmission to the time that the checksum is verified.
-
-     [24] It is NOT recommended that this time value be used to adjust the
-     workstation's clock since the workstation cannot reliably determine
-     that such a KRB_AS_REP actually came from the proper KDC in a timely
-     manner.
-
-     [25] Note, however, that if the time is used as the nonce, one must
-     make sure that the workstation time is monotonically increasing. If the
-     time is ever reset backwards, there is a small, but finite, probability
-     that a nonce will be reused.
-
-     [27] An application code in the encrypted part of a message provides an
-     additional check that the message was decrypted properly.
-
-     [29] An application code in the encrypted part of a message provides an
-     additional check that the message was decrypted properly.
-
-     [31] An application code in the encrypted part of a message provides an
-     additional check that the message was decrypted properly.
-
-     [32] If supported by the encryption method in use, an initialization
-     vector may be passed to the encryption procedure, in order to achieve
-     proper cipher chaining. The initialization vector might come from the
-     last block of the ciphertext from the previous KRB_PRIV message, but it
-     is the application's choice whether or not to use such an
-     initialization vector. If left out, the default initialization vector
-     for the encryption algorithm will be used.
-
-     [33] This prevents an attacker who generates an incorrect AS request
-     from obtaining verifiable plaintext for use in an off-line password
-     guessing attack.
-
-     [35] In the above specification, UNTAGGED OCTET STRING(length) is the
-     notation for an octet string with its tag and length removed. It is not
-     a valid ASN.1 type. The tag bits and length must be removed from the
-     confounder since the purpose of the confounder is so that the message
-
-Neuman, Ts'o, Kohl                                Expires: 10 September, 2000
-
-
-
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-05          June 25, 1999
-
-     starts with random data, but the tag and its length are fixed. For
-     other fields, the length and tag would be redundant if they were
-     included because they are specified by the encryption type. [36] The
-     ordering of the fields in the CipherText is important. Additionally,
-     messages encoded in this format must include a length as part of the
-     msg-seq field. This allows the recipient to verify that the message has
-     not been truncated. Without a length, an attacker could use a chosen
-     plaintext attack to generate a message which could be truncated, while
-     leaving the checksum intact. Note that if the msg-seq is an encoding of
-     an ASN.1 SEQUENCE or OCTET STRING, then the length is part of that
-     encoding.
-
-     [37] In some cases, it may be necessary to use a different "mix-in"
-     string for compatibility reasons; see the discussion of padata in
-     section 5.4.2.
-
-     [38] In some cases, it may be necessary to use a different "mix-in"
-     string for compatibility reasons; see the discussion of padata in
-     section 5.4.2.
-
-     [39] A variant of the key is used to limit the use of a key to a
-     particular function, separating the functions of generating a checksum
-     from other encryption performed using the session key. The constant
-     F0F0F0F0F0F0F0F0 was chosen because it maintains key parity. The
-     properties of DES precluded the use of the complement. The same
-     constant is used for similar purpose in the Message Integrity Check in
-     the Privacy Enhanced Mail standard.
-
-     [40] This error carries additional information in the e- data field.
-     The contents of the e-data field for this message is described in
-     section 5.9.1.
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt b/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt
deleted file mode 100644
index ae79e8a7c..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-revisions-06.txt
+++ /dev/null
@@ -1,7301 +0,0 @@
-INTERNET-DRAFT                                              Clifford Neuman
-                                                                  John Kohl
-                                                              Theodore Ts'o
-                                                              July 14, 2000
-                                                   Expires January 14, 2001
-
-The Kerberos Network Authentication Service (V5)
-
-
-draft-ietf-cat-kerberos-revisions-06.txt
-
-STATUS OF THIS MEMO
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC 2026. 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."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-To learn the current status of any Internet-Draft, please check the
-"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
-Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
-ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
-
-The distribution of this memo is unlimited. It is filed as
-draft-ietf-cat-kerberos-revisions-06.txt, and expires January 14, 2001.
-Please send comments to: krb-protocol@MIT.EDU
-
-     This document is getting closer to a last call, but there are several
-     issues to be discussed. Some, but not all of these issues, are
-     highlighted in comments in the draft. We hope to resolve these issues
-     on the mailing list for the Kerberos working group, leading up to and
-     during the Pittsburgh IETF on a section by section basis, since this
-     is a long document, and it has been difficult to consider it as a
-     whole. Once sections are agreed to, it is out intent to issue the more
-     formal WG and IETF last calls.
-
-ABSTRACT
-
-This document provides an overview and specification of Version 5 of the
-Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol
-and its intended use that require more detailed or clearer explanation than
-was provided in RFC1510. This document is intended to provide a detailed
-description of the protocol, suitable for implementation, together with
-descriptions of the appropriate use of protocol messages and fields within
-those messages.
-
-This document is not intended to describe Kerberos to the end user, system
-administrator, or application developer. Higher level papers describing
-Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88],
-are available elsewhere.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-OVERVIEW
-
-This INTERNET-DRAFT describes the concepts and model upon which the
-Kerberos network authentication system is based. It also specifies Version
-5 of the Kerberos protocol.
-
-The motivations, goals, assumptions, and rationale behind most design
-decisions are treated cursorily; they are more fully described in a paper
-available in IEEE communications [NT94] and earlier in the Kerberos portion
-of the Athena Technical Plan [MNSS87]. The protocols have been a proposed
-standard and are being considered for advancement for draft standard
-through the IETF standard process. Comments are encouraged on the
-presentation, but only minor refinements to the protocol as implemented or
-extensions that fit within current protocol framework will be considered at
-this time.
-
-Requests for addition to an electronic mailing list for discussion of
-Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-request@MIT.EDU.
-This mailing list is gatewayed onto the Usenet as the group
-comp.protocols.kerberos. Requests for further information, including
-documents and code availability, may be sent to info-kerberos@MIT.EDU.
-
-BACKGROUND
-
-The Kerberos model is based in part on Needham and Schroeder's trusted
-third-party authentication protocol [NS78] and on modifications suggested
-by Denning and Sacco [DS81]. The original design and implementation of
-Kerberos Versions 1 through 4 was the work of two former Project Athena
-staff members, Steve Miller of Digital Equipment Corporation and Clifford
-Neuman (now at the Information Sciences Institute of the University of
-Southern California), along with Jerome Saltzer, Technical Director of
-Project Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many
-other members of Project Athena have also contributed to the work on
-Kerberos.
-
-Version 5 of the Kerberos protocol (described in this document) has evolved
-from Version 4 based on new requirements and desires for features not
-available in Version 4. The design of Version 5 of the Kerberos protocol
-was led by Clifford Neuman and John Kohl with much input from the
-community. The development of the MIT reference implementation was led at
-MIT by John Kohl and Theodore T'so, with help and contributed code from
-many others. Since RFC1510 was issued, extensions and revisions to the
-protocol have been proposed by many individuals. Some of these proposals
-are reflected in this document. Where such changes involved significant
-effort, the document cites the contribution of the proposer.
-
-Reference implementations of both version 4 and version 5 of Kerberos are
-publicly available and commercial implementations have been developed and
-are widely used. Details on the differences between Kerberos Versions 4 and
-5 can be found in [KNT92].
-
-1. Introduction
-
-Kerberos provides a means of verifying the identities of principals, (e.g.
-a workstation user or a network server) on an open (unprotected) network.
-This is accomplished without relying on assertions by the host operating
-system, without basing trust on host addresses, without requiring physical
-security of all the hosts on the network, and under the assumption that
-packets traveling along the network can be read, modified, and inserted at
-will[1]. Kerberos performs authentication under these conditions as a
-trusted third-party authentication service by using conventional (shared
-secret key [2] cryptography. Kerberos extensions have been proposed and
-implemented that provide for the use of public key cryptography during
-certain phases of the authentication protocol. These extensions provide for
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-authentication of users registered with public key certification
-authorities, and allow the system to provide certain benefits of public key
-cryptography in situations where they are needed.
-
-The basic Kerberos authentication process proceeds as follows: A client
-sends a request to the authentication server (AS) requesting 'credentials'
-for a given server. The AS responds with these credentials, encrypted in
-the client's key. The credentials consist of 1) a 'ticket' for the server
-and 2) a temporary encryption key (often called a "session key"). The
-client transmits the ticket (which contains the client's identity and a
-copy of the session key, all encrypted in the server's key) to the server.
-The session key (now shared by the client and server) is used to
-authenticate the client, and may optionally be used to authenticate the
-server. It may also be used to encrypt further communication between the
-two parties or to exchange a separate sub-session key to be used to encrypt
-further communication.
-
-Implementation of the basic protocol consists of one or more authentication
-servers running on physically secure hosts. The authentication servers
-maintain a database of principals (i.e., users and servers) and their
-secret keys. Code libraries provide encryption and implement the Kerberos
-protocol. In order to add authentication to its transactions, a typical
-network application adds one or two calls to the Kerberos library directly
-or through the Generic Security Services Application Programming Interface,
-GSSAPI, described in separate document. These calls result in the
-transmission of the necessary messages to achieve authentication.
-
-The Kerberos protocol consists of several sub-protocols (or exchanges).
-There are two basic methods by which a client can ask a Kerberos server for
-credentials. In the first approach, the client sends a cleartext request
-for a ticket for the desired server to the AS. The reply is sent encrypted
-in the client's secret key. Usually this request is for a ticket-granting
-ticket (TGT) which can later be used with the ticket-granting server (TGS).
-In the second method, the client sends a request to the TGS. The client
-uses the TGT to authenticate itself to the TGS in the same manner as if it
-were contacting any other application server that requires Kerberos
-authentication. The reply is encrypted in the session key from the TGT.
-Though the protocol specification describes the AS and the TGS as separate
-servers, they are implemented in practice as different protocol entry
-points within a single Kerberos server.
-
-Once obtained, credentials may be used to verify the identity of the
-principals in a transaction, to ensure the integrity of messages exchanged
-between them, or to preserve privacy of the messages. The application is
-free to choose whatever protection may be necessary.
-
-To verify the identities of the principals in a transaction, the client
-transmits the ticket to the application server. Since the ticket is sent
-"in the clear" (parts of it are encrypted, but this encryption doesn't
-thwart replay) and might be intercepted and reused by an attacker,
-additional information is sent to prove that the message originated with
-the principal to whom the ticket was issued. This information (called the
-authenticator) is encrypted in the session key, and includes a timestamp.
-The timestamp proves that the message was recently generated and is not a
-replay. Encrypting the authenticator in the session key proves that it was
-generated by a party possessing the session key. Since no one except the
-requesting principal and the server know the session key (it is never sent
-over the network in the clear) this guarantees the identity of the client.
-
-The integrity of the messages exchanged between principals can also be
-guaranteed using the session key (passed in the ticket and contained in the
-credentials). This approach provides detection of both replay attacks and
-message stream modification attacks. It is accomplished by generating and
-transmitting a collision-proof checksum (elsewhere called a hash or digest
-function) of the client's message, keyed with the session key. Privacy and
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-integrity of the messages exchanged between principals can be secured by
-encrypting the data to be passed using the session key contained in the
-ticket or the subsession key found in the authenticator.
-
-The authentication exchanges mentioned above require read-only access to
-the Kerberos database. Sometimes, however, the entries in the database must
-be modified, such as when adding new principals or changing a principal's
-key. This is done using a protocol between a client and a third Kerberos
-server, the Kerberos Administration Server (KADM). There is also a protocol
-for maintaining multiple copies of the Kerberos database. Neither of these
-protocols are described in this document.
-
-1.1. Cross-Realm Operation
-
-The Kerberos protocol is designed to operate across organizational
-boundaries. A client in one organization can be authenticated to a server
-in another. Each organization wishing to run a Kerberos server establishes
-its own 'realm'. The name of the realm in which a client is registered is
-part of the client's name, and can be used by the end-service to decide
-whether to honor a request.
-
-By establishing 'inter-realm' keys, the administrators of two realms can
-allow a client authenticated in the local realm to prove its identity to
-servers in other realms[3]. The exchange of inter-realm keys (a separate
-key may be used for each direction) registers the ticket-granting service
-of each realm as a principal in the other realm. A client is then able to
-obtain a ticket-granting ticket for the remote realm's ticket-granting
-service from its local realm. When that ticket-granting ticket is used, the
-remote ticket-granting service uses the inter-realm key (which usually
-differs from its own normal TGS key) to decrypt the ticket-granting ticket,
-and is thus certain that it was issued by the client's own TGS. Tickets
-issued by the remote ticket-granting service will indicate to the
-end-service that the client was authenticated from another realm.
-
-A realm is said to communicate with another realm if the two realms share
-an inter-realm key, or if the local realm shares an inter-realm key with an
-intermediate realm that communicates with the remote realm. An
-authentication path is the sequence of intermediate realms that are
-transited in communicating from one realm to another.
-
-Realms are typically organized hierarchically. Each realm shares a key with
-its parent and a different key with each child. If an inter-realm key is
-not directly shared by two realms, the hierarchical organization allows an
-authentication path to be easily constructed. If a hierarchical
-organization is not used, it may be necessary to consult a database in
-order to construct an authentication path between realms.
-
-Although realms are typically hierarchical, intermediate realms may be
-bypassed to achieve cross-realm authentication through alternate
-authentication paths (these might be established to make communication
-between two realms more efficient). It is important for the end-service to
-know which realms were transited when deciding how much faith to place in
-the authentication process. To facilitate this decision, a field in each
-ticket contains the names of the realms that were involved in
-authenticating the client.
-
-The application server is ultimately responsible for accepting or rejecting
-authentication and should check the transited field. The application server
-may choose to rely on the KDC for the application server's realm to check
-the transited field. The application server's KDC will set the
-TRANSITED-POLICY-CHECKED flag in this case. The KDC's for intermediate
-realms may also check the transited field as they issue
-ticket-granting-tickets for other realms, but they are encouraged not to do
-so. A client may request that the KDC's not check the transited field by
-setting the DISABLE-TRANSITED-CHECK flag. KDC's are encouraged but not
-required to honor this flag.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     [JBrezak] Should there be a section here on how clients determine what
-     realm a service is in? Something like:
-
-     The client may not immediately know what realm a particular service
-     principal is in. There are 2 basic mechanisms that can be used to
-     determine the realm of a service. The first requires that the client
-     fully specify the service principal including the realm in the
-     Kerberos protocol request. If the Kerberos server for the specified
-     realm does not have a principal that exactly matches the service in
-     the request, the Kerberos server will return an error indicating that
-     the service principal was not found. Alternatively the client can make
-     a request providing just the service principal name and requesting
-     name canonicalization from the Kerberos server. The Kerberos server
-     will attempt to locate a service principal in its database that best
-     matches the request principal or provide a referral to another
-     Kerberos realm that may be contain the requested service principal.
-
-1.2. Authorization
-
-As an authentication service, Kerberos provides a means of verifying the
-identity of principals on a network. Authentication is usually useful
-primarily as a first step in the process of authorization, determining
-whether a client may use a service, which objects the client is allowed to
-access, and the type of access allowed for each. Kerberos does not, by
-itself, provide authorization. Possession of a client ticket for a service
-provides only for authentication of the client to that service, and in the
-absence of a separate authorization procedure, it should not be considered
-by an application as authorizing the use of that service.
-
-Such separate authorization methods may be implemented as application
-specific access control functions and may be based on files such as the
-application server, or on separately issued authorization credentials such
-as those based on proxies [Neu93], or on other authorization services.
-Separately authenticated authorization credentials may be embedded in a
-tickets authorization data when encapsulated by the kdc-issued
-authorization data element.
-
-Applications should not be modified to accept the mere issuance of a
-service ticket by the Kerberos server (even by a modified Kerberos server)
-as granting authority to use the service, since such applications may
-become vulnerable to the bypass of this authorization check in an
-environment if they interoperate with other KDCs or where other options for
-application authentication (e.g. the PKTAPP proposal) are provided.
-
-1.3. Environmental assumptions
-
-Kerberos imposes a few assumptions on the environment in which it can
-properly function:
-
-   * 'Denial of service' attacks are not solved with Kerberos. There are
-     places in these protocols where an intruder can prevent an application
-     from participating in the proper authentication steps. Detection and
-     solution of such attacks (some of which can appear to be nnot-uncommon
-     'normal' failure modes for the system) is usually best left to the
-     human administrators and users.
-   * Principals must keep their secret keys secret. If an intruder somehow
-     steals a principal's key, it will be able to masquerade as that
-     principal or impersonate any server to the legitimate principal.
-   * 'Password guessing' attacks are not solved by Kerberos. If a user
-     chooses a poor password, it is possible for an attacker to
-     successfully mount an offline dictionary attack by repeatedly
-     attempting to decrypt, with successive entries from a dictionary,
-     messages obtained which are encrypted under a key derived from the
-     user's password.
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-   * Each host on the network must have a clock which is 'loosely
-     synchronized' to the time of the other hosts; this synchronization is
-     used to reduce the bookkeeping needs of application servers when they
-     do replay detection. The degree of "looseness" can be configured on a
-     per-server basis, but is typically on the order of 5 minutes. If the
-     clocks are synchronized over the network, the clock synchronization
-     protocol must itself be secured from network attackers.
-   * Principal identifiers are not recycled on a short-term basis. A
-     typical mode of access control will use access control lists (ACLs) to
-     grant permissions to particular principals. If a stale ACL entry
-     remains for a deleted principal and the principal identifier is
-     reused, the new principal will inherit rights specified in the stale
-     ACL entry. By not re-using principal identifiers, the danger of
-     inadvertent access is removed.
-
-1.4. Glossary of terms
-
-Below is a list of terms used throughout this document.
-
-Authentication
-     Verifying the claimed identity of a principal.
-Authentication header
-     A record containing a Ticket and an Authenticator to be presented to a
-     server as part of the authentication process.
-Authentication path
-     A sequence of intermediate realms transited in the authentication
-     process when communicating from one realm to another.
-Authenticator
-     A record containing information that can be shown to have been
-     recently generated using the session key known only by the client and
-     server.
-Authorization
-     The process of determining whether a client may use a service, which
-     objects the client is allowed to access, and the type of access
-     allowed for each.
-Capability
-     A token that grants the bearer permission to access an object or
-     service. In Kerberos, this might be a ticket whose use is restricted
-     by the contents of the authorization data field, but which lists no
-     network addresses, together with the session key necessary to use the
-     ticket.
-Ciphertext
-     The output of an encryption function. Encryption transforms plaintext
-     into ciphertext.
-Client
-     A process that makes use of a network service on behalf of a user.
-     Note that in some cases a Server may itself be a client of some other
-     server (e.g. a print server may be a client of a file server).
-Credentials
-     A ticket plus the secret session key necessary to successfully use
-     that ticket in an authentication exchange.
-KDC
-     Key Distribution Center, a network service that supplies tickets and
-     temporary session keys; or an instance of that service or the host on
-     which it runs. The KDC services both initial ticket and
-     ticket-granting ticket requests. The initial ticket portion is
-     sometimes referred to as the Authentication Server (or service). The
-     ticket-granting ticket portion is sometimes referred to as the
-     ticket-granting server (or service).
-Kerberos
-     Aside from the 3-headed dog guarding Hades, the name given to Project
-     Athena's authentication service, the protocol used by that service, or
-     the code used to implement the authentication service.
-Plaintext
-     The input to an encryption function or the output of a decryption
-     function. Decryption transforms ciphertext into plaintext.
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-Principal
-     A uniquely named client or server instance that participates in a
-     network communication.
-Principal identifier
-     The name used to uniquely identify each different principal.
-Seal
-     To encipher a record containing several fields in such a way that the
-     fields cannot be individually replaced without either knowledge of the
-     encryption key or leaving evidence of tampering.
-Secret key
-     An encryption key shared by a principal and the KDC, distributed
-     outside the bounds of the system, with a long lifetime. In the case of
-     a human user's principal, the secret key is derived from a password.
-Server
-     A particular Principal which provides a resource to network clients.
-     The server is sometimes refered to as the Application Server.
-Service
-     A resource provided to network clients; often provided by more than
-     one server (for example, remote file service).
-Session key
-     A temporary encryption key used between two principals, with a
-     lifetime limited to the duration of a single login "session".
-Sub-session key
-     A temporary encryption key used between two principals, selected and
-     exchanged by the principals using the session key, and with a lifetime
-     limited to the duration of a single association.
-Ticket
-     A record that helps a client authenticate itself to a server; it
-     contains the client's identity, a session key, a timestamp, and other
-     information, all sealed using the server's secret key. It only serves
-     to authenticate a client when presented along with a fresh
-     Authenticator.
-
-2. Ticket flag uses and requests
-
-Each Kerberos ticket contains a set of flags which are used to indicate
-various attributes of that ticket. Most flags may be requested by a client
-when the ticket is obtained; some are automatically turned on and off by a
-Kerberos server as required. The following sections explain what the
-various flags mean, and gives examples of reasons to use such a flag.
-
-2.1. Initial and pre-authenticated tickets
-
-The INITIAL flag indicates that a ticket was issued using the AS protocol
-and not issued based on a ticket-granting ticket. Application servers that
-want to require the demonstrated knowledge of a client's secret key (e.g. a
-password-changing program) can insist that this flag be set in any tickets
-they accept, and thus be assured that the client's key was recently
-presented to the application client.
-
-The PRE-AUTHENT and HW-AUTHENT flags provide addition information about the
-initial authentication, regardless of whether the current ticket was issued
-directly (in which case INITIAL will also be set) or issued on the basis of
-a ticket-granting ticket (in which case the INITIAL flag is clear, but the
-PRE-AUTHENT and HW-AUTHENT flags are carried forward from the
-ticket-granting ticket).
-
-2.2. Invalid tickets
-
-The INVALID flag indicates that a ticket is invalid. Application servers
-must reject tickets which have this flag set. A postdated ticket will
-usually be issued in this form. Invalid tickets must be validated by the
-KDC before use, by presenting them to the KDC in a TGS request with the
-VALIDATE option specified. The KDC will only validate tickets after their
-starttime has passed. The validation is required so that postdated tickets
-which have been stolen before their starttime can be rendered permanently
-invalid (through a hot-list mechanism) (see section 3.3.3.1).
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-2.3. Renewable tickets
-
-Applications may desire to hold tickets which can be valid for long periods
-of time. However, this can expose their credentials to potential theft for
-equally long periods, and those stolen credentials would be valid until the
-expiration time of the ticket(s). Simply using short-lived tickets and
-obtaining new ones periodically would require the client to have long-term
-access to its secret key, an even greater risk. Renewable tickets can be
-used to mitigate the consequences of theft. Renewable tickets have two
-"expiration times": the first is when the current instance of the ticket
-expires, and the second is the latest permissible value for an individual
-expiration time. An application client must periodically (i.e. before it
-expires) present a renewable ticket to the KDC, with the RENEW option set
-in the KDC request. The KDC will issue a new ticket with a new session key
-and a later expiration time. All other fields of the ticket are left
-unmodified by the renewal process. When the latest permissible expiration
-time arrives, the ticket expires permanently. At each renewal, the KDC may
-consult a hot-list to determine if the ticket had been reported stolen
-since its last renewal; it will refuse to renew such stolen tickets, and
-thus the usable lifetime of stolen tickets is reduced.
-
-The RENEWABLE flag in a ticket is normally only interpreted by the
-ticket-granting service (discussed below in section 3.3). It can usually be
-ignored by application servers. However, some particularly careful
-application servers may wish to disallow renewable tickets.
-
-If a renewable ticket is not renewed by its expiration time, the KDC will
-not renew the ticket. The RENEWABLE flag is reset by default, but a client
-may request it be set by setting the RENEWABLE option in the KRB_AS_REQ
-message. If it is set, then the renew-till field in the ticket contains the
-time after which the ticket may not be renewed.
-
-2.4. Postdated tickets
-
-Applications may occasionally need to obtain tickets for use much later,
-e.g. a batch submission system would need tickets to be valid at the time
-the batch job is serviced. However, it is dangerous to hold valid tickets
-in a batch queue, since they will be on-line longer and more prone to
-theft. Postdated tickets provide a way to obtain these tickets from the KDC
-at job submission time, but to leave them "dormant" until they are
-activated and validated by a further request of the KDC. If a ticket theft
-were reported in the interim, the KDC would refuse to validate the ticket,
-and the thief would be foiled.
-
-The MAY-POSTDATE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. This
-flag must be set in a ticket-granting ticket in order to issue a postdated
-ticket based on the presented ticket. It is reset by default; it may be
-requested by a client by setting the ALLOW-POSTDATE option in the
-KRB_AS_REQ message. This flag does not allow a client to obtain a postdated
-ticket-granting ticket; postdated ticket-granting tickets can only by
-obtained by requesting the postdating in the KRB_AS_REQ message. The life
-(endtime-starttime) of a postdated ticket will be the remaining life of the
-ticket-granting ticket at the time of the request, unless the RENEWABLE
-option is also set, in which case it can be the full life
-(endtime-starttime) of the ticket-granting ticket. The KDC may limit how
-far in the future a ticket may be postdated.
-
-The POSTDATED flag indicates that a ticket has been postdated. The
-application server can check the authtime field in the ticket to see when
-the original authentication occurred. Some services may choose to reject
-postdated tickets, or they may only accept them within a certain period
-after the original authentication. When the KDC issues a POSTDATED ticket,
-it will also be marked as INVALID, so that the application client must
-present the ticket to the KDC to be validated before use.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-2.5. Proxiable and proxy tickets
-
-At times it may be necessary for a principal to allow a service to perform
-an operation on its behalf. The service must be able to take on the
-identity of the client, but only for a particular purpose. A principal can
-allow a service to take on the principal's identity for a particular
-purpose by granting it a proxy.
-
-The process of granting a proxy using the proxy and proxiable flags is used
-to provide credentials for use with specific services. Though conceptually
-also a proxy, user's wishing to delegate their identity for ANY purpose
-must use the ticket forwarding mechanism described in the next section to
-forward a ticket granting ticket.
-
-The PROXIABLE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. When
-set, this flag tells the ticket-granting server that it is OK to issue a
-new ticket (but not a ticket-granting ticket) with a different network
-address based on this ticket. This flag is set if requested by the client
-on initial authentication. By default, the client will request that it be
-set when requesting a ticket granting ticket, and reset when requesting any
-other ticket.
-
-This flag allows a client to pass a proxy to a server to perform a remote
-request on its behalf, e.g. a print service client can give the print
-server a proxy to access the client's files on a particular file server in
-order to satisfy a print request.
-
-In order to complicate the use of stolen credentials, Kerberos tickets are
-usually valid from only those network addresses specifically included in
-the ticket[4]. When granting a proxy, the client must specify the new
-network address from which the proxy is to be used, or indicate that the
-proxy is to be issued for use from any address.
-
-The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket.
-Application servers may check this flag and at their option they may
-require additional authentication from the agent presenting the proxy in
-order to provide an audit trail.
-
-2.6. Forwardable tickets
-
-Authentication forwarding is an instance of a proxy where the service is
-granted complete use of the client's identity. An example where it might be
-used is when a user logs in to a remote system and wants authentication to
-work from that system as if the login were local.
-
-The FORWARDABLE flag in a ticket is normally only interpreted by the
-ticket-granting service. It can be ignored by application servers. The
-FORWARDABLE flag has an interpretation similar to that of the PROXIABLE
-flag, except ticket-granting tickets may also be issued with different
-network addresses. This flag is reset by default, but users may request
-that it be set by setting the FORWARDABLE option in the AS request when
-they request their initial ticket- granting ticket.
-
-This flag allows for authentication forwarding without requiring the user
-to enter a password again. If the flag is not set, then authentication
-forwarding is not permitted, but the same result can still be achieved if
-the user engages in the AS exchange specifying the requested network
-addresses and supplies a password.
-
-The FORWARDED flag is set by the TGS when a client presents a ticket with
-the FORWARDABLE flag set and requests a forwarded ticket by specifying the
-FORWARDED KDC option and supplying a set of addresses for the new ticket.
-It is also set in all tickets issued based on tickets with the FORWARDED
-flag set. Application servers may choose to process FORWARDED tickets
-differently than non-FORWARDED tickets.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-2.7 Name canonicalization [JBrezak]
-
-If a client does not have the full name information for a principal, it can
-request that the Kerberos server attempt to lookup the name in its database
-and return a canonical form of the requested principal or a referral to a
-realm that has the requested principal in its namespace. Name
-canonicalization allows a principal to have alternate names. Name
-canonicalization must not be used to locate principal names supplied from
-wildcards and is not a mechanism to be used to search a Kerberos database.
-
-The CANONICALIZE flag in a ticket request is used to indicate to the
-Kerberos server that the client will accept an alternative name to the
-principal in the request or a referral to another realm. Both the AS and
-TGS must be able to interpret requests with this flag.
-
-By using this flag, the client can avoid extensive configuration needed to
-map specific host names to a particular realm.
-
-2.8. Other KDC options
-
-There are two additional options which may be set in a client's request of
-the KDC. The RENEWABLE-OK option indicates that the client will accept a
-renewable ticket if a ticket with the requested life cannot otherwise be
-provided. If a ticket with the requested life cannot be provided, then the
-KDC may issue a renewable ticket with a renew-till equal to the the
-requested endtime. The value of the renew-till field may still be adjusted
-by site-determined limits or limits imposed by the individual principal or
-server.
-
-The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service.
-It indicates that the ticket to be issued for the end server is to be
-encrypted in the session key from the a additional second ticket-granting
-ticket provided with the request. See section 3.3.3 for specific details.
-
-3. Message Exchanges
-
-The following sections describe the interactions between network clients
-and servers and the messages involved in those exchanges.
-
-3.1. The Authentication Service Exchange
-
-                          Summary
-      Message direction       Message type    Section
-      1. Client to Kerberos   KRB_AS_REQ      5.4.1
-      2. Kerberos to client   KRB_AS_REP or   5.4.2
-                              KRB_ERROR       5.9.1
-
-The Authentication Service (AS) Exchange between the client and the
-Kerberos Authentication Server is initiated by a client when it wishes to
-obtain authentication credentials for a given server but currently holds no
-credentials. In its basic form, the client's secret key is used for
-encryption and decryption. This exchange is typically used at the
-initiation of a login session to obtain credentials for a Ticket-Granting
-Server which will subsequently be used to obtain credentials for other
-servers (see section 3.3) without requiring further use of the client's
-secret key. This exchange is also used to request credentials for services
-which must not be mediated through the Ticket-Granting Service, but rather
-require a principal's secret key, such as the password-changing service[5].
-This exchange does not by itself provide any assurance of the the identity
-of the user[6].
-
-The exchange consists of two messages: KRB_AS_REQ from the client to
-Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
-messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-In the request, the client sends (in cleartext) its own identity and the
-identity of the server for which it is requesting credentials. The
-response, KRB_AS_REP, contains a ticket for the client to present to the
-server, and a session key that will be shared by the client and the server.
-The session key and additional information are encrypted in the client's
-secret key. The KRB_AS_REP message contains information which can be used
-to detect replays, and to associate it with the message to which it
-replies. Various errors can occur; these are indicated by an error response
-(KRB_ERROR) instead of the KRB_AS_REP response. The error message is not
-encrypted. The KRB_ERROR message contains information which can be used to
-associate it with the message to which it replies. The lack of encryption
-in the KRB_ERROR message precludes the ability to detect replays,
-fabrications, or modifications of such messages.
-
-Without preautentication, the authentication server does not know whether
-the client is actually the principal named in the request. It simply sends
-a reply without knowing or caring whether they are the same. This is
-acceptable because nobody but the principal whose identity was given in the
-request will be able to use the reply. Its critical information is
-encrypted in that principal's key. The initial request supports an optional
-field that can be used to pass additional information that might be needed
-for the initial exchange. This field may be used for preauthentication as
-described in section [hl<>].
-
-3.1.1. Generation of KRB_AS_REQ message
-
-The client may specify a number of options in the initial request. Among
-these options are whether pre-authentication is to be performed; whether
-the requested ticket is to be renewable, proxiable, or forwardable; whether
-it should be postdated or allow postdating of derivative tickets; whether
-the client requests name-canonicalization; and whether a renewable ticket
-will be accepted in lieu of a non-renewable ticket if the requested ticket
-expiration date cannot be satisfied by a non-renewable ticket (due to
-configuration constraints; see section 4). See section A.1 for pseudocode.
-
-The client prepares the KRB_AS_REQ message and sends it to the KDC.
-
-3.1.2. Receipt of KRB_AS_REQ message
-
-If all goes well, processing the KRB_AS_REQ message will result in the
-creation of a ticket for the client to present to the server. The format
-for the ticket is described in section 5.3.1. The contents of the ticket
-are determined as follows.
-
-3.1.3. Generation of KRB_AS_REP message
-
-The authentication server looks up the client and server principals named
-in the KRB_AS_REQ in its database, extracting their respective keys.  If
-the requested client principal named in the request is not found in its
-database, then an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is
-returned. If the request had the CANONICALIZE option set, then the AS can
-attempt to lookup the client principal name in an alternate database, if it
-is found an error message with a KDC_ERR_WRONG_REALM error code and the
-cname and crealm in the error message must contain the true client
-principal name and realm.
-
-If required, the server pre-authenticates the request, and if the
-pre-authentication check fails, an error message with the code
-KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the
-requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP
-is returned. Otherwise it generates a 'random' session key[7].
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-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. DES3-CBC-SHA1 and DES3-CBC-SHA1-KD), 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.
-
-     JBrezak - the behavior of PW-SALT, and ETYPE-INFO should be explained
-     here; also about using keys that have different string-to-key
-     functions like AFSsalt
-
-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.
-
-If the requested start time is absent, indicates a time in the past, or is
-within the window of acceptable clock skew for the KDC and the POSTDATE
-option has not been specified, then the start time of the ticket is set to
-the authentication server's current time. If it indicates a time in the
-future beyond the acceptable clock skew, but the POSTDATED option has not
-been specified then the error KDC_ERR_CANNOT_POSTDATE is returned.
-Otherwise the requested start time is checked against the policy of the
-local realm (the administrator might decide to prohibit certain types or
-ranges of postdated tickets), and if acceptable, the ticket's start time is
-set as requested and the INVALID flag is set in the new ticket. The
-postdated ticket must be validated before use by presenting it to the KDC
-after the start time has been reached.
-
-The expiration time of the ticket will be set to the minimum of the
-following:
-
-   * The expiration time (endtime) requested in the KRB_AS_REQ message.
-   * The ticket's start time plus the maximum allowable lifetime associated
-     with the client principal (the authentication server's database
-     includes a maximum ticket lifetime field in each principal's record;
-     see section 4).
-   * The ticket's start time plus the maximum allowable lifetime associated
-     with the server principal.
-   * The ticket's start time plus the maximum lifetime set by the policy of
-     the local realm.
-
-If the requested expiration time minus the start time (as determined above)
-is less than a site-determined minimum lifetime, an error message with code
-KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the
-ticket exceeds what was determined as above, and if the 'RENEWABLE-OK'
-option was requested, then the 'RENEWABLE' flag is set in the new ticket,
-and the renew-till value is set as if the 'RENEWABLE' option were requested
-(the field and option names are described fully in section 5.4.1).
-
-If the RENEWABLE option has been requested or if the RENEWABLE-OK option
-has been set and a renewable ticket is to be issued, then the renew-till
-field is set to the minimum of:
-
-   * Its requested value.
-   * The start time of the ticket plus the minimum of the two maximum
-     renewable lifetimes associated with the principals' database entries.
-   * The start time of the ticket plus the maximum renewable lifetime set
-     by the policy of the local realm.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-The flags field of the new ticket will have the following options set if
-they have been requested and if the policy of the local realm allows:
-FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new
-ticket is post-dated (the start time is in the future), its INVALID flag
-will also be set.
-
-If all of the above succeed, the server formats a KRB_AS_REP message (see
-section 5.4.2), copying the addresses in the request into the caddr of the
-response, placing any required pre-authentication data into the padata of
-the response, and encrypts the ciphertext part in the client's key using
-the requested encryption method, and sends it to the client. See section
-A.2 for pseudocode.
-
-3.1.4. Generation of KRB_ERROR message
-
-Several errors can occur, and the Authentication Server responds by
-returning an error message, KRB_ERROR, to the client, with the error-code
-and e-text fields set to appropriate values. The error message contents and
-details are described in Section 5.9.1.
-
-3.1.5. Receipt of KRB_AS_REP message
-
-If the reply message type is KRB_AS_REP, then the client verifies that the
-cname and crealm fields in the cleartext portion of the reply match what it
-requested. If any padata fields are present, they may be used to derive the
-proper secret key to decrypt the message. The client decrypts the encrypted
-part of the response using its secret key, verifies that the nonce in the
-encrypted part matches the nonce it supplied in its request (to detect
-replays). It also verifies that the sname and srealm in the response match
-those in the request (or are otherwise expected values), and that the host
-address field is also correct. It then stores the ticket, session key,
-start and expiration times, and other information for later use. The
-key-expiration field from the encrypted part of the response may be checked
-to notify the user of impending key expiration (the client program could
-then suggest remedial action, such as a password change). See section A.3
-for pseudocode.
-
-Proper decryption of the KRB_AS_REP message is not sufficient to verify the
-identity of the user; the user and an attacker could cooperate to generate
-a KRB_AS_REP format message which decrypts properly but is not from the
-proper KDC. If the host wishes to verify the identity of the user, it must
-require the user to present application credentials which can be verified
-using a securely-stored secret key for the host. If those credentials can
-be verified, then the identity of the user can be assured.
-
-3.1.6. Receipt of KRB_ERROR message
-
-If the reply message type is KRB_ERROR, then the client interprets it as an
-error and performs whatever application-specific tasks are necessary to
-recover. If the client set the CANONICALIZE option and a
-KDC_ERR_WRONG_REALM error was returned, the AS request should be retried to
-the realm and client principal name specified in the error message crealm
-and cname field respectively.
-
-3.2. The Client/Server Authentication Exchange
-
-                             Summary
-Message direction                         Message type    Section
-Client to Application server              KRB_AP_REQ      5.5.1
-[optional] Application server to client   KRB_AP_REP or   5.5.2
-                                          KRB_ERROR       5.9.1
-
-The client/server authentication (CS) exchange is used by network
-applications to authenticate the client to the server and vice versa. The
-client must have already acquired credentials for the server using the AS
-or TGS exchange.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-3.2.1. The KRB_AP_REQ message
-
-The KRB_AP_REQ contains authentication information which should be part of
-the first message in an authenticated transaction. It contains a ticket, an
-authenticator, and some additional bookkeeping information (see section
-5.5.1 for the exact format). The ticket by itself is insufficient to
-authenticate a client, since tickets are passed across the network in
-cleartext[DS90], so the authenticator is used to prevent invalid replay of
-tickets by proving to the server that the client knows the session key of
-the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message
-is referred to elsewhere as the 'authentication header.'
-
-3.2.2. Generation of a KRB_AP_REQ message
-
-When a client wishes to initiate authentication to a server, it obtains
-(either through a credentials cache, the AS exchange, or the TGS exchange)
-a ticket and session key for the desired service. The client may re-use any
-tickets it holds until they expire. To use a ticket the client constructs a
-new Authenticator from the the system time, its name, and optionally an
-application specific checksum, an initial sequence number to be used in
-KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in
-negotiations for a session key unique to this particular session.
-Authenticators may not be re-used and will be rejected if replayed to a
-server[LGDSR87]. If a sequence number is to be included, it should be
-randomly chosen so that even after many messages have been exchanged it is
-not likely to collide with other sequence numbers in use.
-
-The client may indicate a requirement of mutual authentication or the use
-of a session-key based ticket by setting the appropriate flag(s) in the
-ap-options field of the message.
-
-The Authenticator is encrypted in the session key and combined with the
-ticket to form the KRB_AP_REQ message which is then sent to the end server
-along with any additional application-specific information. See section A.9
-for pseudocode.
-
-3.2.3. Receipt of KRB_AP_REQ message
-
-Authentication is based on the server's current time of day (clocks must be
-loosely synchronized), the authenticator, and the ticket. Several errors
-are possible. If an error occurs, the server is expected to reply to the
-client with a KRB_ERROR message. This message may be encapsulated in the
-application protocol if its 'raw' form is not acceptable to the protocol.
-The format of error messages is described in section 5.9.1.
-
-The algorithm for verifying authentication information is as follows. If
-the message type is not KRB_AP_REQ, the server returns the
-KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket in
-the KRB_AP_REQ is not one the server can use (e.g., it indicates an old
-key, and the server no longer possesses a copy of the old key), the
-KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION-KEY flag is set
-in the ap-options field, it indicates to the server that the ticket is
-encrypted in the session key from the server's ticket-granting ticket
-rather than its secret key[10]. Since it is possible for the server to be
-registered in multiple realms, with different keys in each, the srealm
-field in the unencrypted portion of the ticket in the KRB_AP_REQ is used to
-specify which secret key the server should use to decrypt that ticket. The
-KRB_AP_ERR_NOKEY error code is returned if the server doesn't have the
-proper key to decipher the ticket.
-
-The ticket is decrypted using the version of the server's key specified by
-the ticket. If the decryption routines detect a modification of the ticket
-(each encryption system must provide safeguards to detect modified
-ciphertext; see section 6), the KRB_AP_ERR_BAD_INTEGRITY error is returned
-(chances are good that different keys were used to encrypt and decrypt).
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-The authenticator is decrypted using the session key extracted from the
-decrypted ticket. If decryption shows it to have been modified, the
-KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the
-client from the ticket are compared against the same fields in the
-authenticator. If they don't match, the KRB_AP_ERR_BADMATCH error is
-returned (they might not match, for example, if the wrong session key was
-used to encrypt the authenticator). The addresses in the ticket (if any)
-are then searched for an address matching the operating-system reported
-address of the client. If no match is found or the server insists on ticket
-addresses but none are present in the ticket, the KRB_AP_ERR_BADADDR error
-is returned.
-
-If the local (server) time and the client time in the authenticator differ
-by more than the allowable clock skew (e.g., 5 minutes), the
-KRB_AP_ERR_SKEW error is returned. If the server name, along with the
-client name, time and microsecond fields from the Authenticator match any
-recently-seen such tuples, the KRB_AP_ERR_REPEAT error is returned[11]. The
-server must remember any authenticator presented within the allowable clock
-skew, so that a replay attempt is guaranteed to fail. If a server loses
-track of any authenticator presented within the allowable clock skew, it
-must reject all requests until the clock skew interval has passed. This
-assures that any lost or re-played authenticators will fall outside the
-allowable clock skew and can no longer be successfully replayed (If this is
-not done, an attacker could conceivably record the ticket and authenticator
-sent over the network to a server, then disable the client's host, pose as
-the disabled host, and replay the ticket and authenticator to subvert the
-authentication.). If a sequence number is provided in the authenticator,
-the server saves it for later use in processing KRB_SAFE and/or KRB_PRIV
-messages. If a subkey is present, the server either saves it for later use
-or uses it to help generate its own choice for a subkey to be returned in a
-KRB_AP_REP message.
-
-The server computes the age of the ticket: local (server) time minus the
-start time inside the Ticket. If the start time is later than the current
-time by more than the allowable clock skew or if the INVALID flag is set in
-the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the
-current time is later than end time by more than the allowable clock skew,
-the KRB_AP_ERR_TKT_EXPIRED error is returned.
-
-If all these checks succeed without an error, the server is assured that
-the client possesses the credentials of the principal named in the ticket
-and thus, the client has been authenticated to the server. See section A.10
-for pseudocode.
-
-Passing these checks provides only authentication of the named principal;
-it does not imply authorization to use the named service. Applications must
-make a separate authorization decisions based upon the authenticated name
-of the user, the requested operation, local acces control information such
-as that contained in a .k5login or .k5users file, and possibly a separate
-distributed authorization service.
-
-3.2.4. Generation of a KRB_AP_REP message
-
-Typically, a client's request will include both the authentication
-information and its initial request in the same message, and the server
-need not explicitly reply to the KRB_AP_REQ. However, if mutual
-authentication (not only authenticating the client to the server, but also
-the server to the client) is being performed, the KRB_AP_REQ message will
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-have MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message
-is required in response. As with the error message, this message may be
-encapsulated in the application protocol if its "raw" form is not
-acceptable to the application's protocol. The timestamp and microsecond
-field used in the reply must be the client's timestamp and microsecond
-field (as provided in the authenticator)[12]. If a sequence number is to be
-included, it should be randomly chosen as described above for the
-authenticator. A subkey may be included if the server desires to negotiate
-a different subkey. The KRB_AP_REP message is encrypted in the session key
-extracted from the ticket. See section A.11 for pseudocode.
-
-3.2.5. Receipt of KRB_AP_REP message
-
-If a KRB_AP_REP message is returned, the client uses the session key from
-the credentials obtained for the server[13] to decrypt the message, and
-verifies that the timestamp and microsecond fields match those in the
-Authenticator it sent to the server. If they match, then the client is
-assured that the server is genuine. The sequence number and subkey (if
-present) are retained for later use. See section A.12 for pseudocode.
-
-3.2.6. Using the encryption key
-
-After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
-server share an encryption key which can be used by the application. The
-'true session key' to be used for KRB_PRIV, KRB_SAFE, or other
-application-specific uses may be chosen by the application based on the
-subkeys in the KRB_AP_REP message and the authenticator[14]. In some cases,
-the use of this session key will be implicit in the protocol; in others the
-method of use must be chosen from several alternatives. We leave the
-protocol negotiations of how to use the key (e.g. selecting an encryption
-or checksum type) to the application programmer; the Kerberos protocol does
-not constrain the implementation options, but an example of how this might
-be done follows.
-
-One way that an application may choose to negotiate a key to be used for
-subequent integrity and privacy protection is for the client to propose a
-key in the subkey field of the authenticator. The server can then choose a
-key using the proposed key from the client as input, returning the new
-subkey in the subkey field of the application reply. This key could then be
-used for subsequent communication. To make this example more concrete, if
-the encryption method in use required a 56 bit key, and for whatever
-reason, one of the parties was prevented from using a key with more than 40
-unknown bits, this method would allow the the party which is prevented from
-using more than 40 bits to either propose (if the client) an initial key
-with a known quantity for 16 of those bits, or to mask 16 of the bits (if
-the server) with the known quantity. The application implementor is warned,
-however, that this is only an example, and that an analysis of the
-particular crytosystem to be used, and the reasons for limiting the key
-length, must be made before deciding whether it is acceptable to mask bits
-of the key.
-
-With both the one-way and mutual authentication exchanges, the peers should
-take care not to send sensitive information to each other without proper
-assurances. In particular, applications that require privacy or integrity
-should use the KRB_AP_REP response from the server to client to assure both
-client and server of their peer's identity. If an application protocol
-requires privacy of its messages, it can use the KRB_PRIV message (section
-3.5). The KRB_SAFE message (section 3.4) can be used to assure integrity.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-3.3. The Ticket-Granting Service (TGS) Exchange
-
-                          Summary
-      Message direction       Message type     Section
-      1. Client to Kerberos   KRB_TGS_REQ      5.4.1
-      2. Kerberos to client   KRB_TGS_REP or   5.4.2
-                              KRB_ERROR        5.9.1
-
-The TGS exchange between a client and the Kerberos Ticket-Granting Server
-is initiated by a client when it wishes to obtain authentication
-credentials for a given server (which might be registered in a remote
-realm), when it wishes to renew or validate an existing ticket, or when it
-wishes to obtain a proxy ticket. In the first case, the client must already
-have acquired a ticket for the Ticket-Granting Service using the AS
-exchange (the ticket-granting ticket is usually obtained when a client
-initially authenticates to the system, such as when a user logs in). The
-message format for the TGS exchange is almost identical to that for the AS
-exchange. The primary difference is that encryption and decryption in the
-TGS exchange does not take place under the client's key. Instead, the
-session key from the ticket-granting ticket or renewable ticket, or
-sub-session key from an Authenticator is used. As is the case for all
-application servers, expired tickets are not accepted by the TGS, so once a
-renewable or ticket-granting ticket expires, the client must use a separate
-exchange to obtain valid tickets.
-
-The TGS exchange consists of two messages: A request (KRB_TGS_REQ) from the
-client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or
-KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the
-client plus a request for credentials. The authentication information
-consists of the authentication header (KRB_AP_REQ) which includes the
-client's previously obtained ticket-granting, renewable, or invalid ticket.
-In the ticket-granting ticket and proxy cases, the request may include one
-or more of: a list of network addresses, a collection of typed
-authorization data to be sealed in the ticket for authorization use by the
-application server, or additional tickets (the use of which are described
-later). The TGS reply (KRB_TGS_REP) contains the requested credentials,
-encrypted in the session key from the ticket-granting ticket or renewable
-ticket, or if present, in the sub-session key from the Authenticator (part
-of the authentication header). The KRB_ERROR message contains an error code
-and text explaining what went wrong. The KRB_ERROR message is not
-encrypted. The KRB_TGS_REP message contains information which can be used
-to detect replays, and to associate it with the message to which it
-replies. The KRB_ERROR message also contains information which can be used
-to associate it with the message to which it replies, but the lack of
-encryption in the KRB_ERROR message precludes the ability to detect replays
-or fabrications of such messages.
-
-3.3.1. Generation of KRB_TGS_REQ message
-
-Before sending a request to the ticket-granting service, the client must
-determine in which realm the application server is registered[15], if it is
-known. If the client does know the service principal name and realm and it
-does not already possess a ticket-granting ticket for the appropriate
-realm, then one must be obtained. This is first attempted by requesting a
-ticket-granting ticket for the destination realm from a Kerberos server for
-which the client does posess a ticket-granting ticket (using the
-KRB_TGS_REQ message recursively). The Kerberos server may return a TGT for
-the desired realm in which case one can proceed.
-
-If the client does not know the realm of the service or the true service
-principal name, then the CANONICALIZE option must be used in the request.
-This will cause the TGS to locate the service principal based on the target
-service name in the ticket and return the service principal name in the
-response. Alternatively, the Kerberos server may return a TGT for a realm
-which is 'closer' to the desired realm (further along the standard
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-hierarchical path) or the realm that may contain the requested service
-principal name in a request with the CANONCALIZE option set [JBrezak], in
-which case this step must be repeated with a Kerberos server in the realm
-specified in the returned TGT. If neither are returned, then the request
-must be retried with a Kerberos server for a realm higher in the hierarchy.
-This request will itself require a ticket-granting ticket for the higher
-realm which must be obtained by recursively applying these directions.
-
-Once the client obtains a ticket-granting ticket for the appropriate realm,
-it determines which Kerberos servers serve that realm, and contacts one.
-The list might be obtained through a configuration file or network service
-or it may be generated from the name of the realm; as long as the secret
-keys exchanged by realms are kept secret, only denial of service results
-from using a false Kerberos server.
-
-As in the AS exchange, the client may specify a number of options in the
-KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing
-an authentication header as an element of the padata field, and including
-the same fields as used in the KRB_AS_REQ message along with several
-optional fields: the enc-authorization-data field for application server
-use and additional tickets required by some options.
-
-In preparing the authentication header, the client can select a sub-session
-key under which the response from the Kerberos server will be
-encrypted[16]. If the sub-session key is not specified, the session key
-from the ticket-granting ticket will be used. If the enc-authorization-data
-is present, it must be encrypted in the sub-session key, if present, from
-the authenticator portion of the authentication header, or if not present,
-using the session key from the ticket-granting ticket.
-
-Once prepared, the message is sent to a Kerberos server for the destination
-realm. See section A.5 for pseudocode.
-
-3.3.2. Receipt of KRB_TGS_REQ message
-
-The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ
-message, but there are many additional checks to be performed. First, the
-Kerberos server must determine which server the accompanying ticket is for
-and it must select the appropriate key to decrypt it. For a normal
-KRB_TGS_REQ message, it will be for the ticket granting service, and the
-TGS's key will be used. If the TGT was issued by another realm, then the
-appropriate inter-realm key must be used. If the accompanying ticket is not
-a ticket granting ticket for the current realm, but is for an application
-server in the current realm, the RENEW, VALIDATE, or PROXY options are
-specified in the request, and the server for which a ticket is requested is
-the server named in the accompanying ticket, then the KDC will decrypt the
-ticket in the authentication header using the key of the server for which
-it was issued. If no ticket can be found in the padata field, the
-KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
-
-Once the accompanying ticket has been decrypted, the user-supplied checksum
-in the Authenticator must be verified against the contents of the request,
-and the message rejected if the checksums do not match (with an error code
-of KRB_AP_ERR_MODIFIED) or if the checksum is not keyed or not
-collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the
-checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is
-returned. If the authorization-data are present, they are decrypted using
-the sub-session key from the Authenticator.
-
-If any of the decryptions indicate failed integrity checks, the
-KRB_AP_ERR_BAD_INTEGRITY error is returned. If the CANONICALIZE option is
-set in the KRB_TGS_REQ, then the requested service name may not be the true
-principal name or the service may not be in the TGS realm.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-3.3.3. Generation of KRB_TGS_REP message
-
-The KRB_TGS_REP message shares its format with the KRB_AS_REP
-(KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The detailed
-specification is in section 5.4.2.
-
-The response will include a ticket for the requested server. The Kerberos
-database is queried to retrieve the record for the requested server
-(including the key with which the ticket will be encrypted). If the request
-is for a ticket granting ticket for a remote realm, and if no key is shared
-with the requested realm, then the Kerberos server will select the realm
-"closest" to the requested realm with which it does share a key, and use
-that realm instead. If the CANONICALIZE option is set, the TGS may return a
-ticket containing the server name of the true service principal. If the
-requested server cannot be found in the TGS database, then a TGT for
-another trusted realm may be returned instead of a ticket for the service.
-This TGT is a referral mechanism to cause the client to retry the request
-to the realm of the TGT. These are the only cases where the response for
-the KDC will be for a different server than that requested by the client.
-
-By default, the address field, the client's name and realm, the list of
-transited realms, the time of initial authentication, the expiration time,
-and the authorization data of the newly-issued ticket will be copied from
-the ticket-granting ticket (TGT) or renewable ticket. If the transited
-field needs to be updated, but the transited type is not supported, the
-KDC_ERR_TRTYPE_NOSUPP error is returned.
-
-If the request specifies an endtime, then the endtime of the new ticket is
-set to the minimum of (a) that request, (b) the endtime from the TGT, and
-(c) the starttime of the TGT plus the minimum of the maximum life for the
-application server and the maximum life for the local realm (the maximum
-life for the requesting principal was already applied when the TGT was
-issued). If the new ticket is to be a renewal, then the endtime above is
-replaced by the minimum of (a) the value of the renew_till field of the
-ticket and (b) the starttime for the new ticket plus the life
-(endtime-starttime) of the old ticket.
-
-If the FORWARDED option has been requested, then the resulting ticket will
-contain the addresses specified by the client. This option will only be
-honored if the FORWARDABLE flag is set in the TGT. The PROXY option is
-similar; the resulting ticket will contain the addresses specified by the
-client. It will be honored only if the PROXIABLE flag in the TGT is set.
-The PROXY option will not be honored on requests for additional
-ticket-granting tickets.
-
-If the requested start time is absent, indicates a time in the past, or is
-within the window of acceptable clock skew for the KDC and the POSTDATE
-option has not been specified, then the start time of the ticket is set to
-the authentication server's current time. If it indicates a time in the
-future beyond the acceptable clock skew, but the POSTDATED option has not
-been specified or the MAY-POSTDATE flag is not set in the TGT, then the
-error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the
-ticket-granting ticket has the MAY-POSTDATE flag set, then the resulting
-ticket will be postdated and the requested starttime is checked against the
-policy of the local realm. If acceptable, the ticket's start time is set as
-requested, and the INVALID flag is set. The postdated ticket must be
-validated before use by presenting it to the KDC after the starttime has
-been reached. However, in no case may the starttime, endtime, or renew-till
-time of a newly-issued postdated ticket extend beyond the renew-till time
-of the ticket-granting ticket.
-
-If the ENC-TKT-IN-SKEY option has been specified and an additional ticket
-has been included in the request, the KDC will decrypt the additional
-ticket using the key for the server to which the additional ticket was
-issued and verify that it is a ticket-granting ticket. If the name of the
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-requested server is missing from the request, the name of the client in the
-additional ticket will be used. Otherwise the name of the requested server
-will be compared to the name of the client in the additional ticket and if
-different, the request will be rejected. If the request succeeds, the
-session key from the additional ticket will be used to encrypt the new
-ticket that is issued instead of using the key of the server for which the
-new ticket will be used[17].
-
-If the name of the server in the ticket that is presented to the KDC as
-part of the authentication header is not that of the ticket-granting server
-itself, the server is registered in the realm of the KDC, and the RENEW
-option is requested, then the KDC will verify that the RENEWABLE flag is
-set in the ticket, that the INVALID flag is not set in the ticket, and that
-the renew_till time is still in the future. If the VALIDATE option is
-rqeuested, the KDC will check that the starttime has passed and the INVALID
-flag is set. If the PROXY option is requested, then the KDC will check that
-the PROXIABLE flag is set in the ticket. If the tests succeed, and the
-ticket passes the hotlist check described in the next paragraph, the KDC
-will issue the appropriate new ticket.
-
-3.3.3.1. Checking for revoked tickets
-
-Whenever a request is made to the ticket-granting server, the presented
-ticket(s) is(are) checked against a hot-list of tickets which have been
-canceled. This hot-list might be implemented by storing a range of issue
-timestamps for 'suspect tickets'; if a presented ticket had an authtime in
-that range, it would be rejected. In this way, a stolen ticket-granting
-ticket or renewable ticket cannot be used to gain additional tickets
-(renewals or otherwise) once the theft has been reported. Any normal ticket
-obtained before it was reported stolen will still be valid (because they
-require no interaction with the KDC), but only until their normal
-expiration time.
-
-The ciphertext part of the response in the KRB_TGS_REP message is encrypted
-in the sub-session key from the Authenticator, if present, or the session
-key key from the ticket-granting ticket. It is not encrypted using the
-client's secret key. Furthermore, the client's key's expiration date and
-the key version number fields are left out since these values are stored
-along with the client's database record, and that record is not needed to
-satisfy a request based on a ticket-granting ticket. See section A.6 for
-pseudocode.
-
-3.3.3.2. Encoding the transited field
-
-If the identity of the server in the TGT that is presented to the KDC as
-part of the authentication header is that of the ticket-granting service,
-but the TGT was issued from another realm, the KDC will look up the
-inter-realm key shared with that realm and use that key to decrypt the
-ticket. If the ticket is valid, then the KDC will honor the request,
-subject to the constraints outlined above in the section describing the AS
-exchange. The realm part of the client's identity will be taken from the
-ticket-granting ticket. The name of the realm that issued the
-ticket-granting ticket will be added to the transited field of the ticket
-to be issued. This is accomplished by reading the transited field from the
-ticket-granting ticket (which is treated as an unordered set of realm
-names), adding the new realm to the set, then constructing and writing out
-its encoded (shorthand) form (this may involve a rearrangement of the
-existing encoding).
-
-Note that the ticket-granting service does not add the name of its own
-realm. Instead, its responsibility is to add the name of the previous
-realm. This prevents a malicious Kerberos server from intentionally leaving
-out its own name (it could, however, omit other realms' names).
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-The names of neither the local realm nor the principal's realm are to be
-included in the transited field. They appear elsewhere in the ticket and
-both are known to have taken part in authenticating the principal. Since
-the endpoints are not included, both local and single-hop inter-realm
-authentication result in a transited field that is empty.
-
-Because the name of each realm transited is added to this field, it might
-potentially be very long. To decrease the length of this field, its
-contents are encoded. The initially supported encoding is optimized for the
-normal case of inter-realm communication: a hierarchical arrangement of
-realms using either domain or X.500 style realm names. This encoding
-(called DOMAIN-X500-COMPRESS) is now described.
-
-Realm names in the transited field are separated by a ",". The ",", "\",
-trailing "."s, and leading spaces (" ") are special characters, and if they
-are part of a realm name, they must be quoted in the transited field by
-preced- ing them with a "\".
-
-A realm name ending with a "." is interpreted as being prepended to the
-previous realm. For example, we can encode traversal of EDU, MIT.EDU,
-ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
-
-     "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
-
-Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points, that
-they would not be included in this field, and we would have:
-
-     "EDU,MIT.,WASHINGTON.EDU"
-
-A realm name beginning with a "/" is interpreted as being appended to the
-previous realm[18]. If it is to stand by itself, then it should be preceded
-by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO,
-/COM/HP, /COM, and /COM/DEC as:
-
-     "/COM,/HP,/APOLLO, /COM/DEC".
-
-Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints, they
-they would not be included in this field, and we would have:
-
-     "/COM,/HP"
-
-A null subfield preceding or following a "," indicates that all realms
-between the previous realm and the next realm have been traversed[19].
-Thus, "," means that all realms along the path between the client and the
-server have been traversed. ",EDU, /COM," means that that all realms from
-the client's realm up to EDU (in a domain style hierarchy) have been
-traversed, and that everything from /COM down to the server's realm in an
-X.500 style has also been traversed. This could occur if the EDU realm in
-one hierarchy shares an inter-realm key directly with the /COM realm in
-another hierarchy.
-
-3.3.4. Receipt of KRB_TGS_REP message
-
-When the KRB_TGS_REP is received by the client, it is processed in the same
-manner as the KRB_AS_REP processing described above. The primary difference
-is that the ciphertext part of the response must be decrypted using the
-session key from the ticket-granting ticket rather than the client's secret
-key. The server name returned in the reply is the true principal name of
-the service. See section A.7 for pseudocode.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-3.4. The KRB_SAFE Exchange
-
-The KRB_SAFE message may be used by clients requiring the ability to detect
-modifications of messages they exchange. It achieves this by including a
-keyed collision-proof checksum of the user data and some control
-information. The checksum is keyed with an encryption key (usually the last
-key negotiated via subkeys, or the session key if no negotiation has
-occured).
-
-3.4.1. Generation of a KRB_SAFE message
-
-When an application wishes to send a KRB_SAFE message, it collects its data
-and the appropriate control information and computes a checksum over them.
-The checksum algorithm should be a keyed one-way hash function (such as the
-RSA- MD5-DES checksum algorithm specified in section 6.4.5, or the DES
-MAC), generated using the sub-session key if present, or the session key.
-Different algorithms may be selected by changing the checksum type in the
-message. Unkeyed or non-collision-proof checksums are not suitable for this
-use.
-
-The control information for the KRB_SAFE message includes both a timestamp
-and a sequence number. The designer of an application using the KRB_SAFE
-message must choose at least one of the two mechanisms. This choice should
-be based on the needs of the application protocol.
-
-Sequence numbers are useful when all messages sent will be received by
-one's peer. Connection state is presently required to maintain the session
-key, so maintaining the next sequence number should not present an
-additional problem.
-
-If the application protocol is expected to tolerate lost messages without
-them being resent, the use of the timestamp is the appropriate replay
-detection mechanism. Using timestamps is also the appropriate mechanism for
-multi-cast protocols where all of one's peers share a common sub-session
-key, but some messages will be sent to a subset of one's peers.
-
-After computing the checksum, the client then transmits the information and
-checksum to the recipient in the message format specified in section 5.6.1.
-
-3.4.2. Receipt of KRB_SAFE message
-
-When an application receives a KRB_SAFE message, it verifies it as follows.
-If any error occurs, an error code is reported for use by the application.
-
-The message is first checked by verifying that the protocol version and
-type fields match the current version and KRB_SAFE, respectively. A
-mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error.
-The application verifies that the checksum used is a collision-proof keyed
-checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. If
-the sender's address was included in the control information, the recipient
-verifies that the operating system's report of the sender's address matches
-the sender's address in the message, and (if a recipient address is
-specified or the recipient requires an address) that one of the recipient's
-addresses appears as the recipient's address in the message. A failed match
-for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp
-and usec and/or the sequence number fields are checked. If timestamp and
-usec are expected and not present, or they are present but not current, the
-KRB_AP_ERR_SKEW error is generated. If the server name, along with the
-client name, time and microsecond fields from the Authenticator match any
-recently-seen (sent or received[20] ) such tuples, the KRB_AP_ERR_REPEAT
-error is generated. If an incorrect sequence number is included, or a
-sequence number is expected but not present, the KRB_AP_ERR_BADORDER error
-is generated. If neither a time-stamp and usec or a sequence number is
-present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is
-computed over the data and control information, and if it doesn't match the
-received checksum, a KRB_AP_ERR_MODIFIED error is generated.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-If all the checks succeed, the application is assured that the message was
-generated by its peer and was not modi- fied in transit.
-
-3.5. The KRB_PRIV Exchange
-
-The KRB_PRIV message may be used by clients requiring confidentiality and
-the ability to detect modifications of exchanged messages. It achieves this
-by encrypting the messages and adding control information.
-
-3.5.1. Generation of a KRB_PRIV message
-
-When an application wishes to send a KRB_PRIV message, it collects its data
-and the appropriate control information (specified in section 5.7.1) and
-encrypts them under an encryption key (usually the last key negotiated via
-subkeys, or the session key if no negotiation has occured). As part of the
-control information, the client must choose to use either a timestamp or a
-sequence number (or both); see the discussion in section 3.4.1 for
-guidelines on which to use. After the user data and control information are
-encrypted, the client transmits the ciphertext and some 'envelope'
-information to the recipient.
-
-3.5.2. Receipt of KRB_PRIV message
-
-When an application receives a KRB_PRIV message, it verifies it as follows.
-If any error occurs, an error code is reported for use by the application.
-
-The message is first checked by verifying that the protocol version and
-type fields match the current version and KRB_PRIV, respectively. A
-mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error.
-The application then decrypts the ciphertext and processes the resultant
-plaintext. If decryption shows the data to have been modified, a
-KRB_AP_ERR_BAD_INTEGRITY error is generated. If the sender's address was
-included in the control information, the recipient verifies that the
-operating system's report of the sender's address matches the sender's
-address in the message, and (if a recipient address is specified or the
-recipient requires an address) that one of the recipient's addresses
-appears as the recipient's address in the message. A failed match for
-either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and
-usec and/or the sequence number fields are checked. If timestamp and usec
-are expected and not present, or they are present but not current, the
-KRB_AP_ERR_SKEW error is generated. If the server name, along with the
-client name, time and microsecond fields from the Authenticator match any
-recently-seen such tuples, the KRB_AP_ERR_REPEAT error is generated. If an
-incorrect sequence number is included, or a sequence number is expected but
-not present, the KRB_AP_ERR_BADORDER error is generated. If neither a
-time-stamp and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED
-error is generated.
-
-If all the checks succeed, the application can assume the message was
-generated by its peer, and was securely transmitted (without intruders able
-to see the unencrypted contents).
-
-3.6. The KRB_CRED Exchange
-
-The KRB_CRED message may be used by clients requiring the ability to send
-Kerberos credentials from one host to another. It achieves this by sending
-the tickets together with encrypted data containing the session keys and
-other information associated with the tickets.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-3.6.1. Generation of a KRB_CRED message
-
-When an application wishes to send a KRB_CRED message it first (using the
-KRB_TGS exchange) obtains credentials to be sent to the remote host. It
-then constructs a KRB_CRED message using the ticket or tickets so obtained,
-placing the session key needed to use each ticket in the key field of the
-corresponding KrbCredInfo sequence of the encrypted part of the the
-KRB_CRED message.
-
-Other information associated with each ticket and obtained during the
-KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence
-in the encrypted part of the KRB_CRED message. The current time and, if
-specifically required by the application the nonce, s-address, and
-r-address fields, are placed in the encrypted part of the KRB_CRED message
-which is then encrypted under an encryption key previosuly exchanged in the
-KRB_AP exchange (usually the last key negotiated via subkeys, or the
-session key if no negotiation has occured).
-
-3.6.2. Receipt of KRB_CRED message
-
-When an application receives a KRB_CRED message, it verifies it. If any
-error occurs, an error code is reported for use by the application. The
-message is verified by checking that the protocol version and type fields
-match the current version and KRB_CRED, respectively. A mismatch generates
-a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then
-decrypts the ciphertext and processes the resultant plaintext. If
-decryption shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY
-error is generated.
-
-If present or required, the recipient verifies that the operating system's
-report of the sender's address matches the sender's address in the message,
-and that one of the recipient's addresses appears as the recipient's
-address in the message. A failed match for either case generates a
-KRB_AP_ERR_BADADDR error. The timestamp and usec fields (and the nonce
-field if required) are checked next. If the timestamp and usec are not
-present, or they are present but not current, the KRB_AP_ERR_SKEW error is
-generated.
-
-If all the checks succeed, the application stores each of the new tickets
-in its ticket cache together with the session key and other information in
-the corresponding KrbCredInfo sequence from the encrypted part of the
-KRB_CRED message.
-
-4. The Kerberos Database
-
-The Kerberos server must have access to a database containing the principal
-identifiers and secret keys of principals to be authenticated[21].
-
-4.1. Database contents
-
-A database entry should contain at least the following fields:
-
-Field                Value
-
-name                 Principal's identifier
-key                  Principal's secret key
-p_kvno               Principal's key version
-max_life             Maximum lifetime for Tickets
-max_renewable_life   Maximum total lifetime for renewable Tickets
-
-The name field is an encoding of the principal's identifier. The key field
-contains an encryption key. This key is the principal's secret key. (The
-key can be encrypted before storage under a Kerberos "master key" to
-protect it in case the database is compromised but the master key is not.
-In that case, an extra field must be added to indicate the master key
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-version used, see below.) The p_kvno field is the key version number of the
-principal's secret key. The max_life field contains the maximum allowable
-lifetime (endtime - starttime) for any Ticket issued for this principal.
-The max_renewable_life field contains the maximum allowable total lifetime
-for any renewable Ticket issued for this principal. (See section 3.1 for a
-description of how these lifetimes are used in determining the lifetime of
-a given Ticket.)
-
-A server may provide KDC service to several realms, as long as the database
-representation provides a mechanism to distinguish between principal
-records with identifiers which differ only in the realm name.
-
-When an application server's key changes, if the change is routine (i.e.
-not the result of disclosure of the old key), the old key should be
-retained by the server until all tickets that had been issued using that
-key have expired. Because of this, it is possible for several keys to be
-active for a single principal. Ciphertext encrypted in a principal's key is
-always tagged with the version of the key that was used for encryption, to
-help the recipient find the proper key for decryption.
-
-When more than one key is active for a particular principal, the principal
-will have more than one record in the Kerberos database. The keys and key
-version numbers will differ between the records (the rest of the fields may
-or may not be the same). Whenever Kerberos issues a ticket, or responds to
-a request for initial authentication, the most recent key (known by the
-Kerberos server) will be used for encryption. This is the key with the
-highest key version number.
-
-4.2. Additional fields
-
-Project Athena's KDC implementation uses additional fields in its database:
-
-Field        Value
-
-K_kvno       Kerberos' key version
-expiration   Expiration date for entry
-attributes   Bit field of attributes
-mod_date     Timestamp of last modification
-mod_name     Modifying principal's identifier
-
-The K_kvno field indicates the key version of the Kerberos master key under
-which the principal's secret key is encrypted.
-
-After an entry's expiration date has passed, the KDC will return an error
-to any client attempting to gain tickets as or for the principal. (A
-database may want to maintain two expiration dates: one for the principal,
-and one for the principal's current key. This allows password aging to work
-independently of the principal's expiration date. However, due to the
-limited space in the responses, the KDC must combine the key expiration and
-principal expiration date into a single value called 'key_exp', which is
-used as a hint to the user to take administrative action.)
-
-The attributes field is a bitfield used to govern the operations involving
-the principal. This field might be useful in conjunction with user
-registration procedures, for site-specific policy implementations (Project
-Athena currently uses it for their user registration process controlled by
-the system-wide database service, Moira [LGDSR87]), to identify whether a
-principal can play the role of a client or server or both, to note whether
-a server is appropriate trusted to recieve credentials delegated by a
-client, or to identify the 'string to key' conversion algorithm used for a
-principal's key[22]. Other bits are used to indicate that certain ticket
-options should not be allowed in tickets encrypted under a principal's key
-(one bit each): Disallow issuing postdated tickets, disallow issuing
-forwardable tickets, disallow issuing tickets based on TGT authentication,
-disallow issuing renewable tickets, disallow issuing proxiable tickets, and
-disallow issuing tickets for which the principal is the server.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-The mod_date field contains the time of last modification of the entry, and
-the mod_name field contains the name of the principal which last modified
-the entry.
-
-4.3. Frequently Changing Fields
-
-Some KDC implementations may wish to maintain the last time that a request
-was made by a particular principal. Information that might be maintained
-includes the time of the last request, the time of the last request for a
-ticket-granting ticket, the time of the last use of a ticket-granting
-ticket, or other times. This information can then be returned to the user
-in the last-req field (see section 5.2).
-
-Other frequently changing information that can be maintained is the latest
-expiration time for any tickets that have been issued using each key. This
-field would be used to indicate how long old keys must remain valid to
-allow the continued use of outstanding tickets.
-
-4.4. Site Constants
-
-The KDC implementation should have the following configurable constants or
-options, to allow an administrator to make and enforce policy decisions:
-
-   * The minimum supported lifetime (used to determine whether the
-     KDC_ERR_NEVER_VALID error should be returned). This constant should
-     reflect reasonable expectations of round-trip time to the KDC,
-     encryption/decryption time, and processing time by the client and
-     target server, and it should allow for a minimum 'useful' lifetime.
-   * The maximum allowable total (renewable) lifetime of a ticket
-     (renew_till - starttime).
-   * The maximum allowable lifetime of a ticket (endtime - starttime).
-   * Whether to allow the issue of tickets with empty address fields
-     (including the ability to specify that such tickets may only be issued
-     if the request specifies some authorization_data).
-   * Whether proxiable, forwardable, renewable or post-datable tickets are
-     to be issued.
-
-5. Message Specifications
-
-The following sections describe the exact contents and encoding of protocol
-messages and objects. The ASN.1 base definitions are presented in the first
-subsection. The remaining subsections specify the protocol objects (tickets
-and authenticators) and messages. Specification of encryption and checksum
-techniques, and the fields related to them, appear in section 6.
-
-Optional field in ASN.1 sequences
-
-For optional integer value and date fields in ASN.1 sequences where a
-default value has been specified, certain default values will not be
-allowed in the encoding because these values will always be represented
-through defaulting by the absence of the optional field. For example, one
-will not send a microsecond zero value because one must make sure that
-there is only one way to encode this value.
-
-Additional fields in ASN.1 sequences
-
-Implementations receiving Kerberos messages with additional fields present
-in ASN.1 sequences should carry the those fields through, unmodified, when
-the message is forwarded. Implementations should not drop such fields if
-the sequence is reencoded.
-
-5.1. ASN.1 Distinguished Encoding Representation
-
-All uses of ASN.1 in Kerberos shall use the Distinguished Encoding
-Representation of the data elements as described in the X.509
-specification, section 8.7 [X509-88].
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-5.2. ASN.1 Base Definitions
-
-The following ASN.1 base definitions are used in the rest of this section.
-Note that since the underscore character (_) is not permitted in ASN.1
-names, the hyphen (-) is used in its place for the purposes of ASN.1 names.
-
-Realm ::=           GeneralString
-PrincipalName ::=   SEQUENCE {
-                    name-type[0]     INTEGER,
-                    name-string[1]   SEQUENCE OF GeneralString
-}
-
-Kerberos realms are encoded as GeneralStrings. Realms shall not contain a
-character with the code 0 (the ASCII NUL). Most realms will usually consist
-of several components separated by periods (.), in the style of Internet
-Domain Names, or separated by slashes (/) in the style of X.500 names.
-Acceptable forms for realm names are specified in section 7. A
-PrincipalName is a typed sequence of components consisting of the following
-sub-fields:
-
-name-type
-     This field specifies the type of name that follows. Pre-defined values
-     for this field are specified in section 7.2. The name-type should be
-     treated as a hint. Ignoring the name type, no two names can be the
-     same (i.e. at least one of the components, or the realm, must be
-     different). This constraint may be eliminated in the future.
-name-string
-     This field encodes a sequence of components that form a name, each
-     component encoded as a GeneralString. Taken together, a PrincipalName
-     and a Realm form a principal identifier. Most PrincipalNames will have
-     only a few components (typically one or two).
-
-KerberosTime ::=   GeneralizedTime
-                   -- Specifying UTC time zone (Z)
-
-The timestamps used in Kerberos are encoded as GeneralizedTimes. An
-encoding shall specify the UTC time zone (Z) and shall not include any
-fractional portions of the seconds. It further shall not include any
-separators. Example: The only valid format for UTC time 6 minutes, 27
-seconds after 9 pm on 6 November 1985 is 19851106210627Z.
-
-HostAddress ::=     SEQUENCE  {
-                    addr-type[0]             INTEGER,
-                    address[1]               OCTET STRING
-}
-
-HostAddresses ::=   SEQUENCE OF HostAddress
-
-The host adddress encodings consists of two fields:
-
-addr-type
-     This field specifies the type of address that follows. Pre-defined
-     values for this field are specified in section 8.1.
-address
-     This field encodes a single address of type addr-type.
-
-The two forms differ slightly. HostAddress contains exactly one address;
-HostAddresses contains a sequence of possibly many addresses.
-
-AuthorizationData ::=   SEQUENCE OF SEQUENCE {
-                        ad-type[0]               INTEGER,
-                        ad-data[1]               OCTET STRING
-}
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-ad-data
-     This field contains authorization data to be interpreted according to
-     the value of the corresponding ad-type field.
-ad-type
-     This field specifies the format for the ad-data subfield. All negative
-     values are reserved for local use. Non-negative values are reserved
-     for registered use.
-
-Each sequence of type and data is refered to as an authorization element.
-Elements may be application specific, however, there is a common set of
-recursive elements that should be understood by all implementations. These
-elements contain other elements embedded within them, and the
-interpretation of the encapsulating element determines which of the
-embedded elements must be interpreted, and which may be ignored.
-Definitions for these common elements may be found in Appendix B.
-
-TicketExtensions ::= SEQUENCE OF SEQUENCE {
-           te-type[0]       INTEGER,
-           te-data[1]       OCTET STRING
-}
-
-
-
-te-data
-     This field contains opaque data that must be caried with the ticket to
-     support extensions to the Kerberos protocol including but not limited
-     to some forms of inter-realm key exchange and plaintext authorization
-     data. See appendix C for some common uses of this field.
-te-type
-     This field specifies the format for the te-data subfield. All negative
-     values are reserved for local use. Non-negative values are reserved
-     for registered use.
-
-APOptions ::=   BIT STRING
-                  -- reserved(0),
-                  -- use-session-key(1),
-                  -- mutual-required(2)
-
-TicketFlags ::= BIT STRING
-                  -- reserved(0),
-                  -- forwardable(1),
-                  -- forwarded(2),
-                  -- proxiable(3),
-                  -- proxy(4),
-                  -- may-postdate(5),
-                  -- postdated(6),
-                  -- invalid(7),
-                  -- renewable(8),
-                  -- initial(9),
-                  -- pre-authent(10),
-                  -- hw-authent(11),
-                  -- transited-policy-checked(12),
-                  -- ok-as-delegate(13)
-
-KDCOptions ::=   BIT STRING io
-                  -- reserved(0),
-                  -- forwardable(1),
-                  -- forwarded(2),
-                  -- proxiable(3),
-                  -- proxy(4),
-                  -- allow-postdate(5),
-                  -- postdated(6),
-                  -- unused7(7),
-                  -- renewable(8),
-                  -- unused9(9),
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-                  -- unused10(10),
-                  -- unused11(11),
-                  -- unused12(12),
-                  -- unused13(13),
-                  -- requestanonymous(14),
-                  -- canonicalize(15),
-                  -- disable-transited-check(26),
-                  -- renewable-ok(27),
-                  -- enc-tkt-in-skey(28),
-                  -- renew(30),
-                  -- validate(31)
-
-ASN.1 Bit strings have a length and a value. When used in Kerberos for the
-APOptions, TicketFlags, and KDCOptions, the length of the bit string on
-generated values should be the smallest number of bits needed to include
-the highest order bit that is set (1), but in no case less than 32 bits.
-The ASN.1 representation of the bit strings uses unnamed bits, with the
-meaning of the individual bits defined by the comments in the specification
-above. Implementations should accept values of bit strings of any length
-and treat the value of flags corresponding to bits beyond the end of the
-bit string as if the bit were reset (0). Comparison of bit strings of
-different length should treat the smaller string as if it were padded with
-zeros beyond the high order bits to the length of the longer string[23].
-
-LastReq ::=   SEQUENCE OF SEQUENCE {
-               lr-type[0]               INTEGER,
-               lr-value[1]              KerberosTime
-}
-
-lr-type
-     This field indicates how the following lr-value field is to be
-     interpreted. Negative values indicate that the information pertains
-     only to the responding server. Non-negative values pertain to all
-     servers for the realm. If the lr-type field is zero (0), then no
-     information is conveyed by the lr-value subfield. If the absolute
-     value of the lr-type field is one (1), then the lr-value subfield is
-     the time of last initial request for a TGT. If it is two (2), then the
-     lr-value subfield is the time of last initial request. If it is three
-     (3), then the lr-value subfield is the time of issue for the newest
-     ticket-granting ticket used. If it is four (4), then the lr-value
-     subfield is the time of the last renewal. If it is five (5), then the
-     lr-value subfield is the time of last request (of any type). If it is
-     (6), then the lr-value subfield is the time when the password will
-     expire.
-lr-value
-     This field contains the time of the last request. the time must be
-     interpreted according to the contents of the accompanying lr-type
-     subfield.
-
-See section 6 for the definitions of Checksum, ChecksumType, EncryptedData,
-EncryptionKey, EncryptionType, and KeyType.
-
-5.3. Tickets and Authenticators
-
-This section describes the format and encryption parameters for tickets and
-authenticators. When a ticket or authenticator is included in a protocol
-message it is treated as an opaque object.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-5.3.1. Tickets
-
-A ticket is a record that helps a client authenticate to a service. A
-Ticket contains the following information:
-
-Ticket ::=        [APPLICATION 1] SEQUENCE {
-                  tkt-vno[0]                   INTEGER,
-                  realm[1]                     Realm,
-                  sname[2]                     PrincipalName,
-                  enc-part[3]                  EncryptedData,
-                  extensions[4]                TicketExtensions OPTIONAL
-}
-
--- Encrypted part of ticket
-EncTicketPart ::= [APPLICATION 3] SEQUENCE {
-                  flags[0]                     TicketFlags,
-                  key[1]                       EncryptionKey,
-                  crealm[2]                    Realm,
-                  cname[3]                     PrincipalName,
-                  transited[4]                 TransitedEncoding,
-                  authtime[5]                  KerberosTime,
-                  starttime[6]                 KerberosTime OPTIONAL,
-                  endtime[7]                   KerberosTime,
-                  renew-till[8]                KerberosTime OPTIONAL,
-                  caddr[9]                     HostAddresses OPTIONAL,
-                  authorization-data[10]       AuthorizationData OPTIONAL
-}
--- encoded Transited field
-TransitedEncoding ::=   SEQUENCE {
-                        tr-type[0]             INTEGER, -- must be
-registered
-                        contents[1]            OCTET STRING
-}
-
-The encoding of EncTicketPart is encrypted in the key shared by Kerberos
-and the end server (the server's secret key). See section 6 for the format
-of the ciphertext.
-
-tkt-vno
-     This field specifies the version number for the ticket format. This
-     document describes version number 5.
-realm
-     This field specifies the realm that issued a ticket. It also serves to
-     identify the realm part of the server's principal identifier. Since a
-     Kerberos server can only issue tickets for servers within its realm,
-     the two will always be identical.
-sname
-     This field specifies all components of the name part of the server's
-     identity, including those parts that identify a specific instance of a
-     service.
-enc-part
-     This field holds the encrypted encoding of the EncTicketPart sequence.
-extensions
-     This optional field contains a sequence of extentions that may be used
-     to carry information that must be carried with the ticket to support
-     several extensions, including but not limited to plaintext
-     authorization data, tokens for exchanging inter-realm keys, and other
-     information that must be associated with a ticket for use by the
-     application server. See Appendix C for definitions of some common
-     extensions.
-
-     Note that some older versions of Kerberos did not support this field.
-     Because this is an optional field it will not break older clients, but
-     older clients might strip this field from the ticket before sending it
-     to the application server. This limits the usefulness of this ticket
-     field to environments where the ticket will not be parsed and
-     reconstructed by these older Kerberos clients.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     If it is known that the client will strip this field from the ticket,
-     as an interim measure the KDC may append this field to the end of the
-     enc-part of the ticket and append a traler indicating the lenght of
-     the appended extensions field. (this paragraph is open for discussion,
-     including the form of the traler).
-flags
-     This field indicates which of various options were used or requested
-     when the ticket was issued. It is a bit-field, where the selected
-     options are indicated by the bit being set (1), and the unselected
-     options and reserved fields being reset (0). Bit 0 is the most
-     significant bit. The encoding of the bits is specified in section 5.2.
-     The flags are described in more detail above in section 2. The
-     meanings of the flags are:
-
-          Bit(s)      Name         Description
-
-          0           RESERVED
-                                   Reserved for future  expansion  of  this
-                                   field.
-
-          1           FORWARDABLE
-                                   The FORWARDABLE flag  is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.  When set,  this
-                                   flag  tells  the  ticket-granting server
-                                   that it is OK to  issue  a  new  ticket-
-                                   granting ticket with a different network
-                                   address based on the presented ticket.
-
-          2           FORWARDED
-                                   When set, this flag indicates  that  the
-                                   ticket  has either been forwarded or was
-                                   issued based on authentication involving
-                                   a forwarded ticket-granting ticket.
-
-          3           PROXIABLE
-                                   The  PROXIABLE  flag  is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.   The  PROXIABLE
-                                   flag  has an interpretation identical to
-                                   that of  the  FORWARDABLE  flag,  except
-                                   that   the   PROXIABLE  flag  tells  the
-                                   ticket-granting server  that  only  non-
-                                   ticket-granting  tickets  may  be issued
-                                   with different network addresses.
-
-          4           PROXY
-                                   When set, this  flag  indicates  that  a
-                                   ticket is a proxy.
-
-          5           MAY-POSTDATE
-                                   The MAY-POSTDATE flag is  normally  only
-                                   interpreted  by  the  TGS,  and  can  be
-                                   ignored by end servers.  This flag tells
-                                   the  ticket-granting server that a post-
-                                   dated ticket may be issued based on this
-                                   ticket-granting ticket.
-
-          6           POSTDATED
-                                   This flag indicates that this ticket has
-                                   been  postdated.   The  end-service  can
-                                   check the authtime field to see when the
-                                   original authentication occurred.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-          7           INVALID
-                                   This flag indicates  that  a  ticket  is
-                                   invalid, and it must be validated by the
-                                   KDC  before  use.   Application  servers
-                                   must reject tickets which have this flag
-                                   set.
-
-          8           RENEWABLE
-                                   The  RENEWABLE  flag  is  normally  only
-                                   interpreted  by the TGS, and can usually
-                                   be ignored by end servers (some particu-
-                                   larly careful servers may wish to disal-
-                                   low  renewable  tickets).   A  renewable
-                                   ticket  can be used to obtain a replace-
-                                   ment ticket  that  expires  at  a  later
-                                   date.
-
-          9           INITIAL
-                                   This flag indicates that this ticket was
-                                   issued  using  the  AS protocol, and not
-                                   issued  based   on   a   ticket-granting
-                                   ticket.
-
-          10          PRE-AUTHENT
-                                   This flag indicates that during  initial
-                                   authentication, the client was authenti-
-                                   cated by the KDC  before  a  ticket  was
-                                   issued.    The   strength  of  the  pre-
-                                   authentication method is not  indicated,
-                                   but is acceptable to the KDC.
-
-          11          HW-AUTHENT
-                                   This flag indicates  that  the  protocol
-                                   employed   for   initial  authentication
-                                   required the use of hardware expected to
-                                   be possessed solely by the named client.
-                                   The hardware  authentication  method  is
-                                   selected  by the KDC and the strength of
-                                   the method is not indicated.
-
-          12           TRANSITED   This flag indicates that the KDC for the
-                  POLICY-CHECKED   realm has checked the transited field
-                                   against a realm defined policy for
-                                   trusted certifiers.  If this flag is
-                                   reset (0), then the application server
-                                   must check the transited field itself,
-                                   and if unable to do so it must reject
-                                   the authentication.  If the flag is set
-                                   (1) then the application server may skip
-                                   its own validation of the transited
-                                   field, relying on the validation
-                                   performed by the KDC.  At its option the
-                                   application server may still apply its
-                                   own validation based on a separate
-                                   policy for acceptance.
-
-          13      OK-AS-DELEGATE   This flag indicates that the server (not
-                                   the client) specified in the ticket has
-                                   been determined by policy of the realm
-                                   to be a suitable recipient of
-                                   delegation.  A client can use the
-                                   presence of this flag to help it make a
-                                   decision whether to delegate credentials
-                                   (either grant a proxy or a forwarded
-                                   ticket granting ticket) to this server.
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-                                   The client is free to ignore the value
-                                   of this flag.  When setting this flag,
-                                   an administrator should consider the
-                                   Security and placement of the server on
-                                   which the service will run, as well as
-                                   whether the service requires the use of
-                                   delegated credentials.
-
-          14          ANONYMOUS
-                                   This flag indicates that  the  principal
-                                   named in the ticket is a generic princi-
-                                   pal for the realm and does not  identify
-                                   the  individual  using  the ticket.  The
-                                   purpose  of  the  ticket  is   only   to
-                                   securely  distribute  a session key, and
-                                   not to identify  the  user.   Subsequent
-                                   requests  using the same ticket and ses-
-                                   sion may be  considered  as  originating
-                                   from  the  same  user, but requests with
-                                   the same username but a different ticket
-                                   are  likely  to originate from different
-                                   users.
-
-          15-31       RESERVED
-                                   Reserved for future use.
-
-key
-     This field exists in the ticket and the KDC response and is used to
-     pass the session key from Kerberos to the application server and the
-     client. The field's encoding is described in section 6.2.
-crealm
-     This field contains the name of the realm in which the client is
-     registered and in which initial authentication took place.
-cname
-     This field contains the name part of the client's principal
-     identifier.
-transited
-     This field lists the names of the Kerberos realms that took part in
-     authenticating the user to whom this ticket was issued. It does not
-     specify the order in which the realms were transited. See section
-     3.3.3.2 for details on how this field encodes the traversed realms.
-     When the names of CA's are to be embedded inthe transited field (as
-     specified for some extentions to the protocol), the X.500 names of the
-     CA's should be mapped into items in the transited field using the
-     mapping defined by RFC2253.
-authtime
-     This field indicates the time of initial authentication for the named
-     principal. It is the time of issue for the original ticket on which
-     this ticket is based. It is included in the ticket to provide
-     additional information to the end service, and to provide the
-     necessary information for implementation of a `hot list' service at
-     the KDC. An end service that is particularly paranoid could refuse to
-     accept tickets for which the initial authentication occurred "too far"
-     in the past. This field is also returned as part of the response from
-     the KDC. When returned as part of the response to initial
-     authentication (KRB_AS_REP), this is the current time on the Kerberos
-     server[24].
-starttime
-     This field in the ticket specifies the time after which the ticket is
-     valid. Together with endtime, this field specifies the life of the
-     ticket. If it is absent from the ticket, its value should be treated
-     as that of the authtime field.
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-endtime
-     This field contains the time after which the ticket will not be
-     honored (its expiration time). Note that individual services may place
-     their own limits on the life of a ticket and may reject tickets which
-     have not yet expired. As such, this is really an upper bound on the
-     expiration time for the ticket.
-renew-till
-     This field is only present in tickets that have the RENEWABLE flag set
-     in the flags field. It indicates the maximum endtime that may be
-     included in a renewal. It can be thought of as the absolute expiration
-     time for the ticket, including all renewals.
-caddr
-     This field in a ticket contains zero (if omitted) or more (if present)
-     host addresses. These are the addresses from which the ticket can be
-     used. If there are no addresses, the ticket can be used from any
-     location. The decision by the KDC to issue or by the end server to
-     accept zero-address tickets is a policy decision and is left to the
-     Kerberos and end-service administrators; they may refuse to issue or
-     accept such tickets. The suggested and default policy, however, is
-     that such tickets will only be issued or accepted when additional
-     information that can be used to restrict the use of the ticket is
-     included in the authorization_data field. Such a ticket is a
-     capability.
-
-     Network addresses are included in the ticket to make it harder for an
-     attacker to use stolen credentials. Because the session key is not
-     sent over the network in cleartext, credentials can't be stolen simply
-     by listening to the network; an attacker has to gain access to the
-     session key (perhaps through operating system security breaches or a
-     careless user's unattended session) to make use of stolen tickets.
-
-     It is important to note that the network address from which a
-     connection is received cannot be reliably determined. Even if it could
-     be, an attacker who has compromised the client's workstation could use
-     the credentials from there. Including the network addresses only makes
-     it more difficult, not impossible, for an attacker to walk off with
-     stolen credentials and then use them from a "safe" location.
-authorization-data
-     The authorization-data field is used to pass authorization data from
-     the principal on whose behalf a ticket was issued to the application
-     service. If no authorization data is included, this field will be left
-     out. Experience has shown that the name of this field is confusing,
-     and that a better name for this field would be restrictions.
-     Unfortunately, it is not possible to change the name of this field at
-     this time.
-
-     This field contains restrictions on any authority obtained on the
-     basis of authentication using the ticket. It is possible for any
-     principal in posession of credentials to add entries to the
-     authorization data field since these entries further restrict what can
-     be done with the ticket. Such additions can be made by specifying the
-     additional entries when a new ticket is obtained during the TGS
-     exchange, or they may be added during chained delegation using the
-     authorization data field of the authenticator.
-
-     Because entries may be added to this field by the holder of
-     credentials, except when an entry is separately authenticated by
-     encapulation in the kdc-issued element, it is not allowable for the
-     presence of an entry in the authorization data field of a ticket to
-     amplify the priveleges one would obtain from using a ticket.
-
-     The data in this field may be specific to the end service; the field
-     will contain the names of service specific objects, and the rights to
-     those objects. The format for this field is described in section 5.2.
-     Although Kerberos is not concerned with the format of the contents of
-     the sub-fields, it does carry type information (ad-type).
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     By using the authorization_data field, a principal is able to issue a
-     proxy that is valid for a specific purpose. For example, a client
-     wishing to print a file can obtain a file server proxy to be passed to
-     the print server. By specifying the name of the file in the
-     authorization_data field, the file server knows that the print server
-     can only use the client's rights when accessing the particular file to
-     be printed.
-
-     A separate service providing authorization or certifying group
-     membership may be built using the authorization-data field. In this
-     case, the entity granting authorization (not the authorized entity),
-     may obtain a ticket in its own name (e.g. the ticket is issued in the
-     name of a privelege server), and this entity adds restrictions on its
-     own authority and delegates the restricted authority through a proxy
-     to the client. The client would then present this authorization
-     credential to the application server separately from the
-     authentication exchange. Alternatively, such authorization credentials
-     may be embedded in the ticket authenticating the authorized entity,
-     when the authorization is separately authenticated using the
-     kdc-issued authorization data element (see B.4).
-
-     Similarly, if one specifies the authorization-data field of a proxy
-     and leaves the host addresses blank, the resulting ticket and session
-     key can be treated as a capability. See [Neu93] for some suggested
-     uses of this field.
-
-     The authorization-data field is optional and does not have to be
-     included in a ticket.
-
-5.3.2. Authenticators
-
-An authenticator is a record sent with a ticket to a server to certify the
-client's knowledge of the encryption key in the ticket, to help the server
-detect replays, and to help choose a "true session key" to use with the
-particular session. The encoding is encrypted in the ticket's session key
-shared by the client and the server:
-
--- Unencrypted authenticator
-Authenticator ::= [APPLICATION 2] SEQUENCE  {
-                  authenticator-vno[0]          INTEGER,
-                  crealm[1]                     Realm,
-                  cname[2]                      PrincipalName,
-                  cksum[3]                      Checksum OPTIONAL,
-                  cusec[4]                      INTEGER,
-                  ctime[5]                      KerberosTime,
-                  subkey[6]                     EncryptionKey OPTIONAL,
-                  seq-number[7]                 INTEGER OPTIONAL,
-                  authorization-data[8]         AuthorizationData OPTIONAL
-}
-
-
-authenticator-vno
-     This field specifies the version number for the format of the
-     authenticator. This document specifies version 5.
-crealm and cname
-     These fields are the same as those described for the ticket in section
-     5.3.1.
-cksum
-     This field contains a checksum of the the applica- tion data that
-     accompanies the KRB_AP_REQ.
-cusec
-     This field contains the microsecond part of the client's timestamp.
-     Its value (before encryption) ranges from 0 to 999999. It often
-     appears along with ctime. The two fields are used together to specify
-     a reasonably accurate timestamp.
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-ctime
-     This field contains the current time on the client's host.
-subkey
-     This field contains the client's choice for an encryption key which is
-     to be used to protect this specific application session. Unless an
-     application specifies otherwise, if this field is left out the session
-     key from the ticket will be used.
-seq-number
-     This optional field includes the initial sequence number to be used by
-     the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to
-     detect replays (It may also be used by application specific messages).
-     When included in the authenticator this field specifies the initial
-     sequence number for messages from the client to the server. When
-     included in the AP-REP message, the initial sequence number is that
-     for messages from the server to the client. When used in KRB_PRIV or
-     KRB_SAFE messages, it is incremented by one after each message is
-     sent. Sequence numbers fall in the range of 0 through 2^32 - 1 and
-     wrap to zero following the value 2^32 - 1.
-
-     For sequence numbers to adequately support the detection of replays
-     they should be non-repeating, even across connection boundaries. The
-     initial sequence number should be random and uniformly distributed
-     across the full space of possible sequence numbers, so that it cannot
-     be guessed by an attacker and so that it and the successive sequence
-     numbers do not repeat other sequences.
-authorization-data
-     This field is the same as described for the ticket in section 5.3.1.
-     It is optional and will only appear when additional restrictions are
-     to be placed on the use of a ticket, beyond those carried in the
-     ticket itself.
-
-5.4. Specifications for the AS and TGS exchanges
-
-This section specifies the format of the messages used in the exchange
-between the client and the Kerberos server. The format of possible error
-messages appears in section 5.9.1.
-
-5.4.1. KRB_KDC_REQ definition
-
-The KRB_KDC_REQ message has no type of its own. Instead, its type is one of
-KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an
-initial ticket or an additional ticket. In either case, the message is sent
-from the client to the Authentication Server to request credentials for a
-service.
-
-The message fields are:
-
-AS-REQ ::=         [APPLICATION 10] KDC-REQ
-TGS-REQ ::=        [APPLICATION 12] KDC-REQ
-
-KDC-REQ ::=        SEQUENCE {
-                   pvno[1]            INTEGER,
-                   msg-type[2]        INTEGER,
-                   padata[3]          SEQUENCE OF PA-DATA OPTIONAL,
-                   req-body[4]        KDC-REQ-BODY
-}
-
-PA-DATA ::=        SEQUENCE {
-                   padata-type[1]     INTEGER,
-                   padata-value[2]    OCTET STRING,
-                                      -- might be encoded AP-REQ
-}
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-KDC-REQ-BODY ::=   SEQUENCE {
-                    kdc-options[0]         KDCOptions,
-                    cname[1]               PrincipalName OPTIONAL,
-                                           -- Used only in AS-REQ
-                    realm[2]               Realm, -- Server's realm
-                                           -- Also client's in AS-REQ
-                    sname[3]               PrincipalName OPTIONAL,
-                    from[4]                KerberosTime OPTIONAL,
-                    till[5]                KerberosTime OPTIONAL,
-                    rtime[6]               KerberosTime OPTIONAL,
-                    nonce[7]               INTEGER,
-                    etype[8]               SEQUENCE OF INTEGER,
-                                           -- EncryptionType,
-                                           -- in preference order
-                    addresses[9]           HostAddresses OPTIONAL,
-                enc-authorization-data[10] EncryptedData OPTIONAL,
-                                           -- Encrypted AuthorizationData
-                                           -- encoding
-                    additional-tickets[11] SEQUENCE OF Ticket OPTIONAL
-}
-
-The fields in this message are:
-
-pvno
-     This field is included in each message, and specifies the protocol
-     version number. This document specifies protocol version 5.
-msg-type
-     This field indicates the type of a protocol message. It will almost
-     always be the same as the application identifier associated with a
-     message. It is included to make the identifier more readily accessible
-     to the application. For the KDC-REQ message, this type will be
-     KRB_AS_REQ or KRB_TGS_REQ.
-padata
-     The padata (pre-authentication data) field contains a sequence of
-     authentication information which may be needed before credentials can
-     be issued or decrypted. In the case of requests for additional tickets
-     (KRB_TGS_REQ), this field will include an element with padata-type of
-     PA-TGS-REQ and data of an authentication header (ticket-granting
-     ticket and authenticator). The checksum in the authenticator (which
-     must be collision-proof) is to be computed over the KDC-REQ-BODY
-     encoding. In most requests for initial authentication (KRB_AS_REQ) and
-     most replies (KDC-REP), the padata field will be left out.
-
-     This field may also contain information needed by certain extensions
-     to the Kerberos protocol. For example, it might be used to initially
-     verify the identity of a client before any response is returned. When
-     this field is used to authenticate or pre-authenticate a request, it
-     should contain a keyed checksum over the KDC-REQ-BODY to bind the
-     pre-authentication data to rest of the request. The KDC, as a matter
-     of policy, may decide whether to honor a KDC-REQ which includes any
-     pre-authentication data that does not contain the checksum field.
-     PA-ENC-TIMESTAMP defines a pre-authentication data type that is used
-     for authenticating a client by way of an encrypted timestamp. This is
-     accomplished with a padata field with padata-type equal to
-     PA-ENC-TIMESTAMP and padata-value defined as follows (query: the
-     checksum is new in this definition. If the optional field will break
-     things we can keep the old PA-ENC-TS-ENC, and define a new alternate
-     form that includes the checksum). :
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-          padata-type     ::= PA-ENC-TIMESTAMP
-          padata-value    ::= EncryptedData -- PA-ENC-TS-ENC
-
-          PA-ENC-TS-ENC   ::= SEQUENCE {
-                          patimestamp[0]     KerberosTime, -- client's time
-                          pausec[1]          INTEGER OPTIONAL,
-                          pachecksum[2]      checksum OPTIONAL
-                                             -- keyed checksum of
-KDC-REQ-BODY
-          }
-
-     with patimestamp containing the client's time and pausec containing
-     the microseconds which may be omitted if a client will not generate
-     more than one request per second. The ciphertext (padata-value)
-     consists of the PA-ENC-TS-ENC sequence, encrypted using the client's
-     secret key.
-
-     [use-specified-kvno item is here for discussion and may be removed] It
-     may also be used by the client to specify the version of a key that is
-     being used for accompanying preauthentication, and/or which should be
-     used to encrypt the reply from the KDC.
-
-     PA-USE-SPECIFIED-KVNO  ::=  Integer
-
-     The KDC should only accept and abide by the value of the
-     use-specified-kvno preauthentication data field when the specified key
-     is still valid and until use of a new key is confirmed. This situation
-     is likely to occur primarily during the period during which an updated
-     key is propagating to other KDC's in a realm.
-
-     The padata field can also contain information needed to help the KDC
-     or the client select the key needed for generating or decrypting the
-     response. This form of the padata is useful for supporting the use of
-     certain token cards with Kerberos. The details of such extensions are
-     specified in separate documents. See [Pat92] for additional uses of
-     this field.
-padata-type
-     The padata-type element of the padata field indicates the way that the
-     padata-value element is to be interpreted. Negative values of
-     padata-type are reserved for unregistered use; non-negative values are
-     used for a registered interpretation of the element type.
-req-body
-     This field is a placeholder delimiting the extent of the remaining
-     fields. If a checksum is to be calculated over the request, it is
-     calculated over an encoding of the KDC-REQ-BODY sequence which is
-     enclosed within the req-body field.
-kdc-options
-     This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the
-     KDC and indicates the flags that the client wants set on the tickets
-     as well as other information that is to modify the behavior of the
-     KDC. Where appropriate, the name of an option may be the same as the
-     flag that is set by that option. Although in most case, the bit in the
-     options field will be the same as that in the flags field, this is not
-     guaranteed, so it is not acceptable to simply copy the options field
-     to the flags field. There are various checks that must be made before
-     honoring an option anyway.
-
-     The kdc_options field is a bit-field, where the selected options are
-     indicated by the bit being set (1), and the unselected options and
-     reserved fields being reset (0). The encoding of the bits is specified
-     in section 5.2. The options are described in more detail above in
-     section 2. The meanings of the options are:
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-        Bit(s)    Name                Description
-         0        RESERVED
-                                      Reserved for future  expansion  of
-this
-                                      field.
-
-         1        FORWARDABLE
-                                      The FORWARDABLE  option  indicates
-that
-                                      the  ticket  to be issued is to have
-its
-                                      forwardable flag set.  It  may  only
-be
-                                      set on the initial request, or in a
-sub-
-                                      sequent request if  the
-ticket-granting
-                                      ticket on which it is based is also
-for-
-                                      wardable.
-
-         2        FORWARDED
-                                      The FORWARDED option is  only
-specified
-                                      in  a  request  to  the
-ticket-granting
-                                      server and will only be honored  if
-the
-                                      ticket-granting  ticket  in  the
-request
-                                      has  its  FORWARDABLE  bit  set.
-This
-                                      option  indicates that this is a
-request
-                                      for forwarding.  The address(es) of
-the
-                                      host  from which the resulting ticket
-is
-                                      to  be  valid  are   included   in
-the
-                                      addresses field of the request.
-
-         3        PROXIABLE
-                                      The PROXIABLE option indicates that
-the
-                                      ticket to be issued is to have its
-prox-
-                                      iable flag set.  It may only be  set
-on
-                                      the  initial request, or in a
-subsequent
-                                      request if the ticket-granting ticket
-on
-                                      which it is based is also proxiable.
-
-         4        PROXY
-                                      The PROXY option indicates that this
-is
-                                      a request for a proxy.  This option
-will
-                                      only be honored if  the
-ticket-granting
-                                      ticket  in the request has its
-PROXIABLE
-                                      bit set.  The address(es)  of  the
-host
-                                      from which the resulting ticket is to
-be
-                                       valid  are  included  in  the
-addresses
-                                      field of the request.
-
-         5        ALLOW-POSTDATE
-                                      The ALLOW-POSTDATE option indicates
-that
-                                      the  ticket  to be issued is to have
-its
-                                      MAY-POSTDATE flag set.  It may  only
-be
-                                      set on the initial request, or in a
-sub-
-                                      sequent request if  the
-ticket-granting
-                                      ticket on which it is based also has
-its
-                                      MAY-POSTDATE flag set.
-
-         6        POSTDATED
-                                      The POSTDATED option indicates that
-this
-                                      is  a  request  for  a postdated
-ticket.
-                                      This option will only be honored if
-the
-                                      ticket-granting  ticket  on  which it
-is
-                                      based has  its  MAY-POSTDATE  flag
-set.
-                                      The  resulting ticket will also have
-its
-                                      INVALID flag set, and that flag  may
-be
-                                      reset by a subsequent request to the
-KDC
-                                      after the starttime in  the  ticket
-has
-                                      been reached.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-         7        UNUSED
-                                      This option is presently unused.
-
-         8        RENEWABLE
-                                      The RENEWABLE option indicates that
-the
-                                      ticket  to  be  issued  is  to  have
-its
-                                      RENEWABLE flag set.  It may only be
-set
-                                      on  the  initial  request,  or  when
-the
-                                      ticket-granting  ticket  on  which
-the
-                                      request  is based is also renewable.
-If
-                                      this option is requested, then the
-rtime
-                                      field   in   the  request  contains
-the
-                                      desired absolute expiration time for
-the
-                                      ticket.
-
-         9       RESERVED
-                                      Reserved for PK-Cross
-
-         10-13     UNUSED
-                                      These options are presently unused.
-
-         14       REQUEST-ANONYMOUS
-                                      The REQUEST-ANONYMOUS  option
-indicates
-                                      that  the  ticket to be issued is not
-to
-                                      identify  the  user  to  which  it
-was
-                                      issued.  Instead, the principal
-identif-
-                                      ier is to be generic,  as  specified
-by
-                                      the  policy  of  the realm (e.g.
-usually
-                                      anonymous@realm).  The  purpose  of
-the
-                                      ticket  is only to securely distribute
-a
-                                      session key, and  not  to  identify
-the
-                                      user.   The ANONYMOUS flag on the
-ticket
-                                      to be returned should be  set.   If
-the
-                                      local  realms  policy  does  not
-permit
-                                      anonymous credentials, the request is
-to
-                                      be rejected.
-
-         15      CANONICALIZE
-                                      The CANONICALIZE option indicates that
-                                      the client will accept the return of a
-                                      true server name instead of the name
-                                      specified in the request. In addition
-                                      the client will be able to process
-                                      any TGT referrals that will direct
-                                      the client to another realm to locate
-                                      the requested server. If a KDC does
-                                      not support name- canonicalization,
-                                      the option is ignored and the
-                                      appropriate
-                                      KDC_ERR_C_PRINCIPAL_UNKNOWN or
-                                      KDC_ERR_S_PRINCIPAL_UNKNOWN error is
-                                      returned. [JBrezak]
-
-         16-25    RESERVED
-                                      Reserved for future use.
-
-         26       DISABLE-TRANSITED-CHECK
-                                      By default the KDC will check the
-                                      transited field of a ticket-granting-
-                                      ticket against the policy of the local
-                                      realm before it will issue derivative
-                                      tickets based on the ticket granting
-                                      ticket.  If this flag is set in the
-                                      request, checking of the transited
-field
-                                      is disabled.  Tickets issued without
-the
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-                                      performance of this check will be
-noted
-                                      by the reset (0) value of the
-                                      TRANSITED-POLICY-CHECKED flag,
-                                      indicating to the application server
-                                      that the tranisted field must be
-checked
-                                      locally.  KDC's are encouraged but not
-                                      required to honor the
-                                      DISABLE-TRANSITED-CHECK option.
-
-         27       RENEWABLE-OK
-                                      The RENEWABLE-OK option indicates that
-a
-                                      renewable ticket will be acceptable if
-a
-                                      ticket with the  requested  life
-cannot
-                                      otherwise be provided.  If a ticket
-with
-                                      the requested life cannot  be
-provided,
-                                      then  a  renewable  ticket may be
-issued
-                                      with  a  renew-till  equal  to  the
-the
-                                      requested  endtime.   The  value  of
-the
-                                      renew-till field may still be limited
-by
-                                      local  limits, or limits selected by
-the
-                                      individual principal or server.
-
-         28       ENC-TKT-IN-SKEY
-                                      This option is used only by the
-ticket-
-                                      granting  service.   The
-ENC-TKT-IN-SKEY
-                                      option indicates that the ticket for
-the
-                                      end  server  is  to  be encrypted in
-the
-                                      session key from the additional
-ticket-
-                                      granting ticket provided.
-
-         29       RESERVED
-                                      Reserved for future use.
-
-         30       RENEW
-                                      This option is used only by the
-ticket-
-                                      granting   service.   The  RENEW
-option
-                                      indicates that the  present  request
-is
-                                      for  a  renewal.  The ticket provided
-is
-                                      encrypted in  the  secret  key  for
-the
-                                      server  on  which  it  is  valid.
-This
-                                      option  will  only  be  honored  if
-the
-                                      ticket  to  be renewed has its
-RENEWABLE
-                                      flag set and if the time in  its
-renew-
-                                      till  field  has not passed.  The
-ticket
-                                      to be renewed is passed  in  the
-padata
-                                      field  as  part  of  the
-authentication
-                                      header.
-
-         31       VALIDATE
-                                      This option is used only by the
-ticket-
-                                      granting  service.   The VALIDATE
-option
-                                      indicates that the request is  to
-vali-
-                                      date  a  postdated ticket.  It will
-only
-                                      be honored if the  ticket  presented
-is
-                                      postdated,  presently  has  its
-INVALID
-                                      flag set, and would be otherwise
-usable
-                                      at  this time.  A ticket cannot be
-vali-
-                                      dated before its starttime.  The
-ticket
-                                      presented for validation is encrypted
-in
-                                      the key of the server for  which  it
-is
-                                      valid  and is passed in the padata
-field
-                                      as part of the authentication header.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-cname and sname
-     These fields are the same as those described for the ticket in section
-     5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is
-     specified. If absent, the name of the server is taken from the name of
-     the client in the ticket passed as additional-tickets.
-enc-authorization-data
-     The enc-authorization-data, if present (and it can only be present in
-     the TGS_REQ form), is an encoding of the desired authorization-data
-     encrypted under the sub-session key if present in the Authenticator,
-     or alternatively from the session key in the ticket-granting ticket,
-     both from the padata field in the KRB_AP_REQ.
-realm
-     This field specifies the realm part of the server's principal
-     identifier. In the AS exchange, this is also the realm part of the
-     client's principal identifier. If the CANONICALIZE option is set, the
-     realm is used as a hint to the KDC for its database lookup.
-from
-     This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
-     requests when the requested ticket is to be postdated. It specifies
-     the desired start time for the requested ticket. If this field is
-     omitted then the KDC should use the current time instead.
-till
-     This field contains the expiration date requested by the client in a
-     ticket request. It is optional and if omitted the requested ticket is
-     to have the maximum endtime permitted according to KDC policy for the
-     parties to the authentication exchange as limited by expiration date
-     of the ticket granting ticket or other preauthentication credentials.
-rtime
-     This field is the requested renew-till time sent from a client to the
-     KDC in a ticket request. It is optional.
-nonce
-     This field is part of the KDC request and response. It it intended to
-     hold a random number generated by the client. If the same number is
-     included in the encrypted response from the KDC, it provides evidence
-     that the response is fresh and has not been replayed by an attacker.
-     Nonces must never be re-used. Ideally, it should be generated
-     randomly, but if the correct time is known, it may suffice[25].
-etype
-     This field specifies the desired encryption algorithm to be used in
-     the response.
-addresses
-     This field is included in the initial request for tickets, and
-     optionally included in requests for additional tickets from the
-     ticket-granting server. It specifies the addresses from which the
-     requested ticket is to be valid. Normally it includes the addresses
-     for the client's host. If a proxy is requested, this field will
-     contain other addresses. The contents of this field are usually copied
-     by the KDC into the caddr field of the resulting ticket.
-additional-tickets
-     Additional tickets may be optionally included in a request to the
-     ticket-granting server. If the ENC-TKT-IN-SKEY option has been
-     specified, then the session key from the additional ticket will be
-     used in place of the server's key to encrypt the new ticket. When he
-     ENC-TKT-IN-SKEY option is used for user-to-user authentication, this
-     addional ticket may be a TGT issued by the local realm or an
-     inter-realm TGT issued for the current KDC's realm by a remote KDC. If
-     more than one option which requires additional tickets has been
-     specified, then the additional tickets are used in the order specified
-     by the ordering of the options bits (see kdc-options, above).
-
-The application code will be either ten (10) or twelve (12) depending on
-whether the request is for an initial ticket (AS-REQ) or for an additional
-ticket (TGS-REQ).
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-The optional fields (addresses, authorization-data and additional-tickets)
-are only included if necessary to perform the operation specified in the
-kdc-options field.
-
-It should be noted that in KRB_TGS_REQ, the protocol version number appears
-twice and two different message types appear: the KRB_TGS_REQ message
-contains these fields as does the authentication header (KRB_AP_REQ) that
-is passed in the padata field.
-
-5.4.2. KRB_KDC_REP definition
-
-The KRB_KDC_REP message format is used for the reply from the KDC for
-either an initial (AS) request or a subsequent (TGS) request. There is no
-message type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP
-or KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply
-depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in
-the client's secret key, and the client's key version number is included in
-the key version number for the encrypted data. For KRB_TGS_REP, the
-ciphertext is encrypted in the sub-session key from the Authenticator, or
-if absent, the session key from the ticket-granting ticket used in the
-request. In that case, no version number will be present in the
-EncryptedData sequence.
-
-The KRB_KDC_REP message contains the following fields:
-
-AS-REP ::=    [APPLICATION 11] KDC-REP
-TGS-REP ::=   [APPLICATION 13] KDC-REP
-
-KDC-REP ::=   SEQUENCE {
-              pvno[0]                    INTEGER,
-              msg-type[1]                INTEGER,
-              padata[2]                  SEQUENCE OF PA-DATA OPTIONAL,
-              crealm[3]                  Realm,
-              cname[4]                   PrincipalName,
-              ticket[5]                  Ticket,
-              enc-part[6]                EncryptedData
-}
-
-EncASRepPart ::=    [APPLICATION 25[27]] EncKDCRepPart
-EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart
-
-EncKDCRepPart ::=   SEQUENCE {
-                    key[0]               EncryptionKey,
-                    last-req[1]          LastReq,
-                    nonce[2]             INTEGER,
-                    key-expiration[3]    KerberosTime OPTIONAL,
-                    flags[4]             TicketFlags,
-                    authtime[5]          KerberosTime,
-                    starttime[6]         KerberosTime OPTIONAL,
-                    endtime[7]           KerberosTime,
-                    renew-till[8]        KerberosTime OPTIONAL,
-                    srealm[9]            Realm,
-                    sname[10]            PrincipalName,
-                    caddr[11]            HostAddresses OPTIONAL
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is either
-     KRB_AS_REP or KRB_TGS_REP.
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-padata
-     This field is described in detail in section 5.4.1. One possible use
-     for this field is to encode an alternate "mix-in" string to be used
-     with a string-to-key algorithm (such as is described in section
-     6.3.2). This ability is useful to ease transitions if a realm name
-     needs to change (e.g. when a company is acquired); in such a case all
-     existing password-derived entries in the KDC database would be flagged
-     as needing a special mix-in string until the next password change.
-crealm, cname, srealm and sname
-     These fields are the same as those described for the ticket in section
-     5.3.1.
-ticket
-     The newly-issued ticket, from section 5.3.1.
-enc-part
-     This field is a place holder for the ciphertext and related
-     information that forms the encrypted part of a message. The
-     description of the encrypted part of the message follows each
-     appearance of this field. The encrypted part is encoded as described
-     in section 6.1.
-key
-     This field is the same as described for the ticket in section 5.3.1.
-last-req
-     This field is returned by the KDC and specifies the time(s) of the
-     last request by a principal. Depending on what information is
-     available, this might be the last time that a request for a
-     ticket-granting ticket was made, or the last time that a request based
-     on a ticket-granting ticket was successful. It also might cover all
-     servers for a realm, or just the particular server. Some
-     implementations may display this information to the user to aid in
-     discovering unauthorized use of one's identity. It is similar in
-     spirit to the last login time displayed when logging into timesharing
-     systems.
-nonce
-     This field is described above in section 5.4.1.
-key-expiration
-     The key-expiration field is part of the response from the KDC and
-     specifies the time that the client's secret key is due to expire. The
-     expiration might be the result of password aging or an account
-     expiration. This field will usually be left out of the TGS reply since
-     the response to the TGS request is encrypted in a session key and no
-     client information need be retrieved from the KDC database. It is up
-     to the application client (usually the login program) to take
-     appropriate action (such as notifying the user) if the expiration time
-     is imminent.
-flags, authtime, starttime, endtime, renew-till and caddr
-     These fields are duplicates of those found in the encrypted portion of
-     the attached ticket (see section 5.3.1), provided so the client may
-     verify they match the intended request and to assist in proper ticket
-     caching. If the message is of type KRB_TGS_REP, the caddr field will
-     only be filled in if the request was for a proxy or forwarded ticket,
-     or if the user is substituting a subset of the addresses from the
-     ticket granting ticket. If the client-requested addresses are not
-     present or not used, then the addresses contained in the ticket will
-     be the same as those included in the ticket-granting ticket.
-
-5.5. Client/Server (CS) message specifications
-
-This section specifies the format of the messages used for the
-authentication of the client to the application server.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-5.5.1. KRB_AP_REQ definition
-
-The KRB_AP_REQ message contains the Kerberos protocol version number, the
-message type KRB_AP_REQ, an options field to indicate any options in use,
-and the ticket and authenticator themselves. The KRB_AP_REQ message is
-often referred to as the 'authentication header'.
-
-AP-REQ ::=      [APPLICATION 14] SEQUENCE {
-                pvno[0]                       INTEGER,
-                msg-type[1]                   INTEGER,
-                ap-options[2]                 APOptions,
-                ticket[3]                     Ticket,
-                authenticator[4]              EncryptedData
-}
-
-APOptions ::=   BIT STRING {
-                reserved(0),
-                use-session-key(1),
-                mutual-required(2)
-}
-
-
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_AP_REQ.
-ap-options
-     This field appears in the application request (KRB_AP_REQ) and affects
-     the way the request is processed. It is a bit-field, where the
-     selected options are indicated by the bit being set (1), and the
-     unselected options and reserved fields being reset (0). The encoding
-     of the bits is specified in section 5.2. The meanings of the options
-     are:
-
-	  Bit(s)   Name              Description
-
-	  0        RESERVED
-				     Reserved for future  expansion  of  this
-				     field.
-
-	  1        USE-SESSION-KEY
-				     The  USE-SESSION-KEY  option   indicates
-				     that the ticket the client is presenting
-				     to a server is encrypted in the  session
-				     key  from  the  server's ticket-granting
-				     ticket.  When this option is not  speci-
-				     fied,  the  ticket  is  encrypted in the
-				     server's secret key.
-
-	  2        MUTUAL-REQUIRED
-				     The  MUTUAL-REQUIRED  option  tells  the
-				     server  that  the client requires mutual
-				     authentication, and that it must respond
-				     with a KRB_AP_REP message.
-
-	  3-31     RESERVED
-				     Reserved for future use.
-
-ticket
-     This field is a ticket authenticating the client to the server.
-authenticator
-     This contains the authenticator, which includes the client's choice of
-     a subkey. Its encoding is described in section 5.3.2.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-5.5.2. KRB_AP_REP definition
-
-The KRB_AP_REP message contains the Kerberos protocol version number, the
-message type, and an encrypted time- stamp. The message is sent in in
-response to an application request (KRB_AP_REQ) where the mutual
-authentication option has been selected in the ap-options field.
-
-AP-REP ::=         [APPLICATION 15] SEQUENCE {
-                   pvno[0]                           INTEGER,
-                   msg-type[1]                       INTEGER,
-                   enc-part[2]                       EncryptedData
-}
-
-EncAPRepPart ::=   [APPLICATION 27[29]] SEQUENCE {
-                   ctime[0]                          KerberosTime,
-                   cusec[1]                          INTEGER,
-                   subkey[2]                         EncryptionKey OPTIONAL,
-                   seq-number[3]                     INTEGER OPTIONAL
-}
-
-The encoded EncAPRepPart is encrypted in the shared session key of the
-ticket. The optional subkey field can be used in an application-arranged
-negotiation to choose a per association session key.
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_AP_REP.
-enc-part
-     This field is described above in section 5.4.2.
-ctime
-     This field contains the current time on the client's host.
-cusec
-     This field contains the microsecond part of the client's timestamp.
-subkey
-     This field contains an encryption key which is to be used to protect
-     this specific application session. See section 3.2.6 for specifics on
-     how this field is used to negotiate a key. Unless an application
-     specifies otherwise, if this field is left out, the sub-session key
-     from the authenticator, or if also left out, the session key from the
-     ticket will be used.
-
-5.5.3. Error message reply
-
-If an error occurs while processing the application request, the KRB_ERROR
-message will be sent in response. See section 5.9.1 for the format of the
-error message. The cname and crealm fields may be left out if the server
-cannot determine their appropriate values from the corresponding KRB_AP_REQ
-message. If the authenticator was decipherable, the ctime and cusec fields
-will contain the values from it.
-
-5.6. KRB_SAFE message specification
-
-This section specifies the format of a message that can be used by either
-side (client or server) of an application to send a tamper-proof message to
-its peer. It presumes that a session key has previously been exchanged (for
-example, by using the KRB_AP_REQ/KRB_AP_REP messages).
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-5.6.1. KRB_SAFE definition
-
-The KRB_SAFE message contains user data along with a collision-proof
-checksum keyed with the last encryption key negotiated via subkeys, or the
-session key if no negotiation has occured. The message fields are:
-
-KRB-SAFE ::=        [APPLICATION 20] SEQUENCE {
-                    pvno[0]                       INTEGER,
-                    msg-type[1]                   INTEGER,
-                    safe-body[2]                  KRB-SAFE-BODY,
-                    cksum[3]                      Checksum
-}
-
-KRB-SAFE-BODY ::=   SEQUENCE {
-                    user-data[0]                  OCTET STRING,
-                    timestamp[1]                  KerberosTime OPTIONAL,
-                    usec[2]                       INTEGER OPTIONAL,
-                    seq-number[3]                 INTEGER OPTIONAL,
-                    s-address[4]                  HostAddress OPTIONAL,
-                    r-address[5]                  HostAddress OPTIONAL
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_SAFE.
-safe-body
-     This field is a placeholder for the body of the KRB-SAFE message.
-cksum
-     This field contains the checksum of the application data. Checksum
-     details are described in section 6.4. The checksum is computed over
-     the encoding of the KRB-SAFE sequence. First, the cksum is zeroed and
-     the checksum is computed over the encoding of the KRB-SAFE sequence,
-     then the checksum is set to the result of that computation, and
-     finally the KRB-SAFE sequence is encoded again.
-user-data
-     This field is part of the KRB_SAFE and KRB_PRIV messages and contain
-     the application specific data that is being passed from the sender to
-     the recipient.
-timestamp
-     This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents
-     are the current time as known by the sender of the message. By
-     checking the timestamp, the recipient of the message is able to make
-     sure that it was recently generated, and is not a replay.
-usec
-     This field is part of the KRB_SAFE and KRB_PRIV headers. It contains
-     the microsecond part of the timestamp.
-seq-number
-     This field is described above in section 5.3.2.
-s-address
-     This field specifies the address in use by the sender of the message.
-     It may be omitted if not required by the application protocol. The
-     application designer considering omission of this field is warned,
-     that the inclusion of this address prevents some kinds of replay
-     attacks (e.g., reflection attacks) and that it is only acceptable to
-     omit this address if there is sufficient information in the integrity
-     protected part of the application message for the recipient to
-     unambiguously determine if it was the intended recipient.
-r-address
-     This field specifies the address in use by the recipient of the
-     message. It may be omitted for some uses (such as broadcast
-     protocols), but the recipient may arbitrarily reject such messages.
-     This field along with s-address can be used to help detect messages
-     which have been incorrectly or maliciously delivered to the wrong
-     recipient.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-5.7. KRB_PRIV message specification
-
-This section specifies the format of a message that can be used by either
-side (client or server) of an application to securely and privately send a
-message to its peer. It presumes that a session key has previously been
-exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
-
-5.7.1. KRB_PRIV definition
-
-The KRB_PRIV message contains user data encrypted in the Session Key. The
-message fields are:
-
-KRB-PRIV ::=         [APPLICATION 21] SEQUENCE {
-                     pvno[0]                           INTEGER,
-                     msg-type[1]                       INTEGER,
-                     enc-part[3]                       EncryptedData
-}
-
-EncKrbPrivPart ::=   [APPLICATION 28[31]] SEQUENCE {
-                     user-data[0]        OCTET STRING,
-                     timestamp[1]        KerberosTime OPTIONAL,
-                     usec[2]             INTEGER OPTIONAL,
-                     seq-number[3]       INTEGER OPTIONAL,
-                     s-address[4]        HostAddress OPTIONAL, -- sender's
-addr
-                     r-address[5]        HostAddress OPTIONAL -- recip's
-addr
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_PRIV.
-enc-part
-     This field holds an encoding of the EncKrbPrivPart sequence encrypted
-     under the session key[32]. This encrypted encoding is used for the
-     enc-part field of the KRB-PRIV message. See section 6 for the format
-     of the ciphertext.
-user-data, timestamp, usec, s-address and r-address
-     These fields are described above in section 5.6.1.
-seq-number
-     This field is described above in section 5.3.2.
-
-5.8. KRB_CRED message specification
-
-This section specifies the format of a message that can be used to send
-Kerberos credentials from one principal to another. It is presented here to
-encourage a common mechanism to be used by applications when forwarding
-tickets or providing proxies to subordinate servers. It presumes that a
-session key has already been exchanged perhaps by using the
-KRB_AP_REQ/KRB_AP_REP messages.
-
-5.8.1. KRB_CRED definition
-
-The KRB_CRED message contains a sequence of tickets to be sent and
-information needed to use the tickets, including the session key from each.
-The information needed to use the tickets is encrypted under an encryption
-key previously exchanged or transferred alongside the KRB_CRED message. The
-message fields are:
-
-KRB-CRED         ::= [APPLICATION 22]   SEQUENCE {
-                 pvno[0]                INTEGER,
-                 msg-type[1]            INTEGER, -- KRB_CRED
-                 tickets[2]             SEQUENCE OF Ticket,
-                 enc-part[3]            EncryptedData
-}
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-EncKrbCredPart   ::= [APPLICATION 29]   SEQUENCE {
-                 ticket-info[0]         SEQUENCE OF KrbCredInfo,
-                 nonce[1]               INTEGER OPTIONAL,
-                 timestamp[2]           KerberosTime OPTIONAL,
-                 usec[3]                INTEGER OPTIONAL,
-                 s-address[4]           HostAddress OPTIONAL,
-                 r-address[5]           HostAddress OPTIONAL
-}
-
-KrbCredInfo      ::=                    SEQUENCE {
-                 key[0]                 EncryptionKey,
-                 prealm[1]              Realm OPTIONAL,
-                 pname[2]               PrincipalName OPTIONAL,
-                 flags[3]               TicketFlags OPTIONAL,
-                 authtime[4]            KerberosTime OPTIONAL,
-                 starttime[5]           KerberosTime OPTIONAL,
-                 endtime[6]             KerberosTime OPTIONAL
-                 renew-till[7]          KerberosTime OPTIONAL,
-                 srealm[8]              Realm OPTIONAL,
-                 sname[9]               PrincipalName OPTIONAL,
-                 caddr[10]              HostAddresses OPTIONAL
-}
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_CRED.
-tickets
-     These are the tickets obtained from the KDC specifically for use by
-     the intended recipient. Successive tickets are paired with the
-     corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED
-     message.
-enc-part
-     This field holds an encoding of the EncKrbCredPart sequence encrypted
-     under the session key shared between the sender and the intended
-     recipient. This encrypted encoding is used for the enc-part field of
-     the KRB-CRED message. See section 6 for the format of the ciphertext.
-nonce
-     If practical, an application may require the inclusion of a nonce
-     generated by the recipient of the message. If the same value is
-     included as the nonce in the message, it provides evidence that the
-     message is fresh and has not been replayed by an attacker. A nonce
-     must never be re-used; it should be generated randomly by the
-     recipient of the message and provided to the sender of the message in
-     an application specific manner.
-timestamp and usec
-     These fields specify the time that the KRB-CRED message was generated.
-     The time is used to provide assurance that the message is fresh.
-s-address and r-address
-     These fields are described above in section 5.6.1. They are used
-     optionally to provide additional assurance of the integrity of the
-     KRB-CRED message.
-key
-     This field exists in the corresponding ticket passed by the KRB-CRED
-     message and is used to pass the session key from the sender to the
-     intended recipient. The field's encoding is described in section 6.2.
-
-The following fields are optional. If present, they can be associated with
-the credentials in the remote ticket file. If left out, then it is assumed
-that the recipient of the credentials already knows their value.
-
-prealm and pname
-     The name and realm of the delegated principal identity.
-flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr
-     These fields contain the values of the correspond- ing fields from the
-     ticket found in the ticket field. Descriptions of the fields are
-     identical to the descriptions in the KDC-REP message.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-5.9. Error message specification
-
-This section specifies the format for the KRB_ERROR message. The fields
-included in the message are intended to return as much information as
-possible about an error. It is not expected that all the information
-required by the fields will be available for all types of errors. If the
-appropriate information is not available when the message is composed, the
-corresponding field will be left out of the message.
-
-Note that since the KRB_ERROR message is only optionally integrity
-protected, it is quite possible for an intruder to synthesize or modify
-such a message. In particular, this means that unless appropriate integrity
-protection mechanisms have been applied to the KRB_ERROR message, the
-client should not use any fields in this message for security-critical
-purposes, such as setting a system clock or generating a fresh
-authenticator. The message can be useful, however, for advising a user on
-the reason for some failure.
-
-5.9.1. KRB_ERROR definition
-
-The KRB_ERROR message consists of the following fields:
-
-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-cksum[13]                   Checksum OPTIONAL,
-}
-
-
-
-pvno and msg-type
-     These fields are described above in section 5.4.1. msg-type is
-     KRB_ERROR.
-ctime
-     This field is described above in section 5.4.1.
-cusec
-     This field is described above in section 5.5.2.
-stime
-     This field contains the current time on the server. It is of type
-     KerberosTime.
-susec
-     This field contains the microsecond part of the server's timestamp.
-     Its value ranges from 0 to 999999. It appears along with stime. The
-     two fields are used in conjunction to specify a reasonably accurate
-     timestamp.
-error-code
-     This field contains the error code returned by Kerberos or the server
-     when a request fails. To interpret the value of this field see the
-     list of error codes in section 8. Implementations are encouraged to
-     provide for national language support in the display of error
-     messages.
-crealm, cname, srealm and sname
-     These fields are described above in section 5.3.1.
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-e-text
-     This field contains additional text to help explain the error code
-     associated with the failed request (for example, it might include a
-     principal name which was unknown).
-e-data
-     This field contains additional data about the error for use by the
-     application to help it recover from or handle the error. If present,
-     this field will contain the encoding of a sequence of TypedData
-     (TYPED-DATA below), unless the errorcode is KDC_ERR_PREAUTH_REQUIRED,
-     in which case it will contain the encoding of a sequence of of padata
-     fields (METHOD-DATA below), each corresponding to an acceptable
-     pre-authentication method and optionally containing data for the
-     method:
-
-     TYPED-DATA   ::=   SEQUENCE of TypeData
-     METHOD-DATA  ::=   SEQUENCE of PA-DATA
-
-     TypedData ::=   SEQUENCE {
-                         data-type[0]   INTEGER,
-                         data-value[1]  OCTET STRING OPTIONAL
-     }
-
-     Note that e-data-types have been reserved for all PA data types
-     defined prior to July 1999. For the KDC_ERR_PREAUTH_REQUIRED message,
-     when using new PA data types defined in July 1999 or later, the
-     METHOD-DATA sequence must itself be encapsulated in an TypedData
-     element of type TD-PADATA. All new implementations interpreting the
-     METHOD-DATA field for the KDC_ERR_PREAUTH_REQUIRED message must accept
-     a type of TD-PADATA, extract the typed data field and interpret the
-     use any elements encapsulated in the TD-PADATA elements as if they
-     were present in the METHOD-DATA sequence.
-e-cksum
-     This field contains an optional checksum for the KRB-ERROR message.
-     The checksum is calculated over the Kerberos ASN.1 encoding of the
-     KRB-ERROR message with the checksum absent. The checksum is then added
-     to the KRB-ERROR structure and the message is re-encoded. The Checksum
-     should be calculated using the session key from the ticket granting
-     ticket or service ticket, where available. If the error is in response
-     to a TGS or AP request, the checksum should be calculated uing the the
-     session key from the client's ticket. If the error is in response to
-     an AS request, then the checksum should be calulated using the
-     client's secret key ONLY if there has been suitable preauthentication
-     to prove knowledge of the secret key by the client[33]. If a checksum
-     can not be computed because the key to be used is not available, no
-     checksum will be included.
-
-     6. Encryption and Checksum Specifications
-
-     The Kerberos protocols described in this document are designed to use
-     stream encryption ciphers, which can be simulated using commonly
-     available block encryption ciphers, such as the Data Encryption
-     Standard [DES77], and triple DES variants, in conjunction with block
-     chaining and checksum methods [DESM80]. Encryption is used to prove
-     the identities of the network entities participating in message
-     exchanges. The Key Distribution Center for each realm is trusted by
-     all principals registered in that realm to store a secret key in
-     confidence. Proof of knowledge of this secret key is used to verify
-     the authenticity of a principal.
-
-     The KDC uses the principal's secret key (in the AS exchange) or a
-     shared session key (in the TGS exchange) to encrypt responses to
-     ticket requests; the ability to obtain the secret key or session key
-     implies the knowledge of the appropriate keys and the identity of the
-     KDC. The ability of a principal to decrypt the KDC response and
-     present a Ticket and a properly formed Authenticator (generated with
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     the session key from the KDC response) to a service verifies the
-     identity of the principal; likewise the ability of the service to
-     extract the session key from the Ticket and prove its knowledge
-     thereof in a response verifies the identity of the service.
-
-     The Kerberos protocols generally assume that the encryption used is
-     secure from cryptanalysis; however, in some cases, the order of fields
-     in the encrypted portions of messages are arranged to minimize the
-     effects of poorly chosen keys. It is still important to choose good
-     keys. If keys are derived from user-typed passwords, those passwords
-     need to be well chosen to make brute force attacks more difficult.
-     Poorly chosen keys still make easy targets for intruders.
-
-     The following sections specify the encryption and checksum mechanisms
-     currently defined for Kerberos. The encodings, chaining, and padding
-     requirements for each are described. For encryption methods, it is
-     often desirable to place random information (often referred to as a
-     confounder) at the start of the message. The requirements for a
-     confounder are specified with each encryption mechanism.
-
-     Some encryption systems use a block-chaining method to improve the the
-     security characteristics of the ciphertext. However, these chaining
-     methods often don't provide an integrity check upon decryption. Such
-     systems (such as DES in CBC mode) must be augmented with a checksum of
-     the plain-text which can be verified at decryption and used to detect
-     any tampering or damage. Such checksums should be good at detecting
-     burst errors in the input. If any damage is detected, the decryption
-     routine is expected to return an error indicating the failure of an
-     integrity check. Each encryption type is expected to provide and
-     verify an appropriate checksum. The specification of each encryption
-     method sets out its checksum requirements.
-
-     Finally, where a key is to be derived from a user's password, an
-     algorithm for converting the password to a key of the appropriate type
-     is included. It is desirable for the string to key function to be
-     one-way, and for the mapping to be different in different realms. This
-     is important because users who are registered in more than one realm
-     will often use the same password in each, and it is desirable that an
-     attacker compromising the Kerberos server in one realm not obtain or
-     derive the user's key in another.
-
-     For an discussion of the integrity characteristics of the candidate
-     encryption and checksum methods considered for Kerberos, the reader is
-     referred to [SG92].
-
-     6.1. Encryption Specifications
-
-     The following ASN.1 definition describes all encrypted messages. The
-     enc-part field which appears in the unencrypted part of messages in
-     section 5 is a sequence consisting of an encryption type, an optional
-     key version number, and the ciphertext.
-
-     EncryptedData ::=   SEQUENCE {
-                         etype[0]     INTEGER, -- EncryptionType
-                         kvno[1]      INTEGER OPTIONAL,
-                         cipher[2]    OCTET STRING -- ciphertext
-     }
-
-
-
-     etype
-          This field identifies which encryption algorithm was used to
-          encipher the cipher. Detailed specifications for selected
-          encryption types appear later in this section.
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     kvno
-          This field contains the version number of the key under which
-          data is encrypted. It is only present in messages encrypted under
-          long lasting keys, such as principals' secret keys.
-     cipher
-          This field contains the enciphered text, encoded as an OCTET
-          STRING.
-     The cipher field is generated by applying the specified encryption
-     algorithm to data composed of the message and algorithm-specific
-     inputs. Encryption mechanisms defined for use with Kerberos must take
-     sufficient measures to guarantee the integrity of the plaintext, and
-     we recommend they also take measures to protect against precomputed
-     dictionary attacks. If the encryption algorithm is not itself capable
-     of doing so, the protections can often be enhanced by adding a
-     checksum and a confounder.
-
-     The suggested format for the data to be encrypted includes a
-     confounder, a checksum, the encoded plaintext, and any necessary
-     padding. The msg-seq field contains the part of the protocol message
-     described in section 5 which is to be encrypted. The confounder,
-     checksum, and padding are all untagged and untyped, and their length
-     is exactly sufficient to hold the appropriate item. The type and
-     length is implicit and specified by the particular encryption type
-     being used (etype). The format for the data to be encrypted for some
-     methods is described in the following diagram, but other methods may
-     deviate from this layour - so long as the definition of the method
-     defines the layout actually in use.
-
-           +-----------+----------+-------------+-----+
-           |confounder |   check  |   msg-seq   | pad |
-           +-----------+----------+-------------+-----+
-
-     The format cannot be described in ASN.1, but for those who prefer an
-     ASN.1-like notation:
-
-     CipherText ::=   ENCRYPTED       SEQUENCE {
-             confounder[0]   UNTAGGED[35] OCTET STRING(conf_length)
-OPTIONAL,
-             check[1]        UNTAGGED OCTET STRING(checksum_length)
-OPTIONAL,
-             msg-seq[2]      MsgSequence,
-             pad             UNTAGGED OCTET STRING(pad_length) OPTIONAL
-     }
-
-     One generates a random confounder of the appropriate length, placing
-     it in confounder; zeroes out check; calculates the appropriate
-     checksum over confounder, check, and msg-seq, placing the result in
-     check; adds the necessary padding; then encrypts using the specified
-     encryption type and the appropriate key.
-
-     Unless otherwise specified, a definition of an encryption algorithm
-     that specifies a checksum, a length for the confounder field, or an
-     octet boundary for padding uses this ciphertext format[36]. Those
-     fields which are not specified will be omitted.
-
-     In the interest of allowing all implementations using a particular
-     encryption type to communicate with all others using that type, the
-     specification of an encryption type defines any checksum that is
-     needed as part of the encryption process. If an alternative checksum
-     is to be used, a new encryption type must be defined.
-
-     Some cryptosystems require additional information beyond the key and
-     the data to be encrypted. For example, DES, when used in
-     cipher-block-chaining mode, requires an initialization vector. If
-     required, the description for each encryption type must specify the
-     source of such additional information. 6.2. Encryption Keys
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     The sequence below shows the encoding of an encryption key:
-
-            EncryptionKey ::=   SEQUENCE {
-                                keytype[0]    INTEGER,
-                                keyvalue[1]   OCTET STRING
-            }
-
-     keytype
-          This field specifies the type of encryption that is to be
-          performed using the key that follows in the keyvalue field. It
-          will always correspond to the etype to be used to generate or
-          decode the EncryptedData. In cases when multiple algorithms use a
-          common kind of key (e.g., if the encryption algorithm uses an
-          alternate checksum algorithm for an integrity check, or a
-          different chaining mechanism), the keytype provides information
-          needed to determine which algorithm is to be used.
-     keyvalue
-          This field contains the key itself, encoded as an octet string.
-     All negative values for the encryption key type are reserved for local
-     use. All non-negative values are reserved for officially assigned type
-     fields and interpreta- tions.
-
-     6.3. Encryption Systems
-
-     6.3.1. The NULL Encryption System (null)
-
-     If no encryption is in use, the encryption system is said to be the
-     NULL encryption system. In the NULL encryption system there is no
-     checksum, confounder or padding. The ciphertext is simply the
-     plaintext. The NULL Key is used by the null encryption system and is
-     zero octets in length, with keytype zero (0).
-
-     6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
-
-     The des-cbc-crc encryption mode encrypts information under the Data
-     Encryption Standard [DES77] using the cipher block chaining mode
-     [DESM80]. A CRC-32 checksum (described in ISO 3309 [ISO3309]) is
-     applied to the confounder and message sequence (msg-seq) and placed in
-     the cksum field. DES blocks are 8 bytes. As a result, the data to be
-     encrypted (the concatenation of confounder, checksum, and message)
-     must be padded to an 8 byte boundary before encryption. The details of
-     the encryption of this data are identical to those for the des-cbc-md5
-     encryption mode.
-
-     Note that, since the CRC-32 checksum is not collision-proof, an
-     attacker could use a probabilistic chosen-plaintext attack to generate
-     a valid message even if a confounder is used [SG92]. The use of
-     collision-proof checksums is recommended for environments where such
-     attacks represent a significant threat. The use of the CRC-32 as the
-     checksum for ticket or authenticator is no longer mandated as an
-     interoperability requirement for Kerberos Version 5 Specification 1
-     (See section 9.1 for specific details).
-
-     6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
-
-     The des-cbc-md4 encryption mode encrypts information under the Data
-     Encryption Standard [DES77] using the cipher block chaining mode
-     [DESM80]. An MD4 checksum (described in [MD492]) is applied to the
-     confounder and message sequence (msg-seq) and placed in the cksum
-     field. DES blocks are 8 bytes. As a result, the data to be encrypted
-     (the concatenation of confounder, checksum, and message) must be
-     padded to an 8 byte boundary before encryption. The details of the
-     encryption of this data are identical to those for the des-cbc-md5
-     encryption mode.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
-
-     The des-cbc-md5 encryption mode encrypts information under the Data
-     Encryption Standard [DES77] using the cipher block chaining mode
-     [DESM80]. An MD5 checksum (described in [MD5-92].) is applied to the
-     confounder and message sequence (msg-seq) and placed in the cksum
-     field. DES blocks are 8 bytes. As a result, the data to be encrypted
-     (the concatenation of confounder, checksum, and message) must be
-     padded to an 8 byte boundary before encryption.
-
-     Plaintext and DES ciphtertext are encoded as blocks of 8 octets which
-     are concatenated to make the 64-bit inputs for the DES algorithms. The
-     first octet supplies the 8 most significant bits (with the octet's
-     MSbit used as the DES input block's MSbit, etc.), the second octet the
-     next 8 bits, ..., and the eighth octet supplies the 8 least
-     significant bits.
-
-     Encryption under DES using cipher block chaining requires an
-     additional input in the form of an initialization vector. Unless
-     otherwise specified, zero should be used as the initialization vector.
-     Kerberos' use of DES requires an 8 octet confounder.
-
-     The DES specifications identify some 'weak' and 'semi-weak' keys;
-     those keys shall not be used for encrypting messages for use in
-     Kerberos. Additionally, because of the way that keys are derived for
-     the encryption of checksums, keys shall not be used that yield 'weak'
-     or 'semi-weak' keys when eXclusive-ORed with the hexadecimal constant
-     F0F0F0F0F0F0F0F0.
-
-     A DES key is 8 octets of data, with keytype one (1). This consists of
-     56 bits of key, and 8 parity bits (one per octet). The key is encoded
-     as a series of 8 octets written in MSB-first order. The bits within
-     the key are also encoded in MSB order. For example, if the encryption
-     key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8)
-     where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8
-     are the parity bits, the first octet of the key would be
-     B1,B2,...,B7,P1 (with B1 as the MSbit). [See the FIPS 81 introduction
-     for reference.]
-
-     String to key transformation
-
-     To generate a DES key from a text string (password), a "salt" is
-     concatenated to the text string, and then padded with ASCII nulls to
-     an 8 byte boundary. This "salt" is normally the realm and each
-     component of the principal's name appended. However, sometimes
-     different salts are used --- for example, when a realm is renamed, or
-     if a user changes her username, or for compatibility with Kerberos V4
-     (whose string-to-key algorithm uses a null string for the salt). This
-     string is then fan-folded and eXclusive-ORed with itself to form an 8
-     byte DES key. Before eXclusive-ORing a block, every byte is shifted
-     one bit to the left to leave the lowest bit zero. The key is the
-     "corrected" by correcting the parity on the key, and if the key
-     matches a 'weak' or 'semi-weak' key as described in the DES
-     specification, it is eXclusive-ORed with the constant
-     00000000000000F0. This key is then used to generate a DES CBC checksum
-     on the initial string (with the salt appended). The result of the CBC
-     checksum is the "corrected" as described above to form the result
-     which is return as the key. Pseudocode follows:
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-          name_to_default_salt(realm, name) {
-               s = realm
-               for(each component in name) {
-                    s = s + component;
-               }
-               return s;
-          }
-
-          key_correction(key) {
-               fixparity(key);
-               if (is_weak_key_key(key))
-                    key = key XOR 0xF0;
-               return(key);
-          }
-
-          string_to_key(string,salt) {
-
-               odd = 1;
-               s = string + salt;
-               tempkey = NULL;
-               pad(s); /* with nulls to 8 byte boundary */
-               for(8byteblock in s) {
-                    if(odd == 0)  {
-                        odd = 1;
-                        reverse(8byteblock)
-                    }
-                    else odd = 0;
-                    left shift every byte in 8byteblock one bit;
-                    tempkey = tempkey XOR 8byteblock;
-               }
-               tempkey = key_correction(tempkey);
-               key = key_correction(DES-CBC-check(s,tempkey));
-               return(key);
-          }
-
-     6.3.5. Triple DES with HMAC-SHA1 Kerberos Encryption Type with and
-     without Key Derivation [Original draft by Marc Horowitz, revisions by
-     David Miller]
-
-          There are still a few pieces of this specification to be included
-          by falue, rather than by reference. This will be done before the
-          Pittsburgh IETF.
-     This encryption type is based on the Triple DES cryptosystem, the
-     HMAC-SHA1 [Krawczyk96] message authentication algorithm, and key
-     derivation for Kerberos V5 [HorowitzB96]. Key derivation may or may
-     not be used in conjunction with the use of Triple DES keys.
-
-     Algorithm Identifiers
-
-     The des3-cbc-hmac-sha1 encryption type has been assigned the value 7.
-     The des3-cbc-hmac-sha1-kd encryption type, specifying the key
-     derivation variant of the encryption type, has been assigned the value
-     16. The hmac-sha1-des3 checksum type has been assigned the value 13.
-     The hmac-sha1-des3-kd checksum type, specifying the key derivation
-     variant of the checksum, has been assigned the value 12.
-
-     Triple DES Key Production
-
-     The EncryptionKey value is 24 octets long. The 7 most significant bits
-     of each octet contain key bits, and the least significant bit is the
-     inverse of the xor of the key bits.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     For the purposes of key derivation, the block size is 64 bits, and the
-     key size is 168 bits. The 168 bits output by key derivation are
-     converted to an EncryptionKey value as follows. First, the 168 bits
-     are divided into three groups of 56 bits, which are expanded
-     individually into 64 bits as follows:
-
-      1  2  3  4  5  6  7  p
-      9 10 11 12 13 14 15  p
-     17 18 19 20 21 22 23  p
-     25 26 27 28 29 30 31  p
-     33 34 35 36 37 38 39  p
-     41 42 43 44 45 46 47  p
-     49 50 51 52 53 54 55  p
-     56 48 40 32 24 16  8  p
-
-     The "p" bits are parity bits computed over the data bits. The output
-     of the three expansions are concatenated to form the EncryptionKey
-     value.
-
-     When the HMAC-SHA1 of a string is computed, the key is used in the
-     EncryptedKey form.
-
-     The string-to-key function is used to tranform UNICODE passwords into
-     DES3 keys. The DES3 string-to-key function relies on the "N-fold"
-     algorithm, which is detailed in [9]. The description of the N-fold
-     algorithm in that document is as follows:
-        o To n-fold a number X, replicate the input value to a length that
-          is the least common multiple of n and the length of X. Before
-          each repetition, the input is rotated to the right by 13 bit
-          positions. The successive n-bit chunks are added together using
-          1's-complement addition (that is, addition with end-around carry)
-          to yield an n-bit result"
-        o The n-fold algorithm, as with DES string-to-key, is applied to
-          the password string concatenated with a salt value. The salt
-          value is derived in the same was as for the DES string-to-key
-          algorithm. For 3-key triple DES then, the operation will involve
-          a 168-fold of the input password string. The remainder of the
-          string-to-key function for DES3 is shown here in pseudocode:
-
-     DES3string-to-key(passwordString, key)
-
-         salt = name_to_default_salt(realm, name)
-         s = passwordString + salt
-         tmpKey1 = 168-fold(s)
-         parityFix(tmpKey1);
-         if not weakKey(tmpKey1)
-             /*
-              * Encrypt temp key in itself with a
-              * zero initialization vector
-              *
-              * Function signature is DES3encrypt(plain, key, iv)
-              * with cipher as the return value
-              */
-             tmpKey2 = DES3encrypt(tmpKey1, tmpKey1, zeroIvec)
-             /*
-              * Encrypt resultant temp key in itself with third component
-              * of first temp key as initialization vector
-              */
-             key = DES3encrypt(tmpKey2, tmpKey1, tmpKey1[2])
-             parityFix(key)
-             if not weakKey(key)
-                  return SUCCESS
-             else
-                  return FAILURE
-         else
-             return FAILURE
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     The weakKey function above is the same weakKey function used with DES
-     keys, but applied to each of the three single DES keys that comprise
-     the triple DES key.
-
-     The lengths of UNICODE encoded character strings include the trailing
-     terminator character (0).
-
-     Encryption Types des3-cbc-hmac-sha1 and des3-cbc-hmac-sha1-kd
-
-     EncryptedData using this type must be generated as described in
-     [Horowitz96]. The encryption algorithm is Triple DES in Outer-CBC
-     mode. The checksum algorithm is HMAC-SHA1. If the key derivation
-     variant of the encryption type is used, encryption key values are
-     modified according to the method under the Key Derivation section
-     below.
-
-     Unless otherwise specified, a zero IV must be used.
-
-     If the length of the input data is not a multiple of the block size,
-     zero octets must be used to pad the plaintext to the next eight-octet
-     boundary. The counfounder must be eight random octets (one block).
-
-     Checksum Types hmac-sha1-des3 and hmac-sha1-des3-kd
-
-     Checksums using this type must be generated as described in
-     [Horowitz96]. The keyed hash algorithm is HMAC-SHA1. If the key
-     derivation variant of the checksum type is used, checksum key values
-     are modified according to the method under the Key Derivation section
-     below.
-
-     Key Derivation
-
-     In the Kerberos protocol, cryptographic keys are used in a number of
-     places. In order to minimize the effect of compromising a key, it is
-     desirable to use a different key for each of these places. Key
-     derivation [Horowitz96] can be used to construct different keys for
-     each operation from the keys transported on the network. For this to
-     be possible, a small change to the specification is necessary.
-
-     This section specifies a profile for the use of key derivation
-     [Horowitz96] with Kerberos. For each place where a key is used, a
-     ``key usage'' must is specified for that purpose. The key, key usage,
-     and encryption/checksum type together describe the transformation from
-     plaintext to ciphertext, or plaintext to checksum.
-
-     Key Usage Values
-
-     This is a complete list of places keys are used in the kerberos
-     protocol, with key usage values and RFC 1510 section numbers:
-
-      1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
-         client key (section 5.4.1)
-      2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
-         application session key), encrypted with the service key
-         (section 5.4.2)
-      3. AS-REP encrypted part (includes tgs session key or application
-         session key), encrypted with the client key (section 5.4.2)
-      4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
-         session key (section 5.4.1)
-      5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
-         authenticator subkey (section 5.4.1)
-      6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
-         with the tgs session key (sections 5.3.2, 5.4.1)
-      7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
-         authenticator subkey), encrypted with the tgs session key
-         (section 5.3.2)
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-      8. TGS-REP encrypted part (includes application session key),
-         encrypted with the tgs session key (section 5.4.2)
-      9. TGS-REP encrypted part (includes application session key),
-         encrypted with the tgs authenticator subkey (section 5.4.2)
-     10. AP-REQ Authenticator cksum, keyed with the application session
-         key (section 5.3.2)
-     11. AP-REQ Authenticator (includes application authenticator
-         subkey), encrypted with the application session key (section
-         5.3.2)
-     12. AP-REP encrypted part (includes application session subkey),
-         encrypted with the application session key (section 5.5.2)
-     13. KRB-PRIV encrypted part, encrypted with a key chosen by the
-         application (section 5.7.1)
-     14. KRB-CRED encrypted part, encrypted with a key chosen by the
-         application (section 5.6.1)
-     15. KRB-SAVE cksum, keyed with a key chosen by the application
-         (section 5.8.1)
-     18. KRB-ERROR checksum (e-cksum in section 5.9.1)
-     19. AD-KDCIssued checksum (ad-checksum in appendix B.1)
-     20. Checksum for Mandatory Ticket Extensions (appendix B.6)
-     21. Checksum in Authorization Data in Ticket Extensions (appendix B.7)
-
-     Key usage values between 1024 and 2047 (inclusive) are reserved for
-     application use. Applications should use even values for encryption
-     and odd values for checksums within this range.
-
-     A few of these key usages need a little clarification. A service which
-     receives an AP-REQ has no way to know if the enclosed Ticket was part
-     of an AS-REP or TGS-REP. Therefore, key usage 2 must always be used
-     for generating a Ticket, whether it is in response to an AS- REQ or
-     TGS-REQ.
-
-     There might exist other documents which define protocols in terms of
-     the RFC1510 encryption types or checksum types. Such documents would
-     not know about key usages. In order that these documents continue to
-     be meaningful until they are updated, key usages 1024 and 1025 must be
-     used to derive keys for encryption and checksums, respectively. New
-     protocols defined in terms of the Kerberos encryption and checksum
-     types should use their own key usages. Key usages may be registered
-     with IANA to avoid conflicts. Key usages must be unsigned 32 bit
-     integers. Zero is not permitted.
-
-     Defining Cryptosystems Using Key Derivation
-
-     Kerberos requires that the ciphertext component of EncryptedData be
-     tamper-resistant as well as confidential. This implies encryption and
-     integrity functions, which must each use their own separate keys. So,
-     for each key usage, two keys must be generated, one for encryption
-     (Ke), and one for integrity (Ki):
-
-           Ke = DK(protocol key, key usage | 0xAA)
-           Ki = DK(protocol key, key usage | 0x55)
-
-     where the protocol key is from the EncryptionKey from the wire
-     protocol, and the key usage is represented as a 32 bit integer in
-     network byte order. The ciphertest must be generated from the
-     plaintext as follows:
-
-        ciphertext = E(Ke, confounder | plaintext | padding) |
-                     H(Ki, confounder | plaintext | padding)
-
-     The confounder and padding are specific to the encryption algorithm E.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     When generating a checksum only, there is no need for a confounder or
-     padding. Again, a new key (Kc) must be used. Checksums must be
-     generated from the plaintext as follows:
-
-           Kc = DK(protocol key, key usage | 0x99)
-           MAC = H(Kc, plaintext)
-
-     Note that each enctype is described by an encryption algorithm E and a
-     keyed hash algorithm H, and each checksum type is described by a keyed
-     hash algorithm H. HMAC, with an appropriate hash, is required for use
-     as H.
-
-     Key Derivation from Passwords
-
-     The well-known constant for password key derivation must be the byte
-     string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values
-     correspond to the ASCII encoding for the string "kerberos".
-
-     6.4. Checksums
-
-     The following is the ASN.1 definition used for a checksum:
-
-              Checksum ::=   SEQUENCE {
-                             cksumtype[0]   INTEGER,
-                             checksum[1]    OCTET STRING
-              }
-
-     cksumtype
-          This field indicates the algorithm used to generate the
-          accompanying checksum.
-     checksum
-          This field contains the checksum itself, encoded as an octet
-          string.
-     Detailed specification of selected checksum types appear later in this
-     section. Negative values for the checksum type are reserved for local
-     use. All non-negative values are reserved for officially assigned type
-     fields and interpretations.
-
-     Checksums used by Kerberos can be classified by two properties:
-     whether they are collision-proof, and whether they are keyed. It is
-     infeasible to find two plaintexts which generate the same checksum
-     value for a collision-proof checksum. A key is required to perturb or
-     initialize the algorithm in a keyed checksum. To prevent
-     message-stream modification by an active attacker, unkeyed checksums
-     should only be used when the checksum and message will be subsequently
-     encrypted (e.g. the checksums defined as part of the encryption
-     algorithms covered earlier in this section).
-
-     Collision-proof checksums can be made tamper-proof if the checksum
-     value is encrypted before inclusion in a message. In such cases, the
-     composition of the checksum and the encryption algorithm must be
-     considered a separate checksum algorithm (e.g. RSA-MD5 encrypted using
-     DES is a new checksum algorithm of type RSA-MD5-DES). For most keyed
-     checksums, as well as for the encrypted forms of unkeyed
-     collision-proof checksums, Kerberos prepends a confounder before the
-     checksum is calculated.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     6.4.1. The CRC-32 Checksum (crc32)
-
-     The CRC-32 checksum calculates a checksum based on a cyclic redundancy
-     check as described in ISO 3309 [ISO3309]. The resulting checksum is
-     four (4) octets in length. The CRC-32 is neither keyed nor
-     collision-proof. The use of this checksum is not recommended. An
-     attacker using a probabilistic chosen-plaintext attack as described in
-     [SG92] might be able to generate an alternative message that satisfies
-     the checksum. The use of collision-proof checksums is recommended for
-     environments where such attacks represent a significant threat.
-
-     6.4.2. The RSA MD4 Checksum (rsa-md4)
-
-     The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm
-     [MD4-92]. The algorithm takes as input an input message of arbitrary
-     length and produces as output a 128-bit (16 octet) checksum. RSA-MD4
-     is believed to be collision-proof.
-
-     6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4-des)
-
-     The RSA-MD4-DES checksum calculates a keyed collision-proof checksum
-     by prepending an 8 octet confounder before the text, applying the RSA
-     MD4 checksum algorithm, and encrypting the confounder and the checksum
-     using DES in cipher-block-chaining (CBC) mode using a variant of the
-     key, where the variant is computed by eXclusive-ORing the key with the
-     constant F0F0F0F0F0F0F0F0[39]. The initialization vector should be
-     zero. The resulting checksum is 24 octets long (8 octets of which are
-     redundant). This checksum is tamper-proof and believed to be
-     collision-proof.
-
-     The DES specifications identify some weak keys' and 'semi-weak keys';
-     those keys shall not be used for generating RSA-MD4 checksums for use
-     in Kerberos.
-
-     The format for the checksum is described in the follow- ing diagram:
-
-
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-     |  des-cbc(confounder   +   rsa-md4(confounder+msg),key=var(key),iv=0)
-|
-
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-     The format cannot be described in ASN.1, but for those who prefer an
-     ASN.1-like notation:
-
-     rsa-md4-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                                confounder[0]   UNTAGGED OCTET STRING(8),
-                                check[1]        UNTAGGED OCTET STRING(16)
-     }
-
-     6.4.4. The RSA MD5 Checksum (rsa-md5)
-
-     The RSA-MD5 checksum calculates a checksum using the RSA MD5
-     algorithm. [MD5-92]. The algorithm takes as input an input message of
-     arbitrary length and produces as output a 128-bit (16 octet) checksum.
-     RSA-MD5 is believed to be collision-proof.
-
-     6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5-des)
-
-     The RSA-MD5-DES checksum calculates a keyed collision-proof checksum
-     by prepending an 8 octet confounder before the text, applying the RSA
-     MD5 checksum algorithm, and encrypting the confounder and the checksum
-     using DES in cipher-block-chaining (CBC) mode using a variant of the
-     key, where the variant is computed by eXclusive-ORing the key with the
-     hexadecimal constant F0F0F0F0F0F0F0F0. The initialization vector
-     should be zero. The resulting checksum is 24 octets long (8 octets of
-     which are redundant). This checksum is tamper-proof and believed to be
-     collision-proof.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     The DES specifications identify some 'weak keys' and 'semi-weak keys';
-     those keys shall not be used for encrypting RSA-MD5 checksums for use
-     in Kerberos.
-
-     The format for the checksum is described in the following diagram:
-
-
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-     |  des-cbc(confounder   +   rsa-md5(confounder+msg),key=var(key),iv=0)
-|
-
-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-     The format cannot be described in ASN.1, but for those who prefer an
-     ASN.1-like notation:
-
-     rsa-md5-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                                confounder[0]   UNTAGGED OCTET STRING(8),
-                                check[1]        UNTAGGED OCTET STRING(16)
-     }
-
-     6.4.6. DES cipher-block chained checksum (des-mac)
-
-     The DES-MAC checksum is computed by prepending an 8 octet confounder
-     to the plaintext, performing a DES CBC-mode encryption on the result
-     using the key and an initialization vector of zero, taking the last
-     block of the ciphertext, prepending the same confounder and encrypting
-     the pair using DES in cipher-block-chaining (CBC) mode using a a
-     variant of the key, where the variant is computed by eXclusive-ORing
-     the key with the hexadecimal constant F0F0F0F0F0F0F0F0. The
-     initialization vector should be zero. The resulting checksum is 128
-     bits (16 octets) long, 64 bits of which are redundant. This checksum
-     is tamper-proof and collision-proof.
-
-     The format for the checksum is described in the following diagram:
-
-
-+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
-     |   des-cbc(confounder  + des-mac(conf+msg,iv=0,key),key=var(key),iv=0)
-|
-
-+--+--+--+--+--+--+--+--+-----+-----+-----+-----+-----+-----+-----+-----+
-
-     The format cannot be described in ASN.1, but for those who prefer an
-     ASN.1-like notation:
-
-     des-mac-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                            confounder[0]   UNTAGGED OCTET STRING(8),
-                            check[1]        UNTAGGED OCTET STRING(8)
-     }
-
-     The DES specifications identify some 'weak' and 'semi-weak' keys;
-     those keys shall not be used for generating DES-MAC checksums for use
-     in Kerberos, nor shall a key be used whose variant is 'weak' or
-     'semi-weak'.
-
-     6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative
-     (rsa-md4-des-k)
-
-     The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum
-     by applying the RSA MD4 checksum algorithm and encrypting the results
-     using DES in cipher-block-chaining (CBC) mode using a DES key as both
-     key and initialization vector. The resulting checksum is 16 octets
-     long. This checksum is tamper-proof and believed to be
-     collision-proof. Note that this checksum type is the old method for
-     encoding the RSA-MD4-DES checksum and it is no longer recommended.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     6.4.8. DES cipher-block chained checksum alternative (des-mac-k)
-
-     The DES-MAC-K checksum is computed by performing a DES CBC-mode
-     encryption of the plaintext, and using the last block of the
-     ciphertext as the checksum value. It is keyed with an encryption key
-     and an initialization vector; any uses which do not specify an
-     additional initialization vector will use the key as both key and
-     initialization vector. The resulting checksum is 64 bits (8 octets)
-     long. This checksum is tamper-proof and collision-proof. Note that
-     this checksum type is the old method for encoding the DES-MAC checksum
-     and it is no longer recommended. The DES specifications identify some
-     'weak keys' and 'semi-weak keys'; those keys shall not be used for
-     generating DES-MAC checksums for use in Kerberos.
-
-     7. Naming Constraints
-
-     7.1. Realm Names
-
-     Although realm names are encoded as GeneralStrings and although a
-     realm can technically select any name it chooses, interoperability
-     across realm boundaries requires agreement on how realm names are to
-     be assigned, and what information they imply.
-
-     To enforce these conventions, each realm must conform to the
-     conventions itself, and it must require that any realms with which
-     inter-realm keys are shared also conform to the conventions and
-     require the same from its neighbors.
-
-     Kerberos realm names are case sensitive. Realm names that differ only
-     in the case of the characters are not equivalent. There are presently
-     four styles of realm names: domain, X500, other, and reserved.
-     Examples of each style follow:
-
-          domain:   ATHENA.MIT.EDU (example)
-            X500:   C=US/O=OSF (example)
-           other:   NAMETYPE:rest/of.name=without-restrictions (example)
-        reserved:   reserved, but will not conflict with above
-
-     Domain names must look like domain names: they consist of components
-     separated by periods (.) and they contain neither colons (:) nor
-     slashes (/). Though domain names themselves are case insensitive, in
-     order for realms to match, the case must match as well. When
-     establishing a new realm name based on an internet domain name it is
-     recommended by convention that the characters be converted to upper
-     case.
-
-     X.500 names contain an equal (=) and cannot contain a colon (:) before
-     the equal. The realm names for X.500 names will be string
-     representations of the names with components separated by slashes.
-     Leading and trailing slashes will not be included.
-
-     Names that fall into the other category must begin with a prefix that
-     contains no equal (=) or period (.) and the prefix must be followed by
-     a colon (:) and the rest of the name. All prefixes must be assigned
-     before they may be used. Presently none are assigned.
-
-     The reserved category includes strings which do not fall into the
-     first three categories. All names in this category are reserved. It is
-     unlikely that names will be assigned to this category unless there is
-     a very strong argument for not using the 'other' category.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     These rules guarantee that there will be no conflicts between the
-     various name styles. The following additional constraints apply to the
-     assignment of realm names in the domain and X.500 categories: the name
-     of a realm for the domain or X.500 formats must either be used by the
-     organization owning (to whom it was assigned) an Internet domain name
-     or X.500 name, or in the case that no such names are registered,
-     authority to use a realm name may be derived from the authority of the
-     parent realm. For example, if there is no domain name for E40.MIT.EDU,
-     then the administrator of the MIT.EDU realm can authorize the creation
-     of a realm with that name.
-
-     This is acceptable because the organization to which the parent is
-     assigned is presumably the organization authorized to assign names to
-     its children in the X.500 and domain name systems as well. If the
-     parent assigns a realm name without also registering it in the domain
-     name or X.500 hierarchy, it is the parent's responsibility to make
-     sure that there will not in the future exists a name identical to the
-     realm name of the child unless it is assigned to the same entity as
-     the realm name.
-
-     7.2. Principal Names
-
-     As was the case for realm names, conventions are needed to ensure that
-     all agree on what information is implied by a principal name. The
-     name-type field that is part of the principal name indicates the kind
-     of information implied by the name. The name-type should be treated as
-     a hint. Ignoring the name type, no two names can be the same (i.e. at
-     least one of the components, or the realm, must be different). The
-     following name types are defined:
-
-     name-type      value   meaning
-
-    NT-UNKNOWN        0   Name type not known
-    NT-PRINCIPAL      1   General principal name (e.g. username, DCE
-principal)
-    NT-SRV-INST       2   Service and other unique instance (krbtgt)
-    NT-SRV-HST        3   Service with host name as instance (telnet, rcmds)
-    NT-SRV-XHST       4   Service with slash-separated host name components
-    NT-UID            5   Unique ID
-    NT-X500-PRINCIPAL 6   Encoded X.509 Distingished name [RFC 1779]
-    NT-SMTP-NAME      7   Name in form of SMTP email name (e.g.
-user@foo.com)
-
-     When a name implies no information other than its uniqueness at a
-     particular time the name type PRINCIPAL should be used. The principal
-     name type should be used for users, and it might also be used for a
-     unique server. If the name is a unique machine generated ID that is
-     guaranteed never to be reassigned then the name type of UID should be
-     used (note that it is generally a bad idea to reassign names of any
-     type since stale entries might remain in access control lists).
-
-     If the first component of a name identifies a service and the
-     remaining components identify an instance of the service in a server
-     specified manner, then the name type of SRV-INST should be used. An
-     example of this name type is the Kerberos ticket-granting service
-     whose name has a first component of krbtgt and a second component
-     identifying the realm for which the ticket is valid.
-
-     If instance is a single component following the service name and the
-     instance identifies the host on which the server is running, then the
-     name type SRV-HST should be used. This type is typically used for
-     Internet services such as telnet and the Berkeley R commands. If the
-     separate components of the host name appear as successive components
-     following the name of the service, then the name type SRV-XHST should
-     be used. This type might be used to identify servers on hosts with
-     X.500 names where the slash (/) might otherwise be ambiguous.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     A name type of NT-X500-PRINCIPAL should be used when a name from an
-     X.509 certificiate is translated into a Kerberos name. The encoding of
-     the X.509 name as a Kerberos principal shall conform to the encoding
-     rules specified in RFC 2253.
-
-     A name type of SMTP allows a name to be of a form that resembles a
-     SMTP email name. This name type can be used in conjunction with
-     name-canonicalization to allow a free-form of username to be specified
-     as a client name and allow the KDC to determine the Kerberos principal
-     name for the requested name. [JBrezak]
-
-     A name type of UNKNOWN should be used when the form of the name is not
-     known. When comparing names, a name of type UNKNOWN will match
-     principals authenticated with names of any type. A principal
-     authenticated with a name of type UNKNOWN, however, will only match
-     other names of type UNKNOWN.
-
-     Names of any type with an initial component of 'krbtgt' are reserved
-     for the Kerberos ticket granting service. See section 8.2.3 for the
-     form of such names.
-
-     7.2.1. Name of server principals
-
-     The principal identifier for a server on a host will generally be
-     composed of two parts: (1) the realm of the KDC with which the server
-     is registered, and (2) a two-component name of type NT-SRV-HST if the
-     host name is an Internet domain name or a multi-component name of type
-     NT-SRV-XHST if the name of the host is of a form such as X.500 that
-     allows slash (/) separators. The first component of the two- or
-     multi-component name will identify the service and the latter
-     components will identify the host. Where the name of the host is not
-     case sensitive (for example, with Internet domain names) the name of
-     the host must be lower case. If specified by the application protocol
-     for services such as telnet and the Berkeley R commands which run with
-     system privileges, the first component may be the string 'host'
-     instead of a service specific identifier. 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.
-
-     8. Constants and other defined values
-
-     8.1. Host address types
-
-     All negative values for the host address type are reserved for local
-     use. All non-negative values are reserved for officially assigned type
-     fields and interpretations.
-
-     The values of the types for the following addresses are chosen to
-     match the defined address family constants in the Berkeley Standard
-     Distributions of Unix. They can be found in with symbolic names AF_xxx
-     (where xxx is an abbreviation of the address family name).
-
-     Internet (IPv4) Addresses
-
-     Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
-     MSB order. The type of IPv4 addresses is two (2).
-
-     Internet (IPv6) Addresses [Westerlund]
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB
-     order. The type of IPv6 addresses is twenty-four (24). [RFC1883]
-     [RFC1884]. The following addresses (see [RFC1884]) MUST not appear in
-     any Kerberos packet:
-        o the Unspecified Address
-        o the Loopback Address
-        o Link-Local addresses
-     IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
-
-     CHAOSnet addresses
-
-     CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB
-     order. The type of CHAOSnet addresses is five (5).
-
-     ISO addresses
-
-     ISO addresses are variable-length. The type of ISO addresses is seven
-     (7).
-
-     Xerox Network Services (XNS) addresses
-
-     XNS addresses are 48-bit (6-octet) quantities, encoded in MSB order.
-     The type of XNS addresses is six (6).
-
-     AppleTalk Datagram Delivery Protocol (DDP) addresses
-
-     AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit
-     network number. The first octet of the address is the node number; the
-     remaining two octets encode the network number in MSB order. The type
-     of AppleTalk DDP addresses is sixteen (16).
-
-     DECnet Phase IV addresses
-
-     DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order.
-     The type of DECnet Phase IV addresses is twelve (12).
-
-     Netbios addresses
-
-     Netbios addresses are 16-octet addresses typically composed of 1 to 15
-     characters, trailing blank (ascii char 20) filled, with a 16th octet
-     of 0x0. The type of Netbios addresses is 20 (0x14).
-
-     8.2. KDC messages
-
-     8.2.1. UDP/IP transport
-
-     When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request
-     using UDP IP transport, the client shall send a UDP datagram
-     containing only an encoding of the request to port 88 (decimal) at the
-     KDC's IP address; the KDC will respond with a reply datagram
-     containing only an encoding of the reply message (either a KRB_ERROR
-     or a KRB_KDC_REP) to the sending port at the sender's IP address.
-     Kerberos servers supporting IP transport must accept UDP requests on
-     port 88 (decimal). The response to a request made through UDP/IP
-     transport must also use UDP/IP transport.
-
-     8.2.2. TCP/IP transport [Westerlund,Danielsson]
-
-     Kerberos servers (KDC's) should accept TCP requests on port 88
-     (decimal) and clients should support the sending of TCP requests on
-     port 88 (decimal). When the KRB_KDC_REQ message is sent to the KDC
-     over a TCP stream, a new connection will be established for each
-     authentication exchange (request and response). The KRB_KDC_REP or
-     KRB_ERROR message will be returned to the client on the same TCP
-     stream that was established for the request. The response to a request
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     made through TCP/IP transport must also use TCP/IP transport.
-     Implementors should note that some extentions to the Kerberos protocol
-     will not work if any implementation not supporting the TCP transport
-     is involved (client or KDC). Implementors are strongly urged to
-     support the TCP transport on both the client and server and are
-     advised that the current notation of "should" support will likely
-     change in the future to must support. The KDC may close the TCP stream
-     after sending a response, but may leave the stream open if it expects
-     a followup - in which case it may close the stream at any time if
-     resource constratints or other factors make it desirable to do so.
-     Care must be taken in managing TCP/IP connections with the KDC to
-     prevent denial of service attacks based on the number of TCP/IP
-     connections with the KDC that remain open. If multiple exchanges with
-     the KDC are needed for certain forms of preauthentication, multiple
-     TCP connections may be required. A client may close the stream after
-     receiving response, and should close the stream if it does not expect
-     to send followup messages. The client must be prepared to have the
-     stream closed by the KDC at anytime, in which case it must simply
-     connect again when it is ready to send subsequent messages.
-
-     The first four octets of the TCP stream used to transmit the request
-     request will encode in network byte order the length of the request
-     (KRB_KDC_REQ), and the length will be followed by the request itself.
-     The response will similarly be preceeded by a 4 octet encoding in
-     network byte order of the length of the KRB_KDC_REP or the KRB_ERROR
-     message and will be followed by the KRB_KDC_REP or the KRB_ERROR
-     response. If the sign bit is set on the integer represented by the
-     first 4 octets, then the next 4 octets will be read, extending the
-     length of the field by another 4 octets (less the sign bit which is
-     reserved for future expansion).
-
-     8.2.3. OSI transport
-
-     During authentication of an OSI client to an OSI server, the mutual
-     authentication of an OSI server to an OSI client, the transfer of
-     credentials from an OSI client to an OSI server, or during exchange of
-     private or integrity checked messages, Kerberos protocol messages may
-     be treated as opaque objects and the type of the authentication
-     mechanism will be:
-
-     OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1),
-security(5),kerberosv5(2)}
-
-     Depending on the situation, the opaque object will be an
-     authentication header (KRB_AP_REQ), an authentication reply
-     (KRB_AP_REP), a safe message (KRB_SAFE), a private message (KRB_PRIV),
-     or a credentials message (KRB_CRED). The opaque data contains an
-     application code as specified in the ASN.1 description for each
-     message. The application code may be used by Kerberos to determine the
-     message type.
-
-     8.2.3. Name of the TGS
-
-     The principal identifier of the ticket-granting service shall be
-     composed of three parts: (1) the realm of the KDC issuing the TGS
-     ticket (2) a two-part name of type NT-SRV-INST, with the first part
-     "krbtgt" and the second part the name of the realm which will accept
-     the ticket-granting ticket. For example, a ticket-granting ticket
-     issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
-     ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
-     (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting ticket
-     issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
-     MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm),
-     ("krbtgt", "MIT.EDU") (name).
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     8.3. Protocol constants and associated values
-
-     The following tables list constants used in the protocol and defines
-     their meanings. Ranges are specified in the "specification" section
-     that limit the values of constants for which values are defined here.
-     This allows implementations to make assumptions about the maximum
-     values that will be received for these constants. Implementation
-     receiving values outside the range specified in the "specification"
-     section may reject the request, but they must recover cleanly.
-
-     Encryption type       etype value block size  minimum pad  confounder
-size
-     NULL                           0     1           0            0
-     des-cbc-crc                    1     8           4            8
-     des-cbc-md4                    2     8           0            8
-     des-cbc-md5                    3     8           0            8
-     reserved                       4
-     des3-cbc-md5                   5     8           0                 8
-     reserved                       6
-     des3-cbc-sha1                  7     8           0                 8
-     dsaWithSHA1-CmsOID             9
-(pkinit)
-     md5WithRSAEncryption-CmsOID   10
-(pkinit)
-     sha1WithRSAEncryption-CmsOID  11
-(pkinit)
-     rc2CBC-EnvOID                 12
-(pkinit)
-     rsaEncryption-EnvOID          13                (pkinit from PKCS#1
-v1.5)
-     rsaES-OAEP-ENV-OID            14                (pkinit from PKCS#1
-v2.0)
-     des-ede3-cbc-Env-OID          15
-(pkinit)
-     des3-cbc-sha1-kd              16                                 (Tom
-Yu)
-     rc4-hmac                      23
-(swift)
-     rc4-hmac-exp                  24
-(swift)
-
-     reserved                      0x8003
-
-     Checksum type              sumtype value       checksum size
-     CRC32                      1                   4
-     rsa-md4                    2                   16
-     rsa-md4-des                3                   24
-     des-mac                    4                   16
-     des-mac-k                  5                   8
-     rsa-md4-des-k              6                   16 (drop rsa ?)
-     rsa-md5                    7                   16 (drop rsa ?)
-     rsa-md5-des                8                   24 (drop rsa ?)
-     rsa-md5-des3               9                   24 (drop rsa ?)
-     hmac-sha1-des3-kd          12                  20
-     hmac-sha1-des3             13                  20
-     sha1 (unkeyed)             14                  20
-
-     padata type                     padata-type value
-
-     PA-TGS-REQ                      1
-     PA-ENC-TIMESTAMP                2
-     PA-PW-SALT                      3
-     reserved                        4
-     PA-ENC-UNIX-TIME                5                  (depricated)
-     PA-SANDIA-SECUREID              6
-     PA-SESAME                       7
-     PA-OSF-DCE                      8
-     PA-CYBERSAFE-SECUREID           9
-     PA-AFS3-SALT                    10
-     PA-ETYPE-INFO                   11
-     PA-SAM-CHALLENGE                12                  (sam/otp)
-     PA-SAM-RESPONSE                 13                  (sam/otp)
-     PA-PK-AS-REQ                    14                  (pkinit)
-     PA-PK-AS-REP                    15                  (pkinit)
-     PA-USE-SPECIFIED-KVNO           20
-     PA-SAM-REDIRECT                 21                  (sam/otp)
-     PA-GET-FROM-TYPED-DATA          22
-     PA-SAM-ETYPE-INFO               23                  (sam/otp)
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     data-type                     value    form of typed-data
-
-     reserved                        1-21
-     TD-PADATA                       22
-     TD-PKINIT-CMS-CERTIFICATES      101      CertificateSet from CMS
-     TD-KRB-PRINCIPAL                102
-     TD-KRB-REALM                    103
-     TD-TRUSTED-CERTIFIERS           104
-     TD-CERTIFICATE-INDEX            105
-     TD-APP-DEFINED-ERROR            106
-
-     authorization data type         ad-type value
-     AD-IF-RELEVANT                     1
-     AD-INTENDED-FOR-SERVER             2
-     AD-INTENDED-FOR-APPLICATION-CLASS  3
-     AD-KDC-ISSUED                      4
-     AD-OR                              5
-     AD-MANDATORY-TICKET-EXTENSIONS     6
-     AD-IN-TICKET-EXTENSIONS            7
-     reserved values                    8-63
-     OSF-DCE                            64
-     SESAME                             65
-     AD-OSF-DCE-PKI-CERTID              66    (hemsath@us.ibm.com)
-     AD-WIN200-PAC                     128
-(jbrezak@exchange.microsoft.com)
-
-     Ticket Extension Types
-
-     TE-TYPE-NULL                  0     Null ticket extension
-     TE-TYPE-EXTERNAL-ADATA        1     Integrity protected authorization
-data
-     reserved                      2     TE-TYPE-PKCROSS-KDC
-     TE-TYPE-PKCROSS-CLIENT        3     PKCROSS cross realm key ticket
-     TE-TYPE-CYBERSAFE-EXT         4     Assigned to CyberSafe Corp
-     reserved                      5     TE-TYPE-DEST-HOST
-
-     alternate authentication type   method-type value
-     reserved values                 0-63
-     ATT-CHALLENGE-RESPONSE          64
-
-     transited encoding type         tr-type value
-     DOMAIN-X500-COMPRESS            1
-     reserved values                 all others
-
-     Label               Value   Meaning or MIT code
-
-     pvno                    5   current Kerberos protocol version number
-
-     message types
-
-     KRB_AS_REQ             10   Request for initial authentication
-     KRB_AS_REP             11   Response to KRB_AS_REQ request
-     KRB_TGS_REQ            12   Request for authentication based on TGT
-     KRB_TGS_REP            13   Response to KRB_TGS_REQ request
-     KRB_AP_REQ             14   application request to server
-     KRB_AP_REP             15   Response to KRB_AP_REQ_MUTUAL
-     KRB_SAFE               20   Safe (checksummed) application message
-     KRB_PRIV               21   Private (encrypted) application message
-     KRB_CRED               22   Private (encrypted) message to forward
-credentials
-     KRB_ERROR              30   Error response
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     name types
-
-     KRB_NT_UNKNOWN        0  Name type not known
-     KRB_NT_PRINCIPAL      1  Just the name of the principal as in DCE, or
-for users
-     KRB_NT_SRV_INST       2  Service and other unique instance (krbtgt)
-     KRB_NT_SRV_HST        3  Service with host name as instance (telnet,
-rcommands)
-     KRB_NT_SRV_XHST       4  Service with host as remaining components
-     KRB_NT_UID            5  Unique ID
-     KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
-
-     error codes
-
-     KDC_ERR_NONE                    0   No error
-     KDC_ERR_NAME_EXP                1   Client's entry in database has
-expired
-     KDC_ERR_SERVICE_EXP             2   Server's entry in database has
-expired
-     KDC_ERR_BAD_PVNO                3   Requested protocol version number
-not supported
-     KDC_ERR_C_OLD_MAST_KVNO         4   Client's key encrypted in old
-master key
-     KDC_ERR_S_OLD_MAST_KVNO         5   Server's key encrypted in old
-master key
-     KDC_ERR_C_PRINCIPAL_UNKNOWN     6   Client not found in Kerberos
-database
-     KDC_ERR_S_PRINCIPAL_UNKNOWN     7   Server not found in Kerberos
-database
-     KDC_ERR_PRINCIPAL_NOT_UNIQUE    8   Multiple principal entries in
-database
-     KDC_ERR_NULL_KEY                9   The client or server has a null key
-     KDC_ERR_CANNOT_POSTDATE        10   Ticket not eligible for postdating
-     KDC_ERR_NEVER_VALID            11   Requested start time is later than
-end time
-     KDC_ERR_POLICY                 12   KDC policy rejects request
-     KDC_ERR_BADOPTION              13   KDC cannot accommodate requested
-option
-     KDC_ERR_ETYPE_NOSUPP           14   KDC has no support for encryption
-type
-     KDC_ERR_SUMTYPE_NOSUPP         15   KDC has no support for checksum
-type
-     KDC_ERR_PADATA_TYPE_NOSUPP     16   KDC has no support for padata type
-     KDC_ERR_TRTYPE_NOSUPP          17   KDC has no support for transited
-type
-     KDC_ERR_CLIENT_REVOKED         18   Clients credentials have been
-revoked
-     KDC_ERR_SERVICE_REVOKED        19   Credentials for server have been
-revoked
-     KDC_ERR_TGT_REVOKED            20   TGT has been revoked
-     KDC_ERR_CLIENT_NOTYET          21   Client not yet valid - try again
-later
-     KDC_ERR_SERVICE_NOTYET         22   Server not yet valid - try again
-later
-     KDC_ERR_KEY_EXPIRED            23   Password has expired - change
-password to reset
-     KDC_ERR_PREAUTH_FAILED         24   Pre-authentication information was
-invalid
-     KDC_ERR_PREAUTH_REQUIRED       25   Additional
-pre-authenticationrequired [40]
-     KDC_ERR_SERVER_NOMATCH         26   Requested server and ticket don't
-match
-     KDC_ERR_MUST_USE_USER2USER     27   Server principal valid for
-user2user only
-     KDC_ERR_PATH_NOT_ACCPETED      28   KDC Policy rejects transited path
-     KDC_ERR_SVC_UNAVAILABLE        29   A service is not available
-     KRB_AP_ERR_BAD_INTEGRITY       31   Integrity check on decrypted field
-failed
-     KRB_AP_ERR_TKT_EXPIRED         32   Ticket expired
-     KRB_AP_ERR_TKT_NYV             33   Ticket not yet valid
-     KRB_AP_ERR_REPEAT              34   Request is a replay
-     KRB_AP_ERR_NOT_US              35   The ticket isn't for us
-     KRB_AP_ERR_BADMATCH            36   Ticket and authenticator don't
-match
-     KRB_AP_ERR_SKEW                37   Clock skew too great
-     KRB_AP_ERR_BADADDR             38   Incorrect net address
-     KRB_AP_ERR_BADVERSION          39   Protocol version mismatch
-     KRB_AP_ERR_MSG_TYPE            40   Invalid msg type
-     KRB_AP_ERR_MODIFIED            41   Message stream modified
-     KRB_AP_ERR_BADORDER            42   Message out of order
-     KRB_AP_ERR_BADKEYVER           44   Specified version of key is not
-available
-     KRB_AP_ERR_NOKEY               45   Service key not available
-     KRB_AP_ERR_MUT_FAIL            46   Mutual authentication failed
-     KRB_AP_ERR_BADDIRECTION        47   Incorrect message direction
-     KRB_AP_ERR_METHOD              48   Alternative authentication method
-required
-     KRB_AP_ERR_BADSEQ              49   Incorrect sequence number in
-message
-     KRB_AP_ERR_INAPP_CKSUM         50   Inappropriate type of checksum in
-message
-     KRB_AP_PATH_NOT_ACCEPTED       51   Policy rejects transited path
-     KRB_ERR_RESPONSE_TOO_BIG       52   Response too big for UDP, retry
-with TCP
-     KRB_ERR_GENERIC                60   Generic error (description in
-e-text)
-     KRB_ERR_FIELD_TOOLONG          61   Field is too long for this
-implementation
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     KDC_ERROR_CLIENT_NOT_TRUSTED            62 (pkinit)
-     KDC_ERROR_KDC_NOT_TRUSTED               63 (pkinit)
-     KDC_ERROR_INVALID_SIG                   64 (pkinit)
-     KDC_ERR_KEY_TOO_WEAK                    65 (pkinit)
-     KDC_ERR_CERTIFICATE_MISMATCH            66 (pkinit)
-     KRB_AP_ERR_NO_TGT                       67 (user-to-user)
-     KDC_ERR_WRONG_REALM                     68 (user-to-user)
-     KRB_AP_ERR_USER_TO_USER_REQUIRED        69 (user-to-user)
-     KDC_ERR_CANT_VERIFY_CERTIFICATE         70 (pkinit)
-     KDC_ERR_INVALID_CERTIFICATE             71 (pkinit)
-     KDC_ERR_REVOKED_CERTIFICATE             72 (pkinit)
-     KDC_ERR_REVOCATION_STATUS_UNKNOWN       73 (pkinit)
-     KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74 (pkinit)
-     KDC_ERR_CLIENT_NAME_MISMATCH            75 (pkinit)
-     KDC_ERR_KDC_NAME_MISMATCH               76 (pkinit)
-
-     9. Interoperability requirements
-
-     Version 5 of the Kerberos protocol supports a myriad of options. Among
-     these are multiple encryption and checksum types, alternative encoding
-     schemes for the transited field, optional mechanisms for
-     pre-authentication, the handling of tickets with no addresses, options
-     for mutual authentication, user to user authentication, support for
-     proxies, forwarding, postdating, and renewing tickets, the format of
-     realm names, and the handling of authorization data.
-
-     In order to ensure the interoperability of realms, it is necessary to
-     define a minimal configuration which must be supported by all
-     implementations. This minimal configuration is subject to change as
-     technology does. For example, if at some later date it is discovered
-     that one of the required encryption or checksum algorithms is not
-     secure, it will be replaced.
-
-     9.1. Specification 2
-
-     This section defines the second specification of these options.
-     Implementations which are configured in this way can be said to
-     support Kerberos Version 5 Specification 2 (5.1). Specification 1
-     (depricated) may be found in RFC1510.
-
-     Transport
-
-     TCP/IP and UDP/IP transport must be supported by KDCs claiming
-     conformance to specification 2. Kerberos clients claiming conformance
-     to specification 2 must support UDP/IP transport for messages with the
-     KDC and should support TCP/IP transport.
-
-     Encryption and checksum methods
-
-     The following encryption and checksum mechanisms must be supported.
-     Implementations may support other mechanisms as well, but the
-     additional mechanisms may only be used when communicating with
-     principals known to also support them: This list is to be determined.
-
-     Encryption: DES-CBC-MD5, one triple des variant (tbd)
-     Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5 (tbd)
-
-     Realm Names
-
-     All implementations must understand hierarchical realms in both the
-     Internet Domain and the X.500 style. When a ticket granting ticket for
-     an unknown realm is requested, the KDC must be able to determine the
-     names of the intermediate realms between the KDCs realm and the
-     requested realm.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     Transited field encoding
-
-     DOMAIN-X500-COMPRESS (described in section 3.3.3.2) must be supported.
-     Alternative encodings may be supported, but they may be used only when
-     that encoding is supported by ALL intermediate realms.
-
-     Pre-authentication methods
-
-     The TGS-REQ method must be supported. The TGS-REQ method is not used
-     on the initial request. The PA-ENC-TIMESTAMP method must be supported
-     by clients but whether it is enabled by default may be determined on a
-     realm by realm basis. If not used in the initial request and the error
-     KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an
-     acceptable method, the client should retry the initial request using
-     the PA-ENC-TIMESTAMP preauthentication method. Servers need not
-     support the PA-ENC-TIMESTAMP method, but if not supported the server
-     should ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a
-     request.
-
-     Mutual authentication
-
-     Mutual authentication (via the KRB_AP_REP message) must be supported.
-
-     Ticket addresses and flags
-
-     All KDC's must pass on tickets that carry no addresses (i.e. if a TGT
-     contains no addresses, the KDC will return derivative tickets), but
-     each realm may set its own policy for issuing such tickets, and each
-     application server will set its own policy with respect to accepting
-     them.
-
-     Proxies and forwarded tickets must be supported. Individual realms and
-     application servers can set their own policy on when such tickets will
-     be accepted.
-
-     All implementations must recognize renewable and postdated tickets,
-     but need not actually implement them. If these options are not
-     supported, the starttime and endtime in the ticket shall specify a
-     ticket's entire useful life. When a postdated ticket is decoded by a
-     server, all implementations shall make the presence of the postdated
-     flag visible to the calling server.
-
-     User-to-user authentication
-
-     Support for user to user authentication (via the ENC-TKT-IN-SKEY KDC
-     option) must be provided by implementations, but individual realms may
-     decide as a matter of policy to reject such requests on a
-     per-principal or realm-wide basis.
-
-     Authorization data
-
-     Implementations must pass all authorization data subfields from
-     ticket-granting tickets to any derivative tickets unless directed to
-     suppress a subfield as part of the definition of that registered
-     subfield type (it is never incorrect to pass on a subfield, and no
-     registered subfield types presently specify suppression at the KDC).
-
-     Implementations must make the contents of any authorization data
-     subfields available to the server when a ticket is used.
-     Implementations are not required to allow clients to specify the
-     contents of the authorization data fields.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     Constant ranges
-
-     All protocol constants are constrained to 32 bit (signed) values
-     unless further constrained by the protocol definition. This limit is
-     provided to allow implementations to make assumptions about the
-     maximum values that will be received for these constants.
-     Implementation receiving values outside this range may reject the
-     request, but they must recover cleanly.
-
-     9.2. Recommended KDC values
-
-     Following is a list of recommended values for a KDC implementation,
-     based on the list of suggested configuration constants (see section
-     4.4).
-
-     minimum lifetime              5 minutes
-     maximum renewable lifetime    1 week
-     maximum ticket lifetime       1 day
-     empty addresses               only when suitable  restrictions  appear
-                                   in authorization data
-     proxiable, etc.               Allowed.
-
-     10. REFERENCES
-
-     [NT94]    B. Clifford Neuman and Theodore Y. Ts'o, "An  Authenti-
-               cation  Service for Computer Networks," IEEE Communica-
-               tions Magazine, Vol. 32(9), pp. 33-38 (September 1994).
-
-     [MNSS87]  S. P. Miller, B. C. Neuman, J. I. Schiller, and  J.  H.
-               Saltzer,  Section  E.2.1:  Kerberos  Authentication and
-               Authorization System, M.I.T. Project Athena, Cambridge,
-               Massachusetts (December 21, 1987).
-
-     [SNS88]   J. G. Steiner, B. C. Neuman, and J. I. Schiller,  "Ker-
-               beros:  An Authentication Service for Open Network Sys-
-               tems," pp. 191-202 in  Usenix  Conference  Proceedings,
-               Dallas, Texas (February, 1988).
-
-     [NS78]    Roger M.  Needham  and  Michael  D.  Schroeder,  "Using
-               Encryption for Authentication in Large Networks of Com-
-               puters,"  Communications  of  the  ACM,  Vol.   21(12),
-               pp. 993-999 (December, 1978).
-
-     [DS81]    Dorothy E. Denning and  Giovanni  Maria  Sacco,  "Time-
-               stamps  in  Key Distribution Protocols," Communications
-               of the ACM, Vol. 24(8), pp. 533-536 (August 1981).
-
-     [KNT92]   John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o,
-               "The Evolution of the Kerberos Authentication Service,"
-               in an IEEE Computer Society Text soon to  be  published
-               (June 1992).
-
-     [Neu93]   B.  Clifford  Neuman,  "Proxy-Based  Authorization  and
-               Accounting  for Distributed Systems," in Proceedings of
-               the 13th International Conference on  Distributed  Com-
-               puting Systems, Pittsburgh, PA (May, 1993).
-
-     [DS90]    Don Davis and Ralph Swick,  "Workstation  Services  and
-               Kerberos  Authentication  at Project Athena," Technical
-               Memorandum TM-424,  MIT Laboratory for Computer Science
-               (February 1990).
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     [LGDSR87] P. J. Levine, M. R. Gretzinger, J. M. Diaz, W. E.  Som-
-               merfeld,  and  K. Raeburn, Section E.1: Service Manage-
-               ment System, M.I.T.  Project  Athena,  Cambridge,  Mas-
-               sachusetts (1987).
-
-     [X509-88] CCITT, Recommendation X.509: The Directory  Authentica-
-               tion Framework, December 1988.
-
-     [Pat92].  J. Pato, Using  Pre-Authentication  to  Avoid  Password
-               Guessing  Attacks, Open Software Foundation DCE Request
-               for Comments 26 (December 1992).
-
-     [DES77]   National Bureau of Standards, U.S. Department  of  Com-
-               merce,  "Data Encryption Standard," Federal Information
-               Processing Standards Publication  46,   Washington,  DC
-               (1977).
-
-     [DESM80]  National Bureau of Standards, U.S. Department  of  Com-
-               merce,  "DES  Modes  of Operation," Federal Information
-               Processing Standards Publication 81,   Springfield,  VA
-               (December 1980).
-
-     [SG92]    Stuart G. Stubblebine and Virgil D. Gligor, "On Message
-               Integrity  in  Cryptographic Protocols," in Proceedings
-               of the IEEE  Symposium  on  Research  in  Security  and
-               Privacy, Oakland, California (May 1992).
-
-     [IS3309]  International Organization  for  Standardization,  "ISO
-               Information  Processing  Systems - Data Communication -
-               High-Level Data Link Control Procedure -  Frame  Struc-
-               ture," IS 3309 (October 1984).  3rd Edition.
-
-     [MD4-92]  R. Rivest, "The  MD4  Message  Digest  Algorithm,"  RFC
-               1320,   MIT  Laboratory  for  Computer  Science  (April
-               1992).
-
-     [MD5-92]  R. Rivest, "The  MD5  Message  Digest  Algorithm,"  RFC
-               1321,   MIT  Laboratory  for  Computer  Science  (April
-               1992).
-
-     [KBC96]   H. Krawczyk, M. Bellare, and R. Canetti, "HMAC:  Keyed-
-               Hashing  for  Message  Authentication,"  Working  Draft
-               draft-ietf-ipsec-hmac-md5-01.txt,   (August 1996).
-
-     [Horowitz96] Horowitz, M., "Key Derivation for Authentication,
-               Integrity, and Privacy",
-draft-horowitz-key-derivation-02.txt,
-               August 1998.
-
-     [HorowitzB96] Horowitz, M., "Key Derivation for Kerberos V5", draft-
-               horowitz-kerb-key-derivation-01.txt, September 1998.
-
-     [Krawczyk96] Krawczyk, H., Bellare, and M., Canetti, R., "HMAC:
-               Keyed-Hashing for Message Authentication",
-draft-ietf-ipsec-hmac-
-               md5-01.txt, August, 1996.
-
-     A. Pseudo-code for protocol processing
-
-     This appendix provides pseudo-code describing how the messages are to
-     be constructed and interpreted by clients and servers.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     A.1. KRB_AS_REQ generation
-
-             request.pvno := protocol version; /* pvno = 5 */
-             request.msg-type := message type; /* type = KRB_AS_REQ */
-
-             if(pa_enc_timestamp_required) then
-                     request.padata.padata-type = PA-ENC-TIMESTAMP;
-                     get system_time;
-                     padata-body.patimestamp,pausec = system_time;
-                     encrypt padata-body into request.padata.padata-value
-                             using client.key; /* derived from password */
-             endif
-
-             body.kdc-options := users's preferences;
-             body.cname := user's name;
-             body.realm := user's realm;
-             body.sname := service's name; /* usually "krbtgt",
-"localrealm" */
-             if (body.kdc-options.POSTDATED is set) then
-                     body.from := requested starting time;
-             else
-                     omit body.from;
-             endif
-             body.till := requested end time;
-             if (body.kdc-options.RENEWABLE is set) then
-                     body.rtime := requested final renewal time;
-             endif
-             body.nonce := random_nonce();
-             body.etype := requested etypes;
-             if (user supplied addresses) then
-                     body.addresses := user's addresses;
-             else
-                     omit body.addresses;
-             endif
-             omit body.enc-authorization-data;
-             request.req-body := body;
-
-             kerberos := lookup(name of local kerberos server (or servers));
-             send(packet,kerberos);
-
-             wait(for response);
-             if (timed_out) then
-                     retry or use alternate server;
-             endif
-
-     A.2. KRB_AS_REQ verification and KRB_AS_REP generation
-
-             decode message into req;
-
-             client := lookup(req.cname,req.realm);
-             server := lookup(req.sname,req.realm);
-
-             get system_time;
-             kdc_time := system_time.seconds;
-
-             if (!client) then
-                     /* no client in Database */
-                     error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
-             endif
-             if (!server) then
-                     /* no server in Database */
-                     error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
-             endif
-
-             if(client.pa_enc_timestamp_required and
-                pa_enc_timestamp not present) then
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-                     error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
-             endif
-
-             if(pa_enc_timestamp present) then
-                     decrypt req.padata-value into decrypted_enc_timestamp
-                             using client.key;
-                             using auth_hdr.authenticator.subkey;
-                     if (decrypt_error()) then
-                             error_out(KRB_AP_ERR_BAD_INTEGRITY);
-                     if(decrypted_enc_timestamp is not within allowable
-skew) then
-                             error_out(KDC_ERR_PREAUTH_FAILED);
-                     endif
-                     if(decrypted_enc_timestamp and usec is replay)
-                             error_out(KDC_ERR_PREAUTH_FAILED);
-                     endif
-                     add decrypted_enc_timestamp and usec to replay cache;
-             endif
-
-             use_etype := first supported etype in req.etypes;
-
-             if (no support for req.etypes) then
-                     error_out(KDC_ERR_ETYPE_NOSUPP);
-             endif
-
-             new_tkt.vno := ticket version; /* = 5 */
-             new_tkt.sname := req.sname;
-             new_tkt.srealm := req.srealm;
-             reset all flags in new_tkt.flags;
-
-             /* It should be noted that local policy may affect the  */
-             /* processing of any of these flags.  For example, some */
-             /* realms may refuse to issue renewable tickets         */
-
-             if (req.kdc-options.FORWARDABLE is set) then
-                     set new_tkt.flags.FORWARDABLE;
-             endif
-             if (req.kdc-options.PROXIABLE is set) then
-                     set new_tkt.flags.PROXIABLE;
-             endif
-
-             if (req.kdc-options.ALLOW-POSTDATE is set) then
-                     set new_tkt.flags.MAY-POSTDATE;
-             endif
-             if ((req.kdc-options.RENEW is set) or
-                 (req.kdc-options.VALIDATE is set) or
-                 (req.kdc-options.PROXY is set) or
-                 (req.kdc-options.FORWARDED is set) or
-                 (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
-                     error_out(KDC_ERR_BADOPTION);
-             endif
-
-             new_tkt.session := random_session_key();
-             new_tkt.cname := req.cname;
-             new_tkt.crealm := req.crealm;
-             new_tkt.transited := empty_transited_field();
-
-             new_tkt.authtime := kdc_time;
-
-             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;
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-             else
-                omit new_tkt.starttime; /* treated as authtime when omitted
-*/
-             endif
-             if (req.till = 0) then
-                     till := infinity;
-             else
-                     till := req.till;
-             endif
-
-             new_tkt.endtime := min(till,
-                                   new_tkt.starttime+client.max_life,
-                                   new_tkt.starttime+server.max_life,
-                                   new_tkt.starttime+max_life_for_realm);
-
-             if ((req.kdc-options.RENEWABLE-OK is set) and
-                 (new_tkt.endtime < req.till)) then
-                     /* we set the RENEWABLE option for later processing */
-                     set req.kdc-options.RENEWABLE;
-                     req.rtime := req.till;
-             endif
-
-             if (req.rtime = 0) then
-                     rtime := infinity;
-             else
-                     rtime := req.rtime;
-             endif
-
-             if (req.kdc-options.RENEWABLE is set) then
-                     set new_tkt.flags.RENEWABLE;
-                     new_tkt.renew-till := min(rtime,
-
-new_tkt.starttime+client.max_rlife,
-
-new_tkt.starttime+server.max_rlife,
-
-new_tkt.starttime+max_rlife_for_realm);
-             else
-                     omit new_tkt.renew-till; /* only present if RENEWABLE
-*/
-             endif
-
-             if (req.addresses) then
-                     new_tkt.caddr := req.addresses;
-             else
-                     omit new_tkt.caddr;
-             endif
-
-             new_tkt.authorization_data := empty_authorization_data();
-
-             encode to-be-encrypted part of ticket into OCTET STRING;
-             new_tkt.enc-part := encrypt OCTET STRING
-                     using etype_for_key(server.key), server.key,
-server.p_kvno;
-
-             /* Start processing the response */
-
-             resp.pvno := 5;
-             resp.msg-type := KRB_AS_REP;
-             resp.cname := req.cname;
-             resp.crealm := req.realm;
-             resp.ticket := new_tkt;
-
-             resp.key := new_tkt.session;
-             resp.last-req := fetch_last_request_info(client);
-             resp.nonce := req.nonce;
-             resp.key-expiration := client.expiration;
-             resp.flags := new_tkt.flags;
-
-             resp.authtime := new_tkt.authtime;
-             resp.starttime := new_tkt.starttime;
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-             resp.endtime := new_tkt.endtime;
-
-             if (new_tkt.flags.RENEWABLE) then
-                     resp.renew-till := new_tkt.renew-till;
-             endif
-
-             resp.realm := new_tkt.realm;
-             resp.sname := new_tkt.sname;
-
-             resp.caddr := new_tkt.caddr;
-
-             encode body of reply into OCTET STRING;
-
-             resp.enc-part := encrypt OCTET STRING
-                              using use_etype, client.key, client.p_kvno;
-             send(resp);
-
-     A.3. KRB_AS_REP verification
-
-             decode response into resp;
-
-             if (resp.msg-type = KRB_ERROR) then
-                     if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP))
-then
-                             set pa_enc_timestamp_required;
-                             goto KRB_AS_REQ;
-                     endif
-                     process_error(resp);
-                     return;
-             endif
-
-             /* On error, discard the response, and zero the session key */
-             /* from the response immediately */
-
-             key = get_decryption_key(resp.enc-part.kvno,
-resp.enc-part.etype,
-                                      resp.padata);
-             unencrypted part of resp := decode of decrypt of resp.enc-part
-                                     using resp.enc-part.etype and key;
-             zero(key);
-
-             if (common_as_rep_tgs_rep_checks fail) then
-                     destroy resp.key;
-                     return error;
-             endif
-
-             if near(resp.princ_exp) then
-                     print(warning message);
-             endif
-             save_for_later(ticket,session,client,server,times,flags);
-
-     A.4. KRB_AS_REP and KRB_TGS_REP common checks
-
-             if (decryption_error() or
-                 (req.cname != resp.cname) or
-                 (req.realm != resp.crealm) or
-                 (req.sname != resp.sname) or
-                 (req.realm != resp.realm) or
-                 (req.nonce != resp.nonce) or
-                 (req.addresses != resp.caddr)) then
-                     destroy resp.key;
-                     return KRB_AP_ERR_MODIFIED;
-             endif
-
-             /* make sure no flags are set that shouldn't be, and that all
-that */
-             /* should be are set
-*/
-             if (!check_flags_for_compatability(req.kdc-options,resp.flags))
-then
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-                     destroy resp.key;
-                     return KRB_AP_ERR_MODIFIED;
-             endif
-
-             if ((req.from = 0) and
-                 (resp.starttime is not within allowable skew)) then
-                     destroy resp.key;
-                     return KRB_AP_ERR_SKEW;
-             endif
-             if ((req.from != 0) and (req.from != resp.starttime)) then
-                     destroy resp.key;
-                     return KRB_AP_ERR_MODIFIED;
-             endif
-             if ((req.till != 0) and (resp.endtime > req.till)) then
-                     destroy resp.key;
-                     return KRB_AP_ERR_MODIFIED;
-             endif
-
-             if ((req.kdc-options.RENEWABLE is set) and
-                 (req.rtime != 0) and (resp.renew-till > req.rtime)) then
-                     destroy resp.key;
-                     return KRB_AP_ERR_MODIFIED;
-             endif
-             if ((req.kdc-options.RENEWABLE-OK is set) and
-                 (resp.flags.RENEWABLE) and
-                 (req.till != 0) and
-                 (resp.renew-till > req.till)) then
-                     destroy resp.key;
-                     return KRB_AP_ERR_MODIFIED;
-             endif
-
-     A.5. KRB_TGS_REQ generation
-
-             /* Note that make_application_request might have to recursivly
-*/
-             /* call this routine to get the appropriate ticket-granting
-ticket */
-
-             request.pvno := protocol version; /* pvno = 5 */
-             request.msg-type := message type; /* type = KRB_TGS_REQ */
-
-             body.kdc-options := users's preferences;
-             /* If the TGT is not for the realm of the end-server  */
-             /* then the sname will be for a TGT for the end-realm */
-             /* and the realm of the requested ticket (body.realm) */
-             /* will be that of the TGS to which the TGT we are    */
-             /* sending applies                                    */
-             body.sname := service's name;
-             body.realm := service's realm;
-
-             if (body.kdc-options.POSTDATED is set) then
-                     body.from := requested starting time;
-             else
-                     omit body.from;
-             endif
-             body.till := requested end time;
-             if (body.kdc-options.RENEWABLE is set) then
-                     body.rtime := requested final renewal time;
-             endif
-             body.nonce := random_nonce();
-             body.etype := requested etypes;
-             if (user supplied addresses) then
-                     body.addresses := user's addresses;
-             else
-                     omit body.addresses;
-             endif
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-             body.enc-authorization-data := user-supplied data;
-             if (body.kdc-options.ENC-TKT-IN-SKEY) then
-                     body.additional-tickets_ticket := second TGT;
-             endif
-
-             request.req-body := body;
-             check := generate_checksum (req.body,checksumtype);
-
-             request.padata[0].padata-type := PA-TGS-REQ;
-             request.padata[0].padata-value := create a KRB_AP_REQ using
-                                           the TGT and checksum
-
-             /* add in any other padata as required/supplied */
-
-             kerberos := lookup(name of local kerberose server (or
-servers));
-             send(packet,kerberos);
-
-             wait(for response);
-             if (timed_out) then
-                     retry or use alternate server;
-             endif
-
-     A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation
-
-             /* note that reading the application request requires first
-             determining the server for which a ticket was issued, and
-choosing the
-             correct key for decryption.  The name of the server appears in
-the
-             plaintext part of the ticket. */
-
-             if (no KRB_AP_REQ in req.padata) then
-                     error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
-             endif
-             verify KRB_AP_REQ in req.padata;
-
-             /* Note that the realm in which the Kerberos server is
-operating is
-             determined by the instance from the ticket-granting ticket.
-The realm
-             in the ticket-granting ticket is the realm under which the
-ticket
-             granting ticket was issued.  It is possible for a single
-Kerberos
-             server to support more than one realm. */
-
-             auth_hdr := KRB_AP_REQ;
-             tgt := auth_hdr.ticket;
-
-             if (tgt.sname is not a TGT for local realm and is not
-req.sname) then
-                     error_out(KRB_AP_ERR_NOT_US);
-
-             realm := realm_tgt_is_for(tgt);
-
-             decode remainder of request;
-
-             if (auth_hdr.authenticator.cksum is missing) then
-                     error_out(KRB_AP_ERR_INAPP_CKSUM);
-             endif
-
-             if (auth_hdr.authenticator.cksum type is not supported) then
-                     error_out(KDC_ERR_SUMTYPE_NOSUPP);
-             endif
-             if (auth_hdr.authenticator.cksum is not both collision-proof
-and keyed) then
-                     error_out(KRB_AP_ERR_INAPP_CKSUM);
-             endif
-
-             set computed_checksum := checksum(req);
-             if (computed_checksum != auth_hdr.authenticatory.cksum) then
-                     error_out(KRB_AP_ERR_MODIFIED);
-             endif
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-
-             server := lookup(req.sname,realm);
-
-             if (!server) then
-                     if (is_foreign_tgt_name(req.sname)) then
-                             server := best_intermediate_tgs(req.sname);
-                     else
-                             /* no server in Database */
-                             error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
-                     endif
-             endif
-
-             session := generate_random_session_key();
-
-             use_etype := first supported etype in req.etypes;
-
-             if (no support for req.etypes) then
-                     error_out(KDC_ERR_ETYPE_NOSUPP);
-             endif
-
-             new_tkt.vno := ticket version; /* = 5 */
-             new_tkt.sname := req.sname;
-             new_tkt.srealm := realm;
-             reset all flags in new_tkt.flags;
-
-             /* It should be noted that local policy may affect the  */
-             /* processing of any of these flags.  For example, some */
-             /* realms may refuse to issue renewable tickets         */
-
-             new_tkt.caddr := tgt.caddr;
-             resp.caddr := NULL; /* We only include this if they change */
-             if (req.kdc-options.FORWARDABLE is set) then
-                     if (tgt.flags.FORWARDABLE is reset) then
-                             error_out(KDC_ERR_BADOPTION);
-                     endif
-                     set new_tkt.flags.FORWARDABLE;
-             endif
-             if (req.kdc-options.FORWARDED is set) then
-                     if (tgt.flags.FORWARDABLE is reset) then
-                             error_out(KDC_ERR_BADOPTION);
-                     endif
-                     set new_tkt.flags.FORWARDED;
-                     new_tkt.caddr := req.addresses;
-                     resp.caddr := req.addresses;
-             endif
-             if (tgt.flags.FORWARDED is set) then
-                     set new_tkt.flags.FORWARDED;
-             endif
-
-             if (req.kdc-options.PROXIABLE is set) then
-                     if (tgt.flags.PROXIABLE is reset)
-                             error_out(KDC_ERR_BADOPTION);
-                     endif
-                     set new_tkt.flags.PROXIABLE;
-             endif
-             if (req.kdc-options.PROXY is set) then
-                     if (tgt.flags.PROXIABLE is reset) then
-                             error_out(KDC_ERR_BADOPTION);
-                     endif
-                     set new_tkt.flags.PROXY;
-                     new_tkt.caddr := req.addresses;
-                     resp.caddr := req.addresses;
-             endif
-
-             if (req.kdc-options.ALLOW-POSTDATE is set) then
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-                     if (tgt.flags.MAY-POSTDATE is reset)
-                             error_out(KDC_ERR_BADOPTION);
-                     endif
-                     set new_tkt.flags.MAY-POSTDATE;
-             endif
-             if (req.kdc-options.POSTDATED is set) then
-                     if (tgt.flags.MAY-POSTDATE is reset) then
-                             error_out(KDC_ERR_BADOPTION);
-                     endif
-                     set new_tkt.flags.POSTDATED;
-                     set new_tkt.flags.INVALID;
-                     if (against_postdate_policy(req.from)) then
-                             error_out(KDC_ERR_POLICY);
-                     endif
-                     new_tkt.starttime := req.from;
-             endif
-
-             if (req.kdc-options.VALIDATE is set) then
-                     if (tgt.flags.INVALID is reset) then
-                             error_out(KDC_ERR_POLICY);
-                     endif
-                     if (tgt.starttime > kdc_time) then
-                             error_out(KRB_AP_ERR_NYV);
-                     endif
-                     if (check_hot_list(tgt)) then
-                             error_out(KRB_AP_ERR_REPEAT);
-                     endif
-                     tkt := tgt;
-                     reset new_tkt.flags.INVALID;
-             endif
-
-             if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
-                                  and those already processed) is set) then
-                     error_out(KDC_ERR_BADOPTION);
-             endif
-
-             new_tkt.authtime := tgt.authtime;
-
-             if (req.kdc-options.RENEW is set) then
-               /* Note that if the endtime has already passed, the ticket
-would  */
-               /* have been rejected in the initial authentication stage, so
-*/
-               /* there is no need to check again here
-*/
-                     if (tgt.flags.RENEWABLE is reset) then
-                             error_out(KDC_ERR_BADOPTION);
-                     endif
-                     if (tgt.renew-till < kdc_time) then
-                             error_out(KRB_AP_ERR_TKT_EXPIRED);
-                     endif
-                     tkt := tgt;
-                     new_tkt.starttime := kdc_time;
-                     old_life := tgt.endttime - tgt.starttime;
-                     new_tkt.endtime := min(tgt.renew-till,
-                                            new_tkt.starttime + old_life);
-             else
-                     new_tkt.starttime := kdc_time;
-                     if (req.till = 0) then
-                             till := infinity;
-                     else
-                             till := req.till;
-                     endif
-                     new_tkt.endtime := min(till,
-
-new_tkt.starttime+client.max_life,
-
-new_tkt.starttime+server.max_life,
-
-new_tkt.starttime+max_life_for_realm,
-                                            tgt.endtime);
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-
-                     if ((req.kdc-options.RENEWABLE-OK is set) and
-                         (new_tkt.endtime < req.till) and
-                         (tgt.flags.RENEWABLE is set) then
-                             /* we set the RENEWABLE option for later
-processing */
-                             set req.kdc-options.RENEWABLE;
-                             req.rtime := min(req.till, tgt.renew-till);
-                     endif
-             endif
-
-             if (req.rtime = 0) then
-                     rtime := infinity;
-             else
-                     rtime := req.rtime;
-             endif
-
-             if ((req.kdc-options.RENEWABLE is set) and
-                 (tgt.flags.RENEWABLE is set)) then
-                     set new_tkt.flags.RENEWABLE;
-                     new_tkt.renew-till := min(rtime,
-
-new_tkt.starttime+client.max_rlife,
-
-new_tkt.starttime+server.max_rlife,
-
-new_tkt.starttime+max_rlife_for_realm,
-                                               tgt.renew-till);
-             else
-                     new_tkt.renew-till := OMIT; /* leave the renew-till
-field out */
-             endif
-             if (req.enc-authorization-data is present) then
-                     decrypt req.enc-authorization-data into
-decrypted_authorization_data
-                             using auth_hdr.authenticator.subkey;
-                     if (decrypt_error()) then
-                             error_out(KRB_AP_ERR_BAD_INTEGRITY);
-                     endif
-             endif
-             new_tkt.authorization_data :=
-req.auth_hdr.ticket.authorization_data +
-                                      decrypted_authorization_data;
-
-             new_tkt.key := session;
-             new_tkt.crealm := tgt.crealm;
-             new_tkt.cname := req.auth_hdr.ticket.cname;
-
-             if (realm_tgt_is_for(tgt) := tgt.realm) then
-                     /* tgt issued by local realm */
-                     new_tkt.transited := tgt.transited;
-             else
-                     /* was issued for this realm by some other realm */
-                     if (tgt.transited.tr-type not supported) then
-                             error_out(KDC_ERR_TRTYPE_NOSUPP);
-                     endif
-                     new_tkt.transited := compress_transited(tgt.transited +
-tgt.realm)
-                     /* Don't check tranited field if TGT for foreign realm,
-                      * or requested not to check */
-                     if (is_not_foreign_tgt_name(new_tkt.server)
-                        && req.kdc-options.DISABLE-TRANSITED-CHECK not set)
-then
-                             /* Check it, so end-server does not have to
-                              * but don't fail, end-server may still accept
-it */
-                             if (check_transited_field(new_tkt.transited) ==
-OK)
-                                   set
-new_tkt.flags.TRANSITED-POLICY-CHECKED;
-                             endif
-                     endif
-             endif
-
-             encode encrypted part of new_tkt into OCTET STRING;
-             if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
-                     if (server not specified) then
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-                             server = req.second_ticket.client;
-                     endif
-                     if ((req.second_ticket is not a TGT) or
-                         (req.second_ticket.client != server)) then
-                             error_out(KDC_ERR_POLICY);
-                     endif
-
-                     new_tkt.enc-part := encrypt OCTET STRING using
-                             using etype_for_key(second-ticket.key),
-second-ticket.key;
-             else
-                     new_tkt.enc-part := encrypt OCTET STRING
-                             using etype_for_key(server.key), server.key,
-server.p_kvno;
-             endif
-
-             resp.pvno := 5;
-             resp.msg-type := KRB_TGS_REP;
-             resp.crealm := tgt.crealm;
-             resp.cname := tgt.cname;
-             resp.ticket := new_tkt;
-
-             resp.key := session;
-             resp.nonce := req.nonce;
-             resp.last-req := fetch_last_request_info(client);
-             resp.flags := new_tkt.flags;
-
-             resp.authtime := new_tkt.authtime;
-             resp.starttime := new_tkt.starttime;
-             resp.endtime := new_tkt.endtime;
-
-             omit resp.key-expiration;
-
-             resp.sname := new_tkt.sname;
-             resp.realm := new_tkt.realm;
-
-             if (new_tkt.flags.RENEWABLE) then
-                     resp.renew-till := new_tkt.renew-till;
-             endif
-
-             encode body of reply into OCTET STRING;
-
-             if (req.padata.authenticator.subkey)
-                     resp.enc-part := encrypt OCTET STRING using use_etype,
-                             req.padata.authenticator.subkey;
-             else resp.enc-part := encrypt OCTET STRING using use_etype,
-tgt.key;
-
-             send(resp);
-
-     A.7. KRB_TGS_REP verification
-
-             decode response into resp;
-
-             if (resp.msg-type = KRB_ERROR) then
-                     process_error(resp);
-                     return;
-             endif
-
-             /* On error, discard the response, and zero the session key
-from
-             the response immediately */
-
-             if (req.padata.authenticator.subkey)
-                     unencrypted part of resp := decode of decrypt of
-resp.enc-part
-                             using resp.enc-part.etype and subkey;
-             else unencrypted part of resp := decode of decrypt of
-resp.enc-part
-                                     using resp.enc-part.etype and tgt's
-session key;
-             if (common_as_rep_tgs_rep_checks fail) then
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-                     destroy resp.key;
-                     return error;
-             endif
-
-             check authorization_data as necessary;
-             save_for_later(ticket,session,client,server,times,flags);
-
-     A.8. Authenticator generation
-
-             body.authenticator-vno := authenticator vno; /* = 5 */
-             body.cname, body.crealm := client name;
-             if (supplying checksum) then
-                     body.cksum := checksum;
-             endif
-             get system_time;
-             body.ctime, body.cusec := system_time;
-             if (selecting sub-session key) then
-                     select sub-session key;
-                     body.subkey := sub-session key;
-             endif
-             if (using sequence numbers) then
-                     select initial sequence number;
-                     body.seq-number := initial sequence;
-             endif
-
-     A.9. KRB_AP_REQ generation
-
-             obtain ticket and session_key from cache;
-
-             packet.pvno := protocol version; /* 5 */
-             packet.msg-type := message type; /* KRB_AP_REQ */
-
-             if (desired(MUTUAL_AUTHENTICATION)) then
-                     set packet.ap-options.MUTUAL-REQUIRED;
-             else
-                     reset packet.ap-options.MUTUAL-REQUIRED;
-             endif
-             if (using session key for ticket) then
-                     set packet.ap-options.USE-SESSION-KEY;
-             else
-                     reset packet.ap-options.USE-SESSION-KEY;
-             endif
-             packet.ticket := ticket; /* ticket */
-             generate authenticator;
-             encode authenticator into OCTET STRING;
-             encrypt OCTET STRING into packet.authenticator using
-session_key;
-
-     A.10. KRB_AP_REQ verification
-
-             receive packet;
-             if (packet.pvno != 5) then
-                     either process using other protocol spec
-                     or error_out(KRB_AP_ERR_BADVERSION);
-             endif
-             if (packet.msg-type != KRB_AP_REQ) then
-                     error_out(KRB_AP_ERR_MSG_TYPE);
-             endif
-             if (packet.ticket.tkt_vno != 5) then
-                     either process using other protocol spec
-                     or error_out(KRB_AP_ERR_BADVERSION);
-             endif
-             if (packet.ap_options.USE-SESSION-KEY is set) then
-                     retrieve session key from ticket-granting ticket for
-                      packet.ticket.{sname,srealm,enc-part.etype};
-             else
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-                     retrieve service key for
-
-packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
-             endif
-             if (no_key_available) then
-                     if (cannot_find_specified_skvno) then
-                             error_out(KRB_AP_ERR_BADKEYVER);
-                     else
-                             error_out(KRB_AP_ERR_NOKEY);
-                     endif
-             endif
-             decrypt packet.ticket.enc-part into decr_ticket using retrieved
-key;
-             if (decryption_error()) then
-                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
-             endif
-             decrypt packet.authenticator into decr_authenticator
-                     using decr_ticket.key;
-             if (decryption_error()) then
-                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
-             endif
-             if (decr_authenticator.{cname,crealm} !=
-                 decr_ticket.{cname,crealm}) then
-                     error_out(KRB_AP_ERR_BADMATCH);
-             endif
-             if (decr_ticket.caddr is present) then
-                     if (sender_address(packet) is not in decr_ticket.caddr)
-then
-                             error_out(KRB_AP_ERR_BADADDR);
-                     endif
-             elseif (application requires addresses) then
-                     error_out(KRB_AP_ERR_BADADDR);
-             endif
-             if (not in_clock_skew(decr_authenticator.ctime,
-                                   decr_authenticator.cusec)) then
-                     error_out(KRB_AP_ERR_SKEW);
-             endif
-             if (repeated(decr_authenticator.{ctime,cusec,cname,crealm}))
-then
-                     error_out(KRB_AP_ERR_REPEAT);
-             endif
-             save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
-             get system_time;
-             if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
-                 (decr_ticket.flags.INVALID is set)) then
-                     /* it hasn't yet become valid */
-                     error_out(KRB_AP_ERR_TKT_NYV);
-             endif
-             if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
-                     error_out(KRB_AP_ERR_TKT_EXPIRED);
-             endif
-             if (decr_ticket.transited) then
-                 /* caller may ignore the TRANSITED-POLICY-CHECKED and do
-                  * check anyway */
-                 if (decr_ticket.flags.TRANSITED-POLICY-CHECKED not set)
-then
-                      if (check_transited_field(decr_ticket.transited) then
-                           error_out(KDC_AP_PATH_NOT_ACCPETED);
-                      endif
-                 endif
-             endif
-             /* caller must check decr_ticket.flags for any pertinent
-details */
-             return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
-
-     A.11. KRB_AP_REP generation
-
-             packet.pvno := protocol version; /* 5 */
-             packet.msg-type := message type; /* KRB_AP_REP */
-
-             body.ctime := packet.ctime;
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-             body.cusec := packet.cusec;
-             if (selecting sub-session key) then
-                     select sub-session key;
-                     body.subkey := sub-session key;
-             endif
-             if (using sequence numbers) then
-                     select initial sequence number;
-                     body.seq-number := initial sequence;
-             endif
-
-             encode body into OCTET STRING;
-
-             select encryption type;
-             encrypt OCTET STRING into packet.enc-part;
-
-     A.12. KRB_AP_REP verification
-
-             receive packet;
-             if (packet.pvno != 5) then
-                     either process using other protocol spec
-                     or error_out(KRB_AP_ERR_BADVERSION);
-             endif
-             if (packet.msg-type != KRB_AP_REP) then
-                     error_out(KRB_AP_ERR_MSG_TYPE);
-             endif
-             cleartext := decrypt(packet.enc-part) using ticket's session
-key;
-             if (decryption_error()) then
-                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
-             endif
-             if (cleartext.ctime != authenticator.ctime) then
-                     error_out(KRB_AP_ERR_MUT_FAIL);
-             endif
-             if (cleartext.cusec != authenticator.cusec) then
-                     error_out(KRB_AP_ERR_MUT_FAIL);
-             endif
-             if (cleartext.subkey is present) then
-                     save cleartext.subkey for future use;
-             endif
-             if (cleartext.seq-number is present) then
-                     save cleartext.seq-number for future verifications;
-             endif
-             return(AUTHENTICATION_SUCCEEDED);
-
-     A.13. KRB_SAFE generation
-
-             collect user data in buffer;
-
-             /* assemble packet: */
-             packet.pvno := protocol version; /* 5 */
-             packet.msg-type := message type; /* KRB_SAFE */
-
-             body.user-data := buffer; /* DATA */
-             if (using timestamp) then
-                     get system_time;
-                     body.timestamp, body.usec := system_time;
-             endif
-             if (using sequence numbers) then
-                     body.seq-number := sequence number;
-             endif
-             body.s-address := sender host addresses;
-             if (only one recipient) then
-                     body.r-address := recipient host address;
-             endif
-             checksum.cksumtype := checksum type;
-             compute checksum over body;
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-             checksum.checksum := checksum value; /* checksum.checksum */
-             packet.cksum := checksum;
-             packet.safe-body := body;
-
-     A.14. KRB_SAFE verification
-
-             receive packet;
-             if (packet.pvno != 5) then
-                     either process using other protocol spec
-                     or error_out(KRB_AP_ERR_BADVERSION);
-             endif
-             if (packet.msg-type != KRB_SAFE) then
-                     error_out(KRB_AP_ERR_MSG_TYPE);
-             endif
-             if (packet.checksum.cksumtype is not both collision-proof and
-keyed) then
-                     error_out(KRB_AP_ERR_INAPP_CKSUM);
-             endif
-             if (safe_priv_common_checks_ok(packet)) then
-                     set computed_checksum := checksum(packet.body);
-                     if (computed_checksum != packet.checksum) then
-                             error_out(KRB_AP_ERR_MODIFIED);
-                     endif
-                     return (packet, PACKET_IS_GENUINE);
-             else
-                     return common_checks_error;
-             endif
-
-     A.15. KRB_SAFE and KRB_PRIV common checks
-
-             if (packet.s-address != O/S_sender(packet)) then
-                     /* O/S report of sender not who claims to have sent it
-*/
-                     error_out(KRB_AP_ERR_BADADDR);
-             endif
-             if ((packet.r-address is present) and
-                 (packet.r-address != local_host_address)) then
-                     /* was not sent to proper place */
-                     error_out(KRB_AP_ERR_BADADDR);
-             endif
-             if (((packet.timestamp is present) and
-                  (not in_clock_skew(packet.timestamp,packet.usec))) or
-                 (packet.timestamp is not present and timestamp expected))
-then
-                     error_out(KRB_AP_ERR_SKEW);
-             endif
-             if (repeated(packet.timestamp,packet.usec,packet.s-address))
-then
-                     error_out(KRB_AP_ERR_REPEAT);
-             endif
-
-             if (((packet.seq-number is present) and
-                  ((not in_sequence(packet.seq-number)))) or
-                 (packet.seq-number is not present and sequence expected))
-then
-                     error_out(KRB_AP_ERR_BADORDER);
-             endif
-             if (packet.timestamp not present and packet.seq-number not
-present) then
-                     error_out(KRB_AP_ERR_MODIFIED);
-             endif
-
-             save_identifier(packet.{timestamp,usec,s-address},
-                             sender_principal(packet));
-
-             return PACKET_IS_OK;
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     A.16. KRB_PRIV generation
-
-             collect user data in buffer;
-
-             /* assemble packet: */
-             packet.pvno := protocol version; /* 5 */
-             packet.msg-type := message type; /* KRB_PRIV */
-
-             packet.enc-part.etype := encryption type;
-
-             body.user-data := buffer;
-             if (using timestamp) then
-                     get system_time;
-                     body.timestamp, body.usec := system_time;
-             endif
-             if (using sequence numbers) then
-                     body.seq-number := sequence number;
-             endif
-             body.s-address := sender host addresses;
-             if (only one recipient) then
-                     body.r-address := recipient host address;
-             endif
-
-             encode body into OCTET STRING;
-
-             select encryption type;
-             encrypt OCTET STRING into packet.enc-part.cipher;
-
-     A.17. KRB_PRIV verification
-
-             receive packet;
-             if (packet.pvno != 5) then
-                     either process using other protocol spec
-                     or error_out(KRB_AP_ERR_BADVERSION);
-             endif
-             if (packet.msg-type != KRB_PRIV) then
-                     error_out(KRB_AP_ERR_MSG_TYPE);
-             endif
-
-             cleartext := decrypt(packet.enc-part) using negotiated key;
-             if (decryption_error()) then
-                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
-             endif
-
-             if (safe_priv_common_checks_ok(cleartext)) then
-                     return(cleartext.DATA,
-PACKET_IS_GENUINE_AND_UNMODIFIED);
-             else
-                     return common_checks_error;
-             endif
-
-     A.18. KRB_CRED generation
-
-             invoke KRB_TGS; /* obtain tickets to be provided to peer */
-
-             /* assemble packet: */
-             packet.pvno := protocol version; /* 5 */
-             packet.msg-type := message type; /* KRB_CRED */
-
-             for (tickets[n] in tickets to be forwarded) do
-                     packet.tickets[n] = tickets[n].ticket;
-             done
-
-             packet.enc-part.etype := encryption type;
-
-             for (ticket[n] in tickets to be forwarded) do
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-                     body.ticket-info[n].key = tickets[n].session;
-                     body.ticket-info[n].prealm = tickets[n].crealm;
-                     body.ticket-info[n].pname = tickets[n].cname;
-                     body.ticket-info[n].flags = tickets[n].flags;
-                     body.ticket-info[n].authtime = tickets[n].authtime;
-                     body.ticket-info[n].starttime = tickets[n].starttime;
-                     body.ticket-info[n].endtime = tickets[n].endtime;
-                     body.ticket-info[n].renew-till = tickets[n].renew-till;
-                     body.ticket-info[n].srealm = tickets[n].srealm;
-                     body.ticket-info[n].sname = tickets[n].sname;
-                     body.ticket-info[n].caddr = tickets[n].caddr;
-             done
-
-             get system_time;
-             body.timestamp, body.usec := system_time;
-
-             if (using nonce) then
-                     body.nonce := nonce;
-             endif
-
-             if (using s-address) then
-                     body.s-address := sender host addresses;
-             endif
-             if (limited recipients) then
-                     body.r-address := recipient host address;
-             endif
-
-             encode body into OCTET STRING;
-
-             select encryption type;
-             encrypt OCTET STRING into packet.enc-part.cipher
-                    using negotiated encryption key;
-
-     A.19. KRB_CRED verification
-
-             receive packet;
-             if (packet.pvno != 5) then
-                     either process using other protocol spec
-                     or error_out(KRB_AP_ERR_BADVERSION);
-             endif
-             if (packet.msg-type != KRB_CRED) then
-                     error_out(KRB_AP_ERR_MSG_TYPE);
-             endif
-
-             cleartext := decrypt(packet.enc-part) using negotiated key;
-             if (decryption_error()) then
-                     error_out(KRB_AP_ERR_BAD_INTEGRITY);
-             endif
-             if ((packet.r-address is present or required) and
-                (packet.s-address != O/S_sender(packet)) then
-                     /* O/S report of sender not who claims to have sent it
-*/
-                     error_out(KRB_AP_ERR_BADADDR);
-             endif
-             if ((packet.r-address is present) and
-                 (packet.r-address != local_host_address)) then
-                     /* was not sent to proper place */
-                     error_out(KRB_AP_ERR_BADADDR);
-             endif
-             if (not in_clock_skew(packet.timestamp,packet.usec)) then
-                     error_out(KRB_AP_ERR_SKEW);
-             endif
-             if (repeated(packet.timestamp,packet.usec,packet.s-address))
-then
-                     error_out(KRB_AP_ERR_REPEAT);
-             endif
-             if (packet.nonce is required or present) and
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-                (packet.nonce != expected-nonce) then
-                     error_out(KRB_AP_ERR_MODIFIED);
-             endif
-
-             for (ticket[n] in tickets that were forwarded) do
-                     save_for_later(ticket[n],key[n],principal[n],
-                                    server[n],times[n],flags[n]);
-             return
-
-     A.20. KRB_ERROR generation
-
-             /* assemble packet: */
-             packet.pvno := protocol version; /* 5 */
-             packet.msg-type := message type; /* KRB_ERROR */
-
-             get system_time;
-             packet.stime, packet.susec := system_time;
-             packet.realm, packet.sname := server name;
-
-             if (client time available) then
-                     packet.ctime, packet.cusec := client_time;
-             endif
-             packet.error-code := error code;
-             if (client name available) then
-                     packet.cname, packet.crealm := client name;
-             endif
-             if (error text available) then
-                     packet.e-text := error text;
-             endif
-             if (error data available) then
-                     packet.e-data := error data;
-             endif
-
-     B. Definition of common authorization data elements
-
-     This appendix contains the definitions of common authorization data
-     elements. These common authorization data elements are recursivly
-     defined, meaning the ad-data for these types will itself contain a
-     sequence of authorization data whose interpretation is affected by the
-     encapsulating element. Depending on the meaning of the encapsulating
-     element, the encapsulated elements may be ignored, might be
-     interpreted as issued directly by the KDC, or they might be stored in
-     a separate plaintext part of the ticket. The types of the
-     encapsulating elements are specified as part of the Kerberos
-     specification because the behavior based on these values should be
-     understood across implementations whereas other elements need only be
-     understood by the applications which they affect.
-
-     In the definitions that follow, the value of the ad-type for the
-     element will be specified in the subsection number, and the value of
-     the ad-data will be as shown in the ASN.1 structure that follows the
-     subsection heading.
-
-     B.1. If relevant
-
-     AD-IF-RELEVANT   AuthorizationData
-
-     AD elements encapsulated within the if-relevant element are intended
-     for interpretation only by application servers that understand the
-     particular ad-type of the embedded element. Application servers that
-     do not understand the type of an element embedded within the
-     if-relevant element may ignore the uninterpretable element. This
-     element promotes interoperability across implementations which may
-     have local extensions for authorization.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     B.2. Intended for server
-
-     AD-INTENDED-FOR-SERVER   SEQUENCE {
-              intended-server[0]     SEQUENCE OF PrincipalName
-              elements[1]            AuthorizationData
-     }
-
-     AD elements encapsulated within the intended-for-server element may be
-     ignored if the application server is not in the list of principal
-     names of intended servers. Further, a KDC issuing a ticket for an
-     application server can remove this element if the application server
-     is not in the list of intended servers.
-
-     Application servers should check for their principal name in the
-     intended-server field of this element. If their principal name is not
-     found, this element should be ignored. If found, then the encapsulated
-     elements should be evaluated in the same manner as if they were
-     present in the top level authorization data field. Applications and
-     application servers that do not implement this element should reject
-     tickets that contain authorization data elements of this type.
-
-     B.3. Intended for application class
-
-     AD-INTENDED-FOR-APPLICATION-CLASS SEQUENCE {
-     intended-application-class[0] SEQUENCE OF GeneralString elements[1]
-     AuthorizationData } AD elements encapsulated within the
-     intended-for-application-class element may be ignored if the
-     application server is not in one of the named classes of application
-     servers. Examples of application server classes include "FILESYSTEM",
-     and other kinds of servers.
-
-     This element and the elements it encapulates may be safely ignored by
-     applications, application servers, and KDCs that do not implement this
-     element.
-
-     B.4. KDC Issued
-
-     AD-KDCIssued   SEQUENCE {
-                    ad-checksum[0]    Checksum,
-                     i-realm[1]       Realm OPTIONAL,
-                     i-sname[2]       PrincipalName OPTIONAL,
-                    elements[3]       AuthorizationData.
-     }
-
-     ad-checksum
-          A checksum over the elements field using a cryptographic checksum
-          method that is identical to the checksum used to protect the
-          ticket itself (i.e. using the same hash function and the same
-          encryption algorithm used to encrypt the ticket) and using a key
-          derived from the same key used to protect the ticket.
-     i-realm, i-sname
-          The name of the issuing principal if different from the KDC
-          itself. This field would be used when the KDC can verify the
-          authenticity of elements signed by the issuing principal and it
-          allows this KDC to notify the application server of the validity
-          of those elements.
-     elements
-          A sequence of authorization data elements issued by the KDC.
-     The KDC-issued ad-data field is intended to provide a means for
-     Kerberos principal credentials to embed within themselves privilege
-     attributes and other mechanisms for positive authorization, amplifying
-     the priveleges of the principal beyond what can be done using a
-     credentials without such an a-data element.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     This can not be provided without this element because the definition
-     of the authorization-data field allows elements to be added at will by
-     the bearer of a TGT at the time that they request service tickets and
-     elements may also be added to a delegated ticket by inclusion in the
-     authenticator.
-
-     For KDC-issued elements this is prevented because the elements are
-     signed by the KDC by including a checksum encrypted using the server's
-     key (the same key used to encrypt the ticket - or a key derived from
-     that key). Elements encapsulated with in the KDC-issued element will
-     be ignored by the application server if this "signature" is not
-     present. Further, elements encapsulated within this element from a
-     ticket granting ticket may be interpreted by the KDC, and used as a
-     basis according to policy for including new signed elements within
-     derivative tickets, but they will not be copied to a derivative ticket
-     directly. If they are copied directly to a derivative ticket by a KDC
-     that is not aware of this element, the signature will not be correct
-     for the application ticket elements, and the field will be ignored by
-     the application server.
-
-     This element and the elements it encapulates may be safely ignored by
-     applications, application servers, and KDCs that do not implement this
-     element.
-
-     B.5. And-Or
-
-     AD-AND-OR           SEQUENCE {
-                             condition-count[0]    INTEGER,
-                             elements[1]           AuthorizationData
-     }
-
-     When restrictive AD elements encapsulated within the and-or element
-     are encountered, only the number specified in condition-count of the
-     encapsulated conditions must be met in order to satisfy this element.
-     This element may be used to implement an "or" operation by setting the
-     condition-count field to 1, and it may specify an "and" operation by
-     setting the condition count to the number of embedded elements.
-     Application servers that do not implement this element must reject
-     tickets that contain authorization data elements of this type.
-
-     B.6. Mandatory ticket extensions
-
-     AD-Mandatory-Ticket-Extensions           SEQUENCE {
-                             te-type[0]       INTEGER,
-                             te-checksum[0]    Checksum
-     }
-
-     An authorization data element of type mandatory-ticket-extensions
-     specifies the type and a collision-proof checksum using the same hash
-     algorithm used to protect the integrity of the ticket itself. This
-     checksum will be calculated over an individual extension field of the
-     type indicated. If there are more than one extension, multiple
-     Mandatory-Ticket-Extensions authorization data elements may be
-     present, each with a checksum for a different extension field. This
-     restriction indicates that the ticket should not be accepted if a
-     ticket extension is not present in the ticket for which the type and
-     checksum do not match that checksum specified in the authorization
-     data element. Note that although the type is redundant for the
-     purposes of the comparison, it makes the comparison easier when
-     multiple extensions are present. Application servers that do not
-     implement this element must reject tickets that contain authorization
-     data elements of this type.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     B.7. Authorization Data in ticket extensions
-
-     AD-IN-Ticket-Extensions   Checksum
-
-     An authorization data element of type in-ticket-extensions specifies a
-     collision-proof checksum using the same hash algorithm used to protect
-     the integrity of the ticket itself. This checksum is calculated over a
-     separate external AuthorizationData field carried in the ticket
-     extensions. Application servers that do not implement this element
-     must reject tickets that contain authorization data elements of this
-     type. Application servers that do implement this element will search
-     the ticket extensions for authorization data fields, calculate the
-     specified checksum over each authorization data field and look for one
-     matching the checksum in this in-ticket-extensions element. If not
-     found, then the ticket must be rejected. If found, the corresponding
-     authorization data elements will be interpreted in the same manner as
-     if they were contained in the top level authorization data field.
-
-     Note that if multiple external authorization data fields are present
-     in a ticket, each will have a corresponding element of type
-     in-ticket-extensions in the top level authorization data field, and
-     the external entries will be linked to the corresponding element by
-     their checksums.
-
-     C. Definition of common ticket extensions
-
-     This appendix contains the definitions of common ticket extensions.
-     Support for these extensions is optional. However, certain extensions
-     have associated authorization data elements that may require rejection
-     of a ticket containing an extension by application servers that do not
-     implement the particular extension. Other extensions have been defined
-     beyond those described in this specification. Such extensions are
-     described elswhere and for some of those extensions the reserved
-     number may be found in the list of constants.
-
-     It is known that older versions of Kerberos did not support this
-     field, and that some clients will strip this field from a ticket when
-     they parse and then reassemble a ticket as it is passed to the
-     application servers. The presence of the extension will not break such
-     clients, but any functionaly dependent on the extensions will not work
-     when such tickets are handled by old clients. In such situations, some
-     implementation may use alternate methods to transmit the information
-     in the extensions field.
-
-     C.1. Null ticket extension
-
-     TE-NullExtension   OctetString -- The empty Octet String
-
-     The te-data field in the null ticket extension is an octet string of
-     lenght zero. This extension may be included in a ticket granting
-     ticket so that the KDC can determine on presentation of the ticket
-     granting ticket whether the client software will strip the extensions
-     field.
-
-     C.2. External Authorization Data
-
-     TE-ExternalAuthorizationData   AuthorizationData
-
-     The te-data field in the external authorization data ticket extension
-     is field of type AuthorizationData containing one or more
-     authorization data elements. If present, a corresponding authorization
-     data element will be present in the primary authorization data for the
-     ticket and that element will contain a checksum of the external
-     authorization data ticket extension.
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     ----------------------------------------------------------------------
-     [TM] Project Athena, Athena, and Kerberos are trademarks of the
-     Massachusetts Institute of Technology (MIT). No commercial use of
-     these trademarks may be made without prior written permission of MIT.
-
-     [1] Note, however, that many applications use Kerberos' functions only
-     upon the initiation of a stream-based network connection. Unless an
-     application subsequently provides integrity protection for the data
-     stream, the identity verification applies only to the initiation of
-     the connection, and does not guarantee that subsequent messages on the
-     connection originate from the same principal.
-
-     [2] Secret and private are often used interchangeably in the
-     literature. In our usage, it takes two (or more) to share a secret,
-     thus a shared DES key is a secret key. Something is only private when
-     no one but its owner knows it. Thus, in public key cryptosystems, one
-     has a public and a private key.
-
-     [3] Of course, with appropriate permission the client could arrange
-     registration of a separately-named prin- cipal in a remote realm, and
-     engage in normal exchanges with that realm's services. However, for
-     even small numbers of clients this becomes cumbersome, and more
-     automatic methods as described here are necessary.
-
-     [4] Though it is permissible to request or issue tick- ets with no
-     network addresses specified.
-
-     [5] The password-changing request must not be honored unless the
-     requester can provide the old password (the user's current secret
-     key). Otherwise, it would be possible for someone to walk up to an
-     unattended ses- sion and change another user's password.
-
-     [6] To authenticate a user logging on to a local system, the
-     credentials obtained in the AS exchange may first be used in a TGS
-     exchange to obtain credentials for a local server. Those credentials
-     must then be verified by a local server through successful completion
-     of the Client/Server exchange.
-
-     [7] "Random" means that, among other things, it should be impossible
-     to guess the next session key based on knowledge of past session keys.
-     This can only be achieved in a pseudo-random number generator if it is
-     based on cryptographic principles. It is more desirable to use a truly
-     random number generator, such as one based on measurements of random
-     physical phenomena.
-
-     [8] Tickets contain both an encrypted and unencrypted portion, so
-     cleartext here refers to the entire unit, which can be copied from one
-     message and replayed in another without any cryptographic skill.
-
-     [9] Note that this can make applications based on unreliable
-     transports difficult to code correctly. If the transport might deliver
-     duplicated messages, either a new authenticator must be generated for
-     each retry, or the application server must match requests and replies
-     and replay the first reply in response to a detected duplicate.
-
-     [10] This is used for user-to-user authentication as described in [8].
-
-     [11] Note that the rejection here is restricted to authenticators from
-     the same principal to the same server. Other client principals
-     communicating with the same server principal should not be have their
-     authenticators rejected if the time and microsecond fields happen to
-     match some other client's authenticator.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     [12] In the Kerberos version 4 protocol, the timestamp in the reply
-     was the client's timestamp plus one. This is not necessary in version
-     5 because version 5 messages are formatted in such a way that it is
-     not possible to create the reply by judicious message surgery (even in
-     encrypted form) without knowledge of the appropriate encryption keys.
-
-     [13] Note that for encrypting the KRB_AP_REP message, the sub-session
-     key is not used, even if present in the Authenticator.
-
-     [14] Implementations of the protocol may wish to provide routines to
-     choose subkeys based on session keys and random numbers and to
-     generate a negotiated key to be returned in the KRB_AP_REP message.
-
-     [15]This can be accomplished in several ways. It might be known
-     beforehand (since the realm is part of the principal identifier), it
-     might be stored in a nameserver, or it might be obtained from a
-     configura- tion file. If the realm to be used is obtained from a
-     nameserver, there is a danger of being spoofed if the nameservice
-     providing the realm name is not authenti- cated. This might result in
-     the use of a realm which has been compromised, and would result in an
-     attacker's ability to compromise the authentication of the application
-     server to the client.
-
-     [16] If the client selects a sub-session key, care must be taken to
-     ensure the randomness of the selected sub- session key. One approach
-     would be to generate a random number and XOR it with the session key
-     from the ticket-granting ticket.
-
-     [17] This allows easy implementation of user-to-user authentication
-     [8], which uses ticket-granting ticket session keys in lieu of secret
-     server keys in situa- tions where such secret keys could be easily
-     comprom- ised.
-
-     [18] For the purpose of appending, the realm preceding the first
-     listed realm is considered to be the null realm ("").
-
-     [19] For the purpose of interpreting null subfields, the client's
-     realm is considered to precede those in the transited field, and the
-     server's realm is considered to follow them.
-
-     [20] This means that a client and server running on the same host and
-     communicating with one another using the KRB_SAFE messages should not
-     share a common replay cache to detect KRB_SAFE replays.
-
-     [21] The implementation of the Kerberos server need not combine the
-     database and the server on the same machine; it is feasible to store
-     the principal database in, say, a network name service, as long as the
-     entries stored therein are protected from disclosure to and
-     modification by unauthorized parties. However, we recommend against
-     such strategies, as they can make system management and threat
-     analysis quite complex.
-
-     [22] See the discussion of the padata field in section 5.4.2 for
-     details on why this can be useful.
-
-     [23] Warning for implementations that unpack and repack data
-     structures during the generation and verification of embedded
-     checksums: Because any checksums applied to data structures must be
-     checked against the original data the length of bit strings must be
-     preserved within a data structure between the time that a checksum is
-     generated through transmission to the time that the checksum is
-     verified.
-
-
-Neuman, Ts'o, Kohl                                   Expires: 14 January
-2001
-
-^L
-
-INTERNET-DRAFT    draft-ietf-cat-kerberos-revisions-06          July 14,
-2000
-
-     [24] It is NOT recommended that this time value be used to adjust the
-     workstation's clock since the workstation cannot reliably determine
-     that such a KRB_AS_REP actually came from the proper KDC in a timely
-     manner.
-
-     [25] Note, however, that if the time is used as the nonce, one must
-     make sure that the workstation time is monotonically increasing. If
-     the time is ever reset backwards, there is a small, but finite,
-     probability that a nonce will be reused.
-
-     [27] An application code in the encrypted part of a message provides
-     an additional check that the message was decrypted properly.
-
-     [29] An application code in the encrypted part of a message provides
-     an additional check that the message was decrypted properly.
-
-     [31] An application code in the encrypted part of a message provides
-     an additional check that the message was decrypted properly.
-
-     [32] If supported by the encryption method in use, an initialization
-     vector may be passed to the encryption procedure, in order to achieve
-     proper cipher chaining. The initialization vector might come from the
-     last block of the ciphertext from the previous KRB_PRIV message, but
-     it is the application's choice whether or not to use such an
-     initialization vector. If left out, the default initialization vector
-     for the encryption algorithm will be used.
-
-     [33] This prevents an attacker who generates an incorrect AS request
-     from obtaining verifiable plaintext for use in an off-line password
-     guessing attack.
-
-     [35] In the above specification, UNTAGGED OCTET STRING(length) is the
-     notation for an octet string with its tag and length removed. It is
-     not a valid ASN.1 type. The tag bits and length must be removed from
-     the confounder since the purpose of the confounder is so that the
-     message starts with random data, but the tag and its length are fixed.
-     For other fields, the length and tag would be redundant if they were
-     included because they are specified by the encryption type. [36] The
-     ordering of the fields in the CipherText is important. Additionally,
-     messages encoded in this format must include a length as part of the
-     msg-seq field. This allows the recipient to verify that the message
-     has not been truncated. Without a length, an attacker could use a
-     chosen plaintext attack to generate a message which could be
-     truncated, while leaving the checksum intact. Note that if the msg-seq
-     is an encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length
-     is part of that encoding.
-
-     [37] In some cases, it may be necessary to use a different "mix-in"
-     string for compatibility reasons; see the discussion of padata in
-     section 5.4.2.
-
-     [38] In some cases, it may be necessary to use a different "mix-in"
-     string for compatibility reasons; see the discussion of padata in
-     section 5.4.2.
-
-     [39] A variant of the key is used to limit the use of a key to a
-     particular function, separating the functions of generating a checksum
-     from other encryption performed using the session key. The constant
-     F0F0F0F0F0F0F0F0 was chosen because it maintains key parity. The
-     properties of DES precluded the use of the complement. The same
-     constant is used for similar purpose in the Message Integrity Check in
-     the Privacy Enhanced Mail standard.
-
-     [40] This error carries additional information in the e- data field.
-     The contents of the e-data field for this message is described in
-     section 5.9.1.
-
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt b/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt
deleted file mode 100644
index 6f7dae0de..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt
+++ /dev/null
@@ -1,325 +0,0 @@
-
-INTERNET-DRAFT                                        Mike Swift 
-draft-ietf-cat-kerberos-set-passwd-02.txt             Microsoft
-March 2000                                            Jonathan Trostle
-                                                      Cisco Systems
-                                                      John Brezak
-                                                      Microsoft
-                                                      Bill Gossman
-                                                      Cybersafe
-
-              Kerberos Set/Change Password: Version 2
-
-
-0. Status Of This Memo
-
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1]. 
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   Comments and suggestions on this document are encouraged.  Comments 
-   on this document should be sent to the CAT working group discussion 
-   list:
-                       ietf-cat-wg@stanford.edu
-
-1. Abstract
-
-   The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), 
-   does not allow for an administrator to set a password for a new user. 
-   This functionality is useful in some environments, and this proposal 
-   extends [4] to allow password setting. The changes are: adding new 
-   fields to the request message to indicate the principal which is 
-   having its password set, not requiring the initial flag in the service 
-   ticket, using a new protocol version number, and adding three new 
-   result codes. We also extend the set/change protocol to allow a 
-   client to send a sequence of keys to the KDC instead of a cleartext 
-   password. If in the cleartext password case, the cleartext password 
-   fails to satisfy password policy, the server should use the result    
-   code KRB5_KPASSWD_POLICY_REJECT.
-
-2. Conventions used in this document 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-   
-3. The Protocol
-
-   The service must accept requests on UDP port 464 and TCP port 464 as 
-   well. The protocol consists of a single request message followed by 
-   a single reply message.  For UDP transport, each message must be fully 
-   contained in a single UDP packet.
-
-   For TCP transport, there is a 4 octet header in network byte order
-   precedes the message and specifies the length of the message. This
-   requirement is consistent with the TCP transport header in 1510bis.
-
-Request Message
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |         message length        |    protocol version number    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |          AP_REQ length        |         AP-REQ data           /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      /                        KRB-PRIV message                       /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   All 16 bit fields are in network byte order. 
-
-   message length field: contains the number of bytes in the message 
-   including this field.
-
-   protocol version number: contains the hex constant 0x0002 (network
-   byte order).
-
-   AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, 
-   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
-   message.
-
-   AP-REQ data: (see [3]) The AP-REQ message must be for the service 
-   principal kadmin/changepw@REALM, where REALM is the REALM of the user 
-   who wishes to change/set his password.  The ticket in the AP-REQ must 
-   must include a subkey in the Authenticator. To enable setting of 
-   passwords/keys, it is not required that the initial flag be set in the 
-   Kerberos service ticket. The initial flag is required for change requests,
-   but not for set password requests. We have the following definitions:
-
-                    old passwd   initial flag  target principal can be
-                    in request?  required?     distinct from 
-                                               authenticating principal?
-                                              
-   change password:  yes         yes           no
-
-   set password:     no          no            yes
-
-   set key:          no          policy        yes
-                                 determined
-
-   KRB-PRIV message (see [3]) This KRB-PRIV message must be generated 
-   using the subkey from the authenticator in the AP-REQ data. 
-
-   The user-data component of the message consists of the following ASN.1 
-   structure encoded as an OCTET STRING:
-
-   ChangePasswdData :: =  SEQUENCE {
-                       newpasswdorkeys[0]   NewPasswdOrKeys,
-                       targname[1]          PrincipalName OPTIONAL,
-                         -- only present in set password: the principal
-                         -- which will have its password set
-                       targrealm[2]         Realm OPTIONAL, 
-                         -- only present in set password: the realm for 
-                         -- the principal which will have its password set
-
-                       }
-
-   NewPasswdOrKeys :: = CHOICE {
-                       passwords[0]  PasswordSequence,       
-                       keyseq[1]     KeySequences
-   }
-                         
-   KeySequences :: = SEQUENCE OF KeySequence
-
-   KeySequence :: = SEQUENCE {
-                       key[0]        EncryptionKey,
-                       salt[1]       OCTET STRING OPTIONAL,
-                       salt-type[2]  INTEGER OPTIONAL
-   }
-
-   PasswordSequence :: = SEQUENCE {
-                       newpasswd[0]  OCTET STRING,
-                       oldpasswd[1]  OCTET STRING OPTIONAL
-                         -- oldpasswd always present for change password
-                         -- but not present for set password 
-   }
-
-   The server must verify the AP-REQ message, check whether the client 
-   principal in the ticket is authorized to set or change the password 
-   (either for that principal, or for the principal in the targname 
-   field if present), and decrypt the new password/keys. The server 
-   also checks whether the initial flag is required for this request, 
-   replying with status 0x0007 if it is not set and should be. An 
-   authorization failure is cause to respond with status 0x0005. For 
-   forward compatibility, the server should be prepared to ignore fields 
-   after targrealm in the structure that it does not understand. 
-
-   The newpasswdorkeys field contains either the new cleartext password 
-   (with the old cleartext password for a change password operation), 
-   or a sequence of encryption keys with their respective salts. 
-
-   In the cleartext password case, if the old password is sent in the
-   request, the request is defined to be a change password request. If
-   the old password is not present in the request, the request is a set
-   password request. The server should apply policy checks to the old 
-   and new password after verifying that the old password is valid. 
-   The server can check validity by obtaining a key from the old 
-   password with a keytype that is present in the KDC database for the 
-   user and comparing the keys for equality. The server then generates 
-   the appropriate keytypes from the password and stores them in the KDC 
-
-   database. If all goes well, status 0x0000 is returned to the client 
-   in the reply message (see below). For a change password operation,
-   the initial flag in the service ticket MUST be set. 
-
-   In the key sequence case, the sequence of keys is sent to the set
-   password service. For a principal that can act as a server, its 
-   preferred keytype should be sent as the first key in the sequence, 
-   but the KDC is not required to honor this preference. Application 
-   servers should use the key sequence option for changing/setting their 
-   keys. The set password service should check that all keys are in the
-   proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise. 
-
-Reply Message
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |         message length        |    protocol version number    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |          AP_REP length        |         AP-REP data           /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      /                          KRB-PRIV message                     /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-   All 16 bit fields are in network byte order. 
-
-   message length field: contains the number of bytes in the message 
-   including this field.
-
-   protocol version number: contains the hex constant 0x0002 (network
-   byte order). (The reply message has the same format as in [4]).
-
-   AP-REP length: length of AP-REP data, in bytes. If the length is zero, 
-   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
-   message.
-
-   AP-REP data: the AP-REP is the response to the AP-REQ in the request 
-   packet.
-   
-   KRB-PRIV from [4]: This KRB-PRIV message must be generated using the 
-   subkey in the authenticator in the AP-REQ data.
-
-   The server will respond with a KRB-PRIV message unless it cannot
-   validate the client AP-REQ or KRB-PRIV message, in which case it will
-   respond with a KRB-ERROR message. NOTE: Unlike change password version
-   1, the KRB-ERROR message will be sent back without any encapsulation. 
-
-   The user-data component of the KRB-PRIV message, or e-data component 
-   of the KRB-ERROR message, must consist of the following data.
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |          result code          |        result string          /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                             edata                             /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-      result code (16 bits) (result codes 0-4 are from [4]):
-         The result code must have one of the following values (network
-         byte order):
-         KRB5_KPASSWD_SUCCESS      0 request succeeds (This value is not 
-                                     allowed in a KRB-ERROR message)
-         KRB5_KPASSWD_MALFORMED    1 request fails due to being malformed
-         KRB5_KPASSWD_HARDERROR    2 request fails due to "hard" error in
-                                     processing the request (for example, 
-                                     there is a resource or other problem 
-                                     causing the request to fail)
-         KRB5_KPASSWD_AUTHERROR    3 request fails due to an error in 
-                                     authentication processing
-         KRB5_KPASSWD_SOFTERROR    4 request fails due to a soft error 
-                                     in processing the request 
-         KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
-         KRB5_KPASSWD_BAD_VERSION  6 protocol version unsupported
-         KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
-         KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy;
-         the result string should include a text message to be presented
-         to the user.
-         KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist
-         (only in response to a set password request).
-         KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
-         containing at least one etype that is not supported by the KDC.
-         The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO 
-         type that specifies the etypes that the KDC supports:
-         
-         KERB-ETYPE-INFO-ENTRY :: = SEQUENCE {
-                encryption-type[0]  INTEGER,
-                salt[1]             OCTET STRING OPTIONAL -- not sent
-         }
-
-         PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY
-
-         The client should retry the request using only etypes (keytypes)
-         that are contained within the PKERB-ETYPE-INFO structure in the
-         previous response. 
-         0xFFFF if the request fails for some other reason.
-         The client must interpret any non-zero result code as a failure.
-      result string - from [4]:
-         This field is a UTF-8 encoded string which should be displayed
-         to the user by the client. Specific reasons for a password 
-         set/change policy failure is one use for this string. 
-      edata: used to convey additional information as defined by the 
-         result code. 
-
-4. References
-
-   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-       9, RFC 2026, October 1996. 
-    
-   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-       Levels", BCP 14, RFC 2119, March 1997 
- 
-   [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
-       Service (V5), Request for Comments 1510.
-
-   [4] M. Horowitz. Kerberos Change Password Protocol,
-       ftp://ds.internic.net/internet-drafts/
-       draft-ietf-cat-kerb-chg-password-02.txt
-
-5. Expiration Date
-
-   This draft expires in September 2000.
-
-6. Authors' Addresses
-
-   Jonathan Trostle
-   Cisco Systems
-   170 W. Tasman Dr.
-   San Jose, CA 95134
-   Email: jtrostle@cisco.com
-
-   Mike Swift 
-   1 Microsoft Way
-   Redmond, WA 98052
-   Email: mikesw@microsoft.com
-
-   John Brezak
-   1 Microsoft Way
-   Redmond, WA 98052
-   Email: jbrezak@microsoft.com
-
-   Bill Gossman
-   Cybersafe Corporation
-   1605 NW Sammamish Rd.
-   Issaquah, WA 98027-5378
-   Email: bill.gossman@cybersafe.com
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt b/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt
deleted file mode 100644
index 0319f8bf3..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt
+++ /dev/null
@@ -1,345 +0,0 @@
-
-INTERNET-DRAFT                                        Mike Swift 
-draft-ietf-cat-kerberos-set-passwd-03.txt             Microsoft
-April 2000                                            Jonathan Trostle
-                                                      Cisco Systems
-                                                      John Brezak
-                                                      Microsoft
-                                                      Bill Gossman
-                                                      Cybersafe
-
-              Kerberos Set/Change Password: Version 2
-
-
-0. Status Of This Memo
-
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1]. 
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   Comments and suggestions on this document are encouraged.  Comments 
-   on this document should be sent to the CAT working group discussion 
-   list:
-                       ietf-cat-wg@stanford.edu
-
-1. Abstract
-
-   The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), 
-   does not allow for an administrator to set a password for a new user. 
-   This functionality is useful in some environments, and this proposal 
-   extends [4] to allow password setting. The changes are: adding new 
-   fields to the request message to indicate the principal which is 
-   having its password set, not requiring the initial flag in the service 
-   ticket, using a new protocol version number, and adding three new 
-   result codes. We also extend the set/change protocol to allow a 
-   client to send a sequence of keys to the KDC instead of a cleartext 
-   password. If in the cleartext password case, the cleartext password 
-   fails to satisfy password policy, the server should use the result    
-   code KRB5_KPASSWD_POLICY_REJECT.
-
-2. Conventions used in this document 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-   
-3. The Protocol
-
-   The service must accept requests on UDP port 464 and TCP port 464 as 
-   well. The protocol consists of a single request message followed by 
-   a single reply message.  For UDP transport, each message must be fully 
-   contained in a single UDP packet.
-
-   For TCP transport, there is a 4 octet header in network byte order
-   precedes the message and specifies the length of the message. This
-   requirement is consistent with the TCP transport header in 1510bis.
-
-Request Message
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |         message length        |    protocol version number    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |          AP_REQ length        |         AP-REQ data           /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      /                        KRB-PRIV message                       /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   All 16 bit fields are in network byte order. 
-
-   message length field: contains the number of bytes in the message 
-   including this field.
-
-   protocol version number: contains the hex constant 0x0002 (network
-   byte order).
-
-   AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, 
-   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
-   message.
-
-   AP-REQ data: (see [3]) For a change password/key request, the AP-REQ 
-   message service ticket sname, srealm principal identifier is 
-   kadmin/changepw@REALM where REALM is the realm of the change password 
-   service. The same applies to a set password/key request except the 
-   principal identifier is kadmin/setpw@REALM. The ticket in the AP-REQ 
-   must include a subkey in the Authenticator. To enable setting of 
-   passwords/keys, it is not required that the initial flag be set in the 
-   Kerberos service ticket. The initial flag is required for change requests,
-   but not for set requests. We have the following definitions:
-
-                    old passwd   initial flag  target principal can be
-                    in request?  required?     distinct from 
-                                               authenticating principal?
-                                              
-   change password:  yes         yes           no
-
-   set password:     no          policy (*)    yes
-
-   set key:          no          policy (*)    yes
-                                 
-   change key:       no          yes           no
-
-   policy (*): implementations SHOULD allow administrators to set the
-   initial flag required for set requests policy to either yes or no.
-   Clients MUST be able to retry set requests that fail due to error 7
-   (initial flag required) with an initial ticket. Clients SHOULD NOT
-   cache service tickets targetted at kadmin/changepw.
-
-   KRB-PRIV message (see [3]) This KRB-PRIV message must be generated 
-   using the subkey from the authenticator in the AP-REQ data. 
-
-   The user-data component of the message consists of the following ASN.1 
-   structure encoded as an OCTET STRING:
-
-   ChangePasswdData :: =  SEQUENCE {
-                       newpasswdorkeys[0]   NewPasswdOrKeys,
-                       targname[1]          PrincipalName OPTIONAL,
-                         -- only present in set password/key: the principal
-                         -- which will have its password or keys set. Not
-                         -- present in a set request if the client principal
-                         -- from the ticket is the principal having its 
-                         -- passwords or keys set.
-                       targrealm[2]         Realm OPTIONAL, 
-                         -- only present in set password/key: the realm for 
-                         -- the principal which will have its password or
-                         -- keys set. Not present in a set request if the 
-                         -- client principal from the ticket is the principal 
-                         -- having its passwords or keys set.
-                       }
-
-   NewPasswdOrKeys :: = CHOICE {
-                       passwords[0]  PasswordSequence,  -- change/set passwd   
-                       keyseq[1]     KeySequences       -- change/set key
-   }
-                         
-   KeySequences :: = SEQUENCE OF KeySequence
-
-   KeySequence :: = SEQUENCE {
-                       key[0]        EncryptionKey,
-                       salt[1]       OCTET STRING OPTIONAL,
-                       salt-type[2]  INTEGER OPTIONAL
-   }
-
-   PasswordSequence :: = SEQUENCE {
-                       newpasswd[0]  OCTET STRING,
-                       oldpasswd[1]  OCTET STRING OPTIONAL
-                         -- oldpasswd always present for change password
-                         -- but not present for set password, set key, or
-                         -- change key
-   }
-
-   The server must verify the AP-REQ message, check whether the client 
-   principal in the ticket is authorized to set or change the password 
-   (either for that principal, or for the principal in the targname 
-   field if present), and decrypt the new password/keys. The server 
-   also checks whether the initial flag is required for this request, 
-   replying with status 0x0007 if it is not set and should be. An 
-   authorization failure is cause to respond with status 0x0005. For 
-   forward compatibility, the server should be prepared to ignore fields 
-   after targrealm in the structure that it does not understand. 
-
-   The newpasswdorkeys field contains either the new cleartext password 
-   (with the old cleartext password for a change password operation), 
-   or a sequence of encryption keys with their respective salts. 
-
-   In the cleartext password case, if the old password is sent in the
-   request, the request MUST be a change password request. If the old 
-   password is not present in the request, the request MUST be a set
-   password request. The server should apply policy checks to the old 
-   and new password after verifying that the old password is valid. 
-   The server can check validity by obtaining a key from the old 
-   password with a keytype that is present in the KDC database for the 
-   user and comparing the keys for equality. The server then generates 
-   the appropriate keytypes from the password and stores them in the KDC 
-   database. If all goes well, status 0x0000 is returned to the client 
-   in the reply message (see below). For a change password operation,
-   the initial flag in the service ticket MUST be set. 
-
-   In the key sequence case, the sequence of keys is sent to the change
-   or set password service (kadmin/changepw or kadmin/setpw respectively). 
-   For a principal that can act as a server, its preferred keytype should 
-   be sent as the first key in the sequence, but the KDC is not required 
-   to honor this preference. Application servers should use the key 
-   sequence option for changing/setting their keys. The change/set password 
-   services should check that all keys are in the proper format, returning 
-   the KRB5_KPASSWD_MALFORMED error otherwise. 
-
-Reply Message
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |         message length        |    protocol version number    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |          AP_REP length        |         AP-REP data           /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      /                          KRB-PRIV message                     /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-   All 16 bit fields are in network byte order. 
-
-   message length field: contains the number of bytes in the message 
-   including this field.
-
-   protocol version number: contains the hex constant 0x0002 (network
-   byte order). (The reply message has the same format as in [4]).
-
-   AP-REP length: length of AP-REP data, in bytes. If the length is zero, 
-   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
-   message.
-
-   AP-REP data: the AP-REP is the response to the AP-REQ in the request 
-   packet.
-   
-   KRB-PRIV from [4]: This KRB-PRIV message must be generated using the 
-   subkey in the authenticator in the AP-REQ data.
-
-   The server will respond with a KRB-PRIV message unless it cannot
-   validate the client AP-REQ or KRB-PRIV message, in which case it will
-   respond with a KRB-ERROR message. NOTE: Unlike change password version
-   1, the KRB-ERROR message will be sent back without any encapsulation. 
-
-   The user-data component of the KRB-PRIV message, or e-data component 
-   of the KRB-ERROR message, must consist of the following data.
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |          result code          |        result string          /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                             edata                             /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-      result code (16 bits) (result codes 0-4 are from [4]):
-         The result code must have one of the following values (network
-         byte order):
-         KRB5_KPASSWD_SUCCESS      0 request succeeds (This value is not 
-                                     allowed in a KRB-ERROR message)
-         KRB5_KPASSWD_MALFORMED    1 request fails due to being malformed
-         KRB5_KPASSWD_HARDERROR    2 request fails due to "hard" error in
-                                     processing the request (for example, 
-                                     there is a resource or other problem 
-                                     causing the request to fail)
-         KRB5_KPASSWD_AUTHERROR    3 request fails due to an error in 
-                                     authentication processing
-         KRB5_KPASSWD_SOFTERROR    4 request fails due to a soft error 
-                                     in processing the request 
-         KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
-         KRB5_KPASSWD_BAD_VERSION  6 protocol version unsupported
-         KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
-         KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy;
-         the result string should include a text message to be presented
-         to the user.
-         KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist
-         (only in response to a set password request).
-         KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
-         containing at least one etype that is not supported by the KDC.
-         The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO 
-         type that specifies the etypes that the KDC supports:
-         
-         KERB-ETYPE-INFO-ENTRY :: = SEQUENCE {
-                encryption-type[0]  INTEGER,
-                salt[1]             OCTET STRING OPTIONAL -- not sent
-         }
-
-         PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY
-
-         The client should retry the request using only etypes (keytypes)
-         that are contained within the PKERB-ETYPE-INFO structure in the
-         previous response. 
-         0xFFFF if the request fails for some other reason.
-         The client must interpret any non-zero result code as a failure.
-      result string - from [4]:
-         This field is a UTF-8 encoded string which should be displayed
-         to the user by the client. Specific reasons for a password 
-
-         set/change policy failure is one use for this string. 
-      edata: used to convey additional information as defined by the 
-         result code. 
-
-4. Acknowledgements
-  
-   The authors thank Tony Andrea for his input to the document.
-
-5. References
-
-   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-       9, RFC 2026, October 1996. 
-    
-   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-       Levels", BCP 14, RFC 2119, March 1997 
- 
-   [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
-       Service (V5), Request for Comments 1510.
-
-   [4] M. Horowitz. Kerberos Change Password Protocol,
-       ftp://ds.internic.net/internet-drafts/
-       draft-ietf-cat-kerb-chg-password-02.txt
-
-6. Expiration Date
-
-   This draft expires in October 2000.
-
-7. Authors' Addresses
-
-   Jonathan Trostle
-   Cisco Systems
-   170 W. Tasman Dr.
-   San Jose, CA 95134
-   Email: jtrostle@cisco.com
-
-   Mike Swift 
-   1 Microsoft Way
-   Redmond, WA 98052
-   Email: mikesw@microsoft.com
-
-   John Brezak
-   1 Microsoft Way
-   Redmond, WA 98052
-   Email: jbrezak@microsoft.com
-
-   Bill Gossman
-   Cybersafe Corporation
-   1605 NW Sammamish Rd.
-   Issaquah, WA 98027-5378
-   Email: bill.gossman@cybersafe.com
-
diff --git a/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.txt b/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.txt
deleted file mode 100644
index b15c8284d..000000000
--- a/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.txt
+++ /dev/null
@@ -1,809 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   Jonathan Trostle
-INTERNET-DRAFT                                             Cisco Systems
-Category: Standards Track                                     Mike Swift
-                                                        University of WA
-                                                             John Brezak
-                                                               Microsoft
-                                                            Bill Gossman
-                                                           Cisco Systems
-
-
-                Kerberos Set/Change Password: Version 2
-              <draft-ietf-cat-kerberos-set-passwd-06.txt>
-
-
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026 [6].
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This draft expires on December 31st, 2001. Please send comments to
-   the authors.
-
-1. Abstract
-
-   This proposal specifies a Kerberos (RFC 1510 [3]) change/set password
-   protocol and a Kerberos change/set key protocol. The protocol
-   consists of a single request and reply message. The request message
-   includes both AP-REQ and KRB-PRIV submessages; the new password is
-   contained in the KRB-PRIV submessage which is encrypted in the
-   subsession key from the AP-REQ. The original Kerberos change password
-   protocol did not allow for an administrator to set a password for a
-   new user. This functionality is useful in some environments, and this
-   proposal allows password setting as well as password changing. The
-   protocol includes fields in the request message to indicate the
-   principal which is having its password set. We also extend the
-   set/change protocol to allow a client to send a sequence of keys to
-
-
-
-Trostle, Swift, Brezak, Gossman                                 [Page 1]
-
-INTERNET DRAFT                 June 2001           Expires December 2001
-
-
-   the KDC instead of a cleartext password. If in the cleartext password
-   case, the cleartext password fails to satisfy password policy, the
-   server should use the result code KRB5_KPASSWD_POLICY_REJECT.
-
-2. Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC2119 [7].
-
-3. Definitions from RFC 1510
-
-   We include some of the relevant ASN.1 definitions from RFC 1510 in
-   this section.
-
-      Realm ::=           GeneralString
-
-      PrincipalName ::=   SEQUENCE {
-                          name-type[0]     INTEGER,
-                          name-string[1]   SEQUENCE OF GeneralString
-      }
-
-      KerberosTime ::=    GeneralizedTime
-                          -- Specifying UTC time zone (Z)
-
-      HostAddress ::=     SEQUENCE  {
-                          addr-type[0]             INTEGER,
-                          address[1]               OCTET STRING
-      }
-
-      EncryptedData ::=   SEQUENCE {
-                        etype[0]     INTEGER, -- EncryptionType
-                        kvno[1]      INTEGER OPTIONAL,
-                        cipher[2]    OCTET STRING -- ciphertext
-      }
-
-      EncryptionKey ::=   SEQUENCE {
-                          keytype[0]    INTEGER,
-                          keyvalue[1]   OCTET STRING
-      }
-
-      Checksum ::=        SEQUENCE {
-                          cksumtype[0]   INTEGER,
-                          checksum[1]    OCTET STRING
-      }
-
-
-      AP-REQ ::= [APPLICATION 14] SEQUENCE {
-              pvno [0]         INTEGER,        -- indicates Version 5
-              msg-type [1]     INTEGER,        -- indicates KRB_AP_REQ
-              ap-options[2]    APOptions,
-              ticket[3]        Ticket,
-              authenticator[4] EncryptedData
-      }
-
-
-
-Trostle, Swift, Brezak, Gossman                                 [Page 2]
-
-INTERNET DRAFT                 June 2001           Expires December 2001
-
-
-      APOptions ::= BIT STRING {
-
-              reserved (0),
-              use-session-key (1),
-              mutual-required (2)
-      }
-
-      Ticket ::= [APPLICATION 1] SEQUENCE {
-              tkt-vno [0]     INTEGER,        -- indicates Version 5
-              realm [1]       Realm,
-              sname [2]       PrincipalName,
-              enc-part [3]    EncryptedData
-      }
-
-
-      -- Encrypted part of ticket
-      EncTicketPart ::= [APPLICATION 3] SEQUENCE {
-              flags[0]        TicketFlags,
-              key[1]          EncryptionKey,
-              crealm[2]       Realm,
-              cname[3]        PrincipalName,
-              transited[4]    TransitedEncoding,
-              authtime[5]     KerberosTime,
-              starttime[6]    KerberosTime OPTIONAL,
-              endtime[7]      KerberosTime,
-              renew-till[8]   KerberosTime OPTIONAL,
-              caddr[9]        HostAddresses OPTIONAL,
-              authorization-data[10]  AuthorizationData OPTIONAL
-      }
-
-      -- Unencrypted authenticator
-      Authenticator ::= [APPLICATION 2] SEQUENCE  {
-              authenticator-vno[0]    INTEGER,
-              crealm[1]               Realm,
-              cname[2]                PrincipalName,
-              cksum[3]                Checksum OPTIONAL,
-              cusec[4]                INTEGER,
-              ctime[5]                KerberosTime,
-              subkey[6]               EncryptionKey OPTIONAL,
-              seq-number[7]           INTEGER OPTIONAL,
-              authorization-data[8]   AuthorizationData OPTIONAL
-      }
-
-      AP-REP ::= [APPLICATION 15] SEQUENCE {
-              pvno [0]        INTEGER,        -- represents Kerberos V5
-              msg-type [1]    INTEGER,        -- represents KRB_AP_REP
-              enc-part [2]    EncryptedData
-      }
-
-      EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
-              ctime [0]       KerberosTime,
-              cusec [1]       INTEGER,
-              subkey [2]      EncryptionKey OPTIONAL,
-              seq-number [3]  INTEGER OPTIONAL
-
-
-
-Trostle, Swift, Brezak, Gossman                                 [Page 3]
-
-INTERNET DRAFT                 June 2001           Expires December 2001
-
-
-      }
-
-   Here is the syntax of the KRB-ERROR message:
-
-      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
-      }
-
-   The KRB-PRIV message is used to send the request and reply data:
-
-      KRB-PRIV ::=     [APPLICATION 21] SEQUENCE {
-                   pvno[0]                   INTEGER,
-                   msg-type[1]               INTEGER,
-                   enc-part[3]               EncryptedData
-      }
-
-      EncKrbPrivPart ::=   [APPLICATION 28] SEQUENCE {
-                   user-data[0]              OCTET STRING,
-                   timestamp[1]              KerberosTime OPTIONAL,
-                   usec[2]                   INTEGER OPTIONAL,
-                   seq-number[3]             INTEGER OPTIONAL,
-                   s-address[4]              HostAddress,
-                                                        -- sender's addr
-                   r-address[5]              HostAddress OPTIONAL
-                                                        -- recip's addr
-      }
-
-
-4. The Protocol
-
-   The service SHOULD accept requests on UDP port 464 and TCP port 464
-   as well. Use of other ports can significantly increase the complexity
-   and size of IPSEC policy rulesets in organizations that have IPSEC
-   capable nodes.
-
-   The protocol consists of a single request message followed by a
-   single reply message.  For UDP transport, each message must be fully
-   contained in a single UDP packet.
-
-   For TCP transport, there is a 4 octet header in network byte order
-   that precedes the message and specifies the length of the message.
-   This requirement is consistent with the TCP transport header in
-
-
-
-Trostle, Swift, Brezak, Gossman                                 [Page 4]
-
-INTERNET DRAFT                 June 2001           Expires December 2001
-
-
-   1510bis.
-
-
-
-   Request Message
-
-        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
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |         message length        |    protocol version number    |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |          AP-REQ length        |         AP-REQ data           /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       /                        KRB-PRIV message                       /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   All 16 bit fields are in network byte order.
-
-   message length field: contains the number of bytes in the message
-   including this field.
-
-   protocol version number: contains the hex constant 0x0002 (network
-   byte order).
-
-   AP-REQ length: length of AP-REQ data, in bytes. If the length is
-   zero, then the last field contains a KRB-ERROR message instead of a
-   KRB-PRIV message.
-
-   AP-REQ data: (see [3]) For a change password/key request, the AP-REQ
-   message service ticket sname, srealm principal identifier is
-   kadmin/changepw@REALM where REALM is the realm of the change password
-   service. The same applies to a set password/key request except the
-   principal identifier is kadmin/setpw@REALM. The authenticator in the
-   AP-REQ MUST contain a subsession key (which will be used to encrypt
-   the KRB-PRIV user data field - see below). The KDC may have stronger
-   pseudorandom generating capability then the clients; thus, the client
-   SHOULD use the session key as an input (along with additional locally
-   pseudorandom generated bits) into the generation of the subsession
-   key. To enable setting of passwords/keys, it is not required that the
-   initial flag be set in the Kerberos service ticket. The initial flag
-   is required for change requests, but not for set requests. We have
-   the following definitions:
-
-                   old passwd   initial flag  target principal can be
-                   in request?  required?     distinct from
-                                              authenticating principal?
-
-   change password:  yes         yes           no
-
-   set password:     no          policy (*)    yes
-
-   set key:          no          policy (*)    yes
-
-   change key:       no          yes           no
-
-
-
-Trostle, Swift, Brezak, Gossman                                 [Page 5]
-
-INTERNET DRAFT                 June 2001           Expires December 2001
-
-
-   policy (*): implementations SHOULD allow administrators to set the
-   initial flag required for set requests policy to either yes or no.
-   Clients MUST be able to retry set requests that fail due to error 7
-   (initial flag required) with an initial ticket. Clients SHOULD NOT
-   cache service tickets targetted at kadmin/changepw.
-
-   KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted
-   using the subsession key from the authenticator in the AP-REQ. The
-   authenticator MUST contain a subsession key. The timestamp and usec
-   fields of the KRB-PRIV message MUST be present, and the data values
-   MUST be copies of the same data values from the authenticator. The
-   recipient should ignore the sender address field in the KRB-PRIV
-   message.
-
-   The user-data component of the message contains the DER encoding of
-   the ChangePasswdData ASN.1 type described below:
-
-    ChangePasswdData ::=  SEQUENCE {
-                        passwds [0]          PasswordSequence OPTIONAL,
-                        keys [1]             KeySequences OPTIONAL,
-                          -- exactly one of the above two will be
-                          -- present, else KRB5_KPASSWD_MALFORMED
-                          -- error will be returned by the server.
-                        targname[2]          PrincipalName OPTIONAL,
-                          -- only present in set password/key: the
-                          -- principal which will have its password
-                          -- or keys set. Not present in a set request
-                          -- if the client principal from the ticket is
-                          -- the principal having its passwords or keys
-                          -- set.
-                        targrealm[3]         Realm OPTIONAL,
-                          -- only present in set password/key: the realm
-                          -- for the principal which will have its
-                          -- password or keys set. Not present in a set
-                          -- request if the client principal from the
-                          -- ticket is the principal having its
-                          -- passwords or keys set.
-                        flags[4]             RequestFlags OPTIONAL
-                          -- 32 bit string
-                        }
-
-    KeySequences ::= SEQUENCE (SIZE (1..MAX)) OF KeySequence
-
-    KeySequence ::= SEQUENCE {
-                     key[0]        EncryptionKey,
-                     salt[1]       OCTET STRING OPTIONAL,
-                           -- depends on enc type, not currently used
-                     salt-type[2]  INTEGER OPTIONAL
-                           -- depends on enc type, not currently used
-    }
-
-    PasswordSequence ::= SEQUENCE {
-                        newpasswd[0]  OCTET STRING,
-                        oldpasswd[1]  OCTET STRING OPTIONAL
-
-
-
-Trostle, Swift, Brezak, Gossman                                 [Page 6]
-
-INTERNET DRAFT                 June 2001           Expires December 2001
-
-
-                          -- oldpasswd always present for change
-                          -- password but not present for set
-                          -- password, set key, or change key
-                          -- NOTE: the passwords are UTF8 strings.
-    }
-
-    RequestFlags ::= BIT STRING (SIZE (32..MAX))
-                      -- reserved(0)
-                      -- request-srv-gen-keys(1)
-                           -- only in change/set keys
-                           -- if the client desires
-                           -- server to contribute to
-                           -- keys;
-                           -- server will return keys
-
-
-   The server must verify the AP-REQ message, check whether the client
-   principal in the ticket is authorized to set/change the password/keys
-   (either for that principal, or for the principal in the targname
-   field if present), and decrypt the new password/keys. The server also
-   checks whether the initial flag is required for this request,
-   replying with status 0x0007 if it is not set and should be. An
-   authorization failure is cause to respond with status 0x0005. For
-   forward compatibility, the server should be prepared to ignore fields
-   after targrealm in the structure that it does not understand.
-
-   If the passwds field is present, it contains the new cleartext
-   password (with the old cleartext password for a change password
-   operation). Otherwise the keys field is present, and it contains a
-   sequence of encryption keys.
-
-   In the cleartext password case, if the old password is sent in the
-   request, the request MUST be a change password request. If the old
-   password is not present in the request, the request MUST be a set
-   password request. The server should apply policy checks to the old
-   and new password after verifying that the old password is valid. The
-   server can check validity by obtaining a key from the old password
-   with a keytype that is present in the KDC database for the user and
-   comparing the keys for equality. The server then generates the
-   appropriate keytypes from the password and stores them in the KDC
-   database. If all goes well, status 0x0000 is returned to the client
-   in the reply message (see below). For a change password operation,
-   the initial flag in the service ticket MUST be set.
-
-   In the key sequence case, the sequence of keys is sent to the change
-   or set password service (kadmin/changepw or kadmin/setpw
-   respectively). For a principal that can act as a server, its
-   preferred keytype should be sent as the first key in the sequence,
-   but the KDC is not required to honor this preference. Application
-   servers SHOULD use the key sequence option for changing/setting their
-   keys. The change/set password services should check that all keys are
-   in the proper format, returning the KRB5_KPASSWD_MALFORMED error
-   otherwise.
-
-
-
-
-Trostle, Swift, Brezak, Gossman                                 [Page 7]
-
-INTERNET DRAFT                 June 2001           Expires December 2001
-
-
-   For change/set key, the request message may include the request flags
-   bit string with the request-srv-gen-keys bit set. In this case, the
-   client is requesting that the server add entropy to its keys in the
-   KeySequences field. When using this option, the client SHOULD attempt
-   to generate pseudorandom keys with as much entropy as possible in its
-   request. The server will return the final key sequence in a
-   KeySequences structure in the edata of the reply message. The server
-   does not store any of the new keys at this point. The client MUST
-   make a subsequent change/set key request without the request-srv-
-   gen-keys bit; if the server returns KRB5_KPASSWD_SUCCESS for this
-   second request, then the new keys have been written into the
-   database. A conformant server MUST support this option.
-
-
-
-
-
-
-
-   Reply Message
-
-        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
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |         message length        |    protocol version number    |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |          AP-REP length        |         AP-REP data           /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       /                          KRB-PRIV message                     /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   All 16 bit fields are in network byte order.
-
-   message length field: contains the number of bytes in the message
-   including this field.
-
-   protocol version number: contains the hex constant 0x0002 (network
-   byte order). (The reply message has the same format as in the
-   original Kerberos change password protocol).
-
-   AP-REP length: length of AP-REP data, in bytes. If the length is
-   zero, then the last field contains a KRB-ERROR message instead of a
-   KRB-PRIV message. An implementation should check this field to
-   determine whether a KRB-ERROR message or KRB-PRIV message has been
-   returned.
-
-   AP-REP data: the AP-REP is the response to the AP-REQ in the request
-   packet. The subkey MUST be present in the AP-REP message.
-
-   KRB-PRIV message: This KRB-PRIV message must be encrypted using the
-   subkey from the AP-REP message. The client should ignore the sender
-   address (the server's address) in the KRB-PRIV message. Reflection
-   attacks are prevented since the subkey is used to encrypt the user-
-   data field of the KRB-PRIV message. The timestamp and usec fields of
-
-
-
-Trostle, Swift, Brezak, Gossman                                 [Page 8]
-
-INTERNET DRAFT                 June 2001           Expires December 2001
-
-
-   the KRB-PRIV message MUST be present, and the data values MUST be
-   copies of the same data values from the AP-REP message.
-
-   The server will respond with a KRB-PRIV message unless it cannot
-   validate the client AP-REQ or KRB-PRIV message, in which case it will
-   respond with a KRB-ERROR message.
-
-   The user-data component of the KRB-PRIV message, or e-data component
-   of the KRB-ERROR message, must consist of the following data.
-
-        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
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |          result code          | key version (only on success) |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |     result string length      |         result string         /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                             edata                             /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-       result code (16 bits) (result codes 0-4 are the same as in the
-       original Kerberos change password protocol):
-
-       The result code must have one of the following values (network
-       byte order):
-
-       KRB5_KPASSWD_SUCCESS            0 request succeeds (This
-                                         value is not allowed in a
-                                         KRB-ERROR message)
-
-       KRB5_KPASSWD_MALFORMED          1 request fails due to being
-                                         malformed
-
-       KRB5_KPASSWD_HARDERROR          2 request fails due to "hard"
-                                         error in processing the
-                                         request (for example, there
-                                         is a resource or other
-                                         problem causing the request
-                                         to fail)
-
-       KRB5_KPASSWD_AUTHERROR          3 request fails due to an
-                                         error in authentication
-                                         processing
-
-       KRB5_KPASSWD_SOFTERROR          4 request fails due to a soft
-                                         error in processing the
-                                         request
-
-       KRB5_KPASSWD_ACCESSDENIED       5 requestor not authorized
-
-       KRB5_KPASSWD_BAD_VERSION        6 protocol version unsupported
-
-       KRB5_KPASSWD_INITIALFLAG_NEEDED 7 initial flag required
-
-
-
-
-Trostle, Swift, Brezak, Gossman                                 [Page 9]
-
-INTERNET DRAFT                 June 2001           Expires December 2001
-
-
-       KRB5_KPASSWD_POLICY_REJECT      8 new cleartext password fails
-                                         policy; the result string
-                                         should include a text
-                                         message to be presented to
-                                         the user.
-
-       KRB5_KPASSWD_WRONG_SRV          9 policy failure: the client
-                                         sent change/set key and
-                                         should have sent change/set
-                                         passwd, or vice-versa.
-
-       KRB5_KPASSWD_BAD_PRINCIPAL     10 target principal does not
-                                         exist (only in response to
-                                         a set password or set key
-                                         request).
-
-       KRB5_KPASSWD_ETYPE_NOSUPP 11 the request contains a key sequence
-                                    containing at least one etype that
-                                    is not supported by the KDC. The
-                                    response edata contains an ASN.1
-                                    DER encoded PKERB-ETYPE-INFO type
-                                    that specifies the etypes that the
-                                    KDC supports:
-
-                                    KERB-ETYPE-INFO-ENTRY :: = SEQUENCE
-                                    {
-                                         encryption-type[0]  INTEGER,
-                                         salt[1]        OCTET STRING
-                                           OPTIONAL -- not sent, client
-                                                    -- may ignore if
-                                                    -- sent
-                                    }
-
-                                    PKERB-ETYPE-INFO ::= SEQUENCE OF
-                                                  KERB-ETYPE-INFO-ENTRY
-
-                                    The client should retry the request
-                                    using only etypes (keytypes) that
-                                    are contained within the
-                                    PKERB-ETYPE-INFO structure in the
-                                    previous response.
-
-       KRB5_KPASSWD_ETYPE_SRVGENKEYS 12 See the following paragraph.
-
-
-       The KRB5_KPASSWD_ETYPE_SRVGENKEYS result code is returned when
-       the request has the request-srv-gen-keys flag set and the
-       server is returning the KeySequences structure defined above in
-       the edata field of the reply. The server returns one key sequence
-       structure of the same keytype for each key sequence structure in
-       the client request, unless it does not support one of the
-       keytypes (or etypes). In that case, it returns error
-       KRB5_KPASSWD_ETYPE_NOSUPP as discussed above. The server MUST
-       add keylength number of bits of entropy to each key, where
-
-
-
-Trostle, Swift, Brezak, Gossman                                [Page 10]
-
-INTERNET DRAFT                 June 2001           Expires December 2001
-
-
-       keylength is the number of actual key bits in the key (minus
-       any parity or non-entropy contributing bits). The assumption
-       here is that the client may have added insufficient entropy
-       to the request keys. The server SHOULD use the client key from
-       each KeySequence structure as input into the final keyvalue for
-       the returned key. The client MUST make another request after
-       receiving a reply with this status, since no keys have been
-       written into the database.
-
-       0xFFFF is returned if the request fails for some other reason.
-       The client must interpret any non-zero result code as a failure.
-
-       key version (16 bits - optional):
-       Present if and only if the result
-       code is KRB5_KPASSWD_SUCCESS. This contains the key version of
-       the new key(s).
-
-       result string length (16 bits):
-       Gives the length of the following result string field, in bytes.
-       If the result string is not present, the length is zero.
-
-       result string (optional):
-       This field is a UTF-8 encoded string which can be displayed
-       to the user. Specific reasons for a password set/change policy
-       failure is one possible use for this string.
-
-       edata (optional):
-       Used to convey additional information as defined by the
-       result code.
-
-5.  Acknowledgements
-
-   The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony
-   Andrea, Nicolas Williams, and other participants from the IETF
-   Kerberos Working Group for their input to the document.
-
-6.  Security Considerations
-
-   Password policies should be enforced to make sure that users do not
-   pick passwords (for change password/key) that are vulnerable to brute
-   force password guessing attacks.
-
-7.  References
-
-   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
-       9, RFC 2026, October 1996.
-
-   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
-       Levels", BCP 14, RFC 2119, March 1997
-
-   [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
-       Service (V5), Request for Comments 1510.
-
-
-
-
-
-Trostle, Swift, Brezak, Gossman                                [Page 11]
-
-INTERNET DRAFT                 June 2001           Expires December 2001
-
-
-8. Expiration Date
-
-      This draft expires on December 31st, 2001.
-
-9. Authors' Addresses
-
-      Jonathan Trostle
-      Cisco Systems
-      170 W. Tasman Dr.
-      San Jose, CA 95134
-      Email: jtrostle@cisco.com
-
-      Mike Swift
-      University of Washington
-      Seattle, WA
-      Email: mikesw@cs.washington.edu
-
-      John Brezak
-      Microsoft
-      1 Microsoft Way
-      Redmond, WA 98052
-      Email: jbrezak@microsoft.com
-
-      Bill Gossman
-      Cisco Systems
-      500 108th Ave. NE, Suite 500
-      Bellevue, WA 98004
-      Email: bgossman@cisco.com
-
-10. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implmentation may be prepared, copied, published and
-   distributed, in whole or in part, without restriction of any kind,
-   provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Trostle, Swift, Brezak, Gossman                                [Page 12]
-
-INTERNET DRAFT                 June 2001           Expires December 2001
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Trostle, Swift, Brezak, Gossman                                [Page 13]
-
diff --git a/doc/standardisation/draft-ietf-cat-krb-dns-locate-00.txt b/doc/standardisation/draft-ietf-cat-krb-dns-locate-00.txt
deleted file mode 100644
index e76a0e402..000000000
--- a/doc/standardisation/draft-ietf-cat-krb-dns-locate-00.txt
+++ /dev/null
@@ -1,250 +0,0 @@
-INTERNET-DRAFT                                             Ken Hornstein
-<draft-ietf-cat-krb-dns-locate-00.txt>                               NRL
-June 21, 1999                                             Jeffrey Altman
-Expires: December 21, 1999                           Columbia University
-
-          Distributing Kerberos KDC and Realm Information with DNS
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   Distribution of this memo is unlimited.  It is filed as <draft-ietf-
-   cat-krb-dns-locate-00.txt>, and expires on December 21, 1999.  Please
-   send comments to the authors.
-
-Abstract
-
-   Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto-
-   col [RFC????] describe any mechanism for clients to learn critical
-   configuration information necessary for proper operation of the pro-
-   tocol.  Such information includes the location of Kerberos key dis-
-   tribution centers or a mapping between DNS domains and Kerberos
-   realms.
-
-   Current Kerberos implementations generally store such configuration
-   information in a file on each client machine.  Experience has shown
-   this method of storing configuration information presents problems
-   with out-of-date information and scaling problems, especially when
-
-Hornstein, Altman                                               [Page 1]
-
-RFC DRAFT                                                  June 21, 1999
-
-   using cross-realm authentication.
-
-   This memo describes a method for using the Domain Name System
-   [RFC1035] for storing such configuration information.  Specifically,
-   methods for storing KDC location and hostname/domain name to realm
-   mapping information are discussed.
-
-Overview - KDC location information
-
-   KDC location information is to be stored using the DNS SRV RR [RFC
-   2052].  The format of this RR is as follows:
-
-   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
-
-   The Service name for Kerberos is always "_kerberos".
-
-   The Proto can be either "_udp" or "_tcp".  If these records are to be
-   used, a "_udp" record MUST be included.  If the Kerberos implementa-
-   tion supports TCP transport, a "_tcp" record SHOULD be included.
-
-   The Realm is the Kerberos realm that this record corresponds to.
-
-   TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
-   meaning as defined in RFC 2052.
-
-Example - KDC location information
-
-   These are DNS records for a Kerberos realm ASDF.COM.  It has two Ker-
-   beros servers, kdc1.asdf.com and kdc2.asdf.com.  Queries should be
-   directed to kdc1.asdf.com first as per the specified priority.
-   Weights are not used in these records.
-
-   _kerberos._udp.ASDF.COM.        IN      SRV     0 0 88 kdc1.asdf.com.
-   _kerberos._udp.ASDF.COM.        IN      SRV     1 0 88 kdc2.asdf.com.
-
-Overview - KAdmin location information
-
-   Kadmin location information is to be stored using the DNS SRV RR [RFC
-   2052].  The format of this RR is as follows:
-
-   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
-
-   The Service name for Kadmin is always "_kadmin".
-
-   The Proto can be either "_udp" or "_tcp".  If these records are to be
-   used, a "_tcp" record MUST be included.  If the Kadmin implementation
-   supports UDP transport, a "_udp" record SHOULD be included.
-
-Hornstein, Altman                                               [Page 2]
-
-RFC DRAFT                                                  June 21, 1999
-
-   The Realm is the Kerberos realm that this record corresponds to.
-
-   TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
-   meaning as defined in RFC 2052.
-
-Example - Kadmin location information
-
-   These are DNS records for a Kerberos realm ASDF.COM.  It has one Kad-
-   min server, kdc1.asdf.com.
-
-   _kadmin._tcp.ASDF.COM.  IN      SRV     0 0 88 kdc1.asdf.com.
-
-Overview - Hostname/domain name to Kerberos realm mapping
-
-   Information on the mapping of DNS hostnames and domain names to Ker-
-   beros realms is stored using DNS TXT records [RFC 1035].  These
-   records have the following format.
-
-   Service.Name TTL Class TXT Realm
-
-   The Service field is always "_kerberos", and prefixes all entries of
-   this type.
-
-   The Name is a DNS hostname or domain name.  This is explained in
-   greater detail below.
-
-   TTL, Class, and TXT have the standard DNS meaning as defined in RFC
-   1035.
-
-   The Realm is the data for the TXT RR, and consists simply of the Ker-
-   beros realm that corresponds to the Name specified.
-
-   When a Kerberos client wishes to utilize a host-specific service, it
-   will perform a DNS TXT query, using the hostname in the Name field of
-   the DNS query.  If the record is not found, the first label of the
-   name is stripped and the query is retried.
-
-   Compliant implementations MUST query the full hostname and the most
-   specific domain name (the hostname with the first label removed).
-   Compliant implementations SHOULD try stripping all subsequent labels
-   until a match is found or the Name field is empty.
-
-Example - Hostname/domain name to Kerberos realm mapping
-
-   For the previously mentioned ASDF.COM realm and domain, some sample
-   records might be as follows:
-
-   _kerberos.asdf.com.             IN      TXT     "ASDF.COM"
-
-Hornstein, Altman                                               [Page 3]
-
-RFC DRAFT                                                  June 21, 1999
-
-   _kerberos.mrkserver.asdf.com.   IN      TXT     "MARKETING.ASDF.COM"
-   _kerberos.salesserver.asdf.com. IN      TXT     "SALES.ASDF.COM"
-
-   Let us suppose that in this case, a Kerberos client wishes to use a
-   Kerberized service on the host foo.asdf.com.  It would first query:
-
-   _kerberos.foo.asdf.com. IN TXT
-
-   Finding no match, it would then query:
-
-   _kerberos.asdf.com. IN TXT
-
-   And find an answer of ASDF.COM.  This would be the realm that
-   foo.asdf.com resides in.
-
-   If another Kerberos client wishes to use a Kerberized service on the
-   host salesserver.asdf.com, it would query:
-
-   _kerberos.salesserver.asdf.com IN TXT
-
-   And find an answer of SALES.ASDF.COM.
-
-Security considerations
-
-   As DNS is deployed today, it is an unsecure service.  Thus the infor-
-   mation returned by it cannot be trusted.  However, the use of DNS to
-   store this configuration information does not introduce any new secu-
-   rity risks to the Kerberos protocol.
-
-   Current practice is to use hostnames to indicate KDC hosts (stored in
-   some implementation-dependent location, but generally a local config
-   file).  These hostnames are vulnerable to the standard set of DNS
-   attacks (denial of service, spoofed entries, etc).  The design of the
-   Kerberos protocol limits attacks of this sort to denial of service.
-   However, the use of SRV records does not change this attack in any
-   way.  They have the same vulnerabilities that already exist in the
-   common practice of using hostnames for KDC locations.
-
-   The same holds true for the TXT records used to indicate the domain
-   name to realm mapping.  Current practice is to configure these map-
-   pings locally.  But this again is vulnerable to spoofing via CNAME
-   records that point to hosts in other domains.  This has the same
-   effect as a spoofed TXT record.
-
-   While the described protocol does not introduce any new security
-   risks to the best of our knowledge, implementations SHOULD provide a
-   way of specifying this information locally without the use of DNS.
-   However, to make this feature worthwhile a lack of any configuration
-
-Hornstein, Altman                                               [Page 4]
-
-RFC DRAFT                                                  June 21, 1999
-
-   information on a client should be interpretted as permission to use
-   DNS.
-
-Expiration
-
-   This Internet-Draft expires on December 21, 1999.
-
-References
-
-   [RFC1510]
-        The Kerberos Network Authentication System; Kohl, Newman; Sep-
-        tember 1993.
-
-   [RFC1035]
-        Domain Names - Implementation and Specification; Mockapetris;
-        November 1987
-
-   [RFC2052]
-        A DNS RR for specifying the location of services (DNS SRV); Gul-
-        brandsen, Vixie; October 1996
-
-Authors' Addresses
-
-   Ken Hornstein
-   US Naval Research Laboratory
-   Bldg A-49, Room 2
-   4555 Overlook Avenue
-   Washington DC  20375 USA
-
-   Phone: +1 (202) 404-4765
-   EMail: kenh@cmf.nrl.navy.mil
-
-   Jeffrey Altman
-   The Kermit Project
-   Columbia University
-   612 West 115th Street #716
-   New York NY 10025-7799 USA
-
-   Phone: +1 (212) 854-1344
-   EMail: jaltman@columbia.edu
-
-Hornstein, Altman                                               [Page 5]
diff --git a/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt b/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt
deleted file mode 100644
index bd31750a1..000000000
--- a/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                             Ken Hornstein
-<draft-ietf-cat-krb-dns-locate-02.txt>                               NRL
-March 10, 2000                                            Jeffrey Altman
-Expires: September 10, 2000                          Columbia University
-
-
-
-          Distributing Kerberos KDC and Realm Information with DNS
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   Distribution of this memo is unlimited.  It is filed as <draft-ietf-
-   cat-krb-dns-locate-02.txt>, and expires on September 10, 2000.  Please
-   send comments to the authors.
-
-Abstract
-
-   Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto-
-   col [RFC????] describe any mechanism for clients to learn critical
-   configuration information necessary for proper operation of the pro-
-   tocol.  Such information includes the location of Kerberos key dis-
-   tribution centers or a mapping between DNS domains and Kerberos
-   realms.
-
-   Current Kerberos implementations generally store such configuration
-   information in a file on each client machine.  Experience has shown
-   this method of storing configuration information presents problems
-   with out-of-date information and scaling problems, especially when
-
-
-
-Hornstein, Altman                                               [Page 1]
-
-RFC DRAFT                                                 March 10, 2000
-
-
-   using cross-realm authentication.
-
-   This memo describes a method for using the Domain Name System
-   [RFC1035] for storing such configuration information.  Specifically,
-   methods for storing KDC location and hostname/domain name to realm
-   mapping information are discussed.
-
-DNS vs. Kerberos - Case Sensitivity of Realm Names
-
-   In Kerberos, realm names are case sensitive.  While it is strongly
-   encouraged that all realm names be all upper case this recommendation
-   has not been adopted by all sites.  Some sites use all lower case
-   names and other use mixed case.  DNS on the other hand is case insen-
-   sitive for queries but is case preserving for responses to TXT
-   queries.  Since "MYREALM", "myrealm", and "MyRealm" are all different
-   it is necessary that the DNS entries be distinguishable.
-
-   Since the recommend realm names are all upper case, we will not
-   require any quoting to be applied to upper case names.  If the realm
-   name contains lower case characters each character is to be quoted by
-   a '=' character.  So "MyRealm" would be represented as "M=yR=e=a=l=m"
-   and "myrealm" as "=m=y=r=e=a=l=m".  If the realm name contains the
-   '=' character it will be represented as "==".
-
-
-Overview - KDC location information
-
-   KDC location information is to be stored using the DNS SRV RR [RFC
-   2052].  The format of this RR is as follows:
-
-   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
-
-   The Service name for Kerberos is always "_kerberos".
-
-   The Proto can be either "_udp" or "_tcp".  If these records are to be
-   used, a "_udp" record MUST be included.  If the Kerberos implementa-
-   tion supports TCP transport, a "_tcp" record SHOULD be included.
-
-   The Realm is the Kerberos realm that this record corresponds to.
-
-   TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
-   meaning as defined in RFC 2052.
-
-Example - KDC location information
-
-   These are DNS records for a Kerberos realm ASDF.COM.  It has two Ker-
-   beros servers, kdc1.asdf.com and kdc2.asdf.com.  Queries should be
-   directed to kdc1.asdf.com first as per the specified priority.
-
-
-
-Hornstein, Altman                                               [Page 2]
-
-RFC DRAFT                                                 March 10, 2000
-
-
-   Weights are not used in these records.
-
-   _kerberos._udp.ASDF.COM.        IN      SRV     0 0 88 kdc1.asdf.com.
-   _kerberos._udp.ASDF.COM.        IN      SRV     1 0 88 kdc2.asdf.com.
-
-Overview - Kerberos password changing server location information
-
-   Kerberos password changing server [KERB-CHG] location is to be stored
-   using the DNS SRV RR [RFC 2052].  The format of this RR is as fol-
-   lows:
-
-   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
-
-   The Service name for the password server is always "_kpasswd".
-
-   The Proto MUST be "_udp".
-
-   The Realm is the Kerberos realm that this record corresponds to.
-
-   TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
-   meaning as defined in RFC 2052.
-
-Overview - Kerberos admin server location information
-
-   Kerberos admin location information is to be stored using the DNS SRV
-   RR [RFC 2052].  The format of this RR is as follows:
-
-   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
-
-   The Service name for the admin server is always "_kerberos-adm".
-
-   The Proto can be either "_udp" or "_tcp".  If these records are to be
-   used, a "_tcp" record MUST be included.  If the Kerberos admin imple-
-   mentation supports UDP transport, a "_udp" record SHOULD be included.
-
-   The Realm is the Kerberos realm that this record corresponds to.
-
-   TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
-   meaning as defined in RFC 2052.
-
-   Note that there is no formal definition of a Kerberos admin protocol,
-   so the use of this record is optional and implementation-dependent.
-
-Example - Kerberos administrative server location information
-
-   These are DNS records for a Kerberos realm ASDF.COM.  It has one
-   administrative server, kdc1.asdf.com.
-
-
-
-
-Hornstein, Altman                                               [Page 3]
-
-RFC DRAFT                                                 March 10, 2000
-
-
-   _kerberos-adm._tcp.ASDF.COM.    IN      SRV     0 0 88 kdc1.asdf.com.
-
-Overview - Hostname/domain name to Kerberos realm mapping
-
-   Information on the mapping of DNS hostnames and domain names to Ker-
-   beros realms is stored using DNS TXT records [RFC 1035].  These
-   records have the following format.
-
-   Service.Name TTL Class TXT Realm
-
-   The Service field is always "_kerberos", and prefixes all entries of
-   this type.
-
-   The Name is a DNS hostname or domain name.  This is explained in
-   greater detail below.
-
-   TTL, Class, and TXT have the standard DNS meaning as defined in RFC
-   1035.
-
-   The Realm is the data for the TXT RR, and consists simply of the Ker-
-   beros realm that corresponds to the Name specified.
-
-   When a Kerberos client wishes to utilize a host-specific service, it
-   will perform a DNS TXT query, using the hostname in the Name field of
-   the DNS query.  If the record is not found, the first label of the
-   name is stripped and the query is retried.
-
-   Compliant implementations MUST query the full hostname and the most
-   specific domain name (the hostname with the first label removed).
-   Compliant implementations SHOULD try stripping all subsequent labels
-   until a match is found or the Name field is empty.
-
-Example - Hostname/domain name to Kerberos realm mapping
-
-   For the previously mentioned ASDF.COM realm and domain, some sample
-   records might be as follows:
-
-   _kerberos.asdf.com.             IN      TXT     "ASDF.COM"
-   _kerberos.mrkserver.asdf.com.   IN      TXT     "MARKETING.ASDF.COM"
-   _kerberos.salesserver.asdf.com. IN      TXT     "SALES.ASDF.COM"
-
-   Let us suppose that in this case, a Kerberos client wishes to use a
-   Kerberized service on the host foo.asdf.com.  It would first query:
-
-   _kerberos.foo.asdf.com. IN TXT
-
-   Finding no match, it would then query:
-
-
-
-
-Hornstein, Altman                                               [Page 4]
-
-RFC DRAFT                                                 March 10, 2000
-
-
-   _kerberos.asdf.com. IN TXT
-
-   And find an answer of ASDF.COM.  This would be the realm that
-   foo.asdf.com resides in.
-
-   If another Kerberos client wishes to use a Kerberized service on the
-   host salesserver.asdf.com, it would query:
-
-   _kerberos.salesserver.asdf.com IN TXT
-
-   And find an answer of SALES.ASDF.COM.
-
-Security considerations
-
-   As DNS is deployed today, it is an unsecure service.  Thus the infor-
-   mation returned by it cannot be trusted.
-
-   Current practice for REALM to KDC mapping is to use hostnames to
-   indicate KDC hosts (stored in some implementation-dependent location,
-   but generally a local config file).  These hostnames are vulnerable
-   to the standard set of DNS attacks (denial of service, spoofed
-   entries, etc).  The design of the Kerberos protocol limits attacks of
-   this sort to denial of service.  However, the use of SRV records does
-   not change this attack in any way.  They have the same vulnerabili-
-   ties that already exist in the common practice of using hostnames for
-   KDC locations.
-
-   Current practice for HOSTNAME to REALM mapping is to provide a local
-   configuration of mappings of hostname or domain name to realm which
-   are then mapped to KDCs.  But this again is vulnerable to spoofing
-   via CNAME records that point to hosts in other domains.  This has the
-   same effect as when a TXT record is spoofed.  In a realm with no
-   cross-realm trusts this is a DoS attack.  However, when cross-realm
-   trusts are used it is possible to redirect a client to use a comprom-
-   ised realm.
-
-   This is not an exploit of the Kerberos protocol but of the Kerberos
-   trust model.  The same can be done to any application that must
-   resolve the hostname in order to determine which domain a non-FQDN
-   belongs to.
-
-   Implementations SHOULD provide a way of specifying this information
-   locally without the use of DNS.  However, to make this feature
-   worthwhile a lack of any configuration information on a client should
-   be interpretted as permission to use DNS.
-
-
-
-
-
-
-Hornstein, Altman                                               [Page 5]
-
-RFC DRAFT                                                 March 10, 2000
-
-
-Expiration
-
-   This Internet-Draft expires on September 10, 2000.
-
-References
-
-
-   [RFC1510]
-        The Kerberos Network Authentication System; Kohl, Newman; Sep-
-        tember 1993.
-
-   [RFC1035]
-        Domain Names - Implementation and Specification; Mockapetris;
-        November 1987
-
-   [RFC2782]
-        A DNS RR for specifying the location of services (DNS SRV); Gul-
-        brandsen, Vixie; Feburary 2000
-
-   [KERB-CHG]
-        Kerberos Change Password Protocol; Horowitz;
-        ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-
-        password-02.txt
-
-Authors' Addresses
-
-   Ken Hornstein
-   US Naval Research Laboratory
-   Bldg A-49, Room 2
-   4555 Overlook Avenue
-   Washington DC  20375 USA
-
-   Phone: +1 (202) 404-4765
-   EMail: kenh@cmf.nrl.navy.mil
-
-   Jeffrey Altman
-   The Kermit Project
-   Columbia University
-   612 West 115th Street #716
-   New York NY 10025-7799 USA
-
-   Phone: +1 (212) 854-1344
-   EMail: jaltman@columbia.edu
-
-
-
-
-
-
-
-
-Hornstein, Altman                                               [Page 6]
-
diff --git a/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt b/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt
deleted file mode 100644
index 11e5dc9f9..000000000
--- a/doc/standardisation/draft-ietf-cat-krb5gss-mech2-03.txt
+++ /dev/null
@@ -1,1333 +0,0 @@
-
-INTERNET-DRAFT                                                    Tom Yu
-Common Authentication Technology WG                                  MIT
-draft-ietf-cat-krb5gss-mech2-03.txt                        04 March 2000
-
-           The Kerberos Version 5 GSSAPI Mechanism, Version 2
-
-Status of This Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   Comments on this document should be sent to
-   "ietf-cat-wg@lists.stanford.edu", the IETF Common Authentication
-   Technology WG discussion list.
-
-Abstract
-
-   This document defines protocols, procedures, and conventions to be
-   employed by peers implementing the Generic Security Service
-   Application Program Interface (as specified in RFC 2743) 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.
-
-Table of Contents
-
-   Status of This Memo ............................................    1
-   Abstract .......................................................    1
-   Acknowledgements ...............................................    1
-   Table of Contents ..............................................    1
-   1.  Introduction ...............................................    3
-   2.  Token Formats ..............................................    3
-      2.1.  Packet Notation .......................................    3
-
-Yu                  Document Expiration: 04 Sep 2000            [Page 1]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-      2.2.  Mechanism OID .........................................    4
-      2.3.  Context Establishment .................................    4
-         2.3.1.  Option Format ....................................    4
-            2.3.1.1.  Delegated Credentials Option ................    5
-            2.3.1.2.  Null Option .................................    5
-         2.3.2.  Initial Token ....................................    6
-            2.3.2.1.  Data to be Checksummed in APREQ .............    8
-         2.3.3.  Response Token ...................................   10
-      2.4.  Per-message Tokens ....................................   12
-         2.4.1.  Sequence Number Usage ............................   12
-         2.4.2.  MIC Token ........................................   12
-            2.4.2.1.  Data to be Checksummed in MIC Token .........   13
-         2.4.3.  Wrap Token .......................................   14
-            2.4.3.1.  Wrap Token With Integrity Only ..............   14
-            2.4.3.2.  Wrap Token With Integrity and Encryption
-                      .............................................   15
-               2.4.3.2.1.  Data to be Encrypted in Wrap Token .....   16
-   3.  ASN.1 Encoding of Octet Strings ............................   17
-   4.  Name Types .................................................   18
-      4.1.  Mandatory Name Forms ..................................   18
-         4.1.1.  Kerberos Principal Name Form .....................   18
-         4.1.2.  Exported Name Object Form for Kerberos5
-                 Mechanism ........................................   19
-   5.  Credentials ................................................   20
-   6.  Parameter Definitions ......................................   20
-      6.1.  Minor Status Codes ....................................   20
-         6.1.1.  Non-Kerberos-specific codes ......................   21
-         6.1.2.  Kerberos-specific-codes ..........................   21
-   7.  Kerberos Protocol Dependencies .............................   22
-   8.  Security Considerations ....................................   22
-   9.  References .................................................   22
-   10.  Author's Address ..........................................   23
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                  Document Expiration: 04 Sep 2000            [Page 2]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-1.  Introduction
-
-   The original Kerberos 5 GSSAPI mechanism[RFC1964] has a number of
-   shortcomings.  This document attempts to remedy them by defining a
-   completely new Kerberos 5 GSSAPI mechanism.
-
-   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.  This is implemented by a special checksum
-   algorithm whose purpose is to copy the input data directly into the
-   checksum field of the authenticator.
-
-   The number assignments for checksum algorithms and for encryption
-   types are inconsistent between the Kerberos protocol and the original
-   GSSAPI mechanism.  If new encryption or checksum algorithms are added
-   to the Kerberos protocol at some point, the GSSAPI mechanism will
-   need to be separately updated to use these new algorithms.
-
-   The original mechanism specifies a crude method of key derivation (by
-   using the XOR of the context key with a fixed constant), which is
-   incompatible with newer cryptosystems which specify key derivation
-   procedures themselves.  The original mechanism also assumes that both
-   checksums and cryptosystem blocksizes are eight bytes.
-
-   Defining all GSSAPI tokens for the new Kerberos 5 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 2743 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.
-
-   One 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 handling of
-   full ASN.1 encoding may be cumbersome.  Also, due to the poor
-   availability of the relevant standards documents, ASN.1 encoders and
-   decoders are difficult to implement completely correctly, so keeping
-   ASN.1 usage to a minimum decreases the probability of bugs in the
-   implementation of the mechanism.  In particular, bit strings need to
-   be transferred at certain points in this mechanism.  There are many
-   conflicting common misunderstandings of how to encode and decode
-   ASN.1 bit strings, which have led difficulties in the implementaion
-   of the Kerberos protocol.
-
-
-
-
-
-Yu                  Document Expiration: 04 Sep 2000            [Page 3]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-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.
-
-   Numbers prefixed by the characters "0x" are in hexadecimal notation,
-   as in the C programming language.  Even though packet diagrams are
-   drawn 16 bits wide, no padding should be used to align the ends of
-   variable-length fields to a 32-bit or 16-bit boundary.
-
-   All integer fields are in network byte order.  All other fields have
-   the size shown in the diagrams, with the exception of variable length
-   fields.
-
-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:
-
-  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
-byte +-------------------------------+-------------------------------+
-  0  |                          option type                          |
-     +-------------------------------+-------------------------------+
-  2  |                                                               |
-     +--                  option length (32 bits)                  --+
-  4  |                                                               |
-     +-------------------------------+-------------------------------+
-  6  |                               .                               |
-     /                 option data (variable length)                 /
-     |                               .                               |
-     +-------------------------------+-------------------------------+
-
-
-
-
-Yu                  Document Expiration: 04 Sep 2000            [Page 4]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-   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 |
-byte +-------------------------------+-------------------------------+
-  0  |                     option type = 0x00001                     |
-     +-------------------------------+-------------------------------+
-  2  |                                                               |
-     +--                      KRB-CRED length                      --+
-  4  |                                                               |
-     +-------------------------------+-------------------------------+
-  6  |                               .                               |
-     /                        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 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:
-
-
-
-
-Yu                  Document Expiration: 04 Sep 2000            [Page 5]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
-byte +-------------------------------+-------------------------------+
-  0  |                        option type = 0                        |
-     +-------------------------------+-------------------------------+
-  2  |                                                               |
-     +--                         length = 0                        --+
-  4  |                                                               |
-     +-------------------------------+-------------------------------+
-
-
-   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 |
-byte +-------------------------------+-------------------------------+
-  0  |                   initial token id = 0x0101                   |
-     +-------------------------------+-------------------------------+
-  2  |                                                               |
-     +--         reserved flag bits          +-----------------------+
-  4  |                                       | I | C | S | R | M | D |
-     +-------------------------------+-------------------------------+
-  6  |                      checksum type count                      |
-     +-------------------------------+-------------------------------+
-  8  |                               .                               |
-     /                       checksum type list                      /
-     |                               .                               |
-     +-------------------------------+-------------------------------+
-  n  |                               .                               |
-     /                            options                            /
-     |                               .                               |
-     +-------------------------------+-------------------------------+
-  m  |                                                               |
-     +--                       AP-REQ length                       --+
- m+2 |                                                               |
-     +-------------------------------+-------------------------------+
- 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: 04 Sep 2000            [Page 6]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-   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
-
-Yu                  Document Expiration: 04 Sep 2000            [Page 7]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-   that they be of the same type as the associated session key.
-
-   XXX The above is not secure.  There should be an algorithmic process
-   to arrive at a subsession key which both sides of the authentication
-   exchange can perform based on the ticket sessions key and data known
-   to both parties, and this should probably be part of the revised
-   Kerberos protocol rather than bound to the GSSAPI mechanism.
-
-2.3.2.1.  Data to be Checksummed in AP-REQ
-
-   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().
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                  Document Expiration: 04 Sep 2000            [Page 8]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
-byte +-------------------------------+-------------------------------+
-  0  |                                                               |
-     +--                   initiator address type                  --+
-  2  |                                                               |
-     +-------------------------------+-------------------------------+
-  4  |                    initiator address length                   |
-     +-------------------------------+-------------------------------+
-  6  |                               .                               |
-     /                       initiator address                       /
-     |                               .                               |
-     +-------------------------------+-------------------------------+
-  n  |                                                               |
-     +--                   acceptor address type                   --+
-     |                                                               |
-     +-------------------------------+-------------------------------+
- n+4 |                    acceptor address length                    |
-     +-------------------------------+-------------------------------+
- n+6 |                               .                               |
-     /                        acceptor address                       /
-     |                               .                               |
-     +-------------------------------+-------------------------------+
-  m  |                               .                               |
-     /                        application data                       /
-     |                               .                               |
-     +-------------------------------+-------------------------------+
-  k  |                   initial token id = 0x0101                   |
-     +-------------------------------+-------------------------------+
- k+2 |                                                               |
-     +--                           flags                           --+
- k+4 |                                                               |
-     +-------------------------------+-------------------------------+
- k+6 |                      checksum type count                      |
-     +-------------------------------+-------------------------------+
- 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.
-
-   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.
-
-
-Yu                  Document Expiration: 04 Sep 2000            [Page 9]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-   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: 04 Sep 2000           [Page 10]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
-byte +-------------------------------+-------------------------------+
-  0  |                   response token id = 0x0202                  |
-     +-------------------------------+-------------------------------+
-  2  |                                                               |
-     +--                  reserved flag bits                 +-------+
-  4  |                                                       | D | E |
-     +-------------------------------+-------------------------------+
-  6  |                                                               |
-     +--                       checksum type                       --+
-  8  |                                                               |
-     +-------------------------------+-------------------------------+
- 10  |                               .                               |
-     /                            options                            /
-     |                               .                               |
-     +-------------------------------+-------------------------------+
-  n  |                                                               |
-     +--                 AP-REP or KRB-ERROR length                --+
- n+2 |                                                               |
-     +-------------------------------+-------------------------------+
- 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.
-
-
-
-Yu                  Document Expiration: 04 Sep 2000           [Page 11]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-   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
-        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.
-
-
-
-
-
-Yu                  Document Expiration: 04 Sep 2000           [Page 12]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-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:
-
-  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
-byte +-------------------------------+-------------------------------+
-  0  |                     MIC token id = 0x0303                     |
-     +-------------------------------+-------------------------------+
-  2  | D |                                                           |
-     +---+                     sequence number                     --+
-  4  |                                                               |
-     +-------------------------------+-------------------------------+
-  6  |                        checksum length                        |
-     +-------------------------------+-------------------------------+
-  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 in cryptosystems that support key
-        derivation.
-
-   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.
-
-
-
-
-
-Yu                  Document Expiration: 04 Sep 2000           [Page 13]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-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.
-
-  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
-byte +-------------------------------+-------------------------------+
-  0  |                     MIC token id = 0x0303                     |
-     +-------------------------------+-------------------------------+
-  2  | D |                                                           |
-     +---+                     sequence number                     --+
-  4  |                                                               |
-     +-------------------------------+-------------------------------+
-  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
-
-
-
-
-
-
-
-
-
-
-
-Yu                  Document Expiration: 04 Sep 2000           [Page 14]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-  bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
-byte +-------------------------------+-------------------------------+
-  0  |                integrity wrap token id = 0x0404               |
-     +-------------------------------+-------------------------------+
-  2  | D |                                                           |
-     +---+                     sequence number                     --+
-  4  |                                                               |
-     +-------------------------------+-------------------------------+
-  6  |                               .                               |
-     /                        application data                       /
-     |                               .                               |
-     +-------------------------------+-------------------------------+
-  n  |                        checksum length                        |
-     +-------------------------------+-------------------------------+
- n+2 |                               .                               |
-     /                         checksum data                         /
-     |                               .                               |
-     +-------------------------------+-------------------------------+
-
-
-   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 in cryptosystems that support key
-        derivation.
-
-   The mechanism implementation should only use checksum types which it
-   knows to be valid for both peers, as described for MIC tokens.
-
-
-
-
-Yu                  Document Expiration: 04 Sep 2000           [Page 15]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-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 |
-byte +-------------------------------+-------------------------------+
-     |                encrypted wrap token id = 0x0505               |
-     +-------------------------------+-------------------------------+
-  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 in cryptosystems that support
-        key derivation.  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 |
-byte +-------------------------------+-------------------------------+
-  0  | D |                                                           |
-     +---+                     sequence number                     --+
-  2  |                                                               |
-     +-------------------------------+-------------------------------+
-  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
-
-Yu                  Document Expiration: 04 Sep 2000           [Page 16]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-        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
-   ITU-T X.690, 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 of the first octet being the most
-   significant bit.  Thus, the length encoding within is in network byte
-   order.
-
-
-
-Yu                  Document Expiration: 04 Sep 2000           [Page 17]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-   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
-
-   This section discusses the name types which may be passed as input to
-   the Kerberos 5 GSSAPI mechanism's GSS_Import_name() call, and their
-   associated identifier values.  It defines interface elements in
-   support of portability, and assumes use of C language bindings per
-   RFC 2744.  In addition to specifying OID values for name type
-   identifiers, symbolic names are included and recommended to GSSAPI
-   implementors in the interests of convenience to callers.  It is
-   understood that not all implementations of the Kerberos 5 GSSAPI
-   mechanism need support all name types in this list, and that
-   additional name forms will likely be added to this list over time.
-   Further, the definitions of some or all name types may later migrate
-   to other, mechanism-independent, specifications.  The occurrence of a
-   name type in this specification is specifically not intended to
-   suggest that the type may be supported only by an implementation of
-   the Kerberos 5 mechanism.  In particular, the occurrence of the
-   string "_KRB5_" in the symbolic name strings constitutes a means to
-   unambiguously register the name strings, avoiding collision with
-   other documents; it is not meant to limit the name types' usage or
-   applicability.
-
-   For purposes of clarification to GSSAPI implementors, this section's
-   discussion of some name forms describes means through which those
-   forms can be supported with existing Kerberos technology.  These
-   discussions are not intended to preclude alternative implementation
-   strategies for support of the name forms within Kerberos mechanisms
-   or mechanisms based on other technologies.  To enhance application
-   portability, implementors of mechanisms are encouraged to support
-   name forms as defined in this section, even if their mechanisms are
-   independent of Kerberos 5.
-
-4.1.  Mandatory Name Forms
-
-   This section discusses name forms which are to be supported by all
-   conformant implementations of the Kerberos 5 GSSAPI mechanism.
-
-4.1.1.  Kerberos Principal Name Form
-
-   This name form shall be represented by the Object Identifier {iso(1)
-   member-body(2) us(840) mit(113554) infosys(1) gssapi(2) krb5(2)
-   krb5_name(1)}.  The recommended symbolic name for this type is
-   "GSS_KRB5_NT_PRINCIPAL_NAME".
-
-   This name type corresponds to the single-string representation of a
-   Kerberos name.  (Within the MIT Kerberos 5 implementation, such names
-   are parseable with the krb5_parse_name() function.)  The elements
-   included within this name representation are as follows, proceeding
-
-Yu                  Document Expiration: 04 Sep 2000           [Page 18]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-   from the beginning of the string:
-
-        (1) One or more principal name components; if more than one
-        principal name component is included, the components are
-        separated by '/'.  Arbitrary octets may be included within
-        principal name components, with the following constraints and
-        special considerations:
-
-           (1a) Any occurrence of the characters '@' or '/' within a
-           name component must be immediately preceded by the '\'
-           quoting character, to prevent interpretation as a component
-           or realm separator.
-
-           (1b) The ASCII newline, tab, backspace, and null characters
-           may occur directly within the component or may be
-           represented, respectively, by '\n', '\t', '\b', or '\0'.
-
-           (1c) If the '\' quoting character occurs outside the contexts
-           described in (1a) and (1b) above, the following character is
-           interpreted literally.  As a special case, this allows the
-           doubled representation '\\' to represent a single occurrence
-           of the quoting character.
-
-           (1d) An occurrence of the '\' quoting character as the last
-           character of a component is illegal.
-
-        (2) Optionally, a '@' character, signifying that a realm name
-        immediately follows. If no realm name element is included, the
-        local realm name is assumed.  The '/' , ':', and null characters
-        may not occur within a realm name; the '@', newline, tab, and
-        backspace characters may be included using the quoting
-        conventions described in (1a), (1b), and (1c) above.
-
-4.1.2.  Exported Name Object Form for Kerberos 5 Mechanism
-
-   When generated by the Kerberos 5 mechanism, the Mechanism OID within
-   the exportable name shall be that of the original Kerberos 5
-   mechanism[RFC1964].  The Mechanism OID for the original Kerberos 5
-   mechanism is:
-
-   {iso(1) member-body(2) us(840) mit(113554) infosys(1) gssapi(2)
-   krb5(2)}
-
-   The name component within the exportable name shall be a contiguous
-   string with structure as defined for the Kerberos Principal Name
-   Form.
-
-   In order to achieve a distinguished encoding for comparison purposes,
-   the following additional constraints are imposed on the export
-   operation:
-
-        (1) all occurrences of the characters '@', '/', and '\' within
-        principal components or realm names shall be quoted with an
-
-Yu                  Document Expiration: 04 Sep 2000           [Page 19]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-        immediately-preceding '\'.
-
-        (2) all occurrences of the null, backspace, tab, or newline
-        characters within principal components or realm names will be
-        represented, respectively, with '\0', '\b', '\t', or '\n'.
-
-        (3) the '\' quoting character shall not be emitted within an
-        exported name except to accomodate cases (1) and (2).
-
-5.  Credentials
-
-   The Kerberos 5 protocol uses different credentials (in the GSSAPI
-   sense) for initiating and accepting security contexts.  Normal
-   clients receive a ticket-granting ticket (TGT) and an associated
-   session key at "login" time; the pair of a TGT and its corresponding
-   session key forms a credential which is suitable for initiating
-   security contexts.  A ticket-granting ticket, its session key, and
-   any other (ticket, key) pairs obtained through use of the
-   ticket-granting-ticket, are typically stored in a Kerberos 5
-   credentials cache, sometimes known as a ticket file.
-
-   The encryption key used by the Kerberos server to seal tickets for a
-   particular application service forms the credentials suitable for
-   accepting security contexts.  These service keys are typically stored
-   in a Kerberos 5 key table (keytab), or srvtab file (the Kerberos 4
-   terminology).  In addition to their use as accepting credentials,
-   these service keys may also be used to obtain initiating credentials
-   for their service principal.
-
-   The Kerberos 5 mechanism's credential handle may contain references
-   to either or both types of credentials.  It is a local matter how the
-   Kerberos 5 mechanism implementation finds the appropriate Kerberos 5
-   credentials cache or key table.
-
-   However, when the Kerberos 5 mechanism attempts to obtain initiating
-   credentials for a service principal which are not available in a
-   credentials cache, and the key for that service principal is
-   available in a Kerberos 5 key table, the mechanism should use the
-   service key to obtain initiating credentials for that service.  This
-   should be accomplished by requesting a ticket-granting-ticket from
-   the Kerberos Key Distribution Center (KDC), and decrypting the KDC's
-   reply using the service key.
-
-6.  Parameter Definitions
-
-   This section defines parameter values used by the Kerberos V5 GSSAPI
-   mechanism.  It defines interface elements in support of portability,
-   and assumes use of C language bindings per RFC 2744.
-
-6.1.  Minor Status Codes
-
-   This section recommends common symbolic names for minor_status values
-   to be returned by the Kerberos 5 GSSAPI mechanism.  Use of these
-
-Yu                  Document Expiration: 04 Sep 2000           [Page 20]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-   definitions will enable independent implementors to enhance
-   application portability across different implementations of the
-   mechanism defined in this specification.  (In all cases,
-   implementations of GSS_Display_status() will enable callers to
-   convert minor_status indicators to text representations.)  Each
-   implementation should make available, through include files or other
-   means, a facility to translate these symbolic names into the concrete
-   values which a particular GSSAPI implementation uses to represent the
-   minor_status values specified in this section.
-
-   It is recognized that this list may grow over time, and that the need
-   for additional minor_status codes specific to particular
-   implementations may arise.  It is recommended, however, that
-   implementations should return a minor_status value as defined on a
-   mechanism-wide basis within this section when that code is accurately
-   representative of reportable status rather than using a separate,
-   implementation-defined code.
-
-6.1.1.  Non-Kerberos-specific codes
-
-   These symbols should likely be incorporated into the generic GSSAPI
-   C-bindings document, since they really are more general.
-
-GSS_KRB5_S_G_BAD_SERVICE_NAME
-        /* "No @ in SERVICE-NAME name string" */
-GSS_KRB5_S_G_BAD_STRING_UID
-        /* "STRING-UID-NAME contains nondigits" */
-GSS_KRB5_S_G_NOUSER
-        /* "UID does not resolve to username" */
-GSS_KRB5_S_G_VALIDATE_FAILED
-        /* "Validation error" */
-GSS_KRB5_S_G_BUFFER_ALLOC
-        /* "Couldn't allocate gss_buffer_t data" */
-GSS_KRB5_S_G_BAD_MSG_CTX
-        /* "Message context invalid" */
-GSS_KRB5_S_G_WRONG_SIZE
-        /* "Buffer is the wrong size" */
-GSS_KRB5_S_G_BAD_USAGE
-        /* "Credential usage type is unknown" */
-GSS_KRB5_S_G_UNKNOWN_QOP
-        /* "Unknown quality of protection specified" */
-
-
-6.1.2.  Kerberos-specific-codes
-
-
-
-
-
-
-
-
-
-
-Yu                  Document Expiration: 04 Sep 2000           [Page 21]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-GSS_KRB5_S_KG_CCACHE_NOMATCH
-        /* "Principal in credential cache does not match desired name" */
-GSS_KRB5_S_KG_KEYTAB_NOMATCH
-        /* "No principal in keytab matches desired name" */
-GSS_KRB5_S_KG_TGT_MISSING
-        /* "Credential cache has no TGT" */
-GSS_KRB5_S_KG_NO_SUBKEY
-        /* "Authenticator has no subkey" */
-GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
-        /* "Context is already fully established" */
-GSS_KRB5_S_KG_BAD_SIGN_TYPE
-        /* "Unknown signature type in token" */
-GSS_KRB5_S_KG_BAD_LENGTH
-        /* "Invalid field length in token" */
-GSS_KRB5_S_KG_CTX_INCOMPLETE
-        /* "Attempt to use incomplete security context" */
-
-
-7.  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.
-
-8.  Security Considerations
-
-   The GSSAPI is a security protocol; therefore, security considerations
-   are discussed throughout this document.  The original 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.
-
-9.  References
-
-   [X.680] ISO/IEC, "Information technology -- Abstract Syntax Notation
-   One (ASN.1): Specification of basic notation", ITU-T X.680 (1997) |
-   ISO/IEC 8824-1:1998
-
-Yu                  Document Expiration: 04 Sep 2000           [Page 22]
-
-Internet-Draft             krb5-gss-mech2-03                  March 2000
-
-   [X.690] ISO/IEC, "Information technology -- ASN.1 encoding rules:
-   Specification of Basic Encoding Rules (BER), Canonical Encoding Rules
-   (CER) and Distinguished Encoding Rules (DER)", ITU-T X.690 (1997) |
-   ISO/IEC 8825-1: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.
-
-   [RFC2743] Linn, J., "Generic Security Service Application Program
-   Interface, Version 2, Update 1", RFC 2743.
-
-   [RFC2744] Wray, J., "Generic Security Service API Version 2:
-   C-bindings", RFC 2744.
-
-10.  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: 04 Sep 2000           [Page 23]
-
diff --git a/doc/standardisation/draft-ietf-ftpext-mlst-08.txt b/doc/standardisation/draft-ietf-ftpext-mlst-08.txt
deleted file mode 100644
index 885cf4967..000000000
--- a/doc/standardisation/draft-ietf-ftpext-mlst-08.txt
+++ /dev/null
@@ -1,3415 +0,0 @@
-FTPEXT Working Group                                              R. Elz
-Internet Draft                                   University of Melbourne
-Expiration Date: April 2000
-                                                              P. Hethmon
-                                                        Hethmon Brothers
-
-                                                            October 1999
-
-
-                           Extensions to FTP
-
-
-                     draft-ietf-ftpext-mlst-08.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is NOT offered in accordance
-   with Section 10 of RFC2026, and the author does not provide the IETF
-   with any rights other than to publish as 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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   To view the list Internet-Draft Shadow Directories, see
-   http://www.ietf.org/shadow.html.
-
-   This entire section has been prepended to this document automatically
-   during formatting without any direct involvement by the author(s) of
-   this draft.
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                  [Page 1]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-Abstract
-
-   In order to overcome the problems caused by the undefined format of
-   the current FTP LIST command output, a new command is needed to
-   transfer standardized listing information from Server-FTP to User-
-   FTP.  Commands to enable this are defined in this document.
-
-   In order to allow consenting clients and servers to interact more
-   freely, a quite basic, and optional, virtual file store structure is
-   defined.
-
-   This proposal also extends the FTP protocol to allow character sets
-   other than US-ASCII[1] by allowing the transmission of 8-bit
-   characters and the recommended use of UTF-8[2] encoding.
-
-   Much implemented, but long undocumented, mechanisms to permit
-   restarts of interrupted data transfers in STREAM mode, are also
-   included here.
-
-   Lastly, the HOST command has been added to allow a style of "virtual
-   site" to be constructed.
-
-   Changed in this version of this document: Minor corrections as
-   discussed on the mailing list, including fixing many typographical
-   errors; Additional examples.  This paragraph will be deleted from the
-   final version of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                  [Page 2]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-
-
-Table of Contents
-
-          Abstract  ................................................   2
-    1     Introduction  ............................................   4
-    2     Document Conventions  ....................................   4
-    2.1   Basic Tokens  ............................................   5
-    2.2   Pathnames  ...............................................   5
-    2.3   Times  ...................................................   7
-    2.4   Server Replies  ..........................................   8
-    3     File Modification Time (MDTM)  ...........................   8
-    3.1   Syntax  ..................................................   9
-    3.2   Error responses  .........................................   9
-    3.3   FEAT response for MDTM  ..................................   9
-    3.4   MDTM Examples  ...........................................  10
-    4     File SIZE  ...............................................  11
-    4.1   Syntax  ..................................................  11
-    4.2   Error responses  .........................................  11
-    4.3   FEAT response for SIZE  ..................................  12
-    4.4   Size Examples  ...........................................  12
-    5     Restart of Interrupted Transfer (REST)  ..................  13
-    5.1   Restarting in STREAM Mode  ...............................  13
-    5.2   Error Recovery and Restart  ..............................  14
-    5.3   Syntax  ..................................................  14
-    5.4   FEAT response for REST  ..................................  16
-    5.5   REST Example  ............................................  16
-    6     Virtual FTP servers  .....................................  16
-    6.1   The HOST command  ........................................  18
-    6.2   Syntax of the HOST command  ..............................  18
-    6.3   HOST command semantics  ..................................  19
-    6.4   HOST command errors  .....................................  21
-    6.5   FEAT response for HOST command  ..........................  22
-    7     A Trivial Virtual File Store (TVFS)  .....................  23
-    7.1   TVFS File Names  .........................................  23
-    7.2   TVFS Path Names  .........................................  24
-    7.3   FEAT Response for TVFS  ..................................  25
-    7.4   OPTS for TVFS  ...........................................  26
-    7.5   TVFS Examples  ...........................................  26
-    8     Listings for Machine Processing (MLST and MLSD)  .........  28
-    8.1   Format of MLSx Requests  .................................  29
-    8.2   Format of MLSx Response  .................................  29
-    8.3   Filename encoding  .......................................  32
-    8.4   Format of Facts  .........................................  33
-    8.5   Standard Facts  ..........................................  33
-    8.6   System Dependent and Local Facts  ........................  41
-    8.7   MLSx Examples  ...........................................  42
-    8.8   FEAT response for MLSx  ..................................  50
-
-
-
-Elz & Hethmon             [Expires April 2000]                  [Page 3]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-    8.9   OPTS parameters for MLST  ................................  51
-    9     Impact On Other FTP Commands  ............................  55
-   10     Character sets and Internationalization  .................  56
-   11     IANA Considerations  .....................................  56
-   11.1   The OS specific fact registry  ...........................  56
-   11.2   The OS specific filetype registry  .......................  57
-   12     Security Considerations  .................................  57
-   13     References  ..............................................  58
-          Acknowledgments  .........................................  59
-          Copyright  ...............................................  60
-          Editors' Addresses  ......................................  60
-
-
-
-
-1. Introduction
-
-   This document amends the File Transfer Protocol (FTP) [3].  Five new
-   commands are added: "SIZE", "HOST", "MDTM", "MLST", and "MLSD".  The
-   existing command "REST" is modified.  Of those, the "SIZE" and "MDTM"
-   commands, and the modifications to "REST" have been in wide use for
-   many years.  The others are new.
-
-   These commands allow a client to restart an interrupted transfer in
-   transfer modes not previously supported in any documented way, to
-   support the notion of virtual hosts, and to obtain a directory
-   listing in a machine friendly, predictable, format.
-
-   An optional structure for the server's file store (NVFS) is also
-   defined, allowing servers that support such a structure to convey
-   that information to clients in a standard way, thus allowing clients
-   more certainty in constructing and interpreting path names.
-
-2. Document Conventions
-
-   This document makes use of the document conventions defined in BCP14
-   [4].  That provides the interpretation of capitalized imperative
-   words like MUST, SHOULD, etc.
-
-   This document also uses notation defined in STD 9 [3].  In
-   particular, the terms "reply", "user", "NVFS", "file", "pathname",
-   "FTP commands", "DTP", "user-FTP process", "user-PI", "user-DTP",
-   "server-FTP process", "server-PI", "server-DTP", "mode", "type",
-   "NVT", "control connection", "data connection", and "ASCII", are all
-   used here as defined there.
-
-   Syntax required is defined using the Augmented BNF defined in [5].
-   Some general ABNF definitions are required throughout the document,
-
-
-
-Elz & Hethmon             [Expires April 2000]                  [Page 4]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   those will be defined later in this section.  At first reading, it
-   may be wise to simply recall that these definitions exist here, and
-   skip to the next section.
-
-2.1. Basic Tokens
-
-   This document imports the core definitions given in Appendix A of
-   [5].  There definitions will be found for basic ABNF elements like
-   ALPHA, DIGIT, SP, etc.  To that, the following terms are added for
-   use in this document.
-
-        TCHAR          = VCHAR / SP / HTAB    ; visible plus white space
-        RCHAR          = ALPHA / DIGIT / "," / "." / ":" / "!" /
-                         "@" / "#" / "$" / "%" / "^" /
-                         "&" / "(" / ")" / "-" / "_" /
-                         "+" / "?" / "/" / "\" / "'" /
-                         DQUOTE   ; <"> -- double quote character (%x22)
-
-   The VCHAR (from [5]), TCHAR, and RCHAR types give basic character
-   types from varying sub-sets of the ASCII character set for use in
-   various commands and responses.
-
-        token          = 1*RCHAR
-
-   A "token" is a string whose precise meaning depends upon the context
-   in which it is used.  In some cases it will be a value from a set of
-   possible values maintained elsewhere.  In others it might be a string
-   invented by one party to an FTP conversation from whatever sources it
-   finds relevant.
-
-   Note that in ABNF, string literals are case insensitive.  That
-   convention is preserved in this document, and implies that FTP
-   commands added by this specification have names that can be
-   represented in any case.  That is, "MDTM" is the same as "mdtm",
-   "Mdtm" and "MdTm" etc.  However note that ALPHA, in particular, is
-   case sensitive.  That implies that a "token" is a case sensitive
-   value.  That implication is correct.
-
-2.2. Pathnames
-
-   Various FTP commands take pathnames as arguments, or return pathnames
-   in responses.  When the MLST command is supported, as indicated in
-   the response to the FEAT command [6], pathnames are to be transferred
-   in one of the following two formats.
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                  [Page 5]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-        pathname       = utf-8-name / raw
-        utf-8-name     = <a UTF-8 encoded Unicode string>
-        raw            = <any string not being a valid UTF-8 encoding>
-
-   Which format is used is at the option of the user-PI or server-PI
-   sending the pathname.  UTF-8 encodings [2] contain enough internal
-   structure that it is always, in practice, possible to determine
-   whether a UTF-8 or raw encoding has been used, in those cases where
-   it matters.  While it is useful for the user-PI to be able to
-   correctly display a pathname received from the server-PI to the user,
-   it is far more important for the user-PI to be able to retain and
-   retransmit the identical pathname when required.  Implementations are
-   advised against converting a UTF-8 pathname to a local encoding, and
-   then attempting to invert the encoding later.  Note that ASCII is a
-   subset of UTF-8.
-
-   Unless otherwise specified, the pathname is terminated by the CRLF
-   that terminates the FTP command, or by the CRLF that ends a reply.
-   Any trailing spaces preceding that CRLF form part of the name.
-   Exactly one space will precede the pathname and serve as a separator
-   from the preceding syntax element.  Any additional spaces form part
-   of the pathname.  See [7] for a fuller explanation of the character
-   encoding issues.  All implementations supporting MLST MUST support
-   [7].
-
-   Implementations should also beware that the control connection uses
-   Telnet NVT conventions [8], and that the Telnet IAC character, if
-   part of a pathname sent over the control connection, MUST be
-   correctly escaped as defined by the Telnet protocol.
-
-   Implementors should also be aware that although Telnet NVT
-   conventions are used over the control connections, Telnet option
-   negotiation MUST NOT be attempted.  See section 4.1.2.12 of [9].
-
-2.2.1. Pathname Syntax
-
-   Except where TVFS is supported (see section 7) this specification
-   imposes no syntax upon pathnames.  Nor does it restrict the character
-   set from which pathnames are created.  This does not imply that the
-   NVFS is required to make sense of all possible pathnames.  Server-PIs
-   may restrict the syntax of valid pathnames in their NVFS in any
-   manner appropriate to their implementation or underlying file system.
-   Similarly, a server-PI may parse the pathname, and assign meaning to
-   the components detected.
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                  [Page 6]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-2.2.2. Wildcarding
-
-   For the commands defined in this specification, all pathnames are to
-   be treated literally.  That is, for a pathname given as a parameter
-   to a command, the file whose name is identical to the pathname given
-   is implied.  No characters from the pathname may be treated as
-   special or "magic", thus no pattern matching (other than for exact
-   equality) between the pathname given and the files present in the
-   NVFS of the Server-FTP is permitted.
-
-   Clients that desire some form of pattern matching functionality must
-   obtain a listing of the relevant directory, or directories, and
-   implement their own filename selection procedures.
-
-2.3. Times
-
-   The syntax of a time value is:
-
-        time-val       = 14DIGIT [ "." 1*DIGIT ]
-
-   The leading, mandatory, fourteen digits are to be interpreted as, in
-   order from the leftmost, four digits giving the year, with a range of
-   1000-9999, two digits giving the month of the year, with a range of
-   01-12, two digits giving the day of the month, with a range of 01-31,
-   two digits giving the hour of the day, with a range of 00-23, two
-   digits giving minutes past the hour, with a range of 00-59, and
-   finally, two digits giving seconds past the minute, with a range of
-   00-60 (with 60 being used only at a leap second).  Years in the tenth
-   century, and earlier, cannot be expressed.  This is not considered a
-   serious defect of the protocol.
-
-   The optional digits, which are preceded by a period, give decimal
-   fractions of a second.  These may be given to whatever precision is
-   appropriate to the circumstance, however implementations MUST NOT add
-   precision to time-vals where that precision does not exist in the
-   underlying value being transmitted.
-
-   Symbolically, a time-val may be viewed as
-
-        YYYYMMDDHHMMSS.sss
-
-   The "." and subsequent digits ("sss") are optional.  However the "."
-   MUST NOT appear unless at least one following digit also appears.
-
-   Time values are always represented in UTC (GMT), and in the Gregorian
-   calendar regardless of what calendar may have been in use at the date
-   and time indicated at the location of the server-PI.
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                  [Page 7]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   The technical differences between GMT, TAI, UTC, UT1, UT2, etc, are
-   not considered here.  A server-FTP process should always use the same
-   time reference, so the times it returns will be consistent.  Clients
-   are not expected to be time synchronized with the server, so the
-   possible difference in times that might be reported by the different
-   time standards is not considered important.
-
-2.4. Server Replies
-
-   Section 4.2 of [3] defines the format and meaning of replies by the
-   server-PI to FTP commands from the user-PI.  Those reply conventions
-   are used here without change.
-
-        error-response = error-code SP *TCHAR CRLF
-        error-code     = ("4" / "5") 2DIGIT
-
-   Implementors should note that the ABNF syntax (which was not used in
-   [3]) used in this document, and other FTP related documents,
-   sometimes shows replies using the one line format.  Unless otherwise
-   explicitly stated, that is not intended to imply that multi-line
-   responses are not permitted.  Implementors should assume that, unless
-   stated to the contrary, any reply to any FTP command (including QUIT)
-   may be of the multi-line format described in [3].
-
-   Throughout this document, replies will be identified by the three
-   digit code that is their first element.  Thus the term "500 reply"
-   means a reply from the server-PI using the three digit code "500".
-
-3. File Modification Time (MDTM)
-
-   The FTP command, MODIFICATION TIME (MDTM), can be used to determine
-   when a file in the server NVFS was last modified.  This command has
-   existed in many FTP servers for many years, as an adjunct to the REST
-   command for STREAM mode, thus is widely available.  However, where
-   supported, the "modify" fact which can be provided in the result from
-   the new MLST command is recommended as a superior alternative.
-
-   When attempting to restart a RETRieve, if the User-FTP makes use of
-   the MDTM command, or "modify" fact, it can check and see if the
-   modification time of the source file is more recent than the
-   modification time of the partially transferred file.  If it is, then
-   most likely the source file has changed and it would be unsafe to
-   restart the previously incomplete file transfer.
-
-   When attempting to restart a STORe, the User FTP can use the MDTM
-   command to discover the modification time of the partially
-   transferred file.  If it is older than the modification time of the
-   file that is about to be STORed, then most likely the source file has
-
-
-
-Elz & Hethmon             [Expires April 2000]                  [Page 8]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   changed and it would be unsafe to restart the file transfer.
-
-   Note that using MLST (described below) where available, can provide
-   this information, and much more, thus giving an even better
-   indication that a file has changed, and that restarting a transfer
-   would not give valid results.
-
-   Note that this is applicable to any RESTart attempt, regardless of
-   the mode of the file transfer.
-
-3.1. Syntax
-
-   The syntax for the MDTM command is:
-
-        mdtm          = "MdTm" SP pathname CRLF
-
-   As with all FTP commands, the "MDTM" command label is interpreted in
-   a case insensitive manner.
-
-   The "pathname" specifies an object in the NVFS which may be the
-   object of a RETR command.  Attempts to query the modification time of
-   files that are unable to be retrieved generate undefined responses.
-
-   The server-PI will respond to the MDTM command with a 213 reply
-   giving the last modification time of the file whose pathname was
-   supplied, or a 550 reply if the file does not exist, the modification
-   time is unavailable, or some other error has occurred.
-
-        mdtm-response = "213" SP time-val CRLF /
-                        error-response
-
-3.2. Error responses
-
-   Where the command is correctly parsed, but the modification time is
-   not available, either because the pathname identifies no existing
-   entity, or because the information is not available for the entity
-   named, then a 550 reply should be sent.  Where the command cannot be
-   correctly parsed, a 500 or 501 reply should be sent, as specified in
-   [3].
-
-3.3. FEAT response for MDTM
-
-   When replying to the FEAT command [6], an FTP server process that
-   supports the MDTM command MUST include a line containing the single
-   word "MDTM".  This MAY be sent in upper or lower case, or a mixture
-   of both (it is case insensitive) but SHOULD be transmitted in upper
-   case only.  That is, the response SHOULD be
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                  [Page 9]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-        C> Feat
-        S> 211- <any descriptive text>
-        S>  ...
-        S>  MDTM
-        S>  ...
-        S> 211 End
-
-   The ellipses indicate place holders where other features may be
-   included, and are not required.  The one space indentation of the
-   feature lines is mandatory [6].
-
-3.4. MDTM Examples
-
-   If we assume the existence of three files, A B and C, and a directory
-   D, and no other files at all, then the MTDM command may behave as
-   indicated.  The "C>" lines are commands from user-PI to server-PI,
-   the "S>" lines are server-PI replies.
-
-        C> MDTM A
-        S> 213 19980615100045.014
-        C> MDTM B
-        S> 213 19980615100045.014
-        C> MDTM C
-        S> 213 19980705132316
-        C> MDTM D
-        S> 550 D is not retrievable
-        C> MDTM E
-        S> 550 No file named "E"
-        C> mdtm file6
-        S> 213 19990929003355
-        C> MdTm 19990929043300 File6
-        S> 213 19991005213102
-        C> MdTm 19990929043300 file6
-        S> 550 19990929043300 file6: No such file or directory.
-
-   From that we can conclude that both A and B were last modified at the
-   same time (to the nearest millisecond), and that C was modified 21
-   days and several hours later.
-
-   The times are in GMT, so file A was modified on the 15th of June,
-   1998, at approximately 11am in London (summer time was then in
-   effect), or perhaps at 8pm in Melbourne, Australia, or at 6am in New
-   York.  All of those represent the same absolute time of course.  The
-   location where the file was modified, and consequently the local wall
-   clock time at that location, is not available.
-
-   There is no file named "E" in the current directory, but there are
-   files named both "file6" and "19990929043300 File6".  The
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 10]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   modification times of those files were obtained.  There is no file
-   named "19990929043300 file6".
-
-4. File SIZE
-
-   The FTP command, SIZE OF FILE (SIZE), is used to obtain the transfer
-   size of a file from the server-FTP process.  That is, the exact
-   number of octets (8 bit bytes) which would be transmitted over the
-   data connection should that file be transmitted.  This value will
-   change depending on the current STRUcture, MODE and TYPE of the data
-   connection, or a data connection which would be created were one
-   created now.  Thus, the result of the SIZE command is dependent on
-   the currently established STRU, MODE and TYPE parameters.
-
-   The SIZE command returns how many octets would be transferred if the
-   file were to be transferred using the current transfer structure,
-   mode and type.  This command is normally used in conjunction with the
-   RESTART (REST) command.  The server-PI might need to read the
-   partially transferred file, do any appropriate conversion, and count
-   the number of octets that would be generated when sending the file in
-   order to correctly respond to this command.  Estimates of the file
-   transfer size MUST NOT be returned, only precise information is
-   acceptable.
-
-4.1. Syntax
-
-   The syntax of the SIZE command is:
-
-        size          = "Size" SP pathname CRLF
-
-   The server-PI will respond to the SIZE command with a 213 reply
-   giving the transfer size of the file whose pathname was supplied, or
-   an error response if the file does not exist, the size is
-   unavailable, or some other error has occurred.  The value returned is
-   in a format suitable for use with the RESTART (REST) command for mode
-   STREAM, provided the transfer mode and type are not altered.
-
-        size-response = "213" SP 1*DIGIT CRLF /
-                        error-response
-
-4.2. Error responses
-
-   Where the command is correctly parsed, but the size is not available,
-   either because the pathname identifies no existing entity, or because
-   the entity named cannot be transferred in the current MODE and TYPE
-   (or at all), then a 550 reply should be sent.  Where the command
-   cannot be correctly parsed, a 500 or 501 reply should be sent, as
-   specified in [3].
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 11]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-4.3. FEAT response for SIZE
-
-   When replying to the FEAT command [6], an FTP server process that
-   supports the SIZE command MUST include a line containing the single
-   word "SIZE".  This word is case insensitive, and MAY be sent in any
-   mixture of upper or lower case, however it SHOULD be sent in upper
-   case.  That is, the response SHOULD be
-
-        C> FEAT
-        S> 211- <any descriptive text>
-        S>  ...
-        S>  SIZE
-        S>  ...
-        S> 211 END
-
-   The ellipses indicate place holders where other features may be
-   included, and are not required.  The one space indentation of the
-   feature lines is mandatory [6].
-
-4.4. Size Examples
-
-   Consider a text file "Example" stored on a Unix(TM) server where each
-   end of line is represented by a single octet.  Assume the file
-   contains 112 lines, and 1830 octets total.  Then the SIZE command
-   would produce:
-
-        C> TYPE I
-        S> 200 Type set to I.
-        C> size Example
-        S> 213 1830
-        C> TYPE A
-        S> 200 Type set to A.
-        C> Size Example
-        S> 213 1942
-
-   Notice that with TYPE=A the SIZE command reports an extra 112 octets.
-   Those are the extra octets that need to be inserted, one at the end
-   of each line, to provide correct end of line semantics for a transfer
-   using TYPE=A.  Other systems might need to make other changes to the
-   transfer format of files when converting between TYPEs and MODEs.
-   The SIZE command takes all of that into account.
-
-   Since calculating the size of a file with this degree of precision
-   may take considerable effort on the part of the server-PI, user-PIs
-   should not used this command unless this precision is essential (such
-   as when about to restart an interrupted transfer).  For other uses,
-   the "Size" fact of the MLST command (see section 8.5.7) ought be
-   requested.
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 12]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-5. Restart of Interrupted Transfer (REST)
-
-   To avoid having to resend the entire file if the file is only
-   partially transferred, both sides need some way to be able to agree
-   on where in the data stream to restart the data transfer.
-
-   The FTP specification [3] includes three modes of data transfer,
-   Stream, Block and Compressed.  In Block and Compressed modes, the
-   data stream that is transferred over the data connection is
-   formatted, allowing the embedding of restart markers into the stream.
-   The sending DTP can include a restart marker with whatever
-   information it needs to be able to restart a file transfer at that
-   point.  The receiving DTP can keep a list of these restart markers,
-   and correlate them with how the file is being saved.  To restart the
-   file transfer, the receiver just sends back that last restart marker,
-   and both sides know how to resume the data transfer.  Note that there
-   are some flaws in the description of the restart mechanism in RFC 959
-   [3].  See section 4.1.3.4 of RFC 1123 [9] for the corrections.
-
-5.1. Restarting in STREAM Mode
-
-   In Stream mode, the data connection contains just a stream of
-   unformatted octets of data.  Explicit restart markers thus cannot be
-   inserted into the data stream, they would be indistinguishable from
-   data.  For this reason, the FTP specification [3] did not provide the
-   ability to do restarts in stream mode.  However, there is not really
-   a need to have explicit restart markers in this case, as restart
-   markers can be implied by the octet offset into the data stream.
-
-   Because the data stream defines the file in STREAM mode, a different
-   data stream would represent a different file.  Thus, an offset will
-   always represent the same position within a file.  On the other hand,
-   in other modes than STREAM, the same file can be transferred using
-   quite different octet sequences, and yet be reconstructed into the
-   one identical file.  Thus an offset into the data stream in transfer
-   modes other than STREAM would not give an unambiguous restart point.
-
-   If the data representation TYPE is IMAGE, and the STRUcture is File,
-   for many systems the file will be stored exactly in the same format
-   as it is sent across the data connection.  It is then usually very
-   easy for the receiver to determine how much data was previously
-   received, and notify the sender of the offset where the transfer
-   should be restarted.  In other representation types and structures
-   more effort will be required, but it remains always possible to
-   determine the offset with finite, but perhaps non-negligible, effort.
-   In the worst case an FTP process may need to open a data connection
-   to itself, set the appropriate transfer type and structure, and
-   actually transmit the file, counting the transmitted octets.
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 13]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   If the user-FTP process is intending to restart a retrieve, it will
-   directly calculate the restart marker, and send that information in
-   the RESTart command.  However, if the user-FTP process is intending
-   to restart sending the file, it needs to be able to determine how
-   much data was previously sent, and correctly received and saved.  A
-   new FTP command is needed to get this information.  This is the
-   purpose of the SIZE command, as documented in section 4.
-
-5.2. Error Recovery and Restart
-
-   STREAM MODE transfers with FILE STRUcture may be restarted even
-   though no restart marker has been transferred in addition to the data
-   itself.  This is done by using the SIZE command, if needed, in
-   combination with the RESTART (REST) command, and one of the standard
-   file transfer commands.
-
-   When using TYPE ASCII or IMAGE, the SIZE command will return the
-   number of octets that would actually be transferred if the file were
-   to be sent between the two systems.  I.e. with type IMAGE, the SIZE
-   normally would be the number of octets in the file.  With type ASCII,
-   the SIZE would be the number of octets in the file including any
-   modifications required to satisfy the TYPE ASCII CR-LF end of line
-   convention.
-
-5.3. Syntax
-
-   The syntax for the REST command when the current transfer mode is
-   STREAM is:
-
-        rest          = "Rest" SP 1*DIGIT CRLF
-
-   The numeric value gives the number of octets of the immediately
-   following transfer to not actually send, effectively causing the
-   transmission to be restarted at a later point.  A value of zero
-   effectively disables restart, causing the entire file to be
-   transmitted.  The server-PI will respond to the REST command with a
-   350 reply, indicating that the REST parameter has been saved, and
-   that another command, which should be either RETR or STOR, should
-   then follow to complete the restart.
-
-        rest-response = "350" SP *TCHAR CRLF /
-                        error-response
-
-   Server-FTP processes may permit transfer commands other than RETR and
-   STOR, such as APPE and STOU, to complete a restart, however, this is
-   not recommended.  STOU (store unique) is undefined in this usage, as
-   storing the remainder of a file into a unique filename is rarely
-   going to be useful.  If APPE (append) is permitted, it MUST act
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 14]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   identically to STOR when a restart marker has been set.  That is, in
-   both cases, octets from the data connection are placed into the file
-   at the location indicated by the restart marker value.
-
-   The REST command is intended to complete a failed transfer.  Use with
-   RETR is comparatively well defined in all cases, as the client bears
-   the responsibility of merging the retrieved data with the partially
-   retrieved file.  If it chooses to use the data obtained other than to
-   complete an earlier transfer, or if it chooses to re-retrieve data
-   that had been retrieved before, that is its choice.  With STOR,
-   however, the server must insert the data into the file named.  The
-   results are undefined if a client uses REST to do other than restart
-   to complete a transfer of a file which had previously failed to
-   completely transfer.  In particular, if the restart marker set with a
-   REST command is not at the end of the data currently stored at the
-   server, as reported by the server, or if insufficient data are
-   provided in a STOR that follows a REST to extend the destination file
-   to at least its previous size, then the effects are undefined.
-
-   The REST command must be the last command issued before the data
-   transfer command which is to cause a restarted rather than complete
-   file transfer.  The effect of issuing a REST command at any other
-   time is undefined.  The server-PI may react to a badly positioned
-   REST command by issuing an error response to the following command,
-   not being a restartable data transfer command, or it may save the
-   restart value and apply it to the next data transfer command, or it
-   may silently ignore the inappropriate restart attempt.  Because of
-   this, a user-PI that has issued a REST command, but which has not
-   successfully transmitted the following data transfer command for any
-   reason, should send another REST command before the next data
-   transfer command.  If that transfer is not to be restarted, then
-   "REST 0" should be issued.
-
-   An error-response will follow a REST command only when the server
-   does not implement the command, or the restart marker value is
-   syntactically invalid for the current transfer mode.  That is, in
-   STREAM mode, if something other than one or more digits appears in
-   the parameter to the REST command.  Any other errors, including such
-   problems as restart marker out of range, should be reported when the
-   following transfer command is issued.  Such errors will cause that
-   transfer request to be rejected with an error indicating the invalid
-   restart attempt.
-
-
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 15]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-5.4. FEAT response for REST
-
-   Where a server-FTP process supports RESTart in STREAM mode, as
-   specified here, it MUST include in the response to the FEAT command
-   [6], a line containing exactly the string "REST STREAM".  This string
-   is not case sensitive, but SHOULD be transmitted in upper case.
-   Where REST is not supported at all, or supported only in block or
-   compressed modes, the REST line MUST NOT be included in the FEAT
-   response.  Where required, the response SHOULD be
-
-        C> feat
-        S> 211- <any descriptive text>
-        S>  ...
-        S>  REST STREAM
-        S>  ...
-        S> 211 end
-
-   The ellipses indicate place holders where other features may be
-   included, and are not required.  The one space indentation of the
-   feature lines is mandatory [6].
-
-5.5. REST Example
-
-   Assume that the transfer of a largish file has previously been
-   interrupted after 802816 octets had been received, that the previous
-   transfer was with TYPE=I, and that it has been verified that the file
-   on the server has not since changed.
-
-        C> TYPE I
-        S> 200 Type set to I.
-        C> PORT 127,0,0,1,15,107
-        S> 200 PORT command successful.
-        C> REST 802816
-        S> 350 Restarting at 802816. Send STORE or RETRIEVE
-        C> RETR cap60.pl198.tar
-        S> 150 Opening BINARY mode data connection
-        [...]
-        S> 226 Transfer complete.
-
-6. Virtual FTP servers
-
-   It has become common in the Internet for many domain names to be
-   allocated to a single IP address.  This has introduced the concept of
-   a "virtual host", where a host appears to exist as an independent
-   entity, but in reality shares all of its resources with one, or more,
-   other such hosts.
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 16]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   Such an arrangement presents some problems for FTP Servers, as all
-   the FTP Server can detect is an incoming FTP connection to a
-   particular IP address.  That is, all domain names which share the IP
-   address also share the FTP server, and more importantly, its NVFS.
-   This means that the various virtual hosts cannot offer different
-   virtual file systems to clients, nor can they offer different
-   authentication systems.
-
-   No scheme can overcome this without modifications of some kind to the
-   user-PI and the user-FTP process.  That process is the only entity
-   that knows which virtual host is required.  It has performed the
-   domain name to IP address translation, and thus has the original
-   domain name available.
-
-   One method which could be used to allow a style of virtual host would
-   be for the client to simply send a "CWD" command after connecting,
-   using the virtual host name as the argument to the CWD command.  This
-   would allow the server-FTP process to implement the file stores of
-   the virtual hosts as sub-directories in its NVFS.  This is simple,
-   and supported by essentially all server-FTP implementations without
-   requiring any code changes.
-
-   While that method is simple to describe, and to implement, it suffers
-   from several drawbacks.  First, the "CWD" command is available only
-   after the user-PI has authenticated itself to the server-FTP process.
-   Thus, all virtual hosts would be required to share a common
-   authentication scheme.  Second, either the server-FTP process needs
-   to be modified to understand the special nature of this first CWD
-   command, negating most of the advantage of this scheme, or all users
-   must see the same identical NVFS view upon connecting (they must
-   connect in the same initial directory) or the NVFS must implement the
-   full set of virtual host directories at each possible initial
-   directory for any possible user, or the virtual host will not be
-   truly transparent.  Third, and again unless the server is specially
-   modified, a user connecting this way to a virtual host would be able
-   to trivially move to any other virtual host supported at the same
-   server-FTP process, exposing the nature of the virtual host.
-
-   Other schemes overloading other existing FTP commands have also been
-   proposed.  None of those have sufficient merit to be worth
-   discussion.
-
-   The conclusion from the examination of the possibilities seems to be
-   that to obtain an adequate emulation of "real" FTP servers, server
-   modifications to support virtual hosts are required.  A new command
-   seems most likely to provide the support required.
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 17]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-6.1. The HOST command
-
-   A new command "HOST" is added to the FTP command set to allow
-   server-FTP process to determine to which of possibly many virtual
-   hosts the client wishes to connect.  This command is intended to be
-   issued before the user is authenticated, allowing the authentication
-   scheme, and set of legal users, to be dependent upon the virtual host
-   chosen.  Server-FTP processes may, if they desire, permit the HOST
-   command to be issued after the user has been authenticated, or may
-   treat that as an erroneous sequence of commands.  The behavior of the
-   server-FTP process which does allow late HOST commands is undefined.
-   One reasonable interpretation would be for the user-PI to be returned
-   to the state that existed after the TCP connection was first
-   established, before user authentication.
-
-   Servers should note that the response to the HOST command is a
-   sensible time to send their "welcome" message.  This allows the
-   message to be personalized for any virtual hosts that are supported,
-   and also allows the client to have determined supported languages, or
-   representations, for the message, and other messages, via the FEAT
-   response, and selected an appropriate one via the LANG command.  See
-   [7] for more information.
-
-6.2. Syntax of the HOST command
-
-   The HOST command is defined as follows.
-
-        host-command     = "Host" SP hostname CRLF
-        hostname         = 1*DNCHAR 1*( "." 1*DNCHAR ) [ "." ]
-        DNCHAR           = ALPHA / DIGIT / "-" / "_" / "$" /
-                           "!" / "%" / "[" / "]" / ":"
-        host-response    = host-ok / error-response
-        host-ok          = "220" [ SP *TCHAR ] CRLF
-
-   As with all FTP commands, the "host" command word is case
-   independent, and may be specified in any character case desired.
-
-   The "hostname" given as a parameter specifies the virtual host to
-   which access is desired.  It should normally be the same name that
-   was used to obtain the IP address to which the FTP control connection
-   was made, after any client conversions to convert an abbreviated or
-   local alias to a complete (fully qualified) domain name, but before
-   resolving a DNS alias (owner of a CNAME resource record) to its
-   canonical name.
-
-   If the client was given a network literal address, and consequently
-   was not required to derive it from a hostname, it should send the
-   HOST command with the network address, as specified to it, enclosed
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 18]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   in brackets (after eliminating any syntax, which might also be
-   brackets, but is not required to be, from which the server deduced
-   that a literal address had been specified.) That is, for example
-
-                         HOST [10.1.2.3]
-
-   should be sent if the client had been instructed to connect to
-   "10.1.2.3", or "[10.1.2.3]", or perhaps even IPv4:10.1.2.3.  The
-   method of indicating to a client that a literal address is to be used
-   is beyond the scope of this specification.
-
-   The parameter is otherwise to be treated as a "complete domain name",
-   as that term is defined in section 3.1 of RFC 1034 [10].  That
-   implies that the name is to be treated as a case independent string,
-   in that upper case ASCII characters are to be treated as equivalent
-   to the corresponding lower case ASCII characters, but otherwise
-   preserved as given.  It also implies some limits on the length of the
-   parameter and of the components that create its internal structure.
-   Those limits are not altered in any way here.
-
-   RFC 1034 imposes no other restrictions upon what kinds of names can
-   be stored in the DNS.  Nor does RFC 1035.  This specification,
-   however, allows only a restricted set of names for the purposes of
-   the HOST command.  Those restrictions can be inferred from the ABNF
-   grammar given for the "hostname".
-
-6.3. HOST command semantics
-
-   Upon receiving the HOST command, before authenticating the user-PI, a
-   server-FTP process should validate that the hostname given represents
-   a valid virtual host for that server, and if so, establish the
-   appropriate environment for that virtual host.  The meaning of that
-   is not specified here, and may range from doing nothing at all, or
-   performing a simple change of working directory, to much more
-   elaborate state changes, as required.
-
-   If the hostname specified is unknown at the server, or if the server
-   is otherwise unwilling to treat the particular connection as a
-   connection to the hostname specified, the server will respond with a
-   504 reply.
-
-   Note: servers may require that the name specified is in some sense
-   equivalent to the particular network address that was used to reach
-   the server.
-
-   If the hostname specified would normally be acceptable, but for any
-   reason is temporarily unavailable, the server SHOULD reply to the
-   HOST command with a 434 reply.
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 19]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   The "220" reply code for the HOST command is the same as the code
-   used on the initial connection established "welcome" message.  This
-   is done deliberately so as to allow the implementation to implement
-   the front end FTP server as a wrapper which simply waits for the HOST
-   command, and then invokes an older, RFC959 compliant, server in the
-   appropriate environment for the particular hostname received.
-
-6.3.1. The REIN command
-
-   As specified in [3], the REIN command returns the state of the
-   connection to that it was immediately after the transport connection
-   was opened.  That is not changed here.  The effect of a HOST command
-   will be lost if a REIN command is performed, a new HOST command must
-   be issued.
-
-   Implementors of user-FTP should be aware that server-FTP
-   implementations which implement the HOST command as a wrapper around
-   older implementations will be unable to correctly implement the REIN
-   command.  In such an implementation, REIN will typically return the
-   server-FTP to the state that existed immediately after the HOST
-   command was issued, instead of to the state immediately after the
-   connection was opened.
-
-6.3.2. User-PI usage of HOST
-
-   A user-PI that conforms to this specification, MUST send the HOST
-   command after opening the transport connection, or after any REIN
-   command, before attempting to authenticate the user with the USER
-   command.
-
-   The following state diagram shows a typical sequence of flow of
-   control, where the "B" (begin) state is assumed to occur after the
-   transport connection has opened, or a REIN command has succeeded.
-   Other commands (such as FEAT [6]) which require no authentication may
-   have intervened.  This diagram is modeled upon (and largely borrowed
-   from) the similar diagram in section 6 of [3].
-
-   In this diagram, a three digit reply indicates that precise server
-   reply code, a single digit on a reply path indicates any server reply
-   beginning with that digit, other than any three digit replies that
-   might take another path.
-
-
-
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 20]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-
-              +---+   HOST    +---+ 1,3,5
-              | B |---------->| W |-----------------
-              +---+           +---+                 |
-                               | |                  |
-                     2,500,502 | | 4,501,503,504    |
-                 --------------   -------------     |
-                |                              |    |
-                V                   1          |    V
-              +---+   USER    +---+-------------->+---+
-              |   |---------->| W | 2       ----->| E |
-              +---+           +---+------  |  --->+---+
-                               | |       | | | |
-                             3 | | 4,5   | | | |
-                 --------------   -----  | | | |
-                |                      | | | | |
-                |                      | | | | |
-                |                 ---------  | |
-                |               1|     | |   | |
-                V                |     | |   | |
-              +---+   PASS    +---+ 2  |  ------->+---+
-              |   |---------->| W |-------------->| S |
-              +---+           +---+   ----------->+---+
-                               | |   | |     | |
-                             3 | |4,5| |     | |
-                 --------------   --------   | |
-                |                    | |  |  |  ----
-                |                    | |  |  |      |
-                |                 -----------       |
-                |             1,3|   | |  |         |
-                V                |  2| |  |         V
-              +---+   ACCT    +---+--  |   ------>+---+
-              |   |---------->| W | 4,5 --------->| F |
-              +---+           +---+-------------->+---+
-
-6.4. HOST command errors
-
-   The server-PI shall reply with a 500 or 502 reply if the HOST command
-   is unrecognized or unimplemented.  A 503 reply may be sent if the
-   HOST command is given after a previous HOST command, or after a user
-   has been authenticated.  Alternately, the server may accept the
-   command at such a time, with server defined behavior.  A 501 reply
-   should be sent if the hostname given is syntactically invalid, and a
-   504 reply if a syntactically valid hostname is not a valid virtual
-   host name for the server.
-
-   In all such cases the server-FTP process should act as if no HOST
-   command had been given.
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 21]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   A user-PI receiving a 500 or 502 reply should assume that the
-   server-PI does not implement the HOST command style virtual server.
-   It may then proceed to login as if the HOST command had succeeded,
-   and perhaps, attempt a CWD command to the hostname after
-   authenticating the user.
-
-   A user-PI receiving some other error reply should assume that the
-   virtual HOST is unavailable, and terminate communications.
-
-   A server-PI that receives a USER command, beginning the
-   authentication sequence, without having received a HOST command
-   SHOULD NOT reject the USER command.  Clients conforming to earlier
-   FTP specifications do not send HOST commands.  In this case the
-   server may act as if some default virtual host had been explicitly
-   selected, or may enter an environment different from that of all
-   supported virtual hosts, perhaps one in which a union of all
-   available accounts exists, and which presents a NVFS which appears to
-   contain sub-directories containing the NVFS for all virtual hosts
-   supported.
-
-6.5. FEAT response for HOST command
-
-   A server-FTP process that supports the host command, and virtual FTP
-   servers, MUST include in the response to the FEAT command [6], a
-   feature line indicating that the HOST command is supported.  This
-   line should contain the single word "HOST".  This MAY be sent in
-   upper or lower case, or a mixture of both (it is case insensitive)
-   but SHOULD be transmitted in upper case only.  That is, the response
-   SHOULD be
-
-        C> Feat
-        S> 211- <any descriptive text>
-        S>  ...
-        S>  HOST
-        S>  ...
-        S> 211 End
-
-   The ellipses indicate place holders where other features may be
-   included, and are not required.  The one space indentation of the
-   feature lines is mandatory [6].
-
-
-
-
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 22]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-7. A Trivial Virtual File Store (TVFS)
-
-   Traditionally, FTP has placed almost no constraints upon the file
-   store (NVFS) provided by a server.  This specification does not alter
-   that.  However, it has become common for servers to attempt to
-   provide at least file system naming conventions modeled loosely upon
-   those of the UNIX(TM) file system.  That is, a tree structured file
-   system, built of directories, each of which can contain other
-   directories, or other kinds of files, or both.  Each file and
-   directory has a file name relative to the directory that contains it,
-   except for the directory at the root of the tree, which is contained
-   in no other directory, and hence has no name of its own.
-
-   That which has so far been described is perfectly consistent with the
-   standard FTP NVFS and access mechanisms.  The "CWD" command is used
-   to move from one directory to an embedded directory.  "CDUP" may be
-   provided to return to the parent directory, and the various file
-   manipulation commands ("RETR", "STOR", the rename commands, etc) are
-   used to manipulate files within the current directory.
-
-   However, it is often useful to be able to reference files other than
-   by changing directories, especially as FTP provides no guaranteed
-   mechanism to return to a previous directory.  The Trivial Virtual
-   File Store (TVFS), if implemented, provides that mechanism.
-
-7.1. TVFS File Names
-
-   Where a server implements the TVFS, no elementary filename shall
-   contain the character "/".  Where the underlying natural file store
-   permits files, or directories, to contain the "/" character in their
-   names, a server-PI implementing TVFS must encode that character in
-   some manner whenever file or directory names are being returned to
-   the user-PI, and reverse that encoding whenever such names are being
-   accepted from the user-PI.
-
-   The encoding method to be used is not specified here.  Where some
-   other character is illegal in file and directory names in the
-   underlying file store, a simple transliteration may be sufficient.
-   Where there is no suitable substitute character a more complex
-   encoding scheme, possibly using an escape character, is likely to be
-   required.
-
-   With the one exception of the unnamed root directory, a TVFS file
-   name may not be empty.  That is, all other file names contain at
-   least one character.
-
-   With the sole exception of the "/" character, any valid IS10646
-   character [11] may be used in a TVFS filename.  When transmitted,
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 23]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   file name characters are encoded using the UTF-8 encoding [2].
-
-7.2. TVFS Path Names
-
-   A TVFS "Path Name" combines the file or directory name of a target
-   file or directory, with the directory names of zero or more enclosing
-   directories, so as to allow the target file or directory to be
-   referenced other than when the server's "current working directory"
-   is the directory directly containing the target file or directory.
-
-   By definition, every TVFS file or directory name is also a TVFS path
-   name.  Such a path name is valid to reference the file from the
-   directory containing the name, that is, when that directory is the
-   server-FTP's current working directory.
-
-   Other TVFS path names are constructed by prefixing a path name by a
-   name of a directory from which the path is valid, and separating the
-   two with the "/" character.  Such a path name is valid to reference
-   the file or directory from the directory containing the newly added
-   directory name.
-
-   Where a path name has been extended to the point where the directory
-   added is the unnamed root directory, the path name will begin with
-   the "/" character.  Such a path is known as a fully qualified path
-   name.  Fully qualified paths may, obviously, not be further extended,
-   as, by definition, no directory contains the root directory.  Being
-   unnamed, it cannot be represented in any other directory.  A fully
-   qualified path name is valid to reference the named file or directory
-   from any location (that is, regardless of what the current working
-   directory may be) in the virtual file store.
-
-   Any path name which is not a fully qualified path name may be
-   referred to as a "relative path name" and will only correctly
-   reference the intended file when the current working directory of the
-   server-FTP is a directory from which the relative path name is valid.
-
-   As a special case, the path name "/" is defined to be a fully
-   qualified path name referring to the root directory.  That is, the
-   root directory does not have a directory (or file) name, but does
-   have a path name.  This special path name may be used only as is as a
-   reference to the root directory.  It may not be combined with other
-   path names using the rules above, as doing so would lead to a path
-   name containing two consecutive "/" characters, which is an undefined
-   sequence.
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 24]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-7.2.1. Notes
-
-     + It is not required, or expected, that there be only one fully
-       qualified path name that will reference any particular file or
-       directory.
-     + As a caveat, though the TVFS file store is basically tree
-       structured, there is no requirement that any file or directory
-       have only one parent directory.
-     + As defined, no TVFS path name will ever contain two consecutive
-       "/" characters.  Such a name is not illegal however, and may be
-       defined by the server for any purpose that suits it.  Clients
-       implementing this specification should not assume any semantics
-       at all for such names.
-     + Similarly, other than the special case path that refers to the
-       root directory, no TVFS path name constructed as defined here
-       will ever end with the "/" character.  Such names are also not
-       illegal, but are undefined.
-     + While any legal IS10646 character is permitted to occur in a TVFS
-       file or directory name, other than "/", server FTP
-       implementations are not required to support all possible IS10646
-       characters.  The subset supported is entirely at the discretion
-       of the server.  The case (where it exists) of the characters that
-       make up file, directory, and path names may be significant.
-       Unless determined otherwise by means unspecified here, clients
-       should assume that all such names are comprised of characters
-       whose case is significant.  Servers are free to treat case (or
-       any other attribute) of a name as irrelevant, and hence map two
-       names which appear to be distinct onto the same underlying file.
-     + There are no defined "magic" names, like ".", ".." or "C:".
-       Servers may implement such names, with any semantics they choose,
-       but are not required to do so.
-     + TVFS imposes no particular semantics or properties upon files,
-       guarantees no access control schemes, or any of the other common
-       properties of a file store.  Only the naming scheme is defined.
-
-7.3. FEAT Response for TVFS
-
-   In response to the FEAT command [6] a server that wishes to indicate
-   support for the TVFS as defined here will include a line that begins
-   with the four characters "TVFS" (in any case, or mixture of cases,
-   upper case is not required).  Servers SHOULD send upper case.
-
-   Such a response to the FEAT command MUST NOT be returned unless the
-   server implements TVFS as defined here.
-
-   Later specifications may add to the TVFS definition.  Such additions
-   should be notified by means of additional text appended to the TVFS
-   feature line.  Such specifications, if any, will define the extra
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 25]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   text.
-
-   Until such a specification is defined, servers should not include
-   anything after "TVFS" in the TVFS feature line.  Clients, however,
-   should be prepared to deal with arbitrary text following the four
-   defined characters, and simply ignore it if unrecognized.
-
-   A typical response to the FEAT command issued by a server
-   implementing only this specification would be:
-
-        C> feat
-        S> 211- <any descriptive text>
-        S>  ...
-        S>  TVFS
-        S>  ...
-        S> 211 end
-
-   The ellipses indicate place holders where other features may be
-   included, and are not required.  The one space indentation of the
-   feature lines is mandatory [6], and is not counted as one of the
-   first four characters for the purposes of this feature listing.
-
-   The TVFS feature adds no new commands to the FTP command repertoire.
-
-7.4. OPTS for TVFS
-
-   There are no options in this TVFS specification, and hence there is
-   no OPTS command defined.
-
-7.5. TVFS Examples
-
-   Assume a TVFS file store is comprised of a root directory, which
-   contains two directories (A and B) and two non-directory files (X and
-   Y).  The A directory contains two directories (C and D) and one other
-   file (Z).  The B directory contains just two non-directory files (P
-   and Q) and the C directory also two non-directory files (also named P
-   and Q, by chance).  The D directory is empty, that is, contains no
-   files or directories.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 26]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   This structure may depicted graphically as...
-
-                      (unnamed root)
-                        /  |  \   \
-                       /   |   \   \
-                      A    X    B   Y
-                     /|\       / \
-                    / | \     /   \
-                   C  D  Z   P     Q
-                  / \
-                 /   \
-                P     Q
-
-   Given this structure, the following fully qualified path names exist.
-
-        /
-        /A
-        /B
-        /X
-        /Y
-        /A/C
-        /A/D
-        /A/Z
-        /A/C/P
-        /A/C/Q
-        /B/P
-        /B/Q
-
-   It is clear that none of the paths / /A /B or /A/D refer to the same
-   directory, as the contents of each is different.  Nor do any of / /A
-   /A/C or /A/D.  However /A/C and /B might be the same directory, there
-   is insufficient information given to tell.  Any of the other path
-   names (/X /Y /A/Z /A/C/P /A/C/Q /B/P and /B/Q) may refer to the same
-   underlying files, in almost any combination.
-
-   If the current working directory of the server-FTP is /A then the
-   following path names, in addition to all the fully qualified path
-   names, are valid
-
-        C
-        D
-        Z
-        C/P
-        C/Q
-
-   These all refer to the same files or directories as the corresponding
-   fully qualified path with "/A/" prepended.
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 27]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   That those path names all exist does not imply that the TVFS sever
-   will necessarily grant any kind of access rights to the named paths,
-   or that access to the same file via different path names will
-   necessarily be granted equal rights.
-
-   None of the following relative paths are valid when the current
-   directory is /A
-
-        A
-        B
-        X
-        Y
-        B/P
-        B/Q
-        P
-        Q
-
-   Any of those could be made valid by changing the server-FTP's current
-   working directory to the appropriate directory.  Note that the paths
-   "P" and "Q" might refer to different files depending upon which
-   directory is selected to cause those to become valid TVFS relative
-   paths.
-
-8. Listings for Machine Processing (MLST and MLSD)
-
-   The MLST and MLSD commands are intended to standardize the file and
-   directory information returned by the Server-FTP process.  These
-   commands differ from the LIST command in that the format of the
-   replies is strictly defined although extensible.
-
-   Two commands are defined, MLST which provides data about exactly the
-   object named on its command line, and no others.  MLSD on the other
-   hand will list the contents of a directory if a directory is named,
-   otherwise a 501 reply will be returned.  In either case, if no object
-   is named, the current directory is assumed.  That will cause MLST to
-   send a one line response, describing the current directory itself,
-   and MLSD to list the contents of the current directory.
-
-   In the following, the term MLSx will be used wherever either MLST or
-   MLSD may be inserted.
-
-   The MLST and MLSD commands also extend the FTP protocol as presented
-   in RFC 959 [3] and RFC 1123 [9] to allow that transmission of 8-bit
-   data over the control connection.  Note this is not specifying
-   character sets which are 8-bit, but specifying that FTP
-   implementations are to specifically allow the transmission and
-   reception of 8-bit bytes, with all bits significant, over the control
-   connection.  That is, all 256 possible octet values are permitted.
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 28]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   The MLSx command allows both UTF-8/Unicode and "raw" forms as
-   arguments, and in responses both to the MLST and MLSD commands, and
-   all other FTP commands which take pathnames as arguments.
-
-8.1. Format of MLSx Requests
-
-   The MLST and MLSD commands each allow a single optional argument.
-   This argument may be either a directory name or, for MLST only, a
-   filename.  For these purposes, a "filename" is the name of any entity
-   in the server NVFS which is not a directory.  Where TVFS is
-   supported, any TVFS relative path name valid in the current working
-   directory, or any TVFS fully qualified path name, may be given.  If a
-   directory name is given then MLSD must return a listing of the
-   contents of the named directory, otherwise it issues a 501 reply, and
-   does not open a data connection.  In all cases for MLST, a single set
-   of fact lines (usually a single fact line) containing the information
-   about the named file or directory shall be returned over the control
-   connection, without opening a data connection.
-
-   If no argument is given then MLSD must return a listing of the
-   contents of the current working directory, and MLST must return a
-   listing giving information about the current working directory
-   itself.  For these purposes, the contents of a directory are whatever
-   filenames (not pathnames) the server-PI will allow to be referenced
-   when the current working directory is the directory named, and which
-   the server-PI desires to reveal to the user-PI.
-
-   No title, header, or summary, lines, or any other formatting, other
-   than as is specified below, is ever returned in the output of an MLST
-   or MLSD command.
-
-   If the Client-FTP sends an invalid argument, the Server-FTP MUST
-   reply with an error code of 501.
-
-   The syntax for the MLSx command is:
-
-        mlst             = "MLst" [ SP pathname ] CRLF
-        mlsd             = "MLsD" [ SP pathname ] CRLF
-
-8.2. Format of MLSx Response
-
-   The format of a response to an MLSx command is as follows:
-
-        mlst-response    = control-response / error-response
-        mlsd-response    = ( initial-response final-response ) /
-                           error-response
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 29]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-        control-response = "250-" [ response-message ] CRLF
-                           1*( SP entry CRLF )
-                           "250" [ SP response-message ] CRLF
-
-        initial-response = "150" [ SP response-message ] CRLF
-        final-response   = "226" SP response-message CRLF
-
-        response-message = *TCHAR
-
-        data-response    = *( entry CRLF )
-
-        entry            = [ facts ] SP pathname
-        facts            = 1*( fact ";" )
-        fact             = factname "=" value
-        factname         = "Size" / "Modify" / "Create" /
-                           "Type" / "Unique" / "Perm" /
-                           "Lang" / "Media-Type" / "CharSet" /
-                           os-depend-fact / local-fact
-        os-depend-fact   = <IANA assigned OS name> "." token
-        local-fact       = "X." token
-        value            = *RCHAR
-
-   Upon receipt of a MLSx command, the server will verify the parameter,
-   and if invalid return an error-response.  For this purpose, the
-   parameter should be considered to be invalid if the client issuing
-   the command does not have permission to perform the request
-   operation.
-
-   If valid, then for an MLST command, the server-PI will send the first
-   (leading) line of the control response, the entry for the pathname
-   given, or the current directory if no pathname was provided, and the
-   terminating line.  Normally exactly one entry would be returned, more
-   entries are permitted only when required to represent a file that is
-   to have multiple "Type" facts returned.
-
-   Note that for MLST the fact set is preceded by a space.  That is
-   provided to guarantee that the fact set cannot be accidentally
-   interpreted as the terminating line of the control response, but is
-   required even when that would not be possible.  Exactly one space
-   exists between the set of facts and the pathname.  Where no facts are
-   present, there will be exactly two leading spaces before the
-   pathname.  No spaces are permitted in the facts, any other spaces in
-   the response are to be treated as being a part of the pathname.
-
-   If the command was an MLSD command, the server will open a data
-   connection as indicated in section 3.2 of RFC959 [3].  If that fails,
-   the server will return an error-response.  If all is OK, the server
-   will return the initial-response, send the appropriate data-response
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 30]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   over the new data connection, close that connection, and then send
-   the final-response over the control connection.  The grammar above
-   defines the format for the data-response, which defines the format of
-   the data returned over the data connection established.
-
-   The data connection opened for a MLSD response shall be a connection
-   as if the "TYPE L 8", "MODE S", and "STRU F" commands had been given,
-   whatever FTP transfer type, mode and structure had actually been set,
-   and without causing those settings to be altered for future commands.
-   That is, this transfer type shall be set for the duration of the data
-   connection established for this command only.  While the content of
-   the data sent can be viewed as a series of lines, implementations
-   should note that there is no maximum line length defined.
-   Implementations should be prepared to deal with arbitrarily long
-   lines.
-
-   The facts part of the specification would contain a series of "file
-   facts" about the file or directory named on the same line.  Typical
-   information to be presented would include file size, last
-   modification time, creation time, a unique identifier, and a
-   file/directory flag.
-
-   The complete format for a successful reply to the MLSD command would
-   be:
-
-        facts SP pathname CRLF
-        facts SP pathname CRLF
-        facts SP pathname CRLF
-        ...
-
-   Note that the format is intended for machine processing, not human
-   viewing, and as such the format is very rigid.  Implementations MUST
-   NOT vary the format by, for example, inserting extra spaces for
-   readability, replacing spaces by tabs, including header or title
-   lines, or inserting blank lines, or in any other way alter this
-   format.  Exactly one space is always required after the set of facts
-   (which may be empty).  More spaces may be present on a line if, and
-   only if, the file name presented contains significant spaces.  The
-   set of facts must not contain any spaces anywhere inside it.  Facts
-   should be provided in each output line only if they both provide
-   relevant information about the file named on the same line, and they
-   are in the set requested by the user-PI.  There is no requirement
-   that the same set of facts be provided for each file, or that the
-   facts presented occur in the same order for each file.
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 31]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-8.3. Filename encoding
-
-   An FTP implementation supporting the MLSx commands must be 8-bit
-   clean.  This is necessary in order to transmit UTF-8 encoded
-   filenames.  This specification recommends the use of UTF-8 encoded
-   filenames.  FTP implementations SHOULD use UTF-8 whenever possible to
-   encourage the maximum interoperability.
-
-   Filenames are not restricted to UTF-8, however treatment of arbitrary
-   character encodings is not specified by this standard.  Applications
-   are encouraged to treat non-UTF-8 encodings of filenames as octet
-   sequences.
-
-   Note that this encoding is unrelated to that of the contents of the
-   file, even if the file contains character data.
-
-   Further information about filename encoding for FTP may be found in
-   "Internationalization of the File Transfer Protocol" [7].
-
-8.3.1. Notes about the Filename
-
-   The filename returned in the MLST response should be the same name as
-   was specified in the MLST command, or, where TVFS is supported, a
-   fully qualified TVFS path naming the same file.  Where no argument
-   was given to the MLST command, the server-PI may either include an
-   empty filename in the response, or it may supply a name that refers
-   to the current directory, if such a name is available.  Where TVFS is
-   supported, a fully qualified path name of the current directory
-   SHOULD be returned.
-
-   Filenames returned in the output from an MLSD command SHOULD be
-   unqualified names within the directory named, or the current
-   directory if no argument was given.  That is, the directory named in
-   the MLSD command SHOULD NOT appear as a component of the filenames
-   returned.
-
-   If the server-FTP process is able, and the "type" fact is being
-   returned, it MAY return in the MLSD response, an entry whose type is
-   "cdir", which names the directory from which the contents of the
-   listing were obtained.  Where TVFS is supported, the name MAY be the
-   fully qualified path name of the directory, or MAY be any other path
-   name which is valid to refer to that directory from the current
-   working directory of the server-FTP.  Where more than one name
-   exists, multiple of these entries may be returned.  In a sense, the
-   "cdir" entry can be viewed as a heading for the MLSD output.
-   However, it is not required to be the first entry returned, and may
-   occur anywhere within the listing.
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 32]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   When TVFS is supported, a user-PI can refer to any file or directory
-   in the listing by combining a type "cdir" name, with the appropriate
-   name from the directory listing using the procedure defined in
-   section 7.2.
-
-   Alternatively, whether TVFS is supported or not, the user-PI can
-   issue a CWD command ([3]) giving a name of type "cdir" from the
-   listing returned, and from that point reference the files returned in
-   the MLSD response from which the cdir was obtained by using the
-   filename components of the listing.
-
-8.4. Format of Facts
-
-   The "facts" for a file in a reply to a MLSx command consist of
-   information about that file.  The facts are a series of keyword=value
-   pairs each followed by semi-colon (";") characters.  An individual
-   fact may not contain a semi-colon in its name or value.  The complete
-   series of facts may not contain the space character.  See the
-   definition or "RCHAR" in section 2.1 for a list of the characters
-   that can occur in a fact value.  Not all are applicable to all facts.
-
-   A sample of a typical series of facts would be: (spread over two
-   lines for presentation here only)
-
-        size=4161;lang=en-US;modify=19970214165800;create=19961001124534;
-        type=file;x.myfact=foo,bar;
-
-8.5. Standard Facts
-
-   This document defines a standard set of facts as follows:
-
-        size       -- Size in octets
-        modify     -- Last modification time
-        create     -- Creation time
-        type       -- Entry type
-        unique     -- Unique id of file/directory
-        perm       -- File permissions, whether read, write, execute is
-                      allowed for the login id.
-        lang       -- Language of the filename per IANA[12] registry.
-        media-type -- MIME media-type of file contents per IANA registry.
-        charset    -- Character set per IANA registry (if not UTF-8)
-
-   Fact names are case-insensitive.  Size, size, SIZE, and SiZe are the
-   same fact.
-
-   Further operating system specific keywords could be specified by
-   using the IANA operating system name as a prefix (examples only):
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 33]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-        OS/2.ea   -- OS/2 extended attributes
-        MACOS.rf  -- MacIntosh resource forks
-        UNIX.mode -- Unix file modes (permissions)
-
-   Implementations may define keywords for experimental, or private use.
-   All such keywords MUST begin with the two character sequence "x.".
-   As type names are case independent, "x." and "X." are equivalent.
-   For example:
-
-        x.ver  -- Version information
-        x.desc -- File description
-        x.type -- File type
-
-8.5.1. The type Fact
-
-   The type fact needs a special description.  Part of the problem with
-   current practices is deciding when a file is a directory.  If it is a
-   directory, is it the current directory, a regular directory, or a
-   parent directory?  The MLST specification makes this unambiguous
-   using the type fact.  The type fact given specifies information about
-   the object listed on the same line of the MLST response.
-
-   Five values are possible for the type fact:
-
-        file         -- a file entry
-        cdir         -- the listed directory
-        pdir         -- a parent directory
-        dir          -- a directory or sub-directory
-        OS.name=type -- an OS or file system dependent file type
-
-   The syntax is defined to be:
-
-        type-fact       = type-label "=" type-val
-        type-label      = "Type"
-        type-val        = "File" / "cdir" / "pdir" / "dir" /
-                          os-type
-
-8.5.1.1. type=file
-
-   The presence of the type=file fact indicates the listed entry is a
-   file containing non-system data.  That is, it may be transferred from
-   one system to another of quite different characteristics, and perhaps
-   still be meaningful.
-
-8.5.1.2. type=cdir
-
-   The type=cdir fact indicates the listed entry contains a pathname of
-   the directory whose contents are listed.  An entry of this type will
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 34]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   only be returned as a part of the result of an MLSD command when the
-   type fact is included, and provides a name for the listed directory,
-   and facts about that directory.  In a sense, it can be viewed as
-   representing the title of the listing, in a machine friendly format.
-   It may appear at any point of the listing, it is not restricted to
-   appearing at the start, though frequently may do so, and may occur
-   multiple times.  It MUST NOT be included if the type fact is not
-   included, or there would be no way for the user-PI to distinguish the
-   name of the directory from an entry in the directory.
-
-   Where TVFS is supported by the server-FTP, this name may be used to
-   construct path names with which to refer to the files and directories
-   returned in the same MLSD output (see section 7.2).  These path names
-   are only expected to work when the server-PI's position in the NVFS
-   file tree is the same as its position when the MLSD command was
-   issued, unless a fully qualified path name results.
-
-   Where TVFS is not supported, the only defined semantics associated
-   with a "type=cdir" entry are that, provided the current working
-   directory of the server-PI has not been changed, a pathname of type
-   "cdir" may be used as an argument to a CWD command, which will cause
-   the current directory of the server-PI to change so that the
-   directory which was listed in its current working directory.
-
-8.5.1.3. type=dir
-
-   If present, the type=dir entry gives the name of a directory.  Such
-   an entry typically cannot be transferred from one system to another
-   using RETR, etc, but should (permissions permitting) be able to be
-   the object of an MLSD command.
-
-8.5.1.4. type=pdir
-
-   If present, which will occur only in the response to a MLSD command
-   when the type fact is included, the type=pdir entry represents a
-   pathname of the parent directory of the listed directory.  As well as
-   having the properties of a type=dir, a CWD command that uses the
-   pathname from this entry should change the user to a parent directory
-   of the listed directory.  If the listed directory is the current
-   directory, a CDUP command may also have the effect of changing to the
-   named directory.  User-FTP processes should note not all responses
-   will include this information, and that some systems may provide
-   multiple type=pdir responses.
-
-   Where TVFS is supported, a "type=pdir" name may be a relative path
-   name, or a fully qualified path name.  A relative path name will be
-   relative to the directory being listed, not to the current directory
-   of the server-PI at the time.
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 35]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   For the purposes of this type value, a "parent directory" is any
-   directory in which there is an entry of type=dir which refers to the
-   directory in which the type=pdir entity was found.  Thus it is not
-   required that all entities with type=pdir refer to the same
-   directory.  The "unique" fact (if supported) can be used to determine
-   whether there is a relationship between the type=pdir entries or not.
-
-8.5.1.5. System defined types
-
-   Files types that are specific to a specific operating system, or file
-   system, can be encoded using the "OS." type names.  The format is:
-
-        os-type   = "OS." os-name "=" os-type
-        os-name   = <an IANA registered operating system name>
-        os-type   = token
-
-   The "os-name" indicates the specific system type which supports the
-   particular localtype.  OS specific types are registered by the IANA
-   using the procedures specified in section 11.  The "os-type" provides
-   the system dependent information as to the type of the file listed.
-   The os-name and os-type strings in an os-type are case independent.
-   "OS.unix=block" and "OS.Unix=BLOCK" represent the same type (or
-   would, if such a type were registered.)
-
-   Note: Where the underlying system supports a file type which is
-   essentially an indirect pointer to another file, the NVFS
-   representation of that type should normally be to represent the file
-   which the reference indicates.  That is, the underlying basic file
-   will appear more than once in the NVFS, each time with the "unique"
-   fact (see immediately following section) containing the same value,
-   indicating that the same file is represented by all such names.
-   User-PIs transferring the file need then transfer it only once, and
-   then insert their own form of indirect reference to construct
-   alternate names where desired, or perhaps even copy the local file if
-   that is the only way to provide two names with the same content.  A
-   file which would be a reference to another file, if only the other
-   file actually existed, may be represented in any OS dependent manner
-   appropriate, or not represented at all.
-
-8.5.1.6. Multiple types
-
-   Where a file is such that it may validly, and sensibly, treated by
-   the server-PI as being of more than one of the above types, then
-   multiple entries should be returned, each with its own "Type" fact of
-   the appropriate type, and each containing the same pathname.  This
-   may occur, for example, with a structured file, which may contain
-   sub-files, and where the server-PI permits the structured file to be
-   treated as a unit, or treated as a directory allowing the sub-files
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 36]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   within it to be referenced.
-
-8.5.2. The unique Fact
-
-   The unique fact is used to present a unique identifier for a file or
-   directory in the NVFS accessed via a server-FTP process.  The value
-   of this fact should be the same for any number of pathnames that
-   refer to the same underlying file.  The fact should have different
-   values for names which reference distinct files.  The mapping between
-   files, and unique fact tokens should be maintained, and remain
-   consistent, for at least the lifetime of the control connection from
-   user-PI to server-PI.
-
-        unique-fact  = "Unique" "=" token
-
-   This fact would be expected to be used by Server-FTPs whose host
-   system allows things such as symbolic links so that the same file may
-   be represented in more than one directory on the server.  The only
-   conclusion that should be drawn is that if two different names each
-   have the same value for the unique fact, they refer to the same
-   underlying object.  The value of the unique fact (the token) should
-   be considered an opaque string for comparison purposes, and is a case
-   dependent value.  The tokens "A" and "a" do not represent the same
-   underlying object.
-
-8.5.3. The modify Fact
-
-   The modify fact is used to determine the last time the content of the
-   file (or directory) indicated was modified.  Any change of substance
-   to the file should cause this value to alter.  That is, if a change
-   is made to a file such that the results of a RETR command would
-   differ, then the value of the modify fact should alter.  User-PIs
-   should not assume that a different modify fact value indicates that
-   the file contents are necessarily different than when last retrieved.
-   Some systems may alter the value of the modify fact for other
-   reasons, though this is discouraged wherever possible.  Also a file
-   may alter, and then be returned to its previous content, which would
-   often be indicated as two incremental alterations to the value of the
-   modify fact.
-
-   For directories, this value should alter whenever a change occurs to
-   the directory such that different filenames would (or might) be
-   included in MLSD output of that directory.
-
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 37]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-        modify-fact  = "Modify" "=" time-val
-
-8.5.4. The create Fact
-
-   The create fact indicates when a file, or directory, was first
-   created.  Exactly what "creation" is for this purpose is not
-   specified here, and may vary from server to server.  About all that
-   can be said about the value returned is that it can never indicate a
-   later time than the modify fact.
-
-        create-fact  = "Create" "=" time-val
-
-   Implementation Note: Implementors of this fact on UNIX(TM) systems
-        should note that the unix "stat" "st_ctime" field does not give
-        creation time, and that unix file systems do not record creation
-        time at all.  Unix (and POSIX) implementations will normally not
-        include this fact.
-
-8.5.5. The perm Fact
-
-   The perm fact is used to indicate access rights the current FTP user
-   has over the object listed.  Its value is always an unordered
-   sequence of alphabetic characters.
-
-        perm-fact    = "Perm" "=" *pvals
-        pvals        = "a" / "c" / "d" / "e" / "f" /
-                       "l" / "m" / "p" / "r" / "w"
-
-   There are ten permission indicators currently defined.  Many are
-   meaningful only when used with a particular type of object.  The
-   indicators are case independent, "d" and "D" are the same indicator.
-
-   The "a" permission applies to objects of type=file, and indicates
-   that the APPE (append) command may be applied to the file named.
-
-   The "c" permission applies to objects of type=dir (and type=pdir,
-   type=cdir).  It indicates that files may be created in the directory
-   named.  That is, that a STOU command is likely to succeed, and that
-   STOR and APPE commands might succeed if the file named did not
-   previously exist, but is to be created in the directory object that
-   has the "c" permission.  It also indicates that the RNTO command is
-   likely to succeed for names in the directory.
-
-   The "d" permission applies to all types.  It indicates that the
-   object named may be deleted, that is, that the RMD command may be
-   applied to it if it is a directory, and otherwise that the DELE
-   command may be applied to it.
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 38]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   The "e" permission applies to the directory types.  When set on an
-   object of type=dir, type=cdir, or type=pdir it indicates that a CWD
-   command naming the object should succeed, and the user should be able
-   to enter the directory named.  For type=pdir it also indicates that
-   the CDUP command may succeed (if this particular pathname is the one
-   to which a CDUP would apply.)
-
-   The "f" permission for objects indicates that the object named may be
-   renamed - that is, may be the object of an RNFR command.
-
-   The "l" permission applies to the directory file types, and indicates
-   that the listing commands, LIST, NLST, and MLSD may be applied to the
-   directory in question.
-
-   The "m" permission applies to directory types, and indicates that the
-   MKD command may be used to create a new directory within the
-   directory under consideration.
-
-   The "p" permission applies to directory types, and indicates that
-   objects in the directory may be deleted, or (stretching naming a
-   little) that the directory may be purged.  Note: it does not indicate
-   that the RMD command may be used to remove the directory named
-   itself, the "d" permission indicator indicates that.
-
-   The "r" permission applies to type=file objects, and for some
-   systems, perhaps to other types of objects, and indicates that the
-   RETR command may be applied to that object.
-
-   The "w" permission applies to type=file objects, and for some
-   systems, perhaps to other types of objects, and indicates that the
-   STOR command may be applied to the object named.
-
-   Note: That a permission indicator is set can never imply that the
-        appropriate command is guaranteed to work - just that it might.
-        Other system specific limitations, such as limitations on
-        available space for storing files, may cause an operation to
-        fail, where the permission flags may have indicated that it was
-        likely to succeed.  The permissions are a guide only.
-
-   Implementation note: The permissions are described here as they apply
-        to FTP commands.  They may not map easily into particular
-        permissions available on the server's operating system.  Servers
-        are expected to synthesize these permission bits from the
-        permission information available from operating system.  For
-        example, to correctly determine whether the "D" permission bit
-        should be set on a directory for a server running on the
-        UNIX(TM) operating system, the server should check that the
-        directory named is empty, and that the user has write permission
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 39]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-        on both the directory under consideration, and its parent
-        directory.
-
-        Some systems may have more specific permissions than those
-        listed here, such systems should map those to the flags defined
-        as best they are able.  Other systems may have only more broad
-        access controls.  They will generally have just a few possible
-        permutations of permission flags, however they should attempt to
-        correctly represent what is permitted.
-
-8.5.6. The lang Fact
-
-   The lang fact describes the natural language of the filename for use
-   in display purposes.  Values used here should be taken from the
-   language registry of the IANA.  See [13] for the syntax, and
-   procedures, related to language tags.
-
-        lang-fact  = "Lang" "=" token
-
-   Server-FTP implementations MUST NOT guess language values.  Language
-   values must be determined in an unambiguous way such as file system
-   tagging of language or by user configuration.  Note that the lang
-   fact provides no information at all about the content of a file, only
-   about the encoding of its name.
-
-8.5.7. The size Fact
-
-   The size fact applies to non-directory file types and should always
-   reflect the approximate size of the file.  This should be as accurate
-   as the server can make it, without going to extraordinary lengths,
-   such as reading the entire file.  The size is expressed in units of
-   octets of data in the file.
-
-   Given limitations in some systems, Client-FTP implementations must
-   understand this size may not be precise and may change between the
-   time of a MLST and RETR operation.
-
-   Clients that need highly accurate size information for some
-   particular reason should use the SIZE command as defined in section
-   4.  The most common need for this accuracy is likely to be in
-   conjunction with the REST command described in section 5.  The size
-   fact, on the other hand, should be used for purposes such as
-   indicating to a human user the approximate size of the file to be
-   transferred, and perhaps to give an idea of expected transfer
-   completion time.
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 40]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-        size-fact  = "Size" "=" 1*DIGIT
-
-8.5.8. The media-type Fact
-
-   The media-type fact represents the IANA media type of the file named,
-   and applies only to non-directory types.  The list of values used
-   must follow the guidelines set by the IANA registry.
-
-        media-type  = "Media-Type" "=" <per IANA guidelines>
-
-   Server-FTP implementations MUST NOT guess media type values.  Media
-   type values must be determined in an unambiguous way such as file
-   system tagging of media-type or by user configuration.  This fact
-   gives information about the content of the file named.  Both the
-   primary media type, and any appropriate subtype should be given,
-   separated by a slash "/" as is traditional.
-
-8.5.9. The charset Fact
-
-   The charset fact provides the IANA character set name, or alias, for
-   the encoded pathnames in a MLSx response.  The default character set
-   is UTF-8 unless specified otherwise.  FTP implementations SHOULD use
-   UTF-8 if possible to encourage maximum interoperability.  The value
-   of this fact applies to the pathname only, and provides no
-   information about the contents of the file.
-
-        charset-type  = "Charset" "=" token
-
-8.5.10. Required facts
-
-   Servers are not required to support any particular set of the
-   available facts.  However, servers SHOULD, if conceivably possible,
-   support at least the type, perm, size, unique, and modify facts.
-
-8.6. System Dependent and Local Facts
-
-   By using an system dependent fact, or a local fact, a server-PI may
-   communicate to the user-PI information about the file named which is
-   peculiar to the underlying file system.
-
-8.6.1. System Dependent Facts
-
-   System dependent fact names are labeled by prefixing a label
-   identifying the specific information returned by the name of the
-   appropriate operating system from the IANA maintained list of
-   operating system names.
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 41]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   The value of an OS dependent fact may be whatever is appropriate to
-   convey the information available.  It must be encoded as a "token" as
-   defined in section 2.1 however.
-
-   In order to allow reliable interoperation between users of system
-   dependent facts, the IANA will maintain a registry of system
-   dependent fact names, their syntax, and the interpretation to be
-   given to their values.  Registrations of system dependent facts are
-   to be accomplished according to the procedures of section 11.
-
-8.6.2. Local Facts
-
-   Implementations may also make available other facts of their own
-   choosing.  As the method of interpretation of such information will
-   generally not be widely understood, server-PIs should be aware that
-   clients will typically ignore any local facts provided.  As there is
-   no registration of locally defined facts, it is entirely possible
-   that different servers will use the same local fact name to provide
-   vastly different information.  Hence user-PIs should be hesitant
-   about making any use of any information in a locally defined fact
-   without some other specific assurance that the particular fact is one
-   that they do comprehend.
-
-   Local fact names all begin with the sequence "X.".  The rest of the
-   name is a "token" (see section 2.1).  The value of a local fact can
-   be anything at all, provided it can be encoded as a "token".
-
-8.7. MLSx Examples
-
-   The following examples are all taken from dialogues between existing
-   FTP clients and servers.  Because of this, not all possible
-   variations of possible response formats are shown in the examples.
-   This should not be taken as limiting the options of other server
-   implementors.  Where the examples show OS dependent information, that
-   is to be treated as being purely for the purposes of demonstration of
-   some possible OS specific information that could be defined.  As at
-   the time of the writing of this document, no OS specific facts or
-   file types have been defined, the examples shown here should not be
-   treated as in any way to be preferred over other possible similar
-   definitions.  Consult the IANA registries to determine what types and
-   facts have been defined.
-
-   In the examples shown, only relevant commands and responses have been
-   included.  This is not to imply that other commands (including
-   authentication, directory modification, PORT or PASV commands, or
-   similar) would not be present in an actual connection, or were not,
-   in fact, actually used in the examples before editing.  Note also
-   that the formats shown are those that are transmitted between client
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 42]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   and server, not formats which would normally ever be reported to the
-   user of the client.
-
-   In the examples, lines that begin "C> " were sent over the control
-   connection from the client to the server, lines that begin "S> " were
-   sent over the control connection from the server to the client, and
-   lines that begin "D> " were sent from the server to the client over a
-   data connection created just to send those lines and closed
-   immediately after.  No examples here show data transferred over a
-   data connection from the client to the server.  In all cases, the
-   prefixes shown above, including the one space, have been added for
-   the purposes of this document, and are not a part of the data
-   exchanged between client and server.
-
-8.7.1. Simple MLST
-
- C> PWD
- S> 257 "/tmp" is current directory.
- C> MLst cap60.pl198.tar.gz
- S> 250- Listing cap60.pl198.tar.gz
- S>  Type=file;Size=1024990;Perm=r; /tmp/cap60.pl198.tar.gz
- S> 250 End
-
-   The client first asked to be told the current directory of the
-   server.  This was purely for the purposes of clarity of this example.
-   The client then requested facts about a specific file.  The server
-   returned the "250-" first control-response line, followed by a single
-   line of facts about the file, followed by the terminating "250 "
-   line.  The text on the control-response line and the terminating line
-   can be anything the server decides to send.  Notice that the fact
-   line is indented by a single space.  Notice also that there are no
-   spaces in the set of facts returned, until the single space before
-   the filename.  The filename returned on the fact line is a fully
-   qualified pathname of the file listed.  The facts returned show that
-   the line refers to a file, that file contains approximately 1024990
-   bytes, though more or less than that may be transferred if the file
-   is retrieved, and a different number may be required to store the
-   file at the client's file store, and the connected user has
-   permission to retrieve the file but not to do anything else
-   particularly interesting.
-
-8.7.2. MLST of a directory
-
- C> PWD
- S> 257 "/" is current directory.
- C> MLst tmp
- S> 250- Listing tmp
- S>  Type=dir;Modify=19981107085215;Perm=el; /tmp
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 43]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
- S> 250 End
-
-   Again the PWD is just for the purposes of demonstration for the
-   example.  The MLST fact line this time shows that the file listed is
-   a directory, that it was last modified at 08:52:15 on the 7th of
-   November, 1998 UTC, and that the user has permission to enter the
-   directory, and to list its contents, but not to modify it in any way.
-   Again, the fully qualified path name of the directory listed is
-   given.
-
-8.7.3. MLSD of a directory
-
- C> MLSD tmp
- S> 150 BINARY connection open for MLSD tmp
- D> Type=cdir;Modify=19981107085215;Perm=el; tmp
- D> Type=cdir;Modify=19981107085215;Perm=el; /tmp
- D> Type=pdir;Modify=19990112030508;Perm=el; ..
- D> Type=file;Size=25730;Modify=19940728095854;Perm=; capmux.tar.z
- D> Type=file;Size=1830;Modify=19940916055648;Perm=r; hatch.c
- D> Type=file;Size=25624;Modify=19951003165342;Perm=r; MacIP-02.txt
- D> Type=file;Size=2154;Modify=19950501105033;Perm=r; uar.netbsd.patch
- D> Type=file;Size=54757;Modify=19951105101754;Perm=r; iptnnladev.1.0.sit.hqx
- D> Type=file;Size=226546;Modify=19970515023901;Perm=r; melbcs.tif
- D> Type=file;Size=12927;Modify=19961025135602;Perm=r; tardis.1.6.sit.hqx
- D> Type=file;Size=17867;Modify=19961025135602;Perm=r; timelord.1.4.sit.hqx
- D> Type=file;Size=224907;Modify=19980615100045;Perm=r; uar.1.2.3.sit.hqx
- D> Type=file;Size=1024990;Modify=19980130010322;Perm=r; cap60.pl198.tar.gz
- S> 226 MLSD completed
-
-   In this example notice that there is no leading space on the fact
-   lines returned over the data connection.  Also notice that two lines
-   of "type=cdir" have been given.  These show two alternate names for
-   the directory listed, one a fully qualified pathname, and the other a
-   local name relative to the servers current directory when the MLSD
-   was performed.  Note that all other filenames in the output are
-   relative to the directory listed, though the server could, if it
-   chose, give a fully qualified path name for the "type=pdir" line.
-   This server has chosen not to.  The other files listed present a
-   fairly boring set of files that are present in the listed directory.
-   Note that there is no particular order in which they are listed.
-   They are not sorted by filename, by size, or by modify time.  Note
-   also that the "perm" fact has an empty value for the file
-   "capmux.tar.z" indicating that the connected user has no permissions
-   at all for that file.  This server has chosen to present the "cdir"
-   and "pdir" lines before the lines showing the content of the
-   directory, it is not required to do so.  The "size" fact does not
-   provide any meaningful information for a directory, so is not
-   included in the fact lines for the directory types shown.
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 44]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-8.7.4. A more complex example
-
- C> MLst test
- S> 250- Listing test
- S>  Type=dir;Perm=el;Unique=keVO1+ZF4 test
- S> 250 End
- C> MLSD test
- S> 150 BINARY connection open for MLSD test
- D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
- D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
- D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar
- D> Type=OS.unix=chr-13/29;Perm=;Unique=keVO1+5G4; device
- D> Type=OS.unix=blk-11/108;Perm=;Unique=keVO1+6G4; block
- D> Type=file;Perm=awr;Unique=keVO1+8G4; writable
- D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; promiscuous
- D> Type=dir;Perm=;Unique=keVO1+1t2; no-exec
- D> Type=file;Perm=r;Unique=keVO1+EG4; two words
- D> Type=file;Perm=r;Unique=keVO1+IH4;  leading space
- D> Type=file;Perm=r;Unique=keVO1+1G4; file1
- D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; incoming
- D> Type=file;Perm=r;Unique=keVO1+1G4; file2
- D> Type=file;Perm=r;Unique=keVO1+1G4; file3
- D> Type=file;Perm=r;Unique=keVO1+1G4; file4
- S> 226 MLSD completed
- C> MLSD test/incoming
- S> 150 BINARY connection open for MLSD test/incoming
- D> Type=cdir;Perm=cpmel;Unique=keVO1+7G4; test/incoming
- D> Type=pdir;Perm=el;Unique=keVO1+ZF4; ..
- D> Type=file;Perm=awdrf;Unique=keVO1+EH4; bar
- D> Type=file;Perm=awdrf;Unique=keVO1+LH4;
- D> Type=file;Perm=rf;Unique=keVO1+1G4; file5
- D> Type=file;Perm=rf;Unique=keVO1+1G4; file6
- D> Type=dir;Perm=cpmdelf;Unique=keVO1+!s2; empty
- S> 226 MLSD completed
-
-   For the purposes of this example the fact set requested has been
-   modified to delete the "size" and "modify" facts, and add the
-   "unique" fact.  First, facts about a filename have been obtained via
-   MLST.  Note that no fully qualified path name was given this time.
-   That was because the server was unable to determine that information.
-   Then having determined that the filename represents a directory, that
-   directory has been listed.  That listing also shows no fully
-   qualified path name, for the same reason, thus has but a single
-   "type=cdir" line.  This directory (which was created especially for
-   the purpose) contains several interesting files.  There are some with
-   OS dependent file types, several sub-directories, and several
-   ordinary files.
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 45]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   Not much can be said here about the OS dependent file types, as none
-   of the information shown there should be treated as any more than
-   possibilities.  It can be seen that the OS type of the server is
-   "unix" though, which is one of the OS types in the IANA registry of
-   Operating System names.
-
-   Of the three directories listed, "no-exec" has no permission granted
-   to this user to access at all.  From the "Unique" fact values, it can
-   be determined that "promiscuous" and "incoming" in fact represent the
-   same directory.  Its permissions show that the connected user has
-   permission to do essentially anything other than to delete the
-   directory.  That directory was later listed.  It happens that the
-   directory can not be deleted because it is not empty.
-
-   Of the normal files listed, two contain spaces in their names.  The
-   file called " leading space" actually contains two spaces in its
-   name, one before the "l" and one between the "g" and the "s".  The
-   two spaces that separate the facts from the visible part of the path
-   name make that clear.  The file "writable" has the "a" and "w"
-   permission bits set, and consequently the connected user should be
-   able to STOR or APPE to that file.
-
-   The other four file names, "file1", "file2", "file3", and "file4" all
-   represent the same underlying file, as can be seen from the values of
-   the "unique" facts of each.  It happens that "file1" and "file2" are
-   Unix "hard" links, and that "file3" and "file4" are "soft" or
-   "symbolic" links to the first two.  None of that information is
-   available via standard MLST facts, it is sufficient for the purposes
-   of FTP to note that all represent the same file, and that the same
-   data would be fetched no matter which of them was retrieved, and that
-   all would be simultaneously modified were data stored in any.
-
-   Finally, the sub-directory "incoming" is listed.  Since "promiscuous"
-   is the same directory there would be no point listing it as well.  In
-   that directory, the files "file5" and "file6" represent still more
-   names for the "file1" file we have seen before.  Notice the entry
-   between that for "bar" and "file5".  Though it is not possible to
-   easily represent it in this document, that shows a file with a name
-   comprising exactly three spaces ("   ").  A client will have no
-   difficulty determining that name from the output presented to it
-   however.  The directory "empty" is, as its name implies, empty,
-   though that is not shown here.  It can, however, be deleted, as can
-   file "bar" and the file whose name is three spaces.  All the files
-   that reside in this directory can be renamed.  This is a consequence
-   of the UNIX semantics of the directory that contains them being
-   modifiable.
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 46]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-8.7.5. More accurate time information
-
- C> MLst file1
- S> 250- Listing file1
- S>  Type=file;Modify=19990929003355.237; file1
- S> 250 End
-
-   In this example, the server-FTP is indicating that "file1" was last
-   modified 237 milliseconds after 00:33:55 UTC on the 29th of
-   September, 1999.
-
-8.7.6. A different server
-
- C> MLST
- S> 250-Begin
- S>  type=dir;unique=AQkAAAAAAAABCAAA; /
- S> 250 End.
- C> MLSD .
- S> 150 Opening ASCII mode data connection for MLS.
- D> type=cdir;unique=AQkAAAAAAAABCAAA; /
- D> type=dir;unique=AQkAAAAAAAABEAAA; bin
- D> type=dir;unique=AQkAAAAAAAABGAAA; etc
- D> type=dir;unique=AQkAAAAAAAAB8AwA; halflife
- D> type=dir;unique=AQkAAAAAAAABoAAA; incoming
- D> type=dir;unique=AQkAAAAAAAABIAAA; lib
- D> type=dir;unique=AQkAAAAAAAABWAEA; linux
- D> type=dir;unique=AQkAAAAAAAABKAEA; ncftpd
- D> type=dir;unique=AQkAAAAAAAABGAEA; outbox
- D> type=dir;unique=AQkAAAAAAAABuAAA; quake2
- D> type=dir;unique=AQkAAAAAAAABQAEA; winstuff
- S> 226 Listing completed.
- C> MLSD linux
- S> 150 Opening ASCII mode data connection for MLS.
- D> type=cdir;unique=AQkAAAAAAAABWAEA; /linux
- D> type=pdir;unique=AQkAAAAAAAABCAAA; /
- D> type=dir;unique=AQkAAAAAAAABeAEA; firewall
- D> type=file;size=12;unique=AQkAAAAAAAACWAEA; helo_world
- D> type=dir;unique=AQkAAAAAAAABYAEA; kernel
- D> type=dir;unique=AQkAAAAAAAABmAEA; scripts
- D> type=dir;unique=AQkAAAAAAAABkAEA; security
- S> 226 Listing completed.
- C> MLSD linux/kernel
- S> 150 Opening ASCII mode data connection for MLS.
- D> type=cdir;unique=AQkAAAAAAAABYAEA; /linux/kernel
- D> type=pdir;unique=AQkAAAAAAAABWAEA; /linux
- D> type=file;size=6704;unique=AQkAAAAAAAADYAEA; k.config
- D> type=file;size=7269221;unique=AQkAAAAAAAACYAEA; linux-2.0.36.tar.gz
- D> type=file;size=12514594;unique=AQkAAAAAAAAEYAEA; linux-2.1.130.tar.gz
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 47]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
- S> 226 Listing completed.
-
-   Note that this server returns its "unique" fact value in quite a
-   different format.  It also returns fully qualified path names for the
-   "pdir" entry.
-
-8.7.7. Some IANA files
-
- C> MLSD .
- S> 150 BINARY connection open for MLSD .
- D> Type=cdir;Modify=19990219183438; /iana/assignments
- D> Type=pdir;Modify=19990112030453; ..
- D> Type=dir;Modify=19990219073522; media-types
- D> Type=dir;Modify=19990112033515; character-set-info
- D> Type=dir;Modify=19990112033529; languages
- D> Type=file;Size=44242;Modify=19990217230400; character-sets
- D> Type=file;Size=1947;Modify=19990209215600; operating-system-names
- S> 226 MLSD completed
- C> MLSD media-types
- S> 150 BINARY connection open for MLSD media-types
- D> Type=cdir;Modify=19990219073522; media-types
- D> Type=cdir;Modify=19990219073522; /iana/assignments/media-types
- D> Type=pdir;Modify=19990219183438; ..
- D> Type=dir;Modify=19990112033045; text
- D> Type=dir;Modify=19990219183442; image
- D> Type=dir;Modify=19990112033216; multipart
- D> Type=dir;Modify=19990112033254; video
- D> Type=file;Size=30249;Modify=19990218032700; media-types
- S> 226 MLSD completed
- C> MLSD character-set-info
- S> 150 BINARY connection open for MLSD character-set-info
- D> Type=cdir;Modify=19990112033515; character-set-info
- D> Type=cdir;Modify=19990112033515; /iana/assignments/character-set-info
- D> Type=pdir;Modify=19990219183438; ..
- D> Type=file;Size=1234;Modify=19980903020400; windows-1251
- D> Type=file;Size=4557;Modify=19980922001400; tis-620
- D> Type=file;Size=801;Modify=19970324130000; ibm775
- D> Type=file;Size=552;Modify=19970320130000; ibm866
- D> Type=file;Size=922;Modify=19960505140000; windows-1258
- S> 226 MLSD completed
- C> MLSD languages
- S> 150 BINARY connection open for MLSD languages
- D> Type=cdir;Modify=19990112033529; languages
- D> Type=cdir;Modify=19990112033529; /iana/assignments/languages
- D> Type=pdir;Modify=19990219183438; ..
- D> Type=file;Size=2391;Modify=19980309130000; default
- D> Type=file;Size=943;Modify=19980309130000; tags
- D> Type=file;Size=870;Modify=19971026130000; navajo
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 48]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
- D> Type=file;Size=699;Modify=19950911140000; no-bok
- S> 226 MLSD completed
- C> PWD
- S> 257 "/iana/assignments" is current directory.
-
-   This example shows some of the IANA maintained files that are
-   relevant for this specification in MLSD format.  Note that these
-   listings have been edited by deleting many entries, the actual
-   listings are much longer.
-
-8.7.8. A stress test of case (in)dependence
-
-   The following example is intended to make clear some cases where case
-   dependent strings are permitted in the MLSx commands, and where case
-   independent strings are required.
-
- C> MlsD .
- S> 150 BINARY connection open for MLSD .
- D> Type=pdir;Modify=19990929011228;Perm=el;Unique=keVO1+ZF4; ..
- D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; FILE2
- D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+aG8; file3
- D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+ag8; FILE3
- D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file1
- D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file2
- D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Ag8; File3
- D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; File1
- D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; File2
- D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bd8; FILE1
- S> 226 MLSD completed
-
-   Note first that the "MLSD" command, shown here as "MlsD" is case
-   independent.  Clients may issue this command in any case, or
-   combination of cases, they desire.  This is the case for all FTP
-   commands.
-
-   Next, notice the labels of the facts.  These are also case
-   independent strings, Server-FTP is permitted to return them in any
-   case they desire.  User-FTP must be prepared to deal with any case,
-   though it may do this by mapping the labels to a common case if
-   desired.
-
-   Then, notice that there are nine objects of "type" file returned.  In
-   a case independent NVFS these would represent three different file
-   names, "file1", "file2", and "file3".  With a case dependent NVFS all
-   nine represent different file names.  Either is possible, server-FTPs
-   may implement a case dependent or a case independent NVFS.  User-FTPs
-   must allow for case dependent selection of files to manipulate on the
-   server.
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 49]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   Lastly, notice that the value of the "unique" fact is case dependent.
-   In the example shown, "file1", "File1", and "file2" all have the same
-   "unique" fact value "keVO1+bD8", and thus all represent the same
-   underlying file.  On the other hand, "FILE1" has a different "unique"
-   fact value ("keVO1+bd8") and hence represents a different file.
-   Similarly, "FILE2" and "File2" are two names for the same underlying
-   file, whereas "file3", "File3" and "FILE3" all represent different
-   underlying files.
-
-   That the approximate sizes ("size" fact) and last modification times
-   ("modify" fact) are the same in all cases might be no more than a
-   coincidence.
-
-   It is not suggested that the operators of server-FTPs create NVFS
-   which stress the protocols to this extent, however both user and
-   server implementations must be prepared to deal with such extreme
-   examples.
-
-8.8. FEAT response for MLSx
-
-   When responding to the FEAT command, a server-FTP process that
-   supports MLST, and MLSD, plus internationalization of pathnames, MUST
-   indicate that this support exists.  It does this by including a MLST
-   feature line.  As well as indicating the basic support, the MLST
-   feature line indicates which MLST facts are available from the
-   server, and which of those will be returned if no subsequent "OPTS
-   MLST" command is sent.
-
-        mlst-feat     = SP "MLST" [SP factlist] CRLF
-        factlist      = 1*( factname ["*"] ";" )
-
-   The initial space shown in the mlst-feat response is that required by
-   the FEAT command, two spaces are not permitted.  If no factlist is
-   given, then the server-FTP process is indicating that it supports
-   MLST, but implements no facts.  Only pathnames can be returned.  This
-   would be a minimal MLST implementation, and useless for most
-   practical purposes.  Where the factlist is present, the factnames
-   included indicate the facts supported by the server.  Where the
-   optional asterisk appears after a factname, that fact will be
-   included in MLST format responses, until an "OPTS MLST" is given to
-   alter the list of facts returned.  After that, subsequent FEAT
-   commands will return the asterisk to show the facts selected by the
-   most recent "OPTS MLST".
-
-   Note that there is no distinct FEAT output for MLSD.  The presence of
-   the MLST feature indicates that both MLST and MLSD are supported.
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 50]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-8.8.1. Examples
-
- C> Feat
- S> 211- Features supported
- S>  REST STREAM
- S>  MDTM
- S>  SIZE
- S>  TVFS
- S>  UTF8
- S>  MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden;
- S> 211 End
-
-   Aside from some features irrelevant here, this server indicates that
-   it supports MLST including several, but not all, standard facts, all
-   of which it will send by default.  It also supports two OS dependent
-   facts, and one locally defined fact.  The latter three must be
-   requested expressly by the client for this server to supply them.
-
- C> Feat
- S> 211-Extensions supported:
- S>  CLNT
- S>  MDTM
- S>  MLST type*;size*;modify*;UNIX.mode*;UNIX.owner;UNIX.group;unique;
- S>  PASV
- S>  REST STREAM
- S>  SIZE
- S>  TVFS
- S>  Compliance Level: 19981201 (IETF mlst-05)
- S> 211 End.
-
-   Again, in addition to some irrelevant features here, this server
-   indicates that it supports MLST, four of the standard facts, one of
-   which ("unique") is not enabled by default, and several OS dependent
-   facts, one of which is provided by the server by default.  This
-   server actually supported more OS dependent facts.  Others were
-   deleted for the purposes of this document to comply with document
-   formatting restrictions.
-
-8.9. OPTS parameters for MLST
-
-   For the MLSx commands, the Client-FTP may specify a list of facts it
-   wishes to be returned in all subsequent MLSx commands until another
-   OPTS MLST command is sent.  The format is specified by:
-
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 51]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-        mlst-opts     = "OPTS" SP "MLST"
-                        [ SP 1*( factname ";" ) ]
-
-   By sending the "OPTS MLST" command, the client requests the server to
-   include only the facts listed as arguments to the command in
-   subsequent output from MLSx commands.  Facts not included in the
-   "OPTS MLST" command MUST NOT be returned by the server.  Facts that
-   are included should be returned for each entry returned from the MLSx
-   command where they meaningfully apply.  Facts requested that are not
-   supported, or which are inappropriate to the file or directory being
-   listed should simply be omitted from the MLSx output.  This is not an
-   error.  Note that where no factname arguments are present, the client
-   is requesting that only the file names be returned.  In this case,
-   and in any other case where no facts are included in the result, the
-   space that separates the fact names and their values from the file
-   name is still required.  That is, the first character of the output
-   line will be a space, (or two characters will be spaces when the line
-   is returned over the control connection,) and the file name will
-   start immediately thereafter.
-
-   Clients should note that generating values for some facts can be
-   possible, but very expensive, for some servers.  It is generally
-   acceptable to retrieve any of the facts that the server offers as its
-   default set before any "OPTS MLST" command has been given, however
-   clients should use particular caution before requesting any facts not
-   in that set.  That is, while other facts may be available from the
-   server, clients should refrain from requesting such facts unless
-   there is a particular operational requirement for that particular
-   information, which ought be more significant than perhaps simply
-   improving the information displayed to an end user.
-
-   Note, there is no "OPTS MLSD" command, the fact names set with the
-   "OPTS MLST" command apply to both MLST and MLSD commands.
-
-   Servers are not required to accept "OPTS MLST" commands before
-   authentication of the user-PI, but may choose to permit them.
-
-8.9.1. OPTS MLST Response
-
-   The "response-message" from [6] to a successful OPTS MLST command has
-   the following syntax.
-
-        mlst-opt-resp = "MLST OPTS" [ SP 1*( factname ";" ) ]
-
-   This defines the "response-message" as used in the "opts-good"
-   message in RFC2389 [6].
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 52]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   The facts named in the response are those which the server will now
-   include in MLST (and MLSD) response, after the processing of the
-   "OPTS MLST" command.  Any facts from the request not supported by the
-   server will be omitted from this response message.  If no facts will
-   be included, the list of facts will be empty.  Note that the list of
-   facts returned will be the same as those marked by a trailing
-   asterisk ("*") in a subsequent FEAT command response.  There is no
-   requirement that the order of the facts returned be the same as that
-   in which they were requested, or that in which they will be listed in
-   a FEAT command response, or that in which facts are returned in MLST
-   responses.  The fixed string "MLST OPTS" in the response may be
-   returned in any case, or mixture of cases.
-
-8.9.2. Examples
-
- C> Feat
- S> 211- Features supported
- S>  MLST Type*;Size;Modify*;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
- S> 211 End
- C> OptS Mlst Type;UNIX.mode;Perm;
- S> 201 MLST OPTS Type;Perm;UNIX.mode;
- C> Feat
- S> 211- Features supported
- S>  MLST Type*;Size;Modify;Perm*;Unique;UNIX.mode*;UNIX.chgd;X.hidden;
- S> 211 End
- C> opts MLst lang;type;charset;create;
- S> 201 MLST OPTS Type;
- C> Feat
- S> 211- Features supported
- S>  MLST Type*;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
- S> 211 End
- C> OPTS mlst size;frogs;
- S> 201 MLST OPTS Size;
- C> Feat
- S> 211- Features supported
- S>  MLST Type;Size*;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
- S> 211 End
- C> opts MLst unique type;
- S> 501 Invalid MLST options
- C> Feat
- S> 211- Features supported
- S>  MLST Type;Size*;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
- S> 211 End
-
-   For the purposes of this example, features other than MLST have been
-   deleted from the output to avoid clutter.  The example shows the
-   initial default feature output for MLST.  The facts requested are
-   then changed by the client.  The first change shows facts that are
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 53]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   available from the server being selected.  Subsequent FEAT output
-   shows the altered features as being returned.  The client then
-   attempts to select some standard features which the server does not
-   support.  This is not an error, however the server simply ignores the
-   requests for unsupported features, as the FEAT output that follows
-   shows.  Then, the client attempts to request a non-standard, and
-   unsupported, feature.  The server ignores that, and selects only the
-   supported features requested.  Lastly, the client sends a request
-   containing a syntax error (spaces cannot appear in the factlist.) The
-   server-FTP sends an error response and completely ignores the
-   request, leaving the fact set selected as it had been previously.
-
-   Note that in all cases, except the error response, the response lists
-   the facts that have been selected.
-
- C> Feat
- S> 211- Features supported
- S>  MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden;
- S> 211 End
- C> Opts MLST
- S> 201 MLST OPTS
- C> Feat
- S> 211- Features supported
- S>  MLST Type;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden;
- S> 211 End
- C> MLst tmp
- S> 250- Listing tmp
- S>   /tmp
- S> 250 End
- C> OPTS mlst unique;size;
- S> 201 MLST OPTS Size;Unique;
- C>  MLst tmp
- S> 250- Listing tmp
- S>  Unique=keVO1+YZ5; /tmp
- S> 250 End
- C> OPTS mlst unique;type;modify;
- S> 201 MLST OPTS Type;Modify;Unique;
- C> MLst tmp
- S> 250- Listing tmp
- S>  Type=dir;Modify=19990930152225;Unique=keVO1+YZ5; /tmp
- S> 250 End
- C> OPTS mlst fish;cakes;
- S> 201 MLST OPTS
- C> MLst tmp
- S> 250- Listing tmp
- S>   /tmp
- S> 250 End
- C> OptS Mlst Modify;Unique;
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 54]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
- S> 201 MLST OPTS Modify;Unique;
- C> MLst tmp
- S> 250- Listing tmp
- S>  Modify=19990930152225;Unique=keVO1+YZ5; /tmp
- S> 250 End
- C> opts MLst fish cakes;
- S> 501 Invalid MLST options
- C>  MLst tmp
- S> 250- Listing tmp
- S>  Modify=19990930152225;Unique=keVO1+YZ5; /tmp
- S> 250 End
-
-   This example shows the effect of changing the facts requested upon
-   subsequent MLST commands.  Notice that a syntax error leaves the set
-   of selected facts unchanged.  Also notice exactly two spaces
-   preceding the pathname when no facts were selected, either
-   deliberately, or because none of the facts requested were available.
-
-9. Impact On Other FTP Commands
-
-   Along with the introduction of MLST, traditional FTP commands must be
-   extended to allow for the use of more than US-ASCII or EBCDIC
-   character sets.  In general, the support of MLST requires support for
-   arbitrary character sets wherever filenames and directory names are
-   allowed.  This applies equally to both arguments given to the
-   following commands and to the replies from them, as appropriate.
-
-        CWD
-        RETR
-        STOR
-        STOU
-        APPE
-        RNFR
-        RNTO
-        DELE
-        RMD
-        MKD
-        PWD
-        STAT
-
-   The arguments to all of these commands should be processed the same
-   way that MLST commands and responses are processed with respect to
-   handling embedded spaces, CRs and NULs.  See section 2.2.
-
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 55]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-10. Character sets and Internationalization
-
-   FTP commands are protocol elements, and are always expressed in
-   ASCII.  FTP responses are composed of the numeric code, which is a
-   protocol element, and a message, which is often expected to convey
-   information to the user.  It is not expected that users normally
-   interact directly with the protocol elements, rather the user FTP-
-   process constructs the commands, and interprets the results, in the
-   manner best suited for the particular user.  Explanatory text in
-   responses generally has no particular meaning to the protocol.  The
-   numeric codes provide all necessary information.  Server-PIs are free
-   to provide the text in any language that can be adequately
-   represented in ASCII, or where an alternative language and
-   representation has been negotiated (see [7]) in that language and
-   representation.
-
-   Pathnames are expected to be encoded in UTF-8 allowing essentially
-   any character to be represented in a pathname.  Meaningful pathnames
-   are defined by the server NVFS.
-
-   No restrictions at all are placed upon the contents of files
-   transferred using the FTP protocols.  Unless the "media-type" fact is
-   provided in a MLSx response nor is any advice given here which would
-   allow determining the content type.  That information is assumed to
-   be obtained via other means.
-
-11. IANA Considerations
-
-   This specification makes use of some lists of values currently
-   maintained by the IANA, and creates two new lists for the IANA to
-   maintain.  It does not add any values to any existing registries.
-
-   The existing IANA registries used by this specification are modified
-   using mechanisms specified elsewhere.
-
-11.1. The OS specific fact registry
-
-   A registry of OS specific fact names shall be maintained by the IANA.
-   The OS names for the OS portion of the fact name must be taken from
-   the IANA's list of registered OS names.  To add a fact name to this
-   OS specific registry of OS specific facts, an applicant must send to
-   the IANA a request, in which is specified the OS name, the OS
-   specific fact name, a definition of the syntax of the fact value,
-   which must conform to the syntax of a token as given in this
-   document, and a specification of the semantics to be associated with
-   the particular fact and its values.  Upon receipt of such an
-   application, and if the combination of OS name and OS specific fact
-   name has not been previously defined, the IANA will add the
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 56]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   specification to the registry.
-
-   Any examples of OS specific facts found in this document are to be
-   treated as examples of possible OS specific facts, and do not form a
-   part of the IANA's registry merely because of being included in this
-   document.
-
-11.2. The OS specific filetype registry
-
-   A registry of OS specific file types shall be maintained by the IANA.
-   The OS names for the OS portion of the fact name must be taken from
-   the IANA's list of registered OS names.  To add a file type to this
-   OS specific registry of OS specific file types, an applicant must
-   send to the IANA a request, in which is specified the OS name, the OS
-   specific file type, a definition of the syntax of the fact value,
-   which must conform to the syntax of a token as given in this
-   document, and a specification of the semantics to be associated with
-   the particular fact and its values.  Upon receipt of such an
-   application, and if the combination of OS name and OS specific file
-   type has not been previously defined, the IANA will add the
-   specification to the registry.
-
-   Any examples of OS specific file types found in this document are to
-   be treated as potential OS specific file types only, and do not form
-   a part of the IANA's registry merely because of being included in
-   this document.
-
-12. Security Considerations
-
-   This memo does not directly concern security.  It is not believed
-   that any of the mechanisms documented here impact in any particular
-   way upon the security of FTP.
-
-   Implementing the SIZE command, and perhaps some of the facts of the
-   MDLx commands, may impose a considerable load on the server, which
-   could lead to denial of service attacks.  Servers have, however,
-   implemented this for many years, without significant reported
-   difficulties.
-
-   With the introduction of virtual hosts to FTP, and the possible
-   accompanying multiple authentication environments, server
-   implementors will need to take some care to ensure that integrity is
-   maintained.
-
-   The FEAT and OPTS commands may be issued before the FTP
-   authentication has occurred [6].  This allows unauthenticated clients
-   to determine which of the features defined here are supported, and to
-   negotiate the fact list for MLSx output.  No actual MLSx commands may
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 57]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   be issued however, and no problems with permitting the selection of
-   the format prior to authentication are foreseen.
-
-   A general discussion of issues related to the security of FTP can be
-   found in [14].
-
-13. References
-
-   [1]  Coded Character Set--7-bit American Standard Code for Information
-        Interchange, ANSI X3.4-1986.
-
-   [2]  Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
-        10646", RFC 2044, October 1996.
-
-   [3]  Postel, J., Reynolds, J., "File Transfer Protocol (FTP)",
-        STD 9, RFC 959, October 1985
-
-   [4]  Bradner, S., "Key words for use in RFCs to Indicate
-        Requirement Levels", BCP 14, RFC 2119, March 1997
-
-   [5]  Crocker, D., Overell, P., "Augmented BNF for Syntax
-        Specifications: ABNF", RFC 2234, November 1997
-
-   [6]  Hethmon, P., Elz, R., "Feature negotiation mechanism for the
-        File Transfer Protocol", RFC 2389, August 1998
-
-   [7]  Curtin, W., "Internationalization of the File Transfer Protocol",
-        RFC 2640, July 1999
-
-   [8]  Postel, J., Reynolds, J., "Telnet protocol Specification"
-        STD 8, RFC 854, May 1983
-
-   [9]  Braden, R,. "Requirements for Internet Hosts -- Application
-        and Support", STD 3, RFC 1123, October 1989
-
-   [10] Mockapetris, P., "Domain Names - Concepts and Facilities"
-        STD 13, RFC 1034, November 1987
-
-   [11] ISO/IEC 10646-1:1993  "Universal multiple-octet coded character set
-        (UCS) -- Part 1: Architecture and basic multilingual plane",
-        International Standard -- Information Technology, 1993
-
-   [12] Internet Assigned Numbers Authority.  http://www.iana.org
-        Email: iana@iana.org.
-
-   [13] Alvestrand, H., "Tags for the Identification of Languages"
-        RFC 1766, March 1995
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 58]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-   [14] Allman, M., Ostermann, S., "FTP Security Considerations"
-        RFC 2577, May 1999
-
-Acknowledgments
-
-   This document is a product of the FTPEXT working group of the IETF.
-
-   The following people are among those who have contributed to this
-   document:
-
-        Alex Belits
-        D. J. Bernstein
-        Dave Cridland
-        Martin J. Duerst
-        Mike Gleason
-        Mark Harris
-        Alun Jones
-        James Matthews
-        Luke Mewburn
-        Jan Mikkelsen
-        Keith Moore
-        Buz Owen
-        Mark Symons
-        Stephen Tihor
-        and the entire FTPEXT working group of the IETF.
-
-   Apologies are offered to any inadvertently omitted.
-
-   Bernhard Rosenkraenzer suggested the HOST command, and initially
-   described it.
-
-   The description of the modifications to the REST command and the MDTM
-   and SIZE commands comes from a set of modifications suggested for
-   RFC959 by Rick Adams in 1989.  A draft containing just those
-   commands, edited by David Borman, has been merged with this document.
-
-   Mike Gleason provided access to the FTP server used in some of the
-   examples.
-
-   All of the examples in this document are taken from actual
-   client/server exchanges, though some have been edited for brevity, or
-   to meet document formatting requirements.
-
-
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 59]
-
-
-Internet Draft       draft-ietf-ftpext-mlst-08.txt          October 1999
-
-
-Copyright
-
-   This document is in the public domain.  Any and all copyright
-   protection that might apply in any jurisdiction is expressly
-   disclaimed.
-
-Editors' Addresses
-
-   Robert Elz
-   University of Melbourne
-   Department of Computer Science
-   Parkville, Vic   3052
-   Australia
-
-   Email: kre@munnari.OZ.AU
-
-
-   Paul Hethmon
-   Hethmon Brothers
-   2305 Chukar Road
-   Knoxville, TN 37923 USA
-
-   Phone: +1 423 690 8990
-   Email: phethmon@hethmon.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Hethmon             [Expires April 2000]                 [Page 60]
diff --git a/doc/standardisation/draft-ietf-kitten-2478bis-00.txt b/doc/standardisation/draft-ietf-kitten-2478bis-00.txt
deleted file mode 100644
index 91071f378..000000000
--- a/doc/standardisation/draft-ietf-kitten-2478bis-00.txt
+++ /dev/null
@@ -1,1230 +0,0 @@
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                                  P. Leach
-Obsoletes: 2478 (if approved)                              K. Jaganathan
-Expires: May 22, 2005                              Microsoft Corporation
-                                                               S. Harman
-                                                                     MIT
-                                                            W. Ingersoll
-                                                        Sun Microsystems
-                                                       November 21, 2004
-
-
-         The Simple and Protected GSS-API Negotiation Mechanism
-                        draft-ietf-kitten-2478bis-00
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on May 22, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document specifies a negotiation mechanism for the Generic
-   Security Service Application Program Interface (GSS-API) which is
-
-
-
-Zhu, et al.               Expires May 22, 2005                  [Page 1]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-   described in RFC 2743.
-
-   GSS-API peers can use this negotiation mechanism to choose from a
-   common set of security mechanisms.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
-   3.  Negotiation Protocol . . . . . . . . . . . . . . . . . . . . .  6
-     3.1   Negotiation Description  . . . . . . . . . . . . . . . . .  6
-     3.2   Negotiation Procedure  . . . . . . . . . . . . . . . . . .  7
-   4.  Token Definitions  . . . . . . . . . . . . . . . . . . . . . .  9
-     4.1   Mechanism Types  . . . . . . . . . . . . . . . . . . . . .  9
-     4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . .  9
-       4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 10
-       4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 11
-   5.  Processing of mechListMIC  . . . . . . . . . . . . . . . . . . 13
-   6.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 15
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
-   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
-   A.  GSS-API Negotiation Support API  . . . . . . . . . . . . . . . 19
-     A.1   GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 19
-     A.2   GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 19
-   B.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 21
-       Intellectual Property and Copyright Statements . . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                  [Page 2]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-1.  Introduction
-
-   The GSS-API [RFC2743] provides a generic interface which can be
-   layered atop different security mechanisms such that if communicating
-   peers acquire GSS-API credentials for the same security mechanism,
-   then a security context may be established between them (subject to
-   policy).  However, GSS-API doesn't prescribe the method by which
-   GSS-API peers can establish whether they have a common security
-   mechanism.
-
-   The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
-   defined here is a pseudo security mechanism, represented by the
-   Object Identifier iso.org.dod.internet.security.mechanism.snego
-   (1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band
-   whether their credentials share common GSS-API security mechanism(s),
-   and if so, to invoke normal security context establishment for a
-   selected common security mechanism.  This is most useful for
-   applications that are based on GSS-API implementations and multiple
-   mechanisms are shared between the peers.
-
-   The SPNEGO mechanism negotiation is based on the following
-   negotiation model: the initiator proposes a list of security
-   mechanism(s), in its preference order (favorite choice first), the
-   acceptor (also known as the target) either accepts the initiator's
-   preferred security mechanism (the first in the list), or chooses one
-   that is available from the offered list, or rejects the proposed
-   value(s).  The target then informs the initiator of its choice.
-
-   Once a common security mechanism is chosen, it MAY also negotiate
-   mechanism-specific options during its context establishment, but that
-   will be inside the mechanism tokens and invisible to this protocol.
-
-   If per-message integrity services are available on the established
-   mechanism security context, the peers can then exchange MIC tokens to
-   ensure that the mechanism list was not tampered with.  This MIC token
-   exchange is OPTIONAL if no interference could have material impact on
-   the negotiation, i.e., when the selected mechanism is the first
-   choice for both peers.
-
-   In order to avoid an extra round trip, the first security token of
-   the preferred mechanism SHOULD be embedded in the initial negotiation
-   message (as defined in Section 4.2).  This mechanism token is
-   referred to as the optimistic token in this document.  If the
-   selected mechanism matches the initiator's preferred mechanism, no
-   additional round trips need to be incurred by using this protocol.
-   In addition, by using the optimistic token, the initiator can recover
-   from a non-fatal error in producing the first token before a
-   mechanism can be selected.  Implementations, however, MAY omit the
-
-
-
-Zhu, et al.               Expires May 22, 2005                  [Page 3]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-   optimistic token, to avoid the cost of generating it in cases where
-   the initiator's preferred mechanism is not selected by the acceptor.
-
-   SPNEGO uses the concepts developed in the GSS-API specification
-   [RFC2743].  The negotiation data is encapsulated in context-level
-   tokens.  Therefore, callers of the GSS-API do not need to be aware of
-   the existence of the negotiation tokens but only of the new
-   pseudo-security mechanism.  A failure in the negotiation phase causes
-   a major status code to be returned: GSS_S_BAD_MECH.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                  [Page 4]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                  [Page 5]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-3.  Negotiation Protocol
-
-   When the established mechanism context provides for integrity
-   protection, the mechanism negotiation can be protected.  When
-   acquiring negotiated security mechanism tokens, per-message integrity
-   services are always requested by the SPNEGO mechanism.
-
-   When the established mechanism context supports per-message integrity
-   services, SPNEGO guarantees that the selected mechanism is mutually
-   preferred.
-
-   This section describes the negotiation process of this protocol.
-
-3.1  Negotiation Description
-
-   The first negotiation token sent by the initiator contains an ordered
-   list of mechanisms (in preference order, favorite choice first), and
-   optionally the initial security token for the preferred mechanism of
-   the initiator (i.e., the first in the list).  The list of security
-   mechanisms available for negotiation is based on the credentials
-   being used.
-
-   The target then processes the token from the initiator.  This will
-   result in one of four possible states (as defined in Section 4.2.2):
-   accept_completed, accept_incomplete, reject, or request_mic.  A
-   reject state will terminate the negotiation;  an accept_completed
-   state indicates that not only was the initiator-selected mechanism
-   acceptable to the target, but that the initial token was sufficient
-   to complete the authentication;  an accept_incomplete state indicates
-   that further message exchange is needed but the MIC token exchange as
-   described in Section 5 is OPITONAL;  a request_mic state (this state
-   can only be present in the first reply message from the target)
-   indicates the MIC token exchange is REQUIRED if per-message integrity
-   services are available.
-
-   Unless the preference order is specified by the application (see
-   Appendix A), the policy by which the target chooses a mechanism is an
-   implementation-specific local matter.  In the absence of application
-   specified preference order or other policy, the target SHALL choose
-   the first mechanism in the initiator proposed list for which it has
-   valid credentials.
-
-   In case of a successful negotiation, the security mechanism in the
-   first reply message represents the value suitable for the target, and
-   picked up from the list offered by the initiator.  A context level
-   token for a reject state is OPTIONAL.
-
-   Once a mechanism has been selected, the tokens specific to the
-
-
-
-Zhu, et al.               Expires May 22, 2005                  [Page 6]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-   selected mechanism are carried within the negotiation tokens.
-
-   Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the
-   mechanism list as seen by the target.
-
-   To avoid conflicts with the use of MIC tokens by SPNEGO,
-   partially-established contexts are not used for per-message calls:
-   the prot_ready_state [RFC2743] will be false even if the underlying
-   mechanism would return true natively.
-
-3.2  Negotiation Procedure
-
-   The basic form of the procedure assumes that per-message integrity
-   services are available on the established mechanism context, and it
-   is summarized as follows:
-
-   (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
-      but requests (either explicitly, with the negotiation mechanism,
-      or through accepting a default, when the default is this
-      negotiation mechanism) that SPNEGO is used.
-
-   (b) The initiator GSS-API implementation emits a negotiation token
-      containing a list of supported security mechanisms (possible just
-      one mechanism) for the credentials used for this context
-      establishment, and optionally an initial security token for the
-      first mechanism from that list.
-
-   (c) The GSS-API initiator application sends the token to the target
-      application.  The GSS-API target application deposits the token
-      through invoking GSS_Accept_sec_context().  The acceptor will do
-      one of the following:
-
-      (I) No proposed mechanism is acceptable, the negotiation SHALL be
-         terminated.  GSS_Accept_sec_context indicates GSS_S_BAD_MECH.
-         The acceptor MAY output a negotiation token containing a reject
-         state.
-
-      (II) If either the initiator's preferred mechanism is not accepted
-         by the target, or this mechanism is accepted but it is not the
-         most preferred mechanism available for the acceptor (see
-         Section 3.1 and Section 5), GSS_Accept_sec_context() indicates
-         GSS_S_CONTINUE_NEEDED.  The acceptor MUST output a negotiation
-         token containing a request_mic state.
-
-      (III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE
-         or GSS_S_CONTINUE_NEEDED, depending on if at least one
-         additional negotiation token from the initiator is needed to
-         establish this context.  The acceptor outputs a negotiation
-
-
-
-Zhu, et al.               Expires May 22, 2005                  [Page 7]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-         token containing an accept_complete or accept_incomplete state,
-         respectively.
-
-      If the initiator's preferred mechanism is accepted, and an
-      optimistic mechanism token was included, this mechanism token MUST
-      be deposited to the selected mechanism through invoking
-      GSS_Accept_sec_context() and if a response mechanism token is
-      emitted, it MUST be included in the response negotiation token.
-      Otherwise, the target will not emit a response mechanism token in
-      the first reply.
-
-   (d) The GSS-API target application returns the negotiation token to
-      the initiator application.  The GSS-API initiator application
-      deposits the token through invoking GSS_Init_sec_context().  The
-      security context initialization is then continued according to the
-      standard GSS-API conventions for the selected mechanism, where the
-      tokens of the selected mechanism are encapsulated until the
-      GSS_S_COMPLETE is returned for both the initiator and the target
-      by the selected security mechanism.
-
-   (e) MIC tokens are then either skipped or exchanged according to
-      Section 5.
-
-   Note that the *_req_flag input parameters for context establishment
-   are relative to the selected mechanism, as are the *_state output
-   parameters.  i.e., these parameters are not applicable to the
-   negotiation process per se.
-
-   On receipt of a negotiation token on the target side, a GSS-API
-   implementation that does not support negotiation would indicate the
-   GSS_S_BAD_MECH status as if a particular basic security mechanism had
-   been requested but was not supported.
-
-   When GSS_Acquire_cred is invoked with this SPNEGO mechanism as
-   desired_mechs, an implementation-specific default credential is used
-   to carry on the negotiation.  A set of mechanisms as specified
-   locally by the system administrator is then available for
-   negotiation.  If there is a desire for the caller to make its own
-   choice, then an additional API has to be used (see Appendix A).
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                  [Page 8]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-4.  Token Definitions
-
-   The type definitions in this section assume an ASN.1 module
-   definition of the following form:
-
-
-      SPNEGOASNOneSpec {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) mechanism(5) snego (2) modules(4) spec2(2)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      -- rest of definitions here
-
-      END
-
-
-   This specifies that the tagging context for the module will be
-   explicit and non-automatic.
-
-   The encoding of SPNEGO protocol messages shall obey the Distinguished
-   Encoding Rules (DER) of ASN.1 as described in [X690].
-
-4.1  Mechanism Types
-
-   In this negotiation model, each OID represents one GSS-API mechanism
-   or one variant of it according to [RFC2743].
-
-
-       MechType ::= OBJECT IDENTIFIER
-           -- OID represents each security mechanism as suggested by
-           -- [RFC2743]
-
-       MechTypeList ::= SEQUENCE OF MechType
-
-
-4.2  Negotiation Tokens
-
-   The syntax of the initial negotiation tokens follows the
-   initialContextToken syntax defined in Section 3.1 of [RFC2743].  The
-   SPNEGO pseudo mechanism is identified by the Object Identifier
-   specified in Section 1.  Subsequent tokens are not encapsulated in
-   this GSS-API generic token framing.
-
-   This section specifies the syntax of the inner token for the initial
-   message, and the syntax of subsequent context establishment tokens.
-
-       NegotiationToken ::= CHOICE {
-           negTokenInit    [0] NegTokenInit,
-
-
-
-Zhu, et al.               Expires May 22, 2005                  [Page 9]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-           negTokenResp    [1] negTokenResp
-       }
-
-
-
-4.2.1  negTokenInit
-
-       NegTokenInit ::= SEQUENCE {
-           mechTypes       [0] MechTypeList,
-           reqFlags        [1] ContextFlags  OPTIONAL,
-           mechToken       [2] OCTET STRING  OPTIONAL,
-           mechListMIC     [3] OCTET STRING  OPTIONAL,
-           ...
-       }
-       ContextFlags ::= BIT STRING {
-           delegFlag       (0),
-           mutualFlag      (1),
-           replayFlag      (2),
-           sequenceFlag    (3),
-           anonFlag        (4),
-           confFlag        (5),
-           integFlag       (6)
-       }
-
-   This is the syntax for the inner token of the initial negotiation
-   message.
-
-   mechTypes
-
-         This field contains one or more security mechanisms available
-         for the initiator in preference order (favorite choice first).
-
-   reqFlags
-
-         This field, if present, contains the service options that are
-         requested to establish the context.  The context flags SHOULD
-         be filled in from the req_flags parameter of
-         GSS_Init_sec_context().  This field SHALL NOT have impact on
-         the negotiation.
-
-   mechToken
-
-         This field, is present, contains the optimistic security
-         mechanism token.
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                 [Page 10]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-   mechlistMIC
-
-         This field, is present, contains a MIC token, which is computed
-         according to Section 5, for the mechanism list in the initial
-         negotiation message.
-
-
-4.2.2  negTokenResp
-
-       NegTokenResp ::= SEQUENCE {
-           negResult       [0] ENUMERATED {
-               accept_completed    (0),
-               accept_incomplete   (1),
-               reject              (2),
-               request_mic         (3)
-           },
-           supportedMech   [1] MechType      OPTIONAL,
-           responseToken   [2] OCTET STRING  OPTIONAL,
-           mechListMIC     [3] OCTET STRING  OPTIONAL,
-           ...
-       }
-
-   This is the syntax for all subsequent negotiation messages.
-
-   negResult
-
-         This field contains the state of the negotiation.  This can be:
-
-         accept_completed
-            No further negotiation message from the peer is expected,
-            and the security context is established for the sender.
-
-         accept_incomplete
-            At least one more negotiation message from the peer is
-            needed to establish the security context.
-
-         reject
-            The sender terminates the negotiation.
-
-         request_mic
-            The sender indicates that the exchange of MIC tokens, as
-            described in Section 5, will be REQUIRED if per-message
-            integrity services are available on the mechanism context to
-            be established.  This value SHALL only be present in the
-            first reply from the target.
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                 [Page 11]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-   supportedMech
-
-         This field SHALL only be present in the first reply from the
-         target.  It is a choice from the mechanism(s) offered by the
-         initiator.
-
-   ResponseToken
-
-         The field, if present, contains tokens specific to the
-         mechanism selected.
-
-   mechlistMIC
-
-         This field, is present, contains a MIC token, which is computed
-         according to Section 5, for the mechanism list in the initial
-         negotiation message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                 [Page 12]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-5.  Processing of mechListMIC
-
-   If the mechanism selected by the negotiation does not support
-   integrity protection, then no mechlistMIC token is used.  Otherwise
-   if the initiator's preferred mechanism is accepted and it is also the
-   most preferred mechanism available for the acceptor (there is no
-   mechanism which, had it been present in the mechanism list, the
-   acceptor would have preferred over the accepted mechanism), then the
-   MIC token exchange, as described later in this section, is OPTIONAL.
-   In all other cases, MIC tokens MUST be exchanged after the mechanism
-   context is fully established.
-
-   It is assumed that per-message integrity services are available on
-   the established mechanism context in the following procedure for
-   processing MIC tokens of the initiator's mechanism list.
-
-   a) The mechlistMIC token (or simply the MIC token) is computed
-      through invoking GSS_GetMIC(): the input context_handle is the
-      established mechanism context, the input qop_req is 0, and the
-      input message is the mechTypes field in the initial negotiation
-      message (only the "value" portion, omitting the tag and length, of
-      the ASN.1 encoding for that field is included).
-
-   b) If the selected mechanism uses an even number of mechanism tokens
-      (namely the acceptor sends the last mechanism token), the acceptor
-      does the following when emitting the negotiation message
-      containing the last mechanism token: if the MIC token exchange is
-      not required, GSS_Accept_sec_context() either indicates
-      GSS_S_COMPLETE and does not include a mechlistMIC token, or
-      indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token
-      and an accept_incomplete state; if the MIC token exchange is
-      required, GSS_Accept_sec_context() indicates
-      GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token.
-      Acceptors who wish to be compatible with legacy Windows SPNEGO
-      implementations as described in Appendix B shall not generate a
-      mechlistMIC token when the MIC token exchange is not required.
-      The initiator then processes the last mechanism token, and does
-      one of the following:
-
-      (I) If a mechlistMIC token was included, and is correctly
-         verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE.  The
-         output negotiation message contains a mechlistMIC token, and an
-         accept_complete state.  The acceptor MUST then verify this
-         mechlistMIC token.
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                 [Page 13]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-      (II) If a mechlistMIC token was included but is incorrect, the
-         negotiation SHALL be terminated.  GSS_Accept_sec_context()
-         indicates GSS_S_DEFECTIVE_TOKEN.
-
-      (III) If no mechlistMIC token was included, and the MIC token
-         exchange is not required, GSS_Init_sec_context() indicates
-         GSS_S_COMPLETE with no output token.
-
-      (IV) If no mechlistMIC token was included, but the MIC token
-         exchange is required, the negotiation SHALL be terminated.
-         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
-
-   c) In the case that the chosen mechanism uses an odd number of
-      mechanism tokens (namely the initiator sends the last mechanism
-      token), the initiator does the following when emitting the
-      negotiation message containing the last mechanism token: if the
-      negResult state was request_mic in the first reply from the
-      target, a mechlistMIC token MUST be included, otherwise the
-      mechlistMIC token is OPTIONAL.  GSS_Init_sec_context() indicates
-      GSS_S_CONTINUE_NEEDED.  Initiators who wish to be compatible with
-      legacy Windows SPNEGO implementations as described in Appendix B
-      shall not generate a mechlistMIC token when the MIC token exchange
-      is not required.  The acceptor then processes the last mechanism
-      token, and does one of the following:
-
-      (I) If a mechlistMIC token was included, and is correctly
-         verified, GSS_Accept_sec_context() indicates GSS_S_COMPLETE.
-         The output negotiation message contains a mechlistMIC token,
-         and an accept_complete state.  The initiator MUST then verify
-         this mechlistMIC token.
-
-      (II) If a mechlistMIC token was included but is incorrect, the
-         negotiation SHALL be terminated.  GSS_Accept_sec_context()
-         indicates GSS_S_DEFECTIVE_TOKEN.
-
-      (III) If no mechlistMIC token was included and the mechlistMIC
-         token exchange is not required, GSS_Accept_sec_context()
-         indicates GSS_S_COMPLETE.  The output negotiation message
-         contains an accept_complete state.
-
-      (IV) If no mechlistMIC token was included and the acceptor sent a
-         request_mic state in the first reply message (the exchange of
-         MIC tokens is required), the negotiation SHALL be terminated.
-         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                 [Page 14]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-6.  Extensibility
-
-   Two mechanisms are provided by extensibility.  First, the ASN.1
-   structures in this specification MAY be expanded by IETF standards
-   action.  Implementations receiving unknown fields MUST ignore these
-   fields.
-
-   Secondly, OIDs corresponding to a desired mechanism attribute may be
-   included in the set of preferred mechanisms by an initiator.  The
-   acceptor can choose to honor this request by preferring mechanisms
-   that have that attribute.  Future work within the Kitten working
-   group is expected to standardize common attributes that SPNEGO
-   mechanisms may wish to support.  At this time it is sufficient to say
-   that initiators MAY include OIDs that do not correspond to mechanisms
-   but instead correspond to desired mechanism attributes in their
-   requests.  Such OIDs MAY influence the acceptor's choice of
-   mechanism.  As discussed in Section 5, if there are mechanisms that
-   if present in the initiator's list of mechanisms might be preferred
-   by the acceptor to the initiator's preferred mechanism, the acceptor
-   MUST demand the MIC token exchange.  As a consequence, acceptors MUST
-   demand the MIC token exchange if they support negotiation of
-   attributes not available in the initiator's preferred mechanism
-   regardless of whether the initiator actually requested these
-   attributes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                 [Page 15]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-7.  Security Considerations
-
-   In order to produce the MIC token for the mechanism list, the
-   mechanism must provide integrity protection.  When the selected
-   mechanism does not support integrity protection, then the negotiation
-   is vulnerable: an active attacker can force it to use a security
-   mechanism that is not mutually preferred but is acceptable anyway to
-   the target.
-
-   When per-message integrity services are available on the established
-   mechanism context, and there was an alteration of the mechanism list
-   by an adversary such that a common mechanism that is not mutually
-   preferred could be selected, this protocol provides the following
-   guarantees: if the last mechanism token is sent by the initiator,
-   both peers shall fail; if the last mechanism token is sent by the
-   acceptor, the acceptor shall not complete and the initiator at worst
-   shall complete with its preferred mechanism being selected.  The
-   negotiation may not be terminated if an alteration was made but it
-   had no material impact.
-
-   The protection of the negotiation depends on the strength of the
-   integrity protection.  In particular, the strength of SPNEGO is no
-   stronger than the integrity protection of the weakest mechanism
-   acceptable to GSS-API peers.
-
-   In all cases, the communicating peers are exposed to the denial of
-   service threat.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                 [Page 16]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-8.  Acknowledgments
-
-   The authors wish to thank Nicolas Williams, Ken Raeburn, Jeff Altman,
-   Cristian Ilac and Martin Rex for their comments and suggestions on
-   earlier versions of this document.
-
-   Eric Baize and Denis Pinkas wrote the original SPNEGO specification
-   [RFC2478], of which some of the text has been retained in this
-   document.
-
-9  References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
-              Negotiation Mechanism", RFC 2478, December 1998.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding Rules 
-              (BER), Canonical Encoding Rules (CER) and Distinguished 
-              Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 
-              ISO/IEC International Standard 8825-1:1998.
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: lzhu@microsoft.com
-
-
-   Paul Leach
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: paulle@microsoft.com
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                 [Page 17]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: karthikj@microsoft.com
-
-
-   Sam Hartman
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA  02139
-   US
-
-   EMail: hartmans@mit.edu
-
-
-   Wyllys Ingersoll
-   Sun Microsystems
-   1775 Wiehle Avenue, 2nd Floor
-   Reston, VA  20190
-   US
-
-   EMail: wyllys.ingersoll@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                 [Page 18]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-Appendix A.  GSS-API Negotiation Support API
-
-   In order to provide to a GSS-API caller (either the initiator or the
-   target or both) the ability to choose among the set of supported
-   mechanisms a reduced set of mechanisms for negotiation, two
-   additional APIs are defined:
-
-   o  GSS_Get_neg_mechs() indicates the set of security mechanisms
-      available on the local system to the caller for negotiation, based
-      on the credentials being used.
-   o  GSS_Set_neg_mechs() specifies the set of security mechanisms to be
-      used on the local system by the caller for negotiation, for the
-      given credentials.
-
-A.1  GSS_Set_neg_mechs call
-
-   Inputs:
-
-   o  cred_handle CREDENTIAL HANDLE, -- NULL specifies default
-      -- credentials
-   o  mech_set SET OF OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the set of security mechanisms
-      available for negotiation has been set to mech_set.
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to specify the set of security mechanisms that may be
-   negotiated with the credential identified by cred_handle.  This call
-   is intended for support of specialized callers who need to restrict
-   the set of negotiable security mechanisms from the set of all
-   security mechanisms available to the caller (based on available
-   credentials).  Note that if more than one mechanism is specified in
-   mech_set, the order in which those mechanisms are specified implies a
-   relative preference.
-
-A.2  GSS_Get_neg_mechs call
-
-   Input:
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                 [Page 19]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-   o  cred_handle CREDENTIAL HANDLE -- NULL specifies default
-      -- credentials
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  mech_set SET OF OBJECT IDENTIFIER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the set of security mechanisms
-      available for negotiation has been returned in mech_set.
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to determine the set of security mechanisms available
-   for negotiation with the credential identified by cred_handle.  This
-   call is intended for support of specialized callers who need to
-   reduce the set of negotiable security mechanisms from the set of
-   supported security mechanisms available to the caller (based on
-   available credentials).
-
-   Note: The GSS_Indicate_mechs() function indicates the full set of
-   mechanism types available on the local system.  Since this call has
-   no input parameter, the returned set is not necessarily available for
-   all credentials.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                 [Page 20]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-Appendix B.  Changes since RFC2478
-
-      SPNEGO implementations in Windows 2000/Windows XP/Windows Server
-      2003 have the following behavior: no mechlistMIC is produced, and
-      mechlistMIC is not processed if one is provided; if the initiator
-      sends the last mechanism token, the acceptor will send back a
-      negotiation token with an accept_complete state and no mechlistMIC
-      token.  In addition, the OID (1.2.840.48018.1.2.2) can be used to
-      identify the GSS-API Kerberos Version 5 mechanism.
-
-      The following changes have been made to be compatible with these
-      legacy implementations.
-
-      *  NegTokenTarg is changed to negTokenResp and it is the message
-         format for all subsequent negotiation tokens.
-      *  NegTokenInit is the message for the initial token and that
-         token only.
-      *  mechTypes in negTokenInit is not optional.
-      *  negResult is not optional in the negTokenResp token.
-      *  Two MIC tokens are exchanged, one in each direction.
-      *  If the selected mechanism is also the most preferred mechanism
-         for both peers, it is safe to omit the MIC tokens.
-
-      If at least one of the two peers implements the pseudo mechanism
-      in this document, the negotiation is protected.
-
-      The following changes are to address the problems in RFC 2478.
-
-      *  reqFlags is not protected therefore it should not impact the
-         negotiation.
-      *  DER encoding is required.
-      *  GSS_GetMIC() input is clarified.
-      *  Per-message integrity services are requested for the negotiated
-         mechanism.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                 [Page 21]
-
-Internet-Draft       GSS-API Negotiation Mechanism         November 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.               Expires May 22, 2005                 [Page 22]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-2478bis-02.txt b/doc/standardisation/draft-ietf-kitten-2478bis-02.txt
deleted file mode 100644
index d63f4f6b8..000000000
--- a/doc/standardisation/draft-ietf-kitten-2478bis-02.txt
+++ /dev/null
@@ -1,1405 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                                  P. Leach
-Obsoletes: 2478 (if approved)                              K. Jaganathan
-Expires: June 1, 2005                              Microsoft Corporation
-                                                            W. Ingersoll
-                                                        Sun Microsystems
-                                                        December 1, 2004
-
-
-         The Simple and Protected GSS-API Negotiation Mechanism
-                       draft-ietf-kitten-2478bis
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on June 1, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document specifies a negotiation mechanism for the Generic
-   Security Service Application Program Interface (GSS-API) which is
-   described in RFC 2743.
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                  [Page 1]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   GSS-API peers can use this negotiation mechanism to choose from a
-   common set of security mechanisms.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
-   3.  Negotiation Protocol . . . . . . . . . . . . . . . . . . . . .  6
-     3.1   Negotiation Description  . . . . . . . . . . . . . . . . .  6
-     3.2   Negotiation Procedure  . . . . . . . . . . . . . . . . . .  7
-   4.  Token Definitions  . . . . . . . . . . . . . . . . . . . . . .  9
-     4.1   Mechanism Types  . . . . . . . . . . . . . . . . . . . . .  9
-     4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . .  9
-       4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 10
-       4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 11
-   5.  Processing of mechListMIC  . . . . . . . . . . . . . . . . . . 13
-   6.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 16
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
-   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
-   10.   Normative References . . . . . . . . . . . . . . . . . . . . 19
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
-   A.  GSS-API Negotiation Support API  . . . . . . . . . . . . . . . 21
-     A.1   GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 21
-     A.2   GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 21
-   B.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 23
-       Intellectual Property and Copyright Statements . . . . . . . . 25
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                  [Page 2]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-1.  Introduction
-
-   The GSS-API [RFC2743] provides a generic interface which can be
-   layered atop different security mechanisms such that if communicating
-   peers acquire GSS-API credentials for the same security mechanism,
-   then a security context may be established between them (subject to
-   policy).  However, GSS-API does not prescribe the method by which
-   GSS-API peers can establish whether they have a common security
-   mechanism.
-
-   The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
-   defined here is a pseudo security mechanism, represented by the
-   Object Identifier iso.org.dod.internet.security.mechanism.snego
-   (1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band
-   whether their credentials share common GSS-API security mechanism(s),
-   and if so, to invoke normal security context establishment for a
-   selected common security mechanism.  This is most useful for
-   applications which are based on GSS-API implementations and share
-   multiple mechanisms between the peers.
-
-   The SPNEGO mechanism negotiation is based on the following
-   negotiation model: the initiator proposes a list of security
-   mechanism(s), in decreasing preference order (favorite choice first),
-   the acceptor (also known as the target) either accepts the
-   initiator's preferred security mechanism (the first in the list), or
-   chooses one that is available from the offered list, or rejects the
-   proposed value(s).  The target then informs the initiator of its
-   choice.
-
-   Once a common security mechanism is chosen, mechanism-specific
-   options MAY be negotiated as part of the selected mechanism's context
-   establishment.  These negotiations (if any) are internal to the
-   mechanism and opaque to the SPNEGO protocol.  As such they are
-   outside the scope of this document.
-
-   If per-message integrity services are available on the established
-   mechanism security context, then the peers can exchange MIC tokens to
-   ensure that the mechanism list was not tampered with.  This MIC token
-   exchange is OPTIONAL if the selected mechanism is the most preferred
-   choice of both peers (see Section 5).
-
-   In order to avoid an extra round trip, the first security token of
-   the initiator's preferred mechanism SHOULD be embedded in the initial
-   negotiation message (as defined in Section 4.2).  This mechanism
-   token is referred to as the optimistic mechanism token in this
-   document.  If the selected mechanism matches the initiator's
-   preferred mechanism, no additional round trips need be incurred by
-   using this protocol.  In addition, using the optimistic mechanism
-
-
-
-Zhu, et al.               Expires June 1, 2005                  [Page 3]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   token allows the initiator to recover from non-fatal errors while
-   producing the first mechanism token before a mechanism can be
-   selected.  Implementations MAY omit the optimistic mechanism token to
-   avoid the cost of generating it in cases where the initiator's
-   preferred mechanism is not selected by the acceptor.
-
-   SPNEGO relies the concepts developed in the GSS-API specification
-   [RFC2743].  The negotiation data is encapsulated in context-level
-   tokens.  Therefore, callers of the GSS-API do not need to be aware of
-   the existence of the negotiation tokens but only of the new
-   pseudo-security mechanism.  A failure in the negotiation phase causes
-   a major status code to be returned: GSS_S_BAD_MECH.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                  [Page 4]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                  [Page 5]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-3.  Negotiation Protocol
-
-   When the established mechanism context provides integrity protection,
-   the mechanism negotiation can be protected.  When acquiring
-   negotiated security mechanism tokens, per-message integrity services
-   are always requested by the SPNEGO mechanism.
-
-   When the established mechanism context supports per-message integrity
-   services, SPNEGO guarantees that the selected mechanism is mutually
-   preferred.
-
-   This section describes the negotiation process of this protocol.
-
-3.1  Negotiation Description
-
-   The first negotiation token sent by the initiator contains an ordered
-   list of mechanisms (in decreasing preference order, favorite
-   mechanism first), and optionally the initial mechanism token for the
-   preferred mechanism of the initiator (i.e., the first in the list).
-   The list of security mechanisms available for negotiation is based on
-   the credentials being used.
-
-   The target then processes the token from the initiator.  This will
-   result in one of four possible states (as defined in Section 4.2.2):
-   accept_completed, accept_incomplete, reject, or request_mic.  A
-   reject state will terminate the negotiation;  an accept_completed
-   state indicates that not only was the initiator-selected mechanism
-   acceptable to the target, but also that the initial mechanism token
-   was sufficient to complete the authentication;  an accept_incomplete
-   state indicates that further message exchange is needed but the MIC
-   token exchange as described in Section 5 is OPTIONAL;  a request_mic
-   state (this state can only be present in the first reply message from
-   the target) indicates the MIC token exchange is REQUIRED if
-   per-message integrity services are available.
-
-   Unless the preference order is specified by the application (see
-   Appendix A), the policy by which the target chooses a mechanism is an
-   implementation-specific local matter.  In the absence of an
-   application specified preference order or other policy, the target
-   SHALL choose the first mechanism in the initiator proposed list for
-   which it has valid credentials.
-
-   In case of a successful negotiation, the security mechanism in the
-   first reply message represents the value suitable for the target,
-   picked up from the list offered by the initiator.  A context level
-   token for a reject state is OPTIONAL.
-
-   Once a mechanism has been selected, the tokens specific to the
-
-
-
-Zhu, et al.               Expires June 1, 2005                  [Page 6]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   selected mechanism are carried within the negotiation tokens.
-
-   Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the
-   mechanism list received by the target.
-
-   To avoid conflicts with the use of MIC tokens by SPNEGO,
-   partially-established contexts are not used for per-message calls:
-   the prot_ready_state [RFC2743] will be false even if the underlying
-   mechanism would return true natively.
-
-3.2  Negotiation Procedure
-
-   The basic form of the procedure assumes that per-message integrity
-   services are available on the established mechanism context, and it
-   is summarized as follows:
-
-   (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
-      but requests that SPNEGO be used.  SPNEGO can either be explicity
-      requested or accepted as the default mechanism.
-
-   (b) The initiator GSS-API implementation emits a negotiation token
-      containing a list of one or more security mechanisms that are
-      available based on the credentials used for this context
-      establishment, and optionally the initial mechanism token for the
-      first mechanism in the list.
-
-   (c) The GSS-API initiator application sends the token to the target
-      application.  The GSS-API target application deposits the token by
-      invoking GSS_Accept_sec_context().  The acceptor will do one of
-      the following:
-
-      (I) If none of the proposed mechanisms are acceptable, the
-         negotiation SHALL be terminated.  GSS_Accept_sec_context
-         indicates GSS_S_BAD_MECH.  The acceptor MAY output a
-         negotiation token containing a reject state.
-
-      (II) If either the initiator's preferred mechanism is not accepted
-         by the target or this mechanism is accepted but it is not the
-         acceptor's most preferred mechanism (see Section 3.1 and
-         Section 5), GSS_Accept_sec_context() indicates
-         GSS_S_CONTINUE_NEEDED.  The acceptor MUST output a negotiation
-         token containing a request_mic state.
-
-      (III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE
-         or GSS_S_CONTINUE_NEEDED depending on if at least one
-         additional negotiation token from the initiator is needed to
-         establish this context.  The acceptor outputs a negotiation
-         token containing an accept_complete or accept_incomplete state,
-
-
-
-Zhu, et al.               Expires June 1, 2005                  [Page 7]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-         respectively.
-
-      If the initiator's preferred mechanism is accepted, and an
-      optimistic mechanism token was included, this mechanism token MUST
-      be deposited to the selected mechanism by invoking
-      GSS_Accept_sec_context() and if a response mechanism token is
-      emitted, it MUST be included in the response negotiation token.
-      Otherwise, the target will not emit a response mechanism token in
-      the first reply.
-
-   (d) The GSS-API target application returns the negotiation token to
-      the initiator application.  The GSS-API initiator application
-      deposits the token by invoking GSS_Init_sec_context().  The
-      security context initialization is then continued according to the
-      standard GSS-API conventions for the selected mechanism, where the
-      tokens of the selected mechanism are encapsulated until the
-      GSS_S_COMPLETE is returned for both the initiator and the target
-      by the selected security mechanism.
-
-   (e) MIC tokens are then either skipped or exchanged according to
-      Section 5.
-
-   Note that the *_req_flag input parameters for context establishment
-   are relative to the selected mechanism, as are the *_state output
-   parameters.  i.e., these parameters are not applicable to the
-   negotiation process per se.
-
-   On receipt of a negotiation token on the target side, a GSS-API
-   implementation that does not support negotiation would indicate the
-   GSS_S_BAD_MECH status as if a particular basic security mechanism had
-   been requested and was not supported.
-
-   When GSS_Acquire_cred is invoked with this negotiation mechanism in
-   the desired_mechs, an implementation-specific default credential is
-   used to carry on the negotiation.  A set of mechanisms as specified
-   locally by the system administrator is then available for
-   negotiation.  If there is a desire for the caller to make its own
-   choice, then an additional API has to be used (see Appendix A).
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                  [Page 8]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-4.  Token Definitions
-
-   The type definitions in this section assume an ASN.1 module
-   definition of the following form:
-
-
-      SPNEGOASNOneSpec {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) mechanism(5) snego (2) modules(4) spec2(2)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      -- rest of definitions here
-
-      END
-
-
-   This specifies that the tagging context for the module will be
-   explicit and non-automatic.
-
-   The encoding of SPNEGO protocol messages shall obey the Distinguished
-   Encoding Rules (DER) of ASN.1 as described in [X690].
-
-4.1  Mechanism Types
-
-   In this negotiation model, each OID represents one GSS-API mechanism
-   or one variant (see Section 6) of it according to [RFC2743].
-
-
-       MechType ::= OBJECT IDENTIFIER
-           -- OID represents each security mechanism as suggested by
-           -- [RFC2743]
-
-       MechTypeList ::= SEQUENCE OF MechType
-
-
-4.2  Negotiation Tokens
-
-   The syntax of the initial negotiation tokens follows the
-   initialContextToken syntax defined in Section 3.1 of [RFC2743].  The
-   SPNEGO pseudo mechanism is identified by the Object Identifier
-   specified in Section 1.  Subsequent tokens are not encapsulated in
-   this GSS-API generic token framing.
-
-   This section specifies the syntax of the inner token for the initial
-   message and the syntax of subsequent context establishment tokens.
-
-       NegotiationToken ::= CHOICE {
-           negTokenInit    [0] NegTokenInit,
-
-
-
-Zhu, et al.               Expires June 1, 2005                  [Page 9]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-           negTokenResp    [1] negTokenResp
-       }
-
-
-
-4.2.1  negTokenInit
-
-       NegTokenInit ::= SEQUENCE {
-           mechTypes       [0] MechTypeList,
-           reqFlags        [1] ContextFlags  OPTIONAL,
-           mechToken       [2] OCTET STRING  OPTIONAL,
-           mechListMIC     [3] OCTET STRING  OPTIONAL,
-           ...
-       }
-       ContextFlags ::= BIT STRING {
-           delegFlag       (0),
-           mutualFlag      (1),
-           replayFlag      (2),
-           sequenceFlag    (3),
-           anonFlag        (4),
-           confFlag        (5),
-           integFlag       (6)
-       }
-
-   This is the syntax for the inner token of the initial negotiation
-   message.
-
-   mechTypes
-
-         This field contains one or more security mechanisms available
-         for the initiator in decreasing preference order (favorite
-         choice first).
-
-   reqFlags
-
-         This field, if present, contains the service options that are
-         requested to establish the context.  The context flags SHOULD
-         be filled in from the req_flags parameter of
-         GSS_Init_sec_context().  This field SHALL NOT have impact on
-         the negotiation.
-
-   mechToken
-
-         This field, if present, contains the optimistic mechanism
-         token.
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 10]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   mechlistMIC
-
-         This field, if present, contains a MIC token for the mechanism
-         list in the initial negotiation message.  This MIC token is
-         computed according to Section 5.
-
-
-4.2.2  negTokenResp
-
-       NegTokenResp ::= SEQUENCE {
-           negResult       [0] ENUMERATED {
-               accept_completed    (0),
-               accept_incomplete   (1),
-               reject              (2),
-               request_mic         (3)
-           }                                 OPTIONAL,
-             -- REQUIRED in the first reply from the target
-           supportedMech   [1] MechType      OPTIONAL,
-             -- present only in the first reply from the target
-           responseToken   [2] OCTET STRING  OPTIONAL,
-           mechListMIC     [3] OCTET STRING  OPTIONAL,
-           ...
-       }
-
-   This is the syntax for all subsequent negotiation messages.
-
-   negResult
-
-         This field, if present, contains the state of the negotiation.
-         This can be:
-
-         accept_completed
-
-            No further negotiation message from the peer is expected,
-            and the security context is established for the sender.
-
-         accept_incomplete
-
-            At least one more negotiation message from the peer is
-            needed to establish the security context.
-
-         reject
-
-            The sender terminates the negotiation.
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 11]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-         request_mic
-
-            The sender indicates that the exchange of MIC tokens, as
-            described in Section 5, will be REQUIRED if per-message
-            integrity services are available on the mechanism context to
-            be established.  This value SHALL only be present in the
-            first reply from the target.
-
-         This field is REQUIRED in the first reply from the target, and
-         it is OPTIONAL thereafter.
-
-   supportedMech
-
-         This field SHALL only be present in the first reply from the
-         target.  It MUST be one of the mechanism(s) offered by the
-         initiator.
-
-   ResponseToken
-
-         This field, if present, contains tokens specific to the
-         mechanism selected.
-
-   mechlistMIC
-
-         This field, if present, contains a MIC token for the mechanism
-         list in the initial negotiation message.  This MIC token is
-         computed according to Section 5.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 12]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-5.  Processing of mechListMIC
-
-   If the mechanism selected by the negotiation does not support
-   integrity protection, then no mechlistMIC token is used.
-
-   Otherwise if the accepted mechanism is the most preferred mechanism
-   of both the initiator and the acceptor, then the MIC token exchange,
-   as described later in this section, is OPTIONAL.  A mechanism is the
-   acceptor's most preferred mechanism if there is no other mechanism
-   which would have been preferred over the accepted mechanism if it had
-   been present in the received mechanism list.
-
-   In all other cases, MIC tokens MUST be exchanged after the mechanism
-   context is fully established.
-
-   It is assumed that per-message integrity services are available on
-   the established mechanism context in the following procedure for
-   processing MIC tokens of the initiator's mechanism list.
-
-   a) The mechlistMIC token (or simply the MIC token) is computed by
-      invoking GSS_GetMIC(): the input context_handle is the established
-      mechanism context, the input qop_req is 0, and the input message
-      is the mechTypes field in the initial negotiation message (only
-      the DER encoding of the type MechTypeList is included).
-
-   b) If the selected mechanism uses an even number of mechanism tokens
-      (namely the acceptor sends the last mechanism token), the acceptor
-      does the following when emitting the negotiation message
-      containing the last mechanism token: if the MIC token exchange is
-      not required, GSS_Accept_sec_context() either indicates
-      GSS_S_COMPLETE and does not include a mechlistMIC token, or
-      indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token
-      and an accept_incomplete state; if the MIC token exchange is
-      required, GSS_Accept_sec_context() indicates
-      GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token.
-      Acceptors that wish to be compatible with legacy Windows SPNEGO
-      implementations as described in Appendix B shall not generate a
-      mechlistMIC token when the MIC token exchange is not required.
-      The initiator then processes the last mechanism token, and does
-      one of the following:
-
-      (I) If a mechlistMIC token was included, and is correctly
-         verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE.  The
-         output negotiation message contains a mechlistMIC token, and an
-         accept_complete state.  The acceptor MUST then verify this
-         mechlistMIC token.
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 13]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-      (II) If a mechlistMIC token was included but is incorrect, the
-         negotiation SHALL be terminated.  GSS_Accept_sec_context()
-         indicates GSS_S_DEFECTIVE_TOKEN.
-
-      (III) If no mechlistMIC token was included, and the MIC token
-         exchange is not required, GSS_Init_sec_context() indicates
-         GSS_S_COMPLETE with no output token.
-
-      (IV) If no mechlistMIC token was included, but the MIC token
-         exchange is required, the negotiation SHALL be terminated.
-         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
-
-   c) In the case that the chosen mechanism uses an odd number of
-      mechanism tokens (namely the initiator sends the last mechanism
-      token), the initiator does the following when emitting the
-      negotiation message containing the last mechanism token: if the
-      negResult state was request_mic in the first reply from the
-      target, a mechlistMIC token MUST be included, otherwise the
-      mechlistMIC token is OPTIONAL.  In the case that the optimistic
-      mechanism token is the only mechanism token for the initiator's
-      preferred mechanism, the mechlistMIC token is OPTIONAL.
-      GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED.
-      Initiators that wish to be compatible with legacy Windows SPNEGO
-      implementations as described in Appendix B shall not generate a
-      mechlistMIC token when the MIC token exchange is not required.
-      The acceptor then processes the last mechanism token and does one
-      of the following:
-
-      (I) If a mechlistMIC token was included and is correctly verified,
-         GSS_Accept_sec_context() indicates GSS_S_COMPLETE.  The output
-         negotiation message contains a mechlistMIC token and an
-         accept_complete state.  The initiator MUST then verify this
-         mechlistMIC token.
-
-      (II) If a mechlistMIC token was included but is incorrect, the
-         negotiation SHALL be terminated.  GSS_Accept_sec_context()
-         indicates GSS_S_DEFECTIVE_TOKEN.
-
-      (III) If no mechlistMIC token was included but the mechlistMIC
-         token exchange is not required, GSS_Accept_sec_context()
-         indicates GSS_S_COMPLETE.  The output negotiation message
-         contains an accept_complete state.
-
-      (IV) In the case that the optimistic mechanism token is also the
-         last mechanism token (when the initiator's preferred mechanism
-         is accepted by the target) and the target sends a request_mic
-         state but the initiator did not send a mechlistMIC token, the
-         target then MUST include a mechlistMIC token in that first
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 14]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-         reply.  GSS_Accept_sec_context() indicates
-         GSS_S_CONTINUE_NEEDED.  The initiator MUST verify the received
-         mechlistMIC token and generate a mechlistMIC token to send back
-         to the target.  The target SHALL in turn verify the returned
-         mechlistMIC token and complete the negotiation.
-
-      (V) If no mechlistMIC token was included and the acceptor sent a
-         request_mic state in the first reply message (the exchange of
-         MIC tokens is required), the negotiation SHALL be terminated.
-         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 15]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-6.  Extensibility
-
-   Two mechanisms are provided for extensibility.  First, the ASN.1
-   structures in this specification MAY be expanded by IETF standards
-   action.  Implementations receiving unknown fields MUST ignore these
-   fields.
-
-   Secondly, OIDs corresponding to a desired mechanism attribute may be
-   included in the set of preferred mechanisms by an initiator.  The
-   acceptor can choose to honor this request by preferring mechanisms
-   that have the included attributes.  Future work within the Kitten
-   working group is expected to standardize common attributes that
-   SPNEGO mechanisms may wish to support.  At this time it is sufficient
-   to say that initiators MAY include OIDs that do not correspond to
-   mechanisms but instead correspond to desired mechanism attributes in
-   their requests.  Such OIDs MAY influence the acceptor's choice of
-   mechanism.  As discussed in Section 5, if there are mechanisms that
-   if present in the initiator's list of mechanisms might be preferred
-   by the acceptor to the initiator's preferred mechanism, the acceptor
-   MUST demand the MIC token exchange.  As a consequence, acceptors MUST
-   demand the MIC token exchange if they support negotiation of
-   attributes not available in the initiator's preferred mechanism
-   regardless of whether the initiator actually requested these
-   attributes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 16]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-7.  Security Considerations
-
-   In order to produce the MIC token for the mechanism list, the
-   mechanism must provide integrity protection.  When the selected
-   mechanism does not support integrity protection, the negotiation is
-   vulnerable: an active attacker can force it to use a security
-   mechanism that is not mutually preferred but is acceptable to the
-   target.
-
-   This protocol provides the following guarantees when per-message
-   integrity services are available on the established mechanism context
-   and the mechanism list was altered by an adversary such that a
-   mechanism which is not mutually preferred could be selected:
-
-   o  if the last mechanism token is sent by the initiator, both peers
-      shall fail;
-   o  if the last mechanism token is sent by the acceptor, the acceptor
-      shall not complete and the initiator at worst shall complete with
-      its preferred mechanism being selected.
-
-   The negotiation may not be terminated if an alteration was made but
-   it had no material impact.
-
-   The protection of the negotiation depends on the strength of the
-   integrity protection.  In particular, the strength of SPNEGO is no
-   stronger than the integrity protection of the weakest mechanism
-   acceptable to GSS-API peers.
-
-   In all cases, the communicating peers are exposed to the denial of
-   service threat.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 17]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-8.  IANA Considerations
-
-   This document has no actions for IANA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 18]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-9.  Acknowledgments
-
-   The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,
-   Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments
-   and suggestions during development of this document.
-
-   Luke Howard provided a prototype of this protocol in Heimdal and
-   resolved several issues in the initial draft.
-
-   Eric Baize and Denis Pinkas wrote the original SPNEGO specification
-   [RFC2478] of which some of the text has been retained in this
-   document.
-
-10  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
-              Negotiation Mechanism", RFC 2478, December 1998.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding 
-              Rules (BER), Canonical Encoding Rules (CER) and 
-              Distinguished Encoding Rules (DER), ITU-T Recommendation 
-              X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: lzhu@microsoft.com
-
-
-   Paul Leach
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: paulle@microsoft.com
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 19]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: karthikj@microsoft.com
-
-
-   Wyllys Ingersoll
-   Sun Microsystems
-   1775 Wiehle Avenue, 2nd Floor
-   Reston, VA  20190
-   US
-
-   EMail: wyllys.ingersoll@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 20]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-Appendix A.  GSS-API Negotiation Support API
-
-   In order to provide to a GSS-API caller (either the initiator or the
-   target or both) the ability to choose among the set of supported
-   mechanisms a reduced set of mechanisms for negotiation, two
-   additional APIs are defined:
-
-   o  GSS_Get_neg_mechs() indicates the set of security mechanisms
-      available on the local system to the caller for negotiation, based
-      on the credentials being used.
-   o  GSS_Set_neg_mechs() specifies the set of security mechanisms to be
-      used on the local system by the caller for negotiation, for the
-      given credentials.
-
-A.1  GSS_Set_neg_mechs call
-
-   Inputs:
-
-   o  cred_handle CREDENTIAL HANDLE, -- NULL specifies default
-      -- credentials
-   o  mech_set SET OF OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the set of security mechanisms
-      available for negotiation has been set to mech_set.
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to specify the set of security mechanisms that may be
-   negotiated with the credential identified by cred_handle.  This call
-   is intended for support of specialized callers who need to restrict
-   the set of negotiable security mechanisms from the set of all
-   security mechanisms available to the caller (based on available
-   credentials).  Note that if more than one mechanism is specified in
-   mech_set, the order in which those mechanisms are specified implies a
-   relative preference.
-
-A.2  GSS_Get_neg_mechs call
-
-   Input:
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 21]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   o  cred_handle CREDENTIAL HANDLE -- NULL specifies default
-      -- credentials
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  mech_set SET OF OBJECT IDENTIFIER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the set of security mechanisms
-      available for negotiation has been returned in mech_set.
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to determine the set of security mechanisms available
-   for negotiation with the credential identified by cred_handle.  This
-   call is intended for support of specialized callers who need to
-   reduce the set of negotiable security mechanisms from the set of
-   supported security mechanisms available to the caller (based on
-   available credentials).
-
-   Note: The GSS_Indicate_mechs() function indicates the full set of
-   mechanism types available on the local system.  Since this call has
-   no input parameter, the returned set is not necessarily available for
-   all credentials.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 22]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-Appendix B.  Changes since RFC2478
-
-      SPNEGO implementations in Windows 2000/Windows XP/Windows Server
-      2003 have the following behavior: no mechlistMIC is produced and
-      mechlistMIC is not processed if one is provided; if the initiator
-      sends the last mechanism token, the acceptor will send back a
-      negotiation token with an accept_complete state and no mechlistMIC
-      token.  In addition, the OID (1.2.840.48018.1.2.2) can be used to
-      identify the GSS-API Kerberos Version 5 mechanism.
-
-      The following changes have been made to be compatible with these
-      legacy implementations.
-
-      *  NegTokenTarg is changed to negTokenResp and it is the message
-         format for all subsequent negotiation tokens.
-      *  NegTokenInit is the message for the initial negotiation message
-         and that message only.
-      *  mechTypes in negTokenInit is not optional.
-      *  Two MIC tokens are exchanged, one in each direction.
-      *  If the selected mechanism is also the most preferred mechanism
-         for both peers, it is safe to omit the MIC tokens.
-
-      If at least one of the two peers implements the pseudo mechanism
-      in this document, the negotiation is protected.
-
-      The following changes are to address the problems in RFC 2478.
-
-      *  reqFlags is not protected therefore it should not impact the
-         negotiation.
-      *  DER encoding is required.
-      *  GSS_GetMIC() input is clarified.
-      *  Per-message integrity services are requested for the negotiated
-         mechanism.
-
-   An implementation that conforms to this specification  will not
-   interoperate with a strict 2748 implementation.  Even if the new
-   implementation always sends a mechlistMIC token, it will still fail
-   to interoperate.  If it is a server, it will fail because it requests
-   a mechlistMIC token using an option that older implementations simply
-   do not support.  Clients will tend to fail as well.
-
-   As an alternative to the approach chosen in this specification, we
-   could have documented a correct behavior that is fully backward
-   compatible with RFC 2478 and included an appendix on how to
-   interoperate with existing incorrect implementations of RFC 2478.
-
-   As a practical matter, the SPNEGO implementers within the IETF have
-   valued interoperability with the Microsoft implementations.  We were
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 23]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   unable to choose to maintain reasonable security guarantees, maintain
-   interoperability with the Microsoft implementations and maintain
-   interoperability with correct implementations of RFC 2478.  The
-   working group was not aware of any RFC 2478 implementations.  Even if
-   there are RFC 2478 implementations, it is unlikely that they will
-   interoperate because of a critical flaw in the description of the
-   encoding of the mechanism list in RFC 2478.
-
-   With the approach taken in this specification, we get security
-   between new implementations all the time while maintaining
-   interoperability with the implementations we have within the IETF
-   community.  The working group believes that this justifies breaking
-   compatibility with a correct implementation of RFC 2478.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 24]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.               Expires June 1, 2005                 [Page 25]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-2478bis-04.txt b/doc/standardisation/draft-ietf-kitten-2478bis-04.txt
deleted file mode 100644
index 48c11d216..000000000
--- a/doc/standardisation/draft-ietf-kitten-2478bis-04.txt
+++ /dev/null
@@ -1,1570 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                                  P. Leach
-Obsoletes: 2478 (if approved)                              K. Jaganathan
-Expires: June 15, 2005                             Microsoft Corporation
-                                                            W. Ingersoll
-                                                        Sun Microsystems
-                                                       December 15, 2004
-
-
-         The Simple and Protected GSS-API Negotiation Mechanism
-                      draft-ietf-kitten-2478bis-04
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on June 15, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document specifies a negotiation mechanism for the Generic
-   Security Service Application Program Interface (GSS-API) which is
-   described in RFC 2743.
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                  [Page 1]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   GSS-API peers can use this negotiation mechanism to choose from a
-   common set of security mechanisms.
-
-   If per-message integrity services are available on the established
-   mechanism context, then the negotiation is protected against an
-   attacker forcing the selection of a mechanism not desired by the
-   peers.
-
-   This mechanism replaces RFC 2478 in order to fix defects in that
-   specification and to describe how to interoperate with
-   implementations of that specification commonly deployed on the
-   Internet.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
-   3.  Negotiation Protocol . . . . . . . . . . . . . . . . . . . . .  6
-     3.1   Negotiation Description  . . . . . . . . . . . . . . . . .  6
-     3.2   Negotiation Procedure  . . . . . . . . . . . . . . . . . .  7
-   4.  Token Definitions  . . . . . . . . . . . . . . . . . . . . . . 10
-     4.1   Mechanism Types  . . . . . . . . . . . . . . . . . . . . . 10
-     4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 10
-       4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 11
-       4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 12
-   5.  Processing of mechListMIC  . . . . . . . . . . . . . . . . . . 14
-   6.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 17
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
-   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
-   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 21
-   10.1  Normative References . . . . . . . . . . . . . . . . . . . . 21
-   10.2  Informative References . . . . . . . . . . . . . . . . . . . 21
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
-   A.  GSS-API Negotiation Support API  . . . . . . . . . . . . . . . 23
-     A.1   GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 23
-     A.2   GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 23
-   B.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 25
-   C.  mechListMIC Computation Example  . . . . . . . . . . . . . . . 27
-       Intellectual Property and Copyright Statements . . . . . . . . 28
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                  [Page 2]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-1.  Introduction
-
-   The GSS-API [RFC2743] provides a generic interface which can be
-   layered atop different security mechanisms such that if communicating
-   peers acquire GSS-API credentials for the same security mechanism,
-   then a security context may be established between them (subject to
-   policy).  However, GSS-API does not prescribe the method by which
-   GSS-API peers can establish whether they have a common security
-   mechanism.
-
-   The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
-   defined here is a pseudo security mechanism, represented by the
-   Object Identifier iso.org.dod.internet.security.mechanism.snego
-   (1.3.6.1.5.5.2), which enables GSS-API peers to determine in-band
-   whether their credentials support a common set of one or more GSS-API
-   security mechanisms, and if so, to invoke the normal security context
-   establishment for a selected common security mechanism.  This is most
-   useful for applications which depend on GSS-API implementations and
-   share multiple mechanisms between the peers.
-
-   The SPNEGO mechanism negotiation is based on the following model: the
-   initiator proposes a list of security mechanism(s), in decreasing
-   preference order (favorite choice first), the acceptor (also known as
-   the target) either accepts the initiator's preferred security
-   mechanism (the first in the list), or chooses one that is available
-   from the offered list, or rejects the proposed value(s).  The target
-   then informs the initiator of its choice.
-
-   Once a common security mechanism is chosen, mechanism-specific
-   options MAY be negotiated as part of the selected mechanism's context
-   establishment.  These negotiations (if any) are internal to the
-   mechanism and opaque to the SPNEGO protocol.  As such they are
-   outside the scope of this document.
-
-   If per-message integrity services are available on the established
-   mechanism security context, then the negotiation is protected to
-   ensure that the mechanism list has not been modified.  In cases where
-   an attacker could have materially influenced the negotiation, peers
-   exchange message integrity code (MIC) tokens to confirm the mechanism
-   list has not been modified.  If no action of an attacker could have
-   materially modified the outcome of the negotiation, the exchange of
-   MIC tokens is optional (see Section 5).  Allowing MIC tokens to be
-   optional in this case provides interoperability with existing
-   implementations while still protecting the negotiation.  This
-   interoperability comes at the cost of increased complexity.
-
-   In order to avoid an extra round trip, the first context
-   establishment token of the initiator's preferred mechanism SHOULD be
-
-
-
-Zhu, et al.              Expires June 15, 2005                  [Page 3]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   embedded in the initial negotiation message (as defined in Section
-   4.2).  (This mechanism token is referred to as the optimistic
-   mechanism token in this document.) In addition, using the optimistic
-   mechanism token allows the initiator to recover from non-fatal errors
-   encountered trying to produce the first mechanism token before a
-   mechanism can be selected.  Implementations MAY omit the optimistic
-   mechanism token in cases where the likelihood of the initiator's
-   preferred mechanism not being selected by the acceptor is significant
-   given the cost of generating it.
-
-   SPNEGO relies on the concepts developed in the GSS-API specification
-   [RFC2743].  The negotiation data is encapsulated in context-level
-   tokens.  Therefore, callers of the GSS-API do not need to be aware of
-   the existence of the negotiation tokens but only of the new
-   pseudo-security mechanism.  A failure in the negotiation phase causes
-   a major status code to be returned: GSS_S_BAD_MECH.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                  [Page 4]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                  [Page 5]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-3.  Negotiation Protocol
-
-   When the established mechanism context provides integrity protection,
-   the mechanism negotiation can be protected.  When acquiring
-   negotiated security mechanism tokens, per-message integrity services
-   are always requested by the SPNEGO mechanism.
-
-   When the established mechanism context supports per-message integrity
-   services, SPNEGO guarantees that the selected mechanism is mutually
-   preferred.
-
-   This section describes the negotiation process of this protocol.
-
-3.1  Negotiation Description
-
-   The first negotiation token sent by the initiator contains an ordered
-   list of mechanisms in decreasing preference order (favorite mechanism
-   first), and optionally the initial mechanism token for the preferred
-   mechanism of the initiator (i.e., the first in the list).  (Note that
-   the list MUST NOT contain mechanisms for which the client does not
-   have appropriate credentials.)
-
-   The target then processes the token from the initiator.  This will
-   result in one of four possible states (as defined in Section 4.2.2)
-   being returned in the reply message: accept_completed,
-   accept_incomplete, reject, or request_mic.  A reject state will
-   terminate the negotiation;  an accept_completed state indicates that
-   not only was the initiator-selected mechanism acceptable to the
-   target, but also that the optimistic mechanism token was sufficient
-   to complete the authentication;  an accept_incomplete state indicates
-   that further message exchange is needed but the MIC token exchange as
-   described in Section 5 is OPTIONAL;  a request_mic state (this state
-   can only be present in the first reply message from the target)
-   indicates the MIC token exchange is REQUIRED if per-message integrity
-   services are available.
-
-   Unless the preference order is specified by the application, the
-   policy by which the target chooses a mechanism is an
-   implementation-specific local matter.  In the absence of an
-   application specified preference order or other policy, the target
-   SHALL choose the first mechanism in the initiator proposed list for
-   which it has valid credentials.
-
-   In case of a successful negotiation, the security mechanism in the
-   first reply message represents the value suitable for the target,
-   chosen from the list offered by the initiator.
-
-   In case of an unsuccessful negotiation, the reject state is returned
-
-
-
-Zhu, et al.              Expires June 15, 2005                  [Page 6]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   and it is OPTIONAL to emit a context level negotiation token.
-
-   Once a mechanism has been selected, context establishment tokens
-   specific to the selected mechanism are carried within the negotiation
-   tokens.
-
-   Lastly, MIC tokens may be exchanged to ensure the authenticity of the
-   mechanism list received by the target.
-
-   To avoid conflicts with the use of MIC tokens by SPNEGO,
-   partially-established contexts MUST NOT be used for per-message
-   calls.  To guarantee this, the prot_ready_state [RFC2743] MUST be set
-   to false on return from GSS_Init_sec_context() and
-   GSS_Accept_sec_context() even if the underlying mechanism returned
-   true.
-
-3.2  Negotiation Procedure
-
-   The basic form of the procedure assumes that per-message integrity
-   services are available on the established mechanism context, and it
-   is summarized as follows:
-
-   (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
-      but requests that SPNEGO be used.  SPNEGO can either be explicity
-      requested or accepted as the default mechanism.
-
-   (b) The initiator GSS-API implementation emits a negotiation token
-      containing a list of one or more security mechanisms that are
-      available based on the credentials used for this context
-      establishment, and optionally the initial mechanism token for the
-      first mechanism in the list.
-
-   (c) The GSS-API initiator application sends the token to the target
-      application.  The GSS-API target application deposits the token by
-      invoking GSS_Accept_sec_context().  The acceptor will do one of
-      the following:
-
-
-         (I) If none of the proposed mechanisms are acceptable, the
-            negotiation SHALL be terminated.  GSS_Accept_sec_context
-            indicates GSS_S_BAD_MECH.  The acceptor MAY output a
-            negotiation token containing a reject state.
-
-         (II) If either the initiator's preferred mechanism is not
-            accepted by the target or this mechanism is accepted but it
-            is not the acceptor's most preferred mechanism (i.e., the
-            MIC token exchange as described in Section 5 is required),
-            GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED.
-
-
-
-Zhu, et al.              Expires June 15, 2005                  [Page 7]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-            The acceptor MUST output a negotiation token containing a
-            request_mic state.
-
-         (III) Otherwise if at least one additional negotiation token
-            from the initiator is needed to establish this context,
-            GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and
-            outputs a negotiation token containing an accept_incomplete
-            state.
-
-         (IV) Otherwise no additional negotiation token from the
-            initiator is needed to establish this context,
-            GSS_Accept_sec_context() indicates GSS_S_COMPLETE and
-            outputs a negotiation token containing an accept_complete
-            state.
-
-      If the initiator's preferred mechanism is accepted, and an
-      optimistic mechanism token was included, this mechanism token MUST
-      be deposited to the selected mechanism by invoking
-      GSS_Accept_sec_context() and if a response mechanism token is
-      emitted, it MUST be included in the response negotiation token.
-      Otherwise, the target will not emit a response mechanism token in
-      the first reply.
-
-   (d) The GSS-API target application returns the negotiation token to
-      the initiator application.  The GSS-API initiator application
-      deposits the token by invoking GSS_Init_sec_context().  The
-      security context initialization is then continued according to the
-      standard GSS-API conventions for the selected mechanism, where the
-      tokens of the selected mechanism are encapsulated in negotiation
-      messages (see Section 4) until the GSS_S_COMPLETE is returned for
-      both the initiator and the target by the selected security
-      mechanism.
-
-   (e) MIC tokens are then either skipped or exchanged according to
-      Section 5.
-
-   Note that the *_req_flag input parameters for context establishment
-   are relative to the selected mechanism, as are the *_state output
-   parameters.  i.e., these parameters are not applicable to the
-   negotiation process per se.
-
-   On receipt of a negotiation token on the target side, a GSS-API
-   implementation that does not support negotiation would indicate the
-   GSS_S_BAD_MECH status as if a particular basic security mechanism had
-   been requested and was not supported.
-
-   When a GSS-API credential is acquired for the SPNEGO mechanism the
-   implementation SHOULD produce a credential element for the SPNEGO
-
-
-
-Zhu, et al.              Expires June 15, 2005                  [Page 8]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   mechanism which internally contains GSS-API credential elements for
-   all mechanisms for which the principal has credentials available,
-   except for any mechanisms which are not to be negotiated, either as
-   per implementation-, site- or application-specific policy.  See
-   Appendix A for interfaces for expressing application policy.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                  [Page 9]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-4.  Token Definitions
-
-   The type definitions in this section assume an ASN.1 module
-   definition of the following form:
-
-
-      SPNEGOASNOneSpec {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) mechanism(5) snego (2) modules(4) spec2(2)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      -- rest of definitions here
-
-      END
-
-
-   This specifies that the tagging context for the module will be
-   explicit and non-automatic.
-
-   The encoding of SPNEGO protocol messages shall obey the Distinguished
-   Encoding Rules (DER) of ASN.1 as described in [X690].
-
-4.1  Mechanism Types
-
-   In this negotiation model, each OID represents one GSS-API mechanism
-   or one variant (see Section 6) of it according to [RFC2743].
-
-
-       MechType ::= OBJECT IDENTIFIER
-           -- OID represents each security mechanism as suggested by
-           -- [RFC2743]
-
-       MechTypeList ::= SEQUENCE OF MechType
-
-
-4.2  Negotiation Tokens
-
-   The syntax of the initial negotiation tokens follows the
-   initialContextToken syntax defined in Section 3.1 of [RFC2743].  The
-   SPNEGO pseudo mechanism is identified by the Object Identifier
-   specified in Section 1.  Subsequent tokens MUST NOT be encapsulated
-   in this GSS-API generic token framing.
-
-   This section specifies the syntax of the inner token for the initial
-   message and the syntax of subsequent context establishment tokens.
-
-       NegotiationToken ::= CHOICE {
-           negTokenInit    [0] NegTokenInit,
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 10]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-           negTokenResp    [1] negTokenResp
-       }
-
-
-
-4.2.1  negTokenInit
-
-       NegTokenInit ::= SEQUENCE {
-           mechTypes       [0] MechTypeList,
-           reqFlags        [1] ContextFlags  OPTIONAL,
-             -- maintained from RFC 2478 for backward compatibility,
-             -- RECOMMENDED to be left out
-           mechToken       [2] OCTET STRING  OPTIONAL,
-           mechListMIC     [3] OCTET STRING  OPTIONAL,
-           ...
-       }
-       ContextFlags ::= BIT STRING {
-           delegFlag       (0),
-           mutualFlag      (1),
-           replayFlag      (2),
-           sequenceFlag    (3),
-           anonFlag        (4),
-           confFlag        (5),
-           integFlag       (6)
-       }
-
-   This is the syntax for the inner token of the initial negotiation
-   message.
-
-   mechTypes
-
-         This field contains one or more security mechanisms available
-         for the initiator in decreasing preference order (favorite
-         choice first).
-
-   reqFlags
-
-         This field, if present, contains the service options that are
-         requested to establish the context.  The context flags SHOULD
-         be filled in from the req_flags parameter of
-         GSS_Init_sec_context().  This field SHALL NOT have impact on
-         the negotiation.
-
-   mechToken
-
-         This field, if present, contains the optimistic mechanism
-         token.
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 11]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   mechlistMIC
-
-         This field, if present, contains a MIC token for the mechanism
-         list in the initial negotiation message.  This MIC token is
-         computed according to Section 5.
-
-
-4.2.2  negTokenResp
-
-       NegTokenResp ::= SEQUENCE {
-           negState       [0] ENUMERATED {
-               accept_completed    (0),
-               accept_incomplete   (1),
-               reject              (2),
-               request_mic         (3)
-           }                                 OPTIONAL,
-             -- REQUIRED in the first reply from the target
-           supportedMech   [1] MechType      OPTIONAL,
-             -- present only in the first reply from the target
-           responseToken   [2] OCTET STRING  OPTIONAL,
-           mechListMIC     [3] OCTET STRING  OPTIONAL,
-           ...
-       }
-
-   This is the syntax for all subsequent negotiation messages.
-
-   negState
-
-         This field, if present, contains the state of the negotiation.
-         This can be:
-
-         accept_completed
-
-            No further negotiation message from the peer is expected,
-            and the security context is established for the sender.
-
-         accept_incomplete
-
-            At least one more negotiation message from the peer is
-            needed to establish the security context.
-
-         reject
-
-            The sender terminates the negotiation.
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 12]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-         request_mic
-
-            The sender indicates that the exchange of MIC tokens, as
-            described in Section 5, will be REQUIRED if per-message
-            integrity services are available on the mechanism context to
-            be established.  This value SHALL only be present in the
-            first reply from the target.
-
-         This field is REQUIRED in the first reply from the target, and
-         it is OPTIONAL thereafter.  When negState is absent the actual
-         state should be inferred from the state of the negotiated
-         mechanism context.
-
-   supportedMech
-
-         This field SHALL only be present in the first reply from the
-         target.  It MUST be one of the mechanism(s) offered by the
-         initiator.
-
-   ResponseToken
-
-         This field, if present, contains tokens specific to the
-         mechanism selected.
-
-   mechlistMIC
-
-         This field, if present, contains a MIC token for the mechanism
-         list in the initial negotiation message.  This MIC token is
-         computed according to Section 5.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 13]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-5.  Processing of mechListMIC
-
-   If the mechanism selected by the negotiation does not support
-   integrity protection, then no mechlistMIC token is used.
-
-   Otherwise, if the accepted mechanism is the most preferred mechanism
-   of both the initiator and the acceptor, then the MIC token exchange,
-   as described later in this section, is OPTIONAL.  A mechanism is the
-   acceptor's most preferred mechanism if there is no other mechanism
-   which, had it been present in the mechanism list, the acceptor would
-   have preferred over the accepted mechanism.
-
-   In all other cases, MIC tokens MUST be exchanged after the mechanism
-   context is fully established.
-
-   a) The mechlistMIC token (or simply the MIC token) is computed over
-      the mechanism list in the initial negotiation message by invoking
-      GSS_GetMIC() as follows: the input context_handle is the
-      established mechanism context, the input qop_req is 0, and the
-      input message is the DER encoding of the value of type
-      MechTypeList which is contained in the "mechTypes" field of the
-      NegTokenInit.  The input message is NOT the DER encoding of the
-      type "[0] MechTypeList".
-
-   b) If the selected mechanism exchanges an even number of mechanism
-      tokens (i.e., the acceptor sends the last mechanism token), the
-      acceptor does the following when emitting the negotiation message
-      containing the last mechanism token: if the MIC token exchange is
-      optional, GSS_Accept_sec_context() either indicates GSS_S_COMPLETE
-      and does not include a mechlistMIC token, or indicates
-      GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token and an
-      accept_incomplete state; if the MIC token exchange is required,
-      GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED, and
-      includes a mechlistMIC token.  Acceptors that wish to be
-      compatible with legacy Windows SPNEGO implementations as described
-      in Appendix B should not generate a mechlistMIC token when the MIC
-      token exchange is not required.  The initiator then processes the
-      last mechanism token, and does one of the following:
-
-      (I) If a mechlistMIC token was included, and is correctly
-         verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE.  The
-         output negotiation message contains a mechlistMIC token, and an
-         accept_complete state.  The acceptor MUST then verify this
-         mechlistMIC token.
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 14]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-      (II) If a mechlistMIC token was included but is incorrect, the
-         negotiation SHALL be terminated.  GSS_Init_sec_context()
-         indicates GSS_S_DEFECTIVE_TOKEN.
-
-      (III) If no mechlistMIC token was included, and the MIC token
-         exchange is not required, GSS_Init_sec_context() indicates
-         GSS_S_COMPLETE with no output token.
-
-      (IV) If no mechlistMIC token was included, but the MIC token
-         exchange is required, the negotiation SHALL be terminated.
-         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
-
-   c) In the case that the chosen mechanism exchanges an odd number of
-      mechanism tokens (i.e., the initiator sends the last mechanism
-      token), the initiator does the following when emitting the
-      negotiation message containing the last mechanism token: if the
-      negState was request_mic in the first reply from the target, a
-      mechlistMIC token MUST be included, otherwise the mechlistMIC
-      token is OPTIONAL.  (Note that the MIC token exchange is required
-      if a mechanism other than the initiator's first choice is chosen.)
-      In the case that the optimistic mechanism token is the only
-      mechanism token for the initiator's preferred mechanism, the
-      mechlistMIC token is OPTIONAL.  Whether or not the mechlistMIC
-      token is included, GSS_Init_sec_context() indicates
-      GSS_S_CONTINUE_NEEDED.  Initiators that wish to be compatible with
-      legacy Windows SPNEGO implementations as described in Appendix B
-      should not generate a mechlistMIC token when the MIC token
-      exchange is not required.  The acceptor then processes the last
-      mechanism token and does one of the following:
-
-      (I) If a mechlistMIC token was included and is correctly verified,
-         GSS_Accept_sec_context() indicates GSS_S_COMPLETE.  The output
-         negotiation message contains a mechlistMIC token and an
-         accept_complete state.  The initiator MUST then verify this
-         mechlistMIC token.
-
-      (II) If a mechlistMIC token was included but is incorrect, the
-         negotiation SHALL be terminated.  GSS_Accept_sec_context()
-         indicates GSS_S_DEFECTIVE_TOKEN.
-
-      (III) If no mechlistMIC token was included but the mechlistMIC
-         token exchange is not required, GSS_Accept_sec_context()
-         indicates GSS_S_COMPLETE.  The output negotiation message
-         contains an accept_complete state.
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 15]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-      (IV) In the case that the optimistic mechanism token is also the
-         last mechanism token (when the initiator's preferred mechanism
-         is accepted by the target) and the target sends a request_mic
-         state but the initiator did not send a mechlistMIC token, the
-         target then MUST include a mechlistMIC token in that first
-         reply.  GSS_Accept_sec_context() indicates
-         GSS_S_CONTINUE_NEEDED.  The initiator MUST verify the received
-         mechlistMIC token and generate a mechlistMIC token to send back
-         to the target.  The target SHALL in turn verify the returned
-         mechlistMIC token and complete the negotiation.
-
-      (V) If no mechlistMIC token was included and the acceptor sent a
-         request_mic state in the first reply message (the exchange of
-         MIC tokens is required), the negotiation SHALL be terminated.
-         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 16]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-6.  Extensibility
-
-   Two mechanisms are provided for extensibility.  First, the ASN.1
-   structures in this specification MAY be expanded by IETF standards
-   action.  Implementations receiving unknown fields MUST ignore these
-   fields.
-
-   Secondly, OIDs corresponding to a desired mechanism attribute (i.e.,
-   mechanism variants) may be included in the set of preferred
-   mechanisms by an initiator.  The acceptor can choose to honor this
-   request by preferring mechanisms that have the included attributes.
-   Future work within the Kitten working group is expected to
-   standardize common attributes that SPNEGO mechanisms may wish to
-   support.  At this time it is sufficient to say that initiators MAY
-   include OIDs that do not correspond to mechanisms.  Such OIDs MAY
-   influence the acceptor's choice of mechanism.  As discussed in
-   Section 5, if there are mechanisms that if present in the initiator's
-   list of mechanisms might be preferred by the acceptor to the
-   initiator's preferred mechanism, the acceptor MUST demand the MIC
-   token exchange.  As a consequence, acceptors MUST demand the MIC
-   token exchange if they support negotiation of attributes not
-   available in the initiator's preferred mechanism regardless of
-   whether the initiator actually requested these attributes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 17]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-7.  Security Considerations
-
-   In order to produce the MIC token for the mechanism list, the
-   mechanism must provide integrity protection.  When the selected
-   mechanism does not support integrity protection, the negotiation is
-   vulnerable: an active attacker can force it to use a security
-   mechanism that is not mutually preferred but is acceptable to the
-   target.
-
-   This protocol provides the following guarantees when per-message
-   integrity services are available on the established mechanism context
-   and the mechanism list was altered by an adversary such that a
-   mechanism which is not mutually preferred could be selected:
-
-   a) If the last mechanism token is sent by the initiator, both peers
-      shall fail;
-   b) If the last mechanism token is sent by the acceptor, the acceptor
-      shall not complete and the initiator at worst shall complete with
-      its preferred mechanism being selected.
-
-   The negotiation may not be terminated if an alteration was made but
-   it had no material impact.
-
-   The protection of the negotiation depends on the strength of the
-   integrity protection.  In particular, the strength of SPNEGO is no
-   stronger than the integrity protection of the weakest mechanism
-   acceptable to GSS-API peers.
-
-   In all cases, the communicating peers are exposed to the denial of
-   service threat.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 18]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-8.  IANA Considerations
-
-   This document has no actions for IANA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 19]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-9.  Acknowledgments
-
-   The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,
-   Jeff Altman, Tom Yu, Cristian Ilac and Martin Rex for their comments
-   and suggestions during development of this document.
-
-   Luke Howard provided a prototype of this protocol in Heimdal and
-   resolved several issues in the initial draft.
-
-   Eric Baize and Denis Pinkas wrote the original SPNEGO specification
-   [RFC2478] of which some of the text has been retained in this
-   document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 20]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-10.  References
-
-10.1  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding 
-              Rules (BER), Canonical Encoding Rules (CER) and 
-              Distinguished Encoding Rules (DER), ITU-T Recommendation 
-              X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
-
-10.2  Informative References
-
-   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
-              Negotiation Mechanism", RFC 2478, December 1998.
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: lzhu@microsoft.com
-
-
-   Paul Leach
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: paulle@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: karthikj@microsoft.com
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 21]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   Wyllys Ingersoll
-   Sun Microsystems
-   1775 Wiehle Avenue, 2nd Floor
-   Reston, VA  20190
-   US
-
-   EMail: wyllys.ingersoll@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 22]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-Appendix A.  GSS-API Negotiation Support API
-
-   In order to provide to a GSS-API caller (either the initiator or the
-   target or both) the ability to choose among the set of supported
-   mechanisms a reduced set of mechanisms for negotiation, two
-   additional APIs are defined:
-
-   o  GSS_Get_neg_mechs() indicates the set of security mechanisms
-      available on the local system to the caller for negotiation, for
-      which appropriate credentials are available.
-   o  GSS_Set_neg_mechs() specifies the set of security mechanisms to be
-      used on the local system by the caller for negotiation, for the
-      given credentials.
-
-A.1  GSS_Set_neg_mechs call
-
-   Inputs:
-
-   o  cred_handle CREDENTIAL HANDLE, -- NULL specifies default
-      -- credentials
-   o  mech_set SET OF OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the set of security mechanisms
-      available for negotiation has been set to mech_set.
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to specify the set of security mechanisms that may be
-   negotiated with the credential identified by cred_handle.  This call
-   is intended for support of specialized callers who need to restrict
-   the set of negotiable security mechanisms from the set of all
-   security mechanisms available to the caller (based on available
-   credentials).  Note that if more than one mechanism is specified in
-   mech_set, the order in which those mechanisms are specified implies a
-   relative preference.
-
-A.2  GSS_Get_neg_mechs call
-
-   Input:
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 23]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   o  cred_handle CREDENTIAL HANDLE -- NULL specifies default
-      -- credentials
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  mech_set SET OF OBJECT IDENTIFIER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the set of security mechanisms
-      available for negotiation has been returned in mech_set.
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to determine the set of security mechanisms available
-   for negotiation with the credential identified by cred_handle.  This
-   call is intended for support of specialized callers who need to
-   reduce the set of negotiable security mechanisms from the set of
-   supported security mechanisms available to the caller (based on
-   available credentials).
-
-   Note: The GSS_Indicate_mechs() function indicates the full set of
-   mechanism types available on the local system.  Since this call has
-   no input parameter, the returned set is not necessarily available for
-   all credentials.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 24]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-Appendix B.  Changes since RFC2478
-
-      SPNEGO implementations in Windows 2000/Windows XP/Windows Server
-      2003 have the following behavior: no mechlistMIC is produced and
-      mechlistMIC is not processed if one is provided; if the initiator
-      sends the last mechanism token, the acceptor will send back a
-      negotiation token with an accept_complete state and no mechlistMIC
-      token.  In addition, an incorrect OID (1.2.840.48018.1.2.2) can be
-      used to identify the GSS-API Kerberos Version 5 mechanism.
-
-      The following changes have been made to be compatible with these
-      legacy implementations.
-
-      *  NegTokenTarg is changed to negTokenResp and it is the message
-         format for all subsequent negotiation tokens.
-      *  NegTokenInit is the message for the initial negotiation message
-         and that message only.
-      *  mechTypes in negTokenInit is not optional.
-      *  If the selected mechanism is also the most preferred mechanism
-         for both peers, it is safe to omit the MIC tokens.
-
-      If at least one of the two peers implements the updated pseudo
-      mechanism in this document, the negotiation is protected.
-
-      The following changes are to address the problems in RFC 2478.
-
-      *  reqFlags is not protected therefore it should not impact the
-         negotiation.
-      *  DER encoding is required.
-      *  GSS_GetMIC() input is clarified.
-      *  Per-message integrity services are requested for the negotiated
-         mechanism.
-      *  Two MIC tokens are exchanged, one in each direction.
-
-   An implementation that conforms to this specification will not
-   interoperate with a strict 2748 implementation.  Even if the new
-   implementation always sends a mechlistMIC token, it will still fail
-   to interoperate.  If it is a server, it will fail because it requests
-   a mechlistMIC token using an option that older implementations simply
-   do not support.  Clients will tend to fail as well.
-
-   As an alternative to the approach chosen in this specification, we
-   could have documented a correct behavior that is fully backward
-   compatible with RFC 2478 and included an appendix on how to
-   interoperate with existing incorrect implementations of RFC 2478.
-
-   As a practical matter, the SPNEGO implementers within the IETF have
-   valued interoperability with the Microsoft implementations.  We were
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 25]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-   unable to choose to maintain reasonable security guarantees, maintain
-   interoperability with the Microsoft implementations and maintain
-   interoperability with correct implementations of RFC 2478.  The
-   working group was not aware of any RFC 2478 implementations deployed
-   on the Internet.  Even if there are such implementations, it is
-   unlikely that they will interoperate because of a critical flaw in
-   the description of the encoding of the mechanism list in RFC 2478.
-
-   With the approach taken in this specification, security is ensured
-   between new implementations all the time while maintaining
-   interoperability with the implementations deployed within the IETF
-   community.  The working group believes that this justifies breaking
-   compatibility with a correct implementation of RFC 2478.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 26]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-Appendix C.  mechListMIC Computation Example
-
-   The following is an example to illustrate how the mechListMIC field
-   would be computed.
-
-   The initial part of the DER encoding of NegTokenInit is constructed
-   as follows (the "nn" are length encodings, possibly longer than one
-   octet):
-
-      30 -- identifier octet for constructed SEQUENCE (NegTokenInit)
-      nn -- length
-
-         -- contents octets of the SEQUENCE begin with
-         -- DER encoding of "[0] MechTypeList":
-         A0 -- identifier octet for constructed [0]
-         nn -- length
-
-             -- contents of the constructed [0] are DER encoding
-             -- of MechTypeList (which is a SEQUENCE):
-             30 -- identifier octet for constructed SEQUENCE
-             nn -- length
-
-                -- contents octets of the SEQUENCE begin with
-                -- DER encoding of OBJECT IDENTIFIER:
-                06 -- identifier octet for primitive OBJECT IDENTIFIER
-                09 -- length
-                2A 86 48 86 F7 12 01 02 02 -- Kerberos V5
-                                           -- {1 2 840 113554 1 2 2}
-
-   If a mechlistMIC needs to be generated (according to the rules in
-   Section 5), it is computed by using the DER encoding of the type
-   MechTypeList data from the initiator's NegTokenInit token as input to
-   the GSS_GetMIC() function.  In this case, the MIC would be computed
-   over the following octets:
-
-      DER encoding of MechTypeList:
-      30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...
-
-   Note that the identifier octet and lengh octet(s) for constructed [0]
-   (A0 nn) are not included in the MIC computation.
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 27]
-
-Internet-Draft       GSS-API Negotiation Mechanism         December 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.              Expires June 15, 2005                 [Page 28]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-2478bis-05.txt b/doc/standardisation/draft-ietf-kitten-2478bis-05.txt
deleted file mode 100644
index 84e025677..000000000
--- a/doc/standardisation/draft-ietf-kitten-2478bis-05.txt
+++ /dev/null
@@ -1,1680 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                                  P. Leach
-Obsoletes: 2478 (if approved)                              K. Jaganathan
-Expires: July 27, 2005                             Microsoft Corporation
-                                                            W. Ingersoll
-                                                        Sun Microsystems
-                                                        January 23, 2005
-
-
-         The Simple and Protected GSS-API Negotiation Mechanism
-                      draft-ietf-kitten-2478bis-05
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 27, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document specifies a negotiation mechanism for the Generic
-   Security Service Application Program Interface (GSS-API) which is
-   described in RFC 2743.
-
-
-
-Zhu, et al.               Expires July 27, 2005                 [Page 1]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-   GSS-API peers can use this negotiation mechanism to choose from a
-   common set of security mechanisms.
-
-   If per-message integrity services are available on the established
-   mechanism context, then the negotiation is protected against an
-   attacker forcing the selection of a mechanism not desired by the
-   peers.
-
-   This mechanism replaces RFC 2478 in order to fix defects in that
-   specification and to describe how to inter-operate with
-   implementations of that specification commonly deployed on the
-   Internet.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
-   3.  Negotiation Protocol . . . . . . . . . . . . . . . . . . . . .  6
-     3.1   Negotiation Description  . . . . . . . . . . . . . . . . .  6
-     3.2   Negotiation Procedure  . . . . . . . . . . . . . . . . . .  7
-   4.  Token Definitions  . . . . . . . . . . . . . . . . . . . . . . 10
-     4.1   Mechanism Types  . . . . . . . . . . . . . . . . . . . . . 10
-     4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 10
-       4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 11
-       4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 12
-   5.  Processing of mechListMIC  . . . . . . . . . . . . . . . . . . 14
-   6.  Extensibility  . . . . . . . . . . . . . . . . . . . . . . . . 17
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
-   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
-   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 21
-     10.1  Normative References . . . . . . . . . . . . . . . . . . . 21
-     10.2  Informative References . . . . . . . . . . . . . . . . . . 21
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
-   A.  SPNEGO ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 23
-   B.  GSS-API Negotiation Support API  . . . . . . . . . . . . . . . 25
-     B.1   GSS_Set_neg_mechs call . . . . . . . . . . . . . . . . . . 25
-     B.2   GSS_Get_neg_mechs call . . . . . . . . . . . . . . . . . . 25
-   C.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 27
-   D.  mechListMIC Computation Example  . . . . . . . . . . . . . . . 29
-       Intellectual Property and Copyright Statements . . . . . . . . 30
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                 [Page 2]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-1.  Introduction
-
-   The GSS-API [RFC2743] provides a generic interface which can be
-   layered atop different security mechanisms such that if communicating
-   peers acquire GSS-API credentials for the same security mechanism,
-   then a security context may be established between them (subject to
-   policy).  However, GSS-API does not prescribe the method by which
-   GSS-API peers can establish whether they have a common security
-   mechanism.
-
-   The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
-   defined here is a pseudo security mechanism, which enables GSS-API
-   peers to determine in-band whether their credentials support a common
-   set of one or more GSS-API security mechanisms, and if so, to invoke
-   the normal security context establishment for a selected common
-   security mechanism.  This is most useful for applications which
-   depend on GSS-API implementations and share multiple mechanisms
-   between the peers.
-
-   The SPNEGO mechanism negotiation is based on the following model: the
-   initiator proposes a list of security mechanism(s), in decreasing
-   preference order (favorite choice first), the acceptor (also known as
-   the target) either accepts the initiator's preferred security
-   mechanism (the first in the list), or chooses one that is available
-   from the offered list, or rejects the proposed value(s).  The target
-   then informs the initiator of its choice.
-
-   Once a common security mechanism is chosen, mechanism-specific
-   options MAY be negotiated as part of the selected mechanism's context
-   establishment.  These negotiations (if any) are internal to the
-   mechanism and opaque to the SPNEGO protocol.  As such they are
-   outside the scope of this document.
-
-   If per-message integrity services are available on the established
-   mechanism security context, then the negotiation is protected to
-   ensure that the mechanism list has not been modified.  In cases where
-   an attacker could have materially influenced the negotiation, peers
-   exchange message integrity code (MIC) tokens to confirm the mechanism
-   list has not been modified.  If no action of an attacker could have
-   materially modified the outcome of the negotiation, the exchange of
-   MIC tokens is optional (see Section 5).  Allowing MIC tokens to be
-   optional in this case provides interoperability with existing
-   implementations while still protecting the negotiation.  This
-   interoperability comes at the cost of increased complexity.
-
-   SPNEGO relies on the concepts developed in the GSS-API specification
-   [RFC2743].  The negotiation data is encapsulated in context-level
-   tokens.  Therefore, callers of the GSS-API do not need to be aware of
-
-
-
-Zhu, et al.               Expires July 27, 2005                 [Page 3]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-   the existence of the negotiation tokens but only of the new
-   pseudo-security mechanism.  A failure in the negotiation phase causes
-   a major status code to be returned: GSS_S_BAD_MECH.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                 [Page 4]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                 [Page 5]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-3.  Negotiation Protocol
-
-   When the established mechanism context provides integrity protection,
-   the mechanism negotiation can be protected.  When acquiring
-   negotiated security mechanism tokens, per-message integrity services
-   are always requested by the SPNEGO mechanism.
-
-   When the established mechanism context supports per-message integrity
-   services, SPNEGO guarantees that the selected mechanism is mutually
-   preferred.
-
-   This section describes the negotiation process of this protocol.
-
-3.1  Negotiation Description
-
-   The first negotiation token sent by the initiator contains an ordered
-   list of mechanisms in decreasing preference order (favorite mechanism
-   first), and optionally the initial mechanism token for the preferred
-   mechanism of the initiator (i.e., the first in the list).  (Note that
-   the list MUST NOT contain either this SPNEGO mechanism itself or any
-   mechanism for which the client does not have appropriate
-   credentials.)
-
-   The target then processes the token from the initiator.  This will
-   result in one of four possible states (as defined in Section 4.2.2)
-   being returned in the reply message: accept-completed,
-   accept-incomplete, reject, or request-mic.  A reject state will
-   terminate the negotiation;  an accept-completed state indicates that
-   not only was the initiator-selected mechanism acceptable to the
-   target, but also that the security mechanism token embedded in the
-   first negotiation message was sufficient to complete the
-   authentication;  an accept-incomplete state indicates that further
-   message exchange is needed but the MIC token exchange as described in
-   Section 5 is OPTIONAL;  a request-mic state (this state can only be
-   present in the first reply message from the target) indicates the MIC
-   token exchange is REQUIRED if per-message integrity services are
-   available.
-
-   Unless the preference order is specified by the application, the
-   policy by which the target chooses a mechanism is an
-   implementation-specific local matter.  In the absence of an
-   application specified preference order or other policy, the target
-   SHALL choose the first mechanism in the initiator proposed list for
-   which it has valid credentials.
-
-   In case of a successful negotiation, the security mechanism in the
-   first reply message represents the value suitable for the target,
-   chosen from the list offered by the initiator.
-
-
-
-Zhu, et al.               Expires July 27, 2005                 [Page 6]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-   In case of an unsuccessful negotiation, the reject state is returned
-   and generating a context level negotiation token is OPTIONAL.
-
-   Once a mechanism has been selected, context establishment tokens
-   specific to the selected mechanism are carried within the negotiation
-   tokens.
-
-   Lastly, MIC tokens may be exchanged to ensure the authenticity of the
-   mechanism list received by the target.
-
-   To avoid conflicts with the use of MIC tokens by SPNEGO,
-   partially-established contexts MUST NOT be used for per-message
-   calls.  To guarantee this, the prot_ready_state [RFC2743] MUST be set
-   to false on return from GSS_Init_sec_context() and
-   GSS_Accept_sec_context() even if the underlying mechanism returned
-   true.
-
-   Note that in order to avoid an extra round trip, the first context
-   establishment token of the initiator's preferred mechanism SHOULD be
-   embedded in the initial negotiation message (as defined in
-   Section 4.2).  (This mechanism token is referred to as the optimistic
-   mechanism token in this document.) In addition, using the optimistic
-   mechanism token allows the initiator to recover from non-fatal errors
-   encountered trying to produce the first mechanism token before a
-   mechanism can be selected.  Implementations MAY omit the optimistic
-   mechanism token in cases where the likelihood of the initiator's
-   preferred mechanism not being selected by the acceptor is significant
-   given the cost of generating it.
-
-3.2  Negotiation Procedure
-
-   The basic form of the procedure assumes that per-message integrity
-   services are available on the established mechanism context, and it
-   is summarized as follows:
-
-   (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
-      but requests that SPNEGO be used.  SPNEGO can either be explicitly
-      requested or accepted as the default mechanism.
-
-   (b) The initiator GSS-API implementation generates a negotiation
-      token containing a list of one or more security mechanisms that
-      are available based on the credentials used for this context
-      establishment, and optionally the initial mechanism token for the
-      first mechanism in the list.
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                 [Page 7]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-   (c) The GSS-API initiator application sends the token to the target
-      application.  The GSS-API target application passes the token by
-      invoking GSS_Accept_sec_context().  The acceptor will do one of
-      the following:
-
-
-         (I) If none of the proposed mechanisms are acceptable, the
-            negotiation SHALL be terminated.  GSS_Accept_sec_context
-            indicates GSS_S_BAD_MECH.  The acceptor MAY output a
-            negotiation token containing a reject state.
-
-         (II) If either the initiator's preferred mechanism is not
-            accepted by the target or this mechanism is accepted but it
-            is not the acceptor's most preferred mechanism (i.e., the
-            MIC token exchange as described in Section 5 is required),
-            GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED.
-            The acceptor MUST output a negotiation token containing a
-            request-mic state.
-
-         (III) Otherwise if at least one additional negotiation token
-            from the initiator is needed to establish this context,
-            GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and
-            outputs a negotiation token containing an accept-incomplete
-            state.
-
-         (IV) Otherwise no additional negotiation token from the
-            initiator is needed to establish this context,
-            GSS_Accept_sec_context() indicates GSS_S_COMPLETE and
-            outputs a negotiation token containing an accept_complete
-            state.
-
-      If the initiator's preferred mechanism is accepted, and an
-      optimistic mechanism token was included, this mechanism token MUST
-      be passed to the selected mechanism by invoking
-      GSS_Accept_sec_context() and if a response mechanism token is
-      returned, it MUST be included in the response negotiation token.
-      Otherwise, the target will not generate a response mechanism token
-      in the first reply.
-
-   (d) The GSS-API target application returns the negotiation token to
-      the initiator application.  The GSS-API initiator application
-      passes the token by invoking GSS_Init_sec_context().  The security
-      context initialization is then continued according to the standard
-      GSS-API conventions for the selected mechanism, where the tokens
-      of the selected mechanism are encapsulated in negotiation messages
-      (see Section 4) until GSS_S_COMPLETE is returned for both the
-      initiator and the target by the selected security mechanism.
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                 [Page 8]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-   (e) MIC tokens are then either skipped or exchanged according to
-      Section 5.
-
-   Note that the *_req_flag input parameters for context establishment
-   are relative to the selected mechanism, as are the *_state output
-   parameters.  i.e., these parameters are not applicable to the
-   negotiation process per se.
-
-   On receipt of a negotiation token on the target side, a GSS-API
-   implementation that does not support negotiation would indicate the
-   GSS_S_BAD_MECH status as if a particular basic security mechanism had
-   been requested and was not supported.
-
-   When a GSS-API credential is acquired for the SPNEGO mechanism the
-   implementation SHOULD produce a credential element for the SPNEGO
-   mechanism which internally contains GSS-API credential elements for
-   all mechanisms for which the principal has credentials available,
-   except for any mechanisms which are not to be negotiated, either as
-   per implementation-, site- or application-specific policy.  See
-   Appendix B for interfaces for expressing application policy.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                 [Page 9]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-4.  Token Definitions
-
-   The type definitions in this section assume an ASN.1 module
-   definition of the following form:
-
-
-       SPNEGOASNOneSpec {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) mechanism(5) snego (2) modules(4) spec2(2)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       -- rest of definitions here
-
-       END
-
-
-   This specifies that the tagging context for the module will be
-   explicit and non-automatic.
-
-   The encoding of SPNEGO protocol messages shall obey the Distinguished
-   Encoding Rules (DER) of ASN.1 as described in [X690].
-
-4.1  Mechanism Types
-
-   In this negotiation model, each OID represents one GSS-API mechanism
-   or one variant (see Section 6) of it according to [RFC2743].
-
-
-       MechType ::= OBJECT IDENTIFIER
-           -- OID represents each security mechanism as suggested by
-           -- [RFC2743]
-
-       MechTypeList ::= SEQUENCE OF MechType
-
-
-4.2  Negotiation Tokens
-
-   The syntax of the initial negotiation tokens follows the
-   initialContextToken syntax defined in Section 3.1 of [RFC2743].  The
-   SPNEGO pseudo mechanism is identified by the Object Identifier
-   iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).
-   Subsequent tokens MUST NOT be encapsulated in this GSS-API generic
-   token framing.
-
-   This section specifies the syntax of the inner token for the initial
-   message and the syntax of subsequent context establishment tokens.
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 10]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-       NegotiationToken ::= CHOICE {
-           negTokenInit    [0] NegTokenInit,
-           negTokenResp    [1] NegTokenResp
-       }
-
-
-
-4.2.1  negTokenInit
-
-       NegTokenInit ::= SEQUENCE {
-           mechTypes       [0] MechTypeList,
-           reqFlags        [1] ContextFlags  OPTIONAL,
-             -- inherited from RFC 2478 for backward compatibility,
-             -- RECOMMENDED to be left out
-           mechToken       [2] OCTET STRING  OPTIONAL,
-           mechListMIC     [3] OCTET STRING  OPTIONAL,
-           ...
-       }
-       ContextFlags ::= BIT STRING {
-           delegFlag       (0),
-           mutualFlag      (1),
-           replayFlag      (2),
-           sequenceFlag    (3),
-           anonFlag        (4),
-           confFlag        (5),
-           integFlag       (6)
-       } (SIZE (32))
-
-   This is the syntax for the inner token of the initial negotiation
-   message.
-
-   mechTypes
-
-         This field contains one or more security mechanisms available
-         for the initiator in decreasing preference order (favorite
-         choice first).
-
-   reqFlags
-
-         This field, if present, contains the service options that are
-         requested to establish the context (the req_flags parameter of
-         GSS_Init_sec_context()).  This field is inherited from RFC 2478
-         and it is not integrity protected.  For implementations of this
-         specification the initiator SHOULD omit this reqFlags field,
-         and the acceptor MUST ignore this reqFlags field.
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 11]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-   mechToken
-
-         This field, if present, contains the optimistic mechanism
-         token.
-
-   mechlistMIC
-
-         This field, if present, contains a MIC token for the mechanism
-         list in the initial negotiation message.  This MIC token is
-         computed according to Section 5.
-
-
-4.2.2  negTokenResp
-
-       NegTokenResp ::= SEQUENCE {
-           negState       [0] ENUMERATED {
-               accept-completed    (0),
-               accept-incomplete   (1),
-               reject              (2),
-               request-mic         (3)
-           }                                 OPTIONAL,
-             -- REQUIRED in the first reply from the target
-           supportedMech   [1] MechType      OPTIONAL,
-             -- present only in the first reply from the target
-           responseToken   [2] OCTET STRING  OPTIONAL,
-           mechListMIC     [3] OCTET STRING  OPTIONAL,
-           ...
-       }
-
-   This is the syntax for all subsequent negotiation messages.
-
-   negState
-
-         This field, if present, contains the state of the negotiation.
-         This can be:
-
-         accept-completed
-
-            No further negotiation message from the peer is expected,
-            and the security context is established for the sender.
-
-         accept-incomplete
-
-            At least one more negotiation message from the peer is
-            needed to establish the security context.
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 12]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-         reject
-
-            The sender terminates the negotiation.
-
-         request-mic
-
-            The sender indicates that the exchange of MIC tokens, as
-            described in Section 5, will be REQUIRED if per-message
-            integrity services are available on the mechanism context to
-            be established.  This value SHALL only be present in the
-            first reply from the target.
-
-         This field is REQUIRED in the first reply from the target, and
-         it is OPTIONAL thereafter.  When negState is absent the actual
-         state should be inferred from the state of the negotiated
-         mechanism context.
-
-   supportedMech
-
-         This field SHALL only be present in the first reply from the
-         target.  It MUST be one of the mechanism(s) offered by the
-         initiator.
-
-   ResponseToken
-
-         This field, if present, contains tokens specific to the
-         mechanism selected.
-
-   mechlistMIC
-
-         This field, if present, contains a MIC token for the mechanism
-         list in the initial negotiation message.  This MIC token is
-         computed according to Section 5.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 13]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-5.  Processing of mechListMIC
-
-   If the mechanism selected by the negotiation does not support
-   integrity protection, then no mechlistMIC token is used.
-
-   Otherwise, if the accepted mechanism is the most preferred mechanism
-   of both the initiator and the acceptor, then the MIC token exchange,
-   as described later in this section, is OPTIONAL.  A mechanism is the
-   acceptor's most preferred mechanism if there is no other mechanism
-   which, had it been present in the mechanism list, the acceptor would
-   have preferred over the accepted mechanism.
-
-   In all other cases, MIC tokens MUST be exchanged after the mechanism
-   context is fully established.
-
-   a) The mechlistMIC token (or simply the MIC token) is computed over
-      the mechanism list in the initial negotiation message by invoking
-      GSS_GetMIC() as follows: the input context_handle is the
-      established mechanism context, the input qop_req is 0, and the
-      input message is the DER encoding of the value of type
-      MechTypeList which is contained in the "mechTypes" field of the
-      NegTokenInit.  The input message is NOT the DER encoding of the
-      type "[0] MechTypeList".
-
-   b) If the selected mechanism exchanges an even number of mechanism
-      tokens (i.e., the acceptor sends the last mechanism token), the
-      acceptor does the following when generating the negotiation
-      message containing the last mechanism token: if the MIC token
-      exchange is optional, GSS_Accept_sec_context() either indicates
-      GSS_S_COMPLETE and does not include a mechlistMIC token, or
-      indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token
-      and an accept-incomplete state; if the MIC token exchange is
-      required, GSS_Accept_sec_context() indicates
-      GSS_S_CONTINUE_NEEDED, and includes a mechlistMIC token.
-      Acceptors that wish to be compatible with legacy Windows SPNEGO
-      implementations as described in Appendix C should not generate a
-      mechlistMIC token when the MIC token exchange is not required.
-      The initiator then processes the last mechanism token, and does
-      one of the following:
-
-      (I) If a mechlistMIC token was included, and is correctly
-         verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE.  The
-         output negotiation message contains a mechlistMIC token, and an
-         accept_complete state.  The acceptor MUST then verify this
-         mechlistMIC token.
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 14]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-      (II) If a mechlistMIC token was included but is incorrect, the
-         negotiation SHALL be terminated.  GSS_Init_sec_context()
-         indicates GSS_S_DEFECTIVE_TOKEN.
-
-      (III) If no mechlistMIC token was included, and the MIC token
-         exchange is not required, GSS_Init_sec_context() indicates
-         GSS_S_COMPLETE with no output token.
-
-      (IV) If no mechlistMIC token was included, but the MIC token
-         exchange is required, the negotiation SHALL be terminated.
-         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
-
-   c) In the case that the chosen mechanism exchanges an odd number of
-      mechanism tokens (i.e., the initiator sends the last mechanism
-      token), the initiator does the following when generating the
-      negotiation message containing the last mechanism token: if the
-      negState was request-mic in the first reply from the target, a
-      mechlistMIC token MUST be included, otherwise the mechlistMIC
-      token is OPTIONAL.  (Note that the MIC token exchange is required
-      if a mechanism other than the initiator's first choice is chosen.)
-      In the case that the optimistic mechanism token is the only
-      mechanism token for the initiator's preferred mechanism, the
-      mechlistMIC token is OPTIONAL.  Whether or not the mechlistMIC
-      token is included, GSS_Init_sec_context() indicates
-      GSS_S_CONTINUE_NEEDED.  Initiators that wish to be compatible with
-      legacy Windows SPNEGO implementations as described in Appendix C
-      should not generate a mechlistMIC token when the MIC token
-      exchange is not required.  The acceptor then processes the last
-      mechanism token and does one of the following:
-
-      (I) If a mechlistMIC token was included and is correctly verified,
-         GSS_Accept_sec_context() indicates GSS_S_COMPLETE.  The output
-         negotiation message contains a mechlistMIC token and an
-         accept_complete state.  The initiator MUST then verify this
-         mechlistMIC token.
-
-      (II) If a mechlistMIC token was included but is incorrect, the
-         negotiation SHALL be terminated.  GSS_Accept_sec_context()
-         indicates GSS_S_DEFECTIVE_TOKEN.
-
-      (III) If no mechlistMIC token was included and the mechlistMIC
-         token exchange is not required, GSS_Accept_sec_context()
-         indicates GSS_S_COMPLETE.  The output negotiation message
-         contains an accept_complete state.
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 15]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-      (IV) In the case that the optimistic mechanism token is also the
-         last mechanism token (when the initiator's preferred mechanism
-         is accepted by the target) and the target sends a request-mic
-         state but the initiator did not send a mechlistMIC token, the
-         target then MUST include a mechlistMIC token in that first
-         reply.  GSS_Accept_sec_context() indicates
-         GSS_S_CONTINUE_NEEDED.  The initiator MUST verify the received
-         mechlistMIC token and generate a mechlistMIC token to send back
-         to the target.  The target SHALL in turn verify the returned
-         mechlistMIC token and complete the negotiation.
-
-      (V) If no mechlistMIC token was included and the acceptor sent a
-         request-mic state in the first reply message (the exchange of
-         MIC tokens is required), the negotiation SHALL be terminated.
-         GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 16]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-6.  Extensibility
-
-   Two mechanisms are provided for extensibility.  First, the ASN.1
-   structures in this specification MAY be expanded by IETF standards
-   action.  Implementations receiving unknown fields MUST ignore these
-   fields.
-
-   Secondly, OIDs corresponding to a desired mechanism attribute (i.e.,
-   mechanism variants) may be included in the set of preferred
-   mechanisms by an initiator.  The acceptor can choose to honor this
-   request by preferring mechanisms that have the included attributes.
-   Future work within the Kitten working group is expected to
-   standardize common attributes that SPNEGO mechanisms may wish to
-   support.  At this time it is sufficient to say that initiators MAY
-   include OIDs that do not correspond to mechanisms.  Such OIDs MAY
-   influence the acceptor's choice of mechanism.  As discussed in
-   Section 5, if there are mechanisms that if present in the initiator's
-   list of mechanisms might be preferred by the acceptor to the
-   initiator's preferred mechanism, the acceptor MUST demand the MIC
-   token exchange.  As the consequence, acceptors MUST demand the MIC
-   token exchange if they support negotiation of attributes not
-   available in the initiator's preferred mechanism regardless of
-   whether the initiator actually requested these attributes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 17]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-7.  Security Considerations
-
-   In order to produce the MIC token for the mechanism list, the
-   mechanism must provide integrity protection.  When the selected
-   mechanism does not support integrity protection, the negotiation is
-   vulnerable: an active attacker can force it to use a security
-   mechanism that is not mutually preferred but is acceptable to the
-   target.
-
-   This protocol provides the following guarantees when per-message
-   integrity services are available on the established mechanism context
-   and the mechanism list was altered by an adversary such that a
-   mechanism which is not mutually preferred could be selected:
-
-   a) If the last mechanism token is sent by the initiator, both peers
-      shall fail;
-   b) If the last mechanism token is sent by the acceptor, the acceptor
-      shall not complete and the initiator at worst shall complete with
-      its preferred mechanism being selected.
-
-   The negotiation may not be terminated if an alteration was made but
-   it had no material impact.
-
-   The protection of the negotiation depends on the strength of the
-   integrity protection.  In particular, the strength of SPNEGO is no
-   stronger than the integrity protection of the weakest mechanism
-   acceptable to GSS-API peers.
-
-   Note that where there exist multiple mechanisms with similar context
-   tokens, but different semantics, such that some or all of the
-   mechanisms' context tokens can be easily altered so that one
-   mechanism's context tokens may pass for another of the similar
-   mechanism's context tokens, then there may exist downgrade or similar
-   attacks.  For example, if a given family of mechanisms uses the same
-   context token syntax for two or more variants and depends on the OID
-   in the initial token's pseudo-ASN.1/DER wrapper, but does not provide
-   integrity protection for that OID, then there may exist an attack
-   against those mechanisms.  SPNEGO does not generally defeat such
-   attacks.
-
-   In all cases, the communicating peers are exposed to the denial of
-   service threat.
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 18]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-8.  IANA Considerations
-
-   This document has no actions for IANA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 19]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-9.  Acknowledgments
-
-   The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,
-   Martin Rex, Jeff Altman, Tom Yu, Cristian Ilac, Simon Spero and Bill
-   Sommerfeld for their comments and suggestions during development of
-   this document.
-
-   Luke Howard provided a prototype of this protocol in Heimdal and
-   resolved several issues in the initial draft.
-
-   Eric Baize and Denis Pinkas wrote the original SPNEGO specification
-   [RFC2478] of which some of the text has been retained in this
-   document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 20]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-10.  References
-
-10.1  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding 
-              Rules (BER), Canonical Encoding Rules (CER) and 
-              Distinguished Encoding Rules (DER), ITU-T Recommendation 
-              X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
-
-10.2  Informative References
-
-   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
-              Negotiation Mechanism", RFC 2478, December 1998.
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Paul Leach
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: paulle@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 21]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-   Wyllys Ingersoll
-   Sun Microsystems
-   1775 Wiehle Avenue, 2nd Floor
-   Reston, VA  20190
-   US
-
-   Email: wyllys.ingersoll@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 22]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-Appendix A.  SPNEGO ASN.1 Module
-
-       SPNEGOASNOneSpec {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) mechanism(5) snego (2) modules(4) spec2(2)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       MechType ::= OBJECT IDENTIFIER
-           -- OID represents each security mechanism as suggested by
-           -- [RFC2743]
-
-       MechTypeList ::= SEQUENCE OF MechType
-
-       NegotiationToken ::= CHOICE {
-           negTokenInit    [0] NegTokenInit,
-           negTokenResp    [1] NegTokenResp
-       }
-
-       NegTokenInit ::= SEQUENCE {
-           mechTypes       [0] MechTypeList,
-           reqFlags        [1] ContextFlags  OPTIONAL,
-             -- inherited from RFC 2478 for backward compatibility,
-             -- RECOMMENDED to be left out
-           mechToken       [2] OCTET STRING  OPTIONAL,
-           mechListMIC     [3] OCTET STRING  OPTIONAL,
-           ...
-       }
-       NegTokenResp ::= SEQUENCE {
-           negState       [0] ENUMERATED {
-               accept-completed    (0),
-               accept-incomplete   (1),
-               reject              (2),
-               request-mic         (3)
-           }                                 OPTIONAL,
-             -- REQUIRED in the first reply from the target
-           supportedMech   [1] MechType      OPTIONAL,
-             -- present only in the first reply from the target
-           responseToken   [2] OCTET STRING  OPTIONAL,
-           mechListMIC     [3] OCTET STRING  OPTIONAL,
-           ...
-       }
-
-       ContextFlags ::= BIT STRING {
-           delegFlag       (0),
-           mutualFlag      (1),
-           replayFlag      (2),
-           sequenceFlag    (3),
-           anonFlag        (4),
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 23]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-           confFlag        (5),
-           integFlag       (6)
-       } (SIZE (32))
-
-       END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 24]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-Appendix B.  GSS-API Negotiation Support API
-
-   In order to provide to a GSS-API caller (either the initiator or the
-   target or both) the ability to choose among the set of supported
-   mechanisms a reduced set of mechanisms for negotiation, two
-   additional APIs are defined:
-
-   o  GSS_Get_neg_mechs() indicates the set of security mechanisms
-      available on the local system to the caller for negotiation, for
-      which appropriate credentials are available.
-   o  GSS_Set_neg_mechs() specifies the set of security mechanisms to be
-      used on the local system by the caller for negotiation, for the
-      given credentials.
-
-B.1  GSS_Set_neg_mechs call
-
-   Inputs:
-
-   o  cred_handle CREDENTIAL HANDLE, -- NULL specifies default
-      -- credentials
-   o  mech_set SET OF OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the set of security mechanisms
-      available for negotiation has been set to mech_set.
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to specify the set of security mechanisms that may be
-   negotiated with the credential identified by cred_handle.  This call
-   is intended for support of specialized callers who need to restrict
-   the set of negotiable security mechanisms from the set of all
-   security mechanisms available to the caller (based on available
-   credentials).  Note that if more than one mechanism is specified in
-   mech_set, the order in which those mechanisms are specified implies a
-   relative preference.
-
-B.2  GSS_Get_neg_mechs call
-
-   Input:
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 25]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-   o  cred_handle CREDENTIAL HANDLE -- NULL specifies default
-      -- credentials
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  mech_set SET OF OBJECT IDENTIFIER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the set of security mechanisms
-      available for negotiation has been returned in mech_set.
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to determine the set of security mechanisms available
-   for negotiation with the credential identified by cred_handle.  This
-   call is intended for support of specialized callers who need to
-   reduce the set of negotiable security mechanisms from the set of
-   supported security mechanisms available to the caller (based on
-   available credentials).
-
-   Note: The GSS_Indicate_mechs() function indicates the full set of
-   mechanism types available on the local system.  Since this call has
-   no input parameter, the returned set is not necessarily available for
-   all credentials.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 26]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-Appendix C.  Changes since RFC2478
-
-      SPNEGO implementations in Microsoft Windows 2000/Windows
-      XP/Windows Server 2003 have the following behavior: no mechlistMIC
-      is produced and mechlistMIC is not processed if one is provided;
-      if the initiator sends the last mechanism token, the acceptor will
-      send back a negotiation token with an accept_complete state and no
-      mechlistMIC token.  In addition, an incorrect OID
-      (1.2.840.48018.1.2.2) can be used to identify the GSS-API Kerberos
-      Version 5 mechanism.
-
-      The following changes have been made to be compatible with these
-      legacy implementations.
-
-      *  NegTokenTarg is changed to negTokenResp and it is the message
-         format for all subsequent negotiation tokens.
-      *  NegTokenInit is the message for the initial negotiation message
-         and that message only.
-      *  mechTypes in negTokenInit is not optional.
-      *  If the selected mechanism is also the most preferred mechanism
-         for both peers, it is safe to omit the MIC tokens.
-
-      If at least one of the two peers implements the updated pseudo
-      mechanism in this document, the negotiation is protected.
-
-      The following changes are to address problems in RFC 2478.
-
-      *  reqFlags is not protected therefore it should not impact the
-         negotiation.
-      *  DER encoding is required.
-      *  GSS_GetMIC() input is clarified.
-      *  Per-message integrity services are requested for the negotiated
-         mechanism.
-      *  Two MIC tokens are exchanged, one in each direction.
-
-   An implementation that conforms to this specification will not
-   inter-operate with a strict 2748 implementation.  Even if the new
-   implementation always sends a mechlistMIC token, it will still fail
-   to inter-operate.  If it is a server, it will fail because it
-   requests a mechlistMIC token using an option that older
-   implementations simply do not support.  Clients will tend to fail as
-   well.
-
-   As an alternative to the approach chosen in this specification, we
-   could have documented a correct behavior that is fully backward
-   compatible with RFC 2478 and included an appendix on how to
-   inter-operate with existing incorrect implementations of RFC 2478.
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 27]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-   As a practical matter, the SPNEGO implementers within the IETF have
-   valued interoperability with the Microsoft implementations.  We were
-   unable to choose to maintain reasonable security guarantees, maintain
-   interoperability with the Microsoft implementations and maintain
-   interoperability with correct implementations of RFC 2478.  The
-   working group was not aware of any RFC 2478 implementations deployed
-   on the Internet.  Even if there are such implementations, it is
-   unlikely that they will inter-operate because of a critical flaw in
-   the description of the encoding of the mechanism list in RFC 2478.
-
-   With the approach taken in this specification, security is ensured
-   between new implementations all the time while maintaining
-   interoperability with the implementations deployed within the IETF
-   community.  The working group believes that this justifies breaking
-   compatibility with a correct implementation of RFC 2478.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 28]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-Appendix D.  mechListMIC Computation Example
-
-   The following is an example to illustrate how the mechListMIC field
-   would be computed.
-
-   The initial part of the DER encoding of NegTokenInit is constructed
-   as follows (the "nn" are length encodings, possibly longer than one
-   octet):
-
-      30 -- identifier octet for constructed SEQUENCE (NegTokenInit)
-      nn -- length
-
-         -- contents octets of the SEQUENCE begin with
-         -- DER encoding of "[0] MechTypeList":
-         A0 -- identifier octet for constructed [0]
-         nn -- length
-
-             -- contents of the constructed [0] are DER encoding
-             -- of MechTypeList (which is a SEQUENCE):
-             30 -- identifier octet for constructed SEQUENCE
-             nn -- length
-
-                -- contents octets of the SEQUENCE begin with
-                -- DER encoding of OBJECT IDENTIFIER:
-                06 -- identifier octet for primitive OBJECT IDENTIFIER
-                09 -- length
-                2A 86 48 86 F7 12 01 02 02 -- Kerberos V5
-                                           -- {1 2 840 113554 1 2 2}
-
-   If a mechlistMIC needs to be generated (according to the rules in
-   Section 5), it is computed by using the DER encoding of the type
-   MechTypeList data from the initiator's NegTokenInit token as input to
-   the GSS_GetMIC() function.  In this case, the MIC would be computed
-   over the following octets:
-
-      DER encoding of MechTypeList:
-      30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...
-
-   Note that the identifier octet and length octet(s) for constructed
-   [0] (A0 nn) are not included in the MIC computation.
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 29]
-
-Internet-Draft        GSS-API Negotiation Mechanism         January 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.               Expires July 27, 2005                [Page 30]
-
diff --git a/doc/standardisation/draft-ietf-kitten-extended-mech-inquiry-01.txt b/doc/standardisation/draft-ietf-kitten-extended-mech-inquiry-01.txt
deleted file mode 100644
index 9aee4d125..000000000
--- a/doc/standardisation/draft-ietf-kitten-extended-mech-inquiry-01.txt
+++ /dev/null
@@ -1,785 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: April 19, 2006                                 October 16, 2005
-
-
-        Extended Generic Security Service Mechanism Inquiry APIs
-             draft-ietf-kitten-extended-mech-inquiry-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document introduces new application programming interfaces
-   (APIs) to the Generic Security Services API (GSS-API) for extended
-   mechanism attribute inquiry.  These interfaces are primarily intended
-   for use in mechanism composition, but also to reduce instances of
-   hardcoding of mechanism identifiers in GSS applications.
-
-   These interfaces include: mechanism attributes and attribute sets, a
-   function for inquiring the attributes of a mechanism, a function for
-   indicating mechanisms that posses given attributes, and a function
-
-
-
-Williams                 Expires April 19, 2006                 [Page 1]
-
-Internet-Draft          Extended GSS Mech Inquiry           October 2005
-
-
-   for displaying mechanism attributes.
-
-
-Table of Contents
-
-   1.      Conventions used in this document  . . . . . . . . . . . .  3
-   2.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.      New GSS-API Interfaces . . . . . . . . . . . . . . . . . .  3
-   3.1.    Mechanism Attributes and Attribute Sets  . . . . . . . . .  3
-   3.2.    Determination of Attribute Sets of Composite Mechs . . . .  4
-   3.3.    List of Known Mechanism Attributes . . . . . . . . . . . .  4
-   3.4.    Mechanism Attribute Sets of Existing Mechs . . . . . . . .  6
-   3.5.    New GSS-API Function Interfaces  . . . . . . . . . . . . .  8
-   3.5.1.  GSS_Indicate_mechs_by_attr() . . . . . . . . . . . . . . .  8
-   3.5.2.  GSS_Inquire_attrs_for_mech() . . . . . . . . . . . . . . .  9
-   3.5.3.  GSS_Display_mech_attr()  . . . . . . . . . . . . . . . . . 10
-   3.5.4.  New Major Status Values  . . . . . . . . . . . . . . . . . 10
-   3.5.5.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 10
-   4.      Requirements for Mechanism Designers . . . . . . . . . . . 11
-   5.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 11
-   6.      Security considerations  . . . . . . . . . . . . . . . . . 11
-   7.      References . . . . . . . . . . . . . . . . . . . . . . . . 12
-   7.1.    Normative  . . . . . . . . . . . . . . . . . . . . . . . . 12
-   7.2.    Normative  . . . . . . . . . . . . . . . . . . . . . . . . 12
-           Author's Address . . . . . . . . . . . . . . . . . . . . . 13
-           Intellectual Property and Copyright Statements . . . . . . 14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 2]
-
-Internet-Draft          Extended GSS Mech Inquiry           October 2005
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-2.  Introduction
-
-
-3.  New GSS-API Interfaces
-
-   GSS-API applications face, today, the problem of how to select from
-   multiple GSS-API mechanisms that may be available.  For example,
-   applications that support mechanism negotiation directly often have
-   to be careful not to use SPNEGO to avoid two-layer mechanism
-   negotiation, but since SPNEGO may be indicated by
-   GSS_Indicate_mechs() and since there's no way to know that a
-   mechanism negotiates mechanisms other than to hardcode the OIDs of
-   such mechanisms, such applications must hardcode the SPNEGO OID.
-   This problem is likely to be exacerbated by the introduction of
-   composite mechanisms.
-
-   To address this problem we introduce a new concept: that of mechanism
-   attributes.  By allowing applications to query the set of attributes
-   associated with individual mechanisms and to find out which
-   mechanisms support a given set of attributes we allow applications to
-   select mechanisms based on their attributes yet without having to
-   hardcode mechanism OIDs.
-
-   Section 3.1 describes the mechanism attributes concept.  Sections
-   3.5.1, 3.5.2 and 3.5.3 describe three new interfaces that deal in
-   mechanisms and attribute sets:
-
-   o  GSS_Indicate_mechs_by_attrs()
-   o  GSS_Inquire_attrs_for_mech()
-   o  GSS_Display_mech_attr()
-
-3.1.  Mechanism Attributes and Attribute Sets
-
-   An abstraction for the features provided by pseudo-mechanisms is
-   needed in order to facilitate the programmatic selection of
-   mechanisms as well as for the programmatic composition of mechanisms.
-
-   Two data types are needed: one for individual mechanism attributes
-   and one for mechanism attribute sets.  To simplify the mechanism
-   attributes interfaces we reuse the 'OID' and 'OID set' data types and
-   model individual mechanism attribute types as OIDs.
-
-
-
-Williams                 Expires April 19, 2006                 [Page 3]
-
-Internet-Draft          Extended GSS Mech Inquiry           October 2005
-
-
-   To this end we define an open namespace of mechanism attributes and
-   assign them arcs off of this OID:
-
-   <TBD> [1.3.6.1.5.5.12 appears to be available, registration w/ IANA
-   TBD]
-
-3.2.  Determination of Attribute Sets of Composite Mechs
-
-   Each mechanism, composite or otherwise, has a set of mechanism
-   attributes that it supports as specified.
-
-   The mechanism attribute set of a composite mechanism is to be
-   determined by the top-most stackable pseudo-mechanism of the
-   composite according to its own attribute set and that of the
-   remainder of the composite mechanism stack below it.
-
-   It may well be that some composite mechanisms' attribute sets consist
-   of the union of those of their every component, however this need not
-   be the case and MUST NOT be assumed.
-
-   Every stackable pseudo-mechanism's specification MUST specify the
-   rules for determining the mechanism attribute set of mechanisms
-   composed by it.
-
-3.3.  List of Known Mechanism Attributes
-
-   +-------------------------+--------+--------------------------------+
-   | Mech Attr Name          |    OID | Arc Name                       |
-   |                         |    Arc |                                |
-   +-------------------------+--------+--------------------------------+
-   | GSS_C_MA_MECH_CONCRETE  |    (1) | concrete-mech                  |
-   | GSS_C_MA_MECH_STACKABLE |    (2) | pseudo-mech                    |
-   | GSS_C_MA_MECH_COMPOSITE |    (3) | composite-mech                 |
-   | GSS_C_MA_MECH_NEGO      |    (4) | mech-negotiation-mech          |
-   | GSS_C_MA_MECH_GLUE      |    (5) | mech-glue                      |
-   | GSS_C_MA_NOT_MECH       |    (6) | not-mech                       |
-   | GSS_C_MA_DEPRECATED     |    (7) | mech-deprecated                |
-   | GSS_C_MA_NOT_DFLT_MECH  |    (8) | mech-not-default               |
-   | GSS_C_MA_ITOK_FRAMED    |    (9) | initial-is-framed              |
-   | GSS_C_MA_AUTH_INIT      |   (10) | auth-init-princ                |
-   | GSS_C_MA_AUTH_TARG      |   (11) | auth-targ-princ                |
-   | GSS_C_MA_AUTH_INIT_INIT |   (12) | auth-init-princ-initial        |
-   | GSS_C_MA_AUTH_TARG_INIT |   (13) | auth-targ-princ-initial        |
-   | GSS_C_MA_AUTH_INIT_ANON |   (14) | auth-init-princ-anon           |
-   | GSS_C_MA_AUTH_TARG_ANON |   (15) | auth-targ-princ-anon           |
-   | GSS_C_MA_DELEG_CRED     |   (16) | deleg-cred                     |
-   | GSS_C_MA_INTEG_PROT     |   (17) | integ-prot                     |
-   | GSS_C_MA_CONF_PROT      |   (18) | conf-prot                      |
-
-
-
-Williams                 Expires April 19, 2006                 [Page 4]
-
-Internet-Draft          Extended GSS Mech Inquiry           October 2005
-
-
-   | GSS_C_MA_MIC            |   (19) | mic                            |
-   | GSS_C_MA_WRAP           |   (20) | wap                            |
-   | GSS_C_MA_PROT_READY     |   (21) | prot-ready                     |
-   | GSS_C_MA_REPLAY_DET     |   (22) | replay-detection               |
-   | GSS_C_MA_OOS_DET        |   (23) | oos-detection                  |
-   | GSS_C_MA_CBINDINGS      |   (24) | channel-bindings               |
-   | GSS_C_MA_CBINDINGS_BIDI |   (25) | channel-bindings-bidirectional |
-   | GSS_C_MA_CBINDINGS_NEGO |   (26) | channel-bindings-negotiate     |
-   | GSS_C_MA_PFS            |   (27) | pfs                            |
-   | GSS_C_MA_COMPRESS       |   (28) | compress                       |
-   | GSS_C_MA_CTX_TRANS      |   (29) | context-transfer               |
-   | <reserved>              | (30..) |                                |
-   +-------------------------+--------+--------------------------------+
-
-                                  Table 1
-
-   +-------------------------+-----------------------------------------+
-   | Mech Attr Name          | Purpose                                 |
-   +-------------------------+-----------------------------------------+
-   | GSS_C_MA_MECH_CONCRETE  | Indicates that a mech is neither a      |
-   |                         | pseudo- mechanism nor a composite       |
-   |                         | mechanism.                              |
-   | GSS_C_MA_MECH_STACKABLE | Indicates that a mech is a              |
-   |                         | pseudo-mechanism.                       |
-   | GSS_C_MA_MECH_COMPOSITE | Indicates that a mech is a composite    |
-   |                         | mechanism.                              |
-   | GSS_C_MA_MECH_NEGO      | Indicates that a mech negotiates other  |
-   |                         | mechs (e.g., SPNEGO has this            |
-   |                         | attribute).                             |
-   | GSS_C_MA_MECH_GLUE      | Indicates that the OID is not for a     |
-   |                         | mechanism but for the GSS-API itself.   |
-   | GSS_C_MA_NOT_MECH       | Indicates that the OID is known, yet    |
-   |                         | also known not to be the OID of any     |
-   |                         | GSS-API mechanism (or the GSS-API       |
-   |                         | itself).                                |
-   | GSS_C_MA_DEPRECATED     | Indicates that a mech (or its OID) is   |
-   |                         | deprecated and MUST NOT be used as a    |
-   |                         | default mechanism.                      |
-   | GSS_C_MA_NOT_DFLT_MECH  | Indicates that a mech (or its OID) MUST |
-   |                         | NOT be used as a default mechanism.     |
-   | GSS_C_MA_ITOK_FRAMED    | Indicates that the given mechanism's    |
-   |                         | initial context tokens are properly     |
-   |                         | framed as per-section 3.1 of rfc2743.   |
-   | GSS_C_MA_AUTH_INIT      | Indicates support for authentication of |
-   |                         | initiator to acceptor.                  |
-   | GSS_C_MA_AUTH_TARG      | Indicates support for authentication of |
-   |                         | acceptor to initiator.                  |
-   | GSS_C_MA_AUTH_INIT_INIT | Indicates support for initial           |
-
-
-
-Williams                 Expires April 19, 2006                 [Page 5]
-
-Internet-Draft          Extended GSS Mech Inquiry           October 2005
-
-
-   |                         | authentication of initiator to          |
-   |                         | acceptor.                               |
-   | GSS_C_MA_AUTH_TARG_INIT | Indicates support for initial           |
-   |                         | authentication of acceptor to           |
-   |                         | initiator.                              |
-   | GSS_C_MA_AUTH_INIT_ANON | Indicates support for initiator         |
-   |                         | anonymity.                              |
-   | GSS_C_MA_AUTH_TARG_ANON | Indicates support for acceptor          |
-   |                         | anonymity.                              |
-   | GSS_C_MA_DELEG_CRED     | Indicates support for credential        |
-   |                         | delegation.                             |
-   | GSS_C_MA_INTEG_PROT     | Indicates support for per-message       |
-   |                         | integrity protection.                   |
-   | GSS_C_MA_CONF_PROT      | Indicates support for per-message       |
-   |                         | confidentiality protection.             |
-   | GSS_C_MA_MIC            | Indicates support for MIC tokens.       |
-   | GSS_C_MA_WRAP           | Indicates support for WRAP tokens.      |
-   | GSS_C_MA_PROT_READY     | Indicates support for per-message       |
-   |                         | protection prior to full context        |
-   |                         | establishment.                          |
-   | GSS_C_MA_REPLAY_DET     | Indicates support for replay detection. |
-   | GSS_C_MA_OOS_DET        | Indicates support for out-of-sequence   |
-   |                         | detection.                              |
-   | GSS_C_MA_CBINDINGS      | Indicates support for channel bindings. |
-   | GSS_C_MA_CBINDINGS_BIDI | Indicates that acceptors                |
-   |                         | unconditionally indicate to initiators  |
-   |                         | whether their channel bindings were     |
-   |                         | matched the acceptors', even when the   |
-   |                         | acceptor applications use               |
-   |                         | GSS_C_NO_CHANNEL_BINDINGS..             |
-   | GSS_C_MA_CBINDINGS_NEGO | Indicates that the mech acts as a       |
-   |                         | signal for application support for and  |
-   |                         | willingness to use channel bindings.    |
-   | GSS_C_MA_PFS            | Indicates support for Perfect Forward   |
-   |                         | Security.                               |
-   | GSS_C_MA_COMPRESS       | Indicates support for compression of    |
-   |                         | data inputs to GSS_Wrap().              |
-   | GSS_C_MA_CTX_TRANS      | Indicates support for security context  |
-   |                         | export/import.                          |
-   +-------------------------+-----------------------------------------+
-
-                                  Table 2
-
-3.4.  Mechanism Attribute Sets of Existing Mechs
-
-   The Kerberos V mechanism [RFC1964] [CFX] provides the following
-   mechanism attributes:
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 6]
-
-Internet-Draft          Extended GSS Mech Inquiry           October 2005
-
-
-   o  GSS_C_MA_MECH_CONCRETE
-   o  GSS_C_MA_ITOK_FRAMED
-   o  GSS_C_MA_AUTH_INIT
-   o  GSS_C_MA_AUTH_TARG
-   o  GSS_C_MA_DELEG_CRED
-   o  GSS_C_MA_INTEG_PROT
-   o  GSS_C_MA_CONF_PROT
-   o  GSS_C_MA_MIC
-   o  GSS_C_MA_WRAP
-   o  GSS_C_MA_PROT_READY
-   o  GSS_C_MA_REPLAY_DET
-   o  GSS_C_MA_OOS_DET
-   o  GSS_C_MA_CBINDINGS
-   o  GSS_C_MA_CTX_TRANS (some implementations, using implementation-
-      specific exported context token formats)
-
-   The Kerberos V mechanism also has a deprecated OID which has the same
-   mechanism attributes as above, and GSS_C_MA_DEPRECATED.
-
-   [The mechanism attributes of the SPKM family of mechanisms will be
-   provided in a separate document as SPKM is current being reviewed for
-   possibly significant changes due to problems in its specifications.]
-
-   The LIPKEY mechanism offers the following attributes:
-
-   o  GSS_C_MA_MECH_CONCRETE (should be stackable, but does not compose)
-   o  GSS_C_MA_ITOK_FRAMED
-   o  GSS_C_MA_AUTH_INIT_INIT
-   o  GSS_C_MA_AUTH_TARG (from SPKM-3)
-   o  GSS_C_MA_AUTH_TARG_ANON (from SPKM-3)
-   o  GSS_C_MA_INTEG_PROT
-   o  GSS_C_MA_CONF_PROT
-   o  GSS_C_MA_REPLAY_DET
-   o  GSS_C_MA_OOS_DET
-   o  GSS_C_MA_CTX_TRANS (some implementations, using implementation-
-      specific exported context token formats)
-
-      (LIPKEY should also provide GSS_C_MA_CBINDINGS, but SPKM-3
-      requires clarifications on this point.)
-
-   The SPNEGO mechanism [SPNEGO] provides the following attributes:
-   o  GSS_C_MA_MECH_NEGO
-   o  GSS_C_MA_ITOK_FRAMED
-
-   The attributes of mechanisms negotiated by SPNEGO are not modified by
-   the use of SPNEGO.
-
-   All other mechanisms' attributes will be described elsewhere.
-
-
-
-Williams                 Expires April 19, 2006                 [Page 7]
-
-Internet-Draft          Extended GSS Mech Inquiry           October 2005
-
-
-3.5.  New GSS-API Function Interfaces
-
-   Several new interfaces are given by which, for example, GSS-API
-   applications may determine what features are provided by a given
-   mechanism, what mechanisms provide what features and what
-   compositions are legal.
-
-   These new interfaces are all OPTIONAL.
-
-   In order to preserve backwards compatibility with applications that
-   do not use the new interfaces GSS_Indicate_mechs() MUST NOT indicate
-   support for any stackable pseduo-mechanisms.  GSS_Indicate_mechs()
-   MAY indicate support for some, all or none of the available composite
-   mechanisms; which composite mechanisms, if any, are indicated through
-   GSS_Indicate_mechs() SHOULD be configurable.  GSS_Acquire_cred() and
-   GSS_Add_cred() MUST NOT create credentials for composite mechanisms
-   not explicitly requested or, if no desired mechanism or mechanisms
-   are given, for composite mechanisms not indicated by
-   GSS_Indicate_mechs().
-
-   Applications SHOULD use GSS_Indicate_mechs_by_attr() instead of
-   GSS_Indicate_mechs() wherever possible.
-
-   Applications can use GSS_Indicate_mechs_by_attr() to determine what,
-   if any, mechanisms provide a given set of features.
-
-   GSS_Indicate_mechs_by_attr() can also be used to indicate (as in
-   GSS_Indicate_mechs()) the set of available mechanisms of each type
-   (concrete, mechanism negotiation pseudo-mechanism, stackable pseudo-
-   mechanism and composite mechanisms).
-
-   Applications may use GSS_Inquire_attrs_for_mech() to test whether a
-   given composite mechanism is available and the set of features that
-   it offers.
-
-3.5.1.  GSS_Indicate_mechs_by_attr()
-
-   Inputs:
-   o  desired_mech_attrs SET OF OBJECT IDENTIFIER -- set of GSS_C_MA_*
-      OIDs that the mechanisms indicated in the mechs output parameter
-      MUST offer.
-   o  except_mech_attrs SET OF OBJECT IDENTIFIER -- set of GSS_C_MA_*
-      OIDs that the mechanisms indicated in the mechs output parameter
-      MUST NOT offer.
-
-   Outputs:
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-
-
-
-Williams                 Expires April 19, 2006                 [Page 8]
-
-Internet-Draft          Extended GSS Mech Inquiry           October 2005
-
-
-   o  mechs SET OF OBJECT IDENTIFIER -- set of mechanisms that support
-      -- the desired_mech_attrs but not the except_mech_attrs.
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates success; the output mechs parameter MAY
-      be the empty set (GSS_C_NO_OID_SET).
-   o  GSS_BAD_MECH_ATTR indicates that at least one mechanism attribute
-      OID in desired_mech_attrs or except_mech_attrs is unknown to the
-      implementation.
-   o  GSS_S_FAILURE indicates that the request failed for some other
-      reason.
-
-   GSS_Indicate_mechs_by_mech_attrs() returns the set of mechanism OIDs
-   that offer at least the desired_mech_attrs but none of the
-   except_mech_attrs.
-
-   When desired_mech_attrs and except_mech_attrs are the empty set this
-   function acts as a version of GSS_indicate_mechs() that outputs the
-   set of all supported mechanisms of all types.  By setting the
-   desired_mechs input parameter to a set of a single GSS_C_MA_MECH*
-   feature applications can obtain the list of all supported mechanisms
-   of a given type (concrete, stackable, etc...).
-
-3.5.2.  GSS_Inquire_attrs_for_mech()
-
-   Inputs:
-   o  mech OBJECT IDENTIFIER -- mechanism OID
-
-   Outputs:
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  mech_attrs SET OF OBJECT IDENTIFIER -- set of mech_attrs OIDs
-      (GSS_C_MA_*)
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates success; the output mech_attrs parameter
-      MAY be the empty set (GSS_C_NO_OID_SET).
-   o  GSS_S_BAD_MECH indicates that the mechanism named by the mech
-      parameter does not exist or that mech is GSS_C_NO_OID and no
-      default mechanism could be determined.
-   o  GSS_S_FAILURE indicates that the request failed for some other
-      reason.
-
-   GSS_Inquire_mech_attrs_for_mech() indicates the set of mechanism
-   attributes supported by a given mechanism.
-
-   Because the mechanism attribute sets of composite mechanisms need not
-   be the union of their components', when called to obtain the feature
-
-
-
-Williams                 Expires April 19, 2006                 [Page 9]
-
-Internet-Draft          Extended GSS Mech Inquiry           October 2005
-
-
-   set of a composite mechanism GSS_Inquire_mech_attrs_for_mech()
-   obtains it by querying the mechanism at the top of the stack.  See
-   Section 3.1.
-
-3.5.3.  GSS_Display_mech_attr()
-
-   Inputs:
-   o  mech_attr OBJECT IDENTIFIER -- mechanism attribute OID
-
-   Outputs:
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  name OCTET STRING, -- name of mechanism attribute (e.g.,
-      GSS_C_MA_*)
-   o  short_desc OCTET STRING, -- a short description of the mechanism
-      attribute
-   o  long_desc OCTET STRING -- a longer description of the mechanism
-      attribute
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates success.
-   o  GSS_S_BAD_MECH_ATTR indicates that the mechanism attribute
-      referenced by the mech_attr parameter is unknown to the
-      implementation.
-   o  GSS_S_FAILURE indicates that the request failed for some other
-      reason.
-
-   This function can be used to obtain human-readable descriptions of
-   GSS-API mechanism attributes.
-
-3.5.4.  New Major Status Values
-
-   A single new major status code is added for GSS_Display_mech_attr():
-   o  GSS_S_BAD_MECH_ATTR
-   roughly corresponding to GSS_S_BAD_MECH, but applicable to mechanism
-   attribute OIDs, rather than to mechanism OIDs.
-
-   For the C-bindings GSS_S_BAD_MECH_ATTR shall have a routine error
-   number of 19 (this is shifted to the left by
-   GSS_C_ROUTINE_ERROR_OFFSET).
-
-3.5.5.  C-Bindings
-
-
-      #define GSS_S_BAD_MECH_ATTR (19ul << GSS_C_ROUTINE_ERROR_OFFSET)
-
-      OM_uint32 gss_inquire_mechs_for_mech_attrs(
-         OM_uint32         *minor_status,
-
-
-
-Williams                 Expires April 19, 2006                [Page 10]
-
-Internet-Draft          Extended GSS Mech Inquiry           October 2005
-
-
-         const gss_OID_set  desired_mech_attrs,
-         gss_OID_set       *mechs);
-
-      OM_uint32 gss_inquire_mech_attrs_for_mech(
-         OM_uint32         *minor_status,
-         const gss_OID      mech,
-         gss_OID_set       *mech_attrs);
-
-      OM_uint32 gss_display_mech_attr(
-         OM_uint32         *minor_status,
-         const gss_OID      mech_attr,
-         gss_buffer_t       name,
-         gss_buffer_t       short_desc,
-         gss_buffer_t       long_desc);
-
-
-   Figure 1
-
-
-4.  Requirements for Mechanism Designers
-
-   Stackable pseudo-mechanisms specifications MUST:
-   o  list the set of GSS-API mechanism attributes associated with them
-   o  list their initial mechanism composition rules
-   o  specify a mechanism for updating their mechanism composition rules
-
-   All other mechanism specifications MUST:
-   o  list the set of GSS-API mechanism attributes associated with them
-
-
-5.  IANA Considerations
-
-   The namsepace of programming language symbols with names beginning
-   with GSS_C_MA_* is reserved for allocation by the IANA.
-
-   Allocation of arcs in the namespace of OIDs relative to the base
-   mechanism attribute OID specified in Section 3.1 is reserved to the
-   IANA.
-
-
-6.  Security considerations
-
-   ...
-
-
-7.  References
-
-7.1.  Normative
-
-
-
-Williams                 Expires April 19, 2006                [Page 11]
-
-Internet-Draft          Extended GSS Mech Inquiry           October 2005
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-7.2.  Normative
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
-              Negotiation Mechanism", RFC 2478, December 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 12]
-
-Internet-Draft          Extended GSS Mech Inquiry           October 2005
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 13]
-
-Internet-Draft          Extended GSS Mech Inquiry           October 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 14]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gss-naming-00.txt b/doc/standardisation/draft-ietf-kitten-gss-naming-00.txt
deleted file mode 100644
index 66d7f0218..000000000
--- a/doc/standardisation/draft-ietf-kitten-gss-naming-00.txt
+++ /dev/null
@@ -1,726 +0,0 @@
-Network Working Group                                         S. Hartman
-Internet-Draft                                                       MIT
-Expires: May 31, 2005                                  November 30, 2004
-
-
-                 Desired Enhancements to GSSAPI Naming
-                  draft-ietf-kitten-gss-naming-00.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on May 31, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   The Generic Security Services API (GSS-API) provides a naming
-   architecture that supports  name-based authorization.  GSS-API
-   authenticates two named parties to each other.  Names can be stored
-   on access control lists to make authorization decisions.  Advances in
-   security mechanisms and the way implementers wish to use GSS-API
-   require this model to be extended.  Some mechanisms such as
-   public-key mechanisms do not have a single name to be used across all
-   environments.  Other mechanisms such as Kerberos allow names to
-
-
-
-Hartman                   Expires May 31, 2005                  [Page 1]
-
-Internet-Draft                 GSS Names                   November 2004
-
-
-   change as people move around organizations.  This document proposes
-   expanding the definition of GSS-API names to deal with these
-   situations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                   Expires May 31, 2005                  [Page 2]
-
-Internet-Draft                 GSS Names                   November 2004
-
-
-1.  Introduction
-
-   The Generic Security Services API [1] authenticates two named parties
-   to each other.  GSS names can be imported in a variety of formats
-   through the gss_import_name call.  Several mechanism-independent name
-   formats such as GSS_C_NT_HOSTBASED_SERVICE for services running on an
-   Internet host and GSS_C_NT_USER_NAME for the names of users.  Other
-   mechanism-specific name types are also provided.  By the time a name
-   is used in acquiring a mechanism-specific credential or establishing
-   a security context, it has been transformed into one of these
-   mechanism-specific name types.  In addition, the GSS-API provides a
-   function called gss_export_name that will flatten a GSS-API name into
-   a binary blob suitable for comparisons.  This binary blob can be
-   stored on ACLs and then authorization decisions can be made simply by
-   comparing the name exported from a newly accepted context to the name
-   on the ACL.
-
-   Inherent in this model is the idea that  mechanism names need to be
-   able to be represented in a single canonical form.  Anyone importing
-   that name needs to be able to retrieve the canonical form of that
-   name.
-
-   Several security mechanisms have been proposed for which this naming
-   architecture is too restrictive.  In some cases it is not always
-   possible to canonicalize any name that is imported.  In other cases
-   there is no single canonical name.
-
-   Storing names on ACLs can be problematic because names tend to change
-   over time .  If the name contains organizational information such as
-   a domain part or an indication of what department someone works for,
-   this changes as the person moves around the organization.  Even if no
-   organizational information is included in the name, the name will
-   change as people change their names.  Updating ACLs to reflect name
-   changes is difficult.
-
-   Also, as GSS-API is used in more complex environments, there is a
-   desire to use attribute certificates [5], Kerberos authorization data
-   [2], or other non-name-based authorization models.  GSS-API needs to
-   be enhanced in order to support these uses in a mechanism-independent
-   manner.
-
-   This draft discusses two different cases where the current GSS-API
-   naming seems inadequate.  Two proposals that have been discussed
-   within the IETF Kitten community are discussed.  Finally, the
-   problems that need to be resolved to adopt either of these proposals
-   are discussed.
-
-
-
-
-
-Hartman                   Expires May 31, 2005                  [Page 3]
-
-Internet-Draft                 GSS Names                   November 2004
-
-
-2.  Kerberos Naming
-
-   The Kerberos Referrals draft [3] proposes a new type of Kerberos name
-   called an enterprise name.  The intent is that the enterprise name is
-   an alias that the user knows for themselves and can use to login.
-   The Kerberos KDC translates this name into a normal Kerberos
-   principal and gives the user tickets for this principal.  This normal
-   principal is used for authorization.  The intent is that the
-   enterprise name tracks the user as they move throughout the
-   organization, even if they move to parts of the organization that
-   have different naming policies.  The name they type at login remains
-   constant, but the Kerberos principal used to authenticate them to
-   services changes.
-
-   Performing a mapping from enterprise  name to principal name is not
-   generally possible for unauthenticated services.  So in order to
-   canonicalize an enterprise name to get a principal, a service must
-   have credentials.  However it may not be desirable to allow services
-   to map enterprise names to principal names in the general case.
-   Also, Kerberos does not (and does not plan to) provide a mechanism
-   for mapping enterprise names to principals besides authentication as
-   the enterprise name.  Thus, any such mapping would be
-   vendor-specific.  With this feature in Kerberos, it is not possible
-   to implement gss_canonicalize_name for enterprise name types.
-
-   Another issue arises with enterprise names.  IN some cases it would
-   be desirable to put   the enterprise name on the ACL instead of a
-   principal name.  Thus, it would be desirable to include the
-   enterprise name in the name exported by gss_export_name.
-   Unfortunately, if this were done, the exported name would change
-   whenever the mapping changed, invalidating any ACL entries based off
-   the old exported name and defeating the purpose  of including the
-   enterprise name.  In some cases it would be desirable to have the
-   exported name be based on the enterprise name and in others based on
-   the principal name, but this is not permitted by the current GSS-API.
-
-   Another development also complicates GSS-API naming for Kerberos.
-   Several vendors have been looking at mechanisms to include group
-   membership information in Kerberos authorization data.  It is
-   desirable to put these group names on ACLs.  Again, GSS-API currently
-   has no mechanism to use this information.
-
-
-
-
-
-
-
-
-
-
-Hartman                   Expires May 31, 2005                  [Page 4]
-
-Internet-Draft                 GSS Names                   November 2004
-
-
-3.  X.509 Names
-
-   X.509 names are at least as complex as Kerberos names.  It seems  the
-   subject name might be the appropriate name to use as the name to be
-   exported in a GSS-API mechanism.  However RFC 3280 [4] does not even
-   require the subject name to be a non-empty sequence.  Instead there
-   are cases where the subjectAltName extension is the only thing to
-   identify the subject of the certificate.  As in the case of Kerberos
-   group memberships, there may be many subjectAltName extensions
-   available in a certificate.  Different applications will care about
-   different extensions.  Thus there is no single value that can be
-   defined as the exported GSS-API name that will be useful in all
-   environments.
-
-   A profile of a particular X.509  GSS-API mechanism could require a
-   specific name be used.  However this would limit that mechanism to
-   require a particular type of certificate.  There is interest in being
-   able to use arbitrary X.509 certificates with GSS-API for some
-   applications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                   Expires May 31, 2005                  [Page 5]
-
-Internet-Draft                 GSS Names                   November 2004
-
-
-4.  Composite Names
-
-   One proposal to solve these problems is to extend the concept of a
-   GSS-API name to include a set of name attributes.  Each attribute
-   would be an octet-string labeled by an OID.  Examples of attributes
-   would include Kerberos enterprise names, group memberships in an
-   authorization infrastructure, Kerberos authorization data attributes
-   and subjectAltName attributes in a certificate.  Several new
-   operations would be needed:
-   1.  Add attribute to name
-   2.  Query attributes of name
-   3.  Query values of an attribute
-   4.  Delete an attribute from a name
-
-4.1  Usage of Name Attributes
-
-   Since attributes are part of GSS-API names, the acceptor can retrieve
-   the attributes of the initiator's name from the context.  These
-   attributes can then be used for authorization.
-
-   Most name attributes will probably not come from explicit operations
-   to add attributes to a name.  Instead, name attributes will probably
-   come from mechanism specific credentials.  Mechanism specific naming
-   and group membership can be  mapped into name attributes by the
-   mechanism implementation.  The specific form of this mapping will
-   generally require protocol specification for each mechanism.
-
-   The value of many  name attributes may be suitable for use in binary
-   comparison.  This should enable applications to use these name
-   attributes on ACLs the same way exported names are now used on ACLs.
-   For example if a particular Subjectaltname extension contains the
-   appropriate  identity for an application, then  the name attribute
-   for this Subjectaltname can be placed on the ACL.  This is only true
-   if the name attribute is stored in some canonical form.
-
-4.2  Open issues
-
-   This section describes parts of the proposal to add attributes to
-   names that will need to be explored before the proposal can become a
-   protocol specification.
-
-   Are mechanisms expected to be able to carry arbitrary name attributes
-   as part of a context establishment?   At first it seems like this
-   would be desirable.  However the purpose of GSS-API is to establish
-   an authenticated context between two peers.  In particular, a context
-   authenticates two named entities to each other.  The names of these
-   entities and attributes associated with these names will be used for
-   authorization decisions.  If an initiator or acceptor is allowed to
-
-
-
-Hartman                   Expires May 31, 2005                  [Page 6]
-
-Internet-Draft                 GSS Names                   November 2004
-
-
-   assert name attributes and the authenticity of these assertions is
-   not validated by the mechanisms, then security problems will result.
-   On the other hand, requiring that name attributes be mechanism
-   specific and only be carried by mechanisms that understand the name
-   attributes and can validate them compromises GSS-API's place as a
-   generic API.  Application authors would be forced to understand
-   mechanism-specific attributes to make authorization decisions.  In
-   addition if mechanisms are not required to transport arbitrary
-   attributes, then application authors will need to deal with different
-   implementations of the same mechanism that support different sets of
-   name attributes.  One possible solution is to carry a source along
-   with each name attribute; this source could indicate whether the
-   attribute comes from a mechanism data structure or from the other
-   party in the authentication.
-
-   Another related question is how will name attributes be mapped into
-   their mechanism-specific forms.  For example it would be desirable to
-   map many  Kerberos authorization data elements into name attributes.
-   In the case of the Microsoft PAC, it would be desirable for some
-   applications to get the entire PAC.  However in many cases, the
-   specific lists of security IDs contained in the PAC would be more
-   directly useful to an application.  So there may not be a good
-   one-to-one mapping between the mechanism-specific elements and the
-   representation desirable at the GSS-API layer.
-
-   Specific name matching rules need to be developed.  How do names with
-   attributes compare?  What is the effect of a name attribute on a
-   target name in gss_accept_sec_context?
-
-4.3  Handling gss_export_name
-
-   For many mechanisms, there will be  an obvious choice to use for the
-   name exported by gss_export_name.  For example in the case of
-   Kerberos, the principal name can continue to be used as the exported
-   name.  This will allow applications depending on existing GSS-API
-   name-based authorization to continue to work.  However it is probably
-   desirable to allow GSS-API mechanisms for which gss_export_name
-   cannot meaningfully be defined.  The behavior of gss_export_name in
-   such cases should probably be to return some error.  Such mechanisms
-   may not work with existing applications and cannot conform to the
-   current version of the GSS-API.
-
-
-
-
-
-
-
-
-
-
-Hartman                   Expires May 31, 2005                  [Page 7]
-
-Internet-Draft                 GSS Names                   November 2004
-
-
-5.  Credential Extensions
-
-   An alternative to the name attributes proposal  is to extend GSS-API
-   credentials  with extensions labeled by OIDs.  Interfaces would be
-   needed to manipulate these credential extensions and to retrieve the
-   credential extensions for credentials used to establish a context.
-   Even if name attributes are used, credential extensions may be useful
-   for other unrelated purposes.
-
-   It is possible to solve problems discussed in this document using
-   some credential extension mechanism.  Doing so will have many of the
-   same open issues as discussed in the  composite names  proposal.  The
-   main advantage of a credential extensions proposal is that  it avoids
-   specifying how name attributes interact with name comparison or
-   target names.
-
-   The primary advantage of the name attributes proposal over credential
-   extensions is that name attributes seem to fit better into the
-   GSS-API authorization model.  Names are already available at all
-   points when authorization decisions are made.  In addition, for many
-   mechanisms the sort of information carried as name attributes will
-   also be carried as part of the name in the mechanism
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                   Expires May 31, 2005                  [Page 8]
-
-Internet-Draft                 GSS Names                   November 2004
-
-
-6.  Mechanisms for Export Name
-
-   Another proposal is to define some GSS-API mechanisms whose only
-   purpose is to have an exportable name form that is useful.  For
-   example, you might be able to export a name as a local machine user
-   ID with such a mechanism.
-
-   This solution works well especially for name information that can be
-   looked up in a directory.  It was unclear from the p      discussion
-   whether this solution would allow mechanism-specific name information
-   to be extracted from a context.  If so, then this solution would meet
-   many of the goals of this document.
-
-   One advantage of this solution is that it requires few if any changes
-   to GSS-API semantics.  It is not as flexible as other solutions.
-   Also, it is not clear how to handle mechanisms that do not have a
-   well defined name to export with this solution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                   Expires May 31, 2005                  [Page 9]
-
-Internet-Draft                 GSS Names                   November 2004
-
-
-7.  Deferring Credential Binding
-
-   Currently GSS-API credentials represent a single mechanism name.
-   While working on other issues discussion focused around choosing the
-   correct credential for a particular  target.  There are several
-   situations where an implementation can do a better job of choosing a
-   default source name to use given the name of the target to connect
-   to.  Currently, GSS-API does not provide a mechanism to do this.
-   Adding such a mechanism would be desirable.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                   Expires May 31, 2005                 [Page 10]
-
-Internet-Draft                 GSS Names                   November 2004
-
-
-8.  Security Considerations
-
-   GSS-API sets up a security context between two named parties.  The
-   GSS-API names are security assertions that are authenticated by the
-   context establishment process.  As such  the GSS naming architecture
-   is critical to the security of GSS-API.
-
-   Currently GSS-API uses a simplistic naming model for authorization.
-   Names can be compared  against a set of names on an access control
-   list.  This architecture is relatively simple and its security
-   properties are well understood.  However it does not provide the
-   flexibility and feature set for future deployments of GSS-API.
-
-   This proposal will significantly increase the complexity of the GSS
-   naming architecture.  As this proposal is fleshed out, we need to
-   consider ways of managing security exposures created by this
-   increased complexity.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                   Expires May 31, 2005                 [Page 11]
-
-Internet-Draft                 GSS Names                   November 2004
-
-
-9.  Acknowledgements
-
-   John Brezak, Paul Leach and Nicolas Williams all participated in
-   discussions that lead to a desire to enhance GSS naming.  Martin Rex
-   provided descriptions of the current naming architecture and pointed
-   out many ways in which proposed enhancements would create
-   interoperability problems or increase complexity.  Martin also
-   provided excellent information on what aspects of GSS naming have
-   tended to be implemented badly or have not met the needs of some
-   customers.
-
-   Nicolas Williams helped describe the possible approaches for
-   enhancing naming.
-
-10  Informative References
-
-   [1]  Linn, J., "Generic Security Service Application Program
-        Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [2]  Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos
-        Network Authentication Service (V5)",
-        draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
-        progress), June 2004.
-
-   [3]  Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating
-        KDC Referrals to locate Kerberos realms",
-        draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress),
-        2004.
-
-   [4]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
-        Public Key Infrastructure Certificate and Certificate Revocation
-        List (CRL) Profile", rfc 3280, April 2002.
-
-   [5]  Farrell, S. and R. Housley, "An Internet Attribute Certificate
-        Profile for Authorization.", rfc 3281, April 2002.
-
-
-Author's Address
-
-   Sam Hartman
-   MIT
-
-   EMail: hartmans@mit.edu
-
-
-
-
-
-
-
-
-Hartman                   Expires May 31, 2005                 [Page 12]
-
-Internet-Draft                 GSS Names                   November 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Hartman                   Expires May 31, 2005                 [Page 13]
-
diff --git a/doc/standardisation/draft-ietf-kitten-gss-naming-01.txt b/doc/standardisation/draft-ietf-kitten-gss-naming-01.txt
deleted file mode 100644
index 51771e593..000000000
--- a/doc/standardisation/draft-ietf-kitten-gss-naming-01.txt
+++ /dev/null
@@ -1,727 +0,0 @@
-Network Working Group                                         S. Hartman
-Internet-Draft                                                       MIT
-Expires: August 21, 2005                               February 20, 2005
-
-
-                 Desired Enhancements to GSSAPI Naming
-                  draft-ietf-kitten-gss-naming-01.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 21, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   The Generic Security Services API (GSS-API) provides a naming
-   architecture that supports  name-based authorization.  GSS-API
-   authenticates two named parties to each other.  Names can be stored
-   on access control lists to make authorization decisions.  Advances in
-   security mechanisms and the way implementers wish to use GSS-API
-   require this model to be extended.  As people move within an
-   organization or change their names, the name authenticated by GSS-API
-   may change.  Using some sort of constant identifier would make ACLs
-
-
-
-Hartman                 Expires August 21, 2005                 [Page 1]
-
-Internet-Draft                 GSS Names                   February 2005
-
-
-   more stable.  Some mechanisms such as public-key mechanisms do not
-   have a single name to be used across all environments.  Other
-   mechanisms such as Kerberos include may include group membership or
-   role information as part of authentication.  This document motivates
-   extensions to GSS-API naming and describes the extensions under
-   discussion.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires August 21, 2005                 [Page 2]
-
-Internet-Draft                 GSS Names                   February 2005
-
-
-1.  Introduction
-
-   The Generic Security Services API [2] authenticates two named parties
-   to each other.  GSS names can be imported in a variety of formats
-   through the gss_import_name call.  Several mechanism-independent name
-   formats are provided including GSS_C_NT_HOSTBASED_SERVICE for
-   services running on an Internet host and GSS_C_NT_USER_NAME for the
-   names of users.  Other mechanism-specific name types are also
-   provided.  By the time a name is used in acquiring a
-   mechanism-specific credential or establishing a security context, it
-   has been transformed into one of these mechanism-specific name types.
-   In addition, the GSS-API provides a function called gss_export_name
-   that will flatten a GSS-API name into a binary blob suitable for
-   comparisons.  This binary blob can be stored on ACLs and then
-   authorization decisions can be made simply by comparing the name
-   exported from a newly accepted context to the name on the ACL.
-
-   Storing names on ACLs can be problematic because names tend to change
-   over time .  If the name contains organizational information such as
-   a domain part or an indication of what department someone works for,
-   this changes as the person moves around the organization.  Even if no
-   organizational information is included in the name, the name will
-   change as people change their names.  Updating ACLs to reflect name
-   changes is difficult.
-
-   Inherent in the GSS naming  model is the idea that  mechanism names
-   need to be able to be represented in a single canonical form.  Anyone
-   importing that name needs to be able to retrieve the canonical form
-   of that name.
-
-   Several security mechanisms have been proposed for which this naming
-   architecture is too restrictive.  In some cases it is not always
-   possible to canonicalize any name that is imported.  In other cases
-   there is no single canonical name.
-
-   Also, as GSS-API is used in more complex environments, there is a
-   desire to use attribute certificates [6], Kerberos authorization data
-   [3], or other non-name-based authorization models.  GSS-API needs to
-   be enhanced in order to support these uses in a mechanism-independent
-   manner.
-
-   This document discusses the particular naming problems with two
-   important classes of GSS-API mechanisms.  It also discusses the set
-   of proposed solutions and open issues with these solutions.  This
-   draft limits discussion to these solutions and provides a description
-   of the problem against which the solutions can be judged.
-
-
-
-
-
-Hartman                 Expires August 21, 2005                 [Page 3]
-
-Internet-Draft                 GSS Names                   February 2005
-
-
-2.  Kerberos Naming
-
-   The Kerberos mechanism demonstrates both the naming stability problem
-   and the authorization extension problem.
-
-   The Kerberos Referrals draft [4] proposes a new type of Kerberos name
-   called an enterprise name.  The intent is that the enterprise name is
-   an alias that the user knows for themselves and can use to login.
-   The Kerberos KDC translates this name into a normal Kerberos
-   principal and gives the user tickets for this principal.  This normal
-   principal is used for authorization.  The intent is that the
-   enterprise name tracks the user as they move throughout the
-   organization, even if they move to parts of the organization that
-   have different naming policies.  The name they type at login remains
-   constant, but the Kerberos principal used to authenticate them to
-   services changes.
-
-   Performing a mapping from enterprise  name to principal name is not
-   generally possible for unauthenticated services.  Even authenticated
-   services may not be authorized to perform this mapping except for
-   their own name.  Also, Kerberos does not (and does not plan to)
-   provide a mechanism for mapping enterprise names to principals
-   besides authentication as the enterprise name.  Thus, any such
-   mapping would be vendor-specific.  With this feature in Kerberos, it
-   is not possible to implement gss_canonicalize_name for enterprise
-   name types.
-
-   Another issue arises with enterprise names.  IN some cases it would
-   be desirable to put   the enterprise name on the ACL instead of a
-   principal name for greater ACL stability.  At first glance this could
-   be accomplished by including the enterprise name in the name exported
-   by gss_export_name.  Unfortunately, if this were done, the exported
-   name would change whenever the mapping changed, invalidating any ACL
-   entries based off the old exported name and defeating the purpose  of
-   including the enterprise name in the exported name.  In some cases it
-   would be desirable to have the exported name be based on the
-   enterprise name and in others based on the principal name, but this
-   is not permitted by the current GSS-API.
-
-   Another development also complicates GSS-API naming for Kerberos.
-   Several vendors have been looking at mechanisms to include group
-   membership information in Kerberos authorization data.  It is
-   desirable to put these group names on ACLs.  Again, GSS-API currently
-   has no mechanism to use this information.
-
-
-
-
-
-
-
-Hartman                 Expires August 21, 2005                 [Page 4]
-
-Internet-Draft                 GSS Names                   February 2005
-
-
-3.  X.509 Names
-
-   X.509 names are more complicated than Kerberos names.  In the
-   Kerberos case there is a single principal carried in all Kerberos
-   messages.  X.509 certificates have multiple options.  It seems  the
-   subject name might be the appropriate name to use as the name to be
-   exported in a GSS-API mechanism.  However RFC 3280 [5] does not even
-   require the subject name to be a non-empty sequence.  Instead there
-   are cases where the subjectAltName extension is the only thing to
-   identify the subject of the certificate.  As in the case of Kerberos
-   group memberships, there may be many subjectAltName extensions
-   available in a certificate.  Different applications will care about
-   different extensions.  Thus there is no single value that can be
-   defined as the exported GSS-API name that will be useful in all
-   environments.
-
-   A profile of a particular X.509  GSS-API mechanism could require a
-   specific name be used.  However this would limit that mechanism to
-   require a particular type of certificate.  There is interest in being
-   able to use arbitrary X.509 certificates with GSS-API for some
-   applications.
-
-   Experience so far has not lead to sufficient interoperability with
-   GSS-API X.509 mechanisms.  Even if the subject name is used, there is
-   ambiguity in how to handle sorting of name components.  Martin Rex
-   said that he was aware of several SPKM [1] implementations but no two
-   were fully interoperable on names.
-
-   Also, as discussed in the introduction, it is desirable to support
-   X.509 attribute certificates.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires August 21, 2005                 [Page 5]
-
-Internet-Draft                 GSS Names                   February 2005
-
-
-4.  Composite Names
-
-   One proposal to solve these problems is to extend the concept of a
-   GSS-API name to include a set of name attributes.  Each attribute
-   would be an octet-string labeled by an OID.  Examples of attributes
-   would include Kerberos enterprise names, group memberships in an
-   authorization infrastructure, Kerberos authorization data attributes
-   and subjectAltName attributes in a certificate.  Several new
-   operations would be needed:
-   1.  Add an  attribute to name.
-   2.  Query attributes of name.
-   3.  Query values of an attribute.
-   4.  Delete an attribute from a name.
-   5.  Export a complete composite name and all its attributes for
-       transport between processes.
-
-   Note that an exported composite name would not be suitable for binary
-   comparison.  Avoiding confusion between this operation and the
-   existing gss_export_name operation will require careful work.
-
-4.1  Usage of Name Attributes
-
-   Since attributes are part of GSS-API names, the acceptor can retrieve
-   the attributes of the initiator's and acceptor's name from the
-   context.  These attributes can then be used for authorization.
-
-   Most name attributes will probably not come from explicit operations
-   to add attributes to a name.  Instead, name attributes will probably
-   come from mechanism specific credentials.  Components of these
-   mechanism specific credentials may come from platform or
-   environment-specific names.  Mechanism specific naming and group
-   membership can be  mapped into name attributes by the mechanism
-   implementation.  The specific form of this mapping will generally
-   require protocol specification for each mechanism.
-
-   The value of many  name attributes may be suitable for use in binary
-   comparison.  This should enable applications to use these name
-   attributes on ACLs the same way exported names are now used on ACLs.
-   For example if a particular Subjectaltname extension contains the
-   appropriate  identity for an application, then  the name attribute
-   for this Subjectaltname can be placed on the ACL.  This is only true
-   if the name attribute is stored in some canonical form.
-
-4.2  Open issues
-
-   This section describes parts of the proposal to add attributes to
-   names that will need to be explored before the proposal can become a
-   protocol specification.
-
-
-
-Hartman                 Expires August 21, 2005                 [Page 6]
-
-Internet-Draft                 GSS Names                   February 2005
-
-
-   Are mechanisms expected to be able to carry arbitrary name attributes
-   as part of a context establishment?   At first it seems like this
-   would be desirable.  However the purpose of GSS-API is to establish
-   an authenticated context between two peers.  In particular, a context
-   authenticates two named entities to each other.  The names of these
-   entities and attributes associated with these names will be used for
-   authorization decisions.  If an initiator or acceptor is allowed to
-   assert name attributes and the authenticity of these assertions is
-   not validated by the mechanisms, then security problems will result.
-   On the other hand, requiring that name attributes be mechanism
-   specific and only be carried by mechanisms that understand the name
-   attributes and can validate them compromises GSS-API's place as a
-   generic API.  Application authors would be forced to understand
-   mechanism-specific attributes to make authorization decisions.  In
-   addition if mechanisms are not required to transport arbitrary
-   attributes, then application authors will need to deal with different
-   implementations of the same mechanism that support different sets of
-   name attributes.  One possible solution is to carry a source along
-   with each name attribute; this source could indicate whether the
-   attribute comes from a mechanism data structure or from the other
-   party in the authentication.
-
-   Another related question is how will name attributes be mapped into
-   their mechanism-specific forms.  For example it would be desirable to
-   map many  Kerberos authorization data elements into name attributes.
-   In the case of the Microsoft PAC, it would be desirable for some
-   applications to get the entire PAC.  However in many cases, the
-   specific lists of security IDs contained in the PAC would be more
-   directly useful to an application.  So there may not be a good
-   one-to-one mapping between the mechanism-specific elements and the
-   representation desirable at the GSS-API layer.
-
-   Specific name matching rules need to be developed.  How do names with
-   attributes compare?  What is the effect of a name attribute on a
-   target name in gss_accept_sec_context?
-
-4.3  Handling gss_export_name
-
-   For many mechanisms, there will be  an obvious choice to use for the
-   name exported by gss_export_name.  For example in the case of
-   Kerberos, the principal name can continue to be used as the exported
-   name.  This will allow applications depending on existing GSS-API
-   name-based authorization to continue to work.  However it is probably
-   desirable to allow GSS-API mechanisms for which gss_export_name
-   cannot meaningfully be defined.  The behavior of gss_export_name in
-   such cases should probably be to return some error.  Such mechanisms
-   may not work with existing applications and cannot conform to the
-   current version of the GSS-API.
-
-
-
-Hartman                 Expires August 21, 2005                 [Page 7]
-
-Internet-Draft                 GSS Names                   February 2005
-
-
-5.  Credential Extensions
-
-   An alternative to the name attributes proposal  is to extend GSS-API
-   credentials  with extensions labeled by OIDs.  Interfaces would be
-   needed to manipulate these credential extensions and to retrieve the
-   credential extensions for credentials used to establish a context.
-   Even if name attributes are used, credential extensions may be useful
-   for other unrelated purposes.
-
-   It is possible to solve problems discussed in this document using
-   some credential extension mechanism.  Doing so will have many of the
-   same open issues as discussed in the  composite names  proposal.  The
-   main advantage of a credential extensions proposal is that  it avoids
-   specifying how name attributes interact with name comparison or
-   target names.
-
-   The primary advantage of the name attributes proposal over credential
-   extensions is that name attributes seem to fit better into the
-   GSS-API authorization model.  Names are already available at all
-   points when authorization decisions are made.  In addition, for many
-   mechanisms the sort of information carried as name attributes will
-   also be carried as part of the name in the mechanism
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires August 21, 2005                 [Page 8]
-
-Internet-Draft                 GSS Names                   February 2005
-
-
-6.  Mechanisms for Export Name
-
-   Another proposal is to define some GSS-API mechanisms whose only
-   purpose is to have an exportable name form that is useful.  For
-   example, you might be able to export a name as a local machine user
-   ID with such a mechanism.
-
-   This solution works well especially for name information that can be
-   looked up in a directory.  It was unclear from the p      discussion
-   whether this solution would allow mechanism-specific name information
-   to be extracted from a context.  If so, then this solution would meet
-   many of the goals of this document.
-
-   One advantage of this solution is that it requires few if any changes
-   to GSS-API semantics.  It is not as flexible as other solutions.
-   Also, it is not clear how to handle mechanisms that do not have a
-   well defined name to export with this solution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires August 21, 2005                 [Page 9]
-
-Internet-Draft                 GSS Names                   February 2005
-
-
-7.  Deferring Credential Binding
-
-   Currently GSS-API credentials represent a single mechanism name.
-   While working on other issues discussion focused around choosing the
-   correct credential for a particular  target.  There are several
-   situations where an implementation can do a better job of choosing a
-   default source name to use given the name of the target to connect
-   to.  Currently, GSS-API does not provide a mechanism to do this.
-   Adding such a mechanism would be desirable.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires August 21, 2005                [Page 10]
-
-Internet-Draft                 GSS Names                   February 2005
-
-
-8.  Security Considerations
-
-   GSS-API sets up a security context between two named parties.  The
-   GSS-API names are security assertions that are authenticated by the
-   context establishment process.  As such  the GSS naming architecture
-   is critical to the security of GSS-API.
-
-   Currently GSS-API uses a simplistic naming model for authorization.
-   Names can be compared  against a set of names on an access control
-   list.  This architecture is relatively simple and its security
-   properties are well understood.  However it does not provide the
-   flexibility and feature set for future deployments of GSS-API.
-
-   This proposal will significantly increase the complexity of the GSS
-   naming architecture.  As this proposal is fleshed out, we need to
-   consider ways of managing security exposures created by this
-   increased complexity.
-
-   One area where the complexity may lead to security problems is
-   composite names with attributes from different sources.  This may be
-   desirable so that name attributes that carry their own
-   authentication.  However the design of any solutions needs to make
-   sure that applications can assign appropriate trust to name
-   components.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires August 21, 2005                [Page 11]
-
-Internet-Draft                 GSS Names                   February 2005
-
-
-9.  Acknowledgements
-
-   John Brezak, Paul Leach and Nicolas Williams all participated in
-   discussions that lead to a desire to enhance GSS naming.  Martin Rex
-   provided descriptions of the current naming architecture and pointed
-   out many ways in which proposed enhancements would create
-   interoperability problems or increase complexity.  Martin also
-   provided excellent information on what aspects of GSS naming have
-   tended to be implemented badly or have not met the needs of some
-   customers.
-
-   Nicolas Williams helped describe the possible approaches for
-   enhancing naming.
-
-10  Informative References
-
-   [1]  Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", rfc
-        2025, October 1996.
-
-   [2]  Linn, J., "Generic Security Service Application Program
-        Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [3]  Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos
-        Network Authentication Service (V5)",
-        draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
-        progress), June 2004.
-
-   [4]  Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating
-        KDC Referrals to locate Kerberos realms",
-        draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress),
-        2004.
-
-   [5]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
-        Public Key Infrastructure Certificate and Certificate Revocation
-        List (CRL) Profile", rfc 3280, April 2002.
-
-   [6]  Farrell, S. and R. Housley, "An Internet Attribute Certificate
-        Profile for Authorization.", rfc 3281, April 2002.
-
-
-Author's Address
-
-   Sam Hartman
-   MIT
-
-   EMail: hartmans@mit.edu
-
-
-
-
-
-Hartman                 Expires August 21, 2005                [Page 12]
-
-Internet-Draft                 GSS Names                   February 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Hartman                 Expires August 21, 2005                [Page 13]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gss-naming-02.txt b/doc/standardisation/draft-ietf-kitten-gss-naming-02.txt
deleted file mode 100644
index b5d044788..000000000
--- a/doc/standardisation/draft-ietf-kitten-gss-naming-02.txt
+++ /dev/null
@@ -1,842 +0,0 @@
-
-
-
-
-Network Working Group                                         S. Hartman
-Internet-Draft                                                       MIT
-Expires: December 4, 2005                                   June 2, 2005
-
-
-                 Desired Enhancements to GSSAPI Naming
-                  draft-ietf-kitten-gss-naming-02.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on December 4, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   The Generic Security Services API (GSS-API) provides a naming
-   architecture that supports  name-based authorization.  GSS-API
-   authenticates two named parties to each other.  Names can be stored
-   on access control lists to make authorization decisions.  Advances in
-   security mechanisms and the way implementers wish to use GSS-API
-   require this model to be extended.  As people move within an
-   organization or change their names, the name authenticated by GSS-API
-   may change.  Using some sort of constant identifier would make ACLs
-   more stable.  Some mechanisms such as public-key mechanisms do not
-
-
-
-Hartman                 Expires December 4, 2005                [Page 1]
-
-Internet-Draft                  GSS Names                      June 2005
-
-
-   have a single name to be used across all environments.  Other
-   mechanisms such as Kerberos include may include group membership or
-   role information as part of authentication.  This document motivates
-   extensions to GSS-API naming and describes the extensions under
-   discussion.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires December 4, 2005                [Page 2]
-
-Internet-Draft                  GSS Names                      June 2005
-
-
-1.  Introduction
-
-   The Generic Security Services API [2] authenticates two named parties
-   to each other.  GSS names can be imported in a variety of formats
-   through the gss_import_name call.  Several mechanism-independent name
-   formats are provided including GSS_C_NT_HOSTBASED_SERVICE for
-   services running on an Internet host and GSS_C_NT_USER_NAME for the
-   names of users.  Other mechanism-specific name types are also
-   provided.  By the time a name is used in acquiring a mechanism-
-   specific credential or establishing a security context, it has been
-   transformed into one of these mechanism-specific name types.  In
-   addition, the GSS-API provides a function called gss_export_name that
-   will flatten a GSS-API name into a binary blob suitable for
-   comparisons.  This binary blob can be stored on ACLs and then
-   authorization decisions can be made simply by comparing the name
-   exported from a newly accepted context to the name on the ACL.
-
-   Storing names on ACLs can be problematic because names tend to change
-   over time .  If the name contains organizational information such as
-   a domain part or an indication of what department someone works for,
-   this changes as the person moves around the organization.  Even if no
-   organizational information is included in the name, the name will
-   change as people change their names.  Updating ACLs to reflect name
-   changes is difficult.  Another significant problem is that names can
-   be reused to apply to another entity than the entity to which they
-   originally applied.  For example if a Unix user ID is placed on an
-   ACL, the account deleted and then a new user assigned the old ID,
-   then that new user may gain privileges intended for the old user.
-
-   Inherent in the GSS naming  model is the idea that  mechanism names
-   need to be able to be represented in a single canonical form.  Anyone
-   importing that name needs to be able to retrieve the canonical form
-   of that name.
-
-   Several security mechanisms have been proposed for which this naming
-   architecture is too restrictive.  In some cases it is not always
-   possible to canonicalize any name that is imported.  In other cases
-   there is no single canonical name.
-
-   Also, as GSS-API is used in more complex environments, there is a
-   desire to use attribute certificates [6], Kerberos authorization data
-   [3], or other non-name-based authorization models.  GSS-API needs to
-   be enhanced in order to support these uses in a mechanism-independent
-   manner.
-
-   This document discusses the particular naming problems with two
-   important classes of GSS-API mechanisms.  It also discusses the set
-   of proposed solutions and open issues with these solutions.  This
-
-
-
-Hartman                 Expires December 4, 2005                [Page 3]
-
-Internet-Draft                  GSS Names                      June 2005
-
-
-   draft limits discussion to these solutions and provides a description
-   of the problem against which the solutions can be judged.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires December 4, 2005                [Page 4]
-
-Internet-Draft                  GSS Names                      June 2005
-
-
-2.  Kerberos Naming
-
-   The Kerberos mechanism demonstrates both the naming stability problem
-   and the authorization extension problem.
-
-   The Kerberos Referrals draft [4] proposes a new type of Kerberos name
-   called an enterprise name.  The intent is that the enterprise name is
-   an alias that the user knows for themselves and can use to login.
-   The Kerberos KDC translates this name into a normal Kerberos
-   principal and gives the user tickets for this principal.  This normal
-   principal is used for authorization.  The intent is that the
-   enterprise name tracks the user as they move throughout the
-   organization, even if they move to parts of the organization that
-   have different naming policies.  The name they type at login remains
-   constant, but the Kerberos principal used to authenticate them to
-   services changes.
-
-   Performing a mapping from enterprise  name to principal name is not
-   generally possible for unauthenticated services.  Even authenticated
-   services may not be authorized to perform this mapping except for
-   their own name.  Also, Kerberos does not (and does not plan to)
-   provide a mechanism for mapping enterprise names to principals
-   besides authentication as the enterprise name.  Thus, any such
-   mapping would be vendor-specific.  With this feature in Kerberos, it
-   is not possible to implement gss_canonicalize_name for enterprise
-   name types.
-
-   Another issue arises with enterprise names.  IN some cases it would
-   be desirable to put   the enterprise name on the ACL instead of a
-   principal name for greater ACL stability.  At first glance this could
-   be accomplished by including the enterprise name in the name exported
-   by gss_export_name.  Unfortunately, if this were done, the exported
-   name would change whenever the mapping changed, invalidating any ACL
-   entries based off the old exported name and defeating the purpose  of
-   including the enterprise name in the exported name.  In some cases it
-   would be desirable to have the exported name be based on the
-   enterprise name and in others based on the principal name, but this
-   is not permitted by the current GSS-API.
-
-   Another development also complicates GSS-API naming for Kerberos.
-   Several vendors have been looking at mechanisms to include group
-   membership information in Kerberos authorization data.  It is
-   desirable to put these group names on ACLs.  Again, GSS-API currently
-   has no mechanism to use this information.
-
-
-
-
-
-
-
-Hartman                 Expires December 4, 2005                [Page 5]
-
-Internet-Draft                  GSS Names                      June 2005
-
-
-3.  X.509 Names
-
-   X.509 names are more complicated than Kerberos names.  In the
-   Kerberos case there is a single principal carried in all Kerberos
-   messages.  X.509 certificates have multiple options.  It seems  the
-   subject name might be the appropriate name to use as the name to be
-   exported in a GSS-API mechanism.  However RFC 3280 [5] does not even
-   require the subject name to be a non-empty sequence.  Instead there
-   are cases where the subjectAltName extension is the only thing to
-   identify the subject of the certificate.  As in the case of Kerberos
-   group memberships, there may be many subjectAltName extensions
-   available in a certificate.  Different applications will care about
-   different extensions.  One possible candidate for an exported name
-   would be all the names and SubjectAltName extensions from a
-   certificate.  However as new names are added then existing ACL
-   entries would be invalidated; this is undesirable.  Thus there is no
-   single value that can be  defined as the exported GSS-API name that
-   will be useful in all environments.
-
-   A profile of a particular X.509  GSS-API mechanism could require a
-   specific name be used.  However this would limit that mechanism to
-   require a particular type of certificate.  There is interest in being
-   able to use arbitrary X.509 certificates with GSS-API for some
-   applications.
-
-   Experience so far has not lead to sufficient interoperability with
-   GSS-API X.509 mechanisms.  Even if the subject name is used, there is
-   ambiguity in how to handle sorting of name components.  Martin Rex
-   said that he was aware of several SPKM [1] implementations but no two
-   were fully interoperable on names.
-
-   Also, as discussed in the introduction, it is desirable to support
-   X.509 attribute certificates.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires December 4, 2005                [Page 6]
-
-Internet-Draft                  GSS Names                      June 2005
-
-
-4.  Composite Names
-
-   One proposal to solve these problems is to extend the concept of a
-   GSS-API name to include a set of name attributes.  Each attribute
-   would be an octet-string labeled by an OID.  Examples of attributes
-   would include Kerberos enterprise names, group memberships in an
-   authorization infrastructure, Kerberos authorization data attributes
-   and subjectAltName attributes in a certificate.  Several new
-   operations would be needed:
-
-   1.  Add an  attribute to name.
-
-   2.  Query attributes of name.
-
-   3.  Query values of an attribute.
-
-   4.  Delete an attribute from a name.
-
-   5.  Export a complete composite name and all its attributes for
-       transport between processes.
-
-   Note that an exported composite name would not generally be suitable
-   for binary comparison.  Avoiding confusion between this operation and
-   the existing gss_export_name operation will require careful work.
-
-   Additional utility operations will probably be needed depending on
-   the implementation of name attributes.
-
-4.1  Usage of Name Attributes
-
-   Since attributes are part of GSS-API names, the acceptor can retrieve
-   the attributes of the initiator's and acceptor's name from the
-   context.  These attributes can then be used for authorization.
-
-   Most name attributes will probably not come from explicit operations
-   to add attributes to a name.  Instead, name attributes will probably
-   come from mechanism specific credentials.  Components of these
-   mechanism specific credentials may come from platform or environment-
-   specific names.  Mechanism specific naming and group membership can
-   be  mapped into name attributes by the mechanism implementation.  The
-   specific form of this mapping will generally require protocol
-   specification for each mechanism.
-
-   The value of many  name attributes may be suitable for use in binary
-   comparison.  This should enable applications to use these name
-   attributes on ACLs the same way exported names are now used on ACLs.
-   For example if a particular Subjectaltname extension contains the
-   appropriate  identity for an application, then  the name attribute
-
-
-
-Hartman                 Expires December 4, 2005                [Page 7]
-
-Internet-Draft                  GSS Names                      June 2005
-
-
-   for this Subjectaltname can be placed on the ACL.  This is only true
-   if the name attribute is stored in some canonical form.
-
-4.2  Open issues
-
-   This section describes parts of the proposal to add attributes to
-   names that will need to be explored before the proposal can become a
-   protocol specification.
-
-   Are mechanisms expected to be able to carry arbitrary name attributes
-   as part of a context establishment?  At first it seems like this
-   would be desirable.  However the purpose of GSS-API is to establish
-   an authenticated context between two peers.  In particular, a context
-   authenticates two named entities to each other.  The names of these
-   entities and attributes associated with these names will be used for
-   authorization decisions.  If an initiator or acceptor is allowed to
-   assert name attributes and the authenticity of these assertions is
-   not validated by the mechanisms, then security problems will result.
-   On the other hand, requiring that name attributes be mechanism
-   specific and only be carried by mechanisms that understand the name
-   attributes and can validate them compromises GSS-API's place as a
-   generic API.  Application authors would be forced to understand
-   mechanism-specific attributes to make authorization decisions.  In
-   addition if mechanisms are not required to transport arbitrary
-   attributes, then application authors will need to deal with different
-   implementations of the same mechanism that support different sets of
-   name attributes.  One possible solution is to carry a source along
-   with each name attribute; this source could indicate whether the
-   attribute comes from a mechanism data structure or from the other
-   party in the authentication.
-
-   Another related question is how will name attributes be mapped into
-   their mechanism-specific forms.  For example it would be desirable to
-   map many  Kerberos authorization data elements into name attributes.
-   In the case of the Microsoft PAC, it would be desirable for some
-   applications to get the entire PAC.  However in many cases, the
-   specific lists of security IDs contained in the PAC would be more
-   directly useful to an application.  So there may not be a good one-
-   to-one mapping between the mechanism-specific elements and the
-   representation desirable at the GSS-API layer.
-
-   Specific name matching rules need to be developed.  How do names with
-   attributes compare?  What is the effect of a name attribute on a
-   target name in gss_accept_sec_context?
-
-4.3  Handling gss_export_name
-
-   For many mechanisms, there will be  an obvious choice to use for the
-
-
-
-Hartman                 Expires December 4, 2005                [Page 8]
-
-Internet-Draft                  GSS Names                      June 2005
-
-
-   name exported by gss_export_name.  For example in the case of
-   Kerberos, the principal name can continue to be used as the exported
-   name.  This will allow applications depending on existing GSS-API
-   name-based authorization to continue to work.  However it is probably
-   desirable to allow GSS-API mechanisms for which gss_export_name
-   cannot meaningfully be defined.  The behavior of gss_export_name in
-   such cases should probably be to return some error.  Such mechanisms
-   may not work with existing applications and cannot conform to the
-   current version of the GSS-API.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires December 4, 2005                [Page 9]
-
-Internet-Draft                  GSS Names                      June 2005
-
-
-5.  Credential Extensions
-
-   An alternative to the name attributes proposal  is to extend GSS-API
-   credentials  with extensions labeled by OIDs.  Interfaces would be
-   needed to manipulate these credential extensions and to retrieve the
-   credential extensions for credentials used to establish a context.
-   Even if name attributes are used, credential extensions may be useful
-   for other unrelated purposes.
-
-   It is possible to solve problems discussed in this document using
-   some credential extension mechanism.  Doing so will have many of the
-   same open issues as discussed in the  composite names  proposal.  The
-   main advantage of a credential extensions proposal is that  it avoids
-   specifying how name attributes interact with name comparison or
-   target names.
-
-   The primary advantage of the name attributes proposal over credential
-   extensions is that name attributes seem to fit better into the GSS-
-   API authorization model.  Names are already available at all points
-   when authorization decisions are made.  In addition, for many
-   mechanisms the sort of information carried as name attributes will
-   also be carried as part of the name in the mechanism
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires December 4, 2005               [Page 10]
-
-Internet-Draft                  GSS Names                      June 2005
-
-
-6.  Mechanisms for Export Name
-
-   Another proposal is to define some GSS-API mechanisms whose only
-   purpose is to have an exportable name form that is useful.  For
-   example, you might be able to export a name as a local machine user
-   ID with such a mechanism.
-
-   This solution works well especially for name information that can be
-   looked up in a directory.  It was unclear from the p      discussion
-   whether this solution would allow mechanism-specific name information
-   to be extracted from a context.  If so, then this solution would meet
-   many of the goals of this document.
-
-   One advantage of this solution is that it requires few if any changes
-   to GSS-API semantics.  It is not as flexible as other solutions.
-   Also, it is not clear how to handle mechanisms that do not have a
-   well defined name to export with this solution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires December 4, 2005               [Page 11]
-
-Internet-Draft                  GSS Names                      June 2005
-
-
-7.  Deferring Credential Binding
-
-   Currently GSS-API credentials represent a single mechanism name.
-   While working on other issues discussion came up focused around
-   choosing the correct credential for a particular target.  There are
-   several situations where an implementation can do a better job of
-   choosing a default source name to use given the name of the target to
-   connect to.  Currently, GSS-API does not provide a mechanism to do
-   this.  Adding such a mechanism would be desirable.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires December 4, 2005               [Page 12]
-
-Internet-Draft                  GSS Names                      June 2005
-
-
-8.  Security Considerations
-
-   GSS-API sets up a security context between two named parties.  The
-   GSS-API names are security assertions that are authenticated by the
-   context establishment process.  As such  the GSS naming architecture
-   is critical to the security of GSS-API.
-
-   Currently GSS-API uses a simplistic naming model for authorization.
-   Names can be compared  against a set of names on an access control
-   list.  This architecture is relatively simple and its security
-   properties are well understood.  However it does not provide the
-   flexibility and feature set for future deployments of GSS-API.
-
-   This proposal will significantly increase the complexity of the GSS
-   naming architecture.  As this proposal is fleshed out, we need to
-   consider ways of managing security exposures created by this
-   increased complexity.
-
-   One area where the complexity may lead to security problems is
-   composite names with attributes from different sources.  This may be
-   desirable so that name attributes that carry their own
-   authentication.  However the design of any solutions needs to make
-   sure that applications can assign appropriate trust to name
-   components.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires December 4, 2005               [Page 13]
-
-Internet-Draft                  GSS Names                      June 2005
-
-
-9.  Acknowledgements
-
-   John Brezak, Paul Leach and Nicolas Williams all participated in
-   discussions that lead to a desire to enhance GSS naming.  Martin Rex
-   provided descriptions of the current naming architecture and pointed
-   out many ways in which proposed enhancements would create
-   interoperability problems or increase complexity.  Martin also
-   provided excellent information on what aspects of GSS naming have
-   tended to be implemented badly or have not met the needs of some
-   customers.
-
-   Nicolas Williams helped describe the possible approaches for
-   enhancing naming.
-
-10.  Informative References
-
-   [1]  Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
-        rfc 2025, October 1996.
-
-   [2]  Linn, J., "Generic Security Service Application Program
-        Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [3]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
-        Network Authentication Service (V5)",
-        draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
-        progress), June 2004.
-
-   [4]  Jaganathan , K., Zhu, L., Swift, M., and J. Brezak, "Generating
-        KDC Referrals to locate Kerberos realms",
-        draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress),
-        2004.
-
-   [5]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
-        Public Key Infrastructure Certificate and Certificate Revocation
-        List (CRL) Profile", rfc 3280, April 2002.
-
-   [6]  Farrell, S. and R. Housley, "An Internet Attribute Certificate
-        Profile for Authorization.", rfc 3281, April 2002.
-
-
-Author's Address
-
-   Sam Hartman
-   MIT
-
-   Email: hartmans@mit.edu
-
-
-
-
-
-Hartman                 Expires December 4, 2005               [Page 14]
-
-Internet-Draft                  GSS Names                      June 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Hartman                 Expires December 4, 2005               [Page 15]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-00.txt b/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-00.txt
deleted file mode 100644
index b7bcc7c5e..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-00.txt
+++ /dev/null
@@ -1,784 +0,0 @@
-
-KITTEN WG                                                    N. Williams
-Internet-Draft                                                       Sun
-Expires: December 30, 2004                                     July 2004
-
-
-  Clarifications and Extensions to the GSS-API for the Use of Channel
-                                Bindings
-            draft-ietf-kitten-gssapi-channel-bindings-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on December 30, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This document clarifies and generalizes the GSS-API "channel
-   bindings" facility.  This document also specifies the format of the
-   various types of channel bindings.
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 1]
-
-Internet-Draft          GSS-API Channel Bindings               July 2004
-
-
-Table of Contents
-
-   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  Generic Structure for GSS-API Channel Bindings . . . . . . . .  5
-     3.1   Proper Mechanism Use of Channel Bindings . . . . . . . . .  5
-   4.  Channel Bindings for SSHv2 . . . . . . . . . . . . . . . . . .  6
-     4.1   GSS_Make_sshv2_channel_bindings()  . . . . . . . . . . . .  6
-       4.1.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . .  6
-   5.  Channel Bindings for TLS . . . . . . . . . . . . . . . . . . .  7
-     5.1   GSS_Make_tls_channel_bindings()  . . . . . . . . . . . . .  7
-       5.1.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . .  7
-   6.  Channel Bindings for IPsec . . . . . . . . . . . . . . . . . .  8
-     6.1   GSS_Make_ipsec_channel_bindings()  . . . . . . . . . . . .  8
-       6.1.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   8.1   Normative  . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   8.2   Informative  . . . . . . . . . . . . . . . . . . . . . . . . 11
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
-   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
-       Intellectual Property and Copyright Statements . . . . . . . . 14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 2]
-
-Internet-Draft          GSS-API Channel Bindings               July 2004
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 3]
-
-Internet-Draft          GSS-API Channel Bindings               July 2004
-
-
-2.  Introduction
-
-   The concept of "channel bindings" and the abstract construction of
-   channel bindings for several types of channels are described in
-   [CHANNEL-BINDINGS]
-
-   To actually use channel bindings in GSS-API aplications additional
-   details are required that are given below.
-
-   First the structure given to channel bindings data in [RFC2744] is
-   generalized to all of the GSS-API, not just its C-Bindings.
-
-   Then the actual construction of channel bindings to SSHv2, TLS and
-   IPsec channels is given.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 4]
-
-Internet-Draft          GSS-API Channel Bindings               July 2004
-
-
-3.  Generic Structure for GSS-API Channel Bindings
-
-   The base GSS-API v2, update 1 specification [RFC2743]describes
-   channel bindings as an OCTET STRING and leaves it to the GSS-API v2,
-   update 1 C-Bindings specification to specify the structure of the
-   contents of the channel bindings OCTET STRINGs.  The C-Bindings
-   specification [RFC2744]then defines, in terms of C, what should be
-   generic structure for channel bindings.  The Kerberos V GSS mechanism
-   [RFC1964]then defines a method for encoding GSS channel bindings in a
-   way that is independent of the C-Bindings!
-
-   In other words, the structure of GSS channel bindings given in
-   [RFC2744] is actually generic, rather than specific to the C
-   programming language.
-
-   Here, then, is a generic re-statement of this structure, in
-   pseudo-ASN.1:
-
-   		GSS-CHANNEL-BINDINGS := SEQUENCE {
-   			initiator-address-type	INTEGER,
-   			initiator-address	OCTET STRING,
-   			acceptor-address-type   INTEGER,
-   			acceptor-address	OCTET STRING,
-   			application-data	OCTET STRING,
-   		}
-
-   The values for the address fields are described in [RFC2744].
-
-   Language-specific bindings of the GSS-API should specify a
-   language-specific formulation of this structure.
-
-3.1  Proper Mechanism Use of Channel Bindings
-
-   As described in [CHANNEL-BINDINGS], GSS mechanisms should exchange
-   integrity protected proofs of channel bindings, where the proof is
-   obtained by running a strong hash of the channel bindings data
-   (encoded as per some mechanism-specific, such as in [RFC1964]) and a
-   binary value to represent the initiator->acceptor, and opposite,
-   direction.
-
-   The encoding of channel bindings used in [RFC1964], with the addition
-   of a binary value as described above, and the substitution of SHA-1
-   for MD5 is a reasonable, generic encoding of GSS-CHANNEL-BINDINGS
-   that any future GSS mechanisms can use.
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 5]
-
-Internet-Draft          GSS-API Channel Bindings               July 2004
-
-
-4.  Channel Bindings for SSHv2
-
-   The SSHv2 channel bindings are constructed as an octet string for the
-   'application-data' field of the channel bindings by concatenating the
-   following values and in this order:
-
-   1.  The ASCII string "GSS SSHv2 CB:"
-   2.  The SSHv2 session ID
-   3.  Any additional application-provided data, encoded as the DER
-       encoding of an ASN.1 OCTET STRING
-
-4.1  GSS_Make_sshv2_channel_bindings()
-
-   Inputs:
-
-   o  session_id OCTET STRING,
-   o  additional_app_data OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  channel_bindings_app_data OCTET STRING
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates no error.
-   o  GSS_S_FAILURE indicates failure to construct the channel bindings
-      as a result, perhaps, of a memory management, or similar failure.
-
-   This function constructs an OCTET STRING for use as the value of the
-   application-data field of the GSS-CHANNEL-BINDINGS structure
-   described above.
-
-4.1.1  C-Bindings
-
-   OM_uint32 gss_make_sshv2_channel_bindings(
-     OM_uint32			*minor_status,
-     const gss_buffer_t		session_id,
-     const gss_buffer_t		additional_app_data,
-     gss_buffer_t	     channel_bindings_app_data
-   );
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 6]
-
-Internet-Draft          GSS-API Channel Bindings               July 2004
-
-
-5.  Channel Bindings for TLS
-
-   The TLS channel bindings are constructed as an octet string for the
-   'application-data' field of the channel bindings by concatenating the
-   following values and in this order:
-
-   1.  The ASCII string "GSS TLSv1.0 CB:"
-   2.  The TLS finished message sent by the client
-   3.  The TLS finished message sent by the server
-   4.  Any additional application-provided data, encoded as the DER
-       encoding of an ASN.1 OCTET STRING
-
-5.1  GSS_Make_tls_channel_bindings()
-
-   Inputs:
-
-   o  client_finished_msg OCTET STRING,
-   o  server_finished_msg OCTET STRING,
-   o  additional_app_data OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  channel_bindings_app_data OCTET STRING
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates no error.
-   o  GSS_S_FAILURE indicates failure to construct the channel bindings
-      as a result, perhaps, of a memory management, or similar failure.
-
-   This function constructs an OCTET STRING for use as the value of the
-   application-data field of the GSS-CHANNEL-BINDINGS structure
-   described above.
-
-5.1.1  C-Bindings
-
-   OM_uint32 gss_make_tls_channel_bindings(
-     OM_uint32			*minor_status,
-     const gss_buffer_t		client_finished_msg,
-     const gss_buffer_t		server_finished_msg,
-     const gss_buffer_t		additional_app_data,
-     gss_buffer_t		channel_bindings_app_data
-   );
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 7]
-
-Internet-Draft          GSS-API Channel Bindings               July 2004
-
-
-6.  Channel Bindings for IPsec
-
-   The IPsec channel bindings are constructed as an octet string for the
-   'application-data' field of the channel bindings by concatenating the
-   following values and in this order:
-
-   1.  The ASCII string "GSS IPsec CB:"
-   2.  The transform ID for encryption, as a 16-bit big-endian word
-   3.  The transform ID for integrity protection, as 16-bit in
-       big-endian word
-   4.  The initiator ID payload as used in the key exchange protocol
-       used for setting up the channel's SAs
-   5.  The responder ID payload as used in the key exchange protocol
-       used for setting up the channel's SAs
-   6.  Any additional application-provided data, encoded as the DER
-       encoding of an ASN.1 OCTET STRING
-
-   Note that traffic selectors are not included.  Inclusion of
-   confidentiality/integrity algorithms protects against MITMs that can
-   compromise weaker algorithms that policy might permit, for the same
-   peers, for other traffic.
-
-6.1  GSS_Make_ipsec_channel_bindings()
-
-   Inputs:
-
-   o  encr_alg INTEGER,
-   o  integ_alg INTEGER,
-   o  initiator_id OCTET_STRING,
-   o  acceptor_id OCTET_STRING,
-   o  additional_app_data OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  channel_bindings_app_data OCTET STRING
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates no error.
-   o  GSS_S_FAILURE indicates failure to construct the channel bindings
-      as a result, perhaps, of a memory management, or similar failure.
-
-   This function constructs an OCTET STRING for use as the value of the
-   application-data field of the GSS-CHANNEL-BINDINGS structure
-   described above.
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 8]
-
-Internet-Draft          GSS-API Channel Bindings               July 2004
-
-
-6.1.1  C-Bindings
-
-   OM_uint32 gss_make_ipsec_channel_bindings(
-     OM_uint32			*minor_status,
-     OM_uint32			encr_alg,
-     OM_uint32			integ_alg,
-     const gss_buffer_t		initiator_id,
-     const gss_buffer_t		acceptor_id,
-     const gss_buffer_t		additional_app_data,
-     gss_buffer_t		channel_bindings_app_data
-   );
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 9]
-
-Internet-Draft          GSS-API Channel Bindings               July 2004
-
-
-7.  Security Considerations
-
-   For general security considerations relating to channel bindings see
-   [CHANNEL-BINDINGS]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 10]
-
-Internet-Draft          GSS-API Channel Bindings               July 2004
-
-
-8.  References
-
-8.1  Normative
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
-              1964, June 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-8.2  Informative
-
-   [RFC0854]  Postel, J. and J. Reynolds, "Telnet Protocol
-              Specification", STD 8, RFC 854, May 1983.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
-              (SPKM)", RFC 2025, October 1996.
-
-   [RFC2203]  Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
-              Specification", RFC 2203, September 1997.
-
-   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
-              Negotiation Mechanism", RFC 2478, December 1998.
-
-   [RFC2623]  Eisler, M., "NFS Version 2 and Version 3 Security Issues
-              and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
-              RFC 2623, June 1999.
-
-   [RFC3530]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
-              Beame, C., Eisler, M. and D. Noveck, "Network File System
-              (NFS) version 4 Protocol", RFC 3530, April 2003.
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 11]
-
-Internet-Draft          GSS-API Channel Bindings               July 2004
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 12]
-
-Internet-Draft          GSS-API Channel Bindings               July 2004
-
-
-Appendix A.  Acknowledgments
-
-   The author would like to thank Mike Eisler for his work on the
-   Channel Conjunction Mechanism I-D and for bringing the problem to a
-   head, Sam Hartman for pointing out that channel bindings provide a
-   general solution to the channel binding problem, Jeff Altman for his
-   suggestion of using the TLS finished messages as the TLS channel
-   bindings, Bill Sommerfeld, for his help in developing channel
-   bindings for IPsec, and Radia Perlman for her most helpful comments.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 13]
-
-Internet-Draft          GSS-API Channel Bindings               July 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams               Expires December 30, 2004               [Page 14]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-01.txt b/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-01.txt
deleted file mode 100644
index f148c6502..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-channel-bindings-01.txt
+++ /dev/null
@@ -1,897 +0,0 @@
-
-
-
-KITTEN WG                                                    N. Williams
-Internet-Draft                                                       Sun
-Expires: April 19, 2006                                 October 16, 2005
-
-
-  Clarifications and Extensions to the GSS-API for the Use of Channel
-                                Bindings
-            draft-ietf-kitten-gssapi-channel-bindings-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document clarifies and generalizes the GSS-API "channel
-   bindings" facility.  This document also specifies the format of the
-   various types of channel bindings.
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 1]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-Table of Contents
-
-   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  Generic Structure for GSS-API Channel Bindings . . . . . . . .  5
-     3.1.  Proper Mechanism Use of Channel Bindings . . . . . . . . .  5
-   4.  Channel Bindings for SSHv2 . . . . . . . . . . . . . . . . . .  6
-     4.1.  GSS_Make_sshv2_channel_bindings()  . . . . . . . . . . . .  6
-       4.1.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . .  7
-   5.  Channel Bindings for TLS . . . . . . . . . . . . . . . . . . .  8
-     5.1.  GSS_Make_tls_channel_bindings()  . . . . . . . . . . . . .  8
-       5.1.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . .  9
-   6.  Channel Bindings for IPsec . . . . . . . . . . . . . . . . . . 10
-     6.1.  GSS_Make_ipsec_channel_bindings()  . . . . . . . . . . . . 10
-       6.1.1.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . 11
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     8.1.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . 13
-     8.2.  Informative  . . . . . . . . . . . . . . . . . . . . . . . 13
-   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 14
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
-   Intellectual Property and Copyright Statements . . . . . . . . . . 16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 2]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 3]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-2.  Introduction
-
-   The concept of "channel bindings" and the abstract construction of
-   channel bindings for several types of channels are described in
-   [CHANNEL-BINDINGS]
-
-   To actually use channel bindings in GSS-API aplications additional
-   details are required that are given below.
-
-   First the structure given to channel bindings data in [RFC2744] is
-   generalized to all of the GSS-API, not just its C-Bindings.
-
-   Then the actual construction of channel bindings to SSHv2, TLS and
-   IPsec channels is given.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 4]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-3.  Generic Structure for GSS-API Channel Bindings
-
-   The base GSS-API v2, update 1 specification [RFC2743]describes
-   channel bindings as an OCTET STRING and leaves it to the GSS-API v2,
-   update 1 C-Bindings specification to specify the structure of the
-   contents of the channel bindings OCTET STRINGs.  The C-Bindings
-   specification [RFC2744]then defines, in terms of C, what should be
-   generic structure for channel bindings.  The Kerberos V GSS mechanism
-   [RFC1964]then defines a method for encoding GSS channel bindings in a
-   way that is independent of the C-Bindings!
-
-   In other words, the structure of GSS channel bindings given in
-   [RFC2744] is actually generic, rather than specific to the C
-   programming language.
-
-   Here, then, is a generic re-statement of this structure, in pseudo-
-   ASN.1:
-
-                   GSS-CHANNEL-BINDINGS := SEQUENCE {
-                           initiator-address-type  INTEGER,
-                           initiator-address       OCTET STRING,
-                           acceptor-address-type   INTEGER,
-                           acceptor-address        OCTET STRING,
-                           application-data        OCTET STRING,
-                   }
-
-   The values for the address fields are described in [RFC2744].
-
-   Language-specific bindings of the GSS-API should specify a language-
-   specific formulation of this structure.
-
-3.1.  Proper Mechanism Use of Channel Bindings
-
-   As described in [CHANNEL-BINDINGS], GSS mechanisms should exchange
-   integrity protected proofs of channel bindings, where the proof is
-   obtained by running a strong hash of the channel bindings data
-   (encoded as per some mechanism-specific, such as in [RFC1964]) and a
-   binary value to represent the initiator->acceptor, and opposite,
-   direction.
-
-   The encoding of channel bindings used in [RFC1964], with the addition
-   of a binary value as described above, and the substitution of SHA-1
-   for MD5 is a reasonable, generic encoding of GSS-CHANNEL-BINDINGS
-   that any future GSS mechanisms can use.
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 5]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-4.  Channel Bindings for SSHv2
-
-   The SSHv2 channel bindings are constructed as an octet string for the
-   'application-data' field of the channel bindings by concatenating the
-   following values and in this order:
-
-   1.  The ASCII string "GSS SSHv2 CB:"
-
-   2.  The SSHv2 session ID
-
-   3.  Any additional application-provided data, encoded as the DER
-       encoding of an ASN.1 OCTET STRING
-
-4.1.  GSS_Make_sshv2_channel_bindings()
-
-   Inputs:
-
-
-   o  session_id OCTET STRING,
-
-   o  additional_app_data OCTET STRING
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  channel_bindings_app_data OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_FAILURE indicates failure to construct the channel bindings
-      as a result, perhaps, of a memory management, or similar failure.
-
-   This function constructs an OCTET STRING for use as the value of the
-   application-data field of the GSS-CHANNEL-BINDINGS structure
-   described above.
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 6]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-4.1.1.  C-Bindings
-
-   OM_uint32 gss_make_sshv2_channel_bindings(
-     OM_uint32                     *minor_status,
-     const gss_buffer_t            session_id,
-     const gss_buffer_t            additional_app_data,
-     gss_buffer_t       channel_bindings_app_data
-   );
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 7]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-5.  Channel Bindings for TLS
-
-   The TLS channel bindings are constructed as an octet string for the
-   'application-data' field of the channel bindings by concatenating the
-   following values and in this order:
-
-   1.  The ASCII string "GSS TLSv1.0 CB:"
-
-   2.  The TLS finished message sent by the client
-
-   3.  The TLS finished message sent by the server
-
-   4.  Any additional application-provided data, encoded as the DER
-       encoding of an ASN.1 OCTET STRING
-
-5.1.  GSS_Make_tls_channel_bindings()
-
-   Inputs:
-
-
-   o  client_finished_msg OCTET STRING,
-
-   o  server_finished_msg OCTET STRING,
-
-   o  additional_app_data OCTET STRING
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  channel_bindings_app_data OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_FAILURE indicates failure to construct the channel bindings
-      as a result, perhaps, of a memory management, or similar failure.
-
-   This function constructs an OCTET STRING for use as the value of the
-   application-data field of the GSS-CHANNEL-BINDINGS structure
-   described above.
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 8]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-5.1.1.  C-Bindings
-
-   OM_uint32 gss_make_tls_channel_bindings(
-     OM_uint32                     *minor_status,
-     const gss_buffer_t            client_finished_msg,
-     const gss_buffer_t            server_finished_msg,
-     const gss_buffer_t            additional_app_data,
-     gss_buffer_t          channel_bindings_app_data
-   );
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 9]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-6.  Channel Bindings for IPsec
-
-   The IPsec channel bindings are constructed as an octet string for the
-   'application-data' field of the channel bindings by concatenating the
-   following values and in this order:
-
-
-   1.  The ASCII string "GSS IPsec CB:"
-
-   2.  The transform ID for encryption, as a 16-bit big-endian word
-
-   3.  The transform ID for integrity protection, as 16-bit in big-
-       endian word
-
-   4.  NOTE: The following needs to be updated to take into account
-       progress of BTNS.
-
-   5.  The initiator ID payload as used in the key exchange protocol
-       used for setting up the channel's SAs
-
-   6.  The responder ID payload as used in the key exchange protocol
-       used for setting up the channel's SAs
-
-   7.  Any additional application-provided data, encoded as the DER
-       encoding of an ASN.1 OCTET STRING
-
-   Note that traffic selectors are not included.  Inclusion of
-   confidentiality/integrity algorithms protects against MITMs that can
-   compromise weaker algorithms that policy might permit, for the same
-   peers, for other traffic.
-
-6.1.  GSS_Make_ipsec_channel_bindings()
-
-   Inputs:
-
-
-   o  encr_alg INTEGER,
-
-   o  integ_alg INTEGER,
-
-   o  initiator_id OCTET_STRING,
-
-   o  acceptor_id OCTET_STRING,
-
-   o  additional_app_data OCTET STRING
-
-   Outputs:
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 10]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  channel_bindings_app_data OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_FAILURE indicates failure to construct the channel bindings
-      as a result, perhaps, of a memory management, or similar failure.
-
-   This function constructs an OCTET STRING for use as the value of the
-   application-data field of the GSS-CHANNEL-BINDINGS structure
-   described above.
-
-6.1.1.  C-Bindings
-
-   OM_uint32 gss_make_ipsec_channel_bindings(
-     OM_uint32                     *minor_status,
-     OM_uint32                     encr_alg,
-     OM_uint32                     integ_alg,
-     const gss_buffer_t            initiator_id,
-     const gss_buffer_t            acceptor_id,
-     const gss_buffer_t            additional_app_data,
-     gss_buffer_t          channel_bindings_app_data
-   );
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 11]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-7.  Security Considerations
-
-   For general security considerations relating to channel bindings see
-   [CHANNEL-BINDINGS]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 12]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-8.  References
-
-8.1.  Normative
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-8.2.  Informative
-
-   [RFC0854]  Postel, J. and J. Reynolds, "Telnet Protocol
-              Specification", STD 8, RFC 854, May 1983.
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
-              (SPKM)", RFC 2025, October 1996.
-
-   [RFC2203]  Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
-              Specification", RFC 2203, September 1997.
-
-   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
-              Negotiation Mechanism", RFC 2478, December 1998.
-
-   [RFC2623]  Eisler, M., "NFS Version 2 and Version 3 Security Issues
-              and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
-              RFC 2623, June 1999.
-
-   [RFC3530]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
-              Beame, C., Eisler, M., and D. Noveck, "Network File System
-              (NFS) version 4 Protocol", RFC 3530, April 2003.
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 13]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-Appendix A.  Acknowledgments
-
-   The author would like to thank Mike Eisler for his work on the
-   Channel Conjunction Mechanism I-D and for bringing the problem to a
-   head, Sam Hartman for pointing out that channel bindings provide a
-   general solution to the channel binding problem, Jeff Altman for his
-   suggestion of using the TLS finished messages as the TLS channel
-   bindings, Bill Sommerfeld, for his help in developing channel
-   bindings for IPsec, and Radia Perlman for her most helpful comments.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 14]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 15]
-
-Internet-Draft          GSS-API Channel Bindings            October 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 16]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-domain-based-names-01.txt b/doc/standardisation/draft-ietf-kitten-gssapi-domain-based-names-01.txt
deleted file mode 100644
index 50cd5b9d9..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-domain-based-names-01.txt
+++ /dev/null
@@ -1,617 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: April 19, 2006                                 October 16, 2005
-
-
-            GSS-API Domain-Based Service Names and Name Type
-           draft-ietf-kitten-gssapi-domain-based-names-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes domainname-based service principal names and
-   the corresponding name type for the Generic Security Service
-   Application Programming Interface (GSS-API).
-
-   Domain-based service names are similar to host-based service names,
-   but using a domain name (not necessarily and Internat domain name)
-   instead of or in addition to a hostname.  The primary purpose of
-   domain-based service names is to provide a way to name clustered
-   services after the domain which they service, thereby allowing their
-
-
-
-Williams                 Expires April 19, 2006                 [Page 1]
-
-Internet-Draft           GSS Domain Based Names             October 2005
-
-
-   clients to authorize the service's servers based on authentication of
-   their names.
-
-
-Table of Contents
-
-   1.    Conventions used in this document  . . . . . . . . . . . . .  3
-   2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.    Name Type OID and Symbolic Name  . . . . . . . . . . . . . .  5
-   4.    Query and Display Syntaxes . . . . . . . . . . . . . . . . .  6
-   5.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  7
-   6.    Security Considerations  . . . . . . . . . . . . . . . . . .  8
-   7.    References . . . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.1.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.2.  Informative  . . . . . . . . . . . . . . . . . . . . . . . .  9
-         Author's Address . . . . . . . . . . . . . . . . . . . . . . 10
-         Intellectual Property and Copyright Statements . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 2]
-
-Internet-Draft           GSS Domain Based Names             October 2005
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 3]
-
-Internet-Draft           GSS Domain Based Names             October 2005
-
-
-2.  Introduction
-
-   The use of hostbased principal names for domain-wide services
-   presents the problem of how to distinguish between an instance of a
-   hostbased service that is authorized to respond for a domain and one
-   that isn't.
-
-   Consider LDAP.  LDAP [RFC3377] with SASL [RFC2222] and the Kerberos V
-   mechanism [RFC1964] for the GSS-API [RFC2743] uses a hostbased
-   principal with a service name of "ldap", a reasonable approach,
-   provided there is only one logical LDAP directory in a Kerberos
-   realm's domain, and that all ldap servers in that realm serve that
-   one LDAP directory.  If there were other LDAP directories, then
-   clients could not tell which service is authorized to serve which
-   directory, not without assuming a secure method for finding LDAP
-   servers (e.g., DNSSEC).  This is a significant, and oft-unstated
-   restriction on users of LDAP.
-
-   Domain based names can eliminate this problem by allowing LDAP
-   service names to indicate which LDAP directory they are authorized to
-   serve.
-
-   A domain-based name consists of three required elements:
-
-   o  a service name
-
-   o  a domain name
-
-   o  a hostname
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 4]
-
-Internet-Draft           GSS Domain Based Names             October 2005
-
-
-3.  Name Type OID and Symbolic Name
-
-   The new name type has an OID of
-
-      [NOTE: OID assignment to be made with IANA.]
-
-      {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss-
-      domain-based(5)}
-
-   The recommended symbolic name for this GSS-API name type is
-   "GSS_C_NT_DOMAINBASED_SERVICE".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 5]
-
-Internet-Draft           GSS Domain Based Names             October 2005
-
-
-4.  Query and Display Syntaxes
-
-   There is a single name syntax for domain-based names.
-
-   The syntax is:
-
-      domain-based-name :=
-
-         | <service> '@' <domain> '@' <hostname>
-
-   Note that for Internet domain names the trailing '.' is not and MUST
-   NOT be included in the domain name (or hostname) parts of the display
-   form GSS-API domain-based MNs.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 6]
-
-Internet-Draft           GSS Domain Based Names             October 2005
-
-
-5.  Examples
-
-   o  ldap@example.tld@ds1.example.tld
-
-   o  kadmin@example.tld@kdc1.example.tld
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 7]
-
-Internet-Draft           GSS Domain Based Names             October 2005
-
-
-6.  Security Considerations
-
-   Use of GSS-API domain-based names may not be negotiable by some GSS-
-   API mechanisms, and some acceptors may not support GSS-API domain-
-   based names.  In such cases initiators are left to fallback on the
-   use of hostbased names, in which case the initiators MUST also verify
-   that the acceptor's hostbased name is authorized to provide the given
-   service for the domain that the initiator had wanted.
-
-   The above security consideration also applies to all GSS-API
-   initiators who lack support for domain-based service names.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 8]
-
-Internet-Draft           GSS Domain Based Names             October 2005
-
-
-7.  References
-
-7.1.  Normative
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-7.2.  Informative
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
-              (SASL)", RFC 2222, October 1997.
-
-   [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
-              Protocol (v3): Technical Specification", RFC 3377,
-              September 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 9]
-
-Internet-Draft           GSS Domain Based Names             October 2005
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 10]
-
-Internet-Draft           GSS Domain Based Names             October 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 11]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-00.txt b/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-00.txt
deleted file mode 100644
index 772f36786..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-00.txt
+++ /dev/null
@@ -1,393 +0,0 @@
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: July 2, 2005                                       January 2005
-
-
-     Namespace Considerations and Registries for GSS-API Extensions
-            draft-ietf-kitten-gssapi-extensions-iana-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 2, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).  All Rights Reserved.
-
-Abstract
-
-   This document describes the ways in which the GSS-API may be extended
-   and directs the creation of IANA registries for various GSS-API
-   namespaces.
-
-
-
-
-
-
-
-
-
-
-Williams                  Expires July 2, 2005                  [Page 1]
-
-Internet-Draft           GSS IANA Instructions              January 2005
-
-
-Table of Contents
-
-   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Extensions to the GSS-API  . . . . . . . . . . . . . . . . . .  3
-   4.  Generic GSS-API Namespaces . . . . . . . . . . . . . . . . . .  3
-   5.  Language Binding-Specific GSS-API Namespaces . . . . . . . . .  4
-   6.  Extension-Specific GSS-API Namespaces  . . . . . . . . . . . .  4
-   7.  Registration Form(s) . . . . . . . . . . . . . . . . . . . . .  4
-   8.  Initial Namespace Registrations  . . . . . . . . . . . . . . .  6
-   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
-   10. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
-       Intellectual Property and Copyright Statements . . . . . . . .  7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                  Expires July 2, 2005                  [Page 2]
-
-Internet-Draft           GSS IANA Instructions              January 2005
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  Introduction
-
-   There is a need for generic and mechanism-specific extensions to the
-   Generic Security Services Application Programming Interface
-   (GSS-API).  As such extensions are designed and standardized, both at
-   the IETF and elsewhere, there is a non-trivial risk of namespace
-   pollution and conflicts.  To avoid this we set out guidelines for
-   extending the GSS-API and create IANA registries of GSS-API
-   namespaces.
-
-   The registration of name prefixes and constant value ranges is
-   allowed so as to save the IANA the trouble of registering every
-   GSS-API name and constant, and to allow for reservation of portions
-   of some GSS namespaces for private extensions or extensions which
-   lack IETF Standards-Track extensions.
-
-3.  Extensions to the GSS-API
-
-   Extensions to the GSS-API can be categorized as follows:
-   o  Generic
-   o  Implementation-specific
-   o  Mechanism-specific
-   o  Language binding-specific
-   o  Any combination of two or all three of the last three
-
-   Extensions to the GSS-API may be purely semantic, without effect on
-   the GSS-API's namespaces.  Or they may introduce new functions,
-   constants, types, etc...; these clearly affect the GSS-API
-   namespaces.
-
-   Extensions that affect the GSS-API namespaces should be registered
-   with the IANA.
-
-4.  Generic GSS-API Namespaces
-
-   All the function, constant and type names, as well as all the
-   constant values specified in the base GSS-API specification for the
-   basic generic GSS-API namespace.
-
-   The generic GSS-API namespaces are:
-   o  Type names
-   o  Function names
-
-
-
-Williams                  Expires July 2, 2005                  [Page 3]
-
-Internet-Draft           GSS IANA Instructions              January 2005
-
-
-   o  Constant names for each type
-   o  Constant values for each type
-   o  Mechanism OIDs
-   o  Name Type OIDs
-   o  Mechanism Attribute OIDs (see [EXTENDED-INQUIRY])
-
-5.  Language Binding-Specific GSS-API Namespaces
-
-   <Add text; discuss header, module, library, class, method namespaces
-   and whatever else comes up that is language-specific and appropriate
-   for registration with the IANA.>
-
-6.  Extension-Specific GSS-API Namespaces
-
-   Extensions to the GSS-API may create additional namespaces.
-   Instructions to the IANA should included for the handling of such
-   namespaces.
-
-7.  Registration Form(s)
-
-   Registrations for GSS-API namespaces SHALL take the following form:
-
-   +----------------------+----------------------+---------------------+
-   | Registration Field   | Possible Values      | Description         |
-   +----------------------+----------------------+---------------------+
-   | Registration type    | 'Individual',        | Indicates whether   |
-   |                      | 'Prefix', 'Range'    | this entry reserves |
-   |                      |                      | a given symbol name |
-   |                      |                      | or constant value   |
-   |                      |                      | or whether it       |
-   |                      |                      | reserves an entire  |
-   |                      |                      | sub-namespace (the  |
-   |                      |                      | name is a "prefix") |
-   |                      |                      | or constant value   |
-   |                      |                      | range.              |
-   | Bindings             | 'Generic',           | Indicates the       |
-   |                      | 'C-bindings',        | language bindings   |
-   |                      | 'Java', 'C#', etc... | that this           |
-   |                      |                      | registration is     |
-   |                      |                      | for, or, if         |
-   |                      |                      | 'Generic', that     |
-   |                      |                      | this is an entry    |
-   |                      |                      | for the generic     |
-   |                      |                      | GSS-API, not        |
-   |                      |                      | specific to any     |
-   |                      |                      | programming         |
-   |                      |                      | language.           |
-   | Object Type          | 'Symbol',            | Indicates whether   |
-
-
-
-Williams                  Expires July 2, 2005                  [Page 4]
-
-Internet-Draft           GSS IANA Instructions              January 2005
-
-
-   |                      | 'Constant-Value'     | this registration   |
-   |                      |                      | is for a symbol     |
-   |                      |                      | (e.g., function,    |
-   |                      |                      | constant name(s))   |
-   |                      |                      | or constant value.  |
-   | Object Programming   | 'Data-Type',         | Indicates the type  |
-   | Type                 | 'Function',          | of the object(s)    |
-   |                      | 'Method', 'Integer', | whose symbolic name |
-   |                      | 'String', 'OID'      | or constant value   |
-   |                      |                      | is this entry       |
-   |                      |                      | registers.          |
-   | Object Name          | <Symbol name or name | The name(s) of      |
-   |                      | prefix>              | symbols or values   |
-   |                      |                      | being registered.   |
-   | Object Value         | <Constant value> or  | [Only for           |
-   |                      | <constant value      | Constant-Value      |
-   |                      | range>               | registrations.] The |
-   |                      |                      | value(s)            |
-   |                      |                      | registered.         |
-   | Description          | <Text>               | Description of      |
-   |                      |                      | object(s) being     |
-   |                      |                      | registered.         |
-   | Reference            | <Reference>          | Reference to        |
-   |                      |                      | document that       |
-   |                      |                      | describes the       |
-   |                      |                      | object(s) being     |
-   |                      |                      | registered.         |
-   | Status               | 'Standards-Track',   |                     |
-   |                      | 'Informational',     |                     |
-   |                      | 'Experimental',      |                     |
-   |                      | 'Obsolete'           |                     |
-   +----------------------+----------------------+---------------------+
-
-   The IANA should create a single GSS-API namespace registry, or
-   multiple registries, one for symbolic names and one for constant
-   values, or it may create a registry per-programming language, at its
-   convenience.
-
-   Entries in these registries should consist of all the fields from
-   their corresponding registration entries.
-
-   Entries SHOULD be sorted by object type, proggamming language, symbol
-   name.
-
-   <Add text on guidelines for IANA consideration of registration
-   applications, particularly with respect to entries lacking normative
-   references, "magic" entries (e.g., special values of 'time' types
-   which indicate something other than absolute or relative time, such
-
-
-
-Williams                  Expires July 2, 2005                  [Page 5]
-
-Internet-Draft           GSS IANA Instructions              January 2005
-
-
-   as GSS_C_INDEFINITE), expert review requirements (if any) for
-   registrations lacking normative references, etc....>
-
-8.  Initial Namespace Registrations
-
-   <Add registration entries for namespaces (name prefixes) for RFC2743/
-   RFC2744/RFC2853.>
-
-   <Add registration entries for private namespaces (name prefixes) for
-   implementation- and/or platform-specific extensions.>
-
-9.  Security Considerations
-
-   This document has no security considerations.
-
-10  Normative
-
-   [EXTENDED-INQUIRY]
-              Williams, N., "Extended Generic Security Service Mechanism
-              Inquiry APIs",
-              draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
-              progress).
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-Williams                  Expires July 2, 2005                  [Page 6]
-
-Internet-Draft           GSS IANA Instructions              January 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                  Expires July 2, 2005                  [Page 7]
-
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-01.txt b/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-01.txt
deleted file mode 100644
index 2d1e888c8..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-01.txt
+++ /dev/null
@@ -1,393 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: April 19, 2006                                 October 16, 2005
-
-
-     Namespace Considerations and Registries for GSS-API Extensions
-            draft-ietf-kitten-gssapi-extensions-iana-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes the ways in which the GSS-API may be extended
-   and directs the creation of IANA registries for various GSS-API
-   namespaces.
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 1]
-
-Internet-Draft            GSS IANA Instructions             October 2005
-
-
-Table of Contents
-
-   1.  Conventions used in this document . . . . . . . . . . . . . . . 3
-   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   3.  Extensions to the GSS-API . . . . . . . . . . . . . . . . . . . 3
-   4.  Generic GSS-API Namespaces  . . . . . . . . . . . . . . . . . . 3
-   5.  Language Binding-Specific GSS-API Namespaces  . . . . . . . . . 4
-   6.  Extension-Specific GSS-API Namespaces . . . . . . . . . . . . . 4
-   7.  Registration Form(s)  . . . . . . . . . . . . . . . . . . . . . 4
-   8.  Initial Namespace Registrations . . . . . . . . . . . . . . . . 5
-   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-   10. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
-       Author's Address  . . . . . . . . . . . . . . . . . . . . . . . 6
-       Intellectual Property and Copyright Statements  . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 2]
-
-Internet-Draft            GSS IANA Instructions             October 2005
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-2.  Introduction
-
-   There is a need for generic and mechanism-specific extensions to the
-   Generic Security Services Application Programming Interface (GSS-
-   API).  As such extensions are designed and standardized, both at the
-   IETF and elsewhere, there is a non-trivial risk of namespace
-   pollution and conflicts.  To avoid this we set out guidelines for
-   extending the GSS-API and create IANA registries of GSS-API
-   namespaces.
-
-   The registration of name prefixes and constant value ranges is
-   allowed so as to save the IANA the trouble of registering every GSS-
-   API name and constant, and to allow for reservation of portions of
-   some GSS namespaces for private extensions or extensions which lack
-   IETF Standards-Track extensions.
-
-
-3.  Extensions to the GSS-API
-
-   Extensions to the GSS-API can be categorized as follows:
-   o  Generic
-   o  Implementation-specific
-   o  Mechanism-specific
-   o  Language binding-specific
-   o  Any combination of two or all three of the last three
-
-   Extensions to the GSS-API may be purely semantic, without effect on
-   the GSS-API's namespaces.  Or they may introduce new functions,
-   constants, types, etc...; these clearly affect the GSS-API
-   namespaces.
-
-   Extensions that affect the GSS-API namespaces should be registered
-   with the IANA.
-
-
-4.  Generic GSS-API Namespaces
-
-   All the function, constant and type names, as well as all the
-   constant values specified in the base GSS-API specification for the
-   basic generic GSS-API namespace.
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 3]
-
-Internet-Draft            GSS IANA Instructions             October 2005
-
-
-   The generic GSS-API namespaces are:
-   o  Type names
-   o  Function names
-   o  Constant names for each type
-   o  Constant values for each type
-   o  Mechanism OIDs
-   o  Name Type OIDs
-   o  Mechanism Attribute OIDs (see [EXTENDED-INQUIRY])
-
-
-5.  Language Binding-Specific GSS-API Namespaces
-
-   <Add text; discuss header, module, library, class, method namespaces
-   and whatever else comes up that is language-specific and appropriate
-   for registration with the IANA.>
-
-
-6.  Extension-Specific GSS-API Namespaces
-
-   Extensions to the GSS-API may create additional namespaces.
-   Instructions to the IANA should included for the handling of such
-   namespaces.
-
-
-7.  Registration Form(s)
-
-   Registrations for GSS-API namespaces SHALL take the following form:
-
-   <TBD>
-
-   The IANA should create a single GSS-API namespace registry, or
-   multiple registries, one for symbolic names and one for constant
-   values, or it may create a registry per-programming language, at its
-   convenience.
-
-   Entries in these registries should consist of all the fields from
-   their corresponding registration entries.
-
-   Entries SHOULD be sorted by object type, proggamming language, symbol
-   name.
-
-   <Add text on guidelines for IANA consideration of registration
-   applications, particularly with respect to entries lacking normative
-   references, "magic" entries (e.g., special values of 'time' types
-   which indicate something other than absolute or relative time, such
-   as GSS_C_INDEFINITE), expert review requirements (if any) for
-   registrations lacking normative references, etc....>
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 4]
-
-Internet-Draft            GSS IANA Instructions             October 2005
-
-
-8.  Initial Namespace Registrations
-
-   <Add registration entries for namespaces (name prefixes) for RFC2743/
-   RFC2744/RFC2853.>
-
-   <Add registration entries for private namespaces (name prefixes) for
-   implementation- and/or platform-specific extensions.>
-
-
-9.  Security Considerations
-
-   This document has no security considerations.
-
-10.  Normative
-
-   [EXTENDED-INQUIRY]
-              Williams, N., "Extended Generic Security Service Mechanism
-              Inquiry APIs",
-              draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
-              progress).
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 5]
-
-Internet-Draft            GSS IANA Instructions             October 2005
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 6]
-
-Internet-Draft            GSS IANA Instructions             October 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 7]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-naming-exts-00.txt b/doc/standardisation/draft-ietf-kitten-gssapi-naming-exts-00.txt
deleted file mode 100644
index c6325ee78..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-naming-exts-00.txt
+++ /dev/null
@@ -1,1117 +0,0 @@
-Internet-Draft                                                       Sun
-Expires: November 14, 2005                                  May 13, 2005
-
-
-                       GSS-API Naming Extensions
-              draft-ietf-kitten-gssapi-naming-exts-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on November 14, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   The Generic Security Services API (GSS-API) provides a simple naming
-   architecture that supports name-based authorization.  This document
-   introduces new APIs that extend the GSS-API naming and authorization
-   model.
-
-
-
-
-
-
-
-
-Williams                Expires November 14, 2005               [Page 1]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-Table of Contents
-
-   1.    Conventions used in this document  . . . . . . . . . . . . .  3
-   2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.    Name Attribute Sources and Criticality . . . . . . . . . . .  3
-   4.    Name Attributes/Values as ACL Subjects . . . . . . . . . . .  4
-   5.    Mapping Mechanism Facilities to Name Attributes  . . . . . .  4
-   5.1   Kerberos V and SPKM Authorization-Data . . . . . . . . . . .  4
-   5.2   Kerberos V Cross-Realm Transit Paths . . . . . . . . . . . .  5
-   5.3   PKIX Certificate Extensions  . . . . . . . . . . . . . . . .  5
-   5.3.1 PKIX EKUs  . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   5.3.2 PKIX Certificate Alternative Names . . . . . . . . . . . . .  6
-   5.3.3 Other PKIX Certificate Extensions and Attributes . . . . . .  6
-   5.4   PKIX Certificate CA Paths and Trust Anchors  . . . . . . . .  6
-   6.    GSS_Inquire_name_attribute() . . . . . . . . . . . . . . . .  6
-   6.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . .  7
-   6.2   Java Bindings  . . . . . . . . . . . . . . . . . . . . . . .  7
-   7.    GSS_Display_name_ext() . . . . . . . . . . . . . . . . . . .  7
-   7.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   7.2   Java Bindings  . . . . . . . . . . . . . . . . . . . . . . .  8
-   8.    GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . . .  8
-   8.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . .  9
-   8.2   Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . 10
-   9.    GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . . 10
-   9.1   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   9.2   Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . 11
-   10.   GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . . 12
-   10.1  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 12
-   10.2  Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . 12
-   11.   GSS_Delete_name_attribute()  . . . . . . . . . . . . . . . . 13
-   11.1  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 13
-   11.2  Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . 13
-   12.   GSS_Export_name_composite()  . . . . . . . . . . . . . . . . 14
-   12.1  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 14
-   12.2  Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . 14
-   13.   GSS_Map_name_to_any()  . . . . . . . . . . . . . . . . . . . 15
-   13.1  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 15
-   13.2  Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . 16
-   14.   GSS_Release_any_name_mapping() . . . . . . . . . . . . . . . 16
-   14.1  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 16
-   14.2  Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . 17
-   15.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 17
-   16.   Security Considerations  . . . . . . . . . . . . . . . . . . 17
-   17.   References . . . . . . . . . . . . . . . . . . . . . . . . . 18
-   17.1  Normative References . . . . . . . . . . . . . . . . . . . . 18
-   17.2  Informative References . . . . . . . . . . . . . . . . . . . 18
-         Author's Address . . . . . . . . . . . . . . . . . . . . . . 18
-         Intellectual Property and Copyright Statements . . . . . . . 20
-
-
-
-Williams                Expires November 14, 2005               [Page 2]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  Introduction
-
-   As described in [I-D.GSS-NAMING] the GSS-API's naming architecture
-   suffers from certain limitations.  This document proposes concrete
-   GSS-API extensions as outlined in [I-D.GSS-NAMING].
-
-   A number of extensions to the GSS-API are described herein with the
-   goal of making authorization information, and other information that
-   can be modelled as "name attributes" available as such to
-   applications.  For example, Kerberos V authorization data elements,
-   both, in their raw forms as well as mapped to more useful value
-   types, can be made available to GSS-API applications through these
-   interfaces.
-
-   The model is that GSS names have attributes.  The attributes of a
-   name may be authenticated by the credential whence the name comes, or
-   may have been set locally on a GSS name for the purpose of
-   "asserting" the attribute during credential acquisition or security
-   context exchange.  Name attributes' values are network
-   representations thereof (e.g., the actual value octets of the
-   contents of an X.509 certificate extension, for example) and are
-   intended to be useful for constructing portable access control
-   facilities.  Applications may often require language- or platform-
-   specific data types, rather than network representations of name
-   attributes, so a function is provided to obtain objects of such types
-   associated with names and name attributes.
-
-3.  Name Attribute Sources and Criticality
-
-   A given GSS name object's name attributes may be authenticated or
-   asserted by an associated credential, or it may be mapped or derived
-   from another attribute of the same name.
-
-   That a given name's given attribute is 'mapped' means that it was
-   obtained through some mapping mechanism applied to another attribute
-   of the name that was not, itself, mapped.  For example, such
-   attributes as platform-specific internal identifiers may sometimes be
-   mapped from other name attributes.
-
-   Name attributes may be "critical," meaning that applications that do
-   not understand them MUST reject security contexts where the peer has
-   such unknown, critical attributes.
-
-
-
-Williams                Expires November 14, 2005               [Page 3]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-4.  Name Attributes/Values as ACL Subjects
-
-   Some name attributes (e.g., numeric user or group identifiers) may be
-   useful as subjects of access control list (ACL) entries, some may not
-   (e.g., time of day login restrictions).  The
-   GSS_Inquire_name_attribute() function indicates this.
-
-   To facilitate the development of portable applications that make use
-   of name attributes to construct and evaluate portable ACLs the GSS-
-   API makes name attribute values available in canonical network
-   encodings thereof.
-
-   To facilitate the development of platform- or language-specific
-   applications that need access to native types of representations of
-   name attributes an optional facility is provided,
-   GSS_Map_name_to_any().
-
-5.  Mapping Mechanism Facilities to Name Attributes
-
-   [NOTE:  This entire section should probably be split into one or more
-   separate Internet-Drafts.  It is here in the -00 of this I-D to help
-   readers understand how to mechanism-specific name attributes would be
-   accessed through these GSS-API extensions.]
-
-   Kerberos V [I-D.ietf-krb-wg-kerberos-clarifications] and the Simple
-   Public-Key GSS-API Mechanism, SPKM [RFC2025], both support the
-   concept and encoding of containers of "authorization-data" as
-   described in [I-D.ietf-krb-wg-kerberos-clarifications].
-
-   PKIX [RFC3280] supports a number of authorization-data-like features,
-   like Extended Key Usage values (EKUs) and certificate extensions.
-
-   The authorization data can be accessed through the GSS-API name
-   attributes facility defined herein.
-
-5.1  Kerberos V and SPKM Authorization-Data
-
-   Authorization-data non-container elements asserted in Kerberos V AP-
-   REQ Authenticators MUST be mapped into *asserted* GSS-API name
-   attributes; if not contained in AD-IF-RELEVANT then they MUST be
-   mapped into *critical* GSS-API name attributes.  AD-AND-OR
-   authorization-data elements MUST be mapped into a single *critical*
-   attribute, (TBD).
-
-   Authorization-data included in Kerberos V Tickets that is not
-   contained in AD-KDCIssued (with valid signature) MUST be mapped into
-   *asserted* GSS-API name attributes.  Conversely, authorization-data
-   elements in Kerberos V Tickets contained by AD-KDCIssued MUST be
-
-
-
-Williams                Expires November 14, 2005               [Page 4]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-   mapped into *authenticated* GSS-API name attributes
-
-   As with authorization-data elements in Authenticators, authorization-
-   data elements in Tickets not contained in AD-IF-RELEVANT are to be
-   mapped to *critical* name attributes, and similarly with AD-AND-OR
-   (see above).
-
-   The OIDs for authorization-data elements are to be the authorization-
-   data element's 'ad-type' integer ID, relative to the base OID <TBD>
-   [NOTE: what about negative ad-type's?  OID arcs are positive
-   integers... ad-type is an Int32, so clearly something can be done.]
-
-5.2  Kerberos V Cross-Realm Transit Paths
-
-   [Add text on how to represent/encode/interpret krb5 realm transit
-   paths as name attribute values.  And text on PKINIT too...  Basically
-   Ticket's 'transited' field should be exposed as an authenticated name
-   attribute, with some uncompressed encoding, possibly encompassing
-   certificate validation paths of client certs used for PKINIT, with
-   criticality determined by the presence of the transit-policy-checked
-   flag.]
-
-5.3  PKIX Certificate Extensions
-
-   [NOTE:  In the Kerberos V authorization-data case we can tell when AD
-   elements are "authenticated" and when the are asserted, but what
-   about x.509 certificate extensions?  Clearly KU, EKUs and
-   subjectAltNames are authenticated in that no CA should sign a cert
-   with, say, arbitrary subjectAltNames not understood by the CA, but,
-   does that also apply to all other x.509 certificate extensions?  The
-   answer may depend on actual CA operator practices...  At worst a new
-   extension may be needed, like Kerberos V's AD-KDCIssued AD container
-   element; at best this text can just say "all cert extensions MUST be
-   mapped to authenticated..." below.]
-
-   PKI certificate extensions MAY/SHOULD/MUST (see comment above) be
-   mapped to *authenticated* GSS-API name attributes with the _same_
-   OIDs, and if they be marked critical in the certificate then they
-   MUST be mapped as *critical* GSS-API name attributes.
-   SubjectAltNames and EKUs, specifically, MUST be mapped to
-   *authenticated* GSS-API name attributes; see below.  Certificate
-   extensions MUST be mapped to GSS-API name attributes whose OIDs are
-   the same as the extensions'
-
-5.3.1  PKIX EKUs
-
-   Extended Key Usage extensions, specifically, MUST be mapped as
-   described above, except that GSS-API name attributes for EKUs MUST
-
-
-
-Williams                Expires November 14, 2005               [Page 5]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-   have NULL values (i.e., zero-length OCTET STRINGs).
-
-   PKI certificate key usages (KUs, but not EKUs), MUST NOT be mapped to
-   GSS-API name attributes.
-
-5.3.2  PKIX Certificate Alternative Names
-
-   PKI certificate subjectAltNames MUST be mapped as *authenticated*,
-   *non-critical* GSS-API name attributes.
-
-   PKI certificate extensions MUST be mapped to *authenticated* GSS-API
-   name attributes with the _same_ OIDs, and if they be marked critical
-   in the certificate then they MUST be mapped as *critical* GSS-API
-   name attributes.
-
-   Extended Key Usage extensions, specifically, MUST be mapped as
-   described above, except that GSS-API name attributes for EKUs MUST
-   have NULL values (i.e., zero-length OCTET STRINGs).
-
-5.3.3  Other PKIX Certificate Extensions and Attributes
-
-   [Add text...]
-
-5.4  PKIX Certificate CA Paths and Trust Anchors
-
-   [Add text on how to represent/encode/interpret PKI certificate
-   validation CA paths as name attribute values, much as with Kerberos V
-   transited paths.]
-
-6.  GSS_Inquire_name_attribute()
-
-   Inputs:
-
-
-   o  attr OBJECT IDENTIFIER
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  attr_name OCTET STRING,
-
-   o  attr_description OCTET STRING,
-
-   o  attr_is_a_name BOOLEAN,
-
-
-
-Williams                Expires November 14, 2005               [Page 6]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-   o  attr_is_trust_indicator BOOLEAN
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
-      known (even if present as a name's attribute).
-
-   o  GSS_S_FAILURE indicates a general error.
-
-   This function outputs a name for the given name attribute,
-   description for display to users, indicates whether the given name
-   attribute's values are useful as the subject of an access control
-   list entry and/or whether the given name attribute's values are
-   useful as indicators of trust (for example, whether they name PKIX
-   trust anchors).
-
-6.1  C-Bindings
-
-   OM_uint32 gss_inquire_name_attribute(
-     OM_uint32                     *minor_status,
-     gss_OID                       attr,
-     gss_buffer_t                  attr_name,
-     gss_buffer_t                  attr_description,
-     int                           *attr_is_a_name,
-     int                           *attr_is_trust_indicator
-   );
-
-
-6.2  Java Bindings
-
-   public String nameAttributeName(Oid attr)
-      throws GSSException
-   public String nameAttributeDescription(Oid attr)
-      throws GSSException
-   public boolean nameAttributeIsName(Oid attr)
-      throws GSSException
-   public boolean nameAttributeIsTrustIndicator(Oid attr)
-      throws GSSException
-
-
-7.  GSS_Display_name_ext()
-
-   Inputs:
-
-
-   o  name NAME,
-
-
-
-Williams                Expires November 14, 2005               [Page 7]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-   o  display_as_name_type OBJECT IDENTIFIER
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  display_name STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_UNAVAILABLE indicates that the given name could not be
-      displayed using the syntax of the given name type.
-
-   o  GSS_S_FAILURE indicates a general error.
-
-   This function displays a given name using the given name syntax, if
-   possible.  This operation may require mapping MNs to generic name
-   syntaxes or generic name syntaxes to mechanism-specific name
-   syntaxes; such mappings may not always be feasible and MAY be inexact
-   or lossy.
-
-7.1  C-Bindings
-
-   OM_uint32 GSS_Display_name_ext(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     gss_OID                       display_as_name_type,
-     gss_buffer_t                  display_name
-   );
-
-
-7.2  Java Bindings
-
-   public String displayExtended(Oid display_as_name_type)
-      throws GSSException
-
-
-8.  GSS_Inquire_name()
-
-   Inputs:
-
-
-   o  name NAME
-
-
-
-Williams                Expires November 14, 2005               [Page 8]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  name_is_MN BOOLEAN,
-
-   o  mn_mech OBJECT IDENTIFIER
-
-   o  asserted_attrs SET OF OBJECT IDENTIFIER
-
-   o  authenticated_attrs SET OF OBJECT IDENTIFIER
-
-   o  critical_attrs SET OF OBJECT IDENTIFIER
-
-   o  all_attrs SET OF OBJECT IDENTIFIER
-
-   o  [NOTE: Perhaps this function should also output an indicator as to
-      the provenance of the name, of which, in the GSS-API, there are
-      three: imported, inquired from a credential, and a peer's name
-      inquired from a security context.]
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_FAILURE indicates a general error.
-
-   This function outputs the sets of attributes of a name, that are
-   authenticated, asserted or critical.  It also indicates if a given
-   NAME is an MN or not and, if it is, what mechanism it's an MN of.
-
-8.1  C-Bindings
-
-   OM_uint32 gss_inquire_name(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     int                           name_is_MN,
-     gss_OID                       *MN_mech,
-     gss_OID_set                   *authenticated,
-     gss_OID_set                   *asserted,
-     gss_OID_set                   *critical,
-     gss_OID_set                   *all_attrs
-   );
-
-
-
-
-
-Williams                Expires November 14, 2005               [Page 9]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-8.2  Java Bindings
-
-   public boolean isMN(boolean authenticated, boolean critical)
-      throws GSSException
-   public Oid mnMech(boolean authenticated, boolean critical)
-      throws GSSException
-   public Oid[] allAttributes(boolean authenticated, boolean critical)
-      throws GSSException
-   public Oid[] authenticatedAttributes(boolean authenticated,
-      boolean critical) throws GSSException
-   public Oid[] assertedAttributes(boolean authenticated,
-      boolean critical) throws GSSException
-   public Oid[] criticalAttributes(boolean authenticated,
-      boolean critical) throws GSSException
-
-
-9.  GSS_Get_name_attribute()
-
-   Inputs:
-
-
-   o  name NAME,
-
-   o  attr OBJECT IDENTIFIER
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  authenticated BOOLEAN,
-
-   o  mapped BOOLEAN,
-
-   o  critical BOOLEAN,
-
-   o  values SET OF OCTET STRING,
-
-   o  display_values SET OF STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
-      known or set.
-
-
-
-Williams                Expires November 14, 2005              [Page 10]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-   o  GSS_S_FAILURE indicates a general error.
-
-   This function outputs the value(s) associated with a given GSS name
-   object for a given name attribute.
-
-9.1  C-Bindings
-
-   The C-bindings of GSS_Get_name_attribute() requires one function call
-   per-attribute value, for multi-valued name attributes.  This is done
-   by using a single gss_buffer_t for each value and an input/output
-   integer parameter to distinguish initial and subsequent calls and to
-   indicate when all values have been obtained.
-
-   The 'more' input/output parameter should point to an integer variable
-   whose value, on first call to gss_name_attribute_get() MUST be -1,
-   and whose value upon function call return will be non-zero to
-   indicate that additional values remain, or zero to indicate that no
-   values remain.  The caller should not modify this parameter after the
-   initial call.
-
-   OM_uint32 gss_get_name_attribute(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     gss_OID                       attr,
-     int                           *authenticated,
-     int                           *mapped,
-     int                           *critical,
-     gss_buffer_t                  value,
-     gss_buffer_t                  display_value,
-     int                           *more
-   );
-
-
-9.2  Java Bindings
-
-   public byte[] getAttributeValue(Oid attr)
-      throws GSSException
-   public String getAttributeDisplayValue(Oid attr)
-      throws GSSException
-   public boolean isAttributeAuthenticated(Oid attr)
-      throws GSSException
-   public boolean isAttributeMapped(Oid attr)
-      throws GSSException
-   public boolean getAttributeCriticality(Oid attr)
-      throws GSSException
-
-
-10.  GSS_Set_name_attribute()
-
-
-
-Williams                Expires November 14, 2005              [Page 11]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-   Inputs:
-
-
-   o  name NAME,
-
-   o  critical BOOLEAN,
-
-   o  attr OBJECT IDENTIFIER,
-
-   o  values SET OF OCTET STRING
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
-      known or could not be set.
-
-   o  GSS_S_FAILURE indicates a general error.
-
-
-10.1  C-Bindings
-
-   The C-bindings of GSS_Set_name_attribute() requires one function call
-   per-attribute value, for multi-valued name attributes -- each call
-   adds one value.  To replace an attribute's every value delete the
-   attribute's values first with GSS_Delete_name_attribute().
-
-   OM_uint32 gss_set_name_attribute(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     int                           critical,
-     gss_OID                       attr,
-     gss_buffer_t                  value
-   );
-
-
-10.2  Java Bindings
-
-   The Java-bindings of GSS_Set_name_attribute() requires one function
-   call per-attribute value, for multi-valued name attributes -- each
-
-
-
-Williams                Expires November 14, 2005              [Page 12]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-   call adds one value.  To replace an attribute's every value delete
-   the attribute's values first with GSS_Delete_name_attribute().
-
-   public abstract setAttribute(Oid attr, boolean critical,
-                                byte[] value)
-      throws GSSException
-
-
-11.  GSS_Delete_name_attribute()
-
-   Inputs:
-
-
-   o  name NAME,
-
-   o  attr OBJECT IDENTIFIER,
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
-      known.
-
-   o  GSS_S_FAILURE indicates a general error.
-
-
-11.1  C-Bindings
-
-   OM_uint32 gss_delete_name_attribute(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     gss_OID                       attr
-   );
-
-
-11.2  Java Bindings
-
-   public abstract deleteAttribute(Oid attr, boolean critical)
-      throws GSSException
-
-
-
-
-Williams                Expires November 14, 2005              [Page 13]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-12.  GSS_Export_name_composite()
-
-   Inputs:
-
-
-   o  name NAME
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  exp_composite_name OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_FAILURE indicates a general error.
-
-   This function outputs a token which can be imported with
-   GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type
-   and which preserves any name attribute information associated with
-   the input name (which GSS_Export_name() may well not).  The token
-   format is no specified here as this facility is intended for inter-
-   process communication only; however, all such tokens MUST start with
-   a two-octet token ID, hex 04 02, in network byte order.
-
-   The OID for GSS_C_NT_COMPOSITE_EXPORT is <TBD>.
-
-12.1  C-Bindings
-
-   OM_uint32 gss_export_name_composite(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     gss_buffer_t                  exp_composite_name
-   );
-
-
-12.2  Java Bindings
-
-   public byte[] exportComposite()
-      throws GSSException
-
-
-13.  GSS_Map_name_to_any()
-
-
-
-Williams                Expires November 14, 2005              [Page 14]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-   Inputs:
-
-
-   o  name NAME,
-
-   o  authenticated BOOLEAN, -- if TRUE no data will be output unless it
-      is authenticated
-
-   o  type_id OBJECT IDENTIFIER
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output ANY DEFINED BY type_id
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_UNAVAILABLE indicates that the mapping or conversion could
-      not be done.  The minor status code may provide additional
-      information.
-
-   o  GSS_S_FAILURE indicates a general error.  The minor status code
-      may provide additional information.
-
-   Whereas name attribute's values are encoded in some network
-   representation applications often require native, language- and/or
-   platform-specific data types.  This function provides access to such
-   types.
-
-13.1  C-Bindings
-
-   struct gss_any;
-   typedef struct gss_any *gss_any_t;
-   OM_uint32 gss_map_name_to_any(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     int                           authenticated,
-     gss_OID                       type_id,
-     gss_any_t                     output
-   );
-
-
-
-
-
-Williams                Expires November 14, 2005              [Page 15]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-13.2  Java Bindings
-
-   ...
-
-
-14.  GSS_Release_any_name_mapping()
-
-   Inputs:
-
-
-   o  name NAME,
-
-   o  type_id OBJECT IDENTIFIER,
-
-   o  input ANY DEFINED BY type_id
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_UNAVAILABLE indicates that the mapping or conversion could
-      not be done.  The minor status code may provide additional
-      information.
-
-   o  GSS_S_FAILURE indicates a general error.  The minor status code
-      may provide additional information.
-
-   This function releases, if possible, the objects of language- and/or
-   platform-specific types output by GSS_Map_name_to_any().  If such
-   types have native release functions applications MAY use either those
-   or this function to release the given object.
-
-14.1  C-Bindings
-
-   struct gss_any;
-   typedef struct gss_any *gss_any_t;
-   OM_uint32 gss_release_any_name_mapping(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     gss_OID                       type_id,
-     gss_any_t                     *input
-
-
-
-Williams                Expires November 14, 2005              [Page 16]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-   );
-
-
-14.2  Java Bindings
-
-   ...
-
-
-15.  IANA Considerations
-
-   This document creates a namespace of GSS-API name attributes.
-   Attributes are named by OID, so no single authority might be needed
-   for allocation, however, in the interest of providing the community
-   with an authority for name attribute OID allocation and a way to find
-   the existing set of name attributes, the IANA should establish both,
-   a single OID off of which name attributes could be allocated, and a
-   registry of known GSS name attributes.
-
-   GSS-API name attribute registry entries should contain all the
-   information that GSS_Inquire_name_attribute() may return about the
-   given name attributes and their OIDs:
-
-   o  a name attribute OID (this is a unique key)
-
-   o  a name attribute symbolic name, starting with "GSS_C_NA_" (this is
-      a unique key)
-
-   o  a brief description, in English
-
-   o  whether the attribute is useful as the subject of access control
-      list entries
-
-   o  whether the attribute is useful as an indicator of trust
-
-   o  an optional normative reference to documentation for the given
-      name attribute
-
-   The allocation and registration policy should be first come, first
-   served.  Registry entries' OIDs need not be based on the base OID
-   given above.
-
-16.  Security Considerations
-
-   <TBA>
-
-   [In particular, the status of a name attribute as "authenticated" vs.
-   "asserted" requires close review, particularly with respect to PKIX
-   certificate extensions.]
-
-
-
-Williams                Expires November 14, 2005              [Page 17]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-17.  References
-
-17.1  Normative References
-
-   [I-D.GSS-NAMING]
-              Hartman, S., "Desired Enhancements to GSSAPI Naming",
-              draft-ietf-kitten-gss-naming-01.txt (work in progress),
-              February 2005.
-
-   [I-D.ietf-krb-wg-kerberos-clarifications]
-              Neuman, C., "The Kerberos Network Authentication Service
-              (V5)", draft-ietf-krb-wg-kerberos-clarifications-07 (work
-              in progress), September 2004.
-
-   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
-              (SPKM)", RFC 2025, October 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-17.2  Informative References
-
-   [RFC1750]  Eastlake, D., Crocker, S., and J. Schiller, "Randomness
-              Recommendations for Security", RFC 1750, December 1994.
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-
-
-
-Williams                Expires November 14, 2005              [Page 18]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires November 14, 2005              [Page 19]
-
-Internet-Draft          GSS-API Naming Extensions               May 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                Expires November 14, 2005              [Page 20]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-naming-exts-01.txt b/doc/standardisation/draft-ietf-kitten-gssapi-naming-exts-01.txt
deleted file mode 100644
index 205807000..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-naming-exts-01.txt
+++ /dev/null
@@ -1,1065 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: April 17, 2006                                 October 14, 2005
-
-
-                       GSS-API Naming Extensions
-              draft-ietf-kitten-gssapi-naming-exts-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 17, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   The Generic Security Services API (GSS-API) provides a simple naming
-   architecture that supports name-based authorization.  This document
-   introduces new APIs that extend the GSS-API naming and authorization
-   model.
-
-
-
-
-
-
-
-
-Williams                 Expires April 17, 2006                 [Page 1]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-Table of Contents
-
-   1.      Conventions used in this document  . . . . . . . . . . . .  3
-   2.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.      Name Attribute Sources and Criticality . . . . . . . . . .  3
-   4.      Name Attributes/Values as ACL Subjects . . . . . . . . . .  4
-   5.      Mapping Mechanism Facilities to Name Attributes  . . . . .  4
-   5.1.    Kerberos V and SPKM Authorization-Data . . . . . . . . . .  4
-   5.2.    Kerberos V Cross-Realm Transit Paths . . . . . . . . . . .  5
-   5.3.    PKIX Certificate Extensions  . . . . . . . . . . . . . . .  5
-   5.3.1.  PKIX EKUs  . . . . . . . . . . . . . . . . . . . . . . . .  6
-   5.3.2.  PKIX Certificate Alternative Names . . . . . . . . . . . .  6
-   5.3.3.  Other PKIX Certificate Extensions and Attributes . . . . .  6
-   5.4.    PKIX Certificate CA Paths and Trust Anchors  . . . . . . .  6
-   6.      GSS_Inquire_name_attribute() . . . . . . . . . . . . . . .  6
-   6.1.    C-Bindings . . . . . . . . . . . . . . . . . . . . . . . .  7
-   7.      GSS_Display_name_ext() . . . . . . . . . . . . . . . . . .  8
-   7.1.    C-Bindings . . . . . . . . . . . . . . . . . . . . . . . .  8
-   8.      GSS_Inquire_name() . . . . . . . . . . . . . . . . . . . .  9
-   8.1.    C-Bindings . . . . . . . . . . . . . . . . . . . . . . . .  9
-   9.      GSS_Get_name_attribute() . . . . . . . . . . . . . . . . . 10
-   9.1.    C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 11
-   10.     GSS_Set_name_attribute() . . . . . . . . . . . . . . . . . 11
-   10.1.   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12
-   11.     GSS_Delete_name_attribute()  . . . . . . . . . . . . . . . 12
-   11.1.   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 13
-   12.     GSS_Export_name_composite()  . . . . . . . . . . . . . . . 13
-   12.1.   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 14
-   13.     GSS_Map_name_to_any()  . . . . . . . . . . . . . . . . . . 14
-   13.1.   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 15
-   14.     GSS_Release_any_name_mapping() . . . . . . . . . . . . . . 15
-   14.1.   C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 16
-   15.     IANA Considerations  . . . . . . . . . . . . . . . . . . . 16
-   16.     Security Considerations  . . . . . . . . . . . . . . . . . 17
-   17.     Normative References . . . . . . . . . . . . . . . . . . . 17
-           Author's Address . . . . . . . . . . . . . . . . . . . . . 18
-           Intellectual Property and Copyright Statements . . . . . . 19
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 17, 2006                 [Page 2]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-2.  Introduction
-
-   As described in [I-D.GSS-NAMING] the GSS-API's naming architecture
-   suffers from certain limitations.  This document proposes concrete
-   GSS-API extensions as outlined in [I-D.GSS-NAMING].
-
-   A number of extensions to the GSS-API [RFC2743] and its C Bindings
-   [RFC2744] are described herein with the goal of making authorization
-   information, and other information that can be modelled as "name
-   attributes" available as such to applications.  For example, Kerberos
-   V authorization data elements, both, in their raw forms as well as
-   mapped to more useful value types, can be made available to GSS-API
-   applications through these interfaces.
-
-   The model is that GSS names have attributes.  The attributes of a
-   name may be authenticated by the credential whence the name comes, or
-   may have been set locally on a GSS name for the purpose of
-   "asserting" the attribute during credential acquisition or security
-   context exchange.  Name attributes' values are network
-   representations thereof (e.g., the actual value octets of the
-   contents of an X.509 certificate extension, for example) and are
-   intended to be useful for constructing portable access control
-   facilities.  Applications may often require language- or platform-
-   specific data types, rather than network representations of name
-   attributes, so a function is provided to obtain objects of such types
-   associated with names and name attributes.
-
-
-3.  Name Attribute Sources and Criticality
-
-   A given GSS name object's name attributes may be authenticated or
-   asserted by an associated credential, or it may be mapped or derived
-   from another attribute of the same name.
-
-   That a given name's given attribute is 'mapped' means that it was
-   obtained through some mapping mechanism applied to another attribute
-   of the name that was not, itself, mapped.  For example, such
-   attributes as platform-specific internal identifiers may sometimes be
-   mapped from other name attributes.
-
-   Name attributes may be "critical," meaning that applications that do
-
-
-
-Williams                 Expires April 17, 2006                 [Page 3]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-   not understand them MUST reject security contexts where the peer has
-   such unknown, critical attributes.
-
-
-4.  Name Attributes/Values as ACL Subjects
-
-   Some name attributes (e.g., numeric user or group identifiers) may be
-   useful as subjects of access control list (ACL) entries, some may not
-   (e.g., time of day login restrictions).  The
-   GSS_Inquire_name_attribute() function indicates this.
-
-   To facilitate the development of portable applications that make use
-   of name attributes to construct and evaluate portable ACLs the GSS-
-   API makes name attribute values available in canonical network
-   encodings thereof.
-
-   To facilitate the development of platform- or language-specific
-   applications that need access to native types of representations of
-   name attributes an optional facility is provided,
-   GSS_Map_name_to_any().
-
-
-5.  Mapping Mechanism Facilities to Name Attributes
-
-   [NOTE: This entire section should probably be split into one or more
-   separate Internet-Drafts.  It is here in the -00 of this I-D to help
-   readers understand how to mechanism-specific name attributes would be
-   accessed through these GSS-API extensions.]
-
-   Kerberos V [I-D.ietf-krb-wg-kerberos-clarifications] and the Simple
-   Public-Key GSS-API Mechanism, SPKM [RFC2025], both support the
-   concept and encoding of containers of "authorization-data" as
-   described in [I-D.ietf-krb-wg-kerberos-clarifications].
-
-   PKIX [RFC3280] supports a number of authorization-data-like features,
-   like Extended Key Usage values (EKUs) and certificate extensions.
-
-   The authorization data can be accessed through the GSS-API name
-   attributes facility defined herein.
-
-5.1.  Kerberos V and SPKM Authorization-Data
-
-   Authorization-data non-container elements asserted in Kerberos V AP-
-   REQ Authenticators MUST be mapped into *asserted* GSS-API name
-   attributes; if not contained in AD-IF-RELEVANT then they MUST be
-   mapped into *critical* GSS-API name attributes.  AD-AND-OR
-   authorization-data elements MUST be mapped into a single *critical*
-   attribute, (TBD).
-
-
-
-Williams                 Expires April 17, 2006                 [Page 4]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-   Authorization-data included in Kerberos V Tickets that is not
-   contained in AD-KDCIssued (with valid signature) MUST be mapped into
-   *asserted* GSS-API name attributes.  Conversely, authorization-data
-   elements in Kerberos V Tickets contained by AD-KDCIssued MUST be
-   mapped into *authenticated* GSS-API name attributes
-
-   As with authorization-data elements in Authenticators, authorization-
-   data elements in Tickets not contained in AD-IF-RELEVANT are to be
-   mapped to *critical* name attributes, and similarly with AD-AND-OR
-   (see above).
-
-   The OIDs for authorization-data elements are to be the authorization-
-   data element's 'ad-type' integer ID, relative to the base OID <TBD>
-   [NOTE: what about negative ad-type's?  OID arcs are positive
-   integers... ad-type is an Int32, so clearly something can be done.]
-
-5.2.  Kerberos V Cross-Realm Transit Paths
-
-   [Add text on how to represent/encode/interpret krb5 realm transit
-   paths as name attribute values.  And text on PKINIT too...  Basically
-   Ticket's 'transited' field should be exposed as an authenticated name
-   attribute, with some uncompressed encoding, possibly encompassing
-   certificate validation paths of client certs used for PKINIT, with
-   criticality determined by the presence of the transit-policy-checked
-   flag.]
-
-5.3.  PKIX Certificate Extensions
-
-   [NOTE: In the Kerberos V authorization-data case we can tell when AD
-   elements are "authenticated" and when the are asserted, but what
-   about x.509 certificate extensions?  Clearly KU, EKUs and
-   subjectAltNames are authenticated in that no CA should sign a cert
-   with, say, arbitrary subjectAltNames not understood by the CA, but,
-   does that also apply to all other x.509 certificate extensions?  The
-   answer may depend on actual CA operator practices...  At worst a new
-   extension may be needed, like Kerberos V's AD-KDCIssued AD container
-   element; at best this text can just say "all cert extensions MUST be
-   mapped to authenticated..." below.]
-
-   PKI certificate extensions MAY/SHOULD/MUST (see comment above) be
-   mapped to *authenticated* GSS-API name attributes with the _same_
-   OIDs, and if they be marked critical in the certificate then they
-   MUST be mapped as *critical* GSS-API name attributes.
-   SubjectAltNames and EKUs, specifically, MUST be mapped to
-   *authenticated* GSS-API name attributes; see below.  Certificate
-   extensions MUST be mapped to GSS-API name attributes whose OIDs are
-   the same as the extensions'
-
-
-
-
-Williams                 Expires April 17, 2006                 [Page 5]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-5.3.1.  PKIX EKUs
-
-   Extended Key Usage extensions, specifically, MUST be mapped as
-   described above, except that GSS-API name attributes for EKUs MUST
-   have NULL values (i.e., zero-length OCTET STRINGs).
-
-   PKI certificate key usages (KUs, but not EKUs), MUST NOT be mapped to
-   GSS-API name attributes.
-
-5.3.2.  PKIX Certificate Alternative Names
-
-   PKI certificate subjectAltNames MUST be mapped as *authenticated*,
-   *non-critical* GSS-API name attributes.
-
-   PKI certificate extensions MUST be mapped to *authenticated* GSS-API
-   name attributes with the _same_ OIDs, and if they be marked critical
-   in the certificate then they MUST be mapped as *critical* GSS-API
-   name attributes.
-
-   Extended Key Usage extensions, specifically, MUST be mapped as
-   described above, except that GSS-API name attributes for EKUs MUST
-   have NULL values (i.e., zero-length OCTET STRINGs).
-
-5.3.3.  Other PKIX Certificate Extensions and Attributes
-
-   [Add text...]
-
-5.4.  PKIX Certificate CA Paths and Trust Anchors
-
-   [Add text on how to represent/encode/interpret PKI certificate
-   validation CA paths as name attribute values, much as with Kerberos V
-   transited paths.]
-
-
-6.  GSS_Inquire_name_attribute()
-
-   [NOTE: This function was somewhat controversial at IETF63; we should
-   decide whether to remove it at IETF64.  The controversy was, as I
-   recall over whether reflection functionality might not be dangerous,
-   leading to construction of inappropriate ACLs through dumb UIs.  For
-   now I am making some changes to it: adding a NAME object as an input
-   parameter and some output parameters.]
-
-   Inputs:
-
-
-   o  name NAME
-
-
-
-
-Williams                 Expires April 17, 2006                 [Page 6]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-   o  attr OBJECT IDENTIFIER
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  attr_name OCTET STRING, -- display name of the attribute
-
-   o  attr_description OCTET STRING, -- description of the attribute
-
-   o  attr_values_ordered BOOLEAN, -- whether the attribute's values are
-      an ordered set
-
-   o  attr_is_a_name BOOLEAN, -- whether the attribute's values can be
-      used as subjects of access control list entries
-
-   o  attr_is_trust_indicator BOOLEAN -- whether the attribute's values
-      represent nodes in trust paths
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
-      known (even if present as a name's attribute).
-
-   o  GSS_S_FAILURE indicates a general error.
-
-   This function outputs a name for the given name attribute,
-   description for display to users, and indicates whether the
-   attribute's values are ordered sets, whether the given name
-   attribute's values are useful as the subject of an access control
-   list entry and/or whether the given name attribute's values are
-   useful as indicators of trust (for example, whether they name PKIX
-   trust anchors).
-
-6.1.  C-Bindings
-
-   OM_uint32 gss_inquire_name_attribute(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     gss_OID                       attr,
-     gss_buffer_t                  attr_name,
-     gss_buffer_t                  attr_description,
-     int                           attr_values_ordered,
-
-
-
-Williams                 Expires April 17, 2006                 [Page 7]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-     int                           *attr_is_a_name,
-     int                           *attr_is_trust_indicator
-   );
-
-
-7.  GSS_Display_name_ext()
-
-   Inputs:
-
-
-   o  name NAME,
-
-   o  display_as_name_type OBJECT IDENTIFIER
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  display_name STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_UNAVAILABLE indicates that the given name could not be
-      displayed using the syntax of the given name type.
-
-   o  GSS_S_FAILURE indicates a general error.
-
-   This function displays a given name using the given name syntax, if
-   possible.  This operation may require mapping MNs to generic name
-   syntaxes or generic name syntaxes to mechanism-specific name
-   syntaxes; such mappings may not always be feasible and MAY be inexact
-   or lossy.
-
-7.1.  C-Bindings
-
-   OM_uint32 GSS_Display_name_ext(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     gss_OID                       display_as_name_type,
-     gss_buffer_t                  display_name
-   );
-
-
-
-
-
-Williams                 Expires April 17, 2006                 [Page 8]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-8.  GSS_Inquire_name()
-
-   Inputs:
-
-
-   o  name NAME
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  name_is_MN BOOLEAN,
-
-   o  mn_mech OBJECT IDENTIFIER,
-
-   o  asserted_attrs SET OF OBJECT IDENTIFIER,
-
-   o  authenticated_attrs SET OF OBJECT IDENTIFIER,
-
-   o  critical_attrs SET OF OBJECT IDENTIFIER,
-
-   o  all_attrs SET OF OBJECT IDENTIFIER,
-
-   o  [NOTE: Perhaps this function should also output an indicator as to
-      the provenance of the name, of which, in the GSS-API, there are
-      three: imported, inquired from a credential, and a peer's name
-      inquired from a security context.]
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_FAILURE indicates a general error.
-
-   This function outputs the sets of attributes of a name, that are
-   authenticated, asserted or critical.  It also indicates if a given
-   NAME is an MN or not and, if it is, what mechanism it's an MN of.
-
-8.1.  C-Bindings
-
-   OM_uint32 gss_inquire_name(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     int                           name_is_MN,
-     gss_OID                       *MN_mech,
-
-
-
-Williams                 Expires April 17, 2006                 [Page 9]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-     gss_OID_set                   *authenticated,
-     gss_OID_set                   *asserted,
-     gss_OID_set                   *critical,
-     gss_OID_set                   *all_attrs
-   );
-
-
-9.  GSS_Get_name_attribute()
-
-   Inputs:
-
-
-   o  name NAME,
-
-   o  attr OBJECT IDENTIFIER
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  authenticated BOOLEAN, -- FALSE if asserted but not authenticated
-      by a trusted entity
-
-   o  negative BOOLEAN,
-
-   o  mapped BOOLEAN,
-
-   o  critical BOOLEAN,
-
-   o  values SET OF OCTET STRING,
-
-   o  display_values SET OF STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
-      known or set.
-
-   o  GSS_S_FAILURE indicates a general error.
-
-   This function outputs the value(s) associated with a given GSS name
-   object for a given name attribute.
-
-
-
-
-Williams                 Expires April 17, 2006                [Page 10]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-   NOTE: This function relies on the GSS-API notion of "SET OF" allowing
-   for order preservation; this has been discussed on the KITTEN WG
-   mailing list and the consensus seems to be that, indeed, that was
-   always the intention.
-
-9.1.  C-Bindings
-
-   The C-bindings of GSS_Get_name_attribute() requires one function call
-   per-attribute value, for multi-valued name attributes.  This is done
-   by using a single gss_buffer_t for each value and an input/output
-   integer parameter to distinguish initial and subsequent calls and to
-   indicate when all values have been obtained.
-
-   The 'more' input/output parameter should point to an integer variable
-   whose value, on first call to gss_name_attribute_get() MUST be -1,
-   and whose value upon function call return will be non-zero to
-   indicate that additional values remain, or zero to indicate that no
-   values remain.  The caller should not modify this parameter after the
-   initial call.
-
-   OM_uint32 gss_get_name_attribute(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     gss_OID                       attr,
-     int                           *authenticated,
-     int                           *negative,
-     int                           *mapped,
-     int                           *critical,
-     gss_buffer_t                  value,
-     gss_buffer_t                  display_value,
-     int                           *more
-   );
-
-
-10.  GSS_Set_name_attribute()
-
-   Inputs:
-
-
-   o  name NAME,
-
-   o  critical BOOLEAN,
-
-   o  negative BOOLEAN,
-
-   o  attr OBJECT IDENTIFIER,
-
-   o  values SET OF OCTET STRING
-
-
-
-Williams                 Expires April 17, 2006                [Page 11]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
-      known or could not be set.
-
-   o  GSS_S_FAILURE indicates a general error.
-
-   NOTE: This function relies on the GSS-API notion of "SET OF" allowing
-   for order preservation; this has been discussed on the KITTEN WG
-   mailing list and the consensus seems to be that, indeed, that was
-   always the intention.
-
-10.1.  C-Bindings
-
-   The C-bindings of GSS_Set_name_attribute() requires one function call
-   per-attribute value, for multi-valued name attributes -- each call
-   adds one value.  To replace an attribute's every value delete the
-   attribute's values first with GSS_Delete_name_attribute().
-
-   OM_uint32 gss_set_name_attribute(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     int                           critical,
-     int                           negative,
-     gss_OID                       attr,
-     gss_buffer_t                  value
-   );
-
-
-11.  GSS_Delete_name_attribute()
-
-   Inputs:
-
-
-   o  name NAME,
-
-   o  attr OBJECT IDENTIFIER,
-
-   Outputs:
-
-
-
-Williams                 Expires April 17, 2006                [Page 12]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_UNAVAILABLE indicates that the given attribute OID is not
-      known.
-
-   o  GSS_S_FAILURE indicates a general error.
-
-   Deletion of negative authenticated attributes from NAME objects MUST
-   NOT be allowed.  [Do we need a new major status code for "permission
-   denied"?]
-
-11.1.  C-Bindings
-
-   OM_uint32 gss_delete_name_attribute(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     gss_OID                       attr
-   );
-
-
-12.  GSS_Export_name_composite()
-
-   Inputs:
-
-
-   o  name NAME
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  exp_composite_name OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_FAILURE indicates a general error.
-
-
-
-
-Williams                 Expires April 17, 2006                [Page 13]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-   This function outputs a token which can be imported with
-   GSS_Import_name(), using GSS_C_NT_COMPOSITE_EXPORT as the name type
-   and which preserves any name attribute information associated with
-   the input name (which GSS_Export_name() may well not).  The token
-   format is no specified here as this facility is intended for inter-
-   process communication only; however, all such tokens MUST start with
-   a two-octet token ID, hex 04 02, in network byte order.
-
-   The OID for GSS_C_NT_COMPOSITE_EXPORT is <TBD>.
-
-12.1.  C-Bindings
-
-   OM_uint32 gss_export_name_composite(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     gss_buffer_t                  exp_composite_name
-   );
-
-
-13.  GSS_Map_name_to_any()
-
-   Inputs:
-
-
-   o  name NAME,
-
-   o  authenticated BOOLEAN, -- if TRUE no data will be output unless it
-      is authenticated
-
-   o  type_id OBJECT IDENTIFIER
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output ANY DEFINED BY type_id
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_UNAVAILABLE indicates that the mapping or conversion could
-      not be done.  The minor status code may provide additional
-      information.
-
-
-
-
-Williams                 Expires April 17, 2006                [Page 14]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-   o  GSS_S_FAILURE indicates a general error.  The minor status code
-      may provide additional information.
-
-   Whereas name attribute's values are encoded in some network
-   representation applications often require native, language- and/or
-   platform-specific data types.  This function provides access to such
-   types.
-
-13.1.  C-Bindings
-
-   typedef struct gss_any *gss_any_t;
-   OM_uint32 gss_map_name_to_any(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     int                           authenticated,
-     gss_OID                       type_id,
-     gss_any_t                     output
-   );
-
-   Note the new C bindings type, gss_any_t.  We define it as a pointer
-   to an incompletely declared struct.
-
-
-14.  GSS_Release_any_name_mapping()
-
-   Inputs:
-
-
-   o  name NAME,
-
-   o  type_id OBJECT IDENTIFIER,
-
-   o  input ANY DEFINED BY type_id
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_UNAVAILABLE indicates that the mapping or conversion could
-      not be done.  The minor status code may provide additional
-      information.
-
-
-
-Williams                 Expires April 17, 2006                [Page 15]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-   o  GSS_S_FAILURE indicates a general error.  The minor status code
-      may provide additional information.
-
-   This function releases, if possible, the objects of language- and/or
-   platform-specific types output by GSS_Map_name_to_any().  If such
-   types have native release functions applications MAY use either those
-   or this function to release the given object.
-
-14.1.  C-Bindings
-
-   typedef struct gss_any *gss_any_t;
-   OM_uint32 gss_release_any_name_mapping(
-     OM_uint32                     *minor_status,
-     gss_name_t                    name,
-     gss_OID                       type_id,
-     gss_any_t                     *input
-   );
-
-
-15.  IANA Considerations
-
-   This document creates a namespace of GSS-API name attributes.
-   Attributes are named by OID, so no single authority might be needed
-   for allocation, however, in the interest of providing the community
-   with an authority for name attribute OID allocation and a way to find
-   the existing set of name attributes, the IANA should establish both,
-   a single OID off of which name attributes could be allocated, and a
-   registry of known GSS name attributes.
-
-   GSS-API name attribute registry entries should contain all the
-   information that GSS_Inquire_name_attribute() may return about the
-   given name attributes and their OIDs:
-
-   o  a name attribute OID (this is a unique key)
-
-   o  a name attribute symbolic name, starting with "GSS_C_NA_" (this is
-      a unique key)
-
-   o  a brief description, in English
-
-   o  whether the attribute is useful as the subject of access control
-      list entries
-
-   o  whether the attribute is useful as an indicator of trust
-
-   o  an optional normative reference to documentation for the given
-      name attribute
-
-
-
-
-Williams                 Expires April 17, 2006                [Page 16]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-   The allocation and registration policy should be first come, first
-   served.  Registry entries' OIDs need not be based on the base OID
-   given above.
-
-
-16.  Security Considerations
-
-   <TBA>
-
-   [In particular, the status of a name attribute as "authenticated" vs.
-   "asserted" requires close review, particularly with respect to PKIX
-   certificate extensions.]
-
-   [Also, we need to work out the security considerations of (and
-   possibly remove) negative attributes.]
-
-17.  Normative References
-
-   [I-D.GSS-NAMING]
-              Hartman, S., "Desired Enhancements to GSSAPI Naming",
-              draft-ietf-kitten-gss-naming-01.txt (work in progress),
-              February 2005.
-
-   [I-D.ietf-krb-wg-kerberos-clarifications]
-              Neuman, C., "The Kerberos Network Authentication Service
-              (V5)", draft-ietf-krb-wg-kerberos-clarifications-07 (work
-              in progress), September 2004.
-
-   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
-              (SPKM)", RFC 2025, October 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-
-
-
-
-
-
-Williams                 Expires April 17, 2006                [Page 17]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 17, 2006                [Page 18]
-
-Internet-Draft          GSS-API Naming Extensions           October 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                 Expires April 17, 2006                [Page 19]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-prf-01.txt b/doc/standardisation/draft-ietf-kitten-gssapi-prf-01.txt
deleted file mode 100644
index 99676165d..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-prf-01.txt
+++ /dev/null
@@ -1,505 +0,0 @@
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: December 30, 2004                                     July 2004
-
-
-                  A PRF API extension for the GSS-API
-                  draft-ietf-kitten-gssapi-prf-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on December 30, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This document defines a Pseudo-Random Function (PRF) extension to the
-   Generic Security Service Applicatoin Programming Interface (GSS-API)
-   for keying application protocols given an established GSS-API
-   security context.  The primary intended use of this function is to
-   key secure session layers that don't or cannot use GSS-API
-   per-message MIC (message integrity check) and wrap tokens for session
-   protection.
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 1]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-Table of Contents
-
-   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . .  5
-   3.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   5.1 Normative References . . . . . . . . . . . . . . . . . . . . .  8
-   5.2 Informative References . . . . . . . . . . . . . . . . . . . .  8
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
-       Intellectual Property and Copyright Statements . . . . . . . .  9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 2]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 3]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-2.  Introduction
-
-   A need has arisen for users of the GSS-API to key applications'
-   cryptographic protocols using established GSS-API security contexts.
-   Such applications can use the GSS-API for authentication, but not for
-   transport security (for whatever reasons), and since the GSS-API does
-   not provide a method for obtaining keying material from established
-   security contexts such applications cannot make effective use of the
-   GSS-API.
-
-   To address this need we define a pseudo-random function (PRF)
-   extension to the GSS-API.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 4]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-3.  GSS_Pseudo_random()
-
-   Inputs:
-
-   o  context CONTEXT handle,
-   o  prf_in OCTET STRING,
-   o  desired_output_len INTEGER
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  prf_out OCTET STRING
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates no error.
-   o  GSS_S_NO_CONTEXT indicates that a null context has been provided
-      as input.
-   o  GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
-      provided as input.
-   o  GSS_S_UNAVAILABLE indicates that the mechanism lacks support for
-      this function.
-   o  GSS_S_FAILURE indicates failure or lack of support; the minor
-      status code may provide additional information.
-
-   This function applies the established context's mechanism's keyed PRF
-   function to the input data (prf_in), keyed with key material
-   associated with the given security context and outputs the resulting
-   octet string (prf_out) of desired_output_len length.
-
-   The output string of this function MUST be a pseudo-random function
-   [GGM1][GGM2] of the input keyed with key material from the
-   established security context -- the chances of getting the same
-   output given different input parameters should be exponentially
-   small.
-
-   This function, applied to the same inputs by an initiator and
-   acceptor using the same established context, MUST produce the *same
-   results* for both, the initiator and acceptor, even if called
-   multiple times for the same context.
-
-   Mechanisms MAY limit the output of the PRF according, possibly in
-   ways related to the types of cryptographic keys available for the PRF
-   function, thus the prf_out output of GSS_Pseudo_random() MAY be
-   smaller than requested.
-
-3.1  C-Bindings
-
-
-
-
-Williams               Expires December 30, 2004                [Page 5]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-   OM_uint32 gss_pseudo_random(
-     OM_uint32			*minor_status,
-     gss_ctx_id_t			context,
-     const gss_buffer_t		prf_in,
-     ssize_t		desired_output_len,
-     gss_buffer_t		prf_out
-   );
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 6]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-4.  Security Considerations
-
-   Care should be taken in properly designing a mechanism's PRF
-   function.
-
-   GSS mechanisms' PRF functions should use a key derived from contexts'
-   session keys and should preserve the forward security properties of
-   the mechanisms' key exchanges.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 7]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-5.  References
-
-5.1  Normative References
-
-   [GGM1]     Goldreich, O., Goldwasser, S. and S. Micali, "How to
-              Construct Random Functions", October 1986.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-5.2  Informative References
-
-   [GGM2]     Goldreich, O., Goldwasser, S. and S. Micali, "On the
-              Cryptographic Applications of Random Functions", 1985.
-
-   [RFC1750]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-              Recommendations for Security", RFC 1750, December 1994.
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 8]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams               Expires December 30, 2004                [Page 9]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-prf-02.txt b/doc/standardisation/draft-ietf-kitten-gssapi-prf-02.txt
deleted file mode 100644
index 9afd512d2..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-prf-02.txt
+++ /dev/null
@@ -1,505 +0,0 @@
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: December 30, 2004                                     July 2004
-
-
-                  A PRF API extension for the GSS-API
-                  draft-ietf-kitten-gssapi-prf-02.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on December 30, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This document defines a Pseudo-Random Function (PRF) extension to the
-   Generic Security Service Applicatoin Programming Interface (GSS-API)
-   for keying application protocols given an established GSS-API
-   security context.  The primary intended use of this function is to
-   key secure session layers that don't or cannot use GSS-API
-   per-message MIC (message integrity check) and wrap tokens for session
-   protection.
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 1]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-Table of Contents
-
-   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . .  5
-   3.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   5.1 Normative References . . . . . . . . . . . . . . . . . . . . .  8
-   5.2 Informative References . . . . . . . . . . . . . . . . . . . .  8
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
-       Intellectual Property and Copyright Statements . . . . . . . .  9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 2]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 3]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-2.  Introduction
-
-   A need has arisen for users of the GSS-API to key applications'
-   cryptographic protocols using established GSS-API security contexts.
-   Such applications can use the GSS-API for authentication, but not for
-   transport security (for whatever reasons), and since the GSS-API does
-   not provide a method for obtaining keying material from established
-   security contexts such applications cannot make effective use of the
-   GSS-API.
-
-   To address this need we define a pseudo-random function (PRF)
-   extension to the GSS-API.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 4]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-3.  GSS_Pseudo_random()
-
-   Inputs:
-
-   o  context CONTEXT handle,
-   o  prf_in OCTET STRING,
-   o  desired_output_len INTEGER
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  prf_out OCTET STRING
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates no error.
-   o  GSS_S_NO_CONTEXT indicates that a null context has been provided
-      as input.
-   o  GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
-      provided as input.
-   o  GSS_S_UNAVAILABLE indicates that the mechanism lacks support for
-      this function or, if the security context is not fully
-      established, that the context is not ready to compute the PRF.
-   o  GSS_S_FAILURE indicates failure or lack of support; the minor
-      status code may provide additional information.
-
-   This function applies the established context's mechanism's keyed PRF
-   function to the input data (prf_in), keyed with key material
-   associated with the given security context and outputs the resulting
-   octet string (prf_out) of desired_output_len length.
-
-   The output string of this function MUST be a pseudo-random function
-   [GGM1][GGM2] of the input keyed with key material from the
-   established security context -- the chances of getting the same
-   output given different input parameters should be exponentially
-   small.
-
-   This function, applied to the same inputs by an initiator and
-   acceptor using the same established context, MUST produce the *same
-   results* for both, the initiator and acceptor, even if called
-   multiple times for the same context.
-
-   Mechanisms MAY limit the output of the PRF according, possibly in
-   ways related to the types of cryptographic keys available for the PRF
-   function, thus the prf_out output of GSS_Pseudo_random() MAY be
-   smaller than requested.
-
-   Mechanisms may be able to compute PRFs with security contexts that
-
-
-
-Williams               Expires December 30, 2004                [Page 5]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-   are not fully established, therefore applications MAY call
-   GSS_Pseudo_random() with such security contexts.  Such mechanisms
-   MUST return GSS_S_UNAVAILABLE when called on to compute a PRF given a
-   security context that is not fully established and also not ready for
-   PRF computation.  Mechanisms that allow for PRF computation prior to
-   full security context establishment MUST use the same PRF and key
-   material, for any given security context, both, before and after full
-   context establishment, and the PRF and key material negotiation MUT
-   be authenticated when the security context is fully established.
-
-3.1  C-Bindings
-
-   OM_uint32 gss_pseudo_random(
-     OM_uint32			*minor_status,
-     gss_ctx_id_t			context,
-     const gss_buffer_t		prf_in,
-     ssize_t		desired_output_len,
-     gss_buffer_t		prf_out
-   );
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 6]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-4.  Security Considerations
-
-   Care should be taken in properly designing a mechanism's PRF
-   function.
-
-   GSS mechanisms' PRF functions should use a key derived from contexts'
-   session keys and should preserve the forward security properties of
-   the mechanisms' key exchanges.
-
-   Some mechanisms may support the GSS PRF function with security
-   contexts that are not fully established, but applications MUST assume
-   that authentication, mutual or otherwise, has not completed until the
-   security context is fully established
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 7]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-5.  References
-
-5.1  Normative References
-
-   [GGM1]     Goldreich, O., Goldwasser, S. and S. Micali, "How to
-              Construct Random Functions", October 1986.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-5.2  Informative References
-
-   [GGM2]     Goldreich, O., Goldwasser, S. and S. Micali, "On the
-              Cryptographic Applications of Random Functions", 1985.
-
-   [RFC1750]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-              Recommendations for Security", RFC 1750, December 1994.
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 8]
-
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams               Expires December 30, 2004                [Page 9]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-prf-03.txt b/doc/standardisation/draft-ietf-kitten-gssapi-prf-03.txt
deleted file mode 100644
index 97687b332..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-prf-03.txt
+++ /dev/null
@@ -1,446 +0,0 @@
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: November 13, 2005                                  May 12, 2005
-
-
-                  A PRF API extension for the GSS-API
-                  draft-ietf-kitten-gssapi-prf-03.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on November 13, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document defines a Pseudo-Random Function (PRF) extension to the
-   Generic Security Service Application Programming Interface (GSS-API)
-   for keying application protocols given an established GSS-API
-   security context.  The primary intended use of this function is to
-   key secure session layers that don't or cannot use GSS-API per-
-   message MIC (message integrity check) and wrap tokens for session
-   protection.
-
-
-
-
-
-Williams                Expires November 13, 2005               [Page 1]
-
-Internet-Draft       A PRF Extension for the GSS-API            May 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   1.1 Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . .  3
-   2.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.2 Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . .  6
-   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
-   5.1 Normative References . . . . . . . . . . . . . . . . . . . . .  7
-   5.2 Informative References . . . . . . . . . . . . . . . . . . . .  7
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  7
-       Intellectual Property and Copyright Statements . . . . . . . .  8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires November 13, 2005               [Page 2]
-
-Internet-Draft       A PRF Extension for the GSS-API            May 2005
-
-
-1.  Introduction
-
-   A need has arisen for users of the GSS-API to key applications'
-   cryptographic protocols using established GSS-API security contexts.
-   Such applications can use the GSS-API for authentication, but not for
-   transport security (for whatever reasons), and since the GSS-API does
-   not provide a method for obtaining keying material from established
-   security contexts such applications cannot make effective use of the
-   GSS-API.
-
-   To address this need we define a pseudo-random function (PRF)
-   extension to the GSS-API.
-
-1.1  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  GSS_Pseudo_random()
-
-   Inputs:
-
-
-   o  context CONTEXT handle,
-
-   o  prf_key INTEGER,
-
-   o  prf_in OCTET STRING,
-
-   o  desired_output_len INTEGER
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  prf_out OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_NO_CONTEXT indicates that a null context has been provided
-      as input.
-
-
-
-
-Williams                Expires November 13, 2005               [Page 3]
-
-Internet-Draft       A PRF Extension for the GSS-API            May 2005
-
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
-      provided as input.
-
-   o  GSS_S_UNAVAILABLE indicates that the mechanism lacks support for
-      this function or, if the security context is not fully
-      established, that the context is not ready to compute the PRF with
-      the given prf_key, or that the given prf_key is not available.
-
-   o  GSS_S_FAILURE indicates general failure, possibly due to the given
-      input data being too large or of zero length, or due to the
-      desired_output_len being zero; the minor status code may provide
-      additional information.
-
-   This function applies the established context's mechanism's keyed
-   pseudo-random function (PRF) to the input data ('prf_in'), keyed with
-   key material associated with the given security context and
-   identified by 'prf_key', and outputs the resulting octet string
-   ('prf_out') of desired_output_len length.
-
-   The minimum input data length is one octet.
-
-   Mechanisms MUST be able to consume all the provided prf_in input data
-   that is 2^14 or fewer octets.
-
-   If a mechanism cannot consume as much input data as provided by the
-   caller, then GSS_Pseudo_random() MUST return GSS_S_FAILURE.
-
-   The minimum desired_output_len is one.
-
-   Mechanisms MUST be able to output at least up to 2^14 octets.
-
-   If the implementation cannot produce the desired output due to lack
-   of resources then it MUST output what it can and still return
-   GSS_S_COMPLETE.
-
-   The prf_key can take on the following values: GSS_C_PRF_KEY_FULL,
-   GSS_C_PRF_KEY_PARTIAL or mechanism-specific values, if any.  This
-   parameter is intended to distinguish between the best cryptographic
-   keys that may be available only after full security context
-   establishment and keys that may be available prior to full security
-   context establishment.  For some mechanisms, or contexts, those two
-   prf_key values MAY refer to the same cryptographic keys; for
-   mechanisms like the Kerberos V GSS-API mechanism [RFC1964] where one
-   peer may assert a key that may be considered better than the others
-   they MAY be different keys.
-
-   GSS_C_PRF_KEY_PARTIAL corresponds to a key that would be have been
-   used while the security context was partially established, even if it
-
-
-
-Williams                Expires November 13, 2005               [Page 4]
-
-Internet-Draft       A PRF Extension for the GSS-API            May 2005
-
-
-   is fully established when GSS_Pseudo_random() is actually called.
-   Mechanism-specific prf_key values are intended to refer to any other
-   keys that may be available.
-
-   The GSS_C_PRF_KEY_FULL value corresponds to the best key available
-   for fully-established security contexts.
-
-   GSS_Pseudo_random() has the following properties:
-
-   o  its output string MUST be a pseudo-random function [GGM1] [GGM2]
-      of the input keyed with key material from the given security
-      context -- the chances of getting the same output given different
-      input parameters should be exponentially small.
-
-   o  when successfully applied to the same inputs by an initiator and
-      acceptor using the same security context, it MUST produce the
-      _same results_ for both, the initiator and acceptor, even if
-      called multiple times (as long as the security context is not
-      expired).
-
-   o  upon full establishment of a security context all cryptographic
-      keys and/or negotiations used for computing the PRF with any
-      prf_key MUST be authenticated (mutually, if mutual authentication
-      is in effect for the given security context).
-
-   o  the outputs of the mechanism's GSS_Pseudo_random() (for different
-      inputs) and its per-message tokens for the given security context
-      MUST be "cryptographically separate;" in other words, it must not
-      be feasible to recover key material for one mechanism operation or
-      transform its tokens and PRF outputs from one to the other given
-      only said tokens and PRF outputs.  [This is a fancy way of saying
-      that key derivation and strong cryptographic operations and
-      constructions must be used.]
-
-   o  as implied by the above requirement, it MUST NOT be possible to
-      access any raw keys of a security context through
-      GSS_Pseudo_random(), no matter what inputs are given.
-
-   Mechanisms MAY limit the output of the PRF, possibly in ways related
-   to the types of cryptographic keys available for the PRF function,
-   thus the prf_out output of GSS_Pseudo_random() MAY be smaller than
-   requested.
-
-2.1  C-Bindings
-
-   #define GSS_C_PRF_KEY_FULL 0
-   #define GSS_C_PRF_KEY_PARTIAL 1
-
-
-
-
-Williams                Expires November 13, 2005               [Page 5]
-
-Internet-Draft       A PRF Extension for the GSS-API            May 2005
-
-
-   OM_uint32 gss_pseudo_random(
-     OM_uint32                     *minor_status,
-     gss_ctx_id_t                  context,
-     int                           prf_key,
-     const gss_buffer_t            prf_in,
-     ssize_t                       desired_output_len,
-     gss_buffer_t                  prf_out
-   );
-
-   Additional major status codes for the C-bindings:
-
-   o  GSS_S_CALL_INACCESSIBLE_READ
-
-   o  GSS_S_CALL_INACCESSIBLE_WRITE
-
-   See [RFC2744].
-
-2.2  Java Bindings
-
-   For Java GSS_Pseudo_random() maps to a GSSContext method, 'prf':
-
-   public static final int GSS_C_PRF_KEY_FULL = 0
-   public static final int GSS_C_PRF_KEY_PARTIAL = 1
-
-   public byte[] prf(int prf_key, byte inBuf[], int outlen)
-      throws GSSException
-
-   See [RFC2853].
-
-3.  IANA Considerations
-
-   This document has no IANA considerations currently.  If and when a
-   relevant IANA registry of GSS-API symbols is created then the generic
-   and language-specific function names, constant names and constant
-   values described above should be added to such a registry.
-
-4.  Security Considerations
-
-   Care should be taken in properly designing a mechanism's PRF
-   function.
-
-   GSS mechanisms' PRF functions should use a key derived from contexts'
-   authenticated session keys and should preserve the forward security
-   properties of the mechanisms' key exchanges.
-
-   Some mechanisms may support the GSS PRF function with security
-   contexts that are not fully established, but applications MUST assume
-   that authentication, mutual or otherwise, has not completed until the
-
-
-
-Williams                Expires November 13, 2005               [Page 6]
-
-Internet-Draft       A PRF Extension for the GSS-API            May 2005
-
-
-   security context is fully established.
-
-   Callers of GSS_Pseudo_random() should avoid accidentally calling it
-   with the same inputs.  One useful technique is to prepend to the
-   prf_in input string, by convention, a string indicating the intended
-   purpose of the PRF output in such a way that unique contexts in which
-   the function is called yield unique inputs to it.
-
-5.  References
-
-5.1  Normative References
-
-   [GGM1]     Goldreich, O., Goldwasser, S., and S. Micali, "How to
-              Construct Random Functions", October 1986.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-   [RFC2853]  Kabat, J. and M. Upadhyay, "Generic Security Service API
-              Version 2 : Java Bindings", RFC 2853, June 2000.
-
-5.2  Informative References
-
-   [GGM2]     Goldreich, O., Goldwasser, S., and S. Micali, "On the
-              Cryptographic Applications of Random Functions", 1985.
-
-   [RFC1750]  Eastlake, D., Crocker, S., and J. Schiller, "Randomness
-              Recommendations for Security", RFC 1750, December 1994.
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-Williams                Expires November 13, 2005               [Page 7]
-
-Internet-Draft       A PRF Extension for the GSS-API            May 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                Expires November 13, 2005               [Page 8]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-prf-04.txt b/doc/standardisation/draft-ietf-kitten-gssapi-prf-04.txt
deleted file mode 100644
index 8a3bb4d34..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-prf-04.txt
+++ /dev/null
@@ -1,505 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: December 15, 2005                                 June 13, 2005
-
-
-                  A PRF API extension for the GSS-API
-                  draft-ietf-kitten-gssapi-prf-04.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on December 15, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document defines a Pseudo-Random Function (PRF) extension to the
-   Generic Security Service Application Programming Interface (GSS-API)
-   for keying application protocols given an established GSS-API
-   security context.  The primary intended use of this function is to
-   key secure session layers that don't or cannot use GSS-API per-
-   message MIC (message integrity check) and wrap tokens for session
-   protection.
-
-
-
-
-
-Williams                Expires December 15, 2005               [Page 1]
-
-Internet-Draft       A PRF Extension for the GSS-API           June 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   1.1 Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . .  3
-   2.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.2 Java Bindings  . . . . . . . . . . . . . . . . . . . . . . . .  6
-   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
-   5.1 Normative References . . . . . . . . . . . . . . . . . . . . .  7
-   5.2 Informative References . . . . . . . . . . . . . . . . . . . .  7
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
-       Intellectual Property and Copyright Statements . . . . . . . .  9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires December 15, 2005               [Page 2]
-
-Internet-Draft       A PRF Extension for the GSS-API           June 2005
-
-
-1.  Introduction
-
-   A need has arisen for users of the GSS-API to key applications'
-   cryptographic protocols using established GSS-API security contexts.
-   Such applications can use the GSS-API for authentication, but not for
-   transport security (for whatever reasons), and since the GSS-API does
-   not provide a method for obtaining keying material from established
-   security contexts such applications cannot make effective use of the
-   GSS-API.
-
-   To address this need we define a pseudo-random function (PRF)
-   extension to the GSS-API.
-
-1.1  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  GSS_Pseudo_random()
-
-   Inputs:
-
-
-   o  context CONTEXT handle,
-
-   o  prf_key INTEGER,
-
-   o  prf_in OCTET STRING,
-
-   o  desired_output_len INTEGER
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  prf_out OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_NO_CONTEXT indicates that a null context has been provided
-      as input.
-
-
-
-
-Williams                Expires December 15, 2005               [Page 3]
-
-Internet-Draft       A PRF Extension for the GSS-API           June 2005
-
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
-      provided as input.
-
-   o  GSS_S_UNAVAILABLE indicates that the mechanism lacks support for
-      this function or, if the security context is not fully
-      established, that the context is not ready to compute the PRF with
-      the given prf_key, or that the given prf_key is not available.
-
-   o  GSS_S_FAILURE indicates general failure, possibly due to the given
-      input data being too large or of zero length, or due to the
-      desired_output_len being zero; the minor status code may provide
-      additional information.
-
-   This function applies the established context's mechanism's keyed
-   pseudo-random function (PRF) to the input data ('prf_in'), keyed with
-   key material associated with the given security context and
-   identified by 'prf_key', and outputs the resulting octet string
-   ('prf_out') of desired_output_len length.
-
-   The minimum input data length is one octet.
-
-   Mechanisms MUST be able to consume all the provided prf_in input data
-   that is 2^14 or fewer octets.
-
-   If a mechanism cannot consume as much input data as provided by the
-   caller, then GSS_Pseudo_random() MUST return GSS_S_FAILURE.
-
-   The minimum desired_output_len is one.
-
-   Mechanisms MUST be able to output at least up to 2^14 octets.
-
-   If the implementation cannot produce the desired output due to lack
-   of resources then it MUST output what it can and still return
-   GSS_S_COMPLETE.
-
-   The prf_key can take on the following values: GSS_C_PRF_KEY_FULL,
-   GSS_C_PRF_KEY_PARTIAL or mechanism-specific values, if any.  This
-   parameter is intended to distinguish between the best cryptographic
-   keys that may be available only after full security context
-   establishment and keys that may be available prior to full security
-   context establishment.  For some mechanisms, or contexts, those two
-   prf_key values MAY refer to the same cryptographic keys; for
-   mechanisms like the Kerberos V GSS-API mechanism [RFC1964] where one
-   peer may assert a key that may be considered better than the others
-   they MAY be different keys.
-
-   GSS_C_PRF_KEY_PARTIAL corresponds to a key that would be have been
-   used while the security context was partially established, even if it
-
-
-
-Williams                Expires December 15, 2005               [Page 4]
-
-Internet-Draft       A PRF Extension for the GSS-API           June 2005
-
-
-   is fully established when GSS_Pseudo_random() is actually called.
-   Mechanism-specific prf_key values are intended to refer to any other
-   keys that may be available.
-
-   The GSS_C_PRF_KEY_FULL value corresponds to the best key available
-   for fully-established security contexts.
-
-   GSS_Pseudo_random() has the following properties:
-
-   o  its output string MUST be a pseudo-random function [GGM1] [GGM2]
-      of the input keyed with key material from the given security
-      context -- the chances of getting the same output given different
-      input parameters should be exponentially small.
-
-   o  when successfully applied to the same inputs by an initiator and
-      acceptor using the same security context, it MUST produce the
-      _same results_ for both, the initiator and acceptor, even if
-      called multiple times (as long as the security context is not
-      expired).
-
-   o  upon full establishment of a security context all cryptographic
-      keys and/or negotiations used for computing the PRF with any
-      prf_key MUST be authenticated (mutually, if mutual authentication
-      is in effect for the given security context).
-
-   o  the outputs of the mechanism's GSS_Pseudo_random() (for different
-      inputs) and its per-message tokens for the given security context
-      MUST be "cryptographically separate;" in other words, it must not
-      be feasible to recover key material for one mechanism operation or
-      transform its tokens and PRF outputs from one to the other given
-      only said tokens and PRF outputs.  [This is a fancy way of saying
-      that key derivation and strong cryptographic operations and
-      constructions must be used.]
-
-   o  as implied by the above requirement, it MUST NOT be possible to
-      access any raw keys of a security context through
-      GSS_Pseudo_random(), no matter what inputs are given.
-
-   Mechanisms MAY limit the output of the PRF, possibly in ways related
-   to the types of cryptographic keys available for the PRF function,
-   thus the prf_out output of GSS_Pseudo_random() MAY be smaller than
-   requested.
-
-2.1  C-Bindings
-
-   #define GSS_C_PRF_KEY_FULL 0
-   #define GSS_C_PRF_KEY_PARTIAL 1
-
-
-
-
-Williams                Expires December 15, 2005               [Page 5]
-
-Internet-Draft       A PRF Extension for the GSS-API           June 2005
-
-
-   OM_uint32 gss_pseudo_random(
-     OM_uint32                     *minor_status,
-     gss_ctx_id_t                  context,
-     int                           prf_key,
-     const gss_buffer_t            prf_in,
-     ssize_t                       desired_output_len,
-     gss_buffer_t                  prf_out
-   );
-
-   Additional major status codes for the C-bindings:
-
-   o  GSS_S_CALL_INACCESSIBLE_READ
-
-   o  GSS_S_CALL_INACCESSIBLE_WRITE
-
-   See [RFC2744].
-
-2.2  Java Bindings
-
-   For Java GSS_Pseudo_random() maps to a GSSContext method, 'prf':
-
-   public static final int GSS_C_PRF_KEY_FULL = 0
-   public static final int GSS_C_PRF_KEY_PARTIAL = 1
-
-   public byte[] prf(int prf_key, byte inBuf[], int outlen)
-      throws GSSException
-
-   See [RFC2853].
-
-3.  IANA Considerations
-
-   This document has no IANA considerations currently.  If and when a
-   relevant IANA registry of GSS-API symbols is created then the generic
-   and language-specific function names, constant names and constant
-   values described above should be added to such a registry.
-
-4.  Security Considerations
-
-   Care should be taken in properly designing a mechanism's PRF
-   function.
-
-   GSS mechanisms' PRF functions should use a key derived from contexts'
-   authenticated session keys and should preserve the forward security
-   properties of the mechanisms' key exchanges.
-
-   Some mechanisms may support the GSS PRF function with security
-   contexts that are not fully established, but applications MUST assume
-   that authentication, mutual or otherwise, has not completed until the
-
-
-
-Williams                Expires December 15, 2005               [Page 6]
-
-Internet-Draft       A PRF Extension for the GSS-API           June 2005
-
-
-   security context is fully established.
-
-   Callers of GSS_Pseudo_random() should avoid accidentally calling it
-   with the same inputs.  One useful technique is to prepend to the
-   prf_in input string, by convention, a string indicating the intended
-   purpose of the PRF output in such a way that unique contexts in which
-   the function is called yield unique inputs to it.
-
-   Pseudo-random functions are, by their nature, capable of producing
-   only limited amounts of cryptographically secure output.  The exact
-   amount of output that one can safely use, unfortunately, varies from
-   one PRF to another (which prevents us from recommending specific
-   numbers).  Because of this we recommend that unless you really know
-   what you are doing (i.e. you are a cryptographer and are qualified to
-   pass judgement on cryptographic functions in areas of period,
-   presence of short cycles, etc), you limit the amount of the PRF
-   output used to the necessary minimum.
-
-5.  References
-
-5.1  Normative References
-
-   [GGM1]     Goldreich, O., Goldwasser, S., and S. Micali, "How to
-              Construct Random Functions", October 1986.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-   [RFC2853]  Kabat, J. and M. Upadhyay, "Generic Security Service API
-              Version 2 : Java Bindings", RFC 2853, June 2000.
-
-5.2  Informative References
-
-   [GGM2]     Goldreich, O., Goldwasser, S., and S. Micali, "On the
-              Cryptographic Applications of Random Functions", 1985.
-
-   [RFC1750]  Eastlake, D., Crocker, S., and J. Schiller, "Randomness
-              Recommendations for Security", RFC 1750, December 1994.
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-
-
-
-Williams                Expires December 15, 2005               [Page 7]
-
-Internet-Draft       A PRF Extension for the GSS-API           June 2005
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires December 15, 2005               [Page 8]
-
-Internet-Draft       A PRF Extension for the GSS-API           June 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                Expires December 15, 2005               [Page 9]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-00.txt b/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-00.txt
deleted file mode 100644
index e5398a0a4..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-00.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: August 15, 2005                               February 14, 2005
-
-
-          GSS-API Extension for Storing Delegated Credentials
-               draft-ietf-kitten-gssapi-store-cred-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 15, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).  All Rights Reserved.
-
-Abstract
-
-   This document defines a new function for the GSS-API which allows
-   applications to store delegated (and other) credentials in the
-   implicit GSS-API credential store.  This is needed for GSS-API
-   applications to use delegated credentials as they would use other
-   credentials.
-
-
-
-
-
-
-
-
-Williams                Expires August 15, 2005                 [Page 1]
-
-Internet-Draft              GSS_Store_cred()               February 2005
-
-
-Table of Contents
-
-   1. Conventions used in this document  . . . . . . . . . . . . . .   3
-   2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   4
-   3. GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . .   5
-   4. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .   7
-   5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
-   6. Security considerations  . . . . . . . . . . . . . . . . . . .   9
-   7. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
-      Author's Address . . . . . . . . . . . . . . . . . . . . . . .   9
-      Intellectual Property and Copyright Statements . . . . . . . .  10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires August 15, 2005                 [Page 2]
-
-Internet-Draft              GSS_Store_cred()               February 2005
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires August 15, 2005                 [Page 3]
-
-Internet-Draft              GSS_Store_cred()               February 2005
-
-
-2.  Introduction
-
-   The GSS-API [RFC2743] clearly assumes that credentials exist in an
-   implicit store whence they can be acquired using GSS_Acquire_cred()
-   and GSS_Add_cred() or through use of the default credential.
-   Multiple credential stores may exist on a given host, but only one
-   store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
-   given time.
-
-   This assumption can be seen in sections 1.1.1.2 and 1.1.1.3 of
-   [RFC2743] as well as in section 3.5 of [RFC2744].
-
-   Note to the RFC editor: please remove this note before publication.]
-
-   Applications may be able to change the credential store from which
-   credentials can be acquired, either by changing user contexts (where
-   the applications have the privilege to do so) or by other means
-   (where a user may have multiple credential stores).
-
-   Some GSS-API acceptor applications always change user contexts, after
-   accepting a GSS-API security context and making appropriate
-   authorization checks, to the user context corresponding to the
-   initiator principal name or to a context requested by the initiator.
-   The means by which credential stores are managed are generally beyond
-   the scope of the GSS-API.
-
-   In the case of delegated credential handles however, such credentials
-   do not exist in the acceptor's credential store or in the credential
-   stores of the user contexts to which the acceptor application might
-   change - which is precisely the raison d'etre of credential
-   delegation.  But the GSS-API provides no mechanism by which delegated
-   credential handles can be made available for acquisition through
-   GSS_Acquire_cred()/GSS_Add_cred().  The GSS-API also does not provide
-   any credential import/export interfaces like the GSS-API context
-   import/export interfaces.
-
-   Thus acceptors are limited to making only direct use of delegated
-   credential handles and only with GSS_Init_sec_context(),
-   GSS_Inquire_cred*() and GSS_Release_cred().  This limitation is
-   particularly onerous on Unix systems where a call to exec() to
-   replace the process image obliterates the delegated credentials
-   handle.
-
-   In order to make delegated credentials generally as useful as
-   credentials that can be acquired with GSS_Acquire_cred() and
-   GSS_Add_cred() a primitive is needed which allows storing of
-   credentials in the implicit credential store.  This primitive we call
-   "GSS_Store_cred()."
-
-
-
-Williams                Expires August 15, 2005                 [Page 4]
-
-Internet-Draft              GSS_Store_cred()               February 2005
-
-
-3.  GSS_Store_cred()
-
-   Inputs:
-   o  input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
-      NOT be GSS_C_NO_CREDENTIAL
-   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-      2=ACCEPT-ONLY
-   o  desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID then
-      store all the elements of the input_cred_handle, otherwise store
-      only the element of the corresponding mechanism
-   o  overwrite_cred BOOLEAN, -- if TRUE replace any credential for the
-      same principal in the credential store
-   o  default_cred BOOLEAN -- if TRUE make the stored credential
-      available as the default credential (for acquisition with
-      GSS_C_NO_NAME as the desired name or for use as
-      GSS_C_NO_CREDENTIAL)
-
-   Outputs:
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
-      mechanism OIDs for which credential elements were successfully
-      stored
-   o  cred_usage_stored INTEGER -- like cred_usage, but indicates what
-      kind of credential was stored (useful when the cred_usage input
-      parameter is set to INITIATE-AND-ACCEPT)
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates that the credentials were successfully
-      stored.
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had
-      expired or expired before they could be stored.
-   o  GSS_S_NO_CRED indicates that no input credentials were given.
-   o  GSS_S_UNAVAILABLE indicates that the credential store is not
-      available.
-   o  GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
-      credential could not be stored because a credential for the same
-      principal exists in the current credential store and the
-      overwrite_cred input argument was FALSE.
-   o  GSS_S_FAILURE indicates that the credential could not be stored
-      for some other reason.  The minor status code may provide more
-      information if a non-GSS_C_NULL_OID desired_mech_element was
-      given.
-
-   GSS_Store_cred() is used to store, in the current credential store, a
-   given credential that has either been acquired from a different
-   credential store or been accepted as a delegated credential.
-
-
-
-
-Williams                Expires August 15, 2005                 [Page 5]
-
-Internet-Draft              GSS_Store_cred()               February 2005
-
-
-   Specific mechanism elements of a credential can be stored one at a
-   time by specifying a non-GSS_C_NULL_OID mechanism OID as the
-   desired_mech_element input argument, in which case the minor status
-   output SHOULD have a mechanism-specific value when the major status
-   is not GSS_S_COMPLETE.
-
-   The initiator, acceptor or both usages of the input credential may be
-   stored as per the cred_usage input argument.
-
-   The credential elements that were actually stored, when the major
-   status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
-   and mech_elements_stored function outputs.
-
-   If credentials already exist in the current store for the principal
-   of the input_cred_handle, then those credentials are not replaced
-   with the input credentials unless the overwrite_cred input argument
-   is TRUE.
-
-   Finally, if the current credential store has no default credential
-   (that is, no credential that could be acquired for GSS_C_NO_NAME) or
-   if the default_cred input argument is TRUE, and the input credential
-   can be successfully stored, then the input credential will be
-   available for acquisition with GSS_C_NO_NAME as the desired name
-   input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as
-   GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(),
-   GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and
-   GSS_Accept_sec_context().
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires August 15, 2005                 [Page 6]
-
-Internet-Draft              GSS_Store_cred()               February 2005
-
-
-4.  C-Bindings
-
-   The C-bindings for GSS_Store_cred() make use of types from and are
-   designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
-
-
-      OM_uint32 gss_store_cred(
-         OM_uint32         *minor_status,
-         gss_cred_id_t     input_cred,
-         gss_cred_usage_t  cred_usage,
-         const gss_OID     desired_mech,
-         OM_uint32         overwrite_cred,
-         OM_uint32         default_cred,
-         gss_OID_set       *elements_stored,
-         gss_cred_usage_t  *cred_usage_stored)
-
-
-                                Figure 1
-
-   The two boolean arguments, 'overwrite_cred' and 'default_cred' are
-   typed as OM_uint32; 0 corresponds to FALSE, non-zero values
-   correspond to TRUE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires August 15, 2005                 [Page 7]
-
-Internet-Draft              GSS_Store_cred()               February 2005
-
-
-5.   Examples
-
-   The intended usage of GSS_Store_cred() is to make delegated
-   credentials available to child processes of GSS-API acceptor
-   applications.  Example pseudo-code:
-
-
-      /*
-       * <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE,
-       * an initiator name (hereafter, "src_name") and a delegated
-       * credential handle (hereafter "deleg_cred").>
-       *
-       * <"requested_username" is a username derived from the
-       * initiator name or explicitly requested by the initiator
-       * application.>
-       */
-      ...
-
-      if (authorize_gss_client(src_name, requested_username)) {
-         /*
-          * For Unix-type platforms this may mean calling setuid() and
-          * it may or may not also mean setting/unsetting such
-          * environment variables as KRB5CCNAME and what not.
-          */
-         if (change_user_context(requested_username))
-            (void) gss_store_creds(&minor_status, deleg_cred,
-   				GSS_C_INITIATE, actual_mech,
-   				0, 1, NULL, NULL);
-         }
-         else ...
-      }
-      else ...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires August 15, 2005                 [Page 8]
-
-Internet-Draft              GSS_Store_cred()               February 2005
-
-
-6.  Security considerations
-
-   Acceptor applications MUST only store delegated credentials into
-   appropriate credential stores and only after proper authorization of
-   the authenticated initiator principal to the requested service(s).
-
-   Acceptor applications that have no use for delegated credentials MUST
-   release them (such acceptor applications that use the GSS-API
-   C-Bindings may simply provide a NULL value for the
-   delegated_cred_handle argument to gss_accept_sec_context()).
-
-7  Normative
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires August 15, 2005                 [Page 9]
-
-Internet-Draft              GSS_Store_cred()               February 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                Expires August 15, 2005                [Page 10]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-01.txt b/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-01.txt
deleted file mode 100644
index 0327d8709..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-01.txt
+++ /dev/null
@@ -1,617 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: April 19, 2006                                 October 16, 2005
-
-
-          GSS-API Extension for Storing Delegated Credentials
-               draft-ietf-kitten-gssapi-store-cred-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document defines a new function for the GSS-API which allows
-   applications to store delegated (and other) credentials in the
-   implicit GSS-API credential store.  This is needed for GSS-API
-   applications to use delegated credentials as they would use other
-   credentials.
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 1]
-
-Internet-Draft              GSS_Store_cred()                October 2005
-
-
-Table of Contents
-
-   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . .  5
-   4.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  7
-   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Security considerations  . . . . . . . . . . . . . . . . . . .  9
-   7.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
-       Intellectual Property and Copyright Statements . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 2]
-
-Internet-Draft              GSS_Store_cred()                October 2005
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 3]
-
-Internet-Draft              GSS_Store_cred()                October 2005
-
-
-2.  Introduction
-
-   The GSS-API [RFC2743] clearly assumes that credentials exist in an
-   implicit store whence they can be acquired using GSS_Acquire_cred()
-   and GSS_Add_cred() or through use of the default credential.
-   Multiple credential stores may exist on a given host, but only one
-   store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
-   given time.
-
-   This assumption can be seen in sections 1.1.1.2 and 1.1.1.3 of
-   [RFC2743] as well as in section 3.5 of [RFC2744].
-
-   Note to the RFC editor: please remove this note before publication.]
-
-   Applications may be able to change the credential store from which
-   credentials can be acquired, either by changing user contexts (where
-   the applications have the privilege to do so) or by other means
-   (where a user may have multiple credential stores).
-
-   Some GSS-API acceptor applications always change user contexts, after
-   accepting a GSS-API security context and making appropriate
-   authorization checks, to the user context corresponding to the
-   initiator principal name or to a context requested by the initiator.
-   The means by which credential stores are managed are generally beyond
-   the scope of the GSS-API.
-
-   In the case of delegated credential handles however, such credentials
-   do not exist in the acceptor's credential store or in the credential
-   stores of the user contexts to which the acceptor application might
-   change - which is precisely the raison d'etre of credential
-   delegation.  But the GSS-API provides no mechanism by which delegated
-   credential handles can be made available for acquisition through
-   GSS_Acquire_cred()/GSS_Add_cred().  The GSS-API also does not provide
-   any credential import/export interfaces like the GSS-API context
-   import/export interfaces.
-
-   Thus acceptors are limited to making only direct use of delegated
-   credential handles and only with GSS_Init_sec_context(),
-   GSS_Inquire_cred*() and GSS_Release_cred().  This limitation is
-   particularly onerous on Unix systems where a call to exec() to
-   replace the process image obliterates the delegated credentials
-   handle.
-
-   In order to make delegated credentials generally as useful as
-   credentials that can be acquired with GSS_Acquire_cred() and
-   GSS_Add_cred() a primitive is needed which allows storing of
-   credentials in the implicit credential store.  This primitive we call
-   "GSS_Store_cred()."
-
-
-
-Williams                 Expires April 19, 2006                 [Page 4]
-
-Internet-Draft              GSS_Store_cred()                October 2005
-
-
-3.  GSS_Store_cred()
-
-   Inputs:
-
-   o  input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
-      NOT be GSS_C_NO_CREDENTIAL
-
-   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-      2=ACCEPT-ONLY
-
-   o  desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID then
-      store all the elements of the input_cred_handle, otherwise store
-      only the element of the corresponding mechanism
-
-   o  overwrite_cred BOOLEAN, -- if TRUE replace any credential for the
-      same principal in the credential store
-
-   o  default_cred BOOLEAN -- if TRUE make the stored credential
-      available as the default credential (for acquisition with
-      GSS_C_NO_NAME as the desired name or for use as
-      GSS_C_NO_CREDENTIAL)
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
-      mechanism OIDs for which credential elements were successfully
-      stored
-
-   o  cred_usage_stored INTEGER -- like cred_usage, but indicates what
-      kind of credential was stored (useful when the cred_usage input
-      parameter is set to INITIATE-AND-ACCEPT)
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the credentials were successfully
-      stored.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had
-      expired or expired before they could be stored.
-
-   o  GSS_S_NO_CRED indicates that no input credentials were given.
-
-   o  GSS_S_UNAVAILABLE indicates that the credential store is not
-      available.
-
-
-
-Williams                 Expires April 19, 2006                 [Page 5]
-
-Internet-Draft              GSS_Store_cred()                October 2005
-
-
-   o  GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
-      credential could not be stored because a credential for the same
-      principal exists in the current credential store and the
-      overwrite_cred input argument was FALSE.
-
-   o  GSS_S_FAILURE indicates that the credential could not be stored
-      for some other reason.  The minor status code may provide more
-      information if a non-GSS_C_NULL_OID desired_mech_element was
-      given.
-
-   GSS_Store_cred() is used to store, in the current credential store, a
-   given credential that has either been acquired from a different
-   credential store or been accepted as a delegated credential.
-
-   Specific mechanism elements of a credential can be stored one at a
-   time by specifying a non-GSS_C_NULL_OID mechanism OID as the
-   desired_mech_element input argument, in which case the minor status
-   output SHOULD have a mechanism-specific value when the major status
-   is not GSS_S_COMPLETE.
-
-   The initiator, acceptor or both usages of the input credential may be
-   stored as per the cred_usage input argument.
-
-   The credential elements that were actually stored, when the major
-   status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
-   and mech_elements_stored function outputs.
-
-   If credentials already exist in the current store for the principal
-   of the input_cred_handle, then those credentials are not replaced
-   with the input credentials unless the overwrite_cred input argument
-   is TRUE.
-
-   Finally, if the current credential store has no default credential
-   (that is, no credential that could be acquired for GSS_C_NO_NAME) or
-   if the default_cred input argument is TRUE, and the input credential
-   can be successfully stored, then the input credential will be
-   available for acquisition with GSS_C_NO_NAME as the desired name
-   input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as
-   GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(),
-   GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and
-   GSS_Accept_sec_context().
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 6]
-
-Internet-Draft              GSS_Store_cred()                October 2005
-
-
-4.  C-Bindings
-
-   The C-bindings for GSS_Store_cred() make use of types from and are
-   designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
-
-
-      OM_uint32 gss_store_cred(
-         OM_uint32         *minor_status,
-         gss_cred_id_t     input_cred,
-         gss_cred_usage_t  cred_usage,
-         const gss_OID     desired_mech,
-         OM_uint32         overwrite_cred,
-         OM_uint32         default_cred,
-         gss_OID_set       *elements_stored,
-         gss_cred_usage_t  *cred_usage_stored)
-
-
-   Figure 1
-
-   The two boolean arguments, 'overwrite_cred' and 'default_cred' are
-   typed as OM_uint32; 0 corresponds to FALSE, non-zero values
-   correspond to TRUE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 7]
-
-Internet-Draft              GSS_Store_cred()                October 2005
-
-
-5.   Examples
-
-   The intended usage of GSS_Store_cred() is to make delegated
-   credentials available to child processes of GSS-API acceptor
-   applications.  Example pseudo-code:
-
-
-      /*
-       * <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE,
-       * an initiator name (hereafter, "src_name") and a delegated
-       * credential handle (hereafter "deleg_cred").>
-       *
-       * <"requested_username" is a username derived from the
-       * initiator name or explicitly requested by the initiator
-       * application.>
-       */
-      ...
-
-      if (authorize_gss_client(src_name, requested_username)) {
-         /*
-          * For Unix-type platforms this may mean calling setuid() and
-          * it may or may not also mean setting/unsetting such
-          * environment variables as KRB5CCNAME and what not.
-          */
-         if (change_user_context(requested_username))
-            (void) gss_store_creds(&minor_status, deleg_cred,
-                                   GSS_C_INITIATE, actual_mech,
-                                   0, 1, NULL, NULL);
-         }
-         else ...
-      }
-      else ...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 8]
-
-Internet-Draft              GSS_Store_cred()                October 2005
-
-
-6.  Security considerations
-
-   Acceptor applications MUST only store delegated credentials into
-   appropriate credential stores and only after proper authorization of
-   the authenticated initiator principal to the requested service(s).
-
-   Acceptor applications that have no use for delegated credentials MUST
-   release them (such acceptor applications that use the GSS-API
-   C-Bindings may simply provide a NULL value for the
-   delegated_cred_handle argument to gss_accept_sec_context()).
-
-7.  Normative
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 9]
-
-Internet-Draft              GSS_Store_cred()                October 2005
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 10]
-
-Internet-Draft              GSS_Store_cred()                October 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 11]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-02.txt b/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-02.txt
deleted file mode 100644
index 80125f960..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-02.txt
+++ /dev/null
@@ -1,673 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Intended status: Informational                          October 19, 2006
-Expires: April 22, 2007
-
-
-          GSS-API Extension for Storing Delegated Credentials
-               draft-ietf-kitten-gssapi-store-cred-02.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 22, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 22, 2007                 [Page 1]
-
-Internet-Draft              GSS_Store_cred()                October 2006
-
-
-Abstract
-
-   This document defines a new function for the GSS-API which allows
-   applications to store delegated (and other) credentials in the
-   implicit GSS-API credential store.  This is needed for GSS-API
-   applications to use delegated credentials as they would use other
-   credentials.
-
-
-Table of Contents
-
-   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . .  5
-   4.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  7
-   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Security considerations  . . . . . . . . . . . . . . . . . . .  9
-   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
-       Intellectual Property and Copyright Statements . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 22, 2007                 [Page 2]
-
-Internet-Draft              GSS_Store_cred()                October 2006
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 22, 2007                 [Page 3]
-
-Internet-Draft              GSS_Store_cred()                October 2006
-
-
-2.  Introduction
-
-   The GSS-API [RFC2743] clearly assumes that credentials exist in an
-   implicit store whence they can be acquired using GSS_Acquire_cred()
-   and GSS_Add_cred() or through use of the default credential.
-   Multiple credential stores may exist on a given host, but only one
-   store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
-   given time.
-
-   This assumption can be seen in sections 1.1.1.2 and 1.1.1.3 of
-   [RFC2743] as well as in section 3.5 of [RFC2744].
-
-   Applications may be able to change the credential store from which
-   credentials can be acquired, either by changing user contexts (where
-   the applications have the privilege to do so) or by other means
-   (where a user may have multiple credential stores).
-
-   Some GSS-API acceptor applications always change user contexts, after
-   accepting a GSS-API security context and making appropriate
-   authorization checks, to the user context corresponding to the
-   initiator principal name or to a context requested by the initiator.
-   The means by which credential stores are managed are generally beyond
-   the scope of the GSS-API.
-
-   In the case of delegated credential handles however, such credentials
-   do not exist in the acceptor's credential store or in the credential
-   stores of the user contexts to which the acceptor application might
-   change.  The GSS-API provides no mechanism by which delegated
-   credential handles can be made available for acquisition through
-   GSS_Acquire_cred()/GSS_Add_cred().  The GSS-API also does not provide
-   any credential import/export interfaces like the GSS-API context
-   import/export interfaces.
-
-   Thus acceptors are limited to making only direct use of delegated
-   credential handles and only with GSS_Init_sec_context(),
-   GSS_Inquire_cred*() and GSS_Release_cred().  This limitation is
-   particularly onerous on Unix systems where a call to exec() to
-   replace the process image obliterates any delegated credentials
-   handle that may exist in that process.
-
-   In order to make delegated credentials generally as useful as
-   credentials that can be acquired with GSS_Acquire_cred() and
-   GSS_Add_cred() a primitive is needed which allows storing of
-   credentials in the implicit credential store.  This primitive we call
-   "GSS_Store_cred()."
-
-
-
-
-
-
-Williams                 Expires April 22, 2007                 [Page 4]
-
-Internet-Draft              GSS_Store_cred()                October 2006
-
-
-3.  GSS_Store_cred()
-
-   Inputs:
-
-   o  input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
-      NOT be GSS_C_NO_CREDENTIAL
-
-   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-      2=ACCEPT-ONLY
-
-   o  desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID then
-      store all the elements of the input_cred_handle, otherwise store
-      only the element of the corresponding mechanism
-
-   o  overwrite_cred BOOLEAN, -- if TRUE replace any credential for the
-      same principal in the credential store
-
-   o  default_cred BOOLEAN -- if TRUE make the stored credential
-      available as the default credential (for acquisition with
-      GSS_C_NO_NAME as the desired name or for use as
-      GSS_C_NO_CREDENTIAL)
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
-      mechanism OIDs for which credential elements were successfully
-      stored
-
-   o  cred_usage_stored INTEGER -- like cred_usage, but indicates what
-      kind of credential was stored (useful when the cred_usage input
-      parameter is set to INITIATE-AND-ACCEPT)
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the credentials were successfully
-      stored.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had
-      expired or expired before they could be stored.
-
-   o  GSS_S_NO_CRED indicates that no input credentials were given.
-
-   o  GSS_S_UNAVAILABLE indicates that the credential store is not
-      available.
-
-
-
-Williams                 Expires April 22, 2007                 [Page 5]
-
-Internet-Draft              GSS_Store_cred()                October 2006
-
-
-   o  GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
-      credential could not be stored because a credential for the same
-      principal exists in the current credential store and the
-      overwrite_cred input argument was FALSE.
-
-   o  GSS_S_FAILURE indicates that the credential could not be stored
-      for some other reason.  The minor status code may provide more
-      information if a non-GSS_C_NULL_OID desired_mech_element was
-      given.
-
-   GSS_Store_cred() is used to store, in the current credential store, a
-   given credential that has either been acquired from a different
-   credential store or been accepted as a delegated credential.
-
-   Specific mechanism elements of a credential can be stored one at a
-   time by specifying a non-GSS_C_NULL_OID mechanism OID as the
-   desired_mech_element input argument, in which case the minor status
-   output SHOULD have a mechanism-specific value when the major status
-   is not GSS_S_COMPLETE.
-
-   The initiator, acceptor or both usages of the input credential may be
-   stored as per the cred_usage input argument.
-
-   The credential elements that were actually stored, when the major
-   status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
-   and mech_elements_stored function outputs.
-
-   If credentials already exist in the current store for the principal
-   of the input_cred_handle, then those credentials are not replaced
-   with the input credentials unless the overwrite_cred input argument
-   is TRUE.
-
-   Finally, if the current credential store has no default credential
-   (that is, no credential that could be acquired for GSS_C_NO_NAME) or
-   if the default_cred input argument is TRUE, and the input credential
-   can be successfully stored, then the input credential will be
-   available for acquisition with GSS_C_NO_NAME as the desired name
-   input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as
-   GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(),
-   GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and
-   GSS_Accept_sec_context().
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 22, 2007                 [Page 6]
-
-Internet-Draft              GSS_Store_cred()                October 2006
-
-
-4.  C-Bindings
-
-   The C-bindings for GSS_Store_cred() make use of types from and are
-   designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
-
-
-      OM_uint32 gss_store_cred(
-         OM_uint32         *minor_status,
-         gss_cred_id_t     input_cred_handle,
-         gss_cred_usage_t  cred_usage,
-         const gss_OID     desired_mech,
-         OM_uint32         overwrite_cred,
-         OM_uint32         default_cred,
-         gss_OID_set       *elements_stored,
-         gss_cred_usage_t  *cred_usage_stored)
-
-
-                                 Figure 1
-
-   The two boolean arguments, 'overwrite_cred' and 'default_cred' are
-   typed as OM_uint32; 0 corresponds to FALSE, non-zero values
-   correspond to TRUE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 22, 2007                 [Page 7]
-
-Internet-Draft              GSS_Store_cred()                October 2006
-
-
-5.  Examples
-
-   The intended usage of GSS_Store_cred() is to make delegated
-   credentials available to child processes of GSS-API acceptor
-   applications.  Example pseudo-code:
-
-
-      /*
-       * <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE,
-       * an initiator name (hereafter, "src_name") and a delegated
-       * credential handle (hereafter "deleg_cred").>
-       *
-       * <"requested_username" is a username derived from the
-       * initiator name or explicitly requested by the initiator
-       * application.>
-       */
-      ...
-
-      if (authorize_gss_client(src_name, requested_username)) {
-         /*
-          * For Unix-type platforms this may mean calling setuid() and
-          * it may or may not also mean setting/unsetting such
-          * environment variables as KRB5CCNAME and what not -- all
-          * OS-specific details.
-          */
-         if (change_user_context(requested_username))
-            (void) gss_store_creds(&minor_status, deleg_cred,
-                                   GSS_C_INITIATE, actual_mech,
-                                   0, 1, NULL, NULL);
-         }
-         else ...
-      }
-      else ...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 22, 2007                 [Page 8]
-
-Internet-Draft              GSS_Store_cred()                October 2006
-
-
-6.  Security considerations
-
-   Acceptor applications MUST only store delegated credentials into
-   appropriate credential stores and only after proper authorization of
-   the authenticated initiator principal to the requested service(s).
-
-   Acceptor applications that have no use for delegated credentials MUST
-   release them (such acceptor applications that use the GSS-API
-   C-Bindings may simply provide a NULL value for the
-   delegated_cred_handle argument to gss_accept_sec_context()).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 22, 2007                 [Page 9]
-
-Internet-Draft              GSS_Store_cred()                October 2006
-
-
-7.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 22, 2007                [Page 10]
-
-Internet-Draft              GSS_Store_cred()                October 2006
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 22, 2007                [Page 11]
-
-Internet-Draft              GSS_Store_cred()                October 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Williams                 Expires April 22, 2007                [Page 12]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-00.txt b/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-00.txt
deleted file mode 100644
index 98da42e87..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-00.txt
+++ /dev/null
@@ -1,1121 +0,0 @@
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: July 26, 2005                                  January 25, 2005
-
-
-                         Guide to the GSS-APIv3
-              draft-ietf-kitten-gssapi-v3-guide-to-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on July 26, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).  All Rights Reserved.
-
-Abstract
-
-   Extensions to the GSS-APIv2 are needed for a number of reasons.  This
-   documents describes the extensions being proposed, the resons,
-   possible future directions, and portability, IANA and security
-   considerations.  This document does not define any protocol or
-   interface and is purely informational.
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                  [Page 1]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-Table of Contents
-
-   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  A Pseudo-Mechanism OID for the GSS-API Itself  . . . . . . . .  5
-   4.  Mechanism Attribute Inquiry Facilities . . . . . . . . . . . .  6
-   5.  Security Context Extensibility Extensions  . . . . . . . . . .  7
-   6.  Credential Extensibility Extensions  . . . . . . . . . . . . .  8
-   7.  Credential Export/Import . . . . . . . . . . . . . . . . . . .  9
-   8.  GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 10
-   9.  Pseudo-Mechanism Stacking  . . . . . . . . . . . . . . . . . . 11
-   10. Naming Extensions  . . . . . . . . . . . . . . . . . . . . . . 12
-   11. Additional Name Types  . . . . . . . . . . . . . . . . . . . . 13
-   12. GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . . 14
-   13. Channel Bindings Specifications  . . . . . . . . . . . . . . . 15
-   14. Semantic and Miscallaneous Extensions  . . . . . . . . . . . . 16
-   15. Portability Considerations . . . . . . . . . . . . . . . . . . 17
-   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
-   17. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
-   18. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
-       Intellectual Property and Copyright Statements . . . . . . . . 20
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                  [Page 2]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                  [Page 3]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-2.  Introduction
-
-   [NOTE: the references section is current fairly empty; the various
-   KITTEN WG work items will be added to this I-D in a subsequent
-   revision.]
-
-   Since the advent of the GSS-APIv2 it has come to be used in a number
-   of Internet (and other) protocols and a number of implementations
-   exist.  In that time implementors and protocol designers have come to
-   understand both, the GSS-API's strengths, and its shortcommings; we
-   believe now that a number of extensions to the GSS-API are needed.
-   Here these proposed extensions, forming what we may call the GSS-API
-   version 3, are described at a high-level.;
-
-   Some of these extensions are intended to facilitate further
-   extensions, so that further major revisions to the GSS-API may not be
-   necessary.  Others are intended to fill voids in the the GSS-APIv2.
-
-   The extensions being proposed are:
-      A pseudo-mechanism OID for the GSS-API itself
-      Mechanism attribute inquiry facilities
-      Security context extensibility extensions
-      Credential extensibility extensions
-      Credential export/import
-      GSS_Store_cred(), for making delegated credentials available for
-      acquisition
-      Pseudo-mechanism stacking
-      Naming extensions, to facilitate authorization by identifiers
-      other than names
-      Additional name types, specifically domain-based naming
-      A pseudo-random function interface
-      Channel bindings specifications
-      Semantic extensions relating to thread- and/or fork-safety
-      [Have I missed anything?  I have a feeling I have.  Re-keying?]
-      ...
-
-   Additionally, because we foresee future minor extensions, including,
-   specifically, extensions which may impact the various namespaces
-   associated with APIs (symbol names, constant values, class names,
-   etc...) we also propose the establishment of IANA registries for
-   these namespaces.
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                  [Page 4]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-3.  A Pseudo-Mechanism OID for the GSS-API Itself
-
-   A mechanism OID is assigned to identify and refer to the GSS-API
-   iself.  This is necessary to enable the use of extended inquiry
-   interfaces to inquire about features of a GSS-API implementation
-   specifically, apart from actual mechanisms.
-
-   But also, this OID is needed for better error handling, so that minor
-   status codes produced in generic contexts that lack a mechanism OID
-   can be distinguished from minor status codes for a "default"
-   mechanism and properly displayed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                  [Page 5]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-4.  Mechanism Attribute Inquiry Facilities
-
-   In the course of designing a pseudo-mechanism stacking facility, as
-   well as while considering the impact of all of these extensions on
-   portability, a need for interfaces through which to discover or
-   inquire by features provided by GSS-API mechanisms was discovered.
-
-   The proposed mechanism attribute inquiry interfaces consist of:
-      GSS_Inquire_mech_attrs_for_mech()
-      GSS_Indicate_mechs_by_mech_attrs()
-      GSS_Display_mech_attr()
-
-   These extensions facilitate portability by allowing GSS-APIv3
-   applications to discover the features provided by a given
-   implementation of the GSS-API or any mechanisms.  These extensions
-   are also useful in facilitating stackable pseudo-mechanisms.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                  [Page 6]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-5.  Security Context Extensibility Extensions
-
-   In order to facilitate future security context options we introduce a
-   GSS_Create_sec_context() interface that creates a security context
-   object, for use with extensions and with GSS_Init_sec_context(),
-   GSS_Accept_sec_context(), and GSS_Inquire_sec_context().  Such
-   security contexts are in a non-established state until they are
-   established through the use of GSS_Init_sec_context() or
-   GSS_Accept_sec_context().
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                  [Page 7]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-6.  Credential Extensibility Extensions
-
-   In order to facilitate future extensions to GSS credentials we
-   introduce a GSS_Create_credential(), similar to
-   GSS_Create_sec_context(), interface that creates an "empty"
-   credential.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                  [Page 8]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-7.  Credential Export/Import
-
-   To allow for passing of credentials between different "session
-   contexts," between different hosts, or for storage of post-dated
-   credentials, we introduce a credential export/import facility, much
-   like the security context export/import facility of the GSS-APIv2.
-
-   Together with credential extensibility and other extensions this
-   facility may allow for:
-      Credential delegation at any time
-      Post-dated credentials, and storage of the such for subsequent
-      use.
-      ...?
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                  [Page 9]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-8.  GSS_Store_cred()
-
-   This extension fills a void in the GSS-APIv2 where delegated
-   credentials could not be used except in the context of the same
-   process that received them.  With this extension acceptor
-   applications can now make delegated credentials available for use,
-   with GSS_Acquire_cred() et.  al., in other process contexts.
-
-   [Manipulation of "credential stores" is (may be?) out of scope for
-   this document.]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                 [Page 10]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-9.  Pseudo-Mechanism Stacking
-
-   A number of pseudo-mechanisms are being proposed which are designed
-   to "stack" atop other mechanisms.  The possiblities are many,
-   including: a compression mechanism, a perfect forward security
-   mechanism, an many others.
-
-   The GSS-APIv2 only had concrete mechanisms and one pseudo-mechanism
-   (SPNEGO) available.  With this proposal the mechanism taxonomy is
-   quite expanded:
-      Concrete mechanisms (e.g., the Kerberos V mechanism)
-      Composite mechanisms (a concrete mechanism composed with one or
-      more stackable pseudo-mechanisms)
-      Stackable pseudo-mechanisms
-      Other pseudo-mechanisms (e.g., SPNEGO, the GSS-API itself)
-
-   Although composed mechanisms may be made available for use by
-   GSS-APIv2 applications without any further extensions, use of
-   stackable pseudo-mechanisms can complicate mechanism negotiation;
-   additionally, discovery of mechanisms appropriate for use in one or
-   another context would require hard-coding information about them in
-   GSS-APIv2 applications.  Extensions to the GSS-APIv2 could facilitate
-   use of composite.
-
-   The mechanism attribute inquiry facilities, together with the
-   forllowing additional interfaces, provide for a complete interface to
-   mechanism composition and for managing the complexity of mechanism
-   negotiation:
-      GSS_Compose_oid()
-      GSS_Decompose_oid()
-      GSS_Release_oid()
-      GSS_Indicate_negotiable_mechs()
-      GSS_Negotiate_mechs()
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                 [Page 11]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-10.  Naming Extensions
-
-   Some applications make use of exported names, as produced by
-   GSS_Export_name(), to create/manage/evaluate access control lists; we
-   call this name-based authorization.
-
-   Exported names typically encode names that are meant for display to
-   humans, not internal identifiers.
-
-   In practice this creates a number of problems.  E.g., the referential
-   integrity of such access control lists is hard to maintain as
-   principals are added, removed, renamed or old principal names reused.
-
-   Additionally, some mechanisms may lack a notion of a "canonical" name
-   for some or all of their principals.  Such mechanisms cannot be used
-   by applications that rely on name-based authorization.
-
-   <Describe the proposed extensions in this area.>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                 [Page 12]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-11.  Additional Name Types
-
-   <Decribe domain-based names and the need for them.>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                 [Page 13]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-12.  GSS_Pseudo_random()
-
-   <Decribe GSS_Pseudo_random() and the need for it.>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                 [Page 14]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-13.  Channel Bindings Specifications
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                 [Page 15]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-14.  Semantic and Miscallaneous Extensions
-
-   The GSS-APIv2 specifications say nothing about the thread-safety,
-   much less the fork-safety, of the GSS-API.  Thread-safety and
-   fork-safety are, after all, platform- and/or language-specific
-   matters.  But as support for multi-threading spreads the matter of
-   thread-safety cannot be avoided.  The matter of fork-safety is
-   specific to platforms that provide a "fork()" function, or similar.
-
-   <describe the GSS-APIv3's thread-safety requirements>
-
-   <reference the portability considerations section>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                 [Page 16]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-15.  Portability Considerations
-
-   The potential for additional generic, mechanism-specific, language
-   binding-specific and, most importantly, semantic extensions to the
-   GSS-APIv3 may create application portability problems.  The mechanism
-   attribute inquiry facilities of the GSS-APIv3 and the
-   pseudo-mechanism OID for the GSS-API itself double as a run-time
-   facility for discovery of feature availability.  Run-time feature
-   discovery facilities, in turn, can be used at application build-time
-   as well by building small applications to display the available
-   features.
-
-   <...>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                 [Page 17]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-16.  IANA Considerations
-
-   <Describe the namespace issues associated with future minor
-   extensions to the GSS-APIv3 and the IANA registries to be created to
-   cope with them.>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                 [Page 18]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-17.  Security Considerations
-
-   <...>
-
-18  Normative
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires July 26, 2005                 [Page 19]
-
-Internet-Draft           Guide to the GSS-APIv3             January 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                 Expires July 26, 2005                 [Page 20]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-01.txt b/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-01.txt
deleted file mode 100644
index b3b94a1d9..000000000
--- a/doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-01.txt
+++ /dev/null
@@ -1,1233 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: April 19, 2006                                 October 16, 2005
-
-
-                         Guide to the GSS-APIv3
-              draft-ietf-kitten-gssapi-v3-guide-to-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   Extensions to the GSS-APIv2 are needed for a number of reasons.  This
-   documents describes the extensions being proposed, the resons,
-   possible future directions, and portability, IANA and security
-   considerations.  This document does not define any protocol or
-   interface and is purely informational.
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 1]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-Table of Contents
-
-   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  A Pseudo-Mechanism OID for the GSS-API Itself  . . . . . . . .  6
-   4.  Mechanism Attribute Inquiry Facilities . . . . . . . . . . . .  7
-   5.  Security Context Extensibility Extensions  . . . . . . . . . .  8
-   6.  Credential Extensibility Extensions  . . . . . . . . . . . . .  9
-   7.  Credential Export/Import . . . . . . . . . . . . . . . . . . . 10
-   8.  GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 11
-   9.  Pseudo-Mechanism Stacking  . . . . . . . . . . . . . . . . . . 12
-   10. Naming Extensions  . . . . . . . . . . . . . . . . . . . . . . 13
-   11. Additional Name Types  . . . . . . . . . . . . . . . . . . . . 14
-   12. GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . . 15
-   13. Channel Bindings Specifications  . . . . . . . . . . . . . . . 16
-   14. Semantic and Miscallaneous Extensions  . . . . . . . . . . . . 17
-   15. Portability Considerations . . . . . . . . . . . . . . . . . . 18
-   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
-   17. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
-   18. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . 20
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
-       Intellectual Property and Copyright Statements . . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 2]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 3]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-2.  Introduction
-
-   [NOTE: the references section is current fairly empty; the various
-   KITTEN WG work items will be added to this I-D in a subsequent
-   revision.]
-
-   Since the advent of the GSS-APIv2 it has come to be used in a number
-   of Internet (and other) protocols and a number of implementations
-   exist.  In that time implementors and protocol designers have come to
-   understand both, the GSS-API's strengths, and its shortcommings; we
-   believe now that a number of extensions to the GSS-API are needed.
-   Here these proposed extensions, forming what we may call the GSS-API
-   version 3, are described at a high-level.;
-
-   Some of these extensions are intended to facilitate further
-   extensions, so that further major revisions to the GSS-API may not be
-   necessary.  Others are intended to fill voids in the the GSS-APIv2.
-
-   The extensions being proposed are:
-
-      A pseudo-mechanism OID for the GSS-API itself
-
-      Mechanism attribute inquiry facilities
-
-      Security context extensibility extensions
-
-      Credential extensibility extensions
-
-      Credential export/import
-
-      GSS_Store_cred(), for making delegated credentials available for
-      acquisition
-
-      Pseudo-mechanism stacking
-
-      Naming extensions, to facilitate authorization by identifiers
-      other than names
-
-      Additional name types, specifically domain-based naming
-
-      A pseudo-random function interface
-
-      Channel bindings specifications
-
-      Semantic extensions relating to thread- and/or fork-safety
-
-      [Have I missed anything?  I have a feeling I have.  Re-keying?]
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 4]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-      ...
-
-   Additionally, because we foresee future minor extensions, including,
-   specifically, extensions which may impact the various namespaces
-   associated with APIs (symbol names, constant values, class names,
-   etc...) we also propose the establishment of IANA registries for
-   these namespaces.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 5]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-3.  A Pseudo-Mechanism OID for the GSS-API Itself
-
-   A mechanism OID is assigned to identify and refer to the GSS-API
-   iself.  This is necessary to enable the use of extended inquiry
-   interfaces to inquire about features of a GSS-API implementation
-   specifically, apart from actual mechanisms.
-
-   But also, this OID is needed for better error handling, so that minor
-   status codes produced in generic contexts that lack a mechanism OID
-   can be distinguished from minor status codes for a "default"
-   mechanism and properly displayed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 6]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-4.  Mechanism Attribute Inquiry Facilities
-
-   In the course of designing a pseudo-mechanism stacking facility, as
-   well as while considering the impact of all of these extensions on
-   portability, a need for interfaces through which to discover or
-   inquire by features provided by GSS-API mechanisms was discovered.
-
-   The proposed mechanism attribute inquiry interfaces consist of:
-
-      GSS_Inquire_mech_attrs_for_mech()
-
-      GSS_Indicate_mechs_by_mech_attrs()
-
-      GSS_Display_mech_attr()
-
-   These extensions facilitate portability by allowing GSS-APIv3
-   applications to discover the features provided by a given
-   implementation of the GSS-API or any mechanisms.  These extensions
-   are also useful in facilitating stackable pseudo-mechanisms.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 7]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-5.  Security Context Extensibility Extensions
-
-   In order to facilitate future security context options we introduce a
-   GSS_Create_sec_context() interface that creates a security context
-   object, for use with extensions and with GSS_Init_sec_context(),
-   GSS_Accept_sec_context(), and GSS_Inquire_sec_context().  Such
-   security contexts are in a non-established state until they are
-   established through the use of GSS_Init_sec_context() or
-   GSS_Accept_sec_context().
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 8]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-6.  Credential Extensibility Extensions
-
-   In order to facilitate future extensions to GSS credentials we
-   introduce a GSS_Create_credential(), similar to
-   GSS_Create_sec_context(), interface that creates an "empty"
-   credential.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 9]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-7.  Credential Export/Import
-
-   To allow for passing of credentials between different "session
-   contexts," between different hosts, or for storage of post-dated
-   credentials, we introduce a credential export/import facility, much
-   like the security context export/import facility of the GSS-APIv2.
-
-   Together with credential extensibility and other extensions this
-   facility may allow for:
-
-      Credential delegation at any time
-
-      Post-dated credentials, and storage of the such for subsequent
-      use.
-
-      ...?
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 10]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-8.  GSS_Store_cred()
-
-   This extension fills a void in the GSS-APIv2 where delegated
-   credentials could not be used except in the context of the same
-   process that received them.  With this extension acceptor
-   applications can now make delegated credentials available for use,
-   with GSS_Acquire_cred() et. al., in other process contexts.
-
-   [Manipulation of "credential stores" is (may be?) out of scope for
-   this document.]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 11]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-9.  Pseudo-Mechanism Stacking
-
-   A number of pseudo-mechanisms are being proposed which are designed
-   to "stack" atop other mechanisms.  The possiblities are many,
-   including: a compression mechanism, a perfect forward security
-   mechanism, an many others.
-
-   The GSS-APIv2 only had concrete mechanisms and one pseudo-mechanism
-   (SPNEGO) available.  With this proposal the mechanism taxonomy is
-   quite expanded:
-
-      Concrete mechanisms (e.g., the Kerberos V mechanism)
-
-      Composite mechanisms (a concrete mechanism composed with one or
-      more stackable pseudo-mechanisms)
-
-      Stackable pseudo-mechanisms
-
-      Other pseudo-mechanisms (e.g., SPNEGO, the GSS-API itself)
-
-   Although composed mechanisms may be made available for use by GSS-
-   APIv2 applications without any further extensions, use of stackable
-   pseudo-mechanisms can complicate mechanism negotiation; additionally,
-   discovery of mechanisms appropriate for use in one or another context
-   would require hard-coding information about them in GSS-APIv2
-   applications.  Extensions to the GSS-APIv2 could facilitate use of
-   composite.
-
-   The mechanism attribute inquiry facilities, together with the
-   forllowing additional interfaces, provide for a complete interface to
-   mechanism composition and for managing the complexity of mechanism
-   negotiation:
-
-      GSS_Compose_oid()
-
-      GSS_Decompose_oid()
-
-      GSS_Release_oid()
-
-      GSS_Indicate_negotiable_mechs()
-
-      GSS_Negotiate_mechs()
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 12]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-10.  Naming Extensions
-
-   Some applications make use of exported names, as produced by
-   GSS_Export_name(), to create/manage/evaluate access control lists; we
-   call this name-based authorization.
-
-   Exported names typically encode names that are meant for display to
-   humans, not internal identifiers.
-
-   In practice this creates a number of problems.  E.g., the referential
-   integrity of such access control lists is hard to maintain as
-   principals are added, removed, renamed or old principal names reused.
-
-   Additionally, some mechanisms may lack a notion of a "canonical" name
-   for some or all of their principals.  Such mechanisms cannot be used
-   by applications that rely on name-based authorization.
-
-   <Describe the proposed extensions in this area.>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 13]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-11.  Additional Name Types
-
-   <Decribe domain-based names and the need for them.>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 14]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-12.  GSS_Pseudo_random()
-
-   <Decribe GSS_Pseudo_random() and the need for it.>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 15]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-13.  Channel Bindings Specifications
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 16]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-14.  Semantic and Miscallaneous Extensions
-
-   The GSS-APIv2 specifications say nothing about the thread-safety,
-   much less the fork-safety, of the GSS-API.  Thread-safety and fork-
-   safety are, after all, platform- and/or language-specific matters.
-   But as support for multi-threading spreads the matter of thread-
-   safety cannot be avoided.  The matter of fork-safety is specific to
-   platforms that provide a "fork()" function, or similar.
-
-   <describe the GSS-APIv3's thread-safety requirements>
-
-   <reference the portability considerations section>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 17]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-15.  Portability Considerations
-
-   The potential for additional generic, mechanism-specific, language
-   binding-specific and, most importantly, semantic extensions to the
-   GSS-APIv3 may create application portability problems.  The mechanism
-   attribute inquiry facilities of the GSS-APIv3 and the pseudo-
-   mechanism OID for the GSS-API itself double as a run-time facility
-   for discovery of feature availability.  Run-time feature discovery
-   facilities, in turn, can be used at application build-time as well by
-   building small applications to display the available features.
-
-   <...>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 18]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-16.  IANA Considerations
-
-   <Describe the namespace issues associated with future minor
-   extensions to the GSS-APIv3 and the IANA registries to be created to
-   cope with them.>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 19]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-17.  Security Considerations
-
-   <...>
-
-18.  Normative
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 20]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 21]
-
-Internet-Draft           Guide to the GSS-APIv3             October 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 22]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-01.txt b/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-01.txt
deleted file mode 100644
index a15914721..000000000
--- a/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-01.txt
+++ /dev/null
@@ -1,393 +0,0 @@
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: December 30, 2004                                     July 2004
-
-
-               A PRF for the Kerberos V GSS-API Mechanism
-                draft-ietf-kitten-krb5-gssapi-prf-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on December 30, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This document defines the Pseudo-Random Function (PRF) for the
-   Kerberos V mechanism for the Generic Security Service Application
-   Programming Interface (GSS-API), based on the PRF defined for the
-   Kerberos V cryptographic framework, for keying application protocols
-   given an established Kerberos V GSS-API security context.
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 1]
-
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-Table of Contents
-
-   1. Conventions used in this document  . . . . . . . . . . . . . . . 3
-   2. Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . . . 4
-   3. Security Considerations  . . . . . . . . . . . . . . . . . . . . 5
-   4. Normative References . . . . . . . . . . . . . . . . . . . . . . 5
-      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
-      Intellectual Property and Copyright Statements . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 2]
-
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 3]
-
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-2.  Kerberos V GSS Mechanism PRF
-
-   The GSS-API PRF [GSS-PRF] function for the Kerberos V mechanism [CFX]
-   shall be the output of a PRF+ function based on the enctype's PRF
-   function keyed with the negotiated session key of the security
-   context and key usage X (TBD).
-
-   The security context MUST be fully established, else the mechanism
-   MUST fail with GSS_S_FAILURE as the major status code and
-   GSS_KRB5_S_KG_CTX_INCOMPLETE as the minor status code.
-
-   This PRF+ MUST be keyed with a key derived, with key usage (TBD),
-   from the session used by the initiator and acceptor, after the
-   security context is fully established, to derive keys for per-message
-   tokens.  For the current Kerberos V mechanism [CFX] this means that
-   the PRF+ MUST be keyed with the acceptor-asserted subkey, if it did
-   assert such a key, or the initiator's sub-session key otherwise.
-
-   The PRF+ function is a simple counter-based extension of the Kerberos
-   V pseudo-random function [KRB5-CRYPTO] for the enctype of the
-   security context's keys:
-
-   	PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
-
-   	Tn = pseudo-random-function(K, n || S)
-
-   	where '||' is the concatenation operator, 'n' is encoded as a
-   	network byte order 32-bit unsigned binary number, and where
-   	truncate(L, S) truncates the input octet string S to length L.
-
-   The maximum output size of the Kerberos V mechanism's GSS-API PRF
-   then is, necessarily, 2^32 octets.
-
-   Implementations MUST support output size of up to 2^14 octets at
-   least.
-
-   If the implementation cannot produce the desired output then it MUST
-   output what it can.
-
-   The minimum input octet string length that implementations MUST
-   support is also 2^14 octets.  If the input octet string is longer
-   than the maximum that an implementation can process then the
-   implementation MUST fail with GSS_S_FAILURE as the major status code
-   and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status code.
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 4]
-
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-3.  Security Considerations
-
-   Kerberos V enctypes' PRF functions use a key derived from contexts'
-   session keys and should preserve the forward security properties of
-   the mechanisms' key exchanges.
-
-   Legacy Kerberos V enctypes may be weak, particularly the single-DES
-   enctypes.
-
-   See also [GSS-PRF] for generic security considerations of
-   GSS_Pseudo_random().
-
-   The computational cost of computing this PRF+ may vary depending on
-   the Kerberos V enctypes being used, but generally the computation of
-   this PRF+ gets more expensive as the input and output octet string
-   lengths grow (note that the use of a counter in the PRF+ construction
-   allows for parallelization).  This means that if an application can
-   be tricked into providing very large input octet strings and
-   requesting very long output octet strings then that may constitue a
-   denial of service attack on the application; therefore applications
-   SHOULD place appropriate limits on the size of any input octet
-   strings received from their peers without integrity protection.
-
-4  Normative References
-
-   [CFX]      Zhu, L., Jaganathan, K. and S. Hartman, "The Kerberos
-              Version 5 GSS-API Mechanism: Version 2".
-
-   [GSS-PRF]  Williams, N., "A PRF API extension for the GSS-API".
-
-   [KRB5-CRYPTO]
-              Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5".
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-
-
-
-Williams               Expires December 30, 2004                [Page 5]
-
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 6]
-
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams               Expires December 30, 2004                [Page 7]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-02.txt b/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-02.txt
deleted file mode 100644
index 6521f9875..000000000
--- a/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-02.txt
+++ /dev/null
@@ -1,393 +0,0 @@
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: December 30, 2004                                     July 2004
-
-
-               A PRF for the Kerberos V GSS-API Mechanism
-                draft-ietf-kitten-krb5-gssapi-prf-02.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on December 30, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This document defines the Pseudo-Random Function (PRF) for the
-   Kerberos V mechanism for the Generic Security Service Application
-   Programming Interface (GSS-API), based on the PRF defined for the
-   Kerberos V cryptographic framework, for keying application protocols
-   given an established Kerberos V GSS-API security context.
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 1]
-
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-Table of Contents
-
-   1. Conventions used in this document  . . . . . . . . . . . . . . . 3
-   2. Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . . . 4
-   3. Security Considerations  . . . . . . . . . . . . . . . . . . . . 5
-   4. Normative References . . . . . . . . . . . . . . . . . . . . . . 5
-      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
-      Intellectual Property and Copyright Statements . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 2]
-
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 3]
-
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-2.  Kerberos V GSS Mechanism PRF
-
-   The GSS-API PRF [GSS-PRF] function for the Kerberos V mechanism [CFX]
-   shall be the output of a PRF+ function based on the enctype's PRF
-   function keyed with the negotiated session key of the security
-   context and key usage X (TBD).
-
-   The security context MUST be fully established, else the mechanism
-   MUST fail with GSS_S_UNAVAILABLE as the major status code and
-   GSS_KRB5_S_KG_CTX_INCOMPLETE as the minor status code.
-
-   This PRF+ MUST be keyed with a key derived, with key usage (TBD),
-   from the session used by the initiator and acceptor, after the
-   security context is fully established, to derive keys for per-message
-   tokens.  For the current Kerberos V mechanism [CFX] this means that
-   the PRF+ MUST be keyed with the acceptor-asserted subkey, if it did
-   assert such a key, or the initiator's sub-session key otherwise.
-
-   The PRF+ function is a simple counter-based extension of the Kerberos
-   V pseudo-random function [KRB5-CRYPTO] for the enctype of the
-   security context's keys:
-
-   	PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
-
-   	Tn = pseudo-random-function(K, n || S)
-
-   	where '||' is the concatenation operator, 'n' is encoded as a
-   	network byte order 32-bit unsigned binary number, and where
-   	truncate(L, S) truncates the input octet string S to length L.
-
-   The maximum output size of the Kerberos V mechanism's GSS-API PRF
-   then is, necessarily, 2^32 octets.
-
-   Implementations MUST support output size of up to 2^14 octets at
-   least.
-
-   If the implementation cannot produce the desired output then it MUST
-   output what it can.
-
-   The minimum input octet string length that implementations MUST
-   support is also 2^14 octets.  If the input octet string is longer
-   than the maximum that an implementation can process then the
-   implementation MUST fail with GSS_S_FAILURE as the major status code
-   and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status code.
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 4]
-
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-3.  Security Considerations
-
-   Kerberos V enctypes' PRF functions use a key derived from contexts'
-   session keys and should preserve the forward security properties of
-   the mechanisms' key exchanges.
-
-   Legacy Kerberos V enctypes may be weak, particularly the single-DES
-   enctypes.
-
-   See also [GSS-PRF] for generic security considerations of
-   GSS_Pseudo_random().
-
-   The computational cost of computing this PRF+ may vary depending on
-   the Kerberos V enctypes being used, but generally the computation of
-   this PRF+ gets more expensive as the input and output octet string
-   lengths grow (note that the use of a counter in the PRF+ construction
-   allows for parallelization).  This means that if an application can
-   be tricked into providing very large input octet strings and
-   requesting very long output octet strings then that may constitue a
-   denial of service attack on the application; therefore applications
-   SHOULD place appropriate limits on the size of any input octet
-   strings received from their peers without integrity protection.
-
-4  Normative References
-
-   [CFX]      Zhu, L., Jaganathan, K. and S. Hartman, "The Kerberos
-              Version 5 GSS-API Mechanism: Version 2".
-
-   [GSS-PRF]  Williams, N., "A PRF API extension for the GSS-API".
-
-   [KRB5-CRYPTO]
-              Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5".
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-
-
-
-Williams               Expires December 30, 2004                [Page 5]
-
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 6]
-
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams               Expires December 30, 2004                [Page 7]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-03.txt b/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-03.txt
deleted file mode 100644
index b943e1672..000000000
--- a/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-03.txt
+++ /dev/null
@@ -1,334 +0,0 @@
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: November 13, 2005                                  May 12, 2005
-
-
-               A PRF for the Kerberos V GSS-API Mechanism
-                draft-ietf-kitten-krb5-gssapi-prf-03.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on November 13, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document defines the Pseudo-Random Function (PRF) for the
-   Kerberos V mechanism for the Generic Security Service Application
-   Programming Interface (GSS-API), based on the PRF defined for the
-   Kerberos V cryptographic framework, for keying application protocols
-   given an established Kerberos V GSS-API security context.
-
-
-
-
-
-
-
-Williams                Expires November 13, 2005               [Page 1]
-
-Internet-Draft        A PRF for the Kerberos V Mech             May 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   1.1 Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . .  3
-   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
-   5.  Normative References . . . . . . . . . . . . . . . . . . . . .  5
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  5
-       Intellectual Property and Copyright Statements . . . . . . . .  6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires November 13, 2005               [Page 2]
-
-Internet-Draft        A PRF for the Kerberos V Mech             May 2005
-
-
-1.  Introduction
-
-   This document specifies the Kerberos V GSS-API mechanism's pseudo-
-   random function corresponding to [GSS-PRF].  The function is a "PRF+"
-   style construction.
-
-1.1  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  Kerberos V GSS Mechanism PRF
-
-   The GSS-API PRF [GSS-PRF] function for the Kerberos V mechanism
-   [RFC1964] shall be the output of a PRF+ function based on the
-   encryption type's PRF function keyed with the negotiated session key
-   of the security context corresponding to the 'prf_key' input
-   parameter of GSS_Pseudo_random().
-
-   This PRF+ MUST be keyed with the key indicated by the 'prf_key' input
-   parameter as follows:
-
-   o  GSS_C_PRF_KEY_FULL -- use the sub-session key asserted by the
-      acceptor, if any, or the sub-session asserted by the initiator, if
-      any, or the Ticket's session key
-
-   o  GSS_C_PRF_KEY_PARTIAL -- use the sub-session key asserted by the
-      initiator, if any, or the Ticket's session key
-
-   The PRF+ function is a simple counter-based extension of the Kerberos
-   V pseudo-random function [RFC3961] for the encryption type of the
-   security context's keys:
-
-         PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
-
-         Tn = pseudo-random(K, n || S)
-
-   where '||' is the concatenation operator, 'n' is encoded as a network
-   byte order 32-bit unsigned binary number, truncate(L, S) truncates
-   the input octet string S to length L, and pseudo-random() is the
-   Kerberos V pseudo-random function [RFC3961].
-
-   The maximum output size of the Kerberos V mechanism's GSS-API PRF
-   then is, necessarily, 2^32 times the output size of the pseudo-
-   random() function for the encryption type of the given key.
-
-   When the input size is longer than 2^14 octets as per [GSS-PRF] and
-
-
-
-Williams                Expires November 13, 2005               [Page 3]
-
-Internet-Draft        A PRF for the Kerberos V Mech             May 2005
-
-
-   exceeds an implementation's resources then the mechanism MUST return
-   GSS_S_FAILURE and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status
-   code.
-
-3.  IANA Considerations
-
-   This document has no IANA considerations currently.  If and when a
-   relevant IANA registry of GSS-API symbols and constants is created
-   then the GSS_KRB5_S_KG_INPUT_TOO_LONG minor status code should be
-   added to such a registry.
-
-4.  Security Considerations
-
-   Kerberos V encryption types' PRF functions use a key derived from
-   contexts' session keys and should preserve the forward security
-   properties of the mechanisms' key exchanges.
-
-   Legacy Kerberos V encryption types may be weak, particularly the
-   single-DES encryption types.
-
-   See also [GSS-PRF] for generic security considerations of
-   GSS_Pseudo_random().
-
-   See also [RFC3961] for generic security considerations of the
-   Kerberos V cryptographic framework.
-
-   Care should be taken not to exceed the useful lifetime of an
-   established security context's session key's useful lifetime as
-   implementations are not required to prevent overuse of the
-   GSS_Pseudo_random() function.  This can effectively be achieved by
-   limiting the number of GSS_Pseudo_random() calls to, say, a handful
-   of calls per-security context.
-
-   Use of Ticket session keys, rather than sub-session keys, when
-   initiators and acceptors fail to assert sub-session keys, is
-   dangerous as ticket reuse can lead to key reuse, therefore initiators
-   should assert sub-session keys always, and acceptors should assert
-   sub-session keys at least when initiators fail to do so..
-
-   The computational cost of computing this PRF+ may vary depending on
-   the Kerberos V encryption types being used, but generally the
-   computation of this PRF+ gets more expensive as the input and output
-   octet string lengths grow (note that the use of a counter in the PRF+
-   construction allows for parallelization).  This means that if an
-   application can be tricked into providing very large input octet
-   strings and requesting very long output octet strings then that may
-   constitute a denial of service attack on the application; therefore
-   applications SHOULD place appropriate limits on the size of any input
-
-
-
-Williams                Expires November 13, 2005               [Page 4]
-
-Internet-Draft        A PRF for the Kerberos V Mech             May 2005
-
-
-   octet strings received from their peers without integrity protection.
-
-5.  Normative References
-
-   [CFX]      Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 GSS-API Mechanism: Version 2".
-
-   [GSS-PRF]  Williams, N., "A PRF API extension for the GSS-API".
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires November 13, 2005               [Page 5]
-
-Internet-Draft        A PRF for the Kerberos V Mech             May 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                Expires November 13, 2005               [Page 6]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-04.txt b/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-04.txt
deleted file mode 100644
index f9c23fbb7..000000000
--- a/doc/standardisation/draft-ietf-kitten-krb5-gssapi-prf-04.txt
+++ /dev/null
@@ -1,337 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: December 15, 2005                                 June 13, 2005
-
-
-               A PRF for the Kerberos V GSS-API Mechanism
-                draft-ietf-kitten-krb5-gssapi-prf-04.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on December 15, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document defines the Pseudo-Random Function (PRF) for the
-   Kerberos V mechanism for the Generic Security Service Application
-   Programming Interface (GSS-API), based on the PRF defined for the
-   Kerberos V cryptographic framework, for keying application protocols
-   given an established Kerberos V GSS-API security context.
-
-
-
-
-
-
-
-Williams                Expires December 15, 2005               [Page 1]
-
-Internet-Draft        A PRF for the Kerberos V Mech            June 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   1.1 Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . .  3
-   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
-   5.  Normative References . . . . . . . . . . . . . . . . . . . . .  4
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  5
-       Intellectual Property and Copyright Statements . . . . . . . .  6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires December 15, 2005               [Page 2]
-
-Internet-Draft        A PRF for the Kerberos V Mech            June 2005
-
-
-1.  Introduction
-
-   This document specifies the Kerberos V GSS-API mechanism's pseudo-
-   random function corresponding to [GSS-PRF].  The function is a "PRF+"
-   style construction.
-
-1.1  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  Kerberos V GSS Mechanism PRF
-
-   The GSS-API PRF [GSS-PRF] function for the Kerberos V mechanism
-   [RFC1964] shall be the output of a PRF+ function based on the
-   encryption type's PRF function keyed with the negotiated session key
-   of the security context corresponding to the 'prf_key' input
-   parameter of GSS_Pseudo_random().
-
-   This PRF+ MUST be keyed with the key indicated by the 'prf_key' input
-   parameter as follows:
-
-   o  GSS_C_PRF_KEY_FULL -- use the sub-session key asserted by the
-      acceptor, if any, or the sub-session asserted by the initiator, if
-      any, or the Ticket's session key
-
-   o  GSS_C_PRF_KEY_PARTIAL -- use the sub-session key asserted by the
-      initiator, if any, or the Ticket's session key
-
-   The PRF+ function is a simple counter-based extension of the Kerberos
-   V pseudo-random function [RFC3961] for the encryption type of the
-   security context's keys:
-
-         PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
-
-         Tn = pseudo-random(K, n || S)
-
-   where '||' is the concatenation operator, 'n' is encoded as a network
-   byte order 32-bit unsigned binary number, truncate(L, S) truncates
-   the input octet string S to length L, and pseudo-random() is the
-   Kerberos V pseudo-random function [RFC3961].
-
-   The maximum output size of the Kerberos V mechanism's GSS-API PRF
-   then is, necessarily, 2^32 times the output size of the pseudo-
-   random() function for the encryption type of the given key.
-
-   When the input size is longer than 2^14 octets as per [GSS-PRF] and
-
-
-
-Williams                Expires December 15, 2005               [Page 3]
-
-Internet-Draft        A PRF for the Kerberos V Mech            June 2005
-
-
-   exceeds an implementation's resources then the mechanism MUST return
-   GSS_S_FAILURE and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status
-   code.
-
-3.  IANA Considerations
-
-   This document has no IANA considerations currently.  If and when a
-   relevant IANA registry of GSS-API symbols and constants is created
-   then the GSS_KRB5_S_KG_INPUT_TOO_LONG minor status code should be
-   added to such a registry.
-
-4.  Security Considerations
-
-   Kerberos V encryption types' PRF functions use a key derived from
-   contexts' session keys and should preserve the forward security
-   properties of the mechanisms' key exchanges.
-
-   Legacy Kerberos V encryption types may be weak, particularly the
-   single-DES encryption types.
-
-   See also [GSS-PRF] for generic security considerations of
-   GSS_Pseudo_random().
-
-   See also [RFC3961] for generic security considerations of the
-   Kerberos V cryptographic framework.
-
-   Use of Ticket session keys, rather than sub-session keys, when
-   initiators and acceptors fail to assert sub-session keys, is
-   dangerous as ticket reuse can lead to key reuse, therefore initiators
-   should assert sub-session keys always, and acceptors should assert
-   sub-session keys at least when initiators fail to do so..
-
-   The computational cost of computing this PRF+ may vary depending on
-   the Kerberos V encryption types being used, but generally the
-   computation of this PRF+ gets more expensive as the input and output
-   octet string lengths grow (note that the use of a counter in the PRF+
-   construction allows for parallelization).  This means that if an
-   application can be tricked into providing very large input octet
-   strings and requesting very long output octet strings then that may
-   constitute a denial of service attack on the application; therefore
-   applications SHOULD place appropriate limits on the size of any input
-   octet strings received from their peers without integrity protection.
-
-5.  Normative References
-
-   [CFX]      Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 GSS-API Mechanism: Version 2".
-
-
-
-
-Williams                Expires December 15, 2005               [Page 4]
-
-Internet-Draft        A PRF for the Kerberos V Mech            June 2005
-
-
-   [GSS-PRF]  Williams, N., "A PRF API extension for the GSS-API".
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires December 15, 2005               [Page 5]
-
-Internet-Draft        A PRF for the Kerberos V Mech            June 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                Expires December 15, 2005               [Page 6]
-
-
diff --git a/doc/standardisation/draft-ietf-kitten-stackable-pseudo-mechs-01.txt b/doc/standardisation/draft-ietf-kitten-stackable-pseudo-mechs-01.txt
deleted file mode 100644
index c3c49e6d6..000000000
--- a/doc/standardisation/draft-ietf-kitten-stackable-pseudo-mechs-01.txt
+++ /dev/null
@@ -1,953 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: April 19, 2006                                 October 16, 2005
-
-
-          Stackable Generic Security Service Pseudo-Mechanisms
-            draft-ietf-kitten-stackable-pseudo-mechs-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document defines and formalizes the concept of stackable pseudo-
-   mechanisms, and associated concept of composite mechanisms, for the
-   Generic Security Service Application Programming Interface (GSS-API),
-   as well as several utility functions.
-
-   Stackable GSS-API pseudo-mechanisms allow for the composition of new
-   mechanisms that combine features from multiple mechanisms.  Stackable
-   mechanisms that add support for Perfect Forward Security (PFS), data
-   compression, additional authentication factors, etc... are
-
-
-
-Williams                 Expires April 19, 2006                 [Page 1]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-   facilitated by this document.
-
-
-Table of Contents
-
-   1.      Conventions used in this document  . . . . . . . . . . . .  3
-   2.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.1.    Glossary . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.      Mechanism Composition Issues . . . . . . . . . . . . . . .  4
-   4.      Mechanism Composition  . . . . . . . . . . . . . . . . . .  5
-   4.1.    Construction of Composed Mechanism OIDs  . . . . . . . . .  5
-   4.2.    Mechanism Composition Rules  . . . . . . . . . . . . . . .  6
-   4.3.    Interfacing with Composite Mechanisms  . . . . . . . . . .  7
-   4.4.    Compatibility with the Basic GSS-APIv2u1 Interfaces  . . .  7
-   4.5.    Processing of Tokens for Composite Mechanisms  . . . . . .  8
-   5.      New GSS-API Interfaces . . . . . . . . . . . . . . . . . .  8
-   5.1.    New GSS-API Function Interfaces  . . . . . . . . . . . . .  9
-   5.1.1.  GSS_Compose_oid()  . . . . . . . . . . . . . . . . . . . .  9
-   5.1.2.  GSS_Decompose_oid()  . . . . . . . . . . . . . . . . . . . 10
-   5.1.3.  GSS_Release_oid()  . . . . . . . . . . . . . . . . . . . . 10
-   5.1.4.  GSS_Indicate_negotiable_mechs()  . . . . . . . . . . . . . 11
-   5.1.5.  GSS_Negotiate_mechs()  . . . . . . . . . . . . . . . . . . 12
-   5.1.6.  C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . 12
-   6.      Negotiation of Composite Mechanisms  . . . . . . . . . . . 13
-   6.1.    Negotiation of Composite Mechanisms Through SPNEGO . . . . 14
-   7.      Requirements for Mechanism Designers . . . . . . . . . . . 14
-   8.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 14
-   9.      Security considerations  . . . . . . . . . . . . . . . . . 14
-   10.     Normative  . . . . . . . . . . . . . . . . . . . . . . . . 15
-           Author's Address . . . . . . . . . . . . . . . . . . . . . 16
-           Intellectual Property and Copyright Statements . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 2]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-2.  Introduction
-
-   Recent discussions within the IETF have shown the need for a
-   refactoring of the features that GSS-API mechanisms may provide and a
-   way to compose new mechanisms from smaller components.
-
-   One way to do this is to "stack" multiple mechanisms on top of each
-   other such that the features of all of them are summed into a new,
-   composite mechanism.
-
-   One existing GSS-API mechanism, LIPKEY [LIPKEY], is essentially
-   stacked over another, SPKM-3 [LIPKEY] (although LIPKEY does not
-   conform to the stackable pseduo-mechanism framework described
-   herein).
-
-   The first truly stackable pseudo-mechanism proposed, CCM [CCM], is
-   intended for signalling, during negotiation of mechanisms, the
-   willingness of an initiator and/or acceptor to utilize channel
-   bindings
-
-   Since then other similar mechanism compositing needs and ideas have
-   come up, along with problems such as "what combinations are possible,
-   useful, reasonable and secure?"  This document addresses those
-   problems.  It introduces the concepts of stackable pseudo-mechanisms,
-   composite mechanisms and mechanism features or attributes, as well as
-   new inquiry and related interfaces to help in the mechanism
-   compositing.
-
-   (Mechanism features are more formally referred to as "mechanism
-   attributes" below.  The terms "feature" and mechanism attribute" are
-   sometimes used interchangeably.)
-
-2.1.  Glossary
-
-   Concrete GSS-API mechanism
-      A mechanism which can be used standalone.  Examples include: the
-      Kerberos V mechanism [CFX], SPKM-1/2 [SPKM] and SPKM-3 [LIPKEY].
-
-   GSS-API Pseudo-mechanism
-      A mechanism which uses other mechanisms in the construction of its
-      context and/or per-message tokens and security contexts.  SPNEGO
-
-
-
-Williams                 Expires April 19, 2006                 [Page 3]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-      is an example of this.
-
-   Stackable GSS-API pseudo-mechanism
-      A mechanism which uses a single other mechanism in the
-      construction of its tokens such that the OID of the composite
-      result can be constructed by prepending the OID of the stackable
-      pseudo-mechanism to the OID of the mechanism to be used by it.
-
-   Mechanism-negotiation GSS-API pseudo-mechanism
-      A GSS-API mechanism that negotiates the use of GSS-API mechanisms.
-      SPNEGO [SPNEGO] is an example of this.
-
-
-3.  Mechanism Composition Issues
-
-   Interfacing with composite mechanisms through the existing GSS-API
-   interfaces and the handling of composite mechanism tokens is
-   straightforward enough and described in Section 4.
-
-   However, the concepts of stackable and composite mechanisms do give
-   rise to several minor problems:
-
-   o  How to determine allowable combinations of mechanisms;
-   o  How to encode composite mechanism OIDs;
-   o  How to decompose the OID of a composite mechanism and process its
-      tokens properly;
-   o  Application interfacing issues such as:
-
-      *  Whether and/or which composite mechanisms should be listed by
-         GSS_Indicate_mechs();
-      *  Whether and/or which composite mechanisms not listed by
-         GSS_Indicate_mechs() may nonetheless be available for use by
-         applications and how applications can detect their
-         availability;
-      *  What additional, if any, interfaces should be provided to help
-         applications select appropriate mechanisms;
-   o
-
-      Mechanism negotiation issues (related to the application interface
-      issues listed above), such as: vspace blankLines='1'/>
-      *  Should applications advertise composite mechanisms in SPNEGO or
-         other application-specific mechanism negotiation contexts?
-      *  Or should applications implicitly advertise composite
-         mechanisms by advertising concrete and stackable pseudo-
-         mechanisms in SPNEGO or other application-specific mechanism
-         negotiation contexts?
-
-   Section 4 addresses the OID composition, decomposition and encoding
-
-
-
-Williams                 Expires April 19, 2006                 [Page 4]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-   issues, as well as basic interfacing and token handling issues.
-
-   Section 5 addresses interfacing issues more generally through the
-   specification of additional, optional APIs.
-
-   Section 6 addresses mechanism negotiation issues.
-
-
-4.  Mechanism Composition
-
-   Mechanism composition by stacking pseudo-mechanisms on a concrete
-   mechanism is conceptually simple: join the OIDs of the several
-   mechanisms in question and process GSS-API tokens and routine calls
-   through the top-most pseudo-mechanism in a stack, which can then, if
-   necessary, recursively call the GSS-API to process any tokens for the
-   remainder of the stack.
-
-   Some stackable pseudo-mechanisms may do nothing more than perform
-   transformations on application data (e.g., compression); such pseudo-
-   mechanisms will generally chain the processing of tokens and routine
-   calls to the mechanisms below them in the stack.
-
-   Other stackable pseudo-mechanisms may utilize the mechanisms below
-   them only during security context setup.  For example, a stackable
-   pseudo-mechanism could perform a Diffie-Hellman key exchange and
-   authenticate it by binding a security context established with the
-   mechanism stacked below it; such a mechanism would provide its own
-   per-message tokens.
-
-4.1.  Construction of Composed Mechanism OIDs
-
-   Composition of mechanism OIDs is simple: prepend the OID of one
-   pseudo-mechanism to the OID of another mechanism (composite or
-   otherwise), but there MUST always be at least one final mechanism OID
-   and it MUST be useful standalone (i.e., it MUST NOT be a pseudo-
-   mechanism).  A composite mechanism OID forms, essentially, a stack.
-
-   The encoding of composed mechanism OIDs is not quite the
-   concatenation of the component OIDs' encodings, however.  This is
-   because the first two arcs of ASN.1 OIDs are encoded differently from
-   subsequent arcs (the first two arcs have a limited namespace and are
-   encoded as a single octet), so were composite mechanism OIDs to be
-   encoded as the concatenation of the component OIDs the result would
-   not decode as the concatenation of the component OIDs.  To avoid this
-   problem the first two arcs of each component of a composite mechanism
-   OID, other than the leading component, will be encoded as other arcs
-   would.
-
-
-
-
-Williams                 Expires April 19, 2006                 [Page 5]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-   Decomposition of composite mechanism OIDs is similar, with each
-   pseudo-mechanism in the stack being able to determine the OID suffix
-   from knowledge of its own OID(s).
-
-   New pseudo-mechanisms MAY be allocated OIDs from the prefix given
-   below as follows by assignment of a sub-string of OID arcs to be
-   appended to this prefix.  This prefix OID is:
-
-   <TBD> [1.3.6.1.5.5.11 appears to be available, registration w/ IANA
-   TBD]
-
-   All OID allocations below this OID MUST be for stackable pseudo-
-   mechanisms and MUST consist of a single arc.  This will make it
-   possible to decompose the OIDs of composite mechanisms without
-   necessarily knowing a priori the OIDs of the component stackable
-   pseudo-mechanisms.
-
-4.2.  Mechanism Composition Rules
-
-   All new stackable pseudo-mechanisms MUST specify the rules for
-   determining whether they can stack above a given mechanism, composite
-   or otherwise.  Such rules may be based on specific mechanism
-   attribute OID sets [EXTENDED-INQUIRY] and/or specific mechanism OIDs
-   (composite and otherwise).
-
-   All stackable pseudo-mechanisms MUST have the following mechanism
-   composition rule relating to unknown mechanism attributes:
-
-   o  composition with mechanisms supporting unknown mechanism
-      attributes MUST NOT be permitted.
-
-   This rule protects against compositions which cannot be considered
-   today but which might nonetheless arise due to the introduction of
-   new mechanisms and which might turn out to be insecure or otherwise
-   undesirable.
-
-   Mechanism composition rules for stackable pseudo-mechanisms MAY and
-   SHOULD be updated as new GSS-API mechanism attributes and mechanisms
-   sporting them are introduced.  The specifications of mechanisms that
-   introduce new mechanism attributes or which otherwise should not be
-   combined with others in ways which would be permitted under existing
-   rules SHOULD also update the mechanism composition rules of affected
-   pseudo-mechanisms.
-
-   A RECOMMENDED way to describe the stacking rules for stackable
-   mechanisms is as an ordered sequence of "MAY stack above X
-   mechanism," "REQUIRES Y mechanism feature(s)," "MUST NOT stack above
-   Z mechanism," and/or "MUST NOT stack above a mechanism with Z
-
-
-
-Williams                 Expires April 19, 2006                 [Page 6]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-   mechanism feature(s)."
-
-   For example a stackable mechanism that provides its own per-msg
-   tokens and does not use the underlying mechnism's per-msg token
-   facilities might require a rule such as "MUST NOT stack above a
-   mechanism with the GSS_C_MA_COMPRESS mechanism feature."
-
-4.3.  Interfacing with Composite Mechanisms
-
-   The basic GSS-API [RFC2743] interfaces MUST NOT accept as input or
-   provide as output the OID of any stackable pseudo-mechanism.
-   Composite mechanisms MUST be treated as concrete mechanisms by the
-   basic GSS-API interfaces [RFC2743].
-
-   Thus the way in which a composite mechanism is used by applications
-   with the basic GSS-API (version 2, update 1) is straightforward:
-   exactly as if composite mechanisms were normal GSS-API mechanisms.
-
-   This is facilitated by the fact that in all cases where the GSS-API
-   implementation might need to know how to process or create a token it
-   has the necessary contextual information, that is, the mechanism OID,
-   available and can decompose composite mechanism OIDs as necessary.
-
-   For example, for initial GSS_Init_sec_context() calls the
-   implementation knows the desired mechanism OID, and if it should be
-   left unspecified, it can pick a default mechanism given the initiator
-   credentials provided by the application (and if none are provided
-   other default mechanism and credential selections can still be made).
-   For subsequent calls to GSS_Init_sec_context() the implementation
-   knows which mechanism to use from the given [partially established]
-   security context.  Similarly for GSS_Accept_sec_context, where on
-   initial calls the mechanism OID can be determined from the given
-   initial context token's framing.
-
-   The manner in which GSS-API implementations and the various
-   mechanisms and pseudo-mechanisms interface with one another is left
-   as an excercise to implementors.
-
-4.4.  Compatibility with the Basic GSS-APIv2u1 Interfaces
-
-   In order to preserve backwards compatibility with applications that
-   use only the basic GSS-API interfaces (version 2, update 1), several
-   restrictions are imposed on the use of composite and stackable
-   pseduo-mechanisms with the basic GSS-API interfaces:
-
-   o  GSS_Indicate_mechs() MUST NOT indicate support for any stackable
-      pseduo-mechanisms under any circumstance.
-   o  GSS_Indicate_mechs() MAY indicate support for some, all or none of
-
-
-
-Williams                 Expires April 19, 2006                 [Page 7]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-      the available composite mechanisms.
-   o  Which composite mechanisms, if any, are indicated through
-      GSS_Indicate_mechs() SHOULD be configurable.
-   o  Composite mechanisms which are not indicated by
-      GSS_Indicate_mechs() MUST NOT be considered as the default
-      mechanism (GSS_C_NULL_OID) or as part of the default mechanism set
-      (GSS_C_NULL_OID_SET).
-   o  The OIDs of *stackable* (not composite) pseudo-mechanisms MUST NOT
-      be accepted as inputs or produced in the output of any of the
-      basic GSS-APIv2, update 1 API functions, except for any OID set
-      construction/iteration functions.  And, if present in any OID SET
-      input parameters of GSS-APIv2, update 1 functions, they MUST be
-      ignored.
-   o  The OIDs of *stackable* (not composite) pseudo-mechanisms MAY only
-      be used as inputs or produced as outputs of functions whose
-      specification explicitly allows for them or which are concerned
-      with the creation/iteration of OID containters, such as OID SETs.
-
-4.5.  Processing of Tokens for Composite Mechanisms
-
-   The initial context token for any standard mechanism, including
-   mechanisms composited from standard pseudo- and concrete mechanisms,
-   MUST be encapsulated as described in section 3.1 of rfc2743
-   [RFC2743], and the OID used in that framing MUST be that of the
-   mechanism, but in the case of composite mechanisms this OID MUST be
-   the OID of the leading component of the composite mechanism.
-
-   Note that this has implications for pluggable multi-mechanism
-   implementations of the GSS-API, namely that acceptors must route
-   initial context tokens to the appropriate mechanism and they must
-   allow that mechanism to determine the composite mechanism OID (such
-   as by allowing that mechanism's GSS_Accept_sec_context() to output
-   the actual mechanism to the application.
-
-   In all other cases the mechanism that produced or is to produce a
-   given token can be determined internally through the given security
-   context.
-
-
-5.  New GSS-API Interfaces
-
-   ...
-
-   Utility functions for mechanism OID composition and decomposition are
-   given in sections 5.1.1, 5.1.2 and 5.1.3.
-
-   Two utility functions, GSS_Indicate_negotiable_mechs() and
-   GSS_Negotiate_mechs(), to aid applications in mechanism negotiation
-
-
-
-Williams                 Expires April 19, 2006                 [Page 8]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-   are described in sections 5.1.4 and 5.1.5.  These two interfaces may
-   be implemented entirely in terms of the other interfaces described
-   herein.
-
-5.1.  New GSS-API Function Interfaces
-
-   Several new interfaces are given by which, for example, GSS-API
-   applications may determine what features are provided by a given
-   mechanism, what mechanisms provide what features and what
-   compositions are legal.
-
-   These new interfaces are all OPTIONAL.
-
-   In order to preserve backwards compatibility with applications that
-   do not use the new interfaces GSS_Indicate_mechs() MUST NOT indicate
-   support for any stackable pseduo-mechanisms.  GSS_Indicate_mechs()
-   MAY indicate support for some, all or none of the available composite
-   mechanisms; which composite mechanisms, if any, are indicated through
-   GSS_Indicate_mechs() SHOULD be configurable.  GSS_Acquire_cred() and
-   GSS_Add_cred() MUST NOT create credentials for composite mechanisms
-   not explicitly requested or, if no desired mechanism or mechanisms
-   are given, for composite mechanisms not indicated by
-   GSS_Indicate_mechs().
-
-   Applications SHOULD use GSS_Indicate_mechs_by_mech_attrs() instead of
-   GSS_Indicate_mechs() wherever possible.
-
-   Applications can use GSS_Indicate_mechs_by_mech_attrs() to determine
-   what, if any, mechanisms provide a given set of features.
-
-   GSS_Indicate_mechs_by_mech_attrs() can also be used to indicate (as
-   in GSS_Indicate_mechs()) the set of available mechanisms of each type
-   (concrete, mechanism negotiation pseudo-mechanism, stackable pseudo-
-   mechanism and composite mechanisms).
-
-   Applications may use GSS_Inquire_mech_attrs_for_mech() to test
-   whether a given composite mechanism is available and the set of
-   features that it offers.
-
-   GSS_Negotiate_mechs() may be used to negotiate the use of mechanisms
-   such that composite mechanisms need not be advertised but instead be
-   implied by offering stackable pseudo-mechanisms.
-
-5.1.1.  GSS_Compose_oid()
-
-   Inputs:
-   o  mech1 OBJECT IDENTIFIER, -- mechanism OID
-   o  mech2 OBJECT IDENTIFIER -- mechanism OID
-
-
-
-Williams                 Expires April 19, 2006                 [Page 9]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-   Outputs:
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  composite OBJECT IDENTIFIER -- OID composition of mech1 with mech2
-      ({mech1 mech2})
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates success.
-   o  GSS_S_BAD_MECH indicates that mech1 is not supported.
-   o  GSS_S_FAILURE indicates that the request failed for some other
-      reason.  The minor status will be specific to mech1 and may
-      provide further information.
-
-5.1.2.  GSS_Decompose_oid()
-
-   Inputs:
-   o  input_mech OBJECT IDENTIFIER, -- mechanism OID.
-   o  mechs SET OF OBJECT IDENTIFIER -- mechanism OIDs (if
-      GSS_C_NULL_OID_SET defaults to the set of stackable pseudo-
-      mechanism OIDs indicated by GSS_Indicate_mechs_by_mech_attrs()).
-
-   Outputs:
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  lead_mech OBJECT IDENTIFIER, -- leading stackable pseudo-
-      mechanism OID.
-   o  trail_mech OBJECT IDENTIFIER -- input_mech with lead_mech removed
-      from the front.
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates success.
-   o  GSS_S_BAD_MECH indicates that the input_mech could not be
-      decomposed as no stackable pseudo-mechanism is available whose OID
-      is a prefix of the input_mech.
-   o  GSS_S_FAILURE indicates that the request failed for some other
-      reason.
-
-5.1.3.  GSS_Release_oid()
-
-   The following text is adapted from the obsoleted rfc2078 [RFC2078].
-
-   Inputs:
-   o  oid OBJECT IDENTIFIER
-
-   Outputs:
-   o  major_status INTEGER,
-   o  minor_status INTEGER
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 10]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates successful completion
-   o  GSS_S_FAILURE indicates that the operation failed
-
-   Allows the caller to release the storage associated with an OBJECT
-   IDENTIFIER buffer allocated by another GSS-API call, specifically
-   GSS_Compose_oid() and GSS_Decompose_oid().  This call's specific
-   behavior depends on the language and programming environment within
-   which a GSS-API implementation operates, and is therefore detailed
-   within applicable bindings specifications; in particular, this call
-   may be superfluous within bindings where memory management is
-   automatic.
-
-5.1.4.  GSS_Indicate_negotiable_mechs()
-
-   Inputs:
-   o  input_cred_handle CREDENTIAL HANDLE, -- credential handle to be
-      used with GSS_Init_sec_context(); may be GSS_C_NO_CREDENTIAL.
-   o  peer_type_known BOOLEAN, -- indicates whether the peer is known to
-      support or not supprot the stackable pseudo-mechanism framework.
-   o  peer_has_mech_stacking BOOLEAN -- indicates whether the peer
-      supports the stackable pseudo-mechanism framework; ignore if
-      peer_type_known is FALSE.
-
-   Outputs:
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  offer_mechs SET OF OBJECT IDENTIFIER, -- mechanisms to offer.
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates success.
-   o  GSS_S_NO_CREDENTIAL indicates that the caller's credentials are
-      expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no
-      credentials could be acquired for GSS_C_NO_NAME.
-   o  GSS_S_FAILURE indicates that the request failed for some other
-      reason.
-
-   This function produces a set of mechanism OIDs, optimized for space,
-   that its caller should advertise to peers during mechanism
-   negotiation.
-
-   The output offer_mechs parameter will include all of the mechanisms
-   for which the input_cred_handle has elements (as indicated by
-   GSS_Inquire_cred()), but composite mechanisms will be included either
-   implicitly or implicitly as per the following rules:
-   o  if peer_type_known is TRUE and peer_has_mech_stacking is FALSE
-      then no composite mechanisms not indicated by GSS_Indicate_mechs()
-      will be advertised, explictly or implicitly;
-
-
-
-Williams                 Expires April 19, 2006                [Page 11]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-   o  if peer_type_known is FALSE then all composite mechanisms
-      indicated by GSS_Indicate_mechs() for which input_cred_handle has
-      elements will be indicated in offer_mechs explicitly and all
-      others may be indicated in offer_mechs implicitly, by including
-      their component stackable pseduo-mechanism OIDs (see below);
-   o  if peer_type_known is TRUE and peer_has_mech_stacking is TRUE
-      composite mechanisms will generally not be advertised explicitly,
-      but will be advertised implicitly, by including their component
-      stackable pseduo-mechanism OIDs (see below); no composite
-      mechanisms will be advertised explicitly
-   o  if the input_cred_handle does not have elements for all of the
-      possible composite mechanisms that could be constructed from the
-      its elements' decomposed mechanisms, then all composite mechanisms
-      for which the input_cred_handle does have elements will be
-      advertised explicitly in offer_mechs.
-
-5.1.5.  GSS_Negotiate_mechs()
-
-   Inputs:
-   o  input_credential_handle CREDENTIAL HANDLE, -- mechanisms offered
-      by the caller.
-   o  peer_mechs SET OF OBJECT IDENTIFIER -- mechanisms offered by the
-      caller's peer.
-
-   Outputs:
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  mechs SET OF OBJECT IDENTIFIER -- mechanisms common to the
-      caller's credentials and the caller's peer.
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates success; the output mechs parameter MAY
-      be the empty set (GSS_C_NO_OID_SET).
-   o  GSS_S_NO_CREDENTIAL indicates that the caller's credentials are
-      expired or, if input_cred_handle is GSS_C_NO_CREDENTIAL, that no
-      credentials could be acquired for GSS_C_NO_NAME.
-   o  GSS_S_FAILURE indicates that the request failed for some other
-      reason.
-
-   This function matches the mechanisms for which the caller has
-   credentials with the mechanisms offered by the caller's peer and
-   returns the set of mechanisms in common to both, accounting for any
-   composite mechanisms offered by the peer implicitly.
-
-5.1.6.  C-Bindings
-
-
-      OM_uint32 gss_compose_oid(
-
-
-
-Williams                 Expires April 19, 2006                [Page 12]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-         OM_uint32         *minor_status,
-         const gss_OID      mech1,
-         const gss_OID      mech2,
-         gss_OID           *composite);
-
-      OM_uint32 gss_decompose_oid(
-         OM_uint32         *minor_status,
-         const gss_OID      input_mech,
-         const gss_OID_set  mechs,
-         gss_OID           *lead_mech,
-         gss_OID           *trail_mech);
-
-      OM_uint32 gss_release_oid(
-         OM_uint32         *minor_status,
-         gss_OID           *oid);
-
-      OM_uint32 gss_indicate_negotiable_mechs(
-         OM_uint32                 *minor_status,
-         const gss_cred_id_t        input_cred_handle,
-         OM_uint32                  peer_type_known,
-         OM_uint32                  peer_has_mech_stacking,
-         gss_OID_set               *offer_mechs);
-
-      OM_uint32 gss_negotiate_mechs(
-         OM_uint32                 *minor_status,
-         const gss_cred_id_t        input_cred_handle,
-         const gss_OID_set          peer_mechs,
-         const gss_OID_set         *mechs);
-
-
-   Figure 1
-
-
-6.  Negotiation of Composite Mechanisms
-
-   Where GSS-API implementations do not support the stackable mechanism
-   framework interfaces applications may only negotiate explicitly from
-   a set of concrete and composite mechanism OIDs as indicated by
-   GSS_Indicate_mechs() and for which suitable credentials are
-   available.  GSS_Indicate_mechs(), as described in Section 4.4, MUST
-   NOT indicate support for individual stackable pseudo-mechanisms, so
-   there will not be any composite mechanisms implied but not explicitly
-   offered in the mechanism negotiation.
-
-   Applications that support the stackable mechanism framework SHOULD
-   use GSS_Indicate_negotiable_mechs() to construct the set of mechanism
-   OIDs to offer to their peers.  GSS_Indicate_negotiable_mechs()
-   optimizes for bandwidth consumption by using decomposed OIDs instead
-
-
-
-Williams                 Expires April 19, 2006                [Page 13]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-   of composed OIDs, where possible.  See Section 5.1.4.
-
-   Peers that support the stackable mechanism framework interfaces
-   SHOULD use GSS_Negotiate_mechs() to select a mechanism as that
-   routine accounts for composite mechanisms implicit in the mechanism
-   offers.
-
-6.1.  Negotiation of Composite Mechanisms Through SPNEGO
-
-   SPNEGO applications MUST advertise either the set of mechanism OIDs
-   for which they have suitable credentials or the set of mechanism OIDs
-   produced by calling GSS_Indicate_negotiable_mechs() with the
-   available credentials and the peer_type_known parameter as FALSE.
-
-
-7.  Requirements for Mechanism Designers
-
-   Stackable pseudo-mechanisms specifications MUST:
-   o  list the set of GSS-API mechanism attributes associated with them
-   o  list their initial mechanism composition rules
-   o  specify a mechanism for updating their mechanism composition rules
-
-   All other mechanism specifications MUST:
-   o  list the set of GSS-API mechanism attributes associated with them
-
-
-8.  IANA Considerations
-
-   Allocation of arcs in the namespace of OIDs relative to the base
-   stackable pseduo-mechanism OID specified in Section 4.1 is reserved
-   to the IANA.
-
-
-9.  Security considerations
-
-   Some composite mechanisms may well not be secure.  The mechanism
-   composition rules of pseudo-mechanisms (including the default
-   composition rule given in Section 4 for unknown mechanism attributes)
-   should be used to prevent the use of unsafe composite mechanisms.
-
-   Designers of pseudo-mechanisms should study the possible combinations
-   of their mechanisms with others and design mechanism composition
-   rules accordingly.
-
-   Similarly, pseudo-mechanism designers MUST specify, and implementors
-   MUST implement, composite mechanism attribute set determination rules
-   appropriate to the subject pseduo-mechanism, as described in section
-   4.2.  Failure to do so may lead to inappropriate composite mechanisms
-
-
-
-Williams                 Expires April 19, 2006                [Page 14]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-   being deemed permissible by programmatic application of flawed
-   mechanism composition rules or to by their application with incorrect
-   mechanism attribute sets.
-
-10.  Normative
-
-   [EXTENDED-INQUIRY]
-              Williams, N., "Extended Generic Security Service Mechanism
-              Inquiry APIs",
-              draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
-              progress).
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 15]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 16]
-
-Internet-Draft             Stackable GSS Mechs              October 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                 Expires April 19, 2006                [Page 17]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-anon-00.txt b/doc/standardisation/draft-ietf-krb-wg-anon-00.txt
deleted file mode 100644
index 7b8bf821d..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-anon-00.txt
+++ /dev/null
@@ -1,562 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                                  P. Leach
-Updates: 4120 (if approved)                                K. Jaganathan
-Expires: December 5, 2006                          Microsoft Corporation
-                                                            June 3, 2006
-
-
-                     Anonymity Support for Kerberos
-                       draft-ietf-krb-wg-anon-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on December 5, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document defines the use of anonymous Kerberos tickets for the
-   purpose of authenticating the servers and enabling secure
-   communication between a client and a server, without identifying the
-   client to the server.
-
-
-
-
-
-
-Zhu, et al.             Expires December 5, 2006                [Page 1]
-
-Internet-Draft         Kerberos Anonymity Support              June 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  5
-   5.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . .  6
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
-   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  7
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
-   Intellectual Property and Copyright Statements . . . . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires December 5, 2006                [Page 2]
-
-Internet-Draft         Kerberos Anonymity Support              June 2006
-
-
-1.  Introduction
-
-   In certain situations or environments, the Kerberos [RFC4120] client
-   may wish to authenticate a server and/or protect communications
-   without revealing its own identity.  For example, consider an
-   application which provides read access to a research database, and
-   which permits queries by arbitrary requestors.  A client of such a
-   service might wish to authenticate the service, to establish trust in
-   the information received from it, but might not wish to disclose its
-   identity to the service for privacy reasons.
-
-   To accomplish this, a Kerberos mechanism is specified in this
-   document by which a client requests an anonymous ticket and use that
-   to authenticate the server and secure subsequent client-server
-   communications.  This provides Kerberos with functional equivalence
-   to TLS [RFC2246] in environments where Kerberos is a more attractive
-   authentication mechanism.
-
-   Using this mechanism, the client has to reveal its identity in its
-   initial request to its own Key Distribution Center (KDC) [RFC4120],
-   and then it can remain anonymous thereafter to KDCs on the cross-
-   realm authentication path, if any, and to the server with which it
-   communicates.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  Definitions
-
-   An anonymous ticket is a ticket that has all of the following
-   properties:
-
-   o  The client's principal name is the anonymous Kerberos principal
-      name.  The anonymous Kerberos principal name is defined as
-      follows: it is a reserved Kerberos principal name as defined in
-      [KRBNAM], the name-type is KRB_NT_RESRVED [KRBNAM], and the name-
-      string is a sequence of two KerberosString components: "RESERVED",
-      "ANONYMOUS".
-
-   o  The client's realm name is the anonymous kerberos realm name.  The
-      anonymous Kerberos realm name is defined as follows: it is a
-      reserved realm name as defined in [KRBNAM] and the realm name is
-      the literal "RESERVED:ANONYMOUS".
-
-
-
-Zhu, et al.             Expires December 5, 2006                [Page 3]
-
-Internet-Draft         Kerberos Anonymity Support              June 2006
-
-
-   o  The authtime field in the ticket is set to the time of the ticket
-      request, not the time of the initial authentication for the
-      principal who has made the request.
-
-   o  The transited field [RFC4120] can either contain the client's
-      authentication path or contain the anonymous authentication path
-      defined as follows: the tr-type field of the transited field is
-      NO-TRANSITED-INFO (as defined later in this section) and the
-      contents field is an empty OCTET STRING.  If a TGS request
-      contains an anonymous ticket with a "normal" authentication path
-      (i.e. the transited field does not contain the anonymous
-      authentication path as defined above), then the reply ticket, if
-      any, MUST NOT contain the anonymous authentication path.  For
-      application servers, no transited policy is defined for the
-      anonymous authentication path, but all of the transited checks
-      would still apply if an anonymous ticket contains a "normal"
-      authentication path.  Note that the "normal" authentication path
-      in an anonymous ticket can be a partial path, thus it may not be
-      sufficient to identify the originating client realm.
-
-   o  It contains no information that can reveal the client's identity
-      other than, at most, the client's realm or the realm(s) on the
-      authentication path.
-
-   o  The anonymous ticket flag (as defined later in this section) is
-      set.
-
-   The anonymous ticket flag is defined as bit 14 (with the first bit
-   being bit 0) in the TicketFlags:
-
-           TicketFlags     ::= KerberosFlags
-             -- anonymous(14)
-             -- TicketFlags and KerberosFlags are defined in [RFC4120]
-
-   The anonymous ticket flag MUST NOT be set by implementations of this
-   specification if the ticket is not an anonymous ticket as defined in
-   this section.
-
-   The request-anonymous KDC option is defined as bit 14 (with the first
-   bit being bit 0) in the KDCOptions:
-
-           KDCOptions      ::= KerberosFlags
-             -- request-anonymous(14)
-             -- KDCOptions and KerberosFlags are defined in [RFC4120]
-
-   The anonymous transited encoding type is defined as follows:
-
-           NO-TRANSITED-INFO    0
-
-
-
-Zhu, et al.             Expires December 5, 2006                [Page 4]
-
-Internet-Draft         Kerberos Anonymity Support              June 2006
-
-
-   This transited encoding type indicates that there is no information
-   available about the authentication path.
-
-   Note that the server principal name and the server realm in a cross-
-   realm referral TGT are not dependent on whether the client is the
-   anonymous principal or not.
-
-
-4.  Protocol Description
-
-   In order to request an anonymous ticket, the client sets the request-
-   anonymous KDC option in an AS or TGS request [RFC4120].  Note that if
-   the service ticket in the PA-TGS-REQ [RFC4120] is anonymous, the
-   request-anonymous KDC option MUST be set in the request.
-
-   When policy allows, the KDC issues an anonymous ticket.  The KDC that
-   implements this specification MUST NOT carry information that can
-   reveal the client's identity, from the TGS request into the returned
-   anonymous ticket.
-
-   It should be noted that unless otherwise specified by this document
-   the client principal name and the client realm in the Kerberos
-   messages [RFC4120] should be the client name and client realm that
-   can uniquely identify the client principal to the KDC, not the
-   anonymous client principal name and the empty realm name.  For
-   example, the client name and realm in the request body and the
-   EncKDCRepPart of the reply [RFC4120] are identifiers of the client
-   principal.  In other words, the client name and client realm in the
-   EncKDCRepPart does not match with that of the returned anonymous
-   ticket.
-
-   If either local policy prohibits issuing of anonymous tickets or it
-   is inappropriate to remove information (such as restrictions) from
-   the TGS request in order to produce an anonymous ticket, the KDC MUST
-   return an error message with the code KDC_ERR_POLICY [RFC4120].
-
-   If a client requires anonymous communication then the client should
-   check to make sure that the resulting ticket is actually anonymous by
-   checking the presence of the anonymous ticket flag.  Because KDCs
-   ignore unknown KDC options, a KDC that does not understand the
-   request-anonymous KDC option will not return an error, but will
-   instead return a normal ticket.
-
-   The subsequent client and server communications then proceed as
-   described in [RFC4120].  The client principal name in the
-   Authenticator of the KRB_AP_REQ MUST be the anonymous client
-   principal name and the client realm of the Authenticator MUST be an
-   empty KerberosString [RFC4120].
-
-
-
-Zhu, et al.             Expires December 5, 2006                [Page 5]
-
-Internet-Draft         Kerberos Anonymity Support              June 2006
-
-
-   A server accepting such an anonymous service ticket may assume that
-   subsequent requests using the same ticket originate from the same
-   client.  Requests with different tickets are likely to originate from
-   different clients.
-
-   Interoperability and backward-compatibility notes: the KDC is given
-   the task of rejecting a request for an anonymous ticket when the
-   anonymous ticket is not acceptable by the server.
-
-
-5.  GSS-API Implementation Notes
-
-   At the GSS-API [RFC2743] level, the use of an anonymous principal by
-   the initiator/client requires a software change of the initiator/
-   client software (to assert the "anonymous" flag when calling
-   GSS_Init_Sec_Context().
-
-   GSS-API does not know or define "anonymous credentials", so the
-   (printable) name of the anonymous principal will rarely be used by or
-   relevant for the initator/client.  The printable name is relevant for
-   the acceptor/server when performing an authorization decision based
-   on the name that pops up from GSS_Accept_Sec_Context() upon
-   successful security context establishment.
-
-   A GSS-API initiator MUST carefully check the resulting context
-   attributes from the initial call to GSS_Init_Sec_Context() when
-   requesting anonymity, because (as in the GSS-API tradition and for
-   backwards compatibility) anonymity is just another optional context
-   attribute.  It could be that the mechanism doesn't recognize the
-   attribute at all or that anonymity is not available for some other
-   reasons -- and in that case the initiator must NOT send the initial
-   security context token to the acceptor, because it will likely reveal
-   the initiators identity to the acceptor, something that can rarely be
-   "un-done".
-
-   GSS-API defines name_type GSS_C_NT_ANONYMOUS [RFC2743] to represent
-   an anonymous identity.  In addition, according to Section 2.1.1 of
-   [RFC1964] the string representation of the anonymous client principal
-   name can be "RESERVED/ANONYMOUS" or "RESERVED/
-   ANONYMOUS@RESERVED:ANONYMOUS" with the name_type
-   GSS_KRB5_NT_PRINCIPAL_NAME.  Implementations conforming to this
-   specification MUST be able to accept the GSS_C_NT_ANONYMOUS name form
-   and the GSS_KRB5_NT_PRINCIPAL_NAME name forms, and consider them
-   equivalent.
-
-   Portable initiators are RECOMMENDED to use default credentials
-   whenever possible, and request anonymity only through the input
-   anon_req_flag to GSS_Init_Sec_Context().
-
-
-
-Zhu, et al.             Expires December 5, 2006                [Page 6]
-
-Internet-Draft         Kerberos Anonymity Support              June 2006
-
-
-6.  Security Considerations
-
-   Since KDCs ignore unknown options [RFC4120], a client requiring
-   anonymous communication needs to make sure that the ticket is
-   actually anonymous.  A KDC that that does not understand the
-   anonymous option would not return an anonymous ticket.
-
-   By using the mechanism defined in this specification, the client does
-   not reveal its identity to the server but its identity may be
-   revealed to the KDC of the server principal (when the server
-   principal is in a different realm than that of the client), and any
-   KDC on the cross-realm authentication path.  The Kerberos client MUST
-   verify the ticket being used are indeed anonymous before
-   communicating with the cross-realm KDC or the server, otherwise the
-   client's identity may be revealed to the server unintentionally.
-
-   In cases where specific server principals must not have access to the
-   client's identity (for example, an anonymous poll service), the KDC
-   can define server principal specific policy that insure any normal
-   service ticket can NEVER be issued to any of these server principals.
-
-
-7.  Acknowledgements
-
-   The authors would like to thank the following individuals for their
-   insightful comments and fruitful discussions: Sam Hartman, Martin
-   Rex, Nicolas Williams, Jeffery Altman, Tom Yu, Chaskiel M Grundman,
-   Love Hoernquist Aestrand, Jeffery Hutzelman, and Clifford Neuman.
-
-
-8.  IANA Considerations
-
-   No IANA actions are required for this document.
-
-9.  Normative References
-
-   [KRBNAM]   Zhu, L., "Additonal Kerberos Naming Contraints", 
-              draft-ietf-krb-wg-naming, work in progress.
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-
-
-
-Zhu, et al.             Expires December 5, 2006                [Page 7]
-
-Internet-Draft         Kerberos Anonymity Support              June 2006
-
-
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires December 5, 2006                [Page 8]
-
-Internet-Draft         Kerberos Anonymity Support              June 2006
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Paul Leach
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: paulle@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires December 5, 2006                [Page 9]
-
-Internet-Draft         Kerberos Anonymity Support              June 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.             Expires December 5, 2006               [Page 10]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-anon-01.txt b/doc/standardisation/draft-ietf-krb-wg-anon-01.txt
deleted file mode 100644
index e1a9e9b1c..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-anon-01.txt
+++ /dev/null
@@ -1,617 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                                  P. Leach
-Updates: 4120 (if approved)                                K. Jaganathan
-Expires: January 17, 2007                          Microsoft Corporation
-                                                           July 16, 2006
-
-
-                     Anonymity Support for Kerberos
-                       draft-ietf-krb-wg-anon-01
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 17, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document defines the use of anonymous Kerberos tickets for the
-   purpose of authenticating the servers and enabling secure
-   communication between a client and a server, without identifying the
-   client to the server.
-
-
-
-
-
-
-Zhu, et al.             Expires January 17, 2007                [Page 1]
-
-Internet-Draft         Kerberos Anonymity Support              July 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  5
-   5.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . .  7
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
-   Intellectual Property and Copyright Statements . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires January 17, 2007                [Page 2]
-
-Internet-Draft         Kerberos Anonymity Support              July 2006
-
-
-1.  Introduction
-
-   In certain situations or environments, the Kerberos [RFC4120] client
-   may wish to authenticate a server and/or protect communications
-   without revealing its own identity.  For example, consider an
-   application which provides read access to a research database, and
-   which permits queries by arbitrary requestors.  A client of such a
-   service might wish to authenticate the service, to establish trust in
-   the information received from it, but might not wish to disclose its
-   identity to the service for privacy reasons.
-
-   To accomplish this, a Kerberos mechanism is specified in this
-   document by which a client requests an anonymous ticket and use that
-   to authenticate the server and secure subsequent client-server
-   communications.  This provides Kerberos with functional equivalence
-   to TLS [RFC2246] in environments where Kerberos is a more attractive
-   authentication mechanism.
-
-   Using this mechanism, the client has to reveal its identity in its
-   initial request to its own Key Distribution Center (KDC) [RFC4120],
-   and then it can remain anonymous thereafter to KDCs on the cross-
-   realm authentication path, if any, and to the server with which it
-   communicates.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  Definitions
-
-   The anonymous Kerberos realm name is a reserved realm name as defined
-   in [KRBNAM] and its value is the literal "RESERVED:ANONYMOUS".
-
-   The anonymous Kerberos principal name is a reserved Kerberos
-   principal name as defined in [KRBNAM], its name-type [RFC4120] is
-   KRB_NT_RESRVED [KRBNAM], and its name-string [RFC4120] is a sequence
-   of two KerberosString components: "RESERVED", "ANONYMOUS".
-
-   In this specification, only the client name or the client realm can
-   be anonymous; the server name or the server realm can not be
-   anonymous.
-
-   The transited field [RFC4120] of a ticket is an anonymous
-   authentication path if the tr-type field of the TransitedEncoding
-
-
-
-Zhu, et al.             Expires January 17, 2007                [Page 3]
-
-Internet-Draft         Kerberos Anonymity Support              July 2006
-
-
-   type [RFC4120] is NO-TRANSITED-INFO and the contents field is an
-   empty OCTET STRING.
-
-           NO-TRANSITED-INFO    TBA
-
-   This transited encoding type indicates that there is no information
-   available about the authentication path.
-
-   The anonymous ticket flag is defined as bit TBA (with the first bit
-   being bit 0) in the TicketFlags:
-
-           TicketFlags     ::= KerberosFlags
-             -- anonymous(TBA)
-             -- TicketFlags and KerberosFlags are defined in [RFC4120]
-
-   An anonymous ticket is a ticket that has all of the following
-   properties:
-
-   o  The cname field [RFC4120] contains the anonymous Kerberos
-      principal name.
-
-   o  The crealm field [RFC4120] contains either the realm name of the
-      client who made the request or the anonymous kerberos realm name,
-      based on the local policy of the KDC.
-
-   o  The transited field [RFC4120] can contain either the client's
-      "normal" authentication path according to Section 3.3.3.2 of
-      [RFC4120] or the anonymous authentication path.
-
-   o  It contains no information that can reveal the client's identity.
-      However the ticket can contain the client realm and the realms on
-      the authentication path, and the authorization data may provide
-      additional information of the client.  For example, an anonymous
-      principal that is only identifiable within a particular group of
-      users can be implemented by using authorization data.
-
-   o  The anonymous ticket flag is set.
-
-   Notes: The anonymous ticket flag MUST NOT be set by implementations
-   of this specification if the ticket is not an anonymous ticket.  The
-   server principal name and the server realm in a cross-realm referral
-   TGT are not dependent on whether the client is the anonymous
-   principal or not.
-
-   The request-anonymous KDC option is defined as bit TBA (with the
-   first bit being bit 0) in the KDCOptions:
-
-
-
-
-
-Zhu, et al.             Expires January 17, 2007                [Page 4]
-
-Internet-Draft         Kerberos Anonymity Support              July 2006
-
-
-           KDCOptions      ::= KerberosFlags
-             -- request-anonymous(TBA)
-             -- KDCOptions and KerberosFlags are defined in [RFC4120]
-
-
-4.  Protocol Description
-
-   In order to request an anonymous ticket, the client sets the request-
-   anonymous KDC option in an Authentication Exchange (AS) or Ticket
-   Granting Service (TGS) request [RFC4120].  The client can request an
-   anonymous TGT based on a normal TGT.  Note that if the ticket in the
-   PA-TGS-REQ [RFC4120] is anonymous, the request-anonymous KDC option
-   MUST be set in the request.
-
-   When propagating authorization data, care MUST be taken by the TGS to
-   ensure that the client confidentiality is not violated: the TGS MUST
-   either fail the request or remove authorization data that may reveal
-   the client's identity.  An optional authorization element unknown by
-   the TGS MUST be removed if it can be ignored (such as ones enclosed
-   in the AD-IF-RELEVANT or the AD-KDCIssued containers [RFC4120]).  The
-   TGS can strip critical unknown authorization data if such data do not
-   convey any rights based on the requesting client's identity.  Here is
-   a table of the known authorization-data elements, flagged with
-   whether they interfere with client anonymity and recommendations for
-   how to process them.
-
-         ad-type          References  Can Breach Confidentiality?
-     ------------------------------------------------------------------
-     AD-IF-RELEVANT        RFC4120     Yes, remove if unknown
-     AD-KDCIssued          RFC4120     Yes, remove if unknown
-     AD-AND-OR             RFC4120     Yes, remove if unknown
-     AD-MANDATORY-FOR-KDC  RFC4120     Yes, fail the request if unknown
-
-   If it is inappropriate to remove an authorization element from the
-   TGS request in order to produce an anonymous ticket, the KDC MUST
-   return an error message with the code KDC_ERR_POLICY [RFC4120].
-
-   When policy allows, the KDC issues an anonymous ticket.  The client
-   realm in the anonymous ticket can be the anonymous realm name based
-   on local policy.  The client name and the client realm the
-   EncKDCRepPart of the reply [RFC4120] MUST match with the
-   corresponding client name and the client realm of the anonymous reply
-   ticket.  The client then MUST use the client name and the client
-   realm returned in the EncKDCRepPart in subsequent message exchanges
-   when using that anonymous ticket.
-
-   If there is a key known by both the client and the KDC for encrypting
-   the KDC reply, the cname field in the request [RFC4120] can be
-
-
-
-Zhu, et al.             Expires January 17, 2007                [Page 5]
-
-Internet-Draft         Kerberos Anonymity Support              July 2006
-
-
-   anonymous.  If the client is anonymous and the KDC does not have a
-   key to encrypt the reply, the KDC MUST return an error message with
-   the code KDC_ERR_NULL_KEY [RFC4120].  For AS exchange, if the reply
-   key is selected from the client keys (for example, as described in
-   Section 3.1.3 of [RFC4120]), then the client principal MUST NOT be
-   anonymous.  The client can use the client keys to request an
-   anonymous TGT in the AS request.  The anonymous client name, for
-   example, can be used in conjunction with PKINIT [RFC4556].  An
-   anonymous PKINIT client can authenticate the KDC based on the KDC
-   certificate.  For TGS exchange, the reply key is selected according
-   to Section 3.3.3 of [RFC4120] as normal.
-
-   The KDC fills out the transited field of the anonymous ticket in the
-   reply as follows: If the service ticket in a TGS request is an
-   anonymous ticket with a "normal" authentication path, then the
-   authentication path in the reply ticket MUST also contain a "normal"
-   authentication path: the TGS MUST add the name of the previous realm.
-   However, if the service ticket in a TGS request is an anonymous
-   ticket with an anonymous authentication path, then the reply ticket
-   can contain either an anonymous authentication path or a "normal"
-   authentication path, based on the local policy of the KDC.  Thus a
-   "normal" authentication path in an anonymous ticket can be a partial
-   path: it may not include all the intermediate realms on the
-   authentication path.
-
-   The KDC fills out the authtime field of the anonymous ticket in the
-   reply as follows: If the anonymous ticket is returned in an AS
-   exchange, the authtime field of the ticket contains the request time.
-   If the anonymous ticket is returned in a TGS exchange, the authtime
-   field contains the time of the initial authentication for the
-   principal who has made the request.  An anonymous ticket can be
-   renewed, and the authtime field of a renewed ticket is the authtime
-   in the anonymous ticket that the renewed ticket was based on.
-
-   If a client requires anonymous communication then the client MUST
-   check to make sure that the ticket in the reply is actually anonymous
-   by checking the presence of the anonymous ticket flag.  Because KDCs
-   ignore unknown KDC options, a KDC that does not understand the
-   request-anonymous KDC option will not return an error, but will
-   instead return a normal ticket.
-
-   The subsequent client and server communications then proceed as
-   described in [RFC4120].  No transited policy checking is needed for
-   the anonymous authentication path.  However, transited policy checks
-   defined in Section 2.7 of [RFC4120] would apply to an anonymous
-   ticket that contains a "normal" authentication path.
-
-   A server accepting an anonymous service ticket may assume that
-
-
-
-Zhu, et al.             Expires January 17, 2007                [Page 6]
-
-Internet-Draft         Kerberos Anonymity Support              July 2006
-
-
-   subsequent requests using the same ticket originate from the same
-   client.  Requests with different tickets are likely to originate from
-   different clients.
-
-   Interoperability and backward-compatibility notes: the KDC is given
-   the task of rejecting a request for an anonymous ticket when the
-   anonymous ticket is not acceptable by the server.
-
-
-5.  GSS-API Implementation Notes
-
-   At the GSS-API [RFC2743] level, the use of an anonymous principal by
-   the initiator/client requires a software change of the initiator/
-   client software (to assert the "anonymous" flag when calling
-   GSS_Init_Sec_Context().
-
-   GSS-API does not know or define "anonymous credentials", so the
-   (printable) name of the anonymous principal will rarely be used by or
-   relevant for the initator/client.  The printable name is relevant for
-   the acceptor/server when performing an authorization decision based
-   on the name that pops up from GSS_Accept_Sec_Context() upon
-   successful security context establishment.
-
-   A GSS-API initiator MUST carefully check the resulting context
-   attributes from the initial call to GSS_Init_Sec_Context() when
-   requesting anonymity, because (as in the GSS-API tradition and for
-   backwards compatibility) anonymity is just another optional context
-   attribute.  It could be that the mechanism doesn't recognize the
-   attribute at all or that anonymity is not available for some other
-   reasons -- and in that case the initiator must NOT send the initial
-   security context token to the acceptor, because it will likely reveal
-   the initiators identity to the acceptor, something that can rarely be
-   "un-done".
-
-   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
-   represent the anonymous identity.  In addition, Section 2.1.1 of
-   [RFC1964] defines the single string representation of a Kerberos
-   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  For
-   the anonymous principals, the name component within the exportable
-   name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm
-   name according to Section 2.1.1 of [RFC1964].  In this specification
-   only the client/initiator can be the anonymous identity.
-
-   Portable initiators are RECOMMENDED to use default credentials
-   whenever possible, and request anonymity only through the input
-   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().
-
-
-
-
-
-Zhu, et al.             Expires January 17, 2007                [Page 7]
-
-Internet-Draft         Kerberos Anonymity Support              July 2006
-
-
-6.  Security Considerations
-
-   Since KDCs ignore unknown options [RFC4120], a client requiring
-   anonymous communication needs to make sure that the ticket is
-   actually anonymous.  A KDC that that does not understand the
-   anonymous option would not return an anonymous ticket.
-
-   By using the mechanism defined in this specification, the client does
-   not reveal its identity to the server but its identity may be
-   revealed to the KDC of the server principal (when the server
-   principal is in a different realm than that of the client), and any
-   KDC on the cross-realm authentication path.  The Kerberos client MUST
-   verify the ticket being used is indeed anonymous before communicating
-   with the cross-realm KDC or the server, otherwise the client's
-   identity may be revealed to the server unintentionally.
-
-   In cases where specific server principals must not have access to the
-   client's identity (for example, an anonymous poll service), the KDC
-   can define server principal specific policy that insure any normal
-   service ticket can NEVER be issued to any of these server principals.
-
-   If the KDC that issued an anonymous ticket were to maintain records
-   of the association of identities to an anonymous ticket, then someone
-   obtaining such records could breach the anonymity.  Additionally, the
-   implementation of most (for now all) KDC's respond to requests at the
-   time that they are received.  Traffic analasys on the connection to
-   the KDC will allow an attacket to match client identities to
-   anonymous tickets issued.  Because there are plaintext parts of the
-   tickets that are exposed on the wire, such matching by a third party
-   observer is relatively straigtforward.
-
-
-7.  Acknowledgements
-
-   The authors would like to thank the following individuals for their
-   insightful comments and fruitful discussions: Sam Hartman, Clifford
-   Neuman, Martin Rex, Nicolas Williams, Jeffery Altman, Tom Yu,
-   Chaskiel M Grundman, Love Hoernquist Aestrand, and Jeffery Hutzelman.
-
-
-8.  IANA Considerations
-
-   No IANA actions are required for this document.
-
-9.  Normative References
-
-   [KRBNAM]   Zhu, L., "Additonal Kerberos Naming Contraints", 
-              draft-ietf-krb-wg-naming, work in progress.
-
-
-
-Zhu, et al.             Expires January 17, 2007                [Page 8]
-
-Internet-Draft         Kerberos Anonymity Support              July 2006
-
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires January 17, 2007                [Page 9]
-
-Internet-Draft         Kerberos Anonymity Support              July 2006
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Paul Leach
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: paulle@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires January 17, 2007               [Page 10]
-
-Internet-Draft         Kerberos Anonymity Support              July 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.             Expires January 17, 2007               [Page 11]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-anon-02.txt b/doc/standardisation/draft-ietf-krb-wg-anon-02.txt
deleted file mode 100644
index 406382d6b..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-anon-02.txt
+++ /dev/null
@@ -1,617 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                                  P. Leach
-Updates: 4120 (if approved)                                K. Jaganathan
-Intended status: Standards Track                   Microsoft Corporation
-Expires: April 14, 2007                                 October 11, 2006
-
-
-                     Anonymity Support for Kerberos
-                       draft-ietf-krb-wg-anon-02
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 14, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document defines extensions to the Kerberos protocol for the
-   Kerberos client to authenticate the Kerberos Key Distribution Center
-   and the Kerberos server, without revealing the client's identity.
-   These extensions can be used to secure communication between the
-   anonymous client and the server.
-
-
-
-
-
-Zhu, et al.              Expires April 14, 2007                 [Page 1]
-
-Internet-Draft         Kerberos Anonymity Support           October 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  5
-   5.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . .  7
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
-   Intellectual Property and Copyright Statements . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires April 14, 2007                 [Page 2]
-
-Internet-Draft         Kerberos Anonymity Support           October 2006
-
-
-1.  Introduction
-
-   In certain situations, the Kerberos [RFC4120] client may wish to
-   authenticate a server and/or protect communications without revealing
-   its own identity.  For example, consider an application which
-   provides read access to a research database, and which permits
-   queries by arbitrary requestors.  A client of such a service might
-   wish to authenticate the service, to establish trust in the
-   information received from it, but might not wish to disclose its
-   identity to the service for privacy reasons.
-
-   Extensions to [RFC4120] are specified in this document by which a
-   client can authenticate the KDC and request an anonymous ticket.  The
-   client can use the anonymous ticket to authenticate the server and
-   protect subsequent client-server communications.  These extensions
-   provide Kerberos with functional equivalence to Transport Layer
-   Security (TLS) [RFC4346].
-
-   By using the extensions defined in this specification, the client MAY
-   reveal its identity in its initial request to its own KDC, but it can
-   remain anonymous thereafter to KDCs on the cross-realm authentication
-   path, and to the server with which it communicates.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  Definitions
-
-   The anonymous Kerberos realm name is a reserved realm name based on
-   [KRBNAM].  The value is the literal "RESERVED:ANONYMOUS".
-
-   The anonymous Kerberos principal name is a reserved Kerberos
-   principal name based on [KRBNAM].  The value of the name-type field
-   is KRB_NT_RESRVED [KRBNAM], and the value of the name-string field is
-   a sequence of two KerberosString components: "RESERVED", "ANONYMOUS".
-
-   Note that in this specification, the anonymous principal name and
-   realm are only applicable to the client in Kerberos messages, the
-   server MUST NOT be anonymous in any Kerberos message.
-
-   The transited field [RFC4120] of a ticket is an anonymous
-   authentication path if the tr-type field of the TransitedEncoding
-   type [RFC4120] is NO-TRANSITED-INFO and the contents field is an
-
-
-
-Zhu, et al.              Expires April 14, 2007                 [Page 3]
-
-Internet-Draft         Kerberos Anonymity Support           October 2006
-
-
-   empty OCTET STRING.
-
-           NO-TRANSITED-INFO    TBA
-
-   This means that no information of the authentication path is
-   disclosed.
-
-   The anonymous ticket flag is defined as bit TBA (with the first bit
-   being bit 0) in the TicketFlags:
-
-           TicketFlags     ::= KerberosFlags
-             -- anonymous(TBA)
-             -- TicketFlags and KerberosFlags are defined in [RFC4120]
-
-   An anonymous ticket is a ticket that has all of the following
-   properties:
-
-   o  The cname field [RFC4120] contains the anonymous Kerberos
-      principal name.
-
-   o  The crealm field [RFC4120] contains either the client's realm name
-      or the anonymous realm name.
-
-   o  The transited field [RFC4120] can contain either the client's
-      authentication path as described in Section 3.3.3.2 of [RFC4120]
-      or the anonymous authentication path.
-
-   o  The anonymous ticket contains no information that can reveal the
-      client's identity.  However the ticket MAY contain the client
-      realm and the realms on the authentication path, and authorization
-      data that MAY provide information related to the client's
-      identity.  For example, an anonymous principal that is only
-      identifiable within a particular group of users can be implemented
-      using authorization data and such authorization data, if included
-      in the anonymous ticket, shall disclose the client's membership of
-      that group.
-
-   o  The anonymous ticket flag is set.
-
-   The request-anonymous KDC option is defined as bit TBA (with the
-   first bit being bit 0) in the KDCOptions:
-
-           KDCOptions      ::= KerberosFlags
-             -- request-anonymous(TBA)
-             -- KDCOptions and KerberosFlags are defined in [RFC4120]
-
-
-
-
-
-
-Zhu, et al.              Expires April 14, 2007                 [Page 4]
-
-Internet-Draft         Kerberos Anonymity Support           October 2006
-
-
-4.  Protocol Description
-
-   In order to request an anonymous ticket, the client sets the request-
-   anonymous KDC option in an Authentication Exchange (AS) or Ticket
-   Granting Service (TGS) request [RFC4120].  The client can request an
-   anonymous TGT based on a normal TGT.  If the client wishes to
-   authenticate the KDC anonymously, it sets the client name as
-   anonymous in the AS exchange and provides a PA_PK_AS_REQ pre-
-   authentication data [RFC4556] where both the signerInfos field and
-   the certificates field of the SignedData [RFC3852] of PA_PK_AS_REQ
-   are empty.  Because the anonymous client does not have an associated
-   asymmetric key pair, the client MUST use the Diffie-Hellman key
-   agreement method by filling in the Diffie-Hellman domain parameters
-   in the clientPublicValue [RFC4556].
-
-   If the ticket in the PA-TGS-REQ [RFC4120] of the TGS request is
-   anonymous, or if the client in the AS request is anonymous, the
-   request-anonymous KDC option MUST be set in the request.
-
-   Upon receiving the AS request with a PA_PK_AS_REQ from the anonymous
-   client, the KDC skips the checks for the client's signature and the
-   client's public key (such as the verification of the binding between
-   the client's public key and the client name), but performs otherwise-
-   applicable checks, and proceeds as normal according to [RFC4556].
-   For example, the AS MUST check if the client's Diffie-Hellman domain
-   parameters are acceptable.  The Diffie-Hellman key agreement method
-   MUST be used and the reply key is derived according to Section
-   3.2.3.1 of [RFC4556].  If the clientPublicValue is not present in the
-   request, the KDC MUST return a KRB-ERROR [RFC4120] with the code
-   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556] and there is no
-   accompanying e-data.  The client that made the anonymous request can
-   authenticate the KDC based on the KDC's signature in the reply.  If
-   the KDC does not have an asymmetric key pair, it MAY reply
-   anonymously.  In which case, both the signerInfos field and the
-   certificates field of the SignedData [RFC3852] of PA_PK_AS_REP in the
-   reply are empty.  The server name in an anonymous reply contains the
-   name of the TGS.  Upon receipt of an anonymous KDC reply, the client
-   MUST reject the returned ticket if it can not authenticate the KDC
-   otherwise.
-
-   The client can use its keys to mutually authenticate with the KDC,
-   and request an anonymous TGT in the AS request.  And in that case,
-   the reply key is selected as normal according to Section 3.1.3 of
-   [RFC4120].
-
-   For the TGS exchange, the reply key is selected as normal according
-   to Section 3.3.3 of [RFC4120].
-
-
-
-
-Zhu, et al.              Expires April 14, 2007                 [Page 5]
-
-Internet-Draft         Kerberos Anonymity Support           October 2006
-
-
-   When policy allows, the KDC issues an anonymous ticket.  Based on
-   local policy, the client realm in the anonymous ticket can be the
-   anonymous realm name or the realm of the KDC.  However, in all cases,
-   the client name and the client realm in the EncKDCRepPart of the
-   reply [RFC4120] MUST match with the corresponding client name and the
-   client realm of the anonymous ticket in the reply.  The client MUST
-   use the client name and the client realm returned in the
-   EncKDCRepPart in subsequent message exchanges when using the obtained
-   anonymous ticket.
-
-   During the TGS request, when propagating authorization data, care
-   MUST be taken by the TGS to ensure that the client confidentiality is
-   not violated.  The TGS MUST either fail the request or remove
-   authorization data that may reveal the client's identity.  An
-   optional authorization element unknown by the TGS MUST be removed if
-   it can be ignored (such as ones enclosed in the AD-IF-RELEVANT
-   structure).  The TGS can only strip critical unknown authorization
-   data if the ticket does not convey any rights such as those conveyed
-   by a KDCIssued authorization data element.  If a ticket contains a
-   KDCIssued authorization data element, then no other authorization
-   data elements may be removed if they could serve to limit the rights
-   conveyed by the KDCIssued element.  Here is a table of the known
-   authorization-data elements, tagged with whether they interfere with
-   client anonymity and recommendations for how to process them:
-
-         ad-type          References  Can Breach Confidentiality?
-     ------------------------------------------------------------------
-     AD-IF-RELEVANT        RFC4120     Yes, remove if unknown
-     AD-KDCIssued          RFC4120     Yes, fail the request if unknown
-     AD-AND-OR             RFC4120     Yes, remove if unknown
-     AD-MANDATORY-FOR-KDC  RFC4120     Yes, fail the request if unknown
-
-   The KDC fills out the transited field of the anonymous ticket in the
-   reply as follows: If the service ticket in a TGS request is an
-   anonymous ticket with a "normal" authentication path, then the
-   authentication path in the reply ticket MUST also contain a "normal"
-   authentication path, the TGS MUST add the name of the previous realm.
-   However, if the service ticket in a TGS request is an anonymous
-   ticket with an anonymous authentication path, then the reply ticket
-   can contain either an anonymous authentication path or a "normal"
-   authentication path, based on local policy of the KDC.  Thus a
-   "normal" authentication path in an anonymous ticket can be a partial
-   path, it may not include all the intermediate realms on the
-   authentication path.
-
-   The KDC fills out the authtime field of the anonymous ticket in the
-   reply as follows: If the anonymous ticket is returned in an AS
-   exchange, the authtime field of the ticket contains the request time.
-
-
-
-Zhu, et al.              Expires April 14, 2007                 [Page 6]
-
-Internet-Draft         Kerberos Anonymity Support           October 2006
-
-
-   If the anonymous ticket is returned in a TGS exchange, the authtime
-   field contains the authtime of the ticket in the PA-TGS-REQ
-   [RFC4120].  An anonymous ticket can be renewed, and the authtime
-   field of a renewed ticket is the authtime in the anonymous ticket on
-   which the renewed ticket was based.
-
-   If it is inappropriate to remove an authorization element from the
-   TGS request in order to produce an anonymous ticket, the KDC MUST
-   return an error message with the code KDC_ERR_POLICY [RFC4120].
-
-   If the client is anonymous and the KDC does not have a key to encrypt
-   the reply, the KDC MUST return an error message with the code
-   KDC_ERR_NULL_KEY [RFC4120] and there is no accompanying e-data.
-
-   If a client requires anonymous communication then the client MUST
-   check to make sure that the ticket in the reply is actually anonymous
-   by checking the presence of the anonymous ticket flag.  This is
-   because KDCs ignore unknown KDC options.  A KDC that does not
-   understand the request-anonymous KDC option will not return an error,
-   but will instead return a normal ticket.
-
-   The subsequent client and server communications then proceed as
-   described in [RFC4120].  No transited policy checking is needed for
-   the anonymous authentication path.  However, transited policy checks
-   defined in Section 2.7 of [RFC4120] would apply to an anonymous
-   ticket that contains a "normal" authentication path.
-
-   A server accepting an anonymous service ticket may assume that
-   subsequent requests using the same ticket originate from the same
-   client.  Requests with different tickets are likely to originate from
-   different clients.
-
-   Interoperability and backward-compatibility notes: the KDC is given
-   the task of rejecting a request for an anonymous ticket when the
-   anonymous ticket is not acceptable by the server.
-
-
-5.  GSS-API Implementation Notes
-
-   At the GSS-API [RFC2743] level, the use of an anonymous principal by
-   the initiator/client requires the initiator/client to assert the
-   "anonymous" flag when calling GSS_Init_Sec_Context().
-
-   GSS-API does not know or define "anonymous credentials", so the
-   (printable) name of the anonymous principal will rarely be used by or
-   relevant for the initiator/client.  The printable name is relevant
-   for the acceptor/server when performing an authorization decision
-   based on the name that pops up from GSS_Accept_Sec_Context() upon
-
-
-
-Zhu, et al.              Expires April 14, 2007                 [Page 7]
-
-Internet-Draft         Kerberos Anonymity Support           October 2006
-
-
-   successful security context establishment.
-
-   A GSS-API initiator MUST carefully check the resulting context
-   attributes from the initial call to GSS_Init_Sec_Context() when
-   requesting anonymity, because (as in the GSS-API tradition and for
-   backwards compatibility) anonymity is just another optional context
-   attribute.  It could be that the mechanism doesn't recognize the
-   attribute at all or that anonymity is not available for some other
-   reasons -- and in that case the initiator must NOT send the initial
-   security context token to the acceptor, because it will likely reveal
-   the initiators identity to the acceptor, something that can rarely be
-   "un-done".
-
-   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
-   represent the anonymous identity.  In addition, Section 2.1.1 of
-   [RFC1964] defines the single string representation of a Kerberos
-   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  For
-   the anonymous principals, the name component within the exportable
-   name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm
-   name according to Section 2.1.1 of [RFC1964].  Note that in this
-   specification only the client/initiator can be anonymous.
-
-   Portable initiators are RECOMMENDED to use default credentials
-   whenever possible, and request anonymity only through the input
-   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().
-
-
-6.  Security Considerations
-
-   Since KDCs ignore unknown options [RFC4120], a client requiring
-   anonymous communication needs to make sure that the ticket is
-   actually anonymous.  This is because a KDC that that does not
-   understand the anonymous option would not return an anonymous ticket.
-
-   By using the mechanism defined in this specification, the client does
-   not reveal its identity to the server but its identity may be
-   revealed to the KDC of the server principal (when the server
-   principal is in a different realm than that of the client), and any
-   KDC on the cross-realm authentication path.  The Kerberos client MUST
-   verify the ticket being used is indeed anonymous before communicating
-   with the server, otherwise the client's identity may be revealed
-   unintentionally.
-
-   In cases where specific server principals must not have access to the
-   client's identity (for example, an anonymous poll service), the KDC
-   can define server principal specific policy that insure any normal
-   service ticket can NEVER be issued to any of these server principals.
-
-
-
-
-Zhu, et al.              Expires April 14, 2007                 [Page 8]
-
-Internet-Draft         Kerberos Anonymity Support           October 2006
-
-
-   If the KDC that issued an anonymous ticket were to maintain records
-   of the association of identities to an anonymous ticket, then someone
-   obtaining such records could breach the anonymity.  Additionally, the
-   implementations of most (for now all) KDC's respond to requests at
-   the time that they are received.  Traffic analysis on the connection
-   to the KDC will allow an attacker to match client identities to
-   anonymous tickets issued.  Because there are plaintext parts of the
-   tickets that are exposed on the wire, such matching by a third party
-   observer is relatively straightforward.
-
-
-7.  Acknowledgements
-
-   Clifford Neuman contributed the core notions of this document.
-
-   Martin Rex wrote the text for GSS-API considerations.
-
-   Nicolas Williams reviewed the GSS-API considerations section and
-   suggested ideas for improvements.
-
-   Sam Hartman and Nicolas Williams were great champions of this work.
-
-   In addition, the following individuals made significant
-   contributions: Jeffery Altman, Tom Yu, Chaskiel M Grundman, Love
-   Hoernquist Aestrand, and Jeffery Hutzelman.
-
-
-8.  IANA Considerations
-
-   Section 3 defines the anonymous Kerberos name and the anonymous
-   Kerberos realm based on [KRBNAM].  The IANA registry for [KRBNAM]
-   need to be updated to add references to this document.
-
-
-9.  Normative References
-
-   [KRBNAM]   Zhu, L., "Additonal Kerberos Naming Contraints", 
-              draft-ietf-krb-wg-naming, work in progress.
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-
-
-
-Zhu, et al.              Expires April 14, 2007                 [Page 9]
-
-Internet-Draft         Kerberos Anonymity Support           October 2006
-
-
-              RFC 3852, July 2004.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Paul Leach
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: paulle@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires April 14, 2007                [Page 10]
-
-Internet-Draft         Kerberos Anonymity Support           October 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Zhu, et al.              Expires April 14, 2007                [Page 11]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-anon-03.txt b/doc/standardisation/draft-ietf-krb-wg-anon-03.txt
deleted file mode 100644
index 3a53f63ab..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-anon-03.txt
+++ /dev/null
@@ -1,617 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                                  P. Leach
-Updates: 4120 (if approved)                                K. Jaganathan
-Intended status: Standards Track                   Microsoft Corporation
-Expires: September 3, 2007                                 March 2, 2007
-
-
-                     Anonymity Support for Kerberos
-                       draft-ietf-krb-wg-anon-03
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 3, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   This document defines extensions to the Kerberos protocol for the
-   Kerberos client to authenticate the Kerberos Key Distribution Center
-   and the Kerberos server, without revealing the client's identity.
-   These extensions can be used to secure communication between the
-   anonymous client and the server.
-
-
-
-
-
-Zhu, et al.             Expires September 3, 2007               [Page 1]
-
-Internet-Draft         Kerberos Anonymity Support             March 2007
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  4
-   5.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . .  7
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
-   Intellectual Property and Copyright Statements . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires September 3, 2007               [Page 2]
-
-Internet-Draft         Kerberos Anonymity Support             March 2007
-
-
-1.  Introduction
-
-   In certain situations, the Kerberos [RFC4120] client may wish to
-   authenticate a server and/or protect communications without revealing
-   its own identity.  For example, consider an application which
-   provides read access to a research database, and which permits
-   queries by arbitrary requestors.  A client of such a service might
-   wish to authenticate the service, to establish trust in the
-   information received from it, but might not wish to disclose its
-   identity to the service for privacy reasons.
-
-   Extensions to [RFC4120] are specified in this document by which a
-   client can authenticate the Key Distribution Center (KDC) and request
-   an anonymous ticket.  The client can use the anonymous ticket to
-   authenticate the server and protect subsequent client-server
-   communications.  These extensions provide Kerberos with functional
-   equivalence to Transport Layer Security (TLS) [RFC4346].
-
-   By using the extensions defined in this specification, the client may
-   reveal its identity in its initial request to its own KDC, but it can
-   remain anonymous thereafter to KDCs on the cross-realm authentication
-   path, and to the server with which it communicates.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  Definitions
-
-   The anonymous Kerberos realm name is defined as a well-known realm
-   name based on [KRBNAM].  The value is the literal "WELLKNOWN:
-   ANONYMOUS".  An anonymous Kerberos realm name MUST NOT be present in
-   the transited field [RFC4120] of a ticket.
-
-   The anonymous Kerberos principal name is defined as a well-known
-   Kerberos principal name based on [KRBNAM].  The value of the name-
-   type field [RFC4120] is KRB_NT_RESRVED [KRBNAM], and the value of the
-   name-string field [RFC4120] is a sequence of two KerberosString
-   components: "WELLKNOWN", "ANONYMOUS".
-
-   Note that in this specification, the anonymous principal name and
-   realm are only applicable to the client in Kerberos messages, the
-   server MUST NOT be anonymous in any Kerberos message.
-
-
-
-
-Zhu, et al.             Expires September 3, 2007               [Page 3]
-
-Internet-Draft         Kerberos Anonymity Support             March 2007
-
-
-   The anonymous ticket flag is defined as bit TBA (with the first bit
-   being bit 0) in the TicketFlags:
-
-           TicketFlags     ::= KerberosFlags
-             -- anonymous(TBA)
-             -- TicketFlags and KerberosFlags are defined in [RFC4120]
-
-   An anonymous ticket is a ticket that has all of the following
-   properties:
-
-   o  The cname field [RFC4120] contains the anonymous Kerberos
-      principal name.
-
-   o  The crealm field [RFC4120] contains the client's realm name, or
-      the name of the realm that issued the initial ticket for the
-      client principal, or the anonymous realm name.
-
-   o  The anonymous ticket contains no information that can reveal the
-      client's identity.  However the ticket may contain the client
-      realm, intermediate realms on the client's authentication path,
-      and authorization data that may provide information related to the
-      client's identity.  For example, an anonymous principal that is
-      identifiable only within a particular group of users can be
-      implemented using authorization data and such authorization data,
-      if included in the anonymous ticket, shall disclose the client's
-      membership of that group.
-
-   o  The anonymous ticket flag is set.
-
-   The request-anonymous KDC option is defined as bit TBA (with the
-   first bit being bit 0) in the KDCOptions:
-
-           KDCOptions      ::= KerberosFlags
-             -- request-anonymous(TBA)
-             -- KDCOptions and KerberosFlags are defined in [RFC4120]
-
-   As described in Section 4, the request-anonymous KDC option is set to
-   request an anonymous ticket.
-
-
-4.  Protocol Description
-
-   In order to request an anonymous ticket, the client sets the request-
-   anonymous KDC option in an Authentication Exchange (AS) or Ticket
-   Granting Service (TGS) request [RFC4120].  The client can request an
-   anonymous Ticket Granting Ticket (TGT) based on a normal TGT.  Unless
-   otherwise specified, the client can obtain an anonymous ticket with
-   the anonymous realm name only by requesting an anonymous ticket in an
-
-
-
-Zhu, et al.             Expires September 3, 2007               [Page 4]
-
-Internet-Draft         Kerberos Anonymity Support             March 2007
-
-
-   AS exchange with the client realm set as anonymous in the request.
-
-   If the client wishes to authenticate the KDC anonymously, it sets the
-   client name as anonymous in the AS exchange and provides a
-   PA_PK_AS_REQ pre-authentication data [RFC4556] where both the
-   signerInfos field and the certificates field of the SignedData
-   [RFC3852] of the PA_PK_AS_REQ are empty.  Because the anonymous
-   client does not have an associated asymmetric key pair, the client
-   MUST choose the Diffie-Hellman key agreement method by filling in the
-   Diffie-Hellman domain parameters in the clientPublicValue [RFC4556].
-
-   If the ticket in the PA-TGS-REQ [RFC4120] of the TGS request is
-   anonymous, or if the client in the AS request is anonymous, the
-   request-anonymous KDC option MUST be set in the request.  Otherwise,
-   the KDC MUST return a KRB-ERROR message with the code
-   KDC_ERR_BADOPTION [RFC4120], and there is no accompanying e-data
-   defined in this document.
-
-   Upon receiving the AS request with a PA_PK_AS_REQ [RFC4556] from the
-   anonymous client, the KDC processes the request according to Section
-   3.1.2 of [RFC4120].  The KDC skips the checks for the client's
-   signature and the client's public key (such as the verification of
-   the binding between the client's public key and the client name), but
-   performs otherwise-applicable checks, and proceeds as normal
-   according to [RFC4556].  For example, the AS MUST check if the
-   client's Diffie-Hellman domain parameters are acceptable.  The
-   Diffie-Hellman key agreement method MUST be used and the reply key is
-   derived according to Section 3.2.3.1 of [RFC4556].  If the
-   clientPublicValue is not present in the request, the KDC MUST return
-   a KRB-ERROR [RFC4120] with the code
-   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556] and there is no
-   accompanying e-data.  If all goes well, an anonymous ticket is
-   generated according to Section 3.1.3 of [RFC4120] and a PA_PK_AS_REP
-   [RFC4556] pre-authentication data is included in the KDC reply
-   according to [RFC4556].  If the KDC does not have an asymmetric key
-   pair, it MAY reply anonymously or reject the authentication attempt.
-   If the KDC replies anonymously, both the signerInfos field and the
-   certificates field of the SignedData [RFC3852] of PA_PK_AS_REP in the
-   reply are empty.  The server name in the anonymous KDC reply contains
-   the name of the TGS.
-
-   Upon receipt of the KDC reply that contains an anonymous ticket and a
-   PA_PK_AS_REP [RFC4556] pre-authentication data, the client can then
-   authenticate the KDC based on the KDC's signature in the
-   PA_PK_AS_REP.  If the KDC's signature is missing in the KDC reply
-   (the reply is anonymous), the client MUST reject the returned ticket
-   if it cannot authenticate the KDC otherwise.
-
-
-
-
-Zhu, et al.             Expires September 3, 2007               [Page 5]
-
-Internet-Draft         Kerberos Anonymity Support             March 2007
-
-
-   The client can use the client keys to mutually authenticate with the
-   KDC, request an anonymous TGT in the AS request.  And in that case,
-   the reply key is selected as normal according to Section 3.1.3 of
-   [RFC4120].
-
-   For the TGS exchange, the reply key is selected as normal according
-   to Section 3.3.3 of [RFC4120].
-
-   When policy allows, the KDC issues an anonymous ticket.  Based on
-   local policy, the client realm in the anonymous ticket can be the
-   anonymous realm name or the realm of the KDC.  However, in all cases,
-   the client name and the client realm in the EncKDCRepPart of the
-   reply [RFC4120] MUST match with the corresponding client name and the
-   client realm of the anonymous ticket in the reply.  The client MUST
-   use the client name and the client realm returned in the
-   EncKDCRepPart in subsequent message exchanges when using the obtained
-   anonymous ticket.
-
-   During the TGS request, when propagating authorization data, care
-   MUST be taken by the TGS to ensure that the client confidentiality is
-   not violated.  If a anonymous ticket is returned, any authorization
-   element that may reveal the client's identity MUST be removed.  The
-   authentication attempt MUST be rejected if there is an authorization
-   element that is intended to restrict the use of the ticket thus
-   cannot be removed or the local policy prevents the removal of an
-   authorization element, and this rule MUST be applied to all critical
-   and optional authorization data.  An optional authorization element
-   unknown by the TGS MUST be removed if it does not potentially convey
-   any rights or limit the rights otherwise conveyed in the ticket.  If
-   there is a critical unknown authorization element, unless this
-   element is encapsulated in a known authorization data element
-   amending the criticality of the elements it contains, authentication
-   MUST fail according to [RFC4120].  If it is inappropriate to remove
-   an authorization element from the TGS request in order to produce an
-   anonymous ticket, the KDC MUST return an error message with the code
-   KDC_ERR_POLICY [RFC4120], and there is no accompanying e-data defined
-   in this document.
-
-   The TGS MUST add the name of the previous realm according to Section
-   3.3.3.2 of [RFC4120].  If the client's realm is the anonymous realm,
-   the abbreviation forms [RFC4120] that build on the preceding name
-   cannot be used at the start of the transited encoding.  The null-
-   subfield form (e.g., encoding ending with ",") [RFC4120] could not be
-   used next to the anonymous realm that can potentially be at the
-   beginning where the client realm is filled in.
-
-   The KDC fills out the authtime field of the anonymous ticket in the
-   reply as follows: If the anonymous ticket is returned in an AS
-
-
-
-Zhu, et al.             Expires September 3, 2007               [Page 6]
-
-Internet-Draft         Kerberos Anonymity Support             March 2007
-
-
-   exchange, the authtime field of the ticket contains the request time.
-   If the anonymous ticket is returned in a TGS exchange, the authtime
-   field contains the authtime of the ticket in the PA-TGS-REQ pre-
-   authentication data [RFC4120].  An anonymous ticket can be renewed,
-   and the authtime field of a renewed ticket is the authtime in the
-   anonymous ticket on which the renewed ticket was based.
-
-   If the client is anonymous and the KDC does not have a key to encrypt
-   the reply (this can happen when, for example, the KDC does not
-   support PKINIT [RFC4556]), the KDC MUST return an error message with
-   the code KDC_ERR_NULL_KEY [RFC4120] and there is no accompanying
-   e-data defined in this document.
-
-   If a client requires anonymous communication then the client MUST
-   check to make sure that the ticket in the reply is actually anonymous
-   by checking the presence of the anonymous ticket flag.  This is
-   because KDCs ignore unknown KDC options.  A KDC that does not
-   understand the request-anonymous KDC option will not return an error,
-   but will instead return a normal ticket.
-
-   The subsequent client and server communications then proceed as
-   described in [RFC4120].
-
-   A server accepting an anonymous service ticket may assume that
-   subsequent requests using the same ticket originate from the same
-   client.  Requests with different tickets are likely to originate from
-   different clients.
-
-
-5.  GSS-API Implementation Notes
-
-   At the GSS-API [RFC2743] level, the use of an anonymous principal by
-   the initiator/client requires the initiator/client to assert the
-   "anonymous" flag when calling GSS_Init_Sec_Context().
-
-   GSS-API does not know or define "anonymous credentials", so the
-   (printable) name of the anonymous principal will rarely be used by or
-   relevant for the initiator/client.  The printable name is relevant
-   for the acceptor/server when performing an authorization decision
-   based on the initiator name that is returned from the acceptor side
-   upon the successful security context establishment.
-
-   A GSS-API initiator MUST carefully check the resulting context
-   attributes from the initial call to GSS_Init_Sec_Context() when
-   requesting anonymity, because (as in the GSS-API tradition and for
-   backwards compatibility) anonymity is just another optional context
-   attribute.  It could be that the mechanism doesn't recognize the
-   attribute at all or that anonymity is not available for some other
-
-
-
-Zhu, et al.             Expires September 3, 2007               [Page 7]
-
-Internet-Draft         Kerberos Anonymity Support             March 2007
-
-
-   reasons -- and in that case the initiator must NOT send the initial
-   security context token to the acceptor, because it will likely reveal
-   the initiators identity to the acceptor, something that can rarely be
-   "un-done".
-
-   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
-   represent the anonymous identity.  In addition, Section 2.1.1 of
-   [RFC1964] defines the single string representation of a Kerberos
-   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  For
-   the anonymous principals, the name component within the exportable
-   name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm
-   name according to Section 2.1.1 of [RFC1964].  Note that in this
-   specification only the client/initiator can be anonymous.
-
-   Portable initiators are RECOMMENDED to use default credentials
-   whenever possible, and request anonymity only through the input
-   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().
-
-
-6.  Security Considerations
-
-   Since KDCs ignore unknown options [RFC4120], a client requiring
-   anonymous communication needs to make sure that the ticket is
-   actually anonymous.  This is because a KDC that that does not
-   understand the anonymous option would not return an anonymous ticket.
-
-   By using the mechanism defined in this specification, the client does
-   not reveal its identity to the server but its identity may be
-   revealed to the KDC of the server principal (when the server
-   principal is in a different realm than that of the client), and any
-   KDC on the cross-realm authentication path.  The Kerberos client MUST
-   verify the ticket being used is indeed anonymous before communicating
-   with the server, otherwise the client's identity may be revealed
-   unintentionally.
-
-   In cases where specific server principals must not have access to the
-   client's identity (for example, an anonymous poll service), the KDC
-   can define server principal specific policy that insure any normal
-   service ticket can NEVER be issued to any of these server principals.
-
-   If the KDC that issued an anonymous ticket were to maintain records
-   of the association of identities to an anonymous ticket, then someone
-   obtaining such records could breach the anonymity.  Additionally, the
-   implementations of most (for now all) KDC's respond to requests at
-   the time that they are received.  Traffic analysis on the connection
-   to the KDC will allow an attacker to match client identities to
-   anonymous tickets issued.  Because there are plaintext parts of the
-   tickets that are exposed on the wire, such matching by a third party
-
-
-
-Zhu, et al.             Expires September 3, 2007               [Page 8]
-
-Internet-Draft         Kerberos Anonymity Support             March 2007
-
-
-   observer is relatively straightforward.
-
-
-7.  Acknowledgements
-
-   Clifford Neuman contributed the core notions of this document.
-
-   Ken Raeburn reviewed the document and provided suggestions for
-   improvements.
-
-   Martin Rex wrote the text for GSS-API considerations.
-
-   Nicolas Williams reviewed the GSS-API considerations section and
-   suggested ideas for improvements.
-
-   Sam Hartman and Nicolas Williams were great champions of this work.
-
-   In addition, the following individuals made significant
-   contributions: Jeffery Altman, Tom Yu, Chaskiel M Grundman, Love
-   Hoernquist Aestrand, and Jeffery Hutzelman.
-
-
-8.  IANA Considerations
-
-   Section 3 defines the anonymous Kerberos name and the anonymous
-   Kerberos realm based on [KRBNAM].  The IANA registry for [KRBNAM]
-   need to be updated to add references to this document.
-
-
-9.  Normative References
-
-   [KRBNAM]   Zhu, L., "Additonal Kerberos Naming Contraints", 
-              draft-ietf-krb-wg-naming, work in progress.
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-
-
-Zhu, et al.             Expires September 3, 2007               [Page 9]
-
-Internet-Draft         Kerberos Anonymity Support             March 2007
-
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Paul Leach
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: paulle@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires September 3, 2007              [Page 10]
-
-Internet-Draft         Kerberos Anonymity Support             March 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Zhu, et al.             Expires September 3, 2007              [Page 11]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-anon-04.txt b/doc/standardisation/draft-ietf-krb-wg-anon-04.txt
deleted file mode 100644
index 8012859a6..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-anon-04.txt
+++ /dev/null
@@ -1,617 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                                  P. Leach
-Updates: 4120 (if approved)                        Microsoft Corporation
-Intended status: Standards Track                            July 7, 2007
-Expires: January 8, 2008
-
-
-                     Anonymity Support for Kerberos
-                       draft-ietf-krb-wg-anon-04
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 8, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   This document defines extensions to the Kerberos protocol for the
-   Kerberos client to authenticate the Kerberos Key Distribution Center
-   and the Kerberos server, without revealing the client's identity.
-   These extensions can be used to secure communication between the
-   anonymous client and the server.
-
-
-
-
-
-Zhu & Leach              Expires January 8, 2008                [Page 1]
-
-Internet-Draft         Kerberos Anonymity Support              July 2007
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  4
-   5.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . .  8
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
-   Intellectual Property and Copyright Statements . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Leach              Expires January 8, 2008                [Page 2]
-
-Internet-Draft         Kerberos Anonymity Support              July 2007
-
-
-1.  Introduction
-
-   In certain situations, the Kerberos [RFC4120] client may wish to
-   authenticate a server and/or protect communications without revealing
-   its own identity.  For example, consider an application which
-   provides read access to a research database, and which permits
-   queries by arbitrary requestors.  A client of such a service might
-   wish to authenticate the service, to establish trust in the
-   information received from it, but might not wish to disclose its
-   identity to the service for privacy reasons.
-
-   Extensions to [RFC4120] are specified in this document by which a
-   client can authenticate the Key Distribution Center (KDC) and request
-   an anonymous ticket.  The client can use the anonymous ticket to
-   authenticate the server and protect subsequent client-server
-   communications.  These extensions provide Kerberos with functional
-   equivalence to Transport Layer Security (TLS) [RFC4346].
-
-   By using the extensions defined in this specification, the client may
-   reveal its identity in its initial request to its own KDC, but it can
-   remain anonymous thereafter to KDCs on the cross-realm authentication
-   path, and to the server with which it communicates.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  Definitions
-
-   The anonymous Kerberos realm name is defined as a well-known realm
-   name based on [KRBNAM].  The value is the literal "WELLKNOWN:
-   ANONYMOUS".  An anonymous Kerberos realm name MUST NOT be present in
-   the transited field [RFC4120] of a ticket.
-
-   The anonymous Kerberos principal name is defined as a well-known
-   Kerberos principal name based on [KRBNAM].  The value of the name-
-   type field [RFC4120] is KRB_NT_WELLKNOWN [KRBNAM], and the value of
-   the name-string field [RFC4120] is a sequence of two KerberosString
-   components: "WELLKNOWN", "ANONYMOUS".
-
-   Note that in this specification, the anonymous principal name and
-   realm are only applicable to the client in Kerberos messages, the
-   server MUST NOT be anonymous in any Kerberos message.
-
-
-
-
-Zhu & Leach              Expires January 8, 2008                [Page 3]
-
-Internet-Draft         Kerberos Anonymity Support              July 2007
-
-
-   The anonymous ticket flag is defined as bit 14 (with the first bit
-   being bit 0) in the TicketFlags:
-
-           TicketFlags     ::= KerberosFlags
-             -- anonymous(14)
-             -- TicketFlags and KerberosFlags are defined in [RFC4120]
-
-   An anonymous ticket is a ticket that has all of the following
-   properties:
-
-   o  The cname field [RFC4120] contains the anonymous Kerberos
-      principal name.
-
-   o  The crealm field [RFC4120] contains the client's realm name, or
-      the name of the realm that issued the initial ticket for the
-      client principal, or the anonymous realm name.
-
-   o  The anonymous ticket contains no information that can reveal the
-      client's identity.  However the ticket may contain the client
-      realm, intermediate realms on the client's authentication path,
-      and authorization data that may provide information related to the
-      client's identity.  For example, an anonymous principal that is
-      identifiable only within a particular group of users can be
-      implemented using authorization data and such authorization data,
-      if included in the anonymous ticket, shall disclose the client's
-      membership of that group.
-
-   o  The anonymous ticket flag is set.
-
-   The anonymous KDC option is defined as bit 14 (with the first bit
-   being bit 0) in the KDCOptions:
-
-           KDCOptions      ::= KerberosFlags
-             -- anonymous(14)
-             -- KDCOptions and KerberosFlags are defined in [RFC4120]
-
-   As described in Section 4, the anonymous KDC option is set to request
-   an anonymous ticket.
-
-
-4.  Protocol Description
-
-   In order to request an anonymous ticket, the client sets the
-   anonymous KDC option in an Authentication Exchange (AS) or Ticket
-   Granting Service (TGS) request [RFC4120].  The client can request an
-   anonymous Ticket Granting Ticket (TGT) based on a normal TGT.  Unless
-   otherwise specified, the client can obtain an anonymous ticket with
-   the anonymous realm name only by requesting an anonymous ticket in an
-
-
-
-Zhu & Leach              Expires January 8, 2008                [Page 4]
-
-Internet-Draft         Kerberos Anonymity Support              July 2007
-
-
-   AS exchange with the client realm set as anonymous in the request.
-
-   If the client wishes to authenticate the KDC anonymously, it sets the
-   client name as anonymous in the AS exchange and provides a
-   PA_PK_AS_REQ pre-authentication data [RFC4556] where both the
-   signerInfos field and the certificates field of the SignedData
-   [RFC3852] of the PA_PK_AS_REQ are empty.  Because the anonymous
-   client does not have an associated asymmetric key pair, the client
-   MUST choose the Diffie-Hellman key agreement method by filling in the
-   Diffie-Hellman domain parameters in the clientPublicValue [RFC4556].
-
-   If the ticket in the PA-TGS-REQ [RFC4120] of the TGS request is
-   anonymous, or if the client in the AS request is anonymous, the
-   anonymous KDC option MUST be set in the request.  Otherwise, the KDC
-   MUST return a KRB-ERROR message with the code KDC_ERR_BADOPTION
-   [RFC4120], and there is no accompanying e-data defined in this
-   document.
-
-   Upon receiving the AS request with a PA_PK_AS_REQ [RFC4556] from the
-   anonymous client, the KDC processes the request according to Section
-   3.1.2 of [RFC4120].  The KDC skips the checks for the client's
-   signature and the client's public key (such as the verification of
-   the binding between the client's public key and the client name), but
-   performs otherwise-applicable checks, and proceeds as normal
-   according to [RFC4556].  For example, the AS MUST check if the
-   client's Diffie-Hellman domain parameters are acceptable.  The
-   Diffie-Hellman key agreement method MUST be used and the reply key is
-   derived according to Section 3.2.3.1 of [RFC4556].  If the
-   clientPublicValue is not present in the request, the KDC MUST return
-   a KRB-ERROR [RFC4120] with the code
-   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556] and there is no
-   accompanying e-data.  If all goes well, an anonymous ticket is
-   generated according to Section 3.1.3 of [RFC4120] and a PA_PK_AS_REP
-   [RFC4556] pre-authentication data is included in the KDC reply
-   according to [RFC4556].  If the KDC does not have an asymmetric key
-   pair, it MAY reply anonymously or reject the authentication attempt.
-   If the KDC replies anonymously, both the signerInfos field and the
-   certificates field of the SignedData [RFC3852] of PA_PK_AS_REP in the
-   reply are empty.  The server name in the anonymous KDC reply contains
-   the name of the TGS.
-
-   Upon receipt of the KDC reply that contains an anonymous ticket and a
-   PA_PK_AS_REP [RFC4556] pre-authentication data, the client can then
-   authenticate the KDC based on the KDC's signature in the
-   PA_PK_AS_REP.  If the KDC's signature is missing in the KDC reply
-   (the reply is anonymous), the client MUST reject the returned ticket
-   if it cannot authenticate the KDC otherwise.
-
-
-
-
-Zhu & Leach              Expires January 8, 2008                [Page 5]
-
-Internet-Draft         Kerberos Anonymity Support              July 2007
-
-
-   The client can use the client keys to mutually authenticate with the
-   KDC, request an anonymous TGT in the AS request.  And in that case,
-   the reply key is selected as normal according to Section 3.1.3 of
-   [RFC4120].
-
-   For the TGS exchange, the reply key is selected as normal according
-   to Section 3.3.3 of [RFC4120].
-
-   When policy allows, the KDC issues an anonymous ticket.  Based on
-   local policy, the client realm in the anonymous ticket can be the
-   anonymous realm name or the realm of the KDC.  However, in all cases,
-   the client name and the client realm in the EncKDCRepPart of the
-   reply [RFC4120] MUST match with the corresponding client name and the
-   client realm of the anonymous ticket in the reply.  The client MUST
-   use the client name and the client realm returned in the
-   EncKDCRepPart in subsequent message exchanges when using the obtained
-   anonymous ticket.
-
-   When propagating authorization data in the ticket or in the enc-
-   authorization-data field [RFC4120] of the request, the TGS MUST
-   ensure that the client confidentiality is not violated in the
-   returned anonymous ticket.  The TGS MUST process the authorization
-   data recursively according to Section 5.2.6 of [RFC4120] beyond the
-   container levels such that all embedded authorization elements are
-   interpreted.  Identity-based authorization data SHOULD NOT be present
-   in an anonymous ticket in that it typically reveals the client's
-   identity.  The specification of a new authorization data type MUST
-   specify the processing rules of the authorization data when an
-   anonymous ticket is returned.  If there is no processing rule defined
-   for an authorization data element or the authorization data element
-   is unknown, the TGS MUST process it when an anonymous ticket is
-   returned as follows:
-
-   o  If the authorization data element may reveal the client's
-      identity, it MUST be removed unless otherwise specified.
-
-   o  If the authorization data element is intended to restrict the use
-      of the ticket or limit the rights otherwise conveyed in the
-      ticket, it cannot be removed in order to hide the client's
-      identity.  In this case, the authentication attempt MUST be
-      rejected, and the KDC MUST return an error message with the code
-      KDC_ERR_POLICY [RFC4120].  There is no accompanying e-data defined
-      in this document.  Note this is applicable to both critical and
-      optional authorization data.
-
-   o  If the authorization data element is unknown, the TGS MAY remove
-      it, or transfer it into the returned anonymous ticket, or reject
-      the authentication attempt, based on local policy for that
-
-
-
-Zhu & Leach              Expires January 8, 2008                [Page 6]
-
-Internet-Draft         Kerberos Anonymity Support              July 2007
-
-
-      authorization data type unless otherwise specified.  If there is
-      no policy defined for a given unknown authorization data type, the
-      authentication MUST be rejected.  The error code is KDC_ERR_POLICY
-      when the authentication is rejected.
-
-   The AD-INITIAL-VERIFIED-CAS authorization data [RFC4556] MAY be
-   removed from an anonymous ticket based on local policy of the TGS.
-
-   The TGS MUST add the name of the previous realm according to Section
-   3.3.3.2 of [RFC4120].  If the client's realm is the anonymous realm,
-   the abbreviation forms [RFC4120] that build on the preceding name
-   cannot be used at the start of the transited encoding.  The null-
-   subfield form (e.g., encoding ending with ",") [RFC4120] could not be
-   used next to the anonymous realm that can potentially be at the
-   beginning where the client realm is filled in.
-
-   The KDC fills out the authtime field of the anonymous ticket in the
-   reply as follows: If the anonymous ticket is returned in an AS
-   exchange, the authtime field of the ticket contains the request time.
-   If the anonymous ticket is returned in a TGS exchange, the authtime
-   field contains the authtime of the ticket in the PA-TGS-REQ pre-
-   authentication data [RFC4120].  An anonymous ticket can be renewed,
-   and the authtime field of a renewed ticket is the authtime in the
-   anonymous ticket on which the renewed ticket was based.
-
-   If the client is anonymous and the KDC does not have a key to encrypt
-   the reply (this can happen when, for example, the KDC does not
-   support PKINIT [RFC4556]), the KDC MUST return an error message with
-   the code KDC_ERR_NULL_KEY [RFC4120] and there is no accompanying
-   e-data defined in this document.
-
-   If a client requires anonymous communication then the client MUST
-   check to make sure that the ticket in the reply is actually anonymous
-   by checking the presence of the anonymous ticket flag.  This is
-   because KDCs ignore unknown KDC options.  A KDC that does not
-   understand the anonymous KDC option will not return an error, but
-   will instead return a normal ticket.
-
-   The subsequent client and server communications then proceed as
-   described in [RFC4120].
-
-   A server accepting an anonymous service ticket may assume that
-   subsequent requests using the same ticket originate from the same
-   client.  Requests with different tickets are likely to originate from
-   different clients.
-
-
-
-
-
-
-Zhu & Leach              Expires January 8, 2008                [Page 7]
-
-Internet-Draft         Kerberos Anonymity Support              July 2007
-
-
-5.  GSS-API Implementation Notes
-
-   At the GSS-API [RFC2743] level, the use of an anonymous principal by
-   the initiator/client requires the initiator/client to assert the
-   "anonymous" flag when calling GSS_Init_Sec_Context().
-
-   GSS-API does not know or define "anonymous credentials", so the
-   (printable) name of the anonymous principal will rarely be used by or
-   relevant for the initiator/client.  The printable name is relevant
-   for the acceptor/server when performing an authorization decision
-   based on the initiator name that is returned from the acceptor side
-   upon the successful security context establishment.
-
-   A GSS-API initiator MUST carefully check the resulting context
-   attributes from the initial call to GSS_Init_Sec_Context() when
-   requesting anonymity, because (as in the GSS-API tradition and for
-   backwards compatibility) anonymity is just another optional context
-   attribute.  It could be that the mechanism doesn't recognize the
-   attribute at all or that anonymity is not available for some other
-   reasons -- and in that case the initiator must NOT send the initial
-   security context token to the acceptor, because it will likely reveal
-   the initiators identity to the acceptor, something that can rarely be
-   "un-done".
-
-   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to
-   represent the anonymous identity.  In addition, Section 2.1.1 of
-   [RFC1964] defines the single string representation of a Kerberos
-   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  For
-   the anonymous principals, the name component within the exportable
-   name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm
-   name according to Section 2.1.1 of [RFC1964].  Note that in this
-   specification only the client/initiator can be anonymous.
-
-   Portable initiators are RECOMMENDED to use default credentials
-   whenever possible, and request anonymity only through the input
-   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().
-
-
-6.  Security Considerations
-
-   Since KDCs ignore unknown options [RFC4120], a client requiring
-   anonymous communication needs to make sure that the ticket is
-   actually anonymous.  This is because a KDC that that does not
-   understand the anonymous option would not return an anonymous ticket.
-
-   By using the mechanism defined in this specification, the client does
-   not reveal its identity to the server but its identity may be
-   revealed to the KDC of the server principal (when the server
-
-
-
-Zhu & Leach              Expires January 8, 2008                [Page 8]
-
-Internet-Draft         Kerberos Anonymity Support              July 2007
-
-
-   principal is in a different realm than that of the client), and any
-   KDC on the cross-realm authentication path.  The Kerberos client MUST
-   verify the ticket being used is indeed anonymous before communicating
-   with the server, otherwise the client's identity may be revealed
-   unintentionally.
-
-   In cases where specific server principals must not have access to the
-   client's identity (for example, an anonymous poll service), the KDC
-   can define server principal specific policy that insure any normal
-   service ticket can NEVER be issued to any of these server principals.
-
-   If the KDC that issued an anonymous ticket were to maintain records
-   of the association of identities to an anonymous ticket, then someone
-   obtaining such records could breach the anonymity.  Additionally, the
-   implementations of most (for now all) KDC's respond to requests at
-   the time that they are received.  Traffic analysis on the connection
-   to the KDC will allow an attacker to match client identities to
-   anonymous tickets issued.  Because there are plaintext parts of the
-   tickets that are exposed on the wire, such matching by a third party
-   observer is relatively straightforward.
-
-
-7.  Acknowledgements
-
-   JK Jaganathan helped editing early revisions of this document.
-
-   Clifford Neuman contributed the core notions of this document.
-
-   Ken Raeburn reviewed the document and provided suggestions for
-   improvements.
-
-   Martin Rex wrote the text for GSS-API considerations.
-
-   Nicolas Williams reviewed the GSS-API considerations section and
-   suggested ideas for improvements.
-
-   Sam Hartman and Nicolas Williams were great champions of this work.
-
-   In addition, the following individuals made significant
-   contributions: Jeffery Altman, Tom Yu, Chaskiel M Grundman, Love
-   Hoernquist Aestrand, and Jeffery Hutzelman.
-
-
-8.  IANA Considerations
-
-   Section 3 defines the anonymous Kerberos name and the anonymous
-   Kerberos realm based on [KRBNAM].  The IANA registry for [KRBNAM]
-   need to be updated to add references to this document.
-
-
-
-Zhu & Leach              Expires January 8, 2008                [Page 9]
-
-Internet-Draft         Kerberos Anonymity Support              July 2007
-
-
-9.  Normative References
-
-   [KRBNAM]   Zhu, L., "Additonal Kerberos Naming Contraints", 
-              draft-ietf-krb-wg-naming, work in progress.
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Paul Leach
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: paulle@microsoft.com
-
-
-
-
-
-
-Zhu & Leach              Expires January 8, 2008               [Page 10]
-
-Internet-Draft         Kerberos Anonymity Support              July 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Zhu & Leach              Expires January 8, 2008               [Page 11]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-anon-10.txt b/doc/standardisation/draft-ietf-krb-wg-anon-10.txt
deleted file mode 100644
index 7ac14a692..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-anon-10.txt
+++ /dev/null
@@ -1,911 +0,0 @@
-

-

-NETWORK WORKING GROUP                                             L. Zhu

-Internet-Draft                                                  P. Leach

-Updates: 4120, 4121 and 4556                       Microsoft Corporation

-(if approved)                                            October 8, 2008

-Intended status: Standards Track

-Expires: April 11, 2009

-

-

-                     Anonymity Support for Kerberos

-                       draft-ietf-krb-wg-anon-10

-

-Status of this Memo

-

-   By submitting this Internet-Draft, each author represents that any

-   applicable patent or other IPR claims of which he or she is aware

-   have been or will be disclosed, and any of which he or she becomes

-   aware will be disclosed, in accordance with Section 6 of BCP 79.

-

-   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."

-

-   The list of current Internet-Drafts can be accessed at

-   http://www.ietf.org/ietf/1id-abstracts.txt.

-

-   The list of Internet-Draft Shadow Directories can be accessed at

-   http://www.ietf.org/shadow.html.

-

-   This Internet-Draft will expire on April 11, 2009.

-

-Abstract

-

-   This document defines extensions to the Kerberos protocol to allow a

-   Kerberos client to securely communicate with a Kerberos application

-   service without revealing its identity, or without revealing more

-   than its Kerberos realm.  It also defines extensions which allow a

-   Kerberos client to obtain anonymous credentials without revealing its

-   identity to the Kerberos Key Distribution Center (KDC).  This

-   document updates RFC 4120, RFC 4121, and RFC 4556.

-

-

-

-

-

-

-Zhu & Leach              Expires April 11, 2009                 [Page 1]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-Table of Contents

-

-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3

-   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3

-   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  5

-     4.1.  Anonymity Support in AS Exchange . . . . . . . . . . . . .  5

-       4.1.1.  Anonymous PKINIT . . . . . . . . . . . . . . . . . . .  6

-     4.2.  Anonymity Support in TGS Exchange  . . . . . . . . . . . .  7

-     4.3.  Subsequent Exchanges and Protocol Actions Common to AS

-           and TGS for Anonymity Support  . . . . . . . . . . . . . .  9

-   5.  Interoperability Requirements  . . . . . . . . . . . . . . . . 10

-   6.  GSS-API Implementation Notes . . . . . . . . . . . . . . . . . 10

-   7.  PKINIT Client Contribution to the Ticket Session Key . . . . . 11

-     7.1.  Combinging Two protocol Keys . . . . . . . . . . . . . . . 12

-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13

-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13

-   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14

-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14

-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 14

-     11.2. Informative References . . . . . . . . . . . . . . . . . . 15

-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

-   Intellectual Property and Copyright Statements . . . . . . . . . . 16

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Zhu & Leach              Expires April 11, 2009                 [Page 2]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-1.  Introduction

-

-   In certain situations, the Kerberos [RFC4120] client may wish to

-   authenticate a server and/or protect communications without revealing

-   the client's own identity.  For example, consider an application

-   which provides read access to a research database, and which permits

-   queries by arbitrary requestors.  A client of such a service might

-   wish to authenticate the service, to establish trust in the

-   information received from it, but might not wish to disclose the

-   client's identity to the service for privacy reasons.

-

-   Extensions to Kerberos are specified in this document by which a

-   client can authenticate the Key Distribution Center (KDC) and request

-   an anonymous ticket.  The client can use the anonymous ticket to

-   authenticate the server and protect subsequent client-server

-   communications.

-

-   By using the extensions defined in this specification, the client can

-   request an anonymous ticket where the client may reveal the client's

-   identity to the client's own KDC, or the client can hide the client's

-   identity completely by using anonymous Public Key Cryptography for

-   Initial Authentication in Kerberos (PKINIT) as defined in

-   Section 4.1.  Using the returned anonymous ticket, the client remains

-   anonymous in subsequent Kerberos exchanges thereafter to KDCs on the

-   cross-realm authentication path, and to the server with which it

-   communicates.

-

-   In this specification, the client realm in the anonymous ticket is

-   the anonymous realm name when anonymous PKINIT is used to obtain the

-   ticket.  The client realm is the client's real realm name if the

-   client is authenticated using the client's long term keys.  Note that

-   the membership of a realm can imply a member of the community

-   represented by the realm.

-

-   The interaction with Generic Security Service Application Program

-   Interface (GSS-API) is described after the protocol description.

-

-

-2.  Conventions Used in This Document

-

-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

-   document are to be interpreted as described in [RFC2119].

-

-

-3.  Definitions

-

-   The anonymous Kerberos realm name is defined as a well-known realm

-

-

-

-Zhu & Leach              Expires April 11, 2009                 [Page 3]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-   name based on [KRBNAM], and the value of this well-known realm name

-   is the literal "WELLKNOWN:ANONYMOUS".

-

-   The anonymous Kerberos principal name is defined as a well-known

-   Kerberos principal name based on [KRBNAM].  The value of the name-

-   type field is KRB_NT_WELLKNOWN [KRBNAM], and the value of the name-

-   string field is a sequence of two KerberosString components:

-   "WELLKNOWN", "ANONYMOUS".

-

-   The anonymous ticket flag is defined as bit 14 (with the first bit

-   being bit 0) in the TicketFlags:

-

-           TicketFlags     ::= KerberosFlags

-             -- anonymous(14)

-             -- TicketFlags and KerberosFlags are defined in [RFC4120]

-

-   This is a new ticket flag that is used to indicate a ticket is an

-   anonymous one.

-

-   An anonymous ticket is a ticket that has all of the following

-   properties:

-

-   o  The cname field contains the anonymous Kerberos principal name.

-

-   o  The crealm field contains the client's realm name or the anonymous

-      realm name.

-

-   o  The anonymous ticket contains no information that can reveal the

-      client's identity.  However the ticket may contain the client

-      realm, intermediate realms on the client's authentication path,

-      and authorization data that may provide information related to the

-      client's identity.  For example, an anonymous principal that is

-      identifiable only within a particular group of users can be

-      implemented using authorization data and such authorization data,

-      if included in the anonymous ticket, would disclose the client's

-      membership of that group.

-

-   o  The anonymous ticket flag is set.

-

-   The anonymous KDC option is defined as bit 14 (with the first bit

-   being bit 0) in the KDCOptions:

-

-           KDCOptions      ::= KerberosFlags

-             -- anonymous(14)

-             -- KDCOptions and KerberosFlags are defined in [RFC4120]

-

-   As described in Section 4, the anonymous KDC option is set to request

-   an anonymous ticket in an Authentication Service (AS) request or an

-

-

-

-Zhu & Leach              Expires April 11, 2009                 [Page 4]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-   Ticket Granting Service (TGS) request.

-

-

-4.  Protocol Description

-

-   In order to request an anonymous ticket, the client sets the

-   anonymous KDC option in an AS request or an TGS request.

-

-   The rest of this section is organized as follows: it first describes

-   protocol actions specific to AS exchanges, then it describes those of

-   TGS exchange.  These are then followed by the decription of protocol

-   actions common to both AS and TGS and those in subsequent exchanges.

-

-4.1.  Anonymity Support in AS Exchange

-

-   The client requests an anonymous ticket by setting the anonymous KDC

-   option in an AS exchange.

-

-   The Kerberos client can use the client's long term keys, or the

-   client's X.509 certificates [RFC4556], or any other preauthenication

-   data, to authenticate to the KDC and requests an anonymous ticket in

-   an AS exchange where the client's identity is known to the KDC.

-

-   If the client in the AS request is anonymous, the anonymous KDC

-   option MUST be set in the request.  Otherwise, the KDC MUST return a

-   KRB-ERROR message with the code KDC_ERR_BADOPTION.

-

-   If the client is anonymous and the KDC does not have a key to encrypt

-   the reply (this can happen when, for example, the KDC does not

-   support PKINIT [RFC4556]), the KDC MUST return an error message with

-   the code KDC_ERR_NULL_KEY [RFC4120].

-

-   When policy allows, the KDC issues an anonymous ticket.  If the

-   client name in the request is the anonymous principal, the client

-   realm (crealm) in the reply is the anonymous realm, otherwise the

-   client realm is the realm of the AS.  According to [RFC4120] the

-   client name and the client realm in the EncTicketPart of the reply

-   MUST match with the corresponding client name and the client realm of

-   the anonymous ticket in the reply; the client MUST use the client

-   name and the client realm returned in the KDC-REP in subsequent

-   message exchanges when using the obtained anonymous ticket.

-

-   Care MUST be taken by the KDC not to reveal the client's identity in

-   the authorization data of the returned ticket when populating the

-   authorization data in a returned anonymous ticket.

-

-   The AD-INITIAL-VERIFIED-CAS authorization data as defined in

-   [RFC4556] contains the issuer name of the client certificate.  This

-

-

-

-Zhu & Leach              Expires April 11, 2009                 [Page 5]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-   authorization is not applicable and MUST NOT be present in the

-   returned anonymous ticket when anonymous PKINIT is used.  When the

-   client is authenticated (i.e. anonymous PKINIT is not used), if it is

-   undesirable to disclose such information about the client's identity,

-   the AD-INITIAL-VERIFIED-CAS authorization data SHOULD be removed from

-   the returned anonymous ticket.

-

-   The client can use the client keys to mutually authenticate with the

-   KDC, request an anonymous TGT in the AS request.  And in that case,

-   the reply key is selected as normal according to Section 3.1.3 of

-   [RFC4120].

-

-4.1.1.  Anonymous PKINIT

-

-   This sub-section defines anonymity PKINIT.

-

-   As described earlier in this section, the client can request an

-   anonymous ticket by authenticating to the KDC using the client's

-   identity; alternatively without revealing the client's identity to

-   the KDC, the Kerberos client can request an anonymous ticket as

-   follows: the client sets the client name as the anonymous principal

-   in the AS exchange and provides a PA_PK_AS_REQ pre-authentication

-   data [RFC4556] where both the signerInfos field and the certificates

-   field of the SignedData [RFC3852] of the PA_PK_AS_REQ are empty.

-   Because the anonymous client does not have an associated asymmetric

-   key pair, the client MUST choose the Diffie-Hellman key agreement

-   method by filling in the Diffie-Hellman domain parameters in the

-   clientPublicValue [RFC4556].  This use of the anonymous client name

-   in conjunction with PKINIT is referred to as anonymous PKINIT.  If

-   anonymous PKINIT is used, the realm name in the returned anonymous

-   ticket MUST be the anonymous realm.

-

-   Upon receiving the anonymous PKINIT request from the client, the KDC

-   processes the request according to Section 3.1.2 of [RFC4120].  The

-   KDC skips the checks for the client's signature and the client's

-   public key (such as the verification of the binding between the

-   client's public key and the client name), but performs otherwise-

-   applicable checks, and proceeds as normal according to [RFC4556].

-   For example, the AS MUST check if the client's Diffie-Hellman domain

-   parameters are acceptable.  The Diffie-Hellman key agreement method

-   MUST be used and the reply key is derived according to Section

-   3.2.3.1 of [RFC4556].  If the clientPublicValue is not present in the

-   request, the KDC MUST return a KRB-ERROR with the code

-   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556].  If all goes

-   well, an anonymous ticket is generated according to Section 3.1.3 of

-   [RFC4120] and a PA_PK_AS_REP [RFC4556] pre-authentication data is

-   included in the KDC reply according to [RFC4556].  If the KDC does

-   not have an asymmetric key pair, it MAY reply anonymously or reject

-

-

-

-Zhu & Leach              Expires April 11, 2009                 [Page 6]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-   the authentication attempt.  If the KDC replies anonymously, both the

-   signerInfos field and the certificates field of the SignedData

-   [RFC3852] of PA_PK_AS_REP in the reply are empty.  The server name in

-   the anonymous KDC reply contains the name of the TGS.

-

-   Upon receipt of the KDC reply that contains an anonymous ticket and a

-   PA_PK_AS_REP [RFC4556] pre-authentication data, the client can then

-   authenticate the KDC based on the KDC's signature in the

-   PA_PK_AS_REP.  If the KDC's signature is missing in the KDC reply

-   (the reply is anonymous), the client MUST reject the returned ticket

-   if it cannot authenticate the KDC otherwise.

-

-   A KDC that supports anonymous PKINIT MUST indicate the support of

-   PKINIT according to Section 3.4 of [RFC4556].

-

-   Note that in order to obtain an anonymous ticket with the anonymous

-   realm name, the client MUST set the client name as the anonymous

-   principal in the request when requesting an anonymous ticket in an AS

-   exchange.  Anonymity PKINIT is the only way via which an anonymous

-   ticket with the anonymous realm as the client realm can be generated

-   in this specification.

-

-4.2.  Anonymity Support in TGS Exchange

-

-   The client requests an anonymous ticket by setting the anonymous KDC

-   option in a TGS exchange, and in that request the client can use a

-   normal Ticket Granting Ticket (TGT) with the client's identity, or an

-   anonymous TGT, or an anonymous cross realm TGT.  If the client uses a

-   normal TGT, the client's identity is known to the TGS.

-

-   Note that the client can completely hide the client's identity in an

-   AS exchange using anonymous PKINIT as described in the previous

-   section.

-

-   If the ticket in the PA-TGS-REQ of the TGS request is an anonymous

-   one, the anonymous KDC option MUST be set in the request.  Otherwise,

-   the KDC MUST return a KRB-ERROR message with the code

-   KDC_ERR_BADOPTION.

-

-   When policy allows, the KDC issues an anonymous ticket.  If the

-   ticket in the TGS request is an anonymous one, the client name and

-   the client realm are copied from that ticket; otherwise the ticket in

-   the TGS request is a normal ticket, the returned anonymous ticket

-   contains the client name as the anonymous principal and the client

-   realm as the true realm of the client.  In all cases, according to

-   [RFC4120] the client name and the client realm in the EncTicketPart

-   of the reply MUST match with the corresponding client name and the

-   client realm of the anonymous ticket in the reply; the client MUST

-

-

-

-Zhu & Leach              Expires April 11, 2009                 [Page 7]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-   use the client name and the client realm returned in the KDC-REP in

-   subsequent message exchanges when using the obtained anonymous

-   ticket.

-

-   Care MUST be taken by the TGS not to reveal the client's identity in

-   the authorization data of the returned ticket.  When propagating

-   authorization data in the ticket or in the enc-authorization-data

-   field of the request, the TGS MUST ensure that the client

-   confidentiality is not violated in the returned anonymous ticket.

-   The TGS MUST process the authorization data recursively according to

-   Section 5.2.6 of [RFC4120] beyond the container levels such that all

-   embedded authorization elements are interpreted.  The TGS SHOULD NOT

-   populate identity-based authorization data into an anonymous ticket

-   in that such authorization data typically reveals the client's

-   identity.  The specification of a new authorization data type MUST

-   specify the processing rules of the authorization data when an

-   anonymous ticket is returned.  If there is no processing rule defined

-   for an authorization data element or the authorization data element

-   is unknown, the TGS MUST process it when an anonymous ticket is

-   returned as follows:

-

-   o  If the authorization data element may reveal the client's

-      identity, it MUST be removed unless otherwise specified.

-

-   o  If the authorization data element, that could reveal's the

-      client's identity. is intended to restrict the use of the ticket

-      or limit the rights otherwise conveyed in the ticket, it cannot be

-      removed in order to hide the client's identity.  In this case, the

-      authentication attempt MUST be rejected, and the TGS MUST return

-      an error message with the code KDC_ERR_POLICY.  Note this is

-      applicable to both critical and optional authorization data.

-

-   o  If the authorization data element is unknown, the TGS MAY remove

-      it, or transfer it into the returned anonymous ticket, or reject

-      the authentication attempt, based on local policy for that

-      authorization data type unless otherwise specified.  If there is

-      no policy defined for a given unknown authorization data type, the

-      authentication MUST be rejected.  The error code is KDC_ERR_POLICY

-      when the authentication is rejected.

-

-   The AD-INITIAL-VERIFIED-CAS authorization data as defined in

-   [RFC4556] contains the issuer name of the client certificate.  If it

-   is undesirable to disclose such information about the client's

-   identity, the AD-INITIAL-VERIFIED-CAS authorization data SHOULD be

-   removed from an anonymous ticket.

-

-   The TGS encodes the name of the previous realm into the transited

-   field according to Section 3.3.3.2 of [RFC4120].  Based on local

-

-

-

-Zhu & Leach              Expires April 11, 2009                 [Page 8]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-   policy, the TGS MAY omit the previous realm if the cross realm TGT is

-   an anonymous one in order to hide the authentication path of the

-   client.  The unordered set of realms in the transited field, if

-   present, can reveal which realm may potentially be the realm of the

-   client or the realm that issued the anonymous TGT.  The anonymous

-   Kerberos realm name MUST NOT be present in the transited field of a

-   ticket.  The true name of the realm that issued the anonymous ticket

-   MAY be present in the transited field of a ticket.

-

-4.3.  Subsequent Exchanges and Protocol Actions Common to AS and TGS for

-      Anonymity Support

-

-   In both AS and TGS exchanges, the realm field in the KDC request is

-   always the realm of the target KDC, not the anonymous realm when the

-   client requests an anonymous ticket.

-

-   Absent other information the KDC MUST NOT include any identifier in

-   the returned anonymous ticket that could reveal the client's identity

-   to the server.

-

-   Unless anonymous PKINIT is used, if a client requires anonymous

-   communication then the client MUST check to make sure that the ticket

-   in the reply is actually anonymous by checking the presence of the

-   anonymous ticket flag in the flags field of the EncKDCRepPart.  This

-   is because KDCs ignore unknown KDC options.  A KDC that does not

-   understand the anonymous KDC option will not return an error, but

-   will instead return a normal ticket.

-

-   The subsequent client and server communications then proceed as

-   described in [RFC4120].

-

-   Note that the anonymous principal name and realm are only applicable

-   to the client in Kerberos messages, the server cannot be anonymous in

-   any Kerberos message per this specification.

-

-   A server accepting an anonymous service ticket may assume that

-   subsequent requests using the same ticket originate from the same

-   client.  Requests with different tickets are likely to originate from

-   different clients.

-

-   Upon receipt of an anonymous ticket, the transited policy check is

-   preformed in the same way as that of a normal ticket if the client's

-   realm is not the anonymous realm; if the client realm is the

-   anonymous realm, absent other information any realm in the

-   authentication path is allowed by the cross-realm policy check.

-

-

-

-

-

-

-Zhu & Leach              Expires April 11, 2009                 [Page 9]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-5.  Interoperability Requirements

-

-   Conforming implementations MUST support the anonymous principal with

-   a non-anonymous realm, and they MAY support the anonymous principal

-   with the anonymous realm using anonymous PKINIT.

-

-

-6.  GSS-API Implementation Notes

-

-   GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to

-   represent the anonymous identity.  In addition, Section 2.1.1 of

-   [RFC1964] defines the single string representation of a Kerberos

-   principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME.  The

-   anonymous principal with the anonymous realm corresponds to the GSS-

-   API anonymous principal.  A principal with the anonymous principal

-   name and a non-anonymous realm is an authenticated principal, hence

-   such a principal does not correspond to the anonymous principal in

-   GSS-API with the GSS_C_NT_ANONYMOUS name type.  The [RFC1964] name

-   syntax for GSS_KRB5_NT_PRINCIPAL_NAME MUST be used for importing the

-   anonymous principal name with a non-anonymous realm name and for

-   displaying and exporting these names.

-

-   At the GSS-API [RFC2743] level, an initiator/client requests the use

-   of an anonymous principal with the anonymous realm by asserting the

-   "anonymous" flag when calling GSS_Init_Sec_Context().  The GSS-API

-   implementation MAY provide implementation-specific means for

-   requesting the use of an anonymous principal with a non-anonymous

-   realm.

-

-   GSS-API does not know or define "anonymous credentials", so the

-   (printable) name of the anonymous principal will rarely be used by or

-   relevant for the initiator/client.  The printable name is relevant

-   for the acceptor/server when performing an authorization decision

-   based on the initiator name that is returned from the acceptor side

-   upon the successful security context establishment.

-

-   A GSS-API initiator MUST carefully check the resulting context

-   attributes from the initial call to GSS_Init_Sec_Context() when

-   requesting anonymity, because (as in the GSS-API tradition and for

-   backwards compatibility) anonymity is just another optional context

-   attribute.  It could be that the mechanism doesn't recognize the

-   attribute at all or that anonymity is not available for some other

-   reasons -- and in that case the initiator MUST NOT send the initial

-   security context token to the acceptor, because it will likely reveal

-   the initiators identity to the acceptor, something that can rarely be

-   "un-done".

-

-   Portable initiators are RECOMMENDED to use default credentials

-

-

-

-Zhu & Leach              Expires April 11, 2009                [Page 10]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-   whenever possible, and request anonymity only through the input

-   anon_req_flag [RFC2743] to GSS_Init_Sec_Context().

-

-

-7.  PKINIT Client Contribution to the Ticket Session Key

-

-   The definition in this section was motivated by protocol analysis of

-   anonymous PKINIT (defined in this document) in building tunneling

-   channels [FAST] and subsequent channel bindings.  In order to enable

-   applications of anonymous PKINIT to form channels, all

-   implementations of anonymous PKINIT need to meet the requirements of

-   this section.  There is otherwise no connection to the rest of this

-   document.

-

-   PKINIT is useful for constructing tunneling channels.  To ensure that

-   an attacker cannot create a channel with a given name, it is

-   desirable that neither the KDC nor the client can unilaterally

-   determine the ticket session key.  To achieve that end, a KDC

-   conforming to this definition MUST encrypt a randomly generated key,

-   called the KDC contribution key, in the PA_PKINIT_KX padata (defined

-   next in this section).  The KDC contribution key is then combined

-   with the reply key to form the ticket session key of the returned

-   ticket.  These two keys are then combined using the KRB-FX-CF2

-   operation defined in Section 7.1, where K1 is the KDC contribution

-   key, K2 is the reply key, the input pepper1 is American Standard Code

-   for Information Interchange (ASCII) [ASAX34] string "PKINIT", and the

-   input pepper2 is ASCII string "KeyExchange".

-

-   PA_PKINIT_KX      135

-     -- padata for PKINIT that contains an encrypted

-     -- KDC contribution key.

-

-   PA-PKINIT-KX  ::= EncryptedData -- EncryptionKey

-     -- Contains an encrypted key randomly

-     -- generated by the KDC (known as the KDC contribution key).

-     -- Both EncryptedData and EncryptionKey are defined in [RFC4120]

-

-   The PA_PKINIT_KX padata MUST be included in the KDC reply when

-   anonymous PKINIT is used; it SHOULD be included if PKINIT is used

-   with the Diffie-Helleman key exchange but the client is not

-   anonymous; it MUST NOT be included otherwise (e.g. when PKINIT is

-   used with the public key encryption as the key exchange).

-

-   The padata-value field of the PA-PKINIT-KX type padata contains the

-   DER [X680] [X690] encoding of the Abstract Syntax Notation One

-   (ASN.1) type PA-PKINIT-KX.  The PA-PKINIT-KX structure is a

-   EncryptedData.  The clear text data being encrypted is the DER

-   encoded Kerberos session key randomly generated by the KDC.  The

-

-

-

-Zhu & Leach              Expires April 11, 2009                [Page 11]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-   encryption key is the reply key and the key usage number is

-   KEY_USAGE_PA_PKINIT_KX (44).

-

-   The client then decrypts the KDC contribution key and verifies the

-   ticket session key in the returned ticket is the combined key of the

-   KDC contribution key and the reply key as described above.  A

-   conforming client MUST reject anonymous PKINIT authentication if the

-   PA_PKINIT_KX padata is not present in the KDC reply or if the ticket

-   session key of the returned ticket is not the combined key of the KDC

-   contribution key and the reply key when PA-PKINIT-KX is present in

-   the KDC reply.

-

-7.1.  Combinging Two protocol Keys

-

-   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()

-   function defined in [RFC3961].

-

-   Given two input keys, K1 and K2, where K1 and K2 can be of two

-   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as

-   follows:

-

-    KRB-FX-CF2(protocol key, protocol key, octet string,

-              octet string)  ->  (protocol key)

-

-    PRF+(K1, pepper1) -> octet-string-1

-    PRF+(K2, pepper2) -> octet-string-2

-    KRB-FX-CF2(K1, K2, pepper1, pepper2) ->

-           random-to-key(octet-string-1 ^ octet-string-2)

-

-   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as

-   follows:

-

-   PRF+(protocol key, octet string) -> (octet string)

-

-   PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||

-                pseudo-random( key, 2 || shared-info ) ||

-                pseudo-random( key, 3 || shared-info ) || ...

-

-   Here the counter value 1, 2, 3 and so on are encoded as a one-octet

-   integer.  The pseudo-random() operation is specified by the enctype

-   of the protocol key.  PRF+() uses the counter to generate enough bits

-   as needed by the random-to-key() [RFC3961] function for the

-   encryption type specified for the resulting key; unneeded bits are

-   removed from the tail.

-

-

-

-

-

-

-

-Zhu & Leach              Expires April 11, 2009                [Page 12]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-8.  Security Considerations

-

-   Since KDCs ignore unknown options, a client requiring anonymous

-   communication needs to make sure that the returned ticket is actually

-   anonymous.  This is because a KDC that that does not understand the

-   anonymous option would not return an anonymous ticket.

-

-   By using the mechanism defined in this specification, the client does

-   not reveal the client's identity to the server but the client

-   identity may be revealed to the KDC of the server principal (when the

-   server principal is in a different realm than that of the client),

-   and any KDC on the cross-realm authentication path.  The Kerberos

-   client MUST verify the ticket being used is indeed anonymous before

-   communicating with the server, otherwise the client's identity may be

-   revealed unintentionally.

-

-   In cases where specific server principals must not have access to the

-   client's identity (for example, an anonymous poll service), the KDC

-   can define server principal specific policy that insure any normal

-   service ticket can NEVER be issued to any of these server principals.

-

-   If the KDC that issued an anonymous ticket were to maintain records

-   of the association of identities to an anonymous ticket, then someone

-   obtaining such records could breach the anonymity.  Additionally, the

-   implementations of most (for now all) KDC's respond to requests at

-   the time that they are received.  Traffic analysis on the connection

-   to the KDC will allow an attacker to match client identities to

-   anonymous tickets issued.  Because there are plaintext parts of the

-   tickets that are exposed on the wire, such matching by a third party

-   observer is relatively straightforward.  A service that is

-   authenticated by the anonymous principals may be able to infer the

-   identity of the client by examining and linking quasi-static protocol

-   information such as the IP address from which a request is received,

-   or by linking multiple uses of the same anonymous ticket.

-

-   The client's real identity is not revealed when the client is

-   authenticated as the anonymous principal.  Application servers MAY

-   reject the authentication in order to, for example, prevent

-   information disclosure or as part of Denial of Service (DOS)

-   prevention.  Application servers MUST avoid accepting anonymous

-   credentials in situations where they must record the client's

-   identity; for example, when there must be an audit trail.

-

-

-9.  Acknowledgements

-

-   JK Jaganathan helped editing early revisions of this document.

-

-

-

-

-Zhu & Leach              Expires April 11, 2009                [Page 13]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-   Clifford Neuman contributed the core notions of this document.

-

-   Ken Raeburn reviewed the document and provided suggestions for

-   improvements.

-

-   Martin Rex wrote the text for GSS-API considerations.

-

-   Nicolas Williams reviewed the GSS-API considerations section and

-   suggested ideas for improvements.

-

-   Sam Hartman and Nicolas Williams were great champions of this work.

-

-   Miguel Garcia and Phillip Hallam-Baker reviewed the document and

-   provided helpful suggestions.

-

-   In addition, the following individuals made significant

-   contributions: Jeffrey Altman, Tom Yu, Chaskiel M Grundman, Love

-   Hornquist Astrand, Jeffrey Hutzelman, and Olga Kornievskaia.

-

-

-10.  IANA Considerations

-

-   This document defines a new 'anonymous' Kerberos well-known name and

-   a new 'anonymous' Kerberos well-known realm based on [KRBNAM].  IANA

-   is requested to add these two values to the Kerberos naming

-   registries that are created in [KRBNAM].

-

-

-11.  References

-

-11.1.  Normative References

-

-   [ASAX34]   American Standard Code for Information Interchange, 

-              ASA X3.4-1963, American Standards Association, June 17, 

-              1963.

-

-   [KRBNAM]   Zhu, L., "Additional Kerberos Naming Constraints",

-              draft-ietf-krb-wg-naming (work in progress), 2008.

-

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

-              RFC 1964, June 1996.

-

-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

-              Requirement Levels", BCP 14, RFC 2119, March 1997.

-

-   [RFC2743]  Linn, J., "Generic Security Service Application Program

-              Interface Version 2, Update 1", RFC 2743, January 2000.

-

-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",

-              RFC 3852, July 2004.

-

-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for

-     

-

-

-Zhu & Leach              Expires April 11, 2009                [Page 14]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-              Kerberos 5", RFC 3961, February 2005.

-

-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The

-              Kerberos Network Authentication Service (V5)", RFC 4120,

-              July 2005.

-

-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial

-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.

-

-

-   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,

-              Information technology - Abstract Syntax Notation One

-              (ASN.1): Specification of basic notation.

-   

-   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,

-              Information technology - ASN.1 encoding Rules:

-              Specification of Basic Encoding Rules (BER), Canonical

-              Encoding Rules (CER) and Distinguished Encoding Rules

-              (DER).        

-              

-11.2.  Informative References

-

-   [FAST]     Zhu, L. and S. Hartman, "A Generalized Framework for

-              Kerberos Pre-Authentication",

-              draft-ietf-krb-wg-preauth-framework (work in progress),

-              2008.

-

-

-Authors' Addresses

-

-   Larry Zhu

-   Microsoft Corporation

-   One Microsoft Way

-   Redmond, WA  98052

-   US

-

-   Email: lzhu@microsoft.com

-

-

-   Paul Leach

-   Microsoft Corporation

-   One Microsoft Way

-   Redmond, WA  98052

-   US

-

-   Email: paulle@microsoft.com

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Zhu & Leach              Expires April 11, 2009                [Page 15]

-

-Internet-Draft         Kerberos Anonymity Support           October 2008

-

-

-Full Copyright Statement

-

-   Copyright (C) The IETF Trust (2008).

-

-   This document is subject to the rights, licenses and restrictions

-   contained in BCP 78, and except as set forth therein, the authors

-   retain all their rights.

-

-   This document and the information contained herein are provided on an

-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS

-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF

-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-Intellectual Property

-

-   The IETF takes no position regarding the validity or scope of any

-   Intellectual Property Rights or other rights that might be claimed to

-   pertain to the implementation or use of the technology described in

-   this document or the extent to which any license under such rights

-   might or might not be available; nor does it represent that it has

-   made any independent effort to identify any such rights.  Information

-   on the procedures with respect to rights in RFC documents can be

-   found in BCP 78 and BCP 79.

-

-   Copies of IPR disclosures made to the IETF Secretariat and any

-   assurances of licenses to be made available, or the result of an

-   attempt made to obtain a general license or permission for the use of

-   such proprietary rights by implementers or users of this

-   specification can be obtained from the IETF on-line IPR repository at

-   http://www.ietf.org/ipr.

-

-   The IETF invites any interested party to bring to its attention any

-   copyrights, patents or patent applications, or other proprietary

-   rights that may cover technology that may be required to implement

-   this standard.  Please address the information to the IETF at

-   ietf-ipr@ietf.org.

-

-

-

-

-

-

-

-

-

-

-

-Zhu & Leach              Expires April 11, 2009                [Page 16]

-

-

diff --git a/doc/standardisation/draft-ietf-krb-wg-cross-problem-statement-04.txt b/doc/standardisation/draft-ietf-krb-wg-cross-problem-statement-04.txt
deleted file mode 100644
index d73e613d8..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-cross-problem-statement-04.txt
+++ /dev/null
@@ -1,731 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                                 S. Sakane
-Intended Status: Informational                           Ken'ichi Kamada
-Expires: January 31, 2010                        Yokogawa Electric Corp.
-                                                               S. Zrelli
-                                                                   JAIST
-                                                             M. Ishiyama
-                                                           Toshiba Corp.
-                                                           July 30, 2009
-
-
-       Problem statement on the cross-realm operation of Kerberos
-            draft-ietf-krb-wg-cross-problem-statement-04.txt
-
-
-
-
-                          Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-   This Internet-Draft expires in January 31, 2010.
-
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-
-
-
-S.Sakane, et al.                                                [Page 1]
-
-Internet-Draft                                                 July 2009
-
-
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-
-Abstract
-
-   As industrial automation is moving towards wider adoption of Internet
-   standards, the Kerberos authentication protocol represents one of the
-   best alternatives for ensuring the confidentiality and the integrity
-   of communications in control networks while meeting performance and
-   security requirements.
-
-   However, the use of Kerberos cross-realm operations in large scale
-   industrial systems may introduce issues that could cause performance
-   and reliability problems. This document describes some examples of
-   actual large scale industrial systems, and lists requirements and
-   restriction regarding authentication operations in such environments.
-   The document then describes standing issues in the Kerberos cross-
-   realm authentication model that should be fixed before Kerberos can
-   be adopted in large scale industrial systems.
-
-
-
-Conventions used in this document
-
-   It is assumed that the readers are familiar with the terms and
-   concepts described in the Kerberos Version 5 [RFC4120].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-S.Sakane, et al.                                                [Page 2]
-
-Internet-Draft                                                 July 2009
-
-
-Table of Contents
-
-    1. Introduction .................................................  4
-    2. Kerberos system ..............................................  4
-       2.1. Kerberos basic operation ................................  4
-       2.2. Cross-realm operation ...................................  5
-    3. Applying Cross-Realm Kerberos in Complex Environments ........  6
-    4. Requirements .................................................  7
-    5. Issues .......................................................  8
-       5.1. Unreliability of authentication chain ...................  8
-       5.2. Possibility of MITM in case of the indirect trust model .  9
-       5.3. Scalability of the direct trust model ...................  9
-       5.4. Exposure to DoS Attacks .................................  9
-       5.5. Client's performance .................................... 10
-       5.6. Pre-authentication problem in roaming scenarios ......... 10
-    6. Implementation consideration ................................. 11
-    7. IANA Considerations .......................................... 11
-    8. Security Considerations ...................................... 11
-    9. Acknowledgments .............................................. 11
-   10. References ................................................... 11
-       10.1. Normative References ................................... 11
-       10.2. Informative References ................................. 12
-   Authors' Addresses ............................................... 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-S.Sakane, et al.                                                [Page 3]
-
-Internet-Draft                                                 July 2009
-
-
-1.  Introduction
-
-   Kerberos Version 5 is a widely deployed mechanism that enables a
-   server to authenticate a client's access.  Each client belongs to a
-   managed domain called realm.  Kerberos supports authentication when a
-   client and a server belong to different realms.  This is called
-   cross-realm operation.
-
-   Meanwhile, there are lots of manners of operation in actual systems,
-   where Kerberos could be applied.  Large systems or distributed
-   systems are typically split into several managed domains.  For
-   example, systems could be split into multiple domains for
-   geographical reasons, or to implement different management policies.
-   Even in such systems, a common authentication mechanism for the
-   different managed domains is required.  When the cross-realm
-   operation of Kerberos is applied to such systems, some issues come
-   out.
-
-   This document briefly describes the Kerberos Version 5 system and its
-   cross-realm mode of operation.  Then, it describes two actual systems
-   that Kerberos could be applied to.  and describes seven requirements
-   of those systems in term both of management and operation.  Finally,
-   it lists six issues of the cross-realm operation when it is applied
-   to those system.
-
-   Note that this document might not describe all of the issues of
-   cross-realm operation.  New issues might be found in the future.  It
-   also does not propose any solution to solve the issues.  Furthermore,
-   publication of this document does not mean that each of the issues
-   have to be solved by the IETF members.  Hence, in further step, we
-   will analyze the issues, define problems and explore the solutions.
-   These works will be described in another document.
-
-   This document is assumed that the readers are familiar with the terms
-   and concepts described in the Kerberos Version 5 [RFC4120].
-
-
-2.  Kerberos system
-
-
-2.1.  Kerberos basic operation
-
-   Kerberos [RFC4120] is a widely deployed authentication system.  The
-   authentication process in Kerberos involves principals and a Key
-   Distribution Center (KDC).  The principals can be users or services.
-   Each KDC maintains a database of principals and shares a secret key
-   with each registered principal.
-
-
-
-
-S.Sakane, et al.                                                [Page 4]
-
-Internet-Draft                                                 July 2009
-
-
-   The authentication process allows a user to acquire the needed
-   credentials from the KDC.  These credentials allow services to
-   authenticate the users before granting them access to the resources.
-   An important part of the credentials are called Tickets.  There are
-   two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket.
-   The TGT is obtained periodically from the KDC and has a limited limit
-   after which it expires and the user must renew it.  The TGT is used
-   to obtain the other kind of tickets, Service Tickets.  The user
-   obtains a TGT from the Authentication Service (AS), a logical
-   component of the KDC.  The process of obtaining a TGT is referred to
-   as 'AS exchange'.  When a TGT request is issued by an user, the AS
-   responds by sending a reply packet containing the credentials which
-   consists of the TGT along with a random key called 'TGS Session Key'.
-   The TGT contains a set of information encrypted using a secret key
-   associated with a special service referred to as TGS (Ticket Granting
-   Service).  The TGS session key is encrypted using the user's key so
-   that the user can obtain the TGS session key only if she knows the
-   secret key shared with the KDC.  The TGT then is used to obtain
-   Service Tickets from the Ticket Granting Service (TGS)- the second
-   component of the KDC.  The process of obtaining service tickets is
-   referred to as 'TGS exchange'.  The request for a service ticket
-   consists on a packet containing a TGT and an 'Authenticator'.  The
-   Authenticator is encrypted using the TGS session key and contains the
-   identity of the user as well as time stamps (for protection against
-   replay attacks).  After decrypting the TGT (which was encrypted by
-   the AS using the TGS's secret key), the TGS extracts the TGS session
-   key.  Using that session key, it decrypts the Authenticator and
-   authenticates the user.  Then, the TGS issues credentials requested
-   by the user.  These credentials consist on a service ticket and a
-   session key that will be used to authenticate the user with the
-   desired application service.
-
-
-2.2.  Cross-realm operation
-
-   The Kerberos protocol provides cross-realm authentication
-   capabilities.  This allows users to obtain service tickets to access
-   services in foreign realms.  In order to access such services, the
-   users first contact their home KDC asking for a TGT that will be used
-   with the TGS of the foreign realm.  If there is a direct trust
-   relationship between the home realm and the foreign realm, namely
-   both realms share keys (this is called inter-realm keys), the home
-   KDC delivers the requested TGT.
-
-   However, if the home realm does not share inter-realm keys with the
-   foreign realm the home KDC will provide a TGT that can be used with
-   an intermediary foreign realm that is likely to be sharing inter-
-   realm keys with the target realm.  The client can use this
-
-
-
-S.Sakane, et al.                                                [Page 5]
-
-Internet-Draft                                                 July 2009
-
-
-   'intermediary TGT' to communicate with the intermediary KDC which
-   will iterate the actions taken by the home KDC.  If the intermediary
-   KDC does not share inter-realm keys with the target foreign realm it
-   will point the user to another intermediary KDC (just as in the first
-   exchange between the user and its home KDC).  However, in the other
-   case (when it shares inter-realm keys with the target realm), the
-   intermediary KDC will issue a TGT that can be used with the KDC of
-   the target realm.  This is so-called indirect trust model.  After
-   obtaining a TGT for the desired foreign realm, the client uses it to
-   obtain service tickets from the TGS of the foreign realm.  Finally,
-   the user access the service using the service ticket.
-
-   When the realms belong to the same institution, a chain of trust can
-   be determined by the client or the KDC by following the DNS domain
-   hierarchy and supposing that the parent domains share keys with all
-   its child sub-domains.  However, because the inter-realm trust model
-   is not necessarily constructing the hierarchic approach anytime, the
-   trust path must be specified manually.  When intermediary realms are
-   involved, the success of the cross-realm operation completely depends
-   on the realms that are part of the authentication path.
-
-
-3.  Applying Cross-Realm Kerberos in Complex Environments
-
-   In order to help understanding both requirements and restriction,
-   this section describes scale and operation of two actual systems that
-   could be supported by cross-realm Kerberos.  The two systems would be
-   most naturally implemented using different models, which will imply
-   different requirements for cross-realm Kerberos.
-
-   We refer to actual petrochemical enterprise [SHELLCHEM], and show two
-   examples among its plants.  The enterprise produces bulk
-   petrochemicals and their delivery to large industrial customers.
-   There are 43 typical plants of the enterprise all over the world.
-   They are managed by the operation sites placed in 35 countries.  This
-   section shows two examples of them.
-
-   One is an example of a centralized system [CSPC].  CSPC is operated
-   by a joint enterprise of two companies.  This system is one of the
-   largest systems of this enterprise in the world.  This is placed in
-   the area of 3.4 square kilo meters in the north coast of Daya Bay,
-   Guangdong, which is at the southeast of China.  3,000 network
-   segments are established in the system.  16,000 control devices are
-   connected to the local area network.  These devices belong to
-   different 9 sub systems, A control device has some control points,
-   which are controlled and monitored by other devices remotely.  There
-   are 200,000 control points in all.  They are controlled by 3
-   different control center.
-
-
-
-S.Sakane, et al.                                                [Page 6]
-
-Internet-Draft                                                 July 2009
-
-
-   Another example is a distributed system [NAM].  The NAM (Nederlandse
-   Aardolie Maatschappij) is operated by a partnership company of two
-   enterprises that represent the oil company.  This system is
-   constituted by some plants that are geographically distributed within
-   the range of 863 square kilometers in the northern part of
-   Netherlands.  26 plants, each is named "cluster", are scattered in
-   the area.  They are connected each other by a private ATM WAN.  Each
-   cluster has approximately 500-1,000 control devices.  These devices
-   are managed by each local control center in each cluster.  In the
-   entire system of the NAM, there are one million control points.
-
-   In the both of the systems, the end devices are basically connected
-   to a local network by a twisted pair cable, which is a low band-width
-   of 32 kbps.  Low clock CPU, for example H8 [RNSS-H8] and M16C [RNSS-
-   M16C], are employed by many control devices.  Furthermore, to
-   suppress power consumption, these CPU may be lowered the number of
-   clocks.  Because there is a requirement of the explosion-proof.  The
-   requirement restricts the amount of total energy in the device.
-
-   A device on the network collects data from other devices which are
-   monitoring condition of the system.  The device uses the data to make
-   a decision how to control another devices.  And then the device gives
-   more than one instruction that controls other devices.  If it took
-   time for data to reach, they could not be associated.  The travel
-   time of data from the device to the other device is demanded within 1
-   second at least.
-
-   A part of the operation, like control of these system, maintenance,
-   and the environmental monitoring, is consigned to an external
-   organization.  Agents who are consigned walk around the plant to get
-   their information, or watch the plant from a remote site.
-
-
-4.  Requirements
-
-   This section lists the requirements derived from the previous
-   section.  R-1, R-2, R-3 and R-4 are related to the management of the
-   divided system.  R-5, R-6 and R-7 are related to the restriction to
-   such industrial network.
-
-
-   R-1  It is necessary to partition a management domain into some
-        domains.  Or it is necessary to delegate a management authority
-        to another independent management domain.
-
-   R-2  It is necessary to allow different independent management
-        domains to coexist on the same network because two or more
-        organizations need to enter into the system and to management
-
-
-
-S.Sakane, et al.                                                [Page 7]
-
-Internet-Draft                                                 July 2009
-
-
-        it.
-
-   R-3  It is necessary that a device controls other devices that belong
-        to a different domain.
-
-   R-4  It is necessary to consider that a device is not always
-        geographically or network topologically close to the other
-        devices even when the devices belong to a same management
-        domain.
-
-   R-5  It is demanded to reduce the management cost as much as
-        possible.
-
-   R-6  It is necessary to consider the processing performance of the
-        device.  And, it is necessary to suppress the power consumption
-        of the device.
-
-   R-7  It is necessary to consider bandwidth of the communication.
-
-
-5.  Issues
-
-   This section lists the issues in the cross-realm operation when we
-   apply the Kerberos version 5 into the system described in the section
-   3, and consider the system applied the Kerberos with the requirements
-   described in the section 4.
-
-
-5.1.  Unreliability of authentication chain
-
-   When the relationship of trust is constructed like a chain or
-   hierarchical, the authentication path is not dependable since it
-   strongly depends on intermediary realms that might not be under the
-   same authority.  If any of the realms in the authentication path is
-   not available, then the principals of the end-realms can not perform
-   the cross-realm operation.
-
-   The end-point realms do not have full control and responsibility of
-   the success of the operations even if their respective KDCs are fully
-   functional.  Dependability of a system decreases if the system relies
-   on uncontrolled components.  We can not be sure at 100% about the
-   result of the authentication since we do not know how is it going in
-   intermediary realms.
-
-   This issue will happen as a by-product of a result meeting the
-   requirements R-1 and R-2.
-
-
-
-
-
-S.Sakane, et al.                                                [Page 8]
-
-Internet-Draft                                                 July 2009
-
-
-5.2.  Possibility of MITM in case of the indirect trust model
-
-   Every KDC in the authentication path knows the shared secret between
-   the client and the remaining KDCs in the authentication path.  This
-   allows a malicious KDC to perform MITM attacks on communications
-   between the client and any KDC in the remaining authentication chain.
-   A malicious KDC also may learn the service session key that is used
-   to protect the communication between the client and the actual
-   application service, and performs a MITM attack between them.
-
-   In [SPECCROSS], the authors have analyzed the cross-realm operations
-   in Kerberos and provided formal proof of the issue discussed in this
-   section.
-
-   This issue will happen as a by-product of a result meeting the
-   requirements R-1 and R-2.
-
-
-5.3.  Scalability of the direct trust model
-
-   In the direct relationship of trust between each realm, the realms
-   involved in the cross-realm operation share keys and their respective
-   TGS principals are registered in each other's KDC.  When direct trust
-   relationships are used, the KDC of each realm must maintain keys with
-   all foreign realms.  This can become a cumbersome task when the
-   number of realms increase.  This also increases maintenance cost.
-
-   This issue will happen as a by-product of a result meeting the
-   requirements R-1, R-2 and R-5.
-
-
-5.4.  Exposure to DoS Attacks
-
-   One of the assumption made when allowing the cross-realm operation in
-   Kerberos is that users can communicate with KDCs located in remote
-   realms.  This practice introduces security threats because KDCs are
-   open to the public network.  Administrators may think of restricting
-   the access to the KDC to the trusted realms only.  However, this
-   approach is not scalable and does not really protect the KDC.
-   Indeed, when the remote realms have several IP prefixes (e.g. control
-   centers or outsourcing companies, located world wide), then the
-   administrator of the local KDC must collect the list of prefixes that
-   belong to these organization.  The filtering rules must then
-   explicitly allow the incoming traffic from any host that belongs to
-   one of these prefixes.  This makes the administrator's tasks more
-   complicated and prone to human errors.  And also, the maintenance
-   cost increases.  On the other hand, when ranges of external IP
-   addresses are allowed to communicate with the KDC, the risk of
-
-
-
-S.Sakane, et al.                                                [Page 9]
-
-Internet-Draft                                                 July 2009
-
-
-   becoming target to attacks from remote malicious users increases.
-
-   This issue will happen as a by-product of a result meeting the
-   requirements R-3, R-4 and R-5.
-
-
-5.5.  Client's performance
-
-   In the cross-realm operation, Kerberos clients have to perform TGS
-   exchanges with all the KDCs in the trust path, including the home KDC
-   and the target KDC.  TGS exchange requires cryptographic operations.
-   This exchange demands important processing time especially when the
-   client has limited computational capabilities.  The overhead of these
-   cross-realm exchanges grows into unacceptable delays.
-
-   We ported the MIT Kerberos library (version 1.2.4), implemented a
-   Kerberos client on our original board with H8 (16-bit, 20MHz), and
-   measured the process time of each Kerberos message [KRBIMPL].  It
-   takes 195 milliseconds to perform a TGS exchange with the on-board
-   H/W crypto engine.  Indeed, this result seems reasonable to the
-   requirement of the response time for the control network.  However,
-   we did not modify the clock speed of the H8 during our measurement.
-   The processing time must be slower in a actual environment because H8
-   is used with lowered clock speed in such system.  Also, the delays
-   can grow to unacceptable delays when the number of intermediary
-   realms increases.
-
-   This issue will happen as a by-product of a result meeting the
-   requirements R-1, R-2, R-6 and R-7.
-
-
-5.6.  Pre-authentication problem in roaming scenarios
-
-   In roaming scenarios, the client needs to contact her home KDC to
-   obtain a cross-realm TGT for the local (or visited) realm.  However,
-   the policy of the network access providers or the gateway in the
-   local network usually does not allow clients to communicate with
-   hosts in the Internet unless they provide valid authentication
-   credentials.  In this manner, the client encounters a chicken-and-egg
-   problem where two resources are interdependent; the Internet
-   connection is needed to contact the home KDC and for obtaining
-   credentials, and on the other hand, the Internet connection is only
-   granted for clients who have valid credentials.  As a result, the
-   Kerberos protocol can not be used as it is for authenticating roaming
-   clients requesting network access.
-
-   This issue will happen as a result meeting the requirements R-3 and
-   R-4.
-
-
-
-S.Sakane, et al.                                               [Page 10]
-
-Internet-Draft                                                 July 2009
-
-
-6.  Implementation consideration
-
-   This document just describes issues of the cross-realm operation.
-   However, there are important matters to be considered, when we solve
-   these issues and implement solution.  Solution must not introduce new
-   problem.  It should use existing components or protocols as much as
-   possible, and it should not introduce any definition of new
-   component.  It should not require new changes to existing deployed
-   clients, and it should not influence the client code-base as much as
-   possible.  Because a KDC is a significant server of the Kerberos
-   system.  New burden should not be introduced into a KDC as much as
-   possible.  You must not forget that there would be a trade-off matter
-   anytime.  So an implementation may not solve all of the problems
-   stated in this document.
-
-
-7.  IANA Considerations
-
-   This document makes no request of IANA.
-
-
-8.  Security Considerations
-
-   This document clarifies the issues of the cross-realm operation of
-   the Kerberos V system, which include security issues to be
-   considered.  See Section 5.1, 5.2, 5.3 and 5.4 for further details.
-
-
-9.  Acknowledgments
-
-   The authors are grateful to Nobuo Okabe, Kazunori Miyazawa, and
-   Atsushi Inoue.  They gave us lots of comments and suggestions to this
-   document from the early stage.  Nicolas Williams, Chaskiel Grundman
-   and Love Hornquist Astrand gave valuable suggestions and corrections.
-   Finally, the authors thank to Jeffrey Hutzelman.  He gave us a lot of
-   suggestions for completion of this document.
-
-
-10.  References
-
-
-10.1.  Normative References
-
-   [RFC4120]     Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-                 Kerberos Network Authentication Service (V5)", RFC
-                 4120, July 2005.
-
-
-
-
-
-S.Sakane, et al.                                               [Page 11]
-
-Internet-Draft                                                 July 2009
-
-
-10.2.  Informative References
-
-   [CSPC]        http://www.shellchemicals.com/news/1,1098,72-news_id=
-                 531,00.html
-
-   [KRBIMPL]     "A Prototype of a Secure Autonomous Bootstrap Mechanism
-                 for Control Networks", Nobuo Okabe, Shoichi Sakane,
-                 Masahiro Ishiyama, Atsushi Inoue and Hiroshi Esaki,
-                 SAINT, pp. 56-62, IEEE Computer Society, 2006.
-
-   [NAM]         http://www.nam.nl/
-
-   [RNSS-H8]     http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing.
-                 jsp&fp=/products/mpumcu/h8_family/
-
-   [RNSS-M16C]   http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi
-                 ng.jsp&fp=/products/mpumcu/m16c_family/
-
-   [SHELLCHEM]   http://www.shellchemicals.com/home/1,1098,-1,00.html
-
-   [SPECCROSS]   I. Cervesato and A. Jaggard and A. Scedrov and C.
-                 Walstad, "Specifying Kerberos 5 Cross-Realm
-                 Authentication", Fifth Workshop on Issues in the Theory
-                 of Security, Jan 2005.
-
-Authors' Addresses
-
-   Shoichi Sakane
-   Ken'ichi Kamada
-   Yokogawa Electric Corporation
-   2-9-32 Nakacho, Musashino-shi,
-   Tokyo  180-8750 Japan
-   E-mail: Shouichi.Sakane@jp.yokogawa.com,
-           Ken-ichi.Kamada@jp.yokogawa.com
-
-
-   Saber Zrelli
-   Japan Advanced Institute of Science and Technology
-   1-1 Asahidai, Nomi,
-   Ishikawa  923-1292 Japan
-   E-mail: zrelli@jaist.ac.jp
-
-
-
-
-
-
-
-
-
-
-S.Sakane, et al.                                               [Page 12]
-
-Internet-Draft                                                 July 2009
-
-
-   Masahiro Ishiyama
-   Toshiba Corporation
-   1, komukai-toshiba-cho, Saiwai-ku,
-   Kawasaki  212-8582 Japan
-   E-mail: masahiro@isl.rdc.toshiba.co.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-S.Sakane, et al.                                               [Page 13]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-crypto-03.txt b/doc/standardisation/draft-ietf-krb-wg-crypto-03.txt
deleted file mode 100644
index b1bee6fa4..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-crypto-03.txt
+++ /dev/null
@@ -1,2690 +0,0 @@
-
-
-
-
-
-
-
-
-
-INTERNET DRAFT                                                K. Raeburn
-Kerberos Working Group                                               MIT
-Document: draft-ietf-krb-wg-crypto-03.txt              February 24, 2003
-                                                 expires August 24, 2003
-
-                 Encryption and Checksum Specifications
-                             for Kerberos 5
-
-Abstract
-
-   This document describes a framework for defining encryption and
-   checksum mechanisms for use with the Kerberos protocol [Kerb],
-   defining an abstraction layer between the Kerberos protocol and
-   related protocols, and the actual mechanisms themselves.  Several
-   mechanisms are also defined in this document.  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".
-
-   Comments should be sent to the editor, or to the IETF Kerberos
-   working group (ietf-krb-wg@anl.gov).
-
-Status
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026 [RFC2026].  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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.html.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-
-
-
-
-
-Raeburn                                                         [Page 1]
-
-INTERNET DRAFT                                             February 2003
-
-
-                           Table of Contents
-
-
-Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
-Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
-Table of Contents  . . . . . . . . . . . . . . . . . . . . . . . . .   2
-Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
-1. Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
-2. Encryption algorithm profile  . . . . . . . . . . . . . . . . . .   4
-3. Checksum algorithm profile  . . . . . . . . . . . . . . . . . . .   9
-4. Simplified profile for CBC ciphers with key derivation  . . . . .  10
-4.1. A key derivation function . . . . . . . . . . . . . . . . . . .  10
-4.2. Simplified profile parameters . . . . . . . . . . . . . . . . .  12
-4.3. Cryptosystem profile based on simplified profile  . . . . . . .  14
-4.4. Checksum profiles based on simplified profile . . . . . . . . .  16
-5. Profiles for Kerberos encryption and checksum algorithms  . . . .  16
-5.1. Unkeyed checksums . . . . . . . . . . . . . . . . . . . . . . .  16
-5.2. DES-based encryption and checksum types . . . . . . . . . . . .  18
-5.3. Triple-DES based encryption and checksum types  . . . . . . . .  28
-6. Use of Kerberos encryption outside this specification . . . . . .  30
-7. Assigned Numbers  . . . . . . . . . . . . . . . . . . . . . . . .  31
-8. Implementation Notes  . . . . . . . . . . . . . . . . . . . . . .  32
-9. Security Considerations . . . . . . . . . . . . . . . . . . . . .  33
-10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . .  34
-11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . .  35
-12. Editor's address . . . . . . . . . . . . . . . . . . . . . . . .  35
-13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  36
-A. Test vectors  . . . . . . . . . . . . . . . . . . . . . . . . . .  36
-A.1. n-fold  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  36
-A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . . . . .  38
-A.3. DES3 DR and DK  . . . . . . . . . . . . . . . . . . . . . . . .  42
-A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . . . . .  43
-A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . . . . .  44
-B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . .  44
-Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  45
-Normative References . . . . . . . . . . . . . . . . . . . . . . . .  46
-Informative References . . . . . . . . . . . . . . . . . . . . . . .  48
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 2]
-
-INTERNET DRAFT                                             February 2003
-
-
-Introduction
-
-   The Kerberos protocols 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 any specific encryption
-   algorithm be used, as long as certain operations are available in the
-   algorithm that is used.
-
-   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.  Test vectors for several
-   functions are given in appendix A.
-
-1. Concepts
-
-   Both encryption and checksum mechanisms are defined in terms of
-   profiles, detailed in later sections.  Each 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.  (Integrity checking may be
-   achieved by incorporating a checksum, if the encryption mode does not
-   provide an integrity check itself.)  It must also provide non-
-   malleability [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 knowledge of 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.  It should be infeasible
-   to find two plaintexts which have the same checksum.  It is NOT
-   required that an eavesdropper be unable to determine if two checksums
-   are for the same message; it is assumed that the messages themselves
-   will be visible to any such eavesdropper.
-
-   Due to advances in cryptography, it is considered unwise by some
-   cryptographers to use the same key for multiple purposes.  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.
-
-
-
-
-Raeburn                                                         [Page 3]
-
-INTERNET DRAFT                                             February 2003
-
-
-   We do this by enumerating the different uses of keys within Kerberos,
-   and making the "usage number" an input to the encryption or checksum
-   mechanisms; this enumeration is outside the scope of this document.
-   Later sections of this document 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" to be used for a particular instance of encryption or
-   checksum operations.  It is expected but not required that the
-   specific key will 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 8-bit
-   bytes.  Environments with other byte sizes will have to emulate this
-   behavior in order to get correct results.
-
-   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 7.
-
-2. 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 what 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 specific values that are not valid or desirable
-      for use; such values should be avoid by all key generation
-      routines.
-
-
-
-Raeburn                                                         [Page 4]
-
-INTERNET DRAFT                                             February 2003
-
-
-   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
-      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 has been decided upon, the corresponding checksum
-      mechanism can simply 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 generation
-      of keys that significantly compromise the confidentiality of
-      encrypted data, if the cryptosystem has such.  Entropy from each
-      source should be preserved as much as possible.  Many of the
-      inputs, while 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 timestamps); 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 normally the
-         principal's pass phrase, but is in general 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.  While the strings provided will use UTF-8
-         encoding, no specific version of Unicode should be assumed; all
-         valid UTF-8 strings should be allowed.
-
-         The third argument, the octet string, may be used to pass
-         mechanism-specific parameters in to this function.  Since doing
-
-
-
-Raeburn                                                         [Page 5]
-
-INTERNET DRAFT                                             February 2003
-
-
-         so implies knowledge of the specific encryption system, it is
-         intended that generating non-default parameter values be an
-         uncommon operation, and that normal Kerberos applications be
-         able to treat this parameter block as an opaque object supplied
-         by the KDC or defaulted to some mechanism-specific constant
-         value.
-
-         This should be a one-way function, so that compromising a
-         user's key in one realm does not compromise the user's key in
-         another realm, 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 bit string of a
-         specific size.  It may be assumed that all the bits of the
-         input string are 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; the usage values must be assumed to be known
-         to an attacker.  The specific-key output value was described in
-         section 1.
-
-   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
-      the user's password.  It may be desirable to construct the
-      encoding such that values weakening the resulting key unacceptably
-      cannot be encoded, if practical.
-
-      Tighter bounds might be permitted by local security policy, or to
-      avoid excess resource consumption; if so, recommended defaults for
-      those bounds should be given in the specification.  The
-      description should also outline possible weaknesses that may be
-      caused by not applying bounds checks or other validation 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 is to be used when the application protocol (Kerberos or
-      otherwise) does not explicitly set the parameter value.  As
-
-
-
-Raeburn                                                         [Page 6]
-
-INTERNET DRAFT                                             February 2003
-
-
-      indicated above, this parameter block should be treated as an
-      opaque object in most cases.
-
-   cipher state
-      This describes any information that can be carried over from one
-      encryption or decryption operation to the next, for use in
-      conjunction 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 as
-      to require that messages be decrypted in the same order they were
-      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.
-
-      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 the setting of the initial vector.  This
-      new specification does not permit application control of the
-      cipher state (beyond "initialize" and "carry over from previous
-      encryption"), since the form and content of the initial cipher
-
-
-
-Raeburn                                                         [Page 7]
-
-INTERNET DRAFT                                             February 2003
-
-
-      state can vary between encryption systems, and may not always be a
-      single block of random data.
-
-      New Kerberos application protocols should not assume that they can
-      control 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 (as DES in CBC
-      mode does not do), then some form of MAC or checksum must be
-      included that can be verified by the receiver.  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 not only
-      indicate the precise contents of the output octet string, but also
-      the output cipher state.  The application protocol may carry
-      forward the output cipher state from one encryption with a given
-      specific key to another; the effect of this "chaining" must be
-      defined.  [2]
-
-      Assuming correctly-produced values for the specific key and cipher
-      state, no input octet string may result in an error indication.
-
-   decrypt (specific-key, state, octet string)->(state, octet string)
-      This function takes the specific key, cipher state, and ciphertext
-      as inputs, and verifies the integrity of the supplied ciphertext.
-      If the ciphertext's integrity is intact, this function produces
-      the plaintext and a new cipher state as outputs; otherwise, an
-      error indication must be returned, and the data discarded.
-
-      The result of the decryption may be longer than the original
-      plaintext, for example if the encryption mode adds padding to
-      reach a multiple of a block size.  If this is the case, any extra
-      octets must be after the decoded plaintext.  An application
-      protocol which needs to know the exact length of the message must
-      encode a length or recognizable "end of message" marker within the
-      plaintext.  [3]
-
-      As with the encryption function, a correct specification for this
-
-
-
-Raeburn                                                         [Page 8]
-
-INTERNET DRAFT                                             February 2003
-
-
-      function must indicate not only the contents of the output octet
-      string, but also the resulting cipher state.
-
-   pseudo-random (protocol-key, octet-string)->(octet-string)
-      This pseudo-random function should generate an octet string of
-      some size that independent of the octet string input.  The PRF
-      output string should be suitable for use in key generation, even
-      if the octet string input is public.  It should not reveal the
-      input key, even if the output is made public.
-
-   These operations and attributes are all that should be required to
-   support Kerberos and various proposed preauthentication schemes.
-
-   A document defining a new encryption type should also describe known
-   weaknesses or attacks, so that its security may be fairly assessed,
-   and should include test vectors or other validation procedures for
-   the operations defined.  Specific references to information readily
-   available elsewhere are sufficient.
-
-3. Checksum algorithm profile
-
-   A checksum mechanism profile must define the following attributes and
-   operations:
-
-   associated encryption algorithm(s)
-      This indicates the types of encryption keys this checksum
-      mechanism can be used with.
-
-      A keyed checksum mechanism may have more than one associated
-      encryption algorithm if they share the same wire key format,
-      string-to-key function, and key derivation function. (This
-      combination means that, for example, a checksum type, key usage
-      value and password are adequate to get the specific key used to
-      compute a checksum.)
-
-      An unkeyed checksum mechanism can be used in conjunction with any
-      encryption type, since the key is ignored, but its use must be
-      limited to cases where the checksum itself is protected, to avoid
-      trivial attacks.
-
-   get_mic function
-      This function generates a MIC token for a given specific key (see
-      section 2), and message (represented as an octet string), that may
-      be used to verify the integrity of the associated message.  This
-      function is not required to return the same deterministic result
-      on every use; it need only generate a token that the verify_mic
-      routine can check.
-
-
-
-
-Raeburn                                                         [Page 9]
-
-INTERNET DRAFT                                             February 2003
-
-
-      The output of this function will also dictate the size of the
-      checksum.
-
-   verify_mic function
-      Given a specific key, message, and MIC token, this function
-      ascertains whether the message integrity has been compromised.
-      For a deterministic get_mic routine, the corresponding verify_mic
-      may simply generate another checksum and compare them.
-
-   The get_mic and verify_mic operations must be able to handle inputs
-   of arbitrary length; if any padding is needed, the padding scheme
-   must be specified as part of these functions.
-
-   These operations and attributes are all that should be required to
-   support Kerberos and various proposed preauthentication schemes.
-
-   As with encryption mechanism definition documents, documents defining
-   new checksum mechanisms should indicate validation processes and
-   known weaknesses.
-
-4. Simplified profile for CBC ciphers with key derivation
-
-   The profile outlines in sections 2 and 3 describes a large number of
-   operations that must be defined for encryption and checksum
-   algorithms to be used with Kerberos.  We describe here a simpler
-   profile from which both encryption and checksum mechanism definitions
-   can be generated, filling in uses of key derivation in appropriate
-   places, providing integrity protection, and defining multiple
-   operations for the cryptosystem profile based on a smaller set of
-   operations given in the simplified profile.  Not all of the existing
-   cryptosystems for Kerberos fit into this simplified profile, but we
-   recommend that future cryptosystems use it or something based on it.
-   [4]
-
-   Not all of the operations in the complete profiles are defined
-   through this mechanism; several must still be defined for each new
-   algorithm pair.
-
-4.1. A key derivation function
-
-   Rather than define some scheme by which a "protocol key" is composed
-   of a large number of encryption keys, we use keys derived from a base
-   key to perform cryptographic operations.  The base key must be used
-   only for generating the derived keys, and this derivation must be
-   non-invertible and entropy-preserving.  Given these restrictions,
-   compromise of one derived key does not compromise the other subkeys.
-   Attack of the base key is limited, since it is only used for
-   derivation, and is not exposed to any user data.
-
-
-
-Raeburn                                                        [Page 10]
-
-INTERNET DRAFT                                             February 2003
-
-
-   Since the derived key has as much entropy as the base keys (if the
-   cryptosystem is good), password-derived keys have the full benefit of
-   all the entropy in the password.
-
-   To generate a derived key from a base key, we generate a pseudorandom
-   octet string, using an algorithm DR described below, and generate a
-   key from that octet string using a function dependent on the
-   encryption algorithm; the input length needed for that function,
-   which is also dependent on the encryption algorithm, dictates the
-   length of the string to be generated by the DR algorithm (the value
-   "k" below).  These procedures are based on the key derivation in
-   [Blumenthal96].
-
-      Derived Key = DK(Base Key, Well-Known Constant)
-
-      DK(Key, Constant) = random-to-key(DR(Key, Constant))
-
-      DR(Key, Constant) = k-truncate(E(Key, Constant,
-                                       initial-cipher-state))
-
-   Here DR is the random-octet generation function described below, and
-   DK is the key-derivation function produced from it.  In this
-   construction, E(Key, Plaintext, CipherState) is a cipher, Constant is
-   a well-known constant determined by the specific usage of this
-   function, and k-truncate truncates its argument by taking the first k
-   bits.  Here, k is the key generation seed length needed for the
-   encryption system.
-
-   The output of the DR function is a string of bits; the actual key is
-   produced by applying the cryptosystem's random-to-key operation on
-   this bitstring.
-
-   If the Constant is smaller than the cipher block size of E, then it
-   must be expanded with n-fold() so it can be encrypted.  If the output
-   of E is shorter than k bits it is fed back into the encryption as
-   many times as necessary.  The construct is as follows (where |
-   indicates concatentation):
-
-      K1 = E(Key, n-fold(Constant), initial-cipher-state)
-      K2 = E(Key, K1, initial-cipher-state)
-      K3 = E(Key, K2, initial-cipher-state)
-      K4 = ...
-
-      DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
-
-   n-fold is an algorithm which takes m input bits and ``stretches''
-   them to form n output bits with equal contribution from each input
-   bit to the output, as described in [Blumenthal96]:
-
-
-
-Raeburn                                                        [Page 11]
-
-INTERNET DRAFT                                             February 2003
-
-
-      We first define a primitive called n-folding, which takes a
-      variable-length input block and produces a fixed-length output
-      sequence.  The intent is to give each input bit approximately
-      equal weight in determining the value of each output bit.  Note
-      that whenever we need to treat a string of octets as a number, the
-      assumed representation is Big-Endian -- Most Significant Byte
-      first.
-
-      To n-fold a number X, replicate the input value to a length that
-      is the least common multiple of n and the length of X.  Before
-      each repetition, the input is rotated to the right by 13 bit
-      positions.  The successive n-bit chunks are added together using
-      1's-complement addition (that is, with end-around carry) to yield
-      a n-bit result....
-
-
-   Test vectors for n-fold are supplied in Appendix A.  [5]
-
-   In this section, n-fold is always used to produce c bits of output,
-   where c is the cipher block size of E.
-
-   The size of the Constant must not be larger than c, because reducing
-   the length of the Constant by n-folding can cause collisions.
-
-   If the size of the Constant is smaller than c, then the Constant must
-   be n-folded to length c.  This string is used as input to E.  If the
-   block size of E is less than the random-to-key input size, then the
-   output from E is taken as input to a second invocation of E.  This
-   process is repeated until the number of bits accumulated is greater
-   than or equal to the random-to-key input size.  When enough bits have
-   been computed, the first k are taken as the random data used to
-   create the key with the algorithm-dependent random-to-key function.
-
-   Since the derived key is the result of one or more encryptions in the
-   base key, deriving the base key from the derived key is equivalent to
-   determining the key from a very small number of plaintext/ciphertext
-   pairs.  Thus, this construction is as strong as the cryptosystem
-   itself.
-
-4.2. Simplified profile parameters
-
-   These are the operations and attributes that must be defined:
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 12]
-
-INTERNET DRAFT                                             February 2003
-
-
-   protocol key format
-   string-to-key function
-   default string-to-key parameters
-   key-generation seed length, k
-   random-to-key function
-      As above for the normal encryption mechanism profile.
-
-   unkeyed hash algorithm, H
-      This should be a collision-resistant hash algorithm with fixed-
-      size output, suitable for use in an HMAC [HMAC].  It must support
-      inputs of arbitrary length.  Its output must be at least the
-      message block size (below).
-
-   HMAC output size, h
-      This indicates the size of the leading substring output by the
-      HMAC function that should be used in transmitted messages.  It
-      should be at least half the output size of the hash function H,
-      and at least 80 bits; it need not match the output size.
-
-   message block size, m
-      This is the size of the smallest units the cipher can handle in
-      the mode in which it is being used.  Messages will be padded to a
-      multiple of this size.  If a block cipher is used in a mode that
-      can handle messages that are not multiples of the cipher block
-      size, such as CBC mode with cipher text stealing (CTS, see [RC5]),
-      this value would be one octet.  For traditional CBC mode with
-      padding, it will be the underlying cipher's block size.
-
-      This value must be a multiple of 8 bits (one octet).
-
-   encryption/decryption functions, E and D
-      These are basic encryption and decryption functions for messages
-      of sizes that are multiples of the message block size.  No
-      integrity checking or confounder should be included here.  These
-      functions take as input the IV or similar data, a protocol-format
-      key, and a octet string, returning a new IV and octet string.
-
-      The encryption function is not required to use CBC mode, but is
-      assumed to be using something with similar properties.  In
-      particular, prepending a cipher-block-size confounder to the
-      plaintext should alter the entire ciphertext (comparable to
-      choosing and including a random initial vector for CBC mode).
-
-      The result of encrypting one cipher block (of size c, above) must
-      be deterministic, for the random octet generation function DR in
-      the previous section to work.  For best security, it should also
-      be no larger than c.
-
-
-
-
-Raeburn                                                        [Page 13]
-
-INTERNET DRAFT                                             February 2003
-
-
-   cipher block size, c
-      This is the block size of the block cipher underlying the
-      encryption and decryption functions indicated above, used for key
-      derivation and for the size of the message confounder and initial
-      vector.  (If a block cipher is not in use, some comparable
-      parameter should be determined.)  It must be at least 5 octets.
-
-      This is not actually an independent parameter; rather, it is a
-      property of the functions E and D.  It is listed here to clarify
-      the distinction between it and the message block size, m.
-
-   While there are still a number of properties to specify, they are
-   fewer and simpler than in the full profile.
-
-4.3. Cryptosystem profile based on simplified profile
-
-   The above key derivation function is used to produce three
-   intermediate keys.  One is used for computing checksums of
-   unencrypted data.  The other two are used for encrypting and
-   checksumming plaintext to be sent encrypted.
-
-   The ciphertext output is the concatenation of the output of the basic
-   encryption function E and a (possibly truncated) HMAC using the
-   specified hash function H, both applied to the plaintext with a
-   random confounder prefix and sufficient padding to bring it to a
-   multiple of the message block size.  When the HMAC is computed, the
-   key is used in the protocol key form.
-
-   Decryption is performed by removing the (partial) HMAC, decrypting
-   the remainder, and verifying the HMAC.  The cipher state is an
-   initial vector, initialized to zero.
-
-   The substring notation "[1..h]" in the following table should be read
-   as using 1-based indexing; leading substrings are used.
-
-
-                   cryptosystem from simplified profile
-----------------------------------------------------------------------------
-protocol key format       As given.
-
-specific key structure    Three protocol-format keys: { Kc, Ke, Ki }.
-
-key-generation seed       As given.
-length
-
-required checksum         As defined below in section 4.4.
-mechanism
-
-
-
-
-Raeburn                                                        [Page 14]
-
-INTERNET DRAFT                                             February 2003
-
-
-                   cryptosystem from simplified profile
-----------------------------------------------------------------------------
-
-cipher state              initial vector (usually of length c)
-
-initial cipher state      all bits zero
-
-encryption function       conf = random string of length c
-                          pad = shortest string to bring confounder
-                                and plaintext to a length that's a
-                                multiple of m
-                          C1 = E(Ke, conf | plaintext | pad,
-                                 oldstate.ivec)
-                          H1 = HMAC(Ki, conf | plaintext | pad)
-                          ciphertext =  C1 | H1[1..h]
-                          newstate.ivec = last c of C1
-
-decryption function       (C1,H1) = ciphertext
-                          P1 = D(Ke, C1, oldstate.ivec)
-                          if (H1 != HMAC(Ki, P1)[1..h])
-                             report error
-                          newstate.ivec = last c of C1
-
-default string-to-key     As given.
-params
-
-pseudo-random function    tmp1 = H(octet-string)
-                          tmp2 = truncate tmp1 to multiple of m
-                          PRF = E(protocol-key, tmp2, initial-cipher-state)
-
-key generation functions:
-
-string-to-key function    As given.
-
-random-to-key function    As given.
-
-key-derivation function   The "well-known constant" used for the DK
-                          function is the key usage number, expressed as
-                          four octets in big-endian order, followed by one
-                          octet indicated below.
-
-                          Kc = DK(base-key, usage | 0x99);
-                          Ke = DK(base-key, usage | 0xAA);
-                          Ki = DK(base-key, usage | 0x55);
-
-
-
-
-
-
-
-Raeburn                                                        [Page 15]
-
-INTERNET DRAFT                                             February 2003
-
-
-4.4. Checksum profiles based on simplified profile
-
-   When an encryption system is defined using the simplified profile
-   given in section 4.2, a checksum algorithm may be defined for it as
-   follows:
-
-
-                checksum mechanism from simplified profile
-             --------------------------------------------------
-             associated cryptosystem   as defined above
-
-             get_mic                   HMAC(Kc, message)[1..h]
-
-             verify_mic                get_mic and compare
-
-   The HMAC function and key Kc are as described in section 4.3.
-
-5. Profiles for Kerberos encryption and checksum algorithms
-
-   These profiles describe the encryption and checksum systems defined
-   for Kerberos.  The astute reader will notice that some of them do not
-   fulfull all of the requirements outlined in previous sections.  These
-   systems are defined for backward compatibility; newer implementations
-   should (whenever possible) attempt to make use of encryption systems
-   which satisfy all of the profile requirements.
-
-   The full list of current encryption and checksum type number
-   assignments, including values currently reserved but not defined in
-   this document, is given in section 7.
-
-5.1. Unkeyed checksums
-
-   These checksum types use no encryption keys, and thus can be used in
-   combination with any encryption type, but may only be used with
-   caution, in limited circumstances where the lack of a key does not
-   provide a window for an attack, preferably as part of an encrypted
-   message.  [6] Keyed checksum algorithms are recommended.
-
-5.1.1. The RSA MD5 Checksum
-
-   The RSA-MD5 checksum calculates a checksum using the RSA MD5
-   algorithm [MD5-92].  The algorithm takes as input an input message of
-   arbitrary length and produces as output a 128-bit (16 octet)
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 16]
-
-INTERNET DRAFT                                             February 2003
-
-
-   checksum.  RSA-MD5 is believed to be collision-proof.
-
-                                  rsa-md5
-               ----------------------------------------------
-               associated cryptosystem   any
-
-               get_mic                   rsa-md5(msg)
-
-               verify_mic                get_mic and compare
-
-   The rsa-md5 checksum algorithm is assigned a checksum type number of
-   seven (7).
-
-5.1.2. The RSA MD4 Checksum
-
-   The RSA-MD4 checksum calculates a checksum using the RSA MD4
-   algorithm [MD4-92].  The algorithm takes as input an input message of
-   arbitrary length and produces as output a 128-bit (16 octet)
-   checksum.  RSA-MD4 is believed to be collision-proof.
-
-
-                                  rsa-md4
-               ----------------------------------------------
-               associated cryptosystem   any
-
-               get_mic                   md4(msg)
-
-               verify_mic                get_mic and compare
-
-
-   The rsa-md4 checksum algorithm is assigned a checksum type number of
-   two (2).
-
-5.1.3. CRC-32 Checksum
-
-   This CRC-32 checksum calculates a checksum based on a cyclic
-   redundancy check as described in ISO 3309 [CRC], modified as
-   described below.  The resulting checksum is four (4) octets in
-   length.  The CRC-32 is neither keyed nor collision-proof; thus, the
-   use of this checksum is not recommended.  An attacker using a
-   probabilistic chosen-plaintext attack as described in [SG92] might be
-   able to generate an alternative message that satisfies the checksum.
-
-   The CRC-32 checksum used in the des-cbc-crc encryption mode is
-   identical to the 32-bit FCS described in ISO 3309 with two
-   exceptions: the sum with the all-ones polynomial times x**k is
-   omitted, and the final remainder is not ones-complemented.  ISO 3309
-   describes the FCS in terms of bits, while this document describes the
-
-
-
-Raeburn                                                        [Page 17]
-
-INTERNET DRAFT                                             February 2003
-
-
-   Kerberos protocol in terms of octets.  To disambiguate the ISO 3309
-   definition for the purpose of computing the CRC-32 in the des-cbc-crc
-   encryption mode, the ordering of bits in each octet shall be assumed
-   to be LSB-first.  Given this assumed ordering of bits within an
-   octet, the mapping of bits to polynomial coefficients shall be
-   identical to that specified in ISO 3309.
-
-   Test values for this modified CRC function are included in appendix
-   A.5.
-
-
-                                   crc32
-               ----------------------------------------------
-               associated cryptosystem   any
-
-               get_mic                   crc32(msg)
-
-               verify_mic                get_mic and compare
-
-
-   The crc32 checksum algorithm is assigned a checksum type number of
-   one (1).
-
-5.2. DES-based encryption and checksum types
-
-   These encryption systems encrypt information under the Data
-   Encryption Standard [DES77] using the cipher block chaining mode
-   [DESM80].  A checksum is computed as described below and placed in
-   the cksum field.  DES blocks are 8 bytes.  As a result, the data to
-   be encrypted (the concatenation of confounder, checksum, and message)
-   must be padded to an 8 byte boundary before encryption.  The values
-   of the padding bytes are unspecified.
-
-   Plaintext and DES ciphertext are encoded as blocks of 8 octets which
-   are concatenated to make the 64-bit inputs for the DES algorithms.
-   The first octet supplies the 8 most significant bits (with the
-   octet's MSB used as the DES input block's MSB, etc.), the second
-   octet the next 8 bits, ..., and the eighth octet supplies the 8 least
-   significant bits.
-
-   Encryption under DES using cipher block chaining requires an
-   additional input in the form of an initialization vector; this vector
-   is specified for each encryption system, below.
-
-   The DES specifications [DESI81] identify four 'weak' and twelve
-   'semi-weak' keys; those keys shall not be used for encrypting
-   messages for use in Kerberos.
-
-
-
-
-Raeburn                                                        [Page 18]
-
-INTERNET DRAFT                                             February 2003
-
-
-   A DES key is 8 octets of data.  This consists of 56 bits of actual
-   key data, and 8 parity bits, one per octet.  The key is encoded as a
-   series of 8 octets written in MSB-first order.  The bits within the
-   key are also encoded in MSB order.  For example, if the encryption
-   key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8)
-   where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8
-   are the parity bits, the first octet of the key would be
-   B1,B2,...,B7,P1 (with B1 as the most significant bit).  See the
-   [DESM80] introduction for reference.
-
-   Encryption data format
-
-   The format for the data to be encrypted includes a one-block
-   confounder, a checksum, the encoded plaintext, and any necessary
-   padding, as described in the following diagram.  The msg-seq field
-   contains the part of the protocol message which is to be encrypted.
-
-                  +-----------+----------+---------+-----+
-                  |confounder | checksum | msg-seq | pad |
-                  +-----------+----------+---------+-----+
-
-   One generates a random confounder of one block, placing it in
-   'confounder'; zeroes out the 'checksum' field (of length appropriate
-   to exactly hold the checksum to be computed); calculates the
-   appropriate checksum over the whole sequence, placing the result in
-   'checksum'; adds the necessary padding; then encrypts using the
-   specified encryption type and the appropriate key.
-
-   String or random-data to key transformation
-
-   To generate a DES key from two UTF-8 text strings (password and
-   salt), the two strings are concatenated, password first, and the
-   result is then padded with zero-valued octets to a multiple of 8
-   octets.
-
-   The top bit of each octet (always zero if the password is plain
-   ASCII, as was assumed when the original specification was written) is
-   discarded, and a bitstring is formed of the remaining seven bits of
-   each octet.  This bitstring is then fan-folded and eXclusive-ORed
-   with itself to produce a 56-bit string.  An eight-octet key is formed
-   from this string, each octet using seven bits from the bit string,
-   leaving the least significant bit unassigned.  The key is then
-   "corrected" by correcting the parity on the key, and if the key
-   matches a 'weak' or 'semi-weak' key as described in the DES
-   specification, it is eXclusive-ORed with the constant
-   0x00000000000000F0.  This key is then used to generate a DES CBC
-   checksum on the initial string with the salt appended.  The result of
-   the CBC checksum is then "corrected" as described above to form the
-
-
-
-Raeburn                                                        [Page 19]
-
-INTERNET DRAFT                                             February 2003
-
-
-   result which is returned as the key.
-
-   For purposes of the string-to-key function, the DES CBC checksum is
-   calculated by CBC encrypting a string using the key as IV and using
-   the final 8 byte block as the checksum.
-
-   Pseudocode follows:
-
-        removeMSBits(8byteblock) {
-          /* Treats a 64 bit block as 8 octets and remove the MSB in
-             each octect (in big endian mode) and concatenates the
-             result.  E.g., input octet string:
-                01110000 01100001 11110011  01110011 11110111 01101111
-                11110010 01100100
-             results in output bit string:
-                1110000 1100001 1110011  1110011 1110111 1101111
-                1110010 1100100  */
-        }
-
-        reverse(56bitblock) {
-          /* Treats a 56-bit block as a binary string and reverse it.
-             E.g., input string:
-                1000001 1010100 1001000  1000101 1001110 1000001
-                0101110 1001101
-             results in output string:
-                1011001 0111010 1000001  0111001 1010001 0001001
-                0010101 1000001  */
-        }
-
-        add_parity_bits(56bitblock) {
-          /* Copies a 56-bit block into a 64-bit block, left shift
-             content in each octet and add DES parity bit.
-             E.g., input string:
-                1100000 0001111 0011100  0110100 1000101 1100100
-                0110110 0010111
-             results in output string:
-                11000001 00011111 00111000  01101000 10001010 11001000
-                01101101 00101111  */
-        }
-
-        key_correction(key) {
-             fixparity(key);
-             if (is_weak_key(key))
-                  key = key XOR 0xF0;
-             return(key);
-        }
-
-
-
-
-
-Raeburn                                                        [Page 20]
-
-INTERNET DRAFT                                             February 2003
-
-
-        mit_des_string_to_key(string,salt) {
-             odd = 1;
-             s = string | salt;
-             tempstring = 0; /* 56-bit string */
-             pad(s); /* with nulls to 8 byte boundary */
-             for (8byteblock in s) {
-                  56bitstring = removeMSBits(8byteblock);
-                  if (odd == 0) reverse(56bitstring);
-                  odd = ! odd;
-                  tempstring = tempstring XOR 56bitstring;
-             }
-             tempkey = key_correction(add_parity_bits(tempstring));
-             key = key_correction(DES-CBC-check(s,tempkey));
-             return(key);
-        }
-
-        des_string_to_key(string,salt,params) {
-             if (length(params) == 0)
-                  type = 0;
-             else if (length(params) == 1)
-                  type = params[0];
-             else
-                  error("invalid params");
-             if (type == 0)
-                  mit_des_string_to_key(string,salt);
-             else
-                  error("invalid params");
-        }
-
-   One common extension is to support the "AFS string-to-key" algorithm,
-   which is not defined here, if the type value above is one (1).
-
-   For generation of a key from a random bit-string, we start with a
-   56-bit string, and as with the string-to-key operation above, insert
-   parity bits, and if the result is a weak or semi-weak key, modify it
-   by exclusive-OR with the constart 0x00000000000000F0:
-
-        des_random_to_key(bitstring) {
-             return key_correction(add_parity_bits(bitstring));
-        }
-
-5.2.1. DES with MD5
-
-   The des-cbc-md5 encryption mode encrypts information under DES in CBC
-   mode with an all-zero initial vector, with an MD5 checksum (described
-   in [MD5-92]) computed and placed in the checksum field.
-
-
-
-
-
-Raeburn                                                        [Page 21]
-
-INTERNET DRAFT                                             February 2003
-
-
-   The encryption system parameters for des-cbc-md5 are:
-
-                                des-cbc-md5
-    --------------------------------------------------------------------
-    protocol key format      8 bytes, parity in low bit of each
-
-    specific key structure   copy of original key
-
-    required checksum        rsa-md5-des
-    mechanism
-
-    key-generation seed      8 bytes
-    length
-
-    cipher state             8 bytes (CBC initial vector)
-
-    initial cipher state     all-zero
-
-    encryption function      des-cbc(confounder | checksum | msg | pad,
-                                     ivec=oldstate)
-                             where
-                             checksum = md5(confounder | 0000...
-                                            | msg | pad)
-
-                             newstate = last block of des-cbc output
-
-    decryption function      decrypt encrypted text and verify checksum
-
-                             newstate = last block of ciphertext
-
-    default string-to-key    empty string
-    params
-
-    pseudo-random function   des-cbc(md5(input-string), ivec=0)
-
-    key generation functions:
-
-    string-to-key            des_string_to_key
-
-    random-to-key            des_random_to_key
-
-    key-derivation           identity
-
-   The des-cbc-md5 encryption type is assigned the etype value three
-   (3).
-
-
-
-
-
-
-Raeburn                                                        [Page 22]
-
-INTERNET DRAFT                                             February 2003
-
-
-5.2.2. DES with MD4
-
-   The des-cbc-md4 encryption mode also encrypts information under DES
-   in CBC mode, with an all-zero initial vector.  An MD4 checksum
-   (described in [MD4-92]) is computed and placed in the checksum field.
-
-                                des-cbc-md4
-    --------------------------------------------------------------------
-    protocol key format      8 bytes, parity in low bit of each
-
-    specific key structure   copy of original key
-
-    required checksum        rsa-md4-des
-    mechanism
-
-    key-generation seed      8 bytes
-    length
-
-    cipher state             8 bytes (CBC initial vector)
-
-    initial cipher state     all-zero
-
-    encryption function      des-cbc(confounder | checksum | msg | pad,
-                                     ivec=oldstate)
-                             where
-                             checksum = md4(confounder | 0000...
-                                            | msg | pad)
-
-                             newstate = last block of des-cbc output
-
-    decryption function      decrypt encrypted text and verify checksum
-
-                             newstate = last block of ciphertext
-
-    default string-to-key    empty string
-    params
-
-    pseudo-random function   des-cbc(md5(input-string), ivec=0)
-
-    key generation functions:
-
-    string-to-key            des_string_to_key
-
-    random-to-key            copy input, then fix parity bits
-
-    key-derivation           identity
-
-
-
-
-
-Raeburn                                                        [Page 23]
-
-INTERNET DRAFT                                             February 2003
-
-
-   Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
-
-   The des-cbc-md4 encryption algorithm is assigned the etype value two
-   (2).
-
-5.2.3. DES with CRC
-
-   The des-cbc-crc encryption type uses DES in CBC mode with the key
-   used as the initialization vector, with a 4-octet CRC-based checksum
-   computed as described in section 5.1.3.  Note that this is not a
-   standard CRC-32 checksum, but a slightly modified one.
-
-
-                                des-cbc-crc
-    --------------------------------------------------------------------
-    protocol key format      8 bytes, parity in low bit of each
-
-    specific key structure   copy of original key
-
-    required checksum        rsa-md5-des
-    mechanism
-
-    key-generation seed      8 bytes
-    length
-
-    cipher state             8 bytes (CBC initial vector)
-
-    initial cipher state     copy of original key
-
-    encryption function      des-cbc(confounder | checksum | msg | pad,
-                                     ivec=oldstate)
-                             where
-                             checksum = crc(confounder | 00000000
-                                            | msg | pad)
-
-                             newstate = last block of des-cbc output
-
-    decryption function      decrypt encrypted text and verify checksum
-
-                             newstate = last block of ciphertext
-
-    default string-to-key    empty string
-    params
-
-    pseudo-random function   des-cbc(md5(input-string), ivec=0)
-
-    key generation functions:
-
-
-
-
-Raeburn                                                        [Page 24]
-
-INTERNET DRAFT                                             February 2003
-
-
-                                des-cbc-crc
-    --------------------------------------------------------------------
-
-    string-to-key            des_string_to_key
-
-    random-to-key            copy input, then fix parity bits
-
-    key-derivation           identity
-
-   The des-cbc-crc encryption algorithm is assigned the etype value one
-   (1).
-
-5.2.4. RSA MD5 Cryptographic Checksum Using DES
-
-   The RSA-MD5-DES checksum calculates a keyed collision-proof checksum
-   by prepending an 8 octet confounder before the text, applying the RSA
-   MD5 checksum algorithm, and encrypting the confounder and the
-   checksum using DES in cipher-block-chaining (CBC) mode using a
-   variant of the key, where the variant is computed by eXclusive-ORing
-   the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0.  The
-   initialization vector should be zero.  The resulting checksum is 24
-   octets long.  This checksum is tamper-proof and believed to be
-   collision-proof.
-
-   The DES specifications identify some 'weak keys' and 'semi-weak
-   keys'; those keys shall not be used for encrypting RSA-MD5 checksums
-   for use in Kerberos.
-
-
-                                rsa-md5-des
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
-                                        conf | rsa-md5(conf | msg))
-
-      verify_mic                decrypt and verify rsa-md5 checksum
-
-
-   The rsa-md5-des checksum algorithm is assigned a checksum type number
-   of eight (8).
-
-5.2.5. RSA MD4 Cryptographic Checksum Using DES
-
-   The RSA-MD4-DES checksum calculates a keyed collision-proof checksum
-   by prepending an 8 octet confounder before the text, applying the RSA
-   MD4 checksum algorithm [MD4-92], and encrypting the confounder and
-   the checksum using DES in cipher-block-chaining (CBC) mode using a
-
-
-
-Raeburn                                                        [Page 25]
-
-INTERNET DRAFT                                             February 2003
-
-
-   variant of the key, where the variant is computed by eXclusive-ORing
-   the key with the constant 0xF0F0F0F0F0F0F0F0.  [7] The initialization
-   vector should be zero.  The resulting checksum is 24 octets long.
-   This checksum is tamper-proof and believed to be collision-proof.
-
-   The DES specifications identify some "weak keys" and "semi-weak
-   keys"; those keys shall not be used for generating RSA-MD4 checksums
-   for use in Kerberos.
-
-                                rsa-md4-des
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
-                                        conf | rsa-md4(conf | msg),
-                                        ivec=0)
-
-      verify_mic                decrypt and verify rsa-md4 checksum
-
-   The rsa-md4-des checksum algorithm is assigned a checksum type number
-   of three (3).
-
-5.2.6. RSA MD4 Cryptographic Checksum Using DES alternative
-
-   The RSA-MD4-DES-K checksum calculates a keyed collision-proof
-   checksum by applying the RSA MD4 checksum algorithm and encrypting
-   the results using DES in cipher block chaining (CBC) mode using a DES
-   key as both key and initialization vector.  The resulting checksum is
-   16 octets long.  This checksum is tamper-proof and believed to be
-   collision-proof.  Note that this checksum type is the old method for
-   encoding the RSA-MD4-DES checksum and it is no longer recommended.
-
-
-                               rsa-md4-des-k
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-cbc(key, md4(msg), ivec=key)
-
-      verify_mic                decrypt, compute checksum and compare
-
-
-   The rsa-md4-des-k checksum algorithm is assigned a checksum type
-   number of six (6).
-
-
-
-
-
-
-
-Raeburn                                                        [Page 26]
-
-INTERNET DRAFT                                             February 2003
-
-
-5.2.7. DES CBC checksum
-
-   The DES-MAC checksum is computed by prepending an 8 octet confounder
-   to the plaintext, padding with zero-valued octets if necessary to
-   bring the length to a multiple of 8 octets, performing a DES CBC-mode
-   encryption on the result using the key and an initialization vector
-   of zero, taking the last block of the ciphertext, prepending the same
-   confounder and encrypting the pair using DES in cipher-block-chaining
-   (CBC) mode using a variant of the key, where the variant is computed
-   by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0.  The
-   initialization vector should be zero.  The resulting checksum is 128
-   bits (16 octets) long, 64 bits of which are redundant.  This checksum
-   is tamper-proof and collision-proof.
-
-
-                                  des-mac
-   ----------------------------------------------------------------------
-   associated     des-cbc-md5, des-cbc-md4, des-cbc-crc
-   cryptosystem
-
-   get_mic        des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
-                          conf | des-mac(key, conf | msg | pad, ivec=0),
-                          ivec=0)
-
-   verify_mic     decrypt, compute DES MAC using confounder, compare
-
-
-   The des-mac checksum algorithm is assigned a checksum type number of
-   four (4).
-
-5.2.8. DES CBC checksum alternative
-
-   The DES-MAC-K checksum is computed by performing a DES CBC-mode
-   encryption of the plaintext, with zero-valued padding bytes if
-   necessary to bring the length to a multiple of 8 octets, and using
-   the last block of the ciphertext as the checksum value.  It is keyed
-   with an encryption key which is also used as the initialization
-   vector.  The resulting checksum is 64 bits (8 octets) long.  This
-   checksum is tamper-proof and collision-proof.  Note that this
-   checksum type is the old method for encoding the DESMAC checksum and
-   it is no longer recommended.
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 27]
-
-INTERNET DRAFT                                             February 2003
-
-
-                                 des-mac-k
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-mac(key, msg | pad, ivec=key)
-
-      verify_mic                compute MAC and compare
-
-
-   The des-mac-k checksum algorithm is assigned a checksum type number
-   of five (5).
-
-5.3. Triple-DES based encryption and checksum types
-
-   This encryption and checksum type pair is based on the Triple DES
-   cryptosystem in Outer-CBC mode, and the HMAC-SHA1 message
-   authentication algorithm.
-
-   A Triple DES key is the concatenation of three DES keys as described
-   above for des-cbc-md5.  A Triple DES key is generated from random
-   data by creating three DES keys from separate sequences of random
-   data.
-
-   Encrypted data using this type must be generated as described in
-   section 4.3.  If the length of the input data is not a multiple of
-   the block size, zero-valued octets must be used to pad the plaintext
-   to the next eight-octet boundary.  The confounder must be eight
-   random octets (one block).
-
-   The simplified profile for Triple DES, with key derivation as defined
-   in section 4, is as follows:
-
-                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
-              ------------------------------------------------
-              protocol key format     24 bytes, parity in low
-                                      bit of each
-
-              key-generation seed     21 bytes
-              length
-
-              hash function           SHA-1
-
-              HMAC output size        160 bits
-
-              message block size      8 bytes
-
-
-
-
-
-
-Raeburn                                                        [Page 28]
-
-INTERNET DRAFT                                             February 2003
-
-
-                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
-              ------------------------------------------------
-              default string-to-key   empty string
-              params
-
-              encryption and          triple-DES encrypt and
-              decryption functions    decrypt, in outer-CBC
-                                      mode (cipher block size
-                                      8 octets)
-
-              key generation functions:
-
-              random-to-key           DES3random-to-key (see
-                                      below)
-
-              string-to-key           DES3string-to-key (see
-                                      below)
-
-   The des3-cbc-hmac-sha1-kd encryption type is assigned the value
-   sixteen (16).  The hmac-sha1-des3-kd checksum algorithm is assigned a
-   checksum type number of twelve (12).
-
-5.3.1. Triple DES Key Production (random-to-key, string-to-key)
-
-   The 168 bits of random key data are converted to a protocol key value
-   as follows.  First, the 168 bits are divided into three groups of 56
-   bits, which are expanded individually into 64 bits as follows:
-
-   DES3random-to-key:
-         1  2  3  4  5  6  7  p
-         9 10 11 12 13 14 15  p
-        17 18 19 20 21 22 23  p
-        25 26 27 28 29 30 31  p
-        33 34 35 36 37 38 39  p
-        41 42 43 44 45 46 47  p
-        49 50 51 52 53 54 55  p
-        56 48 40 32 24 16  8  p
-
-   The "p" bits are parity bits computed over the data bits.  The output
-   of the three expansions are concatenated to form the protocol key
-   value.
-
-   The string-to-key function is used to transform UTF-8 passwords into
-   DES3 keys.  The DES3 string-to-key function relies on the "N-fold"
-   algorithm and DK function, described in section 4.
-
-   The n-fold algorithm is applied to the password string concatenated
-   with a salt value.  For 3-key triple DES, the operation will involve
-
-
-
-Raeburn                                                        [Page 29]
-
-INTERNET DRAFT                                             February 2003
-
-
-   a 168-fold of the input password string, to generate an intermediate
-   key, from which the user's long-term key will be derived with the DK
-   function.  The DES3 string-to-key function is shown here in
-   pseudocode:
-
-         DES3string-to-key(passwordString, salt, params)
-             if (params != emptyString)
-              error("invalid params");
-             s = passwordString + salt
-             tmpKey = random-to-key(168-fold(s))
-             key = DK (tmpKey, KerberosConstant)
-
-   No weak-key checking is performed.  The KerberosConstant value is the
-   byte string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}.  These values
-   correspond to the ASCII encoding for the string "kerberos".
-
-6. Use of Kerberos encryption outside this specification
-
-   Several Kerberos-based application protocols and preauthentication
-   systems have been designed and deployed that perform encryption and
-   message integrity checks in various ways.  While in some cases there
-   may be good reason for specifying these protocols in terms of
-   specific encryption or checksum algorithms, we anticipate that in
-   many cases this will not be true, and more generic approaches
-   independent of particular algorithms will be desirable.  Rather than
-   having each protocol designer reinvent schemes for protecting data,
-   using multiple keys, etc, we have attempted to present in this
-   section a general framework that should be sufficient not only for
-   the Kerberos protocol itself but also for many preauthentication
-   systems and application protocols, while trying to avoid some of the
-   assumptions that can work their way into such protocol designs.
-
-   Some problematic assumptions we've seen (and sometimes made) include:
-   that a random bitstring is always valid as a key (not true for DES
-   keys with parity); that the basic block encryption chaining mode
-   provides no integrity checking, or can easily be separated from such
-   checking (not true for many modes in development that do both
-   simultaneously); that a checksum for a message always results in the
-   same value (not true if a confounder is incorporated); that an
-   initial vector is used (may not be true if a block cipher in CBC mode
-   is not in use).
-
-   Such assumptions, while they may hold for any given set of encryption
-   and checksum algorithms, may not be true of the next algorithms to be
-   defined, leaving the application protocol unable to make use of those
-   algorithms without updates to its specification.
-
-   The Kerberos protocol uses only the attributes and operations
-
-
-
-Raeburn                                                        [Page 30]
-
-INTERNET DRAFT                                             February 2003
-
-
-   described in sections 2 and 3.  Preauthentication systems and
-   application protocols making use of Kerberos are encouraged to use
-   them as well.  The specific key and string-to-key parameters should
-   generally be treated as opaque.  While the string-to-key parameters
-   are manipulated as an octet string, the representation for the
-   specific key structure is implementation-defined; it may not even be
-   a single object.
-
-   While we don't recommend it, some application protocols will
-   undoubtedly continue to use the key data directly, even if only in
-   some of the currently existing protocol specifications.  An
-   implementation intended to support general Kerberos applications may
-   therefore need to make the key data available, as well as the
-   attributes and operations described in sections 2 and 3.  [8]
-
-7. Assigned Numbers
-
-   The following encryption type numbers are already assigned or
-   reserved for use in Kerberos and related protocols.
-
-
-     encryption type                etype      section or comment
-     -----------------------------------------------------------------
-     des-cbc-crc                        1             5.2.3
-     des-cbc-md4                        2             5.2.2
-     des-cbc-md5                        3             5.2.1
-     [reserved]                         4
-     des3-cbc-md5                       5
-     [reserved]                         6
-     des3-cbc-sha1                      7
-     dsaWithSHA1-CmsOID                 9           (pkinit)
-     md5WithRSAEncryption-CmsOID       10           (pkinit)
-     sha1WithRSAEncryption-CmsOID      11           (pkinit)
-     rc2CBC-EnvOID                     12           (pkinit)
-     rsaEncryption-EnvOID              13   (pkinit from PKCS#1 v1.5)
-     rsaES-OAEP-ENV-OID                14   (pkinit from PKCS#1 v2.0)
-     des-ede3-cbc-Env-OID              15           (pkinit)
-     des3-cbc-sha1-kd                  16              5.3
-     aes128-cts-hmac-sha1-96           17          [KRB5-AES]
-     aes256-cts-hmac-sha1-96           18          [KRB5-AES]
-     rc4-hmac                          23          (Microsoft)
-     rc4-hmac-exp                      24          (Microsoft)
-     subkey-keymaterial                65     (opaque; PacketCable)
-
-
-   (The "des3-cbc-sha1" assignment is a deprecated version using no key
-   derivation.  It should not be confused with des3-cbc-sha1-kd.)
-
-
-
-
-Raeburn                                                        [Page 31]
-
-INTERNET DRAFT                                             February 2003
-
-
-   Several numbers have been reserved for use in encryption systems not
-   defined here.  Encryption type numbers have unfortunately been
-   overloaded on occasion in Kerberos-related protocols, so some of the
-   reserved numbers do not and will not correspond to encryption systems
-   fitting the profile presented here.
-
-   The following checksum type numbers are assigned or reserved.  As
-   with encryption type numbers, some overloading of checksum numbers
-   has occurred.
-
-
-   Checksum type              sumtype        checksum         section or
-                                value            size         reference
-   ----------------------------------------------------------------------
-   CRC32                            1               4           5.1.3
-   rsa-md4                          2              16           5.1.2
-   rsa-md4-des                      3              24           5.2.5
-   des-mac                          4              16           5.2.7
-   des-mac-k                        5               8           5.2.8
-   rsa-md4-des-k                    6              16           5.2.6
-   rsa-md5                          7              16           5.1.1
-   rsa-md5-des                      8              24           5.2.4
-   rsa-md5-des3                     9              24             ??
-   sha1 (unkeyed)                  10              20             ??
-   hmac-sha1-des3-kd               12              20            5.3
-   hmac-sha1-des3                  13              20             ??
-   sha1 (unkeyed)                  14              20             ??
-   hmac-sha1-96-aes128             15              20         [KRB5-AES]
-   hmac-sha1-96-aes256             16              20         [KRB5-AES]
-   [reserved]                  0x8003               ?         [GSS-KRB5]
-
-
-   Encryption and checksum type numbers are signed 32-bit values.  Zero
-   is invalid, and negative numbers are reserved for local use.  All
-   standardized values must be positive.
-
-8. Implementation Notes
-
-   The "interface" described here is the minimal information that must
-   be defined to make a cryptosystem useful within Kerberos in an
-   interoperable fashion.  Despite the functional notation used in some
-   places, it is not an attempt to define an API for cryptographic
-   functionality within Kerberos.  Actual implementations providing
-   clean APIs will probably find it useful to make additional
-   information available, which should be possible to derive from a
-   specification written to the framework given here.  For example, an
-   application designer may wish to determine the largest number of
-   bytes that can be encrypted without overflowing a certain size output
-
-
-
-Raeburn                                                        [Page 32]
-
-INTERNET DRAFT                                             February 2003
-
-
-   buffer, or conversely, the maximum number of bytes that might be
-   obtained by decrypting a ciphertext message of a given size.  (In
-   fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5]
-   will require some of these.)
-
-   The presence of a mechanism in this document should not be taken as
-   an indication that it must be implemented for compliance with any
-   specification; required mechanisms will be specified elsewhere.
-   Indeed, some of the mechanisms described here for backwards
-   compatibility are now considered rather weak for protecting critical
-   data.
-
-9. Security Considerations
-
-   Recent years have brought advancements in the ability to perform
-   large-scale attacks against DES, to such a degree that it is not
-   considered a strong encryption mechanism any longer; triple-DES is
-   generally preferred in its place, despite the poorer performance.
-   See [ESP-DES] for a summary of some of the potential attacks, and
-   [EFF-DES] for a detailed discussion of the implementation of
-   particular attack.  However, most Kerberos implementations still have
-   DES as their primary interoperable encryption type.
-
-   DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of
-   single-DES here avoids them. However, DES also has 48 'possibly-weak'
-   keys [Schneier96] (note that the tables in many editions of the
-   reference contains errors) which are not avoided.
-
-   DES weak keys are keys with the property that E1(E1(P)) = P (where E1
-   denotes encryption of a single block with key 1).  DES semi-weak keys
-   or "dual" keys are pairs of keys with the property that E1(P) =
-   D2(P), and thus E2(E1(P)) = P.  Because of the use of CBC mode and
-   leading random confounder, however, these properties are unlikely to
-   present a security problem.
-
-   The use of triple-DES in Kerberos makes no effort to avoid these
-   keys.  The nature of the weak keys is such that it is extremely
-   unlikely that they will weaken the triple-DES encryption -- only
-   slightly more likely than having the middle of the three sub-keys
-   match one of the other two, which effectively converts the encryption
-   to single-DES, which is another case we make no effort to avoid.
-
-   The true CRC-32 checksum is not collision-proof; an attacker could
-   use a probabilistic chosen-plaintext attack to generate a valid
-   message even if a confounder is used [SG92].  The use of collision-
-   proof checksums is of course recommended for environments where such
-   attacks represent a significant threat.  The "simplifications" (read:
-   bugs) introduced when CRC-32 was implemented for Kerberos cause
-
-
-
-Raeburn                                                        [Page 33]
-
-INTERNET DRAFT                                             February 2003
-
-
-   leading zeros to effectively be ignored, so messages differing only
-   in leading zero bits will have the same checksum.
-
-   [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm.
-   Unlike [IPSEC-HMAC], the triple-DES specification here does not use
-   the suggested truncation of the HMAC output.  As pointed out in
-   [IPSEC-HMAC], SHA-1 was not developed to be used as a keyed hash
-   function, which is a criterion of HMAC.  [HMAC-TEST] contains test
-   vectors for HMAC-SHA-1.
-
-   The mit_des_string_to_key function was originally constructed with
-   the assumption that all input would be ASCII; it ignores the top bit
-   of each input byte.  Folding with XOR is also not an especially good
-   mixing mechanism in terms of preserving randomness.
-
-   The n-fold function used in the string-to-key operation for des3-cbc-
-   hmac-sha1-kd was designed to cause each bit of input to contribute
-   equally to the output; it was not designed to maximize or equally
-   distribute randomness in the input, and there are conceivable cases
-   of partially structured input where randomness may be lost.  This
-   should only be an issue for highly structured passwords, however.
-
-   [RFC1851] discusses the relative strength of triple-DES encryption.
-   The relative slow speed of triple-DES encryption may also be an issue
-   for some applications.
-
-   This document, like the Kerberos protocol, completely ignores the
-   notion of limiting the amount of data a key may be used with to a
-   quantity based on the robustness of the algorithm or size of the key.
-   It is assumed that any defined algorithms and key sizes will be
-   strong enough to support very large amounts of data, or they will be
-   deprecated once significant attacks are known.
-
-   This document also places no bounds on the amount of data that can be
-   handled in various operations.  In order to avoid denial of service
-   attacks, implementations will probably want to restrict message sizes
-   at some higher level.
-
-10. IANA Considerations
-
-   None at present.  The management of encryption and checksum type
-   number assignments may be transferred to IANA at some future time.
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 34]
-
-INTERNET DRAFT                                             February 2003
-
-
-11. Acknowledgments
-
-   This document is an extension of the encryption specification
-   included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much
-   of the text of the background, concepts, and DES specifications are
-   drawn directly from that document.
-
-   The abstract framework presented in this document was put together by
-   Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn,
-   and Tom Yu, and the details were refined several times based on
-   comments from John Brezak and others.
-
-   Marc Horowitz wrote the original specification of triple-DES and key
-   derivation in a pair of Internet Drafts (under the names draft-
-   horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which
-   were later folded into a draft revision of [Kerb1510], from which
-   this document was later split off.
-
-   Tom Yu provided the text describing the modifications to the standard
-   CRC algorithm as Kerberos implementations actually use it.
-
-   Miroslav Jurisic provided information for one of the UTF-8 test cases
-   for the string-to-key functions.
-
-   Marcus Watts noticed some errors in earlier drafts, and pointed out
-   that the simplified profile could easily be modified to support
-   cipher text stealing modes.
-
-   Simon Josefsson contributed some clarifications to the DES "CBC
-   checksum", string-to-key and weak key descriptions, and some test
-   vectors.
-
-   Simon Josefsson, Louis LeVay and others also caught some errors in
-   earlier drafts.
-
-12. Editor's address
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-   raeburn@mit.edu
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 35]
-
-INTERNET DRAFT                                             February 2003
-
-
-13. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-A. Test vectors
-
-   This section provides test vectors for various functions defined or
-   described in this document.  For convenience, most inputs are ASCII
-   strings, though some UTF-8 samples are be provided for string-to-key
-   functions.  Keys and other binary data are specified as hexadecimal
-   strings.
-
-A.1. n-fold
-
-   The n-fold function is defined in section 4.1.  As noted there, the
-   sample vector in the original paper defining the algorithm appears to
-   be incorrect.  Here are some test cases provided by Marc Horowitz and
-   Simon Josefsson:
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 36]
-
-INTERNET DRAFT                                             February 2003
-
-
-      64-fold("012345") =
-      64-fold(303132333435) = be072631276b1955
-
-      56-fold("password") =
-      56-fold(70617373776f7264) = 78a07b6caf85fa
-
-      64-fold("Rough Consensus, and Running Code") =
-      64-fold(526f75676820436f6e73656e7375732c20616e642052756e
-              6e696e6720436f6465) = bb6ed30870b7f0e0
-
-      168-fold("password") =
-      168-fold(70617373776f7264) =
-               59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
-
-      192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY"
-      192-fold(4d41535341434856534554545320494e5354495456544520
-               4f4620544543484e4f4c4f4759) =
-               db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
-
-      168-fold("Q") =
-      168-fold(51) =
-               518a54a2 15a8452a 518a54a2 15a8452a
-               518a54a2 15
-
-      168-fold("ba") =
-      168-fold(6261) =
-               fb25d531 ae897449 9f52fd92 ea9857c4
-               ba24cf29 7e
-
-   Here are some additional values corresponding to folded values of the
-   string "kerberos"; the 64-bit form is used in the des3 string-to-key
-   (section 5.3.1).
-
-      64-fold("kerberos") =
-               6b657262 65726f73
-      128-fold("kerberos") =
-               6b657262 65726f73 7b9b5b2b 93132b93
-      168-fold("kerberos") =
-               8372c236 344e5f15 50cd0747 e15d62ca
-               7a5a3bce a4
-      256-fold("kerberos") =
-               6b657262 65726f73 7b9b5b2b 93132b93
-               5c9bdcda d95c9899 c4cae4de e6d6cae4
-
-   Note that the initial octets exactly match the input string when the
-   output length is a multiple of the input length.
-
-
-
-
-
-Raeburn                                                        [Page 37]
-
-INTERNET DRAFT                                             February 2003
-
-
-A.2. mit_des_string_to_key
-
-   The function mit_des_string_to_key is defined in section 5.2.  We
-   present here several test values, with some of the intermediate
-   results.  The fourth test demonstrates the use of UTF-8 with three
-   characters.  The last two tests are specifically constructed so as to
-   trigger the weak-key fixups for the intermediate key produced by fan-
-   folding; we have no test cases that cause such fixups for the final
-   key.
-
-
-   UTF-8 encodings used in test vector:
-   eszett     C3 9F            s-caron     C5 A1      c-acute     C4 87
-   g-clef     F0 9D 84 9E
-
-
-   Test vector:
-
-
-   salt:        "ATHENA.MIT.EDUraeburn"
-                              415448454e412e4d49542e4544557261656275726e
-   password:    "password"    70617373776f7264
-   fan-fold result:           c01e38688ac86c2e
-   intermediate key:          c11f38688ac86d2f
-   DES key:                   cbc22fae235298e3
-
-
-
-   salt:       "WHITEHOUSE.GOVdanny"   5748495445484f5553452e474f5664616e6e79
-   password:   "potatoe"               706f7461746f65
-   fan-fold result:                    a028944ee63c0416
-   intermediate key:                   a129944fe63d0416
-   DES key:                            df3d32a74fd92a01
-
-
-
-   salt:      "EXAMPLE.COMpianist"  4558414D504C452E434F4D7069616E697374
-   password:  g-clef                f09d849e
-   fan-fold result:                 3c4a262c18fab090
-   intermediate key:                3d4a262c19fbb091
-   DES key:                         4ffb26bab0cd9413
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 38]
-
-INTERNET DRAFT                                             February 2003
-
-
-   salt:        "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
-                          415448454e412e4d49542e4544554a757269c5a169c487
-   password:    eszett    c39f
-   fan-fold result:       b8f6c40e305afc9e
-   intermediate key:      b9f7c40e315bfd9e
-   DES key:               62c81a5232b5e69d
-
-
-
-   salt:       "AAAAAAAA"   4141414141414141
-   password:   "11119999"   3131313139393939
-   fan-fold result:         e0e0e0e0f0f0f0f0
-   intermediate key:        e0e0e0e0f1f1f101
-   DES key:                 984054d0f1a73e31
-
-
-
-   salt:       "FFFFAAAA"   4646464641414141
-   password:   "NNNN6666"   4e4e4e4e36363636
-   fan-fold result:         1e1e1e1e0e0e0e0e
-   intermediate key:        1f1f1f1f0e0e0efe
-   DES key:                 c4bf6b25adf7a4f8
-
-
-   This trace provided by Simon Josefsson shows the intermediate
-   processing stages of one of the test inputs:
-
-     string_to_key (des-cbc-md5, string, salt)
-            ;; string:
-            ;; `password' (length 8 bytes)
-            ;; 70 61 73 73 77 6f 72 64
-            ;; salt:
-            ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
-            ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
-            ;; 65 62 75 72 6e
-     des_string_to_key (string, salt)
-            ;; String:
-            ;; `password' (length 8 bytes)
-            ;; 70 61 73 73 77 6f 72 64
-            ;; Salt:
-            ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
-            ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
-            ;; 65 62 75 72 6e
-     odd = 1;
-     s = string | salt;
-
-
-
-
-
-
-Raeburn                                                        [Page 39]
-
-INTERNET DRAFT                                             February 2003
-
-
-     tempstring = 0; /* 56-bit string */
-     pad(s); /* with nulls to 8 byte boundary */
-            ;; s = pad(string|salt):
-            ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'
-            ;; (length 32 bytes)
-            ;; 70 61 73 73 77 6f 72 64  41 54 48 45 4e 41 2e 4d
-            ;; 49 54 2e 45 44 55 72 61  65 62 75 72 6e 00 00 00
-     for (8byteblock in s) {
-            ;; loop iteration 0
-            ;; 8byteblock:
-            ;; `password' (length 8 bytes)
-            ;; 70 61 73 73 77 6f 72 64
-            ;; 01110000 01100001 01110011  01110011 01110111 01101111
-            ;; 01110010 01100100
-     56bitstring = removeMSBits(8byteblock);
-            ;; 56bitstring:
-            ;; 1110000 1100001 1110011  1110011 1110111 1101111
-            ;; 1110010 1100100
-     if (odd == 0) reverse(56bitstring);    ;; odd=1
-     odd = ! odd
-     tempstring = tempstring XOR 56bitstring;
-            ;; tempstring
-            ;; 1110000 1100001 1110011  1110011 1110111 1101111
-            ;; 1110010 1100100
-
-     for (8byteblock in s) {
-            ;; loop iteration 1
-            ;; 8byteblock:
-            ;; `ATHENA.M' (length 8 bytes)
-            ;; 41 54 48 45 4e 41 2e 4d
-            ;; 01000001 01010100 01001000  01000101 01001110 01000001
-            ;; 00101110 01001101
-     56bitstring = removeMSBits(8byteblock);
-            ;; 56bitstring:
-            ;; 1000001 1010100 1001000  1000101 1001110 1000001
-            ;; 0101110 1001101
-     if (odd == 0) reverse(56bitstring);    ;; odd=0
-     reverse(56bitstring)
-            ;; 56bitstring after reverse
-            ;; 1011001 0111010 1000001  0111001 1010001 0001001
-            ;; 0010101 1000001
-     odd = ! odd
-     tempstring = tempstring XOR 56bitstring;
-            ;; tempstring
-            ;; 0101001 1011011 0110010  1001010 0100110 1100110
-            ;; 1100111 0100101
-
-
-
-
-
-Raeburn                                                        [Page 40]
-
-INTERNET DRAFT                                             February 2003
-
-
-     for (8byteblock in s) {
-            ;; loop iteration 2
-            ;; 8byteblock:
-            ;; `IT.EDUra' (length 8 bytes)
-            ;; 49 54 2e 45 44 55 72 61
-            ;; 01001001 01010100 00101110  01000101 01000100 01010101
-            ;; 01110010 01100001
-     56bitstring = removeMSBits(8byteblock);
-            ;; 56bitstring:
-            ;; 1001001 1010100 0101110  1000101 1000100 1010101
-            ;; 1110010 1100001
-     if (odd == 0) reverse(56bitstring);    ;; odd=1
-     odd = ! odd
-     tempstring = tempstring XOR 56bitstring;
-            ;; tempstring
-            ;; 1100000 0001111 0011100  0001111 1100010 0110011
-            ;; 0010101 1000100
-
-     for (8byteblock in s) {
-            ;; loop iteration 3
-            ;; 8byteblock:
-            ;; `eburn\x00\x00\x00' (length 8 bytes)
-            ;; 65 62 75 72 6e 00 00 00
-            ;; 01100101 01100010 01110101  01110010 01101110 00000000
-            ;; 00000000 00000000
-     56bitstring = removeMSBits(8byteblock);
-            ;; 56bitstring:
-            ;; 1100101 1100010 1110101  1110010 1101110 0000000
-            ;; 0000000 0000000
-     if (odd == 0) reverse(56bitstring);    ;; odd=0
-     reverse(56bitstring)
-            ;; 56bitstring after reverse
-            ;; 0000000 0000000 0000000  0111011 0100111 1010111
-            ;; 0100011 1010011
-     odd = ! odd
-     tempstring = tempstring XOR 56bitstring;
-            ;; tempstring
-            ;; 1100000 0001111 0011100  0110100 1000101 1100100
-            ;; 0110110 0010111
-
-     for (8byteblock in s) {
-     }
-            ;; for loop terminated
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 41]
-
-INTERNET DRAFT                                             February 2003
-
-
-     tempkey = key_correction(add_parity_bits(tempstring));
-            ;; tempkey
-            ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes)
-            ;; c1 1f 38 68 8a c8 6d 2f
-            ;; 11000001 00011111 00111000  01101000 10001010 11001000
-            ;; 01101101 00101111
-
-     key = key_correction(DES-CBC-check(s,tempkey));
-            ;; key
-            ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
-            ;; cb c2 2f ae 23 52 98 e3
-            ;; 11001011 11000010 00101111  10101110 00100011 01010010
-            ;; 10011000 11100011
-
-            ;; string_to_key key:
-            ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
-            ;; cb c2 2f ae 23 52 98 e3
-
-
-A.3. DES3 DR and DK
-
-   These tests show the derived-random and derived-key values for the
-   des3-hmac-sha1-kd encryption scheme, using the DR and DK functions
-   defined in section 5.3.1.  The input keys were randomly generated;
-   the usage values are from this specification.
-
-
-   key:                 dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
-   usage:               0000000155
-   DR:                  935079d14490a75c3093c4a6e8c3b049c71e6ee705
-   DK:                  925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
-
-   key:                 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
-   usage:               00000001aa
-   DR:                  9f58e5a047d894101c469845d67ae3c5249ed812f2
-   DK:                  9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
-
-   key:                 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
-   usage:               0000000155
-   DR:                  12fff90c773f956d13fc2ca0d0840349dbd39908eb
-   DK:                  13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
-
-   key:                 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
-   usage:               00000001aa
-   DR:                  f8debf05b097e7dc0603686aca35d91fd9a5516a70
-   DK:                  f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
-
-
-
-
-
-Raeburn                                                        [Page 42]
-
-INTERNET DRAFT                                             February 2003
-
-
-   key:                 d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
-   usage:               6b65726265726f73 ("kerberos")
-   DR:                  2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
-   DK:                  2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
-
-   key:                 c1081649ada74362e6a1459d01dfd30d67c2234c940704da
-   usage:               0000000155
-   DR:                  348056ec98fcc517171d2b4d7a9493af482d999175
-   DK:                  348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
-
-   key:                 5d154af238f46713155719d55e2f1f790dd661f279a7917c
-   usage:               00000001aa
-   DR:                  a8818bc367dadacbe9a6c84627fb60c294b01215e5
-   DK:                  a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
-
-   key:                 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
-   usage:               0000000155
-   DR:                  c813f88b3be2b2f75424ce9175fbc8483b88c8713a
-   DK:                  c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
-
-   key:                 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
-   usage:               00000001aa
-   DR:                  f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
-   DK:                  f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
-
-
-A.4. DES3string_to_key
-
-   These are the keys generated for some of the above input strings for
-   triple-DES with key derivation as defined in section 5.3.1.
-
-    salt:   "ATHENA.MIT.EDUraeburn"
-    passwd: "password"
-    key:    850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
-
-    salt:   "WHITEHOUSE.GOVdanny"
-    passwd: "potatoe"
-    key:    dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
-
-    salt:   "EXAMPLE.COMbuckaroo"
-    passwd: "penny"
-    key:    6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
-
-    salt:   "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
-    passwd: eszett
-    key:    16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
-
-
-
-
-
-Raeburn                                                        [Page 43]
-
-INTERNET DRAFT                                             February 2003
-
-
-    salt:   "EXAMPLE.COMpianist"
-    passwd: g-clef
-    key:    85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
-
-A.5. Modified CRC-32
-
-   Below are modified-CRC32 values for various ASCII and octet strings.
-   Only the printable ASCII characters are checksummed, no C-style
-   trailing zero-valued octet.  The 32-bit modified CRC and the sequence
-   of output bytes as used in Kerberos are shown.  (The octet values are
-   separated here to emphasize that they are octet values and not 32-bit
-   numbers, which will be the most convenient form for manipulation in
-   some implementations.  The bit and byte order used internally for
-   such a number is irrelevant; the octet sequence generated is what is
-   important.)
-
-
-    mod-crc-32("foo") =                                     33 bc 32 73
-    mod-crc-32("test0123456789") =                          d6 88 3e b8
-    mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") =   f7 80 41 e3
-    mod-crc-32(8000) =                                      4b 98 83 3b
-    mod-crc-32(0008) =                                      32 88 db 0e
-    mod-crc-32(0080) =                                      20 83 b8 ed
-    mod-crc-32(80) =                                        20 83 b8 ed
-    mod-crc-32(80000000) =                                  3b b6 59 ed
-    mod-crc-32(00000001) =                                  96 30 07 77
-
-
-B. Significant Changes from RFC 1510
-
-   The encryption and checksum mechanism profiles are new.  The old
-   specification defined a few operations for various mechanisms, but
-   didn't outline what should be required of new mechanisms in terms of
-   abstract properties, nor how to ensure that a mechanism specification
-   is complete enough for interoperability between implementations.  The
-   new profiles do differ from the old specification in a few ways:
-
-      Some message definitions in [Kerb1510] could be read as permitting
-      the initial vector to be specified by the application; the text
-      was too vague.  It is specifically not permitted in this
-      specification.  Some encryption algorithms may not use
-      initialization vectors, so relying on chosen, secret
-      initialization vectors for security is unwise.  Also, the
-      prepended confounder in the existing algorithms is roughly
-      equivalent to a per-message initialization vector that is revealed
-      in encrypted form.  However, carrying state across from one
-      encryption to another is explicitly permitted through the opaque
-      "cipher state" object.
-
-
-
-Raeburn                                                        [Page 44]
-
-INTERNET DRAFT                                             February 2003
-
-
-      The use of key derivation is new.
-
-      Several new methods are introduced, including generation of a key
-      in wire-protocol format from random input data.
-
-      The means for influencing the string-to-key algorithm are laid out
-      more clearly.
-
-   Triple-DES support is new.
-
-   The pseudo-random function is new.
-
-   The des-cbc-crc, DES string-to-key and CRC descriptions have been
-   updated to align them with existing implementations.
-
-   [Kerb1510] had no indication what character set or encoding might be
-   used for pass phrases and salts.
-
-   In [Kerb1510], key types, encryption algorithms and checksum
-   algorithms were only loosely associated, and the association was not
-   well described.  In this specification, key types and encryption
-   algorithms have a one-to-one correspondence, and associations between
-   encryption and checksum algorithms are described so that checksums
-   can be computed given negotiated keys, without requiring further
-   negotiation for checksum types.
-
-Notes
-
-   [1] While Message Authentication Code (MAC) or Message Integrity
-       Check (MIC) would be more appropriate terms for many of the
-       uses in this document, we continue to use the term "checksum"
-       for historical reasons.
-
-   [2] Extending CBC mode across messages would be one obvious
-       example of this chaining.  Another might be the use of
-       counter mode, with a counter randomly initialized and
-       attached to the ciphertext; a second message could continue
-       incrementing the counter when chaining the cipher state, thus
-       avoiding having to transmit another counter value.  However,
-       this chaining is only useful for uninterrupted, ordered
-       sequences of messages.
-
-   [3] In the case of Kerberos, the encrypted objects will generally
-       be ASN.1 DER encodings, which contain indications of their
-       length in the first few octets.
-
-   [4] As of the time of this writing, some new modes of operation
-       have been proposed, some of which may permit encryption and
-
-
-
-Raeburn                                                        [Page 45]
-
-INTERNET DRAFT                                             February 2003
-
-
-       integrity protection simultaneously.  After some of these
-       proposals have been subjected to adequate analysis, we may
-       wish to formulate a new simplified profile based on one of
-       them.
-
-   [5] It should be noted that the sample vector in Appendix B.2 of
-       the original paper appears to be incorrect.  Two independent
-       implementations from the specification (one in C by Marc
-       Horowitz, and another in Scheme by Bill Sommerfeld) agree on
-       a value different from that in [Blumenthal96].
-
-   [6] For example, in MIT's implementation of [Kerb1510], the rsa-
-       md5 unkeyed checksum of application data may be included in
-       an authenticator encrypted in a service's key; since rsa-md5
-       is believed to be collision-proof, even if the application
-       data is exposed to an attacker, it cannot be modified without
-       causing the checksum verification to fail.
-
-   [7] A variant of the key is used to limit the use of a key to a
-       particular function, separating the functions of generating a
-       checksum from other encryption performed using the session
-       key.  The constant 0xF0F0F0F0F0F0F0F0 was chosen because it
-       maintains key parity.  The properties of DES precluded the
-       use of the complement.  The same constant is used for similar
-       purpose in the Message Integrity Check in the Privacy
-       Enhanced Mail standard.
-
-   [8] Perhaps one of the more common reasons for directly
-       performing encryption is direct control over the negotiation
-       and to select a "sufficiently strong" encryption algorithm
-       (whatever that means in the context of a given application).
-       While Kerberos directly provides no facility for negotiating
-       encryption types between the application client and server,
-       there are other means for accomplishing similar goals.  For
-       example, requesting only "strong" session key types from the
-       KDC, and assuming that the type actually returned by the KDC
-       will be understood and supported by the application server.
-
-Normative References
-
-   [Bellare98]
-      Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway,
-      "Relations Among Notions of Security for Public-Key Encryption
-      Schemes".  Extended abstract published in Advances in Cryptology-
-      Crypto 98 Proceedings, Lecture Notes in Computer Science Vol.
-      1462, H. Krawcyzk ed., Springer-Verlag, 1998.
-
-
-
-
-
-Raeburn                                                        [Page 46]
-
-INTERNET DRAFT                                             February 2003
-
-
-   [Blumenthal96]
-      Blumenthal, U., and S. Bellovin, "A Better Key Schedule for DES-
-      Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996.
-   [CRC]
-      International Organization for Standardization, "ISO Information
-      Processing Systems - Data Communication - High-Level Data Link
-      Control Procedure - Frame Structure," IS 3309, 3rd Edition,
-      October 1984.
-   [DES77]
-      National Bureau of Standards, U.S. Department of Commerce, "Data
-      Encryption Standard," Federal Information Processing Standards
-      Publication 46, Washington, DC, 1977.
-   [DESI81]
-      National Bureau of Standards, U.S. Department of Commerce,
-      "Guidelines for implementing and using NBS Data Encryption
-      Standard," Federal Information Processing Standards Publication
-      74, Washington, DC, 1981.
-   [DESM80]
-      National Bureau of Standards, U.S. Department of Commerce, "DES
-      Modes of Operation," Federal Information Processing Standards
-      Publication 81, Springfield, VA, December 1980.
-   [Dolev91]
-      Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography",
-      Proceedings of the 23rd Annual Symposium on Theory of Computing,
-      ACM, 1991.
-   [HMAC]
-      Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
-      for Message Authentication", RFC 2104, February 1997.
-   [KRB5-AES]
-      Raeburn, K., "AES Encyrption for Kerberos 5", RFC XXXX, Xxxxxxxx
-      2003.
-   [MD4-92]
-      Rivest, R., "The MD4 Message Digest Algorithm," RFC 1320, MIT
-      Laboratory for Computer Science, April 1992.
-   [MD5-92]
-      Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321, MIT
-      Laboratory for Computer Science, April 1992.
-   [RFC2026]
-      Bradner, S., "The Internet Standards Process -- Revisions 3," RFC
-      2026, October 1996.
-   [SG92]
-      Stubblebine, S., and V. D. Gligor, "On Message Integrity in
-      Cryptographic Protocols," in Proceedings of the IEEE Symposium on
-      Research in Security and Privacy, Oakland, California, May 1992.
-
-
-
-
-
-
-
-Raeburn                                                        [Page 47]
-
-INTERNET DRAFT                                             February 2003
-
-
-Informative References
-
-   [EFF-DES]
-      Electronic Frontier Foundation, "Cracking DES: Secrets of
-      Encryption Research, Wiretap Politics, and Chip Design", O'Reilly
-      & Associates, Inc., May 1998.
-   [ESP-DES]
-      Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm
-      With Explicit IV", RFC 2405, November 1998.
-   [GSS-KRB5]
-      Linn, J., "The Kerberos Version 5 GSS-API Mechanism," RFC 1964,
-      June 1996.
-   [HMAC-TEST]
-      Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",
-      RFC 2202, September 1997.
-   [IPSEC-HMAC]
-      Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and
-      AH", RFC 2404, November 1998.
-   [Kerb]
-      Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K.
-      Raeburn, "The Kerberos Network Authentication Service (V5)",
-      draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22,
-      2002.  Work in progress.
-   [Kerb1510]
-      Kohl, J., and C. Neuman, "The Kerberos Network Authentication
-      Service (V5)", RFC 1510, September 1993.
-   [RC5]
-      Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
-      RC5-CTS Algorithms", RFC 2040, October 1996.
-   [Schneier96]
-      Schneier, B., "Applied Cryptography Second Edition", John Wiley &
-      Sons, New York, NY, 1996.  ISBN 0-471-12845-7.
-
-Notes to RFC Editor
-
-   Before publication of this document as an RFC, the following changes
-   are needed:
-
-   Change the reference "[KRB5-AES]" in Normative References to indicate
-   the AES draft (draft-raeburn-krb-rijndael-krb-XX) that should be
-   advancing to RFC at the same time.  The RFC number and publication
-   date are needed.
-
-   If draft-ietf-krb-wg-kerberos-clarifications advances to RFC at the
-   same time as this document, change the information for [Kerb] in the
-   Informative References section as well.
-
-   Delete this section.
-
-
-
-Raeburn                                                        [Page 48]
diff --git a/doc/standardisation/draft-ietf-krb-wg-crypto-06.txt b/doc/standardisation/draft-ietf-krb-wg-crypto-06.txt
deleted file mode 100644
index 7fd04fe8b..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-crypto-06.txt
+++ /dev/null
@@ -1,2802 +0,0 @@
-
-
-
-
-
-
-
-
-
-INTERNET DRAFT                                                K. Raeburn
-Kerberos Working Group                                               MIT
-Document: draft-ietf-krb-wg-crypto-06.txt               October 27, 2003
-                                                  expires April 27, 2004
-
-                 Encryption and Checksum Specifications
-                             for Kerberos 5
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026 [RFC2026].  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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.html.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-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.  Several mechanisms
-   are also defined in this document.  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".
-
-   Comments should be sent to the editor, or to the IETF Kerberos
-   working group (ietf-krb-wg@anl.gov).
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 1]
-
-INTERNET DRAFT                                              October 2003
-
-
-                           Table of Contents
-
-
-Status of this Memo  . . . . . . . . . . . . . . . . . . . . . . . .   1
-Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
-Table of Contents  . . . . . . . . . . . . . . . . . . . . . . . . .   2
-1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
-2. Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
-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 . . . . . . . . . . . . . . . . . . .  11
-5.2. Simplified profile parameters . . . . . . . . . . . . . . . . .  13
-5.3. Cryptosystem profile based on simplified profile  . . . . . . .  14
-5.4. Checksum profiles based on simplified profile . . . . . . . . .  16
-6. Profiles for Kerberos encryption and checksum algorithms  . . . .  16
-6.1. Unkeyed checksums . . . . . . . . . . . . . . . . . . . . . . .  16
-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
-8. Assigned Numbers  . . . . . . . . . . . . . . . . . . . . . . . .  31
-9. Implementation Notes  . . . . . . . . . . . . . . . . . . . . . .  33
-10. Security Considerations  . . . . . . . . . . . . . . . . . . . .  33
-11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . .  35
-12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . .  36
-A. Test vectors  . . . . . . . . . . . . . . . . . . . . . . . . . .  37
-A.1. n-fold  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  37
-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 . . . . . . . . . . . . . . . . . . . . . . . .  45
-B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . .  45
-Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  46
-Normative References . . . . . . . . . . . . . . . . . . . . . . . .  47
-Informative References . . . . . . . . . . . . . . . . . . . . . . .  49
-Editor's address . . . . . . . . . . . . . . . . . . . . . . . . . .  49
-Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . .  50
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 2]
-
-INTERNET DRAFT                                              October 2003
-
-
-1. Introduction
-
-   The Kerberos protocols 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 any specific encryption
-   algorithm be used, as long as certain operations are available in the
-   algorithm that is used.
-
-   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.  Test vectors for several
-   functions are given in appendix A.
-
-2. Concepts
-
-   Both encryption and checksum mechanisms are defined in terms of
-   profiles, detailed in later sections.  Each 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.  (Integrity checking may be
-   achieved by incorporating a checksum, if the encryption mode does not
-   provide an integrity check itself.)  It must also provide non-
-   malleability [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 knowledge of 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.  It should be infeasible
-   to find two plaintexts which have the same checksum.  It is NOT
-   required that an eavesdropper be unable to determine if two checksums
-   are for the same message; it is assumed that the messages themselves
-   will be visible to any such eavesdropper.
-
-   Due to advances in cryptography, it is considered unwise by some
-   cryptographers to use the same key for multiple purposes.  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.
-
-
-
-
-Raeburn                                                         [Page 3]
-
-INTERNET DRAFT                                              October 2003
-
-
-   We do this by enumerating the different uses of keys within Kerberos,
-   and making the "usage number" an input to the encryption or checksum
-   mechanisms; this enumeration is outside the scope of this document.
-   Later sections of this document 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" to be used for a particular instance of encryption or
-   checksum operations.  It is expected but not required that the
-   specific key will 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 8-bit
-   bytes.  Environments with other byte sizes will have to emulate this
-   behavior in order to get correct results.
-
-   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 what 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 specific values that are not valid or desirable
-      for use; such values should be avoid by all key generation
-      routines.
-
-
-
-Raeburn                                                         [Page 4]
-
-INTERNET DRAFT                                              October 2003
-
-
-   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 has been decided upon, the corresponding checksum
-      mechanism can simply 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 generation
-      of keys that significantly compromise the confidentiality of
-      encrypted data, if the cryptosystem has such.  Entropy from each
-      source should be preserved as much as possible.  Many of the
-      inputs, while 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 timestamps); 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 normally the
-         principal's pass phrase, but is in general 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.  While the strings provided will use UTF-8
-         encoding, no specific version of Unicode should be assumed; all
-         valid UTF-8 strings should be allowed.
-
-         The third argument, the octet string, may be used to pass
-         mechanism-specific parameters in to this function.  Since doing
-
-
-
-Raeburn                                                         [Page 5]
-
-INTERNET DRAFT                                              October 2003
-
-
-         so implies knowledge of the specific encryption system, it is
-         intended that generating non-default parameter values be an
-         uncommon operation, and that normal Kerberos applications 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
-         the user's key in another realm, 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.  It may be assumed that all the bits of the
-         input string are 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; the usage values must be assumed to be known
-         to an attacker.  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
-      the user's password.  It may be desirable to construct the
-      encoding such that values weakening the resulting key unacceptably
-      cannot be encoded, if practical.
-
-      Tighter bounds might be permitted by local security policy, or to
-      avoid excess resource consumption; if so, recommended defaults for
-      those bounds should be given in the specification.  The
-      description should also outline possible weaknesses that may be
-      caused by not applying bounds checks or other validation 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 is to be used when the application protocol (Kerberos or
-      otherwise) does not explicitly set the parameter value.  As
-
-
-
-Raeburn                                                         [Page 6]
-
-INTERNET DRAFT                                              October 2003
-
-
-      indicated above, this parameter block should be treated as an
-      opaque object in most cases.
-
-   cipher state
-      This describes any information that can be carried over from one
-      encryption or decryption operation to the next, for use in
-      conjunction 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 as
-      to require that messages be decrypted in the same order they were
-      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.
-
-      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 the setting of the initial vector.  This
-      new specification does not permit application control of the
-      cipher state (beyond "initialize" and "carry over from previous
-      encryption"), since the form and content of the initial cipher
-
-
-
-Raeburn                                                         [Page 7]
-
-INTERNET DRAFT                                              October 2003
-
-
-      state can vary between encryption systems, and may not always be a
-      single block of random data.
-
-      New Kerberos application protocols should not assume that they can
-      control 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 (as DES in CBC
-      mode does not do), then some form of MAC or checksum must be
-      included that can be verified by the receiver.  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 not only
-      indicate the precise contents of the output octet string, but also
-      the output cipher state.  The application protocol may carry
-      forward the output cipher state from one encryption with a given
-      specific key to another; the effect of this "chaining" must be
-      defined.  [2]
-
-      Assuming correctly-produced values for the specific key and cipher
-      state, no input octet string may result in an error indication.
-
-   decrypt (specific-key, state, octet string)->(state, octet string)
-      This function takes the specific key, cipher state, and ciphertext
-      as inputs, and verifies the integrity of the supplied ciphertext.
-      If the ciphertext's integrity is intact, this function produces
-      the plaintext and a new cipher state as outputs; otherwise, an
-      error indication must be returned, and the data discarded.
-
-      The result of the decryption may be longer than the original
-      plaintext, for example if the encryption mode adds padding to
-      reach a multiple of a block size.  If this is the case, any extra
-      octets must be after the decoded plaintext.  An application
-      protocol which needs to know the exact length of the message must
-      encode a length or recognizable "end of message" marker within the
-      plaintext.  [3]
-
-      As with the encryption function, a correct specification for this
-
-
-
-Raeburn                                                         [Page 8]
-
-INTERNET DRAFT                                              October 2003
-
-
-      function must indicate not only the contents of the output octet
-      string, but also the resulting cipher state.
-
-   pseudo-random (protocol-key, octet-string)->(octet-string)
-      This pseudo-random function should generate an octet string of
-      some size that independent of the octet string input.  The PRF
-      output string should be suitable for use in key generation, even
-      if the octet string input is public.  It should not reveal the
-      input key, even if the output is made public.
-
-   These operations and attributes are all that is required to support
-   Kerberos and various proposed preauthentication schemes.
-
-   For convenience of certain application protocols that may wish to use
-   the encryption profile, we add the constraint that, for any given
-   plaintext input size, there must be a message size between that given
-   size and that size plus 65535 such that the length of such that the
-   decrypted version of the ciphertext for any message of that size will
-   never have extra octets added at the end.
-
-   Expressed mathematically, for every message length L1, there exists a
-   message size L2 such that:
-
-     L2 >= L1
-     L2 < L1 + 65536
-     for every message M with |M| = L2, decrypt(encrypt(M)) = M
-
-   A document defining a new encryption type should also describe known
-   weaknesses or attacks, so that its security may be fairly assessed,
-   and should include test vectors or other validation procedures for
-   the operations defined.  Specific references to information readily
-   available elsewhere are sufficient.
-
-4. Checksum algorithm profile
-
-   A checksum mechanism profile must define the following attributes and
-   operations:
-
-   associated encryption algorithm(s)
-      This indicates the types of encryption keys this checksum
-      mechanism can be used with.
-
-      A keyed checksum mechanism may have more than one associated
-      encryption algorithm if they share the same wire key format,
-      string-to-key function, and key derivation function. (This
-      combination means that, for example, a checksum type, key usage
-      value and password are adequate to get the specific key used to
-      compute a checksum.)
-
-
-
-Raeburn                                                         [Page 9]
-
-INTERNET DRAFT                                              October 2003
-
-
-      An unkeyed checksum mechanism can be used in conjunction with any
-      encryption type, since the key is ignored, but its use must be
-      limited to cases where the checksum itself is protected, to avoid
-      trivial attacks.
-
-   get_mic function
-      This function generates a MIC token for a given specific key (see
-      section 3), and message (represented as an octet string), that may
-      be used to verify the integrity of the associated message.  This
-      function is not required to return the same deterministic result
-      on every use; it need only generate a token that the verify_mic
-      routine can check.
-
-      The output of this function will also dictate the size of the
-      checksum.  It must be no larger than 65535 octets.
-
-   verify_mic function
-      Given a specific key, message, and MIC token, this function
-      ascertains whether the message integrity has been compromised.
-      For a deterministic get_mic routine, the corresponding verify_mic
-      may simply generate another checksum and compare them.
-
-   The get_mic and verify_mic operations must be able to handle inputs
-   of arbitrary length; if any padding is needed, the padding scheme
-   must be specified as part of these functions.
-
-   These operations and attributes are all that should be required to
-   support Kerberos and various proposed preauthentication schemes.
-
-   As with encryption mechanism definition documents, documents defining
-   new checksum mechanisms should indicate validation processes and
-   known weaknesses.
-
-5. Simplified profile for CBC ciphers with key derivation
-
-   The profile outlines in sections 3 and 4 describes a large number of
-   operations that must be defined for encryption and checksum
-   algorithms to be used with Kerberos.  We describe here a simpler
-   profile from which both encryption and checksum mechanism definitions
-   can be generated, filling in uses of key derivation in appropriate
-   places, providing integrity protection, and defining multiple
-   operations for the cryptosystem profile based on a smaller set of
-   operations given in the simplified profile.  Not all of the existing
-   cryptosystems for Kerberos fit into this simplified profile, but we
-   recommend that future cryptosystems use it or something based on it.
-   [4]
-
-   Not all of the operations in the complete profiles are defined
-
-
-
-Raeburn                                                        [Page 10]
-
-INTERNET DRAFT                                              October 2003
-
-
-   through this mechanism; several must still be defined for each new
-   algorithm pair.
-
-5.1. A key derivation function
-
-   Rather than define some scheme by which a "protocol key" is composed
-   of a large number of encryption keys, we use keys derived from a base
-   key to perform cryptographic operations.  The base key must be used
-   only for generating the derived keys, and this derivation must be
-   non-invertible and entropy-preserving.  Given these restrictions,
-   compromise of one derived key does not compromise the other subkeys.
-   Attack of the base key is limited, since it is only used for
-   derivation, and is not exposed to any user data.
-
-   Since the derived key has as much entropy as the base keys (if the
-   cryptosystem is good), password-derived keys have the full benefit of
-   all the entropy in the password.
-
-   To generate a derived key from a base key, we generate a pseudorandom
-   octet string, using an algorithm DR described below, and generate a
-   key from that octet string using a function dependent on the
-   encryption algorithm; the input length needed for that function,
-   which is also dependent on the encryption algorithm, dictates the
-   length of the string to be generated by the DR algorithm (the value
-   "k" below).  These procedures are based on the key derivation in
-   [Blumenthal96].
-
-      Derived Key = DK(Base Key, Well-Known Constant)
-
-      DK(Key, Constant) = random-to-key(DR(Key, Constant))
-
-      DR(Key, Constant) = k-truncate(E(Key, Constant,
-                                       initial-cipher-state))
-
-   Here DR is the random-octet generation function described below, and
-   DK is the key-derivation function produced from it.  In this
-   construction, E(Key, Plaintext, CipherState) is a cipher, Constant is
-   a well-known constant determined by the specific usage of this
-   function, and k-truncate truncates its argument by taking the first k
-   bits.  Here, k is the key generation seed length needed for the
-   encryption system.
-
-   The output of the DR function is a string of bits; the actual key is
-   produced by applying the cryptosystem's random-to-key operation on
-   this bitstring.
-
-   If the Constant is smaller than the cipher block size of E, then it
-   must be expanded with n-fold() so it can be encrypted.  If the output
-
-
-
-Raeburn                                                        [Page 11]
-
-INTERNET DRAFT                                              October 2003
-
-
-   of E is shorter than k bits it is fed back into the encryption as
-   many times as necessary.  The construct is as follows (where |
-   indicates concatentation):
-
-      K1 = E(Key, n-fold(Constant), initial-cipher-state)
-      K2 = E(Key, K1, initial-cipher-state)
-      K3 = E(Key, K2, initial-cipher-state)
-      K4 = ...
-
-      DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
-
-   n-fold is an algorithm which takes m input bits and ``stretches''
-   them to form n output bits with equal contribution from each input
-   bit to the output, as described in [Blumenthal96]:
-
-      We first define a primitive called n-folding, which takes a
-      variable-length input block and produces a fixed-length output
-      sequence.  The intent is to give each input bit approximately
-      equal weight in determining the value of each output bit.  Note
-      that whenever we need to treat a string of octets as a number, the
-      assumed representation is Big-Endian -- Most Significant Byte
-      first.
-
-      To n-fold a number X, replicate the input value to a length that
-      is the least common multiple of n and the length of X.  Before
-      each repetition, the input is rotated to the right by 13 bit
-      positions.  The successive n-bit chunks are added together using
-      1's-complement addition (that is, with end-around carry) to yield
-      a n-bit result....
-
-
-   Test vectors for n-fold are supplied in Appendix A.  [5]
-
-   In this section, n-fold is always used to produce c bits of output,
-   where c is the cipher block size of E.
-
-   The size of the Constant must not be larger than c, because reducing
-   the length of the Constant by n-folding can cause collisions.
-
-   If the size of the Constant is smaller than c, then the Constant must
-   be n-folded to length c.  This string is used as input to E.  If the
-   block size of E is less than the random-to-key input size, then the
-   output from E is taken as input to a second invocation of E.  This
-   process is repeated until the number of bits accumulated is greater
-   than or equal to the random-to-key input size.  When enough bits have
-   been computed, the first k are taken as the random data used to
-   create the key with the algorithm-dependent random-to-key function.
-
-
-
-
-Raeburn                                                        [Page 12]
-
-INTERNET DRAFT                                              October 2003
-
-
-   Since the derived key is the result of one or more encryptions in the
-   base key, deriving the base key from the derived key is equivalent to
-   determining the key from a very small number of plaintext/ciphertext
-   pairs.  Thus, this construction is as strong as the cryptosystem
-   itself.
-
-5.2. Simplified profile parameters
-
-   These are the operations and attributes that must be defined:
-
-   protocol key format
-   string-to-key function
-   default string-to-key parameters
-   key-generation seed length, k
-   random-to-key function
-      As above for the normal encryption mechanism profile.
-
-   unkeyed hash algorithm, H
-      This should be a collision-resistant hash algorithm with fixed-
-      size output, suitable for use in an HMAC [HMAC].  It must support
-      inputs of arbitrary length.  Its output must be at least the
-      message block size (below).
-
-   HMAC output size, h
-      This indicates the size of the leading substring output by the
-      HMAC function that should be used in transmitted messages.  It
-      should be at least half the output size of the hash function H,
-      and at least 80 bits; it need not match the output size.
-
-   message block size, m
-      This is the size of the smallest units the cipher can handle in
-      the mode in which it is being used.  Messages will be padded to a
-      multiple of this size.  If a block cipher is used in a mode that
-      can handle messages that are not multiples of the cipher block
-      size, such as CBC mode with cipher text stealing (CTS, see [RC5]),
-      this value would be one octet.  For traditional CBC mode with
-      padding, it will be the underlying cipher's block size.
-
-      This value must be a multiple of 8 bits (one octet).
-
-   encryption/decryption functions, E and D
-      These are basic encryption and decryption functions for messages
-      of sizes that are multiples of the message block size.  No
-      integrity checking or confounder should be included here.  These
-      functions take as input the IV or similar data, a protocol-format
-      key, and a octet string, returning a new IV and octet string.
-
-      The encryption function is not required to use CBC mode, but is
-
-
-
-Raeburn                                                        [Page 13]
-
-INTERNET DRAFT                                              October 2003
-
-
-      assumed to be using something with similar properties.  In
-      particular, prepending a cipher-block-size confounder to the
-      plaintext should alter the entire ciphertext (comparable to
-      choosing and including a random initial vector for CBC mode).
-
-      The result of encrypting one cipher block (of size c, above) must
-      be deterministic, for the random octet generation function DR in
-      the previous section to work.  For best security, it should also
-      be no larger than c.
-
-   cipher block size, c
-      This is the block size of the block cipher underlying the
-      encryption and decryption functions indicated above, used for key
-      derivation and for the size of the message confounder and initial
-      vector.  (If a block cipher is not in use, some comparable
-      parameter should be determined.)  It must be at least 5 octets.
-
-      This is not actually an independent parameter; rather, it is a
-      property of the functions E and D.  It is listed here to clarify
-      the distinction between it and the message block size, m.
-
-   While there are still a number of properties to specify, they are
-   fewer and simpler than in the full profile.
-
-5.3. Cryptosystem profile based on simplified profile
-
-   The above key derivation function is used to produce three
-   intermediate keys.  One is used for computing checksums of
-   unencrypted data.  The other two are used for encrypting and
-   checksumming plaintext to be sent encrypted.
-
-   The ciphertext output is the concatenation of the output of the basic
-   encryption function E and a (possibly truncated) HMAC using the
-   specified hash function H, both applied to the plaintext with a
-   random confounder prefix and sufficient padding to bring it to a
-   multiple of the message block size.  When the HMAC is computed, the
-   key is used in the protocol key form.
-
-   Decryption is performed by removing the (partial) HMAC, decrypting
-   the remainder, and verifying the HMAC.  The cipher state is an
-   initial vector, initialized to zero.
-
-   The substring notation "[1..h]" in the following table should be read
-   as using 1-based indexing; leading substrings are used.
-
-
-
-
-
-
-
-Raeburn                                                        [Page 14]
-
-INTERNET DRAFT                                              October 2003
-
-
-                   cryptosystem from simplified profile
-----------------------------------------------------------------------------
-protocol key format       As given.
-
-specific key structure    Three protocol-format keys: { Kc, Ke, Ki }.
-
-key-generation seed       As given.
-length
-
-required checksum         As defined below in section 5.4.
-mechanism
-
-cipher state              initial vector (usually of length c)
-
-initial cipher state      all bits zero
-
-encryption function       conf = random string of length c
-                          pad = shortest string to bring confounder
-                                and plaintext to a length that's a
-                                multiple of m
-                          (C1, newIV) = E(Ke, conf | plaintext | pad,
-                                          oldstate.ivec)
-                          H1 = HMAC(Ki, conf | plaintext | pad)
-                          ciphertext =  C1 | H1[1..h]
-                          newstate.ivec = newIV
-
-decryption function       (C1,H1) = ciphertext
-                          (P1, newIV) = D(Ke, C1, oldstate.ivec)
-                          if (H1 != HMAC(Ki, P1)[1..h])
-                             report error
-                          newstate.ivec = newIV
-
-default string-to-key     As given.
-params
-
-pseudo-random function    tmp1 = H(octet-string)
-                          tmp2 = truncate tmp1 to multiple of m
-                          PRF = E(protocol-key, tmp2, initial-cipher-state)
-
-key generation functions:
-
-string-to-key function    As given.
-
-random-to-key function    As given.
-
-
-
-
-
-
-
-Raeburn                                                        [Page 15]
-
-INTERNET DRAFT                                              October 2003
-
-
-                   cryptosystem from simplified profile
-----------------------------------------------------------------------------
-key-derivation function   The "well-known constant" used for the DK
-                          function is the key usage number, expressed as
-                          four octets in big-endian order, followed by one
-                          octet indicated below.
-
-                          Kc = DK(base-key, usage | 0x99);
-                          Ke = DK(base-key, usage | 0xAA);
-                          Ki = DK(base-key, usage | 0x55);
-
-
-5.4. Checksum profiles based on simplified profile
-
-   When an encryption system is defined using the simplified profile
-   given in section 5.2, a checksum algorithm may be defined for it as
-   follows:
-
-
-                checksum mechanism from simplified profile
-             --------------------------------------------------
-             associated cryptosystem   as defined above
-
-             get_mic                   HMAC(Kc, message)[1..h]
-
-             verify_mic                get_mic and compare
-
-   The HMAC function and key Kc are as described in section 5.3.
-
-6. Profiles for Kerberos encryption and checksum algorithms
-
-   These profiles describe the encryption and checksum systems defined
-   for Kerberos.  The astute reader will notice that some of them do not
-   fulfull all of the requirements outlined in previous sections.  These
-   systems are defined for backward compatibility; newer implementations
-   should (whenever possible) attempt to make use of encryption systems
-   which satisfy all of the profile requirements.
-
-   The full list of current encryption and checksum type number
-   assignments, including values currently reserved but not defined in
-   this document, is given in section 8.
-
-6.1. Unkeyed checksums
-
-   These checksum types use no encryption keys, and thus can be used in
-   combination with any encryption type, but may only be used with
-   caution, in limited circumstances where the lack of a key does not
-   provide a window for an attack, preferably as part of an encrypted
-
-
-
-Raeburn                                                        [Page 16]
-
-INTERNET DRAFT                                              October 2003
-
-
-   message.  [6] Keyed checksum algorithms are recommended.
-
-6.1.1. The RSA MD5 Checksum
-
-   The RSA-MD5 checksum calculates a checksum using the RSA MD5
-   algorithm [MD5-92].  The algorithm takes as input an input message of
-   arbitrary length and produces as output a 128-bit (16 octet)
-   checksum.  RSA-MD5 is believed to be collision-proof.
-
-                                  rsa-md5
-               ----------------------------------------------
-               associated cryptosystem   any
-
-               get_mic                   rsa-md5(msg)
-
-               verify_mic                get_mic and compare
-
-   The rsa-md5 checksum algorithm is assigned a checksum type number of
-   seven (7).
-
-6.1.2. The RSA MD4 Checksum
-
-   The RSA-MD4 checksum calculates a checksum using the RSA MD4
-   algorithm [MD4-92].  The algorithm takes as input an input message of
-   arbitrary length and produces as output a 128-bit (16 octet)
-   checksum.  RSA-MD4 is believed to be collision-proof.
-
-
-                                  rsa-md4
-               ----------------------------------------------
-               associated cryptosystem   any
-
-               get_mic                   md4(msg)
-
-               verify_mic                get_mic and compare
-
-
-   The rsa-md4 checksum algorithm is assigned a checksum type number of
-   two (2).
-
-6.1.3. CRC-32 Checksum
-
-   This CRC-32 checksum calculates a checksum based on a cyclic
-   redundancy check as described in ISO 3309 [CRC], modified as
-   described below.  The resulting checksum is four (4) octets in
-   length.  The CRC-32 is neither keyed nor collision-proof; thus, the
-   use of this checksum is not recommended.  An attacker using a
-   probabilistic chosen-plaintext attack as described in [SG92] might be
-
-
-
-Raeburn                                                        [Page 17]
-
-INTERNET DRAFT                                              October 2003
-
-
-   able to generate an alternative message that satisfies the checksum.
-
-   The CRC-32 checksum used in the des-cbc-crc encryption mode is
-   identical to the 32-bit FCS described in ISO 3309 with two
-   exceptions: the sum with the all-ones polynomial times x**k is
-   omitted, and the final remainder is not ones-complemented.  ISO 3309
-   describes the FCS in terms of bits, while this document describes the
-   Kerberos protocol in terms of octets.  To disambiguate the ISO 3309
-   definition for the purpose of computing the CRC-32 in the des-cbc-crc
-   encryption mode, the ordering of bits in each octet shall be assumed
-   to be LSB-first.  Given this assumed ordering of bits within an
-   octet, the mapping of bits to polynomial coefficients shall be
-   identical to that specified in ISO 3309.
-
-   Test values for this modified CRC function are included in appendix
-   A.5.
-
-
-                                   crc32
-               ----------------------------------------------
-               associated cryptosystem   any
-
-               get_mic                   crc32(msg)
-
-               verify_mic                get_mic and compare
-
-
-   The crc32 checksum algorithm is assigned a checksum type number of
-   one (1).
-
-6.2. DES-based encryption and checksum types
-
-   These encryption systems encrypt information under the Data
-   Encryption Standard [DES77] using the cipher block chaining mode
-   [DESM80].  A checksum is computed as described below and placed in
-   the cksum field.  DES blocks are 8 bytes.  As a result, the data to
-   be encrypted (the concatenation of confounder, checksum, and message)
-   must be padded to an 8 byte boundary before encryption.  The values
-   of the padding bytes are unspecified.
-
-   Plaintext and DES ciphertext are encoded as blocks of 8 octets which
-   are concatenated to make the 64-bit inputs for the DES algorithms.
-   The first octet supplies the 8 most significant bits (with the
-   octet's MSB used as the DES input block's MSB, etc.), the second
-   octet the next 8 bits, ..., and the eighth octet supplies the 8 least
-   significant bits.
-
-   Encryption under DES using cipher block chaining requires an
-
-
-
-Raeburn                                                        [Page 18]
-
-INTERNET DRAFT                                              October 2003
-
-
-   additional input in the form of an initialization vector; this vector
-   is specified for each encryption system, below.
-
-   The DES specifications [DESI81] identify four 'weak' and twelve
-   'semi-weak' keys; those keys shall not be used for encrypting
-   messages for use in Kerberos.  The "variant keys" generated for the
-   RSA-MD5-DES, RSA-MD4-DES and DES-MAC checksum types by an exclusive-
-   or of a DES key with a hexadecimal constant are not checked for this
-   property.
-
-   A DES key is 8 octets of data.  This consists of 56 bits of actual
-   key data, and 8 parity bits, one per octet.  The key is encoded as a
-   series of 8 octets written in MSB-first order.  The bits within the
-   key are also encoded in MSB order.  For example, if the encryption
-   key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8)
-   where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8
-   are the parity bits, the first octet of the key would be
-   B1,B2,...,B7,P1 (with B1 as the most significant bit).  See the
-   [DESM80] introduction for reference.
-
-   Encryption data format
-
-   The format for the data to be encrypted includes a one-block
-   confounder, a checksum, the encoded plaintext, and any necessary
-   padding, as described in the following diagram.  The msg-seq field
-   contains the part of the protocol message which is to be encrypted.
-
-                  +-----------+----------+---------+-----+
-                  |confounder | checksum | msg-seq | pad |
-                  +-----------+----------+---------+-----+
-
-   One generates a random confounder of one block, placing it in
-   'confounder'; zeroes out the 'checksum' field (of length appropriate
-   to exactly hold the checksum to be computed); calculates the
-   appropriate checksum over the whole sequence, placing the result in
-   'checksum'; adds the necessary padding; then encrypts using the
-   specified encryption type and the appropriate key.
-
-   String or random-data to key transformation
-
-   To generate a DES key from two UTF-8 text strings (password and
-   salt), the two strings are concatenated, password first, and the
-   result is then padded with zero-valued octets to a multiple of 8
-   octets.
-
-   The top bit of each octet (always zero if the password is plain
-   ASCII, as was assumed when the original specification was written) is
-   discarded, and a bitstring is formed of the remaining seven bits of
-
-
-
-Raeburn                                                        [Page 19]
-
-INTERNET DRAFT                                              October 2003
-
-
-   each octet.  This bitstring is then fan-folded and eXclusive-ORed
-   with itself to produce a 56-bit string.  An eight-octet key is formed
-   from this string, each octet using seven bits from the bitstring,
-   leaving the least significant bit unassigned.  The key is then
-   "corrected" by correcting the parity on the key, and if the key
-   matches a 'weak' or 'semi-weak' key as described in the DES
-   specification, it is eXclusive-ORed with the constant
-   0x00000000000000F0.  This key is then used to generate a DES CBC
-   checksum on the initial string with the salt appended.  The result of
-   the CBC checksum is then "corrected" as described above to form the
-   result which is returned as the key.
-
-   For purposes of the string-to-key function, the DES CBC checksum is
-   calculated by CBC encrypting a string using the key as IV and using
-   the final 8 byte block as the checksum.
-
-   Pseudocode follows:
-
-        removeMSBits(8byteblock) {
-          /* Treats a 64 bit block as 8 octets and remove the MSB in
-             each octect (in big endian mode) and concatenates the
-             result.  E.g., input octet string:
-                01110000 01100001 11110011  01110011 11110111 01101111
-                11110010 01100100
-             results in output bitstring:
-                1110000 1100001 1110011  1110011 1110111 1101111
-                1110010 1100100  */
-        }
-
-        reverse(56bitblock) {
-          /* Treats a 56-bit block as a binary string and reverse it.
-             E.g., input string:
-                1000001 1010100 1001000  1000101 1001110 1000001
-                0101110 1001101
-             results in output string:
-                1011001 0111010 1000001  0111001 1010001 0001001
-                0010101 1000001  */
-        }
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 20]
-
-INTERNET DRAFT                                              October 2003
-
-
-        add_parity_bits(56bitblock) {
-          /* Copies a 56-bit block into a 64-bit block, left shift
-             content in each octet and add DES parity bit.
-             E.g., input string:
-                1100000 0001111 0011100  0110100 1000101 1100100
-                0110110 0010111
-             results in output string:
-                11000001 00011111 00111000  01101000 10001010 11001000
-                01101101 00101111  */
-        }
-
-        key_correction(key) {
-             fixparity(key);
-             if (is_weak_key(key))
-                  key = key XOR 0xF0;
-             return(key);
-        }
-
-        mit_des_string_to_key(string,salt) {
-             odd = 1;
-             s = string | salt;
-             tempstring = 0; /* 56-bit string */
-             pad(s); /* with nulls to 8 byte boundary */
-             for (8byteblock in s) {
-                  56bitstring = removeMSBits(8byteblock);
-                  if (odd == 0) reverse(56bitstring);
-                  odd = ! odd;
-                  tempstring = tempstring XOR 56bitstring;
-             }
-             tempkey = key_correction(add_parity_bits(tempstring));
-             key = key_correction(DES-CBC-check(s,tempkey));
-             return(key);
-        }
-
-        des_string_to_key(string,salt,params) {
-             if (length(params) == 0)
-                  type = 0;
-             else if (length(params) == 1)
-                  type = params[0];
-             else
-                  error("invalid params");
-             if (type == 0)
-                  mit_des_string_to_key(string,salt);
-             else
-                  error("invalid params");
-        }
-
-   One common extension is to support the "AFS string-to-key" algorithm,
-
-
-
-Raeburn                                                        [Page 21]
-
-INTERNET DRAFT                                              October 2003
-
-
-   which is not defined here, if the type value above is one (1).
-
-   For generation of a key from a random bitstring, we start with a
-   56-bit string, and as with the string-to-key operation above, insert
-   parity bits, and if the result is a weak or semi-weak key, modify it
-   by exclusive-OR with the constart 0x00000000000000F0:
-
-        des_random_to_key(bitstring) {
-             return key_correction(add_parity_bits(bitstring));
-        }
-
-6.2.1. DES with MD5
-
-   The des-cbc-md5 encryption mode encrypts information under DES in CBC
-   mode with an all-zero initial vector, with an MD5 checksum (described
-   in [MD5-92]) computed and placed in the checksum field.
-
-   The encryption system parameters for des-cbc-md5 are:
-
-                                des-cbc-md5
-    --------------------------------------------------------------------
-    protocol key format      8 bytes, parity in low bit of each
-
-    specific key structure   copy of original key
-
-    required checksum        rsa-md5-des
-    mechanism
-
-    key-generation seed      8 bytes
-    length
-
-    cipher state             8 bytes (CBC initial vector)
-
-    initial cipher state     all-zero
-
-    encryption function      des-cbc(confounder | checksum | msg | pad,
-                                     ivec=oldstate)
-                             where
-                             checksum = md5(confounder | 0000...
-                                            | msg | pad)
-
-                             newstate = last block of des-cbc output
-
-    decryption function      decrypt encrypted text and verify checksum
-
-                             newstate = last block of ciphertext
-
-
-
-
-
-Raeburn                                                        [Page 22]
-
-INTERNET DRAFT                                              October 2003
-
-
-                                des-cbc-md5
-    --------------------------------------------------------------------
-    default string-to-key    empty string
-    params
-
-    pseudo-random function   des-cbc(md5(input-string), ivec=0)
-
-    key generation functions:
-
-    string-to-key            des_string_to_key
-
-    random-to-key            des_random_to_key
-
-    key-derivation           identity
-
-   The des-cbc-md5 encryption type is assigned the etype value three
-   (3).
-
-6.2.2. DES with MD4
-
-   The des-cbc-md4 encryption mode also encrypts information under DES
-   in CBC mode, with an all-zero initial vector.  An MD4 checksum
-   (described in [MD4-92]) is computed and placed in the checksum field.
-
-                                des-cbc-md4
-    --------------------------------------------------------------------
-    protocol key format      8 bytes, parity in low bit of each
-
-    specific key structure   copy of original key
-
-    required checksum        rsa-md4-des
-    mechanism
-
-    key-generation seed      8 bytes
-    length
-
-    cipher state             8 bytes (CBC initial vector)
-
-    initial cipher state     all-zero
-
-    encryption function      des-cbc(confounder | checksum | msg | pad,
-                                     ivec=oldstate)
-                             where
-                             checksum = md4(confounder | 0000...
-                                            | msg | pad)
-
-                             newstate = last block of des-cbc output
-
-
-
-
-Raeburn                                                        [Page 23]
-
-INTERNET DRAFT                                              October 2003
-
-
-                                des-cbc-md4
-    --------------------------------------------------------------------
-
-    decryption function      decrypt encrypted text and verify checksum
-
-                             newstate = last block of ciphertext
-
-    default string-to-key    empty string
-    params
-
-    pseudo-random function   des-cbc(md5(input-string), ivec=0)
-
-    key generation functions:
-
-    string-to-key            des_string_to_key
-
-    random-to-key            copy input, then fix parity bits
-
-    key-derivation           identity
-
-   Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
-
-   The des-cbc-md4 encryption algorithm is assigned the etype value two
-   (2).
-
-6.2.3. DES with CRC
-
-   The des-cbc-crc encryption type uses DES in CBC mode with the key
-   used as the initialization vector, with a 4-octet CRC-based checksum
-   computed as described in section 6.1.3.  Note that this is not a
-   standard CRC-32 checksum, but a slightly modified one.
-
-
-                                des-cbc-crc
-    --------------------------------------------------------------------
-    protocol key format      8 bytes, parity in low bit of each
-
-    specific key structure   copy of original key
-
-    required checksum        rsa-md5-des
-    mechanism
-
-    key-generation seed      8 bytes
-    length
-
-    cipher state             8 bytes (CBC initial vector)
-
-
-
-
-
-Raeburn                                                        [Page 24]
-
-INTERNET DRAFT                                              October 2003
-
-
-                                des-cbc-crc
-    --------------------------------------------------------------------
-    initial cipher state     copy of original key
-
-    encryption function      des-cbc(confounder | checksum | msg | pad,
-                                     ivec=oldstate)
-                             where
-                             checksum = crc(confounder | 00000000
-                                            | msg | pad)
-
-                             newstate = last block of des-cbc output
-
-    decryption function      decrypt encrypted text and verify checksum
-
-                             newstate = last block of ciphertext
-
-    default string-to-key    empty string
-    params
-
-    pseudo-random function   des-cbc(md5(input-string), ivec=0)
-
-    key generation functions:
-
-    string-to-key            des_string_to_key
-
-    random-to-key            copy input, then fix parity bits
-
-    key-derivation           identity
-
-   The des-cbc-crc encryption algorithm is assigned the etype value one
-   (1).
-
-6.2.4. RSA MD5 Cryptographic Checksum Using DES
-
-   The RSA-MD5-DES checksum calculates a keyed collision-proof checksum
-   by prepending an 8 octet confounder before the text, applying the RSA
-   MD5 checksum algorithm, and encrypting the confounder and the
-   checksum using DES in cipher-block-chaining (CBC) mode using a
-   variant of the key, where the variant is computed by eXclusive-ORing
-   the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0.  The
-   initialization vector should be zero.  The resulting checksum is 24
-   octets long.  This checksum is tamper-proof and believed to be
-   collision-proof.
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 25]
-
-INTERNET DRAFT                                              October 2003
-
-
-                                rsa-md5-des
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
-                                        conf | rsa-md5(conf | msg))
-
-      verify_mic                decrypt and verify rsa-md5 checksum
-
-
-   The rsa-md5-des checksum algorithm is assigned a checksum type number
-   of eight (8).
-
-6.2.5. RSA MD4 Cryptographic Checksum Using DES
-
-   The RSA-MD4-DES checksum calculates a keyed collision-proof checksum
-   by prepending an 8 octet confounder before the text, applying the RSA
-   MD4 checksum algorithm [MD4-92], and encrypting the confounder and
-   the checksum using DES in cipher-block-chaining (CBC) mode using a
-   variant of the key, where the variant is computed by eXclusive-ORing
-   the key with the constant 0xF0F0F0F0F0F0F0F0.  [7] The initialization
-   vector should be zero.  The resulting checksum is 24 octets long.
-   This checksum is tamper-proof and believed to be collision-proof.
-
-                                rsa-md4-des
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
-                                        conf | rsa-md4(conf | msg),
-                                        ivec=0)
-
-      verify_mic                decrypt and verify rsa-md4 checksum
-
-   The rsa-md4-des checksum algorithm is assigned a checksum type number
-   of three (3).
-
-6.2.6. RSA MD4 Cryptographic Checksum Using DES alternative
-
-   The RSA-MD4-DES-K checksum calculates a keyed collision-proof
-   checksum by applying the RSA MD4 checksum algorithm and encrypting
-   the results using DES in cipher block chaining (CBC) mode using a DES
-   key as both key and initialization vector.  The resulting checksum is
-   16 octets long.  This checksum is tamper-proof and believed to be
-   collision-proof.  Note that this checksum type is the old method for
-   encoding the RSA-MD4-DES checksum and it is no longer recommended.
-
-
-
-
-
-Raeburn                                                        [Page 26]
-
-INTERNET DRAFT                                              October 2003
-
-
-                               rsa-md4-des-k
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-cbc(key, md4(msg), ivec=key)
-
-      verify_mic                decrypt, compute checksum and compare
-
-
-   The rsa-md4-des-k checksum algorithm is assigned a checksum type
-   number of six (6).
-
-6.2.7. DES CBC checksum
-
-   The DES-MAC checksum is computed by prepending an 8 octet confounder
-   to the plaintext, padding with zero-valued octets if necessary to
-   bring the length to a multiple of 8 octets, performing a DES CBC-mode
-   encryption on the result using the key and an initialization vector
-   of zero, taking the last block of the ciphertext, prepending the same
-   confounder and encrypting the pair using DES in cipher-block-chaining
-   (CBC) mode using a variant of the key, where the variant is computed
-   by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0.  The
-   initialization vector should be zero.  The resulting checksum is 128
-   bits (16 octets) long, 64 bits of which are redundant.  This checksum
-   is tamper-proof and collision-proof.
-
-
-                                  des-mac
-   ----------------------------------------------------------------------
-   associated     des-cbc-md5, des-cbc-md4, des-cbc-crc
-   cryptosystem
-
-   get_mic        des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
-                          conf | des-mac(key, conf | msg | pad, ivec=0),
-                          ivec=0)
-
-   verify_mic     decrypt, compute DES MAC using confounder, compare
-
-
-   The des-mac checksum algorithm is assigned a checksum type number of
-   four (4).
-
-6.2.8. DES CBC checksum alternative
-
-   The DES-MAC-K checksum is computed by performing a DES CBC-mode
-   encryption of the plaintext, with zero-valued padding bytes if
-   necessary to bring the length to a multiple of 8 octets, and using
-   the last block of the ciphertext as the checksum value.  It is keyed
-
-
-
-Raeburn                                                        [Page 27]
-
-INTERNET DRAFT                                              October 2003
-
-
-   with an encryption key which is also used as the initialization
-   vector.  The resulting checksum is 64 bits (8 octets) long.  This
-   checksum is tamper-proof and collision-proof.  Note that this
-   checksum type is the old method for encoding the DESMAC checksum and
-   it is no longer recommended.
-
-
-                                 des-mac-k
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-mac(key, msg | pad, ivec=key)
-
-      verify_mic                compute MAC and compare
-
-
-   The des-mac-k checksum algorithm is assigned a checksum type number
-   of five (5).
-
-6.3. Triple-DES based encryption and checksum types
-
-   This encryption and checksum type pair is based on the Triple DES
-   cryptosystem in Outer-CBC mode, and the HMAC-SHA1 message
-   authentication algorithm.
-
-   A Triple DES key is the concatenation of three DES keys as described
-   above for des-cbc-md5.  A Triple DES key is generated from random
-   data by creating three DES keys from separate sequences of random
-   data.
-
-   Encrypted data using this type must be generated as described in
-   section 5.3.  If the length of the input data is not a multiple of
-   the block size, zero-valued octets must be used to pad the plaintext
-   to the next eight-octet boundary.  The confounder must be eight
-   random octets (one block).
-
-   The simplified profile for Triple DES, with key derivation as defined
-   in section 5, is as follows:
-
-                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
-              ------------------------------------------------
-              protocol key format     24 bytes, parity in low
-                                      bit of each
-
-              key-generation seed     21 bytes
-              length
-
-
-
-
-
-Raeburn                                                        [Page 28]
-
-INTERNET DRAFT                                              October 2003
-
-
-                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
-              ------------------------------------------------
-              hash function           SHA-1
-
-              HMAC output size        160 bits
-
-              message block size      8 bytes
-
-              default string-to-key   empty string
-              params
-
-              encryption and          triple-DES encrypt and
-              decryption functions    decrypt, in outer-CBC
-                                      mode (cipher block size
-                                      8 octets)
-
-              key generation functions:
-
-              random-to-key           DES3random-to-key (see
-                                      below)
-
-              string-to-key           DES3string-to-key (see
-                                      below)
-
-   The des3-cbc-hmac-sha1-kd encryption type is assigned the value
-   sixteen (16).  The hmac-sha1-des3-kd checksum algorithm is assigned a
-   checksum type number of twelve (12).
-
-6.3.1. Triple DES Key Production (random-to-key, string-to-key)
-
-   The 168 bits of random key data are converted to a protocol key value
-   as follows.  First, the 168 bits are divided into three groups of 56
-   bits, which are expanded individually into 64 bits as follows:
-
-   DES3random-to-key:
-         1  2  3  4  5  6  7  p
-         9 10 11 12 13 14 15  p
-        17 18 19 20 21 22 23  p
-        25 26 27 28 29 30 31  p
-        33 34 35 36 37 38 39  p
-        41 42 43 44 45 46 47  p
-        49 50 51 52 53 54 55  p
-        56 48 40 32 24 16  8  p
-
-   The "p" bits are parity bits computed over the data bits.  The output
-   of the three expansions, each corrected to avoid "weak" and "semi-
-   weak" keys as in section 6.2, are concatenated to form the protocol
-   key value.
-
-
-
-Raeburn                                                        [Page 29]
-
-INTERNET DRAFT                                              October 2003
-
-
-   The string-to-key function is used to transform UTF-8 passwords into
-   DES3 keys.  The DES3 string-to-key function relies on the "N-fold"
-   algorithm and DK function, described in section 5.
-
-   The n-fold algorithm is applied to the password string concatenated
-   with a salt value.  For 3-key triple DES, the operation will involve
-   a 168-fold of the input password string, to generate an intermediate
-   key, from which the user's long-term key will be derived with the DK
-   function.  The DES3 string-to-key function is shown here in
-   pseudocode:
-
-         DES3string-to-key(passwordString, salt, params)
-             if (params != emptyString)
-              error("invalid params");
-             s = passwordString + salt
-             tmpKey = random-to-key(168-fold(s))
-             key = DK (tmpKey, KerberosConstant)
-
-   Weak key checking is performed in the random-to-key and DK
-   operations.  The KerberosConstant value is the byte string {0x6b 0x65
-   0x72 0x62 0x65 0x72 0x6f 0x73}.  These values correspond to the ASCII
-   encoding for the string "kerberos".
-
-7. Use of Kerberos encryption outside this specification
-
-   Several Kerberos-based application protocols and preauthentication
-   systems have been designed and deployed that perform encryption and
-   message integrity checks in various ways.  While in some cases there
-   may be good reason for specifying these protocols in terms of
-   specific encryption or checksum algorithms, we anticipate that in
-   many cases this will not be true, and more generic approaches
-   independent of particular algorithms will be desirable.  Rather than
-   having each protocol designer reinvent schemes for protecting data,
-   using multiple keys, etc, we have attempted to present in this
-   section a general framework that should be sufficient not only for
-   the Kerberos protocol itself but also for many preauthentication
-   systems and application protocols, while trying to avoid some of the
-   assumptions that can work their way into such protocol designs.
-
-   Some problematic assumptions we've seen (and sometimes made) include:
-   that a random bitstring is always valid as a key (not true for DES
-   keys with parity); that the basic block encryption chaining mode
-   provides no integrity checking, or can easily be separated from such
-   checking (not true for many modes in development that do both
-   simultaneously); that a checksum for a message always results in the
-   same value (not true if a confounder is incorporated); that an
-   initial vector is used (may not be true if a block cipher in CBC mode
-   is not in use).
-
-
-
-Raeburn                                                        [Page 30]
-
-INTERNET DRAFT                                              October 2003
-
-
-   Such assumptions, while they may hold for any given set of encryption
-   and checksum algorithms, may not be true of the next algorithms to be
-   defined, leaving the application protocol unable to make use of those
-   algorithms without updates to its specification.
-
-   The Kerberos protocol uses only the attributes and operations
-   described in sections 3 and 4.  Preauthentication systems and
-   application protocols making use of Kerberos are encouraged to use
-   them as well.  The specific key and string-to-key parameters should
-   generally be treated as opaque.  While the string-to-key parameters
-   are manipulated as an octet string, the representation for the
-   specific key structure is implementation-defined; it may not even be
-   a single object.
-
-   While we don't recommend it, some application protocols will
-   undoubtedly continue to use the key data directly, even if only in
-   some of the currently existing protocol specifications.  An
-   implementation intended to support general Kerberos applications may
-   therefore need to make the key data available, as well as the
-   attributes and operations described in sections 3 and 4.  [8]
-
-8. Assigned Numbers
-
-   The following encryption type numbers are already assigned or
-   reserved for use in Kerberos and related protocols.
-
-
-     encryption type                etype      section or comment
-     -----------------------------------------------------------------
-     des-cbc-crc                        1             6.2.3
-     des-cbc-md4                        2             6.2.2
-     des-cbc-md5                        3             6.2.1
-     [reserved]                         4
-     des3-cbc-md5                       5
-     [reserved]                         6
-     des3-cbc-sha1                      7
-     dsaWithSHA1-CmsOID                 9           (pkinit)
-     md5WithRSAEncryption-CmsOID       10           (pkinit)
-     sha1WithRSAEncryption-CmsOID      11           (pkinit)
-     rc2CBC-EnvOID                     12           (pkinit)
-     rsaEncryption-EnvOID              13   (pkinit from PKCS#1 v1.5)
-     rsaES-OAEP-ENV-OID                14   (pkinit from PKCS#1 v2.0)
-     des-ede3-cbc-Env-OID              15           (pkinit)
-     des3-cbc-sha1-kd                  16              6.3
-     aes128-cts-hmac-sha1-96           17          [KRB5-AES]
-     aes256-cts-hmac-sha1-96           18          [KRB5-AES]
-     rc4-hmac                          23          (Microsoft)
-
-
-
-
-Raeburn                                                        [Page 31]
-
-INTERNET DRAFT                                              October 2003
-
-
-     rc4-hmac-exp                      24          (Microsoft)
-     subkey-keymaterial                65     (opaque; PacketCable)
-
-
-   (The "des3-cbc-sha1" assignment is a deprecated version using no key
-   derivation.  It should not be confused with des3-cbc-sha1-kd.)
-
-   Several numbers have been reserved for use in encryption systems not
-   defined here.  Encryption type numbers have unfortunately been
-   overloaded on occasion in Kerberos-related protocols, so some of the
-   reserved numbers do not and will not correspond to encryption systems
-   fitting the profile presented here.
-
-   The following checksum type numbers are assigned or reserved.  As
-   with encryption type numbers, some overloading of checksum numbers
-   has occurred.
-
-
-   Checksum type              sumtype        checksum         section or
-                                value            size         reference
-   ----------------------------------------------------------------------
-   CRC32                            1               4           6.1.3
-   rsa-md4                          2              16           6.1.2
-   rsa-md4-des                      3              24           6.2.5
-   des-mac                          4              16           6.2.7
-   des-mac-k                        5               8           6.2.8
-   rsa-md4-des-k                    6              16           6.2.6
-   rsa-md5                          7              16           6.1.1
-   rsa-md5-des                      8              24           6.2.4
-   rsa-md5-des3                     9              24             ??
-   sha1 (unkeyed)                  10              20             ??
-   hmac-sha1-des3-kd               12              20            6.3
-   hmac-sha1-des3                  13              20             ??
-   sha1 (unkeyed)                  14              20             ??
-   hmac-sha1-96-aes128             15              20         [KRB5-AES]
-   hmac-sha1-96-aes256             16              20         [KRB5-AES]
-   [reserved]                  0x8003               ?         [GSS-KRB5]
-
-
-   Encryption and checksum type numbers are signed 32-bit values.  Zero
-   is invalid, and negative numbers are reserved for local use.  All
-   standardized values must be positive.
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 32]
-
-INTERNET DRAFT                                              October 2003
-
-
-9. Implementation Notes
-
-   The "interface" described here is the minimal information that must
-   be defined to make a cryptosystem useful within Kerberos in an
-   interoperable fashion.  Despite the functional notation used in some
-   places, it is not an attempt to define an API for cryptographic
-   functionality within Kerberos.  Actual implementations providing
-   clean APIs will probably find it useful to make additional
-   information available, which should be possible to derive from a
-   specification written to the framework given here.  For example, an
-   application designer may wish to determine the largest number of
-   bytes that can be encrypted without overflowing a certain size output
-   buffer, or conversely, the maximum number of bytes that might be
-   obtained by decrypting a ciphertext message of a given size.  (In
-   fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5]
-   will require some of these.)
-
-   The presence of a mechanism in this document should not be taken as
-   an indication that it must be implemented for compliance with any
-   specification; required mechanisms will be specified elsewhere.
-   Indeed, some of the mechanisms described here for backwards
-   compatibility are now considered rather weak for protecting critical
-   data.
-
-10. Security Considerations
-
-   Recent years have brought advancements in the ability to perform
-   large-scale attacks against DES, to such a degree that it is not
-   considered a strong encryption mechanism any longer; triple-DES is
-   generally preferred in its place, despite the poorer performance.
-   See [ESP-DES] for a summary of some of the potential attacks, and
-   [EFF-DES] for a detailed discussion of the implementation of
-   particular attack.  However, most Kerberos implementations still have
-   DES as their primary interoperable encryption type.
-
-   DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of
-   single-DES here avoids them.  However, DES also has 48 'possibly-
-   weak' keys [Schneier96] (note that the tables in many editions of the
-   reference contains errors) which are not avoided.
-
-   DES weak keys are keys with the property that E1(E1(P)) = P (where E1
-   denotes encryption of a single block with key 1).  DES semi-weak keys
-   or "dual" keys are pairs of keys with the property that E1(P) =
-   D2(P), and thus E2(E1(P)) = P.  Because of the use of CBC mode and
-   leading random confounder, however, these properties are unlikely to
-   present a security problem.
-
-   Many of the choices concerning when weak-key corrections are
-
-
-
-Raeburn                                                        [Page 33]
-
-INTERNET DRAFT                                              October 2003
-
-
-   performed relate more to compatibility with existing implementations
-   than to any risk analysis.
-
-   While checks are also done for the component DES keys in a triple-DES
-   key, the nature of the weak keys is such that it is extremely
-   unlikely that they will weaken the triple-DES encryption -- only
-   slightly more likely than having the middle of the three sub-keys
-   match one of the other two, which effectively converts the encryption
-   to single-DES, which is a case we make no effort to avoid.
-
-   The true CRC-32 checksum is not collision-proof; an attacker could
-   use a probabilistic chosen-plaintext attack to generate a valid
-   message even if a confounder is used [SG92].  The use of collision-
-   proof checksums is of course recommended for environments where such
-   attacks represent a significant threat.  The "simplifications" (read:
-   bugs) introduced when CRC-32 was implemented for Kerberos cause
-   leading zeros to effectively be ignored, so messages differing only
-   in leading zero bits will have the same checksum.
-
-   [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm.
-   Unlike [IPSEC-HMAC], the triple-DES specification here does not use
-   the suggested truncation of the HMAC output.  As pointed out in
-   [IPSEC-HMAC], SHA-1 was not developed to be used as a keyed hash
-   function, which is a criterion of HMAC.  [HMAC-TEST] contains test
-   vectors for HMAC-SHA-1.
-
-   The mit_des_string_to_key function was originally constructed with
-   the assumption that all input would be ASCII; it ignores the top bit
-   of each input byte.  Folding with XOR is also not an especially good
-   mixing mechanism in terms of preserving randomness.
-
-   The n-fold function used in the string-to-key operation for des3-cbc-
-   hmac-sha1-kd was designed to cause each bit of input to contribute
-   equally to the output; it was not designed to maximize or equally
-   distribute randomness in the input, and there are conceivable cases
-   of partially structured input where randomness may be lost.  This
-   should only be an issue for highly structured passwords, however.
-
-   [RFC1851] discusses the relative strength of triple-DES encryption.
-   The relative slow speed of triple-DES encryption may also be an issue
-   for some applications.
-
-   In [Bellovin91], there is a suggestion that analyses of encryption
-   schemes should include a model of an attacker capable of submitting
-   known plaintexts to be encrypted with an unknown key, as well as
-   being able to perform many types of operations on known protocol
-   messages.  Recent experiences with the chosen-plaintext attacks on
-   Kerberos version 4 bear out the value of this suggestion.
-
-
-
-Raeburn                                                        [Page 34]
-
-INTERNET DRAFT                                              October 2003
-
-
-   The use of unkeyed encrypted checksums, such as those used in the
-   single-DES cryptosystems specified in [Kerb1510], allows for cut-and-
-   paste attacks, especially if a confounder is not used.  In addition,
-   unkeyed encrypted checksums are vulnerable to chosen-plaintext
-   attacks: an attacker with access to an encryption oracle can easily
-   encrypt the required unkeyed checksum along with the chosen
-   plaintext. [Bellovin99]  These weaknesses, combined with a common
-   implementation design choice described below, allow for a cross-
-   protocol attack from version 4 to version 5.
-
-   The use of a random confounder is an important means of preventing an
-   attacker from making effective use of protocol exchanges as an
-   encryption oracle.  In Kerberos version 4, the encryption of constant
-   plaintext to constant ciphertext makes an effective encryption oracle
-   for an attacker.  The use of random confounders in [Kerb1510]
-   frustrates this sort of chosen-plaintext attack.
-
-   Using the same key for multiple purposes can enable or increase the
-   scope of chosen-plaintext attacks.  Some software which implements
-   both versions 4 and 5 of the Kerberos protocol uses the same keys for
-   both versions of the protocol.  This enables the encryption oracle of
-   version 4 to be used to attack version 5.  Vulnerabilities such as
-   this cross-protocol attack reinforce the wisdom of not using a key
-   for multiple purposes.
-
-   This document, like the Kerberos protocol, completely ignores the
-   notion of limiting the amount of data a key may be used with to a
-   quantity based on the robustness of the algorithm or size of the key.
-   It is assumed that any defined algorithms and key sizes will be
-   strong enough to support very large amounts of data, or they will be
-   deprecated once significant attacks are known.
-
-   This document also places no bounds on the amount of data that can be
-   handled in various operations.  In order to avoid denial of service
-   attacks, implementations will probably want to restrict message sizes
-   at some higher level.
-
-11. IANA Considerations
-
-   Two registries for numeric values should be created: Kerberos
-   Encryption Type Numbers and Kerberos Checksum Type Numbers.  These
-   are signed 32-bit values in twos-complement form.  Positive values up
-   to 2**31-1 inclusive should be assigned only for algorithms specified
-   in accordance with this specification for use with Kerberos or
-   related protocols.  Negative values through -2**31 are for private
-   use; local and experimental algorithms should use these values.  Zero
-   is reserved and may not be assigned.
-
-
-
-
-Raeburn                                                        [Page 35]
-
-INTERNET DRAFT                                              October 2003
-
-
-   Positive encryption and checksum type numbers may be assigned
-   following either of two policies described in [BCP26].
-
-   Standards-track specifications may be assigned values under the
-   Standards Action policy.
-
-   Specifications in Informational RFCs may be assigned values after
-   Expert Review.  A non-IETF specification may be assigned values by
-   publishing an Informational or standards-track RFC referencing the
-   external specification; that specification must be public and
-   published in some permanent record much like the IETF RFCs.  It is
-   highly desirable, though not required, that the full specification be
-   published as an IETF RFC.
-
-   Smaller encryption type values, which encode to smaller octet strings
-   under ASN.1, should be used for IETF standards-track mechanisms, and
-   much higher values (hex 0x1000000 and above) for other mechanisms.
-   No other guidance into allocation order is given.
-
-   Draft IETF specifications should not include values for encryption
-   and checksum type numbers.  Instead, they should indicate that values
-   would be assigned by IANA when the document is approved as an RFC.
-   For development and interoperability testing, values in the private-
-   use range (negative values) may be used, but should not be included
-   in the draft specification.
-
-   Each registered value should have an associated unique name to refer
-   to it by.  The lists given in section 8 should be used as an initial
-   registry; they include reservations for specifications in progress in
-   parallel with this document, and for certain other values believed to
-   be in use already.
-
-12. Acknowledgments
-
-   This document is an extension of the encryption specification
-   included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much
-   of the text of the background, concepts, and DES specifications are
-   drawn directly from that document.
-
-   The abstract framework presented in this document was put together by
-   Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn,
-   and Tom Yu, and the details were refined several times based on
-   comments from John Brezak and others.
-
-   Marc Horowitz wrote the original specification of triple-DES and key
-   derivation in a pair of Internet Drafts (under the names draft-
-   horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which
-   were later folded into a draft revision of [Kerb1510], from which
-
-
-
-Raeburn                                                        [Page 36]
-
-INTERNET DRAFT                                              October 2003
-
-
-   this document was later split off.
-
-   Tom Yu provided the text describing the modifications to the standard
-   CRC algorithm as Kerberos implementations actually use it, and some
-   of the Security Considerations section.
-
-   Miroslav Jurisic provided information for one of the UTF-8 test cases
-   for the string-to-key functions.
-
-   Marcus Watts noticed some errors in earlier drafts, and pointed out
-   that the simplified profile could easily be modified to support
-   cipher text stealing modes.
-
-   Simon Josefsson contributed some clarifications to the DES "CBC
-   checksum", string-to-key and weak key descriptions, and some test
-   vectors.
-
-   Simon Josefsson, Louis LeVay and others also caught some errors in
-   earlier drafts.
-
-A. Test vectors
-
-   This section provides test vectors for various functions defined or
-   described in this document.  For convenience, most inputs are ASCII
-   strings, though some UTF-8 samples are be provided for string-to-key
-   functions.  Keys and other binary data are specified as hexadecimal
-   strings.
-
-A.1. n-fold
-
-   The n-fold function is defined in section 5.1.  As noted there, the
-   sample vector in the original paper defining the algorithm appears to
-   be incorrect.  Here are some test cases provided by Marc Horowitz and
-   Simon Josefsson:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 37]
-
-INTERNET DRAFT                                              October 2003
-
-
-      64-fold("012345") =
-      64-fold(303132333435) = be072631276b1955
-
-      56-fold("password") =
-      56-fold(70617373776f7264) = 78a07b6caf85fa
-
-      64-fold("Rough Consensus, and Running Code") =
-      64-fold(526f75676820436f6e73656e7375732c20616e642052756e
-              6e696e6720436f6465) = bb6ed30870b7f0e0
-
-      168-fold("password") =
-      168-fold(70617373776f7264) =
-               59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
-
-      192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY"
-      192-fold(4d41535341434856534554545320494e5354495456544520
-               4f4620544543484e4f4c4f4759) =
-               db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
-
-      168-fold("Q") =
-      168-fold(51) =
-               518a54a2 15a8452a 518a54a2 15a8452a
-               518a54a2 15
-
-      168-fold("ba") =
-      168-fold(6261) =
-               fb25d531 ae897449 9f52fd92 ea9857c4
-               ba24cf29 7e
-
-   Here are some additional values corresponding to folded values of the
-   string "kerberos"; the 64-bit form is used in the des3 string-to-key
-   (section 6.3.1).
-
-      64-fold("kerberos") =
-               6b657262 65726f73
-      128-fold("kerberos") =
-               6b657262 65726f73 7b9b5b2b 93132b93
-      168-fold("kerberos") =
-               8372c236 344e5f15 50cd0747 e15d62ca
-               7a5a3bce a4
-      256-fold("kerberos") =
-               6b657262 65726f73 7b9b5b2b 93132b93
-               5c9bdcda d95c9899 c4cae4de e6d6cae4
-
-   Note that the initial octets exactly match the input string when the
-   output length is a multiple of the input length.
-
-
-
-
-
-Raeburn                                                        [Page 38]
-
-INTERNET DRAFT                                              October 2003
-
-
-A.2. mit_des_string_to_key
-
-   The function mit_des_string_to_key is defined in section 6.2.  We
-   present here several test values, with some of the intermediate
-   results.  The fourth test demonstrates the use of UTF-8 with three
-   characters.  The last two tests are specifically constructed so as to
-   trigger the weak-key fixups for the intermediate key produced by fan-
-   folding; we have no test cases that cause such fixups for the final
-   key.
-
-
-   UTF-8 encodings used in test vector:
-   eszett     C3 9F            s-caron     C5 A1      c-acute     C4 87
-   g-clef     F0 9D 84 9E
-
-
-   Test vector:
-
-
-   salt:        "ATHENA.MIT.EDUraeburn"
-                              415448454e412e4d49542e4544557261656275726e
-   password:    "password"    70617373776f7264
-   fan-fold result:           c01e38688ac86c2e
-   intermediate key:          c11f38688ac86d2f
-   DES key:                   cbc22fae235298e3
-
-
-
-   salt:       "WHITEHOUSE.GOVdanny"   5748495445484f5553452e474f5664616e6e79
-   password:   "potatoe"               706f7461746f65
-   fan-fold result:                    a028944ee63c0416
-   intermediate key:                   a129944fe63d0416
-   DES key:                            df3d32a74fd92a01
-
-
-
-   salt:      "EXAMPLE.COMpianist"  4558414D504C452E434F4D7069616E697374
-   password:  g-clef                f09d849e
-   fan-fold result:                 3c4a262c18fab090
-   intermediate key:                3d4a262c19fbb091
-   DES key:                         4ffb26bab0cd9413
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 39]
-
-INTERNET DRAFT                                              October 2003
-
-
-   salt:        "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
-                          415448454e412e4d49542e4544554a757269c5a169c487
-   password:    eszett    c39f
-   fan-fold result:       b8f6c40e305afc9e
-   intermediate key:      b9f7c40e315bfd9e
-   DES key:               62c81a5232b5e69d
-
-
-
-   salt:       "AAAAAAAA"   4141414141414141
-   password:   "11119999"   3131313139393939
-   fan-fold result:         e0e0e0e0f0f0f0f0
-   intermediate key:        e0e0e0e0f1f1f101
-   DES key:                 984054d0f1a73e31
-
-
-
-   salt:       "FFFFAAAA"   4646464641414141
-   password:   "NNNN6666"   4e4e4e4e36363636
-   fan-fold result:         1e1e1e1e0e0e0e0e
-   intermediate key:        1f1f1f1f0e0e0efe
-   DES key:                 c4bf6b25adf7a4f8
-
-
-   This trace provided by Simon Josefsson shows the intermediate
-   processing stages of one of the test inputs:
-
-     string_to_key (des-cbc-md5, string, salt)
-            ;; string:
-            ;; `password' (length 8 bytes)
-            ;; 70 61 73 73 77 6f 72 64
-            ;; salt:
-            ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
-            ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
-            ;; 65 62 75 72 6e
-     des_string_to_key (string, salt)
-            ;; String:
-            ;; `password' (length 8 bytes)
-            ;; 70 61 73 73 77 6f 72 64
-            ;; Salt:
-            ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
-            ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
-            ;; 65 62 75 72 6e
-     odd = 1;
-     s = string | salt;
-
-
-
-
-
-
-Raeburn                                                        [Page 40]
-
-INTERNET DRAFT                                              October 2003
-
-
-     tempstring = 0; /* 56-bit string */
-     pad(s); /* with nulls to 8 byte boundary */
-            ;; s = pad(string|salt):
-            ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'
-            ;; (length 32 bytes)
-            ;; 70 61 73 73 77 6f 72 64  41 54 48 45 4e 41 2e 4d
-            ;; 49 54 2e 45 44 55 72 61  65 62 75 72 6e 00 00 00
-     for (8byteblock in s) {
-            ;; loop iteration 0
-            ;; 8byteblock:
-            ;; `password' (length 8 bytes)
-            ;; 70 61 73 73 77 6f 72 64
-            ;; 01110000 01100001 01110011  01110011 01110111 01101111
-            ;; 01110010 01100100
-     56bitstring = removeMSBits(8byteblock);
-            ;; 56bitstring:
-            ;; 1110000 1100001 1110011  1110011 1110111 1101111
-            ;; 1110010 1100100
-     if (odd == 0) reverse(56bitstring);    ;; odd=1
-     odd = ! odd
-     tempstring = tempstring XOR 56bitstring;
-            ;; tempstring
-            ;; 1110000 1100001 1110011  1110011 1110111 1101111
-            ;; 1110010 1100100
-
-     for (8byteblock in s) {
-            ;; loop iteration 1
-            ;; 8byteblock:
-            ;; `ATHENA.M' (length 8 bytes)
-            ;; 41 54 48 45 4e 41 2e 4d
-            ;; 01000001 01010100 01001000  01000101 01001110 01000001
-            ;; 00101110 01001101
-     56bitstring = removeMSBits(8byteblock);
-            ;; 56bitstring:
-            ;; 1000001 1010100 1001000  1000101 1001110 1000001
-            ;; 0101110 1001101
-     if (odd == 0) reverse(56bitstring);    ;; odd=0
-     reverse(56bitstring)
-            ;; 56bitstring after reverse
-            ;; 1011001 0111010 1000001  0111001 1010001 0001001
-            ;; 0010101 1000001
-     odd = ! odd
-     tempstring = tempstring XOR 56bitstring;
-            ;; tempstring
-            ;; 0101001 1011011 0110010  1001010 0100110 1100110
-            ;; 1100111 0100101
-
-
-
-
-
-Raeburn                                                        [Page 41]
-
-INTERNET DRAFT                                              October 2003
-
-
-     for (8byteblock in s) {
-            ;; loop iteration 2
-            ;; 8byteblock:
-            ;; `IT.EDUra' (length 8 bytes)
-            ;; 49 54 2e 45 44 55 72 61
-            ;; 01001001 01010100 00101110  01000101 01000100 01010101
-            ;; 01110010 01100001
-     56bitstring = removeMSBits(8byteblock);
-            ;; 56bitstring:
-            ;; 1001001 1010100 0101110  1000101 1000100 1010101
-            ;; 1110010 1100001
-     if (odd == 0) reverse(56bitstring);    ;; odd=1
-     odd = ! odd
-     tempstring = tempstring XOR 56bitstring;
-            ;; tempstring
-            ;; 1100000 0001111 0011100  0001111 1100010 0110011
-            ;; 0010101 1000100
-
-     for (8byteblock in s) {
-            ;; loop iteration 3
-            ;; 8byteblock:
-            ;; `eburn\x00\x00\x00' (length 8 bytes)
-            ;; 65 62 75 72 6e 00 00 00
-            ;; 01100101 01100010 01110101  01110010 01101110 00000000
-            ;; 00000000 00000000
-     56bitstring = removeMSBits(8byteblock);
-            ;; 56bitstring:
-            ;; 1100101 1100010 1110101  1110010 1101110 0000000
-            ;; 0000000 0000000
-     if (odd == 0) reverse(56bitstring);    ;; odd=0
-     reverse(56bitstring)
-            ;; 56bitstring after reverse
-            ;; 0000000 0000000 0000000  0111011 0100111 1010111
-            ;; 0100011 1010011
-     odd = ! odd
-     tempstring = tempstring XOR 56bitstring;
-            ;; tempstring
-            ;; 1100000 0001111 0011100  0110100 1000101 1100100
-            ;; 0110110 0010111
-
-     for (8byteblock in s) {
-     }
-            ;; for loop terminated
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 42]
-
-INTERNET DRAFT                                              October 2003
-
-
-     tempkey = key_correction(add_parity_bits(tempstring));
-            ;; tempkey
-            ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes)
-            ;; c1 1f 38 68 8a c8 6d 2f
-            ;; 11000001 00011111 00111000  01101000 10001010 11001000
-            ;; 01101101 00101111
-
-     key = key_correction(DES-CBC-check(s,tempkey));
-            ;; key
-            ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
-            ;; cb c2 2f ae 23 52 98 e3
-            ;; 11001011 11000010 00101111  10101110 00100011 01010010
-            ;; 10011000 11100011
-
-            ;; string_to_key key:
-            ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
-            ;; cb c2 2f ae 23 52 98 e3
-
-
-A.3. DES3 DR and DK
-
-   These tests show the derived-random and derived-key values for the
-   des3-hmac-sha1-kd encryption scheme, using the DR and DK functions
-   defined in section 6.3.1.  The input keys were randomly generated;
-   the usage values are from this specification.
-
-
-   key:                 dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
-   usage:               0000000155
-   DR:                  935079d14490a75c3093c4a6e8c3b049c71e6ee705
-   DK:                  925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
-
-   key:                 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
-   usage:               00000001aa
-   DR:                  9f58e5a047d894101c469845d67ae3c5249ed812f2
-   DK:                  9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
-
-   key:                 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
-   usage:               0000000155
-   DR:                  12fff90c773f956d13fc2ca0d0840349dbd39908eb
-   DK:                  13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
-
-   key:                 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
-   usage:               00000001aa
-   DR:                  f8debf05b097e7dc0603686aca35d91fd9a5516a70
-   DK:                  f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
-
-
-
-
-
-Raeburn                                                        [Page 43]
-
-INTERNET DRAFT                                              October 2003
-
-
-   key:                 d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
-   usage:               6b65726265726f73 ("kerberos")
-   DR:                  2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
-   DK:                  2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
-
-   key:                 c1081649ada74362e6a1459d01dfd30d67c2234c940704da
-   usage:               0000000155
-   DR:                  348056ec98fcc517171d2b4d7a9493af482d999175
-   DK:                  348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
-
-   key:                 5d154af238f46713155719d55e2f1f790dd661f279a7917c
-   usage:               00000001aa
-   DR:                  a8818bc367dadacbe9a6c84627fb60c294b01215e5
-   DK:                  a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
-
-   key:                 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
-   usage:               0000000155
-   DR:                  c813f88b3be2b2f75424ce9175fbc8483b88c8713a
-   DK:                  c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
-
-   key:                 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
-   usage:               00000001aa
-   DR:                  f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
-   DK:                  f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
-
-
-A.4. DES3string_to_key
-
-   These are the keys generated for some of the above input strings for
-   triple-DES with key derivation as defined in section 6.3.1.
-
-    salt:   "ATHENA.MIT.EDUraeburn"
-    passwd: "password"
-    key:    850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
-
-    salt:   "WHITEHOUSE.GOVdanny"
-    passwd: "potatoe"
-    key:    dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
-
-    salt:   "EXAMPLE.COMbuckaroo"
-    passwd: "penny"
-    key:    6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
-
-    salt:   "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
-    passwd: eszett
-    key:    16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
-
-
-
-
-
-Raeburn                                                        [Page 44]
-
-INTERNET DRAFT                                              October 2003
-
-
-    salt:   "EXAMPLE.COMpianist"
-    passwd: g-clef
-    key:    85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
-
-A.5. Modified CRC-32
-
-   Below are modified-CRC32 values for various ASCII and octet strings.
-   Only the printable ASCII characters are checksummed, no C-style
-   trailing zero-valued octet.  The 32-bit modified CRC and the sequence
-   of output bytes as used in Kerberos are shown.  (The octet values are
-   separated here to emphasize that they are octet values and not 32-bit
-   numbers, which will be the most convenient form for manipulation in
-   some implementations.  The bit and byte order used internally for
-   such a number is irrelevant; the octet sequence generated is what is
-   important.)
-
-
-    mod-crc-32("foo") =                                     33 bc 32 73
-    mod-crc-32("test0123456789") =                          d6 88 3e b8
-    mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") =   f7 80 41 e3
-    mod-crc-32(8000) =                                      4b 98 83 3b
-    mod-crc-32(0008) =                                      32 88 db 0e
-    mod-crc-32(0080) =                                      20 83 b8 ed
-    mod-crc-32(80) =                                        20 83 b8 ed
-    mod-crc-32(80000000) =                                  3b b6 59 ed
-    mod-crc-32(00000001) =                                  96 30 07 77
-
-
-B. Significant Changes from RFC 1510
-
-   The encryption and checksum mechanism profiles are new.  The old
-   specification defined a few operations for various mechanisms, but
-   didn't outline what should be required of new mechanisms in terms of
-   abstract properties, nor how to ensure that a mechanism specification
-   is complete enough for interoperability between implementations.  The
-   new profiles do differ from the old specification in a few ways:
-
-      Some message definitions in [Kerb1510] could be read as permitting
-      the initial vector to be specified by the application; the text
-      was too vague.  It is specifically not permitted in this
-      specification.  Some encryption algorithms may not use
-      initialization vectors, so relying on chosen, secret
-      initialization vectors for security is unwise.  Also, the
-      prepended confounder in the existing algorithms is roughly
-      equivalent to a per-message initialization vector that is revealed
-      in encrypted form.  However, carrying state across from one
-      encryption to another is explicitly permitted through the opaque
-      "cipher state" object.
-
-
-
-Raeburn                                                        [Page 45]
-
-INTERNET DRAFT                                              October 2003
-
-
-      The use of key derivation is new.
-
-      Several new methods are introduced, including generation of a key
-      in wire-protocol format from random input data.
-
-      The means for influencing the string-to-key algorithm are laid out
-      more clearly.
-
-   Triple-DES support is new.
-
-   The pseudo-random function is new.
-
-   The des-cbc-crc, DES string-to-key and CRC descriptions have been
-   updated to align them with existing implementations.
-
-   [Kerb1510] had no indication what character set or encoding might be
-   used for pass phrases and salts.
-
-   In [Kerb1510], key types, encryption algorithms and checksum
-   algorithms were only loosely associated, and the association was not
-   well described.  In this specification, key types and encryption
-   algorithms have a one-to-one correspondence, and associations between
-   encryption and checksum algorithms are described so that checksums
-   can be computed given negotiated keys, without requiring further
-   negotiation for checksum types.
-
-Notes
-
-   [1] While Message Authentication Code (MAC) or Message Integrity
-       Check (MIC) would be more appropriate terms for many of the
-       uses in this document, we continue to use the term "checksum"
-       for historical reasons.
-
-   [2] Extending CBC mode across messages would be one obvious
-       example of this chaining.  Another might be the use of
-       counter mode, with a counter randomly initialized and
-       attached to the ciphertext; a second message could continue
-       incrementing the counter when chaining the cipher state, thus
-       avoiding having to transmit another counter value.  However,
-       this chaining is only useful for uninterrupted, ordered
-       sequences of messages.
-
-   [3] In the case of Kerberos, the encrypted objects will generally
-       be ASN.1 DER encodings, which contain indications of their
-       length in the first few octets.
-
-   [4] As of the time of this writing, some new modes of operation
-       have been proposed, some of which may permit encryption and
-
-
-
-Raeburn                                                        [Page 46]
-
-INTERNET DRAFT                                              October 2003
-
-
-       integrity protection simultaneously.  After some of these
-       proposals have been subjected to adequate analysis, we may
-       wish to formulate a new simplified profile based on one of
-       them.
-
-   [5] It should be noted that the sample vector in Appendix B.2 of
-       the original paper appears to be incorrect.  Two independent
-       implementations from the specification (one in C by Marc
-       Horowitz, and another in Scheme by Bill Sommerfeld) agree on
-       a value different from that in [Blumenthal96].
-
-   [6] For example, in MIT's implementation of [Kerb1510], the rsa-
-       md5 unkeyed checksum of application data may be included in
-       an authenticator encrypted in a service's key; since rsa-md5
-       is believed to be collision-proof, even if the application
-       data is exposed to an attacker, it cannot be modified without
-       causing the checksum verification to fail.
-
-   [7] A variant of the key is used to limit the use of a key to a
-       particular function, separating the functions of generating a
-       checksum from other encryption performed using the session
-       key.  The constant 0xF0F0F0F0F0F0F0F0 was chosen because it
-       maintains key parity.  The properties of DES precluded the
-       use of the complement.  The same constant is used for similar
-       purpose in the Message Integrity Check in the Privacy
-       Enhanced Mail standard.
-
-   [8] Perhaps one of the more common reasons for directly
-       performing encryption is direct control over the negotiation
-       and to select a "sufficiently strong" encryption algorithm
-       (whatever that means in the context of a given application).
-       While Kerberos directly provides no facility for negotiating
-       encryption types between the application client and server,
-       there are other means for accomplishing similar goals.  For
-       example, requesting only "strong" session key types from the
-       KDC, and assuming that the type actually returned by the KDC
-       will be understood and supported by the application server.
-
-Normative References
-
-   [Bellare98]
-      Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway,
-      "Relations Among Notions of Security for Public-Key Encryption
-      Schemes".  Extended abstract published in Advances in Cryptology-
-      Crypto 98 Proceedings, Lecture Notes in Computer Science Vol.
-      1462, H. Krawcyzk ed., Springer-Verlag, 1998.
-
-
-
-
-
-Raeburn                                                        [Page 47]
-
-INTERNET DRAFT                                              October 2003
-
-
-   [Blumenthal96]
-      Blumenthal, U., and S. Bellovin, "A Better Key Schedule for DES-
-      Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996.
-   [CRC]
-      International Organization for Standardization, "ISO Information
-      Processing Systems - Data Communication - High-Level Data Link
-      Control Procedure - Frame Structure," IS 3309, 3rd Edition,
-      October 1984.
-   [DES77]
-      National Bureau of Standards, U.S. Department of Commerce, "Data
-      Encryption Standard," Federal Information Processing Standards
-      Publication 46, Washington, DC, 1977.
-   [DESI81]
-      National Bureau of Standards, U.S. Department of Commerce,
-      "Guidelines for implementing and using NBS Data Encryption
-      Standard," Federal Information Processing Standards Publication
-      74, Washington, DC, 1981.
-   [DESM80]
-      National Bureau of Standards, U.S. Department of Commerce, "DES
-      Modes of Operation," Federal Information Processing Standards
-      Publication 81, Springfield, VA, December 1980.
-   [Dolev91]
-      Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography",
-      Proceedings of the 23rd Annual Symposium on Theory of Computing,
-      ACM, 1991.
-   [HMAC]
-      Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
-      for Message Authentication", RFC 2104, February 1997.
-   [KRB5-AES]
-      Raeburn, K., "AES Encyrption for Kerberos 5", RFC XXXX, Xxxxxxxx
-      2003.
-   [MD4-92]
-      Rivest, R., "The MD4 Message Digest Algorithm," RFC 1320, MIT
-      Laboratory for Computer Science, April 1992.
-   [MD5-92]
-      Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321, MIT
-      Laboratory for Computer Science, April 1992.
-   [RFC2026]
-      Bradner, S., "The Internet Standards Process -- Revisions 3," RFC
-      2026, October 1996.
-   [SG92]
-      Stubblebine, S., and V. D. Gligor, "On Message Integrity in
-      Cryptographic Protocols," in Proceedings of the IEEE Symposium on
-      Research in Security and Privacy, Oakland, California, May 1992.
-
-
-
-
-
-
-
-Raeburn                                                        [Page 48]
-
-INTERNET DRAFT                                              October 2003
-
-
-Informative References
-
-   [Bellovin91]
-      Bellovin, S. M., and M. Merrit, "Limitations of the Kerberos
-      Authentication System", in Proceedings of the Winter 1991 Usenix
-      Security Conference, January, 1991.
-   [Bellovin99]
-      Bellovin, S. M., and D. Atkins, private communications, 1999.
-   [EFF-DES]
-      Electronic Frontier Foundation, "Cracking DES: Secrets of
-      Encryption Research, Wiretap Politics, and Chip Design", O'Reilly
-      & Associates, Inc., May 1998.
-   [ESP-DES]
-      Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm
-      With Explicit IV", RFC 2405, November 1998.
-   [GSS-KRB5]
-      Linn, J., "The Kerberos Version 5 GSS-API Mechanism," RFC 1964,
-      June 1996.
-   [HMAC-TEST]
-      Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",
-      RFC 2202, September 1997.
-   [IPSEC-HMAC]
-      Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and
-      AH", RFC 2404, November 1998.
-   [Kerb]
-      Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K.
-      Raeburn, "The Kerberos Network Authentication Service (V5)",
-      draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22,
-      2002.  Work in progress.
-   [Kerb1510]
-      Kohl, J., and C. Neuman, "The Kerberos Network Authentication
-      Service (V5)", RFC 1510, September 1993.
-   [RC5]
-      Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
-      RC5-CTS Algorithms", RFC 2040, October 1996.
-   [Schneier96]
-      Schneier, B., "Applied Cryptography Second Edition", John Wiley &
-      Sons, New York, NY, 1996.  ISBN 0-471-12845-7.
-
-Editor's address
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-   raeburn@mit.edu
-
-
-
-
-
-Raeburn                                                        [Page 49]
-
-INTERNET DRAFT                                              October 2003
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-Notes to RFC Editor
-
-   Before publication of this document as an RFC, the following changes
-   are needed:
-
-   Change the reference "[KRB5-AES]" in Normative References to indicate
-   the AES draft (draft-raeburn-krb-rijndael-krb-XX) that should be
-   advancing to RFC at the same time.  The RFC number and publication
-   date are needed.
-
-   If draft-ietf-krb-wg-kerberos-clarifications advances to RFC at the
-   same time as this document, change the information for [Kerb] in the
-   Informative References section as well.
-
-   Change the first-page headers to indicate the RFC number, network
-   working group, etc, as appropriate for an RFC instead of an I-D.
-
-   Remove the contact-info paragraph from the Abstract.
-
-   Delete this section.
-
-
-
-Raeburn                                                        [Page 50]
diff --git a/doc/standardisation/draft-ietf-krb-wg-crypto-07.txt b/doc/standardisation/draft-ietf-krb-wg-crypto-07.txt
deleted file mode 100644
index 7909c3743..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-crypto-07.txt
+++ /dev/null
@@ -1,2858 +0,0 @@
-
-
-
-
-
-
-
-
-
-INTERNET DRAFT                                                K. Raeburn
-Kerberos Working Group                                               MIT
-Document: draft-ietf-krb-wg-crypto-07.txt              February 10, 2004
-                                                 expires August 10, 2004
-
-                 Encryption and Checksum Specifications
-                             for Kerberos 5
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026 [RFC2026].  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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.html.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-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.  Several mechanisms
-   are also defined in this document.  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".
-
-   Comments should be sent to the editor, or to the IETF Kerberos
-   working group (ietf-krb-wg@anl.gov).
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 1]
-
-INTERNET DRAFT                                             February 2004
-
-
-                           1mTable of Contents0m
-
-
-Status of this Memo  . . . . . . . . . . . . . . . . . . . . . . . .   1
-Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
-Table of Contents  . . . . . . . . . . . . . . . . . . . . . . . . .   2
-1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
-2. Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
-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 . . . . . . . . . . . . . . . . . . .  11
-5.2. Simplified profile parameters . . . . . . . . . . . . . . . . .  13
-5.3. Cryptosystem profile based on simplified profile  . . . . . . .  14
-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
-8. Assigned Numbers  . . . . . . . . . . . . . . . . . . . . . . . .  31
-9. Implementation Notes  . . . . . . . . . . . . . . . . . . . . . .  33
-10. Security Considerations  . . . . . . . . . . . . . . . . . . . .  33
-11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . .  35
-12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . .  36
-A. Test vectors  . . . . . . . . . . . . . . . . . . . . . . . . . .  37
-A.1. n-fold  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  37
-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 . . . . . . . . . . . . . . . . . . . . . . . .  45
-B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . . .  45
-Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  46
-Intellectual Property Statement  . . . . . . . . . . . . . . . . . .  47
-Normative References . . . . . . . . . . . . . . . . . . . . . . . .  48
-Informative References . . . . . . . . . . . . . . . . . . . . . . .  49
-Editor's address . . . . . . . . . . . . . . . . . . . . . . . . . .  50
-Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . .  50
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 2]
-
-INTERNET DRAFT                                             February 2004
-
-
-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 any
-   specific encryption algorithm be used, as long as certain operations
-   are available in the algorithm that is used.
-
-   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.  Test vectors for several
-   functions are given in appendix A.
-
-2. Concepts
-
-   Both encryption and checksum mechanisms are defined in terms of
-   profiles, detailed in later sections.  Each 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.  (Integrity checking may be
-   achieved by incorporating a checksum, if the encryption mode does not
-   provide an integrity check itself.)  It must also provide non-
-   malleability [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 knowledge of 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.  It should be infeasible
-   to find two plaintexts which have the same checksum.  It is NOT
-   required that an eavesdropper be unable to determine if two checksums
-   are for the same message; it is assumed that the messages themselves
-   will be visible to any such eavesdropper.
-
-   Due to advances in cryptography, it is considered unwise by some
-   cryptographers to use the same key for multiple purposes.  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.
-
-
-
-
-Raeburn                                                         [Page 3]
-
-INTERNET DRAFT                                             February 2004
-
-
-   We do this by enumerating the different uses of keys within Kerberos,
-   and making the "usage number" an input to the encryption or checksum
-   mechanisms; this enumeration is outside the scope of this document.
-   Later sections of this document 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" to be used for a particular instance of encryption or
-   checksum operations.  It is expected but not required that the
-   specific key will 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 8-bit
-   bytes.  Environments with other byte sizes will have to emulate this
-   behavior in order to get correct results.
-
-   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 what 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 specific values that are not valid or desirable
-      for use; such values should be avoid by all key generation
-      routines.
-
-
-
-Raeburn                                                         [Page 4]
-
-INTERNET DRAFT                                             February 2004
-
-
-   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 has been decided upon, the corresponding checksum
-      mechanism can simply 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 generation
-      of keys that significantly compromise the confidentiality of
-      encrypted data, if the cryptosystem has such.  Entropy from each
-      source should be preserved as much as possible.  Many of the
-      inputs, while 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 timestamps); 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 normally the
-         principal's pass phrase, but is in general 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.  While 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.
-
-
-
-
-Raeburn                                                         [Page 5]
-
-INTERNET DRAFT                                             February 2004
-
-
-         The third argument, the octet string, may be used to pass
-         mechanism-specific parameters in to this function.  Since doing
-         so implies knowledge of the specific encryption system, it is
-         intended that generating non-default parameter values be an
-         uncommon operation, and that normal Kerberos applications 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
-         the user's key in another realm, 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.  It may be assumed that all the bits of the
-         input string are 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; the usage values must be assumed to be known
-         to an attacker.  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
-      the user's password.  It may be desirable to construct the
-      encoding such that values weakening the resulting key unacceptably
-      cannot be encoded, if practical.
-
-      Tighter bounds might be permitted by local security policy, or to
-      avoid excess resource consumption; if so, recommended defaults for
-      those bounds should be given in the specification.  The
-      description should also outline possible weaknesses that may be
-      caused by not applying bounds checks or other validation to a
-      parameter string received from the network.
-
-      As mentioned above, this should be considered opaque to most
-      normal applications.
-
-
-
-
-
-
-Raeburn                                                         [Page 6]
-
-INTERNET DRAFT                                             February 2004
-
-
-   default string-to-key parameters (octet string)
-      This default value for the "params" argument to the string-to-key
-      function is to be used when the application protocol (Kerberos or
-      otherwise) does not explicitly set the parameter value.  As
-      indicated above, this parameter block should be treated as an
-      opaque object in most cases.
-
-   cipher state
-      This describes any information that can be carried over from one
-      encryption or decryption operation to the next, for use in
-      conjunction 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 as
-      to require that messages be decrypted in the same order they were
-      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.
-
-      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
-
-
-
-Raeburn                                                         [Page 7]
-
-INTERNET DRAFT                                             February 2004
-
-
-      implementations permit the setting of the initial vector.  This
-      framework does not provide for application control of the cipher
-      state (beyond "initialize" and "carry over from previous
-      encryption"), since 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 that they can
-      control 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 (as DES in CBC
-      mode does not do), then some form of MAC or checksum must be
-      included that can be verified by the receiver.  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 not only
-      indicate the precise contents of the output octet string, but also
-      the output cipher state.  The application protocol may carry
-      forward the output cipher state from one encryption with a given
-      specific key to another; the effect of this "chaining" must be
-      defined.  [2]
-
-      Assuming correctly-produced values for the specific key and cipher
-      state, no input octet string may result in an error indication.
-
-   decrypt (specific-key, state, octet string)->(state, octet string)
-      This function takes the specific key, cipher state, and ciphertext
-      as inputs, and verifies the integrity of the supplied ciphertext.
-      If the ciphertext's integrity is intact, this function produces
-      the plaintext and a new cipher state as outputs; otherwise, an
-      error indication must be returned, and the data discarded.
-
-      The result of the decryption may be longer than the original
-      plaintext, for example if the encryption mode adds padding to
-      reach a multiple of a block size.  If this is the case, any extra
-      octets must be after the decoded plaintext.  An application
-      protocol which needs to know the exact length of the message must
-
-
-
-Raeburn                                                         [Page 8]
-
-INTERNET DRAFT                                             February 2004
-
-
-      encode a length or recognizable "end of message" marker within the
-      plaintext.  [3]
-
-      As with the encryption function, a correct specification for this
-      function must indicate not only the contents of the output octet
-      string, but also the resulting cipher state.
-
-   pseudo-random (protocol-key, octet-string)->(octet-string)
-      This pseudo-random function should generate an octet string of
-      some size that independent of the octet string input.  The PRF
-      output string should be suitable for use in key generation, even
-      if the octet string input is public.  It should not reveal the
-      input key, even if the output is made public.
-
-   These operations and attributes are all that is required to support
-   Kerberos and various proposed preauthentication schemes.
-
-   For convenience of certain application protocols that may wish to use
-   the encryption profile, we add the constraint that, for any given
-   plaintext input size, there must be a message size between that given
-   size and that size plus 65535 such that the length of such that the
-   decrypted version of the ciphertext for any message of that size will
-   never have extra octets added at the end.
-
-   Expressed mathematically, for every message length L1, there exists a
-   message size L2 such that:
-
-     L2 >= L1
-     L2 < L1 + 65536
-     for every message M with |M| = L2, decrypt(encrypt(M)) = M
-
-   A document defining a new encryption type should also describe known
-   weaknesses or attacks, so that its security may be fairly assessed,
-   and should include test vectors or other validation procedures for
-   the operations defined.  Specific references to information readily
-   available elsewhere are sufficient.
-
-4. Checksum algorithm profile
-
-   A checksum mechanism profile must define the following attributes and
-   operations:
-
-   associated encryption algorithm(s)
-      This indicates the types of encryption keys this checksum
-      mechanism can be used with.
-
-      A keyed checksum mechanism may have more than one associated
-      encryption algorithm if they share the same wire key format,
-
-
-
-Raeburn                                                         [Page 9]
-
-INTERNET DRAFT                                             February 2004
-
-
-      string-to-key function, and key derivation function. (This
-      combination means that, for example, a checksum type, key usage
-      value and password are adequate to get the specific key used to
-      compute a checksum.)
-
-      An unkeyed checksum mechanism can be used in conjunction with any
-      encryption type, since the key is ignored, but its use must be
-      limited to cases where the checksum itself is protected, to avoid
-      trivial attacks.
-
-   get_mic function
-      This function generates a MIC token for a given specific key (see
-      section 3), and message (represented as an octet string), that may
-      be used to verify the integrity of the associated message.  This
-      function is not required to return the same deterministic result
-      on every use; it need only generate a token that the verify_mic
-      routine can check.
-
-      The output of this function will also dictate the size of the
-      checksum.  It must be no larger than 65535 octets.
-
-   verify_mic function
-      Given a specific key, message, and MIC token, this function
-      ascertains whether the message integrity has been compromised.
-      For a deterministic get_mic routine, the corresponding verify_mic
-      may simply generate another checksum and compare them.
-
-   The get_mic and verify_mic operations must be able to handle inputs
-   of arbitrary length; if any padding is needed, the padding scheme
-   must be specified as part of these functions.
-
-   These operations and attributes are all that should be required to
-   support Kerberos and various proposed preauthentication schemes.
-
-   As with encryption mechanism definition documents, documents defining
-   new checksum mechanisms should indicate validation processes and
-   known weaknesses.
-
-5. Simplified profile for CBC ciphers with key derivation
-
-   The profile outlines in sections 3 and 4 describes a large number of
-   operations that must be defined for encryption and checksum
-   algorithms to be used with Kerberos.  We describe here a simpler
-   profile from which both encryption and checksum mechanism definitions
-   can be generated, filling in uses of key derivation in appropriate
-   places, providing integrity protection, and defining multiple
-   operations for the cryptosystem profile based on a smaller set of
-   operations given in the simplified profile.  Not all of the existing
-
-
-
-Raeburn                                                        [Page 10]
-
-INTERNET DRAFT                                             February 2004
-
-
-   cryptosystems for Kerberos fit into this simplified profile, but we
-   recommend that future cryptosystems use it or something based on it.
-   [4]
-
-   Not all of the operations in the complete profiles are defined
-   through this mechanism; several must still be defined for each new
-   algorithm pair.
-
-5.1. A key derivation function
-
-   Rather than define some scheme by which a "protocol key" is composed
-   of a large number of encryption keys, we use keys derived from a base
-   key to perform cryptographic operations.  The base key must be used
-   only for generating the derived keys, and this derivation must be
-   non-invertible and entropy-preserving.  Given these restrictions,
-   compromise of one derived key does not compromise the other subkeys.
-   Attack of the base key is limited, since it is only used for
-   derivation, and is not exposed to any user data.
-
-   Since the derived key has as much entropy as the base keys (if the
-   cryptosystem is good), password-derived keys have the full benefit of
-   all the entropy in the password.
-
-   To generate a derived key from a base key, we generate a pseudorandom
-   octet string, using an algorithm DR described below, and generate a
-   key from that octet string using a function dependent on the
-   encryption algorithm; the input length needed for that function,
-   which is also dependent on the encryption algorithm, dictates the
-   length of the string to be generated by the DR algorithm (the value
-   "k" below).  These procedures are based on the key derivation in
-   [Blumenthal96].
-
-      Derived Key = DK(Base Key, Well-Known Constant)
-
-      DK(Key, Constant) = random-to-key(DR(Key, Constant))
-
-      DR(Key, Constant) = k-truncate(E(Key, Constant,
-                                       initial-cipher-state))
-
-   Here DR is the random-octet generation function described below, and
-   DK is the key-derivation function produced from it.  In this
-   construction, E(Key, Plaintext, CipherState) is a cipher, Constant is
-   a well-known constant determined by the specific usage of this
-   function, and k-truncate truncates its argument by taking the first k
-   bits.  Here, k is the key generation seed length needed for the
-   encryption system.
-
-   The output of the DR function is a string of bits; the actual key is
-
-
-
-Raeburn                                                        [Page 11]
-
-INTERNET DRAFT                                             February 2004
-
-
-   produced by applying the cryptosystem's random-to-key operation on
-   this bitstring.
-
-   If the Constant is smaller than the cipher block size of E, then it
-   must be expanded with n-fold() so it can be encrypted.  If the output
-   of E is shorter than k bits it is fed back into the encryption as
-   many times as necessary.  The construct is as follows (where |
-   indicates concatentation):
-
-      K1 = E(Key, n-fold(Constant), initial-cipher-state)
-      K2 = E(Key, K1, initial-cipher-state)
-      K3 = E(Key, K2, initial-cipher-state)
-      K4 = ...
-
-      DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
-
-   n-fold is an algorithm which takes m input bits and ``stretches''
-   them to form n output bits with equal contribution from each input
-   bit to the output, as described in [Blumenthal96]:
-
-      We first define a primitive called n-folding, which takes a
-      variable-length input block and produces a fixed-length output
-      sequence.  The intent is to give each input bit approximately
-      equal weight in determining the value of each output bit.  Note
-      that whenever we need to treat a string of octets as a number, the
-      assumed representation is Big-Endian -- Most Significant Byte
-      first.
-
-      To n-fold a number X, replicate the input value to a length that
-      is the least common multiple of n and the length of X.  Before
-      each repetition, the input is rotated to the right by 13 bit
-      positions.  The successive n-bit chunks are added together using
-      1's-complement addition (that is, with end-around carry) to yield
-      a n-bit result....
-
-
-   Test vectors for n-fold are supplied in Appendix A.  [5]
-
-   In this section, n-fold is always used to produce c bits of output,
-   where c is the cipher block size of E.
-
-   The size of the Constant must not be larger than c, because reducing
-   the length of the Constant by n-folding can cause collisions.
-
-   If the size of the Constant is smaller than c, then the Constant must
-   be n-folded to length c.  This string is used as input to E.  If the
-   block size of E is less than the random-to-key input size, then the
-   output from E is taken as input to a second invocation of E.  This
-
-
-
-Raeburn                                                        [Page 12]
-
-INTERNET DRAFT                                             February 2004
-
-
-   process is repeated until the number of bits accumulated is greater
-   than or equal to the random-to-key input size.  When enough bits have
-   been computed, the first k are taken as the random data used to
-   create the key with the algorithm-dependent random-to-key function.
-
-   Since the derived key is the result of one or more encryptions in the
-   base key, deriving the base key from the derived key is equivalent to
-   determining the key from a very small number of plaintext/ciphertext
-   pairs.  Thus, this construction is as strong as the cryptosystem
-   itself.
-
-5.2. Simplified profile parameters
-
-   These are the operations and attributes that must be defined:
-
-   protocol key format
-   string-to-key function
-   default string-to-key parameters
-   key-generation seed length, k
-   random-to-key function
-      As above for the normal encryption mechanism profile.
-
-   unkeyed hash algorithm, H
-      This should be a collision-resistant hash algorithm with fixed-
-      size output, suitable for use in an HMAC [HMAC].  It must support
-      inputs of arbitrary length.  Its output must be at least the
-      message block size (below).
-
-   HMAC output size, h
-      This indicates the size of the leading substring output by the
-      HMAC function that should be used in transmitted messages.  It
-      should be at least half the output size of the hash function H,
-      and at least 80 bits; it need not match the output size.
-
-   message block size, m
-      This is the size of the smallest units the cipher can handle in
-      the mode in which it is being used.  Messages will be padded to a
-      multiple of this size.  If a block cipher is used in a mode that
-      can handle messages that are not multiples of the cipher block
-      size, such as CBC mode with cipher text stealing (CTS, see [RC5]),
-      this value would be one octet.  For traditional CBC mode with
-      padding, it will be the underlying cipher's block size.
-
-      This value must be a multiple of 8 bits (one octet).
-
-
-
-
-
-
-
-Raeburn                                                        [Page 13]
-
-INTERNET DRAFT                                             February 2004
-
-
-   encryption/decryption functions, E and D
-      These are basic encryption and decryption functions for messages
-      of sizes that are multiples of the message block size.  No
-      integrity checking or confounder should be included here.  These
-      functions take as input the IV or similar data, a protocol-format
-      key, and a octet string, returning a new IV and octet string.
-
-      The encryption function is not required to use CBC mode, but is
-      assumed to be using something with similar properties.  In
-      particular, prepending a cipher-block-size confounder to the
-      plaintext should alter the entire ciphertext (comparable to
-      choosing and including a random initial vector for CBC mode).
-
-      The result of encrypting one cipher block (of size c, above) must
-      be deterministic, for the random octet generation function DR in
-      the previous section to work.  For best security, it should also
-      be no larger than c.
-
-   cipher block size, c
-      This is the block size of the block cipher underlying the
-      encryption and decryption functions indicated above, used for key
-      derivation and for the size of the message confounder and initial
-      vector.  (If a block cipher is not in use, some comparable
-      parameter should be determined.)  It must be at least 5 octets.
-
-      This is not actually an independent parameter; rather, it is a
-      property of the functions E and D.  It is listed here to clarify
-      the distinction between it and the message block size, m.
-
-   While there are still a number of properties to specify, they are
-   fewer and simpler than in the full profile.
-
-5.3. Cryptosystem profile based on simplified profile
-
-   The above key derivation function is used to produce three
-   intermediate keys.  One is used for computing checksums of
-   unencrypted data.  The other two are used for encrypting and
-   checksumming plaintext to be sent encrypted.
-
-   The ciphertext output is the concatenation of the output of the basic
-   encryption function E and a (possibly truncated) HMAC using the
-   specified hash function H, both applied to the plaintext with a
-   random confounder prefix and sufficient padding to bring it to a
-   multiple of the message block size.  When the HMAC is computed, the
-   key is used in the protocol key form.
-
-   Decryption is performed by removing the (partial) HMAC, decrypting
-   the remainder, and verifying the HMAC.  The cipher state is an
-
-
-
-Raeburn                                                        [Page 14]
-
-INTERNET DRAFT                                             February 2004
-
-
-   initial vector, initialized to zero.
-
-   The substring notation "[1..h]" in the following table should be read
-   as using 1-based indexing; leading substrings are used.
-
-
-                   cryptosystem from simplified profile
-----------------------------------------------------------------------------
-protocol key format       As given.
-
-specific key structure    Three protocol-format keys: { Kc, Ke, Ki }.
-
-key-generation seed       As given.
-length
-
-required checksum         As defined below in section 5.4.
-mechanism
-
-cipher state              initial vector (usually of length c)
-
-initial cipher state      all bits zero
-
-encryption function       conf = random string of length c
-                          pad = shortest string to bring confounder
-                                and plaintext to a length that's a
-                                multiple of m
-                          (C1, newIV) = E(Ke, conf | plaintext | pad,
-                                          oldstate.ivec)
-                          H1 = HMAC(Ki, conf | plaintext | pad)
-                          ciphertext =  C1 | H1[1..h]
-                          newstate.ivec = newIV
-
-decryption function       (C1,H1) = ciphertext
-                          (P1, newIV) = D(Ke, C1, oldstate.ivec)
-                          if (H1 != HMAC(Ki, P1)[1..h])
-                             report error
-                          newstate.ivec = newIV
-
-default string-to-key     As given.
-params
-
-pseudo-random function    tmp1 = H(octet-string)
-                          tmp2 = truncate tmp1 to multiple of m
-                          PRF = E(protocol-key, tmp2, initial-cipher-state)
-
-key generation functions:
-
-
-
-
-
-Raeburn                                                        [Page 15]
-
-INTERNET DRAFT                                             February 2004
-
-
-                   cryptosystem from simplified profile
-----------------------------------------------------------------------------
-string-to-key function    As given.
-
-random-to-key function    As given.
-
-key-derivation function   The "well-known constant" used for the DK
-                          function is the key usage number, expressed as
-                          four octets in big-endian order, followed by one
-                          octet indicated below.
-
-                          Kc = DK(base-key, usage | 0x99);
-                          Ke = DK(base-key, usage | 0xAA);
-                          Ki = DK(base-key, usage | 0x55);
-
-
-5.4. Checksum profiles based on simplified profile
-
-   When an encryption system is defined using the simplified profile
-   given in section 5.2, a checksum algorithm may be defined for it as
-   follows:
-
-
-                checksum mechanism from simplified profile
-             --------------------------------------------------
-             associated cryptosystem   as defined above
-
-             get_mic                   HMAC(Kc, message)[1..h]
-
-             verify_mic                get_mic and compare
-
-   The HMAC function and key Kc are as described in section 5.3.
-
-6. Profiles for Kerberos encryption and checksum algorithms
-
-   These profiles describe the encryption and checksum systems defined
-   for Kerberos.  The astute reader will notice that some of them do not
-   fulfull all of the requirements outlined in previous sections.  These
-   systems are defined for backward compatibility; newer implementations
-   should (whenever possible) attempt to make use of encryption systems
-   which satisfy all of the profile requirements.
-
-   The full list of current encryption and checksum type number
-   assignments, including values currently reserved but not defined in
-   this document, is given in section 8.
-
-
-
-
-
-
-Raeburn                                                        [Page 16]
-
-INTERNET DRAFT                                             February 2004
-
-
-6.1. Unkeyed checksums
-
-   These checksum types use no encryption keys, and thus can be used in
-   combination with any encryption type, but may only be used with
-   caution, in limited circumstances where the lack of a key does not
-   provide a window for an attack, preferably as part of an encrypted
-   message.  [6] Keyed checksum algorithms are recommended.
-
-6.1.1. The RSA MD5 Checksum
-
-   The RSA-MD5 checksum calculates a checksum using the RSA MD5
-   algorithm [MD5-92].  The algorithm takes as input an input message of
-   arbitrary length and produces as output a 128-bit (16 octet)
-   checksum.  RSA-MD5 is believed to be collision-proof.
-
-                                  rsa-md5
-               ----------------------------------------------
-               associated cryptosystem   any
-
-               get_mic                   rsa-md5(msg)
-
-               verify_mic                get_mic and compare
-
-   The rsa-md5 checksum algorithm is assigned a checksum type number of
-   seven (7).
-
-6.1.2. The RSA MD4 Checksum
-
-   The RSA-MD4 checksum calculates a checksum using the RSA MD4
-   algorithm [MD4-92].  The algorithm takes as input an input message of
-   arbitrary length and produces as output a 128-bit (16 octet)
-   checksum.  RSA-MD4 is believed to be collision-proof.
-
-
-                                  rsa-md4
-               ----------------------------------------------
-               associated cryptosystem   any
-
-               get_mic                   md4(msg)
-
-               verify_mic                get_mic and compare
-
-
-   The rsa-md4 checksum algorithm is assigned a checksum type number of
-   two (2).
-
-
-
-
-
-
-Raeburn                                                        [Page 17]
-
-INTERNET DRAFT                                             February 2004
-
-
-6.1.3. CRC-32 Checksum
-
-   This CRC-32 checksum calculates a checksum based on a cyclic
-   redundancy check as described in ISO 3309 [CRC], modified as
-   described below.  The resulting checksum is four (4) octets in
-   length.  The CRC-32 is neither keyed nor collision-proof; thus, the
-   use of this checksum is not recommended.  An attacker using a
-   probabilistic chosen-plaintext attack as described in [SG92] might be
-   able to generate an alternative message that satisfies the checksum.
-
-   The CRC-32 checksum used in the des-cbc-crc encryption mode is
-   identical to the 32-bit FCS described in ISO 3309 with two
-   exceptions: the sum with the all-ones polynomial times x**k is
-   omitted, and the final remainder is not ones-complemented.  ISO 3309
-   describes the FCS in terms of bits, while this document describes the
-   Kerberos protocol in terms of octets.  To disambiguate the ISO 3309
-   definition for the purpose of computing the CRC-32 in the des-cbc-crc
-   encryption mode, the ordering of bits in each octet shall be assumed
-   to be LSB-first.  Given this assumed ordering of bits within an
-   octet, the mapping of bits to polynomial coefficients shall be
-   identical to that specified in ISO 3309.
-
-   Test values for this modified CRC function are included in appendix
-   A.5.
-
-
-                                   crc32
-               ----------------------------------------------
-               associated cryptosystem   any
-
-               get_mic                   crc32(msg)
-
-               verify_mic                get_mic and compare
-
-
-   The crc32 checksum algorithm is assigned a checksum type number of
-   one (1).
-
-6.2. DES-based encryption and checksum types
-
-   These encryption systems encrypt information under the Data
-   Encryption Standard [DES77] using the cipher block chaining mode
-   [DESM80].  A checksum is computed as described below and placed in
-   the cksum field.  DES blocks are 8 bytes.  As a result, the data to
-   be encrypted (the concatenation of confounder, checksum, and message)
-   must be padded to an 8 byte boundary before encryption.  The values
-   of the padding bytes are unspecified.
-
-
-
-
-Raeburn                                                        [Page 18]
-
-INTERNET DRAFT                                             February 2004
-
-
-   Plaintext and DES ciphertext are encoded as blocks of 8 octets which
-   are concatenated to make the 64-bit inputs for the DES algorithms.
-   The first octet supplies the 8 most significant bits (with the
-   octet's MSB used as the DES input block's MSB, etc.), the second
-   octet the next 8 bits, ..., and the eighth octet supplies the 8 least
-   significant bits.
-
-   Encryption under DES using cipher block chaining requires an
-   additional input in the form of an initialization vector; this vector
-   is specified for each encryption system, below.
-
-   The DES specifications [DESI81] identify four 'weak' and twelve
-   'semi-weak' keys; those keys SHALL NOT be used for encrypting
-   messages for use in Kerberos.  The "variant keys" generated for the
-   RSA-MD5-DES, RSA-MD4-DES and DES-MAC checksum types by an exclusive-
-   or of a DES key with a constant are not checked for this property.
-
-   A DES key is 8 octets of data.  This consists of 56 bits of actual
-   key data, and 8 parity bits, one per octet.  The key is encoded as a
-   series of 8 octets written in MSB-first order.  The bits within the
-   key are also encoded in MSB order.  For example, if the encryption
-   key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8)
-   where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8
-   are the parity bits, the first octet of the key would be
-   B1,B2,...,B7,P1 (with B1 as the most significant bit).  See the
-   [DESM80] introduction for reference.
-
-   Encryption data format
-
-   The format for the data to be encrypted includes a one-block
-   confounder, a checksum, the encoded plaintext, and any necessary
-   padding, as described in the following diagram.  The msg-seq field
-   contains the part of the protocol message which is to be encrypted.
-
-                  +-----------+----------+---------+-----+
-                  |confounder | checksum | msg-seq | pad |
-                  +-----------+----------+---------+-----+
-
-   One generates a random confounder of one block, placing it in
-   'confounder'; zeroes out the 'checksum' field (of length appropriate
-   to exactly hold the checksum to be computed); calculates the
-   appropriate checksum over the whole sequence, placing the result in
-   'checksum'; adds the necessary padding; then encrypts using the
-   specified encryption type and the appropriate key.
-
-   String or random-data to key transformation
-
-   To generate a DES key from two UTF-8 text strings (password and
-
-
-
-Raeburn                                                        [Page 19]
-
-INTERNET DRAFT                                             February 2004
-
-
-   salt), the two strings are concatenated, password first, and the
-   result is then padded with zero-valued octets to a multiple of 8
-   octets.
-
-   The top bit of each octet (always zero if the password is plain
-   ASCII, as was assumed when the original specification was written) is
-   discarded, and a bitstring is formed of the remaining seven bits of
-   each octet.  This bitstring is then fan-folded and eXclusive-ORed
-   with itself to produce a 56-bit string.  An eight-octet key is formed
-   from this string, each octet using seven bits from the bitstring,
-   leaving the least significant bit unassigned.  The key is then
-   "corrected" by correcting the parity on the key, and if the key
-   matches a 'weak' or 'semi-weak' key as described in the DES
-   specification, it is eXclusive-ORed with the constant
-   0x00000000000000F0.  This key is then used to generate a DES CBC
-   checksum on the initial string with the salt appended.  The result of
-   the CBC checksum is then "corrected" as described above to form the
-   result which is returned as the key.
-
-   For purposes of the string-to-key function, the DES CBC checksum is
-   calculated by CBC encrypting a string using the key as IV and using
-   the final 8 byte block as the checksum.
-
-   Pseudocode follows:
-
-        removeMSBits(8byteblock) {
-          /* Treats a 64 bit block as 8 octets and remove the MSB in
-             each octect (in big endian mode) and concatenates the
-             result.  E.g., input octet string:
-                01110000 01100001 11110011  01110011 11110111 01101111
-                11110010 01100100
-             results in output bitstring:
-                1110000 1100001 1110011  1110011 1110111 1101111
-                1110010 1100100  */
-        }
-
-        reverse(56bitblock) {
-          /* Treats a 56-bit block as a binary string and reverse it.
-             E.g., input string:
-                1000001 1010100 1001000  1000101 1001110 1000001
-                0101110 1001101
-             results in output string:
-                1011001 0111010 1000001  0111001 1010001 0001001
-                0010101 1000001  */
-        }
-
-
-
-
-
-
-Raeburn                                                        [Page 20]
-
-INTERNET DRAFT                                             February 2004
-
-
-        add_parity_bits(56bitblock) {
-          /* Copies a 56-bit block into a 64-bit block, left shift
-             content in each octet and add DES parity bit.
-             E.g., input string:
-                1100000 0001111 0011100  0110100 1000101 1100100
-                0110110 0010111
-             results in output string:
-                11000001 00011111 00111000  01101000 10001010 11001000
-                01101101 00101111  */
-        }
-
-        key_correction(key) {
-             fixparity(key);
-             if (is_weak_key(key))
-                  key = key XOR 0xF0;
-             return(key);
-        }
-
-        mit_des_string_to_key(string,salt) {
-             odd = 1;
-             s = string | salt;
-             tempstring = 0; /* 56-bit string */
-             pad(s); /* with nulls to 8 byte boundary */
-             for (8byteblock in s) {
-                  56bitstring = removeMSBits(8byteblock);
-                  if (odd == 0) reverse(56bitstring);
-                  odd = ! odd;
-                  tempstring = tempstring XOR 56bitstring;
-             }
-             tempkey = key_correction(add_parity_bits(tempstring));
-             key = key_correction(DES-CBC-check(s,tempkey));
-             return(key);
-        }
-
-        des_string_to_key(string,salt,params) {
-             if (length(params) == 0)
-                  type = 0;
-             else if (length(params) == 1)
-                  type = params[0];
-             else
-                  error("invalid params");
-             if (type == 0)
-                  mit_des_string_to_key(string,salt);
-             else
-                  error("invalid params");
-        }
-
-   One common extension is to support the "AFS string-to-key" algorithm,
-
-
-
-Raeburn                                                        [Page 21]
-
-INTERNET DRAFT                                             February 2004
-
-
-   which is not defined here, if the type value above is one (1).
-
-   For generation of a key from a random bitstring, we start with a
-   56-bit string, and as with the string-to-key operation above, insert
-   parity bits, and if the result is a weak or semi-weak key, modify it
-   by exclusive-OR with the constart 0x00000000000000F0:
-
-        des_random_to_key(bitstring) {
-             return key_correction(add_parity_bits(bitstring));
-        }
-
-6.2.1. DES with MD5
-
-   The des-cbc-md5 encryption mode encrypts information under DES in CBC
-   mode with an all-zero initial vector, with an MD5 checksum (described
-   in [MD5-92]) computed and placed in the checksum field.
-
-   The encryption system parameters for des-cbc-md5 are:
-
-                                des-cbc-md5
-    --------------------------------------------------------------------
-    protocol key format      8 bytes, parity in low bit of each
-
-    specific key structure   copy of original key
-
-    required checksum        rsa-md5-des
-    mechanism
-
-    key-generation seed      8 bytes
-    length
-
-    cipher state             8 bytes (CBC initial vector)
-
-    initial cipher state     all-zero
-
-    encryption function      des-cbc(confounder | checksum | msg | pad,
-                                     ivec=oldstate)
-                             where
-                             checksum = md5(confounder | 0000...
-                                            | msg | pad)
-
-                             newstate = last block of des-cbc output
-
-    decryption function      decrypt encrypted text and verify checksum
-
-                             newstate = last block of ciphertext
-
-
-
-
-
-Raeburn                                                        [Page 22]
-
-INTERNET DRAFT                                             February 2004
-
-
-                                des-cbc-md5
-    --------------------------------------------------------------------
-    default string-to-key    empty string
-    params
-
-    pseudo-random function   des-cbc(md5(input-string), ivec=0)
-
-    key generation functions:
-
-    string-to-key            des_string_to_key
-
-    random-to-key            des_random_to_key
-
-    key-derivation           identity
-
-   The des-cbc-md5 encryption type is assigned the etype value three
-   (3).
-
-6.2.2. DES with MD4
-
-   The des-cbc-md4 encryption mode also encrypts information under DES
-   in CBC mode, with an all-zero initial vector.  An MD4 checksum
-   (described in [MD4-92]) is computed and placed in the checksum field.
-
-                                des-cbc-md4
-    --------------------------------------------------------------------
-    protocol key format      8 bytes, parity in low bit of each
-
-    specific key structure   copy of original key
-
-    required checksum        rsa-md4-des
-    mechanism
-
-    key-generation seed      8 bytes
-    length
-
-    cipher state             8 bytes (CBC initial vector)
-
-    initial cipher state     all-zero
-
-    encryption function      des-cbc(confounder | checksum | msg | pad,
-                                     ivec=oldstate)
-                             where
-                             checksum = md4(confounder | 0000...
-                                            | msg | pad)
-
-                             newstate = last block of des-cbc output
-
-
-
-
-Raeburn                                                        [Page 23]
-
-INTERNET DRAFT                                             February 2004
-
-
-                                des-cbc-md4
-    --------------------------------------------------------------------
-
-    decryption function      decrypt encrypted text and verify checksum
-
-                             newstate = last block of ciphertext
-
-    default string-to-key    empty string
-    params
-
-    pseudo-random function   des-cbc(md5(input-string), ivec=0)
-
-    key generation functions:
-
-    string-to-key            des_string_to_key
-
-    random-to-key            copy input, then fix parity bits
-
-    key-derivation           identity
-
-   Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
-
-   The des-cbc-md4 encryption algorithm is assigned the etype value two
-   (2).
-
-6.2.3. DES with CRC
-
-   The des-cbc-crc encryption type uses DES in CBC mode with the key
-   used as the initialization vector, with a 4-octet CRC-based checksum
-   computed as described in section 6.1.3.  Note that this is not a
-   standard CRC-32 checksum, but a slightly modified one.
-
-
-                                des-cbc-crc
-    --------------------------------------------------------------------
-    protocol key format      8 bytes, parity in low bit of each
-
-    specific key structure   copy of original key
-
-    required checksum        rsa-md5-des
-    mechanism
-
-    key-generation seed      8 bytes
-    length
-
-    cipher state             8 bytes (CBC initial vector)
-
-
-
-
-
-Raeburn                                                        [Page 24]
-
-INTERNET DRAFT                                             February 2004
-
-
-                                des-cbc-crc
-    --------------------------------------------------------------------
-    initial cipher state     copy of original key
-
-    encryption function      des-cbc(confounder | checksum | msg | pad,
-                                     ivec=oldstate)
-                             where
-                             checksum = crc(confounder | 00000000
-                                            | msg | pad)
-
-                             newstate = last block of des-cbc output
-
-    decryption function      decrypt encrypted text and verify checksum
-
-                             newstate = last block of ciphertext
-
-    default string-to-key    empty string
-    params
-
-    pseudo-random function   des-cbc(md5(input-string), ivec=0)
-
-    key generation functions:
-
-    string-to-key            des_string_to_key
-
-    random-to-key            copy input, then fix parity bits
-
-    key-derivation           identity
-
-   The des-cbc-crc encryption algorithm is assigned the etype value one
-   (1).
-
-6.2.4. RSA MD5 Cryptographic Checksum Using DES
-
-   The RSA-MD5-DES checksum calculates a keyed collision-proof checksum
-   by prepending an 8 octet confounder before the text, applying the RSA
-   MD5 checksum algorithm, and encrypting the confounder and the
-   checksum using DES in cipher-block-chaining (CBC) mode using a
-   variant of the key, where the variant is computed by eXclusive-ORing
-   the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0.  The
-   initialization vector should be zero.  The resulting checksum is 24
-   octets long.  This checksum is tamper-proof and believed to be
-   collision-proof.
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 25]
-
-INTERNET DRAFT                                             February 2004
-
-
-                                rsa-md5-des
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
-                                        conf | rsa-md5(conf | msg))
-
-      verify_mic                decrypt and verify rsa-md5 checksum
-
-
-   The rsa-md5-des checksum algorithm is assigned a checksum type number
-   of eight (8).
-
-6.2.5. RSA MD4 Cryptographic Checksum Using DES
-
-   The RSA-MD4-DES checksum calculates a keyed collision-proof checksum
-   by prepending an 8 octet confounder before the text, applying the RSA
-   MD4 checksum algorithm [MD4-92], and encrypting the confounder and
-   the checksum using DES in cipher-block-chaining (CBC) mode using a
-   variant of the key, where the variant is computed by eXclusive-ORing
-   the key with the constant 0xF0F0F0F0F0F0F0F0.  [7] The initialization
-   vector should be zero.  The resulting checksum is 24 octets long.
-   This checksum is tamper-proof and believed to be collision-proof.
-
-                                rsa-md4-des
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
-                                        conf | rsa-md4(conf | msg),
-                                        ivec=0)
-
-      verify_mic                decrypt and verify rsa-md4 checksum
-
-   The rsa-md4-des checksum algorithm is assigned a checksum type number
-   of three (3).
-
-6.2.6. RSA MD4 Cryptographic Checksum Using DES alternative
-
-   The RSA-MD4-DES-K checksum calculates a keyed collision-proof
-   checksum by applying the RSA MD4 checksum algorithm and encrypting
-   the results using DES in cipher block chaining (CBC) mode using a DES
-   key as both key and initialization vector.  The resulting checksum is
-   16 octets long.  This checksum is tamper-proof and believed to be
-   collision-proof.  Note that this checksum type is the old method for
-   encoding the RSA-MD4-DES checksum and it is no longer recommended.
-
-
-
-
-
-Raeburn                                                        [Page 26]
-
-INTERNET DRAFT                                             February 2004
-
-
-                               rsa-md4-des-k
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-cbc(key, md4(msg), ivec=key)
-
-      verify_mic                decrypt, compute checksum and compare
-
-
-   The rsa-md4-des-k checksum algorithm is assigned a checksum type
-   number of six (6).
-
-6.2.7. DES CBC checksum
-
-   The DES-MAC checksum is computed by prepending an 8 octet confounder
-   to the plaintext, padding with zero-valued octets if necessary to
-   bring the length to a multiple of 8 octets, performing a DES CBC-mode
-   encryption on the result using the key and an initialization vector
-   of zero, taking the last block of the ciphertext, prepending the same
-   confounder and encrypting the pair using DES in cipher-block-chaining
-   (CBC) mode using a variant of the key, where the variant is computed
-   by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0.  The
-   initialization vector should be zero.  The resulting checksum is 128
-   bits (16 octets) long, 64 bits of which are redundant.  This checksum
-   is tamper-proof and collision-proof.
-
-
-                                  des-mac
-   ----------------------------------------------------------------------
-   associated     des-cbc-md5, des-cbc-md4, des-cbc-crc
-   cryptosystem
-
-   get_mic        des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
-                          conf | des-mac(key, conf | msg | pad, ivec=0),
-                          ivec=0)
-
-   verify_mic     decrypt, compute DES MAC using confounder, compare
-
-
-   The des-mac checksum algorithm is assigned a checksum type number of
-   four (4).
-
-6.2.8. DES CBC checksum alternative
-
-   The DES-MAC-K checksum is computed by performing a DES CBC-mode
-   encryption of the plaintext, with zero-valued padding bytes if
-   necessary to bring the length to a multiple of 8 octets, and using
-   the last block of the ciphertext as the checksum value.  It is keyed
-
-
-
-Raeburn                                                        [Page 27]
-
-INTERNET DRAFT                                             February 2004
-
-
-   with an encryption key which is also used as the initialization
-   vector.  The resulting checksum is 64 bits (8 octets) long.  This
-   checksum is tamper-proof and collision-proof.  Note that this
-   checksum type is the old method for encoding the DESMAC checksum and
-   it is no longer recommended.
-
-
-                                 des-mac-k
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-mac(key, msg | pad, ivec=key)
-
-      verify_mic                compute MAC and compare
-
-
-   The des-mac-k checksum algorithm is assigned a checksum type number
-   of five (5).
-
-6.3. Triple-DES based encryption and checksum types
-
-   This encryption and checksum type pair is based on the Triple DES
-   cryptosystem in Outer-CBC mode, and the HMAC-SHA1 message
-   authentication algorithm.
-
-   A Triple DES key is the concatenation of three DES keys as described
-   above for des-cbc-md5.  A Triple DES key is generated from random
-   data by creating three DES keys from separate sequences of random
-   data.
-
-   Encrypted data using this type must be generated as described in
-   section 5.3.  If the length of the input data is not a multiple of
-   the block size, zero-valued octets must be used to pad the plaintext
-   to the next eight-octet boundary.  The confounder must be eight
-   random octets (one block).
-
-   The simplified profile for Triple DES, with key derivation as defined
-   in section 5, is as follows:
-
-                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
-              ------------------------------------------------
-              protocol key format     24 bytes, parity in low
-                                      bit of each
-
-              key-generation seed     21 bytes
-              length
-
-
-
-
-
-Raeburn                                                        [Page 28]
-
-INTERNET DRAFT                                             February 2004
-
-
-                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
-              ------------------------------------------------
-              hash function           SHA-1
-
-              HMAC output size        160 bits
-
-              message block size      8 bytes
-
-              default string-to-key   empty string
-              params
-
-              encryption and          triple-DES encrypt and
-              decryption functions    decrypt, in outer-CBC
-                                      mode (cipher block size
-                                      8 octets)
-
-              key generation functions:
-
-              random-to-key           DES3random-to-key (see
-                                      below)
-
-              string-to-key           DES3string-to-key (see
-                                      below)
-
-   The des3-cbc-hmac-sha1-kd encryption type is assigned the value
-   sixteen (16).  The hmac-sha1-des3-kd checksum algorithm is assigned a
-   checksum type number of twelve (12).
-
-6.3.1. Triple DES Key Production (random-to-key, string-to-key)
-
-   The 168 bits of random key data are converted to a protocol key value
-   as follows.  First, the 168 bits are divided into three groups of 56
-   bits, which are expanded individually into 64 bits as follows:
-
-   DES3random-to-key:
-         1  2  3  4  5  6  7  p
-         9 10 11 12 13 14 15  p
-        17 18 19 20 21 22 23  p
-        25 26 27 28 29 30 31  p
-        33 34 35 36 37 38 39  p
-        41 42 43 44 45 46 47  p
-        49 50 51 52 53 54 55  p
-        56 48 40 32 24 16  8  p
-
-   The "p" bits are parity bits computed over the data bits.  The output
-   of the three expansions, each corrected to avoid "weak" and "semi-
-   weak" keys as in section 6.2, are concatenated to form the protocol
-   key value.
-
-
-
-Raeburn                                                        [Page 29]
-
-INTERNET DRAFT                                             February 2004
-
-
-   The string-to-key function is used to transform UTF-8 passwords into
-   DES3 keys.  The DES3 string-to-key function relies on the "N-fold"
-   algorithm and DK function, described in section 5.
-
-   The n-fold algorithm is applied to the password string concatenated
-   with a salt value.  For 3-key triple DES, the operation will involve
-   a 168-fold of the input password string, to generate an intermediate
-   key, from which the user's long-term key will be derived with the DK
-   function.  The DES3 string-to-key function is shown here in
-   pseudocode:
-
-         DES3string-to-key(passwordString, salt, params)
-             if (params != emptyString)
-              error("invalid params");
-             s = passwordString + salt
-             tmpKey = random-to-key(168-fold(s))
-             key = DK (tmpKey, KerberosConstant)
-
-   Weak key checking is performed in the random-to-key and DK
-   operations.  The KerberosConstant value is the byte string {0x6b 0x65
-   0x72 0x62 0x65 0x72 0x6f 0x73}.  These values correspond to the ASCII
-   encoding for the string "kerberos".
-
-7. Use of Kerberos encryption outside this specification
-
-   Several Kerberos-based application protocols and preauthentication
-   systems have been designed and deployed that perform encryption and
-   message integrity checks in various ways.  While in some cases there
-   may be good reason for specifying these protocols in terms of
-   specific encryption or checksum algorithms, we anticipate that in
-   many cases this will not be true, and more generic approaches
-   independent of particular algorithms will be desirable.  Rather than
-   having each protocol designer reinvent schemes for protecting data,
-   using multiple keys, etc, we have attempted to present in this
-   section a general framework that should be sufficient not only for
-   the Kerberos protocol itself but also for many preauthentication
-   systems and application protocols, while trying to avoid some of the
-   assumptions that can work their way into such protocol designs.
-
-   Some problematic assumptions we've seen (and sometimes made) include:
-   that a random bitstring is always valid as a key (not true for DES
-   keys with parity); that the basic block encryption chaining mode
-   provides no integrity checking, or can easily be separated from such
-   checking (not true for many modes in development that do both
-   simultaneously); that a checksum for a message always results in the
-   same value (not true if a confounder is incorporated); that an
-   initial vector is used (may not be true if a block cipher in CBC mode
-   is not in use).
-
-
-
-Raeburn                                                        [Page 30]
-
-INTERNET DRAFT                                             February 2004
-
-
-   Such assumptions, while they may hold for any given set of encryption
-   and checksum algorithms, may not be true of the next algorithms to be
-   defined, leaving the application protocol unable to make use of those
-   algorithms without updates to its specification.
-
-   The Kerberos protocol uses only the attributes and operations
-   described in sections 3 and 4.  Preauthentication systems and
-   application protocols making use of Kerberos are encouraged to use
-   them as well.  The specific key and string-to-key parameters should
-   generally be treated as opaque.  While the string-to-key parameters
-   are manipulated as an octet string, the representation for the
-   specific key structure is implementation-defined; it may not even be
-   a single object.
-
-   While we don't recommend it, some application protocols will
-   undoubtedly continue to use the key data directly, even if only in
-   some of the currently existing protocol specifications.  An
-   implementation intended to support general Kerberos applications may
-   therefore need to make the key data available, as well as the
-   attributes and operations described in sections 3 and 4.  [8]
-
-8. Assigned Numbers
-
-   The following encryption type numbers are already assigned or
-   reserved for use in Kerberos and related protocols.
-
-
-     encryption type                etype      section or comment
-     -----------------------------------------------------------------
-     des-cbc-crc                        1             6.2.3
-     des-cbc-md4                        2             6.2.2
-     des-cbc-md5                        3             6.2.1
-     [reserved]                         4
-     des3-cbc-md5                       5
-     [reserved]                         6
-     des3-cbc-sha1                      7
-     dsaWithSHA1-CmsOID                 9           (pkinit)
-     md5WithRSAEncryption-CmsOID       10           (pkinit)
-     sha1WithRSAEncryption-CmsOID      11           (pkinit)
-     rc2CBC-EnvOID                     12           (pkinit)
-     rsaEncryption-EnvOID              13   (pkinit from PKCS#1 v1.5)
-     rsaES-OAEP-ENV-OID                14   (pkinit from PKCS#1 v2.0)
-     des-ede3-cbc-Env-OID              15           (pkinit)
-     des3-cbc-sha1-kd                  16              6.3
-     aes128-cts-hmac-sha1-96           17          [KRB5-AES]
-     aes256-cts-hmac-sha1-96           18          [KRB5-AES]
-     rc4-hmac                          23          (Microsoft)
-
-
-
-
-Raeburn                                                        [Page 31]
-
-INTERNET DRAFT                                             February 2004
-
-
-     rc4-hmac-exp                      24          (Microsoft)
-     subkey-keymaterial                65     (opaque; PacketCable)
-
-
-   (The "des3-cbc-sha1" assignment is a deprecated version using no key
-   derivation.  It should not be confused with des3-cbc-sha1-kd.)
-
-   Several numbers have been reserved for use in encryption systems not
-   defined here.  Encryption type numbers have unfortunately been
-   overloaded on occasion in Kerberos-related protocols, so some of the
-   reserved numbers do not and will not correspond to encryption systems
-   fitting the profile presented here.
-
-   The following checksum type numbers are assigned or reserved.  As
-   with encryption type numbers, some overloading of checksum numbers
-   has occurred.
-
-
-   Checksum type              sumtype        checksum         section or
-                                value            size         reference
-   ----------------------------------------------------------------------
-   CRC32                            1               4           6.1.3
-   rsa-md4                          2              16           6.1.2
-   rsa-md4-des                      3              24           6.2.5
-   des-mac                          4              16           6.2.7
-   des-mac-k                        5               8           6.2.8
-   rsa-md4-des-k                    6              16           6.2.6
-   rsa-md5                          7              16           6.1.1
-   rsa-md5-des                      8              24           6.2.4
-   rsa-md5-des3                     9              24             ??
-   sha1 (unkeyed)                  10              20             ??
-   hmac-sha1-des3-kd               12              20            6.3
-   hmac-sha1-des3                  13              20             ??
-   sha1 (unkeyed)                  14              20             ??
-   hmac-sha1-96-aes128             15              20         [KRB5-AES]
-   hmac-sha1-96-aes256             16              20         [KRB5-AES]
-   [reserved]                  0x8003               ?         [GSS-KRB5]
-
-
-   Encryption and checksum type numbers are signed 32-bit values.  Zero
-   is invalid, and negative numbers are reserved for local use.  All
-   standardized values must be positive.
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 32]
-
-INTERNET DRAFT                                             February 2004
-
-
-9. Implementation Notes
-
-   The "interface" described here is the minimal information that must
-   be defined to make a cryptosystem useful within Kerberos in an
-   interoperable fashion.  Despite the functional notation used in some
-   places, it is not an attempt to define an API for cryptographic
-   functionality within Kerberos.  Actual implementations providing
-   clean APIs will probably find it useful to make additional
-   information available, which should be possible to derive from a
-   specification written to the framework given here.  For example, an
-   application designer may wish to determine the largest number of
-   bytes that can be encrypted without overflowing a certain size output
-   buffer, or conversely, the maximum number of bytes that might be
-   obtained by decrypting a ciphertext message of a given size.  (In
-   fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5]
-   will require some of these.)
-
-   The presence of a mechanism in this document should not be taken as
-   an indication that it must be implemented for compliance with any
-   specification; required mechanisms will be specified elsewhere.
-   Indeed, some of the mechanisms described here for backwards
-   compatibility are now considered rather weak for protecting critical
-   data.
-
-10. Security Considerations
-
-   Recent years have brought advancements in the ability to perform
-   large-scale attacks against DES, to such a degree that it is not
-   considered a strong encryption mechanism any longer; triple-DES is
-   generally preferred in its place, despite the poorer performance.
-   See [ESP-DES] for a summary of some of the potential attacks, and
-   [EFF-DES] for a detailed discussion of the implementation of
-   particular attack.  However, most Kerberos implementations still have
-   DES as their primary interoperable encryption type.
-
-   DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of
-   single-DES here avoids them.  However, DES also has 48 'possibly-
-   weak' keys [Schneier96] (note that the tables in many editions of the
-   reference contains errors) which are not avoided.
-
-   DES weak keys are keys with the property that E1(E1(P)) = P (where E1
-   denotes encryption of a single block with key 1).  DES semi-weak keys
-   or "dual" keys are pairs of keys with the property that E1(P) =
-   D2(P), and thus E2(E1(P)) = P.  Because of the use of CBC mode and
-   leading random confounder, however, these properties are unlikely to
-   present a security problem.
-
-   Many of the choices concerning when weak-key corrections are
-
-
-
-Raeburn                                                        [Page 33]
-
-INTERNET DRAFT                                             February 2004
-
-
-   performed relate more to compatibility with existing implementations
-   than to any risk analysis.
-
-   While checks are also done for the component DES keys in a triple-DES
-   key, the nature of the weak keys is such that it is extremely
-   unlikely that they will weaken the triple-DES encryption -- only
-   slightly more likely than having the middle of the three sub-keys
-   match one of the other two, which effectively converts the encryption
-   to single-DES, which is a case we make no effort to avoid.
-
-   The true CRC-32 checksum is not collision-proof; an attacker could
-   use a probabilistic chosen-plaintext attack to generate a valid
-   message even if a confounder is used [SG92].  The use of collision-
-   proof checksums is of course recommended for environments where such
-   attacks represent a significant threat.  The "simplifications" (read:
-   bugs) introduced when CRC-32 was implemented for Kerberos cause
-   leading zeros to effectively be ignored, so messages differing only
-   in leading zero bits will have the same checksum.
-
-   [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm.
-   Unlike [IPSEC-HMAC], the triple-DES specification here does not use
-   the suggested truncation of the HMAC output.  As pointed out in
-   [IPSEC-HMAC], SHA-1 was not developed to be used as a keyed hash
-   function, which is a criterion of HMAC.  [HMAC-TEST] contains test
-   vectors for HMAC-SHA-1.
-
-   The mit_des_string_to_key function was originally constructed with
-   the assumption that all input would be ASCII; it ignores the top bit
-   of each input byte.  Folding with XOR is also not an especially good
-   mixing mechanism in terms of preserving randomness.
-
-   The n-fold function used in the string-to-key operation for des3-cbc-
-   hmac-sha1-kd was designed to cause each bit of input to contribute
-   equally to the output; it was not designed to maximize or equally
-   distribute randomness in the input, and there are conceivable cases
-   of partially structured input where randomness may be lost.  This
-   should only be an issue for highly structured passwords, however.
-
-   [RFC1851] discusses the relative strength of triple-DES encryption.
-   The relative slow speed of triple-DES encryption may also be an issue
-   for some applications.
-
-   In [Bellovin91], there is a suggestion that analyses of encryption
-   schemes should include a model of an attacker capable of submitting
-   known plaintexts to be encrypted with an unknown key, as well as
-   being able to perform many types of operations on known protocol
-   messages.  Recent experiences with the chosen-plaintext attacks on
-   Kerberos version 4 bear out the value of this suggestion.
-
-
-
-Raeburn                                                        [Page 34]
-
-INTERNET DRAFT                                             February 2004
-
-
-   The use of unkeyed encrypted checksums, such as those used in the
-   single-DES cryptosystems specified in [Kerb1510], allows for cut-and-
-   paste attacks, especially if a confounder is not used.  In addition,
-   unkeyed encrypted checksums are vulnerable to chosen-plaintext
-   attacks: an attacker with access to an encryption oracle can easily
-   encrypt the required unkeyed checksum along with the chosen
-   plaintext. [Bellovin99]  These weaknesses, combined with a common
-   implementation design choice described below, allow for a cross-
-   protocol attack from version 4 to version 5.
-
-   The use of a random confounder is an important means of preventing an
-   attacker from making effective use of protocol exchanges as an
-   encryption oracle.  In Kerberos version 4, the encryption of constant
-   plaintext to constant ciphertext makes an effective encryption oracle
-   for an attacker.  The use of random confounders in [Kerb1510]
-   frustrates this sort of chosen-plaintext attack.
-
-   Using the same key for multiple purposes can enable or increase the
-   scope of chosen-plaintext attacks.  Some software which implements
-   both versions 4 and 5 of the Kerberos protocol uses the same keys for
-   both versions of the protocol.  This enables the encryption oracle of
-   version 4 to be used to attack version 5.  Vulnerabilities such as
-   this cross-protocol attack reinforce the wisdom of not using a key
-   for multiple purposes.
-
-   This document, like the Kerberos protocol, completely ignores the
-   notion of limiting the amount of data a key may be used with to a
-   quantity based on the robustness of the algorithm or size of the key.
-   It is assumed that any defined algorithms and key sizes will be
-   strong enough to support very large amounts of data, or they will be
-   deprecated once significant attacks are known.
-
-   This document also places no bounds on the amount of data that can be
-   handled in various operations.  In order to avoid denial of service
-   attacks, implementations will probably want to restrict message sizes
-   at some higher level.
-
-11. IANA Considerations
-
-   Two registries for numeric values should be created: Kerberos
-   Encryption Type Numbers and Kerberos Checksum Type Numbers.  These
-   are signed values ranging from -2147483648 to 2147483647.  Positive
-   values should be assigned only for algorithms specified in accordance
-   with this specification for use with Kerberos or related protocols.
-   Negative values are for private use; local and experimental
-   algorithms should use these values.  Zero is reserved and may not be
-   assigned.
-
-
-
-
-Raeburn                                                        [Page 35]
-
-INTERNET DRAFT                                             February 2004
-
-
-   Positive encryption and checksum type numbers may be assigned
-   following either of two policies described in [BCP26].
-
-   Standards-track specifications may be assigned values under the
-   Standards Action policy.
-
-   Specifications in non-standards track RFCs may be assigned values
-   after Expert Review.  A non-IETF specification may be assigned values
-   by publishing an Informational or standards-track RFC referencing the
-   external specification; that specification must be public and
-   published in some permanent record much like the IETF RFCs.  It is
-   highly desirable, though not required, that the full specification be
-   published as an IETF RFC.
-
-   Smaller encryption type values should be used for IETF standards-
-   track mechanisms, and much higher values (16777216 and above) for
-   other mechanisms.  (Rationale: In the Kerberos ASN.1 encoding,
-   smaller numbers encode to smaller octet sequences, so this favors
-   standards-track mechanisms with slightly smaller messages.)  Aside
-   from that guideline, IANA may choose numbers as it sees fit.
-
-   Internet-Draft specifications should not include values for
-   encryption and checksum type numbers.  Instead, they should indicate
-   that values would be assigned by IANA when the document is approved
-   as an RFC.  For development and interoperability testing, values in
-   the private-use range (negative values) may be used, but should not
-   be included in the draft specification.
-
-   Each registered value should have an associated unique name to refer
-   to it by.  The lists given in section 8 should be used as an initial
-   registry; they include reservations for specifications in progress in
-   parallel with this document, and for certain other values believed to
-   be in use already.
-
-12. Acknowledgments
-
-   This document is an extension of the encryption specification
-   included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much
-   of the text of the background, concepts, and DES specifications are
-   drawn directly from that document.
-
-   The abstract framework presented in this document was put together by
-   Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn,
-   and Tom Yu, and the details were refined several times based on
-   comments from John Brezak and others.
-
-   Marc Horowitz wrote the original specification of triple-DES and key
-   derivation in a pair of Internet Drafts (under the names draft-
-
-
-
-Raeburn                                                        [Page 36]
-
-INTERNET DRAFT                                             February 2004
-
-
-   horowitz-key-derivation and draft-horowitz-kerb-key-derivation) which
-   were later folded into a draft revision of [Kerb1510], from which
-   this document was later split off.
-
-   Tom Yu provided the text describing the modifications to the standard
-   CRC algorithm as Kerberos implementations actually use it, and some
-   of the Security Considerations section.
-
-   Miroslav Jurisic provided information for one of the UTF-8 test cases
-   for the string-to-key functions.
-
-   Marcus Watts noticed some errors in earlier drafts, and pointed out
-   that the simplified profile could easily be modified to support
-   cipher text stealing modes.
-
-   Simon Josefsson contributed some clarifications to the DES "CBC
-   checksum", string-to-key and weak key descriptions, and some test
-   vectors.
-
-   Simon Josefsson, Louis LeVay and others also caught some errors in
-   earlier drafts.
-
-A. Test vectors
-
-   This section provides test vectors for various functions defined or
-   described in this document.  For convenience, most inputs are ASCII
-   strings, though some UTF-8 samples are be provided for string-to-key
-   functions.  Keys and other binary data are specified as hexadecimal
-   strings.
-
-A.1. n-fold
-
-   The n-fold function is defined in section 5.1.  As noted there, the
-   sample vector in the original paper defining the algorithm appears to
-   be incorrect.  Here are some test cases provided by Marc Horowitz and
-   Simon Josefsson:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 37]
-
-INTERNET DRAFT                                             February 2004
-
-
-      64-fold("012345") =
-      64-fold(303132333435) = be072631276b1955
-
-      56-fold("password") =
-      56-fold(70617373776f7264) = 78a07b6caf85fa
-
-      64-fold("Rough Consensus, and Running Code") =
-      64-fold(526f75676820436f6e73656e7375732c20616e642052756e
-              6e696e6720436f6465) = bb6ed30870b7f0e0
-
-      168-fold("password") =
-      168-fold(70617373776f7264) =
-               59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
-
-      192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY"
-      192-fold(4d41535341434856534554545320494e5354495456544520
-               4f4620544543484e4f4c4f4759) =
-               db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
-
-      168-fold("Q") =
-      168-fold(51) =
-               518a54a2 15a8452a 518a54a2 15a8452a
-               518a54a2 15
-
-      168-fold("ba") =
-      168-fold(6261) =
-               fb25d531 ae897449 9f52fd92 ea9857c4
-               ba24cf29 7e
-
-   Here are some additional values corresponding to folded values of the
-   string "kerberos"; the 64-bit form is used in the des3 string-to-key
-   (section 6.3.1).
-
-      64-fold("kerberos") =
-               6b657262 65726f73
-      128-fold("kerberos") =
-               6b657262 65726f73 7b9b5b2b 93132b93
-      168-fold("kerberos") =
-               8372c236 344e5f15 50cd0747 e15d62ca
-               7a5a3bce a4
-      256-fold("kerberos") =
-               6b657262 65726f73 7b9b5b2b 93132b93
-               5c9bdcda d95c9899 c4cae4de e6d6cae4
-
-   Note that the initial octets exactly match the input string when the
-   output length is a multiple of the input length.
-
-
-
-
-
-Raeburn                                                        [Page 38]
-
-INTERNET DRAFT                                             February 2004
-
-
-A.2. mit_des_string_to_key
-
-   The function mit_des_string_to_key is defined in section 6.2.  We
-   present here several test values, with some of the intermediate
-   results.  The fourth test demonstrates the use of UTF-8 with three
-   characters.  The last two tests are specifically constructed so as to
-   trigger the weak-key fixups for the intermediate key produced by fan-
-   folding; we have no test cases that cause such fixups for the final
-   key.
-
-   UTF-8 encodings used in test vector:
-   eszett    U+00DF   C3 9F   s-caron   U+0161    C5 A1
-   c-acute   U+0107   C4 87   g-clef    U+1011E   F0 9D 84 9E
-
-   Test vector:
-
-   salt:        "ATHENA.MIT.EDUraeburn"
-                              415448454e412e4d49542e4544557261656275726e
-   password:    "password"    70617373776f7264
-   fan-fold result:           c01e38688ac86c2e
-   intermediate key:          c11f38688ac86d2f
-   DES key:                   cbc22fae235298e3
-
-
-   salt:       "WHITEHOUSE.GOVdanny"
-                           5748495445484f5553452e474f5664616e6e79
-   password:   "potatoe"   706f7461746f65
-   fan-fold result:        a028944ee63c0416
-   intermediate key:       a129944fe63d0416
-   DES key:                df3d32a74fd92a01
-
-
-   salt:      "EXAMPLE.COMpianist"  4558414D504C452E434F4D7069616E697374
-   password:  g-clef (U+1011E)      f09d849e
-   fan-fold result:                 3c4a262c18fab090
-   intermediate key:                3d4a262c19fbb091
-   DES key:                         4ffb26bab0cd9413
-
-
-   salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107)
-                                   415448454e412e4d49542e4544554a757269c5a169c487
-   password:       eszett(U+00DF)
-                                   c39f
-   fan-fold result:b8f6c40e305afc9e
-   intermediate key:               b9f7c40e315bfd9e
-   DES key:                        62c81a5232b5e69d
-
-
-
-
-
-Raeburn                                                        [Page 39]
-
-INTERNET DRAFT                                             February 2004
-
-
-   salt:       "AAAAAAAA"   4141414141414141
-   password:   "11119999"   3131313139393939
-   fan-fold result:         e0e0e0e0f0f0f0f0
-   intermediate key:        e0e0e0e0f1f1f101
-   DES key:                 984054d0f1a73e31
-
-
-   salt:       "FFFFAAAA"   4646464641414141
-   password:   "NNNN6666"   4e4e4e4e36363636
-   fan-fold result:         1e1e1e1e0e0e0e0e
-   intermediate key:        1f1f1f1f0e0e0efe
-   DES key:                 c4bf6b25adf7a4f8
-
-
-   This trace provided by Simon Josefsson shows the intermediate
-   processing stages of one of the test inputs:
-
-     string_to_key (des-cbc-md5, string, salt)
-            ;; string:
-            ;; `password' (length 8 bytes)
-            ;; 70 61 73 73 77 6f 72 64
-            ;; salt:
-            ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
-            ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
-            ;; 65 62 75 72 6e
-     des_string_to_key (string, salt)
-            ;; String:
-            ;; `password' (length 8 bytes)
-            ;; 70 61 73 73 77 6f 72 64
-            ;; Salt:
-            ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
-            ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
-            ;; 65 62 75 72 6e
-     odd = 1;
-     s = string | salt;
-     tempstring = 0; /* 56-bit string */
-     pad(s); /* with nulls to 8 byte boundary */
-            ;; s = pad(string|salt):
-            ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'
-            ;; (length 32 bytes)
-            ;; 70 61 73 73 77 6f 72 64  41 54 48 45 4e 41 2e 4d
-            ;; 49 54 2e 45 44 55 72 61  65 62 75 72 6e 00 00 00
-     for (8byteblock in s) {
-            ;; loop iteration 0
-            ;; 8byteblock:
-            ;; `password' (length 8 bytes)
-            ;; 70 61 73 73 77 6f 72 64
-            ;; 01110000 01100001 01110011  01110011 01110111 01101111
-
-
-
-Raeburn                                                        [Page 40]
-
-INTERNET DRAFT                                             February 2004
-
-
-            ;; 01110010 01100100
-     56bitstring = removeMSBits(8byteblock);
-            ;; 56bitstring:
-            ;; 1110000 1100001 1110011  1110011 1110111 1101111
-            ;; 1110010 1100100
-     if (odd == 0) reverse(56bitstring);    ;; odd=1
-     odd = ! odd
-     tempstring = tempstring XOR 56bitstring;
-            ;; tempstring
-            ;; 1110000 1100001 1110011  1110011 1110111 1101111
-            ;; 1110010 1100100
-
-     for (8byteblock in s) {
-            ;; loop iteration 1
-            ;; 8byteblock:
-            ;; `ATHENA.M' (length 8 bytes)
-            ;; 41 54 48 45 4e 41 2e 4d
-            ;; 01000001 01010100 01001000  01000101 01001110 01000001
-            ;; 00101110 01001101
-     56bitstring = removeMSBits(8byteblock);
-            ;; 56bitstring:
-            ;; 1000001 1010100 1001000  1000101 1001110 1000001
-            ;; 0101110 1001101
-     if (odd == 0) reverse(56bitstring);    ;; odd=0
-     reverse(56bitstring)
-            ;; 56bitstring after reverse
-            ;; 1011001 0111010 1000001  0111001 1010001 0001001
-            ;; 0010101 1000001
-     odd = ! odd
-     tempstring = tempstring XOR 56bitstring;
-            ;; tempstring
-            ;; 0101001 1011011 0110010  1001010 0100110 1100110
-            ;; 1100111 0100101
-
-     for (8byteblock in s) {
-            ;; loop iteration 2
-            ;; 8byteblock:
-            ;; `IT.EDUra' (length 8 bytes)
-            ;; 49 54 2e 45 44 55 72 61
-            ;; 01001001 01010100 00101110  01000101 01000100 01010101
-            ;; 01110010 01100001
-     56bitstring = removeMSBits(8byteblock);
-            ;; 56bitstring:
-            ;; 1001001 1010100 0101110  1000101 1000100 1010101
-            ;; 1110010 1100001
-     if (odd == 0) reverse(56bitstring);    ;; odd=1
-
-
-
-
-
-Raeburn                                                        [Page 41]
-
-INTERNET DRAFT                                             February 2004
-
-
-     odd = ! odd
-     tempstring = tempstring XOR 56bitstring;
-            ;; tempstring
-            ;; 1100000 0001111 0011100  0001111 1100010 0110011
-            ;; 0010101 1000100
-
-     for (8byteblock in s) {
-            ;; loop iteration 3
-            ;; 8byteblock:
-            ;; `eburn\x00\x00\x00' (length 8 bytes)
-            ;; 65 62 75 72 6e 00 00 00
-            ;; 01100101 01100010 01110101  01110010 01101110 00000000
-            ;; 00000000 00000000
-     56bitstring = removeMSBits(8byteblock);
-            ;; 56bitstring:
-            ;; 1100101 1100010 1110101  1110010 1101110 0000000
-            ;; 0000000 0000000
-     if (odd == 0) reverse(56bitstring);    ;; odd=0
-     reverse(56bitstring)
-            ;; 56bitstring after reverse
-            ;; 0000000 0000000 0000000  0111011 0100111 1010111
-            ;; 0100011 1010011
-     odd = ! odd
-     tempstring = tempstring XOR 56bitstring;
-            ;; tempstring
-            ;; 1100000 0001111 0011100  0110100 1000101 1100100
-            ;; 0110110 0010111
-
-     for (8byteblock in s) {
-     }
-            ;; for loop terminated
-
-     tempkey = key_correction(add_parity_bits(tempstring));
-            ;; tempkey
-            ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes)
-            ;; c1 1f 38 68 8a c8 6d 2f
-            ;; 11000001 00011111 00111000  01101000 10001010 11001000
-            ;; 01101101 00101111
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 42]
-
-INTERNET DRAFT                                             February 2004
-
-
-     key = key_correction(DES-CBC-check(s,tempkey));
-            ;; key
-            ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
-            ;; cb c2 2f ae 23 52 98 e3
-            ;; 11001011 11000010 00101111  10101110 00100011 01010010
-            ;; 10011000 11100011
-
-            ;; string_to_key key:
-            ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
-            ;; cb c2 2f ae 23 52 98 e3
-
-
-A.3. DES3 DR and DK
-
-   These tests show the derived-random and derived-key values for the
-   des3-hmac-sha1-kd encryption scheme, using the DR and DK functions
-   defined in section 6.3.1.  The input keys were randomly generated;
-   the usage values are from this specification.
-
-
-   key:                 dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
-   usage:               0000000155
-   DR:                  935079d14490a75c3093c4a6e8c3b049c71e6ee705
-   DK:                  925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
-
-   key:                 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
-   usage:               00000001aa
-   DR:                  9f58e5a047d894101c469845d67ae3c5249ed812f2
-   DK:                  9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
-
-   key:                 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
-   usage:               0000000155
-   DR:                  12fff90c773f956d13fc2ca0d0840349dbd39908eb
-   DK:                  13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
-
-   key:                 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
-   usage:               00000001aa
-   DR:                  f8debf05b097e7dc0603686aca35d91fd9a5516a70
-   DK:                  f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
-
-   key:                 d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
-   usage:               6b65726265726f73 ("kerberos")
-   DR:                  2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
-   DK:                  2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
-
-   key:                 c1081649ada74362e6a1459d01dfd30d67c2234c940704da
-   usage:               0000000155
-
-
-
-
-Raeburn                                                        [Page 43]
-
-INTERNET DRAFT                                             February 2004
-
-
-   DR:                  348056ec98fcc517171d2b4d7a9493af482d999175
-   DK:                  348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
-
-   key:                 5d154af238f46713155719d55e2f1f790dd661f279a7917c
-   usage:               00000001aa
-   DR:                  a8818bc367dadacbe9a6c84627fb60c294b01215e5
-   DK:                  a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
-
-   key:                 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
-   usage:               0000000155
-   DR:                  c813f88b3be2b2f75424ce9175fbc8483b88c8713a
-   DK:                  c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
-
-   key:                 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
-   usage:               00000001aa
-   DR:                  f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
-   DK:                  f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
-
-
-A.4. DES3string_to_key
-
-   These are the keys generated for some of the above input strings for
-   triple-DES with key derivation as defined in section 6.3.1.
-
-    salt:   "ATHENA.MIT.EDUraeburn"
-    passwd: "password"
-    key:    850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
-
-    salt:   "WHITEHOUSE.GOVdanny"
-    passwd: "potatoe"
-    key:    dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
-
-    salt:   "EXAMPLE.COMbuckaroo"
-    passwd: "penny"
-    key:    6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
-
-    salt:   "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i"
-             + c-acute(U+0107)
-    passwd: eszett(U+00DF)
-    key:    16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
-
-    salt:   "EXAMPLE.COMpianist"
-    passwd: g-clef(U+1011E)
-    key:    85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
-
-
-
-
-
-
-
-Raeburn                                                        [Page 44]
-
-INTERNET DRAFT                                             February 2004
-
-
-A.5. Modified CRC-32
-
-   Below are modified-CRC32 values for various ASCII and octet strings.
-   Only the printable ASCII characters are checksummed, no C-style
-   trailing zero-valued octet.  The 32-bit modified CRC and the sequence
-   of output bytes as used in Kerberos are shown.  (The octet values are
-   separated here to emphasize that they are octet values and not 32-bit
-   numbers, which will be the most convenient form for manipulation in
-   some implementations.  The bit and byte order used internally for
-   such a number is irrelevant; the octet sequence generated is what is
-   important.)
-
-
-    mod-crc-32("foo") =                                     33 bc 32 73
-    mod-crc-32("test0123456789") =                          d6 88 3e b8
-    mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") =   f7 80 41 e3
-    mod-crc-32(8000) =                                      4b 98 83 3b
-    mod-crc-32(0008) =                                      32 88 db 0e
-    mod-crc-32(0080) =                                      20 83 b8 ed
-    mod-crc-32(80) =                                        20 83 b8 ed
-    mod-crc-32(80000000) =                                  3b b6 59 ed
-    mod-crc-32(00000001) =                                  96 30 07 77
-
-
-B. Significant Changes from RFC 1510
-
-   The encryption and checksum mechanism profiles are new.  The old
-   specification defined a few operations for various mechanisms, but
-   didn't outline what should be required of new mechanisms in terms of
-   abstract properties, nor how to ensure that a mechanism specification
-   is complete enough for interoperability between implementations.  The
-   new profiles do differ from the old specification in a few ways:
-
-      Some message definitions in [Kerb1510] could be read as permitting
-      the initial vector to be specified by the application; the text
-      was too vague.  It is specifically not permitted in this
-      specification.  Some encryption algorithms may not use
-      initialization vectors, so relying on chosen, secret
-      initialization vectors for security is unwise.  Also, the
-      prepended confounder in the existing algorithms is roughly
-      equivalent to a per-message initialization vector that is revealed
-      in encrypted form.  However, carrying state across from one
-      encryption to another is explicitly permitted through the opaque
-      "cipher state" object.
-
-      The use of key derivation is new.
-
-      Several new methods are introduced, including generation of a key
-
-
-
-Raeburn                                                        [Page 45]
-
-INTERNET DRAFT                                             February 2004
-
-
-      in wire-protocol format from random input data.
-
-      The means for influencing the string-to-key algorithm are laid out
-      more clearly.
-
-   Triple-DES support is new.
-
-   The pseudo-random function is new.
-
-   The des-cbc-crc, DES string-to-key and CRC descriptions have been
-   updated to align them with existing implementations.
-
-   [Kerb1510] had no indication what character set or encoding might be
-   used for pass phrases and salts.
-
-   In [Kerb1510], key types, encryption algorithms and checksum
-   algorithms were only loosely associated, and the association was not
-   well described.  In this specification, key types and encryption
-   algorithms have a one-to-one correspondence, and associations between
-   encryption and checksum algorithms are described so that checksums
-   can be computed given negotiated keys, without requiring further
-   negotiation for checksum types.
-
-Notes
-
-   [1] While Message Authentication Code (MAC) or Message Integrity
-       Check (MIC) would be more appropriate terms for many of the
-       uses in this document, we continue to use the term "checksum"
-       for historical reasons.
-
-   [2] Extending CBC mode across messages would be one obvious
-       example of this chaining.  Another might be the use of
-       counter mode, with a counter randomly initialized and
-       attached to the ciphertext; a second message could continue
-       incrementing the counter when chaining the cipher state, thus
-       avoiding having to transmit another counter value.  However,
-       this chaining is only useful for uninterrupted, ordered
-       sequences of messages.
-
-   [3] In the case of Kerberos, the encrypted objects will generally
-       be ASN.1 DER encodings, which contain indications of their
-       length in the first few octets.
-
-   [4] As of the time of this writing, some new modes of operation
-       have been proposed, some of which may permit encryption and
-       integrity protection simultaneously.  After some of these
-       proposals have been subjected to adequate analysis, we may
-       wish to formulate a new simplified profile based on one of
-
-
-
-Raeburn                                                        [Page 46]
-
-INTERNET DRAFT                                             February 2004
-
-
-       them.
-
-   [5] It should be noted that the sample vector in Appendix B.2 of
-       the original paper appears to be incorrect.  Two independent
-       implementations from the specification (one in C by Marc
-       Horowitz, and another in Scheme by Bill Sommerfeld) agree on
-       a value different from that in [Blumenthal96].
-
-   [6] For example, in MIT's implementation of [Kerb1510], the rsa-
-       md5 unkeyed checksum of application data may be included in
-       an authenticator encrypted in a service's key; since rsa-md5
-       is believed to be collision-proof, even if the application
-       data is exposed to an attacker, it cannot be modified without
-       causing the checksum verification to fail.
-
-   [7] A variant of the key is used to limit the use of a key to a
-       particular function, separating the functions of generating a
-       checksum from other encryption performed using the session
-       key.  The constant 0xF0F0F0F0F0F0F0F0 was chosen because it
-       maintains key parity.  The properties of DES precluded the
-       use of the complement.  The same constant is used for similar
-       purpose in the Message Integrity Check in the Privacy
-       Enhanced Mail standard.
-
-   [8] Perhaps one of the more common reasons for directly
-       performing encryption is direct control over the negotiation
-       and to select a "sufficiently strong" encryption algorithm
-       (whatever that means in the context of a given application).
-       While Kerberos directly provides no facility for negotiating
-       encryption types between the application client and server,
-       there are other means for accomplishing similar goals.  For
-       example, requesting only "strong" session key types from the
-       KDC, and assuming that the type actually returned by the KDC
-       will be understood and supported by the application server.
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-
-
-
-Raeburn                                                        [Page 47]
-
-INTERNET DRAFT                                             February 2004
-
-
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-Normative References
-
-   [Bellare98]
-      Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway,
-      "Relations Among Notions of Security for Public-Key Encryption
-      Schemes".  Extended abstract published in Advances in Cryptology-
-      Crypto 98 Proceedings, Lecture Notes in Computer Science Vol.
-      1462, H. Krawcyzk ed., Springer-Verlag, 1998.
-   [Blumenthal96]
-      Blumenthal, U., and S. Bellovin, "A Better Key Schedule for DES-
-      Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996.
-   [CRC]
-      International Organization for Standardization, "ISO Information
-      Processing Systems - Data Communication - High-Level Data Link
-      Control Procedure - Frame Structure," IS 3309, 3rd Edition,
-      October 1984.
-   [DES77]
-      National Bureau of Standards, U.S. Department of Commerce, "Data
-      Encryption Standard," Federal Information Processing Standards
-      Publication 46, Washington, DC, 1977.
-   [DESI81]
-      National Bureau of Standards, U.S. Department of Commerce,
-      "Guidelines for implementing and using NBS Data Encryption
-      Standard," Federal Information Processing Standards Publication
-      74, Washington, DC, 1981.
-   [DESM80]
-      National Bureau of Standards, U.S. Department of Commerce, "DES
-      Modes of Operation," Federal Information Processing Standards
-      Publication 81, Springfield, VA, December 1980.
-   [Dolev91]
-      Dolev, D., Dwork, C., Naor, M., "Non-malleable cryptography",
-      Proceedings of the 23rd Annual Symposium on Theory of Computing,
-      ACM, 1991.
-   [HMAC]
-      Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
-      for Message Authentication", RFC 2104, February 1997.
-
-
-
-
-
-
-Raeburn                                                        [Page 48]
-
-INTERNET DRAFT                                             February 2004
-
-
-   [KRB5-AES]
-      Raeburn, K., "AES Encyrption for Kerberos 5", RFC XXXX, Xxxxxxxx
-      2003.
-   [MD4-92]
-      Rivest, R., "The MD4 Message Digest Algorithm," RFC 1320, MIT
-      Laboratory for Computer Science, April 1992.
-   [MD5-92]
-      Rivest, R., "The MD5 Message Digest Algorithm," RFC 1321, MIT
-      Laboratory for Computer Science, April 1992.
-   [RFC2026]
-      Bradner, S., "The Internet Standards Process -- Revisions 3," RFC
-      2026, October 1996.
-   [SG92]
-      Stubblebine, S., and V. D. Gligor, "On Message Integrity in
-      Cryptographic Protocols," in Proceedings of the IEEE Symposium on
-      Research in Security and Privacy, Oakland, California, May 1992.
-
-Informative References
-
-   [Bellovin91]
-      Bellovin, S. M., and M. Merrit, "Limitations of the Kerberos
-      Authentication System", in Proceedings of the Winter 1991 Usenix
-      Security Conference, January, 1991.
-   [Bellovin99]
-      Bellovin, S. M., and D. Atkins, private communications, 1999.
-   [EFF-DES]
-      Electronic Frontier Foundation, "Cracking DES: Secrets of
-      Encryption Research, Wiretap Politics, and Chip Design", O'Reilly
-      & Associates, Inc., May 1998.
-   [ESP-DES]
-      Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm
-      With Explicit IV", RFC 2405, November 1998.
-   [GSS-KRB5]
-      Linn, J., "The Kerberos Version 5 GSS-API Mechanism," RFC 1964,
-      June 1996.
-   [HMAC-TEST]
-      Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",
-      RFC 2202, September 1997.
-   [IPSEC-HMAC]
-      Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and
-      AH", RFC 2404, November 1998.
-   [Kerb]
-      Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K.
-      Raeburn, "The Kerberos Network Authentication Service (V5)",
-      draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22,
-      2002.  Work in progress.
-
-
-
-
-
-Raeburn                                                        [Page 49]
-
-INTERNET DRAFT                                             February 2004
-
-
-   [Kerb1510]
-      Kohl, J., and C. Neuman, "The Kerberos Network Authentication
-      Service (V5)", RFC 1510, September 1993.
-   [RC5]
-      Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
-      RC5-CTS Algorithms", RFC 2040, October 1996.
-   [Schneier96]
-      Schneier, B., "Applied Cryptography Second Edition", John Wiley &
-      Sons, New York, NY, 1996.  ISBN 0-471-12845-7.
-
-Editor's address
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-   raeburn@mit.edu
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-Raeburn                                                        [Page 50]
-
-INTERNET DRAFT                                             February 2004
-
-
-Notes to RFC Editor
-
-   Before publication of this document as an RFC, the following changes
-   are needed:
-
-   Change the reference "[KRB5-AES]" in Normative References to indicate
-   the AES draft (draft-raeburn-krb-rijndael-krb-XX) that should be
-   advancing to RFC at the same time.  The RFC number and publication
-   date are needed.
-
-   If draft-ietf-krb-wg-kerberos-clarifications advances to RFC at the
-   same time as this document, change the information for [Kerb] in the
-   Informative References section as well.
-
-   Change the first-page headers to indicate the RFC number, network
-   working group, etc, as appropriate for an RFC instead of an I-D.
-
-   Remove the contact-info paragraph from the Abstract.
-
-   Delete this section.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 51]
diff --git a/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-03.txt b/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-03.txt
deleted file mode 100644
index 50700306a..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-03.txt
+++ /dev/null
@@ -1,673 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                           S. Emery
-Internet-Draft                                          Sun Microsystems
-Updates: 4121 (if approved)                             November 9, 2007
-Intended status: Standards Track
-Expires: May 12, 2008
-
-
-        Kerberos Version 5 GSS-API Channel Binding Hash Agility
-              draft-ietf-krb-wg-gss-cb-hash-agility-03.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on May 12, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                     Expires May 12, 2008                  [Page 1]
-
-Internet-Draft        Channel Binding Hash Agility         November 2007
-
-
-Abstract
-
-   Currently, the Kerberos Version 5 Generic Security Services
-   Application Programming Interface (GSS-API) mechanism [RFC4121] does
-   not have the ability to utilize better hash algorithms used to
-   generate channel binding identities.  The current mechanism for doing
-   this is hard coded to use MD5 only.  The purpose of this document is
-   to outline changes required to update the protocol so that more
-   secure algorithms can be used to create channel binding identities.
-   The extensibility of this solution also provides an eventual
-   replacement of identities based solely on hash algorithms.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
-   3.  Channel binding hash agility . . . . . . . . . . . . . . . . .  5
-   4.  Security considerations  . . . . . . . . . . . . . . . . . . .  7
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                     Expires May 12, 2008                  [Page 2]
-
-Internet-Draft        Channel Binding Hash Agility         November 2007
-
-
-1.  Introduction
-
-   With the recently discovered weaknesses in the MD5 hash algorithm
-   there is a need to move stronger hash alogrithms.  Kerberos Version 5
-   Generic Security Services Application Programming Interface (GSS-API)
-   mechanism [RFC4121] uses MD5 to calculate channel binding identities
-   that are required to be unique.  This document specifies an update to
-   the mechanism that allows it to create channel binding identities
-   based on negotiating algorithms securely.  This will prevent lengthy
-   standardizations in the future when new attacks arise and will allow
-   an incremental update to the protocol so that this will interoperate
-   with older implementations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                     Expires May 12, 2008                  [Page 3]
-
-Internet-Draft        Channel Binding Hash Agility         November 2007
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   The term "little endian order" is used for brevity to refer to the
-   least-significant-octet-first encoding, while the term "big endian
-   order" is for the most-significant-octet-first encoding.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                     Expires May 12, 2008                  [Page 4]
-
-Internet-Draft        Channel Binding Hash Agility         November 2007
-
-
-3.  Channel binding hash agility
-
-   When generating a channel binding identifier, Bnd, a hash is computed
-   from the channel binding information.  Initiators MUST populate the
-   Bnd field in order to maintain interoperability with existing
-   acceptors.  In addition, initiators MUST populate the extension
-   field, Exts, with TYPED-DATA as defined in [RFC4120].  The 0x8003 GSS
-   checksum MUST have the following structure:
-
-      Octet     Name       Description
-      -----------------------------------------------------------------
-      0..3      Lgth       Number of octets in Bnd field;  Represented
-                            in little-endian order;  Currently contains
-                            hex value 10 00 00 00 (16).
-      4..19     Bnd        Channel binding information, as described in
-                            section 4.1.1.2 [RFC4121].
-      20..23    Flags      Four-octet context-establishment flags in
-                            little-endian order as described in section
-                            4.1.1.1 [RFC4121].
-      24..25    DlgOpt     The delegation option identifier (=1) in
-                            little-endian order [optional].  This field
-                            and the next two fields are present if and
-                            only if GSS_C_DELEG_FLAG is set as described
-                            in section 4.1.1.1 [RFC4121].
-      26..27    Dlgth      The length of the Deleg field in
-                            little-endian order [optional].
-      28..(n-1) Deleg      KRB_CRED message (n = Dlgth + 28) [optional].
-      n..last   Exts       Extensions
-
-      where Exts is the concatenation of zero, one or more individual
-      extensions, each of which consists of:
-        type -- big endian order unsigned integer, 32-bits
-        length -- big endian order unsigned integer, 32-bits
-        data -- octet string of length octets
-      in that order
-
-   When channel binding is used the Exts MUST include the following
-   extension:
-
-      data-type 0x00000000
-
-      data-value
-
-         The output obtained by applying the Kerberos V get_mic()
-         operation [RFC3961], using the sub-session key from the
-         authenticator and key usage number TBD, to the channel binding
-         data as described in [RFC4121], section 4.1.1.2 (using get_mic
-         instead of MD5).
-
-
-
-Emery                     Expires May 12, 2008                  [Page 5]
-
-Internet-Draft        Channel Binding Hash Agility         November 2007
-
-
-   Initiators that are unwilling to use a MD5 hash of the channel
-   bindings should set the Bnd field to all ones (1).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                     Expires May 12, 2008                  [Page 6]
-
-Internet-Draft        Channel Binding Hash Agility         November 2007
-
-
-4.  Security considerations
-
-   Initiators do not know if the acceptor had ignored channel bindings
-   or whether it validated the MD5 hash of the channel bindings
-   [RFC4121].
-
-   Ultimately, it is up to the application whether to use channel
-   binding or not.  This is dependent upon the security policy of these
-   applications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                     Expires May 12, 2008                  [Page 7]
-
-Internet-Draft        Channel Binding Hash Agility         November 2007
-
-
-5.  IANA Considerations
-
-   The IANA is hereby requested to create a new registry of "Kerberos V
-   GSS-API mechanism extension types" with four-field entries (type
-   number, type name, description, and normative reference) and,
-   initially, a single registration: 0x00000000, "Channel Binding MIC,"
-   "Extension for hash function-agile channel binding," <this RFC>.
-
-   Registration of additional extensions SHALL be by IESG Protocol
-   Action.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                     Expires May 12, 2008                  [Page 8]
-
-Internet-Draft        Channel Binding Hash Agility         November 2007
-
-
-6.  Acknowledgements
-
-   Larry Zhu helped in the review of this document overall and provided
-   the suggestions of typed data and server acknowledgement.
-
-   Nicolas Williams and Sam Hartman suggested that the Bnd and Exts
-   fields be populated simultaneously.
-
-   Nicolas Williams and Jeffrey Hutzelman had also suggested a number
-   changes to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                     Expires May 12, 2008                  [Page 9]
-
-Internet-Draft        Channel Binding Hash Agility         November 2007
-
-
-7.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                     Expires May 12, 2008                 [Page 10]
-
-Internet-Draft        Channel Binding Hash Agility         November 2007
-
-
-Author's Address
-
-   Shawn Emery
-   Sun Microsystems
-   500 Eldorado Blvd
-   M/S UBRM05-171
-   Broomfield, CO  80021
-   US
-
-   Email: shawn.emery@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                     Expires May 12, 2008                 [Page 11]
-
-Internet-Draft        Channel Binding Hash Agility         November 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Emery                     Expires May 12, 2008                 [Page 12]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-04.txt b/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-04.txt
deleted file mode 100644
index 54f093802..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-04.txt
+++ /dev/null
@@ -1,673 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                           S. Emery
-Internet-Draft                                          Sun Microsystems
-Updates: 4121 (if approved)                                July 14, 2008
-Intended status: Standards Track
-Expires: January 15, 2009
-
-
-        Kerberos Version 5 GSS-API Channel Binding Hash Agility
-              draft-ietf-krb-wg-gss-cb-hash-agility-04.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 15, 2009.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                   Expires January 15, 2009                [Page 1]
-
-Internet-Draft        Channel Binding Hash Agility             July 2008
-
-
-Abstract
-
-   Currently, channel bindings are implemented using a MD5 hash in the
-   Kerberos Version 5 Generic Security Services Application Programming
-   Interface (GSS-API) mechanism [RFC4121].  This document updates
-   RFC4121 to allow the channel binding restriction to be lifted using
-   algorithms negotiated based on Kerberos crypto framework as defined
-   in RFC3961.  In addition, because this update makes use of the last
-   extensible field in the Kerberos client-server exchange message,
-   extensions are defined to allow future protocol extensions.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
-   3.  Channel binding hash agility . . . . . . . . . . . . . . . . .  5
-   4.  Security considerations  . . . . . . . . . . . . . . . . . . .  7
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                   Expires January 15, 2009                [Page 2]
-
-Internet-Draft        Channel Binding Hash Agility             July 2008
-
-
-1.  Introduction
-
-   With the recently discovered weaknesses in the MD5 hash algorithm
-   there is a need to use stronger hash algorithms.  Kerberos Version 5
-   Generic Security Services Application Programming Interface (GSS-API)
-   mechanism [RFC4121] uses MD5 to calculate channel binding verifiers.
-   This document specifies an update to the mechanism that allows it to
-   create channel binding information based on negotiating algorithms
-   securely.  This will allow deploying new algorithms incrementally
-   without break interoperability with older implementations, when new
-   attacks arise in the future.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                   Expires January 15, 2009                [Page 3]
-
-Internet-Draft        Channel Binding Hash Agility             July 2008
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   The term "little endian order" is used for brevity to refer to the
-   least-significant-octet-first encoding, while the term "big endian
-   order" is for the most-significant-octet-first encoding.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                   Expires January 15, 2009                [Page 4]
-
-Internet-Draft        Channel Binding Hash Agility             July 2008
-
-
-3.  Channel binding hash agility
-
-   When generating a channel binding verifier, Bnd, a hash is computed
-   from the channel binding fields.  Initiators MUST populate the Bnd
-   field in order to maintain interoperability with existing acceptors.
-   In addition, initiators MUST populate the extension field, Exts, with
-   TYPED-DATA as defined in [RFC4120].  All fields before Exts, do not
-   change from what is described in [RFC4121], they are listed for
-   convenience.  The 0x8003 GSS checksum MUST have the following
-   structure:
-
-      Octet     Name       Description
-      -----------------------------------------------------------------
-      0..3      Lgth       Number of octets in Bnd field;  Represented
-                            in little-endian order;  Currently contains
-                            hex value 10 00 00 00 (16).
-      4..19     Bnd        Channel binding information, as described in
-                            section 4.1.1.2 [RFC4121].
-      20..23    Flags      Four-octet context-establishment flags in
-                            little-endian order as described in section
-                            4.1.1.1 [RFC4121].
-      24..25    DlgOpt     The delegation option identifier (=1) in
-                            little-endian order [optional].  This field
-                            and the next two fields are present if and
-                            only if GSS_C_DELEG_FLAG is set as described
-                            in section 4.1.1.1 [RFC4121].
-      26..27    Dlgth      The length of the Deleg field in
-                            little-endian order [optional].
-      28..(n-1) Deleg      KRB_CRED message (n = Dlgth + 28) [optional].
-      n..last   Exts       Extensions
-
-      where Exts is the concatenation of zero, one or more individual
-      extensions, each of which consists of, in order:
-
-      type -- big endian order unsigned integer, 32-bits, which contains
-              the type of extension
-      data -- octet string of extension information
-
-      If multiple extensions are present then there MUST be at most one
-      instance of a given extension type.
-
-   When channel binding is used the Exts MUST include the following
-   extension:
-
-
-
-
-
-
-
-
-Emery                   Expires January 15, 2009                [Page 5]
-
-Internet-Draft        Channel Binding Hash Agility             July 2008
-
-
-      data-type 0x00000000
-
-      data-value
-
-         The output obtained by applying the Kerberos V get_mic()
-         operation [RFC3961], using the sub-session key from the
-         authenticator and key usage number 43, to the channel binding
-         data as described in [RFC4121], section 4.1.1.2 (using get_mic
-         instead of MD5).
-
-   Initiators that are unwilling to use a MD5 hash of the channel
-   bindings MUST set the Bnd field to sixteen octets of hex value FF.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                   Expires January 15, 2009                [Page 6]
-
-Internet-Draft        Channel Binding Hash Agility             July 2008
-
-
-4.  Security considerations
-
-   Initiators do not know if the acceptor had ignored channel bindings
-   or whether it validated the MD5 hash of the channel bindings
-   [RFC4121].
-
-   Ultimately, it is up to the application whether to use channel
-   binding or not.  This is dependent upon the security policy of these
-   applications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                   Expires January 15, 2009                [Page 7]
-
-Internet-Draft        Channel Binding Hash Agility             July 2008
-
-
-5.  IANA Considerations
-
-   The IANA is hereby requested to create a new registry of "Kerberos V
-   GSS-API mechanism extension types" with four-field entries (type
-   number, type name, description, and normative reference) and,
-   initially, a single registration: 0x00000000, "Channel Binding MIC,"
-   "Extension for the verifier of the channel bindings," <this RFC>.
-
-   Using the guidelines for allocation as described in [RFC5226], type
-   number assignments are as follows:
-
-      0x00000000 - 0x000003FF IETF Consensus
-
-      0x00000400 - 0xFFFFF3FF Specification Required
-
-      0xFFFFF400 - 0xFFFFFFFF Private Use
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                   Expires January 15, 2009                [Page 8]
-
-Internet-Draft        Channel Binding Hash Agility             July 2008
-
-
-6.  Acknowledgements
-
-   Larry Zhu helped in the review of this document overall and provided
-   the suggestions of typed-data.
-
-   Nicolas Williams and Sam Hartman suggested that the Bnd and Exts
-   fields be populated simultaneously.
-
-   Nicolas Williams and Jeffrey Hutzelman had also suggested a number
-   changes to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                   Expires January 15, 2009                [Page 9]
-
-Internet-Draft        Channel Binding Hash Agility             July 2008
-
-
-7.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
-              May 2008.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                   Expires January 15, 2009               [Page 10]
-
-Internet-Draft        Channel Binding Hash Agility             July 2008
-
-
-Author's Address
-
-   Shawn Emery
-   Sun Microsystems
-   500 Eldorado Blvd
-   M/S UBRM05-171
-   Broomfield, CO  80021
-   US
-
-   Email: shawn.emery@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                   Expires January 15, 2009               [Page 11]
-
-Internet-Draft        Channel Binding Hash Agility             July 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-Emery                   Expires January 15, 2009               [Page 12]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-05.txt b/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-05.txt
deleted file mode 100644
index 313236dda..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-gss-cb-hash-agility-05.txt
+++ /dev/null
@@ -1,673 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                           S. Emery
-Internet-Draft                                          Sun Microsystems
-Updates: 4121 (if approved)                             November 3, 2008
-Intended status: Standards Track
-Expires: May 7, 2009
-
-
-        Kerberos Version 5 GSS-API Channel Binding Hash Agility
-              draft-ietf-krb-wg-gss-cb-hash-agility-05.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on May 7, 2009.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                      Expires May 7, 2009                  [Page 1]
-
-Internet-Draft        Channel Binding Hash Agility         November 2008
-
-
-Abstract
-
-   Currently, channel bindings are implemented using a MD5 hash in the
-   Kerberos Version 5 Generic Security Services Application Programming
-   Interface (GSS-API) mechanism [RFC4121].  This document updates
-   RFC4121 to allow channel bindings using algorithms negotiated based
-   on Kerberos crypto framework as defined in RFC3961.  In addition,
-   because this update makes use of the last extensible field in the
-   Kerberos client-server exchange message, extensions are defined to
-   allow future protocol extensions.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
-   3.  Channel binding hash agility . . . . . . . . . . . . . . . . .  5
-   4.  Security considerations  . . . . . . . . . . . . . . . . . . .  7
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                      Expires May 7, 2009                  [Page 2]
-
-Internet-Draft        Channel Binding Hash Agility         November 2008
-
-
-1.  Introduction
-
-   With the recently discovered weaknesses in the MD5 hash algorithm
-   there is a need to use stronger hash algorithms.  Kerberos Version 5
-   Generic Security Services Application Programming Interface (GSS-API)
-   mechanism [RFC4121] uses MD5 to calculate channel binding verifiers.
-   This document specifies an update to the mechanism that allows it to
-   create channel binding information based on negotiated algorithms.
-   This will allow deploying new algorithms incrementally without break
-   interoperability with older implementations, when new attacks arise
-   in the future.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                      Expires May 7, 2009                  [Page 3]
-
-Internet-Draft        Channel Binding Hash Agility         November 2008
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   The term "little endian order" is used for brevity to refer to the
-   least-significant-octet-first encoding, while the term "big endian
-   order" is for the most-significant-octet-first encoding.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                      Expires May 7, 2009                  [Page 4]
-
-Internet-Draft        Channel Binding Hash Agility         November 2008
-
-
-3.  Channel binding hash agility
-
-   When generating a channel binding verifier, Bnd, a hash is computed
-   from the channel binding fields.  Initiators MUST populate the Bnd
-   field in order to maintain interoperability with existing acceptors.
-   In addition, initiators MUST populate the extension field, Exts.  All
-   fields before "Exts" do not change from what is described in
-   [RFC4121], they are listed for convenience.  The 0x8003 GSS checksum
-   MUST have the following structure:
-
-      Octet     Name       Description
-      -----------------------------------------------------------------
-      0..3      Lgth       Number of octets in Bnd field;  Represented
-                            in little-endian order;  Currently contains
-                            hex value 10 00 00 00 (16).
-      4..19     Bnd        Channel binding information, as described in
-                            section 4.1.1.2 [RFC4121].
-      20..23    Flags      Four-octet context-establishment flags in
-                            little-endian order as described in section
-                            4.1.1.1 [RFC4121].
-      24..25    DlgOpt     The delegation option identifier (=1) in
-                            little-endian order [optional].  This field
-                            and the next two fields are present if and
-                            only if GSS_C_DELEG_FLAG is set as described
-                            in section 4.1.1.1 [RFC4121].
-      26..27    Dlgth      The length of the Deleg field in
-                            little-endian order [optional].
-      28..(n-1) Deleg      KRB_CRED message (n = Dlgth + 28) [optional].
-      n..last   Exts       Extensions
-
-      where Exts is the concatenation of zero, one or more individual
-      extensions, each of which consists of, in order:
-
-        type -- big endian order unsigned integer, 32-bits, which
-                contains the type of extension
-        length -- big endian order unsigned integer, 32-bits, which
-                contains the length, in octets, of the extension data
-                encoded as an array of octets immediately following this
-                field
-        data -- octet string of extension information
-      in that order
-
-      If multiple extensions are present then there MUST be at most one
-      instance of a given extension type.
-
-   When channel binding is used the Exts MUST include the following
-   extension:
-
-
-
-
-Emery                      Expires May 7, 2009                  [Page 5]
-
-Internet-Draft        Channel Binding Hash Agility         November 2008
-
-
-      data-type 0x00000000
-
-      data-value
-
-         The output obtained by applying the Kerberos V get_mic()
-         operation [RFC3961], using the sub-session key from the
-         authenticator and key usage number 43, to the channel binding
-         data as described in [RFC4121], section 4.1.1.2 (using get_mic
-         instead of MD5).
-
-   Initiators that are unwilling to use a MD5 hash of the channel
-   bindings MUST set the Bnd field to sixteen octets of hex value FF.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                      Expires May 7, 2009                  [Page 6]
-
-Internet-Draft        Channel Binding Hash Agility         November 2008
-
-
-4.  Security considerations
-
-   Initiators do not know if the acceptor had ignored channel bindings
-   or whether it validated the MD5 hash of the channel bindings
-   [RFC4121].
-
-   Ultimately, it is up to the application whether to use channel
-   binding or not.  This is dependent upon the security policy of these
-   applications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                      Expires May 7, 2009                  [Page 7]
-
-Internet-Draft        Channel Binding Hash Agility         November 2008
-
-
-5.  IANA Considerations
-
-   The IANA is hereby requested to create a new registry of "Kerberos V
-   GSS-API mechanism extension types" with four-field entries (type
-   number, type name, description, and normative reference) and,
-   initially, a single registration: 0x00000000, "Channel Binding MIC,"
-   "Extension for the verifier of the channel bindings," <this RFC>.
-
-   Using the guidelines for allocation as described in [RFC5226], type
-   number assignments are as follows:
-
-      0x00000000 - 0x000003FF IETF Consensus
-
-      0x00000400 - 0xFFFFF3FF Specification Required
-
-      0xFFFFF400 - 0xFFFFFFFF Private Use
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                      Expires May 7, 2009                  [Page 8]
-
-Internet-Draft        Channel Binding Hash Agility         November 2008
-
-
-6.  Acknowledgements
-
-   Larry Zhu helped in the review of this document overall and provided
-   the suggestions of typed-data.
-
-   Nicolas Williams and Sam Hartman suggested that the Bnd and Exts
-   fields be populated simultaneously.
-
-   Nicolas Williams and Jeffrey Hutzelman had also suggested a number
-   changes to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                      Expires May 7, 2009                  [Page 9]
-
-Internet-Draft        Channel Binding Hash Agility         November 2008
-
-
-7.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
-              May 2008.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                      Expires May 7, 2009                 [Page 10]
-
-Internet-Draft        Channel Binding Hash Agility         November 2008
-
-
-Author's Address
-
-   Shawn Emery
-   Sun Microsystems
-   500 Eldorado Blvd
-   M/S UBRM05-171
-   Broomfield, CO  80021
-   US
-
-   Email: shawn.emery@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Emery                      Expires May 7, 2009                 [Page 11]
-
-Internet-Draft        Channel Binding Hash Agility         November 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-Emery                      Expires May 7, 2009                 [Page 12]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-gss-crypto-00.txt b/doc/standardisation/draft-ietf-krb-wg-gss-crypto-00.txt
deleted file mode 100644
index a1466b8e5..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-gss-crypto-00.txt
+++ /dev/null
@@ -1,562 +0,0 @@
-
-
-
-
-
-
-
-
-
-Internet-Draft                                                K. Raeburn
-Kerberos Working Group                                               MIT
-Updates: RFC 1964                                        August 13, 2003
-Document: draft-ietf-krb-wg-gss-crypto-00.txt  expires February 13, 2004
-
-                 General Kerberos Cryptosystem Support
-                  for the Kerberos 5 GSSAPI Mechanism
-
-Abstract
-
-   This document describes an update to the Kerberos 5 mechanism for
-   GSSAPI to allow the use of Kerberos-defined cryptosystems directly in
-   GSSAPI messages, without requiring further changes for each new
-   encryption or checksum algorithm that complies with the Kerberos
-   crypto framework specifications.
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026 [RFC2026]. 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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-1. Introduction
-
-   Kerberos defines an encryption and checksum framework [KCRYPTO] that
-   provides for complete specification and enumeration of cryptosystem
-   specifications in a general way, to be used within Kerberos and
-   associated protocols.  The GSSAPI Kerberos 5 mechanism definition
-   [GSSAPI-KRB5] sets up a framework for enumerating encryption and
-   checksum types, independently of how such schemes may be used in
-   Kerberos, thus requiring updates for any new encryption or checksum
-   algorithm not directly compatible with those already defined.
-
-
-
-
-Raeburn                                                         [Page 1]
-
-INTERNET DRAFT                                               August 2003
-
-
-   This document describes an update to [GSSAPI-KRB5] to allow the use
-   of any Kerberos-defined cryptosystems directly in GSSAPI messages,
-   without requiring further changes for each new encryption or checksum
-   algorithm that complies with the framework specifications, and
-   without making assumptions concerning block sizes or other
-   characteristics of the underlying encryption operations.
-
-2. Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119.
-
-3. New Algorithm Identifiers
-
-   Two new sealing algorithm numbers and one new signing algorithm
-   number are defined, for use in MIC, Wrap and Delete tokens.
-
-
-                 type          name          octet values
-                 -----------------------------------------
-                 seal   KERBEROS5-ENCRYPT       00 01
-                 sign   KERBEROS5-CHECKSUM      00 01
-                 sign          NONE             ff ff
-
-
-   The KERBEROS5-ENCRYPT algorithm encrypts using the Kerberos
-   encryption type [KCRYPTO] indicated by the encryption key type (using
-   the session key or initiator's subkey, as described in [GSSAPI-
-   KRB5]), with a key usage value KG_USAGE_SEAL, defined below.  All
-   Kerberos encryption types provide for integrity protection, and
-   specify any padding that might be required; neither needs to be done
-   at the GSS mechanism level when KERBEROS5-ENCRYPT is used.  When
-   KERBEROS5-ENCRYPT is used as the seal algorithm, the sign algorithm
-   MUST be NONE.
-
-   The signing algorithm value NONE MUST be used only with a sealing
-   algorithm that incorporates integrity protection; currently,
-   KERBEROS5-ENCRYPT is the only such sealing algorithm.
-
-   The KERBEROS5-CHECKSUM signing algorithm MAY be used in other cases.
-   The contents of the SGN_CKSUM field are determined by computing a
-   Kerberos checksum [KCRYPTO], using the session key or subkey, and a
-   key usage value of KG_USAGE_SIGN.  The Kerberos checksum algorithm to
-   be used is the required-to-implement checksum algorithm associated
-   with the encryption key type.  It should be noted that the checksum
-   input data in this case is not the same as the "to-be-signed data"
-   described in section 1.2.1.1 of [GSSAPI-KRB5]; see below.
-
-
-
-Raeburn                                                         [Page 2]
-
-INTERNET DRAFT                                               August 2003
-
-
-   The encryption or checksum output incorporated in the MIC and Wrap
-   tokens is the octet string output from the corresponding operation in
-   [KCRYPTO]; it should not be confused with the EncryptedData or
-   Checksum object in [KrbClar].
-
-   For purposes of key derivation, we add two new usage values to the
-   list defined in [KrbClar]; one for signing messages, and one for
-   sealing messages:
-
-
-                               name        value
-                           ----------------------
-                           KG_USAGE_SEAL    22
-                           KG_USAGE_SIGN    23
-
-
-4. Adjustments to Previous Definitions
-
-4.1. Quality of Protection
-
-   The GSSAPI specification [GSSAPI] says that a zero QOP value
-   indicates the "default".  The original specification for the Kerberos
-   5 mechanism says that a zero QOP value (or a QOP value with the
-   appropriate bits clear) means DES encryption.
-
-   Since the quality of protection cannot be improved without fully
-   reauthenticating with a stronger key type, the QOP value is now
-   ignored.
-
-4.2. Message Layout
-
-   The definitions of the MIC and Wrap tokens in [GSSAPI-KRB5] assumed
-   an 8-byte checksum size, and a CBC-mode block cipher with an 8-byte
-   block size, without integrity protection.  In the crypto framework
-   described in [KCRYPTO], integrity protection is built into the
-   encryption operations.  CBC mode is not assumed, and indeed there may
-   be no initial vector to supply.  While the operations are performed
-   on messages of specific sizes, the underlying cipher may be a stream
-   cipher.
-
-   We modify the message definitions such that the portions after the
-   first 8 bytes (which specify the token identification and the signing
-   and sealing algorithms) are defined by the algorithms chosen.  The
-   remaining bytes must convey sequence number and direction
-   information, and must protect the integrity of the token id and
-   algorithm indicators.  For the DES-based algorithms specified in
-   [GSSAPI-KRB5], the definition for the remaining data is backwards
-   compatible.
-
-
-
-Raeburn                                                         [Page 3]
-
-INTERNET DRAFT                                               August 2003
-
-
-   The revised message descriptions are thus as follows:
-
-
-                                MIC token
-          Byte #    Name         Description
-          -------------------------------------------------------
-            0..1    TOK_ID       Identification field (01 01).
-            2..3    SGN_ALG      Integrity algorithm indicator.
-            4..7    Filler       Contains ff ff ff ff
-            8..N                 Dependent on SGN_ALG.
-
-          If SGN_ALG is 0000, 0100, 0200:
-            8..15   SND_SEQ      Sequence number/direction
-                                 field, encrypted.
-           16..23   SGN_CKSUM    Checksum of bytes 0..7 and
-                                 application data, as described
-                                 in [GSSAPI-KRB5].
-          If SGN_ALG is 0001:
-            8..15   SND_SEQ      Sequence number/direction
-                                 field, NOT encrypted.
-           16..N    SGN_CKSUM    Checksum of bytes 0..15 and
-                                 application data, with key
-                                 usage KG_USAGE_SIGN.
-
-
-      Suggestions from Microsoft: Moving to 64-bit sequence numbers
-      would be better for long sessions with many messages.  Using the
-      direction flag to perturb the encryption or integrity protection
-      is safer than simply including a flag which a buggy but mostly
-      working implementation might fail to check.
-
-      I am considering changing to use 64-bit sequence numbers, and
-      omitting the direction flag from the transmitted cleartext data.
-      How it would factor into the encrypted Wrap token, I haven't
-      figured out yet.
-
-      - Change the key usage values based on the direction?  It's
-      suggested in [KCRYPTO], perhaps not strongly enough, that the key
-      usage numbers should perturb the key, but DES ignores them,
-      although DES shouldn't use this extension.
-
-      - Add a direction flag byte in encrypted data?  Either depends on
-      an implementor remembering to add the check.  Adding it to
-      checksummed data requires that the implementor get it right.
-
-      - Generate one or two new keys using PRF and random-to-key
-      operations, using different keys for each direction?  Pulling the
-      DK function out of the simplified profile is probably not a good
-
-
-
-Raeburn                                                         [Page 4]
-
-INTERNET DRAFT                                               August 2003
-
-
-      way to do this.
-
-   The filler bytes are included in the checksum calculation for
-   simplicity.  There is no security benefit from including them.
-
-   In the Wrap token, the initial bytes, sequence number and direction
-   are incorporated into the data to be encrypted.  In most cases, this
-   is likely to be more efficient in terms of space and computing power
-   than using unencrypted sequence number and direction fields, adding a
-   checksum, and doing the additional work to authenticate that the
-   checksum and encrypted data are part of the same message.  (The
-   framework in [KCRYPTO] has no support for integrity protection of a
-   block of data only some of which is encrypted, except by treating the
-   two portions independently and using some additional means to ensure
-   that the two parts continue to be associated with one another.)
-
-   The length is also included, as a 4-byte value in network byte order,
-   because the decryption operation in the Kerberos crypto framework
-   does not recover the exact length of the original input.  Thus,
-   messages with application data larger than 4 gigabytes are not
-   supported.
-
-      [Q: Should this length be 8 bytes?  ASN.1 wrapper?]
-
-
-                                Wrap token
-       Byte #      Name         Description
-       -------------------------------------------------------------
-         0..1      TOK_ID       Identification field (02 01).
-         2..3      SGN_ALG      Integrity algorithm indicator.
-         4..5      SEAL_ALG     Sealing algorithm indicator.
-         6..7      Filler       Contains ff ff
-         8..last                Dependent on SEAL_ALG and SGN_ALG.
-
-       If SEAL_ALG is 0000:
-         8..15     SND_SEQ      Encrypted sequence number field.
-        16..23     SGN_CKSUM    Checksum of plaintext padded data,
-                                calculated according to algorithm
-                                specified in SGN_ALG field.  (RFC
-                                1964)
-        24..last   Data         Encrypted padded data.
-
-       If SEAL_ALG is 0001 and SGN_ALG is ffff:
-         8..last   Data         Encrypted bytes 0..5, 2-byte
-                                direction flag, sequence number,
-                                4-byte data length, and data.
-
-
-
-
-
-Raeburn                                                         [Page 5]
-
-INTERNET DRAFT                                               August 2003
-
-
-       If SEAL_ALG is ffff, and SGN_ALG is 0000, 0100, 0200:
-         8..15     SND_SEQ      Encrypted sequence number field.
-        16..23     SGN_CKSUM    Checksum of plaintext padded data,
-                                as in RFC 1964.
-        24..last   Data         plaintext padded data
-
-       If SEAL_ALG if ffff, and SGN_ALG is 0001:
-         8..15     SND_SEQ      Sequence number/direction field,
-                                NOT encrypted.
-        16..N      SGN_CKSUM    Checksum of bytes 0..15 and
-                                application data, with key usage
-                                KG_USAGE_SIGN.
-       N+1..last   Data         plaintext data
-
-
-   The direction flag, as in [GSSAPI-KRB5], is made up of bytes
-   indicating the party sending the token: 00 for the context initiator,
-   or hex FF for the context acceptor.  In the KERBEROS5-ENCRYPT case,
-   only two bytes are used, and they replace the fixed filler bytes of
-   the token header, which need no protection; this reduces slightly the
-   redundancy of the data transmitted.
-
-   The context-deletion token is essentially a MIC token with no user
-   data and a different TOK_ID value.  Thus, its modification is
-   straightforward.
-
-
-                          Context deletion token
-          Byte #    Name         Description
-          -------------------------------------------------------
-            0..1    TOK_ID       Identification field (01 02).
-            2..3    SGN_ALG      Integrity algorithm indicator.
-            4..7    Filler       Contains ff ff ff ff
-
-          If SGN_ALG is 0000, 0100, 0200:
-            8..15   SND_SEQ      Sequence number/direction
-                                 field, encrypted.
-           16..23   SGN_CKSUM    Checksum of bytes 0..7, as
-                                 described in [GSSAPI-KRB5].
-
-          If SGN_ALG is 0001:
-            8..15   SND_SEQ      Sequence number/direction
-                                 field, NOT encrypted.
-           16..N    SGN_CKSUM    Checksum of bytes 0..15, with
-                                 key usage KG_USAGE_SIGN.
-
-
-
-
-
-
-Raeburn                                                         [Page 6]
-
-INTERNET DRAFT                                               August 2003
-
-
-5. Backwards Compatibility Considerations
-
-   The context initiator should request of the KDC credentials using
-   session-key cryptosystem types supported by that implementation; if
-   the only types returned by the KDC are not supported by the mechanism
-   implementation, it should indicate a failure.  This may seem obvious,
-   but early implementations of both Kerberos and the GSSAPI Kerberos
-   mechanism supported only DES keys, so the cryptosystem compatibility
-   question was easy to overlook.
-
-   Under the current mechanism, no negotiation of algorithm types
-   occurs, so server-side (acceptor) implementations cannot request that
-   clients not use algorithm types not understood by the server.
-   However, administration of the server's Kerberos data (e.g., the
-   service key) has to be done in communication with the KDC, and it is
-   from the KDC that the client will request credentials.  The KDC could
-   therefore be given the task of limiting session keys for a given
-   service to types actually supported by the Kerberos and GSSAPI
-   software on the server.
-
-   This does have a drawback for cases where a service principal name is
-   used both for GSSAPI-based and non-GSSAPI-based communication (most
-   notably the "host" service key), if the GSSAPI implementation does
-   not understand (for example) AES but the Kerberos implementation
-   does.  It means that AES session keys cannot be issued for that
-   service principal, which keeps the protection of non-GSSAPI services
-   weaker than necessary.
-
-   It would also be possible to have clients attempt to get DES session
-   keys before trying to get AES session keys, and have the KDC refuse
-   to issue the DES keys only for the most critical of services, for
-   which DES protection is considered inadequate.  However, that would
-   eliminate the possibility of connecting with the more secure
-   cryptosystem to any service that can be accessed with the weaker
-   cryptosystem.  We thus recommend the former approach, putting the
-   burden on the KDC administration and gaining the best protection
-   possible for GSSAPI services, possibly at the cost of weaker
-   protection of non-GSSAPI Kerberos services sharing service principal
-   names with GSSAPI services that have not been updated to support this
-   extension.
-
-   [optional:]
-
-   This mechanism extension MUST NOT be used with the DES encryption key
-   types described in [KCRYPTO], which ignore the key usage values.
-
-
-
-
-
-
-Raeburn                                                         [Page 7]
-
-INTERNET DRAFT                                               August 2003
-
-
-6. Implementation Note
-
-   At least two implementations have been done of extensions to the RFC
-   1964 mechanism for specific non-DES encryption types.  These are not
-   standards-track extensions, but implementors may wish to implement
-   them as well for compatibility with existing products.  No guidance
-   is provided as to when an implementation may wish to use these non-
-   standard extensions instead of the extension specified in this
-   document.
-
-7. Security Considerations
-
-   Various tradeoffs arise regarding the mixing of new and old software,
-   or GSSAPI-based and non-GSSAPI Kerberos authentication.  They are
-   discussed in section 5.
-
-   Remember to check direction flag.  Key usage numbers and direction
-   checks?  Considerations depend on the approach taken....
-
-8. Acknowledgements
-
-   Larry Zhu...
-
-9. Normative References
-
-   [GSSAPI]
-      Linn, J., "Generic Security Service Application Program Interface
-      Version 2, Update 1", RFC 2743, January, 2000.
-
-   [GSSAPI-KRB5]
-      Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
-      June, 1996.
-
-   [KCRYPTO]
-      draft-ietf-krb-wg-crypto-XX -> RFC xxxx
-
-   [KrbClar]
-      draft-ietf-krb-wg-kerberos-clarifications-XX -> RFC xxxx
-
-   [RFC2026]
-      RFC 2026 ...
-
-   [RFC2119]
-      RFC 2119 ...
-
-
-
-
-
-
-
-Raeburn                                                         [Page 8]
-
-INTERNET DRAFT                                               August 2003
-
-
-10. Author's Address
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-Document Change History
-
-Version -XX:
-
-   Split up Abstract and create a real Introduction.  Fix RFC 2026
-   reference in Status section.  Added Conventions, Acknowledgements and
-   Implementation Note sections.  Updated References with more
-   placeholders.  Capitalize some uses of "must" etc.
-
-   Fill in case of Wrap token without integrity protection, using
-   KERBEROS5-CHECKSUM for SGN_ALG.  Fix descriptions of which message
-   layout is used for which algorithms.
-
-
-
-
-Raeburn                                                         [Page 9]
-
-INTERNET DRAFT                                               August 2003
-
-
-   Remove discussion of authenticated encryption with additional data.
-
-   Add discussion of 64-bit sequence numbers and data length, and
-   alternate handling of the direction flag.
-
-
-   Version -XX sent in early 2003 to Kerberos working group:
-
-   Initial revision.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 10]
diff --git a/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-01.txt b/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-01.txt
deleted file mode 100644
index a13f67c5a..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-01.txt
+++ /dev/null
@@ -1,816 +0,0 @@
-
-
-<Kerberos Working Group>                                      Larry Zhu 
-Internet Draft                                       Karthik Jaganathan 
-Updates: 1964                                                 Microsoft 
-Category: Standards Track                                   Sam Hartman 
-draft-ietf-krb-wg-gssapi-cfx-01.txt                                 MIT 
-                                                        August 29, 2003 
-                                             Expires: February 29, 2004 
- 
-          The Kerberos Version 5 GSS-API Mechanism: Version 2 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-      all provisions of Section 10 of [RFC-2026].  
-    
-   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."  
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-    
-1. Abstract 
-    
-   [RFC-1964] defines protocols, procedures, and conventions to be 
-   employed by peers implementing the Generic Security Service 
-   Application Program Interface (as specified in [RFC-2743]) when 
-   using the Kerberos Version 5 mechanism (as specified in [KRBCLAR]). 
-    
-   This memo obsoletes [RFC-1964] and proposes changes in response to 
-   recent developments such as the introduction of Kerberos crypto 
-   framework.  It is intended that this memo or a subsequent version 
-   will become the Kerberos Version 5 GSS-API mechanism specification 
-   on the standards track. 
-    
-2. Conventions used in this document 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
-   document are to be interpreted as described in [RFC-2119]. 
-    
-3. Introduction 
-    
-   [KCRYPTO] defines a generic framework for describing encryption and 
-   checksum types to be used with the Kerberos protocol and associated 
-   protocols. 
-    
-  
-Zhu              Standards Trace - February 16, 2003                1 
-                  Kerberos Version 5 GSS-API      August 2003 
- 
- 
-   [RFC-1964] describes the GSSAPI mechanism for Kerberos V5.  It 
-   defines the format of context initiation, per-message and context 
-   deletion tokens and uses algorithm identifiers for each cryptosystem 
-   in per message and context deletion tokens.   
-    
-   The approach taken in this document obviates the need for algorithm 
-   identifiers.  This is accomplished by using the same encryption and 
-   checksum algorithms specified by the crypto profile [KCRYPTO] for 
-   the session key or subkey that is created during context 
-   negotiation.  Message layouts of the per-message and context 
-   deletion tokens are therefore revised to remove algorithm indicators 
-   and also to add extra information to support the generic crypto 
-   framework [KCRYPTO].  
-    
-   Tokens transferred between GSS-API peers for security context 
-   initiation are also described in this document.  The data elements 
-   exchanged between a GSS-API endpoint implementation and the Kerberos 
-   KDC are not specific to GSS-API usage and are therefore defined 
-   within [KRBCLAR] rather than within this specification. 
-    
-   The new token formats specified in this memo MUST be used with all 
-   "newer" encryption types [KRBCLAR] and MAY be used with "older" 
-   encryption types, provided that the initiator and acceptor know, 
-   from the context establishment, that they can both process these new 
-   token formats. 
-    
-   "Newer" encryption types are those which have been specified along 
-   with or since the new Kerberos cryptosystem specification [KCRYPTO] 
-   [KRBCLAR]. 
-    
-   Note that in this document, "AES" is used for brevity to refer 
-   loosely to either aes128-cts-hmac-sha1-96 or aes256-cts-hmac-sha1-96 
-   as defined in [AES-KRB5].  AES is used as an example of the new 
-   method defined in this document. 
-    
-4. Key Derivation for Per-Message and Context Deletion Tokens 
-    
-   To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 
-   "entropy-preserving" derived keys, for different purposes or key 
-   usages, from a base key or protocol key.  This document defines four 
-   key usage values below for signing and sealing messages: 
-    
-        Name                         value 
-      ------------------------------------- 
-       KG-USAGE-ACCEPTOR-SEAL         22 
-       KG-USAGE-ACCEPTOR-SIGN         23 
-       KG-USAGE-INITIATOR-SEAL        24 
-       KG-USAGE-INITIATOR-SIGN        25 
-          
-   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 
-   used as the usage number in the key derivation function for deriving 
-   keys to be used in MIC and context deletion tokens, and KG-USAGE-
-   ACCEPTOR-SEAL is used for Wrap tokens; similarly when the sender is 
-   the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage 
-
-Zhu              Standards Track - February 16, 2004                2 
-                  Kerberos Version 5 GSS-API      August 2003 
- 
- 
-   number in the key derivation function for MIC and context deletion 
-   tokens, KG-USAGE-INITIATOR-SEAL is used for Wrap Tokens.  Even if 
-   the Wrap token does not provide for confidentiality the same usage 
-   values specified above are used. 
-    
-5. Quality of Protection 
- 
-   The GSSAPI specification [RFC-2743] provides for Quality of 
-   Protection (QOP) values that can be used by the application to 
-   request a certain type of encryption or signing.  A zero QOP value 
-   is used to indicate the "default" protection; applications which use 
-   the default QOP are not guaranteed to be portable across 
-   implementations or even inter-operate with different deployment 
-   configurations of the same implementation.  Using an algorithm that 
-   is different from the one for which the key is defined may not be 
-   appropriate.  Therefore, when the new method in this document is 
-   used, the QOP value is ignored. 
-    
-   The encryption and checksum algorithms in per-message and context 
-   deletion tokens are now implicitly defined by the algorithms 
-   associated with the session key or subkey.  Algorithms identifiers 
-   as described in [RFC-1964] are therefore no longer needed and 
-   removed from the new token headers. 
- 
-6. Token Framing 
-    
-   Per [RFC-2743], all tokens emitted by the Kerberos V5 GSS-API 
-   mechanism will have the framing shown below: 
-    
-      GSS-API DEFINITIONS ::= 
- 
-      BEGIN 
- 
-      MechType ::= OBJECT IDENTIFIER 
-      -- representing Kerberos V5 mechanism 
- 
-      GSSAPI-Token ::= 
-      -- option indication (delegation, etc.) indicated within 
-      -- mechanism-specific token 
-      [APPLICATION 0] IMPLICIT SEQUENCE { 
-              thisMech MechType, 
-              innerToken ANY DEFINED BY thisMech 
-                 -- contents mechanism-specific 
-                 -- ASN.1 structure not required 
-              } 
-      END 
-    
-   The innerToken field always starts with a two byte token-identifier 
-   (TOK_ID).  Here are the TOK_ID values: 
-    
-         Token                       TOK_ID Value in hex 
-        ------------------------------------------- 
-         KRB_AP_REQUEST                 01 00 
-         KRB_AP_REQPLY                  02 00 
-
-Zhu              Standards Track - February 16, 2004                3 
-                  Kerberos Version 5 GSS-API      August 2003 
- 
- 
-         KRB_ERROR                      03 00 
-         [RFC-1964] MIC                 01 01 
-         [RFC-1964] Wrap                01 02 
-         [RFC-1964] context deletion    02 01  
-         MIC                            04 04 
-         Wrap                           04 05 
-         context deletion               05 04 
-             
-    
-7. Context Initialization Tokens 
-    
-   For context initialization tokens, the body for the innerToken field 
-   contains a Kerberos V5 message (KRB_AP_REQUEST, KRB_AP_REPLY, or 
-   KRB_ERROR) as defined in [KRBCLAR].   
-    
-7.1. Authenticator Checksum 
- 
-   The authenticator in the KRB_AP_REQ message MUST include the 
-   optional sequence number and the checksum field.  The checksum field 
-   is used to convey service flags, channel binding, and optional 
-   delegation information.  It MUST have a type of 0x8003.  The length 
-   of the checksum MUST be 24 bytes when delegation is not used.  When 
-   delegation is used, a TGT with its FORWARDABLE flag set will be 
-   transferred within the KRB_CRED [KRBCLAR] message. 
-    
-   The format of the authenticator checksum field is as follows. 
-       
-      Byte    Name      Description 
-     ----------------------------------------------------------------- 
-      0..3    Lgth    Number of bytes in Bnd field; 
-                      Currently contains hex 10 00 00 00 
-                      (16, represented in little-endian form) 
-      4..19   Bnd     MD5 hash of channel bindings, taken over all  
-                      non-null components of bindings, in order  
-                      of declaration.  Integer fields within channel  
-                      bindings are represented in little-endian order  
-                      for the purposes of the MD5 calculation. 
-      20..23  Flags   Bit vector of context-establishment flags, 
-                      as defined next. The resulting bit vector is  
-                      encoded into bytes 20..23 in little-endian form. 
-      24..25  DlgOpt  The Delegation Option identifier (=1) [optional] 
-      26..27  Dlgth   The length of the Deleg field [optional] 
-      28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional] 
-  
-   [we need to get input on how to allow additional data for 
-   extensions.  Nicolas will post some text for this.  If that is the 
-   case, do we need to change the checksum type?] 
- 
-7.1.1. Flags Field 
- 
-   The checksum flags are used to convey service options or extension 
-   negotiation information.  The bits in the Flags field are allocated 
-   as follows (Most significant bit is bit 0): 
-    
-Zhu              Standards Track - February 16, 2004                4 
-                  Kerberos Version 5 GSS-API      August 2003 
- 
- 
-      Bit         Name          Description                  
-    ---------------------------------------------------- 
-      0..11     Mandatory     Critical extension flags 
-      12..15    Optional      Non-critical extension flags 
-      16..31    Standard      Context establishment flags 
-     
-   An extension or context establishment flag can either be critical or 
-   non-critical.  When the context initiator desires a particular 
-   extension or context establishment flag (either critical or non-
-   critical) it sets the appropriate checksum flag.  The context 
-   acceptor MUST ignore unsupported non-critical extensions or flags in 
-   the initiator's context token (i.e., acceptors MUST NOT return an 
-   error just because there were unsupported non-critical extensions or 
-   flags in the initiator's token).  The acceptor MUST return 
-   GSS_S_UNAVAILABLE [RFC-2743] if there are unsupported critical 
-   extensions or flags in the initiator's context token. 
-     
-   The following context establishment flags are defined in [RFC-2744] 
-    
-        Flag Name                Value     
-      --------------------------------- 
-       GSS_C_DELEG_FLAG           1        
-       GSS_C_MUTUAL_FLAG          2       
-       GSS_C_REPLAY_FLAG          4       
-       GSS_C_SEQUENCE_FLAG        8        
-       GSS_C_CONF_FLAG           16      
-       GSS_C_INTEG_FLAG          32     
-       GSS_C_ANON_FLAG           64 
-        
-   Context establishment flags are exposed to the calling application.  
-   If the calling application desires a particular service option then 
-   it requests that option via GSS_Init_sec_context().  An 
-   implementation that supports a particular extension SHOULD then set 
-   the appropriate flag in the checksum Flags field. 
-    
-   All existing context establishment flags are non-critical, and it is 
-   possible that a new context establishment flag can be added as a 
-   critical flag. 
-    
-7.1.2. Channel Binding Information 
- 
-   In computing the contents of the "Bnd" field, the following detailed 
-   points apply:  
-    
-   (1) Each integer field shall be formatted into four bytes, using 
-   little-endian byte ordering, for purposes of MD5 hash computation.  
-    
-   (2) All input length fields within gss_buffer_desc [RFC-2744] 
-   elements of a gss_channel_bindings_struct [RFC-2744], even those 
-   which are zero-valued, shall be included in the hash calculation; 
-   the value elements of gss_buffer_desc elements shall be 
-   dereferenced, and the resulting data shall be included within the 
-   hash computation, only for the case of gss_buffer_desc elements 
-   having non-zero length specifiers.  
-
-Zhu              Standards Track - February 16, 2004                5 
-                  Kerberos Version 5 GSS-API      August 2003 
- 
- 
-    
-   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 
-   valid channel bindings structure, the Bnd field shall be set to 16 
-   zero-valued bytes.  
- 
-   [Nicolas suggested that the only change that might be needed here 
-   was the use of SHA1 instead of MD5] 
- 
-8. Per-Message and Context Deletion Tokens 
-    
-   The new per-message and context deletion token formats defined in 
-   this document are designed to accommodate the requirements of newer 
-   crypto systems.  The token layouts have also been designed to 
-   facilitate scatter-gather and in-place encryption without incurring 
-   significant performance penalties for implementations that do not 
-   allow for either scatter-gather or in-place encryption.   
-    
-   The design along with the rationale behind it is discussed in detail 
-   in the following sections. 
-    
-8.1. Sequence Number and Direction Indicator 
- 
-   The sequence number for any per-message or context deletion token is 
-   a 64 bit integer (expressed in big endian order).  One separate flag 
-   is used as the direction-indicator as described in section 8.2.  
-   Both the sequence number and the direction-indicator are protected 
-   by the encryption and checksum procedures as specified in section 
-   8.4.  
- 
-8.2. Flags Field 
- 
-   The Flags field is a one-byte bit vector used to indicate a set of 
-   attributes.  The meanings of the flags are: 
-    
-        Bit    Name             Description 
-       --------------------------------------------------------------- 
-        0     SentByAcceptor  When set, this flag indicates the sender  
-                              is the context acceptor.  When not set, 
-                              it indicates the sender is the context  
-                              initiator. 
-        1     Sealed          When set in Wrap tokens, this flag  
-                              indicates confidentiality is provided  
-                              for.  It MUST not be set in MIC and  
-                              context deletion tokens. 
-    
-   The rest of available bits are reserved for future use. 
-    
-8.3. EC Field 
- 
-   The EC (Extra Count) field is a two-byte integer field expressed in 
-   big endian order.   
-    
-
-
-Zhu              Standards Track - February 16, 2004                6 
-                  Kerberos Version 5 GSS-API      August 2003 
- 
- 
-   In Wrap tokens with confidentiality, the EC field is used to encode 
-   the size (in bytes) of the random filler, as described in section 
-   8.4. 
-    
-   In Wrap tokens without confidentiality, the EC field is used to 
-   encode the size (in bytes) of the trailing checksum, as described in 
-   section 8.4.   
-    
-   When AES is used, the EC field contains the hex value 00 0C in Wrap 
-   tokens without confidentiality, and 00 00 in Wrap tokens with 
-   confidentiality.   
- 
-8.4. Encryption and Checksum Operations 
-    
-   The encryption algorithms defined by the crypto profiles provide for 
-   integrity protection.  Therefore no separate checksum is needed.  
-    
-   The result of decryption can be longer than the original plaintext 
-   [KCRYPTO] and the extra trailing bytes are called "crypto-system 
-   garbage".  However, given the size of any plaintext data, one can 
-   always find the next (possibly larger) size so that, when padding 
-   the to-be-encrypted text to that size, there will be no crypto-
-   system garbage added [KCRYPTO].  
-    
-   In Wrap tokens that provide for confidentiality, the "header" (the 
-   first 16 bytes of the Wrap token) is appended to the plaintext data 
-   before encryption.  Random filler is inserted between the plaintext-
-   data and the "header", and there SHALL NOT be crypto-system garbage 
-   added by the decryption operation.  The resulting Wrap token is 
-   {"header" | encrypt(plaintext-data | random-filler | "header")}, 
-   where encrypt() is the encryption operation (which provides for 
-   integrity protection) defined in the crypto profile [KCRYPTO].   
-    
-   [A note from the design team (Sam, Nicolas, Ken, JK and Larry):  
-   constraints need to be added to kcrypto to keep the header at the 
-   end of the decrypted data.  Without these constraints, we might have 
-   the header pre-pended to the front of the data and encode an 8 byte 
-   length for the plaintext data, which is less efficient.  
-    
-   Constraints to be added: Given the length of any plaintext data, 
-   there should always exist the next (possibly larger) size for which, 
-   when padding the to-be-encrypted data to that size, there will be no 
-   cryptosystem garbage added, and the number of bytes needed to pad to 
-   the next size is no larger than 64K.  This is a small addition to 
-   kcrypto and we will bring it up at the IETF last call for kcrypto] 
-    
-   In Wrap tokens that do not provide for confidentiality, the checksum 
-   is calculated over the plaintext data concatenated with the token 
-   header (the first 16 bytes of the Wrap token).  The resulting Wrap 
-   token is {"header" | plaintext-data | get_mic(plaintext-data | 
-   "header")},  where get_mic() is the checksum operation defined in 
-   the crypto profile [KCRYPTO].  
-    
-
-Zhu              Standards Track - February 16, 2004                7 
-                  Kerberos Version 5 GSS-API      August 2003 
- 
- 
-   The parameters for the key and the cipher-state in the encrypt() and 
-   get_mic() operations have been omitted for brevity.   
-        
-   The resulting Wrap tokens bind the data to the token header, 
-   including the sequence number and the directional indicator.  
-     
-   [With AEAD, Wrap tokens with confidentiality do not need to encrypt 
-   the header and the overhead can be reduced slightly] 
-   
-   For MIC tokens, the checksum is first calculated over the token 
-   header (the first 16 bytes of the MIC token) and then the to-be-
-   signed plaintext data.   
-   
-   For context deletion tokens, the checksum is calculated over the 
-   token header (the first 16 bytes of the context deletion token). 
-   
-   When AES is used, the checksum algorithm is HMAC_SHA1_96 and the 
-   checksum size is 12 bytes.  Data is pre-pended with a 16 byte 
-   confounder before encryption, and no padding is needed. 
-   
-8.5. RRC Field 
- 
-   The RRC (Right Rotation Count) field in Wrap tokens is added to 
-   allow the data to be encrypted in-place by existing [SSPI] 
-   applications that do not provide an additional buffer for the 
-   trailer (the cipher text after the in-place-encrypted data) in 
-   addition to the buffer for the header (the cipher text before the 
-   in-place-encrypted data).  The resulting Wrap token in the previous 
-   section, excluding the first 16 bytes of the token header, is 
-   rotated to the right by "RRC" bytes.  The net result is that "RRC" 
-   bytes of trailing octets are moved toward the header.  Consider the 
-   following as an example of this rotation operation: Assume that the 
-   RRC value is 3 and the token before the rotation is {"header" | aa | 
-   bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be 
-   {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb 
-   | cc |...| hh} is used to indicate the byte sequence. 
-  
-   The RRC field is expressed as a two-byte integer in big endian 
-   order. 
-    
-   The rotation count value is chosen by the sender based on 
-   implementation details, and the receiver MUST be able to interpret 
-   all possible rotation count values. 
- 
-8.6. Message Layout for Per-message and Context Deletion Tokens 
-    
-   The new message layouts are as follows. 
-    
-   MIC Token: 
-    
-      Byte no           Name           Description 
-       0..1            TOK_ID       Identification field. 
-                                    Tokens emitted by GSS_GetMIC()   
-                                    contain the hex value 04 04 in  
-
-Zhu              Standards Track - February 16, 2004                8 
-                  Kerberos Version 5 GSS-API      August 2003 
- 
- 
-                                    this field. 
-       2               Flags        Attributes field, as described in                 
-                                    Section 8.2. 
-       3..7            Filler       Contains 5 bytes of hex value FF. 
-       8..15           SND_SEQ      Sequence number field in  
-                                    cleartext, in big endian order.  
-       16..last        SGN_CKSUM    Checksum of byte 0..15 and the 
-                                    "to-be-signed" data, where the 
-                                    checksum algorithm is defined by      
-                                    the crypto profile for the  
-                                    session key or subkey. 
- 
-    
-   The Filler field is included in the checksum calculation for 
-   simplicity.  This is common to both MIC and context deletion token 
-   checksum calculations. 
- 
-   Wrap Token: 
-    
-      Byte no           Name           Description 
-       0..1            TOK_ID       Identification field. 
-                                    Tokens emitted by GSS_Wrap()                     
-                                    contain the hex value 05 04  
-                                    in this field. 
-       2               Flags        Attributes field, as described in                 
-                                    Section 8.2. 
-       3               Filler       Contains the hex value FF. 
-       4..5            EC           Contains the "extra count" field,   
-                                    in big endian order as described in  
-                                    section 8.3. 
-       6..7            RRC          Contains the "right rotation                      
-                                    count" in big endian order, as  
-                                    described in section 8.5. 
-       8..15           SND_SEQ      Sequence number field in                      
-                                    cleartext, in big endian order. 
-       16..last        Data         Encrypted data or (plaintext data +  
-                                    checksum), as described in section  
-                                    8.4, where the encryption or  
-                                    checksum algorithm is defined by  
-                                    the crypto profile for the session 
-                                    key or subkey. 
-                                    
-                                   
-   Context Deletion Token:       
-    
-      Byte no          Name             Description 
-       0..1           TOK_ID        Identification field. 
-                                    Tokens emitted by 
-                                    GSS_Delete_sec_context() contain 
-                                    the hex value 04 05 in this  
-                                    field. 
-       2              Flags         Attributes field, as described in                 
-                                    Section 8.2. 
-
-Zhu              Standards Track - February 16, 2004                9 
-                  Kerberos Version 5 GSS-API      August 2003 
- 
- 
-       3..7           Filler        Contains 5 bytes of hex value FF. 
-       8..15          SND_SEQ       Sequence number field in  
-                                    cleartext, in big endian order.  
-       16..N          SGN_CKSUM     Checksum of byte 0..15, where the 
-                                    checksum algorithm is defined by      
-                                    the crypto profile for the  
-                                    session key or subkey. 
-    
-                                 
-9. Parameter Definitions 
-    
-   This section defines parameter values used by the Kerberos V5 GSS-
-   API mechanism. It defines interface elements in support of 
-   portability, and assumes use of C language bindings per [RFC-2744]. 
-    
-9.1. Minor Status Codes 
- 
-   This section recommends common symbolic names for minor_status 
-   values to be returned by the Kerberos V5 GSS-API mechanism.  Use of 
-   these definitions will enable independent implementers to enhance 
-   application portability across different implementations of the 
-   mechanism defined in this specification.  (In all cases, 
-   implementations of GSS_Display_status() will enable callers to 
-   convert minor_status indicators to text representations.)  Each 
-   implementation should make available, through include files or other 
-   means, a facility to translate these symbolic names into the 
-   concrete values which a particular GSS-API implementation uses to 
-   represent the minor_status values specified in this section.  
-    
-   It is recognized that this list may grow over time, and that the 
-   need for additional minor_status codes specific to particular 
-   implementations may arise.  It is recommended, however, that 
-   implementations should return a minor_status value as defined on a 
-   mechanism-wide basis within this section when that code is 
-   accurately representative of reportable status rather than using a 
-   separate, implementation-defined code.  
-    
-9.1.1. Non-Kerberos-specific codes 
- 
-      GSS_KRB5_S_G_BAD_SERVICE_NAME  
-              /* "No @ in SERVICE-NAME name string" */ 
-      GSS_KRB5_S_G_BAD_STRING_UID 
-              /* "STRING-UID-NAME contains nondigits" */ 
-      GSS_KRB5_S_G_NOUSER 
-              /* "UID does not resolve to username" */ 
-      GSS_KRB5_S_G_VALIDATE_FAILED 
-              /* "Validation error" */ 
-      GSS_KRB5_S_G_BUFFER_ALLOC 
-              /* "Couldn't allocate gss_buffer_t data" */ 
-      GSS_KRB5_S_G_BAD_MSG_CTX 
-              /* "Message context invalid" */ 
-      GSS_KRB5_S_G_WRONG_SIZE 
-              /* "Buffer is the wrong size" */ 
-      GSS_KRB5_S_G_BAD_USAGE 
-
-Zhu              Standards Track - February 16, 2004               10 
-                  Kerberos Version 5 GSS-API      August 2003 
- 
- 
-              /* "Credential usage type is unknown" */ 
-      GSS_KRB5_S_G_UNKNOWN_QOP 
-              /* "Unknown quality of protection specified" */ 
-    
-9.1.2. Kerberos-specific-codes 
-    
-      GSS_KRB5_S_KG_CCACHE_NOMATCH  
-              /* "Principal in credential cache does not match desired  
-                 name" */ 
-      GSS_KRB5_S_KG_KEYTAB_NOMATCH 
-              /* "No principal in keytab matches desired name" */ 
-      GSS_KRB5_S_KG_TGT_MISSING 
-              /* "Credential cache has no TGT" */ 
-      GSS_KRB5_S_KG_NO_SUBKEY 
-              /* "Authenticator has no subkey" */ 
-      GSS_KRB5_S_KG_CONTEXT_ESTABLISHED 
-              /* "Context is already fully established" */ 
-      GSS_KRB5_S_KG_BAD_SIGN_TYPE 
-              /* "Unknown signature type in token" */ 
-      GSS_KRB5_S_KG_BAD_LENGTH 
-              /* "Invalid field length in token" */ 
-      GSS_KRB5_S_KG_CTX_INCOMPLETE 
-              /* "Attempt to use incomplete security context" */ 
- 
-9.2. Buffer Sizes 
- 
-   All implementations of this specification shall be capable of 
-   accepting buffers of at least 16K bytes as input to GSS_GetMIC(), 
-   GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting 
-   the output_token generated by GSS_Wrap() for a 16K byte input buffer 
-   as input to GSS_Unwrap().  Support for larger buffer sizes is 
-   optional but recommended. 
- 
-10. Backwards Compatibility Considerations 
- 
-   The new token formats defined in this document will only be 
-   recognized by new implementations.  To address this, implementations 
-   can always use the explicit sign or seal algorithm in [GSSAPI-KRB5] 
-   when the key type corresponds to "older" algorithms.  An alternative 
-   approach might be to retry sending the message with the sign or seal 
-   algorithm explicitly defined as in [GSSAPI-KRB5].  However this 
-   would require the use of a mechanism such as [RFC-2478] to securely 
-   negotiate the algorithm or the use out of band mechanism to choose 
-   appropriate algorithms.  For this reason, it is RECOMMENDED that the 
-   new token formats defined in this document can be used only if both 
-   peers are known during context negotiation to support the new 
-   mechanism (either because of the use of "new" enctypes or because of 
-   the use of Kerberos V extensions). 
- 
-11. Security Considerations 
- 
-   It is possible that the KDC returns a session-key type that is not 
-   supported by the GSSAPI implementation (either on the client and the 
-   server). In this case the implementation MUST not try to use the key 
-
-Zhu              Standards Track - February 16, 2004               11 
-                  Kerberos Version 5 GSS-API      August 2003 
- 
- 
-   with a supported cryptosystem. This will ensure that no security 
-   weaknesses arise due to the use of an inappropriate key with an 
-   encryption algorithm. 
-    
-   In addition the security problem described in [3DES] arising from 
-   the use of a service implementation with a GSSAPI mechanism 
-   supporting only DES and a Kerberos mechanism supporting both DES and 
-   Triple DES is actually a more generic one.  It arises whenever the 
-   GSSAPI implementation does not support a stronger cryptosystem 
-   supported by the Kerberos mechanism.  KDC administrators desiring to 
-   limit the session key types to support interoperability with such 
-   GSSAPI implementations should carefully weigh the reduction in 
-   protection offered by such mechanisms against the benefits of 
-   interoperability. 
-    
-    
-12. Acknowledgments 
-   
-  The authors wish to acknowledge the contributions from the following 
-  individuals:  
- 
-  Ken Raeburn and Nicolas Willams corrected many of our errors in the 
-  use of generic profiles and were instrumental in the creation of this 
-  draft.  
-   
-  Sam Hartman and Ken Raeburn suggested the "floating trailer" idea.   
-   
-  Sam Hartman and Nicolas Williams recommended the replacing our 
-  earlier key derivation function for directional keys with different 
-  key usage numbers for each direction as well as retaining the 
-  directional bit for maximum compatibility.   
-   
-  Paul Leach provided numerous suggestions and comments.  
-   
-  Scott Field, Richard Ward, Dan Simon also provided valuable inputs on 
-  this draft. 
- 
-13. References 
-    
-13.1. Normative References 
-    
-   [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 
-   3", BCP 9, RFC 2026, October 1996.  
-        
-   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 
-   Requirement Levels", BCP 14, RFC 2119, March 1997. 
-    
-   [AES] National Institute of Standards and Technology, U.S. 
-   Department of Commerce, "Advanced Encryption Standard", Federal 
-   Information Processing Standards Publication 197, Washington, DC, 
-   November 2001. 
-    
-
-
-Zhu              Standards Track - February 16, 2004               12 
-                  Kerberos Version 5 GSS-API      August 2003 
- 
- 
-   [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
-   raeburn-krb-rijndael-krb-05.txt, June 2003.  Work in progress. 
-    
-   [3DES] Raeburn, K., "Triple-DES Support for the Kerberos 5 GSSAPI    
-   Mechanism", draft-raeburn-gssapi-krb5-3des-XX.txt in the MIT    
-   distribution, June 2000. 
-    
-   [RFC-2743] Linn, J., "Generic Security Service Application Program    
-   Interface Version 2, Update 1", RFC 2743, January 2000. 
-    
-   [RFC-2744] Wray, J., "Generic Security Service API Version 2 : C-
-   bindings", RFC 2744, January 2000. 
-    
-   [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",    
-   RFC 1964, June 1996. 
-    
-   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 
-   Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003.  Work in 
-   progress.  
-    
-   [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,    
-   Raeburn, K., "The Kerveros Network Authentication Service (V5)",    
-   draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002. 
-   Work in progress. 
-    
-   [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
-   Negotiation Mechanism.", RFC 2478, December 1998. 
- 
-13.2. Informative References 
- 
-   [SSPI] Leach, P., Security Service Provider Interface, MSDN, April 
-   2003 
-    
-14. Author's Address 
-    
-   Larry Zhu 
-   One Microsoft Way 
-   Redmond, WA 98052 - USA 
-   EMail: LZhu@microsoft.com 
- 
-   Karthik Jaganathan 
-   One Microsoft Way 
-   Redmond, WA 98052 - USA 
-   EMail: karthikj@microsoft.com 
- 
-   Sam Hartman 
-   Massachusetts Institute of Technology 
-   77 Massachusetts Avenue 
-   Cambridge, MA 02139 - USA 
-   Email: hartmans@MIT.EDU 
-    
-    
-Zhu              Standards Track - February 16, 2004               13 
-                  Kerberos Version 5 GSS-API      August 2003 
- 
- 
-    
-Full Copyright Statement 
-    
-   "Copyright (C) The Internet Society (date). All Rights Reserved. 
-    
-   This document and translations of it may be copied and          
-   furnished to others, and derivative works that comment on or          
-   otherwise explain it or assist in its implementation may be          
-   prepared, copied, published and distributed, in whole or in          
-   part, without restriction of any kind, provided that the above          
-   copyright notice and this paragraph are included on all such          
-   copies and derivative works.  However, this document itself may          
-   not be modified in any way, such as by removing the copyright          
-   notice or references to the Internet Society or other Internet          
-   organizations, except as needed for the purpose of developing          
-   Internet standards in which case the procedures for copyrights          
-   defined in the Internet Standards process must be followed, or          
-   as required to translate it into languages other than English. 
-    
-   The limited permissions granted above are perpetual and will          
-   not be revoked by the Internet Society or its successors or          
-   assigns. 
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu              Standards Track - February 16, 2004               14 
\ No newline at end of file
diff --git a/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-02.txt b/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-02.txt
deleted file mode 100644
index 96fe594f4..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-02.txt
+++ /dev/null
@@ -1,883 +0,0 @@
-
- 
-
-<Network Working Group>                                       Larry Zhu 
-Internet Draft                                       Karthik Jaganathan 
-Updates: 1964                                                 Microsoft 
-Category: Standards Track                                   Sam Hartman 
-draft-ietf-krb-wg-gssapi-cfx-02.txt                                 MIT 
-                                                     September 29, 2003 
-                                                Expires: March 29, 2004 
- 
-          The Kerberos Version 5 GSS-API Mechanism: Version 2 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of [RFC-2026].  
-    
-   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."  
-    
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt.   
-    
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-Abstract 
-    
-   This memo defines protocols, procedures, and conventions to be 
-   employed by peers implementing the Generic Security Service 
-   Application Program Interface (GSS-API as specified in [RFC-2743]) 
-   when using the Kerberos Version 5 mechanism (as specified in 
-   [KRBCLAR]). 
-    
-   [RFC-1964] is updated and incremental changes are proposed in 
-   response to recent developments such as the introduction of Kerberos 
-   crypto framework [KCRYPTO].  These changes support the inclusion of 
-   new cryptosystems based on crypto profiles [KCRYPTO], by defining 
-   new per-message and context-deletion tokens along with their 
-   encryption and checksum algorithms.   
-    
-Conventions used in this document 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
-   document are to be interpreted as described in [RFC-2119]. 
-    
-1. Introduction 
-    
-
-  
-Zhu                         Internet Draft                           1 
-                 Kerberos Version 5 GSS-API      September 2003 
- 
- 
-   [KCRYPTO] defines a generic framework for describing encryption and 
-   checksum types to be used with the Kerberos protocol and associated 
-   protocols. 
-    
-   [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.  
-   It defines the format of context initiation, per-message and context 
-   deletion tokens and uses algorithm identifiers for each cryptosystem 
-   in per message and context deletion tokens.   
-    
-   The approach taken in this document obviates the need for algorithm 
-   identifiers.  This is accomplished by using the same encryption and 
-   checksum algorithms specified by the crypto profile [KCRYPTO] for 
-   the session key or subkey that is created during context 
-   negotiation.  Message layouts of the per-message and context 
-   deletion tokens are therefore revised to remove algorithm indicators 
-   and also to add extra information to support the generic crypto 
-   framework [KCRYPTO].  
-    
-   Tokens transferred between GSS-API peers for security context 
-   initiation are also described in this document.  The data elements 
-   exchanged between a GSS-API endpoint implementation and the Kerberos 
-   KDC are not specific to GSS-API usage and are therefore defined 
-   within [KRBCLAR] rather than within this specification. 
-    
-   The new token formats specified in this memo MUST be used with all 
-   "newer" encryption types [KRBCLAR] and MAY be used with "older" 
-   encryption types, provided that the initiator and acceptor know, 
-   from the context establishment, that they can both process these new 
-   token formats. 
-    
-   "Newer" encryption types are those which have been specified along 
-   with or since the new Kerberos cryptosystem specification [KCRYPTO], 
-   as defined in section 3.1.3 of [KRBCLAR]. 
-    
-   Note that in this document, the term "little endian order" is used 
-   for brevity to refer to the least-significant-byte-first encoding, 
-   while the term "big endian order" is for the most-significant-byte-
-   first encoding. 
-    
-2. Key Derivation for Per-Message and Context Deletion Tokens 
-    
-   To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 
-   "entropy-preserving" derived keys, for different purposes or key 
-   usages, from a base key or protocol key.  This document defines four 
-   key usage values below for signing and sealing messages: 
-    
-        Name                         Value 
-      ------------------------------------- 
-       KG-USAGE-ACCEPTOR-SEAL         22 
-       KG-USAGE-ACCEPTOR-SIGN         23 
-       KG-USAGE-INITIATOR-SEAL        24 
-       KG-USAGE-INITIATOR-SIGN        25 
-          
-
-Zhu                         Internet Draft                           2 
-                 Kerberos Version 5 GSS-API      September 2003 
- 
- 
-   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 
-   used as the usage number in the key derivation function for deriving 
-   keys to be used in MIC and context deletion tokens, and KG-USAGE-
-   ACCEPTOR-SEAL is used for Wrap tokens; similarly when the sender is 
-   the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage 
-   number in the key derivation function for MIC and context deletion 
-   tokens, KG-USAGE-INITIATOR-SEAL is used for Wrap Tokens.  Even if 
-   the Wrap token does not provide for confidentiality the same usage 
-   values specified above are used. 
-    
-   During context initiation, the acceptor MAY assert a subkey, and if 
-   so, subsequent messages MUST use this subkey as the protocol key and 
-   these messages MUST be flagged as "AcceptorSubkey" as described in 
-   section 4.2.2. 
-    
-3. Quality of Protection 
- 
-   The GSS-API specification [RFC-2743] provides for Quality of 
-   Protection (QOP) values that can be used by applications to request 
-   a certain type of encryption or signing.  A zero QOP value is used 
-   to indicate the "default" protection; applications which use the 
-   default QOP are not guaranteed to be portable across implementations 
-   or even inter-operate with different deployment configurations of 
-   the same implementation.  Using an algorithm that is different from 
-   the one for which the key is defined may not be appropriate.  
-   Therefore, when the new method in this document is used, the QOP 
-   value is ignored. 
-    
-   The encryption and checksum algorithms in per-message and context 
-   deletion tokens are now implicitly defined by the algorithms 
-   associated with the session key or subkey.  Algorithms identifiers 
-   as described in [RFC-1964] are therefore no longer needed and 
-   removed from the new token headers. 
- 
-4. Definitions and Token Formats 
-    
-   This section provides terms and definitions, as well as descriptions 
-   for tokens specific to the Kerberos Version 5 GSS-API mechanism. 
-    
-4.1. Initial Context Tokens 
-    
-   Per [RFC-2743], all context initiation tokens emitted by the 
-   Kerberos V5 GSS-API mechanism will have the framing shown below: 
-    
-         GSS-API DEFINITIONS ::= 
-    
-         BEGIN 
-    
-         MechType ::= OBJECT IDENTIFIER 
-         -- representing Kerberos V5 mechanism 
-    
-         GSSAPI-Token ::= 
-         -- option indication (delegation, etc.) indicated within 
-         -- mechanism-specific token 
-
-Zhu                         Internet Draft                           3 
-                 Kerberos Version 5 GSS-API      September 2003 
- 
- 
-         [APPLICATION 0] IMPLICIT SEQUENCE { 
-                 thisMech MechType, 
-                 innerToken ANY DEFINED BY thisMech 
-                    -- contents mechanism-specific 
-                    -- ASN.1 structure not required 
-                 } 
-    
-         END 
-    
-   The innerToken field starts with a two-byte token-identifier 
-   (TOK_ID) expressed in big endian order, followed by a Kerberos 
-   message.   
-    
-   Here are the TOK_ID values used in the initial tokens: 
-    
-         Token               TOK_ID Value in Hex  
-        ----------------------------------------- 
-         KRB_AP_REQUEST        01 00 
-         KRB_AP_REPLY          02 00 
-         KRB_ERROR             03 00 
-             
-   Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR 
-   are defined in [KRBCLAR].   
-    
-   If an unknown token ID is received in the first context token, the 
-   receiver MUST return GSS_S_CONTINUE_NEEDED major status, and the 
-   returned output token MUST contain a KRB_ERROR message with the 
-   error code KRB_AP_ERR_MSG_TYPE [KRBCLAR]. 
-    
-4.1.1. Authenticator Checksum 
- 
-   The authenticator in the KRB_AP_REQ message MUST include the 
-   optional sequence number and the checksum field.  The checksum field 
-   is used to convey service flags, channel bindings, and optional 
-   delegation information.  It MUST have a type of 0x8003.  The length 
-   of the checksum MUST be 24 bytes when delegation is not used.  When 
-   delegation is used, a ticket-granting ticket will be transferred in 
-   a KRB_CRED message.  The ticket SHOULD have its forwardable flag 
-   set.  The KRB_CRED message MUST be encrypted in the session key of 
-   the ticket used to authenticate the context. 
-    
-   The format of the authenticator checksum field is as follows. 
-       
-      Byte    Name      Description 
-     ----------------------------------------------------------------- 
-      0..3    Lgth    Number of bytes in Bnd field;  Currently contains  
-                      hex value 10 00 00 00 (16, represented in little- 
-                      endian order) 
-      4..19   Bnd     Channel binding information, as describe in  
-                      section 4.1.1.2. 
-      20..23  Flags   Four-byte context-establishment flags in little- 
-                      endian order as described in section 4.1.1.1.  
-      24..25  DlgOpt  The Delegation Option identifier (=1) [optional] 
-      26..27  Dlgth   The length of the Deleg field [optional] 
-
-
-Zhu                         Internet Draft                           4 
-                 Kerberos Version 5 GSS-API      September 2003 
- 
- 
-      28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional] 
- 
-4.1.1.1. Checksum Flags Field 
-    
-   The checksum "Flags" field is used to convey service options or 
-   extension negotiation information.  The following context 
-   establishment flags are defined in [RFC-2744]. 
-    
-        Flag Name              Value     
-      --------------------------------- 
-       GSS_C_DELEG_FLAG           1        
-       GSS_C_MUTUAL_FLAG          2       
-       GSS_C_REPLAY_FLAG          4       
-       GSS_C_SEQUENCE_FLAG        8        
-       GSS_C_CONF_FLAG           16      
-       GSS_C_INTEG_FLAG          32     
-       GSS_C_ANON_FLAG           64 
-        
-   Context establishment flags are exposed to the calling application.  
-   If the calling application desires a particular service option then 
-   it requests that option via GSS_Init_sec_context() [RFC-2743].  An 
-   implementation that supports a particular option or extension SHOULD 
-   then set the appropriate flag in the checksum Flags field.   
-    
-   The receiver MUST ignore unknown checksum flags. 
-    
-4.1.1.2. Channel Binding Information 
- 
-   Channel bindings are user-specified tags to identify a given context 
-   to the peer application.  These tags are intended to be used to 
-   identify the particular communications channel that carries the 
-   context. 
-    
-   When using C language bindings, channel bindings are communicated to 
-   the GSS-API using the following structure [RFC-2744]: 
- 
-      typedef struct gss_channel_bindings_struct { 
-         OM_uint32       initiator_addrtype; 
-         gss_buffer_desc initiator_address; 
-         OM_uint32       acceptor_addrtype; 
-         gss_buffer_desc acceptor_address; 
-         gss_buffer_desc application_data; 
-      } *gss_channel_bindings_t; 
-    
-   The member fields and constants used for different address types are 
-   defined in [RFC-2744]. 
-    
-   The "Bnd" field contains the MD5 hash of channel bindings, taken 
-   over all non-null components of bindings, in order of declaration.  
-   Integer fields within channel bindings are represented in little-
-   endian order for the purposes of the MD5 calculation. 
-    
-   In computing the contents of the Bnd field, the following detailed 
-   points apply:  
-
-
-Zhu                         Internet Draft                           5 
-                 Kerberos Version 5 GSS-API      September 2003 
- 
- 
-    
-   (1) Each integer field shall be formatted into four bytes, using 
-   little endian byte ordering, for purposes of MD5 hash computation.  
-    
-   (2) All input length fields within gss_buffer_desc elements of a 
-   gss_channel_bindings_struct even those which are zero-valued, shall 
-   be included in the hash calculation; the value elements of 
-   gss_buffer_desc elements shall be dereferenced, and the resulting 
-   data shall be included within the hash computation, only for the 
-   case of gss_buffer_desc elements having non-zero length specifiers.  
-    
-   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 
-   valid channel binding structure, the Bnd field shall be set to 16 
-   zero-valued bytes.  
- 
-4.2. Per-Message and Context Deletion Tokens 
-    
-   Three classes of tokens are defined in this section:  "MIC" tokens, 
-   emitted by calls to GSS_GetMIC() and consumed by calls to 
-   GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and 
-   consumed by calls to GSS_Unwrap(), and context deletion tokens, 
-   emitted by calls to GSS_Delete_sec_context() and consumed by calls 
-   to GSS_Process_context_token(). 
-    
-   The new per-message and context deletion tokens introduced here do 
-   not include the pseudo ASN.1 header used by the initial context 
-   tokens.  These new tokens are designed to be used with newer crypto 
-   systems that can, for example, have variable-size checksums.   
-    
-4.2.1. Sequence Number and Direction Indicator 
- 
-   To distinguish intentionally-repeated messages from maliciously-
-   replayed ones, per-message and context deletion tokens contain a 
-   sequence number field, which is a 64 bit integer expressed in big 
-   endian order.  One separate bit is used as the direction-indicator 
-   in the Flags field as described in section 4.2.2, thus preventing an 
-   adversary from sending back the same message in the reverse 
-   direction and having it accepted.  Both the sequence number and the 
-   direction-indicator are protected by the encryption and checksum 
-   procedures specified in section 4.2.4.  
-    
-   After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's 
-   sequence numbers are incremented by one. 
- 
-4.2.2. Flags Field 
- 
-   The "Flags" field is a one-byte integer used to indicate a set of 
-   attributes.  The meanings of bits in this field (the least 
-   significant bit is bit 0) are as follows: 
-    
-        Bit    Name             Description 
-       --------------------------------------------------------------- 
-        0   SentByAcceptor    When set, this flag indicates the sender  
-                              is the context acceptor.  When not set, 
-
-
-Zhu                         Internet Draft                           6 
-                 Kerberos Version 5 GSS-API      September 2003 
- 
- 
-                              it indicates the sender is the context  
-                              initiator. 
-        1   Sealed            When set in Wrap tokens, this flag  
-                              indicates confidentiality is provided  
-                              for.  It SHALL NOT be set in MIC and  
-                              context deletion tokens. 
-        2   AcceptorSubkey    A subkey asserted by the context acceptor 
-                              is used to protect the message. 
-    
-   The rest of available bits are reserved for future use and MUST be 
-   cleared.  The receiver MUST ignore unknown flags. 
-    
-4.2.3. EC Field 
- 
-   The "EC" (Extra Count) field is a two-byte integer field expressed 
-   in big endian order.   
-    
-   In Wrap tokens with confidentiality, the EC field is used to encode 
-   the number of bytes in the filler, as described in section 4.2.4. 
-    
-   In Wrap tokens without confidentiality, the EC field is used to 
-   encode the number of bytes in the trailing checksum, as described in 
-   section 4.2.4.   
- 
-4.2.4. Encryption and Checksum Operations 
-    
-   The encryption algorithms defined by the crypto profiles provide for 
-   integrity protection [KCRYPTO].  Therefore no separate checksum is 
-   needed.  
-    
-   The result of decryption can be longer than the original plaintext 
-   [KCRYPTO] and the extra trailing bytes are called "crypto-system 
-   garbage".  However, given the size of any plaintext data, one can 
-   always find the next (possibly larger) size so that, when padding 
-   the to-be-encrypted text to that size, there will be no crypto-
-   system garbage added [KCRYPTO].  
-    
-   In Wrap tokens that provide for confidentiality, the first 16 bytes 
-   of the Wrap token (the "header") are appended to the plaintext data 
-   before encryption.  Filler bytes can be inserted between the 
-   plaintext-data and the "header", and the values and size of the 
-   filler octets are chosen by implementations, such that there is no 
-   crypto-system garbage present after the decryption.  The resulting 
-   Wrap token is {"header" | encrypt(plaintext-data | filler | 
-   "header")}, where encrypt() is the encryption operation (which 
-   provides for integrity protection) defined in the crypto profile 
-   [KCRYPTO], and the RRC field in the to-be-encrypted header contains 
-   the hex value 00 00.   
-           
-   In Wrap tokens that do not provide for confidentiality, the checksum 
-   is calculated first over the plaintext data, and then the first 16 
-   bytes of the Wrap token (the "header").  Both the EC field and the 
-   RRC field in the token header are filled with zeroes for the purpose 
-   of calculating the checksum.  The resulting Wrap token is {"header" 
-
-
-Zhu                         Internet Draft                           7 
-                 Kerberos Version 5 GSS-API      September 2003 
- 
- 
-   | plaintext-data | get_mic(plaintext-data | "header")},  where 
-   get_mic() is the checksum operation defined in the crypto profile 
-   [KCRYPTO].  
-    
-   The parameters for the key and the cipher-state in the encrypt() and 
-   get_mic() operations have been omitted for brevity.   
-        
-   For MIC tokens, the checksum is first calculated over the first 16 
-   bytes of the MIC token and then the to-be-signed plaintext data.   
-   
-   The resulting Wrap and MIC tokens bind the data to the token header, 
-   including the sequence number and the directional indicator.  
-   
-   For context deletion tokens, the checksum is calculated over the 
-   first 16 bytes of the token message. 
-   
-4.2.5. RRC Field 
- 
-   The "RRC" (Right Rotation Count) field in Wrap tokens is added to 
-   allow the data to be encrypted in-place by existing [SSPI] 
-   applications that do not provide an additional buffer for the 
-   trailer (the cipher text after the in-place-encrypted data) in 
-   addition to the buffer for the header (the cipher text before the 
-   in-place-encrypted data).  The resulting Wrap token in the previous 
-   section, excluding the first 16 bytes of the token header, is 
-   rotated to the right by "RRC" bytes.  The net result is that "RRC" 
-   bytes of trailing octets are moved toward the header.  Consider the 
-   following as an example of this rotation operation:  Assume that the 
-   RRC value is 3 and the token before the rotation is {"header" | aa | 
-   bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be 
-   {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb 
-   | cc |...| hh} is used to indicate the byte sequence. 
-  
-   The RRC field is expressed as a two-byte integer in big endian 
-   order. 
-    
-   The rotation count value is chosen by the sender based on 
-   implementation details, and the receiver MUST be able to interpret 
-   all possible rotation count values. 
- 
-4.2.6. Message Layouts 
-    
-   Per-message and context deletion token messages start with a two-
-   byte token identifier (TOK_ID) field, expressed in big endian order. 
-   These tokens are defined separately in subsequent sub-sections. 
-    
-4.2.6.1. MIC Tokens 
-    
-   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 as received.  The token has the following format: 
-    
-
-Zhu                         Internet Draft                           8 
-                 Kerberos Version 5 GSS-API      September 2003 
- 
-
-      Byte no     Name       Description 
-      -----------------------------------------------------------------  
-       0..1     TOK_ID     Identification field.  Tokens emitted by  
-                           GSS_GetMIC() contain the hex value 04 04  
-                           expressed in big endian order in this field. 
-       2        Flags      Attributes field, as described in section  
-                           4.2.2. 
-       3..7     Filler     Contains five bytes of hex value FF. 
-       8..15    SND_SEQ    Sequence number field in clear text,  
-                           expressed in big endian order.  
-       16..last SGN_CKSUM  Checksum of byte 0..15 and the "to-be- 
-                           signed" data, where the checksum algorithm  
-                           is defined by the crypto profile for the  
-                           session key or subkey. 
-    
-   The Filler field is included in the checksum calculation for 
-   simplicity.  This is common to both MIC and context deletion token 
-   checksum calculations. 
-    
-4.2.6.2. Wrap Tokens 
-    
-   Use of the GSS_Wrap() call yields a token, which consists of a 
-   descriptive header, followed by a body portion that contains either 
-   the input user data in plaintext concatenated with the checksum, or 
-   the input user data encrypted.  The GSS_Wrap() token has the 
-   following format: 
-    
-      Byte no     Name       Description 
-      --------------------------------------------------------------- 
-       0..1     TOK_ID     Identification field.  Tokens emitted by  
-                           GSS_Wrap() contain the the hex value 05 04                 
-                           expressed in big endian order in this field. 
-       2        Flags      Attributes field, as described in section  
-                           4.2.2. 
-       3        Filler     Contains the hex value FF. 
-       4..5     EC         Contains the "extra count" field, in big  
-                           endian order as described in section 4.2.3. 
-       6..7     RRC        Contains the "right rotation count" in big  
-                           endian order, as described in section 4.2.5. 
-       8..15    SND_SEQ    Sequence number field in clear text, 
-                           expressed in big endian order. 
-       16..last Data       Encrypted data for Wrap tokens with  
-                           confidentiality, or plaintext data followed  
-                           by the checksum for Wrap tokens without  
-                           confidentiality, as described in section  
-                           4.2.4, where the encryption or checksum 
-                           algorithm is defined by the crypto profile  
-                           for the session key or subkey. 
-                                   
-4.2.6.3. Context Deletion Tokens        
-    
-   The token emitted by GSS_Delete_sec_context() is based on the packet 
-   format for tokens emitted by GSS_GetMIC().  The context-deletion 
-   token has the following format: 
-    
-
-Zhu                         Internet Draft                           9 
-                 Kerberos Version 5 GSS-API      September 2003 
- 
- 
-      Byte no     Name       Description 
-      ----------------------------------------------------------------- 
-       0..1     TOK_ID     Identification field.  Tokens emitted by  
-                           GSS_Delete_sec_context() contain the hex  
-                           value 04 05 expressed in big endian order in  
-                           this field. 
-       2        Flags      Attributes field, as described in section  
-                           4.2.2. 
-       3..7     Filler     Contains five bytes of hex value FF. 
-       8..15    SND_SEQ    Sequence number field in clear text,  
-                           expressed in big endian order.  
-       16..N    SGN_CKSUM  Checksum of byte 0..15, where the checksum  
-                           algorithm is defined by the crypto profile  
-                           for the session key or subkey. 
-                                 
-5. Parameter Definitions 
-    
-   This section defines parameter values used by the Kerberos V5 GSS-
-   API mechanism. It defines interface elements in support of 
-   portability, and assumes use of C language bindings per [RFC-2744]. 
-    
-5.1. Minor Status Codes 
- 
-   This section recommends common symbolic names for minor_status 
-   values to be returned by the Kerberos V5 GSS-API mechanism.  Use of 
-   these definitions will enable independent implementers to enhance 
-   application portability across different implementations of the 
-   mechanism defined in this specification.  (In all cases, 
-   implementations of GSS_Display_status() will enable callers to 
-   convert minor_status indicators to text representations.)  Each 
-   implementation should make available, through include files or other 
-   means, a facility to translate these symbolic names into the 
-   concrete values which a particular GSS-API implementation uses to 
-   represent the minor_status values specified in this section.  
-    
-   It is recognized that this list may grow over time, and that the 
-   need for additional minor_status codes specific to particular 
-   implementations may arise.  It is recommended, however, that 
-   implementations should return a minor_status value as defined on a 
-   mechanism-wide basis within this section when that code is 
-   accurately representative of reportable status rather than using a 
-   separate, implementation-defined code.  
-    
-5.1.1. Non-Kerberos-specific codes 
- 
-      GSS_KRB5_S_G_BAD_SERVICE_NAME  
-              /* "No @ in SERVICE-NAME name string" */ 
-      GSS_KRB5_S_G_BAD_STRING_UID 
-              /* "STRING-UID-NAME contains nondigits" */ 
-      GSS_KRB5_S_G_NOUSER 
-              /* "UID does not resolve to username" */ 
-      GSS_KRB5_S_G_VALIDATE_FAILED 
-              /* "Validation error" */ 
-      GSS_KRB5_S_G_BUFFER_ALLOC 
-              /* "Couldn't allocate gss_buffer_t data" */ 
-
-
-Zhu                         Internet Draft                          10 
-                 Kerberos Version 5 GSS-API      September 2003 
- 
- 
-      GSS_KRB5_S_G_BAD_MSG_CTX 
-              /* "Message context invalid" */ 
-      GSS_KRB5_S_G_WRONG_SIZE 
-              /* "Buffer is the wrong size" */ 
-      GSS_KRB5_S_G_BAD_USAGE 
-              /* "Credential usage type is unknown" */ 
-      GSS_KRB5_S_G_UNKNOWN_QOP 
-              /* "Unknown quality of protection specified" */ 
-    
-5.1.2. Kerberos-specific-codes 
-    
-      GSS_KRB5_S_KG_CCACHE_NOMATCH  
-              /* "Client principal in credentials does not match   
-                 specified name" */ 
-      GSS_KRB5_S_KG_KEYTAB_NOMATCH 
-              /* "No key available for specified service principal" */ 
-      GSS_KRB5_S_KG_TGT_MISSING 
-              /* "No Kerberos ticket-granting ticket available" */ 
-      GSS_KRB5_S_KG_NO_SUBKEY 
-              /* "Authenticator has no subkey" */ 
-      GSS_KRB5_S_KG_CONTEXT_ESTABLISHED 
-              /* "Context is already fully established" */ 
-      GSS_KRB5_S_KG_BAD_SIGN_TYPE 
-              /* "Unknown signature type in token" */ 
-      GSS_KRB5_S_KG_BAD_LENGTH 
-              /* "Invalid field length in token" */ 
-      GSS_KRB5_S_KG_CTX_INCOMPLETE 
-              /* "Attempt to use incomplete security context" */ 
- 
-5.2. Buffer Sizes 
- 
-   All implementations of this specification shall be capable of 
-   accepting buffers of at least 16K bytes as input to GSS_GetMIC(), 
-   GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting 
-   the output_token generated by GSS_Wrap() for a 16K byte input buffer 
-   as input to GSS_Unwrap().  Support for larger buffer sizes is 
-   optional but recommended. 
- 
-6. Backwards Compatibility Considerations 
- 
-   The new token formats defined in this document will only be 
-   recognized by new implementations.  To address this, implementations 
-   can always use the explicit sign or seal algorithm in [RFC-1964] 
-   when the key type corresponds to "older" enctypes.  An alternative 
-   approach might be to retry sending the message with the sign or seal 
-   algorithm explicitly defined as in [RFC-1964].  However this would 
-   require either the use of a mechanism such as [RFC-2478] to securely 
-   negotiate the method or the use out of band mechanism to choose 
-   appropriate mechanism.  For this reason, it is RECOMMENDED that the 
-   new token formats defined in this document SHOULD be used only if 
-   both peers are known to support the new mechanism during context 
-   negotiation, for example, either because of the use of "new" 
-   enctypes or because of the use of Kerberos Version 5 extensions. 
-
- 
-Zhu                         Internet Draft                          11 
-                 Kerberos Version 5 GSS-API      September 2003 
- 
- 
-7. Security Considerations 
-    
-   Under the current mechanism, no negotiation of algorithm types 
-   occurs, so server-side (acceptor) implementations cannot request 
-   that clients not use algorithm types not understood by the server. 
-   However, administration of the server's Kerberos data (e.g., the 
-   service key) has to be done in communication with the KDC, and it is 
-   from the KDC that the client will request credentials.  The KDC 
-   could therefore be given the task of limiting session keys for a 
-   given service to types actually supported by the Kerberos and GSSAPI 
-   software on the server.   
-    
-   This does have a drawback for cases where a service principal name 
-   is used both for GSSAPI-based and non-GSSAPI-based communication 
-   (most notably the "host" service key), if the GSSAPI implementation 
-   does not understand (for example) AES [AES-KRB5] but the Kerberos 
-   implementation does.  It means that AES session keys cannot be 
-   issued for that service principal, which keeps the protection of 
-   non-GSSAPI services weaker than necessary.  KDC administrators 
-   desiring to limit the session key types to support interoperability 
-   with such GSSAPI implementations should carefully weigh the 
-   reduction in protection offered by such mechanisms against the 
-   benefits of interoperability. 
-    
-8. Acknowledgments 
-   
-  The authors wish to acknowledge the contributions from the following 
-  individuals:  
- 
-  Ken Raeburn and Nicolas Williams corrected many of our errors in the 
-  use of generic profiles and were instrumental in the creation of this 
-  draft.  
-   
-  The text for security considerations was contributed by Ken Raeburn. 
-   
-  Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, 
-  namely the encoding of the RRC field.   
-   
-  Sam Hartman and Nicolas Williams recommended the replacing our 
-  earlier key derivation function for directional keys with different 
-  key usage numbers for each direction as well as retaining the 
-  directional bit for maximum compatibility.   
-   
-  Paul Leach provided numerous suggestions and comments.  
-   
-  Scott Field, Richard Ward, Dan Simon, and Kevin Damour also provided 
-  valuable inputs on this draft. 
-   
-  Jeffrey Hutzelman provided comments on channel bindings and suggested 
-  many editorial changes. 
- 
-  This document retains some of the text of RFC-1964 in relevant 
-  sections. 
-
-Zhu                         Internet Draft                          12 
-                 Kerberos Version 5 GSS-API      September 2003 
- 
- 
-   
-9. References 
-    
-9.1. Normative References 
-    
-   [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 
-   3", BCP 9, RFC 2026, October 1996.  
-        
-   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 
-   Requirement Levels", BCP 14, RFC 2119, March 1997. 
-    
-   [RFC-2743] Linn, J., "Generic Security Service Application Program    
-   Interface Version 2, Update 1", RFC 2743, January 2000. 
-    
-   [RFC-2744] Wray, J., "Generic Security Service API Version 2: C-
-   bindings", RFC 2744, January 2000. 
-    
-   [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",    
-   RFC 1964, June 1996. 
-    
-   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 
-   Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003.  Work in 
-   progress.  
-    
-   [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,    
-   Raeburn, K., "The Kerveros Network Authentication Service (V5)",    
-   draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002. 
-   Work in progress. 
-    
-   [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
-   raeburn-krb-rijndael-krb-05.txt, June 2003.  Work in progress.  
-    
-   [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
-   Negotiation Mechanism", RFC 2478, December 1998. 
- 
-9.2. Informative References 
- 
-   [SSPI] Leach, P., "Security Service Provider Interface", Microsoft 
-   Developer Network (MSDN), April 2003. 
-    
-10. Author's Address 
-    
-   Larry Zhu 
-   One Microsoft Way 
-   Redmond, WA 98052 - USA 
-   EMail: LZhu@microsoft.com 
- 
-   Karthik Jaganathan 
-   One Microsoft Way 
-   Redmond, WA 98052 - USA 
-   EMail: karthikj@microsoft.com 
- 
-Zhu                         Internet Draft                          13 
-                 Kerberos Version 5 GSS-API      September 2003 
- 
- 
-   Sam Hartman 
-   Massachusetts Institute of Technology 
-   77 Massachusetts Avenue 
-   Cambridge, MA 02139 - USA 
-   Email: hartmans@MIT.EDU 
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                         Internet Draft                          14 
-                 Kerberos Version 5 GSS-API      September 2003 
- 
- 
-    
-Full Copyright Statement 
-    
-   Copyright (C) The Internet Society (date). All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this 
-   document itself may not be modified in any way, such as by removing 
-   the copyright notice or references to the Internet Society or other 
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                         Internet Draft                          15 
\ No newline at end of file
diff --git a/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-03.txt b/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-03.txt
deleted file mode 100644
index ab7641e2e..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-03.txt
+++ /dev/null
@@ -1,880 +0,0 @@
-
-
-<Network Working Group>                                       Larry Zhu 
-Internet Draft                                       Karthik Jaganathan 
-Updates: 1964                                                 Microsoft 
-Category: Standards Track                                   Sam Hartman 
-draft-ietf-krb-wg-gssapi-cfx-03.txt                                 MIT 
-                                                       October 26, 2003 
-                                                Expires: April 26, 2004 
- 
-          The Kerberos Version 5 GSS-API Mechanism: Version 2 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of [RFC-2026].  
-    
-   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."  
-    
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt.   
-    
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-Abstract 
-    
-   This memo defines protocols, procedures, and conventions to be 
-   employed by peers implementing the Generic Security Service 
-   Application Program Interface (GSS-API as specified in [RFC-2743]) 
-   when using the Kerberos Version 5 mechanism (as specified in 
-   [KRBCLAR]). 
-    
-   [RFC-1964] is updated and incremental changes are proposed in 
-   response to recent developments such as the introduction of Kerberos 
-   crypto framework [KCRYPTO].  These changes support the inclusion of 
-   new cryptosystems based on crypto profiles [KCRYPTO], by defining 
-   new per-message tokens along with their encryption and checksum 
-   algorithms.   
-    
-Conventions used in this document 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
-   document are to be interpreted as described in [RFC-2119]. 
-    
-1. Introduction 
-    
-
-  
-Zhu                         Internet Draft                           1 
-                  Kerberos Version 5 GSS-API      October 2003 
- 
- 
-   [KCRYPTO] defines a generic framework for describing encryption and 
-   checksum types to be used with the Kerberos protocol and associated 
-   protocols. 
-    
-   [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.  
-   It defines the format of context establishment, per-message and 
-   context deletion tokens and uses algorithm identifiers for each 
-   cryptosystem in per message and context deletion tokens.   
-    
-   The approach taken in this document obviates the need for algorithm 
-   identifiers.  This is accomplished by using the same encryption 
-   algorithm, specified by the crypto profile [KCRYPTO] for the session 
-   key or subkey that is created during context negotiation, and its 
-   required checksum algorithm.  Message layouts of the per-message 
-   tokens are therefore revised to remove algorithm indicators and also 
-   to add extra information to support the generic crypto framework 
-   [KCRYPTO].  
-    
-   Tokens transferred between GSS-API peers for security context 
-   establishment are also described in this document.  The data 
-   elements exchanged between a GSS-API endpoint implementation and the 
-   Kerberos KDC are not specific to GSS-API usage and are therefore 
-   defined within [KRBCLAR] rather than within this specification. 
-    
-   The new token formats specified in this memo MUST be used with all 
-   "newer" encryption types [KRBCLAR] and MAY be used with "older" 
-   encryption types, provided that the initiator and acceptor know, 
-   from the context establishment, that they can both process these new 
-   token formats. 
-    
-   "Newer" encryption types are those which have been specified along 
-   with or since the new Kerberos cryptosystem specification [KCRYPTO], 
-   as defined in section 3.1.3 of [KRBCLAR]. 
-    
-   Note that in this document, the term "little endian order" is used 
-   for brevity to refer to the least-significant-octet-first encoding, 
-   while the term "big endian order" is for the most-significant-octet-
-   first encoding. 
-    
-2. Key Derivation for Per-Message Tokens 
-    
-   To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 
-   "entropy-preserving" derived keys, for different purposes or key 
-   usages, from a base key or protocol key.  This document defines four 
-   key usage values below for signing and sealing messages: 
-    
-        Name                         Value 
-      ------------------------------------- 
-       KG-USAGE-ACCEPTOR-SEAL         22 
-       KG-USAGE-ACCEPTOR-SIGN         23 
-       KG-USAGE-INITIATOR-SEAL        24 
-       KG-USAGE-INITIATOR-SIGN        25 
-          
-
-Zhu                         Internet Draft                           2 
-                  Kerberos Version 5 GSS-API      October 2003 
- 
- 
-   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 
-   used as the usage number in the key derivation function for deriving 
-   keys to be used in MIC tokens, and KG-USAGE-ACCEPTOR-SEAL is used 
-   for Wrap tokens; similarly when the sender is the context initiator, 
-   KG-USAGE-INITIATOR-SIGN is used as the usage number in the key 
-   derivation function for MIC tokens, KG-USAGE-INITIATOR-SEAL is used 
-   for Wrap Tokens.  Even if the Wrap token does not provide for 
-   confidentiality the same usage values specified above are used. 
-    
-   During the context initiation and acceptance sequence, the acceptor 
-   MAY assert a subkey.  If the acceptor asserts a subkey, subsequent 
-   messages SHOULD use this subkey as the protocol key and these 
-   messages MUST be flagged as "AcceptorSubkey" as described in section 
-   4.2.2.  
-    
-3. Quality of Protection 
- 
-   The GSS-API specification [RFC-2743] provides for Quality of 
-   Protection (QOP) values that can be used by applications to request 
-   a certain type of encryption or signing.  A zero QOP value is used 
-   to indicate the "default" protection; applications which do not use 
-   the default QOP are not guaranteed to be portable across 
-   implementations or even inter-operate with different deployment 
-   configurations of the same implementation.  Using an algorithm that 
-   is different from the one for which the key is defined may not be 
-   appropriate.  Therefore, when the new method in this document is 
-   used, the QOP value is ignored. 
-    
-   The encryption and checksum algorithms in per-message tokens are now 
-   implicitly defined by the algorithms associated with the session key 
-   or subkey.  Algorithms identifiers as described in [RFC-1964] are 
-   therefore no longer needed and removed from the new token headers. 
- 
-4. Definitions and Token Formats 
-    
-   This section provides terms and definitions, as well as descriptions 
-   for tokens specific to the Kerberos Version 5 GSS-API mechanism. 
-                                    
-4.1. Context Establishment Tokens 
-    
-   All context establishment tokens emitted by the Kerberos V5 GSS-API 
-   mechanism will have the framing shown below: 
-    
-         GSS-API DEFINITIONS ::= 
-    
-         BEGIN 
-    
-         MechType ::= OBJECT IDENTIFIER 
-         -- representing Kerberos V5 mechanism 
-    
-         GSSAPI-Token ::= 
-         -- option indication (delegation, etc.) indicated within 
-         -- mechanism-specific token 
-         [APPLICATION 0] IMPLICIT SEQUENCE { 
-
-
-Zhu                         Internet Draft                           3 
-                  Kerberos Version 5 GSS-API      October 2003 
- 
- 
-                 thisMech MechType, 
-                 innerToken ANY DEFINED BY thisMech 
-                    -- contents mechanism-specific 
-                    -- ASN.1 structure not required 
-                 } 
-    
-         END 
-    
-   Where the notation and encoding of this pseudo ASN.1 header, which 
-   is referred as the generic GSS-API token framing later in this 
-   document, are described in [RFC-2743], and the innerToken field 
-   starts with a two-octet token-identifier (TOK_ID) expressed in big 
-   endian order, followed by a Kerberos message.   
-    
-   Here are the TOK_ID values used in the context establishment tokens: 
-    
-         Token               TOK_ID Value in Hex  
-        ----------------------------------------- 
-         KRB_AP_REQUEST        01 00 
-         KRB_AP_REPLY          02 00 
-         KRB_ERROR             03 00 
-             
-   Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR 
-   are defined in [KRBCLAR].   
-    
-   If an unknown token identifier (TOK_ID) is received in the initial 
-   context estalishment token, the receiver MUST return 
-   GSS_S_CONTINUE_NEEDED major status, and the returned output token 
-   MUST contain a KRB_ERROR message with the error code 
-   KRB_AP_ERR_MSG_TYPE [KRBCLAR]. 
-    
-4.1.1. Authenticator Checksum 
- 
-   The authenticator in the KRB_AP_REQ message MUST include the 
-   optional sequence number and the checksum field.  The checksum field 
-   is used to convey service flags, channel bindings, and optional 
-   delegation information.  The checksum type MUST be 0x8003.  The 
-   length of the checksum MUST be 24 octets when delegation is not 
-   used.  When delegation is used, a ticket-granting ticket will be 
-   transferred in a KRB_CRED message.  This ticket SHOULD have its 
-   forwardable flag set.  The KRB_CRED message MUST be encrypted in the 
-   session key of the ticket used to authenticate the context. 
-    
-   The format of the authenticator checksum field is as follows. 
-       
-      Octet    Name      Description 
-     ----------------------------------------------------------------- 
-      0..3    Lgth    Number of octets in Bnd field;  Currently  
-                      contains hex value 10 00 00 00 (16, represented  
-                      in little-endian order) 
-      4..19   Bnd     Channel binding information, as described in  
-                      section 4.1.1.2. 
-      20..23  Flags   Four-octet context-establishment flags in little- 
-                      endian order as described in section 4.1.1.1.  
-
-
-Zhu                         Internet Draft                           4 
-                  Kerberos Version 5 GSS-API      October 2003 
- 
- 
-      24..25  DlgOpt  The Delegation Option identifier (=1) [optional] 
-      26..27  Dlgth   The length of the Deleg field [optional] 
-      28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional] 
- 
-4.1.1.1. Checksum Flags Field 
-    
-   The checksum "Flags" field is used to convey service options or 
-   extension negotiation information.  The following context 
-   establishment flags are defined in [RFC-2744]. 
-    
-        Flag Name              Value     
-      --------------------------------- 
-       GSS_C_DELEG_FLAG           1        
-       GSS_C_MUTUAL_FLAG          2       
-       GSS_C_REPLAY_FLAG          4       
-       GSS_C_SEQUENCE_FLAG        8        
-       GSS_C_CONF_FLAG           16      
-       GSS_C_INTEG_FLAG          32     
-        
-   Context establishment flags are exposed to the calling application.  
-   If the calling application desires a particular service option then 
-   it requests that option via GSS_Init_sec_context() [RFC-2743].  An 
-   implementation that supports a particular option or extension SHOULD 
-   then set the appropriate flag in the checksum Flags field.   
-    
-   The most significant eight bits of the checksum flags are reserved 
-   for future use.  The receiver MUST ignore unknown checksum flags. 
-    
-4.1.1.2. Channel Binding Information 
- 
-   Channel bindings are user-specified tags to identify a given context 
-   to the peer application.  These tags are intended to be used to 
-   identify the particular communications channel that carries the 
-   context [RFC-2743] [RFC-2744]. 
-    
-   When using C language bindings, channel bindings are communicated to 
-   the GSS-API using the following structure [RFC-2744]: 
- 
-      typedef struct gss_channel_bindings_struct { 
-         OM_uint32       initiator_addrtype; 
-         gss_buffer_desc initiator_address; 
-         OM_uint32       acceptor_addrtype; 
-         gss_buffer_desc acceptor_address; 
-         gss_buffer_desc application_data; 
-      } *gss_channel_bindings_t; 
-    
-   The member fields and constants used for different address types are 
-   defined in [RFC-2744]. 
-    
-   The "Bnd" field contains the MD5 hash of channel bindings, taken 
-   over all non-null components of bindings, in order of declaration.  
-   Integer fields within channel bindings are represented in little-
-   endian order for the purposes of the MD5 calculation.
- 
-    
-Zhu                         Internet Draft                           5 
-                  Kerberos Version 5 GSS-API      October 2003 
- 
- 
-   In computing the contents of the Bnd field, the following detailed 
-   points apply:  
-    
-   (1) Each integer field shall be formatted into four octets, using 
-   little endian octet ordering, for purposes of MD5 hash computation.  
-    
-   (2) All input length fields within gss_buffer_desc elements of a 
-   gss_channel_bindings_struct even those which are zero-valued, shall 
-   be included in the hash calculation; the value elements of 
-   gss_buffer_desc elements shall be dereferenced, and the resulting 
-   data shall be included within the hash computation, only for the 
-   case of gss_buffer_desc elements having non-zero length specifiers.  
-    
-   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 
-   valid channel binding structure, the Bnd field shall be set to 16 
-   zero-valued octets.  
- 
-4.2. Per-Message Tokens 
-    
-   Two classes of tokens are defined in this section:  "MIC" tokens, 
-   emitted by calls to GSS_GetMIC() and consumed by calls to 
-   GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and 
-   consumed by calls to GSS_Unwrap(). 
-    
-   The new per-message tokens introduced here do not include the 
-   generic GSS-API token framing used by the context establishment 
-   tokens.  These new tokens are designed to be used with newer crypto 
-   systems that can, for example, have variable-size checksums.   
-    
-4.2.1. Sequence Number 
- 
-   To distinguish intentionally-repeated messages from maliciously-
-   replayed ones, per-message tokens contain a sequence number field, 
-   which is a 64 bit integer expressed in big endian order.  After 
-   sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence 
-   numbers are incremented by one. 
- 
-4.2.2. Flags Field 
- 
-   The "Flags" field is a one-octet integer used to indicate a set of 
-   attributes for the protected message.  For example, one flag is 
-   allocated as the direction-indicator, thus preventing an adversary 
-   from sending back the same message in the reverse direction and 
-   having it accepted.   
-    
-   The meanings of bits in this field (the least significant bit is bit 
-   0) are as follows: 
-    
-        Bit    Name             Description 
-       --------------------------------------------------------------- 
-        0   SentByAcceptor    When set, this flag indicates the sender  
-                              is the context acceptor.  When not set, 
-                              it indicates the sender is the context  
-                              initiator. 
-
-
-Zhu                         Internet Draft                           6 
-                  Kerberos Version 5 GSS-API      October 2003 
- 
- 
-        1   Sealed            When set in Wrap tokens, this flag  
-                              indicates confidentiality is provided  
-                              for.  It SHALL NOT be set in MIC tokens. 
-        2   AcceptorSubkey    A subkey asserted by the context acceptor 
-                              is used to protect the message. 
-    
-   The rest of available bits are reserved for future use and MUST be 
-   cleared.  The receiver MUST ignore unknown flags. 
-    
-4.2.3. EC Field 
- 
-   The "EC" (Extra Count) field is a two-octet integer field expressed 
-   in big endian order.   
-    
-   In Wrap tokens with confidentiality, the EC field is used to encode 
-   the number of octets in the filler, as described in section 4.2.4. 
-    
-   In Wrap tokens without confidentiality, the EC field is used to 
-   encode the number of octets in the trailing checksum, as described 
-   in section 4.2.4.   
- 
-4.2.4. Encryption and Checksum Operations 
-    
-   The encryption algorithms defined by the crypto profiles provide for 
-   integrity protection [KCRYPTO].  Therefore no separate checksum is 
-   needed.  
-    
-   The result of decryption can be longer than the original plaintext 
-   [KCRYPTO] and the extra trailing octets are called "crypto-system 
-   garbage".  However, given the size of any plaintext data, one can 
-   always find the next (possibly larger) size so that, when padding 
-   the to-be-encrypted text to that size, there will be no crypto-
-   system garbage added [KCRYPTO].  
- 
-   In Wrap tokens that provide for confidentiality, the first 16 octets 
-   of the Wrap token (the "header", as defined in section 4.2.6), are 
-   appended to the plaintext data before encryption.  Filler octets can 
-   be inserted between the plaintext data and the "header", and the 
-   values and size of the filler octets are chosen by implementations, 
-   such that there is no crypto-system garbage present after the 
-   decryption.  The resulting Wrap token is {"header" | 
-   encrypt(plaintext-data | filler | "header")}, where encrypt() is the 
-   encryption operation (which provides for integrity protection) 
-   defined in the crypto profile [KCRYPTO], and the RRC field in the 
-   to-be-encrypted header contains the hex value 00 00.   
-           
-   In Wrap tokens that do not provide for confidentiality, the checksum 
-   is calculated first over the to-be-signed plaintext data, and then 
-   the first 16 octets of the Wrap token (the "header", as defined in 
-   section 4.2.6).  Both the EC field and the RRC field in the token 
-   header are filled with zeroes for the purpose of calculating the 
-   checksum.  The resulting Wrap token is {"header" | plaintext-data | 
-   get_mic(plaintext-data | "header")},  where get_mic() is the 
-
-Zhu                         Internet Draft                           7 
-                  Kerberos Version 5 GSS-API      October 2003 
- 
- 
-   checksum operation for the required checksum mechanism of the chosen 
-   encryption mechanism defined in the crypto profile [KCRYPTO].  
-    
-   The parameters for the key and the cipher-state in the encrypt() and 
-   get_mic() operations have been omitted for brevity.   
-        
-   For MIC tokens, the checksum is first calculated over the to-be-
-   signed plaintext data, and then the first 16 octets of the MIC 
-   token, where the checksum mechanism is the required checksum 
-   mechanism of the chosen encryption mechanism defined in the crypto 
-   profile [KCRYPTO]. 
-   
-   The resulting Wrap and MIC tokens bind the data to the token header, 
-   including the sequence number and the direction indicator.  
-   
-4.2.5. RRC Field 
- 
-   The "RRC" (Right Rotation Count) field in Wrap tokens is added to 
-   allow the data to be encrypted in-place by existing [SSPI] 
-   applications that do not provide an additional buffer for the 
-   trailer (the cipher text after the in-place-encrypted data) in 
-   addition to the buffer for the header (the cipher text before the 
-   in-place-encrypted data).  The resulting Wrap token in the previous 
-   section, excluding the first 16 octets of the token header, is 
-   rotated to the right by "RRC" octets.  The net result is that "RRC" 
-   octets of trailing octets are moved toward the header.  Consider the 
-   following as an example of this rotation operation:  Assume that the 
-   RRC value is 3 and the token before the rotation is {"header" | aa | 
-   bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be 
-   {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb 
-   | cc |...| hh} is used to indicate the octet sequence. 
-  
-   The RRC field is expressed as a two-octet integer in big endian 
-   order. 
-    
-   The rotation count value is chosen by the sender based on 
-   implementation details, and the receiver MUST be able to interpret 
-   all possible rotation count values. 
- 
-4.2.6. Message Layouts 
-    
-   Per-message tokens start with a two-octet token identifier (TOK_ID) 
-   field, expressed in big endian order.  These tokens are defined 
-   separately in subsequent sub-sections. 
-    
-4.2.6.1. MIC Tokens 
-    
-   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 as received.  The token has the following format: 
-    
-      Octet no     Name       Description 
-      ----------------------------------------------------------------- 
-       0..1     TOK_ID     Identification field.  Tokens emitted by  
-
-
-Zhu                         Internet Draft                           8 
-                  Kerberos Version 5 GSS-API      October 2003 
- 
- 
-                           GSS_GetMIC() contain the hex value 04 04  
-                           expressed in big endian order in this field. 
-       2        Flags      Attributes field, as described in section  
-                           4.2.2. 
-       3..7     Filler     Contains five octets of hex value FF. 
-       8..15    SND_SEQ    Sequence number field in clear text,  
-                           expressed in big endian order.  
-       16..last SGN_CKSUM  Checksum of octet 0..15 and the "to-be- 
-                           signed" data, as described in section 4.2.4. 
-    
-   The Filler field is included in the checksum calculation for 
-   simplicity.   
-    
-4.2.6.2. Wrap Tokens 
-    
-   Use of the GSS_Wrap() call yields a token, which consists of a 
-   descriptive header, followed by a body portion that contains either 
-   the input user data in plaintext concatenated with the checksum, or 
-   the input user data encrypted.  The GSS_Wrap() token has the 
-   following format: 
-    
-      Octet no     Name       Description 
-      --------------------------------------------------------------- 
-       0..1     TOK_ID     Identification field.  Tokens emitted by  
-                           GSS_Wrap() contain the the hex value 05 04                 
-                           expressed in big endian order in this field. 
-       2        Flags      Attributes field, as described in section  
-                           4.2.2. 
-       3        Filler     Contains the hex value FF. 
-       4..5     EC         Contains the "extra count" field, in big  
-                           endian order as described in section 4.2.3. 
-       6..7     RRC        Contains the "right rotation count" in big  
-                           endian order, as described in section 4.2.5. 
-       8..15    SND_SEQ    Sequence number field in clear text, 
-                           expressed in big endian order. 
-       16..last Data       Encrypted data for Wrap tokens with  
-                           confidentiality, or plaintext data followed  
-                           by the checksum for Wrap tokens without  
-                           confidentiality, as described in section  
-                           4.2.4.         
-             
-4.3. Context Deletion Tokens 
- 
-   Context deletion tokens are empty in this mechanism.  Both peers to 
-   a security context invoke GSS_Delete_sec_context() [RFC-2743] 
-   independently, passing a null output_context_token buffer to 
-   indicate that no context_token is required.  Implementations of 
-   GSS_Delete_sec_context() should delete relevant locally-stored 
-   context information. 
-        
-4.4. Token Identifier Assignment Considerations 
-    
-   Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF 
-   inclusive are reserved and SHALL NOT be assigned.  Thus by examining 
-
-
-Zhu                         Internet Draft                           9 
-                  Kerberos Version 5 GSS-API      October 2003 
- 
- 
-   the first two octets of a token, one can tell unambiguously if it is 
-   wrapped with the generic GSS-API token framing.   
-    
-5. Parameter Definitions 
-    
-   This section defines parameter values used by the Kerberos V5 GSS-
-   API mechanism.  It defines interface elements in support of 
-   portability, and assumes use of C language bindings per [RFC-2744]. 
-    
-5.1. Minor Status Codes 
- 
-   This section recommends common symbolic names for minor_status 
-   values to be returned by the Kerberos V5 GSS-API mechanism.  Use of 
-   these definitions will enable independent implementers to enhance 
-   application portability across different implementations of the 
-   mechanism defined in this specification.  (In all cases, 
-   implementations of GSS_Display_status() will enable callers to 
-   convert minor_status indicators to text representations.)  Each 
-   implementation should make available, through include files or other 
-   means, a facility to translate these symbolic names into the 
-   concrete values which a particular GSS-API implementation uses to 
-   represent the minor_status values specified in this section.  
-    
-   It is recognized that this list may grow over time, and that the 
-   need for additional minor_status codes specific to particular 
-   implementations may arise.  It is recommended, however, that 
-   implementations should return a minor_status value as defined on a 
-   mechanism-wide basis within this section when that code is 
-   accurately representative of reportable status rather than using a 
-   separate, implementation-defined code.  
-    
-5.1.1. Non-Kerberos-specific codes 
- 
-      GSS_KRB5_S_G_BAD_SERVICE_NAME  
-              /* "No @ in SERVICE-NAME name string" */ 
-      GSS_KRB5_S_G_BAD_STRING_UID 
-              /* "STRING-UID-NAME contains nondigits" */ 
-      GSS_KRB5_S_G_NOUSER 
-              /* "UID does not resolve to username" */ 
-      GSS_KRB5_S_G_VALIDATE_FAILED 
-              /* "Validation error" */ 
-      GSS_KRB5_S_G_BUFFER_ALLOC 
-              /* "Couldn't allocate gss_buffer_t data" */ 
-      GSS_KRB5_S_G_BAD_MSG_CTX 
-              /* "Message context invalid" */ 
-      GSS_KRB5_S_G_WRONG_SIZE 
-              /* "Buffer is the wrong size" */ 
-      GSS_KRB5_S_G_BAD_USAGE 
-              /* "Credential usage type is unknown" */ 
-      GSS_KRB5_S_G_UNKNOWN_QOP 
-              /* "Unknown quality of protection specified" */ 
-    
-5.1.2. Kerberos-specific-codes 
-    
-Zhu                         Internet Draft                          10 
-                  Kerberos Version 5 GSS-API      October 2003 
- 
- 
-      GSS_KRB5_S_KG_CCACHE_NOMATCH  
-              /* "Client principal in credentials does not match   
-                 specified name" */ 
-      GSS_KRB5_S_KG_KEYTAB_NOMATCH 
-              /* "No key available for specified service principal" */ 
-      GSS_KRB5_S_KG_TGT_MISSING 
-              /* "No Kerberos ticket-granting ticket available" */ 
-      GSS_KRB5_S_KG_NO_SUBKEY 
-              /* "Authenticator has no subkey" */ 
-      GSS_KRB5_S_KG_CONTEXT_ESTABLISHED 
-              /* "Context is already fully established" */ 
-      GSS_KRB5_S_KG_BAD_SIGN_TYPE 
-              /* "Unknown signature type in token" */ 
-      GSS_KRB5_S_KG_BAD_LENGTH 
-              /* "Invalid field length in token" */ 
-      GSS_KRB5_S_KG_CTX_INCOMPLETE 
-              /* "Attempt to use incomplete security context" */ 
- 
-5.2. Buffer Sizes 
- 
-   All implementations of this specification shall be capable of 
-   accepting buffers of at least 16K octets as input to GSS_GetMIC(), 
-   GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting 
-   the output_token generated by GSS_Wrap() for a 16K octet input 
-   buffer as input to GSS_Unwrap().  Support for larger buffer sizes is 
-   optional but recommended. 
- 
-6. Backwards Compatibility Considerations 
- 
-   The new token formats defined in this document will only be 
-   recognized by new implementations.  To address this, implementations 
-   can always use the explicit sign or seal algorithm in [RFC-1964] 
-   when the key type corresponds to "older" enctypes.  An alternative 
-   approach might be to retry sending the message with the sign or seal 
-   algorithm explicitly defined as in [RFC-1964].  However this would 
-   require either the use of a mechanism such as [RFC-2478] to securely 
-   negotiate the method or the use out of band mechanism to choose 
-   appropriate mechanism.  For this reason, it is RECOMMENDED that the 
-   new token formats defined in this document SHOULD be used only if 
-   both peers are known to support the new mechanism during context 
-   negotiation because of, for example, the use of "new" enctypes. 
- 
-   GSS_Unwrap() or GSS_Verify_MIC() can process a message token as 
-   follows: it can look at the first octet of the token header, if it 
-   is 0x60 then the token must carry the generic GSS-API pseudo ASN.1 
-   framing, otherwise the first two octets of the token contain the 
-   TOK_ID that uniquely identify the token message format. 
-    
-7. Security Considerations 
-    
-   Under the current mechanism, no negotiation of algorithm types 
-   occurs, so server-side (acceptor) implementations cannot request 
-   that clients not use algorithm types not understood by the server. 
-
-Zhu                         Internet Draft                          11 
-                  Kerberos Version 5 GSS-API      October 2003 
- 
- 
-   However, administration of the server's Kerberos data (e.g., the 
-   service key) has to be done in communication with the KDC, and it is 
-   from the KDC that the client will request credentials.  The KDC 
-   could therefore be given the task of limiting session keys for a 
-   given service to types actually supported by the Kerberos and GSSAPI 
-   software on the server.   
-    
-   This does have a drawback for cases where a service principal name 
-   is used both for GSSAPI-based and non-GSSAPI-based communication 
-   (most notably the "host" service key), if the GSSAPI implementation 
-   does not understand (for example) AES [AES-KRB5] but the Kerberos 
-   implementation does.  It means that AES session keys cannot be 
-   issued for that service principal, which keeps the protection of 
-   non-GSSAPI services weaker than necessary.  KDC administrators 
-   desiring to limit the session key types to support interoperability 
-   with such GSSAPI implementations should carefully weigh the 
-   reduction in protection offered by such mechanisms against the 
-   benefits of interoperability. 
-    
-8. Acknowledgments 
- 
-  Ken Raeburn and Nicolas Williams corrected many of our errors in the 
-  use of generic profiles and were instrumental in the creation of this 
-  memo.  
-   
-  The text for security considerations was contributed by Ken Raeburn. 
-   
-  Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, 
-  namely the encoding of the RRC field.   
-   
-  Sam Hartman and Nicolas Williams recommended the replacing our 
-  earlier key derivation function for directional keys with different 
-  key usage numbers for each direction as well as retaining the 
-  directional bit for maximum compatibility.   
-   
-  Paul Leach provided numerous suggestions and comments.  
-   
-  Scott Field, Richard Ward, Dan Simon, and Kevin Damour also provided 
-  valuable inputs on this memo. 
-   
-  Jeffrey Hutzelman provided comments on channel bindings and suggested 
-  many editorial changes. 
- 
-  Luke Howard provided implementations of this memo for the Heimdal 
-  code base, and helped inter-operability testing with the Microsoft 
-  code base, together with Love.  These experiments formed the basis of 
-  this memo. 
-   
-  Martin Rex provided suggestions of TOK_ID assignment recommendations 
-  thus the token tagging in this memo is unambiguous if the token is 
-  wrapped with the pseudo ASN.1 header.  
-   
-
-
-Zhu                         Internet Draft                          12 
-                  Kerberos Version 5 GSS-API      October 2003 
- 
- 
-  This document retains some of the text of RFC-1964 in relevant 
-  sections. 
-   
-9. References 
-    
-9.1. Normative References 
-    
-   [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 
-   3", BCP 9, RFC 2026, October 1996.  
-        
-   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 
-   Requirement Levels", BCP 14, RFC 2119, March 1997. 
-    
-   [RFC-2743] Linn, J., "Generic Security Service Application Program    
-   Interface Version 2, Update 1", RFC 2743, January 2000. 
-    
-   [RFC-2744] Wray, J., "Generic Security Service API Version 2: C-
-   bindings", RFC 2744, January 2000. 
-    
-   [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",    
-   RFC 1964, June 1996. 
-    
-   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 
-   Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003.  Work in 
-   progress.  
-    
-   [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,    
-   Raeburn, K., "The Kerberos Network Authentication Service (V5)",    
-   draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002. 
-   Work in progress. 
-    
-   [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
-   raeburn-krb-rijndael-krb-05.txt, June 2003.  Work in progress.  
-    
-   [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
-   Negotiation Mechanism", RFC 2478, December 1998. 
- 
-9.2. Informative References 
- 
-   [SSPI] Leach, P., "Security Service Provider Interface", Microsoft 
-   Developer Network (MSDN), April 2003. 
-    
-10. Author's Address 
-    
-   Larry Zhu 
-   One Microsoft Way 
-   Redmond, WA 98052 - USA 
-   EMail: LZhu@microsoft.com 
- 
-   Karthik Jaganathan 
-   One Microsoft Way 
-   Redmond, WA 98052 - USA
-
- 
-Zhu                         Internet Draft                          13 
-                  Kerberos Version 5 GSS-API      October 2003 
- 
- 
-   EMail: karthikj@microsoft.com 
- 
-   Sam Hartman 
-   Massachusetts Institute of Technology 
-   77 Massachusetts Avenue 
-   Cambridge, MA 02139 - USA 
-   Email: hartmans@MIT.EDU 
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                         Internet Draft                          14 
-                  Kerberos Version 5 GSS-API      October 2003 
- 
- 
-    
-Full Copyright Statement 
-    
-   Copyright (C) The Internet Society (date). All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this 
-   document itself may not be modified in any way, such as by removing 
-   the copyright notice or references to the Internet Society or other 
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                         Internet Draft                          15 
\ No newline at end of file
diff --git a/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-04.txt b/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-04.txt
deleted file mode 100644
index 7d4071865..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-04.txt
+++ /dev/null
@@ -1,884 +0,0 @@
-
-
-<Network Working Group>                                       Larry Zhu 
-Internet Draft                                       Karthik Jaganathan 
-Updates: 1964                                                 Microsoft 
-Category: Standards Track                                   Sam Hartman 
-draft-ietf-krb-wg-gssapi-cfx-04.txt                                 MIT 
-                                                      November 21, 2003 
-                                                  Expires: May 21, 2004 
- 
-          The Kerberos Version 5 GSS-API Mechanism: Version 2 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of [RFC-2026].  
-    
-   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."  
-    
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt.   
-    
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-Abstract 
-    
-   This memo defines protocols, procedures, and conventions to be 
-   employed by peers implementing the Generic Security Service 
-   Application Program Interface (GSS-API as specified in [RFC-2743]) 
-   when using the Kerberos Version 5 mechanism (as specified in 
-   [KRBCLAR]). 
-    
-   [RFC-1964] is updated and incremental changes are proposed in 
-   response to recent developments such as the introduction of Kerberos 
-   crypto framework [KCRYPTO].  These changes support the inclusion of 
-   new cryptosystems based on crypto profiles [KCRYPTO], by defining 
-   new per-message tokens along with their encryption and checksum 
-   algorithms.   
-    
-Conventions used in this document 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
-   document are to be interpreted as described in [RFC-2119]. 
-    
-1. Introduction 
-    
-
-  
-Zhu                         Internet Draft                           1 
-                 Kerberos Version 5 GSS-API      November 2003 
- 
- 
-   [KCRYPTO] defines a generic framework for describing encryption and 
-   checksum types to be used with the Kerberos protocol and associated 
-   protocols. 
-    
-   [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.  
-   It defines the format of context establishment, per-message and 
-   context deletion tokens and uses algorithm identifiers for each 
-   cryptosystem in per message and context deletion tokens.   
-    
-   The approach taken in this document obviates the need for algorithm 
-   identifiers.  This is accomplished by using the same encryption 
-   algorithm, specified by the crypto profile [KCRYPTO] for the session 
-   key or subkey that is created during context negotiation, and its 
-   required checksum algorithm.  Message layouts of the per-message 
-   tokens are therefore revised to remove algorithm indicators and also 
-   to add extra information to support the generic crypto framework 
-   [KCRYPTO].  
-    
-   Tokens transferred between GSS-API peers for security context 
-   establishment are also described in this document.  The data 
-   elements exchanged between a GSS-API endpoint implementation and the 
-   Kerberos KDC are not specific to GSS-API usage and are therefore 
-   defined within [KRBCLAR] rather than within this specification. 
-    
-   The new token formats specified in this memo MUST be used with all 
-   "newer" encryption types [KRBCLAR] and MAY be used with "older" 
-   encryption types, provided that the initiator and acceptor know, 
-   from the context establishment, that they can both process these new 
-   token formats. 
-    
-   "Newer" encryption types are those which have been specified along 
-   with or since the new Kerberos cryptosystem specification [KCRYPTO], 
-   as defined in section 3.1.3 of [KRBCLAR].  The list of not-newer 
-   encryption types is as follows [KCRYPTO]: 
-    
-             Encryption Type             Assigned Number     
-           ---------------------------------------------- 
-            des-cbc-crc                        1              
-            des-cbc-md4                        2              
-            des-cbc-md5                        3              
-            des3-cbc-md5                       5 
-            des3-cbc-sha1                      7 
-            dsaWithSHA1-CmsOID                 9            
-            md5WithRSAEncryption-CmsOID       10            
-            sha1WithRSAEncryption-CmsOID      11           
-            rc2CBC-EnvOID                     12            
-            rsaEncryption-EnvOID              13    
-            rsaES-OAEP-ENV-OID                14    
-            des-ede3-cbc-Env-OID              15            
-            des3-cbc-sha1-kd                  16                       
-            rc4-hmac                          23          
-    
-   Note that in this document, the term "little endian order" is used 
-   for brevity to refer to the least-significant-octet-first encoding,
- 
-
-Zhu                         Internet Draft                           2 
-                 Kerberos Version 5 GSS-API      November 2003 
- 
- 
-   while the term "big endian order" is for the most-significant-octet-
-   first encoding. 
-    
-2. Key Derivation for Per-Message Tokens 
-    
-   To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 
-   "entropy-preserving" derived keys, for different purposes or key 
-   usages, from a base key or protocol key.   
-    
-   This document defines four key usage values below that are used to 
-   derive a specific key for signing and sealing messages, from the 
-   session key or subkey [KRBCLAR] created during the context 
-   establishment. 
-    
-        Name                         Value 
-      ------------------------------------- 
-       KG-USAGE-ACCEPTOR-SEAL         22 
-       KG-USAGE-ACCEPTOR-SIGN         23 
-       KG-USAGE-INITIATOR-SEAL        24 
-       KG-USAGE-INITIATOR-SIGN        25 
-          
-   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 
-   used as the usage number in the key derivation function for deriving 
-   keys to be used in MIC tokens, and KG-USAGE-ACCEPTOR-SEAL is used 
-   for Wrap tokens; similarly when the sender is the context initiator, 
-   KG-USAGE-INITIATOR-SIGN is used as the usage number in the key 
-   derivation function for MIC tokens, KG-USAGE-INITIATOR-SEAL is used 
-   for Wrap Tokens.  Even if the Wrap token does not provide for 
-   confidentiality the same usage values specified above are used. 
-    
-   During the context initiation and acceptance sequence, the acceptor 
-   MAY assert a subkey, and if so, subsequent messages MUST use this 
-   subkey as the protocol key and these messages MUST be flagged as 
-   "AcceptorSubkey" as described in section 4.2.2. 
- 
-3. Quality of Protection 
- 
-   The GSS-API specification [RFC-2743] provides for Quality of 
-   Protection (QOP) values that can be used by applications to request 
-   a certain type of encryption or signing.  A zero QOP value is used 
-   to indicate the "default" protection; applications which do not use 
-   the default QOP are not guaranteed to be portable across 
-   implementations or even inter-operate with different deployment 
-   configurations of the same implementation.  Using an algorithm that 
-   is different from the one for which the key is defined may not be 
-   appropriate.  Therefore, when the new method in this document is 
-   used, the QOP value is ignored. 
-    
-   The encryption and checksum algorithms in per-message tokens are now 
-   implicitly defined by the algorithms associated with the session key 
-   or subkey.  Algorithms identifiers as described in [RFC-1964] are 
-   therefore no longer needed and removed from the new token headers. 
- 
-4. Definitions and Token Formats 
-
-
-Zhu                         Internet Draft                           3 
-                 Kerberos Version 5 GSS-API      November 2003 
- 
- 
-    
-   This section provides terms and definitions, as well as descriptions 
-   for tokens specific to the Kerberos Version 5 GSS-API mechanism. 
-                                    
-4.1. Context Establishment Tokens 
-    
-   All context establishment tokens emitted by the Kerberos V5 GSS-API 
-   mechanism will have the framing shown below: 
-    
-         GSS-API DEFINITIONS ::= 
-    
-         BEGIN 
-    
-         MechType ::= OBJECT IDENTIFIER 
-         -- representing Kerberos V5 mechanism 
-    
-         GSSAPI-Token ::= 
-         -- option indication (delegation, etc.) indicated within 
-         -- mechanism-specific token 
-         [APPLICATION 0] IMPLICIT SEQUENCE { 
-                 thisMech MechType, 
-                 innerToken ANY DEFINED BY thisMech 
-                    -- contents mechanism-specific 
-                    -- ASN.1 structure not required 
-                 } 
-    
-         END 
-    
-   Where the notation and encoding of this pseudo ASN.1 header, which 
-   is referred as the generic GSS-API token framing later in this 
-   document, are described in [RFC-2743], and the innerToken field 
-   starts with a two-octet token-identifier (TOK_ID) expressed in big 
-   endian order, followed by a Kerberos message.   
-    
-   Here are the TOK_ID values used in the context establishment tokens: 
-    
-         Token               TOK_ID Value in Hex  
-        ----------------------------------------- 
-         KRB_AP_REQUEST        01 00 
-         KRB_AP_REPLY          02 00 
-         KRB_ERROR             03 00 
-             
-   Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR 
-   are defined in [KRBCLAR].   
-    
-   If an unknown token identifier (TOK_ID) is received in the initial 
-   context estalishment token, the receiver MUST return 
-   GSS_S_CONTINUE_NEEDED major status, and the returned output token 
-   MUST contain a KRB_ERROR message with the error code 
-   KRB_AP_ERR_MSG_TYPE [KRBCLAR]. 
-    
-4.1.1. Authenticator Checksum 
- 
-
-Zhu                         Internet Draft                           4 
-                 Kerberos Version 5 GSS-API      November 2003 
- 
- 
-   The authenticator in the KRB_AP_REQ message MUST include the 
-   optional sequence number and the checksum field.  The checksum field 
-   is used to convey service flags, channel bindings, and optional 
-   delegation information.  The checksum type MUST be 0x8003.  The 
-   length of the checksum MUST be 24 octets when delegation is not 
-   used.  When delegation is used, a ticket-granting ticket will be 
-   transferred in a KRB_CRED message.  This ticket SHOULD have its 
-   forwardable flag set.  The KRB_CRED message MUST be encrypted in the 
-   session key of the ticket used to authenticate the context. 
-    
-   The format of the authenticator checksum field is as follows. 
-       
-      Octet    Name      Description 
-     ----------------------------------------------------------------- 
-      0..3    Lgth    Number of octets in Bnd field;  Currently  
-                      contains hex value 10 00 00 00 (16, represented  
-                      in little-endian order) 
-      4..19   Bnd     Channel binding information, as described in  
-                      section 4.1.1.2. 
-      20..23  Flags   Four-octet context-establishment flags in little- 
-                      endian order as described in section 4.1.1.1.  
-      24..25  DlgOpt  The Delegation Option identifier (=1) [optional] 
-      26..27  Dlgth   The length of the Deleg field [optional] 
-      28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional] 
- 
-4.1.1.1. Checksum Flags Field 
-    
-   The checksum "Flags" field is used to convey service options or 
-   extension negotiation information.  The following context 
-   establishment flags are defined in [RFC-2744]. 
-    
-        Flag Name              Value     
-      --------------------------------- 
-       GSS_C_DELEG_FLAG           1        
-       GSS_C_MUTUAL_FLAG          2       
-       GSS_C_REPLAY_FLAG          4       
-       GSS_C_SEQUENCE_FLAG        8        
-       GSS_C_CONF_FLAG           16      
-       GSS_C_INTEG_FLAG          32     
-        
-   Context establishment flags are exposed to the calling application.  
-   If the calling application desires a particular service option then 
-   it requests that option via GSS_Init_sec_context() [RFC-2743].  An 
-   implementation that supports a particular option or extension SHOULD 
-   then set the appropriate flag in the checksum Flags field.   
-    
-   The most significant eight bits of the checksum flags are reserved 
-   for future use.  The receiver MUST ignore unknown checksum flags. 
-    
-4.1.1.2. Channel Binding Information 
- 
-   Channel bindings are user-specified tags to identify a given context 
-   to the peer application.  These tags are intended to be used to 
-
-
-Zhu                         Internet Draft                           5 
-                 Kerberos Version 5 GSS-API      November 2003 
- 
- 
-   identify the particular communications channel that carries the 
-   context [RFC-2743] [RFC-2744]. 
-    
-   When using C language bindings, channel bindings are communicated to 
-   the GSS-API using the following structure [RFC-2744]: 
- 
-      typedef struct gss_channel_bindings_struct { 
-         OM_uint32       initiator_addrtype; 
-         gss_buffer_desc initiator_address; 
-         OM_uint32       acceptor_addrtype; 
-         gss_buffer_desc acceptor_address; 
-         gss_buffer_desc application_data; 
-      } *gss_channel_bindings_t; 
-    
-   The member fields and constants used for different address types are 
-   defined in [RFC-2744]. 
-    
-   The "Bnd" field contains the MD5 hash of channel bindings, taken 
-   over all non-null components of bindings, in order of declaration.  
-   Integer fields within channel bindings are represented in little-
-   endian order for the purposes of the MD5 calculation. 
-    
-   In computing the contents of the Bnd field, the following detailed 
-   points apply:  
-    
-   (1) Each integer field shall be formatted into four octets, using 
-   little endian octet ordering, for purposes of MD5 hash computation.  
-    
-   (2) All input length fields within gss_buffer_desc elements of a 
-   gss_channel_bindings_struct even those which are zero-valued, shall 
-   be included in the hash calculation; the value elements of 
-   gss_buffer_desc elements shall be dereferenced, and the resulting 
-   data shall be included within the hash computation, only for the 
-   case of gss_buffer_desc elements having non-zero length specifiers.  
-    
-   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 
-   valid channel binding structure, the Bnd field shall be set to 16 
-   zero-valued octets.  
- 
-4.2. Per-Message Tokens 
-    
-   Two classes of tokens are defined in this section:  "MIC" tokens, 
-   emitted by calls to GSS_GetMIC() and consumed by calls to 
-   GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and 
-   consumed by calls to GSS_Unwrap(). 
-    
-   The new per-message tokens introduced here do not include the 
-   generic GSS-API token framing used by the context establishment 
-   tokens.  These new tokens are designed to be used with newer crypto 
-   systems that can, for example, have variable-size checksums.   
-    
-4.2.1. Sequence Number 
- 
-
-Zhu                         Internet Draft                           6 
-                 Kerberos Version 5 GSS-API      November 2003 
- 
- 
-   To distinguish intentionally-repeated messages from maliciously-
-   replayed ones, per-message tokens contain a sequence number field, 
-   which is a 64 bit integer expressed in big endian order.  After 
-   sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence 
-   numbers are incremented by one. 
- 
-4.2.2. Flags Field 
- 
-   The "Flags" field is a one-octet integer used to indicate a set of 
-   attributes for the protected message.  For example, one flag is 
-   allocated as the direction-indicator, thus preventing an adversary 
-   from sending back the same message in the reverse direction and 
-   having it accepted.   
-    
-   The meanings of bits in this field (the least significant bit is bit 
-   0) are as follows: 
-    
-        Bit    Name             Description 
-       --------------------------------------------------------------- 
-        0   SentByAcceptor    When set, this flag indicates the sender  
-                              is the context acceptor.  When not set, 
-                              it indicates the sender is the context  
-                              initiator. 
-        1   Sealed            When set in Wrap tokens, this flag  
-                              indicates confidentiality is provided  
-                              for.  It SHALL NOT be set in MIC tokens. 
-        2   AcceptorSubkey    A subkey asserted by the context acceptor 
-                              is used to protect the message. 
-    
-   The rest of available bits are reserved for future use and MUST be 
-   cleared.  The receiver MUST ignore unknown flags. 
-    
-4.2.3. EC Field 
- 
-   The "EC" (Extra Count) field is a two-octet integer field expressed 
-   in big endian order.   
-    
-   In Wrap tokens with confidentiality, the EC field is used to encode 
-   the number of octets in the filler, as described in section 4.2.4. 
-    
-   In Wrap tokens without confidentiality, the EC field is used to 
-   encode the number of octets in the trailing checksum, as described 
-   in section 4.2.4.   
- 
-4.2.4. Encryption and Checksum Operations 
-    
-   The encryption algorithms defined by the crypto profiles provide for 
-   integrity protection [KCRYPTO].  Therefore no separate checksum is 
-   needed.  
-    
-   The result of decryption can be longer than the original plaintext 
-   [KCRYPTO] and the extra trailing octets are called "crypto-system 
-   garbage".  However, given the size of any plaintext data, one can 
-   always find the next (possibly larger) size so that, when padding 
-
-
-Zhu                         Internet Draft                           7 
-                 Kerberos Version 5 GSS-API      November 2003 
- 
- 
-   the to-be-encrypted text to that size, there will be no crypto-
-   system garbage added [KCRYPTO].  
- 
-   In Wrap tokens that provide for confidentiality, the first 16 octets 
-   of the Wrap token (the "header", as defined in section 4.2.6), are 
-   appended to the plaintext data before encryption.  Filler octets can 
-   be inserted between the plaintext data and the "header", and the 
-   values and size of the filler octets are chosen by implementations, 
-   such that there is no crypto-system garbage present after the 
-   decryption.  The resulting Wrap token is {"header" | 
-   encrypt(plaintext-data | filler | "header")}, where encrypt() is the 
-   encryption operation (which provides for integrity protection) 
-   defined in the crypto profile [KCRYPTO], and the RRC field in the 
-   to-be-encrypted header contains the hex value 00 00.   
-           
-   In Wrap tokens that do not provide for confidentiality, the checksum 
-   is calculated first over the to-be-signed plaintext data, and then 
-   the first 16 octets of the Wrap token (the "header", as defined in 
-   section 4.2.6).  Both the EC field and the RRC field in the token 
-   header are filled with zeroes for the purpose of calculating the 
-   checksum.  The resulting Wrap token is {"header" | plaintext-data | 
-   get_mic(plaintext-data | "header")},  where get_mic() is the 
-   checksum operation for the required checksum mechanism of the chosen 
-   encryption mechanism defined in the crypto profile [KCRYPTO].  
-    
-   The parameters for the key and the cipher-state in the encrypt() and 
-   get_mic() operations have been omitted for brevity.   
-        
-   For MIC tokens, the checksum is first calculated over the to-be-
-   signed plaintext data, and then the first 16 octets of the MIC 
-   token, where the checksum mechanism is the required checksum 
-   mechanism of the chosen encryption mechanism defined in the crypto 
-   profile [KCRYPTO]. 
-   
-   The resulting Wrap and MIC tokens bind the data to the token header, 
-   including the sequence number and the direction indicator.  
-   
-4.2.5. RRC Field 
- 
-   The "RRC" (Right Rotation Count) field in Wrap tokens is added to 
-   allow the data to be encrypted in-place by existing [SSPI] 
-   applications that do not provide an additional buffer for the 
-   trailer (the cipher text after the in-place-encrypted data) in 
-   addition to the buffer for the header (the cipher text before the 
-   in-place-encrypted data).  The resulting Wrap token in the previous 
-   section, excluding the first 16 octets of the token header, is 
-   rotated to the right by "RRC" octets.  The net result is that "RRC" 
-   octets of trailing octets are moved toward the header.  Consider the 
-   following as an example of this rotation operation:  Assume that the 
-   RRC value is 3 and the token before the rotation is {"header" | aa | 
-   bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be 
-   {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb 
-   | cc |...| hh} is used to indicate the octet sequence. 
-  
-
-Zhu                         Internet Draft                           8 
-                 Kerberos Version 5 GSS-API      November 2003 
- 
- 
-   The RRC field is expressed as a two-octet integer in big endian 
-   order. 
-    
-   The rotation count value is chosen by the sender based on 
-   implementation details, and the receiver MUST be able to interpret 
-   all possible rotation count values. 
- 
-4.2.6. Message Layouts 
-    
-   Per-message tokens start with a two-octet token identifier (TOK_ID) 
-   field, expressed in big endian order.  These tokens are defined 
-   separately in subsequent sub-sections. 
-    
-4.2.6.1. MIC Tokens 
-    
-   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 as received.  The token has the following format: 
-    
-      Octet no     Name       Description 
-      ----------------------------------------------------------------- 
-       0..1     TOK_ID     Identification field.  Tokens emitted by  
-                           GSS_GetMIC() contain the hex value 04 04  
-                           expressed in big endian order in this field. 
-       2        Flags      Attributes field, as described in section  
-                           4.2.2. 
-       3..7     Filler     Contains five octets of hex value FF. 
-       8..15    SND_SEQ    Sequence number field in clear text,  
-                           expressed in big endian order.  
-       16..last SGN_CKSUM  Checksum of octet 0..15 and the "to-be- 
-                           signed" data, as described in section 4.2.4. 
-    
-   The Filler field is included in the checksum calculation for 
-   simplicity.   
-    
-4.2.6.2. Wrap Tokens 
-    
-   Use of the GSS_Wrap() call yields a token, which consists of a 
-   descriptive header, followed by a body portion that contains either 
-   the input user data in plaintext concatenated with the checksum, or 
-   the input user data encrypted.  The GSS_Wrap() token has the 
-   following format: 
-    
-      Octet no     Name       Description 
-      --------------------------------------------------------------- 
-       0..1     TOK_ID     Identification field.  Tokens emitted by  
-                           GSS_Wrap() contain the the hex value 05 04                 
-                           expressed in big endian order in this field. 
-       2        Flags      Attributes field, as described in section  
-                           4.2.2. 
-       3        Filler     Contains the hex value FF. 
-       4..5     EC         Contains the "extra count" field, in big  
-                           endian order as described in section 4.2.3. 
-       6..7     RRC        Contains the "right rotation count" in big  
-
-
-Zhu                         Internet Draft                           9 
-                 Kerberos Version 5 GSS-API      November 2003 
- 
- 
-                           endian order, as described in section 4.2.5. 
-       8..15    SND_SEQ    Sequence number field in clear text, 
-                           expressed in big endian order. 
-       16..last Data       Encrypted data for Wrap tokens with  
-                           confidentiality, or plaintext data followed  
-                           by the checksum for Wrap tokens without  
-                           confidentiality, as described in section  
-                           4.2.4.         
-             
-4.3. Context Deletion Tokens 
- 
-   Context deletion tokens are empty in this mechanism.  Both peers to 
-   a security context invoke GSS_Delete_sec_context() [RFC-2743] 
-   independently, passing a null output_context_token buffer to 
-   indicate that no context_token is required.  Implementations of 
-   GSS_Delete_sec_context() should delete relevant locally-stored 
-   context information. 
-        
-4.4. Token Identifier Assignment Considerations 
-    
-   Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF 
-   inclusive are reserved and SHALL NOT be assigned.  Thus by examining 
-   the first two octets of a token, one can tell unambiguously if it is 
-   wrapped with the generic GSS-API token framing.   
-    
-5. Parameter Definitions 
-    
-   This section defines parameter values used by the Kerberos V5 GSS-
-   API mechanism.  It defines interface elements in support of 
-   portability, and assumes use of C language bindings per [RFC-2744]. 
-    
-5.1. Minor Status Codes 
- 
-   This section recommends common symbolic names for minor_status 
-   values to be returned by the Kerberos V5 GSS-API mechanism.  Use of 
-   these definitions will enable independent implementers to enhance 
-   application portability across different implementations of the 
-   mechanism defined in this specification.  (In all cases, 
-   implementations of GSS_Display_status() will enable callers to 
-   convert minor_status indicators to text representations.)  Each 
-   implementation should make available, through include files or other 
-   means, a facility to translate these symbolic names into the 
-   concrete values which a particular GSS-API implementation uses to 
-   represent the minor_status values specified in this section.  
-    
-   It is recognized that this list may grow over time, and that the 
-   need for additional minor_status codes specific to particular 
-   implementations may arise.  It is recommended, however, that 
-   implementations should return a minor_status value as defined on a 
-   mechanism-wide basis within this section when that code is 
-   accurately representative of reportable status rather than using a 
-   separate, implementation-defined code.  
-    
-5.1.1. Non-Kerberos-specific codes 
-
-
-Zhu                         Internet Draft                          10 
-                 Kerberos Version 5 GSS-API      November 2003 
- 
- 
- 
-      GSS_KRB5_S_G_BAD_SERVICE_NAME  
-              /* "No @ in SERVICE-NAME name string" */ 
-      GSS_KRB5_S_G_BAD_STRING_UID 
-              /* "STRING-UID-NAME contains nondigits" */ 
-      GSS_KRB5_S_G_NOUSER 
-              /* "UID does not resolve to username" */ 
-      GSS_KRB5_S_G_VALIDATE_FAILED 
-              /* "Validation error" */ 
-      GSS_KRB5_S_G_BUFFER_ALLOC 
-              /* "Couldn't allocate gss_buffer_t data" */ 
-      GSS_KRB5_S_G_BAD_MSG_CTX 
-              /* "Message context invalid" */ 
-      GSS_KRB5_S_G_WRONG_SIZE 
-              /* "Buffer is the wrong size" */ 
-      GSS_KRB5_S_G_BAD_USAGE 
-              /* "Credential usage type is unknown" */ 
-      GSS_KRB5_S_G_UNKNOWN_QOP 
-              /* "Unknown quality of protection specified" */ 
-    
-5.1.2. Kerberos-specific-codes 
-    
-      GSS_KRB5_S_KG_CCACHE_NOMATCH  
-              /* "Client principal in credentials does not match   
-                 specified name" */ 
-      GSS_KRB5_S_KG_KEYTAB_NOMATCH 
-              /* "No key available for specified service principal" */ 
-      GSS_KRB5_S_KG_TGT_MISSING 
-              /* "No Kerberos ticket-granting ticket available" */ 
-      GSS_KRB5_S_KG_NO_SUBKEY 
-              /* "Authenticator has no subkey" */ 
-      GSS_KRB5_S_KG_CONTEXT_ESTABLISHED 
-              /* "Context is already fully established" */ 
-      GSS_KRB5_S_KG_BAD_SIGN_TYPE 
-              /* "Unknown signature type in token" */ 
-      GSS_KRB5_S_KG_BAD_LENGTH 
-              /* "Invalid field length in token" */ 
-      GSS_KRB5_S_KG_CTX_INCOMPLETE 
-              /* "Attempt to use incomplete security context" */ 
- 
-5.2. Buffer Sizes 
- 
-   All implementations of this specification shall be capable of 
-   accepting buffers of at least 16K octets as input to GSS_GetMIC(), 
-   GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting 
-   the output_token generated by GSS_Wrap() for a 16K octet input 
-   buffer as input to GSS_Unwrap().  Support for larger buffer sizes is 
-   optional but recommended. 
- 
-6. Backwards Compatibility Considerations 
- 
-   The new token formats defined in this document will only be 
-   recognized by new implementations.  To address this, implementations 
-   can always use the explicit sign or seal algorithm in [RFC-1964] 
-
-
-Zhu                         Internet Draft                          11 
-                 Kerberos Version 5 GSS-API      November 2003 
- 
- 
-   when the key type corresponds to "older" enctypes.  An alternative 
-   approach might be to retry sending the message with the sign or seal 
-   algorithm explicitly defined as in [RFC-1964].  However this would 
-   require either the use of a mechanism such as [RFC-2478] to securely 
-   negotiate the method or the use out of band mechanism to choose 
-   appropriate mechanism.  For this reason, it is RECOMMENDED that the 
-   new token formats defined in this document SHOULD be used only if 
-   both peers are known to support the new mechanism during context 
-   negotiation because of, for example, the use of "new" enctypes. 
- 
-   GSS_Unwrap() or GSS_Verify_MIC() can process a message token as 
-   follows: it can look at the first octet of the token header, if it 
-   is 0x60 then the token must carry the generic GSS-API pseudo ASN.1 
-   framing, otherwise the first two octets of the token contain the 
-   TOK_ID that uniquely identify the token message format. 
-    
-7. Security Considerations 
-    
-   Under the current mechanism, no negotiation of algorithm types 
-   occurs, so server-side (acceptor) implementations cannot request 
-   that clients not use algorithm types not understood by the server. 
-   However, administration of the server's Kerberos data (e.g., the 
-   service key) has to be done in communication with the KDC, and it is 
-   from the KDC that the client will request credentials.  The KDC 
-   could therefore be given the task of limiting session keys for a 
-   given service to types actually supported by the Kerberos and GSSAPI 
-   software on the server.   
-    
-   This does have a drawback for cases where a service principal name 
-   is used both for GSSAPI-based and non-GSSAPI-based communication 
-   (most notably the "host" service key), if the GSSAPI implementation 
-   does not understand (for example) AES [AES-KRB5] but the Kerberos 
-   implementation does.  It means that AES session keys cannot be 
-   issued for that service principal, which keeps the protection of 
-   non-GSSAPI services weaker than necessary.  KDC administrators 
-   desiring to limit the session key types to support interoperability 
-   with such GSSAPI implementations should carefully weigh the 
-   reduction in protection offered by such mechanisms against the 
-   benefits of interoperability. 
-    
-8. Acknowledgments 
- 
-  Ken Raeburn and Nicolas Williams corrected many of our errors in the 
-  use of generic profiles and were instrumental in the creation of this 
-  memo.  
-   
-  The text for security considerations was contributed by Ken Raeburn. 
-   
-  Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, 
-  namely the encoding of the RRC field.   
-   
-  Sam Hartman and Nicolas Williams recommended the replacing our 
-  earlier key derivation function for directional keys with different 
-
-
-Zhu                         Internet Draft                          12 
-                 Kerberos Version 5 GSS-API      November 2003 
- 
- 
-  key usage numbers for each direction as well as retaining the 
-  directional bit for maximum compatibility.   
-   
-  Paul Leach provided numerous suggestions and comments.  
-   
-  Scott Field, Richard Ward, Dan Simon, and Kevin Damour also provided 
-  valuable inputs on this memo. 
-   
-  Jeffrey Hutzelman provided comments on channel bindings and suggested 
-  many editorial changes. 
- 
-  Luke Howard provided implementations of this memo for the Heimdal 
-  code base, and helped inter-operability testing with the Microsoft 
-  code base, together with Love Hornquist Astrand.  These experiments 
-  formed the basis of this memo. 
-   
-  Martin Rex provided suggestions of TOK_ID assignment recommendations 
-  thus the token tagging in this memo is unambiguous if the token is 
-  wrapped with the pseudo ASN.1 header.  
-   
-  This document retains some of the text of RFC-1964 in relevant 
-  sections. 
-   
-9. References 
-    
-9.1. Normative References 
-    
-   [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 
-   3", BCP 9, RFC 2026, October 1996.  
-        
-   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 
-   Requirement Levels", BCP 14, RFC 2119, March 1997. 
-    
-   [RFC-2743] Linn, J., "Generic Security Service Application Program    
-   Interface Version 2, Update 1", RFC 2743, January 2000. 
-    
-   [RFC-2744] Wray, J., "Generic Security Service API Version 2: C-
-   bindings", RFC 2744, January 2000. 
-    
-   [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",    
-   RFC 1964, June 1996. 
-    
-   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 
-   Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003.  Work in 
-   progress.  
-    
-   [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,    
-   Raeburn, K., "The Kerberos Network Authentication Service (V5)",    
-   draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002. 
-   Work in progress. 
-    
-   [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
-   raeburn-krb-rijndael-krb-05.txt, June 2003.  Work in progress. 
-
- 
-Zhu                         Internet Draft                          13 
-                 Kerberos Version 5 GSS-API      November 2003 
- 
- 
-    
-   [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
-   Negotiation Mechanism", RFC 2478, December 1998. 
- 
-9.2. Informative References 
- 
-   [SSPI] Leach, P., "Security Service Provider Interface", Microsoft 
-   Developer Network (MSDN), April 2003. 
-    
-10. Author's Address 
-    
-   Larry Zhu 
-   One Microsoft Way 
-   Redmond, WA 98052 - USA 
-   EMail: LZhu@microsoft.com 
- 
-   Karthik Jaganathan 
-   One Microsoft Way 
-   Redmond, WA 98052 - USA 
-   EMail: karthikj@microsoft.com 
- 
-   Sam Hartman 
-   Massachusetts Institute of Technology 
-   77 Massachusetts Avenue 
-   Cambridge, MA 02139 - USA 
-   Email: hartmans@MIT.EDU 
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                         Internet Draft                          14 
-                 Kerberos Version 5 GSS-API      November 2003 
- 
- 
-    
-Full Copyright Statement 
-    
-   Copyright (C) The Internet Society (date). All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this 
-   document itself may not be modified in any way, such as by removing 
-   the copyright notice or references to the Internet Society or other 
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                         Internet Draft                          15 
diff --git a/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-06.txt b/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-06.txt
deleted file mode 100644
index 92c665896..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-06.txt
+++ /dev/null
@@ -1,988 +0,0 @@
-
- 
-
-<Network Working Group>                                       Larry Zhu 
-Internet Draft                                       Karthik Jaganathan 
-Updates: 1964                                                 Microsoft 
-Category: Standards Track                                   Sam Hartman 
-draft-ietf-krb-wg-gssapi-cfx-06.txt                                 MIT 
-                                                      February 16, 2004 
-                                               Expires: August 16, 2004 
- 
-          The Kerberos Version 5 GSS-API Mechanism: Version 2 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of [RFC-2026].  
-    
-   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."  
-    
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt.   
-    
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-   To learn the current status of any Internet-Draft, please check the 
-   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 
-   Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 
-   ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 
- 
-   The distribution of this memo is unlimited.  It is filed as  
-   draft-ietf-krb-wg-gssapi-cfx-06.txt, and expires on August 10 
-   2004.  Please send comments to: ietf-krb-wg@anl.gov. 
-    
-Abstract 
-    
-   This document defines protocols, procedures, and conventions to be 
-   employed by peers implementing the Generic Security Service 
-   Application Program Interface (GSS-API) when using the Kerberos 
-   Version 5 mechanism. 
-    
-   RFC-1964 is updated and incremental changes are proposed in response 
-   to recent developments such as the introduction of Kerberos 
-   cryptosystem framework.  These changes support the inclusion of new 
-   cryptosystems, by defining new per-message tokens along with their 
-   encryption and checksum algorithms based on the cryptosystem 
-   profiles.   
-    
-Conventions used in this document 
-  
-Zhu                                                                   1 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
-   document are to be interpreted as described in [RFC-2119]. 
-    
-   The term "little endian order" is used for brevity to refer to the 
-   least-significant-octet-first encoding, while the term "big endian 
-   order" is for the most-significant-octet-first encoding. 
-    
-Table of Contents 
-
-   1. Introduction ...............................................  2 
-   2. Key Derivation for Per-Message Tokens ......................  3 
-   3. Quality of Protection ......................................  4 
-   4. Definitions and Token Formats ..............................  4 
-   4.1. Context Establishment Tokens .............................  4 
-   4.1.1. Authenticator Checksum .................................  5 
-   4.2. Per-Message Tokens .......................................  8 
-   4.2.1. Sequence Number ........................................  8 
-   4.2.2. Flags Field ............................................  8 
-   4.2.3. EC Field ...............................................  9 
-   4.2.4. Encryption and Checksum Operations .....................  9 
-   4.2.5. RRC Field .............................................. 10 
-   4.2.6. Message Layouts ........................................ 10 
-   4.3. Context Deletion Tokens .................................. 11 
-   4.4. Token Identifier Assignment Considerations ............... 11 
-   5. Parameter Definitions ...................................... 12 
-   5.1. Minor Status Codes ....................................... 12 
-   5.1.1. Non-Kerberos-specific codes ............................ 12 
-   5.1.2. Kerberos-specific-codes ................................ 12 
-   5.2. Buffer Sizes ............................................. 13 
-   6. Backwards Compatibility Considerations ..................... 13 
-   7. Security Considerations .................................... 13 
-   8. Acknowledgments ............................................ 14 
-   9. Intellectual Property Statement ............................ 15
-   10. References ................................................ 15 
-   10.1. Normative References .................................... 15 
-   10.2. Informative References .................................. 15 
-   11. Author's Address .......................................... 15
-   Full Copyright Statement ...................................... 17  
-   
-1. Introduction 
-    
-   [KCRYPTO] defines a generic framework for describing encryption and 
-   checksum types to be used with the Kerberos protocol and associated 
-   protocols. 
-    
-   [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.  
-   It defines the format of context establishment, per-message and 
-   context deletion tokens and uses algorithm identifiers for each 
-   cryptosystem in per message and context deletion tokens.   
-    
-   The approach taken in this document obviates the need for algorithm 
-   identifiers.  This is accomplished by using the same encryption 
-   algorithm, specified by the crypto profile [KCRYPTO] for the session 
-   key or subkey that is created during context negotiation, and its 
-   required checksum algorithm.  Message layouts of the per-message 
-Zhu                                                                  2 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-   tokens are therefore revised to remove algorithm indicators and also 
-   to add extra information to support the generic crypto framework 
-   [KCRYPTO].  
-    
-   Tokens transferred between GSS-API peers for security context 
-   establishment are also described in this document.  The data 
-   elements exchanged between a GSS-API endpoint implementation and the 
-   Kerberos Key Distribution Center (KDC) [KRBCLAR] are not specific to 
-   GSS-API usage and are therefore defined within [KRBCLAR] rather than 
-   within this specification. 
-    
-   The new token formats specified in this document MUST be used with 
-   all "newer" encryption types [KRBCLAR] and MAY be used with "older" 
-   encryption types, provided that the initiator and acceptor know, 
-   from the context establishment, that they can both process these new 
-   token formats. 
-    
-   "Newer" encryption types are those which have been specified along 
-   with or since the new Kerberos cryptosystem specification [KCRYPTO], 
-   as defined in section 3.1.3 of [KRBCLAR].  The list of not-newer 
-   encryption types is as follows [KCRYPTO]: 
-    
-             Encryption Type             Assigned Number     
-           ---------------------------------------------- 
-            des-cbc-crc                        1              
-            des-cbc-md4                        2              
-            des-cbc-md5                        3              
-            des3-cbc-md5                       5 
-            des3-cbc-sha1                      7 
-            dsaWithSHA1-CmsOID                 9            
-            md5WithRSAEncryption-CmsOID       10            
-            sha1WithRSAEncryption-CmsOID      11           
-            rc2CBC-EnvOID                     12            
-            rsaEncryption-EnvOID              13    
-            rsaES-OAEP-ENV-OID                14    
-            des-ede3-cbc-Env-OID              15            
-            des3-cbc-sha1-kd                  16                       
-            rc4-hmac                          23          
-    
-2. Key Derivation for Per-Message Tokens 
-    
-   To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 
-   "entropy-preserving" derived keys, for different purposes or key 
-   usages, from a base key or protocol key.   
-    
-   This document defines four key usage values below that are used to 
-   derive a specific key for signing and sealing messages, from the 
-   session key or subkey [KRBCLAR] created during the context 
-   establishment. 
-    
-        Name                         Value 
-      ------------------------------------- 
-       KG-USAGE-ACCEPTOR-SEAL         22 
-       KG-USAGE-ACCEPTOR-SIGN         23 
-       KG-USAGE-INITIATOR-SEAL        24 
-
-Zhu                                                                  3 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-       KG-USAGE-INITIATOR-SIGN        25 
-          
-   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 
-   used as the usage number in the key derivation function for deriving 
-   keys to be used in MIC tokens (as defined in section 4.2.6.1), and 
-   KG-USAGE-ACCEPTOR-SEAL is used for Wrap tokens(as defined in section 
-   4.2.6.2); similarly when the sender is the context initiator, KG-
-   USAGE-INITIATOR-SIGN is used as the usage number in the key 
-   derivation function for MIC tokens, KG-USAGE-INITIATOR-SEAL is used 
-   for Wrap Tokens.  Even if the Wrap token does not provide for 
-   confidentiality the same usage values specified above are used. 
-    
-   During the context initiation and acceptance sequence, the acceptor 
-   MAY assert a subkey, and if so, subsequent messages MUST use this 
-   subkey as the protocol key and these messages MUST be flagged as 
-   "AcceptorSubkey" as described in section 4.2.2. 
- 
-3. Quality of Protection 
- 
-   The GSS-API specification [RFC-2743] provides for Quality of 
-   Protection (QOP) values that can be used by applications to request 
-   a certain type of encryption or signing.  A zero QOP value is used 
-   to indicate the "default" protection; applications which do not use 
-   the default QOP are not guaranteed to be portable across 
-   implementations or even inter-operate with different deployment 
-   configurations of the same implementation.  Using an algorithm that 
-   is different from the one for which the key is defined may not be 
-   appropriate.  Therefore, when the new method in this document is 
-   used, the QOP value is ignored. 
-    
-   The encryption and checksum algorithms in per-message tokens are now 
-   implicitly defined by the algorithms associated with the session key 
-   or subkey.  Algorithms identifiers as described in [RFC-1964] are 
-   therefore no longer needed and removed from the new token headers. 
- 
-4. Definitions and Token Formats 
-    
-   This section provides terms and definitions, as well as descriptions 
-   for tokens specific to the Kerberos Version 5 GSS-API mechanism. 
-                                    
-4.1. Context Establishment Tokens 
-    
-   All context establishment tokens emitted by the Kerberos Version 5 
-   GSS-API mechanism SHALL have the framing described in section 3.1 of 
-   [RFC-2743], as illustrated by the following pseudo-ASN.1 structures: 
-    
-         GSS-API DEFINITIONS ::= 
-    
-         BEGIN 
-    
-         MechType ::= OBJECT IDENTIFIER 
-         -- representing Kerberos V5 mechanism 
-    
-         GSSAPI-Token ::= 
-         -- option indication (delegation, etc.) indicated within 
-Zhu                                                                  4 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-         -- mechanism-specific token 
-         [APPLICATION 0] IMPLICIT SEQUENCE { 
-                 thisMech MechType, 
-                 innerToken ANY DEFINED BY thisMech 
-                    -- contents mechanism-specific 
-                    -- ASN.1 structure not required 
-                 } 
-    
-         END 
-    
-   Where the innerToken field starts with a two-octet token-identifier 
-   (TOK_ID) expressed in big endian order, followed by a Kerberos 
-   message.   
-    
-   Here are the TOK_ID values used in the context establishment tokens: 
-    
-         Token               TOK_ID Value in Hex  
-        ----------------------------------------- 
-         KRB_AP_REQ            01 00 
-         KRB_AP_REP            02 00 
-         KRB_ERROR             03 00 
-             
-   Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR 
-   are defined in [KRBCLAR].   
-    
-   If an unknown token identifier (TOK_ID) is received in the initial 
-   context establishment token, the receiver MUST return 
-   GSS_S_CONTINUE_NEEDED major status, and the returned output token 
-   MUST contain a KRB_ERROR message with the error code 
-   KRB_AP_ERR_MSG_TYPE [KRBCLAR]. 
-    
-4.1.1. Authenticator Checksum 
- 
-   The authenticator in the KRB_AP_REQ message MUST include the 
-   optional sequence number and the checksum field.  The checksum field 
-   is used to convey service flags, channel bindings, and optional 
-   delegation information.   
-    
-   The checksum type MUST be 0x8003. When delegation is used, a ticket-
-   granting ticket will be transferred in a KRB_CRED message.  This 
-   ticket SHOULD have its forwardable flag set.  The EncryptedData 
-   field of the KRB_CRED message [KRBCLAR] MUST be encrypted in the 
-   session key of the ticket used to authenticate the context. 
-    
-   The authenticator checksum field SHALL have the following format: 
-       
-      Octet        Name      Description 
-     ----------------------------------------------------------------- 
-      0..3         Lgth    Number of octets in Bnd field;  Represented  
-                           in little-endian order;  Currently contains   
-                           hex value 10 00 00 00 (16). 
-      4..19        Bnd     Channel binding information, as described in  
-                           section 4.1.1.2. 
-      20..23       Flags   Four-octet context-establishment flags in 
-                           little-endian order as described in section  
-Zhu                                                                  5 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-                           4.1.1.1.  
-      24..25       DlgOpt  The delegation option identifier (=1) in  
-                           little-endian order [optional].  This field  
-                           and the next two fields are present if and  
-                           only if GSS_C_DELEG_FLAG is set as described  
-                           in section 4.1.1.1.   
-      26..27       Dlgth   The length of the Deleg field in little- 
-                           endian order [optional]. 
-      28..(n-1)    Deleg   A KRB_CRED message (n = Dlgth + 28)  
-                           [optional].  
-      n..last      Exts    Extensions [optional]. 
-    
-   The length of the checksum field MUST be at least 24 octets when 
-   GSS_C_DELEG_FLAG is not set (as described in section 4.1.1.1), and 
-   at least 28 octets plus Dlgth octets when GSS_C_DELEG_FLAG is set.  
-   When GSS_C_DELEG_FLAG is set, the DlgOpt, Dlgth and Deleg fields 
-   of the checksum data MUST immediately follow the Flags field.  The 
-   optional trailing octets (namely the "Exts" field) facilitate 
-   future extensions to this mechanism.  When delegation is not used 
-   but the Exts field is present, the Exts field starts at octet 24 
-   (DlgOpt, Dlgth and Deleg are absent). 
-    
-   Initiators that do not support the extensions MUST NOT include more 
-   than 24 octets in the checksum field, when GSS_C_DELEG_FLAG is not 
-   set, or more than 28 octets plus the KRB_CRED in the Deleg field, 
-   when GSS_C_DELEG_FLAG is set.  Acceptors that do not understand the 
-   extensions MUST ignore any octets past the Deleg field of the 
-   checksum data, when GSS_C_DELEG_FLAG is set, or past the Flags field 
-   of the checksum data, when GSS_C_DELEG_FLAG is not set. 
- 
-4.1.1.1. Checksum Flags Field 
-    
-   The checksum "Flags" field is used to convey service options or 
-   extension negotiation information. 
-    
-   The following context establishment flags are defined in [RFC-2744].   
-    
-        Flag Name              Value     
-      --------------------------------- 
-       GSS_C_DELEG_FLAG           1        
-       GSS_C_MUTUAL_FLAG          2       
-       GSS_C_REPLAY_FLAG          4       
-       GSS_C_SEQUENCE_FLAG        8        
-       GSS_C_CONF_FLAG           16      
-       GSS_C_INTEG_FLAG          32     
-        
-   Context establishment flags are exposed to the calling application.  
-   If the calling application desires a particular service option then 
-   it requests that option via GSS_Init_sec_context() [RFC-2743].  If 
-   the corresponding return state values [RFC-2743] indicate that any 
-   of above optional context level services will be active on the 
-   context, the corresponding flag values in the table above MUST be 
-   set in the checksum Flags field. 
-    
-
-Zhu                                                                  6 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-   Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for 
-   use with legacy vendor-specific extensions to this mechanism. 
-    
-   All other flag values not specified herein are reserved for future 
-   use.  Future revisions of this mechanism may use these reserved 
-   flags and may rely on implementations of this version to not use 
-   such flags in order to properly negotiate mechanism versions.  
-   Undefined flag values MUST be cleared by the sender, and unknown 
-   flags MUST be ignored by the receiver.   
-    
-4.1.1.2. Channel Binding Information 
-    
-   These tags are intended to be used to identify the particular 
-   communications channel for which the GSS-API security context 
-   establishment tokens are intended, thus limiting the scope within 
-   which an intercepted context establishment token can be reused by an 
-   attacker (see [RFC-2743], section 1.1.6). 
-    
-   When using C language bindings, channel bindings are communicated 
-   to the GSS-API using the following structure [RFC-2744]: 
- 
-      typedef struct gss_channel_bindings_struct { 
-         OM_uint32       initiator_addrtype; 
-         gss_buffer_desc initiator_address; 
-         OM_uint32       acceptor_addrtype; 
-         gss_buffer_desc acceptor_address; 
-         gss_buffer_desc application_data; 
-      } *gss_channel_bindings_t; 
-    
-   The member fields and constants used for different address types 
-   are defined in [RFC-2744]. 
-    
-   The "Bnd" field contains the MD5 hash of channel bindings, taken 
-   over all non-null components of bindings, in order of declaration.  
-   Integer fields within channel bindings are represented in little-
-   endian order for the purposes of the MD5 calculation. 
-    
-   In computing the contents of the Bnd field, the following detailed 
-   points apply:  
-    
-   (1) For purposes of MD5 hash computation, each integer field and 
-   input length field SHALL be formatted into four octets, using 
-   little endian octet ordering.  
-    
-   (2) All input length fields within gss_buffer_desc elements of a 
-   gss_channel_bindings_struct even those which are zero-valued, SHALL 
-   be included in the hash calculation; the value elements of 
-   gss_buffer_desc elements SHALL be dereferenced, and the resulting 
-   data SHALL be included within the hash computation, only for the 
-   case of gss_buffer_desc elements having non-zero length specifiers.  
-    
-   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 
-   valid channel binding structure, the Bnd field SHALL be set to 16 
-   zero-valued octets.  
- 
-Zhu                                                                  7 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-   If the caller to GSS_Accept_sec_context [RFC-2743] passes in 
-   GSS_C_NO_CHANNEL_BINDINGS [RFC-2744] as the channel bindings then 
-   the acceptor MAY ignore any channel bindings supplied by the 
-   initiator, returning success even if the initiator did pass in 
-   channel bindings. 
-    
-   If the application supply, in the channel bindings, a buffer with a 
-   length field larger than 4294967295 (2^32 - 1), the implementation 
-   of this mechanism MAY chose to reject the channel bindings 
-   altogether, using major status GSS_S_BAD_BINDINGS [RFC-2743].  In 
-   any case, the size of channel binding data buffers that can be used 
-   (interoperable, without extensions) with this specification is 
-   limited to 4294967295 octets. 
-    
-4.2. Per-Message Tokens 
-    
-   Two classes of tokens are defined in this section:  "MIC" tokens, 
-   emitted by calls to GSS_GetMIC() and consumed by calls to 
-   GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and 
-   consumed by calls to GSS_Unwrap(). 
-    
-   The new per-message tokens introduced here do not include the 
-   generic GSS-API token framing used by the context establishment 
-   tokens.  These new tokens are designed to be used with newer crypto 
-   systems that can, for example, have variable-size checksums.   
-    
-4.2.1. Sequence Number 
- 
-   To distinguish intentionally-repeated messages from maliciously-
-   replayed ones, per-message tokens contain a sequence number field, 
-   which is a 64 bit integer expressed in big endian order.  After 
-   sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence 
-   numbers SHALL be incremented by one. 
- 
-4.2.2. Flags Field 
- 
-   The "Flags" field is a one-octet integer used to indicate a set of 
-   attributes for the protected message.  For example, one flag is 
-   allocated as the direction-indicator, thus preventing an adversary 
-   from sending back the same message in the reverse direction and 
-   having it accepted.   
-    
-   The meanings of bits in this field (the least significant bit is 
-   bit 0) are as follows: 
-    
-        Bit    Name             Description 
-       --------------------------------------------------------------- 
-        0   SentByAcceptor    When set, this flag indicates the sender  
-                              is the context acceptor.  When not set, 
-                              it indicates the sender is the context  
-                              initiator. 
-        1   Sealed            When set in Wrap tokens, this flag  
-                              indicates confidentiality is provided  
-                              for.  It SHALL NOT be set in MIC tokens. 
-        2   AcceptorSubkey    A subkey asserted by the context acceptor 
-Zhu                                                                  8 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-                              is used to protect the message. 
-    
-   The rest of available bits are reserved for future use and MUST be 
-   cleared.  The receiver MUST ignore unknown flags. 
-    
-4.2.3. EC Field 
- 
-   The "EC" (Extra Count) field is a two-octet integer field expressed 
-   in big endian order.   
-    
-   In Wrap tokens with confidentiality, the EC field SHALL be used to 
-   encode the number of octets in the filler, as described in section 
-   4.2.4. 
-    
-   In Wrap tokens without confidentiality, the EC field SHALL be used 
-   to encode the number of octets in the trailing checksum, as 
-   described in section 4.2.4.   
- 
-4.2.4. Encryption and Checksum Operations 
-    
-   The encryption algorithms defined by the crypto profiles provide for 
-   integrity protection [KCRYPTO].  Therefore no separate checksum is 
-   needed.  
-    
-   The result of decryption can be longer than the original plaintext 
-   [KCRYPTO] and the extra trailing octets are called "crypto-system 
-   garbage" in this document.  However, given the size of any plaintext 
-   data, one can always find a (possibly larger) size so that, when 
-   padding the to-be-encrypted text to that size, there will be no 
-   crypto-system garbage added [KCRYPTO].  
- 
-   In Wrap tokens that provide for confidentiality, the first 16 octets 
-   of the Wrap token (the "header", as defined in section 4.2.6), SHALL 
-   be appended to the plaintext data before encryption.  Filler octets 
-   MAY be inserted between the plaintext data and the "header", and the 
-   values and size of the filler octets are chosen by implementations, 
-   such that there SHALL be no crypto-system garbage present after the 
-   decryption.  The resulting Wrap token is {"header" | 
-   encrypt(plaintext-data | filler | "header")}, where encrypt() is the 
-   encryption operation (which provides for integrity protection) 
-   defined in the crypto profile [KCRYPTO], and the RRC field (as 
-   defined in section 4.2.5) in the to-be-encrypted header contain the 
-   hex value 00 00.   
-           
-   In Wrap tokens that do not provide for confidentiality, the checksum 
-   SHALL be calculated first over the to-be-signed plaintext data, and 
-   then the first 16 octets of the Wrap token (the "header", as defined 
-   in section 4.2.6).  Both the EC field and the RRC field in the token 
-   header SHALL be filled with zeroes for the purpose of calculating 
-   the checksum.  The resulting Wrap token is {"header" | plaintext-
-   data | get_mic(plaintext-data | "header")},  where get_mic() is the 
-   checksum operation for the required checksum mechanism of the chosen 
-   encryption mechanism defined in the crypto profile [KCRYPTO].  
-    
-
-Zhu                                                                  9 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-   The parameters for the key and the cipher-state in the encrypt() and 
-   get_mic() operations have been omitted for brevity.   
-        
-   For MIC tokens, the checksum SHALL be calculated as follows: the 
-   checksum operation is calculated first over the to-be-signed 
-   plaintext data, and then the first 16 octets of the MIC token, where 
-   the checksum mechanism is the required checksum mechanism of the 
-   chosen encryption mechanism defined in the crypto profile [KCRYPTO]. 
-   
-   The resulting Wrap and MIC tokens bind the data to the token header, 
-   including the sequence number and the direction indicator.  
-   
-4.2.5. RRC Field 
- 
-   The "RRC" (Right Rotation Count) field in Wrap tokens is added to 
-   allow the data to be encrypted in-place by existing SSPI (Security 
-   Service Provider Interface) [SSPI] applications that do not provide 
-   an additional buffer for the trailer (the cipher text after the in-
-   place-encrypted data) in addition to the buffer for the header (the 
-   cipher text before the in-place-encrypted data).  The resulting Wrap 
-   token in the previous section, excluding the first 16 octets of the 
-   token header, is rotated to the right by "RRC" octets.  The net 
-   result is that "RRC" octets of trailing octets are moved toward the 
-   header.  Consider the following as an example of this rotation 
-   operation:  Assume that the RRC value is 3 and the token before the 
-   rotation is {"header" | aa | bb | cc | dd | ee | ff | gg | hh}, the 
-   token after rotation would be {"header" | ff | gg | hh | aa | bb | 
-   cc | dd | ee }, where {aa | bb | cc |...| hh} is used to indicate 
-   the octet sequence. 
-  
-   The RRC field is expressed as a two-octet integer in big endian 
-   order. 
-    
-   The rotation count value is chosen by the sender based on 
-   implementation details, and the receiver MUST be able to interpret 
-   all possible rotation count values, including rotation counts 
-   greater than the length of the token. 
- 
-4.2.6. Message Layouts 
-    
-   Per-message tokens start with a two-octet token identifier (TOK_ID) 
-   field, expressed in big endian order.  These tokens are defined 
-   separately in subsequent sub-sections. 
-    
-4.2.6.1. MIC Tokens 
-    
-   Use of the GSS_GetMIC() call yields a token (referred as the MIC 
-   token in this document), separate from the user  
-   data being protected, which can be used to verify the integrity of  
-   that data as received.  The token has the following format: 
-    
-      Octet no   Name        Description 
-      ----------------------------------------------------------------- 
-       0..1     TOK_ID     Identification field.  Tokens emitted by  
-                           GSS_GetMIC() contain the hex value 04 04  
-Zhu                                                                 10 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-                           expressed in big endian order in this field. 
-       2        Flags      Attributes field, as described in section  
-                           4.2.2. 
-       3..7     Filler     Contains five octets of hex value FF. 
-       8..15    SND_SEQ    Sequence number field in clear text,  
-                           expressed in big endian order.  
-       16..last SGN_CKSUM  Checksum of the "to-be-signed" data and  
-                           octet 0..15, as described in section 4.2.4. 
-    
-   The Filler field is included in the checksum calculation for 
-   simplicity.   
-    
-4.2.6.2. Wrap Tokens 
-    
-   Use of the GSS_Wrap() call yields a token (referred as the Wrap 
-   token in this document), which consists of a descriptive header, 
-   followed by a body portion that contains either the input user data 
-   in plaintext concatenated with the checksum, or the input user data 
-   encrypted.  The GSS_Wrap() token SHALL have the following format: 
-    
-      Octet no   Name        Description 
-      --------------------------------------------------------------- 
-       0..1     TOK_ID     Identification field.  Tokens emitted by  
-                           GSS_Wrap() contain the the hex value 05 04                 
-                           expressed in big endian order in this field. 
-       2        Flags      Attributes field, as described in section  
-                           4.2.2. 
-       3        Filler     Contains the hex value FF. 
-       4..5     EC         Contains the "extra count" field, in big  
-                           endian order as described in section 4.2.3. 
-       6..7     RRC        Contains the "right rotation count" in big  
-                           endian order, as described in section 4.2.5. 
-       8..15    SND_SEQ    Sequence number field in clear text, 
-                           expressed in big endian order. 
-       16..last Data       Encrypted data for Wrap tokens with  
-                           confidentiality, or plaintext data followed  
-                           by the checksum for Wrap tokens without  
-                           confidentiality, as described in section  
-                           4.2.4.         
-             
-4.3. Context Deletion Tokens 
- 
-   Context deletion tokens are empty in this mechanism.  Both peers to 
-   a security context invoke GSS_Delete_sec_context() [RFC-2743] 
-   independently, passing a null output_context_token buffer to 
-   indicate that no context_token is required.  Implementations of 
-   GSS_Delete_sec_context() should delete relevant locally-stored 
-   context information. 
-        
-4.4. Token Identifier Assignment Considerations 
-    
-   Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF 
-   inclusive are reserved and SHALL NOT be assigned.  Thus by examining 
-   the first two octets of a token, one can tell unambiguously if it is 
-   wrapped with the generic GSS-API token framing.   
-Zhu                                                                 11 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-    
-5. Parameter Definitions 
-    
-   This section defines parameter values used by the Kerberos V5 GSS-
-   API mechanism.  It defines interface elements in support of 
-   portability, and assumes use of C language bindings per [RFC-2744]. 
-    
-5.1. Minor Status Codes 
- 
-   This section recommends common symbolic names for minor_status 
-   values to be returned by the Kerberos V5 GSS-API mechanism.  Use of 
-   these definitions will enable independent implementers to enhance 
-   application portability across different implementations of the 
-   mechanism defined in this specification.  (In all cases, 
-   implementations of GSS_Display_status() will enable callers to 
-   convert minor_status indicators to text representations.)  Each 
-   implementation should make available, through include files or other 
-   means, a facility to translate these symbolic names into the 
-   concrete values which a particular GSS-API implementation uses to 
-   represent the minor_status values specified in this section.  
-    
-   It is recognized that this list may grow over time, and that the 
-   need for additional minor_status codes specific to particular 
-   implementations may arise.  It is recommended, however, that 
-   implementations should return a minor_status value as defined on a 
-   mechanism-wide basis within this section when that code is 
-   accurately representative of reportable status rather than using a 
-   separate, implementation-defined code.  
-    
-5.1.1. Non-Kerberos-specific codes 
- 
-      GSS_KRB5_S_G_BAD_SERVICE_NAME  
-              /* "No @ in SERVICE-NAME name string" */ 
-      GSS_KRB5_S_G_BAD_STRING_UID 
-              /* "STRING-UID-NAME contains nondigits" */ 
-      GSS_KRB5_S_G_NOUSER 
-              /* "UID does not resolve to username" */ 
-      GSS_KRB5_S_G_VALIDATE_FAILED 
-              /* "Validation error" */ 
-      GSS_KRB5_S_G_BUFFER_ALLOC 
-              /* "Couldn't allocate gss_buffer_t data" */ 
-      GSS_KRB5_S_G_BAD_MSG_CTX 
-              /* "Message context invalid" */ 
-      GSS_KRB5_S_G_WRONG_SIZE 
-              /* "Buffer is the wrong size" */ 
-      GSS_KRB5_S_G_BAD_USAGE 
-              /* "Credential usage type is unknown" */ 
-      GSS_KRB5_S_G_UNKNOWN_QOP 
-              /* "Unknown quality of protection specified" */ 
-    
-5.1.2. Kerberos-specific-codes 
-    
-      GSS_KRB5_S_KG_CCACHE_NOMATCH  
-              /* "Client principal in credentials does not match   
-                 specified name" */ 
-Zhu                                                                 12 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-      GSS_KRB5_S_KG_KEYTAB_NOMATCH 
-              /* "No key available for specified service principal" */ 
-      GSS_KRB5_S_KG_TGT_MISSING 
-              /* "No Kerberos ticket-granting ticket available" */ 
-      GSS_KRB5_S_KG_NO_SUBKEY 
-              /* "Authenticator has no subkey" */ 
-      GSS_KRB5_S_KG_CONTEXT_ESTABLISHED 
-              /* "Context is already fully established" */ 
-      GSS_KRB5_S_KG_BAD_SIGN_TYPE 
-              /* "Unknown signature type in token" */ 
-      GSS_KRB5_S_KG_BAD_LENGTH 
-              /* "Invalid field length in token" */ 
-      GSS_KRB5_S_KG_CTX_INCOMPLETE 
-              /* "Attempt to use incomplete security context" */ 
- 
-5.2. Buffer Sizes 
- 
-   All implementations of this specification MUST be capable of 
-   accepting buffers of at least 16K octets as input to GSS_GetMIC(), 
-   GSS_VerifyMIC(), and GSS_Wrap(), and MUST be capable of accepting 
-   the output_token generated by GSS_Wrap() for a 16K octet input 
-   buffer as input to GSS_Unwrap().  Implementations SHOULD support 64K 
-   octet input buffers, and MAY support even larger input buffer sizes. 
- 
-6. Backwards Compatibility Considerations 
- 
-   The new token formats defined in this document will only be 
-   recognized by new implementations.  To address this, implementations 
-   can always use the explicit sign or seal algorithm in [RFC-1964] 
-   when the key type corresponds to "older" enctypes.  An alternative 
-   approach might be to retry sending the message with the sign or seal 
-   algorithm explicitly defined as in [RFC-1964].  However this would 
-   require either the use of a mechanism such as [RFC-2478] to securely 
-   negotiate the method or the use out of band mechanism to choose 
-   appropriate mechanism.  For this reason, it is RECOMMENDED that the 
-   new token formats defined in this document SHOULD be used only if 
-   both peers are known to support the new mechanism during context 
-   negotiation because of, for example, the use of "new" enctypes. 
- 
-   GSS_Unwrap() or GSS_VerifyMIC() can process a message token as 
-   follows: it can look at the first octet of the token header, if it 
-   is 0x60 then the token must carry the generic GSS-API pseudo ASN.1 
-   framing, otherwise the first two octets of the token contain the 
-   TOK_ID that uniquely identify the token message format. 
-    
-7. Security Considerations 
-    
-   Channel bindings are validated by the acceptor.  The acceptor can 
-   ignore the channel bindings restriction supplied by the initiator 
-   and carried in the authenticator checksum, if channel bindings are 
-   not used by GSS_Accept_sec_context [RFC-2743], and the acceptor does 
-   not prove to the initiator that it has the same channel bindings as 
-   the initiator, even if the client requested mutual authentication.  
-   This limitation should be taken into consideration by designers of 
-   applications that would use channel bindings, whether to limit the 
-Zhu                                                                 13 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-   use of GSS-API contexts to nodes with specific network addresses, to 
-   authenticate other established, secure channels using Kerberos 
-   Version 5, or for any other purpose. 
-    
-   Session key types are selected by the KDC.  Under the current 
-   mechanism, no negotiation of algorithm types occurs, so server-side 
-   (acceptor) implementations cannot request that clients not use 
-   algorithm types not understood by the server.  However, 
-   administrators can control what enctypes can be used for session 
-   keys for this mechanism by controlling the set of the ticket session 
-   key enctypes which the KDC is willing to use in tickets for a given 
-   acceptor principal.  The KDC could therefore be given the task of 
-   limiting session keys for a given service to types actually 
-   supported by the Kerberos and GSSAPI software on the server.  This 
-   does have a drawback for cases where a service principal name is 
-   used both for GSSAPI-based and non-GSSAPI-based communication (most 
-   notably the "host" service key), if the GSSAPI implementation does 
-   not understand (for example) AES [AES-KRB5] but the Kerberos 
-   implementation does.  It means that AES session keys cannot be 
-   issued for that service principal, which keeps the protection of 
-   non-GSSAPI services weaker than necessary.  KDC administrators 
-   desiring to limit the session key types to support interoperability 
-   with such GSSAPI implementations should carefully weigh the 
-   reduction in protection offered by such mechanisms against the 
-   benefits of interoperability. 
-    
-8. Acknowledgments 
- 
-  Ken Raeburn and Nicolas Williams corrected many of our errors in the 
-  use of generic profiles and were instrumental in the creation of 
-  this document.  
-   
-  The text for security considerations was contributed by Nicolas 
-  Williams and Ken Raeburn. 
-   
-  Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, 
-  namely the encoding of the RRC field.   
-   
-  Sam Hartman and Nicolas Williams recommended the replacing our 
-  earlier key derivation function for directional keys with different 
-  key usage numbers for each direction as well as retaining the 
-  directional bit for maximum compatibility.   
-   
-  Paul Leach provided numerous suggestions and comments.  
-   
-  Scott Field, Richard Ward, Dan Simon, Kevin Damour, and Simon 
-  Josefsson also provided valuable inputs on this document. 
-   
-  Jeffrey Hutzelman provided comments and clarifications for the text 
-  related to the channel bindings.  
-   
-  Jeffrey Hutzelman and Russ Housley suggested many editorial changes. 
- 
-
-
-Zhu                                                                 14 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-  Luke Howard provided implementations of this document for the 
-  Heimdal code base, and helped inter-operability testing with the 
-  Microsoft code base, together with Love Hornquist Astrand.  These 
-  experiments formed the basis of this document. 
-   
-  Martin Rex provided suggestions of TOK_ID assignment recommendations 
-  thus the token tagging in this document is unambiguous if the token 
-  is wrapped with the pseudo ASN.1 header.  
-   
-  This document retains some of the text of RFC-1964 in relevant 
-  sections. 
-   
-9. Intellectual Property Statement 
- 
-   The IETF takes no position regarding the validity or scope of any 
-   intellectual property or other rights that might be claimed to 
-   pertain to the implementation or use of the technology described in 
-   this document or the extent to which any license under such rights 
-   might or might not be available; neither does it represent that it 
-   has made any effort to identify any such rights.  Information on the 
-   IETF's procedures with respect to rights in standards-track and 
-   standards-related documentation can be found in BCP-11.  Copies of 
-   claims of rights made available for publication and any assurances 
-   of licenses to be made available, or the result of an attempt made 
-   to obtain a general license or permission for the use of such 
-   proprietary rights by implementers or users of this specification 
-   can be obtained from the IETF Secretariat. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights which may cover technology that may be required to practice 
-   this standard.  Please address the information to the IETF Executive 
-   Director. 
-   
-10. References 
-    
-10.1. Normative References 
-    
-   [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 
-   3", BCP 9, RFC 2026, October 1996.  
-        
-   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 
-   Requirement Levels", BCP 14, RFC 2119, March 1997. 
-    
-   [RFC-2743] Linn, J., "Generic Security Service Application Program    
-   Interface Version 2, Update 1", RFC 2743, January 2000. 
-    
-   [RFC-2744] Wray, J., "Generic Security Service API Version 2: C-
-   bindings", RFC 2744, January 2000. 
-    
-   [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",    
-   RFC 1964, June 1996. 
-    
-
-
-Zhu                                                                 15 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-   [KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf-
-   krb-wg-crypto.  Work in Progress. 
-    
-   [KRBCLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
-   krb-wg-kerberos-clarifications.  Work in Progress. 
- 
-10.2. Informative References 
- 
-   [SSPI] Leach, P., "Security Service Provider Interface", Microsoft 
-   Developer Network (MSDN), April 2003. 
-    
-   [AES-KRB5] RFC-Editor: To be replaced by RFC number for draft-
-   raeburn-krb-rijndael-krb.  Work in Progress. 
-    
-   [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
-   Negotiation Mechanism", RFC 2478, December 1998. 
-    
-11. Author's Address 
-    
-   Larry Zhu 
-   One Microsoft Way 
-   Redmond, WA 98052 - USA 
-   EMail: LZhu@microsoft.com 
- 
-   Karthik Jaganathan 
-   One Microsoft Way 
-   Redmond, WA 98052 - USA 
-   EMail: karthikj@microsoft.com 
- 
-   Sam Hartman 
-   Massachusetts Institute of Technology 
-   77 Massachusetts Avenue 
-   Cambridge, MA 02139 - USA 
-   Email: hartmans@MIT.EDU 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                                                                 16 
-DRAFT               Kerberos Version 5 GSS-API     Expires August 2004 
- 
-    
-Full Copyright Statement 
-    
-   Copyright (C) The Internet Society (date). All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this 
-   document itself may not be modified in any way, such as by removing 
-   the copyright notice or references to the Internet Society or other 
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                                                                 17 
\ No newline at end of file
diff --git a/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-07.txt b/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-07.txt
deleted file mode 100644
index 9f07400de..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-gssapi-cfx-07.txt
+++ /dev/null
@@ -1,985 +0,0 @@
-
-<Network Working Group>                                       Larry Zhu 
-Internet Draft                                       Karthik Jaganathan 
-Updates: 1964                                                 Microsoft 
-Category: Standards Track                                   Sam Hartman 
-draft-ietf-krb-wg-gssapi-cfx-07.txt                                 MIT 
-                                                          March 9, 2004 
-                                             Expires: September 9, 2004 
- 
-          The Kerberos Version 5 GSS-API Mechanism: Version 2 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of [RFC-2026].  
-    
-   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."  
-    
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt.   
-    
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-   To learn the current status of any Internet-Draft, please check the 
-   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 
-   Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 
-   ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 
- 
-   The distribution of this memo is unlimited.  It is filed as  
-   draft-ietf-krb-wg-gssapi-cfx-07.txt, and expires on September 9 
-   2004.  Please send comments to: ietf-krb-wg@anl.gov. 
-    
-Abstract 
-    
-   This document defines protocols, procedures, and conventions to be 
-   employed by peers implementing the Generic Security Service 
-   Application Program Interface (GSS-API) when using the Kerberos 
-   Version 5 mechanism. 
-    
-   RFC-1964 is updated and incremental changes are proposed in response 
-   to recent developments such as the introduction of Kerberos 
-   cryptosystem framework.  These changes support the inclusion of new 
-   cryptosystems, by defining new per-message tokens along with their 
-   encryption and checksum algorithms based on the cryptosystem 
-   profiles.   
-    
-Conventions used in this document 
-  
-Zhu                                                                   1 
-DRAFT             Kerberos Version 5 GSS-API     Expires September 2004 
- 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
-   document are to be interpreted as described in [RFC-2119]. 
-    
-   The term "little endian order" is used for brevity to refer to the 
-   least-significant-octet-first encoding, while the term "big endian 
-   order" is for the most-significant-octet-first encoding. 
-    
-Table of Contents 
-
-   1. Introduction ...............................................  2 
-   2. Key Derivation for Per-Message Tokens ......................  3 
-   3. Quality of Protection ......................................  4 
-   4. Definitions and Token Formats ..............................  4 
-   4.1. Context Establishment Tokens .............................  4 
-   4.1.1. Authenticator Checksum .................................  5 
-   4.2. Per-Message Tokens .......................................  8 
-   4.2.1. Sequence Number ........................................  8 
-   4.2.2. Flags Field ............................................  8 
-   4.2.3. EC Field ...............................................  9 
-   4.2.4. Encryption and Checksum Operations .....................  9 
-   4.2.5. RRC Field .............................................. 10 
-   4.2.6. Message Layouts ........................................ 10 
-   4.3. Context Deletion Tokens .................................. 11 
-   4.4. Token Identifier Assignment Considerations ............... 11 
-   5. Parameter Definitions ...................................... 12 
-   5.1. Minor Status Codes ....................................... 12 
-   5.1.1. Non-Kerberos-specific codes ............................ 12 
-   5.1.2. Kerberos-specific-codes ................................ 12 
-   5.2. Buffer Sizes ............................................. 13 
-   6. Backwards Compatibility Considerations ..................... 13 
-   7. Security Considerations .................................... 13 
-   8. Acknowledgments ............................................ 14 
-   9. Intellectual Property Statement ............................ 15
-   10. References ................................................ 15 
-   10.1. Normative References .................................... 15 
-   10.2. Informative References .................................. 15 
-   11. Author's Address .......................................... 15
-   Full Copyright Statement ...................................... 17  
-   
-1. Introduction 
-    
-   [KCRYPTO] defines a generic framework for describing encryption and 
-   checksum types to be used with the Kerberos protocol and associated 
-   protocols. 
-    
-   [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.  
-   It defines the format of context establishment, per-message and 
-   context deletion tokens and uses algorithm identifiers for each 
-   cryptosystem in per message and context deletion tokens.   
-    
-   The approach taken in this document obviates the need for algorithm 
-   identifiers.  This is accomplished by using the same encryption 
-   algorithm, specified by the crypto profile [KCRYPTO] for the session 
-   key or subkey that is created during context negotiation, and its 
-   required checksum algorithm.  Message layouts of the per-message 
-Zhu                                                                  2 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-   tokens are therefore revised to remove algorithm indicators and also 
-   to add extra information to support the generic crypto framework 
-   [KCRYPTO].  
-    
-   Tokens transferred between GSS-API peers for security context 
-   establishment are also described in this document.  The data 
-   elements exchanged between a GSS-API endpoint implementation and the 
-   Kerberos Key Distribution Center (KDC) [KRBCLAR] are not specific to 
-   GSS-API usage and are therefore defined within [KRBCLAR] rather than 
-   within this specification. 
-    
-   The new token formats specified in this document MUST be used with 
-   all "newer" encryption types [KRBCLAR] and MAY be used with "older" 
-   encryption types, provided that the initiator and acceptor know, 
-   from the context establishment, that they can both process these new 
-   token formats. 
-    
-   "Newer" encryption types are those which have been specified along 
-   with or since the new Kerberos cryptosystem specification [KCRYPTO], 
-   as defined in section 3.1.3 of [KRBCLAR].  The list of not-newer 
-   encryption types is as follows [KCRYPTO]: 
-    
-             Encryption Type             Assigned Number     
-           ---------------------------------------------- 
-            des-cbc-crc                        1              
-            des-cbc-md4                        2              
-            des-cbc-md5                        3              
-            des3-cbc-md5                       5 
-            des3-cbc-sha1                      7 
-            dsaWithSHA1-CmsOID                 9            
-            md5WithRSAEncryption-CmsOID       10            
-            sha1WithRSAEncryption-CmsOID      11           
-            rc2CBC-EnvOID                     12            
-            rsaEncryption-EnvOID              13    
-            rsaES-OAEP-ENV-OID                14    
-            des-ede3-cbc-Env-OID              15            
-            des3-cbc-sha1-kd                  16                       
-            rc4-hmac                          23          
-    
-2. Key Derivation for Per-Message Tokens 
-    
-   To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 
-   "entropy-preserving" derived keys, for different purposes or key 
-   usages, from a base key or protocol key.   
-    
-   This document defines four key usage values below that are used to 
-   derive a specific key for signing and sealing messages, from the 
-   session key or subkey [KRBCLAR] created during the context 
-   establishment. 
-    
-        Name                         Value 
-      ------------------------------------- 
-       KG-USAGE-ACCEPTOR-SEAL         22 
-       KG-USAGE-ACCEPTOR-SIGN         23 
-       KG-USAGE-INITIATOR-SEAL        24 
-
-Zhu                                                                  3 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-       KG-USAGE-INITIATOR-SIGN        25 
-          
-   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 
-   used as the usage number in the key derivation function for deriving 
-   keys to be used in MIC tokens (as defined in section 4.2.6.1), and 
-   KG-USAGE-ACCEPTOR-SEAL is used for Wrap tokens(as defined in section 
-   4.2.6.2); similarly when the sender is the context initiator, KG-
-   USAGE-INITIATOR-SIGN is used as the usage number in the key 
-   derivation function for MIC tokens, KG-USAGE-INITIATOR-SEAL is used 
-   for Wrap Tokens.  Even if the Wrap token does not provide for 
-   confidentiality the same usage values specified above are used. 
-    
-   During the context initiation and acceptance sequence, the acceptor 
-   MAY assert a subkey, and if so, subsequent messages MUST use this 
-   subkey as the protocol key and these messages MUST be flagged as 
-   "AcceptorSubkey" as described in section 4.2.2. 
- 
-3. Quality of Protection 
- 
-   The GSS-API specification [RFC-2743] provides for Quality of 
-   Protection (QOP) values that can be used by applications to request 
-   a certain type of encryption or signing.  A zero QOP value is used 
-   to indicate the "default" protection; applications which do not use 
-   the default QOP are not guaranteed to be portable across 
-   implementations or even inter-operate with different deployment 
-   configurations of the same implementation.  Using an algorithm that 
-   is different from the one for which the key is defined may not be 
-   appropriate.  Therefore, when the new method in this document is 
-   used, the QOP value is ignored. 
-    
-   The encryption and checksum algorithms in per-message tokens are now 
-   implicitly defined by the algorithms associated with the session key 
-   or subkey.  Algorithms identifiers as described in [RFC-1964] are 
-   therefore no longer needed and removed from the new token headers. 
- 
-4. Definitions and Token Formats 
-    
-   This section provides terms and definitions, as well as descriptions 
-   for tokens specific to the Kerberos Version 5 GSS-API mechanism. 
-                                    
-4.1. Context Establishment Tokens 
-    
-   All context establishment tokens emitted by the Kerberos Version 5 
-   GSS-API mechanism SHALL have the framing described in section 3.1 of 
-   [RFC-2743], as illustrated by the following pseudo-ASN.1 structures: 
-    
-         GSS-API DEFINITIONS ::= 
-    
-         BEGIN 
-    
-         MechType ::= OBJECT IDENTIFIER 
-         -- representing Kerberos V5 mechanism 
-    
-         GSSAPI-Token ::= 
-         -- option indication (delegation, etc.) indicated within 
-Zhu                                                                  4 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-         -- mechanism-specific token 
-         [APPLICATION 0] IMPLICIT SEQUENCE { 
-                 thisMech MechType, 
-                 innerToken ANY DEFINED BY thisMech 
-                    -- contents mechanism-specific 
-                    -- ASN.1 structure not required 
-                 } 
-    
-         END 
-    
-   Where the innerToken field starts with a two-octet token-identifier 
-   (TOK_ID) expressed in big endian order, followed by a Kerberos 
-   message.   
-    
-   Here are the TOK_ID values used in the context establishment tokens: 
-    
-         Token               TOK_ID Value in Hex  
-        ----------------------------------------- 
-         KRB_AP_REQ            01 00 
-         KRB_AP_REP            02 00 
-         KRB_ERROR             03 00 
-             
-   Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR 
-   are defined in [KRBCLAR].   
-    
-   If an unknown token identifier (TOK_ID) is received in the initial 
-   context establishment token, the receiver MUST return 
-   GSS_S_CONTINUE_NEEDED major status, and the returned output token 
-   MUST contain a KRB_ERROR message with the error code 
-   KRB_AP_ERR_MSG_TYPE [KRBCLAR]. 
-    
-4.1.1. Authenticator Checksum 
- 
-   The authenticator in the KRB_AP_REQ message MUST include the 
-   optional sequence number and the checksum field.  The checksum field 
-   is used to convey service flags, channel bindings, and optional 
-   delegation information.   
-    
-   The checksum type MUST be 0x8003. When delegation is used, a ticket-
-   granting ticket will be transferred in a KRB_CRED message.  This 
-   ticket SHOULD have its forwardable flag set.  The EncryptedData 
-   field of the KRB_CRED message [KRBCLAR] MUST be encrypted in the 
-   session key of the ticket used to authenticate the context. 
-    
-   The authenticator checksum field SHALL have the following format: 
-       
-      Octet        Name      Description 
-     ----------------------------------------------------------------- 
-      0..3         Lgth    Number of octets in Bnd field;  Represented  
-                           in little-endian order;  Currently contains   
-                           hex value 10 00 00 00 (16). 
-      4..19        Bnd     Channel binding information, as described in  
-                           section 4.1.1.2. 
-      20..23       Flags   Four-octet context-establishment flags in 
-                           little-endian order as described in section  
-Zhu                                                                  5 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-                           4.1.1.1.  
-      24..25       DlgOpt  The delegation option identifier (=1) in  
-                           little-endian order [optional].  This field  
-                           and the next two fields are present if and  
-                           only if GSS_C_DELEG_FLAG is set as described  
-                           in section 4.1.1.1.   
-      26..27       Dlgth   The length of the Deleg field in little- 
-                           endian order [optional]. 
-      28..(n-1)    Deleg   A KRB_CRED message (n = Dlgth + 28)  
-                           [optional].  
-      n..last      Exts    Extensions [optional]. 
-    
-   The length of the checksum field MUST be at least 24 octets when 
-   GSS_C_DELEG_FLAG is not set (as described in section 4.1.1.1), and 
-   at least 28 octets plus Dlgth octets when GSS_C_DELEG_FLAG is set.  
-   When GSS_C_DELEG_FLAG is set, the DlgOpt, Dlgth and Deleg fields 
-   of the checksum data MUST immediately follow the Flags field.  The 
-   optional trailing octets (namely the "Exts" field) facilitate 
-   future extensions to this mechanism.  When delegation is not used 
-   but the Exts field is present, the Exts field starts at octet 24 
-   (DlgOpt, Dlgth and Deleg are absent). 
-    
-   Initiators that do not support the extensions MUST NOT include more 
-   than 24 octets in the checksum field, when GSS_C_DELEG_FLAG is not 
-   set, or more than 28 octets plus the KRB_CRED in the Deleg field, 
-   when GSS_C_DELEG_FLAG is set.  Acceptors that do not understand the 
-   extensions MUST ignore any octets past the Deleg field of the 
-   checksum data, when GSS_C_DELEG_FLAG is set, or past the Flags field 
-   of the checksum data, when GSS_C_DELEG_FLAG is not set. 
- 
-4.1.1.1. Checksum Flags Field 
-    
-   The checksum "Flags" field is used to convey service options or 
-   extension negotiation information. 
-    
-   The following context establishment flags are defined in [RFC-2744].   
-    
-        Flag Name              Value     
-      --------------------------------- 
-       GSS_C_DELEG_FLAG           1        
-       GSS_C_MUTUAL_FLAG          2       
-       GSS_C_REPLAY_FLAG          4       
-       GSS_C_SEQUENCE_FLAG        8        
-       GSS_C_CONF_FLAG           16      
-       GSS_C_INTEG_FLAG          32     
-        
-   Context establishment flags are exposed to the calling application.  
-   If the calling application desires a particular service option then 
-   it requests that option via GSS_Init_sec_context() [RFC-2743].  If 
-   the corresponding return state values [RFC-2743] indicate that any 
-   of above optional context level services will be active on the 
-   context, the corresponding flag values in the table above MUST be 
-   set in the checksum Flags field. 
-    
-
-Zhu                                                                  6 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-   Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for 
-   use with legacy vendor-specific extensions to this mechanism. 
-    
-   All other flag values not specified herein are reserved for future 
-   use.  Future revisions of this mechanism may use these reserved 
-   flags and may rely on implementations of this version to not use 
-   such flags in order to properly negotiate mechanism versions.  
-   Undefined flag values MUST be cleared by the sender, and unknown 
-   flags MUST be ignored by the receiver.   
-    
-4.1.1.2. Channel Binding Information 
-    
-   These tags are intended to be used to identify the particular 
-   communications channel for which the GSS-API security context 
-   establishment tokens are intended, thus limiting the scope within 
-   which an intercepted context establishment token can be reused by an 
-   attacker (see [RFC-2743], section 1.1.6). 
-    
-   When using C language bindings, channel bindings are communicated 
-   to the GSS-API using the following structure [RFC-2744]: 
- 
-      typedef struct gss_channel_bindings_struct { 
-         OM_uint32       initiator_addrtype; 
-         gss_buffer_desc initiator_address; 
-         OM_uint32       acceptor_addrtype; 
-         gss_buffer_desc acceptor_address; 
-         gss_buffer_desc application_data; 
-      } *gss_channel_bindings_t; 
-    
-   The member fields and constants used for different address types 
-   are defined in [RFC-2744]. 
-    
-   The "Bnd" field contains the MD5 hash of channel bindings, taken 
-   over all non-null components of bindings, in order of declaration.  
-   Integer fields within channel bindings are represented in little-
-   endian order for the purposes of the MD5 calculation. 
-    
-   In computing the contents of the Bnd field, the following detailed 
-   points apply:  
-    
-   (1) For purposes of MD5 hash computation, each integer field and 
-   input length field SHALL be formatted into four octets, using 
-   little endian octet ordering.  
-    
-   (2) All input length fields within gss_buffer_desc elements of a 
-   gss_channel_bindings_struct even those which are zero-valued, SHALL 
-   be included in the hash calculation; the value elements of 
-   gss_buffer_desc elements SHALL be dereferenced, and the resulting 
-   data SHALL be included within the hash computation, only for the 
-   case of gss_buffer_desc elements having non-zero length specifiers.  
-    
-   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 
-   valid channel binding structure, the Bnd field SHALL be set to 16 
-   zero-valued octets.  
- 
-Zhu                                                                  7 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-   If the caller to GSS_Accept_sec_context [RFC-2743] passes in 
-   GSS_C_NO_CHANNEL_BINDINGS [RFC-2744] as the channel bindings then 
-   the acceptor MAY ignore any channel bindings supplied by the 
-   initiator, returning success even if the initiator did pass in 
-   channel bindings. 
-    
-   If the application supply, in the channel bindings, a buffer with a 
-   length field larger than 4294967295 (2^32 - 1), the implementation 
-   of this mechanism MAY chose to reject the channel bindings 
-   altogether, using major status GSS_S_BAD_BINDINGS [RFC-2743].  In 
-   any case, the size of channel binding data buffers that can be used 
-   (interoperable, without extensions) with this specification is 
-   limited to 4294967295 octets. 
-    
-4.2. Per-Message Tokens 
-    
-   Two classes of tokens are defined in this section:  "MIC" tokens, 
-   emitted by calls to GSS_GetMIC() and consumed by calls to 
-   GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and 
-   consumed by calls to GSS_Unwrap(). 
-    
-   The new per-message tokens introduced here do not include the 
-   generic GSS-API token framing used by the context establishment 
-   tokens.  These new tokens are designed to be used with newer crypto 
-   systems that can, for example, have variable-size checksums.   
-    
-4.2.1. Sequence Number 
- 
-   To distinguish intentionally-repeated messages from maliciously-
-   replayed ones, per-message tokens contain a sequence number field, 
-   which is a 64 bit integer expressed in big endian order.  After 
-   sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence 
-   numbers SHALL be incremented by one. 
- 
-4.2.2. Flags Field 
- 
-   The "Flags" field is a one-octet integer used to indicate a set of 
-   attributes for the protected message.  For example, one flag is 
-   allocated as the direction-indicator, thus preventing an adversary 
-   from sending back the same message in the reverse direction and 
-   having it accepted.   
-    
-   The meanings of bits in this field (the least significant bit is 
-   bit 0) are as follows: 
-    
-        Bit    Name             Description 
-       --------------------------------------------------------------- 
-        0   SentByAcceptor    When set, this flag indicates the sender  
-                              is the context acceptor.  When not set, 
-                              it indicates the sender is the context  
-                              initiator. 
-        1   Sealed            When set in Wrap tokens, this flag  
-                              indicates confidentiality is provided  
-                              for.  It SHALL NOT be set in MIC tokens. 
-        2   AcceptorSubkey    A subkey asserted by the context acceptor 
-Zhu                                                                  8 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-                              is used to protect the message. 
-    
-   The rest of available bits are reserved for future use and MUST be 
-   cleared.  The receiver MUST ignore unknown flags. 
-    
-4.2.3. EC Field 
- 
-   The "EC" (Extra Count) field is a two-octet integer field expressed 
-   in big endian order.   
-    
-   In Wrap tokens with confidentiality, the EC field SHALL be used to 
-   encode the number of octets in the filler, as described in section 
-   4.2.4. 
-    
-   In Wrap tokens without confidentiality, the EC field SHALL be used 
-   to encode the number of octets in the trailing checksum, as 
-   described in section 4.2.4.   
- 
-4.2.4. Encryption and Checksum Operations 
-    
-   The encryption algorithms defined by the crypto profiles provide for 
-   integrity protection [KCRYPTO].  Therefore no separate checksum is 
-   needed.  
-    
-   The result of decryption can be longer than the original plaintext 
-   [KCRYPTO] and the extra trailing octets are called "crypto-system 
-   residue" in this document.  However, given the size of any plaintext 
-   data, one can always find a (possibly larger) size so that, when 
-   padding the to-be-encrypted text to that size, there will be no 
-   crypto-system residue added [KCRYPTO].  
- 
-   In Wrap tokens that provide for confidentiality, the first 16 octets 
-   of the Wrap token (the "header", as defined in section 4.2.6), SHALL 
-   be appended to the plaintext data before encryption.  Filler octets 
-   MAY be inserted between the plaintext data and the "header", and the 
-   values and size of the filler octets are chosen by implementations, 
-   such that there SHALL be no crypto-system residue present after the 
-   decryption.  The resulting Wrap token is {"header" | 
-   encrypt(plaintext-data | filler | "header")}, where encrypt() is the 
-   encryption operation (which provides for integrity protection) 
-   defined in the crypto profile [KCRYPTO], and the RRC field (as 
-   defined in section 4.2.5) in the to-be-encrypted header contain the 
-   hex value 00 00.   
-           
-   In Wrap tokens that do not provide for confidentiality, the checksum 
-   SHALL be calculated first over the to-be-signed plaintext data, and 
-   then the first 16 octets of the Wrap token (the "header", as defined 
-   in section 4.2.6).  Both the EC field and the RRC field in the token 
-   header SHALL be filled with zeroes for the purpose of calculating 
-   the checksum.  The resulting Wrap token is {"header" | plaintext-
-   data | get_mic(plaintext-data | "header")},  where get_mic() is the 
-   checksum operation for the required checksum mechanism of the chosen 
-   encryption mechanism defined in the crypto profile [KCRYPTO].  
-    
-
-Zhu                                                                  9 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-   The parameters for the key and the cipher-state in the encrypt() and 
-   get_mic() operations have been omitted for brevity.   
-        
-   For MIC tokens, the checksum SHALL be calculated as follows: the 
-   checksum operation is calculated first over the to-be-signed 
-   plaintext data, and then the first 16 octets of the MIC token, where 
-   the checksum mechanism is the required checksum mechanism of the 
-   chosen encryption mechanism defined in the crypto profile [KCRYPTO]. 
-   
-   The resulting Wrap and MIC tokens bind the data to the token header, 
-   including the sequence number and the direction indicator.  
-   
-4.2.5. RRC Field 
- 
-   The "RRC" (Right Rotation Count) field in Wrap tokens is added to 
-   allow the data to be encrypted in-place by existing SSPI (Security 
-   Service Provider Interface) [SSPI] applications that do not provide 
-   an additional buffer for the trailer (the cipher text after the in-
-   place-encrypted data) in addition to the buffer for the header (the 
-   cipher text before the in-place-encrypted data).  The resulting Wrap 
-   token in the previous section, excluding the first 16 octets of the 
-   token header, is rotated to the right by "RRC" octets.  The net 
-   result is that "RRC" octets of trailing octets are moved toward the 
-   header.  Consider the following as an example of this rotation 
-   operation:  Assume that the RRC value is 3 and the token before the 
-   rotation is {"header" | aa | bb | cc | dd | ee | ff | gg | hh}, the 
-   token after rotation would be {"header" | ff | gg | hh | aa | bb | 
-   cc | dd | ee }, where {aa | bb | cc |...| hh} is used to indicate 
-   the octet sequence. 
-  
-   The RRC field is expressed as a two-octet integer in big endian 
-   order. 
-    
-   The rotation count value is chosen by the sender based on 
-   implementation details, and the receiver MUST be able to interpret 
-   all possible rotation count values, including rotation counts 
-   greater than the length of the token. 
- 
-4.2.6. Message Layouts 
-    
-   Per-message tokens start with a two-octet token identifier (TOK_ID) 
-   field, expressed in big endian order.  These tokens are defined 
-   separately in subsequent sub-sections. 
-    
-4.2.6.1. MIC Tokens 
-    
-   Use of the GSS_GetMIC() call yields a token (referred as the MIC 
-   token in this document), separate from the user  
-   data being protected, which can be used to verify the integrity of  
-   that data as received.  The token has the following format: 
-    
-      Octet no   Name        Description 
-      ----------------------------------------------------------------- 
-       0..1     TOK_ID     Identification field.  Tokens emitted by  
-                           GSS_GetMIC() contain the hex value 04 04  
-Zhu                                                                 10 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-                           expressed in big endian order in this field. 
-       2        Flags      Attributes field, as described in section  
-                           4.2.2. 
-       3..7     Filler     Contains five octets of hex value FF. 
-       8..15    SND_SEQ    Sequence number field in clear text,  
-                           expressed in big endian order.  
-       16..last SGN_CKSUM  Checksum of the "to-be-signed" data and  
-                           octet 0..15, as described in section 4.2.4. 
-    
-   The Filler field is included in the checksum calculation for 
-   simplicity.   
-    
-4.2.6.2. Wrap Tokens 
-    
-   Use of the GSS_Wrap() call yields a token (referred as the Wrap 
-   token in this document), which consists of a descriptive header, 
-   followed by a body portion that contains either the input user data 
-   in plaintext concatenated with the checksum, or the input user data 
-   encrypted.  The GSS_Wrap() token SHALL have the following format: 
-    
-      Octet no   Name        Description 
-      --------------------------------------------------------------- 
-       0..1     TOK_ID     Identification field.  Tokens emitted by  
-                           GSS_Wrap() contain the the hex value 05 04                 
-                           expressed in big endian order in this field. 
-       2        Flags      Attributes field, as described in section  
-                           4.2.2. 
-       3        Filler     Contains the hex value FF. 
-       4..5     EC         Contains the "extra count" field, in big  
-                           endian order as described in section 4.2.3. 
-       6..7     RRC        Contains the "right rotation count" in big  
-                           endian order, as described in section 4.2.5. 
-       8..15    SND_SEQ    Sequence number field in clear text, 
-                           expressed in big endian order. 
-       16..last Data       Encrypted data for Wrap tokens with  
-                           confidentiality, or plaintext data followed  
-                           by the checksum for Wrap tokens without  
-                           confidentiality, as described in section  
-                           4.2.4.         
-             
-4.3. Context Deletion Tokens 
- 
-   Context deletion tokens are empty in this mechanism.  Both peers to 
-   a security context invoke GSS_Delete_sec_context() [RFC-2743] 
-   independently, passing a null output_context_token buffer to 
-   indicate that no context_token is required.  Implementations of 
-   GSS_Delete_sec_context() should delete relevant locally-stored 
-   context information. 
-        
-4.4. Token Identifier Assignment Considerations 
-    
-   Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF 
-   inclusive are reserved and SHALL NOT be assigned.  Thus by examining 
-   the first two octets of a token, one can tell unambiguously if it is 
-   wrapped with the generic GSS-API token framing.   
-Zhu                                                                 11 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-    
-5. Parameter Definitions 
-    
-   This section defines parameter values used by the Kerberos V5 GSS-
-   API mechanism.  It defines interface elements in support of 
-   portability, and assumes use of C language bindings per [RFC-2744]. 
-    
-5.1. Minor Status Codes 
- 
-   This section recommends common symbolic names for minor_status 
-   values to be returned by the Kerberos V5 GSS-API mechanism.  Use of 
-   these definitions will enable independent implementers to enhance 
-   application portability across different implementations of the 
-   mechanism defined in this specification.  (In all cases, 
-   implementations of GSS_Display_status() will enable callers to 
-   convert minor_status indicators to text representations.)  Each 
-   implementation should make available, through include files or other 
-   means, a facility to translate these symbolic names into the 
-   concrete values which a particular GSS-API implementation uses to 
-   represent the minor_status values specified in this section.  
-    
-   It is recognized that this list may grow over time, and that the 
-   need for additional minor_status codes specific to particular 
-   implementations may arise.  It is recommended, however, that 
-   implementations should return a minor_status value as defined on a 
-   mechanism-wide basis within this section when that code is 
-   accurately representative of reportable status rather than using a 
-   separate, implementation-defined code.  
-    
-5.1.1. Non-Kerberos-specific codes 
- 
-      GSS_KRB5_S_G_BAD_SERVICE_NAME  
-              /* "No @ in SERVICE-NAME name string" */ 
-      GSS_KRB5_S_G_BAD_STRING_UID 
-              /* "STRING-UID-NAME contains nondigits" */ 
-      GSS_KRB5_S_G_NOUSER 
-              /* "UID does not resolve to username" */ 
-      GSS_KRB5_S_G_VALIDATE_FAILED 
-              /* "Validation error" */ 
-      GSS_KRB5_S_G_BUFFER_ALLOC 
-              /* "Couldn't allocate gss_buffer_t data" */ 
-      GSS_KRB5_S_G_BAD_MSG_CTX 
-              /* "Message context invalid" */ 
-      GSS_KRB5_S_G_WRONG_SIZE 
-              /* "Buffer is the wrong size" */ 
-      GSS_KRB5_S_G_BAD_USAGE 
-              /* "Credential usage type is unknown" */ 
-      GSS_KRB5_S_G_UNKNOWN_QOP 
-              /* "Unknown quality of protection specified" */ 
-    
-5.1.2. Kerberos-specific-codes 
-    
-      GSS_KRB5_S_KG_CCACHE_NOMATCH  
-              /* "Client principal in credentials does not match   
-                 specified name" */ 
-Zhu                                                                 12 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-      GSS_KRB5_S_KG_KEYTAB_NOMATCH 
-              /* "No key available for specified service principal" */ 
-      GSS_KRB5_S_KG_TGT_MISSING 
-              /* "No Kerberos ticket-granting ticket available" */ 
-      GSS_KRB5_S_KG_NO_SUBKEY 
-              /* "Authenticator has no subkey" */ 
-      GSS_KRB5_S_KG_CONTEXT_ESTABLISHED 
-              /* "Context is already fully established" */ 
-      GSS_KRB5_S_KG_BAD_SIGN_TYPE 
-              /* "Unknown signature type in token" */ 
-      GSS_KRB5_S_KG_BAD_LENGTH 
-              /* "Invalid field length in token" */ 
-      GSS_KRB5_S_KG_CTX_INCOMPLETE 
-              /* "Attempt to use incomplete security context" */ 
- 
-5.2. Buffer Sizes 
- 
-   All implementations of this specification MUST be capable of 
-   accepting buffers of at least 16K octets as input to GSS_GetMIC(), 
-   GSS_VerifyMIC(), and GSS_Wrap(), and MUST be capable of accepting 
-   the output_token generated by GSS_Wrap() for a 16K octet input 
-   buffer as input to GSS_Unwrap().  Implementations SHOULD support 64K 
-   octet input buffers, and MAY support even larger input buffer sizes. 
- 
-6. Backwards Compatibility Considerations 
- 
-   The new token formats defined in this document will only be 
-   recognized by new implementations.  To address this, implementations 
-   can always use the explicit sign or seal algorithm in [RFC-1964] 
-   when the key type corresponds to "older" enctypes.  An alternative 
-   approach might be to retry sending the message with the sign or seal 
-   algorithm explicitly defined as in [RFC-1964].  However this would 
-   require either the use of a mechanism such as [RFC-2478] to securely 
-   negotiate the method or the use out of band mechanism to choose 
-   appropriate mechanism.  For this reason, it is RECOMMENDED that the 
-   new token formats defined in this document SHOULD be used only if 
-   both peers are known to support the new mechanism during context 
-   negotiation because of, for example, the use of "new" enctypes. 
- 
-   GSS_Unwrap() or GSS_VerifyMIC() can process a message token as 
-   follows: it can look at the first octet of the token header, if it 
-   is 0x60 then the token must carry the generic GSS-API pseudo ASN.1 
-   framing, otherwise the first two octets of the token contain the 
-   TOK_ID that uniquely identify the token message format. 
-    
-7. Security Considerations 
-    
-   Channel bindings are validated by the acceptor.  The acceptor can 
-   ignore the channel bindings restriction supplied by the initiator 
-   and carried in the authenticator checksum, if channel bindings are 
-   not used by GSS_Accept_sec_context [RFC-2743], and the acceptor does 
-   not prove to the initiator that it has the same channel bindings as 
-   the initiator, even if the client requested mutual authentication.  
-   This limitation should be taken into consideration by designers of 
-   applications that would use channel bindings, whether to limit the 
-Zhu                                                                 13 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-   use of GSS-API contexts to nodes with specific network addresses, to 
-   authenticate other established, secure channels using Kerberos 
-   Version 5, or for any other purpose. 
-    
-   Session key types are selected by the KDC.  Under the current 
-   mechanism, no negotiation of algorithm types occurs, so server-side 
-   (acceptor) implementations cannot request that clients not use 
-   algorithm types not understood by the server.  However, 
-   administrators can control what enctypes can be used for session 
-   keys for this mechanism by controlling the set of the ticket session 
-   key enctypes which the KDC is willing to use in tickets for a given 
-   acceptor principal.  The KDC could therefore be given the task of 
-   limiting session keys for a given service to types actually 
-   supported by the Kerberos and GSSAPI software on the server.  This 
-   does have a drawback for cases where a service principal name is 
-   used both for GSSAPI-based and non-GSSAPI-based communication (most 
-   notably the "host" service key), if the GSSAPI implementation does 
-   not understand (for example) AES [AES-KRB5] but the Kerberos 
-   implementation does.  It means that AES session keys cannot be 
-   issued for that service principal, which keeps the protection of 
-   non-GSSAPI services weaker than necessary.  KDC administrators 
-   desiring to limit the session key types to support interoperability 
-   with such GSSAPI implementations should carefully weigh the 
-   reduction in protection offered by such mechanisms against the 
-   benefits of interoperability. 
-    
-8. Acknowledgments 
- 
-  Ken Raeburn and Nicolas Williams corrected many of our errors in the 
-  use of generic profiles and were instrumental in the creation of 
-  this document.  
-   
-  The text for security considerations was contributed by Nicolas 
-  Williams and Ken Raeburn. 
-   
-  Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, 
-  namely the encoding of the RRC field.   
-   
-  Sam Hartman and Nicolas Williams recommended the replacing our 
-  earlier key derivation function for directional keys with different 
-  key usage numbers for each direction as well as retaining the 
-  directional bit for maximum compatibility.   
-   
-  Paul Leach provided numerous suggestions and comments.  
-   
-  Scott Field, Richard Ward, Dan Simon, Kevin Damour, and Simon 
-  Josefsson also provided valuable inputs on this document. 
-   
-  Jeffrey Hutzelman provided comments and clarifications for the text 
-  related to the channel bindings.  
-   
-  Jeffrey Hutzelman and Russ Housley suggested many editorial changes. 
- 
-
-
-Zhu                                                                 14 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-  Luke Howard provided implementations of this document for the 
-  Heimdal code base, and helped inter-operability testing with the 
-  Microsoft code base, together with Love Hornquist Astrand.  These 
-  experiments formed the basis of this document. 
-   
-  Martin Rex provided suggestions of TOK_ID assignment recommendations 
-  thus the token tagging in this document is unambiguous if the token 
-  is wrapped with the pseudo ASN.1 header.  
-   
-  John Linn wrote the original Kerberos Version 5 mechanism 
-  specification [RFC-1964], of which some of the text has been retained
-  in this document. 
-   
-9. Intellectual Property Statement 
- 
-   The IETF takes no position regarding the validity or scope of any 
-   intellectual property or other rights that might be claimed to 
-   pertain to the implementation or use of the technology described in 
-   this document or the extent to which any license under such rights 
-   might or might not be available; neither does it represent that it 
-   has made any effort to identify any such rights.  Information on the 
-   IETF's procedures with respect to rights in standards-track and 
-   standards-related documentation can be found in BCP-11.  Copies of 
-   claims of rights made available for publication and any assurances 
-   of licenses to be made available, or the result of an attempt made 
-   to obtain a general license or permission for the use of such 
-   proprietary rights by implementers or users of this specification 
-   can be obtained from the IETF Secretariat. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights which may cover technology that may be required to practice 
-   this standard.  Please address the information to the IETF Executive 
-   Director. 
-   
-10. References 
-    
-10.1. Normative References 
-    
-   [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 
-   3", BCP 9, RFC 2026, October 1996.  
-        
-   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 
-   Requirement Levels", BCP 14, RFC 2119, March 1997. 
-    
-   [RFC-2743] Linn, J., "Generic Security Service Application Program    
-   Interface Version 2, Update 1", RFC 2743, January 2000. 
-    
-   [RFC-2744] Wray, J., "Generic Security Service API Version 2: C-
-   bindings", RFC 2744, January 2000. 
-    
-   [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",    
-   RFC 1964, June 1996. 
-    
-Zhu                                                                 15 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-   [KCRYPTO] RFC-Editor: To be replaced by RFC number for draft-ietf-
-   krb-wg-crypto.  Work in Progress. 
-    
-   [KRBCLAR] RFC-Editor: To be replaced by RFC number for draft-ietf-
-   krb-wg-kerberos-clarifications.  Work in Progress. 
- 
-10.2. Informative References 
- 
-   [SSPI] Leach, P., "Security Service Provider Interface", Microsoft 
-   Developer Network (MSDN), April 2003. 
-    
-   [AES-KRB5] RFC-Editor: To be replaced by RFC number for draft-
-   raeburn-krb-rijndael-krb.  Work in Progress. 
-    
-   [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
-   Negotiation Mechanism", RFC 2478, December 1998. 
-    
-11. Author's Address 
-    
-   Larry Zhu 
-   One Microsoft Way 
-   Redmond, WA 98052 - USA 
-   EMail: LZhu@microsoft.com 
- 
-   Karthik Jaganathan 
-   One Microsoft Way 
-   Redmond, WA 98052 - USA 
-   EMail: karthikj@microsoft.com 
- 
-   Sam Hartman 
-   Massachusetts Institute of Technology 
-   77 Massachusetts Avenue 
-   Cambridge, MA 02139 - USA 
-   Email: hartmans@MIT.EDU 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                                                                 16 
-DRAFT            Kerberos Version 5 GSS-API     Expires September 2004 
- 
-    
-Full Copyright Statement 
-    
-   Copyright (C) The Internet Society (date). All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this 
-   document itself may not be modified in any way, such as by removing 
-   the copyright notice or references to the Internet Society or other 
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                                                                 17 
diff --git a/doc/standardisation/draft-ietf-krb-wg-hw-auth-03.txt b/doc/standardisation/draft-ietf-krb-wg-hw-auth-03.txt
deleted file mode 100644
index 54a8db941..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-hw-auth-03.txt
+++ /dev/null
@@ -1,329 +0,0 @@
-
-Kerberos Working Group                                     Matt Crawford
-Internet Draft                                                  Fermilab
-                                                       10 September 2003
-
-              Passwordless Initial Authentication to Kerberos
-                       by Hardware Preauthentication
-                     <draft-ietf-krb-wg-hw-auth-03.txt>
-
-
-
-Status of this Memo
-
-    This document is an Internet-Draft and is in full conformance with
-    all provisions of Section 10 of RFC2026.  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 list Internet-Draft Shadow Directories, see
-    http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-    This document specifies an extension to the Kerberos protocol for
-    performing initial authentication of a user without using that
-    user's long-lived password.  Any "hardware preauthentication" method
-    may be employed instead of the password, and the key of another
-    principal must be nominated to encrypt the returned credential.
-
-    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-    document are to be interpreted as described in [KWORD].
-
-
-1.  Motivation
-
-    Many sites using Kerberos for authentication have users who are
-    often, or even always, away from the site.  Sometimes these users
-
-
-
-Expires March 15, 2004          Crawford                        [Page 1]
-
-Internet Draft    Passwordless Hardware Authentication 10 September 2003
-
-
-    may need to connect to their site while they have no immediate
-    access to a computer with Kerberos software or any other trusted
-    secure remote-access mechanism.  Requiring hardware
-    preauthentication in addition to a password for all such users is an
-    incomplete solution because an eavesdropper with access to both the
-    remote users' path to the host in the site and that host's path to
-    the KDC can still steal the user's credential.
-
-    This document specifies a method by which a Kerberos application
-    server can request that a KDC authenticate a user using a hardware
-    preauthentication method and use a key held by the server in the
-    decryption of the KDC's reply, in place of the user's password.
-
-
-2.  Definitions
-
-    The following terms used here are defined in [KRB5] and [KRB5bis]:
-
-        KDC_ERR_PREAUTH_FAILED, KDC_ERR_PREAUTH_REQUIRED, KRB_AS_REQ,
-        KRB_ERROR, PrincipalName, e-data, enc-part, error-code, kdc-
-        options, padata-type, padata-value.
-
-    These terms are defined in [KRB5bis]:
-
-        PA-SAM-CHALLENGE, PA-SAM-RESPONSE.
-
-    The term "service" denotes some Kerberos service which normally
-    requires a client/server authentication exchange [KRB5] for access
-    and which is capable of both communicating with the KDC's
-    Authentication Service and interacting with the user to the extent
-    required to carry out a single-use authentication mechanism (SAM).
-    It must have access to some principal's long-lived key.  Telnet and
-    FTP services are examples.
-
-    The Kerberos Authentication Service will be denoted by "AS" to avoid
-    confusion with the service.
-
-
-3.  Method
-
-    This mechanism is intended to be employed when a user connects to a
-    service which normally allows only Kerberos-authenticated access.
-    When the service determines that the user will not authenticate (for
-    example, it receives a telnet "WONT AUTHENTICATION" command
-    [TELAUTH], or an FTP "USER" command without a preceding "AUTH"
-    command [FTPSEC]), it may accept a user principal name and attempt
-    to perform passwordless hardware authentication in the following
-    manner.
-
-
-
-Expires March 15, 2004          Crawford                        [Page 2]
-
-Internet Draft    Passwordless Hardware Authentication 10 September 2003
-
-
-3.1.  Initial AS Request and reply
-
-    The service, on behalf of the user, prepares a KRB_AS_REQ [KRB5]
-    message with the flag OPT-HARDWARE-AUTH set in the kdc-options
-    field, in addition to any other desired options and lifetimes.  The
-    service sends this message to a KDC.  If the KDC's policy permits
-    this form of authentication for the user named in the request, and
-    the request is acceptable in all other respects, the KDC determines
-    what hardware preauthentication methods are available for the user
-    principal and constructs a KRB_ERROR message with the error-code set
-    to KDC_ERR_PREAUTH_REQUIRED.  The e-data field of this KRB_ERROR
-    message contains a sequence of PA-DATA which includes an element
-    with padata-type equal to PA-ALT-PRINC and an empty padata-value.
-    In addition to that are any elements needed for hardware
-    preauthentication of the user.  Typically this will consist of an
-    element with padata-type PA-SAM-CHALLENGE and padata-value
-    appropriate to the authentication method.
-
-
-3.2.  Second AS Request
-
-    The service, upon receiving the KRB_ERROR message from the KDC, must
-    process the PA-ALT-PRINC element by selecting a principal whose
-    long-lived key it has access to, and which is in the same realm as
-    the client.  This principal will be referred to as the alternate
-    principal.  It processes the PA-SAM-CHALLENGE normally, except that
-    whenever the user's long-lived (password-derived) encryption key is
-    called for, it uses the alternate principal's key instead.
-
-    The service constructs a second KRB_AS_REQ, again with the OPT-
-    HARDWARE-AUTH flag set in the kdc-options field, and this time with
-    a padata field which includes at least these two PA-DATA items, in
-    this order:
-
-        One with padata-type equal to PA-ALT-PRINC and as padata-value
-        the encoded PrincipalName of the alternate principal,
-
-        One with padata-type equal to PA-SAM-RESPONSE and padata-value
-        constructed as it would be for normal hardware
-        preauthentication, but with the alternate principal's key used
-        in place of the user's key.
-
-    Other PA-DATA may be present before, between or after these items.
-
-    The service sends this second KRB_AS_REQ to a KDC.
-
-
-
-
-
-
-Expires March 15, 2004          Crawford                        [Page 3]
-
-Internet Draft    Passwordless Hardware Authentication 10 September 2003
-
-
-3.3.  Final AS Reply
-
-    The KDC begins processing the AS request normally.  When the PA-ALT-
-    PRINC field is encountered, the KDC does the following:
-
-        First, if this use of the alternate principal named in the
-        request is against local policy, or if the alternate principal
-        does not exist in the database, a KRB_ERROR message with error-
-        code KDC_ERR_PREAUTH_FAILED is returned and processing ends.
-
-        Then, the alternate principal's key is fetched from the database
-        and held for use in subsequent processing.  It will be needed to
-        process the PA-SAM-RESPONSE and to encrypt the enc-part of the
-        KRB_AS_REP if authentication is successful.
-
-    The remainder of the AS request processing is normal, with the noted
-    substitution of the alternate principal's key for the user's.
-
-    The service, upon receiving a KRB_AS_REP, uses the alternate
-    principal's key to decrypt the enc-part, saves the user's credential
-    and takes appropriate measures to ensure that the KRB_AS_REP came
-    from a legitimate KDC and not an imposter.
-
-
-4.  IANA Considerations
-
-    As of this writing, management of Kerberos protocol parameters has
-    not been delegated to IANA.  No new naming or numbering spaces are
-    created by this specification.  Two new values from existing spaces
-    are defined:
-
-        The flag OPT-HARDWARE-AUTH is a previously unused bit in the
-        kdc-options field of a KDC-REQ-BODY [KRB5].  The assignment of
-        bit 11 is expected [BCN].
-
-        The preauthentication type PA-ALT-PRINC is denoted by padata-
-        type 24 [KRB5bis].
-
-
-5.  Security Considerations
-
-    There are no means provided here for protecting the traffic between
-    the user and the service, so it may be susceptible to eavesdropping,
-    hijacking and alteration.  This authentication mechanism is not
-    intended to be used as an alternative to the Kerberos client/server
-    authentication exchange, but as an improvement over making an
-    unprotected connection with a Kerberos password alone, or a password
-    plus a single-use authenticator.
-
-
-
-Expires March 15, 2004          Crawford                        [Page 4]
-
-Internet Draft    Passwordless Hardware Authentication 10 September 2003
-
-
-    The alternate principal's key MUST be involved in construction of
-    the PA-SAM-RESPONSE padata-value, to prevent an adversary
-    constructing a KRB_AS_REQ using that data but a different alternate
-    principal.  In practice, this means that the response data alone
-    must not determine the encryption key for the padata-value.
-
-    A service impersonator can obtain a presumably-valid SAM response
-    from the user which may (or may not) be usable for impersonating the
-    user at a later time.  And of course in the case of successful
-    authentication the service obtains access to the user's credentials.
-    As always, if the service host is compromised, so are the
-    credentials; but at least the service host never has access to the
-    user's password.
-
-    A service host which accepts a Kerberos password for access
-    typically protects itself against an impostor KDC by using the
-    received ticket-granting credential to get a ticket for a service
-    for which it has the key.  This step may be unnecessary when the
-    service host has already successfully used such a key to decrypt the
-    ticket-granting credential itself.
-
-    Use of this authentication method employs the service's long-term
-    key, providing more ciphertext in that key to an eavesdropper.  This
-    key is generally of better quality than a password-derived key and
-    any remaining concerns about the strength of the KRB_AS_REP are
-    better addressed by a general mechanism applicable to all AS
-    exchanges.
-
-
-6.  Acknowledgments
-
-    The first implementation of this extension grew from a beginning by
-    Ken Hornstein, which in turn was built on code released by the MIT
-    Kerberos Team.
-
-
-7.  References
-
-    [BCN]     Newman, C., private communication.
-
-    [FTPSEC]  Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
-              2228.
-
-    [KRB5]    Kohl, J., and C. Neuman, "The Kerberos Network
-              Authentication Service (V5)", RFC 1510.
-
-    [KRB5bis] Neuman, C., T. Yu, S. Hartman, and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", Work in
-
-
-
-Expires March 15, 2004          Crawford                        [Page 5]
-
-Internet Draft    Passwordless Hardware Authentication 10 September 2003
-
-
-              progress.  (Currently draft-ietf-krb-wg-kerberos-
-              clarifications-04.txt.)
-
-    [KWORD] S. Bradner, "Key words for use in RFCs to Indicate
-        Requirement Levels," RFC 2119, March 1997.
-
-    [TELAUTH] Ts'o, T. and J. Altman, "Telnet Authentication Option",
-              RFC 2941.
-
-8.  Author's Address
-
-    Matt Crawford
-    Fermilab MS 369
-    PO Box 500
-    Batavia, IL 60510
-    USA
-
-    Phone: +1 630 840-3461
-    EMail: crawdad@fnal.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires March 15, 2004          Crawford                        [Page 6]
diff --git a/doc/standardisation/draft-ietf-krb-wg-hw-auth-04.txt b/doc/standardisation/draft-ietf-krb-wg-hw-auth-04.txt
deleted file mode 100644
index c6c37b3d3..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-hw-auth-04.txt
+++ /dev/null
@@ -1,394 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-Kerberos Working Group                                     Matt Crawford
-Internet Draft                                                  Fermilab
-                                                         21 October 2006
-
-              Passwordless Initial Authentication to Kerberos
-                       by Hardware Preauthentication
-                     <draft-ietf-krb-wg-hw-auth-04.txt>
-
-
-
-Status of this Memo
-
-    By submitting this Internet-Draft, each author represents that any
-    applicable patent or other IPR claims of which he or she is aware
-    have been or will be disclosed, and any of which he or she becomes
-    aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-    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."
-
-    The list of current Internet-Drafts can be accessed at
-    http://www.ietf.org/1id-abstracts.html.
-
-    To view the list Internet-Draft Shadow Directories, see
-    http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-    This document specifies an extension to the Kerberos protocol for
-    performing initial authentication of a user without using that
-    user's long-lived password.  Any "hardware preauthentication" method
-    may be employed instead of the password, and the key of another
-    principal must be nominated to encrypt the returned credential.
-
-    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-
-
-
-Expires April 26, 2007          Crawford                        [Page 1]
-
-Internet Draft    Passwordless Hardware Authentication   21 October 2006
-
-
-    document are to be interpreted as described in [KWORD].
-
-
-1.  Motivation
-
-    Many sites using Kerberos for authentication have users who are
-    often, or even always, away from the site.  Sometimes these users
-    may need to connect to their site while they have no immediate
-    access to a trustworthy computer with Kerberos software or any other
-    trusted secure remote-access mechanism.  Requiring hardware
-    preauthentication in addition to a password for all such users is an
-    incomplete solution because an eavesdropper with access to both the
-    remote users' path to the host in the site and that host's path to
-    the KDC can still steal the user's credential.
-
-    This document specifies a method by which a Kerberos application
-    server can request that a KDC authenticate a user using a hardware
-    preauthentication method and use a key held by the server in the
-    decryption of the KDC's reply, in place of the user's password.
-
-
-2.  Definitions
-
-    The following terms used here are defined in [KRB5] and [KRB5bis]:
-
-        KDC_ERR_PREAUTH_FAILED, KDC_ERR_PREAUTH_REQUIRED, KRB_AS_REQ,
-        KRB_ERROR, PrincipalName, e-data, enc-part, error-code, kdc-
-        options, padata-type, padata-value.
-
-    These terms are defined in [KRB5bis]:
-
-        PA-SAM-CHALLENGE, PA-SAM-CHALLENGE2, PA-SAM-RESPONSE, PA-SAM-
-        RESPONSE2.
-
-    The term "service" denotes some Kerberos service which normally
-    requires a client/server authentication exchange [KRB5] for access
-    and which is capable of both communicating with the KDC's
-    Authentication Service and interacting with the user to the extent
-    required to carry out a single-use authentication mechanism (SAM).
-    It must have access to some principal's long-lived key.  Telnet and
-    FTP services are examples.
-
-    The Kerberos Authentication Service will be denoted by "AS" to avoid
-    confusion with the service.
-
-
-
-
-
-
-
-Expires April 26, 2007          Crawford                        [Page 2]
-
-Internet Draft    Passwordless Hardware Authentication   21 October 2006
-
-
-3.  Method
-
-    This mechanism is intended to be employed when a user connects to a
-    service which normally allows only Kerberos-authenticated access.
-    When the service determines that the user will not authenticate (for
-    example, it receives a telnet "WONT AUTHENTICATION" command
-    [TELAUTH], or an FTP "USER" command without a preceding "AUTH"
-    command [FTPSEC]), it may accept a user principal name and attempt
-    to perform passwordless hardware authentication in the following
-    manner.
-
-
-3.1.  Initial AS Request and reply
-
-    The service, on behalf of the user, prepares a KRB_AS_REQ [KRB5]
-    message with the flag OPT-HARDWARE-AUTH set in the kdc-options
-    field, in addition to any other desired options and lifetimes.  The
-    service sends this message to a KDC.  If the KDC's policy permits
-    this form of authentication for the user named in the request, and
-    the request is acceptable in all other respects, the KDC determines
-    what hardware preauthentication methods are available for the user
-    principal and constructs a KRB_ERROR message with the error-code set
-    to KDC_ERR_PREAUTH_REQUIRED.  The e-data field of this KRB_ERROR
-    message contains a sequence of PA-DATA which includes an element
-    with padata-type equal to PA-ALT-PRINC and an empty padata-value.
-    In addition to that are any elements needed for hardware
-    preauthentication of the user.  Typically this will include an
-    element with padata-type PA-SAM-CHALLENGE or PA-SAM-CHALLENGE2 and
-    padata-value appropriate to the authentication method.
-
-
-3.2.  Second AS Request
-
-    The service, upon receiving the KRB_ERROR message from the KDC, must
-    process the PA-ALT-PRINC element by selecting a principal whose
-    long-lived key it has access to, and which is in the same realm as
-    the client.  This principal will be referred to as the alternate
-    principal.  It processes the PA-SAM-CHALLENGE normally, except that
-    whenever the user's long-lived (password-derived) encryption key is
-    called for, it uses the alternate principal's key instead.
-
-    The service constructs a second KRB_AS_REQ, again with the OPT-
-    HARDWARE-AUTH flag set in the kdc-options field, and this time with
-    a padata field which includes at least these two PA-DATA items, in
-    this order:
-
-        One with padata-type equal to PA-ALT-PRINC and as padata-value
-        the encoded PrincipalName of the alternate principal,
-
-
-
-Expires April 26, 2007          Crawford                        [Page 3]
-
-Internet Draft    Passwordless Hardware Authentication   21 October 2006
-
-
-        One with padata-type appropriate for hardware token-based
-        preauthentication, such as PA-SAM-RESPONSE or PA-SAM-RESPONSE2,
-        and padata-value constructed as it would be for normal hardware
-        preauthentication, but with the alternate principal's key used
-        in place of the user's key.
-
-    Other PA-DATA may be present before, between or after these items.
-
-    The service sends this second KRB_AS_REQ to a KDC.
-
-
-3.3.  Final AS Reply
-
-    The KDC begins processing the AS request normally.  When the PA-ALT-
-    PRINC field is encountered, the KDC does the following:
-
-        First, if this use of the alternate principal named in the
-        request is against local policy, or if the alternate principal
-        does not exist in the database, a KRB_ERROR message with error-
-        code KDC_ERR_PREAUTH_FAILED is returned and processing ends.
-
-        Then, the alternate principal's key is fetched from the database
-        and held for use in subsequent processing.  It will be needed to
-        process the PA-SAM-RESPONSE, PA-SAM-RESPONSE2, or similar
-        preauthentication data, and to encrypt the enc-part of the
-        KRB_AS_REP if authentication is successful.
-
-    The remainder of the AS request processing is normal, with the noted
-    substitution of the alternate principal's key for the user's.
-
-    The service, upon receiving a KRB_AS_REP, uses the alternate
-    principal's key to decrypt the enc-part, saves the user's credential
-    and takes appropriate measures to ensure that the KRB_AS_REP came
-    from a legitimate KDC and not an imposter.
-
-
-4.  IANA Considerations
-
-    No new naming or numbering spaces are created by this specification.
-    Two values from existing spaces are defined in [KRB5bis] for the
-    mechanism of this document:
-
-        The flag OPT-HARDWARE-AUTH is bit 11 in the kdc-options field of
-        a KDC-REQ-BODY.
-
-        The preauthentication type PA-ALT-PRINC is denoted by padata-
-        type 24.
-
-
-
-
-Expires April 26, 2007          Crawford                        [Page 4]
-
-Internet Draft    Passwordless Hardware Authentication   21 October 2006
-
-
-5.  Security Considerations
-
-    There are no means provided here for protecting the traffic between
-    the user and the service, so it may be susceptible to eavesdropping,
-    hijacking and alteration.  This authentication mechanism is not
-    intended to be used as an alternative to the Kerberos client/server
-    authentication exchange, but as an improvement over making an
-    unprotected connection with a Kerberos password alone, or a password
-    plus a single-use authenticator.
-
-    The alternate principal's key MUST be involved in construction of
-    the PA-SAM-RESPONSE (or PA-SAM-RESPONSE2) padata-value, to prevent
-    an adversary constructing a KRB_AS_REQ using that data but a
-    different alternate principal.  In practice, this means that the
-    response data alone must not determine the encryption key for the
-    padata-value.
-
-    A service impersonator can obtain a presumably-valid SAM response
-    from the user which may (or may not) be usable for impersonating the
-    user at a later time.  And of course in the case of successful
-    authentication the service obtains access to the user's credentials.
-    As always, if the service host is compromised, so are the
-    credentials; but, with this mechanism, at least the service host
-    never has access to the user's password.
-
-    A service host which accepts a Kerberos password for access
-    typically protects itself against an impostor KDC by using the
-    received ticket-granting credential to get a ticket for a service
-    for which it has the key.  This step may be unnecessary when the
-    service host has already successfully used such a key to decrypt the
-    ticket-granting credential itself.
-
-    Use of this authentication method employs the service's long-term
-    key, providing more ciphertext in that key to an eavesdropper.  This
-    key is generally of better quality than a password-derived key and
-    any remaining concerns about the strength of the KRB_AS_REP are
-    better addressed by a general mechanism applicable to all AS
-    exchanges.
-
-
-6.  Acknowledgments
-
-    The first implementation of this extension grew from a beginning by
-    Ken Hornstein, which in turn was built on code released by the MIT
-    Kerberos Team.
-
-
-
-
-
-
-Expires April 26, 2007          Crawford                        [Page 5]
-
-Internet Draft    Passwordless Hardware Authentication   21 October 2006
-
-
-7.  References
-
-    [FTPSEC]  Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
-              2228.
-
-    [KRB5]    Kohl, J., and C. Neuman, "The Kerberos Network
-              Authentication Service (V5)", RFC 1510.
-
-    [KRB5bis] Neuman, C., T. Yu, S. Hartman, and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120.
-
-    [KWORD] S. Bradner, "Key words for use in RFCs to Indicate
-        Requirement Levels," RFC 2119, March 1997.
-
-    [TELAUTH] Ts'o, T. and J. Altman, "Telnet Authentication Option",
-              RFC 2941.
-
-8.  Author's Address
-
-    Matt Crawford
-    Fermilab MS 368
-    PO Box 500
-    Batavia, IL 60510
-    USA
-
-    Phone: +1 630 840-3461
-    EMail: crawdad@fnal.gov
-
-Disclaimer of Validity
-
-    This document and the information contained herein are provided on
-    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
-    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
-    INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
-    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-    Copyright (C) The Internet Trust (2006).  This document is subject
-    to the rights, licenses and restrictions contained in BCP 78, and
-    except as set forth therein, the authors retain all their rights.
-
-
-    Acknowledgment
-
-
-
-
-Expires April 26, 2007          Crawford                        [Page 6]
-
-Internet Draft    Passwordless Hardware Authentication   21 October 2006
-
-
-    Funding for the RFC Editor function is currently provided by the
-    Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires April 26, 2007          Crawford                        [Page 7]
diff --git a/doc/standardisation/draft-ietf-krb-wg-kdc-model-03.txt b/doc/standardisation/draft-ietf-krb-wg-kdc-model-03.txt
deleted file mode 100644
index 39c123a68..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kdc-model-03.txt
+++ /dev/null
@@ -1,1064 +0,0 @@
-
-
-
-KERBEROS WORKING GROUP                                         Johansson
-Internet-Draft                                      Stockholm university
-Intended status: Standards Track                        November 3, 2008
-Expires: May 7, 2009
-
-
-              An information model for Kerberos version 5
-                     draft-ietf-krb-wg-kdc-model-03
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on May 7, 2009.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                  [Page 1]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-Abstract
-
-   This document describes an information model for Kerberos version 5
-   from the point of view of an administrative service.  There is no
-   standard for administrating a kerberos 5 KDC.  This document
-   describes the services exposed by an administrative interface to a
-   KDC.
-
-
-Table of Contents
-
-   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  How to interpret RFC2119 terms . . . . . . . . . . . . . . . .  5
-   4.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  6
-   5.  Information model demarcation  . . . . . . . . . . . . . . . .  7
-   6.  Information model specification  . . . . . . . . . . . . . . .  8
-     6.1.  Principal  . . . . . . . . . . . . . . . . . . . . . . . .  8
-       6.1.1.  Principal: Attributes  . . . . . . . . . . . . . . . .  8
-       6.1.2.  Principal: Associations  . . . . . . . . . . . . . . .  9
-       6.1.3.  Principal: Remarks . . . . . . . . . . . . . . . . . . 10
-     6.2.  KeySet . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-       6.2.1.  KeySet: Attributes . . . . . . . . . . . . . . . . . . 10
-       6.2.2.  KeySet: Associations . . . . . . . . . . . . . . . . . 10
-       6.2.3.  KeySet: Remarks  . . . . . . . . . . . . . . . . . . . 10
-     6.3.  Key  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
-       6.3.1.  Key: Attributes  . . . . . . . . . . . . . . . . . . . 11
-       6.3.2.  Key: Associations  . . . . . . . . . . . . . . . . . . 12
-       6.3.3.  Key: Remarks . . . . . . . . . . . . . . . . . . . . . 12
-     6.4.  Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-       6.4.1.  Policy: Attributes . . . . . . . . . . . . . . . . . . 12
-       6.4.2.  Mandatory-to-implement Policy  . . . . . . . . . . . . 13
-   7.  Implementation Scenarios . . . . . . . . . . . . . . . . . . . 14
-     7.1.  LDAP backend to KDC  . . . . . . . . . . . . . . . . . . . 14
-     7.2.  LDAP frontend to KDC . . . . . . . . . . . . . . . . . . . 14
-     7.3.  SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 17
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
-   Intellectual Property and Copyright Statements . . . . . . . . . . 19
-
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                  [Page 2]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-1.  Requirements notation
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                  [Page 3]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-2.  Introduction
-
-   The Kerberos version 5 authentication service described in [RFC4120]
-   describes how a Key Distribution Service (KDC) provides
-   authentication to clients.  The standard does not stipulate how a KDC
-   is managed and several "kadmin" servers have evolved.  This document
-   describes the services required to administrate a KDC and the
-   underlying information model assumed by a kadmin-type service.
-
-   The information model is written in terms of "attributes" and
-   "services" or "interfaces" but the use of these particular words MUST
-   NOT be taken to imply any particular modeling paradigm so that
-   neither an object oriented model or an LDAP schema is intended.  The
-   author has attempted to describe in natural language the intended
-   semantics and syntax of the components of the model.  An LDAP schema
-   (for instance) based on this model will be more precise in the
-   expression of the syntax while preserving the semantics of this
-   model.
-
-   Implementations of this document MAY decide to change the names used
-   (eg principalName).  If so an implementation MUST provide a name to
-   name mapping to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                  [Page 4]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-3.  How to interpret RFC2119 terms
-
-   This document describes an information model for kerberos 5 but does
-   not directly describe any mapping onto a particular schema- or
-   modelling language.  Hence an implementation of this model consists
-   of a mapping to such a language - eg an LDAP or SQL schema.  The
-   precise interpretation of terms from [RFC2119] therefore require some
-   extra explanation.  The terms MUST, MUST NOT, REQUIRED, SHALL, SHALL
-   NOT mean that an implementation MUST provide a feature but does not
-   mean that this feature MUST be REQUIRED by the implementation - eg an
-   attribute is available in an LDAP schema but marked as OPTIONAL.  If
-   a feature must be implemented and REQUIRED this is made explicit in
-   this model.  The term MAY, OPTIONAL and RECOMMENDED means that an
-   implementation MAY need to REQUIRE the feature due to the particular
-   nature of the schema/modelling language.  In some cases this is
-   expressly forbidden by this model (feature X MUST NOT be REQUIRED by
-   an implementation).
-
-   Note that any implementation of this model SHOULD be published as an
-   RFC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                  [Page 5]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-4.  Acknowledgments
-
-   Love Hoernquist-Aestrand <lha@it.su.se> for important contributions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                  [Page 6]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-5.  Information model demarcation
-
-   The information model specified in the next chapter describes
-   objects, properties of those objects and relations between those
-   objects.  These elements comprise an abstract view of the data
-   represented in a KDC.  It is important to understand that the
-   information model is not a schema.  In particular the way objects are
-   compared for equality beyond that which is implied by the
-   specification of a syntax is not part of this specification.  Nor is
-   ordering specified between elements of a particular syntax.
-
-   Further work on Kerberos will undoubtedly prompt updates to this
-   information model to reflect changes in the functions performed by
-   the KDC.  Such extensions to the information model MUST always use a
-   normative reference to the relevant RFCs detailing the change in KDC
-   function.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                  [Page 7]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-6.  Information model specification
-
-6.1.  Principal
-
-   The fundamental entity stored in a KDC is the principal.  The
-   principal is associated to keys and generalizes the "user" concept.
-   The principal MUST be implemented in full and MUST NOT be optional in
-   an implementation
-
-6.1.1.  Principal: Attributes
-
-6.1.1.1.  principalName
-
-   The principalName MUST uniquely identify the principal within the
-   administrative context of the KDC.  The type of the principalName is
-   not described in this document.  It is a unique identifier and can be
-   viewed as an opaque byte string which can be compared for equality.
-   The attribute SHOULD be single valued.  If an implementation supports
-   multiple values it MUST treat one of the values as special and allow
-   it to be fetched as if it was a single value.
-
-6.1.1.2.  principalNotUsedBefore
-
-   The principal may not be used before this date.  The syntax of the
-   attribute MUST be semantically equivalent with the standard ISO date
-   format.  The attribute MUST be single valued.
-
-6.1.1.3.  principalNotUsedAfter
-
-   The principal may not be used after this date.  The syntax of the
-   attribute MUST be semantically equivalent with the standard ISO date
-   format.  The attribute MUST be single valued.
-
-6.1.1.4.  principalIsDisabled
-
-   A boolean attribute used to (temporarily) disable a principal.  The
-   attribute MUST default to false.
-
-6.1.1.5.  principalAliases
-
-   This multivalued attribute contains an unordered set of aliases for
-   the principal.  Each alias SHOULD be unique within the administrative
-   domain represented by the KDC.  The syntax of an alias is an opaque
-   identifier which can be compared for equality.
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                  [Page 8]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-6.1.1.6.  principalNumberOfFailedAuthenticationAttempts
-
-   This single valued integer attribute contains a count of the number
-   of times an authentication attempt was unsuccessful for this
-   principal.  Implementations SHOULD NOT allow this counter to be
-   reset.
-
-6.1.1.7.  principalLastFailedAuthentication
-
-   This single valued attribute contains the time and date for the last
-   failed authentication attempt for this principal.
-
-6.1.1.8.  principalLastSuccessfulAuthentication
-
-   This single valued attribute contains the time and date for the last
-   successful authentication attempt for this principal.
-
-6.1.1.9.  principalLastCredentialChange
-
-   This single valued attribute contains the time and date for the last
-   successful change of credential (eg password) this principal.
-
-6.1.1.10.  principalCreateTime
-
-   This single valued attribute contains the time and date when this
-   principal was created
-
-6.1.1.11.  principalModdifyTime
-
-   This single valued attribute contains the time and date when this
-   principal was modified excluding credentials change.
-
-6.1.1.12.  principalMaximumTicketLifetime
-
-   This single valued attribute contains the delta time in seconds
-   representing the maximum ticket lifetime for tickets issued for this
-   principal.
-
-6.1.1.13.  principalMaximumRenewableTicketLifetime
-
-   This single valued attribute contains the delta time in seconds
-   representing the maximum amount of time a ticket may be renewed for.
-
-6.1.2.  Principal: Associations
-
-   Each principal MAY be associated with 1 or more KeySet and MAY be
-   associated with 1 or more Policies.  The KeySet is represented as an
-   object in this model since it has attributes associated with it (the
-
-
-
-Johansson                  Expires May 7, 2009                  [Page 9]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-   key version number).  In typical situations the principal is
-   associated with exactly 1 KeySet but implementations MUST NOT assume
-   this case, i.e an implemenation of this standard (e.g an LDAP schema)
-   MUST be able to handle the general case of multiple KeySet associated
-   with each principal.
-
-6.1.3.  Principal: Remarks
-
-   Traditionally a principal consists of a local-part and a realm
-   denoted in string form by local-part@REALM.  The realm concept is
-   used to provide administrative boundaries and together with cross-
-   realm authentication provides scalability to Kerberos 5.  However the
-   realm is not central to an administrative information model.  For
-   instance the initialization or creation of a realm is equivalent to
-   creating a specific set of principals (krbtgt@REALM, etc) which is
-   covered by the model and services described in this document.  A
-   realm is typically associated with policy covering (for instance)
-   keying and password management.  The management of such policy and
-   their association to realms is beyond the scope of this document.
-
-6.2.  KeySet
-
-   A KeySet is a set of keys associated with exactly one principal.
-   This object and its associations MUST NOT be REQUIRED by an
-   implementation.  It is expected that most implementations of this
-   standard will use the set/change password protocol for all aspects of
-   key management [I-D.ietf-krb-wg-kerberos-set-passwd].  This
-   information model only includes these objects for the sake of
-   completenes.
-
-6.2.1.  KeySet: Attributes
-
-6.2.1.1.  keySetVersionNumber
-
-   This is traditionally called the key version number (kvno).  This is
-   a single valued attribute containing a positive integer.
-
-6.2.2.  KeySet: Associations
-
-   To each KeySet MUST be associated a set of 1 or more Keys.
-
-6.2.3.  KeySet: Remarks
-
-   The reason for separating the KeySet from the Principal is security.
-   The security of Kerberos 5 depends absolutely on the security of the
-   keys stored in the KDC.  The KeySet type is provided to make this
-   clear and to make separation of keys from other parts of the model
-   clear.
-
-
-
-Johansson                  Expires May 7, 2009                 [Page 10]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-   Implementations of this standard (eg an LDAP schema) MUST make a
-   clear separation between the representation of KeySet from other
-   information objects.
-
-6.3.  Key
-
-   Implementations of this model MUST NOT REQUIRE keys to be
-   represented.
-
-6.3.1.  Key: Attributes
-
-6.3.1.1.  keyEncryptionType
-
-   The enctype SHOULD be represented as an enumeration of the enctypes
-   supported by the KDC.
-
-6.3.1.2.  keyValue
-
-   The binary representation of the key data.  This MUST be a single
-   valued octet string.
-
-6.3.1.3.  keySaltValue
-
-   The binary representation of the key salt.  This MUST be a single
-   valued octet string.
-
-6.3.1.4.  keyStringToKeyParameter
-
-   This MUST be a single valued octet string representing an opaque
-   parameter associated with the enctype.
-
-6.3.1.5.  keyNotUsedAfter
-
-   This key MUST NOT be used after this date.  The syntax of the
-   attribute MUST be semantically equivalent with the standard ISO date
-   format.  This MUST be a single-valued attribute.
-
-6.3.1.6.  keyNotUsedBefore
-
-   This key MUST NOT be used before this date.  The syntax of the
-   attribute MUST be semantically equivalent with the standard ISO date
-   format.  This MUST be a single-valued attribute.
-
-6.3.1.7.  keyIsDisabled
-
-   This is a boolean attribute which must be set to false by default.
-   If this attribute is true the key MUST NOT be used.  This is used to
-   temporarily disable a key.
-
-
-
-Johansson                  Expires May 7, 2009                 [Page 11]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-6.3.2.  Key: Associations
-
-   None
-
-6.3.3.  Key: Remarks
-
-   The security of the keys is an absolute requirement for the operation
-   of Kerberos 5.  If keys are implemented adequate protection from
-   unauthorized modification and disclosure MUST be available and
-   REQUIRED by the implementation.
-
-6.4.  Policy
-
-   Implementations SHOULD implement policy but MAY allow them to be
-   OPTIONAL.  The Policy should be thought of as a 'typed hole'. i.e an
-   opaque binary value paired with an identifier of type of data
-   contained in the binary value.  Both attributes (type and value) must
-   be present.
-
-6.4.1.  Policy: Attributes
-
-6.4.1.1.  policyIdentifier
-
-   The policyIdentifier MUST be unique within the local administrative
-   context and MUST be globally unique.  Possible types of identifiers
-   include:
-
-      An Object Identifier (OID)
-
-      A URN
-
-      A UUID
-
-   The use of OIDs is recommended for this purpose.
-
-6.4.1.2.  policyIsCritical
-
-   This boolean attribute indicates that the KDC MUST be able to
-   correctly interpret and apply this policy for the key to be used.
-
-6.4.1.3.  policyContent
-
-   This is an optional single opaque binary value used to store a
-   representation of the policy.  In general a policy cannot be fully
-   expressed using attribute-value pairs.  The policyContent is OPTIONAL
-   in the sense that an implementation MAY use it to store an opaque
-   value for those policy-types which are not directly representable in
-   that implementation.
-
-
-
-Johansson                  Expires May 7, 2009                 [Page 12]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-6.4.1.4.  policyUse
-
-   This is an optional single enumerated string value used to describe
-   the applicability of the policy.  Implementations SHOULD provide this
-   attribute and MUST (if the attribute is implemented) describe the
-   enumerated set of possible values.
-
-6.4.2.  Mandatory-to-implement Policy
-
-   All implementations MUST be able to represent the policies listed in
-   this section.  Implementations are not required to use the same
-   underlying data-representation for the policyContent binary value but
-   SHOULD use the same OIDs as the policyIdentifier.
-
-6.4.2.1.  Password Quality Policy
-
-   Password quality policy controls the requirements placed by the KDC
-   on new passwords.  This policy SHOULD be identified by the OID <TBD>.
-
-6.4.2.2.  Password Management Policy
-
-   Password management policy controls how passwords are changed.  This
-   policy SHOULD be identified by the OID <TBD>.
-
-6.4.2.3.  Keying Policy
-
-   A keying policy specifies the association of enctypes with new
-   principals, i.e when a principal is created one of the possibly many
-   applicable keying policies determine the set of keys to associate
-   with the principal.  In general the expression of a keying policy may
-   require a Turing-complete language.  This policy SHOULD be identified
-   by the OID <TBD>.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                 [Page 13]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-7.  Implementation Scenarios
-
-   There are several ways to implement an administrative service for
-   Kerberos 5 based on this information model.  In this section we list
-   a few of them.
-
-7.1.  LDAP backend to KDC
-
-   Given an LDAP schema implementation of this information model it
-   would be possible to build an administrative service by backending
-   the KDC to a directory server where principals and keys are stored.
-   Using the security mechanisms available on the directory server keys
-   are protected from access by anyone apart from the KDC.
-   Administration of the principals, policy and other non-key data is
-   done through the directory server while the keys are modified using
-   the set/change password protocol
-   [I-D.ietf-krb-wg-kerberos-set-passwd].
-
-7.2.  LDAP frontend to KDC
-
-   An alternative way to provide a directory interface to the KDC is to
-   implement an LDAP-frontend to the KDC which exposes all non-key
-   objects as entries and attributes.  As in the example above all keys
-   are modified using the set/change password protocol
-   [I-D.ietf-krb-wg-kerberos-set-passwd].  In this scenario the
-   implementation would typically not use a traditional LDAP
-   implementation but treat LDAP as an access-protocol to data in the
-   native KDC database.
-
-7.3.  SOAP
-
-   Given an XML schema implementation of this information model it would
-   be possible to build a SOAP-interface to the KDC.  This demonstrates
-   the value of creating an abstract information model which is mappable
-   to multiple schema representations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                 [Page 14]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-8.  Security Considerations
-
-   This document describes an abstract information model for Kerberos 5.
-   The Kerberos 5 protocol depends on the security of the keys stored in
-   the KDC.  The model described here assumes that keys MUST NOT be
-   transported in the clear over the network and furthermore that keys
-   are treated as write-only attributes that SHALL only be modified
-   (using the administrative interface) by the change-password protocol
-   [I-D.ietf-krb-wg-kerberos-set-passwd].
-
-   Exposing the object model of a KDC typically implies that objects can
-   be modified and/or deleted.  In a KDC not all principals are created
-   equal, so that for instance deleting krbtgt/EXAMPLE.COM@EXAMPLE.COM
-   effectively disables the EXAMPLE.COM realm.  Hence access control is
-   paramount to the security of any implementation.  This document does
-   not (at the time of writing - leifj) mandate access control.  This
-   only implies that access control is beyond the scope of the standard
-   information model, i.e that access control may not be accessible via
-   any protocol based on this model.  If access control objects is
-   exposed via an extension to this model the presence of access control
-   may in itself provide points of attack by giving away information
-   about principals with elevated rights etc. etc.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                 [Page 15]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-9.  IANA Considerations
-
-   None
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                 [Page 16]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-10.2.  Informative References
-
-   [I-D.ietf-krb-wg-kerberos-set-passwd]
-              Williams, N., "Kerberos Set/Change Key/Password Protocol
-              Version 2", draft-ietf-krb-wg-kerberos-set-passwd-07 (work
-              in progress), September 2007.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                 [Page 17]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-Author's Address
-
-   Leif Johansson
-   Stockholm university
-   Avdelningen foer IT och Media
-   Stockholm  SE-106 91
-
-   Email: leifj@it.su.se
-   URI:   http://people.su.se/~leifj/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                 [Page 18]
-
-Internet-Draft            KDC Information Model            November 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-Johansson                  Expires May 7, 2009                 [Page 19]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-03.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-03.txt
deleted file mode 100644
index 005ea86b0..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-03.txt
+++ /dev/null
@@ -1,7975 +0,0 @@
-
-INTERNET-DRAFT                                          Clifford Neuman
-                                                                USC-ISI
-                                                                 Tom Yu
-                                                            Sam Hartman
-                                                            Ken Raeburn
-                                                                    MIT
-                                                          March 2, 2003
-                                              Expires 2 September, 2003
-
-            The Kerberos Network Authentication Service (V5)
-            draft-ietf-krb-wg-kerberos-clarifications-03.txt
-
-STATUS OF THIS MEMO
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC 2026. 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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   To learn the current status of any Internet-Draft, please check the
-   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
-   Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
-   ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
-
-   The distribution of this memo is unlimited. It is filed as draft-
-   ietf-krb-wg-kerberos-clarifications-03.txt, and expires 2 September
-   2003.  Please send comments to: ietf-krb-wg@anl.gov
-
-ABSTRACT
-
-   This document provides an overview and specification of Version 5 of
-   the Kerberos protocol, and updates RFC1510 to clarify aspects of the
-   protocol and its intended use that require more detailed or clearer
-   explanation than was provided in RFC1510. This document is intended
-   to provide a detailed description of the protocol, suitable for
-   implementation, together with descriptions of the appropriate use of
-   protocol messages and fields within those messages.
-
-
-
-March 2003                                                      [Page 1]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   This document contains a subset of the changes considered and
-   discussed in the Kerberos working group and is intended as an interim
-   description of Kerberos. Additional changes to the Kerberos protocol
-   have been proposed and will appear in a subsequent extensions
-   document.
-
-   This document is not intended to describe Kerberos to the end user,
-   system administrator, or application developer. Higher level papers
-   describing Version 5 of the Kerberos system [NT94] and documenting
-   version 4 [SNS88], are available elsewhere.
-
-OVERVIEW
-
-   This INTERNET-DRAFT describes the concepts and model upon which the
-   Kerberos network authentication system is based. It also specifies
-   Version 5 of the Kerberos protocol.
-
-   The motivations, goals, assumptions, and rationale behind most design
-   decisions are treated cursorily; they are more fully described in a
-   paper available in IEEE communications [NT94] and earlier in the
-   Kerberos portion of the Athena Technical Plan [MNSS87]. The protocols
-   have been a proposed standard and are being considered for
-   advancement for draft standard through the IETF standard process.
-   Comments are encouraged on the presentation, but only minor
-   refinements to the protocol as implemented or extensions that fit
-   within current protocol framework will be considered at this time.
-
-   Requests for addition to an electronic mailing list for discussion of
-   Kerberos, kerberos@MIT.EDU, may be addressed to kerberos-
-   request@MIT.EDU.  This mailing list is gatewayed onto the Usenet as
-   the group comp.protocols.kerberos. Requests for further information,
-   including documents and code availability, may be sent to info-
-   kerberos@MIT.EDU.
-
-BACKGROUND
-
-   The Kerberos model is based in part on Needham and Schroeder's
-   trusted third-party authentication protocol [NS78] and on
-   modifications suggested by Denning and Sacco [DS81]. The original
-   design and implementation of Kerberos Versions 1 through 4 was the
-   work of two former Project Athena staff members, Steve Miller of
-   Digital Equipment Corporation and Clifford Neuman (now at the
-   Information Sciences Institute of the University of Southern
-   California), along with Jerome Saltzer, Technical Director of Project
-   Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other
-   members of Project Athena have also contributed to the work on
-   Kerberos.
-
-
-
-
-March 2003                                                      [Page 2]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   Version 5 of the Kerberos protocol (described in this document) has
-   evolved from Version 4 based on new requirements and desires for
-   features not available in Version 4. The design of Version 5 of the
-   Kerberos protocol was led by Clifford Neuman and John Kohl with much
-   input from the community. The development of the MIT reference
-   implementation was led at MIT by John Kohl and Theodore Ts'o, with
-   help and contributed code from many others. Since RFC1510 was issued,
-   extensions and revisions to the protocol have been proposed by many
-   individuals. Some of these proposals are reflected in this document.
-   Where such changes involved significant effort, the document cites
-   the contribution of the proposer.
-
-   Reference implementations of both version 4 and version 5 of Kerberos
-   are publicly available and commercial implementations have been
-   developed and are widely used. Details on the differences between
-   Kerberos Versions 4 and 5 can be found in [KNT94].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-March 2003                                                      [Page 3]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-                           TTaabbllee ooff CCoonntteennttss
-
-
-1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
-1.1. Cross-realm operation . . . . . . . . . . . . . . . . . . . . .   9
-1.2. Choosing a principal with which to communicate  . . . . . . . .  10
-1.3. Authorization . . . . . . . . . . . . . . . . . . . . . . . . .  11
-1.4. Extending Kerberos Without Breaking Interoperability  . . . . .  11
-1.4.1. Compatibility with RFC 1510 . . . . . . . . . . . . . . . . .  12
-1.4.2. Sending Extensible Messages . . . . . . . . . . . . . . . . .  13
-1.5. Environmental assumptions . . . . . . . . . . . . . . . . . . .  13
-1.6. Glossary of terms . . . . . . . . . . . . . . . . . . . . . . .  14
-2. Ticket flag uses and requests . . . . . . . . . . . . . . . . . .  16
-2.1. Initial, pre-authenticated, and hardware authenticated
-      tickets  . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
-2.2. Invalid tickets . . . . . . . . . . . . . . . . . . . . . . . .  17
-2.3. Renewable tickets . . . . . . . . . . . . . . . . . . . . . . .  18
-2.4. Postdated tickets . . . . . . . . . . . . . . . . . . . . . . .  18
-2.5. Proxiable and proxy tickets . . . . . . . . . . . . . . . . . .  19
-2.6. Forwardable tickets . . . . . . . . . . . . . . . . . . . . . .  20
-2.7. Transited Policy Checking . . . . . . . . . . . . . . . . . . .  21
-2.8. OK as Delegate  . . . . . . . . . . . . . . . . . . . . . . . .  21
-2.9. Other KDC options . . . . . . . . . . . . . . . . . . . . . . .  22
-2.9.1. Renewable-OK  . . . . . . . . . . . . . . . . . . . . . . . .  22
-2.9.2. ENC-TKT-IN-SKEY . . . . . . . . . . . . . . . . . . . . . . .  22
-2.9.3. Passwordless Hardware Authentication  . . . . . . . . . . . .  22
-3. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . . .  23
-3.1. The Authentication Service Exchange . . . . . . . . . . . . . .  23
-3.1.1. Generation of KRB_AS_REQ message  . . . . . . . . . . . . . .  24
-3.1.2. Receipt of KRB_AS_REQ message . . . . . . . . . . . . . . . .  24
-3.1.3. Generation of KRB_AS_REP message  . . . . . . . . . . . . . .  25
-3.1.4. Generation of KRB_ERROR message . . . . . . . . . . . . . . .  27
-3.1.5. Receipt of KRB_AS_REP message . . . . . . . . . . . . . . . .  28
-3.1.6. Receipt of KRB_ERROR message  . . . . . . . . . . . . . . . .  29
-3.2. The Client/Server Authentication Exchange . . . . . . . . . . .  29
-3.2.1. The KRB_AP_REQ message  . . . . . . . . . . . . . . . . . . .  29
-3.2.2. Generation of a KRB_AP_REQ message  . . . . . . . . . . . . .  29
-3.2.3. Receipt of KRB_AP_REQ message . . . . . . . . . . . . . . . .  30
-3.2.4. Generation of a KRB_AP_REP message  . . . . . . . . . . . . .  32
-3.2.5. Receipt of KRB_AP_REP message . . . . . . . . . . . . . . . .  33
-3.2.6. Using the encryption key  . . . . . . . . . . . . . . . . . .  33
-3.3. The Ticket-Granting Service (TGS) Exchange  . . . . . . . . . .  34
-3.3.1. Generation of KRB_TGS_REQ message . . . . . . . . . . . . . .  35
-3.3.2. Receipt of KRB_TGS_REQ message  . . . . . . . . . . . . . . .  37
-3.3.3. Generation of KRB_TGS_REP message . . . . . . . . . . . . . .  37
-3.3.3.1. Checking for revoked tickets  . . . . . . . . . . . . . . .  40
-3.3.3.2. Encoding the transited field  . . . . . . . . . . . . . . .  40
-3.3.4. Receipt of KRB_TGS_REP message  . . . . . . . . . . . . . . .  42
-
-
-
-March 2003                                                      [Page 4]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-3.4. The KRB_SAFE Exchange . . . . . . . . . . . . . . . . . . . . .  42
-3.4.1. Generation of a KRB_SAFE message  . . . . . . . . . . . . . .  42
-3.4.2. Receipt of KRB_SAFE message . . . . . . . . . . . . . . . . .  43
-3.5. The KRB_PRIV Exchange . . . . . . . . . . . . . . . . . . . . .  44
-3.5.1. Generation of a KRB_PRIV message  . . . . . . . . . . . . . .  44
-3.5.2. Receipt of KRB_PRIV message . . . . . . . . . . . . . . . . .  44
-3.6. The KRB_CRED Exchange . . . . . . . . . . . . . . . . . . . . .  45
-3.6.1. Generation of a KRB_CRED message  . . . . . . . . . . . . . .  45
-3.6.2. Receipt of KRB_CRED message . . . . . . . . . . . . . . . . .  46
-3.7. User to User Authentication Exchanges . . . . . . . . . . . . .  46
-4. Encryption and Checksum Specifications  . . . . . . . . . . . . .  48
-5. Message Specifications  . . . . . . . . . . . . . . . . . . . . .  49
-5.1. Specific Compatibility Notes on ASN.1 . . . . . . . . . . . . .  51
-5.1.1. ASN.1 Distinguished Encoding Rules  . . . . . . . . . . . . .  51
-5.1.2. Optional Integer Fields . . . . . . . . . . . . . . . . . . .  51
-5.1.3. Empty SEQUENCE OF Types . . . . . . . . . . . . . . . . . . .  51
-5.1.4. Unrecognized Tag Numbers  . . . . . . . . . . . . . . . . . .  52
-5.1.5. Tag Numbers Greater Than 30 . . . . . . . . . . . . . . . . .  52
-5.2. Basic Kerberos Types  . . . . . . . . . . . . . . . . . . . . .  52
-5.2.1. KerberosString  . . . . . . . . . . . . . . . . . . . . . . .  52
-5.2.2. Realm and PrincipalName . . . . . . . . . . . . . . . . . . .  54
-5.2.3. KerberosTime  . . . . . . . . . . . . . . . . . . . . . . . .  54
-5.2.4. Constrained Integer types . . . . . . . . . . . . . . . . . .  55
-5.2.5. HostAddress and HostAddresses . . . . . . . . . . . . . . . .  55
-5.2.6. AuthorizationData . . . . . . . . . . . . . . . . . . . . . .  56
-5.2.6.1. IF-RELEVANT . . . . . . . . . . . . . . . . . . . . . . . .  57
-5.2.6.2. KDCIssued . . . . . . . . . . . . . . . . . . . . . . . . .  57
-5.2.6.3. AND-OR  . . . . . . . . . . . . . . . . . . . . . . . . . .  59
-5.2.6.4. MANDATORY-FOR-KDC . . . . . . . . . . . . . . . . . . . . .  59
-5.2.7. PA-DATA . . . . . . . . . . . . . . . . . . . . . . . . . . .  59
-5.2.7.1. PA-TGS-REQ  . . . . . . . . . . . . . . . . . . . . . . . .  60
-5.2.7.2. Encrypted Timestamp Pre-authentication  . . . . . . . . . .  60
-5.2.7.3. PA-PW-SALT  . . . . . . . . . . . . . . . . . . . . . . . .  61
-5.2.7.4. PA-ETYPE-INFO . . . . . . . . . . . . . . . . . . . . . . .  61
-5.2.7.5. PA-ETYPE-INFO2  . . . . . . . . . . . . . . . . . . . . . .  62
-5.2.8. KerberosFlags . . . . . . . . . . . . . . . . . . . . . . . .  63
-5.2.9. Cryptosystem-related Types  . . . . . . . . . . . . . . . . .  64
-5.3. Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . .  65
-5.4. Specifications for the AS and TGS exchanges . . . . . . . . . .  73
-5.4.1. KRB_KDC_REQ definition  . . . . . . . . . . . . . . . . . . .  73
-5.4.2. KRB_KDC_REP definition  . . . . . . . . . . . . . . . . . . .  80
-5.5. Client/Server (CS) message specifications . . . . . . . . . . .  84
-5.5.1. KRB_AP_REQ definition . . . . . . . . . . . . . . . . . . . .  84
-5.5.2. KRB_AP_REP definition . . . . . . . . . . . . . . . . . . . .  87
-5.5.3. Error message reply . . . . . . . . . . . . . . . . . . . . .  88
-5.6. KRB_SAFE message specification  . . . . . . . . . . . . . . . .  88
-5.6.1. KRB_SAFE definition . . . . . . . . . . . . . . . . . . . . .  88
-5.7. KRB_PRIV message specification  . . . . . . . . . . . . . . . .  90
-
-
-
-March 2003                                                      [Page 5]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-5.7.1. KRB_PRIV definition . . . . . . . . . . . . . . . . . . . . .  90
-5.8. KRB_CRED message specification  . . . . . . . . . . . . . . . .  91
-5.8.1. KRB_CRED definition . . . . . . . . . . . . . . . . . . . . .  91
-5.9. Error message specification . . . . . . . . . . . . . . . . . .  93
-5.9.1. KRB_ERROR definition  . . . . . . . . . . . . . . . . . . . .  93
-5.10. Application Tag Numbers  . . . . . . . . . . . . . . . . . . .  95
-6. Naming Constraints  . . . . . . . . . . . . . . . . . . . . . . .  96
-6.1. Realm Names . . . . . . . . . . . . . . . . . . . . . . . . . .  96
-6.2. Principal Names . . . . . . . . . . . . . . . . . . . . . . . .  98
-6.2.1. Name of server principals . . . . . . . . . . . . . . . . . .  99
-7. Constants and other defined values  . . . . . . . . . . . . . . . 100
-7.1. Host address types  . . . . . . . . . . . . . . . . . . . . . . 100
-7.2. KDC messaging - IP Transports . . . . . . . . . . . . . . . . . 101
-7.2.1. UDP/IP transport  . . . . . . . . . . . . . . . . . . . . . . 101
-7.2.2. TCP/IP transport  . . . . . . . . . . . . . . . . . . . . . . 101
-7.2.3. KDC Discovery on IP Networks  . . . . . . . . . . . . . . . . 103
-7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names  . . . . 103
-7.2.3.2. Specifying KDC Location information with DNS SRV
-      records  . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
-7.2.3.3. KDC Discovery for Domain Style Realm Names on IP
-      Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
-7.3. Name of the TGS . . . . . . . . . . . . . . . . . . . . . . . . 104
-7.4. OID arc for KerberosV5  . . . . . . . . . . . . . . . . . . . . 104
-7.5. Protocol constants and associated values  . . . . . . . . . . . 104
-7.5.1. Key usage numbers . . . . . . . . . . . . . . . . . . . . . . 105
-7.5.2. PreAuthentication Data Types  . . . . . . . . . . . . . . . . 106
-7.5.3. Address Types . . . . . . . . . . . . . . . . . . . . . . . . 107
-7.5.4. Authorization Data Types  . . . . . . . . . . . . . . . . . . 107
-7.5.5. Transited Encoding Types  . . . . . . . . . . . . . . . . . . 107
-7.5.6. Protocol Version Number . . . . . . . . . . . . . . . . . . . 107
-7.5.7. Kerberos Message Types  . . . . . . . . . . . . . . . . . . . 108
-7.5.8. Name Types  . . . . . . . . . . . . . . . . . . . . . . . . . 108
-7.5.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 108
-8. Interoperability requirements . . . . . . . . . . . . . . . . . . 110
-8.1. Specification 2 . . . . . . . . . . . . . . . . . . . . . . . . 110
-8.2. Recommended KDC values  . . . . . . . . . . . . . . . . . . . . 113
-9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . . 113
-10. Security Considerations  . . . . . . . . . . . . . . . . . . . . 113
-11. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 117
-12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 117
-13. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
-A. ASN.1 module  . . . . . . . . . . . . . . . . . . . . . . . . . . 120
-B. Changes since RFC-1510  . . . . . . . . . . . . . . . . . . . . . 129
-END NOTES  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
-
-
-
-
-
-
-
-March 2003                                                      [Page 6]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-1. Introduction
-
-   Kerberos provides a means of verifying the identities of principals,
-   (e.g. a workstation user or a network server) on an open
-   (unprotected) network. This is accomplished without relying on
-   assertions by the host operating system, without basing trust on host
-   addresses, without requiring physical security of all the hosts on
-   the network, and under the assumption that packets traveling along
-   the network can be read, modified, and inserted at will[1]. Kerberos
-   performs authentication under these conditions as a trusted third-
-   party authentication service by using conventional (shared secret key
-   [2]) cryptography. Kerberos extensions (outside the scope of this
-   document) can provide for the use of public key cryptography during
-   certain phases of the authentication protocol [@RFCE: if PKINIT
-   advances concurrently include reference to the RFC here]. Such
-   extensions support Kerberos authentication for users registered with
-   public key certification authorities and provide certain benefits of
-   public key cryptography in situations where they are needed.
-
-   The basic Kerberos authentication process proceeds as follows: A
-   client sends a request to the authentication server (AS) requesting
-   "credentials" for a given server. The AS responds with these
-   credentials, encrypted in the client's key. The credentials consist
-   of a "ticket" for the server and a temporary encryption key (often
-   called a "session key"). The client transmits the ticket (which
-   contains the client's identity and a copy of the session key, all
-   encrypted in the server's key) to the server. The session key (now
-   shared by the client and server) is used to authenticate the client,
-   and may optionally be used to authenticate the server. It may also be
-   used to encrypt further communication between the two parties or to
-   exchange a separate sub-session key to be used to encrypt further
-   communication.
-
-   Implementation of the basic protocol consists of one or more
-   authentication servers running on physically secure hosts. The
-   authentication servers maintain a database of principals (i.e., users
-   and servers) and their secret keys. Code libraries provide encryption
-   and implement the Kerberos protocol.  In order to add authentication
-   to its transactions, a typical network application adds one or two
-   calls to the Kerberos library directly or through the Generic
-   Security Services Application Programming Interface, GSSAPI,
-   described in separate document [ref to GSSAPI RFC]. These calls
-   result in the transmission of the necessary messages to achieve
-   authentication.
-
-   The Kerberos protocol consists of several sub-protocols (or
-   exchanges).  There are two basic methods by which a client can ask a
-   Kerberos server for credentials. In the first approach, the client
-
-
-
-March 2003                                                      [Page 7]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   sends a cleartext request for a ticket for the desired server to the
-   AS. The reply is sent encrypted in the client's secret key. Usually
-   this request is for a ticket-granting ticket (TGT) which can later be
-   used with the ticket-granting server (TGS).  In the second method,
-   the client sends a request to the TGS. The client uses the TGT to
-   authenticate itself to the TGS in the same manner as if it were
-   contacting any other application server that requires Kerberos
-   authentication. The reply is encrypted in the session key from the
-   TGT.  Though the protocol specification describes the AS and the TGS
-   as separate servers, they are implemented in practice as different
-   protocol entry points within a single Kerberos server.
-
-   Once obtained, credentials may be used to verify the identity of the
-   principals in a transaction, to ensure the integrity of messages
-   exchanged between them, or to preserve privacy of the messages. The
-   application is free to choose whatever protection may be necessary.
-
-   To verify the identities of the principals in a transaction, the
-   client transmits the ticket to the application server. Since the
-   ticket is sent "in the clear" (parts of it are encrypted, but this
-   encryption doesn't thwart replay) and might be intercepted and reused
-   by an attacker, additional information is sent to prove that the
-   message originated with the principal to whom the ticket was issued.
-   This information (called the authenticator) is encrypted in the
-   session key, and includes a timestamp. The timestamp proves that the
-   message was recently generated and is not a replay.  Encrypting the
-   authenticator in the session key proves that it was generated by a
-   party possessing the session key. Since no one except the requesting
-   principal and the server know the session key (it is never sent over
-   the network in the clear) this guarantees the identity of the client.
-
-   The integrity of the messages exchanged between principals can also
-   be guaranteed using the session key (passed in the ticket and
-   contained in the credentials). This approach provides detection of
-   both replay attacks and message stream modification attacks. It is
-   accomplished by generating and transmitting a collision-proof
-   checksum (elsewhere called a hash or digest function) of the client's
-   message, keyed with the session key. Privacy and integrity of the
-   messages exchanged between principals can be secured by encrypting
-   the data to be passed using the session key contained in the ticket
-   or the sub-session key found in the authenticator.
-
-   The authentication exchanges mentioned above require read-only access
-   to the Kerberos database. Sometimes, however, the entries in the
-   database must be modified, such as when adding new principals or
-   changing a principal's key.  This is done using a protocol between a
-   client and a third Kerberos server, the Kerberos Administration
-   Server (KADM). There is also a protocol for maintaining multiple
-
-
-
-March 2003                                                      [Page 8]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   copies of the Kerberos database. Neither of these protocols are
-   described in this document.
-
-1.1. Cross-realm operation
-
-   The Kerberos protocol is designed to operate across organizational
-   boundaries. A client in one organization can be authenticated to a
-   server in another. Each organization wishing to run a Kerberos server
-   establishes its own "realm". The name of the realm in which a client
-   is registered is part of the client's name, and can be used by the
-   end-service to decide whether to honor a request.
-
-   By establishing "inter-realm" keys, the administrators of two realms
-   can allow a client authenticated in the local realm to prove its
-   identity to servers in other realms[3]. The exchange of inter-realm
-   keys (a separate key may be used for each direction) registers the
-   ticket-granting service of each realm as a principal in the other
-   realm. A client is then able to obtain a ticket-granting ticket for
-   the remote realm's ticket-granting service from its local realm. When
-   that ticket-granting ticket is used, the remote ticket-granting
-   service uses the inter-realm key (which usually differs from its own
-   normal TGS key) to decrypt the ticket-granting ticket, and is thus
-   certain that it was issued by the client's own TGS. Tickets issued by
-   the remote ticket-granting service will indicate to the end-service
-   that the client was authenticated from another realm.
-
-   A realm is said to communicate with another realm if the two realms
-   share an inter-realm key, or if the local realm shares an inter-realm
-   key with an intermediate realm that communicates with the remote
-   realm. An authentication path is the sequence of intermediate realms
-   that are transited in communicating from one realm to another.
-
-   Realms may be organized hierarchically. Each realm shares a key with
-   its parent and a different key with each child. If an inter-realm key
-   is not directly shared by two realms, the hierarchical organization
-   allows an authentication path to be easily constructed. If a
-   hierarchical organization is not used, it may be necessary to consult
-   a database in order to construct an authentication path between
-   realms.
-
-   Although realms are typically hierarchical, intermediate realms may
-   be bypassed to achieve cross-realm authentication through alternate
-   authentication paths (these might be established to make
-   communication between two realms more efficient). It is important for
-   the end-service to know which realms were transited when deciding how
-   much faith to place in the authentication process. To facilitate this
-   decision, a field in each ticket contains the names of the realms
-   that were involved in authenticating the client.
-
-
-
-March 2003                                                      [Page 9]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   The application server is ultimately responsible for accepting or
-   rejecting authentication and SHOULD check the transited field. The
-   application server may choose to rely on the KDC for the application
-   server's realm to check the transited field. The application server's
-   KDC will set the TRANSITED-POLICY-CHECKED flag in this case. The KDCs
-   for intermediate realms may also check the transited field as they
-   issue ticket-granting tickets for other realms, but they are
-   encouraged not to do so. A client may request that the KDCs not check
-   the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs
-   are encouraged but not required to honor this flag.
-
-1.2. Choosing a principal with which to communicate
-
-   The Kerberos protocol provides the means for verifying (subject to
-   the assumptions in 1.5) that the entity with which one communicates
-   is the same entity that was registered with the KDC using the claimed
-   identity (principal name). It is still necessary to determine whether
-   that identity corresponds to the entity with which one intends to
-   communicate.
-
-   When appropriate data has been exchanged in advance, this
-   determination may be performed syntactically by the application based
-   on the application protocol specification, information provided by
-   the user, and configuration files. For example, the server principal
-   name (including realm) for a telnet server might be derived from the
-   user specified host name (from the telnet command line), the "host/"
-   prefix specified in the application protocol specification, and a
-   mapping to a Kerberos realm derived syntactically from the domain
-   part of the specified hostname and information from the local
-   Kerberos realms database.
-
-   One can also rely on trusted third parties to make this
-   determination, but only when the data obtained from the third party
-   is suitably integrity protected while resident on the third party
-   server and when transmitted.  Thus, for example, one should not rely
-   on an unprotected domain name system record to map a host alias to
-   the primary name of a server, accepting the primary name as the party
-   one intends to contact, since an attacker can modify the mapping and
-   impersonate the party with which one intended to communicate.
-
-   Implementations of Kerberos and protocols based on Kerberos MUST NOT
-   use insecure DNS queries to canonicalize the hostname components of
-   the service principal names.  In an environment without secure name
-   service, application authors MAY append a statically configured
-   domain name to unqualified hostnames before passing the name to the
-   security mechanisms, but should do no more than that.  Secure name
-   service facilities, if available, might be trusted for hostname
-   canonicalization, but such canonicalization by the client SHOULD NOT
-
-
-
-March 2003                                                     [Page 10]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   be required by an KDC implementation.
-
-   Implementation note: Many current implementations do some degree of
-   canonicalization of the provided service name, often using DNS even
-   though it creates security problems. However there is no consistency
-   among implementations about whether the service name is case folded
-   to lower case or whether reverse resolution is used. To maximize
-   interoperability and security, applications SHOULD provide security
-   mechanisms with names which result from folding the user-entered name
-   to lower case, without performing any other modifications or
-   canonicalization.
-
-1.3. Authorization
-
-   As an authentication service, Kerberos provides a means of verifying
-   the identity of principals on a network. Authentication is usually
-   useful primarily as a first step in the process of authorization,
-   determining whether a client may use a service, which objects the
-   client is allowed to access, and the type of access allowed for each.
-   Kerberos does not, by itself, provide authorization. Possession of a
-   client ticket for a service provides only for authentication of the
-   client to that service, and in the absence of a separate
-   authorization procedure, it should not be considered by an
-   application as authorizing the use of that service.
-
-   Such separate authorization methods MAY be implemented as application
-   specific access control functions and may utilize files on the
-   application server, or on separately issued authorization credentials
-   such as those based on proxies [Neu93], or on other authorization
-   services. Separately authenticated authorization credentials MAY be
-   embedded in a ticket's authorization data when encapsulated by the
-   KDC-issued authorization data element.
-
-   Applications should not accept the mere issuance of a service ticket
-   by the Kerberos server (even by a modified Kerberos server) as
-   granting authority to use the service, since such applications may
-   become vulnerable to the bypass of this authorization check in an
-   environment if they interoperate with other KDCs or where other
-   options for application authentication (e.g.  the PKTAPP proposal)
-   are provided.
-
-1.4. Extending Kerberos Without Breaking Interoperability
-
-   As the deployed base of Kerberos implementations grows, extending
-   Kerberos becomes more important. Unfortunately some extensions to the
-   existing Kerberos protocol create interoperability issues because of
-   uncertainty regarding the treatment of certain extensibility options
-   by some implementations. This section includes guidelines that will
-
-
-
-March 2003                                                     [Page 11]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   enable future implementations to maintain interoperability.
-
-   Kerberos provides a general mechanism for protocol extensibility.
-   Some protocol messages contain typed holes -- sub-messages that
-   contain an octet-string along with an integer that defines how to
-   interpret the octet-string. The integer types are registered
-   centrally, but can be used both for vendor extensions and for
-   extensions standardized through the IETF.
-
-1.4.1. Compatibility with RFC 1510
-
-   It is important to note that existing Kerberos message formats can
-   not be readily extended by adding fields to the ASN.1 types. Sending
-   additional fields often results in the entire message being discarded
-   without an error indication. Future versions of this specification
-   will provide guidelines to ensure that ASN.1 fields can be added
-   without creating an interoperability problem.
-
-   In the meantime, all new or modified implementations of Kerberos that
-   receive an unknown message extension SHOULD preserve the encoding of
-   the extension but otherwise ignore the presence of the extension.
-   Recipients MUST NOT decline a request simply because an extension is
-   present.
-
-   There is one exception to this rule. If an unknown authorization data
-   element type is received by a server other than the ticket granting
-   service either in an AP-REQ or in a ticket contained in an AP-REQ,
-   then authentication MUST fail. One of the primary uses of
-   authorization data is to restrict the use of the ticket. If the
-   service cannot determine whether the restriction applies to that
-   service then a security weakness may result if the ticket can be used
-   for that service. Authorization elements that are optional SHOULD be
-   enclosed in the AD-IF-RELEVANT element.
-
-   The ticket granting service MUST ignore but propagate to derivative
-   tickets any unknown authorization data types, unless those data types
-   are embedded in a MANDATORY-FOR-KDC element, in which case the
-   request will be rejected.  This behavior is appropriate because
-   requiring that the ticket granting service understand unknown
-   authorization data types would require that KDC software be upgraded
-   to understand new application-level restrictions before applications
-   used these restrictions, decreasing the utility of authorization data
-   as a mechanism for restricting the use of tickets. No security
-   problem is created because services to which the tickets are issued
-   will verify the authorization data.
-
-   Implementation note: Many RFC 1510 implementations ignore unknown
-   authorization data elements. Depending on these implementations to
-
-
-
-March 2003                                                     [Page 12]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   honor authorization data restrictions may create a security weakness.
-
-1.4.2. Sending Extensible Messages
-
-   Care must be taken to ensure that old implementations can understand
-   messages sent to them even if they do not understand an extension
-   that is used. Unless the sender knows an extension is supported, the
-   extension cannot change the semantics of the core message or
-   previously defined extensions.
-
-   For example, an extension including key information necessary to
-   decrypt the encrypted part of a KDC-REP could only be used in
-   situations where the recipient was known to support the extension.
-   Thus when designing such extensions it is important to provide a way
-   for the recipient to notify the sender of support for the extension.
-   For example in the case of an extension that changes the KDC-REP
-   reply key, the client could indicate support for the extension by
-   including a padata element in the AS-REQ sequence. The KDC should
-   only use the extension if this padata element is present in the AS-
-   REQ. Even if policy requires the use of the extension, it is better
-   to return an error indicating that the extension is required than to
-   use the extension when the recipient may not support it; debugging
-   why implementations do not interoperate is easier when errors are
-   returned.
-
-1.5. Environmental assumptions
-
-   Kerberos imposes a few assumptions on the environment in which it can
-   properly function:
-
-   *  "Denial of service" attacks are not solved with Kerberos. There
-      are places in the protocols where an intruder can prevent an
-      application from participating in the proper authentication steps.
-      Detection and solution of such attacks (some of which can appear
-      to be not-uncommon "normal" failure modes for the system) is
-      usually best left to the human administrators and users.
-
-   *  Principals MUST keep their secret keys secret. If an intruder
-      somehow steals a principal's key, it will be able to masquerade as
-      that principal or impersonate any server to the legitimate
-      principal.
-
-   *  "Password guessing" attacks are not solved by Kerberos. If a user
-      chooses a poor password, it is possible for an attacker to
-      successfully mount an offline dictionary attack by repeatedly
-      attempting to decrypt, with successive entries from a dictionary,
-      messages obtained which are encrypted under a key derived from the
-      user's password.
-
-
-
-March 2003                                                     [Page 13]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   *  Each host on the network MUST have a clock which is "loosely
-      synchronized" to the time of the other hosts; this synchronization
-      is used to reduce the bookkeeping needs of application servers
-      when they do replay detection. The degree of "looseness" can be
-      configured on a per-server basis, but is typically on the order of
-      5 minutes. If the clocks are synchronized over the network, the
-      clock synchronization protocol MUST itself be secured from network
-      attackers.
-
-   *  Principal identifiers are not recycled on a short-term basis. A
-      typical mode of access control will use access control lists
-      (ACLs) to grant permissions to particular principals. If a stale
-      ACL entry remains for a deleted principal and the principal
-      identifier is reused, the new principal will inherit rights
-      specified in the stale ACL entry. By not re-using principal
-      identifiers, the danger of inadvertent access is removed.
-
-1.6. Glossary of terms
-
-      Below is a list of terms used throughout this document.
-
-   Authentication
-      Verifying the claimed identity of a principal.
-
-   Authentication header
-      A record containing a Ticket and an Authenticator to be presented
-      to a server as part of the authentication process.
-
-   Authentication path
-      A sequence of intermediate realms transited in the authentication
-      process when communicating from one realm to another.
-
-   Authenticator
-      A record containing information that can be shown to have been
-      recently generated using the session key known only by the client
-      and server.
-
-   Authorization
-      The process of determining whether a client may use a service,
-      which objects the client is allowed to access, and the type of
-      access allowed for each.
-
-   Capability
-      A token that grants the bearer permission to access an object or
-      service. In Kerberos, this might be a ticket whose use is
-      restricted by the contents of the authorization data field, but
-      which lists no network addresses, together with the session key
-      necessary to use the ticket.
-
-
-
-March 2003                                                     [Page 14]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   Ciphertext
-      The output of an encryption function. Encryption transforms
-      plaintext into ciphertext.
-
-   Client
-      A process that makes use of a network service on behalf of a user.
-      Note that in some cases a Server may itself be a client of some
-      other server (e.g. a print server may be a client of a file
-      server).
-
-   Credentials
-      A ticket plus the secret session key necessary to successfully use
-      that ticket in an authentication exchange.
-
-   Encryption Type (etype)
-      When associated with encrypted data, an encryption type identifies
-      the algorithm used to encrypt the data and is used to select the
-      appropriate algorithm for decrypting the data.  Encryption type
-      tags are communicated in other messages to enumerate algorithms
-      that are desired, supported, preferred, or allowed to be used for
-      encryption of data between parties.  This preference is combined
-      with local information and policy to select an algorithm to be
-      used.
-
-   KDC
-      Key Distribution Center, a network service that supplies tickets
-      and temporary session keys; or an instance of that service or the
-      host on which it runs. The KDC services both initial ticket and
-      ticket-granting ticket requests. The initial ticket portion is
-      sometimes referred to as the Authentication Server (or service).
-      The ticket-granting ticket portion is sometimes referred to as the
-      ticket-granting server (or service).
-
-   Kerberos
-      The name given to the Project Athena's authentication service, the
-      protocol used by that service, or the code used to implement the
-      authentication service.  The name is adopted from the three-headed
-      dog which guards Hades.
-
-   Key Version Number (kvno)
-      A tag associated with encrypted data identifies which key was used
-      for encryption when a long lived key associated with a principal
-      changes over time.  It is used during the transition to a new key
-      so that the party decrypting a message can tell whether the data
-      was encrypted using the old or the new key.
-
-   Plaintext
-      The input to an encryption function or the output of a decryption
-
-
-
-March 2003                                                     [Page 15]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      function. Decryption transforms ciphertext into plaintext.
-
-   Principal
-      A named client or server entity that participates in a network
-      communication, with one name that is considered canonical.
-
-   Principal identifier
-      The canonical name used to uniquely identify each different
-      principal.
-
-   Seal
-      To encipher a record containing several fields in such a way that
-      the fields cannot be individually replaced without either
-      knowledge of the encryption key or leaving evidence of tampering.
-
-   Secret key
-      An encryption key shared by a principal and the KDC, distributed
-      outside the bounds of the system, with a long lifetime. In the
-      case of a human user's principal, the secret key MAY be derived
-      from a password.
-
-   Server
-      A particular Principal which provides a resource to network
-      clients.  The server is sometimes referred to as the Application
-      Server.
-
-   Service
-      A resource provided to network clients; often provided by more
-      than one server (for example, remote file service).
-
-   Session key
-      A temporary encryption key used between two principals, with a
-      lifetime limited to the duration of a single login "session".
-
-   Sub-session key
-      A temporary encryption key used between two principals, selected
-      and exchanged by the principals using the session key, and with a
-      lifetime limited to the duration of a single association.
-
-   Ticket
-      A record that helps a client authenticate itself to a server; it
-      contains the client's identity, a session key, a timestamp, and
-      other information, all sealed using the server's secret key. It
-      only serves to authenticate a client when presented along with a
-      fresh Authenticator.
-
-
-2. Ticket flag uses and requests
-
-
-
-March 2003                                                     [Page 16]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   Each Kerberos ticket contains a set of flags which are used to
-   indicate attributes of that ticket. Most flags may be requested by a
-   client when the ticket is obtained; some are automatically turned on
-   and off by a Kerberos server as required. The following sections
-   explain what the various flags mean and give examples of reasons to
-   use them. With the exception of the INVALID flag clients MUST ignore
-   ticket flags that are not recognized. KDCs MUST ignore KDC options
-   that are not recognized. Some implementations of RFC 1510 are known
-   to reject unknown KDC options, so clients may need to resend a
-   request without KDC new options absent if the request was rejected
-   when sent with option added since RFC 1510. Since new KDCs will
-   ignore unknown options, clients MUST confirm that the ticket returned
-   by the KDC meets their needs.
-
-   Note that it is not, in general, possible to determine whether an
-   option was not honored because it was not understood or because it
-   was rejected either through configuration or policy. When adding a
-   new option to the Kerberos protocol, designers should consider
-   whether the distinction is important for their option. In cases where
-   it is, a mechanism for the KDC to return an indication that the
-   option was understood but rejected needs to be provided in the
-   specification of the option. Often in such cases, the mechanism needs
-   to be broad enough to permit an error or reason to be returned.
-
-2.1. Initial, pre-authenticated, and hardware authenticated tickets
-
-   The INITIAL flag indicates that a ticket was issued using the AS
-   protocol, rather than issued based on a ticket-granting ticket.
-   Application servers that want to require the demonstrated knowledge
-   of a client's secret key (e.g. a password-changing program) can
-   insist that this flag be set in any tickets they accept, and thus be
-   assured that the client's key was recently presented to the
-   application client.
-
-   The PRE-AUTHENT and HW-AUTHENT flags provide additional information
-   about the initial authentication, regardless of whether the current
-   ticket was issued directly (in which case INITIAL will also be set)
-   or issued on the basis of a ticket-granting ticket (in which case the
-   INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are
-   carried forward from the ticket-granting ticket).
-
-2.2. Invalid tickets
-
-   The INVALID flag indicates that a ticket is invalid. Application
-   servers MUST reject tickets which have this flag set. A postdated
-   ticket will be issued in this form. Invalid tickets MUST be validated
-   by the KDC before use, by presenting them to the KDC in a TGS request
-   with the VALIDATE option specified. The KDC will only validate
-
-
-
-March 2003                                                     [Page 17]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   tickets after their starttime has passed. The validation is required
-   so that postdated tickets which have been stolen before their
-   starttime can be rendered permanently invalid (through a hot-list
-   mechanism) (see section 3.3.3.1).
-
-2.3. Renewable tickets
-
-   Applications may desire to hold tickets which can be valid for long
-   periods of time. However, this can expose their credentials to
-   potential theft for equally long periods, and those stolen
-   credentials would be valid until the expiration time of the
-   ticket(s). Simply using short-lived tickets and obtaining new ones
-   periodically would require the client to have long-term access to its
-   secret key, an even greater risk. Renewable tickets can be used to
-   mitigate the consequences of theft. Renewable tickets have two
-   "expiration times": the first is when the current instance of the
-   ticket expires, and the second is the latest permissible value for an
-   individual expiration time. An application client must periodically
-   (i.e. before it expires) present a renewable ticket to the KDC, with
-   the RENEW option set in the KDC request. The KDC will issue a new
-   ticket with a new session key and a later expiration time. All other
-   fields of the ticket are left unmodified by the renewal process. When
-   the latest permissible expiration time arrives, the ticket expires
-   permanently. At each renewal, the KDC MAY consult a hot-list to
-   determine if the ticket had been reported stolen since its last
-   renewal; it will refuse to renew such stolen tickets, and thus the
-   usable lifetime of stolen tickets is reduced.
-
-   The RENEWABLE flag in a ticket is normally only interpreted by the
-   ticket-granting service (discussed below in section 3.3). It can
-   usually be ignored by application servers. However, some particularly
-   careful application servers MAY disallow renewable tickets.
-
-   If a renewable ticket is not renewed by its expiration time, the KDC
-   will not renew the ticket. The RENEWABLE flag is reset by default,
-   but a client MAY request it be set by setting the RENEWABLE option in
-   the KRB_AS_REQ message. If it is set, then the renew-till field in
-   the ticket contains the time after which the ticket may not be
-   renewed.
-
-2.4. Postdated tickets
-
-   Applications may occasionally need to obtain tickets for use much
-   later, e.g. a batch submission system would need tickets to be valid
-   at the time the batch job is serviced. However, it is dangerous to
-   hold valid tickets in a batch queue, since they will be on-line
-   longer and more prone to theft.  Postdated tickets provide a way to
-   obtain these tickets from the KDC at job submission time, but to
-
-
-
-March 2003                                                     [Page 18]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   leave them "dormant" until they are activated and validated by a
-   further request of the KDC. If a ticket theft were reported in the
-   interim, the KDC would refuse to validate the ticket, and the thief
-   would be foiled.
-
-   The MAY-POSTDATE flag in a ticket is normally only interpreted by the
-   ticket-granting service. It can be ignored by application servers.
-   This flag MUST be set in a ticket-granting ticket in order to issue a
-   postdated ticket based on the presented ticket. It is reset by
-   default; it MAY be requested by a client by setting the ALLOW-
-   POSTDATE option in the KRB_AS_REQ message.  This flag does not allow
-   a client to obtain a postdated ticket-granting ticket; postdated
-   ticket-granting tickets can only by obtained by requesting the
-   postdating in the KRB_AS_REQ message. The life (endtime-starttime) of
-   a postdated ticket will be the remaining life of the ticket-granting
-   ticket at the time of the request, unless the RENEWABLE option is
-   also set, in which case it can be the full life (endtime-starttime)
-   of the ticket-granting ticket. The KDC MAY limit how far in the
-   future a ticket may be postdated.
-
-   The POSTDATED flag indicates that a ticket has been postdated. The
-   application server can check the authtime field in the ticket to see
-   when the original authentication occurred. Some services MAY choose
-   to reject postdated tickets, or they may only accept them within a
-   certain period after the original authentication. When the KDC issues
-   a POSTDATED ticket, it will also be marked as INVALID, so that the
-   application client MUST present the ticket to the KDC to be validated
-   before use.
-
-2.5. Proxiable and proxy tickets
-
-   At times it may be necessary for a principal to allow a service to
-   perform an operation on its behalf. The service must be able to take
-   on the identity of the client, but only for a particular purpose. A
-   principal can allow a service to take on the principal's identity for
-   a particular purpose by granting it a proxy.
-
-   The process of granting a proxy using the proxy and proxiable flags
-   is used to provide credentials for use with specific services. Though
-   conceptually also a proxy, users wishing to delegate their identity
-   in a form usable for all purpose MUST use the ticket forwarding
-   mechanism described in the next section to forward a ticket-granting
-   ticket.
-
-   The PROXIABLE flag in a ticket is normally only interpreted by the
-   ticket-granting service. It can be ignored by application servers.
-   When set, this flag tells the ticket-granting server that it is OK to
-   issue a new ticket (but not a ticket-granting ticket) with a
-
-
-
-March 2003                                                     [Page 19]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   different network address based on this ticket. This flag is set if
-   requested by the client on initial authentication. By default, the
-   client will request that it be set when requesting a ticket-granting
-   ticket, and reset when requesting any other ticket.
-
-   This flag allows a client to pass a proxy to a server to perform a
-   remote request on its behalf (e.g. a print service client can give
-   the print server a proxy to access the client's files on a particular
-   file server in order to satisfy a print request).
-
-   In order to complicate the use of stolen credentials, Kerberos
-   tickets are usually valid from only those network addresses
-   specifically included in the ticket[4]. When granting a proxy, the
-   client MUST specify the new network address from which the proxy is
-   to be used, or indicate that the proxy is to be issued for use from
-   any address.
-
-   The PROXY flag is set in a ticket by the TGS when it issues a proxy
-   ticket.  Application servers MAY check this flag and at their option
-   they MAY require additional authentication from the agent presenting
-   the proxy in order to provide an audit trail.
-
-2.6. Forwardable tickets
-
-   Authentication forwarding is an instance of a proxy where the service
-   granted is complete use of the client's identity. An example where it
-   might be used is when a user logs in to a remote system and wants
-   authentication to work from that system as if the login were local.
-
-   The FORWARDABLE flag in a ticket is normally only interpreted by the
-   ticket-granting service. It can be ignored by application servers.
-   The FORWARDABLE flag has an interpretation similar to that of the
-   PROXIABLE flag, except ticket-granting tickets may also be issued
-   with different network addresses. This flag is reset by default, but
-   users MAY request that it be set by setting the FORWARDABLE option in
-   the AS request when they request their initial ticket-granting
-   ticket.
-
-   This flag allows for authentication forwarding without requiring the
-   user to enter a password again. If the flag is not set, then
-   authentication forwarding is not permitted, but the same result can
-   still be achieved if the user engages in the AS exchange specifying
-   the requested network addresses and supplies a password.
-
-   The FORWARDED flag is set by the TGS when a client presents a ticket
-   with the FORWARDABLE flag set and requests a forwarded ticket by
-   specifying the FORWARDED KDC option and supplying a set of addresses
-   for the new ticket. It is also set in all tickets issued based on
-
-
-
-March 2003                                                     [Page 20]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   tickets with the FORWARDED flag set. Application servers may choose
-   to process FORWARDED tickets differently than non-FORWARDED tickets.
-
-   If addressless tickets are forwarded from one system to another,
-   clients SHOULD still use this option to obtain a new TGT in order to
-   have different session keys on the different systems.
-
-2.7. Transited Policy Checking
-
-   In Kerberos, the application server is ultimately responsible for
-   accepting or rejecting authentication and SHOULD check that only
-   suitably trusted KDCs are relied upon to authenticate a principal.
-   The transited field in the ticket identifies which realms (and thus
-   which KDCs) were involved in the authentication process and an
-   application server would normally check this field. If any of these
-   are untrusted to authenticate the indicated client principal
-   (probably determined by a realm-based policy), the authentication
-   attempt MUST be rejected. The presence of trusted KDCs in this list
-   does not provide any guarantee; an untrusted KDC may have fabricated
-   the list.
-
-   While the end server ultimately decides whether authentication is
-   valid, the KDC for the end server's realm MAY apply a realm specific
-   policy for validating the transited field and accepting credentials
-   for cross-realm authentication. When the KDC applies such checks and
-   accepts such cross-realm authentication it will set the TRANSITED-
-   POLICY-CHECKED flag in the service tickets it issues based on the
-   cross-realm TGT. A client MAY request that the KDCs not check the
-   transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs are
-   encouraged but not required to honor this flag.
-
-   Application servers MUST either do the transited-realm checks
-   themselves, or reject cross-realm tickets without TRANSITED-POLICY-
-   CHECKED set.
-
-2.8. OK as Delegate
-
-   For some applications a client may need to delegate authority to a
-   server to act on its behalf in contacting other services.  This
-   requires that the client forward credentials to an intermediate
-   server.  The ability for a client to obtain a service ticket to a
-   server conveys no information to the client about whether the server
-   should be trusted to accept delegated credentials.  The OK-AS-
-   DELEGATE provides a way for a KDC to communicate local realm policy
-   to a client regarding whether an intermediate server is trusted to
-   accept such credentials.
-
-   The OK-AS-DELEGATE flag from the copy of the ticket flags in the
-
-
-
-March 2003                                                     [Page 21]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   encrypted part of the KDC reply indicates to the client that the
-   server (not the client) specified in the ticket has been determined
-   by policy of the realm to be a suitable recipient of delegation.  A
-   client can use the presence of this flag to help it make a decision
-   whether to delegate credentials (either grant a proxy or a forwarded
-   ticket-granting ticket) to this server.  Ignore the value of this
-   flag. When setting this flag, an administrator should consider the
-   Security and placement of the server on which the service will run,
-   as well as whether the service requires the use of delegated
-   credentials.
-
-2.9. Other KDC options
-
-   There are three additional options which MAY be set in a client's
-   request of the KDC.
-
-2.9.1. Renewable-OK
-
-   The RENEWABLE-OK option indicates that the client will accept a
-   renewable ticket if a ticket with the requested life cannot otherwise
-   be provided. If a ticket with the requested life cannot be provided,
-   then the KDC MAY issue a renewable ticket with a renew-till equal to
-   the requested endtime. The value of the renew-till field MAY still be
-   adjusted by site-determined limits or limits imposed by the
-   individual principal or server.
-
-2.9.2. ENC-TKT-IN-SKEY
-
-   In its basic form the Kerberos protocol supports authentication in a
-   client-server
-    setting and is not well suited to authentication in a peer-to-peer
-   environment because the long term key of the user does not remain on
-   the workstation after initial login. Authentication of such peers may
-   be supported by Kerberos in its user-to-user variant. The ENC-TKT-IN-
-   SKEY option supports user-to-user authentication by allowing the KDC
-   to issue a service ticket encrypted using the session key from
-   another ticket-granting ticket issued to another user. The ENC-TKT-
-   IN-SKEY option is honored only by the ticket-granting service. It
-   indicates that the ticket to be issued for the end server is to be
-   encrypted in the session key from the additional second ticket-
-   granting ticket provided with the request. See section 3.3.3 for
-   specific details.
-
-2.9.3. Passwordless Hardware Authentication
-
-   The OPT-HARDWARE-AUTH option indicates that the client wishes to use
-   some form of hardware authentication instead of or in addition to the
-   client's password or other long-lived encryption key. OPT-HARDWARE-
-
-
-
-March 2003                                                     [Page 22]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   AUTH is honored only by the authentication service. If supported and
-   allowed by policy, the KDC will return an errorcode
-   KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to
-   perform such authentication.
-
-3. Message Exchanges
-
-   The following sections describe the interactions between network
-   clients and servers and the messages involved in those exchanges.
-
-3.1. The Authentication Service Exchange
-
-                             Summary
-
-         Message direction       Message type    Section
-         1. Client to Kerberos   KRB_AS_REQ      5.4.1
-         2. Kerberos to client   KRB_AS_REP or   5.4.2
-                                 KRB_ERROR       5.9.1
-
-   The Authentication Service (AS) Exchange between the client and the
-   Kerberos Authentication Server is initiated by a client when it
-   wishes to obtain authentication credentials for a given server but
-   currently holds no credentials. In its basic form, the client's
-   secret key is used for encryption and decryption. This exchange is
-   typically used at the initiation of a login session to obtain
-   credentials for a Ticket-Granting Server which will subsequently be
-   used to obtain credentials for other servers (see section 3.3)
-   without requiring further use of the client's secret key. This
-   exchange is also used to request credentials for services which must
-   not be mediated through the Ticket-Granting Service, but rather
-   require a principal's secret key, such as the password-changing
-   service[5]. This exchange does not by itself provide any assurance of
-   the identity of the user[6].
-
-   The exchange consists of two messages: KRB_AS_REQ from the client to
-   Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
-   messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
-
-   In the request, the client sends (in cleartext) its own identity and
-   the identity of the server for which it is requesting credentials,
-   other information about the credentials it is requesting, and a
-   randomly generated nonce which can be used to detect replays, and to
-   associate replies with the matching requests. This nonce MUST be
-   generated randomly by the client and remembered for checking against
-   the nonce in the expected reply. The response, KRB_AS_REP, contains a
-   ticket for the client to present to the server, and a session key
-   that will be shared by the client and the server.  The session key
-   and additional information are encrypted in the client's secret key.
-
-
-
-March 2003                                                     [Page 23]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   The encrypted part of the KRB_AS_REP message also contains the nonce
-   which MUST be matched with the nonce from the KRB_AS_REQ message.
-
-   Without pre-authentication, the authentication server does not know
-   whether the client is actually the principal named in the request. It
-   simply sends a reply without knowing or caring whether they are the
-   same. This is acceptable because nobody but the principal whose
-   identity was given in the request will be able to use the reply. Its
-   critical information is encrypted in that principal's key. However,
-   an attacker can send a KRB_AS_REQ message to get known plaintext in
-   order to attack the principal's key. Especially if the key is based
-   on a password, this may create a security exposure. So, the initial
-   request supports an optional field that can be used to pass
-   additional information that might be needed for the initial exchange.
-   This field SHOULD be used for pre-authentication as described in
-   sections 3.1.1 and 5.2.7.
-
-   Various errors can occur; these are indicated by an error response
-   (KRB_ERROR) instead of the KRB_AS_REP response. The error message is
-   not encrypted. The KRB_ERROR message contains information which can
-   be used to associate it with the message to which it replies. The
-   contents of the KRB_ERROR message are not integrity-protected. As
-   such, the client cannot detect replays, fabrications or
-   modifications. A solution to this problem will be included in a
-   future version of the protocol.
-
-3.1.1. Generation of KRB_AS_REQ message
-
-   The client may specify a number of options in the initial request.
-   Among these options are whether pre-authentication is to be
-   performed; whether the requested ticket is to be renewable,
-   proxiable, or forwardable; whether it should be postdated or allow
-   postdating of derivative tickets; and whether a renewable ticket will
-   be accepted in lieu of a non-renewable ticket if the requested ticket
-   expiration date cannot be satisfied by a non-renewable ticket (due to
-   configuration constraints).
-
-   The client prepares the KRB_AS_REQ message and sends it to the KDC.
-
-3.1.2. Receipt of KRB_AS_REQ message
-
-   If all goes well, processing the KRB_AS_REQ message will result in
-   the creation of a ticket for the client to present to the server. The
-   format for the ticket is described in section 5.3. The contents of
-   the ticket are determined as follows.
-
-   Because Kerberos can run over unreliable transports such as UDP, the
-   KDC MUST be prepared to retransmit responses in case they are lost.
-
-
-
-March 2003                                                     [Page 24]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   If a KDC receives a request identical to one it has recently
-   successfully processed, the KDC MUST respond with a KRB_AS_REP
-   message rather than a replay error.  In order to reduce ciphertext
-   given to a potential attacker, KDCs MAY send the same response
-   generated when the request was first handled. KDCs MUST obey this
-   replay behavior even if the actual transport in use is reliable.
-
-3.1.3. Generation of KRB_AS_REP message
-
-   The authentication server looks up the client and server principals
-   named in the KRB_AS_REQ in its database, extracting their respective
-   keys. If the requested client principal named in the request is not
-   known because it doesn't exist in the KDC's principal database, then
-   an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
-
-   If required, the server pre-authenticates the request, and if the
-   pre-authentication check fails, an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is
-   required, but was not present in the request, an error message with
-   the code KDC_ERR_PREAUTH_REQUIRED is returned and a METHOD-DATA
-   object will be stored in the e-data field of the KRB-ERROR message to
-   specify which pre-authentication mechanisms are acceptable.  Usually
-   this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as
-   described below. If the server cannot accommodate any encryption type
-   requested by the client, an error message with code
-   KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC generates a
-   'random' session key[7].
-
-   When responding to an AS request, if there are multiple encryption
-   keys registered for a client in the Kerberos database, then the etype
-   field from the AS request is used by the KDC to select the encryption
-   method to be used to protect the encrypted part of the KRB_AS_REP
-   message which is sent to the client. If there is more than one
-   supported strong encryption type in the etype list, the KDC SHOULD
-   use the first valid strong etype for which an encryption key is
-   available.
-
-   When the user's key is generated from a password or pass phrase, the
-   string-to-key function for the particular encryption key type is
-   used, as specified in [@KCRYPTO]. The salt value and additional
-   parameters for the string-to-key function have default values
-   (specified by section 4 and by the encryption mechanism
-   specification, respectively) that may be overridden by pre-
-   authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-
-   ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of the
-   resulting key only, these values should not be changed for password-
-   based keys except when changing the principal's key.
-
-
-
-
-March 2003                                                     [Page 25]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   When the AS server is to include pre-authentication data in a KRB-
-   ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-INFO,
-   if the etype field of the client's AS-REQ lists at least one "newer"
-   encryption type.  Otherwise (when the etype field of the client's AS-
-   REQ does not list any "newer" encryption types) it MUST send both,
-   PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for each
-   enctype).  A "newer" enctype is any enctype first officially
-   specified concurrently with or subsequent to the issue of this RFC.
-   The enctypes DES, 3DES or RC4 and any defined in [RFC1510] are not
-   newer enctypes.
-
-   It is not possible to reliably generate a user's key given a pass
-   phrase without contacting the KDC, since it will not be known whether
-   alternate salt or parameter values are required.
-
-   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.
-
-   If the requested start time is absent, indicates a time in the past,
-   or is within the window of acceptable clock skew for the KDC and the
-   POSTDATE option has not been specified, then the start time of the
-   ticket is set to the authentication server's current time. If it
-   indicates a time in the future beyond the acceptable clock skew, but
-   the POSTDATED option has not been specified then the error
-   KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start
-   time is checked against the policy of the local realm (the
-   administrator might decide to prohibit certain types or ranges of
-   postdated tickets), and if acceptable, the ticket's start time is set
-   as requested and the INVALID flag is set in the new ticket. The
-   postdated ticket MUST be validated before use by presenting it to the
-   KDC after the start time has been reached.
-
-   The expiration time of the ticket will be set to the earlier of the
-   requested endtime and a time determined by local policy, possibly
-   determined using realm or principal specific factors. For example,
-   the expiration time MAY be set to the earliest of the following:
-
-      *  The expiration time (endtime) requested in the KRB_AS_REQ
-         message.
-
-      *  The ticket's start time plus the maximum allowable lifetime
-         associated with the client principal from the authentication
-         server's database.
-
-
-
-
-March 2003                                                     [Page 26]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      *  The ticket's start time plus the maximum allowable lifetime
-         associated with the server principal.
-
-      *  The ticket's start time plus the maximum lifetime set by the
-         policy of the local realm.
-
-   If the requested expiration time minus the start time (as determined
-   above) is less than a site-determined minimum lifetime, an error
-   message with code KDC_ERR_NEVER_VALID is returned. If the requested
-   expiration time for the ticket exceeds what was determined as above,
-   and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE'
-   flag is set in the new ticket, and the renew-till value is set as if
-   the 'RENEWABLE' option were requested (the field and option names are
-   described fully in section 5.4.1).
-
-   If the RENEWABLE option has been requested or if the RENEWABLE-OK
-   option has been set and a renewable ticket is to be issued, then the
-   renew-till field MAY be set to the earliest of:
-
-      *  Its requested value.
-
-      *  The start time of the ticket plus the minimum of the two
-         maximum renewable lifetimes associated with the principals'
-         database entries.
-
-      *  The start time of the ticket plus the maximum renewable
-         lifetime set by the policy of the local realm.
-
-   The flags field of the new ticket will have the following options set
-   if they have been requested and if the policy of the local realm
-   allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
-   If the new ticket is postdated (the start time is in the future), its
-   INVALID flag will also be set.
-
-   If all of the above succeed, the server will encrypt the ciphertext
-   part of the ticket using the encryption key extracted from the server
-   principal's record in the Kerberos database using the encryption type
-   associated with the server principal's key (this choice is NOT
-   affected by the etype field in the request). It then formats a
-   KRB_AS_REP message (see section 5.4.2), copying the addresses in the
-   request into the caddr of the response, placing any required pre-
-   authentication data into the padata of the response, and encrypts the
-   ciphertext part in the client's key using an acceptable encryption
-   method requested in the etype field of the request, or in some key
-   specified by pre-authentication mechanisms being used.
-
-3.1.4. Generation of KRB_ERROR message
-
-
-
-
-March 2003                                                     [Page 27]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   Several errors can occur, and the Authentication Server responds by
-   returning an error message, KRB_ERROR, to the client, with the error-
-   code and e-text fields set to appropriate values. The error message
-   contents and details are described in Section 5.9.1.
-
-3.1.5. Receipt of KRB_AS_REP message
-
-   If the reply message type is KRB_AS_REP, then the client verifies
-   that the cname and crealm fields in the cleartext portion of the
-   reply match what it requested. If any padata fields are present, they
-   may be used to derive the proper secret key to decrypt the message.
-   The client decrypts the encrypted part of the response using its
-   secret key, verifies that the nonce in the encrypted part matches the
-   nonce it supplied in its request (to detect replays). It also
-   verifies that the sname and srealm in the response match those in the
-   request (or are otherwise expected values), and that the host address
-   field is also correct. It then stores the ticket, session key, start
-   and expiration times, and other information for later use. The last-
-   req field (and the deprecated key-expiration field) from the
-   encrypted part of the response MAY be checked to notify the user of
-   impending key expiration. This enables the client program to suggest
-   remedial action, such as a password change.
-
-   Upon validation of the KRB_AS_REP message (by checking the returned
-   nonce against that sent in the KRB_AS_REQ message) the client knows
-   that the current time on the KDC is that read from the authtime field
-   of the encrypted part of the reply. The client can optionally use
-   this value for clock synchronization in subsequent messages by
-   recording with the ticket the difference (offset) between the
-   authtime value and the local clock. This offset can then be used by
-   the same user to adjust the time read from the system clock when
-   generating messages [DGT96].
-
-   This technique MUST be used when adjusting for clock skew instead of
-   directly changing the system clock because the KDC reply is only
-   authenticated to the user whose secret key was used, but not to the
-   system or workstation. If the clock were adjusted, an attacker
-   colluding with a user logging into a workstation could agree on a
-   password, resulting in a KDC reply that would be correctly validated
-   even though it did not originate from a KDC trusted by the
-   workstation.
-
-   Proper decryption of the KRB_AS_REP message is not sufficient for the
-   host to verify the identity of the user; the user and an attacker
-   could cooperate to generate a KRB_AS_REP format message which
-   decrypts properly but is not from the proper KDC. If the host wishes
-   to verify the identity of the user, it MUST require the user to
-   present application credentials which can be verified using a
-
-
-
-March 2003                                                     [Page 28]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   securely-stored secret key for the host. If those credentials can be
-   verified, then the identity of the user can be assured.
-
-3.1.6. Receipt of KRB_ERROR message
-
-   If the reply message type is KRB_ERROR, then the client interprets it
-   as an error and performs whatever application-specific tasks are
-   necessary to recover.
-
-3.2. The Client/Server Authentication Exchange
-
-                                Summary
-   Message direction                         Message type    Section
-   Client to Application server              KRB_AP_REQ      5.5.1
-   [optional] Application server to client   KRB_AP_REP or   5.5.2
-                                             KRB_ERROR       5.9.1
-
-   The client/server authentication (CS) exchange is used by network
-   applications to authenticate the client to the server and vice versa.
-   The client MUST have already acquired credentials for the server
-   using the AS or TGS exchange.
-
-3.2.1. The KRB_AP_REQ message
-
-   The KRB_AP_REQ contains authentication information which SHOULD be
-   part of the first message in an authenticated transaction. It
-   contains a ticket, an authenticator, and some additional bookkeeping
-   information (see section 5.5.1 for the exact format). The ticket by
-   itself is insufficient to authenticate a client, since tickets are
-   passed across the network in cleartext[8], so the authenticator is
-   used to prevent invalid replay of tickets by proving to the server
-   that the client knows the session key of the ticket and thus is
-   entitled to use the ticket. The KRB_AP_REQ message is referred to
-   elsewhere as the 'authentication header.'
-
-3.2.2. Generation of a KRB_AP_REQ message
-
-   When a client wishes to initiate authentication to a server, it
-   obtains (either through a credentials cache, the AS exchange, or the
-   TGS exchange) a ticket and session key for the desired service. The
-   client MAY re-use any tickets it holds until they expire. To use a
-   ticket the client constructs a new Authenticator from the system
-   time, its name, and optionally an application specific checksum, an
-   initial sequence number to be used in KRB_SAFE or KRB_PRIV messages,
-   and/or a session subkey to be used in negotiations for a session key
-   unique to this particular session.  Authenticators MAY NOT be re-used
-   and will be rejected if replayed to a server[9]. If a sequence number
-   is to be included, it SHOULD be randomly chosen so that even after
-
-
-
-March 2003                                                     [Page 29]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   many messages have been exchanged it is not likely to collide with
-   other sequence numbers in use.
-
-   The client MAY indicate a requirement of mutual authentication or the
-   use of a session-key based ticket (for user to user authentication -
-   see section 3.7) by setting the appropriate flag(s) in the ap-options
-   field of the message.
-
-   The Authenticator is encrypted in the session key and combined with
-   the ticket to form the KRB_AP_REQ message which is then sent to the
-   end server along with any additional application-specific
-   information.
-
-3.2.3. Receipt of KRB_AP_REQ message
-
-   Authentication is based on the server's current time of day (clocks
-   MUST be loosely synchronized), the authenticator, and the ticket.
-   Several errors are possible. If an error occurs, the server is
-   expected to reply to the client with a KRB_ERROR message. This
-   message MAY be encapsulated in the application protocol if its 'raw'
-   form is not acceptable to the protocol.  The format of error messages
-   is described in section 5.9.1.
-
-   The algorithm for verifying authentication information is as follows.
-   If the message type is not KRB_AP_REQ, the server returns the
-   KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket
-   in the KRB_AP_REQ is not one the server can use (e.g., it indicates
-   an old key, and the server no longer possesses a copy of the old
-   key), the KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION-
-   KEY flag is set in the ap-options field, it indicates to the server
-   that user-to-user authentication is in use, and that the ticket is
-   encrypted in the session key from the server's ticket-granting ticket
-   rather than in the server's secret key. See section 3.7 for a more
-   complete description of the affect of user to user authentication on
-   all messages in the Kerberos protocol.
-
-   Since it is possible for the server to be registered in multiple
-   realms, with different keys in each, the srealm field in the
-   unencrypted portion of the ticket in the KRB_AP_REQ is used to
-   specify which secret key the server should use to decrypt that
-   ticket. The KRB_AP_ERR_NOKEY error code is returned if the server
-   doesn't have the proper key to decipher the ticket.
-
-   The ticket is decrypted using the version of the server's key
-   specified by the ticket. If the decryption routines detect a
-   modification of the ticket (each encryption system MUST provide
-   safeguards to detect modified ciphertext; see section 6), the
-   KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that
-
-
-
-March 2003                                                     [Page 30]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   different keys were used to encrypt and decrypt).
-
-   The authenticator is decrypted using the session key extracted from
-   the decrypted ticket. If decryption shows it to have been modified,
-   the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of
-   the client from the ticket are compared against the same fields in
-   the authenticator.  If they don't match, the KRB_AP_ERR_BADMATCH
-   error is returned; this normally is caused by a client error or
-   attempted attack. The addresses in the ticket (if any) are then
-   searched for an address matching the operating-system reported
-   address of the client. If no match is found or the server insists on
-   ticket addresses but none are present in the ticket, the
-   KRB_AP_ERR_BADADDR error is returned. If the local (server) time and
-   the client time in the authenticator differ by more than the
-   allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is
-   returned.
-
-   Unless the application server provides its own suitable means to
-   protect against replay (for example, a challenge-response sequence
-   initiated by the server after authentication, or use of a server-
-   generated encryption subkey), the server MUST utilize a replay cache
-   to remember any authenticator presented within the allowable clock
-   skew. Careful analysis of the application protocol and implementation
-   is recommended before eliminating this cache. The replay cache will
-   store at least the server name, along with the client name, time and
-   microsecond fields from the recently-seen authenticators and if a
-   matching tuple is found, the KRB_AP_ERR_REPEAT error is returned
-   [10]. If a server loses track of authenticators presented within the
-   allowable clock skew, it MUST reject all requests until the clock
-   skew interval has passed, providing assurance that any lost or
-   replayed authenticators will fall outside the allowable clock skew
-   and can no longer be successfully replayed [11].
-
-   Implementation note: If a client generates multiple requests to the
-   KDC with the same timestamp, including the microsecond field, all but
-   the first of the requests received will be rejected as replays. This
-   might happen, for example, if the resolution of the client's clock is
-   too coarse.  Implementations SHOULD ensure that the timestamps are
-   not reused, possibly by incrementing the microseconds field in the
-   time stamp when the clock returns the same time for multiple
-   requests.
-
-   If multiple servers (for example, different services on one machine,
-   or a single service implemented on multiple machines) share a service
-   principal (a practice we do not recommend in general, but acknowledge
-   will be used in some cases), they should also share this replay
-   cache, or the application protocol should be designed so as to
-   eliminate the need for it. Note that this applies to all of the
-
-
-
-March 2003                                                     [Page 31]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   services, if any of the application protocols does not have replay
-   protection built in; an authenticator used with such a service could
-   later be replayed to a different service with the same service
-   principal but no replay protection, if the former doesn't record the
-   authenticator information in the common replay cache.
-
-   If a sequence number is provided in the authenticator, the server
-   saves it for later use in processing KRB_SAFE and/or KRB_PRIV
-   messages. If a subkey is present, the server either saves it for
-   later use or uses it to help generate its own choice for a subkey to
-   be returned in a KRB_AP_REP message.
-
-   The server computes the age of the ticket: local (server) time minus
-   the start time inside the Ticket. If the start time is later than the
-   current time by more than the allowable clock skew or if the INVALID
-   flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned.
-   Otherwise, if the current time is later than end time by more than
-   the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is
-   returned.
-
-   If all these checks succeed without an error, the server is assured
-   that the client possesses the credentials of the principal named in
-   the ticket and thus, the client has been authenticated to the server.
-
-   Passing these checks provides only authentication of the named
-   principal; it does not imply authorization to use the named service.
-   Applications MUST make a separate authorization decisions based upon
-   the authenticated name of the user, the requested operation, local
-   access control information such as that contained in a .k5login or
-   .k5users file, and possibly a separate distributed authorization
-   service.
-
-3.2.4. Generation of a KRB_AP_REP message
-
-   Typically, a client's request will include both the authentication
-   information and its initial request in the same message, and the
-   server need not explicitly reply to the KRB_AP_REQ. However, if
-   mutual authentication (not only authenticating the client to the
-   server, but also the server to the client) is being performed, the
-   KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options
-   field, and a KRB_AP_REP message is required in response. As with the
-   error message, this message MAY be encapsulated in the application
-   protocol if its "raw" form is not acceptable to the application's
-   protocol. The timestamp and microsecond field used in the reply MUST
-   be the client's timestamp and microsecond field (as provided in the
-   authenticator) [12]. If a sequence number is to be included, it
-   SHOULD be randomly chosen as described above for the authenticator. A
-   subkey MAY be included if the server desires to negotiate a different
-
-
-
-March 2003                                                     [Page 32]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   subkey. The KRB_AP_REP message is encrypted in the session key
-   extracted from the ticket.
-
-3.2.5. Receipt of KRB_AP_REP message
-
-   If a KRB_AP_REP message is returned, the client uses the session key
-   from the credentials obtained for the server [13] to decrypt the
-   message, and verifies that the timestamp and microsecond fields match
-   those in the Authenticator it sent to the server. If they match, then
-   the client is assured that the server is genuine. The sequence number
-   and subkey (if present) are retained for later use.
-
-3.2.6. Using the encryption key
-
-   After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
-   server share an encryption key which can be used by the application.
-   In some cases, the use of this session key will be implicit in the
-   protocol; in others the method of use must be chosen from several
-   alternatives. The 'true session key' to be used for KRB_PRIV,
-   KRB_SAFE, or other application-specific uses MAY be chosen by the
-   application based on the session key from the ticket and subkeys in
-   the KRB_AP_REP message and the authenticator [14]. To mitigate the
-   effect of failures in random number generation on the client it is
-   strongly encouraged that any key derived by an application for
-   subsequent use include the full key entropy derived from the KDC
-   generated session key carried in the ticket. We leave the protocol
-   negotiations of how to use the key (e.g. selecting an encryption or
-   checksum type) to the application programmer; the Kerberos protocol
-   does not constrain the implementation options, but an example of how
-   this might be done follows.
-
-   One way that an application may choose to negotiate a key to be used
-   for subsequent integrity and privacy protection is for the client to
-   propose a key in the subkey field of the authenticator. The server
-   can then choose a key using the proposed key from the client as
-   input, returning the new subkey in the subkey field of the
-   application reply. This key could then be used for subsequent
-   communication.
-
-   To make this example more concrete, if the communication patterns of
-   an application dictates the use of encryption modes of operation
-   incompatible with the encryption system used for the authenticator,
-   then a key compatible with the required encryption system may be
-   generated by either the client, the server, or collaboratively by
-   both and exchanged using the subkey field.  This generation might
-   involve the use of a random number as a pre-key, initially generated
-   by either party, which could then be encrypted using the session key
-   from the ticket, and the result exchanged and used for subsequent
-
-
-
-March 2003                                                     [Page 33]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   encryption. By encrypting the pre-key with the session key from the
-   ticket, randomness from the KDC generated key is assured of being
-   present in the negotiated key. Application developers must be careful
-   however, to use a means of introducing this entropy that does not
-   allow an attacker to learn the session key from the ticket if it
-   learns the key generated and used for subsequent communication. The
-   reader should note that this is only an example, and that an analysis
-   of the particular cryptosystem to be used, must be made before
-   deciding how to generate values for the subkey fields, and the key to
-   be used for subsequent communication.
-
-   With both the one-way and mutual authentication exchanges, the peers
-   should take care not to send sensitive information to each other
-   without proper assurances. In particular, applications that require
-   privacy or integrity SHOULD use the KRB_AP_REP response from the
-   server to client to assure both client and server of their peer's
-   identity. If an application protocol requires privacy of its
-   messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE
-   message (section 3.4) can be used to assure integrity.
-
-3.3. The Ticket-Granting Service (TGS) Exchange
-
-                             Summary
-         Message direction       Message type     Section
-         1. Client to Kerberos   KRB_TGS_REQ      5.4.1
-         2. Kerberos to client   KRB_TGS_REP or   5.4.2
-                                 KRB_ERROR        5.9.1
-
-   The TGS exchange between a client and the Kerberos Ticket-Granting
-   Server is initiated by a client when it wishes to obtain
-   authentication credentials for a given server (which might be
-   registered in a remote realm), when it wishes to renew or validate an
-   existing ticket, or when it wishes to obtain a proxy ticket. In the
-   first case, the client must already have acquired a ticket for the
-   Ticket-Granting Service using the AS exchange (the ticket-granting
-   ticket is usually obtained when a client initially authenticates to
-   the system, such as when a user logs in). The message format for the
-   TGS exchange is almost identical to that for the AS exchange.  The
-   primary difference is that encryption and decryption in the TGS
-   exchange does not take place under the client's key. Instead, the
-   session key from the ticket-granting ticket or renewable ticket, or
-   sub-session key from an Authenticator is used. As is the case for all
-   application servers, expired tickets are not accepted by the TGS, so
-   once a renewable or ticket-granting ticket expires, the client must
-   use a separate exchange to obtain valid tickets.
-
-   The TGS exchange consists of two messages: A request (KRB_TGS_REQ)
-   from the client to the Kerberos Ticket-Granting Server, and a reply
-
-
-
-March 2003                                                     [Page 34]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes
-   information authenticating the client plus a request for credentials.
-   The authentication information consists of the authentication header
-   (KRB_AP_REQ) which includes the client's previously obtained ticket-
-   granting, renewable, or invalid ticket.  In the ticket-granting
-   ticket and proxy cases, the request MAY include one or more of: a
-   list of network addresses, a collection of typed authorization data
-   to be sealed in the ticket for authorization use by the application
-   server, or additional tickets (the use of which are described later).
-   The TGS reply (KRB_TGS_REP) contains the requested credentials,
-   encrypted in the session key from the ticket-granting ticket or
-   renewable ticket, or if present, in the sub-session key from the
-   Authenticator (part of the authentication header). The KRB_ERROR
-   message contains an error code and text explaining what went wrong.
-   The KRB_ERROR message is not encrypted. The KRB_TGS_REP message
-   contains information which can be used to detect replays, and to
-   associate it with the message to which it replies. The KRB_ERROR
-   message also contains information which can be used to associate it
-   with the message to which it replies. The same comments about
-   integrity protection of KRB_ERROR messages mentioned in section 3.1
-   apply to the TGS exchange.
-
-3.3.1. Generation of KRB_TGS_REQ message
-
-   Before sending a request to the ticket-granting service, the client
-   MUST determine in which realm the application server is believed to
-   be registered [15]. If the client knows the service principal name
-   and realm and it does not already possess a ticket-granting ticket
-   for the appropriate realm, then one must be obtained. This is first
-   attempted by requesting a ticket-granting ticket for the destination
-   realm from a Kerberos server for which the client possesses a ticket-
-   granting ticket (using the KRB_TGS_REQ message recursively). The
-   Kerberos server MAY return a TGT for the desired realm in which case
-   one can proceed. Alternatively, the Kerberos server MAY return a TGT
-   for a realm which is 'closer' to the desired realm (further along the
-   standard hierarchical path between the client's realm and the
-   requested realm server's realm). It should be noted in this case that
-   misconfiguration of the Kerberos servers may cause loops in the
-   resulting authentication path, which the client should be careful to
-   detect and avoid.
-
-   If the Kerberos server returns a TGT for a 'closer' realm other than
-   the desired realm, the client MAY use local policy configuration to
-   verify that the authentication path used is an acceptable one.
-   Alternatively, a client MAY choose its own authentication path,
-   rather than relying on the Kerberos server to select one. In either
-   case, any policy or configuration information used to choose or
-   validate authentication paths, whether by the Kerberos server or
-
-
-
-March 2003                                                     [Page 35]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   client, MUST be obtained from a trusted source.
-
-   When a client obtains a ticket-granting ticket that is 'closer' to
-   the destination realm, the client MAY cache this ticket and reuse it
-   in future KRB-TGS exchanges with services in the 'closer' realm.
-   However, if the client were to obtain a ticket-granting ticket for
-   the 'closer' realm by starting at the initial KDC rather than as part
-   of obtaining another ticket, then a shorter path to the 'closer'
-   realm might be used. This shorter path may be desirable because fewer
-   intermediate KDCs would know the session key of the ticket involved.
-   For this reason, clients SHOULD evaluate whether they trust the
-   realms transited in obtaining the 'closer' ticket when making a
-   decision to use the ticket in future.
-
-   Once the client obtains a ticket-granting ticket for the appropriate
-   realm, it determines which Kerberos servers serve that realm, and
-   contacts one. The list might be obtained through a configuration file
-   or network service or it MAY be generated from the name of the realm;
-   as long as the secret keys exchanged by realms are kept secret, only
-   denial of service results from using a false Kerberos server.
-
-   (This paragraph changed) As in the AS exchange, the client MAY
-   specify a number of options in the KRB_TGS_REQ message. One of these
-   options is the ENC-TKT-IN-SKEY option used for user-to-user
-   authentication. An overview of user to user authentication can be
-   found in section 3.7. When generating the KRB_TGS_REQ message, this
-   option indicates that the client is including a ticket-granting
-   ticket obtained from the application server in the additional tickets
-   field of the request and that the KDC SHOULD encrypt the ticket for
-   the application server using the session key from this additional
-   ticket, instead of using a server key from the principal database.
-
-   The client prepares the KRB_TGS_REQ message, providing an
-   authentication header as an element of the padata field, and
-   including the same fields as used in the KRB_AS_REQ message along
-   with several optional fields: the enc-authorizatfion-data field for
-   application server use and additional tickets required by some
-   options.
-
-   In preparing the authentication header, the client can select a sub-
-   session key under which the response from the Kerberos server will be
-   encrypted [16]. If the sub-session key is not specified, the session
-   key from the ticket-granting ticket will be used. If the enc-
-   authorization-data is present, it MUST be encrypted in the sub-
-   session key, if present, from the authenticator portion of the
-   authentication header, or if not present, using the session key from
-   the ticket-granting ticket.
-
-
-
-
-March 2003                                                     [Page 36]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   Once prepared, the message is sent to a Kerberos server for the
-   destination realm.
-
-3.3.2. Receipt of KRB_TGS_REQ message
-
-   The KRB_TGS_REQ message is processed in a manner similar to the
-   KRB_AS_REQ message, but there are many additional checks to be
-   performed. First, the Kerberos server MUST determine which server the
-   accompanying ticket is for and it MUST select the appropriate key to
-   decrypt it. For a normal KRB_TGS_REQ message, it will be for the
-   ticket granting service, and the TGS's key will be used. If the TGT
-   was issued by another realm, then the appropriate inter-realm key
-   MUST be used. If the accompanying ticket is not a ticket-granting
-   ticket for the current realm, but is for an application server in the
-   current realm, the RENEW, VALIDATE, or PROXY options are specified in
-   the request, and the server for which a ticket is requested is the
-   server named in the accompanying ticket, then the KDC will decrypt
-   the ticket in the authentication header using the key of the server
-   for which it was issued. If no ticket can be found in the padata
-   field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
-
-   Once the accompanying ticket has been decrypted, the user-supplied
-   checksum in the Authenticator MUST be verified against the contents
-   of the request, and the message rejected if the checksums do not
-   match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum
-   is not keyed or not collision-proof (with an error code of
-   KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the
-   KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data
-   are present, they are decrypted using the sub-session key from the
-   Authenticator.
-
-   If any of the decryptions indicate failed integrity checks, the
-   KRB_AP_ERR_BAD_INTEGRITY error is returned.
-
-   As discussed in section 3.1.2, the KDC MUST send a valid KRB_TGS_REP
-   message if it receives a KRB_TGS_REQ message identical to one it has
-   recently processed. However, if the authenticator is a replay, but
-   the rest of the request is not identical, then the KDC SHOULD return
-   KRB_AP_ERR_REPEAT.
-
-3.3.3. Generation of KRB_TGS_REP message
-
-   The KRB_TGS_REP message shares its format with the KRB_AS_REP
-   (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The
-   detailed specification is in section 5.4.2.
-
-   The response will include a ticket for the requested server or for a
-   ticket granting server of an intermediate KDC to be contacted to
-
-
-
-March 2003                                                     [Page 37]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   obtain the requested ticket. The Kerberos database is queried to
-   retrieve the record for the appropriate server (including the key
-   with which the ticket will be encrypted). If the request is for a
-   ticket-granting ticket for a remote realm, and if no key is shared
-   with the requested realm, then the Kerberos server will select the
-   realm 'closest' to the requested realm with which it does share a
-   key, and use that realm instead. If the requested server cannot be
-   found in the TGS database, then a TGT for another trusted realm MAY
-   be returned instead of a ticket for the service. This TGT is a
-   referral mechanism to cause the client to retry the request to the
-   realm of the TGT.  These are the only cases where the response for
-   the KDC will be for a different server than that requested by the
-   client.
-
-   By default, the address field, the client's name and realm, the list
-   of transited realms, the time of initial authentication, the
-   expiration time, and the authorization data of the newly-issued
-   ticket will be copied from the ticket-granting ticket (TGT) or
-   renewable ticket. If the transited field needs to be updated, but the
-   transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error is
-   returned.
-
-   If the request specifies an endtime, then the endtime of the new
-   ticket is set to the minimum of (a) that request, (b) the endtime
-   from the TGT, and (c) the starttime of the TGT plus the minimum of
-   the maximum life for the application server and the maximum life for
-   the local realm (the maximum life for the requesting principal was
-   already applied when the TGT was issued). If the new ticket is to be
-   a renewal, then the endtime above is replaced by the minimum of (a)
-   the value of the renew_till field of the ticket and (b) the starttime
-   for the new ticket plus the life (endtime-starttime) of the old
-   ticket.
-
-   If the FORWARDED option has been requested, then the resulting ticket
-   will contain the addresses specified by the client. This option will
-   only be honored if the FORWARDABLE flag is set in the TGT. The PROXY
-   option is similar; the resulting ticket will contain the addresses
-   specified by the client. It will be honored only if the PROXIABLE
-   flag in the TGT is set. The PROXY option will not be honored on
-   requests for additional ticket-granting tickets.
-
-   If the requested start time is absent, indicates a time in the past,
-   or is within the window of acceptable clock skew for the KDC and the
-   POSTDATE option has not been specified, then the start time of the
-   ticket is set to the authentication server's current time. If it
-   indicates a time in the future beyond the acceptable clock skew, but
-   the POSTDATED option has not been specified or the MAY-POSTDATE flag
-   is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is
-
-
-
-March 2003                                                     [Page 38]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   returned. Otherwise, if the ticket-granting ticket has the MAY-
-   POSTDATE flag set, then the resulting ticket will be postdated and
-   the requested starttime is checked against the policy of the local
-   realm. If acceptable, the ticket's start time is set as requested,
-   and the INVALID flag is set. The postdated ticket MUST be validated
-   before use by presenting it to the KDC after the starttime has been
-   reached. However, in no case may the starttime, endtime, or renew-
-   till time of a newly-issued postdated ticket extend beyond the renew-
-   till time of the ticket-granting ticket.
-
-   If the ENC-TKT-IN-SKEY option has been specified and an additional
-   ticket has been included in the request, it indicates that the client
-   is using user- to-user authentication to prove its identity to a
-   server that does not have access to a persistent key. Section 3.7
-   describes the affect of this option on the entire Kerberos protocol.
-   When generating the KRB_TGS_REP message, this option in the
-   KRB_TGS_REQ message tells the KDC to decrypt the additional ticket
-   using the key for the server to which the additional ticket was
-   issued and verify that it is a ticket-granting ticket. If the name of
-   the requested server is missing from the request, the name of the
-   client in the additional ticket will be used. Otherwise the name of
-   the requested server will be compared to the name of the client in
-   the additional ticket and if different, the request will be rejected.
-   If the request succeeds, the session key from the additional ticket
-   will be used to encrypt the new ticket that is issued instead of
-   using the key of the server for which the new ticket will be used.
-
-   If the name of the server in the ticket that is presented to the KDC
-   as part of the authentication header is not that of the ticket-
-   granting server itself, the server is registered in the realm of the
-   KDC, and the RENEW option is requested, then the KDC will verify that
-   the RENEWABLE flag is set in the ticket, that the INVALID flag is not
-   set in the ticket, and that the renew_till time is still in the
-   future. If the VALIDATE option is requested, the KDC will check that
-   the starttime has passed and the INVALID flag is set. If the PROXY
-   option is requested, then the KDC will check that the PROXIABLE flag
-   is set in the ticket. If the tests succeed, and the ticket passes the
-   hotlist check described in the next section, the KDC will issue the
-   appropriate new ticket.
-
-   The ciphertext part of the response in the KRB_TGS_REP message is
-   encrypted in the sub-session key from the Authenticator, if present,
-   or the session key from the ticket-granting ticket. It is not
-   encrypted using the client's secret key. Furthermore, the client's
-   key's expiration date and the key version number fields are left out
-   since these values are stored along with the client's database
-   record, and that record is not needed to satisfy a request based on a
-   ticket-granting ticket.
-
-
-
-March 2003                                                     [Page 39]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-3.3.3.1. Checking for revoked tickets
-
-   Whenever a request is made to the ticket-granting server, the
-   presented ticket(s) is(are) checked against a hot-list of tickets
-   which have been canceled. This hot-list might be implemented by
-   storing a range of issue timestamps for 'suspect tickets'; if a
-   presented ticket had an authtime in that range, it would be rejected.
-   In this way, a stolen ticket-granting ticket or renewable ticket
-   cannot be used to gain additional tickets (renewals or otherwise)
-   once the theft has been reported to the KDC for the realm in which
-   the server resides. Any normal ticket obtained before it was reported
-   stolen will still be valid (because they require no interaction with
-   the KDC), but only until their normal expiration time. If TGT's have
-   been issued for cross-realm authentication, use of the cross-realm
-   TGT will not be affected unless the hot-list is propagated to the
-   KDCs for the realms for which such cross-realm tickets were issued.
-
-3.3.3.2. Encoding the transited field
-
-   If the identity of the server in the TGT that is presented to the KDC
-   as part of the authentication header is that of the ticket-granting
-   service, but the TGT was issued from another realm, the KDC will look
-   up the inter-realm key shared with that realm and use that key to
-   decrypt the ticket. If the ticket is valid, then the KDC will honor
-   the request, subject to the constraints outlined above in the section
-   describing the AS exchange.  The realm part of the client's identity
-   will be taken from the ticket-granting ticket. The name of the realm
-   that issued the ticket-granting ticket, if it is not the realm of the
-   client principal, will be added to the transited field of the ticket
-   to be issued. This is accomplished by reading the transited field
-   from the ticket-granting ticket (which is treated as an unordered set
-   of realm names), adding the new realm to the set, then constructing
-   and writing out its encoded (shorthand) form (this may involve a
-   rearrangement of the existing encoding).
-
-   Note that the ticket-granting service does not add the name of its
-   own realm. Instead, its responsibility is to add the name of the
-   previous realm.  This prevents a malicious Kerberos server from
-   intentionally leaving out its own name (it could, however, omit other
-   realms' names).
-
-   The names of neither the local realm nor the principal's realm are to
-   be included in the transited field. They appear elsewhere in the
-   ticket and both are known to have taken part in authenticating the
-   principal. Since the endpoints are not included, both local and
-   single-hop inter-realm authentication result in a transited field
-   that is empty.
-
-
-
-
-March 2003                                                     [Page 40]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   Because the name of each realm transited is added to this field, it
-   might potentially be very long. To decrease the length of this field,
-   its contents are encoded. The initially supported encoding is
-   optimized for the normal case of inter-realm communication: a
-   hierarchical arrangement of realms using either domain or X.500 style
-   realm names. This encoding (called DOMAIN-X500-COMPRESS) is now
-   described.
-
-   Realm names in the transited field are separated by a ",". The ",",
-   "\", trailing "."s, and leading spaces (" ") are special characters,
-   and if they are part of a realm name, they MUST be quoted in the
-   transited field by preceding them with a "\".
-
-   A realm name ending with a "." is interpreted as being prepended to
-   the previous realm. For example, we can encode traversal of EDU,
-   MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
-
-      "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
-
-   Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points,
-   that they would not be included in this field, and we would have:
-
-      "EDU,MIT.,WASHINGTON.EDU"
-
-   A realm name beginning with a "/" is interpreted as being appended to
-   the previous realm.  For the purpose of appending, the realm
-   preceding the first listed realm is considered to be the null realm
-   ("").  If a realm name beginning with a "/" is to stand by itself,
-   then it SHOULD be preceded by a space (" "). For example, we can
-   encode traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as:
-
-      "/COM,/HP,/APOLLO, /COM/DEC".
-
-   Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints,
-   they would not be included in this field, and we would have:
-
-      "/COM,/HP"
-
-   A null subfield preceding or following a "," indicates that all
-   realms between the previous realm and the next realm have been
-   traversed.  For the purpose of interpreting null subfields, the
-   client's realm is considered to precede those in the transited field,
-   and the server's realm is considered to follow them.  Thus, "," means
-   that all realms along the path between the client and the server have
-   been traversed. ",EDU, /COM," means that all realms from the client's
-   realm up to EDU (in a domain style hierarchy) have been traversed,
-   and that everything from /COM down to the server's realm in an X.500
-   style has also been traversed. This could occur if the EDU realm in
-
-
-
-March 2003                                                     [Page 41]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   one hierarchy shares an inter-realm key directly with the /COM realm
-   in another hierarchy.
-
-3.3.4. Receipt of KRB_TGS_REP message
-
-   When the KRB_TGS_REP is received by the client, it is processed in
-   the same manner as the KRB_AS_REP processing described above. The
-   primary difference is that the ciphertext part of the response must
-   be decrypted using the sub-session key from the Authenticator, if it
-   was specified in the request, or the session key from the ticket-
-   granting ticket, rather than the client's secret key. The server name
-   returned in the reply is the true principal name of the service.
-
-3.4. The KRB_SAFE Exchange
-
-   The KRB_SAFE message MAY be used by clients requiring the ability to
-   detect modifications of messages they exchange. It achieves this by
-   including a keyed collision-proof checksum of the user data and some
-   control information. The checksum is keyed with an encryption key
-   (usually the last key negotiated via subkeys, or the session key if
-   no negotiation has occurred).
-
-3.4.1. Generation of a KRB_SAFE message
-
-   When an application wishes to send a KRB_SAFE message, it collects
-   its data and the appropriate control information and computes a
-   checksum over them.  The checksum algorithm should be the keyed
-   checksum mandated to be implemented along with the crypto system used
-   for the sub-session or session key. The checksum is generated using
-   the sub-session key if present, and the session key. Some
-   implementations use a different checksum algorithm for the KRB_SAFE
-   messages but doing so in a interoperable manner is not always
-   possible.
-
-   Implementations SHOULD accept any checksum algorithm they implement
-   that both have adequate security and that have keys compatible with
-   the sub-session or session key. Unkeyed or non-collision-proof
-   checksums are not suitable for this use.
-
-   The control information for the KRB_SAFE message includes both a
-   timestamp and a sequence number. The designer of an application using
-   the KRB_SAFE message MUST choose at least one of the two mechanisms.
-   This choice SHOULD be based on the needs of the application protocol.
-
-   Sequence numbers are useful when all messages sent will be received
-   by one's peer. Connection state is presently required to maintain the
-   session key, so maintaining the next sequence number should not
-   present an additional problem.
-
-
-
-March 2003                                                     [Page 42]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   If the application protocol is expected to tolerate lost messages
-   without them being resent, the use of the timestamp is the
-   appropriate replay detection mechanism. Using timestamps is also the
-   appropriate mechanism for multi-cast protocols where all of one's
-   peers share a common sub-session key, but some messages will be sent
-   to a subset of one's peers.
-
-   After computing the checksum, the client then transmits the
-   information and checksum to the recipient in the message format
-   specified in section 5.6.1.
-
-3.4.2. Receipt of KRB_SAFE message
-
-   When an application receives a KRB_SAFE message, it verifies it as
-   follows.  If any error occurs, an error code is reported for use by
-   the application.
-
-   The message is first checked by verifying that the protocol version
-   and type fields match the current version and KRB_SAFE, respectively.
-   A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
-   error. The application verifies that the checksum used is a
-   collision-proof keyed checksum that uses keys compatible with the
-   sub-session or session key as appropriate (or with the application
-   key derived from the session or sub-session keys), and if it is not,
-   a KRB_AP_ERR_INAPP_CKSUM error is generated.  The sender's address
-   MUST be included in the control information; the recipient verifies
-   that the operating system's report of the sender's address matches
-   the sender's address in the message, and (if a recipient address is
-   specified or the recipient requires an address) that one of the
-   recipient's addresses appears as the recipient's address in the
-   message. To work with network address translation, senders MAY use
-   the directional address type specified in section 8.1 for the sender
-   address and not include recipient addresses. A failed match for
-   either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp
-   and usec and/or the sequence number fields are checked. If timestamp
-   and usec are expected and not present, or they are present but not
-   current, the KRB_AP_ERR_SKEW error is generated. If the server name,
-   along with the client name, time and microsecond fields from the
-   Authenticator match any recently-seen (sent or received) such tuples,
-   the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence
-   number is included, or a sequence number is expected but not present,
-   the KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp
-   and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error
-   is generated. Finally, the checksum is computed over the data and
-   control information, and if it doesn't match the received checksum, a
-   KRB_AP_ERR_MODIFIED error is generated.
-
-   If all the checks succeed, the application is assured that the
-
-
-
-March 2003                                                     [Page 43]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   message was generated by its peer and was not modified in transit.
-
-3.5. The KRB_PRIV Exchange
-
-   The KRB_PRIV message MAY be used by clients requiring confidentiality
-   and the ability to detect modifications of exchanged messages. It
-   achieves this by encrypting the messages and adding control
-   information.
-
-3.5.1. Generation of a KRB_PRIV message
-
-   When an application wishes to send a KRB_PRIV message, it collects
-   its data and the appropriate control information (specified in
-   section 5.7.1) and encrypts them under an encryption key (usually the
-   last key negotiated via subkeys, or the session key if no negotiation
-   has occurred). As part of the control information, the client MUST
-   choose to use either a timestamp or a sequence number (or both); see
-   the discussion in section 3.4.1 for guidelines on which to use. After
-   the user data and control information are encrypted, the client
-   transmits the ciphertext and some 'envelope' information to the
-   recipient.
-
-3.5.2. Receipt of KRB_PRIV message
-
-   When an application receives a KRB_PRIV message, it verifies it as
-   follows.  If any error occurs, an error code is reported for use by
-   the application.
-
-   The message is first checked by verifying that the protocol version
-   and type fields match the current version and KRB_PRIV, respectively.
-   A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
-   error. The application then decrypts the ciphertext and processes the
-   resultant plaintext. If decryption shows the data to have been
-   modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated.
-
-   The sender's address MUST be included in the control information; the
-   recipient verifies that the operating system's report of the sender's
-   address matches the sender's address in the message.  If a recipient
-   address is specified or the recipient requires an address then one of
-   the recipient's addresses MUST also appear as the recipient's address
-   in the message.  Where a sender's or receiver's address might not
-   otherwise match the address in a message because of network address
-   translation, an application MAY be written to use addresses of the
-   directional address type in place of the actual network address.
-
-   A failed match for either case generates a KRB_AP_ERR_BADADDR error.
-   To work with network address translation, implementations MAY use the
-   directional address type defined in section 7.1 for the sender
-
-
-
-March 2003                                                     [Page 44]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   address and include no recipient address. Then the timestamp and usec
-   and/or the sequence number fields are checked. If timestamp and usec
-   are expected and not present, or they are present but not current,
-   the KRB_AP_ERR_SKEW error is generated. If the server name, along
-   with the client name, time and microsecond fields from the
-   Authenticator match any recently-seen such tuples, the
-   KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number
-   is included, or a sequence number is expected but not present, the
-   KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and
-   usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error is
-   generated.
-
-   If all the checks succeed, the application can assume the message was
-   generated by its peer, and was securely transmitted (without
-   intruders able to see the unencrypted contents).
-
-3.6. The KRB_CRED Exchange
-
-   The KRB_CRED message MAY be used by clients requiring the ability to
-   send Kerberos credentials from one host to another. It achieves this
-   by sending the tickets together with encrypted data containing the
-   session keys and other information associated with the tickets.
-
-3.6.1. Generation of a KRB_CRED message
-
-   When an application wishes to send a KRB_CRED message it first (using
-   the KRB_TGS exchange) obtains credentials to be sent to the remote
-   host. It then constructs a KRB_CRED message using the ticket or
-   tickets so obtained, placing the session key needed to use each
-   ticket in the key field of the corresponding KrbCredInfo sequence of
-   the encrypted part of the KRB_CRED message.
-
-   Other information associated with each ticket and obtained during the
-   KRB_TGS exchange is also placed in the corresponding KrbCredInfo
-   sequence in the encrypted part of the KRB_CRED message. The current
-   time and, if specifically required by the application (and
-   communicated from the recipient to the sender by application specific
-   means) the nonce, s-address, and r-address fields, are placed in the
-   encrypted part of the KRB_CRED message which is then encrypted under
-   an encryption key previously exchanged in the KRB_AP exchange
-   (usually the last key negotiated via subkeys, or the session key if
-   no negotiation has occurred).
-
-   Implementation note: When constructing a KRB_CRED message for
-   inclusion in a GSSAPI initial context token, the MIT implementation
-   of Kerberos will not encrypt the KRB_CRED message if the session key
-   is a DES or triple DES key.  For interoperability with MIT, the
-   Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI
-
-
-
-March 2003                                                     [Page 45]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   token if it is using a DES session key. Starting at version 1.2.5,
-   MIT Kerberos can receive and decode either encrypted or unencrypted
-   KRB_CRED tokens in the GSSAPI exchange. The Heimdal implementation of
-   Kerberos can also accept either encrypted or unencrypted KRB_CRED
-   messages. Since the KRB_CRED message in a GSSAPI token is encrypted
-   in the authenticator, the MIT behavior does not present a security
-   problem, although it is a violation of the Kerberos specification.
-
-3.6.2. Receipt of KRB_CRED message
-
-   When an application receives a KRB_CRED message, it verifies it. If
-   any error occurs, an error code is reported for use by the
-   application. The message is verified by checking that the protocol
-   version and type fields match the current version and KRB_CRED,
-   respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or
-   KRB_AP_ERR_MSG_TYPE error. The application then decrypts the
-   ciphertext and processes the resultant plaintext. If decryption shows
-   the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
-   generated.
-
-   If present or required, the recipient MAY verify that the operating
-   system's report of the sender's address matches the sender's address
-   in the message, and that one of the recipient's addresses appears as
-   the recipient's address in the message. The address check does not
-   provide any added security, since the address if present has already
-   been checked in the KRB_AP_REQ message and there is not any benefit
-   to be gained by an attacker in reflecting a KRB_CRED message back to
-   its originator. Thus, the recipient MAY ignore the address even if
-   present in order to work better in NAT environments. A failed match
-   for either case generates a KRB_AP_ERR_BADADDR error. Recipients MAY
-   skip the address check as the KRB_CRED message cannot generally be
-   reflected back to the originator.  The timestamp and usec fields (and
-   the nonce field if required) are checked next. If the timestamp and
-   usec are not present, or they are present but not current, the
-   KRB_AP_ERR_SKEW error is generated.
-
-   If all the checks succeed, the application stores each of the new
-   tickets in its credentials cache together with the session key and
-   other information in the corresponding KrbCredInfo sequence from the
-   encrypted part of the KRB_CRED message.
-
-3.7. User to User Authentication Exchanges
-
-   User to User authentication provides a method to perform
-   authentication when the verifier does not have a access to long term
-   service key. This might be the case when running a server (for
-   example a window server) as a user on a workstation. In such cases,
-   the server may have access to the ticket-granting ticket obtained
-
-
-
-March 2003                                                     [Page 46]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   when the user logged in to the workstation, but because the server is
-   running as an unprivileged user it might not have access to system
-   keys. Similar situations may arise when running peer-to-peer
-   applications.
-
-                             Summary
-       Message direction                    Message type     Sections
-       0. Message from application server   Not Specified
-       1. Client to Kerberos                KRB_TGS_REQ      3.3 + 5.4.1
-       2. Kerberos to client                KRB_TGS_REP or   3.3 + 5.4.2
-                                            KRB_ERROR        5.9.1
-       3. Client to Application server      KRB_AP_REQ       3.2 + 5.5.1
-
-   To address this problem, the Kerberos protocol allows the client to
-   request that the ticket issued by the KDC be encrypted using a
-   session key from a ticket-granting ticket issued to the party that
-   will verify the authentication.  This ticket-granting ticket must be
-   obtained from the verifier by means of an exchange external to the
-   Kerberos protocol, usually as part of the application protocol. This
-   message is shown in the summary above as message 0. Note that because
-   the ticket-granting ticket is encrypted in the KDC's secret key, it
-   can not be used for authentication without posession of the
-   corresponding secret key.  Furthermore, because the verifier does not
-   reveal the corresponding secret key, providing a copy of the
-   verifier's ticket-granting ticket does not allow impersonation of the
-   verifier.
-
-   Message 0 in the table above represents an application specific
-   negotation between the client and server, at the end of which both
-   have determined that they will use user to user authentication and
-   the client has obtained the server's TGT.
-
-   Next, the client includes the server's TGT as an additional ticket in
-   its KRB_TGS_REQ request to the KDC (message 1 in the table above) and
-   specifyies the ENC-TKT-IN-SKEY option in its request.
-
-   If validated according to the instructions in 3.3.3, the application
-   ticket returned to the client (message 2 in the table above) will be
-   encrypted using the session key from the additional ticket and the
-   client will note this when it uses or stores the application ticket.
-
-   When contacting the server using a ticket obtained for user to user
-   authentication (message 3 in the table above), the client MUST
-   specify the USE-SESSION-KEY flag in the ap-options field. This tells
-   the application server to use the session key associated with its
-   ticket-granting ticket to decrypt the server ticket provided in the
-   application request.
-
-
-
-
-March 2003                                                     [Page 47]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-4. Encryption and Checksum Specifications
-
-   The Kerberos protocols described in this document are designed to
-   encrypt messages of arbitrary sizes, using stream or block encryption
-   ciphers.  Encryption is used to prove the identities of the network
-   entities participating in message exchanges. The Key Distribution
-   Center for each realm is trusted by all principals registered in that
-   realm to store a secret key in confidence. Proof of knowledge of this
-   secret key is used to verify the authenticity of a principal.
-
-   The KDC uses the principal's secret key (in the AS exchange) or a
-   shared session key (in the TGS exchange) to encrypt responses to
-   ticket requests; the ability to obtain the secret key or session key
-   implies the knowledge of the appropriate keys and the identity of the
-   KDC. The ability of a principal to decrypt the KDC response and
-   present a Ticket and a properly formed Authenticator (generated with
-   the session key from the KDC response) to a service verifies the
-   identity of the principal; likewise the ability of the service to
-   extract the session key from the Ticket and prove its knowledge
-   thereof in a response verifies the identity of the service.
-
-   [@KCRYPTO] defines a framework for defining encryption and checksum
-   mechanisms for use with Kerberos. It also defines several such
-   mechanisms, and more may be added in future updates to that document.
-
-   The string-to-key operation provided by [@KCRYPTO] is used to produce
-   a long-term key for a principal (generally for a user). The default
-   salt string, if none is provided via pre-authentication data, is the
-   concatenation of the principal's realm and name components, in order,
-   with no separators.  Unless otherwise indicated, the default string-
-   to-key opaque parameter set as defined in [@KCRYPTO] is used.
-
-   Encrypted data, keys and checksums are transmitted using the
-   EncryptedData, EncryptionKey and Checksum data objects defined in
-   section 5.2.9. The encryption, decryption, and checksum operations
-   described in this document use the corresponding encryption,
-   decryption, and get_mic operations described in [@KCRYPTO], with
-   implicit "specific key" generation using the "key usage" values
-   specified in the description of each EncryptedData or Checksum object
-   to vary the key for each operation. Note that in some cases, the
-   value to be used is dependent on the method of choosing the key or
-   the context of the message.
-
-   Key usages are unsigned 32 bit integers; zero is not permitted. The
-   key usage values for encrypting or checksumming Kerberos messages are
-   indicated in section 5 along with the message definitions. Key usage
-   values 512-1023 are reserved for uses internal to a Kerberos
-   implementation. (For example, seeding a pseudo-random number
-
-
-
-March 2003                                                     [Page 48]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   generator with a value produced by encrypting something with a
-   session key and a key usage value not used for any other purpose.)
-   Key usage values between 1024 and 2047 (inclusive) are reserved for
-   application use; applications SHOULD use even values for encryption
-   and odd values for checksums within this range. Key usage values are
-   also summarized in a table in section 7.5.1.
-
-   There might exist other documents which define protocols in terms of
-   the RFC1510 encryption types or checksum types. Such documents would
-   not know about key usages. In order that these specifications
-   continue to be meaningful until they are updated, if not key usage
-   values are specified then key usages 1024 and 1025 must be used to
-   derive keys for encryption and checksums, respectively (this does not
-   apply to protocols that do their own encryption independent of this
-   framework, directly using the key resulting from the Kerberos
-   authentication exchange.) New protocols defined in terms of the
-   Kerberos encryption and checksum types SHOULD use their own key usage
-   values.
-
-   Unless otherwise indicated, no cipher state chaining is done from one
-   encryption operation to another.
-
-   Implementation note: While not recommended, some application
-   protocols will continue to use the key data directly, even if only in
-   currently existing protocol specifications. An implementation
-   intended to support general Kerberos applications may therefore need
-   to make key data available, as well as the attributes and operations
-   described in [@KCRYPTO].  One of the more common reasons for directly
-   performing encryption is direct control over negotiation and
-   selection of a "sufficiently strong" encryption algorithm (in the
-   context of a given application). While Kerberos does not directly
-   provide a facility for negotiating encryption types between the
-   application client and server, there are approaches for using
-   Kerberos to facilitate this negotiation - for example, a client may
-   request only "sufficiently strong" session key types from the KDC and
-   expect that any type returned by the KDC will be understood and
-   supported by the application server.
-
-5. Message Specifications
-
-   NOTE: The ASN.1 collected here should be identical to the contents of
-   Appendix A. In case of conflict, the contents of Appendix A shall
-   take precedence.
-
-   The Kerberos protocol is defined here in terms of Abstract Syntax
-   Notation One (ASN.1) [X680], which provides a syntax for specifying
-   both the abstract layout of protocol messages as well as their
-   encodings. Implementors not utilizing an existing ASN.1 compiler or
-
-
-
-March 2003                                                     [Page 49]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   support library are cautioned to thoroughly understand the actual
-   ASN.1 specification to ensure correct implementation behavior, as
-   there is more complexity in the notation than is immediately obvious,
-   and some tutorials and guides to ASN.1 are misleading or erroneous.
-
-   Note that in several places, there have been changes here from RFC
-   1510 that change the abstract types. This is in part to address
-   widespread assumptions that various implementors have made, in some
-   cases resulting in unintentional violations of the ASN.1 standard.
-   These are clearly flagged where they occur. The differences between
-   the abstract types in RFC 1510 and abstract types in this document
-   can cause incompatible encodings to be emitted when certain encoding
-   rules, e.g. the Packed Encoding Rules (PER), are used. This
-   theoretical incompatibility should not be relevant for Kerberos,
-   since Kerberos explicitly specifies the use of the Distinguished
-   Encoding Rules (DER). It might be an issue for protocols wishing to
-   use Kerberos types with other encoding rules. (This practice is not
-   recommended.) With very few exceptions (most notably the usages of
-   BIT STRING), the encodings resulting from using the DER remain
-   identical between the types defined in RFC 1510 and the types defined
-   in this document.
-
-   The type definitions in this section assume an ASN.1 module
-   definition of the following form:
-
-   KerberosV5Spec2 {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2) modules(4) krb5spec2(2)
-   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-   -- rest of definitions here
-
-   END
-
-   This specifies that the tagging context for the module will be
-   explicit and non-automatic.
-
-   Note that in some other publications [RFC1510] [RFC1964], the "dod"
-   portion of the object identifier is erroneously specified as having
-   the value "5".  In the case of RFC 1964, use of the "correct" OID
-   value would result in a change in the wire protocol; therefore, it
-   remains unchanged for now.
-
-   Note that elsewhere in this document, nomenclature for various
-   message types is inconsistent, but seems to largely follow C language
-   conventions, including use of underscore (_) characters and all-caps
-   spelling of names intended to be numeric constants. Also, in some
-   places, identifiers (especially ones refering to constants) are
-
-
-
-March 2003                                                     [Page 50]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   written in all-caps in order to distinguish them from surrounding
-   explanatory text.
-
-   The ASN.1 notation does not permit underscores in identifiers, so in
-   actual ASN.1 definitions, underscores are replaced with hyphens (-).
-   Additionally, structure member names and defined values in ASN.1 MUST
-   begin with a lowercase letter, while type names MUST begin with an
-   uppercase letter.
-
-5.1. Specific Compatibility Notes on ASN.1
-
-   For compatibility purposes, implementors should heed the following
-   specific notes regarding the use of ASN.1 in Kerberos. These notes do
-   not describe deviations from standard usage of ASN.1. The purpose of
-   these notes is to instead describe some historical quirks and non-
-   compliance of various implementations, as well as historical
-   ambiguities, which, while being valid ASN.1, can lead to confusion
-   during implementation.
-
-5.1.1. ASN.1 Distinguished Encoding Rules
-
-   The encoding of Kerberos protocol messages shall obey the
-   Distinguished Encoding Rules (DER) of ASN.1 as described in [X690].
-   Some implementations (believed to be primarly ones derived from DCE
-   1.1 and earlier) are known to use the more general Basic Encoding
-   Rules (BER); in particular, these implementations send indefinite
-   encodings of lengths. Implementations MAY accept such encodings in
-   the interests of backwards compatibility, though implementors are
-   warned that decoding fully-general BER is fraught with peril.
-
-5.1.2. Optional Integer Fields
-
-   Some implementations do not internally distinguish between an omitted
-   optional integer value and a transmitted value of zero. The places in
-   the protocol where this is relevant include various microseconds
-   fields, nonces, and sequence numbers. Implementations SHOULD treat
-   omitted optional integer values as having been transmitted with a
-   value of zero, if the application is expecting this.
-
-5.1.3. Empty SEQUENCE OF Types
-
-   There are places in the protocol where a message contains a SEQUENCE
-   OF type as an optional member. This can result in an encoding that
-   contains an empty SEQUENCE OF encoding. The Kerberos protocol does
-   not semantically distinguish between an absent optional SEQUENCE OF
-   type and a present optional but empty SEQUENCE OF type.
-   Implementations SHOULD NOT send empty SEQUENCE OF encodings that are
-   marked OPTIONAL, but SHOULD accept them as being equivalent to an
-
-
-
-March 2003                                                     [Page 51]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos
-   messages, instances of these problematic optional SEQUENCE OF types
-   are indicated with a comment.
-
-5.1.4. Unrecognized Tag Numbers
-
-   Future revisions to this protocol may include new message types with
-   different APPLICATION class tag numbers. Such revisions should
-   protect older implementations by only sending the message types to
-   parties that are known to understand them, e.g. by means of a flag
-   bit set by the receiver in a preceding request. In the interest of
-   robust error handling, implementations SHOULD gracefully handle
-   receiving a message with an unrecognized tag anyway, and return an
-   error message if appropriate.
-
-5.1.5. Tag Numbers Greater Than 30
-
-   A naive implementation of a DER ASN.1 decoder may experience problems
-   with ASN.1 tag numbers greater than 30, due to such tag numbers being
-   encoded using more than one byte. Future revisions of this protocol
-   may utilize tag numbers greater than 30, and implementations SHOULD
-   be prepared to gracefully return an error, if appropriate, if they do
-   not recognize the tag.
-
-5.2. Basic Kerberos Types
-
-   This section defines a number of basic types that are potentially
-   used in multiple Kerberos protocol messages.
-
-5.2.1. KerberosString
-
-   The original specification of the Kerberos protocol in RFC 1510 uses
-   GeneralString in numerous places for human-readable string data.
-   Historical implementations of Kerberos cannot utilize the full power
-   of GeneralString.  This ASN.1 type requires the use of designation
-   and invocation escape sequences as specified in ISO-2022/ECMA-35
-   [ISO-2022/ECMA-35] to switch character sets, and the default
-   character set that is designated as G0 is the ISO-646/ECMA-6
-   [ISO-646,ECMA-6] International Reference Version (IRV) (aka U.S.
-   ASCII), which mostly works.
-
-   ISO-2022/ECMA-35 defines four character-set code elements (G0..G3)
-   and two Control-function code elements (C0..C1). DER prohibits the
-   designation of character sets as any but the G0 and C0 sets.
-   Unfortunately, this seems to have the side effect of prohibiting the
-   use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any other
-   character-sets that utilize a 96-character set, since it is
-   prohibited by ISO-2022/ECMA-35 to designate them as the G0 code
-
-
-
-March 2003                                                     [Page 52]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   element. This side effect is being investigated in the ASN.1
-   standards community.
-
-   In practice, many implementations treat GeneralStrings as if they
-   were 8-bit strings of whichever character set the implementation
-   defaults to, without regard for correct usage of character-set
-   designation escape sequences. The default character set is often
-   determined by the current user's operating system dependent locale.
-   At least one major implementation places unescaped UTF-8 encoded
-   Unicode characters in the GeneralString. This failure to adhere to
-   the GeneralString specifications results in interoperability issues
-   when conflicting character encodings are utilized by the Kerberos
-   clients, services, and KDC.
-
-   This unfortunate situation is the result of improper documentation of
-   the restrictions of the ASN.1 GeneralString type in prior Kerberos
-   specifications.
-
-   The new (post-RFC 1510) type KerberosString, defined below, is a
-   GeneralString that is constrained to only contain characters in
-   IA5String
-
-      KerberosString  ::= GeneralString (IA5String)
-
-   US-ASCII control characters should in general not be used in
-   KerberosString, except for cases such as newlines in lengthy error
-   messages. Control characters SHOULD NOT be used in principal names or
-   realm names.
-
-   For compatibility, implementations MAY choose to accept GeneralString
-   values that contain characters other than those permitted by
-   IA5String, but they should be aware that character set designation
-   codes will likely be absent, and that the encoding should probably be
-   treated as locale-specific in almost every way. Implementations MAY
-   also choose to emit GeneralString values that are beyond those
-   permitted by IA5String, but should be aware that doing so is
-   extraordinarily risky from an interoperability perspective.
-
-   Some existing implementations use GeneralString to encode unescaped
-   locale-specific characters. This is a violation of the ASN.1
-   standard. Most of these implementations encode US-ASCII in the left-
-   hand half, so as long the implementation transmits only US-ASCII, the
-   ASN.1 standard is not violated in this regard. As soon as such an
-   implementation encodes unescaped locale-specific characters with the
-   high bit set, it violates the ASN.1 standard.
-
-   Other implementations have been known to use GeneralString to contain
-   a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8
-
-
-
-March 2003                                                     [Page 53]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   is a different encoding, not a 94 or 96 character "G" set as defined
-   by ISO 2022.  It is believed that these implementations do not even
-   use the ISO 2022 escape sequence to change the character encoding.
-   Even if implementations were to announce the change of encoding by
-   using that escape sequence, the ASN.1 standard prohibits the use of
-   any escape sequences other than those used to designate/invoke "G" or
-   "C" sets allowed by GeneralString.
-
-   Future revisions to this protocol will almost certainly allow for a
-   more interoperable representation of principal names, probably
-   including UTF8String.
-
-   Note that applying a new constraint to a previously unconstrained
-   type constitutes creation of a new ASN.1 type. In this particular
-   case, the change does not result in a changed encoding under DER.
-
-5.2.2. Realm and PrincipalName
-
-   Realm           ::= KerberosString
-
-   PrincipalName   ::= SEQUENCE {
-           name-type       [0] Int32,
-           name-string     [1] SEQUENCE OF KerberosString
-   }
-
-   Kerberos realm names are encoded as KerberosStrings. Realms shall not
-   contain a character with the code 0 (the US-ASCII NUL). Most realms
-   will usually consist of several components separated by periods (.),
-   in the style of Internet Domain Names, or separated by slashes (/) in
-   the style of X.500 names. Acceptable forms for realm names are
-   specified in section 6.1.. A PrincipalName is a typed sequence of
-   components consisting of the following sub-fields:
-
-   name-type
-      This field specifies the type of name that follows. Pre-defined
-      values for this field are specified in section 6.2. The name-type
-      SHOULD be treated as a hint. Ignoring the name type, no two names
-      can be the same (i.e. at least one of the components, or the
-      realm, must be different).
-
-   name-string
-      This field encodes a sequence of components that form a name, each
-      component encoded as a KerberosString. Taken together, a
-      PrincipalName and a Realm form a principal identifier. Most
-      PrincipalNames will have only a few components (typically one or
-      two).
-
-5.2.3. KerberosTime
-
-
-
-March 2003                                                     [Page 54]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   KerberosTime    ::= GeneralizedTime -- with no fractional seconds
-
-   The timestamps used in Kerberos are encoded as GeneralizedTimes. A
-   KerberosTime value shall not include any fractional portions of the
-   seconds.  As required by the DER, it further shall not include any
-   separators, and it shall specify the UTC time zone (Z). Example: The
-   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
-   November 1985 is 19851106210627Z.
-
-5.2.4. Constrained Integer types
-
-   Some integer members of types SHOULD be constrained to values
-   representable in 32 bits, for compatibility with reasonable
-   implementation limits.
-
-   Int32           ::= INTEGER (-2147483648..2147483647)
-                       -- signed values representable in 32 bits
-
-   UInt32          ::= INTEGER (0..4294967295)
-                       -- unsigned 32 bit values
-
-   Microseconds    ::= INTEGER (0..999999)
-                       -- microseconds
-
-   While this results in changes to the abstract types from the RFC 1510
-   version, the encoding in DER should be unaltered. Historical
-   implementations were typically limited to 32-bit integer values
-   anyway, and assigned numbers SHOULD fall in the space of integer
-   values representable in 32 bits in order to promote interoperability
-   anyway.
-
-   There are several integer fields in messages that are constrained to
-   fixed values.
-
-   pvno
-      also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always
-      the constant integer 5. There is no easy way to make this field
-      into a useful protocol version number, so its value is fixed.
-
-   msg-type
-      this integer field is usually identical to the application tag
-      number of the containing message type.
-
-5.2.5. HostAddress and HostAddresses
-
-   HostAddress     ::= SEQUENCE  {
-           addr-type       [0] Int32,
-           address         [1] OCTET STRING
-
-
-
-March 2003                                                     [Page 55]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   }
-
-   -- NOTE: HostAddresses is always used as an OPTIONAL field and
-   -- should not be empty.
-   HostAddresses   -- NOTE: subtly different from rfc1510,
-                   -- but has a value mapping and encodes the same
-           ::= SEQUENCE OF HostAddress
-
-   The host address encodings consists of two fields:
-
-   addr-type
-      This field specifies the type of address that follows. Pre-defined
-      values for this field are specified in section 7.5.3.
-
-   address
-      This field encodes a single address of type addr-type.
-
-5.2.6. AuthorizationData
-
-      -- NOTE: AuthorizationData is always used as an OPTIONAL field and
-      -- should not be empty.
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-              ad-type         [0] Int32,
-              ad-data         [1] OCTET STRING
-      }
-
-   ad-data
-      This field contains authorization data to be interpreted according
-      to the value of the corresponding ad-type field.
-
-   ad-type
-      This field specifies the format for the ad-data subfield. All
-      negative values are reserved for local use. Non-negative values
-      are reserved for registered use.
-
-   Each sequence of type and data is referred to as an authorization
-   element.  Elements MAY be application specific, however, there is a
-   common set of recursive elements that should be understood by all
-   implementations. These elements contain other elements embedded
-   within them, and the interpretation of the encapsulating element
-   determines which of the embedded elements must be interpreted, and
-   which may be ignored.
-
-   These common authorization data elements are recursively defined,
-   meaning the ad-data for these types will itself contain a sequence of
-   authorization data whose interpretation is affected by the
-   encapsulating element. Depending on the meaning of the encapsulating
-   element, the encapsulated elements may be ignored, might be
-
-
-
-March 2003                                                     [Page 56]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   interpreted as issued directly by the KDC, or they might be stored in
-   a separate plaintext part of the ticket. The types of the
-   encapsulating elements are specified as part of the Kerberos
-   specification because the behavior based on these values should be
-   understood across implementations whereas other elements need only be
-   understood by the applications which they affect.
-
-   Authorization data elements are considered critical if present in a
-   ticket or authenticator. Unless encapsulated in a known authorization
-   data element amending the criticality of the elements it contains, if
-   an unknown authorization data element type is received by a server
-   either in an AP-REQ or in a ticket contained in an AP-REQ, then
-   authentication MUST fail.  Authorization data is intended to restrict
-   the use of a ticket. If the service cannot determine whether the
-   restriction applies to that service then a security weakness may
-   result if the ticket can be used for that service. Authorization
-   elements that are optional can be enclosed in AD-IF-RELEVANT element.
-
-   In the definitions that follow, the value of the ad-type for the
-   element will be specified as the least significant part of the
-   subsection number, and the value of the ad-data will be as shown in
-   the ASN.1 structure that follows the subsection heading.
-
-             contents of ad-data          ad-type
-
-    DER encoding of AD-IF-RELEVANT        1
-
-    DER encoding of AD-KDCIssued          4
-
-    DER encoding of AD-AND-OR             5
-
-    DER encoding of AD-MANDATORY-FOR-KDC  8
-
-5.2.6.1. IF-RELEVANT
-
-   AD-IF-RELEVANT          ::= AuthorizationData
-
-   AD elements encapsulated within the if-relevant element are intended
-   for interpretation only by application servers that understand the
-   particular ad-type of the embedded element. Application servers that
-   do not understand the type of an element embedded within the if-
-   relevant element MAY ignore the uninterpretable element. This element
-   promotes interoperability across implementations which may have local
-   extensions for authorization.  The ad-type for AD-IF-RELEVANT is (1).
-
-5.2.6.2. KDCIssued
-
-   AD-KDCIssued            ::= SEQUENCE {
-
-
-
-March 2003                                                     [Page 57]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-           ad-checksum     [0] Checksum,
-           i-realm         [1] Realm OPTIONAL,
-           i-sname         [2] PrincipalName OPTIONAL,
-           elements        [3] AuthorizationData
-   }
-
-   ad-checksum
-      A checksum over the elements field using a cryptographic checksum
-      method that is identical to the checksum used to protect the
-      ticket itself (i.e. using the same hash function and the same
-      encryption algorithm used to encrypt the ticket) using the key
-      used to protect the ticket, and a key usage value of 19.
-
-   i-realm, i-sname
-      The name of the issuing principal if different from the KDC
-      itself.  This field would be used when the KDC can verify the
-      authenticity of elements signed by the issuing principal and it
-      allows this KDC to notify the application server of the validity
-      of those elements.
-
-   elements
-      A sequence of authorization data elements issued by the KDC.
-
-   The KDC-issued ad-data field is intended to provide a means for
-   Kerberos principal credentials to embed within themselves privilege
-   attributes and other mechanisms for positive authorization,
-   amplifying the privileges of the principal beyond what can be done
-   using a credentials without such an a-data element.
-
-   This can not be provided without this element because the definition
-   of the authorization-data field allows elements to be added at will
-   by the bearer of a TGT at the time that they request service tickets
-   and elements may also be added to a delegated ticket by inclusion in
-   the authenticator.
-
-   For KDC-issued elements this is prevented because the elements are
-   signed by the KDC by including a checksum encrypted using the
-   server's key (the same key used to encrypt the ticket - or a key
-   derived from that key). Elements encapsulated with in the KDC-issued
-   element will be ignored by the application server if this "signature"
-   is not present. Further, elements encapsulated within this element
-   from a ticket-granting ticket MAY be interpreted by the KDC, and used
-   as a basis according to policy for including new signed elements
-   within derivative tickets, but they will not be copied to a
-   derivative ticket directly. If they are copied directly to a
-   derivative ticket by a KDC that is not aware of this element, the
-   signature will not be correct for the application ticket elements,
-   and the field will be ignored by the application server.
-
-
-
-March 2003                                                     [Page 58]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   This element and the elements it encapulates MAY be safely ignored by
-   applications, application servers, and KDCs that do not implement
-   this element.
-
-   The ad-type for AD-KDC-ISSUED is (4).
-
-5.2.6.3. AND-OR
-
-   AD-AND-OR               ::= SEQUENCE {
-           condition-count [0] INTEGER,
-           elements        [1] AuthorizationData
-   }
-
-
-   When restrictive AD elements are encapsulated within the and-or
-   element, the and-or element is considered satisfied if and only if at
-   least the number of encapsulated elements specified in condition-
-   count are satisifed.  Therefore, this element MAY be used to
-   implement an "or" operation by setting the condition-count field to
-   1, and it MAY specify an "and" operation by setting the condition
-   count to the number of embedded elements. Application servers that do
-   not implement this element MUST reject tickets that contain
-   authorization data elements of this type.
-
-   The ad-type for AD-AND-OR is (5).
-
-5.2.6.4. MANDATORY-FOR-KDC
-
-   AD-MANDATORY-FOR-KDC    ::= AuthorizationData
-
-   AD elements encapsulated within the mandatory-for-kdc element are to
-   be interpreted by the KDC. KDCs that do not understand the type of an
-   element embedded within the mandatory-for-kdc element MUST reject the
-   request.
-
-   The ad-type for AD-MANDATORY-FOR-KDC is (8).
-
-5.2.7. PA-DATA
-
-   Historically, PA-DATA have been known as "pre-authentication data",
-   meaning that they were used to augment the initial authentication
-   with the KDC.  Since that time, they have also been used as a typed
-   hole with which to extend protocol exchanges with the KDC.
-
-   PA-DATA         ::= SEQUENCE {
-           -- NOTE: first tag is [1], not [0]
-           padata-type     [1] Int32,
-           padata-value    [2] OCTET STRING -- might be encoded AP-REQ
-
-
-
-March 2003                                                     [Page 59]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   }
-
-   padata-type
-      indicates the way that the padata-value element is to be
-      interpreted.  Negative values of padata-type are reserved for
-      unregistered use; non-negative values are used for a registered
-      interpretation of the element type.
-
-   padata-value
-      Usually contains the DER encoding of another type; the padata-type
-      field identifies which type is encoded here.
-
-       padata-type        name           contents of padata-value
-
-       1            pa-tgs-req       DER encoding of AP-REQ
-
-       2            pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP
-
-       3            pa-pw-salt       salt (not ASN.1 encoded)
-
-       11           pa-etype-info    DER encoding of ETYPE-INFO
-
-       19           pa-etype-info2   DER encoding of ETYPE-INFO2
-
-      This field MAY also contain information needed by certain
-      extensions to the Kerberos protocol. For example, it might be used
-      to initially verify the identity of a client before any response
-      is returned.
-
-      The padata field can also contain information needed to help the
-      KDC or the client select the key needed for generating or
-      decrypting the response. This form of the padata is useful for
-      supporting the use of certain token cards with Kerberos. The
-      details of such extensions are specified in separate documents.
-      See [Pat92] for additional uses of this field.
-
-5.2.7.1. PA-TGS-REQ
-
-   In the case of requests for additional tickets (KRB_TGS_REQ), padata-
-   value will contain an encoded AP-REQ. The checksum in the
-   authenticator (which MUST be collision-proof) is to be computed over
-   the KDC-REQ-BODY encoding.
-
-5.2.7.2. Encrypted Timestamp Pre-authentication
-
-   There are pre-authentication types that may be used to pre-
-   authenticate a client by means of an encrypted timestamp.
-
-
-
-
-March 2003                                                     [Page 60]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
-
-   PA-ENC-TS-ENC           ::= SEQUENCE {
-           patimestamp     [0] KerberosTime -- client's time --,
-           pausec          [1] Microseconds OPTIONAL
-   }
-
-   Patimestamp contains the client's time, and pausec contains the
-   microseconds, which MAY be omitted if a client will not generate more
-   than one request per second. The ciphertext (padata-value) consists
-   of the PA-ENC-TS-ENC encoding, encrypted using the client's secret
-   key and a key usage value of 1.
-
-   This pre-authentication type was not present in RFC 1510, but many
-   implementations support it.
-
-5.2.7.3. PA-PW-SALT
-
-   The padata-value for this pre-authentication type contains the salt
-   for the string-to-key to be used by the client to obtain the key for
-   decrypting the encrypted part of an AS-REP message. Unfortunately,
-   for historical reasons, the character set to be used is unspecified
-   and probably locale-specific.
-
-   This pre-authentication type was not present in RFC 1510, but many
-   implementations support it. It is necessary in any case where the
-   salt for the string-to-key algorithm is not the default.
-
-   In the trivial example, a zero-length salt string is very commonplace
-   for realms that have converted their principal databases from
-   Kerberos 4.
-
-   A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message
-   that requests additional pre-authentication. Implementation note:
-   some KDC implementations issue an erroneous PA-PW-SALT when issuing a
-   KRB-ERROR message that requests additional pre-authentication.
-   Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a KRB-
-   ERROR message that requests additional pre-authentication.
-
-5.2.7.4. PA-ETYPE-INFO
-
-   The ETYPE-INFO pre-authentication type is sent by the KDC in a KRB-
-   ERROR indicating a requirement for additional pre-authentication. It
-   is usually used to notify a client of which key to use for the
-   encryption of an encrypted timestamp for the purposes of sending a
-   PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an
-   AS-REP to provide information to the client about which key salt to
-   use for the string-to-key to be used by the client to obtain the key
-
-
-
-March 2003                                                     [Page 61]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   for decrypting the encrypted part the AS-REP.
-
-   ETYPE-INFO-ENTRY        ::= SEQUENCE {
-           etype           [0] Int32,
-           salt            [1] OCTET STRING OPTIONAL
-   }
-
-   ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
-
-   The salt, like that of PA-PW-SALT, is also completely unspecified
-   with respect to character set and is probably locale-specific.
-
-   If ETYPE-INFO is sent in an AS-REP, there shall be exactly one ETYPE-
-   INFO-ENTRY, and its etype shall match that of the enc-part in the AS-
-   REP.
-
-   This pre-authentication type was not present in RFC 1510, but many
-   implementations that support encrypted timestamps for pre-
-   authentication need to support ETYPE-INFO as well.
-
-5.2.7.5. PA-ETYPE-INFO2
-
-   The ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB-
-   ERROR indicating a requirement for additional pre-authentication. It
-   is usually used to notify a client of which key to use for the
-   encryption of an encrypted timestamp for the purposes of sending a
-   PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an
-   AS-REP to provide information to the client about which key salt to
-   use for the string-to-key to be used by the client to obtain the key
-   for decrypting the encrypted part the AS-REP.
-
-   ETYPE-INFO2-ENTRY       ::= SEQUENCE {
-           etype           [0] Int32,
-           salt            [1] KerberosString OPTIONAL,
-           s2kparams       [2] OCTET STRING OPTIONAL
-   }
-
-   ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY
-
-   The type of the salt is KerberosString, but existing installations
-   might have locale-specific characters stored in salt strings, and
-   implementors MAY choose to handle them.
-
-   The interpretation of s2kparams is specified in the cryptosystem
-   description associated with the etype. Each cryptosystem has a
-   default interpretation of s2kparams that will hold if that element is
-   omitted from the encoding of ETYPE-INFO2-ENTRY.
-
-
-
-
-March 2003                                                     [Page 62]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one
-   ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in
-   the AS-REP.
-
-   The preferred ordering of pre-authentication data that modify client
-   key selection is: ETYPE-INFO2, followed by ETYPE-INFO, followed by
-   PW-SALT. A KDC shall send all of these pre-authentication data that
-   it supports, in the preferred ordering, when issuing an AS-REP or
-   when issuing a KRB-ERROR requesting additional pre-authentication.
-
-   The ETYPE-INFO2 pre-authentication type was not present in RFC 1510.
-
-5.2.8. KerberosFlags
-
-   For several message types, a specific constrained bit string type,
-   KerberosFlags, is used.
-
-   KerberosFlags   ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
-                       -- shall be sent, but no fewer than 32
-
-   Compatibility note: the following paragraphs describe a change from
-   the RFC1510 description of bit strings that would result in
-   incompatility in the case of an implementation that strictly
-   conformed to ASN.1 DER and RFC1510.
-
-   ASN.1 bit strings have multiple uses. The simplest use of a bit
-   string is to contain a vector of bits, with no particular meaning
-   attached to individual bits. This vector of bits is not necessarily a
-   multiple of eight bits long.  The use in Kerberos of a bit string as
-   a compact boolean vector wherein each element has a distinct meaning
-   poses some problems. The natural notation for a compact boolean
-   vector is the ASN.1 "NamedBit" notation, and the DER require that
-   encodings of a bit string using "NamedBit" notation exclude any
-   trailing zero bits. This truncation is easy to neglect, especially
-   given C language implementations that naturally choose to store
-   boolean vectors as 32 bit integers.
-
-   For example, if the notation for KDCOptions were to include the
-   "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be
-   encoded had only the "forwardable" (bit number one) bit set, the DER
-   encoding MUST include only two bits: the first reserved bit
-   ("reserved", bit number zero, value zero) and the one-valued bit (bit
-   number one) for "forwardable".
-
-   Most existing implementations of Kerberos unconditionally send 32
-   bits on the wire when encoding bit strings used as boolean vectors.
-   This behavior violates the ASN.1 syntax used for flag values in RFC
-   1510, but occurs on such a widely installed base that the protocol
-
-
-
-March 2003                                                     [Page 63]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   description is being modified to accomodate it.
-
-   Consequently, this document removes the "NamedBit" notations for
-   individual bits, relegating them to comments. The size constraint on
-   the KerberosFlags type requires that at least 32 bits be encoded at
-   all times, though a lenient implementation MAY choose to accept fewer
-   than 32 bits and to treat the missing bits as set to zero.
-
-   Currently, no uses of KerberosFlags specify more than 32 bits worth
-   of flags, although future revisions of this document may do so. When
-   more than 32 bits are to be transmitted in a KerberosFlags value,
-   future revisions to this document will likely specify that the
-   smallest number of bits needed to encode the highest-numbered one-
-   valued bit should be sent. This is somewhat similar to the DER
-   encoding of a bit string that is declared with the "NamedBit"
-   notation.
-
-5.2.9. Cryptosystem-related Types
-
-   Many Kerberos protocol messages contain an EncryptedData as a
-   container for arbitrary encrypted data, which is often the encrypted
-   encoding of another data type. Fields within EncryptedData assist the
-   recipient in selecting a key with which to decrypt the enclosed data.
-
-   EncryptedData   ::= SEQUENCE {
-           etype   [0] Int32 -- EncryptionType --,
-           kvno    [1] UInt32 OPTIONAL,
-           cipher  [2] OCTET STRING -- ciphertext
-   }
-
-   etype
-      This field identifies which encryption algorithm was used to
-      encipher the cipher.
-
-   kvno
-      This field contains the version number of the key under which data
-      is encrypted. It is only present in messages encrypted under long
-      lasting keys, such as principals' secret keys.
-
-   cipher
-      This field contains the enciphered text, encoded as an OCTET
-      STRING.  (Note that the encryption mechanisms defined in
-      [@KCRYPTO] MUST incorporate integrity protection as well, so no
-      additional checksum is required.)
-
-   The EncryptionKey type is the means by which cryptographic keys used
-   for encryption are transfered.
-
-
-
-
-March 2003                                                     [Page 64]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   EncryptionKey   ::= SEQUENCE {
-           keytype         [0] Int32 -- actually encryption type --,
-           keyvalue        [1] OCTET STRING
-   }
-
-   keytype
-      This field specifies the encryption type of the encryption key
-      that follows in the keyvalue field. While its name is "keytype",
-      it actually specifies an encryption type. Previously, multiple
-      cryptosystems that performed encryption differently but were
-      capable of using keys with the same characteristics were permitted
-      to share an assigned number to designate the type of key; this
-      usage is now deprecated.
-
-   keyvalue
-      This field contains the key itself, encoded as an octet string.
-
-   Messages containing cleartext data to be authenticated will usually
-   do so by using a member of type Checksum. Most instances of Checksum
-   use a keyed hash, though exceptions will be noted.
-
-   Checksum        ::= SEQUENCE {
-           cksumtype       [0] Int32,
-           checksum        [1] OCTET STRING
-   }
-
-   cksumtype
-      This field indicates the algorithm used to generate the
-      accompanying checksum.
-
-   checksum
-      This field contains the checksum itself, encoded as an octet
-      string.
-
-   See section 4 for a brief description of the use of encryption and
-   checksums in Kerberos.
-
-5.3. Tickets
-
-   This section describes the format and encryption parameters for
-   tickets and authenticators. When a ticket or authenticator is
-   included in a protocol message it is treated as an opaque object. A
-   ticket is a record that helps a client authenticate to a service. A
-   Ticket contains the following information:
-
-   Ticket          ::= [APPLICATION 1] SEQUENCE {
-           tkt-vno         [0] INTEGER (5),
-           realm           [1] Realm,
-
-
-
-March 2003                                                     [Page 65]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-           sname           [2] PrincipalName,
-           enc-part        [3] EncryptedData -- EncTicketPart
-   }
-
-   -- Encrypted part of ticket
-   EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
-           flags                   [0] TicketFlags,
-           key                     [1] EncryptionKey,
-           crealm                  [2] Realm,
-           cname                   [3] PrincipalName,
-           transited               [4] TransitedEncoding,
-           authtime                [5] KerberosTime,
-           starttime               [6] KerberosTime OPTIONAL,
-           endtime                 [7] KerberosTime,
-           renew-till              [8] KerberosTime OPTIONAL,
-           caddr                   [9] HostAddresses OPTIONAL,
-           authorization-data      [10] AuthorizationData OPTIONAL
-   }
-
-   -- encoded Transited field
-   TransitedEncoding       ::= SEQUENCE {
-           tr-type         [0] Int32 -- must be registered --,
-           contents        [1] OCTET STRING
-   }
-
-   TicketFlags     ::= KerberosFlags
-           -- reserved(0),
-           -- forwardable(1),
-           -- forwarded(2),
-           -- proxiable(3),
-           -- proxy(4),
-           -- may-postdate(5),
-           -- postdated(6),
-           -- invalid(7),
-           -- renewable(8),
-           -- initial(9),
-           -- pre-authent(10),
-           -- hw-authent(11),
-   -- the following are new since 1510
-           -- transited-policy-checked(12),
-           -- ok-as-delegate(13)
-
-   tkt-vno
-      This field specifies the version number for the ticket format.
-      This document describes version number 5.
-
-   realm
-      This field specifies the realm that issued a ticket. It also
-
-
-
-March 2003                                                     [Page 66]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      serves to identify the realm part of the server's principal
-      identifier. Since a Kerberos server can only issue tickets for
-      servers within its realm, the two will always be identical.
-
-   sname
-      This field specifies all components of the name part of the
-      server's identity, including those parts that identify a specific
-      instance of a service.
-
-   enc-part
-      This field holds the encrypted encoding of the EncTicketPart
-      sequence.  It is encrypted in the key shared by Kerberos and the
-      end server (the server's secret key), using a key usage value of
-      2.
-
-   flags
-      This field indicates which of various options were used or
-      requested when the ticket was issued. The meanings of the flags
-      are:
-
-         Bit(s)  Name                   Description
-
-         0       reserved               Reserved for future expansion of this
-                                        field.
-
-                                        The FORWARDABLE flag is normally only
-                                        interpreted by the TGS, and can be
-                                        ignored by end servers. When set, this
-         1       forwardable            flag tells the ticket-granting server
-                                        that it is OK to issue a new
-                                        ticket-granting ticket with a
-                                        different network address based on the
-                                        presented ticket.
-
-                                        When set, this flag indicates that the
-                                        ticket has either been forwarded or
-         2       forwarded              was issued based on authentication
-                                        involving a forwarded ticket-granting
-                                        ticket.
-
-                                        The PROXIABLE flag is normally only
-                                        interpreted by the TGS, and can be
-                                        ignored by end servers. The PROXIABLE
-                                        flag has an interpretation identical
-         3       proxiable              to that of the FORWARDABLE flag,
-                                        except that the PROXIABLE flag tells
-                                        the ticket-granting server that only
-                                        non-ticket-granting tickets may be
-
-
-
-March 2003                                                     [Page 67]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-                                        issued with different network
-                                        addresses.
-
-         4       proxy                  When set, this flag indicates that a
-                                        ticket is a proxy.
-
-                                        The MAY-POSTDATE flag is normally only
-                                        interpreted by the TGS, and can be
-         5       may-postdate           ignored by end servers. This flag
-                                        tells the ticket-granting server that
-                                        a post-dated ticket MAY be issued
-                                        based on this ticket-granting ticket.
-
-                                        This flag indicates that this ticket
-                                        has been postdated. The end-service
-         6       postdated              can check the authtime field to see
-                                        when the original authentication
-                                        occurred.
-
-                                        This flag indicates that a ticket is
-                                        invalid, and it must be validated by
-         7       invalid                the KDC before use. Application
-                                        servers must reject tickets which have
-                                        this flag set.
-
-                                        The RENEWABLE flag is normally only
-                                        interpreted by the TGS, and can
-                                        usually be ignored by end servers
-         8       renewable              (some particularly careful servers MAY
-                                        disallow renewable tickets). A
-                                        renewable ticket can be used to obtain
-                                        a replacement ticket that expires at a
-                                        later date.
-
-                                        This flag indicates that this ticket
-         9       initial                was issued using the AS protocol, and
-                                        not issued based on a ticket-granting
-                                        ticket.
-
-                                        This flag indicates that during
-                                        initial authentication, the client was
-                                        authenticated by the KDC before a
-         10      pre-authent            ticket was issued. The strength of the
-                                        pre-authentication method is not
-                                        indicated, but is acceptable to the
-                                        KDC.
-
-                                        This flag indicates that the protocol
-
-
-
-March 2003                                                     [Page 68]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-                                        employed for initial authentication
-                                        required the use of hardware expected
-         11      hw-authent             to be possessed solely by the named
-                                        client. The hardware authentication
-                                        method is selected by the KDC and the
-                                        strength of the method is not
-                                        indicated.
-
-                                        This flag indicates that the KDC for
-                                        the realm has checked the transited
-                                        field against a realm defined policy
-                                        for trusted certifiers. If this flag
-                                        is reset (0), then the application
-                                        server must check the transited field
-                                        itself, and if unable to do so it must
-                                        reject the authentication. If the flag
-         12      transited-             is set (1) then the application server
-                 policy-checked         MAY skip its own validation of the
-                                        transited field, relying on the
-                                        validation performed by the KDC. At
-                                        its option the application server MAY
-                                        still apply its own validation based
-                                        on a separate policy for acceptance.
-
-                                        This flag is new since RFC 1510.
-
-                                        This flag indicates that the server
-                                        (not the client) specified in the
-                                        ticket has been determined by policy
-                                        of the realm to be a suitable
-                                        recipient of delegation. A client can
-                                        use the presence of this flag to help
-                                        it make a decision whether to delegate
-                                        credentials (either grant a proxy or a
-                                        forwarded ticket-granting ticket) to
-         13      ok-as-delegate         this server. The client is free to
-                                        ignore the value of this flag. When
-                                        setting this flag, an administrator
-                                        should consider the Security and
-                                        placement of the server on which the
-                                        service will run, as well as whether
-                                        the service requires the use of
-                                        delegated credentials.
-
-                                        This flag is new since RFC 1510.
-
-         14-31   reserved               Reserved for future use.
-
-
-
-
-March 2003                                                     [Page 69]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   key
-      This field exists in the ticket and the KDC response and is used
-      to pass the session key from Kerberos to the application server
-      and the client.
-
-   crealm
-      This field contains the name of the realm in which the client is
-      registered and in which initial authentication took place.
-
-   cname
-      This field contains the name part of the client's principal
-      identifier.
-
-   transited
-      This field lists the names of the Kerberos realms that took part
-      in authenticating the user to whom this ticket was issued. It does
-      not specify the order in which the realms were transited. See
-      section 3.3.3.2 for details on how this field encodes the
-      traversed realms.  When the names of CA's are to be embedded in
-      the transited field (as specified for some extensions to the
-      protocol), the X.500 names of the CA's SHOULD be mapped into items
-      in the transited field using the mapping defined by RFC2253.
-
-   authtime
-      This field indicates the time of initial authentication for the
-      named principal. It is the time of issue for the original ticket
-      on which this ticket is based. It is included in the ticket to
-      provide additional information to the end service, and to provide
-      the necessary information for implementation of a `hot list'
-      service at the KDC. An end service that is particularly paranoid
-      could refuse to accept tickets for which the initial
-      authentication occurred "too far" in the past. This field is also
-      returned as part of the response from the KDC.  When returned as
-      part of the response to initial authentication (KRB_AS_REP), this
-      is the current time on the Kerberos server.  It is NOT recommended
-      that this time value be used to adjust the workstation's clock
-      since the workstation cannot reliably determine that such a
-      KRB_AS_REP actually came from the proper KDC in a timely manner.
-
-
-   starttime
-
-      This field in the ticket specifies the time after which the ticket
-      is valid. Together with endtime, this field specifies the life of
-      the ticket. If the starttime field is absent from the ticket, then
-      the authtime field SHOULD be used in its place to determine the
-      life of the ticket.
-
-
-
-
-March 2003                                                     [Page 70]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   endtime
-      This field contains the time after which the ticket will not be
-      honored (its expiration time). Note that individual services MAY
-      place their own limits on the life of a ticket and MAY reject
-      tickets which have not yet expired. As such, this is really an
-      upper bound on the expiration time for the ticket.
-
-   renew-till
-      This field is only present in tickets that have the RENEWABLE flag
-      set in the flags field. It indicates the maximum endtime that may
-      be included in a renewal. It can be thought of as the absolute
-      expiration time for the ticket, including all renewals.
-
-   caddr
-      This field in a ticket contains zero (if omitted) or more (if
-      present) host addresses. These are the addresses from which the
-      ticket can be used. If there are no addresses, the ticket can be
-      used from any location. The decision by the KDC to issue or by the
-      end server to accept addressless tickets is a policy decision and
-      is left to the Kerberos and end-service administrators; they MAY
-      refuse to issue or accept such tickets. Because of the wide
-      deployment of network address translation, it is recommended that
-      policy allow the issue and acceptance of such tickets.
-
-      Network addresses are included in the ticket to make it harder for
-      an attacker to use stolen credentials. Because the session key is
-      not sent over the network in cleartext, credentials can't be
-      stolen simply by listening to the network; an attacker has to gain
-      access to the session key (perhaps through operating system
-      security breaches or a careless user's unattended session) to make
-      use of stolen tickets.
-
-      It is important to note that the network address from which a
-      connection is received cannot be reliably determined. Even if it
-      could be, an attacker who has compromised the client's workstation
-      could use the credentials from there. Including the network
-      addresses only makes it more difficult, not impossible, for an
-      attacker to walk off with stolen credentials and then use them
-      from a "safe" location.
-
-   authorization-data
-      The authorization-data field is used to pass authorization data
-      from the principal on whose behalf a ticket was issued to the
-      application service. If no authorization data is included, this
-      field will be left out. Experience has shown that the name of this
-      field is confusing, and that a better name for this field would be
-      restrictions. Unfortunately, it is not possible to change the name
-      of this field at this time.
-
-
-
-March 2003                                                     [Page 71]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      This field contains restrictions on any authority obtained on the
-      basis of authentication using the ticket. It is possible for any
-      principal in posession of credentials to add entries to the
-      authorization data field since these entries further restrict what
-      can be done with the ticket.  Such additions can be made by
-      specifying the additional entries when a new ticket is obtained
-      during the TGS exchange, or they MAY be added during chained
-      delegation using the authorization data field of the
-      authenticator.
-
-      Because entries may be added to this field by the holder of
-      credentials, except when an entry is separately authenticated by
-      encapsulation in the KDC-issued element, it is not allowable for
-      the presence of an entry in the authorization data field of a
-      ticket to amplify the privileges one would obtain from using a
-      ticket.
-
-      The data in this field may be specific to the end service; the
-      field will contain the names of service specific objects, and the
-      rights to those objects. The format for this field is described in
-      section 5.2.6.  Although Kerberos is not concerned with the format
-      of the contents of the sub-fields, it does carry type information
-      (ad-type).
-
-      By using the authorization_data field, a principal is able to
-      issue a proxy that is valid for a specific purpose. For example, a
-      client wishing to print a file can obtain a file server proxy to
-      be passed to the print server. By specifying the name of the file
-      in the authorization_data field, the file server knows that the
-      print server can only use the client's rights when accessing the
-      particular file to be printed.
-
-      A separate service providing authorization or certifying group
-      membership may be built using the authorization-data field. In
-      this case, the entity granting authorization (not the authorized
-      entity), may obtain a ticket in its own name (e.g. the ticket is
-      issued in the name of a privilege server), and this entity adds
-      restrictions on its own authority and delegates the restricted
-      authority through a proxy to the client. The client would then
-      present this authorization credential to the application server
-      separately from the authentication exchange.  Alternatively, such
-      authorization credentials MAY be embedded in the ticket
-      authenticating the authorized entity, when the authorization is
-      separately authenticated using the KDC-issued authorization data
-      element (see 5.2.6.2).
-
-      Similarly, if one specifies the authorization-data field of a
-      proxy and leaves the host addresses blank, the resulting ticket
-
-
-
-March 2003                                                     [Page 72]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      and session key can be treated as a capability. See [Neu93] for
-      some suggested uses of this field.
-
-      The authorization-data field is optional and does not have to be
-      included in a ticket.
-
-5.4. Specifications for the AS and TGS exchanges
-
-   This section specifies the format of the messages used in the
-   exchange between the client and the Kerberos server. The format of
-   possible error messages appears in section 5.9.1.
-
-5.4.1. KRB_KDC_REQ definition
-
-   The KRB_KDC_REQ message has no application tag number of its own.
-   Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ,
-   which each have an application tag, depending on whether the request
-   is for an initial ticket or an additional ticket. In either case, the
-   message is sent from the client to the KDC to request credentials for
-   a service.
-
-   The message fields are:
-
-   AS-REQ          ::= [APPLICATION 10] KDC-REQ
-
-   TGS-REQ         ::= [APPLICATION 12] KDC-REQ
-
-   KDC-REQ         ::= SEQUENCE {
-           -- NOTE: first tag is [1], not [0]
-           pvno            [1] INTEGER (5) ,
-           msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
-           padata          [3] SEQUENCE OF PA-DATA OPTIONAL
-                               -- NOTE: not empty --,
-           req-body        [4] KDC-REQ-BODY
-   }
-
-   KDC-REQ-BODY    ::= SEQUENCE {
-           kdc-options             [0] KDCOptions,
-           cname                   [1] PrincipalName OPTIONAL
-                                       -- Used only in AS-REQ --,
-           realm                   [2] Realm
-                                       -- Server's realm
-                                       -- Also client's in AS-REQ --,
-           sname                   [3] PrincipalName OPTIONAL,
-           from                    [4] KerberosTime OPTIONAL,
-           till                    [5] KerberosTime,
-           rtime                   [6] KerberosTime OPTIONAL,
-           nonce                   [7] UInt32,
-
-
-
-March 2003                                                     [Page 73]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-           etype                   [8] SEQUENCE OF Int32 -- EncryptionType
-                                       -- in preference order --,
-           addresses               [9] HostAddresses OPTIONAL,
-           enc-authorization-data  [10] EncryptedData -- AuthorizationData --,
-           additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
-                                           -- NOTE: not empty
-   }
-
-   KDCOptions      ::= KerberosFlags
-           -- reserved(0),
-           -- forwardable(1),
-           -- forwarded(2),
-           -- proxiable(3),
-           -- proxy(4),
-           -- allow-postdate(5),
-           -- postdated(6),
-           -- unused7(7),
-           -- renewable(8),
-           -- unused9(9),
-           -- unused10(10),
-           -- opt-hardware-auth(11),
-           -- unused12(12),
-           -- unused13(13),
-   -- 15 is reserved for canonicalize
-           -- unused15(15),
-   -- 26 was unused in 1510
-           -- disable-transited-check(26),
-   --
-           -- renewable-ok(27),
-           -- enc-tkt-in-skey(28),
-           -- renew(30),
-           -- validate(31)
-
-   The fields in this message are:
-
-   pvno
-      This field is included in each message, and specifies the protocol
-      version number. This document specifies protocol version 5.
-
-   msg-type
-      This field indicates the type of a protocol message. It will
-      almost always be the same as the application identifier associated
-      with a message. It is included to make the identifier more readily
-      accessible to the application. For the KDC-REQ message, this type
-      will be KRB_AS_REQ or KRB_TGS_REQ.
-
-   padata
-      Contains pre-authentication data. Requests for additional tickets
-
-
-
-March 2003                                                     [Page 74]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ.
-
-      The padata (pre-authentication data) field contains a sequence of
-      authentication information which may be needed before credentials
-      can be issued or decrypted.
-
-   req-body
-      This field is a placeholder delimiting the extent of the remaining
-      fields. If a checksum is to be calculated over the request, it is
-      calculated over an encoding of the KDC-REQ-BODY sequence which is
-      enclosed within the req-body field.
-
-   kdc-options
-      This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to
-      the KDC and indicates the flags that the client wants set on the
-      tickets as well as other information that is to modify the
-      behavior of the KDC.  Where appropriate, the name of an option may
-      be the same as the flag that is set by that option. Although in
-      most case, the bit in the options field will be the same as that
-      in the flags field, this is not guaranteed, so it is not
-      acceptable to simply copy the options field to the flags field.
-      There are various checks that must be made before honoring an
-      option anyway.
-
-      The kdc_options field is a bit-field, where the selected options
-      are indicated by the bit being set (1), and the unselected options
-      and reserved fields being reset (0). The encoding of the bits is
-      specified in section 5.2. The options are described in more detail
-      above in section 2. The meanings of the options are:
-
-         Bits    Name                     Description
-
-         0       RESERVED                 Reserved for future expansion of
-                                          this field.
-
-                                          The FORWARDABLE option indicates
-                                          that the ticket to be issued is to
-                                          have its forwardable flag set. It
-         1       FORWARDABLE              may only be set on the initial
-                                          request, or in a subsequent request
-                                          if the ticket-granting ticket on
-                                          which it is based is also
-                                          forwardable.
-
-                                          The FORWARDED option is only
-                                          specified in a request to the
-                                          ticket-granting server and will only
-                                          be honored if the ticket-granting
-
-
-
-March 2003                                                     [Page 75]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-                                          ticket in the request has its
-         2       FORWARDED                FORWARDABLE bit set. This option
-                                          indicates that this is a request for
-                                          forwarding. The address(es) of the
-                                          host from which the resulting ticket
-                                          is to be valid are included in the
-                                          addresses field of the request.
-
-                                          The PROXIABLE option indicates that
-                                          the ticket to be issued is to have
-                                          its proxiable flag set. It may only
-         3       PROXIABLE                be set on the initial request, or in
-                                          a subsequent request if the
-                                          ticket-granting ticket on which it
-                                          is based is also proxiable.
-
-                                          The PROXY option indicates that this
-                                          is a request for a proxy. This
-                                          option will only be honored if the
-                                          ticket-granting ticket in the
-         4       PROXY                    request has its PROXIABLE bit set.
-                                          The address(es) of the host from
-                                          which the resulting ticket is to be
-                                          valid are included in the addresses
-                                          field of the request.
-
-                                          The ALLOW-POSTDATE option indicates
-                                          that the ticket to be issued is to
-                                          have its MAY-POSTDATE flag set. It
-         5       ALLOW-POSTDATE           may only be set on the initial
-                                          request, or in a subsequent request
-                                          if the ticket-granting ticket on
-                                          which it is based also has its
-                                          MAY-POSTDATE flag set.
-
-                                          The POSTDATED option indicates that
-                                          this is a request for a postdated
-                                          ticket. This option will only be
-                                          honored if the ticket-granting
-                                          ticket on which it is based has its
-         6       POSTDATED                MAY-POSTDATE flag set. The resulting
-                                          ticket will also have its INVALID
-                                          flag set, and that flag may be reset
-                                          by a subsequent request to the KDC
-                                          after the starttime in the ticket
-                                          has been reached.
-
-         7       RESERVED                 This option is presently unused.
-
-
-
-March 2003                                                     [Page 76]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-                                          The RENEWABLE option indicates that
-                                          the ticket to be issued is to have
-                                          its RENEWABLE flag set. It may only
-                                          be set on the initial request, or
-                                          when the ticket-granting ticket on
-         8       RENEWABLE                which the request is based is also
-                                          renewable. If this option is
-                                          requested, then the rtime field in
-                                          the request contains the desired
-                                          absolute expiration time for the
-                                          ticket.
-
-         9       RESERVED                 Reserved for PK-Cross
-
-         10      RESERVED                 Reserved for future use.
-
-         11      RESERVED                 Reserved for opt-hardware-auth.
-
-         12-25   RESERVED                 Reserved for future use.
-
-                                          By default the KDC will check the
-                                          transited field of a
-                                          ticket-granting-ticket against the
-                                          policy of the local realm before it
-                                          will issue derivative tickets based
-                                          on the ticket-granting ticket. If
-                                          this flag is set in the request,
-                                          checking of the transited field is
-                                          disabled. Tickets issued without the
-         26      DISABLE-TRANSITED-CHECK  performance of this check will be
-                                          noted by the reset (0) value of the
-                                          TRANSITED-POLICY-CHECKED flag,
-                                          indicating to the application server
-                                          that the tranisted field must be
-                                          checked locally. KDCs are
-                                          encouraged but not required to honor
-                                          the DISABLE-TRANSITED-CHECK option.
-
-                                          This flag is new since RFC 1510
-
-                                          The RENEWABLE-OK option indicates
-                                          that a renewable ticket will be
-                                          acceptable if a ticket with the
-                                          requested life cannot otherwise be
-                                          provided. If a ticket with the
-                                          requested life cannot be provided,
-         27      RENEWABLE-OK             then a renewable ticket may be
-                                          issued with a renew-till equal to
-
-
-
-March 2003                                                     [Page 77]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-                                          the requested endtime. The value
-                                          of the renew-till field may still be
-                                          limited by local limits, or limits
-                                          selected by the individual principal
-                                          or server.
-
-                                          This option is used only by the
-                                          ticket-granting service. The
-                                          ENC-TKT-IN-SKEY option indicates
-         28      ENC-TKT-IN-SKEY          that the ticket for the end server
-                                          is to be encrypted in the session
-                                          key from the additional
-                                          ticket-granting ticket provided.
-
-         29      RESERVED                 Reserved for future use.
-
-                                          This option is used only by the
-                                          ticket-granting service. The RENEW
-                                          option indicates that the present
-                                          request is for a renewal. The ticket
-                                          provided is encrypted in the secret
-                                          key for the server on which it is
-         30      RENEW                    valid. This option will only be
-                                          honored if the ticket to be renewed
-                                          has its RENEWABLE flag set and if
-                                          the time in its renew-till field has
-                                          not passed. The ticket to be renewed
-                                          is passed in the padata field as
-                                          part of the authentication header.
-
-                                          This option is used only by the
-                                          ticket-granting service. The
-                                          VALIDATE option indicates that the
-                                          request is to validate a postdated
-                                          ticket. It will only be honored if
-                                          the ticket presented is postdated,
-                                          presently has its INVALID flag set,
-         31      VALIDATE                 and would be otherwise usable at
-                                          this time. A ticket cannot be
-                                          validated before its starttime. The
-                                          ticket presented for validation is
-                                          encrypted in the key of the server
-                                          for which it is valid and is passed
-                                          in the padata field as part of the
-                                          authentication header.
-   cname and sname
-      These fields are the same as those described for the ticket in
-      section 5.3. The sname may only be absent when the ENC-TKT-IN-SKEY
-
-
-
-March 2003                                                     [Page 78]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      option is specified. If absent, the name of the server is taken
-      from the name of the client in the ticket passed as additional-
-      tickets.
-
-   enc-authorization-data
-      The enc-authorization-data, if present (and it can only be present
-      in the TGS_REQ form), is an encoding of the desired authorization-
-      data encrypted under the sub-session key if present in the
-      Authenticator, or alternatively from the session key in the
-      ticket-granting ticket (both the Authenticator and ticket-granting
-      ticket come from the padata field in the KRB_TGS_REQ). The key
-      usage value used when encrypting is 5 if a sub-session key is
-      used, or 4 if the session key is used.
-
-   realm
-      This field specifies the realm part of the server's principal
-      identifier. In the AS exchange, this is also the realm part of the
-      client's principal identifier.
-
-   from
-      This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
-      requests when the requested ticket is to be postdated. It
-      specifies the desired start time for the requested ticket. If this
-      field is omitted then the KDC SHOULD use the current time instead.
-
-   till
-      This field contains the expiration date requested by the client in
-      a ticket request. It is not optional, but if the requested endtime
-      is "19700101000000Z", the requested ticket is to have the maximum
-      endtime permitted according to KDC policy. Implementation note:
-      This special timestamp corresponds to a UNIX time_t value of zero
-      on most systems.
-
-   rtime
-      This field is the requested renew-till time sent from a client to
-      the KDC in a ticket request. It is optional.
-
-   nonce
-      This field is part of the KDC request and response. It is intended
-      to hold a random number generated by the client. If the same
-      number is included in the encrypted response from the KDC, it
-      provides evidence that the response is fresh and has not been
-      replayed by an attacker.  Nonces MUST NEVER be reused.
-
-   etype
-      This field specifies the desired encryption algorithm to be used
-      in the response.
-
-
-
-
-March 2003                                                     [Page 79]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   addresses
-      This field is included in the initial request for tickets, and
-      optionally included in requests for additional tickets from the
-      ticket-granting server. It specifies the addresses from which the
-      requested ticket is to be valid. Normally it includes the
-      addresses for the client's host. If a proxy is requested, this
-      field will contain other addresses. The contents of this field are
-      usually copied by the KDC into the caddr field of the resulting
-      ticket.
-
-   additional-tickets
-      Additional tickets MAY be optionally included in a request to the
-      ticket-granting server. If the ENC-TKT-IN-SKEY option has been
-      specified, then the session key from the additional ticket will be
-      used in place of the server's key to encrypt the new ticket. When
-      the ENC-TKT-IN-SKEY option is used for user-to-user
-      authentication, this addional ticket MAY be a TGT issued by the
-      local realm or an inter-realm TGT issued for the current KDC's
-      realm by a remote KDC. If more than one option which requires
-      additional tickets has been specified, then the additional tickets
-      are used in the order specified by the ordering of the options
-      bits (see kdc-options, above).
-
-   The application tag number will be either ten (10) or twelve (12)
-   depending on whether the request is for an initial ticket (AS-REQ) or
-   for an additional ticket (TGS-REQ).
-
-   The optional fields (addresses, authorization-data and additional-
-   tickets) are only included if necessary to perform the operation
-   specified in the kdc-options field.
-
-   It should be noted that in KRB_TGS_REQ, the protocol version number
-   appears twice and two different message types appear: the KRB_TGS_REQ
-   message contains these fields as does the authentication header
-   (KRB_AP_REQ) that is passed in the padata field.
-
-5.4.2. KRB_KDC_REP definition
-
-   The KRB_KDC_REP message format is used for the reply from the KDC for
-   either an initial (AS) request or a subsequent (TGS) request. There
-   is no message type for KRB_KDC_REP. Instead, the type will be either
-   KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext
-   part of the reply depends on the message type. For KRB_AS_REP, the
-   ciphertext is encrypted in the client's secret key, and the client's
-   key version number is included in the key version number for the
-   encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the
-   sub-session key from the Authenticator, or if absent, the session key
-   from the ticket-granting ticket used in the request.  In that case,
-
-
-
-March 2003                                                     [Page 80]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   no version number will be present in the EncryptedData sequence.
-
-   The KRB_KDC_REP message contains the following fields:
-
-   AS-REP          ::= [APPLICATION 11] KDC-REP
-
-   TGS-REP         ::= [APPLICATION 13] KDC-REP
-
-   KDC-REP         ::= SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
-           padata          [2] SEQUENCE OF PA-DATA OPTIONAL
-                                   -- NOTE: not empty --,
-           crealm          [3] Realm,
-           cname           [4] PrincipalName,
-           ticket          [5] Ticket,
-           enc-part        [6] EncryptedData
-                                   -- EncASRepPart or EncTGSRepPart,
-                                   -- as appropriate
-   }
-
-   EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
-
-   EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
-
-   EncKDCRepPart   ::= SEQUENCE {
-           key             [0] EncryptionKey,
-           last-req        [1] LastReq,
-           nonce           [2] UInt32,
-           key-expiration  [3] KerberosTime OPTIONAL,
-           flags           [4] TicketFlags,
-           authtime        [5] KerberosTime,
-           starttime       [6] KerberosTime OPTIONAL,
-           endtime         [7] KerberosTime,
-           renew-till      [8] KerberosTime OPTIONAL,
-           srealm          [9] Realm,
-           sname           [10] PrincipalName,
-           caddr           [11] HostAddresses OPTIONAL
-   }
-
-   LastReq         ::=     SEQUENCE OF SEQUENCE {
-           lr-type         [0] Int32,
-           lr-value        [1] KerberosTime
-   }
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      either KRB_AS_REP or KRB_TGS_REP.
-
-
-
-March 2003                                                     [Page 81]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   padata
-      This field is described in detail in section 5.4.1. One possible
-      use for this field is to encode an alternate "salt" string to be
-      used with a string-to-key algorithm. This ability is useful to
-      ease transitions if a realm name needs to change (e.g. when a
-      company is acquired); in such a case all existing password-derived
-      entries in the KDC database would be flagged as needing a special
-      salt string until the next password change.
-
-   crealm, cname, srealm and sname
-      These fields are the same as those described for the ticket in
-      section 5.3.
-
-   ticket
-      The newly-issued ticket, from section 5.3.
-
-   enc-part
-      This field is a place holder for the ciphertext and related
-      information that forms the encrypted part of a message. The
-      description of the encrypted part of the message follows each
-      appearance of this field.
-
-      The key usage value for encrypting this field is 3 in an AS-REP
-      message, using the client's long-term key or another key selected
-      via pre-authentication mechanisms. In a TGS-REP message, the key
-      usage value is 8 if the TGS session key is used, or 9 if a TGS
-      authenticator subkey is used.
-
-      Compatibility note: Some implementations unconditionally send an
-      encrypted EncTGSRepPart (application tag number 26) in this field
-      regardless of whether the reply is a AS-REP or a TGS-REP. In the
-      interests of compatibility, implementors MAY relax the check on
-      the tag number of the decrypted ENC-PART.
-
-   key
-      This field is the same as described for the ticket in section 5.3.
-
-   last-req
-      This field is returned by the KDC and specifies the time(s) of the
-      last request by a principal. Depending on what information is
-      available, this might be the last time that a request for a
-      ticket-granting ticket was made, or the last time that a request
-      based on a ticket-granting ticket was successful. It also might
-      cover all servers for a realm, or just the particular server. Some
-      implementations MAY display this information to the user to aid in
-      discovering unauthorized use of one's identity. It is similar in
-      spirit to the last login time displayed when logging into
-      timesharing systems.
-
-
-
-March 2003                                                     [Page 82]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      lr-type
-         This field indicates how the following lr-value field is to be
-         interpreted. Negative values indicate that the information
-         pertains only to the responding server. Non-negative values
-         pertain to all servers for the realm.
-
-         If the lr-type field is zero (0), then no information is
-         conveyed by the lr-value subfield. If the absolute value of the
-         lr-type field is one (1), then the lr-value subfield is the
-         time of last initial request for a TGT. If it is two (2), then
-         the lr-value subfield is the time of last initial request. If
-         it is three (3), then the lr-value subfield is the time of
-         issue for the newest ticket-granting ticket used. If it is four
-         (4), then the lr-value subfield is the time of the last
-         renewal. If it is five (5), then the lr-value subfield is the
-         time of last request (of any type).  If it is (6), then the lr-
-         value subfield is the time when the password will expire.  If
-         it is (7), then the lr-value subfield is the time when the
-         account will expire.
-
-      lr-value
-         This field contains the time of the last request. The time MUST
-         be interpreted according to the contents of the accompanying
-         lr-type subfield.
-
-   nonce
-      This field is described above in section 5.4.1.
-
-   key-expiration
-      The key-expiration field is part of the response from the KDC and
-      specifies the time that the client's secret key is due to expire.
-      The expiration might be the result of password aging or an account
-      expiration. If present, it SHOULD be set to the earliest of the
-      user's key expiration and account expiration.  The use of this
-      field is deprecated and the last-req field SHOULD be used to
-      convey this information instead.  This field will usually be left
-      out of the TGS reply since the response to the TGS request is
-      encrypted in a session key and no client information need be
-      retrieved from the KDC database. It is up to the application
-      client (usually the login program) to take appropriate action
-      (such as notifying the user) if the expiration time is imminent.
-
-   flags, authtime, starttime, endtime, renew-till and caddr
-      These fields are duplicates of those found in the encrypted
-      portion of the attached ticket (see section 5.3), provided so the
-      client MAY verify they match the intended request and to assist in
-      proper ticket caching. If the message is of type KRB_TGS_REP, the
-      caddr field will only be filled in if the request was for a proxy
-
-
-
-March 2003                                                     [Page 83]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      or forwarded ticket, or if the user is substituting a subset of
-      the addresses from the ticket-granting ticket. If the client-
-      requested addresses are not present or not used, then the
-      addresses contained in the ticket will be the same as those
-      included in the ticket-granting ticket.
-
-5.5. Client/Server (CS) message specifications
-
-   This section specifies the format of the messages used for the
-   authentication of the client to the application server.
-
-5.5.1. KRB_AP_REQ definition
-
-   The KRB_AP_REQ message contains the Kerberos protocol version number,
-   the message type KRB_AP_REQ, an options field to indicate any options
-   in use, and the ticket and authenticator themselves. The KRB_AP_REQ
-   message is often referred to as the 'authentication header'.
-
-   AP-REQ          ::= [APPLICATION 14] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (14),
-           ap-options      [2] APOptions,
-           ticket          [3] Ticket,
-           authenticator   [4] EncryptedData -- Authenticator
-   }
-
-   APOptions       ::= KerberosFlags
-           -- reserved(0),
-           -- use-session-key(1),
-           -- mutual-required(2)
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_AP_REQ.
-
-   ap-options
-      This field appears in the application request (KRB_AP_REQ) and
-      affects the way the request is processed. It is a bit-field, where
-      the selected options are indicated by the bit being set (1), and
-      the unselected options and reserved fields being reset (0). The
-      encoding of the bits is specified in section 5.2. The meanings of
-      the options are:
-
-         Bit(s)  Name            Description
-
-         0       reserved        Reserved for future expansion of this field.
-
-                                 The USE-SESSION-KEY option indicates that the
-
-
-
-March 2003                                                     [Page 84]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-                                 ticket the client is presenting to a server
-         1       use-session-key is encrypted in the session key from the
-                                 server's ticket-granting ticket. When this
-                                 option is not specified, the ticket is
-                                 encrypted in the server's secret key.
-
-                                 The MUTUAL-REQUIRED option tells the server
-         2       mutual-required that the client requires mutual
-                                 authentication, and that it must respond with
-                                 a KRB_AP_REP message.
-
-         3-31    reserved        Reserved for future use.
-
-   ticket
-      This field is a ticket authenticating the client to the server.
-
-   authenticator
-      This contains the encrypted authenticator, which includes the
-      client's choice of a subkey.
-
-   The encrypted authenticator is included in the AP-REQ; it certifies
-   to a server that the sender has recent knowledge of the encryption
-   key in the accompanying ticket, to help the server detect replays. It
-   also assists in the selection of a "true session key" to use with the
-   particular session.  The DER encoding of the following is encrypted
-   in the ticket's session key, with a key usage value of 11 in normal
-   application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field
-   of a TGS-REQ exchange (see section 5.4.1):
-
-   -- Unencrypted authenticator
-   Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-           authenticator-vno       [0] INTEGER (5),
-           crealm                  [1] Realm,
-           cname                   [2] PrincipalName,
-           cksum                   [3] Checksum OPTIONAL,
-           cusec                   [4] Microseconds,
-           ctime                   [5] KerberosTime,
-           subkey                  [6] EncryptionKey OPTIONAL,
-           seq-number              [7] UInt32 OPTIONAL,
-           authorization-data      [8] AuthorizationData OPTIONAL
-   }
-
-   authenticator-vno
-      This field specifies the version number for the format of the
-      authenticator. This document specifies version 5.
-
-   crealm and cname
-      These fields are the same as those described for the ticket in
-
-
-
-March 2003                                                     [Page 85]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      section 5.3.
-
-   cksum
-      This field contains a checksum of the application data that
-      accompanies the KRB_AP_REQ, computed using a key usage value of 10
-      in normal application exchanges, or 6 when used in the TGS-REQ PA-
-      TGS-REQ AP-DATA field.
-
-   cusec
-      This field contains the microsecond part of the client's
-      timestamp. Its value (before encryption) ranges from 0 to 999999.
-      It often appears along with ctime. The two fields are used
-      together to specify a reasonably accurate timestamp.
-
-   ctime
-      This field contains the current time on the client's host.
-
-   subkey
-      This field contains the client's choice for an encryption key
-      which is to be used to protect this specific application session.
-      Unless an application specifies otherwise, if this field is left
-      out the session key from the ticket will be used.
-
-   seq-number
-      This optional field includes the initial sequence number to be
-      used by the KRB_PRIV or KRB_SAFE messages when sequence numbers
-      are used to detect replays (It may also be used by application
-      specific messages).  When included in the authenticator this field
-      specifies the initial sequence number for messages from the client
-      to the server. When included in the AP-REP message, the initial
-      sequence number is that for messages from the server to the
-      client. When used in KRB_PRIV or KRB_SAFE messages, it is
-      incremented by one after each message is sent.  Sequence numbers
-      fall in the range of 0 through 2^32 - 1 and wrap to zero following
-      the value 2^32 - 1.
-
-      For sequence numbers to adequately support the detection of
-      replays they SHOULD be non-repeating, even across connection
-      boundaries. The initial sequence number SHOULD be random and
-      uniformly distributed across the full space of possible sequence
-      numbers, so that it cannot be guessed by an attacker and so that
-      it and the successive sequence numbers do not repeat other
-      sequences.
-
-      Implmentation note: historically, some implementations transmit
-      signed twos-complement numbers for sequence numbers. In the
-      interests of compatibility, implementations MAY accept the
-      equivalent negative number where a positive number greater than
-
-
-
-March 2003                                                     [Page 86]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      2^31 - 1 is expected.
-
-      Implementation note: as noted before, some implementations omit
-      the optional sequence number when its value would be zero.
-      Implementations MAY accept an omitted sequence number when
-      expecting a value of zero, and SHOULD NOT transmit an
-      Authenticator with a initial sequence number of zero.
-
-   authorization-data
-      This field is the same as described for the ticket in section 5.3.
-      It is optional and will only appear when additional restrictions
-      are to be placed on the use of a ticket, beyond those carried in
-      the ticket itself.
-
-5.5.2. KRB_AP_REP definition
-
-   The KRB_AP_REP message contains the Kerberos protocol version number,
-   the message type, and an encrypted time-stamp. The message is sent in
-   response to an application request (KRB_AP_REQ) where the mutual
-   authentication option has been selected in the ap-options field.
-
-   AP-REP          ::= [APPLICATION 15] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (15),
-           enc-part        [2] EncryptedData -- EncAPRepPart
-   }
-
-   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
-           ctime           [0] KerberosTime,
-           cusec           [1] Microseconds,
-           subkey          [2] EncryptionKey OPTIONAL,
-           seq-number      [3] UInt32 OPTIONAL
-   }
-
-   The encoded EncAPRepPart is encrypted in the shared session key of
-   the ticket. The optional subkey field can be used in an application-
-   arranged negotiation to choose a per association session key.
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_AP_REP.
-
-   enc-part
-      This field is described above in section 5.4.2. It is computed
-      with a key usage value of 12.
-
-   ctime
-      This field contains the current time on the client's host.
-
-
-
-March 2003                                                     [Page 87]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   cusec
-      This field contains the microsecond part of the client's
-      timestamp.
-
-   subkey
-      This field contains an encryption key which is to be used to
-      protect this specific application session. See section 3.2.6 for
-      specifics on how this field is used to negotiate a key. Unless an
-      application specifies otherwise, if this field is left out, the
-      sub-session key from the authenticator, or if also left out, the
-      session key from the ticket will be used.
-
-   seq-number
-      This field is described above in section 5.3.2.
-
-5.5.3. Error message reply
-
-   If an error occurs while processing the application request, the
-   KRB_ERROR message will be sent in response. See section 5.9.1 for the
-   format of the error message. The cname and crealm fields MAY be left
-   out if the server cannot determine their appropriate values from the
-   corresponding KRB_AP_REQ message. If the authenticator was
-   decipherable, the ctime and cusec fields will contain the values from
-   it.
-
-5.6. KRB_SAFE message specification
-
-   This section specifies the format of a message that can be used by
-   either side (client or server) of an application to send a tamper-
-   proof message to its peer. It presumes that a session key has
-   previously been exchanged (for example, by using the
-   KRB_AP_REQ/KRB_AP_REP messages).
-
-5.6.1. KRB_SAFE definition
-
-   The KRB_SAFE message contains user data along with a collision-proof
-   checksum keyed with the last encryption key negotiated via subkeys,
-   or the session key if no negotiation has occurred. The message fields
-   are:
-
-   KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (20),
-           safe-body       [2] KRB-SAFE-BODY,
-           cksum           [3] Checksum
-   }
-
-   KRB-SAFE-BODY   ::= SEQUENCE {
-
-
-
-March 2003                                                     [Page 88]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-           user-data       [0] OCTET STRING,
-           timestamp       [1] KerberosTime OPTIONAL,
-           usec            [2] Microseconds OPTIONAL,
-           seq-number      [3] UInt32 OPTIONAL,
-           s-address       [4] HostAddress,
-           r-address       [5] HostAddress OPTIONAL
-   }
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_SAFE.
-
-   safe-body
-      This field is a placeholder for the body of the KRB-SAFE message.
-
-   cksum
-      This field contains the checksum of the application data, computed
-      with a key usage value of 15.
-
-      The checksum is computed over the encoding of the KRB-SAFE
-      sequence.  First, the cksum is set to a type zero, zero-length
-      value and the checksum is computed over the encoding of the KRB-
-      SAFE sequence, then the checksum is set to the result of that
-      computation, and finally the KRB-SAFE sequence is encoded again.
-      This method, while different than the one specified in RFC 1510,
-      corresponds to existing practice.
-
-   user-data
-      This field is part of the KRB_SAFE and KRB_PRIV messages and
-      contain the application specific data that is being passed from
-      the sender to the recipient.
-
-   timestamp
-      This field is part of the KRB_SAFE and KRB_PRIV messages. Its
-      contents are the current time as known by the sender of the
-      message. By checking the timestamp, the recipient of the message
-      is able to make sure that it was recently generated, and is not a
-      replay.
-
-   usec
-      This field is part of the KRB_SAFE and KRB_PRIV headers. It
-      contains the microsecond part of the timestamp.
-
-   seq-number
-      This field is described above in section 5.3.2.
-
-   s-address
-      Sender's address.
-
-
-
-March 2003                                                     [Page 89]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      This field specifies the address in use by the sender of the
-      message.  It MAY be omitted if not required by the application
-      protocol.
-
-   r-address
-      This field specifies the address in use by the recipient of the
-      message. It MAY be omitted for some uses (such as broadcast
-      protocols), but the recipient MAY arbitrarily reject such
-      messages. This field, along with s-address, can be used to help
-      detect messages which have been incorrectly or maliciously
-      delivered to the wrong recipient.
-
-5.7. KRB_PRIV message specification
-
-   This section specifies the format of a message that can be used by
-   either side (client or server) of an application to securely and
-   privately send a message to its peer. It presumes that a session key
-   has previously been exchanged (for example, by using the
-   KRB_AP_REQ/KRB_AP_REP messages).
-
-5.7.1. KRB_PRIV definition
-
-   The KRB_PRIV message contains user data encrypted in the Session Key.
-   The message fields are:
-
-   KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (21),
-                           -- NOTE: there is no [2] tag
-           enc-part        [3] EncryptedData -- EncKrbPrivPart
-   }
-
-   EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-           user-data       [0] OCTET STRING,
-           timestamp       [1] KerberosTime OPTIONAL,
-           usec            [2] Microseconds OPTIONAL,
-           seq-number      [3] UInt32 OPTIONAL,
-           s-address       [4] HostAddress -- sender's addr --,
-           r-address       [5] HostAddress OPTIONAL -- recip's addr
-   }
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_PRIV.
-
-   enc-part
-      This field holds an encoding of the EncKrbPrivPart sequence
-      encrypted under the session key, with a key usage value of 13.
-
-
-
-March 2003                                                     [Page 90]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      This encrypted encoding is used for the enc-part field of the KRB-
-      PRIV message.
-
-   user-data, timestamp, usec, s-address and r-address
-      These fields are described above in section 5.6.1.
-
-   seq-number
-      This field is described above in section 5.3.2.
-
-5.8. KRB_CRED message specification
-
-   This section specifies the format of a message that can be used to
-   send Kerberos credentials from one principal to another. It is
-   presented here to encourage a common mechanism to be used by
-   applications when forwarding tickets or providing proxies to
-   subordinate servers. It presumes that a session key has already been
-   exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages.
-
-5.8.1. KRB_CRED definition
-
-   The KRB_CRED message contains a sequence of tickets to be sent and
-   information needed to use the tickets, including the session key from
-   each.  The information needed to use the tickets is encrypted under
-   an encryption key previously exchanged or transferred alongside the
-   KRB_CRED message. The message fields are:
-
-   KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (22),
-           tickets         [2] SEQUENCE OF Ticket,
-           enc-part        [3] EncryptedData -- EncKrbCredPart
-   }
-
-   EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-           ticket-info     [0] SEQUENCE OF KrbCredInfo,
-           nonce           [1] UInt32 OPTIONAL,
-           timestamp       [2] KerberosTime OPTIONAL,
-           usec            [3] Microseconds OPTIONAL,
-           s-address       [4] HostAddress OPTIONAL,
-           r-address       [5] HostAddress OPTIONAL
-   }
-
-   KrbCredInfo     ::= SEQUENCE {
-           key             [0] EncryptionKey,
-           prealm          [1] Realm OPTIONAL,
-           pname           [2] PrincipalName OPTIONAL,
-           flags           [3] TicketFlags OPTIONAL,
-           authtime        [4] KerberosTime OPTIONAL,
-
-
-
-March 2003                                                     [Page 91]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-           starttime       [5] KerberosTime OPTIONAL,
-           endtime         [6] KerberosTime OPTIONAL,
-           renew-till      [7] KerberosTime OPTIONAL,
-           srealm          [8] Realm OPTIONAL,
-           sname           [9] PrincipalName OPTIONAL,
-           caddr           [10] HostAddresses OPTIONAL
-   }
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_CRED.
-
-   tickets
-      These are the tickets obtained from the KDC specifically for use
-      by the intended recipient. Successive tickets are paired with the
-      corresponding KrbCredInfo sequence from the enc-part of the KRB-
-      CRED message.
-
-   enc-part
-      This field holds an encoding of the EncKrbCredPart sequence
-      encrypted under the session key shared between the sender and the
-      intended recipient, with a key usage value of 14. This encrypted
-      encoding is used for the enc-part field of the KRB-CRED message.
-
-      Implementation note: implementations of certain applications, most
-      notably certain implementations of the Kerberos GSS-API mechanism,
-      do not separately encrypt the contents of the EncKrbCredPart of
-      the KRB-CRED message when sending it.  In the case of those GSS-
-      API mechanisms, this is not a security vulnerability, as the
-      entire KRB-CRED message is itself embedded in an encrypted
-      message.
-
-   nonce
-      If practical, an application MAY require the inclusion of a nonce
-      generated by the recipient of the message. If the same value is
-      included as the nonce in the message, it provides evidence that
-      the message is fresh and has not been replayed by an attacker. A
-      nonce MUST NEVER be reused; it SHOULD be generated randomly by the
-      recipient of the message and provided to the sender of the message
-      in an application specific manner.
-
-   timestamp and usec
-      These fields specify the time that the KRB-CRED message was
-      generated.  The time is used to provide assurance that the message
-      is fresh.
-
-   s-address and r-address
-      These fields are described above in section 5.6.1. They are used
-
-
-
-March 2003                                                     [Page 92]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      optionally to provide additional assurance of the integrity of the
-      KRB-CRED message.
-
-   key
-      This field exists in the corresponding ticket passed by the KRB-
-      CRED message and is used to pass the session key from the sender
-      to the intended recipient. The field's encoding is described in
-      section 5.2.9.
-
-   The following fields are optional. If present, they can be associated
-   with the credentials in the remote ticket file. If left out, then it
-   is assumed that the recipient of the credentials already knows their
-   value.
-
-   prealm and pname
-      The name and realm of the delegated principal identity.
-
-   flags, authtime, starttime, endtime, renew-till, srealm, sname, and
-      caddr
-      These fields contain the values of the corresponding fields from
-      the ticket found in the ticket field. Descriptions of the fields
-      are identical to the descriptions in the KDC-REP message.
-
-5.9. Error message specification
-
-   This section specifies the format for the KRB_ERROR message. The
-   fields included in the message are intended to return as much
-   information as possible about an error. It is not expected that all
-   the information required by the fields will be available for all
-   types of errors. If the appropriate information is not available when
-   the message is composed, the corresponding field will be left out of
-   the message.
-
-   Note that since the KRB_ERROR message is not integrity protected, it
-   is quite possible for an intruder to synthesize or modify such a
-   message. In particular, this means that the client SHOULD NOT use any
-   fields in this message for security-critical purposes, such as
-   setting a system clock or generating a fresh authenticator. The
-   message can be useful, however, for advising a user on the reason for
-   some failure.
-
-5.9.1. KRB_ERROR definition
-
-   The KRB_ERROR message consists of the following fields:
-
-   KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (30),
-
-
-
-March 2003                                                     [Page 93]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-           ctime           [2] KerberosTime OPTIONAL,
-           cusec           [3] Microseconds OPTIONAL,
-           stime           [4] KerberosTime,
-           susec           [5] Microseconds,
-           error-code      [6] Int32,
-           crealm          [7] Realm OPTIONAL,
-           cname           [8] PrincipalName OPTIONAL,
-           realm           [9] Realm -- service realm --,
-           sname           [10] PrincipalName -- service name --,
-           e-text          [11] KerberosString OPTIONAL,
-           e-data          [12] OCTET STRING OPTIONAL
-   }
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. +A msg-type is
-      KRB_ERROR.
-
-   ctime
-      This field is described above in section 5.4.1.
-
-   cusec
-      This field is described above in section 5.5.2.
-
-   stime
-      This field contains the current time on the server. It is of type
-      KerberosTime.
-
-   susec
-      This field contains the microsecond part of the server's
-      timestamp. Its value ranges from 0 to 999999. It appears along
-      with stime. The two fields are used in conjunction to specify a
-      reasonably accurate timestamp.
-
-   error-code
-      This field contains the error code returned by Kerberos or the
-      server when a request fails. To interpret the value of this field
-      see the list of error codes in section 7.5.9. Implementations are
-      encouraged to provide for national language support in the display
-      of error messages.
-
-   crealm, cname, srealm and sname
-      These fields are described above in section 5.3.
-
-   e-text
-      This field contains additional text to help explain the error code
-      associated with the failed request (for example, it might include
-      a principal name which was unknown).
-
-
-
-
-March 2003                                                     [Page 94]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   e-data
-      This field contains additional data about the error for use by the
-      application to help it recover from or handle the error. If the
-      errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
-      contain an encoding of a sequence of padata fields, each
-      corresponding to an acceptable pre-authentication method and
-      optionally containing data for the method:
-
-      METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-   For error codes defined in this document other than
-   KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field
-   are implementation-defined. Similarly, for future error codes, the
-   format and contents of the e-data field are implementation-defined
-   unless specified. Whether defined by the implementation or in a
-   future document, the e-data field MAY take the form of TYPED-DATA:
-
-   TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-           data-type       [0] INTEGER,
-           data-value      [1] OCTET STRING OPTIONAL
-   }
-
-5.10. Application Tag Numbers
-
-   The following table lists the application class tag numbers used by
-   various data types defined in this section.
-
-    Tag Number(s)    Type Name    Comments
-
-    0                             unused
-
-    1              Ticket         PDU
-
-    2              Authenticator  non-PDU
-
-    3              EncTicketPart  non-PDU
-
-    4-9                           unused
-
-    10             AS-REQ         PDU
-
-    11             AS-REP         PDU
-
-    12             TGS-REQ        PDU
-
-    13             TGS-REP        PDU
-
-    14             AP-REQ         PDU
-
-
-
-March 2003                                                     [Page 95]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-    15             AP-REP         PDU
-
-    16             RESERVED16     TGT-REQ (for user-to-user)
-
-    17             RESERVED17     TGT-REP (for user-to-user)
-
-    18-19                         unused
-
-    20             KRB-SAFE       PDU
-
-    21             KRB-PRIV       PDU
-
-    22             KRB-CRED       PDU
-
-    23-24                         unused
-
-    25             EncASRepPart   non-PDU
-
-    26             EncTGSRepPart  non-PDU
-
-    27             EncApRepPart   non-PDU
-
-    28             EncKrbPrivPart non-PDU
-
-    29             EncKrbCredPart non-PDU
-
-    30             KRB-ERROR      PDU
-
-   The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above are
-   the only ASN.1 types intended as top-level types of the Kerberos
-   protcol, and are the only types that may be used as elements in
-   another protocol that makes use of Kerberos.
-
-6. Naming Constraints
-
-6.1. Realm Names
-
-   Although realm names are encoded as GeneralStrings and although a
-   realm can technically select any name it chooses, interoperability
-   across realm boundaries requires agreement on how realm names are to
-   be assigned, and what information they imply.
-
-   To enforce these conventions, each realm MUST conform to the
-   conventions itself, and it MUST require that any realms with which
-   inter-realm keys are shared also conform to the conventions and
-   require the same from its neighbors.
-
-   Kerberos realm names are case sensitive. Realm names that differ only
-
-
-
-March 2003                                                     [Page 96]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   in the case of the characters are not equivalent. There are presently
-   three styles of realm names: domain, X500, and other. Examples of
-   each style follow:
-
-        domain:   ATHENA.MIT.EDU
-          X500:   C=US/O=OSF
-         other:   NAMETYPE:rest/of.name=without-restrictions
-
-   Domain syle realm names MUST look like domain names: they consist of
-   components separated by periods (.) and they contain neither colons
-   (:) nor slashes (/). Though domain names themselves are case
-   insensitive, in order for realms to match, the case must match as
-   well. When establishing a new realm name based on an internet domain
-   name it is recommended by convention that the characters be converted
-   to upper case.
-
-   X.500 names contain an equal (=) and cannot contain a colon (:)
-   before the equal. The realm names for X.500 names will be string
-   representations of the names with components separated by slashes.
-   Leading and trailing slashes will not be included. Note that the
-   slash separator is consistent with Kerberos implementations based on
-   RFC1510, but it is different from the separator recommended in
-   RFC2253.
-
-   Names that fall into the other category MUST begin with a prefix that
-   contains no equal (=) or period (.) and the prefix MUST be followed
-   by a colon (:) and the rest of the name. All prefixes must be
-   assigned before they may be used. Presently none are assigned.
-
-   The reserved category includes strings which do not fall into the
-   first three categories. All names in this category are reserved. It
-   is unlikely that names will be assigned to this category unless there
-   is a very strong argument for not using the 'other' category.
-
-   These rules guarantee that there will be no conflicts between the
-   various name styles. The following additional constraints apply to
-   the assignment of realm names in the domain and X.500 categories: the
-   name of a realm for the domain or X.500 formats must either be used
-   by the organization owning (to whom it was assigned) an Internet
-   domain name or X.500 name, or in the case that no such names are
-   registered, authority to use a realm name MAY be derived from the
-   authority of the parent realm. For example, if there is no domain
-   name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
-   authorize the creation of a realm with that name.
-
-   This is acceptable because the organization to which the parent is
-   assigned is presumably the organization authorized to assign names to
-   its children in the X.500 and domain name systems as well. If the
-
-
-
-March 2003                                                     [Page 97]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   parent assigns a realm name without also registering it in the domain
-   name or X.500 hierarchy, it is the parent's responsibility to make
-   sure that there will not in the future exist a name identical to the
-   realm name of the child unless it is assigned to the same entity as
-   the realm name.
-
-6.2. Principal Names
-
-   As was the case for realm names, conventions are needed to ensure
-   that all agree on what information is implied by a principal name.
-   The name-type field that is part of the principal name indicates the
-   kind of information implied by the name. The name-type SHOULD be
-   treated only as a hint to interpreting the meaning of a name. It is
-   not significant when checking for equivalence. Principal names that
-   differ only in the name-type identify the same principal. The name
-   type does not partition the name space. Ignoring the name type, no
-   two names can be the same (i.e. at least one of the components, or
-   the realm, MUST be different). The following name types are defined:
-
-   name-type      value   meaning
-
-   name types
-
-   NT-UNKNOWN        0  Name type not known
-   NT-PRINCIPAL      1  Just the name of the principal as in DCE, or for users
-   NT-SRV-INST       2  Service and other unique instance (krbtgt)
-   NT-SRV-HST        3  Service with host name as instance (telnet, rcommands)
-   NT-SRV-XHST       4  Service with host as remaining components
-   NT-UID            5  Unique ID
-   NT-X500-PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
-   NT-SMTP-NAME      7  Name in form of SMTP email name (e.g. user@foo.com)
-   NT-ENTERPRISE    10   Enterprise name - may be mapped to principal name
-
-   When a name implies no information other than its uniqueness at a
-   particular time the name type PRINCIPAL SHOULD be used. The principal
-   name type SHOULD be used for users, and it might also be used for a
-   unique server. If the name is a unique machine generated ID that is
-   guaranteed never to be reassigned then the name type of UID SHOULD be
-   used (note that it is generally a bad idea to reassign names of any
-   type since stale entries might remain in access control lists).
-
-   If the first component of a name identifies a service and the
-   remaining components identify an instance of the service in a server
-   specified manner, then the name type of SRV-INST SHOULD be used. An
-   example of this name type is the Kerberos ticket-granting service
-   whose name has a first component of krbtgt and a second component
-   identifying the realm for which the ticket is valid.
-
-
-
-
-March 2003                                                     [Page 98]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   If the first component of a name identifies a service and there is a
-   single component following the service name identifying the instance
-   as the host on which the server is running, then the name type SRV-
-   HST SHOULD be used. This type is typically used for Internet services
-   such as telnet and the Berkeley R commands. If the separate
-   components of the host name appear as successive components following
-   the name of the service, then the name type SRV-XHST SHOULD be used.
-   This type might be used to identify servers on hosts with X.500 names
-   where the slash (/) might otherwise be ambiguous.
-
-   A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an
-   X.509 certificate is translated into a Kerberos name. The encoding of
-   the X.509 name as a Kerberos principal shall conform to the encoding
-   rules specified in RFC 2253.
-
-   A name type of SMTP allows a name to be of a form that resembles a
-   SMTP email name. This name, including an "@" and a domain name, is
-   used as the one component of the principal name.
-
-   A name type of UNKNOWN SHOULD be used when the form of the name is
-   not known. When comparing names, a name of type UNKNOWN will match
-   principals authenticated with names of any type. A principal
-   authenticated with a name of type UNKNOWN, however, will only match
-   other names of type UNKNOWN.
-
-   Names of any type with an initial component of 'krbtgt' are reserved
-   for the Kerberos ticket granting service. See section 7.5.8 for the
-   form of such names.
-
-6.2.1. Name of server principals
-
-   The principal identifier for a server on a host will generally be
-   composed of two parts: (1) the realm of the KDC with which the server
-   is registered, and (2) a two-component name of type NT-SRV-HST if the
-   host name is an Internet domain name or a multi-component name of
-   type NT-SRV-XHST if the name of the host is of a form such as X.500
-   that allows slash (/) separators. The first component of the two- or
-   multi-component name will identify the service and the latter
-   components will identify the host. Where the name of the host is not
-   case sensitive (for example, with Internet domain names) the name of
-   the host MUST be lower case. If specified by the application protocol
-   for services such as telnet and the Berkeley R commands which run
-   with system privileges, the first component MAY be the string 'host'
-   instead of a service specific identifier. When a host has an official
-   name and one or more aliases and the official name can be reliably
-   determined, the official name of the host SHOULD be used when
-   constructing the name of the server principal.
-
-
-
-
-March 2003                                                     [Page 99]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-7. Constants and other defined values
-
-7.1. Host address types
-
-   All negative values for the host address type are reserved for local
-   use.  All non-negative values are reserved for officially assigned
-   type fields and interpretations.
-
-   Internet (IPv4) Addresses
-
-      Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded
-      in MSB order. The IPv4 loopback address SHOULD NOT appear in a
-      Kerberos packet. The type of IPv4 addresses is two (2).
-
-   Internet (IPv6) Addresses
-
-      IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities,
-      encoded in MSB order. The type of IPv6 addresses is twenty-four
-      (24). The following addresses MUST NOT appear in any Kerberos
-      packet:
-
-         *  the Unspecified Address
-         *  the Loopback Address
-         *  Link-Local addresses
-
-      IPv4-mapped IPv6 addresses MUST be represented as addresses of
-      type 2.
-
-   DECnet Phase IV addresses
-
-      DECnet Phase IV addresses are 16-bit addresses, encoded in LSB
-      order. The type of DECnet Phase IV addresses is twelve (12).
-
-   Netbios addresses
-
-      Netbios addresses are 16-octet addresses typically composed of 1
-      to 15 alphanumeric characters and padded with the US-ASCII SPC
-      character (code 32).  The 16th octet MUST be the US-ASCII NUL
-      character (code 0).  The type of Netbios addresses is twenty (20).
-
-   Directional Addresses
-
-      In many environments, including the sender address in KRB_SAFE and
-      KRB_PRIV messages is undesirable because the addresses may be
-      changed in transport by network address translators. However, if
-      these addresses are removed, the messages may be subject to a
-      reflection attack in which a message is reflected back to its
-      originator. The directional address type provides a way to avoid
-
-
-
-March 2003                                                    [Page 100]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      transport addresses and reflection attacks. Directional addresses
-      are encoded as four byte unsigned integers in network byte order.
-      If the message is originated by the party sending the original
-      KRB_AP_REQ message, then an address of 0 SHOULD be used. If the
-      message is originated by the party to whom that KRB_AP_REQ was
-      sent, then the address 1 SHOULD be used. Applications involving
-      multiple parties can specify the use of other addresses.
-
-      Directional addresses MUST only be used for the sender address
-      field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used
-      as a ticket address or in a KRB_AP_REQ message. This address type
-      SHOULD only be used in situations where the sending party knows
-      that the receiving party supports the address type. This generally
-      means that directional addresses may only be used when the
-      application protocol requires their support. Directional addresses
-      are type (3).
-
-7.2. KDC messaging - IP Transports
-
-   Kerberos defines two IP transport mechanisms for communication
-   between clients and servers: UDP/IP and TCP/IP.
-
-7.2.1. UDP/IP transport
-
-   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
-   requests and SHOULD listen for such requests on port 88 (decimal)
-   unless specifically configured to listen on an alternative UDP port.
-   Alternate ports MAY be used when running multiple KDCs for multiple
-   realms on the same host.
-
-   Kerberos clients supporting IP transports SHOULD support the sending
-   of UDP requests. Clients SHOULD use KDC discovery [7.2.3] to identify
-   the IP address and port to which they will send their request.
-
-   When contacting a KDC for a KRB_KDC_REQ request using UDP/IP
-   transport, the client shall send a UDP datagram containing only an
-   encoding of the request to the KDC. The KDC will respond with a reply
-   datagram containing only an encoding of the reply message (either a
-   KRB_ERROR or a KRB_KDC_REP) to the sending port at the sender's IP
-   address. The response to a request made through UDP/IP transport MUST
-   also use UDP/IP transport. If the response can not be handled using
-   UDP (for example because it is too large), the KDC MUST return
-   KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the request
-   using the TCP transport.
-
-7.2.2. TCP/IP transport
-
-   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
-
-
-
-March 2003                                                    [Page 101]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   requests and SHOULD listen for such requests on port 88 (decimal)
-   unless specifically configured to listen on an alternate TCP port.
-   Alternate ports MAY be used when running multiple KDCs for multiple
-   realms on the same host.
-
-   Clients MUST support the sending of TCP requests, but MAY choose to
-   intially try a request using the UDP transport. Clients SHOULD use
-   KDC discovery [7.2.3] to identify the IP address and port to which
-   they will send their request.
-
-   Implementation note: Some extensions to the Kerberos protocol will
-   not succeed if any client or KDC not supporting the TCP transport is
-   involved.  Implementations of RFC 1510 were not required to support
-   TCP/IP transports.
-
-   When the KRB_KDC_REQ message is sent to the KDC over a TCP stream,
-   the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to
-   the client on the same TCP stream that was established for the
-   request. The KDC MAY close the TCP stream after sending a response,
-   but MAY leave the stream open for a reasonable period of time if it
-   expects a followup. Care must be taken in managing TCP/IP connections
-   on the KDC to prevent denial of service attacks based on the number
-   of open TCP/IP connections.
-
-   The client MUST be prepared to have the stream closed by the KDC at
-   anytime after the receipt of a response. A stream closure SHOULD NOT
-   be treated as a fatal error. Instead, if multiple exchanges are
-   required (e.g., certain forms of pre-authentication) the client may
-   need to establish a new connection when it is ready to send
-   subsequent messages. A client MAY close the stream after receiving a
-   response, and SHOULD close the stream if it does not expect to send
-   followup messages.
-
-   A client MAY send multiple requests before receiving responses,
-   though it must be prepared to handle the connection being closed
-   after the first response.
-
-   Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR)
-   sent over the TCP stream is preceded by the length of the request as
-   4 octets in network byte order. The high bit of the length is
-   reserved for future expansion and MUST currently be set to zero.
-
-   If multiple requests are sent over a single TCP connection, and the
-   KDC sends multiple responses, the KDC is not required to send the
-   responses in the order of the corresponding requests. This may permit
-   some implementations to send each response as soon as it is ready
-   even if earlier requests are still being processed (for example,
-   waiting for a response from an external device or database).
-
-
-
-March 2003                                                    [Page 102]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-7.2.3. KDC Discovery on IP Networks
-
-   Kerberos client implementations MUST provide a means for the client
-   to determine the location of the Kerberos Key Distribution Centers
-   (KDCs).  Traditionally, Kerberos implementations have stored such
-   configuration information in a file on each client machine.
-   Experience has shown this method of storing configuration information
-   presents problems with out-of-date information and scaling problems,
-   especially when using cross-realm authentication. This section
-   describes a method for using the Domain Name System [RFC 1035] for
-   storing KDC location information.
-
-7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names
-
-   In Kerberos, realm names are case sensitive. While it is strongly
-   encouraged that all realm names be all upper case this recommendation
-   has not been adopted by all sites. Some sites use all lower case
-   names and other use mixed case. DNS on the other hand is case
-   insensitive for queries. Since "MYREALM", "myrealm", and "MyRealm"
-   are all different it is necessary that only one of the possible
-   combinations of upper and lower case characters be used. This
-   restriction may be lifted in the future as the DNS naming scheme is
-   expanded to support non-US-ASCII names.
-
-7.2.3.2. Specifying KDC Location information with DNS SRV records
-
-   KDC location information is to be stored using the DNS SRV RR [RFC
-   2052].  The format of this RR is as follows:
-
-      Service.Proto.Realm TTL Class SRV Priority Weight Port Target
-
-   The Service name for Kerberos is always "_kerberos".
-
-   The Proto can be one of "_udp", "_tcp". If these SRV records are to
-   be used, both "_udp" and "_tcp" records MUST be specified for all KDC
-   deployments.
-
-   The Realm is the Kerberos realm that this record corresponds to.
-
-   TTL, Class, SRV, Priority, Weight, and Target have the standard
-   meaning as defined in RFC 2052.
-
-   As per RFC 2052 the Port number used for "_udp" and "_tcp" SRV
-   records SHOULD be the value assigned to "kerberos" by the Internet
-   Assigned Number Authority: 88 (decimal) unless the KDC is configured
-   to listen on an alternate TCP port.
-
-   Implementation note: Many existing client implementations do not
-
-
-
-March 2003                                                    [Page 103]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   support KDC Discovery and are configured to send requests to the IANA
-   assigned port (88 decimal), so it is strongly recommended that KDCs
-   be configured to listen on that port.
-
-7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks
-
-   These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
-   Kerberos servers, kdc1.example.com and kdc2.example.com. Queries
-   should be directed to kdc1.example.com first as per the specified
-   priority. Weights are not used in these sample records.
-
-     _kerberos._udp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
-     _kerberos._udp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
-     _kerberos._tcp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
-     _kerberos._tcp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
-
-7.3. Name of the TGS
-
-   The principal identifier of the ticket-granting service shall be
-   composed of three parts: (1) the realm of the KDC issuing the TGS
-   ticket (2) a two-part name of type NT-SRV-INST, with the first part
-   "krbtgt" and the second part the name of the realm which will accept
-   the ticket-granting ticket. For example, a ticket-granting ticket
-   issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
-   ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
-   (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting
-   ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets
-   from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU"
-   (realm), ("krbtgt", "MIT.EDU") (name).
-
-7.4. OID arc for KerberosV5
-
-   This OID MAY be used to identify Kerberos protocol messages
-   encapsulated in other protocols. It also designates the OID arc for
-   KerberosV5-related OIDs assigned by future IETF action.
-   Implementation note:: RFC 1510 had an incorrect value (5) for "dod"
-   in its OID.
-
-   id-krb5         OBJECT IDENTIFIER ::= {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2)
-   }
-
-   Assignment of OIDs beneath the id-krb5 arc must be obtained by
-   contacting krb5-oid-registrar@mit.edu.
-
-7.5. Protocol constants and associated values
-
-
-
-
-March 2003                                                    [Page 104]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   The following tables list constants used in the protocol and define
-   their meanings. Ranges are specified in the "specification" section
-   that limit the values of constants for which values are defined here.
-   This allows implementations to make assumptions about the maximum
-   values that will be received for these constants. Implementation
-   receiving values outside the range specified in the "specification"
-   section MAY reject the request, but they MUST recover cleanly.
-
-7.5.1. Key usage numbers
-
-   The encryption and checksum specifications in [@KCRYPTO] require as
-   input a "key usage number", to alter the encryption key used in any
-   specific message, to make certain types of cryptographic attack more
-   difficult. These are the key usage values assigned in this document:
-
-           1.          AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted
-                       with the client key (section 5.2.7.2)
-           2.          AS-REP Ticket and TGS-REP Ticket (includes TGS session
-                       key or application session key), encrypted with the
-                       service key (section 5.3)
-           3.          AS-REP encrypted part (includes TGS session key or
-                       application session key), encrypted with the client key
-                       (section 5.4.2)
-           4.          TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with
-                       the TGS session key (section 5.4.1)
-           5.          TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with
-                       the TGS authenticator subkey (section 5.4.1)
-           6.          TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
-                       keyed with the TGS session key (sections 5.5.1)
-           7.          TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator
-                       (includes TGS authenticator subkey), encrypted with the
-                       TGS session key (section 5.5.1)
-           8.          TGS-REP encrypted part (includes application session
-                       key), encrypted with the TGS session key (section
-                       5.4.2)
-           9.          TGS-REP encrypted part (includes application session
-                       key), encrypted with the TGS authenticator subkey
-                       (section 5.4.2)
-           10.         AP-REQ Authenticator cksum, keyed with the application
-                       session key (section 5.5.1)
-           11.         AP-REQ Authenticator (includes application
-                       authenticator subkey), encrypted with the application
-                       session key (section 5.5.1)
-           12.         AP-REP encrypted part (includes application session
-                       subkey), encrypted with the application session key
-                       (section 5.5.2)
-           13.         KRB-PRIV encrypted part, encrypted with a key chosen by
-                       the application (section 5.7.1)
-
-
-
-March 2003                                                    [Page 105]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-           14.         KRB-CRED encrypted part, encrypted with a key chosen by
-                       the application (section 5.8.1)
-           15.         KRB-SAFE cksum, keyed with a key chosen by the
-                       application (section 5.6.1)
-           19.         AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4)
-         22-24.        Reserved for use in GSSAPI mechanisms derived from RFC
-                       1964. (raeburn/MIT)
-    16-18,20-21,25-511. Reserved for future use in Kerberos and related
-                       protocols.
-        512-1023.      Reserved for uses internal to a Kerberos
-                       implementation.
-         1024.         Encryption for application use in protocols that
-                       do not specify key usage values
-         1025.         Checksums for application use in protocols that
-                       do not specify key usage values
-       1026-2047.      Reserved for application use.
-
-
-7.5.2. PreAuthentication Data Types
-
-   padata and data types           padata-type value  comment
-
-   PA-TGS-REQ                      1
-   PA-ENC-TIMESTAMP                2
-   PA-PW-SALT                      3
-   [reserved]                      4
-   PA-ENC-UNIX-TIME                5        (deprecated)
-   PA-SANDIA-SECUREID              6
-   PA-SESAME                       7
-   PA-OSF-DCE                      8
-   PA-CYBERSAFE-SECUREID           9
-   PA-AFS3-SALT                    10
-   PA-ETYPE-INFO                   11
-   PA-SAM-CHALLENGE                12       (sam/otp)
-   PA-SAM-RESPONSE                 13       (sam/otp)
-   PA-PK-AS-REQ                    14       (pkinit)
-   PA-PK-AS-REP                    15       (pkinit)
-   PA-ETYPE-INFO2                  19       (replaces pa-etype-info)
-   PA-USE-SPECIFIED-KVNO           20
-   PA-SAM-REDIRECT                 21       (sam/otp)
-   PA-GET-FROM-TYPED-DATA          22       (embedded in typed data)
-   TD-PADATA                       22       (embeds padata)
-   PA-SAM-ETYPE-INFO               23       (sam/otp)
-   PA-ALT-PRINC                    24       (crawdad@fnal.gov)
-   PA-SAM-CHALLENGE2               30       (kenh@pobox.com)
-   PA-SAM-RESPONSE2                31       (kenh@pobox.com)
-   PA-EXTRA-TGT                    41       Reserved extra TGT
-   TD-PKINIT-CMS-CERTIFICATES      101      CertificateSet from CMS
-
-
-
-March 2003                                                    [Page 106]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   TD-KRB-PRINCIPAL                102      PrincipalName
-   TD-KRB-REALM                    103      Realm
-   TD-TRUSTED-CERTIFIERS           104      from PKINIT
-   TD-CERTIFICATE-INDEX            105      from PKINIT
-   TD-APP-DEFINED-ERROR            106      application specific
-   TD-REQ-NONCE                    107      INTEGER
-   TD-REQ-SEQ                      108      INTEGER
-   PA-PAC-REQUEST                  128      (jbrezak@exchange.microsoft.com)
-
-7.5.3. Address Types
-
-   Address type                   value
-
-   IPv4                             2
-   Directional                      3
-   ChaosNet                         5
-   XNS                              6
-   ISO                              7
-   DECNET Phase IV                 12
-   AppleTalk DDP                   16
-   NetBios                         20
-   IPv6                            24
-
-7.5.4. Authorization Data Types
-
-   authorization data type         ad-type value
-   AD-IF-RELEVANT                     1
-   AD-INTENDED-FOR-SERVER             2
-   AD-INTENDED-FOR-APPLICATION-CLASS  3
-   AD-KDC-ISSUED                      4
-   AD-AND-OR                          5
-   AD-MANDATORY-TICKET-EXTENSIONS     6
-   AD-IN-TICKET-EXTENSIONS            7
-   AD-MANDATORY-FOR-KDC               8
-   reserved values                    9-63
-   OSF-DCE                            64
-   SESAME                             65
-   AD-OSF-DCE-PKI-CERTID              66         (hemsath@us.ibm.com)
-   AD-WIN2K-PAC                      128         (jbrezak@exchange.microsoft.com)
-
-7.5.5. Transited Encoding Types
-
-   transited encoding type         tr-type value
-   DOMAIN-X500-COMPRESS            1
-   reserved values                 all others
-
-7.5.6. Protocol Version Number
-
-
-
-
-March 2003                                                    [Page 107]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   Label               Value   Meaning or MIT code
-
-   pvno                    5   current Kerberos protocol version number
-
-7.5.7. Kerberos Message Types
-
-   message types
-
-   KRB_AS_REQ             10   Request for initial authentication
-   KRB_AS_REP             11   Response to KRB_AS_REQ request
-   KRB_TGS_REQ            12   Request for authentication based on TGT
-   KRB_TGS_REP            13   Response to KRB_TGS_REQ request
-   KRB_AP_REQ             14   application request to server
-   KRB_AP_REP             15   Response to KRB_AP_REQ_MUTUAL
-   KRB_RESERVED16         16   Reserved for user-to-user krb_tgt_request
-   KRB_RESERVED17         17   Reserved for user-to-user krb_tgt_reply
-   KRB_SAFE               20   Safe (checksummed) application message
-   KRB_PRIV               21   Private (encrypted) application message
-   KRB_CRED               22   Private (encrypted) message to forward credentials
-   KRB_ERROR              30   Error response
-
-7.5.8. Name Types
-
-   name types
-
-   KRB_NT_UNKNOWN        0  Name type not known
-   KRB_NT_PRINCIPAL      1  Just the name of the principal as in DCE, or for users
-   KRB_NT_SRV_INST       2  Service and other unique instance (krbtgt)
-   KRB_NT_SRV_HST        3  Service with host name as instance (telnet, rcommands)
-   KRB_NT_SRV_XHST       4  Service with host as remaining components
-   KRB_NT_UID            5  Unique ID
-   KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
-   KRB_NT_SMTP_NAME      7  Name in form of SMTP email name (e.g. user@foo.com)
-   KRB_NT_ENTERPRISE    10   Enterprise name - may be mapped to principal name
-
-7.5.9. Error Codes
-
-   error codes
-
-   KDC_ERR_NONE                    0   No error
-   KDC_ERR_NAME_EXP                1   Client's entry in database has expired
-   KDC_ERR_SERVICE_EXP             2   Server's entry in database has expired
-   KDC_ERR_BAD_PVNO                3   Requested protocol version number
-                                          not supported
-   KDC_ERR_C_OLD_MAST_KVNO         4   Client's key encrypted in old master key
-   KDC_ERR_S_OLD_MAST_KVNO         5   Server's key encrypted in old master key
-   KDC_ERR_C_PRINCIPAL_UNKNOWN     6   Client not found in Kerberos database
-   KDC_ERR_S_PRINCIPAL_UNKNOWN     7   Server not found in Kerberos database
-
-
-
-March 2003                                                    [Page 108]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   KDC_ERR_PRINCIPAL_NOT_UNIQUE    8   Multiple principal entries in database
-   KDC_ERR_NULL_KEY                9   The client or server has a null key
-   KDC_ERR_CANNOT_POSTDATE        10   Ticket not eligible for postdating
-   KDC_ERR_NEVER_VALID            11   Requested start time is later than end time
-   KDC_ERR_POLICY                 12   KDC policy rejects request
-   KDC_ERR_BADOPTION              13   KDC cannot accommodate requested option
-   KDC_ERR_ETYPE_NOSUPP           14   KDC has no support for encryption type
-   KDC_ERR_SUMTYPE_NOSUPP         15   KDC has no support for checksum type
-   KDC_ERR_PADATA_TYPE_NOSUPP     16   KDC has no support for padata type
-   KDC_ERR_TRTYPE_NOSUPP          17   KDC has no support for transited type
-   KDC_ERR_CLIENT_REVOKED         18   Clients credentials have been revoked
-   KDC_ERR_SERVICE_REVOKED        19   Credentials for server have been revoked
-   KDC_ERR_TGT_REVOKED            20   TGT has been revoked
-   KDC_ERR_CLIENT_NOTYET          21   Client not yet valid - try again later
-   KDC_ERR_SERVICE_NOTYET         22   Server not yet valid - try again later
-   KDC_ERR_KEY_EXPIRED            23   Password has expired
-                                             - change password to reset
-   KDC_ERR_PREAUTH_FAILED         24   Pre-authentication information was invalid
-   KDC_ERR_PREAUTH_REQUIRED       25   Additional pre-authenticationrequired
-   KDC_ERR_SERVER_NOMATCH         26   Requested server and ticket don't match
-   KDC_ERR_MUST_USE_USER2USER     27   Server principal valid for user2user only
-   KDC_ERR_PATH_NOT_ACCPETED      28   KDC Policy rejects transited path
-   KDC_ERR_SVC_UNAVAILABLE        29   A service is not available
-   KRB_AP_ERR_BAD_INTEGRITY       31   Integrity check on decrypted field failed
-   KRB_AP_ERR_TKT_EXPIRED         32   Ticket expired
-   KRB_AP_ERR_TKT_NYV             33   Ticket not yet valid
-   KRB_AP_ERR_REPEAT              34   Request is a replay
-   KRB_AP_ERR_NOT_US              35   The ticket isn't for us
-   KRB_AP_ERR_BADMATCH            36   Ticket and authenticator don't match
-   KRB_AP_ERR_SKEW                37   Clock skew too great
-   KRB_AP_ERR_BADADDR             38   Incorrect net address
-   KRB_AP_ERR_BADVERSION          39   Protocol version mismatch
-   KRB_AP_ERR_MSG_TYPE            40   Invalid msg type
-   KRB_AP_ERR_MODIFIED            41   Message stream modified
-   KRB_AP_ERR_BADORDER            42   Message out of order
-   KRB_AP_ERR_BADKEYVER           44   Specified version of key is not available
-   KRB_AP_ERR_NOKEY               45   Service key not available
-   KRB_AP_ERR_MUT_FAIL            46   Mutual authentication failed
-   KRB_AP_ERR_BADDIRECTION        47   Incorrect message direction
-   KRB_AP_ERR_METHOD              48   Alternative authentication method required
-   KRB_AP_ERR_BADSEQ              49   Incorrect sequence number in message
-   KRB_AP_ERR_INAPP_CKSUM         50   Inappropriate type of checksum in message
-   KRB_AP_PATH_NOT_ACCEPTED       51   Policy rejects transited path
-   KRB_ERR_RESPONSE_TOO_BIG       52   Response too big for UDP, retry with TCP
-   KRB_ERR_GENERIC                60   Generic error (description in e-text)
-   KRB_ERR_FIELD_TOOLONG          61   Field is too long for this implementation
-   KDC_ERROR_CLIENT_NOT_TRUSTED      62 Reserved for PKINIT
-   KDC_ERROR_KDC_NOT_TRUSTED         63 Reserved for PKINIT
-
-
-
-March 2003                                                    [Page 109]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   KDC_ERROR_INVALID_SIG             64 Reserved for PKINIT
-   KDC_ERR_KEY_TOO_WEAK              65 Reserved for PKINIT
-   KDC_ERR_CERTIFICATE_MISMATCH      66 Reserved for PKINIT
-   KRB_AP_ERR_NO_TGT                 67 No TGT available to validate USER-TO-USER
-   KDC_ERR_WRONG_REALM               68 USER-TO-USER TGT issued different KDC
-   KRB_AP_ERR_USER_TO_USER_REQUIRED  69 Ticket must be for USER-TO-USER
-   KDC_ERR_CANT_VERIFY_CERTIFICATE   70 Reserved for PKINIT
-   KDC_ERR_INVALID_CERTIFICATE             71 Reserved for PKINIT
-   KDC_ERR_REVOKED_CERTIFICATE             72 Reserved for PKINIT
-   KDC_ERR_REVOCATION_STATUS_UNKNOWN       73 Reserved for PKINIT
-   KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74 Reserved for PKINIT
-   KDC_ERR_CLIENT_NAME_MISMATCH            75 Reserved for PKINIT
-   KDC_ERR_KDC_NAME_MISMATCH               76 Reserved for PKINIT
-
-8. Interoperability requirements
-
-   Version 5 of the Kerberos protocol supports a myriad of options.
-   Among these are multiple encryption and checksum types, alternative
-   encoding schemes for the transited field, optional mechanisms for
-   pre-authentication, the handling of tickets with no addresses,
-   options for mutual authentication, user to user authentication,
-   support for proxies, forwarding, postdating, and renewing tickets,
-   the format of realm names, and the handling of authorization data.
-
-   In order to ensure the interoperability of realms, it is necessary to
-   define a minimal configuration which must be supported by all
-   implementations. This minimal configuration is subject to change as
-   technology does. For example, if at some later date it is discovered
-   that one of the required encryption or checksum algorithms is not
-   secure, it will be replaced.
-
-8.1. Specification 2
-
-   This section defines the second specification of these options.
-   Implementations which are configured in this way can be said to
-   support Kerberos Version 5 Specification 2 (5.2). Specification 1
-   (deprecated) may be found in RFC1510.
-
-   Transport
-
-      TCP/IP and UDP/IP transport MUST be supported by clients and KDCs
-      claiming conformance to specification 2.
-
-   Encryption and checksum methods
-
-      The following encryption and checksum mechanisms MUST be
-      supported.
-
-
-
-
-March 2003                                                    [Page 110]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      Encryption: AES256-CTS-HMAC-SHA1-96
-      Checksums: HMAC-SHA1-96-AES256
-
-      Implementations SHOULD support other mechanisms as well, but the
-      additional mechanisms may only be used when communicating with
-      principals known to also support them. The mechanisms that SHOULD
-      be supported are:
-
-      Encryption:  DES-CBC-MD5, DES3-CBC-SHA1-KD
-      Checksums:   DES-MD5, HMAC-SHA1-DES3-KD
-
-      Implementations MAY support other mechanisms as well, but the
-      additional mechanisms may only be used when communicating with
-      principals known to also support them.
-
-      Implementation note: earlier implementations of Kerberos generate
-      messages using the CRC-32, RSA-MD5 checksum methods. For
-      interoperability with these earlier releases implementors MAY
-      consider supporting these checksum methods but should carefully
-      analyze the security impplications to limit the situations within
-      which these methods are accepted.
-
-   Realm Names
-
-      All implementations MUST understand hierarchical realms in both
-      the Internet Domain and the X.500 style. When a ticket-granting
-      ticket for an unknown realm is requested, the KDC MUST be able to
-      determine the names of the intermediate realms between the KDCs
-      realm and the requested realm.
-
-   Transited field encoding
-
-      DOMAIN-X500-COMPRESS (described in section 3.3.3.2) MUST be
-      supported.  Alternative encodings MAY be supported, but they may
-      be used only when that encoding is supported by ALL intermediate
-      realms.
-
-   Pre-authentication methods
-
-      The TGS-REQ method MUST be supported. The TGS-REQ method is not
-      used on the initial request. The PA-ENC-TIMESTAMP method MUST be
-      supported by clients but whether it is enabled by default MAY be
-      determined on a realm by realm basis. If not used in the initial
-      request and the error KDC_ERR_PREAUTH_REQUIRED is returned
-      specifying PA-ENC-TIMESTAMP as an acceptable method, the client
-      SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre-
-      authentication method. Servers need not support the PA-ENC-
-      TIMESTAMP method, but if not supported the server SHOULD ignore
-
-
-
-March 2003                                                    [Page 111]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      the presence of PA-ENC-TIMESTAMP pre-authentication in a request.
-
-      The ETYPE-INFO2 method MUST be supported; this method is used to
-      communicate the set of supported encryption types, and
-      corresponding salt and string to key paramters. The ETYPE-INFO
-      method SHOULD be supported for interoperability with older
-      implementation.
-
-   Mutual authentication
-
-      Mutual authentication (via the KRB_AP_REP message) MUST be
-      supported.
-
-   Ticket addresses and flags
-
-      All KDCs MUST pass through tickets that carry no addresses (i.e.
-      if a TGT contains no addresses, the KDC will return derivative
-      tickets).  Implementations SHOULD default to requesting
-      addressless tickets as this significantly increases
-      interoperability with network address translation.  In some cases
-      realms or application servers MAY require that tickets have an
-      address.
-
-      Implementations SHOULD accept directional address type for the
-      KRB_SAFE and KRB_PRIV message and SHOULD include directional
-      addresses in these messages when other address types are not
-      available.
-
-      Proxies and forwarded tickets MUST be supported. Individual realms
-      and application servers can set their own policy on when such
-      tickets will be accepted.
-
-      All implementations MUST recognize renewable and postdated
-      tickets, but need not actually implement them. If these options
-      are not supported, the starttime and endtime in the ticket shall
-      specify a ticket's entire useful life. When a postdated ticket is
-      decoded by a server, all implementations shall make the presence
-      of the postdated flag visible to the calling server.
-
-   User-to-user authentication
-
-      Support for user to user authentication (via the ENC-TKT-IN-SKEY
-      KDC option) MUST be provided by implementations, but individual
-      realms MAY decide as a matter of policy to reject such requests on
-      a per-principal or realm-wide basis.
-
-   Authorization data
-
-
-
-
-March 2003                                                    [Page 112]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      Implementations MUST pass all authorization data subfields from
-      ticket-granting tickets to any derivative tickets unless directed
-      to suppress a subfield as part of the definition of that
-      registered subfield type (it is never incorrect to pass on a
-      subfield, and no registered subfield types presently specify
-      suppression at the KDC).
-
-      Implementations MUST make the contents of any authorization data
-      subfields available to the server when a ticket is used.
-      Implementations are not required to allow clients to specify the
-      contents of the authorization data fields.
-
-   Constant ranges
-
-      All protocol constants are constrained to 32 bit (signed) values
-      unless further constrained by the protocol definition. This limit
-      is provided to allow implementations to make assumptions about the
-      maximum values that will be received for these constants.
-      Implementation receiving values outside this range MAY reject the
-      request, but they MUST recover cleanly.
-
-8.2. Recommended KDC values
-
-   Following is a list of recommended values for a KDC configuration.
-
-   minimum lifetime              5 minutes
-   maximum renewable lifetime    1 week
-   maximum ticket lifetime       1 day
-   acceptable clock skew         5 minutes
-   empty addresses               Allowed.
-   proxiable, etc.               Allowed.
-
-9. IANA considerations
-
-   Section 7 of this document specifies protocol constants and other
-   defined values required for the interoperability of multiple
-   implementations. Until otherwise specified in a subsequent RFC,
-   allocations of additional protocol constants and other defined values
-   required for extensions to the Kerberos protocol will be administered
-   by the Kerberos Working Group.
-
-10. Security Considerations
-
-   As an authentication service, Kerberos provides a means of verifying
-   the identity of principals on a network. Kerberos does not, by
-   itself, provide authorization. Applications should not accept the
-   issuance of a service ticket by the Kerberos server as granting
-   authority to use the service, since such applications may become
-
-
-
-March 2003                                                    [Page 113]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   vulnerable to the bypass of this authorization check in an
-   environment if they inter-operate with other KDCs or where other
-   options for application authentication are provided.
-
-   Denial of service attacks are not solved with Kerberos. There are
-   places in the protocols where an intruder can prevent an application
-   from participating in the proper authentication steps. Because
-   authentication is a required step for the use of many services,
-   successful denial of service attacks on a Kerberos server might
-   result in the denial of other network services that rely on Kerberos
-   for authentication. Kerberos is vulnerable to many kinds of denial of
-   service attacks: denial of service attacks on the network which would
-   prevent clients from contacting the KDC; denial of service attacks on
-   the domain name system which could prevent a client from finding the
-   IP address of the Kerberos server; and denial of service attack by
-   overloading the Kerberos KDC itself with repeated requests.
-
-   Interoperability conflicts caused by incompatible character-set usage
-   (see 5.2.1) can result in denial of service for clients that utilize
-   character-sets in Kerberos strings other than those stored in the KDC
-   database.
-
-   Authentication servers maintain a database of principals (i.e., users
-   and servers) and their secret keys. The security of the
-   authentication server machines is critical. The breach of security of
-   an authentication server will compromise the security of all servers
-   that rely upon the compromised KDC, and will compromise the
-   authentication of any principals registered in the realm of the
-   compromised KDC.
-
-   Principals must keep their secret keys secret. If an intruder somehow
-   steals a principal's key, it will be able to masquerade as that
-   principal or impersonate any server to the legitimate principal.
-
-   Password guessing attacks are not solved by Kerberos. If a user
-   chooses a poor password, it is possible for an attacker to
-   successfully mount an off-line dictionary attack by repeatedly
-   attempting to decrypt, with successive entries from a dictionary,
-   messages obtained which are encrypted under a key derived from the
-   user's password.
-
-   Unless pre-authentication options are required by the policy of a
-   realm, the KDC will not know whether a request for authentication
-   succeeds. An attacker can request a reply with credentials for any
-   principal. These credentials will likely not be of much use to the
-   attacker unless it knows the client's secret key, but the
-   availability of the response encrypted in the client's secret key
-   provides the attacker with ciphertext that may be used to mount brute
-
-
-
-March 2003                                                    [Page 114]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   force or dictionary attacks to decrypt the credentials, by guessing
-   the user's password. For this reason it is strongly encouraged that
-   Kerberos realms require the use of pre-authentication. Even with pre-
-   authentication, attackers may try brute force or dictionary attacks
-   against credentials that are observed by eavesdropping on the
-   network.
-
-   Because a client can request a ticket for any server principal and
-   can attempt a brute force or dictionary attack against the server
-   principal's key using that ticket, it is strongly encouraged that
-   keys be randomly generated (rather than generated from passwords) for
-   any principals that are usable as the target principal for a
-   KRB_TGS_REQ or KRB_AS_REQ messages.
-
-   Each host on the network must have a clock which is loosely
-   synchronized to the time of the other hosts; this synchronization is
-   used to reduce the bookkeeping needs of application servers when they
-   do replay detection. The degree of "looseness" can be configured on a
-   per-server basis, but is typically on the order of 5 minutes. If the
-   clocks are synchronized over the network, the clock synchronization
-   protocol must itself be secured from network attackers.
-
-   Principal identifiers must not recycled on a short-term basis. A
-   typical mode of access control will use access control lists (ACLs)
-   to grant permissions to particular principals. If a stale ACL entry
-   remains for a deleted principal and the principal identifier is
-   reused, the new principal will inherit rights specified in the stale
-   ACL entry. By not reusing principal identifiers, the danger of
-   inadvertent access is removed.
-
-   Proper decryption of an KRB_AS_REP message from the KDC is not
-   sufficient for the host to verify the identity of the user; the user
-   and an attacker could cooperate to generate a KRB_AS_REP format
-   message which decrypts properly but is not from the proper KDC. To
-   authenticate a user logging on to a local system, the credentials
-   obtained in the AS exchange may first be used in a TGS exchange to
-   obtain credentials for a local server. Those credentials must then be
-   verified by a local server through successful completion of the
-   Client/Server exchange.
-
-   Kerberos credentials contain clear-text information identifying the
-   principals to which they apply. If privacy of this information is
-   needed, this exchange should itself be encapsulated in a protocol
-   providing for confidentiality on the exchange of these credentials.
-
-   Applications must take care to protect communications subsequent to
-   authentication either by using the KRB_PRIV or KRB_SAFE messages as
-   appropriate, or by applying their own confidentiality or integrity
-
-
-
-March 2003                                                    [Page 115]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   mechanisms on such communications. Completion of the KRB_AP_REQ and
-   KRB_AP_REP exchange without subsequent use of confidentiality and
-   integrity mechanisms provides only for authentication of the parties
-   to the communication and not confidentiality and integrity of the
-   subsequent communication. Application applying confidentiality and
-   protections mechanisms other than KRB_PRIV and KRB_SAFE must make
-   sure that the authentication step is appropriately linked with the
-   protected communication channel that is established by the
-   application.
-
-   Unless the application server provides its own suitable means to
-   protect against replay (for example, a challenge-response sequence
-   initiated by the server after authentication, or use of a server-
-   generated encryption subkey), the server must utilize a replay cache
-   to remember any authenticator presented within the allowable clock
-   skew. All services sharing a key need to use the same replay cache.
-   If separate replay caches are used, then and authenticator used with
-   one such service could later be replayed to a different service with
-   the same service principal.
-
-   If a server loses track of authenticators presented within the
-   allowable clock skew, it must reject all requests until the clock
-   skew interval has passed, providing assurance that any lost or
-   replayed authenticators will fall outside the allowable clock skew
-   and can no longer be successfully replayed.
-
-   Implementations of Kerberos should not use untrusted directory
-   servers to determine the realm of a host. To allow such would allow
-   the compromise of the directory server to enable an attacker to
-   direct the client to accept authentication with the wrong principal
-   (i.e. one with a similar name, but in a realm with which the
-   legitimate host was not registered).
-
-   Implementations of Kerberos must not use DNS to canonicalize the host
-   components of service principal names. To allow such canonicalization
-   would allow a compromise of the DNS to result in a client obtaining
-   credentials and correctly authenticating to the wrong principal.
-   Though the client will know who it is communicating with, it will not
-   be the principal with which it intended to communicate.
-
-   If the Kerberos server returns a TGT for a 'closer' realm other than
-   the desired realm, the client may use local policy configuration to
-   verify that the authentication path used is an acceptable one.
-   Alternatively, a client may choose its own authentication path,
-   rather than relying on the Kerberos server to select one. In either
-   case, any policy or configuration information used to choose or
-   validate authentication paths, whether by the Kerberos server or
-   client, must be obtained from a trusted source.
-
-
-
-March 2003                                                    [Page 116]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   The Kerberos protocol in its basic form does not provide perfect
-   forward secrecy for communications. If traffic has been recorded by
-   an eavesdropper, then messages encrypted using the KRB_PRIV message,
-   or messages encrypted using application specific encryption under
-   keys exchanged using Kerberos can be decrypted if any of the user's,
-   application server's, or KDC's key is subsequently discovered. This
-   is because the session key use to encrypt such messages is
-   transmitted over the network encrypted in the key of the application
-   server, and also encrypted under the session key from the user's
-   ticket-granting ticket when returned to the user in the KRB_TGS_REP
-   message. The session key from the ticket-granting ticket was sent to
-   the user in the KRB_AS_REP message encrypted in the user's secret
-   key, and embedded in the ticket-granting ticket, which was encrypted
-   in the key of the KDC. Application requiring perfect forward secrecy
-   must exchange keys through mechanisms that provide such assurance,
-   but may use Kerberos for authentication of the encrypted channel
-   established through such other means.
-
-11. Author's Addresses
-
-
-       Clifford Neuman
-       Information Sciences Institute
-       University of Southern California
-       4676 Admiralty Way
-       Marina del Rey, CA 90292, USA
-       Email: bcn@isi.edu
-
-       Tom Yu
-       Massachusetts Institute of Technology
-       77 Massachusetts Avenue
-       Cambridge, MA 02139, USA
-       Email: tlyu@mit.edu
-
-       Sam Hartman
-       Massachusetts Institute of Technology
-       77 Massachusetts Avenue
-       Cambridge, MA 02139, USA
-       Email: hartmans@mit.edu
-
-       Kenneth Raeburn
-       Massachusetts Institute of Technology
-       77 Massachusetts Avenue
-       Cambridge, MA 02139, USA
-       Email: raeburn@MIT.EDU
-
-
-12. Acknowledgements
-
-
-
-March 2003                                                    [Page 117]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   This document is a revision to RFC1510 which was co-authored with
-   John Kohl.  The specification of the Kerberos protocol described in
-   this document is the result of many years of effort.  Over this
-   period many individuals have contributed to the definition of the
-   protocol and to the writing of the specification. Unfortunately it is
-   not possible to list all contributors as authors of this document,
-   though there are many not listed who are authors in spirit, because
-   they contributed text for parts of some sections, because they
-   contributed to the design of parts of the protocol, or because they
-   contributed significantly to the discussion of the protocol in the
-   IETF common authentication technology (CAT) and Kerberos working
-   groups.
-
-   Among those contributing to the development and specification of
-   Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan
-   Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl,
-   Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn,
-   Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome
-   Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift,
-   Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar
-   Westerlund, and Nicolas Williams. Many other members of MIT Project
-   Athena, the MIT networking group, and the Kerberos and CAT working
-   groups of the IETF contributed but are not listed.
-
-13. REFERENCES
-
-   [@KRYPTO]
-      RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
-      crypto.
-
-   [@AES]
-      RFC-Editor: To be replaced by RFC number for draft-raeburn0krb-
-      rijndael-krb.
-
-   [DGT96]
-      Don Davis, Daniel Geer, and Theodore Ts'0, "Kerberos With Clocks
-      Adrift: History, Protocols, and Implementation", USENIX Computing
-      Systems 9:1 (Januart 1996).
-
-   [DS81]
-      Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
-      Distribution Protocols," Communications of the ACM, Vol. 24(8),
-      pp.  533-536 (August 1981).
-
-   [ISO-646/ECMA-6]
-      7-bit Coded Character Set
-
-   [ISO-2022/ECMA-35]
-
-
-
-March 2003                                                    [Page 118]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      Character Code Structure and Extension Techniques
-
-   [ISO-4873/ECMA-43]
-      8-bit Coded Character Set Structure and Rules
-
-   [KNT94]
-
-      John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
-      Evolution of the Kerberos Authentication System". In Distributed
-      Open Systems, pages 78-94. IEEE Computer Society Press, 1994.
-
-   [MNSS87]
-      S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer,
-      Section E.2.1: Kerberos Authentication and Authorization System,
-      M.I.T. Project Athena, Cambridge, Massachusetts (December 21,
-      1987).
-
-   [Neu93]
-      B. Clifford Neuman, "Proxy-Based Authorization and Accounting for
-      Distributed Systems," in Proceedings of the 13th International
-      Conference on Distributed Computing Systems, Pittsburgh, PA (May,
-      1993).
-
-   [NS78]
-      Roger M. Needham and Michael D. Schroeder, "Using Encryption for
-      Authentication in Large Networks of Computers," Communications of
-      the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
-
-   [NT94]
-      B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication
-      Service for Computer Networks," IEEE Communications Magazine, Vol.
-      32(9), pp.  33-38 (September 1994).
-
-   [Pat92].
-      J. Pato, Using Pre-Authentication to Avoid Password Guessing
-      Attacks, Open Software Foundation DCE Request for Comments 26
-      (December 1992).
-
-   [RFC1035]
-      P.V. Mockapetris, RFC1035: "Domain Names - Implementations and
-      Specification," November 1, 1987, Obsoletes - RFC973, RFC882,
-      RFC883. Updated by RFC1101, RFC1183, RFC1348, RFCRFC1876, RFC1982,
-      RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308,
-      RFC2535, RFC2845, and RFC3425. Status: Standard.
-
-   [RFC1510]
-      J. Kohl and  B. C. Neuman, RFC1510: "The Kerberos Network
-      Authentication Service (v5)," September 1993, Status: Proposed
-
-
-
-March 2003                                                    [Page 119]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-      Standard.
-
-   [RFC2026]
-      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
-      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
-      Practice.
-
-   [RFC2052]
-      A. Gulbrandsen and P. Vixie, RFC2052: "A DNS RR for Specifying the
-      Location of Services (DNS SRV)," October 1996, Obseleted by
-      RFC2782, Status: Experimental
-
-   [RFC2253]
-      M. Wahl, S. Killie, and T. Howes, RFC2253: "Lightweight Directory
-      Access Protocol (v3): UTF-8 String Representation or Distinguished
-      Names," December 1997, Obsoletes - RFC1779, Updated by RFC3377,
-      Status: Proposed Standard.
-
-   [RFC2273]
-      D. Levi, P. Meyer, and B. Stewart, RFC2273: "SNMPv3 Applications,"
-      January 1998, Obsoletes - RFC2263, Obsoleted by RFC2573, Status:
-      Proposed Standard.
-
-   [RFC2373]
-      R. Hinden, S. Deering, RFC2373: "IP Version 6 Addressing
-      Architecture," July 1998, Status: Proposed Standard.
-
-   [SNS88]
-      J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An
-      Authentication Service for Open Network Systems," pp. 191-202 in
-      Usenix Conference Proceedings, Dallas, Texas (February, 1988).
-
-   [X680]
-      Abstract Syntax Notation One (ASN.1): Specification of Basic
-      Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
-      International Standard 8824-1:1998.
-
-   [X690]
-      ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
-      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
-      (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
-      Standard 8825-1:1998.
-
-A. ASN.1 module
-
-   KerberosV5Spec2 {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2) modules(4) krb5spec2(2)
-
-
-
-March 2003                                                    [Page 120]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-   -- OID arc for KerberosV5
-   --
-   -- This OID may be used to identify Kerberos protocol messages
-   -- encapsulated in other protocols.
-   --
-   -- This OID also designates the OID arc for KerberosV5-related OIDs.
-   --
-   -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID.
-   id-krb5         OBJECT IDENTIFIER ::= {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2)
-   }
-
-   Int32           ::= INTEGER (-2147483648..2147483647)
-                       -- signed values representable in 32 bits
-
-   UInt32          ::= INTEGER (0..4294967295)
-                       -- unsigned 32 bit values
-
-   Microseconds    ::= INTEGER (0..999999)
-                       -- microseconds
-
-   KerberosString  ::= GeneralString (IA5String)
-
-   Realm           ::= KerberosString
-
-   PrincipalName   ::= SEQUENCE {
-           name-type       [0] Int32,
-           name-string     [1] SEQUENCE OF KerberosString
-   }
-
-   KerberosTime    ::= GeneralizedTime -- with no fractional seconds
-
-   HostAddress     ::= SEQUENCE  {
-           addr-type       [0] Int32,
-           address         [1] OCTET STRING
-   }
-
-   -- NOTE: HostAddresses is always used as an OPTIONAL field and
-   -- should not be empty.
-   HostAddresses   -- NOTE: subtly different from rfc1510,
-                   -- but has a value mapping and encodes the same
-           ::= SEQUENCE OF HostAddress
-
-   -- NOTE: AuthorizationData is always used as an OPTIONAL field and
-   -- should not be empty.
-
-
-
-March 2003                                                    [Page 121]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-           ad-type         [0] Int32,
-           ad-data         [1] OCTET STRING
-   }
-
-   PA-DATA         ::= SEQUENCE {
-           -- NOTE: first tag is [1], not [0]
-           padata-type     [1] Int32,
-           padata-value    [2] OCTET STRING -- might be encoded AP-REQ
-   }
-
-   KerberosFlags   ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
-                       -- shall be sent, but no fewer than 32
-
-   EncryptedData   ::= SEQUENCE {
-           etype   [0] Int32 -- EncryptionType --,
-           kvno    [1] UInt32 OPTIONAL,
-           cipher  [2] OCTET STRING -- ciphertext
-   }
-
-   EncryptionKey   ::= SEQUENCE {
-           keytype         [0] Int32 -- actually encryption type --,
-           keyvalue        [1] OCTET STRING
-   }
-
-   Checksum        ::= SEQUENCE {
-           cksumtype       [0] Int32,
-           checksum        [1] OCTET STRING
-   }
-
-   Ticket          ::= [APPLICATION 1] SEQUENCE {
-           tkt-vno         [0] INTEGER (5),
-           realm           [1] Realm,
-           sname           [2] PrincipalName,
-           enc-part        [3] EncryptedData -- EncTicketPart
-   }
-
-   -- Encrypted part of ticket
-   EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
-           flags                   [0] TicketFlags,
-           key                     [1] EncryptionKey,
-           crealm                  [2] Realm,
-           cname                   [3] PrincipalName,
-           transited               [4] TransitedEncoding,
-           authtime                [5] KerberosTime,
-           starttime               [6] KerberosTime OPTIONAL,
-           endtime                 [7] KerberosTime,
-           renew-till              [8] KerberosTime OPTIONAL,
-
-
-
-March 2003                                                    [Page 122]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-           caddr                   [9] HostAddresses OPTIONAL,
-           authorization-data      [10] AuthorizationData OPTIONAL
-   }
-
-   -- encoded Transited field
-   TransitedEncoding       ::= SEQUENCE {
-           tr-type         [0] Int32 -- must be registered --,
-           contents        [1] OCTET STRING
-   }
-
-   TicketFlags     ::= KerberosFlags
-           -- reserved(0),
-           -- forwardable(1),
-           -- forwarded(2),
-           -- proxiable(3),
-           -- proxy(4),
-           -- may-postdate(5),
-           -- postdated(6),
-           -- invalid(7),
-           -- renewable(8),
-           -- initial(9),
-           -- pre-authent(10),
-           -- hw-authent(11),
-   -- the following are new since 1510
-           -- transited-policy-checked(12),
-           -- ok-as-delegate(13)
-
-   AS-REQ          ::= [APPLICATION 10] KDC-REQ
-
-   TGS-REQ         ::= [APPLICATION 12] KDC-REQ
-
-   KDC-REQ         ::= SEQUENCE {
-           -- NOTE: first tag is [1], not [0]
-           pvno            [1] INTEGER (5) ,
-           msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
-           padata          [3] SEQUENCE OF PA-DATA OPTIONAL
-                               -- NOTE: not empty --,
-           req-body        [4] KDC-REQ-BODY
-   }
-
-   KDC-REQ-BODY    ::= SEQUENCE {
-           kdc-options             [0] KDCOptions,
-           cname                   [1] PrincipalName OPTIONAL
-                                       -- Used only in AS-REQ --,
-           realm                   [2] Realm
-                                       -- Server's realm
-                                       -- Also client's in AS-REQ --,
-           sname                   [3] PrincipalName OPTIONAL,
-
-
-
-March 2003                                                    [Page 123]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-           from                    [4] KerberosTime OPTIONAL,
-           till                    [5] KerberosTime,
-           rtime                   [6] KerberosTime OPTIONAL,
-           nonce                   [7] UInt32,
-           etype                   [8] SEQUENCE OF Int32 -- EncryptionType
-                                       -- in preference order --,
-           addresses               [9] HostAddresses OPTIONAL,
-           enc-authorization-data  [10] EncryptedData -- AuthorizationData --,
-           additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
-                                           -- NOTE: not empty
-   }
-
-   KDCOptions      ::= KerberosFlags
-           -- reserved(0),
-           -- forwardable(1),
-           -- forwarded(2),
-           -- proxiable(3),
-           -- proxy(4),
-           -- allow-postdate(5),
-           -- postdated(6),
-           -- unused7(7),
-           -- renewable(8),
-           -- unused9(9),
-           -- unused10(10),
-           -- opt-hardware-auth(11),
-           -- unused12(12),
-           -- unused13(13),
-   -- 15 is reserved for canonicalize
-           -- unused15(15),
-   -- 26 was unused in 1510
-           -- disable-transited-check(26),
-   --
-           -- renewable-ok(27),
-           -- enc-tkt-in-skey(28),
-           -- renew(30),
-           -- validate(31)
-
-   AS-REP          ::= [APPLICATION 11] KDC-REP
-
-   TGS-REP         ::= [APPLICATION 13] KDC-REP
-
-   KDC-REP         ::= SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
-           padata          [2] SEQUENCE OF PA-DATA OPTIONAL
-                                   -- NOTE: not empty --,
-           crealm          [3] Realm,
-           cname           [4] PrincipalName,
-
-
-
-March 2003                                                    [Page 124]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-           ticket          [5] Ticket,
-           enc-part        [6] EncryptedData
-                                   -- EncASRepPart or EncTGSRepPart,
-                                   -- as appropriate
-   }
-
-   EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
-
-   EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
-
-   EncKDCRepPart   ::= SEQUENCE {
-           key             [0] EncryptionKey,
-           last-req        [1] LastReq,
-           nonce           [2] UInt32,
-           key-expiration  [3] KerberosTime OPTIONAL,
-           flags           [4] TicketFlags,
-           authtime        [5] KerberosTime,
-           starttime       [6] KerberosTime OPTIONAL,
-           endtime         [7] KerberosTime,
-           renew-till      [8] KerberosTime OPTIONAL,
-           srealm          [9] Realm,
-           sname           [10] PrincipalName,
-           caddr           [11] HostAddresses OPTIONAL
-   }
-
-   LastReq         ::=     SEQUENCE OF SEQUENCE {
-           lr-type         [0] Int32,
-           lr-value        [1] KerberosTime
-   }
-
-   AP-REQ          ::= [APPLICATION 14] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (14),
-           ap-options      [2] APOptions,
-           ticket          [3] Ticket,
-           authenticator   [4] EncryptedData -- Authenticator
-   }
-
-   APOptions       ::= KerberosFlags
-           -- reserved(0),
-           -- use-session-key(1),
-           -- mutual-required(2)
-
-   -- Unencrypted authenticator
-   Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-           authenticator-vno       [0] INTEGER (5),
-           crealm                  [1] Realm,
-           cname                   [2] PrincipalName,
-
-
-
-March 2003                                                    [Page 125]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-           cksum                   [3] Checksum OPTIONAL,
-           cusec                   [4] Microseconds,
-           ctime                   [5] KerberosTime,
-           subkey                  [6] EncryptionKey OPTIONAL,
-           seq-number              [7] UInt32 OPTIONAL,
-           authorization-data      [8] AuthorizationData OPTIONAL
-   }
-
-   AP-REP          ::= [APPLICATION 15] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (15),
-           enc-part        [2] EncryptedData -- EncAPRepPart
-   }
-
-   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
-           ctime           [0] KerberosTime,
-           cusec           [1] Microseconds,
-           subkey          [2] EncryptionKey OPTIONAL,
-           seq-number      [3] UInt32 OPTIONAL
-   }
-
-   KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (20),
-           safe-body       [2] KRB-SAFE-BODY,
-           cksum           [3] Checksum
-   }
-
-   KRB-SAFE-BODY   ::= SEQUENCE {
-           user-data       [0] OCTET STRING,
-           timestamp       [1] KerberosTime OPTIONAL,
-           usec            [2] Microseconds OPTIONAL,
-           seq-number      [3] UInt32 OPTIONAL,
-           s-address       [4] HostAddress,
-           r-address       [5] HostAddress OPTIONAL
-   }
-
-   KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (21),
-                           -- NOTE: there is no [2] tag
-           enc-part        [3] EncryptedData -- EncKrbPrivPart
-   }
-
-   EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-           user-data       [0] OCTET STRING,
-           timestamp       [1] KerberosTime OPTIONAL,
-           usec            [2] Microseconds OPTIONAL,
-
-
-
-March 2003                                                    [Page 126]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-           seq-number      [3] UInt32 OPTIONAL,
-           s-address       [4] HostAddress -- sender's addr --,
-           r-address       [5] HostAddress OPTIONAL -- recip's addr
-   }
-
-   KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (22),
-           tickets         [2] SEQUENCE OF Ticket,
-           enc-part        [3] EncryptedData -- EncKrbCredPart
-   }
-
-   EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-           ticket-info     [0] SEQUENCE OF KrbCredInfo,
-           nonce           [1] UInt32 OPTIONAL,
-           timestamp       [2] KerberosTime OPTIONAL,
-           usec            [3] Microseconds OPTIONAL,
-           s-address       [4] HostAddress OPTIONAL,
-           r-address       [5] HostAddress OPTIONAL
-   }
-
-   KrbCredInfo     ::= SEQUENCE {
-           key             [0] EncryptionKey,
-           prealm          [1] Realm OPTIONAL,
-           pname           [2] PrincipalName OPTIONAL,
-           flags           [3] TicketFlags OPTIONAL,
-           authtime        [4] KerberosTime OPTIONAL,
-           starttime       [5] KerberosTime OPTIONAL,
-           endtime         [6] KerberosTime OPTIONAL,
-           renew-till      [7] KerberosTime OPTIONAL,
-           srealm          [8] Realm OPTIONAL,
-           sname           [9] PrincipalName OPTIONAL,
-           caddr           [10] HostAddresses OPTIONAL
-   }
-
-   KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (30),
-           ctime           [2] KerberosTime OPTIONAL,
-           cusec           [3] Microseconds OPTIONAL,
-           stime           [4] KerberosTime,
-           susec           [5] Microseconds,
-           error-code      [6] Int32,
-           crealm          [7] Realm OPTIONAL,
-           cname           [8] PrincipalName OPTIONAL,
-           realm           [9] Realm -- service realm --,
-           sname           [10] PrincipalName -- service name --,
-           e-text          [11] KerberosString OPTIONAL,
-
-
-
-March 2003                                                    [Page 127]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-           e-data          [12] OCTET STRING OPTIONAL
-   }
-
-   METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-   TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-           data-type       [0] INTEGER,
-           data-value      [1] OCTET STRING OPTIONAL
-   }
-
-   -- preauth stuff follows
-
-   PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
-
-   PA-ENC-TS-ENC           ::= SEQUENCE {
-           patimestamp     [0] KerberosTime -- client's time --,
-           pausec          [1] Microseconds OPTIONAL
-   }
-
-   ETYPE-INFO-ENTRY        ::= SEQUENCE {
-           etype           [0] Int32,
-           salt            [1] OCTET STRING OPTIONAL
-   }
-
-   ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
-
-   ETYPE-INFO2-ENTRY       ::= SEQUENCE {
-           etype           [0] Int32,
-           salt            [1] KerberosString OPTIONAL,
-           s2kparams       [2] OCTET STRING OPTIONAL
-   }
-
-   ETYPE-INFO2             ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO-ENTRY
-
-   AD-IF-RELEVANT          ::= AuthorizationData
-
-   AD-KDCIssued            ::= SEQUENCE {
-           ad-checksum     [0] Checksum,
-           i-realm         [1] Realm OPTIONAL,
-           i-sname         [2] PrincipalName OPTIONAL,
-           elements        [3] AuthorizationData
-   }
-
-   AD-AND-OR               ::= SEQUENCE {
-           condition-count [0] INTEGER,
-           elements        [1] AuthorizationData
-   }
-
-
-
-
-March 2003                                                    [Page 128]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   AD-MANDATORY-FOR-KDC    ::= AuthorizationData
-
-   END
-
-B. Changes since RFC-1510
-
-   This document replaces RFC-1510 and clarifies specification of items
-   that were not completely specified. Where changes to recommended
-   implementation choices were made, or where new options were added,
-   those changes are described within the document and listed in this
-   section. More significantly, "Specification 2" in section 8 changes
-   the required encryption and checksum methods to bring them in line
-   with the best current practices and to deprecate methods that are no
-   longer considered sufficiently strong.
-
-   Discussion was added to section 1 regarding the ability to rely on
-   the KDC to check the transited field, and on the inclusion of a flag
-   in a ticket indicating that this check has occurred. This is a new
-   capability not present in RFC1510. Pre-existing implementations may
-   ignore or not set this flag without negative security implications.
-
-   The definition of the secret key says that in the case of a user the
-   key may be derived from a password. In 1510, it said that the key was
-   derived from the password. This change was made to accommodate
-   situations where the user key might be stored on a smart-card, or
-   otherwise obtained independent of a password.
-
-   The introduction mentions the use of public key cryptography for
-   initial authentication in Kerberos by reference. RFC1510 did not
-   include such a reference.
-
-   Section 1.2 was added to explain that while Kerberos provides
-   authentication of a named principal, it is still the responsibility
-   of the application to ensure that the authenticated name is the
-   entity with which the application wishes to communicate.
-
-   Discussion of extensibility has been added to the introduction.
-
-   Discussion of how extensibility affects ticket flags and KDC options
-   was added to the introduction of section 2. No changes were made to
-   existing options and flags specified in RFC1510, though some of the
-   sections in the specification were renumbered, and text was revised
-   to make the description and intent of existing options clearer,
-   especially with respect to the ENC-TKT-IN-SKEY option (now section
-   2.9.2) which is used for user-to-user authentication.  The new option
-   and ticket flag transited policy checking (section 2.7) was added.
-
-   A warning regarding generation of session keys for application use
-
-
-
-March 2003                                                    [Page 129]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   was added to section 3, urging the inclusion of key entropy from the
-   KDC generated session key in the ticket. An example regarding use of
-   the sub-session key was added to section 3.2.6. Descriptions of the
-   pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data
-   items were added. The recommendation for use of pre-authentication
-   was changed from "may" to "should" and a note was added regarding
-   known plaintext attacks.
-
-   In RFC 1510, section 4 described the database in the KDC. This
-   discussion was not necessary for interoperability and unnecessarily
-   constrained implementation. The old section 4 was removed.
-
-   The current section 4 was formerly section 6 on encryption and
-   checksum specifications. The major part of this section was brought
-   up to date to support new encryption methods, and move to a separate
-   document. Those few remaining aspects of the encryption and checksum
-   specification specific to Kerberos are now specified in section 4.
-
-   Significant changes were made to the layout of section 5 to clarify
-   the correct behavior for optional fields. Many of these changes were
-   made necessary because of improper ASN.1 description in the original
-   Kerberos specification which left the correct behavior
-   underspecified. Additionally, the wording in this section was
-   tightened wherever possible to ensure that implementations conforming
-   to this specification will be extensible with the addition of new
-   fields in future specifications.
-
-   Text was added describing time_t=0 issues in the ASN.1. Text was also
-   added, clarifying issues with implementations treating omitted
-   optional integers as zero. Text was added clarifying behavior for
-   optional SEQUENCE or SEQUENCE OF that may be empty. Discussion was
-   added regarding sequence numbers and behavior of some
-   implementations, including "zero" behavior and negative numbers. A
-   compatibility note was added regarding the unconditional sending of
-   EncTGSRepPart regardless of the enclosing reply type. Minor changes
-   were made to the description of the HostAddresses type. Integer types
-   were constrained. KerberosString was defined as a (significantly)
-   constrained GeneralString. KerberosFlags was defined to reflect
-   existing implementation behavior that departs from the definition in
-   RFC 1510. The transited-policy-checked(12) and the ok-as-delegate(13)
-   ticket flags were added. The disable-transited-check(26) KDC option
-   was added.
-
-   Descriptions of commonly implemented PA-DATA were added to section 5.
-   The description of KRB-SAFE has been updated to note the existing
-   implementation behavior of double-encoding.
-
-   There were two definitions of METHOD-DATA in RFC 1510. The second
-
-
-
-March 2003                                                    [Page 130]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   one, intended for use with KRB_AP_ERR_METHOD was removed leaving the
-   SEQUENCE OF PA-DATA definition.
-
-   Section 7, naming constraints, from RFC1510 was moved to section 6.
-
-   Words were added describing the convention that domain based realm
-   names for newly created realms should be specified as upper case.
-   This recommendation does not make lower case realm names illegal.
-   Words were added highlighting that the slash separated components in
-   the X500 style of realm names is consistent with existing RFC1510
-   based implementations, but that it conflicts with the general
-   recommendation of X.500 name representation specified in RFC2253.
-
-   Section 8, network transport, constants and defined values, from
-   RFC1510 was moved to section 7.  Since RFC1510, the definition of the
-   TCP transport for Kerberos messages was added, and the encryption and
-   checksum number assignments have been moved into a separate document.
-
-   "Specification 2" in section 8 of the current document changes the
-   required encryption and checksum methods to bring them in line with
-   the best current practices and to deprecate methods that are no
-   longer considered sufficiently strong.
-
-   Two new sections, on IANA considerations and security considerations
-   were added.
-
-   The pseudo-code has been removed from the appendix. The pseudo-code
-   was sometimes misinterpreted to limit implementation choices and in
-   RFC 1510, it was not always consistent with the words in the
-   specification. Effort was made to clear up any ambiguities in the
-   specification, rather than to rely on the pseudo-code.
-
-   An appendix was added containing the complete ASN.1 module drawn from
-   the discussion in section 5 of the current document.
-
-   An appendix was added defining those authorization data elements that
-   must be understood by all Kerberos implementations.
-
-END NOTES
-
-   [TM] Project Athena, Athena, and Kerberos are trademarks of the
-   Massachusetts Institute of Technology (MIT). No commercial use of
-   these trademarks may be made without prior written permission of MIT.
-
-   [1] Note, however, that many applications use Kerberos' functions
-   only upon the initiation of a stream-based network connection. Unless
-   an application subsequently provides integrity protection for the
-   data stream, the identity verification applies only to the initiation
-
-
-
-March 2003                                                    [Page 131]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   of the connection, and does not guarantee that subsequent messages on
-   the connection originate from the same principal.
-
-   [2] Secret and private are often used interchangeably in the
-   literature.  In our usage, it takes two (or more) to share a secret,
-   thus a shared DES key is a secret key. Something is only private when
-   no one but its owner knows it. Thus, in public key cryptosystems, one
-   has a public and a private key.
-
-   [3] Of course, with appropriate permission the client could arrange
-   registration of a separately-named principal in a remote realm, and
-   engage in normal exchanges with that realm's services. However, for
-   even small numbers of clients this becomes cumbersome, and more
-   automatic methods as described here are necessary.
-
-   [4] Though it is permissible to request or issue tickets with no
-   network addresses specified.
-
-   [5] The password-changing request must not be honored unless the
-   requester can provide the old password (the user's current secret
-   key). Otherwise, it would be possible for someone to walk up to an
-   unattended session and change another user's password.
-
-   [6] To authenticate a user logging on to a local system, the
-   credentials obtained in the AS exchange may first be used in a TGS
-   exchange to obtain credentials for a local server. Those credentials
-   must then be verified by a local server through successful completion
-   of the Client/Server exchange.
-
-   [7] "Random" means that, among other things, it should be impossible
-   to guess the next session key based on knowledge of past session
-   keys. This can only be achieved in a pseudo-random number generator
-   if it is based on cryptographic principles. It is more desirable to
-   use a truly random number generator, such as one based on
-   measurements of random physical phenomena.
-
-   [8] Tickets contain both an encrypted and unencrypted portion, so
-   cleartext here refers to the entire unit, which can be copied from
-   one message and replayed in another without any cryptographic skill.
-
-   [9] Note that this can make applications based on unreliable
-   transports difficult to code correctly. If the transport might
-   deliver duplicated messages, either a new authenticator must be
-   generated for each retry, or the application server must match
-   requests and replies and replay the first reply in response to a
-   detected duplicate.
-
-   [10] Note also that the rejection here is restricted to
-
-
-
-March 2003                                                    [Page 132]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-03.txt DRAFT
-
-
-   authenticators from the same principal to the same server. Other
-   client principals communicating with the same server principal should
-   not be have their authenticators rejected if the time and microsecond
-   fields happen to match some other client's authenticator.
-
-   [11] If this is not done, an attacker could subvert the
-   authentication by recording the ticket and authenticator sent over
-   the network to a server and replaying them following an event that
-   caused the server to lose track of recently seen authenticators.
-
-   [12] In the Kerberos version 4 protocol, the timestamp in the reply
-   was the client's timestamp plus one. This is not necessary in version
-   5 because version 5 messages are formatted in such a way that it is
-   not possible to create the reply by judicious message surgery (even
-   in encrypted form) without knowledge of the appropriate encryption
-   keys.
-
-   [13] Note that for encrypting the KRB_AP_REP message, the sub-session
-   key is not used, even if present in the Authenticator.
-
-   [14] Implementations of the protocol may provide routines to choose
-   subkeys based on session keys and random numbers and to generate a
-   negotiated key to be returned in the KRB_AP_REP message.
-
-   [15]This can be accomplished in several ways. It might be known
-   beforehand (since the realm is part of the principal identifier), it
-   might be stored in a nameserver, or it might be obtained from a
-   configuration file. If the realm to be used is obtained from a
-   nameserver, there is a danger of being spoofed if the nameservice
-   providing the realm name is not authenticated.  This might result in
-   the use of a realm which has been compromised, and would result in an
-   attacker's ability to compromise the authentication of the
-   application server to the client.
-
-   [16] If the client selects a sub-session key, care must be taken to
-   ensure the randomness of the selected sub-session key. One approach
-   would be to generate a random number and XOR it with the session key
-   from the ticket-granting ticket.
-
-
-
-
-
-
-
-
-
-
-
-
-
-March 2003                                                    [Page 133]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-05.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-05.txt
deleted file mode 100644
index 1d62a9589..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-05.txt
+++ /dev/null
@@ -1,8267 +0,0 @@
-INTERNET-DRAFT                                          Clifford Neuman
-Obsoletes: 1510                                                 USC-ISI
-                                                                 Tom Yu
-                                                            Sam Hartman
-                                                            Ken Raeburn
-                                                                    MIT
-                                                      February 15, 2004
-                                                Expires 15 August, 2004
-
-            The Kerberos Network Authentication Service (V5)
-
-STATUS OF THIS MEMO
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC 2026. 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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   To learn the current status of any Internet-Draft, please check the
-   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
-   Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
-   ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
-
-   The distribution of this memo is unlimited. It is filed as draft-
-   ietf-krb-wg-kerberos-clarifications-05.txt, and expires 15 August
-   2004.  Please send comments to: ietf-krb-wg@anl.gov
-
-ABSTRACT
-
-   This document provides an overview and specification of Version 5 of
-   the Kerberos protocol, and updates RFC1510 to clarify aspects of the
-   protocol and its intended use that require more detailed or clearer
-   explanation than was provided in RFC1510. This document is intended
-   to provide a detailed description of the protocol, suitable for
-   implementation, together with descriptions of the appropriate use of
-   protocol messages and fields within those messages.
-
-
-
-February 2004                                                   [Page 1]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-OVERVIEW
-
-   This document describes the concepts and model upon which the
-   Kerberos network authentication system is based. It also specifies
-   Version 5 of the Kerberos protocol.  The motivations, goals,
-   assumptions, and rationale behind most design decisions are treated
-   cursorily; they are more fully described in a paper available in IEEE
-   communications [NT94] and earlier in the Kerberos portion of the
-   Athena Technical Plan [MNSS87].
-
-   This document is not intended to describe Kerberos to the end user,
-   system administrator, or application developer. Higher level papers
-   describing Version 5 of the Kerberos system [NT94] and documenting
-   version 4 [SNS88], are available elsewhere.
-
-BACKGROUND
-
-   The Kerberos model is based in part on Needham and Schroeder's
-   trusted third-party authentication protocol [NS78] and on
-   modifications suggested by Denning and Sacco [DS81]. The original
-   design and implementation of Kerberos Versions 1 through 4 was the
-   work of two former Project Athena staff members, Steve Miller of
-   Digital Equipment Corporation and Clifford Neuman (now at the
-   Information Sciences Institute of the University of Southern
-   California), along with Jerome Saltzer, Technical Director of Project
-   Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other
-   members of Project Athena have also contributed to the work on
-   Kerberos.
-
-   Version 5 of the Kerberos protocol (described in this document) has
-   evolved from Version 4 based on new requirements and desires for
-   features not available in Version 4. The design of Version 5 of the
-   Kerberos protocol was led by Clifford Neuman and John Kohl with much
-   input from the community. The development of the MIT reference
-   implementation was led at MIT by John Kohl and Theodore Ts'o, with
-   help and contributed code from many others. Since RFC1510 was issued,
-   extensions and revisions to the protocol have been proposed by many
-   individuals. Some of these proposals are reflected in this document.
-   Where such changes involved significant effort, the document cites
-   the contribution of the proposer.
-
-   Reference implementations of both version 4 and version 5 of Kerberos
-   are publicly available and commercial implementations have been
-   developed and are widely used. Details on the differences between
-   Kerberos Versions 4 and 5 can be found in [KNT94].
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119.
-
-
-February 2004                                                   [Page 2]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-                            Table of Contents
-
-
-
-1. Introduction ...................................................    7
-1.1. Cross-realm operation ........................................    9
-1.2. Choosing a principal with which to communicate ...............   10
-1.3. Authorization ................................................   11
-1.4. Extending Kerberos Without Breaking Interoperability .........   12
-1.4.1. Compatibility with RFC 1510 ................................   12
-1.4.2. Sending Extensible Messages ................................   13
-1.5. Environmental assumptions ....................................   14
-1.6. Glossary of terms ............................................   14
-2. Ticket flag uses and requests ..................................   17
-2.1. Initial, pre-authenticated, and hardware authenticated
-      tickets .....................................................   18
-2.2. Invalid tickets ..............................................   18
-2.3. Renewable tickets ............................................   18
-2.4. Postdated tickets ............................................   19
-2.5. Proxiable and proxy tickets ..................................   20
-2.6. Forwardable tickets ..........................................   21
-2.7. Transited Policy Checking ....................................   21
-2.8. OK as Delegate ...............................................   22
-2.9. Other KDC options ............................................   23
-2.9.1. Renewable-OK ...............................................   23
-2.9.2. ENC-TKT-IN-SKEY ............................................   23
-2.9.3. Passwordless Hardware Authentication .......................   23
-3. Message Exchanges ..............................................   23
-3.1. The Authentication Service Exchange ..........................   23
-3.1.1. Generation of KRB_AS_REQ message ...........................   25
-3.1.2. Receipt of KRB_AS_REQ message ..............................   25
-3.1.3. Generation of KRB_AS_REP message ...........................   25
-3.1.4. Generation of KRB_ERROR message ............................   28
-3.1.5. Receipt of KRB_AS_REP message ..............................   28
-3.1.6. Receipt of KRB_ERROR message ...............................   29
-3.2. The Client/Server Authentication Exchange ....................   30
-3.2.1. The KRB_AP_REQ message .....................................   30
-3.2.2. Generation of a KRB_AP_REQ message .........................   30
-3.2.3. Receipt of KRB_AP_REQ message ..............................   31
-3.2.4. Generation of a KRB_AP_REP message .........................   33
-3.2.5. Receipt of KRB_AP_REP message ..............................   33
-3.2.6. Using the encryption key ...................................   34
-3.3. The Ticket-Granting Service (TGS) Exchange ...................   34
-3.3.1. Generation of KRB_TGS_REQ message ..........................   36
-3.3.2. Receipt of KRB_TGS_REQ message .............................   37
-
-
-
-February 2004                                                   [Page 3]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-3.3.3. Generation of KRB_TGS_REP message ..........................   38
-3.3.3.1. Checking for revoked tickets .............................   40
-3.3.3.2. Encoding the transited field .............................   41
-3.3.4. Receipt of KRB_TGS_REP message .............................   42
-3.4. The KRB_SAFE Exchange ........................................   43
-3.4.1. Generation of a KRB_SAFE message ...........................   43
-3.4.2. Receipt of KRB_SAFE message ................................   43
-3.5. The KRB_PRIV Exchange ........................................   44
-3.5.1. Generation of a KRB_PRIV message ...........................   45
-3.5.2. Receipt of KRB_PRIV message ................................   45
-3.6. The KRB_CRED Exchange ........................................   46
-3.6.1. Generation of a KRB_CRED message ...........................   46
-3.6.2. Receipt of KRB_CRED message ................................   47
-3.7. User-to-User Authentication Exchanges ........................   47
-4. Encryption and Checksum Specifications .........................   49
-5. Message Specifications .........................................   50
-5.1. Specific Compatibility Notes on ASN.1 ........................   52
-5.1.1. ASN.1 Distinguished Encoding Rules .........................   52
-5.1.2. Optional Integer Fields ....................................   52
-5.1.3. Empty SEQUENCE OF Types ....................................   52
-5.1.4. Unrecognized Tag Numbers ...................................   53
-5.1.5. Tag Numbers Greater Than 30 ................................   53
-5.2. Basic Kerberos Types .........................................   53
-5.2.1. KerberosString .............................................   53
-5.2.2. Realm and PrincipalName ....................................   55
-5.2.3. KerberosTime ...............................................   56
-5.2.4. Constrained Integer types ..................................   56
-5.2.5. HostAddress and HostAddresses ..............................   57
-5.2.6. AuthorizationData ..........................................   57
-5.2.6.1. IF-RELEVANT ..............................................   59
-5.2.6.2. KDCIssued ................................................   59
-5.2.6.3. AND-OR ...................................................   60
-5.2.6.4. MANDATORY-FOR-KDC ........................................   60
-5.2.7. PA-DATA ....................................................   61
-5.2.7.1. PA-TGS-REQ ...............................................   62
-5.2.7.2. Encrypted Timestamp Pre-authentication ...................   62
-5.2.7.3. PA-PW-SALT ...............................................   62
-5.2.7.4. PA-ETYPE-INFO ............................................   63
-5.2.7.5. PA-ETYPE-INFO2 ...........................................   63
-5.2.8. KerberosFlags ..............................................   64
-5.2.9. Cryptosystem-related Types .................................   65
-5.3. Tickets ......................................................   67
-5.4. Specifications for the AS and TGS exchanges ..................   74
-5.4.1. KRB_KDC_REQ definition .....................................   74
-5.4.2. KRB_KDC_REP definition .....................................   82
-5.5. Client/Server (CS) message specifications ....................   85
-5.5.1. KRB_AP_REQ definition ......................................   85
-5.5.2. KRB_AP_REP definition ......................................   89
-
-
-
-February 2004                                                   [Page 4]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-5.5.3. Error message reply ........................................   90
-5.6. KRB_SAFE message specification ...............................   90
-5.6.1. KRB_SAFE definition ........................................   90
-5.7. KRB_PRIV message specification ...............................   92
-5.7.1. KRB_PRIV definition ........................................   92
-5.8. KRB_CRED message specification ...............................   92
-5.8.1. KRB_CRED definition ........................................   93
-5.9. Error message specification ..................................   95
-5.9.1. KRB_ERROR definition .......................................   95
-5.10. Application Tag Numbers .....................................   97
-6. Naming Constraints .............................................   98
-6.1. Realm Names ..................................................   98
-6.2. Principal Names ..............................................   99
-6.2.1. Name of server principals ..................................  101
-7. Constants and other defined values .............................  101
-7.1. Host address types ...........................................  101
-7.2. KDC messaging - IP Transports ................................  103
-7.2.1. UDP/IP transport ...........................................  103
-7.2.2. TCP/IP transport ...........................................  103
-7.2.3. KDC Discovery on IP Networks ...............................  104
-7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names .......  105
-7.2.3.2. Specifying KDC Location information with DNS SRV
-      records .....................................................  105
-7.2.3.3. KDC Discovery for Domain Style Realm Names on IP
-      Networks ....................................................  106
-7.3. Name of the TGS ..............................................  106
-7.4. OID arc for KerberosV5 .......................................  106
-7.5. Protocol constants and associated values .....................  106
-7.5.1. Key usage numbers ..........................................  107
-7.5.2. PreAuthentication Data Types
-      .............................................................  108
-7.5.3. Address Types
-      .............................................................  109
-7.5.4. Authorization Data Types
-      .............................................................  109
-7.5.5. Transited Encoding Types
-      .............................................................  109
-7.5.6. Protocol Version Number
-      .............................................................  110
-7.5.7. Kerberos Message Types
-      .............................................................  110
-7.5.8. Name Types
-      .............................................................  110
-7.5.9. Error Codes
-      .............................................................  110
-8. Interoperability requirements ..................................  112
-8.1. Specification 2 ..............................................  112
-8.2. Recommended KDC values .......................................  115
-
-
-
-February 2004                                                   [Page 5]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-9. IANA considerations ............................................  115
-10. Security Considerations .......................................  116
-11. Author's Addresses ............................................  120
-12. Acknowledgements ..............................................  121
-13. REFERENCES ....................................................  122
-13.1 NORMATIVE REFERENCES .........................................  122
-13.2 INFORMATIVE REFERENCES .......................................  123
-14. Copyright Statement ...........................................  124
-15. Intellectual Property .........................................  125
-A. ASN.1 module ...................................................  125
-B. Changes since RFC-1510 .........................................  133
-END NOTES .........................................................  136
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-February 2004                                                   [Page 6]
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-1. Introduction
-
-      Kerberos provides a means of verifying the identities of
-      principals, (e.g. a workstation user or a network server) on an
-      open (unprotected) network. This is accomplished without relying
-      on assertions by the host operating system, without basing trust
-      on host addresses, without requiring physical security of all the
-      hosts on the network, and under the assumption that packets
-      traveling along the network can be read, modified, and inserted at
-      will[1]. Kerberos performs authentication under these conditions
-      as a trusted third-party authentication service by using
-      conventional (shared secret key [2]) cryptography. Kerberos
-      extensions (outside the scope of this document) can provide for
-      the use of public key cryptography during certain phases of the
-      authentication protocol [@RFCE: if PKINIT advances concurrently
-      include reference to the RFC here]. Such extensions support
-      Kerberos authentication for users registered with public key
-      certification authorities and provide certain benefits of public
-      key cryptography in situations where they are needed.
-
-      The basic Kerberos authentication process proceeds as follows: A
-      client sends a request to the authentication server (AS)
-      requesting "credentials" for a given server. The AS responds with
-      these credentials, encrypted in the client's key. The credentials
-      consist of a "ticket" for the server and a temporary encryption
-      key (often called a "session key"). The client transmits the
-      ticket (which contains the client's identity and a copy of the
-      session key, all encrypted in the server's key) to the server. The
-      session key (now shared by the client and server) is used to
-      authenticate the client, and may optionally be used to
-      authenticate the server. It may also be used to encrypt further
-      communication between the two parties or to exchange a separate
-      sub-session key to be used to encrypt further communication.
-
-      Implementation of the basic protocol consists of one or more
-      authentication servers running on physically secure hosts. The
-      authentication servers maintain a database of principals (i.e.,
-      users and servers) and their secret keys. Code libraries provide
-      encryption and implement the Kerberos protocol.  In order to add
-      authentication to its transactions, a typical network application
-      adds calls to the Kerberos library directly or through the Generic
-      Security Services Application Programming Interface, GSSAPI,
-      described in separate document [ref to GSSAPI RFC]. These calls
-      result in the transmission of the necessary messages to achieve
-      authentication.
-
-      The Kerberos protocol consists of several sub-protocols (or
-      exchanges).  There are two basic methods by which a client can ask
-
-
-
-February 2004                                                   [Page 7]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      a Kerberos server for credentials. In the first approach, the
-      client sends a cleartext request for a ticket for the desired
-      server to the AS. The reply is sent encrypted in the client's
-      secret key. Usually this request is for a ticket-granting ticket
-      (TGT) which can later be used with the ticket-granting server
-      (TGS).  In the second method, the client sends a request to the
-      TGS. The client uses the TGT to authenticate itself to the TGS in
-      the same manner as if it were contacting any other application
-      server that requires Kerberos authentication. The reply is
-      encrypted in the session key from the TGT.  Though the protocol
-      specification describes the AS and the TGS as separate servers,
-      they are implemented in practice as different protocol entry
-      points within a single Kerberos server.
-
-      Once obtained, credentials may be used to verify the identity of
-      the principals in a transaction, to ensure the integrity of
-      messages exchanged between them, or to preserve privacy of the
-      messages. The application is free to choose whatever protection
-      may be necessary.
-
-      To verify the identities of the principals in a transaction, the
-      client transmits the ticket to the application server. Since the
-      ticket is sent "in the clear" (parts of it are encrypted, but this
-      encryption doesn't thwart replay) and might be intercepted and
-      reused by an attacker, additional information is sent to prove
-      that the message originated with the principal to whom the ticket
-      was issued. This information (called the authenticator) is
-      encrypted in the session key, and includes a timestamp. The
-      timestamp proves that the message was recently generated and is
-      not a replay.  Encrypting the authenticator in the session key
-      proves that it was generated by a party possessing the session
-      key. Since no one except the requesting principal and the server
-      know the session key (it is never sent over the network in the
-      clear) this guarantees the identity of the client.
-
-      The integrity of the messages exchanged between principals can
-      also be guaranteed using the session key (passed in the ticket and
-      contained in the credentials). This approach provides detection of
-      both replay attacks and message stream modification attacks. It is
-      accomplished by generating and transmitting a collision-proof
-      checksum (elsewhere called a hash or digest function) of the
-      client's message, keyed with the session key. Privacy and
-      integrity of the messages exchanged between principals can be
-      secured by encrypting the data to be passed using the session key
-      contained in the ticket or the sub-session key found in the
-      authenticator.
-
-      The authentication exchanges mentioned above require read-only
-
-
-
-February 2004                                                   [Page 8]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      access to the Kerberos database. Sometimes, however, the entries
-      in the database must be modified, such as when adding new
-      principals or changing a principal's key.  This is done using a
-      protocol between a client and a third Kerberos server, the
-      Kerberos Administration Server (KADM). There is also a protocol
-      for maintaining multiple copies of the Kerberos database. Neither
-      of these protocols are described in this document.
-
-1.1. Cross-realm operation
-
-      The Kerberos protocol is designed to operate across organizational
-      boundaries. A client in one organization can be authenticated to a
-      server in another. Each organization wishing to run a Kerberos
-      server establishes its own "realm". The name of the realm in which
-      a client is registered is part of the client's name, and can be
-      used by the end-service to decide whether to honor a request.
-
-      By establishing "inter-realm" keys, the administrators of two
-      realms can allow a client authenticated in the local realm to
-      prove its identity to servers in other realms[3]. The exchange of
-      inter-realm keys (a separate key may be used for each direction)
-      registers the ticket-granting service of each realm as a principal
-      in the other realm. A client is then able to obtain a ticket-
-      granting ticket for the remote realm's ticket-granting service
-      from its local realm. When that ticket-granting ticket is used,
-      the remote ticket-granting service uses the inter-realm key (which
-      usually differs from its own normal TGS key) to decrypt the
-      ticket-granting ticket, and is thus certain that it was issued by
-      the client's own TGS. Tickets issued by the remote ticket-granting
-      service will indicate to the end-service that the client was
-      authenticated from another realm.
-
-      A realm is said to communicate with another realm if the two
-      realms share an inter-realm key, or if the local realm shares an
-      inter-realm key with an intermediate realm that communicates with
-      the remote realm. An authentication path is the sequence of
-      intermediate realms that are transited in communicating from one
-      realm to another.
-
-      Realms may be organized hierarchically. Each realm shares a key
-      with its parent and a different key with each child. If an inter-
-      realm key is not directly shared by two realms, the hierarchical
-      organization allows an authentication path to be easily
-      constructed. If a hierarchical organization is not used, it may be
-      necessary to consult a database in order to construct an
-      authentication path between realms.
-
-      Although realms are typically hierarchical, intermediate realms
-
-
-
-February 2004                                                   [Page 9]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      may be bypassed to achieve cross-realm authentication through
-      alternate authentication paths (these might be established to make
-      communication between two realms more efficient). It is important
-      for the end-service to know which realms were transited when
-      deciding how much faith to place in the authentication process. To
-      facilitate this decision, a field in each ticket contains the
-      names of the realms that were involved in authenticating the
-      client.
-
-      The application server is ultimately responsible for accepting or
-      rejecting authentication and SHOULD check the transited field. The
-      application server may choose to rely on the KDC for the
-      application server's realm to check the transited field. The
-      application server's KDC will set the TRANSITED-POLICY-CHECKED
-      flag in this case. The KDCs for intermediate realms may also check
-      the transited field as they issue ticket-granting tickets for
-      other realms, but they are encouraged not to do so. A client may
-      request that the KDCs not check the transited field by setting the
-      DISABLE-TRANSITED-CHECK flag. KDCs SHOULD honor this flag.
-
-1.2. Choosing a principal with which to communicate
-
-      The Kerberos protocol provides the means for verifying (subject to
-      the assumptions in 1.5) that the entity with which one
-      communicates is the same entity that was registered with the KDC
-      using the claimed identity (principal name). It is still necessary
-      to determine whether that identity corresponds to the entity with
-      which one intends to communicate.
-
-      When appropriate data has been exchanged in advance, this
-      determination may be performed syntactically by the application
-      based on the application protocol specification, information
-      provided by the user, and configuration files. For example, the
-      server principal name (including realm) for a telnet server might
-      be derived from the user specified host name (from the telnet
-      command line), the "host/" prefix specified in the application
-      protocol specification, and a mapping to a Kerberos realm derived
-      syntactically from the domain part of the specified hostname and
-      information from the local Kerberos realms database.
-
-      One can also rely on trusted third parties to make this
-      determination, but only when the data obtained from the third
-      party is suitably integrity protected while resident on the third
-      party server and when transmitted.  Thus, for example, one should
-      not rely on an unprotected domain name system record to map a host
-      alias to the primary name of a server, accepting the primary name
-      as the party one intends to contact, since an attacker can modify
-      the mapping and impersonate the party with which one intended to
-
-
-
-February 2004                                                  [Page 10]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      communicate.
-
-      Implementations of Kerberos and protocols based on Kerberos MUST
-      NOT use insecure DNS queries to canonicalize the hostname
-      components of the service principal names (i.e. MUST NOT use
-      insecure DNS queries to map one name to another to determine the
-      host part of the principal name with which one is to communicate).
-      In an environment without secure name service, application authors
-      MAY append a statically configured domain name to unqualified
-      hostnames before passing the name to the security mechanisms, but
-      should do no more than that.  Secure name service facilities, if
-      available, might be trusted for hostname canonicalization, but
-      such canonicalization by the client SHOULD NOT be required by KDC
-      implementations.
-
-      Implementation note: Many current implementations do some degree
-      of canonicalization of the provided service name, often using DNS
-      even though it creates security problems. However there is no
-      consistency among implementations about whether the service name
-      is case folded to lower case or whether reverse resolution is
-      used. To maximize interoperability and security, applications
-      SHOULD provide security mechanisms with names which result from
-      folding the user-entered name to lower case, without performing
-      any other modifications or canonicalization.
-
-1.3. Authorization
-
-      As an authentication service, Kerberos provides a means of
-      verifying the identity of principals on a network. Authentication
-      is usually useful primarily as a first step in the process of
-      authorization, determining whether a client may use a service,
-      which objects the client is allowed to access, and the type of
-      access allowed for each. Kerberos does not, by itself, provide
-      authorization. Possession of a client ticket for a service
-      provides only for authentication of the client to that service,
-      and in the absence of a separate authorization procedure, it
-      should not be considered by an application as authorizing the use
-      of that service.
-
-      Such separate authorization methods MAY be implemented as
-      application specific access control functions and may utilize
-      files on the application server, or on separately issued
-      authorization credentials such as those based on proxies [Neu93],
-      or on other authorization services. Separately authenticated
-      authorization credentials MAY be embedded in a ticket's
-      authorization data when encapsulated by the KDC-issued
-      authorization data element.
-
-
-
-
-February 2004                                                  [Page 11]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      Applications should not accept the mere issuance of a service
-      ticket by the Kerberos server (even by a modified Kerberos server)
-      as granting authority to use the service, since such applications
-      may become vulnerable to the bypass of this authorization check in
-      an environment if they interoperate with other KDCs or where other
-      options for application authentication are provided.
-
-1.4. Extending Kerberos Without Breaking Interoperability
-
-      As the deployed base of Kerberos implementations grows, extending
-      Kerberos becomes more important. Unfortunately some extensions to
-      the existing Kerberos protocol create interoperability issues
-      because of uncertainty regarding the treatment of certain
-      extensibility options by some implementations. This section
-      includes guidelines that will enable future implementations to
-      maintain interoperability.
-
-      Kerberos provides a general mechanism for protocol extensibility.
-      Some protocol messages contain typed holes -- sub-messages that
-      contain an octet-string along with an integer that defines how to
-      interpret the octet-string. The integer types are registered
-      centrally, but can be used both for vendor extensions and for
-      extensions standardized through the IETF.
-
-      In this document, the word "extension" means an extension by
-      defining a new type to insert into an existing typed hole in a
-      protocol message.  It does not mean extension by addition of new
-      fields to ASN.1 types, unless explicitly indicated otherwise in
-      the text.
-
-1.4.1. Compatibility with RFC 1510
-
-      It is important to note that existing Kerberos message formats can
-      not be readily extended by adding fields to the ASN.1 types.
-      Sending additional fields often results in the entire message
-      being discarded without an error indication. Future versions of
-      this specification will provide guidelines to ensure that ASN.1
-      fields can be added without creating an interoperability problem.
-
-      In the meantime, all new or modified implementations of Kerberos
-      that receive an unknown message extension SHOULD preserve the
-      encoding of the extension but otherwise ignore the presence of the
-      extension. Recipients MUST NOT decline a request simply because an
-      extension is present.
-
-      There is one exception to this rule. If an unknown authorization
-      data element type is received by a server other than the ticket
-      granting service either in an AP-REQ or in a ticket contained in
-
-
-
-February 2004                                                  [Page 12]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      an AP-REQ, then authentication MUST fail. One of the primary uses
-      of authorization data is to restrict the use of the ticket. If the
-      service cannot determine whether the restriction applies to that
-      service then a security weakness may result if the ticket can be
-      used for that service. Authorization elements that are optional
-      SHOULD be enclosed in the AD-IF-RELEVANT element.
-
-      The ticket granting service MUST ignore but propagate to
-      derivative tickets any unknown authorization data types, unless
-      those data types are embedded in a MANDATORY-FOR-KDC element, in
-      which case the request will be rejected.  This behavior is
-      appropriate because requiring that the ticket granting service
-      understand unknown authorization data types would require that KDC
-      software be upgraded to understand new application-level
-      restrictions before applications used these restrictions,
-      decreasing the utility of authorization data as a mechanism for
-      restricting the use of tickets. No security problem is created
-      because services to which the tickets are issued will verify the
-      authorization data.
-
-      Implementation note: Many RFC 1510 implementations ignore unknown
-      authorization data elements. Depending on these implementations to
-      honor authorization data restrictions may create a security
-      weakness.
-
-1.4.2. Sending Extensible Messages
-
-      Care must be taken to ensure that old implementations can
-      understand messages sent to them even if they do not understand an
-      extension that is used. Unless the sender knows an extension is
-      supported, the extension cannot change the semantics of the core
-      message or previously defined extensions.
-
-      For example, an extension including key information necessary to
-      decrypt the encrypted part of a KDC-REP could only be used in
-      situations where the recipient was known to support the extension.
-      Thus when designing such extensions it is important to provide a
-      way for the recipient to notify the sender of support for the
-      extension. For example in the case of an extension that changes
-      the KDC-REP reply key, the client could indicate support for the
-      extension by including a padata element in the AS-REQ sequence.
-      The KDC should only use the extension if this padata element is
-      present in the AS-REQ. Even if policy requires the use of the
-      extension, it is better to return an error indicating that the
-      extension is required than to use the extension when the recipient
-      may not support it; debugging why implementations do not
-      interoperate is easier when errors are returned.
-
-
-
-
-February 2004                                                  [Page 13]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-1.5. Environmental assumptions
-
-      Kerberos imposes a few assumptions on the environment in which it
-      can properly function:
-
-   *  "Denial of service" attacks are not solved with Kerberos. There
-      are places in the protocols where an intruder can prevent an
-      application from participating in the proper authentication steps.
-      Detection and solution of such attacks (some of which can appear
-      to be not-uncommon "normal" failure modes for the system) is
-      usually best left to the human administrators and users.
-
-   *  Principals MUST keep their secret keys secret. If an intruder
-      somehow steals a principal's key, it will be able to masquerade as
-      that principal or impersonate any server to the legitimate
-      principal.
-
-   *  "Password guessing" attacks are not solved by Kerberos. If a user
-      chooses a poor password, it is possible for an attacker to
-      successfully mount an offline dictionary attack by repeatedly
-      attempting to decrypt, with successive entries from a dictionary,
-      messages obtained which are encrypted under a key derived from the
-      user's password.
-
-   *  Each host on the network MUST have a clock which is "loosely
-      synchronized" to the time of the other hosts; this synchronization
-      is used to reduce the bookkeeping needs of application servers
-      when they do replay detection. The degree of "looseness" can be
-      configured on a per-server basis, but is typically on the order of
-      5 minutes. If the clocks are synchronized over the network, the
-      clock synchronization protocol MUST itself be secured from network
-      attackers.
-
-   *  Principal identifiers are not recycled on a short-term basis. A
-      typical mode of access control will use access control lists
-      (ACLs) to grant permissions to particular principals. If a stale
-      ACL entry remains for a deleted principal and the principal
-      identifier is reused, the new principal will inherit rights
-      specified in the stale ACL entry. By not re-using principal
-      identifiers, the danger of inadvertent access is removed.
-
-1.6. Glossary of terms
-
-      Below is a list of terms used throughout this document.
-
-   Authentication
-      Verifying the claimed identity of a principal.
-
-
-
-
-February 2004                                                  [Page 14]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-   Authentication header
-      A record containing a Ticket and an Authenticator to be presented
-      to a server as part of the authentication process.
-
-   Authentication path
-      A sequence of intermediate realms transited in the authentication
-      process when communicating from one realm to another.
-
-   Authenticator
-      A record containing information that can be shown to have been
-      recently generated using the session key known only by the client
-      and server.
-
-   Authorization
-      The process of determining whether a client may use a service,
-      which objects the client is allowed to access, and the type of
-      access allowed for each.
-
-   Capability
-      A token that grants the bearer permission to access an object or
-      service. In Kerberos, this might be a ticket whose use is
-      restricted by the contents of the authorization data field, but
-      which lists no network addresses, together with the session key
-      necessary to use the ticket.
-
-   Ciphertext
-      The output of an encryption function. Encryption transforms
-      plaintext into ciphertext.
-
-   Client
-      A process that makes use of a network service on behalf of a user.
-      Note that in some cases a Server may itself be a client of some
-      other server (e.g. a print server may be a client of a file
-      server).
-
-   Credentials
-      A ticket plus the secret session key necessary to successfully use
-      that ticket in an authentication exchange.
-
-   Encryption Type (etype)
-      When associated with encrypted data, an encryption type identifies
-      the algorithm used to encrypt the data and is used to select the
-      appropriate algorithm for decrypting the data.  Encryption type
-      tags are communicated in other messages to enumerate algorithms
-      that are desired, supported, preferred, or allowed to be used for
-      encryption of data between parties.  This preference is combined
-      with local information and policy to select an algorithm to be
-      used.
-
-
-
-February 2004                                                  [Page 15]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-   KDC
-      Key Distribution Center, a network service that supplies tickets
-      and temporary session keys; or an instance of that service or the
-      host on which it runs. The KDC services both initial ticket and
-      ticket-granting ticket requests. The initial ticket portion is
-      sometimes referred to as the Authentication Server (or service).
-      The ticket-granting ticket portion is sometimes referred to as the
-      ticket-granting server (or service).
-
-   Kerberos
-      The name given to the Project Athena's authentication service, the
-      protocol used by that service, or the code used to implement the
-      authentication service.  The name is adopted from the three-headed
-      dog which guards Hades.
-
-   Key Version Number (kvno)
-      A tag associated with encrypted data identifies which key was used
-      for encryption when a long lived key associated with a principal
-      changes over time.  It is used during the transition to a new key
-      so that the party decrypting a message can tell whether the data
-      was encrypted using the old or the new key.
-
-   Plaintext
-      The input to an encryption function or the output of a decryption
-      function. Decryption transforms ciphertext into plaintext.
-
-   Principal
-      A named client or server entity that participates in a network
-      communication, with one name that is considered canonical.
-
-   Principal identifier
-      The canonical name used to uniquely identify each different
-      principal.
-
-   Seal
-      To encipher a record containing several fields in such a way that
-      the fields cannot be individually replaced without either
-      knowledge of the encryption key or leaving evidence of tampering.
-
-   Secret key
-      An encryption key shared by a principal and the KDC, distributed
-      outside the bounds of the system, with a long lifetime. In the
-      case of a human user's principal, the secret key MAY be derived
-      from a password.
-
-   Server
-      A particular Principal which provides a resource to network
-      clients.  The server is sometimes referred to as the Application
-
-
-
-February 2004                                                  [Page 16]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      Server.
-
-   Service
-      A resource provided to network clients; often provided by more
-      than one server (for example, remote file service).
-
-   Session key
-      A temporary encryption key used between two principals, with a
-      lifetime limited to the duration of a single login "session".  In
-      the Kerberos system, a session key is generated by the KDC.  The
-      session key is distinct from the sub-session key, described next..
-
-   Sub-session key
-      A temporary encryption key used between two principals, selected
-      and exchanged by the principals using the session key, and with a
-      lifetime limited to the duration of a single association. The sub-
-      session key is also referred to as the subkey.
-
-   Ticket
-      A record that helps a client authenticate itself to a server; it
-      contains the client's identity, a session key, a timestamp, and
-      other information, all sealed using the server's secret key. It
-      only serves to authenticate a client when presented along with a
-      fresh Authenticator.
-
-
-2. Ticket flag uses and requests
-
-      Each Kerberos ticket contains a set of flags which are used to
-      indicate attributes of that ticket. Most flags may be requested by
-      a client when the ticket is obtained; some are automatically
-      turned on and off by a Kerberos server as required. The following
-      sections explain what the various flags mean and give examples of
-      reasons to use them. With the exception of the INVALID flag
-      clients MUST ignore ticket flags that are not recognized. KDCs
-      MUST ignore KDC options that are not recognized. Some
-      implementations of RFC 1510 are known to reject unknown KDC
-      options, so clients may need to resend a request without new KDC
-      options if the request was rejected when sent with options added
-      since RFC 1510. Since new KDCs will ignore unknown options,
-      clients MUST confirm that the ticket returned by the KDC meets
-      their needs.
-
-      Note that it is not, in general, possible to determine whether an
-      option was not honored because it was not understood or because it
-      was rejected either through configuration or policy. When adding a
-      new option to the Kerberos protocol, designers should consider
-      whether the distinction is important for their option. In cases
-
-
-
-February 2004                                                  [Page 17]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      where it is, a mechanism for the KDC to return an indication that
-      the option was understood but rejected needs to be provided in the
-      specification of the option. Often in such cases, the mechanism
-      needs to be broad enough to permit an error or reason to be
-      returned.
-
-2.1. Initial, pre-authenticated, and hardware authenticated tickets
-
-      The INITIAL flag indicates that a ticket was issued using the AS
-      protocol, rather than issued based on a ticket-granting ticket.
-      Application servers that want to require the demonstrated
-      knowledge of a client's secret key (e.g. a password-changing
-      program) can insist that this flag be set in any tickets they
-      accept, and thus be assured that the client's key was recently
-      presented to the application client.
-
-      The PRE-AUTHENT and HW-AUTHENT flags provide additional
-      information about the initial authentication, regardless of
-      whether the current ticket was issued directly (in which case
-      INITIAL will also be set) or issued on the basis of a ticket-
-      granting ticket (in which case the INITIAL flag is clear, but the
-      PRE-AUTHENT and HW-AUTHENT flags are carried forward from the
-      ticket-granting ticket).
-
-2.2. Invalid tickets
-
-      The INVALID flag indicates that a ticket is invalid. Application
-      servers MUST reject tickets which have this flag set. A postdated
-      ticket will be issued in this form. Invalid tickets MUST be
-      validated by the KDC before use, by presenting them to the KDC in
-      a TGS request with the VALIDATE option specified. The KDC will
-      only validate tickets after their starttime has passed. The
-      validation is required so that postdated tickets which have been
-      stolen before their starttime can be rendered permanently invalid
-      (through a hot-list mechanism) (see section 3.3.3.1).
-
-2.3. Renewable tickets
-
-      Applications may desire to hold tickets which can be valid for
-      long periods of time. However, this can expose their credentials
-      to potential theft for equally long periods, and those stolen
-      credentials would be valid until the expiration time of the
-      ticket(s). Simply using short-lived tickets and obtaining new ones
-      periodically would require the client to have long-term access to
-      its secret key, an even greater risk. Renewable tickets can be
-      used to mitigate the consequences of theft. Renewable tickets have
-      two "expiration times": the first is when the current instance of
-      the ticket expires, and the second is the latest permissible value
-
-
-
-February 2004                                                  [Page 18]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      for an individual expiration time. An application client must
-      periodically (i.e. before it expires) present a renewable ticket
-      to the KDC, with the RENEW option set in the KDC request. The KDC
-      will issue a new ticket with a new session key and a later
-      expiration time. All other fields of the ticket are left
-      unmodified by the renewal process. When the latest permissible
-      expiration time arrives, the ticket expires permanently. At each
-      renewal, the KDC MAY consult a hot-list to determine if the ticket
-      had been reported stolen since its last renewal; it will refuse to
-      renew such stolen tickets, and thus the usable lifetime of stolen
-      tickets is reduced.
-
-      The RENEWABLE flag in a ticket is normally only interpreted by the
-      ticket-granting service (discussed below in section 3.3). It can
-      usually be ignored by application servers. However, some
-      particularly careful application servers MAY disallow renewable
-      tickets.
-
-      If a renewable ticket is not renewed by its expiration time, the
-      KDC will not renew the ticket. The RENEWABLE flag is reset by
-      default, but a client MAY request it be set by setting the
-      RENEWABLE option in the KRB_AS_REQ message. If it is set, then the
-      renew-till field in the ticket contains the time after which the
-      ticket may not be renewed.
-
-2.4. Postdated tickets
-
-      Applications may occasionally need to obtain tickets for use much
-      later, e.g. a batch submission system would need tickets to be
-      valid at the time the batch job is serviced. However, it is
-      dangerous to hold valid tickets in a batch queue, since they will
-      be on-line longer and more prone to theft.  Postdated tickets
-      provide a way to obtain these tickets from the KDC at job
-      submission time, but to leave them "dormant" until they are
-      activated and validated by a further request of the KDC. If a
-      ticket theft were reported in the interim, the KDC would refuse to
-      validate the ticket, and the thief would be foiled.
-
-      The MAY-POSTDATE flag in a ticket is normally only interpreted by
-      the ticket-granting service. It can be ignored by application
-      servers. This flag MUST be set in a ticket-granting ticket in
-      order to issue a postdated ticket based on the presented ticket.
-      It is reset by default; it MAY be requested by a client by setting
-      the ALLOW-POSTDATE option in the KRB_AS_REQ message.  This flag
-      does not allow a client to obtain a postdated ticket-granting
-      ticket; postdated ticket-granting tickets can only by obtained by
-      requesting the postdating in the KRB_AS_REQ message. The life
-      (endtime-starttime) of a postdated ticket will be the remaining
-
-
-
-February 2004                                                  [Page 19]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      life of the ticket-granting ticket at the time of the request,
-      unless the RENEWABLE option is also set, in which case it can be
-      the full life (endtime-starttime) of the ticket-granting ticket.
-      The KDC MAY limit how far in the future a ticket may be postdated.
-
-      The POSTDATED flag indicates that a ticket has been postdated. The
-      application server can check the authtime field in the ticket to
-      see when the original authentication occurred. Some services MAY
-      choose to reject postdated tickets, or they may only accept them
-      within a certain period after the original authentication. When
-      the KDC issues a POSTDATED ticket, it will also be marked as
-      INVALID, so that the application client MUST present the ticket to
-      the KDC to be validated before use.
-
-2.5. Proxiable and proxy tickets
-
-      At times it may be necessary for a principal to allow a service to
-      perform an operation on its behalf. The service must be able to
-      take on the identity of the client, but only for a particular
-      purpose. A principal can allow a service to take on the
-      principal's identity for a particular purpose by granting it a
-      proxy.
-
-      The process of granting a proxy using the proxy and proxiable
-      flags is used to provide credentials for use with specific
-      services. Though conceptually also a proxy, users wishing to
-      delegate their identity in a form usable for all purpose MUST use
-      the ticket forwarding mechanism described in the next section to
-      forward a ticket-granting ticket.
-
-      The PROXIABLE flag in a ticket is normally only interpreted by the
-      ticket-granting service. It can be ignored by application servers.
-      When set, this flag tells the ticket-granting server that it is OK
-      to issue a new ticket (but not a ticket-granting ticket) with a
-      different network address based on this ticket. This flag is set
-      if requested by the client on initial authentication. By default,
-      the client will request that it be set when requesting a ticket-
-      granting ticket, and reset when requesting any other ticket.
-
-      This flag allows a client to pass a proxy to a server to perform a
-      remote request on its behalf (e.g. a print service client can give
-      the print server a proxy to access the client's files on a
-      particular file server in order to satisfy a print request).
-
-      In order to complicate the use of stolen credentials, Kerberos
-      tickets are usually valid from only those network addresses
-      specifically included in the ticket[4]. When granting a proxy, the
-      client MUST specify the new network address from which the proxy
-
-
-
-February 2004                                                  [Page 20]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      is to be used, or indicate that the proxy is to be issued for use
-      from any address.
-
-      The PROXY flag is set in a ticket by the TGS when it issues a
-      proxy ticket.  Application servers MAY check this flag and at
-      their option they MAY require additional authentication from the
-      agent presenting the proxy in order to provide an audit trail.
-
-2.6. Forwardable tickets
-
-      Authentication forwarding is an instance of a proxy where the
-      service that is granted is complete use of the client's identity.
-      An example where it might be used is when a user logs in to a
-      remote system and wants authentication to work from that system as
-      if the login were local.
-
-      The FORWARDABLE flag in a ticket is normally only interpreted by
-      the ticket-granting service. It can be ignored by application
-      servers. The FORWARDABLE flag has an interpretation similar to
-      that of the PROXIABLE flag, except ticket-granting tickets may
-      also be issued with different network addresses. This flag is
-      reset by default, but users MAY request that it be set by setting
-      the FORWARDABLE option in the AS request when they request their
-      initial ticket-granting ticket.
-
-      This flag allows for authentication forwarding without requiring
-      the user to enter a password again. If the flag is not set, then
-      authentication forwarding is not permitted, but the same result
-      can still be achieved if the user engages in the AS exchange
-      specifying the requested network addresses and supplies a
-      password.
-
-      The FORWARDED flag is set by the TGS when a client presents a
-      ticket with the FORWARDABLE flag set and requests a forwarded
-      ticket by specifying the FORWARDED KDC option and supplying a set
-      of addresses for the new ticket. It is also set in all tickets
-      issued based on tickets with the FORWARDED flag set. Application
-      servers may choose to process FORWARDED tickets differently than
-      non-FORWARDED tickets.
-
-      If addressless tickets are forwarded from one system to another,
-      clients SHOULD still use this option to obtain a new TGT in order
-      to have different session keys on the different systems.
-
-2.7. Transited Policy Checking
-
-      In Kerberos, the application server is ultimately responsible for
-      accepting or rejecting authentication and SHOULD check that only
-
-
-
-February 2004                                                  [Page 21]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      suitably trusted KDCs are relied upon to authenticate a principal.
-      The transited field in the ticket identifies which realms (and
-      thus which KDCs) were involved in the authentication process and
-      an application server would normally check this field. If any of
-      these are untrusted to authenticate the indicated client principal
-      (probably determined by a realm-based policy), the authentication
-      attempt MUST be rejected. The presence of trusted KDCs in this
-      list does not provide any guarantee; an untrusted KDC may have
-      fabricated the list.
-
-      While the end server ultimately decides whether authentication is
-      valid, the KDC for the end server's realm MAY apply a realm
-      specific policy for validating the transited field and accepting
-      credentials for cross-realm authentication. When the KDC applies
-      such checks and accepts such cross-realm authentication it will
-      set the TRANSITED-POLICY-CHECKED flag in the service tickets it
-      issues based on the cross-realm TGT. A client MAY request that the
-      KDCs not check the transited field by setting the DISABLE-
-      TRANSITED-CHECK flag. KDCs are encouraged but not required to
-      honor this flag.
-
-      Application servers MUST either do the transited-realm checks
-      themselves, or reject cross-realm tickets without TRANSITED-
-      POLICY-CHECKED set.
-
-2.8. OK as Delegate
-
-      For some applications a client may need to delegate authority to a
-      server to act on its behalf in contacting other services.  This
-      requires that the client forward credentials to an intermediate
-      server.  The ability for a client to obtain a service ticket to a
-      server conveys no information to the client about whether the
-      server should be trusted to accept delegated credentials.  The OK-
-      AS-DELEGATE provides a way for a KDC to communicate local realm
-      policy to a client regarding whether an intermediate server is
-      trusted to accept such credentials.
-
-      The copy of the ticket flags in the encrypted part of the KDC
-      reply may have the OK-AS-DELEGATE flag set to indicates to the
-      client that the server specified in the ticket has been determined
-      by policy of the realm to be a suitable recipient of delegation.
-      A client can use the presence of this flag to help it make a
-      decision whether to delegate credentials (either grant a proxy or
-      a forwarded ticket-granting ticket) to this server.  It is
-      acceptable to ignore the value of this flag. When setting this
-      flag, an administrator should consider the security and placement
-      of the server on which the service will run, as well as whether
-      the service requires the use of delegated credentials.
-
-
-
-February 2004                                                  [Page 22]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-2.9. Other KDC options
-
-      There are three additional options which MAY be set in a client's
-      request of the KDC.
-
-2.9.1. Renewable-OK
-
-      The RENEWABLE-OK option indicates that the client will accept a
-      renewable ticket if a ticket with the requested life cannot
-      otherwise be provided. If a ticket with the requested life cannot
-      be provided, then the KDC MAY issue a renewable ticket with a
-      renew-till equal to the requested endtime. The value of the renew-
-      till field MAY still be adjusted by site-determined limits or
-      limits imposed by the individual principal or server.
-
-2.9.2. ENC-TKT-IN-SKEY
-
-      In its basic form the Kerberos protocol supports authentication in
-      a client-server
-       setting and is not well suited to authentication in a peer-to-
-      peer environment because the long term key of the user does not
-      remain on the workstation after initial login. Authentication of
-      such peers may be supported by Kerberos in its user-to-user
-      variant. The ENC-TKT-IN-SKEY option supports user-to-user
-      authentication by allowing the KDC to issue a service ticket
-      encrypted using the session key from another ticket-granting
-      ticket issued to another user. The ENC-TKT-IN-SKEY option is
-      honored only by the ticket-granting service. It indicates that the
-      ticket to be issued for the end server is to be encrypted in the
-      session key from the additional second ticket-granting ticket
-      provided with the request. See section 3.3.3 for specific details.
-
-2.9.3. Passwordless Hardware Authentication
-
-      The OPT-HARDWARE-AUTH option indicates that the client wishes to
-      use some form of hardware authentication instead of or in addition
-      to the client's password or other long-lived encryption key. OPT-
-      HARDWARE-AUTH is honored only by the authentication service. If
-      supported and allowed by policy, the KDC will return an errorcode
-      KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to
-      perform such authentication.
-
-3. Message Exchanges
-
-      The following sections describe the interactions between network
-      clients and servers and the messages involved in those exchanges.
-
-3.1. The Authentication Service Exchange
-
-
-
-February 2004                                                  [Page 23]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-                                Summary
-
-            Message direction       Message type    Section
-            1. Client to Kerberos   KRB_AS_REQ      5.4.1
-            2. Kerberos to client   KRB_AS_REP or   5.4.2
-                                    KRB_ERROR       5.9.1
-
-      The Authentication Service (AS) Exchange between the client and
-      the Kerberos Authentication Server is initiated by a client when
-      it wishes to obtain authentication credentials for a given server
-      but currently holds no credentials. In its basic form, the
-      client's secret key is used for encryption and decryption. This
-      exchange is typically used at the initiation of a login session to
-      obtain credentials for a Ticket-Granting Server which will
-      subsequently be used to obtain credentials for other servers (see
-      section 3.3) without requiring further use of the client's secret
-      key. This exchange is also used to request credentials for
-      services which must not be mediated through the Ticket-Granting
-      Service, but rather require a principal's secret key, such as the
-      password-changing service[5]. This exchange does not by itself
-      provide any assurance of the identity of the user[6].
-
-      The exchange consists of two messages: KRB_AS_REQ from the client
-      to Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for
-      these messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
-
-      In the request, the client sends (in cleartext) its own identity
-      and the identity of the server for which it is requesting
-      credentials, other information about the credentials it is
-      requesting, and a randomly generated nonce which can be used to
-      detect replays, and to associate replies with the matching
-      requests. This nonce MUST be generated randomly by the client and
-      remembered for checking against the nonce in the expected reply.
-      The response, KRB_AS_REP, contains a ticket for the client to
-      present to the server, and a session key that will be shared by
-      the client and the server.  The session key and additional
-      information are encrypted in the client's secret key. The
-      encrypted part of the KRB_AS_REP message also contains the nonce
-      which MUST be matched with the nonce from the KRB_AS_REQ message.
-
-      Without pre-authentication, the authentication server does not
-      know whether the client is actually the principal named in the
-      request. It simply sends a reply without knowing or caring whether
-      they are the same. This is acceptable because nobody but the
-      principal whose identity was given in the request will be able to
-      use the reply. Its critical information is encrypted in that
-      principal's key. However, an attacker can send a KRB_AS_REQ
-      message to get known plaintext in order to attack the principal's
-
-
-
-February 2004                                                  [Page 24]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      key. Especially if the key is based on a password, this may create
-      a security exposure. So, the initial request supports an optional
-      field that can be used to pass additional information that might
-      be needed for the initial exchange. This field SHOULD be used for
-      pre-authentication as described in sections 3.1.1 and 5.2.7.
-
-      Various errors can occur; these are indicated by an error response
-      (KRB_ERROR) instead of the KRB_AS_REP response. The error message
-      is not encrypted. The KRB_ERROR message contains information which
-      can be used to associate it with the message to which it replies.
-      The contents of the KRB_ERROR message are not integrity-protected.
-      As such, the client cannot detect replays, fabrications or
-      modifications. A solution to this problem will be included in a
-      future version of the protocol.
-
-3.1.1. Generation of KRB_AS_REQ message
-
-      The client may specify a number of options in the initial request.
-      Among these options are whether pre-authentication is to be
-      performed; whether the requested ticket is to be renewable,
-      proxiable, or forwardable; whether it should be postdated or allow
-      postdating of derivative tickets; and whether a renewable ticket
-      will be accepted in lieu of a non-renewable ticket if the
-      requested ticket expiration date cannot be satisfied by a non-
-      renewable ticket (due to configuration constraints).
-
-      The client prepares the KRB_AS_REQ message and sends it to the
-      KDC.
-
-3.1.2. Receipt of KRB_AS_REQ message
-
-      If all goes well, processing the KRB_AS_REQ message will result in
-      the creation of a ticket for the client to present to the server.
-      The format for the ticket is described in section 5.3.
-
-      Because Kerberos can run over unreliable transports such as UDP,
-      the KDC MUST be prepared to retransmit responses in case they are
-      lost. If a KDC receives a request identical to one it has recently
-      successfully processed, the KDC MUST respond with a KRB_AS_REP
-      message rather than a replay error.  In order to reduce ciphertext
-      given to a potential attacker, KDCs MAY send the same response
-      generated when the request was first handled. KDCs MUST obey this
-      replay behavior even if the actual transport in use is reliable.
-
-3.1.3. Generation of KRB_AS_REP message
-
-      The authentication server looks up the client and server
-      principals named in the KRB_AS_REQ in its database, extracting
-
-
-
-February 2004                                                  [Page 25]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      their respective keys. If the requested client principal named in
-      the request is not known because it doesn't exist in the KDC's
-      principal database, then an error message with a
-      KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
-
-      If required, the server pre-authenticates the request, and if the
-      pre-authentication check fails, an error message with the code
-      KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is
-      required, but was not present in the request, an error message
-      with the code KDC_ERR_PREAUTH_REQUIRED is returned and a METHOD-
-      DATA object will be stored in the e-data field of the KRB-ERROR
-      message to specify which pre-authentication mechanisms are
-      acceptable.  Usually this will include PA-ETYPE-INFO and/or PA-
-      ETYPE-INFO2 elements as described below. If the server cannot
-      accommodate any encryption type requested by the client, an error
-      message with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the
-      KDC generates a 'random' session key[7].
-
-      When responding to an AS request, if there are multiple encryption
-      keys registered for a client in the Kerberos database, then the
-      etype field from the AS request is used by the KDC to select the
-      encryption method to be used to protect the encrypted part of the
-      KRB_AS_REP message which is sent to the client. If there is more
-      than one supported strong encryption type in the etype list, the
-      KDC SHOULD use the first valid strong etype for which an
-      encryption key is available.
-
-      When the user's key is generated from a password or pass phrase,
-      the string-to-key function for the particular encryption key type
-      is used, as specified in [@KCRYPTO]. The salt value and additional
-      parameters for the string-to-key function have default values
-      (specified by section 4 and by the encryption mechanism
-      specification, respectively) that may be overridden by pre-
-      authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-
-      ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of
-      the resulting key only, these values should not be changed for
-      password-based keys except when changing the principal's key.
-
-      When the AS server is to include pre-authentication data in a KRB-
-      ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-
-      INFO, if the etype field of the client's AS-REQ lists at least one
-      "newer" encryption type.  Otherwise (when the etype field of the
-      client's AS-REQ does not list any "newer" encryption types) it
-      MUST send both, PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an
-      entry for each enctype).  A "newer" enctype is any enctype first
-      officially specified concurrently with or subsequent to the issue
-      of this RFC.  The enctypes DES, 3DES or RC4 and any defined in
-      [RFC1510] are not "newer" enctypes.
-
-
-
-February 2004                                                  [Page 26]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      It is not possible to reliably generate a user's key given a pass
-      phrase without contacting the KDC, since it will not be known
-      whether alternate salt or parameter values are required.
-
-      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.
-
-      If the requested start time is absent, indicates a time in the
-      past, or is within the window of acceptable clock skew for the KDC
-      and the POSTDATE option has not been specified, then the start
-      time of the ticket is set to the authentication server's current
-      time. If it indicates a time in the future beyond the acceptable
-      clock skew, but the POSTDATED option has not been specified then
-      the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the
-      requested start time is checked against the policy of the local
-      realm (the administrator might decide to prohibit certain types or
-      ranges of postdated tickets), and if acceptable, the ticket's
-      start time is set as requested and the INVALID flag is set in the
-      new ticket. The postdated ticket MUST be validated before use by
-      presenting it to the KDC after the start time has been reached.
-
-      The expiration time of the ticket will be set to the earlier of
-      the requested endtime and a time determined by local policy,
-      possibly determined using realm or principal specific factors. For
-      example, the expiration time MAY be set to the earliest of the
-      following:
-
-      *  The expiration time (endtime) requested in the KRB_AS_REQ
-         message.
-
-      *  The ticket's start time plus the maximum allowable lifetime
-         associated with the client principal from the authentication
-         server's database.
-
-      *  The ticket's start time plus the maximum allowable lifetime
-         associated with the server principal.
-
-      *  The ticket's start time plus the maximum lifetime set by the
-         policy of the local realm.
-
-   If the requested expiration time minus the start time (as determined
-   above) is less than a site-determined minimum lifetime, an error
-   message with code KDC_ERR_NEVER_VALID is returned. If the requested
-   expiration time for the ticket exceeds what was determined as above,
-
-
-
-February 2004                                                  [Page 27]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-   and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE'
-   flag is set in the new ticket, and the renew-till value is set as if
-   the 'RENEWABLE' option were requested (the field and option names are
-   described fully in section 5.4.1).
-
-   If the RENEWABLE option has been requested or if the RENEWABLE-OK
-   option has been set and a renewable ticket is to be issued, then the
-   renew-till field MAY be set to the earliest of:
-
-      *  Its requested value.
-
-      *  The start time of the ticket plus the minimum of the two
-         maximum renewable lifetimes associated with the principals'
-         database entries.
-
-      *  The start time of the ticket plus the maximum renewable
-         lifetime set by the policy of the local realm.
-
-   The flags field of the new ticket will have the following options set
-   if they have been requested and if the policy of the local realm
-   allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
-   If the new ticket is postdated (the start time is in the future), its
-   INVALID flag will also be set.
-
-   If all of the above succeed, the server will encrypt the ciphertext
-   part of the ticket using the encryption key extracted from the server
-   principal's record in the Kerberos database using the encryption type
-   associated with the server principal's key (this choice is NOT
-   affected by the etype field in the request). It then formats a
-   KRB_AS_REP message (see section 5.4.2), copying the addresses in the
-   request into the caddr of the response, placing any required pre-
-   authentication data into the padata of the response, and encrypts the
-   ciphertext part in the client's key using an acceptable encryption
-   method requested in the etype field of the request, or in some key
-   specified by pre-authentication mechanisms being used.
-
-3.1.4. Generation of KRB_ERROR message
-
-      Several errors can occur, and the Authentication Server responds
-      by returning an error message, KRB_ERROR, to the client, with the
-      error-code and e-text fields set to appropriate values. The error
-      message contents and details are described in Section 5.9.1.
-
-3.1.5. Receipt of KRB_AS_REP message
-
-      If the reply message type is KRB_AS_REP, then the client verifies
-      that the cname and crealm fields in the cleartext portion of the
-      reply match what it requested. If any padata fields are present,
-
-
-
-February 2004                                                  [Page 28]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      they may be used to derive the proper secret key to decrypt the
-      message. The client decrypts the encrypted part of the response
-      using its secret key, verifies that the nonce in the encrypted
-      part matches the nonce it supplied in its request (to detect
-      replays). It also verifies that the sname and srealm in the
-      response match those in the request (or are otherwise expected
-      values), and that the host address field is also correct. It then
-      stores the ticket, session key, start and expiration times, and
-      other information for later use. The last-req field (and the
-      deprecated key-expiration field) from the encrypted part of the
-      response MAY be checked to notify the user of impending key
-      expiration. This enables the client program to suggest remedial
-      action, such as a password change.
-
-      Upon validation of the KRB_AS_REP message (by checking the
-      returned nonce against that sent in the KRB_AS_REQ message) the
-      client knows that the current time on the KDC is that read from
-      the authtime field of the encrypted part of the reply. The client
-      can optionally use this value for clock synchronization in
-      subsequent messages by recording with the ticket the difference
-      (offset) between the authtime value and the local clock. This
-      offset can then be used by the same user to adjust the time read
-      from the system clock when generating messages [DGT96].
-
-      This technique MUST be used when adjusting for clock skew instead
-      of directly changing the system clock because the KDC reply is
-      only authenticated to the user whose secret key was used, but not
-      to the system or workstation. If the clock were adjusted, an
-      attacker colluding with a user logging into a workstation could
-      agree on a password, resulting in a KDC reply that would be
-      correctly validated even though it did not originate from a KDC
-      trusted by the workstation.
-
-      Proper decryption of the KRB_AS_REP message is not sufficient for
-      the host to verify the identity of the user; the user and an
-      attacker could cooperate to generate a KRB_AS_REP format message
-      which decrypts properly but is not from the proper KDC. If the
-      host wishes to verify the identity of the user, it MUST require
-      the user to present application credentials which can be verified
-      using a securely-stored secret key for the host. If those
-      credentials can be verified, then the identity of the user can be
-      assured.
-
-3.1.6. Receipt of KRB_ERROR message
-
-      If the reply message type is KRB_ERROR, then the client interprets
-      it as an error and performs whatever application-specific tasks
-      are necessary to recover.
-
-
-
-February 2004                                                  [Page 29]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-3.2. The Client/Server Authentication Exchange
-
-                                   Summary
-      Message direction                         Message type    Section
-      Client to Application server              KRB_AP_REQ      5.5.1
-      [optional] Application server to client   KRB_AP_REP or   5.5.2
-                                                KRB_ERROR       5.9.1
-
-      The client/server authentication (CS) exchange is used by network
-      applications to authenticate the client to the server and vice
-      versa. The client MUST have already acquired credentials for the
-      server using the AS or TGS exchange.
-
-3.2.1. The KRB_AP_REQ message
-
-      The KRB_AP_REQ contains authentication information which SHOULD be
-      part of the first message in an authenticated transaction. It
-      contains a ticket, an authenticator, and some additional
-      bookkeeping information (see section 5.5.1 for the exact format).
-      The ticket by itself is insufficient to authenticate a client,
-      since tickets are passed across the network in cleartext[8], so
-      the authenticator is used to prevent invalid replay of tickets by
-      proving to the server that the client knows the session key of the
-      ticket and thus is entitled to use the ticket. The KRB_AP_REQ
-      message is referred to elsewhere as the 'authentication header.'
-
-3.2.2. Generation of a KRB_AP_REQ message
-
-      When a client wishes to initiate authentication to a server, it
-      obtains (either through a credentials cache, the AS exchange, or
-      the TGS exchange) a ticket and session key for the desired
-      service. The client MAY re-use any tickets it holds until they
-      expire. To use a ticket the client constructs a new Authenticator
-      from the system time, its name, and optionally an application
-      specific checksum, an initial sequence number to be used in
-      KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used
-      in negotiations for a session key unique to this particular
-      session.  Authenticators MAY NOT be re-used and SHOULD be rejected
-      if replayed to a server[9]. If a sequence number is to be
-      included, it SHOULD be randomly chosen so that even after many
-      messages have been exchanged it is not likely to collide with
-      other sequence numbers in use.
-
-      The client MAY indicate a requirement of mutual authentication or
-      the use of a session-key based ticket (for user-to-user
-      authentication - see section 3.7) by setting the appropriate
-      flag(s) in the ap-options field of the message.
-
-
-
-
-February 2004                                                  [Page 30]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      The Authenticator is encrypted in the session key and combined
-      with the ticket to form the KRB_AP_REQ message which is then sent
-      to the end server along with any additional application-specific
-      information.
-
-3.2.3. Receipt of KRB_AP_REQ message
-
-      Authentication is based on the server's current time of day
-      (clocks MUST be loosely synchronized), the authenticator, and the
-      ticket. Several errors are possible. If an error occurs, the
-      server is expected to reply to the client with a KRB_ERROR
-      message. This message MAY be encapsulated in the application
-      protocol if its raw form is not acceptable to the protocol.  The
-      format of error messages is described in section 5.9.1.
-
-      The algorithm for verifying authentication information is as
-      follows. If the message type is not KRB_AP_REQ, the server returns
-      the KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the
-      Ticket in the KRB_AP_REQ is not one the server can use (e.g., it
-      indicates an old key, and the server no longer possesses a copy of
-      the old key), the KRB_AP_ERR_BADKEYVER error is returned. If the
-      USE-SESSION-KEY flag is set in the ap-options field, it indicates
-      to the server that user-to-user authentication is in use, and that
-      the ticket is encrypted in the session key from the server's
-      ticket-granting ticket rather than in the server's secret key. See
-      section 3.7 for a more complete description of the effect of user-
-      to-user authentication on all messages in the Kerberos protocol.
-
-      Since it is possible for the server to be registered in multiple
-      realms, with different keys in each, the srealm field in the
-      unencrypted portion of the ticket in the KRB_AP_REQ is used to
-      specify which secret key the server should use to decrypt that
-      ticket. The KRB_AP_ERR_NOKEY error code is returned if the server
-      doesn't have the proper key to decipher the ticket.
-
-      The ticket is decrypted using the version of the server's key
-      specified by the ticket. If the decryption routines detect a
-      modification of the ticket (each encryption system MUST provide
-      safeguards to detect modified ciphertext), the
-      KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that
-      different keys were used to encrypt and decrypt).
-
-      The authenticator is decrypted using the session key extracted
-      from the decrypted ticket. If decryption shows it to have been
-      modified, the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name
-      and realm of the client from the ticket are compared against the
-      same fields in the authenticator.  If they don't match, the
-      KRB_AP_ERR_BADMATCH error is returned; this normally is caused by
-
-
-
-February 2004                                                  [Page 31]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      a client error or attempted attack. The addresses in the ticket
-      (if any) are then searched for an address matching the operating-
-      system reported address of the client. If no match is found or the
-      server insists on ticket addresses but none are present in the
-      ticket, the KRB_AP_ERR_BADADDR error is returned. If the local
-      (server) time and the client time in the authenticator differ by
-      more than the allowable clock skew (e.g., 5 minutes), the
-      KRB_AP_ERR_SKEW error is returned.
-
-      Unless the application server provides its own suitable means to
-      protect against replay (for example, a challenge-response sequence
-      initiated by the server after authentication, or use of a server-
-      generated encryption subkey), the server MUST utilize a replay
-      cache to remember any authenticator presented within the allowable
-      clock skew. Careful analysis of the application protocol and
-      implementation is recommended before eliminating this cache. The
-      replay cache will store at least the server name, along with the
-      client name, time and microsecond fields from the recently-seen
-      authenticators and if a matching tuple is found, the
-      KRB_AP_ERR_REPEAT error is returned [10]. If a server loses track
-      of authenticators presented within the allowable clock skew, it
-      MUST reject all requests until the clock skew interval has passed,
-      providing assurance that any lost or replayed authenticators will
-      fall outside the allowable clock skew and can no longer be
-      successfully replayed [11].
-
-      Implementation note: If a client generates multiple requests to
-      the KDC with the same timestamp, including the microsecond field,
-      all but the first of the requests received will be rejected as
-      replays. This might happen, for example, if the resolution of the
-      client's clock is too coarse.  Client implementations SHOULD
-      ensure that the timestamps are not reused, possibly by
-      incrementing the microseconds field in the time stamp when the
-      clock returns the same time for multiple requests.
-
-      If multiple servers (for example, different services on one
-      machine, or a single service implemented on multiple machines)
-      share a service principal (a practice we do not recommend in
-      general, but acknowledge will be used in some cases), they MUST
-      either share this replay cache, or the application protocol MUST
-      be designed so as to eliminate the need for it. Note that this
-      applies to all of the services, if any of the application
-      protocols does not have replay protection built in; an
-      authenticator used with such a service could later be replayed to
-      a different service with the same service principal but no replay
-      protection, if the former doesn't record the authenticator
-      information in the common replay cache.
-
-
-
-
-February 2004                                                  [Page 32]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      If a sequence number is provided in the authenticator, the server
-      saves it for later use in processing KRB_SAFE and/or KRB_PRIV
-      messages. If a subkey is present, the server either saves it for
-      later use or uses it to help generate its own choice for a subkey
-      to be returned in a KRB_AP_REP message.
-
-      The server computes the age of the ticket: local (server) time
-      minus the start time inside the Ticket. If the start time is later
-      than the current time by more than the allowable clock skew or if
-      the INVALID flag is set in the ticket, the KRB_AP_ERR_TKT_NYV
-      error is returned. Otherwise, if the current time is later than
-      end time by more than the allowable clock skew, the
-      KRB_AP_ERR_TKT_EXPIRED error is returned.
-
-      If all these checks succeed without an error, the server is
-      assured that the client possesses the credentials of the principal
-      named in the ticket and thus, the client has been authenticated to
-      the server.
-
-      Passing these checks provides only authentication of the named
-      principal; it does not imply authorization to use the named
-      service. Applications MUST make a separate authorization decision
-      based upon the authenticated name of the user, the requested
-      operation, local access control information such as that contained
-      in a .k5login or .k5users file, and possibly a separate
-      distributed authorization service.
-
-3.2.4. Generation of a KRB_AP_REP message
-
-      Typically, a client's request will include both the authentication
-      information and its initial request in the same message, and the
-      server need not explicitly reply to the KRB_AP_REQ. However, if
-      mutual authentication (not only authenticating the client to the
-      server, but also the server to the client) is being performed, the
-      KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options
-      field, and a KRB_AP_REP message is required in response. As with
-      the error message, this message MAY be encapsulated in the
-      application protocol if its "raw" form is not acceptable to the
-      application's protocol. The timestamp and microsecond field used
-      in the reply MUST be the client's timestamp and microsecond field
-      (as provided in the authenticator) [12]. If a sequence number is
-      to be included, it SHOULD be randomly chosen as described above
-      for the authenticator. A subkey MAY be included if the server
-      desires to negotiate a different subkey. The KRB_AP_REP message is
-      encrypted in the session key extracted from the ticket.
-
-3.2.5. Receipt of KRB_AP_REP message
-
-
-
-
-February 2004                                                  [Page 33]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      If a KRB_AP_REP message is returned, the client uses the session
-      key from the credentials obtained for the server [13] to decrypt
-      the message, and verifies that the timestamp and microsecond
-      fields match those in the Authenticator it sent to the server. If
-      they match, then the client is assured that the server is genuine.
-      The sequence number and subkey (if present) are retained for later
-      use.
-
-3.2.6. Using the encryption key
-
-      After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client
-      and server share an encryption key which can be used by the
-      application. In some cases, the use of this session key will be
-      implicit in the protocol; in others the method of use must be
-      chosen from several alternatives. The actual encryption key to be
-      used for KRB_PRIV, KRB_SAFE, or other application-specific uses
-      MAY be chosen by the application based on the session key from the
-      ticket and subkeys in the KRB_AP_REP message and the authenticator
-      [14]. To mitigate the effect of failures in random number
-      generation on the client it is strongly encouraged that any key
-      derived by an application for subsequent use include the full key
-      entropy derived from the KDC generated session key carried in the
-      ticket. We leave the protocol negotiations of how to use the key
-      (e.g. selecting an encryption or checksum type) to the application
-      programmer; the Kerberos protocol does not constrain the
-      implementation options, but an example of how this might be done
-      follows.
-
-      One way that an application may choose to negotiate a key to be
-      used for subsequent integrity and privacy protection is for the
-      client to propose a key in the subkey field of the authenticator.
-      The server can then choose a key using the proposed key from the
-      client as input, returning the new subkey in the subkey field of
-      the application reply. This key could then be used for subsequent
-      communication.
-
-      With both the one-way and mutual authentication exchanges, the
-      peers should take care not to send sensitive information to each
-      other without proper assurances. In particular, applications that
-      require privacy or integrity SHOULD use the KRB_AP_REP response
-      from the server to client to assure both client and server of
-      their peer's identity. If an application protocol requires privacy
-      of its messages, it can use the KRB_PRIV message (section 3.5).
-      The KRB_SAFE message (section 3.4) can be used to assure
-      integrity.
-
-3.3. The Ticket-Granting Service (TGS) Exchange
-
-
-
-
-February 2004                                                  [Page 34]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-                                Summary
-            Message direction       Message type     Section
-            1. Client to Kerberos   KRB_TGS_REQ      5.4.1
-            2. Kerberos to client   KRB_TGS_REP or   5.4.2
-                                    KRB_ERROR        5.9.1
-
-      The TGS exchange between a client and the Kerberos Ticket-Granting
-      Server is initiated by a client when it wishes to obtain
-      authentication credentials for a given server (which might be
-      registered in a remote realm), when it wishes to renew or validate
-      an existing ticket, or when it wishes to obtain a proxy ticket. In
-      the first case, the client must already have acquired a ticket for
-      the Ticket-Granting Service using the AS exchange (the ticket-
-      granting ticket is usually obtained when a client initially
-      authenticates to the system, such as when a user logs in). The
-      message format for the TGS exchange is almost identical to that
-      for the AS exchange.  The primary difference is that encryption
-      and decryption in the TGS exchange does not take place under the
-      client's key. Instead, the session key from the ticket-granting
-      ticket or renewable ticket, or sub-session key from an
-      Authenticator is used. As is the case for all application servers,
-      expired tickets are not accepted by the TGS, so once a renewable
-      or ticket-granting ticket expires, the client must use a separate
-      exchange to obtain valid tickets.
-
-      The TGS exchange consists of two messages: A request (KRB_TGS_REQ)
-      from the client to the Kerberos Ticket-Granting Server, and a
-      reply (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes
-      information authenticating the client plus a request for
-      credentials. The authentication information consists of the
-      authentication header (KRB_AP_REQ) which includes the client's
-      previously obtained ticket-granting, renewable, or invalid ticket.
-      In the ticket-granting ticket and proxy cases, the request MAY
-      include one or more of: a list of network addresses, a collection
-      of typed authorization data to be sealed in the ticket for
-      authorization use by the application server, or additional tickets
-      (the use of which are described later). The TGS reply
-      (KRB_TGS_REP) contains the requested credentials, encrypted in the
-      session key from the ticket-granting ticket or renewable ticket,
-      or if present, in the sub-session key from the Authenticator (part
-      of the authentication header). The KRB_ERROR message contains an
-      error code and text explaining what went wrong. The KRB_ERROR
-      message is not encrypted. The KRB_TGS_REP message contains
-      information which can be used to detect replays, and to associate
-      it with the message to which it replies. The KRB_ERROR message
-      also contains information which can be used to associate it with
-      the message to which it replies. The same comments about integrity
-      protection of KRB_ERROR messages mentioned in section 3.1 apply to
-
-
-
-February 2004                                                  [Page 35]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      the TGS exchange.
-
-3.3.1. Generation of KRB_TGS_REQ message
-
-      Before sending a request to the ticket-granting service, the
-      client MUST determine in which realm the application server is
-      believed to be registered [15]. If the client knows the service
-      principal name and realm and it does not already possess a ticket-
-      granting ticket for the appropriate realm, then one must be
-      obtained. This is first attempted by requesting a ticket-granting
-      ticket for the destination realm from a Kerberos server for which
-      the client possesses a ticket-granting ticket (using the
-      KRB_TGS_REQ message recursively). The Kerberos server MAY return a
-      TGT for the desired realm in which case one can proceed.
-      Alternatively, the Kerberos server MAY return a TGT for a realm
-      which is 'closer' to the desired realm (further along the standard
-      hierarchical path between the client's realm and the requested
-      realm server's realm). It should be noted in this case that
-      misconfiguration of the Kerberos servers may cause loops in the
-      resulting authentication path, which the client should be careful
-      to detect and avoid.
-
-      If the Kerberos server returns a TGT for a 'closer' realm other
-      than the desired realm, the client MAY use local policy
-      configuration to verify that the authentication path used is an
-      acceptable one.  Alternatively, a client MAY choose its own
-      authentication path, rather than relying on the Kerberos server to
-      select one. In either case, any policy or configuration
-      information used to choose or validate authentication paths,
-      whether by the Kerberos server or client, MUST be obtained from a
-      trusted source.
-
-      When a client obtains a ticket-granting ticket that is 'closer' to
-      the destination realm, the client MAY cache this ticket and reuse
-      it in future KRB-TGS exchanges with services in the 'closer'
-      realm. However, if the client were to obtain a ticket-granting
-      ticket for the 'closer' realm by starting at the initial KDC
-      rather than as part of obtaining another ticket, then a shorter
-      path to the 'closer' realm might be used. This shorter path may be
-      desirable because fewer intermediate KDCs would know the session
-      key of the ticket involved. For this reason, clients SHOULD
-      evaluate whether they trust the realms transited in obtaining the
-      'closer' ticket when making a decision to use the ticket in
-      future.
-
-      Once the client obtains a ticket-granting ticket for the
-      appropriate realm, it determines which Kerberos servers serve that
-      realm, and contacts one. The list might be obtained through a
-
-
-
-February 2004                                                  [Page 36]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      configuration file or network service or it MAY be generated from
-      the name of the realm; as long as the secret keys exchanged by
-      realms are kept secret, only denial of service results from using
-      a false Kerberos server.
-
-       As in the AS exchange, the client MAY specify a number of options
-      in the KRB_TGS_REQ message. One of these options is the ENC-TKT-
-      IN-SKEY option used for user-to-user authentication. An overview
-      of user-to-user authentication can be found in section 3.7. When
-      generating the KRB_TGS_REQ message, this option indicates that the
-      client is including a ticket-granting ticket obtained from the
-      application server in the additional tickets field of the request
-      and that the KDC SHOULD encrypt the ticket for the application
-      server using the session key from this additional ticket, instead
-      of using a server key from the principal database.
-
-      The client prepares the KRB_TGS_REQ message, providing an
-      authentication header as an element of the padata field, and
-      including the same fields as used in the KRB_AS_REQ message along
-      with several optional fields: the enc-authorizatfion-data field
-      for application server use and additional tickets required by some
-      options.
-
-      In preparing the authentication header, the client can select a
-      sub-session key under which the response from the Kerberos server
-      will be encrypted [16]. If the sub-session key is not specified,
-      the session key from the ticket-granting ticket will be used. If
-      the enc-authorization-data is present, it MUST be encrypted in the
-      sub-session key, if present, from the authenticator portion of the
-      authentication header, or if not present, using the session key
-      from the ticket-granting ticket.
-
-      Once prepared, the message is sent to a Kerberos server for the
-      destination realm.
-
-3.3.2. Receipt of KRB_TGS_REQ message
-
-      The KRB_TGS_REQ message is processed in a manner similar to the
-      KRB_AS_REQ message, but there are many additional checks to be
-      performed. First, the Kerberos server MUST determine which server
-      the accompanying ticket is for and it MUST select the appropriate
-      key to decrypt it. For a normal KRB_TGS_REQ message, it will be
-      for the ticket granting service, and the TGS's key will be used.
-      If the TGT was issued by another realm, then the appropriate
-      inter-realm key MUST be used. If the accompanying ticket is not a
-      ticket-granting ticket for the current realm, but is for an
-      application server in the current realm, the RENEW, VALIDATE, or
-      PROXY options are specified in the request, and the server for
-
-
-
-February 2004                                                  [Page 37]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      which a ticket is requested is the server named in the
-      accompanying ticket, then the KDC will decrypt the ticket in the
-      authentication header using the key of the server for which it was
-      issued. If no ticket can be found in the padata field, the
-      KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
-
-      Once the accompanying ticket has been decrypted, the user-supplied
-      checksum in the Authenticator MUST be verified against the
-      contents of the request, and the message rejected if the checksums
-      do not match (with an error code of KRB_AP_ERR_MODIFIED) or if the
-      checksum is not collision-proof (with an error code of
-      KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported,
-      the KDC_ERR_SUMTYPE_NOSUPP error is returned. If the
-      authorization-data are present, they are decrypted using the sub-
-      session key from the Authenticator.
-
-      If any of the decryptions indicate failed integrity checks, the
-      KRB_AP_ERR_BAD_INTEGRITY error is returned.
-
-      As discussed in section 3.1.2, the KDC MUST send a valid
-      KRB_TGS_REP message if it receives a KRB_TGS_REQ message identical
-      to one it has recently processed. However, if the authenticator is
-      a replay, but the rest of the request is not identical, then the
-      KDC SHOULD return KRB_AP_ERR_REPEAT.
-
-3.3.3. Generation of KRB_TGS_REP message
-
-      The KRB_TGS_REP message shares its format with the KRB_AS_REP
-      (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The
-      detailed specification is in section 5.4.2.
-
-      The response will include a ticket for the requested server or for
-      a ticket granting server of an intermediate KDC to be contacted to
-      obtain the requested ticket. The Kerberos database is queried to
-      retrieve the record for the appropriate server (including the key
-      with which the ticket will be encrypted). If the request is for a
-      ticket-granting ticket for a remote realm, and if no key is shared
-      with the requested realm, then the Kerberos server will select the
-      realm 'closest' to the requested realm with which it does share a
-      key, and use that realm instead.  This is the only case where the
-      response for the KDC will be for a different server than that
-      requested by the client.
-
-      By default, the address field, the client's name and realm, the
-      list of transited realms, the time of initial authentication, the
-      expiration time, and the authorization data of the newly-issued
-      ticket will be copied from the ticket-granting ticket (TGT) or
-      renewable ticket. If the transited field needs to be updated, but
-
-
-
-February 2004                                                  [Page 38]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      the transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP
-      error is returned.
-
-      If the request specifies an endtime, then the endtime of the new
-      ticket is set to the minimum of (a) that request, (b) the endtime
-      from the TGT, and (c) the starttime of the TGT plus the minimum of
-      the maximum life for the application server and the maximum life
-      for the local realm (the maximum life for the requesting principal
-      was already applied when the TGT was issued). If the new ticket is
-      to be a renewal, then the endtime above is replaced by the minimum
-      of (a) the value of the renew_till field of the ticket and (b) the
-      starttime for the new ticket plus the life (endtime-starttime) of
-      the old ticket.
-
-      If the FORWARDED option has been requested, then the resulting
-      ticket will contain the addresses specified by the client. This
-      option will only be honored if the FORWARDABLE flag is set in the
-      TGT. The PROXY option is similar; the resulting ticket will
-      contain the addresses specified by the client. It will be honored
-      only if the PROXIABLE flag in the TGT is set. The PROXY option
-      will not be honored on requests for additional ticket-granting
-      tickets.
-
-      If the requested start time is absent, indicates a time in the
-      past, or is within the window of acceptable clock skew for the KDC
-      and the POSTDATE option has not been specified, then the start
-      time of the ticket is set to the authentication server's current
-      time. If it indicates a time in the future beyond the acceptable
-      clock skew, but the POSTDATED option has not been specified or the
-      MAY-POSTDATE flag is not set in the TGT, then the error
-      KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the ticket-
-      granting ticket has the MAY-POSTDATE flag set, then the resulting
-      ticket will be postdated and the requested starttime is checked
-      against the policy of the local realm. If acceptable, the ticket's
-      start time is set as requested, and the INVALID flag is set. The
-      postdated ticket MUST be validated before use by presenting it to
-      the KDC after the starttime has been reached. However, in no case
-      may the starttime, endtime, or renew-till time of a newly-issued
-      postdated ticket extend beyond the renew-till time of the ticket-
-      granting ticket.
-
-      If the ENC-TKT-IN-SKEY option has been specified and an additional
-      ticket has been included in the request, it indicates that the
-      client is using user- to-user authentication to prove its identity
-      to a server that does not have access to a persistent key. Section
-      3.7 describes the affect of this option on the entire Kerberos
-      protocol. When generating the KRB_TGS_REP message, this option in
-      the KRB_TGS_REQ message tells the KDC to decrypt the additional
-
-
-
-February 2004                                                  [Page 39]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      ticket using the key for the server to which the additional ticket
-      was issued and verify that it is a ticket-granting ticket. If the
-      name of the requested server is missing from the request, the name
-      of the client in the additional ticket will be used. Otherwise the
-      name of the requested server will be compared to the name of the
-      client in the additional ticket and if different, the request will
-      be rejected. If the request succeeds, the session key from the
-      additional ticket will be used to encrypt the new ticket that is
-      issued instead of using the key of the server for which the new
-      ticket will be used.
-
-      If the name of the server in the ticket that is presented to the
-      KDC as part of the authentication header is not that of the
-      ticket-granting server itself, the server is registered in the
-      realm of the KDC, and the RENEW option is requested, then the KDC
-      will verify that the RENEWABLE flag is set in the ticket, that the
-      INVALID flag is not set in the ticket, and that the renew_till
-      time is still in the future. If the VALIDATE option is requested,
-      the KDC will check that the starttime has passed and the INVALID
-      flag is set. If the PROXY option is requested, then the KDC will
-      check that the PROXIABLE flag is set in the ticket. If the tests
-      succeed, and the ticket passes the hotlist check described in the
-      next section, the KDC will issue the appropriate new ticket.
-
-      The ciphertext part of the response in the KRB_TGS_REP message is
-      encrypted in the sub-session key from the Authenticator, if
-      present, or the session key from the ticket-granting ticket. It is
-      not encrypted using the client's secret key. Furthermore, the
-      client's key's expiration date and the key version number fields
-      are left out since these values are stored along with the client's
-      database record, and that record is not needed to satisfy a
-      request based on a ticket-granting ticket.
-
-3.3.3.1. Checking for revoked tickets
-
-      Whenever a request is made to the ticket-granting server, the
-      presented ticket(s) is(are) checked against a hot-list of tickets
-      which have been canceled. This hot-list might be implemented by
-      storing a range of issue timestamps for 'suspect tickets'; if a
-      presented ticket had an authtime in that range, it would be
-      rejected. In this way, a stolen ticket-granting ticket or
-      renewable ticket cannot be used to gain additional tickets
-      (renewals or otherwise) once the theft has been reported to the
-      KDC for the realm in which the server resides. Any normal ticket
-      obtained before it was reported stolen will still be valid
-      (because they require no interaction with the KDC), but only until
-      their normal expiration time. If TGT's have been issued for cross-
-      realm authentication, use of the cross-realm TGT will not be
-
-
-
-February 2004                                                  [Page 40]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      affected unless the hot-list is propagated to the KDCs for the
-      realms for which such cross-realm tickets were issued.
-
-3.3.3.2. Encoding the transited field
-
-      If the identity of the server in the TGT that is presented to the
-      KDC as part of the authentication header is that of the ticket-
-      granting service, but the TGT was issued from another realm, the
-      KDC will look up the inter-realm key shared with that realm and
-      use that key to decrypt the ticket. If the ticket is valid, then
-      the KDC will honor the request, subject to the constraints
-      outlined above in the section describing the AS exchange.  The
-      realm part of the client's identity will be taken from the ticket-
-      granting ticket. The name of the realm that issued the ticket-
-      granting ticket, if it is not the realm of the client principal,
-      will be added to the transited field of the ticket to be issued.
-      This is accomplished by reading the transited field from the
-      ticket-granting ticket (which is treated as an unordered set of
-      realm names), adding the new realm to the set, then constructing
-      and writing out its encoded (shorthand) form (this may involve a
-      rearrangement of the existing encoding).
-
-      Note that the ticket-granting service does not add the name of its
-      own realm. Instead, its responsibility is to add the name of the
-      previous realm.  This prevents a malicious Kerberos server from
-      intentionally leaving out its own name (it could, however, omit
-      other realms' names).
-
-      The names of neither the local realm nor the principal's realm are
-      to be included in the transited field. They appear elsewhere in
-      the ticket and both are known to have taken part in authenticating
-      the principal. Since the endpoints are not included, both local
-      and single-hop inter-realm authentication result in a transited
-      field that is empty.
-
-      Because the name of each realm transited is added to this field,
-      it might potentially be very long. To decrease the length of this
-      field, its contents are encoded. The initially supported encoding
-      is optimized for the normal case of inter-realm communication: a
-      hierarchical arrangement of realms using either domain or X.500
-      style realm names. This encoding (called DOMAIN-X500-COMPRESS) is
-      now described.
-
-      Realm names in the transited field are separated by a ",". The
-      ",", "\", trailing "."s, and leading spaces (" ") are special
-      characters, and if they are part of a realm name, they MUST be
-      quoted in the transited field by preceding them with a "\".
-
-
-
-
-February 2004                                                  [Page 41]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      A realm name ending with a "." is interpreted as being prepended
-      to the previous realm. For example, we can encode traversal of
-      EDU, MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and
-      CS.WASHINGTON.EDU as:
-
-         "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
-
-      Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points,
-      that they would not be included in this field, and we would have:
-
-         "EDU,MIT.,WASHINGTON.EDU"
-
-      A realm name beginning with a "/" is interpreted as being appended
-      to the previous realm.  For the purpose of appending, the realm
-      preceding the first listed realm is considered to be the null
-      realm ("").  If a realm name beginning with a "/" is to stand by
-      itself, then it SHOULD be preceded by a space (" "). For example,
-      we can encode traversal of /COM/HP/APOLLO, /COM/HP, /COM, and
-      /COM/DEC as:
-
-         "/COM,/HP,/APOLLO, /COM/DEC".
-
-      Like the example above, if /COM/HP/APOLLO and /COM/DEC are
-      endpoints, they would not be included in this field, and we would
-      have:
-
-         "/COM,/HP"
-
-      A null subfield preceding or following a "," indicates that all
-      realms between the previous realm and the next realm have been
-      traversed.  For the purpose of interpreting null subfields, the
-      client's realm is considered to precede those in the transited
-      field, and the server's realm is considered to follow them.  Thus,
-      "," means that all realms along the path between the client and
-      the server have been traversed. ",EDU, /COM," means that all
-      realms from the client's realm up to EDU (in a domain style
-      hierarchy) have been traversed, and that everything from /COM down
-      to the server's realm in an X.500 style has also been traversed.
-      This could occur if the EDU realm in one hierarchy shares an
-      inter-realm key directly with the /COM realm in another hierarchy.
-
-3.3.4. Receipt of KRB_TGS_REP message
-
-      When the KRB_TGS_REP is received by the client, it is processed in
-      the same manner as the KRB_AS_REP processing described above. The
-      primary difference is that the ciphertext part of the response
-      must be decrypted using the sub-session key from the
-      Authenticator, if it was specified in the request, or the session
-
-
-
-February 2004                                                  [Page 42]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      key from the ticket-granting ticket, rather than the client's
-      secret key. The server name returned in the reply is the true
-      principal name of the service.
-
-3.4. The KRB_SAFE Exchange
-
-      The KRB_SAFE message MAY be used by clients requiring the ability
-      to detect modifications of messages they exchange. It achieves
-      this by including a keyed collision-proof checksum of the user
-      data and some control information. The checksum is keyed with an
-      encryption key (usually the last key negotiated via subkeys, or
-      the session key if no negotiation has occurred).
-
-3.4.1. Generation of a KRB_SAFE message
-
-      When an application wishes to send a KRB_SAFE message, it collects
-      its data and the appropriate control information and computes a
-      checksum over them.  The checksum algorithm should be the keyed
-      checksum mandated to be implemented along with the crypto system
-      used for the sub-session or session key. The checksum is generated
-      using the sub-session key if present or the session key. Some
-      implementations use a different checksum algorithm for the
-      KRB_SAFE messages but doing so in a interoperable manner is not
-      always possible.
-
-      The control information for the KRB_SAFE message includes both a
-      timestamp and a sequence number. The designer of an application
-      using the KRB_SAFE message MUST choose at least one of the two
-      mechanisms. This choice SHOULD be based on the needs of the
-      application protocol.
-
-      Sequence numbers are useful when all messages sent will be
-      received by one's peer. Connection state is presently required to
-      maintain the session key, so maintaining the next sequence number
-      should not present an additional problem.
-
-      If the application protocol is expected to tolerate lost messages
-      without them being resent, the use of the timestamp is the
-      appropriate replay detection mechanism. Using timestamps is also
-      the appropriate mechanism for multi-cast protocols where all of
-      one's peers share a common sub-session key, but some messages will
-      be sent to a subset of one's peers.
-
-      After computing the checksum, the client then transmits the
-      information and checksum to the recipient in the message format
-      specified in section 5.6.1.
-
-3.4.2. Receipt of KRB_SAFE message
-
-
-
-February 2004                                                  [Page 43]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      When an application receives a KRB_SAFE message, it verifies it as
-      follows.  If any error occurs, an error code is reported for use
-      by the application.
-
-      The message is first checked by verifying that the protocol
-      version and type fields match the current version and KRB_SAFE,
-      respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or
-      KRB_AP_ERR_MSG_TYPE error. The application verifies that the
-      checksum used is a collision-proof keyed checksum that uses keys
-      compatible with the sub-session or session key as appropriate (or
-      with the application key derived from the session or sub-session
-      keys), and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is
-      generated.  The sender's address MUST be included in the control
-      information; the recipient verifies that the operating system's
-      report of the sender's address matches the sender's address in the
-      message, and (if a recipient address is specified or the recipient
-      requires an address) that one of the recipient's addresses appears
-      as the recipient's address in the message. To work with network
-      address translation, senders MAY use the directional address type
-      specified in section 8.1 for the sender address and not include
-      recipient addresses. A failed match for either case generates a
-      KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the
-      sequence number fields are checked. If timestamp and usec are
-      expected and not present, or they are present but not current, the
-      KRB_AP_ERR_SKEW error is generated. Timestamps are not required to
-      be strictly ordered; they are only required to be in the skew
-      window.  If the server name, along with the client name, time and
-      microsecond fields from the Authenticator match any recently-seen
-      (sent or received) such tuples, the KRB_AP_ERR_REPEAT error is
-      generated. If an incorrect sequence number is included, or a
-      sequence number is expected but not present, the
-      KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp
-      and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED
-      error is generated. Finally, the checksum is computed over the
-      data and control information, and if it doesn't match the received
-      checksum, a KRB_AP_ERR_MODIFIED error is generated.
-
-      If all the checks succeed, the application is assured that the
-      message was generated by its peer and was not modified in transit.
-
-      Implementations SHOULD accept any checksum algorithm they
-      implement that both have adequate security and that have keys
-      compatible with the sub-session or session key. Unkeyed or non-
-      collision-proof checksums are not suitable for this use.
-
-3.5. The KRB_PRIV Exchange
-
-      The KRB_PRIV message MAY be used by clients requiring
-
-
-
-February 2004                                                  [Page 44]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      confidentiality and the ability to detect modifications of
-      exchanged messages. It achieves this by encrypting the messages
-      and adding control information.
-
-3.5.1. Generation of a KRB_PRIV message
-
-      When an application wishes to send a KRB_PRIV message, it collects
-      its data and the appropriate control information (specified in
-      section 5.7.1) and encrypts them under an encryption key (usually
-      the last key negotiated via subkeys, or the session key if no
-      negotiation has occurred). As part of the control information, the
-      client MUST choose to use either a timestamp or a sequence number
-      (or both); see the discussion in section 3.4.1 for guidelines on
-      which to use. After the user data and control information are
-      encrypted, the client transmits the ciphertext and some 'envelope'
-      information to the recipient.
-
-3.5.2. Receipt of KRB_PRIV message
-
-      When an application receives a KRB_PRIV message, it verifies it as
-      follows.  If any error occurs, an error code is reported for use
-      by the application.
-
-      The message is first checked by verifying that the protocol
-      version and type fields match the current version and KRB_PRIV,
-      respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or
-      KRB_AP_ERR_MSG_TYPE error. The application then decrypts the
-      ciphertext and processes the resultant plaintext. If decryption
-      shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY
-      error is generated.
-
-      The sender's address MUST be included in the control information;
-      the recipient verifies that the operating system's report of the
-      sender's address matches the sender's address in the message.  If
-      a recipient address is specified or the recipient requires an
-      address then one of the recipient's addresses MUST also appear as
-      the recipient's address in the message.  Where a sender's or
-      receiver's address might not otherwise match the address in a
-      message because of network address translation, an application MAY
-      be written to use addresses of the directional address type in
-      place of the actual network address.
-
-      A failed match for either case generates a KRB_AP_ERR_BADADDR
-      error. To work with network address translation, implementations
-      MAY use the directional address type defined in section 7.1 for
-      the sender address and include no recipient address.
-
-      Then the timestamp and usec and/or the sequence number fields are
-
-
-
-February 2004                                                  [Page 45]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      checked. If timestamp and usec are expected and not present, or
-      they are present but not current, the KRB_AP_ERR_SKEW error is
-      generated. If the server name, along with the client name, time
-      and microsecond fields from the Authenticator match any recently-
-      seen such tuples, the KRB_AP_ERR_REPEAT error is generated. If an
-      incorrect sequence number is included, or a sequence number is
-      expected but not present, the KRB_AP_ERR_BADORDER error is
-      generated. If neither a time-stamp and usec or a sequence number
-      is present, a KRB_AP_ERR_MODIFIED error is generated.
-
-      If all the checks succeed, the application can assume the message
-      was generated by its peer, and was securely transmitted (without
-      intruders able to see the unencrypted contents).
-
-3.6. The KRB_CRED Exchange
-
-      The KRB_CRED message MAY be used by clients requiring the ability
-      to send Kerberos credentials from one host to another. It achieves
-      this by sending the tickets together with encrypted data
-      containing the session keys and other information associated with
-      the tickets.
-
-3.6.1. Generation of a KRB_CRED message
-
-      When an application wishes to send a KRB_CRED message it first
-      (using the KRB_TGS exchange) obtains credentials to be sent to the
-      remote host. It then constructs a KRB_CRED message using the
-      ticket or tickets so obtained, placing the session key needed to
-      use each ticket in the key field of the corresponding KrbCredInfo
-      sequence of the encrypted part of the KRB_CRED message.
-
-      Other information associated with each ticket and obtained during
-      the KRB_TGS exchange is also placed in the corresponding
-      KrbCredInfo sequence in the encrypted part of the KRB_CRED
-      message. The current time and, if specifically required by the
-      application the nonce, s-address, and r-address fields, are placed
-      in the encrypted part of the KRB_CRED message which is then
-      encrypted under an encryption key previously exchanged in the
-      KRB_AP exchange (usually the last key negotiated via subkeys, or
-      the session key if no negotiation has occurred).
-
-      Implementation note: When constructing a KRB_CRED message for
-      inclusion in a GSSAPI initial context token, the MIT
-      implementation of Kerberos will not encrypt the KRB_CRED message
-      if the session key is a DES or triple DES key.  For
-      interoperability with MIT, the Microsoft implementation will not
-      encrypt the KRB_CRED in a GSSAPI token if it is using a DES
-      session key. Starting at version 1.2.5, MIT Kerberos can receive
-
-
-
-February 2004                                                  [Page 46]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      and decode either encrypted or unencrypted KRB_CRED tokens in the
-      GSSAPI exchange. The Heimdal implementation of Kerberos can also
-      accept either encrypted or unencrypted KRB_CRED messages. Since
-      the KRB_CRED message in a GSSAPI token is encrypted in the
-      authenticator, the MIT behavior does not present a security
-      problem, although it is a violation of the Kerberos specification.
-
-3.6.2. Receipt of KRB_CRED message
-
-      When an application receives a KRB_CRED message, it verifies it.
-      If any error occurs, an error code is reported for use by the
-      application. The message is verified by checking that the protocol
-      version and type fields match the current version and KRB_CRED,
-      respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or
-      KRB_AP_ERR_MSG_TYPE error. The application then decrypts the
-      ciphertext and processes the resultant plaintext. If decryption
-      shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY
-      error is generated.
-
-      If present or required, the recipient MAY verify that the
-      operating system's report of the sender's address matches the
-      sender's address in the message, and that one of the recipient's
-      addresses appears as the recipient's address in the message. The
-      address check does not provide any added security, since the
-      address if present has already been checked in the KRB_AP_REQ
-      message and there is not any benefit to be gained by an attacker
-      in reflecting a KRB_CRED message back to its originator. Thus, the
-      recipient MAY ignore the address even if present in order to work
-      better in NAT environments. A failed match for either case
-      generates a KRB_AP_ERR_BADADDR error. Recipients MAY skip the
-      address check as the KRB_CRED message cannot generally be
-      reflected back to the originator.  The timestamp and usec fields
-      (and the nonce field if required) are checked next. If the
-      timestamp and usec are not present, or they are present but not
-      current, the KRB_AP_ERR_SKEW error is generated.
-
-      If all the checks succeed, the application stores each of the new
-      tickets in its credentials cache together with the session key and
-      other information in the corresponding KrbCredInfo sequence from
-      the encrypted part of the KRB_CRED message.
-
-3.7. User-to-User Authentication Exchanges
-
-      User-to-User authentication provides a method to perform
-      authentication when the verifier does not have a access to long
-      term service key. This might be the case when running a server
-      (for example a window server) as a user on a workstation. In such
-      cases, the server may have access to the ticket-granting ticket
-
-
-
-February 2004                                                  [Page 47]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      obtained when the user logged in to the workstation, but because
-      the server is running as an unprivileged user it might not have
-      access to system keys. Similar situations may arise when running
-      peer-to-peer applications.
-
-                                Summary
-          Message direction                    Message type     Sections
-          0. Message from application server   Not Specified
-          1. Client to Kerberos                KRB_TGS_REQ      3.3 + 5.4.1
-          2. Kerberos to client                KRB_TGS_REP or   3.3 + 5.4.2
-                                               KRB_ERROR        5.9.1
-          3. Client to Application server      KRB_AP_REQ       3.2 + 5.5.1
-
-      To address this problem, the Kerberos protocol allows the client
-      to request that the ticket issued by the KDC be encrypted using a
-      session key from a ticket-granting ticket issued to the party that
-      will verify the authentication.  This ticket-granting ticket must
-      be obtained from the verifier by means of an exchange external to
-      the Kerberos protocol, usually as part of the application
-      protocol. This message is shown in the summary above as message 0.
-      Note that because the ticket-granting ticket is encrypted in the
-      KDC's secret key, it can not be used for authentication without
-      possession of the corresponding secret key.  Furthermore, because
-      the verifier does not reveal the corresponding secret key,
-      providing a copy of the verifier's ticket-granting ticket does not
-      allow impersonation of the verifier.
-
-      Message 0 in the table above represents an application specific
-      negotiation between the client and server, at the end of which
-      both have determined that they will use user-to-user
-      authentication and the client has obtained the server's TGT.
-
-      Next, the client includes the server's TGT as an additional ticket
-      in its KRB_TGS_REQ request to the KDC (message 1 in the table
-      above) and specifies the ENC-TKT-IN-SKEY option in its request.
-
-      If validated according to the instructions in 3.3.3, the
-      application ticket returned to the client (message 2 in the table
-      above) will be encrypted using the session key from the additional
-      ticket and the client will note this when it uses or stores the
-      application ticket.
-
-      When contacting the server using a ticket obtained for user-to-
-      user authentication (message 3 in the table above), the client
-      MUST specify the USE-SESSION-KEY flag in the ap-options field.
-      This tells the application server to use the session key
-      associated with its ticket-granting ticket to decrypt the server
-      ticket provided in the application request.
-
-
-
-February 2004                                                  [Page 48]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-4. Encryption and Checksum Specifications
-
-      The Kerberos protocols described in this document are designed to
-      encrypt messages of arbitrary sizes, using stream or block
-      encryption ciphers.  Encryption is used to prove the identities of
-      the network entities participating in message exchanges. The Key
-      Distribution Center for each realm is trusted by all principals
-      registered in that realm to store a secret key in confidence.
-      Proof of knowledge of this secret key is used to verify the
-      authenticity of a principal.
-
-      The KDC uses the principal's secret key (in the AS exchange) or a
-      shared session key (in the TGS exchange) to encrypt responses to
-      ticket requests; the ability to obtain the secret key or session
-      key implies the knowledge of the appropriate keys and the identity
-      of the KDC. The ability of a principal to decrypt the KDC response
-      and present a Ticket and a properly formed Authenticator
-      (generated with the session key from the KDC response) to a
-      service verifies the identity of the principal; likewise the
-      ability of the service to extract the session key from the Ticket
-      and prove its knowledge thereof in a response verifies the
-      identity of the service.
-
-      [@KCRYPTO] defines a framework for defining encryption and
-      checksum mechanisms for use with Kerberos. It also defines several
-      such mechanisms, and more may be added in future updates to that
-      document.
-
-      The string-to-key operation provided by [@KCRYPTO] is used to
-      produce a long-term key for a principal (generally for a user).
-      The default salt string, if none is provided via pre-
-      authentication data, is the concatenation of the principal's realm
-      and name components, in order, with no separators.  Unless
-      otherwise indicated, the default string-to-key opaque parameter
-      set as defined in [@KCRYPTO] is used.
-
-      Encrypted data, keys and checksums are transmitted using the
-      EncryptedData, EncryptionKey and Checksum data objects defined in
-      section 5.2.9. The encryption, decryption, and checksum operations
-      described in this document use the corresponding encryption,
-      decryption, and get_mic operations described in [@KCRYPTO], with
-      implicit "specific key" generation using the "key usage" values
-      specified in the description of each EncryptedData or Checksum
-      object to vary the key for each operation. Note that in some
-      cases, the value to be used is dependent on the method of choosing
-      the key or the context of the message.
-
-      Key usages are unsigned 32 bit integers; zero is not permitted.
-
-
-
-February 2004                                                  [Page 49]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      The key usage values for encrypting or checksumming Kerberos
-      messages are indicated in section 5 along with the message
-      definitions. Key usage values 512-1023 are reserved for uses
-      internal to a Kerberos implementation. (For example, seeding a
-      pseudo-random number generator with a value produced by encrypting
-      something with a session key and a key usage value not used for
-      any other purpose.) Key usage values between 1024 and 2047
-      (inclusive) are reserved for application use; applications SHOULD
-      use even values for encryption and odd values for checksums within
-      this range. Key usage values are also summarized in a table in
-      section 7.5.1.
-
-      There might exist other documents which define protocols in terms
-      of the RFC1510 encryption types or checksum types. Such documents
-      would not know about key usages. In order that these
-      specifications continue to be meaningful until they are updated,
-      if no key usage values are specified then key usages 1024 and 1025
-      must be used to derive keys for encryption and checksums,
-      respectively (this does not apply to protocols that do their own
-      encryption independent of this framework, directly using the key
-      resulting from the Kerberos authentication exchange.) New
-      protocols defined in terms of the Kerberos encryption and checksum
-      types SHOULD use their own key usage values.
-
-      Unless otherwise indicated, no cipher state chaining is done from
-      one encryption operation to another.
-
-      Implementation note: While not recommended, some application
-      protocols will continue to use the key data directly, even if only
-      in currently existing protocol specifications. An implementation
-      intended to support general Kerberos applications may therefore
-      need to make key data available, as well as the attributes and
-      operations described in [@KCRYPTO].  One of the more common
-      reasons for directly performing encryption is direct control over
-      negotiation and selection of a "sufficiently strong" encryption
-      algorithm (in the context of a given application). While Kerberos
-      does not directly provide a facility for negotiating encryption
-      types between the application client and server, there are
-      approaches for using Kerberos to facilitate this negotiation - for
-      example, a client may request only "sufficiently strong" session
-      key types from the KDC and expect that any type returned by the
-      KDC will be understood and supported by the application server.
-
-5. Message Specifications
-
-      NOTE: The ASN.1 collected here should be identical to the contents
-      of Appendix A. In case of conflict, the contents of Appendix A
-      shall take precedence.
-
-
-
-February 2004                                                  [Page 50]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      The Kerberos protocol is defined here in terms of Abstract Syntax
-      Notation One (ASN.1) [X680], which provides a syntax for
-      specifying both the abstract layout of protocol messages as well
-      as their encodings. Implementors not utilizing an existing ASN.1
-      compiler or support library are cautioned to thoroughly understand
-      the actual ASN.1 specification to ensure correct implementation
-      behavior, as there is more complexity in the notation than is
-      immediately obvious, and some tutorials and guides to ASN.1 are
-      misleading or erroneous.
-
-      Note that in several places, there have been changes here from RFC
-      1510 that change the abstract types. This is in part to address
-      widespread assumptions that various implementors have made, in
-      some cases resulting in unintentional violations of the ASN.1
-      standard. These are clearly flagged where they occur. The
-      differences between the abstract types in RFC 1510 and abstract
-      types in this document can cause incompatible encodings to be
-      emitted when certain encoding rules, e.g. the Packed Encoding
-      Rules (PER), are used. This theoretical incompatibility should not
-      be relevant for Kerberos, since Kerberos explicitly specifies the
-      use of the Distinguished Encoding Rules (DER). It might be an
-      issue for protocols wishing to use Kerberos types with other
-      encoding rules. (This practice is not recommended.) With very few
-      exceptions (most notably the usages of BIT STRING), the encodings
-      resulting from using the DER remain identical between the types
-      defined in RFC 1510 and the types defined in this document.
-
-      The type definitions in this section assume an ASN.1 module
-      definition of the following form:
-
-      KerberosV5Spec2 {
-              iso(1) identified-organization(3) dod(6) internet(1)
-              security(5) kerberosV5(2) modules(4) krb5spec2(2)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      -- rest of definitions here
-
-      END
-
-      This specifies that the tagging context for the module will be
-      explicit and non-automatic.
-
-      Note that in some other publications [RFC1510] [RFC1964], the
-      "dod" portion of the object identifier is erroneously specified as
-      having the value "5".  In the case of RFC 1964, use of the
-      "correct" OID value would result in a change in the wire protocol;
-      therefore, it remains unchanged for now.
-
-
-
-
-February 2004                                                  [Page 51]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      Note that elsewhere in this document, nomenclature for various
-      message types is inconsistent, but largely follows C language
-      conventions, including use of underscore (_) characters and all-
-      caps spelling of names intended to be numeric constants. Also, in
-      some places, identifiers (especially ones referring to constants)
-      are written in all-caps in order to distinguish them from
-      surrounding explanatory text.
-
-      The ASN.1 notation does not permit underscores in identifiers, so
-      in actual ASN.1 definitions, underscores are replaced with hyphens
-      (-). Additionally, structure member names and defined values in
-      ASN.1 MUST begin with a lowercase letter, while type names MUST
-      begin with an uppercase letter.
-
-5.1. Specific Compatibility Notes on ASN.1
-
-      For compatibility purposes, implementors should heed the following
-      specific notes regarding the use of ASN.1 in Kerberos. These notes
-      do not describe deviations from standard usage of ASN.1. The
-      purpose of these notes is to instead describe some historical
-      quirks and non-compliance of various implementations, as well as
-      historical ambiguities, which, while being valid ASN.1, can lead
-      to confusion during implementation.
-
-5.1.1. ASN.1 Distinguished Encoding Rules
-
-      The encoding of Kerberos protocol messages shall obey the
-      Distinguished Encoding Rules (DER) of ASN.1 as described in
-      [X690]. Some implementations (believed to be primarily ones
-      derived from DCE 1.1 and earlier) are known to use the more
-      general Basic Encoding Rules (BER); in particular, these
-      implementations send indefinite encodings of lengths.
-      Implementations MAY accept such encodings in the interests of
-      backwards compatibility, though implementors are warned that
-      decoding fully-general BER is fraught with peril.
-
-5.1.2. Optional Integer Fields
-
-      Some implementations do not internally distinguish between an
-      omitted optional integer value and a transmitted value of zero.
-      The places in the protocol where this is relevant include various
-      microseconds fields, nonces, and sequence numbers. Implementations
-      SHOULD treat omitted optional integer values as having been
-      transmitted with a value of zero, if the application is expecting
-      this.
-
-5.1.3. Empty SEQUENCE OF Types
-
-
-
-
-February 2004                                                  [Page 52]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      There are places in the protocol where a message contains a
-      SEQUENCE OF type as an optional member. This can result in an
-      encoding that contains an empty SEQUENCE OF encoding. The Kerberos
-      protocol does not semantically distinguish between an absent
-      optional SEQUENCE OF type and a present optional but empty
-      SEQUENCE OF type. Implementations SHOULD NOT send empty SEQUENCE
-      OF encodings that are marked OPTIONAL, but SHOULD accept them as
-      being equivalent to an omitted OPTIONAL type. In the ASN.1 syntax
-      describing Kerberos messages, instances of these problematic
-      optional SEQUENCE OF types are indicated with a comment.
-
-5.1.4. Unrecognized Tag Numbers
-
-      Future revisions to this protocol may include new message types
-      with different APPLICATION class tag numbers. Such revisions
-      should protect older implementations by only sending the message
-      types to parties that are known to understand them, e.g. by means
-      of a flag bit set by the receiver in a preceding request. In the
-      interest of robust error handling, implementations SHOULD
-      gracefully handle receiving a message with an unrecognized tag
-      anyway, and return an error message if appropriate.
-
-      In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the
-      incorrect tag is sent over a TCP transport.  The KDCs SHOULD NOT
-      respond to messages received with an unknown tag over UDP
-      transport in order to avoid denial of service attacks.  For non-
-      KDC applications, the Kerberos implementation typically indicates
-      an error to the application which takes appropriate steps based on
-      the application protocol.
-
-5.1.5. Tag Numbers Greater Than 30
-
-      A naive implementation of a DER ASN.1 decoder may experience
-      problems with ASN.1 tag numbers greater than 30, due to such tag
-      numbers being encoded using more than one byte. Future revisions
-      of this protocol may utilize tag numbers greater than 30, and
-      implementations SHOULD be prepared to gracefully return an error,
-      if appropriate, if they do not recognize the tag.
-
-5.2. Basic Kerberos Types
-
-      This section defines a number of basic types that are potentially
-      used in multiple Kerberos protocol messages.
-
-5.2.1. KerberosString
-
-      The original specification of the Kerberos protocol in RFC 1510
-      uses GeneralString in numerous places for human-readable string
-
-
-
-February 2004                                                  [Page 53]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      data. Historical implementations of Kerberos cannot utilize the
-      full power of GeneralString.  This ASN.1 type requires the use of
-      designation and invocation escape sequences as specified in
-      ISO-2022/ECMA-35 [ISO-2022/ECMA-35] to switch character sets, and
-      the default character set that is designated as G0 is the
-      ISO-646/ECMA-6 [ISO-646,ECMA-6] International Reference Version
-      (IRV) (aka U.S. ASCII), which mostly works.
-
-      ISO-2022/ECMA-35 defines four character-set code elements (G0..G3)
-      and two Control-function code elements (C0..C1). DER prohibits the
-      designation of character sets as any but the G0 and C0 sets.
-      Unfortunately, this seems to have the side effect of prohibiting
-      the use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any
-      other character-sets that utilize a 96-character set, since it is
-      prohibited by ISO-2022/ECMA-35 to designate them as the G0 code
-      element. This side effect is being investigated in the ASN.1
-      standards community.
-
-      In practice, many implementations treat GeneralStrings as if they
-      were 8-bit strings of whichever character set the implementation
-      defaults to, without regard for correct usage of character-set
-      designation escape sequences. The default character set is often
-      determined by the current user's operating system dependent
-      locale. At least one major implementation places unescaped UTF-8
-      encoded Unicode characters in the GeneralString. This failure to
-      adhere to the GeneralString specifications results in
-      interoperability issues when conflicting character encodings are
-      utilized by the Kerberos clients, services, and KDC.
-
-      This unfortunate situation is the result of improper documentation
-      of the restrictions of the ASN.1 GeneralString type in prior
-      Kerberos specifications.
-
-      The new (post-RFC 1510) type KerberosString, defined below, is a
-      GeneralString that is constrained to only contain characters in
-      IA5String
-
-         KerberosString  ::= GeneralString (IA5String)
-
-      In general, US-ASCII control characters should not be used in
-      KerberosString. Control characters SHOULD NOT be used in principal
-      names or realm names.
-
-      For compatibility, implementations MAY choose to accept
-      GeneralString values that contain characters other than those
-      permitted by IA5String, but they should be aware that character
-      set designation codes will likely be absent, and that the encoding
-      should probably be treated as locale-specific in almost every way.
-
-
-
-February 2004                                                  [Page 54]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      Implementations MAY also choose to emit GeneralString values that
-      are beyond those permitted by IA5String, but should be aware that
-      doing so is extraordinarily risky from an interoperability
-      perspective.
-
-      Some existing implementations use GeneralString to encode
-      unescaped locale-specific characters. This is a violation of the
-      ASN.1 standard. Most of these implementations encode US-ASCII in
-      the left-hand half, so as long the implementation transmits only
-      US-ASCII, the ASN.1 standard is not violated in this regard. As
-      soon as such an implementation encodes unescaped locale-specific
-      characters with the high bit set, it violates the ASN.1 standard.
-
-      Other implementations have been known to use GeneralString to
-      contain a UTF-8 encoding. This also violates the ASN.1 standard,
-      since UTF-8 is a different encoding, not a 94 or 96 character "G"
-      set as defined by ISO 2022.  It is believed that these
-      implementations do not even use the ISO 2022 escape sequence to
-      change the character encoding. Even if implementations were to
-      announce the change of encoding by using that escape sequence, the
-      ASN.1 standard prohibits the use of any escape sequences other
-      than those used to designate/invoke "G" or "C" sets allowed by
-      GeneralString.
-
-      Future revisions to this protocol will almost certainly allow for
-      a more interoperable representation of principal names, probably
-      including UTF8String.
-
-      Note that applying a new constraint to a previously unconstrained
-      type constitutes creation of a new ASN.1 type. In this particular
-      case, the change does not result in a changed encoding under DER.
-
-5.2.2. Realm and PrincipalName
-
-      Realm           ::= KerberosString
-
-      PrincipalName   ::= SEQUENCE {
-              name-type       [0] Int32,
-              name-string     [1] SEQUENCE OF KerberosString
-      }
-
-      Kerberos realm names are encoded as KerberosStrings. Realms shall
-      not contain a character with the code 0 (the US-ASCII NUL). Most
-      realms will usually consist of several components separated by
-      periods (.), in the style of Internet Domain Names, or separated
-      by slashes (/) in the style of X.500 names. Acceptable forms for
-      realm names are specified in section 6.1.. A PrincipalName is a
-      typed sequence of components consisting of the following sub-
-
-
-
-February 2004                                                  [Page 55]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      fields:
-
-   name-type
-      This field specifies the type of name that follows. Pre-defined
-      values for this field are specified in section 6.2. The name-type
-      SHOULD be treated as a hint. Ignoring the name type, no two names
-      can be the same (i.e. at least one of the components, or the
-      realm, must be different).
-
-   name-string
-      This field encodes a sequence of components that form a name, each
-      component encoded as a KerberosString. Taken together, a
-      PrincipalName and a Realm form a principal identifier. Most
-      PrincipalNames will have only a few components (typically one or
-      two).
-
-5.2.3. KerberosTime
-
-      KerberosTime    ::= GeneralizedTime -- with no fractional seconds
-
-      The timestamps used in Kerberos are encoded as GeneralizedTimes. A
-      KerberosTime value shall not include any fractional portions of
-      the seconds.  As required by the DER, it further shall not include
-      any separators, and it shall specify the UTC time zone (Z).
-      Example: The only valid format for UTC time 6 minutes, 27 seconds
-      after 9 pm on 6 November 1985 is 19851106210627Z.
-
-5.2.4. Constrained Integer types
-
-      Some integer members of types SHOULD be constrained to values
-      representable in 32 bits, for compatibility with reasonable
-      implementation limits.
-
-      Int32           ::= INTEGER (-2147483648..2147483647)
-                          -- signed values representable in 32 bits
-
-      UInt32          ::= INTEGER (0..4294967295)
-                          -- unsigned 32 bit values
-
-      Microseconds    ::= INTEGER (0..999999)
-                          -- microseconds
-
-      While this results in changes to the abstract types from the RFC
-      1510 version, the encoding in DER should be unaltered. Historical
-      implementations were typically limited to 32-bit integer values
-      anyway, and assigned numbers SHOULD fall in the space of integer
-      values representable in 32 bits in order to promote
-      interoperability anyway.
-
-
-
-February 2004                                                  [Page 56]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      There are several integer fields in messages that are constrained
-      to fixed values.
-
-   pvno
-      also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always
-      the constant integer 5. There is no easy way to make this field
-      into a useful protocol version number, so its value is fixed.
-
-   msg-type
-      this integer field is usually identical to the application tag
-      number of the containing message type.
-
-5.2.5. HostAddress and HostAddresses
-
-      HostAddress     ::= SEQUENCE  {
-              addr-type       [0] Int32,
-              address         [1] OCTET STRING
-      }
-
-      -- NOTE: HostAddresses is always used as an OPTIONAL field and
-      -- should not be empty.
-      HostAddresses   -- NOTE: subtly different from rfc1510,
-                      -- but has a value mapping and encodes the same
-              ::= SEQUENCE OF HostAddress
-
-      The host address encodings consists of two fields:
-
-   addr-type
-      This field specifies the type of address that follows. Pre-defined
-      values for this field are specified in section 7.5.3.
-
-   address
-      This field encodes a single address of type addr-type.
-
-5.2.6. AuthorizationData
-
-      -- NOTE: AuthorizationData is always used as an OPTIONAL field and
-      -- should not be empty.
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-              ad-type         [0] Int32,
-              ad-data         [1] OCTET STRING
-      }
-
-   ad-data
-      This field contains authorization data to be interpreted according
-      to the value of the corresponding ad-type field.
-
-   ad-type
-
-
-
-February 2004                                                  [Page 57]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      This field specifies the format for the ad-data subfield. All
-      negative values are reserved for local use. Non-negative values
-      are reserved for registered use.
-
-   Each sequence of type and data is referred to as an authorization
-   element.  Elements MAY be application specific, however, there is a
-   common set of recursive elements that should be understood by all
-   implementations. These elements contain other elements embedded
-   within them, and the interpretation of the encapsulating element
-   determines which of the embedded elements must be interpreted, and
-   which may be ignored.
-
-   These common authorization data elements are recursively defined,
-   meaning the ad-data for these types will itself contain a sequence of
-   authorization data whose interpretation is affected by the
-   encapsulating element. Depending on the meaning of the encapsulating
-   element, the encapsulated elements may be ignored, might be
-   interpreted as issued directly by the KDC, or they might be stored in
-   a separate plaintext part of the ticket. The types of the
-   encapsulating elements are specified as part of the Kerberos
-   specification because the behavior based on these values should be
-   understood across implementations whereas other elements need only be
-   understood by the applications which they affect.
-
-   Authorization data elements are considered critical if present in a
-   ticket or authenticator. Unless encapsulated in a known authorization
-   data element amending the criticality of the elements it contains, if
-   an unknown authorization data element type is received by a server
-   either in an AP-REQ or in a ticket contained in an AP-REQ, then
-   authentication MUST fail.  Authorization data is intended to restrict
-   the use of a ticket. If the service cannot determine whether the
-   restriction applies to that service then a security weakness may
-   result if the ticket can be used for that service. Authorization
-   elements that are optional can be enclosed in AD-IF-RELEVANT element.
-
-   In the definitions that follow, the value of the ad-type for the
-   element will be specified as the least significant part of the
-   subsection number, and the value of the ad-data will be as shown in
-   the ASN.1 structure that follows the subsection heading.
-
-             contents of ad-data          ad-type
-
-    DER encoding of AD-IF-RELEVANT        1
-
-    DER encoding of AD-KDCIssued          4
-
-    DER encoding of AD-AND-OR             5
-
-
-
-
-February 2004                                                  [Page 58]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-    DER encoding of AD-MANDATORY-FOR-KDC  8
-
-5.2.6.1. IF-RELEVANT
-
-      AD-IF-RELEVANT          ::= AuthorizationData
-
-      AD elements encapsulated within the if-relevant element are
-      intended for interpretation only by application servers that
-      understand the particular ad-type of the embedded element.
-      Application servers that do not understand the type of an element
-      embedded within the if-relevant element MAY ignore the
-      uninterpretable element. This element promotes interoperability
-      across implementations which may have local extensions for
-      authorization.  The ad-type for AD-IF-RELEVANT is (1).
-
-5.2.6.2. KDCIssued
-
-      AD-KDCIssued            ::= SEQUENCE {
-              ad-checksum     [0] Checksum,
-              i-realm         [1] Realm OPTIONAL,
-              i-sname         [2] PrincipalName OPTIONAL,
-              elements        [3] AuthorizationData
-      }
-
-   ad-checksum
-      A cryptographic checksum computed over the DER encoding of the
-      AuthorizationData in the "elements" field, keyed with the session
-      key.  Its checksumtype is the mandatory checksum type for the
-      encryption type of the session key, and its key usage value is 19.
-
-   i-realm, i-sname
-      The name of the issuing principal if different from the KDC
-      itself.  This field would be used when the KDC can verify the
-      authenticity of elements signed by the issuing principal and it
-      allows this KDC to notify the application server of the validity
-      of those elements.
-
-   elements
-      A sequence of authorization data elements issued by the KDC.
-
-   The KDC-issued ad-data field is intended to provide a means for
-   Kerberos principal credentials to embed within themselves privilege
-   attributes and other mechanisms for positive authorization,
-   amplifying the privileges of the principal beyond what can be done
-   using a credentials without such an a-data element.
-
-   This can not be provided without this element because the definition
-   of the authorization-data field allows elements to be added at will
-
-
-
-February 2004                                                  [Page 59]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-   by the bearer of a TGT at the time that they request service tickets
-   and elements may also be added to a delegated ticket by inclusion in
-   the authenticator.
-
-   For KDC-issued elements this is prevented because the elements are
-   signed by the KDC by including a checksum encrypted using the
-   server's key (the same key used to encrypt the ticket - or a key
-   derived from that key). Elements encapsulated with in the KDC-issued
-   element MUST  be ignored by the application server if this
-   "signature" is not present. Further, elements encapsulated within
-   this element from a ticket-granting ticket MAY be interpreted by the
-   KDC, and used as a basis according to policy for including new signed
-   elements within derivative tickets, but they will not be copied to a
-   derivative ticket directly. If they are copied directly to a
-   derivative ticket by a KDC that is not aware of this element, the
-   signature will not be correct for the application ticket elements,
-   and the field will be ignored by the application server.
-
-   This element and the elements it encapsulates MAY be safely ignored
-   by applications, application servers, and KDCs that do not implement
-   this element.
-
-   The ad-type for AD-KDC-ISSUED is (4).
-
-5.2.6.3. AND-OR
-
-      AD-AND-OR               ::= SEQUENCE {
-              condition-count [0] INTEGER,
-              elements        [1] AuthorizationData
-      }
-
-
-      When restrictive AD elements are encapsulated within the and-or
-      element, the and-or element is considered satisfied if and only if
-      at least the number of encapsulated elements specified in
-      condition-count are satisfied.  Therefore, this element MAY be
-      used to implement an "or" operation by setting the condition-count
-      field to 1, and it MAY specify an "and" operation by setting the
-      condition count to the number of embedded elements. Application
-      servers that do not implement this element MUST reject tickets
-      that contain authorization data elements of this type.
-
-      The ad-type for AD-AND-OR is (5).
-
-5.2.6.4. MANDATORY-FOR-KDC
-
-      AD-MANDATORY-FOR-KDC    ::= AuthorizationData
-
-
-
-
-February 2004                                                  [Page 60]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      AD elements encapsulated within the mandatory-for-kdc element are
-      to be interpreted by the KDC. KDCs that do not understand the type
-      of an element embedded within the mandatory-for-kdc element MUST
-      reject the request.
-
-      The ad-type for AD-MANDATORY-FOR-KDC is (8).
-
-5.2.7. PA-DATA
-
-      Historically, PA-DATA have been known as "pre-authentication
-      data", meaning that they were used to augment the initial
-      authentication with the KDC.  Since that time, they have also been
-      used as a typed hole with which to extend protocol exchanges with
-      the KDC.
-
-      PA-DATA         ::= SEQUENCE {
-              -- NOTE: first tag is [1], not [0]
-              padata-type     [1] Int32,
-              padata-value    [2] OCTET STRING -- might be encoded AP-REQ
-      }
-
-   padata-type
-      indicates the way that the padata-value element is to be
-      interpreted.  Negative values of padata-type are reserved for
-      unregistered use; non-negative values are used for a registered
-      interpretation of the element type.
-
-   padata-value
-      Usually contains the DER encoding of another type; the padata-type
-      field identifies which type is encoded here.
-
-       padata-type        name           contents of padata-value
-
-       1            pa-tgs-req       DER encoding of AP-REQ
-
-       2            pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP
-
-       3            pa-pw-salt       salt (not ASN.1 encoded)
-
-       11           pa-etype-info    DER encoding of ETYPE-INFO
-
-       19           pa-etype-info2   DER encoding of ETYPE-INFO2
-
-      This field MAY also contain information needed by certain
-      extensions to the Kerberos protocol. For example, it might be used
-      to initially verify the identity of a client before any response
-      is returned.
-
-
-
-
-February 2004                                                  [Page 61]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      The padata field can also contain information needed to help the
-      KDC or the client select the key needed for generating or
-      decrypting the response. This form of the padata is useful for
-      supporting the use of certain token cards with Kerberos. The
-      details of such extensions are specified in separate documents.
-      See [Pat92] for additional uses of this field.
-
-5.2.7.1. PA-TGS-REQ
-
-      In the case of requests for additional tickets (KRB_TGS_REQ),
-      padata-value will contain an encoded AP-REQ. The checksum in the
-      authenticator (which MUST be collision-proof) is to be computed
-      over the KDC-REQ-BODY encoding.
-
-5.2.7.2. Encrypted Timestamp Pre-authentication
-
-      There are pre-authentication types that may be used to pre-
-      authenticate a client by means of an encrypted timestamp.
-
-      PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
-
-      PA-ENC-TS-ENC           ::= SEQUENCE {
-              patimestamp     [0] KerberosTime -- client's time --,
-              pausec          [1] Microseconds OPTIONAL
-      }
-
-      Patimestamp contains the client's time, and pausec contains the
-      microseconds, which MAY be omitted if a client will not generate
-      more than one request per second. The ciphertext (padata-value)
-      consists of the PA-ENC-TS-ENC encoding, encrypted using the
-      client's secret key and a key usage value of 1.
-
-      This pre-authentication type was not present in RFC 1510, but many
-      implementations support it.
-
-5.2.7.3. PA-PW-SALT
-
-      The padata-value for this pre-authentication type contains the
-      salt for the string-to-key to be used by the client to obtain the
-      key for decrypting the encrypted part of an AS-REP message.
-      Unfortunately, for historical reasons, the character set to be
-      used is unspecified and probably locale-specific.
-
-      This pre-authentication type was not present in RFC 1510, but many
-      implementations support it. It is necessary in any case where the
-      salt for the string-to-key algorithm is not the default.
-
-      In the trivial example, a zero-length salt string is very
-
-
-
-February 2004                                                  [Page 62]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      commonplace for realms that have converted their principal
-      databases from Kerberos 4.
-
-      A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message
-      that requests additional pre-authentication. Implementation note:
-      some KDC implementations issue an erroneous PA-PW-SALT when
-      issuing a KRB-ERROR message that requests additional pre-
-      authentication. Therefore, clients SHOULD ignore a PA-PW-SALT
-      accompanying a KRB-ERROR message that requests additional pre-
-      authentication.  As noted in section 3.1.3, a KDC MUST NOT send
-      PA-PW-SALT when the client's AS-REQ includes at least one "newer"
-      etype.
-
-5.2.7.4. PA-ETYPE-INFO
-
-      The ETYPE-INFO pre-authentication type is sent by the KDC in a
-      KRB-ERROR indicating a requirement for additional pre-
-      authentication. It is usually used to notify a client of which key
-      to use for the encryption of an encrypted timestamp for the
-      purposes of sending a PA-ENC-TIMESTAMP pre-authentication value.
-      It MAY also be sent in an AS-REP to provide information to the
-      client about which key salt to use for the string-to-key to be
-      used by the client to obtain the key for decrypting the encrypted
-      part the AS-REP.
-
-      ETYPE-INFO-ENTRY        ::= SEQUENCE {
-              etype           [0] Int32,
-              salt            [1] OCTET STRING OPTIONAL
-      }
-
-      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
-
-      The salt, like that of PA-PW-SALT, is also completely unspecified
-      with respect to character set and is probably locale-specific.
-
-      If ETYPE-INFO is sent in an AS-REP, there shall be exactly one
-      ETYPE-INFO-ENTRY, and its etype shall match that of the enc-part
-      in the AS-REP.
-
-      This pre-authentication type was not present in RFC 1510, but many
-      implementations that support encrypted timestamps for pre-
-      authentication need to support ETYPE-INFO as well.  As noted in
-      section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's
-      AS-REQ includes at least one "newer" etype.
-
-5.2.7.5. PA-ETYPE-INFO2
-
-      The ETYPE-INFO2 pre-authentication type is sent by the KDC in a
-
-
-
-February 2004                                                  [Page 63]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      KRB-ERROR indicating a requirement for additional pre-
-      authentication. It is usually used to notify a client of which key
-      to use for the encryption of an encrypted timestamp for the
-      purposes of sending a PA-ENC-TIMESTAMP pre-authentication value.
-      It MAY also be sent in an AS-REP to provide information to the
-      client about which key salt to use for the string-to-key to be
-      used by the client to obtain the key for decrypting the encrypted
-      part the AS-REP.
-
-      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
-              etype           [0] Int32,
-              salt            [1] KerberosString OPTIONAL,
-              s2kparams       [2] OCTET STRING OPTIONAL
-      }
-
-      ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
-
-      The type of the salt is KerberosString, but existing installations
-      might have locale-specific characters stored in salt strings, and
-      implementors MAY choose to handle them.
-
-      The interpretation of s2kparams is specified in the cryptosystem
-      description associated with the etype. Each cryptosystem has a
-      default interpretation of s2kparams that will hold if that element
-      is omitted from the encoding of ETYPE-INFO2-ENTRY.
-
-      If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one
-      ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part
-      in the AS-REP.
-
-      The preferred ordering of the "hint" pre-authentication data that
-      affect client key selection is: ETYPE-INFO2, followed by ETYPE-
-      INFO, followed by PW-SALT.  As noted in section 3.1.3, a KDC MUST
-      NOT send ETYPE-INFO or PW-SALT when the client's AS-REQ includes
-      at least one "newer" etype.
-
-      The ETYPE-INFO2 pre-authentication type was not present in RFC
-      1510.
-
-5.2.8. KerberosFlags
-
-      For several message types, a specific constrained bit string type,
-      KerberosFlags, is used.
-
-      KerberosFlags   ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
-                          -- shall be sent, but no fewer than 32
-
-      Compatibility note: the following paragraphs describe a change
-
-
-
-February 2004                                                  [Page 64]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      from the RFC1510 description of bit strings that would result in
-      incompatility in the case of an implementation that strictly
-      conformed to ASN.1 DER and RFC1510.
-
-      ASN.1 bit strings have multiple uses. The simplest use of a bit
-      string is to contain a vector of bits, with no particular meaning
-      attached to individual bits. This vector of bits is not
-      necessarily a multiple of eight bits long.  The use in Kerberos of
-      a bit string as a compact boolean vector wherein each element has
-      a distinct meaning poses some problems. The natural notation for a
-      compact boolean vector is the ASN.1 "NamedBit" notation, and the
-      DER require that encodings of a bit string using "NamedBit"
-      notation exclude any trailing zero bits. This truncation is easy
-      to neglect, especially given C language implementations that
-      naturally choose to store boolean vectors as 32 bit integers.
-
-      For example, if the notation for KDCOptions were to include the
-      "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be
-      encoded had only the "forwardable" (bit number one) bit set, the
-      DER encoding MUST include only two bits: the first reserved bit
-      ("reserved", bit number zero, value zero) and the one-valued bit
-      (bit number one) for "forwardable".
-
-      Most existing implementations of Kerberos unconditionally send 32
-      bits on the wire when encoding bit strings used as boolean
-      vectors. This behavior violates the ASN.1 syntax used for flag
-      values in RFC 1510, but occurs on such a widely installed base
-      that the protocol description is being modified to accommodate it.
-
-      Consequently, this document removes the "NamedBit" notations for
-      individual bits, relegating them to comments. The size constraint
-      on the KerberosFlags type requires that at least 32 bits be
-      encoded at all times, though a lenient implementation MAY choose
-      to accept fewer than 32 bits and to treat the missing bits as set
-      to zero.
-
-      Currently, no uses of KerberosFlags specify more than 32 bits
-      worth of flags, although future revisions of this document may do
-      so. When more than 32 bits are to be transmitted in a
-      KerberosFlags value, future revisions to this document will likely
-      specify that the smallest number of bits needed to encode the
-      highest-numbered one-valued bit should be sent. This is somewhat
-      similar to the DER encoding of a bit string that is declared with
-      the "NamedBit" notation.
-
-5.2.9. Cryptosystem-related Types
-
-      Many Kerberos protocol messages contain an EncryptedData as a
-
-
-
-February 2004                                                  [Page 65]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      container for arbitrary encrypted data, which is often the
-      encrypted encoding of another data type. Fields within
-      EncryptedData assist the recipient in selecting a key with which
-      to decrypt the enclosed data.
-
-      EncryptedData   ::= SEQUENCE {
-              etype   [0] Int32 -- EncryptionType --,
-              kvno    [1] UInt32 OPTIONAL,
-              cipher  [2] OCTET STRING -- ciphertext
-      }
-
-   etype
-      This field identifies which encryption algorithm was used to
-      encipher the cipher.
-
-   kvno
-      This field contains the version number of the key under which data
-      is encrypted. It is only present in messages encrypted under long
-      lasting keys, such as principals' secret keys.
-
-   cipher
-      This field contains the enciphered text, encoded as an OCTET
-      STRING.  (Note that the encryption mechanisms defined in
-      [@KCRYPTO] MUST incorporate integrity protection as well, so no
-      additional checksum is required.)
-
-   The EncryptionKey type is the means by which cryptographic keys used
-   for encryption are transferred.
-
-   EncryptionKey   ::= SEQUENCE {
-           keytype         [0] Int32 -- actually encryption type --,
-           keyvalue        [1] OCTET STRING
-   }
-
-   keytype
-      This field specifies the encryption type of the encryption key
-      that follows in the keyvalue field. While its name is "keytype",
-      it actually specifies an encryption type. Previously, multiple
-      cryptosystems that performed encryption differently but were
-      capable of using keys with the same characteristics were permitted
-      to share an assigned number to designate the type of key; this
-      usage is now deprecated.
-
-   keyvalue
-      This field contains the key itself, encoded as an octet string.
-
-   Messages containing cleartext data to be authenticated will usually
-   do so by using a member of type Checksum. Most instances of Checksum
-
-
-
-February 2004                                                  [Page 66]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-   use a keyed hash, though exceptions will be noted.
-
-   Checksum        ::= SEQUENCE {
-           cksumtype       [0] Int32,
-           checksum        [1] OCTET STRING
-   }
-
-   cksumtype
-      This field indicates the algorithm used to generate the
-      accompanying checksum.
-
-   checksum
-      This field contains the checksum itself, encoded as an octet
-      string.
-
-   See section 4 for a brief description of the use of encryption and
-   checksums in Kerberos.
-
-5.3. Tickets
-
-      This section describes the format and encryption parameters for
-      tickets and authenticators. When a ticket or authenticator is
-      included in a protocol message it is treated as an opaque object.
-      A ticket is a record that helps a client authenticate to a
-      service. A Ticket contains the following information:
-
-      Ticket          ::= [APPLICATION 1] SEQUENCE {
-              tkt-vno         [0] INTEGER (5),
-              realm           [1] Realm,
-              sname           [2] PrincipalName,
-              enc-part        [3] EncryptedData -- EncTicketPart
-      }
-
-      -- Encrypted part of ticket
-      EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
-              flags                   [0] TicketFlags,
-              key                     [1] EncryptionKey,
-              crealm                  [2] Realm,
-              cname                   [3] PrincipalName,
-              transited               [4] TransitedEncoding,
-              authtime                [5] KerberosTime,
-              starttime               [6] KerberosTime OPTIONAL,
-              endtime                 [7] KerberosTime,
-              renew-till              [8] KerberosTime OPTIONAL,
-              caddr                   [9] HostAddresses OPTIONAL,
-              authorization-data      [10] AuthorizationData OPTIONAL
-      }
-
-
-
-
-February 2004                                                  [Page 67]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      -- encoded Transited field
-      TransitedEncoding       ::= SEQUENCE {
-              tr-type         [0] Int32 -- must be registered --,
-              contents        [1] OCTET STRING
-      }
-
-      TicketFlags     ::= KerberosFlags
-              -- reserved(0),
-              -- forwardable(1),
-              -- forwarded(2),
-              -- proxiable(3),
-              -- proxy(4),
-              -- may-postdate(5),
-              -- postdated(6),
-              -- invalid(7),
-              -- renewable(8),
-              -- initial(9),
-              -- pre-authent(10),
-              -- hw-authent(11),
-      -- the following are new since 1510
-              -- transited-policy-checked(12),
-              -- ok-as-delegate(13)
-
-   tkt-vno
-      This field specifies the version number for the ticket format.
-      This document describes version number 5.
-
-   realm
-      This field specifies the realm that issued a ticket. It also
-      serves to identify the realm part of the server's principal
-      identifier. Since a Kerberos server can only issue tickets for
-      servers within its realm, the two will always be identical.
-
-   sname
-      This field specifies all components of the name part of the
-      server's identity, including those parts that identify a specific
-      instance of a service.
-
-   enc-part
-      This field holds the encrypted encoding of the EncTicketPart
-      sequence.  It is encrypted in the key shared by Kerberos and the
-      end server (the server's secret key), using a key usage value of
-      2.
-
-   flags
-      This field indicates which of various options were used or
-      requested when the ticket was issued. The meanings of the flags
-      are:
-
-
-
-February 2004                                                  [Page 68]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-         Bit(s)  Name                   Description
-
-         0       reserved               Reserved for future expansion of this
-                                        field.
-
-                                        The FORWARDABLE flag is normally only
-                                        interpreted by the TGS, and can be
-                                        ignored by end servers. When set, this
-         1       forwardable            flag tells the ticket-granting server
-                                        that it is OK to issue a new
-                                        ticket-granting ticket with a
-                                        different network address based on the
-                                        presented ticket.
-
-                                        When set, this flag indicates that the
-                                        ticket has either been forwarded or
-         2       forwarded              was issued based on authentication
-                                        involving a forwarded ticket-granting
-                                        ticket.
-
-                                        The PROXIABLE flag is normally only
-                                        interpreted by the TGS, and can be
-                                        ignored by end servers. The PROXIABLE
-                                        flag has an interpretation identical
-         3       proxiable              to that of the FORWARDABLE flag,
-                                        except that the PROXIABLE flag tells
-                                        the ticket-granting server that only
-                                        non-ticket-granting tickets may be
-                                        issued with different network
-                                        addresses.
-
-         4       proxy                  When set, this flag indicates that a
-                                        ticket is a proxy.
-
-                                        The MAY-POSTDATE flag is normally only
-                                        interpreted by the TGS, and can be
-         5       may-postdate           ignored by end servers. This flag
-                                        tells the ticket-granting server that
-                                        a post-dated ticket MAY be issued
-                                        based on this ticket-granting ticket.
-
-                                        This flag indicates that this ticket
-                                        has been postdated. The end-service
-         6       postdated              can check the authtime field to see
-                                        when the original authentication
-                                        occurred.
-
-                                        This flag indicates that a ticket is
-
-
-
-February 2004                                                  [Page 69]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-                                        invalid, and it must be validated by
-         7       invalid                the KDC before use. Application
-                                        servers must reject tickets which have
-                                        this flag set.
-
-                                        The RENEWABLE flag is normally only
-                                        interpreted by the TGS, and can
-                                        usually be ignored by end servers
-         8       renewable              (some particularly careful servers MAY
-                                        disallow renewable tickets). A
-                                        renewable ticket can be used to obtain
-                                        a replacement ticket that expires at a
-                                        later date.
-
-                                        This flag indicates that this ticket
-         9       initial                was issued using the AS protocol, and
-                                        not issued based on a ticket-granting
-                                        ticket.
-
-                                        This flag indicates that during
-                                        initial authentication, the client was
-                                        authenticated by the KDC before a
-         10      pre-authent            ticket was issued. The strength of the
-                                        pre-authentication method is not
-                                        indicated, but is acceptable to the
-                                        KDC.
-
-                                        This flag indicates that the protocol
-                                        employed for initial authentication
-                                        required the use of hardware expected
-         11      hw-authent             to be possessed solely by the named
-                                        client. The hardware authentication
-                                        method is selected by the KDC and the
-                                        strength of the method is not
-                                        indicated.
-
-                                        This flag indicates that the KDC for
-                                        the realm has checked the transited
-                                        field against a realm defined policy
-                                        for trusted certifiers. If this flag
-                                        is reset (0), then the application
-                                        server must check the transited field
-                                        itself, and if unable to do so it must
-                                        reject the authentication. If the flag
-         12      transited-             is set (1) then the application server
-                 policy-checked         MAY skip its own validation of the
-                                        transited field, relying on the
-                                        validation performed by the KDC. At
-
-
-
-February 2004                                                  [Page 70]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-                                        its option the application server MAY
-                                        still apply its own validation based
-                                        on a separate policy for acceptance.
-
-                                        This flag is new since RFC 1510.
-
-                                        This flag indicates that the server
-                                        (not the client) specified in the
-                                        ticket has been determined by policy
-                                        of the realm to be a suitable
-                                        recipient of delegation. A client can
-                                        use the presence of this flag to help
-                                        it make a decision whether to delegate
-                                        credentials (either grant a proxy or a
-                                        forwarded ticket-granting ticket) to
-         13      ok-as-delegate         this server. The client is free to
-                                        ignore the value of this flag. When
-                                        setting this flag, an administrator
-                                        should consider the Security and
-                                        placement of the server on which the
-                                        service will run, as well as whether
-                                        the service requires the use of
-                                        delegated credentials.
-
-                                        This flag is new since RFC 1510.
-
-         14-31   reserved               Reserved for future use.
-
-   key
-      This field exists in the ticket and the KDC response and is used
-      to pass the session key from Kerberos to the application server
-      and the client.
-
-   crealm
-      This field contains the name of the realm in which the client is
-      registered and in which initial authentication took place.
-
-   cname
-      This field contains the name part of the client's principal
-      identifier.
-
-   transited
-      This field lists the names of the Kerberos realms that took part
-      in authenticating the user to whom this ticket was issued. It does
-      not specify the order in which the realms were transited. See
-      section 3.3.3.2 for details on how this field encodes the
-      traversed realms.  When the names of CA's are to be embedded in
-      the transited field (as specified for some extensions to the
-
-
-
-February 2004                                                  [Page 71]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      protocol), the X.500 names of the CA's SHOULD be mapped into items
-      in the transited field using the mapping defined by RFC2253.
-
-   authtime
-      This field indicates the time of initial authentication for the
-      named principal. It is the time of issue for the original ticket
-      on which this ticket is based. It is included in the ticket to
-      provide additional information to the end service, and to provide
-      the necessary information for implementation of a `hot list'
-      service at the KDC. An end service that is particularly paranoid
-      could refuse to accept tickets for which the initial
-      authentication occurred "too far" in the past. This field is also
-      returned as part of the response from the KDC.  When returned as
-      part of the response to initial authentication (KRB_AS_REP), this
-      is the current time on the Kerberos server.  It is NOT recommended
-      that this time value be used to adjust the workstation's clock
-      since the workstation cannot reliably determine that such a
-      KRB_AS_REP actually came from the proper KDC in a timely manner.
-
-
-   starttime
-
-      This field in the ticket specifies the time after which the ticket
-      is valid. Together with endtime, this field specifies the life of
-      the ticket. If the starttime field is absent from the ticket, then
-      the authtime field SHOULD be used in its place to determine the
-      life of the ticket.
-
-   endtime
-      This field contains the time after which the ticket will not be
-      honored (its expiration time). Note that individual services MAY
-      place their own limits on the life of a ticket and MAY reject
-      tickets which have not yet expired. As such, this is really an
-      upper bound on the expiration time for the ticket.
-
-   renew-till
-      This field is only present in tickets that have the RENEWABLE flag
-      set in the flags field. It indicates the maximum endtime that may
-      be included in a renewal. It can be thought of as the absolute
-      expiration time for the ticket, including all renewals.
-
-   caddr
-      This field in a ticket contains zero (if omitted) or more (if
-      present) host addresses. These are the addresses from which the
-      ticket can be used. If there are no addresses, the ticket can be
-      used from any location. The decision by the KDC to issue or by the
-      end server to accept addressless tickets is a policy decision and
-      is left to the Kerberos and end-service administrators; they MAY
-
-
-
-February 2004                                                  [Page 72]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      refuse to issue or accept such tickets. Because of the wide
-      deployment of network address translation, it is recommended that
-      policy allow the issue and acceptance of such tickets.
-
-      Network addresses are included in the ticket to make it harder for
-      an attacker to use stolen credentials. Because the session key is
-      not sent over the network in cleartext, credentials can't be
-      stolen simply by listening to the network; an attacker has to gain
-      access to the session key (perhaps through operating system
-      security breaches or a careless user's unattended session) to make
-      use of stolen tickets.
-
-      It is important to note that the network address from which a
-      connection is received cannot be reliably determined. Even if it
-      could be, an attacker who has compromised the client's workstation
-      could use the credentials from there. Including the network
-      addresses only makes it more difficult, not impossible, for an
-      attacker to walk off with stolen credentials and then use them
-      from a "safe" location.
-
-   authorization-data
-      The authorization-data field is used to pass authorization data
-      from the principal on whose behalf a ticket was issued to the
-      application service. If no authorization data is included, this
-      field will be left out. Experience has shown that the name of this
-      field is confusing, and that a better name for this field would be
-      restrictions. Unfortunately, it is not possible to change the name
-      of this field at this time.
-
-      This field contains restrictions on any authority obtained on the
-      basis of authentication using the ticket. It is possible for any
-      principal in possession of credentials to add entries to the
-      authorization data field since these entries further restrict what
-      can be done with the ticket.  Such additions can be made by
-      specifying the additional entries when a new ticket is obtained
-      during the TGS exchange, or they MAY be added during chained
-      delegation using the authorization data field of the
-      authenticator.
-
-      Because entries may be added to this field by the holder of
-      credentials, except when an entry is separately authenticated by
-      encapsulation in the KDC-issued element, it is not allowable for
-      the presence of an entry in the authorization data field of a
-      ticket to amplify the privileges one would obtain from using a
-      ticket.
-
-      The data in this field may be specific to the end service; the
-      field will contain the names of service specific objects, and the
-
-
-
-February 2004                                                  [Page 73]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      rights to those objects. The format for this field is described in
-      section 5.2.6.  Although Kerberos is not concerned with the format
-      of the contents of the sub-fields, it does carry type information
-      (ad-type).
-
-      By using the authorization_data field, a principal is able to
-      issue a proxy that is valid for a specific purpose. For example, a
-      client wishing to print a file can obtain a file server proxy to
-      be passed to the print server. By specifying the name of the file
-      in the authorization_data field, the file server knows that the
-      print server can only use the client's rights when accessing the
-      particular file to be printed.
-
-      A separate service providing authorization or certifying group
-      membership may be built using the authorization-data field. In
-      this case, the entity granting authorization (not the authorized
-      entity), may obtain a ticket in its own name (e.g. the ticket is
-      issued in the name of a privilege server), and this entity adds
-      restrictions on its own authority and delegates the restricted
-      authority through a proxy to the client. The client would then
-      present this authorization credential to the application server
-      separately from the authentication exchange.  Alternatively, such
-      authorization credentials MAY be embedded in the ticket
-      authenticating the authorized entity, when the authorization is
-      separately authenticated using the KDC-issued authorization data
-      element (see 5.2.6.2).
-
-      Similarly, if one specifies the authorization-data field of a
-      proxy and leaves the host addresses blank, the resulting ticket
-      and session key can be treated as a capability. See [Neu93] for
-      some suggested uses of this field.
-
-      The authorization-data field is optional and does not have to be
-      included in a ticket.
-
-5.4. Specifications for the AS and TGS exchanges
-
-      This section specifies the format of the messages used in the
-      exchange between the client and the Kerberos server. The format of
-      possible error messages appears in section 5.9.1.
-
-5.4.1. KRB_KDC_REQ definition
-
-      The KRB_KDC_REQ message has no application tag number of its own.
-      Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ,
-      which each have an application tag, depending on whether the
-      request is for an initial ticket or an additional ticket. In
-      either case, the message is sent from the client to the KDC to
-
-
-
-February 2004                                                  [Page 74]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      request credentials for a service.
-
-      The message fields are:
-
-      AS-REQ          ::= [APPLICATION 10] KDC-REQ
-
-      TGS-REQ         ::= [APPLICATION 12] KDC-REQ
-
-      KDC-REQ         ::= SEQUENCE {
-              -- NOTE: first tag is [1], not [0]
-              pvno            [1] INTEGER (5) ,
-              msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
-              padata          [3] SEQUENCE OF PA-DATA OPTIONAL
-                                  -- NOTE: not empty --,
-              req-body        [4] KDC-REQ-BODY
-      }
-
-      KDC-REQ-BODY    ::= SEQUENCE {
-              kdc-options             [0] KDCOptions,
-              cname                   [1] PrincipalName OPTIONAL
-                                          -- Used only in AS-REQ --,
-              realm                   [2] Realm
-                                          -- Server's realm
-                                          -- Also client's in AS-REQ --,
-              sname                   [3] PrincipalName OPTIONAL,
-              from                    [4] KerberosTime OPTIONAL,
-              till                    [5] KerberosTime,
-              rtime                   [6] KerberosTime OPTIONAL,
-              nonce                   [7] UInt32,
-              etype                   [8] SEQUENCE OF Int32 -- EncryptionType
-                                          -- in preference order --,
-              addresses               [9] HostAddresses OPTIONAL,
-              enc-authorization-data  [10] EncryptedData -- AuthorizationData --,
-              additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
-                                              -- NOTE: not empty
-      }
-
-      KDCOptions      ::= KerberosFlags
-              -- reserved(0),
-              -- forwardable(1),
-              -- forwarded(2),
-              -- proxiable(3),
-              -- proxy(4),
-              -- allow-postdate(5),
-              -- postdated(6),
-              -- unused7(7),
-              -- renewable(8),
-              -- unused9(9),
-
-
-
-February 2004                                                  [Page 75]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-              -- unused10(10),
-              -- opt-hardware-auth(11),
-              -- unused12(12),
-              -- unused13(13),
-      -- 15 is reserved for canonicalize
-              -- unused15(15),
-      -- 26 was unused in 1510
-              -- disable-transited-check(26),
-      --
-              -- renewable-ok(27),
-              -- enc-tkt-in-skey(28),
-              -- renew(30),
-              -- validate(31)
-
-   The fields in this message are:
-
-   pvno
-      This field is included in each message, and specifies the protocol
-      version number. This document specifies protocol version 5.
-
-   msg-type
-      This field indicates the type of a protocol message. It will
-      almost always be the same as the application identifier associated
-      with a message. It is included to make the identifier more readily
-      accessible to the application. For the KDC-REQ message, this type
-      will be KRB_AS_REQ or KRB_TGS_REQ.
-
-   padata
-      Contains pre-authentication data. Requests for additional tickets
-      (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ.
-
-      The padata (pre-authentication data) field contains a sequence of
-      authentication information which may be needed before credentials
-      can be issued or decrypted.
-
-   req-body
-      This field is a placeholder delimiting the extent of the remaining
-      fields. If a checksum is to be calculated over the request, it is
-      calculated over an encoding of the KDC-REQ-BODY sequence which is
-      enclosed within the req-body field.
-
-   kdc-options
-      This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to
-      the KDC and indicates the flags that the client wants set on the
-      tickets as well as other information that is to modify the
-      behavior of the KDC.  Where appropriate, the name of an option may
-      be the same as the flag that is set by that option. Although in
-      most case, the bit in the options field will be the same as that
-
-
-
-February 2004                                                  [Page 76]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      in the flags field, this is not guaranteed, so it is not
-      acceptable to simply copy the options field to the flags field.
-      There are various checks that must be made before honoring an
-      option anyway.
-
-      The kdc_options field is a bit-field, where the selected options
-      are indicated by the bit being set (1), and the unselected options
-      and reserved fields being reset (0). The encoding of the bits is
-      specified in section 5.2. The options are described in more detail
-      above in section 2. The meanings of the options are:
-
-         Bits    Name                     Description
-
-         0       RESERVED                 Reserved for future expansion of
-                                          this field.
-
-                                          The FORWARDABLE option indicates
-                                          that the ticket to be issued is to
-                                          have its forwardable flag set. It
-         1       FORWARDABLE              may only be set on the initial
-                                          request, or in a subsequent request
-                                          if the ticket-granting ticket on
-                                          which it is based is also
-                                          forwardable.
-
-                                          The FORWARDED option is only
-                                          specified in a request to the
-                                          ticket-granting server and will only
-                                          be honored if the ticket-granting
-                                          ticket in the request has its
-         2       FORWARDED                FORWARDABLE bit set. This option
-                                          indicates that this is a request for
-                                          forwarding. The address(es) of the
-                                          host from which the resulting ticket
-                                          is to be valid are included in the
-                                          addresses field of the request.
-
-                                          The PROXIABLE option indicates that
-                                          the ticket to be issued is to have
-                                          its proxiable flag set. It may only
-         3       PROXIABLE                be set on the initial request, or in
-                                          a subsequent request if the
-                                          ticket-granting ticket on which it
-                                          is based is also proxiable.
-
-                                          The PROXY option indicates that this
-                                          is a request for a proxy. This
-                                          option will only be honored if the
-
-
-
-February 2004                                                  [Page 77]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-                                          ticket-granting ticket in the
-         4       PROXY                    request has its PROXIABLE bit set.
-                                          The address(es) of the host from
-                                          which the resulting ticket is to be
-                                          valid are included in the addresses
-                                          field of the request.
-
-                                          The ALLOW-POSTDATE option indicates
-                                          that the ticket to be issued is to
-                                          have its MAY-POSTDATE flag set. It
-         5       ALLOW-POSTDATE           may only be set on the initial
-                                          request, or in a subsequent request
-                                          if the ticket-granting ticket on
-                                          which it is based also has its
-                                          MAY-POSTDATE flag set.
-
-                                          The POSTDATED option indicates that
-                                          this is a request for a postdated
-                                          ticket. This option will only be
-                                          honored if the ticket-granting
-                                          ticket on which it is based has its
-         6       POSTDATED                MAY-POSTDATE flag set. The resulting
-                                          ticket will also have its INVALID
-                                          flag set, and that flag may be reset
-                                          by a subsequent request to the KDC
-                                          after the starttime in the ticket
-                                          has been reached.
-
-         7       RESERVED                 This option is presently unused.
-
-                                          The RENEWABLE option indicates that
-                                          the ticket to be issued is to have
-                                          its RENEWABLE flag set. It may only
-                                          be set on the initial request, or
-                                          when the ticket-granting ticket on
-         8       RENEWABLE                which the request is based is also
-                                          renewable. If this option is
-                                          requested, then the rtime field in
-                                          the request contains the desired
-                                          absolute expiration time for the
-                                          ticket.
-
-         9       RESERVED                 Reserved for PK-Cross
-
-         10      RESERVED                 Reserved for future use.
-
-         11      RESERVED                 Reserved for opt-hardware-auth.
-
-
-
-
-February 2004                                                  [Page 78]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-         12-25   RESERVED                 Reserved for future use.
-
-                                          By default the KDC will check the
-                                          transited field of a
-                                          ticket-granting-ticket against the
-                                          policy of the local realm before it
-                                          will issue derivative tickets based
-                                          on the ticket-granting ticket. If
-                                          this flag is set in the request,
-                                          checking of the transited field is
-                                          disabled. Tickets issued without the
-         26      DISABLE-TRANSITED-CHECK  performance of this check will be
-                                          noted by the reset (0) value of the
-                                          TRANSITED-POLICY-CHECKED flag,
-                                          indicating to the application server
-                                          that the tranisted field must be
-                                          checked locally. KDCs are
-                                          encouraged but not required to honor
-                                          the DISABLE-TRANSITED-CHECK option.
-
-                                          This flag is new since RFC 1510
-
-                                          The RENEWABLE-OK option indicates
-                                          that a renewable ticket will be
-                                          acceptable if a ticket with the
-                                          requested life cannot otherwise be
-                                          provided. If a ticket with the
-                                          requested life cannot be provided,
-         27      RENEWABLE-OK             then a renewable ticket may be
-                                          issued with a renew-till equal to
-                                          the requested endtime. The value
-                                          of the renew-till field may still be
-                                          limited by local limits, or limits
-                                          selected by the individual principal
-                                          or server.
-
-                                          This option is used only by the
-                                          ticket-granting service. The
-                                          ENC-TKT-IN-SKEY option indicates
-         28      ENC-TKT-IN-SKEY          that the ticket for the end server
-                                          is to be encrypted in the session
-                                          key from the additional
-                                          ticket-granting ticket provided.
-
-         29      RESERVED                 Reserved for future use.
-
-                                          This option is used only by the
-                                          ticket-granting service. The RENEW
-
-
-
-February 2004                                                  [Page 79]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-                                          option indicates that the present
-                                          request is for a renewal. The ticket
-                                          provided is encrypted in the secret
-                                          key for the server on which it is
-         30      RENEW                    valid. This option will only be
-                                          honored if the ticket to be renewed
-                                          has its RENEWABLE flag set and if
-                                          the time in its renew-till field has
-                                          not passed. The ticket to be renewed
-                                          is passed in the padata field as
-                                          part of the authentication header.
-
-                                          This option is used only by the
-                                          ticket-granting service. The
-                                          VALIDATE option indicates that the
-                                          request is to validate a postdated
-                                          ticket. It will only be honored if
-                                          the ticket presented is postdated,
-                                          presently has its INVALID flag set,
-         31      VALIDATE                 and would be otherwise usable at
-                                          this time. A ticket cannot be
-                                          validated before its starttime. The
-                                          ticket presented for validation is
-                                          encrypted in the key of the server
-                                          for which it is valid and is passed
-                                          in the padata field as part of the
-                                          authentication header.
-   cname and sname
-      These fields are the same as those described for the ticket in
-      section 5.3. The sname may only be absent when the ENC-TKT-IN-SKEY
-      option is specified. If absent, the name of the server is taken
-      from the name of the client in the ticket passed as additional-
-      tickets.
-
-   enc-authorization-data
-      The enc-authorization-data, if present (and it can only be present
-      in the TGS_REQ form), is an encoding of the desired authorization-
-      data encrypted under the sub-session key if present in the
-      Authenticator, or alternatively from the session key in the
-      ticket-granting ticket (both the Authenticator and ticket-granting
-      ticket come from the padata field in the KRB_TGS_REQ). The key
-      usage value used when encrypting is 5 if a sub-session key is
-      used, or 4 if the session key is used.
-
-   realm
-      This field specifies the realm part of the server's principal
-      identifier. In the AS exchange, this is also the realm part of the
-      client's principal identifier.
-
-
-
-February 2004                                                  [Page 80]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-   from
-      This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
-      requests when the requested ticket is to be postdated. It
-      specifies the desired start time for the requested ticket. If this
-      field is omitted then the KDC SHOULD use the current time instead.
-
-   till
-      This field contains the expiration date requested by the client in
-      a ticket request. It is not optional, but if the requested endtime
-      is "19700101000000Z", the requested ticket is to have the maximum
-      endtime permitted according to KDC policy. Implementation note:
-      This special timestamp corresponds to a UNIX time_t value of zero
-      on most systems.
-
-   rtime
-      This field is the requested renew-till time sent from a client to
-      the KDC in a ticket request. It is optional.
-
-   nonce
-      This field is part of the KDC request and response. It is intended
-      to hold a random number generated by the client. If the same
-      number is included in the encrypted response from the KDC, it
-      provides evidence that the response is fresh and has not been
-      replayed by an attacker.  Nonces MUST NEVER be reused.
-
-   etype
-      This field specifies the desired encryption algorithm to be used
-      in the response.
-
-   addresses
-      This field is included in the initial request for tickets, and
-      optionally included in requests for additional tickets from the
-      ticket-granting server. It specifies the addresses from which the
-      requested ticket is to be valid. Normally it includes the
-      addresses for the client's host. If a proxy is requested, this
-      field will contain other addresses. The contents of this field are
-      usually copied by the KDC into the caddr field of the resulting
-      ticket.
-
-   additional-tickets
-      Additional tickets MAY be optionally included in a request to the
-      ticket-granting server. If the ENC-TKT-IN-SKEY option has been
-      specified, then the session key from the additional ticket will be
-      used in place of the server's key to encrypt the new ticket. When
-      the ENC-TKT-IN-SKEY option is used for user-to-user
-      authentication, this additional ticket MAY be a TGT issued by the
-      local realm or an inter-realm TGT issued for the current KDC's
-      realm by a remote KDC. If more than one option which requires
-
-
-
-February 2004                                                  [Page 81]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      additional tickets has been specified, then the additional tickets
-      are used in the order specified by the ordering of the options
-      bits (see kdc-options, above).
-
-   The application tag number will be either ten (10) or twelve (12)
-   depending on whether the request is for an initial ticket (AS-REQ) or
-   for an additional ticket (TGS-REQ).
-
-   The optional fields (addresses, authorization-data and additional-
-   tickets) are only included if necessary to perform the operation
-   specified in the kdc-options field.
-
-   It should be noted that in KRB_TGS_REQ, the protocol version number
-   appears twice and two different message types appear: the KRB_TGS_REQ
-   message contains these fields as does the authentication header
-   (KRB_AP_REQ) that is passed in the padata field.
-
-5.4.2. KRB_KDC_REP definition
-
-      The KRB_KDC_REP message format is used for the reply from the KDC
-      for either an initial (AS) request or a subsequent (TGS) request.
-      There is no message type for KRB_KDC_REP. Instead, the type will
-      be either KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the
-      ciphertext part of the reply depends on the message type. For
-      KRB_AS_REP, the ciphertext is encrypted in the client's secret
-      key, and the client's key version number is included in the key
-      version number for the encrypted data. For KRB_TGS_REP, the
-      ciphertext is encrypted in the sub-session key from the
-      Authenticator, or if absent, the session key from the ticket-
-      granting ticket used in the request.  In that case, no version
-      number will be present in the EncryptedData sequence.
-
-      The KRB_KDC_REP message contains the following fields:
-
-      AS-REP          ::= [APPLICATION 11] KDC-REP
-
-      TGS-REP         ::= [APPLICATION 13] KDC-REP
-
-      KDC-REP         ::= SEQUENCE {
-              pvno            [0] INTEGER (5),
-              msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
-              padata          [2] SEQUENCE OF PA-DATA OPTIONAL
-                                      -- NOTE: not empty --,
-              crealm          [3] Realm,
-              cname           [4] PrincipalName,
-              ticket          [5] Ticket,
-              enc-part        [6] EncryptedData
-                                      -- EncASRepPart or EncTGSRepPart,
-
-
-
-February 2004                                                  [Page 82]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-                                      -- as appropriate
-      }
-
-      EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
-
-      EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
-
-      EncKDCRepPart   ::= SEQUENCE {
-              key             [0] EncryptionKey,
-              last-req        [1] LastReq,
-              nonce           [2] UInt32,
-              key-expiration  [3] KerberosTime OPTIONAL,
-              flags           [4] TicketFlags,
-              authtime        [5] KerberosTime,
-              starttime       [6] KerberosTime OPTIONAL,
-              endtime         [7] KerberosTime,
-              renew-till      [8] KerberosTime OPTIONAL,
-              srealm          [9] Realm,
-              sname           [10] PrincipalName,
-              caddr           [11] HostAddresses OPTIONAL
-      }
-
-      LastReq         ::=     SEQUENCE OF SEQUENCE {
-              lr-type         [0] Int32,
-              lr-value        [1] KerberosTime
-      }
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      either KRB_AS_REP or KRB_TGS_REP.
-
-   padata
-      This field is described in detail in section 5.4.1. One possible
-      use for this field is to encode an alternate "salt" string to be
-      used with a string-to-key algorithm. This ability is useful to
-      ease transitions if a realm name needs to change (e.g. when a
-      company is acquired); in such a case all existing password-derived
-      entries in the KDC database would be flagged as needing a special
-      salt string until the next password change.
-
-   crealm, cname, srealm and sname
-      These fields are the same as those described for the ticket in
-      section 5.3.
-
-   ticket
-      The newly-issued ticket, from section 5.3.
-
-   enc-part
-
-
-
-February 2004                                                  [Page 83]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      This field is a place holder for the ciphertext and related
-      information that forms the encrypted part of a message. The
-      description of the encrypted part of the message follows each
-      appearance of this field.
-
-      The key usage value for encrypting this field is 3 in an AS-REP
-      message, using the client's long-term key or another key selected
-      via pre-authentication mechanisms. In a TGS-REP message, the key
-      usage value is 8 if the TGS session key is used, or 9 if a TGS
-      authenticator subkey is used.
-
-      Compatibility note: Some implementations unconditionally send an
-      encrypted EncTGSRepPart (application tag number 26) in this field
-      regardless of whether the reply is a AS-REP or a TGS-REP. In the
-      interests of compatibility, implementors MAY relax the check on
-      the tag number of the decrypted ENC-PART.
-
-   key
-      This field is the same as described for the ticket in section 5.3.
-
-   last-req
-      This field is returned by the KDC and specifies the time(s) of the
-      last request by a principal. Depending on what information is
-      available, this might be the last time that a request for a
-      ticket-granting ticket was made, or the last time that a request
-      based on a ticket-granting ticket was successful. It also might
-      cover all servers for a realm, or just the particular server. Some
-      implementations MAY display this information to the user to aid in
-      discovering unauthorized use of one's identity. It is similar in
-      spirit to the last login time displayed when logging into
-      timesharing systems.
-
-      lr-type
-         This field indicates how the following lr-value field is to be
-         interpreted. Negative values indicate that the information
-         pertains only to the responding server. Non-negative values
-         pertain to all servers for the realm.
-
-         If the lr-type field is zero (0), then no information is
-         conveyed by the lr-value subfield. If the absolute value of the
-         lr-type field is one (1), then the lr-value subfield is the
-         time of last initial request for a TGT. If it is two (2), then
-         the lr-value subfield is the time of last initial request. If
-         it is three (3), then the lr-value subfield is the time of
-         issue for the newest ticket-granting ticket used. If it is four
-         (4), then the lr-value subfield is the time of the last
-         renewal. If it is five (5), then the lr-value subfield is the
-         time of last request (of any type).  If it is (6), then the lr-
-
-
-
-February 2004                                                  [Page 84]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-         value subfield is the time when the password will expire.  If
-         it is (7), then the lr-value subfield is the time when the
-         account will expire.
-
-      lr-value
-         This field contains the time of the last request. The time MUST
-         be interpreted according to the contents of the accompanying
-         lr-type subfield.
-
-   nonce
-      This field is described above in section 5.4.1.
-
-   key-expiration
-      The key-expiration field is part of the response from the KDC and
-      specifies the time that the client's secret key is due to expire.
-      The expiration might be the result of password aging or an account
-      expiration. If present, it SHOULD be set to the earliest of the
-      user's key expiration and account expiration.  The use of this
-      field is deprecated and the last-req field SHOULD be used to
-      convey this information instead.  This field will usually be left
-      out of the TGS reply since the response to the TGS request is
-      encrypted in a session key and no client information need be
-      retrieved from the KDC database. It is up to the application
-      client (usually the login program) to take appropriate action
-      (such as notifying the user) if the expiration time is imminent.
-
-   flags, authtime, starttime, endtime, renew-till and caddr
-      These fields are duplicates of those found in the encrypted
-      portion of the attached ticket (see section 5.3), provided so the
-      client MAY verify they match the intended request and to assist in
-      proper ticket caching. If the message is of type KRB_TGS_REP, the
-      caddr field will only be filled in if the request was for a proxy
-      or forwarded ticket, or if the user is substituting a subset of
-      the addresses from the ticket-granting ticket. If the client-
-      requested addresses are not present or not used, then the
-      addresses contained in the ticket will be the same as those
-      included in the ticket-granting ticket.
-
-5.5. Client/Server (CS) message specifications
-
-      This section specifies the format of the messages used for the
-      authentication of the client to the application server.
-
-5.5.1. KRB_AP_REQ definition
-
-      The KRB_AP_REQ message contains the Kerberos protocol version
-      number, the message type KRB_AP_REQ, an options field to indicate
-      any options in use, and the ticket and authenticator themselves.
-
-
-
-February 2004                                                  [Page 85]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      The KRB_AP_REQ message is often referred to as the 'authentication
-      header'.
-
-      AP-REQ          ::= [APPLICATION 14] SEQUENCE {
-              pvno            [0] INTEGER (5),
-              msg-type        [1] INTEGER (14),
-              ap-options      [2] APOptions,
-              ticket          [3] Ticket,
-              authenticator   [4] EncryptedData -- Authenticator
-      }
-
-      APOptions       ::= KerberosFlags
-              -- reserved(0),
-              -- use-session-key(1),
-              -- mutual-required(2)
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_AP_REQ.
-
-   ap-options
-      This field appears in the application request (KRB_AP_REQ) and
-      affects the way the request is processed. It is a bit-field, where
-      the selected options are indicated by the bit being set (1), and
-      the unselected options and reserved fields being reset (0). The
-      encoding of the bits is specified in section 5.2. The meanings of
-      the options are:
-
-         Bit(s)  Name            Description
-
-         0       reserved        Reserved for future expansion of this field.
-
-                                 The USE-SESSION-KEY option indicates that the
-                                 ticket the client is presenting to a server
-         1       use-session-key is encrypted in the session key from the
-                                 server's ticket-granting ticket. When this
-                                 option is not specified, the ticket is
-                                 encrypted in the server's secret key.
-
-                                 The MUTUAL-REQUIRED option tells the server
-         2       mutual-required that the client requires mutual
-                                 authentication, and that it must respond with
-                                 a KRB_AP_REP message.
-
-         3-31    reserved        Reserved for future use.
-
-   ticket
-      This field is a ticket authenticating the client to the server.
-
-
-
-February 2004                                                  [Page 86]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-   authenticator
-      This contains the encrypted authenticator, which includes the
-      client's choice of a subkey.
-
-   The encrypted authenticator is included in the AP-REQ; it certifies
-   to a server that the sender has recent knowledge of the encryption
-   key in the accompanying ticket, to help the server detect replays. It
-   also assists in the selection of a "true session key" to use with the
-   particular session.  The DER encoding of the following is encrypted
-   in the ticket's session key, with a key usage value of 11 in normal
-   application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field
-   of a TGS-REQ exchange (see section 5.4.1):
-
-   -- Unencrypted authenticator
-   Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-           authenticator-vno       [0] INTEGER (5),
-           crealm                  [1] Realm,
-           cname                   [2] PrincipalName,
-           cksum                   [3] Checksum OPTIONAL,
-           cusec                   [4] Microseconds,
-           ctime                   [5] KerberosTime,
-           subkey                  [6] EncryptionKey OPTIONAL,
-           seq-number              [7] UInt32 OPTIONAL,
-           authorization-data      [8] AuthorizationData OPTIONAL
-   }
-
-   authenticator-vno
-      This field specifies the version number for the format of the
-      authenticator. This document specifies version 5.
-
-   crealm and cname
-      These fields are the same as those described for the ticket in
-      section 5.3.
-
-   cksum
-      This field contains a checksum of the application data that
-      accompanies the KRB_AP_REQ, computed using a key usage value of 10
-      in normal application exchanges, or 6 when used in the TGS-REQ PA-
-      TGS-REQ AP-DATA field.
-
-   cusec
-      This field contains the microsecond part of the client's
-      timestamp. Its value (before encryption) ranges from 0 to 999999.
-      It often appears along with ctime. The two fields are used
-      together to specify a reasonably accurate timestamp.
-
-   ctime
-      This field contains the current time on the client's host.
-
-
-
-February 2004                                                  [Page 87]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-   subkey
-      This field contains the client's choice for an encryption key
-      which is to be used to protect this specific application session.
-      Unless an application specifies otherwise, if this field is left
-      out the session key from the ticket will be used.
-
-   seq-number
-      This optional field includes the initial sequence number to be
-      used by the KRB_PRIV or KRB_SAFE messages when sequence numbers
-      are used to detect replays (It may also be used by application
-      specific messages).  When included in the authenticator this field
-      specifies the initial sequence number for messages from the client
-      to the server. When included in the AP-REP message, the initial
-      sequence number is that for messages from the server to the
-      client. When used in KRB_PRIV or KRB_SAFE messages, it is
-      incremented by one after each message is sent.  Sequence numbers
-      fall in the range of 0 through 2^32 - 1 and wrap to zero following
-      the value 2^32 - 1.
-
-      For sequence numbers to adequately support the detection of
-      replays they SHOULD be non-repeating, even across connection
-      boundaries. The initial sequence number SHOULD be random and
-      uniformly distributed across the full space of possible sequence
-      numbers, so that it cannot be guessed by an attacker and so that
-      it and the successive sequence numbers do not repeat other
-      sequences.  In the event that more than 2^32 messages are to be
-      generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying
-      SHOULD be performed before sequence numbers are reused with the
-      same encryption key.
-
-      Implmentation note: historically, some implementations transmit
-      signed twos-complement numbers for sequence numbers. In the
-      interests of compatibility, implementations MAY accept the
-      equivalent negative number where a positive number greater than
-      2^31 - 1 is expected.
-
-      Implementation note: as noted before, some implementations omit
-      the optional sequence number when its value would be zero.
-      Implementations MAY accept an omitted sequence number when
-      expecting a value of zero, and SHOULD NOT transmit an
-      Authenticator with a initial sequence number of zero.
-
-   authorization-data
-      This field is the same as described for the ticket in section 5.3.
-      It is optional and will only appear when additional restrictions
-      are to be placed on the use of a ticket, beyond those carried in
-      the ticket itself.
-
-
-
-
-February 2004                                                  [Page 88]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-5.5.2. KRB_AP_REP definition
-
-      The KRB_AP_REP message contains the Kerberos protocol version
-      number, the message type, and an encrypted time-stamp. The message
-      is sent in response to an application request (KRB_AP_REQ) where
-      the mutual authentication option has been selected in the ap-
-      options field.
-
-      AP-REP          ::= [APPLICATION 15] SEQUENCE {
-              pvno            [0] INTEGER (5),
-              msg-type        [1] INTEGER (15),
-              enc-part        [2] EncryptedData -- EncAPRepPart
-      }
-
-      EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
-              ctime           [0] KerberosTime,
-              cusec           [1] Microseconds,
-              subkey          [2] EncryptionKey OPTIONAL,
-              seq-number      [3] UInt32 OPTIONAL
-      }
-
-      The encoded EncAPRepPart is encrypted in the shared session key of
-      the ticket. The optional subkey field can be used in an
-      application-arranged negotiation to choose a per association
-      session key.
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_AP_REP.
-
-   enc-part
-      This field is described above in section 5.4.2. It is computed
-      with a key usage value of 12.
-
-   ctime
-      This field contains the current time on the client's host.
-
-   cusec
-      This field contains the microsecond part of the client's
-      timestamp.
-
-   subkey
-      This field contains an encryption key which is to be used to
-      protect this specific application session. See section 3.2.6 for
-      specifics on how this field is used to negotiate a key. Unless an
-      application specifies otherwise, if this field is left out, the
-      sub-session key from the authenticator, or if also left out, the
-      session key from the ticket will be used.
-
-
-
-February 2004                                                  [Page 89]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-   seq-number
-      This field is described above in section 5.3.2.
-
-5.5.3. Error message reply
-
-      If an error occurs while processing the application request, the
-      KRB_ERROR message will be sent in response. See section 5.9.1 for
-      the format of the error message. The cname and crealm fields MAY
-      be left out if the server cannot determine their appropriate
-      values from the corresponding KRB_AP_REQ message. If the
-      authenticator was decipherable, the ctime and cusec fields will
-      contain the values from it.
-
-5.6. KRB_SAFE message specification
-
-      This section specifies the format of a message that can be used by
-      either side (client or server) of an application to send a tamper-
-      proof message to its peer. It presumes that a session key has
-      previously been exchanged (for example, by using the
-      KRB_AP_REQ/KRB_AP_REP messages).
-
-5.6.1. KRB_SAFE definition
-
-      The KRB_SAFE message contains user data along with a collision-
-      proof checksum keyed with the last encryption key negotiated via
-      subkeys, or the session key if no negotiation has occurred. The
-      message fields are:
-
-      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-              pvno            [0] INTEGER (5),
-              msg-type        [1] INTEGER (20),
-              safe-body       [2] KRB-SAFE-BODY,
-              cksum           [3] Checksum
-      }
-
-      KRB-SAFE-BODY   ::= SEQUENCE {
-              user-data       [0] OCTET STRING,
-              timestamp       [1] KerberosTime OPTIONAL,
-              usec            [2] Microseconds OPTIONAL,
-              seq-number      [3] UInt32 OPTIONAL,
-              s-address       [4] HostAddress,
-              r-address       [5] HostAddress OPTIONAL
-      }
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_SAFE.
-
-
-
-
-February 2004                                                  [Page 90]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-   safe-body
-      This field is a placeholder for the body of the KRB-SAFE message.
-
-   cksum
-      This field contains the checksum of the application data, computed
-      with a key usage value of 15.
-
-      The checksum is computed over the encoding of the KRB-SAFE
-      sequence.  First, the cksum is set to a type zero, zero-length
-      value and the checksum is computed over the encoding of the KRB-
-      SAFE sequence, then the checksum is set to the result of that
-      computation, and finally the KRB-SAFE sequence is encoded again.
-      This method, while different than the one specified in RFC 1510,
-      corresponds to existing practice.
-
-   user-data
-      This field is part of the KRB_SAFE and KRB_PRIV messages and
-      contain the application specific data that is being passed from
-      the sender to the recipient.
-
-   timestamp
-      This field is part of the KRB_SAFE and KRB_PRIV messages. Its
-      contents are the current time as known by the sender of the
-      message. By checking the timestamp, the recipient of the message
-      is able to make sure that it was recently generated, and is not a
-      replay.
-
-   usec
-      This field is part of the KRB_SAFE and KRB_PRIV headers. It
-      contains the microsecond part of the timestamp.
-
-   seq-number
-      This field is described above in section 5.3.2.
-
-   s-address
-      Sender's address.
-
-      This field specifies the address in use by the sender of the
-      message.
-
-   r-address
-      This field specifies the address in use by the recipient of the
-      message. It MAY be omitted for some uses (such as broadcast
-      protocols), but the recipient MAY arbitrarily reject such
-      messages. This field, along with s-address, can be used to help
-      detect messages which have been incorrectly or maliciously
-      delivered to the wrong recipient.
-
-
-
-
-February 2004                                                  [Page 91]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-5.7. KRB_PRIV message specification
-
-      This section specifies the format of a message that can be used by
-      either side (client or server) of an application to securely and
-      privately send a message to its peer. It presumes that a session
-      key has previously been exchanged (for example, by using the
-      KRB_AP_REQ/KRB_AP_REP messages).
-
-5.7.1. KRB_PRIV definition
-
-      The KRB_PRIV message contains user data encrypted in the Session
-      Key. The message fields are:
-
-      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-              pvno            [0] INTEGER (5),
-              msg-type        [1] INTEGER (21),
-                              -- NOTE: there is no [2] tag
-              enc-part        [3] EncryptedData -- EncKrbPrivPart
-      }
-
-      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-              user-data       [0] OCTET STRING,
-              timestamp       [1] KerberosTime OPTIONAL,
-              usec            [2] Microseconds OPTIONAL,
-              seq-number      [3] UInt32 OPTIONAL,
-              s-address       [4] HostAddress -- sender's addr --,
-              r-address       [5] HostAddress OPTIONAL -- recip's addr
-      }
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_PRIV.
-
-   enc-part
-      This field holds an encoding of the EncKrbPrivPart sequence
-      encrypted under the session key, with a key usage value of 13.
-      This encrypted encoding is used for the enc-part field of the KRB-
-      PRIV message.
-
-   user-data, timestamp, usec, s-address and r-address
-      These fields are described above in section 5.6.1.
-
-   seq-number
-      This field is described above in section 5.3.2.
-
-5.8. KRB_CRED message specification
-
-      This section specifies the format of a message that can be used to
-
-
-
-February 2004                                                  [Page 92]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      send Kerberos credentials from one principal to another. It is
-      presented here to encourage a common mechanism to be used by
-      applications when forwarding tickets or providing proxies to
-      subordinate servers. It presumes that a session key has already
-      been exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP
-      messages.
-
-5.8.1. KRB_CRED definition
-
-      The KRB_CRED message contains a sequence of tickets to be sent and
-      information needed to use the tickets, including the session key
-      from each.  The information needed to use the tickets is encrypted
-      under an encryption key previously exchanged or transferred
-      alongside the KRB_CRED message. The message fields are:
-
-      KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
-              pvno            [0] INTEGER (5),
-              msg-type        [1] INTEGER (22),
-              tickets         [2] SEQUENCE OF Ticket,
-              enc-part        [3] EncryptedData -- EncKrbCredPart
-      }
-
-      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-              ticket-info     [0] SEQUENCE OF KrbCredInfo,
-              nonce           [1] UInt32 OPTIONAL,
-              timestamp       [2] KerberosTime OPTIONAL,
-              usec            [3] Microseconds OPTIONAL,
-              s-address       [4] HostAddress OPTIONAL,
-              r-address       [5] HostAddress OPTIONAL
-      }
-
-      KrbCredInfo     ::= SEQUENCE {
-              key             [0] EncryptionKey,
-              prealm          [1] Realm OPTIONAL,
-              pname           [2] PrincipalName OPTIONAL,
-              flags           [3] TicketFlags OPTIONAL,
-              authtime        [4] KerberosTime OPTIONAL,
-              starttime       [5] KerberosTime OPTIONAL,
-              endtime         [6] KerberosTime OPTIONAL,
-              renew-till      [7] KerberosTime OPTIONAL,
-              srealm          [8] Realm OPTIONAL,
-              sname           [9] PrincipalName OPTIONAL,
-              caddr           [10] HostAddresses OPTIONAL
-      }
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_CRED.
-
-
-
-February 2004                                                  [Page 93]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-   tickets
-      These are the tickets obtained from the KDC specifically for use
-      by the intended recipient. Successive tickets are paired with the
-      corresponding KrbCredInfo sequence from the enc-part of the KRB-
-      CRED message.
-
-   enc-part
-      This field holds an encoding of the EncKrbCredPart sequence
-      encrypted under the session key shared between the sender and the
-      intended recipient, with a key usage value of 14. This encrypted
-      encoding is used for the enc-part field of the KRB-CRED message.
-
-      Implementation note: implementations of certain applications, most
-      notably certain implementations of the Kerberos GSS-API mechanism,
-      do not separately encrypt the contents of the EncKrbCredPart of
-      the KRB-CRED message when sending it.  In the case of those GSS-
-      API mechanisms, this is not a security vulnerability, as the
-      entire KRB-CRED message is itself embedded in an encrypted
-      message.
-
-   nonce
-      If practical, an application MAY require the inclusion of a nonce
-      generated by the recipient of the message. If the same value is
-      included as the nonce in the message, it provides evidence that
-      the message is fresh and has not been replayed by an attacker. A
-      nonce MUST NEVER be reused.
-
-   timestamp and usec
-      These fields specify the time that the KRB-CRED message was
-      generated.  The time is used to provide assurance that the message
-      is fresh.
-
-   s-address and r-address
-      These fields are described above in section 5.6.1. They are used
-      optionally to provide additional assurance of the integrity of the
-      KRB-CRED message.
-
-   key
-      This field exists in the corresponding ticket passed by the KRB-
-      CRED message and is used to pass the session key from the sender
-      to the intended recipient. The field's encoding is described in
-      section 5.2.9.
-
-   The following fields are optional. If present, they can be associated
-   with the credentials in the remote ticket file. If left out, then it
-   is assumed that the recipient of the credentials already knows their
-   value.
-
-
-
-
-February 2004                                                  [Page 94]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-   prealm and pname
-      The name and realm of the delegated principal identity.
-
-   flags, authtime, starttime, endtime, renew-till, srealm, sname, and
-      caddr
-      These fields contain the values of the corresponding fields from
-      the ticket found in the ticket field. Descriptions of the fields
-      are identical to the descriptions in the KDC-REP message.
-
-5.9. Error message specification
-
-      This section specifies the format for the KRB_ERROR message. The
-      fields included in the message are intended to return as much
-      information as possible about an error. It is not expected that
-      all the information required by the fields will be available for
-      all types of errors. If the appropriate information is not
-      available when the message is composed, the corresponding field
-      will be left out of the message.
-
-      Note that since the KRB_ERROR message is not integrity protected,
-      it is quite possible for an intruder to synthesize or modify such
-      a message. In particular, this means that the client SHOULD NOT
-      use any fields in this message for security-critical purposes,
-      such as setting a system clock or generating a fresh
-      authenticator. The message can be useful, however, for advising a
-      user on the reason for some failure.
-
-5.9.1. KRB_ERROR definition
-
-      The KRB_ERROR message consists of the following fields:
-
-      KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
-              pvno            [0] INTEGER (5),
-              msg-type        [1] INTEGER (30),
-              ctime           [2] KerberosTime OPTIONAL,
-              cusec           [3] Microseconds OPTIONAL,
-              stime           [4] KerberosTime,
-              susec           [5] Microseconds,
-              error-code      [6] Int32,
-              crealm          [7] Realm OPTIONAL,
-              cname           [8] PrincipalName OPTIONAL,
-              realm           [9] Realm -- service realm --,
-              sname           [10] PrincipalName -- service name --,
-              e-text          [11] KerberosString OPTIONAL,
-              e-data          [12] OCTET STRING OPTIONAL
-      }
-
-   pvno and msg-type
-
-
-
-February 2004                                                  [Page 95]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_ERROR.
-
-   ctime
-      This field is described above in section 5.5.2.
-
-   cusec
-      This field is described above in section 5.5.2.
-
-   stime
-      This field contains the current time on the server. It is of type
-      KerberosTime.
-
-   susec
-      This field contains the microsecond part of the server's
-      timestamp. Its value ranges from 0 to 999999. It appears along
-      with stime. The two fields are used in conjunction to specify a
-      reasonably accurate timestamp.
-
-   error-code
-      This field contains the error code returned by Kerberos or the
-      server when a request fails. To interpret the value of this field
-      see the list of error codes in section 7.5.9. Implementations are
-      encouraged to provide for national language support in the display
-      of error messages.
-
-   crealm, cname, realm and sname
-      These fields are described above in section 5.3.
-
-   e-text
-      This field contains additional text to help explain the error code
-      associated with the failed request (for example, it might include
-      a principal name which was unknown).
-
-   e-data
-      This field contains additional data about the error for use by the
-      application to help it recover from or handle the error. If the
-      errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
-      contain an encoding of a sequence of padata fields, each
-      corresponding to an acceptable pre-authentication method and
-      optionally containing data for the method:
-
-      METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-   For error codes defined in this document other than
-   KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field
-   are implementation-defined. Similarly, for future error codes, the
-   format and contents of the e-data field are implementation-defined
-
-
-
-February 2004                                                  [Page 96]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-   unless specified. Whether defined by the implementation or in a
-   future document, the e-data field MAY take the form of TYPED-DATA:
-
-   TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-           data-type       [0] INTEGER,
-           data-value      [1] OCTET STRING OPTIONAL
-   }
-
-5.10. Application Tag Numbers
-
-      The following table lists the application class tag numbers used
-      by various data types defined in this section.
-
-       Tag Number(s)    Type Name    Comments
-
-       0                             unused
-
-       1              Ticket         PDU
-
-       2              Authenticator  non-PDU
-
-       3              EncTicketPart  non-PDU
-
-       4-9                           unused
-
-       10             AS-REQ         PDU
-
-       11             AS-REP         PDU
-
-       12             TGS-REQ        PDU
-
-       13             TGS-REP        PDU
-
-       14             AP-REQ         PDU
-
-       15             AP-REP         PDU
-
-       16             RESERVED16     TGT-REQ (for user-to-user)
-
-       17             RESERVED17     TGT-REP (for user-to-user)
-
-       18-19                         unused
-
-       20             KRB-SAFE       PDU
-
-       21             KRB-PRIV       PDU
-
-       22             KRB-CRED       PDU
-
-
-
-February 2004                                                  [Page 97]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-       23-24                         unused
-
-       25             EncASRepPart   non-PDU
-
-       26             EncTGSRepPart  non-PDU
-
-       27             EncApRepPart   non-PDU
-
-       28             EncKrbPrivPart non-PDU
-
-       29             EncKrbCredPart non-PDU
-
-       30             KRB-ERROR      PDU
-
-      The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above
-      are the only ASN.1 types intended as top-level types of the
-      Kerberos protocol, and are the only types that may be used as
-      elements in another protocol that makes use of Kerberos.
-
-6. Naming Constraints
-
-6.1. Realm Names
-
-      Although realm names are encoded as GeneralStrings and although a
-      realm can technically select any name it chooses, interoperability
-      across realm boundaries requires agreement on how realm names are
-      to be assigned, and what information they imply.
-
-      To enforce these conventions, each realm MUST conform to the
-      conventions itself, and it MUST require that any realms with which
-      inter-realm keys are shared also conform to the conventions and
-      require the same from its neighbors.
-
-      Kerberos realm names are case sensitive. Realm names that differ
-      only in the case of the characters are not equivalent. There are
-      presently three styles of realm names: domain, X500, and other.
-      Examples of each style follow:
-
-           domain:   ATHENA.MIT.EDU
-             X500:   C=US/O=OSF
-            other:   NAMETYPE:rest/of.name=without-restrictions
-
-      Domain style realm names MUST look like domain names: they consist
-      of components separated by periods (.) and they contain neither
-      colons (:) nor slashes (/). Though domain names themselves are
-      case insensitive, in order for realms to match, the case must
-      match as well. When establishing a new realm name based on an
-      internet domain name it is recommended by convention that the
-
-
-
-February 2004                                                  [Page 98]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      characters be converted to upper case.
-
-      X.500 names contain an equal (=) and cannot contain a colon (:)
-      before the equal. The realm names for X.500 names will be string
-      representations of the names with components separated by slashes.
-      Leading and trailing slashes will not be included. Note that the
-      slash separator is consistent with Kerberos implementations based
-      on RFC1510, but it is different from the separator recommended in
-      RFC2253.
-
-      Names that fall into the other category MUST begin with a prefix
-      that contains no equal (=) or period (.) and the prefix MUST be
-      followed by a colon (:) and the rest of the name. All prefixes
-      expect those beginning with used. Presently none are assigned.
-
-      The reserved category includes strings which do not fall into the
-      first three categories. All names in this category are reserved.
-      It is unlikely that names will be assigned to this category unless
-      there is a very strong argument for not using the 'other'
-      category.
-
-      These rules guarantee that there will be no conflicts between the
-      various name styles. The following additional constraints apply to
-      the assignment of realm names in the domain and X.500 categories:
-      the name of a realm for the domain or X.500 formats must either be
-      used by the organization owning (to whom it was assigned) an
-      Internet domain name or X.500 name, or in the case that no such
-      names are registered, authority to use a realm name MAY be derived
-      from the authority of the parent realm. For example, if there is
-      no domain name for E40.MIT.EDU, then the administrator of the
-      MIT.EDU realm can authorize the creation of a realm with that
-      name.
-
-      This is acceptable because the organization to which the parent is
-      assigned is presumably the organization authorized to assign names
-      to its children in the X.500 and domain name systems as well. If
-      the parent assigns a realm name without also registering it in the
-      domain name or X.500 hierarchy, it is the parent's responsibility
-      to make sure that there will not in the future exist a name
-      identical to the realm name of the child unless it is assigned to
-      the same entity as the realm name.
-
-6.2. Principal Names
-
-      As was the case for realm names, conventions are needed to ensure
-      that all agree on what information is implied by a principal name.
-      The name-type field that is part of the principal name indicates
-      the kind of information implied by the name. The name-type SHOULD
-
-
-
-February 2004                                                  [Page 99]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      be treated only as a hint to interpreting the meaning of a name.
-      It is not significant when checking for equivalence. Principal
-      names that differ only in the name-type identify the same
-      principal. The name type does not partition the name space.
-      Ignoring the name type, no two names can be the same (i.e. at
-      least one of the components, or the realm, MUST be different). The
-      following name types are defined:
-
-      name-type      value   meaning
-
-      name types
-
-      NT-UNKNOWN        0  Name type not known
-      NT-PRINCIPAL      1  Just the name of the principal as in DCE, or for users
-      NT-SRV-INST       2  Service and other unique instance (krbtgt)
-      NT-SRV-HST        3  Service with host name as instance (telnet, rcommands)
-      NT-SRV-XHST       4  Service with host as remaining components
-      NT-UID            5  Unique ID
-      NT-X500-PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
-      NT-SMTP-NAME      7  Name in form of SMTP email name (e.g. user@foo.com)
-      NT-ENTERPRISE    10   Enterprise name - may be mapped to principal name
-
-      When a name implies no information other than its uniqueness at a
-      particular time the name type PRINCIPAL SHOULD be used. The
-      principal name type SHOULD be used for users, and it might also be
-      used for a unique server. If the name is a unique machine
-      generated ID that is guaranteed never to be reassigned then the
-      name type of UID SHOULD be used (note that it is generally a bad
-      idea to reassign names of any type since stale entries might
-      remain in access control lists).
-
-      If the first component of a name identifies a service and the
-      remaining components identify an instance of the service in a
-      server specified manner, then the name type of SRV-INST SHOULD be
-      used. An example of this name type is the Kerberos ticket-granting
-      service whose name has a first component of krbtgt and a second
-      component identifying the realm for which the ticket is valid.
-
-      If the first component of a name identifies a service and there is
-      a single component following the service name identifying the
-      instance as the host on which the server is running, then the name
-      type SRV-HST SHOULD be used. This type is typically used for
-      Internet services such as telnet and the Berkeley R commands. If
-      the separate components of the host name appear as successive
-      components following the name of the service, then the name type
-      SRV-XHST SHOULD be used. This type might be used to identify
-      servers on hosts with X.500 names where the slash (/) might
-      otherwise be ambiguous.
-
-
-
-February 2004                                                 [Page 100]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      A name type of NT-X500-PRINCIPAL SHOULD be used when a name from
-      an X.509 certificate is translated into a Kerberos name. The
-      encoding of the X.509 name as a Kerberos principal shall conform
-      to the encoding rules specified in RFC 2253.
-
-      A name type of SMTP allows a name to be of a form that resembles a
-      SMTP email name. This name, including an "@" and a domain name, is
-      used as the one component of the principal name.
-
-      A name type of UNKNOWN SHOULD be used when the form of the name is
-      not known. When comparing names, a name of type UNKNOWN will match
-      principals authenticated with names of any type. A principal
-      authenticated with a name of type UNKNOWN, however, will only
-      match other names of type UNKNOWN.
-
-      Names of any type with an initial component of 'krbtgt' are
-      reserved for the Kerberos ticket granting service. See section 7.3
-      for the form of such names.
-
-6.2.1. Name of server principals
-
-      The principal identifier for a server on a host will generally be
-      composed of two parts: (1) the realm of the KDC with which the
-      server is registered, and (2) a two-component name of type NT-SRV-
-      HST if the host name is an Internet domain name or a multi-
-      component name of type NT-SRV-XHST if the name of the host is of a
-      form such as X.500 that allows slash (/) separators. The first
-      component of the two- or multi-component name will identify the
-      service and the latter components will identify the host. Where
-      the name of the host is not case sensitive (for example, with
-      Internet domain names) the name of the host MUST be lower case. If
-      specified by the application protocol for services such as telnet
-      and the Berkeley R commands which run with system privileges, the
-      first component MAY be the string 'host' instead of a service
-      specific identifier.
-
-7. Constants and other defined values
-
-7.1. Host address types
-
-      All negative values for the host address type are reserved for
-      local use.  All non-negative values are reserved for officially
-      assigned type fields and interpretations.
-
-   Internet (IPv4) Addresses
-
-      Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded
-      in MSB order. The IPv4 loopback address SHOULD NOT appear in a
-
-
-
-February 2004                                                 [Page 101]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      Kerberos packet. The type of IPv4 addresses is two (2).
-
-   Internet (IPv6) Addresses
-
-      IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities,
-      encoded in MSB order. The type of IPv6 addresses is twenty-four
-      (24). The following addresses MUST NOT appear in any Kerberos
-      packet:
-
-         *  the Unspecified Address
-         *  the Loopback Address
-         *  Link-Local addresses
-
-      IPv4-mapped IPv6 addresses MUST be represented as addresses of
-      type 2.
-
-   DECnet Phase IV addresses
-
-      DECnet Phase IV addresses are 16-bit addresses, encoded in LSB
-      order. The type of DECnet Phase IV addresses is twelve (12).
-
-   Netbios addresses
-
-      Netbios addresses are 16-octet addresses typically composed of 1
-      to 15 alphanumeric characters and padded with the US-ASCII SPC
-      character (code 32).  The 16th octet MUST be the US-ASCII NUL
-      character (code 0).  The type of Netbios addresses is twenty (20).
-
-   Directional Addresses
-
-      In many environments, including the sender address in KRB_SAFE and
-      KRB_PRIV messages is undesirable because the addresses may be
-      changed in transport by network address translators. However, if
-      these addresses are removed, the messages may be subject to a
-      reflection attack in which a message is reflected back to its
-      originator. The directional address type provides a way to avoid
-      transport addresses and reflection attacks. Directional addresses
-      are encoded as four byte unsigned integers in network byte order.
-      If the message is originated by the party sending the original
-      KRB_AP_REQ message, then an address of 0 SHOULD be used. If the
-      message is originated by the party to whom that KRB_AP_REQ was
-      sent, then the address 1 SHOULD be used. Applications involving
-      multiple parties can specify the use of other addresses.
-
-      Directional addresses MUST only be used for the sender address
-      field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used
-      as a ticket address or in a KRB_AP_REQ message. This address type
-      SHOULD only be used in situations where the sending party knows
-
-
-
-February 2004                                                 [Page 102]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      that the receiving party supports the address type. This generally
-      means that directional addresses may only be used when the
-      application protocol requires their support. Directional addresses
-      are type (3).
-
-7.2. KDC messaging - IP Transports
-
-      Kerberos defines two IP transport mechanisms for communication
-      between clients and servers: UDP/IP and TCP/IP.
-
-7.2.1. UDP/IP transport
-
-      Kerberos servers (KDCs) supporting IP transports MUST accept UDP
-      requests and SHOULD listen for such requests on port 88 (decimal)
-      unless specifically configured to listen on an alternative UDP
-      port. Alternate ports MAY be used when running multiple KDCs for
-      multiple realms on the same host.
-
-      Kerberos clients supporting IP transports SHOULD support the
-      sending of UDP requests. Clients SHOULD use KDC discovery [7.2.3]
-      to identify the IP address and port to which they will send their
-      request.
-
-      When contacting a KDC for a KRB_KDC_REQ request using UDP/IP
-      transport, the client shall send a UDP datagram containing only an
-      encoding of the request to the KDC. The KDC will respond with a
-      reply datagram containing only an encoding of the reply message
-      (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at the
-      sender's IP address. The response to a request made through UDP/IP
-      transport MUST also use UDP/IP transport. If the response can not
-      be handled using UDP (for example because it is too large), the
-      KDC MUST return KRB_ERR_RESPONSE_TOO_BIG, forcing the client to
-      retry the request using the TCP transport.
-
-7.2.2. TCP/IP transport
-
-      Kerberos servers (KDCs) supporting IP transports MUST accept TCP
-      requests and SHOULD listen for such requests on port 88 (decimal)
-      unless specifically configured to listen on an alternate TCP port.
-      Alternate ports MAY be used when running multiple KDCs for
-      multiple realms on the same host.
-
-      Clients MUST support the sending of TCP requests, but MAY choose
-      to initially try a request using the UDP transport. Clients SHOULD
-      use KDC discovery [7.2.3] to identify the IP address and port to
-      which they will send their request.
-
-      Implementation note: Some extensions to the Kerberos protocol will
-
-
-
-February 2004                                                 [Page 103]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      not succeed if any client or KDC not supporting the TCP transport
-      is involved.  Implementations of RFC 1510 were not required to
-      support TCP/IP transports.
-
-      When the KRB_KDC_REQ message is sent to the KDC over a TCP stream,
-      the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned
-      to the client on the same TCP stream that was established for the
-      request. The KDC MAY close the TCP stream after sending a
-      response, but MAY leave the stream open for a reasonable period of
-      time if it expects a followup. Care must be taken in managing
-      TCP/IP connections on the KDC to prevent denial of service attacks
-      based on the number of open TCP/IP connections.
-
-      The client MUST be prepared to have the stream closed by the KDC
-      at anytime after the receipt of a response. A stream closure
-      SHOULD NOT be treated as a fatal error. Instead, if multiple
-      exchanges are required (e.g., certain forms of pre-authentication)
-      the client may need to establish a new connection when it is ready
-      to send subsequent messages. A client MAY close the stream after
-      receiving a response, and SHOULD close the stream if it does not
-      expect to send followup messages.
-
-      A client MAY send multiple requests before receiving responses,
-      though it must be prepared to handle the connection being closed
-      after the first response.
-
-      Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR)
-      sent over the TCP stream is preceded by the length of the request
-      as 4 octets in network byte order. The high bit of the length is
-      reserved for future expansion and MUST currently be set to zero.
-      If a KDC that does not understand how to interpret a set high bit
-      of the length encoding receives a request with the high order bit
-      of the length set, it MUST return a KRB-ERROR message with the
-      error KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream.
-
-      If multiple requests are sent over a single TCP connection, and
-      the KDC sends multiple responses, the KDC is not required to send
-      the responses in the order of the corresponding requests. This may
-      permit some implementations to send each response as soon as it is
-      ready even if earlier requests are still being processed (for
-      example, waiting for a response from an external device or
-      database).
-
-7.2.3. KDC Discovery on IP Networks
-
-      Kerberos client implementations MUST provide a means for the
-      client to determine the location of the Kerberos Key Distribution
-      Centers (KDCs).  Traditionally, Kerberos implementations have
-
-
-
-February 2004                                                 [Page 104]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      stored such configuration information in a file on each client
-      machine. Experience has shown this method of storing configuration
-      information presents problems with out-of-date information and
-      scaling problems, especially when using cross-realm
-      authentication. This section describes a method for using the
-      Domain Name System [RFC 1035] for storing KDC location
-      information.
-
-7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names
-
-      In Kerberos, realm names are case sensitive. While it is strongly
-      encouraged that all realm names be all upper case this
-      recommendation has not been adopted by all sites. Some sites use
-      all lower case names and other use mixed case. DNS on the other
-      hand is case insensitive for queries. Since the realm names
-      "MYREALM", "myrealm", and "MyRealm" are all different, but resolve
-      the same in the domain name system, it is necessary that only one
-      of the possible combinations of upper and lower case characters be
-      used in realm names.
-
-7.2.3.2. Specifying KDC Location information with DNS SRV records
-
-      KDC location information is to be stored using the DNS SRV RR [RFC
-      2782].  The format of this RR is as follows:
-
-         _Service._Proto.Realm TTL Class SRV Priority Weight Port Target
-
-      The Service name for Kerberos is always "kerberos".
-
-      The Proto can be one of "udp", "tcp". If these SRV records are to
-      be used, both "udp" and "tcp" records MUST be specified for all
-      KDC deployments.
-
-      The Realm is the Kerberos realm that this record corresponds to.
-      The realm MUST be a domain style realm name.
-
-      TTL, Class, SRV, Priority, Weight, and Target have the standard
-      meaning as defined in RFC 2782.
-
-      As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
-      records SHOULD be the value assigned to "kerberos" by the Internet
-      Assigned Number Authority: 88 (decimal) unless the KDC is
-      configured to listen on an alternate TCP port.
-
-      Implementation note: Many existing client implementations do not
-      support KDC Discovery and are configured to send requests to the
-      IANA assigned port (88 decimal), so it is strongly recommended
-      that KDCs be configured to listen on that port.
-
-
-
-February 2004                                                 [Page 105]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks
-
-      These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
-      Kerberos servers, kdc1.example.com and kdc2.example.com. Queries
-      should be directed to kdc1.example.com first as per the specified
-      priority. Weights are not used in these sample records.
-
-        _kerberos._udp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
-        _kerberos._udp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
-        _kerberos._tcp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
-        _kerberos._tcp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
-
-7.3. Name of the TGS
-
-      The principal identifier of the ticket-granting service shall be
-      composed of three parts: (1) the realm of the KDC issuing the TGS
-      ticket (2) a two-part name of type NT-SRV-INST, with the first
-      part "krbtgt" and the second part the name of the realm which will
-      accept the ticket-granting ticket. For example, a ticket-granting
-      ticket issued by the ATHENA.MIT.EDU realm to be used to get
-      tickets from the ATHENA.MIT.EDU KDC has a principal identifier of
-      "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A
-      ticket-granting ticket issued by the ATHENA.MIT.EDU realm to be
-      used to get tickets from the MIT.EDU realm has a principal
-      identifier of "ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU")
-      (name).
-
-7.4. OID arc for KerberosV5
-
-      This OID MAY be used to identify Kerberos protocol messages
-      encapsulated in other protocols. It also designates the OID arc
-      for KerberosV5-related OIDs assigned by future IETF action.
-      Implementation note:: RFC 1510 had an incorrect value (5) for
-      "dod" in its OID.
-
-      id-krb5         OBJECT IDENTIFIER ::= {
-              iso(1) identified-organization(3) dod(6) internet(1)
-              security(5) kerberosV5(2)
-      }
-
-
-      Assignment of OIDs beneath the id-krb5 arc must be obtained by
-      contacting the registrar for the id-krb5 arc, or its designee.  At
-      the time of the issuance of this RFC, such registrations can be
-      obtained by contacting krb5-oid-registrar@mit.edu.
-
-7.5. Protocol constants and associated values
-
-
-
-
-February 2004                                                 [Page 106]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      The following tables list constants used in the protocol and
-      define their meanings. Ranges are specified in the "specification"
-      section that limit the values of constants for which values are
-      defined here. This allows implementations to make assumptions
-      about the maximum values that will be received for these
-      constants. Implementation receiving values outside the range
-      specified in the "specification" section MAY reject the request,
-      but they MUST recover cleanly.
-
-7.5.1. Key usage numbers
-
-      The encryption and checksum specifications in [@KCRYPTO] require
-      as input a "key usage number", to alter the encryption key used in
-      any specific message, to make certain types of cryptographic
-      attack more difficult. These are the key usage values assigned in
-      this document:
-
-              1.          AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted
-                          with the client key (section 5.2.7.2)
-              2.          AS-REP Ticket and TGS-REP Ticket (includes TGS session
-                          key or application session key), encrypted with the
-                          service key (section 5.3)
-              3.          AS-REP encrypted part (includes TGS session key or
-                          application session key), encrypted with the client key
-                          (section 5.4.2)
-              4.          TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with
-                          the TGS session key (section 5.4.1)
-              5.          TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with
-                          the TGS authenticator subkey (section 5.4.1)
-              6.          TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
-                          keyed with the TGS session key (sections 5.5.1)
-              7.          TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator
-                          (includes TGS authenticator subkey), encrypted with the
-                          TGS session key (section 5.5.1)
-              8.          TGS-REP encrypted part (includes application session
-                          key), encrypted with the TGS session key (section
-                          5.4.2)
-              9.          TGS-REP encrypted part (includes application session
-                          key), encrypted with the TGS authenticator subkey
-                          (section 5.4.2)
-              10.         AP-REQ Authenticator cksum, keyed with the application
-                          session key (section 5.5.1)
-              11.         AP-REQ Authenticator (includes application
-                          authenticator subkey), encrypted with the application
-                          session key (section 5.5.1)
-              12.         AP-REP encrypted part (includes application session
-                          subkey), encrypted with the application session key
-                          (section 5.5.2)
-
-
-
-February 2004                                                 [Page 107]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-              13.         KRB-PRIV encrypted part, encrypted with a key chosen by
-                          the application (section 5.7.1)
-              14.         KRB-CRED encrypted part, encrypted with a key chosen by
-                          the application (section 5.8.1)
-              15.         KRB-SAFE cksum, keyed with a key chosen by the
-                          application (section 5.6.1)
-              19.         AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4)
-            22-25.        Reserved for use in GSSAPI mechanisms derived from RFC
-                          1964. (raeburn/MIT)
-       16-18,20-21,26-511. Reserved for future use in Kerberos and related
-                          protocols.
-           512-1023.      Reserved for uses internal to a Kerberos
-                          implementation.
-            1024.         Encryption for application use in protocols that
-                          do not specify key usage values
-            1025.         Checksums for application use in protocols that
-                          do not specify key usage values
-          1026-2047.      Reserved for application use.
-
-
-7.5.2. PreAuthentication Data Types
-
-      padata and data types           padata-type value  comment
-
-      PA-TGS-REQ                      1
-      PA-ENC-TIMESTAMP                2
-      PA-PW-SALT                      3
-      [reserved]                      4
-      PA-ENC-UNIX-TIME                5        (deprecated)
-      PA-SANDIA-SECUREID              6
-      PA-SESAME                       7
-      PA-OSF-DCE                      8
-      PA-CYBERSAFE-SECUREID           9
-      PA-AFS3-SALT                    10
-      PA-ETYPE-INFO                   11
-      PA-SAM-CHALLENGE                12       (sam/otp)
-      PA-SAM-RESPONSE                 13       (sam/otp)
-      PA-PK-AS-REQ                    14       (pkinit)
-      PA-PK-AS-REP                    15       (pkinit)
-      PA-ETYPE-INFO2                  19       (replaces pa-etype-info)
-      PA-USE-SPECIFIED-KVNO           20
-      PA-SAM-REDIRECT                 21       (sam/otp)
-      PA-GET-FROM-TYPED-DATA          22       (embedded in typed data)
-      TD-PADATA                       22       (embeds padata)
-      PA-SAM-ETYPE-INFO               23       (sam/otp)
-      PA-ALT-PRINC                    24       (crawdad@fnal.gov)
-      PA-SAM-CHALLENGE2               30       (kenh@pobox.com)
-      PA-SAM-RESPONSE2                31       (kenh@pobox.com)
-
-
-
-February 2004                                                 [Page 108]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      PA-EXTRA-TGT                    41       Reserved extra TGT
-      TD-PKINIT-CMS-CERTIFICATES      101      CertificateSet from CMS
-      TD-KRB-PRINCIPAL                102      PrincipalName
-      TD-KRB-REALM                    103      Realm
-      TD-TRUSTED-CERTIFIERS           104      from PKINIT
-      TD-CERTIFICATE-INDEX            105      from PKINIT
-      TD-APP-DEFINED-ERROR            106      application specific
-      TD-REQ-NONCE                    107      INTEGER
-      TD-REQ-SEQ                      108      INTEGER
-      PA-PAC-REQUEST                  128      (jbrezak@exchange.microsoft.com)
-
-7.5.3. Address Types
-
-      Address type                   value
-
-      IPv4                             2
-      Directional                      3
-      ChaosNet                         5
-      XNS                              6
-      ISO                              7
-      DECNET Phase IV                 12
-      AppleTalk DDP                   16
-      NetBios                         20
-      IPv6                            24
-
-7.5.4. Authorization Data Types
-
-      authorization data type         ad-type value
-      AD-IF-RELEVANT                     1
-      AD-INTENDED-FOR-SERVER             2
-      AD-INTENDED-FOR-APPLICATION-CLASS  3
-      AD-KDC-ISSUED                      4
-      AD-AND-OR                          5
-      AD-MANDATORY-TICKET-EXTENSIONS     6
-      AD-IN-TICKET-EXTENSIONS            7
-      AD-MANDATORY-FOR-KDC               8
-      reserved values                    9-63
-      OSF-DCE                            64
-      SESAME                             65
-      AD-OSF-DCE-PKI-CERTID              66         (hemsath@us.ibm.com)
-      AD-WIN2K-PAC                      128         (jbrezak@exchange.microsoft.com)
-
-7.5.5. Transited Encoding Types
-
-      transited encoding type         tr-type value
-      DOMAIN-X500-COMPRESS            1
-      reserved values                 all others
-
-
-
-
-February 2004                                                 [Page 109]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-7.5.6. Protocol Version Number
-
-      Label               Value   Meaning or MIT code
-
-      pvno                    5   current Kerberos protocol version number
-
-7.5.7. Kerberos Message Types
-
-      message types
-
-      KRB_AS_REQ             10   Request for initial authentication
-      KRB_AS_REP             11   Response to KRB_AS_REQ request
-      KRB_TGS_REQ            12   Request for authentication based on TGT
-      KRB_TGS_REP            13   Response to KRB_TGS_REQ request
-      KRB_AP_REQ             14   application request to server
-      KRB_AP_REP             15   Response to KRB_AP_REQ_MUTUAL
-      KRB_RESERVED16         16   Reserved for user-to-user krb_tgt_request
-      KRB_RESERVED17         17   Reserved for user-to-user krb_tgt_reply
-      KRB_SAFE               20   Safe (checksummed) application message
-      KRB_PRIV               21   Private (encrypted) application message
-      KRB_CRED               22   Private (encrypted) message to forward credentials
-      KRB_ERROR              30   Error response
-
-7.5.8. Name Types
-
-      name types
-
-      KRB_NT_UNKNOWN        0  Name type not known
-      KRB_NT_PRINCIPAL      1  Just the name of the principal as in DCE, or for users
-      KRB_NT_SRV_INST       2  Service and other unique instance (krbtgt)
-      KRB_NT_SRV_HST        3  Service with host name as instance (telnet, rcommands)
-      KRB_NT_SRV_XHST       4  Service with host as remaining components
-      KRB_NT_UID            5  Unique ID
-      KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
-      KRB_NT_SMTP_NAME      7  Name in form of SMTP email name (e.g. user@foo.com)
-      KRB_NT_ENTERPRISE    10   Enterprise name - may be mapped to principal name
-
-7.5.9. Error Codes
-
-      error codes
-
-      KDC_ERR_NONE                    0   No error
-      KDC_ERR_NAME_EXP                1   Client's entry in database has expired
-      KDC_ERR_SERVICE_EXP             2   Server's entry in database has expired
-      KDC_ERR_BAD_PVNO                3   Requested protocol version number
-                                             not supported
-      KDC_ERR_C_OLD_MAST_KVNO         4   Client's key encrypted in old master key
-      KDC_ERR_S_OLD_MAST_KVNO         5   Server's key encrypted in old master key
-
-
-
-February 2004                                                 [Page 110]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      KDC_ERR_C_PRINCIPAL_UNKNOWN     6   Client not found in Kerberos database
-      KDC_ERR_S_PRINCIPAL_UNKNOWN     7   Server not found in Kerberos database
-      KDC_ERR_PRINCIPAL_NOT_UNIQUE    8   Multiple principal entries in database
-      KDC_ERR_NULL_KEY                9   The client or server has a null key
-      KDC_ERR_CANNOT_POSTDATE        10   Ticket not eligible for postdating
-      KDC_ERR_NEVER_VALID            11   Requested start time is later than end time
-      KDC_ERR_POLICY                 12   KDC policy rejects request
-      KDC_ERR_BADOPTION              13   KDC cannot accommodate requested option
-      KDC_ERR_ETYPE_NOSUPP           14   KDC has no support for encryption type
-      KDC_ERR_SUMTYPE_NOSUPP         15   KDC has no support for checksum type
-      KDC_ERR_PADATA_TYPE_NOSUPP     16   KDC has no support for padata type
-      KDC_ERR_TRTYPE_NOSUPP          17   KDC has no support for transited type
-      KDC_ERR_CLIENT_REVOKED         18   Clients credentials have been revoked
-      KDC_ERR_SERVICE_REVOKED        19   Credentials for server have been revoked
-      KDC_ERR_TGT_REVOKED            20   TGT has been revoked
-      KDC_ERR_CLIENT_NOTYET          21   Client not yet valid - try again later
-      KDC_ERR_SERVICE_NOTYET         22   Server not yet valid - try again later
-      KDC_ERR_KEY_EXPIRED            23   Password has expired
-                                                - change password to reset
-      KDC_ERR_PREAUTH_FAILED         24   Pre-authentication information was invalid
-      KDC_ERR_PREAUTH_REQUIRED       25   Additional pre-authenticationrequired
-      KDC_ERR_SERVER_NOMATCH         26   Requested server and ticket don't match
-      KDC_ERR_MUST_USE_USER2USER     27   Server principal valid for user2user only
-      KDC_ERR_PATH_NOT_ACCPETED      28   KDC Policy rejects transited path
-      KDC_ERR_SVC_UNAVAILABLE        29   A service is not available
-      KRB_AP_ERR_BAD_INTEGRITY       31   Integrity check on decrypted field failed
-      KRB_AP_ERR_TKT_EXPIRED         32   Ticket expired
-      KRB_AP_ERR_TKT_NYV             33   Ticket not yet valid
-      KRB_AP_ERR_REPEAT              34   Request is a replay
-      KRB_AP_ERR_NOT_US              35   The ticket isn't for us
-      KRB_AP_ERR_BADMATCH            36   Ticket and authenticator don't match
-      KRB_AP_ERR_SKEW                37   Clock skew too great
-      KRB_AP_ERR_BADADDR             38   Incorrect net address
-      KRB_AP_ERR_BADVERSION          39   Protocol version mismatch
-      KRB_AP_ERR_MSG_TYPE            40   Invalid msg type
-      KRB_AP_ERR_MODIFIED            41   Message stream modified
-      KRB_AP_ERR_BADORDER            42   Message out of order
-      KRB_AP_ERR_BADKEYVER           44   Specified version of key is not available
-      KRB_AP_ERR_NOKEY               45   Service key not available
-      KRB_AP_ERR_MUT_FAIL            46   Mutual authentication failed
-      KRB_AP_ERR_BADDIRECTION        47   Incorrect message direction
-      KRB_AP_ERR_METHOD              48   Alternative authentication method required
-      KRB_AP_ERR_BADSEQ              49   Incorrect sequence number in message
-      KRB_AP_ERR_INAPP_CKSUM         50   Inappropriate type of checksum in message
-      KRB_AP_PATH_NOT_ACCEPTED       51   Policy rejects transited path
-      KRB_ERR_RESPONSE_TOO_BIG       52   Response too big for UDP, retry with TCP
-      KRB_ERR_GENERIC                60   Generic error (description in e-text)
-      KRB_ERR_FIELD_TOOLONG          61   Field is too long for this implementation
-
-
-
-February 2004                                                 [Page 111]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      KDC_ERROR_CLIENT_NOT_TRUSTED      62 Reserved for PKINIT
-      KDC_ERROR_KDC_NOT_TRUSTED         63 Reserved for PKINIT
-      KDC_ERROR_INVALID_SIG             64 Reserved for PKINIT
-      KDC_ERR_KEY_TOO_WEAK              65 Reserved for PKINIT
-      KDC_ERR_CERTIFICATE_MISMATCH      66 Reserved for PKINIT
-      KRB_AP_ERR_NO_TGT                 67 No TGT available to validate USER-TO-USER
-      KDC_ERR_WRONG_REALM               68 USER-TO-USER TGT issued different KDC
-      KRB_AP_ERR_USER_TO_USER_REQUIRED  69 Ticket must be for USER-TO-USER
-      KDC_ERR_CANT_VERIFY_CERTIFICATE   70 Reserved for PKINIT
-      KDC_ERR_INVALID_CERTIFICATE             71 Reserved for PKINIT
-      KDC_ERR_REVOKED_CERTIFICATE             72 Reserved for PKINIT
-      KDC_ERR_REVOCATION_STATUS_UNKNOWN       73 Reserved for PKINIT
-      KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74 Reserved for PKINIT
-      KDC_ERR_CLIENT_NAME_MISMATCH            75 Reserved for PKINIT
-      KDC_ERR_KDC_NAME_MISMATCH               76 Reserved for PKINIT
-
-8. Interoperability requirements
-
-      Version 5 of the Kerberos protocol supports a myriad of options.
-      Among these are multiple encryption and checksum types,
-      alternative encoding schemes for the transited field, optional
-      mechanisms for pre-authentication, the handling of tickets with no
-      addresses, options for mutual authentication, user-to-user
-      authentication, support for proxies, forwarding, postdating, and
-      renewing tickets, the format of realm names, and the handling of
-      authorization data.
-
-      In order to ensure the interoperability of realms, it is necessary
-      to define a minimal configuration which must be supported by all
-      implementations. This minimal configuration is subject to change
-      as technology does. For example, if at some later date it is
-      discovered that one of the required encryption or checksum
-      algorithms is not secure, it will be replaced.
-
-8.1. Specification 2
-
-      This section defines the second specification of these options.
-      Implementations which are configured in this way can be said to
-      support Kerberos Version 5 Specification 2 (5.2). Specification 1
-      (deprecated) may be found in RFC1510.
-
-   Transport
-
-      TCP/IP and UDP/IP transport MUST be supported by clients and KDCs
-      claiming conformance to specification 2.
-
-   Encryption and checksum methods
-
-
-
-
-February 2004                                                 [Page 112]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      The following encryption and checksum mechanisms MUST be
-      supported.
-
-      Encryption: AES256-CTS-HMAC-SHA1-96
-      Checksums: HMAC-SHA1-96-AES256
-
-      Implementations SHOULD support other mechanisms as well, but the
-      additional mechanisms may only be used when communicating with
-      principals known to also support them. The mechanisms that SHOULD
-      be supported are:
-
-      Encryption:  DES-CBC-MD5, DES3-CBC-SHA1-KD
-      Checksums:   DES-MD5, HMAC-SHA1-DES3-KD
-
-      Implementations MAY support other mechanisms as well, but the
-      additional mechanisms may only be used when communicating with
-      principals known to also support them.
-
-      Implementation note: earlier implementations of Kerberos generate
-      messages using the CRC-32, RSA-MD5 checksum methods. For
-      interoperability with these earlier releases implementors MAY
-      consider supporting these checksum methods but should carefully
-      analyze the security impplications to limit the situations within
-      which these methods are accepted.
-
-   Realm Names
-
-      All implementations MUST understand hierarchical realms in both
-      the Internet Domain and the X.500 style. When a ticket-granting
-      ticket for an unknown realm is requested, the KDC MUST be able to
-      determine the names of the intermediate realms between the KDCs
-      realm and the requested realm.
-
-   Transited field encoding
-
-      DOMAIN-X500-COMPRESS (described in section 3.3.3.2) MUST be
-      supported.  Alternative encodings MAY be supported, but they may
-      be used only when that encoding is supported by ALL intermediate
-      realms.
-
-   Pre-authentication methods
-
-      The TGS-REQ method MUST be supported. The TGS-REQ method is not
-      used on the initial request. The PA-ENC-TIMESTAMP method MUST be
-      supported by clients but whether it is enabled by default MAY be
-      determined on a realm by realm basis. If not used in the initial
-      request and the error KDC_ERR_PREAUTH_REQUIRED is returned
-      specifying PA-ENC-TIMESTAMP as an acceptable method, the client
-
-
-
-February 2004                                                 [Page 113]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre-
-      authentication method. Servers need not support the PA-ENC-
-      TIMESTAMP method, but if not supported the server SHOULD ignore
-      the presence of PA-ENC-TIMESTAMP pre-authentication in a request.
-
-      The ETYPE-INFO2 method MUST be supported; this method is used to
-      communicate the set of supported encryption types, and
-      corresponding salt and string to key paramters. The ETYPE-INFO
-      method SHOULD be supported for interoperability with older
-      implementation.
-
-   Mutual authentication
-
-      Mutual authentication (via the KRB_AP_REP message) MUST be
-      supported.
-
-   Ticket addresses and flags
-
-      All KDCs MUST pass through tickets that carry no addresses (i.e.
-      if a TGT contains no addresses, the KDC will return derivative
-      tickets).  Implementations SHOULD default to requesting
-      addressless tickets as this significantly increases
-      interoperability with network address translation.  In some cases
-      realms or application servers MAY require that tickets have an
-      address.
-
-      Implementations SHOULD accept directional address type for the
-      KRB_SAFE and KRB_PRIV message and SHOULD include directional
-      addresses in these messages when other address types are not
-      available.
-
-      Proxies and forwarded tickets MUST be supported. Individual realms
-      and application servers can set their own policy on when such
-      tickets will be accepted.
-
-      All implementations MUST recognize renewable and postdated
-      tickets, but need not actually implement them. If these options
-      are not supported, the starttime and endtime in the ticket shall
-      specify a ticket's entire useful life. When a postdated ticket is
-      decoded by a server, all implementations shall make the presence
-      of the postdated flag visible to the calling server.
-
-   User-to-user authentication
-
-      Support for user-to-user authentication (via the ENC-TKT-IN-SKEY
-      KDC option) MUST be provided by implementations, but individual
-      realms MAY decide as a matter of policy to reject such requests on
-      a per-principal or realm-wide basis.
-
-
-
-February 2004                                                 [Page 114]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-   Authorization data
-
-      Implementations MUST pass all authorization data subfields from
-      ticket-granting tickets to any derivative tickets unless directed
-      to suppress a subfield as part of the definition of that
-      registered subfield type (it is never incorrect to pass on a
-      subfield, and no registered subfield types presently specify
-      suppression at the KDC).
-
-      Implementations MUST make the contents of any authorization data
-      subfields available to the server when a ticket is used.
-      Implementations are not required to allow clients to specify the
-      contents of the authorization data fields.
-
-   Constant ranges
-
-      All protocol constants are constrained to 32 bit (signed) values
-      unless further constrained by the protocol definition. This limit
-      is provided to allow implementations to make assumptions about the
-      maximum values that will be received for these constants.
-      Implementation receiving values outside this range MAY reject the
-      request, but they MUST recover cleanly.
-
-8.2. Recommended KDC values
-
-      Following is a list of recommended values for a KDC configuration.
-
-      minimum lifetime              5 minutes
-      maximum renewable lifetime    1 week
-      maximum ticket lifetime       1 day
-      acceptable clock skew         5 minutes
-      empty addresses               Allowed.
-      proxiable, etc.               Allowed.
-
-9. IANA considerations
-
-      Section 7 of this document specifies protocol constants and other
-      defined values required for the interoperability of multiple
-      implementations. Until otherwise specified in a subsequent RFC, or
-      upon disbanding of the Kerberos working group, allocations of
-      additional protocol constants and other defined values required
-      for extensions to the Kerberos protocol will be administered by
-      the kerberos working group.  Following the recomendations outlined
-      in [RFC 2434], guidance is provided to the IANA as follows:
-
-      "reserved" realm name types in section 6.1 and "other" realm types
-      except those beginning with "X-" or "x-" will not be registered
-      without IETF standards action, at which point guidlines for
-
-
-
-February 2004                                                 [Page 115]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      further assignment will be specified.  Realm name types beginning
-      with "X-" or "x-" are for private use.
-
-      For host address types described in section 7.1, negative values
-      are for private use.  Assignment of additional positive numbers is
-      subject to review by the kerberos working group or other expert
-      review.
-
-      Additional key usage numbers as defined in section 7.5.1 will be
-      assigned subject to review by the kerberos working group or other
-      expert review.
-
-      Additional preauthentciation data type values as defined in
-      section 7.5.2 will be assigned subject to review by the kerberos
-      working group or other expert review.
-
-      Additional Authorization Data Types as defined in section 7.5.4
-      will be assigned subject to review by the kerberos working group
-      or other expert review.  Although it is anticipated that there may
-      be significant demand for private use types, provision is
-      intentionaly not made for a private use portion of the namespace
-      because conficts between privately assigned values coule have
-      detrimental security implications.
-
-      Additional Transited Encoding Types as defined in section 7.5.5
-      present special concerns for interoperability with existing
-      implementations.  As such, such assignments will only be made by
-      standards action, except that the Kerberos working group or
-      another other working group with competent jurisdiction may make
-      preliminary assignments for documents which are moving through the
-      standards process.
-
-      Additional Kerberos Message Types as described in section 7.5.7
-      will be assigned subject to review by the kerberos working group
-      or other expert review.
-
-      Additional Name Types as described in section 7.5.8 will be
-      assigned subject to review by the kerberos working group or other
-      expert review.
-
-      Additional error codes described in section 7.5.9 will be assigned
-      subject to review by the kerberos working group or other expert
-      review.
-
-10. Security Considerations
-
-      As an authentication service, Kerberos provides a means of
-      verifying the identity of principals on a network. Kerberos does
-
-
-
-February 2004                                                 [Page 116]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      not, by itself, provide authorization. Applications should not
-      accept the issuance of a service ticket by the Kerberos server as
-      granting authority to use the service, since such applications may
-      become vulnerable to the bypass of this authorization check in an
-      environment if they inter-operate with other KDCs or where other
-      options for application authentication are provided.
-
-      Denial of service attacks are not solved with Kerberos. There are
-      places in the protocols where an intruder can prevent an
-      application from participating in the proper authentication steps.
-      Because authentication is a required step for the use of many
-      services, successful denial of service attacks on a Kerberos
-      server might result in the denial of other network services that
-      rely on Kerberos for authentication. Kerberos is vulnerable to
-      many kinds of denial of service attacks: denial of service attacks
-      on the network which would prevent clients from contacting the
-      KDC; denial of service attacks on the domain name system which
-      could prevent a client from finding the IP address of the Kerberos
-      server; and denial of service attack by overloading the Kerberos
-      KDC itself with repeated requests.
-
-      Interoperability conflicts caused by incompatible character-set
-      usage (see 5.2.1) can result in denial of service for clients that
-      utilize character-sets in Kerberos strings other than those stored
-      in the KDC database.
-
-      Authentication servers maintain a database of principals (i.e.,
-      users and servers) and their secret keys. The security of the
-      authentication server machines is critical. The breach of security
-      of an authentication server will compromise the security of all
-      servers that rely upon the compromised KDC, and will compromise
-      the authentication of any principals registered in the realm of
-      the compromised KDC.
-
-      Principals must keep their secret keys secret. If an intruder
-      somehow steals a principal's key, it will be able to masquerade as
-      that principal or impersonate any server to the legitimate
-      principal.
-
-      Password guessing attacks are not solved by Kerberos. If a user
-      chooses a poor password, it is possible for an attacker to
-      successfully mount an off-line dictionary attack by repeatedly
-      attempting to decrypt, with successive entries from a dictionary,
-      messages obtained which are encrypted under a key derived from the
-      user's password.
-
-      Unless pre-authentication options are required by the policy of a
-      realm, the KDC will not know whether a request for authentication
-
-
-
-February 2004                                                 [Page 117]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      succeeds. An attacker can request a reply with credentials for any
-      principal. These credentials will likely not be of much use to the
-      attacker unless it knows the client's secret key, but the
-      availability of the response encrypted in the client's secret key
-      provides the attacker with ciphertext that may be used to mount
-      brute force or dictionary attacks to decrypt the credentials, by
-      guessing the user's password. For this reason it is strongly
-      encouraged that Kerberos realms require the use of pre-
-      authentication. Even with pre-authentication, attackers may try
-      brute force or dictionary attacks against credentials that are
-      observed by eavesdropping on the network.
-
-      Because a client can request a ticket for any server principal and
-      can attempt a brute force or dictionary attack against the server
-      principal's key using that ticket, it is strongly encouraged that
-      keys be randomly generated (rather than generated from passwords)
-      for any principals that are usable as the target principal for a
-      KRB_TGS_REQ or KRB_AS_REQ messages. [RFC1750]
-
-      Although the DES-CBC-MD5 encryption method and DES-MD5 checksum
-      methods are listed as SHOULD be implemented for backward
-      compatibility, the single DES encryption algorithm on which these
-      are based is weak and stronger algorithms should be used whenever
-      possible.
-
-      Each host on the network must have a clock which is loosely
-      synchronized to the time of the other hosts; this synchronization
-      is used to reduce the bookkeeping needs of application servers
-      when they do replay detection. The degree of "looseness" can be
-      configured on a per-server basis, but is typically on the order of
-      5 minutes. If the clocks are synchronized over the network, the
-      clock synchronization protocol MUST itself be secured from network
-      attackers.
-
-      Principal identifiers must not recycled on a short-term basis. A
-      typical mode of access control will use access control lists
-      (ACLs) to grant permissions to particular principals. If a stale
-      ACL entry remains for a deleted principal and the principal
-      identifier is reused, the new principal will inherit rights
-      specified in the stale ACL entry. By not reusing principal
-      identifiers, the danger of inadvertent access is removed.
-
-      Proper decryption of an KRB_AS_REP message from the KDC is not
-      sufficient for the host to verify the identity of the user; the
-      user and an attacker could cooperate to generate a KRB_AS_REP
-      format message which decrypts properly but is not from the proper
-      KDC. To authenticate a user logging on to a local system, the
-      credentials obtained in the AS exchange may first be used in a TGS
-
-
-
-February 2004                                                 [Page 118]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      exchange to obtain credentials for a local server. Those
-      credentials must then be verified by a local server through
-      successful completion of the Client/Server exchange.
-
-      Many RFC 1510 compliant implementations ignore unknown
-      authorization data elements. Depending on these implementations to
-      honor authorization data restrictions may create a security
-      weakness.
-
-      Kerberos credentials contain clear-text information identifying
-      the principals to which they apply. If privacy of this information
-      is needed, this exchange should itself be encapsulated in a
-      protocol providing for confidentiality on the exchange of these
-      credentials.
-
-      Applications must take care to protect communications subsequent
-      to authentication either by using the KRB_PRIV or KRB_SAFE
-      messages as appropriate, or by applying their own confidentiality
-      or integrity mechanisms on such communications. Completion of the
-      KRB_AP_REQ and KRB_AP_REP exchange without subsequent use of
-      confidentiality and integrity mechanisms provides only for
-      authentication of the parties to the communication and not
-      confidentiality and integrity of the subsequent communication.
-      Application applying confidentiality and integrity protection
-      mechanisms other than KRB_PRIV and KRB_SAFE must make sure that
-      the authentication step is appropriately linked with the protected
-      communication channel that is established by the application.
-
-      Unless the application server provides its own suitable means to
-      protect against replay (for example, a challenge-response sequence
-      initiated by the server after authentication, or use of a server-
-      generated encryption subkey), the server must utilize a replay
-      cache to remember any authenticator presented within the allowable
-      clock skew. All services sharing a key need to use the same replay
-      cache. If separate replay caches are used, then and authenticator
-      used with one such service could later be replayed to a different
-      service with the same service principal.
-
-      If a server loses track of authenticators presented within the
-      allowable clock skew, it must reject all requests until the clock
-      skew interval has passed, providing assurance that any lost or
-      replayed authenticators will fall outside the allowable clock skew
-      and can no longer be successfully replayed.
-
-      Implementations of Kerberos should not use untrusted directory
-      servers to determine the realm of a host. To allow such would
-      allow the compromise of the directory server to enable an attacker
-      to direct the client to accept authentication with the wrong
-
-
-
-February 2004                                                 [Page 119]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      principal (i.e. one with a similar name, but in a realm with which
-      the legitimate host was not registered).
-
-      Implementations of Kerberos must not use DNS to map one name to
-      another (canonicalize) to determine the host part of the principal
-      name with which one is to communicate.  To allow such
-      canonicalization would allow a compromise of the DNS to result in
-      a client obtaining credentials and correctly authenticating to the
-      wrong principal. Though the client will know who it is
-      communicating with, it will not be the principal with which it
-      intended to communicate.
-
-      If the Kerberos server returns a TGT for a 'closer' realm other
-      than the desired realm, the client may use local policy
-      configuration to verify that the authentication path used is an
-      acceptable one.  Alternatively, a client may choose its own
-      authentication path, rather than relying on the Kerberos server to
-      select one. In either case, any policy or configuration
-      information used to choose or validate authentication paths,
-      whether by the Kerberos server or client, must be obtained from a
-      trusted source.
-
-      The Kerberos protocol in its basic form does not provide perfect
-      forward secrecy for communications. If traffic has been recorded
-      by an eavesdropper, then messages encrypted using the KRB_PRIV
-      message, or messages encrypted using application specific
-      encryption under keys exchanged using Kerberos can be decrypted if
-      any of the user's, application server's, or KDC's key is
-      subsequently discovered. This is because the session key use to
-      encrypt such messages is transmitted over the network encrypted in
-      the key of the application server, and also encrypted under the
-      session key from the user's ticket-granting ticket when returned
-      to the user in the KRB_TGS_REP message. The session key from the
-      ticket-granting ticket was sent to the user in the KRB_AS_REP
-      message encrypted in the user's secret key, and embedded in the
-      ticket-granting ticket, which was encrypted in the key of the KDC.
-      Application requiring perfect forward secrecy must exchange keys
-      through mechanisms that provide such assurance, but may use
-      Kerberos for authentication of the encrypted channel established
-      through such other means.
-
-11. Author's Addresses
-
-
-          Clifford Neuman
-          Information Sciences Institute
-          University of Southern California
-          4676 Admiralty Way
-
-
-
-February 2004                                                 [Page 120]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-          Marina del Rey, CA 90292, USA
-          Email: bcn@isi.edu
-
-          Tom Yu
-          Massachusetts Institute of Technology
-          77 Massachusetts Avenue
-          Cambridge, MA 02139, USA
-          Email: tlyu@mit.edu
-
-          Sam Hartman
-          Massachusetts Institute of Technology
-          77 Massachusetts Avenue
-          Cambridge, MA 02139, USA
-          Email: hartmans@mit.edu
-
-          Kenneth Raeburn
-          Massachusetts Institute of Technology
-          77 Massachusetts Avenue
-          Cambridge, MA 02139, USA
-          Email: raeburn@MIT.EDU
-
-
-12. Acknowledgements
-
-      This document is a revision to RFC1510 which was co-authored with
-      John Kohl.  The specification of the Kerberos protocol described
-      in this document is the result of many years of effort.  Over this
-      period many individuals have contributed to the definition of the
-      protocol and to the writing of the specification. Unfortunately it
-      is not possible to list all contributors as authors of this
-      document, though there are many not listed who are authors in
-      spirit, because they contributed text for parts of some sections,
-      because they contributed to the design of parts of the protocol,
-      or because they contributed significantly to the discussion of the
-      protocol in the IETF common authentication technology (CAT) and
-      Kerberos working groups.
-
-      Among those contributing to the development and specification of
-      Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan
-      Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John
-      Kohl, Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John
-      Linn, Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis,
-      Jerome Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick,
-      Mike Swift, Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques
-      Vidrine, Assar Westerlund, and Nicolas Williams. Many other
-      members of MIT Project Athena, the MIT networking group, and the
-      Kerberos and CAT working groups of the IETF contributed but are
-      not listed.
-
-
-
-February 2004                                                 [Page 121]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      Funding for the RFC Editor function is currently provided by the
-      Internet Society.
-
-13. REFERENCES
-
-13.1 NORMATIVE REFERENCES
-
-   [@KCRYPTO]
-      RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
-      crypto.
-
-   [@AES]
-      RFC-Editor: To be replaced by RFC number for draft-raeburn0krb-
-      rijndael-krb.
-
-   [ISO-646/ECMA-6]
-      7-bit Coded Character Set
-
-   [ISO-2022/ECMA-35]
-      Character Code Structure and Extension Techniques
-
-   [ISO-4873/ECMA-43]
-      8-bit Coded Character Set Structure and Rules
-
-   [RFC1035]
-      P.V. Mockapetris, RFC1035: "Domain Names - Implementations and
-      Specification," November 1, 1987, Obsoletes - RFC973, RFC882,
-      RFC883. Updated by RFC1101, RFC1183, RFC1348, RFCRFC1876, RFC1982,
-      RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308,
-      RFC2535, RFC2845, and RFC3425. Status: Standard.
-
-   [RFC2119]
-
-      S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
-      Requirement Levels", March 1997.
-
-   [RFC2434]
-      T. Narten, H. Alvestrand, RFC2434: "Guidelines for writing IANA
-      Consideration Secionts in RFCs" October, 1998.
-
-   [RFC2782]
-      A. Gulbrandsen,  P. Vixie and L. Esibov., RFC2782: "A DNS RR for
-      Specifying the Location of Services (DNS SRV)," February 2000.
-
-   [RFC2253]
-      M. Wahl, S. Killie, and T. Howes, RFC2253: "Lightweight Directory
-      Access Protocol (v3): UTF-8 String Representation or Distinguished
-      Names," December 1997, Obsoletes - RFC1779, Updated by RFC3377,
-
-
-
-February 2004                                                 [Page 122]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      Status: Proposed Standard.
-
-   [RFC2373]
-      R. Hinden, S. Deering, RFC2373: "IP Version 6 Addressing
-      Architecture," July 1998, Status: Proposed Standard.
-
-   [X680]
-      Abstract Syntax Notation One (ASN.1): Specification of Basic
-      Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
-      International Standard 8824-1:1998.
-
-   [X690]
-      ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
-      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
-      (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
-      Standard 8825-1:1998.
-
-13.2 INFORMATIVE REFERENCES
-
-   [DGT96]
-      Don Davis, Daniel Geer, and Theodore Ts'o, "Kerberos With Clocks
-      Adrift: History, Protocols, and Implementation", USENIX Computing
-      Systems 9:1 (January 1996).
-
-   [DS81]
-      Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
-      Distribution Protocols," Communications of the ACM, Vol. 24(8),
-      pp.  533-536 (August 1981).
-
-   [KNT94]
-
-      John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
-      Evolution of the Kerberos Authentication System". In Distributed
-      Open Systems, pages 78-94. IEEE Computer Society Press, 1994.
-
-   [MNSS87]
-      S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer,
-      Section E.2.1: Kerberos Authentication and Authorization System,
-      M.I.T. Project Athena, Cambridge, Massachusetts (December 21,
-      1987).
-
-   [NS78]
-      Roger M. Needham and Michael D. Schroeder, "Using Encryption for
-      Authentication in Large Networks of Computers," Communications of
-      the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
-
-   [Neu93]
-      B. Clifford Neuman, "Proxy-Based Authorization and Accounting for
-
-
-
-February 2004                                                 [Page 123]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      Distributed Systems," in Proceedings of the 13th International
-      Conference on Distributed Computing Systems, Pittsburgh, PA (May,
-      1993).
-
-   [NT94]
-      B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication
-      Service for Computer Networks," IEEE Communications Magazine, Vol.
-      32(9), pp.  33-38 (September 1994).
-
-   [Pat92].
-      J. Pato, Using Pre-Authentication to Avoid Password Guessing
-      Attacks, Open Software Foundation DCE Request for Comments 26
-      (December 1992).
-
-   [RFC1510]
-      J. Kohl and  B. C. Neuman, RFC1510: "The Kerberos Network
-      Authentication Service (v5)," September 1993, Status: Proposed
-      Standard.
-
-   [RFC1750]
-      D. Eastlake, S. Crocker, and J. Schiller "Randomness
-      Recommendation for Security" December 1994, Status: Informational.
-
-   [RFC2026]
-      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
-      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
-      Practice.
-
-   [SNS88]
-      J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An
-      Authentication Service for Open Network Systems," pp. 191-202 in
-      Usenix Conference Proceedings, Dallas, Texas (February, 1988).
-
-
-14. Copyright Statement
-
-      Copyright (C) The Internet Society (2004).  This document is
-      subject to the rights, licenses and restrictions contained in BCP
-      78 and except as set forth therein, the authors retain all their
-      rights.
-
-      This document and the information contained herein are provided on
-      an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
-      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
-      THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
-      EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
-      THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
-      ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
-
-
-
-February 2004                                                 [Page 124]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      PARTICULAR PURPOSE.
-
-15. Intellectual Property
-
-      The IETF takes no position regarding the validity or scope of any
-      Intellectual Property Rights or other rights that might be claimed
-      to pertain to the implementation or use of the technology
-      described in this document or the extent to which any license
-      under such rights might or might not be available; nor does it
-      represent that it has made any independent effort to identify any
-      such rights.  Information on the procedures with respect to rights
-      in RFC documents can be found in BCP 78 and BCP 79.
-
-      Copies of IPR disclosures made to the IETF Secretariat and any
-      assurances of licenses to be made available, or the result of an
-      attempt made to obtain a general license or permission for the use
-      of such proprietary rights by implementers or users of this
-      specification can be obtained from the IETF on-line IPR repository
-      at http://www.ietf.org/ipr.
-
-      The IETF invites any interested party to bring to its attention
-      any copyrights, patents or patent applications, or other
-      proprietary rights that may cover technology that may be required
-      to implement this standard.  Please address the information to the
-      IETF at ietf-ipr@ietf.org.
-
-A. ASN.1 module
-
-      KerberosV5Spec2 {
-              iso(1) identified-organization(3) dod(6) internet(1)
-              security(5) kerberosV5(2) modules(4) krb5spec2(2)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      -- OID arc for KerberosV5
-      --
-      -- This OID may be used to identify Kerberos protocol messages
-      -- encapsulated in other protocols.
-      --
-      -- This OID also designates the OID arc for KerberosV5-related OIDs.
-      --
-      -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID.
-      id-krb5         OBJECT IDENTIFIER ::= {
-              iso(1) identified-organization(3) dod(6) internet(1)
-              security(5) kerberosV5(2)
-      }
-
-      Int32           ::= INTEGER (-2147483648..2147483647)
-                          -- signed values representable in 32 bits
-
-
-
-February 2004                                                 [Page 125]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      UInt32          ::= INTEGER (0..4294967295)
-                          -- unsigned 32 bit values
-
-      Microseconds    ::= INTEGER (0..999999)
-                          -- microseconds
-
-      KerberosString  ::= GeneralString (IA5String)
-
-      Realm           ::= KerberosString
-
-      PrincipalName   ::= SEQUENCE {
-              name-type       [0] Int32,
-              name-string     [1] SEQUENCE OF KerberosString
-      }
-
-      KerberosTime    ::= GeneralizedTime -- with no fractional seconds
-
-      HostAddress     ::= SEQUENCE  {
-              addr-type       [0] Int32,
-              address         [1] OCTET STRING
-      }
-
-      -- NOTE: HostAddresses is always used as an OPTIONAL field and
-      -- should not be empty.
-      HostAddresses   -- NOTE: subtly different from rfc1510,
-                      -- but has a value mapping and encodes the same
-              ::= SEQUENCE OF HostAddress
-
-      -- NOTE: AuthorizationData is always used as an OPTIONAL field and
-      -- should not be empty.
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-              ad-type         [0] Int32,
-              ad-data         [1] OCTET STRING
-      }
-
-      PA-DATA         ::= SEQUENCE {
-              -- NOTE: first tag is [1], not [0]
-              padata-type     [1] Int32,
-              padata-value    [2] OCTET STRING -- might be encoded AP-REQ
-      }
-
-      KerberosFlags   ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
-                          -- shall be sent, but no fewer than 32
-
-      EncryptedData   ::= SEQUENCE {
-              etype   [0] Int32 -- EncryptionType --,
-              kvno    [1] UInt32 OPTIONAL,
-              cipher  [2] OCTET STRING -- ciphertext
-
-
-
-February 2004                                                 [Page 126]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      }
-
-      EncryptionKey   ::= SEQUENCE {
-              keytype         [0] Int32 -- actually encryption type --,
-              keyvalue        [1] OCTET STRING
-      }
-
-      Checksum        ::= SEQUENCE {
-              cksumtype       [0] Int32,
-              checksum        [1] OCTET STRING
-      }
-
-      Ticket          ::= [APPLICATION 1] SEQUENCE {
-              tkt-vno         [0] INTEGER (5),
-              realm           [1] Realm,
-              sname           [2] PrincipalName,
-              enc-part        [3] EncryptedData -- EncTicketPart
-      }
-
-      -- Encrypted part of ticket
-      EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
-              flags                   [0] TicketFlags,
-              key                     [1] EncryptionKey,
-              crealm                  [2] Realm,
-              cname                   [3] PrincipalName,
-              transited               [4] TransitedEncoding,
-              authtime                [5] KerberosTime,
-              starttime               [6] KerberosTime OPTIONAL,
-              endtime                 [7] KerberosTime,
-              renew-till              [8] KerberosTime OPTIONAL,
-              caddr                   [9] HostAddresses OPTIONAL,
-              authorization-data      [10] AuthorizationData OPTIONAL
-      }
-
-      -- encoded Transited field
-      TransitedEncoding       ::= SEQUENCE {
-              tr-type         [0] Int32 -- must be registered --,
-              contents        [1] OCTET STRING
-      }
-
-      TicketFlags     ::= KerberosFlags
-              -- reserved(0),
-              -- forwardable(1),
-              -- forwarded(2),
-              -- proxiable(3),
-              -- proxy(4),
-              -- may-postdate(5),
-              -- postdated(6),
-
-
-
-February 2004                                                 [Page 127]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-              -- invalid(7),
-              -- renewable(8),
-              -- initial(9),
-              -- pre-authent(10),
-              -- hw-authent(11),
-      -- the following are new since 1510
-              -- transited-policy-checked(12),
-              -- ok-as-delegate(13)
-
-      AS-REQ          ::= [APPLICATION 10] KDC-REQ
-
-      TGS-REQ         ::= [APPLICATION 12] KDC-REQ
-
-      KDC-REQ         ::= SEQUENCE {
-              -- NOTE: first tag is [1], not [0]
-              pvno            [1] INTEGER (5) ,
-              msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
-              padata          [3] SEQUENCE OF PA-DATA OPTIONAL
-                                  -- NOTE: not empty --,
-              req-body        [4] KDC-REQ-BODY
-      }
-
-      KDC-REQ-BODY    ::= SEQUENCE {
-              kdc-options             [0] KDCOptions,
-              cname                   [1] PrincipalName OPTIONAL
-                                          -- Used only in AS-REQ --,
-              realm                   [2] Realm
-                                          -- Server's realm
-                                          -- Also client's in AS-REQ --,
-              sname                   [3] PrincipalName OPTIONAL,
-              from                    [4] KerberosTime OPTIONAL,
-              till                    [5] KerberosTime,
-              rtime                   [6] KerberosTime OPTIONAL,
-              nonce                   [7] UInt32,
-              etype                   [8] SEQUENCE OF Int32 -- EncryptionType
-                                          -- in preference order --,
-              addresses               [9] HostAddresses OPTIONAL,
-              enc-authorization-data  [10] EncryptedData -- AuthorizationData --,
-              additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
-                                              -- NOTE: not empty
-      }
-
-      KDCOptions      ::= KerberosFlags
-              -- reserved(0),
-              -- forwardable(1),
-              -- forwarded(2),
-              -- proxiable(3),
-              -- proxy(4),
-
-
-
-February 2004                                                 [Page 128]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-              -- allow-postdate(5),
-              -- postdated(6),
-              -- unused7(7),
-              -- renewable(8),
-              -- unused9(9),
-              -- unused10(10),
-              -- opt-hardware-auth(11),
-              -- unused12(12),
-              -- unused13(13),
-      -- 15 is reserved for canonicalize
-              -- unused15(15),
-      -- 26 was unused in 1510
-              -- disable-transited-check(26),
-      --
-              -- renewable-ok(27),
-              -- enc-tkt-in-skey(28),
-              -- renew(30),
-              -- validate(31)
-
-      AS-REP          ::= [APPLICATION 11] KDC-REP
-
-      TGS-REP         ::= [APPLICATION 13] KDC-REP
-
-      KDC-REP         ::= SEQUENCE {
-              pvno            [0] INTEGER (5),
-              msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
-              padata          [2] SEQUENCE OF PA-DATA OPTIONAL
-                                      -- NOTE: not empty --,
-              crealm          [3] Realm,
-              cname           [4] PrincipalName,
-              ticket          [5] Ticket,
-              enc-part        [6] EncryptedData
-                                      -- EncASRepPart or EncTGSRepPart,
-                                      -- as appropriate
-      }
-
-      EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
-
-      EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
-
-      EncKDCRepPart   ::= SEQUENCE {
-              key             [0] EncryptionKey,
-              last-req        [1] LastReq,
-              nonce           [2] UInt32,
-              key-expiration  [3] KerberosTime OPTIONAL,
-              flags           [4] TicketFlags,
-              authtime        [5] KerberosTime,
-              starttime       [6] KerberosTime OPTIONAL,
-
-
-
-February 2004                                                 [Page 129]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-              endtime         [7] KerberosTime,
-              renew-till      [8] KerberosTime OPTIONAL,
-              srealm          [9] Realm,
-              sname           [10] PrincipalName,
-              caddr           [11] HostAddresses OPTIONAL
-      }
-
-      LastReq         ::=     SEQUENCE OF SEQUENCE {
-              lr-type         [0] Int32,
-              lr-value        [1] KerberosTime
-      }
-
-      AP-REQ          ::= [APPLICATION 14] SEQUENCE {
-              pvno            [0] INTEGER (5),
-              msg-type        [1] INTEGER (14),
-              ap-options      [2] APOptions,
-              ticket          [3] Ticket,
-              authenticator   [4] EncryptedData -- Authenticator
-      }
-
-      APOptions       ::= KerberosFlags
-              -- reserved(0),
-              -- use-session-key(1),
-              -- mutual-required(2)
-
-      -- Unencrypted authenticator
-      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-              authenticator-vno       [0] INTEGER (5),
-              crealm                  [1] Realm,
-              cname                   [2] PrincipalName,
-              cksum                   [3] Checksum OPTIONAL,
-              cusec                   [4] Microseconds,
-              ctime                   [5] KerberosTime,
-              subkey                  [6] EncryptionKey OPTIONAL,
-              seq-number              [7] UInt32 OPTIONAL,
-              authorization-data      [8] AuthorizationData OPTIONAL
-      }
-
-      AP-REP          ::= [APPLICATION 15] SEQUENCE {
-              pvno            [0] INTEGER (5),
-              msg-type        [1] INTEGER (15),
-              enc-part        [2] EncryptedData -- EncAPRepPart
-      }
-
-      EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
-              ctime           [0] KerberosTime,
-              cusec           [1] Microseconds,
-              subkey          [2] EncryptionKey OPTIONAL,
-
-
-
-February 2004                                                 [Page 130]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-              seq-number      [3] UInt32 OPTIONAL
-      }
-
-      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-              pvno            [0] INTEGER (5),
-              msg-type        [1] INTEGER (20),
-              safe-body       [2] KRB-SAFE-BODY,
-              cksum           [3] Checksum
-      }
-
-      KRB-SAFE-BODY   ::= SEQUENCE {
-              user-data       [0] OCTET STRING,
-              timestamp       [1] KerberosTime OPTIONAL,
-              usec            [2] Microseconds OPTIONAL,
-              seq-number      [3] UInt32 OPTIONAL,
-              s-address       [4] HostAddress,
-              r-address       [5] HostAddress OPTIONAL
-      }
-
-      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-              pvno            [0] INTEGER (5),
-              msg-type        [1] INTEGER (21),
-                              -- NOTE: there is no [2] tag
-              enc-part        [3] EncryptedData -- EncKrbPrivPart
-      }
-
-      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-              user-data       [0] OCTET STRING,
-              timestamp       [1] KerberosTime OPTIONAL,
-              usec            [2] Microseconds OPTIONAL,
-              seq-number      [3] UInt32 OPTIONAL,
-              s-address       [4] HostAddress -- sender's addr --,
-              r-address       [5] HostAddress OPTIONAL -- recip's addr
-      }
-
-      KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
-              pvno            [0] INTEGER (5),
-              msg-type        [1] INTEGER (22),
-              tickets         [2] SEQUENCE OF Ticket,
-              enc-part        [3] EncryptedData -- EncKrbCredPart
-      }
-
-      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-              ticket-info     [0] SEQUENCE OF KrbCredInfo,
-              nonce           [1] UInt32 OPTIONAL,
-              timestamp       [2] KerberosTime OPTIONAL,
-              usec            [3] Microseconds OPTIONAL,
-              s-address       [4] HostAddress OPTIONAL,
-
-
-
-February 2004                                                 [Page 131]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-              r-address       [5] HostAddress OPTIONAL
-      }
-
-      KrbCredInfo     ::= SEQUENCE {
-              key             [0] EncryptionKey,
-              prealm          [1] Realm OPTIONAL,
-              pname           [2] PrincipalName OPTIONAL,
-              flags           [3] TicketFlags OPTIONAL,
-              authtime        [4] KerberosTime OPTIONAL,
-              starttime       [5] KerberosTime OPTIONAL,
-              endtime         [6] KerberosTime OPTIONAL,
-              renew-till      [7] KerberosTime OPTIONAL,
-              srealm          [8] Realm OPTIONAL,
-              sname           [9] PrincipalName OPTIONAL,
-              caddr           [10] HostAddresses OPTIONAL
-      }
-
-      KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
-              pvno            [0] INTEGER (5),
-              msg-type        [1] INTEGER (30),
-              ctime           [2] KerberosTime OPTIONAL,
-              cusec           [3] Microseconds OPTIONAL,
-              stime           [4] KerberosTime,
-              susec           [5] Microseconds,
-              error-code      [6] Int32,
-              crealm          [7] Realm OPTIONAL,
-              cname           [8] PrincipalName OPTIONAL,
-              realm           [9] Realm -- service realm --,
-              sname           [10] PrincipalName -- service name --,
-              e-text          [11] KerberosString OPTIONAL,
-              e-data          [12] OCTET STRING OPTIONAL
-      }
-
-      METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-      TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-              data-type       [0] INTEGER,
-              data-value      [1] OCTET STRING OPTIONAL
-      }
-
-      -- preauth stuff follows
-
-      PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
-
-      PA-ENC-TS-ENC           ::= SEQUENCE {
-              patimestamp     [0] KerberosTime -- client's time --,
-              pausec          [1] Microseconds OPTIONAL
-      }
-
-
-
-February 2004                                                 [Page 132]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      ETYPE-INFO-ENTRY        ::= SEQUENCE {
-              etype           [0] Int32,
-              salt            [1] OCTET STRING OPTIONAL
-      }
-
-      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
-
-      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
-              etype           [0] Int32,
-              salt            [1] KerberosString OPTIONAL,
-              s2kparams       [2] OCTET STRING OPTIONAL
-      }
-
-      ETYPE-INFO2             ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
-
-      AD-IF-RELEVANT          ::= AuthorizationData
-
-      AD-KDCIssued            ::= SEQUENCE {
-              ad-checksum     [0] Checksum,
-              i-realm         [1] Realm OPTIONAL,
-              i-sname         [2] PrincipalName OPTIONAL,
-              elements        [3] AuthorizationData
-      }
-
-      AD-AND-OR               ::= SEQUENCE {
-              condition-count [0] INTEGER,
-              elements        [1] AuthorizationData
-      }
-
-      AD-MANDATORY-FOR-KDC    ::= AuthorizationData
-
-      END
-
-B. Changes since RFC-1510
-
-      This document replaces RFC-1510 and clarifies specification of
-      items that were not completely specified. Where changes to
-      recommended implementation choices were made, or where new options
-      were added, those changes are described within the document and
-      listed in this section. More significantly, "Specification 2" in
-      section 8 changes the required encryption and checksum methods to
-      bring them in line with the best current practices and to
-      deprecate methods that are no longer considered sufficiently
-      strong.
-
-      Discussion was added to section 1 regarding the ability to rely on
-      the KDC to check the transited field, and on the inclusion of a
-      flag in a ticket indicating that this check has occurred. This is
-
-
-
-February 2004                                                 [Page 133]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      a new capability not present in RFC1510. Pre-existing
-      implementations may ignore or not set this flag without negative
-      security implications.
-
-      The definition of the secret key says that in the case of a user
-      the key may be derived from a password. In 1510, it said that the
-      key was derived from the password. This change was made to
-      accommodate situations where the user key might be stored on a
-      smart-card, or otherwise obtained independent of a password.
-
-      The introduction mentions the use of public key cryptography for
-      initial authentication in Kerberos by reference. RFC1510 did not
-      include such a reference.
-
-      Section 1.2 was added to explain that while Kerberos provides
-      authentication of a named principal, it is still the
-      responsibility of the application to ensure that the authenticated
-      name is the entity with which the application wishes to
-      communicate.
-
-      Discussion of extensibility has been added to the introduction.
-
-      Discussion of how extensibility affects ticket flags and KDC
-      options was added to the introduction of section 2. No changes
-      were made to existing options and flags specified in RFC1510,
-      though some of the sections in the specification were renumbered,
-      and text was revised to make the description and intent of
-      existing options clearer, especially with respect to the ENC-TKT-
-      IN-SKEY option (now section 2.9.2) which is used for user-to-user
-      authentication.  The new option and ticket flag transited policy
-      checking (section 2.7) was added.
-
-      A warning regarding generation of session keys for application use
-      was added to section 3, urging the inclusion of key entropy from
-      the KDC generated session key in the ticket. An example regarding
-      use of the sub-session key was added to section 3.2.6.
-      Descriptions of the pa-etype-info, pa-etype-info2, and pa-pw-salt
-      pre-authentication data items were added. The recommendation for
-      use of pre-authentication was changed from "may" to "should" and a
-      note was added regarding known plaintext attacks.
-
-      In RFC 1510, section 4 described the database in the KDC. This
-      discussion was not necessary for interoperability and
-      unnecessarily constrained implementation. The old section 4 was
-      removed.
-
-      The current section 4 was formerly section 6 on encryption and
-      checksum specifications. The major part of this section was
-
-
-
-February 2004                                                 [Page 134]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      brought up to date to support new encryption methods, and move to
-      a separate document. Those few remaining aspects of the encryption
-      and checksum specification specific to Kerberos are now specified
-      in section 4.
-
-      Significant changes were made to the layout of section 5 to
-      clarify the correct behavior for optional fields. Many of these
-      changes were made necessary because of improper ASN.1 description
-      in the original Kerberos specification which left the correct
-      behavior underspecified. Additionally, the wording in this section
-      was tightened wherever possible to ensure that implementations
-      conforming to this specification will be extensible with the
-      addition of new fields in future specifications.
-
-      Text was added describing time_t=0 issues in the ASN.1. Text was
-      also added, clarifying issues with implementations treating
-      omitted optional integers as zero. Text was added clarifying
-      behavior for optional SEQUENCE or SEQUENCE OF that may be empty.
-      Discussion was added regarding sequence numbers and behavior of
-      some implementations, including "zero" behavior and negative
-      numbers. A compatibility note was added regarding the
-      unconditional sending of EncTGSRepPart regardless of the enclosing
-      reply type. Minor changes were made to the description of the
-      HostAddresses type. Integer types were constrained. KerberosString
-      was defined as a (significantly) constrained GeneralString.
-      KerberosFlags was defined to reflect existing implementation
-      behavior that departs from the definition in RFC 1510. The
-      transited-policy-checked(12) and the ok-as-delegate(13) ticket
-      flags were added. The disable-transited-check(26) KDC option was
-      added.
-
-      Descriptions of commonly implemented PA-DATA were added to section
-      5. The description of KRB-SAFE has been updated to note the
-      existing implementation behavior of double-encoding.
-
-      There were two definitions of METHOD-DATA in RFC 1510. The second
-      one, intended for use with KRB_AP_ERR_METHOD was removed leaving
-      the SEQUENCE OF PA-DATA definition.
-
-      Section 7, naming constraints, from RFC1510 was moved to section
-      6.
-
-      Words were added describing the convention that domain based realm
-      names for newly created realms should be specified as upper case.
-      This recommendation does not make lower case realm names illegal.
-      Words were added highlighting that the slash separated components
-      in the X500 style of realm names is consistent with existing
-      RFC1510 based implementations, but that it conflicts with the
-
-
-
-February 2004                                                 [Page 135]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      general recommendation of X.500 name representation specified in
-      RFC2253.
-
-      Section 8, network transport, constants and defined values, from
-      RFC1510 was moved to section 7.  Since RFC1510, the definition of
-      the TCP transport for Kerberos messages was added, and the
-      encryption and checksum number assignments have been moved into a
-      separate document.
-
-      "Specification 2" in section 8 of the current document changes the
-      required encryption and checksum methods to bring them in line
-      with the best current practices and to deprecate methods that are
-      no longer considered sufficiently strong.
-
-      Two new sections, on IANA considerations and security
-      considerations were added.
-
-      The pseudo-code has been removed from the appendix. The pseudo-
-      code was sometimes misinterpreted to limit implementation choices
-      and in RFC 1510, it was not always consistent with the words in
-      the specification. Effort was made to clear up any ambiguities in
-      the specification, rather than to rely on the pseudo-code.
-
-      An appendix was added containing the complete ASN.1 module drawn
-      from the discussion in section 5 of the current document.
-
-END NOTES
-
-      [TM] Project Athena, Athena, and Kerberos are trademarks of the
-      Massachusetts Institute of Technology (MIT). No commercial use of
-      these trademarks may be made without prior written permission of
-      MIT.
-
-      [1] Note, however, that many applications use Kerberos' functions
-      only upon the initiation of a stream-based network connection.
-      Unless an application subsequently provides integrity protection
-      for the data stream, the identity verification applies only to the
-      initiation of the connection, and does not guarantee that
-      subsequent messages on the connection originate from the same
-      principal.
-
-      [2] Secret and private are often used interchangeably in the
-      literature.  In our usage, it takes two (or more) to share a
-      secret, thus a shared DES key is a secret key. Something is only
-      private when no one but its owner knows it. Thus, in public key
-      cryptosystems, one has a public and a private key.
-
-      [3] Of course, with appropriate permission the client could
-
-
-
-February 2004                                                 [Page 136]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      arrange registration of a separately-named principal in a remote
-      realm, and engage in normal exchanges with that realm's services.
-      However, for even small numbers of clients this becomes
-      cumbersome, and more automatic methods as described here are
-      necessary.
-
-      [4] Though it is permissible to request or issue tickets with no
-      network addresses specified.
-
-      [5] The password-changing request must not be honored unless the
-      requester can provide the old password (the user's current secret
-      key). Otherwise, it would be possible for someone to walk up to an
-      unattended session and change another user's password.
-
-      [6] To authenticate a user logging on to a local system, the
-      credentials obtained in the AS exchange may first be used in a TGS
-      exchange to obtain credentials for a local server. Those
-      credentials must then be verified by a local server through
-      successful completion of the Client/Server exchange.
-
-      [7] "Random" means that, among other things, it should be
-      impossible to guess the next session key based on knowledge of
-      past session keys. This can only be achieved in a pseudo-random
-      number generator if it is based on cryptographic principles. It is
-      more desirable to use a truly random number generator, such as one
-      based on measurements of random physical phenomena.  See [RFC1750]
-      for an in depth discussion of randomness.
-
-      [8] Tickets contain both an encrypted and unencrypted portion, so
-      cleartext here refers to the entire unit, which can be copied from
-      one message and replayed in another without any cryptographic
-      skill.
-
-      [9] Note that this can make applications based on unreliable
-      transports difficult to code correctly. If the transport might
-      deliver duplicated messages, either a new authenticator must be
-      generated for each retry, or the application server must match
-      requests and replies and replay the first reply in response to a
-      detected duplicate.
-
-      [10] Note also that the rejection here is restricted to
-      authenticators from the same principal to the same server. Other
-      client principals communicating with the same server principal
-      should not be have their authenticators rejected if the time and
-      microsecond fields happen to match some other client's
-      authenticator.
-
-      [11] If this is not done, an attacker could subvert the
-
-
-
-February 2004                                                 [Page 137]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-05.txt DRAFT
-
-
-      authentication by recording the ticket and authenticator sent over
-      the network to a server and replaying them following an event that
-      caused the server to lose track of recently seen authenticators.
-
-      [12] In the Kerberos version 4 protocol, the timestamp in the
-      reply was the client's timestamp plus one. This is not necessary
-      in version 5 because version 5 messages are formatted in such a
-      way that it is not possible to create the reply by judicious
-      message surgery (even in encrypted form) without knowledge of the
-      appropriate encryption keys.
-
-      [13] Note that for encrypting the KRB_AP_REP message, the sub-
-      session key is not used, even if present in the Authenticator.
-
-      [14] Implementations of the protocol may provide routines to
-      choose subkeys based on session keys and random numbers and to
-      generate a negotiated key to be returned in the KRB_AP_REP
-      message.
-
-      [15]This can be accomplished in several ways. It might be known
-      beforehand (since the realm is part of the principal identifier),
-      it might be stored in a nameserver, or it might be obtained from a
-      configuration file. If the realm to be used is obtained from a
-      nameserver, there is a danger of being spoofed if the nameservice
-      providing the realm name is not authenticated.  This might result
-      in the use of a realm which has been compromised, and would result
-      in an attacker's ability to compromise the authentication of the
-      application server to the client.
-
-      [16] If the client selects a sub-session key, care must be taken
-      to ensure the randomness of the selected sub-session key. One
-      approach would be to generate a random number and XOR it with the
-      session key from the ticket-granting ticket.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-February 2004                                                 [Page 138]
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-06.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-06.txt
deleted file mode 100644
index a607843ef..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-clarifications-06.txt
+++ /dev/null
@@ -1,8039 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                          Clifford Neuman
-Obsoletes: 1510                                                 USC-ISI
-                                                                 Tom Yu
-                                                            Sam Hartman
-                                                            Ken Raeburn
-                                                                    MIT
-                                                          June 29, 2004
-                                              Expires 29 December, 2004
-
-            The Kerberos Network Authentication Service (V5)
-            draft-ietf-krb-wg-kerberos-clarifications-06.txt 
-
-STATUS OF THIS MEMO
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC 2026. 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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   To learn the current status of any Internet-Draft, please check the
-   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
-   Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
-   ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
-
-   The distribution of this memo is unlimited. It is filed as draft-
-   ietf-krb-wg-kerberos-clarifications-06.txt, and expires 29 December
-   2004.  Please send comments to: ietf-krb-wg@anl.gov
-
-ABSTRACT
-
-   This document provides an overview and specification of Version 5 of
-   the Kerberos protocol, and obsoletes RFC1510 to clarify aspects of
-   the protocol and its intended use that require more detailed or
-   clearer explanation than was provided in RFC1510. This document is
-   intended to provide a detailed description of the protocol, suitable
-   for implementation, together with descriptions of the appropriate use
-   of protocol messages and fields within those messages.
-
-
-
-June 2004                                                       [Page 1]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-OVERVIEW
-
-   This document describes the concepts and model upon which the
-   Kerberos network authentication system is based. It also specifies
-   Version 5 of the Kerberos protocol.  The motivations, goals,
-   assumptions, and rationale behind most design decisions are treated
-   cursorily; they are more fully described in a paper available in IEEE
-   communications [NT94] and earlier in the Kerberos portion of the
-   Athena Technical Plan [MNSS87].
-
-   This document is not intended to describe Kerberos to the end user,
-   system administrator, or application developer. Higher level papers
-   describing Version 5 of the Kerberos system [NT94] and documenting
-   version 4 [SNS88], are available elsewhere.
-
-BACKGROUND
-
-   The Kerberos model is based in part on Needham and Schroeder's
-   trusted third-party authentication protocol [NS78] and on
-   modifications suggested by Denning and Sacco [DS81]. The original
-   design and implementation of Kerberos Versions 1 through 4 was the
-   work of two former Project Athena staff members, Steve Miller of
-   Digital Equipment Corporation and Clifford Neuman (now at the
-   Information Sciences Institute of the University of Southern
-   California), along with Jerome Saltzer, Technical Director of Project
-   Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other
-   members of Project Athena have also contributed to the work on
-   Kerberos.
-
-   Version 5 of the Kerberos protocol (described in this document) has
-   evolved from Version 4 based on new requirements and desires for
-   features not available in Version 4. The design of Version 5 of the
-   Kerberos protocol was led by Clifford Neuman and John Kohl with much
-   input from the community. The development of the MIT reference
-   implementation was led at MIT by John Kohl and Theodore Ts'o, with
-   help and contributed code from many others. Since RFC1510 was issued,
-   extensions and revisions to the protocol have been proposed by many
-   individuals. Some of these proposals are reflected in this document.
-   Where such changes involved significant effort, the document cites
-   the contribution of the proposer.
-
-   Reference implementations of both version 4 and version 5 of Kerberos
-   are publicly available and commercial implementations have been
-   developed and are widely used. Details on the differences between
-   Kerberos Versions 4 and 5 can be found in [KNT94].
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119.
-
-
-June 2004                                                       [Page 2]
-
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-                           Table of Contents
-
-
-1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
-1.1. Cross-realm operation . . . . . . . . . . . . . . . . . . . . .   8
-1.2. Choosing a principal with which to communicate  . . . . . . . .   9
-1.3. Authorization . . . . . . . . . . . . . . . . . . . . . . . . .  10
-1.4. Extending Kerberos Without Breaking Interoperability  . . . . .  11
-1.4.1. Compatibility with RFC 1510 . . . . . . . . . . . . . . . . .  11
-1.4.2. Sending Extensible Messages . . . . . . . . . . . . . . . . .  12
-1.5. Environmental assumptions . . . . . . . . . . . . . . . . . . .  12
-1.6. Glossary of terms . . . . . . . . . . . . . . . . . . . . . . .  13
-2. Ticket flag uses and requests . . . . . . . . . . . . . . . . . .  16
-2.1. Initial, pre-authenticated, and hardware authenticated
-      tickets  . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
-2.2. Invalid tickets . . . . . . . . . . . . . . . . . . . . . . . .  17
-2.3. Renewable tickets . . . . . . . . . . . . . . . . . . . . . . .  17
-2.4. Postdated tickets . . . . . . . . . . . . . . . . . . . . . . .  18
-2.5. Proxiable and proxy tickets . . . . . . . . . . . . . . . . . .  19
-2.6. Forwardable tickets . . . . . . . . . . . . . . . . . . . . . .  19
-2.7. Transited Policy Checking . . . . . . . . . . . . . . . . . . .  20
-2.8. OK as Delegate  . . . . . . . . . . . . . . . . . . . . . . . .  21
-2.9. Other KDC options . . . . . . . . . . . . . . . . . . . . . . .  21
-2.9.1. Renewable-OK  . . . . . . . . . . . . . . . . . . . . . . . .  21
-2.9.2. ENC-TKT-IN-SKEY . . . . . . . . . . . . . . . . . . . . . . .  22
-2.9.3. Passwordless Hardware Authentication  . . . . . . . . . . . .  22
-3. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . . .  22
-3.1. The Authentication Service Exchange . . . . . . . . . . . . . .  22
-3.1.1. Generation of KRB_AS_REQ message  . . . . . . . . . . . . . .  24
-3.1.2. Receipt of KRB_AS_REQ message . . . . . . . . . . . . . . . .  24
-3.1.3. Generation of KRB_AS_REP message  . . . . . . . . . . . . . .  24
-3.1.4. Generation of KRB_ERROR message . . . . . . . . . . . . . . .  27
-3.1.5. Receipt of KRB_AS_REP message . . . . . . . . . . . . . . . .  27
-3.1.6. Receipt of KRB_ERROR message  . . . . . . . . . . . . . . . .  28
-3.2. The Client/Server Authentication Exchange . . . . . . . . . . .  28
-3.2.1. The KRB_AP_REQ message  . . . . . . . . . . . . . . . . . . .  29
-3.2.2. Generation of a KRB_AP_REQ message  . . . . . . . . . . . . .  29
-3.2.3. Receipt of KRB_AP_REQ message . . . . . . . . . . . . . . . .  30
-3.2.4. Generation of a KRB_AP_REP message  . . . . . . . . . . . . .  32
-3.2.5. Receipt of KRB_AP_REP message . . . . . . . . . . . . . . . .  33
-3.2.6. Using the encryption key  . . . . . . . . . . . . . . . . . .  33
-3.3. The Ticket-Granting Service (TGS) Exchange  . . . . . . . . . .  34
-3.3.1. Generation of KRB_TGS_REQ message . . . . . . . . . . . . . .  35
-3.3.2. Receipt of KRB_TGS_REQ message  . . . . . . . . . . . . . . .  37
-3.3.3. Generation of KRB_TGS_REP message . . . . . . . . . . . . . .  38
-3.3.3.1. Checking for revoked tickets  . . . . . . . . . . . . . . .  40
-3.3.3.2. Encoding the transited field  . . . . . . . . . . . . . . .  40
-3.3.4. Receipt of KRB_TGS_REP message  . . . . . . . . . . . . . . .  42
-
-
-
-June 2004                                                       [Page 3]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-3.4. The KRB_SAFE Exchange . . . . . . . . . . . . . . . . . . . . .  42
-3.4.1. Generation of a KRB_SAFE message  . . . . . . . . . . . . . .  42
-3.4.2. Receipt of KRB_SAFE message . . . . . . . . . . . . . . . . .  43
-3.5. The KRB_PRIV Exchange . . . . . . . . . . . . . . . . . . . . .  44
-3.5.1. Generation of a KRB_PRIV message  . . . . . . . . . . . . . .  44
-3.5.2. Receipt of KRB_PRIV message . . . . . . . . . . . . . . . . .  44
-3.6. The KRB_CRED Exchange . . . . . . . . . . . . . . . . . . . . .  45
-3.6.1. Generation of a KRB_CRED message  . . . . . . . . . . . . . .  45
-3.6.2. Receipt of KRB_CRED message . . . . . . . . . . . . . . . . .  46
-3.7. User-to-User Authentication Exchanges . . . . . . . . . . . . .  47
-4. Encryption and Checksum Specifications  . . . . . . . . . . . . .  48
-5. Message Specifications  . . . . . . . . . . . . . . . . . . . . .  50
-5.1. Specific Compatibility Notes on ASN.1 . . . . . . . . . . . . .  51
-5.1.1. ASN.1 Distinguished Encoding Rules  . . . . . . . . . . . . .  51
-5.1.2. Optional Integer Fields . . . . . . . . . . . . . . . . . . .  51
-5.1.3. Empty SEQUENCE OF Types . . . . . . . . . . . . . . . . . . .  52
-5.1.4. Unrecognized Tag Numbers  . . . . . . . . . . . . . . . . . .  52
-5.1.5. Tag Numbers Greater Than 30 . . . . . . . . . . . . . . . . .  52
-5.2. Basic Kerberos Types  . . . . . . . . . . . . . . . . . . . . .  52
-5.2.1. KerberosString  . . . . . . . . . . . . . . . . . . . . . . .  53
-5.2.2. Realm and PrincipalName . . . . . . . . . . . . . . . . . . .  54
-5.2.3. KerberosTime  . . . . . . . . . . . . . . . . . . . . . . . .  55
-5.2.4. Constrained Integer types . . . . . . . . . . . . . . . . . .  55
-5.2.5. HostAddress and HostAddresses . . . . . . . . . . . . . . . .  56
-5.2.6. AuthorizationData . . . . . . . . . . . . . . . . . . . . . .  56
-5.2.6.1. IF-RELEVANT . . . . . . . . . . . . . . . . . . . . . . . .  58
-5.2.6.2. KDCIssued . . . . . . . . . . . . . . . . . . . . . . . . .  58
-5.2.6.3. AND-OR  . . . . . . . . . . . . . . . . . . . . . . . . . .  59
-5.2.6.4. MANDATORY-FOR-KDC . . . . . . . . . . . . . . . . . . . . .  59
-5.2.7. PA-DATA . . . . . . . . . . . . . . . . . . . . . . . . . . .  60
-5.2.7.1. PA-TGS-REQ  . . . . . . . . . . . . . . . . . . . . . . . .  61
-5.2.7.2. Encrypted Timestamp Pre-authentication  . . . . . . . . . .  61
-5.2.7.3. PA-PW-SALT  . . . . . . . . . . . . . . . . . . . . . . . .  61
-5.2.7.4. PA-ETYPE-INFO . . . . . . . . . . . . . . . . . . . . . . .  62
-5.2.7.5. PA-ETYPE-INFO2  . . . . . . . . . . . . . . . . . . . . . .  62
-5.2.8. KerberosFlags . . . . . . . . . . . . . . . . . . . . . . . .  63
-5.2.9. Cryptosystem-related Types  . . . . . . . . . . . . . . . . .  64
-5.3. Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . .  66
-5.4. Specifications for the AS and TGS exchanges . . . . . . . . . .  73
-5.4.1. KRB_KDC_REQ definition  . . . . . . . . . . . . . . . . . . .  73
-5.4.2. KRB_KDC_REP definition  . . . . . . . . . . . . . . . . . . .  81
-5.5. Client/Server (CS) message specifications . . . . . . . . . . .  84
-5.5.1. KRB_AP_REQ definition . . . . . . . . . . . . . . . . . . . .  84
-5.5.2. KRB_AP_REP definition . . . . . . . . . . . . . . . . . . . .  87
-5.5.3. Error message reply . . . . . . . . . . . . . . . . . . . . .  88
-5.6. KRB_SAFE message specification  . . . . . . . . . . . . . . . .  89
-5.6.1. KRB_SAFE definition . . . . . . . . . . . . . . . . . . . . .  89
-5.7. KRB_PRIV message specification  . . . . . . . . . . . . . . . .  90
-
-
-
-June 2004                                                       [Page 4]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-5.7.1. KRB_PRIV definition . . . . . . . . . . . . . . . . . . . . .  91
-5.8. KRB_CRED message specification  . . . . . . . . . . . . . . . .  91
-5.8.1. KRB_CRED definition . . . . . . . . . . . . . . . . . . . . .  91
-5.9. Error message specification . . . . . . . . . . . . . . . . . .  94
-5.9.1. KRB_ERROR definition  . . . . . . . . . . . . . . . . . . . .  94
-5.10. Application Tag Numbers  . . . . . . . . . . . . . . . . . . .  96
-6. Naming Constraints  . . . . . . . . . . . . . . . . . . . . . . .  97
-6.1. Realm Names . . . . . . . . . . . . . . . . . . . . . . . . . .  97
-6.2. Principal Names . . . . . . . . . . . . . . . . . . . . . . . .  98
-6.2.1. Name of server principals . . . . . . . . . . . . . . . . . . 100
-7. Constants and other defined values  . . . . . . . . . . . . . . . 100
-7.1. Host address types  . . . . . . . . . . . . . . . . . . . . . . 100
-7.2. KDC messaging - IP Transports . . . . . . . . . . . . . . . . . 101
-7.2.1. UDP/IP transport  . . . . . . . . . . . . . . . . . . . . . . 102
-7.2.2. TCP/IP transport  . . . . . . . . . . . . . . . . . . . . . . 102
-7.2.3. KDC Discovery on IP Networks  . . . . . . . . . . . . . . . . 103
-7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names  . . . . 103
-7.2.3.2. Specifying KDC Location information with DNS SRV
-      records  . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
-7.2.3.3. KDC Discovery for Domain Style Realm Names on IP
-      Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
-7.3. Name of the TGS . . . . . . . . . . . . . . . . . . . . . . . . 105
-7.4. OID arc for KerberosV5  . . . . . . . . . . . . . . . . . . . . 105
-7.5. Protocol constants and associated values  . . . . . . . . . . . 105
-7.5.1. Key usage numbers . . . . . . . . . . . . . . . . . . . . . . 105
-7.5.2. PreAuthentication Data Types  . . . . . . . . . . . . . . . . 107
-7.5.3. Address Types . . . . . . . . . . . . . . . . . . . . . . . . 108
-7.5.4. Authorization Data Types  . . . . . . . . . . . . . . . . . . 108
-7.5.5. Transited Encoding Types  . . . . . . . . . . . . . . . . . . 108
-7.5.6. Protocol Version Number . . . . . . . . . . . . . . . . . . . 108
-7.5.7. Kerberos Message Types  . . . . . . . . . . . . . . . . . . . 108
-7.5.8. Name Types  . . . . . . . . . . . . . . . . . . . . . . . . . 109
-7.5.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 109
-8. Interoperability requirements . . . . . . . . . . . . . . . . . . 111
-8.1. Specification 2 . . . . . . . . . . . . . . . . . . . . . . . . 111
-8.2. Recommended KDC values  . . . . . . . . . . . . . . . . . . . . 114
-9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . . 114
-10. Security Considerations  . . . . . . . . . . . . . . . . . . . . 115
-11. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 119
-12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 120
-13. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
-13.1 NORMATIVE REFERENCES  . . . . . . . . . . . . . . . . . . . . . 120
-13.2 INFORMATIVE REFERENCES  . . . . . . . . . . . . . . . . . . . . 121
-14. Copyright Statement  . . . . . . . . . . . . . . . . . . . . . . 123
-15. Intellectual Property  . . . . . . . . . . . . . . . . . . . . . 123
-A. ASN.1 module  . . . . . . . . . . . . . . . . . . . . . . . . . . 124
-B. Changes since RFC-1510  . . . . . . . . . . . . . . . . . . . . . 132
-END NOTES  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
-
-
-
-June 2004                                                       [Page 5]
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-1. Introduction
-
-   Kerberos provides a means of verifying the identities of principals,
-   (e.g. a workstation user or a network server) on an open
-   (unprotected) network. This is accomplished without relying on
-   assertions by the host operating system, without basing trust on host
-   addresses, without requiring physical security of all the hosts on
-   the network, and under the assumption that packets traveling along
-   the network can be read, modified, and inserted at will. Kerberos
-   performs authentication under these conditions as a trusted third-
-   party authentication service by using conventional (shared secret
-   key) cryptography.  Extensions to Kerberos (outside the scope of this
-   document) can provide for the use of public key cryptography during
-   certain phases of the authentication protocol [@RFCE: if PKINIT
-   advances concurrently include reference to the RFC here]. Such
-   extensions support Kerberos authentication for users registered with
-   public key certification authorities and provide certain benefits of
-   public key cryptography in situations where they are needed.
-
-   The basic Kerberos authentication process proceeds as follows: A
-   client sends a request to the authentication server (AS) requesting
-   "credentials" for a given server. The AS responds with these
-   credentials, encrypted in the client's key. The credentials consist
-   of a "ticket" for the server and a temporary encryption key (often
-   called a "session key"). The client transmits the ticket (which
-   contains the client's identity and a copy of the session key, all
-   encrypted in the server's key) to the server. The session key (now
-   shared by the client and server) is used to authenticate the client,
-   and may optionally be used to authenticate the server. It may also be
-   used to encrypt further communication between the two parties or to
-   exchange a separate sub-session key to be used to encrypt further
-   communication.  Note that many applications use Kerberos' functions
-   only upon the initiation of a stream-based network connection. Unless
-   an application performs encryption or integrity protection for the
-   data stream, the identity verification applies only to the initiation
-   of the connection, and does not guarantee that subsequent messages on
-   the connection originate from the same principal.
-
-   Implementation of the basic protocol consists of one or more
-   authentication servers running on physically secure hosts. The
-   authentication servers maintain a database of principals (i.e., users
-   and servers) and their secret keys. Code libraries provide encryption
-   and implement the Kerberos protocol.  In order to add authentication
-   to its transactions, a typical network application adds calls to the
-   Kerberos library directly or through the Generic Security Services
-   Application Programming Interface, GSSAPI, described in separate
-   document [ref to GSSAPI RFC]. These calls result in the transmission
-   of the necessary messages to achieve authentication.
-
-
-
-June 2004                                                       [Page 6]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   The Kerberos protocol consists of several sub-protocols (or
-   exchanges).  There are two basic methods by which a client can ask a
-   Kerberos server for credentials. In the first approach, the client
-   sends a cleartext request for a ticket for the desired server to the
-   AS. The reply is sent encrypted in the client's secret key. Usually
-   this request is for a ticket-granting ticket (TGT) which can later be
-   used with the ticket-granting server (TGS).  In the second method,
-   the client sends a request to the TGS. The client uses the TGT to
-   authenticate itself to the TGS in the same manner as if it were
-   contacting any other application server that requires Kerberos
-   authentication. The reply is encrypted in the session key from the
-   TGT.  Though the protocol specification describes the AS and the TGS
-   as separate servers, they are implemented in practice as different
-   protocol entry points within a single Kerberos server.
-
-   Once obtained, credentials may be used to verify the identity of the
-   principals in a transaction, to ensure the integrity of messages
-   exchanged between them, or to preserve privacy of the messages. The
-   application is free to choose whatever protection may be necessary.
-
-   To verify the identities of the principals in a transaction, the
-   client transmits the ticket to the application server. Since the
-   ticket is sent "in the clear" (parts of it are encrypted, but this
-   encryption doesn't thwart replay) and might be intercepted and reused
-   by an attacker, additional information is sent to prove that the
-   message originated with the principal to whom the ticket was issued.
-   This information (called the authenticator) is encrypted in the
-   session key, and includes a timestamp. The timestamp proves that the
-   message was recently generated and is not a replay.  Encrypting the
-   authenticator in the session key proves that it was generated by a
-   party possessing the session key. Since no one except the requesting
-   principal and the server know the session key (it is never sent over
-   the network in the clear) this guarantees the identity of the client.
-
-   The integrity of the messages exchanged between principals can also
-   be guaranteed using the session key (passed in the ticket and
-   contained in the credentials). This approach provides detection of
-   both replay attacks and message stream modification attacks. It is
-   accomplished by generating and transmitting a collision-proof
-   checksum (elsewhere called a hash or digest function) of the client's
-   message, keyed with the session key. Privacy and integrity of the
-   messages exchanged between principals can be secured by encrypting
-   the data to be passed using the session key contained in the ticket
-   or the sub-session key found in the authenticator.
-
-   The authentication exchanges mentioned above require read-only access
-   to the Kerberos database. Sometimes, however, the entries in the
-   database must be modified, such as when adding new principals or
-
-
-
-June 2004                                                       [Page 7]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   changing a principal's key.  This is done using a protocol between a
-   client and a third Kerberos server, the Kerberos Administration
-   Server (KADM). There is also a protocol for maintaining multiple
-   copies of the Kerberos database. Neither of these protocols are
-   described in this document.
-
-1.1. Cross-realm operation
-
-   The Kerberos protocol is designed to operate across organizational
-   boundaries. A client in one organization can be authenticated to a
-   server in another. Each organization wishing to run a Kerberos server
-   establishes its own "realm". The name of the realm in which a client
-   is registered is part of the client's name, and can be used by the
-   end-service to decide whether to honor a request.
-
-   By establishing "inter-realm" keys, the administrators of two realms
-   can allow a client authenticated in the local realm to prove its
-   identity to servers in other realms. The exchange of inter-realm keys
-   (a separate key may be used for each direction) registers the ticket-
-   granting service of each realm as a principal in the other realm. A
-   client is then able to obtain a ticket-granting ticket for the remote
-   realm's ticket-granting service from its local realm. When that
-   ticket-granting ticket is used, the remote ticket-granting service
-   uses the inter-realm key (which usually differs from its own normal
-   TGS key) to decrypt the ticket-granting ticket, and is thus certain
-   that it was issued by the client's own TGS. Tickets issued by the
-   remote ticket-granting service will indicate to the end-service that
-   the client was authenticated from another realm.
-
-   WIthout cross-realm operation, and with appropriate permission the
-   client can arrange registration of a separately-named principal in a
-   remote realm, and engage in normal exchanges with that realm's
-   services. However, for even small numbers of clients this becomes
-   cumbersome, and more automatic methods as described here are
-   necessary.
-
-   A realm is said to communicate with another realm if the two realms
-   share an inter-realm key, or if the local realm shares an inter-realm
-   key with an intermediate realm that communicates with the remote
-   realm. An authentication path is the sequence of intermediate realms
-   that are transited in communicating from one realm to another.
-
-   Realms may be organized hierarchically. Each realm shares a key with
-   its parent and a different key with each child. If an inter-realm key
-   is not directly shared by two realms, the hierarchical organization
-   allows an authentication path to be easily constructed. If a
-   hierarchical organization is not used, it may be necessary to consult
-   a database in order to construct an authentication path between
-
-
-
-June 2004                                                       [Page 8]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   realms.
-
-   Although realms are typically hierarchical, intermediate realms may
-   be bypassed to achieve cross-realm authentication through alternate
-   authentication paths (these might be established to make
-   communication between two realms more efficient). It is important for
-   the end-service to know which realms were transited when deciding how
-   much faith to place in the authentication process. To facilitate this
-   decision, a field in each ticket contains the names of the realms
-   that were involved in authenticating the client.
-
-   The application server is ultimately responsible for accepting or
-   rejecting authentication and SHOULD check the transited field. The
-   application server may choose to rely on the KDC for the application
-   server's realm to check the transited field. The application server's
-   KDC will set the TRANSITED-POLICY-CHECKED flag in this case. The KDCs
-   for intermediate realms may also check the transited field as they
-   issue ticket-granting tickets for other realms, but they are
-   encouraged not to do so. A client may request that the KDCs not check
-   the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs
-   SHOULD honor this flag.
-
-1.2. Choosing a principal with which to communicate
-
-   The Kerberos protocol provides the means for verifying (subject to
-   the assumptions in 1.5) that the entity with which one communicates
-   is the same entity that was registered with the KDC using the claimed
-   identity (principal name). It is still necessary to determine whether
-   that identity corresponds to the entity with which one intends to
-   communicate.
-
-   When appropriate data has been exchanged in advance, this
-   determination may be performed syntactically by the application based
-   on the application protocol specification, information provided by
-   the user, and configuration files. For example, the server principal
-   name (including realm) for a telnet server might be derived from the
-   user specified host name (from the telnet command line), the "host/"
-   prefix specified in the application protocol specification, and a
-   mapping to a Kerberos realm derived syntactically from the domain
-   part of the specified hostname and information from the local
-   Kerberos realms database.
-
-   One can also rely on trusted third parties to make this
-   determination, but only when the data obtained from the third party
-   is suitably integrity protected while resident on the third party
-   server and when transmitted.  Thus, for example, one should not rely
-   on an unprotected domain name system record to map a host alias to
-   the primary name of a server, accepting the primary name as the party
-
-
-
-June 2004                                                       [Page 9]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   one intends to contact, since an attacker can modify the mapping and
-   impersonate the party with which one intended to communicate.
-
-   Implementations of Kerberos and protocols based on Kerberos MUST NOT
-   use insecure DNS queries to canonicalize the hostname components of
-   the service principal names (i.e. MUST NOT use insecure DNS queries
-   to map one name to another to determine the host part of the
-   principal name with which one is to communicate).  In an environment
-   without secure name service, application authors MAY append a
-   statically configured domain name to unqualified hostnames before
-   passing the name to the security mechanisms, but should do no more
-   than that.  Secure name service facilities, if available, might be
-   trusted for hostname canonicalization, but such canonicalization by
-   the client SHOULD NOT be required by KDC implementations.
-
-   Implementation note: Many current implementations do some degree of
-   canonicalization of the provided service name, often using DNS even
-   though it creates security problems. However there is no consistency
-   among implementations about whether the service name is case folded
-   to lower case or whether reverse resolution is used. To maximize
-   interoperability and security, applications SHOULD provide security
-   mechanisms with names which result from folding the user-entered name
-   to lower case, without performing any other modifications or
-   canonicalization.
-
-1.3. Authorization
-
-   As an authentication service, Kerberos provides a means of verifying
-   the identity of principals on a network. Authentication is usually
-   useful primarily as a first step in the process of authorization,
-   determining whether a client may use a service, which objects the
-   client is allowed to access, and the type of access allowed for each.
-   Kerberos does not, by itself, provide authorization. Possession of a
-   client ticket for a service provides only for authentication of the
-   client to that service, and in the absence of a separate
-   authorization procedure, it should not be considered by an
-   application as authorizing the use of that service.
-
-   Such separate authorization methods MAY be implemented as application
-   specific access control functions and may utilize files on the
-   application server, or on separately issued authorization credentials
-   such as those based on proxies [Neu93], or on other authorization
-   services. Separately authenticated authorization credentials MAY be
-   embedded in a ticket's authorization data when encapsulated by the
-   KDC-issued authorization data element.
-
-   Applications should not accept the mere issuance of a service ticket
-   by the Kerberos server (even by a modified Kerberos server) as
-
-
-
-June 2004                                                      [Page 10]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   granting authority to use the service, since such applications may
-   become vulnerable to the bypass of this authorization check in an
-   environment if they interoperate with other KDCs or where other
-   options for application authentication are provided.
-
-1.4. Extending Kerberos Without Breaking Interoperability
-
-   As the deployed base of Kerberos implementations grows, extending
-   Kerberos becomes more important. Unfortunately some extensions to the
-   existing Kerberos protocol create interoperability issues because of
-   uncertainty regarding the treatment of certain extensibility options
-   by some implementations. This section includes guidelines that will
-   enable future implementations to maintain interoperability.
-
-   Kerberos provides a general mechanism for protocol extensibility.
-   Some protocol messages contain typed holes -- sub-messages that
-   contain an octet-string along with an integer that defines how to
-   interpret the octet-string. The integer types are registered
-   centrally, but can be used both for vendor extensions and for
-   extensions standardized through the IETF.
-
-   In this document, the word "extension" means an extension by defining
-   a new type to insert into an existing typed hole in a protocol
-   message.  It does not mean extension by addition of new fields to
-   ASN.1 types, unless explicitly indicated otherwise in the text.
-
-1.4.1. Compatibility with RFC 1510
-
-   It is important to note that existing Kerberos message formats can
-   not be readily extended by adding fields to the ASN.1 types. Sending
-   additional fields often results in the entire message being discarded
-   without an error indication. Future versions of this specification
-   will provide guidelines to ensure that ASN.1 fields can be added
-   without creating an interoperability problem.
-
-   In the meantime, all new or modified implementations of Kerberos that
-   receive an unknown message extension SHOULD preserve the encoding of
-   the extension but otherwise ignore the presence of the extension.
-   Recipients MUST NOT decline a request simply because an extension is
-   present.
-
-   There is one exception to this rule. If an unknown authorization data
-   element type is received by a server other than the ticket granting
-   service either in an AP-REQ or in a ticket contained in an AP-REQ,
-   then authentication MUST fail. One of the primary uses of
-   authorization data is to restrict the use of the ticket. If the
-   service cannot determine whether the restriction applies to that
-   service then a security weakness may result if the ticket can be used
-
-
-
-June 2004                                                      [Page 11]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   for that service. Authorization elements that are optional SHOULD be
-   enclosed in the AD-IF-RELEVANT element.
-
-   The ticket granting service MUST ignore but propagate to derivative
-   tickets any unknown authorization data types, unless those data types
-   are embedded in a MANDATORY-FOR-KDC element, in which case the
-   request will be rejected.  This behavior is appropriate because
-   requiring that the ticket granting service understand unknown
-   authorization data types would require that KDC software be upgraded
-   to understand new application-level restrictions before applications
-   used these restrictions, decreasing the utility of authorization data
-   as a mechanism for restricting the use of tickets. No security
-   problem is created because services to which the tickets are issued
-   will verify the authorization data.
-
-   Implementation note: Many RFC 1510 implementations ignore unknown
-   authorization data elements. Depending on these implementations to
-   honor authorization data restrictions may create a security weakness.
-
-1.4.2. Sending Extensible Messages
-
-   Care must be taken to ensure that old implementations can understand
-   messages sent to them even if they do not understand an extension
-   that is used. Unless the sender knows an extension is supported, the
-   extension cannot change the semantics of the core message or
-   previously defined extensions.
-
-   For example, an extension including key information necessary to
-   decrypt the encrypted part of a KDC-REP could only be used in
-   situations where the recipient was known to support the extension.
-   Thus when designing such extensions it is important to provide a way
-   for the recipient to notify the sender of support for the extension.
-   For example in the case of an extension that changes the KDC-REP
-   reply key, the client could indicate support for the extension by
-   including a padata element in the AS-REQ sequence. The KDC should
-   only use the extension if this padata element is present in the AS-
-   REQ. Even if policy requires the use of the extension, it is better
-   to return an error indicating that the extension is required than to
-   use the extension when the recipient may not support it; debugging
-   why implementations do not interoperate is easier when errors are
-   returned.
-
-1.5. Environmental assumptions
-
-   Kerberos imposes a few assumptions on the environment in which it can
-   properly function:
-
-   *  "Denial of service" attacks are not solved with Kerberos. There
-
-
-
-June 2004                                                      [Page 12]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      are places in the protocols where an intruder can prevent an
-      application from participating in the proper authentication steps.
-      Detection and solution of such attacks (some of which can appear
-      to be not-uncommon "normal" failure modes for the system) is
-      usually best left to the human administrators and users.
-
-   *  Principals MUST keep their secret keys secret. If an intruder
-      somehow steals a principal's key, it will be able to masquerade as
-      that principal or impersonate any server to the legitimate
-      principal.
-
-   *  "Password guessing" attacks are not solved by Kerberos. If a user
-      chooses a poor password, it is possible for an attacker to
-      successfully mount an offline dictionary attack by repeatedly
-      attempting to decrypt, with successive entries from a dictionary,
-      messages obtained which are encrypted under a key derived from the
-      user's password.
-
-   *  Each host on the network MUST have a clock which is "loosely
-      synchronized" to the time of the other hosts; this synchronization
-      is used to reduce the bookkeeping needs of application servers
-      when they do replay detection. The degree of "looseness" can be
-      configured on a per-server basis, but is typically on the order of
-      5 minutes. If the clocks are synchronized over the network, the
-      clock synchronization protocol MUST itself be secured from network
-      attackers.
-
-   *  Principal identifiers are not recycled on a short-term basis. A
-      typical mode of access control will use access control lists
-      (ACLs) to grant permissions to particular principals. If a stale
-      ACL entry remains for a deleted principal and the principal
-      identifier is reused, the new principal will inherit rights
-      specified in the stale ACL entry. By not re-using principal
-      identifiers, the danger of inadvertent access is removed.
-
-1.6. Glossary of terms
-
-      Below is a list of terms used throughout this document.
-
-   Authentication
-      Verifying the claimed identity of a principal.
-
-   Authentication header
-      A record containing a Ticket and an Authenticator to be presented
-      to a server as part of the authentication process.
-
-   Authentication path
-      A sequence of intermediate realms transited in the authentication
-
-
-
-June 2004                                                      [Page 13]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      process when communicating from one realm to another.
-
-   Authenticator
-      A record containing information that can be shown to have been
-      recently generated using the session key known only by the client
-      and server.
-
-   Authorization
-      The process of determining whether a client may use a service,
-      which objects the client is allowed to access, and the type of
-      access allowed for each.
-
-   Capability
-      A token that grants the bearer permission to access an object or
-      service. In Kerberos, this might be a ticket whose use is
-      restricted by the contents of the authorization data field, but
-      which lists no network addresses, together with the session key
-      necessary to use the ticket.
-
-   Ciphertext
-      The output of an encryption function. Encryption transforms
-      plaintext into ciphertext.
-
-   Client
-      A process that makes use of a network service on behalf of a user.
-      Note that in some cases a Server may itself be a client of some
-      other server (e.g. a print server may be a client of a file
-      server).
-
-   Credentials
-      A ticket plus the secret session key necessary to successfully use
-      that ticket in an authentication exchange.
-
-   Encryption Type (etype)
-      When associated with encrypted data, an encryption type identifies
-      the algorithm used to encrypt the data and is used to select the
-      appropriate algorithm for decrypting the data.  Encryption type
-      tags are communicated in other messages to enumerate algorithms
-      that are desired, supported, preferred, or allowed to be used for
-      encryption of data between parties.  This preference is combined
-      with local information and policy to select an algorithm to be
-      used.
-
-   KDC
-      Key Distribution Center, a network service that supplies tickets
-      and temporary session keys; or an instance of that service or the
-      host on which it runs. The KDC services both initial ticket and
-      ticket-granting ticket requests. The initial ticket portion is
-
-
-
-June 2004                                                      [Page 14]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      sometimes referred to as the Authentication Server (or service).
-      The ticket-granting ticket portion is sometimes referred to as the
-      ticket-granting server (or service).
-
-   Kerberos
-      The name given to the Project Athena's authentication service, the
-      protocol used by that service, or the code used to implement the
-      authentication service.  The name is adopted from the three-headed
-      dog which guards Hades.
-
-   Key Version Number (kvno)
-      A tag associated with encrypted data identifies which key was used
-      for encryption when a long lived key associated with a principal
-      changes over time.  It is used during the transition to a new key
-      so that the party decrypting a message can tell whether the data
-      was encrypted using the old or the new key.
-
-   Plaintext
-      The input to an encryption function or the output of a decryption
-      function. Decryption transforms ciphertext into plaintext.
-
-   Principal
-      A named client or server entity that participates in a network
-      communication, with one name that is considered canonical.
-
-   Principal identifier
-      The canonical name used to uniquely identify each different
-      principal.
-
-   Seal
-      To encipher a record containing several fields in such a way that
-      the fields cannot be individually replaced without either
-      knowledge of the encryption key or leaving evidence of tampering.
-
-   Secret key
-      An encryption key shared by a principal and the KDC, distributed
-      outside the bounds of the system, with a long lifetime. In the
-      case of a human user's principal, the secret key MAY be derived
-      from a password.
-
-   Server
-      A particular Principal which provides a resource to network
-      clients.  The server is sometimes referred to as the Application
-      Server.
-
-   Service
-      A resource provided to network clients; often provided by more
-      than one server (for example, remote file service).
-
-
-
-June 2004                                                      [Page 15]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   Session key
-      A temporary encryption key used between two principals, with a
-      lifetime limited to the duration of a single login "session".  In
-      the Kerberos system, a session key is generated by the KDC.  The
-      session key is distinct from the sub-session key, described next..
-
-   Sub-session key
-      A temporary encryption key used between two principals, selected
-      and exchanged by the principals using the session key, and with a
-      lifetime limited to the duration of a single association. The sub-
-      session key is also referred to as the subkey.
-
-   Ticket
-      A record that helps a client authenticate itself to a server; it
-      contains the client's identity, a session key, a timestamp, and
-      other information, all sealed using the server's secret key. It
-      only serves to authenticate a client when presented along with a
-      fresh Authenticator.
-
-
-2. Ticket flag uses and requests
-
-   Each Kerberos ticket contains a set of flags which are used to
-   indicate attributes of that ticket. Most flags may be requested by a
-   client when the ticket is obtained; some are automatically turned on
-   and off by a Kerberos server as required. The following sections
-   explain what the various flags mean and give examples of reasons to
-   use them. With the exception of the INVALID flag clients MUST ignore
-   ticket flags that are not recognized. KDCs MUST ignore KDC options
-   that are not recognized. Some implementations of RFC 1510 are known
-   to reject unknown KDC options, so clients may need to resend a
-   request without new KDC options if the request was rejected when sent
-   with options added since RFC 1510. Since new KDCs will ignore unknown
-   options, clients MUST confirm that the ticket returned by the KDC
-   meets their needs.
-
-   Note that it is not, in general, possible to determine whether an
-   option was not honored because it was not understood or because it
-   was rejected either through configuration or policy. When adding a
-   new option to the Kerberos protocol, designers should consider
-   whether the distinction is important for their option. In cases where
-   it is, a mechanism for the KDC to return an indication that the
-   option was understood but rejected needs to be provided in the
-   specification of the option. Often in such cases, the mechanism needs
-   to be broad enough to permit an error or reason to be returned.
-
-2.1. Initial, pre-authenticated, and hardware authenticated tickets
-
-
-
-
-June 2004                                                      [Page 16]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   The INITIAL flag indicates that a ticket was issued using the AS
-   protocol, rather than issued based on a ticket-granting ticket.
-   Application servers that want to require the demonstrated knowledge
-   of a client's secret key (e.g. a password-changing program) can
-   insist that this flag be set in any tickets they accept, and thus be
-   assured that the client's key was recently presented to the
-   application client.
-
-   The PRE-AUTHENT and HW-AUTHENT flags provide additional information
-   about the initial authentication, regardless of whether the current
-   ticket was issued directly (in which case INITIAL will also be set)
-   or issued on the basis of a ticket-granting ticket (in which case the
-   INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are
-   carried forward from the ticket-granting ticket).
-
-2.2. Invalid tickets
-
-   The INVALID flag indicates that a ticket is invalid. Application
-   servers MUST reject tickets which have this flag set. A postdated
-   ticket will be issued in this form. Invalid tickets MUST be validated
-   by the KDC before use, by presenting them to the KDC in a TGS request
-   with the VALIDATE option specified. The KDC will only validate
-   tickets after their starttime has passed. The validation is required
-   so that postdated tickets which have been stolen before their
-   starttime can be rendered permanently invalid (through a hot-list
-   mechanism) (see section 3.3.3.1).
-
-2.3. Renewable tickets
-
-   Applications may desire to hold tickets which can be valid for long
-   periods of time. However, this can expose their credentials to
-   potential theft for equally long periods, and those stolen
-   credentials would be valid until the expiration time of the
-   ticket(s). Simply using short-lived tickets and obtaining new ones
-   periodically would require the client to have long-term access to its
-   secret key, an even greater risk. Renewable tickets can be used to
-   mitigate the consequences of theft. Renewable tickets have two
-   "expiration times": the first is when the current instance of the
-   ticket expires, and the second is the latest permissible value for an
-   individual expiration time. An application client must periodically
-   (i.e. before it expires) present a renewable ticket to the KDC, with
-   the RENEW option set in the KDC request. The KDC will issue a new
-   ticket with a new session key and a later expiration time. All other
-   fields of the ticket are left unmodified by the renewal process. When
-   the latest permissible expiration time arrives, the ticket expires
-   permanently. At each renewal, the KDC MAY consult a hot-list to
-   determine if the ticket had been reported stolen since its last
-   renewal; it will refuse to renew such stolen tickets, and thus the
-
-
-
-June 2004                                                      [Page 17]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   usable lifetime of stolen tickets is reduced.
-
-   The RENEWABLE flag in a ticket is normally only interpreted by the
-   ticket-granting service (discussed below in section 3.3). It can
-   usually be ignored by application servers. However, some particularly
-   careful application servers MAY disallow renewable tickets.
-
-   If a renewable ticket is not renewed by its expiration time, the KDC
-   will not renew the ticket. The RENEWABLE flag is reset by default,
-   but a client MAY request it be set by setting the RENEWABLE option in
-   the KRB_AS_REQ message. If it is set, then the renew-till field in
-   the ticket contains the time after which the ticket may not be
-   renewed.
-
-2.4. Postdated tickets
-
-   Applications may occasionally need to obtain tickets for use much
-   later, e.g. a batch submission system would need tickets to be valid
-   at the time the batch job is serviced. However, it is dangerous to
-   hold valid tickets in a batch queue, since they will be on-line
-   longer and more prone to theft.  Postdated tickets provide a way to
-   obtain these tickets from the KDC at job submission time, but to
-   leave them "dormant" until they are activated and validated by a
-   further request of the KDC. If a ticket theft were reported in the
-   interim, the KDC would refuse to validate the ticket, and the thief
-   would be foiled.
-
-   The MAY-POSTDATE flag in a ticket is normally only interpreted by the
-   ticket-granting service. It can be ignored by application servers.
-   This flag MUST be set in a ticket-granting ticket in order to issue a
-   postdated ticket based on the presented ticket. It is reset by
-   default; it MAY be requested by a client by setting the ALLOW-
-   POSTDATE option in the KRB_AS_REQ message.  This flag does not allow
-   a client to obtain a postdated ticket-granting ticket; postdated
-   ticket-granting tickets can only by obtained by requesting the
-   postdating in the KRB_AS_REQ message. The life (endtime-starttime) of
-   a postdated ticket will be the remaining life of the ticket-granting
-   ticket at the time of the request, unless the RENEWABLE option is
-   also set, in which case it can be the full life (endtime-starttime)
-   of the ticket-granting ticket. The KDC MAY limit how far in the
-   future a ticket may be postdated.
-
-   The POSTDATED flag indicates that a ticket has been postdated. The
-   application server can check the authtime field in the ticket to see
-   when the original authentication occurred. Some services MAY choose
-   to reject postdated tickets, or they may only accept them within a
-   certain period after the original authentication. When the KDC issues
-   a POSTDATED ticket, it will also be marked as INVALID, so that the
-
-
-
-June 2004                                                      [Page 18]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   application client MUST present the ticket to the KDC to be validated
-   before use.
-
-2.5. Proxiable and proxy tickets
-
-   At times it may be necessary for a principal to allow a service to
-   perform an operation on its behalf. The service must be able to take
-   on the identity of the client, but only for a particular purpose. A
-   principal can allow a service to take on the principal's identity for
-   a particular purpose by granting it a proxy.
-
-   The process of granting a proxy using the proxy and proxiable flags
-   is used to provide credentials for use with specific services. Though
-   conceptually also a proxy, users wishing to delegate their identity
-   in a form usable for all purpose MUST use the ticket forwarding
-   mechanism described in the next section to forward a ticket-granting
-   ticket.
-
-   The PROXIABLE flag in a ticket is normally only interpreted by the
-   ticket-granting service. It can be ignored by application servers.
-   When set, this flag tells the ticket-granting server that it is OK to
-   issue a new ticket (but not a ticket-granting ticket) with a
-   different network address based on this ticket. This flag is set if
-   requested by the client on initial authentication. By default, the
-   client will request that it be set when requesting a ticket-granting
-   ticket, and reset when requesting any other ticket.
-
-   This flag allows a client to pass a proxy to a server to perform a
-   remote request on its behalf (e.g. a print service client can give
-   the print server a proxy to access the client's files on a particular
-   file server in order to satisfy a print request).
-
-   In order to complicate the use of stolen credentials, Kerberos
-   tickets are often valid from only those network addresses
-   specifically included in the ticket, but it is permissible as a
-   policy option to allow requests and issue tickets with no network
-   addresses specified.  When granting a proxy, the client MUST specify
-   the new network address from which the proxy is to be used, or
-   indicate that the proxy is to be issued for use from any address.
-
-   The PROXY flag is set in a ticket by the TGS when it issues a proxy
-   ticket.  Application servers MAY check this flag and at their option
-   they MAY require additional authentication from the agent presenting
-   the proxy in order to provide an audit trail.
-
-2.6. Forwardable tickets
-
-   Authentication forwarding is an instance of a proxy where the service
-
-
-
-June 2004                                                      [Page 19]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   that is granted is complete use of the client's identity. An example
-   where it might be used is when a user logs in to a remote system and
-   wants authentication to work from that system as if the login were
-   local.
-
-   The FORWARDABLE flag in a ticket is normally only interpreted by the
-   ticket-granting service. It can be ignored by application servers.
-   The FORWARDABLE flag has an interpretation similar to that of the
-   PROXIABLE flag, except ticket-granting tickets may also be issued
-   with different network addresses. This flag is reset by default, but
-   users MAY request that it be set by setting the FORWARDABLE option in
-   the AS request when they request their initial ticket-granting
-   ticket.
-
-   This flag allows for authentication forwarding without requiring the
-   user to enter a password again. If the flag is not set, then
-   authentication forwarding is not permitted, but the same result can
-   still be achieved if the user engages in the AS exchange specifying
-   the requested network addresses and supplies a password.
-
-   The FORWARDED flag is set by the TGS when a client presents a ticket
-   with the FORWARDABLE flag set and requests a forwarded ticket by
-   specifying the FORWARDED KDC option and supplying a set of addresses
-   for the new ticket. It is also set in all tickets issued based on
-   tickets with the FORWARDED flag set. Application servers may choose
-   to process FORWARDED tickets differently than non-FORWARDED tickets.
-
-   If addressless tickets are forwarded from one system to another,
-   clients SHOULD still use this option to obtain a new TGT in order to
-   have different session keys on the different systems.
-
-2.7. Transited Policy Checking
-
-   In Kerberos, the application server is ultimately responsible for
-   accepting or rejecting authentication and SHOULD check that only
-   suitably trusted KDCs are relied upon to authenticate a principal.
-   The transited field in the ticket identifies which realms (and thus
-   which KDCs) were involved in the authentication process and an
-   application server would normally check this field. If any of these
-   are untrusted to authenticate the indicated client principal
-   (probably determined by a realm-based policy), the authentication
-   attempt MUST be rejected. The presence of trusted KDCs in this list
-   does not provide any guarantee; an untrusted KDC may have fabricated
-   the list.
-
-   While the end server ultimately decides whether authentication is
-   valid, the KDC for the end server's realm MAY apply a realm specific
-   policy for validating the transited field and accepting credentials
-
-
-
-June 2004                                                      [Page 20]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   for cross-realm authentication. When the KDC applies such checks and
-   accepts such cross-realm authentication it will set the TRANSITED-
-   POLICY-CHECKED flag in the service tickets it issues based on the
-   cross-realm TGT. A client MAY request that the KDCs not check the
-   transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs are
-   encouraged but not required to honor this flag.
-
-   Application servers MUST either do the transited-realm checks
-   themselves, or reject cross-realm tickets without TRANSITED-POLICY-
-   CHECKED set.
-
-2.8. OK as Delegate
-
-   For some applications a client may need to delegate authority to a
-   server to act on its behalf in contacting other services.  This
-   requires that the client forward credentials to an intermediate
-   server.  The ability for a client to obtain a service ticket to a
-   server conveys no information to the client about whether the server
-   should be trusted to accept delegated credentials.  The OK-AS-
-   DELEGATE provides a way for a KDC to communicate local realm policy
-   to a client regarding whether an intermediate server is trusted to
-   accept such credentials.
-
-   The copy of the ticket flags in the encrypted part of the KDC reply
-   may have the OK-AS-DELEGATE flag set to indicates to the client that
-   the server specified in the ticket has been determined by policy of
-   the realm to be a suitable recipient of delegation.  A client can use
-   the presence of this flag to help it make a decision whether to
-   delegate credentials (either grant a proxy or a forwarded ticket-
-   granting ticket) to this server.  It is acceptable to ignore the
-   value of this flag. When setting this flag, an administrator should
-   consider the security and placement of the server on which the
-   service will run, as well as whether the service requires the use of
-   delegated credentials.
-
-2.9. Other KDC options
-
-   There are three additional options which MAY be set in a client's
-   request of the KDC.
-
-2.9.1. Renewable-OK
-
-   The RENEWABLE-OK option indicates that the client will accept a
-   renewable ticket if a ticket with the requested life cannot otherwise
-   be provided. If a ticket with the requested life cannot be provided,
-   then the KDC MAY issue a renewable ticket with a renew-till equal to
-   the requested endtime. The value of the renew-till field MAY still be
-   adjusted by site-determined limits or limits imposed by the
-
-
-
-June 2004                                                      [Page 21]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   individual principal or server.
-
-2.9.2. ENC-TKT-IN-SKEY
-
-   In its basic form the Kerberos protocol supports authentication in a
-   client-server
-    setting and is not well suited to authentication in a peer-to-peer
-   environment because the long term key of the user does not remain on
-   the workstation after initial login. Authentication of such peers may
-   be supported by Kerberos in its user-to-user variant. The ENC-TKT-IN-
-   SKEY option supports user-to-user authentication by allowing the KDC
-   to issue a service ticket encrypted using the session key from
-   another ticket-granting ticket issued to another user. The ENC-TKT-
-   IN-SKEY option is honored only by the ticket-granting service. It
-   indicates that the ticket to be issued for the end server is to be
-   encrypted in the session key from the additional second ticket-
-   granting ticket provided with the request. See section 3.3.3 for
-   specific details.
-
-2.9.3. Passwordless Hardware Authentication
-
-   The OPT-HARDWARE-AUTH option indicates that the client wishes to use
-   some form of hardware authentication instead of or in addition to the
-   client's password or other long-lived encryption key. OPT-HARDWARE-
-   AUTH is honored only by the authentication service. If supported and
-   allowed by policy, the KDC will return an errorcode
-   KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to
-   perform such authentication.
-
-3. Message Exchanges
-
-   The following sections describe the interactions between network
-   clients and servers and the messages involved in those exchanges.
-
-3.1. The Authentication Service Exchange
-
-                             Summary
-
-         Message direction       Message type    Section
-         1. Client to Kerberos   KRB_AS_REQ      5.4.1
-         2. Kerberos to client   KRB_AS_REP or   5.4.2
-                                 KRB_ERROR       5.9.1
-
-   the Kerberos Authentication Server is initiated by a client when it
-   wishes to obtain authentication credentials for a given server but
-   currently holds no credentials. In its basic form, the client's
-   secret key is used for encryption and decryption. This exchange is
-   typically used at the initiation of a login session to obtain
-
-
-
-June 2004                                                      [Page 22]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   credentials for a Ticket-Granting Server which will subsequently be
-   used to obtain credentials for other servers (see section 3.3)
-   without requiring further use of the client's secret key. This
-   exchange is also used to request credentials for services which must
-   not be mediated through the Ticket-Granting Service, but rather
-   require a principal's secret key, such as the password-changing
-   service for which the request must not be honored unless the
-   requester can provide the users old password (preventing someone from
-   walking up to an unattended session and changing another user's
-   password).
-
-   This exchange does not by itself provide any assurance of the
-   identity of the user. To authenticate a user logging on to a local
-   system, the credentials obtained in the AS exchange may first be used
-   in a TGS exchange to obtain credentials for a local server. Those
-   credentials must then be verified by a local server through
-   successful completion of the Client/Server exchange.
-
-   The AS exchange consists of two messages: KRB_AS_REQ from the client
-   to Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for
-   these messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
-
-   In the request, the client sends (in cleartext) its own identity and
-   the identity of the server for which it is requesting credentials,
-   other information about the credentials it is requesting, and a
-   randomly generated nonce which can be used to detect replays, and to
-   associate replies with the matching requests. This nonce MUST be
-   generated randomly by the client and remembered for checking against
-   the nonce in the expected reply. The response, KRB_AS_REP, contains a
-   ticket for the client to present to the server, and a session key
-   that will be shared by the client and the server.  The session key
-   and additional information are encrypted in the client's secret key.
-   The encrypted part of the KRB_AS_REP message also contains the nonce
-   which MUST be matched with the nonce from the KRB_AS_REQ message.
-
-   Without pre-authentication, the authentication server does not know
-   whether the client is actually the principal named in the request. It
-   simply sends a reply without knowing or caring whether they are the
-   same. This is acceptable because nobody but the principal whose
-   identity was given in the request will be able to use the reply. Its
-   critical information is encrypted in that principal's key. However,
-   an attacker can send a KRB_AS_REQ message to get known plaintext in
-   order to attack the principal's key. Especially if the key is based
-   on a password, this may create a security exposure. So, the initial
-   request supports an optional field that can be used to pass
-   additional information that might be needed for the initial exchange.
-   This field SHOULD be used for pre-authentication as described in
-   sections 3.1.1 and 5.2.7.
-
-
-
-June 2004                                                      [Page 23]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   Various errors can occur; these are indicated by an error response
-   (KRB_ERROR) instead of the KRB_AS_REP response. The error message is
-   not encrypted. The KRB_ERROR message contains information which can
-   be used to associate it with the message to which it replies. The
-   contents of the KRB_ERROR message are not integrity-protected. As
-   such, the client cannot detect replays, fabrications or
-   modifications. A solution to this problem will be included in a
-   future version of the protocol.
-
-3.1.1. Generation of KRB_AS_REQ message
-
-   The client may specify a number of options in the initial request.
-   Among these options are whether pre-authentication is to be
-   performed; whether the requested ticket is to be renewable,
-   proxiable, or forwardable; whether it should be postdated or allow
-   postdating of derivative tickets; and whether a renewable ticket will
-   be accepted in lieu of a non-renewable ticket if the requested ticket
-   expiration date cannot be satisfied by a non-renewable ticket (due to
-   configuration constraints).
-
-   The client prepares the KRB_AS_REQ message and sends it to the KDC.
-
-3.1.2. Receipt of KRB_AS_REQ message
-
-   If all goes well, processing the KRB_AS_REQ message will result in
-   the creation of a ticket for the client to present to the server. The
-   format for the ticket is described in section 5.3.
-
-   Because Kerberos can run over unreliable transports such as UDP, the
-   KDC MUST be prepared to retransmit responses in case they are lost.
-   If a KDC receives a request identical to one it has recently
-   successfully processed, the KDC MUST respond with a KRB_AS_REP
-   message rather than a replay error.  In order to reduce ciphertext
-   given to a potential attacker, KDCs MAY send the same response
-   generated when the request was first handled. KDCs MUST obey this
-   replay behavior even if the actual transport in use is reliable.
-
-3.1.3. Generation of KRB_AS_REP message
-
-   The authentication server looks up the client and server principals
-   named in the KRB_AS_REQ in its database, extracting their respective
-   keys. If the requested client principal named in the request is not
-   known because it doesn't exist in the KDC's principal database, then
-   an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
-
-   If required, the server pre-authenticates the request, and if the
-   pre-authentication check fails, an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is
-
-
-
-June 2004                                                      [Page 24]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   required, but was not present in the request, an error message with
-   the code KDC_ERR_PREAUTH_REQUIRED is returned and a METHOD-DATA
-   object will be stored in the e-data field of the KRB-ERROR message to
-   specify which pre-authentication mechanisms are acceptable.  Usually
-   this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as
-   described below. If the server cannot accommodate any encryption type
-   requested by the client, an error message with code
-   KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC generates a
-   'random' session key, meaning that, among other things, it should be
-   impossible to guess the next session key based on knowledge of past
-   session keys. This can only be achieved in a pseudo-random number
-   generator if it is based on cryptographic principles. It is more
-   desirable to use a truly random number generator, such as one based
-   on measurements of random physical phenomena.  See [RFC1750] for an
-   in depth discussion of randomness.
-
-   When responding to an AS request, if there are multiple encryption
-   keys registered for a client in the Kerberos database, then the etype
-   field from the AS request is used by the KDC to select the encryption
-   method to be used to protect the encrypted part of the KRB_AS_REP
-   message which is sent to the client. If there is more than one
-   supported strong encryption type in the etype list, the KDC SHOULD
-   use the first valid strong etype for which an encryption key is
-   available.
-
-   When the user's key is generated from a password or pass phrase, the
-   string-to-key function for the particular encryption key type is
-   used, as specified in [@KCRYPTO]. The salt value and additional
-   parameters for the string-to-key function have default values
-   (specified by section 4 and by the encryption mechanism
-   specification, respectively) that may be overridden by pre-
-   authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-
-   ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of the
-   resulting key only, these values should not be changed for password-
-   based keys except when changing the principal's key.
-
-   When the AS server is to include pre-authentication data in a KRB-
-   ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-INFO,
-   if the etype field of the client's AS-REQ lists at least one "newer"
-   encryption type.  Otherwise (when the etype field of the client's AS-
-   REQ does not list any "newer" encryption types) it MUST send both,
-   PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for each
-   enctype).  A "newer" enctype is any enctype first officially
-   specified concurrently with or subsequent to the issue of this RFC.
-   The enctypes DES, 3DES or RC4 and any defined in [RFC1510] are not
-   "newer" enctypes.
-
-   It is not possible to reliably generate a user's key given a pass
-
-
-
-June 2004                                                      [Page 25]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   phrase without contacting the KDC, since it will not be known whether
-   alternate salt or parameter values are required.
-
-   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.
-
-   If the requested start time is absent, indicates a time in the past,
-   or is within the window of acceptable clock skew for the KDC and the
-   POSTDATE option has not been specified, then the start time of the
-   ticket is set to the authentication server's current time. If it
-   indicates a time in the future beyond the acceptable clock skew, but
-   the POSTDATED option has not been specified then the error
-   KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start
-   time is checked against the policy of the local realm (the
-   administrator might decide to prohibit certain types or ranges of
-   postdated tickets), and if acceptable, the ticket's start time is set
-   as requested and the INVALID flag is set in the new ticket. The
-   postdated ticket MUST be validated before use by presenting it to the
-   KDC after the start time has been reached.
-
-   The expiration time of the ticket will be set to the earlier of the
-   requested endtime and a time determined by local policy, possibly
-   determined using realm or principal specific factors. For example,
-   the expiration time MAY be set to the earliest of the following:
-
-      *  The expiration time (endtime) requested in the KRB_AS_REQ
-         message.
-
-      *  The ticket's start time plus the maximum allowable lifetime
-         associated with the client principal from the authentication
-         server's database.
-
-      *  The ticket's start time plus the maximum allowable lifetime
-         associated with the server principal.
-
-      *  The ticket's start time plus the maximum lifetime set by the
-         policy of the local realm.
-
-   If the requested expiration time minus the start time (as determined
-   above) is less than a site-determined minimum lifetime, an error
-   message with code KDC_ERR_NEVER_VALID is returned. If the requested
-   expiration time for the ticket exceeds what was determined as above,
-   and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE'
-   flag is set in the new ticket, and the renew-till value is set as if
-
-
-
-June 2004                                                      [Page 26]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   the 'RENEWABLE' option were requested (the field and option names are
-   described fully in section 5.4.1).
-
-   If the RENEWABLE option has been requested or if the RENEWABLE-OK
-   option has been set and a renewable ticket is to be issued, then the
-   renew-till field MAY be set to the earliest of:
-
-      *  Its requested value.
-
-      *  The start time of the ticket plus the minimum of the two
-         maximum renewable lifetimes associated with the principals'
-         database entries.
-
-      *  The start time of the ticket plus the maximum renewable
-         lifetime set by the policy of the local realm.
-
-   The flags field of the new ticket will have the following options set
-   if they have been requested and if the policy of the local realm
-   allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
-   If the new ticket is postdated (the start time is in the future), its
-   INVALID flag will also be set.
-
-   If all of the above succeed, the server will encrypt the ciphertext
-   part of the ticket using the encryption key extracted from the server
-   principal's record in the Kerberos database using the encryption type
-   associated with the server principal's key (this choice is NOT
-   affected by the etype field in the request). It then formats a
-   KRB_AS_REP message (see section 5.4.2), copying the addresses in the
-   request into the caddr of the response, placing any required pre-
-   authentication data into the padata of the response, and encrypts the
-   ciphertext part in the client's key using an acceptable encryption
-   method requested in the etype field of the request, or in some key
-   specified by pre-authentication mechanisms being used.
-
-3.1.4. Generation of KRB_ERROR message
-
-   Several errors can occur, and the Authentication Server responds by
-   returning an error message, KRB_ERROR, to the client, with the error-
-   code and e-text fields set to appropriate values. The error message
-   contents and details are described in Section 5.9.1.
-
-3.1.5. Receipt of KRB_AS_REP message
-
-   If the reply message type is KRB_AS_REP, then the client verifies
-   that the cname and crealm fields in the cleartext portion of the
-   reply match what it requested. If any padata fields are present, they
-   may be used to derive the proper secret key to decrypt the message.
-   The client decrypts the encrypted part of the response using its
-
-
-
-June 2004                                                      [Page 27]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   secret key, verifies that the nonce in the encrypted part matches the
-   nonce it supplied in its request (to detect replays). It also
-   verifies that the sname and srealm in the response match those in the
-   request (or are otherwise expected values), and that the host address
-   field is also correct. It then stores the ticket, session key, start
-   and expiration times, and other information for later use. The last-
-   req field (and the deprecated key-expiration field) from the
-   encrypted part of the response MAY be checked to notify the user of
-   impending key expiration. This enables the client program to suggest
-   remedial action, such as a password change.
-
-   Upon validation of the KRB_AS_REP message (by checking the returned
-   nonce against that sent in the KRB_AS_REQ message) the client knows
-   that the current time on the KDC is that read from the authtime field
-   of the encrypted part of the reply. The client can optionally use
-   this value for clock synchronization in subsequent messages by
-   recording with the ticket the difference (offset) between the
-   authtime value and the local clock. This offset can then be used by
-   the same user to adjust the time read from the system clock when
-   generating messages [DGT96].
-
-   This technique MUST be used when adjusting for clock skew instead of
-   directly changing the system clock because the KDC reply is only
-   authenticated to the user whose secret key was used, but not to the
-   system or workstation. If the clock were adjusted, an attacker
-   colluding with a user logging into a workstation could agree on a
-   password, resulting in a KDC reply that would be correctly validated
-   even though it did not originate from a KDC trusted by the
-   workstation.
-
-   Proper decryption of the KRB_AS_REP message is not sufficient for the
-   host to verify the identity of the user; the user and an attacker
-   could cooperate to generate a KRB_AS_REP format message which
-   decrypts properly but is not from the proper KDC. If the host wishes
-   to verify the identity of the user, it MUST require the user to
-   present application credentials which can be verified using a
-   securely-stored secret key for the host. If those credentials can be
-   verified, then the identity of the user can be assured.
-
-3.1.6. Receipt of KRB_ERROR message
-
-   If the reply message type is KRB_ERROR, then the client interprets it
-   as an error and performs whatever application-specific tasks are
-   necessary to recover.
-
-3.2. The Client/Server Authentication Exchange
-
-                                Summary
-
-
-
-June 2004                                                      [Page 28]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   Message direction                         Message type    Section
-   Client to Application server              KRB_AP_REQ      5.5.1
-   [optional] Application server to client   KRB_AP_REP or   5.5.2
-                                             KRB_ERROR       5.9.1
-
-   The client/server authentication (CS) exchange is used by network
-   applications to authenticate the client to the server and vice versa.
-   The client MUST have already acquired credentials for the server
-   using the AS or TGS exchange.
-
-3.2.1. The KRB_AP_REQ message
-
-   The KRB_AP_REQ contains authentication information which SHOULD be
-   part of the first message in an authenticated transaction. It
-   contains a ticket, an authenticator, and some additional bookkeeping
-   information (see section 5.5.1 for the exact format). The ticket by
-   itself is insufficient to authenticate a client, since tickets are
-   passed across the network in cleartext (tickets contain both an
-   encrypted and unencrypted portion, so cleartext here refers to the
-   entire unit, which can be copied from one message and replayed in
-   another without any cryptographic skill), so the authenticator is
-   used to prevent invalid replay of tickets by proving to the server
-   that the client knows the session key of the ticket and thus is
-   entitled to use the ticket. The KRB_AP_REQ message is referred to
-   elsewhere as the 'authentication header.'
-
-3.2.2. Generation of a KRB_AP_REQ message
-
-   When a client wishes to initiate authentication to a server, it
-   obtains (either through a credentials cache, the AS exchange, or the
-   TGS exchange) a ticket and session key for the desired service. The
-   client MAY re-use any tickets it holds until they expire. To use a
-   ticket the client constructs a new Authenticator from the system
-   time, its name, and optionally an application specific checksum, an
-   initial sequence number to be used in KRB_SAFE or KRB_PRIV messages,
-   and/or a session subkey to be used in negotiations for a session key
-   unique to this particular session.  Authenticators MUST NOT be re-
-   used and SHOULD be rejected if replayed to a server.  Note that this
-   can make applications based on unreliable transports difficult to
-   code correctly. If the transport might deliver duplicated messages,
-   either a new authenticator must be generated for each retry, or the
-   application server must match requests and replies and replay the
-   first reply in response to a detected duplicate.
-
-   If a sequence number is to be included, it SHOULD be randomly chosen
-   so that even after many messages have been exchanged it is not likely
-   to collide with other sequence numbers in use.
-
-
-
-
-June 2004                                                      [Page 29]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   The client MAY indicate a requirement of mutual authentication or the
-   use of a session-key based ticket (for user-to-user authentication -
-   see section 3.7) by setting the appropriate flag(s) in the ap-options
-   field of the message.
-
-   The Authenticator is encrypted in the session key and combined with
-   the ticket to form the KRB_AP_REQ message which is then sent to the
-   end server along with any additional application-specific
-   information.
-
-3.2.3. Receipt of KRB_AP_REQ message
-
-   Authentication is based on the server's current time of day (clocks
-   MUST be loosely synchronized), the authenticator, and the ticket.
-   Several errors are possible. If an error occurs, the server is
-   expected to reply to the client with a KRB_ERROR message. This
-   message MAY be encapsulated in the application protocol if its raw
-   form is not acceptable to the protocol.  The format of error messages
-   is described in section 5.9.1.
-
-   The algorithm for verifying authentication information is as follows.
-   If the message type is not KRB_AP_REQ, the server returns the
-   KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket
-   in the KRB_AP_REQ is not one the server can use (e.g., it indicates
-   an old key, and the server no longer possesses a copy of the old
-   key), the KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION-
-   KEY flag is set in the ap-options field, it indicates to the server
-   that user-to-user authentication is in use, and that the ticket is
-   encrypted in the session key from the server's ticket-granting ticket
-   rather than in the server's secret key. See section 3.7 for a more
-   complete description of the effect of user-to-user authentication on
-   all messages in the Kerberos protocol.
-
-   Since it is possible for the server to be registered in multiple
-   realms, with different keys in each, the srealm field in the
-   unencrypted portion of the ticket in the KRB_AP_REQ is used to
-   specify which secret key the server should use to decrypt that
-   ticket. The KRB_AP_ERR_NOKEY error code is returned if the server
-   doesn't have the proper key to decipher the ticket.
-
-   The ticket is decrypted using the version of the server's key
-   specified by the ticket. If the decryption routines detect a
-   modification of the ticket (each encryption system MUST provide
-   safeguards to detect modified ciphertext), the
-   KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that
-   different keys were used to encrypt and decrypt).
-
-   The authenticator is decrypted using the session key extracted from
-
-
-
-June 2004                                                      [Page 30]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   the decrypted ticket. If decryption shows it to have been modified,
-   the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of
-   the client from the ticket are compared against the same fields in
-   the authenticator.  If they don't match, the KRB_AP_ERR_BADMATCH
-   error is returned; this normally is caused by a client error or
-   attempted attack. The addresses in the ticket (if any) are then
-   searched for an address matching the operating-system reported
-   address of the client. If no match is found or the server insists on
-   ticket addresses but none are present in the ticket, the
-   KRB_AP_ERR_BADADDR error is returned. If the local (server) time and
-   the client time in the authenticator differ by more than the
-   allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is
-   returned.
-
-   Unless the application server provides its own suitable means to
-   protect against replay (for example, a challenge-response sequence
-   initiated by the server after authentication, or use of a server-
-   generated encryption subkey), the server MUST utilize a replay cache
-   to remember any authenticator presented within the allowable clock
-   skew. Careful analysis of the application protocol and implementation
-   is recommended before eliminating this cache. The replay cache will
-   store at least the server name, along with the client name, time and
-   microsecond fields from the recently-seen authenticators and if a
-   matching tuple is found, the KRB_AP_ERR_REPEAT error is returned.
-   Note that the rejection here is restricted to authenticators from the
-   same principal to the same server. Other client principals
-   communicating with the same server principal should not have their
-   authenticators rejected if the time and microsecond fields happen to
-   match some other client's authenticator.
-
-   If a server loses track of authenticators presented within the
-   allowable clock skew, it MUST reject all requests until the clock
-   skew interval has passed, providing assurance that any lost or
-   replayed authenticators will fall outside the allowable clock skew
-   and can no longer be successfully replayed.  If this were not done,
-   an attacker could subvert the authentication by recording the ticket
-   and authenticator sent over the network to a server and replaying
-   them following an event that caused the server to lose track of
-   recently seen authenticators.
-
-   Implementation note: If a client generates multiple requests to the
-   KDC with the same timestamp, including the microsecond field, all but
-   the first of the requests received will be rejected as replays. This
-   might happen, for example, if the resolution of the client's clock is
-   too coarse.  Client implementations SHOULD ensure that the timestamps
-   are not reused, possibly by incrementing the microseconds field in
-   the time stamp when the clock returns the same time for multiple
-   requests.
-
-
-
-June 2004                                                      [Page 31]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   If multiple servers (for example, different services on one machine,
-   or a single service implemented on multiple machines) share a service
-   principal (a practice we do not recommend in general, but acknowledge
-   will be used in some cases), they MUST either share this replay
-   cache, or the application protocol MUST be designed so as to
-   eliminate the need for it. Note that this applies to all of the
-   services, if any of the application protocols does not have replay
-   protection built in; an authenticator used with such a service could
-   later be replayed to a different service with the same service
-   principal but no replay protection, if the former doesn't record the
-   authenticator information in the common replay cache.
-
-   If a sequence number is provided in the authenticator, the server
-   saves it for later use in processing KRB_SAFE and/or KRB_PRIV
-   messages. If a subkey is present, the server either saves it for
-   later use or uses it to help generate its own choice for a subkey to
-   be returned in a KRB_AP_REP message.
-
-   The server computes the age of the ticket: local (server) time minus
-   the start time inside the Ticket. If the start time is later than the
-   current time by more than the allowable clock skew or if the INVALID
-   flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned.
-   Otherwise, if the current time is later than end time by more than
-   the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is
-   returned.
-
-   If all these checks succeed without an error, the server is assured
-   that the client possesses the credentials of the principal named in
-   the ticket and thus, the client has been authenticated to the server.
-
-   Passing these checks provides only authentication of the named
-   principal; it does not imply authorization to use the named service.
-   Applications MUST make a separate authorization decision based upon
-   the authenticated name of the user, the requested operation, local
-   access control information such as that contained in a .k5login or
-   .k5users file, and possibly a separate distributed authorization
-   service.
-
-3.2.4. Generation of a KRB_AP_REP message
-
-   Typically, a client's request will include both the authentication
-   information and its initial request in the same message, and the
-   server need not explicitly reply to the KRB_AP_REQ. However, if
-   mutual authentication (not only authenticating the client to the
-   server, but also the server to the client) is being performed, the
-   KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options
-   field, and a KRB_AP_REP message is required in response. As with the
-   error message, this message MAY be encapsulated in the application
-
-
-
-June 2004                                                      [Page 32]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   protocol if its "raw" form is not acceptable to the application's
-   protocol. The timestamp and microsecond field used in the reply MUST
-   be the client's timestamp and microsecond field (as provided in the
-   authenticator). If a sequence number is to be included, it SHOULD be
-   randomly chosen as described above for the authenticator. A subkey
-   MAY be included if the server desires to negotiate a different
-   subkey. The KRB_AP_REP message is encrypted in the session key
-   extracted from the ticket.
-
-   Note that in the Kerberos version 4 protocol, the timestamp in the
-   reply was the client's timestamp plus one. This is not necessary in
-   version 5 because version 5 messages are formatted in such a way that
-   it is not possible to create the reply by judicious message surgery
-   (even in encrypted form) without knowledge of the appropriate
-   encryption keys.
-
-3.2.5. Receipt of KRB_AP_REP message
-
-   If a KRB_AP_REP message is returned, the client uses the session key
-   from the credentials obtained for the server to decrypt the message
-   (Note that for encrypting the KRB_AP_REP message, the sub-session key
-   is not used, even if present in the Authenticator), and verifies that
-   the timestamp and microsecond fields match those in the Authenticator
-   it sent to the server. If they match, then the client is assured that
-   the server is genuine. The sequence number and subkey (if present)
-   are retained for later use.
-
-3.2.6. Using the encryption key
-
-   After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
-   server share an encryption key which can be used by the application.
-   In some cases, the use of this session key will be implicit in the
-   protocol; in others the method of use must be chosen from several
-   alternatives. The actual encryption key to be used for KRB_PRIV,
-   KRB_SAFE, or other application-specific uses MAY be chosen by the
-   application based on the session key from the ticket and subkeys in
-   the KRB_AP_REP message and the authenticator.  Implementations of the
-   protocol MAY provide routines to choose subkeys based on session keys
-   and random numbers and to generate a negotiated key to be returned in
-   the KRB_AP_REP message.
-
-   To mitigate the effect of failures in random number generation on the
-   client it is strongly encouraged that any key derived by an
-   application for subsequent use include the full key entropy derived
-   from the KDC generated session key carried in the ticket. We leave
-   the protocol negotiations of how to use the key (e.g. selecting an
-   encryption or checksum type) to the application programmer; the
-   Kerberos protocol does not constrain the implementation options, but
-
-
-
-June 2004                                                      [Page 33]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   an example of how this might be done follows.
-
-   One way that an application may choose to negotiate a key to be used
-   for subsequent integrity and privacy protection is for the client to
-   propose a key in the subkey field of the authenticator. The server
-   can then choose a key using the proposed key from the client as
-   input, returning the new subkey in the subkey field of the
-   application reply. This key could then be used for subsequent
-   communication.
-
-   With both the one-way and mutual authentication exchanges, the peers
-   should take care not to send sensitive information to each other
-   without proper assurances. In particular, applications that require
-   privacy or integrity SHOULD use the KRB_AP_REP response from the
-   server to client to assure both client and server of their peer's
-   identity. If an application protocol requires privacy of its
-   messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE
-   message (section 3.4) can be used to assure integrity.
-
-3.3. The Ticket-Granting Service (TGS) Exchange
-
-                             Summary
-         Message direction       Message type     Section
-         1. Client to Kerberos   KRB_TGS_REQ      5.4.1
-         2. Kerberos to client   KRB_TGS_REP or   5.4.2
-                                 KRB_ERROR        5.9.1
-
-   The TGS exchange between a client and the Kerberos Ticket-Granting
-   Server is initiated by a client when it wishes to obtain
-   authentication credentials for a given server (which might be
-   registered in a remote realm), when it wishes to renew or validate an
-   existing ticket, or when it wishes to obtain a proxy ticket. In the
-   first case, the client must already have acquired a ticket for the
-   Ticket-Granting Service using the AS exchange (the ticket-granting
-   ticket is usually obtained when a client initially authenticates to
-   the system, such as when a user logs in). The message format for the
-   TGS exchange is almost identical to that for the AS exchange.  The
-   primary difference is that encryption and decryption in the TGS
-   exchange does not take place under the client's key. Instead, the
-   session key from the ticket-granting ticket or renewable ticket, or
-   sub-session key from an Authenticator is used. As is the case for all
-   application servers, expired tickets are not accepted by the TGS, so
-   once a renewable or ticket-granting ticket expires, the client must
-   use a separate exchange to obtain valid tickets.
-
-   The TGS exchange consists of two messages: A request (KRB_TGS_REQ)
-   from the client to the Kerberos Ticket-Granting Server, and a reply
-   (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes
-
-
-
-June 2004                                                      [Page 34]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   information authenticating the client plus a request for credentials.
-   The authentication information consists of the authentication header
-   (KRB_AP_REQ) which includes the client's previously obtained ticket-
-   granting, renewable, or invalid ticket.  In the ticket-granting
-   ticket and proxy cases, the request MAY include one or more of: a
-   list of network addresses, a collection of typed authorization data
-   to be sealed in the ticket for authorization use by the application
-   server, or additional tickets (the use of which are described later).
-   The TGS reply (KRB_TGS_REP) contains the requested credentials,
-   encrypted in the session key from the ticket-granting ticket or
-   renewable ticket, or if present, in the sub-session key from the
-   Authenticator (part of the authentication header). The KRB_ERROR
-   message contains an error code and text explaining what went wrong.
-   The KRB_ERROR message is not encrypted. The KRB_TGS_REP message
-   contains information which can be used to detect replays, and to
-   associate it with the message to which it replies. The KRB_ERROR
-   message also contains information which can be used to associate it
-   with the message to which it replies. The same comments about
-   integrity protection of KRB_ERROR messages mentioned in section 3.1
-   apply to the TGS exchange.
-
-3.3.1. Generation of KRB_TGS_REQ message
-
-   Before sending a request to the ticket-granting service, the client
-   MUST determine in which realm the application server is believed to
-   be registered. This can be accomplished in several ways. It might be
-   known beforehand (since the realm is part of the principal
-   identifier), it might be stored in a nameserver, or it might be
-   obtained from a configuration file. If the realm to be used is
-   obtained from a nameserver, there is a danger of being spoofed if the
-   nameservice providing the realm name is not authenticated.  This
-   might result in the use of a realm which has been compromised, and
-   would result in an attacker's ability to compromise the
-   authentication of the application server to the client.
-
-   If the client knows the service principal name and realm and it does
-   not already possess a ticket-granting ticket for the appropriate
-   realm, then one must be obtained. This is first attempted by
-   requesting a ticket-granting ticket for the destination realm from a
-   Kerberos server for which the client possesses a ticket-granting
-   ticket (using the KRB_TGS_REQ message recursively). The Kerberos
-   server MAY return a TGT for the desired realm in which case one can
-   proceed. Alternatively, the Kerberos server MAY return a TGT for a
-   realm which is 'closer' to the desired realm (further along the
-   standard hierarchical path between the client's realm and the
-   requested realm server's realm). It should be noted in this case that
-   misconfiguration of the Kerberos servers may cause loops in the
-   resulting authentication path, which the client should be careful to
-
-
-
-June 2004                                                      [Page 35]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   detect and avoid.
-
-   If the Kerberos server returns a TGT for a 'closer' realm other than
-   the desired realm, the client MAY use local policy configuration to
-   verify that the authentication path used is an acceptable one.
-   Alternatively, a client MAY choose its own authentication path,
-   rather than relying on the Kerberos server to select one. In either
-   case, any policy or configuration information used to choose or
-   validate authentication paths, whether by the Kerberos server or
-   client, MUST be obtained from a trusted source.
-
-   When a client obtains a ticket-granting ticket that is 'closer' to
-   the destination realm, the client MAY cache this ticket and reuse it
-   in future KRB-TGS exchanges with services in the 'closer' realm.
-   However, if the client were to obtain a ticket-granting ticket for
-   the 'closer' realm by starting at the initial KDC rather than as part
-   of obtaining another ticket, then a shorter path to the 'closer'
-   realm might be used. This shorter path may be desirable because fewer
-   intermediate KDCs would know the session key of the ticket involved.
-   For this reason, clients SHOULD evaluate whether they trust the
-   realms transited in obtaining the 'closer' ticket when making a
-   decision to use the ticket in future.
-
-   Once the client obtains a ticket-granting ticket for the appropriate
-   realm, it determines which Kerberos servers serve that realm, and
-   contacts one. The list might be obtained through a configuration file
-   or network service or it MAY be generated from the name of the realm;
-   as long as the secret keys exchanged by realms are kept secret, only
-   denial of service results from using a false Kerberos server.
-
-    As in the AS exchange, the client MAY specify a number of options in
-   the KRB_TGS_REQ message. One of these options is the ENC-TKT-IN-SKEY
-   option used for user-to-user authentication. An overview of user-to-
-   user authentication can be found in section 3.7. When generating the
-   KRB_TGS_REQ message, this option indicates that the client is
-   including a ticket-granting ticket obtained from the application
-   server in the additional tickets field of the request and that the
-   KDC SHOULD encrypt the ticket for the application server using the
-   session key from this additional ticket, instead of using a server
-   key from the principal database.
-
-   The client prepares the KRB_TGS_REQ message, providing an
-   authentication header as an element of the padata field, and
-   including the same fields as used in the KRB_AS_REQ message along
-   with several optional fields: the enc-authorizatfion-data field for
-   application server use and additional tickets required by some
-   options.
-
-
-
-
-June 2004                                                      [Page 36]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   In preparing the authentication header, the client can select a sub-
-   session key under which the response from the Kerberos server will be
-   encrypted. If the client selects a sub-session key, care must be
-   taken to ensure the randomness of the selected sub-session key. One
-   approach would be to generate a random number and XOR it with the
-   session key from the ticket-granting ticket.
-
-   If the sub-session key is not specified, the session key from the
-   ticket-granting ticket will be used. If the enc-authorization-data is
-   present, it MUST be encrypted in the sub-session key, if present,
-   from the authenticator portion of the authentication header, or if
-   not present, using the session key from the ticket-granting ticket.
-
-   Once prepared, the message is sent to a Kerberos server for the
-   destination realm.
-
-3.3.2. Receipt of KRB_TGS_REQ message
-
-   The KRB_TGS_REQ message is processed in a manner similar to the
-   KRB_AS_REQ message, but there are many additional checks to be
-   performed. First, the Kerberos server MUST determine which server the
-   accompanying ticket is for and it MUST select the appropriate key to
-   decrypt it. For a normal KRB_TGS_REQ message, it will be for the
-   ticket granting service, and the TGS's key will be used. If the TGT
-   was issued by another realm, then the appropriate inter-realm key
-   MUST be used. If the accompanying ticket is not a ticket-granting
-   ticket for the current realm, but is for an application server in the
-   current realm, the RENEW, VALIDATE, or PROXY options are specified in
-   the request, and the server for which a ticket is requested is the
-   server named in the accompanying ticket, then the KDC will decrypt
-   the ticket in the authentication header using the key of the server
-   for which it was issued. If no ticket can be found in the padata
-   field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
-
-   Once the accompanying ticket has been decrypted, the user-supplied
-   checksum in the Authenticator MUST be verified against the contents
-   of the request, and the message rejected if the checksums do not
-   match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum
-   is not collision-proof (with an error code of
-   KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the
-   KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data
-   are present, they are decrypted using the sub-session key from the
-   Authenticator.
-
-   If any of the decryptions indicate failed integrity checks, the
-   KRB_AP_ERR_BAD_INTEGRITY error is returned.
-
-   As discussed in section 3.1.2, the KDC MUST send a valid KRB_TGS_REP
-
-
-
-June 2004                                                      [Page 37]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   message if it receives a KRB_TGS_REQ message identical to one it has
-   recently processed. However, if the authenticator is a replay, but
-   the rest of the request is not identical, then the KDC SHOULD return
-   KRB_AP_ERR_REPEAT.
-
-3.3.3. Generation of KRB_TGS_REP message
-
-   The KRB_TGS_REP message shares its format with the KRB_AS_REP
-   (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The
-   detailed specification is in section 5.4.2.
-
-   The response will include a ticket for the requested server or for a
-   ticket granting server of an intermediate KDC to be contacted to
-   obtain the requested ticket. The Kerberos database is queried to
-   retrieve the record for the appropriate server (including the key
-   with which the ticket will be encrypted). If the request is for a
-   ticket-granting ticket for a remote realm, and if no key is shared
-   with the requested realm, then the Kerberos server will select the
-   realm 'closest' to the requested realm with which it does share a
-   key, and use that realm instead.  This is the only case where the
-   response for the KDC will be for a different server than that
-   requested by the client.
-
-   By default, the address field, the client's name and realm, the list
-   of transited realms, the time of initial authentication, the
-   expiration time, and the authorization data of the newly-issued
-   ticket will be copied from the ticket-granting ticket (TGT) or
-   renewable ticket. If the transited field needs to be updated, but the
-   transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error is
-   returned.
-
-   If the request specifies an endtime, then the endtime of the new
-   ticket is set to the minimum of (a) that request, (b) the endtime
-   from the TGT, and (c) the starttime of the TGT plus the minimum of
-   the maximum life for the application server and the maximum life for
-   the local realm (the maximum life for the requesting principal was
-   already applied when the TGT was issued). If the new ticket is to be
-   a renewal, then the endtime above is replaced by the minimum of (a)
-   the value of the renew_till field of the ticket and (b) the starttime
-   for the new ticket plus the life (endtime-starttime) of the old
-   ticket.
-
-   If the FORWARDED option has been requested, then the resulting ticket
-   will contain the addresses specified by the client. This option will
-   only be honored if the FORWARDABLE flag is set in the TGT. The PROXY
-   option is similar; the resulting ticket will contain the addresses
-   specified by the client. It will be honored only if the PROXIABLE
-   flag in the TGT is set. The PROXY option will not be honored on
-
-
-
-June 2004                                                      [Page 38]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   requests for additional ticket-granting tickets.
-
-   If the requested start time is absent, indicates a time in the past,
-   or is within the window of acceptable clock skew for the KDC and the
-   POSTDATE option has not been specified, then the start time of the
-   ticket is set to the authentication server's current time. If it
-   indicates a time in the future beyond the acceptable clock skew, but
-   the POSTDATED option has not been specified or the MAY-POSTDATE flag
-   is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is
-   returned. Otherwise, if the ticket-granting ticket has the MAY-
-   POSTDATE flag set, then the resulting ticket will be postdated and
-   the requested starttime is checked against the policy of the local
-   realm. If acceptable, the ticket's start time is set as requested,
-   and the INVALID flag is set. The postdated ticket MUST be validated
-   before use by presenting it to the KDC after the starttime has been
-   reached. However, in no case may the starttime, endtime, or renew-
-   till time of a newly-issued postdated ticket extend beyond the renew-
-   till time of the ticket-granting ticket.
-
-   If the ENC-TKT-IN-SKEY option has been specified and an additional
-   ticket has been included in the request, it indicates that the client
-   is using user- to-user authentication to prove its identity to a
-   server that does not have access to a persistent key. Section 3.7
-   describes the affect of this option on the entire Kerberos protocol.
-   When generating the KRB_TGS_REP message, this option in the
-   KRB_TGS_REQ message tells the KDC to decrypt the additional ticket
-   using the key for the server to which the additional ticket was
-   issued and verify that it is a ticket-granting ticket. If the name of
-   the requested server is missing from the request, the name of the
-   client in the additional ticket will be used. Otherwise the name of
-   the requested server will be compared to the name of the client in
-   the additional ticket and if different, the request will be rejected.
-   If the request succeeds, the session key from the additional ticket
-   will be used to encrypt the new ticket that is issued instead of
-   using the key of the server for which the new ticket will be used.
-
-   If the name of the server in the ticket that is presented to the KDC
-   as part of the authentication header is not that of the ticket-
-   granting server itself, the server is registered in the realm of the
-   KDC, and the RENEW option is requested, then the KDC will verify that
-   the RENEWABLE flag is set in the ticket, that the INVALID flag is not
-   set in the ticket, and that the renew_till time is still in the
-   future. If the VALIDATE option is requested, the KDC will check that
-   the starttime has passed and the INVALID flag is set. If the PROXY
-   option is requested, then the KDC will check that the PROXIABLE flag
-   is set in the ticket. If the tests succeed, and the ticket passes the
-   hotlist check described in the next section, the KDC will issue the
-   appropriate new ticket.
-
-
-
-June 2004                                                      [Page 39]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   The ciphertext part of the response in the KRB_TGS_REP message is
-   encrypted in the sub-session key from the Authenticator, if present,
-   or the session key from the ticket-granting ticket. It is not
-   encrypted using the client's secret key. Furthermore, the client's
-   key's expiration date and the key version number fields are left out
-   since these values are stored along with the client's database
-   record, and that record is not needed to satisfy a request based on a
-   ticket-granting ticket.
-
-3.3.3.1. Checking for revoked tickets
-
-   Whenever a request is made to the ticket-granting server, the
-   presented ticket(s) is(are) checked against a hot-list of tickets
-   which have been canceled. This hot-list might be implemented by
-   storing a range of issue timestamps for 'suspect tickets'; if a
-   presented ticket had an authtime in that range, it would be rejected.
-   In this way, a stolen ticket-granting ticket or renewable ticket
-   cannot be used to gain additional tickets (renewals or otherwise)
-   once the theft has been reported to the KDC for the realm in which
-   the server resides. Any normal ticket obtained before it was reported
-   stolen will still be valid (because they require no interaction with
-   the KDC), but only until their normal expiration time. If TGT's have
-   been issued for cross-realm authentication, use of the cross-realm
-   TGT will not be affected unless the hot-list is propagated to the
-   KDCs for the realms for which such cross-realm tickets were issued.
-
-3.3.3.2. Encoding the transited field
-
-   If the identity of the server in the TGT that is presented to the KDC
-   as part of the authentication header is that of the ticket-granting
-   service, but the TGT was issued from another realm, the KDC will look
-   up the inter-realm key shared with that realm and use that key to
-   decrypt the ticket. If the ticket is valid, then the KDC will honor
-   the request, subject to the constraints outlined above in the section
-   describing the AS exchange.  The realm part of the client's identity
-   will be taken from the ticket-granting ticket. The name of the realm
-   that issued the ticket-granting ticket, if it is not the realm of the
-   client principal, will be added to the transited field of the ticket
-   to be issued. This is accomplished by reading the transited field
-   from the ticket-granting ticket (which is treated as an unordered set
-   of realm names), adding the new realm to the set, then constructing
-   and writing out its encoded (shorthand) form (this may involve a
-   rearrangement of the existing encoding).
-
-   Note that the ticket-granting service does not add the name of its
-   own realm. Instead, its responsibility is to add the name of the
-   previous realm.  This prevents a malicious Kerberos server from
-   intentionally leaving out its own name (it could, however, omit other
-
-
-
-June 2004                                                      [Page 40]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   realms' names).
-
-   The names of neither the local realm nor the principal's realm are to
-   be included in the transited field. They appear elsewhere in the
-   ticket and both are known to have taken part in authenticating the
-   principal. Since the endpoints are not included, both local and
-   single-hop inter-realm authentication result in a transited field
-   that is empty.
-
-   Because the name of each realm transited is added to this field, it
-   might potentially be very long. To decrease the length of this field,
-   its contents are encoded. The initially supported encoding is
-   optimized for the normal case of inter-realm communication: a
-   hierarchical arrangement of realms using either domain or X.500 style
-   realm names. This encoding (called DOMAIN-X500-COMPRESS) is now
-   described.
-
-   Realm names in the transited field are separated by a ",". The ",",
-   "\", trailing "."s, and leading spaces (" ") are special characters,
-   and if they are part of a realm name, they MUST be quoted in the
-   transited field by preceding them with a "\".
-
-   A realm name ending with a "." is interpreted as being prepended to
-   the previous realm. For example, we can encode traversal of EDU,
-   MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
-
-      "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
-
-   Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were end-points,
-   that they would not be included in this field, and we would have:
-
-      "EDU,MIT.,WASHINGTON.EDU"
-
-   A realm name beginning with a "/" is interpreted as being appended to
-   the previous realm.  For the purpose of appending, the realm
-   preceding the first listed realm is considered to be the null realm
-   ("").  If a realm name beginning with a "/" is to stand by itself,
-   then it SHOULD be preceded by a space (" "). For example, we can
-   encode traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as:
-
-      "/COM,/HP,/APOLLO, /COM/DEC".
-
-   Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints,
-   they would not be included in this field, and we would have:
-
-      "/COM,/HP"
-
-   A null subfield preceding or following a "," indicates that all
-
-
-
-June 2004                                                      [Page 41]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   realms between the previous realm and the next realm have been
-   traversed.  For the purpose of interpreting null subfields, the
-   client's realm is considered to precede those in the transited field,
-   and the server's realm is considered to follow them.  Thus, "," means
-   that all realms along the path between the client and the server have
-   been traversed. ",EDU, /COM," means that all realms from the client's
-   realm up to EDU (in a domain style hierarchy) have been traversed,
-   and that everything from /COM down to the server's realm in an X.500
-   style has also been traversed. This could occur if the EDU realm in
-   one hierarchy shares an inter-realm key directly with the /COM realm
-   in another hierarchy.
-
-3.3.4. Receipt of KRB_TGS_REP message
-
-   When the KRB_TGS_REP is received by the client, it is processed in
-   the same manner as the KRB_AS_REP processing described above. The
-   primary difference is that the ciphertext part of the response must
-   be decrypted using the sub-session key from the Authenticator, if it
-   was specified in the request, or the session key from the ticket-
-   granting ticket, rather than the client's secret key. The server name
-   returned in the reply is the true principal name of the service.
-
-3.4. The KRB_SAFE Exchange
-
-   The KRB_SAFE message MAY be used by clients requiring the ability to
-   detect modifications of messages they exchange. It achieves this by
-   including a keyed collision-proof checksum of the user data and some
-   control information. The checksum is keyed with an encryption key
-   (usually the last key negotiated via subkeys, or the session key if
-   no negotiation has occurred).
-
-3.4.1. Generation of a KRB_SAFE message
-
-   When an application wishes to send a KRB_SAFE message, it collects
-   its data and the appropriate control information and computes a
-   checksum over them.  The checksum algorithm should be the keyed
-   checksum mandated to be implemented along with the crypto system used
-   for the sub-session or session key. The checksum is generated using
-   the sub-session key if present or the session key. Some
-   implementations use a different checksum algorithm for the KRB_SAFE
-   messages but doing so in a interoperable manner is not always
-   possible.
-
-   The control information for the KRB_SAFE message includes both a
-   timestamp and a sequence number. The designer of an application using
-   the KRB_SAFE message MUST choose at least one of the two mechanisms.
-   This choice SHOULD be based on the needs of the application protocol.
-
-
-
-
-June 2004                                                      [Page 42]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   Sequence numbers are useful when all messages sent will be received
-   by one's peer. Connection state is presently required to maintain the
-   session key, so maintaining the next sequence number should not
-   present an additional problem.
-
-   If the application protocol is expected to tolerate lost messages
-   without them being resent, the use of the timestamp is the
-   appropriate replay detection mechanism. Using timestamps is also the
-   appropriate mechanism for multi-cast protocols where all of one's
-   peers share a common sub-session key, but some messages will be sent
-   to a subset of one's peers.
-
-   After computing the checksum, the client then transmits the
-   information and checksum to the recipient in the message format
-   specified in section 5.6.1.
-
-3.4.2. Receipt of KRB_SAFE message
-
-   When an application receives a KRB_SAFE message, it verifies it as
-   follows.  If any error occurs, an error code is reported for use by
-   the application.
-
-   The message is first checked by verifying that the protocol version
-   and type fields match the current version and KRB_SAFE, respectively.
-   A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
-   error. The application verifies that the checksum used is a
-   collision-proof keyed checksum that uses keys compatible with the
-   sub-session or session key as appropriate (or with the application
-   key derived from the session or sub-session keys), and if it is not,
-   a KRB_AP_ERR_INAPP_CKSUM error is generated.  The sender's address
-   MUST be included in the control information; the recipient verifies
-   that the operating system's report of the sender's address matches
-   the sender's address in the message, and (if a recipient address is
-   specified or the recipient requires an address) that one of the
-   recipient's addresses appears as the recipient's address in the
-   message. To work with network address translation, senders MAY use
-   the directional address type specified in section 8.1 for the sender
-   address and not include recipient addresses. A failed match for
-   either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp
-   and usec and/or the sequence number fields are checked. If timestamp
-   and usec are expected and not present, or they are present but not
-   current, the KRB_AP_ERR_SKEW error is generated. Timestamps are not
-   required to be strictly ordered; they are only required to be in the
-   skew window.  If the server name, along with the client name, time
-   and microsecond fields from the Authenticator match any recently-seen
-   (sent or received) such tuples, the KRB_AP_ERR_REPEAT error is
-   generated. If an incorrect sequence number is included, or a sequence
-   number is expected but not present, the KRB_AP_ERR_BADORDER error is
-
-
-
-June 2004                                                      [Page 43]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   generated. If neither a time-stamp and usec or a sequence number is
-   present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the
-   checksum is computed over the data and control information, and if it
-   doesn't match the received checksum, a KRB_AP_ERR_MODIFIED error is
-   generated.
-
-   If all the checks succeed, the application is assured that the
-   message was generated by its peer and was not modified in transit.
-
-   Implementations SHOULD accept any checksum algorithm they implement
-   that both have adequate security and that have keys compatible with
-   the sub-session or session key. Unkeyed or non-collision-proof
-   checksums are not suitable for this use.
-
-3.5. The KRB_PRIV Exchange
-
-   The KRB_PRIV message MAY be used by clients requiring confidentiality
-   and the ability to detect modifications of exchanged messages. It
-   achieves this by encrypting the messages and adding control
-   information.
-
-3.5.1. Generation of a KRB_PRIV message
-
-   When an application wishes to send a KRB_PRIV message, it collects
-   its data and the appropriate control information (specified in
-   section 5.7.1) and encrypts them under an encryption key (usually the
-   last key negotiated via subkeys, or the session key if no negotiation
-   has occurred). As part of the control information, the client MUST
-   choose to use either a timestamp or a sequence number (or both); see
-   the discussion in section 3.4.1 for guidelines on which to use. After
-   the user data and control information are encrypted, the client
-   transmits the ciphertext and some 'envelope' information to the
-   recipient.
-
-3.5.2. Receipt of KRB_PRIV message
-
-   When an application receives a KRB_PRIV message, it verifies it as
-   follows.  If any error occurs, an error code is reported for use by
-   the application.
-
-   The message is first checked by verifying that the protocol version
-   and type fields match the current version and KRB_PRIV, respectively.
-   A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
-   error. The application then decrypts the ciphertext and processes the
-   resultant plaintext. If decryption shows the data to have been
-   modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated.
-
-   The sender's address MUST be included in the control information; the
-
-
-
-June 2004                                                      [Page 44]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   recipient verifies that the operating system's report of the sender's
-   address matches the sender's address in the message.  If a recipient
-   address is specified or the recipient requires an address then one of
-   the recipient's addresses MUST also appear as the recipient's address
-   in the message.  Where a sender's or receiver's address might not
-   otherwise match the address in a message because of network address
-   translation, an application MAY be written to use addresses of the
-   directional address type in place of the actual network address.
-
-   A failed match for either case generates a KRB_AP_ERR_BADADDR error.
-   To work with network address translation, implementations MAY use the
-   directional address type defined in section 7.1 for the sender
-   address and include no recipient address.
-
-   Then the timestamp and usec and/or the sequence number fields are
-   checked. If timestamp and usec are expected and not present, or they
-   are present but not current, the KRB_AP_ERR_SKEW error is generated.
-   If the server name, along with the client name, time and microsecond
-   fields from the Authenticator match any recently-seen such tuples,
-   the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence
-   number is included, or a sequence number is expected but not present,
-   the KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp
-   and usec or a sequence number is present, a KRB_AP_ERR_MODIFIED error
-   is generated.
-
-   If all the checks succeed, the application can assume the message was
-   generated by its peer, and was securely transmitted (without
-   intruders able to see the unencrypted contents).
-
-3.6. The KRB_CRED Exchange
-
-   The KRB_CRED message MAY be used by clients requiring the ability to
-   send Kerberos credentials from one host to another. It achieves this
-   by sending the tickets together with encrypted data containing the
-   session keys and other information associated with the tickets.
-
-3.6.1. Generation of a KRB_CRED message
-
-   When an application wishes to send a KRB_CRED message it first (using
-   the KRB_TGS exchange) obtains credentials to be sent to the remote
-   host. It then constructs a KRB_CRED message using the ticket or
-   tickets so obtained, placing the session key needed to use each
-   ticket in the key field of the corresponding KrbCredInfo sequence of
-   the encrypted part of the KRB_CRED message.
-
-   Other information associated with each ticket and obtained during the
-   KRB_TGS exchange is also placed in the corresponding KrbCredInfo
-   sequence in the encrypted part of the KRB_CRED message. The current
-
-
-
-June 2004                                                      [Page 45]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   time and, if specifically required by the application the nonce, s-
-   address, and r-address fields, are placed in the encrypted part of
-   the KRB_CRED message which is then encrypted under an encryption key
-   previously exchanged in the KRB_AP exchange (usually the last key
-   negotiated via subkeys, or the session key if no negotiation has
-   occurred).
-
-   Implementation note: When constructing a KRB_CRED message for
-   inclusion in a GSSAPI initial context token, the MIT implementation
-   of Kerberos will not encrypt the KRB_CRED message if the session key
-   is a DES or triple DES key.  For interoperability with MIT, the
-   Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI
-   token if it is using a DES session key. Starting at version 1.2.5,
-   MIT Kerberos can receive and decode either encrypted or unencrypted
-   KRB_CRED tokens in the GSSAPI exchange. The Heimdal implementation of
-   Kerberos can also accept either encrypted or unencrypted KRB_CRED
-   messages. Since the KRB_CRED message in a GSSAPI token is encrypted
-   in the authenticator, the MIT behavior does not present a security
-   problem, although it is a violation of the Kerberos specification.
-
-3.6.2. Receipt of KRB_CRED message
-
-   When an application receives a KRB_CRED message, it verifies it. If
-   any error occurs, an error code is reported for use by the
-   application. The message is verified by checking that the protocol
-   version and type fields match the current version and KRB_CRED,
-   respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or
-   KRB_AP_ERR_MSG_TYPE error. The application then decrypts the
-   ciphertext and processes the resultant plaintext. If decryption shows
-   the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
-   generated.
-
-   If present or required, the recipient MAY verify that the operating
-   system's report of the sender's address matches the sender's address
-   in the message, and that one of the recipient's addresses appears as
-   the recipient's address in the message. The address check does not
-   provide any added security, since the address if present has already
-   been checked in the KRB_AP_REQ message and there is not any benefit
-   to be gained by an attacker in reflecting a KRB_CRED message back to
-   its originator. Thus, the recipient MAY ignore the address even if
-   present in order to work better in NAT environments. A failed match
-   for either case generates a KRB_AP_ERR_BADADDR error. Recipients MAY
-   skip the address check as the KRB_CRED message cannot generally be
-   reflected back to the originator.  The timestamp and usec fields (and
-   the nonce field if required) are checked next. If the timestamp and
-   usec are not present, or they are present but not current, the
-   KRB_AP_ERR_SKEW error is generated.
-
-
-
-
-June 2004                                                      [Page 46]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   If all the checks succeed, the application stores each of the new
-   tickets in its credentials cache together with the session key and
-   other information in the corresponding KrbCredInfo sequence from the
-   encrypted part of the KRB_CRED message.
-
-3.7. User-to-User Authentication Exchanges
-
-   User-to-User authentication provides a method to perform
-   authentication when the verifier does not have a access to long term
-   service key. This might be the case when running a server (for
-   example a window server) as a user on a workstation. In such cases,
-   the server may have access to the ticket-granting ticket obtained
-   when the user logged in to the workstation, but because the server is
-   running as an unprivileged user it might not have access to system
-   keys. Similar situations may arise when running peer-to-peer
-   applications.
-
-                             Summary
-       Message direction                    Message type     Sections
-       0. Message from application server   Not Specified
-       1. Client to Kerberos                KRB_TGS_REQ      3.3 + 5.4.1
-       2. Kerberos to client                KRB_TGS_REP or   3.3 + 5.4.2
-                                            KRB_ERROR        5.9.1
-       3. Client to Application server      KRB_AP_REQ       3.2 + 5.5.1
-
-   To address this problem, the Kerberos protocol allows the client to
-   request that the ticket issued by the KDC be encrypted using a
-   session key from a ticket-granting ticket issued to the party that
-   will verify the authentication.  This ticket-granting ticket must be
-   obtained from the verifier by means of an exchange external to the
-   Kerberos protocol, usually as part of the application protocol. This
-   message is shown in the summary above as message 0. Note that because
-   the ticket-granting ticket is encrypted in the KDC's secret key, it
-   can not be used for authentication without possession of the
-   corresponding secret key.  Furthermore, because the verifier does not
-   reveal the corresponding secret key, providing a copy of the
-   verifier's ticket-granting ticket does not allow impersonation of the
-   verifier.
-
-   Message 0 in the table above represents an application specific
-   negotiation between the client and server, at the end of which both
-   have determined that they will use user-to-user authentication and
-   the client has obtained the server's TGT.
-
-   Next, the client includes the server's TGT as an additional ticket in
-   its KRB_TGS_REQ request to the KDC (message 1 in the table above) and
-   specifies the ENC-TKT-IN-SKEY option in its request.
-
-
-
-
-June 2004                                                      [Page 47]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   If validated according to the instructions in 3.3.3, the application
-   ticket returned to the client (message 2 in the table above) will be
-   encrypted using the session key from the additional ticket and the
-   client will note this when it uses or stores the application ticket.
-
-   When contacting the server using a ticket obtained for user-to-user
-   authentication (message 3 in the table above), the client MUST
-   specify the USE-SESSION-KEY flag in the ap-options field. This tells
-   the application server to use the session key associated with its
-   ticket-granting ticket to decrypt the server ticket provided in the
-   application request.
-
-4. Encryption and Checksum Specifications
-
-   The Kerberos protocols described in this document are designed to
-   encrypt messages of arbitrary sizes, using stream or block encryption
-   ciphers.  Encryption is used to prove the identities of the network
-   entities participating in message exchanges. The Key Distribution
-   Center for each realm is trusted by all principals registered in that
-   realm to store a secret key in confidence. Proof of knowledge of this
-   secret key is used to verify the authenticity of a principal.
-
-   The KDC uses the principal's secret key (in the AS exchange) or a
-   shared session key (in the TGS exchange) to encrypt responses to
-   ticket requests; the ability to obtain the secret key or session key
-   implies the knowledge of the appropriate keys and the identity of the
-   KDC. The ability of a principal to decrypt the KDC response and
-   present a Ticket and a properly formed Authenticator (generated with
-   the session key from the KDC response) to a service verifies the
-   identity of the principal; likewise the ability of the service to
-   extract the session key from the Ticket and prove its knowledge
-   thereof in a response verifies the identity of the service.
-
-   [@KCRYPTO] defines a framework for defining encryption and checksum
-   mechanisms for use with Kerberos. It also defines several such
-   mechanisms, and more may be added in future updates to that document.
-
-   The string-to-key operation provided by [@KCRYPTO] is used to produce
-   a long-term key for a principal (generally for a user). The default
-   salt string, if none is provided via pre-authentication data, is the
-   concatenation of the principal's realm and name components, in order,
-   with no separators.  Unless otherwise indicated, the default string-
-   to-key opaque parameter set as defined in [@KCRYPTO] is used.
-
-   Encrypted data, keys and checksums are transmitted using the
-   EncryptedData, EncryptionKey and Checksum data objects defined in
-   section 5.2.9. The encryption, decryption, and checksum operations
-   described in this document use the corresponding encryption,
-
-
-
-June 2004                                                      [Page 48]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   decryption, and get_mic operations described in [@KCRYPTO], with
-   implicit "specific key" generation using the "key usage" values
-   specified in the description of each EncryptedData or Checksum object
-   to vary the key for each operation. Note that in some cases, the
-   value to be used is dependent on the method of choosing the key or
-   the context of the message.
-
-   Key usages are unsigned 32 bit integers; zero is not permitted. The
-   key usage values for encrypting or checksumming Kerberos messages are
-   indicated in section 5 along with the message definitions. Key usage
-   values 512-1023 are reserved for uses internal to a Kerberos
-   implementation. (For example, seeding a pseudo-random number
-   generator with a value produced by encrypting something with a
-   session key and a key usage value not used for any other purpose.)
-   Key usage values between 1024 and 2047 (inclusive) are reserved for
-   application use; applications SHOULD use even values for encryption
-   and odd values for checksums within this range. Key usage values are
-   also summarized in a table in section 7.5.1.
-
-   There might exist other documents which define protocols in terms of
-   the RFC1510 encryption types or checksum types. Such documents would
-   not know about key usages. In order that these specifications
-   continue to be meaningful until they are updated, if no key usage
-   values are specified then key usages 1024 and 1025 must be used to
-   derive keys for encryption and checksums, respectively (this does not
-   apply to protocols that do their own encryption independent of this
-   framework, directly using the key resulting from the Kerberos
-   authentication exchange.) New protocols defined in terms of the
-   Kerberos encryption and checksum types SHOULD use their own key usage
-   values.
-
-   Unless otherwise indicated, no cipher state chaining is done from one
-   encryption operation to another.
-
-   Implementation note: While not recommended, some application
-   protocols will continue to use the key data directly, even if only in
-   currently existing protocol specifications. An implementation
-   intended to support general Kerberos applications may therefore need
-   to make key data available, as well as the attributes and operations
-   described in [@KCRYPTO].  One of the more common reasons for directly
-   performing encryption is direct control over negotiation and
-   selection of a "sufficiently strong" encryption algorithm (in the
-   context of a given application). While Kerberos does not directly
-   provide a facility for negotiating encryption types between the
-   application client and server, there are approaches for using
-   Kerberos to facilitate this negotiation - for example, a client may
-   request only "sufficiently strong" session key types from the KDC and
-   expect that any type returned by the KDC will be understood and
-
-
-
-June 2004                                                      [Page 49]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   supported by the application server.
-
-5. Message Specifications
-
-   NOTE: The ASN.1 collected here should be identical to the contents of
-   Appendix A. In case of conflict, the contents of Appendix A shall
-   take precedence.
-
-   The Kerberos protocol is defined here in terms of Abstract Syntax
-   Notation One (ASN.1) [X680], which provides a syntax for specifying
-   both the abstract layout of protocol messages as well as their
-   encodings. Implementors not utilizing an existing ASN.1 compiler or
-   support library are cautioned to thoroughly understand the actual
-   ASN.1 specification to ensure correct implementation behavior, as
-   there is more complexity in the notation than is immediately obvious,
-   and some tutorials and guides to ASN.1 are misleading or erroneous.
-
-   Note that in several places, there have been changes here from RFC
-   1510 that change the abstract types. This is in part to address
-   widespread assumptions that various implementors have made, in some
-   cases resulting in unintentional violations of the ASN.1 standard.
-   These are clearly flagged where they occur. The differences between
-   the abstract types in RFC 1510 and abstract types in this document
-   can cause incompatible encodings to be emitted when certain encoding
-   rules, e.g. the Packed Encoding Rules (PER), are used. This
-   theoretical incompatibility should not be relevant for Kerberos,
-   since Kerberos explicitly specifies the use of the Distinguished
-   Encoding Rules (DER). It might be an issue for protocols wishing to
-   use Kerberos types with other encoding rules. (This practice is not
-   recommended.) With very few exceptions (most notably the usages of
-   BIT STRING), the encodings resulting from using the DER remain
-   identical between the types defined in RFC 1510 and the types defined
-   in this document.
-
-   The type definitions in this section assume an ASN.1 module
-   definition of the following form:
-
-   KerberosV5Spec2 {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2) modules(4) krb5spec2(2)
-   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-   -- rest of definitions here
-
-   END
-
-   This specifies that the tagging context for the module will be
-   explicit and non-automatic.
-
-
-
-June 2004                                                      [Page 50]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   Note that in some other publications [RFC1510] [RFC1964], the "dod"
-   portion of the object identifier is erroneously specified as having
-   the value "5".  In the case of RFC 1964, use of the "correct" OID
-   value would result in a change in the wire protocol; therefore, it
-   remains unchanged for now.
-
-   Note that elsewhere in this document, nomenclature for various
-   message types is inconsistent, but largely follows C language
-   conventions, including use of underscore (_) characters and all-caps
-   spelling of names intended to be numeric constants. Also, in some
-   places, identifiers (especially ones referring to constants) are
-   written in all-caps in order to distinguish them from surrounding
-   explanatory text.
-
-   The ASN.1 notation does not permit underscores in identifiers, so in
-   actual ASN.1 definitions, underscores are replaced with hyphens (-).
-   Additionally, structure member names and defined values in ASN.1 MUST
-   begin with a lowercase letter, while type names MUST begin with an
-   uppercase letter.
-
-5.1. Specific Compatibility Notes on ASN.1
-
-   For compatibility purposes, implementors should heed the following
-   specific notes regarding the use of ASN.1 in Kerberos. These notes do
-   not describe deviations from standard usage of ASN.1. The purpose of
-   these notes is to instead describe some historical quirks and non-
-   compliance of various implementations, as well as historical
-   ambiguities, which, while being valid ASN.1, can lead to confusion
-   during implementation.
-
-5.1.1. ASN.1 Distinguished Encoding Rules
-
-   The encoding of Kerberos protocol messages shall obey the
-   Distinguished Encoding Rules (DER) of ASN.1 as described in [X690].
-   Some implementations (believed to be primarily ones derived from DCE
-   1.1 and earlier) are known to use the more general Basic Encoding
-   Rules (BER); in particular, these implementations send indefinite
-   encodings of lengths. Implementations MAY accept such encodings in
-   the interests of backwards compatibility, though implementors are
-   warned that decoding fully-general BER is fraught with peril.
-
-5.1.2. Optional Integer Fields
-
-   Some implementations do not internally distinguish between an omitted
-   optional integer value and a transmitted value of zero. The places in
-   the protocol where this is relevant include various microseconds
-   fields, nonces, and sequence numbers. Implementations SHOULD treat
-   omitted optional integer values as having been transmitted with a
-
-
-
-June 2004                                                      [Page 51]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   value of zero, if the application is expecting this.
-
-5.1.3. Empty SEQUENCE OF Types
-
-   There are places in the protocol where a message contains a SEQUENCE
-   OF type as an optional member. This can result in an encoding that
-   contains an empty SEQUENCE OF encoding. The Kerberos protocol does
-   not semantically distinguish between an absent optional SEQUENCE OF
-   type and a present optional but empty SEQUENCE OF type.
-   Implementations SHOULD NOT send empty SEQUENCE OF encodings that are
-   marked OPTIONAL, but SHOULD accept them as being equivalent to an
-   omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos
-   messages, instances of these problematic optional SEQUENCE OF types
-   are indicated with a comment.
-
-5.1.4. Unrecognized Tag Numbers
-
-   Future revisions to this protocol may include new message types with
-   different APPLICATION class tag numbers. Such revisions should
-   protect older implementations by only sending the message types to
-   parties that are known to understand them, e.g. by means of a flag
-   bit set by the receiver in a preceding request. In the interest of
-   robust error handling, implementations SHOULD gracefully handle
-   receiving a message with an unrecognized tag anyway, and return an
-   error message if appropriate.
-
-   In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the
-   incorrect tag is sent over a TCP transport.  The KDCs SHOULD NOT
-   respond to messages received with an unknown tag over UDP transport
-   in order to avoid denial of service attacks.  For non-KDC
-   applications, the Kerberos implementation typically indicates an
-   error to the application which takes appropriate steps based on the
-   application protocol.
-
-5.1.5. Tag Numbers Greater Than 30
-
-   A naive implementation of a DER ASN.1 decoder may experience problems
-   with ASN.1 tag numbers greater than 30, due to such tag numbers being
-   encoded using more than one byte. Future revisions of this protocol
-   may utilize tag numbers greater than 30, and implementations SHOULD
-   be prepared to gracefully return an error, if appropriate, if they do
-   not recognize the tag.
-
-5.2. Basic Kerberos Types
-
-   This section defines a number of basic types that are potentially
-   used in multiple Kerberos protocol messages.
-
-
-
-
-June 2004                                                      [Page 52]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-5.2.1. KerberosString
-
-   The original specification of the Kerberos protocol in RFC 1510 uses
-   GeneralString in numerous places for human-readable string data.
-   Historical implementations of Kerberos cannot utilize the full power
-   of GeneralString.  This ASN.1 type requires the use of designation
-   and invocation escape sequences as specified in ISO-2022/ECMA-35
-   [ISO-2022/ECMA-35] to switch character sets, and the default
-   character set that is designated as G0 is the ISO-646/ECMA-6
-   [ISO-646,ECMA-6] International Reference Version (IRV) (aka U.S.
-   ASCII), which mostly works.
-
-   ISO-2022/ECMA-35 defines four character-set code elements (G0..G3)
-   and two Control-function code elements (C0..C1). DER prohibits the
-   designation of character sets as any but the G0 and C0 sets.
-   Unfortunately, this seems to have the side effect of prohibiting the
-   use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any other
-   character-sets that utilize a 96-character set, since it is
-   prohibited by ISO-2022/ECMA-35 to designate them as the G0 code
-   element. This side effect is being investigated in the ASN.1
-   standards community.
-
-   In practice, many implementations treat GeneralStrings as if they
-   were 8-bit strings of whichever character set the implementation
-   defaults to, without regard for correct usage of character-set
-   designation escape sequences. The default character set is often
-   determined by the current user's operating system dependent locale.
-   At least one major implementation places unescaped UTF-8 encoded
-   Unicode characters in the GeneralString. This failure to adhere to
-   the GeneralString specifications results in interoperability issues
-   when conflicting character encodings are utilized by the Kerberos
-   clients, services, and KDC.
-
-   This unfortunate situation is the result of improper documentation of
-   the restrictions of the ASN.1 GeneralString type in prior Kerberos
-   specifications.
-
-   The new (post-RFC 1510) type KerberosString, defined below, is a
-   GeneralString that is constrained to only contain characters in
-   IA5String
-
-      KerberosString  ::= GeneralString (IA5String)
-
-   In general, US-ASCII control characters should not be used in
-   KerberosString. Control characters SHOULD NOT be used in principal
-   names or realm names.
-
-   For compatibility, implementations MAY choose to accept GeneralString
-
-
-
-June 2004                                                      [Page 53]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   values that contain characters other than those permitted by
-   IA5String, but they should be aware that character set designation
-   codes will likely be absent, and that the encoding should probably be
-   treated as locale-specific in almost every way. Implementations MAY
-   also choose to emit GeneralString values that are beyond those
-   permitted by IA5String, but should be aware that doing so is
-   extraordinarily risky from an interoperability perspective.
-
-   Some existing implementations use GeneralString to encode unescaped
-   locale-specific characters. This is a violation of the ASN.1
-   standard. Most of these implementations encode US-ASCII in the left-
-   hand half, so as long the implementation transmits only US-ASCII, the
-   ASN.1 standard is not violated in this regard. As soon as such an
-   implementation encodes unescaped locale-specific characters with the
-   high bit set, it violates the ASN.1 standard.
-
-   Other implementations have been known to use GeneralString to contain
-   a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8
-   is a different encoding, not a 94 or 96 character "G" set as defined
-   by ISO 2022.  It is believed that these implementations do not even
-   use the ISO 2022 escape sequence to change the character encoding.
-   Even if implementations were to announce the change of encoding by
-   using that escape sequence, the ASN.1 standard prohibits the use of
-   any escape sequences other than those used to designate/invoke "G" or
-   "C" sets allowed by GeneralString.
-
-   Future revisions to this protocol will almost certainly allow for a
-   more interoperable representation of principal names, probably
-   including UTF8String.
-
-   Note that applying a new constraint to a previously unconstrained
-   type constitutes creation of a new ASN.1 type. In this particular
-   case, the change does not result in a changed encoding under DER.
-
-5.2.2. Realm and PrincipalName
-
-   Realm           ::= KerberosString
-
-   PrincipalName   ::= SEQUENCE {
-           name-type       [0] Int32,
-           name-string     [1] SEQUENCE OF KerberosString
-   }
-
-   Kerberos realm names are encoded as KerberosStrings. Realms shall not
-   contain a character with the code 0 (the US-ASCII NUL). Most realms
-   will usually consist of several components separated by periods (.),
-   in the style of Internet Domain Names, or separated by slashes (/) in
-   the style of X.500 names. Acceptable forms for realm names are
-
-
-
-June 2004                                                      [Page 54]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   specified in section 6.1.. A PrincipalName is a typed sequence of
-   components consisting of the following sub-fields:
-
-   name-type
-      This field specifies the type of name that follows. Pre-defined
-      values for this field are specified in section 6.2. The name-type
-      SHOULD be treated as a hint. Ignoring the name type, no two names
-      can be the same (i.e. at least one of the components, or the
-      realm, must be different).
-
-   name-string
-      This field encodes a sequence of components that form a name, each
-      component encoded as a KerberosString. Taken together, a
-      PrincipalName and a Realm form a principal identifier. Most
-      PrincipalNames will have only a few components (typically one or
-      two).
-
-5.2.3. KerberosTime
-
-   KerberosTime    ::= GeneralizedTime -- with no fractional seconds
-
-   The timestamps used in Kerberos are encoded as GeneralizedTimes. A
-   KerberosTime value shall not include any fractional portions of the
-   seconds.  As required by the DER, it further shall not include any
-   separators, and it shall specify the UTC time zone (Z). Example: The
-   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
-   November 1985 is 19851106210627Z.
-
-5.2.4. Constrained Integer types
-
-   Some integer members of types SHOULD be constrained to values
-   representable in 32 bits, for compatibility with reasonable
-   implementation limits.
-
-   Int32           ::= INTEGER (-2147483648..2147483647)
-                       -- signed values representable in 32 bits
-
-   UInt32          ::= INTEGER (0..4294967295)
-                       -- unsigned 32 bit values
-
-   Microseconds    ::= INTEGER (0..999999)
-                       -- microseconds
-
-   While this results in changes to the abstract types from the RFC 1510
-   version, the encoding in DER should be unaltered. Historical
-   implementations were typically limited to 32-bit integer values
-   anyway, and assigned numbers SHOULD fall in the space of integer
-   values representable in 32 bits in order to promote interoperability
-
-
-
-June 2004                                                      [Page 55]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   anyway.
-
-   There are several integer fields in messages that are constrained to
-   fixed values.
-
-   pvno
-      also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always
-      the constant integer 5. There is no easy way to make this field
-      into a useful protocol version number, so its value is fixed.
-
-   msg-type
-      this integer field is usually identical to the application tag
-      number of the containing message type.
-
-5.2.5. HostAddress and HostAddresses
-
-   HostAddress     ::= SEQUENCE  {
-           addr-type       [0] Int32,
-           address         [1] OCTET STRING
-   }
-
-   -- NOTE: HostAddresses is always used as an OPTIONAL field and
-   -- should not be empty.
-   HostAddresses   -- NOTE: subtly different from rfc1510,
-                   -- but has a value mapping and encodes the same
-           ::= SEQUENCE OF HostAddress
-
-   The host address encodings consists of two fields:
-
-   addr-type
-      This field specifies the type of address that follows. Pre-defined
-      values for this field are specified in section 7.5.3.
-
-   address
-      This field encodes a single address of type addr-type.
-
-5.2.6. AuthorizationData
-
-      -- NOTE: AuthorizationData is always used as an OPTIONAL field and
-      -- should not be empty.
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-              ad-type         [0] Int32,
-              ad-data         [1] OCTET STRING
-      }
-
-   ad-data
-      This field contains authorization data to be interpreted according
-      to the value of the corresponding ad-type field.
-
-
-
-June 2004                                                      [Page 56]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   ad-type
-      This field specifies the format for the ad-data subfield. All
-      negative values are reserved for local use. Non-negative values
-      are reserved for registered use.
-
-   Each sequence of type and data is referred to as an authorization
-   element.  Elements MAY be application specific, however, there is a
-   common set of recursive elements that should be understood by all
-   implementations. These elements contain other elements embedded
-   within them, and the interpretation of the encapsulating element
-   determines which of the embedded elements must be interpreted, and
-   which may be ignored.
-
-   These common authorization data elements are recursively defined,
-   meaning the ad-data for these types will itself contain a sequence of
-   authorization data whose interpretation is affected by the
-   encapsulating element. Depending on the meaning of the encapsulating
-   element, the encapsulated elements may be ignored, might be
-   interpreted as issued directly by the KDC, or they might be stored in
-   a separate plaintext part of the ticket. The types of the
-   encapsulating elements are specified as part of the Kerberos
-   specification because the behavior based on these values should be
-   understood across implementations whereas other elements need only be
-   understood by the applications which they affect.
-
-   Authorization data elements are considered critical if present in a
-   ticket or authenticator. Unless encapsulated in a known authorization
-   data element amending the criticality of the elements it contains, if
-   an unknown authorization data element type is received by a server
-   either in an AP-REQ or in a ticket contained in an AP-REQ, then
-   authentication MUST fail.  Authorization data is intended to restrict
-   the use of a ticket. If the service cannot determine whether the
-   restriction applies to that service then a security weakness may
-   result if the ticket can be used for that service. Authorization
-   elements that are optional can be enclosed in AD-IF-RELEVANT element.
-
-   In the definitions that follow, the value of the ad-type for the
-   element will be specified as the least significant part of the
-   subsection number, and the value of the ad-data will be as shown in
-   the ASN.1 structure that follows the subsection heading.
-
-             contents of ad-data          ad-type
-
-    DER encoding of AD-IF-RELEVANT        1
-
-    DER encoding of AD-KDCIssued          4
-
-    DER encoding of AD-AND-OR             5
-
-
-
-June 2004                                                      [Page 57]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-    DER encoding of AD-MANDATORY-FOR-KDC  8
-
-5.2.6.1. IF-RELEVANT
-
-   AD-IF-RELEVANT          ::= AuthorizationData
-
-   AD elements encapsulated within the if-relevant element are intended
-   for interpretation only by application servers that understand the
-   particular ad-type of the embedded element. Application servers that
-   do not understand the type of an element embedded within the if-
-   relevant element MAY ignore the uninterpretable element. This element
-   promotes interoperability across implementations which may have local
-   extensions for authorization.  The ad-type for AD-IF-RELEVANT is (1).
-
-5.2.6.2. KDCIssued
-
-   AD-KDCIssued            ::= SEQUENCE {
-           ad-checksum     [0] Checksum,
-           i-realm         [1] Realm OPTIONAL,
-           i-sname         [2] PrincipalName OPTIONAL,
-           elements        [3] AuthorizationData
-   }
-
-   ad-checksum
-      A cryptographic checksum computed over the DER encoding of the
-      AuthorizationData in the "elements" field, keyed with the session
-      key.  Its checksumtype is the mandatory checksum type for the
-      encryption type of the session key, and its key usage value is 19.
-
-   i-realm, i-sname
-      The name of the issuing principal if different from the KDC
-      itself.  This field would be used when the KDC can verify the
-      authenticity of elements signed by the issuing principal and it
-      allows this KDC to notify the application server of the validity
-      of those elements.
-
-   elements
-      A sequence of authorization data elements issued by the KDC.
-
-   The KDC-issued ad-data field is intended to provide a means for
-   Kerberos principal credentials to embed within themselves privilege
-   attributes and other mechanisms for positive authorization,
-   amplifying the privileges of the principal beyond what can be done
-   using a credentials without such an a-data element.
-
-   This can not be provided without this element because the definition
-   of the authorization-data field allows elements to be added at will
-   by the bearer of a TGT at the time that they request service tickets
-
-
-
-June 2004                                                      [Page 58]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   and elements may also be added to a delegated ticket by inclusion in
-   the authenticator.
-
-   For KDC-issued elements this is prevented because the elements are
-   signed by the KDC by including a checksum encrypted using the
-   server's key (the same key used to encrypt the ticket - or a key
-   derived from that key). Elements encapsulated with in the KDC-issued
-   element MUST  be ignored by the application server if this
-   "signature" is not present. Further, elements encapsulated within
-   this element from a ticket-granting ticket MAY be interpreted by the
-   KDC, and used as a basis according to policy for including new signed
-   elements within derivative tickets, but they will not be copied to a
-   derivative ticket directly. If they are copied directly to a
-   derivative ticket by a KDC that is not aware of this element, the
-   signature will not be correct for the application ticket elements,
-   and the field will be ignored by the application server.
-
-   This element and the elements it encapsulates MAY be safely ignored
-   by applications, application servers, and KDCs that do not implement
-   this element.
-
-   The ad-type for AD-KDC-ISSUED is (4).
-
-5.2.6.3. AND-OR
-
-   AD-AND-OR               ::= SEQUENCE {
-           condition-count [0] INTEGER,
-           elements        [1] AuthorizationData
-   }
-
-
-   When restrictive AD elements are encapsulated within the and-or
-   element, the and-or element is considered satisfied if and only if at
-   least the number of encapsulated elements specified in condition-
-   count are satisfied.  Therefore, this element MAY be used to
-   implement an "or" operation by setting the condition-count field to
-   1, and it MAY specify an "and" operation by setting the condition
-   count to the number of embedded elements. Application servers that do
-   not implement this element MUST reject tickets that contain
-   authorization data elements of this type.
-
-   The ad-type for AD-AND-OR is (5).
-
-5.2.6.4. MANDATORY-FOR-KDC
-
-   AD-MANDATORY-FOR-KDC    ::= AuthorizationData
-
-   AD elements encapsulated within the mandatory-for-kdc element are to
-
-
-
-June 2004                                                      [Page 59]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   be interpreted by the KDC. KDCs that do not understand the type of an
-   element embedded within the mandatory-for-kdc element MUST reject the
-   request.
-
-   The ad-type for AD-MANDATORY-FOR-KDC is (8).
-
-5.2.7. PA-DATA
-
-   Historically, PA-DATA have been known as "pre-authentication data",
-   meaning that they were used to augment the initial authentication
-   with the KDC.  Since that time, they have also been used as a typed
-   hole with which to extend protocol exchanges with the KDC.
-
-   PA-DATA         ::= SEQUENCE {
-           -- NOTE: first tag is [1], not [0]
-           padata-type     [1] Int32,
-           padata-value    [2] OCTET STRING -- might be encoded AP-REQ
-   }
-
-   padata-type
-      indicates the way that the padata-value element is to be
-      interpreted.  Negative values of padata-type are reserved for
-      unregistered use; non-negative values are used for a registered
-      interpretation of the element type.
-
-   padata-value
-      Usually contains the DER encoding of another type; the padata-type
-      field identifies which type is encoded here.
-
-       padata-type        name           contents of padata-value
-
-       1            pa-tgs-req       DER encoding of AP-REQ
-
-       2            pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP
-
-       3            pa-pw-salt       salt (not ASN.1 encoded)
-
-       11           pa-etype-info    DER encoding of ETYPE-INFO
-
-       19           pa-etype-info2   DER encoding of ETYPE-INFO2
-
-      This field MAY also contain information needed by certain
-      extensions to the Kerberos protocol. For example, it might be used
-      to initially verify the identity of a client before any response
-      is returned.
-
-      The padata field can also contain information needed to help the
-      KDC or the client select the key needed for generating or
-
-
-
-June 2004                                                      [Page 60]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      decrypting the response. This form of the padata is useful for
-      supporting the use of certain token cards with Kerberos. The
-      details of such extensions are specified in separate documents.
-      See [Pat92] for additional uses of this field.
-
-5.2.7.1. PA-TGS-REQ
-
-   In the case of requests for additional tickets (KRB_TGS_REQ), padata-
-   value will contain an encoded AP-REQ. The checksum in the
-   authenticator (which MUST be collision-proof) is to be computed over
-   the KDC-REQ-BODY encoding.
-
-5.2.7.2. Encrypted Timestamp Pre-authentication
-
-   There are pre-authentication types that may be used to pre-
-   authenticate a client by means of an encrypted timestamp.
-
-   PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
-
-   PA-ENC-TS-ENC           ::= SEQUENCE {
-           patimestamp     [0] KerberosTime -- client's time --,
-           pausec          [1] Microseconds OPTIONAL
-   }
-
-   Patimestamp contains the client's time, and pausec contains the
-   microseconds, which MAY be omitted if a client will not generate more
-   than one request per second. The ciphertext (padata-value) consists
-   of the PA-ENC-TS-ENC encoding, encrypted using the client's secret
-   key and a key usage value of 1.
-
-   This pre-authentication type was not present in RFC 1510, but many
-   implementations support it.
-
-5.2.7.3. PA-PW-SALT
-
-   The padata-value for this pre-authentication type contains the salt
-   for the string-to-key to be used by the client to obtain the key for
-   decrypting the encrypted part of an AS-REP message. Unfortunately,
-   for historical reasons, the character set to be used is unspecified
-   and probably locale-specific.
-
-   This pre-authentication type was not present in RFC 1510, but many
-   implementations support it. It is necessary in any case where the
-   salt for the string-to-key algorithm is not the default.
-
-   In the trivial example, a zero-length salt string is very commonplace
-   for realms that have converted their principal databases from
-   Kerberos 4.
-
-
-
-June 2004                                                      [Page 61]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message
-   that requests additional pre-authentication. Implementation note:
-   some KDC implementations issue an erroneous PA-PW-SALT when issuing a
-   KRB-ERROR message that requests additional pre-authentication.
-   Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a KRB-
-   ERROR message that requests additional pre-authentication.  As noted
-   in section 3.1.3, a KDC MUST NOT send PA-PW-SALT when the client's
-   AS-REQ includes at least one "newer" etype.
-
-5.2.7.4. PA-ETYPE-INFO
-
-   The ETYPE-INFO pre-authentication type is sent by the KDC in a KRB-
-   ERROR indicating a requirement for additional pre-authentication. It
-   is usually used to notify a client of which key to use for the
-   encryption of an encrypted timestamp for the purposes of sending a
-   PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an
-   AS-REP to provide information to the client about which key salt to
-   use for the string-to-key to be used by the client to obtain the key
-   for decrypting the encrypted part the AS-REP.
-
-   ETYPE-INFO-ENTRY        ::= SEQUENCE {
-           etype           [0] Int32,
-           salt            [1] OCTET STRING OPTIONAL
-   }
-
-   ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
-
-   The salt, like that of PA-PW-SALT, is also completely unspecified
-   with respect to character set and is probably locale-specific.
-
-   If ETYPE-INFO is sent in an AS-REP, there shall be exactly one ETYPE-
-   INFO-ENTRY, and its etype shall match that of the enc-part in the AS-
-   REP.
-
-   This pre-authentication type was not present in RFC 1510, but many
-   implementations that support encrypted timestamps for pre-
-   authentication need to support ETYPE-INFO as well.  As noted in
-   section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's
-   AS-REQ includes at least one "newer" etype.
-
-5.2.7.5. PA-ETYPE-INFO2
-
-   The ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB-
-   ERROR indicating a requirement for additional pre-authentication. It
-   is usually used to notify a client of which key to use for the
-   encryption of an encrypted timestamp for the purposes of sending a
-   PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an
-   AS-REP to provide information to the client about which key salt to
-
-
-
-June 2004                                                      [Page 62]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   use for the string-to-key to be used by the client to obtain the key
-   for decrypting the encrypted part the AS-REP.
-
-   ETYPE-INFO2-ENTRY       ::= SEQUENCE {
-           etype           [0] Int32,
-           salt            [1] KerberosString OPTIONAL,
-           s2kparams       [2] OCTET STRING OPTIONAL
-   }
-
-   ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
-
-   The type of the salt is KerberosString, but existing installations
-   might have locale-specific characters stored in salt strings, and
-   implementors MAY choose to handle them.
-
-   The interpretation of s2kparams is specified in the cryptosystem
-   description associated with the etype. Each cryptosystem has a
-   default interpretation of s2kparams that will hold if that element is
-   omitted from the encoding of ETYPE-INFO2-ENTRY.
-
-   If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one
-   ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in
-   the AS-REP.
-
-   The preferred ordering of the "hint" pre-authentication data that
-   affect client key selection is: ETYPE-INFO2, followed by ETYPE-INFO,
-   followed by PW-SALT.  As noted in section 3.1.3, a KDC MUST NOT send
-   ETYPE-INFO or PW-SALT when the client's AS-REQ includes at least one
-   "newer" etype.
-
-   The ETYPE-INFO2 pre-authentication type was not present in RFC 1510.
-
-5.2.8. KerberosFlags
-
-   For several message types, a specific constrained bit string type,
-   KerberosFlags, is used.
-
-   KerberosFlags   ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
-                       -- shall be sent, but no fewer than 32
-
-   Compatibility note: the following paragraphs describe a change from
-   the RFC1510 description of bit strings that would result in
-   incompatility in the case of an implementation that strictly
-   conformed to ASN.1 DER and RFC1510.
-
-   ASN.1 bit strings have multiple uses. The simplest use of a bit
-   string is to contain a vector of bits, with no particular meaning
-   attached to individual bits. This vector of bits is not necessarily a
-
-
-
-June 2004                                                      [Page 63]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   multiple of eight bits long.  The use in Kerberos of a bit string as
-   a compact boolean vector wherein each element has a distinct meaning
-   poses some problems. The natural notation for a compact boolean
-   vector is the ASN.1 "NamedBit" notation, and the DER require that
-   encodings of a bit string using "NamedBit" notation exclude any
-   trailing zero bits. This truncation is easy to neglect, especially
-   given C language implementations that naturally choose to store
-   boolean vectors as 32 bit integers.
-
-   For example, if the notation for KDCOptions were to include the
-   "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be
-   encoded had only the "forwardable" (bit number one) bit set, the DER
-   encoding MUST include only two bits: the first reserved bit
-   ("reserved", bit number zero, value zero) and the one-valued bit (bit
-   number one) for "forwardable".
-
-   Most existing implementations of Kerberos unconditionally send 32
-   bits on the wire when encoding bit strings used as boolean vectors.
-   This behavior violates the ASN.1 syntax used for flag values in RFC
-   1510, but occurs on such a widely installed base that the protocol
-   description is being modified to accommodate it.
-
-   Consequently, this document removes the "NamedBit" notations for
-   individual bits, relegating them to comments. The size constraint on
-   the KerberosFlags type requires that at least 32 bits be encoded at
-   all times, though a lenient implementation MAY choose to accept fewer
-   than 32 bits and to treat the missing bits as set to zero.
-
-   Currently, no uses of KerberosFlags specify more than 32 bits worth
-   of flags, although future revisions of this document may do so. When
-   more than 32 bits are to be transmitted in a KerberosFlags value,
-   future revisions to this document will likely specify that the
-   smallest number of bits needed to encode the highest-numbered one-
-   valued bit should be sent. This is somewhat similar to the DER
-   encoding of a bit string that is declared with the "NamedBit"
-   notation.
-
-5.2.9. Cryptosystem-related Types
-
-   Many Kerberos protocol messages contain an EncryptedData as a
-   container for arbitrary encrypted data, which is often the encrypted
-   encoding of another data type. Fields within EncryptedData assist the
-   recipient in selecting a key with which to decrypt the enclosed data.
-
-   EncryptedData   ::= SEQUENCE {
-           etype   [0] Int32 -- EncryptionType --,
-           kvno    [1] UInt32 OPTIONAL,
-           cipher  [2] OCTET STRING -- ciphertext
-
-
-
-June 2004                                                      [Page 64]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   }
-
-   etype
-      This field identifies which encryption algorithm was used to
-      encipher the cipher.
-
-   kvno
-      This field contains the version number of the key under which data
-      is encrypted. It is only present in messages encrypted under long
-      lasting keys, such as principals' secret keys.
-
-   cipher
-      This field contains the enciphered text, encoded as an OCTET
-      STRING.  (Note that the encryption mechanisms defined in
-      [@KCRYPTO] MUST incorporate integrity protection as well, so no
-      additional checksum is required.)
-
-   The EncryptionKey type is the means by which cryptographic keys used
-   for encryption are transferred.
-
-   EncryptionKey   ::= SEQUENCE {
-           keytype         [0] Int32 -- actually encryption type --,
-           keyvalue        [1] OCTET STRING
-   }
-
-   keytype
-      This field specifies the encryption type of the encryption key
-      that follows in the keyvalue field. While its name is "keytype",
-      it actually specifies an encryption type. Previously, multiple
-      cryptosystems that performed encryption differently but were
-      capable of using keys with the same characteristics were permitted
-      to share an assigned number to designate the type of key; this
-      usage is now deprecated.
-
-   keyvalue
-      This field contains the key itself, encoded as an octet string.
-
-   Messages containing cleartext data to be authenticated will usually
-   do so by using a member of type Checksum. Most instances of Checksum
-   use a keyed hash, though exceptions will be noted.
-
-   Checksum        ::= SEQUENCE {
-           cksumtype       [0] Int32,
-           checksum        [1] OCTET STRING
-   }
-
-   cksumtype
-      This field indicates the algorithm used to generate the
-
-
-
-June 2004                                                      [Page 65]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      accompanying checksum.
-
-   checksum
-      This field contains the checksum itself, encoded as an octet
-      string.
-
-   See section 4 for a brief description of the use of encryption and
-   checksums in Kerberos.
-
-5.3. Tickets
-
-   This section describes the format and encryption parameters for
-   tickets and authenticators. When a ticket or authenticator is
-   included in a protocol message it is treated as an opaque object. A
-   ticket is a record that helps a client authenticate to a service. A
-   Ticket contains the following information:
-
-   Ticket          ::= [APPLICATION 1] SEQUENCE {
-           tkt-vno         [0] INTEGER (5),
-           realm           [1] Realm,
-           sname           [2] PrincipalName,
-           enc-part        [3] EncryptedData -- EncTicketPart
-   }
-
-   -- Encrypted part of ticket
-   EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
-           flags                   [0] TicketFlags,
-           key                     [1] EncryptionKey,
-           crealm                  [2] Realm,
-           cname                   [3] PrincipalName,
-           transited               [4] TransitedEncoding,
-           authtime                [5] KerberosTime,
-           starttime               [6] KerberosTime OPTIONAL,
-           endtime                 [7] KerberosTime,
-           renew-till              [8] KerberosTime OPTIONAL,
-           caddr                   [9] HostAddresses OPTIONAL,
-           authorization-data      [10] AuthorizationData OPTIONAL
-   }
-
-   -- encoded Transited field
-   TransitedEncoding       ::= SEQUENCE {
-           tr-type         [0] Int32 -- must be registered --,
-           contents        [1] OCTET STRING
-   }
-
-   TicketFlags     ::= KerberosFlags
-           -- reserved(0),
-           -- forwardable(1),
-
-
-
-June 2004                                                      [Page 66]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-           -- forwarded(2),
-           -- proxiable(3),
-           -- proxy(4),
-           -- may-postdate(5),
-           -- postdated(6),
-           -- invalid(7),
-           -- renewable(8),
-           -- initial(9),
-           -- pre-authent(10),
-           -- hw-authent(11),
-   -- the following are new since 1510
-           -- transited-policy-checked(12),
-           -- ok-as-delegate(13)
-
-   tkt-vno
-      This field specifies the version number for the ticket format.
-      This document describes version number 5.
-
-   realm
-      This field specifies the realm that issued a ticket. It also
-      serves to identify the realm part of the server's principal
-      identifier. Since a Kerberos server can only issue tickets for
-      servers within its realm, the two will always be identical.
-
-   sname
-      This field specifies all components of the name part of the
-      server's identity, including those parts that identify a specific
-      instance of a service.
-
-   enc-part
-      This field holds the encrypted encoding of the EncTicketPart
-      sequence.  It is encrypted in the key shared by Kerberos and the
-      end server (the server's secret key), using a key usage value of
-      2.
-
-   flags
-      This field indicates which of various options were used or
-      requested when the ticket was issued. The meanings of the flags
-      are:
-
-         Bit(s)  Name                   Description
-
-         0       reserved               Reserved for future expansion of this
-                                        field.
-
-                                        The FORWARDABLE flag is normally only
-                                        interpreted by the TGS, and can be
-                                        ignored by end servers. When set, this
-
-
-
-June 2004                                                      [Page 67]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-         1       forwardable            flag tells the ticket-granting server
-                                        that it is OK to issue a new
-                                        ticket-granting ticket with a
-                                        different network address based on the
-                                        presented ticket.
-
-                                        When set, this flag indicates that the
-                                        ticket has either been forwarded or
-         2       forwarded              was issued based on authentication
-                                        involving a forwarded ticket-granting
-                                        ticket.
-
-                                        The PROXIABLE flag is normally only
-                                        interpreted by the TGS, and can be
-                                        ignored by end servers. The PROXIABLE
-                                        flag has an interpretation identical
-         3       proxiable              to that of the FORWARDABLE flag,
-                                        except that the PROXIABLE flag tells
-                                        the ticket-granting server that only
-                                        non-ticket-granting tickets may be
-                                        issued with different network
-                                        addresses.
-
-         4       proxy                  When set, this flag indicates that a
-                                        ticket is a proxy.
-
-                                        The MAY-POSTDATE flag is normally only
-                                        interpreted by the TGS, and can be
-         5       may-postdate           ignored by end servers. This flag
-                                        tells the ticket-granting server that
-                                        a post-dated ticket MAY be issued
-                                        based on this ticket-granting ticket.
-
-                                        This flag indicates that this ticket
-                                        has been postdated. The end-service
-         6       postdated              can check the authtime field to see
-                                        when the original authentication
-                                        occurred.
-
-                                        This flag indicates that a ticket is
-                                        invalid, and it must be validated by
-         7       invalid                the KDC before use. Application
-                                        servers must reject tickets which have
-                                        this flag set.
-
-                                        The RENEWABLE flag is normally only
-                                        interpreted by the TGS, and can
-                                        usually be ignored by end servers
-
-
-
-June 2004                                                      [Page 68]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-         8       renewable              (some particularly careful servers MAY
-                                        disallow renewable tickets). A
-                                        renewable ticket can be used to obtain
-                                        a replacement ticket that expires at a
-                                        later date.
-
-                                        This flag indicates that this ticket
-         9       initial                was issued using the AS protocol, and
-                                        not issued based on a ticket-granting
-                                        ticket.
-
-                                        This flag indicates that during
-                                        initial authentication, the client was
-                                        authenticated by the KDC before a
-         10      pre-authent            ticket was issued. The strength of the
-                                        pre-authentication method is not
-                                        indicated, but is acceptable to the
-                                        KDC.
-
-                                        This flag indicates that the protocol
-                                        employed for initial authentication
-                                        required the use of hardware expected
-         11      hw-authent             to be possessed solely by the named
-                                        client. The hardware authentication
-                                        method is selected by the KDC and the
-                                        strength of the method is not
-                                        indicated.
-
-                                        This flag indicates that the KDC for
-                                        the realm has checked the transited
-                                        field against a realm defined policy
-                                        for trusted certifiers. If this flag
-                                        is reset (0), then the application
-                                        server must check the transited field
-                                        itself, and if unable to do so it must
-                                        reject the authentication. If the flag
-         12      transited-             is set (1) then the application server
-                 policy-checked         MAY skip its own validation of the
-                                        transited field, relying on the
-                                        validation performed by the KDC. At
-                                        its option the application server MAY
-                                        still apply its own validation based
-                                        on a separate policy for acceptance.
-
-                                        This flag is new since RFC 1510.
-
-                                        This flag indicates that the server
-                                        (not the client) specified in the
-
-
-
-June 2004                                                      [Page 69]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-                                        ticket has been determined by policy
-                                        of the realm to be a suitable
-                                        recipient of delegation. A client can
-                                        use the presence of this flag to help
-                                        it make a decision whether to delegate
-                                        credentials (either grant a proxy or a
-                                        forwarded ticket-granting ticket) to
-         13      ok-as-delegate         this server. The client is free to
-                                        ignore the value of this flag. When
-                                        setting this flag, an administrator
-                                        should consider the Security and
-                                        placement of the server on which the
-                                        service will run, as well as whether
-                                        the service requires the use of
-                                        delegated credentials.
-
-                                        This flag is new since RFC 1510.
-
-         14-31   reserved               Reserved for future use.
-
-   key
-      This field exists in the ticket and the KDC response and is used
-      to pass the session key from Kerberos to the application server
-      and the client.
-
-   crealm
-      This field contains the name of the realm in which the client is
-      registered and in which initial authentication took place.
-
-   cname
-      This field contains the name part of the client's principal
-      identifier.
-
-   transited
-      This field lists the names of the Kerberos realms that took part
-      in authenticating the user to whom this ticket was issued. It does
-      not specify the order in which the realms were transited. See
-      section 3.3.3.2 for details on how this field encodes the
-      traversed realms.  When the names of CA's are to be embedded in
-      the transited field (as specified for some extensions to the
-      protocol), the X.500 names of the CA's SHOULD be mapped into items
-      in the transited field using the mapping defined by RFC2253.
-
-   authtime
-      This field indicates the time of initial authentication for the
-      named principal. It is the time of issue for the original ticket
-      on which this ticket is based. It is included in the ticket to
-      provide additional information to the end service, and to provide
-
-
-
-June 2004                                                      [Page 70]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      the necessary information for implementation of a `hot list'
-      service at the KDC. An end service that is particularly paranoid
-      could refuse to accept tickets for which the initial
-      authentication occurred "too far" in the past. This field is also
-      returned as part of the response from the KDC.  When returned as
-      part of the response to initial authentication (KRB_AS_REP), this
-      is the current time on the Kerberos server.  It is NOT recommended
-      that this time value be used to adjust the workstation's clock
-      since the workstation cannot reliably determine that such a
-      KRB_AS_REP actually came from the proper KDC in a timely manner.
-
-
-   starttime
-
-      This field in the ticket specifies the time after which the ticket
-      is valid. Together with endtime, this field specifies the life of
-      the ticket. If the starttime field is absent from the ticket, then
-      the authtime field SHOULD be used in its place to determine the
-      life of the ticket.
-
-   endtime
-      This field contains the time after which the ticket will not be
-      honored (its expiration time). Note that individual services MAY
-      place their own limits on the life of a ticket and MAY reject
-      tickets which have not yet expired. As such, this is really an
-      upper bound on the expiration time for the ticket.
-
-   renew-till
-      This field is only present in tickets that have the RENEWABLE flag
-      set in the flags field. It indicates the maximum endtime that may
-      be included in a renewal. It can be thought of as the absolute
-      expiration time for the ticket, including all renewals.
-
-   caddr
-      This field in a ticket contains zero (if omitted) or more (if
-      present) host addresses. These are the addresses from which the
-      ticket can be used. If there are no addresses, the ticket can be
-      used from any location. The decision by the KDC to issue or by the
-      end server to accept addressless tickets is a policy decision and
-      is left to the Kerberos and end-service administrators; they MAY
-      refuse to issue or accept such tickets. Because of the wide
-      deployment of network address translation, it is recommended that
-      policy allow the issue and acceptance of such tickets.
-
-      Network addresses are included in the ticket to make it harder for
-      an attacker to use stolen credentials. Because the session key is
-      not sent over the network in cleartext, credentials can't be
-      stolen simply by listening to the network; an attacker has to gain
-
-
-
-June 2004                                                      [Page 71]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      access to the session key (perhaps through operating system
-      security breaches or a careless user's unattended session) to make
-      use of stolen tickets.
-
-      It is important to note that the network address from which a
-      connection is received cannot be reliably determined. Even if it
-      could be, an attacker who has compromised the client's workstation
-      could use the credentials from there. Including the network
-      addresses only makes it more difficult, not impossible, for an
-      attacker to walk off with stolen credentials and then use them
-      from a "safe" location.
-
-   authorization-data
-      The authorization-data field is used to pass authorization data
-      from the principal on whose behalf a ticket was issued to the
-      application service. If no authorization data is included, this
-      field will be left out. Experience has shown that the name of this
-      field is confusing, and that a better name for this field would be
-      restrictions. Unfortunately, it is not possible to change the name
-      of this field at this time.
-
-      This field contains restrictions on any authority obtained on the
-      basis of authentication using the ticket. It is possible for any
-      principal in possession of credentials to add entries to the
-      authorization data field since these entries further restrict what
-      can be done with the ticket.  Such additions can be made by
-      specifying the additional entries when a new ticket is obtained
-      during the TGS exchange, or they MAY be added during chained
-      delegation using the authorization data field of the
-      authenticator.
-
-      Because entries may be added to this field by the holder of
-      credentials, except when an entry is separately authenticated by
-      encapsulation in the KDC-issued element, it is not allowable for
-      the presence of an entry in the authorization data field of a
-      ticket to amplify the privileges one would obtain from using a
-      ticket.
-
-      The data in this field may be specific to the end service; the
-      field will contain the names of service specific objects, and the
-      rights to those objects. The format for this field is described in
-      section 5.2.6.  Although Kerberos is not concerned with the format
-      of the contents of the sub-fields, it does carry type information
-      (ad-type).
-
-      By using the authorization_data field, a principal is able to
-      issue a proxy that is valid for a specific purpose. For example, a
-      client wishing to print a file can obtain a file server proxy to
-
-
-
-June 2004                                                      [Page 72]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      be passed to the print server. By specifying the name of the file
-      in the authorization_data field, the file server knows that the
-      print server can only use the client's rights when accessing the
-      particular file to be printed.
-
-      A separate service providing authorization or certifying group
-      membership may be built using the authorization-data field. In
-      this case, the entity granting authorization (not the authorized
-      entity), may obtain a ticket in its own name (e.g. the ticket is
-      issued in the name of a privilege server), and this entity adds
-      restrictions on its own authority and delegates the restricted
-      authority through a proxy to the client. The client would then
-      present this authorization credential to the application server
-      separately from the authentication exchange.  Alternatively, such
-      authorization credentials MAY be embedded in the ticket
-      authenticating the authorized entity, when the authorization is
-      separately authenticated using the KDC-issued authorization data
-      element (see 5.2.6.2).
-
-      Similarly, if one specifies the authorization-data field of a
-      proxy and leaves the host addresses blank, the resulting ticket
-      and session key can be treated as a capability. See [Neu93] for
-      some suggested uses of this field.
-
-      The authorization-data field is optional and does not have to be
-      included in a ticket.
-
-5.4. Specifications for the AS and TGS exchanges
-
-   This section specifies the format of the messages used in the
-   exchange between the client and the Kerberos server. The format of
-   possible error messages appears in section 5.9.1.
-
-5.4.1. KRB_KDC_REQ definition
-
-   The KRB_KDC_REQ message has no application tag number of its own.
-   Instead, it is incorporated into one of KRB_AS_REQ or KRB_TGS_REQ,
-   which each have an application tag, depending on whether the request
-   is for an initial ticket or an additional ticket. In either case, the
-   message is sent from the client to the KDC to request credentials for
-   a service.
-
-   The message fields are:
-
-   AS-REQ          ::= [APPLICATION 10] KDC-REQ
-
-   TGS-REQ         ::= [APPLICATION 12] KDC-REQ
-
-
-
-
-June 2004                                                      [Page 73]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   KDC-REQ         ::= SEQUENCE {
-           -- NOTE: first tag is [1], not [0]
-           pvno            [1] INTEGER (5) ,
-           msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
-           padata          [3] SEQUENCE OF PA-DATA OPTIONAL
-                               -- NOTE: not empty --,
-           req-body        [4] KDC-REQ-BODY
-   }
-
-   KDC-REQ-BODY    ::= SEQUENCE {
-           kdc-options             [0] KDCOptions,
-           cname                   [1] PrincipalName OPTIONAL
-                                       -- Used only in AS-REQ --,
-           realm                   [2] Realm
-                                       -- Server's realm
-                                       -- Also client's in AS-REQ --,
-           sname                   [3] PrincipalName OPTIONAL,
-           from                    [4] KerberosTime OPTIONAL,
-           till                    [5] KerberosTime,
-           rtime                   [6] KerberosTime OPTIONAL,
-           nonce                   [7] UInt32,
-           etype                   [8] SEQUENCE OF Int32 -- EncryptionType
-                                       -- in preference order --,
-           addresses               [9] HostAddresses OPTIONAL,
-           enc-authorization-data  [10] EncryptedData OPTIONAL
-                                       -- AuthorizationData --,
-           additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
-                                           -- NOTE: not empty
-   }
-
-   KDCOptions      ::= KerberosFlags
-           -- reserved(0),
-           -- forwardable(1),
-           -- forwarded(2),
-           -- proxiable(3),
-           -- proxy(4),
-           -- allow-postdate(5),
-           -- postdated(6),
-           -- unused7(7),
-           -- renewable(8),
-           -- unused9(9),
-           -- unused10(10),
-           -- opt-hardware-auth(11),
-           -- unused12(12),
-           -- unused13(13),
-   -- 15 is reserved for canonicalize
-           -- unused15(15),
-   -- 26 was unused in 1510
-
-
-
-June 2004                                                      [Page 74]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-           -- disable-transited-check(26),
-   --
-           -- renewable-ok(27),
-           -- enc-tkt-in-skey(28),
-           -- renew(30),
-           -- validate(31)
-
-   The fields in this message are:
-
-   pvno
-      This field is included in each message, and specifies the protocol
-      version number. This document specifies protocol version 5.
-
-   msg-type
-      This field indicates the type of a protocol message. It will
-      almost always be the same as the application identifier associated
-      with a message. It is included to make the identifier more readily
-      accessible to the application. For the KDC-REQ message, this type
-      will be KRB_AS_REQ or KRB_TGS_REQ.
-
-   padata
-      Contains pre-authentication data. Requests for additional tickets
-      (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ.
-
-      The padata (pre-authentication data) field contains a sequence of
-      authentication information which may be needed before credentials
-      can be issued or decrypted.
-
-   req-body
-      This field is a placeholder delimiting the extent of the remaining
-      fields. If a checksum is to be calculated over the request, it is
-      calculated over an encoding of the KDC-REQ-BODY sequence which is
-      enclosed within the req-body field.
-
-   kdc-options
-      This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to
-      the KDC and indicates the flags that the client wants set on the
-      tickets as well as other information that is to modify the
-      behavior of the KDC.  Where appropriate, the name of an option may
-      be the same as the flag that is set by that option. Although in
-      most case, the bit in the options field will be the same as that
-      in the flags field, this is not guaranteed, so it is not
-      acceptable to simply copy the options field to the flags field.
-      There are various checks that must be made before honoring an
-      option anyway.
-
-      The kdc_options field is a bit-field, where the selected options
-      are indicated by the bit being set (1), and the unselected options
-
-
-
-June 2004                                                      [Page 75]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      and reserved fields being reset (0). The encoding of the bits is
-      specified in section 5.2. The options are described in more detail
-      above in section 2. The meanings of the options are:
-
-         Bits    Name                     Description
-
-         0       RESERVED                 Reserved for future expansion of
-                                          this field.
-
-                                          The FORWARDABLE option indicates
-                                          that the ticket to be issued is to
-                                          have its forwardable flag set. It
-         1       FORWARDABLE              may only be set on the initial
-                                          request, or in a subsequent request
-                                          if the ticket-granting ticket on
-                                          which it is based is also
-                                          forwardable.
-
-                                          The FORWARDED option is only
-                                          specified in a request to the
-                                          ticket-granting server and will only
-                                          be honored if the ticket-granting
-                                          ticket in the request has its
-         2       FORWARDED                FORWARDABLE bit set. This option
-                                          indicates that this is a request for
-                                          forwarding. The address(es) of the
-                                          host from which the resulting ticket
-                                          is to be valid are included in the
-                                          addresses field of the request.
-
-                                          The PROXIABLE option indicates that
-                                          the ticket to be issued is to have
-                                          its proxiable flag set. It may only
-         3       PROXIABLE                be set on the initial request, or in
-                                          a subsequent request if the
-                                          ticket-granting ticket on which it
-                                          is based is also proxiable.
-
-                                          The PROXY option indicates that this
-                                          is a request for a proxy. This
-                                          option will only be honored if the
-                                          ticket-granting ticket in the
-         4       PROXY                    request has its PROXIABLE bit set.
-                                          The address(es) of the host from
-                                          which the resulting ticket is to be
-                                          valid are included in the addresses
-                                          field of the request.
-
-
-
-
-June 2004                                                      [Page 76]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-                                          The ALLOW-POSTDATE option indicates
-                                          that the ticket to be issued is to
-                                          have its MAY-POSTDATE flag set. It
-         5       ALLOW-POSTDATE           may only be set on the initial
-                                          request, or in a subsequent request
-                                          if the ticket-granting ticket on
-                                          which it is based also has its
-                                          MAY-POSTDATE flag set.
-
-                                          The POSTDATED option indicates that
-                                          this is a request for a postdated
-                                          ticket. This option will only be
-                                          honored if the ticket-granting
-                                          ticket on which it is based has its
-         6       POSTDATED                MAY-POSTDATE flag set. The resulting
-                                          ticket will also have its INVALID
-                                          flag set, and that flag may be reset
-                                          by a subsequent request to the KDC
-                                          after the starttime in the ticket
-                                          has been reached.
-
-         7       RESERVED                 This option is presently unused.
-
-                                          The RENEWABLE option indicates that
-                                          the ticket to be issued is to have
-                                          its RENEWABLE flag set. It may only
-                                          be set on the initial request, or
-                                          when the ticket-granting ticket on
-         8       RENEWABLE                which the request is based is also
-                                          renewable. If this option is
-                                          requested, then the rtime field in
-                                          the request contains the desired
-                                          absolute expiration time for the
-                                          ticket.
-
-         9       RESERVED                 Reserved for PK-Cross
-
-         10      RESERVED                 Reserved for future use.
-
-         11      RESERVED                 Reserved for opt-hardware-auth.
-
-         12-25   RESERVED                 Reserved for future use.
-
-                                          By default the KDC will check the
-                                          transited field of a
-                                          ticket-granting-ticket against the
-                                          policy of the local realm before it
-                                          will issue derivative tickets based
-
-
-
-June 2004                                                      [Page 77]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-                                          on the ticket-granting ticket. If
-                                          this flag is set in the request,
-                                          checking of the transited field is
-                                          disabled. Tickets issued without the
-         26      DISABLE-TRANSITED-CHECK  performance of this check will be
-                                          noted by the reset (0) value of the
-                                          TRANSITED-POLICY-CHECKED flag,
-                                          indicating to the application server
-                                          that the tranisted field must be
-                                          checked locally. KDCs are
-                                          encouraged but not required to honor
-                                          the DISABLE-TRANSITED-CHECK option.
-
-                                          This flag is new since RFC 1510
-
-                                          The RENEWABLE-OK option indicates
-                                          that a renewable ticket will be
-                                          acceptable if a ticket with the
-                                          requested life cannot otherwise be
-                                          provided. If a ticket with the
-                                          requested life cannot be provided,
-         27      RENEWABLE-OK             then a renewable ticket may be
-                                          issued with a renew-till equal to
-                                          the requested endtime. The value
-                                          of the renew-till field may still be
-                                          limited by local limits, or limits
-                                          selected by the individual principal
-                                          or server.
-
-                                          This option is used only by the
-                                          ticket-granting service. The
-                                          ENC-TKT-IN-SKEY option indicates
-         28      ENC-TKT-IN-SKEY          that the ticket for the end server
-                                          is to be encrypted in the session
-                                          key from the additional
-                                          ticket-granting ticket provided.
-
-         29      RESERVED                 Reserved for future use.
-
-                                          This option is used only by the
-                                          ticket-granting service. The RENEW
-                                          option indicates that the present
-                                          request is for a renewal. The ticket
-                                          provided is encrypted in the secret
-                                          key for the server on which it is
-         30      RENEW                    valid. This option will only be
-                                          honored if the ticket to be renewed
-                                          has its RENEWABLE flag set and if
-
-
-
-June 2004                                                      [Page 78]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-                                          the time in its renew-till field has
-                                          not passed. The ticket to be renewed
-                                          is passed in the padata field as
-                                          part of the authentication header.
-
-                                          This option is used only by the
-                                          ticket-granting service. The
-                                          VALIDATE option indicates that the
-                                          request is to validate a postdated
-                                          ticket. It will only be honored if
-                                          the ticket presented is postdated,
-                                          presently has its INVALID flag set,
-         31      VALIDATE                 and would be otherwise usable at
-                                          this time. A ticket cannot be
-                                          validated before its starttime. The
-                                          ticket presented for validation is
-                                          encrypted in the key of the server
-                                          for which it is valid and is passed
-                                          in the padata field as part of the
-                                          authentication header.
-   cname and sname
-      These fields are the same as those described for the ticket in
-      section 5.3. The sname may only be absent when the ENC-TKT-IN-SKEY
-      option is specified. If absent, the name of the server is taken
-      from the name of the client in the ticket passed as additional-
-      tickets.
-
-   enc-authorization-data
-      The enc-authorization-data, if present (and it can only be present
-      in the TGS_REQ form), is an encoding of the desired authorization-
-      data encrypted under the sub-session key if present in the
-      Authenticator, or alternatively from the session key in the
-      ticket-granting ticket (both the Authenticator and ticket-granting
-      ticket come from the padata field in the KRB_TGS_REQ). The key
-      usage value used when encrypting is 5 if a sub-session key is
-      used, or 4 if the session key is used.
-
-   realm
-      This field specifies the realm part of the server's principal
-      identifier. In the AS exchange, this is also the realm part of the
-      client's principal identifier.
-
-   from
-      This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
-      requests when the requested ticket is to be postdated. It
-      specifies the desired start time for the requested ticket. If this
-      field is omitted then the KDC SHOULD use the current time instead.
-
-
-
-
-June 2004                                                      [Page 79]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   till
-      This field contains the expiration date requested by the client in
-      a ticket request. It is not optional, but if the requested endtime
-      is "19700101000000Z", the requested ticket is to have the maximum
-      endtime permitted according to KDC policy. Implementation note:
-      This special timestamp corresponds to a UNIX time_t value of zero
-      on most systems.
-
-   rtime
-      This field is the requested renew-till time sent from a client to
-      the KDC in a ticket request. It is optional.
-
-   nonce
-      This field is part of the KDC request and response. It is intended
-      to hold a random number generated by the client. If the same
-      number is included in the encrypted response from the KDC, it
-      provides evidence that the response is fresh and has not been
-      replayed by an attacker.  Nonces MUST NEVER be reused.
-
-   etype
-      This field specifies the desired encryption algorithm to be used
-      in the response.
-
-   addresses
-      This field is included in the initial request for tickets, and
-      optionally included in requests for additional tickets from the
-      ticket-granting server. It specifies the addresses from which the
-      requested ticket is to be valid. Normally it includes the
-      addresses for the client's host. If a proxy is requested, this
-      field will contain other addresses. The contents of this field are
-      usually copied by the KDC into the caddr field of the resulting
-      ticket.
-
-   additional-tickets
-      Additional tickets MAY be optionally included in a request to the
-      ticket-granting server. If the ENC-TKT-IN-SKEY option has been
-      specified, then the session key from the additional ticket will be
-      used in place of the server's key to encrypt the new ticket. When
-      the ENC-TKT-IN-SKEY option is used for user-to-user
-      authentication, this additional ticket MAY be a TGT issued by the
-      local realm or an inter-realm TGT issued for the current KDC's
-      realm by a remote KDC. If more than one option which requires
-      additional tickets has been specified, then the additional tickets
-      are used in the order specified by the ordering of the options
-      bits (see kdc-options, above).
-
-   The application tag number will be either ten (10) or twelve (12)
-   depending on whether the request is for an initial ticket (AS-REQ) or
-
-
-
-June 2004                                                      [Page 80]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   for an additional ticket (TGS-REQ).
-
-   The optional fields (addresses, authorization-data and additional-
-   tickets) are only included if necessary to perform the operation
-   specified in the kdc-options field.
-
-   It should be noted that in KRB_TGS_REQ, the protocol version number
-   appears twice and two different message types appear: the KRB_TGS_REQ
-   message contains these fields as does the authentication header
-   (KRB_AP_REQ) that is passed in the padata field.
-
-5.4.2. KRB_KDC_REP definition
-
-   The KRB_KDC_REP message format is used for the reply from the KDC for
-   either an initial (AS) request or a subsequent (TGS) request. There
-   is no message type for KRB_KDC_REP. Instead, the type will be either
-   KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext
-   part of the reply depends on the message type. For KRB_AS_REP, the
-   ciphertext is encrypted in the client's secret key, and the client's
-   key version number is included in the key version number for the
-   encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the
-   sub-session key from the Authenticator, or if absent, the session key
-   from the ticket-granting ticket used in the request.  In that case,
-   no version number will be present in the EncryptedData sequence.
-
-   The KRB_KDC_REP message contains the following fields:
-
-   AS-REP          ::= [APPLICATION 11] KDC-REP
-
-   TGS-REP         ::= [APPLICATION 13] KDC-REP
-
-   KDC-REP         ::= SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
-           padata          [2] SEQUENCE OF PA-DATA OPTIONAL
-                                   -- NOTE: not empty --,
-           crealm          [3] Realm,
-           cname           [4] PrincipalName,
-           ticket          [5] Ticket,
-           enc-part        [6] EncryptedData
-                                   -- EncASRepPart or EncTGSRepPart,
-                                   -- as appropriate
-   }
-
-   EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
-
-   EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
-
-
-
-
-June 2004                                                      [Page 81]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   EncKDCRepPart   ::= SEQUENCE {
-           key             [0] EncryptionKey,
-           last-req        [1] LastReq,
-           nonce           [2] UInt32,
-           key-expiration  [3] KerberosTime OPTIONAL,
-           flags           [4] TicketFlags,
-           authtime        [5] KerberosTime,
-           starttime       [6] KerberosTime OPTIONAL,
-           endtime         [7] KerberosTime,
-           renew-till      [8] KerberosTime OPTIONAL,
-           srealm          [9] Realm,
-           sname           [10] PrincipalName,
-           caddr           [11] HostAddresses OPTIONAL
-   }
-
-   LastReq         ::=     SEQUENCE OF SEQUENCE {
-           lr-type         [0] Int32,
-           lr-value        [1] KerberosTime
-   }
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      either KRB_AS_REP or KRB_TGS_REP.
-
-   padata
-      This field is described in detail in section 5.4.1. One possible
-      use for this field is to encode an alternate "salt" string to be
-      used with a string-to-key algorithm. This ability is useful to
-      ease transitions if a realm name needs to change (e.g. when a
-      company is acquired); in such a case all existing password-derived
-      entries in the KDC database would be flagged as needing a special
-      salt string until the next password change.
-
-   crealm, cname, srealm and sname
-      These fields are the same as those described for the ticket in
-      section 5.3.
-
-   ticket
-      The newly-issued ticket, from section 5.3.
-
-   enc-part
-      This field is a place holder for the ciphertext and related
-      information that forms the encrypted part of a message. The
-      description of the encrypted part of the message follows each
-      appearance of this field.
-
-      The key usage value for encrypting this field is 3 in an AS-REP
-      message, using the client's long-term key or another key selected
-
-
-
-June 2004                                                      [Page 82]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      via pre-authentication mechanisms. In a TGS-REP message, the key
-      usage value is 8 if the TGS session key is used, or 9 if a TGS
-      authenticator subkey is used.
-
-      Compatibility note: Some implementations unconditionally send an
-      encrypted EncTGSRepPart (application tag number 26) in this field
-      regardless of whether the reply is a AS-REP or a TGS-REP. In the
-      interests of compatibility, implementors MAY relax the check on
-      the tag number of the decrypted ENC-PART.
-
-   key
-      This field is the same as described for the ticket in section 5.3.
-
-   last-req
-      This field is returned by the KDC and specifies the time(s) of the
-      last request by a principal. Depending on what information is
-      available, this might be the last time that a request for a
-      ticket-granting ticket was made, or the last time that a request
-      based on a ticket-granting ticket was successful. It also might
-      cover all servers for a realm, or just the particular server. Some
-      implementations MAY display this information to the user to aid in
-      discovering unauthorized use of one's identity. It is similar in
-      spirit to the last login time displayed when logging into
-      timesharing systems.
-
-      lr-type
-         This field indicates how the following lr-value field is to be
-         interpreted. Negative values indicate that the information
-         pertains only to the responding server. Non-negative values
-         pertain to all servers for the realm.
-
-         If the lr-type field is zero (0), then no information is
-         conveyed by the lr-value subfield. If the absolute value of the
-         lr-type field is one (1), then the lr-value subfield is the
-         time of last initial request for a TGT. If it is two (2), then
-         the lr-value subfield is the time of last initial request. If
-         it is three (3), then the lr-value subfield is the time of
-         issue for the newest ticket-granting ticket used. If it is four
-         (4), then the lr-value subfield is the time of the last
-         renewal. If it is five (5), then the lr-value subfield is the
-         time of last request (of any type).  If it is (6), then the lr-
-         value subfield is the time when the password will expire.  If
-         it is (7), then the lr-value subfield is the time when the
-         account will expire.
-
-      lr-value
-         This field contains the time of the last request. The time MUST
-         be interpreted according to the contents of the accompanying
-
-
-
-June 2004                                                      [Page 83]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-         lr-type subfield.
-
-   nonce
-      This field is described above in section 5.4.1.
-
-   key-expiration
-      The key-expiration field is part of the response from the KDC and
-      specifies the time that the client's secret key is due to expire.
-      The expiration might be the result of password aging or an account
-      expiration. If present, it SHOULD be set to the earliest of the
-      user's key expiration and account expiration.  The use of this
-      field is deprecated and the last-req field SHOULD be used to
-      convey this information instead.  This field will usually be left
-      out of the TGS reply since the response to the TGS request is
-      encrypted in a session key and no client information need be
-      retrieved from the KDC database. It is up to the application
-      client (usually the login program) to take appropriate action
-      (such as notifying the user) if the expiration time is imminent.
-
-   flags, authtime, starttime, endtime, renew-till and caddr
-      These fields are duplicates of those found in the encrypted
-      portion of the attached ticket (see section 5.3), provided so the
-      client MAY verify they match the intended request and to assist in
-      proper ticket caching. If the message is of type KRB_TGS_REP, the
-      caddr field will only be filled in if the request was for a proxy
-      or forwarded ticket, or if the user is substituting a subset of
-      the addresses from the ticket-granting ticket. If the client-
-      requested addresses are not present or not used, then the
-      addresses contained in the ticket will be the same as those
-      included in the ticket-granting ticket.
-
-5.5. Client/Server (CS) message specifications
-
-   This section specifies the format of the messages used for the
-   authentication of the client to the application server.
-
-5.5.1. KRB_AP_REQ definition
-
-   The KRB_AP_REQ message contains the Kerberos protocol version number,
-   the message type KRB_AP_REQ, an options field to indicate any options
-   in use, and the ticket and authenticator themselves. The KRB_AP_REQ
-   message is often referred to as the 'authentication header'.
-
-   AP-REQ          ::= [APPLICATION 14] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (14),
-           ap-options      [2] APOptions,
-           ticket          [3] Ticket,
-
-
-
-June 2004                                                      [Page 84]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-           authenticator   [4] EncryptedData -- Authenticator
-   }
-
-   APOptions       ::= KerberosFlags
-           -- reserved(0),
-           -- use-session-key(1),
-           -- mutual-required(2)
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_AP_REQ.
-
-   ap-options
-      This field appears in the application request (KRB_AP_REQ) and
-      affects the way the request is processed. It is a bit-field, where
-      the selected options are indicated by the bit being set (1), and
-      the unselected options and reserved fields being reset (0). The
-      encoding of the bits is specified in section 5.2. The meanings of
-      the options are:
-
-         Bit(s)  Name            Description
-
-         0       reserved        Reserved for future expansion of this field.
-
-                                 The USE-SESSION-KEY option indicates that the
-                                 ticket the client is presenting to a server
-         1       use-session-key is encrypted in the session key from the
-                                 server's ticket-granting ticket. When this
-                                 option is not specified, the ticket is
-                                 encrypted in the server's secret key.
-
-                                 The MUTUAL-REQUIRED option tells the server
-         2       mutual-required that the client requires mutual
-                                 authentication, and that it must respond with
-                                 a KRB_AP_REP message.
-
-         3-31    reserved        Reserved for future use.
-
-   ticket
-      This field is a ticket authenticating the client to the server.
-
-   authenticator
-      This contains the encrypted authenticator, which includes the
-      client's choice of a subkey.
-
-   The encrypted authenticator is included in the AP-REQ; it certifies
-   to a server that the sender has recent knowledge of the encryption
-   key in the accompanying ticket, to help the server detect replays. It
-
-
-
-June 2004                                                      [Page 85]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   also assists in the selection of a "true session key" to use with the
-   particular session.  The DER encoding of the following is encrypted
-   in the ticket's session key, with a key usage value of 11 in normal
-   application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field
-   of a TGS-REQ exchange (see section 5.4.1):
-
-   -- Unencrypted authenticator
-   Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-           authenticator-vno       [0] INTEGER (5),
-           crealm                  [1] Realm,
-           cname                   [2] PrincipalName,
-           cksum                   [3] Checksum OPTIONAL,
-           cusec                   [4] Microseconds,
-           ctime                   [5] KerberosTime,
-           subkey                  [6] EncryptionKey OPTIONAL,
-           seq-number              [7] UInt32 OPTIONAL,
-           authorization-data      [8] AuthorizationData OPTIONAL
-   }
-
-   authenticator-vno
-      This field specifies the version number for the format of the
-      authenticator. This document specifies version 5.
-
-   crealm and cname
-      These fields are the same as those described for the ticket in
-      section 5.3.
-
-   cksum
-      This field contains a checksum of the application data that
-      accompanies the KRB_AP_REQ, computed using a key usage value of 10
-      in normal application exchanges, or 6 when used in the TGS-REQ PA-
-      TGS-REQ AP-DATA field.
-
-   cusec
-      This field contains the microsecond part of the client's
-      timestamp. Its value (before encryption) ranges from 0 to 999999.
-      It often appears along with ctime. The two fields are used
-      together to specify a reasonably accurate timestamp.
-
-   ctime
-      This field contains the current time on the client's host.
-
-   subkey
-      This field contains the client's choice for an encryption key
-      which is to be used to protect this specific application session.
-      Unless an application specifies otherwise, if this field is left
-      out the session key from the ticket will be used.
-
-
-
-
-June 2004                                                      [Page 86]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   seq-number
-      This optional field includes the initial sequence number to be
-      used by the KRB_PRIV or KRB_SAFE messages when sequence numbers
-      are used to detect replays (It may also be used by application
-      specific messages).  When included in the authenticator this field
-      specifies the initial sequence number for messages from the client
-      to the server. When included in the AP-REP message, the initial
-      sequence number is that for messages from the server to the
-      client. When used in KRB_PRIV or KRB_SAFE messages, it is
-      incremented by one after each message is sent.  Sequence numbers
-      fall in the range of 0 through 2^32 - 1 and wrap to zero following
-      the value 2^32 - 1.
-
-      For sequence numbers to adequately support the detection of
-      replays they SHOULD be non-repeating, even across connection
-      boundaries. The initial sequence number SHOULD be random and
-      uniformly distributed across the full space of possible sequence
-      numbers, so that it cannot be guessed by an attacker and so that
-      it and the successive sequence numbers do not repeat other
-      sequences.  In the event that more than 2^32 messages are to be
-      generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying
-      SHOULD be performed before sequence numbers are reused with the
-      same encryption key.
-
-      Implmentation note: historically, some implementations transmit
-      signed twos-complement numbers for sequence numbers. In the
-      interests of compatibility, implementations MAY accept the
-      equivalent negative number where a positive number greater than
-      2^31 - 1 is expected.
-
-      Implementation note: as noted before, some implementations omit
-      the optional sequence number when its value would be zero.
-      Implementations MAY accept an omitted sequence number when
-      expecting a value of zero, and SHOULD NOT transmit an
-      Authenticator with a initial sequence number of zero.
-
-   authorization-data
-      This field is the same as described for the ticket in section 5.3.
-      It is optional and will only appear when additional restrictions
-      are to be placed on the use of a ticket, beyond those carried in
-      the ticket itself.
-
-5.5.2. KRB_AP_REP definition
-
-   The KRB_AP_REP message contains the Kerberos protocol version number,
-   the message type, and an encrypted time-stamp. The message is sent in
-   response to an application request (KRB_AP_REQ) where the mutual
-   authentication option has been selected in the ap-options field.
-
-
-
-June 2004                                                      [Page 87]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   AP-REP          ::= [APPLICATION 15] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (15),
-           enc-part        [2] EncryptedData -- EncAPRepPart
-   }
-
-   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
-           ctime           [0] KerberosTime,
-           cusec           [1] Microseconds,
-           subkey          [2] EncryptionKey OPTIONAL,
-           seq-number      [3] UInt32 OPTIONAL
-   }
-
-   The encoded EncAPRepPart is encrypted in the shared session key of
-   the ticket. The optional subkey field can be used in an application-
-   arranged negotiation to choose a per association session key.
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_AP_REP.
-
-   enc-part
-      This field is described above in section 5.4.2. It is computed
-      with a key usage value of 12.
-
-   ctime
-      This field contains the current time on the client's host.
-
-   cusec
-      This field contains the microsecond part of the client's
-      timestamp.
-
-   subkey
-      This field contains an encryption key which is to be used to
-      protect this specific application session. See section 3.2.6 for
-      specifics on how this field is used to negotiate a key. Unless an
-      application specifies otherwise, if this field is left out, the
-      sub-session key from the authenticator, or if also left out, the
-      session key from the ticket will be used.
-
-   seq-number
-      This field is described above in section 5.3.2.
-
-5.5.3. Error message reply
-
-   If an error occurs while processing the application request, the
-   KRB_ERROR message will be sent in response. See section 5.9.1 for the
-   format of the error message. The cname and crealm fields MAY be left
-
-
-
-June 2004                                                      [Page 88]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   out if the server cannot determine their appropriate values from the
-   corresponding KRB_AP_REQ message. If the authenticator was
-   decipherable, the ctime and cusec fields will contain the values from
-   it.
-
-5.6. KRB_SAFE message specification
-
-   This section specifies the format of a message that can be used by
-   either side (client or server) of an application to send a tamper-
-   proof message to its peer. It presumes that a session key has
-   previously been exchanged (for example, by using the
-   KRB_AP_REQ/KRB_AP_REP messages).
-
-5.6.1. KRB_SAFE definition
-
-   The KRB_SAFE message contains user data along with a collision-proof
-   checksum keyed with the last encryption key negotiated via subkeys,
-   or the session key if no negotiation has occurred. The message fields
-   are:
-
-   KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (20),
-           safe-body       [2] KRB-SAFE-BODY,
-           cksum           [3] Checksum
-   }
-
-   KRB-SAFE-BODY   ::= SEQUENCE {
-           user-data       [0] OCTET STRING,
-           timestamp       [1] KerberosTime OPTIONAL,
-           usec            [2] Microseconds OPTIONAL,
-           seq-number      [3] UInt32 OPTIONAL,
-           s-address       [4] HostAddress,
-           r-address       [5] HostAddress OPTIONAL
-   }
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_SAFE.
-
-   safe-body
-      This field is a placeholder for the body of the KRB-SAFE message.
-
-   cksum
-      This field contains the checksum of the application data, computed
-      with a key usage value of 15.
-
-      The checksum is computed over the encoding of the KRB-SAFE
-
-
-
-June 2004                                                      [Page 89]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      sequence.  First, the cksum is set to a type zero, zero-length
-      value and the checksum is computed over the encoding of the KRB-
-      SAFE sequence, then the checksum is set to the result of that
-      computation, and finally the KRB-SAFE sequence is encoded again.
-      This method, while different than the one specified in RFC 1510,
-      corresponds to existing practice.
-
-   user-data
-      This field is part of the KRB_SAFE and KRB_PRIV messages and
-      contain the application specific data that is being passed from
-      the sender to the recipient.
-
-   timestamp
-      This field is part of the KRB_SAFE and KRB_PRIV messages. Its
-      contents are the current time as known by the sender of the
-      message. By checking the timestamp, the recipient of the message
-      is able to make sure that it was recently generated, and is not a
-      replay.
-
-   usec
-      This field is part of the KRB_SAFE and KRB_PRIV headers. It
-      contains the microsecond part of the timestamp.
-
-   seq-number
-      This field is described above in section 5.3.2.
-
-   s-address
-      Sender's address.
-
-      This field specifies the address in use by the sender of the
-      message.
-
-   r-address
-      This field specifies the address in use by the recipient of the
-      message. It MAY be omitted for some uses (such as broadcast
-      protocols), but the recipient MAY arbitrarily reject such
-      messages. This field, along with s-address, can be used to help
-      detect messages which have been incorrectly or maliciously
-      delivered to the wrong recipient.
-
-5.7. KRB_PRIV message specification
-
-   This section specifies the format of a message that can be used by
-   either side (client or server) of an application to securely and
-   privately send a message to its peer. It presumes that a session key
-   has previously been exchanged (for example, by using the
-   KRB_AP_REQ/KRB_AP_REP messages).
-
-
-
-
-June 2004                                                      [Page 90]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-5.7.1. KRB_PRIV definition
-
-   The KRB_PRIV message contains user data encrypted in the Session Key.
-   The message fields are:
-
-   KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (21),
-                           -- NOTE: there is no [2] tag
-           enc-part        [3] EncryptedData -- EncKrbPrivPart
-   }
-
-   EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-           user-data       [0] OCTET STRING,
-           timestamp       [1] KerberosTime OPTIONAL,
-           usec            [2] Microseconds OPTIONAL,
-           seq-number      [3] UInt32 OPTIONAL,
-           s-address       [4] HostAddress -- sender's addr --,
-           r-address       [5] HostAddress OPTIONAL -- recip's addr
-   }
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_PRIV.
-
-   enc-part
-      This field holds an encoding of the EncKrbPrivPart sequence
-      encrypted under the session key, with a key usage value of 13.
-      This encrypted encoding is used for the enc-part field of the KRB-
-      PRIV message.
-
-   user-data, timestamp, usec, s-address and r-address
-      These fields are described above in section 5.6.1.
-
-   seq-number
-      This field is described above in section 5.3.2.
-
-5.8. KRB_CRED message specification
-
-   This section specifies the format of a message that can be used to
-   send Kerberos credentials from one principal to another. It is
-   presented here to encourage a common mechanism to be used by
-   applications when forwarding tickets or providing proxies to
-   subordinate servers. It presumes that a session key has already been
-   exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages.
-
-5.8.1. KRB_CRED definition
-
-
-
-
-June 2004                                                      [Page 91]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   The KRB_CRED message contains a sequence of tickets to be sent and
-   information needed to use the tickets, including the session key from
-   each.  The information needed to use the tickets is encrypted under
-   an encryption key previously exchanged or transferred alongside the
-   KRB_CRED message. The message fields are:
-
-   KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (22),
-           tickets         [2] SEQUENCE OF Ticket,
-           enc-part        [3] EncryptedData -- EncKrbCredPart
-   }
-
-   EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-           ticket-info     [0] SEQUENCE OF KrbCredInfo,
-           nonce           [1] UInt32 OPTIONAL,
-           timestamp       [2] KerberosTime OPTIONAL,
-           usec            [3] Microseconds OPTIONAL,
-           s-address       [4] HostAddress OPTIONAL,
-           r-address       [5] HostAddress OPTIONAL
-   }
-
-   KrbCredInfo     ::= SEQUENCE {
-           key             [0] EncryptionKey,
-           prealm          [1] Realm OPTIONAL,
-           pname           [2] PrincipalName OPTIONAL,
-           flags           [3] TicketFlags OPTIONAL,
-           authtime        [4] KerberosTime OPTIONAL,
-           starttime       [5] KerberosTime OPTIONAL,
-           endtime         [6] KerberosTime OPTIONAL,
-           renew-till      [7] KerberosTime OPTIONAL,
-           srealm          [8] Realm OPTIONAL,
-           sname           [9] PrincipalName OPTIONAL,
-           caddr           [10] HostAddresses OPTIONAL
-   }
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_CRED.
-
-   tickets
-      These are the tickets obtained from the KDC specifically for use
-      by the intended recipient. Successive tickets are paired with the
-      corresponding KrbCredInfo sequence from the enc-part of the KRB-
-      CRED message.
-
-   enc-part
-      This field holds an encoding of the EncKrbCredPart sequence
-
-
-
-June 2004                                                      [Page 92]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      encrypted under the session key shared between the sender and the
-      intended recipient, with a key usage value of 14. This encrypted
-      encoding is used for the enc-part field of the KRB-CRED message.
-
-      Implementation note: implementations of certain applications, most
-      notably certain implementations of the Kerberos GSS-API mechanism,
-      do not separately encrypt the contents of the EncKrbCredPart of
-      the KRB-CRED message when sending it.  In the case of those GSS-
-      API mechanisms, this is not a security vulnerability, as the
-      entire KRB-CRED message is itself embedded in an encrypted
-      message.
-
-   nonce
-      If practical, an application MAY require the inclusion of a nonce
-      generated by the recipient of the message. If the same value is
-      included as the nonce in the message, it provides evidence that
-      the message is fresh and has not been replayed by an attacker. A
-      nonce MUST NEVER be reused.
-
-   timestamp and usec
-      These fields specify the time that the KRB-CRED message was
-      generated.  The time is used to provide assurance that the message
-      is fresh.
-
-   s-address and r-address
-      These fields are described above in section 5.6.1. They are used
-      optionally to provide additional assurance of the integrity of the
-      KRB-CRED message.
-
-   key
-      This field exists in the corresponding ticket passed by the KRB-
-      CRED message and is used to pass the session key from the sender
-      to the intended recipient. The field's encoding is described in
-      section 5.2.9.
-
-   The following fields are optional. If present, they can be associated
-   with the credentials in the remote ticket file. If left out, then it
-   is assumed that the recipient of the credentials already knows their
-   value.
-
-   prealm and pname
-      The name and realm of the delegated principal identity.
-
-   flags, authtime, starttime, endtime, renew-till, srealm, sname, and
-      caddr
-      These fields contain the values of the corresponding fields from
-      the ticket found in the ticket field. Descriptions of the fields
-      are identical to the descriptions in the KDC-REP message.
-
-
-
-June 2004                                                      [Page 93]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-5.9. Error message specification
-
-   This section specifies the format for the KRB_ERROR message. The
-   fields included in the message are intended to return as much
-   information as possible about an error. It is not expected that all
-   the information required by the fields will be available for all
-   types of errors. If the appropriate information is not available when
-   the message is composed, the corresponding field will be left out of
-   the message.
-
-   Note that since the KRB_ERROR message is not integrity protected, it
-   is quite possible for an intruder to synthesize or modify such a
-   message. In particular, this means that the client SHOULD NOT use any
-   fields in this message for security-critical purposes, such as
-   setting a system clock or generating a fresh authenticator. The
-   message can be useful, however, for advising a user on the reason for
-   some failure.
-
-5.9.1. KRB_ERROR definition
-
-   The KRB_ERROR message consists of the following fields:
-
-   KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (30),
-           ctime           [2] KerberosTime OPTIONAL,
-           cusec           [3] Microseconds OPTIONAL,
-           stime           [4] KerberosTime,
-           susec           [5] Microseconds,
-           error-code      [6] Int32,
-           crealm          [7] Realm OPTIONAL,
-           cname           [8] PrincipalName OPTIONAL,
-           realm           [9] Realm -- service realm --,
-           sname           [10] PrincipalName -- service name --,
-           e-text          [11] KerberosString OPTIONAL,
-           e-data          [12] OCTET STRING OPTIONAL
-   }
-
-   pvno and msg-type
-      These fields are described above in section 5.4.1. msg-type is
-      KRB_ERROR.
-
-   ctime, cusec
-      These fields are described above in section 5.5.2.  If the values
-      for these fields are known to the entity generating the error
-      (such as it would if the KRB-ERROR is generated in reply to, e.g.,
-      a failed authentication service request), they should be populated
-      in the KRB-ERROR.  If the values are not available, these fields
-
-
-
-June 2004                                                      [Page 94]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      can be omitted.
-
-   stime
-      This field contains the current time on the server. It is of type
-      KerberosTime.
-
-   susec
-      This field contains the microsecond part of the server's
-      timestamp. Its value ranges from 0 to 999999. It appears along
-      with stime. The two fields are used in conjunction to specify a
-      reasonably accurate timestamp.
-
-   error-code
-      This field contains the error code returned by Kerberos or the
-      server when a request fails. To interpret the value of this field
-      see the list of error codes in section 7.5.9. Implementations are
-      encouraged to provide for national language support in the display
-      of error messages.
-
-   crealm, and cname
-      These fields are described above in section 5.3.  When the entity
-      generating the error knows these values, they should be populated
-      in the KRB-ERROR.  If the values are not known, the crealm and
-      cname fields SHOULD be omitted.
-
-   realm and sname
-      These fields are described above in section 5.3.
-
-   e-text
-      This field contains additional text to help explain the error code
-      associated with the failed request (for example, it might include
-      a principal name which was unknown).
-
-   e-data
-      This field contains additional data about the error for use by the
-      application to help it recover from or handle the error. If the
-      errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
-      contain an encoding of a sequence of padata fields, each
-      corresponding to an acceptable pre-authentication method and
-      optionally containing data for the method:
-
-      METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-   For error codes defined in this document other than
-   KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field
-   are implementation-defined. Similarly, for future error codes, the
-   format and contents of the e-data field are implementation-defined
-   unless specified. Whether defined by the implementation or in a
-
-
-
-June 2004                                                      [Page 95]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   future document, the e-data field MAY take the form of TYPED-DATA:
-
-   TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-           data-type       [0] INTEGER,
-           data-value      [1] OCTET STRING OPTIONAL
-   }
-
-5.10. Application Tag Numbers
-
-   The following table lists the application class tag numbers used by
-   various data types defined in this section.
-
-    Tag Number(s)    Type Name    Comments
-
-    0                             unused
-
-    1              Ticket         PDU
-
-    2              Authenticator  non-PDU
-
-    3              EncTicketPart  non-PDU
-
-    4-9                           unused
-
-    10             AS-REQ         PDU
-
-    11             AS-REP         PDU
-
-    12             TGS-REQ        PDU
-
-    13             TGS-REP        PDU
-
-    14             AP-REQ         PDU
-
-    15             AP-REP         PDU
-
-    16             RESERVED16     TGT-REQ (for user-to-user)
-
-    17             RESERVED17     TGT-REP (for user-to-user)
-
-    18-19                         unused
-
-    20             KRB-SAFE       PDU
-
-    21             KRB-PRIV       PDU
-
-    22             KRB-CRED       PDU
-
-
-
-
-June 2004                                                      [Page 96]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-    23-24                         unused
-
-    25             EncASRepPart   non-PDU
-
-    26             EncTGSRepPart  non-PDU
-
-    27             EncApRepPart   non-PDU
-
-    28             EncKrbPrivPart non-PDU
-
-    29             EncKrbCredPart non-PDU
-
-    30             KRB-ERROR      PDU
-
-   The ASN.1 types marked as "PDU" (Protocol Data Unit) in the above are
-   the only ASN.1 types intended as top-level types of the Kerberos
-   protocol, and are the only types that may be used as elements in
-   another protocol that makes use of Kerberos.
-
-6. Naming Constraints
-
-6.1. Realm Names
-
-   Although realm names are encoded as GeneralStrings and although a
-   realm can technically select any name it chooses, interoperability
-   across realm boundaries requires agreement on how realm names are to
-   be assigned, and what information they imply.
-
-   To enforce these conventions, each realm MUST conform to the
-   conventions itself, and it MUST require that any realms with which
-   inter-realm keys are shared also conform to the conventions and
-   require the same from its neighbors.
-
-   Kerberos realm names are case sensitive. Realm names that differ only
-   in the case of the characters are not equivalent. There are presently
-   three styles of realm names: domain, X500, and other. Examples of
-   each style follow:
-
-        domain:   ATHENA.MIT.EDU
-          X500:   C=US/O=OSF
-         other:   NAMETYPE:rest/of.name=without-restrictions
-
-   Domain style realm names MUST look like domain names: they consist of
-   components separated by periods (.) and they contain neither colons
-   (:) nor slashes (/). Though domain names themselves are case
-   insensitive, in order for realms to match, the case must match as
-   well. When establishing a new realm name based on an internet domain
-   name it is recommended by convention that the characters be converted
-
-
-
-June 2004                                                      [Page 97]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   to upper case.
-
-   X.500 names contain an equal (=) and cannot contain a colon (:)
-   before the equal. The realm names for X.500 names will be string
-   representations of the names with components separated by slashes.
-   Leading and trailing slashes will not be included. Note that the
-   slash separator is consistent with Kerberos implementations based on
-   RFC1510, but it is different from the separator recommended in
-   RFC2253.
-
-   Names that fall into the other category MUST begin with a prefix that
-   contains no equal (=) or period (.) and the prefix MUST be followed
-   by a colon (:) and the rest of the name. All prefixes expect those
-   beginning with used. Presently none are assigned.
-
-   The reserved category includes strings which do not fall into the
-   first three categories. All names in this category are reserved. It
-   is unlikely that names will be assigned to this category unless there
-   is a very strong argument for not using the 'other' category.
-
-   These rules guarantee that there will be no conflicts between the
-   various name styles. The following additional constraints apply to
-   the assignment of realm names in the domain and X.500 categories: the
-   name of a realm for the domain or X.500 formats must either be used
-   by the organization owning (to whom it was assigned) an Internet
-   domain name or X.500 name, or in the case that no such names are
-   registered, authority to use a realm name MAY be derived from the
-   authority of the parent realm. For example, if there is no domain
-   name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
-   authorize the creation of a realm with that name.
-
-   This is acceptable because the organization to which the parent is
-   assigned is presumably the organization authorized to assign names to
-   its children in the X.500 and domain name systems as well. If the
-   parent assigns a realm name without also registering it in the domain
-   name or X.500 hierarchy, it is the parent's responsibility to make
-   sure that there will not in the future exist a name identical to the
-   realm name of the child unless it is assigned to the same entity as
-   the realm name.
-
-6.2. Principal Names
-
-   As was the case for realm names, conventions are needed to ensure
-   that all agree on what information is implied by a principal name.
-   The name-type field that is part of the principal name indicates the
-   kind of information implied by the name. The name-type SHOULD be
-   treated only as a hint to interpreting the meaning of a name. It is
-   not significant when checking for equivalence. Principal names that
-
-
-
-June 2004                                                      [Page 98]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   differ only in the name-type identify the same principal. The name
-   type does not partition the name space. Ignoring the name type, no
-   two names can be the same (i.e. at least one of the components, or
-   the realm, MUST be different). The following name types are defined:
-
-   name-type      value   meaning
-
-   name types
-
-   NT-UNKNOWN        0  Name type not known
-   NT-PRINCIPAL      1  Just the name of the principal as in DCE, or for users
-   NT-SRV-INST       2  Service and other unique instance (krbtgt)
-   NT-SRV-HST        3  Service with host name as instance (telnet, rcommands)
-   NT-SRV-XHST       4  Service with host as remaining components
-   NT-UID            5  Unique ID
-   NT-X500-PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
-   NT-SMTP-NAME      7  Name in form of SMTP email name (e.g. user@foo.com)
-   NT-ENTERPRISE    10   Enterprise name - may be mapped to principal name
-
-   When a name implies no information other than its uniqueness at a
-   particular time the name type PRINCIPAL SHOULD be used. The principal
-   name type SHOULD be used for users, and it might also be used for a
-   unique server. If the name is a unique machine generated ID that is
-   guaranteed never to be reassigned then the name type of UID SHOULD be
-   used (note that it is generally a bad idea to reassign names of any
-   type since stale entries might remain in access control lists).
-
-   If the first component of a name identifies a service and the
-   remaining components identify an instance of the service in a server
-   specified manner, then the name type of SRV-INST SHOULD be used. An
-   example of this name type is the Kerberos ticket-granting service
-   whose name has a first component of krbtgt and a second component
-   identifying the realm for which the ticket is valid.
-
-   If the first component of a name identifies a service and there is a
-   single component following the service name identifying the instance
-   as the host on which the server is running, then the name type SRV-
-   HST SHOULD be used. This type is typically used for Internet services
-   such as telnet and the Berkeley R commands. If the separate
-   components of the host name appear as successive components following
-   the name of the service, then the name type SRV-XHST SHOULD be used.
-   This type might be used to identify servers on hosts with X.500 names
-   where the slash (/) might otherwise be ambiguous.
-
-   A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an
-   X.509 certificate is translated into a Kerberos name. The encoding of
-   the X.509 name as a Kerberos principal shall conform to the encoding
-   rules specified in RFC 2253.
-
-
-
-June 2004                                                      [Page 99]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   A name type of SMTP allows a name to be of a form that resembles a
-   SMTP email name. This name, including an "@" and a domain name, is
-   used as the one component of the principal name.
-
-   A name type of UNKNOWN SHOULD be used when the form of the name is
-   not known. When comparing names, a name of type UNKNOWN will match
-   principals authenticated with names of any type. A principal
-   authenticated with a name of type UNKNOWN, however, will only match
-   other names of type UNKNOWN.
-
-   Names of any type with an initial component of 'krbtgt' are reserved
-   for the Kerberos ticket granting service. See section 7.3 for the
-   form of such names.
-
-6.2.1. Name of server principals
-
-   The principal identifier for a server on a host will generally be
-   composed of two parts: (1) the realm of the KDC with which the server
-   is registered, and (2) a two-component name of type NT-SRV-HST if the
-   host name is an Internet domain name or a multi-component name of
-   type NT-SRV-XHST if the name of the host is of a form such as X.500
-   that allows slash (/) separators. The first component of the two- or
-   multi-component name will identify the service and the latter
-   components will identify the host. Where the name of the host is not
-   case sensitive (for example, with Internet domain names) the name of
-   the host MUST be lower case. If specified by the application protocol
-   for services such as telnet and the Berkeley R commands which run
-   with system privileges, the first component MAY be the string 'host'
-   instead of a service specific identifier.
-
-7. Constants and other defined values
-
-7.1. Host address types
-
-   All negative values for the host address type are reserved for local
-   use.  All non-negative values are reserved for officially assigned
-   type fields and interpretations.
-
-   Internet (IPv4) Addresses
-
-      Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded
-      in MSB order. The IPv4 loopback address SHOULD NOT appear in a
-      Kerberos packet. The type of IPv4 addresses is two (2).
-
-   Internet (IPv6) Addresses
-
-      IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities,
-      encoded in MSB order. The type of IPv6 addresses is twenty-four
-
-
-
-June 2004                                                     [Page 100]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      (24). The following addresses MUST NOT appear in any Kerberos
-      packet:
-
-         *  the Unspecified Address
-         *  the Loopback Address
-         *  Link-Local addresses
-
-      IPv4-mapped IPv6 addresses MUST be represented as addresses of
-      type 2.
-
-   DECnet Phase IV addresses
-
-      DECnet Phase IV addresses are 16-bit addresses, encoded in LSB
-      order. The type of DECnet Phase IV addresses is twelve (12).
-
-   Netbios addresses
-
-      Netbios addresses are 16-octet addresses typically composed of 1
-      to 15 alphanumeric characters and padded with the US-ASCII SPC
-      character (code 32).  The 16th octet MUST be the US-ASCII NUL
-      character (code 0).  The type of Netbios addresses is twenty (20).
-
-   Directional Addresses
-
-      In many environments, including the sender address in KRB_SAFE and
-      KRB_PRIV messages is undesirable because the addresses may be
-      changed in transport by network address translators. However, if
-      these addresses are removed, the messages may be subject to a
-      reflection attack in which a message is reflected back to its
-      originator. The directional address type provides a way to avoid
-      transport addresses and reflection attacks. Directional addresses
-      are encoded as four byte unsigned integers in network byte order.
-      If the message is originated by the party sending the original
-      KRB_AP_REQ message, then an address of 0 SHOULD be used. If the
-      message is originated by the party to whom that KRB_AP_REQ was
-      sent, then the address 1 SHOULD be used. Applications involving
-      multiple parties can specify the use of other addresses.
-
-      Directional addresses MUST only be used for the sender address
-      field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used
-      as a ticket address or in a KRB_AP_REQ message. This address type
-      SHOULD only be used in situations where the sending party knows
-      that the receiving party supports the address type. This generally
-      means that directional addresses may only be used when the
-      application protocol requires their support. Directional addresses
-      are type (3).
-
-7.2. KDC messaging - IP Transports
-
-
-
-June 2004                                                     [Page 101]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   Kerberos defines two IP transport mechanisms for communication
-   between clients and servers: UDP/IP and TCP/IP.
-
-7.2.1. UDP/IP transport
-
-   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
-   requests and SHOULD listen for such requests on port 88 (decimal)
-   unless specifically configured to listen on an alternative UDP port.
-   Alternate ports MAY be used when running multiple KDCs for multiple
-   realms on the same host.
-
-   Kerberos clients supporting IP transports SHOULD support the sending
-   of UDP requests. Clients SHOULD use KDC discovery [7.2.3] to identify
-   the IP address and port to which they will send their request.
-
-   When contacting a KDC for a KRB_KDC_REQ request using UDP/IP
-   transport, the client shall send a UDP datagram containing only an
-   encoding of the request to the KDC. The KDC will respond with a reply
-   datagram containing only an encoding of the reply message (either a
-   KRB_ERROR or a KRB_KDC_REP) to the sending port at the sender's IP
-   address. The response to a request made through UDP/IP transport MUST
-   also use UDP/IP transport. If the response can not be handled using
-   UDP (for example because it is too large), the KDC MUST return
-   KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the request
-   using the TCP transport.
-
-7.2.2. TCP/IP transport
-
-   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
-   requests and SHOULD listen for such requests on port 88 (decimal)
-   unless specifically configured to listen on an alternate TCP port.
-   Alternate ports MAY be used when running multiple KDCs for multiple
-   realms on the same host.
-
-   Clients MUST support the sending of TCP requests, but MAY choose to
-   initially try a request using the UDP transport. Clients SHOULD use
-   KDC discovery [7.2.3] to identify the IP address and port to which
-   they will send their request.
-
-   Implementation note: Some extensions to the Kerberos protocol will
-   not succeed if any client or KDC not supporting the TCP transport is
-   involved.  Implementations of RFC 1510 were not required to support
-   TCP/IP transports.
-
-   When the KRB_KDC_REQ message is sent to the KDC over a TCP stream,
-   the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to
-   the client on the same TCP stream that was established for the
-   request. The KDC MAY close the TCP stream after sending a response,
-
-
-
-June 2004                                                     [Page 102]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   but MAY leave the stream open for a reasonable period of time if it
-   expects a followup. Care must be taken in managing TCP/IP connections
-   on the KDC to prevent denial of service attacks based on the number
-   of open TCP/IP connections.
-
-   The client MUST be prepared to have the stream closed by the KDC at
-   anytime after the receipt of a response. A stream closure SHOULD NOT
-   be treated as a fatal error. Instead, if multiple exchanges are
-   required (e.g., certain forms of pre-authentication) the client may
-   need to establish a new connection when it is ready to send
-   subsequent messages. A client MAY close the stream after receiving a
-   response, and SHOULD close the stream if it does not expect to send
-   followup messages.
-
-   A client MAY send multiple requests before receiving responses,
-   though it must be prepared to handle the connection being closed
-   after the first response.
-
-   Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR)
-   sent over the TCP stream is preceded by the length of the request as
-   4 octets in network byte order. The high bit of the length is
-   reserved for future expansion and MUST currently be set to zero.  If
-   a KDC that does not understand how to interpret a set high bit of the
-   length encoding receives a request with the high order bit of the
-   length set, it MUST return a KRB-ERROR message with the error
-   KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream.
-
-   If multiple requests are sent over a single TCP connection, and the
-   KDC sends multiple responses, the KDC is not required to send the
-   responses in the order of the corresponding requests. This may permit
-   some implementations to send each response as soon as it is ready
-   even if earlier requests are still being processed (for example,
-   waiting for a response from an external device or database).
-
-7.2.3. KDC Discovery on IP Networks
-
-   Kerberos client implementations MUST provide a means for the client
-   to determine the location of the Kerberos Key Distribution Centers
-   (KDCs).  Traditionally, Kerberos implementations have stored such
-   configuration information in a file on each client machine.
-   Experience has shown this method of storing configuration information
-   presents problems with out-of-date information and scaling problems,
-   especially when using cross-realm authentication. This section
-   describes a method for using the Domain Name System [RFC 1035] for
-   storing KDC location information.
-
-7.2.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names
-
-
-
-
-June 2004                                                     [Page 103]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   In Kerberos, realm names are case sensitive. While it is strongly
-   encouraged that all realm names be all upper case this recommendation
-   has not been adopted by all sites. Some sites use all lower case
-   names and other use mixed case. DNS on the other hand is case
-   insensitive for queries. Since the realm names "MYREALM", "myrealm",
-   and "MyRealm" are all different, but resolve the same in the domain
-   name system, it is necessary that only one of the possible
-   combinations of upper and lower case characters be used in realm
-   names.
-
-7.2.3.2. Specifying KDC Location information with DNS SRV records
-
-   KDC location information is to be stored using the DNS SRV RR [RFC
-   2782].  The format of this RR is as follows:
-
-      _Service._Proto.Realm TTL Class SRV Priority Weight Port Target
-
-   The Service name for Kerberos is always "kerberos".
-
-   The Proto can be one of "udp", "tcp". If these SRV records are to be
-   used, both "udp" and "tcp" records MUST be specified for all KDC
-   deployments.
-
-   The Realm is the Kerberos realm that this record corresponds to.  The
-   realm MUST be a domain style realm name.
-
-   TTL, Class, SRV, Priority, Weight, and Target have the standard
-   meaning as defined in RFC 2782.
-
-   As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
-   records SHOULD be the value assigned to "kerberos" by the Internet
-   Assigned Number Authority: 88 (decimal) unless the KDC is configured
-   to listen on an alternate TCP port.
-
-   Implementation note: Many existing client implementations do not
-   support KDC Discovery and are configured to send requests to the IANA
-   assigned port (88 decimal), so it is strongly recommended that KDCs
-   be configured to listen on that port.
-
-7.2.3.3. KDC Discovery for Domain Style Realm Names on IP Networks
-
-   These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
-   Kerberos servers, kdc1.example.com and kdc2.example.com. Queries
-   should be directed to kdc1.example.com first as per the specified
-   priority. Weights are not used in these sample records.
-
-     _kerberos._udp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
-     _kerberos._udp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
-
-
-
-June 2004                                                     [Page 104]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-     _kerberos._tcp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
-     _kerberos._tcp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
-
-7.3. Name of the TGS
-
-   The principal identifier of the ticket-granting service shall be
-   composed of three parts: (1) the realm of the KDC issuing the TGS
-   ticket (2) a two-part name of type NT-SRV-INST, with the first part
-   "krbtgt" and the second part the name of the realm which will accept
-   the ticket-granting ticket. For example, a ticket-granting ticket
-   issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
-   ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
-   (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A ticket-granting
-   ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets
-   from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU"
-   (realm), ("krbtgt", "MIT.EDU") (name).
-
-7.4. OID arc for KerberosV5
-
-   This OID MAY be used to identify Kerberos protocol messages
-   encapsulated in other protocols. It also designates the OID arc for
-   KerberosV5-related OIDs assigned by future IETF action.
-   Implementation note:: RFC 1510 had an incorrect value (5) for "dod"
-   in its OID.
-
-   id-krb5         OBJECT IDENTIFIER ::= {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2)
-   }
-
-
-   Assignment of OIDs beneath the id-krb5 arc must be obtained by
-   contacting the registrar for the id-krb5 arc, or its designee.  At
-   the time of the issuance of this RFC, such registrations can be
-   obtained by contacting krb5-oid-registrar@mit.edu.
-
-7.5. Protocol constants and associated values
-
-   The following tables list constants used in the protocol and define
-   their meanings. Ranges are specified in the "specification" section
-   that limit the values of constants for which values are defined here.
-   This allows implementations to make assumptions about the maximum
-   values that will be received for these constants. Implementation
-   receiving values outside the range specified in the "specification"
-   section MAY reject the request, but they MUST recover cleanly.
-
-7.5.1. Key usage numbers
-
-
-
-
-June 2004                                                     [Page 105]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   The encryption and checksum specifications in [@KCRYPTO] require as
-   input a "key usage number", to alter the encryption key used in any
-   specific message, to make certain types of cryptographic attack more
-   difficult. These are the key usage values assigned in this document:
-
-           1.          AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted
-                       with the client key (section 5.2.7.2)
-           2.          AS-REP Ticket and TGS-REP Ticket (includes TGS session
-                       key or application session key), encrypted with the
-                       service key (section 5.3)
-           3.          AS-REP encrypted part (includes TGS session key or
-                       application session key), encrypted with the client key
-                       (section 5.4.2)
-           4.          TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with
-                       the TGS session key (section 5.4.1)
-           5.          TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with
-                       the TGS authenticator subkey (section 5.4.1)
-           6.          TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
-                       keyed with the TGS session key (sections 5.5.1)
-           7.          TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator
-                       (includes TGS authenticator subkey), encrypted with the
-                       TGS session key (section 5.5.1)
-           8.          TGS-REP encrypted part (includes application session
-                       key), encrypted with the TGS session key (section
-                       5.4.2)
-           9.          TGS-REP encrypted part (includes application session
-                       key), encrypted with the TGS authenticator subkey
-                       (section 5.4.2)
-           10.         AP-REQ Authenticator cksum, keyed with the application
-                       session key (section 5.5.1)
-           11.         AP-REQ Authenticator (includes application
-                       authenticator subkey), encrypted with the application
-                       session key (section 5.5.1)
-           12.         AP-REP encrypted part (includes application session
-                       subkey), encrypted with the application session key
-                       (section 5.5.2)
-           13.         KRB-PRIV encrypted part, encrypted with a key chosen by
-                       the application (section 5.7.1)
-           14.         KRB-CRED encrypted part, encrypted with a key chosen by
-                       the application (section 5.8.1)
-           15.         KRB-SAFE cksum, keyed with a key chosen by the
-                       application (section 5.6.1)
-           19.         AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4)
-         22-25.        Reserved for use in GSSAPI mechanisms derived from RFC
-                       1964. (raeburn/MIT)
-    16-18,20-21,26-511. Reserved for future use in Kerberos and related
-                       protocols.
-        512-1023.      Reserved for uses internal to a Kerberos
-
-
-
-June 2004                                                     [Page 106]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-                       implementation.
-         1024.         Encryption for application use in protocols that
-                       do not specify key usage values
-         1025.         Checksums for application use in protocols that
-                       do not specify key usage values
-       1026-2047.      Reserved for application use.
-
-
-7.5.2. PreAuthentication Data Types
-
-   padata and data types           padata-type value  comment
-
-   PA-TGS-REQ                      1
-   PA-ENC-TIMESTAMP                2
-   PA-PW-SALT                      3
-   [reserved]                      4
-   PA-ENC-UNIX-TIME                5        (deprecated)
-   PA-SANDIA-SECUREID              6
-   PA-SESAME                       7
-   PA-OSF-DCE                      8
-   PA-CYBERSAFE-SECUREID           9
-   PA-AFS3-SALT                    10
-   PA-ETYPE-INFO                   11
-   PA-SAM-CHALLENGE                12       (sam/otp)
-   PA-SAM-RESPONSE                 13       (sam/otp)
-   PA-PK-AS-REQ                    14       (pkinit)
-   PA-PK-AS-REP                    15       (pkinit)
-   PA-ETYPE-INFO2                  19       (replaces pa-etype-info)
-   PA-USE-SPECIFIED-KVNO           20
-   PA-SAM-REDIRECT                 21       (sam/otp)
-   PA-GET-FROM-TYPED-DATA          22       (embedded in typed data)
-   TD-PADATA                       22       (embeds padata)
-   PA-SAM-ETYPE-INFO               23       (sam/otp)
-   PA-ALT-PRINC                    24       (crawdad@fnal.gov)
-   PA-SAM-CHALLENGE2               30       (kenh@pobox.com)
-   PA-SAM-RESPONSE2                31       (kenh@pobox.com)
-   PA-EXTRA-TGT                    41       Reserved extra TGT
-   TD-PKINIT-CMS-CERTIFICATES      101      CertificateSet from CMS
-   TD-KRB-PRINCIPAL                102      PrincipalName
-   TD-KRB-REALM                    103      Realm
-   TD-TRUSTED-CERTIFIERS           104      from PKINIT
-   TD-CERTIFICATE-INDEX            105      from PKINIT
-   TD-APP-DEFINED-ERROR            106      application specific
-   TD-REQ-NONCE                    107      INTEGER
-   TD-REQ-SEQ                      108      INTEGER
-   PA-PAC-REQUEST                  128      (jbrezak@exchange.microsoft.com)
-
-7.5.3. Address Types
-
-
-
-June 2004                                                     [Page 107]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   Address type                   value
-
-   IPv4                             2
-   Directional                      3
-   ChaosNet                         5
-   XNS                              6
-   ISO                              7
-   DECNET Phase IV                 12
-   AppleTalk DDP                   16
-   NetBios                         20
-   IPv6                            24
-
-7.5.4. Authorization Data Types
-
-   authorization data type         ad-type value
-   AD-IF-RELEVANT                     1
-   AD-INTENDED-FOR-SERVER             2
-   AD-INTENDED-FOR-APPLICATION-CLASS  3
-   AD-KDC-ISSUED                      4
-   AD-AND-OR                          5
-   AD-MANDATORY-TICKET-EXTENSIONS     6
-   AD-IN-TICKET-EXTENSIONS            7
-   AD-MANDATORY-FOR-KDC               8
-   reserved values                    9-63
-   OSF-DCE                            64
-   SESAME                             65
-   AD-OSF-DCE-PKI-CERTID              66     (hemsath@us.ibm.com)
-   AD-WIN2K-PAC                      128     (jbrezak@exchange.microsoft.com)
-
-7.5.5. Transited Encoding Types
-
-   transited encoding type         tr-type value
-   DOMAIN-X500-COMPRESS            1
-   reserved values                 all others
-
-7.5.6. Protocol Version Number
-
-   Label               Value   Meaning or MIT code
-
-   pvno                    5   current Kerberos protocol version number
-
-7.5.7. Kerberos Message Types
-
-   message types
-
-   KRB_AS_REQ             10   Request for initial authentication
-   KRB_AS_REP             11   Response to KRB_AS_REQ request
-   KRB_TGS_REQ            12   Request for authentication based on TGT
-
-
-
-June 2004                                                     [Page 108]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   KRB_TGS_REP         13   Response to KRB_TGS_REQ request
-   KRB_AP_REQ          14   application request to server
-   KRB_AP_REP          15   Response to KRB_AP_REQ_MUTUAL
-   KRB_RESERVED16      16   Reserved for user-to-user krb_tgt_request
-   KRB_RESERVED17      17   Reserved for user-to-user krb_tgt_reply
-   KRB_SAFE            20   Safe (checksummed) application message
-   KRB_PRIV            21   Private (encrypted) application message
-   KRB_CRED            22   Private (encrypted) message to forward credentials
-   KRB_ERROR           30   Error response
-
-7.5.8. Name Types
-
-   name types
-
-   KRB_NT_UNKNOWN     0  Name type not known
-   KRB_NT_PRINCIPAL   1  Just the name of the principal as in DCE, or for users
-   KRB_NT_SRV_INST    2  Service and other unique instance (krbtgt)
-   KRB_NT_SRV_HST     3  Service with host name as instance (telnet, rcommands)
-   KRB_NT_SRV_XHST    4  Service with host as remaining components
-   KRB_NT_UID         5  Unique ID
-   KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]
-   KRB_NT_SMTP_NAME   7  Name in form of SMTP email name (e.g. user@foo.com)
-   KRB_NT_ENTERPRISE 10   Enterprise name - may be mapped to principal name
-
-7.5.9. Error Codes
-
-   error codes
-
-   KDC_ERR_NONE                  0  No error
-   KDC_ERR_NAME_EXP              1  Client's entry in database has expired
-   KDC_ERR_SERVICE_EXP           2  Server's entry in database has expired
-   KDC_ERR_BAD_PVNO              3  Requested protocol version number
-                                       not supported
-   KDC_ERR_C_OLD_MAST_KVNO       4  Client's key encrypted in old master key
-   KDC_ERR_S_OLD_MAST_KVNO       5  Server's key encrypted in old master key
-   KDC_ERR_C_PRINCIPAL_UNKNOWN   6  Client not found in Kerberos database
-   KDC_ERR_S_PRINCIPAL_UNKNOWN   7  Server not found in Kerberos database
-   KDC_ERR_PRINCIPAL_NOT_UNIQUE  8  Multiple principal entries in database
-   KDC_ERR_NULL_KEY              9  The client or server has a null key
-   KDC_ERR_CANNOT_POSTDATE      10  Ticket not eligible for postdating
-   KDC_ERR_NEVER_VALID          11  Requested start time is later than end time
-   KDC_ERR_POLICY               12  KDC policy rejects request
-   KDC_ERR_BADOPTION            13  KDC cannot accommodate requested option
-   KDC_ERR_ETYPE_NOSUPP         14  KDC has no support for encryption type
-   KDC_ERR_SUMTYPE_NOSUPP       15  KDC has no support for checksum type
-   KDC_ERR_PADATA_TYPE_NOSUPP   16  KDC has no support for padata type
-   KDC_ERR_TRTYPE_NOSUPP        17  KDC has no support for transited type
-   KDC_ERR_CLIENT_REVOKED       18  Clients credentials have been revoked
-
-
-
-June 2004                                                     [Page 109]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   KDC_ERR_SERVICE_REVOKED      19   Credentials for server have been revoked
-   KDC_ERR_TGT_REVOKED          20   TGT has been revoked
-   KDC_ERR_CLIENT_NOTYET        21   Client not yet valid - try again later
-   KDC_ERR_SERVICE_NOTYET       22   Server not yet valid - try again later
-   KDC_ERR_KEY_EXPIRED          23   Password has expired
-                                           - change password to reset
-   KDC_ERR_PREAUTH_FAILED       24   Pre-authentication information was invalid
-   KDC_ERR_PREAUTH_REQUIRED     25   Additional pre-authenticationrequired
-   KDC_ERR_SERVER_NOMATCH       26   Requested server and ticket don't match
-   KDC_ERR_MUST_USE_USER2USER   27   Server principal valid for user2user only
-   KDC_ERR_PATH_NOT_ACCPETED    28   KDC Policy rejects transited path
-   KDC_ERR_SVC_UNAVAILABLE      29   A service is not available
-   KRB_AP_ERR_BAD_INTEGRITY     31   Integrity check on decrypted field failed
-   KRB_AP_ERR_TKT_EXPIRED       32   Ticket expired
-   KRB_AP_ERR_TKT_NYV           33   Ticket not yet valid
-   KRB_AP_ERR_REPEAT            34   Request is a replay
-   KRB_AP_ERR_NOT_US            35   The ticket isn't for us
-   KRB_AP_ERR_BADMATCH          36   Ticket and authenticator don't match
-   KRB_AP_ERR_SKEW              37   Clock skew too great
-   KRB_AP_ERR_BADADDR           38   Incorrect net address
-   KRB_AP_ERR_BADVERSION        39   Protocol version mismatch
-   KRB_AP_ERR_MSG_TYPE          40   Invalid msg type
-   KRB_AP_ERR_MODIFIED          41   Message stream modified
-   KRB_AP_ERR_BADORDER          42   Message out of order
-   KRB_AP_ERR_BADKEYVER         44   Specified version of key is not available
-   KRB_AP_ERR_NOKEY             45   Service key not available
-   KRB_AP_ERR_MUT_FAIL          46   Mutual authentication failed
-   KRB_AP_ERR_BADDIRECTION      47   Incorrect message direction
-   KRB_AP_ERR_METHOD            48   Alternative authentication method required
-   KRB_AP_ERR_BADSEQ            49   Incorrect sequence number in message
-   KRB_AP_ERR_INAPP_CKSUM       50   Inappropriate type of checksum in message
-   KRB_AP_PATH_NOT_ACCEPTED     51   Policy rejects transited path
-   KRB_ERR_RESPONSE_TOO_BIG     52   Response too big for UDP, retry with TCP
-   KRB_ERR_GENERIC              60   Generic error (description in e-text)
-   KRB_ERR_FIELD_TOOLONG        61   Field is too long for this implementation
-   KDC_ERROR_CLIENT_NOT_TRUSTED    62 Reserved for PKINIT
-   KDC_ERROR_KDC_NOT_TRUSTED       63 Reserved for PKINIT
-   KDC_ERROR_INVALID_SIG           64 Reserved for PKINIT
-   KDC_ERR_KEY_TOO_WEAK            65 Reserved for PKINIT
-   KDC_ERR_CERTIFICATE_MISMATCH    66 Reserved for PKINIT
-   KRB_AP_ERR_NO_TGT               67 No TGT available to validate USER-TO-USER
-   KDC_ERR_WRONG_REALM             68 USER-TO-USER TGT issued different KDC
-   KRB_AP_ERR_USER_TO_USER_REQUIRED  69 Ticket must be for USER-TO-USER
-   KDC_ERR_CANT_VERIFY_CERTIFICATE   70 Reserved for PKINIT
-   KDC_ERR_INVALID_CERTIFICATE             71 Reserved for PKINIT
-   KDC_ERR_REVOKED_CERTIFICATE             72 Reserved for PKINIT
-   KDC_ERR_REVOCATION_STATUS_UNKNOWN       73 Reserved for PKINIT
-   KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74 Reserved for PKINIT
-
-
-
-June 2004                                                     [Page 110]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   KDC_ERR_CLIENT_NAME_MISMATCH            75 Reserved for PKINIT
-   KDC_ERR_KDC_NAME_MISMATCH               76 Reserved for PKINIT
-
-8. Interoperability requirements
-
-   Version 5 of the Kerberos protocol supports a myriad of options.
-   Among these are multiple encryption and checksum types, alternative
-   encoding schemes for the transited field, optional mechanisms for
-   pre-authentication, the handling of tickets with no addresses,
-   options for mutual authentication, user-to-user authentication,
-   support for proxies, forwarding, postdating, and renewing tickets,
-   the format of realm names, and the handling of authorization data.
-
-   In order to ensure the interoperability of realms, it is necessary to
-   define a minimal configuration which must be supported by all
-   implementations. This minimal configuration is subject to change as
-   technology does. For example, if at some later date it is discovered
-   that one of the required encryption or checksum algorithms is not
-   secure, it will be replaced.
-
-8.1. Specification 2
-
-   This section defines the second specification of these options.
-   Implementations which are configured in this way can be said to
-   support Kerberos Version 5 Specification 2 (5.2). Specification 1
-   (deprecated) may be found in RFC1510.
-
-   Transport
-
-      TCP/IP and UDP/IP transport MUST be supported by clients and KDCs
-      claiming conformance to specification 2.
-
-   Encryption and checksum methods
-
-      The following encryption and checksum mechanisms MUST be
-      supported.
-
-      Encryption: AES256-CTS-HMAC-SHA1-96
-      Checksums: HMAC-SHA1-96-AES256
-
-      Implementations SHOULD support other mechanisms as well, but the
-      additional mechanisms may only be used when communicating with
-      principals known to also support them. The mechanisms that SHOULD
-      be supported are:
-
-      Encryption:  DES-CBC-MD5, DES3-CBC-SHA1-KD
-      Checksums:   DES-MD5, HMAC-SHA1-DES3-KD
-
-
-
-
-June 2004                                                     [Page 111]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      Implementations MAY support other mechanisms as well, but the
-      additional mechanisms may only be used when communicating with
-      principals known to also support them.
-
-      Implementation note: earlier implementations of Kerberos generate
-      messages using the CRC-32, RSA-MD5 checksum methods. For
-      interoperability with these earlier releases implementors MAY
-      consider supporting these checksum methods but should carefully
-      analyze the security impplications to limit the situations within
-      which these methods are accepted.
-
-   Realm Names
-
-      All implementations MUST understand hierarchical realms in both
-      the Internet Domain and the X.500 style. When a ticket-granting
-      ticket for an unknown realm is requested, the KDC MUST be able to
-      determine the names of the intermediate realms between the KDCs
-      realm and the requested realm.
-
-   Transited field encoding
-
-      DOMAIN-X500-COMPRESS (described in section 3.3.3.2) MUST be
-      supported.  Alternative encodings MAY be supported, but they may
-      be used only when that encoding is supported by ALL intermediate
-      realms.
-
-   Pre-authentication methods
-
-      The TGS-REQ method MUST be supported. The TGS-REQ method is not
-      used on the initial request. The PA-ENC-TIMESTAMP method MUST be
-      supported by clients but whether it is enabled by default MAY be
-      determined on a realm by realm basis. If not used in the initial
-      request and the error KDC_ERR_PREAUTH_REQUIRED is returned
-      specifying PA-ENC-TIMESTAMP as an acceptable method, the client
-      SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre-
-      authentication method. Servers need not support the PA-ENC-
-      TIMESTAMP method, but if not supported the server SHOULD ignore
-      the presence of PA-ENC-TIMESTAMP pre-authentication in a request.
-
-      The ETYPE-INFO2 method MUST be supported; this method is used to
-      communicate the set of supported encryption types, and
-      corresponding salt and string to key paramters. The ETYPE-INFO
-      method SHOULD be supported for interoperability with older
-      implementation.
-
-   Mutual authentication
-
-      Mutual authentication (via the KRB_AP_REP message) MUST be
-
-
-
-June 2004                                                     [Page 112]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      supported.
-
-   Ticket addresses and flags
-
-      All KDCs MUST pass through tickets that carry no addresses (i.e.
-      if a TGT contains no addresses, the KDC will return derivative
-      tickets).  Implementations SHOULD default to requesting
-      addressless tickets as this significantly increases
-      interoperability with network address translation.  In some cases
-      realms or application servers MAY require that tickets have an
-      address.
-
-      Implementations SHOULD accept directional address type for the
-      KRB_SAFE and KRB_PRIV message and SHOULD include directional
-      addresses in these messages when other address types are not
-      available.
-
-      Proxies and forwarded tickets MUST be supported. Individual realms
-      and application servers can set their own policy on when such
-      tickets will be accepted.
-
-      All implementations MUST recognize renewable and postdated
-      tickets, but need not actually implement them. If these options
-      are not supported, the starttime and endtime in the ticket shall
-      specify a ticket's entire useful life. When a postdated ticket is
-      decoded by a server, all implementations shall make the presence
-      of the postdated flag visible to the calling server.
-
-   User-to-user authentication
-
-      Support for user-to-user authentication (via the ENC-TKT-IN-SKEY
-      KDC option) MUST be provided by implementations, but individual
-      realms MAY decide as a matter of policy to reject such requests on
-      a per-principal or realm-wide basis.
-
-   Authorization data
-
-      Implementations MUST pass all authorization data subfields from
-      ticket-granting tickets to any derivative tickets unless directed
-      to suppress a subfield as part of the definition of that
-      registered subfield type (it is never incorrect to pass on a
-      subfield, and no registered subfield types presently specify
-      suppression at the KDC).
-
-      Implementations MUST make the contents of any authorization data
-      subfields available to the server when a ticket is used.
-      Implementations are not required to allow clients to specify the
-      contents of the authorization data fields.
-
-
-
-June 2004                                                     [Page 113]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   Constant ranges
-
-      All protocol constants are constrained to 32 bit (signed) values
-      unless further constrained by the protocol definition. This limit
-      is provided to allow implementations to make assumptions about the
-      maximum values that will be received for these constants.
-      Implementation receiving values outside this range MAY reject the
-      request, but they MUST recover cleanly.
-
-8.2. Recommended KDC values
-
-   Following is a list of recommended values for a KDC configuration.
-
-   minimum lifetime              5 minutes
-   maximum renewable lifetime    1 week
-   maximum ticket lifetime       1 day
-   acceptable clock skew         5 minutes
-   empty addresses               Allowed.
-   proxiable, etc.               Allowed.
-
-9. IANA considerations
-
-   Section 7 of this document specifies protocol constants and other
-   defined values required for the interoperability of multiple
-   implementations. Until otherwise specified in a subsequent RFC, or
-   upon disbanding of the Kerberos working group, allocations of
-   additional protocol constants and other defined values required for
-   extensions to the Kerberos protocol will be administered by the
-   kerberos working group.  Following the recomendations outlined in
-   [RFC 2434], guidance is provided to the IANA as follows:
-
-   "reserved" realm name types in section 6.1 and "other" realm types
-   except those beginning with "X-" or "x-" will not be registered
-   without IETF standards action, at which point guidlines for further
-   assignment will be specified.  Realm name types beginning with "X-"
-   or "x-" are for private use.
-
-   For host address types described in section 7.1, negative values are
-   for private use.  Assignment of additional positive numbers is
-   subject to review by the kerberos working group or other expert
-   review.
-
-   Additional key usage numbers as defined in section 7.5.1 will be
-   assigned subject to review by the kerberos working group or other
-   expert review.
-
-   Additional preauthentciation data type values as defined in section
-   7.5.2 will be assigned subject to review by the kerberos working
-
-
-
-June 2004                                                     [Page 114]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   group or other expert review.
-
-   Additional Authorization Data Types as defined in section 7.5.4 will
-   be assigned subject to review by the kerberos working group or other
-   expert review.  Although it is anticipated that there may be
-   significant demand for private use types, provision is intentionaly
-   not made for a private use portion of the namespace because conficts
-   between privately assigned values coule have detrimental security
-   implications.
-
-   Additional Transited Encoding Types as defined in section 7.5.5
-   present special concerns for interoperability with existing
-   implementations.  As such, such assignments will only be made by
-   standards action, except that the Kerberos working group or another
-   other working group with competent jurisdiction may make preliminary
-   assignments for documents which are moving through the standards
-   process.
-
-   Additional Kerberos Message Types as described in section 7.5.7 will
-   be assigned subject to review by the kerberos working group or other
-   expert review.
-
-   Additional Name Types as described in section 7.5.8 will be assigned
-   subject to review by the kerberos working group or other expert
-   review.
-
-   Additional error codes described in section 7.5.9 will be assigned
-   subject to review by the kerberos working group or other expert
-   review.
-
-10. Security Considerations
-
-   As an authentication service, Kerberos provides a means of verifying
-   the identity of principals on a network. Kerberos does not, by
-   itself, provide authorization. Applications should not accept the
-   issuance of a service ticket by the Kerberos server as granting
-   authority to use the service, since such applications may become
-   vulnerable to the bypass of this authorization check in an
-   environment if they inter-operate with other KDCs or where other
-   options for application authentication are provided.
-
-   Denial of service attacks are not solved with Kerberos. There are
-   places in the protocols where an intruder can prevent an application
-   from participating in the proper authentication steps. Because
-   authentication is a required step for the use of many services,
-   successful denial of service attacks on a Kerberos server might
-   result in the denial of other network services that rely on Kerberos
-   for authentication. Kerberos is vulnerable to many kinds of denial of
-
-
-
-June 2004                                                     [Page 115]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   service attacks: denial of service attacks on the network which would
-   prevent clients from contacting the KDC; denial of service attacks on
-   the domain name system which could prevent a client from finding the
-   IP address of the Kerberos server; and denial of service attack by
-   overloading the Kerberos KDC itself with repeated requests.
-
-   Interoperability conflicts caused by incompatible character-set usage
-   (see 5.2.1) can result in denial of service for clients that utilize
-   character-sets in Kerberos strings other than those stored in the KDC
-   database.
-
-   Authentication servers maintain a database of principals (i.e., users
-   and servers) and their secret keys. The security of the
-   authentication server machines is critical. The breach of security of
-   an authentication server will compromise the security of all servers
-   that rely upon the compromised KDC, and will compromise the
-   authentication of any principals registered in the realm of the
-   compromised KDC.
-
-   Principals must keep their secret keys secret. If an intruder somehow
-   steals a principal's key, it will be able to masquerade as that
-   principal or impersonate any server to the legitimate principal.
-
-   Password guessing attacks are not solved by Kerberos. If a user
-   chooses a poor password, it is possible for an attacker to
-   successfully mount an off-line dictionary attack by repeatedly
-   attempting to decrypt, with successive entries from a dictionary,
-   messages obtained which are encrypted under a key derived from the
-   user's password.
-
-   Unless pre-authentication options are required by the policy of a
-   realm, the KDC will not know whether a request for authentication
-   succeeds. An attacker can request a reply with credentials for any
-   principal. These credentials will likely not be of much use to the
-   attacker unless it knows the client's secret key, but the
-   availability of the response encrypted in the client's secret key
-   provides the attacker with ciphertext that may be used to mount brute
-   force or dictionary attacks to decrypt the credentials, by guessing
-   the user's password. For this reason it is strongly encouraged that
-   Kerberos realms require the use of pre-authentication. Even with pre-
-   authentication, attackers may try brute force or dictionary attacks
-   against credentials that are observed by eavesdropping on the
-   network.
-
-   Because a client can request a ticket for any server principal and
-   can attempt a brute force or dictionary attack against the server
-   principal's key using that ticket, it is strongly encouraged that
-   keys be randomly generated (rather than generated from passwords) for
-
-
-
-June 2004                                                     [Page 116]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   any principals that are usable as the target principal for a
-   KRB_TGS_REQ or KRB_AS_REQ messages. [RFC1750]
-
-   Although the DES-CBC-MD5 encryption method and DES-MD5 checksum
-   methods are listed as SHOULD be implemented for backward
-   compatibility, the single DES encryption algorithm on which these are
-   based is weak and stronger algorithms should be used whenever
-   possible.
-
-   Each host on the network must have a clock which is loosely
-   synchronized to the time of the other hosts; this synchronization is
-   used to reduce the bookkeeping needs of application servers when they
-   do replay detection. The degree of "looseness" can be configured on a
-   per-server basis, but is typically on the order of 5 minutes. If the
-   clocks are synchronized over the network, the clock synchronization
-   protocol MUST itself be secured from network attackers.
-
-   Principal identifiers must not recycled on a short-term basis. A
-   typical mode of access control will use access control lists (ACLs)
-   to grant permissions to particular principals. If a stale ACL entry
-   remains for a deleted principal and the principal identifier is
-   reused, the new principal will inherit rights specified in the stale
-   ACL entry. By not reusing principal identifiers, the danger of
-   inadvertent access is removed.
-
-   Proper decryption of an KRB_AS_REP message from the KDC is not
-   sufficient for the host to verify the identity of the user; the user
-   and an attacker could cooperate to generate a KRB_AS_REP format
-   message which decrypts properly but is not from the proper KDC. To
-   authenticate a user logging on to a local system, the credentials
-   obtained in the AS exchange may first be used in a TGS exchange to
-   obtain credentials for a local server. Those credentials must then be
-   verified by a local server through successful completion of the
-   Client/Server exchange.
-
-   Many RFC 1510 compliant implementations ignore unknown authorization
-   data elements. Depending on these implementations to honor
-   authorization data restrictions may create a security weakness.
-
-   Kerberos credentials contain clear-text information identifying the
-   principals to which they apply. If privacy of this information is
-   needed, this exchange should itself be encapsulated in a protocol
-   providing for confidentiality on the exchange of these credentials.
-
-   Applications must take care to protect communications subsequent to
-   authentication either by using the KRB_PRIV or KRB_SAFE messages as
-   appropriate, or by applying their own confidentiality or integrity
-   mechanisms on such communications. Completion of the KRB_AP_REQ and
-
-
-
-June 2004                                                     [Page 117]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   KRB_AP_REP exchange without subsequent use of confidentiality and
-   integrity mechanisms provides only for authentication of the parties
-   to the communication and not confidentiality and integrity of the
-   subsequent communication. Application applying confidentiality and
-   integrity protection mechanisms other than KRB_PRIV and KRB_SAFE must
-   make sure that the authentication step is appropriately linked with
-   the protected communication channel that is established by the
-   application.
-
-   Unless the application server provides its own suitable means to
-   protect against replay (for example, a challenge-response sequence
-   initiated by the server after authentication, or use of a server-
-   generated encryption subkey), the server must utilize a replay cache
-   to remember any authenticator presented within the allowable clock
-   skew. All services sharing a key need to use the same replay cache.
-   If separate replay caches are used, then and authenticator used with
-   one such service could later be replayed to a different service with
-   the same service principal.
-
-   If a server loses track of authenticators presented within the
-   allowable clock skew, it must reject all requests until the clock
-   skew interval has passed, providing assurance that any lost or
-   replayed authenticators will fall outside the allowable clock skew
-   and can no longer be successfully replayed.
-
-   Implementations of Kerberos should not use untrusted directory
-   servers to determine the realm of a host. To allow such would allow
-   the compromise of the directory server to enable an attacker to
-   direct the client to accept authentication with the wrong principal
-   (i.e. one with a similar name, but in a realm with which the
-   legitimate host was not registered).
-
-   Implementations of Kerberos must not use DNS to map one name to
-   another (canonicalize) to determine the host part of the principal
-   name with which one is to communicate.  To allow such
-   canonicalization would allow a compromise of the DNS to result in a
-   client obtaining credentials and correctly authenticating to the
-   wrong principal. Though the client will know who it is communicating
-   with, it will not be the principal with which it intended to
-   communicate.
-
-   If the Kerberos server returns a TGT for a 'closer' realm other than
-   the desired realm, the client may use local policy configuration to
-   verify that the authentication path used is an acceptable one.
-   Alternatively, a client may choose its own authentication path,
-   rather than relying on the Kerberos server to select one. In either
-   case, any policy or configuration information used to choose or
-   validate authentication paths, whether by the Kerberos server or
-
-
-
-June 2004                                                     [Page 118]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   client, must be obtained from a trusted source.
-
-   The Kerberos protocol in its basic form does not provide perfect
-   forward secrecy for communications. If traffic has been recorded by
-   an eavesdropper, then messages encrypted using the KRB_PRIV message,
-   or messages encrypted using application specific encryption under
-   keys exchanged using Kerberos can be decrypted if any of the user's,
-   application server's, or KDC's key is subsequently discovered. This
-   is because the session key use to encrypt such messages is
-   transmitted over the network encrypted in the key of the application
-   server, and also encrypted under the session key from the user's
-   ticket-granting ticket when returned to the user in the KRB_TGS_REP
-   message. The session key from the ticket-granting ticket was sent to
-   the user in the KRB_AS_REP message encrypted in the user's secret
-   key, and embedded in the ticket-granting ticket, which was encrypted
-   in the key of the KDC. Application requiring perfect forward secrecy
-   must exchange keys through mechanisms that provide such assurance,
-   but may use Kerberos for authentication of the encrypted channel
-   established through such other means.
-
-11. Author's Addresses
-
-
-       Clifford Neuman
-       Information Sciences Institute
-       University of Southern California
-       4676 Admiralty Way
-       Marina del Rey, CA 90292, USA
-       Email: bcn@isi.edu
-
-       Tom Yu
-       Massachusetts Institute of Technology
-       77 Massachusetts Avenue
-       Cambridge, MA 02139, USA
-       Email: tlyu@mit.edu
-
-       Sam Hartman
-       Massachusetts Institute of Technology
-       77 Massachusetts Avenue
-       Cambridge, MA 02139, USA
-       Email: hartmans@mit.edu
-
-       Kenneth Raeburn
-       Massachusetts Institute of Technology
-       77 Massachusetts Avenue
-       Cambridge, MA 02139, USA
-       Email: raeburn@MIT.EDU
-
-
-
-
-June 2004                                                     [Page 119]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-12. Acknowledgements
-
-   This document is a revision to RFC1510 which was co-authored with
-   John Kohl.  The specification of the Kerberos protocol described in
-   this document is the result of many years of effort.  Over this
-   period many individuals have contributed to the definition of the
-   protocol and to the writing of the specification. Unfortunately it is
-   not possible to list all contributors as authors of this document,
-   though there are many not listed who are authors in spirit, because
-   they contributed text for parts of some sections, because they
-   contributed to the design of parts of the protocol, or because they
-   contributed significantly to the discussion of the protocol in the
-   IETF common authentication technology (CAT) and Kerberos working
-   groups.
-
-   Among those contributing to the development and specification of
-   Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan
-   Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl,
-   Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn,
-   Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome
-   Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift,
-   Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar
-   Westerlund, and Nicolas Williams. Many other members of MIT Project
-   Athena, the MIT networking group, and the Kerberos and CAT working
-   groups of the IETF contributed but are not listed.
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-13. REFERENCES
-
-13.1 NORMATIVE REFERENCES
-
-   [@KCRYPTO]
-      RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
-      crypto.
-
-   [@AES]
-      RFC-Editor: To be replaced by RFC number for draft-raeburn0krb-
-      rijndael-krb.
-
-   [ISO-646/ECMA-6]
-      7-bit Coded Character Set
-
-   [ISO-2022/ECMA-35]
-      Character Code Structure and Extension Techniques
-
-   [RFC1035]
-
-
-
-June 2004                                                     [Page 120]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      P.V. Mockapetris, RFC1035: "Domain Names - Implementations and
-      Specification," November 1, 1987, Obsoletes - RFC973, RFC882,
-      RFC883. Updated by RFC1101, RFC1183, RFC1348, RFCRFC1876, RFC1982,
-      RFC1995, RFC1996, RFC2065, RFC2136, RFC2137, RFC2181, RFC2308,
-      RFC2535, RFC2845, and RFC3425. Status: Standard.
-
-   [RFC2119]
-
-      S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
-      Requirement Levels", March 1997.
-
-   [RFC2434]
-      T. Narten, H. Alvestrand, RFC2434: "Guidelines for writing IANA
-      Consideration Secionts in RFCs" October, 1998.
-
-   [RFC2782]
-      A. Gulbrandsen,  P. Vixie and L. Esibov., RFC2782: "A DNS RR for
-      Specifying the Location of Services (DNS SRV)," February 2000.
-
-   [RFC2253]
-      M. Wahl, S. Killie, and T. Howes, RFC2253: "Lightweight Directory
-      Access Protocol (v3): UTF-8 String Representation or Distinguished
-      Names," December 1997, Obsoletes - RFC1779, Updated by RFC3377,
-      Status: Proposed Standard.
-
-   [RFC2373]
-      R. Hinden, S. Deering, RFC2373: "IP Version 6 Addressing
-      Architecture," July 1998, Status: Proposed Standard.
-
-   [X680]
-      Abstract Syntax Notation One (ASN.1): Specification of Basic
-      Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
-      International Standard 8824-1:1998.
-
-   [X690]
-      ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
-      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
-      (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
-      Standard 8825-1:1998.
-
-13.2 INFORMATIVE REFERENCES
-
-   [DGT96]
-      Don Davis, Daniel Geer, and Theodore Ts'o, "Kerberos With Clocks
-      Adrift: History, Protocols, and Implementation", USENIX Computing
-      Systems 9:1 (January 1996).
-
-   [DS81]
-
-
-
-June 2004                                                     [Page 121]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
-      Distribution Protocols," Communications of the ACM, Vol. 24(8),
-      pp.  533-536 (August 1981).
-
-   [KNT94]
-
-      John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
-      Evolution of the Kerberos Authentication System". In Distributed
-      Open Systems, pages 78-94. IEEE Computer Society Press, 1994.
-
-   [MNSS87]
-      S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer,
-      Section E.2.1: Kerberos Authentication and Authorization System,
-      M.I.T. Project Athena, Cambridge, Massachusetts (December 21,
-      1987).
-
-   [NS78]
-      Roger M. Needham and Michael D. Schroeder, "Using Encryption for
-      Authentication in Large Networks of Computers," Communications of
-      the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
-
-   [Neu93]
-      B. Clifford Neuman, "Proxy-Based Authorization and Accounting for
-      Distributed Systems," in Proceedings of the 13th International
-      Conference on Distributed Computing Systems, Pittsburgh, PA (May,
-      1993).
-
-   [NT94]
-      B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication
-      Service for Computer Networks," IEEE Communications Magazine, Vol.
-      32(9), pp.  33-38 (September 1994).
-
-   [Pat92].
-      J. Pato, Using Pre-Authentication to Avoid Password Guessing
-      Attacks, Open Software Foundation DCE Request for Comments 26
-      (December 1992).
-
-   [RFC1510]
-      J. Kohl and  B. C. Neuman, RFC1510: "The Kerberos Network
-      Authentication Service (v5)," September 1993, Status: Proposed
-      Standard.
-
-   [RFC1750]
-      D. Eastlake, S. Crocker, and J. Schiller "Randomness
-      Recommendation for Security" December 1994, Status: Informational.
-
-   [RFC2026]
-      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
-
-
-
-June 2004                                                     [Page 122]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
-      Practice.
-
-   [SNS88]
-      J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An
-      Authentication Service for Open Network Systems," pp. 191-202 in
-      Usenix Conference Proceedings, Dallas, Texas (February, 1988).
-
-
-14. Copyright Statement
-
-      Copyright (C) The Internet Society (2004).  This document is
-      subject to the rights, licenses and restrictions contained in BCP
-      78 and except as set forth therein, the authors retain all their
-      rights.
-
-      This document and the information contained herein are provided on
-      an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
-      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
-      THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
-      EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
-      THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
-      ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
-      PARTICULAR PURPOSE.
-
-15. Intellectual Property
-
-      The IETF takes no position regarding the validity or scope of any
-      Intellectual Property Rights or other rights that might be claimed
-      to pertain to the implementation or use of the technology
-      described in this document or the extent to which any license
-      under such rights might or might not be available; nor does it
-      represent that it has made any independent effort to identify any
-      such rights.  Information on the procedures with respect to rights
-      in RFC documents can be found in BCP 78 and BCP 79.
-
-      Copies of IPR disclosures made to the IETF Secretariat and any
-      assurances of licenses to be made available, or the result of an
-      attempt made to obtain a general license or permission for the use
-      of such proprietary rights by implementers or users of this
-      specification can be obtained from the IETF on-line IPR repository
-      at http://www.ietf.org/ipr.
-
-      The IETF invites any interested party to bring to its attention
-      any copyrights, patents or patent applications, or other
-      proprietary rights that may cover technology that may be required
-      to implement this standard.  Please address the information to the
-      IETF at ietf-ipr@ietf.org.
-
-
-
-June 2004                                                     [Page 123]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-A. ASN.1 module
-
-   KerberosV5Spec2 {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2) modules(4) krb5spec2(2)
-   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-   -- OID arc for KerberosV5
-   --
-   -- This OID may be used to identify Kerberos protocol messages
-   -- encapsulated in other protocols.
-   --
-   -- This OID also designates the OID arc for KerberosV5-related OIDs.
-   --
-   -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID.
-   id-krb5         OBJECT IDENTIFIER ::= {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2)
-   }
-
-   Int32           ::= INTEGER (-2147483648..2147483647)
-                       -- signed values representable in 32 bits
-
-   UInt32          ::= INTEGER (0..4294967295)
-                       -- unsigned 32 bit values
-
-   Microseconds    ::= INTEGER (0..999999)
-                       -- microseconds
-
-   KerberosString  ::= GeneralString (IA5String)
-
-   Realm           ::= KerberosString
-
-   PrincipalName   ::= SEQUENCE {
-           name-type       [0] Int32,
-           name-string     [1] SEQUENCE OF KerberosString
-   }
-
-   KerberosTime    ::= GeneralizedTime -- with no fractional seconds
-
-   HostAddress     ::= SEQUENCE  {
-           addr-type       [0] Int32,
-           address         [1] OCTET STRING
-   }
-
-   -- NOTE: HostAddresses is always used as an OPTIONAL field and
-   -- should not be empty.
-   HostAddresses   -- NOTE: subtly different from rfc1510,
-
-
-
-June 2004                                                     [Page 124]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-                   -- but has a value mapping and encodes the same
-           ::= SEQUENCE OF HostAddress
-
-   -- NOTE: AuthorizationData is always used as an OPTIONAL field and
-   -- should not be empty.
-   AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-           ad-type         [0] Int32,
-           ad-data         [1] OCTET STRING
-   }
-
-   PA-DATA         ::= SEQUENCE {
-           -- NOTE: first tag is [1], not [0]
-           padata-type     [1] Int32,
-           padata-value    [2] OCTET STRING -- might be encoded AP-REQ
-   }
-
-   KerberosFlags   ::= BIT STRING (SIZE (32..MAX)) -- minimum number of bits
-                       -- shall be sent, but no fewer than 32
-
-   EncryptedData   ::= SEQUENCE {
-           etype   [0] Int32 -- EncryptionType --,
-           kvno    [1] UInt32 OPTIONAL,
-           cipher  [2] OCTET STRING -- ciphertext
-   }
-
-   EncryptionKey   ::= SEQUENCE {
-           keytype         [0] Int32 -- actually encryption type --,
-           keyvalue        [1] OCTET STRING
-   }
-
-   Checksum        ::= SEQUENCE {
-           cksumtype       [0] Int32,
-           checksum        [1] OCTET STRING
-   }
-
-   Ticket          ::= [APPLICATION 1] SEQUENCE {
-           tkt-vno         [0] INTEGER (5),
-           realm           [1] Realm,
-           sname           [2] PrincipalName,
-           enc-part        [3] EncryptedData -- EncTicketPart
-   }
-
-   -- Encrypted part of ticket
-   EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
-           flags                   [0] TicketFlags,
-           key                     [1] EncryptionKey,
-           crealm                  [2] Realm,
-           cname                   [3] PrincipalName,
-
-
-
-June 2004                                                     [Page 125]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-           transited               [4] TransitedEncoding,
-           authtime                [5] KerberosTime,
-           starttime               [6] KerberosTime OPTIONAL,
-           endtime                 [7] KerberosTime,
-           renew-till              [8] KerberosTime OPTIONAL,
-           caddr                   [9] HostAddresses OPTIONAL,
-           authorization-data      [10] AuthorizationData OPTIONAL
-   }
-
-   -- encoded Transited field
-   TransitedEncoding       ::= SEQUENCE {
-           tr-type         [0] Int32 -- must be registered --,
-           contents        [1] OCTET STRING
-   }
-
-   TicketFlags     ::= KerberosFlags
-           -- reserved(0),
-           -- forwardable(1),
-           -- forwarded(2),
-           -- proxiable(3),
-           -- proxy(4),
-           -- may-postdate(5),
-           -- postdated(6),
-           -- invalid(7),
-           -- renewable(8),
-           -- initial(9),
-           -- pre-authent(10),
-           -- hw-authent(11),
-   -- the following are new since 1510
-           -- transited-policy-checked(12),
-           -- ok-as-delegate(13)
-
-   AS-REQ          ::= [APPLICATION 10] KDC-REQ
-
-   TGS-REQ         ::= [APPLICATION 12] KDC-REQ
-
-   KDC-REQ         ::= SEQUENCE {
-           -- NOTE: first tag is [1], not [0]
-           pvno            [1] INTEGER (5) ,
-           msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
-           padata          [3] SEQUENCE OF PA-DATA OPTIONAL
-                               -- NOTE: not empty --,
-           req-body        [4] KDC-REQ-BODY
-   }
-
-   KDC-REQ-BODY    ::= SEQUENCE {
-           kdc-options             [0] KDCOptions,
-           cname                   [1] PrincipalName OPTIONAL
-
-
-
-June 2004                                                     [Page 126]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-                                       -- Used only in AS-REQ --,
-           realm                   [2] Realm
-                                       -- Server's realm
-                                       -- Also client's in AS-REQ --,
-           sname                   [3] PrincipalName OPTIONAL,
-           from                    [4] KerberosTime OPTIONAL,
-           till                    [5] KerberosTime,
-           rtime                   [6] KerberosTime OPTIONAL,
-           nonce                   [7] UInt32,
-           etype                   [8] SEQUENCE OF Int32 -- EncryptionType
-                                       -- in preference order --,
-           addresses               [9] HostAddresses OPTIONAL,
-           enc-authorization-data  [10] EncryptedData OPTIONAL
-                                       -- AuthorizationData --,
-           additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
-                                           -- NOTE: not empty
-   }
-
-   KDCOptions      ::= KerberosFlags
-           -- reserved(0),
-           -- forwardable(1),
-           -- forwarded(2),
-           -- proxiable(3),
-           -- proxy(4),
-           -- allow-postdate(5),
-           -- postdated(6),
-           -- unused7(7),
-           -- renewable(8),
-           -- unused9(9),
-           -- unused10(10),
-           -- opt-hardware-auth(11),
-           -- unused12(12),
-           -- unused13(13),
-   -- 15 is reserved for canonicalize
-           -- unused15(15),
-   -- 26 was unused in 1510
-           -- disable-transited-check(26),
-   --
-           -- renewable-ok(27),
-           -- enc-tkt-in-skey(28),
-           -- renew(30),
-           -- validate(31)
-
-   AS-REP          ::= [APPLICATION 11] KDC-REP
-
-   TGS-REP         ::= [APPLICATION 13] KDC-REP
-
-   KDC-REP         ::= SEQUENCE {
-
-
-
-June 2004                                                     [Page 127]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
-           padata          [2] SEQUENCE OF PA-DATA OPTIONAL
-                                   -- NOTE: not empty --,
-           crealm          [3] Realm,
-           cname           [4] PrincipalName,
-           ticket          [5] Ticket,
-           enc-part        [6] EncryptedData
-                                   -- EncASRepPart or EncTGSRepPart,
-                                   -- as appropriate
-   }
-
-   EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
-
-   EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
-
-   EncKDCRepPart   ::= SEQUENCE {
-           key             [0] EncryptionKey,
-           last-req        [1] LastReq,
-           nonce           [2] UInt32,
-           key-expiration  [3] KerberosTime OPTIONAL,
-           flags           [4] TicketFlags,
-           authtime        [5] KerberosTime,
-           starttime       [6] KerberosTime OPTIONAL,
-           endtime         [7] KerberosTime,
-           renew-till      [8] KerberosTime OPTIONAL,
-           srealm          [9] Realm,
-           sname           [10] PrincipalName,
-           caddr           [11] HostAddresses OPTIONAL
-   }
-
-   LastReq         ::=     SEQUENCE OF SEQUENCE {
-           lr-type         [0] Int32,
-           lr-value        [1] KerberosTime
-   }
-
-   AP-REQ          ::= [APPLICATION 14] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (14),
-           ap-options      [2] APOptions,
-           ticket          [3] Ticket,
-           authenticator   [4] EncryptedData -- Authenticator
-   }
-
-   APOptions       ::= KerberosFlags
-           -- reserved(0),
-           -- use-session-key(1),
-           -- mutual-required(2)
-
-
-
-June 2004                                                     [Page 128]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   -- Unencrypted authenticator
-   Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-           authenticator-vno       [0] INTEGER (5),
-           crealm                  [1] Realm,
-           cname                   [2] PrincipalName,
-           cksum                   [3] Checksum OPTIONAL,
-           cusec                   [4] Microseconds,
-           ctime                   [5] KerberosTime,
-           subkey                  [6] EncryptionKey OPTIONAL,
-           seq-number              [7] UInt32 OPTIONAL,
-           authorization-data      [8] AuthorizationData OPTIONAL
-   }
-
-   AP-REP          ::= [APPLICATION 15] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (15),
-           enc-part        [2] EncryptedData -- EncAPRepPart
-   }
-
-   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
-           ctime           [0] KerberosTime,
-           cusec           [1] Microseconds,
-           subkey          [2] EncryptionKey OPTIONAL,
-           seq-number      [3] UInt32 OPTIONAL
-   }
-
-   KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (20),
-           safe-body       [2] KRB-SAFE-BODY,
-           cksum           [3] Checksum
-   }
-
-   KRB-SAFE-BODY   ::= SEQUENCE {
-           user-data       [0] OCTET STRING,
-           timestamp       [1] KerberosTime OPTIONAL,
-           usec            [2] Microseconds OPTIONAL,
-           seq-number      [3] UInt32 OPTIONAL,
-           s-address       [4] HostAddress,
-           r-address       [5] HostAddress OPTIONAL
-   }
-
-   KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (21),
-                           -- NOTE: there is no [2] tag
-           enc-part        [3] EncryptedData -- EncKrbPrivPart
-   }
-
-
-
-June 2004                                                     [Page 129]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-           user-data       [0] OCTET STRING,
-           timestamp       [1] KerberosTime OPTIONAL,
-           usec            [2] Microseconds OPTIONAL,
-           seq-number      [3] UInt32 OPTIONAL,
-           s-address       [4] HostAddress -- sender's addr --,
-           r-address       [5] HostAddress OPTIONAL -- recip's addr
-   }
-
-   KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (22),
-           tickets         [2] SEQUENCE OF Ticket,
-           enc-part        [3] EncryptedData -- EncKrbCredPart
-   }
-
-   EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-           ticket-info     [0] SEQUENCE OF KrbCredInfo,
-           nonce           [1] UInt32 OPTIONAL,
-           timestamp       [2] KerberosTime OPTIONAL,
-           usec            [3] Microseconds OPTIONAL,
-           s-address       [4] HostAddress OPTIONAL,
-           r-address       [5] HostAddress OPTIONAL
-   }
-
-   KrbCredInfo     ::= SEQUENCE {
-           key             [0] EncryptionKey,
-           prealm          [1] Realm OPTIONAL,
-           pname           [2] PrincipalName OPTIONAL,
-           flags           [3] TicketFlags OPTIONAL,
-           authtime        [4] KerberosTime OPTIONAL,
-           starttime       [5] KerberosTime OPTIONAL,
-           endtime         [6] KerberosTime OPTIONAL,
-           renew-till      [7] KerberosTime OPTIONAL,
-           srealm          [8] Realm OPTIONAL,
-           sname           [9] PrincipalName OPTIONAL,
-           caddr           [10] HostAddresses OPTIONAL
-   }
-
-   KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (30),
-           ctime           [2] KerberosTime OPTIONAL,
-           cusec           [3] Microseconds OPTIONAL,
-           stime           [4] KerberosTime,
-           susec           [5] Microseconds,
-           error-code      [6] Int32,
-           crealm          [7] Realm OPTIONAL,
-
-
-
-June 2004                                                     [Page 130]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-           cname           [8] PrincipalName OPTIONAL,
-           realm           [9] Realm -- service realm --,
-           sname           [10] PrincipalName -- service name --,
-           e-text          [11] KerberosString OPTIONAL,
-           e-data          [12] OCTET STRING OPTIONAL
-   }
-
-   METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-   TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-           data-type       [0] INTEGER,
-           data-value      [1] OCTET STRING OPTIONAL
-   }
-
-   -- preauth stuff follows
-
-   PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
-
-   PA-ENC-TS-ENC           ::= SEQUENCE {
-           patimestamp     [0] KerberosTime -- client's time --,
-           pausec          [1] Microseconds OPTIONAL
-   }
-
-   ETYPE-INFO-ENTRY        ::= SEQUENCE {
-           etype           [0] Int32,
-           salt            [1] OCTET STRING OPTIONAL
-   }
-
-   ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
-
-   ETYPE-INFO2-ENTRY       ::= SEQUENCE {
-           etype           [0] Int32,
-           salt            [1] KerberosString OPTIONAL,
-           s2kparams       [2] OCTET STRING OPTIONAL
-   }
-
-   ETYPE-INFO2             ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
-
-   AD-IF-RELEVANT          ::= AuthorizationData
-
-   AD-KDCIssued            ::= SEQUENCE {
-           ad-checksum     [0] Checksum,
-           i-realm         [1] Realm OPTIONAL,
-           i-sname         [2] PrincipalName OPTIONAL,
-           elements        [3] AuthorizationData
-   }
-
-   AD-AND-OR               ::= SEQUENCE {
-
-
-
-June 2004                                                     [Page 131]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-           condition-count [0] INTEGER,
-           elements        [1] AuthorizationData
-   }
-
-   AD-MANDATORY-FOR-KDC    ::= AuthorizationData
-
-   END
-
-B. Changes since RFC-1510
-
-   This document replaces RFC-1510 and clarifies specification of items
-   that were not completely specified. Where changes to recommended
-   implementation choices were made, or where new options were added,
-   those changes are described within the document and listed in this
-   section. More significantly, "Specification 2" in section 8 changes
-   the required encryption and checksum methods to bring them in line
-   with the best current practices and to deprecate methods that are no
-   longer considered sufficiently strong.
-
-   Discussion was added to section 1 regarding the ability to rely on
-   the KDC to check the transited field, and on the inclusion of a flag
-   in a ticket indicating that this check has occurred. This is a new
-   capability not present in RFC1510. Pre-existing implementations may
-   ignore or not set this flag without negative security implications.
-
-   The definition of the secret key says that in the case of a user the
-   key may be derived from a password. In 1510, it said that the key was
-   derived from the password. This change was made to accommodate
-   situations where the user key might be stored on a smart-card, or
-   otherwise obtained independent of a password.
-
-   The introduction mentions the use of public key cryptography for
-   initial authentication in Kerberos by reference. RFC1510 did not
-   include such a reference.
-
-   Section 1.2 was added to explain that while Kerberos provides
-   authentication of a named principal, it is still the responsibility
-   of the application to ensure that the authenticated name is the
-   entity with which the application wishes to communicate.
-
-   Discussion of extensibility has been added to the introduction.
-
-   Discussion of how extensibility affects ticket flags and KDC options
-   was added to the introduction of section 2. No changes were made to
-   existing options and flags specified in RFC1510, though some of the
-   sections in the specification were renumbered, and text was revised
-   to make the description and intent of existing options clearer,
-   especially with respect to the ENC-TKT-IN-SKEY option (now section
-
-
-
-June 2004                                                     [Page 132]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   2.9.2) which is used for user-to-user authentication.  The new option
-   and ticket flag transited policy checking (section 2.7) was added.
-
-   A warning regarding generation of session keys for application use
-   was added to section 3, urging the inclusion of key entropy from the
-   KDC generated session key in the ticket. An example regarding use of
-   the sub-session key was added to section 3.2.6. Descriptions of the
-   pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data
-   items were added. The recommendation for use of pre-authentication
-   was changed from "may" to "should" and a note was added regarding
-   known plaintext attacks.
-
-   In RFC 1510, section 4 described the database in the KDC. This
-   discussion was not necessary for interoperability and unnecessarily
-   constrained implementation. The old section 4 was removed.
-
-   The current section 4 was formerly section 6 on encryption and
-   checksum specifications. The major part of this section was brought
-   up to date to support new encryption methods, and move to a separate
-   document. Those few remaining aspects of the encryption and checksum
-   specification specific to Kerberos are now specified in section 4.
-
-   Significant changes were made to the layout of section 5 to clarify
-   the correct behavior for optional fields. Many of these changes were
-   made necessary because of improper ASN.1 description in the original
-   Kerberos specification which left the correct behavior
-   underspecified. Additionally, the wording in this section was
-   tightened wherever possible to ensure that implementations conforming
-   to this specification will be extensible with the addition of new
-   fields in future specifications.
-
-   Text was added describing time_t=0 issues in the ASN.1. Text was also
-   added, clarifying issues with implementations treating omitted
-   optional integers as zero. Text was added clarifying behavior for
-   optional SEQUENCE or SEQUENCE OF that may be empty. Discussion was
-   added regarding sequence numbers and behavior of some
-   implementations, including "zero" behavior and negative numbers. A
-   compatibility note was added regarding the unconditional sending of
-   EncTGSRepPart regardless of the enclosing reply type. Minor changes
-   were made to the description of the HostAddresses type. Integer types
-   were constrained. KerberosString was defined as a (significantly)
-   constrained GeneralString. KerberosFlags was defined to reflect
-   existing implementation behavior that departs from the definition in
-   RFC 1510. The transited-policy-checked(12) and the ok-as-delegate(13)
-   ticket flags were added. The disable-transited-check(26) KDC option
-   was added.
-
-   Descriptions of commonly implemented PA-DATA were added to section 5.
-
-
-
-June 2004                                                     [Page 133]
-
-
-
-
-
-Neuman, et al.    draft-ietf-krb-wg-kerberos-clarifications-06.txt DRAFT
-
-
-   The description of KRB-SAFE has been updated to note the existing
-   implementation behavior of double-encoding.
-
-   There were two definitions of METHOD-DATA in RFC 1510. The second
-   one, intended for use with KRB_AP_ERR_METHOD was removed leaving the
-   SEQUENCE OF PA-DATA definition.
-
-   Section 7, naming constraints, from RFC1510 was moved to section 6.
-
-   Words were added describing the convention that domain based realm
-   names for newly created realms should be specified as upper case.
-   This recommendation does not make lower case realm names illegal.
-   Words were added highlighting that the slash separated components in
-   the X500 style of realm names is consistent with existing RFC1510
-   based implementations, but that it conflicts with the general
-   recommendation of X.500 name representation specified in RFC2253.
-
-   Section 8, network transport, constants and defined values, from
-   RFC1510 was moved to section 7.  Since RFC1510, the definition of the
-   TCP transport for Kerberos messages was added, and the encryption and
-   checksum number assignments have been moved into a separate document.
-
-   "Specification 2" in section 8 of the current document changes the
-   required encryption and checksum methods to bring them in line with
-   the best current practices and to deprecate methods that are no
-   longer considered sufficiently strong.
-
-   Two new sections, on IANA considerations and security considerations
-   were added.
-
-   The pseudo-code has been removed from the appendix. The pseudo-code
-   was sometimes misinterpreted to limit implementation choices and in
-   RFC 1510, it was not always consistent with the words in the
-   specification. Effort was made to clear up any ambiguities in the
-   specification, rather than to rely on the pseudo-code.
-
-   An appendix was added containing the complete ASN.1 module drawn from
-   the discussion in section 5 of the current document.
-
-END NOTES
-
-   (*TM) Project Athena, Athena, and Kerberos are trademarks of the
-   Massachusetts Institute of Technology (MIT). No commercial use of
-   these trademarks may be made without prior written permission of MIT.
-
-
-
-
-
-
-
-June 2004                                                     [Page 134]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-00.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-00.txt
deleted file mode 100644
index 5845995f2..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-00.txt
+++ /dev/null
@@ -1,725 +0,0 @@
-
-
-Kerberos Working Group                                         M. Swift 
-Internet Draft                                         University of WA 
-Document: draft-ietf-krb-wg-kerberos-referrals-00.txt         J. Brezak 
-Category: Standards Track                                     Microsoft 
-                                                             J. Trostle 
-                                                          Cisco Systems 
-                                                             K. Raeburn 
-                                                                    MIT 
-                                                          February 2001 
-
- 
-           Generating KDC Referrals to locate Kerberos realms 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1].  
-    
-   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."  
-    
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   The draft documents a new method for a Kerberos Key Distribution 
-   Center (KDC) to respond to client requests for kerberos tickets when 
-   the client does not have detailed configuration information on the 
-   realms of users or services. The KDC will handle requests for 
-   principals in other realms by returning either a referral error or a 
-   cross-realm TGT to another realm on the referral path. The clients 
-   will use this referral information to reach the realm of the target 
-   principal and then receive the ticket. 
-    
-2. Conventions used in this document 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-    
-3. Introduction 
-    
-
-
-  
-Swift                 Category - Standards Track                     1 
-
-
-
-
-
-
-
-
-                            KDC Referrals               February 2001 
- 
- 
-   Current implementations of the Kerberos AS and TGS protocols, as 
-   defined in RFC 1510 [3], use principal names constructed from a 
-   known user or service name and realm. A service name is typically 
-   constructed from a name of the service and the DNS host name of the 
-   computer that is providing the service. Many existing deployments of 
-   Kerberos use a single Kerberos realm where all users and services 
-   would be using the same realm. However in an environment where there 
-   are multiple trusted Kerberos realms, the client needs to be able to 
-   determine what realm a particular user or service is in before 
-   making an AS or TGS request. Traditionally this requires client 
-   configuration to make this possible. 
-    
-   When having to deal with multiple trusted realms, users are forced 
-   to know what realm they are in before they can obtain a ticket 
-   granting ticket (TGT) with an AS request. However, in many cases the 
-   user would like to use a more familiar name that is not directly 
-   related to the realm of their Kerberos principal name. A good 
-   example of this is an RFC-822 style email name. This document 
-   describes a mechanism that would allow a user to specify a user 
-   principal name that is an alias for the user's Kerberos principal 
-   name. In practice this would be the name that the user specifies to 
-   obtain a TGT from a Kerberos KDC. The user principal name no longer 
-   has a direct relationship with the Kerberos principal or realm. Thus 
-   the administrator is able to move the user's principal to other 
-   realms without the user having to know that it happened. 
-    
-   Once a user has a TGT, they would like to be able to access services 
-   in any trusted Kerberos realm. To do this requires that the client 
-   be able to determine what realm the target service's host is in 
-   before making the TGS request. Current implementations of Kerberos 
-   typically have a table that maps DNS host names to corresponding 
-   Kerberos realms. In order for this to work on the client, each 
-   application canonicalizes the host name of the service by doing a 
-   DNS lookup followed by a reverse lookup using the returned IP 
-   address. The returned primary host name is then used in the 
-   construction of the principal name for the target service. In order 
-   for the correct realm to be added for the target host, the mapping 
-   table [domain_to_realm] is consulted for the realm corresponding to 
-   the DNS host name. The corresponding realm is then used to complete 
-   the target service principal name. 
-    
-   This traditional mechanism requires that each client have very 
-   detailed configuration information about the hosts that are 
-   providing services and their corresponding realms. Having client 
-   side configuration information can be very costly from an 
-   administration point of view - especially if there are many realms 
-   and computers in the environment. 
-    
-   Current implementations of Kerberos also have difficulty with 
-   services on hosts that can have multiple host names (multi-homed 
-   hosts). Traditionally, each host name would need to have a distinct 
-   principal and a corresponding key. An extreme example of this would 
-   be a Web server with multiple host names for each domain that it is 
-  
-Swift                 Category - Standards Track                     2 
-
-
-
-
-
-
-
-
-                            KDC Referrals               February 2001 
- 
- 
-   supporting. Principal aliases allow multi-homed hosts to have a 
-   single Kerberos principal (with a single key) that can have 
-   identities for each distinct host name. This mechanism allows the 
-   Kerberos client to request a service ticket for the distinct 
-   hostname and allows the KDC to return a ticket for the single 
-   principal that the host is using. This canonical principal name 
-   allows the host to only have to manage a single key for all of the 
-   identities that it supports. In addition, the client only needs to 
-   know the realm of the canonical service name, not all of the 
-   identities. 
-    
-   This draft proposes a solution for these problems and simplifies 
-   administration by minimizing the configuration information needed on 
-   each computer using Kerberos. Specifically it describes a mechanism 
-   to allow the KDC to handle Canonicalization of names, provide for 
-   principal aliases for users and services and provide a mechanism for 
-   the KDC to determine the trusted realm authentication path by being 
-   able to generate referrals to other realms in order to locate 
-   principals. 
-    
-   To rectify these problems, this draft introduces three new kinds of   
-   KDC referrals: 
-        
-   1. AS ticket referrals, in which the client doesn't know which realm 
-      contains a user account.  
-   2. TGS ticket referrals, in which the client doesn't know which 
-      realm contains a server account.  
-   3. Cross realm shortcut referrals, in which the KDC chooses the next 
-      path on a referral chain 
-    
-4. Realm Organization Model 
-    
-   This draft assumes that the world of principals is arranged on 
-   multiple levels: the realm, the enterprise, and the world. A KDC may 
-   issue tickets for any principal in its realm or cross-realm tickets 
-   for realms with which it has a direct trust relationship. The KDC 
-   also has access to a trusted name service that can resolve any name 
-   from within its enterprise into a realm. This trusted name service 
-   removes the need to use an untrusted DNS lookup for name resolution. 
-    
-   For example, consider the following configuration, where lines 
-   indicate trust relationships: 
-    
-                  MS.COM  
-                /        \ 
-               /          \ 
-        OFFICE.MS.COM    NT.MS.COM 
-    
-   In this configuration, all users in the MS.COM enterprise could have 
-   a principal name such as alice@MS.COM, with the same realm portion. 
-   In addition, servers at MS.COM should be able to have DNS host names 
-   from any DNS domain independent of what Kerberos realm their 
-   principal resides in. 
-  
-Swift                 Category - Standards Track                     3 
-
-
-
-
-
-
-
-
-                            KDC Referrals               February 2001 
- 
- 
-    
-5. Principal Names 
-    
-5.1 Service Principal Names 
-    
-   The standard Kerberos model in RFC 1510 [3] gives each Kerberos 
-   principal a single name. However, if a service is reachable by 
-   several addresses, it is useful for a principal to have multiple 
-   names. Consider a service running on a multi-homed machine. Rather 
-   than requiring a separate principal and password for each name it 
-   exports, a single account with multiple names could be used. 
-    
-   Multiple names are also useful for services in that clients need not 
-   perform DNS lookups to resolve a host name into a full DNS address. 
-   Instead, the service may have a name for each of its supported host 
-   names, including its IP address. Nonetheless, it is still convenient 
-   for the service to not have to be aware of all these names. Thus a 
-   new name may be added to DNS for a service by updating DNS and the 
-   KDC database without having to notify the service. In addition, it 
-   implies that these aliases are globally unique: they do not include 
-   a specifier dictating what realm contains the principal. Thus, an 
-   alias for a server is of the form "class/instance/name" and may be 
-   transmitted as any name type. 
-    
-5.2 Client Principal Names 
-    
-   Similarly, a client account may also have multiple principal names. 
-   More useful, though, is a globally unique name that allows 
-   unification of email and security principal names. For example, all 
-   users at MS may have a client principal name of the form 
-   "joe@MS.COM" even though the principals are contained in multiple 
-   realms. This global name is again an alias for the true client 
-   principal name, which is indicates what realm contains the 
-   principal. Thus, accounts "alice" in the realm ntdev.MS.COM and 
-   "bob" in office.MS.COM may logon as "alice@MS.COM" and "bob@MS.COM". 
-   This requires a new client principal name type, as the AS-REQ 
-   message only contains a single realm field, and the realm portion of 
-   this name doesn't correspond to any Kerberos realm. Thus, the entire 
-   name "alice@MS.COM" is transmitted in the client name field of the 
-   AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL. 
-    
-        KRB-NT-ENTERPRISE-PRINCIPAL     10 
-    
-5.3 Name Canonicalization 
-    
-   In order to support name aliases, the Kerberos client must 
-   explicitly request the name-canonicalization KDC option (bit 15) in 
-   the ticket flags for the TGS-REQ. This flag indicates to the KDC 
-   that the client is prepared to receive a reply with a different 
-   client or server principal name than the request. Thus, the 
-   KDCOptions types is redefined as: 
-    
-        KDCOptions ::=   BIT STRING { 
-  
-Swift                 Category - Standards Track                     4 
-
-
-
-
-
-
-
-
-                            KDC Referrals               February 2001 
- 
- 
-                          reserved(0), 
-                          forwardable(1), 
-                          forwarded(2), 
-                          proxiable(3), 
-                          proxy(4), 
-                          allow-postdate(5), 
-                          postdated(6), 
-                          unused7(7), 
-                          renewable(8), 
-                          unused9(9), 
-                          unused10(10), 
-                          unused11(11), 
-                          name-canonicalize(15), 
-                          renewable-ok(27), 
-                          enc-tkt-in-skey(28), 
-                          renew(30), 
-                          validate(31) 
-         } 
-    
-6. Client Referrals 
-    
-   The simplest form of ticket referral is for a user requesting a 
-   ticket using an AS-REQ. In this case, the client machine will send 
-   the AS request to a convenient trusted realm, either the realm of 
-   the client machine or the realm of the client name. In the case of 
-   the name Alice@MS.COM, the client may optimistically choose to send 
-   the request to MS.COM. 
-    
-   The client will send the string "alice@MS.COM" in the client 
-   principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type 
-   with the crealm set to MS.COM. The KDC will try to lookup the name 
-   in its local account database. If the account is present in the 
-   crealm of the request, it MUST return a KDC reply structure with the 
-   appropriate ticket. If the account is not present in the crealm 
-   specified in the request and the name-canonicalize flag in the 
-   KDCoptions is set, the KDC will try to lookup the entire name, 
-   Alice@MS.COM, using a name service. If this lookup is unsuccessful, 
-   it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup 
-   is successful, it MUST return an error KDC_ERR_WRONG_REALM (0x44) 
-   and in the error message the cname and crealm field MUST contain the 
-   client name and the true realm of the client. If the KDC contains 
-   the account locally, it MUST return a normal ticket. The client name 
-   and realm portions of the ticket and KDC reply message MUST be the 
-   client's true name in the realm, not the globally unique name. 
-    
-   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 
-   new AS request with the same client principal name used to generate 
-   the first referral to the realm specified by the crealm field of the 
-   kerberos error message from the first request. This request MUST 
-   produce a valid AS response with a ticket for the canonical user 
-   name. The ticket MUST also include the ticket extension containing 
-   the TE-REFERRAL-DATA with the referred-names set to the name from 
-
-  
-Swift                 Category - Standards Track                     5 
-
-
-
-
-
-
-
-
-                            KDC Referrals               February 2001 
- 
- 
-   the AS request. Any other error or referral will terminate the 
-   request and result in a failed AS request. 
-    
-7. Server Referrals 
-    
-   The server referral mechanism is a bit more complex than the client 
-   referral mechanism. The primary problem is that the KDC must return 
-   a referral ticket rather than an error message, so it will include 
-   in the TGS response information about what realm contains the 
-   service. This is done by returning information about the server name 
-   in the pre-auth data field of the KDC reply. 
-    
-   If the KDC resolves the server principal name into a principal in 
-   its realm, it may return a normal ticket. If the name-canonicalize 
-   flag in the KDCoptions is not set, then the KDC MUST only look up 
-   the name as a normal principal name. Otherwise, it MUST search all 
-   aliases as well. The server principal name in both the ticket and 
-   the KDC reply MUST be the true server principal name instead of one 
-   of the aliases. This frees the application server from needing to 
-   know about all its aliases. 
-    
-   If the name-canonicalize flag in the KDCoptions is set and the KDC 
-   doesn't find the principal locally, the KDC can return a cross-realm 
-   ticket granting ticket to the next hop on the trust path towards a 
-   realm that may be able to resolve the principal name. 
-    
-   If the KDC can determine the service principal's realm, it can 
-   return the server realm as ticket extension data. The ticket 
-   extension MUST be encrypted using the session key from the ticket, 
-   and the same etype as is used to protect the TGS reply body. 
-    
-   The data itself is an ASN.1 encoded structure containing the 
-   server's realm, and if known, canonical principal name and alias 
-   names. The first name in the sequence is the canonical principal 
-   name. 
-    
-                TE-REFERRAL-INFO        20 
-                 
-                TE-REFERRAL-DATA ::= SEQUENCE { 
-                        referred-server-realm[0]  KERB-REALM 
-                        referred-names[1]         SEQUENCE OF 
-                        PrincipalNames OPTIONAL 
-                } 
-    
-    
-   The client can use this information to request a chain of cross-
-   realm ticket granting tickets until it reaches the realm of the 
-   server, and can then expect to receive a valid service ticket. 
-    
-   In order to facilitate cross-realm interoperability, a client SHOULD 
-   NOT send short names in TGS requests to the KDC. A short name is 
-   defined as a Kerberos name that includes a DNS name that is not 
-   fully qualified. The client MAY use forward DNS lookups to obtain 
-  
-Swift                 Category - Standards Track                     6 
-
-
-
-
-
-
-
-
-                            KDC Referrals               February 2001 
- 
- 
-   the long name that corresponds to the user entered short name (the 
-   short name will be a prefix of the corresponding long name). 
-    
-   The client may use the referred-names field to tell if it already 
-   has a ticket to the server in its ticket cache. 
-    
-   The client can use this information to request a chain of cross-
-   realm ticket granting tickets until it reaches the realm of the 
-   server, and can then expect to receive a valid service ticket. 
-   However an implementation should limit the number of referrals that 
-   it processes to avoid infinite referral loops. A suggested limit is 
-   5 referrals before giving up. 
-    
-8. Cross Realm Routing 
-    
-   The current Kerberos protocol requires the client to explicitly 
-   request a cross-realm TGT for each pair of realms on a referral 
-   chain. As a result, the client machines need to be aware of the 
-   trust hierarchy and of any short-cut trusts (those that aren't 
-   parent-child trusts). This requires more configurations on the 
-   client. Instead, the client should be able to request a TGT to the 
-   target realm from each realm on the route. The KDC will determine 
-   the best path for the client and return a cross-realm TGT. The 
-   client has to be aware that a request for a cross-realm TGT may 
-   return a TGT for a realm different from the one requested. 
-    
-9. Security Considerations 
- 
-   The original Kerberos specification stated that the server principal 
-   name in the KDC reply was the same as the server name in the 
-   request. These protocol changes break that assumption, so the client 
-   may be vulnerable to a denial of service attack by an attacker that 
-   replays replies from previous requests. It can verify that the 
-   request was one of its own by checking the client-address field or 
-   authtime field, though, so the damage is limited and detectable. 
-    
-   For the AS exchange case, it is important that the logon mechanism 
-   not trust a name that has not been used to authenticate the user. 
-   For example, the name that the user enters as part of a logon 
-   exchange may not be the name that the user authenticates as, given 
-   that the KDC_ERR_WRONG_REALM error may have been returned. The 
-   relevant Kerberos naming information for logon (if any), is the 
-   client name and client realm in the service ticket targeted at the 
-   workstation that was obtained using the user's initial TGT. 
-    
-   How the client name and client realm is mapped into a local account 
-   for logon is a local matter, but the client logon mechanism MUST use 
-   additional information such as the client realm and/or authorization 
-   attributes from the service ticket presented to the workstation by 
-   the user, when mapping the logon credentials to a local account on 
-   the workstation. 
-    
-10. Discussion 
-  
-Swift                 Category - Standards Track                     7 
-
-
-
-
-
-
-
-
-                            KDC Referrals               February 2001 
- 
- 
- 
-   This section contains issues and suggestions that need to be 
-   incorporated into this draft. From Ken Raeburn [raeburn@mit.edu]: 
-    
-   1) No means to do name canonicalization if you're not 
-      authenticating. Is it okay to require credentials in order to do 
-      canonicalization? If so, how about this: Send a TGS_REQ for the 
-      service name you have.  If you get back a TGS_REP for a service, 
-      great; pull out the name and throw out the credentials.  If you 
-      get back a TGS_REP for a TGT service, ask again in the specified 
-      realm.  If you get back a KRB_ERROR because policy prohibits you 
-      from authenticating to that service, we can add to the 
-      specification that the {realm,sname} in the KRB_ERROR must be the 
-      canonical name, and the checksum must be used.  As long as the 
-      checksum is present, it's still a secure exchange with the KDC.  
-       
-      If we have to be able to do name canonicalization without any 
-      sort of credentials, either client-side (tickets) or server-side 
-      (tickets automatically acquired via service key), I think we just 
-      lose. But maybe GSSAPI should be changed if that's the case. 
-    
-   2) Can't refer to another realm and specify a different service name 
-      to give to that realm's KDC.  The local KDC can tell you a 
-      different service name or a different realm name, but not both. 
-      This comes up in the "gnuftp.raeburn.org CNAME ftp.gnu.org" type 
-      of case I've mentioned. 
-       
-      Except ... the KDC-REP structure includes padata and ticket 
-      extensions fields that are extensible.  We could add a required 
-      value to one of them -- perhaps only in the case where you return 
-      a TGT when not asked -- that contains signed information about 
-      the principal name to ask for in the other realm.  (It would have 
-      to be required, otherwise a man-in-the-middle could make it go 
-      away.) Signing would be done using the session key for the TGS. 
-    
-   3) Secure canonicalization of service name in AS_REQ. If the 
-      response is an AS_REP, we need a way to tell that the altered 
-      server name wasn't a result of a MITM attack on the AS_REQ 
-      message.  Again, the KDC-REP extensible fields could have a new 
-      required value added when name canonicalization happens, 
-      indicating what the original principal name (in the AS_REQ 
-      message) was, and signed using the same key as protects the 
-      AS_REP.  If it doesn't match what the client requested, the 
-      messages were altered in transit. 
-    
-   4) Client name needs referral to another realm, and server name 
-      needs canonicalization of some sort. The above fixes wouldn't 
-      work for this case, and I'm not even sure which KDC should be 
-      doing the canonicalization anyways. 
-    
-    
-   The other-principal-name datum would probably look something like: 
-    
-  
-Swift                 Category - Standards Track                     8 
-
-
-
-
-
-
-
-
-                            KDC Referrals               February 2001 
- 
- 
-       PrincipalAndNonce ::= SEQUENCE { 
-                    name[0]     PrincipalName, 
-                    nonce[1]    INTEGER         -- copied from KDC_REQ 
-       } 
-       SignedPrincipal ::= SEQUENCE { 
-                    name-and-nonce[0]   PrincipalAndNonce, 
-                    cksum[1]    Checksum 
-       } 
-       {PA,TE}-ORIGINAL-SERVER-PRINCIPAL ::= SignedPrincipal 
-       {PA,TE}-REMOTE-SERVER-PRINCIPAL ::= SignedPrincipal 
-    
-   with the checksum computed over the encoding of the 'name-and-nonce' 
-   field, and appropriate PA- or TE- numbers assigned.  I don't have a 
-   strong opinion on whether it'd be a pa-data or ticket extension; 
-   conceptually it seems like an abuse of either, but, well, I think 
-   I'd rather abuse them than leave the facility both in and 
-   inadequate. 
-    
-   The nonce is needed because multiple exchanges may be made with the 
-   same key, and these extension fields aren't packed in with the other 
-   encrypted data in the same response, so a MITM could pick apart 
-   multiple messages and mix-and-match components.  (In a TGS_REQ 
-   exchange, a subsession key would help, but it's not required.) 
-    
-   The extension field would be required to prevent a MITM from 
-   discarding the field from a response; a flag bit in a protected part 
-   of the message (probably in 'flags' in EncKDCRepPart) could also let 
-   us know of a cases where the information can be omitted, namely, 
-   when no name change is done.  Perhaps the bit should be set to 
-   indicate that a name change *was* done, and clear if it wasn't, 
-   making the no-change case more directly compatible with RFC1510. 
- 
-11. References 
-    
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   3  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
-      Service (V5)", RFC 1510, September 1993 
-    
-    
-12. Author's Addresses 
-    
-   Michael Swift 
-   University of Washington 
-   Seattle, Washington 
-   Email: mikesw@cs.washington.edu 
-    
-   John Brezak 
-  
-Swift                 Category - Standards Track                     9 
-
-
-
-
-
-
-
-
-                            KDC Referrals               February 2001 
- 
- 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@Microsoft.com 
-    
-   Jonathan Trostle 
-   Cisco Systems 
-   170 W. Tasman Dr. 
-   San Jose, CA 95134 
-   Email: jtrostle@cisco.com 
-    
-   Kenneth Raeburn 
-   Massachusetts Institute of Technology 77 
-   Massachusetts Avenue 
-   Cambridge, Massachusetts 02139 
-   Email: raeburn@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                 Category - Standards Track                    10 
-
-
-
-
-
-
-
-
-                            KDC Referrals               February 2001 
- 
- 
-   Full Copyright Statement 
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this   
-   document itself may not be modified in any way, such as by removing   
-   the copyright notice or references to the Internet Society or other   
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
-    
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                 Category - Standards Track                    11 
-
-
-
-
-
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-03.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-03.txt
deleted file mode 100644
index cbe294482..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-03.txt
+++ /dev/null
@@ -1,638 +0,0 @@
-
-
-
-Kerberos Working Group                                          Karthik 
-                                                             Jaganathan 
-Internet Draft                                                Larry Zhu 
-Document: draft-ietf-krb-wg-kerberos-referrals-03.txt       John Brezak 
-Category: Standards Track                                     Microsoft 
-                                                             Mike Swift 
-                                                          University of  
-                                                             Washington 
-                                                       Jonathan Trostle 
-                                                          Cisco Systems 
-                                                        Expires: August 
-                                                                   2004 
- 
- 
-           Generating KDC Referrals to locate Kerberos realms 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1].  
-    
-   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."  
-    
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   The draft documents a new method for a Kerberos Key Distribution 
-   Center (KDC) to respond to client requests for kerberos tickets when 
-   the client does not have detailed configuration information on the 
-   realms of users or services. The KDC will handle requests for 
-   principals in other realms by returning either a referral error or a 
-   cross-realm TGT to another realm on the referral path. The clients 
-   will use this referral information to reach the realm of the target 
-   principal and then receive the ticket. 
-    
-2. Conventions used in this document 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-    
-
-  
-Jaganathan            Category - Standards Track                     1 
-                            KDC Referrals                 August 2004 
- 
- 
-3. Introduction 
-    
-   Current implementations of the Kerberos AS and TGS protocols, as 
-   defined in [3], use principal names constructed from a known user or 
-   service name and realm. A service name is typically constructed from 
-   a name of the service and the DNS host name of the computer that is 
-   providing the service. Many existing deployments of Kerberos use a 
-   single Kerberos realm where all users and services would be using 
-   the same realm. However in an environment where there are multiple 
-   trusted Kerberos realms, the client needs to be able to determine 
-   what realm a particular user or service is in before making an AS or 
-   TGS request. Traditionally this requires client configuration to 
-   make this possible. 
-    
-   When having to deal with multiple trusted realms, users are forced 
-   to know what realm they are in before they can obtain a ticket 
-   granting ticket (TGT) with an AS request. However, in many cases the 
-   user would like to use a more familiar name that is not directly 
-   related to the realm of their Kerberos principal name. A good 
-   example of this is an RFC-822 style email name. This document 
-   describes a mechanism that would allow a user to specify a user 
-   principal name that is an alias for the user's Kerberos principal 
-   name. In practice this would be the name that the user specifies to 
-   obtain a TGT from a Kerberos KDC. The user principal name no longer 
-   has a direct relationship with the Kerberos principal or realm. Thus 
-   the administrator is able to move the user's principal to other 
-   realms without the user having to know that it happened. 
-    
-   Once a user has a TGT, they would like to be able to access services 
-   in any trusted Kerberos realm. To do this requires that the client 
-   be able to determine what realm the target service's host is in 
-   before making the TGS request. Current implementations of Kerberos 
-   typically have a table that maps DNS host names to corresponding 
-   Kerberos realms. In order for this to work on the client, each 
-   application canonicalizes the host name of the service by doing a 
-   DNS lookup followed by a reverse lookup using the returned IP 
-   address. The returned primary host name is then used in the 
-   construction of the principal name for the target service. In order 
-   for the correct realm to be added for the target host, the mapping 
-   table [domain_to_realm] is consulted for the realm corresponding to 
-   the DNS host name. The corresponding realm is then used to complete 
-   the target service principal name. 
-    
-   This traditional mechanism requires that each client have very 
-   detailed configuration information about the hosts that are 
-   providing services and their corresponding realms. Having client 
-   side configuration information can be very costly from an 
-   administration point of view - especially if there are many realms 
-   and computers in the environment. 
-    
-   There are also cases where specific DNS aliases (local names) have 
-   been setup in an organization to refer to a server in another 
-   organization (remote server). The server has different DNS names in 
-  
-Jaganathan            Category - Standards Track                     2 
-                            KDC Referrals                 August 2004 
- 
- 
-   each organization and each organization has a Kerberos realm that is 
-   configured to service DNS names within that organization. Ideally 
-   users are able to authenticate to the server in the other 
-   organization using the local server name. This would mean that the 
-   local realm be able to produce a ticket to the remote server under 
-   its name. You could give that remote server an identity in the local 
-   realm and then have that remote server maintain a separate secret 
-   for each alias it is known as. Alternatively you could arrange to 
-   have the local realm issue a referral to the remote realm and notify 
-   the requesting client of the server's remote name that should be 
-   used in order to request a ticket. 
-    
-   This draft proposes a solution for these problems and simplifies 
-   administration by minimizing the configuration information needed on 
-   each computer using Kerberos. Specifically it describes a mechanism 
-   to allow the KDC to handle Canonicalization of names, provide for 
-   principal aliases for users and services and provide a mechanism for 
-   the KDC to determine the trusted realm authentication path by being 
-   able to generate referrals to other realms in order to locate 
-   principals. 
-    
-   To rectify these problems, this draft introduces three new kinds of   
-   KDC referrals: 
-        
-   1. AS ticket referrals, in which the client doesn't know which realm 
-      contains a user account.  
-   2. TGS ticket referrals, in which the client doesn't know which 
-      realm contains a server account.  
-   3. Cross realm shortcut referrals, in which the KDC chooses the next 
-      path on a referral chain 
-    
-4. Realm Organization Model 
-    
-   This draft assumes that the world of principals is arranged on 
-   multiple levels: the realm, the enterprise, and the world. A KDC may 
-   issue tickets for any principal in its realm or cross-realm tickets 
-   for realms with which it has a direct trust relationship. The KDC 
-   also has access to a trusted name service that can resolve any name 
-   from within its enterprise into a realm. This trusted name service 
-   removes the need to use an untrusted DNS lookup for name resolution. 
-    
-   For example, consider the following configuration, where lines 
-   indicate trust relationships: 
-    
-                  MS.COM  
-                /        \ 
-               /          \ 
-        OFFICE.MS.COM    NT.MS.COM 
-    
-   In this configuration, all users in the MS.COM enterprise could have 
-   a principal name such as alice@MS.COM, with the same realm portion. 
-   In addition, servers at MS.COM should be able to have DNS host names 
-
-  
-Jaganathan            Category - Standards Track                     3 
-                            KDC Referrals                 August 2004 
- 
- 
-   from any DNS domain independent of what Kerberos realm their 
-   principal resides in. 
-    
-5. Client Name Canonicalization 
-    
-   A client account may have multiple principal names. More useful, 
-   though, is a globally unique name that allows unification of email 
-   and security principal names. For example, all users at MS may have 
-   a client principal name of the form "joe@MS.COM" even though the 
-   principals are contained in multiple realms. This global name is 
-   again an alias for the true client principal name, which indicates 
-   what realm contains the principal. Thus, accounts "alice" in the 
-   realm NT.MS.COM and "bob" in OFFICE.MS.COM may logon as 
-   "alice@MS.COM" and "bob@MS.COM". 
-    
-   This utilizes a new client principal name type, as the AS-REQ 
-   message only contains a single realm field, and the realm portion of 
-   this name doesn't correspond to any Kerberos realm. Thus, the entire 
-   name "alice@MS.COM" is transmitted in the client name field of the 
-   AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL. 
-    
-        KRB-NT-ENTERPRISE-PRINCIPAL     10 
-    
-   The KDC will recognize this name type and then transform the 
-   requested name into the true principal name. The true principal name 
-   can be using a name type different from the requested name type. 
-   Typically the returned principal name will be a KRB-NT-PRINCIPAL. 
-   The returned name will be the same in the AS response and in the 
-   ticket. The KDC will always return a different name type than KRB-
-   NT-ENTERPRISE-PRINCIPAL. This is regardless of the presence of the 
-   "canonicalize" KDC option. 
-    
-   If the "canonicalize" KDC option is set, then the KDC MAY change the 
-   client principal name and type in the AS response and ticket 
-   regardless of the name type of the client name in the request. For 
-   example the AS request may specify a client name of "fred@MS.COM" as 
-   an KRB-NT-PRINCIPAL with the "canonicalize" KDC option set and the 
-   KDC will return with a client name of "104567" as a KRB-NT-UID. 
-     
-6. Requesting a referral 
-    
-   In order to request referrals, the Kerberos client must explicitly 
-   request the canonicalize KDC option (bit 15) in the KDC options for 
-   the TGS-REQ. This flag indicates to the KDC that the client is 
-   prepared to receive a reply that contains a principal name other 
-   than the one requested. Thus, the KDCOptions types is redefined as: 
-    
-        KDCOptions ::=   BIT STRING { 
-                          reserved(0), 
-                          forwardable(1), 
-                          forwarded(2), 
-                          proxiable(3), 
-                          proxy(4), 
-  
-Jaganathan            Category - Standards Track                     4 
-                            KDC Referrals                 August 2004 
- 
- 
-                          allow-postdate(5), 
-                          postdated(6), 
-                          unused7(7), 
-                          renewable(8), 
-                          unused9(9), 
-                          unused10(10), 
-                          unused11(11), 
-                          canonicalize(15), 
-                          renewable-ok(27), 
-                          enc-tkt-in-skey(28), 
-                          renew(30), 
-                          validate(31) 
-         } 
-         
-   The client should expect, when sending names with the "canonicalize" 
-   KDC option, that names in the KDC's reply will be different than the 
-   name in the request. 
-    
-6.1 Client Referrals 
-    
-   The simplest form of ticket referral is for a user requesting a 
-   ticket using an AS-REQ. In this case, the client machine will send 
-   the AS request to a convenient trusted realm, either the realm of 
-   the client machine or the realm of the client name. In the case of 
-   the name Alice@MS.COM, the client may optimistically choose to send 
-   the request to MS.COM. The realm in the AS request is always the 
-   name of the realm that the request is for as specified in [3]. 
-    
-   The client will send the string "alice@MS.COM" in the client 
-   principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type 
-   with the crealm set to MS.COM. The KDC will try to lookup the name 
-   in its local account database. If the account is present in the 
-   realm of the request, it MUST return a KDC reply structure with the 
-   appropriate ticket. 
-    
-   If the account is not present in the realm specified in the request 
-   and the "canonicalize" KDC option is set, the KDC will try to lookup 
-   the entire name, Alice@MS.COM, using a name service. If this lookup 
-   is unsuccessful, it MUST return the error 
-   KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup is successful, it MUST 
-   return an error KDC_ERR_WRONG_REALM (0x44) and in the error message 
-   the crealm field will contain the the true realm of the client or 
-   another realm that has better information about the client's true 
-   realm. The client MUST NOT use a cname returned from a referral. 
-    
-   If the KDC contains the account locally and "canonicalize" KDC 
-   option is not set, it MUST return a normal ticket. The client name 
-   and realm portions of the ticket and KDC reply message MUST be the 
-   client's true name in the realm, not the globally unique name. 
-    
-   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 
-   new AS request with the same client principal name used to generate 
-   the first referral to the realm specified by the realm field of the 
-  
-Jaganathan            Category - Standards Track                     5 
-                            KDC Referrals                 August 2004 
- 
- 
-   kerberos error message from the first request. This request MUST 
-   produce a valid AS response with a ticket for the canonical user 
-   name.  
-    
-   An implementation should limit the number of referrals that it 
-   processes to avoid infinite referral loops. A suggested limit is 5 
-   referrals before giving up. In MicrosoftÆs implementation the 
-   default limit is 3 since through the use of the global catalog any 
-   domain in one forest is reachable from any other domain in another 
-   trusting forest with 3 or less referrals.  
-    
-6.2 Service Referrals 
-    
-   The primary problem is that the KDC must return a referral ticket 
-   rather than an error message as is done in AS request referrals. 
-   There needs to be a place to include in the TGS response information 
-   about what realm contains the service. This is done by returning 
-   information about the service name in the pre-auth data field of the 
-   KDC reply. 
-    
-   If the KDC resolves the service principal name into a principal in 
-   the realm specified by the service realm name, it will return a 
-   normal ticket. When using canonicalization, the client can omit the 
-   service realm name. If it is supplied, it is used as a hint by the 
-   KDC, but the service principal lookup is not constrained to locating 
-   the service principal name in that specified realm. If the 
-   "canonicalize" flag in the KDC options is not set, then the KDC MUST 
-   only look up the name as a normal principal name in the specified 
-   service realm.  
-    
-   If the "canonicalize" flag in the KDC options is set and the KDC 
-   doesn't find the principal locally, the KDC can return a cross-realm 
-   ticket granting ticket to the next hop on the trust path towards a 
-   realm that may be able to resolve the principal name. 
-    
-   If the KDC can determine the service principal's realm, it SHOULD 
-   return the service realm as KDC supplied pre-authentication data 
-   element. The preauth data MUST be encrypted using the sub-session 
-   key from the authenticator if present or the session key from the 
-   ticket. 
-    
-   The data itself is an ASN.1 encoded structure containing the 
-   server's realm, and if known, the real principal name.  
-    
-                PA-SERVER-REFERRAL-INFO        25 
-                 
-                PA-SERVER-REFERRAL :: = KERB-ENCRYPTED-DATA  
-                                           -- PA-SERVER-REFERRAL-DATA 
-                 
-                PA-SERVER-REFERRAL-DATA ::= SEQUENCE { 
-                        referred-server-realm[0]  KERB-REALM 
-                        referred-name[1]         PrincipalName OPTIONAL 
-                        ... 
-  
-Jaganathan            Category - Standards Track                     6 
-                            KDC Referrals                 August 2004 
- 
- 
-                } 
-    
-    
-   If applicable to the encryption type, the key derivation value will 
-   for the PA-SERVER-REFERRAL is 22. 
-    
-   If the referred-name field is present, the client MUST use that name 
-   in a subsequent TGS request to the service realm when following the 
-   referral. 
-    
-   The client will use this information to request a chain of cross-
-   realm ticket granting tickets until it reaches the realm of the 
-   service, and can then expect to receive a valid service ticket.  
-    
-   However an implementation should limit the number of referrals that 
-   it processes to avoid infinite referral loops. A suggested limit is 
-   5 referrals before giving up. 
-    
-   This is an example of a client requesting a service ticket for a 
-   service in realm NT.MS.COM where the client is in OFFICE.MS.COM. 
-    
-        +NC = Canonicalize KDCOption set 
-        +PA-REFERRAL = returned PA-SERVER-REFERRAL-INFO 
-         
-        C: TGS-REQ sname=server/foo.nt.ms.com srealm=NULL +NC to 
-        OFFICE.MS.COM 
-        S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL 
-        containing NT.MS.COM 
-        C: TGS-REQ sname=krbtgt/NT.MS.COM@MS.COM +NC to MS.COM 
-        S: TGS-REP sname=krbtgt/NT.MS.COM@MS.COM 
-        C: TGS-REQ sname=server/foo.nt.ms.com srealm=NT.MS.COM +NC to 
-        NT.MS.COM 
-        S: TGS-REP sname=server/foo.nt.ms.com@NT.MS.COM 
-    
-   Notice that the client only specifies the service name in the 
-   initial and final TGS request. 
-    
-7. Cross Realm Routing 
-    
-   The current Kerberos protocol requires the client to explicitly 
-   request a cross-realm TGT for each pair of realms on a referral 
-   chain. As a result, the client need to be aware of the trust 
-   hierarchy and of any short-cut trusts (those that aren't parent-
-   child trusts). Instead, the client should be able to request a TGT 
-   to the target realm from each realm on the route. The KDC will 
-   determine the best path for the client and return a cross-realm TGT. 
-   The client has to be aware that a request for a cross-realm TGT may 
-   return a TGT for a realm different from the one requested. 
-    
-   For compatibility, the client MUST use the "canonicalize" KDC option 
-   if it is able to use cross-realm routing from the KDC. 
-    
-8. Compatibility with earlier implementations of name canonicalization 
-  
-Jaganathan            Category - Standards Track                     7 
-                            KDC Referrals                 August 2004 
- 
- 
-    
-   The Microsoft Windows 2000 release included an earlier form of name-
-   canonicalization [4]. It has these differences: 
-    
-   1) The TGS referral data was returned inside of the KDC message as 
-      "encrypted pre auth data". 
-    
-                KERB-ENCRYPTED-KDC-REPLY ::=  SEQUENCE { 
-                        session-key[0]   KERB-ENCRYPTION-KEY, 
-                        last-request[1]  PKERB-LAST-REQUEST, 
-                        nonce[2]         INTEGER, 
-                        key-expiration[3] KERB-TIME OPTIONAL, 
-                        flags[4]         KERB-TICKET-FLAGS, 
-                        authtime[5]      KERB-TIME, 
-                        starttime[6]     KERB-TIME OPTIONAL, 
-                        endtime[7]       KERB-TIME, 
-                        renew-until[8]   KERB-TIME OPTIONAL, 
-                        server-realm[9]  KERB-REALM, 
-                        server-name[10]  KERB-PRINCIPAL-NAME, 
-                        client-addresses[11] PKERB-HOST-ADDRESSES 
-                OPTIONAL, 
-                        encrypted-pa-data[12] SEQUENCE OF KERB-PA-DATA 
-                OPTIONAL 
-                } 
-    
-   2) The preauth data type definition in the encrypted preauth data is 
-      as follows: 
-    
-                PA-SVR-REFERRAL-INFO        20 
-                 
-                PA-SVR-REFERRAL-DATA ::= SEQUENCE { 
-                        referred-server-name[1]  PrincipalName OPTIONAL 
-                        referred-server-realm[0] KERB-REALM 
-                } 
-    
-     
-9. Security Considerations 
- 
-   In the case of TGS requests the client may be vulnerable to a denial 
-   of service attack by an attacker that replays replies from previous 
-   requests. The client can verify that the request was one of its own 
-   by checking the client-address field or authtime field, though, so 
-   the damage is limited and detectable. Clients MUST NOT process cross 
-   realm referral TGTs if the KDC reply does not include the encrypted 
-   PA-SERVER-REFERRAL-INFO.  
-    
-   For the AS exchange case, it is important that the logon mechanism 
-   not trust a name that has not been used to authenticate the user. 
-   For example, the name that the user enters as part of a logon 
-   exchange may not be the name that the user authenticates as, given 
-   that the KDC_ERR_WRONG_REALM error may have been returned. The 
-   relevant Kerberos naming information for logon (if any), is the 
-
-  
-Jaganathan            Category - Standards Track                     8 
-                            KDC Referrals                 August 2004 
- 
- 
-   client name and client realm in the service ticket targeted at the 
-   workstation that was obtained using the user's initial TGT. 
-    
-   How the client name and client realm is mapped into a local account 
-   for logon is a local matter, but the client logon mechanism MUST use 
-   additional information such as the client realm and/or authorization 
-   attributes from the service ticket presented to the workstation by 
-   the user, when mapping the logon credentials to a local account on 
-   the workstation. 
- 
-10. Acknowledgements 
-   The authors wish to thank Ken Raeburn for his comments and 
-   suggestions.  
- 
-11.1 Normative References 
-    
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   3  Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K. 
-      Raeburn, "The Kerberos Network Authentication Service (V5)", 
-      draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22, 
-      2002.  Work in progress. 
- 
-11.2 Informative References 
-    
-    
-   4  J. Trostle, I. Kosinovsky, and M. Swift,"Implementation of 
-      Crossrealm Referral Handling in the MIT Kerberos Client", In 
-      Network and Distributed System Security Symposium, February 2001. 
-    
-    
-12. Author's Addresses 
-    
-   Karthik Jaganathan 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: karthikj@Microsoft.com 
-    
-   Larry Zhu 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: lzhu@Microsoft.com 
-    
-   Michael Swift 
-   University of Washington 
-  
-Jaganathan            Category - Standards Track                     9 
-                            KDC Referrals                 August 2004 
- 
- 
-   Seattle, Washington 
-   Email: mikesw@cs.washington.edu 
-    
-   John Brezak 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@Microsoft.com 
-    
-   Jonathan Trostle 
-   Cisco Systems 
-   170 W. Tasman Dr. 
-   San Jose, CA 95134 
-   Email: jtrostle@cisco.com 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Jaganathan            Category - Standards Track                    10 
-                            KDC Referrals                 August 2004 
- 
- 
-   Full Copyright Statement 
- 
-   Copyright (C) The Internet Society (1999).  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this   
-   document itself may not be modified in any way, such as by removing   
-   the copyright notice or references to the Internet Society or other   
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
-    
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Jaganathan            Category - Standards Track                    11 
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-04.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-04.txt
deleted file mode 100644
index 98d97a377..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-04.txt
+++ /dev/null
@@ -1,767 +0,0 @@
-Kerberos Working Group                               Karthik Jaganathan
-Internet Draft                                                Larry Zhu
-Document: draft-ietf-krb-wg-kerberos-referrals-04.txt       John Brezak
-Category: Standards Track                                     Microsoft
-                                                             Mike Swift
-                                               University of Washington
-                                                       Jonathan Trostle
-                                                          Cisco Systems
-                                                  Expires: January 2005
-
-
-           Generating KDC Referrals to locate Kerberos realms
-
-
-Status of this Memo
-
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC-2026 [1].
-
-
-   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."
-
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
-   Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-
-   The draft documents a method for a Kerberos Key Distribution Center
-   (KDC) to respond to client requests for Kerberos tickets when the
-   client does not have detailed configuration information on the realms
-   of users or services. The KDC will handle requests for principals in
-   other realms by returning either a referral error or a cross-realm
-   TGT to another realm on the referral path. The clients will use this
-   referral information to reach the realm of the target principal and
-   then receive the ticket.
-
-
-Conventions used in this document
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC-2119 [2].
-
-
-1. Introduction
-
-
-
-
-Jaganathan                                                      [Page 1]
-
-
-
-
-
-
-                              KDC Referrals                 January 2005
-
-
-
-   Current implementations of the Kerberos AS and TGS protocols, as
-   defined in [3], use principal names constructed from a known user or
-   service name and realm. A service name is typically constructed from
-   a name of the service and the DNS host name of the computer that is
-   providing the service. Many existing deployments of Kerberos use a
-   single Kerberos realm where all users and services would be using the
-   same realm.  However in an environment where there are multiple
-   trusted Kerberos realms, the client needs to be able to determine
-   what realm a particular user or service is in before making an AS or
-   TGS request. Traditionally this requires client configuration to make
-   this possible.
-
-
-   When having to deal with multiple trusted realms, users are forced to
-   know what realm they are in before they can obtain a ticket granting
-   ticket (TGT) with an AS request. However, in many cases the user
-   would like to use a more familiar name that is not directly related
-   to the realm of their Kerberos principal name. A good example of this
-   is an RFC-821 style email name [4]. This document describes a
-   mechanism that would allow a user to specify a user principal name
-   that is an alias for the user's Kerberos principal name. In practice
-   this would be the name that the user specifies to obtain a TGT from a
-   Kerberos KDC. The user principal name no longer has a direct
-   relationship with the Kerberos principal or realm. Thus the
-   administrator is able to move the user's principal to other realms
-   without the user having to know that it happened.
-
-
-   Once a user has a TGT, they would like to be able to access services
-   in any trusted Kerberos realm. To do this requires that the client be
-   able to determine what realm the target service principal is in
-   before making the TGS request. Current implementations of Kerberos
-   typically have a table that maps DNS host names to corresponding
-   Kerberos realms.  In order for this to work on the client, each
-   application canonicalizes the host name of the service, for example
-   by doing a DNS lookup followed by a reverse lookup using the returned
-   IP address. The returned primary host name is then used in the
-   construction of the principal name for the target service. In order
-   for the correct realm to be added for the target host, the mapping
-   table [domain_to_realm] is consulted for the realm corresponding to
-   the DNS host name. The corresponding realm is then used to complete
-   the target service principal name.
-
-
-   This traditional mechanism requires that each client have very
-   detailed configuration information about the hosts that are providing
-   services and their corresponding realms. Having client side
-   configuration information can be very costly from an administration
-   point of view - especially if there are many realms and computers in
-   the environment.
-
-
-
-
-
-Jaganathan                                                      [Page 2]
-
-
-
-
-
-
-                              KDC Referrals                 January 2005
-
-
-
-   There are also cases where specific DNS aliases (local names) have
-   been setup in an organization to refer to a server in another
-   organization (remote server). The server has different DNS names in
-   each organization and each organization has a Kerberos realm that is
-   configured to service DNS names within that organization. Ideally
-   users are able to authenticate to the server in the other
-   organization using the local server name. This would mean that the
-   local realm be able to produce a ticket to the remote server under
-   its name. You could give that remote server an identity in the local
-   realm and then have that remote server maintain a separate secret for
-   each alias it is known as. Alternatively you could arrange to have
-   the local realm issue a referral to the remote realm and notify the
-   requesting client of the server's remote name that should be used in
-   order to request a ticket.
-
-
-   This draft proposes a solution for these problems and simplifies
-   administration by minimizing the configuration information needed on
-   each computer using Kerberos. Specifically it describes a mechanism
-   to allow the KDC to handle canonicalization of names, provide for
-   principal aliases for users and services and provide a mechanism for
-   the KDC to determine the trusted realm authentication path by being
-   able to generate referrals to other realms in order to locate
-   principals.
-
-
-   To rectify these problems, this draft introduces three new kinds of
-   KDC referrals:
-
-
-   1. AS ticket referrals, in which the client doesn't know which realm
-   contains a user account.
-   2. TGS ticket referrals, in which the client doesn't know which realm
-   contains a server account.
-   3. Cross realm shortcut referrals, in which the KDC chooses the next
-   path on a referral chain
-
-
-2. Requesting a referral
-
-
-   In order to request referrals defined in section 5, 6, and 7, the
-   Kerberos client MUST explicitly request the canonicalize KDC option
-   (bit 15) [3] for the AS-REQ or TGS-REQ. This flag indicates to the
-   KDC that the client is prepared to receive a reply that contains a
-   principal name other than the one requested.
-
-
-       KDCOptions ::= KerberosFlags
-                -- canonicalize (15)
-                -- other KDCOptions values omitted
-
-
-   The client should expect, when sending names with the "canonicalize"
-   KDC option, that names in the KDC's reply MAY be different than the
-
-
-
-
-Jaganathan                                                      [Page 3]
-
-
-
-
-
-
-                              KDC Referrals                 January 2005
-
-
-
-   name in the request. A referral ticket is a cross realm TGT that is
-   returned when the sname of the ticket is not the sname in the request
-   [3].
-
-
-3. Realm Organization Model
-
-
-   This draft assumes that the world of principals is arranged on
-   multiple levels: the realm, the enterprise, and the world. A KDC may
-   issue tickets for any principal in its realm or cross-realm tickets
-   for realms with which it has a direct trust relationship. The KDC
-   also has access to a trusted name service that can resolve any name
-   from within its enterprise into a realm. This trusted name service
-   removes the need to use an un-trusted DNS lookup for name resolution.
-
-
-   For example, consider the following configuration, where lines
-   indicate trust relationships:
-
-
-
-                     MS.COM
-                   /        \
-                  /          \
-           OFFICE.MS.COM  NTDEV.MS.COM
-
-
-
-   In this configuration, all users in the MS.COM enterprise could have
-   a principal name such as alice@MS.COM, with the same realm portion.
-   In addition, servers at MS.COM should be able to have DNS host names
-   from any DNS domain independent of what Kerberos realm their
-   principals reside in.
-
-
-4. Client Name Canonicalization
-
-
-   A client account may have multiple principal names. More useful,
-   though, is a globally unique name that allows unification of email
-   and security principal names. For example, all users at MS may have a
-   client principal name of the form "joe@MS.COM" even though the
-   principals are contained in multiple realms. This global name is
-   again an alias for the true client principal name, which indicates
-   what realm contains the principal. Thus, accounts "alice" in the
-   realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as
-   "alice@MS.COM" and "bob@MS.COM".
-
-
-   This utilizes a new client principal name type, as the AS-REQ message
-   only contains a single realm field, and the realm portion of this
-   name doesn't correspond to any Kerberos realm. Thus, the entire name
-   "alice@MS.COM" is transmitted as a single component in the client
-   name field of the AS-REQ message, with a name type of NT-ENTERPRISE
-   [3]. The KDC will recognize this name type and then transform the
-
-
-
-
-Jaganathan                                                      [Page 4]
-
-
-
-
-
-
-                              KDC Referrals                 January 2005
-
-
-
-   requested name into the true principal name.  The true principal name
-   can be using a name type different from the requested name type.
-   Typically the true principal name will be a NT-PRINCIPAL [3].
-
-
-   If the "canonicalize" KDC option is set, then the KDC MAY change the
-   client principal name and type in the AS response and ticket returned
-   from the name type of the client name in the request. For example the
-   AS request may specify a client name of "bob@MS.COM" as an NT-
-   PRINCIPAL with the "canonicalize" KDC option set and the KDC will
-   return with a client name of "104567" as a NT-UID.
-
-
-5. Client Referrals
-
-
-   The simplest form of ticket referral is for a user requesting a
-   ticket using an AS-REQ. In this case, the client machine will send
-   the AS-REQ to a convenient trusted realm, for example the realm of
-   the client machine. In the case of the name alice@MS.COM, the client
-   MAY optimistically choose to send the request to MS.COM. The realm in
-   the AS-REQ is always the name of the realm that the request is for as
-   specified in [3].
-
-
-   The KDC will try to lookup the name in its local account database. If
-   the account is present in the realm of the request, it SHOULD return
-   a KDC reply structure with the appropriate ticket.
-
-
-   If the account is not present in the realm specified in the request
-   and the "canonicalize" KDC option is set, the KDC will try to lookup
-   the entire name, alice@MS.COM, using a name service. If this lookup
-   is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN
-   [3].  If the lookup is successful, it MUST return an error
-   KDC_ERR_WRONG_REALM [3] and in the error message the crealm field
-   will contain either the true realm of the client or another realm
-   that MAY have better information about the client's true realm. The
-   client MUST NOT use a cname returned from a referral.
-
-
-   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
-   new AS request with the same client principal name used to generate
-   the first referral to the realm specified by the realm field of the
-   Kerberos error message from the first request. The client SHOULD
-   repeat these steps until it finds the true realm of the client. To
-   avoid infinite referral loops, an implementation should limit the
-   number of referrals.  A suggested limit is 5 referrals before giving
-   up. In Microsoft's current implementation through the use of global
-   catalogs any domain in one forest is reachable from any other domain
-   in the same forest or another trusted forest with 3 or less
-   referrals.
-
-
-6. Service Referrals
-
-
-
-
-Jaganathan                                                      [Page 5]
-
-
-
-
-
-
-                              KDC Referrals                 January 2005
-
-
-
-   The primary problem in service referrals is that the KDC must return
-   a referral ticket rather than an error message as is done in AS
-   ticket referrals. There needs to be a place to include in the TGS-REP
-   information about what realm contains the service. This is done by
-   returning information about the service name in the pre-
-   authentication data field of the KDC reply [3].
-
-
-   If the KDC resolves the service principal name into a principal in
-   the realm specified by the service realm name, it will return a
-   normal ticket.
-
-
-   If the "canonicalize" flag in the KDC options is not set, the KDC
-   MUST only look up the name as a normal principal name in the
-   specified service realm. If the "canonicalize" flag in the KDC
-   options is set and the KDC doesn't find the principal locally, the
-   KDC MAY return a cross-realm ticket granting ticket to the next hop
-   on the trust path towards a realm that may be able to resolve the
-   principal name.
-
-
-   When a referral TGT is returned, the KDC MUST return the target realm
-   for the referral TGT as an KDC supplied pre-authentication data
-   element in the response. The pre-authentication data MUST be
-   encrypted using the sub-session key from the authenticator if present
-   or the session key from the ticket. The pre-authentication data
-   contains the referred realm, and if known, the real principal name.
-
-
-       PA-SERVER-REFERRAL      25
-
-
-       PA-SERVER-REFERRAL-DATA ::= EncryptedData
-                             -- ServerReferalData --
-
-
-       ServerReferralData ::= SEQUENCE {
-              referred-realm         [0] Realm,
-                             -- target realm of the referral TGT
-              referred-name          [1] PrincipalName OPTIONAL,
-                             -- service principal name, MAY differ
-                             -- from the server name in the request
-              ...
-       }
-
-
-   Clients MUST NOT process referral tickets if the KDC response does
-   not contain the PA-SERVER-REFERRAL.
-
-
-   If applicable to the encryption type, the key usage value for the
-   encryption key used by PA-SERVER-REFERRAL is 26 if the session key
-   from the ticket is used or 27 if a sub-session key is used.
-
-
-   If the referred-name field is present, the client MUST use that name
-
-
-
-
-Jaganathan                                                      [Page 6]
-
-
-
-
-
-
-                              KDC Referrals                 January 2005
-
-
-
-   in a subsequent TGS request to the service realm when following the
-   referral.
-
-
-   The client will use this information to request a chain of cross-
-   realm ticket granting tickets until it reaches the realm of the
-   service, and can then expect to receive a valid service ticket.
-   However an implementation should limit the number of referrals that
-   it processes to avoid infinite referral loops. A suggested limit is 5
-   referrals before giving up.
-
-
-   Here is an example of a client requesting a service ticket for a
-   service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM.
-
-
-       +NC = Canonicalize KDCOption set
-       +PA-REFERRAL = returned PA-SERVER-REFERRAL
-       C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to OFFICE.MS.COM
-       S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
-          containing MS.COM as the referred realm with no referred name
-       C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to MS.COM
-       S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL
-          containing NTDEV.MS.COM as the referred realm with no referred
-          name
-       C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to NTDEV.MS.COM
-       S: TGS-REP sname=server/foo.ntdev.ms.com@NTDEV.MS.COM
-
-
-7. Cross Realm Routing
-
-
-   The current Kerberos protocol requires the client to explicitly
-   request a cross-realm TGT for each pair of realms on a referral
-   chain. As a result, the client need to be aware of the trust
-   hierarchy and of any short-cut trusts (those that aren't parent-
-   child trusts).
-
-
-   Instead, using this referral routing mechanism, The KDC will
-   determine the best path for the client and return a cross-realm TGT
-   as the referral TGT, and the target realm for this TGT in the PA-
-   SERVER-REFERRAL of the KDC reply.
-
-
-   If the "canonicalize" KDC option is not set, the KDC MUST NOT return
-   a referral ticket. Clients MUST NOT process referral tickets if the
-   KDC response does not contain the PA-SERVER-REFERRAL.
-
-
-8. Compatibility with earlier implementations of name canonicalization
-
-
-   The Microsoft Windows 2000 and Windows 2003 releases included an
-   earlier form of name-canonicalization [5]. Here are the differences:
-
-
-   1) The TGS referral data is returned inside of the KDC message as
-
-
-
-
-Jaganathan                                                      [Page 7]
-
-
-
-
-
-
-                              KDC Referrals                 January 2005
-
-
-
-   "encrypted pre-authentication data".
-
-
-       EncKDCRepPart   ::= SEQUENCE {
-              key                [0] EncryptionKey,
-              last-req           [1] LastReq,
-              nonce              [2] UInt32,
-              key-expiration     [3] KerberosTime OPTIONAL,
-              flags              [4] TicketFlags,
-              authtime           [5] KerberosTime,
-              starttime          [6] KerberosTime OPTIONAL,
-              endtime            [7] KerberosTime,
-              renew-till         [8] KerberosTime OPTIONAL,
-              srealm             [9] Realm,
-              sname             [10] PrincipalName,
-              caddr             [11] HostAddresses OPTIONAL,
-              encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
-      }
-
-
-   2) The preauth data type definition in the encrypted preauth data is
-   as follows:
-
-
-       PA-SVR-REFERRAL-INFO       20
-
-
-       PA-SVR-REFERRAL-DATA ::= SEQUENCE {
-              referred-name   [1] PrincipalName OPTIONAL,
-              referred-realm  [0] Realm
-       }
-
-
-9. Security Considerations
-
-
-   In the case of TGS requests the client may be vulnerable to a denial
-   of service attack by an attacker that replays replies from previous
-   requests. The client can verify that the request was one of its own
-   by checking the client-address field or authtime field, though, so
-   the damage is limited and detectable.
-
-
-   For the AS exchange case, it is important that the logon mechanism
-   not trust a name that has not been used to authenticate the user.
-   For example, the name that the user enters as part of a logon
-   exchange may not be the name that the user authenticates as, given
-   that the KDC_ERR_WRONG_REALM error may have been returned. The
-   relevant Kerberos naming information for logon (if any), is the
-   client name and client realm in the service ticket targeted at the
-   workstation that was obtained using the user's initial TGT.
-
-
-   How the client name and client realm is mapped into a local account
-   for logon is a local matter, but the client logon mechanism MUST use
-   additional information such as the client realm and/or authorization
-
-
-
-
-Jaganathan                                                      [Page 8]
-
-
-
-
-
-
-                              KDC Referrals                 January 2005
-
-
-
-   attributes from the service ticket presented to the workstation by
-   the user, when mapping the logon credentials to a local account on
-   the workstation.
-
-
-10. Acknowledgements
-
-
-   The authors wish to thank Ken Raeburn for his comments and
-   suggestions.
-
-
-11. References
-
-
-11.1 Normative References
-
-
-   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
-   9, RFC 2026, October 1996.
-
-
-   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
-   Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
-   Network Authentication Service (V5)", draft-ietf-krb-wg-kerberos-
-   clarifications. Work in progress.
-
-
-   [4] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August
-   1982.
-
-
-11.2 Informative References
-
-
-   [5] Trostle, J., Kosinovsky, I., and Swift, M., "Implementation of
-   Crossrealm Referral Handling in the MIT Kerberos Client", In Network
-   and Distributed System Security Symposium, February 2001.
-
-
-12. Author's Addresses
-
-
-   Karthik Jaganathan
-   Microsoft
-   One Microsoft Way
-   Redmond, Washington
-   Email: karthikj@Microsoft.com
-
-
-   Larry Zhu
-   Microsoft
-   One Microsoft Way
-   Redmond, Washington
-   Email: lzhu@Microsoft.com
-
-
-   Michael Swift
-   University of Washington
-
-
-
-
-Jaganathan                                                      [Page 9]
-
-
-
-
-
-
-                              KDC Referrals                 January 2005
-
-
-
-   Seattle, Washington
-   Email: mikesw@cs.washington.edu
-
-
-   John Brezak
-   Microsoft
-   One Microsoft Way
-   Redmond, Washington
-   Email: jbrezak@Microsoft.com
-
-
-   Jonathan Trostle
-   Cisco Systems
-   170 W. Tasman Dr.
-   San Jose, CA 95134
-   Email: jtrostle@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan                                                     [Page 10]
-
-
-
-
-
-
-                              KDC Referrals                 January 2005
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan                                                     [Page 11]
\ No newline at end of file
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt
deleted file mode 100644
index 9b41e0430..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt
+++ /dev/null
@@ -1,961 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                             K. Jaganathan
-Obsoletes: 2478 (if approved)                      Microsoft Corporation
-Expires: April 25, 2005                                 October 25, 2004
-
-
-           Generating KDC Referrals to locate Kerberos realms
-                  draft-ietf-krb-wg-kerberos-referrals-05
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 25, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   The memo documents a method for a Kerberos Key Distribution Center
-   (KDC) to respond to client requests for Kerberos tickets when the
-   client does not have detailed configuration information on the realms
-   of users or services.  The KDC will handle requests for principals in
-   other realms by returning either a referral error or a cross-realm
-   TGT to another realm on the referral path.  The clients will use this
-   referral information to reach the realm of the target principal and
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                 [Page 1]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-   then receive the ticket.
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.   Conventions Used in This Document  . . . . . . . . . . . . .   5
-   3.   Requesting a Referral  . . . . . . . . . . . . . . . . . . .   6
-   4.   Realm Organization Model . . . . . . . . . . . . . . . . . .   7
-   5.   Client Name Canonicalization . . . . . . . . . . . . . . . .   8
-   6.   Client Referrals . . . . . . . . . . . . . . . . . . . . . .   9
-   7.   Server Referrals . . . . . . . . . . . . . . . . . . . . . .  10
-   8.   Cross Realm Routing  . . . . . . . . . . . . . . . . . . . .  12
-   9.   Compatibility with Earlier Implementations of Name
-        Canonicalization . . . . . . . . . . . . . . . . . . . . . .  13
-   10.  Security Considerations  . . . . . . . . . . . . . . . . . .  14
-   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  15
-   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  16
-   12.1   Normative References . . . . . . . . . . . . . . . . . . .  16
-   12.2   Informative References . . . . . . . . . . . . . . . . . .  16
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  16
-        Intellectual Property and Copyright Statements . . . . . . .  17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                 [Page 2]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-1.  Introduction
-
-   Current implementations of the Kerberos AS and TGS protocols, as
-   defined in [KRBCLR], use principal names constructed from a known
-   user or service name and realm.  A service name is typically
-   constructed from a name of the service and the DNS host name of the
-   computer that is providing the service.  Many existing deployments of
-   Kerberos use a single Kerberos realm where all users and services
-   would be using the same realm.  However in an environment where there
-   are multiple trusted Kerberos realms, the client needs to be able to
-   determine what realm a particular user or service is in before making
-   an AS or TGS request.  Traditionally this requires client
-   configuration to make this possible.
-
-   When having to deal with multiple trusted realms, users are forced to
-   know what realm they are in before they can obtain a ticket granting
-   ticket (TGT) with an AS request.  However, in many cases the user
-   would like to use a more familiar name that is not directly related
-   to the realm of their Kerberos principal name.  A good example of
-   this is an RFC 822 style email name [RFC822].  This document
-   describes a mechanism that would allow a user to specify a user
-   principal name that is an alias for the user's Kerberos principal
-   name.  In practice this would be the name that the user specifies to
-   obtain a TGT from a Kerberos KDC.  The user principal name no longer
-   has a direct relationship with the Kerberos principal or realm.  Thus
-   the administrator is able to move the user's principal to other
-   realms without the user having to know that it happened.
-
-   Once a user has a TGT, they would like to be able to access services
-   in any trusted Kerberos realm.  To do this requires that the client
-   be able to determine what realm the target service principal is in
-   before making the TGS request.  Current implementations of Kerberos
-   typically have a table that maps DNS host names to corresponding
-   Kerberos realms.  In order for this to work on the client, each
-   application canonicalizes the host name of the service, for example
-   by doing a DNS lookup followed by a reverse lookup using the returned
-   IP address.  The returned primary host name is then used in the
-   construction of the principal name for the target service.  In order
-   for the correct realm to be added for the target host, the mapping
-   table [domain_to_realm] is consulted for the realm corresponding to
-   the DNS host name.  The corresponding realm is then used to complete
-   the target service principal name.
-
-   This traditional mechanism requires that each client have very
-   detailed configuration information about the hosts that are providing
-   services and their corresponding realms.  Having client side
-   configuration information can be very costly from an administration
-   point of view - especially if there are many realms and computers in
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                 [Page 3]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-   the environment.
-
-   There are also cases where specific DNS aliases (local names) have
-   been setup in an organization to refer to a server in another
-   organization (remote server).  The server has different DNS names in
-   each organization and each organization has a Kerberos realm that is
-   configured to service DNS names within that organization.  Ideally
-   users are able to authenticate to the server in the other
-   organization using the local server name.  This would mean that the
-   local realm be able to produce a ticket to the remote server under
-   its name.  You could give that remote server an identity in the local
-   realm and then have that remote server maintain a separate secret for
-   each alias it is known as.  Alternatively you could arrange to have
-   the local realm issue a referral to the remote realm and notify the
-   requesting client of the server's remote name that should be used in
-   order to request a ticket.
-
-   This memo proposes a solution for these problems and simplifies
-   administration by minimizing the configuration information needed on
-   each computer using Kerberos.  Specifically it describes a mechanism
-   to allow the KDC to handle canonicalization of names, provide for
-   principal aliases for users and services and provide a mechanism for
-   the KDC to determine the trusted realm authentication path by being
-   able to generate referrals to other realms in order to locate
-   principals.
-
-   Two kinds of KDC referrals are introduced in this memo:
-
-   1.  Client referrals, in which the client doesn't know which realm
-      contains a user account.
-   2.  Server referrals, in which the client doesn't know which realm
-      contains a server account.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                 [Page 4]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                 [Page 5]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-3.  Requesting a Referral
-
-   In order to request referrals defined in section 5, 6, and 7, the
-   Kerberos client MUST explicitly request the canonicalize KDC option
-   (bit 15) [KRBCLR] for the AS-REQ or TGS-REQ.  This flag indicates to
-   the KDC that the client is prepared to receive a reply that contains
-   a principal name other than the one requested.
-
-
-          KDCOptions ::= KerberosFlags
-                   -- canonicalize (15)
-                   -- other KDCOptions values omitted
-
-   The client should expect, when sending names with the "canonicalize"
-   KDC option, that names in the KDC's reply MAY be different than the
-   name in the request.  A referral TGT is a cross realm TGT that is
-   returned with the server name of the ticket being different from the
-   server name in the request [KRBCLR].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                 [Page 6]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-4.  Realm Organization Model
-
-   This memo assumes that the world of principals is arranged on
-   multiple levels: the realm, the enterprise, and the world.  A KDC may
-   issue tickets for any principal in its realm or cross-realm tickets
-   for realms with which it has a direct trust relationship.  The KDC
-   also has access to a trusted name service that can resolve any name
-   from within its enterprise into a realm.  This trusted name service
-   removes the need to use an un-trusted DNS lookup for name resolution.
-
-   For example, consider the following configuration, where lines
-   indicate trust relationships:
-
-                        MS.COM
-                      /        \
-                     /          \
-              OFFICE.MS.COM  NTDEV.MS.COM
-
-   In this configuration, all users in the MS.COM enterprise could have
-   a principal name such as alice@MS.COM, with the same realm portion.
-   In addition, servers at MS.COM should be able to have DNS host names
-   from any DNS domain independent of what Kerberos realm their
-   principals reside in.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                 [Page 7]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-5.  Client Name Canonicalization
-
-   A client account may have multiple principal names.  More useful,
-   though, is a globally unique name that allows unification of email
-   and security principal names.  For example, all users at MS may have
-   a client principal name of the form "joe@MS.COM" even though the
-   principals are contained in multiple realms.  This global name is
-   again an alias for the true client principal name, which indicates
-   what realm contains the principal.  Thus, accounts "alice" in the
-   realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as
-   "alice@MS.COM" and "bob@MS.COM".
-
-   This utilizes a new client principal name type, as the AS-REQ message
-   only contains a single realm field, and the realm portion of this
-   name doesn't correspond to any Kerberos realm.  Thus, the entire name
-   "alice@MS.COM" is transmitted as a single component in the client
-   name field of the AS-REQ message, with a name type of NT-ENTERPRISE
-   [KRBCLR].  The KDC will recognize this name type and then transform
-   the requested name into the true principal name.  The true principal
-   name can be using a name type different from the requested name type.
-   Typically the true principal name will be a NT-PRINCIPAL [KRBCLR].
-
-   If the "canonicalize" KDC option is set, then the KDC MAY change the
-   client principal name and type in the AS response and ticket returned
-   from the name type of the client name in the request.  For example
-   the AS request may specify a client name of "bob@MS.COM" as an
-   NT-ENTERPRISE name with the "canonicalize" KDC option set and the KDC
-   will return with a client name of "104567" as a NT-UID.
-
-   It is assumed that the client discovers whether the KDC supports the
-   NT-ENTERPRISE name type via out of band mechanisms.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                 [Page 8]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-6.  Client Referrals
-
-   The simplest form of ticket referral is for a user requesting a
-   ticket using an AS-REQ.  In this case, the client machine will send
-   the AS-REQ to a convenient trusted realm, for example the realm of
-   the client machine.  In the case of the name alice@MS.COM, the client
-   MAY optimistically choose to send the request to MS.COM.  The realm
-   in the AS-REQ is always the name of the realm that the request is for
-   as specified in [KRBCLR].
-
-   The KDC will try to lookup the name in its local account database.
-   If the account is present in the realm of the request, it SHOULD
-   return a KDC reply structure with the appropriate ticket.
-
-   If the account is not present in the realm specified in the request
-   and the "canonicalize" KDC option is set, the KDC will try to lookup
-   the entire name, alice@MS.COM, using a name service.  If this lookup
-   is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN
-   [KRBCLR].  If the lookup is successful, it MUST return an error
-   KDC_ERR_WRONG_REALM [KRBCLR] and in the error message the crealm
-   field will contain either the true realm of the client or another
-   realm that MAY have better information about the client's true realm.
-   The client SHALL NOT use a cname returned from a referral until that
-   name is validated.
-
-   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
-   new AS request with the same client principal name used to generate
-   the first referral to the realm specified by the realm field of the
-   Kerberos error message from the first request.  The client SHOULD
-   repeat these steps until it finds the true realm of the client.  To
-   avoid infinite referral loops, an implementation should limit the
-   number of referrals.  A suggested limit is 5 referrals before giving
-   up.
-
-   In Microsoft's current implementation through the use of global
-   catalogs any domain in one forest is reachable from any other domain
-   in the same forest or another trusted forest with 3 or less
-   referrals.  A forest is a collection of realms with hierarchical
-   trust relationships: there can be multiple trust trees in a forest;
-   each child and parent realm pair and each root realm pair have
-   bidirectional transitional direct rusts between them.
-
-   The true principal name of the client, carried via the KRB_ERROR
-   message, can be validated in a subsequent TGS message exchange where
-   its value is communicated back to the KDC via the authenticator in
-   the PA-TGS-REQ padata [KRBCLR].
-
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                 [Page 9]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-7.  Server Referrals
-
-   The primary difference in server referrals is that the KDC MUST
-   return a referral TGT rather than an error message as is done in the
-   client referrals.  There needs to be a place to include in the reply
-   information about what realm contains the server.  This is done by
-   returning information about the server name in the pre-authentication
-   data field of the KDC reply [KRBCLR], as specified later in this
-   section.
-
-   If the KDC resolves the server principal name into a principal in the
-   realm specified by the service realm name, it will return a normal
-   ticket.
-
-   If the "canonicalize" flag in the KDC options is not set, the KDC
-   MUST only look up the name as a normal principal name in the
-   specified server realm.  If the "canonicalize" flag in the KDC
-   options is set and the KDC doesn't find the principal locally, the
-   KDC MAY return a cross-realm ticket granting ticket to the next hop
-   on the trust path towards a realm that may be able to resolve the
-   principal name.  The true principal name of the server SHALL be
-   returned in the padata of the reply if it is different from what is
-   specified the request.
-
-   When a referral TGT is returned, the KDC MUST return the target realm
-   for the referral TGT as an KDC supplied pre-authentication data
-   element in the response.  This referral information in
-   pre-authentication data MUST be encrypted using the session key from
-   the reply ticket.  The key usage value for the encryption operation
-   used by PA-SERVER-REFERRAL is 26.
-
-   The pre-authentication data returned by the KDC, which contains the
-   referred realm and the true principal name of server, is encoded in
-   DER as follows.
-
-          PA-SERVER-REFERRAL      25
-
-          PA-SERVER-REFERRAL-DATA ::= EncryptedData
-                                -- ServerReferralData --
-
-          ServerReferralData ::= SEQUENCE {
-                 referred-realm         [0] Realm, OPTIONAL
-                                -- target realm of the referral TGT
-                 true-principal-name    [1] PrincipalName OPTIONAL,
-                                -- true server principal name
-                 ...
-          }
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                [Page 10]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-   Clients SHALL NOT accept a reply ticket, whose the server principal
-   name is different from that of the request,  if the KDC response does
-   not contain a PA-SERVER-REFERRAL padata entry.
-
-   The referred-realm field is present if and only if the returned
-   ticket is a referral TGT, not a service ticket for the requested
-   server principal.
-
-   When a referral TGT is returned and the true-principal-name field is
-   present, the client MUST use that name in the subsequent requests to
-   the server realm when following the referral.
-
-   Client SHALL NOT accept a true server principal name for a service
-   ticket if the true-principal-name field is not present in the
-   PA-SERVER-REFERRAL data.
-
-   The client will use this referral information to request a chain of
-   cross-realm ticket granting tickets until it reaches the realm of the
-   server, and can then expect to receive a valid service ticket.
-
-   However an implementation should limit the number of referrals that
-   it processes to avoid infinite referral loops.  A suggested limit is
-   5 referrals before giving up.
-
-   Here is an example of a client requesting a service ticket for a
-   service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM.
-
-          +NC = Canonicalize KDCOption set
-          +PA-REFERRAL = returned PA-SERVER-REFERRAL
-          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM
-          S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
-             containing MS.COM as the referred realm with no
-             true-principal-name
-          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM
-          S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL
-             containing NTDEV.MS.COM as the referred realm with no
-             true-principal-name
-          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM
-          S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                [Page 11]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-8.  Cross Realm Routing
-
-   The current Kerberos protocol requires the client to explicitly
-   request a cross-realm TGT for each pair of realms on a referral
-   chain.  As a result, the client need to be aware of the trust
-   hierarchy and of any short-cut trusts (those that aren't parent-
-   child trusts).
-
-   Instead, using the server referral routing mechanism as defined in
-   Section 7, The KDC will determine the best path for the client and
-   return a cross-realm TGT as the referral TGT, and the target realm
-   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
-
-   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
-   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
-   response does not contain the PA-SERVER-REFERRAL padata.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                [Page 12]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-9.  Compatibility with Earlier Implementations of Name Canonicalization
-
-   The Microsoft Windows 2000 and Windows 2003 releases included an
-   earlier form of name-canonicalization [XPR].  Here are the
-   differences:
-
-   1) The TGS referral data is returned inside of the KDC message as
-      "encrypted pre-authentication data".
-
-
-
-          EncKDCRepPart   ::= SEQUENCE {
-                 key                [0] EncryptionKey,
-                 last-req           [1] LastReq,
-                 nonce              [2] UInt32,
-                 key-expiration     [3] KerberosTime OPTIONAL,
-                 flags              [4] TicketFlags,
-                 authtime           [5] KerberosTime,
-                 starttime          [6] KerberosTime OPTIONAL,
-                 endtime            [7] KerberosTime,
-                 renew-till         [8] KerberosTime OPTIONAL,
-                 srealm             [9] Realm,
-                 sname             [10] PrincipalName,
-                 caddr             [11] HostAddresses OPTIONAL,
-                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
-         }
-
-   2) The preauth data type definition in the encrypted preauth data is
-      as follows:
-
-
-
-          PA-SVR-REFERRAL-INFO       20
-
-          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
-                 referred-name   [1] PrincipalName OPTIONAL,
-                 referred-realm  [0] Realm
-          }}
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                [Page 13]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-10.  Security Considerations
-
-   For the AS exchange case, it is important that the logon mechanism
-   not trust a name that has not been used to authenticate the user.
-   For example, the name that the user enters as part of a logon
-   exchange may not be the name that the user authenticates as, given
-   that the KDC_ERR_WRONG_REALM error may have been returned.  The
-   relevant Kerberos naming information for logon (if any), is the
-   client name and client realm in the service ticket targeted at the
-   workstation that was obtained using the user's initial TGT.
-
-   How the client name and client realm is mapped into a local account
-   for logon is a local matter, but the client logon mechanism MUST use
-   additional information such as the client realm and/or authorization
-   attributes from the service ticket presented to the workstation by
-   the user, when mapping the logon credentials to a local account on
-   the workstation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                [Page 14]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-11.  Acknowledgments
-
-   The authors wish to thank Ken Raeburn for his comments and
-   suggestions.
-
-   Sam Hartman, Ken Raeburn, and authors came up with the idea of using
-   the ticket key to encrypt the referral data, which prevents cut and
-   paste attack using the referral data and referral TGTs.
-
-   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
-   version of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                [Page 15]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-12.  References
-
-12.1  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [KRBCLR]   Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 
-              Kerberos Network Authentication Service (V5)", 
-              draft-ietf-krb-wg-kerberos-clarifications. Work in 
-              progress.
-              
-   [RFC822]   Crocker, D., "Standard for the Format of ARPA Internet 
-              Text Messages", RFC 822, August 1982.
-
-12.2  Informative References
-
-   [XPR]      Trostle, J., Kosinovsky, I., and Swift, M., 
-              "Implementation of Crossrealm Referral Handling in the 
-              MIT Kerberos Client", In Network and Distributed System 
-              Security Symposium, February 2001.
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: lzhu@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: karthikj@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                [Page 16]
-
-Internet-Draft               KDC Referrals                  October 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu & Jaganathan         Expires April 25, 2005                [Page 17]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-06.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-06.txt
deleted file mode 100644
index 238baaea8..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-06.txt
+++ /dev/null
@@ -1,733 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                             K. Jaganathan
-Updates: 4120 (if approved)                        Microsoft Corporation
-Expires: January 20, 2006                                  July 19, 2005
-
-
-           Generating KDC Referrals to locate Kerberos realms
-                draft-ietf-krb-wg-kerberos-referrals-06
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 20, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   The memo documents a method for a Kerberos Key Distribution Center
-   (KDC) to respond to client requests for Kerberos tickets when the
-   client does not have detailed configuration information on the realms
-   of users or services.  The KDC will handle requests for principals in
-   other realms by returning either a referral error or a cross-realm
-   TGT to another realm on the referral path.  The clients will use this
-   referral information to reach the realm of the target principal and
-   then receive the ticket.
-
-
-
-Zhu & Jaganathan        Expires January 20, 2006                [Page 1]
-
-Internet-Draft                KDC Referrals                    July 2005
-
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.   Conventions Used in This Document  . . . . . . . . . . . . .   4
-   3.   Requesting a Referral  . . . . . . . . . . . . . . . . . . .   4
-   4.   Realm Organization Model . . . . . . . . . . . . . . . . . .   5
-   5.   Client Name Canonicalization . . . . . . . . . . . . . . . .   5
-   6.   Client Referrals . . . . . . . . . . . . . . . . . . . . . .   6
-   7.   Server Referrals . . . . . . . . . . . . . . . . . . . . . .   7
-   8.   Cross Realm Routing  . . . . . . . . . . . . . . . . . . . .   9
-   9.   Compatibility with Earlier Implementations of Name
-        Canonicalization . . . . . . . . . . . . . . . . . . . . . .   9
-   10.  Security Considerations  . . . . . . . . . . . . . . . . . .  10
-   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  11
-   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  11
-     12.1   Normative References . . . . . . . . . . . . . . . . . .  11
-     12.2   Informative References . . . . . . . . . . . . . . . . .  11
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  12
-        Intellectual Property and Copyright Statements . . . . . . .  13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan        Expires January 20, 2006                [Page 2]
-
-Internet-Draft                KDC Referrals                    July 2005
-
-
-1.  Introduction
-
-   Current implementations of the Kerberos AS and TGS protocols, as
-   defined in [RFC4120], use principal names constructed from a known
-   user or service name and realm.  A service name is typically
-   constructed from a name of the service and the DNS host name of the
-   computer that is providing the service.  Many existing deployments of
-   Kerberos use a single Kerberos realm where all users and services
-   would be using the same realm.  However in an environment where there
-   are multiple trusted Kerberos realms, the client needs to be able to
-   determine what realm a particular user or service is in before making
-   an AS or TGS request.  Traditionally this requires client
-   configuration to make this possible.
-
-   When having to deal with multiple trusted realms, users are forced to
-   know what realm they are in before they can obtain a ticket granting
-   ticket (TGT) with an AS request.  However, in many cases the user
-   would like to use a more familiar name that is not directly related
-   to the realm of their Kerberos principal name.  A good example of
-   this is an RFC 822 style email name.  This document describes a
-   mechanism that would allow a user to specify a user principal name
-   that is an alias for the user's Kerberos principal name.  In practice
-   this would be the name that the user specifies to obtain a TGT from a
-   Kerberos KDC.  The user principal name no longer has a direct
-   relationship with the Kerberos principal or realm.  Thus the
-   administrator is able to move the user's principal to other realms
-   without the user having to know that it happened.
-
-   Once a user has a TGT, they would like to be able to access services
-   in any trusted Kerberos realm.  To do this requires that the client
-   be able to determine what realm the target service principal is in
-   before making the TGS request.  Current implementations of Kerberos
-   typically have a table that maps DNS host names to corresponding
-   Kerberos realms.  In order for this to work on the client, each
-   application canonicalizes the host name of the service, for example
-   by doing a DNS lookup followed by a reverse lookup using the returned
-   IP address.  The returned primary host name is then used in the
-   construction of the principal name for the target service.  In order
-   for the correct realm to be added for the target host, the mapping
-   table [domain_to_realm] is consulted for the realm corresponding to
-   the DNS host name.  The corresponding realm is then used to complete
-   the target service principal name.
-
-   This traditional mechanism requires that each client have very
-   detailed configuration information about the hosts that are providing
-   services and their corresponding realms.  Having client side
-   configuration information can be very costly from an administration
-   point of view - especially if there are many realms and computers in
-
-
-
-Zhu & Jaganathan        Expires January 20, 2006                [Page 3]
-
-Internet-Draft                KDC Referrals                    July 2005
-
-
-   the environment.
-
-   There are also cases where specific DNS aliases (local names) have
-   been setup in an organization to refer to a server in another
-   organization (remote server).  The server has different DNS names in
-   each organization and each organization has a Kerberos realm that is
-   configured to service DNS names within that organization.  Ideally
-   users are able to authenticate to the server in the other
-   organization using the local server name.  This would mean that the
-   local realm be able to produce a ticket to the remote server under
-   its name.  You could give that remote server an identity in the local
-   realm and then have that remote server maintain a separate secret for
-   each alias it is known as.  Alternatively you could arrange to have
-   the local realm issue a referral to the remote realm and notify the
-   requesting client of the server's remote name that should be used in
-   order to request a ticket.
-
-   This memo proposes a solution for these problems and simplifies
-   administration by minimizing the configuration information needed on
-   each computer using Kerberos.  Specifically it describes a mechanism
-   to allow the KDC to handle canonicalization of names, provide for
-   principal aliases for users and services and provide a mechanism for
-   the KDC to determine the trusted realm authentication path by being
-   able to generate referrals to other realms in order to locate
-   principals.
-
-   Two kinds of KDC referrals are introduced in this memo:
-
-   1. Client referrals, in which the client doesn't know which realm
-      contains a user account.
-   2. Server referrals, in which the client doesn't know which realm
-      contains a server account.
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-3.  Requesting a Referral
-
-   In order to request referrals defined in section 5, 6, and 7, the
-   Kerberos client MUST explicitly request the canonicalize KDC option
-   (bit 15) [RFC4120] for the AS-REQ or TGS-REQ.  This flag indicates to
-   the KDC that the client is prepared to receive a reply that contains
-   a principal name other than the one requested.
-
-
-
-
-
-Zhu & Jaganathan        Expires January 20, 2006                [Page 4]
-
-Internet-Draft                KDC Referrals                    July 2005
-
-
-          KDCOptions ::= KerberosFlags
-                   -- canonicalize (15)
-                   -- other KDCOptions values omitted
-
-   The client should expect, when sending names with the "canonicalize"
-   KDC option, that names in the KDC's reply MAY be different than the
-   name in the request.  A referral TGT is a cross realm TGT that is
-   returned with the server name of the ticket being different from the
-   server name in the request [RFC4120].
-
-4.  Realm Organization Model
-
-   This memo assumes that the world of principals is arranged on
-   multiple levels: the realm, the enterprise, and the world.  A KDC may
-   issue tickets for any principal in its realm or cross-realm tickets
-   for realms with which it has a direct trust relationship.  The KDC
-   also has access to a trusted name service that can resolve any name
-   from within its enterprise into a realm.  This trusted name service
-   removes the need to use an un-trusted DNS lookup for name resolution.
-
-   For example, consider the following configuration, where lines
-   indicate trust relationships:
-
-                        MS.COM
-                      /        \
-                     /          \
-              OFFICE.MS.COM  NTDEV.MS.COM
-
-   In this configuration, all users in the MS.COM enterprise could have
-   a principal name such as alice@MS.COM, with the same realm portion.
-   In addition, servers at MS.COM should be able to have DNS host names
-   from any DNS domain independent of what Kerberos realm their
-   principals reside in.
-
-5.  Client Name Canonicalization
-
-   A client account may have multiple principal names.  More useful,
-   though, is a globally unique name that allows unification of email
-   and security principal names.  For example, all users at MS may have
-   a client principal name of the form "joe@MS.COM" even though the
-   principals are contained in multiple realms.  This global name is
-   again an alias for the true client principal name, which indicates
-   what realm contains the principal.  Thus, accounts "alice" in the
-   realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as "alice@
-   MS.COM" and "bob@MS.COM".
-
-   This utilizes a new client principal name type, as the AS-REQ message
-   only contains a single realm field, and the realm portion of this
-
-
-
-Zhu & Jaganathan        Expires January 20, 2006                [Page 5]
-
-Internet-Draft                KDC Referrals                    July 2005
-
-
-   name doesn't correspond to any Kerberos realm.  Thus, the entire name
-   "alice@MS.COM" is transmitted as a single component in the client
-   name field of the AS-REQ message, with a name type of NT-ENTERPRISE
-   [RFC4120].  The KDC will recognize this name type and then transform
-   the requested name into the true principal name.  The true principal
-   name can be using a name type different from the requested name type.
-   Typically the true principal name will be a NT-PRINCIPAL [RFC4120].
-
-   If the "canonicalize" KDC option is set, then the KDC MAY change the
-   client principal name and type in the AS response and ticket returned
-   from the name type of the client name in the request.  For example
-   the AS request may specify a client name of "bob@MS.COM" as an NT-
-   ENTERPRISE name with the "canonicalize" KDC option set and the KDC
-   will return with a client name of "104567" as a NT-UID.
-
-   It is assumed that the client discovers whether the KDC supports the
-   NT-ENTERPRISE name type via out of band mechanisms.
-
-6.  Client Referrals
-
-   The simplest form of ticket referral is for a user requesting a
-   ticket using an AS-REQ.  In this case, the client machine will send
-   the AS-REQ to a convenient trusted realm, for example the realm of
-   the client machine.  In the case of the name alice@MS.COM, the client
-   MAY optimistically choose to send the request to MS.COM.  The realm
-   in the AS-REQ is always the name of the realm that the request is for
-   as specified in [RFC4120].
-
-   The KDC will try to lookup the name in its local account database.
-   If the account is present in the realm of the request, it SHOULD
-   return a KDC reply structure with the appropriate ticket.
-
-   If the account is not present in the realm specified in the request
-   and the "canonicalize" KDC option is set, the KDC will try to lookup
-   the entire name, alice@MS.COM, using a name service.  If this lookup
-   is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN
-   [RFC4120].  If the lookup is successful, it MUST return an error
-   KDC_ERR_WRONG_REALM [RFC4120] and in the error message the crealm
-   field will contain either the true realm of the client or another
-   realm that MAY have better information about the client's true realm.
-   The client SHALL NOT use a cname returned from a referral until that
-   name is validated.
-
-   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
-   new AS request with the same client principal name used to generate
-   the first referral to the realm specified by the realm field of the
-   Kerberos error message from the first request.  The client SHOULD
-   repeat these steps until it finds the true realm of the client.  To
-
-
-
-Zhu & Jaganathan        Expires January 20, 2006                [Page 6]
-
-Internet-Draft                KDC Referrals                    July 2005
-
-
-   avoid infinite referral loops, an implementation should limit the
-   number of referrals.  A suggested limit is 5 referrals before giving
-   up.
-
-   In Microsoft's current implementation through the use of global
-   catalogs any domain in one forest is reachable from any other domain
-   in the same forest or another trusted forest with 3 or less
-   referrals.  A forest is a collection of realms with hierarchical
-   trust relationships: there can be multiple trust trees in a forest;
-   each child and parent realm pair and each root realm pair have
-   bidirectional transitive direct rusts between them.
-
-   The true principal name of the client, returned in AS-REQ, can be
-   validated in a subsequent TGS message exchange where its value is
-   communicated back to the KDC via the authenticator in the PA-TGS-REQ
-   padata [RFC4120].
-
-7.  Server Referrals
-
-   The primary difference in server referrals is that the KDC MUST
-   return a referral TGT rather than an error message as is done in the
-   client referrals.  There needs to be a place to include in the reply
-   information about what realm contains the server.  This is done by
-   returning information about the server name in the pre-authentication
-   data field of the KDC reply [RFC4120], as specified later in this
-   section.
-
-   If the KDC resolves the server principal name into a principal in the
-   realm specified by the service realm name, it will return a normal
-   ticket.
-
-   If the "canonicalize" flag in the KDC options is not set, the KDC
-   MUST only look up the name as a normal principal name in the
-   specified server realm.  If the "canonicalize" flag in the KDC
-   options is set and the KDC doesn't find the principal locally, the
-   KDC MAY return a cross-realm ticket granting ticket to the next hop
-   on the trust path towards a realm that may be able to resolve the
-   principal name.  The true principal name of the server SHALL be
-   returned in the padata of the reply if it is different from what is
-   specified the request.
-
-   When a referral TGT is returned, the KDC MUST return the target realm
-   for the referral TGT as an KDC supplied pre-authentication data
-   element in the response.  This referral information in pre-
-   authentication data MUST be encrypted using the session key from the
-   reply ticket.  The key usage value for the encryption operation used
-   by PA-SERVER-REFERRAL is 26.
-
-
-
-
-Zhu & Jaganathan        Expires January 20, 2006                [Page 7]
-
-Internet-Draft                KDC Referrals                    July 2005
-
-
-   The pre-authentication data returned by the KDC, which contains the
-   referred realm and the true principal name of server, is encoded in
-   DER as follows.
-
-          PA-SERVER-REFERRAL      25
-
-          PA-SERVER-REFERRAL-DATA ::= EncryptedData
-                                -- ServerReferralData --
-
-          ServerReferralData ::= SEQUENCE {
-                 referred-realm         [0] Realm OPTIONAL,
-                                -- target realm of the referral TGT
-                 true-principal-name    [1] PrincipalName OPTIONAL,
-                                -- true server principal name
-                 ...
-          }
-
-   Clients SHALL NOT accept a reply ticket, whose the server principal
-   name is different from that of the request, if the KDC response does
-   not contain a PA-SERVER-REFERRAL padata entry.
-
-   The referred-realm field is present if and only if the returned
-   ticket is a referral TGT, not a service ticket for the requested
-   server principal.
-
-   When a referral TGT is returned and the true-principal-name field is
-   present, the client MUST use that name in the subsequent requests to
-   the server realm when following the referral.
-
-   Client SHALL NOT accept a true server principal name for a service
-   ticket if the true-principal-name field is not present in the PA-
-   SERVER-REFERRAL data.
-
-   The client will use this referral information to request a chain of
-   cross-realm ticket granting tickets until it reaches the realm of the
-   server, and can then expect to receive a valid service ticket.
-
-   However an implementation should limit the number of referrals that
-   it processes to avoid infinite referral loops.  A suggested limit is
-   5 referrals before giving up.
-
-   Here is an example of a client requesting a service ticket for a
-   service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM.
-
-
-
-
-
-
-
-
-Zhu & Jaganathan        Expires January 20, 2006                [Page 8]
-
-Internet-Draft                KDC Referrals                    July 2005
-
-
-          +NC = Canonicalize KDCOption set
-          +PA-REFERRAL = returned PA-SERVER-REFERRAL
-          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM
-          S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
-             containing MS.COM as the referred realm with no
-             true-principal-name
-          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM
-          S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL
-             containing NTDEV.MS.COM as the referred realm with no
-             true-principal-name
-          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM
-          S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM
-
-
-8.  Cross Realm Routing
-
-   The current Kerberos protocol requires the client to explicitly
-   request a cross-realm TGT for each pair of realms on a referral
-   chain.  As a result, the client need to be aware of the trust
-   hierarchy and of any short-cut trusts (those that aren't parent-
-   child trusts).
-
-   Instead, using the server referral routing mechanism as defined in
-   Section 7, The KDC will determine the best path for the client and
-   return a cross-realm TGT as the referral TGT, and the target realm
-   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
-
-   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
-   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
-   response does not contain the PA-SERVER-REFERRAL padata.
-
-9.  Compatibility with Earlier Implementations of Name Canonicalization
-
-   The Microsoft Windows 2000 and Windows 2003 releases included an
-   earlier form of name-canonicalization [XPR].  Here are the
-   differences:
-
-   1) The TGS referral data is returned inside of the KDC message as
-      "encrypted pre-authentication data".
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan        Expires January 20, 2006                [Page 9]
-
-Internet-Draft                KDC Referrals                    July 2005
-
-
-          EncKDCRepPart   ::= SEQUENCE {
-                 key                [0] EncryptionKey,
-                 last-req           [1] LastReq,
-                 nonce              [2] UInt32,
-                 key-expiration     [3] KerberosTime OPTIONAL,
-                 flags              [4] TicketFlags,
-                 authtime           [5] KerberosTime,
-                 starttime          [6] KerberosTime OPTIONAL,
-                 endtime            [7] KerberosTime,
-                 renew-till         [8] KerberosTime OPTIONAL,
-                 srealm             [9] Realm,
-                 sname             [10] PrincipalName,
-                 caddr             [11] HostAddresses OPTIONAL,
-                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
-         }
-
-   2) The preauth data type definition in the encrypted preauth data is
-      as follows:
-
-
-
-          PA-SVR-REFERRAL-INFO       20
-
-          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
-                 referred-name   [1] PrincipalName OPTIONAL,
-                 referred-realm  [0] Realm
-          }}
-
-   3) When [PKINIT] is used, the NT-ENTERPRISE client name is encoded as
-      a Subject Alternative Name (SAN) extension [RFC3280] in the
-      client's X.509 certificate.  The type of the otherName field for
-      this SAN extension is AnotherName [RFC3280].  The type-id field of
-      the type AnotherName is id-ms-sc-logon-upn
-      (1.3.6.1.4.1.311.20.2.3) and the value field of the type
-      AnotherName is a KerberosString [RFC4120].  The value of this
-      KerberosString type is the single component in the name-string
-      [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
-
-10.  Security Considerations
-
-   For the AS exchange case, it is important that the logon mechanism
-   not trust a name that has not been used to authenticate the user.
-   For example, the name that the user enters as part of a logon
-   exchange may not be the name that the user authenticates as, given
-   that the KDC_ERR_WRONG_REALM error may have been returned.  The
-   relevant Kerberos naming information for logon (if any), is the
-   client name and client realm in the service ticket targeted at the
-   workstation that was obtained using the user's initial TGT.
-
-
-
-Zhu & Jaganathan        Expires January 20, 2006               [Page 10]
-
-Internet-Draft                KDC Referrals                    July 2005
-
-
-   How the client name and client realm is mapped into a local account
-   for logon is a local matter, but the client logon mechanism MUST use
-   additional information such as the client realm and/or authorization
-   attributes from the service ticket presented to the workstation by
-   the user, when mapping the logon credentials to a local account on
-   the workstation.
-
-11.  Acknowledgments
-
-   The authors wish to thank Ken Raeburn for his comments and
-   suggestions.
-
-   Sam Hartman, Ken Raeburn, and authors came up with the idea of using
-   the ticket key to encrypt the referral data, which prevents cut and
-   paste attack using the referral data and referral TGTs.
-
-   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
-   version of this document.
-
-12.  References
-
-12.1  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-                            
-   [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
-              cat-kerberos-pk-init.  Work in Progress. 
-
-12.2  Informative References
-
-   [XPR]      Trostle, J., Kosinovsky, I., and Swift, M., 
-              "Implementation of Crossrealm Referral Handling in the 
-              MIT Kerberos Client", In Network and Distributed System 
-              Security Symposium, February 2001.
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan        Expires January 20, 2006               [Page 11]
-
-Internet-Draft                KDC Referrals                    July 2005
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Jaganathan        Expires January 20, 2006               [Page 12]
-
-Internet-Draft                KDC Referrals                    July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu & Jaganathan        Expires January 20, 2006               [Page 13]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-08.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-08.txt
deleted file mode 100644
index 37061a2e1..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-08.txt
+++ /dev/null
@@ -1,896 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                         K. Raeburn
-Internet-Draft                                                       MIT
-Updates: 4120 (if approved)                                       L. Zhu
-Expires: December 27, 2006                                 K. Jaganathan
-                                                   Microsoft Corporation
-                                                           June 25, 2006
-
-
-           Generating KDC Referrals to Locate Kerberos Realms
-                draft-ietf-krb-wg-kerberos-referrals-08
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on December 27, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   The memo documents a method for a Kerberos Key Distribution Center
-   (KDC) to respond to client requests for Kerberos tickets when the
-   client does not have detailed configuration information on the realms
-   of users or services.  The KDC will handle requests for principals in
-   other realms by returning either a referral error or a cross-realm
-   TGT to another realm on the referral path.  The clients will use this
-
-
-
-Raeburn, et al.         Expires December 27, 2006               [Page 1]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-   referral information to reach the realm of the target principal and
-   then receive the ticket.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
-   3.  Requesting a Referral  . . . . . . . . . . . . . . . . . . . .  4
-   4.  Realm Organization Model . . . . . . . . . . . . . . . . . . .  5
-   5.  Client Name Canonicalization . . . . . . . . . . . . . . . . .  5
-   6.  Client Referrals . . . . . . . . . . . . . . . . . . . . . . .  7
-   7.  Server Referrals . . . . . . . . . . . . . . . . . . . . . . .  8
-   8.  Server Name Canonicalization (Informative) . . . . . . . . . . 10
-   9.  Cross Realm Routing  . . . . . . . . . . . . . . . . . . . . . 10
-   10. Caching Information  . . . . . . . . . . . . . . . . . . . . . 11
-   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
-   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-     14.1.  Normative References  . . . . . . . . . . . . . . . . . . 12
-     14.2.  Informative References  . . . . . . . . . . . . . . . . . 12
-   Appendix A.  Compatibility with Earlier Implementations of
-                Name Canonicalization . . . . . . . . . . . . . . . . 13
-   Appendix B.  Document history  . . . . . . . . . . . . . . . . . . 14
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
-   Intellectual Property and Copyright Statements . . . . . . . . . . 16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn, et al.         Expires December 27, 2006               [Page 2]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-1.  Introduction
-
-   Current implementations of the Kerberos AS and TGS protocols, as
-   defined in [RFC4120], use principal names constructed from a known
-   user or service name and realm.  A service name is typically
-   constructed from a name of the service and the DNS host name of the
-   computer that is providing the service.  Many existing deployments of
-   Kerberos use a single Kerberos realm where all users and services
-   would be using the same realm.  However in an environment where there
-   are multiple trusted Kerberos realms, the client needs to be able to
-   determine what realm a particular user or service is in before making
-   an AS or TGS request.  Traditionally this requires client
-   configuration to make this possible.
-
-   When having to deal with multiple trusted realms, users are forced to
-   know what realm they are in before they can obtain a ticket granting
-   ticket (TGT) with an AS request.  However, in many cases the user
-   would like to use a more familiar name that is not directly related
-   to the realm of their Kerberos principal name.  A good example of
-   this is an RFC 822 style email name.  This document describes a
-   mechanism that would allow a user to specify a user principal name
-   that is an alias for the user's Kerberos principal name.  In practice
-   this would be the name that the user specifies to obtain a TGT from a
-   Kerberos KDC.  The user principal name no longer has a direct
-   relationship with the Kerberos principal or realm.  Thus the
-   administrator is able to move the user's principal to other realms
-   without the user having to know that it happened.
-
-   Once a user has a TGT, they would like to be able to access services
-   in any trusted Kerberos realm.  To do this requires that the client
-   be able to determine what realm the target service principal is in
-   before making the TGS request.  Current implementations of Kerberos
-   typically have a table that maps DNS host names to corresponding
-   Kerberos realms.  In order for this to work on the client, each
-   application canonicalizes the host name of the service, for example
-   by doing a DNS lookup followed by a reverse lookup using the returned
-   IP address.  The returned primary host name is then used in the
-   construction of the principal name for the target service.  In order
-   for the correct realm to be added for the target host, the mapping
-   table [domain_to_realm] is consulted for the realm corresponding to
-   the DNS host name.  The corresponding realm is then used to complete
-   the target service principal name.
-
-   This traditional mechanism requires that each client have very
-   detailed configuration information about the hosts that are providing
-   services and their corresponding realms.  Having client side
-   configuration information can be very costly from an administration
-   point of view - especially if there are many realms and computers in
-
-
-
-Raeburn, et al.         Expires December 27, 2006               [Page 3]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-   the environment.
-
-   There are also cases where specific DNS aliases (local names) have
-   been setup in an organization to refer to a server in another
-   organization (remote server).  The server has different DNS names in
-   each organization and each organization has a Kerberos realm that is
-   configured to service DNS names within that organization.  Ideally
-   users are able to authenticate to the server in the other
-   organization using the local server name.  This would mean that the
-   local realm be able to produce a ticket to the remote server under
-   its name.  You could give that remote server an identity in the local
-   realm and then have that remote server maintain a separate secret for
-   each alias it is known as.  Alternatively you could arrange to have
-   the local realm issue a referral to the remote realm and notify the
-   requesting client of the server's remote name that should be used in
-   order to request a ticket.
-
-   This memo proposes a solution for these problems and simplifies
-   administration by minimizing the configuration information needed on
-   each computer using Kerberos.  Specifically it describes a mechanism
-   to allow the KDC to handle canonicalization of names, provide for
-   principal aliases for users and services and provide a mechanism for
-   the KDC to determine the trusted realm authentication path by being
-   able to generate referrals to other realms in order to locate
-   principals.
-
-   Two kinds of KDC referrals are introduced in this memo:
-
-   1. Client referrals, in which the client doesn't know which realm
-      contains a user account.
-   2. Server referrals, in which the client doesn't know which realm
-      contains a server account.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  Requesting a Referral
-
-   In order to request referrals defined in section 5, 6, and 7, the
-   Kerberos client MUST explicitly request the canonicalize KDC option
-   (bit 15) [RFC4120] for the AS-REQ or TGS-REQ.  This flag indicates to
-   the KDC that the client is prepared to receive a reply that contains
-   a principal name other than the one requested.
-
-
-
-Raeburn, et al.         Expires December 27, 2006               [Page 4]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-          KDCOptions ::= KerberosFlags
-                   -- canonicalize (15)
-                   -- other KDCOptions values omitted
-
-   The client should expect, when sending names with the "canonicalize"
-   KDC option, that names in the KDC's reply MAY be different than the
-   name in the request.  A referral TGT is a cross realm TGT that is
-   returned with the server name of the ticket being different from the
-   server name in the request [RFC4120].
-
-
-4.  Realm Organization Model
-
-   This memo assumes that the world of principals is arranged on
-   multiple levels: the realm, the enterprise, and the world.  A KDC may
-   issue tickets for any principal in its realm or cross-realm tickets
-   for realms with which it has a direct trust relationship.  The KDC
-   also has access to a trusted name service that can resolve any name
-   from within its enterprise into a realm.  This trusted name service
-   removes the need to use an un-trusted DNS lookup for name resolution.
-
-   For example, consider the following configuration, where lines
-   indicate trust relationships:
-
-                        MS.COM
-                      /        \
-                     /          \
-              OFFICE.MS.COM  NTDEV.MS.COM
-
-   In this configuration, all users in the MS.COM enterprise could have
-   a principal name such as alice@MS.COM, with the same realm portion.
-   In addition, servers at MS.COM should be able to have DNS host names
-   from any DNS domain independent of what Kerberos realm their
-   principals reside in.
-
-
-5.  Client Name Canonicalization
-
-   A client account may have multiple principal names.  More useful,
-   though, is a globally unique name that allows unification of email
-   and security principal names.  For example, all users at MS may have
-   a client principal name of the form "joe@MS.COM" even though the
-   principals are contained in multiple realms.  This global name is
-   again an alias for the true client principal name, which indicates
-   what realm contains the principal.  Thus, accounts "alice" in the
-   realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may log on as "alice@
-   MS.COM" and "bob@MS.COM".
-
-
-
-
-Raeburn, et al.         Expires December 27, 2006               [Page 5]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-   This utilizes a new client principal name type, as the AS-REQ message
-   only contains a single realm field, and the realm portion of this
-   name doesn't correspond to any Kerberos realm.  Thus, the entire name
-   "alice@MS.COM" is transmitted as a single component in the client
-   name field of the AS-REQ message, with a name type of NT-ENTERPRISE
-   [RFC4120] (and the local realm name).  The KDC will recognize this
-   name type and then transform the requested name into the true
-   principal name.  The true principal name can be using a name type
-   different from the requested name type.  Typically the true principal
-   name will be a NT-PRINCIPAL [RFC4120].
-
-   If the "canonicalize" KDC option is set, then the KDC MAY change the
-   client principal name and type in the AS response and ticket returned
-   from the name type of the client name in the request, and include a
-   mandatory PA-DATA object authenticating the client name mapping:
-
-   PA-CLIENT-CANONICALIZED ::= SEQUENCE {
-     names          [0] SEQUENCE {
-       requested-name [0] PrincipalName,
-       real-name      [1] PrincipalName
-     },
-     canon-checksum [1] Checksum
-   }
-
-   The canon-checksum field is computed over the DER encoding of the
-   names sequences, using the returned session key and a key usage value
-   of (TBD).
-
-   If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is
-   not included.  If the client name is changed, and the PA-CLIENT-
-   CANONICALIZED field does not exist, or the checksum cannot be
-   verified, or the requested-name field doesn't match the originally-
-   transmitted request, the client should discard the response.
-
-   For example the AS request may specify a client name of "bob@MS.COM"
-   as an NT-ENTERPRISE name with the "canonicalize" KDC option set and
-   the KDC will return with a client name of "104567" as a NT-UID, and a
-   PA-CLIENT-CANONICALIZED field listing the NT-ENTERPRISE "bob@MS.COM"
-   principal as the requested-name and the NT-UID "104567" principal as
-   the real-name.
-
-   It is assumed that the client discovers whether the KDC supports the
-   NT-ENTERPRISE name type via out of band mechanisms.
-
-   In order to enable one party in a user-to-user exchange to confirm
-   the identity of another when only the alias is known, the KDC MAY
-   include the following authorization data element, wrapped in AD-IF-
-   RELEVANT, in the initial credentials and copy it from a ticket-
-
-
-
-Raeburn, et al.         Expires December 27, 2006               [Page 6]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-   granting ticket into additional credentials:
-
-   AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD --
-     login-alias  [0] PrincipalName,
-     checksum     [1] Checksum
-   }
-
-   (Q: Wrapped inside KDCIssued too?  Use SEQUENCE OF PrincipalName?)
-
-   The checksum is computed over the DER encoding of the login-alias
-   field using (WHICH KEY?  If recipient can forge it, the KDC can't
-   trust it when returned, and would have to verify that the alias is
-   valid before copying it to additional credentials) and a key usage
-   number of (TBD).
-
-   The recipient of this authenticator must check the AD-LOGIN-ALIAS
-   name, if present, in addition to the normal client name field,
-   against the identity of the party with which it wishes to
-   authenticate; either should be allowed to match.  (Note that this is
-   not backwards compatible with [RFC4120]; if the server side of the
-   user-to-user exchange does not support this extension, and does not
-   know the true principal name, authentication may fail if the alias is
-   sought in the client name field.)
-
-
-6.  Client Referrals
-
-   The simplest form of ticket referral is for a user requesting a
-   ticket using an AS-REQ.  In this case, the client machine will send
-   the AS-REQ to a convenient trusted realm, for example the realm of
-   the client machine.  In the case of the name alice@MS.COM, the client
-   MAY optimistically choose to send the request to MS.COM.  The realm
-   in the AS-REQ is always the name of the realm that the request is for
-   as specified in [RFC4120].
-
-   The KDC will try to lookup the name in its local account database.
-   If the account is present in the realm of the request, it SHOULD
-   return a KDC reply structure with the appropriate ticket.
-
-   If the account is not present in the realm specified in the request
-   and the "canonicalize" KDC option is set, the KDC will try to lookup
-   the entire name, alice@MS.COM, using a name service.  If this lookup
-   is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN
-   [RFC4120].  If the lookup is successful, it MUST return an error
-   KDC_ERR_WRONG_REALM [RFC4120] and in the error message the crealm
-   field will contain either the true realm of the client or another
-   realm that MAY have better information about the client's true realm.
-   The client SHALL NOT use a cname returned from a referral until that
-
-
-
-Raeburn, et al.         Expires December 27, 2006               [Page 7]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-   name is validated.
-
-   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
-   new AS request with the same client principal name used to generate
-   the first referral to the realm specified by the realm field of the
-   Kerberos error message from the first request.  (The client realm
-   name will be updated in the new request to refer to this new realm.)
-   The client SHOULD repeat these steps until it finds the true realm of
-   the client.  To avoid infinite referral loops, an implementation
-   should limit the number of referrals.  A suggested limit is 5
-   referrals before giving up.
-
-   Since the same client name is sent to the referring and referred-to
-   realms, both realms must recognize the same client names.  In
-   particular, the referring realm cannot (usefully) define principal
-   name aliases that the referred-to realm will not know.
-
-   The true principal name of the client, returned in AS-REQ, can be
-   validated in a subsequent TGS message exchange where its value is
-   communicated back to the KDC via the authenticator in the PA-TGS-REQ
-   padata [RFC4120].
-
-
-7.  Server Referrals
-
-   The primary difference in server referrals is that the KDC MUST
-   return a referral TGT rather than an error message as is done in the
-   client referrals.  There needs to be a place to include in the reply
-   information about what realm contains the server.  This is done by
-   returning information about the server name in the pre-authentication
-   data field of the KDC reply [RFC4120], as specified later in this
-   section.
-
-   If the KDC resolves the server principal name into a principal in the
-   realm specified by the service realm name, it will return a normal
-   ticket.
-
-   If the "canonicalize" flag in the KDC options is not set, the KDC
-   MUST only look up the name as a normal principal name in the
-   specified server realm.  If the "canonicalize" flag in the KDC
-   options is set and the KDC doesn't find the principal locally, the
-   KDC MAY return a cross-realm ticket granting ticket to the next hop
-   on the trust path towards a realm that may be able to resolve the
-   principal name.  The true principal name of the server SHALL be
-   returned in the padata of the reply if it is different from what is
-   specified the request.
-
-   When a referral TGT is returned, the KDC MUST return the target realm
-
-
-
-Raeburn, et al.         Expires December 27, 2006               [Page 8]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-   for the referral TGT as an KDC supplied pre-authentication data
-   element in the response.  This referral information in pre-
-   authentication data MUST be encrypted using the session key from the
-   reply ticket.  The key usage value for the encryption operation used
-   by PA-SERVER-REFERRAL is 26.
-
-   The pre-authentication data returned by the KDC, which contains the
-   referred realm and the true principal name of server, is encoded in
-   DER as follows.
-
-          PA-SERVER-REFERRAL      25
-
-          PA-SERVER-REFERRAL-DATA ::= EncryptedData
-                                -- ServerReferralData --
-
-          ServerReferralData ::= SEQUENCE {
-                 referred-realm           [0] Realm OPTIONAL,
-                                -- target realm of the referral TGT
-                 true-principal-name      [1] PrincipalName OPTIONAL,
-                                -- true server principal name
-                 requested-principal-name [2] PrincipalName OPTIONAL,
-                                -- requested server name
-                 ...
-          }
-
-   Clients SHALL NOT accept a reply ticket, whose the server principal
-   name is different from that of the request, if the KDC response does
-   not contain a PA-SERVER-REFERRAL padata entry.
-
-   The requested-principal-name MUST be included by the KDC, and MUST be
-   verified by the client, if the client sent an AS-REQ, as protection
-   against a man-in-the-middle modification to the AS-REQ message.
-
-   (Note that with the forthcoming rfc1510ter, the AS-REP may include an
-   option checksum of the AS-REQ, in which case this check would no
-   longer be necessary.)
-
-   The referred-realm field is present if and only if the returned
-   ticket is a referral TGT, not a service ticket for the requested
-   server principal.
-
-   When a referral TGT is returned and the true-principal-name field is
-   present, the client MUST use that name in the subsequent requests to
-   the server realm when following the referral.
-
-   Client SHALL NOT accept a true server principal name for a service
-   ticket if the true-principal-name field is not present in the PA-
-   SERVER-REFERRAL data.
-
-
-
-Raeburn, et al.         Expires December 27, 2006               [Page 9]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-   The client will use this referral information to request a chain of
-   cross-realm ticket granting tickets until it reaches the realm of the
-   server, and can then expect to receive a valid service ticket.
-
-   However an implementation should limit the number of referrals that
-   it processes to avoid infinite referral loops.  A suggested limit is
-   5 referrals before giving up.
-
-   Here is an example of a client requesting a service ticket for a
-   service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM.
-
-          +NC = Canonicalize KDCOption set
-          +PA-REFERRAL = returned PA-SERVER-REFERRAL
-          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM
-          S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
-             containing MS.COM as the referred realm with no
-             true-principal-name
-          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM
-          S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL
-             containing NTDEV.MS.COM as the referred realm with no
-             true-principal-name
-          C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM
-          S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM
-
-   Note that any referral or alias processing of the server name in
-   user-to-user authentication should use the same data as client name
-   canonicalization or referral.  Otherwise, the name used by one user
-   to log in may not be useable by another for user-to-user
-   authentication to the first.
-
-
-8.  Server Name Canonicalization (Informative)
-
-   No attempt is being made in this document to provide a means for
-   dealing with local-realm server principal name canonicalization or
-   aliasing.  The most obvious use case for this would be a hostname-
-   based service principal name ("host/foobar.example.com"), with a DNS
-   alias ("foo") for the server host which is used by the client.  There
-   are other ways this can be handled, currently, though they may
-   require additional configuration on the application server or KDC or
-   both.
-
-
-9.  Cross Realm Routing
-
-   The current Kerberos protocol requires the client to explicitly
-   request a cross-realm TGT for each pair of realms on a referral
-   chain.  As a result, the client need to be aware of the trust
-
-
-
-Raeburn, et al.         Expires December 27, 2006              [Page 10]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-   hierarchy and of any short-cut trusts (those that aren't parent-
-   child trusts).
-
-   Instead, using the server referral routing mechanism as defined in
-   Section 7, The KDC will determine the best path for the client and
-   return a cross-realm TGT as the referral TGT, and the target realm
-   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
-
-   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
-   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
-   response does not contain the PA-SERVER-REFERRAL padata.
-
-
-10.  Caching Information
-
-   It is possible that the client may wish to get additional credentials
-   for the same service principal, perhaps with different authorization-
-   data restrictions or other changed attributes.  The return of a
-   server referral from a KDC can be taken as an indication that the
-   requested principal does not currently exist in the local realm.
-   Clearly, it would reduce network traffic if the clientn could cache
-   that information and use it when acquiring the second set of
-   credentials for a service, rather than always having to re-check with
-   the local KDC to see if the name has been created locally.
-
-   Rather than introduce a new timeout field for this cached
-   information, we can use the lifetime of the returned TGT in this
-   case.  When the TGT expires, the previously returned referral from
-   the local KDC should be considered invalid, and the local KDC must be
-   asked again for information for the desired service principal name.
-   If the client is still in contact with the service and needs to
-   reauthenticate to the same service regardless of local service
-   principal name assignments, it should use the referred-realm and
-   true-principal-name values when requesting new credentials.
-
-   Accordingly, KDC authors and maintainers should consider what factors
-   (e.g., DNS alias lifetimes) they may or may not wish to incorporate
-   into credential expiration times in cases of referrals.
-
-
-11.  Open Issues
-
-   When should client name aliases be included in credentials?
-
-   Should all known client name aliases be included, or only the one
-   used at initial ticket acquisition?
-
-
-
-
-
-Raeburn, et al.         Expires December 27, 2006              [Page 11]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-12.  Security Considerations
-
-   For the AS exchange case, it is important that the logon mechanism
-   not trust a name that has not been used to authenticate the user.
-   For example, the name that the user enters as part of a logon
-   exchange may not be the name that the user authenticates as, given
-   that the KDC_ERR_WRONG_REALM error may have been returned.  The
-   relevant Kerberos naming information for logon (if any), is the
-   client name and client realm in the service ticket targeted at the
-   workstation that was obtained using the user's initial TGT.
-
-   How the client name and client realm is mapped into a local account
-   for logon is a local matter, but the client logon mechanism MUST use
-   additional information such as the client realm and/or authorization
-   attributes from the service ticket presented to the workstation by
-   the user, when mapping the logon credentials to a local account on
-   the workstation.
-
-
-13.  Acknowledgments
-
-   Sam Hartman and authors came up with the idea of using the ticket key
-   to encrypt the referral data, which prevents cut and paste attack
-   using the referral data and referral TGTs.
-
-   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
-   version of this document.
-
-
-14.  References
-
-14.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-14.2.  Informative References
-
-   [I-D.ietf-cat-kerberos-pk-init]
-              Tung, B. and L. Zhu, "Public Key Cryptography for Initial
-              Authentication in Kerberos",
-              draft-ietf-cat-kerberos-pk-init-34 (work in progress),
-              February 2006.
-
-
-
-
-Raeburn, et al.         Expires December 27, 2006              [Page 12]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [XPR]      Trostle, J., Kosinovsky, I., and M. Swift, "Implementation
-              of Crossrealm Referral Handling in the MIT Kerberos
-              Client",  Network and Distributed System Security
-              Symposium, February 2001.
-
-
-Appendix A.  Compatibility with Earlier Implementations of Name
-             Canonicalization
-
-   The Microsoft Windows 2000 and Windows 2003 releases included an
-   earlier form of name-canonicalization [XPR].  Here are the
-   differences:
-
-   1) The TGS referral data is returned inside of the KDC message as
-      "encrypted pre-authentication data".
-
-
-
-          EncKDCRepPart   ::= SEQUENCE {
-                 key                [0] EncryptionKey,
-                 last-req           [1] LastReq,
-                 nonce              [2] UInt32,
-                 key-expiration     [3] KerberosTime OPTIONAL,
-                 flags              [4] TicketFlags,
-                 authtime           [5] KerberosTime,
-                 starttime          [6] KerberosTime OPTIONAL,
-                 endtime            [7] KerberosTime,
-                 renew-till         [8] KerberosTime OPTIONAL,
-                 srealm             [9] Realm,
-                 sname             [10] PrincipalName,
-                 caddr             [11] HostAddresses OPTIONAL,
-                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
-         }
-
-   2) The preauth data type definition in the encrypted preauth data is
-      as follows:
-
-
-
-
-
-
-
-
-
-
-Raeburn, et al.         Expires December 27, 2006              [Page 13]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-          PA-SVR-REFERRAL-INFO       20
-
-          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
-                 referred-name   [1] PrincipalName OPTIONAL,
-                 referred-realm  [0] Realm
-          }}
-
-   3) When [I-D.ietf-cat-kerberos-pk-init] is used, the NT-ENTERPRISE
-      client name is encoded as a Subject Alternative Name (SAN)
-      extension [RFC3280] in the client's X.509 certificate.  The type
-      of the otherName field for this SAN extension is AnotherName
-      [RFC3280].  The type-id field of the type AnotherName is id-ms-sc-
-      logon-upn (1.3.6.1.4.1.311.20.2.3) and the value field of the type
-      AnotherName is a KerberosString [RFC4120].  The value of this
-      KerberosString type is the single component in the name-string
-      [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
-
-   In Microsoft's current implementation through the use of global
-   catalogs any domain in one forest is reachable from any other domain
-   in the same forest or another trusted forest with 3 or less
-   referrals.  A forest is a collection of realms with hierarchical
-   trust relationships: there can be multiple trust trees in a forest;
-   each child and parent realm pair and each root realm pair have
-   bidirectional transitive direct rusts between them.
-
-   While we might want to permit multiple aliases to exist and even be
-   reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only
-   one alias to exist, so this question had not previously arisen.
-
-
-Appendix B.  Document history
-
-   08 Moved Microsoft implementation info to appendix.  Clarify lack of
-      local server name canonicalization.  Added optional authz-data for
-      login alias, to support user-to-user case.  Added requested-
-      principal-name to ServerReferralData.  Added discussion of caching
-      information, and referral TGT lifetime.
-   07 Re-issued with new editor.  Fixed up some references.  Started
-      history.
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn, et al.         Expires December 27, 2006              [Page 14]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-Authors' Addresses
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA  02139
-   US
-
-   Email: raeburn@mit.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn, et al.         Expires December 27, 2006              [Page 15]
-
-Internet-Draft                KDC Referrals                    June 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Raeburn, et al.         Expires December 27, 2006              [Page 16]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-09.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-09.txt
deleted file mode 100644
index 24e3ace21..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-09.txt
+++ /dev/null
@@ -1,896 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                         K. Raeburn
-Internet-Draft                                                       MIT
-Updates: 4120 (if approved)                                       L. Zhu
-Intended status: Standards Track                   Microsoft Corporation
-Expires: September 6, 2007                                 March 5, 2007
-
-
-           Generating KDC Referrals to Locate Kerberos Realms
-                draft-ietf-krb-wg-kerberos-referrals-09
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 6, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   The memo documents a method for a Kerberos Key Distribution Center
-   (KDC) to respond to client requests for Kerberos tickets when the
-   client does not have detailed configuration information on the realms
-   of users or services.  The KDC will handle requests for principals in
-   other realms by returning either a referral error or a cross-realm
-   TGT to another realm on the referral path.  The clients will use this
-   referral information to reach the realm of the target principal and
-
-
-
-Raeburn & Zhu           Expires September 6, 2007               [Page 1]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-   then receive the ticket.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
-   3.  Requesting a Referral  . . . . . . . . . . . . . . . . . . . .  4
-   4.  Realm Organization Model . . . . . . . . . . . . . . . . . . .  5
-   5.  Client Name Canonicalization . . . . . . . . . . . . . . . . .  5
-   6.  Client Referrals . . . . . . . . . . . . . . . . . . . . . . .  7
-   7.  Server Referrals . . . . . . . . . . . . . . . . . . . . . . .  8
-   8.  Server Name Canonicalization (Informative) . . . . . . . . . . 10
-   9.  Cross Realm Routing  . . . . . . . . . . . . . . . . . . . . . 10
-   10. Caching Information  . . . . . . . . . . . . . . . . . . . . . 11
-   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
-   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-     14.1.  Normative References  . . . . . . . . . . . . . . . . . . 12
-     14.2.  Informative References  . . . . . . . . . . . . . . . . . 12
-   Appendix A.  Compatibility with Earlier Implementations of
-                Name Canonicalization . . . . . . . . . . . . . . . . 13
-   Appendix B.  Document history  . . . . . . . . . . . . . . . . . . 14
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
-   Intellectual Property and Copyright Statements . . . . . . . . . . 16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn & Zhu           Expires September 6, 2007               [Page 2]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-1.  Introduction
-
-   Current implementations of the Kerberos AS and TGS protocols, as
-   defined in [RFC4120], use principal names constructed from a known
-   user or service name and realm.  A service name is typically
-   constructed from a name of the service and the DNS host name of the
-   computer that is providing the service.  Many existing deployments of
-   Kerberos use a single Kerberos realm where all users and services
-   would be using the same realm.  However in an environment where there
-   are multiple trusted Kerberos realms, the client needs to be able to
-   determine what realm a particular user or service is in before making
-   an AS or TGS request.  Traditionally this requires client
-   configuration to make this possible.
-
-   When having to deal with multiple trusted realms, users are forced to
-   know what realm they are in before they can obtain a ticket granting
-   ticket (TGT) with an AS request.  However, in many cases the user
-   would like to use a more familiar name that is not directly related
-   to the realm of their Kerberos principal name.  A good example of
-   this is an RFC 822 style email name.  This document describes a
-   mechanism that would allow a user to specify a user principal name
-   that is an alias for the user's Kerberos principal name.  In practice
-   this would be the name that the user specifies to obtain a TGT from a
-   Kerberos KDC.  The user principal name no longer has a direct
-   relationship with the Kerberos principal or realm.  Thus the
-   administrator is able to move the user's principal to other realms
-   without the user having to know that it happened.
-
-   Once a user has a TGT, they would like to be able to access services
-   in any trusted Kerberos realm.  To do this requires that the client
-   be able to determine what realm the target service principal is in
-   before making the TGS request.  Current implementations of Kerberos
-   typically have a table that maps DNS host names to corresponding
-   Kerberos realms.  The user-supplied host name or its domain component
-   is looked up in this table (often using the result of some form of
-   host name lookup performed with insecure DNS queries, in violation of
-   [RFC4120]).  The corresponding realm is then used to complete the
-   target service principal name.
-
-   This traditional mechanism requires that each client have very
-   detailed configuration information about the hosts that are providing
-   services and their corresponding realms.  Having client side
-   configuration information can be very costly from an administration
-   point of view - especially if there are many realms and computers in
-   the environment.
-
-   There are also cases where specific DNS aliases (local names) have
-   been setup in an organization to refer to a server in another
-
-
-
-Raeburn & Zhu           Expires September 6, 2007               [Page 3]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-   organization (remote server).  The server has different DNS names in
-   each organization and each organization has a Kerberos realm that is
-   configured to service DNS names within that organization.  Ideally
-   users are able to authenticate to the server in the other
-   organization using the local server name.  This would mean that the
-   local realm be able to produce a ticket to the remote server under
-   its name.  The administrator in the local realm could give that
-   remote server an identity in the local realm and then have that
-   remote server maintain a separate secret for each alias it is known
-   as.  Alternatively the administrator could arrange to have the local
-   realm issue a referral to the remote realm and notify the requesting
-   client of the server's remote name that should be used in order to
-   request a ticket.
-
-   This memo proposes a solution for these problems and simplifies
-   administration by minimizing the configuration information needed on
-   each computer using Kerberos.  Specifically it describes a mechanism
-   to allow the KDC to handle canonicalization of names, provide for
-   principal aliases for users and services and allow the KDC to
-   determine the trusted realm authentication path by being able to
-   generate referrals to other realms in order to locate principals.
-
-   Two kinds of KDC referrals are introduced in this memo:
-
-   1. Client referrals, in which the client doesn't know which realm
-      contains a user account.
-   2. Server referrals, in which the client doesn't know which realm
-      contains a server account.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  Requesting a Referral
-
-   In order to request referrals defined in section 5, 6, and 7, the
-   Kerberos client MUST explicitly request the canonicalize KDC option
-   (bit 15) [RFC4120] for the AS-REQ or TGS-REQ.  This flag indicates to
-   the KDC that the client is prepared to receive a reply that contains
-   a principal name other than the one requested.
-
-
-          KDCOptions ::= KerberosFlags
-                   -- canonicalize (15)
-
-
-
-Raeburn & Zhu           Expires September 6, 2007               [Page 4]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-                   -- other KDCOptions values omitted
-
-   The client should expect, when sending names with the "canonicalize"
-   KDC option, that names in the KDC's reply MAY be different than the
-   name in the request.  A referral TGT is a cross realm TGT that is
-   returned with the server name of the ticket being different from the
-   server name in the request [RFC4120].
-
-
-4.  Realm Organization Model
-
-   This memo assumes that the world of principals is arranged on
-   multiple levels: the realm, the enterprise, and the world.  A KDC may
-   issue tickets for any principal in its realm or cross-realm tickets
-   for realms with which it has a direct trust relationship.  The KDC
-   also has access to a trusted name service that can resolve any name
-   from within its enterprise into a realm.  This trusted name service
-   removes the need to use an un-trusted DNS lookup for name resolution.
-
-   For example, consider the following configuration, where lines
-   indicate trust relationships:
-
-                      EXAMPLE.COM
-                      /        \
-                     /          \
-          ADMIN.EXAMPLE.COM  DEV.EXAMPLE.COM
-
-   In this configuration, all users in the EXAMPLE.COM enterprise could
-   have principal names such as alice@EXAMPLE.COM, with the same realm
-   portion.  In addition, servers at EXAMPLE.COM should be able to have
-   DNS host names from any DNS domain independent of what Kerberos realm
-   their principals reside in.
-
-
-5.  Client Name Canonicalization
-
-   A client account may have multiple principal names.  More useful,
-   though, is a globally unique name that allows unification of email
-   and security principal names.  For example, all users at EXAMPLE.COM
-   may have a client principal name of the form "joe@EXAMPLE.COM" even
-   though the principals are contained in multiple realms.  This global
-   name is again an alias for the true client principal name, which
-   indicates what realm contains the principal.  Thus, accounts "alice"
-   in the realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log
-   on as "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM".
-
-   This utilizes a new client principal name type, as the AS-REQ message
-   only contains a single realm field, and the realm portion of this
-
-
-
-Raeburn & Zhu           Expires September 6, 2007               [Page 5]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-   name corresponds to the Kerberos realm with which the request is
-   made.  Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a
-   single component in the client name field of the AS-REQ message, with
-   a name type of NT-ENTERPRISE [RFC4120] (and the local realm name).
-   The KDC will recognize this name type and then transform the
-   requested name into the true principal name if the client account
-   resides in the local realm.  The true principal name can have a name
-   type different from the requested name type.  Typically the true
-   principal name will be a NT-PRINCIPAL [RFC4120].
-
-   If the "canonicalize" KDC option is set, then the KDC MAY change the
-   client principal name and type in the AS response and ticket returned
-   from the name type of the client name in the request, and include a
-   mandatory PA-DATA object authenticating the client name mapping:
-
-   ReferralInfo ::= SEQUENCE {
-     requested-name  [0] PrincipalName,
-     mapped-name     [1] PrincipalName,
-     ...
-   }
-   PA-CLIENT-CANONICALIZED ::= SEQUENCE {
-     names          [0] ReferralInfo,
-     canon-checksum [1] Checksum
-   }
-
-   The canon-checksum field is computed over the DER encoding of the
-   names sequences, using the AS reply key and a key usage value of
-   (TBD).
-
-   If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is
-   not included.  If the client name is changed, and the PA-CLIENT-
-   CANONICALIZED field does not exist, or the checksum cannot be
-   verified, or the requested-name field doesn't match the client name
-   in the originally-transmitted request, the client should discard the
-   response.
-
-   For example the AS request may specify a client name of "bob@
-   EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC
-   option set and the KDC will return with a client name of "104567" as
-   a NT-UID, and a PA-CLIENT-CANONICALIZED field listing the NT-
-   ENTERPRISE "bob@EXAMPLE.COM" principal as the requested-name and the
-   NT-UID "104567" principal as the mapped-name.
-
-   (It is assumed that the client discovers whether the KDC supports the
-   NT-ENTERPRISE name type via out of band mechanisms.)
-
-   In order to enable one party in a user-to-user exchange to confirm
-   the identity of another when only the alias is known, the KDC MAY
-
-
-
-Raeburn & Zhu           Expires September 6, 2007               [Page 6]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-   include the following authorization data element, wrapped in AD-KDC-
-   ISSUED, in the initial credentials and copy it from a ticket-granting
-   ticket into additional credentials:
-
-   AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD --
-     login-aliases  [0] SEQUENCE(1..MAX) OF PrincipalName,
-   }
-
-   The login-aliases field lists one or more of the aliases the
-   principal may have used in the initial ticket request.
-
-   The recipient of this authenticator must check the AD-LOGIN-ALIAS
-   names, if present, in addition to the normal client name field,
-   against the identity of the party with which it wishes to
-   authenticate; either should be allowed to match.  (Note that this is
-   not backwards compatible with [RFC4120]; if the server side of the
-   user-to-user exchange does not support this extension, and does not
-   know the true principal name, authentication may fail if the alias is
-   sought in the client name field.)
-
-
-6.  Client Referrals
-
-   The simplest form of ticket referral is for a user requesting a
-   ticket using an AS-REQ.  In this case, the client machine will send
-   the AS-REQ to a convenient trusted realm, for example the realm of
-   the client machine.  In the case of the name alice@EXAMPLE.COM, the
-   client MAY optimistically choose to send the request to EXAMPLE.COM.
-   The realm in the AS-REQ is always the name of the realm that the
-   request is for as specified in [RFC4120].
-
-   The KDC will try to lookup the name in its local account database.
-   If the account is present in the realm of the request, it SHOULD
-   return a KDC reply structure with the appropriate ticket.
-
-   If the account is not present in the realm specified in the request
-   and the "canonicalize" KDC option is set, the KDC will try to lookup
-   the entire name, alice@EXAMPLE.COM, using a name service.  If this
-   lookup is unsuccessful, it MUST return the error
-   KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120].  If the lookup is successful,
-   it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the
-   error message the crealm field will contain either the true realm of
-   the client or another realm that MAY have better information about
-   the client's true realm.  The client SHALL NOT use a cname returned
-   from a Kerberos error until that name is validated.
-
-   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
-   new AS request with the same client principal name used to generate
-
-
-
-Raeburn & Zhu           Expires September 6, 2007               [Page 7]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-   the first referral to the realm specified by the realm field of the
-   Kerberos error message corresponding to the first request.  (The
-   client realm name will be updated in the new request to refer to this
-   new realm.)  The client SHOULD repeat these steps until it finds the
-   true realm of the client.  To avoid infinite referral loops, an
-   implementation should limit the number of referrals.  A suggested
-   limit is 5 referrals before giving up.
-
-   Since the same client name is sent to the referring and referred-to
-   realms, both realms must recognize the same client names.  In
-   particular, the referring realm cannot (usefully) define principal
-   name aliases that the referred-to realm will not know.
-
-   The true principal name of the client, returned in AS-REQ, can be
-   validated in a subsequent TGS message exchange where its value is
-   communicated back to the KDC via the authenticator in the PA-TGS-REQ
-   padata [RFC4120].
-
-
-7.  Server Referrals
-
-   The primary difference in server referrals is that the KDC MUST
-   return a referral TGT rather than an error message as is done in the
-   client referrals.  There needs to be a place to include in the reply
-   information about what realm contains the server.  This is done by
-   returning information about the server name in the pre-authentication
-   data field of the KDC reply [RFC4120], as specified later in this
-   section.
-
-   If the KDC resolves the server principal name into a principal in the
-   realm specified by the service realm name, it will return a normal
-   ticket.
-
-   If the "canonicalize" flag in the KDC options is not set, the KDC
-   MUST only look up the name as a normal principal name in the
-   specified server realm.  If the "canonicalize" flag in the KDC
-   options is set and the KDC doesn't find the principal locally, the
-   KDC MAY return a cross-realm ticket granting ticket to the next hop
-   on the trust path towards a realm that may be able to resolve the
-   principal name.  The true principal name of the server SHALL be
-   returned in the padata of the reply if it is different from what is
-   specified the request.
-
-   When a referral TGT is returned, the KDC MUST return the target realm
-   for the referral TGT as an KDC supplied pre-authentication data
-   element in the response.  This referral information in pre-
-   authentication data MUST be encrypted using the session key from the
-   reply ticket.  The key usage value for the encryption operation used
-
-
-
-Raeburn & Zhu           Expires September 6, 2007               [Page 8]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-   by PA-SERVER-REFERRAL is 26.
-
-   The pre-authentication data returned by the KDC, which contains the
-   referred realm and the true principal name of server, is encoded in
-   DER as follows.
-
-          PA-SERVER-REFERRAL      25
-
-          PA-SERVER-REFERRAL-DATA ::= EncryptedData
-                                -- ServerReferralData --
-
-          ServerReferralData ::= SEQUENCE {
-                 referred-realm           [0] Realm OPTIONAL,
-                                -- target realm of the referral TGT
-                 true-principal-name      [1] PrincipalName OPTIONAL,
-                                -- true server principal name
-                 requested-principal-name [2] PrincipalName OPTIONAL,
-                                -- requested server name
-                 ...
-          }
-
-   Clients SHALL NOT accept a reply ticket, whose the server principal
-   name is different from that of the request, if the KDC response does
-   not contain a PA-SERVER-REFERRAL padata entry.
-
-   The requested-principal-name MUST be included by the KDC, and MUST be
-   verified by the client, if the client sent an AS-REQ, as protection
-   against a man-in-the-middle modification to the AS-REQ message.
-
-   The referred-realm field is present if and only if the returned
-   ticket is a referral TGT, not a service ticket for the requested
-   server principal.
-
-   When a referral TGT is returned and the true-principal-name field is
-   present, the client MUST use that name in the subsequent requests to
-   the server realm when following the referral.
-
-   Client SHALL NOT accept a true server principal name for a service
-   ticket if the true-principal-name field is not present in the PA-
-   SERVER-REFERRAL data.
-
-   The client will use this referral information to request a chain of
-   cross-realm ticket granting tickets until it reaches the realm of the
-   server, and can then expect to receive a valid service ticket.
-
-   However an implementation should limit the number of referrals that
-   it processes to avoid infinite referral loops.  A suggested limit is
-   5 referrals before giving up.
-
-
-
-Raeburn & Zhu           Expires September 6, 2007               [Page 9]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-   Here is an example of a client requesting a service ticket for a
-   service in realm DEV.EXAMPLE.COM where the client is in
-   ADMIN.EXAMPLE.COM.
-
-      +NC = Canonicalize KDCOption set
-      +PA-REFERRAL = returned PA-SERVER-REFERRAL
-      C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM
-      S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM +PA-REFERRAL
-         containing EXAMPLE.COM as the referred realm with no
-         true-principal-name
-      C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM
-      S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM +PA-REFERRAL
-         containing DEV.EXAMPLE.COM as the referred realm with no
-         true-principal-name
-      C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM
-      S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM
-
-   Note that any referral or alias processing of the server name in
-   user-to-user authentication should use the same data as client name
-   canonicalization or referral.  Otherwise, the name used by one user
-   to log in may not be useable by another for user-to-user
-   authentication to the first.
-
-
-8.  Server Name Canonicalization (Informative)
-
-   No attempt is being made in this document to provide a means for
-   dealing with local-realm server principal name canonicalization or
-   aliasing.  The most obvious use case for this would be a hostname-
-   based service principal name ("host/foobar.example.com"), with a DNS
-   alias ("foo") for the server host which is used by the client.  There
-   are other ways this can be handled, currently, though they may
-   require additional configuration on the application server or KDC or
-   both.
-
-
-9.  Cross Realm Routing
-
-   The current Kerberos protocol requires the client to explicitly
-   request a cross-realm TGT for each pair of realms on a referral
-   chain.  As a result, the client need to be aware of the trust
-   hierarchy and of any short-cut trusts (those that aren't parent-
-   child trusts).
-
-   Instead, using the server referral routing mechanism as defined in
-   Section 7, The KDC will determine the best path for the client and
-   return a cross-realm TGT as the referral TGT, and the target realm
-   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
-
-
-
-Raeburn & Zhu           Expires September 6, 2007              [Page 10]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
-   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
-   response does not contain the PA-SERVER-REFERRAL padata.
-
-
-10.  Caching Information
-
-   It is possible that the client may wish to get additional credentials
-   for the same service principal, perhaps with different authorization-
-   data restrictions or other changed attributes.  The return of a
-   server referral from a KDC can be taken as an indication that the
-   requested principal does not currently exist in the local realm.
-   Clearly, it would reduce network traffic if the clients could cache
-   that information and use it when acquiring the second set of
-   credentials for a service, rather than always having to re-check with
-   the local KDC to see if the name has been created locally.
-
-   Rather than introduce a new timeout field for this cached
-   information, we can use the lifetime of the returned TGT in this
-   case.  When the TGT expires, the previously returned referral from
-   the local KDC should be considered invalid, and the local KDC must be
-   asked again for information for the desired service principal name.
-   (Note that the client may get back multiple referral TGTs from the
-   local KDC to the same remote realm, with different lifetimes.  The
-   lifetime information must be properly associated with the requested
-   service principal names.  Simply having another TGT for the same
-   remote realm does not extend the validity of previously acquired
-   information about one service principal name.)  If the client is
-   still in contact with the service and needs to reauthenticate to the
-   same service regardless of local service principal name assignments,
-   it should use the referred-realm and true-principal-name values when
-   requesting new credentials.
-
-   Accordingly, KDC authors and maintainers should consider what factors
-   (e.g., DNS alias lifetimes) they may or may not wish to incorporate
-   into credential expiration times in cases of referrals.
-
-
-11.  Open Issues
-
-   When should client name aliases be included in credentials?
-
-   Should all known client name aliases be included, or only the one
-   used at initial ticket acquisition?
-
-   We still don't discuss what "validation" of the returned information
-   means.
-
-
-
-
-Raeburn & Zhu           Expires September 6, 2007              [Page 11]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-12.  Security Considerations
-
-   For the AS exchange case, it is important that the logon mechanism
-   not trust a name that has not been used to authenticate the user.
-   For example, the name that the user enters as part of a logon
-   exchange may not be the name that the user authenticates as, given
-   that the KDC_ERR_WRONG_REALM error may have been returned.  The
-   relevant Kerberos naming information for logon (if any), is the
-   client name and client realm in the service ticket targeted at the
-   workstation that was obtained using the user's initial TGT.
-
-   How the client name and client realm is mapped into a local account
-   for logon is a local matter, but the client logon mechanism MUST use
-   additional information such as the client realm and/or authorization
-   attributes from the service ticket presented to the workstation by
-   the user, when mapping the logon credentials to a local account on
-   the workstation.
-
-
-13.  Acknowledgments
-
-   Sam Hartman and authors came up with the idea of using the ticket key
-   to encrypt the referral data, which prevents cut and paste attack
-   using the referral data and referral TGTs.
-
-   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
-   version of this document.
-
-   Karthik Jaganathan contributed to earlier versions.
-
-
-14.  References
-
-14.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-14.2.  Informative References
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-
-
-Raeburn & Zhu           Expires September 6, 2007              [Page 12]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-   [XPR]      Trostle, J., Kosinovsky, I., and M. Swift, "Implementation
-              of Crossrealm Referral Handling in the MIT Kerberos
-              Client",  Network and Distributed System Security
-              Symposium, February 2001.
-
-
-Appendix A.  Compatibility with Earlier Implementations of Name
-             Canonicalization
-
-   (Remove this section when Microsoft publishes this information in a
-   separate document.)
-
-   The Microsoft Windows 2000 and Windows 2003 releases included an
-   earlier form of name-canonicalization [XPR].  Here are the
-   differences:
-
-   1) The TGS referral data is returned inside of the KDC message as
-      "encrypted pre-authentication data".
-
-
-
-          EncKDCRepPart   ::= SEQUENCE {
-                 key                [0] EncryptionKey,
-                 last-req           [1] LastReq,
-                 nonce              [2] UInt32,
-                 key-expiration     [3] KerberosTime OPTIONAL,
-                 flags              [4] TicketFlags,
-                 authtime           [5] KerberosTime,
-                 starttime          [6] KerberosTime OPTIONAL,
-                 endtime            [7] KerberosTime,
-                 renew-till         [8] KerberosTime OPTIONAL,
-                 srealm             [9] Realm,
-                 sname             [10] PrincipalName,
-                 caddr             [11] HostAddresses OPTIONAL,
-                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
-         }
-
-   2) The preauth data type definition in the encrypted preauth data is
-      as follows:
-
-
-
-
-
-
-
-
-
-Raeburn & Zhu           Expires September 6, 2007              [Page 13]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-          PA-SVR-REFERRAL-INFO       20
-
-          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
-                 referred-name   [1] PrincipalName OPTIONAL,
-                 referred-realm  [0] Realm
-          }}
-
-   3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is
-      encoded as a Subject Alternative Name (SAN) extension [RFC3280] in
-      the client's X.509 certificate.  The type of the otherName field
-      for this SAN extension is AnotherName [RFC3280].  The type-id
-      field of the type AnotherName is id-ms-sc-logon-upn
-      (1.3.6.1.4.1.311.20.2.3) and the value field of the type
-      AnotherName is a KerberosString [RFC4120].  The value of this
-      KerberosString type is the single component in the name-string
-      [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
-
-   In Microsoft's current implementation through the use of global
-   catalogs any domain in one forest is reachable from any other domain
-   in the same forest or another trusted forest with 3 or less
-   referrals.  A forest is a collection of realms with hierarchical
-   trust relationships: there can be multiple trust trees in a forest;
-   each child and parent realm pair and each root realm pair have
-   bidirectional transitive direct rusts between them.
-
-   While we might want to permit multiple aliases to exist and even be
-   reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only
-   one NT-ENTERPRISE alias to exist, so this question had not previously
-   arisen.
-
-
-Appendix B.  Document history
-
-   [REMOVE BEFORE PUBLICATION.]
-
-   09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain.
-      Rewrote description of existing practice.  (Don't name the lookup
-      table consulted.  Mention that DNS "canonicalization" is contrary
-      to [RFC4120].)  Noted Microsoft behavior should be moved out into
-      a separate document.  Changed some second-person references in the
-      introduction to identify the proper parties.  Changed PA-CLIENT-
-      CANONICALIZED to use a separate type for the actual referral data,
-      add an extension marker to that type, and change the checksum key
-      from the "returned session key" to the "AS reply key".  Changed
-      AD-LOGIN-ALIAS to contain a sequence of names, to be contained in
-      AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer
-      needed separate checksum.  Attempt to clarify the cache lifetime
-      of referral information.
-
-
-
-Raeburn & Zhu           Expires September 6, 2007              [Page 14]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-   08 Moved Microsoft implementation info to appendix.  Clarify lack of
-      local server name canonicalization.  Added optional authz-data for
-      login alias, to support user-to-user case.  Added requested-
-      principal-name to ServerReferralData.  Added discussion of caching
-      information, and referral TGT lifetime.
-   07 Re-issued with new editor.  Fixed up some references.  Started
-      history.
-
-
-Authors' Addresses
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA  02139
-   US
-
-   Email: raeburn@mit.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn & Zhu           Expires September 6, 2007              [Page 15]
-
-Internet-Draft                KDC Referrals                   March 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Raeburn & Zhu           Expires September 6, 2007              [Page 16]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-10.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-10.txt
deleted file mode 100644
index b7e1beb59..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-10.txt
+++ /dev/null
@@ -1,1008 +0,0 @@
-
-
-
-Kerberos Working Group                                        K. Raeburn
-Internet-Draft                                                       MIT
-Updates: 4120 (if approved)                                       L. Zhu
-Intended status: Standards Track                   Microsoft Corporation
-Expires: August 28, 2008                               February 25, 2008
-
-
-           Generating KDC Referrals to Locate Kerberos Realms
-                draft-ietf-krb-wg-kerberos-referrals-10
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 28, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-Abstract
-
-   The memo documents a method for a Kerberos Key Distribution Center
-   (KDC) to respond to client requests for Kerberos tickets when the
-   client does not have detailed configuration information on the realms
-   of users or services.  The KDC will handle requests for principals in
-   other realms by returning either a referral error or a cross-realm
-   TGT to another realm on the referral path.  The clients will use this
-   referral information to reach the realm of the target principal and
-
-
-
-Raeburn & Zhu            Expires August 28, 2008                [Page 1]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-   then receive the ticket.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
-   3.  Requesting a Referral  . . . . . . . . . . . . . . . . . . . .  4
-   4.  Realm Organization Model . . . . . . . . . . . . . . . . . . .  5
-   5.  Enterprise Principal Name Type . . . . . . . . . . . . . . . .  5
-   6.  Name Canonicalization  . . . . . . . . . . . . . . . . . . . .  5
-   7.  Client Referrals . . . . . . . . . . . . . . . . . . . . . . .  7
-   8.  Server Referrals . . . . . . . . . . . . . . . . . . . . . . .  9
-   9.  Cross Realm Routing  . . . . . . . . . . . . . . . . . . . . . 11
-   10. Caching Information  . . . . . . . . . . . . . . . . . . . . . 11
-   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 12
-   12. Number Assignments . . . . . . . . . . . . . . . . . . . . . . 12
-   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
-     13.1.  Shared-password case  . . . . . . . . . . . . . . . . . . 13
-   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
-   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
-     15.1.  Normative References  . . . . . . . . . . . . . . . . . . 14
-     15.2.  Informative References  . . . . . . . . . . . . . . . . . 14
-   Appendix A.  Compatibility with Earlier Implementations of
-                Name Canonicalization . . . . . . . . . . . . . . . . 14
-   Appendix B.  Document history [REMOVE BEFORE PUBLICATION]  . . . . 16
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
-   Intellectual Property and Copyright Statements . . . . . . . . . . 18
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn & Zhu            Expires August 28, 2008                [Page 2]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-1.  Introduction
-
-   Current implementations of the Kerberos AS and TGS protocols, as
-   defined in [RFC4120], use principal names constructed from a known
-   user or service name and realm.  A service name is typically
-   constructed from a name of the service and the DNS host name of the
-   computer that is providing the service.  Many existing deployments of
-   Kerberos use a single Kerberos realm where all users and services
-   would be using the same realm.  However in an environment where there
-   are multiple trusted Kerberos realms, the client needs to be able to
-   determine what realm a particular user or service is in before making
-   an AS or TGS request.  Traditionally this requires client
-   configuration to make this possible.
-
-   When having to deal with multiple trusted realms, users are forced to
-   know what realm they are in before they can obtain a ticket granting
-   ticket (TGT) with an AS request.  However, in many cases the user
-   would like to use a more familiar name that is not directly related
-   to the realm of their Kerberos principal name.  A good example of
-   this is an RFC 822 style email name.  This document describes a
-   mechanism that would allow a user to specify a user principal name
-   that is an alias for the user's Kerberos principal name.  In practice
-   this would be the name that the user specifies to obtain a TGT from a
-   Kerberos KDC.  The user principal name no longer has a direct
-   relationship with the Kerberos principal or realm.  Thus the
-   administrator is able to move the user's principal to other realms
-   without the user having to know that it happened.
-
-   Once a user has a TGT, they would like to be able to access services
-   in any trusted Kerberos realm.  To do this requires that the client
-   be able to determine what realm the target service principal is in
-   before making the TGS request.  Current implementations of Kerberos
-   typically have a table that maps DNS host names to corresponding
-   Kerberos realms.  The user-supplied host name or its domain component
-   is looked up in this table (often using the result of some form of
-   host name lookup performed with insecure DNS queries, in violation of
-   [RFC4120]).  The corresponding realm is then used to complete the
-   target service principal name.
-
-   This traditional mechanism requires that each client have very
-   detailed configuration information about the hosts that are providing
-   services and their corresponding realms.  Having client side
-   configuration information can be very costly from an administration
-   point of view - especially if there are many realms and computers in
-   the environment.
-
-   There are also cases where specific DNS aliases (local names) have
-   been setup in an organization to refer to a server in another
-
-
-
-Raeburn & Zhu            Expires August 28, 2008                [Page 3]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-   organization (remote server).  The server has different DNS names in
-   each organization and each organization has a Kerberos realm that is
-   configured to service DNS names within that organization.  Ideally
-   users are able to authenticate to the server in the other
-   organization using the local server name.  This would mean that the
-   local realm be able to produce a ticket to the remote server under
-   its name.  The administrator in the local realm could give that
-   remote server an identity in the local realm and then have that
-   remote server maintain a separate secret for each alias it is known
-   as.  Alternatively the administrator could arrange to have the local
-   realm issue a referral to the remote realm and notify the requesting
-   client of the server's remote name that should be used in order to
-   request a ticket.
-
-   This memo proposes a solution for these problems and simplifies
-   administration by minimizing the configuration information needed on
-   each computer using Kerberos.  Specifically it describes a mechanism
-   to allow the KDC to handle canonicalization of names, provide for
-   principal aliases for users and services and allow the KDC to
-   determine the trusted realm authentication path by being able to
-   generate referrals to other realms in order to locate principals.
-
-   Two kinds of KDC referrals are introduced in this memo:
-
-   1. Client referrals, in which the client doesn't know which realm
-      contains a user account.
-   2. Server referrals, in which the client doesn't know which realm
-      contains a server account.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  Requesting a Referral
-
-   In order to request referrals defined in section 5, 6, and 7, the
-   Kerberos client MUST explicitly request the canonicalize KDC option
-   (bit 15) [RFC4120] for the AS-REQ or TGS-REQ.  This flag indicates to
-   the KDC that the client is prepared to receive a reply that contains
-   a principal name other than the one requested.
-
-
-          KDCOptions ::= KerberosFlags
-                   -- canonicalize (15)
-
-
-
-Raeburn & Zhu            Expires August 28, 2008                [Page 4]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-                   -- other KDCOptions values omitted
-
-   The client should expect, when sending names with the "canonicalize"
-   KDC option, that names in the KDC's reply MAY be different than the
-   name in the request.  A referral TGT is a cross realm TGT that is
-   returned with the server name of the ticket being different from the
-   server name in the request [RFC4120].
-
-
-4.  Realm Organization Model
-
-   This memo assumes that the world of principals is arranged on
-   multiple levels: the realm, the enterprise, and the world.  A KDC may
-   issue tickets for any principal in its realm or cross-realm tickets
-   for realms with which it has a direct trust relationship.  The KDC
-   also has access to a trusted name service that can resolve any name
-   from within its enterprise into a realm.  This trusted name service
-   removes the need to use an un-trusted DNS lookup for name resolution.
-
-   For example, consider the following configuration, where lines
-   indicate trust relationships:
-
-                      EXAMPLE.COM
-                      /        \
-                     /          \
-          ADMIN.EXAMPLE.COM  DEV.EXAMPLE.COM
-
-   In this configuration, all users in the EXAMPLE.COM enterprise could
-   have principal names such as alice@EXAMPLE.COM, with the same realm
-   portion.  In addition, servers at EXAMPLE.COM should be able to have
-   DNS host names from any DNS domain independent of what Kerberos realm
-   their principals reside in.
-
-
-5.  Enterprise Principal Name Type
-
-   The NT-ENTERPRISE type principal name contains one component, a
-   string of realm-defined content, which is intended to be used as an
-   alias for another principal name in some realm in the enterprise.  It
-   is used for conveying the alias name, not for the real principal
-   names within the realms, and thus is only useful when name
-   canonicalization is requested.
-
-
-6.  Name Canonicalization
-
-   A service or account may have multiple principal names.  More useful,
-   though, is a globally unique name that allows unification of email
-
-
-
-Raeburn & Zhu            Expires August 28, 2008                [Page 5]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-   and security principal names.  For example, all users at EXAMPLE.COM
-   may have a client principal name of the form "joe@EXAMPLE.COM" even
-   though the principals are contained in multiple realms.  This global
-   name is again an alias for the true client principal name, which
-   indicates what realm contains the principal.  Thus, accounts "alice"
-   in the realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log
-   on as "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM".
-
-   This utilizes a new client principal name type, as the AS-REQ message
-   only contains a single realm field, and the realm portion of this
-   name corresponds to the Kerberos realm with which the request is
-   made.  Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a
-   single component in the client name field of the AS-REQ message, with
-   a name type of NT-ENTERPRISE [RFC4120] (and the local realm name).
-   The KDC will recognize this name type and then transform the
-   requested name into the true principal name if the client account
-   resides in the local realm.  The true principal name can have a name
-   type different from the requested name type.  Typically the true
-   principal name will be a NT-PRINCIPAL [RFC4120].
-
-   If the "canonicalize" KDC option is set, then the KDC MAY change the
-   client principal name and type in the AS response and ticket returned
-   from the name type of the client name in the request, and include a
-   mandatory PA-DATA object authenticating the client name mapping:
-
-   ReferralInfo ::= SEQUENCE {
-     requested-name  [0] PrincipalName,
-     mapped-name     [1] PrincipalName,
-     ...
-   }
-   PA-CLIENT-CANONICALIZED ::= SEQUENCE {
-     names          [0] ReferralInfo,
-     canon-checksum [1] Checksum
-   }
-
-   The canon-checksum field is computed over the DER encoding of the
-   names sequences, using the AS reply key and a key usage value of
-   (TBD).
-
-   If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is
-   not included.  If the client name is changed, and the PA-CLIENT-
-   CANONICALIZED field does not exist, or the checksum cannot be
-   verified, or the requested-name field doesn't match the client name
-   in the originally-transmitted request, the client should discard the
-   response.
-
-   For example the AS request may specify a client name of "bob@
-   EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC
-
-
-
-Raeburn & Zhu            Expires August 28, 2008                [Page 6]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-   option set and the KDC will return with a client name of "104567" as
-   a NT-UID, and a PA-CLIENT-CANONICALIZED field listing the NT-
-   ENTERPRISE "bob@EXAMPLE.COM" principal as the requested-name and the
-   NT-UID "104567" principal as the mapped-name.
-
-   (It is assumed that the client discovers whether the KDC supports the
-   NT-ENTERPRISE name type via out of band mechanisms.)
-
-   In order to enable one party in a user-to-user exchange to confirm
-   the identity of another when only the alias is known, the KDC MAY
-   include the following authorization data element, wrapped in AD-KDC-
-   ISSUED, in the initial credentials and copy it from a ticket-granting
-   ticket into additional credentials:
-
-   AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD --
-     login-aliases  [0] SEQUENCE(1..MAX) OF PrincipalName,
-   }
-
-   The login-aliases field lists one or more of the aliases the
-   principal may have used in the initial ticket request.
-
-   The recipient of this authenticator must check the AD-LOGIN-ALIAS
-   names, if present, in addition to the normal client name field,
-   against the identity of the party with which it wishes to
-   authenticate; either should be allowed to match.  (Note that this is
-   not backwards compatible with [RFC4120]; if the server side of the
-   user-to-user exchange does not support this extension, and does not
-   know the true principal name, authentication may fail if the alias is
-   sought in the client name field.)
-
-   The use of AD-KDC-ISSUED authorization data elements in cross-realm
-   cases has not been well explored at this writing; hence we will only
-   specify the inclusion of this data in the one-realm case.  The alias
-   information should be dropped in the general cross-realm case.
-   However, a realm may implement a policy of accepting and re-signing
-   (wrapping in a new AD-KDC-ISSUED element) alias information provided
-   by certain other realms in the cross-realm ticket-granting service.
-
-
-7.  Client Referrals
-
-   The simplest form of ticket referral is for a user requesting a
-   ticket using an AS-REQ.  In this case, the client machine will send
-   the AS-REQ to a convenient trusted realm, for example the realm of
-   the client machine.  In the case of the name alice@EXAMPLE.COM, the
-   client MAY optimistically choose to send the request to EXAMPLE.COM.
-   The realm in the AS-REQ is always the name of the realm that the
-   request is for as specified in [RFC4120].
-
-
-
-Raeburn & Zhu            Expires August 28, 2008                [Page 7]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-   The KDC will try to lookup the name in its local account database.
-   If the account is present in the realm of the request, it SHOULD
-   return a KDC reply structure with the appropriate ticket.
-
-   If the account is not present in the realm specified in the request
-   and the "canonicalize" KDC option is set, the KDC will try to lookup
-   the entire name, alice@EXAMPLE.COM, using a name service.  If this
-   lookup is unsuccessful, it MUST return the error
-   KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120].  If the lookup is successful,
-   it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the
-   error message the crealm field will contain either the true realm of
-   the client or another realm that MAY have better information about
-   the client's true realm.  The client SHALL NOT use a cname returned
-   from a Kerberos error until that name is validated.
-
-   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
-   new AS request with the same client principal name used to generate
-   the first referral to the realm specified by the realm field of the
-   Kerberos error message corresponding to the first request.  (The
-   client realm name will be updated in the new request to refer to this
-   new realm.)  The client SHOULD repeat these steps until it finds the
-   true realm of the client.  To avoid infinite referral loops, an
-   implementation should limit the number of referrals.  A suggested
-   limit is 5 referrals before giving up.
-
-   Since the same client name is sent to the referring and referred-to
-   realms, both realms must recognize the same client names.  In
-   particular, the referring realm cannot (usefully) define principal
-   name aliases that the referred-to realm will not know.
-
-   The true principal name of the client, returned in AS-REQ, can be
-   validated in a subsequent TGS message exchange where its value is
-   communicated back to the KDC via the authenticator in the PA-TGS-REQ
-   padata [RFC4120].  However, this requires trusting the referred-to
-   realm's KDCs.  Clients should limit the referral mappings they will
-   accept to realms trusted via some local policy.  Some possible
-   factors that might be taken into consideration for such a policy
-   might include:
-
-   o  Any realm indicated by the local KDC, if the returned KRB-ERROR
-      message is protected, for example using a public key known to be
-      associated with the KDC
-   o  A list of realms configured by an administrator
-   o  Any realm accepted by the user when explicitly prompted
-
-
-
-
-
-
-
-Raeburn & Zhu            Expires August 28, 2008                [Page 8]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-8.  Server Referrals
-
-   The primary difference in server referrals is that the KDC MUST
-   return a referral TGT rather than an error message as is done in the
-   client referrals.  There needs to be a place to include in the reply
-   information about what realm contains the server.  This is done by
-   returning information about the server name in the pre-authentication
-   data field of the KDC reply [RFC4120], as specified later in this
-   section.
-
-   If the KDC resolves the server principal name into a principal in the
-   realm specified by the service realm name, it will return a normal
-   ticket.
-
-   If the "canonicalize" flag in the KDC options is not set, the KDC
-   MUST only look up the name as a normal principal name in the
-   specified server realm.  If the "canonicalize" flag in the KDC
-   options is set and the KDC doesn't find the principal locally, the
-   KDC MAY return a cross-realm ticket granting ticket to the next hop
-   on the trust path towards a realm that may be able to resolve the
-   principal name.  The true principal name of the server SHALL be
-   returned in the padata of the reply if it is different from what is
-   specified the request.
-
-   When a referral TGT is returned, the KDC MUST return the target realm
-   for the referral TGT as an KDC supplied pre-authentication data
-   element in the response.  This referral information in pre-
-   authentication data MUST be encrypted using the session key from the
-   reply ticket.  The key usage value for the encryption operation used
-   by PA-SERVER-REFERRAL is 26.
-
-   The pre-authentication data returned by the KDC, which contains the
-   referred realm and the true principal name of server, is encoded in
-   DER as follows.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn & Zhu            Expires August 28, 2008                [Page 9]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-          PA-SERVER-REFERRAL      25
-
-          PA-SERVER-REFERRAL-DATA ::= EncryptedData
-                                -- ServerReferralData --
-
-          ServerReferralData ::= SEQUENCE {
-                 referred-realm           [0] Realm OPTIONAL,
-                                -- target realm of the referral TGT
-                 true-principal-name      [1] PrincipalName OPTIONAL,
-                                -- true server principal name
-                 requested-principal-name [2] PrincipalName OPTIONAL,
-                                -- requested server name
-                 referral-valid-until     [3] KerberosTime OPTIONAL,
-                 ...
-          }
-
-   Clients SHALL NOT accept a reply ticket in which the server principal
-   name is different from that of the request, if the KDC response does
-   not contain a PA-SERVER-REFERRAL padata entry.
-
-   The requested-principal-name MUST be included by the KDC, and MUST be
-   verified by the client, if the client sent an AS-REQ, as protection
-   against a man-in-the-middle modification to the AS-REQ message.
-
-   The referred-realm field is present if and only if the returned
-   ticket is a referral TGT, not a service ticket for the requested
-   server principal.
-
-   When a referral TGT is returned and the true-principal-name field is
-   present, the client MUST use that name in the subsequent requests to
-   the server realm when following the referral.
-
-   Client SHALL NOT accept a true server principal name for a service
-   ticket if the true-principal-name field is not present in the PA-
-   SERVER-REFERRAL data.
-
-   The client will use this referral information to request a chain of
-   cross-realm ticket granting tickets until it reaches the realm of the
-   server, and can then expect to receive a valid service ticket.
-
-   However an implementation should limit the number of referrals that
-   it processes to avoid infinite referral loops.  A suggested limit is
-   5 referrals before giving up.
-
-   The client may cache the mapping of the requested name to the name of
-   the next realm to use and the principal name to ask for.  (See
-   Section 10.)  The referral-valid-until field, if present, conveys how
-   long this information is valid for.
-
-
-
-Raeburn & Zhu            Expires August 28, 2008               [Page 10]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-   Here is an example of a client requesting a service ticket for a
-   service in realm DEV.EXAMPLE.COM where the client is in
-   ADMIN.EXAMPLE.COM.
-
-      +NC = Canonicalize KDCOption set
-      +PA-REFERRAL = returned PA-SERVER-REFERRAL
-      C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM
-      S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM +PA-REFERRAL
-         containing EXAMPLE.COM as the referred realm with no
-         true-principal-name
-      C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM
-      S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM +PA-REFERRAL
-         containing DEV.EXAMPLE.COM as the referred realm with no
-         true-principal-name
-      C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM
-      S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM
-
-   Note that any referral or alias processing of the server name in
-   user-to-user authentication should use the same data as client name
-   canonicalization or referral.  Otherwise, the name used by one user
-   to log in may not be useable by another for user-to-user
-   authentication to the first.
-
-
-9.  Cross Realm Routing
-
-   The current Kerberos protocol requires the client to explicitly
-   request a cross-realm TGT for each pair of realms on a referral
-   chain.  As a result, the client need to be aware of the trust
-   hierarchy and of any short-cut trusts (those that aren't parent-
-   child trusts).
-
-   Instead, using the server referral routing mechanism as defined in
-   Section 8, The KDC will determine the best path for the client and
-   return a cross-realm TGT as the referral TGT, and the target realm
-   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
-
-   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
-   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
-   response does not contain the PA-SERVER-REFERRAL padata.
-
-
-10.  Caching Information
-
-   It is possible that the client may wish to get additional credentials
-   for the same service principal, perhaps with different authorization-
-   data restrictions or other changed attributes.  The return of a
-   server referral from a KDC can be taken as an indication that the
-
-
-
-Raeburn & Zhu            Expires August 28, 2008               [Page 11]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-   requested principal does not currently exist in the local realm.
-   Clearly, it would reduce network traffic if the clients could cache
-   that information and use it when acquiring the second set of
-   credentials for a service, rather than always having to re-check with
-   the local KDC to see if the name has been created locally.
-
-   If the referral-valid-until field is provided in the PA-SERVER-
-   REFERRAL-DATA message, it indicates the expiration time of this data;
-   if it is not included, the expiration time of the TGT is used.  When
-   the TGT expires, the previously returned referral from the local KDC
-   should be considered invalid, and the local KDC must be asked again
-   for information for the desired service principal name.  (Note that
-   the client may get back multiple referral TGTs from the local KDC to
-   the same remote realm, with different lifetimes.  The lifetime
-   information must be properly associated with the requested service
-   principal names.  Simply having another TGT for the same remote realm
-   does not extend the validity of previously acquired information about
-   one service principal name.)  If the client is still in contact with
-   the service and needs to reauthenticate to the same service
-   regardless of local service principal name assignments, it should use
-   the referred-realm and true-principal-name values when requesting new
-   credentials.
-
-   Accordingly, KDC authors and maintainers should consider what factors
-   (e.g., DNS alias lifetimes) they may or may not wish to incorporate
-   into credential expiration times in cases of referrals.
-
-
-11.  Open Issues
-
-   Client referral info validation
-
-   When should client name aliases be included in credentials?  Should
-   all known client name aliases be included, or only the one used at
-   initial ticket acquisition?
-
-   Should list the policies that need to be defined.
-
-   More examples: u2u, policy checks, maybe cross-realm.
-
-   Restore server name canonicalization from early drafts.
-
-
-12.  Number Assignments
-
-   Most number registries in the Kerberos protocol have not been turned
-   over to IANA for management at the time of this writing, hence this
-   is not an "IANA Considerations" section.
-
-
-
-Raeburn & Zhu            Expires August 28, 2008               [Page 12]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-   Various values do need assigning for this draft:
-      AD-LOGIN-ALIAS
-      PA-CLIENT-CANONICALIZED
-      key usage value for PA-CLIENT-CANONICALIZED field canon-checksum
-
-
-13.  Security Considerations
-
-   For the AS exchange case, it is important that the logon mechanism
-   not trust a name that has not been used to authenticate the user.
-   For example, the name that the user enters as part of a logon
-   exchange may not be the name that the user authenticates as, given
-   that the KDC_ERR_WRONG_REALM error may have been returned.  The
-   relevant Kerberos naming information for logon (if any), is the
-   client name and client realm in the service ticket targeted at the
-   workstation that was obtained using the user's initial TGT.
-
-   How the client name and client realm is mapped into a local account
-   for logon is a local matter, but the client logon mechanism MUST use
-   additional information such as the client realm and/or authorization
-   attributes from the service ticket presented to the workstation by
-   the user, when mapping the logon credentials to a local account on
-   the workstation.
-
-13.1.  Shared-password case
-
-   A special case to examine is when the user is known (or correctly
-   suspected) to use the same password for multiple accounts.  A man-in-
-   the-middle attacker can either alter the request on its way to the
-   KDC, changing the client principal name, or reply to the client with
-   a response previously send by the KDC in response to a request from
-   the attacker.  The response received by the client can then be
-   decrypted by the user, though if the default "salt" generated from
-   the principal name is used to produce the user's key, a PA-ETYPE-INFO
-   or PA-ETYPE-INFO2 preauth record may need to be added or altered by
-   the attacker to cause the client software to generate the key needed
-   for the message it will receive.  None of this requires the attacker
-   to know the user's password, and without further checking, could
-   cause the user to unknowingly use the wrong credentials.
-
-   In normal [RFC4120] operation, a generated AP-REQ message includes in
-   the Authenticator field a copy of the client's idea of its own
-   principal name.  If this differs from the name in the KDC-generated
-   Ticket, the application server will reject the message.
-
-   With client name canonicalization as described in this document, the
-   client may get its principal name from the response from the KDC.
-   Requiring the PA-CLIENT-CANONICALIZED data lets the client securely
-
-
-
-Raeburn & Zhu            Expires August 28, 2008               [Page 13]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-   check that the requested name was not altered in transit.  If the PA-
-   CLIENT-CANONICALIZED data is absent, the client can use the principal
-   name it requested.
-
-
-14.  Acknowledgments
-
-   Sam Hartman and authors came up with the idea of using the ticket key
-   to encrypt the referral data, which prevents cut and paste attack
-   using the referral data and referral TGTs.
-
-   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
-   version of this document.
-
-   Karthik Jaganathan contributed to earlier versions.
-
-
-15.  References
-
-15.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-15.2.  Informative References
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-   [XPR]      Trostle, J., Kosinovsky, I., and M. Swift, "Implementation
-              of Crossrealm Referral Handling in the MIT Kerberos
-              Client",  Network and Distributed System Security
-              Symposium, February 2001.
-
-
-Appendix A.  Compatibility with Earlier Implementations of Name
-             Canonicalization
-
-   The Microsoft Windows 2000 and Windows 2003 releases included an
-
-
-
-Raeburn & Zhu            Expires August 28, 2008               [Page 14]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-   earlier form of name-canonicalization [XPR].  Here are the
-   differences:
-
-   1) The TGS referral data is returned inside of the KDC message as
-      "encrypted pre-authentication data".
-
-
-
-          EncKDCRepPart   ::= SEQUENCE {
-                 key                [0] EncryptionKey,
-                 last-req           [1] LastReq,
-                 nonce              [2] UInt32,
-                 key-expiration     [3] KerberosTime OPTIONAL,
-                 flags              [4] TicketFlags,
-                 authtime           [5] KerberosTime,
-                 starttime          [6] KerberosTime OPTIONAL,
-                 endtime            [7] KerberosTime,
-                 renew-till         [8] KerberosTime OPTIONAL,
-                 srealm             [9] Realm,
-                 sname             [10] PrincipalName,
-                 caddr             [11] HostAddresses OPTIONAL,
-                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
-         }
-
-   2) The preauth data type definition in the encrypted preauth data is
-      as follows:
-
-
-
-          PA-SVR-REFERRAL-INFO       20
-
-          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
-                 referred-name   [1] PrincipalName OPTIONAL,
-                 referred-realm  [0] Realm
-          }}
-
-   3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is
-      encoded as a Subject Alternative Name (SAN) extension [RFC3280] in
-      the client's X.509 certificate.  The type of the otherName field
-      for this SAN extension is AnotherName [RFC3280].  The type-id
-      field of the type AnotherName is id-ms-sc-logon-upn
-      (1.3.6.1.4.1.311.20.2.3) and the value field of the type
-      AnotherName is a KerberosString [RFC4120].  The value of this
-      KerberosString type is the single component in the name-string
-      [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
-
-   In Microsoft's current implementation through the use of global
-   catalogs any domain in one forest is reachable from any other domain
-
-
-
-Raeburn & Zhu            Expires August 28, 2008               [Page 15]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-   in the same forest or another trusted forest with 3 or less
-   referrals.  A forest is a collection of realms with hierarchical
-   trust relationships: there can be multiple trust trees in a forest;
-   each child and parent realm pair and each root realm pair have
-   bidirectional transitive direct rusts between them.
-
-   While we might want to permit multiple aliases to exist and even be
-   reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only
-   one NT-ENTERPRISE alias to exist, so this question had not previously
-   arisen.
-
-
-Appendix B.  Document history [REMOVE BEFORE PUBLICATION]
-
-   10 TBD
-   09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain.
-      Rewrote description of existing practice.  (Don't name the lookup
-      table consulted.  Mention that DNS "canonicalization" is contrary
-      to [RFC4120].)  Noted Microsoft behavior should be moved out into
-      a separate document.  Changed some second-person references in the
-      introduction to identify the proper parties.  Changed PA-CLIENT-
-      CANONICALIZED to use a separate type for the actual referral data,
-      add an extension marker to that type, and change the checksum key
-      from the "returned session key" to the "AS reply key".  Changed
-      AD-LOGIN-ALIAS to contain a sequence of names, to be contained in
-      AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer
-      needed separate checksum.  Attempt to clarify the cache lifetime
-      of referral information.
-   08 Moved Microsoft implementation info to appendix.  Clarify lack of
-      local server name canonicalization.  Added optional authz-data for
-      login alias, to support user-to-user case.  Added requested-
-      principal-name to ServerReferralData.  Added discussion of caching
-      information, and referral TGT lifetime.
-   07 Re-issued with new editor.  Fixed up some references.  Started
-      history.
-
-
-Authors' Addresses
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA  02139
-   US
-
-   Email: raeburn@mit.edu
-
-
-
-
-
-Raeburn & Zhu            Expires August 28, 2008               [Page 16]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn & Zhu            Expires August 28, 2008               [Page 17]
-
-Internet-Draft                KDC Referrals                February 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Raeburn & Zhu            Expires August 28, 2008               [Page 18]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-11.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-11.txt
deleted file mode 100644
index 7c4c5a365..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-11.txt
+++ /dev/null
@@ -1,1064 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                         K. Raeburn
-Internet-Draft                                                       MIT
-Updates: 4120 (if approved)                                       L. Zhu
-Intended status: Standards Track                   Microsoft Corporation
-Expires: January 15, 2009                                  July 14, 2008
-
-
- Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm
-                               Referrals
-                draft-ietf-krb-wg-kerberos-referrals-11
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 15, 2009.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-Abstract
-
-   The memo documents a method for a Kerberos Key Distribution Center
-   (KDC) to respond to client requests for Kerberos tickets when the
-   client does not have detailed configuration information on the realms
-   of users or services.  The KDC will handle requests for principals in
-   other realms by returning either a referral error or a cross-realm
-   TGT to another realm on the referral path.  The clients will use this
-
-
-
-Raeburn & Zhu           Expires January 15, 2009                [Page 1]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-   referral information to reach the realm of the target principal and
-   then receive the ticket.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
-   3.  Requesting a Referral  . . . . . . . . . . . . . . . . . . . .  4
-   4.  Realm Organization Model . . . . . . . . . . . . . . . . . . .  5
-   5.  Enterprise Principal Name Type . . . . . . . . . . . . . . . .  5
-   6.  Name Canonicalization  . . . . . . . . . . . . . . . . . . . .  6
-   7.  Client Referrals . . . . . . . . . . . . . . . . . . . . . . .  8
-   8.  Server Referrals . . . . . . . . . . . . . . . . . . . . . . .  9
-   9.  Cross Realm Routing  . . . . . . . . . . . . . . . . . . . . . 12
-   10. Caching Information  . . . . . . . . . . . . . . . . . . . . . 12
-   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 13
-   12. Number Assignments . . . . . . . . . . . . . . . . . . . . . . 13
-   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
-   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
-     14.1.  Shared-password case  . . . . . . . . . . . . . . . . . . 14
-     14.2.  Preauthentication data  . . . . . . . . . . . . . . . . . 14
-   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
-   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
-     16.1.  Normative References  . . . . . . . . . . . . . . . . . . 15
-     16.2.  Informative References  . . . . . . . . . . . . . . . . . 15
-   Appendix A.  Compatibility with Earlier Implementations of
-                Name Canonicalization . . . . . . . . . . . . . . . . 15
-   Appendix B.  Document history [REMOVE BEFORE PUBLICATION]  . . . . 17
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
-   Intellectual Property and Copyright Statements . . . . . . . . . . 19
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn & Zhu           Expires January 15, 2009                [Page 2]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-1.  Introduction
-
-   Current implementations of the Kerberos AS and TGS protocols, as
-   defined in [RFC4120], use principal names constructed from a known
-   user or service name and realm.  A service name is typically
-   constructed from a name of the service and the DNS host name of the
-   computer that is providing the service.  Many existing deployments of
-   Kerberos use a single Kerberos realm where all users and services
-   would be using the same realm.  However in an environment where there
-   are multiple trusted Kerberos realms, the client needs to be able to
-   determine what realm a particular user or service is in before making
-   an AS or TGS request.  Traditionally this requires client
-   configuration to make this possible.
-
-   When having to deal with multiple trusted realms, users are forced to
-   know what realm they are in before they can obtain a ticket granting
-   ticket (TGT) with an AS request.  However, in many cases the user
-   would like to use a more familiar name that is not directly related
-   to the realm of their Kerberos principal name.  A good example of
-   this is an RFC 822 style email name.  This document describes a
-   mechanism that would allow a user to specify a user principal name
-   that is an alias for the user's Kerberos principal name.  In practice
-   this would be the name that the user specifies to obtain a TGT from a
-   Kerberos KDC.  The user principal name no longer has a direct
-   relationship with the Kerberos principal or realm.  Thus the
-   administrator is able to move the user's principal to other realms
-   without the user having to know that it happened.
-
-   Once a user has a TGT, they would like to be able to access services
-   in any trusted Kerberos realm.  To do this requires that the client
-   be able to determine what realm the target service principal is in
-   before making the TGS request.  Current implementations of Kerberos
-   typically have a table that maps DNS host names to corresponding
-   Kerberos realms.  The user-supplied host name or its domain component
-   is looked up in this table (often using the result of some form of
-   host name lookup performed with insecure DNS queries, in violation of
-   [RFC4120]).  The corresponding realm is then used to complete the
-   target service principal name.
-
-   This traditional mechanism requires that each client have very
-   detailed configuration information about the hosts that are providing
-   services and their corresponding realms.  Having client side
-   configuration information can be very costly from an administration
-   point of view - especially if there are many realms and computers in
-   the environment.
-
-   There are also cases where specific DNS aliases (local names) have
-   been setup in an organization to refer to a server in another
-
-
-
-Raeburn & Zhu           Expires January 15, 2009                [Page 3]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-   organization (remote server).  The server has different DNS names in
-   each organization and each organization has a Kerberos realm that is
-   configured to service DNS names within that organization.  Ideally
-   users are able to authenticate to the server in the other
-   organization using the local server name.  This would mean that the
-   local realm be able to produce a ticket to the remote server under
-   its name.  The administrator in the local realm could give that
-   remote server an identity in the local realm and then have that
-   remote server maintain a separate secret for each alias it is known
-   as.  Alternatively the administrator could arrange to have the local
-   realm issue a referral to the remote realm and notify the requesting
-   client of the server's remote name that should be used in order to
-   request a ticket.
-
-   This memo proposes a solution for these problems and simplifies
-   administration by minimizing the configuration information needed on
-   each computer using Kerberos.  Specifically it describes a mechanism
-   to allow the KDC to handle canonicalization of names, provide for
-   principal aliases for users and services and allow the KDC to
-   determine the trusted realm authentication path by being able to
-   generate referrals to other realms in order to locate principals.
-
-   Two kinds of KDC referrals are introduced in this memo:
-
-   1. Client referrals, in which the client doesn't know which realm
-      contains a user account.
-   2. Server referrals, in which the client doesn't know which realm
-      contains a server account.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  Requesting a Referral
-
-   In order to request referrals as defined in later sections, the
-   Kerberos client MUST explicitly request the canonicalize KDC option
-   (bit 15) [RFC4120] for the AS-REQ or TGS-REQ.  This flag indicates to
-   the KDC that the client is prepared to receive a reply that contains
-   a principal name other than the one requested.
-
-
-          KDCOptions ::= KerberosFlags
-                   -- canonicalize (15)
-
-
-
-Raeburn & Zhu           Expires January 15, 2009                [Page 4]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-                   -- other KDCOptions values omitted
-
-   The client should expect, when sending names with the "canonicalize"
-   KDC option, that names in the KDC's reply MAY be different than the
-   name in the request.  A referral TGT is a cross realm TGT that is
-   returned with the server name of the ticket being different from the
-   server name in the request [RFC4120].
-
-
-4.  Realm Organization Model
-
-   This memo assumes that the world of principals is arranged on
-   multiple levels: the realm, the enterprise, and the world.  A KDC may
-   issue tickets for any principal in its realm or cross-realm tickets
-   for realms with which it has a direct trust relationship.  The KDC
-   also has access to a trusted name service that can resolve any name
-   from within its enterprise into a realm.  This trusted name service
-   removes the need to use an un-trusted DNS lookup for name resolution.
-
-   For example, consider the following configuration, where lines
-   indicate trust relationships:
-
-                      EXAMPLE.COM
-                      /        \
-                     /          \
-          ADMIN.EXAMPLE.COM  DEV.EXAMPLE.COM
-
-   In this configuration, all users in the EXAMPLE.COM enterprise could
-   have principal names such as alice@EXAMPLE.COM, with the same realm
-   portion.  In addition, servers at EXAMPLE.COM should be able to have
-   DNS host names from any DNS domain independent of what Kerberos realm
-   their principals reside in.
-
-
-5.  Enterprise Principal Name Type
-
-   The NT-ENTERPRISE type principal name contains one component, a
-   string of realm-defined content, which is intended to be used as an
-   alias for another principal name in some realm in the enterprise.  It
-   is used for conveying the alias name, not for the real principal
-   names within the realms, and thus is only useful when name
-   canonicalization is requested.
-
-   The intent is to allow unification of email and security principal
-   names.  For example, all users at EXAMPLE.COM may have a client
-   principal name of the form "joe@EXAMPLE.COM" even though the
-   principals are contained in multiple realms.  This global name is
-   again an alias for the true client principal name, which indicates
-
-
-
-Raeburn & Zhu           Expires January 15, 2009                [Page 5]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-   what realm contains the principal.  Thus, accounts "alice" in the
-   realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log on as
-   "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM".
-
-   This utilizes a new principal name type, as the KDC-REQ message only
-   contains a single client realm field, and the realm portion of this
-   name corresponds to the Kerberos realm with which the request is
-   made.  Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a
-   single component in the client name field of the AS-REQ message, with
-   a name type of NT-ENTERPRISE [RFC4120] (and the local realm name).
-   The KDC will recognize this name type and then transform the
-   requested name into the true principal name if the client account
-   resides in the local realm.  The true principal name can have a name
-   type different from the requested name type.  Typically the true
-   principal name will be a NT-PRINCIPAL [RFC4120].
-
-
-6.  Name Canonicalization
-
-   A service or account may have multiple principal names.  For example,
-   if a host is known by multiple names, host-based services on it may
-   be known by multiple names in order to prevent the client from
-   needing a secure directory service to determine the correct hostname
-   to use.  In order that the host should not need to be updated
-   whenever a new alias is created, the KDC may provide the mapping
-   information to the client in the credential acquisition process.
-
-   If the "canonicalize" KDC option is set, then the KDC MAY change the
-   client and server principal names and types in the AS response and
-   ticket returned from the name type of the client name in the request.
-   In a TGS exchange, the server principal name and type may be changed.
-
-   If the client principal name is changed in an AS exchange, the KDC
-   must include a mandatory PA-DATA object authenticating the client
-   name mapping:
-
-   ClientReferralInfo ::= SEQUENCE {
-     requested-name  [0] PrincipalName,
-     mapped-name     [1] PrincipalName,
-     ...
-   }
-   PA-CLIENT-CANONICALIZED ::= SEQUENCE {
-     names          [0] ClientReferralInfo,
-     canon-checksum [1] Checksum
-   }
-
-   The canon-checksum field is computed over the DER encoding of the
-   names sequences, using the AS reply key and a key usage value of
-
-
-
-Raeburn & Zhu           Expires January 15, 2009                [Page 6]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-   (TBD).
-
-   If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is
-   not included.  If the client name is changed, and the PA-CLIENT-
-   CANONICALIZED field does not exist, or the checksum cannot be
-   verified, or the requested-name field doesn't match the client name
-   in the originally-transmitted request, the client should discard the
-   response.
-
-   For example the AS request may specify a client name of "bob@
-   EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC
-   option set and the KDC will return with a client name of "104567" as
-   a NT-UID, and a PA-CLIENT-CANONICALIZED field listing the NT-
-   ENTERPRISE "bob@EXAMPLE.COM" principal as the requested-name and the
-   NT-UID "104567" principal as the mapped-name.
-
-   (It is assumed that the client discovers whether the KDC supports the
-   NT-ENTERPRISE name type via out of band mechanisms.)
-
-   If the server name is changed, a PA-SERVER-REFERRAL preauth data
-   entry MUST be supplied by the KDC and validated by the client.
-
-   In order to enable one party in a user-to-user exchange to confirm
-   the identity of another when only the alias is known, the KDC MAY
-   include the following authorization data element, wrapped in AD-KDC-
-   ISSUED, in the initial credentials and copy it from a ticket-granting
-   ticket into additional credentials:
-
-   AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD --
-     login-aliases  [0] SEQUENCE(1..MAX) OF PrincipalName,
-   }
-
-   The login-aliases field lists one or more of the aliases the
-   principal may have.
-
-   The recipient of this authenticator must check the AD-LOGIN-ALIAS
-   names, if present, in addition to the normal client name field,
-   against the identity of the party with which it wishes to
-   authenticate; either should be allowed to match.  (Note that this is
-   not backwards compatible with [RFC4120]; if the server side of the
-   user-to-user exchange does not support this extension, and does not
-   know the true principal name, authentication may fail if the alias is
-   sought in the client name field.)
-
-   The use of AD-KDC-ISSUED authorization data elements in cross-realm
-   cases has not been well explored at this writing; hence we will only
-   specify the inclusion of this data in the one-realm case.  The alias
-   information SHOULD be dropped in the general cross-realm case.
-
-
-
-Raeburn & Zhu           Expires January 15, 2009                [Page 7]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-   However, a realm MAY implement a policy of accepting and re-signing
-   (wrapping in a new AD-KDC-ISSUED element) alias information provided
-   by certain trusted realms, in the cross-realm ticket-granting
-   service.
-
-   The canonical principal name for an alias may not be in the form of a
-   ticket-granting service name, as (in a case of server name
-   canonicalization) that would be construed as a case of cross-realm
-   referral, described below.
-
-
-7.  Client Referrals
-
-   The simplest form of ticket referral is for a user requesting a
-   ticket using an AS-REQ.  In this case, the client machine will send
-   the AS-REQ to a convenient trusted realm, for example the realm of
-   the client machine.  In the case of the name alice@EXAMPLE.COM, the
-   client MAY optimistically choose to send the request to EXAMPLE.COM.
-   The realm in the AS-REQ is always the name of the realm that the
-   request is for as specified in [RFC4120].
-
-   The KDC will try to lookup the name in its local account database.
-   If the account is present in the realm of the request, it SHOULD
-   return a KDC reply structure with the appropriate ticket.
-
-   If the account is not present in the realm specified in the request
-   and the "canonicalize" KDC option is set, the KDC may look up the
-   client principal name using some kind of name service or directory
-   service.  If this lookup is unsuccessful, it MUST return the error
-   KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120].  If the lookup is successful,
-   it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the
-   error message the crealm field will contain either the true realm of
-   the client or another realm that MAY have better information about
-   the client's true realm.  The client SHALL NOT use the cname returned
-   in this error message.
-
-   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
-   new AS request with the same client principal name used to generate
-   the first referral to the realm specified by the realm field of the
-   Kerberos error message corresponding to the first request.  (The
-   client realm name will be updated in the new request to refer to this
-   new realm.)  The client SHOULD repeat these steps until it finds the
-   true realm of the client.  To avoid infinite referral loops, an
-   implementation should limit the number of referrals.  A suggested
-   limit is 5 referrals before giving up.
-
-   Since the same client name is sent to the referring and referred-to
-   realms, both realms must recognize the same client names.  In
-
-
-
-Raeburn & Zhu           Expires January 15, 2009                [Page 8]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-   particular, the referring realm cannot (usefully) define principal
-   name aliases that the referred-to realm will not know.
-
-   The true principal name of the client, returned in AS-REQ, can be
-   validated in a subsequent TGS message exchange where its value is
-   communicated back to the KDC via the authenticator in the PA-TGS-REQ
-   padata [RFC4120].  However, this requires trusting the referred-to
-   realm's KDCs.  Clients should limit the referral mappings they will
-   accept to realms trusted via some local policy.  Some possible
-   factors that might be taken into consideration for such a policy
-   might include:
-
-   o  Any realm indicated by the local KDC, if the returned KRB-ERROR
-      message is protected by some additional means, for example using a
-      preauthentication scheme using a public key known to be associated
-      with the KDC, or an IPsec tunnel known to have the desired KDC as
-      the remote endpoint
-   o  A list of realms configured by an administrator
-   o  Any realm accepted by the user when explicitly prompted
-
-   There is currently no provision for changing the client name in a
-   client referral response, because there is no method for verifying
-   that a man-in-the-middle attack did not change the requested name in
-   the request on the way to the KDC.
-
-
-8.  Server Referrals
-
-   The primary difference in server referrals is that the KDC returns a
-   referral TGT rather than an error message as is done in the client
-   referrals.  There needs to be a place to include in the reply
-   information about what realm contains the server; this is done by
-   returning information about the server name in the pre-authentication
-   data field of the KDC reply [RFC4120], as specified later in this
-   section.
-
-   If the "canonicalize" flag in the KDC options is set and the KDC
-   doesn't find the principal locally, either as a regular principal or
-   as an alias for another local principal, the KDC MAY return a cross-
-   realm ticket granting ticket to the next hop on the trust path
-   towards a realm that may be able to resolve the principal name.  The
-   true principal name of the server SHALL be returned in the padata of
-   the reply if it is different from what is specified the request.
-
-   When a referral TGT is returned, the KDC MUST return the target realm
-   for the referral TGT as an KDC supplied pre-authentication data
-   element in the response.  This referral information in pre-
-   authentication data MUST be encrypted using the session key from the
-
-
-
-Raeburn & Zhu           Expires January 15, 2009                [Page 9]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-   reply ticket.  The key usage value for the encryption operation used
-   by PA-SERVER-REFERRAL is 26.
-
-   The pre-authentication data returned by the KDC, which contains the
-   referred realm and the true principal name of server, is encoded in
-   DER as follows.
-
-
-         PA-SERVER-REFERRAL      25
-
-         SERVER-REFERRAL-DATA ::= EncryptedData
-                               -- ServerReferralData
-                               -- returned session key, ku=26
-
-         ServerReferralData ::= SEQUENCE {
-                referred-realm           [0] Realm OPTIONAL,
-                               -- target realm of the referral TGT
-                true-principal-name      [1] PrincipalName OPTIONAL,
-                               -- true server principal name
-                requested-principal-name [2] PrincipalName OPTIONAL,
-                               -- requested server name
-                referral-valid-until     [3] KerberosTime OPTIONAL,
-                rep-cksum                [4] Checksum,
-                               -- associated {AS,TGS}-REP with no padata
-                               -- reply key, ku=[TBD]
-                ...
-         }
-
-   The rep-cksum field is a checksum computed over the DER encoding of
-   the AS-REP or TGS-REP message with which the SERVER-REFERRAL-DATA is
-   included, but with the padata field omitted.  It SHOULD be computed
-   using the mandatory-to-implement checksum type associated with the
-   encryption type of the reply key.  (Encrypting the referral data in
-   with the reply key but without the checksum only proves that it was
-   generated by one of the parties with access to the reply key; it is
-   not proof against cut-and-paste attacks combining parts of different
-   KDC replies using the same reply key.)
-
-   Clients SHALL NOT accept a reply ticket in which the server principal
-   name is different from that of the request, if the KDC response does
-   not contain a PA-SERVER-REFERRAL padata entry.
-
-   The requested-principal-name MUST be included by the KDC, and MUST be
-   verified by the client, if the client sent an AS-REQ, as protection
-   against a man-in-the-middle modification to the AS-REQ message.
-
-   The referred-realm field is present if and only if the returned
-   ticket is a referral TGT, not a service ticket for the requested
-
-
-
-Raeburn & Zhu           Expires January 15, 2009               [Page 10]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-   server principal.
-
-   When a referral TGT is returned and the true-principal-name field is
-   present, the client MUST use that name in the subsequent requests to
-   the server realm when following the referral.
-
-   Client SHALL NOT accept a true server principal name for a service
-   ticket if the true-principal-name field is not present in the PA-
-   SERVER-REFERRAL data.
-
-   The client will use this referral information to request a chain of
-   cross-realm ticket granting tickets until it reaches the realm of the
-   server, and can then expect to receive a valid service ticket.
-
-   However an implementation should limit the number of referrals that
-   it processes to avoid infinite referral loops.  A suggested limit is
-   5 referrals before giving up.
-
-   The client may cache the mapping of the requested name to the name of
-   the next realm to use and the principal name to ask for.  (See
-   Section 10.)  The referral-valid-until field, if present, conveys how
-   long this information is valid for.
-
-   Here is an example of a client requesting a service ticket for a
-   service in realm DEV.EXAMPLE.COM where the client is in
-   ADMIN.EXAMPLE.COM.
-
-      +NC = Canonicalize KDCOption set
-      +PA-REFERRAL = returned PA-SERVER-REFERRAL
-      C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM
-      S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM +PA-REFERRAL
-         containing EXAMPLE.COM as the referred realm with no
-         true-principal-name
-      C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM
-      S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM +PA-REFERRAL
-         containing DEV.EXAMPLE.COM as the referred realm with no
-         true-principal-name
-      C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM
-      S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM
-
-   Note that any referral or alias processing of the server name in
-   user-to-user authentication should use the same data as client name
-   canonicalization or referral.  Otherwise, the name used by one user
-   to log in may not be useable by another for user-to-user
-   authentication to the first.
-
-
-
-
-
-
-Raeburn & Zhu           Expires January 15, 2009               [Page 11]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-9.  Cross Realm Routing
-
-   The current Kerberos protocol requires the client to explicitly
-   request a cross-realm TGT for each pair of realms on a referral
-   chain.  As a result, the client need to be aware of the trust
-   hierarchy and of any short-cut trusts (those that aren't parent-
-   child trusts).
-
-   Instead, using the server referral routing mechanism as defined in
-   Section 8, The KDC will determine the best path for the client and
-   return a cross-realm TGT as the referral TGT, and the target realm
-   for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
-
-   If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
-   a referral TGT.  Clients SHALL NOT process referral TGTs if the KDC
-   response does not contain the PA-SERVER-REFERRAL padata.
-
-
-10.  Caching Information
-
-   It is possible that the client may wish to get additional credentials
-   for the same service principal, perhaps with different authorization-
-   data restrictions or other changed attributes.  The return of a
-   server referral from a KDC can be taken as an indication that the
-   requested principal does not currently exist in the local realm.
-   Clearly, it would reduce network traffic if the clients could cache
-   that information and use it when acquiring the second set of
-   credentials for a service, rather than always having to re-check with
-   the local KDC to see if the name has been created locally.
-
-   If the referral-valid-until field is provided in the PA-SERVER-
-   REFERRAL-DATA message, it indicates the expiration time of this data;
-   if it is not included, the expiration time of the TGT is used.  When
-   the TGT expires, the previously returned referral from the local KDC
-   should be considered invalid, and the local KDC must be asked again
-   for information for the desired service principal name.  (Note that
-   the client may get back multiple referral TGTs from the local KDC to
-   the same remote realm, with different lifetimes.  The lifetime
-   information must be properly associated with the requested service
-   principal names.  Simply having another TGT for the same remote realm
-   does not extend the validity of previously acquired information about
-   one service principal name.)  If the client is still in contact with
-   the service and needs to reauthenticate to the same service
-   regardless of local service principal name assignments, it should use
-   the referred-realm and true-principal-name values when requesting new
-   credentials.
-
-   Accordingly, KDC authors and maintainers should consider what factors
-
-
-
-Raeburn & Zhu           Expires January 15, 2009               [Page 12]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-   (e.g., DNS alias lifetimes) they may or may not wish to incorporate
-   into credential expiration times in cases of referrals.
-
-
-11.  Open Issues
-
-   Client referral info validation
-
-   When should client name aliases be included in credentials?  Should
-   all known client name aliases be included, or only the one used at
-   initial ticket acquisition?
-
-   Should list the policies that need to be defined.
-
-   More examples: u2u, policy checks, maybe cross-realm.
-
-   Possibly generalize the integrity/privacy protection on
-   ServerReferralData into a general padata wrapper?
-
-   Is PA-SERVER-REFERRAL needed in a TGS exchange?
-
-   Do we need to send requested-name fields, or can we just include them
-   in checksums?
-
-
-12.  Number Assignments
-
-   Most number registries in the Kerberos protocol have not been turned
-   over to IANA for management at the time of this writing, hence this
-   is not an "IANA Considerations" section.
-
-   Various values do need assigning for this draft:
-      AD-LOGIN-ALIAS
-      PA-CLIENT-CANONICALIZED
-      key usage value for PA-CLIENT-CANONICALIZED field canon-checksum
-
-
-13.  IANA Considerations
-
-   None at present.
-
-
-14.  Security Considerations
-
-   For the AS exchange case, it is important that the logon mechanism
-   not trust a name that has not been used to authenticate the user.
-   For example, the name that the user enters as part of a logon
-   exchange may not be the name that the user authenticates as, given
-
-
-
-Raeburn & Zhu           Expires January 15, 2009               [Page 13]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-   that the KDC_ERR_WRONG_REALM error may have been returned.  The
-   relevant Kerberos naming information for logon (if any), is the
-   client name and client realm in the service ticket targeted at the
-   workstation that was obtained using the user's initial TGT.
-
-   How the client name and client realm is mapped into a local account
-   for logon is a local matter, but the client logon mechanism MUST use
-   additional information such as the client realm and/or authorization
-   attributes from the service ticket presented to the workstation by
-   the user, when mapping the logon credentials to a local account on
-   the workstation.
-
-14.1.  Shared-password case
-
-   A special case to examine is when the user is known (or correctly
-   suspected) to use the same password for multiple accounts.  A man-in-
-   the-middle attacker can either alter the request on its way to the
-   KDC, changing the client principal name, or reply to the client with
-   a response previously send by the KDC in response to a request from
-   the attacker.  The response received by the client can then be
-   decrypted by the user, though if the default "salt" generated from
-   the principal name is used to produce the user's key, a PA-ETYPE-INFO
-   or PA-ETYPE-INFO2 preauth record may need to be added or altered by
-   the attacker to cause the client software to generate the key needed
-   for the message it will receive.  None of this requires the attacker
-   to know the user's password, and without further checking, could
-   cause the user to unknowingly use the wrong credentials.
-
-   In normal [RFC4120] operation, a generated AP-REQ message includes in
-   the Authenticator field a copy of the client's idea of its own
-   principal name.  If this differs from the name in the KDC-generated
-   Ticket, the application server will reject the message.
-
-   With client name canonicalization as described in this document, the
-   client may get its principal name from the response from the KDC.
-   Requiring the PA-CLIENT-CANONICALIZED data lets the client securely
-   check that the requested name was not altered in transit.  If the PA-
-   CLIENT-CANONICALIZED data is absent, the client can use the principal
-   name it requested.
-
-14.2.  Preauthentication data
-
-   In cases of credential renewal, forwarding, or validation, if
-   credentials are sent to the KDC that are not an initial ticket-
-   granting ticket for the client's home realm, the encryption key used
-   to protect the TGS exchange is one known to a third party (namely,
-   the service for which the credential was issued).  Consequently, in
-   such an exchange, the protection described earlier for the
-
-
-
-Raeburn & Zhu           Expires January 15, 2009               [Page 14]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-   preauthentication data cannot be assumed to provide a secure channel
-   between the KDC and the client, and such preauth data MUST NOT be
-   trusted for any information that needs to come from the KDC.
-
-
-15.  Acknowledgments
-
-   Sam Hartman and authors came up with the idea of using the ticket key
-   to encrypt the referral data, which prevents cut and paste attack
-   using the referral data and referral TGTs.
-
-   John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
-   version of this document.
-
-   Karthik Jaganathan contributed to earlier versions.
-
-
-16.  References
-
-16.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-16.2.  Informative References
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-   [XPR]      Trostle, J., Kosinovsky, I., and M. Swift, "Implementation
-              of Crossrealm Referral Handling in the MIT Kerberos
-              Client",  Network and Distributed System Security
-              Symposium, February 2001.
-
-
-Appendix A.  Compatibility with Earlier Implementations of Name
-             Canonicalization
-
-   The Microsoft Windows 2000 and Windows 2003 releases included an
-
-
-
-Raeburn & Zhu           Expires January 15, 2009               [Page 15]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-   earlier form of name-canonicalization [XPR].  Here are the
-   differences:
-
-   1) The TGS referral data is returned inside of the KDC message as
-      "encrypted pre-authentication data".
-
-
-
-          EncKDCRepPart   ::= SEQUENCE {
-                 key                [0] EncryptionKey,
-                 last-req           [1] LastReq,
-                 nonce              [2] UInt32,
-                 key-expiration     [3] KerberosTime OPTIONAL,
-                 flags              [4] TicketFlags,
-                 authtime           [5] KerberosTime,
-                 starttime          [6] KerberosTime OPTIONAL,
-                 endtime            [7] KerberosTime,
-                 renew-till         [8] KerberosTime OPTIONAL,
-                 srealm             [9] Realm,
-                 sname             [10] PrincipalName,
-                 caddr             [11] HostAddresses OPTIONAL,
-                 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
-         }
-
-   2) The preauth data type definition in the encrypted preauth data is
-      as follows:
-
-
-
-          PA-SVR-REFERRAL-INFO       20
-
-          PA-SVR-REFERRAL-DATA ::= SEQUENCE {
-                 referred-name   [1] PrincipalName OPTIONAL,
-                 referred-realm  [0] Realm
-          }}
-
-   3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is
-      encoded as a Subject Alternative Name (SAN) extension [RFC3280] in
-      the client's X.509 certificate.  The type of the otherName field
-      for this SAN extension is AnotherName [RFC3280].  The type-id
-      field of the type AnotherName is id-ms-sc-logon-upn
-      (1.3.6.1.4.1.311.20.2.3) and the value field of the type
-      AnotherName is a KerberosString [RFC4120].  The value of this
-      KerberosString type is the single component in the name-string
-      [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
-
-   In Microsoft's current implementation through the use of global
-   catalogs any domain in one forest is reachable from any other domain
-
-
-
-Raeburn & Zhu           Expires January 15, 2009               [Page 16]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-   in the same forest or another trusted forest with 3 or less
-   referrals.  A forest is a collection of realms with hierarchical
-   trust relationships: there can be multiple trust trees in a forest;
-   each child and parent realm pair and each root realm pair have
-   bidirectional transitive direct rusts between them.
-
-   While we might want to permit multiple aliases to exist and even be
-   reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only
-   one NT-ENTERPRISE alias to exist, so this question had not previously
-   arisen.
-
-
-Appendix B.  Document history [REMOVE BEFORE PUBLICATION]
-
-   11 Changed title.  Better protection on server referral preauth data.
-      Support server name canonicalization.  Rename ReferralInfo to
-      ClientReferralInfo.  Disallow alias mapping to a TGT principal.
-      Explain why no name change in client referrals.  Add empty IANA
-      Considerations.  Add some notes on preauth data protection during
-      renewal etc.
-   10 Separate enterprise principal names into a separate section.  Add
-      a little wording to suggest server principal name canonicalization
-      might be allowed; not fleshed out.  Advise against AD-KDC-ISSUED
-      in cronn-realm cases.  Advise policy checks on returned client
-      referral info, since there's no security.  List number
-      assignments.  Add security analysis of shared-password case.  No
-      longer plan to remove Microsoft appendix.  Add referral-valid-
-      until field.
-   09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain.
-      Rewrote description of existing practice.  (Don't name the lookup
-      table consulted.  Mention that DNS "canonicalization" is contrary
-      to [RFC4120].)  Noted Microsoft behavior should be moved out into
-      a separate document.  Changed some second-person references in the
-      introduction to identify the proper parties.  Changed PA-CLIENT-
-      CANONICALIZED to use a separate type for the actual referral data,
-      add an extension marker to that type, and change the checksum key
-      from the "returned session key" to the "AS reply key".  Changed
-      AD-LOGIN-ALIAS to contain a sequence of names, to be contained in
-      AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer
-      needed separate checksum.  Attempt to clarify the cache lifetime
-      of referral information.
-   08 Moved Microsoft implementation info to appendix.  Clarify lack of
-      local server name canonicalization.  Added optional authz-data for
-      login alias, to support user-to-user case.  Added requested-
-      principal-name to ServerReferralData.  Added discussion of caching
-      information, and referral TGT lifetime.
-
-
-
-
-
-Raeburn & Zhu           Expires January 15, 2009               [Page 17]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-   07 Re-issued with new editor.  Fixed up some references.  Started
-      history.
-
-
-Authors' Addresses
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA  02139
-   US
-
-   Email: raeburn@mit.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn & Zhu           Expires January 15, 2009               [Page 18]
-
-Internet-Draft                KDC Referrals                    July 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Raeburn & Zhu           Expires January 15, 2009               [Page 19]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-sam-02.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-sam-02.txt
deleted file mode 100644
index ca2ae64f4..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-sam-02.txt
+++ /dev/null
@@ -1,1049 +0,0 @@
-INTERNET-DRAFT                                           Ken Hornstein
-<draft-ietf-krb-wg-kerberos-sam-02.txt>      Naval Research Laboratory
-Updates: RFC 1510                                           Ken Renard
-October 27, 2003                                           WareOnEarth
-                                                       Clifford Newman
-                                                                   ISI
-                                                             Glen Zorn
-                                                         Cisco Systems
-
-
-
-      Integrating Single-use Authentication Mechanisms with Kerberos
-
-
-0. Status Of this Memo
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 10 of RFC2026.  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 docu-
-   ments at any time.  It is inappropriate to use  Internet-Drafts  as
-   reference  material  or  to  cite them other than as ``work in pro-
-   gress.''
-
-   To learn the current status of any Internet-Draft, please check the
-   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
-   dow Directories on ds.internic.net (US East  Coast),  nic.nordu.net
-   (Europe),  ftp.isi.edu  (US  West Coast), or munnari.oz.au (Pacific
-   Rim).
-
-   The distribution of  this  memo  is  unlimited.   It  is  filed  as
-   <draft-ietf-krb-wg-kerberos-sam-02.txt>,   and  expires  April  27,
-   2004.  Please send comments to the authors.
-
-
-1. Abstract
-   This document defines extensions to the Kerberos protocol  specifi-
-   cation  [RFC1510]  which  provide  a  method  by which a variety of
-   single-use authentication mechanisms may be  supported  within  the
-   protocol.  The method defined specifies a standard fashion in which
-   the preauthentication data and error data fields in  Kerberos  mes-
-   sages may be used to support single-use authentication mechanisms.
-
-
-2. Terminology
-   To simplify the following discussion, we will  define  those  terms
-   which  may be unfamiliar to the audience or specific to the discus-
-   sion itself.
-
-   Single-use Preauthentication Data (SPD):  Data sent in the  padata-
-   value  field  of  a  Kerberos  V5 message proving that knowledge of
-
-
-
-Hornstein, Renard, Newman, Zorn                               [Page 1]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-   certain unique information is held by a principal.   This  informa-
-   tion  may  or may not be identical to the single-use authentication
-   data input to the client.  For example, in the case of  S/Key,  the
-   principal  might  input  a  one-time  password  (in  any of several
-   forms); the knowledge of this one-time password is taken  to  indi-
-   cate  knowledge  of  the principal's secret passphrase.  Similarly,
-   the SPD may or may not contain the provided single-use  authentica-
-   tion  data.   For  instance,  if  a given single-use authentication
-   mechanism includes a token which generates an encryption key for  a
-   supported  cryptosystem, that key could be used to encrypt portions
-   of the SPD before transmission.  As long as the  verification  pro-
-   cess  of  the mechanism was capable of independently generating the
-   same key, the  successful  decryption  of  the  SPD  would  provide
-   assurance  that  the originator of the message was in possession of
-   the token, as well as whatever information the  token  required  to
-   generate the encryption key.
-
-   Single-use Authentication Mechanism (SAM):  A system for generating
-   and verifying authentication data which is usable only once.
-
-   Single-use Authentication Data (SAD):  SAM-specific  data  provided
-   by  a principal as input to client software to be used in the crea-
-   tion of SPD.
-
-
-3. Motivation and Scope
-   Several  single-use  authentication  mechanisms  are  currently  in
-   widespread  use, including hardware-based schemes from vendors such
-   as Enigma Logic, CRYPTOCard, and Security  Dynamics  and  software-
-   based  methods  like  S/Key  [RFC1760].  The hardware-based schemes
-   typically require that  the  authenticating  user  carry  a  small,
-   credit-card-sized  electronic device (called a token) which is used
-   to generate unique authentication data.  Some  tokens  require  the
-   user  to  enter data into the device.  This input may take the form
-   of a Personal Identification Number (PIN), a server-generated chal-
-   lenge string or both.  Other tokens do not use a challenge-response
-   technique, instead spontaneously generating new and unique  authen-
-   tication  data  every  few seconds.  These tokens are usually time-
-   synchronized with a server.  The  use  of  one-time  passwords  and
-   token  cards  as an authentication mechanism has steadily increased
-   over the past few years; in  addition,  the  Internet  Architecture
-   Board  has  encouraged the use of SAMs to improve Internet security
-   [RFC1636].
-
-   The widespread acceptance of Kerberos within the Internet community
-   has  produced  considerable demand for the integration of SAM tech-
-   nology with the authentication protocol.  Several currently  avail-
-   able  implementations of Kerberos include support for some types of
-   token cards, but the implementations are either not  interoperable,
-   or  would require the release of source code (not always an option)
-   to make them interoperate.  This memo attempts to remedy that prob-
-   lem  by specifying a method in which SAM data may be securely tran-
-   sported in Kerberos V5 messages in a standard, extensible  fashion.
-   This  document  does  not,  however,  attempt  to precisely specify
-
-
-
-Hornstein, Renard, Newman, Zorn                               [Page 2]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-   either the generation or verification of SAM data,  since  this  is
-   likely to be SAM-specific; nor does it dictate the conditions under
-   which SAM data must be included in Kerberos messages, since we con-
-   sider this to be a matter of local policy.
-
-   A primary reason for using a SAM with Kerberos  is  to  reduce  the
-   threat  from  common  attacks  on Kerberos passwords (poorly chosen
-   passwords, password guessing, etc).  If passwords are used in  com-
-   bination  with  SAM authentication data, users must still adhere to
-   sensible password policies and safe practices regarding the  selec-
-   tion,  secrecy,  and  maintenance of their passwords.  Depending on
-   the specific mechanism used, the purpose of the SAD is  to  augment
-   (or sometimes replace) the use of a password as a secret key.
-
-
-4. Generic Approach - Two Models
-   As outlined above, there are essentially two  types  of  single-use
-   authentication  mechanisms:  challenge/response and time-based.  In
-   order to support challenge/response mechanisms,  the  Kerberos  Key
-   Distribution  Center  (KDC)  must communicate the appropriate chal-
-   lenge string to the user, via the  client  software.   Furthermore,
-   some  challenge/response  mechanisms  require tight synchronization
-   between all instances of the KDC and the client.   One  example  is
-   S/Key  and  its variants.  If the KDC and client do not perform the
-   same number of message digest iterations, the protocol  will  fail;
-   worse,  it  might be possible for an eavesdropping attacker to cap-
-   ture a valid S/Key passcode and replay it to a  KDC  replica  which
-   had an outdated iteration number.  In the time-based case, no chal-
-   lenge is required.  This naturally  gives  rise  to  two  modes  of
-   client behavior, described below.
-
-
-4.1 Challenge/Response Model
-   The client begins with an initial KRB_AS_REQ message  to  the  KDC,
-   possibly using existing preauthentication methods (PA-ENC-TIMESTAMP
-   (encrypted  timestamp),  PA-OSF-DCE  (DCE),  etc.).   Depending  on
-   whether  preauthentication  is  used,  the  user  may or may not be
-   prompted at this time for a Kerberos password.   If  (for  example)
-   encrypted  timestamp  preauthentication is used, then the user will
-   be prompted; on the other hand, if no preauthentication is  in  use
-   the  prompt  for  the  password may be deferred (possibly forever).
-   Note that the use of preauthentication here may  allow  an  offline
-   guessing  attack  against  the  Kerberos password separate from the
-   SPD.  However, if the use of a SAM is required, then  the  password
-   by itself is not sufficient for authentication.  (Specify character
-   strings as UTF-8)
-
-   The KDC will determine in an implementation-  and  policy-dependent
-   fashion if the client is required to utilize a single-use authenti-
-   cation mechanism.  For  example,  the  implementation  may  use  IP
-   address screening to require principals authenticating from outside
-   a firewall to use a SAM, while principals on the inside  need  not.
-   If  SAM  usage  is  required,  then  the  KDC  will  respond with a
-   KRB_ERROR   message,   with   the   error-code   field    set    to
-
-
-
-Hornstein, Renard, Newman, Zorn                               [Page 3]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-   KDC_ERR_PREAUTH_REQUIRED  and the e-data field containing the ASN.1
-   structure that is a sequence of PA-DATA fields.
-
-   If the type of one of the PA-DATA fields  is  PA-SAM-REDIRECT,  the
-   client  should  re-execute  the  authentication  protocol  from the
-   beginning, directing messages to another of the KDCs for the realm.
-   This  is done to allow some methods to require that a single KDC be
-   used for SAM authentication when tight  synchronization  is  needed
-   between all replicas and the KDC database propagation code does not
-   provide such synchronization.  The corresponding padata-value  will
-   contain an encoded sequence of host addresses [RFC1510], from which
-   the client must choose the KDC to be contacted next.   The  PA-SAM-
-   REDIRECT is defined as:
-
-
-   PA-SAM-REDIRECT ::=    HostAddresses
-
-
-   Client implementations SHOULD check the addresses  in  the  PA-SAM-
-   REDIRECT  and  verify  that  they are a subset of the KDC addresses
-   that they have been configured for that realm.
-
-   If none of the PA-DATA fields have a value of PA-SAM-REDIRECT, then
-   if  one  of the PA-DATA fields has the type PA-SAM-CHALLENGE-2, the
-   exchange will continue as described in section 5, below.
-
-   Note that some Kerberos implementations support an older preauthen-
-   tication  mechanism  with the padata types PA-SAM-CHALLENGE and PA-
-   SAM-RESPONSE.  That protocol is depreciated and not defined here.
-
-
-4.2 Time-based Model
-   For mechanisms where no challenge is required,  the  user  (or  the
-   client  software  being  utilized)  may  or  may  not know a priori
-   whether SAM usage is required.  If it does not know, then the  ini-
-   tial exchange may proceed as above.  If it is known that a use of a
-   single-use authentication mechanism  is  required  then  the  first
-   exchange  can  be  skipped  and the authentication will continue as
-   follows.
-
-
-5. SAM Preauthentication
-
-   An optional SAM-CHALLENGE-2 may be sent from the KDC to the  client
-   and  the  client  will  send a SAM-RESPONSE-2 as pre-authentication
-   data in the KRB-AS-REQ.  The details of the messages follow.
-
-5.1 SAM-CHALLENGE-2
-
-   Prior to performing preauthentication using a single-use  authenti-
-   cation  mechanism,  the  client  must  know  whether a challenge is
-   required (if the client doesn't have this information prior to  its
-   sending  the  first  KRB_AS_REQ message, it will be informed of the
-   requirement by the KDC, as described in section  4.1).  The  client
-
-
-
-Hornstein, Renard, Newman, Zorn                               [Page 4]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-   does  NOT need to know the specific type of SAM in use.  If a chal-
-   lenge is required the client will be sent the challenge by the KDC.
-   This  means that a client supporting SAMs will be able to work with
-   new methods without modification.  The challenge, as  well  as  all
-   other prompts mentioned herein, can be internationalized by the KDC
-   on a per-principal basis.
-
-   If a KRB_ERROR message is received from the KDC indicating that SAM
-   usage  is required, that message will include in its e-data field a
-   PA-DATA structure that encodes information  about  the  SAM  to  be
-   used.   This  includes  whether a challenge is required, and if so,
-   the challenge itself; and informational data about the type of  SAM
-   that  is  in  use,  and how to prompt for the SAD.  The SAM type is
-   informational only and does not affect the behavior of the  client.
-   The  prompt  is also informational and may be presented to the user
-   by the client, or it may be safely ignored.
-
-   The ASN.1 definition for the SAM challenge is:
-
-          PA-SAM-CHALLENGE-2 ::= SEQUENCE {
-              sam-body[0]                 PA-SAM-CHALLENGE-2-BODY,
-              sam-cksum[1]                SEQUENCE (1..MAX) OF Checksum,
-              ...
-          }
-
-          PA-SAM-CHALLENGE-2-BODY ::= SEQUENCE {
-              sam-type[0]                 INTEGER (0..4294967295),
-              sam-flags[1]                SAMFlags,
-              sam-type-name[2]            GeneralString OPTIONAL,
-              sam-track-id[3]             GeneralString OPTIONAL,
-                                            -- Key usage of 26
-              sam-challenge-label[4]      GeneralString OPTIONAL,
-              sam-challenge[5]            GeneralString OPTIONAL,
-              sam-response-prompt[6]      GeneralString OPTIONAL,
-              sam-pk-for-sad[7]           OCTET STRING OPTIONAL,
-              sam-nonce[8]                INTEGER (0..4294967295),
-              sam-etype[9]                INTEGER (0..4294967295),
-              ...
-          }
-
-          SAMFlags ::= BIT STRING (SIZE (32..MAX))
-              -- use-sad-as-key(0)
-              -- send-encrypted-sad(1)
-              -- must-pk-encrypt-sad(2)
-
-5.1.1  SAM-TYPE and SAM-TYPE-NAME Fields
-
-   The sam-type field is informational only, but it must be  specified
-   and sam-type values must be registered with the IANA.
-
-   Initially defined values of the sam-type codes are:
-
-       PA_SAM_TYPE_ENIGMA     1   -- Enigma Logic
-       PA_SAM_TYPE_DIGI_PATH  2   -- Digital Pathways
-
-
-
-Hornstein, Renard, Newman, Zorn                               [Page 5]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-       PA_SAM_TYPE_SKEY_K0    3   -- S/key where  KDC has key 0
-       PA_SAM_TYPE_SKEY       4   -- Traditional S/Key
-       PA_SAM_TYPE_SECURID    5   -- Security Dynamics
-       PA_SAM_TYPE_CRYPTOCARD 6   -- CRYPTOCard
-
-   PA_SAM_TYPE_SECURID, PA_SAM_TYPE_DIGI_PATH, PA_SAM_TYPE_ENIGMA, and
-   PA_SAM_TYPE_CRYPTOCARD     represent     popular    token    cards.
-   PA_SAM_TYPE_SKEY is the traditional S/Key protocol,  in  which  the
-   SAD  verifier  does  not  have  knowledge  of the principal's S/Key
-   secret.  PA_SAM_TYPE_SKEY_K0 is a variant of S/Key  that  uses  the
-   same  SAD  and PC software or hardware device, but where the zeroth
-   key (the S/Key secret) is actually stored on, and can be  used  by,
-   the  SAD verifier to independently generate the correct authentica-
-   tion data.
-
-   Note that using  PA_SAM_TYPE_SKEY_K0  gives  up  one  advantage  of
-   S/Key, viz., that the information required to generate the SAD need
-   not be stored on the host; but since the SAD verifier (which may be
-   the  KDC) is assumed to be more secure than other hosts on the net-
-   work, it may be acceptable to give up this advantage in some situa-
-   tions.  The advantage of using this S/Key variant is that the secu-
-   rity of the network protocol is strengthened since the SAD need not
-   be  sent  from the client to the KDC.  Thus, the SAD can be used as
-   part of the key used to encrypt the encrypted parts of both the SPD
-   and the KRB_AS_REP message, rather than being sent protected by the
-   principal's Kerberos secret key  which  may  have  been  previously
-   exposed  to an attacker (see section 6, below).  In any case, there
-   is a definite advantage to being interoperable with the S/Key algo-
-   rithm.
-
-   Due to the volatility of, and rapid developments in,  the  area  of
-   single-use   authentication   mechanisms  (both  software-only  and
-   hardware supported), any subsequently defined sam-type  codes  will
-   be maintained by the IANA.
-
-   The optional sam-type-name field is a UTF-8  character  string  for
-   informational  use only.  It may be used by the client to display a
-   short description of the type of single-use authentication  mechan-
-   ism to be used.
-
-5.1.2  SAM-FLAGS Field
-
-   The sam-flags field indicates whether the SAD is known by  the  KDC
-   (in which case it can be used as part of the encryption key for the
-   ensuing KRB_AS_REP message), or if it must be provided to  the  KDC
-   in a recoverable manner.  If it is known to the KDC, use-sad-as-key
-   indicates that the SAD alone will be used to generate  the  encryp-
-   tion  key  for  the forthcoming KRB_AS_REQ and KRB_AS_REP messages,
-   and that the user will not need  to  also  enter  a  password.   We
-   recommend  that this option only be used if the SAD will be used to
-   generate adequate keying material (sufficient length, secrecy, ran-
-   domness)  for  the cryptographic algorithm used.  If the single-use
-   authentication data is  not  known  (and  cannot  be  generated  or
-   discovered)  by  the KDC, then send-encrypted-sad flag will be set,
-
-
-
-Hornstein, Renard, Newman, Zorn                               [Page 6]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-   indicating that the SAD must be sent to the KDC encrypted under the
-   principal's  secret  key.   If  neither  use-sad-as-key  nor  send-
-   encrypted-sad are set, the client may assume that the KDC knows the
-   SAD,  but  the  Kerberos  password  should  be  used along with the
-   passcode in the derivation of the encryption key (see  below).   No
-   more  than  one  of the send-encrypted-sad and use-sad-as-key flags
-   should be in a SAM-CHALLENGE-2.
-
-   The must-pk-encrypt-sad flag is reserved for future use.   If  this
-   flag  is  set and a client does not support the must-pk-encrypt-sad
-   option (to be defined in a separate document), the client will  not
-   be able to complete the authentication and must notify the user.
-
-5.1.3  SAM-CHECKSUM Field
-
-   The sam-cksum field contains a sequence of  at  least  one  crypto-
-   graphic  checksum  of  encoding of the PA-SAM-CHALLENGE-2 sequence.
-   If the send-encrypted-sad flag is set, the key to be used for  this
-   checksum  is  the client's long-term secret.  If the use-sad-as-key
-   flag is set, then the SAD alone will be used as the key.   If  nei-
-   ther  flag  is  set, then the key used for this checksum is derived
-   from the SAD and the user's password (see section 5.2).
-
-   The checksum algorithm to be used for this is the mandatory  check-
-   sum  associated with the encryption algorithm specified in the sam-
-   etype field, with a key usage of 25.
-
-   In some cases there may be more than one valid SAD; some preauthen-
-   tication  mechanisms  may have a range of valid responses.  In that
-   case, the KDC may elect to return multiple checksums, one for  each
-   possible  SAD response.  The number of possible responses of course
-   depends on the mechanism and site policy.  In the case where multi-
-   ple  checksums  are  returned, the client MUST try each checksum in
-   turn until one of the checksums  is  verified  successfully.   Note
-   that in the non-send-encrypted-sad case the checksum cannot be ver-
-   ified until the user enters in the SAD, but if no checksum  can  be
-   verified, the client MUST not send a response but instead return an
-   error to the user.
-
-   The sam-cksum field  is  generated  by  calculating  the  specified
-   checksum over the DER-encoded SAM-CHALLENGE-2-BODY sequence.
-
-   If no checksum is included, or is of the wrong type,  or  none  are
-   found  which  are  correct, the client MUST abort the dialogue with
-   the   KDC   and    issue,    respectively,    KRB5_SAM_NO_CHECKSUM,
-   KRB5_SAM_BAD_CHECKSUM_TYPE,  or  KRB5_SAM_BAD_CHECKSUM  error  mes-
-   sages.
-
-5.1.4  SAM-TRACK-ID Field
-
-   The optional sam-track-id field may be returned by the KDC  in  the
-   KRB_ERROR  message.   If  present,  the client MUST copy this field
-   into the corresponding field of the SAM response sent in the subse-
-   quent  KRB_AS_REQ  message.   This  field may be used by the KDC to
-
-
-
-Hornstein, Renard, Newman, Zorn                               [Page 7]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-   match challenges and responses.  It might  be  a  suitably  encoded
-   integer,  or  even  be encrypted data with the KDC state encoded so
-   that the KDC doesn't have to maintain the state  internally.   Note
-   that  when  a  KDC  supplies  a sam-track-id, it MUST link the sam-
-   track-id with the sam-nonce field to prevent spoofing of  the  sam-
-   track-id field.
-
-   The key usage type 26 is reserved  for  use  to  encrypt  the  sam-
-   track-id  data.   The  key  used  to  encrypt  the  sam-track-id is
-   mechanism-dependent.
-
-5.1.5  SAM-CHALLENGE-LABEL Field
-
-   The sam-challenge-label field is informational and optional.  If it
-   is  included, is will be an UTF-8 encoded character.  If present, a
-   client may choose to precede the presentation of the challenge with
-   this  string.   For  example,  if  the  challenge is 135773 and the
-   string in the sam-challenge-label field  is  "Enter  the  following
-   number on your card", the client may choose to display to the user:
-
-          Enter the following number on your card: 135773
-
-   If no challenge label was presented, or if the  client  chooses  to
-   ignore it, the client might display instead:
-
-          Challenge from authentication server: 135773
-
-   Internationalization is supported by allowing customization of  the
-   challenge  label  and other strings on a per-principal basis.  Note
-   that this character string should be encoded using UTF-8.
-
-5.1.6  SAM-CHALLENGE Field
-
-   The optional sam-challenge field contains a  string  that  will  be
-   needed  by  the  user to generate a suitable response.  If the sam-
-   challenge field is left out, it indicates that the SAM in use  does
-   not  require  a  challenge,  and that the authorized user should be
-   able to produce the correct SAD without one.  If the  sam-challenge
-   field  is present, it is the data that is used by the SAD generator
-   to create the SAD to be used in the production of  the  SPD  to  be
-   included in the response.
-
-5.1.7  SAM-RESPONSE-PROMPT Field
-
-   The sam-response-prompt field is informational  and  optional.   If
-   present, a client may choose to precede the prompt for the response
-   with the specified string.
-
-          Passcode:
-
-5.1.8  SAM-PK-FOR-SAD Field
-
-   sam-pk-for-sad is  an  optional  field.   It  is  included  in  the
-   interest  of  future  extensability  of  the protocol to the use of
-
-
-
-Hornstein, Renard, Newman, Zorn                               [Page 8]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-   public-key cryptography.
-
-5.1.9  SAM-NONCE Field
-
-   The sam-nonce is a KDC-supplied nonce and  should  conform  to  the
-   specification   of   the  nonce  field  in  a  KRB_KDC_REQ  message
-   [RFC1510].
-
-   Challenge/Response mechanisms MUST link the nonce  field  with  the
-   sam-track-id  (if  one  is  included) to prevent replay of the sam-
-   track-id field.
-
-5.1.10  SAM-ETYPE Field
-
-   The sam-etype field contains the encryption type to be used by  the
-   client  for  all encrypted fields in the PA-SAM-RESPONSE-2 message.
-   The KDC should pick an appropriate encryption  algorithm  based  on
-   the   encryption   algorithms   listed   in  the  client's  initial
-   KRB_AS_REQ.
-
-5.2  Obtaining SAM Authentication Data
-
-   If the client is performing SAM preauthentication  in  the  initial
-   message,  without  receipt  of  a  PA-SAM-CHALLENGE-2 (i.e. without
-   waiting for the KRB_ERROR message), and the SAM  in  use  does  not
-   require  a  challenge,  the  client  will  prompt for the SAD in an
-   application-specific manner.
-
-   Once the user has been prompted for and entered the SAD (and possi-
-   bly the Kerberos password), the client will derive a key to be used
-   to encrypt the preauthentication data  for  a  KRB_AS_REQ  message.
-   This key will be determined as follows:
-
-          By default, the key is derived from the password and the SAD
-          by running each through the string_to_key function [RFC1510]
-          separately; i.e., K1  =  string_to_key(password)  and  K2  =
-          string_to_key(SAD).   When  the  keys  are both DES or 3DES,
-          keys  K1  and  K2  will  be  combined  using  the  algorithm
-          described  in  Appendix  B, ``DES/3DES Key Combination Algo-
-          rithm''.  For all other encryption algorithms, the algorithm
-          described in Appendix A, ``Key Combination Algorithm'' shall
-          be used.  Note that this algorithm is  not  commutative;  an
-          implementation  MUST insure that K1 is the key corresponding
-          to the user's long-term password, and K2 is the output  from
-          the SAD.  In either case, the salt used by the string_to_key
-          algorithm for the SAD shall be the same salt as used for the
-          user's password.
-
-          If the send-encrypted-sad flag  is  set,  the  key  will  be
-          derived   by   running  the  Kerberos  password  though  the
-          string_to_key function in the normal fashion.
-
-          If the use-sad-as-key flag is set and the integrity  of  the
-          PA-SAM-CHALLENGE-2  PADATA  field  can be verified using the
-
-
-
-Hornstein, Renard, Newman, Zorn                               [Page 9]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-          sam-cksum  field,  then  the  SAD   is   run   through   the
-          string_to_key function and the result is used as the encryp-
-          tion key for the request.  WARNING: the  use  of  single-use
-          authentication data in this manner is NOT recommended unless
-          the range of the SAD is large enough to make  an  exhaustive
-          off-line  search  impractical  and the risks involved in the
-          use of SAD alone are  fully  considered.   Also,  note  that
-          without  the availability to the KDC of a relatively static,
-          unique secret key shared with the user, the only  mechanisms
-          that  can  be  used  to protect the integrity of the PA-SAM-
-          CHALLENGE-2 PADATA field are  based  on  either  public  key
-          cryptography  or  the  KDC's  a  priori knowledge of the SAD
-          itself.  In the latter case, the client must obtain the  SAD
-          from  the  user  and  use  it to verify the integrity of the
-          challenge before the new KRB_AS_REQ message is sent.
-
-          The sam-pk-for-sad field is reserved  for  future  use.   If
-          this  field is not empty and the client does not support the
-          use of public-key encryption for SAD (to  be  defined  in  a
-          separate  document), the client will not be able to complete
-          the authentication and must notify the user.
-
-5.3  SAM-RESPONSE PA-DATA
-
-   The client will then send another KRB_AS_REQ message  to  the  KDC,
-   but with a padata field with padata-type equal to PA-SAM-RESPONSE-2
-   and padata-value defined as follows:
-
-          PA-SAM-RESPONSE-2 ::= SEQUENCE {
-              sam-type[0]                 INTEGER (0..4294967295),
-              sam-flags[1]                SAMFlags,
-              sam-track-id[2]             GeneralString OPTIONAL,
-              sam-enc-nonce-or-sad[3]     EncryptedData,
-                                             -- PA-ENC-SAM-RESPONSE-ENC
-                                             -- Key usage of 27
-              sam-nonce[4]                INTEGER (0..4294967295),
-              ...
-          }
-
-          PA-ENC-SAM-RESPONSE-ENC ::= SEQUENCE {
-               sam-nonce[0]               INTEGER (0..4294967295),
-               sam-sad[1]                 GeneralString OPTIONAL,
-               ...
-          }
-
-   The source of the data included in the PA-SAM-RESPONSE-2  structure
-   depends upon whether or not a KRB_ERROR message was received by the
-   client from the KDC.
-
-5.3.1  SAM-TYPE, SAM-FLAGS, and SAM-NONCE Fields
-
-   If an error reply was received, the sam-type, sam-flags,  and  sam-
-   nonce  fields will contain copies of the same fields from the error
-   message.
-
-
-
-Hornstein, Renard, Newman, Zorn                              [Page 10]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-   If no error reply was received  (i.e.,  the  client  knows  that  a
-   single-use  authentication  mechanism  is to be used), the sam-type
-   field must be set to a value chosen from  the  list  of  registered
-   sam-type codes.
-
-   The value of the sam-flags field may vary depending upon  the  type
-   of  SAM  in use, but in all cases the must-pk-encrypt-sad flag must
-   be zero.  If the send-encrypted-sad flag is set, the sam-sad  field
-   must  contain  the entered single-use authentication data (see Sec-
-   tion 5.3.3).
-
-5.3.2  SAM-TRACK-ID Field
-
-   Note that if there is no sam-track-id in the request,  it  MUST  be
-   omitted  in the response.  Otherwise, the sam-track-id data MUST be
-   copied from the SAM-CHALLENGE-2 to the SAM-RESPONSE-2.
-
-5.3.3  SAM-ENC-NONCE-OR-SAD
-
-   The sam-enc-nonce-or-sad field represends the results of the preau-
-   thentication  process.   It  contains  the  encrypted SAD or a SAD-
-   encrypted nonce.  The PA-ENC-SAM-RESPONSE-ENC message is  encrypted
-   with  the SAD, password + SAD, or password (based on the sam-flags)
-   with key usage 27.  The fields of the  PA-ENC-SAM-REPONSE-ENC  mes-
-   sage are populated as follows:
-
-   The sam-nonce contains the nonce from the SAM-CHALLENGE-2.  This is
-   the same as the unencrypted sam-nonce described in section 5.2.2.
-
-   The sam-sad field contains the SAD if send-encrypted-sad is set  in
-   the sam-flags.  Otherwise, it is omitted.
-
-5.4  Verification of the SAM-RESPONSE-2
-
-   Upon receipt the KDC validates this PADATA in  much  the  same  way
-   that  it  validates  the  PA-ENC-TS preauthentication method except
-   that it uses the SAD (if available,  and  possibly  in  conjunction
-   with  saved  state information or portions of the preauthentication
-   data) to determine  the  correct  key(s)  required  to  verify  the
-   encrypted  data.   Note that if the KDC uses the sam-track-id field
-   to encode its state, the SAM-verification routine   is  responsible
-   for  including  information in that field to detect modification or
-   replay by an attacker.
-
-5.5  KRB5-AS-REP
-
-   The rest of the processing of the request proceeds normally, except
-   that  instead  of  being  encrypted  in  the user's secret key, the
-   KRB_AS_REP message is encrypted in the key obtained  above.   Note,
-   however, that some single-use authentication mechanisms may require
-   further KRB_AS_REQ/KRB_ERROR exchanges to complete  authentication;
-   for example, in order to allow the server to resynchronize with the
-   drifting clock on a time-based token card.  In these cases the  KDC
-   may  respond  with another KRB_ERROR message containing a different
-
-
-
-Hornstein, Renard, Newman, Zorn                              [Page 11]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-   sam-type value, along with appropriate prompts  and/or  challenges.
-   This  sequence  of  exchanges  will  continue  until authentication
-   either succeeds or fails.
-
-6.  Requirements for Single-use Authentication Mechanisms
-
-   Single-Use Authentication Mechanisms vary  in  their  capabilities.
-   To  aid  implementers,  we summarize here how various types of SAMs
-   would operate using this protocool.
-
-   If a SAM system can provide a SAD or a sequence of  valid  SADs  to
-   the   KDC,  then  the  implementation  SHOULD  NOT  set  the  send-
-   encrypted-sad flag.  This SAM system should provide the SAD to  the
-   KDC, which will combine it with the user's long-term key (password)
-   to generate the key used to generate the  checksum  placed  in  the
-   sam-cksum  field  in the PA-SAM-CHALLENGE-2 message.  This combined
-   key will also be used by the KDC to verify  PA-SAM-RESPONSE-2  mes-
-   sage  by  using it to decrypt the sam-enc-nonce-or-sad field and as
-   the key to encrypt the KRB-AS-REP.  If a SAM system returns a range
-   of  valid  responses, each response can be used to generate a valid
-   checksum which can be placed in the sam-cksum sequence.
-
-   If a SAM system can generate enough entropy, it can  set  the  use-
-   sad-as-key  field  to use the SAD solely as keying material, but it
-   should be noted that most SAM systems  that  require  the  user  to
-   enter  in  a  response  do  not  have enough entropy to replace the
-   user's long-term key.  The most likely consumer  of  use-sad-as-key
-   is a hardware token which communicates a key directly with Kerberos
-   client software.  With or without the use of  use-sad-as-key,  this
-   is  the  preferred method as it protects against offline dictionary
-   attacks against the user's password.
-
-   If a SAM system cannot provide a SAD or a sequence of SADs  to  the
-   KDC,  then  the send-encrypted-sad flag must be set.  In this case,
-   the SAD will be encrypted using the user's  long-term  key  in  the
-   PA-SAM-RESPONSE-2  message.   It  should  be  noted  that this is a
-   weaker solution, as it does not protect the user's password against
-   offline  dictionary attacks, and any additional entropy provided by
-   the SAM system cannot be used.
-
-7. Security considerations
-
-   Single-use authentication  mechanisms  requiring  the  use  of  the
-   send-encrypted-sad  option are discouraged as their use on the net-
-   work is less secure than the case where a combination of the  users
-   password  and  SAD  is  used as the encryption key.  In particular,
-   when  the  send-encrypted-sad  option  is  used,  an  attacker  who
-   observes the response and is in possession of the users' secret key
-   (which doesn't change from login to  login)  can  use  the  key  to
-   decrypt the response and obtain the single-use authentication data.
-   This is dependent on the SAM technology used.
-
-   If the KDC sets the must-pk-encrypt-sad flag of the sam-flags field
-   but  the  client  software  being  used does not support public-key
-
-
-
-Hornstein, Renard, Newman, Zorn                              [Page 12]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-   cryptography, it is possible that legitimate users  may  be  denied
-   service.
-
-   An attacker in possession of the users encryption key (again, which
-   doesn't   change   from   login   to   login)   might  be  able  to
-   generate/modify a SAM challenge and attach the  appropriate  check-
-   sum.   This  affects  the  security  of both the send-encrypted-sad
-   option and the must-pk-encrypt-sad option.
-
-
-8. Expiration
-   This Internet-Draft expires on April 27, 2004.
-
-
-9. References
-
-   [RFC1510]
-        The Kerberos Network Authentication System; Kohl  and  Neuman;
-        September 1993.
-
-   [RFC1760]
-        The S/Key One-Time Password System; Haller; February 1995
-
-   [RFC1636]
-        Report of IAB Workshop on Security in the  Internet  Architec-
-        ture; Braden, Clark, Crocker and Huitema; June 1994
-
-   [KCRYPTO]
-        Encryption and Checksum Specifications for  Kerberos  5;  Rae-
-        burn; May 2002
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornstein, Renard, Newman, Zorn                              [Page 13]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-10. Authors' Addresses
-   Ken Hornstein
-   Naval Research Laboratory
-   4555 Overlook Avenue
-   Washington, DC 20375
-
-   Phone: 202-404-4765
-   EMail: kenh@cmf.nrl.navy.mil
-
-
-   Ken Renard
-   WareOnEarth
-   6849 Old Dominion Dr, Suite 365
-   Annandale, VA 22003
-
-   Phone: 703-622-3469
-   EMail: kdrenard@wareonearth.com
-
-
-   B. Clifford Neuman
-   USC/Information Sciences Institute
-   4676 Admiralty Way #1001
-   Marina del Rey, CA 90292-6695
-
-   Phone: 310-822-1511
-   EMail: bcn@isi.edu
-
-
-   Glen Zorn
-   Cisco Systems
-   500 108th Ave NE
-   Suite 500
-   Bellevue, WA  98004
-
-   Phone: 425-344-8113
-   EMail: gwz@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornstein, Renard, Newman, Zorn                              [Page 14]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-Appendix A - Key combination algorithm
-
-   Definitions:
-
-   prf - Pseudo-random function that outputs an octet string based  on
-   an input key and a input octet string (defined in [KCRYPTO])
-
-   ^   - Exclusive-OR operation
-
-   random-to-key - Generates  an  encryption  key  from  random  input
-   (defined in [KCRYPTO])
-
-   Given two input keys, K1 and K2,  where  K1  is  derived  from  the
-   user's  long-term  password, and K2 is derived from the SAD, output
-   key (K3) is derived as follows:
-
-   Two sequence of octets, R1 and R2, shall be produced for  each  key
-   K1  and K2.  R1 and R2 will be generated by iterating over calls to
-   prf() until enough bits are generated as needed by  the  random-to-
-   key function for the encryption type specified for K3.
-
-   The octet-string parameter to the prf() function shall be the ASCII
-   string  "CombineA"  for  K1, and "CombineB" for K2.  These have the
-   following byte values:
-               { 0x43 0x6f 0x6d 0x62 0x69 0x6e 0x65 0x41 }
-               { 0x43 0x6f 0x6d 0x62 0x69 0x6e 0x65 0x42 }
-
-   Furthermore,  on  each  iteration  both  octet-strings  will   have
-   appended  to them the iteration count in the form of an ASCII, base
-   10, numeral.  The iteration count shall start at zero.  The  format
-   of  the iteration count is equivalant to the C language "%d" format
-   to the printf() function call.  Pseudo code implementing this  fol-
-   lows:
-
-   count = 0;
-   while ( bits < required_bits) {
-       sprintf(A1, "CombineA%d", count);
-       sprintf(A2, "CombineB%d", count);
-       R1 += prf(K1, A1);
-       R2 += prf(K2, A2);
-       count++;
-   }
-
-   When R1 and R2 have been generated, they are truncated if the  they
-   are  longer  than the length required by random-to-key.  The key is
-   then generated as follows:
-
-       K3 = random-to-key(R1 ^ R2)
-
-
-
-
-
-
-
-
-
-Hornstein, Renard, Newman, Zorn                              [Page 15]
-
-
-
-
-
-INTERNET-DRAFT                                        October 27, 2003
-
-
-   Appendix B - DES/3DES Key combination algorithm
-
-      Definitions:
-
-      DR - generate "random" data from an encryption key  (defined  in
-      [KCRYPTO])
-
-      n-fold - "stretches" or "shrinks" a sequence bits to a specified
-      size (defined in [KCRYPTO])
-
-      random-to-key - Generates an encryption key  from  random  input
-      (defined in [KCRYPTO])
-
-      DK - Derive-Key, defined in [KCRYPTO])
-
-      CombineConstant - The ASCII encoding of  the  string  "combine",
-      which is defined as the following byte string:
-
-                   { 0x63 0x6f 0x6d 0x62 0x69 0x6e 0x65 }
-
-      Note: | means "concatenate"
-
-      Given two input keys, K1 and K2, the Combine-Key function is  as
-      follows:
-
-      R1 = DR(K1, n-fold(K2)) R2 = DR(K2, n-fold(K1))
-
-      rnd = n-fold(R1 | R2)
-
-      tkey = random-to-key(rnd)
-
-      Combine-Key(K1, K2) = DK(tkey, CombineConstant)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornstein, Renard, Newman, Zorn                              [Page 16]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-00.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-00.txt
deleted file mode 100644
index da5dd0dac..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-00.txt
+++ /dev/null
@@ -1,1352 +0,0 @@
-
-Kerberos Working Group                                  Jonathan Trostle
-INTERNET-DRAFT                                             Cisco Systems
-Category: Standards Track                                     Mike Swift
-                                                        University of WA
-                                                             John Brezak
-                                                               Microsoft
-                                                            Bill Gossman
-                                                           Cisco Systems
-                                                        Nicolas Williams
-                                                        Sun Microsystems
-
-
-
-                Kerberos Set/Change Password: Version 2
-              <draft-ietf-krb-wg-kerberos-set-passwd-00.txt>
-
-
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026 [RFC2026].
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This draft expires on December 31st, 2001. Please send comments to
-   the authors.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This proposal specifies an extensible protocol for setting keys and
-   changing the passwords of Kerberos [RFC1510] principals.
-
-   The protocol support a single operation per-session when run over UDP, or
-
-Trostle et. al.							[Page 1]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-   multiple operations per-session when run over TCP.  Clients can
-   change their own principal's password or keys or they can change
-   other principals', provided that they are properly authorized to do
-   so.
-
-   Additional related features include the ability to determine the
-   known aliases of Kerberos principals.  This feature will facilitate
-   the implementation of aliasing of target principal names in KDC
-   requests by allowing principals to know which names are aliases of
-   their canonical principal names.  Principal aliasing is needed to
-   properly support the use of aliases and short-form names by users
-   without requiring that clients canonicalize principal names, possibly
-   using insecure name services in the process.
-
-   This protocol uses IETF language tags [RFC3066] to negotiate proper
-   localization of help messages intended for users.  UTF-8 is used
-   throughout for strings, suitably constrained, where necessary, by the
-   minor version of Kerberos V in use by clients and servers.
-
-1. Introduction
-
-   Kerberos lacks a single, standard protocol for changing passwords and
-   keys.  While several vendor-specific protocols exist for changing
-   Kerberos passwords/keys, none are properly internationalized.
-
-   This document defines a protocol that is somewhat backward-compatible
-   with the "kpasswd" protocol, version 1 [KPASSWDv1] and a derivative
-   defined in [RFC3244] that uses more or less the same protocol framing.
-
-   This new protocol is designed to be extensible and properly
-   internationalized.
-
-2. Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-3. Table of Contents
-
-   1. Introduction
-   2. Conventions used in this document
-   3. Table of Contents
-   4. The Protocol
-   4.1 Transports
-   4.2 Protocol Framing
-   4.2.1 The protocol over UDP
-   4.2.2 The protocol over TCP
-   4.3 Protocol version negotiation
-   4.3.1 Protocol major version negotiation
-   4.3.2 Protocol minor version negotiation
-   4.4 Use of Kerberos V
-   4.4.1 Use of KRB-ERROR
-
-Trostle et. al.							[Page 2]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-   4.5 Use of ASN.1
-   4.6 Protocol internationalization
-   4.6.1 Normalization forms for UTF-8 strings
-   4.6.2 Language negotiation
-   4.7 Protocol Extensibility
-   4.8 Protocol Subsets
-   5  Protocol Operations
-   5.1 PDUs
-   6  ASN1 Module
-   7 Descriptions of each protocol requests and responses
-   7.1 Null Request
-   7.2 Change Password
-   7.3 Set Keys Requests
-   7.5 The Get Policy Request
-   7.6 The Get Aliases Request
-   7.7 The Get Supported Enctypes Request
-   8 IANA Considerations
-   9 Security Considerations
-   10 Description of TLV Encoding of Sample Subsets of the Protocol
-   10.1 TLV encoding of the Null request and response
-   10.2 TLV encoding of Error-Response
-   10.3 TLV encoding of the change password requests and responses
-   10.4 TLV encoding of Change Keys requests and responses
-   11 Acknowledgements
-   12 References
-   13 Expiration Date
-   14 Authors' Addresses
-   15 Notes to the RFC Editor
-
-4. The Protocol
-
-   The structure of the protocol is quite similar to that of typical RPC
-   protocols.  Each operation has a structure for each client request and
-   a structure for each server response.  Each transaction consists of a
-   single operation; the abstract syntax for the protocol implies the
-   use, on the wire, of an operation identifier associated with an
-   opaque blob representing the request of response.  The protocol data
-   is wrapped in a KRB-PRIV and framed in a header that is backwards
-   compatible with version 1 of this protocol.
-
-4.1 Transports 
-
-   The service SHOULD accept requests on UDP port 464 and TCP port 464.
-   This is the same port used by version 1 [KPASSWDv1] of this protocol,
-   but version 2 is a completely different protocol sharing with version
-   1 only the outer framing.
-
-4.2 Protocol Framing
-
-   For compatibility with the original Kerberos password changing
-   protocol developed at MIT, the first 4 bytes of the message consist
-   of a 2-byte network byte order message length, followed by a 2 byte
-   network byte order protocol version number, followed by a 2 byte
-
-Trostle et. al.							[Page 3]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-   network byte order length for an optional AP-REQ, AP-REP or
-   KRB-ERROR, followed by the same, if present, followed by a KRB-PRIV
-   (optional in TCP) containing the actual protocol message encoded in
-   DER [X690].
-
-   In the case of TCP there is an additional 4 byte network byte order
-   length prepended to the frame described above.
-   
-   The protocol version number MUST be set to 2 for this protocol.
-
-   Bytes on the wire description of the framing:
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |         message length        |    protocol version number    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      | AP-REQ length (0 if absent)   | AP-REQ data (if present)      /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      /                   KRB-PRIV message                            /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   The same framing applies equally to requests and responses, but 
-   responses use AP-REP and/or KRB-ERROR instead of AP-REQ:
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |         message length        |    protocol version number    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      | AP-REP length (0 if absent)   | AP-REP data (if present)      /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      /                   KRB-PRIV message                            /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |         message length        |    protocol version number    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      | KRB-ERROR length (0 if absent)| KRB-ERROR data (if present)   /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   For the UDP case the AP-REQ/AP-REP/KRB-ERROR MUST always be included.
-
-   Note that this framing is used by version 1 [KPASSWDv1] and version
-   0xff80 [RFC3244], though the latter does not use the framing when
-   responding with KRB-ERROR messages.
-
-   Servers MAY respond to version 0xff80 requests with an un-framed
-   KRB-ERROR and e-data set as per-RFC3244 [RFC3244], otherwise clients
-   and server MUST always use this framing.  See section 4.3.
-
-
-Trostle et. al.							[Page 4]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-4.2.1 The protocol over UDP
-
-   In the UDP case there is a single message from the client and a
-   single response from the server with no state kept between requests,
-   and each request MUST include a Kerberos AP-REQ and a KRB-PRIV and
-   each response MUST carry an AP-REP, or KRB-ERROR and a KDB-PRIV.
-   Both the client and server MUST destroy the authentication context
-   after each operation.
-
-   UDP clients MUST not request the use of sequence numbers, otherwise
-   it cannot generate the KRB-PRIV prior to receiving the AP-REP.
-   Clients MAY refuse to operate version 2 of the protocol over UDP; it
-   is RECOMMENDED that servers reject version 2 UDP requests.
-
-4.2.2 The protocol over TCP
-
-   When used with the TCP transport, there is a 4 octet header in
-   network byte order that precedes the message and specifies the length
-   of the message.
-
-   The initial message from the client MUST carry an AP-REQ and the
-   response to any request bearing an AP-REQ MUST carry an AP-REP.
-
-   Subsequent messages MAY involve Kerberos V AP exchanges, but
-   generally the client SHOULD NOT initiate a new AP exchange except
-   when it desires to authenticate as a different principal, when
-   its current authentication context is about to expire or when the
-   server responds with an error indicating that the client must
-   re-initialize the authentication context (possibly due to the
-   previous context expiring).
-
-   The server MUST NOT process any requests that do not contain an
-   AP-REQ unless a non-expired authentication context is currently
-   established with the client on the same TCP connection.
-
-   Servers MAY close open sessions at any time.
-
-4.3 Protocol version negotiation
-
-   There are several major versions of this protocol.  Version 2 also
-   introduces a notion of protocol minor versions for use in negotiating
-   protocol extensions.  As of this time only one minor version is
-   defined for major version 2: minor version 0.
-
-4.3.1 Protocol major version negotiation
-
-   Version 2 clients that also support other versions, such as
-   [KPASSWDv1] or [rfc3244] SHOULD attempt to use version 2 of the
-   protocol first and then try other versions if the server
-   responds with either a message framed as described in section 4.2 but
-   with a protocol version number other than 2 (in the case of
-   [KPASSWDv1], or a KRB-ERRROR with an error code of
-   KRB5_KPASSWD_BAD_VERSION in the e-data field [RFC3244].
-
-Trostle et. al.							[Page 5]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-
-   Note that some version 1 servers return a KRB-ERROR indicating that
-   versions other than 1 of the change password protocol are not
-   supported rather than an AP-REP and a KRB-PRIV containing the error
-   data.  Therefore change password protocol negotiation is subject to
-   downgrade attacks where version 2 clients support version 1 of this
-   protocol.
-
-   Also note that some [RFC3244] implementations do not return any
-   responses to requests for protocol versions other than 0xff80, and in
-   the TCP case close the TCP connection.
-
-   Version 2 servers MAY support other versions of the Kerberos password
-   change protocol.
-
-   Version 2 servers SHOULD respond to non-v2 requests using whatever
-   response is appropriate for the versions used by the clients, but if
-   a server does not do this or know how to do this then it MUST respond
-   with an error framed as in section 4.2, using an AP-REP and KRB-PRIV
-   if the client's AP-REQ can be accepted, or a KRB-ERROR (framed)
-   otherwise and using a ProtocolErrorCode value of
-   unsupported-major-version.
-
-4.3.2 Protocol minor version negotiation
-
-   Version 2 clients are free to use whatever protocol minor version and
-   message extensions are available to them in their initial messages to
-   version 2 servers, provided that the minor versions (other than 0)
-   have been defined through IETF documents and registered with the
-   IANA.
-
-   Version 2 clients and servers MUST support all protocol minor
-   versions between 0 to the highest version supported by the client and
-   server.  That is, a client or server that supports minor version 4
-   MUST also support minor versions 0, 1, 2 and 3.
-
-   Version 2 servers MUST answer with the highest protocol minor version
-   number supported by the server and the client.
-
-   Version 2 clients MUST use the protocol minor version used in a
-   server's reply for any subsequent messages in the same session
-   (currently this only applies to TCP sessions).
-
-   See section 4.7 for further description of the protocol's
-   extensibility and its relation to protocol minor versions and the
-   negotiation thereof.
-
-4.4 Use of Kerberos V
-
-   This protocol makes use of messages defined in [RFC1510] and
-   [clarifications].  Specifically, AP-REQ, AP-REP, KRB-ERROR and
-   KRB-PRIV.  Because of the proposed extensions to Kerberos V which
-   will require a new ASN.1 module, and because of the ways that the
-
-Trostle et. al.							[Page 6]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-   Kerberos V ASN.1 types will change, this protocol cannot safely
-   import any types from the Kerberos V module, therefore the Kerberos
-   PDUs are encoded as OCTET STRINGs herein.
-
-   All operations are to be performed by the server on behalf of the
-   client principal.
-
-   The client SHOULD use "kadmin/changepw" as the server principal name
-   for this protocol.  The server MUST have a principal name of
-   "kadmin/changepw" and MAY have a principal name of "kadmin/setpw."
-
-   The client MUST request mutual authentication and the client MUST NOT
-   request the use of sequence numbers when using the protocol over
-   UDP, but it MUST request the use of sequence numbers when running
-   over TCP.
-
-   The server MUST reject requests that operate on the same principal as
-   the client's if the client's principal is not in the same realm as
-   the server's principal name or if the client's ticket is not INITIAL.
-
-   The server MAY reject all requests from clients operating on
-   principals not in the client's realm.  The server MAY reject all
-   requests operating on principals other than the client's.
-
-4.4.1 Use of KRB-ERROR
-
-   When an error arises during the AP exchange for which
-   [clarifications] does not provide an appropriate error code then the
-   server MUST use KRB_ERR_GENERIC as the error, a localized (if
-   possible [er, is that ok, pre-extensions? probably not]) error string
-   for the e-text field of KRB-ERROR and the encoding of an
-   Error-Response PDU (see section 6) as e-data.
-
-4.5 Use of ASN.1
-
-   This protocol's messages are defined in ASN.1, using only features
-   from [X680].  All ASN.1 types defined herein are to be encoded in
-   DER [X690].  A complete ASN.1 module is given in section 6.  The
-   ASN.1 tagging environment for this module is EXPLICIT.
-
-   The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
-   KRB-PRIV as described above.
-
-4.6 Protocol internationalization
-
-   Protocol requests have an optional field indicationg the languages
-   spoken by the client user; the client SHOULD send its list of spoken
-   languages to the server (once per-TCP session), but if future
-   extensions to the Kerberos protocol should add similar functionality
-   then the client SHOULD NOT use this field when using the extended
-   Kerberos protocol.  All strings in the protocol are UTF-8 strings.
-   The server SHOULD localize all strings intended for users to a
-   language in common with the languages spoken by the client user.
-
-Trostle et. al.							[Page 7]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-
-   For TCP sessions servers MUST cache the optional language tag lists
-   from prior requests for use with requests that exclude the language
-   tag list.  Clients MAY expect such server behaviour and send the
-   language tag lists only when they change or even just once per-TCP
-   session.  Clients SHOULD send the server the language tag list at
-   least once, with or before any actual operation.
-
-   Kerberos principal and realm names used in this protocol MUST be
-   constrained as per the specification of the version of Kerberos V
-   used by the client.
-
-4.6.1 Normalization forms for UTF-8 strings
-
-   No normalization form is required for string types other than
-   for PrincipalName and Realm, which two types are constrained by the
-   specification of the version of Kerberos V used by the client, and
-   the password fields in the change password operation, which MUST be
-   normalized according to [k5stringprep].
-
-4.6.2 Language negotiation
-
-   The server MUST pick a language from the client's input list or
-   the default language tag (see [RFC3066]) for text in its responses
-   which is meant for the user to read.
-
-   The server SHOULD use a language selection algorithm such that
-   consideration is first given to exact matches between the client's
-   spoken languages and the server's available locales, followed by
-   "fuzzy" matches where only the first sub-tags of the client's
-   language tag list are used for matching against the servers available
-   locales.
-
-   When the server has a message catalog for one of the client's spoken
-   languages the server SHOULD localize any text strings intended for
-   users to read.
-
-4.7 Protocol Extensibility
-
-   The protocol is defined in ASN.1 and uses extensibility markers
-   throughout.  As such, the module presented herein can be extended
-   within the framework of [X680].
-
-   Typed holes are not used in this protocol as it is very simple and
-   does not require the ability to deal with abstract data types defined
-   in different layers.  For this reason, the only way to extend this
-   protocol is by extending the ASN.1 module within the framework of the
-   IETF; all future extensions to this protocol have to be defined in
-   IETF documents unless otherwise specified in a future IETF revision
-   of this protocol.
-
-   A protocol minor version number is used to negotiate use of
-   extensions.  See section 4.3.2 for the minor version negotiation.
-
-Trostle et. al.							[Page 8]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-
-   Message extensions are to be closely tied to protocol minor numbers.
-   Clients MAY use any protocol minor version that they support in
-   initial requests, and MUST use the protocol minor version indicated
-   in the server's initial reply in any subsequent requests in the same
-   session (this only applies in the TCP case).  Clients MAY cache the
-   minor version number supported by any given server for a reasonably
-   short and finite amount of time - 24 hours is the maximum RECOMMENDED
-   time for caching server minor version information.
-
-   Servers SHOULD ignore protocol extensions and minor versions that they
-   do not understand in initial requests, except for extensions to the
-   "Op-req" type, which MUST result in an error; servers MAY respond
-   with an error (ProtocolErrorCode value of unsupported-minor-version)
-   to clients that use minor versions unsupported by the server in their
-   initial requests.
-
-   Servers MUST select the highest minor version in common with their
-   clients for use in replies.
-
-   Servers MAY support a subset of the operations defined in this
-   protocol but MUST support all the PDUs.
-
-4.8 Protocol Subsets
-
-   The structure of the protocol is such that the ASN.1 syntaxes for the
-   various operations supported by the protocol are independent of the
-   each other.  Clients and servers MAY implement subsets of the overall
-   protocol.
-
-   The structure of this protocol and the properties of the
-   tag-length-value (TLV) DER encoding of ASN.1 make it possible to
-   describe the encoding of individual operations' messages very simply.
-
-   In the interest of facilitating ease of implementation for trivial
-   subsets of this protocol, without the need for ASN.1 compilers,
-   section 10 describes examples of TLV layouts of some individual
-   protocol operations (but the DER encodings of tags, lengths and
-   UNIVERSAL values is not described).
-
-
-5  Protocol Operations
-
-   The protocol as defined herein supports the following operations
-   relating to the management of Kerberos principal's passwords or keys:
-
-     - change password
-     - set key
-     - get password policy name and/or description of principal
-     - list aliases of a principal
-     - list enctypes supported by realm
-
-   These operations are needed to support Kerberos V interoperability
-
-Trostle et. al.							[Page 9]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-   between clients and KDCs of different implementation origins.
-
-   The operation for retrieving a list of aliases of a principal is
-   needed where KDCs implement aliasing of principal names and allows
-   clients to properly setup their "keytabs" when principal aliasing is
-   in use.
-
-   Operations such as creation or deletion of principals are outside the
-   scope of this document, and should be performed via directories or
-   other Kerberos administration protocols.  However, it is conceivable
-   that such operations could be added to this protocol at a later
-   point.
-
-   Operations can be added to the protocol only via future IETF RFCs.
-
-   The individual operations are described in section 7.
-
-5.1 PDUs
-
-   The types "Request," "Response" and "Error-Response" are the ASN.1
-   module's PDUs.
-
-   The "Request" and "Response" PDUs are always to be sent wrapped in
-   KRB-PRIV messages, except for the "Error-Response" PDU which MUST be
-   sent as KRB-ERROR e-data (see section 4.4.1) when AP exchanges fail,
-   otherwise it MUST be sent wrapped in a KRB-PRIV.
-
-   The PDUs are described in section 6.
-
-
-6  ASN1 Module
-
-DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
--- Unsafe: IMPORT AP-REQ, AP-REP, KRB-ERROR, KRB-PRIV, PrincipalName,
---			    Realm, KerberosString, FROM KerberosV5Spec2
-
--- From [clarifications]
-PrincipalName	    ::= SEQUENCE {
-	name-type   [0] Int32,
-	name-string [1] SEQUENCE OF UTF8String
-}
-Realm		    ::= UTF8String
--- NOTE WELL: Principal and realm names MUST be constrained by the
---            specification of the version of Kerberos V used by the
---            client.
--- 
--- [Perhaps PrincipalName should be a SEQUENCE of an optional name type
--- and a UTF8String, for simplicity.]
-
--- From [clarifications]
-Int32	    ::= INTEGER (-2147483648..2147483647)
-UInt32	    ::= INTEGER (0..4294967295)
-
-Trostle et. al.							[Page 10]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-
--- Based on EncryptionKey type from [clarifications]
-Key	    ::= SEQUENCE {
-	enc-type	[0] Int32,	-- from Kerberos
-	key		[1] OCTET STRING,
-	...
-}
-
-Etype	    ::= Int32	-- as in [clarifications]
--- Perhaps we should use an extensible CHOICE of Int32?
-
-Language-Tag	    ::= UTF8String -- Constrained by [RFC3066]
-
--- Use LangTaggedText instead of UTF8String for *-text fields and remove
--- "language" field?
---
--- LangTaggedText should be used as e-text for KRB-ERROR, at least in
--- extensions, perhaps in [clarifications]
-LangTaggedText	    ::= SEQUENCE {
-	language	[0] Language-Tag OPTIONAL,
-	text		[1] UTF8String,
-	...
-}
-
-Request		::= [APPLICATION 0] SEQUENCE {
-	pvno-major	[0] INTEGER DEFAULT 2,
-	pvno-minor	[1] INTEGER DEFAULT 0,
-	languages	[2] SEQUENCE OF Language-Tag OPTIONAL,
-	targ-name	[3] PrincipalName OPTIONAL,
-	targ-realm	[4] Realm OPTIONAL,
-		-- If targ-name/realm are missing then the request
-		-- applies to the principal of the client
-	operation	[5] Op-req,
-	...
-}
-
-Response	::= [APPLICATION 1] SEQUENCE {
-	pvno-major	[0] INTEGER DEFAULT 2,
-	pvno-minor	[1] INTEGER DEFAULT 0,
-	language	[2] Language-Tag DEFAULT "i-default",
-	result		[3] Op-rep OPTIONAL,
-	...
-}
-
-Error-Response	::= [APPLICATION 2] SEQUENCE {
-	pvno-major	[0] INTEGER DEFAULT 2,
-	pvno-minor	[1] INTEGER DEFAULT 0,
-	language	[2] Language-Tag DEFAULT "i-default",
-	error-code	[3] ProtocolErrorCode,
-	help-text	[4] UTF8String OPTIONAL,
-	op-error	[5] Op-error OPTIONAL,
-	...
-}
-
-Trostle et. al.							[Page 11]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-
-Op-req		::= CHOICE {
-	null			[0] Req-null,
-	change-pw		[1] Req-change-pw,
-	set-keys		[2] Req-set-keys,
-	get-pw-policy		[3] Req-get-pw-policy,
-	get-princ-aliases	[4] Req-get-princ-aliases,
-	get-supported-etypes	[5] Req-get-supported-etypes,
-	...
-}
-
-Op-rep		::= CHOICE {
-	null			[0] Rep-null,
-	change-pw		[1] Rep-change-pw,
-	set-keys		[2] Rep-set-keys,
-	get-pw-policy		[3] Rep-get-pw-policy,
-	get-princ-aliases	[4] Rep-get-princ-aliases,
-	get-supported-etypes	[5] Rep-get-supported-etypes,
-	...
-}
-
-Op-error	::= CHOICE {
-	null			[0] Err-null,
-	change-pw		[1] Err-change-pw,
-	set-keys		[2] Err-set-keys,
-	get-pw-policy		[3] Err-get-pw-policy,
-	get-princ-aliases	[4] Err-get-princ-aliases,
-	get-supported-etypes	[5] Err-get-supported-etypes,
-	...
-}
-
-ProtocolErrorCode	    ::= ENUM {
-	-- Remember, ASN.1 enums are zero-based
-	generic-error,
-	unsupported-major-version,
-	unsupported-minor-version,
-	unsupported-operation,
-	authorization-failed,
-	initial-ticket-required,
-	target-principal-unknown,
-	...
-}
-
---
--- Requests and responses
---
-
--- NULL request, much like ONC RPC's NULL procedure
-Req-null    ::= NULL
-
-Rep-null    ::= NULL
-
-Err-null    ::= NULL
-
-Trostle et. al.							[Page 12]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-
--- Change password
-Req-change-pw	::= SEQUENCE {
-	old-pw		[0] UTF8String,
-	new-pw		[1] UTF8String OPTIONAL,
-	etypes		[2] SEQUENCE (1..) OF Etype OPTIONAL,
-	...
-}
-
-Rep-change-pw	::= SEQUENCE {
-	info-text	[0] UTF8String OPTIONAL,
-	new-pw		[1] UTF8String OPTIONAL,
-				-- generated by the server if present
-				-- (and requested by the client)
-	etypes		[2] SEQUENCE (1..) OF Etype OPTIONAL,
-	...
-}
-
-Err-change-pw	::= SEQUENCE {
-	help-text		[0] UTF8String OPTIONAL,
-	code			[1] ENUM {
-		generic,
-		wont-generate-new-pw,
-		old-pw-incorrect,
-		new-pw-rejected-generic,
-		pw-change-too-soon,
-		...
-	},
-	suggested-new-pw	[2] UTF8String OPTIONAL,
-	...
-}
-
--- Change/Set keys
-
-Req-set-keys	::= SEQUENCE {
-	etypes		[0] SEQUENCE (1..) OF Etype,
-	entropy		[1] OCTET STRING OPTIONAL,
-				-- The client can provide entropy for
-				-- the server's use while generating
-				-- keys.
-	...
-}
-
-Rep-set-keys	::= SEQUENCE {
-	info-text	[0] UTF8String OPTIONAL,
-	kvno		[1] UInt32,
-	keys		[2] SEQUENCE (1..) OF Key,
-				-- The server always makes the keys.
-	aliases		[3] SEQUENCE OF SEQUENCE {
-		name	    [0] PrincipalName,
-		realm	    [1] Realm OPTIONAL,
-		...
-	} OPTIONAL,
-
-Trostle et. al.							[Page 13]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-	...
-}
-
-Err-set-keys	::= SEQUENCE {
-	help-text	[0] UTF8String OPTIONAL, -- Reason for rejection
-	enctypes	[1] SEQUENCE of Etype OPTIONAL, -- supported enctypes
-	code		[2] ENUM {
-		etype-no-support,
-		...
-	}
-}
-
--- Get password policy
-Req-get-pw-policy   ::= NULL
-
-Rep-get-pw-policy   ::= SEQUENCE {
-	help-text	[0] UTF8String OPTIONAL,
-	policy-name	[1] UTF8String OPTIONAL,
-	description	[2] UTF8String OPTIONAL,
-	...
-}
-
-Err-get-pw-policy   ::= NULL
-
--- Get principal aliases
-Req-get-princ-aliases	::= NULL
-
-Rep-get-princ-aliases	::= SEQUENCE {
-	help-text	[0] UTF8String OPTIONAL,
-	aliases		[1] SEQUENCE OF SEQUENCE {
-		name	    [0] PrincipalName,
-		realm	    [1] Realm OPTIONAL,
-		...
-	} OPTIONAL,
-	...
-}
-
-Err-get-princ-aliases	::= NULL
-
--- Get list of enctypes supported by KDC for new keys
-Req-get-supported-etypes    ::=	NULL
-
-Rep-get-supported-etypes    ::= SEQUENCE OF Etype
-
-Err-get-supported-etypes    ::= NULL
-
-END
-
-7 Descriptions of each protocol requests and responses
-
-   This section describes the semantics of each operation request and
-   response defined in the ASN.1 module in section 6.
-
-
-Trostle et. al.							[Page 14]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-   Requests and responses consist of an outer structure ("Request," 
-   "Response" and "Error-Response") containing fields common to all
-   requests/responses, and an inner structure for fields that are
-   specific to each operation's requests/responses.
-
-   Specifically, the outer Request structure has a field for passing a
-   client's spoken (read) languages to the server.  It also has two
-   optional fields for identifying the operation's target principal's
-   name and realm (if not sent then the server MUST use the client
-   principal name and realm from the AP exchange as the target).
-
-   The Response and Error PDU' outer structures include a field
-   indicating the language that the server has chosen for localization
-   of text intended to be displayed to users.
-
-   All three PDUs, "Request," "Response," and "Error-Response" include a
-   protocol version number and the two responses include an optional
-   field through which the server can indicate which language, from the
-   client's list, the server can "speak."
-
-7.1 Null Request
-
-   The null request is intended for use with TCP; its purpose is similar
-   to RPC null procedures and is akin to a "ping" operation.
-
-7.2 Change Password
-
-   The change password request has two fields: old-pw (old password -
-   required) and new-pw (new password - optional).  The server MUST
-   validate the old password and MUST check the quality of the new
-   password, if sent, according to the password policy associated with
-   the client's principal before accepting the request.  If the client
-   does not specify a new password the server MUST either generate one
-   and return it in the response or reject the request with
-   wont-generate-new-pw as the Err-change-pw message's error code.
-
-   If the server rejects a client's proposed new password it SHOULD
-   include a description of the password quality policy in effect for
-   the target principal and/or an explanation of what was wrong with the
-   proposed password in the help-text field of the Err-change-pw
-   message.  Additionally, servers MAY include a randomly generated, but
-   preferably user-friendly password in the suggested-new-pw field of
-   Err-change-pw messages when the client's proposed new password
-   violates the target principal's password quality policy; of course,
-   any such suggested new password MUST pass the target principal's
-   password quality policy.
-
-   Clients MAY specify key enctypes to set with new passwords, but
-   generally SHOULD NOT do so.  If a client requests specific enctypes
-   then the server MUST NOT create keys from the new password of any
-   enctype other than those requested by the client.
-
-   Servers MAY indicate the enctypes of the keys created with new
-
-Trostle et. al.							[Page 15]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-   passwords, but SHOULD NOT do so unless the client requested specific
-   enctypes - in which case the server MUST include the new key enctypes
-   in the change password response.
-
-7.3 Set Keys Requests
-
-   The set keys request consists of a sequence of key enctypes and an
-   optional OCTET STRING of client-provided entropy.
-
-   The server generates keys of the requested enctypes and returns them.
-   The server MAY utilize some, all or none of the client-provided
-   entropy, if any, to generate the keys, but the server SHOULD input
-   some entropy in the process.
-
-   The server SHOULD also include a list of the target principal's
-   aliases, if there are any.
-
-7.5 The Get Policy Request
-   
-   It is common for sites to set policies with respect to password
-   quality.  It is beyond the scope of this document to describe such
-   policies.  However, it is reasonable for password policies to have
-   names and as such for this protocol to associate named password
-   quality policies with principals.  It may also be reasonable for
-   users to learn of their password quality policies.
-
-   The protocol therefore provides an operation for retrieving the name
-   and/or description of the password policy that applies to the target
-   principal name.
-
-   Management of password quality policies' actual content is beyond the
-   scope of this protocol.
-
-7.6 The Get Aliases Request
-   
-   This request allows a client to obtain a list of aliases associated
-   with a principal so that the client can properly configure the
-   principal's "keytab."
-
-   Principal aliases are principal names for which the KDC will issue
-   tickets (with the alias being either the client or target principal
-   name of such tickets) using the same key as the "canonical" principal
-   name, but without canonicalizing the aliased names in KDC exchanges.
-
-7.7 The Get Supported Enctypes Request
-
-   This request allows a client to learn of the target principal's
-   realm's supported enctypes.
-
-
-8 IANA Considerations
-
-   ...
-
-Trostle et. al.							[Page 16]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-
-9 Security Considerations
-   
-   Implementors and site administrators should note that the redundancy
-   of UTF-8 encodings varies by Unicode codepoint used.  Password
-   quality policies should, therefore, take this into account when
-   estimating the amount of redundancy and entropy in a proposed new
-   password.  [?? It's late at night - I think this is correct.]
-
-   Kerberos set/change password/key protocol major version negotiation
-   cannot be done securely.  A downgrade attack is possible against
-   clients that attempt to negotiate the protocol major version to use
-   with a server.  It is not clear at this time that the attacker would
-   gain much from such a downgrade attack other than denial of service
-   (DoS) by forcing the client to use a protocol version which does not
-   support some feature needed by the client (Kerberos V in general is
-   subject to a variety of DoS attacks anyways [RFC1510]).
-
-   [More text needed]
-
-10 Description of TLV Encoding of Sample Subsets of the Protocol
-
-  This section provides example descriptions of the TLV DER encodings of
-  some requests and responses.  This section is not intended to be
-  authoritative and implementors are encouraged to base their
-  implementations on the ASN.1 syntax given in section 6.  These TLV
-  descriptions are given here in the interest of promoting
-  implementation of this protocol even by implementors who do not have
-  access to ASN.1 development tools.
-
-  Tags are described as T(<tag>) where <tag> is a letter denoting the
-  tag type (u for UNIVERSAL, a for APPLICATION, c for CONTEXT and p for
-  PRIVATE) and a number or universal type name.
-
-  Lengths and values are described as L{<value>}, where <value> is a
-  description of the encoding of the value, except for scalar UNIVERSAL
-  types, where <value> shall be '<' description of value '>'.
-
-  Optional fields are enclosed in square brackets ('[' and ']').
-
-  Repetition is denoted by ellipsis ("...").
-
-  Extensibility is denoted by "[...]".
-
-  Comments are introduced by "--" as in ASN.1
-
-10.1 TLV encoding of the Null request and response
-
-   -- Null Request
-   -- Outer application tag
-   T(a0)L{T(uSEQUENCE)L{
-     -- "preamble"
-     -- pvno-major == 2 so it is left out
-
-Trostle et. al.							[Page 17]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-     -- pvno-minor == 0 so it is left out
-     -- optional languages list
-     [T(c2)L{
-       T(uSEQUENCE)L{
-         T(uUTF8String)L{<language tag>}
-         ...
-       }
-     }]
-     -- optional targ-name
-     [T(c3)L{
-       Tc(uSEQUENCE)L{
-	 -- name-type
-         T(c0)L{T(uINTEGER)L{<name-type>}}
-	 -- name-string
-	 T(c1)L{
-	   T(uSEQUENCE)L{
-	     [T(uUTF8String)L{<component name>}]
-	     ...
-	   }
-	 }
-       }
-     }]
-     -- optional targ-realm
-     [T(c4)L{T(uUTF8String)L{<realm name>}}]
-     -- end of preamble
-
-     -- operation choice tag
-     T(c5)L{
-       -- null CHOICE (this tag indicates the CHOICE taken; replace this
-       -- TLV with the TLV for any operation to get the Request encoding
-       -- of that operation)
-       T(c0)L{
-	 -- Req-null (this is the encoding of the value of the CHOICE
-	 -- taken); NULL has no LV part.
-	 T(uNULL)
-       }
-     }
-     -- extensions
-     [...]
-   }}
-
-   -- Null Response
-   -- Outer application tag
-   T(a1)L{T(uSEQUENCE)L{
-     -- "preamble"
-     -- pvno-major == 2 so it is left out
-     -- pvno-minor == 0 so it is left out
-     -- optional language
-     [T(c1)L{T(uUTF8String)L{<language tag>}}]
-     -- end preamble
-     -- operation choice tag
-     T(c2)L{
-       -- null CHOICE
-
-Trostle et. al.							[Page 18]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-       T(c0)L{
-         T(uNULL)
-       }
-     }
-   }}
-
-10.2 TLV encoding of Error-Response
-
-   -- Error Response
-   -- Outer application tag
-   T(a1)L{T(uSEQUENCE)L{
-     -- "preamble"
-     -- pvno-major == 2 so it is left out
-     -- pvno-minor == 0 so it is left out
-     -- optional language
-     [T(c2)L{T(uUTF8String)L{<language tag>}}]
-     -- end preamble
-     -- error code
-     T(c3)L{T(uENUM)L{<error code}}
-     T(c4)L{T(uUTF8String)L{<error text}}
-     -- optional CHOICE
-     T(c5)L{
-       -- CHOICE TLV goes here
-       T(c<choice taken>)L{<value of CHOICE taken>}
-     }
-     -- extensions
-     [...]
-   }}
-
-10.3 TLV encoding of the change password requests and responses
-
-   -- Req-change-pw
-     -- choice tag
-     T(c1)L{
-       T(uSEQUENCE)L{
-	 -- old password
-	 T(c0)L{T(uUTF8String)L{<password string>}}
-	 -- new password (optional; if missing server must generate it)
-	 [T(c1)L{T(uUTF8String)L{<password string>}}]
-	 -- extensions
-	 [...]
-       }
-     }
-
-   -- Rep-change-pw
-     -- choice tag
-     T(c1)L{
-       T(uSEQUENCE)L{
-	 -- optional informational text
-	 [T(c0)L{T(uUTF8String)L{<text>}}]
-	 -- new password (optional; see section 6)
-	 [T(c1)L{T(uUTF8String)L{<new password>}}]
-	 -- extensions
-
-Trostle et. al.							[Page 19]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-	 [...]
-       }
-     }
-
-   -- Err-change-pw
-     -- choice tag
-     T(c1)L{
-       T(uSEQUENCE)L{
-	 -- optional help text
-	 [T(c0)L{T(uUTF8String)L{<text>}}]
-	 -- error code
-	 T(c1)L{T(uENUM)L{<error code>}}]
-	 -- extensions
-	 [...]
-       }
-     }
-
-10.4 TLV encoding of Change Keys requests and responses
-
-   -- Req-set-keys
-     -- choice tag
-     T(c1)L{
-       T(uSEQUENCE)L{
-	 -- new key enctypes
-	 T(c0)L{T(uSEQUENCE)L{
-	   T(uINTEGER)L{<etype integer>},
-	   ...
-	 }}
-	 -- optional entropy
-	 [T(c1)L{T(uOCTET STRING)L{<entropy>}}]
-	 -- extensions
-	 [...]
-       }
-     }
-
-   -- Rep-set-keys
-     -- choice tag
-     T(c1)L{
-       T(uSEQUENCE)L{
-	 -- optional informational text
-	 [T(c0)L{T(uUTF8String)L{<text>}}]
-	 -- new kvno
-	 T(c1)L{T(uINTEGER)L{<new kvno>}}
-	 -- new keys
-	 T(c2)L{T(uSEQUENCE)L{
-	   -- first key
-	   T(uSEQUENCE)L{
-	     T(uINTEGER)L{<etype>}
-	     T(uOCTET STRING)L{<key>}
-	     -- extensions to Key
-	     [...]
-	   }
-	   -- additional keys, if any
-
-Trostle et. al.							[Page 20]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-	   ...
-	 }}
-	 -- optional aliases
-	 [T(c3)L{T(uSEQUENCE)L{
-	   -- first alias
-	   T(uSEQUENCE)L{
-	     -- principal name
-	     T(uSEQUENCE)L{
-	       T(uUTF8String)L{<component1>},
-	       -- components 2..N, if any
-	       ...
-	     }
-	     T(uUTF8String)L{<realm name>}
-	     -- extensions
-	     [...]
-	   }
-	   -- additional aliases, if any
-	   ...
-	 }}]
-	 -- extensions
-	 [...]
-       }
-     }
-
-   -- Err-set-keys
-     -- choice tag
-     T(c1)L{
-       T(uSEQUENCE)L{
-	 -- optional help text
-	 [T(c0)L{T(uUTF8String)L{<text>}}]
-	 -- KDC supported enctypes
-	 [T(c1)L{T(uSEQUENCE)L{
-	   T(uINTEGER)L{<etype integer>},
-	   ...
-	 }}]
-	 -- error code
-	 T(c2)L{T(uENUM)L{<error code>}}]
-	 -- extensions
-	 [...]
-       }
-     }
-
-11 Acknowledgements
-   
-   The authors would like to thank Sam Hartman, Paul W. Nelson and
-   Marcus Watts for their assistance.
-
-   The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony
-   Andrea, Paul W. Nelson, Marcus Watts and other participants from the
-   IETF Kerberos Working Group for their input to the document.
-
-12 References
-
-
-Trostle et. al.							[Page 21]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-12.1 Normative References
-
-   [RFC2026]
-      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
-      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
-      Practice.
-
-   [RFC2119]
-      S. Bradner, RFC2119 (BCP14):  "Key words for use in RFCs to
-      Indicate Requirement Levels," March 1997, Status: Best Current
-      Practice.
-
-   [X680]
-      Abstract Syntax Notation One (ASN.1): Specification of Basic
-      Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
-      International Standard 8824-1:1998.
-      http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf
-
-   [X690]
-      ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
-      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
-      (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
-      Standard 8825-1:1998.
-      http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf
-
-   [RFC1510]
-      J. Kohl and  B. C. Neuman, RFC1510: "The Kerberos Network
-      Authentication Service (v5)," September 1993, Status: Proposed
-      Standard.
-
-   [clarifications]
-      RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
-      kerberos-clarifications.
-
-   [k5stringprep]
-      RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
-      utf8-profile.
-
-   [RFC3066]
-      H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of
-      Languages," January 2001, Obsoletes RFC1766, Status: Best Current
-      Practice.
-
-   [KPASSWDv1]
-      (Reference needed!)
-
-12.1 Informative References
-
-   [RFC3244]
-      M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000
-      Kerberos Change Password and Set Password Protocols," February
-      2002, Status: Informational.
-
-
-Trostle et. al.							[Page 22]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-13 Authors' Addresses
-
-      Jonathan Trostle
-      Cisco Systems
-      170 W. Tasman Dr.
-      San Jose, CA 95134
-      Email: jtrostle@cisco.com
-
-      Mike Swift
-      University of Washington
-      Seattle, WA
-      Email: mikesw@cs.washington.edu
-
-      John Brezak
-      Microsoft
-      1 Microsoft Way
-      Redmond, WA 98052
-      Email: jbrezak@microsoft.com
-
-      Bill Gossman
-      Cisco Systems
-      500 108th Ave. NE, Suite 500
-      Bellevue, WA 98004
-      Email: bgossman@cisco.com
-
-      Nicolas Williams
-      Sun Microsystems
-      5300 Riata Trace Ct
-      Austin, TX 78727
-      Email: nicolas.williams@sun.com
-
-14 Notes to the RFC Editor
-
-   This document has two KRB WG drafts as normative references and
-   cannot progress until those drafts progress, but no other draft
-   depends on this one.
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-
-Trostle et. al.							[Page 23]
-
-DRAFT		Kerberos Set/Change Password v2		Expires November 2003
-
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-02.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-02.txt
deleted file mode 100644
index a25d8096c..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-02.txt
+++ /dev/null
@@ -1,1793 +0,0 @@
-
-Kerberos Working Group                                  Nicolas Williams
-INTERNET-DRAFT                                          Sun Microsystems
-Category: Standards Track                               Jonathan Trostle
-                                                           Cisco Systems
-
-
-
-                Kerberos Set/Change Password: Version 2
-              <draft-ietf-krb-wg-kerberos-set-passwd-02.txt>
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 12, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This document specifies an extensible protocol for setting keys and
-   changing the passwords of Kerberos V principals.
-
-Table of Contents
-
-   1  Introduction
-   2  The Protocol
-   2.1  Transports 
-   2.2  Protocol Framing
-   2.3  Protocol version negotiation
-   2.3.1  Protocol Major Version Negotiation
-   2.3.2  Protocol Minor Version Negotiation
-   2.4  Use of Kerberos V
-
-N. Williams et. al.						[Page 1]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   2.5  Use of ASN.1
-   2.6  Internationalization
-   2.6.1  Normalization Forms for UTF-8 Strings
-   2.6.2  Language Negotiation
-   2.7  Protocol Extensibility
-   2.8  Protocol Subsets
-   3  Protocol Elements
-   3.1  PDUs
-   3.2  Operations
-   3.2.1  Null
-   3.2.2  Change Kerberos Password
-   3.2.3  Set Kerberos Password
-   3.2.4  Set Kerberos Keys
-   3.2.5  Generate Kerberos Keys
-   3.2.6  Get New Keys
-   3.2.7  Commit New Keys
-   3.2.8  Get Password Quality Policy
-   3.2.9  Get Principal Aliases
-   3.2.10  Get Realm's Supported Kerberos V Version and Features
-   4  ASN.1 Module
-   6  IANA Considerations
-   7  Security Considerations
-   8  Acknowledgements
-   9  References
-   9.1  Normative References
-   9.2  Informative References
-   10  Authors' Addresses
-   11  Notes to the RFC Editor
-
-Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-1  Introduction
-
-   Up to this point Kerberos V has lacked a single, standard protocol
-   for changing passwords and keys.  While several vendor-specific
-   protocols exist for changing Kerberos passwords/keys, none are
-   properly internationalized and all are incomplete in one respect or
-   another and none are sufficiently extensible to cope with new
-   features that may be added to Kerberos V at some future time.
-
-   This document defines a protocol that is somewhat backward-compatible
-   with the "kpasswd" protocol defined in [RFC3244] that uses more or
-   less the same protocol framing.
-
-   This new protocol is designed to be extensible and properly
-   internationalized.
-
-2  The Protocol
-
-
-N. Williams et. al.						[Page 2]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   The structure of the protocol is quite similar to that of typical RPC
-   protocols.  Each transaction consists of a data structure specific to
-   an operation which is then wrapped in a data structure which is
-   general to all operations of the protocol.  These data structures are
-   defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they
-   are encoded using the Distinguished Encoding Rules (DER) [X690].
-
-   All protocol data is wrapped KRB-PRIV messages, or, in some cases, a
-   KRB-ERROR, and framed in a header that is backwards compatible with
-   [RFC3244].
-
-2.1  Transports 
-
-   The service supports only connection-oriented transports,
-   specifically TCP, and MUST accept requests on TCP port 464, the same
-   as in [RFC3244].
-
-2.2  Protocol Framing
-
-   Requests and responses are exchanged using the same framing as in
-   [RFC3244], but with the following differences:
-
-    - the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1)
-
-    - the 'AP-REQ length' field of the request can be set to 0x0, in
-      which case the 'AP-REQ' field of the request is excluded
-
-    - the 'KRB-PRIV' field of the request and reply is mutually
-      exclusive with the 'AP-REQ' field of the request
-
-    - the 'AP-REP length' field of the reply can be set to 0x0, in
-      which case the 'AP-REP' field of the reply is excluded
-
-    - all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can
-      be or has been accepted by the server
-
-    - any KRB-ERROR messages are framed and sent in the 'AP-REP' field
-      of the reply
-
-   The initial message from the client MUST carry an AP-REQ and the
-   response to any request bearing an AP-REQ MUST carry an AP-REP or
-   MUST be a KRB-ERROR.
-
-   Subsequent messages exchanged on the same TCP connection MAY involve
-   Kerberos V AP exchanges, but generally the client SHOULD NOT initiate
-   a new AP exchange except when it desires to authenticate as a
-   different principal, when the ticket last used for authentication
-   expires or when the server responds with an error indicating that the
-   client must re-authenticate.
-
-2.3  Protocol Version Negotiation
-
-   There are several major versions of this protocol.  Version 2 also
-
-N. Williams et. al.						[Page 3]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   introduces a notion of protocol minor versions for use in negotiating
-   protocol extensions.  As of this time only one minor version is
-   defined for major version 2: minor version 0, defined herein.
-
-2.3.1  Protocol Major Version Negotiation
-
-   Version 2 clients that also support other versions, such as 0xff80,
-   as in [RFC3244], SHOULD attempt to use version 2 of the protocol
-   first.
-
-   Servers which do not support version 2 of this protocol typically
-   include their preferred version number in the reply and/or may
-   include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a
-   status code of KRB5_KPASSWD_MALFORMED.
-
-   Note that some [RFC3244] server implementations close the TCP
-   connection without returning any other response.  Note also that
-   there is no integrity protection for the major version number in the
-   protocol framing or for any data in a KRB-ERROR.
-
-   As a result change password protocol major version negotiation is
-   subject to downgrade attacks.  Therefore major version negotiation is
-   NOT RECOMMENDED.
-
-   Where the server indicates that it does not support version 2, the
-   client MAY, but SHOULD NOT, unless configured to do so, fall back on
-   another major version of this protocol.
-
-   Version 2 servers MAY respond to non-v2 requests using whatever
-   response is appropriate for the versions used by the clients, but if
-   a server does not do this or know how to do this then it MUST respond
-   with an error framed as in section 2.2, using an AP-REP and KRB-PRIV
-   if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and
-   using a ProtocolErrorCode value of unsupported-major-version.
-
-   It is expected that implementations of as yet unspecified future
-   major versions of this protocol will be required to support version 2
-   integrity protected error replies for properly indicating no support
-   for version 2 of the protocl.  We also hope that no further major
-   versions of this protocol will be needed.
-
-2.3.2  Protocol Minor Version Negotiation
-
-   Version 2 clients are free to use whatever protocol minor version and
-   message extensions are available to them in their initial messages to
-   version 2 servers, provided that the minor versions (other than 0)
-   have been defined through IETF documents.
-
-   Version 2 servers MUST answer with the highest protocol minor version
-   number supported by the server and the client.
-
-   Version 2 clients MUST use the protocol minor version used in a
-   server's reply for any subsequent messages in the same TCP session.
-
-N. Williams et. al.						[Page 4]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-
-   See section 2.7 for further description of the protocol's
-   extensibility and its relation to protocol minor versions and the
-   negotiation thereof.
-
-2.4  Use of Kerberos V and Key Exchange
-
-   This protocol makes use of messages defined in [RFC1510] and
-   [clarifications].  Specifically, AP-REQ, AP-REP, KRB-ERROR and
-   KRB-PRIV.
-
-   All operations are to be performed by the server on behalf of the
-   client principal.
-
-   Clients SHOULD use "kadmin/setpw" as the principal name of the server
-   for all requests except when changing the client principal's own
-   expired password, for which they should use "kadmin/changepw".  The 
-   "kadmin/changepw" service exists to allow KDCs to limit principals
-   with expired passwords to getting initial tickets to the password
-   changing service only and only for changing expired passwords.
-
-   Servers MUST limit clients that used the "kadmin/changepw" service
-   principal name to changing the password of the client principal.
-
-   The client MUST request mutual authentication and the client MUST
-   MUST request the use of sequence numbers.
-
-   Clients SHOULD use INITIAL tickets for requests whose target
-   principal is the client's principal.  Servers SHOULD force the use of
-   INITIAL tickets for such requests and MAY force the use of INITIAL
-   for all others - see section 3.2.
-
-   Servers MUST specify a sub-session key.
-
-   The encrypted part of KRB-PRIVs MUST be encrypted with the server's
-   sub-session key and key usage 20 (client->server) or 21
-   (server->client).
-
-   After each new AP exchange the client and server MUST destroy the
-   session keys, if any, resulting from the previous AP exchange.
-
-2.5  Use of ASN.1
-
-   This protocol's messages are defined in ASN.1, using only features
-   from [X680].  All ASN.1 types defined herein are to be encoded in
-   DER [X690].  A complete ASN.1 module is given in section 4.
-
-   The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
-   KRB-PRIV as described above and/or as e-data in KRB-ERROR messages.
-
-2.6  Internationalization
-
-   This protocol's request PDU carries an optional field indicating the
-
-N. Williams et. al.						[Page 5]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   languages spoken by the client user; the client SHOULD send its list
-   of spoken languages to the server (once per-TCP session).
-
-   The server SHOULD localize all strings intended for display to users
-   to a language in common with the languages spoken by the client user.
-
-   Strings for Kerberos principal and realm names used in this protocol
-   are be constrained as per [clarifications].
-
-2.6.1  Normalization Forms for UTF-8 Strings
-
-   Because Kerberos V [clarifications] restricts principal names, realm
-   names and passwords to IA5String, this protocol uses UTF8String with
-   an extensible constraint to IA5String.
-
-   Future versions of Kerberos may relax this constraint; if so then a
-   minor version of this protocol should relax this constraint
-   accordingly.
-
-2.6.2  Language Negotiation
-
-   The server MUST pick a language from the client's input list or
-   the default language tag (see [RFC3066]) for text in its responses
-   which is meant for the user to read.
-
-   The server SHOULD use a language selection algorithm such that
-   consideration is first given to exact matches between the client's
-   spoken languages and the server's available locales, followed by
-   "fuzzy" matches where only the first sub-tags of the client's
-   language tag list are used for matching against the servers available
-   locales.
-
-   Servers MUST cache the optional language tag lists from prior
-   requests for use with subsequent requests that exclude the language
-   tag list.  Clients MAY expect such server behaviour and send the
-   language tag lists only once per-TCP session.  Clients SHOULD send
-   the server the language tag list at least once.
-
-   When the server has a message catalog for one of the client's spoken
-   languages the server SHOULD localize any text strings intended for
-   display to users.
-
-2.7  Protocol Extensibility
-
-   The protocol is defined in ASN.1 and uses extensibility markers
-   throughout.  As such, the module presented herein can be extended
-   within the framework of [X680].
-
-   Typed holes are not used in this protocol as it is very simple and
-   does not require the ability to deal with abstract data types defined
-   in different layers.  For this reason, the only way to extend this
-   protocol is by extending the ASN.1 module within the framework of the
-   IETF; all future extensions to this protocol have to be defined in
-
-N. Williams et. al.						[Page 6]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   IETF documents unless otherwise specified in a future IETF revision
-   of this protocol.
-
-   A protocol minor version number is used to negotiate use of
-   extensions.  See section 2.3.2 for the minor version negotiation.
-
-   Servers SHOULD ignore unknown additions to the ASN.1 types, in
-   initial requests, where the syntax allows them, except for extensions
-   to the "Op-req" type, which MUST result in an error.
-
-   Servers MUST respond with an error (ProtocolErrorCode value of
-   unsupported-minor-version) to clients that use operations unknown to
-   the server.
-
-2.8  Protocol Subsets
-
-   The structure of the protocol is such that the ASN.1 syntaxes for the
-   various operations supported by the protocol are independent of the
-   each other.  Client and server implementations MAY implement subsets
-   of the overall protocol by removing some alternatives to the Op-req,
-   Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4.
-   
-   For example, it should be possible to have a password-change only
-   client that cannot set principal's keys - and vice versa.
-
-3  Protocol Elements
-
-   The protocol as defined herein supports the following operations
-   relating to the management of Kerberos principal's passwords or keys:
-
-     [NOTE:  New since last version of this I-D.]
-     - get principal's current and preferred string-to-key parameters
-
-     - change password (or enctypes and string-to-key parameters)
-     - set password (administrative)
-     - set new keys
-     - generate new keys
-     - get new, un-committed keys
-     - commit new keys
-     - get password policy name and/or description of principal
-     - list aliases of a principal
-     - list enctypes and version of Kerberos V supported by realm
-
-   The operation for retrieving a list of aliases of a principal is
-   needed where KDCs implement aliasing of principal names and allows
-   clients to properly setup their key databases when principal aliasing
-   is in use.
-
-   Operations such as creation or deletion of principals are outside the
-   scope of this document, and should be performed via other means, such
-   as through directories or other Kerberos administration protocols.
-
-   The individual operations are described in section 3.2.
-
-N. Williams et. al.						[Page 7]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-
-3.1  PDUs
-
-   The types "Request," "Response" and "Error-Response" are the ASN.1
-   module's PDUs.
-
-   The "Request" and "Response" PDUs are always to be sent wrapped in
-   KRB-PRIV messages, except for the "Error-Response" PDU which MUST be
-   sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail,
-   otherwise it MUST be sent wrapped in a KRB-PRIV.
-
-   The ASN.1 syntax for the PDUs is given in section 4.
-
-   Note that the first field of each PDU is the major version of the
-   protocol, defaulted to 2, meaning that it is never included in
-   version 2 exchanges.  Similarly, the second field of each PDU is the
-   minor version, defaulted to 0.
-
-   The request, responses and error PDUs consist of an outer structure
-   ("Request," "Response" and "Error-Response") containing fields common
-   to all requests, responses and errors, respectively, and an inner
-   structure for fields that are specific to each operation's
-   requests/responses.  The inner structure is optional in the case of
-   the Error-Response PDU and need not be included when generic errors
-   occur for which there is a suitable ProtocolErrorCode.
-
-   Specifically, the outer Request structure has a field for passing a
-   client user's spoken (read) languages to the server.  It also has two
-   optional fields for identifying the requested operation's target
-   principal's name and realm (if not sent then the server MUST use the
-   client's principal name and realm as the target).  A boolean field
-   for indicating whether or not the request should be dry-run is also
-   included; dry-runs can be used to test server policies, and servers
-   MUST NOT modify any principals when processing dry-run requests.
-
-   The Response and Error PDUs' outer structures include a field
-   indicating the language that the server has chosen for localization
-   of text intended to be displayed to users; this field is defaulted to
-   "i-default".  This language tag applies to all UTF8 strings in the
-   inner structure (Op-rep and Op-err) that are meant to be displayed to
-   users.
-
-   The protocol error codes are:
-
-      - proto-generic-error
-
-        An operation-specific error ocurred, see the inner Op-error.
-
-      - proto-format-error
-      - proto-unsupported-major-version
-      - proto-unsupported-minor-version
-      - proto-unsupported-operation
-
-
-N. Williams et. al.						[Page 8]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-      - proto-wrong-service-principal
-
-        Use kadmin/setpw for the server's principal name.
-
-      - proto-re-authentication-required
-
-        The server demands that the client re-authenticate through a new
-        AP exchange.
-
-      - proto-initial-ticket-required
-
-        Use of an INITIAL ticket is required for the requested
-        operation.
-
-      - proto-client-and-target-realm-mismatch
-
-        The server requires that the client's principal name and the
-        target principal of the operation share the same realm name.
-
-      - proto-target-principal-unknown
-      - proto-authorization-failed
-
-3.2  Operations
-
-   This section describes the semantics of each operation request and
-   response defined in the ASN.1 module in section 4.
-      
-3.2.1  Null
-
-   NAME
-
-      null - Null or "ping" operation
-
-   DESCRIPTION
-
-      The null request is intended for use with TCP; its purpose is
-      similar to RPC null procedures and is akin to a "ping" operation.
-
-   ERRORS
-
-      None.
-
-3.2.2  Change Kerberos Password
-
-   NAME
-
-      change-pw - Change password operation
-
-   SYNOPSIS
-
-      Req-change-pw(old-pw, [languages], [new-pw],
-                    [commit], [etypes]) ->
-         Rep-change-pw([info-text], [new-pw], [etypes]) |
-
-N. Williams et. al.						[Page 9]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-         Err-change-pw([help-text], error code, [error info])
-
-   DESCRIPTION
-
-      Change a principal's password.
-
-      The change password request has one required, three optional and
-      one defaulted arguments: "old-pw" (required), "languages,"
-      "new-pw", "commit" (defaults to "TRUE") and "etypes",
-      corresponding to the target principal's old password, its
-      preferred languages, its new password, a boolean indicating
-      whether or not to make the new long-term key available for
-      immediate use, and the desired enctypes for the new long-term
-      keys.
-
-      The server MUST validate the old password and MUST check the
-      quality of the new password, if sent, according the password
-      quality policy associated with the target principal.
-
-      If the old and new passwords in the request are the same strings,
-      and the principal is not currently required to change its
-      password, then the server MAY permit the password change as way to
-      change a principal's enctypes and string-to-key parameters.  This
-      feature provides a way to, for example, add enctypes to a
-      principals' password-derived long-term keys without forcing a
-      password change following an upgrade to the KDC that adds support
-      for new enctypes.
-
-      A client MAY request that the server generate a new password by
-      excluding the new password from its request, in which case the
-      server MUST either generate a new password or respond with an
-      error indicating that it does not support this feature.
-
-      Server-generated passwords MUST meet the target principal's
-      password quality policy.  It is RECOMMENDED that server-generated
-      passwords be user-friendly, that is, memorable and that the target
-      principal's preferred languages be taken into account by the
-      password generation alogrithm used by the server.
-
-      Uncommitted password changes are commited using the commit-keys
-      operation.
-
-   RETURN
-
-      Upon successful password changes the server responds with a
-      Rep-change-pw.  The fields of Rep-change-pw are all optional and
-      include:
-
-         - 'info-text' which the server can use to send a message to the
-           user such as "Your new password will expire in 90 days," for
-           example.
-
-         - 'new-pw' which the server MUST include if the client
-
-N. Williams et. al.						[Page 10]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-           requested that the server generate a new password; generated
-           passwords MUST pass the target principal's password quality
-           policy.
-
-         - 'etypes' which the server MAY include to indicate which types
-           of long-term keys it created for the target principal and
-           which the server MUST include if the client specified a set
-           of enctypes in its request.
-
-   ERRORS
-
-      The server may respond to change password requests with protocol
-      or operation errors.  See section 3.1 for a description of
-      protocol error codes.
-
-      All operation errors include an optional 'help-text' field by
-      which the server can describe the error in a human-readable,
-      localizaed string.
-
-      Change password error codes include:
-
-         - generic-error
-
-         - old-pw-incorrect
-
-         - wont-generate-new-pw
-
-           The server will not generate a new password for this
-           principal or does not support password generation in general.
-
-         - new-pw-rejected-generic
-
-           The client's proposed new password failed the target
-           principal's password quality policy.
-
-           The server MUST include a description of the password quality
-           policy or aspect of it that the client's proposed new
-           password failed to meet.
-
-           The server MAY generate and send a new password that the
-           client can then use as a new password and which is guaranteed
-           to pass the target principal's current password quality
-           policy.
-
-           The server MAY include a set of policy error code hints.
-
-         - etype-not-supported
-
-           The client requested an enctype that the KDC does not
-           support.
-
-3.2.3  Set Kerberos Password
-
-
-N. Williams et. al.						[Page 11]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   NAME
-
-      set-pw - Set password operation
-
-   SYNOPSIS
-
-      Req-set-pw([languages], [new-pw], [commit], [etypes]) ->
-         Rep-set-pw([info-text], [new-pw], [etypes]) |
-         Err-set-pw([help-text], error code, [error info])
-
-   DESCRIPTION
-
-      Administratively set a principal's password.
-
-      The set password request has three optional and one defaulted
-      arguments: "languages", "new-pw," "commit" (defaulted to "TRUE")
-      and "etypes", corresponding to the target principal's preferred
-      languages, new password, a boolean indicating whether or not to
-      make the new long-term key available for immediate use, and the
-      desired enctypes for the new long-term keys.
-
-      The server MUST check the quality of the new password, if sent,
-      according the password quality policy associated with the target
-      principal.
-
-      The server SHOULD require that the client use the change-pw
-      operation instead of set-pw when the client principal and the
-      target principal are the same.
-
-      A client MAY request that the server generate a new password by
-      excluding the new password from its request, in which case the
-      server MUST either generate a new password or respond with an
-      error indicating that it does not support this feature.
-
-      Server-generated passwords MUST meet the target principal's
-      password quality policy.  It is RECOMMENDED that server-generated
-      passwords be user-friendly, that is, memorable and that the target
-      principal's preferred languages be taken into account by the
-      password generation alogrithm used by the server.
-
-   RETURN
-
-      Upon successfully setting a password the server responds with a
-      Rep-set-pw.  The fields of Rep-set-pw are all optional and
-      include:
-
-         - 'info-text' which the server can use to send a message to the
-           user such as "Your new password will expire in 90 days," for
-           example.
-
-         - 'new-pw' which the server MUST include if the client
-           requested that the server generate a new password; generated
-           passwords MUST pass the target principal's password quality
-
-N. Williams et. al.						[Page 12]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-           policy.
-
-         - 'etypes' which the server MAY include to indicate which types
-           of long-term keys it created for the target principal and
-           which the server MUST include if the client specified a set
-           of enctypes in its request.
-
-   ERRORS
-
-      The server may respond to set password requests with protocol or
-      operation errors.  See section XYZ for a description of protocol
-      error codes.
-
-      All operation errors include an optional 'help-text' field by
-      which the server can describe the error in a human-readable,
-      localizaed string.
-
-      Set password error codes include:
-
-         - generic-error
-
-         - use-change-pw
-
-           The server demands that the client use the change-pw
-           operation for the target principal of the set-pw request.
-
-         - wont-generate-new-pw
-
-           The server will not generate a new password for this
-           principal or does not support password generation in general.
-
-         - new-pw-rejected-generic
-
-           The client's proposed new password failed the target
-           principal's password quality policy.
-
-           The server MUST include a description of the password quality
-           policy or aspect of it that the client's proposed new
-           password failed to meet.
-
-           The server MAY generate and send a new password that the
-           client can then use as a new password and which is guaranteed
-           to pass the target principal's current password quality
-           policy.
-
-           The server MAY include a set of policy error code hints.
-
-         - etype-not-supported
-
-           The client requested an enctype that the KDC does not
-           support.
-
-3.2.4  Set Kerberos Keys
-
-N. Williams et. al.						[Page 13]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-
-   NAME
-
-      set-keys
-
-   SYNOPSIS
-
-      Req-set-keys(new-keys, commit?, [isupport]) ->
-         Rep-set-keys([info-text], kvno, aliases, [isupport])
-
-   DESCRIPTION
-
-      The set-keys request consists of two required fields and one
-      optional field: "new-keys", "commit" (a boolean field - see below)
-      and "isupport", an optional field for indicating to the KDC what
-      Kerberos V features are supported by the target principal.
-
-      When "commit" is true the KDC makes the new keys available for
-      issueing tickets encrypted in them immediately.  Otherwise the
-      client MUST follow up with a commit-keys request to make the keys
-      available.  This feature is useful for changing keys shared by
-      multiple hosts, in clustered services, for example, in an atomic
-      manner; see section 3.2.6 and 3.2.7.
-
-      If a principal has keys are awaiting commitment when a new
-      set-keys request for that principal s made then the KDC MUST
-      overwrite the deferred keys.
-
-   RETURN
-
-      For successful set-keys operations the server returns:
-
-         - Informational text, optional.
-
-         - The new kvno for the target principal.
-
-         - A list of aliases of the target principal known to the KDC
-           (optional).
-
-         - The set of Kerberos V features supported by the KDC
-           (optional).
-
-   ERRORS
-
-      The server may respond with the following errors:
-
-         - generic
-         - deferred-commit-no-support
-         - etype-no-support
-
-3.2.5  Generate Kerberos Keys
-
-   NAME
-
-N. Williams et. al.						[Page 14]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-
-      gen-keys
-
-   SYNOPSIS
-
-      Req-gen-keys(etypes, [entropy], commit?, [isupport]) ->
-         Rep-set-keys([info-text], key, kvno, aliases, [isupport])
-
-   DESCRIPTION
-
-      The gen-keys is similar to the set-keys request (see section
-      3.2.4) but differs in that the server generates keys of
-      client-requested enctypes, rather than the client providing
-      specific keys.
-
-      The gen-keys request consists of two required fields and two
-      optional fields: "etypes" (the enctypes of the new keys),
-      "entropy", "commit" and "isupport" (see section 3.2.4).
-
-      If a principal has keys are awaiting commitment when a new
-      set-keys request for that principal s made then the KDC MUST
-      overwrite the deferred keys.
-
-   RETURN
-
-      For successful set-keys operations the server returns:
-
-         - Informational text, optional.
-
-         - The new kvno for the target principal.
-
-         - The new key (only one is needed).
-
-         - A list of aliases of the target principal known to the KDC
-           (optional).
-
-         - The set of Kerberos V features supported by the KDC
-           (optional).
-
-   ERRORS
-
-      The server may respond with the following errors:
-
-         - generic
-         - deferred-commit-no-support
-         - etype-no-support
-
-3.2.6  Get New Keys
-
-   NAME
-
-      get-keys
-
-
-N. Williams et. al.						[Page 15]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   SYNOPSIS
-
-      Req-get-keys(kvno) ->
-         Rep-get-keys([info-text], keys, aliases, [isupport]) |
-         Err-get-keys([help-text], error code, [error info])
-
-   DESCRIPTION
-
-      This request allows a client to get the keys set or generated in a
-      previous set-keys or gen-keys request with deferred commitment..
-
-   RETURN
-
-      If the target principal and kvno correspond to uncommitted keys
-      the server MUST respond with the actual keys that would be set by
-      a subsequent commit-keys request.  Otherwise the server MUST
-      respond with an error (meaning that this operation cannot be used
-      to extract keys from the KDC that may be in use).
-
-   ERRORS
-
-         - generic
-         - kvno-committed
-         - no-such-kvno
-
-3.2.7  Commit New Keys
-
-   NAME
-
-      commit-keys
-
-   SYNOPSIS
-
-      Req-commit-keys(kvno) ->
-         Rep-commit-keys() |
-         Err-commit-keys([help-text], error code, [error info])
-
-   DESCRIPTION
-
-      The commit-keys operation allows a client to bring a principal's
-      new keys into use at the KDC.
-
-      Clients should make a commit-keys request corresponding to a
-      deferred commitment set-keys/gen-keys operation as soon as the
-      local key database for the target principal is updated.
-
-      The target principal name and the kvno MUST match those from a
-      prior set-keys or gen-keys operation.
-
-      Servers MAY expire delayed key commitments at will.  Servers
-      SHOULD expire uncommitted new keys after a reasonable amount of
-      time (600 seconds is RECOMMENDED).
-
-
-N. Williams et. al.						[Page 16]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-      Servers MUST respond to new set-keys requests for principals with
-      pending, uncommitted new keys by expiring the uncommitted new keys
-      and proceeding as if there had been no expired new keys.
-
-   ERRORS
-
-      - generic
-      - op-kvno-expired
-      - op-kvno-unknown
-      - new-keys-conflict (A set-keys or gen-keys request succeeded
-                           subsequent to the request that matches this
-                           {principal, kvno} tuple.)
-
-3.2.8  Get Password Quality Policy
-   
-   NAME
-
-      get-pw-policy
-
-   SYNOPSIS
-
-      Req-get-pw-policy() ->
-         Rep-get-pw-policy([policy name], [policy description])
-
-   DESCRIPTION
-
-      Returns a description of the target principal's associated
-      password quality policy, if any, as a list of localized
-      UTF8String values.
-
-      Clients can use this operation in conjunction with the change-pw
-      operation to obtain text that can be displayed to the user before
-      the user actually enters a new password.
-
-      It is common for sites to set policies with respect to password
-      quality.  It is beyond the scope of this document to describe such
-      policies.  Management of password quality policies' actual content
-      is also beyond the scope of this protocol.
-
-   ERRORS
-
-      No operation errors are defined.
-
-
-3.2.9  Get Principal Aliases
-   
-   NAME
-
-      get-print-aliases
-
-   SYNOPSIS
-
-      Req-get-princ-aliases() ->
-
-N. Williams et. al.						[Page 17]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-         Rep-get-princ-aliases(aliases)
-
-   DESCRIPTION
-
-      Returns a list of aliases of the target principal.
-
-   ERRORS
-
-      No operation-specific errors.
-
-3.2.10  Get Realm's Supported Kerberos V Version and Features
-   
-   NAME
-
-      get-realm-krb5-support
-
-   SYNOPSIS
-
-      Req-get-realm-krb5-support() ->
-         Rep-get-realm-krb5-support(isupport)
-
-   DESCRIPTION
-
-      Returns set of Kerberos V features support by the target
-      principal's realm's KDCs.
-
-   ERRORS
-
-      No operation-specific errors.
-
-3.2.11  Retrieve Principal's S2K Params and Preferred Params
-   
-   NAME
-
-      get-s2kparams
-
-   SYNOPSIS
-
-      Req-get-s2kparams() ->
-         Rep-get-s2kparams([princ-s2kparams], [preferred-s2kparams])
-
-   DESCRIPTION
-
-      Returns the string2key parameters for the principal's current
-      password-derived long-term keys, if any, and the parameters that
-      the realm would prefer, if they differ from the former.
-
-      This operation is intended for use with the change-pw() operation.
-      When surprised by a KDC's PA-ETYPE-INFO2 a client SHOULD check if
-      the principal's long-term secret keys' string2key parameters (and
-      enctype list) should be changed and, if so, change them.
-
-      If the 'princ-s2kparams' return value is missing then the
-
-N. Williams et. al.						[Page 18]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-      principal does not have a password-derived long-term key.
-
-      The 'preferred-s2kparams' MUST be excluded if the principal's
-      string2key parameters satisfy the realm's policy.
-
-   ERRORS
-
-      No operation-specific errors.
-
-3.3  Principal Aliases
-
-   Applications that use Kerberos often have to derive acceptor
-   principal names from hostnames entered by users.  Such hostnames may
-   be aliases, they may be fully qualified, partially qualified or not
-   qualified at all.  Some implementations have resorted to deriving
-   principal names from such hostnames by utilizing the names services
-   to canonicalize the hostname first; such practices are not secure
-   unless the name service are secure, which often aren't.
-
-   One method for securely deriving principal names from hostnames is to
-   alias principals at the KDC such that the KDC will issue tickets for
-   principal names which are aliases of others.  It is helpful for
-   principals to know what are their aliases as known by the KDCs.
-
-   Note that changing a principal's aliases is out of scope for this
-   protocol.
-
-3.4  Kerberos V Feature Negotiation
-
-   Principals and realms' KDCs may need to know about additional
-   Kerberos V features and extensions that they each support.  Several
-   operations (see above) provide a way for clients and servers to
-   exchange such infomration, in the form of lists of types supported
-   for the various typed holes used in Kerberos V.
-
-4  ASN.1 Module
-
-   DEFINITIONS EXPLICIT TAGS ::= BEGIN
-   -- 
-   -- Note:  EXPLICIT tagging is in use by default throughout this
-   --        module.
-
-   -- From [clarifications] with modifications
-   PrincipalName            ::= SEQUENCE {
-        name-string [1] SEQUENCE OF UTF8String (IA5String, ...)
-   }
-   Realm                    ::= UTF8String (IA5String, ...)
-   Salt                     ::= UTF8String (IA5String, ...)
-   Password                 ::= UTF8String (IA5String, ...)
-
-   -- NOTE WELL: Principal and realm names MUST be constrained by the
-   --            specification of the version of Kerberos V used by the
-   --            client.
-
-N. Williams et. al.						[Page 19]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   -- 
-   -- [Perhaps PrincipalName should be a SEQUENCE of an optional name
-   --  type and a UTF8String, for simplicity.]
-
-   -- From [clarifications]
-   Int32            ::= INTEGER (-2147483648..2147483647)
-   UInt32           ::= INTEGER (0..4294967295)
-
-   -- Based on [clarifications]
-   Etype            ::= Int32
-   Etype-Info-Entry ::= SEQUENCE {
-        etype           [0] Etype,
-        salt            [1] Salt OPTIONAL,
-        s2kparams       [2] OCTET STRING OPTIONAL,
-        ...
-   }
-   Key              ::= SEQUENCE {
-        enc-type        [0] Etype,        -- from Kerberos
-        key             [1] OCTET STRING,
-        ...
-   }
-
-   Language-Tag     ::= UTF8String -- Constrained by [RFC3066]
-
-   -- Empty, extensible SEQUENCEs are legal ASN.1
-   Extensible-NULL  ::= SEQUENCE {
-        ...
-   }
-
-   -- Kerberos clients negotiate some parameters relating to their peers
-   -- indirectly through the KDC.  Today this is true of ticket session
-   -- key enctypes, but in the future this indirect negotiation may also
-   -- occur with respect to the minor version of Kerberos V to be used
-   -- between clients and servers.  Additionally, KDCs may need to know
-   -- what authorization-data types are supported by service principals,
-   -- both, for compatibility with legacy software and for optimization.
-   --
-   -- Thesefore it is important for KDCs to know what features of
-   -- Kerberos V each service principal supports.
-   --
-   -- In version 2.0 of this protocol the clients and servers may notify
-   -- each other of their support for:
-   --
-   --  - enctypes
-   --  - authorization data types
-   --  - transited encoding data types
-   --
-   -- All authorization-data types defined in [clarifications] are
-   -- assumed to be supported if the minor version is 1 and do not need
-   -- to be included in the ad-type list.
-   --
-   -- Int32 is used for enctype and transited encoding data type
-   -- identifiers.
-
-N. Williams et. al.						[Page 20]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   --
-   -- An extensible CHOICE of Int32 is used for authorization data
-   -- types.
-
-   KerberosV-TR-ID             ::= Int32
-
-   KerberosV-AD-ID             ::= CHOICE {
-        ad-int                [0] Int32,
-        ...
-   }
-
-   KerberosVSupportNego        ::= SEQUENCE {
-        enc-types       [0] SEQUENCE OF Etype,
-        ad-types        [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL,
-                                    -- authorization data types
-        tr-enc-types    [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL,
-                                    -- transited encoding types
-        ...
-   }
-
-   Request                     ::= [APPLICATION 0] SEQUENCE {
-        pvno-minor      [0] INTEGER DEFAULT 0,
-        languages       [1] SEQUENCE OF Language-Tag OPTIONAL,
-                -- Should be defaulted to the SEQUENCE of "i-default"
-        targ-name       [2] PrincipalName OPTIONAL,
-        targ-realm      [3] Realm OPTIONAL,
-                -- If targ-name/realm are missing then the request
-                -- applies to the principal of the client
-        dry-run         [4] BOOLEAN DEFAULT FALSE,
-        operation       [5] Op-req,
-        ...
-   }
-
-   Response                    ::= [APPLICATION 1] SEQUENCE {
-        pvno-minor      [0] INTEGER DEFAULT 0,
-        language        [1] Language-Tag DEFAULT "i-default",
-        result          [2] Op-rep,
-        ...
-   }
-
-   Error-Response              ::= [APPLICATION 2] SEQUENCE {
-        pvno-minor      [0] INTEGER DEFAULT 0,
-        language        [1] Language-Tag DEFAULT "i-default",
-        error-code      [2] ProtocolErrorCode,
-        help-text       [3] UTF8String OPTIONAL,
-        op-error        [4] Op-err OPTIONAL,
-        ...
-   }
-
-   Op-req                      ::= CHOICE {
-        null                     [0] Req-null,
-        change-pw                [1] Req-change-pw,
-        set-pw                   [2] Req-set-pw,
-
-N. Williams et. al.						[Page 21]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-        set-keys                 [3] Req-set-keys,
-        gen-keys                 [4] Req-gen-keys,
-        get-keys                 [5] Req-get-keys,
-        commit-keys              [6] Req-commit-keys,
-        get-pw-policy            [7] Req-get-pw-policy,
-        get-princ-aliases        [8] Req-get-princ-aliases,
-        get-realm-krb5-support   [9] Req-get-realm-krb5-support,
-        get-s2kparams            [10] Req-get-s2kparams,
-        ...
-   }
-
-   Op-rep                     ::= CHOICE {
-        null                    [0] Rep-null,
-        change-pw               [1] Rep-change-pw,
-        set-pw                  [2] Rep-set-pw,
-        set-keys                [3] Rep-set-keys,
-        gen-keys                [4] Req-gen-keys,
-        get-keys                [5] Req-get-keys,
-        commit-keys             [6] Rep-commit-keys,
-        get-pw-policy           [7] Rep-get-pw-policy,
-        get-princ-aliases       [8] Rep-get-princ-aliases,
-        get-realm-krb5-support  [9] Rep-get-realm-krb5-support,
-        get-s2kparams           [10] Rep-get-s2kparams,
-        ...
-   }
-
-   Op-err        ::= CHOICE {
-        null                    [0] Err-null,
-        change-pw               [1] Err-change-pw,
-        set-pw                  [2] Err-set-pw,
-        set-keys                [3] Err-set-keys,
-        gen-keys                [4] Err-gen-keys,
-        get-keys                [5] Err-get-keys,
-        commit-keys             [6] Err-commit-keys,
-        get-pw-policy           [7] Err-get-pw-policy,
-        get-princ-aliases       [8] Err-get-princ-aliases,
-        get-realm-krb5-support  [9] Err-get-realm-krb5-support,
-        get-s2kparams           [10] Err-get-s2kparams,
-        ...
-   }
-
-   ProtocolErrorCode           ::= ENUM {
-        proto-format-error,
-        proto-unsupported-major-version,
-        proto-unsupported-minor-version,
-        proto-unsupported-operation,      -- Request CHOICE tag unknown
-        proto-generic-see-op-error,       -- See Op-error
-        proto-wrong-service-principal,    -- Use kadmin/setpw
-        proto-re-authentication-required,
-        proto-initial-ticket-required,
-        proto-client-and-target-realm-mismatch,
-        proto-target-principal-unknown,
-        proto-authorization-failed,
-
-N. Williams et. al.						[Page 22]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-        proto-dry-run-not-permitted,
-        ...
-   }
-
-   -- These codes are hints for clients, primarily for when they are
-   -- used for changing the passwords of automated principals; error
-   -- replies carry password quality policy help text that is more
-   -- appropriate for clients to display to users.
-   PW-Quality-Codes        ::= ENUM {
-        pwq-generic,
-        pwq-too-soon,
-        pwq-repeated,
-        pwq-too-short,
-        pwq-dictionary-words,
-        pwq-prohibited-codepoints,
-        pwq-need-more-char-classes,
-        ...
-   }
-
-   --
-   -- Requests and responses
-   --
-
-   -- NULL request, much like ONC RPC's NULL procedure - NOT extensible
-   Req-null    ::= NULL
-
-   Rep-null    ::= NULL
-
-   Err-null    ::= NULL
-
-   -- Change password
-   Req-change-pw        ::= SEQUENCE {
-        old-pw            [0] Password,
-        new-pw            [1] Password OPTIONAL,
-        commit            [2] BOOLEAN DEFAULT TRUE,
-        etypes            [3] SEQUENCE (1..) OF Etype OPTIONAL,
-        ...
-   }
-
-   Rep-change-pw        ::= SEQUENCE {
-        info-text         [0] UTF8String OPTIONAL,
-        new-pw            [1] Password OPTIONAL,
-                            -- generated by the server if present
-                            -- (and requested by the client)
-        etypes            [2] SEQUENCE (1..) OF Etype OPTIONAL,
-        ...
-   }
-
-   Err-change-pw        ::= SEQUENCE {
-        help-text         [0] UTF8String OPTIONAL,
-        error             [1] CHOICE {
-            op-generic-error           [0] Extensible-NULL,
-            op-old-pw-incorrect        [1] Extensible-NULL,
-
-N. Williams et. al.						[Page 23]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-            op-wont-generate-new-pw    [2] Extensible-NULL,
-            op-new-pw-rejected-generic [3] SEQUENCE {
-                    policy                  [1] SEQUENCE OF UTF8String,
-                    suggested-pw            [2] Password OPTIONAL,
-                    policy-codes            [3] SET OF PW-Quality-Codes
-                                                    OPTIONAL,
-                    ...
-            }
-            op-etype-not-supported     [4] SEQUENCE {
-                    supported-etypes   [1] SEQUENCE OF Etype,
-                    ...
-            },
-            ...
-        },
-        ...
-   }
-
-   -- Set password
-   Req-set-pw        ::= SEQUENCE {
-        languages        [0] SEQUENCE OF Language-Tag OPTIONAL,
-        new-pw                [1] Password OPTIONAL,
-        commit                [2] BOOLEAN DEFAULT TRUE,
-        etypes                [3] SEQUENCE (1..) OF Etype OPTIONAL,
-        ...
-   }
-
-   Rep-set-pw        ::= SEQUENCE {
-        info-text        [0] UTF8String OPTIONAL,
-        new-pw                [1] Password OPTIONAL,
-                                -- generated by the server if present
-                                -- (and requested by the client)
-        etypes                [2] SEQUENCE (1..) OF Etype OPTIONAL,
-        ...
-   }
-
-   Err-set-pw        ::= Err-change-pw
-
-   -- Set keys
-   Req-set-keys      ::= SEQUENCE {
-        keys            [0] SEQUENCE OF Key,
-        commit          [1] BOOLEAN DEFAULT TRUE,
-                                -- TRUE  -> install keys now
-                                -- 
-                                -- FALSE -> require set-keys-commit
-                                --          before issuing tickets
-                                --          encrypted with these keys.
-                                -- 
-                                -- See commit-keys op
-        isupport        [2] KerberosVSupportNego OPTIONAL,
-                                -- For future Kerberos V extensions KDCs
-                                -- may need to know what krb5 version is
-                                -- supported by individual service
-                                -- principals.  This field provides a
-
-N. Williams et. al.						[Page 24]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-                                -- way to tell the KDC what version of
-                                -- Kerberos V the target principal
-                                -- supports.
-        ...
-   }
-
-   Rep-set-keys        ::= SEQUENCE {
-        info-text        [0] UTF8String OPTIONAL,
-        kvno             [1] UInt32,
-        aliases          [2] SEQUENCE OF SEQUENCE {
-                name     [0] PrincipalName,
-                realm    [1] Realm OPTIONAL,
-                ...
-        },
-        isupport         [3] KerberosVSupportNego OPTIONAL,
-        ...
-        -- Should there be ETYPE-INFO2 stuff here?
-   }
-
-   Err-set-keys        ::= SEQUENCE {
-        help-text     [0] UTF8String OPTIONAL, -- Reason for rejection
-        error         [1] CHOICE {
-                op-generic                    [0] Extensible-NULL,
-                op-deferred-commit-no-support [1] Extensible-NULL,
-                op-etype-no-support           [2] SEQUENCE OF {
-                        supported-etypes      [1] SEQUENCE OF Etype,
-                        ...
-                }
-                ...
-        }
-   }
-
-   -- Generate keys
-   Req-gen-keys        ::= SEQUENCE {
-        etypes           [0] SEQUENCE (1..) OF Etype,
-        entropy          [1] OCTET STRING OPTIONAL,
-        commit           [2] BOOLEAN DEFAULT TRUE,
-                                -- TRUE  -> install keys now
-                                -- 
-                                -- FALSE -> require set-keys-commit
-                                --          before issuing tickets
-                                --          encrypted with these keys.
-                                -- 
-                                -- See commit-keys op
-        isupport         [3] KerberosVSupportNego OPTIONAL,
-                                -- For future Kerberos V extensions KDCs
-                                -- may need to know what krb5 version is
-                                -- supported by individual service
-                                -- principals.  This field provides a
-                                -- way to tell the KDC what version of
-                                -- Kerberos V the target principal
-                                -- supports.
-        ...
-
-N. Williams et. al.						[Page 25]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   }
-
-   Rep-gen-keys        ::= SEQUENCE {
-        info-text        [0] UTF8String OPTIONAL,
-        kvno             [1] UInt32,
-        key              [2] Key,
-        aliases          [3] SEQUENCE OF SEQUENCE {
-                name          [0] PrincipalName,
-                realm         [1] Realm OPTIONAL,
-                ...
-        },
-        isupport         [4] KerberosVSupportNego OPTIONAL,
-        ...
-        -- Should there be ETYPE-INFO2 stuff here?
-   }
-
-   Err-gen-keys        ::= Err-set-keys
-
-   -- Get un-committed key request
-   Req-get-keys        ::= SEQUENCE {
-        kvno             [0] UInt32,
-        ...
-   }
-
-   Rep-get-keys        ::= SEQUENCE {
-        info-text        [0] UTF8String OPTIONAL,
-        keys             [1] SEQUENCE OF Key,
-        aliases          [2] SEQUENCE OF SEQUENCE {
-                name          [0] PrincipalName,
-                realm         [1] Realm OPTIONAL,
-                ...
-        },
-        isupport         [3] KerberosVSupportNego OPTIONAL,
-        ...
-        -- Should there be ETYPE-INFO2 stuff here?
-   }
-
-   Err-get-keys      ::= SEQUENCE {
-        help-text      [0] UTF8String OPTIONAL, -- Reason for rejection
-        error          [1] CHOICE {
-                op-generic         [0] Extensible-NULL,
-                op-kvno-committed  [1] Extensible-NULL,
-                op-no-such-kvno    [1] Extensible-NULL,
-                ...
-        }
-   }
-
-   -- Commit a set keys request
-   Req-commit-keys ::= SEQUENCE {
-        kvno         [0] UInt32,
-        ...
-   }
-
-
-N. Williams et. al.						[Page 26]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   Rep-commit-keys ::= Extensible-NULL
-
-   Err-commit-keys ::= SEQUENCE {
-        help-text    [0] UTF8String OPTIONAL, -- Reason for rejection
-        error        [1] CHOICE {
-                op-generic           [0] Extensible-NULL,
-                op-kvno-expired      [1] Extensible-NULL,
-                    -- The client took too long to respond.
-                op-kvno-unknown      [2] Extensible-NULL,
-                    -- The targ princ/kvno is invalid or unknown to the
-                    -- server (perhaps it lost track of state)
-                op-new-keys-conflict [3] Extensible-NULL,
-                    -- A new-keys/commit-keys request subsequent to the
-                    -- new-keys that produced the kvno has completed
-                    -- and incremented the principal's kvno
-                ...
-        }
-        ...
-   }
-
-   -- Get password policy
-   Req-get-pw-policy   ::= Extensible-NULL
-
-   Rep-get-pw-policy   ::= SEQUENCE {
-        policy-name      [0] UTF8String OPTIONAL,
-        description      [1] SEQUENCE OF UTF8String OPTIONAL,
-        ...
-   }
-
-   Err-get-pw-policy   ::= Extensible-NULL
-
-   -- Get principal aliases
-   Req-get-princ-aliases        ::= Extensible-NULL
-
-   Rep-get-princ-aliases        ::= SEQUENCE {
-        help-text    [0] UTF8String OPTIONAL,
-        aliases      [1] SEQUENCE OF SEQUENCE {
-                name      [0] PrincipalName,
-                realm     [1] Realm OPTIONAL,
-                ...
-        },
-        ...
-   }
-
-   Err-get-princ-aliases        ::= Extensible-NULL
-
-   -- Get list of enctypes supported by KDC for new keys
-   Req-get-realm-krb5-support   ::= Extensible-NULL
-
-   Rep-get-realm-krb5-support   ::= SEQUENCE {
-        isupport        [0] KerberosVSupportNego,
-                                -- Version of Kerberos V supported by
-                                -- the target realm.
-
-N. Williams et. al.						[Page 27]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-        ...
-   }
-
-   Err-get-realm-krb5-support   ::= Extensible-NULL
-
-   -- Get s2kparams
-   Req-get-s2kparams            ::= Extensible-NULL
-
-   Rep-get-s2kparams            ::= SEQUENCE {
-        help-text       [0] UTF8String OPTIONAL,
-        s2kparams       [1] SEQUENCE OF Etype-Info-Entry,
-        ...
-   }
-
-   Err-get-s2kparams            ::= Extensible-NULL
-
-   END
-
-
-6  IANA Considerations
-
-   There are no IANA considerations for this document.
-
-7  Security Considerations
-   
-   Implementors and site administrators should note that the redundancy
-   of UTF-8 encodings of passwords varies by language.  Password quality
-   policies SHOULD, therefore, take this into account when estimating
-   the amount of redundancy and entropy in a proposed new password.  [??
-   It's late at night - I think this is correct.]
-
-   Kerberos set/change password/key protocol major version negotiation
-   cannot be done securely; a downgrade attack is possible against
-   clients that attempt to negotiate the protocol major version to use
-   with a server.  It is not clear at this time that the attacker would
-   gain much from such a downgrade attack other than denial of service
-   (DoS) by forcing the client to use a protocol version which does not
-   support some feature needed by the client (Kerberos V in general is
-   subject to a variety of DoS attacks anyways [RFC1510]).  Clients
-   SHOULD NOT negotiate support for legacy major versions of this
-   protocol unless configured otherwise.
-
-   This protocol does not have Perfect Forward Security (PFS).  As a
-   result, any passive network snooper watching password/key changing
-   operations who has stolen a principal's password or long-term keys
-   can find out what the new ones are.
-
-   [More text needed?]
-
-8  Acknowledgements
-   
-   The authors would like to thank Bill GossmanMike Swift, John Brezak,
-   Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W.
-
-N. Williams et. al.						[Page 28]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   Nelson, Marcus Watts, Love, Joel N.  Weber II, Jeffrey Hutzelman and
-   other participants from the IETF Kerberos Working Group for their
-   assistance.
-
-9  References
-
-9.1  Normative References
-
-   [RFC2026]
-      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
-      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
-      Practice.
-
-   [RFC2119]
-      S. Bradner, RFC2119 (BCP14):  "Key words for use in RFCs to
-      Indicate Requirement Levels," March 1997, Status: Best Current
-      Practice.
-
-   [X680]
-      Abstract Syntax Notation One (ASN.1): Specification of Basic
-      Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
-      International Standard 8824-1:1998.
-      http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf
-
-   [X690]
-      ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
-      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
-      (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
-      Standard 8825-1:1998.
-      http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf
-
-   [clarifications]
-      RFC-Editor: To be replaced by RFC number for
-      draft-ietf-krb-wg-kerberos-clarifications.
-
-   [RFC3066]
-      H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of
-      Languages," January 2001, Obsoletes RFC1766, Status: Best Current
-      Practice.
-
-9.2  Informative References
-
-   [RFC3244]
-      M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000
-      Kerberos Change Password and Set Password Protocols," February
-      2002, Status: Informational.
-
-10  Authors' Addresses
-
-      Nicolas Williams
-      Sun Microsystems
-      5300 Riata Trace Ct
-      Austin, TX 78727
-
-N. Williams et. al.						[Page 29]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-      Email: nicolas.williams@sun.com
-
-      Jonathan Trostle
-      Cisco Systems
-      170 W. Tasman Dr.
-      San Jose, CA 95134
-      Email: jtrostle@cisco.com
-
-11  Notes to the RFC Editor
-
-   This document has two KRB WG drafts as normative references and
-   cannot progress until those drafts progress, but no other draft
-   depends on this one.
-
-12  Change History
-
-    -01 -> -02
-
-     - Removed Bill Gossman, Mike Swift and John Brezak as authors.
-
-     - Removed UDP as a transport for this protocol.
-
-     - Replaced redundant copies of framing ASCII art with reference to
-       RFC3244.
-
-     - Made all name/password strings UTF8String with an extensible
-       constraint to IA5String.
-
-     - Added a method for doing dry runs of operations.  This is helpful
-       in testing passwords against password quality policies.
-
-     - Added an operation for retrieving a principal's current and
-       preferred string-to-key parameters, and a way to change them
-       without changing the principal's password.
-
-     - Added password quality codes as hints for smart clients, but
-       these are optional and not to be used instead of messages to be
-       displayed to useds.
-
-     - Added a 'commit' option to change-pw and set-pw (as requested by
-       Larry).
-
-     - Removed "version" field of the Kerberos V feature negotiation
-       struture.
-
-
-
-N. Williams et. al.						[Page 30]
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-N. Williams et. al.						[Page 31]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-03.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-03.txt
deleted file mode 100644
index 3a923d00d..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-03.txt
+++ /dev/null
@@ -1,1816 +0,0 @@
-
-Kerberos Working Group                                  Nicolas Williams
-INTERNET-DRAFT                                          Sun Microsystems
-Expires: August 22, 2005                               February 21, 2005
-
-
-
-
-                Kerberos Set/Change Password: Version 2
-              <draft-ietf-krb-wg-kerberos-set-passwd-03.txt>
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 22, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).  All Rights Reserved.
-
-Abstract
-
-   This document specifies an extensible protocol for setting keys and
-   changing the passwords of Kerberos V principals.
-
-Table of Contents
-
-   1  Introduction
-   2  The Protocol
-   2.1  Transports 
-   2.2  Protocol Framing
-   2.3  Protocol version negotiation
-   2.3.1  Protocol Major Version Negotiation
-   2.3.2  Protocol Minor Version Negotiation
-   2.4  Use of Kerberos V
-
-N. Williams        						[Page 1]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   2.5  Use of ASN.1
-   2.6  Internationalization
-   2.6.1  Normalization Forms for UTF-8 Strings
-   2.6.2  Language Negotiation
-   2.7  Protocol Extensibility
-   2.8  Protocol Subsets
-   3  Protocol Elements
-   3.1  PDUs
-   3.2  Operations
-   3.2.1  Null
-   3.2.2  Change Kerberos Password
-   3.2.3  Set Kerberos Password
-   3.2.4  Set Kerberos Keys
-   3.2.5  Generate Kerberos Keys
-   3.2.6  Get New Keys
-   3.2.7  Commit New Keys
-   3.2.8  Get Password Quality Policy
-   3.2.9  Get Principal Aliases
-   3.2.10  Get Realm's Supported Kerberos V Version and Features
-   4  ASN.1 Module
-   6  IANA Considerations
-   7  Security Considerations
-   8  Acknowledgements
-   9  References
-   9.1  Normative References
-   9.2  Informative References
-   10  Authors' Addresses
-   11  Notes to the RFC Editor
-
-Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-1  Introduction
-
-   Up to this point Kerberos V has lacked a single, standard protocol
-   for changing passwords and keys.  While several vendor-specific
-   protocols exist for changing Kerberos passwords/keys, none are
-   properly internationalized and all are incomplete in one respect or
-   another and none are sufficiently extensible to cope with new
-   features that may be added to Kerberos V at some future time.
-
-   This document defines a protocol that is somewhat backward-compatible
-   with the "kpasswd" protocol defined in [RFC3244] that uses more or
-   less the same protocol framing.
-
-   This new protocol is designed to be extensible and properly
-   internationalized.
-
-2  The Protocol
-
-
-N. Williams        						[Page 2]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   The structure of the protocol is quite similar to that of typical RPC
-   protocols.  Each transaction consists of a data structure specific to
-   an operation which is then wrapped in a data structure which is
-   general to all operations of the protocol.  These data structures are
-   defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they
-   are encoded using the Distinguished Encoding Rules (DER) [X690].
-
-   All protocol data is wrapped KRB-PRIV messages, or, in some cases, a
-   KRB-ERROR, and framed in a header that is backwards compatible with
-   [RFC3244].
-
-2.1  Transports 
-
-   The service supports only connection-oriented transports,
-   specifically TCP, and MUST accept requests on TCP port 464, the same
-   as in [RFC3244].
-
-2.2  Protocol Framing
-
-   Requests and responses are exchanged using the same framing as in
-   [RFC3244], but with the following differences:
-
-    - the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1)
-
-    - the 'AP-REQ length' field of the request can be set to 0x0, in
-      which case the 'AP-REQ' field of the request is excluded
-
-    - the 'KRB-PRIV' field of the request and reply is mutually
-      exclusive with the 'AP-REQ' field of the request
-
-    - the 'AP-REP length' field of the reply can be set to 0x0, in
-      which case the 'AP-REP' field of the reply is excluded
-
-    - all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can
-      be or has been accepted by the server
-
-    - any KRB-ERROR messages are framed and sent in the 'AP-REP' field
-      of the reply
-
-   The initial message from the client MUST carry an AP-REQ and the
-   response to any request bearing an AP-REQ MUST carry an AP-REP or
-   MUST be a KRB-ERROR.
-
-   Subsequent messages exchanged on the same TCP connection MAY involve
-   Kerberos V AP exchanges, but generally the client SHOULD NOT initiate
-   a new AP exchange except when it desires to authenticate as a
-   different principal, when the ticket last used for authentication
-   expires or when the server responds with an error indicating that the
-   client must re-authenticate.
-
-2.3  Protocol Version Negotiation
-
-   There are several major versions of this protocol.  Version 2 also
-
-N. Williams        						[Page 3]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   introduces a notion of protocol minor versions for use in negotiating
-   protocol extensions.  As of this time only one minor version is
-   defined for major version 2: minor version 0, defined herein.
-
-2.3.1  Protocol Major Version Negotiation
-
-   Version 2 clients that also support other versions, such as 0xff80,
-   as in [RFC3244], SHOULD attempt to use version 2 of the protocol
-   first.
-
-   Servers which do not support version 2 of this protocol typically
-   include their preferred version number in the reply and/or may
-   include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a
-   status code of KRB5_KPASSWD_MALFORMED.
-
-   Note that some [RFC3244] server implementations close the TCP
-   connection without returning any other response.  Note also that
-   there is no integrity protection for the major version number in the
-   protocol framing or for any data in a KRB-ERROR.
-
-   As a result change password protocol major version negotiation is
-   subject to downgrade attacks.  Therefore major version negotiation is
-   NOT RECOMMENDED.
-
-   Where the server indicates that it does not support version 2, the
-   client MAY, but SHOULD NOT, unless configured to do so, fall back on
-   another major version of this protocol.
-
-   Version 2 servers MAY respond to non-v2 requests using whatever
-   response is appropriate for the versions used by the clients, but if
-   a server does not do this or know how to do this then it MUST respond
-   with an error framed as in section 2.2, using an AP-REP and KRB-PRIV
-   if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and
-   using a ProtocolErrorCode value of unsupported-major-version.
-
-   It is expected that implementations of as yet unspecified future
-   major versions of this protocol will be required to support version 2
-   integrity protected error replies for properly indicating no support
-   for version 2 of the protocl.  We also hope that no further major
-   versions of this protocol will be needed.
-
-2.3.2  Protocol Minor Version Negotiation
-
-   Version 2 clients are free to use whatever protocol minor version and
-   message extensions are available to them in their initial messages to
-   version 2 servers, provided that the minor versions (other than 0)
-   have been defined through IETF documents.
-
-   Version 2 servers MUST answer with the highest protocol minor version
-   number supported by the server and the client.
-
-   Version 2 clients MUST use the protocol minor version used in a
-   server's reply for any subsequent messages in the same TCP session.
-
-N. Williams        						[Page 4]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-
-   See section 2.7 for further description of the protocol's
-   extensibility and its relation to protocol minor versions and the
-   negotiation thereof.
-
-2.4  Use of Kerberos V and Key Exchange
-
-   This protocol makes use of messages defined in [RFC1510] and
-   [clarifications].  Specifically, AP-REQ, AP-REP, KRB-ERROR and
-   KRB-PRIV.
-
-   All operations are to be performed by the server on behalf of the
-   client principal.
-
-   Clients SHOULD use "kadmin/setpw" as the principal name of the server
-   for all requests except when changing the client principal's own
-   expired password, for which they should use "kadmin/changepw".  The 
-   "kadmin/changepw" service exists to allow KDCs to limit principals
-   with expired passwords to getting initial tickets to the password
-   changing service only and only for changing expired passwords.
-
-   Servers MUST limit clients that used the "kadmin/changepw" service
-   principal name to changing the password of the client principal.
-
-   The client MUST request mutual authentication and the client MUST
-   MUST request the use of sequence numbers.
-
-   Clients SHOULD use INITIAL tickets for requests whose target
-   principal is the client's principal.  Servers SHOULD force the use of
-   INITIAL tickets for such requests and MAY force the use of INITIAL
-   for all others - see section 3.2.
-
-   Servers MUST specify a sub-session key.
-
-   The encrypted part of KRB-PRIVs MUST be encrypted with the server's
-   sub-session key and key usage 20 (client->server) or 21
-   (server->client).
-
-   After each new AP exchange the client and server MUST destroy the
-   session keys, if any, resulting from the previous AP exchange.
-
-2.5  Use of ASN.1
-
-   This protocol's messages are defined in ASN.1, using only features
-   from [X680].  All ASN.1 types defined herein are to be encoded in
-   DER [X690].  A complete ASN.1 module is given in section 4.
-
-   The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
-   KRB-PRIV as described above and/or as e-data in KRB-ERROR messages.
-
-2.6  Internationalization
-
-   This protocol's request PDU carries an optional field indicating the
-
-N. Williams        						[Page 5]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   languages spoken by the client user; the client SHOULD send its list
-   of spoken languages to the server (once per-TCP session).
-
-   The server SHOULD localize all strings intended for display to users
-   to a language in common with the languages spoken by the client user.
-
-   Strings for Kerberos principal and realm names used in this protocol
-   are be constrained as per [clarifications].
-
-2.6.1  Normalization Forms for UTF-8 Strings
-
-   Because Kerberos V [clarifications] restricts principal names, realm
-   names and passwords to IA5String, this protocol uses UTF8String with
-   an extensible constraint to IA5String.
-
-   Future versions of Kerberos may relax this constraint; if so then a
-   minor version of this protocol should relax this constraint
-   accordingly.
-
-2.6.2  Language Negotiation
-
-   The server MUST pick a language from the client's input list or
-   the default language tag (see [RFC3066]) for text in its responses
-   which is meant for the user to read.
-
-   The server SHOULD use a language selection algorithm such that
-   consideration is first given to exact matches between the client's
-   spoken languages and the server's available locales, followed by
-   "fuzzy" matches where only the first sub-tags of the client's
-   language tag list are used for matching against the servers available
-   locales.
-
-   Servers MUST cache the optional language tag lists from prior
-   requests for use with subsequent requests that exclude the language
-   tag list.  Clients MAY expect such server behaviour and send the
-   language tag lists only once per-TCP session.  Clients SHOULD send
-   the server the language tag list at least once.
-
-   When the server has a message catalog for one of the client's spoken
-   languages the server SHOULD localize any text strings intended for
-   display to users.
-
-2.7  Protocol Extensibility
-
-   The protocol is defined in ASN.1 and uses extensibility markers
-   throughout.  As such, the module presented herein can be extended
-   within the framework of [X680].
-
-   Typed holes are not used in this protocol as it is very simple and
-   does not require the ability to deal with abstract data types defined
-   in different layers.  For this reason, the only way to extend this
-   protocol is by extending the ASN.1 module within the framework of the
-   IETF; all future extensions to this protocol have to be defined in
-
-N. Williams        						[Page 6]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   IETF documents unless otherwise specified in a future IETF revision
-   of this protocol.
-
-   A protocol minor version number is used to negotiate use of
-   extensions.  See section 2.3.2 for the minor version negotiation.
-
-   Servers SHOULD ignore unknown additions to the ASN.1 types, in
-   initial requests, where the syntax allows them, except for extensions
-   to the "Op-req" type, which MUST result in an error.
-
-   Servers MUST respond with an error (ProtocolErrorCode value of
-   unsupported-minor-version) to clients that use operations unknown to
-   the server.
-
-2.8  Protocol Subsets
-
-   The structure of the protocol is such that the ASN.1 syntaxes for the
-   various operations supported by the protocol are independent of the
-   each other.  Client and server implementations MAY implement subsets
-   of the overall protocol by removing some alternatives to the Op-req,
-   Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4.
-   
-   For example, it should be possible to have a password-change only
-   client that cannot set principal's keys - and vice versa.
-
-3  Protocol Elements
-
-   The protocol as defined herein supports the following operations
-   relating to the management of Kerberos principal's passwords or keys:
-
-     [NOTE:  New since last version of this I-D.]
-     - get principal's current and preferred string-to-key parameters
-
-     - change password (or enctypes and string-to-key parameters)
-     - set password (administrative)
-     - set new keys
-     - generate new keys
-     - get new, un-committed keys
-     - commit new keys
-     - get password policy name and/or description of principal
-     - list aliases of a principal
-     - list enctypes and version of Kerberos V supported by realm
-
-   The operation for retrieving a list of aliases of a principal is
-   needed where KDCs implement aliasing of principal names and allows
-   clients to properly setup their key databases when principal aliasing
-   is in use.
-
-   Operations such as creation or deletion of principals are outside the
-   scope of this document, and should be performed via other means, such
-   as through directories or other Kerberos administration protocols.
-
-   The individual operations are described in section 3.2.
-
-N. Williams        						[Page 7]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-
-3.1  PDUs
-
-   The types "Request," "Response" and "Error-Response" are the ASN.1
-   module's PDUs.
-
-   The "Request" and "Response" PDUs are always to be sent wrapped in
-   KRB-PRIV messages, except for the "Error-Response" PDU which MUST be
-   sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail,
-   otherwise it MUST be sent wrapped in a KRB-PRIV.
-
-   The ASN.1 syntax for the PDUs is given in section 4.
-
-   Note that the first field of each PDU is the major version of the
-   protocol, defaulted to 2, meaning that it is never included in
-   version 2 exchanges.  Similarly, the second field of each PDU is the
-   minor version, defaulted to 0.
-
-   The request, responses and error PDUs consist of an outer structure
-   ("Request," "Response" and "Error-Response") containing fields common
-   to all requests, responses and errors, respectively, and an inner
-   structure for fields that are specific to each operation's
-   requests/responses.  The inner structure is optional in the case of
-   the Error-Response PDU and need not be included when generic errors
-   occur for which there is a suitable ProtocolErrorCode.
-
-   Specifically, the outer Request structure has a field for passing a
-   client user's spoken (read) languages to the server.  It also has two
-   optional fields for identifying the requested operation's target
-   principal's name and realm (if not sent then the server MUST use the
-   client's principal name and realm as the target).  A boolean field
-   for indicating whether or not the request should be dry-run is also
-   included; dry-runs can be used to test server policies, and servers
-   MUST NOT modify any principals when processing dry-run requests.
-
-   The Response and Error PDUs' outer structures include a field
-   indicating the language that the server has chosen for localization
-   of text intended to be displayed to users; this field is defaulted to
-   "i-default".  This language tag applies to all UTF8 strings in the
-   inner structure (Op-rep and Op-err) that are meant to be displayed to
-   users.
-
-   The protocol error codes are:
-
-      - proto-generic-error
-
-        An operation-specific error ocurred, see the inner Op-error.
-
-      - proto-format-error
-      - proto-unsupported-major-version
-      - proto-unsupported-minor-version
-      - proto-unsupported-operation
-
-
-N. Williams        						[Page 8]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-      - proto-wrong-service-principal
-
-        Use kadmin/setpw for the server's principal name.
-
-      - proto-re-authentication-required
-
-        The server demands that the client re-authenticate through a new
-        AP exchange.
-
-      - proto-initial-ticket-required
-
-        Use of an INITIAL ticket is required for the requested
-        operation.
-
-      - proto-client-and-target-realm-mismatch
-
-        The server requires that the client's principal name and the
-        target principal of the operation share the same realm name.
-
-      - proto-target-principal-unknown
-      - proto-authorization-failed
-
-3.2  Operations
-
-   This section describes the semantics of each operation request and
-   response defined in the ASN.1 module in section 4.
-      
-3.2.1  Null
-
-   NAME
-
-      null - Null or "ping" operation
-
-   DESCRIPTION
-
-      The null request is intended for use with TCP; its purpose is
-      similar to RPC null procedures and is akin to a "ping" operation.
-
-   ERRORS
-
-      None.
-
-3.2.2  Change Kerberos Password
-
-   NAME
-
-      change-pw - Change password operation
-
-   SYNOPSIS
-
-      Req-change-pw(old-pw, [languages], [new-pw],
-                    [commit], [etypes]) ->
-         Rep-change-pw([info-text], [new-pw], [etypes]) |
-
-N. Williams        						[Page 9]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-         Err-change-pw([help-text], error code, [error info])
-
-   DESCRIPTION
-
-      Change a principal's password.
-
-      The change password request has one required, three optional and
-      one defaulted arguments: "old-pw" (required), "languages,"
-      "new-pw", "commit" (defaults to "TRUE") and "etypes",
-      corresponding to the target principal's old password, its
-      preferred languages, its new password, a boolean indicating
-      whether or not to make the new long-term key available for
-      immediate use, and the desired enctypes for the new long-term
-      keys.
-
-      The server MUST validate the old password and MUST check the
-      quality of the new password, if sent, according the password
-      quality policy associated with the target principal.
-
-      If the old and new passwords in the request are the same strings,
-      and the principal is not currently required to change its
-      password, then the server MAY permit the password change as way to
-      change a principal's enctypes and string-to-key parameters.  This
-      feature provides a way to, for example, add enctypes to a
-      principals' password-derived long-term keys without forcing a
-      password change following an upgrade to the KDC that adds support
-      for new enctypes.
-
-      A client MAY request that the server generate a new password by
-      excluding the new password from its request, in which case the
-      server MUST either generate a new password or respond with an
-      error indicating that it does not support this feature.
-
-      Server-generated passwords MUST meet the target principal's
-      password quality policy.  It is RECOMMENDED that server-generated
-      passwords be user-friendly, that is, memorable and that the target
-      principal's preferred languages be taken into account by the
-      password generation alogrithm used by the server.
-
-      Uncommitted password changes are commited using the commit-keys
-      operation.
-
-   RETURN
-
-      Upon successful password changes the server responds with a
-      Rep-change-pw.  The fields of Rep-change-pw are all optional and
-      include:
-
-         - 'info-text' which the server can use to send a message to the
-           user such as "Your new password will expire in 90 days," for
-           example.
-
-         - 'new-pw' which the server MUST include if the client
-
-N. Williams        						[Page 10]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-           requested that the server generate a new password; generated
-           passwords MUST pass the target principal's password quality
-           policy.
-
-         - 'etypes' which the server MAY include to indicate which types
-           of long-term keys it created for the target principal and
-           which the server MUST include if the client specified a set
-           of enctypes in its request.
-
-   ERRORS
-
-      The server may respond to change password requests with protocol
-      or operation errors.  See section 3.1 for a description of
-      protocol error codes.
-
-      All operation errors include an optional 'help-text' field by
-      which the server can describe the error in a human-readable,
-      localizaed string.
-
-      Change password error codes include:
-
-         - generic-error
-
-         - old-pw-incorrect
-
-         - wont-generate-new-pw
-
-           The server will not generate a new password for this
-           principal or does not support password generation in general.
-
-         - new-pw-rejected-generic
-
-           The client's proposed new password failed the target
-           principal's password quality policy.
-
-           The server MUST include a description of the password quality
-           policy or aspect of it that the client's proposed new
-           password failed to meet.
-
-           The server MAY generate and send a new password that the
-           client can then use as a new password and which is guaranteed
-           to pass the target principal's current password quality
-           policy.
-
-           The server MAY include a set of policy error code hints.
-
-         - etype-not-supported
-
-           The client requested an enctype that the KDC does not
-           support.
-
-3.2.3  Set Kerberos Password
-
-
-N. Williams        						[Page 11]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   NAME
-
-      set-pw - Set password operation
-
-   SYNOPSIS
-
-      Req-set-pw([languages], [new-pw], [commit], [etypes]) ->
-         Rep-set-pw([info-text], [new-pw], [etypes]) |
-         Err-set-pw([help-text], error code, [error info])
-
-   DESCRIPTION
-
-      Administratively set a principal's password.
-
-      The set password request has three optional and one defaulted
-      arguments: "languages", "new-pw," "commit" (defaulted to "TRUE")
-      and "etypes", corresponding to the target principal's preferred
-      languages, new password, a boolean indicating whether or not to
-      make the new long-term key available for immediate use, and the
-      desired enctypes for the new long-term keys.
-
-      The server MUST check the quality of the new password, if sent,
-      according the password quality policy associated with the target
-      principal.
-
-      The server SHOULD require that the client use the change-pw
-      operation instead of set-pw when the client principal and the
-      target principal are the same.
-
-      A client MAY request that the server generate a new password by
-      excluding the new password from its request, in which case the
-      server MUST either generate a new password or respond with an
-      error indicating that it does not support this feature.
-
-      Server-generated passwords MUST meet the target principal's
-      password quality policy.  It is RECOMMENDED that server-generated
-      passwords be user-friendly, that is, memorable and that the target
-      principal's preferred languages be taken into account by the
-      password generation alogrithm used by the server.
-
-   RETURN
-
-      Upon successfully setting a password the server responds with a
-      Rep-set-pw.  The fields of Rep-set-pw are all optional and
-      include:
-
-         - 'info-text' which the server can use to send a message to the
-           user such as "Your new password will expire in 90 days," for
-           example.
-
-         - 'new-pw' which the server MUST include if the client
-           requested that the server generate a new password; generated
-           passwords MUST pass the target principal's password quality
-
-N. Williams        						[Page 12]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-           policy.
-
-         - 'etypes' which the server MAY include to indicate which types
-           of long-term keys it created for the target principal and
-           which the server MUST include if the client specified a set
-           of enctypes in its request.
-
-   ERRORS
-
-      The server may respond to set password requests with protocol or
-      operation errors.  See section XYZ for a description of protocol
-      error codes.
-
-      All operation errors include an optional 'help-text' field by
-      which the server can describe the error in a human-readable,
-      localizaed string.
-
-      Set password error codes include:
-
-         - generic-error
-
-         - use-change-pw
-
-           The server demands that the client use the change-pw
-           operation for the target principal of the set-pw request.
-
-         - wont-generate-new-pw
-
-           The server will not generate a new password for this
-           principal or does not support password generation in general.
-
-         - new-pw-rejected-generic
-
-           The client's proposed new password failed the target
-           principal's password quality policy.
-
-           The server MUST include a description of the password quality
-           policy or aspect of it that the client's proposed new
-           password failed to meet.
-
-           The server MAY generate and send a new password that the
-           client can then use as a new password and which is guaranteed
-           to pass the target principal's current password quality
-           policy.
-
-           The server MAY include a set of policy error code hints.
-
-         - etype-not-supported
-
-           The client requested an enctype that the KDC does not
-           support.
-
-3.2.4  Set Kerberos Keys
-
-N. Williams        						[Page 13]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-
-   NAME
-
-      set-keys
-
-   SYNOPSIS
-
-      Req-set-keys(new-keys, commit?, [isupport]) ->
-         Rep-set-keys([info-text], kvno, aliases, [isupport])
-
-   DESCRIPTION
-
-      The set-keys request consists of two required fields and one
-      optional field: "new-keys", "commit" (a boolean field - see below)
-      and "isupport", an optional field for indicating to the KDC what
-      Kerberos V features are supported by the target principal.
-
-      When "commit" is true the KDC makes the new keys available for
-      issueing tickets encrypted in them immediately.  Otherwise the
-      client MUST follow up with a commit-keys request to make the keys
-      available.  This feature is useful for changing keys shared by
-      multiple hosts, in clustered services, for example, in an atomic
-      manner; see section 3.2.6 and 3.2.7.
-
-      If a principal has keys are awaiting commitment when a new
-      set-keys request for that principal s made then the KDC MUST
-      overwrite the deferred keys.
-
-   RETURN
-
-      For successful set-keys operations the server returns:
-
-         - Informational text, optional.
-
-         - The new kvno for the target principal.
-
-         - A list of aliases of the target principal known to the KDC
-           (optional).
-
-         - The set of Kerberos V features supported by the KDC
-           (optional).
-
-   ERRORS
-
-      The server may respond with the following errors:
-
-         - generic
-         - deferred-commit-no-support
-         - etype-no-support
-
-3.2.5  Generate Kerberos Keys
-
-   NAME
-
-N. Williams        						[Page 14]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-
-      gen-keys
-
-   SYNOPSIS
-
-      Req-gen-keys(etypes, [entropy], commit?, [isupport]) ->
-         Rep-set-keys([info-text], key, kvno, aliases, [isupport])
-
-   DESCRIPTION
-
-      The gen-keys is similar to the set-keys request (see section
-      3.2.4) but differs in that the server generates keys of
-      client-requested enctypes, rather than the client providing
-      specific keys.
-
-      The gen-keys request consists of two required fields and two
-      optional fields: "etypes" (the enctypes of the new keys),
-      "entropy", "commit" and "isupport" (see section 3.2.4).
-
-      If a principal has keys are awaiting commitment when a new
-      set-keys request for that principal s made then the KDC MUST
-      overwrite the deferred keys.
-
-   RETURN
-
-      For successful set-keys operations the server returns:
-
-         - Informational text, optional.
-
-         - The new kvno for the target principal.
-
-         - The new key (only one is needed).
-
-         - A list of aliases of the target principal known to the KDC
-           (optional).
-
-         - The set of Kerberos V features supported by the KDC
-           (optional).
-
-   ERRORS
-
-      The server may respond with the following errors:
-
-         - generic
-         - deferred-commit-no-support
-         - etype-no-support
-
-3.2.6  Get New Keys
-
-   NAME
-
-      get-keys
-
-
-N. Williams        						[Page 15]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   SYNOPSIS
-
-      Req-get-keys(kvno) ->
-         Rep-get-keys([info-text], keys, aliases, [isupport]) |
-         Err-get-keys([help-text], error code, [error info])
-
-   DESCRIPTION
-
-      This request allows a client to get the keys set or generated in a
-      previous set-keys or gen-keys request with deferred commitment..
-
-   RETURN
-
-      If the target principal and kvno correspond to uncommitted keys
-      the server MUST respond with the actual keys that would be set by
-      a subsequent commit-keys request.  Otherwise the server MUST
-      respond with an error (meaning that this operation cannot be used
-      to extract keys from the KDC that may be in use).
-
-   ERRORS
-
-         - generic
-         - kvno-committed
-         - no-such-kvno
-
-3.2.7  Commit New Keys
-
-   NAME
-
-      commit-keys
-
-   SYNOPSIS
-
-      Req-commit-keys(kvno) ->
-         Rep-commit-keys() |
-         Err-commit-keys([help-text], error code, [error info])
-
-   DESCRIPTION
-
-      The commit-keys operation allows a client to bring a principal's
-      new keys into use at the KDC.
-
-      Clients should make a commit-keys request corresponding to a
-      deferred commitment set-keys/gen-keys operation as soon as the
-      local key database for the target principal is updated.
-
-      The target principal name and the kvno MUST match those from a
-      prior set-keys or gen-keys operation.
-
-      Servers MAY expire delayed key commitments at will.  Servers
-      SHOULD expire uncommitted new keys after a reasonable amount of
-      time (600 seconds is RECOMMENDED).
-
-
-N. Williams        						[Page 16]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-      Servers MUST respond to new set-keys requests for principals with
-      pending, uncommitted new keys by expiring the uncommitted new keys
-      and proceeding as if there had been no expired new keys.
-
-   ERRORS
-
-      - generic
-      - op-kvno-expired
-      - op-kvno-unknown
-      - new-keys-conflict (A set-keys or gen-keys request succeeded
-                           subsequent to the request that matches this
-                           {principal, kvno} tuple.)
-
-3.2.8  Get Password Quality Policy
-   
-   NAME
-
-      get-pw-policy
-
-   SYNOPSIS
-
-      Req-get-pw-policy() ->
-         Rep-get-pw-policy([policy name], [policy description])
-
-   DESCRIPTION
-
-      Returns a description of the target principal's associated
-      password quality policy, if any, as a list of localized
-      UTF8String values.
-
-      Clients can use this operation in conjunction with the change-pw
-      operation to obtain text that can be displayed to the user before
-      the user actually enters a new password.
-
-      It is common for sites to set policies with respect to password
-      quality.  It is beyond the scope of this document to describe such
-      policies.  Management of password quality policies' actual content
-      is also beyond the scope of this protocol.
-
-   ERRORS
-
-      No operation errors are defined.
-
-
-3.2.9  Get Principal Aliases
-   
-   NAME
-
-      get-print-aliases
-
-   SYNOPSIS
-
-      Req-get-princ-aliases() ->
-
-N. Williams        						[Page 17]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-         Rep-get-princ-aliases(aliases)
-
-   DESCRIPTION
-
-      Returns a list of aliases of the target principal.
-
-   ERRORS
-
-      No operation-specific errors.
-
-3.2.10  Get Realm's Supported Kerberos V Version and Features
-   
-   NAME
-
-      get-realm-krb5-support
-
-   SYNOPSIS
-
-      Req-get-realm-krb5-support() ->
-         Rep-get-realm-krb5-support(isupport)
-
-   DESCRIPTION
-
-      Returns set of Kerberos V features support by the target
-      principal's realm's KDCs.
-
-   ERRORS
-
-      No operation-specific errors.
-
-3.2.11  Retrieve Principal's S2K Params and Preferred Params
-   
-   NAME
-
-      get-s2kparams
-
-   SYNOPSIS
-
-      Req-get-s2kparams() ->
-         Rep-get-s2kparams([princ-s2kparams], [preferred-s2kparams])
-
-   DESCRIPTION
-
-      Returns the string2key parameters for the principal's current
-      password-derived long-term keys, if any, and the parameters that
-      the realm would prefer, if they differ from the former.
-
-      This operation is intended for use with the change-pw() operation.
-      When surprised by a KDC's PA-ETYPE-INFO2 a client SHOULD check if
-      the principal's long-term secret keys' string2key parameters (and
-      enctype list) should be changed and, if so, change them.
-
-      If the 'princ-s2kparams' return value is missing then the
-
-N. Williams        						[Page 18]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-      principal does not have a password-derived long-term key.
-
-      The 'preferred-s2kparams' MUST be excluded if the principal's
-      string2key parameters satisfy the realm's policy.
-
-   ERRORS
-
-      No operation-specific errors.
-
-3.3  Principal Aliases
-
-   Applications that use Kerberos often have to derive acceptor
-   principal names from hostnames entered by users.  Such hostnames may
-   be aliases, they may be fully qualified, partially qualified or not
-   qualified at all.  Some implementations have resorted to deriving
-   principal names from such hostnames by utilizing the names services
-   to canonicalize the hostname first; such practices are not secure
-   unless the name service are secure, which often aren't.
-
-   One method for securely deriving principal names from hostnames is to
-   alias principals at the KDC such that the KDC will issue tickets for
-   principal names which are aliases of others.  It is helpful for
-   principals to know what are their aliases as known by the KDCs.
-
-   Note that changing a principal's aliases is out of scope for this
-   protocol.
-
-3.4  Kerberos V Feature Negotiation
-
-   Principals and realms' KDCs may need to know about additional
-   Kerberos V features and extensions that they each support.  Several
-   operations (see above) provide a way for clients and servers to
-   exchange such infomration, in the form of lists of types supported
-   for the various typed holes used in Kerberos V.
-
-4  ASN.1 Module
-
-   DEFINITIONS EXPLICIT TAGS ::= BEGIN
-   -- 
-   -- Note:  EXPLICIT tagging is in use by default throughout this
-   --        module.
-
-   -- From [clarifications] with modifications
-   PrincipalName            ::= SEQUENCE {
-        name-string [1] SEQUENCE OF UTF8String (IA5String, ...)
-   }
-   Realm                    ::= UTF8String (IA5String, ...)
-   Salt                     ::= UTF8String (IA5String, ...)
-   Password                 ::= UTF8String (IA5String, ...)
-
-   -- NOTE WELL: Principal and realm names MUST be constrained by the
-   --            specification of the version of Kerberos V used by the
-   --            client.
-
-N. Williams        						[Page 19]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   -- 
-   -- [Perhaps PrincipalName should be a SEQUENCE of an optional name
-   --  type and a UTF8String, for simplicity.]
-
-   -- From [clarifications]
-   Int32            ::= INTEGER (-2147483648..2147483647)
-   UInt32           ::= INTEGER (0..4294967295)
-
-   -- Based on [clarifications]
-   Etype            ::= Int32
-   Etype-Info-Entry ::= SEQUENCE {
-        etype           [0] Etype,
-        salt            [1] Salt OPTIONAL,
-        s2kparams       [2] OCTET STRING OPTIONAL,
-        ...
-   }
-   Key              ::= SEQUENCE {
-        enc-type        [0] Etype,        -- from Kerberos
-        key             [1] OCTET STRING,
-        ...
-   }
-
-   Language-Tag     ::= UTF8String -- Constrained by [RFC3066]
-
-   -- Empty, extensible SEQUENCEs are legal ASN.1
-   Extensible-NULL  ::= SEQUENCE {
-        ...
-   }
-
-   -- Kerberos clients negotiate some parameters relating to their peers
-   -- indirectly through the KDC.  Today this is true of ticket session
-   -- key enctypes, but in the future this indirect negotiation may also
-   -- occur with respect to the minor version of Kerberos V to be used
-   -- between clients and servers.  Additionally, KDCs may need to know
-   -- what authorization-data types are supported by service principals,
-   -- both, for compatibility with legacy software and for optimization.
-   --
-   -- Thesefore it is important for KDCs to know what features of
-   -- Kerberos V each service principal supports.
-   --
-   -- In version 2.0 of this protocol the clients and servers may notify
-   -- each other of their support for:
-   --
-   --  - enctypes
-   --  - authorization data types
-   --  - transited encoding data types
-   --
-   -- All authorization-data types defined in [clarifications] are
-   -- assumed to be supported if the minor version is 1 and do not need
-   -- to be included in the ad-type list.
-   --
-   -- Int32 is used for enctype and transited encoding data type
-   -- identifiers.
-
-N. Williams        						[Page 20]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   --
-   -- An extensible CHOICE of Int32 is used for authorization data
-   -- types.
-
-   KerberosV-TR-ID             ::= Int32
-
-   KerberosV-AD-ID             ::= CHOICE {
-        ad-int                [0] Int32,
-        ...
-   }
-
-   KerberosVSupportNego        ::= SEQUENCE {
-        enc-types       [0] SEQUENCE OF Etype,
-        ad-types        [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL,
-                                    -- authorization data types
-        tr-enc-types    [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL,
-                                    -- transited encoding types
-        ...
-   }
-
-   Request                     ::= [APPLICATION 0] SEQUENCE {
-        pvno-minor      [0] INTEGER DEFAULT 0,
-        languages       [1] SEQUENCE OF Language-Tag OPTIONAL,
-                -- Should be defaulted to the SEQUENCE of "i-default"
-        targ-name       [2] PrincipalName OPTIONAL,
-        targ-realm      [3] Realm OPTIONAL,
-                -- If targ-name/realm are missing then the request
-                -- applies to the principal of the client
-        dry-run         [4] BOOLEAN DEFAULT FALSE,
-        operation       [5] Op-req,
-        ...
-   }
-
-   Response                    ::= [APPLICATION 1] SEQUENCE {
-        pvno-minor      [0] INTEGER DEFAULT 0,
-        language        [1] Language-Tag DEFAULT "i-default",
-        result          [2] Op-rep,
-        ...
-   }
-
-   Error-Response              ::= [APPLICATION 2] SEQUENCE {
-        pvno-minor      [0] INTEGER DEFAULT 0,
-        language        [1] Language-Tag DEFAULT "i-default",
-        error-code      [2] ProtocolErrorCode,
-        help-text       [3] UTF8String OPTIONAL,
-        op-error        [4] Op-err OPTIONAL,
-        ...
-   }
-
-   Op-req                      ::= CHOICE {
-        null                     [0] Req-null,
-        change-pw                [1] Req-change-pw,
-        set-pw                   [2] Req-set-pw,
-
-N. Williams        						[Page 21]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-        set-keys                 [3] Req-set-keys,
-        gen-keys                 [4] Req-gen-keys,
-        get-keys                 [5] Req-get-keys,
-        commit-keys              [6] Req-commit-keys,
-        get-pw-policy            [7] Req-get-pw-policy,
-        get-princ-aliases        [8] Req-get-princ-aliases,
-        get-realm-krb5-support   [9] Req-get-realm-krb5-support,
-        get-s2kparams            [10] Req-get-s2kparams,
-        ...
-   }
-
-   Op-rep                     ::= CHOICE {
-        null                    [0] Rep-null,
-        change-pw               [1] Rep-change-pw,
-        set-pw                  [2] Rep-set-pw,
-        set-keys                [3] Rep-set-keys,
-        gen-keys                [4] Req-gen-keys,
-        get-keys                [5] Req-get-keys,
-        commit-keys             [6] Rep-commit-keys,
-        get-pw-policy           [7] Rep-get-pw-policy,
-        get-princ-aliases       [8] Rep-get-princ-aliases,
-        get-realm-krb5-support  [9] Rep-get-realm-krb5-support,
-        get-s2kparams           [10] Rep-get-s2kparams,
-        ...
-   }
-
-   Op-err        ::= CHOICE {
-        null                    [0] Err-null,
-        change-pw               [1] Err-change-pw,
-        set-pw                  [2] Err-set-pw,
-        set-keys                [3] Err-set-keys,
-        gen-keys                [4] Err-gen-keys,
-        get-keys                [5] Err-get-keys,
-        commit-keys             [6] Err-commit-keys,
-        get-pw-policy           [7] Err-get-pw-policy,
-        get-princ-aliases       [8] Err-get-princ-aliases,
-        get-realm-krb5-support  [9] Err-get-realm-krb5-support,
-        get-s2kparams           [10] Err-get-s2kparams,
-        ...
-   }
-
-   ProtocolErrorCode           ::= ENUM {
-        proto-format-error,
-        proto-unsupported-major-version,
-        proto-unsupported-minor-version,
-        proto-unsupported-operation,      -- Request CHOICE tag unknown
-        proto-generic-see-op-error,       -- See Op-error
-        proto-wrong-service-principal,    -- Use kadmin/setpw
-        proto-re-authentication-required,
-        proto-initial-ticket-required,
-        proto-client-and-target-realm-mismatch,
-        proto-target-principal-unknown,
-        proto-authorization-failed,
-
-N. Williams        						[Page 22]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-        proto-dry-run-not-permitted,
-        ...
-   }
-
-   -- These codes are hints for clients, primarily for when they are
-   -- used for changing the passwords of automated principals; error
-   -- replies carry password quality policy help text that is more
-   -- appropriate for clients to display to users.
-   PW-Quality-Codes        ::= ENUM {
-        pwq-generic,
-        pwq-too-soon,
-        pwq-repeated,
-        pwq-too-short,
-        pwq-dictionary-words,
-        pwq-prohibited-codepoints,
-        pwq-need-more-char-classes,
-        ...
-   }
-
-   --
-   -- Requests and responses
-   --
-
-   -- NULL request, much like ONC RPC's NULL procedure - NOT extensible
-   Req-null    ::= NULL
-
-   Rep-null    ::= NULL
-
-   Err-null    ::= NULL
-
-   -- Change password
-   Req-change-pw        ::= SEQUENCE {
-        old-pw            [0] Password,
-        new-pw            [1] Password OPTIONAL,
-        commit            [2] BOOLEAN DEFAULT TRUE,
-        etypes            [3] SEQUENCE (1..) OF Etype OPTIONAL,
-        ...
-   }
-
-   Rep-change-pw        ::= SEQUENCE {
-        info-text         [0] UTF8String OPTIONAL,
-        new-pw            [1] Password OPTIONAL,
-                            -- generated by the server if present
-                            -- (and requested by the client)
-        etypes            [2] SEQUENCE (1..) OF Etype OPTIONAL,
-        ...
-   }
-
-   Err-change-pw        ::= SEQUENCE {
-        help-text         [0] UTF8String OPTIONAL,
-        error             [1] CHOICE {
-            op-generic-error           [0] Extensible-NULL,
-            op-old-pw-incorrect        [1] Extensible-NULL,
-
-N. Williams        						[Page 23]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-            op-wont-generate-new-pw    [2] Extensible-NULL,
-            op-new-pw-rejected-generic [3] SEQUENCE {
-                    policy                  [1] SEQUENCE OF UTF8String,
-                    suggested-pw            [2] Password OPTIONAL,
-                    policy-codes            [3] SET OF PW-Quality-Codes
-                                                    OPTIONAL,
-                    ...
-            }
-            op-etype-not-supported     [4] SEQUENCE {
-                    supported-etypes   [1] SEQUENCE OF Etype,
-                    ...
-            },
-            ...
-        },
-        ...
-   }
-
-   -- Set password
-   Req-set-pw        ::= SEQUENCE {
-        languages        [0] SEQUENCE OF Language-Tag OPTIONAL,
-        new-pw                [1] Password OPTIONAL,
-        commit                [2] BOOLEAN DEFAULT TRUE,
-        etypes                [3] SEQUENCE (1..) OF Etype OPTIONAL,
-        ...
-   }
-
-   Rep-set-pw        ::= SEQUENCE {
-        info-text        [0] UTF8String OPTIONAL,
-        new-pw                [1] Password OPTIONAL,
-                                -- generated by the server if present
-                                -- (and requested by the client)
-        etypes                [2] SEQUENCE (1..) OF Etype OPTIONAL,
-        ...
-   }
-
-   Err-set-pw        ::= Err-change-pw
-
-   -- Set keys
-   Req-set-keys      ::= SEQUENCE {
-        keys            [0] SEQUENCE OF Key,
-        commit          [1] BOOLEAN DEFAULT TRUE,
-                                -- TRUE  -> install keys now
-                                -- 
-                                -- FALSE -> require set-keys-commit
-                                --          before issuing tickets
-                                --          encrypted with these keys.
-                                -- 
-                                -- See commit-keys op
-        isupport        [2] KerberosVSupportNego OPTIONAL,
-                                -- For future Kerberos V extensions KDCs
-                                -- may need to know what krb5 version is
-                                -- supported by individual service
-                                -- principals.  This field provides a
-
-N. Williams        						[Page 24]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-                                -- way to tell the KDC what version of
-                                -- Kerberos V the target principal
-                                -- supports.
-        ...
-   }
-
-   Rep-set-keys        ::= SEQUENCE {
-        info-text        [0] UTF8String OPTIONAL,
-        kvno             [1] UInt32,
-        aliases          [2] SEQUENCE OF SEQUENCE {
-                name     [0] PrincipalName,
-                realm    [1] Realm OPTIONAL,
-                ...
-        },
-        isupport         [3] KerberosVSupportNego OPTIONAL,
-        ...
-        -- Should there be ETYPE-INFO2 stuff here?
-   }
-
-   Err-set-keys        ::= SEQUENCE {
-        help-text     [0] UTF8String OPTIONAL, -- Reason for rejection
-        error         [1] CHOICE {
-                op-generic                    [0] Extensible-NULL,
-                op-deferred-commit-no-support [1] Extensible-NULL,
-                op-etype-no-support           [2] SEQUENCE OF {
-                        supported-etypes      [1] SEQUENCE OF Etype,
-                        ...
-                }
-                ...
-        }
-   }
-
-   -- Generate keys
-   Req-gen-keys        ::= SEQUENCE {
-        etypes           [0] SEQUENCE (1..) OF Etype,
-        entropy          [1] OCTET STRING OPTIONAL,
-        commit           [2] BOOLEAN DEFAULT TRUE,
-                                -- TRUE  -> install keys now
-                                -- 
-                                -- FALSE -> require set-keys-commit
-                                --          before issuing tickets
-                                --          encrypted with these keys.
-                                -- 
-                                -- See commit-keys op
-        isupport         [3] KerberosVSupportNego OPTIONAL,
-                                -- For future Kerberos V extensions KDCs
-                                -- may need to know what krb5 version is
-                                -- supported by individual service
-                                -- principals.  This field provides a
-                                -- way to tell the KDC what version of
-                                -- Kerberos V the target principal
-                                -- supports.
-        ...
-
-N. Williams        						[Page 25]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   }
-
-   Rep-gen-keys        ::= SEQUENCE {
-        info-text        [0] UTF8String OPTIONAL,
-        kvno             [1] UInt32,
-        key              [2] Key,
-        aliases          [3] SEQUENCE OF SEQUENCE {
-                name          [0] PrincipalName,
-                realm         [1] Realm OPTIONAL,
-                ...
-        },
-        isupport         [4] KerberosVSupportNego OPTIONAL,
-        ...
-        -- Should there be ETYPE-INFO2 stuff here?
-   }
-
-   Err-gen-keys        ::= Err-set-keys
-
-   -- Get un-committed key request
-   Req-get-keys        ::= SEQUENCE {
-        kvno             [0] UInt32,
-        ...
-   }
-
-   Rep-get-keys        ::= SEQUENCE {
-        info-text        [0] UTF8String OPTIONAL,
-        keys             [1] SEQUENCE OF Key,
-        aliases          [2] SEQUENCE OF SEQUENCE {
-                name          [0] PrincipalName,
-                realm         [1] Realm OPTIONAL,
-                ...
-        },
-        isupport         [3] KerberosVSupportNego OPTIONAL,
-        ...
-        -- Should there be ETYPE-INFO2 stuff here?
-   }
-
-   Err-get-keys      ::= SEQUENCE {
-        help-text      [0] UTF8String OPTIONAL, -- Reason for rejection
-        error          [1] CHOICE {
-                op-generic         [0] Extensible-NULL,
-                op-kvno-committed  [1] Extensible-NULL,
-                op-no-such-kvno    [1] Extensible-NULL,
-                ...
-        }
-   }
-
-   -- Commit a set keys request
-   Req-commit-keys ::= SEQUENCE {
-        kvno         [0] UInt32,
-        ...
-   }
-
-
-N. Williams        						[Page 26]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   Rep-commit-keys ::= Extensible-NULL
-
-   Err-commit-keys ::= SEQUENCE {
-        help-text    [0] UTF8String OPTIONAL, -- Reason for rejection
-        error        [1] CHOICE {
-                op-generic           [0] Extensible-NULL,
-                op-kvno-expired      [1] Extensible-NULL,
-                    -- The client took too long to respond.
-                op-kvno-unknown      [2] Extensible-NULL,
-                    -- The targ princ/kvno is invalid or unknown to the
-                    -- server (perhaps it lost track of state)
-                op-new-keys-conflict [3] Extensible-NULL,
-                    -- A new-keys/commit-keys request subsequent to the
-                    -- new-keys that produced the kvno has completed
-                    -- and incremented the principal's kvno
-                ...
-        }
-        ...
-   }
-
-   -- Get password policy
-   Req-get-pw-policy   ::= Extensible-NULL
-
-   Rep-get-pw-policy   ::= SEQUENCE {
-        policy-name      [0] UTF8String OPTIONAL,
-        description      [1] SEQUENCE OF UTF8String OPTIONAL,
-        ...
-   }
-
-   Err-get-pw-policy   ::= Extensible-NULL
-
-   -- Get principal aliases
-   Req-get-princ-aliases        ::= Extensible-NULL
-
-   Rep-get-princ-aliases        ::= SEQUENCE {
-        help-text    [0] UTF8String OPTIONAL,
-        aliases      [1] SEQUENCE OF SEQUENCE {
-                name      [0] PrincipalName,
-                realm     [1] Realm OPTIONAL,
-                ...
-        },
-        ...
-   }
-
-   Err-get-princ-aliases        ::= Extensible-NULL
-
-   -- Get list of enctypes supported by KDC for new keys
-   Req-get-realm-krb5-support   ::= Extensible-NULL
-
-   Rep-get-realm-krb5-support   ::= SEQUENCE {
-        isupport        [0] KerberosVSupportNego,
-                                -- Version of Kerberos V supported by
-                                -- the target realm.
-
-N. Williams        						[Page 27]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-        ...
-   }
-
-   Err-get-realm-krb5-support   ::= Extensible-NULL
-
-   -- Get s2kparams
-   Req-get-s2kparams            ::= Extensible-NULL
-
-   Rep-get-s2kparams            ::= SEQUENCE {
-        help-text       [0] UTF8String OPTIONAL,
-        s2kparams       [1] SEQUENCE OF Etype-Info-Entry,
-        ...
-   }
-
-   Err-get-s2kparams            ::= Extensible-NULL
-
-   END
-
-
-6  IANA Considerations
-
-   There are no IANA considerations for this document.
-
-7  Security Considerations
-   
-   Implementors and site administrators should note that the redundancy
-   of UTF-8 encodings of passwords varies by language.  Password quality
-   policies SHOULD, therefore, take this into account when estimating
-   the amount of redundancy and entropy in a proposed new password.  [??
-   It's late at night - I think this is correct.]
-
-   Kerberos set/change password/key protocol major version negotiation
-   cannot be done securely; a downgrade attack is possible against
-   clients that attempt to negotiate the protocol major version to use
-   with a server.  It is not clear at this time that the attacker would
-   gain much from such a downgrade attack other than denial of service
-   (DoS) by forcing the client to use a protocol version which does not
-   support some feature needed by the client (Kerberos V in general is
-   subject to a variety of DoS attacks anyways [RFC1510]).  Clients
-   SHOULD NOT negotiate support for legacy major versions of this
-   protocol unless configured otherwise.
-
-   This protocol does not have Perfect Forward Security (PFS).  As a
-   result, any passive network snooper watching password/key changing
-   operations who has stolen a principal's password or long-term keys
-   can find out what the new ones are.
-
-   [More text needed?]
-
-8  Acknowledgements
-   
-   The authors would like to thank Bill GossmanMike Swift, John Brezak,
-   Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W.
-
-N. Williams        						[Page 28]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-   Nelson, Marcus Watts, Love, Joel N.  Weber II, Jeffrey Hutzelman and
-   other participants from the IETF Kerberos Working Group for their
-   assistance.
-
-9  References
-
-9.1  Normative References
-
-   [RFC2026]
-      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
-      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
-      Practice.
-
-   [RFC2119]
-      S. Bradner, RFC2119 (BCP14):  "Key words for use in RFCs to
-      Indicate Requirement Levels," March 1997, Status: Best Current
-      Practice.
-
-   [X680]
-      Abstract Syntax Notation One (ASN.1): Specification of Basic
-      Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
-      International Standard 8824-1:1998.
-      http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf
-
-   [X690]
-      ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
-      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
-      (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
-      Standard 8825-1:1998.
-      http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf
-
-   [clarifications]
-      RFC-Editor: To be replaced by RFC number for
-      draft-ietf-krb-wg-kerberos-clarifications.
-
-   [RFC3066]
-      H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of
-      Languages," January 2001, Obsoletes RFC1766, Status: Best Current
-      Practice.
-
-9.2  Informative References
-
-   [RFC3244]
-      M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000
-      Kerberos Change Password and Set Password Protocols," February
-      2002, Status: Informational.
-
-10  Authors' Addresses
-
-      Nicolas Williams
-      Sun Microsystems
-      5300 Riata Trace Ct
-      Austin, TX 78727
-
-N. Williams        						[Page 29]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-      Email: nicolas.williams@sun.com
-
-
-11  Notes to the RFC Editor
-
-   This document has two KRB WG drafts as normative references and
-   cannot progress until those drafts progress, but no other draft
-   depends on this one.
-
-12  Change History
-
-    -01 -> -02
-
-     - Removed Bill Gossman, Mike Swift and John Brezak as authors.
-
-     - Removed UDP as a transport for this protocol.
-
-     - Replaced redundant copies of framing ASCII art with reference to
-       RFC3244.
-
-     - Made all name/password strings UTF8String with an extensible
-       constraint to IA5String.
-
-     - Added a method for doing dry runs of operations.  This is helpful
-       in testing passwords against password quality policies.
-
-     - Added an operation for retrieving a principal's current and
-       preferred string-to-key parameters, and a way to change them
-       without changing the principal's password.
-
-     - Added password quality codes as hints for smart clients, but
-       these are optional and not to be used instead of messages to be
-       displayed to useds.
-
-     - Added a 'commit' option to change-pw and set-pw (as requested by
-       Larry).
-
-     - Removed "version" field of the Kerberos V feature negotiation
-       struture.
-
-
-
-N. Williams        						[Page 30]
-
-
-DRAFT		Kerberos Set/Change Password v2		Expires January 2005
-
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                Expires August 22, 2005                [Page 31]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-04.txt b/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-04.txt
deleted file mode 100644
index b8547195e..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-04.txt
+++ /dev/null
@@ -1,1787 +0,0 @@
-
-Kerberos Working Group                                  Nicolas Williams
-INTERNET-DRAFT                                          Sun Microsystems
-Expires: August 22, 2005                                    October 2005
-
-
-
-
-                Kerberos Set/Change Password: Version 2
-              <draft-ietf-krb-wg-kerberos-set-passwd-04.txt>
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 17, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document specifies an extensible protocol for setting keys and
-   changing the passwords of Kerberos V principals.
-
-Table of Contents
-
-   1  Introduction
-   2  The Protocol
-   2.1  Transports 
-   2.2  Protocol Framing
-   2.3  Protocol version negotiation
-   2.3.1  Protocol Major Version Negotiation
-   2.3.2  Protocol Minor Version Negotiation
-   2.4  Use of Kerberos V
-
-N. Williams        						[Page 1]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-   2.5  Use of ASN.1
-   2.6  Internationalization
-   2.6.1  Normalization Forms for UTF-8 Strings
-   2.6.2  Language Negotiation
-   2.7  Protocol Extensibility
-   2.8  Protocol Subsets
-   3  Protocol Elements
-   3.1  PDUs
-   3.2  Operations
-   3.2.1  Null
-   3.2.2  Change Kerberos Password
-   3.2.3  Set Kerberos Password
-   3.2.4  Set Kerberos Keys
-   3.2.5  Generate Kerberos Keys
-   3.2.6  Get New Keys
-   3.2.7  Commit New Keys
-   3.2.8  Get Password Quality Policy
-   3.2.9  Get Principal Aliases
-   3.2.10  Get Realm's Supported Kerberos V Version and Features
-   4  ASN.1 Module
-   6  IANA Considerations
-   7  Security Considerations
-   8  Acknowledgements
-   9  References
-   9.1  Normative References
-   9.2  Informative References
-   10  Authors' Addresses
-   11  Notes to the RFC Editor
-
-Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-1  Introduction
-
-   Up to this point Kerberos V has lacked a single, standard protocol
-   for changing passwords and keys.  While several vendor-specific
-   protocols exist for changing Kerberos passwords/keys, none are
-   properly internationalized and all are incomplete in one respect or
-   another and none are sufficiently extensible to cope with new
-   features that may be added to Kerberos V at some future time.
-
-   This document defines a protocol that is somewhat backward-compatible
-   with the "kpasswd" protocol defined in [RFC3244] that uses more or
-   less the same protocol framing.
-
-   This new protocol is designed to be extensible and properly
-   internationalized.
-
-2  The Protocol
-
-
-N. Williams        						[Page 2]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-   The structure of the protocol is quite similar to that of typical RPC
-   protocols.  Each transaction consists of a data structure specific to
-   an operation which is then wrapped in a data structure which is
-   general to all operations of the protocol.  These data structures are
-   defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they
-   are encoded using the Distinguished Encoding Rules (DER) [X690].
-
-   All protocol data is wrapped KRB-PRIV messages, or, in some cases, a
-   KRB-ERROR, and framed in a header that is backwards compatible with
-   [RFC3244].
-
-2.1  Transports 
-
-   The service supports only connection-oriented transports,
-   specifically TCP, and MUST accept requests on TCP port 464, the same
-   as in [RFC3244].
-
-2.2  Protocol Framing
-
-   Requests and responses are exchanged using the same framing as in
-   [RFC3244], but with the following differences:
-
-    - the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1)
-
-    - the 'AP-REQ length' field of the request can be set to 0x0, in
-      which case the 'AP-REQ' field of the request is excluded
-
-    - the 'KRB-PRIV' field of the request and reply is mutually
-      exclusive with the 'AP-REQ' field of the request
-
-    - the 'AP-REP length' field of the reply can be set to 0x0, in
-      which case the 'AP-REP' field of the reply is excluded
-
-    - all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can
-      be or has been accepted by the server
-
-    - any KRB-ERROR messages are framed and sent in the 'AP-REP' field
-      of the reply
-
-   The initial message from the client MUST carry an AP-REQ and the
-   response to any request bearing an AP-REQ MUST carry an AP-REP or
-   MUST be a KRB-ERROR.
-
-   Subsequent messages exchanged on the same TCP connection MAY involve
-   Kerberos V AP exchanges, but generally the client SHOULD NOT initiate
-   a new AP exchange except when it desires to authenticate as a
-   different principal, when the ticket last used for authentication
-   expires or when the server responds with an error indicating that the
-   client must re-authenticate.
-
-2.3  Protocol Version Negotiation
-
-   There are several major versions of this protocol.  Version 2 also
-
-N. Williams        						[Page 3]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-   introduces a notion of protocol minor versions for use in negotiating
-   protocol extensions.  As of this time only one minor version is
-   defined for major version 2: minor version 0, defined herein.
-
-2.3.1  Protocol Major Version Negotiation
-
-   Version 2 clients that also support other versions, such as 0xff80,
-   as in [RFC3244], SHOULD attempt to use version 2 of the protocol
-   first.
-
-   Servers which do not support version 2 of this protocol typically
-   include their preferred version number in the reply and/or may
-   include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a
-   status code of KRB5_KPASSWD_MALFORMED.
-
-   Note that some [RFC3244] server implementations close the TCP
-   connection without returning any other response.  Note also that
-   there is no integrity protection for the major version number in the
-   protocol framing or for any data in a KRB-ERROR.
-
-   As a result change password protocol major version negotiation is
-   subject to downgrade attacks.  Therefore major version negotiation is
-   NOT RECOMMENDED.
-
-   Where the server indicates that it does not support version 2, the
-   client MAY, but SHOULD NOT, unless configured to do so, fall back on
-   another major version of this protocol.
-
-   Version 2 servers MAY respond to non-v2 requests using whatever
-   response is appropriate for the versions used by the clients, but if
-   a server does not do this or know how to do this then it MUST respond
-   with an error framed as in section 2.2, using an AP-REP and KRB-PRIV
-   if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and
-   using a ProtocolErrorCode value of unsupported-major-version.
-
-   It is expected that implementations of as yet unspecified future
-   major versions of this protocol will be required to support version 2
-   integrity protected error replies for properly indicating no support
-   for version 2 of the protocl.  We also hope that no further major
-   versions of this protocol will be needed.
-
-2.3.2  Protocol Minor Version Negotiation
-
-   Version 2 clients are free to use whatever protocol minor version and
-   message extensions are available to them in their initial messages to
-   version 2 servers, provided that the minor versions (other than 0)
-   have been defined through IETF documents.
-
-   Version 2 servers MUST answer with the highest protocol minor version
-   number supported by the server and the client.
-
-   Version 2 clients MUST use the protocol minor version used in a
-   server's reply for any subsequent messages in the same TCP session.
-
-N. Williams        						[Page 4]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-
-   See section 2.7 for further description of the protocol's
-   extensibility and its relation to protocol minor versions and the
-   negotiation thereof.
-
-2.4  Use of Kerberos V and Key Exchange
-
-   This protocol makes use of messages defined in [RFC1510] and
-   [clarifications].  Specifically, AP-REQ, AP-REP, KRB-ERROR and
-   KRB-PRIV.
-
-   All operations are to be performed by the server on behalf of the
-   client principal.
-
-   Clients SHOULD use "kadmin/setpw" as the principal name of the server
-   for all requests except when changing the client principal's own
-   expired password, for which they should use "kadmin/changepw".  The 
-   "kadmin/changepw" service exists to allow KDCs to limit principals
-   with expired passwords to getting initial tickets to the password
-   changing service only and only for changing expired passwords.
-
-   Servers MUST limit clients that used the "kadmin/changepw" service
-   principal name to changing the password of the client principal.
-
-   The client MUST request mutual authentication and the client MUST
-   MUST request the use of sequence numbers.
-
-   Clients SHOULD use INITIAL tickets for requests whose target
-   principal is the client's principal.  Servers SHOULD force the use of
-   INITIAL tickets for such requests and MAY force the use of INITIAL
-   for all others - see section 3.2.
-
-   Servers MUST specify a sub-session key.
-
-   The encrypted part of KRB-PRIVs MUST be encrypted with the server's
-   sub-session key and key usage 20 (client->server) or 21
-   (server->client).
-
-   After each new AP exchange the client and server MUST destroy the
-   session keys, if any, resulting from the previous AP exchange.
-
-2.5  Use of ASN.1
-
-   This protocol's messages are defined in ASN.1, using only features
-   from [X680].  All ASN.1 types defined herein are to be encoded in
-   DER [X690].  A complete ASN.1 module is given in section 4.
-
-   The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
-   KRB-PRIV as described above and/or as e-data in KRB-ERROR messages.
-
-2.6  Internationalization
-
-   This protocol's request PDU carries an optional field indicating the
-
-N. Williams        						[Page 5]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-   languages spoken by the client user; the client SHOULD send its list
-   of spoken languages to the server (once per-TCP session).
-
-   The server SHOULD localize all strings intended for display to users
-   to a language in common with the languages spoken by the client user.
-
-   Strings for Kerberos principal and realm names used in this protocol
-   are be constrained as per [clarifications].
-
-2.6.1  Normalization Forms for UTF-8 Strings
-
-   Because Kerberos V [clarifications] restricts principal names, realm
-   names and passwords to IA5String, this protocol uses UTF8String with
-   an extensible constraint to IA5String.
-
-   Future versions of Kerberos may relax this constraint; if so then a
-   minor version of this protocol should relax this constraint
-   accordingly.
-
-2.6.2  Language Negotiation
-
-   The server MUST pick a language from the client's input list or
-   the default language tag (see [RFC3066]) for text in its responses
-   which is meant for the user to read.
-
-   The server SHOULD use a language selection algorithm such that
-   consideration is first given to exact matches between the client's
-   spoken languages and the server's available locales, followed by
-   "fuzzy" matches where only the first sub-tags of the client's
-   language tag list are used for matching against the servers available
-   locales.
-
-   Servers MUST cache the optional language tag lists from prior
-   requests for use with subsequent requests that exclude the language
-   tag list.  Clients MAY expect such server behaviour and send the
-   language tag lists only once per-TCP session.  Clients SHOULD send
-   the server the language tag list at least once.
-
-   When the server has a message catalog for one of the client's spoken
-   languages the server SHOULD localize any text strings intended for
-   display to users.
-
-2.7  Protocol Extensibility
-
-   The protocol is defined in ASN.1 and uses extensibility markers
-   throughout.  As such, the module presented herein can be extended
-   within the framework of [X680].
-
-   Typed holes are not used in this protocol as it is very simple and
-   does not require the ability to deal with abstract data types defined
-   in different layers.  For this reason, the only way to extend this
-   protocol is by extending the ASN.1 module within the framework of the
-   IETF; all future extensions to this protocol have to be defined in
-
-N. Williams        						[Page 6]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-   IETF documents unless otherwise specified in a future IETF revision
-   of this protocol.
-
-   A protocol minor version number is used to negotiate use of
-   extensions.  See section 2.3.2 for the minor version negotiation.
-
-   Servers SHOULD ignore unknown additions to the ASN.1 types, in
-   initial requests, where the syntax allows them, except for extensions
-   to the "Op-req" type, which MUST result in an error.
-
-   Servers MUST respond with an error (ProtocolErrorCode value of
-   unsupported-minor-version) to clients that use operations unknown to
-   the server.
-
-2.8  Protocol Subsets
-
-   The structure of the protocol is such that the ASN.1 syntaxes for the
-   various operations supported by the protocol are independent of the
-   each other.  Client and server implementations MAY implement subsets
-   of the overall protocol by removing some alternatives to the Op-req,
-   Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4.
-   
-   For example, it should be possible to have a password-change only
-   client that cannot set principal's keys - and vice versa.
-
-3  Protocol Elements
-
-   The protocol as defined herein supports the following operations
-   relating to the management of Kerberos principal's passwords or keys:
-
-     [NOTE:  New since last version of this I-D.]
-     - get principal's current and preferred string-to-key parameters
-
-     - change password (or enctypes and string-to-key parameters)
-     - set password (administrative)
-     - set new keys
-     - generate new keys
-     - get new, un-committed keys
-     - commit new keys
-     - get password policy name and/or description of principal
-     - list aliases of a principal
-     - list enctypes and version of Kerberos V supported by realm
-
-   The operation for retrieving a list of aliases of a principal is
-   needed where KDCs implement aliasing of principal names and allows
-   clients to properly setup their key databases when principal aliasing
-   is in use.
-
-   Operations such as creation or deletion of principals are outside the
-   scope of this document, and should be performed via other means, such
-   as through directories or other Kerberos administration protocols.
-
-   The individual operations are described in section 3.2.
-
-N. Williams        						[Page 7]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-
-3.1  PDUs
-
-   The types "Request," "Response" and "Error-Response" are the ASN.1
-   module's PDUs.
-
-   The "Request" and "Response" PDUs are always to be sent wrapped in
-   KRB-PRIV messages, except for the "Error-Response" PDU which MUST be
-   sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail,
-   otherwise it MUST be sent wrapped in a KRB-PRIV.
-
-   The ASN.1 syntax for the PDUs is given in section 4.
-
-   Note that the first field of each PDU is the major version of the
-   protocol, defaulted to 2, meaning that it is never included in
-   version 2 exchanges.  Similarly, the second field of each PDU is the
-   minor version, defaulted to 0.
-
-   The request, responses and error PDUs consist of an outer structure
-   ("Request," "Response" and "Error-Response") containing fields common
-   to all requests, responses and errors, respectively, and an inner
-   structure for fields that are specific to each operation's
-   requests/responses.  The inner structure is optional in the case of
-   the Error-Response PDU and need not be included when generic errors
-   occur for which there is a suitable ProtocolErrorCode.
-
-   Specifically, the outer Request structure has a field for passing a
-   client user's spoken (read) languages to the server.  It also has two
-   optional fields for identifying the requested operation's target
-   principal's name and realm (if not sent then the server MUST use the
-   client's principal name and realm as the target).  A boolean field
-   for indicating whether or not the request should be dry-run is also
-   included; dry-runs can be used to test server policies, and servers
-   MUST NOT modify any principals when processing dry-run requests.
-
-   The Response and Error PDUs' outer structures include a field
-   indicating the language that the server has chosen for localization
-   of text intended to be displayed to users; this field is defaulted to
-   "i-default".  This language tag applies to all UTF8 strings in the
-   inner structure (Op-rep and Op-err) that are meant to be displayed to
-   users.
-
-   The protocol error codes are:
-
-      - proto-generic-error
-
-        An operation-specific error ocurred, see the inner Op-error.
-
-      - proto-format-error
-      - proto-unsupported-major-version
-      - proto-unsupported-minor-version
-      - proto-unsupported-operation
-
-
-N. Williams        						[Page 8]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-      - proto-wrong-service-principal
-
-        Use kadmin/setpw for the server's principal name.
-
-      - proto-re-authentication-required
-
-        The server demands that the client re-authenticate through a new
-        AP exchange.
-
-      - proto-initial-ticket-required
-
-        Use of an INITIAL ticket is required for the requested
-        operation.
-
-      - proto-client-and-target-realm-mismatch
-
-        The server requires that the client's principal name and the
-        target principal of the operation share the same realm name.
-
-      - proto-target-principal-unknown
-      - proto-authorization-failed
-
-3.2  Operations
-
-   This section describes the semantics of each operation request and
-   response defined in the ASN.1 module in section 4.
-      
-3.2.1  Null
-
-   NAME
-
-      null - Null or "ping" operation
-
-   DESCRIPTION
-
-      The null request is intended for use with TCP; its purpose is
-      similar to RPC null procedures and is akin to a "ping" operation.
-
-   ERRORS
-
-      None.
-
-3.2.2  Change Kerberos Password
-
-   NAME
-
-      change-pw - Change password operation
-
-   SYNOPSIS
-
-      Req-change-pw(old-pw, [languages], [new-pw],
-                    [commit], [etypes]) ->
-         Rep-change-pw([info-text], [new-pw], [etypes]) |
-
-N. Williams        						[Page 9]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-         Err-change-pw([help-text], error code, [error info])
-
-   DESCRIPTION
-
-      Change a principal's password.
-
-      The change password request has one required, three optional and
-      one defaulted arguments: "old-pw" (required), "languages,"
-      "new-pw", "commit" (defaults to "TRUE") and "etypes",
-      corresponding to the target principal's old password, its
-      preferred languages, its new password, a boolean indicating
-      whether or not to make the new long-term key available for
-      immediate use, and the desired enctypes for the new long-term
-      keys.
-
-      The server MUST validate the old password and MUST check the
-      quality of the new password, if sent, according the password
-      quality policy associated with the target principal.
-
-      If the old and new passwords in the request are the same strings,
-      and the principal is not currently required to change its
-      password, then the server MAY permit the password change as way to
-      change a principal's enctypes and string-to-key parameters.  This
-      feature provides a way to, for example, add enctypes to a
-      principals' password-derived long-term keys without forcing a
-      password change following an upgrade to the KDC that adds support
-      for new enctypes.
-
-      A client MAY request that the server generate a new password by
-      excluding the new password from its request, in which case the
-      server MUST either generate a new password or respond with an
-      error indicating that it does not support this feature.
-
-      Server-generated passwords MUST meet the target principal's
-      password quality policy.  It is RECOMMENDED that server-generated
-      passwords be user-friendly, that is, memorable and that the target
-      principal's preferred languages be taken into account by the
-      password generation alogrithm used by the server.
-
-      Uncommitted password changes are commited using the commit-keys
-      operation.
-
-   RETURN
-
-      Upon successful password changes the server responds with a
-      Rep-change-pw.  The fields of Rep-change-pw are all optional and
-      include:
-
-         - 'info-text' which the server can use to send a message to the
-           user such as "Your new password will expire in 90 days," for
-           example.
-
-         - 'new-pw' which the server MUST include if the client
-
-N. Williams        						[Page 10]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-           requested that the server generate a new password; generated
-           passwords MUST pass the target principal's password quality
-           policy.
-
-         - 'etypes' which the server MAY include to indicate which types
-           of long-term keys it created for the target principal and
-           which the server MUST include if the client specified a set
-           of enctypes in its request.
-
-   ERRORS
-
-      The server may respond to change password requests with protocol
-      or operation errors.  See section 3.1 for a description of
-      protocol error codes.
-
-      All operation errors include an optional 'help-text' field by
-      which the server can describe the error in a human-readable,
-      localizaed string.
-
-      Change password error codes include:
-
-         - generic-error
-
-         - old-pw-incorrect
-
-         - wont-generate-new-pw
-
-           The server will not generate a new password for this
-           principal or does not support password generation in general.
-
-         - new-pw-rejected-generic
-
-           The client's proposed new password failed the target
-           principal's password quality policy.
-
-           The server MUST include a description of the password quality
-           policy or aspect of it that the client's proposed new
-           password failed to meet.
-
-           The server MAY generate and send a new password that the
-           client can then use as a new password and which is guaranteed
-           to pass the target principal's current password quality
-           policy.
-
-           The server MAY include a set of policy error code hints.
-
-         - etype-not-supported
-
-           The client requested an enctype that the KDC does not
-           support.
-
-3.2.3  Set Kerberos Password
-
-
-N. Williams        						[Page 11]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-   NAME
-
-      set-pw - Set password operation
-
-   SYNOPSIS
-
-      Req-set-pw([languages], [new-pw], [commit], [etypes]) ->
-         Rep-set-pw([info-text], [new-pw], [etypes]) |
-         Err-set-pw([help-text], error code, [error info])
-
-   DESCRIPTION
-
-      Administratively set a principal's password.
-
-      The set password request has three optional and one defaulted
-      arguments: "languages", "new-pw," "commit" (defaulted to "TRUE")
-      and "etypes", corresponding to the target principal's preferred
-      languages, new password, a boolean indicating whether or not to
-      make the new long-term key available for immediate use, and the
-      desired enctypes for the new long-term keys.
-
-      The server MUST check the quality of the new password, if sent,
-      according the password quality policy associated with the target
-      principal.
-
-      The server SHOULD require that the client use the change-pw
-      operation instead of set-pw when the client principal and the
-      target principal are the same.
-
-      A client MAY request that the server generate a new password by
-      excluding the new password from its request, in which case the
-      server MUST either generate a new password or respond with an
-      error indicating that it does not support this feature.
-
-      Server-generated passwords MUST meet the target principal's
-      password quality policy.  It is RECOMMENDED that server-generated
-      passwords be user-friendly, that is, memorable and that the target
-      principal's preferred languages be taken into account by the
-      password generation alogrithm used by the server.
-
-   RETURN
-
-      Upon successfully setting a password the server responds with a
-      Rep-set-pw.  The fields of Rep-set-pw are all optional and
-      include:
-
-         - 'info-text' which the server can use to send a message to the
-           user such as "Your new password will expire in 90 days," for
-           example.
-
-         - 'new-pw' which the server MUST include if the client
-           requested that the server generate a new password; generated
-           passwords MUST pass the target principal's password quality
-
-N. Williams        						[Page 12]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-           policy.
-
-         - 'etypes' which the server MAY include to indicate which types
-           of long-term keys it created for the target principal and
-           which the server MUST include if the client specified a set
-           of enctypes in its request.
-
-   ERRORS
-
-      The server may respond to set password requests with protocol or
-      operation errors.  See section XYZ for a description of protocol
-      error codes.
-
-      All operation errors include an optional 'help-text' field by
-      which the server can describe the error in a human-readable,
-      localizaed string.
-
-      Set password error codes include:
-
-         - generic-error
-
-         - use-change-pw
-
-           The server demands that the client use the change-pw
-           operation for the target principal of the set-pw request.
-
-         - wont-generate-new-pw
-
-           The server will not generate a new password for this
-           principal or does not support password generation in general.
-
-         - new-pw-rejected-generic
-
-           The client's proposed new password failed the target
-           principal's password quality policy.
-
-           The server MUST include a description of the password quality
-           policy or aspect of it that the client's proposed new
-           password failed to meet.
-
-           The server MAY generate and send a new password that the
-           client can then use as a new password and which is guaranteed
-           to pass the target principal's current password quality
-           policy.
-
-           The server MAY include a set of policy error code hints.
-
-         - etype-not-supported
-
-           The client requested an enctype that the KDC does not
-           support.
-
-3.2.4  Set Kerberos Keys
-
-N. Williams        						[Page 13]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-
-   NAME
-
-      set-keys
-
-   SYNOPSIS
-
-      Req-set-keys(new-keys, commit?, [isupport]) ->
-         Rep-set-keys([info-text], kvno, aliases, [isupport])
-
-   DESCRIPTION
-
-      The set-keys request consists of two required fields and one
-      optional field: "new-keys", "commit" (a boolean field - see below)
-      and "isupport", an optional field for indicating to the KDC what
-      Kerberos V features are supported by the target principal.
-
-      When "commit" is true the KDC makes the new keys available for
-      issueing tickets encrypted in them immediately.  Otherwise the
-      client MUST follow up with a commit-keys request to make the keys
-      available.  This feature is useful for changing keys shared by
-      multiple hosts, in clustered services, for example, in an atomic
-      manner; see section 3.2.6 and 3.2.7.
-
-      If a principal has keys are awaiting commitment when a new
-      set-keys request for that principal s made then the KDC MUST
-      overwrite the deferred keys.
-
-   RETURN
-
-      For successful set-keys operations the server returns:
-
-         - Informational text, optional.
-
-         - The new kvno for the target principal.
-
-         - A list of aliases of the target principal known to the KDC
-           (optional).
-
-         - The set of Kerberos V features supported by the KDC
-           (optional).
-
-   ERRORS
-
-      The server may respond with the following errors:
-
-         - generic
-         - deferred-commit-no-support
-         - etype-no-support
-
-3.2.5  Generate Kerberos Keys
-
-   NAME
-
-N. Williams        						[Page 14]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-
-      gen-keys
-
-   SYNOPSIS
-
-      Req-gen-keys(etypes, [entropy], commit?, [isupport]) ->
-         Rep-set-keys([info-text], key, kvno, aliases, [isupport])
-
-   DESCRIPTION
-
-      The gen-keys is similar to the set-keys request (see section
-      3.2.4) but differs in that the server generates keys of
-      client-requested enctypes, rather than the client providing
-      specific keys.
-
-      The gen-keys request consists of two required fields and two
-      optional fields: "etypes" (the enctypes of the new keys),
-      "entropy", "commit" and "isupport" (see section 3.2.4).
-
-      If a principal has keys are awaiting commitment when a new
-      set-keys request for that principal s made then the KDC MUST
-      overwrite the deferred keys.
-
-   RETURN
-
-      For successful set-keys operations the server returns:
-
-         - Informational text, optional.
-
-         - The new kvno for the target principal.
-
-         - The new key (only one is needed).
-
-         - A list of aliases of the target principal known to the KDC
-           (optional).
-
-         - The set of Kerberos V features supported by the KDC
-           (optional).
-
-   ERRORS
-
-      The server may respond with the following errors:
-
-         - generic
-         - deferred-commit-no-support
-         - etype-no-support
-
-3.2.6  Get New Keys
-
-   NAME
-
-      get-keys
-
-
-N. Williams        						[Page 15]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-   SYNOPSIS
-
-      Req-get-keys(kvno) ->
-         Rep-get-keys([info-text], keys, aliases, [isupport]) |
-         Err-get-keys([help-text], error code, [error info])
-
-   DESCRIPTION
-
-      This request allows a client to get the keys set or generated in a
-      previous set-keys or gen-keys request with deferred commitment..
-
-   RETURN
-
-      If the target principal and kvno correspond to uncommitted keys
-      the server MUST respond with the actual keys that would be set by
-      a subsequent commit-keys request.  Otherwise the server MUST
-      respond with an error (meaning that this operation cannot be used
-      to extract keys from the KDC that may be in use).
-
-   ERRORS
-
-         - generic
-         - kvno-committed
-         - no-such-kvno
-
-3.2.7  Commit New Keys
-
-   NAME
-
-      commit-keys
-
-   SYNOPSIS
-
-      Req-commit-keys(kvno) ->
-         Rep-commit-keys() |
-         Err-commit-keys([help-text], error code, [error info])
-
-   DESCRIPTION
-
-      The commit-keys operation allows a client to bring a principal's
-      new keys into use at the KDC.
-
-      Clients should make a commit-keys request corresponding to a
-      deferred commitment set-keys/gen-keys operation as soon as the
-      local key database for the target principal is updated.
-
-      The target principal name and the kvno MUST match those from a
-      prior set-keys or gen-keys operation.
-
-      Servers MAY expire delayed key commitments at will.  Servers
-      SHOULD expire uncommitted new keys after a reasonable amount of
-      time (600 seconds is RECOMMENDED).
-
-
-N. Williams        						[Page 16]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-      Servers MUST respond to new set-keys requests for principals with
-      pending, uncommitted new keys by expiring the uncommitted new keys
-      and proceeding as if there had been no expired new keys.
-
-   ERRORS
-
-      - generic
-      - op-kvno-expired
-      - op-kvno-unknown
-      - new-keys-conflict (A set-keys or gen-keys request succeeded
-                           subsequent to the request that matches this
-                           {principal, kvno} tuple.)
-
-3.2.8  Get Password Quality Policy
-   
-   NAME
-
-      get-pw-policy
-
-   SYNOPSIS
-
-      Req-get-pw-policy() ->
-         Rep-get-pw-policy([policy name], [policy description])
-
-   DESCRIPTION
-
-      Returns a description of the target principal's associated
-      password quality policy, if any, as a list of localized
-      UTF8String values.
-
-      Clients can use this operation in conjunction with the change-pw
-      operation to obtain text that can be displayed to the user before
-      the user actually enters a new password.
-
-      It is common for sites to set policies with respect to password
-      quality.  It is beyond the scope of this document to describe such
-      policies.  Management of password quality policies' actual content
-      is also beyond the scope of this protocol.
-
-   ERRORS
-
-      No operation errors are defined.
-
-
-3.2.9  Get Principal Aliases
-   
-   NAME
-
-      get-print-aliases
-
-   SYNOPSIS
-
-      Req-get-princ-aliases() ->
-
-N. Williams        						[Page 17]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-         Rep-get-princ-aliases(aliases)
-
-   DESCRIPTION
-
-      Returns a list of aliases of the target principal.
-
-   ERRORS
-
-      No operation-specific errors.
-
-3.2.10  Get Realm's Supported Kerberos V Version and Features
-   
-   NAME
-
-      get-realm-krb5-support
-
-   SYNOPSIS
-
-      Req-get-realm-krb5-support() ->
-         Rep-get-realm-krb5-support(isupport)
-
-   DESCRIPTION
-
-      Returns set of Kerberos V features support by the target
-      principal's realm's KDCs.
-
-   ERRORS
-
-      No operation-specific errors.
-
-3.2.11  Retrieve Principal's S2K Params and Preferred Params
-   
-   NAME
-
-      get-s2kparams
-
-   SYNOPSIS
-
-      Req-get-s2kparams() ->
-         Rep-get-s2kparams([princ-s2kparams], [preferred-s2kparams])
-
-   DESCRIPTION
-
-      Returns the string2key parameters for the principal's current
-      password-derived long-term keys, if any, and the parameters that
-      the realm would prefer, if they differ from the former.
-
-      This operation is intended for use with the change-pw() operation.
-      When surprised by a KDC's PA-ETYPE-INFO2 a client SHOULD check if
-      the principal's long-term secret keys' string2key parameters (and
-      enctype list) should be changed and, if so, change them.
-
-      If the 'princ-s2kparams' return value is missing then the
-
-N. Williams        						[Page 18]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-      principal does not have a password-derived long-term key.
-
-      The 'preferred-s2kparams' MUST be excluded if the principal's
-      string2key parameters satisfy the realm's policy.
-
-   ERRORS
-
-      No operation-specific errors.
-
-3.3  Principal Aliases
-
-   Applications that use Kerberos often have to derive acceptor
-   principal names from hostnames entered by users.  Such hostnames may
-   be aliases, they may be fully qualified, partially qualified or not
-   qualified at all.  Some implementations have resorted to deriving
-   principal names from such hostnames by utilizing the names services
-   to canonicalize the hostname first; such practices are not secure
-   unless the name service are secure, which often aren't.
-
-   One method for securely deriving principal names from hostnames is to
-   alias principals at the KDC such that the KDC will issue tickets for
-   principal names which are aliases of others.  It is helpful for
-   principals to know what are their aliases as known by the KDCs.
-
-   Note that changing a principal's aliases is out of scope for this
-   protocol.
-
-3.4  Kerberos V Feature Negotiation
-
-   Principals and realms' KDCs may need to know about additional
-   Kerberos V features and extensions that they each support.  Several
-   operations (see above) provide a way for clients and servers to
-   exchange such infomration, in the form of lists of types supported
-   for the various typed holes used in Kerberos V.
-
-4  ASN.1 Module
-
-   DEFINITIONS EXPLICIT TAGS ::= BEGIN
-   -- 
-   -- Note:  EXPLICIT tagging is in use by default throughout this
-   --        module.
-
-   -- From [clarifications] with modifications
-   PrincipalName            ::= SEQUENCE {
-        name-string [1] SEQUENCE OF UTF8String (IA5String, ...)
-   }
-   Realm                    ::= UTF8String (IA5String, ...)
-   Salt                     ::= UTF8String (IA5String, ...)
-   Password                 ::= UTF8String (IA5String, ...)
-
-   -- NOTE WELL: Principal and realm names MUST be constrained by the
-   --            specification of the version of Kerberos V used by the
-   --            client.
-
-N. Williams        						[Page 19]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-   -- 
-   -- [Perhaps PrincipalName should be a SEQUENCE of an optional name
-   --  type and a UTF8String, for simplicity.]
-
-   -- From [clarifications]
-   Int32            ::= INTEGER (-2147483648..2147483647)
-   UInt32           ::= INTEGER (0..4294967295)
-
-   -- Based on [clarifications]
-   Etype            ::= Int32
-   Etype-Info-Entry ::= SEQUENCE {
-        etype           [0] Etype,
-        salt            [1] Salt OPTIONAL,
-        s2kparams       [2] OCTET STRING OPTIONAL,
-        ...
-   }
-   Key              ::= SEQUENCE {
-        enc-type        [0] Etype,        -- from Kerberos
-        key             [1] OCTET STRING,
-        ...
-   }
-
-   Language-Tag     ::= UTF8String -- Constrained by [RFC3066]
-
-   -- Empty, extensible SEQUENCEs are legal ASN.1
-   Extensible-NULL  ::= SEQUENCE {
-        ...
-   }
-
-   -- Kerberos clients negotiate some parameters relating to their peers
-   -- indirectly through the KDC.  Today this is true of ticket session
-   -- key enctypes, but in the future this indirect negotiation may also
-   -- occur with respect to the minor version of Kerberos V to be used
-   -- between clients and servers.  Additionally, KDCs may need to know
-   -- what authorization-data types are supported by service principals,
-   -- both, for compatibility with legacy software and for optimization.
-   --
-   -- Thesefore it is important for KDCs to know what features of
-   -- Kerberos V each service principal supports.
-   --
-   -- In version 2.0 of this protocol the clients and servers may notify
-   -- each other of their support for:
-   --
-   --  - enctypes
-   --  - authorization data types
-   --  - transited encoding data types
-   --
-   -- All authorization-data types defined in [clarifications] are
-   -- assumed to be supported if the minor version is 1 and do not need
-   -- to be included in the ad-type list.
-   --
-   -- Int32 is used for enctype and transited encoding data type
-   -- identifiers.
-
-N. Williams        						[Page 20]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-   --
-   -- An extensible CHOICE of Int32 is used for authorization data
-   -- types.
-
-   KerberosV-TR-ID             ::= Int32
-
-   KerberosV-AD-ID             ::= CHOICE {
-        ad-int                [0] Int32,
-        ...
-   }
-
-   KerberosVSupportNego        ::= SEQUENCE {
-        enc-types       [0] SEQUENCE OF Etype,
-        ad-types        [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL,
-                                    -- authorization data types
-        tr-enc-types    [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL,
-                                    -- transited encoding types
-        ...
-   }
-
-   Request                     ::= [APPLICATION 0] SEQUENCE {
-        pvno-minor      [0] INTEGER DEFAULT 0,
-        languages       [1] SEQUENCE OF Language-Tag OPTIONAL,
-                -- Should be defaulted to the SEQUENCE of "i-default"
-        targ-name       [2] PrincipalName OPTIONAL,
-        targ-realm      [3] Realm OPTIONAL,
-                -- If targ-name/realm are missing then the request
-                -- applies to the principal of the client
-        dry-run         [4] BOOLEAN DEFAULT FALSE,
-        operation       [5] Op-req,
-        ...
-   }
-
-   Response                    ::= [APPLICATION 1] SEQUENCE {
-        pvno-minor      [0] INTEGER DEFAULT 0,
-        language        [1] Language-Tag DEFAULT "i-default",
-        result          [2] Op-rep,
-        ...
-   }
-
-   Error-Response              ::= [APPLICATION 2] SEQUENCE {
-        pvno-minor      [0] INTEGER DEFAULT 0,
-        language        [1] Language-Tag DEFAULT "i-default",
-        error-code      [2] ProtocolErrorCode,
-        help-text       [3] UTF8String OPTIONAL,
-        op-error        [4] Op-err OPTIONAL,
-        ...
-   }
-
-   Op-req                      ::= CHOICE {
-        null                     [0] Req-null,
-        change-pw                [1] Req-change-pw,
-        set-pw                   [2] Req-set-pw,
-
-N. Williams        						[Page 21]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-        set-keys                 [3] Req-set-keys,
-        gen-keys                 [4] Req-gen-keys,
-        get-keys                 [5] Req-get-keys,
-        commit-keys              [6] Req-commit-keys,
-        get-pw-policy            [7] Req-get-pw-policy,
-        get-princ-aliases        [8] Req-get-princ-aliases,
-        get-realm-krb5-support   [9] Req-get-realm-krb5-support,
-        get-s2kparams            [10] Req-get-s2kparams,
-        ...
-   }
-
-   Op-rep                     ::= CHOICE {
-        null                    [0] Rep-null,
-        change-pw               [1] Rep-change-pw,
-        set-pw                  [2] Rep-set-pw,
-        set-keys                [3] Rep-set-keys,
-        gen-keys                [4] Req-gen-keys,
-        get-keys                [5] Req-get-keys,
-        commit-keys             [6] Rep-commit-keys,
-        get-pw-policy           [7] Rep-get-pw-policy,
-        get-princ-aliases       [8] Rep-get-princ-aliases,
-        get-realm-krb5-support  [9] Rep-get-realm-krb5-support,
-        get-s2kparams           [10] Rep-get-s2kparams,
-        ...
-   }
-
-   Op-err        ::= CHOICE {
-        null                    [0] Err-null,
-        change-pw               [1] Err-change-pw,
-        set-pw                  [2] Err-set-pw,
-        set-keys                [3] Err-set-keys,
-        gen-keys                [4] Err-gen-keys,
-        get-keys                [5] Err-get-keys,
-        commit-keys             [6] Err-commit-keys,
-        get-pw-policy           [7] Err-get-pw-policy,
-        get-princ-aliases       [8] Err-get-princ-aliases,
-        get-realm-krb5-support  [9] Err-get-realm-krb5-support,
-        get-s2kparams           [10] Err-get-s2kparams,
-        ...
-   }
-
-   ProtocolErrorCode           ::= ENUM {
-        proto-format-error,
-        proto-unsupported-major-version,
-        proto-unsupported-minor-version,
-        proto-unsupported-operation,      -- Request CHOICE tag unknown
-        proto-generic-see-op-error,       -- See Op-error
-        proto-wrong-service-principal,    -- Use kadmin/setpw
-        proto-re-authentication-required,
-        proto-initial-ticket-required,
-        proto-client-and-target-realm-mismatch,
-        proto-target-principal-unknown,
-        proto-authorization-failed,
-
-N. Williams        						[Page 22]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-        proto-dry-run-not-permitted,
-        ...
-   }
-
-   -- These codes are hints for clients, primarily for when they are
-   -- used for changing the passwords of automated principals; error
-   -- replies carry password quality policy help text that is more
-   -- appropriate for clients to display to users.
-   PW-Quality-Codes        ::= ENUM {
-        pwq-generic,
-        pwq-too-soon,
-        pwq-repeated,
-        pwq-too-short,
-        pwq-dictionary-words,
-        pwq-prohibited-codepoints,
-        pwq-need-more-char-classes,
-        ...
-   }
-
-   --
-   -- Requests and responses
-   --
-
-   -- NULL request, much like ONC RPC's NULL procedure - NOT extensible
-   Req-null    ::= NULL
-
-   Rep-null    ::= NULL
-
-   Err-null    ::= NULL
-
-   -- Change password
-   Req-change-pw        ::= SEQUENCE {
-        old-pw            [0] Password,
-        new-pw            [1] Password OPTIONAL,
-        commit            [2] BOOLEAN DEFAULT TRUE,
-        etypes            [3] SEQUENCE (1..) OF Etype OPTIONAL,
-        ...
-   }
-
-   Rep-change-pw        ::= SEQUENCE {
-        info-text         [0] UTF8String OPTIONAL,
-        new-pw            [1] Password OPTIONAL,
-                            -- generated by the server if present
-                            -- (and requested by the client)
-        etypes            [2] SEQUENCE (1..) OF Etype OPTIONAL,
-        ...
-   }
-
-   Err-change-pw        ::= SEQUENCE {
-        help-text         [0] UTF8String OPTIONAL,
-        error             [1] CHOICE {
-            op-generic-error           [0] Extensible-NULL,
-            op-old-pw-incorrect        [1] Extensible-NULL,
-
-N. Williams        						[Page 23]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-            op-wont-generate-new-pw    [2] Extensible-NULL,
-            op-new-pw-rejected-generic [3] SEQUENCE {
-                    policy                  [1] SEQUENCE OF UTF8String,
-                    suggested-pw            [2] Password OPTIONAL,
-                    policy-codes            [3] SET OF PW-Quality-Codes
-                                                    OPTIONAL,
-                    ...
-            }
-            op-etype-not-supported     [4] SEQUENCE {
-                    supported-etypes   [1] SEQUENCE OF Etype,
-                    ...
-            },
-            ...
-        },
-        ...
-   }
-
-   -- Set password
-   Req-set-pw        ::= SEQUENCE {
-        languages        [0] SEQUENCE OF Language-Tag OPTIONAL,
-        new-pw                [1] Password OPTIONAL,
-        commit                [2] BOOLEAN DEFAULT TRUE,
-        etypes                [3] SEQUENCE (1..) OF Etype OPTIONAL,
-        ...
-   }
-
-   Rep-set-pw        ::= SEQUENCE {
-        info-text        [0] UTF8String OPTIONAL,
-        new-pw                [1] Password OPTIONAL,
-                                -- generated by the server if present
-                                -- (and requested by the client)
-        etypes                [2] SEQUENCE (1..) OF Etype OPTIONAL,
-        ...
-   }
-
-   Err-set-pw        ::= Err-change-pw
-
-   -- Set keys
-   Req-set-keys      ::= SEQUENCE {
-        keys            [0] SEQUENCE OF Key,
-        commit          [1] BOOLEAN DEFAULT TRUE,
-                                -- TRUE  -> install keys now
-                                -- 
-                                -- FALSE -> require set-keys-commit
-                                --          before issuing tickets
-                                --          encrypted with these keys.
-                                -- 
-                                -- See commit-keys op
-        isupport        [2] KerberosVSupportNego OPTIONAL,
-                                -- For future Kerberos V extensions KDCs
-                                -- may need to know what krb5 version is
-                                -- supported by individual service
-                                -- principals.  This field provides a
-
-N. Williams        						[Page 24]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-                                -- way to tell the KDC what version of
-                                -- Kerberos V the target principal
-                                -- supports.
-        ...
-   }
-
-   Rep-set-keys        ::= SEQUENCE {
-        info-text        [0] UTF8String OPTIONAL,
-        kvno             [1] UInt32,
-        aliases          [2] SEQUENCE OF SEQUENCE {
-                name     [0] PrincipalName,
-                realm    [1] Realm OPTIONAL,
-                ...
-        },
-        isupport         [3] KerberosVSupportNego OPTIONAL,
-        ...
-        -- Should there be ETYPE-INFO2 stuff here?
-   }
-
-   Err-set-keys        ::= SEQUENCE {
-        help-text     [0] UTF8String OPTIONAL, -- Reason for rejection
-        error         [1] CHOICE {
-                op-generic                    [0] Extensible-NULL,
-                op-deferred-commit-no-support [1] Extensible-NULL,
-                op-etype-no-support           [2] SEQUENCE OF {
-                        supported-etypes      [1] SEQUENCE OF Etype,
-                        ...
-                }
-                ...
-        }
-   }
-
-   -- Generate keys
-   Req-gen-keys        ::= SEQUENCE {
-        etypes           [0] SEQUENCE (1..) OF Etype,
-        entropy          [1] OCTET STRING OPTIONAL,
-        commit           [2] BOOLEAN DEFAULT TRUE,
-                                -- TRUE  -> install keys now
-                                -- 
-                                -- FALSE -> require set-keys-commit
-                                --          before issuing tickets
-                                --          encrypted with these keys.
-                                -- 
-                                -- See commit-keys op
-        isupport         [3] KerberosVSupportNego OPTIONAL,
-                                -- For future Kerberos V extensions KDCs
-                                -- may need to know what krb5 version is
-                                -- supported by individual service
-                                -- principals.  This field provides a
-                                -- way to tell the KDC what version of
-                                -- Kerberos V the target principal
-                                -- supports.
-        ...
-
-N. Williams        						[Page 25]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-   }
-
-   Rep-gen-keys        ::= SEQUENCE {
-        info-text        [0] UTF8String OPTIONAL,
-        kvno             [1] UInt32,
-        key              [2] Key,
-        aliases          [3] SEQUENCE OF SEQUENCE {
-                name          [0] PrincipalName,
-                realm         [1] Realm OPTIONAL,
-                ...
-        },
-        isupport         [4] KerberosVSupportNego OPTIONAL,
-        ...
-        -- Should there be ETYPE-INFO2 stuff here?
-   }
-
-   Err-gen-keys        ::= Err-set-keys
-
-   -- Get un-committed key request
-   Req-get-keys        ::= SEQUENCE {
-        kvno             [0] UInt32,
-        ...
-   }
-
-   Rep-get-keys        ::= SEQUENCE {
-        info-text        [0] UTF8String OPTIONAL,
-        keys             [1] SEQUENCE OF Key,
-        aliases          [2] SEQUENCE OF SEQUENCE {
-                name          [0] PrincipalName,
-                realm         [1] Realm OPTIONAL,
-                ...
-        },
-        isupport         [3] KerberosVSupportNego OPTIONAL,
-        ...
-        -- Should there be ETYPE-INFO2 stuff here?
-   }
-
-   Err-get-keys      ::= SEQUENCE {
-        help-text      [0] UTF8String OPTIONAL, -- Reason for rejection
-        error          [1] CHOICE {
-                op-generic         [0] Extensible-NULL,
-                op-kvno-committed  [1] Extensible-NULL,
-                op-no-such-kvno    [1] Extensible-NULL,
-                ...
-        }
-   }
-
-   -- Commit a set keys request
-   Req-commit-keys ::= SEQUENCE {
-        kvno         [0] UInt32,
-        ...
-   }
-
-
-N. Williams        						[Page 26]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-   Rep-commit-keys ::= Extensible-NULL
-
-   Err-commit-keys ::= SEQUENCE {
-        help-text    [0] UTF8String OPTIONAL, -- Reason for rejection
-        error        [1] CHOICE {
-                op-generic           [0] Extensible-NULL,
-                op-kvno-expired      [1] Extensible-NULL,
-                    -- The client took too long to respond.
-                op-kvno-unknown      [2] Extensible-NULL,
-                    -- The targ princ/kvno is invalid or unknown to the
-                    -- server (perhaps it lost track of state)
-                op-new-keys-conflict [3] Extensible-NULL,
-                    -- A new-keys/commit-keys request subsequent to the
-                    -- new-keys that produced the kvno has completed
-                    -- and incremented the principal's kvno
-                ...
-        }
-        ...
-   }
-
-   -- Get password policy
-   Req-get-pw-policy   ::= Extensible-NULL
-
-   Rep-get-pw-policy   ::= SEQUENCE {
-        policy-name      [0] UTF8String OPTIONAL,
-        description      [1] SEQUENCE OF UTF8String OPTIONAL,
-        ...
-   }
-
-   Err-get-pw-policy   ::= Extensible-NULL
-
-   -- Get principal aliases
-   Req-get-princ-aliases        ::= Extensible-NULL
-
-   Rep-get-princ-aliases        ::= SEQUENCE {
-        help-text    [0] UTF8String OPTIONAL,
-        aliases      [1] SEQUENCE OF SEQUENCE {
-                name      [0] PrincipalName,
-                realm     [1] Realm OPTIONAL,
-                ...
-        },
-        ...
-   }
-
-   Err-get-princ-aliases        ::= Extensible-NULL
-
-   -- Get list of enctypes supported by KDC for new keys
-   Req-get-realm-krb5-support   ::= Extensible-NULL
-
-   Rep-get-realm-krb5-support   ::= SEQUENCE {
-        isupport        [0] KerberosVSupportNego,
-                                -- Version of Kerberos V supported by
-                                -- the target realm.
-
-N. Williams        						[Page 27]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-        ...
-   }
-
-   Err-get-realm-krb5-support   ::= Extensible-NULL
-
-   -- Get s2kparams
-   Req-get-s2kparams            ::= Extensible-NULL
-
-   Rep-get-s2kparams            ::= SEQUENCE {
-        help-text       [0] UTF8String OPTIONAL,
-        s2kparams       [1] SEQUENCE OF Etype-Info-Entry,
-        ...
-   }
-
-   Err-get-s2kparams            ::= Extensible-NULL
-
-   END
-
-
-6  IANA Considerations
-
-   There are no IANA considerations for this document.
-
-7  Security Considerations
-   
-   Implementors and site administrators should note that the redundancy
-   of UTF-8 encodings of passwords varies by language.  Password quality
-   policies SHOULD, therefore, take this into account when estimating
-   the amount of redundancy and entropy in a proposed new password.  [??
-   It's late at night - I think this is correct.]
-
-   Kerberos set/change password/key protocol major version negotiation
-   cannot be done securely; a downgrade attack is possible against
-   clients that attempt to negotiate the protocol major version to use
-   with a server.  It is not clear at this time that the attacker would
-   gain much from such a downgrade attack other than denial of service
-   (DoS) by forcing the client to use a protocol version which does not
-   support some feature needed by the client (Kerberos V in general is
-   subject to a variety of DoS attacks anyways [RFC1510]).  Clients
-   SHOULD NOT negotiate support for legacy major versions of this
-   protocol unless configured otherwise.
-
-   This protocol does not have Perfect Forward Security (PFS).  As a
-   result, any passive network snooper watching password/key changing
-   operations who has stolen a principal's password or long-term keys
-   can find out what the new ones are.
-
-   [More text needed?]
-
-8  Acknowledgements
-   
-   The authors would like to thank original editors/authors Jonathan
-   Trostle, Bill Gossman, Mike Swift, John Brezak, as well as Ken
-   Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W.
-
-N. Williams        						[Page 28]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-   Nelson, Marcus Watts, Love, Joel N.  Weber II, Jeffrey Hutzelman and
-   other participants from the IETF Kerberos Working Group for their
-   assistance.
-
-9  References
-
-9.1  Normative References
-
-   [RFC2026]
-      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
-      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
-      Practice.
-
-   [RFC2119]
-      S. Bradner, RFC2119 (BCP14):  "Key words for use in RFCs to
-      Indicate Requirement Levels," March 1997, Status: Best Current
-      Practice.
-
-   [X680]
-      Abstract Syntax Notation One (ASN.1): Specification of Basic
-      Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
-      International Standard 8824-1:1998.
-      http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf
-
-   [X690]
-      ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
-      Canonical Encoding Rules (CER) and Distinguished Encoding Rules
-      (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
-      Standard 8825-1:1998.
-      http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf
-
-   [clarifications]
-      RFC-Editor: To be replaced by RFC number for
-      draft-ietf-krb-wg-kerberos-clarifications.
-
-   [RFC3066]
-      H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of
-      Languages," January 2001, Obsoletes RFC1766, Status: Best Current
-      Practice.
-
-9.2  Informative References
-
-   [RFC3244]
-      M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000
-      Kerberos Change Password and Set Password Protocols," February
-      2002, Status: Informational.
-
-10  Authors' Addresses
-
-      Nicolas Williams
-      Sun Microsystems
-      5300 Riata Trace Ct
-      Austin, TX 78727
-
-N. Williams        						[Page 29]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-      Email: nicolas.williams@sun.com
-
-
-11  Notes to the RFC Editor
-
-   This document has two KRB WG drafts as normative references and
-   cannot progress until those drafts progress, but no other draft
-   depends on this one.
-
-12  Change History
-
-    -01 -> -02
-
-     - Removed Bill Gossman, Mike Swift and John Brezak as authors.
-
-     - Removed UDP as a transport for this protocol.
-
-     - Replaced redundant copies of framing ASCII art with reference to
-       RFC3244.
-
-     - Made all name/password strings UTF8String with an extensible
-       constraint to IA5String.
-
-     - Added a method for doing dry runs of operations.  This is helpful
-       in testing passwords against password quality policies.
-
-     - Added an operation for retrieving a principal's current and
-       preferred string-to-key parameters, and a way to change them
-       without changing the principal's password.
-
-     - Added password quality codes as hints for smart clients, but
-       these are optional and not to be used instead of messages to be
-       displayed to useds.
-
-     - Added a 'commit' option to change-pw and set-pw (as requested by
-       Larry).
-
-     - Removed "version" field of the Kerberos V feature negotiation
-       struture.
-
-
-
-N. Williams        						[Page 30]
-
-DRAFT		Kerberos Set/Change Password v2		  Expires April 2006
-
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams                Expires August 22, 2005                [Page 31]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt b/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt
deleted file mode 100644
index a6dec9d1e..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                             Ken Hornstein
-<draft-ietf-krb-wg-krb-dns-locate-02.txt>                            NRL
-February 28, 2001                                         Jeffrey Altman
-Expires: August 28, 2001                             Columbia University
-
-
-
-          Distributing Kerberos KDC and Realm Information with DNS
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   Distribution of this memo is unlimited.  It is filed as <draft-ietf-
-   krb-wg-krb-dns-locate-02.txt>, and expires on August 28, 2001.
-   Please send comments to the authors.
-
-Abstract
-
-   Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto-
-   col [RFC????] describe any mechanism for clients to learn critical
-   configuration information necessary for proper operation of the pro-
-   tocol.  Such information includes the location of Kerberos key dis-
-   tribution centers or a mapping between DNS domains and Kerberos
-   realms.
-
-   Current Kerberos implementations generally store such configuration
-   information in a file on each client machine.  Experience has shown
-   this method of storing configuration information presents problems
-   with out-of-date information and scaling problems, especially when
-
-
-
-Hornstein, Altman                                               [Page 1]
-
-RFC DRAFT                                              February 28, 2001
-
-
-   using cross-realm authentication.
-
-   This memo describes a method for using the Domain Name System
-   [RFC1035] for storing such configuration information.  Specifically,
-   methods for storing KDC location and hostname/domain name to realm
-   mapping information are discussed.
-
-DNS vs. Kerberos - Case Sensitivity of Realm Names
-
-   In Kerberos, realm names are case sensitive.  While it is strongly
-   encouraged that all realm names be all upper case this recommendation
-   has not been adopted by all sites.  Some sites use all lower case
-   names and other use mixed case.  DNS on the other hand is case insen-
-   sitive for queries but is case preserving for responses to TXT
-   queries.  Since "MYREALM", "myrealm", and "MyRealm" are all different
-   it is necessary that only one of the possible combinations of upper
-   and lower case characters be used.  This restriction may be lifted in
-   the future as the DNS naming scheme is expanded to support non-ASCII
-   names.
-
-Overview - KDC location information
-
-   KDC location information is to be stored using the DNS SRV RR [RFC
-   2052].  The format of this RR is as follows:
-
-   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
-
-   The Service name for Kerberos is always "_kerberos".
-
-   The Proto can be either "_udp" or "_tcp".  If these records are to be
-   used, a "_udp" record MUST be included.  If the Kerberos implementa-
-   tion supports TCP transport, a "_tcp" record SHOULD be included.
-
-   The Realm is the Kerberos realm that this record corresponds to.
-
-   TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
-   ing as defined in RFC 2052.
-
-   As per RFC 2052 the Port number should be the value assigned to "ker-
-   beros" by the Internet Assigned Number Authority (88).
-
-Example - KDC location information
-
-   These are DNS records for a Kerberos realm ASDF.COM.  It has two Ker-
-   beros servers, kdc1.asdf.com and kdc2.asdf.com.  Queries should be
-   directed to kdc1.asdf.com first as per the specified priority.
-   Weights are not used in these records.
-
-
-
-
-Hornstein, Altman                                               [Page 2]
-
-RFC DRAFT                                              February 28, 2001
-
-
-   _kerberos._udp.ASDF.COM.        IN      SRV     0 0 88 kdc1.asdf.com.
-   _kerberos._udp.ASDF.COM.        IN      SRV     1 0 88 kdc2.asdf.com.
-
-Overview - Kerberos password changing server location information
-
-   Kerberos password changing server [KERB-CHG] location is to be stored
-   using the DNS SRV RR [RFC 2052].  The format of this RR is as fol-
-   lows:
-
-   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
-
-   The Service name for the password server is always "_kpasswd".
-
-   The Proto MUST be "_udp".
-
-   The Realm is the Kerberos realm that this record corresponds to.
-
-   TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
-   ing as defined in RFC 2052.
-
-   As per RFC 2052 the Port number should be the value assigned to
-   "kpasswd" by the Internet Assigned Number Authority (464).
-
-Overview - Kerberos admin server location information
-
-   Kerberos admin location information is to be stored using the DNS SRV
-   RR [RFC 2052].  The format of this RR is as follows:
-
-   Service.Proto.Realm TTL Class SRV Priority Weight Port Target
-
-   The Service name for the admin server is always "_kerberos-adm".
-
-   The Proto can be either "_udp" or "_tcp".  If these records are to be
-   used, a "_tcp" record MUST be included.  If the Kerberos admin imple-
-   mentation supports UDP transport, a "_udp" record SHOULD be included.
-
-   The Realm is the Kerberos realm that this record corresponds to.
-
-   TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
-   ing as defined in RFC 2052.
-
-   As per RFC 2052 the Port number should be the value assigned to
-   "kerberos-adm" by the Internet Assigned Number Authority (749).
-
-   Note that there is no formal definition of a Kerberos admin protocol,
-   so the use of this record is optional and implementation-dependent.
-
-
-
-
-
-Hornstein, Altman                                               [Page 3]
-
-RFC DRAFT                                              February 28, 2001
-
-
-Example - Kerberos administrative server location information
-
-   These are DNS records for a Kerberos realm ASDF.COM.  It has one
-   administrative server, kdc1.asdf.com.
-
-   _kerberos-adm._tcp.ASDF.COM.    IN      SRV     0 0 749 kdc1.asdf.com.
-
-Overview - Hostname/domain name to Kerberos realm mapping
-
-   Information on the mapping of DNS hostnames and domain names to Ker-
-   beros realms is stored using DNS TXT records [RFC 1035].  These
-   records have the following format.
-
-   Service.Name TTL Class TXT Realm
-
-   The Service field is always "_kerberos", and prefixes all entries of
-   this type.
-
-   The Name is a DNS hostname or domain name.  This is explained in
-   greater detail below.
-
-   TTL, Class, and TXT have the standard DNS meaning as defined in RFC
-   1035.
-
-   The Realm is the data for the TXT RR, and consists simply of the Ker-
-   beros realm that corresponds to the Name specified.
-
-   When a Kerberos client wishes to utilize a host-specific service, it
-   will perform a DNS TXT query, using the hostname in the Name field of
-   the DNS query.  If the record is not found, the first label of the
-   name is stripped and the query is retried.
-
-   Compliant implementations MUST query the full hostname and the most
-   specific domain name (the hostname with the first label removed).
-   Compliant implementations SHOULD try stripping all subsequent labels
-   until a match is found or the Name field is empty.
-
-Example - Hostname/domain name to Kerberos realm mapping
-
-   For the previously mentioned ASDF.COM realm and domain, some sample
-   records might be as follows:
-
-   _kerberos.asdf.com.             IN      TXT     "ASDF.COM"
-   _kerberos.mrkserver.asdf.com.   IN      TXT     "MARKETING.ASDF.COM"
-   _kerberos.salesserver.asdf.com. IN      TXT     "SALES.ASDF.COM"
-
-   Let us suppose that in this case, a Kerberos client wishes to use a
-   Kerberized service on the host foo.asdf.com.  It would first query:
-
-
-
-Hornstein, Altman                                               [Page 4]
-
-RFC DRAFT                                              February 28, 2001
-
-
-   _kerberos.foo.asdf.com. IN TXT
-
-   Finding no match, it would then query:
-
-   _kerberos.asdf.com. IN TXT
-
-   And find an answer of ASDF.COM.  This would be the realm that
-   foo.asdf.com resides in.
-
-   If another Kerberos client wishes to use a Kerberized service on the
-   host salesserver.asdf.com, it would query:
-
-   _kerberos.salesserver.asdf.com IN TXT
-
-   And find an answer of SALES.ASDF.COM.
-
-Security considerations
-
-   As DNS is deployed today, it is an unsecure service.  Thus the infor-
-   mation returned by it cannot be trusted.
-
-   Current practice for REALM to KDC mapping is to use hostnames to
-   indicate KDC hosts (stored in some implementation-dependent location,
-   but generally a local config file).  These hostnames are vulnerable
-   to the standard set of DNS attacks (denial of service, spoofed
-   entries, etc).  The design of the Kerberos protocol limits attacks of
-   this sort to denial of service.  However, the use of SRV records does
-   not change this attack in any way.  They have the same vulnerabili-
-   ties that already exist in the common practice of using hostnames for
-   KDC locations.
-
-   Current practice for HOSTNAME to REALM mapping is to provide a local
-   configuration of mappings of hostname or domain name to realm which
-   are then mapped to KDCs.  But this again is vulnerable to spoofing
-   via CNAME records that point to hosts in other domains.  This has the
-   same effect as when a TXT record is spoofed.  In a realm with no
-   cross-realm trusts this is a DoS attack.  However, when cross-realm
-   trusts are used it is possible to redirect a client to use a comprom-
-   ised realm.
-
-   This is not an exploit of the Kerberos protocol but of the Kerberos
-   trust model.  The same can be done to any application that must
-   resolve the hostname in order to determine which domain a non-FQDN
-   belongs to.
-
-   Implementations SHOULD provide a way of specifying this information
-   locally without the use of DNS.  However, to make this feature
-   worthwhile a lack of any configuration information on a client should
-
-
-
-Hornstein, Altman                                               [Page 5]
-
-RFC DRAFT                                              February 28, 2001
-
-
-   be interpretted as permission to use DNS.
-
-Expiration
-
-   This Internet-Draft expires on August 28, 2001.
-
-References
-
-
-   [RFC1510]
-        The Kerberos Network Authentication System; Kohl, Newman; Sep-
-        tember 1993.
-
-   [RFC1035]
-        Domain Names - Implementation and Specification; Mockapetris;
-        November 1987
-
-   [RFC2782]
-        A DNS RR for specifying the location of services (DNS SRV); Gul-
-        brandsen, Vixie; Feburary 2000
-
-   [KERB-CHG]
-        Kerberos Change Password Protocol; Horowitz;
-        ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-
-        password-02.txt
-
-Authors' Addresses
-
-   Ken Hornstein
-   US Naval Research Laboratory
-   Bldg A-49, Room 2
-   4555 Overlook Avenue
-   Washington DC  20375 USA
-
-   Phone: +1 (202) 404-4765
-   EMail: kenh@cmf.nrl.navy.mil
-
-   Jeffrey Altman
-   The Kermit Project
-   Columbia University
-   612 West 115th Street #716
-   New York NY 10025-7799 USA
-
-   Phone: +1 (212) 854-1344
-   EMail: jaltman@columbia.edu
-
-
-
-
-
-
-Hornstein, Altman                                               [Page 6]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-00.txt b/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-00.txt
deleted file mode 100644
index 66e5521ed..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-00.txt
+++ /dev/null
@@ -1,505 +0,0 @@
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                             K. Jaganathan
-Expires: February 8, 2005                          Microsoft Corporation
-                                                             N. Williams
-                                                        Sun Microsystems
-                                                         August 10, 2004
-
-
-                        OCSP Support for PKINIT
-                    draft-ietf-krb-wg-ocsp-for-pkinit-00
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on February 8, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document defines a mechanism to enable in-band transmission of
-   OCSP responses.  These responses are used to verify the validity of
-   the certificates used in PKINIT - the Kerberos Version 5 extension
-   that provides for the use of public key cryptography.
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 1]
-
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.   Conventions Used in This Document  . . . . . . . . . . . . . . 4
-   3.   Message Definition . . . . . . . . . . . . . . . . . . . . . . 5
-   4.   Security Considerations  . . . . . . . . . . . . . . . . . . . 6
-   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 7
-   6.   References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
-        Intellectual Property and Copyright Statements . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 2]
-
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-1.  Introduction
-
-   Online Certificate Status Protocol (OCSP) [RFC2560] enables
-   applications to obtain timely information regarding the revocation
-   status of a certificate.  Because OCSP responses are well-bounded and
-   small in size, constrained clients may wish to use OCSP to check the
-   validity of KDC certificates in order to avoid transmission of large
-   Certificate Revocation Lists (CRLs) and therefore save bandwidth on
-   constrained networks.
-
-   This document defines a pre-authentication type [CLARIFICATIONS],
-   where the client and the KDC MAY piggyback OCSP responses for
-   certificates used in authentication exchanges, as defined in
-   [PKINIT].
-
-   By using this OPTIONAL extension, PKINIT clients and the KDC can
-   maximize the reuse of cached OCSP responses.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 3]
-
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 4]
-
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-3.  Message Definition
-
-   A pre-authentication type identifier is defined for this mechanism:
-
-              PA-PK-OCSP-RESPONSE              16
-
-   The corresponding pre-authentication field contains OCSP data as
-   follows:
-
-          PA-PK-OCSP-DATA ::= SEQUENCE OF OcspResponse
-
-          OcspResponse ::= OCTET STRING
-                         -- contains a complete OCSP response,
-                         -- defined in [RFC2560]
-
-   The client MAY send OCSP responses for certificates used in
-   PA-PK-AS-REQ via a PA-PK-OCSP-RESPONSE.
-
-   The KDC that receives a PA-PK-OCSP-RESPONSE the SHOULD send a
-   PA-PK-OCSP-RESPONSE in response.  The client can request a
-   PA-PK-OCSP-RESPONSE by using an empty sequence in its request.
-
-   Note the lack of integrity protection for the empty or missing OCSP
-   response; lack of an expected OCSP response from the KDC for the
-   KDC's certificates SHOULD be treated as an error by the client,
-   unless it is configured otherwise.
-
-   When using OCSP, the response is signed by the OCSP server, which is
-   trusted by the receiver.  Depending on local policy, further
-   verification of the validity of the OCSP servers MAY need to be done.
-
-   The client and the KDC SHOULD ignore invalid OCSP responses received
-   via this mechanism, and they MAY implement CRL processing logic as a
-   fall-back position, if the OCSP responses received via this mechanism
-   alone are not sufficient for the verification of certificate
-   validity.  The client and/or the KDC MAY ignore a valid OCSP response
-   and perform their own revocation status verification independently.
-
-   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
-   PA-PK-OCSP-RESPONSE from the client.
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 5]
-
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-4.  Security Considerations
-
-   The pre-authentication data in this document do not actually
-   authenticate any principals, and MUST be used in conjunction with
-   PKINIT.
-
-   There is a downgrade attack against clients which want OCSP responses
-   from the KDC for the KDC's certificates.  The clients, however, can
-   treat the absence of valid OCSP responses as an error, based on their
-   local configuration.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 6]
-
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-5.  IANA Considerations
-
-   This document defines a new pre-authentication type for use with
-   PKINIT to encode OCSP responses.  The official value for this padata
-   identifier need to be acquired from IANA.
-
-6  References
-
-   [CLARIFICATIONS]
-              Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", 
-              draft-ietf-krb-wg-kerberos-clarifications, Work in 
-              progress.
-
-   [PKINIT]   Tung, B. and B. Neuman, "Public Key Cryptography for
-              Initial Authentication in Kerberos", 
-              draft-ietf-cat-kerberos-pk-init, Work in progress.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
-              Adams, "X.509 Internet Public Key Infrastructure Online
-              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: lzhu@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: karthikj@microsoft.com
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 7]
-
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 8]
-
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   This document was based on conversations among the authors, Jeffrey 
-   Altman, Sam Hartman, Martin Rex, and other members of the Kerberos 
-   working group.
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 9]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-01.txt b/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-01.txt
deleted file mode 100644
index a4927feee..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-01.txt
+++ /dev/null
@@ -1,566 +0,0 @@
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                             K. Jaganathan
-Expires: February 8, 2005                          Microsoft Corporation
-                                                             N. Williams
-                                                        Sun Microsystems
-                                                         August 10, 2004
-
-
-
-                        OCSP Support for PKINIT
-                   draft-ietf-krb-wg-ocsp-for-pkinit-01
-
-
-Status of this Memo
-
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-
-   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."
-
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-   This Internet-Draft will expire on February 8, 2005.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).
-
-
-Abstract
-
-
-   This document defines a mechanism to enable in-band transmission of
-   OCSP responses.  These responses are used to verify the validity of
-   the certificates used in PKINIT - the Kerberos Version 5 extension
-   that provides for the use of public key cryptography.
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 1]
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-
-Table of Contents
-
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.   Conventions Used in This Document  . . . . . . . . . . . . . . 4
-   3.   Message Definition . . . . . . . . . . . . . . . . . . . . . . 5
-   4.   Security Considerations  . . . . . . . . . . . . . . . . . . . 6
-   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 7
-   6.   References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
-        Intellectual Property and Copyright Statements . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 2]
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-
-1.  Introduction
-
-
-   Online Certificate Status Protocol (OCSP) [RFC2560] enables
-   applications to obtain timely information regarding the revocation
-   status of a certificate.  Because OCSP responses are well-bounded and
-   small in size, constrained clients may wish to use OCSP to check the
-   validity of KDC certificates in order to avoid transmission of large
-   Certificate Revocation Lists (CRLs) and therefore save bandwidth on
-   constrained networks.
-
-
-   This document defines a pre-authentication type [CLARIFICATIONS],
-   where the client and the KDC MAY piggyback OCSP responses for
-   certificates used in authentication exchanges, as defined in
-   [PKINIT].
-
-
-   By using this OPTIONAL extension, PKINIT clients and the KDC can
-   maximize the reuse of cached OCSP responses.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 3]
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-
-2.  Conventions Used in This Document
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 4]
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-
-3.  Message Definition
-
-
-   A pre-authentication type identifier is defined for this mechanism:
-
-
-              PA-PK-OCSP-RESPONSE              16
-
-
-   The corresponding pre-authentication field contains OCSP data as
-   follows:
-
-
-          PA-PK-OCSP-DATA ::= SEQUENCE OF OcspResponse
-
-
-          OcspResponse ::= OCTET STRING
-                         -- contains a complete OCSP response,
-                         -- defined in [RFC2560]
-
-
-   The client MAY send OCSP responses for certificates used in
-   PA-PK-AS-REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
-
-
-   The KDC that receives a PA-PK-OCSP-RESPONSE the SHOULD send a
-   PA-PK-OCSP-RESPONSE in response.  The client can request a
-   PA-PK-OCSP-RESPONSE by using an empty sequence in its request.
-
-
-   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
-   PA-PK-OCSP-RESPONSE from the client.
-
-
-   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
-   certificates used in PA-PK-AS-REP [PKINIT].
-
-
-   Note the lack of integrity protection for the empty or missing OCSP
-   response; lack of an expected OCSP response from the KDC for the
-   KDC's certificates SHOULD be treated as an error by the client,
-   unless it is configured otherwise.
-
-
-   When using OCSP, the response is signed by the OCSP server, which is
-   trusted by the receiver.  Depending on local policy, further
-   verification of the validity of the OCSP servers MAY need to be done.
-
-
-   The client and the KDC SHOULD ignore invalid OCSP responses received
-   via this mechanism, and they MAY implement CRL processing logic as a
-   fall-back position, if the OCSP responses received via this mechanism
-   alone are not sufficient for the verification of certificate
-   validity.  The client and/or the KDC MAY ignore a valid OCSP response
-   and perform their own revocation status verification independently.
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 5]
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-
-4.  Security Considerations
-
-
-   The pre-authentication data in this document do not actually
-   authenticate any principals, and MUST be used in conjunction with
-   PKINIT.
-
-
-   There is a downgrade attack against clients which want OCSP responses
-   from the KDC for the KDC's certificates.  The clients, however, can
-   treat the absence of valid OCSP responses as an error, based on their
-   local configuration.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 6]
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-
-5.  IANA Considerations
-
-
-   This document defines a new pre-authentication type for use with
-   PKINIT to encode OCSP responses.  The official value for this padata
-   identifier need to be acquired from IANA.
-
-
-6  References
-
-
-   [CLARIFICATIONS]
-              Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", 
-              draft-ietf-krb-wg-kerberos-clarifications, Work in 
-              progress.
-
-
-   [PKINIT]   Tung, B. and B. Neuman, "Public Key Cryptography for
-              Initial Authentication in Kerberos", 
-              draft-ietf-cat-kerberos-pk-init, Work in progress.
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
-              Adams, "X.509 Internet Public Key Infrastructure Online
-              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
-
-
-
-Authors' Addresses
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-
-   EMail: lzhu@microsoft.com
-
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-
-   EMail: karthikj@microsoft.com
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 7]
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 8]
-Internet-Draft          OCSP Support for PKINIT              August 2004
-
-
-
-Intellectual Property Statement
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
-   This document was based on conversations among the authors, Jeffrey 
-   Altman, Sam Hartman, Martin Rex, and other members of the Kerberos 
-   working group.
-
-
-
-
-
-Zhu, et al.             Expires February 8, 2005                [Page 9]
\ No newline at end of file
diff --git a/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-02.txt b/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-02.txt
deleted file mode 100644
index 55cdf4c76..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-02.txt
+++ /dev/null
@@ -1,562 +0,0 @@
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                             K. Jaganathan
-Expires: May 21, 2005                              Microsoft Corporation
-                                                             N. Williams
-                                                        Sun Microsystems
-                                                       November 20, 2004
-
-
-                        OCSP Support for PKINIT
-                 draft-ietf-krb-wg-ocsp-for-pkinit-02
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on May 21, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document defines a mechanism to enable in-band transmission of
-   OCSP responses.  These responses are used to verify the validity of
-   the certificates used in PKINIT - the Kerberos Version 5 extension
-   that provides for the use of public key cryptography.
-
-
-
-
-Zhu, et al.               Expires May 21, 2005                  [Page 1]
-
-Internet-Draft          OCSP Support for PKINIT            November 2004
-
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.   Conventions Used in This Document  . . . . . . . . . . . . .   4
-   3.   Message Definition . . . . . . . . . . . . . . . . . . . . .   5
-   4.   Security Considerations  . . . . . . . . . . . . . . . . . .   6
-   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   7
-   6.   Acknowledgement  . . . . . . . . . . . . . . . . . . . . . .   8
-   7.   References . . . . . . . . . . . . . . . . . . . . . . . . .   8
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .   8
-        Intellectual Property and Copyright Statements . . . . . . .  10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 21, 2005                  [Page 2]
-
-Internet-Draft          OCSP Support for PKINIT            November 2004
-
-
-1.  Introduction
-
-   Online Certificate Status Protocol (OCSP) [RFC2560] enables
-   applications to obtain timely information regarding the revocation
-   status of a certificate.  Because OCSP responses are well-bounded and
-   small in size, constrained clients may wish to use OCSP to check the
-   validity of KDC certificates in order to avoid transmission of large
-   Certificate Revocation Lists (CRLs) and therefore save bandwidth on
-   constrained networks [OCSP-PROFILE].
-
-   This document defines a pre-authentication type [CLARIFICATIONS],
-   where the client and the KDC MAY piggyback OCSP responses for
-   certificates used in authentication exchanges, as defined in
-   [PKINIT].
-
-   By using this OPTIONAL extension, PKINIT clients and the KDC can
-   maximize the reuse of cached OCSP responses.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 21, 2005                  [Page 3]
-
-Internet-Draft          OCSP Support for PKINIT            November 2004
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 21, 2005                  [Page 4]
-
-Internet-Draft          OCSP Support for PKINIT            November 2004
-
-
-3.  Message Definition
-
-   A pre-authentication type identifier is defined for this mechanism:
-
-              PA-PK-OCSP-RESPONSE              16
-
-   The corresponding pre-authentication field contains OCSP data as
-   follows:
-
-          PA-PK-OCSP-DATA ::= SEQUENCE OF OcspResponse
-
-          OcspResponse ::= OCTET STRING
-                         -- contains a complete OCSP response,
-                         -- defined in [RFC2560]
-
-   The client MAY send OCSP responses for certificates used in
-   PA-PK-AS-REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
-
-   The KDC that receives a PA-PK-OCSP-RESPONSE the SHOULD send a
-   PA-PK-OCSP-RESPONSE in response.  The client can request a
-   PA-PK-OCSP-RESPONSE by using an empty sequence in its request.
-
-   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
-   PA-PK-OCSP-RESPONSE from the client.
-
-   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
-   certificates used in PA-PK-AS-REP [PKINIT].
-
-   Note the lack of integrity protection for the empty or missing OCSP
-   response; lack of an expected OCSP response from the KDC for the
-   KDC's certificates SHOULD be treated as an error by the client,
-   unless it is configured otherwise.
-
-   When using OCSP, the response is signed by the OCSP server, which is
-   trusted by the receiver.  Depending on local policy, further
-   verification of the validity of the OCSP servers MAY need to be done.
-
-   The client and the KDC SHOULD ignore invalid OCSP responses received
-   via this mechanism, and they MAY implement CRL processing logic as a
-   fall-back position, if the OCSP responses received via this mechanism
-   alone are not sufficient for the verification of certificate
-   validity.  The client and/or the KDC MAY ignore a valid OCSP response
-   and perform their own revocation status verification independently.
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 21, 2005                  [Page 5]
-
-Internet-Draft          OCSP Support for PKINIT            November 2004
-
-
-4.  Security Considerations
-
-   The pre-authentication data in this document do not actually
-   authenticate any principals, and MUST be used in conjunction with
-   PKINIT.
-
-   There is a downgrade attack against clients which want OCSP responses
-   from the KDC for the KDC's certificates.  The clients, however, can
-   treat the absence of valid OCSP responses as an error, based on their
-   local configuration.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 21, 2005                  [Page 6]
-
-Internet-Draft          OCSP Support for PKINIT            November 2004
-
-
-5.  IANA Considerations
-
-   This document defines a new pre-authentication type for use with
-   PKINIT to encode OCSP responses.  The official value for this padata
-   identifier need to be acquired from IANA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 21, 2005                  [Page 7]
-
-Internet-Draft          OCSP Support for PKINIT            November 2004
-
-
-6.  Acknowledgements
-
-   This document was based on conversations among the authors, Jeffrey
-   Altman, Sam Hartman, Martin Rex and other members of the Kerberos
-   working group.
-
-7  References
-
-   [CLARIFICATIONS]
-              Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", 
-              draft-ietf-krb-wg-kerberos-clarifications, Work in 
-              progress.
-
-   [OCSP-PROFILE]
-              Deacon, A. and R. Hurst, "Lightweight OCSP Profile for
-              High Volume Environments", 
-              draft-ietf-pkix-lightweight-ocsp-profile, Work in
-              progress.
-
-   [PKINIT]   Tung, B., Neuman, B. and S. Medvinsky, "Public Key
-              Cryptography for Initial Authentication in Kerberos",
-              draft-ietf-cat-kerberos-pk-init, Work in progress.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
-              Adams, "X.509 Internet Public Key Infrastructure Online
-              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: lzhu@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: karthikj@microsoft.com
-
-
-
-
-Zhu, et al.               Expires May 21, 2005                  [Page 8]
-
-Internet-Draft          OCSP Support for PKINIT            November 2004
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 21, 2005                  [Page 9]
-
-Internet-Draft          OCSP Support for PKINIT            November 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.               Expires May 21, 2005                 [Page 10]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-04.txt b/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-04.txt
deleted file mode 100644
index 319f16159..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-04.txt
+++ /dev/null
@@ -1,394 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                             K. Jaganathan
-Expires: August 4, 2005                            Microsoft Corporation
-                                                             N. Williams
-                                                        Sun Microsystems
-                                                        January 31, 2005
-
-
-                        OCSP Support for PKINIT
-                   draft-ietf-krb-wg-ocsp-for-pkinit-04
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 4, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document defines a mechanism to enable in-band transmission of
-   Online Certificate Status Protocol (OCSP) responses in the Kerberos
-   network authentication protocol.  These responses are used to verify
-   the validity of the certificates used in PKINIT - the Kerberos
-
-
-
-Zhu, et al.              Expires August 4, 2005                 [Page 1]
-
-Internet-Draft           OCSP Support for PKINIT            January 2005
-
-
-   Version 5 extension that provides for the use of public key
-   cryptography.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Message Definition . . . . . . . . . . . . . . . . . . . . . .  3
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
-     7.1   Normative References . . . . . . . . . . . . . . . . . . .  5
-     7.2   Informative References . . . . . . . . . . . . . . . . . .  5
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  5
-       Intellectual Property and Copyright Statements . . . . . . . .  7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires August 4, 2005                 [Page 2]
-
-Internet-Draft           OCSP Support for PKINIT            January 2005
-
-
-1.  Introduction
-
-   Online Certificate Status Protocol (OCSP) [RFC2560] enables
-   applications to obtain timely information regarding the revocation
-   status of a certificate.  Because OCSP responses are well-bounded and
-   small in size, constrained clients may wish to use OCSP to check the
-   validity of the certificates for Kerberos Key Distribution Center
-   (KDC) in order to avoid transmission of large Certificate Revocation
-   Lists (CRLs) and therefore save bandwidth on constrained networks
-   [OCSP-PROFILE].
-
-   This document defines a pre-authentication type [CLARIFICATIONS],
-   where the client and the KDC MAY piggyback OCSP responses for
-   certificates used in authentication exchanges, as defined in
-   [PKINIT].
-
-   By using this OPTIONAL extension, PKINIT clients and the KDC can
-   maximize the reuse of cached OCSP responses.
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-3.  Message Definition
-
-   A pre-authentication type identifier is defined for this mechanism:
-
-              PA-PK-OCSP-RESPONSE              16
-
-   The corresponding padata-value field [CLARIFICATIONS] contains the
-   DER [X60] encoding of the following ASN.1 type:
-
-          PKOcspData ::= SEQUENCE OF OcspResponse
-
-          OcspResponse ::= OCTET STRING
-                         -- contains a complete OCSP response,
-                         -- defined in [RFC2560]
-
-   The client MAY send OCSP responses for certificates used in
-   PA-PK-AS-REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
-
-   The KDC that receives a PA-PK-OCSP-RESPONSE then SHOULD send a
-   PA-PK-OCSP-RESPONSE containing OCSP responses for certificates used
-   in the KDC's PA-PK-AS-REP.  The client can request a
-   PA-PK-OCSP-RESPONSE by using a PKOcspData containing an empty
-   sequence.
-
-
-
-Zhu, et al.              Expires August 4, 2005                 [Page 3]
-
-Internet-Draft           OCSP Support for PKINIT            January 2005
-
-
-   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
-   PA-PK-OCSP-RESPONSE from the client.
-
-   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
-   certificates used in PA-PK-AS-REP [PKINIT].
-
-   Note the lack of integrity protection for the empty or missing OCSP
-   response; lack of an expected OCSP response from the KDC for the
-   KDC's certificates SHOULD be treated as an error by the client,
-   unless it is configured otherwise.
-
-   When using OCSP, the response is signed by the OCSP server, which is
-   trusted by the receiver.  Depending on local policy, further
-   verification of the validity of the OCSP servers may be needed
-
-   The client and the KDC SHOULD ignore invalid OCSP responses received
-   via this mechanism, and they MAY implement CRL processing logic as a
-   fall-back position, if the OCSP responses received via this mechanism
-   alone are not sufficient for the verification of certificate
-   validity.  The client and/or the KDC MAY ignore a valid OCSP response
-   and perform their own revocation status verification independently.
-
-4.  Security Considerations
-
-   The pre-authentication data in this document do not actually
-   authenticate any principals, but is designed to be used in
-   conjunction with PKINIT.
-
-   There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
-   data and PKINIT pre-authentication data other than a given OCSP
-   response corresponding to a certificate used in a PKINIT
-   pre-authentication data element.  Attacks involving removal or
-   replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
-   are, at worst, downgrade attacks, where a PKINIT client or KDC would
-   proceed without use of CRLs or OCSP for certificate validation, or
-   denial of service attacks, where a PKINIT client or KDC that cannot
-   validate the other's certificate without an accompanying OCSP
-   response might reject the AS exchange or where they might have to
-   download very large CRLs in order to continue.  Kerberos V does not
-   protect against denial-of-service attacks, therefore the
-   denial-of-service aspect of these attacks are acceptable.
-
-   If a PKINIT client or KDC cannot validate certificates without the
-   aid of a valid PA-PK-OCSP-RESPONSE then it SHOULD fail the AS
-   exchange, possibly according to local configuration.
-
-
-
-
-
-
-Zhu, et al.              Expires August 4, 2005                 [Page 4]
-
-Internet-Draft           OCSP Support for PKINIT            January 2005
-
-
-5.  IANA Considerations
-
-   No IANA actions are required for this document.
-
-6.  Acknowledgements
-
-   This document was based on conversations among the authors, Jeffrey
-   Altman, Sam Hartman, Martin Rex and other members of the Kerberos
-   working group.
-
-7.  References
-
-7.1  Normative References
-
-   [CLARIFICATIONS]
-              RFC-Editor: To be replaced by RFC number for draft-ietf-
-              krb-wg-kerberos-clarifications.  Work in Progress. 
-
-   [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
-              cat-kerberos-pk-init.  Work in Progress. 
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
-              Adams, "X.509 Internet Public Key Infrastructure Online
-              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
-
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding 
-              Rules (BER), Canonical Encoding Rules (CER) and 
-              Distinguished Encoding Rules (DER), ITU-T Recommendation 
-              X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
-
-7.2  Informative References
-
-   [OCSP-PROFILE]
-              RFC-Editor: To be replaced by RFC number for draft-deacon-
-              lightweight-ocsp-profile.  Work in Progress.  
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-Zhu, et al.              Expires August 4, 2005                 [Page 5]
-
-Internet-Draft           OCSP Support for PKINIT            January 2005
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires August 4, 2005                 [Page 6]
-
-Internet-Draft           OCSP Support for PKINIT            January 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.              Expires August 4, 2005                 [Page 7]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-05.txt b/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-05.txt
deleted file mode 100644
index e777e3272..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-05.txt
+++ /dev/null
@@ -1,399 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                             K. Jaganathan
-Expires: November 21, 2005                         Microsoft Corporation
-                                                             N. Williams
-                                                        Sun Microsystems
-                                                            May 20, 2005
-
-
-                        OCSP Support for PKINIT
-                   draft-ietf-krb-wg-ocsp-for-pkinit-05
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667. 
-   
-   By submitting this Internet-Draft, each author represents
-   that any applicable patent or other IPR claims of which he
-   or she is aware have been or will be disclosed, and any of
-   which he or she becomes aware will be disclosed, in
-   accordance with Section 6 of BCP 79.
-   
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on November 21, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document defines a mechanism to enable in-band transmission of
-   Online Certificate Status Protocol (OCSP) responses in the Kerberos
-   network authentication protocol.  These responses are used to verify
-   the validity of the certificates used in PKINIT - the Kerberos
-
-
-
-Zhu, et al.             Expires November 21, 2005               [Page 1]
-
-Internet-Draft           OCSP Support for PKINIT                May 2005
-
-
-   Version 5 extension that provides for the use of public key
-   cryptography.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Message Definition . . . . . . . . . . . . . . . . . . . . . .  3
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
-     7.1   Normative References . . . . . . . . . . . . . . . . . . .  5
-     7.2   Informative References . . . . . . . . . . . . . . . . . .  5
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  5
-       Intellectual Property and Copyright Statements . . . . . . . .  7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires November 21, 2005               [Page 2]
-
-Internet-Draft           OCSP Support for PKINIT                May 2005
-
-
-1.  Introduction
-
-   Online Certificate Status Protocol (OCSP) [RFC2560] enables
-   applications to obtain timely information regarding the revocation
-   status of a certificate.  Because OCSP responses are well-bounded and
-   small in size, constrained clients may wish to use OCSP to check the
-   validity of the certificates for Kerberos Key Distribution Center
-   (KDC) in order to avoid transmission of large Certificate Revocation
-   Lists (CRLs) and therefore save bandwidth on constrained networks
-   [OCSP-PROFILE].
-
-   This document defines a pre-authentication type [CLARIFICATIONS],
-   where the client and the KDC MAY piggyback OCSP responses for
-   certificates used in authentication exchanges, as defined in
-   [PKINIT].
-
-   By using this OPTIONAL extension, PKINIT clients and the KDC can
-   maximize the reuse of cached OCSP responses.
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-3.  Message Definition
-
-   A pre-authentication type identifier is defined for this mechanism:
-
-              PA-PK-OCSP-RESPONSE              18
-
-   The corresponding padata-value field [CLARIFICATIONS] contains the
-   DER [X60] encoding of the following ASN.1 type:
-
-          PKOcspData ::= SEQUENCE OF OcspResponse
-                         -- If more than one OcspResponse is
-                         -- included, the first OcspResponse
-                         -- MUST contain the OCSP response
-                         -- for the signer's certificate.
-
-          OcspResponse ::= OCTET STRING
-                         -- Contains a complete OCSP response,
-                         -- as defined in [RFC2560].
-
-   The client MAY send OCSP responses for certificates used in PA-PK-AS-
-   REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
-
-   The KDC that receives a PA-PK-OCSP-RESPONSE then SHOULD send a PA-PK-
-
-
-
-Zhu, et al.             Expires November 21, 2005               [Page 3]
-
-Internet-Draft           OCSP Support for PKINIT                May 2005
-
-
-   OCSP-RESPONSE containing OCSP responses for certificates used in the
-   KDC's PA-PK-AS-REP.  The client can request a PA-PK-OCSP-RESPONSE by
-   using a PKOcspData containing an empty sequence.
-
-   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a PA-
-   PK-OCSP-RESPONSE from the client.
-
-   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
-   certificates used in PA-PK-AS-REP [PKINIT].
-
-   Note the lack of integrity protection for the empty or missing OCSP
-   response; lack of an expected OCSP response from the KDC for the
-   KDC's certificates SHOULD be treated as an error by the client,
-   unless it is configured otherwise.
-
-   When using OCSP, the response is signed by the OCSP server, which is
-   trusted by the receiver.  Depending on local policy, further
-   verification of the validity of the OCSP servers may be needed
-
-   The client and the KDC SHOULD ignore invalid OCSP responses received
-   via this mechanism, and they MAY implement CRL processing logic as a
-   fall-back position, if the OCSP responses received via this mechanism
-   alone are not sufficient for the verification of certificate
-   validity.  The client and/or the KDC MAY ignore a valid OCSP response
-   and perform their own revocation status verification independently.
-
-4.  Security Considerations
-
-   The pre-authentication data in this document do not actually
-   authenticate any principals, but is designed to be used in
-   conjunction with PKINIT.
-
-   There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
-   data and PKINIT pre-authentication data other than a given OCSP
-   response corresponding to a certificate used in a PKINIT pre-
-   authentication data element.  Attacks involving removal or
-   replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
-   are, at worst, downgrade attacks, where a PKINIT client or KDC would
-   proceed without use of CRLs or OCSP for certificate validation, or
-   denial of service attacks, where a PKINIT client or KDC that cannot
-   validate the other's certificate without an accompanying OCSP
-   response might reject the AS exchange or where they might have to
-   download very large CRLs in order to continue.  Kerberos V does not
-   protect against denial-of-service attacks, therefore the denial-of-
-   service aspect of these attacks are acceptable.
-
-   If a PKINIT client or KDC cannot validate certificates without the
-   aid of a valid PA-PK-OCSP-RESPONSE then it SHOULD fail the AS
-
-
-
-Zhu, et al.             Expires November 21, 2005               [Page 4]
-
-Internet-Draft           OCSP Support for PKINIT                May 2005
-
-
-   exchange, possibly according to local configuration.
-
-5.  IANA Considerations
-
-   No IANA actions are required for this document.
-
-6.  Acknowledgements
-
-   This document was based on conversations among the authors, Jeffrey
-   Altman, Sam Hartman, Martin Rex and other members of the Kerberos
-   working group.
-
-7.  References
-
-7.1  Normative References
-
-   [CLARIFICATIONS]
-              RFC-Editor: To be replaced by RFC number for draft-ietf-
-              krb-wg-kerberos-clarifications.  Work in Progress. 
-
-   [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
-              cat-kerberos-pk-init.  Work in Progress. 
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
-              Adams, "X.509 Internet Public Key Infrastructure Online
-              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
-
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding 
-              Rules (BER), Canonical Encoding Rules (CER) and 
-              Distinguished Encoding Rules (DER), ITU-T Recommendation 
-              X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
-
-7.2  Informative References
-
-   [OCSP-PROFILE]
-              RFC-Editor: To be replaced by RFC number for draft-deacon-
-              lightweight-ocsp-profile.  Work in Progress.  
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires November 21, 2005               [Page 5]
-
-Internet-Draft           OCSP Support for PKINIT                May 2005
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires November 21, 2005               [Page 6]
-
-Internet-Draft           OCSP Support for PKINIT                May 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.             Expires November 21, 2005               [Page 7]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-06.txt b/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-06.txt
deleted file mode 100644
index f6679d0cd..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-06.txt
+++ /dev/null
@@ -1,397 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                             K. Jaganathan
-Expires: January 20, 2006                          Microsoft Corporation
-                                                             N. Williams
-                                                        Sun Microsystems
-                                                           July 19, 2005
-
-
-                        OCSP Support for PKINIT
-                  draft-ietf-krb-wg-ocsp-for-pkinit-06
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 20, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document defines a mechanism to enable in-band transmission of
-   Online Certificate Status Protocol (OCSP) responses in the Kerberos
-   network authentication protocol.  These responses are used to verify
-   the validity of the certificates used in PKINIT - the Kerberos
-   Version 5 extension that provides for the use of public key
-   cryptography.
-
-
-
-Zhu, et al.             Expires January 20, 2006                [Page 1]
-
-Internet-Draft           OCSP Support for PKINIT               July 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Message Definition . . . . . . . . . . . . . . . . . . . . . .  3
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
-     7.1   Normative References . . . . . . . . . . . . . . . . . . .  5
-     7.2   Informative References . . . . . . . . . . . . . . . . . .  5
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  5
-       Intellectual Property and Copyright Statements . . . . . . . .  7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires January 20, 2006                [Page 2]
-
-Internet-Draft           OCSP Support for PKINIT               July 2005
-
-
-1.  Introduction
-
-   Online Certificate Status Protocol (OCSP) [RFC2560] enables
-   applications to obtain timely information regarding the revocation
-   status of a certificate.  Because OCSP responses are well-bounded and
-   small in size, constrained clients may wish to use OCSP to check the
-   validity of the certificates for Kerberos Key Distribution Center
-   (KDC) in order to avoid transmission of large Certificate Revocation
-   Lists (CRLs) and therefore save bandwidth on constrained networks
-   [OCSP-PROFILE].
-
-   This document defines a pre-authentication type [RFC4120], where the
-   client and the KDC MAY piggyback OCSP responses for certificates used
-   in authentication exchanges, as defined in [PKINIT].
-
-   By using this OPTIONAL extension, PKINIT clients and the KDC can
-   maximize the reuse of cached OCSP responses.
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-3.  Message Definition
-
-   A pre-authentication type identifier is defined for this mechanism:
-
-              PA-PK-OCSP-RESPONSE              18
-
-   The corresponding padata-value field [RFC4120] contains the DER [X60]
-   encoding of the following ASN.1 type:
-
-          PKOcspData ::= SEQUENCE OF OcspResponse
-                         -- If more than one OcspResponse is
-                         -- included, the first OcspResponse
-                         -- MUST contain the OCSP response
-                         -- for the signer's certificate.
-                         -- The signer refers to the client for
-                         -- AS-REQ, and the KDC for the AS-REP,
-                         -- respectively.
-
-          OcspResponse ::= OCTET STRING
-                         -- Contains a complete OCSP response,
-                         -- as defined in [RFC2560].
-
-   The client MAY send OCSP responses for certificates used in PA-PK-AS-
-   REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
-
-
-
-Zhu, et al.             Expires January 20, 2006                [Page 3]
-
-Internet-Draft           OCSP Support for PKINIT               July 2005
-
-
-   The KDC that receives a PA-PK-OCSP-RESPONSE then SHOULD send a PA-PK-
-   OCSP-RESPONSE containing OCSP responses for certificates used in the
-   KDC's PA-PK-AS-REP.  The client can request a PA-PK-OCSP-RESPONSE by
-   using a PKOcspData containing an empty sequence.
-
-   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a PA-
-   PK-OCSP-RESPONSE from the client.
-
-   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
-   certificates used in PA-PK-AS-REP [PKINIT].
-
-   Note the lack of integrity protection for the empty or missing OCSP
-   response; lack of an expected OCSP response from the KDC for the
-   KDC's certificates SHOULD be treated as an error by the client,
-   unless it is configured otherwise.
-
-   When using OCSP, the response is signed by the OCSP server, which is
-   trusted by the receiver.  Depending on local policy, further
-   verification of the validity of the OCSP servers may be needed
-
-   The client and the KDC SHOULD ignore invalid OCSP responses received
-   via this mechanism, and they MAY implement CRL processing logic as a
-   fall-back position, if the OCSP responses received via this mechanism
-   alone are not sufficient for the verification of certificate
-   validity.  The client and/or the KDC MAY ignore a valid OCSP response
-   and perform their own revocation status verification independently.
-
-4.  Security Considerations
-
-   The pre-authentication data in this document do not actually
-   authenticate any principals, but is designed to be used in
-   conjunction with PKINIT.
-
-   There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
-   data and PKINIT pre-authentication data other than a given OCSP
-   response corresponding to a certificate used in a PKINIT pre-
-   authentication data element.  Attacks involving removal or
-   replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
-   are, at worst, downgrade attacks, where a PKINIT client or KDC would
-   proceed without use of CRLs or OCSP for certificate validation, or
-   denial of service attacks, where a PKINIT client or KDC that cannot
-   validate the other's certificate without an accompanying OCSP
-   response might reject the AS exchange or where they might have to
-   download very large CRLs in order to continue.  Kerberos V does not
-   protect against denial-of-service attacks, therefore the denial-of-
-   service aspect of these attacks are acceptable.
-
-   If a PKINIT client or KDC cannot validate certificates without the
-
-
-
-Zhu, et al.             Expires January 20, 2006                [Page 4]
-
-Internet-Draft           OCSP Support for PKINIT               July 2005
-
-
-   aid of a valid PA-PK-OCSP-RESPONSE then it SHOULD fail the AS
-   exchange, possibly according to local configuration.
-
-5.  IANA Considerations
-
-   No IANA actions are required for this document.
-
-6.  Acknowledgements
-
-   This document was based on conversations among the authors, Jeffrey
-   Altman, Sam Hartman, Martin Rex and other members of the Kerberos
-   working group.
-
-7.  References
-
-7.1  Normative References
-
-   [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
-              cat-kerberos-pk-init.  Work in Progress. 
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
-              Adams, "X.509 Internet Public Key Infrastructure Online
-              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding 
-              Rules (BER), Canonical Encoding Rules (CER) and 
-              Distinguished Encoding Rules (DER), ITU-T Recommendation 
-              X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
-
-7.2  Informative References
-
-   [OCSP-PROFILE]
-              RFC-Editor: To be replaced by RFC number for draft-deacon-
-              lightweight-ocsp-profile.  Work in Progress.  
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires January 20, 2006                [Page 5]
-
-Internet-Draft           OCSP Support for PKINIT               July 2005
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires January 20, 2006                [Page 6]
-
-Internet-Draft           OCSP Support for PKINIT               July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.             Expires January 20, 2006                [Page 7]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-otp-preauth-05.txt b/doc/standardisation/draft-ietf-krb-wg-otp-preauth-05.txt
deleted file mode 100644
index c40b83459..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-otp-preauth-05.txt
+++ /dev/null
@@ -1,1848 +0,0 @@
-

-

-

-Network Working Group                                        G. Richards

-Internet-Draft                         RSA, The Security Division of EMC

-Intended status: Standards Track                           July 14, 2008

-Expires: January 15, 2009

-

-

-                         OTP Pre-authentication

-                    draft-ietf-krb-wg-otp-preauth-05

-

-Status of this Memo

-

-   By submitting this Internet-Draft, each author represents that any

-   applicable patent or other IPR claims of which he or she is aware

-   have been or will be disclosed, and any of which he or she becomes

-   aware will be disclosed, in accordance with Section 6 of BCP 79.

-

-   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."

-

-   The list of current Internet-Drafts can be accessed at

-   http://www.ietf.org/ietf/1id-abstracts.txt.

-

-   The list of Internet-Draft Shadow Directories can be accessed at

-   http://www.ietf.org/shadow.html.

-

-   This Internet-Draft will expire on January 15, 2009.

-

-Abstract

-

-   The Kerberos protocol provides a framework authenticating a client

-   using the exchange of pre-authentication data.  This document

-   describes the use of this framework to carry out One Time Password

-   (OTP) authentication.

-

-

-

-

-

-

-

-

-

-

-

-Richards                Expires January 15, 2009                [Page 1]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-Table of Contents

-

-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

-     1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  3

-     1.2.  Overall Design . . . . . . . . . . . . . . . . . . . . . .  3

-     1.3.  Conventions Used in this Document  . . . . . . . . . . . .  4

-   2.  Usage Overview . . . . . . . . . . . . . . . . . . . . . . . .  4

-     2.1.  OTP Mechanism Support  . . . . . . . . . . . . . . . . . .  4

-     2.2.  Pre-Authentication . . . . . . . . . . . . . . . . . . . .  4

-     2.3.  PIN Change . . . . . . . . . . . . . . . . . . . . . . . .  5

-     2.4.  Re-Synchronization . . . . . . . . . . . . . . . . . . . .  6

-   3.  Pre-Authentication Protocol Details  . . . . . . . . . . . . .  6

-     3.1.  Initial Client Request . . . . . . . . . . . . . . . . . .  6

-     3.2.  KDC Challenge  . . . . . . . . . . . . . . . . . . . . . .  6

-     3.3.  Client Response  . . . . . . . . . . . . . . . . . . . . .  7

-     3.4.  Verifying the pre-auth Data  . . . . . . . . . . . . . . .  9

-     3.5.  Confirming the Reply Key Change  . . . . . . . . . . . . . 10

-     3.6.  Reply Key Generation . . . . . . . . . . . . . . . . . . . 11

-   4.  OTP Kerberos Message Types . . . . . . . . . . . . . . . . . . 13

-     4.1.  PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 13

-     4.2.  PA-OTP-REQUEST . . . . . . . . . . . . . . . . . . . . . . 15

-     4.3.  PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 18

-     4.4.  PA-OTP-PIN-CHANGE  . . . . . . . . . . . . . . . . . . . . 19

-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19

-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19

-     6.1.  Man-in-the-Middle  . . . . . . . . . . . . . . . . . . . . 19

-     6.2.  Reflection . . . . . . . . . . . . . . . . . . . . . . . . 20

-     6.3.  Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 20

-     6.4.  Brute Force Attack . . . . . . . . . . . . . . . . . . . . 20

-     6.5.  FAST Facilities  . . . . . . . . . . . . . . . . . . . . . 20

-   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21

-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21

-     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 21

-     8.2.  Informative References . . . . . . . . . . . . . . . . . . 21

-   Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 22

-   Appendix B.  Examples of OTP Pre-Authentication Exchanges  . . . . 24

-     B.1.  Four Pass Authentication . . . . . . . . . . . . . . . . . 24

-     B.2.  Two Pass Authentication  . . . . . . . . . . . . . . . . . 27

-     B.3.  Pin Change . . . . . . . . . . . . . . . . . . . . . . . . 29

-     B.4.  Resynchronization  . . . . . . . . . . . . . . . . . . . . 30

-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32

-   Intellectual Property and Copyright Statements . . . . . . . . . . 33

-

-

-

-

-

-

-

-

-

-Richards                Expires January 15, 2009                [Page 2]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-1.  Introduction

-

-1.1.  Scope

-

-   This document describes a FAST [ZhHa07] factor that allows One-Time

-   Password (OTP) values to be used in the Kerberos V5 [RFC4120] pre-

-   authentication in a manner that does not require use of the user's

-   Kerberos password.  The system is designed to work with different

-   types of OTP algorithms such as time-based OTPs [RFC2808], counter-

-   based tokens [RFC4226], challenge-response and [RFC2289] type

-   systems.  It is also designed to work with tokens that are

-   electronically connected to the user's computer via means such as a

-   USB interface.

-

-   This FAST factor provides the following facilities (as defined in

-   [ZhHa07]): client-authentication, replacing-reply-key and KDC-

-   authentication.  It does not provide the strengthening-reply-key

-   facility.

-

-   This proposal is partially based upon previous work on integrating

-   single-use authentication mechanisms into Kerberos [HoReNeZo04] and

-   allows for the use of the existing password-change extensions to

-   handle PIN change as described in [RFC3244].

-

-1.2.  Overall Design

-

-   This proposal supports 4-pass and 2-pass variants.  In the 4-pass

-   system, the client sends the KDC an initial AS-REQ and the KDC

-   responds with a KRB-ERROR containing padata that includes a random

-   nonce.  The client then encrypts the nonce and returns it along with

-   its own random value to the KDC in a second AS-REQ.  Finally, the KDC

-   returns the client's random value encrypted within the padata of the

-   AS-REP.  In the 2-pass variant, the client encrypts a timestamp

-   rather than a nonce from the KDC and the encrypted data is sent to

-   the KDC in the initial AS-REQ.  This variant can be used in cases

-   where the client can determine in advance that OTP pre-authentication

-   is supported by the KDC and which OTP key should be used.

-

-   In both systems, in order to create the message sent to the KDC, the

-   client must generate the OTP value and three keys: the standard Reply

-   Key, a key to encrypt the data sent to the KDC and a final key to

-   decrypt the KDC's reply.  In most cases, the OTP value will be used

-   in the key generation but in order to support algorithms where the

-   KDC cannot obtain the value (e.g.  [RFC2289]), the system also

-   supports the option of including the OTP value in the request along

-   with the encrypted nonce.  In addition, in order to support

-   situations where the KDC is unable to obtain the plaintext OTP value,

-   the system also supports the use of hashed OTP values in the key

-

-

-

-Richards                Expires January 15, 2009                [Page 3]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   derivation.

-

-   The message from the client to the KDC is sent within the encrypted

-   data provided by the FAST padata type of the AS-REQ.  The KDC then

-   obtains the OTP value, generates the same keys and verifies the pre-

-   authentication data by decrypting the nonce.  If the verification

-   succeeds then it confirms knowledge of the Reply Key by returning the

-   client's nonce encrypted under one of the generated keys within the

-   encrypted part of the FAST padata of the AS-REP.

-

-1.3.  Conventions Used in this Document

-

-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

-   document are to be interpreted as described in [RFC2119].

-

-   This document assumes familiarity with the Kerberos preauthentication

-   framework [ZhHa07] and so freely uses terminology and notation from

-   this document.

-

-   The word padata is used as shorthand for pre-authentication data.

-

-

-2.  Usage Overview

-

-2.1.  OTP Mechanism Support

-

-   As described above, this document describes a generic system for

-   supporting different OTP mechanisms in Kerberos pre-authentication.

-   However, to ensure interoperability, all implementations of this

-   specification SHOULD provide a mechanism for OTP mechanism support to

-   be added or removed.

-

-2.2.  Pre-Authentication

-

-   The approach uses pre-authentication data in AS-REQ, AS-REP and KRB-

-   ERROR messages.

-

-   In the 4-pass system, the client begins by sending an initial AS-REQ

-   to the KDC that may contain pre-authentication data such as the

-   standard Kerberos password data.  The KDC will then determine, in an

-   implementation dependent fashion, whether OTP authentication is

-   required and if it is, it will respond with a KRB-ERROR message

-   containing a PA-OTP-CHALLENGE in the PA-DATA.

-

-   The PA-OTP-CHALLENGE will contain a KDC generated nonce, an

-   encryption type, an optional list of hash algorithm identifiers, an

-   optional iteration count and optional information on how the OTP

-

-

-

-Richards                Expires January 15, 2009                [Page 4]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   should be generated by the client.  The client will then generate the

-   OTP value, its own nonce and two keys: a Client Key to encrypt the

-   KDC's nonce and a Reply Key used to decrypt the KDC's reply.

-

-   As described in Section 3.6, these keys will be generated from the

-   Armor Key (defined in [ZhHa07]) and the OTP value unless the OTP

-   algorithm does not allow the KDC to obtain the OTP value.  If hash

-   algorithm identifiers were included in the PA-OTP-CHALLENGE then the

-   client will use the hash of the OTP value rather than the plaintext

-   value in the key generation.

-

-   The generated Client Key will be used to encrypt the nonce received

-   from the KDC using the specified encryption type.  The encrypted

-   value, a random nonce generated by the client along with optional

-   information on how the OTP was generated are then sent to the KDC in

-   a PA-OTP-REQUEST element encrypted within the armored-data of a PA-

-   FX-FAST-REQUEST PA-DATA element of a second AS-REQ.

-

-   In the 2-pass system, the client sends the PA-OTP-REQUEST in the

-   initial AS-REQ instead of sending it in response to a PA-OTP-

-   CHALLENGE returned by the KDC.  Since no challenge is received from

-   the KDC, the client includes an encrypted timestamp in the request

-   rather than the encrypted KDC nonce.

-

-   In both cases, on receipt of a PA-OTP-REQUEST, the KDC generate the

-   same keys as the client, and use the generated Client Key to verify

-   the pre-authentication by decrypting the encrypted data sent by the

-   client (either nonce or timestamp).  If the validation succeeds then

-   the KDC will authenticate itself to the client and confirm that the

-   Reply Key has been updated by encrypting the client's nonce under the

-   Reply Key and returning the encrypted value in the encData of a PA-

-   OTP-CONFIRM.  The PA-OTP-CONFIRM is encrypted within the armored-data

-   of a PA-FX-FAST-REPLY PA-DATA element of the AS-REP as described in

-   [ZhHa07].

-

-2.3.  PIN Change

-

-   If, following successful validation of a PA-OTP-REQUEST in a AS-REQ,

-   the KDC requires that the user changes their PIN then it will include

-   a PA-OTP-PIN-CHANGE element in the armored data of the PA-FX-FAST-

-   REPLY PA-DATA element of the AS-REP.  This data can be used to return

-   a new PIN to the user if the KDC has updated the PIN or to indicate

-   to the user that they must change their PIN.

-

-   In the latter case, it is recommended that user PIN change be handled

-   by a PIN change service supporting the ChangePasswdData in a AP-REQ

-   as described in [RFC3244].  If a user PIN for OTP is required to

-   change and such a service is used then the KDC MUST NOT return a TGT

-

-

-

-Richards                Expires January 15, 2009                [Page 5]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   when the user is authenticated using this PIN.  The KDC SHOULD return

-   a service ticket to the PIN change service when the existing PIN is

-   required to change, in order for the client to compute an AP-REQ

-   according to [RFC3244].  In order to complicate stealing service

-   tickets intended for the PIN change service (and the corresponding

-   session keys), the lifetime of the PIN-change service tickets should

-   be just long enough to complete the PIN change, regardless whether

-   the exiting PIN needs to be changed or not.  A 1-minute lifetime is

-   RECOMMENED.  This way the PIN change service can effectively force

-   the user to present the existing PIN in order to change to use a new

-   PIN.

-

-2.4.  Re-Synchronization

-

-   It is possible with time and event-based tokens that the OTP server

-   will lose synchronization with the current token state.  If, when

-   processing a PA-OTP-REQUEST, the pre-authentication validation fails

-   for this reason then the KDC SHALL return a KRB-ERROR message

-   containing a PA-OTP-CHALLENGE in the PA-DATA with the "nextOTP" flag

-   set.  If this flag is set then the client MUST re-try the

-   authentication using the OTP for the token "state" after that used in

-   the failed authentication attempt.

-

-

-3.  Pre-Authentication Protocol Details

-

-3.1.  Initial Client Request

-

-   In the 4-pass mode, the client begins by sending an initial AS-REQ

-   possibly containing other pre-authentication data.  If the KDC

-   determines that OTP-based pre-authentication is required and the

-   request does not contain a PA-OTP-REQUEST then it will respond as

-   described in Section 3.2.

-

-   If the client has all the necessary information, it MAY use the

-   2-pass system by constructing a PA-OTP-REQUEST as described in

-   Section 3.3 and including it in the initial request.

-

-3.2.  KDC Challenge

-

-   If the user is required to authenticate using an OTP then the KDC

-   SHALL respond to the initial AS-REQ with a KRB-ERROR containing:

-

-   o  An error code of KDC_ERR_PREAUTH_REQUIRED

-

-   o  An e-data field containing PA-DATA with a PA-OTP-CHALLENGE.

-

-   The PA-OTP-CHALLENGE SHALL contain a random nonce value to be

-

-

-

-Richards                Expires January 15, 2009                [Page 6]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   returned encrypted in the client response and the encryption type to

-   be used by the client.

-

-   If the OTP is to be generated using an server generated challenge

-   then the value of the challenge SHALL be included in the otp-

-   challenge field.  If the OTP is to be generated by combining the

-   challenge with the token's current state (e.g. time) then the

-   "combine" flag SHALL be set.

-

-   The KDC MAY use the otp-service to identify the service provided by

-   the KDC in order to assist the client in locating the OTP token to be

-   used.  For example, this field could be used when a client has

-   multiple OTP tokens from different servers to identify the KDC.

-   Similarly, if the KDC can determine which OTP token key is the be

-   used, then the otp-keyID field MAY be used to pass that value to the

-   client.

-

-   The otp-algID field MAY be used to identify the algorithm that should

-   be used in the OTP calculation.  For example, it could be used when a

-   user has been issued with multiple tokens of different types.

-

-   In order to support connected tokens that can generate OTP values of

-   varying length, the KDC MAY include the desired length of the OTP in

-   the otp-length field.

-

-   In order to support cases where the KDC cannot obtain plaintext

-   values for the OTPs, the challenge MAY also contain a sequence of one

-   way hash function algorithm identifiers and a minimum value of the

-   iteration count to be used by the client when hashing the OTP value.

-

-3.3.  Client Response

-

-   The client response SHALL be sent to the KDC as a PA-OTP-REQUEST

-   included within the enc-fast-req of a PA-FX-FAST-REQUEST encrypted

-   under the current Armor Key as described in [ZhHa07].

-

-   In order to generate its response, the client must generate an OTP

-   value.  The OTP value MUST be based on the parameters in the KDC

-   challenge if present and the response SHOULD include any information

-   on the generated OTP value reported by the OTP token

-

-   If the "nextOTP" flag is set in the PA-OTP-CHALLENGE, then the client

-   MUST generate the OTP value in the next token state that that used in

-   the previous PA-OTP-REQUEST.  The "nextOTP" flag must also be set in

-   the PA-OTP-REQUEST.

-

-   The otp-time and otp-counter fields MAY be used to return the time

-   and counter values used by the token.  The otp-format field MAY be

-

-

-

-Richards                Expires January 15, 2009                [Page 7]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   used to report the format of the generated OTP.  This field SHOULD be

-   used if a token can generate OTP values in multiple formats.  The

-   otp-algID field MAY be used by the client to report the algorithm

-   used in the OTP calculation and the otp-keyID MAY be used to report

-   the identifier of the OTP token key used.

-

-   If an otp-challenge is present in the PA-OTP-CHALLENGE then the OTP

-   value MUST be generated based on a challenge if the token is capable

-   of accepting a challenge.  The client MAY ignore the provided

-   challenge if and only if the token is not capable of including a

-   challenge in the OTP calculation.  If the "combine" flag is not set

-   in the PA-OTP-CHALLENGE then the OTP SHALL be calculated based only

-   the challenge and not the internal state (e.g. time or counter) of

-   the token.  If the "combine" flag is set then the OTP SHALL be

-   calculated using both the internal state and the provided challenge.

-   If the flag is set but otp-challenge is not present then the client

-   SHALL regard the request as invalid.

-

-   If the OTP value was generated by a challenge not sent by the KDC

-   then the challenge SHALL be included in the otp-challenge of the PA-

-   OTP-RESPONSE.  If the OTP was generated by combining a challenge

-   (either received from the KDC or generated by the client) with the

-   token state then the "combine" flag SHALL be set in the PA-OTP-

-   RESPONSE.

-

-   The client MUST derive the Client Key and Reply Key as described in

-   Section 3.6.  In order to support OTP algorithms where the KDC cannot

-   obtain the OTP value, the client MAY include the generated value in

-   the otp-value field of the response.  However, the client MUST NOT

-   include the OTP value in the response unless it is allowed by the

-   algorithm profile.  If it is included then the OTP value MUST NOT be

-   used in the key derivation.

-

-   If the client used hashed OTP values in the key derivation process

-   then it MUST include the hash algorithm and iteration count used in

-   the hashAlg and iterationCount fields of the PA-OTP-REQUEST.  These

-   fields MUST NOT be included if hashed OTP values were not used.  It

-   is RECOMMENDED that the iteration count used by the client be chosen

-   in such a way that it is computationally infeasible/unattractive for

-   an attacker to brute-force search for the given OTP within the

-   lifetime of that OTP.

-

-   If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE

-   that contained hash algorithm identifiers and the OTP value is to be

-   used in the key derivation then the client MUST use hashed OTP values

-   and MUST select the first algorithm from the list that it supports.

-   However, if the algorithm identifiers do not conform to local policy

-   restrictions then the authentication attempt MUST NOT proceed.  If

-

-

-

-Richards                Expires January 15, 2009                [Page 8]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   the iteration count specified in the PA-OTP-CHALLENGE does not

-   conform to local policy then the client MAY use a higher value but

-   MUST NOT use a lower value.  That is, the value in the KDC challenge

-   is a minimum value.

-

-   The generated Client Key is used by the client to encrypt data to be

-   included in the encData of the response to allow the KDC to

-   authenticate the user.  The key usage for this encryption is

-   KEY_USAGE_OTP_REQUEST.

-

-   o  If the response is being generated in response to a KDC challenge

-      then client encrypts a PA-OTP-ENC-REQUEST containing the value of

-      nonce from the corresponding challenge using the encryption type

-      specified in the challenge.

-

-   o  If the response is not in response to a KDC challenge then the

-      client encrypts a PA-ENC-TS-ENC containing the current time as in

-      the encrypted timestamp pre-authentication mechanism [RFC4120].

-

-   If the client is working in 2-pass mode and so is not responding to

-   an initial KDC challenge then the values of the iteration count, hash

-   algorithms and encryption type cannot be obtained from that

-   challenge.  The client SHOULD use any values obtained from a previous

-   PA-OTP-CHALLENGE or, if no values are available, it MAY use initial

-   configured values.

-

-   Finally, the client generates a random value to include in the nonce

-   of the response.  This value will then be returned encrypted by the

-   KDC.

-

-3.4.  Verifying the pre-auth Data

-

-   The KDC validates the pre-authentication data by generating the same

-   keys as the client and using the generated Client Key to decrypt the

-   value of encData from the PA-OTP-REQUEST.

-

-   If the otp-value field is included in the PA-OTP-REQUEST then the KDC

-   MUST use that value in the key generation.  Otherwise, the KDC will

-   need to generate or obtain the value.

-

-   If the otp-challenge field is present, then the OTP was calculated

-   using that challenge.  If the "combine" flag is also set, then the

-   OTP was calculated using the challenge and the token's current state.

-

-   It is RECOMMENDED that the KDC acts upon the values of otp-time, otp-

-   counter, otp-format, otp-algID and otp-keyID if they are present in

-   the PA-OTP-REQUEST.  If the KDC receives a request containing these

-   values but cannot act upon theme then they MAY be ignored.

-

-

-

-Richards                Expires January 15, 2009                [Page 9]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   The KDC generates the Client Key and Reply Key as described in

-   Section 3.6 from the OTP value using the hash algorithm and iteration

-   count if present in the PA-OTP-REQUEST.  However, the client

-   authentication MUST fail if the KDC requires hashed OTP values and

-   the hashAlg field was not present in the PA-OTP-REQUEST, if the hash

-   algorithm identifier or the value of iterationCount included in the

-   PA-OTP-REQUEST do not conform to local KDC policy or if the value of

-   the iterationCount is less than that specified in the PA-OTP-

-   CHALLENGE.

-

-   The generated Client Key is then used to decrypt the encData from the

-   PA-OTP-REQUEST.  If the client response was sent as a result of a PA-

-   OTP-CHALLENGE then decrypted data will be a PA-OTP-ENC-REQUEST and

-   the client authentication MUST fail if the nonce value from the PA-

-   OTP-ENC-REQUEST is not the same as the nonce value sent in the PA-

-   OTP-CHALLENGE.  If the response was not sent as a result of a PA-OTP-

-   CHALLENGE then the decrypted value will be a PA-ENC-TS-ENC and the

-   authentication process will be the same as with standard encrypted

-   timestamp pre-authentication [RFC4120]

-

-   The authentication MUST fail if the encryption type used by the

-   client in the encData does not conform to policy.

-

-   If authentication fails due to the hash algorithm, iteration count or

-   encryption type used by the client then the KDC SHOULD return a PA-

-   OTP-CHALLENGE with the required values in the error response.  If the

-   authentication fails due to the token state on the server no longer

-   being synchronized with the token used then the KDC SHALL return a

-   PA-OTP-CHALLENGE with the "nextOTP" flag set as described in

-   Section 2.4.

-

-   If during the authentication process, the KDC determines that the

-   user's PIN has expired then it MAY include a PA-OTP-PIN-CHANGE in the

-   response as described in Section 2.3

-

-3.5.  Confirming the Reply Key Change

-

-   If the pre-authentication data was successfully verified, then, in

-   order to support mutual authentication, the KDC SHALL respond to the

-   client's PA-OTP-REQUEST by including in the AS-REP, a PA-OTP-CONFIRM

-   containing the client's nonce from PA-OTP-REQUEST encrypted under the

-   generated Reply Key.

-

-   The nonce SHALL be returned within a PA-OTP-ENC-CONFIRM encrypted

-   within the encData of the PA-OTP-CONFIRM.  The key usage SHALL be

-   KEY_USAGE_OTP_CONFIRM and the encryption type SHOULD be the same as

-   used by the client in the encData of the PA-OTP-REQUEST.

-

-

-

-

-Richards                Expires January 15, 2009               [Page 10]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   The PA-OTP-CONFIRM SHALL be sent to the client within the enc-fast-

-   rep of a PA-FX-FAST-REPLY encrypted under the current Armor Key.

-

-   The client then uses its generated Reply Key to decrypt the PA-OTP-

-   ENC-CONFIRM from the encData of the PA-OTP-CONFIRM.  The client MUST

-   fail the authentication process if the nonce value in the PA-OTP-ENC-

-   CONFIRM is not the same as the nonce value sent in the PA-OTP-

-   REQUEST.

-

-3.6.  Reply Key Generation

-

-   In order to authenticate the user, the client and KDC need to

-   generate two encryption keys:

-

-   o  The Client Key to be used by the client to encrypt and by the KDC

-      to decrypt the encData in the PA-OTP-REQUEST.

-

-   o  The Reply Key to be used in the standard manner by the KDC to

-      encrypt data in the AS-REP but also to be used by the KDC to

-      encrypt and by the client to decrypt the encData value in the PA-

-      OTP-CONFIRM.

-

-   The method used to generate the three keys will depend on the OTP

-   algorithm.

-

-   o  If the OTP value is included in the otp-value of the PA-OTP-

-      REQUEST then all three keys SHALL be the same as the Armor Key

-      (defined in [ZhHa07]).

-

-   o  If the OTP value is not included in the otp-value of the PA-OTP-

-      REQUEST then the three keys SHALL be derived from the Armor Key

-      and the OTP value as described below.

-

-   If the OTP value is not included in the PA-OTP-REQUEST, then the

-   Reply Key SHALL be generated using the KRB_FX_CF2 algorithm from

-   [ZhHa07]

-

-             Client Key = KRB_FX_CF2(K1, K2, O1, O2)

-             Reply Key = KRB_FX_CF2(K1, K2, O3, O4)

-

-   The first input keys, K1, shall be the Armor Key. The second input

-   key, K2, shall be derived from the OTP value using string-to-key

-   (defined in [RFC3961]).

-

-   The octet string parameters, O1, O2, O3 and O4, shall be the ASCII

-   string "Combine1", "Combine2", "Combine3" and "Combine4" as shown

-   below:

-

-

-

-

-Richards                Expires January 15, 2009               [Page 11]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x31}

-      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x32}

-      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x33}

-      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x34}

-

-   If the hash of the OTP value is to be used then K2 SHALL be derived

-   as follows:

-

-   o  An initial hash value, H, is generated:

-

-             H = hash(sname|nonce|OTP)

-

-      Where:

-      *  "|" denotes concatenation

-      *  hash is the hash algorithm selected by the client.

-      *  sname is the UTF-8 encoding of the KDC's fully qualified domain

-         name.  If the domain name is an Internationalized Domain Name

-         then the value shall be the output of nameprep [RFC3491] as

-         described in [RFC3490]

-      *  nonce is the random nonce value generated by the client to be

-         included in the PA-OTP-REQUEST.

-      *  OTP is the OTP value.

-

-   o  The initial hash value is then hashed iterationCount-1 times to

-      produce a final hash value, H'.  (Where iterationCount is the

-      value from the PA-OTP-REQUEST.)

-

-             H' = hash(hash(...(iterationCount-1 times)...(H)))

-

-   o  The value of K2 is then derived from the base64 [RFC2045] encoding

-      of this final hash value.

-

-             K2 = string-to-key(Base64(H')||"Krb-preAuth")

-

-   If the OTP value is binary and the hash value is not used, then K2

-   SHALL be derived from the base64 encoding of the OTP value.

-

-             K2 = string-to-key(Base64(OTP)||"Krb-preAuth")

-

-   If the OTP value is not binary and the hash value is not used, then

-   K2 SHALL be derived by running the OTP value once through string-to-

-   key.

-

-             K2 = string-to-key(OTP||"Krb-preAuth")

-

-   The salt and any additional parameters for string-to-key will be

-   derived as described in section 3.1.3 of [RFC4120] using preauth data

-   or default values defined for the particular enctype.  The symbol

-

-

-

-Richards                Expires January 15, 2009               [Page 12]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   "||" denotes string concatenation.

-

-

-4.  OTP Kerberos Message Types

-

-4.1.  PA-OTP-CHALLENGE

-

-   The PA_OTP_CHALLENGE padata type is sent by the KDC to the client in

-   the PA-DATA of a KRB-ERROR when pre-authentication using an OTP value

-   is required.  The corresponding padata-value field contains the DER

-   encoding of a PA-OTP-CHALLENGE containing a server generated nonce

-   and information for the client on how to generate the OTP.

-

-             PA_OTP_CHALLENGE     << TBA >>

-

-             PA-OTP-CHALLENGE ::= SEQUENCE {

-               flags              OTPFlags,

-               nonce              UInt32,

-               etype              Int32,

-               supportedHashAlg   SEQUENCE OF AlgorithmIdentifier

-                                                  OPTIONAL,

-               iterationCount     INTEGER         OPTIONAL,

-               otp-challenge      OCTET STRING (SIZE(8..MAX)) OPTIONAL,

-               otp-length     [0] Int32           OPTIONAL,

-               otp-service        UTF8String      OPTIONAL,

-               otp-keyID      [1] OCTET STRING    OPTIONAL,

-               otp-algID          AnyURI          OPTIONAL,

-               ...

-             }

-

-             OTPFlags ::= KerberosFlags

-             -- nextOTP (0)

-             -- combine (1)

-

-   flags

-      If the "nextOTP" flag is set then the OTP SHALL be based on the

-      next token "state" rather than the current one.  As an example,

-      for a time-based token, this means the next time slot and for an

-      event-based token, this could mean the next counter value.

-

-      The "combine flag controls how the challenge included in otp-

-      challenge shall be used.  If the flag is set then OTP SHALL be

-      calculated using the challenge from otp-challenge and the internal

-      token state (e.g. time or counter).  If the "combine" flag is not

-      set then the OTP SHALL be calculated based only on the challenge.

-      If the flag is set and otp-challenge is not present then the

-      request SHALL be regarded as invalid.

-

-

-

-

-Richards                Expires January 15, 2009               [Page 13]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   nonce

-      A KDC-supplied nonce value to be encrypted by the client in the

-      PA-OTP-REQUEST.

-

-   etype

-      The encryption type to be used by the client to encrypt the nonce

-      in the PA-OTP-REQUEST.

-

-   supportedHashAlg

-      If present then a hash of the OTP value MUST be used in the key

-      derivation rather than the plain text value.  Each

-      AlgorithmIdentifier identifies a hash algorithm that is supported

-      by the KDC in decreasing order of preference.  The client MUST

-      select the first algorithm from the list that it supports.

-      Support for SHA1 by both the client and KDC is REQUIRED.  The

-      AlgorithmIdentifer selected by the client MUST be placed in the

-      hashAlg element of the PA-OTP-REQUEST.

-

-   iterationCount

-      The minimum value of the iteration count to be used by the client

-      when hashing the OTP value.  This value MUST be present if and

-      only if supportedHashAlg is present.  If the value of this element

-      does not conform to local policy on the client then the client MAY

-      use a larger value but MUST NOT use a lower value.  The value of

-      the iteration count used by the client MUST be returned in the PA-

-      OTP-REQUEST sent to the KDC.

-

-   otp-challenge

-      The otp-challenge is used by the KDC to send a challenge value for

-      use in the OTP calculation.  The challenge is an optional octet

-      string that SHOULD be uniquely generated for each request it is

-      present in, and SHOULD be eight octets or longer when present.

-      When the challenge is not present, the OTP will be calculated on

-      the current token state only.  The client MAY ignore a provided

-      challenge if and only if the OTP token the client is interacting

-      with is not capable of including a challenge in the OTP

-      calculation.  In this case, KDC policies will determine whether to

-      accept a provided OTP value or not.

-

-   otp-length

-      Use of this field is OPTIONAL, but MAY be used by the KDC to

-      specify the desired length of the generated OTP in octets.  For

-      example, this field could be used when a token is capable of

-      producing OTP values of different lengths.

-

-

-

-

-

-

-

-Richards                Expires January 15, 2009               [Page 14]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   otp-service

-      Use of this field is OPTIONAL, but MAY be used by the KDC to

-      identify the appropriate OTP tokens to be used.  For example, this

-      field could be used when a client has multiple OTP tokens from

-      different servers.

-

-   otp-keyID

-      Use of this field is OPTIONAL, but MAY be used by the KDC to

-      identify which token key should be used for the authentication.

-      For example, this field could be used when a user has been issued

-      multiple token keys by the same server.

-

-   otp-algID

-      use of this field is OPTIONAL, but MAY be used by the KDC to

-      identify the algorithm to use when generating the OTP.

-

-4.2.  PA-OTP-REQUEST

-

-   The padata-type PA_OTP_REQUEST is sent by the client to the KDC in

-   the KrbFastReq padata of a PA-FX-FAST-REQUEST that is included in the

-   PA-DATA of an AS-REQ.  The corresponding padata-value field contains

-   the DER encoding of a PA-OTP-REQUEST.

-

-   The message contains pre-authentication data encrypted by the client

-   using the generated Client Key and optional information on how the

-   OTP was generated.  It may also, optionally, contain the generated

-   OTP value.

-

-             PA_OTP_REQUEST     << TBA >>

-

-             PA-OTP-REQUEST ::= SEQUENCE {

-               flags             OTPFlags,

-               nonce             UInt32,

-               encData           EncryptedData,

-                                 -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC

-                                 -- Key usage of KEY_USAGE_OTP_REQUEST

-               hashAlg           AlgorithmIdentifier OPTIONAL,

-               iterationCount    INTEGER         OPTIONAL,

-               otp-value         OCTET STRING    OPTIONAL,

-               otp-challenge [0] OCTET STRING    OPTIONAL,

-               otp-time          KerberosTime    OPTIONAL,

-               otp-counter   [1] OCTET STRING    OPTIONAL,

-               otp-format    [2] OTPFormat       OPTIONAL,

-               otp-keyID     [3] OCTET STRING    OPTIONAL,

-               otp-algID         AnyURI          OPTIONAL,

-               ...

-             }

-

-

-

-

-Richards                Expires January 15, 2009               [Page 15]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-             KEY_USAGE_OTP_REQUEST  << TBA >>

-

-

-             PA-OTP-ENC-REQUEST ::= SEQUENCE {

-               nonce     UInt32,

-               ...

-             }

-

-

-             OTPFormat ::= INTEGER {

-               decimal(0),

-               hexadecimal(1),

-               alphanumeric(2),

-               binary(3)

-             }

-

-   flags

-      If the "nextOTP" flag is set then the OTP was calculated based on

-      the next token "state" rather than the current one.  This flag

-      MUST be set if and only if it was set in a corresponding PA-OTP-

-      CHALLENGE.

-

-      If the "combine" flag is set then the OTP was calculated based on

-      a challenge and the token state.

-

-   nonce

-      A random nonce value generated by the client to be returned

-      encrypted by the KDC in the PA-OTP-CONFIRM.

-

-   encData

-      This field contains the pre-authentication data encrypted under

-      the Client Key with a key usage of KEY_USAGE_OTP_REQUEST.  If the

-      PA-OTP-REQUEST is sent as a result of a PA-OTP_CHALLENGE then this

-      MUST contain a PA-OTP-ENC-REQUEST with the nonce from the PA-OTP-

-      CHALLENGE.  If no challenge was received then this MUST contain a

-      PA-ENC-TS-ENC.

-

-   hashAlg

-      This field MUST be present if and only if a hash of the OTP value

-      was used as input to string-to-key (see Section 3.6) and MUST

-      contain the AlgorithmIdentifier of the hash algorithm used.  If

-      the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE then

-      the AlgorithmIdentifer MUST be the first one supported by the

-      client from the supportedHashAlg of the PA-OTP-CHALLENGE.

-

-

-

-

-

-

-

-Richards                Expires January 15, 2009               [Page 16]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   iterationCount

-      This field MUST be present if and only if a hash of the OTP value

-      was used as input to string-to-key (see Section 3.6) and MUST

-      contain the iteration count used when hashing the OTP value.  If

-      the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE then

-      the value MUST NOT be less that that specified in the PA-OTP-

-      CHALLENGE.

-

-   otp-value

-      The generated OTP value.  This value MUST NOT be present unless

-      allowed by the OTP algorithm profile.

-

-   otp-challenge

-      Value used by the client in the OTP calculation.  It MUST be sent

-      to the KDC if and only if the value would otherwise be unknown to

-      the KDC.  For example, the token or client modified or generated

-      challenge.

-

-   otp-time

-      This field MAY be included by the client to carry the time value

-      as reported by the OTP token.  Use of this element is OPTIONAL but

-      it MAY be used by a client to simplify the OTP calculations of the

-      KDC.  It is RECOMMENDED that the KDC act upon this value if it is

-      present in the request and it is capable of using it in the

-      generation of the OTP value.

-

-   otp-counter

-      This field MAY be included by the client to carry the token

-      counter value, as reported by the OTP token.  Use of this element

-      is OPTIONAL but it MAY be used by a client to simplify the OTP

-      calculations of the KDC.  It is RECOMMENDED that the KDC act upon

-      this value if it is present in the request and it is capable of

-      using it in the generation of the OTP value.

-

-   otp-format

-      This field MAY be used by the client to send the format of the

-      generated OTP as reported by the OTP token.  Use of this element

-      is OPTIONAL but it MAY be used by the client to simplify the OTP

-      calculation.  It is RECOMMENDED that the KDC act upon this value

-      if it is present in the request and it is capable of using it in

-      the generation of the OTP value.

-

-   otp-keyID

-      This field MAY be used by the client to send the identifier of the

-      token key used, as reported by the OTP token.  Use of this field

-      is OPTIONAL but MAY be used by the client to simplify the

-      authentication process by identifying a particular token key

-      associated with the user.  It is RECOMMENDED that the KDC act upon

-

-

-

-Richards                Expires January 15, 2009               [Page 17]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-      this value if it is present in the request and it is capable of

-      using it in the generation of the OTP value.

-

-   otp-algID

-      This field MAY be used by the client to send the identifier of the

-      OTP algorithm used, as reported by the OTP token.  Use of this

-      element is OPTIONAL but it MAY be used by the client to simplify

-      the OTP calculation.  It is RECOMMENDED that the KDC act upon this

-      value if it is present in the request and it is capable of using

-      it in the generation of the OTP value.

-

-4.3.  PA-OTP-CONFIRM

-

-   The padata-type PA_OTP_CONFIRM is returned by the KDC in the enc-

-   fast-rep of a PA-FX-FAST-REPLY in the AS-REP of the KDC.  It is used

-   to return the client's nonce encrypted under the new Reply Key in

-   order to authenticate the KDC and confirm the Reply Key change.

-

-   The corresponding padata-value field contains the DER encoding of a

-   PA-OTP-CONFIRM.

-

-             PA_OTP_CONFIRM     << TBA >>

-

-             PA-OTP-CONFIRM ::= SEQUENCE {

-               encData        EncryptedData,

-                                   -- PA-OTP-ENC-CONFIRM

-                                   -- Key usage of KEY_USAGE_OTP_CONFIRM

-               ...

-             }

-

-             KEY_USAGE_OTP_CONFIRM  << TBA >>

-

-

-             PA-OTP-ENC-CONFIRM ::= SEQUENCE {

-               nonce     UInt32,

-               ...

-             }

-

-   encData

-      An EncryptedData containing a PA-OTP-ENC-CONFIRM containing the

-      value of the nonce from the corresponding PA-OTP-REQUEST encrypted

-      under the current Reply Key. The key usage SHALL be

-      KEY_USAGE_OTP_CONFIRM and the encryption type SHOULD be the same

-      as that used by the client in the PA-OTP-REQUEST.

-

-

-

-

-

-

-

-Richards                Expires January 15, 2009               [Page 18]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-4.4.  PA-OTP-PIN-CHANGE

-

-   The padata-type PA_OTP_PIN_CHANGE is returned by the KDC in the enc-

-   fast-rep of a PA-FX-FAST-REPLY in the AS-REP if the user must change

-   their PIN or if the user's PIN has been changed.

-

-   The corresponding padata-value field contains the DER encoding of a

-   PA-OTP-PIN-CHANGE.

-

-             PA_OTP_PIN_CHANGE     << TBA >>

-

-             PA-OTP-PIN-CHANGE ::= SEQUENCE {

-               flags         PinFlags,

-               pin           UTF8String OPTIONAL,

-               minLength     INTEGER    OPTIONAL,

-               maxLength [1] INTEGER    OPTIONAL,

-               ...

-             }

-

-             PinFlags ::= KerberosFlags

-               -- systemSetPin (0)

-

-   If the "systemSetPin" flag is set then the user's PIN has been

-   changed and the new PIN value is contained in the pin field.  The pin

-   field MUST therefore be present.

-

-   If the "systemSetPin" flag is not set then the user's PIN has not

-   been changed by the server but it MUST instead be changed by the

-   user.  Restrictions on the size of the PIN MAY be given by the

-   minLength and maxLength fields.  If the pin field is present then it

-   contains a PIN value that MAY be used by the user when changing the

-   PIN.

-

-

-5.  IANA Considerations

-

-   A registry may be required for the otp-algID values as introduced in

-   Section 4.1.  No other IANA actions are anticipated.

-

-

-6.  Security Considerations

-

-6.1.  Man-in-the-Middle

-

-   In the system described in this document, the OTP pre-authentication

-   protocol is tunnelled within the FAST Armor channel provided by the

-   pre-authentication framework.  As described in [AsNiNy02], tunneled

-   protocols are potentially vulnerable to man-in-the-middle attacks if

-

-

-

-Richards                Expires January 15, 2009               [Page 19]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   the outer tunnel is compromised and it is generally considered good

-   practice in such cases to bind the inner encryption to the outer

-   tunnel.

-

-   Even though no such attacks are known at this point, the proposed

-   system uses the outer Armor Key in the derivation of the inner Client

-   and Reply keys and so achieve crypto-binding to the outer channel.

-

-6.2.  Reflection

-

-   The 4-pass system described above is a challenge-response protocol

-   and such protocols are potentially vulnerable to reflection attacks.

-   No such attacks are known at this point but to help mitigate against

-   such attacks, the system uses different keys to encrypt the client

-   and server nonces.

-

-6.3.  Replay

-

-   The 2-pass version of the protocol does not involve a server nonce

-   and so the client instead encrypts a timestamp.  To reduce the chance

-   of replay attacks, the KDC must check that the client time used in

-   such a request is later than that used in previous requests.

-

-6.4.  Brute Force Attack

-

-   A compromised or hostile KDC may be able to obtain the OTP value used

-   by the client via a brute force attack.  If the OTP value is short

-   then the KDC could iterate over the possible OTP values until a

-   Client Key is generated that can decrypt the encData sent in the PA-

-   OTP-REQUEST.

-

-   As described in Section 3.6, an iteration count can be used in the

-   generation of the Client Key and the value of the iteration count can

-   be controlled by local client policy.  Use of this iteration count

-   can make it computationally infeasible/unattractive for an attacker

-   to brute-force search for the given OTP within the lifetime of that

-   OTP.

-

-6.5.  FAST Facilities

-

-   The secret used to generate the OTP is known only to the client and

-   the KDC and so successful decryption of the encrypted nonce by the

-   KDC authenticates the user.  Similarly, successful decryption of the

-   encrypted nonce by the client proves that the expected KDC replied.

-   The Reply Key is replaced by a key generated from the OTP and Armor

-   Key. This FAST factor therefore provides the following facilities:

-   client-authentication, replacing-reply-key and KDC-authentication.

-

-

-

-

-Richards                Expires January 15, 2009               [Page 20]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-7.  Acknowledgments

-

-   Many significant contributions were made to this document by RSA

-   employees but special thanks go to Magnus Nystrom, John Linn, Robert

-   Polansky and Boris Khoutorski.

-

-   Many valuable suggestions were also made by members of the Kerberos

-   Working group but special thanks go to Larry Zhu, Jeffrey Hutzelman,

-   Tim Alsop, Henry Hotz and Nicolas Williams.

-

-

-8.  References

-

-8.1.  Normative References

-

-   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail

-              Extensions (MIME) Part One: Format of Internet Message

-              Bodies", RFC 2045, November 1996.

-

-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

-              Requirement Levels", BCP 14, RFC 2119, March 1997.

-

-   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,

-              "Internationalizing Domain Names in Applications (IDNA)",

-              RFC 3490, March 2003.

-

-   [RFC3491]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep

-              Profile for Internationalized Domain Names (IDN)",

-              RFC 3491, March 2003.

-

-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for

-              Kerberos 5", RFC 3961, February 2005.

-

-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The

-              Kerberos Network Authentication Service (V5)", RFC 4120,

-              July 2005.

-

-   [ZhHa07]   Znu, L. and S. Hartman, "A generalized Framework for

-              Kerberos Pre-Authentication",

-              draft-ietf-krb-wg-preauth-framework-08 (work in progress),

-              July 2008.

-

-8.2.  Informative References

-

-   [AsNiNy02]

-              Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle

-              in Tunneled Authentication Protocols", Cryptology ePrint

-              Archive Report 2002/163, November 2002.

-

-

-

-Richards                Expires January 15, 2009               [Page 21]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   [HoReNeZo04]

-              Horstein, K., Renard, K., Neuman, C., and G. Zorn,

-              "Integrating Single-use Authentication Mechanisms with

-              Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in

-              progress), July 2004.

-

-   [RFC2289]  Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-

-              Time Password System", RFC 2289, February 1998.

-

-   [RFC2808]  Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808,

-              April 2000.

-

-   [RFC3244]  Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows

-              2000 Kerberos Change Password and Set Password Protocols",

-              RFC 3244, February 2002.

-

-   [RFC4226]  M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and

-              O. Ranen, "HOTP: An HMAC-Based One-Time Password

-              Algorithm", RFC 4226, December 2005.

-

-

-Appendix A.  ASN.1 Module

-

-   OTPKerberos

-   DEFINITIONS IMPLICIT TAGS ::=

-   BEGIN

-

-   IMPORTS

-       AnyURI

-       FROM XSD {joint-iso-itu-t asn1(1) specification(0)

-                 modules(0) xsd-module(1)};

-

-       KerberosTime, KerberosFlags, EncryptionKey, UInt32,

-       Int32, EncryptedData

-       FROM KerberosV5Spec2 {iso(1) identified-organization(3)

-                             dod(6) internet(1) security(5)

-                             kerberosV5(2) modules(4) krb5spec2(2)}

-                             -- as defined in RFC 4120.

-       AlgorithmIdentifier

-       FROM PKIX1Explicit88 { iso (1) identified-organization (3)

-                              dod (6) internet (1)

-                              security (5) mechanisms (5) pkix (7)

-                              id-mod (0) id-pkix1-explicit (18) };

-                              -- As defined in RFC 3280.

-

-       PA-OTP-CHALLENGE ::= SEQUENCE {

-         flags              OTPFlags,

-         nonce              UInt32,

-

-

-

-Richards                Expires January 15, 2009               [Page 22]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-         etype              Int32,

-         supportedHashAlg   SEQUENCE OF AlgorithmIdentifier

-                                            OPTIONAL,

-         iterationCount     INTEGER         OPTIONAL,

-         otp-challenge      OCTET STRING (SIZE(8..MAX)) OPTIONAL,

-         otp-length     [0] Int32           OPTIONAL,

-         otp-service        UTF8String      OPTIONAL,

-         otp-keyID      [1] OCTET STRING    OPTIONAL,

-         otp-algID          AnyURI          OPTIONAL,

-         ...

-       }

-

-       OTPFlags ::= KerberosFlags

-       -- nextOTP (0)

-       -- combine (1)

-

-       PA-OTP-REQUEST ::= SEQUENCE {

-         flags             OTPFlags,

-         nonce             UInt32,

-         encData           EncryptedData,

-                           -- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC

-                           -- Key usage of KEY_USAGE_OTP_REQUEST

-         hashAlg           AlgorithmIdentifier OPTIONAL,

-         iterationCount    INTEGER         OPTIONAL,

-         otp-value         OCTET STRING    OPTIONAL,

-         otp-challenge [0] OCTET STRING (SIZE(8..MAX)) OPTIONAL,

-         otp-time          KerberosTime    OPTIONAL,

-         otp-counter   [1] OCTET STRING    OPTIONAL,

-         otp-format    [2] OTPFormat       OPTIONAL,

-         otp-keyID     [3] OCTET STRING    OPTIONAL,

-         otp-algID         AnyURI          OPTIONAL,

-         ...

-       }

-

-       PA-OTP-ENC-REQUEST ::= SEQUENCE {

-         nonce     UInt32,

-         ...

-       }

-

-       OTPFormat ::= INTEGER {

-         decimal(0),

-         hexadecimal(1),

-         alphanumeric(2),

-         binary(3)

-       }

-

-       PA-OTP-CONFIRM ::= SEQUENCE {

-         encData        EncryptedData,

-

-

-

-Richards                Expires January 15, 2009               [Page 23]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-                        -- PA-OTP-ENC-CONFIRM

-                        -- Key usage of KEY_USAGE_OTP_CONFIRM

-         ...

-       }

-

-       PA-OTP-ENC-CONFIRM ::= SEQUENCE {

-         nonce     UInt32,

-         ...

-       }

-

-       PA-OTP-PIN-CHANGE ::= SEQUENCE {

-         flags         PinFlags,

-         pin           UTF8String OPTIONAL,

-         minLength     INTEGER    OPTIONAL,

-         maxLength [0] INTEGER    OPTIONAL,

-         ...

-       }

-

-       PinFlags ::= KerberosFlags

-       -- systemSetPin (0)

-

-   END

-

-

-Appendix B.  Examples of OTP Pre-Authentication Exchanges

-

-   This section is non-normative.

-

-B.1.  Four Pass Authentication

-

-   In this mode, the client sends an initial AS-REQ to the KDC that does

-   not contain a PA-OTP-REQUEST and the KDC responds with a KRB-ERROR

-   containing a PA-OTP-CHALLENGE.

-

-   In this example, the user has been issued with a connected, time-

-   based token and the KDC requires hashed OTP values in the key

-   generation with SHA-384 as the preferred hash algorithm and a minimum

-   of 1024 iterations.  It also requires that 256-bit AES be used to

-   encrypt the nonce.  The local policy on the client supports SHA-256

-   and requires 100,000 iterations of the OTP value.

-

-   The basic sequence of steps involved is as follows:

-

-   1.   The client obtains the user name of the user.

-

-   2.   The client sends an initial AS-REQ to the KDC that does not

-        contain a PA-OTP-REQUEST.

-

-

-

-

-Richards                Expires January 15, 2009               [Page 24]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   3.   The KDC determines that the user identified by the AS-REQ

-        requires OTP authentication.

-

-   4.   The KDC constructs a PA-OTP-CHALLENGE as follows:

-

-        flags

-           0

-

-        nonce

-           A randomly generated value.

-

-        etype

-           aes256-cts-hmac-sha1-96

-

-        supportedHashAlg

-           AlgorithmIdentifiers for SHA-384, SHA-256 and SHA-1

-

-        iterationCount

-           1024

-

-        otp-service

-           A string that can be used by the client to assist the user in

-           locating the correct token.

-

-   5.   The KDC returns a KRB-ERROR with an error code of

-        KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.

-

-   6.   The client displays the value of otp-service and prompts the

-        user to connect the token.

-

-   7.   The client obtains the current OTP value from the token and

-        records the time as reported by the token.

-

-   8.   The client generates Client Key and Reply Key as described in

-        Section 3.6 using SHA-256 from the list of algorithms sent by

-        the KDC and the iteration count of 100,000 as required by local

-        policy.

-

-   9.   The client constructs a PA-OTP-REQUEST as follows:

-

-        flags

-           0

-

-        nonce

-           A randomly generated value.

-

-

-

-

-

-

-Richards                Expires January 15, 2009               [Page 25]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-        encData

-           An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted

-           under the Client Key with a key usage of

-           KEY_USAGE_OTP_REQUEST and an encryption type of aes256-cts-

-           hmac-sha1-96.  The PA-OTP-ENC-REQUEST contains the nonce from

-           the PA-OTP-CHALLENGE.

-

-        hashAlg

-           SHA-256

-

-        iterationCount

-           100,000

-

-        otp-time

-           The time used in the OTP calculation as reported by the OTP

-           token.

-

-   10.  The client encrypts the PA-OTP-REQUEST within the enc-fast-req

-        of a PA-FX-FAST-REQUEST.

-

-   11.  The client sends an AS-REQ to the KDC containing the PA-FX-FAST-

-        REQUEST within the padata.

-

-   12.  The KDC validates the pre-authentication data in the PA-OTP-

-        REQUEST:

-

-        *  Generates the Client Key and Reply Key from the OTP value for

-           the user identified in the AS-REQ, using an iteration count

-           of 100,000 and hash algorithm of SHA-256 as specified in the

-           PA-OTP-REQUEST.

-

-        *  Uses the generated Client Key to decrypt the PA-OTP-ENC-

-           REQUEST in the encData of the PA-OTP-REQUEST.

-

-        *  Authenticates the user by comparing the nonce value from the

-           decrypted PA-OTP-ENC-REQUEST to that sent in the

-           corresponding PA-OTP-CHALLENGE.

-

-   13.  The KDC constructs a TGT for the user.

-

-   14.  The KDC constructs a PA-OTP-CONFIRM as follows:

-

-        encData

-           An EncryptedData containing a PA-OTP-ENC-CONFIRM encrypted

-           under the Reply Key with a key usage of KEY_USAGE_OTP_CONFIRM

-           and an encryption type of aes256-cts-hmac-sha1-96 (the

-           encryption type used by the client in the PA-OTP-REQUEST).

-           The PA-OTP-ENC-CONFIRM contains the nonce from the PA-OTP-

-

-

-

-Richards                Expires January 15, 2009               [Page 26]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-           REQUEST.

-

-   15.  The KDC encrypts the PA-OTP-CONFIRM within the enc-fast-rep of a

-        PA-FX-FAST-REPLY.

-

-   16.  The KDC returns an AS-REP to the client, encrypted using the

-        Reply Key, containing the TGT and padata with the PA-FX-FAST-

-        REPLY.

-

-   17.  The client authenticates the KDC and verifies the Reply Key

-        change.

-

-        *  Uses the generated Reply Key to decrypt the PA-OTP-ENC-

-           CONFIRM in the encData of the PA-OTP-CONFIRM.

-

-        *  Authenticates the KDC by comparing the nonce value from the

-           decrypted PA-OTP-ENC-CONFIRM to that sent in the

-           corresponding PA-OTP-REQUEST.

-

-B.2.  Two Pass Authentication

-

-   In this mode, the client includes a PA-OTP-REQUEST within a PA-FX-

-   FAST-REQUEST pre-auth of the initial AS-REQ sent to the KDC.

-

-   In this example, the user has been issued with a hand-held token and

-   so none of the OTP generation parameters (otp-length etc) are

-   included in the PA-OTP-RESPONSE.  The KDC does not require hashed OTP

-   values in the key generation.

-

-   It is assumed that the client has been configured with the following

-   information or has obtained it from a previous PA-OTP-CHALLENGE.

-   o  The encryption type of aes128-cts-hmac-sha1-96 to use to encrypt

-      the encData.

-   o  The fact that hashed OTP values are not required.

-

-   The basic sequence of steps involved is as follows:

-

-   1.   The client obtains the user name and OTP value from the user.

-

-   2.   The client generates Client Key and Reply Key using unhashed OTP

-        values as described in Section 3.6.

-

-   3.   The client constructs a PA-OTP-REQUEST as follows:

-

-

-

-

-

-

-

-

-Richards                Expires January 15, 2009               [Page 27]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-        flags

-           0

-

-        nonce

-           A randomly generated value.

-

-        encData

-           An EncryptedData containing a PA-ENC-TS-ENC encrypted under

-           the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and

-           an encryption type of aes128-cts-hmac-sha1-96.  The PA-ENC-

-           TS-ENC contains the current client time.

-

-   4.   The client encrypts the PA-OTP-REQUEST within the enc-fast-req

-        of a PA-FX-FAST-REQUEST.

-

-   5.   The client sends an AS-REQ to the KDC containing the PA-FX-FAST-

-        REQUEST within the padata.

-

-   6.   The KDC validates the pre-authentication data:

-

-        *  Generates the Client Key and Reply Key from the unhashed OTP

-           value for the user identified in the AS-REQ.

-

-        *  Uses the generated Client Key to decrypt the PA-ENC-TS-ENC in

-           the encData of the PA-OTP-REQUEST.

-

-        *  Authenticates the user using the timestamp in the standard

-           manner.

-

-   7.   The KDC constructs a TGT for the user.

-

-   8.   The KDC constructs a PA-OTP-CONFIRM as follows:

-

-        encData

-           An EncryptedData containing a PA-OTP-ENC-CONFIRM encrypted

-           under the Reply Key with a key usage of KEY_USAGE_OTP_CONFIRM

-           and an encryption type of aes128-cts-hmac-sha1-96 (the

-           encryption type used by the client in the PA-OTP-REQUEST).

-           The PA-OTP-ENC-CONFIRM contains the nonce from the PA-OTP-

-           REQUEST.

-

-   9.   The KDC encrypts the PA-OTP-CONFIRM within the enc-fast-rep of a

-        PA-FX-FAST-REPLY.

-

-   10.  The KDC returns an AS-REP to the client, encrypted using the

-        Reply Key, containing the TGT and padata with the PA-FX-FAST-

-        REPLY.

-

-

-

-

-Richards                Expires January 15, 2009               [Page 28]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-   11.  The client authenticates the KDC and verifies the key change.

-

-        *  Uses the generated Reply Key to decrypt the PA-OTP-ENC-

-           CONFIRM in the encData of the PA-OTP-CONFIRM.

-

-        *  Authenticates the KDC by comparing the nonce value from the

-           decrypted PA-OTP-ENC-CONFIRM to that sent in the

-           corresponding PA-OTP-REQUEST.

-

-B.3.  Pin Change

-

-   This exchange follows from the point where the KDC receives the PA-

-   OTP-REQUEST from the client in the examples in Appendix B.1 and

-   Appendix B.2.  During the validation of the pre-authentication data

-   (whether encrypted nonce or encrypted timestamp), the KDC determines

-   that the user's PIN has expired and so must be changed.  The KDC

-   therefore includes a PA-OTP-PIN-CHANGE along with the PA-OTP-CONFIRM

-   in the AS-REP.

-

-   In this example, the KDC does not generate PIN values for the user

-   but requires that the user generate a new PIN that is between 4 and 8

-   characters in length.  The actual PIN change is handled by a PIN

-   change service that requires the "initial" bit to be set in the

-   service ticket.

-

-   The basic sequence of steps involved is as follows:

-

-   1.   The client constructs and sends a PA-OTP-REQUEST to the KDC as

-        described in the previous examples.

-

-   2.   The KDC validates the pre-authentication data and authenticates

-        the user as in the previous examples but determines that the

-        user's PIN has expired.

-

-   3.   KDC constructs a ticket for a PIN change service with the

-        "initial" flag set.

-

-   4.   KDC constructs a PA-OTP-CONFIRM as in the previous examples.

-

-   5.   KDC constructs a PA-OTP-PIN-CHANGE as follows:

-

-        flags

-           0

-

-

-

-

-

-

-

-

-Richards                Expires January 15, 2009               [Page 29]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-        minLength

-           4

-

-        maxLength

-           8

-

-   6.   KDC encrypts the PA-OTP-PIN-CHANGE and PA-OTP-CONFIRM within the

-        enc-fast-rep of a PA-FX-FAST-REPLY.

-

-   7.   KDC returns an AS-REP to the client containing the ticket to the

-        PIN change service and padata containing the PA-FX-FAST-REPLY.

-

-   8.   The client authenticates the KDC as in the previous examples.

-

-   9.   The client uses the ticket in the AS-REP to call the PIN change

-        service and change the user's PIN.

-

-   10.  The client sends a second AS-REQ to the KDC containing a PA-OTP-

-        REQUEST constructed using the new PIN.

-

-   11.  The KDC responds with an AS-REP containing a TGT and a PA-OTP-

-        CONFRIM.

-

-

-B.4.  Resynchronization

-

-   This exchange follows from the point where the KDC receives the PA-

-   OTP-REQUEST from the client.  During the validation of the pre-

-   authentication data (whether encrypted nonce or encrypted timestamp),

-   the KDC determines that the local record of the token's state needs

-   to be re-synchronized with the token.  The KDC therefore includes a

-   KRB-ERROR containing a PA-OTP-CHALLENGE with the "nextOTP" flag set.

-

-   The sequence of steps below follows is a variation of the four pass

-   examples shown in Appendix B.1 but the same process would also work

-   in the two-pass case.

-

-   1.   The client constructs and sends a PA-OTP-REQUEST to the KDC as

-        described in the previous examples.

-

-   2.   The KDC validates the pre-authentication data and authenticates

-        the user as in the previous examples but determines that user's

-        token requires re-synchronizing.

-

-   3.   KDC constructs a PA-OTP-CHALLENGE as follows:

-

-

-

-

-

-

-Richards                Expires January 15, 2009               [Page 30]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-        flags

-           nextOTP bit set

-

-        nonce

-           A randomly generated value.

-

-        etype

-           aes256-cts-hmac-sha1-96

-

-        supportedHashAlg

-           AlgorithmIdentifiers for SHA-256 and SHA-1

-

-        iterationCount

-           1024

-

-        otp-service

-           Set to a string that can be used by the client to assist the

-           user in locating the correct token.

-

-   4.   KDC returns a KRB-ERROR with an error code of

-        KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.

-

-   5.   The client obtains the next OTP value from the token and records

-        the time as reported by the token.

-

-   6.   The client generates Client Key Reply Key as described in

-        Section 3.6 using SHA-256 from the list of algorithms sent by

-        the KDC and the iteration count of 100,000 as required by local

-        policy.

-

-   7.   The client constructs a PA-OTP-REQUEST as follows:

-

-        flags

-           nextOTP bit set

-

-        nonce

-           A randomly generated value.

-

-        encData

-           An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted

-           under the Client Key with a key usage of

-           KEY_USAGE_OTP_REQUEST and an encryption type of aes256-cts-

-           hmac-sha1-96.  The PA-OTP-ENC-REQUEST contains the nonce from

-           the PA-OTP-CHALLENGE.

-

-

-

-

-

-

-

-Richards                Expires January 15, 2009               [Page 31]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-        hashAlg

-           SHA-256

-

-        iterationCount

-           100,000

-

-        otp-time

-           The time used in the OTP calculation as reported by the OTP

-           token.

-

-   8.   The client encrypts the PA-OTP-REQUEST within the enc-fast-req

-        of a PA-FX-FAST-REQUEST.

-

-   9.   The client sends an AS-REQ to the KDC containing the PA-FX-FAST-

-        REQUEST within the padata.

-

-   10.  Authentication process now proceeds as with the standard

-        sequence.

-

-

-Author's Address

-

-   Gareth Richards

-   RSA, The Security Division of EMC

-   RSA House

-   Western Road

-   Bracknell, Berkshire  RG12 1RT

-   UK

-

-   Email: gareth.richards@rsa.com

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Richards                Expires January 15, 2009               [Page 32]

-

-Internet-Draft           OTP Pre-authentication                July 2008

-

-

-Full Copyright Statement

-

-   Copyright (C) The IETF Trust (2008).

-

-   This document is subject to the rights, licenses and restrictions

-   contained in BCP 78, and except as set forth therein, the authors

-   retain all their rights.

-

-   This document and the information contained herein are provided on an

-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS

-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF

-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-Intellectual Property

-

-   The IETF takes no position regarding the validity or scope of any

-   Intellectual Property Rights or other rights that might be claimed to

-   pertain to the implementation or use of the technology described in

-   this document or the extent to which any license under such rights

-   might or might not be available; nor does it represent that it has

-   made any independent effort to identify any such rights.  Information

-   on the procedures with respect to rights in RFC documents can be

-   found in BCP 78 and BCP 79.

-

-   Copies of IPR disclosures made to the IETF Secretariat and any

-   assurances of licenses to be made available, or the result of an

-   attempt made to obtain a general license or permission for the use of

-   such proprietary rights by implementers or users of this

-   specification can be obtained from the IETF on-line IPR repository at

-   http://www.ietf.org/ipr.

-

-   The IETF invites any interested party to bring to its attention any

-   copyrights, patents or patent applications, or other proprietary

-   rights that may cover technology that may be required to implement

-   this standard.  Please address the information to the IETF at

-   ietf-ipr@ietf.org.

-

-

-

-

-

-

-

-

-

-

-

-Richards                Expires January 15, 2009               [Page 33]

-

diff --git a/doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-00.txt b/doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-00.txt
deleted file mode 100644
index bf2dd5f2d..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-00.txt
+++ /dev/null
@@ -1,672 +0,0 @@
-
-
-
-Network Working Group                               L. Hornquist Astrand
-Internet-Draft                                      Stockholm University
-Expires: September 2, 2006                                        L. Zhu
-                                                   Microsoft Corporation
-                                                              March 2006
-
-
-                       PK-INIT algorithm agility
-                draft-ietf-krb-wg-pkinit-alg-agility-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 2, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   The PK-INIT protocol have in several places hard coded crypto
-   algorithms.  The protocol specification needs to be updated so it can
-   support negotiation to upgrading to newer versions of crypto
-   algorithms.  This document addresses this issue.
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 1]
-
-Internet-Draft          PK-INIT algorithm agility             March 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
-   3.  paChecksum agility . . . . . . . . . . . . . . . . . . . . . .  5
-   4.  CMS Digest Algorithm agility . . . . . . . . . . . . . . . . .  6
-   5.  Certificate Signer Algorithm Identifier agility  . . . . . . .  7
-   6.  octetstring2key function agility . . . . . . . . . . . . . . .  8
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 2]
-
-Internet-Draft          PK-INIT algorithm agility             March 2006
-
-
-1.  Introduction
-
-   The Kerberos PK-INIT document contains several hardcoded algorithms
-   that was know designed at design time that they had to be replaced by
-   something else at a later time, this document described how to use
-   other algorithms other then those that are hard-coded.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 3]
-
-Internet-Draft          PK-INIT algorithm agility             March 2006
-
-
-2.  Requirements notation
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 4]
-
-Internet-Draft          PK-INIT algorithm agility             March 2006
-
-
-3.  paChecksum agility
-
-   The paChecksum binds the PK-INIT part of the request to main body of
-   the Kerberos request (KDC-REQ-BODY).  This is to makes sure an
-   attacker can not change the request from the client to the server.
-   The problem is that paChecksum is hardcoded to use SHA1-1, however,
-   there is a mechaism to provide algorithm agility for the paChecksum
-   within the PK-INIT prototcol.  Newer clients can choose not send the
-   paChecksum field, but rather add some new fields after the existing
-   fields, older KDC will send back know failure-code so that newer
-   clients can fall back to the old protocol if local policy allows
-   that.
-
-   If the attacker can preserve the checksum in paChecksum, an attacker
-   can, for example, change the KDC-REQ-BODY is to downgrade the
-   encryption types used, expend the expiration time, etc, and then try
-   to brute-force the request.
-
-   In the Public Key Encryption case of PK-INIT the reply contains a
-   checksum over the whole request in the asChecksum field, in this case
-   the client will detect any modifications to the request.  Since the
-   asChecksum is using the associated checksum of the session key
-   encryption type, asChecksum field is algorithm agile.
-
-   One way to solve this problem is to add the asChecksum to the Diffie-
-   Hellman case reply too, and just ignore the paCheckSum field.  The
-   KDC should still not issue tickets that are too weak, since that
-   exposes the problem.  This is regardless of the using PK-INIT or not.
-
-   Questions for wg: Wait for Kerberos Extensions that will solve this
-   problem (ignore the problem for how), or use add asChecksum to DH
-   case.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 5]
-
-Internet-Draft          PK-INIT algorithm agility             March 2006
-
-
-4.  CMS Digest Algorithm agility
-
-   The client can tell KDC what the supported CMS types are in the
-   requset packet, but there are no equivalent for KDC to the the client
-   what the digest algorithm are support in an reply.
-
-   Have KDC send the CMS list of supported encryption types in the
-   e-data field of KRB-ERROR when returning the
-   KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error.
-
-   DER encoded TS-SD-PARAMETERS specifies supported digest algorithms.
-   The list is in decreasing preference order.
-
-
-
-   TD-SD-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 6]
-
-Internet-Draft          PK-INIT algorithm agility             March 2006
-
-
-5.  Certificate Signer Algorithm Identifier agility
-
-   The KDC can reject a certificate based on the signers hash algorithm
-   with the error KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED, but doesn't tell
-   the client what algorithm are supported.
-
-   DER encoded TS-DC-PARAMETERS specifies supported certificate digest
-   algorithms.  The AllowedAlgorithms is in decreasing preference order.
-   RejectedAlgorithm may be include my the KDC to tell what algorithm
-   was rejected in case the rejected certificate was part of a computed
-   chain.
-
-
-
-   TD-DC-PARAMETERS ::= SEQUENCE {
-       AllowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
-       RejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL
-   }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 7]
-
-Internet-Draft          PK-INIT algorithm agility             March 2006
-
-
-6.  octetstring2key function agility
-
-   The PK-INIT standard uses a home-grown string 2 key function in the
-   DH case.  The function uses SHA-1 to mix and stretch the DH shared
-   key.
-
-   Describe how the client announces that is supports the new String to
-   key function.  Probably by stuffing it into the supportCMSTypes field
-   in the request.
-
-   Use NIST SP 800 56B when its published.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 8]
-
-Internet-Draft          PK-INIT algorithm agility             March 2006
-
-
-7.  Security Considerations
-
-   This document describes negotiation of checksum types and other
-   cryptographic functions.  Most of this negotiation is done
-   unauthenticated with no way to very
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires September 2, 2006              [Page 9]
-
-Internet-Draft          PK-INIT algorithm agility             March 2006
-
-
-8.  IANA Considerations
-
-   No IANA considerations.
-
-9.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires September 2, 2006             [Page 10]
-
-Internet-Draft          PK-INIT algorithm agility             March 2006
-
-
-Authors' Addresses
-
-   Love Hornquist Astrand
-   Stockholm University
-   SE-106 91  STOCKHOLM
-   SWEDEN
-
-   Email: lha@it.su.se
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires September 2, 2006             [Page 11]
-
-Internet-Draft          PK-INIT algorithm agility             March 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Hornquist Astrand & Zhu  Expires September 2, 2006             [Page 12]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-03.txt b/doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-03.txt
deleted file mode 100644
index bd6dbfe32..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-pkinit-alg-agility-03.txt
+++ /dev/null
@@ -1,1175 +0,0 @@
-
-
-Network Working Group                               L. Hornquist Astrand
-Internet-Draft                                      Stockholm University
-Intended status: Standards Track                                  L. Zhu
-Expires: January 10, 2008                          Microsoft Corporation
-                                                            July 9, 2007
-
-
-                       PK-INIT algorithm agility
-                draft-ietf-krb-wg-pkinit-alg-agility-03
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 10, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 1]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-Abstract
-
-   The PK-INIT defined in RFC 4556 is examined and updated to remove
-   protocol structures tied to specific cryptographic algorithms.  The
-   affinity to SHA-1 as the checksum algorithm in the authentication
-   request is analyzed.  The PK-INIT key derivation function is made
-   negotiable, the digest algorithms for signing the pre-authentication
-   data and the client's X.509 certificates are made discoverable.
-
-   These changes provide protection preemptively against vulnerabilities
-   discovered in the future against any specific cryptographic
-   algorithm, and allow incremental deployment of newer algorithms.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  5
-   3.  paChecksum Agility . . . . . . . . . . . . . . . . . . . . . .  6
-   4.  CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . .  7
-   5.  X.509 Certificate Signer Algorithm Agility . . . . . . . . . .  8
-   6.  KDF agility  . . . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
-     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 16
-     10.2.  Informative References  . . . . . . . . . . . . . . . . . 17
-   Appendix A.  PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 18
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
-   Intellectual Property and Copyright Statements . . . . . . . . . . 21
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 2]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-1.  Introduction
-
-   In August 2004, Xiaoyun Wang's research group reported MD4 [RFC1320]
-   collisions generated using hand calculation [WANG04] alongside
-   attacks on later hash function designs in the MD4, MD5 [RFC1321] and
-   SHA [RFC4634] family.  Implementations based on Wang's algorithm can
-   find collisions in real time.  These discoveries challenged the
-   security for protocols relying on the collision resistance properties
-   of these hashes, for example one can forge a digital signature when
-   SHA-1 [RFC4634] is the digest algorithm.  A more far reaching side
-   effect of these recent events, however, is that it is now generally
-   considered flawed or distasteful at least if protocols are designed
-   to use only specific algorithms.
-
-   The Internet Engineer Task Force (IETF) called for actions to update
-   existing protocols to provide crypto algorithm agility in order to
-   untie protocols with specific algorithms.  The idea is that if the
-   protocol has crypto algorithm agility, and when a new vulnerability
-   specific to an algorithm is discovered, this algorithm can be
-   disabled via protocol negotiation quickly, thus we can avoid the wait
-   for the multi-year standardization and implementation efforts to
-   update the protocols.  In additon, crypto agility allows deployment
-   of new crypto algorithms to be done incrementally, rather than
-   requring a "flag day" on which the change must be deployed everywhere
-   at the same time in order to maintain interoperability.
-
-   This document is to update PK-INIT [RFC4556] to provide crypto
-   algorithm agility.  Several protocol structures used in the [RFC4556]
-   protocol are either tied to SHA-1, or require the algorithms not
-   negotiated but rather based on local policy.  The following concerns
-   have been addressed:
-
-   o  The checksum algorithm in the authentication request is hardwired
-      to use SHA-1 [RFC4634].
-
-   o  The acceptable digest algorithms for signing the authentication
-      data are not discoverable.
-
-   o  The key derivation function in Section 3.2.3 of [RFC4556] is
-      hardwired to use SHA-1.
-
-   o  The acceptable digest algorithms for signing the client X.509
-      certificates are not discoverable.
-
-   To accomplish these, new key derivation functions (KDFs) identifiable
-   by object identifiers are defined.  The PKINIT client provides a list
-   of KDFs in the request and the KDC picks one in the response, thus a
-   mutually-supported KDF is negotiated.
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 3]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-   Furthermore, structures are defined to allow the client discover the
-   Cryptographic Message Syntax (CMS) [RFC3852] digest algorithms
-   supported by the KDC for signing the pre-authentication data and
-   signing the client X.509 certificate.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 4]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-2.  Requirements Notation
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 5]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-3.  paChecksum Agility
-
-   The paChecksum defined in Section 3.2.1 of [RFC4556] provides a
-   cryptographic binding between the client's pre-authentication data
-   and the corresponding Kerberos request body.  This also prevents the
-   KDC body from being tempered with.  SHA-1 is the only allowed
-   checksum algorithm defined in [RFC4556].  This facility relies the
-   collision resistance properties of the SHA-1 checksum [RFC4634].
-
-   When the reply key delivery mechanism is based on public key
-   encryption as described in Section 3.2.3. of [RFC4556], the
-   asChecksum in the KDC reply provides the binding between the pre-
-   authentication and the ticket request and response messages, and
-   integrity protection for the unauthenticated clear text in these
-   messages.  However, if the reply key delivery mechanism is based on
-   the Diffie-Hellman key agreement as described in Section 3.2.3.1 of
-   [RFC4556], the security provided by using SHA-1 in the paChecksum is
-   weak.  In this case, the new KDF selected by the KDC as described in
-   Section 6 provides the cryptographic binding and integrity
-   protection.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 6]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-4.  CMS Digest Algorithm Agility
-
-   When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned
-   as described In section 3.2.2 of [RFC4556], implementations
-   comforming to this specification can OPTIONALLY send back a list of
-   supported CMS types signifying the digest algorithms supported by the
-   KDC, in the decreasing preference order.  This is accomplished by
-   including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the
-   error data.
-
-
-
-   TD-CMS-DIGEST-ALGORITHMS ::= INTEGER 111
-
-
-   The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains
-   the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded
-   TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows:
-
-
-
-   TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
-       AlgorithmIdentifier
-           -- Contains the list of CMS algorithm [RFC3852]
-           -- identifiers that identify the digest algorithms
-           -- acceptable by the KDC for signing CMS data in
-           -- the order of decreasing preference.
-
-
-   The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy
-   digest algorithms supported by the KDC.
-
-   This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS
-   can facilitate trouble-shooting when none of the digest algorithms
-   supported by the client is supported by the KDC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 7]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-5.  X.509 Certificate Signer Algorithm Agility
-
-   When the client's X.509 certificate is rejected and the
-   KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as
-   described in section 3.2.2 of [RFC4556], conforming implementations
-   can OPTIONALLY send a list of digest algorithms acceptable by the KDC
-   for use by the CA in signing the client's X.509 certificate, in the
-   decreasing preference order.  This is accomplished by including a
-   TD_CERT_DIGEST_ALGORITHMS typed data element in the error data.  The
-   corresponding data contains the ASN.1 DER encoding of the structure
-   TD-CERT-DIGEST-ALGORITHMS-DATA defined as follows:
-
-
-   TD-CERT-DIGEST-ALGORITHMS ::= INTEGER 112
-
-   TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
-           allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
-                      -- Contains the list of CMS algorithm [RFC3852]
-                      -- identifiers that identify the digest algorithms
-                      -- that are used by the CA to sign the client's
-                      -- X.509 certificate and acceptable by the KDC in
-                      -- the process of validating the client's X.509
-                      -- certificate, in the order of decreasing
-                      -- preference.
-           rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
-                      -- This identifies the digest algorithm that was
-                      -- used to sign the client's X.509 certificate and
-                      -- has been rejected by the KDC in the process of
-                      -- validating the client's X.509 certificate
-                      -- [RFC3280].
-           ...
-   }
-
-
-   The KDC fills in allowedAlgorithm field with the list of algorithm
-   [RFC3852] identifiers that identify digest algorithms that are used
-   by the CA to sign the client's X.509 certificate and acceptable by
-   the KDC in the process of validating the client's X.509 certificate,
-   in the order of decreasing preference.  The rejectedAlgorithm field
-   identifies the signing algorithm for use in signing the client's
-   X.509 certificate that has been rejected by the KDC in the process of
-   validating the client's certificate [RFC3280].
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 8]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-6.  KDF agility
-
-   Based on [RFC3766] and [X9.42], Section 3.2.3.1 of [RFC4556] defines
-   a Key Derivation Function (KDF) that derives a Kerberos protocol key
-   based on the secret value generated by the Diffie-Hellman key
-   exchange.  This KDF requires the use of SHA-1 [RFC4634].
-
-   New KDFs defined in this document based on [SP80056A] can be used in
-   conjunction with any hash functions.  A new KDF is identified by an
-   object identifier.  The following KDF object identifiers are defined:
-
-
-
-   id-pkinit-kdf OBJECT IDENTIFIER           ::= { id-pkinit 6 }
-       -- PKINIT KDFs
-   id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER   ::= { id-pkinit-kdf 1 }
-       -- SP800 56A ASN.1 structured hash based KDF using SHA-1
-   id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER ::= { id-pkinit-kdf 2 }
-       -- SP800 56A ASN.1 structured hash based KDF using SHA-256
-   id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER ::= { id-pkinit-kdf 3 }
-       -- SP800 56A ASN.1 structured hash based KDF using SHA-512
-
-
-   Where id-pkinit is defined in [RFC4556].  The id-pkinit-kdf-ah-sha1
-   KDF is the ASN.1 structured hash based KDF (HKDF) [SP80056A] that
-   uses SHA-1 [RFC4634] as the hash function.  Similarly id-pkinit-kdf-
-   ah-sha256 and id-pkinit-kdf-ah-sha512 are the ASN.1 structured HKDF
-   using SHA-256 [RFC4634] and SHA-512 [RFC4634] respectively.  The
-   common input parameters for these KDFs are provided as follows:
-
-   o  The secret value is the shared secret value generated by the
-      Diffie-Hellman exchange.  The Diffie-Hellman shared value is first
-      padded with leading zeros such that the size of the secret value
-      in octets is the same as that of the modulus, then represented as
-      a string of octets in big-endian order.
-
-   o  The key data length is K. K is the key-generation seed length in
-      bits [RFC3961] for the Authentication Service (AS) reply key.  The
-      enctype of the AS reply key is selected according to [RFC4120].
-
-   o  The algorithm identifier input parameter is the identifier of the
-      respective KDF.  For example, this is id-pkinit-kdf-ah-sha1 if the
-      KDF is the [SP80056A] ASN.1 structured HKDF using SHA-1 as the
-      hash.
-
-   o  The initiator identifier is an OCTET STRING that contains the
-      ASN.1 DER encoding of the KRB5PrincipalName [RFC4556] that
-      identifies the client as specified in the AS-REQ [RFC4120] in the
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008               [Page 9]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-      request.
-
-   o  The recipient identifier is an OCTET STRING that contains the
-      ASN.1 DER encoding of the KRB5PrincipalName [RFC4556] that
-      identifies the TGS as specified in the AS-REQ [RFC4120] in the
-      request.
-
-   o  The supplemental private information is absent (not used).
-
-   o  The supplemental public information is an OCTET STRING that
-      contains the ASN.1 DER encoding of the structure PkinitSuppPubInfo
-      as defined later in this section.
-
-   o  The hash length is 128 for id-pkinit-kdf-ah-sha1, 256 for id-
-      pkinit-kdf-ah-sha256, and 512 for id-pkinit-kdf-ah-sha512.
-
-   o  The maximum hash input length is 2^64 in bits.
-
-   The structure PkinitSuppPubInfo is defined as follows:
-
-
-   PkinitSuppPubInfo ::= SEQUENCE {
-          enctype           [0] Int32,
-              -- The enctype of the AS reply key.
-          as-REQ            [1] OCTET STRING,
-              -- This contains the AS-REQ in the request.
-          pk-as-rep         [2] OCTET STRING,
-              -- Contains the DER encoding of the type
-              -- PA-PK-AS-REP [RFC4556] in the KDC reply.
-          ticket            [3] Ticket,
-              -- This is the ticket in the KDC reply.
-          ...
-   }
-
-
-   The PkinitSuppPubInfo structure contains mutually-known public
-   information specific to the authentication exchange.  The enctype
-   field is the enctype of the AS reply key as selected according to
-   [RFC4120].  The as-REQ field contains the DER encoding of the type
-   AS-REQ [RFC4120] in the request sent from the client to the KDC.
-   Note that the as-REQ field does not include the wrapping 4 octet
-   length field when TCP is used.  The pk-as-rep field contains the DER
-   encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply.  The
-   ticket field is filled with the ticket in the KDC reply.  The
-   PkinitSuppPubInfo provides a cryptographic bindings between the pre-
-   authentication data and the corresponding ticket request and
-   response, thus addressing the concerns described in Section 3.
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 10]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-   The above ASN.1 structured [SP80056A] HKDF produces a bit string of
-   length K in bits as the keying material, and then the AS reply key is
-   the output of random-to-key() [RFC3961] using that returned keying
-   material as the input.
-
-   The KDF is negotiated between the client and the KDC.  The client
-   sends an unordered set of supported KDFs in the request, and the KDC
-   picks one from the set in the reply.
-
-   To acomplish this, the AuthPack structure in [RFC4556] is extended as
-   follows:
-
-
-   AuthPack ::= SEQUENCE {
-          pkAuthenticator   [0] PKAuthenticator,
-          clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
-          supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
-                   OPTIONAL,
-          clientDHNonce     [3] DHNonce OPTIONAL,
-          ...,
-          supportedKDFs     [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
-              -- Contains an unordered set of KDFs supported by the
-              -- client.
-          ...
-   }
-
-   KDFAlgorithmId ::= SEQUENCE {
-          kdf-id            [0] OBJECT IDENTIFIER,
-              -- The object identifier of the KDF
-          ...
-   }
-
-
-   The new field supportedKDFs contains an unordered set of KDFs
-   supported by the client.
-
-   The KDFAlgorithmId structure contains an object identifier that
-   identifies a KDF.  The algorithm of the KDF and its parameters are
-   defined by the corresponding specification of that KDF.
-
-   The DHRepInfo structure in [RFC4556] is extended as follows:
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 11]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-   DHRepInfo ::= SEQUENCE {
-           dhSignedData         [0] IMPLICIT OCTET STRING,
-           serverDHNonce        [1] DHNonce OPTIONAL,
-           ...,
-           kdf                  [2] KDFAlgorithmId OPTIONAL,
-               -- The KDF picked by the KDC.
-           ...
-   }
-
-
-   The new field kdf in the extended DHRepInfo structure identifies the
-   KDF picked by the KDC.  This kdf field MUST be filled by the
-   comforming KDC if the supportedKDFs field is present in the request,
-   and it MUST be one of the KDFs supported by the client as indicated
-   in the request.  Which KDF is chosen is a matter of the local policy
-   on the KDC.
-
-   If the supportedKDFs field is not present in the request, the kdf
-   field in the reply MUST be absent.
-
-   If the client fills the supportedKDFs field in the request, but the
-   kdf field in the reply is not present, the client can deduce that the
-   KDC is not updated to conform with this specification.  In that case,
-   it is a matter of local policy on the client whether to reject the
-   reply when the kdf field is absent in the reply.
-
-   Implementations comforming to this specification MUST support id-
-   pkinit-kdf-ah-sha256.
-
-   If no acceptable KDF is found, the error KDC_ERR_NO_ACCEPTABLE_KDF
-   (82).
-
-   PKINIT introduces the following new error code:
-
-   o  KDC_ERR_NO_ACCEPTABLE_KDF 82
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 12]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-7.  Security Considerations
-
-   This document describes negotiation of checksum types, key derivation
-   functions and other cryptographic functions.  If negotiation is done
-   unauthenticated, care MUST be taken to accept only acceptable values.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 13]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-8.  Acknowledgements
-
-   Jeffery Hutzelman and Shawn Emery reviewed the document and provided
-   suggestions for improvements.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 14]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-9.  IANA Considerations
-
-   No IANA considerations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 15]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
-              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
-              RFC 3766, April 2004.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3852, July 2004.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
-              (SHA and HMAC-SHA)", July 2006.
-
-   [SP80056A]
-              Barker, E., Don, D., and M. Smid, "Recommendation for
-              Pair-Wise Key Establishment Schemes Using Discrete
-              Logarithm Cryptography", March 2006.
-
-   [X680]     ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-
-              1:2002, Information technology - Abstract Syntax Notation
-              One (ASN.1): Specification of basic notation".
-
-   [X690]     ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-
-              1:2002, Information technology - ASN.1 encoding Rules:
-              Specification of Basic Encoding Rules (BER), Canonical
-              Encoding Rules (CER) and Distinguished Encoding Rules
-              (DER)".
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 16]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-10.2.  Informative References
-
-   [RFC1320]  Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320,
-              April 1992.
-
-   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-              April 1992.
-
-   [WANG04]   Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu,
-              "Cryptanalysis of Hash functions MD4 and RIPEMD",
-              August 2004.
-
-   [X9.42]    ANSI, "Public Key Cryptography for the Financial Services
-              Industry: Agreement of Symmetric Keys Using Discrete
-              Logarithm Cryptography", 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 17]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-Appendix A.  PKINIT ASN.1 Module
-
-
-
-   KerberosV5-PK-INIT-Agility-SPEC {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2) modules(4) pkinit(5) agility (1)
-   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-   IMPORTS
-      AlgorithmIdentifier, SubjectPublicKeyInfo
-          FROM PKIX1Explicit88 { iso (1)
-            identified-organization (3) dod (6) internet (1)
-            security (5) mechanisms (5) pkix (7) id-mod (0)
-            id-pkix1-explicit (18) }
-            -- As defined in RFC 3280.
-
-      Ticket, Int32, Realm, EncryptionKey, Checksum
-          FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-            dod(6) internet(1) security(5) kerberosV5(2)
-            modules(4) krb5spec2(2) }
-            -- as defined in RFC 4120.
-
-      PKAuthenticator, DHNonce
-          FROM KerberosV5-PK-INIT-SPEC {
-            iso(1) identified-organization(3) dod(6) internet(1)
-            security(5) kerberosV5(2) modules(4) pkinit(5) };
-            -- as defined in RFC 4556.
-
-   TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
-       AlgorithmIdentifier
-           -- Contains the list of CMS algorithm [RFC3852]
-           -- identifiers that identify the digest algorithms
-           -- acceptable by the KDC for signing CMS data in
-           -- the order of decreasing preference.
-
-   TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
-          allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
-              -- Contains the list of CMS algorithm [RFC3852]
-              -- identifiers that identify the digest algorithms
-              -- that are used by the CA to sign the client's
-              -- X.509 certificate and acceptable by the KDC in
-              -- the process of validating the client's X.509
-              -- certificate, in the order of decreasing
-              -- preference.
-          rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
-              -- This identifies the digest algorithm that was
-              -- used to sign the client's X.509 certificate and
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 18]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-              -- has been rejected by the KDC in the process of
-              -- validating the client's X.509 certificate
-              -- [RFC3280].
-          ...
-   }
-
-   PkinitSuppPubInfo ::= SEQUENCE {
-          enctype           [0] Int32,
-              -- The enctype of the AS reply key.
-          as-REQ            [1] OCTET STRING,
-              -- This contains the AS-REQ in the request.
-          pk-as-rep         [2] OCTET STRING,
-              -- Contains the DER encoding of the type
-              -- PA-PK-AS-REP [RFC4556] in the KDC reply.
-          ticket            [3] Ticket,
-              -- This is the ticket in the KDC reply.
-          ...
-   }
-
-   AuthPack ::= SEQUENCE {
-          pkAuthenticator   [0] PKAuthenticator,
-          clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
-          supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
-                   OPTIONAL,
-          clientDHNonce     [3] DHNonce OPTIONAL,
-          ...,
-          supportedKDFs     [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
-              -- Contains an unordered set of KDFs supported by the
-              -- client.
-          ...
-   }
-
-   KDFAlgorithmId ::= SEQUENCE {
-          kdf-id            [0] OBJECT IDENTIFIER,
-              -- The object identifier of the KDF
-          ...
-   }
-
-   DHRepInfo ::= SEQUENCE {
-          dhSignedData      [0] IMPLICIT OCTET STRING,
-          serverDHNonce     [1] DHNonce OPTIONAL,
-          ...,
-          kdf               [2] KDFAlgorithmId OPTIONAL,
-              -- The KDF picked by the KDC.
-          ...
-   }
-   END
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 19]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-Authors' Addresses
-
-   Love Hornquist Astrand
-   Stockholm University
-   SE-106 91 Stockholm
-   Sweden
-
-   Email: lha@it.su.se
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 20]
-
-Internet-Draft          PK-INIT algorithm agility              July 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Hornquist Astrand & Zhu  Expires January 10, 2008              [Page 21]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-00.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-00.txt
deleted file mode 100644
index 56d43df3a..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-00.txt
+++ /dev/null
@@ -1,1177 +0,0 @@
-
-
-Kerberos Working Group                                        S. Hartman
-Internet-Draft                                                       MIT
-Expires: August 9, 2004                                 February 9, 2004
-
-
-         A Generalized Framework for Kerberos Preauthentication
-                 draft-ietf-krb-wg-preauth-framework-00
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at http://
-   www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 9, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
-   Kerberos is a protocol for verifying the identity of principals
-   (e.g., a workstation user or a network server) on an open network.
-   The Kerberos protocol provides a mechanism called preauthentication
-   for proving the identity  of a principal and for better protecting
-   the long-term secret of the principal.
-
-   This document describes a model for Kerberos preauthentication
-   mechanisms.  The model describes what state in the Kerberos request a
-   preauthentication mechanism is likely to change. It also describes
-   how multiple preauthentication mechanisms used in the same request
-   will interact.
-
-   This document also provides common tools needed by multiple
-
-
-
-Hartman                  Expires August 9, 2004                 [Page 1]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-   preauthentication mechanisms.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [1].
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Model for Preauthentication  . . . . . . . . . . . . . . . . .  4
-   2.1 Information Managed by Model . . . . . . . . . . . . . . . . .  5
-   2.2 The Preauth_Required Error . . . . . . . . . . . . . . . . . .  6
-   2.3 Client to KDC  . . . . . . . . . . . . . . . . . . . . . . . .  7
-   2.4 KDC to Client  . . . . . . . . . . . . . . . . . . . . . . . .  7
-   3.  Preauthentication Facilities . . . . . . . . . . . . . . . . .  9
-   3.1 Client Authentication  . . . . . . . . . . . . . . . . . . . . 10
-   3.2 Strengthen Reply Key . . . . . . . . . . . . . . . . . . . . . 10
-   3.3 Replace Reply Key  . . . . . . . . . . . . . . . . . . . . . . 11
-   3.4 Verify Response  . . . . . . . . . . . . . . . . . . . . . . . 11
-   4.  Requirements for Preauthentication Mechanisms  . . . . . . . . 12
-   5.  Tools for Use in Preauthentication Mechanisms  . . . . . . . . 13
-   5.1 Combine Keys . . . . . . . . . . . . . . . . . . . . . . . . . 13
-   5.2 Signing Requests/Responses . . . . . . . . . . . . . . . . . . 13
-   5.3 Managing State for the KDC . . . . . . . . . . . . . . . . . . 13
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
-       Normative References . . . . . . . . . . . . . . . . . . . . . 17
-       Informative References . . . . . . . . . . . . . . . . . . . . 18
-   A.  Todo List  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
-       Intellectual Property and Copyright Statements . . . . . . . . 20
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires August 9, 2004                 [Page 2]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-1. Introduction
-
-   The core Kerberos specification treats preauthentication data as an
-   opaque typed hole in the messages to the KDC that may influence the
-   reply key used to encrypt the KDC response.  This generality has been
-   useful: preauthentication data is used for a variety of extensions to
-   the protocol, many outside the expectations of the initial designers.
-   However, this generality makes designing the more common types of
-   preauthentication mechanisms difficult. Each mechanism needs to
-   specify how it interacts with other mechanisms.  Also, problems like
-   combining a key with the long-term secret or proving the identity of
-   the user are common to multiple mechanisms.  Where there are
-   generally well-accepted solutions to these problems, it is desirable
-   to standardize one of these solutions so mechanisms  can avoid
-   duplication of work.  In other cases, a modular approach to these
-   problems is appropriate.  The modular approach will allow new  and
-   better solutions to common preauth problems to be used by existing
-   mechanisms as they are developed.
-
-   This document specifies a framework for Kerberos preauthentication
-   mechanisms.  IT defines the common set of functions preauthentication
-   mechanisms perform as well as how these functions affect the state of
-   the request and response.  In addition several common tools needed by
-   preauthentication mechanisms are provided.  Unlike [3], this
-   framework is not complete--it does not describe all the inputs and
-   outputs for the preauthentication mechanisms.  Mechanism designers
-   should try to be consistent with this framework because doing so will
-   make their mechanisms easier to implement.  Kerberos implementations
-   are likely to have plugin architectures  for preauthentication; such
-   architectures are likely to support mechanisms that follow this
-   framework plus commonly used extensions.
-
-   This document should be read only after reading the documents
-   describing the Kerberos cryptography framework [3] and the core
-   Kerberos protocol [2].  This document freely uses terminology and
-   notation from these documents without reference or further
-   explanation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires August 9, 2004                 [Page 3]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-2. Model for Preauthentication
-
-   when a Kerberos client wishes to obtain a ticket using the
-   authentication server, it sends an initial AS request.  If
-   preauthentication is being used, then the KDC will respond with a
-   KDC_ERR_PREAUTH_REQUIRED error.  Alternatively, if the client knows
-   what preauthentication to use, it MAY optimize a round-trip and send
-   an initial request with padata included.  If the client includes the
-   wrong padata, the server MAY return KDC_ERR_PREAUTH_FAILED with no
-   indication of what padata should have been included.  For
-   interoperability reasons, clients that include optimistic preauth
-   MUST retry with no padata and examine the KDC_ERR_PREAUTH_REQUIRED if
-   they receive a KDC_ERR_PREAUTH_FAILED in response to their initial
-   optimistic request.
-
-   The KDC maintains no state between two requests; subsequent requests
-   may even be processed by a different KDC. On the other hand, the
-   client treats a series of exchanges with KDCs as a single
-   authentication session.  Each exchange accumulates state and
-   hopefully brings the client closer to a successful authentication.
-
-   These models for state management are in apparent conflict. For many
-   of the simpler preauthentication scenarios,  the client uses one
-   round trip to find out what mechanisms the KDC supports.  Then the
-   next request contains sufficient preauthentication for the KDC to be
-   able to return a successful response.  For these simple scenarios,
-   the client only sends one request with preauthentication data and so
-   the authentication session is trivial.  For more complex
-   authentication sessions, the KDC needs to provide the client with a
-   cookie to include in future requests to capture the current state of
-   the authentication session.  Handling of multiple round-trip
-   mechanisms is discussed in Section 5.3.
-
-   This framework specifies the behavior of Kerberos preauthentication
-   mechanisms used to identify users or to modify the reply key used to
-   encrypt the KDC response.  The padata typed hole may be used to carry
-   extensions to Kerberos that have nothing to do with proving the
-   identity of the user or establishing a reply key.  These extensions
-   are outside the scope of this framework.  However mechanisms that do
-   accomplish these goals should follow this framework.
-
-   This framework specifies the minimum state that a Kerberos
-   implementation needs to maintain while handling a request in order to
-   process preauthentication.  It also specifies how Kerberos
-   implementations process the preauthentication data at each step of
-   the AS request process.
-
-
-
-
-
-Hartman                  Expires August 9, 2004                 [Page 4]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-2.1 Information Managed by Model
-
-   The following information is maintained by the client and KDC as each
-   request is being processed:
-
-   o  The reply key used to encrypt the KDC response
-
-   o  How strongly the identity of the client has been authenticated
-
-   o  Whether the reply key has been used in this authentication session
-
-   o  Whether the contents of the KDC response can be  verified by the
-      client principal
-
-   o  Whether the contents of the KDC response can be  verified by the
-      client machine
-
-   Conceptually, the reply key is initially the long-term key of the
-   principal.  However, principals can have multiple long-term keys
-   because of support for multiple encryption types, salts and
-   string2key parameters.  As described in section 5.2.7.5 of the
-   Kerberos protocol [2], the KDC sends PA-ETYPe-INFO2 to notify the
-   client  what types of keys are available.  Thus in full generality,
-   the reply key in the preauth model is actually a set of keys.  At the
-   beginning of a request, it is initialized to the set of long-term
-   keys advertised in the PA-ETYPE-INFO2 element on the KDC.  If
-   multiple reply keys are available, the client chooses which one to
-   use.  Thus the client does not need to treat the reply key as a set.
-   At the beginning of a handling a request, the client picks a reply
-   key to use.
-
-   KDC implementations MAY choose to offer only one key in the
-   PA-ETYPE-INFO2 element.  Since the KDC already knows the client's
-   list of supported enctypes from the  request, no interoperability
-   problems are created by choosing a single possible reply key.  This
-   way, the KDC implementation avoids the complexity of treating the
-   reply key as a set.
-
-   At the beginning of handling a message on both the client and KDC,
-   the client's identity is not authenticated.  A mechanism may indicate
-   that it has successfully authenticated the client's identity.  This
-   information is useful to keep track of on the client  in order to
-   know what preauthentication mechanisms should be used.  The KDC needs
-   to keep track of whether the client is authenticated because the
-   primary purpose of preauthentication is to authenticate the client
-   identity before issuing a ticket.  Implementations that have
-   preauthentication mechanisms offering significantly different
-   strengths of client authentication MAY choose to keep track of the
-
-
-
-Hartman                  Expires August 9, 2004                 [Page 5]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-   strength of the authentication used as an input into policy
-   decisions.  For example, some principals might require strong
-   preauthentication, while less sensitive principals can use relatively
-   weak forms of preauthentication like encrypted timestamp.
-
-   Initially the reply key has not been used.  A preauthentication
-   mechanism that uses the reply key either directly to encrypt or
-   cheksum some data or indirectly in the generation of new keys MUST
-   indicate that the reply key is used.  This state is maintained by the
-   client and KDC to enforce the security requirement stated in Section
-   3.3 that the reply key cannot be replaced after it is used.
-
-   Without preauthentication, the client knows that the KDC request is
-   authentic and has not been modified because it is encrypted in the
-   long-term key of the client.  Only the KDC and client know that key.
-   So at the start of handling any message the KDC request is presumed
-   to be verified to the client principal.  Any preauthentication
-   mechanism that sets a new reply key not based on the principal's
-   long-term secret MUST either verify the KDC response some other way
-   or indicate that the response is not verified.  If a mechanism
-   indicates that the response is not verified then the client
-   implementation MUST return an error unless a subsequent mechanism
-   verifies the response.  The KDC needs to track this state so it can
-   avoid generating a response that is not verified.
-
-   The typical Kerberos request does not provide a way for the client
-   machine to know that it is talking to the correct KDC. Someone who
-   can inject packets into the network between the client machine and
-   the KDC and who knows the password that the user will give to the
-   client machine can generate a KDC response that will decrypt
-   properly.  So, if the client machine needs to authenticate that the
-   user is in fact the named principal, then the client machine needs to
-   do a TGS request for itself as a service.  Some preauthentication
-   mechanisms may provide  a way for the client to authenticate the KDC.
-   Examples of this include signing the response with a well-known
-   public key or providing a ticket for the client machine as a service
-   in addition to the requested ticket.
-
-2.2 The Preauth_Required Error
-
-   Typically a client starts an authentication session by sending  an
-   initial request with no preauthentication.  If the KDC requires
-   preauthentication, then it returns a KDC_ERR_PREAUTH_REQUIRED
-   message.  This message MAY also be returned for preauthentication
-   configurations that use multi-round-trip mechanisms.  This error
-   contains a sequence of padata.  Typically the padata contains the
-   preauth type IDs of all the available preauthentication mechanisms.
-   IN the initial error response, most mechanisms do not contain data.
-
-
-
-Hartman                  Expires August 9, 2004                 [Page 6]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-   If a mechanism requires multiple round trips or starts with a
-   challenge from the KDC to the client, then it will likely contain
-   data in the initial error response.
-
-   The KDC SHOULD NOT send data that is encrypted in the long-term
-   password-based key of the principal.  Doing so has the same security
-   exposures as the Kerberos protocol without preauthentication.  There
-   are few situations where preauthentication is desirable and where the
-   KDC needs to expose ciphertext encrypted in a weak key before the
-   client has proven knowledge of that key.
-
-   In order to generate the error response, the KDC first starts by
-   initializing the preauthentication state.  Then it processes any
-   padata in the client's request in the order provided by the client.
-   Mechanisms that are not understood by the KDC are ignored.
-   Mechanisms that are inappropriate for the client principal or request
-   SHOULD also be ignored.  Next, it generates padata for the error
-   response, modifying the preauthentication state appropriately as each
-   mechanism is processed.  The KDC chooses the order in which it will
-   generated padata (and thus the order of padata in the response), but
-   it needs to modify the preauthentication state consistently with the
-   choice of order.  For example, if some mechanism establishes an
-   authenticated client identity, then the mechanisms subsequent in the
-   generated response receive this state as input.  After the padata is
-   generated, the error response is sent.
-
-2.3 Client to KDC
-
-   This description assumes a client has already received a
-   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
-   optimistic preauthentication then the client needs to optimisticly
-   choose the information it would normally receive from that error
-   response.
-
-   The client starts by initializing the preauthentication state as
-   specified.  It then processes the pdata in the
-   KDC_ERR_PREAUTH_REQUIRED.
-
-   After processing the pdata in the KDC error, the client generates a
-   new request.  It processes the preauthentication mechanisms in the
-   order in which they will appear in the next request, updating the
-   state as appropriate. When the request is complete it is sent.
-
-2.4 KDC to Client
-
-   When a KDC receives an AS request from a client, it needs to
-   determine whether it will respond with an error or  a AS reply.
-   There are many causes for an error to be generated that have nothing
-
-
-
-Hartman                  Expires August 9, 2004                 [Page 7]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-   to do with preauthentication; they are discussed in the Kerberos
-   specification.
-
-   From the standpoint of evaluating the preauthentication, the KDC
-   first starts by initializing the preauthentication state.  IT then
-   processes the padata in the request.  AS mentioned in Section 2.2,
-   the KDC MAY ignore padata that is inappropriate for the configuration
-   and MUST ignore padata of an unknown type.
-
-   At this point the KDC decides whether it will issue a
-   preauthentication required error or a reply.  Typically a KDC will
-   issue a reply if the client's identity has been authenticated to a
-   sufficient degree.  The processing of the preauthentication required
-   error is described in Section 2.2.
-
-   The KDC generates the pdata modifying the preauthentication state as
-   necessary.  Then it generates the final response, encrypting it in
-   the current preauthentication reply key.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires August 9, 2004                 [Page 8]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-3. Preauthentication Facilities
-
-   Preauthentication mechanisms can be thought of as conceptually
-   providing various facilities.  This serves two useful purposes.
-   First, mechanism authors can choose only to solve one specific small
-   problem.  It is often useful for a mechanism designed to offer key
-   management not to directly provide client authentication but instead
-   to allow one or more other mechanisms to handle this need.  Secondly,
-   thinking about the  abstract services that a mechanism provides
-   yields a minimum set of security requirements that all mechanisms
-   providing that facility must meet. These security requirements are
-   not complete; mechanisms will have additional security requirements
-   based on the specific protocol they employ.
-
-   A mechanism is not constrained to only offering one of these
-   facilities.  While such mechanisms can be designed and are sometimes
-   useful, many preauthentication mechanisms implement several
-   facilities.  By combining multiple facilities in a single mechanism,
-   it is often easier to construct a secure, simple solution than  by
-   solving the problem in full generality.  Even when mechanisms provide
-   multiple facilities, they need to meet the security requirements for
-   all the facilities they provide.
-
-   According to Kerberos extensibility rules (section 1.4.2 of the
-   Kerberos specification [2]), an extension MUST NOT change the
-   semantics of a message unless a recipient is known to understand that
-   extension.  Because a client does not know that the KDC supports a
-   particular preauth mechanism when it sends an initial request, a
-   preauth mechanism MUST NOT change the semantics of the request in a
-   way that will break a KDC that does not understand that mechanism.
-   Similarly, KDCs MUST not send messages to clients that affect the
-   core semantics unless the clients have indicated support for the
-   message.
-
-   The only state in this model that would break the interpretation of a
-   message is changing the expected reply key.  If one mechanism changed
-   the reply key and a later mechanism used that reply key, then a KDC
-   that interpreted the second mechanism but not the first would fail to
-   interpret the request correctly.  In order to avoid this problem,
-   extensions that change core semantics are typically divided into two
-   parts.  The first part proposes a change to the core semantic--for
-   example proposes a new reply key.  The second part acknowledges that
-   the extension is understood and that the change takes effect. Section
-   3.2 discusses how to design mechanisms that modify the reply key to
-   be split into a proposal and acceptance without requiring additional
-   round trips to use the new reply key in subsiquent preauthentication.
-   Other changes in the state described in Section 2.1 can safely be
-   ignored by a KDC that does not understand a mechanism.  Mechanisms
-
-
-
-Hartman                  Expires August 9, 2004                 [Page 9]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-   that modify the behavior of the request outside the scope of this
-   framework need to carefully consider the Kerberos extensibility rules
-   to avoid similar problems.
-
-3.1 Client Authentication
-
-      Binding to reply key
-
-      Consider Secure ID case where you don't have anything to bind to
-
-
-3.2 Strengthen Reply Key
-
-   Particularly, when dealing with keys based on passwords it is
-   desirable to increase the strength of the key by adding additional
-   secrets to it.  Examples of sources of additional secrets include the
-   results of a Diffie-Hellman key exchange or key bits from the output
-   of a smart card [5].  Typically these additional secrets are
-   converted into a Kerberos protocol key.  Then they are combined with
-   the existing reply key as discussed in Section 5.1.
-
-   If a mechanism implementing this facility wishes to modify the reply
-   key before knowing that the other party in the exchange supports the
-   mechanism, it proposes modifying the reply key.  The other party then
-   includes a message indicating that the proposal is accepted if it is
-   understood and meets policy.  In many cases it is desirable to use
-   the new reply key for client authentication and for other facilities.
-   Waiting for the other party to accept the proposal and actually
-   modify the reply key state would add an additional round trip to the
-   exchange.  Instead, mechanism designers  are encouraged to include a
-   typed hole for additional padata in the message that proposes the
-   reply key change.  The padata included in the typed hole are
-   generated assuming the new reply key. If the other party accepts the
-   proposal, then these padata are interpreted as if they were included
-   immediately following the proposal.  The party generating the
-   proposal can determine whether the padata were processed based on
-   whether the proposal for the reply key is accepted.
-
-   The specific formats of the proposal message, including where padata
-   are  are included is a matter for the mechanism specification.
-   Similarly, the format of the message accepting the proposal is
-   mechanism-specific.
-
-   Mechanisms implementing this facility and including a typed hole for
-   additional padata MUST checksum that padata using a keyed checksum or
-   encrypt the padata.  Typically the reply key is used to protect the
-   padata.  XXX If you are only minimally increasing the strength of the
-   reply key, this may give the attacker access to something too close
-
-
-
-Hartman                  Expires August 9, 2004                [Page 10]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-   to the original reply key.  However, binding the padata to the new
-   reply key  seems potentially important from a security standpoint.
-   There may also be objections to this from a double encryption
-   standpoint because we also recommend client authentication facilities
-   be tied to the reply key.
-
-3.3 Replace Reply Key
-
-      Containers to handle reply key when not sure whether other side
-      supports mech
-
-      Make sure reply key is not used previously
-
-      Interactions with client authentication
-
-      Reference to container argument
-
-
-3.4 Verify Response
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires August 9, 2004                [Page 11]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-4. Requirements for Preauthentication Mechanisms
-
-      State management for multi-round-trip mechs
-
-      Security interactions with other mechs
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires August 9, 2004                [Page 12]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-5. Tools for Use in Preauthentication Mechanisms
-
-5.1 Combine Keys
-
-5.2 Signing Requests/Responses
-
-5.3 Managing State for the KDC
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires August 9, 2004                [Page 13]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-6. IANA Considerations
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires August 9, 2004                [Page 14]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-7. Security Considerations
-
-      Very little of the AS request is authenticated.  Same for padata
-      in the reply or error.  Discuss implications
-
-      Table of security requirements stated elsewhere in the document
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires August 9, 2004                [Page 15]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-8. Acknowledgements
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires August 9, 2004                [Page 16]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", RFC 2119, BCP 14, March 1997.
-
-   [2]  Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos
-        Network Authentication Service (V5)",
-        draft-ietf-krb-wg-kerberos-clarifications-04.txt (work in
-        progress), June 2003.
-
-   [3]  Raeburn, K., "Encryption and Checksum Specifications for
-        Kerberos 5", draft-ietf-krb-wg-crypto-03.txt (work in progress).
-
-   [4]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
-        2279, January 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires August 9, 2004                [Page 17]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-Informative References
-
-   [5]  Hornstein, K., Renard, K., Neuman, C. and G. Zorn, "Integrating
-        Single-use Authentication Mechanisms with Kerberos",
-        draft-ietf-krb-wg-kerberos-sam-02.txt (work in progress),
-        October 2003.
-
-
-Author's Address
-
-   Sam hartman
-   MIT
-
-   EMail: hartmans@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires August 9, 2004                [Page 18]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-Appendix A. Todo List
-
-      Flesh out sections that are still outlines
-
-      Discuss cookies and multiple-round-trip mechanisms.
-
-      Talk about checksum contributions from each mechanism
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires August 9, 2004                [Page 19]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights. Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11. Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard. Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Hartman                  Expires August 9, 2004                [Page 20]
-
-Internet-Draft        Kerberos Preauth Framework           February 2004
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires August 9, 2004                [Page 21]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-01.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-01.txt
deleted file mode 100644
index a98e7e658..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-01.txt
+++ /dev/null
@@ -1,1165 +0,0 @@
-Kerberos Working Group                                        S. Hartman
-Internet-Draft                                                       MIT
-Expires: January 17, 2005                                  July 19, 2004
-
-
-
-        A Generalized Framework for Kerberos Pre-Authentication
-                 draft-ietf-krb-wg-preauth-framework-01
-
-
-Status of this Memo
-
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-
-   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."
-
-
-   The list of current Internet-Drafts can be accessed at http://
-   www.ietf.org/ietf/1id-abstracts.txt.
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-   This Internet-Draft will expire on January 17, 2005.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-
-Abstract
-
-
-   Kerberos is a protocol for verifying the identity of principals
-   (e.g., a workstation user or a network server) on an open network.
-   The Kerberos protocol provides a mechanism called pre-authentication
-   for proving the identity  of a principal and for better protecting
-   the long-term secret of the principal.
-
-
-   This document describes a model for Kerberos pre-authentication
-   mechanisms.  The model describes what state in the Kerberos request a
-   pre-authentication mechanism is likely to change. It also describes
-   how multiple pre-authentication mechanisms used in the same request
-   will interact.
-
-
-
-
-Hartman                 Expires January 17, 2005                [Page 1]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-   This document also provides common tools needed by multiple
-   pre-authentication mechanisms.
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [1].
-
-
-Table of Contents
-
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  4
-     2.1   Information Managed by Model . . . . . . . . . . . . . . .  5
-     2.2   The Preauth_Required Error . . . . . . . . . . . . . . . .  7
-     2.3   Client to KDC  . . . . . . . . . . . . . . . . . . . . . .  7
-     2.4   KDC to Client  . . . . . . . . . . . . . . . . . . . . . .  8
-   3.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . .  9
-     3.1   Client Authentication  . . . . . . . . . . . . . . . . . . 10
-     3.2   Strengthen Reply Key . . . . . . . . . . . . . . . . . . . 10
-     3.3   Replace Reply Key  . . . . . . . . . . . . . . . . . . . . 11
-     3.4   Verify Response  . . . . . . . . . . . . . . . . . . . . . 11
-   4.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 12
-   5.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 13
-     5.1   Combine Keys . . . . . . . . . . . . . . . . . . . . . . . 13
-     5.2   Signing Requests/Responses . . . . . . . . . . . . . . . . 13
-     5.3   Managing State for the KDC . . . . . . . . . . . . . . . . 13
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
-   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 17
-   9.2   Informative References . . . . . . . . . . . . . . . . . . . 17
-   A.  Todo List  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
-       Intellectual Property and Copyright Statements . . . . . . . . 19
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 17, 2005                [Page 2]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-1.  Introduction
-
-
-   The core Kerberos specification treats pre-authentication data as an
-   opaque typed hole in the messages to the KDC that may influence the
-   reply key used to encrypt the KDC response.  This generality has been
-   useful: pre-authentication data is used for a variety of extensions
-   to the protocol, many outside the expectations of the initial
-   designers.  However, this generality makes designing the more common
-   types of pre-authentication mechanisms difficult. Each mechanism
-   needs to specify how it interacts with other mechanisms.  Also,
-   problems like combining a key with the long-term secret or proving
-   the identity of the user are common to multiple mechanisms.  Where
-   there are generally well-accepted solutions to these problems, it is
-   desirable to standardize one of these solutions so mechanisms  can
-   avoid duplication of work.  In other cases, a modular approach to
-   these problems is appropriate.  The modular approach will allow new
-   and better solutions to common pre-authentication problems to be used
-   by existing mechanisms as they are developed.
-
-
-   This document specifies a framework for Kerberos pre-authentication
-   mechanisms.  IT defines the common set of functions
-   pre-authentication mechanisms perform as well as how these functions
-   affect the state of the request and response.  In addition several
-   common tools needed by pre-authentication mechanisms are provided.
-   Unlike [3], this framework is not complete--it does not describe all
-   the inputs and outputs for the pre-authentication mechanisms.
-   Mechanism designers should try to be consistent with this framework
-   because doing so will make their mechanisms easier to implement.
-   Kerberos implementations are likely to have plugin architectures  for
-   pre-authentication; such architectures are likely to support
-   mechanisms that follow this framework plus commonly used extensions.
-
-
-   This document should be read only after reading the documents
-   describing the Kerberos cryptography framework [3] and the core
-   Kerberos protocol [2].  This document freely uses terminology and
-   notation from these documents without reference or further
-   explanation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 17, 2005                [Page 3]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-2.  Model for Pre-Authentication
-
-
-   when a Kerberos client wishes to obtain a ticket using the
-   authentication server, it sends an initial AS request.  If
-   pre-authentication is being used, then the KDC will respond with a
-   KDC_ERR_PREAUTH_REQUIRED error.  Alternatively, if the client knows
-   what pre-authentication to use, it MAY optimize a round-trip and send
-   an initial request with padata included.  If the client includes the
-   wrong padata, the server MAY return KDC_ERR_PREAUTH_FAILED with no
-   indication of what padata should have been included.  For
-   interoperability reasons, clients that include optimistic
-   pre-authentication MUST retry with no padata and examine the
-   KDC_ERR_PREAUTH_REQUIRED if they receive a KDC_ERR_PREAUTH_FAILED in
-   response to their initial optimistic request.
-
-
-   The KDC maintains no state between two requests; subsequent requests
-   may even be processed by a different KDC. On the other hand, the
-   client treats a series of exchanges with KDCs as a single
-   authentication session.  Each exchange accumulates state and
-   hopefully brings the client closer to a successful authentication.
-
-
-   These models for state management are in apparent conflict. For many
-   of the simpler pre-authentication scenarios,  the client uses one
-   round trip to find out what mechanisms the KDC supports.  Then the
-   next request contains sufficient pre-authentication for the KDC to be
-   able to return a successful response.  For these simple scenarios,
-   the client only sends one request with pre-authentication data and so
-   the authentication session is trivial.  For more complex
-   authentication sessions, the KDC needs to provide the client with a
-   cookie to include in future requests to capture the current state of
-   the authentication session.  Handling of multiple round-trip
-   mechanisms is discussed in Section 5.3.
-
-
-   This framework specifies the behavior of Kerberos pre-authentication
-   mechanisms used to identify users or to modify the reply key used to
-   encrypt the KDC response.  The padata typed hole may be used to carry
-   extensions to Kerberos that have nothing to do with proving the
-   identity of the user or establishing a reply key.  These extensions
-   are outside the scope of this framework.  However mechanisms that do
-   accomplish these goals should follow this framework.
-
-
-   This framework specifies the minimum state that a Kerberos
-   implementation needs to maintain while handling a request in order to
-   process pre-authentication.  It also specifies how Kerberos
-   implementations process the pre-authentication data at each step of
-   the AS request process.
-
-
-
-
-
-
-Hartman                 Expires January 17, 2005                [Page 4]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-2.1  Information Managed by Model
-
-
-   The following information is maintained by the client and KDC as each
-   request is being processed:
-   o  The reply key used to encrypt the KDC response
-   o  How strongly the identity of the client has been authenticated
-   o  Whether the reply key has been used in this authentication session
-   o  Whether the reply key has been replaced in this authentication
-      session
-   o  Whether the contents of the KDC response can be  verified by the
-      client principal
-   o  Whether the contents of the KDC response can be  verified by the
-      client machine
-
-
-   Conceptually, the reply key is initially the long-term key of the
-   principal.  However, principals can have multiple long-term keys
-   because of support for multiple encryption types, salts and
-   string2key parameters.  As described in section 5.2.7.5 of the
-   Kerberos protocol [2], the KDC sends PA-ETYPe-INFO2 to notify the
-   client  what types of keys are available.  Thus in full generality,
-   the reply key in the pre-authentication model is actually a set of
-   keys.  At the beginning of a request, it is initialized to the set of
-   long-term keys advertised in the PA-ETYPE-INFO2 element on the KDC.
-   If multiple reply keys are available, the client chooses which one to
-   use.  Thus the client does not need to treat the reply key as a set.
-   At the beginning of a handling a request, the client picks a reply
-   key to use.
-
-
-   KDC implementations MAY choose to offer only one key in the
-   PA-ETYPE-INFO2 element.  Since the KDC already knows the client's
-   list of supported enctypes from the  request, no interoperability
-   problems are created by choosing a single possible reply key.  This
-   way, the KDC implementation avoids the complexity of treating the
-   reply key as a set.
-
-
-   At the beginning of handling a message on both the client and KDC,
-   the client's identity is not authenticated.  A mechanism may indicate
-   that it has successfully authenticated the client's identity.  This
-   information is useful to keep track of on the client  in order to
-   know what pre-authentication mechanisms should be used.  The KDC
-   needs to keep track of whether the client is authenticated because
-   the primary purpose of pre-authentication is to authenticate the
-   client identity before issuing a ticket.  Implementations that have
-   pre-authentication mechanisms offering significantly different
-   strengths of client authentication MAY choose to keep track of the
-   strength of the authentication used as an input into policy
-   decisions.  For example, some principals might require strong
-   pre-authentication, while less sensitive principals can use
-
-
-
-
-Hartman                 Expires January 17, 2005                [Page 5]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-   relatively weak forms of pre-authentication like encrypted timestamp.
-
-
-   Initially the reply key has not been used.  A pre-authentication
-   mechanism that uses the reply key either directly to encrypt or
-   checksum some data or indirectly in the generation of new keys MUST
-   indicate that the reply key is used.  This state is maintained by the
-   client and KDC to enforce the security requirement stated in Section
-   3.3 that the reply key cannot be replaced after it is used.
-
-
-   Initially the reply key has not been replaced.  If a mechanism
-   implements the Replace Reply Key facility discussed in Section 3.3,
-   then the state MUST be updated to indicate that the reply key has
-   been replaced. Once the reply key has been replaced, knowledge of the
-   reply key is insufficient to authenticate the client. The reply key
-   is marked replaced in exactly the same situations as the KDC reply
-   is marked as not being verified to the client principal.  However,
-   while mechanisms can verify the KDC request to the client, once the
-   reply key is replaced, then the reply key remains replaced for the
-   remainder of the authentication session.
-
-
-   Without pre-authentication, the client knows that the KDC request is
-   authentic and has not been modified because it is encrypted in the
-   long-term key of the client.  Only the KDC and client know that key.
-   So at the start of handling any message the KDC request is presumed
-   to be verified to the client principal.  Any pre-authentication
-   mechanism that sets a new reply key not based on the principal's
-   long-term secret MUST either verify the KDC response some other way
-   or indicate that the response is not verified.  If a mechanism
-   indicates that the response is not verified then the client
-   implementation MUST return an error unless a subsequent mechanism
-   verifies the response.  The KDC needs to track this state so it can
-   avoid generating a response that is not verified.
-
-
-   The typical Kerberos request does not provide a way for the client
-   machine to know that it is talking to the correct KDC. Someone who
-   can inject packets into the network between the client machine and
-   the KDC and who knows the password that the user will give to the
-   client machine can generate a KDC response that will decrypt
-   properly.  So, if the client machine needs to authenticate that the
-   user is in fact the named principal, then the client machine needs to
-   do a TGS request for itself as a service.  Some pre-authentication
-   mechanisms may provide  a way for the client to authenticate the KDC.
-   Examples of this include signing the response with a well-known
-   public key or providing a ticket for the client machine as a service
-   in addition to the requested ticket.
-
-
-
-
-
-
-
-Hartman                 Expires January 17, 2005                [Page 6]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-2.2  The Preauth_Required Error
-
-
-   Typically a client starts an authentication session by sending  an
-   initial request with no pre-authentication.  If the KDC requires
-   pre-authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED
-   message.  This message MAY also be returned for pre-authentication
-   configurations that use multi-round-trip mechanisms.  This error
-   contains a sequence of padata.  Typically the padata contains the
-   pre-authentication type IDs of all the available pre-authentication
-   mechanisms.  IN the initial error response, most mechanisms do not
-   contain data.  If a mechanism requires multiple round trips or starts
-   with a challenge from the KDC to the client, then it will likely
-   contain data in the initial error response.
-
-
-   The KDC SHOULD NOT send data that is encrypted in the long-term
-   password-based key of the principal.  Doing so has the same security
-   exposures as the Kerberos protocol without pre-authentication.  There
-   are few situations where pre-authentication is desirable and where
-   the KDC needs to expose ciphertext encrypted in a weak key before the
-   client has proven knowledge of that key.
-
-
-   In order to generate the error response, the KDC first starts by
-   initializing the pre-authentication state.  Then it processes any
-   padata in the client's request in the order provided by the client.
-   Mechanisms that are not understood by the KDC are ignored.
-   Mechanisms that are inappropriate for the client principal or request
-   SHOULD also be ignored.  Next, it generates padata for the error
-   response, modifying the pre-authentication state appropriately as
-   each mechanism is processed.  The KDC chooses the order in which it
-   will generated padata (and thus the order of padata in the response),
-   but it needs to modify the pre-authentication state consistently with
-   the choice of order.  For example, if some mechanism establishes an
-   authenticated client identity, then the mechanisms subsequent in the
-   generated response receive this state as input.  After the padata is
-   generated, the error response is sent.
-
-
-2.3  Client to KDC
-
-
-   This description assumes a client has already received a
-   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
-   optimistic pre-authentication then the client needs to optimisticly
-   choose the information it would normally receive from that error
-   response.
-
-
-   The client starts by initializing the pre-authentication state as
-   specified.  It then processes the pdata in the
-   KDC_ERR_PREAUTH_REQUIRED.
-
-
-
-
-
-Hartman                 Expires January 17, 2005                [Page 7]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-   After processing the pdata in the KDC error, the client generates a
-   new request.  It processes the pre-authentication mechanisms in the
-   order in which they will appear in the next request, updating the
-   state as appropriate. When the request is complete it is sent.
-
-
-2.4  KDC to Client
-
-
-   When a KDC receives an AS request from a client, it needs to
-   determine whether it will respond with an error or  a AS reply.
-   There are many causes for an error to be generated that have nothing
-   to do with pre-authentication; they are discussed in the Kerberos
-   specification.
-
-
-   From the standpoint of evaluating the pre-authentication, the KDC
-   first starts by initializing the pre-authentication state.  IT then
-   processes the padata in the request.  AS mentioned in Section 2.2,
-   the KDC MAY ignore padata that is inappropriate for the configuration
-   and MUST ignore padata of an unknown type.
-
-
-   At this point the KDC decides whether it will issue a
-   pre-authentication required error or a reply.  Typically a KDC will
-   issue a reply if the client's identity has been authenticated to a
-   sufficient degree.  The processing of the pre-authentication required
-   error is described in Section 2.2.
-
-
-   The KDC generates the pdata modifying the pre-authentication state as
-   necessary.  Then it generates the final response, encrypting it in
-   the current pre-authentication reply key.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 17, 2005                [Page 8]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-3.  Pre-Authentication Facilities
-
-
-   Pre-Authentication mechanisms can be thought of as providing various
-   conceptual facilities.  This serves two useful purposes.  First,
-   mechanism authors can choose only to solve one specific small
-   problem.  It is often useful for a mechanism designed to offer key
-   management not to directly provide client authentication but instead
-   to allow one or more other mechanisms to handle this need.  Secondly,
-   thinking about the  abstract services that a 2mechanism provides
-   yields a minimum set of security requirements that all mechanisms
-   providing that facility must meet. These security requirements are
-   not complete; mechanisms will have additional security requirements
-   based on the specific protocol they employ.
-
-
-   A mechanism is not constrained to only offering one of these
-   facilities.  While such mechanisms can be designed and are sometimes
-   useful, many pre-authentication mechanisms implement several
-   facilities.  By combining multiple facilities in a single mechanism,
-   it is often easier to construct a secure, simple solution than  by
-   solving the problem in full generality.  Even when mechanisms provide
-   multiple facilities, they need to meet the security requirements for
-   all the facilities they provide.
-
-
-   According to Kerberos extensibility rules (section 1.4.2 of the
-   Kerberos specification [2]), an extension MUST NOT change the
-   semantics of a message unless a recipient is known to understand that
-   extension.  Because a client does not know that the KDC supports a
-   particular pre-authentication mechanism when it sends an initial
-   request, a preauth mechanism MUST NOT change the semantics of the
-   request in a way that will break a KDC that does not understand that
-   mechanism.  Similarly, KDCs MUST not send messages to clients that
-   affect the core semantics unless the clients have indicated support
-   for the message.
-
-
-   The only state in this model that would break the interpretation of a
-   message is changing the expected reply key.  If one mechanism changed
-   the reply key and a later mechanism used that reply key, then a KDC
-   that interpreted the second mechanism but not the first would fail to
-   interpret the request correctly.  In order to avoid this problem,
-   extensions that change core semantics are typically divided into two
-   parts.  The first part proposes a change to the core semantic--for
-   example proposes a new reply key.  The second part acknowledges that
-   the extension is understood and that the change takes effect. Section
-   3.2 discusses how to design mechanisms that modify the reply key to
-   be split into a proposal and acceptance without requiring additional
-   round trips to use the new reply key in subsequent
-   pre-authentication. Other changes in the state described in Section
-   2.1 can safely be ignored by a KDC that does not understand a
-
-
-
-
-Hartman                 Expires January 17, 2005                [Page 9]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-   mechanism.  Mechanisms that modify the behavior of the request
-   outside the scope of this framework need to carefully consider the
-   Kerberos extensibility rules to avoid similar problems.
-
-
-3.1  Client Authentication
-
-
-   The client authentication facility proves the identity of a user to
-   the KDC before a ticket is issued.  Examples of mechanisms
-   implementing this facility include the encrypted timestamp facility
-   defined in Section 5.2.7.2 of the Kerberos specification [2] and the
-   single-use mechanism defined in [5]. Mechanisms that provide this
-   facility are expected to mark the client  as authenticated.
-
-
-   Mechanisms implementing this facility SHOULD require the client to
-   prove knowledge  of the reply key before transmitting a successful
-   KDC reply.  Otherwise, an attacker can intercept the
-   pre-authentication exchange and get a reply to attack.  One way of
-   proving the client knows the reply key is to implement the Replace
-   Reply Key facility along with this facility.  The Pkinit mechanism
-   [6] implements Client Authentication along side Replace Reply Key.
-
-
-   If the reply key has been replaced, then mechanisms such as encrypted
-   timestamp that rely on knowledge of the reply key to authenticate the
-   client MUST NOT be used.
-
-
-3.2  Strengthen Reply Key
-
-
-   Particularly, when dealing with keys based on passwords, it is
-   desirable to increase the strength of the key by adding additional
-   secrets to it.  Examples of sources of additional secrets include the
-   results of a Diffie-Hellman key exchange or key bits from the output
-   of a smart card [5].  Typically these additional secrets are
-   converted into a Kerberos protocol key.  Then they are combined with
-   the existing reply key as discussed in Section 5.1.
-
-
-   If a mechanism implementing this facility wishes to modify the reply
-   key before knowing that the other party in the exchange supports the
-   mechanism, it proposes modifying the reply key.  The other party then
-   includes a message indicating that the proposal is accepted if it is
-   understood and meets policy.  In many cases it is desirable to use
-   the new reply key for client authentication and for other facilities.
-   Waiting for the other party to accept the proposal and actually
-   modify the reply key state would add an additional round trip to the
-   exchange.  Instead, mechanism designers  are encouraged to include a
-   typed hole for additional padata in the message that proposes the
-   reply key change.  The padata included in the typed hole are
-   generated assuming the new reply key. If the other party accepts the
-   proposal, then these padata are interpreted as if they were included
-
-
-
-
-Hartman                 Expires January 17, 2005               [Page 10]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-   immediately following the proposal.  The party generating the
-   proposal can determine whether the padata were processed based on
-   whether the proposal for the reply key is accepted.
-
-
-   The specific formats of the proposal message, including where padata
-   are  are included is a matter for the mechanism specification.
-   Similarly, the format of the message accepting the proposal is
-   mechanism-specific.
-
-
-   Mechanisms implementing this facility and including a typed hole for
-   additional padata MUST checksum that padata using a keyed checksum or
-   encrypt the padata.  Typically the reply key is used to protect the
-   padata.  XXX If you are only minimally increasing the strength of the
-   reply key, this may give the attacker access to something too close
-   to the original reply key.  However, binding the padata to the new
-   reply key  seems potentially important from a security standpoint.
-   There may also be objections to this from a double encryption
-   standpoint because we also recommend client authentication facilities
-   be tied to the reply key.
-
-
-3.3  Replace Reply Key
-
-
-   The Replace Reply Key facility replaces the key in which a successful
-   AS reply will be encrypted.    This facility can only be used in
-   cases where knowledge of the reply key is not used to authenticate
-   the client.  The new reply key MUST be communicated to the client and
-   KDC in a secure manner.    Mechanisms implementing this facility MUST
-   mark the reply key as replaced in the pre-authentication state.
-   Mechanisms implementing this facility MUST either provide a mechanism
-   to verify the KDC reply to the client or mark the reply as unverified
-   in the pre-authentication state. Mechanisms implementing this
-   facility SHOULD NOT be used if a previous mechanism has used the
-   reply key.
-
-
-   As with the Strengthen Reply Key facility, Kerberos extensibility
-   rules require that the reply key not be changed unless both sides of
-   the exchange understand the extension.  In the case of this facility
-   it will likely be more common for both sides to know that the
-   facility is available by the time that the new key is available to be
-   used.  However, mechanism designers can use a container for padata in
-   a proposal message as discussed in Section 3.2 if appropriate.
-
-
-3.4  Verify Response
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 17, 2005               [Page 11]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-4.  Requirements for Pre-Authentication Mechanisms
-
-
-      State management for multi-round-trip mechs
-      Security interactions with other mechs
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 17, 2005               [Page 12]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-5.  Tools for Use in Pre-Authentication Mechanisms
-
-
-5.1  Combine Keys
-
-
-5.2  Signing Requests/Responses
-
-
-5.3  Managing State for the KDC
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 17, 2005               [Page 13]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-6.  IANA Considerations
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 17, 2005               [Page 14]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-7.  Security Considerations
-
-
-      Very little of the AS request is authenticated.  Same for padata
-      in the reply or error.  Discuss implications
-      Table of security requirements stated elsewhere in the document
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 17, 2005               [Page 15]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-8.  Acknowledgements
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 17, 2005               [Page 16]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-9.  References
-
-
-9.1  Normative References
-
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", RFC 2119, BCP 14, March 1997.
-
-
-   [2]  Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos
-        Network Authentication Service (V5)",
-        draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
-        progress), June 2004.
-
-
-   [3]  Raeburn, K., "Encryption and Checksum Specifications for
-        Kerberos 5", draft-ietf-krb-wg-crypto-03.txt (work in progress).
-
-
-   [4]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
-        2279, January 1998.
-
-
-9.2  Informative References
-
-
-   [5]  Hornstein, K., Renard, K., Neuman, C. and G. Zorn, "Integrating
-        Single-use Authentication Mechanisms with Kerberos",
-        draft-ietf-krb-wg-kerberos-sam-02.txt (work in progress),
-        October 2003.
-
-
-   [6]  Tung, B., Neuman, C., Hur, M., Medvinsky, A. and S. Medvinsky,
-        "Public Key Cryptography for Initial Authentication in
-        Kerberos", draft-ietf-cat-kerberos-pk-init-19.txt (work in
-        progress), April 2004.
-
-
-
-Author's Address
-
-
-   Sam hartman
-   MIT
-
-
-   EMail: hartmans@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 17, 2005               [Page 17]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-Appendix A.  Todo List
-
-
-      Flesh out sections that are still outlines
-      Discuss cookies and multiple-round-trip mechanisms.
-      Talk about checksum contributions from each mechanism
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                 Expires January 17, 2005               [Page 18]
-Internet-Draft        Kerberos Preauth Framework               July 2004
-
-
-
-Intellectual Property Statement
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights. Information
-   on the IETF's procedures with respect to rights in IETF Documents can
-   be found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard. Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Hartman                 Expires January 17, 2005               [Page 19] 
\ No newline at end of file
diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-02.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-02.txt
deleted file mode 100644
index e3f81542d..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-02.txt
+++ /dev/null
@@ -1,1178 +0,0 @@
-
-
-
-Kerberos Working Group                                        S. Hartman
-Internet-Draft                                                       MIT
-Expires: April 24, 2005                                 October 24, 2004
-
-
-        A Generalized Framework for Kerberos Pre-Authentication
-                 draft-ietf-krb-wg-preauth-framework-02
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 24, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   Kerberos is a protocol for verifying the identity of principals
-   (e.g., a workstation user or a network server) on an open network.
-   The Kerberos protocol provides a mechanism called pre-authentication
-   for proving the identity  of a principal and for better protecting
-   the long-term secret of the principal.
-
-   This document describes a model for Kerberos pre-authentication
-   mechanisms.  The model describes what state in the Kerberos request a
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 1]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-   pre-authentication mechanism is likely to change.  It also describes
-   how multiple pre-authentication mechanisms used in the same request
-   will interact.
-
-   This document also provides common tools needed by multiple
-   pre-authentication mechanisms.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [1].
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  4
-     2.1   Information Managed by Model . . . . . . . . . . . . . . .  5
-     2.2   The Initial Preauth_Required Error . . . . . . . . . . . .  7
-     2.3   Client to KDC  . . . . . . . . . . . . . . . . . . . . . .  8
-     2.4   KDC to Client  . . . . . . . . . . . . . . . . . . . . . .  8
-   3.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 10
-     3.1   Client Authentication  . . . . . . . . . . . . . . . . . . 11
-     3.2   Strengthen Reply Key . . . . . . . . . . . . . . . . . . . 11
-     3.3   Replace Reply Key  . . . . . . . . . . . . . . . . . . . . 12
-     3.4   Verify Response  . . . . . . . . . . . . . . . . . . . . . 12
-   4.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 14
-   5.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15
-     5.1   Combine Keys . . . . . . . . . . . . . . . . . . . . . . . 15
-     5.2   Signing Requests/Responses . . . . . . . . . . . . . . . . 15
-     5.3   Managing State for the KDC . . . . . . . . . . . . . . . . 15
-     5.4   PA-AUTHENTICATION-SET  . . . . . . . . . . . . . . . . . . 15
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
-   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 19
-   9.2   Informative References . . . . . . . . . . . . . . . . . . . 19
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
-   A.  Todo List  . . . . . . . . . . . . . . . . . . . . . . . . . . 20
-       Intellectual Property and Copyright Statements . . . . . . . . 21
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 2]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-1.  Introduction
-
-   The core Kerberos specification treats pre-authentication data as an
-   opaque typed hole in the messages to the KDC that may influence the
-   reply key used to encrypt the KDC response.  This generality has been
-   useful: pre-authentication data is used for a variety of extensions
-   to the protocol, many outside the expectations of the initial
-   designers.  However, this generality makes designing the more common
-   types of pre-authentication mechanisms difficult.  Each mechanism
-   needs to specify how it interacts with other mechanisms.  Also,
-   problems like combining a key with the long-term secret or proving
-   the identity of the user are common to multiple mechanisms.  Where
-   there are generally well-accepted solutions to these problems, it is
-   desirable to standardize one of these solutions so mechanisms  can
-   avoid duplication of work.  In other cases, a modular approach to
-   these problems is appropriate.  The modular approach will allow new
-   and better solutions to common pre-authentication problems to be used
-   by existing mechanisms as they are developed.
-
-   This document specifies a framework for Kerberos pre-authentication
-   mechanisms.  IT defines the common set of functions
-   pre-authentication mechanisms perform as well as how these functions
-   affect the state of the request and response.  In addition several
-   common tools needed by pre-authentication mechanisms are provided.
-   Unlike [3], this framework is not complete--it does not describe all
-   the inputs and outputs for the pre-authentication mechanisms.
-   Mechanism designers should try to be consistent with this framework
-   because doing so will make their mechanisms easier to implement.
-   Kerberos implementations are likely to have plugin architectures  for
-   pre-authentication; such architectures are likely to support
-   mechanisms that follow this framework plus commonly used extensions.
-
-   This document should be read only after reading the documents
-   describing the Kerberos cryptography framework [3] and the core
-   Kerberos protocol [2].  This document freely uses terminology and
-   notation from these documents without reference or further
-   explanation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 3]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-2.  Model for Pre-Authentication
-
-   when a Kerberos client wishes to obtain a ticket using the
-   authentication server, it sends an initial AS request.  If
-   pre-authentication is being used, then the KDC will respond with a
-   KDC_ERR_PREAUTH_REQUIRED error.  Alternatively, if the client knows
-   what pre-authentication to use, it MAY optimize a round-trip and send
-   an initial request with padata included.  If the client includes the
-   wrong padata, the server MAY return KDC_ERR_PREAUTH_FAILED with no
-   indication of what padata should have been included.  For
-   interoperability reasons, clients that include optimistic
-   pre-authentication MUST retry with no padata and examine the
-   KDC_ERR_PREAUTH_REQUIRED if they receive a KDC_ERR_PREAUTH_FAILED in
-   response to their initial optimistic request.
-
-   The KDC maintains no state between two requests; subsequent requests
-   may even be processed by a different KDC.  On the other hand, the
-   client treats a series of exchanges with KDCs as a single
-   authentication session.  Each exchange accumulates state and
-   hopefully brings the client closer to a successful authentication.
-
-   These models for state management are in apparent conflict.  For many
-   of the simpler pre-authentication scenarios,  the client uses one
-   round trip to find out what mechanisms the KDC supports.  Then the
-   next request contains sufficient pre-authentication for the KDC to be
-   able to return a successful response.  For these simple scenarios,
-   the client only sends one request with pre-authentication data and so
-   the authentication session is trivial.  For more complex
-   authentication sessions, the KDC needs to provide the client with a
-   cookie to include in future requests to capture the current state of
-   the authentication session.  Handling of multiple round-trip
-   mechanisms is discussed in Section 5.3.
-
-   This framework specifies the behavior of Kerberos pre-authentication
-   mechanisms used to identify users or to modify the reply key used to
-   encrypt the KDC response.  The padata typed hole may be used to carry
-   extensions to Kerberos that have nothing to do with proving the
-   identity of the user or establishing a reply key.  These extensions
-   are outside the scope of this framework.  However mechanisms that do
-   accomplish these goals should follow this framework.
-
-   This framework specifies the minimum state that a Kerberos
-   implementation needs to maintain while handling a request in order to
-   process pre-authentication.  It also specifies how Kerberos
-   implementations process the pre-authentication data at each step of
-   the AS request process.
-
-
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 4]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-2.1  Information Managed by Model
-
-   The following information is maintained by the client and KDC as each
-   request is being processed:
-   o  The reply key used to encrypt the KDC response
-   o  How strongly the identity of the client has been authenticated
-   o  Whether the reply key has been used in this authentication session
-   o  Whether the reply key has been replaced in this authentication
-      session
-   o  Whether the contents of the KDC response can be  verified by the
-      client principal
-   o  Whether the contents of the KDC response can be  verified by the
-      client machine
-
-   Conceptually, the reply key is initially the long-term key of the
-   principal.  However, principals can have multiple long-term keys
-   because of support for multiple encryption types, salts and
-   string2key parameters.  As described in section 5.2.7.5 of the
-   Kerberos protocol [2], the KDC sends PA-ETYPe-INFO2 to notify the
-   client  what types of keys are available.  Thus in full generality,
-   the reply key in the pre-authentication model is actually a set of
-   keys.  At the beginning of a request, it is initialized to the set of
-   long-term keys advertised in the PA-ETYPE-INFO2 element on the KDC.
-   If multiple reply keys are available, the client chooses which one to
-   use.  Thus the client does not need to treat the reply key as a set.
-   At the beginning of a handling a request, the client picks a reply
-   key to use.
-
-   KDC implementations MAY choose to offer only one key in the
-   PA-ETYPE-INFO2 element.  Since the KDC already knows the client's
-   list of supported enctypes from the  request, no interoperability
-   problems are created by choosing a single possible reply key.  This
-   way, the KDC implementation avoids the complexity of treating the
-   reply key as a set.
-
-   At the beginning of handling a message on both the client and KDC,
-   the client's identity is not authenticated.  A mechanism may indicate
-   that it has successfully authenticated the client's identity.  This
-   information is useful to keep track of on the client  in order to
-   know what pre-authentication mechanisms should be used.  The KDC
-   needs to keep track of whether the client is authenticated because
-   the primary purpose of pre-authentication is to authenticate the
-   client identity before issuing a ticket.  Implementations that have
-   pre-authentication mechanisms offering significantly different
-   strengths of client authentication MAY choose to keep track of the
-   strength of the authentication used as an input into policy
-   decisions.  For example, some principals might require strong
-   pre-authentication, while less sensitive principals can use
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 5]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-   relatively weak forms of pre-authentication like encrypted timestamp.
-
-   Initially the reply key has not been used.  A pre-authentication
-   mechanism that uses the reply key either directly to encrypt or
-   checksum some data or indirectly in the generation of new keys MUST
-   indicate that the reply key is used.  This state is maintained by the
-   client and KDC to enforce the security requirement stated in Section
-   3.3 that the reply key cannot be replaced after it is used.
-
-   Initially the reply key has not been replaced.  If a mechanism
-   implements the Replace Reply Key facility discussed in Section 3.3,
-   then the state MUST be updated to indicate that the reply key has
-   been replaced.  Once the reply key has been replaced, knowledge of
-   the reply key is insufficient to authenticate the client.  The reply
-   key is marked replaced in exactly the same situations as the KDC
-   reply  is marked as not being verified to the client principal.
-   However, while mechanisms can verify the KDC request to the client,
-   once the reply key is replaced, then the reply key remains replaced
-   for the remainder of the authentication session.
-
-   Without pre-authentication, the client knows that the KDC request is
-   authentic and has not been modified because it is encrypted in the
-   long-term key of the client.  Only the KDC and client know that key.
-   So at the start of handling any message the KDC request is presumed
-   to be verified to the client principal.  Any pre-authentication
-   mechanism that sets a new reply key not based on the principal's
-   long-term secret MUST either verify the KDC response some other way
-   or indicate that the response is not verified.  If a mechanism
-   indicates that the response is not verified then the client
-   implementation MUST return an error unless a subsequent mechanism
-   verifies the response.  The KDC needs to track this state so it can
-   avoid generating a response that is not verified.
-
-   The typical Kerberos request does not provide a way for the client
-   machine to know that it is talking to the correct KDC.  Someone who
-   can inject packets into the network between the client machine and
-   the KDC and who knows the password that the user will give to the
-   client machine can generate a KDC response that will decrypt
-   properly.  So, if the client machine needs to authenticate that the
-   user is in fact the named principal, then the client machine needs to
-   do a TGS request for itself as a service.  Some pre-authentication
-   mechanisms may provide  a way for the client to authenticate the KDC.
-   Examples of this include signing the response with a well-known
-   public key or providing a ticket for the client machine as a service
-   in addition to the requested ticket.
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 6]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-2.2  The Initial Preauth_Required Error
-
-   Typically a client starts an authentication session by sending  an
-   initial request with no pre-authentication.  If the KDC requires
-   pre-authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED
-   message.  This message MAY also be returned for pre-authentication
-   configurations that use multi-round-trip mechanisms; see Section 2.4
-   for details of that case.  This
-
-   The KDC needs to choose which mechanisms to offer the client.  The
-   client needs to be able to choose what mechanisms to use from the
-   first message.  For example consider the KDC that will accept
-   mechanism A followed by mechanism B or alternatively the single
-   mechanism C.  A client that supports A and C needs to know that it
-   should not bother trying A.
-
-   Mechanisms can either be sufficient on their own or can be part of an
-   authentication set--a group of mechanisms that all need to
-   successfully complete in order to authenticate a client.  Some
-   mechanisms may only be useful in authentication sets; others may be
-   useful alone or in authentication sets.  For the second group of
-   mechanisms, KDC policy dictates whether the mechanism will be part of
-   an authentication set or offered alone.  For each mechanism that is
-   offered alone, the KDC includes the pre-authentication type ID of the
-   mechanism in the padata sequence returned in the
-   KDC_ERR_PREAUTH_REQUIRED error.  The KDC MAY include any initial
-   data for the mechanisms.
-
-   The KDC includes a a PA-AUTHENTICATION-SET padata element for each
-   authentication set; this element is defined in Section 5.4.  This
-   element includes the pa-type and pa-value for the first mechanism in
-   the authentication set.  It also includes the  pa-type for each of
-   the other mechanisms.  Associated with the second and following
-   pa-type is a pa-hint, which is an octet-string specified by the
-   pre-authentication mechanism.  This hint may provide information for
-   the client which helps it determine whether the mechanism can be
-   used.  For example a public-key mechanism might include the
-   certificate authorities it trusts in the hint info.  Most mechanisms
-   today do not  specify hint info; if a mechanism does not specify hint
-   info the KDC MUST not send a hint for that mechanism.  To allow
-   future revisions of mechanism specifications to add hint info,
-   clients MUST ignore hint info received for mechanisms that the client
-   believes do not support hint info.
-
-   The KDC SHOULD NOT send data that is encrypted in the long-term
-   password-based key of the principal.  Doing so has the same security
-   exposures as the Kerberos protocol without pre-authentication.  There
-   are few situations where pre-authentication is desirable and where
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 7]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-   the KDC needs to expose ciphertext encrypted in a weak key before the
-   client has proven knowledge of that key.
-
-2.3  Client to KDC
-
-   This description assumes a client has already received a
-   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
-   optimistic pre-authentication then the client needs to optimisticly
-   choose the information it would normally receive from that error
-   response.
-
-   The client starts by initializing the pre-authentication state as
-   specified.  It then processes the padata in the
-   KDC_ERR_PREAUTH_REQUIRED.
-
-   When processing the response to the first KDC_ERR_PREAUTH_REQUIRED,
-   the client MAY ignore any padata it chooses unless doing so violates
-   a specification to which the client conforms.  Clients MUST NOT
-   ignore the padata defined in Section 5.3.  Clients SHOULD  process
-   padata unrelated to this framework or other means of authenticating
-   the user.  Clients SHOULD choose one authentication set or mechanism
-   that could lead to authenticating the user and ignore the rest.
-   Since the set of mechanisms offered by the KDC is ordered, clients
-   typically choose the first mechanism that the client can usefully
-   perform.  If a client chooses to ignore a padata it MUST NOT process
-   the padata, allow the padata to affect the pre-authentication state,
-   nor respond to the padata.
-
-   For each padata the client chooses to process, the client processes
-   the padata and modifies the pre-authentication state as required by
-   that mechanism.  Padata are processed in the order received from the
-   KDC.
-
-   After processing the padata in the KDC error, the client generates a
-   new request.  It processes the pre-authentication mechanisms in the
-   order in which they will appear in the next request, updating the
-   state as appropriate.  When the request is complete it is sent.
-
-2.4  KDC to Client
-
-   When a KDC receives an AS request from a client, it needs to
-   determine whether it will respond with an error or  a AS reply.
-   There are many causes for an error to be generated that have nothing
-   to do with pre-authentication; they are discussed in the Kerberos
-   specification.
-
-   From the standpoint of evaluating the pre-authentication, the KDC
-   first starts by initializing the pre-authentication state.  IT then
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 8]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-   processes the padata in the request.  AS mentioned in Section 2.2,
-   the KDC MAY ignore padata that is inappropriate for the configuration
-   and MUST ignore padata of an unknown type.
-
-   At this point the KDC decides whether it will issue a
-   pre-authentication required error or a reply.  Typically a KDC will
-   issue a reply if the client's identity has been authenticated to a
-   sufficient degree.
-
-   In the case of a PREAUTH_REQUIRED error, the KDC first starts by
-   initializing the pre-authentication state.  Then it processes any
-   padata in the client's request in the order provided by the client.
-   Mechanisms that are not understood by the KDC are ignored.
-   Mechanisms that are inappropriate for the client principal or request
-   SHOULD also be ignored.  Next, it generates padata for the error
-   response, modifying the pre-authentication state appropriately as
-   each mechanism is processed.  The KDC chooses the order in which it
-   will generated padata (and thus the order of padata in the response),
-   but it needs to modify the pre-authentication state consistently with
-   the choice of order.  For example, if some mechanism establishes an
-   authenticated client identity, then the mechanisms subsequent in the
-   generated response receive this state as input.  After the padata is
-   generated, the error response is sent.  Typically the second and
-   following PREAUTH_REQUIRED errors in an authentication session will
-   include KDC state as discussed in Section 5.3.
-
-   To generate a final reply, the KDC generates the padata modifying the
-   pre-authentication state as necessary.  Then it generates the final
-   response, encrypting it in the current pre-authentication reply key.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                 [Page 9]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-3.  Pre-Authentication Facilities
-
-   Pre-Authentication mechanisms can be thought of as providing various
-   conceptual facilities.  This serves two useful purposes.  First,
-   mechanism authors can choose only to solve one specific small
-   problem.  It is often useful for a mechanism designed to offer key
-   management not to directly provide client authentication but instead
-   to allow one or more other mechanisms to handle this need.  Secondly,
-   thinking about the  abstract services that a 2mechanism provides
-   yields a minimum set of security requirements that all mechanisms
-   providing that facility must meet.  These security requirements are
-   not complete; mechanisms will have additional security requirements
-   based on the specific protocol they employ.
-
-   A mechanism is not constrained to only offering one of these
-   facilities.  While such mechanisms can be designed and are sometimes
-   useful, many pre-authentication mechanisms implement several
-   facilities.  By combining multiple facilities in a single mechanism,
-   it is often easier to construct a secure, simple solution than  by
-   solving the problem in full generality.  Even when mechanisms provide
-   multiple facilities, they need to meet the security requirements for
-   all the facilities they provide.
-
-   According to Kerberos extensibility rules (section 1.4.2 of the
-   Kerberos specification [2]), an extension MUST NOT change the
-   semantics of a message unless a recipient is known to understand that
-   extension.  Because a client does not know that the KDC supports a
-   particular pre-authentication mechanism when it sends an initial
-   request, a preauth mechanism MUST NOT change the semantics of the
-   request in a way that will break a KDC that does not understand that
-   mechanism.  Similarly, KDCs MUST not send messages to clients that
-   affect the core semantics unless the clients have indicated support
-   for the message.
-
-   The only state in this model that would break the interpretation of a
-   message is changing the expected reply key.  If one mechanism changed
-   the reply key and a later mechanism used that reply key, then a KDC
-   that interpreted the second mechanism but not the first would fail to
-   interpret the request correctly.  In order to avoid this problem,
-   extensions that change core semantics are typically divided into two
-   parts.  The first part proposes a change to the core semantic--for
-   example proposes a new reply key.  The second part acknowledges that
-   the extension is understood and that the change takes effect.
-   Section 3.2 discusses how to design mechanisms that modify the reply
-   key to be split into a proposal and acceptance without requiring
-   additional round trips to use the new reply key in subsequent
-   pre-authentication.  Other changes in the state described in Section
-   2.1 can safely be ignored by a KDC that does not understand a
-
-
-
-Hartman                  Expires April 24, 2005                [Page 10]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-   mechanism.  Mechanisms that modify the behavior of the request
-   outside the scope of this framework need to carefully consider the
-   Kerberos extensibility rules to avoid similar problems.
-
-3.1  Client Authentication
-
-   The client authentication facility proves the identity of a user to
-   the KDC before a ticket is issued.  Examples of mechanisms
-   implementing this facility include the encrypted timestamp facility
-   defined in Section 5.2.7.2 of the Kerberos specification [2] and the
-   single-use mechanism defined in [5].  Mechanisms that provide this
-   facility are expected to mark the client  as authenticated.
-
-   Mechanisms implementing this facility SHOULD require the client to
-   prove knowledge  of the reply key before transmitting a successful
-   KDC reply.  Otherwise, an attacker can intercept the
-   pre-authentication exchange and get a reply to attack.  One way of
-   proving the client knows the reply key is to implement the Replace
-   Reply Key facility along with this facility.  The Pkinit mechanism
-   [6] implements Client Authentication along side Replace Reply Key.
-
-   If the reply key has been replaced, then mechanisms such as encrypted
-   timestamp that rely on knowledge of the reply key to authenticate the
-   client MUST NOT be used.
-
-3.2  Strengthen Reply Key
-
-   Particularly, when dealing with keys based on passwords, it is
-   desirable to increase the strength of the key by adding additional
-   secrets to it.  Examples of sources of additional secrets include the
-   results of a Diffie-Hellman key exchange or key bits from the output
-   of a smart card [5].  Typically these additional secrets are
-   converted into a Kerberos protocol key.  Then they are combined with
-   the existing reply key as discussed in Section 5.1.
-
-   If a mechanism implementing this facility wishes to modify the reply
-   key before knowing that the other party in the exchange supports the
-   mechanism, it proposes modifying the reply key.  The other party then
-   includes a message indicating that the proposal is accepted if it is
-   understood and meets policy.  In many cases it is desirable to use
-   the new reply key for client authentication and for other facilities.
-   Waiting for the other party to accept the proposal and actually
-   modify the reply key state would add an additional round trip to the
-   exchange.  Instead, mechanism designers  are encouraged to include a
-   typed hole for additional padata in the message that proposes the
-   reply key change.  The padata included in the typed hole are
-   generated assuming the new reply key.  If the other party accepts the
-   proposal, then these padata are interpreted as if they were included
-
-
-
-Hartman                  Expires April 24, 2005                [Page 11]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-   immediately following the proposal.  The party generating the
-   proposal can determine whether the padata were processed based on
-   whether the proposal for the reply key is accepted.
-
-   The specific formats of the proposal message, including where padata
-   are  are included is a matter for the mechanism specification.
-   Similarly, the format of the message accepting the proposal is
-   mechanism-specific.
-
-   Mechanisms implementing this facility and including a typed hole for
-   additional padata MUST checksum that padata using a keyed checksum or
-   encrypt the padata.  Typically the reply key is used to protect the
-   padata.  XXX If you are only minimally increasing the strength of the
-   reply key, this may give the attacker access to something too close
-   to the original reply key.  However, binding the padata to the new
-   reply key  seems potentially important from a security standpoint.
-   There may also be objections to this from a double encryption
-   standpoint because we also recommend client authentication facilities
-   be tied to the reply key.
-
-3.3  Replace Reply Key
-
-   The Replace Reply Key facility replaces the key in which a successful
-   AS reply will be encrypted.  This facility can only be used in cases
-   where knowledge of the reply key is not used to authenticate the
-   client.  The new reply key MUST be communicated to the client and KDC
-   in a secure manner.  Mechanisms implementing this facility MUST mark
-   the reply key as replaced in the pre-authentication state.
-   Mechanisms implementing this facility MUST either provide a mechanism
-   to verify the KDC reply to the client or mark the reply as unverified
-   in the pre-authentication state.  Mechanisms implementing this
-   facility SHOULD NOT be used if a previous mechanism has used the
-   reply key.
-
-   As with the Strengthen Reply Key facility, Kerberos extensibility
-   rules require that the reply key not be changed unless both sides of
-   the exchange understand the extension.  In the case of this facility
-   it will likely be more common for both sides to know that the
-   facility is available by the time that the new key is available to be
-   used.  However, mechanism designers can use a container for padata in
-   a proposal message as discussed in Section 3.2 if appropriate.
-
-3.4  Verify Response
-
-   This facility verifies that the response comes from the expected KDC.
-   In traditional Kerberos, the KDC and the client share a key, so if
-   the ticket can be decrypted then the client knows that a trusted KDC
-   responded.  Note that the client machine cannot trust the client
-
-
-
-Hartman                  Expires April 24, 2005                [Page 12]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-   unless the machine retrieves a service ticket for itself.  However,
-   if the reply key is replaced, some mechanism is required to verify
-   the KDC.  Mechanisms providing this facility provide such a
-   mechanism.  They mark the pre-authentication state as having been
-   verified; they may also mark it as verified to the client host.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                [Page 13]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-4.  Requirements for Pre-Authentication Mechanisms
-
-   This section lists requirements for specifications of
-   pre-authentication mechanisms.
-
-   For each message in the pre-authentication mechanism, the
-   specification describes  the pa-type value to be used and the
-   contents of the message.  The processing  of the message my the
-   sender and recipient is also specified.  This specification needs to
-   include all modifications to the pre-authentication state.
-
-   Generally mechanisms have a message that can be sent as part of the
-   first KDC_ERR_PREAUTH_REQUIRED or as part of an authentication set.
-   If the client will need information such as available certificate
-   authorities in order to determine if it can use the mechanism, then
-   this information should be in that first message.  IN addition, such
-   mechanisms should also define a pa-hint to be included in
-   authentication sets when the mechanism is not the first mechanism in
-   the authentication set.  Often, the same information included in the
-   first pa-value is appropriate to include in the pa-hint.
-
-   In order to ease in security analysis the mechanism specification
-   should describe what facilities from this document are offered by the
-   mechanism.  For each facility, the security considerations section of
-   the mechanism specification should show that the security
-   requirements of that facility are met.
-
-   Significant problems have resulted in the specification of Kerberos
-   protocols because much of the KDC exchange is not protected against
-   authentication.  The security considerations section should discuss
-   unauthenticated plaintext attacks.  It should either show that
-   plaintext is protected or discuss what harm an attacker could do by
-   modifying the plaintext.  It is generally acceptable for an attacker
-   to be able to cause the protocol negotiation to fail by modifying
-   plaintext.  More significant attacks should be evaluated carefully.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                [Page 14]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-5.  Tools for Use in Pre-Authentication Mechanisms
-
-5.1  Combine Keys
-
-5.2  Signing Requests/Responses
-
-5.3  Managing State for the KDC
-
-5.4  PA-AUTHENTICATION-SET
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                [Page 15]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-6.  IANA Considerations
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                [Page 16]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-7.  Security Considerations
-
-      Very little of the AS request is authenticated.  Same for padata
-      in the reply or error.  Discuss implications
-      Table of security requirements stated elsewhere in the document
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                [Page 17]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-8.  Acknowledgements
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                [Page 18]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-9.  References
-
-9.1  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", RFC 2119, BCP 14, March 1997.
-
-   [2]  Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos
-        Network Authentication Service (V5)",
-        draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
-        progress), June 2004.
-
-   [3]  Raeburn, K., "Encryption and Checksum Specifications for
-        Kerberos 5", draft-ietf-krb-wg-crypto-03.txt (work in progress).
-
-   [4]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
-        2279, January 1998.
-
-9.2  Informative References
-
-   [5]  Hornstein, K., Renard, K., Neuman, C. and G. Zorn, "Integrating
-        Single-use Authentication Mechanisms with Kerberos",
-        draft-ietf-krb-wg-kerberos-sam-02.txt (work in progress),
-        October 2003.
-
-   [6]  Tung, B., Neuman, C., Hur, M., Medvinsky, A. and S. Medvinsky,
-        "Public Key Cryptography for Initial Authentication in
-        Kerberos", draft-ietf-cat-kerberos-pk-init-19.txt (work in
-        progress), April 2004.
-
-
-Author's Address
-
-   Sam hartman
-   MIT
-
-   EMail: hartmans@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                [Page 19]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-Appendix A.  Todo List
-
-      Flesh out sections that are still outlines
-      Discuss cookies and multiple-round-trip mechanisms.
-      Talk about checksum contributions from each mechanism
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman                  Expires April 24, 2005                [Page 20]
-
-Internet-Draft        Kerberos Preauth Framework            October 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Hartman                  Expires April 24, 2005                [Page 21]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-04.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-04.txt
deleted file mode 100644
index 2354a5926..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-04.txt
+++ /dev/null
@@ -1,1830 +0,0 @@
-
-
-Kerberos Working Group                                            L. Zhu
-Internet-Draft                                     Microsoft Corporation
-Updates: 4120 (if approved)                                   S. Hartman
-Intended status: Standards Track                                     MIT
-Expires: April 28, 2007                                 October 25, 2006
-
-
-        A Generalized Framework for Kerberos Pre-Authentication
-                 draft-ietf-krb-wg-preauth-framework-04
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 28, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   Kerberos is a protocol for verifying the identity of principals
-   (e.g., a workstation user or a network server) on an open network.
-   The Kerberos protocol provides a mechanism called pre-authentication
-   for proving the identity of a principal and for better protecting the
-   long-term secret of the principal.
-
-   This document describes a model for Kerberos pre-authentication
-
-
-
-Zhu & Hartman            Expires April 28, 2007                 [Page 1]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   mechanisms.  The model describes what state in the Kerberos request a
-   pre-authentication mechanism is likely to change.  It also describes
-   how multiple pre-authentication mechanisms used in the same request
-   will interact.
-
-   This document also provides common tools needed by multiple pre-
-   authentication mechanisms.  One of such tools is a secure channel
-   between the client and the KDC with a reply key delivery mechanism,
-   this secure channel can be used to protect the authentication
-   exchange thus eliminate offline dictionary attacks.  With these
-   tools, it is straightforward to chain multiple authentication factors
-   or add a plugin to, for example, utilize a different key management
-   system, or support a new key agreement algorithm.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
-   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  5
-     3.1.  Information Managed by the Pre-authentication Model  . . .  6
-     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  8
-     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . .  9
-     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 10
-   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 11
-     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 12
-     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 12
-     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 13
-     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 14
-   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 14
-   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15
-     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 15
-     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 17
-     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 17
-     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 18
-     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 19
-       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 20
-       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 21
-       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 24
-     6.6.  Authentication Strength Indication . . . . . . . . . . . . 27
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 28
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 28
-   Appendix A.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 28
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
-
-
-
-Zhu & Hartman            Expires April 28, 2007                 [Page 2]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   Intellectual Property and Copyright Statements . . . . . . . . . . 32
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Hartman            Expires April 28, 2007                 [Page 3]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-1.  Introduction
-
-   The core Kerberos specification [RFC4120] treats pre-authentication
-   data as an opaque typed hole in the messages to the KDC that may
-   influence the reply key used to encrypt the KDC reply.  This
-   generality has been useful: pre-authentication data is used for a
-   variety of extensions to the protocol, many outside the expectations
-   of the initial designers.  However, this generality makes designing
-   more common types of pre-authentication mechanisms difficult.  Each
-   mechanism needs to specify how it interacts with other mechanisms.
-   Also, problems like combining a key with the long-term secret or
-   proving the identity of the user are common to multiple mechanisms.
-   Where there are generally well-accepted solutions to these problems,
-   it is desirable to standardize one of these solutions so mechanisms
-   can avoid duplication of work.  In other cases, a modular approach to
-   these problems is appropriated.  The modular approach will allow new
-   and better solutions to common pre-authentication problems to be used
-   by existing mechanisms as they are developed.
-
-   This document specifies a framework for Kerberos pre-authentication
-   mechanisms.  It defines the common set of functions pre-
-   authentication mechanisms perform as well as how these functions
-   affect the state of the request and reply.  In addition several
-   common tools needed by pre-authentication mechanisms are provided.
-   Unlike [RFC3961], this framework is not complete--it does not
-   describe all the inputs and outputs for the pre-authentication
-   mechanisms.  Pre-Authentication mechanism designers should try to be
-   consistent with this framework because doing so will make their
-   mechanisms easier to implement.  Kerberos implementations are likely
-   to have plugin architectures for pre-authentication; such
-   architectures are likely to support mechanisms that follow this
-   framework plus commonly used extensions.
-
-   One of these common tools is the flexible authentication secure
-   tunneling (FAST) padata.  FAST provides a protected channel between
-   the client and the KDC, and it also delivers a reply key within the
-   protected channel.  Based on FAST, pre-authentication mechanisms can
-   extend Kerberos with ease, to support, for example, password
-   authenticated key exchange (PAKE) protocols with zero knowledge
-   password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-authentication
-   mechanism can be encapsulated in the padata field Section 6.5 of
-   FAST.  A pre-authentication type thus carried within FAST is called a
-   FAST factor.  A FAST factor MUST NOT be used outside of FAST unless
-   its specification explicitly allows so.  Note that FAST without a
-   FAST factor for authentication does NOT by itself authenticate the
-   client or the KDC.
-
-   New pre-authentication mechanisms SHOULD design FAST factors, instead
-
-
-
-Zhu & Hartman            Expires April 28, 2007                 [Page 4]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   of full-blown pre-authentication mechanisms.
-
-   A conversation consists of all messages that are necessary to
-   complete the mutual authentication between the client and the KDC.  A
-   conversation is the smallest logic unit for messages exchanged
-   between the client and the KDC.  The KDC need to manage mulitple
-   authentication sets frequently need to keep track of KDC states
-   during a convesation, standard solutions are provided for these
-   common problems.
-
-   This document should be read only after reading the documents
-   describing the Kerberos cryptography framework [RFC3961] and the core
-   Kerberos protocol [RFC4120].  This document freely uses terminology
-   and notation from these documents without reference or further
-   explanation.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   The word padata is used as the shorthand of pre-authentication data.
-   A conversation is used to refer to all authentication messages
-   exchanged between the client and the KDC.
-
-
-3.  Model for Pre-Authentication
-
-   When a Kerberos client wishes to obtain a ticket using the
-   authentication server, it sends an initial Authentication Service
-   (AS) request.  If pre-authentication is required but not being used,
-   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
-   Alternatively, if the client knows what pre-authentication to use, it
-   MAY optimize away a round-trip and send an initial request with
-   padata included in the initial request.  If the client includes the
-   wrong padata, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
-   indication of what padata should have been included.  In that case,
-   the client MUST retry with no padata and examine the error data of
-   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
-   authentication information in the accompanying error data of
-   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data as
-   that of the KDC_ERR_PREAUTH_REQUIRED error, and then retry.
-
-   The conventional KDC maintains no state between two requests;
-   subsequent requests may even be processed by a different KDC.  On the
-   other hand, the client treats a series of exchanges with KDCs as a
-
-
-
-Zhu & Hartman            Expires April 28, 2007                 [Page 5]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   single authentication session.  Each exchange accumulates state and
-   hopefully brings the client closer to a successful authentication.
-
-   These models for state management are in apparent conflict.  For many
-   of the simpler pre-authentication scenarios, the client uses one
-   round trip to find out what mechanisms the KDC supports.  Then the
-   next request contains sufficient pre-authentication for the KDC to be
-   able to return a successful reply.  For these simple scenarios, the
-   client only sends one request with pre-authentication data and so the
-   authentication session is trivial.  For more complex authentication
-   sessions, the KDC needs to provide the client with a cookie to
-   include in future requests to capture the current state of the
-   authentication session.  Handling of multiple round-trip mechanisms
-   is discussed in Section 6.3.
-
-   This framework specifies the behavior of Kerberos pre-authentication
-   mechanisms used to identify users or to modify the reply key used to
-   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
-   extensions to Kerberos that have nothing to do with proving the
-   identity of the user or establishing a reply key.  Such extensions
-   are outside the scope of this framework.  However mechanisms that do
-   accomplish these goals should follow this framework.
-
-   This framework specifies the minimum state that a Kerberos
-   implementation needs to maintain while handling a request in order to
-   process pre-authentication.  It also specifies how Kerberos
-   implementations process the padata at each step of the AS request
-   process.
-
-3.1.  Information Managed by the Pre-authentication Model
-
-   The following information is maintained by the client and KDC as each
-   request is being processed:
-
-   o  The reply key used to encrypt the KDC reply
-
-   o  How strongly the identity of the client has been authenticated
-
-   o  Whether the reply key has been used in this authentication session
-
-   o  Whether the reply key has been replaced in this authentication
-      session
-
-   o  Whether the contents of the KDC reply can be verified by the
-      client principal
-
-
-
-
-
-
-Zhu & Hartman            Expires April 28, 2007                 [Page 6]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   o  Whether the contents of the KDC reply can be verified by the
-      client machine
-
-   Conceptually, the reply key is initially the long-term key of the
-   principal.  However, principals can have multiple long-term keys
-   because of support for multiple encryption types, salts and
-   string2key parameters.  As described in section 5.2.7.5 of the
-   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
-   the client what types of keys are available.  Thus in full
-   generality, the reply key in the pre-authentication model is actually
-   a set of keys.  At the beginning of a request, it is initialized to
-   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
-   the KDC.  If multiple reply keys are available, the client chooses
-   which one to use.  Thus the client does not need to treat the reply
-   key as a set.  At the beginning of a handling a request, the client
-   picks a reply key to use.
-
-   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
-   INFO2 element.  Since the KDC already knows the client's list of
-   supported enctypes from the request, no interoperability problems are
-   created by choosing a single possible reply key.  This way, the KDC
-   implementation avoids the complexity of treating the reply key as a
-   set.
-
-   When the padata in the request is verified by the KDC, then the
-   client is known to have that key, therefore the KDC SHOULD pick the
-   same key as the reply key.
-
-   At the beginning of handling a message on both the client and the
-   KDC, the client's identity is not authenticated.  A mechanism may
-   indicate that it has successfully authenticated the client's
-   identity.  This information is useful to keep track of on the client
-   in order to know what pre-authentication mechanisms should be used.
-   The KDC needs to keep track of whether the client is authenticated
-   because the primary purpose of pre-authentication is to authenticate
-   the client identity before issuing a ticket.  The handling of
-   authentication strength using various authentication mechanisms is
-   discussed in Section 6.6.
-
-   Initially the reply key has not been used.  A pre-authentication
-   mechanism that uses the reply key either directly to encrypt or
-   checksum some data or indirectly in the generation of new keys MUST
-   indicate that the reply key is used.  This state is maintained by the
-   client and the KDC to enforce the security requirement stated in
-   Section 4.3 that the reply key cannot be used after it is replaced.
-
-   Initially the reply key has not been replaced.  If a mechanism
-   implements the Replace Reply Key facility discussed in Section 4.3,
-
-
-
-Zhu & Hartman            Expires April 28, 2007                 [Page 7]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   then the state MUST be updated to indicate that the reply key has
-   been replaced.  Once the reply key has been replaced, knowledge of
-   the reply key is insufficient to authenticate the client.  The reply
-   key is marked replaced in exactly the same situations as the KDC
-   reply is marked as not being verified to the client principal.
-   However, while mechanisms can verify the KDC reply to the client,
-   once the reply key is replaced, then the reply key remains replaced
-   for the remainder of the authentication session.
-
-   Without pre-authentication, the client knows that the KDC reply is
-   authentic and has not been modified because it is encrypted in a
-   long-term key of the client.  Only the KDC and the client know that
-   key.  So at the start of handling any message the KDC reply is
-   presumed to be verified using the client principal's long-term key.
-   Any pre-authentication mechanism that sets a new reply key not based
-   on the principal's long-term secret MUST either verify the KDC reply
-   some other way or indicate that the reply is not verified.  If a
-   mechanism indicates that the reply is not verified then the client
-   implementation MUST return an error unless a subsequent mechanism
-   verifies the reply.  The KDC needs to track this state so it can
-   avoid generating a reply that is not verified.
-
-   The typical Kerberos request does not provide a way for the client
-   machine to know that it is talking to the correct KDC.  Someone who
-   can inject packets into the network between the client machine and
-   the KDC and who knows the password that the user will give to the
-   client machine can generate a KDC reply that will decrypt properly.
-   So, if the client machine needs to authenticate that the user is in
-   fact the named principal, then the client machine needs to do a TGS
-   request for itself as a service.  Some pre-authentication mechanisms
-   may provide a way for the client to authenticate the KDC.  Examples
-   of this include signing the reply with a well-known public key or
-   providing a ticket for the client machine as a service in addition to
-   the requested ticket.
-
-3.2.  Initial Pre-authentication Required Error
-
-   Typically a client starts an authentication session by sending an
-   initial request with no pre-authentication.  If the KDC requires pre-
-   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
-   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
-   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED for
-   pre-authentication configurations that use multi-round-trip
-   mechanisms; see Section 3.4 for details of that case.
-
-   The KDC needs to choose which mechanisms to offer the client.  The
-   client needs to be able to choose what mechanisms to use from the
-   first message.  For example consider the KDC that will accept
-
-
-
-Zhu & Hartman            Expires April 28, 2007                 [Page 8]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   mechanism A followed by mechanism B or alternatively the single
-   mechanism C. A client that supports A and C needs to know that it
-   should not bother trying A.
-
-   Mechanisms can either be sufficient on their own or can be part of an
-   authentication set--a group of mechanisms that all need to
-   successfully complete in order to authenticate a client.  Some
-   mechanisms may only be useful in authentication sets; others may be
-   useful alone or in authentication sets.  For the second group of
-   mechanisms, KDC policy dictates whether the mechanism will be part of
-   an authentication set or offered alone.  For each mechanism that is
-   offered alone, the KDC includes the pre-authentication type ID of the
-   mechanism in the padata sequence returned in the
-   KDC_ERR_PREAUTH_REQUIRED error.
-
-   The KDC SHOULD NOT send data that is encrypted in the long-term
-   password-based key of the principal.  Doing so has the same security
-   exposures as the Kerberos protocol without pre-authentication.  There
-   are few situations where pre-authentication is desirable and where
-   the KDC needs to expose cipher text encrypted in a weak key before
-   the client has proven knowledge of that key.
-
-3.3.  Client to KDC
-
-   This description assumes a client has already received a
-   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
-   optimistic pre-authentication then the client needs to optimistically
-   choose the information it would normally receive from that error
-   response.
-
-   The client starts by initializing the pre-authentication state as
-   specified.  It then processes the padata in the
-   KDC_ERR_PREAUTH_REQUIRED.
-
-   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
-   client MAY ignore any padata it chooses unless doing so violates a
-   specification to which the client conforms.  Clients MUST NOT ignore
-   the padata defined in Section 6.3.  Clients SHOULD process padata
-   unrelated to this framework or other means of authenticating the
-   user.  Clients SHOULD choose one authentication set or mechanism that
-   could lead to authenticating the user and ignore the rest.  Since the
-   list of mechanisms offered by the KDC is in the decreasing preference
-   order, clients typically choose the first mechanism that the client
-   can usefully perform.  If a client chooses to ignore a padata it MUST
-   NOT process the padata, allow the padata to affect the pre-
-   authentication state, nor respond to the padata.
-
-   For each padata the client chooses to process, the client processes
-
-
-
-Zhu & Hartman            Expires April 28, 2007                 [Page 9]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   the padata and modifies the pre-authentication state as required by
-   that mechanism.  Padata are processed in the order received from the
-   KDC.
-
-   After processing the padata in the KDC error, the client generates a
-   new request.  It processes the pre-authentication mechanisms in the
-   order in which they will appear in the next request, updating the
-   state as appropriate.  The request is sent when it is complete.
-
-3.4.  KDC to Client
-
-   When a KDC receives an AS request from a client, it needs to
-   determine whether it will respond with an error or a AS reply.  There
-   are many causes for an error to be generated that have nothing to do
-   with pre-authentication; they are discussed in the core Kerberos
-   specification.
-
-   From the standpoint of evaluating the pre-authentication, the KDC
-   first starts by initializing the pre-authentication state.  It then
-   processes the padata in the request.  As mentioned in Section 3.3,
-   the KDC MAY ignore padata that is inappropriate for the configuration
-   and MUST ignore padata of an unknown type.
-
-   At this point the KDC decides whether it will issue a pre-
-   authentication required error or a reply.  Typically a KDC will issue
-   a reply if the client's identity has been authenticated to a
-   sufficient degree.
-
-   In the case of a KDC_ERR_PREAUTH_REQUIRED error, the KDC first starts
-   by initializing the pre-authentication state.  Then it processes any
-   padata in the client's request in the order provided by the client.
-   Mechanisms that are not understood by the KDC are ignored.
-   Mechanisms that are inappropriate for the client principal or the
-   request SHOULD also be ignored.  Next, it generates padata for the
-   error response, modifying the pre-authentication state appropriately
-   as each mechanism is processed.  The KDC chooses the order in which
-   it will generate padata (and thus the order of padata in the
-   response), but it needs to modify the pre-authentication state
-   consistently with the choice of order.  For example, if some
-   mechanism establishes an authenticated client identity, then the
-   subsequent mechanisms in the generated response receive this state as
-   input.  After the padata is generated, the error response is sent.
-   Typically the errors with the code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
-   in a converstation will include KDC state as discussed in
-   Section 6.3.
-
-   To generate a final reply, the KDC generates the padata modifying the
-   pre-authentication state as necessary.  Then it generates the final
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 10]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   response, encrypting it in the current pre-authentication reply key.
-
-
-4.  Pre-Authentication Facilities
-
-   Pre-Authentication mechanisms can be thought of as providing various
-   conceptual facilities.  This serves two useful purposes.  First,
-   mechanism authors can choose only to solve one specific small
-   problem.  It is often useful for a mechanism designed to offer key
-   management not to directly provide client authentication but instead
-   to allow one or more other mechanisms to handle this need.  Secondly,
-   thinking about the abstract services that a mechanism provides yields
-   a minimum set of security requirements that all mechanisms providing
-   that facility must meet.  These security requirements are not
-   complete; mechanisms will have additional security requirements based
-   on the specific protocol they employ.
-
-   A mechanism is not constrained to only offering one of these
-   facilities.  While such mechanisms can be designed and are sometimes
-   useful, many pre-authentication mechanisms implement several
-   facilities.  By combining multiple facilities in a single mechanism,
-   it is often easier to construct a secure, simple solution than by
-   solving the problem in full generality.  Even when mechanisms provide
-   multiple facilities, they need to meet the security requirements for
-   all the facilities they provide.
-
-   According to Kerberos extensibility rules (Section 1.5 of the
-   Kerberos specification [RFC4120]), an extension MUST NOT change the
-   semantics of a message unless a recipient is known to understand that
-   extension.  Because a client does not know that the KDC supports a
-   particular pre-authentication mechanism when it sends an initial
-   request, a pre-authentication mechanism MUST NOT change the semantics
-   of the request in a way that will break a KDC that does not
-   understand that mechanism.  Similarly, KDCs MUST not send messages to
-   clients that affect the core semantics unless the client has
-   indicated support for the message.
-
-   The only state in this model that would break the interpretation of a
-   message is changing the expected reply key.  If one mechanism changed
-   the reply key and a later mechanism used that reply key, then a KDC
-   that interpreted the second mechanism but not the first would fail to
-   interpret the request correctly.  In order to avoid this problem,
-   extensions that change core semantics are typically divided into two
-   parts.  The first part proposes a change to the core semantic--for
-   example proposes a new reply key.  The second part acknowledges that
-   the extension is understood and that the change takes effect.
-   Section 4.2 discusses how to design mechanisms that modify the reply
-   key to be split into a proposal and acceptance without requiring
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 11]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   additional round trips to use the new reply key in subsequent pre-
-   authentication.  Other changes in the state described in Section 3.1
-   can safely be ignored by a KDC that does not understand a mechanism.
-   Mechanisms that modify the behavior of the request outside the scope
-   of this framework need to carefully consider the Kerberos
-   extensibility rules to avoid similar problems.
-
-4.1.  Client-authentication Facility
-
-   The client authentication facility proves the identity of a user to
-   the KDC before a ticket is issued.  Examples of mechanisms
-   implementing this facility include the encrypted timestamp facility
-   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
-   Mechanisms that provide this facility are expected to mark the client
-   as authenticated.
-
-   Mechanisms implementing this facility SHOULD require the client to
-   prove knowledge of the reply key before transmitting a successful KDC
-   reply.  Otherwise, an attacker can intercept the pre-authentication
-   exchange and get a reply to attack.  One way of proving the client
-   knows the reply key is to implement the Replace Reply Key facility
-   along with this facility.  The PKINIT mechanism [RFC4556] implements
-   Client Authentication alongside Replace Reply Key.
-
-   If the reply key has been replaced, then mechanisms such as
-   encrypted-timestamp that rely on knowledge of the reply key to
-   authenticate the client MUST NOT be used.
-
-4.2.  Strengthening-reply-key Facility
-
-   Particularly, when dealing with keys based on passwords, it is
-   desirable to increase the strength of the key by adding additional
-   secrets to it.  Examples of sources of additional secrets include the
-   results of a Diffie-Hellman key exchange or key bits from the output
-   of a smart card [RFC4556].  Typically these additional secrets can be
-   first combined with the existing reply key and then converted to a
-   protocol key using tools defined in Section 6.1.
-
-   If a mechanism implementing this facility wishes to modify the reply
-   key before knowing that the other party in the exchange supports the
-   mechanism, it proposes modifying the reply key.  The other party then
-   includes a message indicating that the proposal is accepted if it is
-   understood and meets policy.  In many cases it is desirable to use
-   the new reply key for client authentication and for other facilities.
-   Waiting for the other party to accept the proposal and actually
-   modify the reply key state would add an additional round trip to the
-   exchange.  Instead, mechanism designers are encouraged to include a
-   typed hole for additional padata in the message that proposes the
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 12]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   reply key change.  The padata included in the typed hole are
-   generated assuming the new reply key.  If the other party accepts the
-   proposal, then these padata are interpreted as if they were included
-   immediately following the proposal.  The party generating the
-   proposal can determine whether the padata were processed based on
-   whether the proposal for the reply key is accepted.
-
-   The specific formats of the proposal message, including where padata
-   are are included is a matter for the mechanism specification.
-   Similarly, the format of the message accepting the proposal is
-   mechanism-specific.
-
-   Mechanisms implementing this facility and including a typed hole for
-   additional padata MUST checksum that padata using a keyed checksum or
-   encrypt the padata.  Typically the reply key is used to protect the
-   padata.  If you are only minimally increasing the strength of the
-   reply key, this may give the attacker access to something too close
-   to the original reply key.  However, binding the padata to the new
-   reply key seems potentially important from a security standpoint.
-   There may also be objections to this from a double encryption
-   standpoint because we also recommend client authentication facilities
-   be tied to the reply key.
-
-4.3.  Replacing-reply-key Facility
-
-   The Replace Reply Key facility replaces the key in which a successful
-   AS reply will be encrypted.  This facility can only be used in cases
-   where knowledge of the reply key is not used to authenticate the
-   client.  The new reply key MUST be communicated to the client and the
-   KDC in a secure manner.  Mechanisms implementing this facility MUST
-   mark the reply key as replaced in the pre-authentication state.
-   Mechanisms implementing this facility MUST either provide a mechanism
-   to verify the KDC reply to the client or mark the reply as unverified
-   in the pre-authentication state.  Mechanisms implementing this
-   facility SHOULD NOT be used if a previous mechanism has used the
-   reply key.
-
-   As with the strengthening-reply-key facility, Kerberos extensibility
-   rules require that the reply key not be changed unless both sides of
-   the exchange understand the extension.  In the case of this facility
-   it will likely be more common for both sides to know that the
-   facility is available by the time that the new key is available to be
-   used.  However, mechanism designers can use a container for padata in
-   a proposal message as discussed in Section 4.2 if appropriate.
-
-
-
-
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 13]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-4.4.  KDC-authentication Facility
-
-   This facility verifies that the reply comes from the expected KDC.
-   In traditional Kerberos, the KDC and the client share a key, so if
-   the KDC reply can be decrypted then the client knows that a trusted
-   KDC responded.  Note that the client machine cannot trust the client
-   unless the machine is presented with a service ticket for it
-   (typically the machine can retrieve this ticket by itself).  However,
-   if the reply key is replaced, some mechanism is required to verify
-   the KDC.  Pre-authentication mechanisms providing this facility allow
-   a client to determine that the expected KDC has responded even after
-   the reply key is replaced.  They mark the pre-authentication state as
-   having been verified.
-
-
-5.  Requirements for Pre-Authentication Mechanisms
-
-   This section lists requirements for specifications of pre-
-   authentication mechanisms.
-
-   For each message in the pre-authentication mechanism, the
-   specification describes the pa-type value to be used and the contents
-   of the message.  The processing of the message by the sender and
-   recipient is also specified.  This specification needs to include all
-   modifications to the pre-authentication state.
-
-   Generally mechanisms have a message that can be sent in the error
-   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
-   authentication set.  If the client need information such as, for
-   example, trusted certificate authorities in order to determine if it
-   can use the mechanism, then this information should be in that
-   message.  In addition, such mechanisms should also define a pa-hint
-   to be included in authentication sets.  Often, the same information
-   included in the padata-value is appropriate to include in the pa-
-   hint.
-
-   In order to ease security analysis the mechanism specification should
-   describe what facilities from this document are offered by the
-   mechanism.  For each facility, the security consideration section of
-   the mechanism specification should show that the security
-   requirements of that facility are met.  This requirement is
-   applicable to any FAST factor that is used in FAST to provide
-   authentication information.
-
-   Significant problems have resulted in the specification of Kerberos
-   protocols because much of the KDC exchange is not protected against
-   authentication.  The security considerations section should discuss
-   unauthenticated plaintext attacks.  It should either show that
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 14]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   plaintext is protected or discuss what harm an attacker could do by
-   modifying the plaintext.  It is generally acceptable for an attacker
-   to be able to cause the protocol negotiation to fail by modifying
-   plaintext.  More significant attacks should be evaluated carefully.
-
-
-6.  Tools for Use in Pre-Authentication Mechanisms
-
-   This section describes common tools needed by multiple pre-
-   authentication mechanisms.  By using these tools mechanism designers
-   can use a modular approach to specify mechanism details and ease
-   security analysis.
-
-6.1.  Combining Keys
-
-   Frequently a weak key need to be combined with a stronger key before
-   use.  For example, passwords are typically limited in size and
-   insufficiently random, therefore it is desirable to increase the
-   strength of the keys based on passwords by adding additional secrets
-   to it.  Additional source of secrecy may come from hardware tokens.
-
-   This section provides standard ways to combine two keys into one.
-
-   KRB-FX-CF1() is defined to combine two pass-phrases.
-
-    KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
-    KRB-FX-CF1(x, y) -> x || y
-
-   Where || denotes concatenation.  The strength of the final key is
-   roughly the total strength of the individual keys being combined.
-
-   An example usage of KRB-FX-CF1() is when a device provides random but
-   short passwords, the password is often combined with a personal
-   identification number (PIN).  The password and the PIN can be
-   combined using KRB-FX-CF1().
-
-   The function KRB-FX-CF2() produces a new key based on two existing
-   keys of the same enctype and it is base on a secure hash function and
-   the primitives encrypt(), random-to-key() and K-truncate() described
-   in [RFC3961].
-
-    KRB-FX-CF2(protocol key, protocol key, octet string) ->
-                  (resulting key)
-
-   The KRB-FX-CF2() function takes two protocol keys and an octet string
-   as input, and output a new key of the same enctype.
-
-
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 15]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-    encrypt(B, initial-cipher-state, pepper) -> (state-1, cipher-text-1)
-
-    encrypt(A, initial-cipher-state, pepper) -> (state-2, cipher-text-2)
-
-    PRF+(H, cipher-text-1 | cipher-text-2) -> bitstring-1
-
-    K-truncate(cipher-text-1) -> bitstring-2
-
-    random-to-key(bitstring-2) -> final-key
-
-    KRB-FX-CF2(A, B, pepper) -> final-key
-
-   Where initial-cipher-state is defined in [RFC3961] and the key-
-   generation seed length K is specified by the enctype profile
-   [RFC3961].  The value of the parameter pepper is RECOMMENDED to be in
-   the form of contextID || SharedInfo per guidelines in [HKDF].  If the
-   value of pepper is too short for the encrypt() primitive, it MUST
-   first be padded with all zeroes to the next shortest length that
-   encryt() can operate on.  PRF+() produces a bit-string of at least K
-   bits in length.
-
-   H is the secure hash function associated with the enctype.  An
-   example of a secure hash function is SHA-256 [SHA2].
-
-   This document updates [RFC3961] to associate a secure hash function
-   with every enctype.  Unless otherwise specified by the enctype
-   specification, the associated hash function is SHA-256.  The
-   associated hash function for hmac-sha1-96-aes256 is SHA-512 [SHA2].
-
-        encryption type       etype       associated hash function
-      --------------------------------------------------------------
-      hmac-sha1-96-aes256      16             SHA-512 [SHA2]
-
-   PRF+ is defined as follows:
-
-     PRF+(secure hash function, octet string) -> (octet string)
-
-     PRF+(H, shared-info) -> H( 1 || shared-info ) ||
-        H( 2 || shared-info ) H ( 3 || shared-info ) || ...
-
-   Where the counter value 1, 2, 3 and so on are encoded as a one-octet
-   integer.
-
-   Mechanism designers MUST specify the pepper value when combining two
-   keys using KRB-FX-CF2().
-
-
-
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 16]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-6.2.  Protecting Requests/Responses
-
-   Mechanism designers SHOULD provide integrity protection of the
-   messages in a conversation whenever feasible
-
-   Sensitive data MUST be encrypted when sent over the wire.  Non-
-   sensitive data that have privacy implications are encouraged to be
-   encrypted as well.
-
-   If there are more than one roundtrip for an authentication exchange,
-   mechanism designers SHOULD allow either the client or the KDC provide
-   a checksum of all the messages exchanged on the wire, that is then
-   verified by the receiver.
-
-   Primitives defined in [RFC3961] are RECOMMENDED for integrity
-   protection and confidentiality.  Mechanisms based on these primitives
-   have the benefit of crypto-agility provided by [RFC3961].  The
-   advantage afforded by crypto-agility is the ability to avoid a multi-
-   year standardization and deployment cycle to fix a problem specific
-   to a particular algorithm, when real attacks do arise against that
-   algorithm.
-
-   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
-
-6.3.  Managing States for the KDC
-
-   For any conversation that consists of more than two messages, the KDC
-   likely need to keep track of KDC states for incomplete authentication
-   exchanges and destroy the states of a conversation when the
-   authentication completes successful or fails, or the KDC times out.
-   When the KDC times out, the KDC returns an error message with the
-   code KDC_ERR_PREAUTH_TIMED_OUT.
-
-       KDC_ERR_PREAUTH_TIMED_OUT           TBA
-
-   Upnon receipt of this error, the client MUST abort the existing
-   conversation, and restart a new one.
-
-   An example, where more than one message from the client is needed, is
-   when the client is authenticated based on a challenge-response
-   scheme.  In that case, the KDC need to keep track of the challenge
-   issued for a client authentication request.
-
-   The PA-FX-COOKIE pdata type is defined in this section to facilitate
-   state management.
-
-       PA_FX_COOKIE                        TBA
-
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 17]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   The corresponding padata-value field [RFC4120] contains the
-   Distinguished Encoding Rules (DER) [X60] [X690] encoding of the
-   following Abstract Syntax Notation One (ASN.1) type PA-FX-COOKIE:
-
-     PA-FX-COOKIE ::= SEQUENCE {
-         Cookie          [1] OCTET STRING,
-             -- Opaque data, for use to associate all the messages in a
-             -- single conversation between the client and the KDC.
-             -- This can be generated by either the client or the KDC.
-             -- The receiver MUST copy the exact Cookie encapsulated in
-             -- a PA_FX_COOKIE data element into the next message of the
-             -- same conversation.
-         ...
-     }
-
-   The PA-FX-COOKIE structure contains an opaque cookie that is a logic
-   identifier of all the messages in a conversation.
-
-   The PA_FX_COOKIE can be initially sent by the client or the KDC, the
-   receiver MUST copy the Cookie into a PA_FX_COOKIE padata and include
-   it in the next message, if any, in the same conversation.
-
-   The content of the PA_FX_COOKIE padata is a local matter of the
-   sender.  Implementations MUST NOT include any sensitive or private
-   data in the PA-FX-COOKIE structure.
-
-   If at least one more message for a mechanism or a mechanism set is
-   expected by the KDC, the KDC returns a
-   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA_FX_COOKIE to
-   identify the conversation with the client.
-
-       KDC_ERR_MORE_PREAUTH_DATA_NEEDED    TBA
-
-   If a PA_FX_COOKIE is included in the client request, the KDC then
-   MUST copy the exact cookie into the response.
-
-6.4.  Pre-authentication Set
-
-   If all mechanisms in a group need to successfully complete in order
-   to authenticate a client, the client and the KDC SHOULD use the
-   PA_AUTHENTICATION_SET padata element.  A PA_AUTHENTICATION_SET padata
-   element contains the ASN.1 DER encoding of the PA-AUTHENTICATION-SET
-   structure:
-
-
-
-
-
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 18]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-       PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-       PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-           pa-type         [1] Int32,
-               -- same as padata-type.
-           pa-hint         [2] OCTET STRING,
-               -- hint data.
-           ...
-       }
-
-   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
-   contains the corresponding value of padata-type in PA-DATA [RFC4120].
-   Associated with the pa-type is a pa-hint, which is an octet-string
-   specified by the pre-authentication mechanism.  This hint may provide
-   information for the client which helps it determine whether the
-   mechanism can be used.  For example a public-key mechanism might
-   include the certificate authorities it trusts in the hint info.  Most
-   mechanisms today do not specify hint info; if a mechanism does not
-   specify hint info the KDC MUST NOT send a hint for that mechanism.
-   To allow future revisions of mechanism specifications to add hint
-   info, clients MUST ignore hint info received for mechanisms that the
-   client believes do not support hint info.
-
-   When indicating which sets of padata are supported, the KDC includes
-   a PA-AUTHENTICATION-SET padata element for each authentication set.
-
-   The client sends the padata-value for the first mechanism it picks in
-   the authentication set, when the first mechanism completes, the
-   client and the KDC will proceed with the second mechanism, and so on
-   until all mechanisms complete successfully.  The PA_FX_COOKIE as
-   defined in Section 6.3 MUST be sent by the KDC along with the first
-   message that contains a PA-AUTHENTICATION-SET, in order to keep track
-   of KDC states.
-
-6.5.  Definition of Kerberos FAST Padata
-
-   The cipher text exposure of encrypted timestamp pre-authentication
-   data is a security concern for Kerberos.  Attackers can lauch offline
-   dictionary attack using the cipher text.  The FAST pre-authentication
-   padata is a tool to mitigate this threat.  FAST also provides
-   solutions to common problems for pre-authentication mechanisms such
-   as binding of the request and the reply, freshness guarantee of the
-   authentication.  FAST itself, however, does not authenticate the
-   client or the KDC, instead, it provides a typed hole to allow pre-
-   authentication data be tunneled using FAST messages.  A pre-
-   authentication data element used within FAST is called a FAST factor.
-   A FAST factor capatures the minimal work required for extending
-   Kerberos to support a new authentication scheme.  A FAST factor MUST
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 19]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   NOT be used outside of FAST unless its specification explicitly
-   allows so.  The typed holes in FAST messages can also be used as
-   generic ones that are not intended to prove the client's identity, or
-   establish the reply key.
-
-   New pre-authentication mechanisms SHOULD be designed as FAST factors,
-   instead of full-blown pre-authentication mechanisms.
-
-   A FAST mechanism factor when used within FAST to authenticate the
-   client or the KDC is a pre-authentication mechanism, as such the
-   specification of such a FAST factor SHOULD specify which facilities
-   it provides per Section 5.
-
-   Implementations of the pre-authentication framework SHOULD use
-   encrypted timestamp pre-authentication, if that is the mechanism to
-   authenticate the client, as a FAST factor to avoid security exposure.
-
-   The encrypted timestamp FAST factor MUST fill out the encrypted rep-
-   key-package field as described in Section 6.5.3.  It provides the
-   following facilities: client-authentication, replacing-reply-key,
-   KDC-authentication.  It does not provide the strengthening-reply-key
-   facility.  The security considerations section of this document
-   provides an explaination why the security requirements are met.
-
-   FAST employs an armoring scheme.  The armor can be a host Ticket
-   Granting Ticket (TGT), or an anonymous TGT obtained based on
-   anonymous PKINIT [KRB-ANON], or a pre-shared long term key such as a
-   host key.  The rest of this section describes the types of armors and
-   the messages used by FAST.
-
-6.5.1.  FAST Armors
-
-   An armor key is used to encrypt pre-authentication data in the FAST
-   request and the response.  The ArmorData structure is used to
-   identify the armor key.  It contains the following two fields: the
-   armor-type identifies the type of armor data, and the armor-value as
-   an OCTET STRING contains the data.
-
-       KrbFastArmor ::= SEQUENCE {
-           armor-type     [1] Int32,
-               -- Type of the armor.
-           armor-value    [2] OCTET STRING,
-               -- Value of the armor.
-           ...
-       }
-
-   The value of the armor key is a matter of the armor type
-   specification.  The following types of armors are currently defined:
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 20]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-       FX_FAST_ARMOR_AP_REQUEST  1
-       FX_FAST_ARMOR_KEY_ID      2
-
-   Conforming implementations MUST implement the
-   FX_FAST_ARMOR_AP_REQUEST armor type.
-
-6.5.1.1.  Ticket-based Armors
-
-   The FX_FAST_ARMOR_AP_REQUEST armor type is based on a Kerberos TGT.
-   The armor-value field of an FX_FAST_ARMOR_AP_REQUEST armor contains
-   an AP-REQ encoded in DER.  The subkey field in the AP-REQ MUST be
-   present.  And the armor key is the subkey in the AP-REQ
-   authenticator.
-
-   If the client has a TGT for the expected KDC, it can use that ticket
-   to construct the AP-REQ.  If not, the client can use anonymous PKINIT
-   as described in [KRB-ANON] to obtain a TGT anonymously and use that
-   to construct an FX_FAST_ARMOR_AP_REQUEST armor.
-
-6.5.1.2.  Key-based Armors
-
-   The FX_FAST_ARMOR_KEY_ID armor type is used to carry an identifier of
-   a key that is shared between the client host and the KDC.  The
-   content and the encoding of the armor-data field of this armor type
-   is a local matter of the communicating client and the expected KDC.
-   The FX_FAST_ARMOR_KEY_ID armor is useful when the client host and the
-   KDC does have a shared key and it is beneficial to minimize the
-   number of messages exchanged between the client and the KDC, namely
-   by eliminating the messages for obtaining a host ticket based on the
-   host key.
-
-6.5.2.  FAST Request
-
-   A padata type PA_FX_FAST is defined for the Kerberos FAST pre-
-   authentication padata.  The corresponding padata-value field
-   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
-   REQUEST.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 21]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-    PA-FX-FAST-REQUEST ::= CHOICE {
-        armored-data    [1] KrbFastAmoredReq,
-        ...
-    }
-
-    KrbFastAmoredReq ::= SEQUENCE {
-        armor           [1] KrbFastArmor OPTIONAL,
-            -- Contains the armor that determines the armor key.
-            -- MUST be present in the initial AS-REQ in a converstation,
-            -- MUST be absent in any subsequent AS-REQ.
-            -- MUST be absent in TGS-REQ.
-        req-checksum    [2] Checksum,
-            -- Checksum performed over the type KDC-REQ-BODY.
-            -- The checksum key is the armor key, and the checksum
-            -- type is the required checksum type for the enctype of
-            -- the armor key.
-        enc-fast-req    [3] EncryptedData, -- KrbFastReq --
-            -- The encryption key is the armor key, and the key usage
-            -- number is TBA.
-        ...
-    }
-
-   The PA-FX-FAST-REQUEST contains a KrbFastAmoredReq structure.  The
-   KrbFastAmoredReq encapsulates the encrypted padata.
-
-   The armor key is used to encrypt the KrbFastReq structure, and the
-   key usage number for that encryption is TBA.  The armor field in the
-   KrbFastAmoredReq structure is filled to identify the armor key.
-
-   When a KrbFastAmoredReq is included in an AS request, the armor field
-   MUST be present in the initial AS-REQ in a converstation, specifying
-   the armor key being used.  The armor field MUST be absent in any
-   subsequent AS-REQ of the same converstation.  Thus the armor key is
-   specified explicitly in the initial AS-REQ in a converstation, and
-   implicitly thereafter.
-
-   When a KrbFastAmoredReq is included in a TGS request, the armor field
-   MUST be absent.  In which case, the subkey in the AP-REQ
-   authenticator in the PA-TGS-REQ PA-DATA MUST be present, and the
-   armor key is implicitly that subkey.
-
-   The req-checksum field contains a checksum that is performed over the
-   type KDC-REQ-BODY of the containing message.  The checksum key is the
-   armor key, and the checksum type is the required checksum type for
-   the enctype of the armor key.
-
-   The enc-fast-req field contains an encrypted KrbFastReq structure.
-   The KrbFastReq structure contains the following information:
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 22]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-       KrbFastReq ::= SEQUENCE {
-           fast-options    [0] FastOptions,
-               -- Additional options.
-           padata          [1] SEQUENCE OF PA-DATA,
-               -- padata typed holes.
-           timestamp       [2] KerberosTime,
-           usec            [3] Microseconds,
-               -- timestamp and usec represent the time of the client
-               -- host.
-           req-nonce       [4] OCTET STRING,
-               -- At least 128 octets in length, randomly filled using
-               -- a PRNG by the client for each message request.
-           ...
-       }
-
-   The fast-options field indicates various options that are to modify
-   the behavior of the KDC.  The meanings of the options are as follows:
-
-      FastOptions ::= KerberosFlags
-          -- reserved(0),
-          -- anonymous(1),
-          -- kdc-referrals(16)
-
-
-      Bits    Name          Description
-     -----------------------------------------------------------------
-      0     RESERVED        Reserved for future expansion of this field.
-      1     anonymous       Requesting the KDC to hide client names in
-                            the KDC response, as described next in this
-                            section.
-      16    kdc-referrals   Requesting the KDC to follow referrals, as
-                            described next in this section.
-
-   Bits 1 through 15 (with bit 2 and bit 15 included) are critical
-   options.  If the KDC does not understand a critical option, it MUST
-   fail the request.  Bit 16 and onward (with bit 16 included) are non-
-   critical options.  The KDC conforming to this specification ignores
-   unknown non-critical options.
-
-   The anonymous Option
-
-      The Kerberos response defined in [RFC4120] contains the client
-      identity in clear text, This makes traffic analysis
-      straightforward.  The anonymous option is designed to complicate
-      traffic analysis performed over the client-KDC messages.  If the
-      anonymous option is set, the KDC implementing PA_FX_FAST MUST
-      identify the client as the anonymous principal in the KDC reply
-      and the error response.  Thus this option is set by the client if
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 23]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-      it wishes to hide the client identity in the KDC response.
-
-   The kdc-referrals Option
-
-      The Kerberos client described in [RFC4120] has to request referral
-      TGTs along the authentication path in order to get a service
-      ticket for the target service.  The Kerberos client described in
-      the [REFERRALS] need to contain the AS specified in the error
-      response in order to complete client referrals.  In many cases, it
-      is desirable to keep the client's involvement minimal.  For
-      example, the client may contact the KDC via a satellite link that
-      has high latency, or the client has limited computational
-      capabilities.  The kdc-referrals option is designed to minimize
-      the number of KDC response messages that the client need to
-      process.  If the kdc-referrals option is set, the KDC that honors
-      this option acts as the client to follow AS referrals and TGS
-      referrals [REFERRALS], and return the ticket thus-obtained using
-      the reply key expected by the client.  The kdc-referrals option
-      can be implemented when the KDC knows the reply key.  KDC can
-      igore kdc-referrals option when it does not understand it or it
-      does not allow it based on local policy.  The client MUST be able
-      to process the KDC responses when this option is not honored by
-      the KDC, unless otherwise specified.
-
-   The padata field contains a list of PA-DATA structures as described
-   in Section 5.2.7 in [RFC4120].  These PA-DATA structures can contain
-   FAST factors.  They can also be used as generic typed-holes to
-   contain data not intended for proving the client's identity or
-   establishing a reply key, but for protocol extensibility.
-
-   The timestamp and usec fields represent the time of the client host,
-   these fields have the same semantics as the corresponding-
-   identically-named fields in Section 5.6.1 of [RFC4120].
-
-   The req-nonce field is randomly filled using a PRNG by the client for
-   each message request.  It MUST have at least 128 octets in length.
-
-6.5.3.  FAST Response
-
-   The KDC that supports the PA_FX_FAST padata MUST include a PA_FX_FAST
-   padata element in the KDC reply and/or the error response, when the
-   client and the KDC agreed upon the armor key.  The corresponding
-   padata-value field [RFC4120] in the KDC response is the DER encoding
-   of the ASN.1 type PA-FX-FAST-REPLY.
-
-
-
-
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 24]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-      PA-FX-FAST-REPLY ::= CHOICE {
-          armored-data    [1] KrbFastArmoredRep,
-          ...
-      }
-
-      KrbFastArmoredRep ::= SEQUENCE {
-          enc-fast-rep    [1] EncryptedData, -- KrbFastResponse --
-              -- The encryption key is the armor key in the request, and
-              -- the key usage number is TBA.
-          ...
-      }
-
-   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
-   structure.  The KrbFastArmoredRep structure encapsulates the padata
-   in the KDC reply in the encrypted form.  The KrbFastResponse is
-   encrypted with the armor key used in the corresponding request, and
-   the key usage number is TBA.
-
-   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
-   KDC response MUST reject the reply based on local policy.  The
-   Kerberos client MAY process an error message without a PA-FX-FAST-
-   REPLY, if that is only intended to return better error information to
-   the application, typically for trouble-shooing purposes.
-
-   The KrbFastResponse structure contains the following information:
-
-      KrbFastResponse ::= SEQUENCE {
-          padata          [1] SEQUENCE OF PA-DATA,
-              -- padata typed holes.
-          finish          [2] KrbFastFinish OPTIONAL,
-              -- MUST be present if the client is authenticated,
-              -- absent otherwise.
-              -- Typically this is present if and only if the containing
-              -- message is the last one in a conversation.
-          rep-nonce       [3] OCTET STRING,
-              -- At least 128 octets in length, randomly filled using
-              -- a PRNG by the KDC for each KDC response.
-          ...
-      }
-
-   The padata field in the KrbFastResponse structure contains a list of
-   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
-   PA-DATA structures are used to carry data completing the exchange for
-   the FAST factors.  They can also be used as generic typed-holes for
-   protocol extensibility.
-
-   The finish field contains a KrbFastFinish structure.  It is filled by
-   the KDC when the client has been authenticated (the client
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 25]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   authenticated state is marked), it MUST be absent otherwise.
-   Consequently this field can only be present in an AS-REP or a TGS-REP
-   when a ticket is returned.  And typically the containing message with
-   the finish field present is the last one in a conversation.
-
-   The KrbFastFinish structure contains the following information:
-
-    KrbFastFinish ::= SEQUENCE {
-        authtime        [1] KerberosTime,
-        usec            [2] Microseconds,
-            -- timestamp and usec represent the time on the KDC when
-            -- the reply was generated.
-        rep-key-package [3]  EncryptedData OPTIONAL, -- EncryptionKey --
-            -- This, if present, replaces the reply key for AS and TGS.
-            -- The encryption key is the client key, unless otherwise
-            -- specified. The key usage number is TBA.
-        crealm          [4] Realm,
-        cname           [5] PrincipalName,
-            -- Contains the client realm and the client name.
-        checksum        [6] Checksum,
-            -- Checksum performed over all the messages in the
-            -- conversation, except the containing message.
-            -- The checksum key is the ticket session key of the reply
-            -- ticket, and the checksum type is the required checksum
-            -- type of that key.
-        ...
-    }
-
-   The timestamp and usec fields represent the time on the KDC when the
-   reply was generated, these fields have the same semantics as the
-   corresponding-identically-named fields in Section 5.6.1 of [RFC4120].
-   The client MUST use the KDC's time in these fields thereafter when
-   using the returned ticket.  Note that the KDC's time in AS-REP may
-   not match the authtime in the reply ticket if the kdc-referrals
-   option is requested and honored by the KDC.
-
-   The rep-key-package field, if present, contains the reply key
-   encrypted using the client key unless otherwise specified.  The key
-   usage number is TBA.
-
-   When the encrypted timestamp FAST factor is used in the request, the
-   rep-key-package field MUST be present and the client key is used to
-   encrypt the reply key enclosed in the KrbFastArmoredRep.
-
-   The cname and crealm fields identifies the authenticated client.
-
-   The checksum field contains a checksum of all the messages in the
-   conversation excluding and prior to the containing message.  The
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 26]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   checksum key is the ticket session key of the reply ticket, and the
-   checksum type is the required checksum type of the enctype of that
-   key.
-
-   The rep-nonce field is randomly filled using a PRNG by the KDC for
-   each KDC response, and it MUST have at least 128 octets in length.
-
-   The client MUST include a PA_FX_COOKIE as defined in Section 6.3, if
-   it includes a PA_FX_FAST in the request.
-
-6.6.  Authentication Strength Indication
-
-   Implementations that have pre-authentication mechanisms offering
-   significantly different strengths of client authentication MAY choose
-   to keep track of the strength of the authentication used as an input
-   into policy decisions.  For example, some principals might require
-   strong pre-authentication, while less sensitive principals can use
-   relatively weak forms of pre-authentication like encrypted timestamp.
-
-   An AuthorizationData data type AD-Authentication-Strength is defined
-   for this purpose.
-
-          AD-authentication-strength      TBA
-
-   The corresponding ad-data field contains the DER encoding of the pre-
-   authentication data set as defined in Section 6.4.  This set contains
-   all the pre-authentication mechanisms that were used to authenticate
-   the client.  If only one pre-authentication mechanism was used to
-   authenticate the client, the pre-authentication set contains one
-   element.
-
-   The AD-authentication-strength element MUST be included in the AD-IF-
-   RELEVANT, thus it can be ignored if it is unknown to the receiver.
-
-
-7.  IANA Considerations
-
-   This document defines FAST factors, these are mini- and light-
-   weighted- pre-authentication mechanisms.  A new IANA registry should
-   be setup for registering FAST factor IDs.
-
-
-8.  Security Considerations
-
-   The kdc-referrals option in the Kerberos FAST padata requests the KDC
-   to act as the client to follow referrals.  This can overload the KDC.
-   To limit the damages of denied of service using this option, KDCs MAY
-   restrict the number of simultaneous active requests with this option
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 27]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   for any given client principal.
-
-   Because the client secrets are known only to the client and the KDC,
-   the verification of the encrypted timestamp proves the client's
-   identity, the verification of the encrypted rep-key-package in the
-   KDC reply proves that the expected KDC responded.  The encrypted
-   reply key is contained in the rep-key-package in the PA-FX-FAST-
-   REPLY.  Therefore, the encrypted timestamp FAST factor as a pre-
-   authentication mechanism offers the following facilities: client-
-   authentication, replacing-reply-key, KDC-authentication.  There is no
-   un-authenticated cleartext introduced by the encrypted timestamp FAST
-   factor.
-
-
-9.  Acknowledgements
-
-   Serveral suggestions from Jeffery Hutzman based on early revisions of
-   this documents led to significant improvements of this document.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity 
-              Support", draft-ietf-krb-wg-anon, work in progress.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [REFERALS] Raeburn, K. et al, "Generating KDC Referrals to Locate 
-              Kerberos Realms", draft-ietf-krb-wg-kerberos-referrals, 
-              work in progress.
-
-Zhu & Hartman            Expires April 27, 2007                [Page 27]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   [SHA2]     National Institute of Standards and Technology, "Secure 
-              Hash Standard (SHS)", Federal Information Processing 
-              Standards Publication 180-2, August 2002.  
-
-   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
-              Information technology - Abstract Syntax Notation One
-              (ASN.1): Specification of basic notation.
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 28]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-   
-   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
-              Information technology - ASN.1 encoding Rules:
-              Specification of Basic Encoding Rules (BER), Canonical
-              Encoding Rules (CER) and Distinguished Encoding Rules
-              (DER).
-
-10.2.  Informative References
-
-   [EKE]      Bellovin, S. M. and M. Merritt. "Augmented 
-              Encrypted Key Exchange: A Password-Based Protocol Secure 
-              Against Dictionary Attacks and Password File Compromise". 
-              Proceedings of the 1st ACM Conference on Computer and 
-              Communications Security, ACM Press, November 1993.
-   
-   [HKDF]     Dang, Q. and P. Polk, draft-dang-nistkdf, work in 
-              progress.
-
-   [IEEE1363.2] 
-              IEEE P1363.2: Password-Based Public-Key Cryptography, 
-              2004.
-           
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-
-Appendix A.  ASN.1 module
-
-    KerberosPreauthFramework {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2) modules(4) preauth-framework(3)
-    } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-    IMPORTS
-
-          KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
-          Int32, EncryptedData, PA-DATA
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) };
-                 -- as defined in RFC 4120.
-
-    PA-FX-COOKIE ::= SEQUENCE {
-        Cookie          [1] OCTET STRING,
-            -- Opaque data, for use to associate all the messages in a
-            -- single conversation between the client and the KDC.
-            -- This can be generated by either the client or the KDC.
-            -- The receiver MUST copy the exact Cookie encapsulated in
-            -- a PA_FX_COOKIE data element into the next message of the
-            -- same conversation.
-        ...
-    }
-
-    PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-    PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-        pa-type         [1] Int32,
-            -- same as padata-type.
-        pa-hint         [2] OCTET STRING,
-            -- hint data.
-        ...
-    }
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 29]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-
-    PA-FX-FAST-REQUEST ::= CHOICE {
-        armored-data    [1] KrbFastAmoredReq,
-        ...
-    }
-
-    KrbFastAmoredReq ::= SEQUENCE {
-        armor           [1] KrbFastArmor OPTIONAL,
-            -- Contains the armor that determines the armor key.
-            -- MUST be present in AS-REQ.
-            -- MUST be absent in TGS-REQ.
-        req-checksum    [2] Checksum,
-            -- Checksum performed over the type KDC-REQ-BODY.
-            -- The checksum key is the armor key, and the checksum
-            -- type is the required checksum type for the enctype of
-            -- the armor key.
-        enc-fast-req    [3] EncryptedData, -- KrbFastReq --
-            -- The encryption key is the armor key, and the key usage
-            -- number is TBA.
-        ...
-    }
-
-    KrbFastArmor ::= SEQUENCE {
-        armor-type     [1] Int32,
-            -- Type of the armor.
-        armor-value    [2] OCTET STRING,
-            -- Value of the armor.
-        ...
-    }
-
-    KrbFastReq ::= SEQUENCE {
-        fast-options    [0] FastOptions,
-            -- Additional options.
-        padata          [1] SEQUENCE OF PA-DATA,
-            -- padata typed holes.
-        timestamp       [2] KerberosTime,
-        usec            [3] Microseconds,
-            -- timestamp and usec represent the time of the client
-            -- host.
-        req-nonce       [4] OCTET STRING,
-            -- At least 128 octets in length, randomly filled using
-            -- a PRNG by the client for each message request.
-        ...
-    }
-
-    FastOptions ::= KerberosFlags
-        -- reserved(0),
-        -- anonymous(1),
-        -- kdc-referrals(16)
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 30]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-
-    PA-FX-FAST-REPLY ::= CHOICE {
-        armored-data    [1] KrbFastArmoredRep,
-        ...
-    }
-
-    KrbFastArmoredRep ::= SEQUENCE {
-        enc-fast-rep    [1] EncryptedData, -- KrbFastResponse --
-            -- The encryption key is the armor key in the request, and
-            -- the key usage number is TBA.
-        ...
-    }
-
-    KrbFastResponse ::= SEQUENCE {
-        padata          [1] SEQUENCE OF PA-DATA,
-            -- padata typed holes.
-        finish          [2] KrbFastFinish OPTIONAL,
-            -- MUST be present if the client is authenticated,
-            -- absent otherwise.
-            -- Typically this is present if and only if the containing
-            -- message is the last one in a conversation.
-        rep-nonce       [3] OCTET STRING,
-            -- At least 128 octets in length, randomly filled using
-            -- a PRNG by the KDC for each KDC response.
-        ...
-    }
-
-    KrbFastFinish ::= SEQUENCE {
-        timestamp       [1] KerberosTime,
-        usec            [2] Microseconds,
-            -- timestamp and usec represent the time on the KDC when
-            -- the reply was generated.
-        rep-key-package [3]  EncryptedData OPTIONAL, -- EncryptionKey --
-            -- This, if present, replaces the reply key for AS and TGS.
-            -- The encryption key is the client key, unless otherwise
-            -- specified. The key usage number is TBA.
-        crealm          [4] Realm,
-        cname           [5] PrincipalName,
-            -- Contains the client realm and the client name.
-        checksum        [6] Checksum,
-            -- Checksum performed over all the messages in the
-            -- conversation, except the containing message.
-            -- The checksum key is the ticket session key of the reply
-            -- ticket, and the checksum type is the required checksum
-            -- type of that key.
-        ...
-    }
-
-    END
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Sam hartman
-   MIT
-
-   Email: hartmans@mit.edu
-
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 31]
-
-Internet-Draft         Kerberos Preauth Framework           October 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Zhu & Hartman            Expires April 28, 2007                [Page 32]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-05.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-05.txt
deleted file mode 100644
index dc17ceb52..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-05.txt
+++ /dev/null
@@ -1,1938 +0,0 @@
-
-
-Kerberos Working Group                                            L. Zhu
-Internet-Draft                                     Microsoft Corporation
-Updates: 4120 (if approved)                                   S. Hartman
-Intended status: Standards Track                                     MIT
-Expires: September 6, 2007                                 March 5, 2007
-
-
-        A Generalized Framework for Kerberos Pre-Authentication
-                 draft-ietf-krb-wg-preauth-framework-05
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 6, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   Kerberos is a protocol for verifying the identity of principals
-   (e.g., a workstation user or a network server) on an open network.
-   The Kerberos protocol provides a mechanism called pre-authentication
-   for proving the identity of a principal and for better protecting the
-   long-term secret of the principal.
-
-   This document describes a model for Kerberos pre-authentication
-
-
-
-Zhu & Hartman           Expires September 6, 2007               [Page 1]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   mechanisms.  The model describes what state in the Kerberos request a
-   pre-authentication mechanism is likely to change.  It also describes
-   how multiple pre-authentication mechanisms used in the same request
-   will interact.
-
-   This document also provides common tools needed by multiple pre-
-   authentication mechanisms.  One of these tools is a secure channel
-   between the client and the KDC with a reply key delivery mechanism;
-   this secure channel can be used to protect the authentication
-   exchange thus eliminate offline dictionary attacks.  With these
-   tools, it is straightforward to chain multiple authentication
-   mechanisms, utilize a different key management system, or support a
-   new key agreement algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Hartman           Expires September 6, 2007               [Page 2]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Conventions and Terminologies Used in This Document  . . . . .  5
-   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  5
-     3.1.  Information Managed by the Pre-authentication Model  . . .  6
-     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  8
-     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . .  9
-     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 10
-   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 10
-     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 12
-     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 12
-     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 13
-     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 14
-   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 14
-   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15
-     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 15
-     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 16
-     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 17
-     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 19
-     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 20
-       6.5.1.  FAST and Encrypted Time Stamp  . . . . . . . . . . . . 21
-       6.5.2.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 21
-       6.5.3.  FAST Request . . . . . . . . . . . . . . . . . . . . . 22
-       6.5.4.  FAST Response  . . . . . . . . . . . . . . . . . . . . 26
-       6.5.5.  Error Messages used with Kerberos FAST . . . . . . . . 28
-     6.6.  Authentication Strength Indication . . . . . . . . . . . . 28
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 30
-   Appendix A.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 30
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
-   Intellectual Property and Copyright Statements . . . . . . . . . . 34
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Hartman           Expires September 6, 2007               [Page 3]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-1.  Introduction
-
-   The core Kerberos specification [RFC4120] treats pre-authentication
-   data as an opaque typed hole in the messages to the KDC that may
-   influence the reply key used to encrypt the KDC reply.  This
-   generality has been useful: pre-authentication data is used for a
-   variety of extensions to the protocol, many outside the expectations
-   of the initial designers.  However, this generality makes designing
-   more common types of pre-authentication mechanisms difficult.  Each
-   mechanism needs to specify how it interacts with other mechanisms.
-   Also, problems like combining a key with the long-term secret or
-   proving the identity of the user are common to multiple mechanisms.
-   Where there are generally well-accepted solutions to these problems,
-   it is desirable to standardize one of these solutions so mechanisms
-   can avoid duplication of work.  In other cases, a modular approach to
-   these problems is appropriate.  The modular approach will allow new
-   and better solutions to common pre-authentication problems to be used
-   by existing mechanisms as they are developed.
-
-   This document specifies a framework for Kerberos pre-authentication
-   mechanisms.  It defines the common set of functions that pre-
-   authentication mechanisms perform as well as how these functions
-   affect the state of the request and reply.  In addition several
-   common tools needed by pre-authentication mechanisms are provided.
-   Unlike [RFC3961], this framework is not complete--it does not
-   describe all the inputs and outputs for the pre-authentication
-   mechanisms.  Pre-Authentication mechanism designers should try to be
-   consistent with this framework because doing so will make their
-   mechanisms easier to implement.  Kerberos implementations are likely
-   to have plugin architectures for pre-authentication; such
-   architectures are likely to support mechanisms that follow this
-   framework plus commonly used extensions.
-
-   One of these common tools is the flexible authentication secure
-   tunneling (FAST) padata.  FAST provides a protected channel between
-   the client and the KDC, and it also delivers a reply key within the
-   protected channel.  Based on FAST, pre-authentication mechanisms can
-   extend Kerberos with ease, to support, for example, password
-   authenticated key exchange (PAKE) protocols with zero knowledge
-   password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-authentication
-   mechanism can be encapsulated in the FAST messages as defined in
-   Section 6.5.  A pre-authentication type carried within FAST is called
-   a FAST factor.  Creating a FAST factor is the easiest path to create
-   a new pre-authentication mechanism.  FAST factors are significantly
-   easier to analyze from a security standpoint than other pre-
-   authentication mechanisms.
-
-   Mechanism designers should design FAST factors, instead of new pre-
-
-
-
-Zhu & Hartman           Expires September 6, 2007               [Page 4]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   authentication mechanisms outside of FAST.
-
-   This document should be read only after reading the documents
-   describing the Kerberos cryptography framework [RFC3961] and the core
-   Kerberos protocol [RFC4120].  This document freely uses terminology
-   and notation from these documents without reference or further
-   explanation.
-
-
-2.  Conventions and Terminologies Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   The word padata is used as the shorthand of pre-authentication data.
-
-   A conversation is used to refer to all authentication messages
-   exchanged between the client and the KDCs in order to authenticate
-   the client principal.  A conversation as defined here consists of all
-   messages that are necessary to complete the authentication between
-   the client and the KDC.  It is the smallest logic unit for messages
-   exchanged between the client and the KDC.
-
-
-3.  Model for Pre-Authentication
-
-   When a Kerberos client wishes to obtain a ticket using the
-   authentication server, it sends an initial Authentication Service
-   (AS) request.  If pre-authentication is required but not being used,
-   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
-   Alternatively, if the client knows what pre-authentication to use, it
-   MAY optimize away a round-trip and send an initial request with
-   padata included in the initial request.  If the client includes the
-   wrong padata, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
-   indication of what padata should have been included.  In that case,
-   the client MUST retry with no padata and examine the error data of
-   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
-   authentication information in the accompanying error data of
-   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
-   then retry.
-
-   The conventional KDC maintains no state between two requests;
-   subsequent requests may even be processed by a different KDC.  On the
-   other hand, the client treats a series of exchanges with KDCs as a
-   single conversation.  Each exchange accumulates state and hopefully
-   brings the client closer to a successful authentication.
-
-
-
-
-Zhu & Hartman           Expires September 6, 2007               [Page 5]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   These models for state management are in apparent conflict.  For many
-   of the simpler pre-authentication scenarios, the client uses one
-   round trip to find out what mechanisms the KDC supports.  Then the
-   next request contains sufficient pre-authentication for the KDC to be
-   able to return a successful reply.  For these simple scenarios, the
-   client only sends one request with pre-authentication data and so the
-   conversation is trivial.  For more complex conversations, the KDC
-   needs to provide the client with a cookie to include in future
-   requests to capture the current state of the authentication session.
-   Handling of multiple round-trip mechanisms is discussed in
-   Section 6.3.
-
-   This framework specifies the behavior of Kerberos pre-authentication
-   mechanisms used to identify users or to modify the reply key used to
-   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
-   extensions to Kerberos that have nothing to do with proving the
-   identity of the user or establishing a reply key.  Such extensions
-   are outside the scope of this framework.  However mechanisms that do
-   accomplish these goals should follow this framework.
-
-   This framework specifies the minimum state that a Kerberos
-   implementation needs to maintain while handling a request in order to
-   process pre-authentication.  It also specifies how Kerberos
-   implementations process the padata at each step of the AS request
-   process.
-
-3.1.  Information Managed by the Pre-authentication Model
-
-   The following information is maintained by the client and KDC as each
-   request is being processed:
-
-   o  The reply key used to encrypt the KDC reply
-
-   o  How strongly the identity of the client has been authenticated
-
-   o  Whether the reply key has been used in this conversation
-
-   o  Whether the reply key has been replaced in this conversation
-
-   o  Whether the contents of the KDC reply can be verified by the
-      client principal
-
-
-   Conceptually, the reply key is initially the long-term key of the
-   principal.  However, principals can have multiple long-term keys
-   because of support for multiple encryption types, salts and
-   string2key parameters.  As described in Section 5.2.7.5 of the
-   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
-
-
-
-Zhu & Hartman           Expires September 6, 2007               [Page 6]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   the client what types of keys are available.  Thus in full
-   generality, the reply key in the pre-authentication model is actually
-   a set of keys.  At the beginning of a request, it is initialized to
-   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
-   the KDC.  If multiple reply keys are available, the client chooses
-   which one to use.  Thus the client does not need to treat the reply
-   key as a set.  At the beginning of a request, the client picks a
-   reply key to use.
-
-   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
-   INFO2 element.  Since the KDC already knows the client's list of
-   supported enctypes from the request, no interoperability problems are
-   created by choosing a single possible reply key.  This way, the KDC
-   implementation avoids the complexity of treating the reply key as a
-   set.
-
-   When the padata in the request is verified by the KDC, then the
-   client is known to have that key, therefore the KDC SHOULD pick the
-   same key as the reply key.
-
-   At the beginning of handling a message on both the client and the
-   KDC, the client's identity is not authenticated.  A mechanism may
-   indicate that it has successfully authenticated the client's
-   identity.  This information is useful to keep track of on the client
-   in order to know what pre-authentication mechanisms should be used.
-   The KDC needs to keep track of whether the client is authenticated
-   because the primary purpose of pre-authentication is to authenticate
-   the client identity before issuing a ticket.  The handling of
-   authentication strength using various authentication mechanisms is
-   discussed in Section 6.6.
-
-   Initially the reply key has not been used.  A pre-authentication
-   mechanism that uses the reply key to encrypt or checksum some data in
-   the generation of new keys MUST indicate that the reply key is used.
-   This state is maintained by the client and the KDC to enforce the
-   security requirement stated in Section 4.3 that the reply key cannot
-   be replaced after it is used.
-
-   Initially the reply key has not been replaced.  If a mechanism
-   implements the Replace Reply Key facility discussed in Section 4.3,
-   then the state MUST be updated to indicate that the reply key has
-   been replaced.  Once the reply key has been replaced, knowledge of
-   the reply key is insufficient to authenticate the client.  The reply
-   key is marked replaced in exactly the same situations as the KDC
-   reply is marked as not being verified to the client principal.
-   However, while mechanisms can verify the KDC reply to the client,
-   once the reply key is replaced, then the reply key remains replaced
-   for the remainder of the conversation.
-
-
-
-Zhu & Hartman           Expires September 6, 2007               [Page 7]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   Without pre-authentication, the client knows that the KDC reply is
-   authentic and has not been modified because it is encrypted in a
-   long-term key of the client.  Only the KDC and the client know that
-   key.  So at the start of handling any message the KDC reply is
-   presumed to be verified using the client principal's long-term key.
-   Any pre-authentication mechanism that sets a new reply key not based
-   on the principal's long-term secret MUST either verify the KDC reply
-   some other way or indicate that the reply is not verified.  If a
-   mechanism indicates that the reply is not verified then the client
-   implementation MUST return an error unless a subsequent mechanism
-   verifies the reply.  The KDC needs to track this state so it can
-   avoid generating a reply that is not verified.
-
-   The typical Kerberos request does not provide a way for the client
-   machine to know that it is talking to the correct KDC.  Someone who
-   can inject packets into the network between the client machine and
-   the KDC and who knows the password that the user will give to the
-   client machine can generate a KDC reply that will decrypt properly.
-   So, if the client machine needs to authenticate that the user is in
-   fact the named principal, then the client machine needs to do a TGS
-   request for itself as a service.  Some pre-authentication mechanisms
-   may provide a way for the client to authenticate the KDC.  Examples
-   of this include signing the reply that can be verified using a well-
-   known public key or providing a ticket for the client machine as a
-   service.
-
-3.2.  Initial Pre-authentication Required Error
-
-   Typically a client starts a conversation by sending an initial
-   request with no pre-authentication.  If the KDC requires pre-
-   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
-   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
-   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
-   (defined in Section 6.3) for pre-authentication configurations that
-   use multi-round-trip mechanisms; see Section 3.4 for details of that
-   case. [[anchor3: Is it desirable to define a new error code for this?
-   Probably but we need to call out to the WG.]]
-
-   The KDC needs to choose which mechanisms to offer the client.  The
-   client needs to be able to choose what mechanisms to use from the
-   first message.  For example consider the KDC that will accept
-   mechanism A followed by mechanism B or alternatively the single
-   mechanism C. A client that supports A and C needs to know that it
-   should not bother trying A.
-
-   Mechanisms can either be sufficient on their own or can be part of an
-   authentication set--a group of mechanisms that all need to
-   successfully complete in order to authenticate a client.  Some
-
-
-
-Zhu & Hartman           Expires September 6, 2007               [Page 8]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   mechanisms may only be useful in authentication sets; others may be
-   useful alone or in authentication sets.  For the second group of
-   mechanisms, KDC policy dictates whether the mechanism will be part of
-   an authentication set or offered alone.  For each mechanism that is
-   offered alone, the KDC includes the pre-authentication type ID of the
-   mechanism in the padata sequence returned in the
-   KDC_ERR_PREAUTH_REQUIRED error.
-
-   The KDC SHOULD NOT send data that is encrypted in the long-term
-   password-based key of the principal.  Doing so has the same security
-   exposures as the Kerberos protocol without pre-authentication.  There
-   are few situations where pre-authentication is desirable and where
-   the KDC needs to expose cipher text encrypted in a weak key before
-   the client has proven knowledge of that key.
-
-3.3.  Client to KDC
-
-   This description assumes that a client has already received a
-   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
-   optimistic pre-authentication then the client needs to optimistically
-   choose the information it would normally receive from that error
-   response.
-
-   The client starts by initializing the pre-authentication state as
-   specified.  It then processes the padata in the
-   KDC_ERR_PREAUTH_REQUIRED.
-
-   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
-   client MAY ignore any padata it chooses unless doing so violates a
-   specification to which the client conforms.  Clients conforming to
-   this specification MUST NOT ignore the padata defined in Section 6.3.
-   Clients SHOULD process padata unrelated to this framework or other
-   means of authenticating the user.  Clients SHOULD choose one
-   authentication set or mechanism that could lead to authenticating the
-   user and ignore the rest.  Since the list of mechanisms offered by
-   the KDC is in the decreasing preference order, clients typically
-   choose the first mechanism or authentication set that the client can
-   usefully perform.  If a client chooses to ignore a padata it MUST NOT
-   process the padata, allow the padata to affect the pre-authentication
-   state, nor respond to the padata.
-
-   For each padata the client chooses to process, the client processes
-   the padata and modifies the pre-authentication state as required by
-   that mechanism.  Padata are processed in the order received from the
-   KDC.
-
-   After processing the padata in the KDC error, the client generates a
-   new request.  It processes the pre-authentication mechanisms in the
-
-
-
-Zhu & Hartman           Expires September 6, 2007               [Page 9]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   order in which they will appear in the next request, updating the
-   state as appropriate.  The request is sent when it is complete.
-
-3.4.  KDC to Client
-
-   When a KDC receives an AS request from a client, it needs to
-   determine whether it will respond with an error or an AS reply.
-   There are many causes for an error to be generated that have nothing
-   to do with pre-authentication; they are discussed in the core
-   Kerberos specification.
-
-   From the standpoint of evaluating the pre-authentication, the KDC
-   first starts by initializing the pre-authentication state.  It then
-   processes the padata in the request.  As mentioned in Section 3.3,
-   the KDC MAY ignore padata that is inappropriate for the configuration
-   and MUST ignore padata of an unknown type.
-
-   At this point the KDC decides whether it will issue a pre-
-   authentication required error or a reply.  Typically a KDC will issue
-   a reply if the client's identity has been authenticated to a
-   sufficient degree.
-
-   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC
-   first starts by initializing the pre-authentication state.  Then it
-   processes any padata in the client's request in the order provided by
-   the client.  Mechanisms that are not understood by the KDC are
-   ignored.  Mechanisms that are inappropriate for the client principal
-   or the request SHOULD also be ignored.  Next, it generates padata for
-   the error response, modifying the pre-authentication state
-   appropriately as each mechanism is processed.  The KDC chooses the
-   order in which it will generate padata (and thus the order of padata
-   in the response), but it needs to modify the pre-authentication state
-   consistently with the choice of order.  For example, if some
-   mechanism establishes an authenticated client identity, then the
-   subsequent mechanisms in the generated response receive this state as
-   input.  After the padata is generated, the error response is sent.
-   Typically the errors with the code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
-   in a converstation will include KDC state as discussed in
-   Section 6.3.
-
-   To generate a final reply, the KDC generates the padata modifying the
-   pre-authentication state as necessary.  Then it generates the final
-   response, encrypting it in the current pre-authentication reply key.
-
-
-4.  Pre-Authentication Facilities
-
-   Pre-Authentication mechanisms can be thought of as providing various
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 10]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   conceptual facilities.  This serves two useful purposes.  First,
-   mechanism authors can choose only to solve one specific small
-   problem.  It is often useful for a mechanism designed to offer key
-   management not to directly provide client authentication but instead
-   to allow one or more other mechanisms to handle this need.  Secondly,
-   thinking about the abstract services that a mechanism provides yields
-   a minimum set of security requirements that all mechanisms providing
-   that facility must meet.  These security requirements are not
-   complete; mechanisms will have additional security requirements based
-   on the specific protocol they employ.
-
-   A mechanism is not constrained to only offering one of these
-   facilities.  While such mechanisms can be designed and are sometimes
-   useful, many pre-authentication mechanisms implement several
-   facilities.  By combining multiple facilities in a single mechanism,
-   it is often easier to construct a secure, simple solution than by
-   solving the problem in full generality.  Even when mechanisms provide
-   multiple facilities, they need to meet the security requirements for
-   all the facilities they provide.  If the FAST factor approach is
-   used, it is likely that one or a small number of facilities can be
-   provided by a single mechanism without complicating the security
-   analysis.
-
-   According to Kerberos extensibility rules (Section 1.5 of the
-   Kerberos specification [RFC4120]), an extension MUST NOT change the
-   semantics of a message unless a recipient is known to understand that
-   extension.  Because a client does not know that the KDC supports a
-   particular pre-authentication mechanism when it sends an initial
-   request, a pre-authentication mechanism MUST NOT change the semantics
-   of the request in a way that will break a KDC that does not
-   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
-   clients that affect the core semantics unless the client has
-   indicated support for the message.
-
-   The only state in this model that would break the interpretation of a
-   message is changing the expected reply key.  If one mechanism changed
-   the reply key and a later mechanism used that reply key, then a KDC
-   that interpreted the second mechanism but not the first would fail to
-   interpret the request correctly.  In order to avoid this problem,
-   extensions that change core semantics are typically divided into two
-   parts.  The first part proposes a change to the core semantic--for
-   example proposes a new reply key.  The second part acknowledges that
-   the extension is understood and that the change takes effect.
-   Section 4.2 discusses how to design mechanisms that modify the reply
-   key to be split into a proposal and acceptance without requiring
-   additional round trips to use the new reply key in subsequent pre-
-   authentication.  Other changes in the state described in Section 3.1
-   can safely be ignored by a KDC that does not understand a mechanism.
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 11]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   Mechanisms that modify the behavior of the request outside the scope
-   of this framework need to carefully consider the Kerberos
-   extensibility rules to avoid similar problems.
-
-4.1.  Client-authentication Facility
-
-   The client authentication facility proves the identity of a user to
-   the KDC before a ticket is issued.  Examples of mechanisms
-   implementing this facility include the encrypted timestamp facility
-   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
-   Mechanisms that provide this facility are expected to mark the client
-   as authenticated.
-
-   Mechanisms implementing this facility SHOULD require the client to
-   prove knowledge of the reply key before transmitting a successful KDC
-   reply.  Otherwise, an attacker can intercept the pre-authentication
-   exchange and get a reply to attack.  One way of proving the client
-   knows the reply key is to implement the Replace Reply Key facility
-   along with this facility.  The PKINIT mechanism [RFC4556] implements
-   Client Authentication alongside Replace Reply Key.
-
-   If the reply key has been replaced, then mechanisms such as
-   encrypted-timestamp that rely on knowledge of the reply key to
-   authenticate the client MUST NOT be used.
-
-4.2.  Strengthening-reply-key Facility
-
-   Particularly, when dealing with keys based on passwords, it is
-   desirable to increase the strength of the key by adding additional
-   secrets to it.  Examples of sources of additional secrets include the
-   results of a Diffie-Hellman key exchange or key bits from the output
-   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
-   be first combined with the existing reply key and then converted to a
-   protocol key using tools defined in Section 6.1.
-
-   If a mechanism implementing this facility wishes to modify the reply
-   key before knowing that the other party in the exchange supports the
-   mechanism, it proposes modifying the reply key.  The other party then
-   includes a message indicating that the proposal is accepted if it is
-   understood and meets policy.  In many cases it is desirable to use
-   the new reply key for client authentication and for other facilities.
-   Waiting for the other party to accept the proposal and actually
-   modify the reply key state would add an additional round trip to the
-   exchange.  Instead, mechanism designers are encouraged to include a
-   typed hole for additional padata in the message that proposes the
-   reply key change.  The padata included in the typed hole are
-   generated assuming the new reply key.  If the other party accepts the
-   proposal, then these padata are considered as an inner level.  As
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 12]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   with the outer level, one authentication set or mechanism is
-   typically chosen for client authentication, along with auxiliary
-   mechanisms such as KDC cookies, and other mechanisms are ignored.
-   [[anchor6: Containers like this need more thought.  For example if
-   you are constructing an authentication set do you expect to use a
-   strengthen reply key mechanism in conjunction with something else, do
-   you include the something else in the hint of the strengthen
-   mechanism or as its own entry.  It's easier to configure and express
-   the authentication set as its own entry.  However if you do that' the
-   composition of the mechanisms looks in practice than it appears in
-   the authentication set.]]  The party generating the proposal can
-   determine whether the padata were processed based on whether the
-   proposal for the reply key is accepted.
-
-   The specific formats of the proposal message, including where padata
-   are included is a matter for the mechanism specification.  Similarly,
-   the format of the message accepting the proposal is mechanism-
-   specific.
-
-   Mechanisms implementing this facility and including a typed hole for
-   additional padata MUST checksum that padata using a keyed checksum or
-   encrypt the padata. [[anchor7: Why?  I suspect there's an obvious
-   attack here but I need to work through it and add detail.  In
-   particular, it seems that a checksum at the end should be
-   sufficient.]]Typically the reply key is used to protect the padata.
-   If you are only minimally increasing the strength of the reply key,
-   this may give the attacker access to something too close to the
-   original reply key.  However, binding the padata to the new reply key
-   seems potentially important from a security standpoint.  There may
-   also be objections to this from a double encryption standpoint
-   because we also recommend client authentication facilities be tied to
-   the reply key.
-
-4.3.  Replacing-reply-key Facility
-
-   The Replace Reply Key facility replaces the key in which a successful
-   AS reply will be encrypted.  This facility can only be used in cases
-   where knowledge of the reply key is not used to authenticate the
-   client.  The new reply key MUST be communicated to the client and the
-   KDC in a secure manner.  Mechanisms implementing this facility MUST
-   mark the reply key as replaced in the pre-authentication state.
-   Mechanisms implementing this facility MUST either provide a mechanism
-   to verify the KDC reply to the client or mark the reply as unverified
-   in the pre-authentication state.  Mechanisms implementing this
-   facility SHOULD NOT be used if a previous mechanism has used the
-   reply key.
-
-   As with the strengthening-reply-key facility, Kerberos extensibility
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 13]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   rules require that the reply key not be changed unless both sides of
-   the exchange understand the extension.  In the case of this facility
-   it will likely be more common for both sides to know that the
-   facility is available by the time that the new key is available to be
-   used.  However, mechanism designers can use a container for padata in
-   a proposal message as discussed in Section 4.2 if appropriate.
-
-4.4.  KDC-authentication Facility
-
-   This facility verifies that the reply comes from the expected KDC.
-   In traditional Kerberos, the KDC and the client share a key, so if
-   the KDC reply can be decrypted then the client knows that a trusted
-   KDC responded.  Note that the client machine cannot trust the client
-   unless the machine is presented with a service ticket for it
-   (typically the machine can retrieve this ticket by itself).  However,
-   if the reply key is replaced, some mechanism is required to verify
-   the KDC.  Pre-authentication mechanisms providing this facility allow
-   a client to determine that the expected KDC has responded even after
-   the reply key is replaced.  They mark the pre-authentication state as
-   having been verified.
-
-
-5.  Requirements for Pre-Authentication Mechanisms
-
-   This section lists requirements for specifications of pre-
-   authentication mechanisms.
-
-   For each message in the pre-authentication mechanism, the
-   specification describes the pa-type value to be used and the contents
-   of the message.  The processing of the message by the sender and
-   recipient is also specified.  This specification needs to include all
-   modifications to the pre-authentication state.
-
-   Generally mechanisms have a message that can be sent in the error
-   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
-   authentication set.  If the client needs information such as trusted
-   certificate authorities in order to determine if it can use the
-   mechanism, then this information should be in that message.  In
-   addition, such mechanisms should also define a pa-hint to be included
-   in authentication sets.  Often, the same information included in the
-   padata-value is appropriate to include in the pa-hint (as defined in
-   Section 6.4).
-
-   In order to ease security analysis the mechanism specification should
-   describe what facilities from this document are offered by the
-   mechanism.  For each facility, the security consideration section of
-   the mechanism specification should show that the security
-   requirements of that facility are met.  This requirement is
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 14]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   applicable to any FAST factor that provides authentication
-   information.
-
-   Significant problems have resulted in the specification of Kerberos
-   protocols because much of the KDC exchange is not protected against
-   authentication.  The security considerations section should discuss
-   unauthenticated plaintext attacks.  It should either show that
-   plaintext is protected or discuss what harm an attacker could do by
-   modifying the plaintext.  It is generally acceptable for an attacker
-   to be able to cause the protocol negotiation to fail by modifying
-   plaintext.  More significant attacks should be evaluated carefully.
-
-   As discussed in Section 6.3, there is no guarantee that a client will
-   use the same KDCs for all messages in a conversation.  The mechanism
-   specification needs to show why the mechanism is secure in this
-   situation.  The hardest problem to deal with, especially for
-   challenge/response mechanisms is to make sure that the same response
-   cannot be replayed against two KDCs while allowing the client to talk
-   to any KDC.
-
-
-6.  Tools for Use in Pre-Authentication Mechanisms
-
-   This section describes common tools needed by multiple pre-
-   authentication mechanisms.  By using these tools mechanism designers
-   can use a modular approach to specify mechanism details and ease
-   security analysis.
-
-6.1.  Combining Keys
-
-   Frequently a weak key need to be combined with a stronger key before
-   use.  For example, passwords are typically limited in size and
-   insufficiently random, therefore it is desirable to increase the
-   strength of the keys based on passwords by adding additional secrets.
-   Additional source of secrecy may come from hardware tokens.
-
-   This section provides standard ways to combine two keys into one.
-
-   KRB-FX-CF1() is defined to combine two pass-phrases.
-
-       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
-       KRB-FX-CF1(x, y) -> x || y
-
-   Where || denotes concatenation.  The strength of the final key is
-   roughly the total strength of the individual keys being combined
-   assuming that the string_to_key() function [RFC3961] uses all its
-   input evenly.
-
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 15]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   An example usage of KRB-FX-CF1() is when a device provides random but
-   short passwords, the password is often combined with a personal
-   identification number (PIN).  The password and the PIN can be
-   combined using KRB-FX-CF1().
-
-   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
-   function defined in [RFC3961].
-
-   Given two input keys, K1 and K2, where K1 and K2 can be of two
-   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
-   follows:
-
-       KRB-FX-CF2(protocol key, protocol key, octet string,
-                 octet string)  ->  (protocol key)
-
-       PRF+(K1, pepper1) -> octet-string-1
-       PRF+(K2, pepper2) -> octet-string-2
-       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
-              random-to-key(octet-string-1 ^ octet-string-2)
-
-   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
-   follows:
-
-    PRF+(protocol key, octet string) -> (octet string)
-
-    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
-                  pseudo-random( key, 2 || shared-info ) ||
-                  pseudo-random( key, 3 || shared-info ) || ...
-
-   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
-   integer.  The pseudo-random() operation is specified by the enctype
-   of the protocol key.  PRF+() uses the counter to generate enough bits
-   as needed by the random-to-key() [RFC3961] function for the
-   encryption type specified for the resulting key; unneeded bits are
-   removed from the tail.
-
-   Mechanism designers MUST specify the pepper values when combining two
-   keys using KRB-FX-CF2().  The pepper1 and pepper2 MUST be distinct so
-   that if the two keys being combined are the same, the resulting key
-   is not a trivial key.
-
-6.2.  Protecting Requests/Responses
-
-   Mechanism designers SHOULD protect clear text portions of pre-
-   authentication data.  Various denial of service attacks and downgrade
-   attacks against Kerberos are possible unless plaintexts are somehow
-   protected against modification.  An early design goal of Kerberos
-   Version 5 [RFC4120] was to avoid encrypting more of the
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 16]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   authentication exchange that was required.  (Version 4 doubly-
-   encrypted the encrypted part of a ticket in a KDC reply, for
-   example.)  This minimization of encryption reduces the load on the
-   KDC and busy servers.  Also, during the initial design of Version 5,
-   the existence of legal restrictions on the export of cryptography
-   made it desirable to minimize of the number of uses of encryption in
-   the protocol.  Unfortunately, performing this minimization created
-   numerous instances of unauthenticated security-relevant plaintext
-   fields.
-
-   If there are more than one roundtrip for an authentication exchange,
-   mechanism designers need to allow either the client or the KDC to
-   provide a checksum of all the messages exchanged on the wire in the
-   conversation, and the checksum is then verified by the receiver.
-
-   Primitives defined in [RFC3961] are RECOMMENDED for integrity
-   protection and confidentiality.  Mechanisms based on these primitives
-   have the benefit of crypto-agility provided by [RFC3961].
-
-   The advantage afforded by crypto-agility is the ability to avoid a
-   multi-year standardization and deployment cycle to fix a problem that
-   is specific to a particular algorithm, when real attacks do arise
-   against that algorithm.
-
-   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
-
-   Note that data used by FAST factors (defined in Section 6.5) are
-   encrypted in a protected channel, in most cases, therefore no un-
-   authenticated-text issue is associated with these mechanisms.
-   However mechanism designers MUST consider the case carefully when the
-   KDC authentication is not provided by Kerberos FAST.
-
-6.3.  Managing States for the KDC
-
-   [[anchor11: Kerberos is stateless today.  We can either maintain that
-   and store all the state in a cookie or change that and require
-   clients go to the same KDC for future requests.  Consider how this
-   interacts with proxies.  The rest of this section assumes we maintain
-   the current model.]]  Kerberos KDCs are stateless.  There is no
-   requirement that clients will choose the same KDC for the second
-   request in a conversation.  Proxies or other intermediate nodes may
-   also influence KDC selection.  So, each request from a client to a
-   KDC must include sufficient information that the KDC can regenerate
-   any needed state.  This is accomplished by giving the client a
-   potentially long opaque cookie in responses to include in future
-   requests in the same conversation.  The KDC MAY respond that a
-   conversation is too old and needs to restart by responding with a
-   KDC_ERR_PREAUTH_EXPIRED error.
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 17]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-       KDC_ERR_PREAUTH_EXPIRED            TBA
-
-   When a client receives this error, the client MUST abort the existing
-   conversation, and restart a new one.
-
-   An example, where more than one message from the client is needed, is
-   when the client is authenticated based on a challenge-response
-   scheme.  In that case, the KDC needs to keep track of the challenge
-   issued for a client authentication request.
-
-   The PA-FX-COOKIE pdata type is defined in this section to facilitate
-   state management.  This padata is sent by the KDC when the KDC
-   requires state for a future transaction.  The client includes this
-   opaque token in the next message in the conversation.  The token may
-   be relatively large; clients MUST be prepared for tokens somewhat
-   larger than the size of all messages in a conversation.
-
-       PA_FX_COOKIE                       TBA
-           -- Stateless cookie that is not tied to a specific KDC.
-
-   The corresponding padata-value field [RFC4120] contains the
-   Distinguished Encoding Rules (DER) [X60] [X690] encoding of the
-   following Abstract Syntax Notation One (ASN.1) type PA-FX-COOKIE:
-
-     PA-FX-COOKIE ::= SEQUENCE {
-         Cookie            [1] OCTET STRING,
-             -- Opaque data, for use to associate all the messages in a
-             -- single conversation between the client and the KDC.
-             -- This can be generated by either the client or the KDC.
-             -- The receiver MUST copy the exact Cookie encapsulated in
-             -- a PA_FX_COOKIE data element into the next message of the
-             -- same conversation.
-         ...
-     }
-
-   The content of the PA_FX_COOKIE padata is a local matter of the KDC.
-   However the KDC MUST construct the token in such a manner that a
-   malicious client cannot subvert the authentication process by
-   manipulating the token.  The KDC implementation needs to consider
-   expiration of tokens, key rollover and other security issues in token
-   design.  The content of the Cookie field is likely specific to the
-   pre-authentication mechanisms used to authenticate the client.  In
-   order to compute the finished field in the KrbFastRespons structure
-   as defined in Section 6.5.4, all the previous messages in the
-   conversation MUST be included in the Cookie.  If a client
-   authentication response can be replayed to multiple KDCs via the
-   PA_FX_COOKIE mechanism, an expiration in the Cookie is RECOMMENDED to
-   prevent the response being presented indefinitely.
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 18]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   If at least one more message for a mechanism or a mechanism set is
-   expected by the KDC, the KDC returns a
-   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA_FX_COOKIE to
-   identify the conversation with the client.
-
-       KDC_ERR_MORE_PREAUTH_DATA_NEEDED   TBA
-
-6.4.  Pre-authentication Set
-
-   If all mechanisms in a group need to successfully complete in order
-   to authenticate a client, the client and the KDC SHOULD use the
-   PA_AUTHENTICATION_SET padata element.
-
-   A PA_AUTHENTICATION_SET padata element contains the ASN.1 DER
-   encoding of the PA-AUTHENTICATION-SET structure:
-
-       PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-       PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-           pa-type           [1] Int32,
-               -- same as padata-type.
-           pa-hint           [2] OCTET STRING,
-               -- hint data.
-           ...
-       }
-
-   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
-   contains the corresponding value of padata-type in PA-DATA [RFC4120].
-   Associated with the pa-type is a pa-hint, which is an octet-string
-   specified by the pre-authentication mechanism.  This hint may provide
-   information for the client which helps it determine whether the
-   mechanism can be used.  For example a public-key mechanism might
-   include the certificate authorities it trusts in the hint info.  Most
-   mechanisms today do not specify hint info; if a mechanism does not
-   specify hint info the KDC MUST NOT send a hint for that mechanism.
-   To allow future revisions of mechanism specifications to add hint
-   info, clients MUST ignore hint info received for mechanisms that the
-   client believes do not support hint info. [[anchor12: What if you
-   have a padata type as the first member of a set that requires a
-   challenge.  For example SAM assumes that the KDC sends a challenge to
-   the client initially.  That's not a pa-hint; that's a pa-value.  How
-   do you convey that data with this?]] [[anchor13: The PA-SET appears
-   only in the first message from the KDC to the client?  In particular,
-   the client should not be prepared for the future authentication
-   mechanisms to change as the conversation progresses.  I think this is
-   correct; we should discuss and if the WG agrees the text should
-   reflect this.]]
-
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 19]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   When indicating which sets of padata are supported, the KDC includes
-   a PA-AUTHENTICATION-SET padata element for each authentication set.
-
-   The client sends the padata-value for the first mechanism it picks in
-   the authentication set, when the first mechanism completes, the
-   client and the KDC will proceed with the second mechanism, and so on
-   until all mechanisms complete successfully.  The PA_FX_COOKIE as
-   defined in Section 6.3 MUST be sent by the KDC along with the first
-   message that contains a PA-AUTHENTICATION-SET, in order to keep track
-   of KDC states.
-
-   [[anchor14: It's much easier to design UIs if you can determine ahead
-   of time what all the elements of your dialogue will need to be.  If
-   we mandate that the pa-hints need to be sufficient that you can
-   determine what information you will require from a user ahead of time
-   we can simplify the UI for login.  I propose that we make this
-   requirement.  WG agreement required.]]
-
-6.5.  Definition of Kerberos FAST Padata
-
-   The cipher text exposure when using the encrypted timestamp pre-
-   authentication data is a security concern for Kerberos.  Attackers
-   can launch offline dictionary attack using the cipher text.  The FAST
-   pre-authentication padata is a tool to mitigate this threat.  FAST
-   also provides solutions to common problems for pre-authentication
-   mechanisms such as binding of the request and the reply, freshness
-   guarantee of the authentication.  FAST itself, however, does not
-   authenticate the client or the KDC, instead, it provides a typed hole
-   to allow pre-authentication data be tunneled.  A pre-authentication
-   data element used within FAST is called a FAST factor.  A FAST factor
-   captures the minimal work required for extending Kerberos to support
-   a new authentication scheme.
-
-   A FAST factor MUST NOT be used outside of FAST unless its
-   specification explicitly allows so.  The typed holes in FAST messages
-   can also be used as generic holes for other padata that are not
-   intended to prove the client's identity, or establish the reply key.
-
-   New pre-authentication mechanisms SHOULD be designed as FAST factors,
-   instead of full-blown pre-authentication mechanisms.
-
-   FAST factors that are pre-authentication mechanisms MUST meet the
-   requirements in Section 5.
-
-   FAST employs an armoring scheme.  The armor can be a host Ticket
-   Granting Ticket (TGT), or an anonymous TGT obtained based on
-   anonymous PKINIT [KRB-ANON], or a pre-shared long term key such as a
-   host key.  The armoring TGT can be a cross-realm TGT.  The rest of
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 20]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   this section describes the types of armors and the messages used by
-   FAST.
-
-6.5.1.  FAST and Encrypted Time Stamp
-
-   FAST provides new behavior for encrypted time stamp [RFC4120].  When
-   used as a FAST factor, this mechanism provides stronger security
-   guarantees.
-
-   Implementations of the pre-authentication framework SHOULD use
-   encrypted timestamp pre-authentication, if that is the mechanism to
-   authenticate the client, as a FAST factor to avoid security exposure.
-
-   The encrypted timestamp FAST factor MUST fill out the encrypted rep-
-   key-package field as described in Section 6.5.4.  It provides the
-   following facilities: client-authentication, replacing-reply-key,
-   KDC-authentication.  It does not provide the strengthening-reply-key
-   facility.  The security considerations section of this document
-   provides an explanation why the security requirements are met.
-
-6.5.2.  FAST Armors
-
-   An armor key is used to encrypt pre-authentication data in the FAST
-   request and the response.  The ArmorData structure is used to
-   identify the armor key.  It contains the following two fields: the
-   armor-type identifies the type of armor data, and the armor-value as
-   an OCTET STRING contains the data.
-
-       KrbFastArmor ::= SEQUENCE {
-           armor-type        [1] Int32,
-               -- Type of the armor.
-           armor-value       [2] OCTET STRING,
-               -- Value of the armor.
-           ...
-       }
-
-   The value of the armor key is a matter of the armor type
-   specification.  The following armor types are currently defined :
-
-
-       FX_FAST_ARMOR_AP_REQUEST  1
-       FX_FAST_ARMOR_KEY_ID      2
-
-   Conforming implementations MUST implement the
-   FX_FAST_ARMOR_AP_REQUEST armor type.
-
-
-
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 21]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-6.5.2.1.  Ticket-based Armors
-
-   The FX_FAST_ARMOR_AP_REQUEST armor type is based on a Kerberos TGT.
-   The armor-value field of an FX_FAST_ARMOR_AP_REQUEST armor contains
-   an AP-REQ encoded in DER.  The subkey field in the AP-REQ MUST be
-   present.  The armor key is the subkey in the AP-REQ authenticator.
-
-   The ticket in the AP-REQ MUST be for the TGT service of the target
-   KDC.  Here are 3 ways in the decreasing preference order how an armor
-   TGT SHOULD be obtained:
-
-   1.  If the client is authenticating from a host machine whose
-       Kerberos realm has a trust path to the client's realm, the host
-       machine obtains a TGT to the client's realm, and this ticket is
-       the armor ticket.
-
-   2.  Otherwise, the client's host machine cannot obtain a host ticket
-       strictly based on RFC4120, but the KDC has a signing asymmetric
-       key that the client can verify its binding with the expected KDC,
-       the client then can use anonymous PKINIT to obtain a anonymous
-       TGT, and use that TGT to as the armor ticket.
-
-   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
-       TGT without KDC authentication.  Note that this mode of operation
-       is vulnerable to man-in-the-middle attacks at the time of
-       obtaining the initial anonymous TGT.
-
-   Because the KDC does not know if the client is able to trust the
-   ticket it has, the KDC and client MUST initialize the pre-
-   authentication state to an unverified KDC.
-
-6.5.2.2.  Key-based Armors
-
-   The FX_FAST_ARMOR_KEY_ID armor type is used to carry an identifier of
-   a key that is shared between the client host and the KDC.  The
-   content and the encoding of the armor-data field of this armor type
-   is a local matter of the communicating client and the expected KDC.
-   The FX_FAST_ARMOR_KEY_ID armor is useful when the client host and the
-   KDC does have a shared key and it is beneficial to minimize the
-   number of messages exchanged between the client and the KDC, namely
-   by eliminating the messages for obtaining a host ticket based on the
-   host key. [[anchor19: Do we believe this has sufficient value to
-   specify or do we want to assume all armor comes from tickets?]]
-
-6.5.3.  FAST Request
-
-   A padata type PA_FX_FAST is defined for the Kerberos FAST pre-
-   authentication padata.  The corresponding padata-value field
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 22]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
-   REQUEST.
-
-       PA_FX_FAST                         TBA
-           -- Padata type for Kerberos FAST
-
-       PA-FX-FAST-REQUEST ::= CHOICE {
-           armored-data      [1] KrbFastAmoredReq,
-           ...
-       }
-
-       KrbFastAmoredReq ::= SEQUENCE {
-           armor             [1] KrbFastArmor OPTIONAL,
-               -- Contains the armor that determines the armor key.
-               -- MUST be present in AS-REQ.
-               -- MUST be absent in TGS-REQ.
-           req-checksum      [2] Checksum,
-               -- Checksum performed over the type KDC-REQ-BODY.
-               -- The checksum key is the armor key, the checksum
-               -- type is the required checksum type for the enctype of
-               -- the armor key, and the key usage number is
-               -- KEY_USAGE_FAST_REA_CHKSUM.
-           enc-fast-req      [3] EncryptedData, -- KrbFastReq --
-               -- The encryption key is the armor key, and the key usage
-               -- number is KEY_USAGE_FAST_ENC.
-           ...
-       }
-
-       KEY_USAGE_FAST_REA_CHKSUM          TBA
-       KEY_USAGE_FAST_ENC                 TBA
-
-   The PA-FX-FAST-REQUEST contains a KrbFastAmoredReq structure.  The
-   KrbFastAmoredReq encapsulates the encrypted padata.
-
-   The armor key is used to encrypt the KrbFastReq structure, and the
-   key usage number for that encryption is KEY_USAGE_FAST_ARMOR.
-
-       KEY_USAGE_FAST_ARMOR               TBA
-
-   The armor key is identified as follows:
-
-   o  When a KrbFastAmoredReq is included in an AS request, the armor
-      field MUST be present in the initial AS-REQ in a conversation,
-      specifying the armor key being used.  The armor field MUST be
-      absent in any subsequent AS-REQ of the same conversation.  In
-      other words, the armor key is specified explicitly in the initial
-      AS-REQ in a conversation, and implicitly thereafter.
-
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 23]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   o  When a KrbFastAmoredReq is included in a TGS request, the armor
-      field MUST be absent.  In which case, the subkey in the AP-REQ
-      authenticator in the PA-TGS-REQ PA-DATA MUST be present, and the
-      armor key is implicitly that subkey.
-
-   The req-checksum field contains a checksum that is performed over the
-   type KDC-REQ-BODY of the containing message.  The checksum key is the
-   armor key, and the checksum type is the required checksum type for
-   the enctype of the armor key.
-
-   The enc-fast-req field contains an encrypted KrbFastReq structure.
-   The KrbFastReq structure contains the following information:
-
-       KrbFastReq ::= SEQUENCE {
-           fast-options      [0] FastOptions,
-               -- Additional options.
-           padata            [1] SEQUENCE OF PA-DATA,
-               -- padata typed holes.
-           crealm            [2] Realm OPTIONAL,
-           cname             [3] PrincipalName OPTIONAL,
-               -- Contains the client realm and the client name.
-               -- If present, the client name and realm in the
-               -- AS_REQ KDC-REQ-BODY [RFC4120] MUST be ignored.
-           ...
-       }
-
-   The fast-options field indicates various options that are to modify
-   the behavior of the KDC.  The meanings of the options are as follows:
-
-      FastOptions ::= KerberosFlags
-          -- reserved(0),
-          -- anonymous(1),
-          -- kdc-referrals(16)
-
-
-      Bits    Name          Description
-     -----------------------------------------------------------------
-      0     RESERVED        Reserved for future expansion of this field.
-      1     anonymous       Requesting the KDC to hide client names in
-                            the KDC response, as described next in this
-                            section.
-      16    kdc-referrals   Requesting the KDC to follow referrals, as
-                            described next in this section.
-
-   Bits 1 through 15 (with bit 2 and bit 15 included) are critical
-   options.  If the KDC does not understand a critical option, it MUST
-   fail the request.  Bit 16 and onward (with bit 16 included) are non-
-   critical options.  KDCs conforming to this specification ignores
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 24]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   unknown non-critical options.
-
-   The anonymous Option
-
-      The Kerberos response defined in [RFC4120] contains the client
-      identity in clear text, This makes traffic analysis
-      straightforward.  The anonymous option is designed to complicate
-      traffic analysis performed over the messages exchanged between the
-      client and the KDC.  If the anonymous option is set, the KDC
-      implementing PA_FX_FAST MUST identify the client as the anonymous
-      principal in the KDC reply and the error response.  Hence this
-      option is set by the client if it wishes to conceal the client
-      identity in the KDC response.
-
-   The kdc-referrals Option
-
-      The Kerberos client described in [RFC4120] has to request referral
-      TGTs along the authentication path in order to get a service
-      ticket for the target service.  The Kerberos client described in
-      the [REFERRALS] need to contact the AS specified in the error
-      response in order to complete client referrals.  The kdc-referrals
-      option is designed to minimize the number of messages that need to
-      be processed by the client.  This option is useful when, for
-      example, the client may contact the KDC via a satellite link that
-      has high latency, or the client has limited computational
-      capabilities.  If the kdc-referrals option is set, the KDC that
-      honors this option acts as the client to follow AS referrals and
-      TGS referrals [REFERRALS], and return the ticket thus-obtained
-      using the reply key expected by the client.  The kdc-referrals
-      option can be implemented when the KDC knows the reply key.  The
-      KDC can ignore kdc-referrals option when it does not understand it
-      or it does not allow this option based on local policy.  The
-      client MUST be able to process the KDC responses when this option
-      is not honored by the KDC, unless otherwise specified.
-
-   The padata field contains a list of PA-DATA structures as described
-   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
-   FAST factors.  They can also be used as generic typed-holes to
-   contain data not intended for proving the client's identity or
-   establishing a reply key, but for protocol extensibility.
-
-   The crealm field and the cname field identify the client principal in
-   the ticket request.  If either the crealm field or the cname field is
-   present, the corresponding crealm or cname field in the KDC-REQ-BODY
-   [RFC4120] of an AS-REQ MUST be ignored.  The client can fill in these
-   fields in the KrbFastReq structure and leaves the cname field and the
-   crealm field KDC-REQ-BODY absent, thus conceals its identity in the
-   AS-REQ.
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 25]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-6.5.4.  FAST Response
-
-   The KDC that supports the PA_FX_FAST padata MUST include a PA_FX_FAST
-   padata element in the KDC reply and/or the error response, when the
-   client and the KDC agreed upon the armor key.  The corresponding
-   padata-value field [RFC4120] in the KDC response is the DER encoding
-   of the ASN.1 type PA-FX-FAST-REPLY.
-
-      PA-FX-FAST-REPLY ::= CHOICE {
-          armored-data      [1] KrbFastArmoredRep,
-          ...
-      }
-
-      KrbFastArmoredRep ::= SEQUENCE {
-          enc-fast-rep      [1] EncryptedData, -- KrbFastResponse --
-              -- The encryption key is the armor key in the request, and
-              -- the key usage number is KEY_USAGE_FAST_REP.
-          ...
-      }
-      KEY_USAGE_FAST_REP                 TBA
-
-   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
-   structure.  The KrbFastArmoredRep structure encapsulates the padata
-   in the KDC reply in the encrypted form.  The KrbFastResponse is
-   encrypted with the armor key used in the corresponding request, and
-   the key usage number is KEY_USAGE_FAST_REP.
-
-   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
-   KDC response MUST support a local policy that rejects the request.
-   Clients MAY also support policies that fall back to other mechanisms
-   or that do not use pre-authentication when FAST is unavailable.  It
-   is important to consider the potential downgrade attacks when
-   deploying such a policy.  The Kerberos client MAY process an error
-   message without a PA-FX-FAST-REPLY, if that is only intended to
-   return better error information to the application, typically for
-   trouble-shooing purposes.
-
-   The KrbFastResponse structure contains the following information:
-
-      KrbFastResponse ::= SEQUENCE {
-          padata            [1] SEQUENCE OF PA-DATA,
-              -- padata typed holes.
-          finished          [2] KrbFastFinished OPTIONAL,
-              -- MUST be present if the client is authenticated,
-              -- absent otherwise.
-              -- Typically this is present if and only if the containing
-              -- message is the last one in a conversation.
-          ...
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 26]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-      }
-
-   The padata field in the KrbFastResponse structure contains a list of
-   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
-   PA-DATA structures are used to carry data advancing the exchange
-   specific for the FAST factors.  They can also be used as generic
-   typed-holes for protocol extensibility.
-
-   The finished field contains a KrbFastFinished structure.  It is
-   filled by the KDC in the final message in the conversation; it MUST
-   be absent otherwise.  Consequently this field can only be present in
-   an AS-REP or a TGS-REP when a ticket is returned.
-
-   The KrbFastFinished structure contains the following information:
-
-     KrbFastFinished ::= SEQUENCE {
-         timestamp         [1] KerberosTime,
-         usec              [2] Microseconds,
-             -- timestamp and usec represent the time on the KDC when
-             -- the reply was generated.
-         rep-key-package   [3]  EncryptedData OPTIONAL,
-                       -- EncryptionKey --
-             -- This, if present, replaces the reply key for AS and TGS.
-             -- The encryption key is the client key, unless otherwise
-             -- specified. The key usage number is
-             -- KEY_USAGE_FAST_FINISHED.
-         crealm            [4] Realm,
-         cname             [5] PrincipalName,
-             -- Contains the client realm and the client name.
-         checksum          [6] Checksum,
-             -- Checksum performed over all the messages in the
-             -- conversation, except the containing message.
-             -- The checksum key is the ticket session key of the reply
-             -- ticket, and the checksum type is the required checksum
-             -- type of that key.
-         ...
-     }
-     KEY_USAGE_FAST_REP_KEY             TBA
-     KEY_USAGE_FAST_FINISHED            TBA
-
-   The timestamp and usec fields represent the time on the KDC when the
-   reply ticket was generated, these fields have the same semantics as
-   the corresponding-identically-named fields in Section 5.6.1 of
-   [RFC4120].  The client MUST use the KDC's time in these fields
-   thereafter when using the returned ticket.  Note that the KDC's time
-   in AS-REP may not match the authtime in the reply ticket if the kdc-
-   referrals option is requested and honored by the KDC.
-
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 27]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   The rep-key-package field, if present, contains the reply key
-   encrypted using the client key unless otherwise specified.  The key
-   usage number is KEY_USAGE_FAST_REP_KEY.
-
-   When the encrypted timestamp FAST factor is used in the request, the
-   rep-key-package field MUST be present and the client key is used to
-   encrypt the reply key enclosed in the KrbFastArmoredRep.
-
-   The cname and crealm fields identify the authenticated client.
-
-   The checksum field contains a checksum of all the messages in the
-   conversation prior to the containing message (the containing message
-   is excluded).  The checksum key is the ticket session key of the
-   reply ticket, the checksum type is the required checksum type of the
-   enctype of that key, and the key usage number is
-   KEY_USAGE_FAST_FINISHED.
-
-6.5.5.  Error Messages used with Kerberos FAST
-
-   If the Kerberos FAST padata was included in the request, unless
-   otherwise specified, the e-data field of the KRB-ERROR message
-   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
-   [RFC4120], where a PA_FX_FAST padata element is included and it
-   contains the DER encoding of the type PA-FX-FAST-REPLY.  If the
-   e-data field of the KRB-ERROR message contains the DER encoding of a
-   TYPED-DATA, a typed data element TD_FX_FAST SHOULD be included in the
-   e-data if the Kerberos FAST padata is included in the request, and
-   the corresponding data-value field [RFC4120] contains the ASN.1 DER
-   encoding of the type PA-FX-FAST-REPLY.  In other words, the typed
-   data element type TD_FX_FAST is allocated to encapsulate the FAST
-   reply message in the error responses.  If a PA-FX-FAST-REPLY is not
-   included in the error reply, it is a matter of the local policy on
-   the client to accept the information in the error message without
-   integrity protection. [[anchor21: Why do we want padata in arbitrary
-   error responses?  What if the KDC cannot generate a fast reply
-   because for example no armor nor state cookie was included in a
-   request?  Also, we need to confirm that the WG is OK with a pre-
-   authentication specification changing error returns for unrelated
-   errors.]]
-
-       TD_FX_FAST                         TBA
-           -- Typed data element type for Kerberos FAST
-
-6.6.  Authentication Strength Indication
-
-   Implementations that have pre-authentication mechanisms offering
-   significantly different strengths of client authentication MAY choose
-   to keep track of the strength of the authentication used as an input
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 28]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-   into policy decisions.  For example, some principals might require
-   strong pre-authentication, while less sensitive principals can use
-   relatively weak forms of pre-authentication like encrypted timestamp.
-
-   An AuthorizationData data type AD-Authentication-Strength is defined
-   for this purpose.
-
-       AD-authentication-strength         TBA
-
-   The corresponding ad-data field contains the DER encoding of the pre-
-   authentication data set as defined in Section 6.4.  This set contains
-   all the pre-authentication mechanisms that were used to authenticate
-   the client.  If only one pre-authentication mechanism was used to
-   authenticate the client, the pre-authentication set contains one
-   element.
-
-   The AD-authentication-strength element MUST be included in the AD-IF-
-   RELEVANT, thus it can be ignored if it is unknown to the receiver.
-
-
-7.  IANA Considerations
-
-   This document defines FAST factors, these are mini- and light-
-   weighted- pre-authentication mechanisms.  A new IANA registry should
-   be setup for registering FAST factor IDs.  The evaluation policy is
-   "Specification Required".
-
-
-8.  Security Considerations
-
-   The kdc-referrals option in the Kerberos FAST padata requests the KDC
-   to act as the client to follow referrals.  This can overload the KDC.
-   To limit the damages of denied of service using this option, KDCs MAY
-   restrict the number of simultaneous active requests with this option
-   for any given client principal.
-
-   Because the client secrets are known only to the client and the KDC,
-   the verification of the encrypted timestamp proves the client's
-   identity, the verification of the encrypted rep-key-package in the
-   KDC reply proves that the expected KDC responded.  The encrypted
-   reply key is contained in the rep-key-package in the PA-FX-FAST-
-   REPLY.  Therefore, the encrypted timestamp FAST factor as a pre-
-   authentication mechanism offers the following facilities: client-
-   authentication, replacing-reply-key, KDC-authentication.  There is no
-   un-authenticated clear text introduced by the encrypted timestamp
-   FAST factor.
-
-
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 29]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-9.  Acknowledgements
-
-   Several suggestions from Jeffery Hutzman based on early revisions of
-   this documents led to significant improvements of this document.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity 
-              Support", draft-ietf-krb-wg-anon, work in progress.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [REFERALS] Raeburn, K. et al, "Generating KDC Referrals to Locate 
-              Kerberos Realms", draft-ietf-krb-wg-kerberos-referrals, 
-              work in progress.
-
-   [SHA2]     National Institute of Standards and Technology, "Secure 
-              Hash Standard (SHS)", Federal Information Processing 
-              Standards Publication 180-2, August 2002.  
-
-   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
-              Information technology - Abstract Syntax Notation One
-              (ASN.1): Specification of basic notation.
-   
-   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
-              Information technology - ASN.1 encoding Rules:
-              Specification of Basic Encoding Rules (BER), Canonical
-              Encoding Rules (CER) and Distinguished Encoding Rules
-              (DER).
-
-10.2.  Informative References
-
-   [EKE]      Bellovin, S. M. and M. Merritt. "Augmented 
-              Encrypted Key Exchange: A Password-Based Protocol Secure 
-              Against Dictionary Attacks and Password File Compromise". 
-              Proceedings of the 1st ACM Conference on Computer and 
-              Communications Security, ACM Press, November 1993.
-   
-   [HKDF]     Dang, Q. and P. Polk, draft-dang-nistkdf, work in 
-              progress.
-
-   [IEEE1363.2] 
-              IEEE P1363.2: Password-Based Public-Key Cryptography, 
-              2004.
-
-   [KRB-WG.SAM]
-              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
-              "Integrating Single-use Authentication Mechanisms with
-              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
-              progress), October 2003.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-
-Appendix A.  ASN.1 module
-
-     KerberosPreauthFramework {
-            iso(1) identified-organization(3) dod(6) internet(1)
-            security(5) kerberosV5(2) modules(4) preauth-framework(3)
-     } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-     IMPORTS
-           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
-           Int32, EncryptedData, PA-DATA
-                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                  dod(6) internet(1) security(5) kerberosV5(2)
-                  modules(4) krb5spec2(2) };
-                  -- as defined in RFC 4120.
-
-     PA-FX-COOKIE ::= SEQUENCE {
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 30]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-         Cookie            [1] OCTET STRING,
-             -- Opaque data, for use to associate all the messages in a
-             -- single conversation between the client and the KDC.
-             -- This can be generated by either the client or the KDC.
-             -- The receiver MUST copy the exact Cookie encapsulated in
-             -- a PA_FX_COOKIE data element into the next message of the
-             -- same conversation.
-         ...
-     }
-
-     PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-     PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-         pa-type           [1] Int32,
-             -- same as padata-type.
-         pa-hint           [2] OCTET STRING,
-             -- hint data.
-         ...
-     }
-
-     PA-FX-FAST-REQUEST ::= CHOICE {
-         armored-data      [1] KrbFastAmoredReq,
-         ...
-     }
-
-     KrbFastAmoredReq ::= SEQUENCE {
-         armor             [1] KrbFastArmor OPTIONAL,
-             -- Contains the armor that determines the armor key.
-             -- MUST be present in AS-REQ.
-             -- MUST be absent in TGS-REQ.
-         req-checksum      [2] Checksum,
-             -- Checksum performed over the type KDC-REQ-BODY.
-             -- The checksum key is the armor key, the checksum
-             -- type is the required checksum type for the enctype of
-             -- the armor key, and the key usage number is
-             -- KEY_USAGE_FAST_REA_CHKSUM.
-         enc-fast-req      [3] EncryptedData, -- KrbFastReq --
-             -- The encryption key is the armor key, and the key usage
-             -- number is KEY_USAGE_FAST_ENC.
-         ...
-     }
-
-     KrbFastArmor ::= SEQUENCE {
-         armor-type        [1] Int32,
-             -- Type of the armor.
-         armor-value       [2] OCTET STRING,
-             -- Value of the armor.
-         ...
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 31]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-     }
-
-     KrbFastReq ::= SEQUENCE {
-         fast-options      [0] FastOptions,
-             -- Additional options.
-         padata            [1] SEQUENCE OF PA-DATA,
-             -- padata typed holes.
-         crealm            [2] Realm OPTIONAL,
-         cname             [3] PrincipalName OPTIONAL,
-             -- Contains the client realm and the client name.
-             -- If present, the client name and realm in the
-             -- AS_REQ KDC-REQ-BODY [RFC4120] MUST be ignored.
-         ...
-     }
-
-     FastOptions ::= KerberosFlags
-         -- reserved(0),
-         -- anonymous(1),
-         -- kdc-referrals(16)
-
-     PA-FX-FAST-REPLY ::= CHOICE {
-         armored-data      [1] KrbFastArmoredRep,
-         ...
-     }
-
-     KrbFastArmoredRep ::= SEQUENCE {
-         enc-fast-rep      [1] EncryptedData, -- KrbFastResponse --
-             -- The encryption key is the armor key in the request, and
-             -- the key usage number is KEY_USAGE_FAST_REP.
-         ...
-     }
-
-     KrbFastResponse ::= SEQUENCE {
-         padata            [1] SEQUENCE OF PA-DATA,
-             -- padata typed holes.
-         finished          [2] KrbFastFinished OPTIONAL,
-             -- MUST be present if the client is authenticated,
-             -- absent otherwise.
-             -- Typically this is present if and only if the containing
-             -- message is the last one in a conversation.
-         ...
-     }
-
-     KrbFastFinished ::= SEQUENCE {
-         timestamp         [1] KerberosTime,
-         usec              [2] Microseconds,
-             -- timestamp and usec represent the time on the KDC when
-             -- the reply was generated.
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 32]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-         rep-key-package   [3]  EncryptedData OPTIONAL,
-                       -- EncryptionKey --
-             -- This, if present, replaces the reply key for AS and TGS.
-             -- The encryption key is the client key, unless otherwise
-             -- specified. The key usage number is
-             -- KEY_USAGE_FAST_FINISHED.
-         crealm            [4] Realm,
-         cname             [5] PrincipalName,
-             -- Contains the client realm and the client name.
-         checksum          [6] Checksum,
-             -- Checksum performed over all the messages in the
-             -- conversation, except the containing message.
-             -- The checksum key is the ticket session key of the reply
-             -- ticket, and the checksum type is the required checksum
-             -- type of that key.
-         ...
-     }
-     END
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Sam hartman
-   MIT
-
-   Email: hartmans@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 33]
-
-Internet-Draft         Kerberos Preauth Framework             March 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Zhu & Hartman           Expires September 6, 2007              [Page 34]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-06.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-06.txt
deleted file mode 100644
index 7df5301bd..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-06.txt
+++ /dev/null
@@ -1,2184 +0,0 @@
-
-
-
-Kerberos Working Group                                            L. Zhu
-Internet-Draft                                     Microsoft Corporation
-Updates: 4120 (if approved)                                   S. Hartman
-Intended status: Standards Track                                     MIT
-Expires: January 9, 2008                                    July 8, 2007
-
-
-        A Generalized Framework for Kerberos Pre-Authentication
-                 draft-ietf-krb-wg-preauth-framework-06
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 9, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   Kerberos is a protocol for verifying the identity of principals
-   (e.g., a workstation user or a network server) on an open network.
-   The Kerberos protocol provides a mechanism called pre-authentication
-   for proving the identity of a principal and for better protecting the
-   long-term secret of the principal.
-
-   This document describes a model for Kerberos pre-authentication
-
-
-
-Zhu & Hartman            Expires January 9, 2008                [Page 1]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   mechanisms.  The model describes what state in the Kerberos request a
-   pre-authentication mechanism is likely to change.  It also describes
-   how multiple pre-authentication mechanisms used in the same request
-   will interact.
-
-   This document also provides common tools needed by multiple pre-
-   authentication mechanisms.  One of these tools is a secure channel
-   between the client and the KDC with a reply key delivery mechanism;
-   this secure channel can be used to protect the authentication
-   exchange thus eliminate offline dictionary attacks.  With these
-   tools, it is relatively straightforward to chain multiple
-   authentication mechanisms, utilize a different key management system,
-   or support a new key agreement algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Hartman            Expires January 9, 2008                [Page 2]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Conventions and Terminology Used in This Document  . . . . . .  5
-   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  5
-     3.1.  Information Managed by the Pre-authentication Model  . . .  6
-     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  8
-     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . .  9
-     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 10
-   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 10
-     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 12
-     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 12
-     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 13
-     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 14
-   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 14
-   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15
-     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 15
-     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 16
-     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 17
-     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 19
-     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 21
-       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 22
-       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 23
-       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 27
-       6.5.4.  Authenticated Kerberos Error Messages using
-               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 29
-       6.5.5.  The Authenticated Timestamp FAST Factor  . . . . . . . 30
-     6.6.  Authentication Strength Indication . . . . . . . . . . . . 32
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 34
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 34
-   Appendix A.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 35
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
-   Intellectual Property and Copyright Statements . . . . . . . . . . 39
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Hartman            Expires January 9, 2008                [Page 3]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-1.  Introduction
-
-   The core Kerberos specification [RFC4120] treats pre-authentication
-   data as an opaque typed hole in the messages to the KDC that may
-   influence the reply key used to encrypt the KDC reply.  This
-   generality has been useful: pre-authentication data is used for a
-   variety of extensions to the protocol, many outside the expectations
-   of the initial designers.  However, this generality makes designing
-   more common types of pre-authentication mechanisms difficult.  Each
-   mechanism needs to specify how it interacts with other mechanisms.
-   Also, problems like combining a key with the long-term secret or
-   proving the identity of the user are common to multiple mechanisms.
-   Where there are generally well-accepted solutions to these problems,
-   it is desirable to standardize one of these solutions so mechanisms
-   can avoid duplication of work.  In other cases, a modular approach to
-   these problems is appropriate.  The modular approach will allow new
-   and better solutions to common pre-authentication problems to be used
-   by existing mechanisms as they are developed.
-
-   This document specifies a framework for Kerberos pre-authentication
-   mechanisms.  It defines the common set of functions that pre-
-   authentication mechanisms perform as well as how these functions
-   affect the state of the request and reply.  In addition several
-   common tools needed by pre-authentication mechanisms are provided.
-   Unlike [RFC3961], this framework is not complete--it does not
-   describe all the inputs and outputs for the pre-authentication
-   mechanisms.  Pre-Authentication mechanism designers should try to be
-   consistent with this framework because doing so will make their
-   mechanisms easier to implement.  Kerberos implementations are likely
-   to have plugin architectures for pre-authentication; such
-   architectures are likely to support mechanisms that follow this
-   framework plus commonly used extensions.
-
-   One of these common tools is the flexible authentication secure
-   tunneling (FAST) padata type.  FAST provides a protected channel
-   between the client and the KDC, and it can optionally deliver a reply
-   key within the protected channel.  Based on FAST, pre-authentication
-   mechanisms can extend Kerberos with ease, to support, for example,
-   password authenticated key exchange (PAKE) protocols with zero
-   knowledge password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-
-   authentication mechanism can be encapsulated in the FAST messages as
-   defined in Section 6.5.  A pre-authentication type carried within
-   FAST is called a FAST factor.  Creating a FAST factor is the easiest
-   path to create a new pre-authentication mechanism.  FAST factors are
-   significantly easier to analyze from a security standpoint than other
-   pre-authentication mechanisms.
-
-   Mechanism designers should design FAST factors, instead of new pre-
-
-
-
-Zhu & Hartman            Expires January 9, 2008                [Page 4]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   authentication mechanisms outside of FAST.
-
-
-2.  Conventions and Terminology Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   The word padata is used as a shorthand for pre-authentication data.
-
-   A conversation is the set of all authentication messages exchanged
-   between the client and the KDCs in order to authenticate the client
-   principal.  A conversation as defined here consists of all messages
-   that are necessary to complete the authentication between the client
-   and the KDC.
-
-   Lastly, this document should be read only after reading the documents
-   describing the Kerberos cryptography framework [RFC3961] and the core
-   Kerberos protocol [RFC4120].  This document may freely use
-   terminology and notation from these documents without reference or
-   further explanation.
-
-
-3.  Model for Pre-Authentication
-
-   When a Kerberos client wishes to obtain a ticket using the
-   authentication server, it sends an initial Authentication Service
-   (AS) request.  If pre-authentication is required but not being used,
-   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
-   Alternatively, if the client knows what pre-authentication to use, it
-   MAY optimize away a round-trip and send an initial request with
-   padata included in the initial request.  If the client includes the
-   padata computed using the wrong pre-authentication mechanism or
-   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
-   indication of what padata should have been included.  In that case,
-   the client MUST retry with no padata and examine the error data of
-   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
-   authentication information in the accompanying error data of
-   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
-   then retry.
-
-   The conventional KDC maintains no state between two requests;
-   subsequent requests may even be processed by a different KDC.  On the
-   other hand, the client treats a series of exchanges with KDCs as a
-   single conversation.  Each exchange accumulates state and hopefully
-   brings the client closer to a successful authentication.
-
-
-
-
-Zhu & Hartman            Expires January 9, 2008                [Page 5]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   These models for state management are in apparent conflict.  For many
-   of the simpler pre-authentication scenarios, the client uses one
-   round trip to find out what mechanisms the KDC supports.  Then the
-   next request contains sufficient pre-authentication for the KDC to be
-   able to return a successful reply.  For these simple scenarios, the
-   client only sends one request with pre-authentication data and so the
-   conversation is trivial.  For more complex conversations, the KDC
-   needs to provide the client with a cookie to include in future
-   requests to capture the current state of the authentication session.
-   Handling of multiple round-trip mechanisms is discussed in
-   Section 6.3.
-
-   This framework specifies the behavior of Kerberos pre-authentication
-   mechanisms used to identify users or to modify the reply key used to
-   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
-   extensions to Kerberos that have nothing to do with proving the
-   identity of the user or establishing a reply key.  Such extensions
-   are outside the scope of this framework.  However mechanisms that do
-   accomplish these goals should follow this framework.
-
-   This framework specifies the minimum state that a Kerberos
-   implementation needs to maintain while handling a request in order to
-   process pre-authentication.  It also specifies how Kerberos
-   implementations process the padata at each step of the AS request
-   process.
-
-3.1.  Information Managed by the Pre-authentication Model
-
-   The following information is maintained by the client and KDC as each
-   request is being processed:
-
-   o  The reply key used to encrypt the KDC reply
-
-   o  How strongly the identity of the client has been authenticated
-
-   o  Whether the reply key has been used in this conversation
-
-   o  Whether the reply key has been replaced in this conversation
-
-   o  Whether the contents of the KDC reply can be verified by the
-      client principal
-
-
-   Conceptually, the reply key is initially the long-term key of the
-   principal.  However, principals can have multiple long-term keys
-   because of support for multiple encryption types, salts and
-   string2key parameters.  As described in Section 5.2.7.5 of the
-   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
-
-
-
-Zhu & Hartman            Expires January 9, 2008                [Page 6]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   the client what types of keys are available.  Thus in full
-   generality, the reply key in the pre-authentication model is actually
-   a set of keys.  At the beginning of a request, it is initialized to
-   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
-   the KDC.  If multiple reply keys are available, the client chooses
-   which one to use.  Thus the client does not need to treat the reply
-   key as a set.  At the beginning of a request, the client picks a
-   reply key to use.
-
-   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
-   INFO2 element.  Since the KDC already knows the client's list of
-   supported enctypes from the request, no interoperability problems are
-   created by choosing a single possible reply key.  This way, the KDC
-   implementation avoids the complexity of treating the reply key as a
-   set.
-
-   When the padata in the request is verified by the KDC, then the
-   client is known to have that key, therefore the KDC SHOULD pick the
-   same key as the reply key.
-
-   At the beginning of handling a message on both the client and the
-   KDC, the client's identity is not authenticated.  A mechanism may
-   indicate that it has successfully authenticated the client's
-   identity.  This information is useful to keep track of on the client
-   in order to know what pre-authentication mechanisms should be used.
-   The KDC needs to keep track of whether the client is authenticated
-   because the primary purpose of pre-authentication is to authenticate
-   the client identity before issuing a ticket.  The handling of
-   authentication strength using various authentication mechanisms is
-   discussed in Section 6.6.
-
-   Initially the reply key has not been used.  A pre-authentication
-   mechanism that uses the reply key to encrypt or checksum some data in
-   the generation of new keys MUST indicate that the reply key is used.
-   This state is maintained by the client and the KDC to enforce the
-   security requirement stated in Section 4.3 that the reply key cannot
-   be replaced after it is used.
-
-   Initially the reply key has not been replaced.  If a mechanism
-   implements the Replace Reply Key facility discussed in Section 4.3,
-   then the state MUST be updated to indicate that the reply key has
-   been replaced.  Once the reply key has been replaced, knowledge of
-   the reply key is insufficient to authenticate the client.  The reply
-   key is marked replaced in exactly the same situations as the KDC
-   reply is marked as not being verified to the client principal.
-   However, while mechanisms can verify the KDC reply to the client,
-   once the reply key is replaced, then the reply key remains replaced
-   for the remainder of the conversation.
-
-
-
-Zhu & Hartman            Expires January 9, 2008                [Page 7]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   Without pre-authentication, the client knows that the KDC reply is
-   authentic and has not been modified because it is encrypted in a
-   long-term key of the client.  Only the KDC and the client know that
-   key.  So at the start of handling any message the KDC reply is
-   presumed to be verified using the client principal's long-term key.
-   Any pre-authentication mechanism that sets a new reply key not based
-   on the principal's long-term secret MUST either verify the KDC reply
-   some other way or indicate that the reply is not verified.  If a
-   mechanism indicates that the reply is not verified then the client
-   implementation MUST return an error unless a subsequent mechanism
-   verifies the reply.  The KDC needs to track this state so it can
-   avoid generating a reply that is not verified.
-
-   The typical Kerberos request does not provide a way for the client
-   machine to know that it is talking to the correct KDC.  Someone who
-   can inject packets into the network between the client machine and
-   the KDC and who knows the password that the user will give to the
-   client machine can generate a KDC reply that will decrypt properly.
-   So, if the client machine needs to authenticate that the user is in
-   fact the named principal, then the client machine needs to do a TGS
-   request for itself as a service.  Some pre-authentication mechanisms
-   may provide a way for the client to authenticate the KDC.  Examples
-   of this include signing the reply that can be verified using a well-
-   known public key or providing a ticket for the client machine as a
-   service.
-
-3.2.  Initial Pre-authentication Required Error
-
-   Typically a client starts a conversation by sending an initial
-   request with no pre-authentication.  If the KDC requires pre-
-   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
-   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
-   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
-   (defined in Section 6.3) for pre-authentication configurations that
-   use multi-round-trip mechanisms; see Section 3.4 for details of that
-   case.
-
-   The KDC needs to choose which mechanisms to offer the client.  The
-   client needs to be able to choose what mechanisms to use from the
-   first message.  For example consider the KDC that will accept
-   mechanism A followed by mechanism B or alternatively the single
-   mechanism C. A client that supports A and C needs to know that it
-   should not bother trying A.
-
-   Mechanisms can either be sufficient on their own or can be part of an
-   authentication set--a group of mechanisms that all need to
-   successfully complete in order to authenticate a client.  Some
-   mechanisms may only be useful in authentication sets; others may be
-
-
-
-Zhu & Hartman            Expires January 9, 2008                [Page 8]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   useful alone or in authentication sets.  For the second group of
-   mechanisms, KDC policy dictates whether the mechanism will be part of
-   an authentication set or offered alone.  For each mechanism that is
-   offered alone, the KDC includes the pre-authentication type ID of the
-   mechanism in the padata sequence returned in the
-   KDC_ERR_PREAUTH_REQUIRED error.
-
-   The KDC SHOULD NOT send data that is encrypted in the long-term
-   password-based key of the principal.  Doing so has the same security
-   exposures as the Kerberos protocol without pre-authentication.  There
-   are few situations where pre-authentication is desirable and where
-   the KDC needs to expose cipher text encrypted in a weak key before
-   the client has proven knowledge of that key.
-
-3.3.  Client to KDC
-
-   This description assumes that a client has already received a
-   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
-   optimistic pre-authentication then the client needs to optimistically
-   guess values for the information it would normally receive from that
-   error response.
-
-   The client starts by initializing the pre-authentication state as
-   specified.  It then processes the padata in the
-   KDC_ERR_PREAUTH_REQUIRED.
-
-   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
-   client MAY ignore any padata it chooses unless doing so violates a
-   specification to which the client conforms.  Clients conforming to
-   this specification MUST NOT ignore the padata defined in Section 6.3.
-   Clients SHOULD process padata unrelated to this framework or other
-   means of authenticating the user.  Clients SHOULD choose one
-   authentication set or mechanism that could lead to authenticating the
-   user and ignore the rest.  Since the list of mechanisms offered by
-   the KDC is in the decreasing preference order, clients typically
-   choose the first mechanism or authentication set that the client can
-   usefully perform.  If a client chooses to ignore a padata it MUST NOT
-   process the padata, allow the padata to affect the pre-authentication
-   state, nor respond to the padata.
-
-   For each padata the client chooses to process, the client processes
-   the padata and modifies the pre-authentication state as required by
-   that mechanism.  Padata are processed in the order received from the
-   KDC.
-
-   After processing the padata in the KDC error, the client generates a
-   new request.  It processes the pre-authentication mechanisms in the
-   order in which they will appear in the next request, updating the
-
-
-
-Zhu & Hartman            Expires January 9, 2008                [Page 9]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   state as appropriate.  The request is sent when it is complete.
-
-3.4.  KDC to Client
-
-   When a KDC receives an AS request from a client, it needs to
-   determine whether it will respond with an error or an AS reply.
-   There are many causes for an error to be generated that have nothing
-   to do with pre-authentication; they are discussed in the core
-   Kerberos specification.
-
-   From the standpoint of evaluating the pre-authentication, the KDC
-   first starts by initializing the pre-authentication state.  It then
-   processes the padata in the request.  As mentioned in Section 3.3,
-   the KDC MAY ignore padata that is inappropriate for the configuration
-   and MUST ignore padata of an unknown type.
-
-   At this point the KDC decides whether it will issue a pre-
-   authentication required error or a reply.  Typically a KDC will issue
-   a reply if the client's identity has been authenticated to a
-   sufficient degree.
-
-   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC
-   first starts by initializing the pre-authentication state.  Then it
-   processes any padata in the client's request in the order provided by
-   the client.  Mechanisms that are not understood by the KDC are
-   ignored.  Mechanisms that are inappropriate for the client principal
-   or the request SHOULD also be ignored.  Next, it generates padata for
-   the error response, modifying the pre-authentication state
-   appropriately as each mechanism is processed.  The KDC chooses the
-   order in which it will generate padata (and thus the order of padata
-   in the response), but it needs to modify the pre-authentication state
-   consistently with the choice of order.  For example, if some
-   mechanism establishes an authenticated client identity, then the
-   subsequent mechanisms in the generated response receive this state as
-   input.  After the padata is generated, the error response is sent.
-   Typically the errors with the code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
-   in a converstation will include KDC state as discussed in
-   Section 6.3.
-
-   To generate a final reply, the KDC generates the padata modifying the
-   pre-authentication state as necessary.  Then it generates the final
-   response, encrypting it in the current pre-authentication reply key.
-
-
-4.  Pre-Authentication Facilities
-
-   Pre-Authentication mechanisms can be thought of as providing various
-   conceptual facilities.  This serves two useful purposes.  First,
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 10]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   mechanism authors can choose only to solve one specific small
-   problem.  It is often useful for a mechanism designed to offer key
-   management not to directly provide client authentication but instead
-   to allow one or more other mechanisms to handle this need.  Secondly,
-   thinking about the abstract services that a mechanism provides yields
-   a minimum set of security requirements that all mechanisms providing
-   that facility must meet.  These security requirements are not
-   complete; mechanisms will have additional security requirements based
-   on the specific protocol they employ.
-
-   A mechanism is not constrained to only offering one of these
-   facilities.  While such mechanisms can be designed and are sometimes
-   useful, many pre-authentication mechanisms implement several
-   facilities.  By combining multiple facilities in a single mechanism,
-   it is often easier to construct a secure, simple solution than by
-   solving the problem in full generality.  Even when mechanisms provide
-   multiple facilities, they need to meet the security requirements for
-   all the facilities they provide.  If the FAST factor approach is
-   used, it is likely that one or a small number of facilities can be
-   provided by a single mechanism without complicating the security
-   analysis.
-
-   According to Kerberos extensibility rules (Section 1.5 of the
-   Kerberos specification [RFC4120]), an extension MUST NOT change the
-   semantics of a message unless a recipient is known to understand that
-   extension.  Because a client does not know that the KDC supports a
-   particular pre-authentication mechanism when it sends an initial
-   request, a pre-authentication mechanism MUST NOT change the semantics
-   of the request in a way that will break a KDC that does not
-   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
-   clients that affect the core semantics unless the client has
-   indicated support for the message.
-
-   The only state in this model that would break the interpretation of a
-   message is changing the expected reply key.  If one mechanism changed
-   the reply key and a later mechanism used that reply key, then a KDC
-   that interpreted the second mechanism but not the first would fail to
-   interpret the request correctly.  In order to avoid this problem,
-   extensions that change core semantics are typically divided into two
-   parts.  The first part proposes a change to the core semantic--for
-   example proposes a new reply key.  The second part acknowledges that
-   the extension is understood and that the change takes effect.
-   Section 4.2 discusses how to design mechanisms that modify the reply
-   key to be split into a proposal and acceptance without requiring
-   additional round trips to use the new reply key in subsequent pre-
-   authentication.  Other changes in the state described in Section 3.1
-   can safely be ignored by a KDC that does not understand a mechanism.
-   Mechanisms that modify the behavior of the request outside the scope
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 11]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   of this framework need to carefully consider the Kerberos
-   extensibility rules to avoid similar problems.
-
-4.1.  Client-authentication Facility
-
-   The client authentication facility proves the identity of a user to
-   the KDC before a ticket is issued.  Examples of mechanisms
-   implementing this facility include the encrypted timestamp facility
-   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
-   Mechanisms that provide this facility are expected to mark the client
-   as authenticated.
-
-   Mechanisms implementing this facility SHOULD require the client to
-   prove knowledge of the reply key before transmitting a successful KDC
-   reply.  Otherwise, an attacker can intercept the pre-authentication
-   exchange and get a reply to attack.  One way of proving the client
-   knows the reply key is to implement the Replace Reply Key facility
-   along with this facility.  The PKINIT mechanism [RFC4556] implements
-   Client Authentication alongside Replace Reply Key.
-
-   If the reply key has been replaced, then mechanisms such as
-   encrypted-timestamp that rely on knowledge of the reply key to
-   authenticate the client MUST NOT be used.
-
-4.2.  Strengthening-reply-key Facility
-
-   Particularly, when dealing with keys based on passwords, it is
-   desirable to increase the strength of the key by adding additional
-   secrets to it.  Examples of sources of additional secrets include the
-   results of a Diffie-Hellman key exchange or key bits from the output
-   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
-   be first combined with the existing reply key and then converted to a
-   protocol key using tools defined in Section 6.1.
-
-   If a mechanism implementing this facility wishes to modify the reply
-   key before knowing that the other party in the exchange supports the
-   mechanism, it proposes modifying the reply key.  The other party then
-   includes a message indicating that the proposal is accepted if it is
-   understood and meets policy.  In many cases it is desirable to use
-   the new reply key for client authentication and for other facilities.
-   Waiting for the other party to accept the proposal and actually
-   modify the reply key state would add an additional round trip to the
-   exchange.  Instead, mechanism designers are encouraged to include a
-   typed hole for additional padata in the message that proposes the
-   reply key change.  The padata included in the typed hole are
-   generated assuming the new reply key.  If the other party accepts the
-   proposal, then these padata are considered as an inner level.  As
-   with the outer level, one authentication set or mechanism is
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 12]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   typically chosen for client authentication, along with auxiliary
-   mechanisms such as KDC cookies, and other mechanisms are ignored.
-   [[anchor5: Containers like this need more thought.  For example if
-   you are constructing an authentication set do you expect to use a
-   strengthen reply key mechanism in conjunction with something else, do
-   you include the something else in the hint of the strengthen
-   mechanism or as its own entry.  It's easier to configure and express
-   the authentication set as its own entry.  However if you do that' the
-   composition of the mechanisms looks in practice than it appears in
-   the authentication set.]]  The party generating the proposal can
-   determine whether the padata were processed based on whether the
-   proposal for the reply key is accepted.
-
-   The specific formats of the proposal message, including where padata
-   are included is a matter for the mechanism specification.  Similarly,
-   the format of the message accepting the proposal is mechanism-
-   specific.
-
-   Mechanisms implementing this facility and including a typed hole for
-   additional padata MUST checksum that padata using a keyed checksum or
-   encrypt the padata.  This requirement protects against modification
-   of the contents of the typed hole.  By modifying these contents an
-   attacker might be able to choose which mechanism is used to
-   authenticate the client, or to convince a party to provide text
-   encrypted in a key that the attacker had manipulated.  It is
-   important that mechanisms strengthen the reply key enough that using
-   it to checksum padata is appropriate.
-
-4.3.  Replacing-reply-key Facility
-
-   The Replace Reply Key facility replaces the key in which a successful
-   AS reply will be encrypted.  This facility can only be used in cases
-   where knowledge of the reply key is not used to authenticate the
-   client.  The new reply key MUST be communicated to the client and the
-   KDC in a secure manner.  Mechanisms implementing this facility MUST
-   mark the reply key as replaced in the pre-authentication state.
-   Mechanisms implementing this facility MUST either provide a mechanism
-   to verify the KDC reply to the client or mark the reply as unverified
-   in the pre-authentication state.  Mechanisms implementing this
-   facility SHOULD NOT be used if a previous mechanism has used the
-   reply key.
-
-   As with the strengthening-reply-key facility, Kerberos extensibility
-   rules require that the reply key not be changed unless both sides of
-   the exchange understand the extension.  In the case of this facility
-   it will likely be more common for both sides to know that the
-   facility is available by the time that the new key is available to be
-   used.  However, mechanism designers can use a container for padata in
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 13]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   a proposal message as discussed in Section 4.2 if appropriate.
-
-4.4.  KDC-authentication Facility
-
-   This facility verifies that the reply comes from the expected KDC.
-   In traditional Kerberos, the KDC and the client share a key, so if
-   the KDC reply can be decrypted then the client knows that a trusted
-   KDC responded.  Note that the client machine cannot trust the client
-   unless the machine is presented with a service ticket for it
-   (typically the machine can retrieve this ticket by itself).  However,
-   if the reply key is replaced, some mechanism is required to verify
-   the KDC.  Pre-authentication mechanisms providing this facility allow
-   a client to determine that the expected KDC has responded even after
-   the reply key is replaced.  They mark the pre-authentication state as
-   having been verified.
-
-
-5.  Requirements for Pre-Authentication Mechanisms
-
-   This section lists requirements for specifications of pre-
-   authentication mechanisms.
-
-   For each message in the pre-authentication mechanism, the
-   specification describes the pa-type value to be used and the contents
-   of the message.  The processing of the message by the sender and
-   recipient is also specified.  This specification needs to include all
-   modifications to the pre-authentication state.
-
-   Generally mechanisms have a message that can be sent in the error
-   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
-   authentication set.  If the client needs information such as trusted
-   certificate authorities in order to determine if it can use the
-   mechanism, then this information should be in that message.  In
-   addition, such mechanisms should also define a pa-hint to be included
-   in authentication sets.  Often, the same information included in the
-   padata-value is appropriate to include in the pa-hint (as defined in
-   Section 6.4).
-
-   In order to ease security analysis the mechanism specification should
-   describe what facilities from this document are offered by the
-   mechanism.  For each facility, the security consideration section of
-   the mechanism specification should show that the security
-   requirements of that facility are met.  This requirement is
-   applicable to any FAST factor that provides authentication
-   information.
-
-   Significant problems have resulted in the specification of Kerberos
-   protocols because much of the KDC exchange is not protected against
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 14]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   authentication.  The security considerations section should discuss
-   unauthenticated plaintext attacks.  It should either show that
-   plaintext is protected or discuss what harm an attacker could do by
-   modifying the plaintext.  It is generally acceptable for an attacker
-   to be able to cause the protocol negotiation to fail by modifying
-   plaintext.  More significant attacks should be evaluated carefully.
-
-   As discussed in Section 6.3, there is no guarantee that a client will
-   use the same KDCs for all messages in a conversation.  The mechanism
-   specification needs to show why the mechanism is secure in this
-   situation.  The hardest problem to deal with, especially for
-   challenge/response mechanisms is to make sure that the same response
-   cannot be replayed against two KDCs while allowing the client to talk
-   to any KDC.
-
-
-6.  Tools for Use in Pre-Authentication Mechanisms
-
-   This section describes common tools needed by multiple pre-
-   authentication mechanisms.  By using these tools mechanism designers
-   can use a modular approach to specify mechanism details and ease
-   security analysis.
-
-6.1.  Combining Keys
-
-   Frequently a weak key needs to be combined with a stronger key before
-   use.  For example, passwords are typically limited in size and
-   insufficiently random, therefore it is desirable to increase the
-   strength of the keys based on passwords by adding additional secrets.
-   Additional source of secrecy may come from hardware tokens.
-
-   This section provides standard ways to combine two keys into one.
-
-   KRB-FX-CF1() is defined to combine two pass-phrases.
-
-       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
-       KRB-FX-CF1(x, y) -> x || y
-
-   Where || denotes concatenation.  The strength of the final key is
-   roughly the total strength of the individual keys being combined
-   assuming that the string_to_key() function [RFC3961] uses all its
-   input evenly.
-
-   An example usage of KRB-FX-CF1() is when a device provides random but
-   short passwords, the password is often combined with a personal
-   identification number (PIN).  The password and the PIN can be
-   combined using KRB-FX-CF1().
-
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 15]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
-   function defined in [RFC3961].
-
-   Given two input keys, K1 and K2, where K1 and K2 can be of two
-   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
-   follows:
-
-       KRB-FX-CF2(protocol key, protocol key, octet string,
-                 octet string)  ->  (protocol key)
-
-       PRF+(K1, pepper1) -> octet-string-1
-       PRF+(K2, pepper2) -> octet-string-2
-       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
-              random-to-key(octet-string-1 ^ octet-string-2)
-
-   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
-   follows:
-
-    PRF+(protocol key, octet string) -> (octet string)
-
-    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
-                  pseudo-random( key, 2 || shared-info ) ||
-                  pseudo-random( key, 3 || shared-info ) || ...
-
-   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
-   integer.  The pseudo-random() operation is specified by the enctype
-   of the protocol key.  PRF+() uses the counter to generate enough bits
-   as needed by the random-to-key() [RFC3961] function for the
-   encryption type specified for the resulting key; unneeded bits are
-   removed from the tail.
-
-   Mechanism designers MUST specify the values for the input parameter
-   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
-   pepper1 and pepper2 MUST be distinct so that if the two keys being
-   combined are the same, the resulting key is not a trivial key.
-
-6.2.  Protecting Requests/Responses
-
-   Mechanism designers SHOULD protect clear text portions of pre-
-   authentication data.  Various denial of service attacks and downgrade
-   attacks against Kerberos are possible unless plaintexts are somehow
-   protected against modification.  An early design goal of Kerberos
-   Version 5 [RFC4120] was to avoid encrypting more of the
-   authentication exchange that was required.  (Version 4 doubly-
-   encrypted the encrypted part of a ticket in a KDC reply, for
-   example.)  This minimization of encryption reduces the load on the
-   KDC and busy servers.  Also, during the initial design of Version 5,
-   the existence of legal restrictions on the export of cryptography
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 16]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   made it desirable to minimize of the number of uses of encryption in
-   the protocol.  Unfortunately, performing this minimization created
-   numerous instances of unauthenticated security-relevant plaintext
-   fields.
-
-   If there is more than one roundtrip for an authentication exchange,
-   mechanism designers need to allow either the client or the KDC to
-   provide a checksum of all the messages exchanged on the wire in the
-   conversation, and the checksum is then verified by the receiver.
-
-   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
-
-   Primitives defined in [RFC3961] are RECOMMENDED for integrity
-   protection and confidentiality.  Mechanisms based on these primitives
-   are crypto-agile as the result of using [RFC3961] along with
-   [RFC4120].  The advantage afforded by crypto-agility is the ability
-   to avoid a multi-year standardization and deployment cycle to fix a
-   problem that is specific to a particular algorithm, when real attacks
-   do arise against that algorithm.
-
-   Note that data used by FAST factors (defined in Section 6.5) is
-   encrypted in a protected channel, thus they do not share the un-
-   authenticated-text issues with mechanisms designed as full-blown pre-
-   authentication mechanisms.
-
-6.3.  Managing States for the KDC
-
-   Kerberos KDCs are stateless.  There is no requirement that clients
-   will choose the same KDC for the second request in a conversation.
-   Proxies or other intermediate nodes may also influence KDC selection.
-   So, each request from a client to a KDC must include sufficient
-   information that the KDC can regenerate any needed state.  This is
-   accomplished by giving the client a potentially long opaque cookie in
-   responses to include in future requests in the same conversation.
-   The KDC MAY respond that a conversation is too old and needs to
-   restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
-
-       KDC_ERR_PREAUTH_EXPIRED            TBA
-
-   When a client receives this error, the client SHOULD abort the
-   existing conversation, and restart a new one.
-
-   An example, where more than one message from the client is needed, is
-   when the client is authenticated based on a challenge-response
-   scheme.  In that case, the KDC needs to keep track of the challenge
-   issued for a client authentication request.
-
-   The PA-FX-COOKIE pdata type is defined in this section to facilitate
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 17]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   state management.  This padata is sent by the KDC when the KDC
-   requires state for a future transaction.  The client includes this
-   opaque token in the next message in the conversation.  The token may
-   be relatively large; clients MUST be prepared for tokens somewhat
-   larger than the size of all messages in a conversation.
-
-       PA_FX_COOKIE                       TBA
-           -- Stateless cookie that is not tied to a specific KDC.
-
-   The corresponding padata-value field [RFC4120] contains the
-   Distinguished Encoding Rules (DER) [X60] [X690] encoding of the
-   following Abstract Syntax Notation One (ASN.1) type PA-FX-COOKIE:
-
-      PA-FX-COOKIE ::= SEQUENCE {
-          conversationId  [0] OCTET STRING,
-             -- Contains the identifier of this conversation. This field
-             -- must contain the same value for all the messages
-             -- within the same conversation.
-          enc-binding-key [1] EncryptedData OPTIONAL,
-                          -- EncryptionKey --
-             -- This field is present when and only when a FAST
-             -- padata as defined in Section 6.5 is included.
-             -- The encrypted data, when decrypted, contains an
-             -- EncryptionKey structure.
-             -- This encryption key is encrypted using the armor key
-             -- (defined in Section 6.5.1), and the key usage for the
-             -- encryption is KEY_USAGE_FAST_BINDING_KEY.
-             -- Present only once in a converstation.
-          cookie          [2] OCTET STRING OPTIONAL,
-             -- Opaque data, for use to associate all the messages in
-             -- a single conversation between the client and the KDC.
-             -- This is generated by the KDC and the client MUST copy
-             -- the exact cookie encapsulated in a PA_FX_COOKIE data
-             -- element into the next message of the same conversation.
-          ...
-      }
-      KEY_USAGE_FAST_BINDING_KEY         TBA
-
-   The conversationId field contains a sufficiently-long rand number
-   that uniquely identifies the conversation.  If a PA_FX_COOKIE padata
-   is present in one message, a PA_FX_COOKIE structure MUST be present
-   in all subsequent messages of the same converstation between the
-   client and the KDC, with the same conversationId value.
-
-   The enc-binding-key field is present when and only when a FAST padata
-   (defined in Section 6.5) is included.  The enc-binding-key field is
-   present only once in a conversation.  It MUST be ignored if it is
-   present in a subsequent message of the same conversation.  The
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 18]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   encrypted data, when decrypted, contains an EncryptionKey structure
-   that is called the binding key.  The binding key is encrypted using
-   the armor key (defined in Section 6.5.1), and the key usage for the
-   encryption is KEY_USAGE_FAST_BINDING_KEY.
-
-   If a Kerberos FAST padata as defined in Section 6.5 is included in
-   one message, it MUST be included in all subsequent messages of the
-   same conversation.
-
-   When FAST padata as defined Section 6.5 is included, the PA-FX-COOKIE
-   padata MUST be included.
-
-   The cookie token is generated by the KDC and the client MUST copy the
-   exact cookie encapsulated in a PA_FX_COOKIE data element into the
-   next message of the same conversation.  The content of the cookie
-   field is a local matter of the KDC.  However the KDC MUST construct
-   the cookie token in such a manner that a malicious client cannot
-   subvert the authentication process by manipulating the token.  The
-   KDC implementation needs to consider expiration of tokens, key
-   rollover and other security issues in token design.  The content of
-   the cookie field is likely specific to the pre-authentication
-   mechanisms used to authenticate the client.  If a client
-   authentication response can be replayed to multiple KDCs via the
-   PA_FX_COOKIE mechanism, an expiration in the cookie is RECOMMENDED to
-   prevent the response being presented indefinitely.
-
-   If at least one more message for a mechanism or a mechanism set is
-   expected by the KDC, the KDC returns a
-   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA_FX_COOKIE to
-   identify the conversation with the client according to Section 6.5.4.
-
-        KDC_ERR_MORE_PREAUTH_DATA_NEEDED   TBA
-
-6.4.  Pre-authentication Set
-
-   If all mechanisms in a group need to successfully complete in order
-   to authenticate a client, the client and the KDC SHOULD use the
-   PA_AUTHENTICATION_SET padata element.
-
-   A PA_AUTHENTICATION_SET padata element contains the ASN.1 DER
-   encoding of the PA-AUTHENTICATION-SET structure:
-
-
-
-
-
-
-
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 19]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-            pa-type      [0] Int32,
-                -- same as padata-type.
-            pa-hint      [1] OCTET STRING,
-                -- hint data.
-            ...
-        }
-
-   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
-   contains the corresponding value of padata-type in PA-DATA [RFC4120].
-   Associated with the pa-type is a pa-hint, which is an octet-string
-   specified by the pre-authentication mechanism.  This hint may provide
-   information for the client which helps it determine whether the
-   mechanism can be used.  For example a public-key mechanism might
-   include the certificate authorities it trusts in the hint info.  Most
-   mechanisms today do not specify hint info; if a mechanism does not
-   specify hint info the KDC MUST NOT send a hint for that mechanism.
-   To allow future revisions of mechanism specifications to add hint
-   info, clients MUST ignore hint info received for mechanisms that the
-   client believes do not support hint info.  If a member of the pre-
-   authentication mechanism set that requires a challenge, a separate
-   padata that carries the challenge SHOULD be included along with the
-   pre-authentication set padata.
-
-   The PA-AUTHENTICATION-SET appears only in the first message from the
-   KDC to the client.  In particular, the client should not be prepared
-   for the future authentication mechanisms to change as the
-   conversation progresses. [[anchor9: I think this is correct; we
-   should discuss and if the WG agrees the text should reflect this.]]
-
-   When indicating which sets of pre-authentication mechanisms are
-   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
-   for each pre-authentication mechanism set.
-
-   The client sends the padata-value for the first mechanism it picks in
-   the pre-authentication set, when the first mechanism completes, the
-   client and the KDC will proceed with the second mechanism, and so on
-   until all mechanisms complete successfully.  The PA_FX_COOKIE as
-   defined in Section 6.3 MUST be sent by the KDC along with the first
-   message that contains a PA-AUTHENTICATION-SET, in order to keep track
-   of KDC states.
-
-   Before the authentication succeeds and a ticket is returned, the
-   message that the client sends is an AS_REQ and the message that the
-   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
-   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_NEEDED as defined
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 20]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   in Section 6.3 and the accompanying e-data contains the DER encoding
-   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
-   the METHOD-DATA.  If there is no padata, the e-data field is absent
-   in the KRB-ERROR message.
-
-   If one mechanism completes on the client side, and the client expects
-   the KDC to send the next padata for the next pre-authentication
-   mechanism before the authentication succeeds, the client sends an
-   AS_REQ with a padata of type PA_FX_HEARTBEAT.
-
-        PA_FX_HEARTBEAT                    TBA
-
-   The padata-value for the PA_FX_HEARTBEAT is empty.
-
-   If one mechanism completes on the KDC side, and the KDC expects the
-   client to send the next padata for the next pre-authentication
-   mechanism before the authentication succeeds, the KDC sends a KRB-
-   ERROR message with the code KDC_ERR_MORE_PREAUTH_DATA_NEEDED and
-   includes a padata of type PA_FX_HEARTBEAT.
-
-   [[anchor10: It's much easier to design UIs if you can determine ahead
-   of time what all the elements of your dialogue will need to be.  If
-   we mandate that the pa-hints need to be sufficient that you can
-   determine what information you will require from a user ahead of time
-   we can simplify the UI for login.  I propose that we make this
-   requirement.  WG agreement required.]]
-
-6.5.  Definition of Kerberos FAST Padata
-
-   As described in [RFC4120], Kerberos is vulnerable to offline
-   dictionary attacks.  An attacker can request an AS-REP and try
-   various passwords to see if they can decrypt the resulting ticket.
-   RFC 4120 provides the entrypted timestap pre-authentication method
-   that ameliorates the situation somewhat by requiring that an attacker
-   observe a successful authentication.  However stronger security is
-   desired in many environments.  The Kerberos FAST pre-authentication
-   padata defined in this section provides a tool to significantly
-   reduce vulnerability to offline dictionary attack.  When combined
-   with encrypted timestamp, FAST requires an attacker to mount a
-   successful man-in-the-middle attack to observe ciphertext.  When
-   combined with host keys, FAST can even protect against active
-   attacks.  FAST also provides solutions to common problems for pre-
-   authentication mechanisms such as binding of the request and the
-   reply, freshness guarantee of the authentication.  FAST itself,
-   however, does not authenticate the client or the KDC, instead, it
-   provides a typed hole to allow pre-authentication data be tunneled.
-   A pre-authentication data element used within FAST is called a FAST
-   factor.  A FAST factor captures the minimal work required for
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 21]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   extending Kerberos to support a new pre-authentication scheme.
-
-   A FAST factor MUST NOT be used outside of FAST unless its
-   specification explicitly allows so.  The typed holes in FAST messages
-   can also be used as generic holes for other padata that are not
-   intended to prove the client's identity, or establish the reply key.
-
-   New pre-authentication mechanisms SHOULD be designed as FAST factors,
-   instead of full-blown pre-authentication mechanisms.
-
-   FAST factors that are pre-authentication mechanisms MUST meet the
-   requirements in Section 5.
-
-   FAST employs an armoring scheme.  The armor can be a Ticket Granting
-   Ticket (TGT) obtained by the client's machine using the host keys to
-   pre-authenticate with the KDC, or an anonymous TGT obtained based on
-   anonymous PKINIT [KRB-ANON] [RFC4556].
-
-   The rest of this section describes the types of armors and the syntax
-   of the messages used by FAST.  Conforming implementations MUST
-   support Kerberos FAST padata.
-
-6.5.1.  FAST Armors
-
-   An armor key is used to encrypt pre-authentication data in the FAST
-   request and the response.  The KrbFastArmor structure is defined to
-   identify the armor key.  This structure contains the following two
-   fields: the armor-type identifies the type of armors, and the armor-
-   value as an OCTET STRING contains the description of the armor scheme
-   and the armor key.
-
-        KrbFastArmor ::= SEQUENCE {
-            armor-type   [0] Int32,
-                -- Type of the armor.
-            armor-value  [1] OCTET STRING,
-                -- Value of the armor.
-            ...
-        }
-
-   The value of the armor key is a matter of the armor type
-   specification.  Only one armor type is defined in this document.
-
-        FX_FAST_ARMOR_AP_REQUEST           TBA
-
-   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
-
-   Conforming implementations MUST implement the
-   FX_FAST_ARMOR_AP_REQUEST armor type.
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 22]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-6.5.1.1.  Ticket-based Armors
-
-   This is a ticket-based armoring scheme.  The armor-type is
-   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
-   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
-   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
-   The armor key is the subkey in the AP-REQ authenticator.
-
-   The server name field of the armor ticket MUST identify the TGS of
-   the target realm.  Here are three ways in the decreasing preference
-   order how an armor TGT SHOULD be obtained:
-
-   1.  If the client is authenticating from a host machine whose
-       Kerberos realm has a trust path to the client's realm, the host
-       machine obtains a TGT by pre-authenticating intitialy the realm
-       of the host machine using the host keys.  If the client's realm
-       is different than the realm of the local host, the machine then
-       obtains a cross-realm TGT to the client's realm as the armor
-       ticket.  Otherwise, the host's primary TGT is the armor ticket.
-
-   2.  If the client's host machine cannot obtain a host ticket strictly
-       based on RFC4120, but the KDC has an asymmetric signing key that
-       the client can verify the binding between the public key of the
-       signing key and the expected KDC, the client can use anonymous
-       PKINIT [KRB-ANON] [RFC4556] to authenticate the KDC and obtain an
-       anonymous TGT as the armor ticket.  The armor key can be a cross-
-       team TGT obtained based on the initial primary TGT obtained using
-       anonymous PKINIT with KDC authentication.
-
-   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
-       TGT without KDC authentication and that TGT is the armor ticket.
-       Note that this mode of operation is vulnerable to man-in-the-
-       middle attacks at the time of obtaining the initial anonymous
-       armor TGT.  The armor key can be a cross-team TGT obtained based
-       on the initial primary TGT obtained using anonymous PKINIT
-       without KDC authentication.
-
-   Because the KDC does not know if the client is able to trust the
-   ticket it has, the KDC MUST initialize the pre-authentication state
-   to an unverified KDC.
-
-6.5.2.  FAST Request
-
-   A padata type PA_FX_FAST is defined for the Kerberos FAST pre-
-   authentication padata.  The corresponding padata-value field
-   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
-   REQUEST.
-
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 23]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-       PA_FX_FAST                         TBA
-           -- Padata type for Kerberos FAST
-
-       PA-FX-FAST-REQUEST ::= CHOICE {
-           armored-data [0] KrbFastArmoredReq,
-           ...
-       }
-
-       KrbFastArmoredReq ::= SEQUENCE {
-           armor        [0] KrbFastArmor OPTIONAL,
-               -- Contains the armor that identifies the armor key.
-               -- MUST be present in AS-REQ.
-               -- MUST be absent in TGS-REQ.
-           req-checksum [1] Checksum,
-               -- Checksum performed over the type KDC-REQ-BODY for
-               -- the req-body field of the KDC-REQ structure defined in
-               -- [RFC4120]
-               -- The checksum key is the armor key, the checksum
-               -- type is the required checksum type for the enctype of
-               -- the armor key, and the key usage number is
-               -- KEY_USAGE_FAST_REA_CHKSUM.
-           enc-fast-req [2] EncryptedData, -- KrbFastReq --
-               -- The encryption key is the armor key, and the key usage
-               -- number is KEY_USAGE_FAST_ENC.
-           ...
-       }
-
-       KEY_USAGE_FAST_REA_CHKSUM          TBA
-       KEY_USAGE_FAST_ENC                 TBA
-
-   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
-   The KrbFastArmoredReq encapsulates the encrypted padata.
-
-   The enc-fast-req field contains an encrypted KrbFastReq structure.
-   The armor key is used to encrypt the KrbFastReq structure, and the
-   key usage number for that encryption is KEY_USAGE_FAST_ARMOR.
-
-        KEY_USAGE_FAST_ARMOR               TBA
-
-   The armor key is selected as follows:
-
-   o  In an AS request, the armor field in the KrbFastArmoredReq
-      structure MUST be present and the armor key is identified
-      according to the specification of the armor type.
-
-   o  In a TGS request, the armor field in the KrbFastArmoredReq
-      structure MUST NOT be present and the subkey in the AP-REQ
-      authenticator in the PA-TGS-REQ PA-DATA MUST be present.  In this
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 24]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-      case, the armor key is that subkey in the AP-REQ authenticator.
-
-   The req-checksum field contains a checksum that is performed over the
-   type KDC-REQ-BODY for the req-body field of the KDC-REQ [RFC4120]
-   structure of the containing message.  The checksum key is the armor
-   key, and the checksum type is the required checksum type for the
-   enctype of the armor key per [RFC3961]. [[anchor12: Is this checksum
-   still needed if we include a full kdc-req-body]]
-
-   The KrbFastReq structure contains the following information:
-
-       KrbFastReq ::= SEQUENCE {
-           fast-options [0] FastOptions,
-               -- Additional options.
-           padata       [1] SEQUENCE OF PA-DATA,
-               -- padata typed holes.
-           req-body     [2] KDC-REQ-BODY,
-               -- Contains the KDC request body as defined in Section
-               -- 5.4.1 of [RFC4120].  The req-body field in the KDC-REQ
-               -- structure [RFC4120] MUST be ignored.
-               -- The client name and realm in the KDC-REQ [RFC4120]
-               -- MUST NOT be present for AS-REQ and TGS-REQ when
-               -- Kerberos FAST padata is included in the request.
-           ...
-       }
-
-   [[anchor13: See mailing list discussion about whether client name
-   absent is correct.]]
-
-   The fast-options field indicates various options that are to modify
-   the behavior of the KDC.  The following options are defined:
-
-        FastOptions ::= KerberosFlags
-            -- reserved(0),
-            -- anonymous(1),
-            -- kdc-referrals(16)
-
-
-      Bits    Name          Description
-     -----------------------------------------------------------------
-      0     RESERVED        Reserved for future expansion of this field.
-      1     anonymous       Requesting the KDC to hide client names in
-                            the KDC response, as described next in this
-                            section.
-      16    kdc-referrals   Requesting the KDC to follow referrals, as
-                            described next in this section.
-
-   Bits 1 through 15 (with bit 2 and bit 15 included) are critical
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 25]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   options.  If the KDC does not support a critical option, it MUST fail
-   the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS (there is no
-   accompanying e-data defined in this document for this error code).
-   Bit 16 and onward (with bit 16 included) are non-critical options.
-   KDCs conforming to this specification ignores unknown non-critical
-   options.
-
-        KDC_ERR_UNKNOWN_FAST_OPTIONS       TBA
-
-   The anonymous Option
-
-      The Kerberos response defined in [RFC4120] contains the client
-      identity in clear text, This makes traffic analysis
-      straightforward.  The anonymous option is designed to complicate
-      traffic analysis.  If the anonymous option is set, the KDC
-      implementing PA_FX_FAST MUST identify the client as the anonymous
-      principal in the KDC reply and the error response.  Hence this
-      option is set by the client if it wishes to conceal the client
-      identity in the KDC response.
-
-   The kdc-referrals Option
-
-      The Kerberos client described in [RFC4120] has to request referral
-      TGTs along the authentication path in order to get a service
-      ticket for the target service.  The Kerberos client described in
-      the [REFERRALS] need to contact the AS specified in the error
-      response in order to complete client referrals.  The kdc-referrals
-      option is designed to minimize the number of messages that need to
-      be processed by the client.  This option is useful when, for
-      example, the client may contact the KDC via a satellite link that
-      has high network latency, or the client has limited computational
-      capabilities.  If the kdc-referrals option is set, the KDC that
-      honors this option acts as the client to follow AS referrals and
-      TGS referrals [REFERRALS], and return the service ticket to the
-      named server principal in the client request using the reply key
-      expected by the client.  The kdc-referrals option can be
-      implemented when the KDC knows the reply key.  The KDC can ignore
-      kdc-referrals option when it does not understand it or it does not
-      allow this option based on local policy.  The client SHOULD be
-      able to process the KDC responses when this option is not honored
-      by the KDC.
-
-   The padata field contains a list of PA-DATA structures as described
-   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
-   FAST factors.  They can also be used as generic typed-holes to
-   contain data not intended for proving the client's identity or
-   establishing a reply key, but for protocol extensibility.
-
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 26]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   The KDC-REQ-BODY in the FAST structure is used in preference to the
-   KDC-REQ-BODY outside of the FAST pre-authentication.  This outer
-   structure SHOULD be filled in for backwards compatibility with KDCs
-   that do not support FAST.  The client MAY fill in the cname and
-   crealm fields in the kdc-req-body in the KrbFastReq structure and
-   leave the cname field and the crealm field in KDC-REQ absent, in
-   order to conceal the client's identity in the AS-REQ.[[anchor14:
-   Absent is probably wrong.  Presumably we want a name similar to the
-   anonymous principal name.]]
-
-6.5.3.  FAST Response
-
-   The KDC that supports the PA_FX_FAST padata MUST include a PA_FX_FAST
-   padata element in the KDC reply.  In the case of an error, the
-   PA_FX_FAST padata is included in the KDC responses according to
-   Section 6.5.4.
-
-   The corresponding padata-value field [RFC4120] for the PA_FX_FAST in
-   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
-   FAST-REPLY.
-
-      PA-FX-FAST-REPLY ::= CHOICE {
-          armored-data [0] KrbFastArmoredRep,
-          ...
-      }
-
-      KrbFastArmoredRep ::= SEQUENCE {
-          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
-              -- The encryption key is the armor key in the request, and
-              -- the key usage number is KEY_USAGE_FAST_REP.
-          ...
-      }
-      KEY_USAGE_FAST_REP                 TBA
-
-   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
-   structure.  The KrbFastArmoredRep structure encapsulates the padata
-   in the KDC reply in the encrypted form.  The KrbFastResponse is
-   encrypted with the armor key used in the corresponding request, and
-   the key usage number is KEY_USAGE_FAST_REP.
-
-   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
-   KDC response MUST support a local policy that rejects the response.
-   Clients MAY also support policies that fall back to other mechanisms
-   or that do not use pre-authentication when FAST is unavailable.  It
-   is important to consider the potential downgrade attacks when
-   deploying such a policy.
-
-   The KrbFastResponse structure contains the following information:
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 27]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-     KrbFastResponse ::= SEQUENCE {
-         padata      [0] SEQUENCE OF PA-DATA,
-             -- padata typed holes.
-         rep-key     [1] EncryptionKey OPTIONAL,
-             -- This, if present, replaces the reply key for AS and TGS.
-             -- MUST be absent in KRB-ERROR.
-         finished    [2] KrbFastFinished OPTIONAL,
-             -- MUST be present if the client is authenticated,
-             -- absent otherwise.
-             -- Typically this is present if and only if the containing
-             -- message is the last one in a conversation.
-         ...
-     }
-
-   The padata field in the KrbFastResponse structure contains a list of
-   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
-   PA-DATA structures are used to carry data advancing the exchange
-   specific for the FAST factors.  They can also be used as generic
-   typed-holes for protocol extensibility.
-
-   The rep-key field, if present, contains the reply key that is used to
-   encrypted the KDC reply.  The rep-key field MUST be absent in the
-   case where an error occurs.  The enctype of the rep-key is the
-   strongest mutually supported by the KDC and the client.
-
-   The finished field contains a KrbFastFinished structure.  It is
-   filled by the KDC in the final message in the conversation; it MUST
-   be absent otherwise.  In other words, this field can only be present
-   in an AS-REP or a TGS-REP when a ticket is returned.
-
-   The KrbFastFinished structure contains the following information:
-
-        KrbFastFinished ::= SEQUENCE {
-            timestamp   [0] KerberosTime,
-            usec        [1] Microseconds,
-                -- timestamp and usec represent the time on the KDC when
-                -- the reply was generated.
-            crealm      [2] Realm,
-            cname       [3] PrincipalName,
-                -- Contains the client realm and the client name.
-            checksum    [4] Checksum,
-                -- Checksum performed over all the messages in the
-                -- conversation, except the containing message.
-                -- The checksum key is the binding key as defined in
-                -- Section 6.3, and the checksum type is the required
-                -- checksum type of the binding key.
-            ...
-        }
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 28]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-        KEY_USAGE_FAST_FINISHED            TBA
-
-   The timestamp and usec fields represent the time on the KDC when the
-   reply ticket was generated, these fields have the same semantics as
-   the corresponding-identically-named fields in Section 5.6.1 of
-   [RFC4120].  The client MUST use the KDC's time in these fields
-   thereafter when using the returned ticket.  Note that the KDC's time
-   in AS-REP may not match the authtime in the reply ticket if the kdc-
-   referrals option is requested and honored by the KDC.
-
-   The cname and crealm fields identify the authenticated client.
-
-   The checksum field contains a checksum of all the messages in the
-   conversation prior to the containing message (the containing message
-   is excluded).  The checksum key is the binding key as defined in
-   Section 6.3, and the checksum type is the required checksum type of
-   the enctype of that key, and the key usage number is
-   KEY_USAGE_FAST_FINISHED. [[anchor15: Examples would be good here;
-   what all goes into the checksum?]]
-
-   When FAST padata is included, the PA-FX-COOKIE padata as defined in
-   Section 6.3 MUST also be included if the KDC expects at least one
-   more message from the client in order to complete the authentication.
-
-6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
-
-   If the Kerberos FAST padata was included in the request, unless
-   otherwise specified, the e-data field of the KRB-ERROR message
-   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
-   [RFC4120] and a PA_FX_FAST is included in the METHOD-DATA.  The KDC
-   MUST include all the padata elements such as PA-ETYPE-INFO2 and
-   padata elments that indicate acceptable pre-authentication mechanisms
-   [RFC4120] and in the KrbFastResponse structure.
-
-   If the Kerberos FAST padata is included in the request but not
-   included in the error reply, it is a matter of the local policy on
-   the client to accept the information in the error message without
-   integrity protection.  The Kerberos client MAY process an error
-   message without a PA-FX-FAST-REPLY, if that is only intended to
-   return better error information to the application, typically for
-   trouble-shooting purposes.
-
-   In the cases where the e-data field of the KRB-ERROR message is
-   expected to carry a TYPED-DATA [RFC4120] element, the
-   PA_FX_TYPED_DATA padata is included in the KrbFastResponse structure
-   to encapsulate the TYPED-DATA [RFC4120] elements.  For example, the
-   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
-   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 29]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   [RFC4556].
-
-        PA_FX_TYPED_DATA                   TBA
-            -- This is the padata element that encapsulates a TYPED-DATA
-            -- structure.
-
-   The corresponding padata-value for the PA_FX_TYPED_DATA padata type
-   contains the DER encoding of the ASN.1 type TYPED-DATA [RFC4120].
-
-6.5.5.  The Authenticated Timestamp FAST Factor
-
-   The encrypted time stamp [RFC4120] padata can be used as a FAST
-   factor to authenticate the client and it does not expose the cipher
-   text derived using the client's long term keys.  However this FAST
-   factor is not risk-free from current intellectual property claims as
-   of the time of this writing.  To provide a clearn replacement FAST
-   factor that closely matches the encrypted timestamp FAST factor, the
-   authenticated timestamp pre-authentication is introduced in this
-   section.
-
-   The authenticated timestamp FAST factor authenticates a client by
-   means of computing a checksum over a time-stamped structure using the
-   client's long term keys.  The padata-type is
-   PA_AUTHENTICATED_TIMESTAMP and the corresponding padata-value
-   contains the DER encoding of ASN.1 type AuthenticatedTimestamp.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 30]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-        AuthenticatedTimestampToBeSigned ::= SEQUENCE {
-            timestamp   [0] PA-ENC-TS-ENC,
-                -- Contains the timestamp field of the corresponding
-                -- AuthenticatedTimestamp structure.
-            req-body    [1] KDC-REQ-BODY OPTIONAL,
-                -- MUST contain the req-body field of the KDC-REQ
-                -- structure in the containing AS-REQ for the client
-                -- request.
-                -- MUST be Absent for the KDC reply.
-            ...
-        }
-
-        AuthenticatedTimestamp ::= SEQUENCE {
-            timestamp   [0] PA-ENC-TS-ENC,
-                -- Filled out according to Section 5.2.7.2 of [RFC4120].
-                -- Contains the client's current time for the client,
-                -- and the KDC's current time for the KDC.
-            checksum    [1] CheckSum,
-                -- The checksum is performed over the type
-                -- AuthenticatedTimestampToBeSigned and the key usage is
-                -- KEY_USAGE_AUTHENTICATED_TS_CLIENT for the client and
-                _ KEY_USAGE_AUTHENTICATED_TS_KDC for the KDC
-            ...
-        }
-
-        KEY_USAGE_AUTHENTICATED_TS_CLIENT  TBA
-        KEY_USAGE_AUTHENTICATED_TS_KDC     TBA
-
-   The client fills out the AuthenticatedTimestamp structure as follows:
-
-   o  The timestamp field in the AuthenticatedTimestamp structure is
-      filled out with the client's current time according to Section
-      5.2.7.2 of [RFC4120].
-
-   o  The checksum field in the AuthenticatedTimestamp structure is
-      performed over the type AuthenticatedTimestampToBeSigned.  The
-      checksum key is one of the client's long term keys.  The key usage
-      for the checksum operation is KEY_USAGE_AUTHENTICATED_TS_CLIENT.
-      The checksum type is the required checksum type for the strongest
-      enctype mutually supported by the client and the KDC.
-
-   o  Within the AuthenticatedTimestampToBeSigned structure, the
-      timestamp field contains the timestamp field of the corresponding
-      AuthenticatedTimestamp structure, and the req-body field MUST
-      contain the req-body field of the KDC-REQ structure in the
-      containing AS-REQ.
-
-   Upon receipt of the PA_AUTHENTICATED_TIMESTAMP FAST factor, the KDC
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 31]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   MUST process the padata in a way similar to that of the encrypted
-   timestamp padata.  The KDC MUST verify the checksum in the
-   AuthenticatedTimestamp structure and the timestamp is within the
-   window of acceptable clock skew for the KDC.
-
-   When the authenticated timestamp FAST factor is accepted by the KDC,
-   the KDC MUST include a PA_AUTHENTICATED_TIMESTAMP as a FAST factor in
-   in a successful KDC reply and it MUST include the rep-key field as
-   defined in Section 6.5.3.
-
-   The KDC fills out the AuthenticatedTimestamp structure as follows:
-
-   o  The timestamp field in the AuthenticatedTimestamp structure is
-      filled out with the KDC's current time according to Section
-      5.2.7.2 of [RFC4120].
-
-   o  The checksum field in the AuthenticatedTimestamp structure is
-      performed over the type AuthenticatedTimestampToBeSigned.  The
-      checksum key is the reply key picked from the client's long term
-      keys according to [RFC4120].  The key usage for the checksum
-      operation is KEY_USAGE_AUTHENTICATED_TS_KDC.  The checksum type is
-      the required checksum type for the checksum key.
-
-   o  Within the AuthenticatedTimestampToBeSigned structure, the
-      timestamp field contains the timestamp field of the corresponding
-      AuthenticatedTimestamp structure, and the req-body field MUST be
-      absent.
-
-   Upon receipt of the PA_AUTHENTICATED_TIMESTAMP FAST factor in the KDC
-   reply, the client MUST verify the checksum in the
-   AuthenticatedTimestamp structure and the timestamp is within the
-   window of acceptable clock skew for the client.  The successful
-   verificaiton of the PA_AUTHENTICATED_TIMESTAMP padata authenticates
-   the KDC.
-
-   The authenticated timestamp FAST factor provides the following
-   facilities: client-authentication, replacing-reply-key, KDC-
-   authentication.  It does not provide the strengthening-reply-key
-   facility.  The security considerations section of this document
-   provides an explanation why the security requirements are met.
-
-   Conforming implementations MUST support the authenticated timestamp
-   FAST factor.
-
-6.6.  Authentication Strength Indication
-
-   Implementations that have pre-authentication mechanisms offering
-   significantly different strengths of client authentication MAY choose
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 32]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-   to keep track of the strength of the authentication used as an input
-   into policy decisions.  For example, some principals might require
-   strong pre-authentication, while less sensitive principals can use
-   relatively weak forms of pre-authentication like encrypted timestamp.
-
-   An AuthorizationData data type AD-Authentication-Strength is defined
-   for this purpose.
-
-        AD-authentication-strength         TBA
-
-   The corresponding ad-data field contains the DER encoding of the pre-
-   authentication data set as defined in Section 6.4.  This set contains
-   all the pre-authentication mechanisms that were used to authenticate
-   the client.  If only one pre-authentication mechanism was used to
-   authenticate the client, the pre-authentication set contains one
-   element.
-
-   The AD-authentication-strength element MUST be included in the AD-IF-
-   RELEVANT, thus it can be ignored if it is unknown to the receiver.
-
-
-7.  IANA Considerations
-
-   This document defines several new pa-data types, key usages and error
-   codes.  In addition it would be good to track which pa-data items are
-   only to be used as FAST factors.
-
-
-8.  Security Considerations
-
-   The kdc-referrals option in the Kerberos FAST padata requests the KDC
-   to act as the client to follow referrals.  This can overload the KDC.
-   To limit the damages of denied of service using this option, KDCs MAY
-   restrict the number of simultaneous active requests with this option
-   for any given client principal.
-
-   Because the client secrets are known only to the client and the KDC,
-   the verification of the authenticated timestamp proves the client's
-   identity, the verification of the authenticated timestamp in the KDC
-   reply proves that the expected KDC responded.  The encrypted reply
-   key is contained in the rep-key in the PA-FX-FAST-REPLY.  Therefore,
-   the authenticated timestamp FAST factor as a pre-authentication
-   mechanism offers the following facilities: client-authentication,
-   replacing-reply-key, KDC-authentication.  There is no un-
-   authenticated clear text introduced by the authenticated timestamp
-   FAST factor.
-
-
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 33]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-9.  Acknowledgements
-
-   Several suggestions from Jeffery Hutzman based on early revisions of
-   this documents led to significant improvements of this document.
-
-   The proposal to ask one KDC to chase down the referrals and return
-   the final ticket is based on requirements in [ID.CROSS].
-
-   Joel Webber had a proposal for a mechanism similar to FAST that
-   created a protected tunnel for Kerberos pre-authentication.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [KRB-ANON]
-              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
-              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
-
-   [REFERRALS]
-              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
-              Locate Kerberos Realms",
-              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
-              progress), 2007.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-10.2.  Informative References
-
-   [ID.CROSS]
-              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
-              Statement on the Operation of Kerberos in a Specific
-              System", draft-sakane-krb-cross-problem-statement-02.txt
-              (work in progress), April 2007.
-
-   [KRB-WG.SAM]
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 34]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
-              "Integrating Single-use Authentication Mechanisms with
-              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
-              progress), October 2003.
-
-
-Appendix A.  ASN.1 module
-
-     KerberosPreauthFramework {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2) modules(4) preauth-framework(3)
-     } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-     IMPORTS
-          KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
-          Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) };
-                 -- as defined in RFC 4120.
-
-     PA-FX-COOKIE ::= SEQUENCE {
-         conversationId  [0] OCTET STRING,
-            -- Contains the identifier of this conversation. This field
-            -- must contain the same value for all the messages
-            -- within the same conversation.
-         enc-binding-key [1] EncryptedData OPTIONAL,
-                         -- EncryptionKey --
-            -- This field is present when and only when a FAST
-            -- padata as defined in Section 6.5 is included.
-            -- The encrypted data, when decrypted, contains an
-            -- EncryptionKey structure.
-            -- This encryption key is encrypted using the armor key
-            -- (defined in Section 6.5.1), and the key usage for the
-            -- encryption is KEY_USAGE_FAST_BINDING_KEY.
-         cookie          [2] OCTET STRING OPTIONAL,
-            -- Opaque data, for use to associate all the messages in
-            -- a single conversation between the client and the KDC.
-            -- This is generated by the KDC and the client MUST copy
-            -- the exact cookie encapsulated in a PA_FX_COOKIE data
-            -- element into the next message of the same conversation.
-         ...
-     }
-
-     PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-     PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-         pa-type      [0] Int32,
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 35]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-             -- same as padata-type.
-         pa-hint      [1] OCTET STRING,
-             -- hint data.
-         ...
-     }
-
-     KrbFastArmor ::= SEQUENCE {
-         armor-type   [0] Int32,
-             -- Type of the armor.
-         armor-value  [1] OCTET STRING,
-             -- Value of the armor.
-         ...
-     }
-
-     PA-FX-FAST-REQUEST ::= CHOICE {
-         armored-data [0] KrbFastArmoredReq,
-         ...
-     }
-
-     KrbFastArmoredReq ::= SEQUENCE {
-         armor        [0] KrbFastArmor OPTIONAL,
-             -- Contains the armor that identifies the armor key.
-             -- MUST be present in AS-REQ.
-             -- MUST be absent in TGS-REQ.
-         req-checksum [1] Checksum,
-             -- Checksum performed over the type KDC-REQ-BODY for
-             -- the req-body field of the KDC-REQ structure defined in
-             -- [RFC4120]
-             -- The checksum key is the armor key, the checksum
-             -- type is the required checksum type for the enctype of
-             -- the armor key, and the key usage number is
-             -- KEY_USAGE_FAST_REA_CHKSUM.
-         enc-fast-req [2] EncryptedData, -- KrbFastReq --
-             -- The encryption key is the armor key, and the key usage
-             -- number is KEY_USAGE_FAST_ENC.
-         ...
-     }
-
-     KrbFastReq ::= SEQUENCE {
-         fast-options [0] FastOptions,
-             -- Additional options.
-         padata       [1] SEQUENCE OF PA-DATA,
-             -- padata typed holes.
-         req-body     [2] KDC-REQ-BODY,
-             -- Contains the KDC request body as defined in Section
-             -- 5.4.1 of [RFC4120].  The req-body field in the KDC-REQ
-             -- structure [RFC4120] MUST be ignored.
-             -- The client name and realm in the KDC-REQ [RFC4120]
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 36]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-             -- MUST NOT be present for AS-REQ and TGS-REQ when
-             -- Kerberos FAST padata is included in the request.
-         ...
-     }
-
-     FastOptions ::= KerberosFlags
-         -- reserved(0),
-         -- anonymous(1),
-         -- kdc-referrals(16)
-
-     PA-FX-FAST-REPLY ::= CHOICE {
-         armored-data [0] KrbFastArmoredRep,
-         ...
-     }
-
-     KrbFastArmoredRep ::= SEQUENCE {
-         enc-fast-rep [0] EncryptedData, -- KrbFastResponse --
-             -- The encryption key is the armor key in the request, and
-             -- the key usage number is KEY_USAGE_FAST_REP.
-         ...
-     }
-
-     KrbFastResponse ::= SEQUENCE {
-         padata      [0] SEQUENCE OF PA-DATA,
-             -- padata typed holes.
-         rep-key     [1] EncryptionKey OPTIONAL,
-             -- This, if present, replaces the reply key for AS and TGS.
-             -- MUST be absent in KRB-ERROR.
-         finished    [2] KrbFastFinished OPTIONAL,
-             -- MUST be present if the client is authenticated,
-             -- absent otherwise.
-             -- Typically this is present if and only if the containing
-             -- message is the last one in a conversation.
-         ...
-     }
-
-     KrbFastFinished ::= SEQUENCE {
-         timestamp   [0] KerberosTime,
-         usec        [1] Microseconds,
-             -- timestamp and usec represent the time on the KDC when
-             -- the reply was generated.
-         crealm      [2] Realm,
-         cname       [3] PrincipalName,
-             -- Contains the client realm and the client name.
-         checksum    [4] Checksum,
-             -- Checksum performed over all the messages in the
-             -- conversation, except the containing message.
-             -- The checksum key is the binding key as defined in
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 37]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-             -- Section 6.3, and the checksum type is the required
-             -- checksum type of the binding key.
-         ...
-     }
-
-     AuthenticatedTimestampToBeSigned ::= SEQUENCE {
-         timestamp   [0] PA-ENC-TS-ENC,
-             -- Contains the timestamp field of the corresponding
-             -- AuthenticatedTimestamp structure.
-         req-body    [1] KDC-REQ-BODY OPTIONAL,
-             -- MUST contain the req-body field of the KDC-REQ
-             -- structure in the containing AS-REQ for the client
-             -- request.
-             -- MUST be Absent for the KDC reply.
-         ...
-     }
-
-     AuthenticatedTimestamp ::= SEQUENCE {
-         timestamp   [0] PA-ENC-TS-ENC,
-             -- Filled out according to Section 5.2.7.2 of [RFC4120].
-             -- Contains the client's current time for the client,
-             -- and the KDC's current time for the KDC.
-         checksum    [1] CheckSum,
-             -- The checksum is performed over the type
-             -- AuthenticatedTimestampToBeSigned and the key usage is
-             -- KEY_USAGE_AUTHENTICATED_TS_CLIENT for the client and
-             _ KEY_USAGE_AUTHENTICATED_TS_KDC for the KDC
-         ...
-     }
-     END
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Sam hartman
-   MIT
-
-   Email: hartmans@mit.edu
-
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 38]
-
-Internet-Draft         Kerberos Preauth Framework              July 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Zhu & Hartman            Expires January 9, 2008               [Page 39]
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-08.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-08.txt
deleted file mode 100644
index 96f996350..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-08.txt
+++ /dev/null
@@ -1,2266 +0,0 @@
-

-

-Kerberos Working Group                                            L. Zhu

-Internet-Draft                                     Microsoft Corporation

-Updates: 4120 (if approved)                                   S. Hartman

-Intended status: Standards Track                       Painless Security

-Expires: January 15, 2009                                  July 14, 2008

-

-

-        A Generalized Framework for Kerberos Pre-Authentication

-                 draft-ietf-krb-wg-preauth-framework-08

-

-Status of this Memo

-

-   By submitting this Internet-Draft, each author represents that any

-   applicable patent or other IPR claims of which he or she is aware

-   have been or will be disclosed, and any of which he or she becomes

-   aware will be disclosed, in accordance with Section 6 of BCP 79.

-

-   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."

-

-   The list of current Internet-Drafts can be accessed at

-   http://www.ietf.org/ietf/1id-abstracts.txt.

-

-   The list of Internet-Draft Shadow Directories can be accessed at

-   http://www.ietf.org/shadow.html.

-

-   This Internet-Draft will expire on January 15, 2009.

-

-Abstract

-

-   Kerberos is a protocol for verifying the identity of principals

-   (e.g., a workstation user or a network server) on an open network.

-   The Kerberos protocol provides a mechanism called pre-authentication

-   for proving the identity of a principal and for better protecting the

-   long-term secret of the principal.

-

-   This document describes a model for Kerberos pre-authentication

-   mechanisms.  The model describes what state in the Kerberos request a

-   pre-authentication mechanism is likely to change.  It also describes

-   how multiple pre-authentication mechanisms used in the same request

-   will interact.

-

-

-

-Zhu & Hartman           Expires January 15, 2009                [Page 1]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   This document also provides common tools needed by multiple pre-

-   authentication mechanisms.  One of these tools is a secure channel

-   between the client and the KDC with a reply key delivery mechanism;

-   this secure channel can be used to protect the authentication

-   exchange thus eliminate offline dictionary attacks.  With these

-   tools, it is relatively straightforward to chain multiple

-   authentication mechanisms, utilize a different key management system,

-   or support a new key agreement algorithm.

-

-

-Table of Contents

-

-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

-   2.  Conventions and Terminology Used in This Document  . . . . . .  5

-   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  5

-     3.1.  Information Managed by the Pre-authentication Model  . . .  6

-     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  8

-     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . .  9

-     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 10

-   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 10

-     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 12

-     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 12

-     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 13

-     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 14

-   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 14

-   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15

-     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 15

-     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 16

-     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 17

-     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 19

-     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 22

-       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 23

-       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 24

-       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 28

-       6.5.4.  Authenticated Kerberos Error Messages using

-               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 30

-       6.5.5.  The Encrypted Challenge FAST Factor  . . . . . . . . . 31

-     6.6.  Authentication Strength Indication . . . . . . . . . . . . 32

-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33

-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33

-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34

-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34

-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 34

-     10.2. Informative References . . . . . . . . . . . . . . . . . . 34

-   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 35

-     A.1.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 35

-     A.2.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 35

-   Appendix B.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 35

-

-

-

-Zhu & Hartman           Expires January 15, 2009                [Page 2]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39

-   Intellectual Property and Copyright Statements . . . . . . . . . . 40

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Zhu & Hartman           Expires January 15, 2009                [Page 3]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-1.  Introduction

-

-   The core Kerberos specification [RFC4120] treats pre-authentication

-   data as an opaque typed hole in the messages to the KDC that may

-   influence the reply key used to encrypt the KDC reply.  This

-   generality has been useful: pre-authentication data is used for a

-   variety of extensions to the protocol, many outside the expectations

-   of the initial designers.  However, this generality makes designing

-   more common types of pre-authentication mechanisms difficult.  Each

-   mechanism needs to specify how it interacts with other mechanisms.

-   Also, problems like combining a key with the long-term secret or

-   proving the identity of the user are common to multiple mechanisms.

-   Where there are generally well-accepted solutions to these problems,

-   it is desirable to standardize one of these solutions so mechanisms

-   can avoid duplication of work.  In other cases, a modular approach to

-   these problems is appropriate.  The modular approach will allow new

-   and better solutions to common pre-authentication problems to be used

-   by existing mechanisms as they are developed.

-

-   This document specifies a framework for Kerberos pre-authentication

-   mechanisms.  It defines the common set of functions that pre-

-   authentication mechanisms perform as well as how these functions

-   affect the state of the request and reply.  In addition several

-   common tools needed by pre-authentication mechanisms are provided.

-   Unlike [RFC3961], this framework is not complete--it does not

-   describe all the inputs and outputs for the pre-authentication

-   mechanisms.  Pre-Authentication mechanism designers should try to be

-   consistent with this framework because doing so will make their

-   mechanisms easier to implement.  Kerberos implementations are likely

-   to have plugin architectures for pre-authentication; such

-   architectures are likely to support mechanisms that follow this

-   framework plus commonly used extensions.

-

-   One of these common tools is the flexible authentication secure

-   tunneling (FAST) padata type.  FAST provides a protected channel

-   between the client and the KDC, and it can optionally deliver a reply

-   key within the protected channel.  Based on FAST, pre-authentication

-   mechanisms can extend Kerberos with ease, to support, for example,

-   password authenticated key exchange (PAKE) protocols with zero

-   knowledge password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-

-   authentication mechanism can be encapsulated in the FAST messages as

-   defined in Section 6.5.  A pre-authentication type carried within

-   FAST is called a FAST factor.  Creating a FAST factor is the easiest

-   path to create a new pre-authentication mechanism.  FAST factors are

-   significantly easier to analyze from a security standpoint than other

-   pre-authentication mechanisms.

-

-   Mechanism designers should design FAST factors, instead of new pre-

-

-

-

-Zhu & Hartman           Expires January 15, 2009                [Page 4]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   authentication mechanisms outside of FAST.

-

-

-2.  Conventions and Terminology Used in This Document

-

-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

-   document are to be interpreted as described in [RFC2119].

-

-   The word padata is used as a shorthand for pre-authentication data.

-

-   A conversation is the set of all authentication messages exchanged

-   between the client and the KDCs in order to authenticate the client

-   principal.  A conversation as defined here consists of all messages

-   that are necessary to complete the authentication between the client

-   and the KDC.

-

-   Lastly, this document should be read only after reading the documents

-   describing the Kerberos cryptography framework [RFC3961] and the core

-   Kerberos protocol [RFC4120].  This document may freely use

-   terminology and notation from these documents without reference or

-   further explanation.

-

-

-3.  Model for Pre-Authentication

-

-   When a Kerberos client wishes to obtain a ticket using the

-   authentication server, it sends an initial Authentication Service

-   (AS) request.  If pre-authentication is required but not being used,

-   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.

-   Alternatively, if the client knows what pre-authentication to use, it

-   MAY optimize away a round-trip and send an initial request with

-   padata included in the initial request.  If the client includes the

-   padata computed using the wrong pre-authentication mechanism or

-   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no

-   indication of what padata should have been included.  In that case,

-   the client MUST retry with no padata and examine the error data of

-   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-

-   authentication information in the accompanying error data of

-   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and

-   then retry.

-

-   The conventional KDC maintains no state between two requests;

-   subsequent requests may even be processed by a different KDC.  On the

-   other hand, the client treats a series of exchanges with KDCs as a

-   single conversation.  Each exchange accumulates state and hopefully

-   brings the client closer to a successful authentication.

-

-

-

-

-Zhu & Hartman           Expires January 15, 2009                [Page 5]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   These models for state management are in apparent conflict.  For many

-   of the simpler pre-authentication scenarios, the client uses one

-   round trip to find out what mechanisms the KDC supports.  Then the

-   next request contains sufficient pre-authentication for the KDC to be

-   able to return a successful reply.  For these simple scenarios, the

-   client only sends one request with pre-authentication data and so the

-   conversation is trivial.  For more complex conversations, the KDC

-   needs to provide the client with a cookie to include in future

-   requests to capture the current state of the authentication session.

-   Handling of multiple round-trip mechanisms is discussed in

-   Section 6.3.

-

-   This framework specifies the behavior of Kerberos pre-authentication

-   mechanisms used to identify users or to modify the reply key used to

-   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry

-   extensions to Kerberos that have nothing to do with proving the

-   identity of the user or establishing a reply key.  Such extensions

-   are outside the scope of this framework.  However mechanisms that do

-   accomplish these goals should follow this framework.

-

-   This framework specifies the minimum state that a Kerberos

-   implementation needs to maintain while handling a request in order to

-   process pre-authentication.  It also specifies how Kerberos

-   implementations process the padata at each step of the AS request

-   process.

-

-3.1.  Information Managed by the Pre-authentication Model

-

-   The following information is maintained by the client and KDC as each

-   request is being processed:

-

-   o  The reply key used to encrypt the KDC reply

-

-   o  How strongly the identity of the client has been authenticated

-

-   o  Whether the reply key has been used in this conversation

-

-   o  Whether the reply key has been replaced in this conversation

-

-   o  Whether the contents of the KDC reply can be verified by the

-      client principal

-

-

-   Conceptually, the reply key is initially the long-term key of the

-   principal.  However, principals can have multiple long-term keys

-   because of support for multiple encryption types, salts and

-   string2key parameters.  As described in Section 5.2.7.5 of the

-   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify

-

-

-

-Zhu & Hartman           Expires January 15, 2009                [Page 6]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   the client what types of keys are available.  Thus in full

-   generality, the reply key in the pre-authentication model is actually

-   a set of keys.  At the beginning of a request, it is initialized to

-   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on

-   the KDC.  If multiple reply keys are available, the client chooses

-   which one to use.  Thus the client does not need to treat the reply

-   key as a set.  At the beginning of a request, the client picks a

-   reply key to use.

-

-   KDC implementations MAY choose to offer only one key in the PA-ETYPE-

-   INFO2 element.  Since the KDC already knows the client's list of

-   supported enctypes from the request, no interoperability problems are

-   created by choosing a single possible reply key.  This way, the KDC

-   implementation avoids the complexity of treating the reply key as a

-   set.

-

-   When the padata in the request is verified by the KDC, then the

-   client is known to have that key, therefore the KDC SHOULD pick the

-   same key as the reply key.

-

-   At the beginning of handling a message on both the client and the

-   KDC, the client's identity is not authenticated.  A mechanism may

-   indicate that it has successfully authenticated the client's

-   identity.  This information is useful to keep track of on the client

-   in order to know what pre-authentication mechanisms should be used.

-   The KDC needs to keep track of whether the client is authenticated

-   because the primary purpose of pre-authentication is to authenticate

-   the client identity before issuing a ticket.  The handling of

-   authentication strength using various authentication mechanisms is

-   discussed in Section 6.6.

-

-   Initially the reply key has not been used.  A pre-authentication

-   mechanism that uses the reply key to encrypt or checksum some data in

-   the generation of new keys MUST indicate that the reply key is used.

-   This state is maintained by the client and the KDC to enforce the

-   security requirement stated in Section 4.3 that the reply key cannot

-   be replaced after it is used.

-

-   Initially the reply key has not been replaced.  If a mechanism

-   implements the Replace Reply Key facility discussed in Section 4.3,

-   then the state MUST be updated to indicate that the reply key has

-   been replaced.  Once the reply key has been replaced, knowledge of

-   the reply key is insufficient to authenticate the client.  The reply

-   key is marked replaced in exactly the same situations as the KDC

-   reply is marked as not being verified to the client principal.

-   However, while mechanisms can verify the KDC reply to the client,

-   once the reply key is replaced, then the reply key remains replaced

-   for the remainder of the conversation.

-

-

-

-Zhu & Hartman           Expires January 15, 2009                [Page 7]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   Without pre-authentication, the client knows that the KDC reply is

-   authentic and has not been modified because it is encrypted in a

-   long-term key of the client.  Only the KDC and the client know that

-   key.  So at the start of a conversation, the KDC reply is presumed to

-   be verified using the client principal's long-term key.  Any pre-

-   authentication mechanism that sets a new reply key not based on the

-   principal's long-term secret MUST either verify the KDC reply some

-   other way or indicate that the reply is not verified.  If a mechanism

-   indicates that the reply is not verified then the client

-   implementation MUST return an error unless a subsequent mechanism

-   verifies the reply.  The KDC needs to track this state so it can

-   avoid generating a reply that is not verified.

-

-   The typical Kerberos request does not provide a way for the client

-   machine to know that it is talking to the correct KDC.  Someone who

-   can inject packets into the network between the client machine and

-   the KDC and who knows the password that the user will give to the

-   client machine can generate a KDC reply that will decrypt properly.

-   So, if the client machine needs to authenticate that the user is in

-   fact the named principal, then the client machine needs to do a TGS

-   request for itself as a service.  Some pre-authentication mechanisms

-   may provide a way for the client to authenticate the KDC.  Examples

-   of this include signing the reply that can be verified using a well-

-   known public key or providing a ticket for the client machine as a

-   service.

-

-3.2.  Initial Pre-authentication Required Error

-

-   Typically a client starts a conversation by sending an initial

-   request with no pre-authentication.  If the KDC requires pre-

-   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.

-   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,

-   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED

-   (defined in Section 6.3) for pre-authentication configurations that

-   use multi-round-trip mechanisms; see Section 3.4 for details of that

-   case.

-

-   The KDC needs to choose which mechanisms to offer the client.  The

-   client needs to be able to choose what mechanisms to use from the

-   first message.  For example consider the KDC that will accept

-   mechanism A followed by mechanism B or alternatively the single

-   mechanism C. A client that supports A and C needs to know that it

-   should not bother trying A.

-

-   Mechanisms can either be sufficient on their own or can be part of an

-   authentication set--a group of mechanisms that all need to

-   successfully complete in order to authenticate a client.  Some

-   mechanisms may only be useful in authentication sets; others may be

-

-

-

-Zhu & Hartman           Expires January 15, 2009                [Page 8]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   useful alone or in authentication sets.  For the second group of

-   mechanisms, KDC policy dictates whether the mechanism will be part of

-   an authentication set or offered alone.  For each mechanism that is

-   offered alone, the KDC includes the pre-authentication type ID of the

-   mechanism in the padata sequence returned in the

-   KDC_ERR_PREAUTH_REQUIRED error.

-

-   The KDC SHOULD NOT send data that is encrypted in the long-term

-   password-based key of the principal.  Doing so has the same security

-   exposures as the Kerberos protocol without pre-authentication.  There

-   are few situations where pre-authentication is desirable and where

-   the KDC needs to expose cipher text encrypted in a weak key before

-   the client has proven knowledge of that key.

-

-3.3.  Client to KDC

-

-   This description assumes that a client has already received a

-   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs

-   optimistic pre-authentication then the client needs to optimistically

-   guess values for the information it would normally receive from that

-   error response.

-

-   The client starts by initializing the pre-authentication state as

-   specified.  It then processes the padata in the

-   KDC_ERR_PREAUTH_REQUIRED.

-

-   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the

-   client MAY ignore any padata it chooses unless doing so violates a

-   specification to which the client conforms.  Clients conforming to

-   this specification MUST NOT ignore the padata defined in Section 6.3.

-   Clients SHOULD process padata unrelated to this framework or other

-   means of authenticating the user.  Clients SHOULD choose one

-   authentication set or mechanism that could lead to authenticating the

-   user and ignore the rest.  Since the list of mechanisms offered by

-   the KDC is in the decreasing preference order, clients typically

-   choose the first mechanism or authentication set that the client can

-   usefully perform.  If a client chooses to ignore a padata it MUST NOT

-   process the padata, allow the padata to affect the pre-authentication

-   state, nor respond to the padata.

-

-   For each padata the client chooses to process, the client processes

-   the padata and modifies the pre-authentication state as required by

-   that mechanism.  Padata are processed in the order received from the

-   KDC.

-

-   After processing the padata in the KDC error, the client generates a

-   new request.  It processes the pre-authentication mechanisms in the

-   order in which they will appear in the next request, updating the

-

-

-

-Zhu & Hartman           Expires January 15, 2009                [Page 9]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   state as appropriate.  The request is sent when it is complete.

-

-3.4.  KDC to Client

-

-   When a KDC receives an AS request from a client, it needs to

-   determine whether it will respond with an error or an AS reply.

-   There are many causes for an error to be generated that have nothing

-   to do with pre-authentication; they are discussed in the core

-   Kerberos specification.

-

-   From the standpoint of evaluating the pre-authentication, the KDC

-   first starts by initializing the pre-authentication state.  It then

-   processes the padata in the request.  As mentioned in Section 3.3,

-   the KDC MAY ignore padata that is inappropriate for the configuration

-   and MUST ignore padata of an unknown type.  The KDC MUST NOT ignore

-   padata of types used in previous messages.  For example, if a KDC

-   issues a KDC_ERR_PREAUTH_REQUIRED error including padata of type x,

-   then the KDC cannot ignore padata of type x received in an AS-REQ

-   message from the client.

-

-   At this point the KDC decides whether it will issue an error or a

-   reply.  Typically a KDC will issue a reply if the client's identity

-   has been authenticated to a sufficient degree.

-

-   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC

-   first starts by initializing the pre-authentication state.  Then it

-   processes any padata in the client's request in the order provided by

-   the client.  Mechanisms that are not understood by the KDC are

-   ignored.  Next, it generates padata for the error response, modifying

-   the pre-authentication state appropriately as each mechanism is

-   processed.  The KDC chooses the order in which it will generate

-   padata (and thus the order of padata in the response), but it needs

-   to modify the pre-authentication state consistently with the choice

-   of order.  For example, if some mechanism establishes an

-   authenticated client identity, then the subsequent mechanisms in the

-   generated response receive this state as input.  After the padata is

-   generated, the error response is sent.  Typically the errors with the

-   code KDC_ERR_MORE_PREAUTH_DATA_NEEDED in a converstation will include

-   KDC state as discussed in Section 6.3.

-

-   To generate a final reply, the KDC generates the padata modifying the

-   pre-authentication state as necessary.  Then it generates the final

-   response, encrypting it in the current pre-authentication reply key.

-

-

-4.  Pre-Authentication Facilities

-

-   Pre-Authentication mechanisms can be thought of as providing various

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 10]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   conceptual facilities.  This serves two useful purposes.  First,

-   mechanism authors can choose only to solve one specific small

-   problem.  It is often useful for a mechanism designed to offer key

-   management not to directly provide client authentication but instead

-   to allow one or more other mechanisms to handle this need.  Secondly,

-   thinking about the abstract services that a mechanism provides yields

-   a minimum set of security requirements that all mechanisms providing

-   that facility must meet.  These security requirements are not

-   complete; mechanisms will have additional security requirements based

-   on the specific protocol they employ.

-

-   A mechanism is not constrained to only offering one of these

-   facilities.  While such mechanisms can be designed and are sometimes

-   useful, many pre-authentication mechanisms implement several

-   facilities.  By combining multiple facilities in a single mechanism,

-   it is often easier to construct a secure, simple solution than by

-   solving the problem in full generality.  Even when mechanisms provide

-   multiple facilities, they need to meet the security requirements for

-   all the facilities they provide.  If the FAST factor approach is

-   used, it is likely that one or a small number of facilities can be

-   provided by a single mechanism without complicating the security

-   analysis.

-

-   According to Kerberos extensibility rules (Section 1.5 of the

-   Kerberos specification [RFC4120]), an extension MUST NOT change the

-   semantics of a message unless a recipient is known to understand that

-   extension.  Because a client does not know that the KDC supports a

-   particular pre-authentication mechanism when it sends an initial

-   request, a pre-authentication mechanism MUST NOT change the semantics

-   of the request in a way that will break a KDC that does not

-   understand that mechanism.  Similarly, KDCs MUST NOT send messages to

-   clients that affect the core semantics unless the client has

-   indicated support for the message.

-

-   The only state in this model that would break the interpretation of a

-   message is changing the expected reply key.  If one mechanism changed

-   the reply key and a later mechanism used that reply key, then a KDC

-   that interpreted the second mechanism but not the first would fail to

-   interpret the request correctly.  In order to avoid this problem,

-   extensions that change core semantics are typically divided into two

-   parts.  The first part proposes a change to the core semantic--for

-   example proposes a new reply key.  The second part acknowledges that

-   the extension is understood and that the change takes effect.

-   Section 4.2 discusses how to design mechanisms that modify the reply

-   key to be split into a proposal and acceptance without requiring

-   additional round trips to use the new reply key in subsequent pre-

-   authentication.  Other changes in the state described in Section 3.1

-   can safely be ignored by a KDC that does not understand a mechanism.

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 11]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   Mechanisms that modify the behavior of the request outside the scope

-   of this framework need to carefully consider the Kerberos

-   extensibility rules to avoid similar problems.

-

-4.1.  Client-authentication Facility

-

-   The client authentication facility proves the identity of a user to

-   the KDC before a ticket is issued.  Examples of mechanisms

-   implementing this facility include the encrypted timestamp facility

-   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].

-   Mechanisms that provide this facility are expected to mark the client

-   as authenticated.

-

-   Mechanisms implementing this facility SHOULD require the client to

-   prove knowledge of the reply key before transmitting a successful KDC

-   reply.  Otherwise, an attacker can intercept the pre-authentication

-   exchange and get a reply to attack.  One way of proving the client

-   knows the reply key is to implement the Replace Reply Key facility

-   along with this facility.  The PKINIT mechanism [RFC4556] implements

-   Client Authentication alongside Replace Reply Key.

-

-   If the reply key has been replaced, then mechanisms such as

-   encrypted-timestamp that rely on knowledge of the reply key to

-   authenticate the client MUST NOT be used.

-

-4.2.  Strengthening-reply-key Facility

-

-   Particularly, when dealing with keys based on passwords, it is

-   desirable to increase the strength of the key by adding additional

-   secrets to it.  Examples of sources of additional secrets include the

-   results of a Diffie-Hellman key exchange or key bits from the output

-   of a smart card [KRB-WG.SAM].  Typically these additional secrets can

-   be first combined with the existing reply key and then converted to a

-   protocol key using tools defined in Section 6.1.

-

-   Typically a mechanism implementing this facility will know that the

-   other side of the exchange supports the facility before the reply key

-   is changed.  For example, a mechanism might need to learn the

-   certificate for a KDC before encrypting a new key in the public key

-   belonging to that certificate.  However, if a mechanism implementing

-   this facility wishes to modify the reply key before knowing that the

-   other party in the exchange supports the mechanism, it proposes

-   modifying the reply key.  The other party then includes a message

-   indicating that the proposal is accepted if it is understood and

-   meets policy.  In many cases it is desirable to use the new reply key

-   for client authentication and for other facilities.  Waiting for the

-   other party to accept the proposal and actually modify the reply key

-   state would add an additional round trip to the exchange.  Instead,

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 12]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   mechanism designers are encouraged to include a typed hole for

-   additional padata in the message that proposes the reply key change.

-   The padata included in the typed hole are generated assuming the new

-   reply key.  If the other party accepts the proposal, then these

-   padata are considered as an inner level.  As with the outer level,

-   one authentication set or mechanism is typically chosen for client

-   authentication, along with auxiliary mechanisms such as KDC cookies,

-   and other mechanisms are ignored.  When mechanisms include such a

-   container, the hint provided for use in authentication sets MUST

-   contain a sequence of inner mechanisms along with hints for those

-   mechanisms.  The party generating the proposal can determine whether

-   the padata were processed based on whether the proposal for the reply

-   key is accepted.

-

-   The specific formats of the proposal message, including where padata

-   are included is a matter for the mechanism specification.  Similarly,

-   the format of the message accepting the proposal is mechanism-

-   specific.

-

-   Mechanisms implementing this facility and including a typed hole for

-   additional padata MUST checksum that padata using a keyed checksum or

-   encrypt the padata.  This requirement protects against modification

-   of the contents of the typed hole.  By modifying these contents an

-   attacker might be able to choose which mechanism is used to

-   authenticate the client, or to convince a party to provide text

-   encrypted in a key that the attacker had manipulated.  It is

-   important that mechanisms strengthen the reply key enough that using

-   it to checksum padata is appropriate.

-

-4.3.  Replacing-reply-key Facility

-

-   The Replace Reply Key facility replaces the key in which a successful

-   AS reply will be encrypted.  This facility can only be used in cases

-   where knowledge of the reply key is not used to authenticate the

-   client.  The new reply key MUST be communicated to the client and the

-   KDC in a secure manner.  Mechanisms implementing this facility MUST

-   mark the reply key as replaced in the pre-authentication state.

-   Mechanisms implementing this facility MUST either provide a mechanism

-   to verify the KDC reply to the client or mark the reply as unverified

-   in the pre-authentication state.  Mechanisms implementing this

-   facility SHOULD NOT be used if a previous mechanism has used the

-   reply key.

-

-   As with the strengthening-reply-key facility, Kerberos extensibility

-   rules require that the reply key not be changed unless both sides of

-   the exchange understand the extension.  In the case of this facility

-   it will likely be the case for both sides to know that the facility

-   is available by the time that the new key is available to be used.

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 13]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   However, mechanism designers can use a container for padata in a

-   proposal message as discussed in Section 4.2 if appropriate.

-

-4.4.  KDC-authentication Facility

-

-   This facility verifies that the reply comes from the expected KDC.

-   In traditional Kerberos, the KDC and the client share a key, so if

-   the KDC reply can be decrypted then the client knows that a trusted

-   KDC responded.  Note that the client machine cannot trust the client

-   unless the machine is presented with a service ticket for it

-   (typically the machine can retrieve this ticket by itself).  However,

-   if the reply key is replaced, some mechanism is required to verify

-   the KDC.  Pre-authentication mechanisms providing this facility allow

-   a client to determine that the expected KDC has responded even after

-   the reply key is replaced.  They mark the pre-authentication state as

-   having been verified.

-

-

-5.  Requirements for Pre-Authentication Mechanisms

-

-   This section lists requirements for specifications of pre-

-   authentication mechanisms.

-

-   For each message in the pre-authentication mechanism, the

-   specification describes the pa-type value to be used and the contents

-   of the message.  The processing of the message by the sender and

-   recipient is also specified.  This specification needs to include all

-   modifications to the pre-authentication state.

-

-   Generally mechanisms have a message that can be sent in the error

-   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an

-   authentication set.  If the client needs information such as trusted

-   certificate authorities in order to determine if it can use the

-   mechanism, then this information should be in that message.  In

-   addition, such mechanisms should also define a pa-hint to be included

-   in authentication sets.  Often, the same information included in the

-   padata-value is appropriate to include in the pa-hint (as defined in

-   Section 6.4).

-

-   In order to ease security analysis the mechanism specification should

-   describe what facilities from this document are offered by the

-   mechanism.  For each facility, the security consideration section of

-   the mechanism specification should show that the security

-   requirements of that facility are met.  This requirement is

-   applicable to any FAST factor that provides authentication

-   information.

-

-   Significant problems have resulted in the specification of Kerberos

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 14]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   protocols because much of the KDC exchange is not protected against

-   authentication.  The security considerations section should discuss

-   unauthenticated plaintext attacks.  It should either show that

-   plaintext is protected or discuss what harm an attacker could do by

-   modifying the plaintext.  It is generally acceptable for an attacker

-   to be able to cause the protocol negotiation to fail by modifying

-   plaintext.  More significant attacks should be evaluated carefully.

-

-   As discussed in Section 6.3, there is no guarantee that a client will

-   use the same KDCs for all messages in a conversation.  The mechanism

-   specification needs to show why the mechanism is secure in this

-   situation.  The hardest problem to deal with, especially for

-   challenge/response mechanisms is to make sure that the same response

-   cannot be replayed against two KDCs while allowing the client to talk

-   to any KDC.

-

-

-6.  Tools for Use in Pre-Authentication Mechanisms

-

-   This section describes common tools needed by multiple pre-

-   authentication mechanisms.  By using these tools mechanism designers

-   can use a modular approach to specify mechanism details and ease

-   security analysis.

-

-6.1.  Combining Keys

-

-   Frequently a weak key needs to be combined with a stronger key before

-   use.  For example, passwords are typically limited in size and

-   insufficiently random, therefore it is desirable to increase the

-   strength of the keys based on passwords by adding additional secrets.

-   Additional source of secrecy may come from hardware tokens.

-

-   This section provides standard ways to combine two keys into one.

-

-   KRB-FX-CF1() is defined to combine two pass-phrases.

-

-       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)

-       KRB-FX-CF1(x, y) -> x || y

-

-   Where || denotes concatenation.  The strength of the final key is

-   roughly the total strength of the individual keys being combined

-   assuming that the string_to_key() function [RFC3961] uses all its

-   input evenly.

-

-   An example usage of KRB-FX-CF1() is when a device provides random but

-   short passwords, the password is often combined with a personal

-   identification number (PIN).  The password and the PIN can be

-   combined using KRB-FX-CF1().

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 15]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()

-   function defined in [RFC3961].

-

-   Given two input keys, K1 and K2, where K1 and K2 can be of two

-   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as

-   follows:

-

-       KRB-FX-CF2(protocol key, protocol key, octet string,

-                 octet string)  ->  (protocol key)

-

-       PRF+(K1, pepper1) -> octet-string-1

-       PRF+(K2, pepper2) -> octet-string-2

-       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->

-              random-to-key(octet-string-1 ^ octet-string-2)

-

-   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as

-   follows:

-

-    PRF+(protocol key, octet string) -> (octet string)

-

-    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||

-                  pseudo-random( key, 2 || shared-info ) ||

-                  pseudo-random( key, 3 || shared-info ) || ...

-

-   Here the counter value 1, 2, 3 and so on are encoded as a one-octet

-   integer.  The pseudo-random() operation is specified by the enctype

-   of the protocol key.  PRF+() uses the counter to generate enough bits

-   as needed by the random-to-key() [RFC3961] function for the

-   encryption type specified for the resulting key; unneeded bits are

-   removed from the tail.

-

-   Mechanism designers MUST specify the values for the input parameter

-   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The

-   pepper1 and pepper2 MUST be distinct so that if the two keys being

-   combined are the same, the resulting key is not a trivial key.

-

-6.2.  Protecting Requests/Responses

-

-   Mechanism designers SHOULD protect clear text portions of pre-

-   authentication data.  Various denial of service attacks and downgrade

-   attacks against Kerberos are possible unless plaintexts are somehow

-   protected against modification.  An early design goal of Kerberos

-   Version 5 [RFC4120] was to avoid encrypting more of the

-   authentication exchange that was required.  (Version 4 doubly-

-   encrypted the encrypted part of a ticket in a KDC reply, for

-   example.)  This minimization of encryption reduces the load on the

-   KDC and busy servers.  Also, during the initial design of Version 5,

-   the existence of legal restrictions on the export of cryptography

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 16]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   made it desirable to minimize of the number of uses of encryption in

-   the protocol.  Unfortunately, performing this minimization created

-   numerous instances of unauthenticated security-relevant plaintext

-   fields.

-

-   If there is more than one roundtrip for an authentication exchange,

-   mechanism designers need to allow either the client or the KDC to

-   provide a checksum of all the messages exchanged on the wire in the

-   conversation, and the checksum is then verified by the receiver.

-

-   New mechanisms MUST NOT be hard-wired to use a specific algorithm.

-

-   Primitives defined in [RFC3961] are RECOMMENDED for integrity

-   protection and confidentiality.  Mechanisms based on these primitives

-   are crypto-agile as the result of using [RFC3961] along with

-   [RFC4120].  The advantage afforded by crypto-agility is the ability

-   to avoid a multi-year standardization and deployment cycle to fix a

-   problem that is specific to a particular algorithm, when real attacks

-   do arise against that algorithm.

-

-   Note that data used by FAST factors (defined in Section 6.5) is

-   encrypted in a protected channel, thus they do not share the un-

-   authenticated-text issues with mechanisms designed as full-blown pre-

-   authentication mechanisms.

-

-6.3.  Managing States for the KDC

-

-   Kerberos KDCs are stateless.  There is no requirement that clients

-   will choose the same KDC for the second request in a conversation.

-   Proxies or other intermediate nodes may also influence KDC selection.

-   So, each request from a client to a KDC must include sufficient

-   information that the KDC can regenerate any needed state.  This is

-   accomplished by giving the client a potentially long opaque cookie in

-   responses to include in future requests in the same conversation.

-   The KDC MAY respond that a conversation is too old and needs to

-   restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.

-

-       KDC_ERR_PREAUTH_EXPIRED            TBA

-

-   When a client receives this error, the client SHOULD abort the

-   existing conversation, and restart a new one.

-

-   An example, where more than one message from the client is needed, is

-   when the client is authenticated based on a challenge-response

-   scheme.  In that case, the KDC needs to keep track of the challenge

-   issued for a client authentication request.

-

-   The PA-FX-COOKIE pdata type is defined in this section to facilitate

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 17]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   state management.  This padata is sent by the KDC when the KDC

-   requires state for a future transaction.  The client includes this

-   opaque token in the next message in the conversation.  The token may

-   be relatively large; clients MUST be prepared for tokens somewhat

-   larger than the size of all messages in a conversation.

-

-       PA_FX_COOKIE                       TBA

-           -- Stateless cookie that is not tied to a specific KDC.

-

-   The corresponding padata-value field [RFC4120] contains the

-   Distinguished Encoding Rules (DER) [X60] [X690] encoding of the

-   following Abstract Syntax Notation One (ASN.1) type PA-FX-COOKIE:

-

-      PA-FX-COOKIE ::= SEQUENCE {

-          conversationId  [0] OCTET STRING,

-             -- Contains the identifier of this conversation. This field

-             -- must contain the same value for all the messages

-             -- within the same conversation.

-          enc-binding-key [1] EncryptedData OPTIONAL,

-                          -- EncryptionKey --

-             -- This field is present when and only when a FAST

-             -- padata as defined in Section 6.5 is included.

-             -- The encrypted data, when decrypted, contains an

-             -- EncryptionKey structure.

-             -- This encryption key is encrypted using the armor key

-             -- (defined in Section 6.5.1), and the key usage for the

-             -- encryption is KEY_USAGE_FAST_BINDING_KEY.

-             -- Present only once in a converstation.

-          cookie          [2] OCTET STRING OPTIONAL,

-             -- Opaque data, for use to associate all the messages in

-             -- a single conversation between the client and the KDC.

-             -- This is generated by the KDC and the client MUST copy

-             -- the exact cookie encapsulated in a PA_FX_COOKIE data

-             -- element into the next message of the same conversation.

-          ...

-      }

-      KEY_USAGE_FAST_BINDING_KEY         TBA

-

-   The conversationId field contains a sufficiently-long rand number

-   that uniquely identifies the conversation.  If a PA_FX_COOKIE padata

-   is present in one message, a PA_FX_COOKIE structure MUST be present

-   in all subsequent messages of the same converstation between the

-   client and the KDC, with the same conversationId value.

-

-   The enc-binding-key field is present when and only when a FAST padata

-   (defined in Section 6.5) is included.  The enc-binding-key field is

-   present only once in a conversation.  It MUST be ignored if it is

-   present in a subsequent message of the same conversation.  The

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 18]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   encrypted data, when decrypted, contains an EncryptionKey structure

-   that is called the binding key.  The binding key is encrypted using

-   the armor key (defined in Section 6.5.1), and the key usage for the

-   encryption is KEY_USAGE_FAST_BINDING_KEY.

-

-   If a Kerberos FAST padata as defined in Section 6.5 is included in

-   one message, it MUST be included in all subsequent messages of the

-   same conversation.

-

-   When FAST padata as defined Section 6.5 is included, the PA-FX-COOKIE

-   padata MUST be included.

-

-   The cookie token is generated by the KDC and the client MUST copy the

-   exact cookie encapsulated in a PA_FX_COOKIE data element into the

-   next message of the same conversation.  The content of the cookie

-   field is a local matter of the KDC.  However the KDC MUST construct

-   the cookie token in such a manner that a malicious client cannot

-   subvert the authentication process by manipulating the token.  The

-   KDC implementation needs to consider expiration of tokens, key

-   rollover and other security issues in token design.  The content of

-   the cookie field is likely specific to the pre-authentication

-   mechanisms used to authenticate the client.  If a client

-   authentication response can be replayed to multiple KDCs via the

-   PA_FX_COOKIE mechanism, an expiration in the cookie is RECOMMENDED to

-   prevent the response being presented indefinitely.

-

-   If at least one more message for a mechanism or a mechanism set is

-   expected by the KDC, the KDC returns a

-   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA_FX_COOKIE to

-   identify the conversation with the client according to Section 6.5.4.

-

-        KDC_ERR_MORE_PREAUTH_DATA_NEEDED   TBA

-

-6.4.  Pre-authentication Set

-

-   If all mechanisms in a group need to successfully complete in order

-   to authenticate a client, the client and the KDC SHOULD use the

-   PA_AUTHENTICATION_SET padata element.

-

-   A PA_AUTHENTICATION_SET padata element contains the ASN.1 DER

-   encoding of the PA-AUTHENTICATION-SET structure:

-

-

-

-

-

-

-

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 19]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM

-

-        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {

-            pa-type      [0] Int32,

-                -- same as padata-type.

-            pa-hint      [1] OCTET STRING OPTIONAL,

-            pa-value  [2] OCTET STRING OPTIONAL,

-            ...

-        }

-

-   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure

-   contains the corresponding value of padata-type in PA-DATA [RFC4120].

-   Associated with the pa-type is a pa-hint, which is an octet-string

-   specified by the pre-authentication mechanism.  This hint may provide

-   information for the client which helps it determine whether the

-   mechanism can be used.  For example a public-key mechanism might

-   include the certificate authorities it trusts in the hint info.  Most

-   mechanisms today do not specify hint info; if a mechanism does not

-   specify hint info the KDC MUST NOT send a hint for that mechanism.

-   To allow future revisions of mechanism specifications to add hint

-   info, clients MUST ignore hint info received for mechanisms that the

-   client believes do not support hint info.  The pa-value element of

-   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the

-   first padata-value from the KDC to the client.  If the client chooses

-   this authentication set then the client MUST process this pa-value.

-   The pa-value element MUST be absent for all but the first entry in

-   the authentication set.  Clients MUST ignore pa-value for the second

-   and following entries in the authentication set.

-

-   If the client chooses an authentication set, then its AS-REQ message

-   MUST contain a PA_AUTHENTICATION_SET_SELECTED padata element.  This

-   element contains the encoding of the PA-AUTHENTICATION-SET sequence

-   received from the KDC corresponding to the authentication set that is

-   chosen.  The client MUST use the same octet values received from the

-   KDC; it cannot re-encode the sequence.  This allows KDCs to use bit-

-   wise comparison to identify the selected authentication set.  The

-   PA_AUTHENTICATION_SET_SELECTED padata element MUST come before any

-   padata elements from the authentication set in the padata sequence in

-   the AS-REQ message.  The client MAY cache authentication sets from

-   prior messages and use them to construct an optimistic initial AS-

-   REQ.  If the KDC receives a PA_AUTHENTICATION_SET_SELECTED padata

-   element that does not correspond to an authentication set that it

-   would offer, then the KDC returns the

-   KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The edata in this

-   error contains a sequence of padata just as for the

-   KDC_ERR_PREAUTH_REQUIRED error.

-

-

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 20]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-      PA_AUTHENTICATION_SET_SELECTED         TBA

-      KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET TBA

-

-   The PA-AUTHENTICATION-SET appears only in the first message from the

-   KDC to the client.  In particular, the client MAY fail if the

-   authentication mechanism sets change as the conversation progresses.

-   Clients MAY assume that the hints provided in the authentication set

-   contain enough information that the client knows what user interface

-   elements need to be displayed during the entire authentication

-   conversation.  Exceptional circumstances such as expired passwords or

-   expired accounts may require that additional user interface be

-   displayed.  Mechanism designers need to carefully consider the design

-   of their hints so that the client has this information.  This way,

-   clients can construct necessary dialogue boxes or wizards based on

-   the authentication set and can present a coherent user interface.

-   Current standards for user interface do not provide an acceptable

-   experience when the client has to ask additional questions later in

-   the conversation.

-

-   When indicating which sets of pre-authentication mechanisms are

-   supported, the KDC includes a PA-AUTHENTICATION-SET padata element

-   for each pre-authentication mechanism set.

-

-   The client sends the padata-value for the first mechanism it picks in

-   the pre-authentication set, when the first mechanism completes, the

-   client and the KDC will proceed with the second mechanism, and so on

-   until all mechanisms complete successfully.  The PA_FX_COOKIE as

-   defined in Section 6.3 MUST be sent by the KDC along with the first

-   message that contains a PA-AUTHENTICATION-SET, in order to keep track

-   of KDC states.

-

-   Before the authentication succeeds and a ticket is returned, the

-   message that the client sends is an AS_REQ and the message that the

-   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR

-   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_NEEDED as defined

-   in Section 6.3 and the accompanying e-data contains the DER encoding

-   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in

-   the METHOD-DATA.  If there is no padata, the e-data field is absent

-   in the KRB-ERROR message.

-

-   If the client sends the last message for a given mechanism, then the

-   KDC sends the first message for the next mechanism.  If the next

-   mechanism does not start with a KDC-side challenge, then the KDC

-   includes a padata item with the appropriate pa-type and an empty pa-

-   data.

-

-   If the KDC sends the last message for a particular mechanism, the KDC

-   also includes the first padata for the next mechanism.

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 21]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-6.5.  Definition of Kerberos FAST Padata

-

-   As described in [RFC4120], Kerberos is vulnerable to offline

-   dictionary attacks.  An attacker can request an AS-REP and try

-   various passwords to see if they can decrypt the resulting ticket.

-   RFC 4120 provides the entrypted timestap pre-authentication method

-   that ameliorates the situation somewhat by requiring that an attacker

-   observe a successful authentication.  However stronger security is

-   desired in many environments.  The Kerberos FAST pre-authentication

-   padata defined in this section provides a tool to significantly

-   reduce vulnerability to offline dictionary attack.  When combined

-   with encrypted timestamp, FAST requires an attacker to mount a

-   successful man-in-the-middle attack to observe ciphertext.  When

-   combined with host keys, FAST can even protect against active

-   attacks.  FAST also provides solutions to common problems for pre-

-   authentication mechanisms such as binding of the request and the

-   reply, freshness guarantee of the authentication.  FAST itself,

-   however, does not authenticate the client or the KDC, instead, it

-   provides a typed hole to allow pre-authentication data be tunneled.

-   A pre-authentication data element used within FAST is called a FAST

-   factor.  A FAST factor captures the minimal work required for

-   extending Kerberos to support a new pre-authentication scheme.

-

-   A FAST factor MUST NOT be used outside of FAST unless its

-   specification explicitly allows so.  The typed holes in FAST messages

-   can also be used as generic holes for other padata that are not

-   intended to prove the client's identity, or establish the reply key.

-

-   New pre-authentication mechanisms SHOULD be designed as FAST factors,

-   instead of full-blown pre-authentication mechanisms.

-

-   FAST factors that are pre-authentication mechanisms MUST meet the

-   requirements in Section 5.

-

-   FAST employs an armoring scheme.  The armor can be a Ticket Granting

-   Ticket (TGT) obtained by the client's machine using the host keys to

-   pre-authenticate with the KDC, or an anonymous TGT obtained based on

-   anonymous PKINIT [KRB-ANON] [RFC4556].

-

-   The rest of this section describes the types of armors and the syntax

-   of the messages used by FAST.  Conforming implementations MUST

-   support Kerberos FAST padata.

-

-   Any FAST armor scheme MUST provide a fresh armor key for each

-   conversation.  Clients and KDCs can assume that if a message is

-   encrypted and integrity protected with a given armor key then it is

-   part of the conversation using that armor key.

-

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 22]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-6.5.1.  FAST Armors

-

-   An armor key is used to encrypt pre-authentication data in the FAST

-   request and the response.  The KrbFastArmor structure is defined to

-   identify the armor key.  This structure contains the following two

-   fields: the armor-type identifies the type of armors, and the armor-

-   value as an OCTET STRING contains the description of the armor scheme

-   and the armor key.

-

-        KrbFastArmor ::= SEQUENCE {

-            armor-type   [0] Int32,

-                -- Type of the armor.

-            armor-value  [1] OCTET STRING,

-                -- Value of the armor.

-            ...

-        }

-

-   The value of the armor key is a matter of the armor type

-   specification.  Only one armor type is defined in this document.

-

-        FX_FAST_ARMOR_AP_REQUEST           TBA

-

-   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.

-

-   Conforming implementations MUST implement the

-   FX_FAST_ARMOR_AP_REQUEST armor type.

-

-6.5.1.1.  Ticket-based Armors

-

-   This is a ticket-based armoring scheme.  The armor-type is

-   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER

-   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket

-   or an armor TGT.  The subkey field in the AP-REQ MUST be present.

-   The armor key is the subkey in the AP-REQ authenticator.

-

-   The server name field of the armor ticket MUST identify the TGS of

-   the target realm.  Here are three ways in the decreasing preference

-   order how an armor TGT SHOULD be obtained:

-

-   1.  If the client is authenticating from a host machine whose

-       Kerberos realm has a trust path to the client's realm, the host

-       machine obtains a TGT by pre-authenticating intitialy the realm

-       of the host machine using the host keys.  If the client's realm

-       is different than the realm of the local host, the machine then

-       obtains a cross-realm TGT to the client's realm as the armor

-       ticket.  Otherwise, the host's primary TGT is the armor ticket.

-

-

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 23]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   2.  If the client's host machine cannot obtain a host ticket strictly

-       based on RFC4120, but the KDC has an asymmetric signing key that

-       the client can verify the binding between the public key of the

-       signing key and the expected KDC, the client can use anonymous

-       PKINIT [KRB-ANON] [RFC4556] to authenticate the KDC and obtain an

-       anonymous TGT as the armor ticket.  The armor key can be a cross-

-       team TGT obtained based on the initial primary TGT obtained using

-       anonymous PKINIT with KDC authentication.

-

-   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous

-       TGT without KDC authentication and that TGT is the armor ticket.

-       Note that this mode of operation is vulnerable to man-in-the-

-       middle attacks at the time of obtaining the initial anonymous

-       armor TGT.  The armor key can be a cross-team TGT obtained based

-       on the initial primary TGT obtained using anonymous PKINIT

-       without KDC authentication.

-

-   Because the KDC does not know if the client is able to trust the

-   ticket it has, the KDC MUST initialize the pre-authentication state

-   to an unverified KDC.

-

-6.5.2.  FAST Request

-

-   A padata type PA_FX_FAST is defined for the Kerberos FAST pre-

-   authentication padata.  The corresponding padata-value field

-   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-

-   REQUEST.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 24]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-       PA_FX_FAST                         TBA

-           -- Padata type for Kerberos FAST

-

-       PA-FX-FAST-REQUEST ::= CHOICE {

-           armored-data [0] KrbFastArmoredReq,

-           ...

-       }

-

-       KrbFastArmoredReq ::= SEQUENCE {

-           armor        [0] KrbFastArmor OPTIONAL,

-               -- Contains the armor that identifies the armor key.

-               -- MUST be present in AS-REQ.

-               -- MUST be absent in TGS-REQ.

-           req-checksum [1] Checksum,

-               -- Checksum performed over the type KDC-REQ-BODY for

-               -- the req-body field of the KDC-REQ structure defined in

-               -- [RFC4120]

-               -- The checksum key is the armor key, the checksum

-               -- type is the required checksum type for the enctype of

-               -- the armor key, and the key usage number is

-               -- KEY_USAGE_FAST_REA_CHKSUM.

-           enc-fast-req [2] EncryptedData, -- KrbFastReq --

-               -- The encryption key is the armor key, and the key usage

-               -- number is KEY_USAGE_FAST_ENC.

-           ...

-       }

-

-       KEY_USAGE_FAST_REA_CHKSUM          TBA

-       KEY_USAGE_FAST_ENC                 TBA

-

-   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.

-   The KrbFastArmoredReq encapsulates the encrypted padata.

-

-   The enc-fast-req field contains an encrypted KrbFastReq structure.

-   The armor key is used to encrypt the KrbFastReq structure, and the

-   key usage number for that encryption is KEY_USAGE_FAST_ARMOR.

-

-        KEY_USAGE_FAST_ARMOR               TBA

-

-   The armor key is selected as follows:

-

-   o  In an AS request, the armor field in the KrbFastArmoredReq

-      structure MUST be present and the armor key is identified

-      according to the specification of the armor type.

-

-   o  In a TGS request, the armor field in the KrbFastArmoredReq

-      structure MUST NOT be present and the subkey in the AP-REQ

-      authenticator in the PA-TGS-REQ PA-DATA MUST be present.  In this

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 25]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-      case, the armor key is that subkey in the AP-REQ authenticator.

-

-   The req-checksum field contains a checksum that is performed over the

-   type KDC-REQ-BODY for the req-body field of the KDC-REQ [RFC4120]

-   structure of the containing message.  The checksum key is the armor

-   key, and the checksum type is the required checksum type for the

-   enctype of the armor key per [RFC3961].  This checksum is included in

-   order to bind the FAST data to the outer request.  A KDC that

-   implements FAST will ignore the outer request, but including a

-   checksum is relatively cheap and may prevent confusing behavior.

-

-   The KrbFastReq structure contains the following information:

-

-        KrbFastReq ::= SEQUENCE {

-            fast-options [0] FastOptions,

-                -- Additional options.

-            padata       [1] SEQUENCE OF PA-DATA,

-                -- padata typed holes.

-            req-body     [2] KDC-REQ-BODY,

-                -- Contains the KDC request body as defined in Section

-                -- 5.4.1 of [RFC4120].

-                -- This req-body field is preferred over the outer field

-                -- in the KDC request.

-             ...

-        }

-

-   The fast-options field indicates various options that are to modify

-   the behavior of the KDC.  The following options are defined:

-

-        FastOptions ::= KerberosFlags

-            -- reserved(0),

-            -- anonymous(1),

-            -- kdc-referrals(16)

-

-

-      Bits    Name          Description

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

-      0     RESERVED        Reserved for future expansion of this field.

-      1     anonymous       Requesting the KDC to hide client names in

-                            the KDC response, as described next in this

-                            section.

-      16    kdc-referrals   Requesting the KDC to follow referrals, as

-                            described next in this section.

-

-   Bits 1 through 15 (with bit 2 and bit 15 included) are critical

-   options.  If the KDC does not support a critical option, it MUST fail

-   the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS (there is no

-   accompanying e-data defined in this document for this error code).

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 26]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   Bit 16 and onward (with bit 16 included) are non-critical options.

-   KDCs conforming to this specification ignores unknown non-critical

-   options.

-

-        KDC_ERR_UNKNOWN_FAST_OPTIONS       TBA

-

-   The anonymous Option

-

-      The Kerberos response defined in [RFC4120] contains the client

-      identity in clear text, This makes traffic analysis

-      straightforward.  The anonymous option is designed to complicate

-      traffic analysis.  If the anonymous option is set, the KDC

-      implementing PA_FX_FAST MUST identify the client as the anonymous

-      principal [KRB-ANON] in the KDC reply and the error response.

-      Hence this option is set by the client if it wishes to conceal the

-      client identity in the KDC response.  A conforming KD ignores the

-      client principal name in the outer KDC-REQ-BODY field, and

-      identifies the client using the cname and crealm fields in the

-      req-body field of the KrbFastReq structure.

-

-   The kdc-referrals Option

-

-      The Kerberos client described in [RFC4120] has to request referral

-      TGTs along the authentication path in order to get a service

-      ticket for the target service.  The Kerberos client described in

-      the [REFERRALS] need to contact the AS specified in the error

-      response in order to complete client referrals.  The kdc-referrals

-      option is designed to minimize the number of messages that need to

-      be processed by the client.  This option is useful when, for

-      example, the client may contact the KDC via a satellite link that

-      has high network latency, or the client has limited computational

-      capabilities.  If the kdc-referrals option is set, the KDC that

-      honors this option acts as the client to follow AS referrals and

-      TGS referrals [REFERRALS], and return the service ticket to the

-      named server principal in the client request using the reply key

-      expected by the client.  The kdc-referrals option can be

-      implemented when the KDC knows the reply key.  The KDC can ignore

-      kdc-referrals option when it does not understand it or it does not

-      allow this option based on local policy.  The client SHOULD be

-      able to process the KDC responses when this option is not honored

-      by the KDC.

-

-   The padata field contains a list of PA-DATA structures as described

-   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain

-   FAST factors.  They can also be used as generic typed-holes to

-   contain data not intended for proving the client's identity or

-   establishing a reply key, but for protocol extensibility.

-

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 27]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   The KDC-REQ-BODY in the FAST structure is used in preference to the

-   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-

-   REQ-BODY structure SHOULD be filled in for backwards compatibility

-   with KDCs that do not support FAST.  A conforming KDC ignores the

-   outer KDC-REQ-BODY field in the KDC request.

-

-6.5.3.  FAST Response

-

-   The KDC that supports the PA_FX_FAST padata MUST include a PA_FX_FAST

-   padata element in the KDC reply.  In the case of an error, the

-   PA_FX_FAST padata is included in the KDC responses according to

-   Section 6.5.4.

-

-   The corresponding padata-value field [RFC4120] for the PA_FX_FAST in

-   the KDC response contains the DER encoding of the ASN.1 type PA-FX-

-   FAST-REPLY.

-

-      PA-FX-FAST-REPLY ::= CHOICE {

-          armored-data [0] KrbFastArmoredRep,

-          ...

-      }

-

-      KrbFastArmoredRep ::= SEQUENCE {

-          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --

-              -- The encryption key is the armor key in the request, and

-              -- the key usage number is KEY_USAGE_FAST_REP.

-          ...

-      }

-      KEY_USAGE_FAST_REP                 TBA

-

-   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep

-   structure.  The KrbFastArmoredRep structure encapsulates the padata

-   in the KDC reply in the encrypted form.  The KrbFastResponse is

-   encrypted with the armor key used in the corresponding request, and

-   the key usage number is KEY_USAGE_FAST_REP.

-

-   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the

-   KDC response MUST support a local policy that rejects the response.

-   Clients MAY also support policies that fall back to other mechanisms

-   or that do not use pre-authentication when FAST is unavailable.  It

-   is important to consider the potential downgrade attacks when

-   deploying such a policy.

-

-   The KrbFastResponse structure contains the following information:

-

-

-

-

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 28]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-     KrbFastResponse ::= SEQUENCE {

-         padata      [0] SEQUENCE OF PA-DATA,

-             -- padata typed holes.

-         rep-key     [1] EncryptionKey OPTIONAL,

-             -- This, if present, replaces the reply key for AS and TGS.

-             -- MUST be absent in KRB-ERROR.

-         finished    [2] KrbFastFinished OPTIONAL,

-             -- MUST be present if the client is authenticated,

-             -- absent otherwise.

-             -- Typically this is present if and only if the containing

-             -- message is the last one in a conversation.

-         ...

-     }

-

-   The padata field in the KrbFastResponse structure contains a list of

-   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These

-   PA-DATA structures are used to carry data advancing the exchange

-   specific for the FAST factors.  They can also be used as generic

-   typed-holes for protocol extensibility.

-

-   The rep-key field, if present, contains the reply key that is used to

-   encrypted the KDC reply.  The rep-key field MUST be absent in the

-   case where an error occurs.  The enctype of the rep-key is the

-   strongest mutually supported by the KDC and the client.

-

-   The finished field contains a KrbFastFinished structure.  It is

-   filled by the KDC in the final message in the conversation; it MUST

-   be absent otherwise.  In other words, this field can only be present

-   in an AS-REP or a TGS-REP when a ticket is returned.

-

-   The KrbFastFinished structure contains the following information:

-

-        KrbFastFinished ::= SEQUENCE {

-            timestamp   [0] KerberosTime,

-            usec        [1] Microseconds,

-                -- timestamp and usec represent the time on the KDC when

-                -- the reply was generated.

-            crealm      [2] Realm,

-            cname       [3] PrincipalName,

-                -- Contains the client realm and the client name.

-            checksum    [4] Checksum,

-                -- Checksum performed over all the messages in the

-                -- conversation, except the containing message.

-                -- The checksum key is the binding key as defined in

-                -- Section 6.3, and the checksum type is the required

-                -- checksum type of the binding key.

-            ...

-        }

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 29]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-        KEY_USAGE_FAST_FINISHED            TBA

-

-   The timestamp and usec fields represent the time on the KDC when the

-   reply ticket was generated, these fields have the same semantics as

-   the corresponding-identically-named fields in Section 5.6.1 of

-   [RFC4120].  The client MUST use the KDC's time in these fields

-   thereafter when using the returned ticket.  Note that the KDC's time

-   in AS-REP may not match the authtime in the reply ticket if the kdc-

-   referrals option is requested and honored by the KDC.

-

-   The cname and crealm fields identify the authenticated client.

-

-   The checksum field contains a checksum of all the messages in the

-   conversation prior to the containing message (the containing message

-   is excluded).  The checksum key is the binding key as defined in

-   Section 6.3, and the checksum type is the required checksum type of

-   the enctype of that key, and the key usage number is

-   KEY_USAGE_FAST_FINISHED. [[anchor9: Examples would be good here; what

-   all goes into the checksum?]]

-

-   When FAST padata is included, the PA-FX-COOKIE padata as defined in

-   Section 6.3 MUST also be included if the KDC expects at least one

-   more message from the client in order to complete the authentication.

-

-6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST

-

-   If the Kerberos FAST padata was included in the request, unless

-   otherwise specified, the e-data field of the KRB-ERROR message

-   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA

-   [RFC4120] and a PA_FX_FAST is included in the METHOD-DATA.  The KDC

-   MUST include all the padata elements such as PA-ETYPE-INFO2 and

-   padata elments that indicate acceptable pre-authentication mechanisms

-   [RFC4120] and in the KrbFastResponse structure.

-

-   If the Kerberos FAST padata is included in the request but not

-   included in the error reply, it is a matter of the local policy on

-   the client to accept the information in the error message without

-   integrity protection.  The Kerberos client MAY process an error

-   message without a PA-FX-FAST-REPLY, if that is only intended to

-   return better error information to the application, typically for

-   trouble-shooting purposes.

-

-   In the cases where the e-data field of the KRB-ERROR message is

-   expected to carry a TYPED-DATA [RFC4120] element, the

-   PA_FX_TYPED_DATA padata is included in the KrbFastResponse structure

-   to encapsulate the TYPED-DATA [RFC4120] elements.  For example, the

-   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR

-   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 30]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   [RFC4556].

-

-        PA_FX_TYPED_DATA                   TBA

-            -- This is the padata element that encapsulates a TYPED-DATA

-            -- structure.

-

-   The corresponding padata-value for the PA_FX_TYPED_DATA padata type

-   contains the DER encoding of the ASN.1 type TYPED-DATA [RFC4120].

-

-6.5.5.  The Encrypted Challenge FAST Factor

-

-   The encrypted challenge FAST factor authenticates a client using the

-   client's long-term key.  This factor works similarly to the encrypted

-   time stamp pre-authentication option described in [RFC4120].  The

-   client encrypts a structure containing a timestamp in the challenge

-   key.  The challenge key is KRB-FX-CF2(long_term_key, armor_key,

-   "challengelongterm", "challengearmor").  Because the armor key is

-   fresh and random, the challenge key is fresh and random.  The only

-   purpose of the timestamp is to limit the validity of the

-   authentication so that a request cannot be replayed.  A client MAY

-   base the timestamp based on the KDC time in a KDC error and need not

-   maintain accurate time synchronization itself.  If a client bases its

-   time on an untrusted source, an attacker may trick the client into

-   producing an authentication request that is valid at some future

-   time.  The attacker may be able to use this authentication request to

-   make it appear that a client has authenticated at that future time.

-   If ticket-based armor is used, then the lifetime of the ticket will

-   limit the window in which an attacker can make the client appear to

-   have authenticated.  For many situations, the ability of an attacker

-   to cause a client to appear to have authenticated is not a

-   significant concern; the ability to avoid requiring time

-   synchronization on clients is more valuable.

-

-   The client sends a padata of type PA_ENCRYPTED_CHALLENGE the

-   corresponding padata-value contains the DER encoding of ASN.1 type

-   EncryptedChallenge.

-

-      EncryptedChallenge ::= EncryptedData

-              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key

-              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the

-              --  client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.

-

-      PA_ENCRYPTED_CHALLENGE          TBA

-      KEY_USAGE_ENC_CHALLENGE_CLIENT  TBA

-      KEY_USAGE_ENC_CHALLENGE_KDC     TBA

-

-   The client includes some time stamp reasonably close to the KDC's

-   current time and encrypts it in the challenge key.  Clients MAY use

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 31]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   the current time; doing so prevents the exposure where an attacker

-   can cause a client to appear to authenticate in the future.  The

-   client sends the request including this factor.

-

-   On receiving an AS-REQ containing the PA_ENCRYPTED_CHALLENGE fast

-   factor, the KDC decrypts the timestamp.  If the decryption fails the

-   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including etype-info2 in

-   the error [[anchor11: Or should this be KRB_APP_ERR_MODIFIED?]].  The

-   KDC confirms that the timestamp falls within its current clock skew

-   returning KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see

-   if the encrypted challenge is a replay.  The KDC MUST NOT consider

-   two encrypted challenges replays simply because the time stamps are

-   the same; to be a replay, the ciphertext MUST be identical.  It is

-   not clear that RFC 3961 prevents encryption systems for which an

-   attacker can transform one ciphertext into a different ciphertext

-   yielding an identical plaintext.  So, it may not be safe to base

-   replay detection on the ciphertext in the general case.  However the

-   FAST tunnel provides integrity protection so requiring ciphertext be

-   identical is secure in this instance.  Allowing clients to re-use

-   time stamps avoids requiring that clients maintain state about which

-   time stamps have been used.

-

-   If the KDC accepts the encrypted challenge, it MUST include a padata

-   element of type PA_ENCRYPTED_CHALLENGE.  The KDC encrypts its current

-   time in the challenge key.  The KDC MUST replace the reply key before

-   issuing a ticket. [[anchor12: I'd like to say that the KDC replaces

-   its reply key by this point.  However we need to decide at what

-   points the FAST mechanism for replacing the reply key can be used and

-   how that interacts with this.]]The client MUST check that the

-   timestamp decrypts properly.  The client MAY check that the timestamp

-   is in some reasonable skew of the current time.  The client MUST NOT

-   require that the timestamp be identical to the timestamp in the

-   issued credentials or the returned message.

-

-   The encrypted challenge FAST factor provides the following

-   facilities: client-authentication, KDC authentication.  It does not

-   provide the strengthening-reply-key facility.  The security

-   considerations section of this document provides an explanation why

-   the security requirements are met.

-

-   Conforming implementations MUST support the encrypted challenge FAST

-   factor.

-

-6.6.  Authentication Strength Indication

-

-   Implementations that have pre-authentication mechanisms offering

-   significantly different strengths of client authentication MAY choose

-   to keep track of the strength of the authentication used as an input

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 32]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   into policy decisions.  For example, some principals might require

-   strong pre-authentication, while less sensitive principals can use

-   relatively weak forms of pre-authentication like encrypted timestamp.

-

-   An AuthorizationData data type AD-Authentication-Strength is defined

-   for this purpose.

-

-        AD-authentication-strength         TBA

-

-   The corresponding ad-data field contains the DER encoding of the pre-

-   authentication data set as defined in Section 6.4.  This set contains

-   all the pre-authentication mechanisms that were used to authenticate

-   the client.  If only one pre-authentication mechanism was used to

-   authenticate the client, the pre-authentication set contains one

-   element.

-

-   The AD-authentication-strength element MUST be included in the AD-IF-

-   RELEVANT, thus it can be ignored if it is unknown to the receiver.

-

-

-7.  IANA Considerations

-

-   This document defines several new pa-data types, key usages and error

-   codes.  In addition it would be good to track which pa-data items are

-   only to be used as FAST factors.

-

-

-8.  Security Considerations

-

-   The kdc-referrals option in the Kerberos FAST padata requests the KDC

-   to act as the client to follow referrals.  This can overload the KDC.

-   To limit the damages of denied of service using this option, KDCs MAY

-   restrict the number of simultaneous active requests with this option

-   for any given client principal.

-

-   Because the client secrets are known only to the client and the KDC,

-   the verification of the authenticated timestamp proves the client's

-   identity, the verification of the authenticated timestamp in the KDC

-   reply proves that the expected KDC responded.  The encrypted reply

-   key is contained in the rep-key in the PA-FX-FAST-REPLY.  Therefore,

-   the authenticated timestamp FAST factor as a pre-authentication

-   mechanism offers the following facilities: client-authentication,

-   replacing-reply-key, KDC-authentication.  There is no un-

-   authenticated clear text introduced by the authenticated timestamp

-   FAST factor.

-

-

-

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 33]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-9.  Acknowledgements

-

-   Sam Hartman would like to thank the MIT Kerberos Consortium for its

-   funding of his time on this project prior to April 2008.

-

-   Several suggestions from Jeffery Hutzman based on early revisions of

-   this documents led to significant improvements of this document.

-

-   The proposal to ask one KDC to chase down the referrals and return

-   the final ticket is based on requirements in [ID.CROSS].

-

-   Joel Webber had a proposal for a mechanism similar to FAST that

-   created a protected tunnel for Kerberos pre-authentication.

-

-

-10.  References

-

-10.1.  Normative References

-

-   [KRB-ANON]

-              Zhu, L. and P. Leach, "Kerberos Anonymity Support",

-              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.

-

-   [REFERRALS]

-              Raeburn, K. and L. Zhu, "Generating KDC Referrals to

-              Locate Kerberos Realms",

-              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in

-              progress), 2007.

-

-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

-              Requirement Levels", BCP 14, RFC 2119, March 1997.

-

-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for

-              Kerberos 5", RFC 3961, February 2005.

-

-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The

-              Kerberos Network Authentication Service (V5)", RFC 4120,

-              July 2005.

-

-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial

-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 34]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-   [SHA2]     National Institute of Standards and Technology, "Secure 

-              Hash Standard (SHS)", Federal Information Processing 

-              Standards Publication 180-2, August 2002.  

-

-   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,

-              Information technology - Abstract Syntax Notation One

-              (ASN.1): Specification of basic notation.

-   

-   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,

-              Information technology - ASN.1 encoding Rules:

-              Specification of Basic Encoding Rules (BER), Canonical

-              Encoding Rules (CER) and Distinguished Encoding Rules

-              (DER).              

-

-10.2.  Informative References

-

-   [EKE]      Bellovin, S. M. and M. Merritt. "Augmented 

-              Encrypted Key Exchange: A Password-Based Protocol Secure 

-              Against Dictionary Attacks and Password File Compromise". 

-              Proceedings of the 1st ACM Conference on Computer and 

-              Communications Security, ACM Press, November 1993.

-   

-   [HKDF]     Dang, Q. and P. Polk, draft-dang-nistkdf, work in 

-              progress.

-

-   [IEEE1363.2] 

-              IEEE P1363.2: Password-Based Public-Key Cryptography, 

-              2004.

-

-   [ID.CROSS]

-              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem

-              Statement on the Operation of Kerberos in a Specific

-              System", draft-sakane-krb-cross-problem-statement-02.txt

-              (work in progress), April 2007.

-

-   [KRB-WG.SAM]

-

-              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,

-              "Integrating Single-use Authentication Mechanisms with

-              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in

-              progress), October 2003.

-

-

-Appendix A.  Change History

-

-   RFC editor, please remove this section before publication.

-

-A.1.  Changes since 07

-

-      Propose replacement of authenticated timestamp with encrypted

-      challenge.  The desire to avoid clients needing time

-      synchronization and to simply the factor.

-      Add a requirement that any FAST armor scheme must provide a fresh

-      key for each conversation.  This allows us to assume that anything

-      encrypted/integrity protected in the right key is fresh and not

-      subject to cross-conversation cut&paste.

-      Removed heartbeat padata.  The KDC will double up messages if it

-      needs to; the client simply sends its message and waits for the

-      next response.

-      Define PA_AUTHENTICATION_SET_SELECTED

-      Clarify a KDC cannot ignore padata is has clamed to support

-

-A.2.  Changes since 06

-

-      Note that even for replace reply key it is likely that the side

-      using the mechanism will know that the other side supports it.

-      Since it is reasonablly unlikely we'll need a container mechanism

-      other than FAST itself, we don't need to optimize for that case.

-      So, we want to optimize for implementation simplicity.  Thus if

-      you do have such a container mechanism interacting with

-      authentication sets we'll assume that the hint need to describe

-      hints for all contained mechanisms.  This closes out a long-

-      standing issue.

-      Write up what Sam believes is the consensus on UI and prompts in

-      the authentication set: clients MAY assume that they have all the

-      UI information they need.

-

-

-Appendix B.  ASN.1 module

-

-     KerberosPreauthFramework {

-           iso(1) identified-organization(3) dod(6) internet(1)

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 35]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-           security(5) kerberosV5(2) modules(4) preauth-framework(3)

-     } DEFINITIONS EXPLICIT TAGS ::= BEGIN

-

-     IMPORTS

-          KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,

-          Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,

-          Microseconds, KerberosFlags

-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)

-                 dod(6) internet(1) security(5) kerberosV5(2)

-                 modules(4) krb5spec2(2) };

-                 -- as defined in RFC 4120.

-

-     PA-FX-COOKIE ::= SEQUENCE {

-         conversationId  [0] OCTET STRING,

-            -- Contains the identifier of this conversation. This field

-            -- must contain the same value for all the messages

-            -- within the same conversation.

-         enc-binding-key [1] EncryptedData OPTIONAL,

-                         -- EncryptionKey --

-            -- This field is present when and only when a FAST

-            -- padata as defined in Section 6.5 is included.

-            -- The encrypted data, when decrypted, contains an

-            -- EncryptionKey structure.

-            -- This encryption key is encrypted using the armor key

-            -- (defined in Section 6.5.1), and the key usage for the

-            -- encryption is KEY_USAGE_FAST_BINDING_KEY.

-            -- Present only once in a converstation.

-         cookie          [2] OCTET STRING OPTIONAL,

-            -- Opaque data, for use to associate all the messages in

-            -- a single conversation between the client and the KDC.

-            -- This is generated by the KDC and the client MUST copy

-            -- the exact cookie encapsulated in a PA_FX_COOKIE data

-            -- element into the next message of the same conversation.

-         ...

-     }

-

-     PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM

-

-     PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {

-         pa-type      [0] Int32,

-             -- same as padata-type.

-         pa-hint      [1] OCTET STRING OPTIONAL,

-         pa-value  [2] OCTET STRING OPTIONAL,

-         ...

-     }

-

-     KrbFastArmor ::= SEQUENCE {

-         armor-type   [0] Int32,

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 36]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-             -- Type of the armor.

-         armor-value  [1] OCTET STRING,

-             -- Value of the armor.

-         ...

-     }

-

-     PA-FX-FAST-REQUEST ::= CHOICE {

-         armored-data [0] KrbFastArmoredReq,

-         ...

-     }

-

-     KrbFastArmoredReq ::= SEQUENCE {

-         armor        [0] KrbFastArmor OPTIONAL,

-             -- Contains the armor that identifies the armor key.

-             -- MUST be present in AS-REQ.

-             -- MUST be absent in TGS-REQ.

-         req-checksum [1] Checksum,

-             -- Checksum performed over the type KDC-REQ-BODY for

-             -- the req-body field of the KDC-REQ structure defined in

-             -- [RFC4120]

-             -- The checksum key is the armor key, the checksum

-             -- type is the required checksum type for the enctype of

-             -- the armor key, and the key usage number is

-             -- KEY_USAGE_FAST_REA_CHKSUM.

-         enc-fast-req [2] EncryptedData, -- KrbFastReq --

-             -- The encryption key is the armor key, and the key usage

-             -- number is KEY_USAGE_FAST_ENC.

-         ...

-     }

-

-     KrbFastReq ::= SEQUENCE {

-         fast-options [0] FastOptions,

-             -- Additional options.

-         padata       [1] SEQUENCE OF PA-DATA,

-             -- padata typed holes.

-         req-body     [2] KDC-REQ-BODY,

-             -- Contains the KDC request body as defined in Section

-             -- 5.4.1 of [RFC4120].

-             -- This req-body field is preferred over the outer field

-             -- in the KDC request.

-          ...

-     }

-

-     FastOptions ::= KerberosFlags

-         -- reserved(0),

-         -- anonymous(1),

-         -- kdc-referrals(16)

-

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 37]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-     PA-FX-FAST-REPLY ::= CHOICE {

-         armored-data [0] KrbFastArmoredRep,

-         ...

-     }

-

-     KrbFastArmoredRep ::= SEQUENCE {

-         enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --

-             -- The encryption key is the armor key in the request, and

-             -- the key usage number is KEY_USAGE_FAST_REP.

-         ...

-     }

-

-     KrbFastResponse ::= SEQUENCE {

-         padata      [0] SEQUENCE OF PA-DATA,

-             -- padata typed holes.

-         rep-key     [1] EncryptionKey OPTIONAL,

-             -- This, if present, replaces the reply key for AS and TGS.

-             -- MUST be absent in KRB-ERROR.

-         finished    [2] KrbFastFinished OPTIONAL,

-             -- MUST be present if the client is authenticated,

-             -- absent otherwise.

-             -- Typically this is present if and only if the containing

-             -- message is the last one in a conversation.

-         ...

-     }

-

-     KrbFastFinished ::= SEQUENCE {

-         timestamp   [0] KerberosTime,

-         usec        [1] Microseconds,

-             -- timestamp and usec represent the time on the KDC when

-             -- the reply was generated.

-         crealm      [2] Realm,

-         cname       [3] PrincipalName,

-             -- Contains the client realm and the client name.

-         checksum    [4] Checksum,

-             -- Checksum performed over all the messages in the

-             -- conversation, except the containing message.

-             -- The checksum key is the binding key as defined in

-             -- Section 6.3, and the checksum type is the required

-             -- checksum type of the binding key.

-         ...

-     }

-

-     EncryptedChallenge ::= EncryptedData

-             -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key

-             -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the

-             --  client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.

-     END

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 38]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-Authors' Addresses

-

-   Larry Zhu

-   Microsoft Corporation

-   One Microsoft Way

-   Redmond, WA  98052

-   US

-

-   Email: lzhu@microsoft.com

-

-

-   Sam hartman

-   Painless Security

-

-   Email: hartmans-ietf@mit.edu

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 39]

-

-Internet-Draft         Kerberos Preauth Framework              July 2008

-

-

-Full Copyright Statement

-

-   Copyright (C) The IETF Trust (2008).

-

-   This document is subject to the rights, licenses and restrictions

-   contained in BCP 78, and except as set forth therein, the authors

-   retain all their rights.

-

-   This document and the information contained herein are provided on an

-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS

-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF

-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-Intellectual Property

-

-   The IETF takes no position regarding the validity or scope of any

-   Intellectual Property Rights or other rights that might be claimed to

-   pertain to the implementation or use of the technology described in

-   this document or the extent to which any license under such rights

-   might or might not be available; nor does it represent that it has

-   made any independent effort to identify any such rights.  Information

-   on the procedures with respect to rights in RFC documents can be

-   found in BCP 78 and BCP 79.

-

-   Copies of IPR disclosures made to the IETF Secretariat and any

-   assurances of licenses to be made available, or the result of an

-   attempt made to obtain a general license or permission for the use of

-   such proprietary rights by implementers or users of this

-   specification can be obtained from the IETF on-line IPR repository at

-   http://www.ietf.org/ipr.

-

-   The IETF invites any interested party to bring to its attention any

-   copyrights, patents or patent applications, or other proprietary

-   rights that may cover technology that may be required to implement

-   this standard.  Please address the information to the IETF at

-   ietf-ipr@ietf.org.

-

-

-

-

-

-

-

-

-

-

-

-Zhu & Hartman           Expires January 15, 2009               [Page 40]

-

-

diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-09.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-09.txt
deleted file mode 100644
index 9a4d76ad9..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-09.txt
+++ /dev/null
@@ -1,2521 +0,0 @@
-
-
-
-Kerberos Working Group                                        S. Hartman
-Internet-Draft                                         Painless Security
-Updates: 4120 (if approved)                                       L. Zhu
-Intended status: Standards Track                   Microsoft Corporation
-Expires: August 15, 2009                               February 11, 2009
-
-
-        A Generalized Framework for Kerberos Pre-Authentication
-                 draft-ietf-krb-wg-preauth-framework-09
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 15, 2009.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.
-
-Abstract
-
-   Kerberos is a protocol for verifying the identity of principals
-
-
-
-Hartman & Zhu            Expires August 15, 2009                [Page 1]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   (e.g., a workstation user or a network server) on an open network.
-   The Kerberos protocol provides a mechanism called pre-authentication
-   for proving the identity of a principal and for better protecting the
-   long-term secrets of the principal.
-
-   This document describes a model for Kerberos pre-authentication
-   mechanisms.  The model describes what state in the Kerberos request a
-   pre-authentication mechanism is likely to change.  It also describes
-   how multiple pre-authentication mechanisms used in the same request
-   will interact.
-
-   This document also provides common tools needed by multiple pre-
-   authentication mechanisms.  One of these tools is a secure channel
-   between the client and the KDC with a reply key delivery mechanism;
-   this secure channel can be used to protect the authentication
-   exchange thus eliminate offline dictionary attacks.  With these
-   tools, it is relatively straightforward to chain multiple
-   authentication mechanisms, utilize a different key management system,
-   or support a new key agreement algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu            Expires August 15, 2009                [Page 2]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Conventions and Terminology Used in This Document  . . . . . .  6
-   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  6
-     3.1.  Information Managed by the Pre-authentication Model  . . .  7
-     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  9
-     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . . 10
-     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 11
-   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 12
-     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 13
-     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 13
-     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 14
-     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 15
-   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 15
-   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 16
-     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 16
-     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 18
-     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 18
-     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 20
-     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 22
-       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 23
-       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 25
-       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 29
-       6.5.4.  Authenticated Kerberos Error Messages using
-               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 32
-       6.5.5.  Outer and Inner Requests . . . . . . . . . . . . . . . 33
-       6.5.6.  The Encrypted Challenge FAST Factor  . . . . . . . . . 33
-     6.6.  Authentication Strength Indication . . . . . . . . . . . . 35
-   7.  Assigned Constants . . . . . . . . . . . . . . . . . . . . . . 35
-     7.1.  New Errors . . . . . . . . . . . . . . . . . . . . . . . . 36
-     7.2.  Key Usage Numbers  . . . . . . . . . . . . . . . . . . . . 36
-     7.3.  Authorization Data Elements  . . . . . . . . . . . . . . . 36
-     7.4.  New PA-DATA Types  . . . . . . . . . . . . . . . . . . . . 36
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 36
-     8.1.  Pre-authentication and Typed Data  . . . . . . . . . . . . 36
-     8.2.  Fast Armor Types . . . . . . . . . . . . . . . . . . . . . 38
-     8.3.  FAST Options . . . . . . . . . . . . . . . . . . . . . . . 39
-   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 39
-   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 40
-     11.2. Informative References . . . . . . . . . . . . . . . . . . 40
-   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 41
-     A.1.  Changes since 08 . . . . . . . . . . . . . . . . . . . . . 41
-     A.2.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 42
-     A.3.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 42
-   Appendix B.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 42
-
-
-
-Hartman & Zhu            Expires August 15, 2009                [Page 3]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu            Expires August 15, 2009                [Page 4]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-1.  Introduction
-
-   The core Kerberos specification [RFC4120] treats pre-authentication
-   data as an opaque typed hole in the messages to the KDC that may
-   influence the reply key used to encrypt the KDC reply.  This
-   generality has been useful: pre-authentication data is used for a
-   variety of extensions to the protocol, many outside the expectations
-   of the initial designers.  However, this generality makes designing
-   more common types of pre-authentication mechanisms difficult.  Each
-   mechanism needs to specify how it interacts with other mechanisms.
-   Also, problems like combining a key with the long-term secrets or
-   proving the identity of the user are common to multiple mechanisms.
-   Where there are generally well-accepted solutions to these problems,
-   it is desirable to standardize one of these solutions so mechanisms
-   can avoid duplication of work.  In other cases, a modular approach to
-   these problems is appropriate.  The modular approach will allow new
-   and better solutions to common pre-authentication problems to be used
-   by existing mechanisms as they are developed.
-
-   This document specifies a framework for Kerberos pre-authentication
-   mechanisms.  It defines the common set of functions that pre-
-   authentication mechanisms perform as well as how these functions
-   affect the state of the request and reply.  In addition several
-   common tools needed by pre-authentication mechanisms are provided.
-   Unlike [RFC3961], this framework is not complete--it does not
-   describe all the inputs and outputs for the pre-authentication
-   mechanisms.  Pre-Authentication mechanism designers should try to be
-   consistent with this framework because doing so will make their
-   mechanisms easier to implement.  Kerberos implementations are likely
-   to have plugin architectures for pre-authentication; such
-   architectures are likely to support mechanisms that follow this
-   framework plus commonly used extensions.  This framework also
-   facilitates combining multiple pre-authentication mechanisms, each of
-   which may represent an authentication factor, into a single multi-
-   factor pre-authentication mechanism.
-
-   One of these common tools is the flexible authentication secure
-   tunneling (FAST) padata type.  FAST provides a protected channel
-   between the client and the KDC, and it can optionally deliver a reply
-   key within the protected channel.  Based on FAST, pre-authentication
-   mechanisms can extend Kerberos with ease, to support, for example,
-   password authenticated key exchange (PAKE) protocols with zero
-   knowledge password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-
-   authentication mechanism can be encapsulated in the FAST messages as
-   defined in Section 6.5.  A pre-authentication type carried within
-   FAST is called a FAST factor.  Creating a FAST factor is the easiest
-   path to create a new pre-authentication mechanism.  FAST factors are
-   significantly easier to analyze from a security standpoint than other
-
-
-
-Hartman & Zhu            Expires August 15, 2009                [Page 5]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   pre-authentication mechanisms.
-
-   Mechanism designers should design FAST factors, instead of new pre-
-   authentication mechanisms outside of FAST.
-
-
-2.  Conventions and Terminology Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   The word padata is used as a shorthand for pre-authentication data.
-
-   A conversation is the set of all authentication messages exchanged
-   between the client and the client's KDCs in order to authenticate the
-   client principal.  A conversation as defined here consists of all
-   messages that are necessary to complete the authentication between
-   the client and the client's KDCs.
-
-   If the KDC reply in an Authentication Service (AS) exchange is
-   verified, the KDC is authenticated by the client.  In this document,
-   verification of the KDC reply is used as a synonym of authentication
-   of the KDC.
-
-   Lastly, this document should be read only after reading the documents
-   describing the Kerberos cryptography framework [RFC3961] and the core
-   Kerberos protocol [RFC4120].  This document may freely use
-   terminology and notation from these documents without reference or
-   further explanation.
-
-
-3.  Model for Pre-Authentication
-
-   When a Kerberos client wishes to obtain a ticket using the
-   authentication server, it sends an initial Authentication Service
-   (AS) request.  If pre-authentication is required but not being used,
-   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
-   Alternatively, if the client knows what pre-authentication to use, it
-   MAY optimize away a round-trip and send an initial request with
-   padata included in the initial request.  If the client includes the
-   padata computed using the wrong pre-authentication mechanism or
-   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
-   indication of what padata should have been included.  In that case,
-   the client MUST retry with no padata and examine the error data of
-   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
-   authentication information in the accompanying error data of
-   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
-
-
-
-Hartman & Zhu            Expires August 15, 2009                [Page 6]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   then retry.
-
-   The conventional KDC maintains no state between two requests;
-   subsequent requests may even be processed by a different KDC.  On the
-   other hand, the client treats a series of exchanges with KDCs as a
-   single conversation.  Each exchange accumulates state and hopefully
-   brings the client closer to a successful authentication.
-
-   These models for state management are in apparent conflict.  For many
-   of the simpler pre-authentication scenarios, the client uses one
-   round trip to find out what mechanisms the KDC supports.  Then the
-   next request contains sufficient pre-authentication for the KDC to be
-   able to return a successful reply.  For these simple scenarios, the
-   client only sends one request with pre-authentication data and so the
-   conversation is trivial.  For more complex conversations, the KDC
-   needs to provide the client with a cookie to include in future
-   requests to capture the current state of the authentication session.
-   Handling of multiple round-trip mechanisms is discussed in
-   Section 6.3.
-
-   This framework specifies the behavior of Kerberos pre-authentication
-   mechanisms used to identify users or to modify the reply key used to
-   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
-   extensions to Kerberos that have nothing to do with proving the
-   identity of the user or establishing a reply key.  Such extensions
-   are outside the scope of this framework.  However mechanisms that do
-   accomplish these goals should follow this framework.
-
-   This framework specifies the minimum state that a Kerberos
-   implementation needs to maintain while handling a request in order to
-   process pre-authentication.  It also specifies how Kerberos
-   implementations process the padata at each step of the AS request
-   process.
-
-3.1.  Information Managed by the Pre-authentication Model
-
-   The following information is maintained by the client and KDC as each
-   request is being processed:
-
-   o  The reply key used to encrypt the KDC reply
-
-   o  How strongly the identity of the client has been authenticated
-
-   o  Whether the reply key has been used in this conversation
-
-   o  Whether the reply key has been replaced in this conversation
-
-
-
-
-
-Hartman & Zhu            Expires August 15, 2009                [Page 7]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   o  Whether the contents of the KDC reply can be verified by the
-      client principal
-
-
-   Conceptually, the reply key is initially the long-term key of the
-   principal.  However, principals can have multiple long-term keys
-   because of support for multiple encryption types, salts and
-   string2key parameters.  As described in Section 5.2.7.5 of the
-   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
-   the client what types of keys are available.  Thus in full
-   generality, the reply key in the pre-authentication model is actually
-   a set of keys.  At the beginning of a request, it is initialized to
-   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
-   the KDC.  If multiple reply keys are available, the client chooses
-   which one to use.  Thus the client does not need to treat the reply
-   key as a set.  At the beginning of a request, the client picks a key
-   to use.
-
-   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
-   INFO2 element.  Since the KDC already knows the client's list of
-   supported enctypes from the request, no interoperability problems are
-   created by choosing a single possible reply key.  This way, the KDC
-   implementation avoids the complexity of treating the reply key as a
-   set.
-
-   When the padata in the request is verified by the KDC, then the
-   client is known to have that key, therefore the KDC SHOULD pick the
-   same key as the reply key.
-
-   At the beginning of handling a message on both the client and the
-   KDC, the client's identity is not authenticated.  A mechanism may
-   indicate that it has successfully authenticated the client's
-   identity.  This information is useful to keep track of on the client
-   in order to know what pre-authentication mechanisms should be used.
-   The KDC needs to keep track of whether the client is authenticated
-   because the primary purpose of pre-authentication is to authenticate
-   the client identity before issuing a ticket.  The handling of
-   authentication strength using various authentication mechanisms is
-   discussed in Section 6.6.
-
-   Initially the reply key has not been used.  A pre-authentication
-   mechanism that uses the reply key to encrypt or checksum some data in
-   the generation of new keys MUST indicate that the reply key is used.
-   This state is maintained by the client and the KDC to enforce the
-   security requirement stated in Section 4.3 that the reply key SHOULD
-   NOT be replaced after it is used.
-
-   Initially the reply key has not been replaced.  If a mechanism
-
-
-
-Hartman & Zhu            Expires August 15, 2009                [Page 8]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   implements the Replace Reply Key facility discussed in Section 4.3,
-   then the state MUST be updated to indicate that the reply key has
-   been replaced.  Once the reply key has been replaced, knowledge of
-   the reply key is insufficient to authenticate the client.  The reply
-   key is marked replaced in exactly the same situations as the KDC
-   reply is marked as not being verified to the client principal.
-   However, while mechanisms can verify the KDC reply to the client,
-   once the reply key is replaced, then the reply key remains replaced
-   for the remainder of the conversation.
-
-   Without pre-authentication, the client knows that the KDC reply is
-   authentic and has not been modified because it is encrypted in a
-   long-term key of the client.  Only the KDC and the client know that
-   key.  So at the start of a conversation, the KDC reply is presumed to
-   be verified using the client principal's long-term key.  It should be
-   noted that in this document, verifying the KDC reply means
-   authenticating the KDC, and these phrases are used interchangeably.
-   Any pre-authentication mechanism that sets a new reply key not based
-   on the principal's long-term secret MUST either verify the KDC reply
-   some other way or indicate that the reply is not verified.  If a
-   mechanism indicates that the reply is not verified then the client
-   implementation MUST return an error unless a subsequent mechanism
-   verifies the reply.  The KDC needs to track this state so it can
-   avoid generating a reply that is not verified.
-
-   The typical Kerberos request does not provide a way for the client
-   machine to know that it is talking to the correct KDC.  Someone who
-   can inject packets into the network between the client machine and
-   the KDC and who knows the password that the user will give to the
-   client machine can generate a KDC reply that will decrypt properly.
-   So, if the client machine needs to authenticate that the user is in
-   fact the named principal, then the client machine needs to do a TGS
-   request for itself as a service.  Some pre-authentication mechanisms
-   may provide a way for the client machine to authenticate the KDC.
-   Examples of this include signing the reply that can be verified using
-   a well-known public key or providing a ticket for the client machine
-   as a service.
-
-3.2.  Initial Pre-authentication Required Error
-
-   Typically a client starts a conversation by sending an initial
-   request with no pre-authentication.  If the KDC requires pre-
-   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
-   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
-   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
-   (defined in Section 6.3) for pre-authentication configurations that
-   use multi-round-trip mechanisms; see Section 3.4 for details of that
-   case.
-
-
-
-Hartman & Zhu            Expires August 15, 2009                [Page 9]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   The KDC needs to choose which mechanisms to offer the client.  The
-   client needs to be able to choose what mechanisms to use from the
-   first message.  For example consider the KDC that will accept
-   mechanism A followed by mechanism B or alternatively the single
-   mechanism C. A client that supports A and C needs to know that it
-   should not bother trying A.
-
-   Mechanisms can either be sufficient on their own or can be part of an
-   authentication set--a group of mechanisms that all need to
-   successfully complete in order to authenticate a client.  Some
-   mechanisms may only be useful in authentication sets; others may be
-   useful alone or in authentication sets.  For the second group of
-   mechanisms, KDC policy dictates whether the mechanism will be part of
-   an authentication set or offered alone.  For each mechanism that is
-   offered alone, the KDC includes the pre-authentication type ID of the
-   mechanism in the padata sequence returned in the
-   KDC_ERR_PREAUTH_REQUIRED error.
-
-   The KDC SHOULD NOT send data that is encrypted in the long-term
-   password-based key of the principal.  Doing so has the same security
-   exposures as the Kerberos protocol without pre-authentication.  There
-   are few situations where the KDC needs to expose cipher text
-   encrypted in a weak key before the client has proven knowledge of
-   that key, and pre-authentication is desirable.
-
-3.3.  Client to KDC
-
-   This description assumes that a client has already received a
-   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
-   optimistic pre-authentication then the client needs to guess values
-   for the information it would normally receive from that error
-   response or use cached information obtained in prior interactions
-   with the KDC.
-
-   The client starts by initializing the pre-authentication state as
-   specified.  It then processes the padata in the
-   KDC_ERR_PREAUTH_REQUIRED.
-
-   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
-   client MAY ignore any padata it chooses unless doing so violates a
-   specification to which the client conforms.  Clients conforming to
-   this specification MUST NOT ignore the padata defined in Section 6.3.
-   Clients SHOULD process padata unrelated to this framework or other
-   means of authenticating the user.  Clients SHOULD choose one
-   authentication set or mechanism that could lead to authenticating the
-   user and ignore the rest.  Since the list of mechanisms offered by
-   the KDC is in the decreasing preference order, clients typically
-   choose the first mechanism or authentication set that the client can
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 10]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   usefully perform.  If a client chooses to ignore a padata it MUST NOT
-   process the padata, allow the padata to affect the pre-authentication
-   state, nor respond to the padata.
-
-   For each padata the client chooses to process, the client processes
-   the padata and modifies the pre-authentication state as required by
-   that mechanism.  Padata are processed in the order received from the
-   KDC.
-
-   After processing the padata in the KDC error, the client generates a
-   new request.  It processes the pre-authentication mechanisms in the
-   order in which they will appear in the next request, updating the
-   state as appropriate.  The request is sent when it is complete.
-
-3.4.  KDC to Client
-
-   When a KDC receives an AS request from a client, it needs to
-   determine whether it will respond with an error or an AS reply.
-   There are many causes for an error to be generated that have nothing
-   to do with pre-authentication; they are discussed in the core
-   Kerberos specification.
-
-   From the standpoint of evaluating the pre-authentication, the KDC
-   first starts by initializing the pre-authentication state.  If a PA-
-   FX-COOKIE pre-authentication data item is present, it is processed
-   first; see Section 6.3 for a definition.  It then processes the
-   padata in the request.  As mentioned in Section 3.3, the KDC MAY
-   ignore padata that is inappropriate for the configuration and MUST
-   ignore padata of an unknown type.  The KDC MUST NOT ignore padata of
-   types used in previous messages.  For example, if a KDC issues a
-   KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the
-   KDC cannot ignore padata of type x received in an AS-REQ message from
-   the client.
-
-   At this point the KDC decides whether it will issue an error or a
-   reply.  Typically a KDC will issue a reply if the client's identity
-   has been authenticated to a sufficient degree.
-
-   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC
-   first starts by initializing the pre-authentication state.  Then it
-   processes any padata in the client's request in the order provided by
-   the client.  Mechanisms that are not understood by the KDC are
-   ignored.  Next, it generates padata for the error response, modifying
-   the pre-authentication state appropriately as each mechanism is
-   processed.  The KDC chooses the order in which it will generate
-   padata (and thus the order of padata in the response), but it needs
-   to modify the pre-authentication state consistently with the choice
-   of order.  For example, if some mechanism establishes an
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 11]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   authenticated client identity, then the subsequent mechanisms in the
-   generated response receive this state as input.  After the padata is
-   generated, the error response is sent.  Typically the errors with the
-   code KDC_ERR_MORE_PREAUTH_DATA_NEEDED in a conversation will include
-   KDC state as discussed in Section 6.3.
-
-   To generate a final reply, the KDC generates the padata modifying the
-   pre-authentication state as necessary.  Then it generates the final
-   response, encrypting it in the current pre-authentication reply key.
-
-
-4.  Pre-Authentication Facilities
-
-   Pre-Authentication mechanisms can be thought of as providing various
-   conceptual facilities.  This serves two useful purposes.  First,
-   mechanism authors can choose only to solve one specific small
-   problem.  It is often useful for a mechanism designed to offer key
-   management not to directly provide client authentication but instead
-   to allow one or more other mechanisms to handle this need.  Secondly,
-   thinking about the abstract services that a mechanism provides yields
-   a minimum set of security requirements that all mechanisms providing
-   that facility must meet.  These security requirements are not
-   complete; mechanisms will have additional security requirements based
-   on the specific protocol they employ.
-
-   A mechanism is not constrained to only offering one of these
-   facilities.  While such mechanisms can be designed and are sometimes
-   useful, many pre-authentication mechanisms implement several
-   facilities.  By combining multiple facilities in a single mechanism,
-   it is often easier to construct a secure, simple solution than by
-   solving the problem in full generality.  Even when mechanisms provide
-   multiple facilities, they need to meet the security requirements for
-   all the facilities they provide.  If the FAST factor approach is
-   used, it is likely that one or a small number of facilities can be
-   provided by a single mechanism without complicating the security
-   analysis.
-
-   According to Kerberos extensibility rules (Section 1.5 of the
-   Kerberos specification [RFC4120]), an extension MUST NOT change the
-   semantics of a message unless a recipient is known to understand that
-   extension.  Because a client does not know that the KDC supports a
-   particular pre-authentication mechanism when it sends an initial
-   request, a pre-authentication mechanism MUST NOT change the semantics
-   of the request in a way that will break a KDC that does not
-   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
-   clients that affect the core semantics unless the client has
-   indicated support for the message.
-
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 12]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   The only state in this model that would break the interpretation of a
-   message is changing the expected reply key.  If one mechanism changed
-   the reply key and a later mechanism used that reply key, then a KDC
-   that interpreted the second mechanism but not the first would fail to
-   interpret the request correctly.  In order to avoid this problem,
-   extensions that change core semantics are typically divided into two
-   parts.  The first part proposes a change to the core semantic--for
-   example proposes a new reply key.  The second part acknowledges that
-   the extension is understood and that the change takes effect.
-   Section 4.2 discusses how to design mechanisms that modify the reply
-   key to be split into a proposal and acceptance without requiring
-   additional round trips to use the new reply key in subsequent pre-
-   authentication.  Other changes in the state described in Section 3.1
-   can safely be ignored by a KDC that does not understand a mechanism.
-   Mechanisms that modify the behavior of the request outside the scope
-   of this framework need to carefully consider the Kerberos
-   extensibility rules to avoid similar problems.
-
-4.1.  Client-authentication Facility
-
-   The client authentication facility proves the identity of a user to
-   the KDC before a ticket is issued.  Examples of mechanisms
-   implementing this facility include the encrypted timestamp facility
-   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
-   Mechanisms that provide this facility are expected to mark the client
-   as authenticated.
-
-   Mechanisms implementing this facility SHOULD require the client to
-   prove knowledge of the reply key before transmitting a successful KDC
-   reply.  Otherwise, an attacker can intercept the pre-authentication
-   exchange and get a reply to attack.  One way of proving the client
-   knows the reply key is to implement the Replace Reply Key facility
-   along with this facility.  The PKINIT mechanism [RFC4556] implements
-   Client Authentication alongside Replace Reply Key.
-
-   If the reply key has been replaced, then mechanisms such as
-   encrypted-timestamp that rely on knowledge of the reply key to
-   authenticate the client MUST NOT be used.
-
-4.2.  Strengthening-reply-key Facility
-
-   Particularly when dealing with keys based on passwords, it is
-   desirable to increase the strength of the key by adding additional
-   secrets to it.  Examples of sources of additional secrets include the
-   results of a Diffie-Hellman key exchange or key bits from the output
-   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
-   be first combined with the existing reply key and then converted to a
-   protocol key using tools defined in Section 6.1.
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 13]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   Typically a mechanism implementing this facility will know that the
-   other side of the exchange supports the facility before the reply key
-   is changed.  For example, a mechanism might need to learn the
-   certificate for a KDC before encrypting a new key in the public key
-   belonging to that certificate.  However, if a mechanism implementing
-   this facility wishes to modify the reply key before knowing that the
-   other party in the exchange supports the mechanism, it proposes
-   modifying the reply key.  The other party then includes a message
-   indicating that the proposal is accepted if it is understood and
-   meets policy.  In many cases it is desirable to use the new reply key
-   for client authentication and for other facilities.  Waiting for the
-   other party to accept the proposal and actually modify the reply key
-   state would add an additional round trip to the exchange.  Instead,
-   mechanism designers are encouraged to include a typed hole for
-   additional padata in the message that proposes the reply key change.
-   The padata included in the typed hole are generated assuming the new
-   reply key.  If the other party accepts the proposal, then these
-   padata are considered as an inner level.  As with the outer level,
-   one authentication set or mechanism is typically chosen for client
-   authentication, along with auxiliary mechanisms such as KDC cookies,
-   and other mechanisms are ignored.  When mechanisms include such a
-   container, the hint provided for use in authentication sets (as
-   defined in Section 6.4) MUST contain a sequence of inner mechanisms
-   along with hints for those mechanisms.  The party generating the
-   proposal can determine whether the padata were processed based on
-   whether the proposal for the reply key is accepted.
-
-   The specific formats of the proposal message, including where padata
-   are included is a matter for the mechanism specification.  Similarly,
-   the format of the message accepting the proposal is mechanism-
-   specific.
-
-   Mechanisms implementing this facility and including a typed hole for
-   additional padata MUST checksum that padata using a keyed checksum or
-   encrypt the padata.  This requirement protects against modification
-   of the contents of the typed hole.  By modifying these contents an
-   attacker might be able to choose which mechanism is used to
-   authenticate the client, or to convince a party to provide text
-   encrypted in a key that the attacker had manipulated.  It is
-   important that mechanisms strengthen the reply key enough that using
-   it to checksum padata is appropriate.
-
-4.3.  Replacing-reply-key Facility
-
-   The Replace Reply Key facility replaces the key in which a successful
-   AS reply will be encrypted.  This facility can only be used in cases
-   where knowledge of the reply key is not used to authenticate the
-   client.  The new reply key MUST be communicated to the client and the
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 14]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   KDC in a secure manner.  This facility MUST NOT be used if there can
-   be a man-in-the-middle between the client and the KDC.  Mechanisms
-   implementing this facility MUST mark the reply key as replaced in the
-   pre-authentication state.  Mechanisms implementing this facility MUST
-   either provide a mechanism to verify the KDC reply to the client or
-   mark the reply as unverified in the pre-authentication state.
-   Mechanisms implementing this facility SHOULD NOT be used if a
-   previous mechanism has used the reply key.
-
-   As with the strengthening-reply-key facility, Kerberos extensibility
-   rules require that the reply key not be changed unless both sides of
-   the exchange understand the extension.  In the case of this facility
-   it will likely be the case for both sides to know that the facility
-   is available by the time that the new key is available to be used.
-   However, mechanism designers can use a container for padata in a
-   proposal message as discussed in Section 4.2 if appropriate.
-
-4.4.  KDC-authentication Facility
-
-   This facility verifies that the reply comes from the expected KDC.
-   In traditional Kerberos, the KDC and the client share a key, so if
-   the KDC reply can be decrypted then the client knows that a trusted
-   KDC responded.  Note that the client machine cannot trust the client
-   unless the machine is presented with a service ticket for it
-   (typically the machine can retrieve this ticket by itself).  However,
-   if the reply key is replaced, some mechanism is required to verify
-   the KDC.  Pre-authentication mechanisms providing this facility allow
-   a client to determine that the expected KDC has responded even after
-   the reply key is replaced.  They mark the pre-authentication state as
-   having been verified.
-
-
-5.  Requirements for Pre-Authentication Mechanisms
-
-   This section lists requirements for specifications of pre-
-   authentication mechanisms.
-
-   For each message in the pre-authentication mechanism, the
-   specification describes the pa-type value to be used and the contents
-   of the message.  The processing of the message by the sender and
-   recipient is also specified.  This specification needs to include all
-   modifications to the pre-authentication state.
-
-   Generally mechanisms have a message that can be sent in the error
-   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
-   authentication set.  If the client needs information such as trusted
-   certificate authorities in order to determine if it can use the
-   mechanism, then this information should be in that message.  In
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 15]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   addition, such mechanisms should also define a pa-hint to be included
-   in authentication sets.  Often, the same information included in the
-   padata-value is appropriate to include in the pa-hint (as defined in
-   Section 6.4).
-
-   In order to ease security analysis the mechanism specification should
-   describe what facilities from this document are offered by the
-   mechanism.  For each facility, the security consideration section of
-   the mechanism specification should show that the security
-   requirements of that facility are met.  This requirement is
-   applicable to any FAST factor that provides authentication
-   information.
-
-   Significant problems have resulted in the specification of Kerberos
-   protocols because much of the KDC exchange is not protected against
-   authentication.  The security considerations section should discuss
-   unauthenticated plaintext attacks.  It should either show that
-   plaintext is protected or discuss what harm an attacker could do by
-   modifying the plaintext.  It is generally acceptable for an attacker
-   to be able to cause the protocol negotiation to fail by modifying
-   plaintext.  More significant attacks should be evaluated carefully.
-
-   As discussed in Section 6.3, there is no guarantee that a client will
-   use the same KDCs for all messages in a conversation.  The mechanism
-   specification needs to show why the mechanism is secure in this
-   situation.  The hardest problem to deal with, especially for
-   challenge/response mechanisms is to make sure that the same response
-   cannot be replayed against two KDCs while allowing the client to talk
-   to any KDC.
-
-
-6.  Tools for Use in Pre-Authentication Mechanisms
-
-   This section describes common tools needed by multiple pre-
-   authentication mechanisms.  By using these tools mechanism designers
-   can use a modular approach to specify mechanism details and ease
-   security analysis.
-
-6.1.  Combining Keys
-
-   Frequently a weak key needs to be combined with a stronger key before
-   use.  For example, passwords are typically limited in size and
-   insufficiently random, therefore it is desirable to increase the
-   strength of the keys based on passwords by adding additional secrets.
-   Additional source of secrecy may come from hardware tokens.
-
-   This section provides standard ways to combine two keys into one.
-
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 16]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   KRB-FX-CF1() is defined to combine two pass-phrases.
-
-       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
-       KRB-FX-CF1(x, y) -> x || y
-
-   Where || denotes concatenation.  The strength of the final key is
-   roughly the total strength of the individual keys being combined
-   assuming that the string_to_key() function [RFC3961] uses all its
-   input evenly.
-
-   An example usage of KRB-FX-CF1() is when a device provides random but
-   short passwords, the password is often combined with a personal
-   identification number (PIN).  The password and the PIN can be
-   combined using KRB-FX-CF1().
-
-   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
-   function defined in [RFC3961].
-
-   Given two input keys, K1 and K2, where K1 and K2 can be of two
-   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
-   follows:
-
-       KRB-FX-CF2(protocol key, protocol key, octet string,
-                 octet string)  ->  (protocol key)
-
-       PRF+(K1, pepper1) -> octet-string-1
-       PRF+(K2, pepper2) -> octet-string-2
-       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
-              random-to-key(octet-string-1 ^ octet-string-2)
-
-   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
-   follows:
-
-    PRF+(protocol key, octet string) -> (octet string)
-
-    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
-                  pseudo-random( key, 2 || shared-info ) ||
-                  pseudo-random( key, 3 || shared-info ) || ...
-
-   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
-   integer.  The pseudo-random() operation is specified by the enctype
-   of the protocol key.  PRF+() uses the counter to generate enough bits
-   as needed by the random-to-key() [RFC3961] function for the
-   encryption type specified for the resulting key; unneeded bits are
-   removed from the tail.  Unless otherwise specified, the resulting
-   enctype of KRB-FX-CF2 is the enctype of k1.
-
-   Mechanism designers MUST specify the values for the input parameter
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 17]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
-   pepper1 and pepper2 MUST be distinct so that if the two keys being
-   combined are the same, the resulting key is not a trivial key.
-
-6.2.  Protecting Requests/Responses
-
-   Mechanism designers SHOULD protect clear text portions of pre-
-   authentication data.  Various denial of service attacks and downgrade
-   attacks against Kerberos are possible unless plaintexts are somehow
-   protected against modification.  An early design goal of Kerberos
-   Version 5 [RFC4120] was to avoid encrypting more of the
-   authentication exchange that was required.  (Version 4 doubly-
-   encrypted the encrypted part of a ticket in a KDC reply, for
-   example.)  This minimization of encryption reduces the load on the
-   KDC and busy servers.  Also, during the initial design of Version 5,
-   the existence of legal restrictions on the export of cryptography
-   made it desirable to minimize of the number of uses of encryption in
-   the protocol.  Unfortunately, performing this minimization created
-   numerous instances of unauthenticated security-relevant plaintext
-   fields.
-
-   If there is more than one round trip for an authentication exchange,
-   mechanism designers need to allow either the client or the KDC to
-   provide a checksum of all the messages exchanged on the wire in the
-   conversation, and the checksum is then verified by the receiver.
-
-   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
-
-   Primitives defined in [RFC3961] are RECOMMENDED for integrity
-   protection and confidentiality.  Mechanisms based on these primitives
-   are crypto-agile as the result of using [RFC3961] along with
-   [RFC4120].  The advantage afforded by crypto-agility is the ability
-   to incrementally deploy a fix specific to a particular algorithm thus
-   avoid a multi-year standardization and deployment cycle, when real
-   attacks do arise against that algorithm.
-
-   Note that data used by FAST factors (defined in Section 6.5) is
-   encrypted in a protected channel, thus they do not share the un-
-   authenticated-text issues with mechanisms designed as full-blown pre-
-   authentication mechanisms.
-
-6.3.  Managing States for the KDC
-
-   Kerberos KDCs are stateless.  There is no requirement that clients
-   will choose the same KDC for the second request in a conversation.
-   Proxies or other intermediate nodes may also influence KDC selection.
-   So, each request from a client to a KDC must include sufficient
-   information that the KDC can regenerate any needed state.  This is
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 18]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   accomplished by giving the client a potentially long opaque cookie in
-   responses to include in future requests in the same conversation.
-   The KDC MAY respond that a conversation is too old and needs to
-   restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
-
-       KDC_ERR_PREAUTH_EXPIRED            TBA
-
-   When a client receives this error, the client SHOULD abort the
-   existing conversation, and restart a new one.
-
-   An example, where more than one message from the client is needed, is
-   when the client is authenticated based on a challenge-response
-   scheme.  In that case, the KDC needs to keep track of the challenge
-   issued for a client authentication request.
-
-   The PA-FX-COOKIE padata type is defined in this section to facilitate
-   state management.  This padata is sent by the KDC when the KDC
-   requires state for a future transaction.  The client includes this
-   opaque token in the next message in the conversation.  The token may
-   be relatively large; clients MUST be prepared for tokens somewhat
-   larger than the size of all messages in a conversation.
-
-       PA-FX-COOKIE                       TBA
-           -- Stateless cookie that is not tied to a specific KDC.
-
-   The corresponding padata-value field [RFC4120] contains an opaque
-   token that will be echoed by the client in its response to an error
-   from the KDC.
-
-   The cookie token is generated by the KDC and transmitted in a PA-FX-
-   COOKIE pre-authentication data item of a KRB-ERROR message.  The
-   client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data
-   element into the next message of the same conversation.  The content
-   of the cookie field is a local matter of the KDC.  As a result, it is
-   not generally possible to mix KDC implementations from different
-   vendors in the same realm.  However the KDC MUST construct the cookie
-   token in such a manner that a malicious client cannot subvert the
-   authentication process by manipulating the token.  The KDC
-   implementation needs to consider expiration of tokens, key rollover
-   and other security issues in token design.  The content of the cookie
-   field is likely specific to the pre-authentication mechanisms used to
-   authenticate the client.  If a client authentication response can be
-   replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an
-   expiration in the cookie is RECOMMENDED to prevent the response being
-   presented indefinitely.
-
-   If at least one more message for a mechanism or a mechanism set is
-   expected by the KDC, the KDC returns a
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 19]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA-FX-COOKIE to
-   identify the conversation with the client according to Section 3.2.
-   The cookie is not expected to stay constant for a conversation: the
-   KDC is expected to generate a new cookie for each message.
-
-        KDC_ERR_MORE_PREAUTH_DATA_NEEDED   TBA
-
-6.4.  Pre-authentication Set
-
-   If all mechanisms in a group need to successfully complete in order
-   to authenticate a client, the client and the KDC SHOULD use the PA-
-   AUTHENTICATION-SET padata element.
-
-        PA-AUTHENTICATION-SET              TBA
-
-   A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
-   encoding of the PA-AUTHENTICATION-SET structure:
-
-        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-            pa-type      [0] Int32,
-                -- same as padata-type.
-            pa-hint      [1] OCTET STRING OPTIONAL,
-            pa-value  [2] OCTET STRING OPTIONAL,
-            ...
-        }
-
-   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
-   contains the corresponding value of padata-type in PA-DATA [RFC4120].
-   Associated with the pa-type is a pa-hint, which is an octet-string
-   specified by the pre-authentication mechanism.  This hint may provide
-   information for the client which helps it determine whether the
-   mechanism can be used.  For example a public-key mechanism might
-   include the certificate authorities it trusts in the hint info.  Most
-   mechanisms today do not specify hint info; if a mechanism does not
-   specify hint info the KDC MUST NOT send a hint for that mechanism.
-   To allow future revisions of mechanism specifications to add hint
-   info, clients MUST ignore hint info received for mechanisms that the
-   client believes do not support hint info.  The pa-value element of
-   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
-   first padata-value from the KDC to the client.  If the client chooses
-   this authentication set then the client MUST process this pa-value.
-   The pa-value element MUST be absent for all but the first entry in
-   the authentication set.  Clients MUST ignore pa-value for the second
-   and following entries in the authentication set.
-
-   If the client chooses an authentication set, then its first AS-REQ
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 20]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   message MUST contain a PA-AUTHENTICATION-SET-SELECTED padata element.
-   This element contains the encoding of the PA-AUTHENTICATION-SET
-   sequence received from the KDC corresponding to the authentication
-   set that is chosen.  The client MUST use the same octet values
-   received from the KDC; it cannot re-encode the sequence.  This allows
-   KDCs to use bit-wise comparison to identify the selected
-   authentication set.  The PA-AUTHENTICATION-SET-SELECTED padata
-   element MUST come before any padata elements from the authentication
-   set in the padata sequence in the AS-REQ message.  The client MAY
-   cache authentication sets from prior messages and use them to
-   construct an optimistic initial AS-REQ.  If the KDC receives a PA-
-   AUTHENTICATION-SET-SELECTED padata element that does not correspond
-   to an authentication set that it would offer, then the KDC returns
-   the KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The e-data in this
-   error contains a sequence of padata just as for the
-   KDC_ERR_PREAUTH_REQUIRED error.
-
-
-         PA-AUTHENTICATION-SET-SELECTED         TBA
-         KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET TBA
-
-   The PA-AUTHENTICATION-SET appears only in the first message from the
-   KDC to the client.  In particular, the client MAY fail if the
-   authentication mechanism sets change as the conversation progresses.
-   Clients MAY assume that the hints provided in the authentication set
-   contain enough information that the client knows what user interface
-   elements need to be displayed during the entire authentication
-   conversation.  Exceptional circumstances such as expired passwords or
-   expired accounts may require that additional user interface be
-   displayed.  Mechanism designers need to carefully consider the design
-   of their hints so that the client has this information.  This way,
-   clients can construct necessary dialogue boxes or wizards based on
-   the authentication set and can present a coherent user interface.
-   Current standards for user interface do not provide an acceptable
-   experience when the client has to ask additional questions later in
-   the conversation.
-
-   When indicating which sets of pre-authentication mechanisms are
-   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
-   for each pre-authentication mechanism set.
-
-   The client sends the padata-value for the first mechanism it picks in
-   the pre-authentication set, when the first mechanism completes, the
-   client and the KDC will proceed with the second mechanism, and so on
-   until all mechanisms complete successfully.  The PA-FX-COOKIE as
-   defined in Section 6.3 MUST be sent by the KDC so that the
-   conversation can continue if the conversation involves multiple KDCs.
-   The cookie may not be needed in the first message containing the PA-
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 21]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   AUTHENTICATION-SET sequence as the KDC may be able to reconstruct the
-   state from the PA-AUTHENTICATION-SET-SELECTED padata.  KDCs MUST
-   support clients that do not include a cookie because they
-   optimistically choose an authentication set, although they MAY always
-   return KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in
-   that message.  Clients that support PA-AUTHENTICATION-SET MUST
-   support PA-FX-COOKIE.
-
-   Before the authentication succeeds and a ticket is returned, the
-   message that the client sends is an AS_REQ and the message that the
-   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
-   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_NEEDED as defined
-   in Section 6.3 and the accompanying e-data contains the DER encoding
-   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
-   the METHOD-DATA.  If there is no padata, the e-data field is absent
-   in the KRB-ERROR message.
-
-   If the client sends the last message for a given mechanism, then the
-   KDC sends the first message for the next mechanism.  If the next
-   mechanism does not start with a KDC-side challenge, then the KDC
-   includes a padata item with the appropriate pa-type and an empty pa-
-   data.
-
-   If the KDC sends the last message for a particular mechanism, the KDC
-   also includes the first padata for the next mechanism.
-
-6.5.  Definition of Kerberos FAST Padata
-
-   As described in [RFC4120], Kerberos is vulnerable to offline
-   dictionary attacks.  An attacker can request an AS-REP and try
-   various passwords to see if they can decrypt the resulting ticket.
-   RFC 4120 provides the encrypted timestamp pre-authentication method
-   that ameliorates the situation somewhat by requiring that an attacker
-   observe a successful authentication.  However stronger security is
-   desired in many environments.  The Kerberos FAST pre-authentication
-   padata defined in this section provides a tool to significantly
-   reduce vulnerability to offline dictionary attack.  When combined
-   with encrypted challenge, FAST requires an attacker to mount a
-   successful man-in-the-middle attack to observe ciphertext.  When
-   combined with host keys, FAST can even protect against active
-   attacks.  FAST also provides solutions to common problems for pre-
-   authentication mechanisms such as binding of the request and the
-   reply, freshness guarantee of the authentication.  FAST itself,
-   however, does not authenticate the client or the KDC, instead, it
-   provides a typed hole to allow pre-authentication data be tunneled.
-   A pre-authentication data element used within FAST is called a FAST
-   factor.  A FAST factor captures the minimal work required for
-   extending Kerberos to support a new pre-authentication scheme.
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 22]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   A FAST factor MUST NOT be used outside of FAST unless its
-   specification explicitly allows so.  The typed holes in FAST messages
-   can also be used as generic holes for other padata that are not
-   intended to prove the client's identity, or establish the reply key.
-
-   New pre-authentication mechanisms SHOULD be designed as FAST factors,
-   instead of full-blown pre-authentication mechanisms.
-
-   FAST factors that are pre-authentication mechanisms MUST meet the
-   requirements in Section 5.
-
-   FAST employs an armoring scheme.  The armor can be a Ticket Granting
-   Ticket (TGT) obtained by the client's machine using the host keys to
-   pre-authenticate with the KDC, or an anonymous TGT obtained based on
-   anonymous PKINIT [KRB-ANON] [RFC4556].
-
-   The rest of this section describes the types of armors and the syntax
-   of the messages used by FAST.  Conforming implementations MUST
-   support Kerberos FAST padata.
-
-   Any FAST armor scheme MUST provide a fresh armor key for each
-   conversation.  Clients and KDCs can assume that if a message is
-   encrypted and integrity protected with a given armor key then it is
-   part of the conversation using that armor key.
-
-   All KDCs in a realm MUST support FAST if FAST is offered by any KDC
-   as a pre-authentication mechanism.
-
-6.5.1.  FAST Armors
-
-   An armor key is used to encrypt pre-authentication data in the FAST
-   request and the response.  The KrbFastArmor structure is defined to
-   identify the armor key.  This structure contains the following two
-   fields: the armor-type identifies the type of armors, and the armor-
-   value is an OCTET STRING that contains the description of the armor
-   scheme and the armor key.
-
-        KrbFastArmor ::= SEQUENCE {
-            armor-type   [0] Int32,
-                -- Type of the armor.
-            armor-value  [1] OCTET STRING,
-                -- Value of the armor.
-            ...
-        }
-
-   The value of the armor key is a matter of the armor type
-   specification.  Only one armor type is defined in this document.
-
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 23]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-        FX_FAST_ARMOR_AP_REQUEST           1
-
-   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
-
-   Conforming implementations MUST implement the
-   FX_FAST_ARMOR_AP_REQUEST armor type.
-
-   FAST implementations MUST maintain state about whether the armor
-   mechanism authenticates the KDC.  If it does not, then a fast factor
-   that authenticates the KDC MUST be used if the reply key is replaced.
-
-6.5.1.1.  Ticket-based Armors
-
-   This is a ticket-based armoring scheme.  The armor-type is
-   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
-   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
-   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
-   The armor key is defined by the following function:
-
-       armor_key = KRB-FX-CF2( subkey, ticket_session_key,
-                   "subkeyarmor", "ticketarmor" )
-
-   The `ticket_key' is the session key from the ticket in the ap-req.
-   The `subkey' is the ap-req subkey.  This construction guarantees that
-   both the KDC (through the session key) and the client (through the
-   subkey) contribute to the armor key.
-
-   The server name field of the armor ticket MUST identify the TGS of
-   the target realm.  Here are three common ways in the decreasing
-   preference order how an armor TGT SHOULD be obtained:
-
-   1.  If the client is authenticating from a host machine whose
-       Kerberos realm has an authentication path to the client's realm,
-       the host machine obtains a TGT by using the host keys.  If the
-       client's realm is different than the realm of the local host, the
-       machine then obtains a cross-realm TGT to the client's realm as
-       the armor ticket.  Otherwise, the host's primary TGT is the armor
-       ticket.
-
-   2.  If the client's host machine cannot obtain a host ticket strictly
-       based on RFC4120, but the KDC has an asymmetric signing key whose
-       binding with the expected KDC can be verified by the client, the
-       client can use anonymous PKINIT [KRB-ANON] [RFC4556] to
-       authenticate the KDC and obtain an anonymous TGT as the armor
-       ticket.  The armor ticket can also be a cross-realm TGT obtained
-       based on the initial primary TGT obtained using anonymous PKINIT
-       with KDC authentication.
-
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 24]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
-       TGT without KDC authentication and that TGT is the armor ticket.
-       Note that this mode of operation is vulnerable to man-in-the-
-       middle attacks at the time of obtaining the initial anonymous
-       armor TGT.
-
-   If anonymous PKINIT is used, The KDC cannot know whether its signing
-   key can be verified by the client, hence the KDC MUST be marked as
-   unverified from the KDC's point of view while the client could be
-   able to authenticate the KDC by verifying the KDC's signing key is
-   bound with the expected KDC.  The client needs to carefully consider
-   the risk and benefit tradeoffs associated with active attacks before
-   exposing cipher text encrypted using the user's long-term secrets
-   when the armor does not authenticate the KDC.
-
-   The TGS MUST reject a request if there is an AD-fx-fast-armor (TBD)
-   element in the authenticator of the pa-tgs-req padata or if the
-   ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-
-   armor authorization data element.  These tickets and authenticators
-   MAY be used as FAST armor tickets but not to obtain a ticket via the
-   TGS.  This authorization data is used in a system where the
-   encryption of the user's pre-authentication data is performed in an
-   unprivileged user process.  A privileged process can provide to the
-   user process a host ticket, an authenticator for use with that
-   ticket, and the sub session key contained in the authenticator.  In
-   order for the host process to ensure that the host ticket is not
-   accidentally or intentionally misused, (i.e. the user process might
-   use the host ticket to authenticate as the host), it MUST include a
-   critical authorization data element of the type AD-fx-fast-armor when
-   providing the authenticator or in the enc-authorization-data field of
-   the TGS request used to obtain the TGT.  The corresponding ad-data
-   field of the AD-fx-fast-armor element is empty.
-
-   As discussed previously, the server of an armor ticket MUST be the
-   TGS of the realm from whom service is requested.  As a result, if
-   this armor type is used when a ticket is being validated, proxied, or
-   in other cases where a ticket other than a TGT is presented to the
-   TGS, a TGT will be used as an armor ticket, while another ticket will
-   be used in the pa-tgs-req authenticator.
-
-6.5.2.  FAST Request
-
-   A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
-   authentication padata.  The corresponding padata-value field
-   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
-   REQUEST.  As with all pre-authentication types, the KDC SHOULD
-   advertise PA-FX-FAST with an empty pa-value in a PREAUTH_REQUIRED
-   error.  Clients MUST ignore the pa-value of PA-FX-FAST in an initial
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 25]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   PREAUTH_REQUIRED error.  FAST is not expected to be used in an
-   authentication set: clients will typically use FAST padata if
-   available and this decision should not depend on what other pre-
-   authentication methods are available.  As such, no pa-hint is defined
-   for FAST at this time.
-
-       PA-FX-FAST                         TBA
-           -- Padata type for Kerberos FAST
-
-       PA-FX-FAST-REQUEST ::= CHOICE {
-           armored-data [0] KrbFastArmoredReq,
-           ...
-       }
-
-       KrbFastArmoredReq ::= SEQUENCE {
-           armor        [0] KrbFastArmor OPTIONAL,
-               -- Contains the armor that identifies the armor key.
-               -- MUST be present in AS-REQ.
-           req-checksum [1] Checksum,
-               -- Checksum performed over the type KDC-REQ-BODY for
-               -- the req-body field of the KDC-REQ structure defined in
-               -- [RFC4120]
-               -- The checksum key is the armor key, the checksum
-               -- type is the required checksum type for the enctype of
-               -- the armor key, and the key usage number is
-               -- KEY_USAGE_FAST_REQ_CHKSUM.
-           enc-fast-req [2] EncryptedData, -- KrbFastReq --
-               -- The encryption key is the armor key, and the key usage
-               -- number is KEY_USAGE_FAST_ENC.
-           ...
-       }
-
-       KEY_USAGE_FAST_REQ_CHKSUM          TBA
-       KEY_USAGE_FAST_ENC                 TBA
-
-   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
-   The KrbFastArmoredReq encapsulates the encrypted padata.
-
-   The enc-fast-req field contains an encrypted KrbFastReq structure.
-   The armor key is used to encrypt the KrbFastReq structure, and the
-   key usage number for that encryption is KEY_USAGE_FAST_ENC.
-
-   The armor key is selected as follows:
-
-   o  In an AS request, the armor field in the KrbFastArmoredReq
-      structure MUST be present and the armor key is identified
-      according to the specification of the armor type.
-
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 26]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   o  There are two possibilities for armor for a TGS request.  If the
-      ticket presented in the PA-TGS-REQ authenticator is a TGT, then
-      the client SHOULD not include the armor field in the Krbfastreq
-      and a subkey MUST be included in the PA-TGS-REQ authenticator.  In
-      this case, the armor key is the same armor key that would be
-      computed if the TGS-REQ authenticator was used in a
-      FX_FAST_ARMOR_AP_REQUEST armor.  If a ticket other than a TGT is
-      being presented to the TGS, a client SHOULD use some form of FAST
-      armor such as a ticket-based armor with a TGT as an armor ticket.
-      Clients MAY present a non-TGT in the PA-TGS-REQ authenticator and
-      omit the armor field, in which case the armor key is the same that
-      would be computed if the authenticator were used in a
-      FX_FAST_ARMOR_AP_REQUEST armor.  This is the only case where a
-      ticket other than a TGT can be used to establish an armor key;
-      even though the armor key is computed the same as a
-      FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used as an armor
-      ticket in FX_FAST_ARMOR_AP_REQUEST.
-
-   The req-checksum field contains a checksum that is performed over the
-   type KDC-REQ-BODY for the req-body field of the KDC-REQ [RFC4120]
-   structure of the containing message.  The checksum key is the armor
-   key, and the checksum type is the required checksum type for the
-   enctype of the armor key per [RFC3961].  This checksum is included in
-   order to bind the FAST padata to the outer request.  A KDC that
-   implements FAST will ignore the outer request, but including a
-   checksum is relatively cheap and may prevent confusing behavior.
-
-   The KrbFastReq structure contains the following information:
-
-        KrbFastReq ::= SEQUENCE {
-            fast-options [0] FastOptions,
-                -- Additional options.
-            padata       [1] SEQUENCE OF PA-DATA,
-                -- padata typed holes.
-            req-body     [2] KDC-REQ-BODY,
-                -- Contains the KDC request body as defined in Section
-                -- 5.4.1 of [RFC4120].
-                -- This req-body field is preferred over the outer field
-                -- in the KDC request.
-             ...
-        }
-
-   The fast-options field indicates various options that are to modify
-   the behavior of the KDC.  The following options are defined:
-
-        FastOptions ::= KerberosFlags
-            -- reserved(0),
-            -- hide-client-names(1),
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 27]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-            -- kdcfollow--referrals(16)
-
-
-     Bits    Name                    Description
-    -----------------------------------------------------------------
-     0     RESERVED              Reserved for future expansion of this
-                                 field.
-     1     hide-client-names     Requesting the KDC to hide client
-                                 names in the KDC response, as
-                                 described next in this section.
-     16    kdc-follow-referrals  Requesting the KDC to follow referrals.
-
-   Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are
-   critical options.  If the KDC does not support a critical option, it
-   MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and
-   there is no accompanying e-data defined in this document for this
-   error code.  Bit 16 and onward (with bit 16 included) are non-
-   critical options.  KDCs conforming to this specification ignore
-   unknown non-critical options.
-
-        KDC_ERR_UNKNOWN_FAST_OPTIONS       TBA
-
-   The hide-client-names Option
-
-      The Kerberos response defined in [RFC4120] contains the client
-      identity in clear text, This makes traffic analysis
-      straightforward.  The hide-client-names option is designed to
-      complicate traffic analysis.  If the hide-client-names option is
-      set, the KDC implementing PA-FX-FAST MUST identify the client as
-      the anonymous principal [KRB-ANON] in the KDC reply and the error
-      response.  Hence this option is set by the client if it wishes to
-      conceal the client identity in the KDC response.  A conforming KDC
-      ignores the client principal name in the outer KDC-REQ-BODY field,
-      and identifies the client using the cname and crealm fields in the
-      req-body field of the KrbFastReq structure.
-
-   The kdc-follow-referrals Option
-
-      The Kerberos client described in [RFC4120] has to request referral
-      TGTs along the authentication path in order to get a service
-      ticket for the target service.  The Kerberos client described in
-      the [REFERRALS] needs to contact the AS specified in the error
-      response in order to complete client referrals.  The kdc-follow-
-      referrals option is designed to minimize the number of messages
-      that need to be processed by the client.  This option is useful
-      when, for example, the client may contact the KDC via a satellite
-      link that has high network latency, or the client has limited
-      computational capabilities.  If the kdc-follow-referrals option is
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 28]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-      set, the KDC MAY act as the client to follow TGS referrals
-      [REFERRALS], and return the service ticket to the named server
-      principal in the client request using the reply key expected by
-      the client.  That is, rather than returning a referral, the KDC
-      follows that referral by contacting a remote KDC and processing
-      the referral.  The kdc-referrals option can be implemented when
-      the KDC knows the reply key.  The KDC can ignore kdc-referrals
-      option when it does not understand it or it does not allow this
-      option based on local policy.  The client SHOULD be capable of
-      processing the KDC responses when this option is not honored by
-      the KDC.  Clients SHOULD use TCP to contact a KDC if this option
-      is going to be used to avoid problems when the client's UDP
-      retransmit algorithm has timeouts insufficient to allow the KDC to
-      interact with remote KDCs.
-
-   The padata field contains a list of PA-DATA structures as described
-   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
-   FAST factors.  They can also be used as generic typed-holes to
-   contain data not intended for proving the client's identity or
-   establishing a reply key, but for protocol extensibility.
-
-   The KDC-REQ-BODY in the FAST structure is used in preference to the
-   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-
-   REQ-BODY structure SHOULD be filled in for backwards compatibility
-   with KDCs that do not support FAST.  A conforming KDC ignores the
-   outer KDC-REQ-BODY field in the KDC request.  However pre-
-   authentication data methods such as [RFC4556] that include a checksum
-   of the KDC-REQ-BODY should checksum the outer KDC-REQ-BODY.  These
-   methods will already be bound to the inner body through the integrity
-   protection in the FAST request.
-
-6.5.3.  FAST Response
-
-   The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST
-   padata element in the KDC reply.  In the case of an error, the PA-FX-
-   FAST padata is included in the KDC responses according to
-   Section 6.5.4.
-
-   The corresponding padata-value field [RFC4120] for the PA-FX-FAST in
-   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
-   FAST-REPLY.
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 29]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-      PA-FX-FAST-REPLY ::= CHOICE {
-          armored-data [0] KrbFastArmoredRep,
-          ...
-      }
-
-      KrbFastArmoredRep ::= SEQUENCE {
-          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
-              -- The encryption key is the armor key in the request, and
-              -- the key usage number is KEY_USAGE_FAST_REP.
-          ...
-      }
-      KEY_USAGE_FAST_REP                 TBA
-
-   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
-   structure.  The KrbFastArmoredRep structure encapsulates the padata
-   in the KDC reply in the encrypted form.  The KrbFastResponse is
-   encrypted with the armor key used in the corresponding request, and
-   the key usage number is KEY_USAGE_FAST_REP.
-
-   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
-   KDC response MUST support a local policy that rejects the response.
-   Clients MAY also support policies that fall back to other mechanisms
-   or that do not use pre-authentication when FAST is unavailable.  It
-   is important to consider the potential downgrade attacks when
-   deploying such a policy.
-
-   The KrbFastResponse structure contains the following information:
-
-     KrbFastResponse ::= SEQUENCE {
-         padata      [0] SEQUENCE OF PA-DATA,
-             -- padata typed holes.
-         rep-key     [1] EncryptionKey OPTIONAL,
-             -- This, if present, replaces the reply key for AS and TGS.
-             -- MUST be absent in KRB-ERROR.
-         finished    [2] KrbFastFinished OPTIONAL,
-             -- MUST be present if the client is authenticated,
-             -- absent otherwise.
-             -- Typically this is present if and only if the containing
-             -- message is the last one in a conversation.
-         ...
-     }
-
-   The padata field in the KrbFastResponse structure contains a list of
-   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
-   PA-DATA structures are used to carry data advancing the exchange
-   specific for the FAST factors.  They can also be used as generic
-   typed-holes for protocol extensibility.  Unless otherwise specified,
-   the KDC MUST include any padata otherwise in the outer KDC reply into
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 30]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   this field.  The padata field in the KDC reply structure outside of
-   the PA-FX-FAST-REPLY structure typically includes only the PA-FX-
-   FAST-REPLY padata and optionally the PA-FX-COOKIE padata.
-
-   The rep-key field, if present, contains the reply key that is used to
-   encrypted the KDC reply.  The rep-key field MUST be absent in the
-   case where an error occurs.  The enctype of the rep-key is the
-   strongest mutually supported by the KDC and the client.
-
-   The finished field contains a KrbFastFinished structure.  It is
-   filled by the KDC in the final message in the conversation; it MUST
-   be absent otherwise.  In other words, this field can only be present
-   in an AS-REP or a TGS-REP when a ticket is returned.
-
-   The KrbFastFinished structure contains the following information:
-
-      KrbFastFinished ::= SEQUENCE {
-          timestamp   [0] KerberosTime,
-          usec        [1] Microseconds,
-              -- timestamp and usec represent the time on the KDC when
-              -- the reply was generated.
-          crealm      [2] Realm,
-          cname       [3] PrincipalName,
-              -- Contains the client realm and the client name.
-          checksum    [4] Checksum,
-              -- Checksum performed over all the messages in the
-              -- conversation, except the containing message.
-              -- The checksum key is the armor key as defined in
-              -- Section 6.5.1, and the checksum type is the required
-              -- checksum type of the armor key.
-          ticket-checksum [5] Checksum,
-              -- checksum  of the ticket in the KDC-REP  using the armor
-              -- and  the key usage is KEY_USAGE_FAST_FINISH.
-              -- The checksum type is the required checksum type
-              -- of the armor key.
-          ...
-      }
-      KEY_USAGE_FAST_FINISHED            TBA
-
-   The timestamp and usec fields represent the time on the KDC when the
-   reply ticket was generated, these fields have the same semantics as
-   the corresponding-identically-named fields in Section 5.6.1 of
-   [RFC4120].  The client MUST use the KDC's time in these fields
-   thereafter when using the returned ticket.  Note that the KDC's time
-   in AS-REP may not match the authtime in the reply ticket if the kdc-
-   follow-referrals option is requested and honored by the KDC.  The
-   client need not confirm that the timestamp returned is within
-   allowable clock skew: the armor key guarantees that the reply is
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 31]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   fresh.  The client MAY trust the time stamp returned.
-
-   The cname and crealm fields identify the authenticated client.  If
-   facilities described in [REFERRALS] are used, the authenticated
-   client may differ from the client in the FAST request.
-
-   The checksum field contains a checksum of all the messages in the
-   conversation prior to the containing message (the containing message
-   is excluded).  The checksum key is the armor key, and the checksum
-   type is the required checksum type of the enctype of that key, and
-   the key usage number is KEY_USAGE_FAST_FINISHED.  The ticket-checksum
-   is a checksum of the issued ticket using the same key and key usage.
-
-   When FAST padata is included, the PA-FX-COOKIE padata as defined in
-   Section 6.3 MUST also be included if the KDC expects at least one
-   more message from the client in order to complete the authentication.
-
-6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
-
-   If the Kerberos FAST padata was included in the request, unless
-   otherwise specified, the e-data field of the KRB-ERROR message
-   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
-   [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA.  The KDC
-   MUST include all the padata elements such as PA-ETYPE-INFO2 and
-   padata elements that indicate acceptable pre-authentication
-   mechanisms [RFC4120] in the KrbFastResponse structure.
-
-   The KDC MUST also include a PA-FX-ERROR padata item in the
-   KRBFastResponse structure.  The padata-value element of this sequence
-   is the ASN.1 DER encoding of the type KRB-ERROR.  The e-data field
-   MUST be absent in the PA-FX-ERROR padata.  All other fields should be
-   the same as the outer KRB-ERROR.  The client ignores the outer error
-   and uses the combination of the padata in the KRBFastResponse and the
-   error information in the PA-FX-ERROR.
-
-              PA-FX-ERROR                        TBA
-
-   If the Kerberos FAST padata is included in the request but not
-   included in the error reply, it is a matter of the local policy on
-   the client to accept the information in the error message without
-   integrity protection.  The Kerberos client MAY process an error
-   message without a PA-FX-FAST-REPLY, if that is only intended to
-   return better error information to the application, typically for
-   trouble-shooting purposes.
-
-   In the cases where the e-data field of the KRB-ERROR message is
-   expected to carry a TYPED-DATA [RFC4120] element, then that
-   information should be transmitted in a pa-data element within the
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 32]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   KRBFastResponse structure.  The padata-type is the same as the data-
-   type would be in the typed data element and the padata-value is the
-   same as the data-value.  As discussed in Section 8, data-types and
-   padata-types are drawn from the same namespace.  For example, the
-   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
-   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
-   [RFC4556].
-
-6.5.5.  Outer and Inner Requests
-
-   Typically, a client will know that FAST is being used before a
-   request containing PA-FX-FAST is sent.  So, the outer AS request
-   typically only includes two pa-data items: PA-FX-FAST and PA-FX-
-   COOKIE.  The client MAY include additional pa-data, but the KDC MUST
-   ignore the outer request body and any padata besides PA-FX-FAST and
-   PA-FX-COOKIE if PA-FX-FAST is processed.  In the case of the TGS
-   request, the outer request should include PA-FX-FAST and PA-TGS-REQ.
-
-   When an AS generates a response, all padata besides PA-FX-FAST and
-   PA-FX-COOKIE should be included in PA-FX-FAST.  The client MUST
-   ignore other padata outside of PA-FX-FAST.
-
-6.5.6.  The Encrypted Challenge FAST Factor
-
-   The encrypted challenge FAST factor authenticates a client using the
-   client's long-term key.  This factor works similarly to the encrypted
-   time stamp pre-authentication option described in [RFC4120].  The
-   client encrypts a structure containing a timestamp in the challenge
-   key.  The challenge key used by the client to send a message to the
-   KDC is KRB-FX-CF2(armor_key,long_term_key, "clientchallengearmor",
-   "challengelongterm").  The challenge key used by the KDC encrypting
-   to the client is KRB-FX-CF2(armor_key, long_term_key,
-   "kdcchallengearmor", "challengelongterm").  Because the armor key is
-   fresh and random, the challenge key is fresh and random.  The only
-   purpose of the timestamp is to limit the validity of the
-   authentication so that a request cannot be replayed.  A client MAY
-   base the timestamp on the KDC time in a KDC error and need not
-   maintain accurate time synchronization itself.  If a client bases its
-   time on an untrusted source, an attacker may trick the client into
-   producing an authentication request that is valid at some future
-   time.  The attacker may be able to use this authentication request to
-   make it appear that a client has authenticated at that future time.
-   If ticket-based armor is used, then the lifetime of the ticket will
-   limit the window in which an attacker can make the client appear to
-   have authenticated.  For many situations, the ability of an attacker
-   to cause a client to appear to have authenticated is not a
-   significant concern; the ability to avoid requiring time
-   synchronization on clients is more valuable.
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 33]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   The client sends a padata of type PA-ENCRYPTED-CHALLENGE the
-   corresponding padata-value contains the DER encoding of ASN.1 type
-   EncryptedChallenge.
-
-      EncryptedChallenge ::= EncryptedData
-              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
-
-      PA-ENCRYPTED-CHALLENGE          TBA
-      KEY_USAGE_ENC_CHALLENGE_CLIENT  TBA
-      KEY_USAGE_ENC_CHALLENGE_KDC     TBA
-
-   The client includes some time stamp reasonably close to the KDC's
-   current time and encrypts it in the challenge key.  Clients MAY use
-   the current time; doing so prevents the exposure where an attacker
-   can cause a client to appear to authenticate in the future.  The
-   client sends the request including this factor.
-
-   On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE fast
-   factor, the KDC decrypts the timestamp.  If the decryption fails the
-   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in
-   the KRBFastResponse in the error.  The KDC confirms that the
-   timestamp falls within its current clock skew returning
-   KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see if the
-   encrypted challenge is a replay.  The KDC MUST NOT consider two
-   encrypted challenges replays simply because the time stamps are the
-   same; to be a replay, the ciphertext MUST be identical.  Allowing
-   clients to re-use time stamps avoids requiring that clients maintain
-   state about which time stamps have been used.
-
-   If the KDC accepts the encrypted challenge, it MUST include a padata
-   element of type PA-ENCRYPTED-CHALLENGE.  The KDC encrypts its current
-   time in the challenge key.  The KDC MUST replace the reply key before
-   issuing a ticket.  The client MUST check that the timestamp decrypts
-   properly.  The client MAY check that the timestamp is winthin the
-   window of acceptable clock skew for the client.  The client MUST NOT
-   require that the timestamp be identical to the timestamp in the
-   issued credentials or the returned message.
-
-   The encrypted challenge FAST factor provides the following
-   facilities: client-authentication and KDC authentication.  This FAST
-   factor also takes advantage of the FAST facility to replace the reply
-   key.  It does not provide the strengthening-reply-key facility.  The
-   security considerations section of this document provides an
-   explanation why the security requirements are met.
-
-   The encrypted challenge FAST factor can be useful in an
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 34]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   authentication set.  No pa-hint is defined because the only
-   information needed by this mechanism is information contained in the
-   PA-ETYPE-INFO2 pre-authentication data.  KDCs are already required to
-   send PA-ETYPE-INFO2.  If KDCs were not required to send PA-ETYPE-
-   INFO2 then that information would need to be part of a hint for
-   encrypted challenge.
-
-   Conforming implementations MUST support the encrypted challenge FAST
-   factor.
-
-6.6.  Authentication Strength Indication
-
-   Implementations that have pre-authentication mechanisms offering
-   significantly different strengths of client authentication MAY choose
-   to keep track of the strength of the authentication used as an input
-   into policy decisions.  For example, some principals might require
-   strong pre-authentication, while less sensitive principals can use
-   relatively weak forms of pre-authentication like encrypted timestamp.
-
-   An AuthorizationData data type AD-Authentication-Strength is defined
-   for this purpose.
-
-        AD-authentication-strength         TBA
-
-   The corresponding ad-data field contains the DER encoding of the pre-
-   authentication data set as defined in Section 6.4.  This set contains
-   all the pre-authentication mechanisms that were used to authenticate
-   the client.  If only one pre-authentication mechanism was used to
-   authenticate the client, the pre-authentication set contains one
-   element.
-
-   The AD-authentication-strength element MUST be included in the AD-IF-
-   RELEVANT, thus it can be ignored if it is unknown to the receiver.
-
-
-7.  Assigned Constants
-
-   The pre-authentication framework and FAST involve using a number of
-   Kerberos protocol constants.  This section lists protocol constants
-   first introduced in this specification drawn from registries not
-   managed by IANA.  Many of these registries would best be managed by
-   IANA; that is a known issue that is out of scope for this document.
-   The constants described in this section have been accounted for and
-   will appear in the next revision of the Kerberos core specification
-   or in a document creating IANA registries.
-
-   Section 8 creates IANA registries for a different set of constants
-   used by the extensions described in this document.
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 35]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-7.1.  New Errors
-
-           KDC_ERR_PREAUTH_EXPIRED                TBA
-           KDC_ERR_MORE_PREAUTH_DATA_NEEDED       TBA
-           KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET TBA
-           KDC_ERR_UNKNOWN_FAST_OPTIONS           TBA
-
-7.2.  Key Usage Numbers
-
-           KEY_USAGE_FAST_REQ_CHKSUM          TBA
-           KEY_USAGE_FAST_ENC                 TBA
-           KEY_USAGE_FAST_REP                 TBA
-           KEY_USAGE_FAST_FINISHED            TBA
-           KEY_USAGE_ENC_CHALLENGE_CLIENT     TBA
-           KEY_USAGE_ENC_CHALLENGE_KDC        TBA
-
-7.3.  Authorization Data Elements
-
-           AD-authentication-strength         TBA
-           AD-fx-fast-armor                   TBA
-
-7.4.  New PA-DATA Types
-
-           PA-FX-COOKIE                       TBA
-           PA-AUTHENTICATION-SET              TBA
-           PA-AUTHENTICATION-SET-SELECTED     TBA
-           PA-FX-FAST                         TBA
-           PA-FX-ERROR                        TBA
-           PA-ENCRYPTED-CHALLENGE             TBA
-
-
-8.  IANA Considerations
-
-   This document creates a number of IANA registries.  These registries
-   should all be located under
-   http://www.iana.org/assignments/kerberos-parameters.
-
-8.1.  Pre-authentication and Typed Data
-
-   RFC 4120 defines pre-authentication data, which can be included in a
-   KDC request or response in order to authenticate the client or extend
-   the protocol.  In addition, it defines Typed-Data which is an
-   extension mechanism for errors.  Both pre-authentication data and
-   typed data are carried as a 32-bit signed integer along with an octet
-   string.  The encoding of typed data and pre-authentication data is
-   slightly different.  However the types for pre-authentication data
-   and typed-data are drawn from the same namespace.  By convention,
-   registrations starting with TD- are typed data and registration
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 36]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   starting with PA- are pre-authentication data.  It is important that
-   these data types be drawn from the same namespace, because some
-   errors where it would be desirable to include typed data require the
-   e-data field to be formatted as pre-authentication data.
-
-   When Kerberos FAST is used, pre-authentication data encoding is
-   always used.
-
-   There is one apparently conflicting registration between typed data
-   and pre-authentication data.  PA-GET-FROM-TYPED-DATA and TD-PADATA
-   are both assigned the value 22.  However this registration is simply
-   a mechanism to include an element of the other encoding.  The use of
-   both should be deprecated.
-
-   This document creates a registry for pre-authentication and typed
-   data.  The registration procedures are as follows.  Expert review for
-   pre-authentication mechanisms designed to authenticate users, KDCs,
-   or establish the reply key.  The expert first determines that the
-   purpose of the method is to authenticate clients, KDCs, or to
-   establish the reply key.  If so, expert review is appropriate.  The
-   expert evaluates the security and interoperability of the
-   specification.
-
-   IETF review is required if the expert believes that the pre-
-   authentication method is broader than these three areas.  Pre-
-   authentication methods that change the Kerberos state machine or
-   otherwise make significant changes to the Kerberos protocol should be
-   standards track RFCs.  A concern that a particular method needs to be
-   a standards track RFC may be raised as an objection during IETF
-   review.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 37]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-                              Type Value                       Reference
-   PA-TGS-REQ                 1    RFC 4120
-   PA-ENC-TIMESTAMP           2    RFC 4120
-   PA-PW-SALT                 3    RFC 4120
-   [reserved]                 4
-   PA-ENC-UNIX-TIME           5    (deprecated)
-   PA-SANDIA-SECUREID         6
-   PA-SESAME                  7
-   PA-OSF-DCE                 8
-   PA-CYBERSAFE-SECUREID      9
-   PA-AFS3-SALT               10
-   PA-ETYPE-INFO              11   RFC 4120
-   PA-SAM-CHALLENGE           12   (sam/otp)
-   PA-SAM-RESPONSE            13   (sam/otp)
-   PA-PK-AS-REQ_OLD           14   draft-ietf-cat-kerberos-pk-init-09
-   PA-PK-AS-REP_OLD           15   draft-ietf-cat-kerberos-pk-init-09
-   PA-PK-AS-REQ               16   RFC 4556
-   PA-PK-AS-REP               17   RFC 4556
-   PA-ETYPE-INFO2             19   RFC 4120
-   PA-USE-SPECIFIED-KVNO      20
-   PA-SAM-REDIRECT            21   (sam/otp)
-   PA-GET-FROM-TYPED-DATA     22   (embedded in typed data)
-   TD-PADATA                  22   (embeds padata)
-   PA-SAM-ETYPE-INFO          23   (sam/otp)
-   PA-ALT-PRINC               24   (crawdad@fnal.gov)
-   PA-SAM-CHALLENGE2          30   (kenh@pobox.com)
-   PA-SAM-RESPONSE2           31   (kenh@pobox.com)
-   PA-EXTRA-TGT               41   Reserved extra TGT
-   TD-PKINIT-CMS-CERTIFICATES 101  CertificateSet from CMS
-   TD-KRB-PRINCIPAL           102  PrincipalName
-   TD-KRB-REALM               103  Realm
-   TD-TRUSTED-CERTIFIERS      104  from PKINIT
-   TD-CERTIFICATE-INDEX       105  from PKINIT
-   TD-APP-DEFINED-ERROR       106  application specific
-   TD-REQ-NONCE               107  INTEGER
-   TD-REQ-SEQ                 108  INTEGER
-   PA-PAC-REQUEST             128  MS-KILE
-
-
-8.2.  Fast Armor Types
-
-   FAST armor types are defined in Section 6.5.1.  A FAST armor type is
-   a signed 32-bit integer.  FAST armor types are assigned by standards
-   action.
-
-          Type    Name                   Description
-        ------------------------------------------------------------
-          0                              Reserved.
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 38]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-          1   FX_FAST_ARMOR_AP_REQUEST   Ticket armor using an ap-req.
-
-8.3.  FAST Options
-
-   A FAST request includes a set of bit flags to indicate additional
-   options.  Bits 0-15 are critical; other bits are non-critical.
-   Assigning bits greater than 31 may require special support in
-   implementations.  Assignment of FAST options requires standards
-   action.
-
-      Type    Name                   Description
-     -------------------------------------------------------------------
-      0     RESERVED               Reserved for future expansion of this
-                                   field.
-      1     hide-client-names      Requesting the KDC to hide client
-                                   names in  the KDC response
-      16    kdc-follow-referrals   Requesting the KDC to follow
-                                   referrals
-
-
-9.  Security Considerations
-
-   The kdc-referrals option in the Kerberos FAST padata requests the KDC
-   to act as the client to follow referrals.  This can overload the KDC.
-   To limit the damages of denied of service using this option, KDCs MAY
-   restrict the number of simultaneous active requests with this option
-   for any given client principal.
-
-   With regarding to the facilities provided by the Encrypted Challenge
-   FAST factor, the challenge key is derived from the client secrets and
-   because the client secrets are known only to the client and the KDC,
-   the verification of the EncryptedChallenge structure proves the
-   client's identity, the verification of the EncryptedChallenge
-   structure in the KDC reply proves that the expected KDC responded.
-   Therefore, the Encrypted Challenge FAST factor as a pre-
-   authentication mechanism offers the following facilities: client-
-   authentication and KDC-authentication.  There is no un-authenticated
-   clear text introduced by the Encrypted Challenge FAST factor.
-
-
-10.  Acknowledgements
-
-   Sam Hartman would like to thank the MIT Kerberos Consortium for its
-   funding of his time on this project.
-
-   Several suggestions from Jeffrey Hutzelman based on early revisions
-   of this documents led to significant improvements of this document.
-
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 39]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-   The proposal to ask one KDC to chase down the referrals and return
-   the final ticket is based on requirements in [ID.CROSS].
-
-   Joel Webber had a proposal for a mechanism similar to FAST that
-   created a protected tunnel for Kerberos pre-authentication.
-
-
-11.  References
-
-11.1.  Normative References
-
-   [KRB-ANON]
-              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
-              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-11.2.  Informative References
-
-   [ID.CROSS]
-              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
-              Statement on the Operation of Kerberos in a Specific
-              System", draft-sakane-krb-cross-problem-statement-02.txt
-              (work in progress), April 2007.
-
-   [KRB-WG.SAM]
-              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
-              "Integrating Single-use Authentication Mechanisms with
-              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
-              progress), October 2003.
-
-   [REFERRALS]
-              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
-              Locate Kerberos Realms",
-              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
-              progress), 2007.
-
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 40]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-Appendix A.  Change History
-
-   RFC editor, please remove this section before publication.
-
-A.1.  Changes since 08
-
-      Fix a number of typos
-      Rename anonymous flag to hide-client-name; rename kdc-referals to
-      kdc-follow-referrals
-      Clarify how anonymous pkinit interacts with KDC verified.
-      Introduce AD-fx-fast-armor authorization data to deal with
-      unprivileged processes constructing KDC requests.  Note that a TGT
-      is always used for armor tickets if the armor field is present; if
-      you proxy or validate you'll end up with a TGT armor ticket and
-      another ticket in the pa-tgs-req.  Alternatively you can simply
-      use the other ticket in the PA-TGS-REQ; weak consensus within WG.
-      All KDCs in a realm MUST support FAST if it is to be offered.
-      The cookie message is always generated by the KDC.
-      Note that the client can trust and need not verify the time stamp
-      in the finish message.  This can seed the client's idea of KDC
-      time.
-      Note that the client name in the finish message may differ from
-      the name in the request if referrals are used.
-      Note that KDCs should advertize fast in preauth_required errors.
-      Armor key is constructed using KRB-FX-CF2.  This is true even in
-      the TGS case; there is no security reason to do this.  Using the
-      subkey as done in draft 08 would be fine, but the current text
-      uses the same procedure both in the TGS and AS case.
-      Use a different challenge key in each direction in the encrypted
-      challenge option.
-      Note that the KDC should process PA-FX-COOKIE before other padata.
-      KRB-FX-CF2 uses k1's enctype for the result; change around calling
-      order so we pass in subkeys and armor keys as k1 in preference to
-      long-term keys or ticket session keys.
-      Clarify the relationship between authentication sets and cookies.
-      A cookie may not be needed in the first message.  Clarify how this
-      interacts with optimistic clients.
-      Remove text raising a concern that RFC 3961 may permit ciphertext
-      transformations that do not change plaintext: discussion on the
-      list came to the conclusion that RFC 3961 does not permit this.
-      Remove binding key concept; use the armor key instead.  The cookie
-      becomes just an octet string.
-      Include PA-FX-ERROR to protect the error information per Dublin.
-      Returning preauth_failed in the failed to decrypt encrypted
-      challenge seems fine; remove the issue marker
-      Add a section describing what goes in the inner and outer request.
-      I believe it is redundant but found it useful while putting
-      together an implementation proposal.
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 41]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-      Use hyphen rather than underscore in the constants for pre-
-      authentication data to be consistent with RFC 4120.
-      Add a ticket-checksum to the finished message
-      Remove redundant KEY_USAGE_FAST_ARMOR.
-      Add protocol constants section for non-IANA registrations and
-      flesh out IANA section.
-      Clarify that kdc-req-body checksums should always use the outer
-      body even for mechanisms like PKINIT that include their own (now
-      redundant) checksum.
-      Remove mechanism for encapsulating typed data in padata; just
-      reflect the value.
-
-A.2.  Changes since 07
-
-      Propose replacement of authenticated timestamp with encrypted
-      challenge.  The desire to avoid clients needing time
-      synchronization and to simply the factor.
-      Add a requirement that any FAST armor scheme must provide a fresh
-      key for each conversation.  This allows us to assume that anything
-      encrypted/integrity protected in the right key is fresh and not
-      subject to cross-conversation cut and paste.
-      Removed heartbeat padata.  The KDC will double up messages if it
-      needs to; the client simply sends its message and waits for the
-      next response.
-      Define PA-AUTHENTICATION-SET-SELECTED
-      Clarify a KDC cannot ignore padata is has claimed to support
-
-A.3.  Changes since 06
-
-      Note that even for replace reply key it is likely that the side
-      using the mechanism will know that the other side supports it.
-      Since it is reasonably unlikely we'll need a container mechanism
-      other than FAST itself, we don't need to optimize for that case.
-      So, we want to optimize for implementation simplicity.  Thus if
-      you do have such a container mechanism interacting with
-      authentication sets we'll assume that the hint need to describe
-      hints for all contained mechanisms.  This closes out a long-
-      standing issue.
-      Write up what Sam believes is the consensus on UI and prompts in
-      the authentication set: clients MAY assume that they have all the
-      UI information they need.
-
-
-Appendix B.  ASN.1 module
-
-     KerberosPreauthFramework {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2) modules(4) preauth-framework(3)
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 42]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-     } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-     IMPORTS
-          KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
-          Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
-          Microseconds, KerberosFlags
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) };
-                 -- as defined in RFC 4120.
-
-
-     PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-     PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-         pa-type      [0] Int32,
-             -- same as padata-type.
-         pa-hint      [1] OCTET STRING OPTIONAL,
-         pa-value  [2] OCTET STRING OPTIONAL,
-         ...
-     }
-
-     KrbFastArmor ::= SEQUENCE {
-         armor-type   [0] Int32,
-             -- Type of the armor.
-         armor-value  [1] OCTET STRING,
-             -- Value of the armor.
-         ...
-     }
-
-     PA-FX-FAST-REQUEST ::= CHOICE {
-         armored-data [0] KrbFastArmoredReq,
-         ...
-     }
-
-     KrbFastArmoredReq ::= SEQUENCE {
-         armor        [0] KrbFastArmor OPTIONAL,
-             -- Contains the armor that identifies the armor key.
-             -- MUST be present in AS-REQ.
-         req-checksum [1] Checksum,
-             -- Checksum performed over the type KDC-REQ-BODY for
-             -- the req-body field of the KDC-REQ structure defined in
-             -- [RFC4120]
-             -- The checksum key is the armor key, the checksum
-             -- type is the required checksum type for the enctype of
-             -- the armor key, and the key usage number is
-             -- KEY_USAGE_FAST_REQ_CHKSUM.
-         enc-fast-req [2] EncryptedData, -- KrbFastReq --
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 43]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-             -- The encryption key is the armor key, and the key usage
-             -- number is KEY_USAGE_FAST_ENC.
-         ...
-     }
-
-     KrbFastReq ::= SEQUENCE {
-         fast-options [0] FastOptions,
-             -- Additional options.
-         padata       [1] SEQUENCE OF PA-DATA,
-             -- padata typed holes.
-         req-body     [2] KDC-REQ-BODY,
-             -- Contains the KDC request body as defined in Section
-             -- 5.4.1 of [RFC4120].
-             -- This req-body field is preferred over the outer field
-             -- in the KDC request.
-          ...
-     }
-
-     FastOptions ::= KerberosFlags
-         -- reserved(0),
-         -- anonymous(1),
-         -- kdc-referrals(16)
-
-     PA-FX-FAST-REPLY ::= CHOICE {
-         armored-data [0] KrbFastArmoredRep,
-         ...
-     }
-
-     KrbFastArmoredRep ::= SEQUENCE {
-         enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
-             -- The encryption key is the armor key in the request, and
-             -- the key usage number is KEY_USAGE_FAST_REP.
-         ...
-     }
-
-     KrbFastResponse ::= SEQUENCE {
-         padata      [0] SEQUENCE OF PA-DATA,
-             -- padata typed holes.
-         rep-key     [1] EncryptionKey OPTIONAL,
-             -- This, if present, replaces the reply key for AS and TGS.
-             -- MUST be absent in KRB-ERROR.
-         finished    [2] KrbFastFinished OPTIONAL,
-             -- MUST be present if the client is authenticated,
-             -- absent otherwise.
-             -- Typically this is present if and only if the containing
-             -- message is the last one in a conversation.
-         ...
-     }
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 44]
-
-Internet-Draft         Kerberos Preauth Framework          February 2009
-
-
-     KrbFastFinished ::= SEQUENCE {
-         timestamp   [0] KerberosTime,
-         usec        [1] Microseconds,
-             -- timestamp and usec represent the time on the KDC when
-             -- the reply was generated.
-         crealm      [2] Realm,
-         cname       [3] PrincipalName,
-             -- Contains the client realm and the client name.
-         checksum    [4] Checksum,
-             -- Checksum performed over all the messages in the
-             -- conversation, except the containing message.
-             -- The checksum key is the armor key as defined in
-             -- Section 6.5.1, and the checksum type is the required
-             -- checksum type of the armor key.
-         ticket-checksum [5] Checksum,
-             -- checksum  of the ticket in the KDC-REP  using the armor
-             -- and  the key usage is KEY_USAGE_FAST_FINISH.
-             -- The checksum type is the required checksum type
-             -- of the armor key.
-         ...
-     }
-
-     EncryptedChallenge ::= EncryptedData
-             -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-             -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-             -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
-     END
-
-
-Authors' Addresses
-
-   Sam hartman
-   Painless Security
-
-   Email: hartmans-ietf@mit.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-Hartman & Zhu            Expires August 15, 2009               [Page 45]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-10.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-10.txt
deleted file mode 100644
index db244176b..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-10.txt
+++ /dev/null
@@ -1,2633 +0,0 @@
-
-
-
-Kerberos Working Group                                        S. Hartman
-Internet-Draft                                         Painless Security
-Updates: 4120 (if approved)                                       L. Zhu
-Intended status: Standards Track                   Microsoft Corporation
-Expires: September 10, 2009                                March 9, 2009
-
-
-        A Generalized Framework for Kerberos Pre-Authentication
-                 draft-ietf-krb-wg-preauth-framework-10
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 10, 2009.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   Kerberos is a protocol for verifying the identity of principals
-   (e.g., a workstation user or a network server) on an open network.
-
-
-
-Hartman & Zhu          Expires September 10, 2009               [Page 1]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   The Kerberos protocol provides a mechanism called pre-authentication
-   for proving the identity of a principal and for better protecting the
-   long-term secrets of the principal.
-
-   This document describes a model for Kerberos pre-authentication
-   mechanisms.  The model describes what state in the Kerberos request a
-   pre-authentication mechanism is likely to change.  It also describes
-   how multiple pre-authentication mechanisms used in the same request
-   will interact.
-
-   This document also provides common tools needed by multiple pre-
-   authentication mechanisms.  One of these tools is a secure channel
-   between the client and the KDC with a reply key delivery mechanism;
-   this secure channel can be used to protect the authentication
-   exchange thus eliminate offline dictionary attacks.  With these
-   tools, it is relatively straightforward to chain multiple
-   authentication mechanisms, utilize a different key management system,
-   or support a new key agreement algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009               [Page 2]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Conventions and Terminology Used in This Document  . . . . . .  6
-   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  6
-     3.1.  Information Managed by the Pre-authentication Model  . . .  7
-     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  9
-     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . . 10
-     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 11
-   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 12
-     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 13
-     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 14
-     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 15
-     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 15
-   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 15
-   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 16
-     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 17
-     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 18
-     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 19
-     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 20
-     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 23
-       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 24
-       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 26
-       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 30
-       6.5.4.  Authenticated Kerberos Error Messages using
-               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 33
-       6.5.5.  Outer and Inner Requests . . . . . . . . . . . . . . . 34
-       6.5.6.  The Encrypted Challenge FAST Factor  . . . . . . . . . 34
-     6.6.  Authentication Strength Indication . . . . . . . . . . . . 36
-   7.  Assigned Constants . . . . . . . . . . . . . . . . . . . . . . 36
-     7.1.  New Errors . . . . . . . . . . . . . . . . . . . . . . . . 37
-     7.2.  Key Usage Numbers  . . . . . . . . . . . . . . . . . . . . 37
-     7.3.  Authorization Data Elements  . . . . . . . . . . . . . . . 37
-     7.4.  New PA-DATA Types  . . . . . . . . . . . . . . . . . . . . 37
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 37
-     8.1.  Pre-authentication and Typed Data  . . . . . . . . . . . . 37
-     8.2.  Fast Armor Types . . . . . . . . . . . . . . . . . . . . . 39
-     8.3.  FAST Options . . . . . . . . . . . . . . . . . . . . . . . 40
-   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 40
-   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 41
-     11.2. Informative References . . . . . . . . . . . . . . . . . . 41
-   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 42
-     A.1.  Changes since 09 . . . . . . . . . . . . . . . . . . . . . 42
-     A.2.  Changes since 08 . . . . . . . . . . . . . . . . . . . . . 42
-     A.3.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 43
-     A.4.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 43
-
-
-
-Hartman & Zhu          Expires September 10, 2009               [Page 3]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   Appendix B.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 44
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009               [Page 4]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-1.  Introduction
-
-   The core Kerberos specification [RFC4120] treats pre-authentication
-   data as an opaque typed hole in the messages to the KDC that may
-   influence the reply key used to encrypt the KDC reply.  This
-   generality has been useful: pre-authentication data is used for a
-   variety of extensions to the protocol, many outside the expectations
-   of the initial designers.  However, this generality makes designing
-   more common types of pre-authentication mechanisms difficult.  Each
-   mechanism needs to specify how it interacts with other mechanisms.
-   Also, problems like combining a key with the long-term secrets or
-   proving the identity of the user are common to multiple mechanisms.
-   Where there are generally well-accepted solutions to these problems,
-   it is desirable to standardize one of these solutions so mechanisms
-   can avoid duplication of work.  In other cases, a modular approach to
-   these problems is appropriate.  The modular approach will allow new
-   and better solutions to common pre-authentication problems to be used
-   by existing mechanisms as they are developed.
-
-   This document specifies a framework for Kerberos pre-authentication
-   mechanisms.  It defines the common set of functions that pre-
-   authentication mechanisms perform as well as how these functions
-   affect the state of the request and reply.  In addition several
-   common tools needed by pre-authentication mechanisms are provided.
-   Unlike [RFC3961], this framework is not complete--it does not
-   describe all the inputs and outputs for the pre-authentication
-   mechanisms.  Pre-Authentication mechanism designers should try to be
-   consistent with this framework because doing so will make their
-   mechanisms easier to implement.  Kerberos implementations are likely
-   to have plugin architectures for pre-authentication; such
-   architectures are likely to support mechanisms that follow this
-   framework plus commonly used extensions.  This framework also
-   facilitates combining multiple pre-authentication mechanisms, each of
-   which may represent an authentication factor, into a single multi-
-   factor pre-authentication mechanism.
-
-   One of these common tools is the flexible authentication secure
-   tunneling (FAST) padata type.  FAST provides a protected channel
-   between the client and the KDC, and it can optionally deliver a reply
-   key within the protected channel.  Based on FAST, pre-authentication
-   mechanisms can extend Kerberos with ease, to support, for example,
-   password authenticated key exchange (PAKE) protocols with zero
-   knowledge password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-
-   authentication mechanism can be encapsulated in the FAST messages as
-   defined in Section 6.5.  A pre-authentication type carried within
-   FAST is called a FAST factor.  Creating a FAST factor is the easiest
-   path to create a new pre-authentication mechanism.  FAST factors are
-   significantly easier to analyze from a security standpoint than other
-
-
-
-Hartman & Zhu          Expires September 10, 2009               [Page 5]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   pre-authentication mechanisms.
-
-   Mechanism designers should design FAST factors, instead of new pre-
-   authentication mechanisms outside of FAST.
-
-
-2.  Conventions and Terminology Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   This document should be read only after reading the documents
-   describing the Kerberos cryptography framework [RFC3961] and the core
-   Kerberos protocol [RFC4120].  This document may freely use
-   terminology and notation from these documents without reference or
-   further explanation.
-
-   The word padata is used as a shorthand for pre-authentication data.
-
-   A conversation is the set of all authentication messages exchanged
-   between the client and the client's Authentication Service (AS) in
-   order to authenticate the client principal.  A conversation as
-   defined here consists of all messages that are necessary to complete
-   the authentication between the client and the client's AS.  In the
-   Ticket Exchange Service (TGS) exchange, a conversation consists of
-   the request message and the reply message.  The term conversation is
-   defined here for both AS and TGS for convenience of discussion.  See
-   Section 6.3 for specific rules on the extent of a conversation in the
-   AS-REQ case.  Prior to this framework, implementations needed to use
-   implementation-specific heuristics to determine the extent of a
-   conversation.
-
-   If the KDC reply in an AS exchange is verified, the KDC is
-   authenticated by the client.  In this document, verification of the
-   KDC reply is used as a synonym of authentication of the KDC.
-
-
-3.  Model for Pre-Authentication
-
-   When a Kerberos client wishes to obtain a ticket using the
-   authentication server, it sends an initial Authentication Service
-   (AS) request.  If pre-authentication is required but not being used,
-   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
-   Alternatively, if the client knows what pre-authentication to use, it
-   MAY optimize away a round-trip and send an initial request with
-   padata included in the initial request.  If the client includes the
-   padata computed using the wrong pre-authentication mechanism or
-
-
-
-Hartman & Zhu          Expires September 10, 2009               [Page 6]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
-   indication of what padata should have been included.  In that case,
-   the client MUST retry with no padata and examine the error data of
-   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
-   authentication information in the accompanying error data of
-   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
-   then retry.
-
-   The conventional KDC maintains no state between two requests;
-   subsequent requests may even be processed by a different KDC.  On the
-   other hand, the client treats a series of exchanges with KDCs as a
-   single conversation.  Each exchange accumulates state and hopefully
-   brings the client closer to a successful authentication.
-
-   These models for state management are in apparent conflict.  For many
-   of the simpler pre-authentication scenarios, the client uses one
-   round trip to find out what mechanisms the KDC supports.  Then the
-   next request contains sufficient pre-authentication for the KDC to be
-   able to return a successful reply.  For these simple scenarios, the
-   client only sends one request with pre-authentication data and so the
-   conversation is trivial.  For more complex conversations, the KDC
-   needs to provide the client with a cookie to include in future
-   requests to capture the current state of the authentication session.
-   Handling of multiple round-trip mechanisms is discussed in
-   Section 6.3.
-
-   This framework specifies the behavior of Kerberos pre-authentication
-   mechanisms used to identify users or to modify the reply key used to
-   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
-   extensions to Kerberos that have nothing to do with proving the
-   identity of the user or establishing a reply key.  Such extensions
-   are outside the scope of this framework.  However mechanisms that do
-   accomplish these goals should follow this framework.
-
-   This framework specifies the minimum state that a Kerberos
-   implementation needs to maintain while handling a request in order to
-   process pre-authentication.  It also specifies how Kerberos
-   implementations process the padata at each step of the AS request
-   process.
-
-3.1.  Information Managed by the Pre-authentication Model
-
-   The following information is maintained by the client and KDC as each
-   request is being processed:
-
-   o  The reply key used to encrypt the KDC reply
-
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009               [Page 7]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   o  How strongly the identity of the client has been authenticated
-
-   o  Whether the reply key has been used in this conversation
-
-   o  Whether the reply key has been replaced in this conversation
-
-   o  Whether the contents of the KDC reply can be verified by the
-      client principal
-
-
-   Conceptually, the reply key is initially the long-term key of the
-   principal.  However, principals can have multiple long-term keys
-   because of support for multiple encryption types, salts and
-   string2key parameters.  As described in Section 5.2.7.5 of the
-   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
-   the client what types of keys are available.  Thus in full
-   generality, the reply key in the pre-authentication model is actually
-   a set of keys.  At the beginning of a request, it is initialized to
-   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
-   the KDC.  If multiple reply keys are available, the client chooses
-   which one to use.  Thus the client does not need to treat the reply
-   key as a set.  At the beginning of a request, the client picks a key
-   to use.
-
-   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
-   INFO2 element.  Since the KDC already knows the client's list of
-   supported enctypes from the request, no interoperability problems are
-   created by choosing a single possible reply key.  This way, the KDC
-   implementation avoids the complexity of treating the reply key as a
-   set.
-
-   When the padata in the request is verified by the KDC, then the
-   client is known to have that key, therefore the KDC SHOULD pick the
-   same key as the reply key.
-
-   At the beginning of handling a message on both the client and the
-   KDC, the client's identity is not authenticated.  A mechanism may
-   indicate that it has successfully authenticated the client's
-   identity.  This information is useful to keep track of on the client
-   in order to know what pre-authentication mechanisms should be used.
-   The KDC needs to keep track of whether the client is authenticated
-   because the primary purpose of pre-authentication is to authenticate
-   the client identity before issuing a ticket.  The handling of
-   authentication strength using various authentication mechanisms is
-   discussed in Section 6.6.
-
-   Initially the reply key has not been used.  A pre-authentication
-   mechanism that uses the reply key to encrypt or checksum some data in
-
-
-
-Hartman & Zhu          Expires September 10, 2009               [Page 8]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   the generation of new keys MUST indicate that the reply key is used.
-   This state is maintained by the client and the KDC to enforce the
-   security requirement stated in Section 4.3 that the reply key SHOULD
-   NOT be replaced after it is used.
-
-   Initially the reply key has not been replaced.  If a mechanism
-   implements the Replace Reply Key facility discussed in Section 4.3,
-   then the state MUST be updated to indicate that the reply key has
-   been replaced.  Once the reply key has been replaced, knowledge of
-   the reply key is insufficient to authenticate the client.  The reply
-   key is marked replaced in exactly the same situations as the KDC
-   reply is marked as not being verified to the client principal.
-   However, while mechanisms can verify the KDC reply to the client,
-   once the reply key is replaced, then the reply key remains replaced
-   for the remainder of the conversation.
-
-   Without pre-authentication, the client knows that the KDC reply is
-   authentic and has not been modified because it is encrypted in a
-   long-term key of the client.  Only the KDC and the client know that
-   key.  So at the start of a conversation, the KDC reply is presumed to
-   be verified using the client principal's long-term key.  It should be
-   noted that in this document, verifying the KDC reply means
-   authenticating the KDC, and these phrases are used interchangeably.
-   Any pre-authentication mechanism that sets a new reply key not based
-   on the principal's long-term secret MUST either verify the KDC reply
-   some other way or indicate that the reply is not verified.  If a
-   mechanism indicates that the reply is not verified then the client
-   implementation MUST return an error unless a subsequent mechanism
-   verifies the reply.  The KDC needs to track this state so it can
-   avoid generating a reply that is not verified.
-
-   The typical Kerberos request does not provide a way for the client
-   machine to know that it is talking to the correct KDC.  Someone who
-   can inject packets into the network between the client machine and
-   the KDC and who knows the password that the user will give to the
-   client machine can generate a KDC reply that will decrypt properly.
-   So, if the client machine needs to authenticate that the user is in
-   fact the named principal, then the client machine needs to do a TGS
-   request for itself as a service.  Some pre-authentication mechanisms
-   may provide a way for the client machine to authenticate the KDC.
-   Examples of this include signing the reply that can be verified using
-   a well-known public key or providing a ticket for the client machine
-   as a service.
-
-3.2.  Initial Pre-authentication Required Error
-
-   Typically a client starts a conversation by sending an initial
-   request with no pre-authentication.  If the KDC requires pre-
-
-
-
-Hartman & Zhu          Expires September 10, 2009               [Page 9]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
-   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
-   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
-   (defined in Section 6.3) for pre-authentication configurations that
-   use multi-round-trip mechanisms; see Section 3.4 for details of that
-   case.
-
-   The KDC needs to choose which mechanisms to offer the client.  The
-   client needs to be able to choose what mechanisms to use from the
-   first message.  For example consider the KDC that will accept
-   mechanism A followed by mechanism B or alternatively the single
-   mechanism C. A client that supports A and C needs to know that it
-   should not bother trying A.
-
-   Mechanisms can either be sufficient on their own or can be part of an
-   authentication set--a group of mechanisms that all need to
-   successfully complete in order to authenticate a client.  Some
-   mechanisms may only be useful in authentication sets; others may be
-   useful alone or in authentication sets.  For the second group of
-   mechanisms, KDC policy dictates whether the mechanism will be part of
-   an authentication set or offered alone.  For each mechanism that is
-   offered alone, the KDC includes the pre-authentication type ID of the
-   mechanism in the padata sequence returned in the
-   KDC_ERR_PREAUTH_REQUIRED error.
-
-   The KDC SHOULD NOT send data that is encrypted in the long-term
-   password-based key of the principal.  Doing so has the same security
-   exposures as the Kerberos protocol without pre-authentication.  There
-   are few situations where the KDC needs to expose cipher text
-   encrypted in a weak key before the client has proven knowledge of
-   that key, and pre-authentication is desirable.
-
-3.3.  Client to KDC
-
-   This description assumes that a client has already received a
-   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
-   optimistic pre-authentication then the client needs to guess values
-   for the information it would normally receive from that error
-   response or use cached information obtained in prior interactions
-   with the KDC.
-
-   The client starts by initializing the pre-authentication state as
-   specified.  It then processes the padata in the
-   KDC_ERR_PREAUTH_REQUIRED.
-
-   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
-   client MAY ignore any padata it chooses unless doing so violates a
-   specification to which the client conforms.  Clients conforming to
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 10]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   this specification MUST NOT ignore the padata defined in Section 6.3.
-   Clients SHOULD process padata unrelated to this framework or other
-   means of authenticating the user.  Clients SHOULD choose one
-   authentication set or mechanism that could lead to authenticating the
-   user and ignore the rest.  Since the list of mechanisms offered by
-   the KDC is in the decreasing preference order, clients typically
-   choose the first mechanism or authentication set that the client can
-   usefully perform.  If a client chooses to ignore a padata it MUST NOT
-   process the padata, allow the padata to affect the pre-authentication
-   state, nor respond to the padata.
-
-   For each padata the client chooses to process, the client processes
-   the padata and modifies the pre-authentication state as required by
-   that mechanism.  Padata are processed in the order received from the
-   KDC.
-
-   After processing the padata in the KDC error, the client generates a
-   new request.  It processes the pre-authentication mechanisms in the
-   order in which they will appear in the next request, updating the
-   state as appropriate.  The request is sent when it is complete.
-
-3.4.  KDC to Client
-
-   When a KDC receives an AS request from a client, it needs to
-   determine whether it will respond with an error or an AS reply.
-   There are many causes for an error to be generated that have nothing
-   to do with pre-authentication; they are discussed in the core
-   Kerberos specification.
-
-   From the standpoint of evaluating the pre-authentication, the KDC
-   first starts by initializing the pre-authentication state.  If a PA-
-   FX-COOKIE pre-authentication data item is present, it is processed
-   first; see Section 6.3 for a definition.  It then processes the
-   padata in the request.  As mentioned in Section 3.3, the KDC MAY
-   ignore padata that is inappropriate for the configuration and MUST
-   ignore padata of an unknown type.  The KDC MUST NOT ignore padata of
-   types used in previous messages.  For example, if a KDC issues a
-   KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the
-   KDC cannot ignore padata of type x received in an AS-REQ message from
-   the client.
-
-   At this point the KDC decides whether it will issue an error or a
-   reply.  Typically a KDC will issue a reply if the client's identity
-   has been authenticated to a sufficient degree.
-
-   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC
-   first starts by initializing the pre-authentication state.  Then it
-   processes any padata in the client's request in the order provided by
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 11]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   the client.  Mechanisms that are not understood by the KDC are
-   ignored.  Next, it generates padata for the error response, modifying
-   the pre-authentication state appropriately as each mechanism is
-   processed.  The KDC chooses the order in which it will generate
-   padata (and thus the order of padata in the response), but it needs
-   to modify the pre-authentication state consistently with the choice
-   of order.  For example, if some mechanism establishes an
-   authenticated client identity, then the subsequent mechanisms in the
-   generated response receive this state as input.  After the padata is
-   generated, the error response is sent.  Typically the errors with the
-   code KDC_ERR_MORE_PREAUTH_DATA_NEEDED in a conversation will include
-   KDC state as discussed in Section 6.3.
-
-   To generate a final reply, the KDC generates the padata modifying the
-   pre-authentication state as necessary.  Then it generates the final
-   response, encrypting it in the current pre-authentication reply key.
-
-
-4.  Pre-Authentication Facilities
-
-   Pre-Authentication mechanisms can be thought of as providing various
-   conceptual facilities.  This serves two useful purposes.  First,
-   mechanism authors can choose only to solve one specific small
-   problem.  It is often useful for a mechanism designed to offer key
-   management not to directly provide client authentication but instead
-   to allow one or more other mechanisms to handle this need.  Secondly,
-   thinking about the abstract services that a mechanism provides yields
-   a minimum set of security requirements that all mechanisms providing
-   that facility must meet.  These security requirements are not
-   complete; mechanisms will have additional security requirements based
-   on the specific protocol they employ.
-
-   A mechanism is not constrained to only offering one of these
-   facilities.  While such mechanisms can be designed and are sometimes
-   useful, many pre-authentication mechanisms implement several
-   facilities.  By combining multiple facilities in a single mechanism,
-   it is often easier to construct a secure, simple solution than by
-   solving the problem in full generality.  Even when mechanisms provide
-   multiple facilities, they need to meet the security requirements for
-   all the facilities they provide.  If the FAST factor approach is
-   used, it is likely that one or a small number of facilities can be
-   provided by a single mechanism without complicating the security
-   analysis.
-
-   According to Kerberos extensibility rules (Section 1.5 of the
-   Kerberos specification [RFC4120]), an extension MUST NOT change the
-   semantics of a message unless a recipient is known to understand that
-   extension.  Because a client does not know that the KDC supports a
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 12]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   particular pre-authentication mechanism when it sends an initial
-   request, a pre-authentication mechanism MUST NOT change the semantics
-   of the request in a way that will break a KDC that does not
-   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
-   clients that affect the core semantics unless the client has
-   indicated support for the message.
-
-   The only state in this model that would break the interpretation of a
-   message is changing the expected reply key.  If one mechanism changed
-   the reply key and a later mechanism used that reply key, then a KDC
-   that interpreted the second mechanism but not the first would fail to
-   interpret the request correctly.  In order to avoid this problem,
-   extensions that change core semantics are typically divided into two
-   parts.  The first part proposes a change to the core semantic--for
-   example proposes a new reply key.  The second part acknowledges that
-   the extension is understood and that the change takes effect.
-   Section 4.2 discusses how to design mechanisms that modify the reply
-   key to be split into a proposal and acceptance without requiring
-   additional round trips to use the new reply key in subsequent pre-
-   authentication.  Other changes in the state described in Section 3.1
-   can safely be ignored by a KDC that does not understand a mechanism.
-   Mechanisms that modify the behavior of the request outside the scope
-   of this framework need to carefully consider the Kerberos
-   extensibility rules to avoid similar problems.
-
-4.1.  Client-authentication Facility
-
-   The client authentication facility proves the identity of a user to
-   the KDC before a ticket is issued.  Examples of mechanisms
-   implementing this facility include the encrypted timestamp facility
-   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
-   Mechanisms that provide this facility are expected to mark the client
-   as authenticated.
-
-   Mechanisms implementing this facility SHOULD require the client to
-   prove knowledge of the reply key before transmitting a successful KDC
-   reply.  Otherwise, an attacker can intercept the pre-authentication
-   exchange and get a reply to attack.  One way of proving the client
-   knows the reply key is to implement the Replace Reply Key facility
-   along with this facility.  The PKINIT mechanism [RFC4556] implements
-   Client Authentication alongside Replace Reply Key.
-
-   If the reply key has been replaced, then mechanisms such as
-   encrypted-timestamp that rely on knowledge of the reply key to
-   authenticate the client MUST NOT be used.
-
-
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 13]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-4.2.  Strengthening-reply-key Facility
-
-   Particularly when dealing with keys based on passwords, it is
-   desirable to increase the strength of the key by adding additional
-   secrets to it.  Examples of sources of additional secrets include the
-   results of a Diffie-Hellman key exchange or key bits from the output
-   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
-   be first combined with the existing reply key and then converted to a
-   protocol key using tools defined in Section 6.1.
-
-   Typically a mechanism implementing this facility will know that the
-   other side of the exchange supports the facility before the reply key
-   is changed.  For example, a mechanism might need to learn the
-   certificate for a KDC before encrypting a new key in the public key
-   belonging to that certificate.  However, if a mechanism implementing
-   this facility wishes to modify the reply key before knowing that the
-   other party in the exchange supports the mechanism, it proposes
-   modifying the reply key.  The other party then includes a message
-   indicating that the proposal is accepted if it is understood and
-   meets policy.  In many cases it is desirable to use the new reply key
-   for client authentication and for other facilities.  Waiting for the
-   other party to accept the proposal and actually modify the reply key
-   state would add an additional round trip to the exchange.  Instead,
-   mechanism designers are encouraged to include a typed hole for
-   additional padata in the message that proposes the reply key change.
-   The padata included in the typed hole are generated assuming the new
-   reply key.  If the other party accepts the proposal, then these
-   padata are considered as an inner level.  As with the outer level,
-   one authentication set or mechanism is typically chosen for client
-   authentication, along with auxiliary mechanisms such as KDC cookies,
-   and other mechanisms are ignored.  When mechanisms include such a
-   container, the hint provided for use in authentication sets (as
-   defined in Section 6.4) MUST contain a sequence of inner mechanisms
-   along with hints for those mechanisms.  The party generating the
-   proposal can determine whether the padata were processed based on
-   whether the proposal for the reply key is accepted.
-
-   The specific formats of the proposal message, including where padata
-   are included is a matter for the mechanism specification.  Similarly,
-   the format of the message accepting the proposal is mechanism-
-   specific.
-
-   Mechanisms implementing this facility and including a typed hole for
-   additional padata MUST checksum that padata using a keyed checksum or
-   encrypt the padata.  This requirement protects against modification
-   of the contents of the typed hole.  By modifying these contents an
-   attacker might be able to choose which mechanism is used to
-   authenticate the client, or to convince a party to provide text
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 14]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   encrypted in a key that the attacker had manipulated.  It is
-   important that mechanisms strengthen the reply key enough that using
-   it to checksum padata is appropriate.
-
-4.3.  Replacing-reply-key Facility
-
-   The Replace Reply Key facility replaces the key in which a successful
-   AS reply will be encrypted.  This facility can only be used in cases
-   where knowledge of the reply key is not used to authenticate the
-   client.  The new reply key MUST be communicated to the client and the
-   KDC in a secure manner.  This facility MUST NOT be used if there can
-   be a man-in-the-middle between the client and the KDC.  Mechanisms
-   implementing this facility MUST mark the reply key as replaced in the
-   pre-authentication state.  Mechanisms implementing this facility MUST
-   either provide a mechanism to verify the KDC reply to the client or
-   mark the reply as unverified in the pre-authentication state.
-   Mechanisms implementing this facility SHOULD NOT be used if a
-   previous mechanism has used the reply key.
-
-   As with the strengthening-reply-key facility, Kerberos extensibility
-   rules require that the reply key not be changed unless both sides of
-   the exchange understand the extension.  In the case of this facility
-   it will likely be the case for both sides to know that the facility
-   is available by the time that the new key is available to be used.
-   However, mechanism designers can use a container for padata in a
-   proposal message as discussed in Section 4.2 if appropriate.
-
-4.4.  KDC-authentication Facility
-
-   This facility verifies that the reply comes from the expected KDC.
-   In traditional Kerberos, the KDC and the client share a key, so if
-   the KDC reply can be decrypted then the client knows that a trusted
-   KDC responded.  Note that the client machine cannot trust the client
-   unless the machine is presented with a service ticket for it
-   (typically the machine can retrieve this ticket by itself).  However,
-   if the reply key is replaced, some mechanism is required to verify
-   the KDC.  Pre-authentication mechanisms providing this facility allow
-   a client to determine that the expected KDC has responded even after
-   the reply key is replaced.  They mark the pre-authentication state as
-   having been verified.
-
-
-5.  Requirements for Pre-Authentication Mechanisms
-
-   This section lists requirements for specifications of pre-
-   authentication mechanisms.
-
-   For each message in the pre-authentication mechanism, the
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 15]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   specification describes the pa-type value to be used and the contents
-   of the message.  The processing of the message by the sender and
-   recipient is also specified.  This specification needs to include all
-   modifications to the pre-authentication state.
-
-   Generally mechanisms have a message that can be sent in the error
-   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
-   authentication set.  If the client needs information such as trusted
-   certificate authorities in order to determine if it can use the
-   mechanism, then this information should be in that message.  In
-   addition, such mechanisms should also define a pa-hint to be included
-   in authentication sets.  Often, the same information included in the
-   padata-value is appropriate to include in the pa-hint (as defined in
-   Section 6.4).
-
-   In order to ease security analysis the mechanism specification should
-   describe what facilities from this document are offered by the
-   mechanism.  For each facility, the security consideration section of
-   the mechanism specification should show that the security
-   requirements of that facility are met.  This requirement is
-   applicable to any FAST factor that provides authentication
-   information.
-
-   Significant problems have resulted in the specification of Kerberos
-   protocols because much of the KDC exchange is not protected against
-   authentication.  The security considerations section should discuss
-   unauthenticated plaintext attacks.  It should either show that
-   plaintext is protected or discuss what harm an attacker could do by
-   modifying the plaintext.  It is generally acceptable for an attacker
-   to be able to cause the protocol negotiation to fail by modifying
-   plaintext.  More significant attacks should be evaluated carefully.
-
-   As discussed in Section 6.3, there is no guarantee that a client will
-   use the same KDCs for all messages in a conversation.  The mechanism
-   specification needs to show why the mechanism is secure in this
-   situation.  The hardest problem to deal with, especially for
-   challenge/response mechanisms is to make sure that the same response
-   cannot be replayed against two KDCs while allowing the client to talk
-   to any KDC.
-
-
-6.  Tools for Use in Pre-Authentication Mechanisms
-
-   This section describes common tools needed by multiple pre-
-   authentication mechanisms.  By using these tools mechanism designers
-   can use a modular approach to specify mechanism details and ease
-   security analysis.
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 16]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-6.1.  Combining Keys
-
-   Frequently a weak key needs to be combined with a stronger key before
-   use.  For example, passwords are typically limited in size and
-   insufficiently random, therefore it is desirable to increase the
-   strength of the keys based on passwords by adding additional secrets.
-   Additional source of secrecy may come from hardware tokens.
-
-   This section provides standard ways to combine two keys into one.
-
-   KRB-FX-CF1() is defined to combine two pass-phrases.
-
-       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
-       KRB-FX-CF1(x, y) -> x || y
-
-   Where || denotes concatenation.  The strength of the final key is
-   roughly the total strength of the individual keys being combined
-   assuming that the string_to_key() function [RFC3961] uses all its
-   input evenly.
-
-   An example usage of KRB-FX-CF1() is when a device provides random but
-   short passwords, the password is often combined with a personal
-   identification number (PIN).  The password and the PIN can be
-   combined using KRB-FX-CF1().
-
-   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
-   function defined in [RFC3961].
-
-   Given two input keys, K1 and K2, where K1 and K2 can be of two
-   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
-   follows:
-
-       KRB-FX-CF2(protocol key, protocol key, octet string,
-                 octet string)  ->  (protocol key)
-
-       PRF+(K1, pepper1) -> octet-string-1
-       PRF+(K2, pepper2) -> octet-string-2
-       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
-              random-to-key(octet-string-1 ^ octet-string-2)
-
-   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
-   follows:
-
-    PRF+(protocol key, octet string) -> (octet string)
-
-    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
-                  pseudo-random( key, 2 || shared-info ) ||
-                  pseudo-random( key, 3 || shared-info ) || ...
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 17]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
-   integer.  The pseudo-random() operation is specified by the enctype
-   of the protocol key.  PRF+() uses the counter to generate enough bits
-   as needed by the random-to-key() [RFC3961] function for the
-   encryption type specified for the resulting key; unneeded bits are
-   removed from the tail.  Unless otherwise specified, the resulting
-   enctype of KRB-FX-CF2 is the enctype of k1.
-
-   Mechanism designers MUST specify the values for the input parameter
-   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
-   pepper1 and pepper2 MUST be distinct so that if the two keys being
-   combined are the same, the resulting key is not a trivial key.
-
-6.2.  Protecting Requests/Responses
-
-   Mechanism designers SHOULD protect clear text portions of pre-
-   authentication data.  Various denial of service attacks and downgrade
-   attacks against Kerberos are possible unless plaintexts are somehow
-   protected against modification.  An early design goal of Kerberos
-   Version 5 [RFC4120] was to avoid encrypting more of the
-   authentication exchange that was required.  (Version 4 doubly-
-   encrypted the encrypted part of a ticket in a KDC reply, for
-   example.)  This minimization of encryption reduces the load on the
-   KDC and busy servers.  Also, during the initial design of Version 5,
-   the existence of legal restrictions on the export of cryptography
-   made it desirable to minimize of the number of uses of encryption in
-   the protocol.  Unfortunately, performing this minimization created
-   numerous instances of unauthenticated security-relevant plaintext
-   fields.
-
-   If there is more than one round trip for an authentication exchange,
-   mechanism designers need to allow either the client or the KDC to
-   provide a checksum of all the messages exchanged on the wire in the
-   conversation, and the checksum is then verified by the receiver.
-
-   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
-
-   Primitives defined in [RFC3961] are RECOMMENDED for integrity
-   protection and confidentiality.  Mechanisms based on these primitives
-   are crypto-agile as the result of using [RFC3961] along with
-   [RFC4120].  The advantage afforded by crypto-agility is the ability
-   to incrementally deploy a fix specific to a particular algorithm thus
-   avoid a multi-year standardization and deployment cycle, when real
-   attacks do arise against that algorithm.
-
-   Note that data used by FAST factors (defined in Section 6.5) is
-   encrypted in a protected channel, thus they do not share the un-
-   authenticated-text issues with mechanisms designed as full-blown pre-
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 18]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   authentication mechanisms.
-
-6.3.  Managing States for the KDC
-
-   Kerberos KDCs are stateless.  There is no requirement that clients
-   will choose the same KDC for the second request in a conversation.
-   Proxies or other intermediate nodes may also influence KDC selection.
-   So, each request from a client to a KDC must include sufficient
-   information that the KDC can regenerate any needed state.  This is
-   accomplished by giving the client a potentially long opaque cookie in
-   responses to include in future requests in the same conversation.
-   The KDC MAY respond that a conversation is too old and needs to
-   restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
-
-       KDC_ERR_PREAUTH_EXPIRED            90
-
-   When a client receives this error, the client SHOULD abort the
-   existing conversation, and restart a new one.
-
-   An example, where more than one message from the client is needed, is
-   when the client is authenticated based on a challenge-response
-   scheme.  In that case, the KDC needs to keep track of the challenge
-   issued for a client authentication request.
-
-   The PA-FX-COOKIE padata type is defined in this section to facilitate
-   state management in the AS exchange.  This padata is sent by the KDC
-   when the KDC requires state for a future transaction.  The client
-   includes this opaque token in the next message in the conversation.
-   The token may be relatively large; clients MUST be prepared for
-   tokens somewhat larger than the size of all messages in a
-   conversation.
-
-       PA-FX-COOKIE                       133
-           -- Stateless cookie that is not tied to a specific KDC.
-
-   The corresponding padata-value field [RFC4120] contains an opaque
-   token that will be echoed by the client in its response to an error
-   from the KDC.
-
-   The cookie token is generated by the KDC and transmitted in a PA-FX-
-   COOKIE pre-authentication data item of a KRB-ERROR message.  The
-   client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data
-   element into the next message of the same conversation.  The content
-   of the cookie field is a local matter of the KDC.  As a result, it is
-   not generally possible to mix KDC implementations from different
-   vendors in the same realm.  However the KDC MUST construct the cookie
-   token in such a manner that a malicious client cannot subvert the
-   authentication process by manipulating the token.  The KDC
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 19]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   implementation needs to consider expiration of tokens, key rollover
-   and other security issues in token design.  The content of the cookie
-   field is likely specific to the pre-authentication mechanisms used to
-   authenticate the client.  If a client authentication response can be
-   replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an
-   expiration in the cookie is RECOMMENDED to prevent the response being
-   presented indefinitely.
-
-   If at least one more message for a mechanism or a mechanism set is
-   expected by the KDC, the KDC returns a
-   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA-FX-COOKIE to
-   identify the conversation with the client according to Section 3.2.
-   The cookie is not expected to stay constant for a conversation: the
-   KDC is expected to generate a new cookie for each message.
-
-        KDC_ERR_MORE_PREAUTH_DATA_NEEDED   91
-
-   A client MAY throw away the state associated with a conversation and
-   begin a new conversation by discarding its state and not including a
-   cooking in the first message of a conversation.  KDCs that comply
-   with this specification MUST include a cookie in a response when the
-   client can continue the conversation.  In particular, a KDC MUST
-   include a cookie in a KDC_ERR_PREAUTH_REQUIRED or
-   KDC_ERR_MORE_PREAUTH_DATA_NEEDED.  KDCs SHOULD include a cookie in
-   errors containing additional information allowing a client to retry.
-   One reasonable strategy for meeting these requirements is to always
-   include a cookie in KDC errors.
-
-   A KDC MAY indicate that it is terminating a conversation by not
-   including a cookie in a response.  When FAST is used, clients can
-   assume that the absence of a cookie means that the KDC is ending the
-   conversation.  Clients also need to deal with KDCs prior to this
-   specification that do not include cookies; if cookies nor FAST are
-   used in a conversation, the absence of a cookie is not a strong
-   indication that the KDC is terminating the conversation.
-
-6.4.  Pre-authentication Set
-
-   If all mechanisms in a group need to successfully complete in order
-   to authenticate a client, the client and the KDC SHOULD use the PA-
-   AUTHENTICATION-SET padata element.
-
-        PA-AUTHENTICATION-SET              134
-
-   A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
-   encoding of the PA-AUTHENTICATION-SET structure:
-
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 20]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-            pa-type      [0] Int32,
-                -- same as padata-type.
-            pa-hint      [1] OCTET STRING OPTIONAL,
-            pa-value  [2] OCTET STRING OPTIONAL,
-            ...
-        }
-
-   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
-   contains the corresponding value of padata-type in PA-DATA [RFC4120].
-   Associated with the pa-type is a pa-hint, which is an octet-string
-   specified by the pre-authentication mechanism.  This hint may provide
-   information for the client which helps it determine whether the
-   mechanism can be used.  For example a public-key mechanism might
-   include the certificate authorities it trusts in the hint info.  Most
-   mechanisms today do not specify hint info; if a mechanism does not
-   specify hint info the KDC MUST NOT send a hint for that mechanism.
-   To allow future revisions of mechanism specifications to add hint
-   info, clients MUST ignore hint info received for mechanisms that the
-   client believes do not support hint info.  The pa-value element of
-   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
-   first padata-value from the KDC to the client.  If the client chooses
-   this authentication set then the client MUST process this pa-value.
-   The pa-value element MUST be absent for all but the first entry in
-   the authentication set.  Clients MUST ignore pa-value for the second
-   and following entries in the authentication set.
-
-   If the client chooses an authentication set, then its first AS-REQ
-   message MUST contain a PA-AUTH-SET-SELECTED padata element.  This
-   element contains the encoding of the PA-AUTHENTICATION-SET sequence
-   received from the KDC corresponding to the authentication set that is
-   chosen.  The client MUST use the same octet values received from the
-   KDC; it cannot re-encode the sequence.  This allows KDCs to use bit-
-   wise comparison to identify the selected authentication set.  The PA-
-   AUTH-SET-SELECTED padata element MUST come before any padata elements
-   from the authentication set in the padata sequence in the AS-REQ
-   message.  The client MAY cache authentication sets from prior
-   messages and use them to construct an optimistic initial AS-REQ.  If
-   the KDC receives a PA-AUTH-SET-SELECTED padata element that does not
-   correspond to an authentication set that it would offer, then the KDC
-   returns the KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The e-data
-   in this error contains a sequence of padata just as for the
-   KDC_ERR_PREAUTH_REQUIRED error.
-
-
-         PA-AUTH-SET-SELECTED                   135
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 21]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-         KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
-
-   The PA-AUTHENTICATION-SET appears only in the first message from the
-   KDC to the client.  In particular, the client MAY fail if the
-   authentication mechanism sets change as the conversation progresses.
-   Clients MAY assume that the hints provided in the authentication set
-   contain enough information that the client knows what user interface
-   elements need to be displayed during the entire authentication
-   conversation.  Exceptional circumstances such as expired passwords or
-   expired accounts may require that additional user interface be
-   displayed.  Mechanism designers needs to carefully consider the
-   design of their hints so that the client has this information.  This
-   way, clients can construct necessary dialogue boxes or wizards based
-   on the authentication set and can present a coherent user interface.
-   Current standards for user interface do not provide an acceptable
-   experience when the client has to ask additional questions later in
-   the conversation.
-
-   When indicating which sets of pre-authentication mechanisms are
-   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
-   for each pre-authentication mechanism set.
-
-   The client sends the padata-value for the first mechanism it picks in
-   the pre-authentication set, when the first mechanism completes, the
-   client and the KDC will proceed with the second mechanism, and so on
-   until all mechanisms complete successfully.  The PA-FX-COOKIE as
-   defined in Section 6.3 MUST be sent by the KDC so that the
-   conversation can continue if the conversation involves multiple KDCs.
-   The cookie may not be needed in the first message containing the PA-
-   AUTHENTICATION-SET sequence as the KDC may be able to reconstruct the
-   state from the PA-AUTHENTICATION-SET-SELECTED padata.  KDCs MUST
-   support clients that do not include a cookie because they
-   optimistically choose an authentication set, although they MAY always
-   return KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in
-   that message.  Clients that support PA-AUTHENTICATION-SET MUST
-   support PA-FX-COOKIE.
-
-   Before the authentication succeeds and a ticket is returned, the
-   message that the client sends is an AS_REQ and the message that the
-   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
-   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_NEEDED as defined
-   in Section 6.3 and the accompanying e-data contains the DER encoding
-   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
-   the METHOD-DATA.  If there is no padata, the e-data field is absent
-   in the KRB-ERROR message.
-
-   If the client sends the last message for a given mechanism, then the
-   KDC sends the first message for the next mechanism.  If the next
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 22]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   mechanism does not start with a KDC-side challenge, then the KDC
-   includes a padata item with the appropriate pa-type and an empty pa-
-   data.
-
-   If the KDC sends the last message for a particular mechanism, the KDC
-   also includes the first padata for the next mechanism.
-
-6.5.  Definition of Kerberos FAST Padata
-
-   As described in [RFC4120], Kerberos is vulnerable to offline
-   dictionary attacks.  An attacker can request an AS-REP and try
-   various passwords to see if they can decrypt the resulting ticket.
-   RFC 4120 provides the encrypted timestamp pre-authentication method
-   that ameliorates the situation somewhat by requiring that an attacker
-   observe a successful authentication.  However stronger security is
-   desired in many environments.  The Kerberos FAST pre-authentication
-   padata defined in this section provides a tool to significantly
-   reduce vulnerability to offline dictionary attack.  When combined
-   with encrypted challenge, FAST requires an attacker to mount a
-   successful man-in-the-middle attack to observe ciphertext.  When
-   combined with host keys, FAST can even protect against active
-   attacks.  FAST also provides solutions to common problems for pre-
-   authentication mechanisms such as binding of the request and the
-   reply, freshness guarantee of the authentication.  FAST itself,
-   however, does not authenticate the client or the KDC, instead, it
-   provides a typed hole to allow pre-authentication data be tunneled.
-   A pre-authentication data element used within FAST is called a FAST
-   factor.  A FAST factor captures the minimal work required for
-   extending Kerberos to support a new pre-authentication scheme.
-
-   A FAST factor MUST NOT be used outside of FAST unless its
-   specification explicitly allows so.  The typed holes in FAST messages
-   can also be used as generic holes for other padata that are not
-   intended to prove the client's identity, or establish the reply key.
-
-   New pre-authentication mechanisms SHOULD be designed as FAST factors,
-   instead of full-blown pre-authentication mechanisms.
-
-   FAST factors that are pre-authentication mechanisms MUST meet the
-   requirements in Section 5.
-
-   FAST employs an armoring scheme.  The armor can be a Ticket Granting
-   Ticket (TGT) obtained by the client's machine using the host keys to
-   pre-authenticate with the KDC, or an anonymous TGT obtained based on
-   anonymous PKINIT [KRB-ANON] [RFC4556].
-
-   The rest of this section describes the types of armors and the syntax
-   of the messages used by FAST.  Conforming implementations MUST
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 23]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   support Kerberos FAST padata.
-
-   Any FAST armor scheme MUST provide a fresh armor key for each
-   conversation.  Clients and KDCs can assume that if a message is
-   encrypted and integrity protected with a given armor key then it is
-   part of the conversation using that armor key.
-
-   All KDCs in a realm MUST support FAST if FAST is offered by any KDC
-   as a pre-authentication mechanism.
-
-6.5.1.  FAST Armors
-
-   An armor key is used to encrypt pre-authentication data in the FAST
-   request and the response.  The KrbFastArmor structure is defined to
-   identify the armor key.  This structure contains the following two
-   fields: the armor-type identifies the type of armors, and the armor-
-   value is an OCTET STRING that contains the description of the armor
-   scheme and the armor key.
-
-        KrbFastArmor ::= SEQUENCE {
-            armor-type   [0] Int32,
-                -- Type of the armor.
-            armor-value  [1] OCTET STRING,
-                -- Value of the armor.
-            ...
-        }
-
-   The value of the armor key is a matter of the armor type
-   specification.  Only one armor type is defined in this document.
-
-        FX_FAST_ARMOR_AP_REQUEST           1
-
-   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
-
-   Conforming implementations MUST implement the
-   FX_FAST_ARMOR_AP_REQUEST armor type.
-
-   FAST implementations MUST maintain state about whether the armor
-   mechanism authenticates the KDC.  If it does not, then a fast factor
-   that authenticates the KDC MUST be used if the reply key is replaced.
-
-6.5.1.1.  Ticket-based Armors
-
-   This is a ticket-based armoring scheme.  The armor-type is
-   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
-   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
-   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
-   The armor key is defined by the following function:
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 24]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-       armor_key = KRB-FX-CF2( subkey, ticket_session_key,
-                   "subkeyarmor", "ticketarmor" )
-
-   The `ticket_key' is the session key from the ticket in the ap-req.
-   The `subkey' is the ap-req subkey.  This construction guarantees that
-   both the KDC (through the session key) and the client (through the
-   subkey) contribute to the armor key.
-
-   The server name field of the armor ticket MUST identify the TGS of
-   the target realm.  Here are three common ways in the decreasing
-   preference order how an armor TGT SHOULD be obtained:
-
-   1.  If the client is authenticating from a host machine whose
-       Kerberos realm has an authentication path to the client's realm,
-       the host machine obtains a TGT by using the host keys.  If the
-       client's realm is different than the realm of the local host, the
-       machine then obtains a cross-realm TGT to the client's realm as
-       the armor ticket.  Otherwise, the host's primary TGT is the armor
-       ticket.
-
-   2.  If the client's host machine cannot obtain a host ticket strictly
-       based on RFC4120, but the KDC has an asymmetric signing key whose
-       binding with the expected KDC can be verified by the client, the
-       client can use anonymous PKINIT [KRB-ANON] [RFC4556] to
-       authenticate the KDC and obtain an anonymous TGT as the armor
-       ticket.  The armor ticket can also be a cross-realm TGT obtained
-       based on the initial primary TGT obtained using anonymous PKINIT
-       with KDC authentication.
-
-   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
-       TGT without KDC authentication and that TGT is the armor ticket.
-       Note that this mode of operation is vulnerable to man-in-the-
-       middle attacks at the time of obtaining the initial anonymous
-       armor TGT.
-
-   If anonymous PKINIT is used to obtain the armor ticket, the KDC
-   cannot know whether its signing key can be verified by the client,
-   hence the KDC MUST be marked as unverified from the KDC's point of
-   view while the client could be able to authenticate the KDC by
-   verifying the KDC's signing key is bound with the expected KDC.  The
-   client needs to carefully consider the risk and benefit tradeoffs
-   associated with active attacks before exposing cipher text encrypted
-   using the user's long-term secrets when the armor does not
-   authenticate the KDC.
-
-   The TGS MUST reject a request if there is an AD-fx-fast-armor (TBD)
-   element in the authenticator of the pa-tgs-req padata or if the
-   ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 25]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   armor authorization data element.  These tickets and authenticators
-   MAY be used as FAST armor tickets but not to obtain a ticket via the
-   TGS.  This authorization data is used in a system where the
-   encryption of the user's pre-authentication data is performed in an
-   unprivileged user process.  A privileged process can provide to the
-   user process a host ticket, an authenticator for use with that
-   ticket, and the sub session key contained in the authenticator.  In
-   order for the host process to ensure that the host ticket is not
-   accidentally or intentionally misused, (i.e. the user process might
-   use the host ticket to authenticate as the host), it MUST include a
-   critical authorization data element of the type AD-fx-fast-armor when
-   providing the authenticator or in the enc-authorization-data field of
-   the TGS request used to obtain the TGT.  The corresponding ad-data
-   field of the AD-fx-fast-armor element is empty.
-
-   As discussed previously, the server of an armor ticket MUST be the
-   TGS of the realm from whom service is requested.  As a result, if
-   this armor type is used when a ticket is being validated, proxied, or
-   in other cases where a ticket other than a TGT is presented to the
-   TGS, a TGT will be used as an armor ticket, while another ticket will
-   be used in the pa-tgs-req authenticator.
-
-6.5.2.  FAST Request
-
-   A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
-   authentication padata.  The corresponding padata-value field
-   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
-   REQUEST.  As with all pre-authentication types, the KDC SHOULD
-   advertise PA-FX-FAST with an empty pa-value in a PREAUTH_REQUIRED
-   error.  Clients MUST ignore the pa-value of PA-FX-FAST in an initial
-   PREAUTH_REQUIRED error.  FAST is not expected to be used in an
-   authentication set: clients will typically use FAST padata if
-   available and this decision should not depend on what other pre-
-   authentication methods are available.  As such, no pa-hint is defined
-   for FAST at this time.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 26]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-       PA-FX-FAST                         136
-           -- Padata type for Kerberos FAST
-
-       PA-FX-FAST-REQUEST ::= CHOICE {
-           armored-data [0] KrbFastArmoredReq,
-           ...
-       }
-
-       KrbFastArmoredReq ::= SEQUENCE {
-           armor        [0] KrbFastArmor OPTIONAL,
-               -- Contains the armor that identifies the armor key.
-               -- MUST be present in AS-REQ.
-           req-checksum [1] Checksum,
-               -- For AS, contains the checksum performed over the type
-               -- KDC-REQ-BODY for the req-body field of the KDC-REQ
-               -- structure;
-               -- For TGS, contains the checksum performed over the type
-               -- AP-REQ in the PA-TGS-REQ padata.
-               -- The checksum key is the armor key, the checksum
-               -- type is the required checksum type for the enctype of
-               -- the armor key, and the key usage number is
-               -- KEY_USAGE_FAST_REQ_CHKSUM.
-           enc-fast-req [2] EncryptedData, -- KrbFastReq --
-               -- The encryption key is the armor key, and the key usage
-               -- number is KEY_USAGE_FAST_ENC.
-           ...
-       }
-
-       KEY_USAGE_FAST_REQ_CHKSUM          50
-       KEY_USAGE_FAST_ENC                 51
-
-   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
-   The KrbFastArmoredReq encapsulates the encrypted padata.
-
-   The enc-fast-req field contains an encrypted KrbFastReq structure.
-   The armor key is used to encrypt the KrbFastReq structure, and the
-   key usage number for that encryption is KEY_USAGE_FAST_ENC.
-
-   The armor key is selected as follows:
-
-   o  In an AS request, the armor field in the KrbFastArmoredReq
-      structure MUST be present and the armor key is identified
-      according to the specification of the armor type.
-
-   o  There are two possibilities for armor for a TGS request.  If the
-      ticket presented in the PA-TGS-REQ authenticator is a TGT, then
-      the client SHOULD not include the armor field in the Krbfastreq
-      and a subkey MUST be included in the PA-TGS-REQ authenticator.  In
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 27]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-      this case, the armor key is the same armor key that would be
-      computed if the TGS-REQ authenticator was used in a
-      FX_FAST_ARMOR_AP_REQUEST armor.  If a ticket other than a TGT is
-      being presented to the TGS, a client SHOULD use some form of FAST
-      armor such as a ticket-based armor with a TGT as an armor ticket.
-      Clients MAY present a non-TGT in the PA-TGS-REQ authenticator and
-      omit the armor field, in which case the armor key is the same that
-      would be computed if the authenticator were used in a
-      FX_FAST_ARMOR_AP_REQUEST armor.  This is the only case where a
-      ticket other than a TGT can be used to establish an armor key;
-      even though the armor key is computed the same as a
-      FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used as an armor
-      ticket in FX_FAST_ARMOR_AP_REQUEST.
-
-   The req-checksum field contains a checksum computed differently for
-   AS and TGS.  For an AS-REQ, it is performed over the type KDC-REQ-
-   BODY for the req-body field of the KDC-REQ structure of the
-   containing message; for an TGS-REQ, it is performed over the type AP-
-   REQ in the PA-TGS-REQ padata of the TGS request.  The checksum key is
-   the armor key, and the checksum type is the required checksum type
-   for the enctype of the armor key per [RFC3961].  This checksum is
-   included in order to bind the FAST padata to the outer request.  A
-   KDC that implements FAST will ignore the outer request, but including
-   a checksum is relatively cheap and may prevent confusing behavior.
-
-   The KrbFastReq structure contains the following information:
-
-        KrbFastReq ::= SEQUENCE {
-            fast-options [0] FastOptions,
-                -- Additional options.
-            padata       [1] SEQUENCE OF PA-DATA,
-                -- padata typed holes.
-            req-body     [2] KDC-REQ-BODY,
-                -- Contains the KDC request body as defined in Section
-                -- 5.4.1 of [RFC4120].
-                -- This req-body field is preferred over the outer field
-                -- in the KDC request.
-             ...
-        }
-
-   The fast-options field indicates various options that are to modify
-   the behavior of the KDC.  The following options are defined:
-
-        FastOptions ::= KerberosFlags
-            -- reserved(0),
-            -- hide-client-names(1),
-            -- kdcfollow--referrals(16)
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 28]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-     Bits    Name                    Description
-    -----------------------------------------------------------------
-     0     RESERVED              Reserved for future expansion of this
-                                 field.
-     1     hide-client-names     Requesting the KDC to hide client
-                                 names in the KDC response, as
-                                 described next in this section.
-     16    kdc-follow-referrals  Requesting the KDC to follow referrals.
-
-   Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are
-   critical options.  If the KDC does not support a critical option, it
-   MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and
-   there is no accompanying e-data defined in this document for this
-   error code.  Bit 16 and onward (with bit 16 included) are non-
-   critical options.  KDCs conforming to this specification ignore
-   unknown non-critical options.
-
-        KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS       93
-
-   The hide-client-names Option
-
-      The Kerberos response defined in [RFC4120] contains the client
-      identity in clear text, This makes traffic analysis
-      straightforward.  The hide-client-names option is designed to
-      complicate traffic analysis.  If the hide-client-names option is
-      set, the KDC implementing PA-FX-FAST MUST identify the client as
-      the anonymous principal [KRB-ANON] in the KDC reply and the error
-      response.  Hence this option is set by the client if it wishes to
-      conceal the client identity in the KDC response.  A conforming KDC
-      ignores the client principal name in the outer KDC-REQ-BODY field,
-      and identifies the client using the cname and crealm fields in the
-      req-body field of the KrbFastReq structure.
-
-   The kdc-follow-referrals Option
-
-      The Kerberos client described in [RFC4120] has to request referral
-      TGTs along the authentication path in order to get a service
-      ticket for the target service.  The Kerberos client described in
-      the [REFERRALS] needs to contact the AS specified in the error
-      response in order to complete client referrals.  The kdc-follow-
-      referrals option is designed to minimize the number of messages
-      that need to be processed by the client.  This option is useful
-      when, for example, the client may contact the KDC via a satellite
-      link that has high network latency, or the client has limited
-      computational capabilities.  If the kdc-follow-referrals option is
-      set, the KDC MAY act as the client to follow TGS referrals
-      [REFERRALS], and return the service ticket to the named server
-      principal in the client request using the reply key expected by
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 29]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-      the client.  That is, rather than returning a referral, the KDC
-      follows that referral by contacting a remote KDC and processing
-      the referral.  The kdc-referrals option can be implemented when
-      the KDC knows the reply key.  The KDC can ignore kdc-referrals
-      option when it does not understand it or it does not allow this
-      option based on local policy.  The client SHOULD be capable of
-      processing the KDC responses when this option is not honored by
-      the KDC.  Clients SHOULD use TCP to contact a KDC if this option
-      is going to be used to avoid problems when the client's UDP
-      retransmit algorithm has timeouts insufficient to allow the KDC to
-      interact with remote KDCs.
-
-   The padata field contains a list of PA-DATA structures as described
-   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
-   FAST factors.  They can also be used as generic typed-holes to
-   contain data not intended for proving the client's identity or
-   establishing a reply key, but for protocol extensibility.  If the KDC
-   supports the PA-FX-FAST-REQUEST padata, unless otherwise specified,
-   the client MUST place any padata that is otherwise in the outer KDC
-   request body into this field.  In a TGS request, PA-TGS-REQ padata is
-   not included in this field and it is present in the outer KDC request
-   body.
-
-   The KDC-REQ-BODY in the FAST structure is used in preference to the
-   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-
-   REQ-BODY structure SHOULD be filled in for backwards compatibility
-   with KDCs that do not support FAST.  A conforming KDC ignores the
-   outer KDC-REQ-BODY field in the KDC request.  However pre-
-   authentication data methods such as [RFC4556] that include a checksum
-   of the KDC-REQ-BODY should checksum the outer KDC-REQ-BODY.  These
-   methods will already be bound to the inner body through the integrity
-   protection in the FAST request.
-
-6.5.3.  FAST Response
-
-   The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST
-   padata element in the KDC reply.  In the case of an error, the PA-FX-
-   FAST padata is included in the KDC responses according to
-   Section 6.5.4.
-
-   The corresponding padata-value field [RFC4120] for the PA-FX-FAST in
-   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
-   FAST-REPLY.
-
-
-
-
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 30]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-      PA-FX-FAST-REPLY ::= CHOICE {
-          armored-data [0] KrbFastArmoredRep,
-          ...
-      }
-
-      KrbFastArmoredRep ::= SEQUENCE {
-          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
-              -- The encryption key is the armor key in the request, and
-              -- the key usage number is KEY_USAGE_FAST_REP.
-          ...
-      }
-      KEY_USAGE_FAST_REP                 52
-
-   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
-   structure.  The KrbFastArmoredRep structure encapsulates the padata
-   in the KDC reply in the encrypted form.  The KrbFastResponse is
-   encrypted with the armor key used in the corresponding request, and
-   the key usage number is KEY_USAGE_FAST_REP.
-
-   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
-   KDC response MUST support a local policy that rejects the response.
-   Clients MAY also support policies that fall back to other mechanisms
-   or that do not use pre-authentication when FAST is unavailable.  It
-   is important to consider the potential downgrade attacks when
-   deploying such a policy.
-
-   The KrbFastResponse structure contains the following information:
-
-        KrbFastResponse ::= SEQUENCE {
-            padata      [0] SEQUENCE OF PA-DATA,
-                -- padata typed holes.
-            rep-key     [1] EncryptionKey OPTIONAL,
-                -- This, if present, replaces the reply key for AS and
-                -- TGS.
-                -- MUST be absent in KRB-ERROR.
-            finished    [2] KrbFastFinished OPTIONAL,
-                -- Present in AS or TGS reply; absent otherwise.
-            ...
-        }
-
-   The padata field in the KrbFastResponse structure contains a list of
-   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
-   PA-DATA structures are used to carry data advancing the exchange
-   specific for the FAST factors.  They can also be used as generic
-   typed-holes for protocol extensibility.  Unless otherwise specified,
-   the KDC MUST include any padata that is otherwise in the outer KDC-
-   REP structure into this field.  The padata field in the KDC reply
-   structure outside of the PA-FX-FAST-REPLY structure typically
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 31]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   includes only the PA-FX- FAST-REPLY padata and optionally the PA-FX-
-   COOKIE padata.
-
-   The rep-key field, if present, contains the reply key that is used to
-   encrypted the KDC reply.  The rep-key field MUST be absent in the
-   case where an error occurs.  The enctype of the rep-key is the
-   strongest mutually supported by the KDC and the client.
-
-   The finished field contains a KrbFastFinished structure.  It is
-   filled by the KDC in the final message in the conversation.  This
-   field is present in an AS-REP or a TGS-REP when a ticket is returned,
-   and it is not present in an error reply.
-
-   The KrbFastFinished structure contains the following information:
-
-      KrbFastFinished ::= SEQUENCE {
-          timestamp   [0] KerberosTime,
-          usec        [1] Microseconds,
-              -- timestamp and usec represent the time on the KDC when
-              -- the reply was generated.
-          crealm      [2] Realm,
-          cname       [3] PrincipalName,
-              -- Contains the client realm and the client name.
-          checksum    [4] Checksum,
-              -- Checksum performed over all the messages in the
-              -- conversation, except the containing message.
-              -- The checksum key is the armor key as defined in
-              -- Section 6.5.1, and the checksum type is the required
-              -- checksum type of the armor key.
-          ticket-checksum [5] Checksum,
-              -- checksum  of the ticket in the KDC-REP  using the armor
-              -- and the key usage is KEY_USAGE_FAST_FINISH.
-              -- The checksum type is the required checksum type
-              -- of the armor key.
-          ...
-      }
-      KEY_USAGE_FAST_FINISHED            53
-
-   The timestamp and usec fields represent the time on the KDC when the
-   reply ticket was generated, these fields have the same semantics as
-   the corresponding-identically-named fields in Section 5.6.1 of
-   [RFC4120].  The client MUST use the KDC's time in these fields
-   thereafter when using the returned ticket.  Note that the KDC's time
-   in AS-REP may not match the authtime in the reply ticket if the kdc-
-   follow-referrals option is requested and honored by the KDC.  The
-   client need not confirm that the timestamp returned is within
-   allowable clock skew: the armor key guarantees that the reply is
-   fresh.  The client MAY trust the time stamp returned.
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 32]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   The cname and crealm fields identify the authenticated client.  If
-   facilities described in [REFERRALS] are used, the authenticated
-   client may differ from the client in the FAST request.
-
-   The checksum field contains a checksum of all the messages in the
-   conversation prior to the containing message (the containing message
-   is excluded).  The checksum key is the armor key, and the checksum
-   type is the required checksum type of the enctype of that key, and
-   the key usage number is KEY_USAGE_FAST_FINISHED.  The ticket-checksum
-   is a checksum of the issued ticket using the same key and key usage.
-
-   When FAST padata is included, the PA-FX-COOKIE padata as defined in
-   Section 6.3 MUST also be included if the KDC expects at least one
-   more message from the client in order to complete the authentication.
-
-6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
-
-   If the Kerberos FAST padata was included in the request, unless
-   otherwise specified, the e-data field of the KRB-ERROR message
-   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
-   [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA.  The KDC
-   MUST include all the padata elements such as PA-ETYPE-INFO2 and
-   padata elements that indicate acceptable pre-authentication
-   mechanisms [RFC4120] in the KrbFastResponse structure.
-
-   The KDC MUST also include a PA-FX-ERROR padata item in the
-   KRBFastResponse structure.  The padata-value element of this sequence
-   is the ASN.1 DER encoding of the type KRB-ERROR.  The e-data field
-   MUST be absent in the PA-FX-ERROR padata.  All other fields should be
-   the same as the outer KRB-ERROR.  The client ignores the outer error
-   and uses the combination of the padata in the KRBFastResponse and the
-   error information in the PA-FX-ERROR.
-
-              PA-FX-ERROR                        137
-
-   If the Kerberos FAST padata is included in the request but not
-   included in the error reply, it is a matter of the local policy on
-   the client to accept the information in the error message without
-   integrity protection.  The Kerberos client MAY process an error
-   message without a PA-FX-FAST-REPLY, if that is only intended to
-   return better error information to the application, typically for
-   trouble-shooting purposes.
-
-   In the cases where the e-data field of the KRB-ERROR message is
-   expected to carry a TYPED-DATA [RFC4120] element, then that
-   information should be transmitted in a pa-data element within the
-   KRBFastResponse structure.  The padata-type is the same as the data-
-   type would be in the typed data element and the padata-value is the
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 33]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   same as the data-value.  As discussed in Section 8, data-types and
-   padata-types are drawn from the same namespace.  For example, the
-   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
-   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
-   [RFC4556].
-
-6.5.5.  Outer and Inner Requests
-
-   Typically, a client will know that FAST is being used before a
-   request containing PA-FX-FAST is sent.  So, the outer AS request
-   typically only includes two pa-data items: PA-FX-FAST and PA-FX-
-   COOKIE.  The client MAY include additional pa-data, but the KDC MUST
-   ignore the outer request body and any padata besides PA-FX-FAST and
-   PA-FX-COOKIE if PA-FX-FAST is processed.  In the case of the TGS
-   request, the outer request should include PA-FX-FAST and PA-TGS-REQ.
-
-   When an AS generates a response, all padata besides PA-FX-FAST and
-   PA-FX-COOKIE should be included in PA-FX-FAST.  The client MUST
-   ignore other padata outside of PA-FX-FAST.
-
-6.5.6.  The Encrypted Challenge FAST Factor
-
-   The encrypted challenge FAST factor authenticates a client using the
-   client's long-term key.  This factor works similarly to the encrypted
-   time stamp pre-authentication option described in [RFC4120].  The
-   client encrypts a structure containing a timestamp in the challenge
-   key.  The challenge key used by the client to send a message to the
-   KDC is KRB-FX-CF2(armor_key,long_term_key, "clientchallengearmor",
-   "challengelongterm").  The challenge key used by the KDC encrypting
-   to the client is KRB-FX-CF2(armor_key, long_term_key,
-   "kdcchallengearmor", "challengelongterm").  Because the armor key is
-   fresh and random, the challenge key is fresh and random.  The only
-   purpose of the timestamp is to limit the validity of the
-   authentication so that a request cannot be replayed.  A client MAY
-   base the timestamp on the KDC time in a KDC error and need not
-   maintain accurate time synchronization itself.  If a client bases its
-   time on an untrusted source, an attacker may trick the client into
-   producing an authentication request that is valid at some future
-   time.  The attacker may be able to use this authentication request to
-   make it appear that a client has authenticated at that future time.
-   If ticket-based armor is used, then the lifetime of the ticket will
-   limit the window in which an attacker can make the client appear to
-   have authenticated.  For many situations, the ability of an attacker
-   to cause a client to appear to have authenticated is not a
-   significant concern; the ability to avoid requiring time
-   synchronization on clients is more valuable.
-
-   The client sends a padata of type PA-ENCRYPTED-CHALLENGE the
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 34]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   corresponding padata-value contains the DER encoding of ASN.1 type
-   EncryptedChallenge.
-
-      EncryptedChallenge ::= EncryptedData
-              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
-
-      PA-ENCRYPTED-CHALLENGE          138
-      KEY_USAGE_ENC_CHALLENGE_CLIENT  54
-      KEY_USAGE_ENC_CHALLENGE_KDC     55
-
-   The client includes some time stamp reasonably close to the KDC's
-   current time and encrypts it in the challenge key.  Clients MAY use
-   the current time; doing so prevents the exposure where an attacker
-   can cause a client to appear to authenticate in the future.  The
-   client sends the request including this factor.
-
-   On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE fast
-   factor, the KDC decrypts the timestamp.  If the decryption fails the
-   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in
-   the KRBFastResponse in the error.  The KDC confirms that the
-   timestamp falls within its current clock skew returning
-   KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see if the
-   encrypted challenge is a replay.  The KDC MUST NOT consider two
-   encrypted challenges replays simply because the time stamps are the
-   same; to be a replay, the ciphertext MUST be identical.  Allowing
-   clients to re-use time stamps avoids requiring that clients maintain
-   state about which time stamps have been used.
-
-   If the KDC accepts the encrypted challenge, it MUST include a padata
-   element of type PA-ENCRYPTED-CHALLENGE.  The KDC encrypts its current
-   time in the challenge key.  The KDC MUST replace the reply key before
-   issuing a ticket.  The client MUST check that the timestamp decrypts
-   properly.  The client MAY check that the timestamp is winthin the
-   window of acceptable clock skew for the client.  The client MUST NOT
-   require that the timestamp be identical to the timestamp in the
-   issued credentials or the returned message.
-
-   The encrypted challenge FAST factor provides the following
-   facilities: client-authentication and KDC authentication.  This FAST
-   factor also takes advantage of the FAST facility to replace the reply
-   key.  It does not provide the strengthening-reply-key facility.  The
-   security considerations section of this document provides an
-   explanation why the security requirements are met.
-
-   The encrypted challenge FAST factor can be useful in an
-   authentication set.  No pa-hint is defined because the only
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 35]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   information needed by this mechanism is information contained in the
-   PA-ETYPE-INFO2 pre-authentication data.  KDCs are already required to
-   send PA-ETYPE-INFO2.  If KDCs were not required to send PA-ETYPE-
-   INFO2 then that information would need to be part of a hint for
-   encrypted challenge.
-
-   Conforming implementations MUST support the encrypted challenge FAST
-   factor.
-
-6.6.  Authentication Strength Indication
-
-   Implementations that have pre-authentication mechanisms offering
-   significantly different strengths of client authentication MAY choose
-   to keep track of the strength of the authentication used as an input
-   into policy decisions.  For example, some principals might require
-   strong pre-authentication, while less sensitive principals can use
-   relatively weak forms of pre-authentication like encrypted timestamp.
-
-   An AuthorizationData data type AD-Authentication-Strength is defined
-   for this purpose.
-
-        AD-authentication-strength         70
-
-   The corresponding ad-data field contains the DER encoding of the pre-
-   authentication data set as defined in Section 6.4.  This set contains
-   all the pre-authentication mechanisms that were used to authenticate
-   the client.  If only one pre-authentication mechanism was used to
-   authenticate the client, the pre-authentication set contains one
-   element.
-
-   The AD-authentication-strength element MUST be included in the AD-IF-
-   RELEVANT, thus it can be ignored if it is unknown to the receiver.
-
-
-7.  Assigned Constants
-
-   The pre-authentication framework and FAST involve using a number of
-   Kerberos protocol constants.  This section lists protocol constants
-   first introduced in this specification drawn from registries not
-   managed by IANA.  Many of these registries would best be managed by
-   IANA; that is a known issue that is out of scope for this document.
-   The constants described in this section have been accounted for and
-   will appear in the next revision of the Kerberos core specification
-   or in a document creating IANA registries.
-
-   Section 8 creates IANA registries for a different set of constants
-   used by the extensions described in this document.
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 36]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-7.1.  New Errors
-
-           KDC_ERR_PREAUTH_EXPIRED                 90
-           KDC_ERR_MORE_PREAUTH_DATA_NEEDED        91
-           KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET  92
-           KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS            93
-
-7.2.  Key Usage Numbers
-
-           KEY_USAGE_FAST_REQ_CHKSUM               50
-           KEY_USAGE_FAST_ENC                      51
-           KEY_USAGE_FAST_REP                      52
-           KEY_USAGE_FAST_FINISHED                 53
-           KEY_USAGE_ENC_CHALLENGE_CLIENT          54
-           KEY_USAGE_ENC_CHALLENGE_KDC             55
-
-7.3.  Authorization Data Elements
-
-           AD-authentication-strength              70
-           AD-fx-fast-armor                        71
-
-7.4.  New PA-DATA Types
-
-           PA-FX-COOKIE                            133
-           PA-AUTHENTICATION-SET                   134
-           PA-AUTH-SET-SELECTED                    135
-           PA-FX-FAST                              136
-           PA-FX-ERROR                             137
-           PA-ENCRYPTED-CHALLENGE                  138
-
-
-8.  IANA Considerations
-
-   This document creates a number of IANA registries.  These registries
-   should all be located under
-   http://www.iana.org/assignments/kerberos-parameters.
-
-8.1.  Pre-authentication and Typed Data
-
-   RFC 4120 defines pre-authentication data, which can be included in a
-   KDC request or response in order to authenticate the client or extend
-   the protocol.  In addition, it defines Typed-Data which is an
-   extension mechanism for errors.  Both pre-authentication data and
-   typed data are carried as a 32-bit signed integer along with an octet
-   string.  The encoding of typed data and pre-authentication data is
-   slightly different.  However the types for pre-authentication data
-   and typed-data are drawn from the same namespace.  By convention,
-   registrations starting with TD- are typed data and registration
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 37]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   starting with PA- are pre-authentication data.  It is important that
-   these data types be drawn from the same namespace, because some
-   errors where it would be desirable to include typed data require the
-   e-data field to be formatted as pre-authentication data.
-
-   When Kerberos FAST is used, pre-authentication data encoding is
-   always used.
-
-   There is one apparently conflicting registration between typed data
-   and pre-authentication data.  PA-GET-FROM-TYPED-DATA and TD-PADATA
-   are both assigned the value 22.  However this registration is simply
-   a mechanism to include an element of the other encoding.  The use of
-   both should be deprecated.
-
-   This document creates a registry for pre-authentication and typed
-   data.  The registration procedures are as follows.  Expert review for
-   pre-authentication mechanisms designed to authenticate users, KDCs,
-   or establish the reply key.  The expert first determines that the
-   purpose of the method is to authenticate clients, KDCs, or to
-   establish the reply key.  If so, expert review is appropriate.  The
-   expert evaluates the security and interoperability of the
-   specification.
-
-   IETF review is required if the expert believes that the pre-
-   authentication method is broader than these three areas.  Pre-
-   authentication methods that change the Kerberos state machine or
-   otherwise make significant changes to the Kerberos protocol should be
-   standards track RFCs.  A concern that a particular method needs to be
-   a standards track RFC may be raised as an objection during IETF
-   review.
-
-      Type                Value    Reference
-  ----------------------------------------------------------------------
-  PA-TGS-REQ                 1    RFC 4120
-  PA-ENC-TIMESTAMP           2    RFC 4120
-  PA-PW-SALT                 3    RFC 4120
-  [reserved]                 4
-  PA-ENC-UNIX-TIME           5    (deprecated)
-  PA-SANDIA-SECUREID         6
-  PA-SESAME                  7
-  PA-OSF-DCE                 8
-  PA-CYBERSAFE-SECUREID      9
-  PA-AFS3-SALT               10
-  PA-ETYPE-INFO              11   RFC 4120
-  PA-SAM-CHALLENGE           12   (sam/otp)
-  PA-SAM-RESPONSE            13   (sam/otp)
-  PA-PK-AS-REQ_OLD           14   draft-ietf-cat-kerberos-pk-init-09
-  PA-PK-AS-REP_OLD           15   draft-ietf-cat-kerberos-pk-init-09
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 38]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-  PA-PK-AS-REQ               16   RFC 4556
-  PA-PK-AS-REP               17   RFC 4556
-  PA-ETYPE-INFO2             19   RFC 4120
-  PA-USE-SPECIFIED-KVNO      20
-  PA-SAM-REDIRECT            21   (sam/otp)
-  PA-GET-FROM-TYPED-DATA     22   (embedded in typed data)
-  TD-PADATA                  22   (embeds padata)
-  PA-SAM-ETYPE-INFO          23   (sam/otp)
-  PA-ALT-PRINC               24   (crawdad@fnal.gov)
-  PA-SAM-CHALLENGE2          30   (kenh@pobox.com)
-  PA-SAM-RESPONSE2           31   (kenh@pobox.com)
-  PA-EXTRA-TGT               41   Reserved extra TGT
-  TD-PKINIT-CMS-CERTIFICATES 101  CertificateSet from CMS
-  TD-KRB-PRINCIPAL           102  PrincipalName
-  TD-KRB-REALM               103  Realm
-  TD-TRUSTED-CERTIFIERS      104  PKINIT
-  TD-CERTIFICATE-INDEX       105  PKINIT
-  TD-APP-DEFINED-ERROR       106  Application specific
-  TD-REQ-NONCE               107  INTEGER
-  TD-REQ-SEQ                 108  INTEGER
-  PA-PAC-REQUEST             128  MS-KILE
-  PA-FOR_USER                129  MS-KILE
-  PA-FOR-X509-USER           130  MS-KILE
-  PA-FOR-CHECK_DUPS          131  MS-KILE
-  PA-AS-CHECKSUM             132  MS-KILE
-  PA-FX-COOKIE               133  draft-ietf-krb-wg-preauth-framework
-  PA-AUTHENTICATION-SET      134  draft-ietf-krb-wg-preauth-framework
-  PA-AUTH-SET-SELECTED       135  draft-ietf-krb-wg-preauth-framework
-  PA-FX-FAST                 136  draft-ietf-krb-wg-preauth-framework
-  PA-FX-ERROR                137  draft-ietf-krb-wg-preauth-framework
-  PA-ENCRYPTED-CHALLENGE     138  draft-ietf-krb-wg-preauth-framework
-  PA-OTP-CHALLENGE           141  (gareth.richards@rsa.com)
-  PA-OTP-REQUEST             142  (gareth.richards@rsa.com)
-  PA-OTP-CONFIRM             143  (gareth.richards@rsa.com)
-  PA-SUPPORTED-ETYPES        165  MS-KILE
-
-8.2.  Fast Armor Types
-
-   FAST armor types are defined in Section 6.5.1.  A FAST armor type is
-   a signed 32-bit integer.  FAST armor types are assigned by standards
-   action.
-
-          Type    Name                   Description
-        ------------------------------------------------------------
-          0                              Reserved.
-          1   FX_FAST_ARMOR_AP_REQUEST   Ticket armor using an ap-req.
-
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 39]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-8.3.  FAST Options
-
-   A FAST request includes a set of bit flags to indicate additional
-   options.  Bits 0-15 are critical; other bits are non-critical.
-   Assigning bits greater than 31 may require special support in
-   implementations.  Assignment of FAST options requires standards
-   action.
-
-      Type    Name                   Description
-     -------------------------------------------------------------------
-      0     RESERVED               Reserved for future expansion of this
-                                   field.
-      1     hide-client-names      Requesting the KDC to hide client
-                                   names in  the KDC response
-      16    kdc-follow-referrals   Requesting the KDC to follow
-                                   referrals
-
-
-9.  Security Considerations
-
-   The kdc-referrals option in the Kerberos FAST padata requests the KDC
-   to act as the client to follow referrals.  This can overload the KDC.
-   To limit the damages of denied of service using this option, KDCs MAY
-   restrict the number of simultaneous active requests with this option
-   for any given client principal.
-
-   With regarding to the facilities provided by the Encrypted Challenge
-   FAST factor, the challenge key is derived from the client secrets and
-   because the client secrets are known only to the client and the KDC,
-   the verification of the EncryptedChallenge structure proves the
-   client's identity, the verification of the EncryptedChallenge
-   structure in the KDC reply proves that the expected KDC responded.
-   Therefore, the Encrypted Challenge FAST factor as a pre-
-   authentication mechanism offers the following facilities: client-
-   authentication and KDC-authentication.  There is no un-authenticated
-   clear text introduced by the Encrypted Challenge FAST factor.
-
-
-10.  Acknowledgements
-
-   Sam Hartman would like to thank the MIT Kerberos Consortium for its
-   funding of his time on this project.
-
-   Several suggestions from Jeffrey Hutzelman based on early revisions
-   of this documents led to significant improvements of this document.
-
-   The proposal to ask one KDC to chase down the referrals and return
-   the final ticket is based on requirements in [ID.CROSS].
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 40]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   Joel Webber had a proposal for a mechanism similar to FAST that
-   created a protected tunnel for Kerberos pre-authentication.
-
-
-11.  References
-
-11.1.  Normative References
-
-   [KRB-ANON]
-              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
-              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-11.2.  Informative References
-
-   [ID.CROSS]
-              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
-              Statement on the Operation of Kerberos in a Specific
-              System", draft-sakane-krb-cross-problem-statement-02.txt
-              (work in progress), April 2007.
-
-   [KRB-WG.SAM]
-              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
-              "Integrating Single-use Authentication Mechanisms with
-              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
-              progress), October 2003.
-
-   [REFERRALS]
-              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
-              Locate Kerberos Realms",
-              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
-              progress), 2007.
-
-
-
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 41]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-Appendix A.  Change History
-
-   RFC editor, please remove this section before publication.
-
-A.1.  Changes since 09
-
-      Clarify conversations by defining for TGS and by describing how
-      cookies form conversation boundaries.
-      Simplify text surrounding when finish is included: always for AS
-      and TGS reply, never for error.
-      Fill in IANA and constants
-
-A.2.  Changes since 08
-
-      Fix a number of typos
-      Rename anonymous flag to hide-client-name; rename kdc-referals to
-      kdc-follow-referrals
-      Clarify how anonymous pkinit interacts with KDC verified.
-      Introduce AD-fx-fast-armor authorization data to deal with
-      unprivileged processes constructing KDC requests.  Note that a TGT
-      is always used for armor tickets if the armor field is present; if
-      you proxy or validate you'll end up with a TGT armor ticket and
-      another ticket in the pa-tgs-req.  Alternatively you can simply
-      use the other ticket in the PA-TGS-REQ; weak consensus within WG.
-      All KDCs in a realm MUST support FAST if it is to be offered.
-      The cookie message is always generated by the KDC.
-      Note that the client can trust and need not verify the time stamp
-      in the finish message.  This can seed the client's idea of KDC
-      time.
-      Note that the client name in the finish message may differ from
-      the name in the request if referrals are used.
-      Note that KDCs should advertize fast in preauth_required errors.
-      Armor key is constructed using KRB-FX-CF2.  This is true even in
-      the TGS case; there is no security reason to do this.  Using the
-      subkey as done in draft 08 would be fine, but the current text
-      uses the same procedure both in the TGS and AS case.
-      Use a different challenge key in each direction in the encrypted
-      challenge option.
-      Note that the KDC should process PA-FX-COOKIE before other padata.
-      KRB-FX-CF2 uses k1's enctype for the result; change around calling
-      order so we pass in subkeys and armor keys as k1 in preference to
-      long-term keys or ticket session keys.
-      Clarify the relationship between authentication sets and cookies.
-      A cookie may not be needed in the first message.  Clarify how this
-      interacts with optimistic clients.
-      Remove text raising a concern that RFC 3961 may permit ciphertext
-      transformations that do not change plaintext: discussion on the
-      list came to the conclusion that RFC 3961 does not permit this.
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 42]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-      Remove binding key concept; use the armor key instead.  The cookie
-      becomes just an octet string.
-      Include PA-FX-ERROR to protect the error information per Dublin.
-      Returning preauth_failed in the failed to decrypt encrypted
-      challenge seems fine; remove the issue marker
-      Add a section describing what goes in the inner and outer request.
-      I believe it is redundant but found it useful while putting
-      together an implementation proposal.
-      Use hyphen rather than underscore in the constants for pre-
-      authentication data to be consistent with RFC 4120.
-      Add a ticket-checksum to the finished message
-      Remove redundant KEY_USAGE_FAST_ARMOR.
-      Add protocol constants section for non-IANA registrations and
-      flesh out IANA section.
-      Clarify that kdc-req-body checksums should always use the outer
-      body even for mechanisms like PKINIT that include their own (now
-      redundant) checksum.
-      Remove mechanism for encapsulating typed data in padata; just
-      reflect the value.
-
-A.3.  Changes since 07
-
-      Propose replacement of authenticated timestamp with encrypted
-      challenge.  The desire to avoid clients needing time
-      synchronization and to simply the factor.
-      Add a requirement that any FAST armor scheme must provide a fresh
-      key for each conversation.  This allows us to assume that anything
-      encrypted/integrity protected in the right key is fresh and not
-      subject to cross-conversation cut and paste.
-      Removed heartbeat padata.  The KDC will double up messages if it
-      needs to; the client simply sends its message and waits for the
-      next response.
-      Define PA-AUTH-SET-SELECTED
-      Clarify a KDC cannot ignore padata is has claimed to support
-
-A.4.  Changes since 06
-
-      Note that even for replace reply key it is likely that the side
-      using the mechanism will know that the other side supports it.
-      Since it is reasonably unlikely we'll need a container mechanism
-      other than FAST itself, we don't need to optimize for that case.
-      So, we want to optimize for implementation simplicity.  Thus if
-      you do have such a container mechanism interacting with
-      authentication sets we'll assume that the hint need to describe
-      hints for all contained mechanisms.  This closes out a long-
-      standing issue.
-
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 43]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-      Write up what Sam believes is the consensus on UI and prompts in
-      the authentication set: clients MAY assume that they have all the
-      UI information they need.
-
-
-Appendix B.  ASN.1 module
-
-      KerberosPreauthFramework {
-            iso(1) identified-organization(3) dod(6) internet(1)
-            security(5) kerberosV5(2) modules(4) preauth-framework(3)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      IMPORTS
-           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
-           Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
-           Microseconds, KerberosFlags
-                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                  dod(6) internet(1) security(5) kerberosV5(2)
-                  modules(4) krb5spec2(2) };
-                  -- as defined in RFC 4120.
-
-
-      PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-      PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-          pa-type      [0] Int32,
-              -- same as padata-type.
-          pa-hint      [1] OCTET STRING OPTIONAL,
-          pa-value  [2] OCTET STRING OPTIONAL,
-          ...
-      }
-
-      KrbFastArmor ::= SEQUENCE {
-          armor-type   [0] Int32,
-              -- Type of the armor.
-          armor-value  [1] OCTET STRING,
-              -- Value of the armor.
-          ...
-      }
-
-      PA-FX-FAST-REQUEST ::= CHOICE {
-          armored-data [0] KrbFastArmoredReq,
-          ...
-      }
-
-      KrbFastArmoredReq ::= SEQUENCE {
-          armor        [0] KrbFastArmor OPTIONAL,
-              -- Contains the armor that identifies the armor key.
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 44]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-              -- MUST be present in AS-REQ.
-          req-checksum [1] Checksum,
-              -- For AS, contains the checksum performed over the type
-              -- KDC-REQ-BODY for the req-body field of the KDC-REQ
-              -- structure;
-              -- For TGS, contains the checksum performed over the type
-              -- AP-REQ in the PA-TGS-REQ padata.
-              -- The checksum key is the armor key, the checksum
-              -- type is the required checksum type for the enctype of
-              -- the armor key, and the key usage number is
-              -- KEY_USAGE_FAST_REQ_CHKSUM.
-          enc-fast-req [2] EncryptedData, -- KrbFastReq --
-              -- The encryption key is the armor key, and the key usage
-              -- number is KEY_USAGE_FAST_ENC.
-          ...
-      }
-
-      KrbFastReq ::= SEQUENCE {
-          fast-options [0] FastOptions,
-              -- Additional options.
-          padata       [1] SEQUENCE OF PA-DATA,
-              -- padata typed holes.
-          req-body     [2] KDC-REQ-BODY,
-              -- Contains the KDC request body as defined in Section
-              -- 5.4.1 of [RFC4120].
-              -- This req-body field is preferred over the outer field
-              -- in the KDC request.
-           ...
-      }
-
-      FastOptions ::= KerberosFlags
-          -- reserved(0),
-          -- anonymous(1),
-          -- kdc-referrals(16)
-
-      PA-FX-FAST-REPLY ::= CHOICE {
-          armored-data [0] KrbFastArmoredRep,
-          ...
-      }
-
-      KrbFastArmoredRep ::= SEQUENCE {
-          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
-              -- The encryption key is the armor key in the request, and
-              -- the key usage number is KEY_USAGE_FAST_REP.
-          ...
-      }
-
-      KrbFastResponse ::= SEQUENCE {
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 45]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-          padata      [0] SEQUENCE OF PA-DATA,
-              -- padata typed holes.
-          rep-key     [1] EncryptionKey OPTIONAL,
-              -- This, if present, replaces the reply key for AS and
-              -- TGS.
-              -- MUST be absent in KRB-ERROR.
-          finished    [2] KrbFastFinished OPTIONAL,
-              -- Present in AS or TGS reply; absent otherwise.
-          ...
-      }
-
-      KrbFastFinished ::= SEQUENCE {
-          timestamp   [0] KerberosTime,
-          usec        [1] Microseconds,
-              -- timestamp and usec represent the time on the KDC when
-              -- the reply was generated.
-          crealm      [2] Realm,
-          cname       [3] PrincipalName,
-              -- Contains the client realm and the client name.
-          checksum    [4] Checksum,
-              -- Checksum performed over all the messages in the
-              -- conversation, except the containing message.
-              -- The checksum key is the armor key as defined in
-              -- Section 6.5.1, and the checksum type is the required
-              -- checksum type of the armor key.
-          ticket-checksum [5] Checksum,
-              -- checksum  of the ticket in the KDC-REP  using the armor
-              -- and the key usage is KEY_USAGE_FAST_FINISH.
-              -- The checksum type is the required checksum type
-              -- of the armor key.
-          ...
-      }
-
-      EncryptedChallenge ::= EncryptedData
-              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
-      END
-
-
-Authors' Addresses
-
-   Sam hartman
-   Painless Security
-
-   Email: hartmans-ietf@mit.edu
-
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 46]
-
-Internet-Draft         Kerberos Preauth Framework             March 2009
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu          Expires September 10, 2009              [Page 47]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-11.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-11.txt
deleted file mode 100644
index e314f231c..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-11.txt
+++ /dev/null
@@ -1,2689 +0,0 @@
-
-
-
-Kerberos Working Group                                        S. Hartman
-Internet-Draft                                         Painless Security
-Updates: 4120 (if approved)                                       L. Zhu
-Intended status: Standards Track                   Microsoft Corporation
-Expires: November 21, 2009                                  May 20, 2009
-
-
-        A Generalized Framework for Kerberos Pre-Authentication
-                 draft-ietf-krb-wg-preauth-framework-11
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on November 21, 2009.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   Kerberos is a protocol for verifying the identity of principals
-   (e.g., a workstation user or a network server) on an open network.
-
-
-
-Hartman & Zhu           Expires November 21, 2009               [Page 1]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   The Kerberos protocol provides a mechanism called pre-authentication
-   for proving the identity of a principal and for better protecting the
-   long-term secrets of the principal.
-
-   This document describes a model for Kerberos pre-authentication
-   mechanisms.  The model describes what state in the Kerberos request a
-   pre-authentication mechanism is likely to change.  It also describes
-   how multiple pre-authentication mechanisms used in the same request
-   will interact.
-
-   This document also provides common tools needed by multiple pre-
-   authentication mechanisms.  One of these tools is a secure channel
-   between the client and the KDC with a reply key delivery mechanism;
-   this secure channel can be used to protect the authentication
-   exchange thus eliminate offline dictionary attacks.  With these
-   tools, it is relatively straightforward to chain multiple
-   authentication mechanisms, utilize a different key management system,
-   or support a new key agreement algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires November 21, 2009               [Page 2]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Conventions and Terminology Used in This Document  . . . . . .  6
-   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  6
-     3.1.  Information Managed by the Pre-authentication Model  . . .  7
-     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  9
-     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . . 10
-     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 11
-   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 12
-     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 13
-     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 14
-     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 15
-     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 15
-   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 15
-   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 16
-     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 17
-     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 18
-     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 19
-     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 20
-     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 23
-       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 24
-       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 26
-       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 30
-       6.5.4.  Authenticated Kerberos Error Messages using
-               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 33
-       6.5.5.  Outer and Inner Requests . . . . . . . . . . . . . . . 34
-       6.5.6.  The Encrypted Challenge FAST Factor  . . . . . . . . . 34
-     6.6.  Authentication Strength Indication . . . . . . . . . . . . 36
-   7.  Assigned Constants . . . . . . . . . . . . . . . . . . . . . . 37
-     7.1.  New Errors . . . . . . . . . . . . . . . . . . . . . . . . 37
-     7.2.  Key Usage Numbers  . . . . . . . . . . . . . . . . . . . . 37
-     7.3.  Authorization Data Elements  . . . . . . . . . . . . . . . 37
-     7.4.  New PA-DATA Types  . . . . . . . . . . . . . . . . . . . . 37
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
-     8.1.  Pre-authentication and Typed Data  . . . . . . . . . . . . 38
-     8.2.  Fast Armor Types . . . . . . . . . . . . . . . . . . . . . 40
-     8.3.  FAST Options . . . . . . . . . . . . . . . . . . . . . . . 40
-   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 40
-   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 41
-     11.2. Informative References . . . . . . . . . . . . . . . . . . 42
-   Appendix A.  Test Vectors for KRB-FX-CF2 . . . . . . . . . . . . . 42
-   Appendix B.  Change History  . . . . . . . . . . . . . . . . . . . 43
-     B.1.  Changes since 10 . . . . . . . . . . . . . . . . . . . . . 43
-     B.2.  Changes since 09 . . . . . . . . . . . . . . . . . . . . . 43
-     B.3.  Changes since 08 . . . . . . . . . . . . . . . . . . . . . 43
-
-
-
-Hartman & Zhu           Expires November 21, 2009               [Page 3]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-     B.4.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 45
-     B.5.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 45
-   Appendix C.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 45
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires November 21, 2009               [Page 4]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-1.  Introduction
-
-   The core Kerberos specification [RFC4120] treats pre-authentication
-   data as an opaque typed hole in the messages to the KDC that may
-   influence the reply key used to encrypt the KDC reply.  This
-   generality has been useful: pre-authentication data is used for a
-   variety of extensions to the protocol, many outside the expectations
-   of the initial designers.  However, this generality makes designing
-   more common types of pre-authentication mechanisms difficult.  Each
-   mechanism needs to specify how it interacts with other mechanisms.
-   Also, problems like combining a key with the long-term secrets or
-   proving the identity of the user are common to multiple mechanisms.
-   Where there are generally well-accepted solutions to these problems,
-   it is desirable to standardize one of these solutions so mechanisms
-   can avoid duplication of work.  In other cases, a modular approach to
-   these problems is appropriate.  The modular approach will allow new
-   and better solutions to common pre-authentication problems to be used
-   by existing mechanisms as they are developed.
-
-   This document specifies a framework for Kerberos pre-authentication
-   mechanisms.  It defines the common set of functions that pre-
-   authentication mechanisms perform as well as how these functions
-   affect the state of the request and reply.  In addition several
-   common tools needed by pre-authentication mechanisms are provided.
-   Unlike [RFC3961], this framework is not complete--it does not
-   describe all the inputs and outputs for the pre-authentication
-   mechanisms.  Pre-Authentication mechanism designers should try to be
-   consistent with this framework because doing so will make their
-   mechanisms easier to implement.  Kerberos implementations are likely
-   to have plugin architectures for pre-authentication; such
-   architectures are likely to support mechanisms that follow this
-   framework plus commonly used extensions.  This framework also
-   facilitates combining multiple pre-authentication mechanisms, each of
-   which may represent an authentication factor, into a single multi-
-   factor pre-authentication mechanism.
-
-   One of these common tools is the flexible authentication secure
-   tunneling (FAST) padata type.  FAST provides a protected channel
-   between the client and the KDC, and it can optionally deliver a reply
-   key within the protected channel.  Based on FAST, pre-authentication
-   mechanisms can extend Kerberos with ease, to support, for example,
-   password authenticated key exchange (PAKE) protocols with zero
-   knowledge password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-
-   authentication mechanism can be encapsulated in the FAST messages as
-   defined in Section 6.5.  A pre-authentication type carried within
-   FAST is called a FAST factor.  Creating a FAST factor is the easiest
-   path to create a new pre-authentication mechanism.  FAST factors are
-   significantly easier to analyze from a security standpoint than other
-
-
-
-Hartman & Zhu           Expires November 21, 2009               [Page 5]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   pre-authentication mechanisms.
-
-   Mechanism designers should design FAST factors, instead of new pre-
-   authentication mechanisms outside of FAST.
-
-
-2.  Conventions and Terminology Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   This document should be read only after reading the documents
-   describing the Kerberos cryptography framework [RFC3961] and the core
-   Kerberos protocol [RFC4120].  This document may freely use
-   terminology and notation from these documents without reference or
-   further explanation.
-
-   The word padata is used as a shorthand for pre-authentication data.
-
-   A conversation is the set of all authentication messages exchanged
-   between the client and the client's Authentication Service (AS) in
-   order to authenticate the client principal.  A conversation as
-   defined here consists of all messages that are necessary to complete
-   the authentication between the client and the client's AS.  In the
-   Ticket Exchange Service (TGS) exchange, a conversation consists of
-   the request message and the reply message.  The term conversation is
-   defined here for both AS and TGS for convenience of discussion.  See
-   Section 6.3 for specific rules on the extent of a conversation in the
-   AS-REQ case.  Prior to this framework, implementations needed to use
-   implementation-specific heuristics to determine the extent of a
-   conversation.
-
-   If the KDC reply in an AS exchange is verified, the KDC is
-   authenticated by the client.  In this document, verification of the
-   KDC reply is used as a synonym of authentication of the KDC.
-
-
-3.  Model for Pre-Authentication
-
-   When a Kerberos client wishes to obtain a ticket using the
-   authentication server, it sends an initial Authentication Service
-   (AS) request.  If pre-authentication is required but not being used,
-   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
-   Alternatively, if the client knows what pre-authentication to use, it
-   MAY optimize away a round-trip and send an initial request with
-   padata included in the initial request.  If the client includes the
-   padata computed using the wrong pre-authentication mechanism or
-
-
-
-Hartman & Zhu           Expires November 21, 2009               [Page 6]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
-   indication of what padata should have been included.  In that case,
-   the client MUST retry with no padata and examine the error data of
-   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
-   authentication information in the accompanying error data of
-   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
-   then retry.
-
-   The conventional KDC maintains no state between two requests;
-   subsequent requests may even be processed by a different KDC.  On the
-   other hand, the client treats a series of exchanges with KDCs as a
-   single conversation.  Each exchange accumulates state and hopefully
-   brings the client closer to a successful authentication.
-
-   These models for state management are in apparent conflict.  For many
-   of the simpler pre-authentication scenarios, the client uses one
-   round trip to find out what mechanisms the KDC supports.  Then the
-   next request contains sufficient pre-authentication for the KDC to be
-   able to return a successful reply.  For these simple scenarios, the
-   client only sends one request with pre-authentication data and so the
-   conversation is trivial.  For more complex conversations, the KDC
-   needs to provide the client with a cookie to include in future
-   requests to capture the current state of the authentication session.
-   Handling of multiple round-trip mechanisms is discussed in
-   Section 6.3.
-
-   This framework specifies the behavior of Kerberos pre-authentication
-   mechanisms used to identify users or to modify the reply key used to
-   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
-   extensions to Kerberos that have nothing to do with proving the
-   identity of the user or establishing a reply key.  Such extensions
-   are outside the scope of this framework.  However mechanisms that do
-   accomplish these goals should follow this framework.
-
-   This framework specifies the minimum state that a Kerberos
-   implementation needs to maintain while handling a request in order to
-   process pre-authentication.  It also specifies how Kerberos
-   implementations process the padata at each step of the AS request
-   process.
-
-3.1.  Information Managed by the Pre-authentication Model
-
-   The following information is maintained by the client and KDC as each
-   request is being processed:
-
-   o  The reply key used to encrypt the KDC reply
-
-
-
-
-
-Hartman & Zhu           Expires November 21, 2009               [Page 7]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   o  How strongly the identity of the client has been authenticated
-
-   o  Whether the reply key has been used in this conversation
-
-   o  Whether the reply key has been replaced in this conversation
-
-   o  Whether the contents of the KDC reply can be verified by the
-      client principal
-
-
-   Conceptually, the reply key is initially the long-term key of the
-   principal.  However, principals can have multiple long-term keys
-   because of support for multiple encryption types, salts and
-   string2key parameters.  As described in Section 5.2.7.5 of the
-   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
-   the client what types of keys are available.  Thus in full
-   generality, the reply key in the pre-authentication model is actually
-   a set of keys.  At the beginning of a request, it is initialized to
-   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
-   the KDC.  If multiple reply keys are available, the client chooses
-   which one to use.  Thus the client does not need to treat the reply
-   key as a set.  At the beginning of a request, the client picks a key
-   to use.
-
-   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
-   INFO2 element.  Since the KDC already knows the client's list of
-   supported enctypes from the request, no interoperability problems are
-   created by choosing a single possible reply key.  This way, the KDC
-   implementation avoids the complexity of treating the reply key as a
-   set.
-
-   When the padata in the request is verified by the KDC, then the
-   client is known to have that key, therefore the KDC SHOULD pick the
-   same key as the reply key.
-
-   At the beginning of handling a message on both the client and the
-   KDC, the client's identity is not authenticated.  A mechanism may
-   indicate that it has successfully authenticated the client's
-   identity.  This information is useful to keep track of on the client
-   in order to know what pre-authentication mechanisms should be used.
-   The KDC needs to keep track of whether the client is authenticated
-   because the primary purpose of pre-authentication is to authenticate
-   the client identity before issuing a ticket.  The handling of
-   authentication strength using various authentication mechanisms is
-   discussed in Section 6.6.
-
-   Initially the reply key has not been used.  A pre-authentication
-   mechanism that uses the reply key to encrypt or checksum some data in
-
-
-
-Hartman & Zhu           Expires November 21, 2009               [Page 8]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   the generation of new keys MUST indicate that the reply key is used.
-   This state is maintained by the client and the KDC to enforce the
-   security requirement stated in Section 4.3 that the reply key SHOULD
-   NOT be replaced after it is used.
-
-   Initially the reply key has not been replaced.  If a mechanism
-   implements the Replace Reply Key facility discussed in Section 4.3,
-   then the state MUST be updated to indicate that the reply key has
-   been replaced.  Once the reply key has been replaced, knowledge of
-   the reply key is insufficient to authenticate the client.  The reply
-   key is marked replaced in exactly the same situations as the KDC
-   reply is marked as not being verified to the client principal.
-   However, while mechanisms can verify the KDC reply to the client,
-   once the reply key is replaced, then the reply key remains replaced
-   for the remainder of the conversation.
-
-   Without pre-authentication, the client knows that the KDC reply is
-   authentic and has not been modified because it is encrypted in a
-   long-term key of the client.  Only the KDC and the client know that
-   key.  So at the start of a conversation, the KDC reply is presumed to
-   be verified using the client principal's long-term key.  It should be
-   noted that in this document, verifying the KDC reply means
-   authenticating the KDC, and these phrases are used interchangeably.
-   Any pre-authentication mechanism that sets a new reply key not based
-   on the principal's long-term secret MUST either verify the KDC reply
-   some other way or indicate that the reply is not verified.  If a
-   mechanism indicates that the reply is not verified then the client
-   implementation MUST return an error unless a subsequent mechanism
-   verifies the reply.  The KDC needs to track this state so it can
-   avoid generating a reply that is not verified.
-
-   The typical Kerberos request does not provide a way for the client
-   machine to know that it is talking to the correct KDC.  Someone who
-   can inject packets into the network between the client machine and
-   the KDC and who knows the password that the user will give to the
-   client machine can generate a KDC reply that will decrypt properly.
-   So, if the client machine needs to authenticate that the user is in
-   fact the named principal, then the client machine needs to do a TGS
-   request for itself as a service.  Some pre-authentication mechanisms
-   may provide a way for the client machine to authenticate the KDC.
-   Examples of this include signing the reply that can be verified using
-   a well-known public key or providing a ticket for the client machine
-   as a service.
-
-3.2.  Initial Pre-authentication Required Error
-
-   Typically a client starts a conversation by sending an initial
-   request with no pre-authentication.  If the KDC requires pre-
-
-
-
-Hartman & Zhu           Expires November 21, 2009               [Page 9]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
-   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
-   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
-   (defined in Section 6.3) for pre-authentication configurations that
-   use multi-round-trip mechanisms; see Section 3.4 for details of that
-   case.
-
-   The KDC needs to choose which mechanisms to offer the client.  The
-   client needs to be able to choose what mechanisms to use from the
-   first message.  For example consider the KDC that will accept
-   mechanism A followed by mechanism B or alternatively the single
-   mechanism C. A client that supports A and C needs to know that it
-   should not bother trying A.
-
-   Mechanisms can either be sufficient on their own or can be part of an
-   authentication set--a group of mechanisms that all need to
-   successfully complete in order to authenticate a client.  Some
-   mechanisms may only be useful in authentication sets; others may be
-   useful alone or in authentication sets.  For the second group of
-   mechanisms, KDC policy dictates whether the mechanism will be part of
-   an authentication set, offered alone, or both.  For each mechanism
-   that is offered alone (even if it is also offered in an
-   authentication set), the KDC includes the pre-authentication type ID
-   of the mechanism in the padata sequence returned in the
-   KDC_ERR_PREAUTH_REQUIRED error.  Mechanisms that are only offered as
-   part of an authentication set are not directly represented in the
-   padata sequence returned in the KDC_ERR_PREAUTH_REQUIRED error,
-   although they are represented in the PA-AUTHENTICATION-SET sequence.
-
-   The KDC SHOULD NOT send data that is encrypted in the long-term
-   password-based key of the principal.  Doing so has the same security
-   exposures as the Kerberos protocol without pre-authentication.  There
-   are few situations where the KDC needs to expose cipher text
-   encrypted in a weak key before the client has proven knowledge of
-   that key, and pre-authentication is desirable.
-
-3.3.  Client to KDC
-
-   This description assumes that a client has already received a
-   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
-   optimistic pre-authentication then the client needs to guess values
-   for the information it would normally receive from that error
-   response or use cached information obtained in prior interactions
-   with the KDC.
-
-   The client starts by initializing the pre-authentication state as
-   specified.  It then processes the padata in the
-   KDC_ERR_PREAUTH_REQUIRED.
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 10]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
-   client MAY ignore any padata it chooses unless doing so violates a
-   specification to which the client conforms.  Clients conforming to
-   this specification MUST NOT ignore the padata defined in Section 6.3.
-   Clients SHOULD process padata unrelated to this framework or other
-   means of authenticating the user.  Clients SHOULD choose one
-   authentication set or mechanism that could lead to authenticating the
-   user and ignore the rest.  Since the list of mechanisms offered by
-   the KDC is in the decreasing preference order, clients typically
-   choose the first mechanism or authentication set that the client can
-   usefully perform.  If a client chooses to ignore a padata it MUST NOT
-   process the padata, allow the padata to affect the pre-authentication
-   state, nor respond to the padata.
-
-   For each padata the client chooses to process, the client processes
-   the padata and modifies the pre-authentication state as required by
-   that mechanism.  Padata are processed in the order received from the
-   KDC.
-
-   After processing the padata in the KDC error, the client generates a
-   new request.  It processes the pre-authentication mechanisms in the
-   order in which they will appear in the next request, updating the
-   state as appropriate.  The request is sent when it is complete.
-
-3.4.  KDC to Client
-
-   When a KDC receives an AS request from a client, it needs to
-   determine whether it will respond with an error or an AS reply.
-   There are many causes for an error to be generated that have nothing
-   to do with pre-authentication; they are discussed in the core
-   Kerberos specification.
-
-   From the standpoint of evaluating the pre-authentication, the KDC
-   first starts by initializing the pre-authentication state.  If a PA-
-   FX-COOKIE pre-authentication data item is present, it is processed
-   first; see Section 6.3 for a definition.  It then processes the
-   padata in the request.  As mentioned in Section 3.3, the KDC MAY
-   ignore padata that is inappropriate for the configuration and MUST
-   ignore padata of an unknown type.  The KDC MUST NOT ignore padata of
-   types used in previous messages.  For example, if a KDC issues a
-   KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the
-   KDC cannot ignore padata of type x received in an AS-REQ message from
-   the client.
-
-   At this point the KDC decides whether it will issue an error or a
-   reply.  Typically a KDC will issue a reply if the client's identity
-   has been authenticated to a sufficient degree.
-
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 11]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC
-   first starts by initializing the pre-authentication state.  Then it
-   processes any padata in the client's request in the order provided by
-   the client.  Mechanisms that are not understood by the KDC are
-   ignored.  Next, it generates padata for the error response, modifying
-   the pre-authentication state appropriately as each mechanism is
-   processed.  The KDC chooses the order in which it will generate
-   padata (and thus the order of padata in the response), but it needs
-   to modify the pre-authentication state consistently with the choice
-   of order.  For example, if some mechanism establishes an
-   authenticated client identity, then the subsequent mechanisms in the
-   generated response receive this state as input.  After the padata is
-   generated, the error response is sent.  Typically the errors with the
-   code KDC_ERR_MORE_PREAUTH_DATA_NEEDED in a conversation will include
-   KDC state as discussed in Section 6.3.
-
-   To generate a final reply, the KDC generates the padata modifying the
-   pre-authentication state as necessary.  Then it generates the final
-   response, encrypting it in the current pre-authentication reply key.
-
-
-4.  Pre-Authentication Facilities
-
-   Pre-Authentication mechanisms can be thought of as providing various
-   conceptual facilities.  This serves two useful purposes.  First,
-   mechanism authors can choose only to solve one specific small
-   problem.  It is often useful for a mechanism designed to offer key
-   management not to directly provide client authentication but instead
-   to allow one or more other mechanisms to handle this need.  Secondly,
-   thinking about the abstract services that a mechanism provides yields
-   a minimum set of security requirements that all mechanisms providing
-   that facility must meet.  These security requirements are not
-   complete; mechanisms will have additional security requirements based
-   on the specific protocol they employ.
-
-   A mechanism is not constrained to only offering one of these
-   facilities.  While such mechanisms can be designed and are sometimes
-   useful, many pre-authentication mechanisms implement several
-   facilities.  By combining multiple facilities in a single mechanism,
-   it is often easier to construct a secure, simple solution than by
-   solving the problem in full generality.  Even when mechanisms provide
-   multiple facilities, they need to meet the security requirements for
-   all the facilities they provide.  If the FAST factor approach is
-   used, it is likely that one or a small number of facilities can be
-   provided by a single mechanism without complicating the security
-   analysis.
-
-   According to Kerberos extensibility rules (Section 1.5 of the
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 12]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   Kerberos specification [RFC4120]), an extension MUST NOT change the
-   semantics of a message unless a recipient is known to understand that
-   extension.  Because a client does not know that the KDC supports a
-   particular pre-authentication mechanism when it sends an initial
-   request, a pre-authentication mechanism MUST NOT change the semantics
-   of the request in a way that will break a KDC that does not
-   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
-   clients that affect the core semantics unless the client has
-   indicated support for the message.
-
-   The only state in this model that would break the interpretation of a
-   message is changing the expected reply key.  If one mechanism changed
-   the reply key and a later mechanism used that reply key, then a KDC
-   that interpreted the second mechanism but not the first would fail to
-   interpret the request correctly.  In order to avoid this problem,
-   extensions that change core semantics are typically divided into two
-   parts.  The first part proposes a change to the core semantic--for
-   example proposes a new reply key.  The second part acknowledges that
-   the extension is understood and that the change takes effect.
-   Section 4.2 discusses how to design mechanisms that modify the reply
-   key to be split into a proposal and acceptance without requiring
-   additional round trips to use the new reply key in subsequent pre-
-   authentication.  Other changes in the state described in Section 3.1
-   can safely be ignored by a KDC that does not understand a mechanism.
-   Mechanisms that modify the behavior of the request outside the scope
-   of this framework need to carefully consider the Kerberos
-   extensibility rules to avoid similar problems.
-
-4.1.  Client-authentication Facility
-
-   The client authentication facility proves the identity of a user to
-   the KDC before a ticket is issued.  Examples of mechanisms
-   implementing this facility include the encrypted timestamp facility
-   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
-   Mechanisms that provide this facility are expected to mark the client
-   as authenticated.
-
-   Mechanisms implementing this facility SHOULD require the client to
-   prove knowledge of the reply key before transmitting a successful KDC
-   reply.  Otherwise, an attacker can intercept the pre-authentication
-   exchange and get a reply to attack.  One way of proving the client
-   knows the reply key is to implement the Replace Reply Key facility
-   along with this facility.  The PKINIT mechanism [RFC4556] implements
-   Client Authentication alongside Replace Reply Key.
-
-   If the reply key has been replaced, then mechanisms such as
-   encrypted-timestamp that rely on knowledge of the reply key to
-   authenticate the client MUST NOT be used.
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 13]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-4.2.  Strengthening-reply-key Facility
-
-   Particularly when dealing with keys based on passwords, it is
-   desirable to increase the strength of the key by adding additional
-   secrets to it.  Examples of sources of additional secrets include the
-   results of a Diffie-Hellman key exchange or key bits from the output
-   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
-   be first combined with the existing reply key and then converted to a
-   protocol key using tools defined in Section 6.1.
-
-   Typically a mechanism implementing this facility will know that the
-   other side of the exchange supports the facility before the reply key
-   is changed.  For example, a mechanism might need to learn the
-   certificate for a KDC before encrypting a new key in the public key
-   belonging to that certificate.  However, if a mechanism implementing
-   this facility wishes to modify the reply key before knowing that the
-   other party in the exchange supports the mechanism, it proposes
-   modifying the reply key.  The other party then includes a message
-   indicating that the proposal is accepted if it is understood and
-   meets policy.  In many cases it is desirable to use the new reply key
-   for client authentication and for other facilities.  Waiting for the
-   other party to accept the proposal and actually modify the reply key
-   state would add an additional round trip to the exchange.  Instead,
-   mechanism designers are encouraged to include a typed hole for
-   additional padata in the message that proposes the reply key change.
-   The padata included in the typed hole are generated assuming the new
-   reply key.  If the other party accepts the proposal, then these
-   padata are considered as an inner level.  As with the outer level,
-   one authentication set or mechanism is typically chosen for client
-   authentication, along with auxiliary mechanisms such as KDC cookies,
-   and other mechanisms are ignored.  When mechanisms include such a
-   container, the hint provided for use in authentication sets (as
-   defined in Section 6.4) MUST contain a sequence of inner mechanisms
-   along with hints for those mechanisms.  The party generating the
-   proposal can determine whether the padata were processed based on
-   whether the proposal for the reply key is accepted.
-
-   The specific formats of the proposal message, including where padata
-   are included is a matter for the mechanism specification.  Similarly,
-   the format of the message accepting the proposal is mechanism-
-   specific.
-
-   Mechanisms implementing this facility and including a typed hole for
-   additional padata MUST checksum that padata using a keyed checksum or
-   encrypt the padata.  This requirement protects against modification
-   of the contents of the typed hole.  By modifying these contents an
-   attacker might be able to choose which mechanism is used to
-   authenticate the client, or to convince a party to provide text
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 14]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   encrypted in a key that the attacker had manipulated.  It is
-   important that mechanisms strengthen the reply key enough that using
-   it to checksum padata is appropriate.
-
-4.3.  Replacing-reply-key Facility
-
-   The Replace Reply Key facility replaces the key in which a successful
-   AS reply will be encrypted.  This facility can only be used in cases
-   where knowledge of the reply key is not used to authenticate the
-   client.  The new reply key MUST be communicated to the client and the
-   KDC in a secure manner.  This facility MUST NOT be used if there can
-   be a man-in-the-middle between the client and the KDC.  Mechanisms
-   implementing this facility MUST mark the reply key as replaced in the
-   pre-authentication state.  Mechanisms implementing this facility MUST
-   either provide a mechanism to verify the KDC reply to the client or
-   mark the reply as unverified in the pre-authentication state.
-   Mechanisms implementing this facility SHOULD NOT be used if a
-   previous mechanism has used the reply key.
-
-   As with the strengthening-reply-key facility, Kerberos extensibility
-   rules require that the reply key not be changed unless both sides of
-   the exchange understand the extension.  In the case of this facility
-   it will likely be the case for both sides to know that the facility
-   is available by the time that the new key is available to be used.
-   However, mechanism designers can use a container for padata in a
-   proposal message as discussed in Section 4.2 if appropriate.
-
-4.4.  KDC-authentication Facility
-
-   This facility verifies that the reply comes from the expected KDC.
-   In traditional Kerberos, the KDC and the client share a key, so if
-   the KDC reply can be decrypted then the client knows that a trusted
-   KDC responded.  Note that the client machine cannot trust the client
-   unless the machine is presented with a service ticket for it
-   (typically the machine can retrieve this ticket by itself).  However,
-   if the reply key is replaced, some mechanism is required to verify
-   the KDC.  Pre-authentication mechanisms providing this facility allow
-   a client to determine that the expected KDC has responded even after
-   the reply key is replaced.  They mark the pre-authentication state as
-   having been verified.
-
-
-5.  Requirements for Pre-Authentication Mechanisms
-
-   This section lists requirements for specifications of pre-
-   authentication mechanisms.
-
-   For each message in the pre-authentication mechanism, the
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 15]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   specification describes the pa-type value to be used and the contents
-   of the message.  The processing of the message by the sender and
-   recipient is also specified.  This specification needs to include all
-   modifications to the pre-authentication state.
-
-   Generally mechanisms have a message that can be sent in the error
-   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
-   authentication set.  If the client needs information such as trusted
-   certificate authorities in order to determine if it can use the
-   mechanism, then this information should be in that message.  In
-   addition, such mechanisms should also define a pa-hint to be included
-   in authentication sets.  Often, the same information included in the
-   padata-value is appropriate to include in the pa-hint (as defined in
-   Section 6.4).
-
-   In order to ease security analysis the mechanism specification should
-   describe what facilities from this document are offered by the
-   mechanism.  For each facility, the security consideration section of
-   the mechanism specification should show that the security
-   requirements of that facility are met.  This requirement is
-   applicable to any FAST factor that provides authentication
-   information.
-
-   Significant problems have resulted in the specification of Kerberos
-   protocols because much of the KDC exchange is not protected against
-   authentication.  The security considerations section should discuss
-   unauthenticated plaintext attacks.  It should either show that
-   plaintext is protected or discuss what harm an attacker could do by
-   modifying the plaintext.  It is generally acceptable for an attacker
-   to be able to cause the protocol negotiation to fail by modifying
-   plaintext.  More significant attacks should be evaluated carefully.
-
-   As discussed in Section 6.3, there is no guarantee that a client will
-   use the same KDCs for all messages in a conversation.  The mechanism
-   specification needs to show why the mechanism is secure in this
-   situation.  The hardest problem to deal with, especially for
-   challenge/response mechanisms is to make sure that the same response
-   cannot be replayed against two KDCs while allowing the client to talk
-   to any KDC.
-
-
-6.  Tools for Use in Pre-Authentication Mechanisms
-
-   This section describes common tools needed by multiple pre-
-   authentication mechanisms.  By using these tools mechanism designers
-   can use a modular approach to specify mechanism details and ease
-   security analysis.
-
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 16]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-6.1.  Combining Keys
-
-   Frequently a weak key needs to be combined with a stronger key before
-   use.  For example, passwords are typically limited in size and
-   insufficiently random, therefore it is desirable to increase the
-   strength of the keys based on passwords by adding additional secrets.
-   Additional source of secrecy may come from hardware tokens.
-
-   This section provides standard ways to combine two keys into one.
-
-   KRB-FX-CF1() is defined to combine two pass-phrases.
-
-       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
-       KRB-FX-CF1(x, y) -> x || y
-
-   Where || denotes concatenation.  The strength of the final key is
-   roughly the total strength of the individual keys being combined
-   assuming that the string_to_key() function [RFC3961] uses all its
-   input evenly.
-
-   An example usage of KRB-FX-CF1() is when a device provides random but
-   short passwords, the password is often combined with a personal
-   identification number (PIN).  The password and the PIN can be
-   combined using KRB-FX-CF1().
-
-   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
-   function defined in [RFC3961].
-
-   Given two input keys, K1 and K2, where K1 and K2 can be of two
-   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
-   follows:
-
-       KRB-FX-CF2(protocol key, protocol key, octet string,
-                 octet string)  ->  (protocol key)
-
-       PRF+(K1, pepper1) -> octet-string-1
-       PRF+(K2, pepper2) -> octet-string-2
-       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
-              random-to-key(octet-string-1 ^ octet-string-2)
-
-   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
-   follows:
-
-    PRF+(protocol key, octet string) -> (octet string)
-
-    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
-                  pseudo-random( key, 2 || shared-info ) ||
-                  pseudo-random( key, 3 || shared-info ) || ...
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 17]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
-   integer.  The pseudo-random() operation is specified by the enctype
-   of the protocol key.  PRF+() uses the counter to generate enough bits
-   as needed by the random-to-key() [RFC3961] function for the
-   encryption type specified for the resulting key; unneeded bits are
-   removed from the tail.  Unless otherwise specified, the resulting
-   enctype of KRB-FX-CF2 is the enctype of k1.
-
-   Mechanism designers MUST specify the values for the input parameter
-   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
-   pepper1 and pepper2 MUST be distinct so that if the two keys being
-   combined are the same, the resulting key is not a trivial key.
-
-6.2.  Protecting Requests/Responses
-
-   Mechanism designers SHOULD protect clear text portions of pre-
-   authentication data.  Various denial of service attacks and downgrade
-   attacks against Kerberos are possible unless plaintexts are somehow
-   protected against modification.  An early design goal of Kerberos
-   Version 5 [RFC4120] was to avoid encrypting more of the
-   authentication exchange that was required.  (Version 4 doubly-
-   encrypted the encrypted part of a ticket in a KDC reply, for
-   example.)  This minimization of encryption reduces the load on the
-   KDC and busy servers.  Also, during the initial design of Version 5,
-   the existence of legal restrictions on the export of cryptography
-   made it desirable to minimize of the number of uses of encryption in
-   the protocol.  Unfortunately, performing this minimization created
-   numerous instances of unauthenticated security-relevant plaintext
-   fields.
-
-   If there is more than one round trip for an authentication exchange,
-   mechanism designers need to allow either the client or the KDC to
-   provide a checksum of all the messages exchanged on the wire in the
-   conversation, and the checksum is then verified by the receiver.
-
-   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
-
-   Primitives defined in [RFC3961] are RECOMMENDED for integrity
-   protection and confidentiality.  Mechanisms based on these primitives
-   are crypto-agile as the result of using [RFC3961] along with
-   [RFC4120].  The advantage afforded by crypto-agility is the ability
-   to incrementally deploy a fix specific to a particular algorithm thus
-   avoid a multi-year standardization and deployment cycle, when real
-   attacks do arise against that algorithm.
-
-   Note that data used by FAST factors (defined in Section 6.5) is
-   encrypted in a protected channel, thus they do not share the un-
-   authenticated-text issues with mechanisms designed as full-blown pre-
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 18]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   authentication mechanisms.
-
-6.3.  Managing States for the KDC
-
-   Kerberos KDCs are stateless in that there is no requirement that
-   clients will choose the same KDC for the second request in a
-   conversation.  Proxies or other intermediate nodes may also influence
-   KDC selection.  So, each request from a client to a KDC must include
-   sufficient information that the KDC can regenerate any needed state.
-   This is accomplished by giving the client a potentially long opaque
-   cookie in responses to include in future requests in the same
-   conversation.  The KDC MAY respond that a conversation is too old and
-   needs to restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
-
-       KDC_ERR_PREAUTH_EXPIRED            90
-
-   When a client receives this error, the client SHOULD abort the
-   existing conversation, and restart a new one.
-
-   An example, where more than one message from the client is needed, is
-   when the client is authenticated based on a challenge-response
-   scheme.  In that case, the KDC needs to keep track of the challenge
-   issued for a client authentication request.
-
-   The PA-FX-COOKIE padata type is defined in this section to facilitate
-   state management in the AS exchange.  This padata is sent by the KDC
-   when the KDC requires state for a future transaction.  The client
-   includes this opaque token in the next message in the conversation.
-   The token may be relatively large; clients MUST be prepared for
-   tokens somewhat larger than the size of all messages in a
-   conversation.
-
-       PA-FX-COOKIE                       133
-           -- Stateless cookie that is not tied to a specific KDC.
-
-   The corresponding padata-value field [RFC4120] contains an opaque
-   token that will be echoed by the client in its response to an error
-   from the KDC.
-
-   The cookie token is generated by the KDC and transmitted in a PA-FX-
-   COOKIE pre-authentication data item of a KRB-ERROR message.  The
-   client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data
-   element into the next message of the same conversation.  The content
-   of the cookie field is a local matter of the KDC.  As a result, it is
-   not generally possible to mix KDC implementations from different
-   vendors in the same realm.  However the KDC MUST construct the cookie
-   token in such a manner that a malicious client cannot subvert the
-   authentication process by manipulating the token.  The KDC
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 19]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   implementation needs to consider expiration of tokens, key rollover
-   and other security issues in token design.  The content of the cookie
-   field is likely specific to the pre-authentication mechanisms used to
-   authenticate the client.  If a client authentication response can be
-   replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an
-   expiration in the cookie is RECOMMENDED to prevent the response being
-   presented indefinitely.
-
-   If at least one more message for a mechanism or a mechanism set is
-   expected by the KDC, the KDC returns a
-   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA-FX-COOKIE to
-   identify the conversation with the client according to Section 3.2.
-   The cookie is not expected to stay constant for a conversation: the
-   KDC is expected to generate a new cookie for each message.
-
-        KDC_ERR_MORE_PREAUTH_DATA_NEEDED   91
-
-   A client MAY throw away the state associated with a conversation and
-   begin a new conversation by discarding its state and not including a
-   cooking in the first message of a conversation.  KDCs that comply
-   with this specification MUST include a cookie in a response when the
-   client can continue the conversation.  In particular, a KDC MUST
-   include a cookie in a KDC_ERR_PREAUTH_REQUIRED or
-   KDC_ERR_MORE_PREAUTH_DATA_NEEDED.  KDCs SHOULD include a cookie in
-   errors containing additional information allowing a client to retry.
-   One reasonable strategy for meeting these requirements is to always
-   include a cookie in KDC errors.
-
-   A KDC MAY indicate that it is terminating a conversation by not
-   including a cookie in a response.  When FAST is used, clients can
-   assume that the absence of a cookie means that the KDC is ending the
-   conversation.  Clients also need to deal with KDCs prior to this
-   specification that do not include cookies; if cookies nor FAST are
-   used in a conversation, the absence of a cookie is not a strong
-   indication that the KDC is terminating the conversation.
-
-6.4.  Pre-authentication Set
-
-   If all mechanisms in a group need to successfully complete in order
-   to authenticate a client, the client and the KDC SHOULD use the PA-
-   AUTHENTICATION-SET padata element.
-
-        PA-AUTHENTICATION-SET              134
-
-   A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
-   encoding of the PA-AUTHENTICATION-SET structure:
-
-
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 20]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-            pa-type      [0] Int32,
-                -- same as padata-type.
-            pa-hint      [1] OCTET STRING OPTIONAL,
-            pa-value     [2] OCTET STRING OPTIONAL,
-            ...
-        }
-
-   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
-   contains the corresponding value of padata-type in PA-DATA [RFC4120].
-   Associated with the pa-type is a pa-hint, which is an octet-string
-   specified by the pre-authentication mechanism.  This hint may provide
-   information for the client which helps it determine whether the
-   mechanism can be used.  For example a public-key mechanism might
-   include the certificate authorities it trusts in the hint info.  Most
-   mechanisms today do not specify hint info; if a mechanism does not
-   specify hint info the KDC MUST NOT send a hint for that mechanism.
-   To allow future revisions of mechanism specifications to add hint
-   info, clients MUST ignore hint info received for mechanisms that the
-   client believes do not support hint info.  The pa-value element of
-   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
-   first padata-value from the KDC to the client.  If the client chooses
-   this authentication set then the client MUST process this pa-value.
-   The pa-value element MUST be absent for all but the first entry in
-   the authentication set.  Clients MUST ignore pa-value for the second
-   and following entries in the authentication set.
-
-   If the client chooses an authentication set, then its first AS-REQ
-   message MUST contain a PA-AUTH-SET-SELECTED padata element.  This
-   element contains the encoding of the PA-AUTHENTICATION-SET sequence
-   received from the KDC corresponding to the authentication set that is
-   chosen.  The client MUST use the same octet values received from the
-   KDC; it cannot re-encode the sequence.  This allows KDCs to use bit-
-   wise comparison to identify the selected authentication set.  The PA-
-   AUTH-SET-SELECTED padata element MUST come before any padata elements
-   from the authentication set in the padata sequence in the AS-REQ
-   message.  The client MAY cache authentication sets from prior
-   messages and use them to construct an optimistic initial AS-REQ.  If
-   the KDC receives a PA-AUTH-SET-SELECTED padata element that does not
-   correspond to an authentication set that it would offer, then the KDC
-   returns the KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The e-data
-   in this error contains a sequence of padata just as for the
-   KDC_ERR_PREAUTH_REQUIRED error.
-
-
-         PA-AUTH-SET-SELECTED                   135
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 21]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-         KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
-
-   The PA-AUTHENTICATION-SET appears only in the first message from the
-   KDC to the client.  In particular, the client MAY fail if the
-   authentication mechanism sets change as the conversation progresses.
-   Clients MAY assume that the hints provided in the authentication set
-   contain enough information that the client knows what user interface
-   elements need to be displayed during the entire authentication
-   conversation.  Exceptional circumstances such as expired passwords or
-   expired accounts may require that additional user interface be
-   displayed.  Mechanism designers needs to carefully consider the
-   design of their hints so that the client has this information.  This
-   way, clients can construct necessary dialogue boxes or wizards based
-   on the authentication set and can present a coherent user interface.
-   Current standards for user interface do not provide an acceptable
-   experience when the client has to ask additional questions later in
-   the conversation.
-
-   When indicating which sets of pre-authentication mechanisms are
-   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
-   for each pre-authentication mechanism set.
-
-   The client sends the padata-value for the first mechanism it picks in
-   the pre-authentication set, when the first mechanism completes, the
-   client and the KDC will proceed with the second mechanism, and so on
-   until all mechanisms complete successfully.  The PA-FX-COOKIE as
-   defined in Section 6.3 MUST be sent by the KDC.  One reason for this
-   requirement is so that the conversation can continue if the
-   conversation involves multiple KDCs.  KDCs MUST support clients that
-   do not include a cookie because they optimistically choose an
-   authentication set, although they MAY always return
-   KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in that
-   message.  Clients that support PA-AUTHENTICATION-SET MUST support PA-
-   FX-COOKIE.
-
-   Before the authentication succeeds and a ticket is returned, the
-   message that the client sends is an AS_REQ and the message that the
-   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
-   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_NEEDED as defined
-   in Section 6.3 and the accompanying e-data contains the DER encoding
-   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
-   the METHOD-DATA.  If there is no padata, the e-data field is absent
-   in the KRB-ERROR message.
-
-   If the client sends the last message for a given mechanism, then the
-   KDC sends the first message for the next mechanism.  If the next
-   mechanism does not start with a KDC-side challenge, then the KDC
-   includes a padata item with the appropriate pa-type and an empty pa-
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 22]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   data.
-
-   If the KDC sends the last message for a particular mechanism, the KDC
-   also includes the first padata for the next mechanism.
-
-6.5.  Definition of Kerberos FAST Padata
-
-   As described in [RFC4120], Kerberos is vulnerable to offline
-   dictionary attacks.  An attacker can request an AS-REP and try
-   various passwords to see if they can decrypt the resulting ticket.
-   RFC 4120 provides the encrypted timestamp pre-authentication method
-   that ameliorates the situation somewhat by requiring that an attacker
-   observe a successful authentication.  However stronger security is
-   desired in many environments.  The Kerberos FAST pre-authentication
-   padata defined in this section provides a tool to significantly
-   reduce vulnerability to offline dictionary attack.  When combined
-   with encrypted challenge, FAST requires an attacker to mount a
-   successful man-in-the-middle attack to observe ciphertext.  When
-   combined with host keys, FAST can even protect against active
-   attacks.  FAST also provides solutions to common problems for pre-
-   authentication mechanisms such as binding of the request and the
-   reply, freshness guarantee of the authentication.  FAST itself,
-   however, does not authenticate the client or the KDC, instead, it
-   provides a typed hole to allow pre-authentication data be tunneled.
-   A pre-authentication data element used within FAST is called a FAST
-   factor.  A FAST factor captures the minimal work required for
-   extending Kerberos to support a new pre-authentication scheme.
-
-   A FAST factor MUST NOT be used outside of FAST unless its
-   specification explicitly allows so.  The typed holes in FAST messages
-   can also be used as generic holes for other padata that are not
-   intended to prove the client's identity, or establish the reply key.
-
-   New pre-authentication mechanisms SHOULD be designed as FAST factors,
-   instead of full-blown pre-authentication mechanisms.
-
-   FAST factors that are pre-authentication mechanisms MUST meet the
-   requirements in Section 5.
-
-   FAST employs an armoring scheme.  The armor can be a Ticket Granting
-   Ticket (TGT) obtained by the client's machine using the host keys to
-   pre-authenticate with the KDC, or an anonymous TGT obtained based on
-   anonymous PKINIT [KRB-ANON] [RFC4556].
-
-   The rest of this section describes the types of armors and the syntax
-   of the messages used by FAST.  Conforming implementations MUST
-   support Kerberos FAST padata.
-
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 23]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   Any FAST armor scheme MUST provide a fresh armor key for each
-   conversation.  Clients and KDCs can assume that if a message is
-   encrypted and integrity protected with a given armor key then it is
-   part of the conversation using that armor key.
-
-   All KDCs in a realm MUST support FAST if FAST is offered by any KDC
-   as a pre-authentication mechanism.
-
-6.5.1.  FAST Armors
-
-   An armor key is used to encrypt pre-authentication data in the FAST
-   request and the response.  The KrbFastArmor structure is defined to
-   identify the armor key.  This structure contains the following two
-   fields: the armor-type identifies the type of armors, and the armor-
-   value is an OCTET STRING that contains the description of the armor
-   scheme and the armor key.
-
-        KrbFastArmor ::= SEQUENCE {
-            armor-type   [0] Int32,
-                -- Type of the armor.
-            armor-value  [1] OCTET STRING,
-                -- Value of the armor.
-            ...
-        }
-
-   The value of the armor key is a matter of the armor type
-   specification.  Only one armor type is defined in this document.
-
-        FX_FAST_ARMOR_AP_REQUEST           1
-
-   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
-
-   Conforming implementations MUST implement the
-   FX_FAST_ARMOR_AP_REQUEST armor type.
-
-   FAST implementations MUST maintain state about whether the armor
-   mechanism authenticates the KDC.  If it does not, then a fast factor
-   that authenticates the KDC MUST be used if the reply key is replaced.
-
-6.5.1.1.  Ticket-based Armors
-
-   This is a ticket-based armoring scheme.  The armor-type is
-   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
-   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
-   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
-   The armor key is defined by the following function:
-
-       armor_key = KRB-FX-CF2( subkey, ticket_session_key,
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 24]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-                   "subkeyarmor", "ticketarmor" )
-
-   The `ticket_session_key' is the session key from the ticket in the
-   ap-req.  The `subkey' is the ap-req subkey.  This construction
-   guarantees that both the KDC (through the session key) and the client
-   (through the subkey) contribute to the armor key.
-
-   The server name field of the armor ticket MUST identify the TGS of
-   the target realm.  Here are three common ways in the decreasing
-   preference order how an armor TGT SHOULD be obtained:
-
-   1.  If the client is authenticating from a host machine whose
-       Kerberos realm has an authentication path to the client's realm,
-       the host machine obtains a TGT by using the host keys.  If the
-       client's realm is different than the realm of the local host, the
-       machine then obtains a cross-realm TGT to the client's realm as
-       the armor ticket.  Otherwise, the host's primary TGT is the armor
-       ticket.
-
-   2.  If the client's host machine cannot obtain a host ticket strictly
-       based on RFC4120, but the KDC has an asymmetric signing key whose
-       binding with the expected KDC can be verified by the client, the
-       client can use anonymous PKINIT [KRB-ANON] [RFC4556] to
-       authenticate the KDC and obtain an anonymous TGT as the armor
-       ticket.  The armor ticket can also be a cross-realm TGT obtained
-       based on the initial primary TGT obtained using anonymous PKINIT
-       with KDC authentication.
-
-   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
-       TGT without KDC authentication and that TGT is the armor ticket.
-       Note that this mode of operation is vulnerable to man-in-the-
-       middle attacks at the time of obtaining the initial anonymous
-       armor TGT.
-
-   If anonymous PKINIT is used to obtain the armor ticket, the KDC
-   cannot know whether its signing key can be verified by the client,
-   hence the KDC MUST be marked as unverified from the KDC's point of
-   view while the client could be able to authenticate the KDC by
-   verifying the KDC's signing key is bound with the expected KDC.  The
-   client needs to carefully consider the risk and benefit tradeoffs
-   associated with active attacks before exposing cipher text encrypted
-   using the user's long-term secrets when the armor does not
-   authenticate the KDC.
-
-   The TGS MUST reject a request if there is an AD-fx-fast-armor (TBD)
-   element in the authenticator of the pa-tgs-req padata or if the
-   ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-
-   armor authorization data element.  These tickets and authenticators
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 25]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   MAY be used as FAST armor tickets but not to obtain a ticket via the
-   TGS.  This authorization data is used in a system where the
-   encryption of the user's pre-authentication data is performed in an
-   unprivileged user process.  A privileged process can provide to the
-   user process a host ticket, an authenticator for use with that
-   ticket, and the sub session key contained in the authenticator.  In
-   order for the host process to ensure that the host ticket is not
-   accidentally or intentionally misused, (i.e. the user process might
-   use the host ticket to authenticate as the host), it MUST include a
-   critical authorization data element of the type AD-fx-fast-armor when
-   providing the authenticator or in the enc-authorization-data field of
-   the TGS request used to obtain the TGT.  The corresponding ad-data
-   field of the AD-fx-fast-armor element is empty.
-
-   As discussed previously, the server of an armor ticket MUST be the
-   TGS of the realm from whom service is requested.  As a result, if
-   this armor type is used when a ticket is being validated, proxied, or
-   in other cases where a ticket other than a TGT is presented to the
-   TGS, a TGT will be used as an armor ticket, while another ticket will
-   be used in the pa-tgs-req authenticator.
-
-6.5.2.  FAST Request
-
-   A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
-   authentication padata.  The corresponding padata-value field
-   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
-   REQUEST.  As with all pre-authentication types, the KDC SHOULD
-   advertise PA-FX-FAST in a PREAUTH_REQUIRED error.  KDCs MUST send the
-   advertisement of pa-fx-fast with an empty pa-value.  Clients MUST
-   ignore the pa-value of PA-FX-FAST in an initial PREAUTH_REQUIRED
-   error.  FAST is not expected to be used in an authentication set:
-   clients will typically use FAST padata if available and this decision
-   should not depend on what other pre-authentication methods are
-   available.  As such, no pa-hint is defined for FAST at this time.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 26]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-       PA-FX-FAST                         136
-           -- Padata type for Kerberos FAST
-
-       PA-FX-FAST-REQUEST ::= CHOICE {
-           armored-data [0] KrbFastArmoredReq,
-           ...
-       }
-
-       KrbFastArmoredReq ::= SEQUENCE {
-           armor        [0] KrbFastArmor OPTIONAL,
-               -- Contains the armor that identifies the armor key.
-               -- MUST be present in AS-REQ.
-           req-checksum [1] Checksum,
-               -- For AS, contains the checksum performed over the type
-               -- KDC-REQ-BODY for the req-body field of the KDC-REQ
-               -- structure;
-               -- For TGS, contains the checksum performed over the type
-               -- AP-REQ in the PA-TGS-REQ padata.
-               -- The checksum key is the armor key, the checksum
-               -- type is the required checksum type for the enctype of
-               -- the armor key, and the key usage number is
-               -- KEY_USAGE_FAST_REQ_CHKSUM.
-           enc-fast-req [2] EncryptedData, -- KrbFastReq --
-               -- The encryption key is the armor key, and the key usage
-               -- number is KEY_USAGE_FAST_ENC.
-           ...
-       }
-
-       KEY_USAGE_FAST_REQ_CHKSUM          50
-       KEY_USAGE_FAST_ENC                 51
-
-   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
-   The KrbFastArmoredReq encapsulates the encrypted padata.
-
-   The enc-fast-req field contains an encrypted KrbFastReq structure.
-   The armor key is used to encrypt the KrbFastReq structure, and the
-   key usage number for that encryption is KEY_USAGE_FAST_ENC.
-
-   The armor key is selected as follows:
-
-   o  In an AS request, the armor field in the KrbFastArmoredReq
-      structure MUST be present and the armor key is identified
-      according to the specification of the armor type.
-
-   o  There are two possibilities for armor for a TGS request.  If the
-      ticket presented in the PA-TGS-REQ authenticator is a TGT, then
-      the client SHOULD not include the armor field in the Krbfastreq
-      and a subkey MUST be included in the PA-TGS-REQ authenticator.  In
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 27]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-      this case, the armor key is the same armor key that would be
-      computed if the TGS-REQ authenticator was used in a
-      FX_FAST_ARMOR_AP_REQUEST armor.  If a ticket other than a TGT is
-      being presented to the TGS, a client SHOULD use some form of FAST
-      armor such as a ticket-based armor with a TGT as an armor ticket.
-      Clients MAY present a non-TGT in the PA-TGS-REQ authenticator and
-      omit the armor field, in which case the armor key is the same that
-      would be computed if the authenticator were used in a
-      FX_FAST_ARMOR_AP_REQUEST armor.  This is the only case where a
-      ticket other than a TGT can be used to establish an armor key;
-      even though the armor key is computed the same as a
-      FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used as an armor
-      ticket in FX_FAST_ARMOR_AP_REQUEST.
-
-   The req-checksum field contains a checksum computed differently for
-   AS and TGS.  For an AS-REQ, it is performed over the type KDC-REQ-
-   BODY for the req-body field of the KDC-REQ structure of the
-   containing message; for an TGS-REQ, it is performed over the type AP-
-   REQ in the PA-TGS-REQ padata of the TGS request.  The checksum key is
-   the armor key, and the checksum type is the required checksum type
-   for the enctype of the armor key per [RFC3961].  This checksum MUST
-   be a keyed checksume and it is included in order to bind the FAST
-   padata to the outer request.  A KDC that implements FAST will ignore
-   the outer request, but including a checksum is relatively cheap and
-   may prevent confusing behavior.
-
-   The KrbFastReq structure contains the following information:
-
-        KrbFastReq ::= SEQUENCE {
-            fast-options [0] FastOptions,
-                -- Additional options.
-            padata       [1] SEQUENCE OF PA-DATA,
-                -- padata typed holes.
-            req-body     [2] KDC-REQ-BODY,
-                -- Contains the KDC request body as defined in Section
-                -- 5.4.1 of [RFC4120].
-                -- This req-body field is preferred over the outer field
-                -- in the KDC request.
-             ...
-        }
-
-   The fast-options field indicates various options that are to modify
-   the behavior of the KDC.  The following options are defined:
-
-        FastOptions ::= KerberosFlags
-            -- reserved(0),
-            -- hide-client-names(1),
-            -- kdc-follow-referrals(16)
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 28]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-     Bits    Name                    Description
-    -----------------------------------------------------------------
-     0     RESERVED              Reserved for future expansion of this
-                                 field.
-     1     hide-client-names     Requesting the KDC to hide client
-                                 names in the KDC response, as
-                                 described next in this section.
-     16    kdc-follow-referrals  Requesting the KDC to follow referrals.
-
-   Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are
-   critical options.  If the KDC does not support a critical option, it
-   MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and
-   there is no accompanying e-data defined in this document for this
-   error code.  Bit 16 and onward (with bit 16 included) are non-
-   critical options.  KDCs conforming to this specification ignore
-   unknown non-critical options.
-
-        KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
-
-   The hide-client-names Option
-
-      The Kerberos response defined in [RFC4120] contains the client
-      identity in clear text, This makes traffic analysis
-      straightforward.  The hide-client-names option is designed to
-      complicate traffic analysis.  If the hide-client-names option is
-      set, the KDC implementing PA-FX-FAST MUST identify the client as
-      the anonymous principal [KRB-ANON] in the KDC reply and the error
-      response.  Hence this option is set by the client if it wishes to
-      conceal the client identity in the KDC response.  A conforming KDC
-      ignores the client principal name in the outer KDC-REQ-BODY field,
-      and identifies the client using the cname and crealm fields in the
-      req-body field of the KrbFastReq structure.
-
-   The kdc-follow-referrals Option
-
-      The Kerberos client described in [RFC4120] has to request referral
-      TGTs along the authentication path in order to get a service
-      ticket for the target service.  The Kerberos client described in
-      the [REFERRALS] needs to contact the AS specified in the error
-      response in order to complete client referrals.  The kdc-follow-
-      referrals option is designed to minimize the number of messages
-      that need to be processed by the client.  This option is useful
-      when, for example, the client may contact the KDC via a satellite
-      link that has high network latency, or the client has limited
-      computational capabilities.  If the kdc-follow-referrals option is
-      set, the KDC MAY act as the client to follow TGS referrals
-      [REFERRALS], and return the service ticket to the named server
-      principal in the client request using the reply key expected by
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 29]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-      the client.  That is, rather than returning a referral, the KDC
-      follows that referral by contacting a remote KDC and processing
-      the referral.  The kdc-referrals option can be implemented when
-      the KDC knows the reply key.  The KDC can ignore kdc-referrals
-      option when it does not understand it or it does not allow this
-      option based on local policy.  The client SHOULD be capable of
-      processing the KDC responses when this option is not honored by
-      the KDC.  Clients SHOULD use TCP to contact a KDC if this option
-      is going to be used to avoid problems when the client's UDP
-      retransmit algorithm has timeouts insufficient to allow the KDC to
-      interact with remote KDCs.
-
-   The padata field contains a list of PA-DATA structures as described
-   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
-   FAST factors.  They can also be used as generic typed-holes to
-   contain data not intended for proving the client's identity or
-   establishing a reply key, but for protocol extensibility.  If the KDC
-   supports the PA-FX-FAST-REQUEST padata, unless otherwise specified,
-   the client MUST place any padata that is otherwise in the outer KDC
-   request body into this field.  In a TGS request, PA-TGS-REQ padata is
-   not included in this field and it is present in the outer KDC request
-   body.
-
-   The KDC-REQ-BODY in the FAST structure is used in preference to the
-   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-
-   REQ-BODY structure SHOULD be filled in for backwards compatibility
-   with KDCs that do not support FAST.  A conforming KDC ignores the
-   outer KDC-REQ-BODY field in the KDC request.  However pre-
-   authentication data methods such as [RFC4556] that include a checksum
-   of the KDC-REQ-BODY should checksum the outer KDC-REQ-BODY.  These
-   methods will already be bound to the inner body through the integrity
-   protection in the FAST request.
-
-   In a TGS request, a client MAY include the AD-fx-fast-used authdata
-   either in the pa-tgs-req authenticator or in the authorization data
-   in the pa-tgs-req ticket.  If the KDC receives this authorization
-   data but does not find a FAST padata then it MUST return
-   KRB_APP_ERR_MODIFIED.
-
-6.5.3.  FAST Response
-
-   The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST
-   padata element in the KDC reply.  In the case of an error, the PA-FX-
-   FAST padata is included in the KDC responses according to
-   Section 6.5.4.
-
-   The corresponding padata-value field [RFC4120] for the PA-FX-FAST in
-   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 30]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   FAST-REPLY.
-
-      PA-FX-FAST-REPLY ::= CHOICE {
-          armored-data [0] KrbFastArmoredRep,
-          ...
-      }
-
-      KrbFastArmoredRep ::= SEQUENCE {
-          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
-              -- The encryption key is the armor key in the request, and
-              -- the key usage number is KEY_USAGE_FAST_REP.
-          ...
-      }
-      KEY_USAGE_FAST_REP                 52
-
-   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
-   structure.  The KrbFastArmoredRep structure encapsulates the padata
-   in the KDC reply in the encrypted form.  The KrbFastResponse is
-   encrypted with the armor key used in the corresponding request, and
-   the key usage number is KEY_USAGE_FAST_REP.
-
-   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
-   KDC response MUST support a local policy that rejects the response.
-   Clients MAY also support policies that fall back to other mechanisms
-   or that do not use pre-authentication when FAST is unavailable.  It
-   is important to consider the potential downgrade attacks when
-   deploying such a policy.
-
-   The KrbFastResponse structure contains the following information:
-
-       KrbFastResponse ::= SEQUENCE {
-           padata         [0] SEQUENCE OF PA-DATA,
-               -- padata typed holes.
-           strengthen-key [1] EncryptionKey OPTIONAL,
-               -- This, if present, strengthens the reply key for AS and
-               -- TGS.
-               -- MUST be absent in KRB-ERROR.
-           finished       [2] KrbFastFinished OPTIONAL,
-               -- Present in AS or TGS reply; absent otherwise.
-           nonce          [3] UInt32,
-               -- Nonce from the client request.
-           ...
-  }
-
-   The padata field in the KrbFastResponse structure contains a list of
-   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
-   PA-DATA structures are used to carry data advancing the exchange
-   specific for the FAST factors.  They can also be used as generic
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 31]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   typed-holes for protocol extensibility.  Unless otherwise specified,
-   the KDC MUST include any padata that is otherwise in the outer KDC-
-   REP structure into this field.  The padata field in the KDC reply
-   structure outside of the PA-FX-FAST-REPLY structure typically
-   includes only the PA-FX- FAST-REPLY padata.
-
-   The strengthen-key field provides a mechanism for the KDC to
-   strengthen the reply key.  If set, the reply key is strengthened
-   after all padata items are processed.  Let padata-reply-key be the
-   reply key after padata processing.
-
-   reply-key = KRB-FX-CF2(strengthen-key, padata-reply-key,
-                         "strengthenkey", "replykey")
-
-   The strengthen-key field MAY be set in an AS or TGS reply; it must be
-   absent in an error reply.
-
-   The finished field contains a KrbFastFinished structure.  It is
-   filled by the KDC in the final message in the conversation.  This
-   field is present in an AS-REP or a TGS-REP when a ticket is returned,
-   and it is not present in an error reply.
-
-   The KrbFastFinished structure contains the following information:
-
-       KrbFastFinished ::= SEQUENCE {
-           timestamp       [0] KerberosTime,
-           usec            [1] Microseconds,
-               -- timestamp and usec represent the time on the KDC when
-               -- the reply was generated.
-           crealm          [2] Realm,
-           cname           [3] PrincipalName,
-               -- Contains the client realm and the client name.
-           ticket-checksum [4] Checksum,
-               -- checksum of the ticket in the KDC-REP  using the armor
-               -- and the key usage is KEY_USAGE_FAST_FINISH.
-               -- The checksum type is the required checksum type
-               -- of the armor key.
-           ...
-       }
-       KEY_USAGE_FAST_FINISHED            53
-
-   The timestamp and usec fields represent the time on the KDC when the
-   reply ticket was generated, these fields have the same semantics as
-   the corresponding-identically-named fields in Section 5.6.1 of
-   [RFC4120].  The client MUST use the KDC's time in these fields
-   thereafter when using the returned ticket.  Note that the KDC's time
-   in AS-REP may not match the authtime in the reply ticket if the kdc-
-   follow-referrals option is requested and honored by the KDC.  The
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 32]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   client need not confirm that the timestamp returned is within
-   allowable clock skew: the armor key guarantees that the reply is
-   fresh.  The client MAY trust the time stamp returned.
-
-   The cname and crealm fields identify the authenticated client.  If
-   facilities described in [REFERRALS] are used, the authenticated
-   client may differ from the client in the FAST request.
-
-   The ticket-checksum is a checksum of the issued ticket.  The checksum
-   key is the armor key, and the checksum type is the required checksum
-   type of the enctype of that key, and the key usage number is
-   KEY_USAGE_FAST_FINISHED.
-
-   When FAST padata is included, the PA-FX-COOKIE padata as defined in
-   Section 6.3 MUST be included in the padata sequence in the
-   KrbFastResponse sequence if the KDC expects at least one more message
-   from the client in order to complete the authentication.
-
-   The nonce field in the KrbFastResponse contains the value of the
-   nonce field in the KDC-REQ of the corresponding client request and it
-   binds the KDC response with the client request.  The client MUST
-   verify that this nonce value in the reply matches with that of the
-   request and reject the KDC reply otherwise.  To prevent the response
-   from one message in a conversation from being replayed to a request
-   in another message, clients SHOULD use a new nonce for each message
-   in a conversation.
-
-6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
-
-   If the Kerberos FAST padata was included in the request, unless
-   otherwise specified, the e-data field of the KRB-ERROR message
-   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
-   [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA.  The KDC
-   MUST include all the padata elements such as PA-ETYPE-INFO2 and
-   padata elements that indicate acceptable pre-authentication
-   mechanisms [RFC4120] in the KrbFastResponse structure.
-
-   The KDC MUST also include a PA-FX-ERROR padata item in the
-   KRBFastResponse structure.  The padata-value element of this sequence
-   is the ASN.1 DER encoding of the type KRB-ERROR.  The e-data field
-   MUST be absent in the PA-FX-ERROR padata.  All other fields should be
-   the same as the outer KRB-ERROR.  The client ignores the outer error
-   and uses the combination of the padata in the KRBFastResponse and the
-   error information in the PA-FX-ERROR.
-
-              PA-FX-ERROR                        137
-
-   If the Kerberos FAST padata is included in the request but not
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 33]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   included in the error reply, it is a matter of the local policy on
-   the client to accept the information in the error message without
-   integrity protection.  The client SHOULD however process the KDC
-   errors as the result of the KDC's inability to accept the AP_REQ
-   armor and potentially retry another request with a different armor
-   when applicable.  The Kerberos client MAY process an error message
-   without a PA-FX-FAST-REPLY, if that is only intended to return better
-   error information to the application, typically for trouble-shooting
-   purposes.
-
-   In the cases where the e-data field of the KRB-ERROR message is
-   expected to carry a TYPED-DATA [RFC4120] element, then that
-   information should be transmitted in a pa-data element within the
-   KRBFastResponse structure.  The padata-type is the same as the data-
-   type would be in the typed data element and the padata-value is the
-   same as the data-value.  As discussed in Section 8, data-types and
-   padata-types are drawn from the same namespace.  For example, the
-   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
-   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
-   [RFC4556].
-
-6.5.5.  Outer and Inner Requests
-
-   Typically, a client will know that FAST is being used before a
-   request containing PA-FX-FAST is sent.  So, the outer AS request
-   typically only includes one pa-data item: PA-FX-FAST.  The client MAY
-   include additional pa-data, but the KDC MUST ignore the outer request
-   body and any padata besides PA-FX-FAST if and only if PA-FX-FAST is
-   processed.  In the case of the TGS request, the outer request should
-   include PA-FX-FAST and PA-TGS-REQ.
-
-   When an AS generates a response, all padata besides PA-FX-FAST should
-   be included in PA-FX-FAST.  The client MUST ignore other padata
-   outside of PA-FX-FAST.
-
-6.5.6.  The Encrypted Challenge FAST Factor
-
-   The encrypted challenge FAST factor authenticates a client using the
-   client's long-term key.  This factor works similarly to the encrypted
-   time stamp pre-authentication option described in [RFC4120].  The
-   client encrypts a structure containing a timestamp in the challenge
-   key.  The challenge key used by the client to send a message to the
-   KDC is KRB-FX-CF2(armor_key,long_term_key, "clientchallengearmor",
-   "challengelongterm").  The challenge key used by the KDC encrypting
-   to the client is KRB-FX-CF2(armor_key, long_term_key,
-   "kdcchallengearmor", "challengelongterm").  Because the armor key is
-   fresh and random, the challenge key is fresh and random.  The only
-   purpose of the timestamp is to limit the validity of the
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 34]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   authentication so that a request cannot be replayed.  A client MAY
-   base the timestamp on the KDC time in a KDC error and need not
-   maintain accurate time synchronization itself.  If a client bases its
-   time on an untrusted source, an attacker may trick the client into
-   producing an authentication request that is valid at some future
-   time.  The attacker may be able to use this authentication request to
-   make it appear that a client has authenticated at that future time.
-   If ticket-based armor is used, then the lifetime of the ticket will
-   limit the window in which an attacker can make the client appear to
-   have authenticated.  For many situations, the ability of an attacker
-   to cause a client to appear to have authenticated is not a
-   significant concern; the ability to avoid requiring time
-   synchronization on clients is more valuable.
-
-   The client sends a padata of type PA-ENCRYPTED-CHALLENGE the
-   corresponding padata-value contains the DER encoding of ASN.1 type
-   EncryptedChallenge.
-
-      EncryptedChallenge ::= EncryptedData
-              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
-
-      PA-ENCRYPTED-CHALLENGE          138
-      KEY_USAGE_ENC_CHALLENGE_CLIENT  54
-      KEY_USAGE_ENC_CHALLENGE_KDC     55
-
-   The client includes some time stamp reasonably close to the KDC's
-   current time and encrypts it in the challenge key.  Clients MAY use
-   the current time; doing so prevents the exposure where an attacker
-   can cause a client to appear to authenticate in the future.  The
-   client sends the request including this factor.
-
-   On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE fast
-   factor, the KDC decrypts the timestamp.  If the decryption fails the
-   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in
-   the KRBFastResponse in the error.  The KDC confirms that the
-   timestamp falls within its current clock skew returning
-   KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see if the
-   encrypted challenge is a replay.  The KDC MUST NOT consider two
-   encrypted challenges replays simply because the time stamps are the
-   same; to be a replay, the ciphertext MUST be identical.  Allowing
-   clients to re-use time stamps avoids requiring that clients maintain
-   state about which time stamps have been used.
-
-   If the KDC accepts the encrypted challenge, it MUST include a padata
-   element of type PA-ENCRYPTED-CHALLENGE.  The KDC encrypts its current
-   time in the challenge key.  The KDC MUST strengthen the reply key
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 35]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   before issuing a ticket.  The client MUST check that the timestamp
-   decrypts properly.  The client MAY check that the timestamp is
-   winthin the window of acceptable clock skew for the client.  The
-   client MUST NOT require that the timestamp be identical to the
-   timestamp in the issued credentials or the returned message.
-
-   The encrypted challenge FAST factor provides the following
-   facilities: client-authentication and KDC authentication.  This FAST
-   factor also takes advantage of the FAST facility to strengthen the
-   reply key.  It does not provide the replacing-reply-key facility.
-   The security considerations section of this document provides an
-   explanation why the security requirements are met.
-
-   The encrypted challenge FAST factor can be useful in an
-   authentication set.  No pa-hint is defined because the only
-   information needed by this mechanism is information contained in the
-   PA-ETYPE-INFO2 pre-authentication data.  KDCs are already required to
-   send PA-ETYPE-INFO2.  If KDCs were not required to send PA-ETYPE-
-   INFO2 then that information would need to be part of a hint for
-   encrypted challenge.
-
-   Conforming implementations MUST support the encrypted challenge FAST
-   factor.
-
-6.6.  Authentication Strength Indication
-
-   Implementations that have pre-authentication mechanisms offering
-   significantly different strengths of client authentication MAY choose
-   to keep track of the strength of the authentication used as an input
-   into policy decisions.  For example, some principals might require
-   strong pre-authentication, while less sensitive principals can use
-   relatively weak forms of pre-authentication like encrypted timestamp.
-
-   An AuthorizationData data type AD-Authentication-Strength is defined
-   for this purpose.
-
-        AD-authentication-strength         70
-
-   The corresponding ad-data field contains the DER encoding of the pre-
-   authentication data set as defined in Section 6.4.  This set contains
-   all the pre-authentication mechanisms that were used to authenticate
-   the client.  If only one pre-authentication mechanism was used to
-   authenticate the client, the pre-authentication set contains one
-   element.
-
-   The AD-authentication-strength element MUST be included in the AD-IF-
-   RELEVANT, thus it can be ignored if it is unknown to the receiver.
-
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 36]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-7.  Assigned Constants
-
-   The pre-authentication framework and FAST involve using a number of
-   Kerberos protocol constants.  This section lists protocol constants
-   first introduced in this specification drawn from registries not
-   managed by IANA.  Many of these registries would best be managed by
-   IANA; that is a known issue that is out of scope for this document.
-   The constants described in this section have been accounted for and
-   will appear in the next revision of the Kerberos core specification
-   or in a document creating IANA registries.
-
-   Section 8 creates IANA registries for a different set of constants
-   used by the extensions described in this document.
-
-7.1.  New Errors
-
-           KDC_ERR_PREAUTH_EXPIRED                 90
-           KDC_ERR_MORE_PREAUTH_DATA_NEEDED        91
-           KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET  92
-           KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
-
-7.2.  Key Usage Numbers
-
-           KEY_USAGE_FAST_REQ_CHKSUM               50
-           KEY_USAGE_FAST_ENC                      51
-           KEY_USAGE_FAST_REP                      52
-           KEY_USAGE_FAST_FINISHED                 53
-           KEY_USAGE_ENC_CHALLENGE_CLIENT          54
-           KEY_USAGE_ENC_CHALLENGE_KDC             55
-
-7.3.  Authorization Data Elements
-
-           AD-authentication-strength              70
-           AD-fx-fast-armor                        71
-           AD-fx-fast-used                         72
-
-7.4.  New PA-DATA Types
-
-           PA-FX-COOKIE                            133
-           PA-AUTHENTICATION-SET                   134
-           PA-AUTH-SET-SELECTED                    135
-           PA-FX-FAST                              136
-           PA-FX-ERROR                             137
-           PA-ENCRYPTED-CHALLENGE                  138
-
-
-
-
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 37]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-8.  IANA Considerations
-
-   This document creates a number of IANA registries.  These registries
-   should all be located under
-   http://www.iana.org/assignments/kerberos-parameters.
-
-8.1.  Pre-authentication and Typed Data
-
-   RFC 4120 defines pre-authentication data, which can be included in a
-   KDC request or response in order to authenticate the client or extend
-   the protocol.  In addition, it defines Typed-Data which is an
-   extension mechanism for errors.  Both pre-authentication data and
-   typed data are carried as a 32-bit signed integer along with an octet
-   string.  The encoding of typed data and pre-authentication data is
-   slightly different.  However the types for pre-authentication data
-   and typed-data are drawn from the same namespace.  By convention,
-   registrations starting with TD- are typed data and registration
-   starting with PA- are pre-authentication data.  It is important that
-   these data types be drawn from the same namespace, because some
-   errors where it would be desirable to include typed data require the
-   e-data field to be formatted as pre-authentication data.
-
-   When Kerberos FAST is used, pre-authentication data encoding is
-   always used.
-
-   There is one apparently conflicting registration between typed data
-   and pre-authentication data.  PA-GET-FROM-TYPED-DATA and TD-PADATA
-   are both assigned the value 22.  However this registration is simply
-   a mechanism to include an element of the other encoding.  The use of
-   both should be deprecated.
-
-   This document creates a registry for pre-authentication and typed
-   data.  The registration procedures are as follows.  Expert review for
-   pre-authentication mechanisms designed to authenticate users, KDCs,
-   or establish the reply key.  The expert first determines that the
-   purpose of the method is to authenticate clients, KDCs, or to
-   establish the reply key.  If so, expert review is appropriate.  The
-   expert evaluates the security and interoperability of the
-   specification.
-
-   IETF review is required if the expert believes that the pre-
-   authentication method is broader than these three areas.  Pre-
-   authentication methods that change the Kerberos state machine or
-   otherwise make significant changes to the Kerberos protocol should be
-   standards track RFCs.  A concern that a particular method needs to be
-   a standards track RFC may be raised as an objection during IETF
-   review.
-
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 38]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-      Type                Value    Reference
-  ----------------------------------------------------------------------
-  PA-TGS-REQ                 1    RFC 4120
-  PA-ENC-TIMESTAMP           2    RFC 4120
-  PA-PW-SALT                 3    RFC 4120
-  [reserved]                 4
-  PA-ENC-UNIX-TIME           5    (deprecated)
-  PA-SANDIA-SECUREID         6
-  PA-SESAME                  7
-  PA-OSF-DCE                 8
-  PA-CYBERSAFE-SECUREID      9
-  PA-AFS3-SALT               10
-  PA-ETYPE-INFO              11   RFC 4120
-  PA-SAM-CHALLENGE           12   (sam/otp)
-  PA-SAM-RESPONSE            13   (sam/otp)
-  PA-PK-AS-REQ_OLD           14   draft-ietf-cat-kerberos-pk-init-09
-  PA-PK-AS-REP_OLD           15   draft-ietf-cat-kerberos-pk-init-09
-  PA-PK-AS-REQ               16   RFC 4556
-  PA-PK-AS-REP               17   RFC 4556
-  PA-PK-OCSP-RESPONSE        18   RFC 4557
-  PA-ETYPE-INFO2             19   RFC 4120
-  PA-USE-SPECIFIED-KVNO      20
-  PA-SVR-REFERRAL-INFO       20   (referrals)
-  PA-SAM-REDIRECT            21   (sam/otp)
-  PA-GET-FROM-TYPED-DATA     22   (embedded in typed data)
-  TD-PADATA                  22   (embeds padata)
-  PA-SAM-ETYPE-INFO          23   (sam/otp)
-  PA-ALT-PRINC               24   (crawdad@fnal.gov)
-  PA-SERVER-REFERRAL         25   (referrals)
-  PA-SAM-CHALLENGE2          30   (kenh@pobox.com)
-  PA-SAM-RESPONSE2           31   (kenh@pobox.com)
-  PA-EXTRA-TGT               41   Reserved extra TGT
-  TD-PKINIT-CMS-CERTIFICATES 101  CertificateSet from CMS
-  TD-KRB-PRINCIPAL           102  PrincipalName
-  TD-KRB-REALM               103  Realm
-  TD-TRUSTED-CERTIFIERS      104  PKINIT
-  TD-CERTIFICATE-INDEX       105  PKINIT
-  TD-APP-DEFINED-ERROR       106  Application specific
-  TD-REQ-NONCE               107  INTEGER
-  TD-REQ-SEQ                 108  INTEGER
-  PA-PAC-REQUEST             128  MS-KILE
-  PA-FOR_USER                129  MS-KILE
-  PA-FOR-X509-USER           130  MS-KILE
-  PA-FOR-CHECK_DUPS          131  MS-KILE
-  PA-AS-CHECKSUM             132  MS-KILE
-  PA-FX-COOKIE               133  draft-ietf-krb-wg-preauth-framework
-  PA-AUTHENTICATION-SET      134  draft-ietf-krb-wg-preauth-framework
-  PA-AUTH-SET-SELECTED       135  draft-ietf-krb-wg-preauth-framework
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 39]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-  PA-FX-FAST                 136  draft-ietf-krb-wg-preauth-framework
-  PA-FX-ERROR                137  draft-ietf-krb-wg-preauth-framework
-  PA-ENCRYPTED-CHALLENGE     138  draft-ietf-krb-wg-preauth-framework
-  PA-OTP-CHALLENGE           141  (gareth.richards@rsa.com)
-  PA-OTP-REQUEST             142  (gareth.richards@rsa.com)
-  PA-OTP-CONFIRM             143  (gareth.richards@rsa.com)
-  PA-OTP-PIN-CHANGE          144  (gareth.richards@rsa.com)
-  PA-EPAK-AS-REQ             145  (sshock@gmail.com)
-  PA-EPAK-AS-REP             146  (sshock@gmail.com>)
-  PA_PKINIT_KX               147  draft-ietf-krb-wg-anon
-  PA_PKU2U_NAME              148  draft-zhu-pku2u
-  PA-SUPPORTED-ETYPES        165  MS-KILE
-  PA-EXTENDED_ERROR          166  MS-KILE
-
-8.2.  Fast Armor Types
-
-   FAST armor types are defined in Section 6.5.1.  A FAST armor type is
-   a signed 32-bit integer.  FAST armor types are assigned by standards
-   action.
-
-          Type    Name                   Description
-        ------------------------------------------------------------
-          0                              Reserved.
-          1   FX_FAST_ARMOR_AP_REQUEST   Ticket armor using an ap-req.
-
-8.3.  FAST Options
-
-   A FAST request includes a set of bit flags to indicate additional
-   options.  Bits 0-15 are critical; other bits are non-critical.
-   Assigning bits greater than 31 may require special support in
-   implementations.  Assignment of FAST options requires standards
-   action.
-
-      Type    Name                   Description
-     -------------------------------------------------------------------
-      0     RESERVED               Reserved for future expansion of this
-                                   field.
-      1     hide-client-names      Requesting the KDC to hide client
-                                   names in  the KDC response
-      16    kdc-follow-referrals   Requesting the KDC to follow
-                                   referrals
-
-
-9.  Security Considerations
-
-   The kdc-referrals option in the Kerberos FAST padata requests the KDC
-   to act as the client to follow referrals.  This can overload the KDC.
-   To limit the damages of denied of service using this option, KDCs MAY
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 40]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   restrict the number of simultaneous active requests with this option
-   for any given client principal.
-
-   With regarding to the facilities provided by the Encrypted Challenge
-   FAST factor, the challenge key is derived from the client secrets and
-   because the client secrets are known only to the client and the KDC,
-   the verification of the EncryptedChallenge structure proves the
-   client's identity, the verification of the EncryptedChallenge
-   structure in the KDC reply proves that the expected KDC responded.
-   Therefore, the Encrypted Challenge FAST factor as a pre-
-   authentication mechanism offers the following facilities: client-
-   authentication and KDC-authentication.  There is no un-authenticated
-   clear text introduced by the Encrypted Challenge FAST factor.
-
-
-10.  Acknowledgements
-
-   Sam Hartman would like to thank the MIT Kerberos Consortium for its
-   funding of his time on this project.
-
-   Several suggestions from Jeffrey Hutzelman based on early revisions
-   of this documents led to significant improvements of this document.
-
-   The proposal to ask one KDC to chase down the referrals and return
-   the final ticket is based on requirements in [ID.CROSS].
-
-   Joel Webber had a proposal for a mechanism similar to FAST that
-   created a protected tunnel for Kerberos pre-authentication.
-
-   Srinivas Cheruku and Greg Hudson provided valuable review comments.
-
-
-11.  References
-
-11.1.  Normative References
-
-   [KRB-ANON]
-              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
-              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 41]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-              July 2005.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-11.2.  Informative References
-
-   [ID.CROSS]
-              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
-              Statement on the Operation of Kerberos in a Specific
-              System", draft-sakane-krb-cross-problem-statement-02.txt
-              (work in progress), April 2007.
-
-   [KRB-WG.SAM]
-              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
-              "Integrating Single-use Authentication Mechanisms with
-              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
-              progress), October 2003.
-
-   [REFERRALS]
-              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
-              Locate Kerberos Realms",
-              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
-              progress), 2007.
-
-
-Appendix A.  Test Vectors for KRB-FX-CF2
-
-   This informative appendix presents test vectors for the KRB-FX-CF2
-   function.  Test vectors are presented for several encryption types.
-   In all cases the first key (k1) is the result of string-to-
-   key("key1", "key1", default_parameters) and the second key (k2) is
-   the result of string-to-key("key2", "key2", default_parameters).
-   Both keys are of the same enctype.  The presented test vector is the
-   hexadecimal encoding of the key produced by KRB-FX-CF2(k1, k2, "a",
-   "b").  The peppers are one-octet ASCII strings.
-
-   In performing interoperability testing, there was significant
-   ambiguity surrounding [RFC3961] pseudo-random operations.  These test
-   vectors assume that the AES pseudo-random operation is aes-
-   ecb(trunc128(sha-1(input))) where trunc128 truncates its input to
-   128-bits.  The 3DES pseudo-random operation is assumed to be des3-
-   cbc(trunc128(sha-1(input))).  The DES pseudo-random operation is
-   assumed to be des-cbc(md5(input).  As specified in RFC 4757, the RC4
-   pseudo-random operation is hmac-sha1(input).
-
-   These test vectors were produced with revision 22359 of the MIT
-   Kerberos sources.  The AES 256 and AES 128 test vectors have been
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 42]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-   confirmed by another implementer.  The RC4 implementation of KRB-FX-
-   CF2 from that revision of MIT Kerberos worked against another
-   implementation during an interoperability event, although these
-   specific test vectors have not been confirmed.  The DES and triple
-   DES test vectors have not been confirmed.
-
-
-   aes 128 (enctype 17): 97df97e4b798b29eb31ed7280287a92a
-   AES256 (enctype 18): 4d6ca4e629785c1f01baf55e2e548566
-                        b9617ae3a96868c337cb93b5e72b1c7b
-   DES (enctype 1): 43bae3738c9467e6
-   3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01
-   RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672
-
-
-Appendix B.  Change History
-
-   RFC editor, please remove this section before publication.
-
-B.1.  Changes since 10
-
-      The checksum member of the KrbFastFinished sequence has been
-      removed.  A nonce field has been added to KrbFastResponse.
-      The cookie no longer needs to be outside of FAST.  In fact, some
-      security guarantees depend on the cookie being inside FAST now
-      that the finish checksum has been removed.  Affected that change.
-      Replace the rep-key field in KrbFastResponse with the strengthen-
-      key field.  Per mailing list discussion, there are security
-      advantages to strengthening the reply key.
-      Clarify handling of authentication sets.
-      Include the AD-fx-fast-used authorization data type.
-      Include note about random nonces.
-
-B.2.  Changes since 09
-
-      Clarify conversations by defining for TGS and by describing how
-      cookies form conversation boundaries.
-      Simplify text surrounding when finish is included: always for AS
-      and TGS reply, never for error.
-      Fill in IANA and constants
-
-B.3.  Changes since 08
-
-      Fix a number of typos
-      Rename anonymous flag to hide-client-name; rename kdc-referals to
-      kdc-follow-referrals
-
-
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 43]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-      Clarify how anonymous pkinit interacts with KDC verified.
-      Introduce AD-fx-fast-armor authorization data to deal with
-      unprivileged processes constructing KDC requests.  Note that a TGT
-      is always used for armor tickets if the armor field is present; if
-      you proxy or validate you'll end up with a TGT armor ticket and
-      another ticket in the pa-tgs-req.  Alternatively you can simply
-      use the other ticket in the PA-TGS-REQ; weak consensus within WG.
-      All KDCs in a realm MUST support FAST if it is to be offered.
-      The cookie message is always generated by the KDC.
-      Note that the client can trust and need not verify the time stamp
-      in the finish message.  This can seed the client's idea of KDC
-      time.
-      Note that the client name in the finish message may differ from
-      the name in the request if referrals are used.
-      Note that KDCs should advertize fast in preauth_required errors.
-      Armor key is constructed using KRB-FX-CF2.  This is true even in
-      the TGS case; there is no security reason to do this.  Using the
-      subkey as done in draft 08 would be fine, but the current text
-      uses the same procedure both in the TGS and AS case.
-      Use a different challenge key in each direction in the encrypted
-      challenge option.
-      Note that the KDC should process PA-FX-COOKIE before other padata.
-      KRB-FX-CF2 uses k1's enctype for the result; change around calling
-      order so we pass in subkeys and armor keys as k1 in preference to
-      long-term keys or ticket session keys.
-      Clarify the relationship between authentication sets and cookies.
-      A cookie may not be needed in the first message.  Clarify how this
-      interacts with optimistic clients.
-      Remove text raising a concern that RFC 3961 may permit ciphertext
-      transformations that do not change plaintext: discussion on the
-      list came to the conclusion that RFC 3961 does not permit this.
-      Remove binding key concept; use the armor key instead.  The cookie
-      becomes just an octet string.
-      Include PA-FX-ERROR to protect the error information per Dublin.
-      Returning preauth_failed in the failed to decrypt encrypted
-      challenge seems fine; remove the issue marker
-      Add a section describing what goes in the inner and outer request.
-      I believe it is redundant but found it useful while putting
-      together an implementation proposal.
-      Use hyphen rather than underscore in the constants for pre-
-      authentication data to be consistent with RFC 4120.
-      Add a ticket-checksum to the finished message
-      Remove redundant KEY_USAGE_FAST_ARMOR.
-      Add protocol constants section for non-IANA registrations and
-      flesh out IANA section.
-      Clarify that kdc-req-body checksums should always use the outer
-      body even for mechanisms like PKINIT that include their own (now
-      redundant) checksum.
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 44]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-      Remove mechanism for encapsulating typed data in padata; just
-      reflect the value.
-
-B.4.  Changes since 07
-
-      Propose replacement of authenticated timestamp with encrypted
-      challenge.  The desire to avoid clients needing time
-      synchronization and to simply the factor.
-      Add a requirement that any FAST armor scheme must provide a fresh
-      key for each conversation.  This allows us to assume that anything
-      encrypted/integrity protected in the right key is fresh and not
-      subject to cross-conversation cut and paste.
-      Removed heartbeat padata.  The KDC will double up messages if it
-      needs to; the client simply sends its message and waits for the
-      next response.
-      Define PA-AUTH-SET-SELECTED
-      Clarify a KDC cannot ignore padata is has claimed to support
-
-B.5.  Changes since 06
-
-      Note that even for replace reply key it is likely that the side
-      using the mechanism will know that the other side supports it.
-      Since it is reasonably unlikely we'll need a container mechanism
-      other than FAST itself, we don't need to optimize for that case.
-      So, we want to optimize for implementation simplicity.  Thus if
-      you do have such a container mechanism interacting with
-      authentication sets we'll assume that the hint need to describe
-      hints for all contained mechanisms.  This closes out a long-
-      standing issue.
-      Write up what Sam believes is the consensus on UI and prompts in
-      the authentication set: clients MAY assume that they have all the
-      UI information they need.
-
-
-Appendix C.  ASN.1 module
-
-      KerberosPreauthFramework {
-            iso(1) identified-organization(3) dod(6) internet(1)
-            security(5) kerberosV5(2) modules(4) preauth-framework(3)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      IMPORTS
-           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
-           Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
-           Microseconds, KerberosFlags
-                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                  dod(6) internet(1) security(5) kerberosV5(2)
-                  modules(4) krb5spec2(2) };
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 45]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-                  -- as defined in RFC 4120.
-
-
-      PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-      PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-          pa-type      [0] Int32,
-              -- same as padata-type.
-          pa-hint      [1] OCTET STRING OPTIONAL,
-          pa-value     [2] OCTET STRING OPTIONAL,
-          ...
-      }
-
-      KrbFastArmor ::= SEQUENCE {
-          armor-type   [0] Int32,
-              -- Type of the armor.
-          armor-value  [1] OCTET STRING,
-              -- Value of the armor.
-          ...
-      }
-
-      PA-FX-FAST-REQUEST ::= CHOICE {
-          armored-data [0] KrbFastArmoredReq,
-          ...
-      }
-
-      KrbFastArmoredReq ::= SEQUENCE {
-          armor        [0] KrbFastArmor OPTIONAL,
-              -- Contains the armor that identifies the armor key.
-              -- MUST be present in AS-REQ.
-          req-checksum [1] Checksum,
-              -- For AS, contains the checksum performed over the type
-              -- KDC-REQ-BODY for the req-body field of the KDC-REQ
-              -- structure;
-              -- For TGS, contains the checksum performed over the type
-              -- AP-REQ in the PA-TGS-REQ padata.
-              -- The checksum key is the armor key, the checksum
-              -- type is the required checksum type for the enctype of
-              -- the armor key, and the key usage number is
-              -- KEY_USAGE_FAST_REQ_CHKSUM.
-          enc-fast-req [2] EncryptedData, -- KrbFastReq --
-              -- The encryption key is the armor key, and the key usage
-              -- number is KEY_USAGE_FAST_ENC.
-          ...
-      }
-
-      KrbFastReq ::= SEQUENCE {
-          fast-options [0] FastOptions,
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 46]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-              -- Additional options.
-          padata       [1] SEQUENCE OF PA-DATA,
-              -- padata typed holes.
-          req-body     [2] KDC-REQ-BODY,
-              -- Contains the KDC request body as defined in Section
-              -- 5.4.1 of [RFC4120].
-              -- This req-body field is preferred over the outer field
-              -- in the KDC request.
-           ...
-      }
-
-      FastOptions ::= KerberosFlags
-          -- reserved(0),
-          -- hide-client-names(1),
-          -- kdc-follow-referrals(16)
-
-      PA-FX-FAST-REPLY ::= CHOICE {
-          armored-data [0] KrbFastArmoredRep,
-          ...
-      }
-
-      KrbFastArmoredRep ::= SEQUENCE {
-          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
-              -- The encryption key is the armor key in the request, and
-              -- the key usage number is KEY_USAGE_FAST_REP.
-          ...
-      }
-
-      KrbFastResponse ::= SEQUENCE {
-          padata         [0] SEQUENCE OF PA-DATA,
-              -- padata typed holes.
-          strengthen-key [1] EncryptionKey OPTIONAL,
-              -- This, if present, strengthens the reply key for AS and
-              -- TGS.
-              -- MUST be absent in KRB-ERROR.
-          finished       [2] KrbFastFinished OPTIONAL,
-              -- Present in AS or TGS reply; absent otherwise.
-          nonce          [3] UInt32,
-              -- Nonce from the client request.
-          ...
-      }
-
-      KrbFastFinished ::= SEQUENCE {
-          timestamp       [0] KerberosTime,
-          usec            [1] Microseconds,
-              -- timestamp and usec represent the time on the KDC when
-              -- the reply was generated.
-          crealm          [2] Realm,
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 47]
-
-Internet-Draft         Kerberos Preauth Framework               May 2009
-
-
-          cname           [3] PrincipalName,
-              -- Contains the client realm and the client name.
-          ticket-checksum [4] Checksum,
-              -- checksum of the ticket in the KDC-REP  using the armor
-              -- and the key usage is KEY_USAGE_FAST_FINISH.
-              -- The checksum type is the required checksum type
-              -- of the armor key.
-          ...
-      }
-
-      EncryptedChallenge ::= EncryptedData
-              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
-      END
-
-
-Authors' Addresses
-
-   Sam hartman
-   Painless Security
-
-   Email: hartmans-ietf@mit.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires November 21, 2009              [Page 48]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-12.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-12.txt
deleted file mode 100644
index 3b5cbd6be..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-12.txt
+++ /dev/null
@@ -1,2745 +0,0 @@
-
-
-
-Kerberos Working Group                                        S. Hartman
-Internet-Draft                                         Painless Security
-Updates: 4120 (if approved)                                       L. Zhu
-Intended status: Standards Track                   Microsoft Corporation
-Expires: December 6, 2009                                   June 4, 2009
-
-
-        A Generalized Framework for Kerberos Pre-Authentication
-                 draft-ietf-krb-wg-preauth-framework-12
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on December 6, 2009.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   Kerberos is a protocol for verifying the identity of principals
-   (e.g., a workstation user or a network server) on an open network.
-
-
-
-Hartman & Zhu           Expires December 6, 2009                [Page 1]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   The Kerberos protocol provides a mechanism called pre-authentication
-   for proving the identity of a principal and for better protecting the
-   long-term secrets of the principal.
-
-   This document describes a model for Kerberos pre-authentication
-   mechanisms.  The model describes what state in the Kerberos request a
-   pre-authentication mechanism is likely to change.  It also describes
-   how multiple pre-authentication mechanisms used in the same request
-   will interact.
-
-   This document also provides common tools needed by multiple pre-
-   authentication mechanisms.  One of these tools is a secure channel
-   between the client and the KDC with a reply key delivery mechanism;
-   this secure channel can be used to protect the authentication
-   exchange thus eliminate offline dictionary attacks.  With these
-   tools, it is relatively straightforward to chain multiple
-   authentication mechanisms, utilize a different key management system,
-   or support a new key agreement algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009                [Page 2]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Conventions and Terminology Used in This Document  . . . . . .  6
-   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  6
-     3.1.  Information Managed by the Pre-authentication Model  . . .  7
-     3.2.  Initial Pre-authentication Required Error  . . . . . . . .  9
-     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . . 10
-     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 11
-   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 12
-     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 13
-     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 14
-     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 15
-     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 15
-   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 15
-   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 16
-     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 17
-     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 18
-     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 19
-     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 20
-     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 23
-       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 24
-       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 26
-       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 30
-       6.5.4.  Authenticated Kerberos Error Messages using
-               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 33
-       6.5.5.  Outer and Inner Requests . . . . . . . . . . . . . . . 34
-       6.5.6.  The Encrypted Challenge FAST Factor  . . . . . . . . . 34
-     6.6.  Authentication Strength Indication . . . . . . . . . . . . 36
-   7.  Assigned Constants . . . . . . . . . . . . . . . . . . . . . . 37
-     7.1.  New Errors . . . . . . . . . . . . . . . . . . . . . . . . 37
-     7.2.  Key Usage Numbers  . . . . . . . . . . . . . . . . . . . . 37
-     7.3.  Authorization Data Elements  . . . . . . . . . . . . . . . 37
-     7.4.  New PA-DATA Types  . . . . . . . . . . . . . . . . . . . . 37
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
-     8.1.  Pre-authentication and Typed Data  . . . . . . . . . . . . 38
-     8.2.  Fast Armor Types . . . . . . . . . . . . . . . . . . . . . 40
-     8.3.  FAST Options . . . . . . . . . . . . . . . . . . . . . . . 40
-   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 40
-   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 42
-     11.2. Informative References . . . . . . . . . . . . . . . . . . 42
-   Appendix A.  Test Vectors for KRB-FX-CF2 . . . . . . . . . . . . . 43
-   Appendix B.  Change History  . . . . . . . . . . . . . . . . . . . 44
-     B.1.  Changes since 11 . . . . . . . . . . . . . . . . . . . . . 44
-     B.2.  Changes since 10 . . . . . . . . . . . . . . . . . . . . . 44
-     B.3.  Changes since 09 . . . . . . . . . . . . . . . . . . . . . 44
-
-
-
-Hartman & Zhu           Expires December 6, 2009                [Page 3]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-     B.4.  Changes since 08 . . . . . . . . . . . . . . . . . . . . . 44
-     B.5.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 46
-     B.6.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 46
-   Appendix C.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 46
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009                [Page 4]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-1.  Introduction
-
-   The core Kerberos specification [RFC4120] treats pre-authentication
-   data as an opaque typed hole in the messages to the KDC that may
-   influence the reply key used to encrypt the KDC reply.  This
-   generality has been useful: pre-authentication data is used for a
-   variety of extensions to the protocol, many outside the expectations
-   of the initial designers.  However, this generality makes designing
-   more common types of pre-authentication mechanisms difficult.  Each
-   mechanism needs to specify how it interacts with other mechanisms.
-   Also, problems like combining a key with the long-term secrets or
-   proving the identity of the user are common to multiple mechanisms.
-   Where there are generally well-accepted solutions to these problems,
-   it is desirable to standardize one of these solutions so mechanisms
-   can avoid duplication of work.  In other cases, a modular approach to
-   these problems is appropriate.  The modular approach will allow new
-   and better solutions to common pre-authentication problems to be used
-   by existing mechanisms as they are developed.
-
-   This document specifies a framework for Kerberos pre-authentication
-   mechanisms.  It defines the common set of functions that pre-
-   authentication mechanisms perform as well as how these functions
-   affect the state of the request and reply.  In addition several
-   common tools needed by pre-authentication mechanisms are provided.
-   Unlike [RFC3961], this framework is not complete--it does not
-   describe all the inputs and outputs for the pre-authentication
-   mechanisms.  Pre-Authentication mechanism designers should try to be
-   consistent with this framework because doing so will make their
-   mechanisms easier to implement.  Kerberos implementations are likely
-   to have plugin architectures for pre-authentication; such
-   architectures are likely to support mechanisms that follow this
-   framework plus commonly used extensions.  This framework also
-   facilitates combining multiple pre-authentication mechanisms, each of
-   which may represent an authentication factor, into a single multi-
-   factor pre-authentication mechanism.
-
-   One of these common tools is the flexible authentication secure
-   tunneling (FAST) padata type.  FAST provides a protected channel
-   between the client and the KDC, and it can optionally deliver a reply
-   key within the protected channel.  Based on FAST, pre-authentication
-   mechanisms can extend Kerberos with ease, to support, for example,
-   password authenticated key exchange (PAKE) protocols with zero
-   knowledge password proof (ZKPP) [EKE] [IEEE1363.2].  Any pre-
-   authentication mechanism can be encapsulated in the FAST messages as
-   defined in Section 6.5.  A pre-authentication type carried within
-   FAST is called a FAST factor.  Creating a FAST factor is the easiest
-   path to create a new pre-authentication mechanism.  FAST factors are
-   significantly easier to analyze from a security standpoint than other
-
-
-
-Hartman & Zhu           Expires December 6, 2009                [Page 5]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   pre-authentication mechanisms.
-
-   Mechanism designers should design FAST factors, instead of new pre-
-   authentication mechanisms outside of FAST.
-
-
-2.  Conventions and Terminology Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   This document should be read only after reading the documents
-   describing the Kerberos cryptography framework [RFC3961] and the core
-   Kerberos protocol [RFC4120].  This document may freely use
-   terminology and notation from these documents without reference or
-   further explanation.
-
-   The word padata is used as a shorthand for pre-authentication data.
-
-   A conversation is the set of all authentication messages exchanged
-   between the client and the client's Authentication Service (AS) in
-   order to authenticate the client principal.  A conversation as
-   defined here consists of all messages that are necessary to complete
-   the authentication between the client and the client's AS.  In the
-   Ticket Exchange Service (TGS) exchange, a conversation consists of
-   the request message and the reply message.  The term conversation is
-   defined here for both AS and TGS for convenience of discussion.  See
-   Section 6.3 for specific rules on the extent of a conversation in the
-   AS-REQ case.  Prior to this framework, implementations needed to use
-   implementation-specific heuristics to determine the extent of a
-   conversation.
-
-   If the KDC reply in an AS exchange is verified, the KDC is
-   authenticated by the client.  In this document, verification of the
-   KDC reply is used as a synonym of authentication of the KDC.
-
-
-3.  Model for Pre-Authentication
-
-   When a Kerberos client wishes to obtain a ticket using the
-   authentication server, it sends an initial Authentication Service
-   (AS) request.  If pre-authentication is required but not being used,
-   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
-   Alternatively, if the client knows what pre-authentication to use, it
-   MAY optimize away a round-trip and send an initial request with
-   padata included in the initial request.  If the client includes the
-   padata computed using the wrong pre-authentication mechanism or
-
-
-
-Hartman & Zhu           Expires December 6, 2009                [Page 6]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
-   indication of what padata should have been included.  In that case,
-   the client MUST retry with no padata and examine the error data of
-   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
-   authentication information in the accompanying error data of
-   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
-   then retry.
-
-   The conventional KDC maintains no state between two requests;
-   subsequent requests may even be processed by a different KDC.  On the
-   other hand, the client treats a series of exchanges with KDCs as a
-   single conversation.  Each exchange accumulates state and hopefully
-   brings the client closer to a successful authentication.
-
-   These models for state management are in apparent conflict.  For many
-   of the simpler pre-authentication scenarios, the client uses one
-   round trip to find out what mechanisms the KDC supports.  Then the
-   next request contains sufficient pre-authentication for the KDC to be
-   able to return a successful reply.  For these simple scenarios, the
-   client only sends one request with pre-authentication data and so the
-   conversation is trivial.  For more complex conversations, the KDC
-   needs to provide the client with a cookie to include in future
-   requests to capture the current state of the authentication session.
-   Handling of multiple round-trip mechanisms is discussed in
-   Section 6.3.
-
-   This framework specifies the behavior of Kerberos pre-authentication
-   mechanisms used to identify users or to modify the reply key used to
-   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
-   extensions to Kerberos that have nothing to do with proving the
-   identity of the user or establishing a reply key.  Such extensions
-   are outside the scope of this framework.  However mechanisms that do
-   accomplish these goals should follow this framework.
-
-   This framework specifies the minimum state that a Kerberos
-   implementation needs to maintain while handling a request in order to
-   process pre-authentication.  It also specifies how Kerberos
-   implementations process the padata at each step of the AS request
-   process.
-
-3.1.  Information Managed by the Pre-authentication Model
-
-   The following information is maintained by the client and KDC as each
-   request is being processed:
-
-   o  The reply key used to encrypt the KDC reply
-
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009                [Page 7]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   o  How strongly the identity of the client has been authenticated
-
-   o  Whether the reply key has been used in this conversation
-
-   o  Whether the reply key has been replaced in this conversation
-
-   o  Whether the contents of the KDC reply can be verified by the
-      client principal
-
-
-   Conceptually, the reply key is initially the long-term key of the
-   principal.  However, principals can have multiple long-term keys
-   because of support for multiple encryption types, salts and
-   string2key parameters.  As described in Section 5.2.7.5 of the
-   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
-   the client what types of keys are available.  Thus in full
-   generality, the reply key in the pre-authentication model is actually
-   a set of keys.  At the beginning of a request, it is initialized to
-   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
-   the KDC.  If multiple reply keys are available, the client chooses
-   which one to use.  Thus the client does not need to treat the reply
-   key as a set.  At the beginning of a request, the client picks a key
-   to use.
-
-   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
-   INFO2 element.  Since the KDC already knows the client's list of
-   supported enctypes from the request, no interoperability problems are
-   created by choosing a single possible reply key.  This way, the KDC
-   implementation avoids the complexity of treating the reply key as a
-   set.
-
-   When the padata in the request is verified by the KDC, then the
-   client is known to have that key, therefore the KDC SHOULD pick the
-   same key as the reply key.
-
-   At the beginning of handling a message on both the client and the
-   KDC, the client's identity is not authenticated.  A mechanism may
-   indicate that it has successfully authenticated the client's
-   identity.  This information is useful to keep track of on the client
-   in order to know what pre-authentication mechanisms should be used.
-   The KDC needs to keep track of whether the client is authenticated
-   because the primary purpose of pre-authentication is to authenticate
-   the client identity before issuing a ticket.  The handling of
-   authentication strength using various authentication mechanisms is
-   discussed in Section 6.6.
-
-   Initially the reply key has not been used.  A pre-authentication
-   mechanism that uses the reply key to encrypt or checksum some data in
-
-
-
-Hartman & Zhu           Expires December 6, 2009                [Page 8]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   the generation of new keys MUST indicate that the reply key is used.
-   This state is maintained by the client and the KDC to enforce the
-   security requirement stated in Section 4.3 that the reply key SHOULD
-   NOT be replaced after it is used.
-
-   Initially the reply key has not been replaced.  If a mechanism
-   implements the Replace Reply Key facility discussed in Section 4.3,
-   then the state MUST be updated to indicate that the reply key has
-   been replaced.  Once the reply key has been replaced, knowledge of
-   the reply key is insufficient to authenticate the client.  The reply
-   key is marked replaced in exactly the same situations as the KDC
-   reply is marked as not being verified to the client principal.
-   However, while mechanisms can verify the KDC reply to the client,
-   once the reply key is replaced, then the reply key remains replaced
-   for the remainder of the conversation.
-
-   Without pre-authentication, the client knows that the KDC reply is
-   authentic and has not been modified because it is encrypted in a
-   long-term key of the client.  Only the KDC and the client know that
-   key.  So at the start of a conversation, the KDC reply is presumed to
-   be verified using the client principal's long-term key.  It should be
-   noted that in this document, verifying the KDC reply means
-   authenticating the KDC, and these phrases are used interchangeably.
-   Any pre-authentication mechanism that sets a new reply key not based
-   on the principal's long-term secret MUST either verify the KDC reply
-   some other way or indicate that the reply is not verified.  If a
-   mechanism indicates that the reply is not verified then the client
-   implementation MUST return an error unless a subsequent mechanism
-   verifies the reply.  The KDC needs to track this state so it can
-   avoid generating a reply that is not verified.
-
-   The typical Kerberos request does not provide a way for the client
-   machine to know that it is talking to the correct KDC.  Someone who
-   can inject packets into the network between the client machine and
-   the KDC and who knows the password that the user will give to the
-   client machine can generate a KDC reply that will decrypt properly.
-   So, if the client machine needs to authenticate that the user is in
-   fact the named principal, then the client machine needs to do a TGS
-   request for itself as a service.  Some pre-authentication mechanisms
-   may provide a way for the client machine to authenticate the KDC.
-   Examples of this include signing the reply that can be verified using
-   a well-known public key or providing a ticket for the client machine
-   as a service.
-
-3.2.  Initial Pre-authentication Required Error
-
-   Typically a client starts a conversation by sending an initial
-   request with no pre-authentication.  If the KDC requires pre-
-
-
-
-Hartman & Zhu           Expires December 6, 2009                [Page 9]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
-   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
-   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED
-   (defined in Section 6.3) for pre-authentication configurations that
-   use multi-round-trip mechanisms; see Section 3.4 for details of that
-   case.
-
-   The KDC needs to choose which mechanisms to offer the client.  The
-   client needs to be able to choose what mechanisms to use from the
-   first message.  For example consider the KDC that will accept
-   mechanism A followed by mechanism B or alternatively the single
-   mechanism C. A client that supports A and C needs to know that it
-   should not bother trying A.
-
-   Mechanisms can either be sufficient on their own or can be part of an
-   authentication set--a group of mechanisms that all need to
-   successfully complete in order to authenticate a client.  Some
-   mechanisms may only be useful in authentication sets; others may be
-   useful alone or in authentication sets.  For the second group of
-   mechanisms, KDC policy dictates whether the mechanism will be part of
-   an authentication set, offered alone, or both.  For each mechanism
-   that is offered alone (even if it is also offered in an
-   authentication set), the KDC includes the pre-authentication type ID
-   of the mechanism in the padata sequence returned in the
-   KDC_ERR_PREAUTH_REQUIRED error.  Mechanisms that are only offered as
-   part of an authentication set are not directly represented in the
-   padata sequence returned in the KDC_ERR_PREAUTH_REQUIRED error,
-   although they are represented in the PA-AUTHENTICATION-SET sequence.
-
-   The KDC SHOULD NOT send data that is encrypted in the long-term
-   password-based key of the principal.  Doing so has the same security
-   exposures as the Kerberos protocol without pre-authentication.  There
-   are few situations where the KDC needs to expose cipher text
-   encrypted in a weak key before the client has proven knowledge of
-   that key, and pre-authentication is desirable.
-
-3.3.  Client to KDC
-
-   This description assumes that a client has already received a
-   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
-   optimistic pre-authentication then the client needs to guess values
-   for the information it would normally receive from that error
-   response or use cached information obtained in prior interactions
-   with the KDC.
-
-   The client starts by initializing the pre-authentication state as
-   specified.  It then processes the padata in the
-   KDC_ERR_PREAUTH_REQUIRED.
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 10]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
-   client MAY ignore any padata it chooses unless doing so violates a
-   specification to which the client conforms.  Clients conforming to
-   this specification MUST NOT ignore the padata defined in Section 6.3.
-   Clients SHOULD process padata unrelated to this framework or other
-   means of authenticating the user.  Clients SHOULD choose one
-   authentication set or mechanism that could lead to authenticating the
-   user and ignore the rest.  Since the list of mechanisms offered by
-   the KDC is in the decreasing preference order, clients typically
-   choose the first mechanism or authentication set that the client can
-   usefully perform.  If a client chooses to ignore a padata it MUST NOT
-   process the padata, allow the padata to affect the pre-authentication
-   state, nor respond to the padata.
-
-   For each padata the client chooses to process, the client processes
-   the padata and modifies the pre-authentication state as required by
-   that mechanism.  Padata are processed in the order received from the
-   KDC.
-
-   After processing the padata in the KDC error, the client generates a
-   new request.  It processes the pre-authentication mechanisms in the
-   order in which they will appear in the next request, updating the
-   state as appropriate.  The request is sent when it is complete.
-
-3.4.  KDC to Client
-
-   When a KDC receives an AS request from a client, it needs to
-   determine whether it will respond with an error or an AS reply.
-   There are many causes for an error to be generated that have nothing
-   to do with pre-authentication; they are discussed in the core
-   Kerberos specification.
-
-   From the standpoint of evaluating the pre-authentication, the KDC
-   first starts by initializing the pre-authentication state.  If a PA-
-   FX-COOKIE pre-authentication data item is present, it is processed
-   first; see Section 6.3 for a definition.  It then processes the
-   padata in the request.  As mentioned in Section 3.3, the KDC MAY
-   ignore padata that is inappropriate for the configuration and MUST
-   ignore padata of an unknown type.  The KDC MUST NOT ignore padata of
-   types used in previous messages.  For example, if a KDC issues a
-   KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the
-   KDC cannot ignore padata of type x received in an AS-REQ message from
-   the client.
-
-   At this point the KDC decides whether it will issue an error or a
-   reply.  Typically a KDC will issue a reply if the client's identity
-   has been authenticated to a sufficient degree.
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 11]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   In the case of a KDC_ERR_MORE_PREAUTH_DATA_NEEDED error, the KDC
-   first starts by initializing the pre-authentication state.  Then it
-   processes any padata in the client's request in the order provided by
-   the client.  Mechanisms that are not understood by the KDC are
-   ignored.  Next, it generates padata for the error response, modifying
-   the pre-authentication state appropriately as each mechanism is
-   processed.  The KDC chooses the order in which it will generate
-   padata (and thus the order of padata in the response), but it needs
-   to modify the pre-authentication state consistently with the choice
-   of order.  For example, if some mechanism establishes an
-   authenticated client identity, then the subsequent mechanisms in the
-   generated response receive this state as input.  After the padata is
-   generated, the error response is sent.  Typically the errors with the
-   code KDC_ERR_MORE_PREAUTH_DATA_NEEDED in a conversation will include
-   KDC state as discussed in Section 6.3.
-
-   To generate a final reply, the KDC generates the padata modifying the
-   pre-authentication state as necessary.  Then it generates the final
-   response, encrypting it in the current pre-authentication reply key.
-
-
-4.  Pre-Authentication Facilities
-
-   Pre-Authentication mechanisms can be thought of as providing various
-   conceptual facilities.  This serves two useful purposes.  First,
-   mechanism authors can choose only to solve one specific small
-   problem.  It is often useful for a mechanism designed to offer key
-   management not to directly provide client authentication but instead
-   to allow one or more other mechanisms to handle this need.  Secondly,
-   thinking about the abstract services that a mechanism provides yields
-   a minimum set of security requirements that all mechanisms providing
-   that facility must meet.  These security requirements are not
-   complete; mechanisms will have additional security requirements based
-   on the specific protocol they employ.
-
-   A mechanism is not constrained to only offering one of these
-   facilities.  While such mechanisms can be designed and are sometimes
-   useful, many pre-authentication mechanisms implement several
-   facilities.  By combining multiple facilities in a single mechanism,
-   it is often easier to construct a secure, simple solution than by
-   solving the problem in full generality.  Even when mechanisms provide
-   multiple facilities, they need to meet the security requirements for
-   all the facilities they provide.  If the FAST factor approach is
-   used, it is likely that one or a small number of facilities can be
-   provided by a single mechanism without complicating the security
-   analysis.
-
-   According to Kerberos extensibility rules (Section 1.5 of the
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 12]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   Kerberos specification [RFC4120]), an extension MUST NOT change the
-   semantics of a message unless a recipient is known to understand that
-   extension.  Because a client does not know that the KDC supports a
-   particular pre-authentication mechanism when it sends an initial
-   request, a pre-authentication mechanism MUST NOT change the semantics
-   of the request in a way that will break a KDC that does not
-   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
-   clients that affect the core semantics unless the client has
-   indicated support for the message.
-
-   The only state in this model that would break the interpretation of a
-   message is changing the expected reply key.  If one mechanism changed
-   the reply key and a later mechanism used that reply key, then a KDC
-   that interpreted the second mechanism but not the first would fail to
-   interpret the request correctly.  In order to avoid this problem,
-   extensions that change core semantics are typically divided into two
-   parts.  The first part proposes a change to the core semantic--for
-   example proposes a new reply key.  The second part acknowledges that
-   the extension is understood and that the change takes effect.
-   Section 4.2 discusses how to design mechanisms that modify the reply
-   key to be split into a proposal and acceptance without requiring
-   additional round trips to use the new reply key in subsequent pre-
-   authentication.  Other changes in the state described in Section 3.1
-   can safely be ignored by a KDC that does not understand a mechanism.
-   Mechanisms that modify the behavior of the request outside the scope
-   of this framework need to carefully consider the Kerberos
-   extensibility rules to avoid similar problems.
-
-4.1.  Client-authentication Facility
-
-   The client authentication facility proves the identity of a user to
-   the KDC before a ticket is issued.  Examples of mechanisms
-   implementing this facility include the encrypted timestamp facility
-   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
-   Mechanisms that provide this facility are expected to mark the client
-   as authenticated.
-
-   Mechanisms implementing this facility SHOULD require the client to
-   prove knowledge of the reply key before transmitting a successful KDC
-   reply.  Otherwise, an attacker can intercept the pre-authentication
-   exchange and get a reply to attack.  One way of proving the client
-   knows the reply key is to implement the Replace Reply Key facility
-   along with this facility.  The PKINIT mechanism [RFC4556] implements
-   Client Authentication alongside Replace Reply Key.
-
-   If the reply key has been replaced, then mechanisms such as
-   encrypted-timestamp that rely on knowledge of the reply key to
-   authenticate the client MUST NOT be used.
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 13]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-4.2.  Strengthening-reply-key Facility
-
-   Particularly when dealing with keys based on passwords, it is
-   desirable to increase the strength of the key by adding additional
-   secrets to it.  Examples of sources of additional secrets include the
-   results of a Diffie-Hellman key exchange or key bits from the output
-   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
-   be first combined with the existing reply key and then converted to a
-   protocol key using tools defined in Section 6.1.
-
-   Typically a mechanism implementing this facility will know that the
-   other side of the exchange supports the facility before the reply key
-   is changed.  For example, a mechanism might need to learn the
-   certificate for a KDC before encrypting a new key in the public key
-   belonging to that certificate.  However, if a mechanism implementing
-   this facility wishes to modify the reply key before knowing that the
-   other party in the exchange supports the mechanism, it proposes
-   modifying the reply key.  The other party then includes a message
-   indicating that the proposal is accepted if it is understood and
-   meets policy.  In many cases it is desirable to use the new reply key
-   for client authentication and for other facilities.  Waiting for the
-   other party to accept the proposal and actually modify the reply key
-   state would add an additional round trip to the exchange.  Instead,
-   mechanism designers are encouraged to include a typed hole for
-   additional padata in the message that proposes the reply key change.
-   The padata included in the typed hole are generated assuming the new
-   reply key.  If the other party accepts the proposal, then these
-   padata are considered as an inner level.  As with the outer level,
-   one authentication set or mechanism is typically chosen for client
-   authentication, along with auxiliary mechanisms such as KDC cookies,
-   and other mechanisms are ignored.  When mechanisms include such a
-   container, the hint provided for use in authentication sets (as
-   defined in Section 6.4) MUST contain a sequence of inner mechanisms
-   along with hints for those mechanisms.  The party generating the
-   proposal can determine whether the padata were processed based on
-   whether the proposal for the reply key is accepted.
-
-   The specific formats of the proposal message, including where padata
-   are included is a matter for the mechanism specification.  Similarly,
-   the format of the message accepting the proposal is mechanism-
-   specific.
-
-   Mechanisms implementing this facility and including a typed hole for
-   additional padata MUST checksum that padata using a keyed checksum or
-   encrypt the padata.  This requirement protects against modification
-   of the contents of the typed hole.  By modifying these contents an
-   attacker might be able to choose which mechanism is used to
-   authenticate the client, or to convince a party to provide text
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 14]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   encrypted in a key that the attacker had manipulated.  It is
-   important that mechanisms strengthen the reply key enough that using
-   it to checksum padata is appropriate.
-
-4.3.  Replacing-reply-key Facility
-
-   The Replace Reply Key facility replaces the key in which a successful
-   AS reply will be encrypted.  This facility can only be used in cases
-   where knowledge of the reply key is not used to authenticate the
-   client.  The new reply key MUST be communicated to the client and the
-   KDC in a secure manner.  This facility MUST NOT be used if there can
-   be a man-in-the-middle between the client and the KDC.  Mechanisms
-   implementing this facility MUST mark the reply key as replaced in the
-   pre-authentication state.  Mechanisms implementing this facility MUST
-   either provide a mechanism to verify the KDC reply to the client or
-   mark the reply as unverified in the pre-authentication state.
-   Mechanisms implementing this facility SHOULD NOT be used if a
-   previous mechanism has used the reply key.
-
-   As with the strengthening-reply-key facility, Kerberos extensibility
-   rules require that the reply key not be changed unless both sides of
-   the exchange understand the extension.  In the case of this facility
-   it will likely be the case for both sides to know that the facility
-   is available by the time that the new key is available to be used.
-   However, mechanism designers can use a container for padata in a
-   proposal message as discussed in Section 4.2 if appropriate.
-
-4.4.  KDC-authentication Facility
-
-   This facility verifies that the reply comes from the expected KDC.
-   In traditional Kerberos, the KDC and the client share a key, so if
-   the KDC reply can be decrypted then the client knows that a trusted
-   KDC responded.  Note that the client machine cannot trust the client
-   unless the machine is presented with a service ticket for it
-   (typically the machine can retrieve this ticket by itself).  However,
-   if the reply key is replaced, some mechanism is required to verify
-   the KDC.  Pre-authentication mechanisms providing this facility allow
-   a client to determine that the expected KDC has responded even after
-   the reply key is replaced.  They mark the pre-authentication state as
-   having been verified.
-
-
-5.  Requirements for Pre-Authentication Mechanisms
-
-   This section lists requirements for specifications of pre-
-   authentication mechanisms.
-
-   For each message in the pre-authentication mechanism, the
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 15]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   specification describes the pa-type value to be used and the contents
-   of the message.  The processing of the message by the sender and
-   recipient is also specified.  This specification needs to include all
-   modifications to the pre-authentication state.
-
-   Generally mechanisms have a message that can be sent in the error
-   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
-   authentication set.  If the client needs information such as trusted
-   certificate authorities in order to determine if it can use the
-   mechanism, then this information should be in that message.  In
-   addition, such mechanisms should also define a pa-hint to be included
-   in authentication sets.  Often, the same information included in the
-   padata-value is appropriate to include in the pa-hint (as defined in
-   Section 6.4).
-
-   In order to ease security analysis the mechanism specification should
-   describe what facilities from this document are offered by the
-   mechanism.  For each facility, the security consideration section of
-   the mechanism specification should show that the security
-   requirements of that facility are met.  This requirement is
-   applicable to any FAST factor that provides authentication
-   information.
-
-   Significant problems have resulted in the specification of Kerberos
-   protocols because much of the KDC exchange is not protected against
-   authentication.  The security considerations section should discuss
-   unauthenticated plaintext attacks.  It should either show that
-   plaintext is protected or discuss what harm an attacker could do by
-   modifying the plaintext.  It is generally acceptable for an attacker
-   to be able to cause the protocol negotiation to fail by modifying
-   plaintext.  More significant attacks should be evaluated carefully.
-
-   As discussed in Section 6.3, there is no guarantee that a client will
-   use the same KDCs for all messages in a conversation.  The mechanism
-   specification needs to show why the mechanism is secure in this
-   situation.  The hardest problem to deal with, especially for
-   challenge/response mechanisms is to make sure that the same response
-   cannot be replayed against two KDCs while allowing the client to talk
-   to any KDC.
-
-
-6.  Tools for Use in Pre-Authentication Mechanisms
-
-   This section describes common tools needed by multiple pre-
-   authentication mechanisms.  By using these tools mechanism designers
-   can use a modular approach to specify mechanism details and ease
-   security analysis.
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 16]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-6.1.  Combining Keys
-
-   Frequently a weak key needs to be combined with a stronger key before
-   use.  For example, passwords are typically limited in size and
-   insufficiently random, therefore it is desirable to increase the
-   strength of the keys based on passwords by adding additional secrets.
-   Additional source of secrecy may come from hardware tokens.
-
-   This section provides standard ways to combine two keys into one.
-
-   KRB-FX-CF1() is defined to combine two pass-phrases.
-
-       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
-       KRB-FX-CF1(x, y) -> x || y
-
-   Where || denotes concatenation.  The strength of the final key is
-   roughly the total strength of the individual keys being combined
-   assuming that the string_to_key() function [RFC3961] uses all its
-   input evenly.
-
-   An example usage of KRB-FX-CF1() is when a device provides random but
-   short passwords, the password is often combined with a personal
-   identification number (PIN).  The password and the PIN can be
-   combined using KRB-FX-CF1().
-
-   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
-   function defined in [RFC3961].
-
-   Given two input keys, K1 and K2, where K1 and K2 can be of two
-   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
-   follows:
-
-       KRB-FX-CF2(protocol key, protocol key, octet string,
-                 octet string)  ->  (protocol key)
-
-       PRF+(K1, pepper1) -> octet-string-1
-       PRF+(K2, pepper2) -> octet-string-2
-       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
-              random-to-key(octet-string-1 ^ octet-string-2)
-
-   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
-   follows:
-
-    PRF+(protocol key, octet string) -> (octet string)
-
-    PRF+(key, shared-info) -> pseudo-random( key,  1 || shared-info ) ||
-                  pseudo-random( key, 2 || shared-info ) ||
-                  pseudo-random( key, 3 || shared-info ) || ...
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 17]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
-   integer.  The pseudo-random() operation is specified by the enctype
-   of the protocol key.  PRF+() uses the counter to generate enough bits
-   as needed by the random-to-key() [RFC3961] function for the
-   encryption type specified for the resulting key; unneeded bits are
-   removed from the tail.  Unless otherwise specified, the resulting
-   enctype of KRB-FX-CF2 is the enctype of k1.
-
-   Mechanism designers MUST specify the values for the input parameter
-   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
-   pepper1 and pepper2 MUST be distinct so that if the two keys being
-   combined are the same, the resulting key is not a trivial key.
-
-6.2.  Protecting Requests/Responses
-
-   Mechanism designers SHOULD protect clear text portions of pre-
-   authentication data.  Various denial of service attacks and downgrade
-   attacks against Kerberos are possible unless plaintexts are somehow
-   protected against modification.  An early design goal of Kerberos
-   Version 5 [RFC4120] was to avoid encrypting more of the
-   authentication exchange that was required.  (Version 4 doubly-
-   encrypted the encrypted part of a ticket in a KDC reply, for
-   example.)  This minimization of encryption reduces the load on the
-   KDC and busy servers.  Also, during the initial design of Version 5,
-   the existence of legal restrictions on the export of cryptography
-   made it desirable to minimize of the number of uses of encryption in
-   the protocol.  Unfortunately, performing this minimization created
-   numerous instances of unauthenticated security-relevant plaintext
-   fields.
-
-   If there is more than one round trip for an authentication exchange,
-   mechanism designers need to allow either the client or the KDC to
-   provide a checksum of all the messages exchanged on the wire in the
-   conversation, and the checksum is then verified by the receiver.
-
-   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
-
-   Primitives defined in [RFC3961] are RECOMMENDED for integrity
-   protection and confidentiality.  Mechanisms based on these primitives
-   are crypto-agile as the result of using [RFC3961] along with
-   [RFC4120].  The advantage afforded by crypto-agility is the ability
-   to incrementally deploy a fix specific to a particular algorithm thus
-   avoid a multi-year standardization and deployment cycle, when real
-   attacks do arise against that algorithm.
-
-   Note that data used by FAST factors (defined in Section 6.5) is
-   encrypted in a protected channel, thus they do not share the un-
-   authenticated-text issues with mechanisms designed as full-blown pre-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 18]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   authentication mechanisms.
-
-6.3.  Managing States for the KDC
-
-   Kerberos KDCs are stateless in that there is no requirement that
-   clients will choose the same KDC for the second request in a
-   conversation.  Proxies or other intermediate nodes may also influence
-   KDC selection.  So, each request from a client to a KDC must include
-   sufficient information that the KDC can regenerate any needed state.
-   This is accomplished by giving the client a potentially long opaque
-   cookie in responses to include in future requests in the same
-   conversation.  The KDC MAY respond that a conversation is too old and
-   needs to restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
-
-       KDC_ERR_PREAUTH_EXPIRED            90
-
-   When a client receives this error, the client SHOULD abort the
-   existing conversation, and restart a new one.
-
-   An example, where more than one message from the client is needed, is
-   when the client is authenticated based on a challenge-response
-   scheme.  In that case, the KDC needs to keep track of the challenge
-   issued for a client authentication request.
-
-   The PA-FX-COOKIE padata type is defined in this section to facilitate
-   state management in the AS exchange.  This padata is sent by the KDC
-   when the KDC requires state for a future transaction.  The client
-   includes this opaque token in the next message in the conversation.
-   The token may be relatively large; clients MUST be prepared for
-   tokens somewhat larger than the size of all messages in a
-   conversation.
-
-       PA-FX-COOKIE                       133
-           -- Stateless cookie that is not tied to a specific KDC.
-
-   The corresponding padata-value field [RFC4120] contains an opaque
-   token that will be echoed by the client in its response to an error
-   from the KDC.
-
-   The cookie token is generated by the KDC and transmitted in a PA-FX-
-   COOKIE pre-authentication data item of a KRB-ERROR message.  The
-   client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data
-   element into the next message of the same conversation.  The content
-   of the cookie field is a local matter of the KDC.  As a result, it is
-   not generally possible to mix KDC implementations from different
-   vendors in the same realm.  However the KDC MUST construct the cookie
-   token in such a manner that a malicious client cannot subvert the
-   authentication process by manipulating the token.  The KDC
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 19]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   implementation needs to consider expiration of tokens, key rollover
-   and other security issues in token design.  The content of the cookie
-   field is likely specific to the pre-authentication mechanisms used to
-   authenticate the client.  If a client authentication response can be
-   replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an
-   expiration in the cookie is RECOMMENDED to prevent the response being
-   presented indefinitely.
-
-   If at least one more message for a mechanism or a mechanism set is
-   expected by the KDC, the KDC returns a
-   KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA-FX-COOKIE to
-   identify the conversation with the client according to Section 3.2.
-   The cookie is not expected to stay constant for a conversation: the
-   KDC is expected to generate a new cookie for each message.
-
-        KDC_ERR_MORE_PREAUTH_DATA_NEEDED   91
-
-   A client MAY throw away the state associated with a conversation and
-   begin a new conversation by discarding its state and not including a
-   cooking in the first message of a conversation.  KDCs that comply
-   with this specification MUST include a cookie in a response when the
-   client can continue the conversation.  In particular, a KDC MUST
-   include a cookie in a KDC_ERR_PREAUTH_REQUIRED or
-   KDC_ERR_MORE_PREAUTH_DATA_NEEDED.  KDCs SHOULD include a cookie in
-   errors containing additional information allowing a client to retry.
-   One reasonable strategy for meeting these requirements is to always
-   include a cookie in KDC errors.
-
-   A KDC MAY indicate that it is terminating a conversation by not
-   including a cookie in a response.  When FAST is used, clients can
-   assume that the absence of a cookie means that the KDC is ending the
-   conversation.  Clients also need to deal with KDCs prior to this
-   specification that do not include cookies; if cookies nor FAST are
-   used in a conversation, the absence of a cookie is not a strong
-   indication that the KDC is terminating the conversation.
-
-6.4.  Pre-authentication Set
-
-   If all mechanisms in a group need to successfully complete in order
-   to authenticate a client, the client and the KDC SHOULD use the PA-
-   AUTHENTICATION-SET padata element.
-
-        PA-AUTHENTICATION-SET              134
-
-   A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
-   encoding of the PA-AUTHENTICATION-SET structure:
-
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 20]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-            pa-type      [0] Int32,
-                -- same as padata-type.
-            pa-hint      [1] OCTET STRING OPTIONAL,
-            pa-value     [2] OCTET STRING OPTIONAL,
-            ...
-        }
-
-   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
-   contains the corresponding value of padata-type in PA-DATA [RFC4120].
-   Associated with the pa-type is a pa-hint, which is an octet-string
-   specified by the pre-authentication mechanism.  This hint may provide
-   information for the client which helps it determine whether the
-   mechanism can be used.  For example a public-key mechanism might
-   include the certificate authorities it trusts in the hint info.  Most
-   mechanisms today do not specify hint info; if a mechanism does not
-   specify hint info the KDC MUST NOT send a hint for that mechanism.
-   To allow future revisions of mechanism specifications to add hint
-   info, clients MUST ignore hint info received for mechanisms that the
-   client believes do not support hint info.  The pa-value element of
-   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
-   first padata-value from the KDC to the client.  If the client chooses
-   this authentication set then the client MUST process this pa-value.
-   The pa-value element MUST be absent for all but the first entry in
-   the authentication set.  Clients MUST ignore pa-value for the second
-   and following entries in the authentication set.
-
-   If the client chooses an authentication set, then its first AS-REQ
-   message MUST contain a PA-AUTH-SET-SELECTED padata element.  This
-   element contains the encoding of the PA-AUTHENTICATION-SET sequence
-   received from the KDC corresponding to the authentication set that is
-   chosen.  The client MUST use the same octet values received from the
-   KDC; it cannot re-encode the sequence.  This allows KDCs to use bit-
-   wise comparison to identify the selected authentication set.  The PA-
-   AUTH-SET-SELECTED padata element MUST come before any padata elements
-   from the authentication set in the padata sequence in the AS-REQ
-   message.  The client MAY cache authentication sets from prior
-   messages and use them to construct an optimistic initial AS-REQ.  If
-   the KDC receives a PA-AUTH-SET-SELECTED padata element that does not
-   correspond to an authentication set that it would offer, then the KDC
-   returns the KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The e-data
-   in this error contains a sequence of padata just as for the
-   KDC_ERR_PREAUTH_REQUIRED error.
-
-
-         PA-AUTH-SET-SELECTED                   135
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 21]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-         KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
-
-   The PA-AUTHENTICATION-SET appears only in the first message from the
-   KDC to the client.  In particular, the client MAY fail if the
-   authentication mechanism sets change as the conversation progresses.
-   Clients MAY assume that the hints provided in the authentication set
-   contain enough information that the client knows what user interface
-   elements need to be displayed during the entire authentication
-   conversation.  Exceptional circumstances such as expired passwords or
-   expired accounts may require that additional user interface be
-   displayed.  Mechanism designers needs to carefully consider the
-   design of their hints so that the client has this information.  This
-   way, clients can construct necessary dialogue boxes or wizards based
-   on the authentication set and can present a coherent user interface.
-   Current standards for user interface do not provide an acceptable
-   experience when the client has to ask additional questions later in
-   the conversation.
-
-   When indicating which sets of pre-authentication mechanisms are
-   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
-   for each pre-authentication mechanism set.
-
-   The client sends the padata-value for the first mechanism it picks in
-   the pre-authentication set, when the first mechanism completes, the
-   client and the KDC will proceed with the second mechanism, and so on
-   until all mechanisms complete successfully.  The PA-FX-COOKIE as
-   defined in Section 6.3 MUST be sent by the KDC.  One reason for this
-   requirement is so that the conversation can continue if the
-   conversation involves multiple KDCs.  KDCs MUST support clients that
-   do not include a cookie because they optimistically choose an
-   authentication set, although they MAY always return
-   KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in that
-   message.  Clients that support PA-AUTHENTICATION-SET MUST support PA-
-   FX-COOKIE.
-
-   Before the authentication succeeds and a ticket is returned, the
-   message that the client sends is an AS_REQ and the message that the
-   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
-   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_NEEDED as defined
-   in Section 6.3 and the accompanying e-data contains the DER encoding
-   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
-   the METHOD-DATA.  If there is no padata, the e-data field is absent
-   in the KRB-ERROR message.
-
-   If the client sends the last message for a given mechanism, then the
-   KDC sends the first message for the next mechanism.  If the next
-   mechanism does not start with a KDC-side challenge, then the KDC
-   includes a padata item with the appropriate pa-type and an empty pa-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 22]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   data.
-
-   If the KDC sends the last message for a particular mechanism, the KDC
-   also includes the first padata for the next mechanism.
-
-6.5.  Definition of Kerberos FAST Padata
-
-   As described in [RFC4120], Kerberos is vulnerable to offline
-   dictionary attacks.  An attacker can request an AS-REP and try
-   various passwords to see if they can decrypt the resulting ticket.
-   RFC 4120 provides the encrypted timestamp pre-authentication method
-   that ameliorates the situation somewhat by requiring that an attacker
-   observe a successful authentication.  However stronger security is
-   desired in many environments.  The Kerberos FAST pre-authentication
-   padata defined in this section provides a tool to significantly
-   reduce vulnerability to offline dictionary attack.  When combined
-   with encrypted challenge, FAST requires an attacker to mount a
-   successful man-in-the-middle attack to observe ciphertext.  When
-   combined with host keys, FAST can even protect against active
-   attacks.  FAST also provides solutions to common problems for pre-
-   authentication mechanisms such as binding of the request and the
-   reply, freshness guarantee of the authentication.  FAST itself,
-   however, does not authenticate the client or the KDC, instead, it
-   provides a typed hole to allow pre-authentication data be tunneled.
-   A pre-authentication data element used within FAST is called a FAST
-   factor.  A FAST factor captures the minimal work required for
-   extending Kerberos to support a new pre-authentication scheme.
-
-   A FAST factor MUST NOT be used outside of FAST unless its
-   specification explicitly allows so.  The typed holes in FAST messages
-   can also be used as generic holes for other padata that are not
-   intended to prove the client's identity, or establish the reply key.
-
-   New pre-authentication mechanisms SHOULD be designed as FAST factors,
-   instead of full-blown pre-authentication mechanisms.
-
-   FAST factors that are pre-authentication mechanisms MUST meet the
-   requirements in Section 5.
-
-   FAST employs an armoring scheme.  The armor can be a Ticket Granting
-   Ticket (TGT) obtained by the client's machine using the host keys to
-   pre-authenticate with the KDC, or an anonymous TGT obtained based on
-   anonymous PKINIT [KRB-ANON] [RFC4556].
-
-   The rest of this section describes the types of armors and the syntax
-   of the messages used by FAST.  Conforming implementations MUST
-   support Kerberos FAST padata.
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 23]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   Any FAST armor scheme MUST provide a fresh armor key for each
-   conversation.  Clients and KDCs can assume that if a message is
-   encrypted and integrity protected with a given armor key then it is
-   part of the conversation using that armor key.
-
-   All KDCs in a realm MUST support FAST if FAST is offered by any KDC
-   as a pre-authentication mechanism.
-
-6.5.1.  FAST Armors
-
-   An armor key is used to encrypt pre-authentication data in the FAST
-   request and the response.  The KrbFastArmor structure is defined to
-   identify the armor key.  This structure contains the following two
-   fields: the armor-type identifies the type of armors, and the armor-
-   value is an OCTET STRING that contains the description of the armor
-   scheme and the armor key.
-
-        KrbFastArmor ::= SEQUENCE {
-            armor-type   [0] Int32,
-                -- Type of the armor.
-            armor-value  [1] OCTET STRING,
-                -- Value of the armor.
-            ...
-        }
-
-   The value of the armor key is a matter of the armor type
-   specification.  Only one armor type is defined in this document.
-
-        FX_FAST_ARMOR_AP_REQUEST           1
-
-   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
-
-   Conforming implementations MUST implement the
-   FX_FAST_ARMOR_AP_REQUEST armor type.
-
-   FAST implementations MUST maintain state about whether the armor
-   mechanism authenticates the KDC.  If it does not, then a fast factor
-   that authenticates the KDC MUST be used if the reply key is replaced.
-
-6.5.1.1.  Ticket-based Armors
-
-   This is a ticket-based armoring scheme.  The armor-type is
-   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
-   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
-   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
-   The armor key is defined by the following function:
-
-       armor_key = KRB-FX-CF2( subkey, ticket_session_key,
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 24]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-                   "subkeyarmor", "ticketarmor" )
-
-   The `ticket_session_key' is the session key from the ticket in the
-   ap-req.  The `subkey' is the ap-req subkey.  This construction
-   guarantees that both the KDC (through the session key) and the client
-   (through the subkey) contribute to the armor key.
-
-   The server name field of the armor ticket MUST identify the TGS of
-   the target realm.  Here are three common ways in the decreasing
-   preference order how an armor TGT SHOULD be obtained:
-
-   1.  If the client is authenticating from a host machine whose
-       Kerberos realm has an authentication path to the client's realm,
-       the host machine obtains a TGT by using the host keys.  If the
-       client's realm is different than the realm of the local host, the
-       machine then obtains a cross-realm TGT to the client's realm as
-       the armor ticket.  Otherwise, the host's primary TGT is the armor
-       ticket.
-
-   2.  If the client's host machine cannot obtain a host ticket strictly
-       based on RFC4120, but the KDC has an asymmetric signing key whose
-       binding with the expected KDC can be verified by the client, the
-       client can use anonymous PKINIT [KRB-ANON] [RFC4556] to
-       authenticate the KDC and obtain an anonymous TGT as the armor
-       ticket.  The armor ticket can also be a cross-realm TGT obtained
-       based on the initial primary TGT obtained using anonymous PKINIT
-       with KDC authentication.
-
-   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
-       TGT without KDC authentication and that TGT is the armor ticket.
-       Note that this mode of operation is vulnerable to man-in-the-
-       middle attacks at the time of obtaining the initial anonymous
-       armor TGT.
-
-   If anonymous PKINIT is used to obtain the armor ticket, the KDC
-   cannot know whether its signing key can be verified by the client,
-   hence the KDC MUST be marked as unverified from the KDC's point of
-   view while the client could be able to authenticate the KDC by
-   verifying the KDC's signing key is bound with the expected KDC.  The
-   client needs to carefully consider the risk and benefit tradeoffs
-   associated with active attacks before exposing cipher text encrypted
-   using the user's long-term secrets when the armor does not
-   authenticate the KDC.
-
-   The TGS MUST reject a request if there is an AD-fx-fast-armor (TBD)
-   element in the authenticator of the pa-tgs-req padata or if the
-   ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-
-   armor authorization data element.  These tickets and authenticators
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 25]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   MAY be used as FAST armor tickets but not to obtain a ticket via the
-   TGS.  This authorization data is used in a system where the
-   encryption of the user's pre-authentication data is performed in an
-   unprivileged user process.  A privileged process can provide to the
-   user process a host ticket, an authenticator for use with that
-   ticket, and the sub session key contained in the authenticator.  In
-   order for the host process to ensure that the host ticket is not
-   accidentally or intentionally misused, (i.e. the user process might
-   use the host ticket to authenticate as the host), it MUST include a
-   critical authorization data element of the type AD-fx-fast-armor when
-   providing the authenticator or in the enc-authorization-data field of
-   the TGS request used to obtain the TGT.  The corresponding ad-data
-   field of the AD-fx-fast-armor element is empty.
-
-   As discussed previously, the server of an armor ticket MUST be the
-   TGS of the realm from whom service is requested.  As a result, if
-   this armor type is used when a ticket is being validated, proxied, or
-   in other cases where a ticket other than a TGT is presented to the
-   TGS, a TGT will be used as an armor ticket, while another ticket will
-   be used in the pa-tgs-req authenticator.
-
-6.5.2.  FAST Request
-
-   A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
-   authentication padata.  The corresponding padata-value field
-   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
-   REQUEST.  As with all pre-authentication types, the KDC SHOULD
-   advertise PA-FX-FAST in a PREAUTH_REQUIRED error.  KDCs MUST send the
-   advertisement of pa-fx-fast with an empty pa-value.  Clients MUST
-   ignore the pa-value of PA-FX-FAST in an initial PREAUTH_REQUIRED
-   error.  FAST is not expected to be used in an authentication set:
-   clients will typically use FAST padata if available and this decision
-   should not depend on what other pre-authentication methods are
-   available.  As such, no pa-hint is defined for FAST at this time.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 26]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-       PA-FX-FAST                         136
-           -- Padata type for Kerberos FAST
-
-       PA-FX-FAST-REQUEST ::= CHOICE {
-           armored-data [0] KrbFastArmoredReq,
-           ...
-       }
-
-       KrbFastArmoredReq ::= SEQUENCE {
-           armor        [0] KrbFastArmor OPTIONAL,
-               -- Contains the armor that identifies the armor key.
-               -- MUST be present in AS-REQ.
-           req-checksum [1] Checksum,
-               -- For AS, contains the checksum performed over the type
-               -- KDC-REQ-BODY for the req-body field of the KDC-REQ
-               -- structure;
-               -- For TGS, contains the checksum performed over the type
-               -- AP-REQ in the PA-TGS-REQ padata.
-               -- The checksum key is the armor key, the checksum
-               -- type is the required checksum type for the enctype of
-               -- the armor key, and the key usage number is
-               -- KEY_USAGE_FAST_REQ_CHKSUM.
-           enc-fast-req [2] EncryptedData, -- KrbFastReq --
-               -- The encryption key is the armor key, and the key usage
-               -- number is KEY_USAGE_FAST_ENC.
-           ...
-       }
-
-       KEY_USAGE_FAST_REQ_CHKSUM          50
-       KEY_USAGE_FAST_ENC                 51
-
-   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
-   The KrbFastArmoredReq encapsulates the encrypted padata.
-
-   The enc-fast-req field contains an encrypted KrbFastReq structure.
-   The armor key is used to encrypt the KrbFastReq structure, and the
-   key usage number for that encryption is KEY_USAGE_FAST_ENC.
-
-   The armor key is selected as follows:
-
-   o  In an AS request, the armor field in the KrbFastArmoredReq
-      structure MUST be present and the armor key is identified
-      according to the specification of the armor type.
-
-   o  There are two possibilities for armor for a TGS request.  If the
-      ticket presented in the PA-TGS-REQ authenticator is a TGT, then
-      the client SHOULD not include the armor field in the Krbfastreq
-      and a subkey MUST be included in the PA-TGS-REQ authenticator.  In
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 27]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-      this case, the armor key is the same armor key that would be
-      computed if the TGS-REQ authenticator was used in a
-      FX_FAST_ARMOR_AP_REQUEST armor.  If a ticket other than a TGT is
-      being presented to the TGS, a client SHOULD use some form of FAST
-      armor such as a ticket-based armor with a TGT as an armor ticket.
-      Clients MAY present a non-TGT in the PA-TGS-REQ authenticator and
-      omit the armor field, in which case the armor key is the same that
-      would be computed if the authenticator were used in a
-      FX_FAST_ARMOR_AP_REQUEST armor.  This is the only case where a
-      ticket other than a TGT can be used to establish an armor key;
-      even though the armor key is computed the same as a
-      FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used as an armor
-      ticket in FX_FAST_ARMOR_AP_REQUEST.
-
-   The req-checksum field contains a checksum computed differently for
-   AS and TGS.  For an AS-REQ, it is performed over the type KDC-REQ-
-   BODY for the req-body field of the KDC-REQ structure of the
-   containing message; for an TGS-REQ, it is performed over the type AP-
-   REQ in the PA-TGS-REQ padata of the TGS request.  The checksum key is
-   the armor key, and the checksum type is the required checksum type
-   for the enctype of the armor key per [RFC3961].  This checksum MUST
-   be a keyed checksume and it is included in order to bind the FAST
-   padata to the outer request.  A KDC that implements FAST will ignore
-   the outer request, but including a checksum is relatively cheap and
-   may prevent confusing behavior.
-
-   The KrbFastReq structure contains the following information:
-
-        KrbFastReq ::= SEQUENCE {
-            fast-options [0] FastOptions,
-                -- Additional options.
-            padata       [1] SEQUENCE OF PA-DATA,
-                -- padata typed holes.
-            req-body     [2] KDC-REQ-BODY,
-                -- Contains the KDC request body as defined in Section
-                -- 5.4.1 of [RFC4120].
-                -- This req-body field is preferred over the outer field
-                -- in the KDC request.
-             ...
-        }
-
-   The fast-options field indicates various options that are to modify
-   the behavior of the KDC.  The following options are defined:
-
-        FastOptions ::= KerberosFlags
-            -- reserved(0),
-            -- hide-client-names(1),
-            -- kdc-follow-referrals(16)
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 28]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-     Bits    Name                    Description
-    -----------------------------------------------------------------
-     0     RESERVED              Reserved for future expansion of this
-                                 field.
-     1     hide-client-names     Requesting the KDC to hide client
-                                 names in the KDC response, as
-                                 described next in this section.
-     16    kdc-follow-referrals  Requesting the KDC to follow referrals.
-
-   Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are
-   critical options.  If the KDC does not support a critical option, it
-   MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and
-   there is no accompanying e-data defined in this document for this
-   error code.  Bit 16 and onward (with bit 16 included) are non-
-   critical options.  KDCs conforming to this specification ignore
-   unknown non-critical options.
-
-        KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
-
-   The hide-client-names Option
-
-      The Kerberos response defined in [RFC4120] contains the client
-      identity in clear text, This makes traffic analysis
-      straightforward.  The hide-client-names option is designed to
-      complicate traffic analysis.  If the hide-client-names option is
-      set, the KDC implementing PA-FX-FAST MUST identify the client as
-      the anonymous principal [KRB-ANON] in the KDC reply and the error
-      response.  Hence this option is set by the client if it wishes to
-      conceal the client identity in the KDC response.  A conforming KDC
-      ignores the client principal name in the outer KDC-REQ-BODY field,
-      and identifies the client using the cname and crealm fields in the
-      req-body field of the KrbFastReq structure.
-
-   The kdc-follow-referrals Option
-
-      The Kerberos client described in [RFC4120] has to request referral
-      TGTs along the authentication path in order to get a service
-      ticket for the target service.  The Kerberos client described in
-      the [REFERRALS] needs to contact the AS specified in the error
-      response in order to complete client referrals.  The kdc-follow-
-      referrals option is designed to minimize the number of messages
-      that need to be processed by the client.  This option is useful
-      when, for example, the client may contact the KDC via a satellite
-      link that has high network latency, or the client has limited
-      computational capabilities.  If the kdc-follow-referrals option is
-      set, the KDC MAY act as the client to follow TGS referrals
-      [REFERRALS], and return the service ticket to the named server
-      principal in the client request using the reply key expected by
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 29]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-      the client.  That is, rather than returning a referral, the KDC
-      follows that referral by contacting a remote KDC and processing
-      the referral.  The kdc-referrals option can be implemented when
-      the KDC knows the reply key.  The KDC can ignore kdc-referrals
-      option when it does not understand it or it does not allow this
-      option based on local policy.  The client SHOULD be capable of
-      processing the KDC responses when this option is not honored by
-      the KDC.  Clients SHOULD use TCP to contact a KDC if this option
-      is going to be used to avoid problems when the client's UDP
-      retransmit algorithm has timeouts insufficient to allow the KDC to
-      interact with remote KDCs.
-
-   The padata field contains a list of PA-DATA structures as described
-   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
-   FAST factors.  They can also be used as generic typed-holes to
-   contain data not intended for proving the client's identity or
-   establishing a reply key, but for protocol extensibility.  If the KDC
-   supports the PA-FX-FAST-REQUEST padata, unless otherwise specified,
-   the client MUST place any padata that is otherwise in the outer KDC
-   request body into this field.  In a TGS request, PA-TGS-REQ padata is
-   not included in this field and it is present in the outer KDC request
-   body.
-
-   The KDC-REQ-BODY in the FAST structure is used in preference to the
-   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-
-   REQ-BODY structure SHOULD be filled in for backwards compatibility
-   with KDCs that do not support FAST.  A conforming KDC ignores the
-   outer KDC-REQ-BODY field in the KDC request.  Pre-authentication data
-   methods such as [RFC4556] that include a checksum of the KDC-REQ-BODY
-   should checksum the KDC-REQ-BODY.
-
-   In a TGS request, a client MAY include the AD-fx-fast-used authdata
-   either in the pa-tgs-req authenticator or in the authorization data
-   in the pa-tgs-req ticket.  If the KDC receives this authorization
-   data but does not find a FAST padata then it MUST return
-   KRB_APP_ERR_MODIFIED.
-
-6.5.3.  FAST Response
-
-   The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST
-   padata element in the KDC reply.  In the case of an error, the PA-FX-
-   FAST padata is included in the KDC responses according to
-   Section 6.5.4.
-
-   The corresponding padata-value field [RFC4120] for the PA-FX-FAST in
-   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
-   FAST-REPLY.
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 30]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-      PA-FX-FAST-REPLY ::= CHOICE {
-          armored-data [0] KrbFastArmoredRep,
-          ...
-      }
-
-      KrbFastArmoredRep ::= SEQUENCE {
-          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
-              -- The encryption key is the armor key in the request, and
-              -- the key usage number is KEY_USAGE_FAST_REP.
-          ...
-      }
-      KEY_USAGE_FAST_REP                 52
-
-   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
-   structure.  The KrbFastArmoredRep structure encapsulates the padata
-   in the KDC reply in the encrypted form.  The KrbFastResponse is
-   encrypted with the armor key used in the corresponding request, and
-   the key usage number is KEY_USAGE_FAST_REP.
-
-   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
-   KDC response MUST support a local policy that rejects the response.
-   Clients MAY also support policies that fall back to other mechanisms
-   or that do not use pre-authentication when FAST is unavailable.  It
-   is important to consider the potential downgrade attacks when
-   deploying such a policy.
-
-   The KrbFastResponse structure contains the following information:
-
-       KrbFastResponse ::= SEQUENCE {
-           padata         [0] SEQUENCE OF PA-DATA,
-               -- padata typed holes.
-           strengthen-key [1] EncryptionKey OPTIONAL,
-               -- This, if present, strengthens the reply key for AS and
-               -- TGS.
-               -- MUST be absent in KRB-ERROR.
-           finished       [2] KrbFastFinished OPTIONAL,
-               -- Present in AS or TGS reply; absent otherwise.
-           nonce          [3] UInt32,
-               -- Nonce from the client request.
-           ...
-  }
-
-   The padata field in the KrbFastResponse structure contains a list of
-   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
-   PA-DATA structures are used to carry data advancing the exchange
-   specific for the FAST factors.  They can also be used as generic
-   typed-holes for protocol extensibility.  Unless otherwise specified,
-   the KDC MUST include any padata that is otherwise in the outer KDC-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 31]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   REP structure into this field.  The padata field in the KDC reply
-   structure outside of the PA-FX-FAST-REPLY structure typically
-   includes only the PA-FX- FAST-REPLY padata.
-
-   The strengthen-key field provides a mechanism for the KDC to
-   strengthen the reply key.  If set, the reply key is strengthened
-   after all padata items are processed.  Let padata-reply-key be the
-   reply key after padata processing.
-
-   reply-key = KRB-FX-CF2(strengthen-key, padata-reply-key,
-                         "strengthenkey", "replykey")
-
-   The strengthen-key field MAY be set in an AS or TGS reply; it must be
-   absent in an error reply.
-
-   The finished field contains a KrbFastFinished structure.  It is
-   filled by the KDC in the final message in the conversation.  This
-   field is present in an AS-REP or a TGS-REP when a ticket is returned,
-   and it is not present in an error reply.
-
-   The KrbFastFinished structure contains the following information:
-
-       KrbFastFinished ::= SEQUENCE {
-           timestamp       [0] KerberosTime,
-           usec            [1] Microseconds,
-               -- timestamp and usec represent the time on the KDC when
-               -- the reply was generated.
-           crealm          [2] Realm,
-           cname           [3] PrincipalName,
-               -- Contains the client realm and the client name.
-           ticket-checksum [4] Checksum,
-               -- checksum of the ticket in the KDC-REP  using the armor
-               -- and the key usage is KEY_USAGE_FAST_FINISH.
-               -- The checksum type is the required checksum type
-               -- of the armor key.
-           ...
-       }
-       KEY_USAGE_FAST_FINISHED            53
-
-   The timestamp and usec fields represent the time on the KDC when the
-   reply ticket was generated, these fields have the same semantics as
-   the corresponding-identically-named fields in Section 5.6.1 of
-   [RFC4120].  The client MUST use the KDC's time in these fields
-   thereafter when using the returned ticket.  Note that the KDC's time
-   in AS-REP may not match the authtime in the reply ticket if the kdc-
-   follow-referrals option is requested and honored by the KDC.  The
-   client need not confirm that the timestamp returned is within
-   allowable clock skew: the armor key guarantees that the reply is
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 32]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   fresh.  The client MAY trust the time stamp returned.
-
-   The cname and crealm fields identify the authenticated client.  If
-   facilities described in [REFERRALS] are used, the authenticated
-   client may differ from the client in the FAST request.
-
-   The ticket-checksum is a checksum of the issued ticket.  The checksum
-   key is the armor key, and the checksum type is the required checksum
-   type of the enctype of that key, and the key usage number is
-   KEY_USAGE_FAST_FINISHED.
-
-   When FAST padata is included, the PA-FX-COOKIE padata as defined in
-   Section 6.3 MUST be included in the padata sequence in the
-   KrbFastResponse sequence if the KDC expects at least one more message
-   from the client in order to complete the authentication.
-
-   The nonce field in the KrbFastResponse contains the value of the
-   nonce field in the KDC-REQ of the corresponding client request and it
-   binds the KDC response with the client request.  The client MUST
-   verify that this nonce value in the reply matches with that of the
-   request and reject the KDC reply otherwise.  To prevent the response
-   from one message in a conversation from being replayed to a request
-   in another message, clients SHOULD use a new nonce for each message
-   in a conversation.
-
-6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
-
-   If the Kerberos FAST padata was included in the request, unless
-   otherwise specified, the e-data field of the KRB-ERROR message
-   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
-   [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA.  The KDC
-   MUST include all the padata elements such as PA-ETYPE-INFO2 and
-   padata elements that indicate acceptable pre-authentication
-   mechanisms [RFC4120] in the KrbFastResponse structure.
-
-   The KDC MUST also include a PA-FX-ERROR padata item in the
-   KRBFastResponse structure.  The padata-value element of this sequence
-   is the ASN.1 DER encoding of the type KRB-ERROR.  The e-data field
-   MUST be absent in the PA-FX-ERROR padata.  All other fields should be
-   the same as the outer KRB-ERROR.  The client ignores the outer error
-   and uses the combination of the padata in the KRBFastResponse and the
-   error information in the PA-FX-ERROR.
-
-              PA-FX-ERROR                        137
-
-   If the Kerberos FAST padata is included in the request but not
-   included in the error reply, it is a matter of the local policy on
-   the client to accept the information in the error message without
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 33]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   integrity protection.  The client SHOULD however process the KDC
-   errors as the result of the KDC's inability to accept the AP_REQ
-   armor and potentially retry another request with a different armor
-   when applicable.  The Kerberos client MAY process an error message
-   without a PA-FX-FAST-REPLY, if that is only intended to return better
-   error information to the application, typically for trouble-shooting
-   purposes.
-
-   In the cases where the e-data field of the KRB-ERROR message is
-   expected to carry a TYPED-DATA [RFC4120] element, then that
-   information should be transmitted in a pa-data element within the
-   KRBFastResponse structure.  The padata-type is the same as the data-
-   type would be in the typed data element and the padata-value is the
-   same as the data-value.  As discussed in Section 8, data-types and
-   padata-types are drawn from the same namespace.  For example, the
-   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
-   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
-   [RFC4556].
-
-6.5.5.  Outer and Inner Requests
-
-   Typically, a client will know that FAST is being used before a
-   request containing PA-FX-FAST is sent.  So, the outer AS request
-   typically only includes one pa-data item: PA-FX-FAST.  The client MAY
-   include additional pa-data, but the KDC MUST ignore the outer request
-   body and any padata besides PA-FX-FAST if and only if PA-FX-FAST is
-   processed.  In the case of the TGS request, the outer request should
-   include PA-FX-FAST and PA-TGS-REQ.
-
-   When an AS generates a response, all padata besides PA-FX-FAST should
-   be included in PA-FX-FAST.  The client MUST ignore other padata
-   outside of PA-FX-FAST.
-
-6.5.6.  The Encrypted Challenge FAST Factor
-
-   The encrypted challenge FAST factor authenticates a client using the
-   client's long-term key.  This factor works similarly to the encrypted
-   time stamp pre-authentication option described in [RFC4120].  The
-   client encrypts a structure containing a timestamp in the challenge
-   key.  The challenge key used by the client to send a message to the
-   KDC is KRB-FX-CF2(armor_key,long_term_key, "clientchallengearmor",
-   "challengelongterm").  The challenge key used by the KDC encrypting
-   to the client is KRB-FX-CF2(armor_key, long_term_key,
-   "kdcchallengearmor", "challengelongterm").  Because the armor key is
-   fresh and random, the challenge key is fresh and random.  The only
-   purpose of the timestamp is to limit the validity of the
-   authentication so that a request cannot be replayed.  A client MAY
-   base the timestamp on the KDC time in a KDC error and need not
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 34]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   maintain accurate time synchronization itself.  If a client bases its
-   time on an untrusted source, an attacker may trick the client into
-   producing an authentication request that is valid at some future
-   time.  The attacker may be able to use this authentication request to
-   make it appear that a client has authenticated at that future time.
-   If ticket-based armor is used, then the lifetime of the ticket will
-   limit the window in which an attacker can make the client appear to
-   have authenticated.  For many situations, the ability of an attacker
-   to cause a client to appear to have authenticated is not a
-   significant concern; the ability to avoid requiring time
-   synchronization on clients is more valuable.
-
-   The client sends a padata of type PA-ENCRYPTED-CHALLENGE the
-   corresponding padata-value contains the DER encoding of ASN.1 type
-   EncryptedChallenge.
-
-      EncryptedChallenge ::= EncryptedData
-              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
-
-      PA-ENCRYPTED-CHALLENGE          138
-      KEY_USAGE_ENC_CHALLENGE_CLIENT  54
-      KEY_USAGE_ENC_CHALLENGE_KDC     55
-
-   The client includes some time stamp reasonably close to the KDC's
-   current time and encrypts it in the challenge key.  Clients MAY use
-   the current time; doing so prevents the exposure where an attacker
-   can cause a client to appear to authenticate in the future.  The
-   client sends the request including this factor.
-
-   On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE fast
-   factor, the KDC decrypts the timestamp.  If the decryption fails the
-   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in
-   the KRBFastResponse in the error.  The KDC confirms that the
-   timestamp falls within its current clock skew returning
-   KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see if the
-   encrypted challenge is a replay.  The KDC MUST NOT consider two
-   encrypted challenges replays simply because the time stamps are the
-   same; to be a replay, the ciphertext MUST be identical.  Allowing
-   clients to re-use time stamps avoids requiring that clients maintain
-   state about which time stamps have been used.
-
-   If the KDC accepts the encrypted challenge, it MUST include a padata
-   element of type PA-ENCRYPTED-CHALLENGE.  The KDC encrypts its current
-   time in the challenge key.  The KDC MUST strengthen the reply key
-   before issuing a ticket.  The client MUST check that the timestamp
-   decrypts properly.  The client MAY check that the timestamp is
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 35]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   winthin the window of acceptable clock skew for the client.  The
-   client MUST NOT require that the timestamp be identical to the
-   timestamp in the issued credentials or the returned message.
-
-   The encrypted challenge FAST factor provides the following
-   facilities: client-authentication and KDC authentication.  This FAST
-   factor also takes advantage of the FAST facility to strengthen the
-   reply key.  It does not provide the replacing-reply-key facility.
-   The security considerations section of this document provides an
-   explanation why the security requirements are met.
-
-   The encrypted challenge FAST factor can be useful in an
-   authentication set.  No pa-hint is defined because the only
-   information needed by this mechanism is information contained in the
-   PA-ETYPE-INFO2 pre-authentication data.  KDCs are already required to
-   send PA-ETYPE-INFO2.  If KDCs were not required to send PA-ETYPE-
-   INFO2 then that information would need to be part of a hint for
-   encrypted challenge.
-
-   Conforming implementations MUST support the encrypted challenge FAST
-   factor.
-
-6.6.  Authentication Strength Indication
-
-   Implementations that have pre-authentication mechanisms offering
-   significantly different strengths of client authentication MAY choose
-   to keep track of the strength of the authentication used as an input
-   into policy decisions.  For example, some principals might require
-   strong pre-authentication, while less sensitive principals can use
-   relatively weak forms of pre-authentication like encrypted timestamp.
-
-   An AuthorizationData data type AD-Authentication-Strength is defined
-   for this purpose.
-
-        AD-authentication-strength         70
-
-   The corresponding ad-data field contains the DER encoding of the pre-
-   authentication data set as defined in Section 6.4.  This set contains
-   all the pre-authentication mechanisms that were used to authenticate
-   the client.  If only one pre-authentication mechanism was used to
-   authenticate the client, the pre-authentication set contains one
-   element.
-
-   The AD-authentication-strength element MUST be included in the AD-IF-
-   RELEVANT, thus it can be ignored if it is unknown to the receiver.
-
-
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 36]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-7.  Assigned Constants
-
-   The pre-authentication framework and FAST involve using a number of
-   Kerberos protocol constants.  This section lists protocol constants
-   first introduced in this specification drawn from registries not
-   managed by IANA.  Many of these registries would best be managed by
-   IANA; that is a known issue that is out of scope for this document.
-   The constants described in this section have been accounted for and
-   will appear in the next revision of the Kerberos core specification
-   or in a document creating IANA registries.
-
-   Section 8 creates IANA registries for a different set of constants
-   used by the extensions described in this document.
-
-7.1.  New Errors
-
-           KDC_ERR_PREAUTH_EXPIRED                 90
-           KDC_ERR_MORE_PREAUTH_DATA_NEEDED        91
-           KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET  92
-           KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
-
-7.2.  Key Usage Numbers
-
-           KEY_USAGE_FAST_REQ_CHKSUM               50
-           KEY_USAGE_FAST_ENC                      51
-           KEY_USAGE_FAST_REP                      52
-           KEY_USAGE_FAST_FINISHED                 53
-           KEY_USAGE_ENC_CHALLENGE_CLIENT          54
-           KEY_USAGE_ENC_CHALLENGE_KDC             55
-
-7.3.  Authorization Data Elements
-
-           AD-authentication-strength              70
-           AD-fx-fast-armor                        71
-           AD-fx-fast-used                         72
-
-7.4.  New PA-DATA Types
-
-           PA-FX-COOKIE                            133
-           PA-AUTHENTICATION-SET                   134
-           PA-AUTH-SET-SELECTED                    135
-           PA-FX-FAST                              136
-           PA-FX-ERROR                             137
-           PA-ENCRYPTED-CHALLENGE                  138
-
-
-
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 37]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-8.  IANA Considerations
-
-   This document creates a number of IANA registries.  These registries
-   should all be located under
-   http://www.iana.org/assignments/kerberos-parameters.
-
-8.1.  Pre-authentication and Typed Data
-
-   RFC 4120 defines pre-authentication data, which can be included in a
-   KDC request or response in order to authenticate the client or extend
-   the protocol.  In addition, it defines Typed-Data which is an
-   extension mechanism for errors.  Both pre-authentication data and
-   typed data are carried as a 32-bit signed integer along with an octet
-   string.  The encoding of typed data and pre-authentication data is
-   slightly different.  However the types for pre-authentication data
-   and typed-data are drawn from the same namespace.  By convention,
-   registrations starting with TD- are typed data and registration
-   starting with PA- are pre-authentication data.  It is important that
-   these data types be drawn from the same namespace, because some
-   errors where it would be desirable to include typed data require the
-   e-data field to be formatted as pre-authentication data.
-
-   When Kerberos FAST is used, pre-authentication data encoding is
-   always used.
-
-   There is one apparently conflicting registration between typed data
-   and pre-authentication data.  PA-GET-FROM-TYPED-DATA and TD-PADATA
-   are both assigned the value 22.  However this registration is simply
-   a mechanism to include an element of the other encoding.  The use of
-   both should be deprecated.
-
-   This document creates a registry for pre-authentication and typed
-   data.  The registration procedures are as follows.  Expert review for
-   pre-authentication mechanisms designed to authenticate users, KDCs,
-   or establish the reply key.  The expert first determines that the
-   purpose of the method is to authenticate clients, KDCs, or to
-   establish the reply key.  If so, expert review is appropriate.  The
-   expert evaluates the security and interoperability of the
-   specification.
-
-   IETF review is required if the expert believes that the pre-
-   authentication method is broader than these three areas.  Pre-
-   authentication methods that change the Kerberos state machine or
-   otherwise make significant changes to the Kerberos protocol should be
-   standards track RFCs.  A concern that a particular method needs to be
-   a standards track RFC may be raised as an objection during IETF
-   review.
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 38]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-      Type                Value    Reference
-  ----------------------------------------------------------------------
-  PA-TGS-REQ                 1    RFC 4120
-  PA-ENC-TIMESTAMP           2    RFC 4120
-  PA-PW-SALT                 3    RFC 4120
-  [reserved]                 4
-  PA-ENC-UNIX-TIME           5    (deprecated)
-  PA-SANDIA-SECUREID         6
-  PA-SESAME                  7
-  PA-OSF-DCE                 8
-  PA-CYBERSAFE-SECUREID      9
-  PA-AFS3-SALT               10
-  PA-ETYPE-INFO              11   RFC 4120
-  PA-SAM-CHALLENGE           12   (sam/otp)
-  PA-SAM-RESPONSE            13   (sam/otp)
-  PA-PK-AS-REQ_OLD           14   draft-ietf-cat-kerberos-pk-init-09
-  PA-PK-AS-REP_OLD           15   draft-ietf-cat-kerberos-pk-init-09
-  PA-PK-AS-REQ               16   RFC 4556
-  PA-PK-AS-REP               17   RFC 4556
-  PA-PK-OCSP-RESPONSE        18   RFC 4557
-  PA-ETYPE-INFO2             19   RFC 4120
-  PA-USE-SPECIFIED-KVNO      20
-  PA-SVR-REFERRAL-INFO       20   (referrals)
-  PA-SAM-REDIRECT            21   (sam/otp)
-  PA-GET-FROM-TYPED-DATA     22   (embedded in typed data)
-  TD-PADATA                  22   (embeds padata)
-  PA-SAM-ETYPE-INFO          23   (sam/otp)
-  PA-ALT-PRINC               24   (crawdad@fnal.gov)
-  PA-SERVER-REFERRAL         25   (referrals)
-  PA-SAM-CHALLENGE2          30   (kenh@pobox.com)
-  PA-SAM-RESPONSE2           31   (kenh@pobox.com)
-  PA-EXTRA-TGT               41   Reserved extra TGT
-  TD-PKINIT-CMS-CERTIFICATES 101  CertificateSet from CMS
-  TD-KRB-PRINCIPAL           102  PrincipalName
-  TD-KRB-REALM               103  Realm
-  TD-TRUSTED-CERTIFIERS      104  PKINIT
-  TD-CERTIFICATE-INDEX       105  PKINIT
-  TD-APP-DEFINED-ERROR       106  Application specific
-  TD-REQ-NONCE               107  INTEGER
-  TD-REQ-SEQ                 108  INTEGER
-  PA-PAC-REQUEST             128  MS-KILE
-  PA-FOR_USER                129  MS-KILE
-  PA-FOR-X509-USER           130  MS-KILE
-  PA-FOR-CHECK_DUPS          131  MS-KILE
-  PA-AS-CHECKSUM             132  MS-KILE
-  PA-FX-COOKIE               133  draft-ietf-krb-wg-preauth-framework
-  PA-AUTHENTICATION-SET      134  draft-ietf-krb-wg-preauth-framework
-  PA-AUTH-SET-SELECTED       135  draft-ietf-krb-wg-preauth-framework
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 39]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-  PA-FX-FAST                 136  draft-ietf-krb-wg-preauth-framework
-  PA-FX-ERROR                137  draft-ietf-krb-wg-preauth-framework
-  PA-ENCRYPTED-CHALLENGE     138  draft-ietf-krb-wg-preauth-framework
-  PA-OTP-CHALLENGE           141  (gareth.richards@rsa.com)
-  PA-OTP-REQUEST             142  (gareth.richards@rsa.com)
-  PA-OTP-CONFIRM             143  (gareth.richards@rsa.com)
-  PA-OTP-PIN-CHANGE          144  (gareth.richards@rsa.com)
-  PA-EPAK-AS-REQ             145  (sshock@gmail.com)
-  PA-EPAK-AS-REP             146  (sshock@gmail.com>)
-  PA_PKINIT_KX               147  draft-ietf-krb-wg-anon
-  PA_PKU2U_NAME              148  draft-zhu-pku2u
-  PA-SUPPORTED-ETYPES        165  MS-KILE
-  PA-EXTENDED_ERROR          166  MS-KILE
-
-8.2.  Fast Armor Types
-
-   FAST armor types are defined in Section 6.5.1.  A FAST armor type is
-   a signed 32-bit integer.  FAST armor types are assigned by standards
-   action.
-
-          Type    Name                   Description
-        ------------------------------------------------------------
-          0                              Reserved.
-          1   FX_FAST_ARMOR_AP_REQUEST   Ticket armor using an ap-req.
-
-8.3.  FAST Options
-
-   A FAST request includes a set of bit flags to indicate additional
-   options.  Bits 0-15 are critical; other bits are non-critical.
-   Assigning bits greater than 31 may require special support in
-   implementations.  Assignment of FAST options requires standards
-   action.
-
-      Type    Name                   Description
-     -------------------------------------------------------------------
-      0     RESERVED               Reserved for future expansion of this
-                                   field.
-      1     hide-client-names      Requesting the KDC to hide client
-                                   names in  the KDC response
-      16    kdc-follow-referrals   Requesting the KDC to follow
-                                   referrals
-
-
-9.  Security Considerations
-
-   The kdc-referrals option in the Kerberos FAST padata requests the KDC
-   to act as the client to follow referrals.  This can overload the KDC.
-   To limit the damages of denial of service using this option, KDCs MAY
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 40]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   restrict the number of simultaneous active requests with this option
-   for any given client principal.
-
-   With regarding to the facilities provided by the Encrypted Challenge
-   FAST factor, the challenge key is derived from the client secrets and
-   because the client secrets are known only to the client and the KDC,
-   the verification of the EncryptedChallenge structure proves the
-   client's identity, the verification of the EncryptedChallenge
-   structure in the KDC reply proves that the expected KDC responded.
-   Therefore, the Encrypted Challenge FAST factor as a pre-
-   authentication mechanism offers the following facilities: client-
-   authentication and KDC-authentication.  There is no un-authenticated
-   clear text introduced by the Encrypted Challenge FAST factor.
-
-   FAST provides an encrypted tunnel over which pre-authentication
-   conversations can take place.  In addition, FAST optionally
-   authenticates the KDC to the client.  It is the responsibility of
-   FAST factors to authenticate the client to the KDC.  Care MUST be
-   taken to design FAST factors such that they are bound to the
-   conversation.  If this is not done, a man-in-the-middle may be able
-   to cut&paste a fast factor from one conversation to another.  The
-   easiest way to do this is to bind each fast factor to the armor key
-   which is guaranteed to be unique for each conversation.
-
-   The anonymous pkinit mode for obtaining an armor ticket does not
-   always authenticate the KDC to the client before the conversation
-   begins.  Tracking the KDC verified state guarantees that by the end
-   of the conversation, the client has authenticated the KDC.  However
-   fast factor designers need to consider the implications of using
-   their factor when the KDC has not yet been authenticated.  If this
-   proves problematic in an environment, then the particular fast factor
-   should not be used with anonymous PKINIT.
-
-   Existing pre-authentication mechanisms are believed to be at least as
-   secure when used with FAST as they are when used outside of FAST.
-   One part of this security is making sure that when pre-authentication
-   methods checksum the request, they checksum the inner request rather
-   than the outer request.  If the mechanism checksummed the outer
-   request, a man-in-the-middle could observe it outside a FAST tunnel
-   and then cut&paste it into a FAST exchange where the inner rather
-   than outer request would be used to select attributes of the issued
-   ticket.  Such attacks would typically invalidate auditing information
-   or create a situation where the client and KDC disagree about what
-   ticket is issued.  However, such attacks are unlikely to allow an
-   attacker who would not be able to authenticate as a principal to do
-   so.  Even so, FAST is believed to defend against these attacks in
-   existing legacy mechanism.  However since there is no standard for
-   how legacy mechanisms bind the request to the pre-authentication or
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 41]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   provide integrity protection, security analysis can be difficult.  In
-   some cases FAST may significantly improve the integrity protection of
-   legacy mechanisms.
-
-
-10.  Acknowledgements
-
-   Sam Hartman would like to thank the MIT Kerberos Consortium for its
-   funding of his time on this project.
-
-   Several suggestions from Jeffrey Hutzelman based on early revisions
-   of this documents led to significant improvements of this document.
-
-   The proposal to ask one KDC to chase down the referrals and return
-   the final ticket is based on requirements in [ID.CROSS].
-
-   Joel Webber had a proposal for a mechanism similar to FAST that
-   created a protected tunnel for Kerberos pre-authentication.
-
-   Srinivas Cheruku and Greg Hudson provided valuable review comments.
-
-
-11.  References
-
-11.1.  Normative References
-
-   [KRB-ANON]
-              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
-              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-11.2.  Informative References
-
-   [ID.CROSS]
-              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
-              Statement on the Operation of Kerberos in a Specific
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 42]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-              System", draft-sakane-krb-cross-problem-statement-02.txt
-              (work in progress), April 2007.
-
-   [KRB-WG.SAM]
-              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
-              "Integrating Single-use Authentication Mechanisms with
-              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
-              progress), October 2003.
-
-   [REFERRALS]
-              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
-              Locate Kerberos Realms",
-              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
-              progress), 2007.
-
-
-Appendix A.  Test Vectors for KRB-FX-CF2
-
-   This informative appendix presents test vectors for the KRB-FX-CF2
-   function.  Test vectors are presented for several encryption types.
-   In all cases the first key (k1) is the result of string-to-
-   key("key1", "key1", default_parameters) and the second key (k2) is
-   the result of string-to-key("key2", "key2", default_parameters).
-   Both keys are of the same enctype.  The presented test vector is the
-   hexadecimal encoding of the key produced by KRB-FX-CF2(k1, k2, "a",
-   "b").  The peppers are one-octet ASCII strings.
-
-   In performing interoperability testing, there was significant
-   ambiguity surrounding [RFC3961] pseudo-random operations.  These test
-   vectors assume that the AES pseudo-random operation is aes-
-   ecb(trunc128(sha-1(input))) where trunc128 truncates its input to
-   128-bits.  The 3DES pseudo-random operation is assumed to be des3-
-   cbc(trunc128(sha-1(input))).  The DES pseudo-random operation is
-   assumed to be des-cbc(md5(input).  As specified in RFC 4757, the RC4
-   pseudo-random operation is hmac-sha1(input).
-
-   These test vectors were produced with revision 22359 of the MIT
-   Kerberos sources.  The AES 256 and AES 128 test vectors have been
-   confirmed by another implementer.  The RC4 implementation of KRB-FX-
-   CF2 from that revision of MIT Kerberos worked against another
-   implementation during an interoperability event, although these
-   specific test vectors have not been confirmed.  The DES and triple
-   DES test vectors have not been confirmed.
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 43]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-   aes 128 (enctype 17): 97df97e4b798b29eb31ed7280287a92a
-   AES256 (enctype 18): 4d6ca4e629785c1f01baf55e2e548566
-                        b9617ae3a96868c337cb93b5e72b1c7b
-   DES (enctype 1): 43bae3738c9467e6
-   3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01
-   RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672
-
-
-Appendix B.  Change History
-
-   RFC editor, please remove this section before publication.
-
-B.1.  Changes since 11
-
-      Checksum the inner request body in methods like PKINIT, not the
-      outer request body.  Per mailing list discussion, this change
-      addresses a potential security weakness.
-      Add additional security considerations text
-
-B.2.  Changes since 10
-
-      The checksum member of the KrbFastFinished sequence has been
-      removed.  A nonce field has been added to KrbFastResponse.
-      The cookie no longer needs to be outside of FAST.  In fact, some
-      security guarantees depend on the cookie being inside FAST now
-      that the finish checksum has been removed.  Affected that change.
-      Replace the rep-key field in KrbFastResponse with the strengthen-
-      key field.  Per mailing list discussion, there are security
-      advantages to strengthening the reply key.
-      Clarify handling of authentication sets.
-      Include the AD-fx-fast-used authorization data type.
-      Include note about random nonces.
-
-B.3.  Changes since 09
-
-      Clarify conversations by defining for TGS and by describing how
-      cookies form conversation boundaries.
-      Simplify text surrounding when finish is included: always for AS
-      and TGS reply, never for error.
-      Fill in IANA and constants
-
-B.4.  Changes since 08
-
-      Fix a number of typos
-      Rename anonymous flag to hide-client-name; rename kdc-referals to
-      kdc-follow-referrals
-
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 44]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-      Clarify how anonymous pkinit interacts with KDC verified.
-      Introduce AD-fx-fast-armor authorization data to deal with
-      unprivileged processes constructing KDC requests.  Note that a TGT
-      is always used for armor tickets if the armor field is present; if
-      you proxy or validate you'll end up with a TGT armor ticket and
-      another ticket in the pa-tgs-req.  Alternatively you can simply
-      use the other ticket in the PA-TGS-REQ; weak consensus within WG.
-      All KDCs in a realm MUST support FAST if it is to be offered.
-      The cookie message is always generated by the KDC.
-      Note that the client can trust and need not verify the time stamp
-      in the finish message.  This can seed the client's idea of KDC
-      time.
-      Note that the client name in the finish message may differ from
-      the name in the request if referrals are used.
-      Note that KDCs should advertize fast in preauth_required errors.
-      Armor key is constructed using KRB-FX-CF2.  This is true even in
-      the TGS case; there is no security reason to do this.  Using the
-      subkey as done in draft 08 would be fine, but the current text
-      uses the same procedure both in the TGS and AS case.
-      Use a different challenge key in each direction in the encrypted
-      challenge option.
-      Note that the KDC should process PA-FX-COOKIE before other padata.
-      KRB-FX-CF2 uses k1's enctype for the result; change around calling
-      order so we pass in subkeys and armor keys as k1 in preference to
-      long-term keys or ticket session keys.
-      Clarify the relationship between authentication sets and cookies.
-      A cookie may not be needed in the first message.  Clarify how this
-      interacts with optimistic clients.
-      Remove text raising a concern that RFC 3961 may permit ciphertext
-      transformations that do not change plaintext: discussion on the
-      list came to the conclusion that RFC 3961 does not permit this.
-      Remove binding key concept; use the armor key instead.  The cookie
-      becomes just an octet string.
-      Include PA-FX-ERROR to protect the error information per Dublin.
-      Returning preauth_failed in the failed to decrypt encrypted
-      challenge seems fine; remove the issue marker
-      Add a section describing what goes in the inner and outer request.
-      I believe it is redundant but found it useful while putting
-      together an implementation proposal.
-      Use hyphen rather than underscore in the constants for pre-
-      authentication data to be consistent with RFC 4120.
-      Add a ticket-checksum to the finished message
-      Remove redundant KEY_USAGE_FAST_ARMOR.
-      Add protocol constants section for non-IANA registrations and
-      flesh out IANA section.
-      Clarify that kdc-req-body checksums should always use the outer
-      body even for mechanisms like PKINIT that include their own (now
-      redundant) checksum.
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 45]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-      Remove mechanism for encapsulating typed data in padata; just
-      reflect the value.
-
-B.5.  Changes since 07
-
-      Propose replacement of authenticated timestamp with encrypted
-      challenge.  The desire to avoid clients needing time
-      synchronization and to simply the factor.
-      Add a requirement that any FAST armor scheme must provide a fresh
-      key for each conversation.  This allows us to assume that anything
-      encrypted/integrity protected in the right key is fresh and not
-      subject to cross-conversation cut and paste.
-      Removed heartbeat padata.  The KDC will double up messages if it
-      needs to; the client simply sends its message and waits for the
-      next response.
-      Define PA-AUTH-SET-SELECTED
-      Clarify a KDC cannot ignore padata is has claimed to support
-
-B.6.  Changes since 06
-
-      Note that even for replace reply key it is likely that the side
-      using the mechanism will know that the other side supports it.
-      Since it is reasonably unlikely we'll need a container mechanism
-      other than FAST itself, we don't need to optimize for that case.
-      So, we want to optimize for implementation simplicity.  Thus if
-      you do have such a container mechanism interacting with
-      authentication sets we'll assume that the hint need to describe
-      hints for all contained mechanisms.  This closes out a long-
-      standing issue.
-      Write up what Sam believes is the consensus on UI and prompts in
-      the authentication set: clients MAY assume that they have all the
-      UI information they need.
-
-
-Appendix C.  ASN.1 module
-
-      KerberosPreauthFramework {
-            iso(1) identified-organization(3) dod(6) internet(1)
-            security(5) kerberosV5(2) modules(4) preauth-framework(3)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      IMPORTS
-           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
-           Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
-           Microseconds, KerberosFlags
-                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                  dod(6) internet(1) security(5) kerberosV5(2)
-                  modules(4) krb5spec2(2) };
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 46]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-                  -- as defined in RFC 4120.
-
-
-      PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-      PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-          pa-type      [0] Int32,
-              -- same as padata-type.
-          pa-hint      [1] OCTET STRING OPTIONAL,
-          pa-value     [2] OCTET STRING OPTIONAL,
-          ...
-      }
-
-      KrbFastArmor ::= SEQUENCE {
-          armor-type   [0] Int32,
-              -- Type of the armor.
-          armor-value  [1] OCTET STRING,
-              -- Value of the armor.
-          ...
-      }
-
-      PA-FX-FAST-REQUEST ::= CHOICE {
-          armored-data [0] KrbFastArmoredReq,
-          ...
-      }
-
-      KrbFastArmoredReq ::= SEQUENCE {
-          armor        [0] KrbFastArmor OPTIONAL,
-              -- Contains the armor that identifies the armor key.
-              -- MUST be present in AS-REQ.
-          req-checksum [1] Checksum,
-              -- For AS, contains the checksum performed over the type
-              -- KDC-REQ-BODY for the req-body field of the KDC-REQ
-              -- structure;
-              -- For TGS, contains the checksum performed over the type
-              -- AP-REQ in the PA-TGS-REQ padata.
-              -- The checksum key is the armor key, the checksum
-              -- type is the required checksum type for the enctype of
-              -- the armor key, and the key usage number is
-              -- KEY_USAGE_FAST_REQ_CHKSUM.
-          enc-fast-req [2] EncryptedData, -- KrbFastReq --
-              -- The encryption key is the armor key, and the key usage
-              -- number is KEY_USAGE_FAST_ENC.
-          ...
-      }
-
-      KrbFastReq ::= SEQUENCE {
-          fast-options [0] FastOptions,
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 47]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-              -- Additional options.
-          padata       [1] SEQUENCE OF PA-DATA,
-              -- padata typed holes.
-          req-body     [2] KDC-REQ-BODY,
-              -- Contains the KDC request body as defined in Section
-              -- 5.4.1 of [RFC4120].
-              -- This req-body field is preferred over the outer field
-              -- in the KDC request.
-           ...
-      }
-
-      FastOptions ::= KerberosFlags
-          -- reserved(0),
-          -- hide-client-names(1),
-          -- kdc-follow-referrals(16)
-
-      PA-FX-FAST-REPLY ::= CHOICE {
-          armored-data [0] KrbFastArmoredRep,
-          ...
-      }
-
-      KrbFastArmoredRep ::= SEQUENCE {
-          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
-              -- The encryption key is the armor key in the request, and
-              -- the key usage number is KEY_USAGE_FAST_REP.
-          ...
-      }
-
-      KrbFastResponse ::= SEQUENCE {
-          padata         [0] SEQUENCE OF PA-DATA,
-              -- padata typed holes.
-          strengthen-key [1] EncryptionKey OPTIONAL,
-              -- This, if present, strengthens the reply key for AS and
-              -- TGS.
-              -- MUST be absent in KRB-ERROR.
-          finished       [2] KrbFastFinished OPTIONAL,
-              -- Present in AS or TGS reply; absent otherwise.
-          nonce          [3] UInt32,
-              -- Nonce from the client request.
-          ...
-      }
-
-      KrbFastFinished ::= SEQUENCE {
-          timestamp       [0] KerberosTime,
-          usec            [1] Microseconds,
-              -- timestamp and usec represent the time on the KDC when
-              -- the reply was generated.
-          crealm          [2] Realm,
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 48]
-
-Internet-Draft         Kerberos Preauth Framework              June 2009
-
-
-          cname           [3] PrincipalName,
-              -- Contains the client realm and the client name.
-          ticket-checksum [4] Checksum,
-              -- checksum of the ticket in the KDC-REP  using the armor
-              -- and the key usage is KEY_USAGE_FAST_FINISH.
-              -- The checksum type is the required checksum type
-              -- of the armor key.
-          ...
-      }
-
-      EncryptedChallenge ::= EncryptedData
-              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
-      END
-
-
-Authors' Addresses
-
-   Sam hartman
-   Painless Security
-
-   Email: hartmans-ietf@mit.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires December 6, 2009               [Page 49]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-13.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-13.txt
deleted file mode 100644
index b045c97c0..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-13.txt
+++ /dev/null
@@ -1,2803 +0,0 @@
-
-
-
-Kerberos Working Group                                        S. Hartman
-Internet-Draft                                         Painless Security
-Updates: 4120 (if approved)                                       L. Zhu
-Intended status: Standards Track                   Microsoft Corporation
-Expires: January 30, 2010                                  July 29, 2009
-
-
-        A Generalized Framework for Kerberos Pre-Authentication
-                 draft-ietf-krb-wg-preauth-framework-13
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 30, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   Kerberos is a protocol for verifying the identity of principals
-   (e.g., a workstation user or a network server) on an open network.
-
-
-
-Hartman & Zhu           Expires January 30, 2010                [Page 1]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   The Kerberos protocol provides a mechanism called pre-authentication
-   for proving the identity of a principal and for better protecting the
-   long-term secrets of the principal.
-
-   This document describes a model for Kerberos pre-authentication
-   mechanisms.  The model describes what state in the Kerberos request a
-   pre-authentication mechanism is likely to change.  It also describes
-   how multiple pre-authentication mechanisms used in the same request
-   will interact.
-
-   This document also provides common tools needed by multiple pre-
-   authentication mechanisms.  One of these tools is a secure channel
-   between the client and the KDC with a reply key strengthening
-   mechanism; this secure channel can be used to protect the
-   authentication exchange thus eliminate offline dictionary attacks.
-   With these tools, it is relatively straightforward to chain multiple
-   authentication mechanisms, utilize a different key management system,
-   or support a new key agreement algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010                [Page 2]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Conventions and Terminology Used in This Document  . . . . . .  6
-   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  6
-     3.1.  Information Managed by the Pre-authentication Model  . . .  7
-     3.2.  Initial Pre-authentication Required Error  . . . . . . . . 10
-     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . . 10
-     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 11
-   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 12
-     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 13
-     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 14
-     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 15
-     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 15
-   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 16
-   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 17
-     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 17
-     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 18
-     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 19
-     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 20
-     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 23
-       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 24
-       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 26
-       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 30
-       6.5.4.  Authenticated Kerberos Error Messages using
-               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 33
-       6.5.5.  Outer and Inner Requests . . . . . . . . . . . . . . . 34
-       6.5.6.  The Encrypted Challenge FAST Factor  . . . . . . . . . 34
-     6.6.  Authentication Strength Indication . . . . . . . . . . . . 36
-   7.  Assigned Constants . . . . . . . . . . . . . . . . . . . . . . 37
-     7.1.  New Errors . . . . . . . . . . . . . . . . . . . . . . . . 37
-     7.2.  Key Usage Numbers  . . . . . . . . . . . . . . . . . . . . 37
-     7.3.  Authorization Data Elements  . . . . . . . . . . . . . . . 37
-     7.4.  New PA-DATA Types  . . . . . . . . . . . . . . . . . . . . 38
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
-     8.1.  Pre-authentication and Typed Data  . . . . . . . . . . . . 38
-     8.2.  Fast Armor Types . . . . . . . . . . . . . . . . . . . . . 40
-     8.3.  FAST Options . . . . . . . . . . . . . . . . . . . . . . . 40
-   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 41
-   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 43
-     11.2. Informative References . . . . . . . . . . . . . . . . . . 43
-   Appendix A.  Test Vectors for KRB-FX-CF2 . . . . . . . . . . . . . 44
-   Appendix B.  Change History  . . . . . . . . . . . . . . . . . . . 44
-     B.1.  Changes since 12 . . . . . . . . . . . . . . . . . . . . . 45
-     B.2.  Changes since 11 . . . . . . . . . . . . . . . . . . . . . 45
-     B.3.  Changes since 10 . . . . . . . . . . . . . . . . . . . . . 45
-
-
-
-Hartman & Zhu           Expires January 30, 2010                [Page 3]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-     B.4.  Changes since 09 . . . . . . . . . . . . . . . . . . . . . 45
-     B.5.  Changes since 08 . . . . . . . . . . . . . . . . . . . . . 45
-     B.6.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 47
-     B.7.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 47
-   Appendix C.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 47
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010                [Page 4]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-1.  Introduction
-
-   The core Kerberos specification [RFC4120] treats pre-authentication
-   data as an opaque typed hole in the messages to the KDC that may
-   influence the reply key used to encrypt the KDC reply.  This
-   generality has been useful: pre-authentication data is used for a
-   variety of extensions to the protocol, many outside the expectations
-   of the initial designers.  However, this generality makes designing
-   more common types of pre-authentication mechanisms difficult.  Each
-   mechanism needs to specify how it interacts with other mechanisms.
-   Also, problems like combining a key with the long-term secrets or
-   proving the identity of the user are common to multiple mechanisms.
-   Where there are generally well-accepted solutions to these problems,
-   it is desirable to standardize one of these solutions so mechanisms
-   can avoid duplication of work.  In other cases, a modular approach to
-   these problems is appropriate.  The modular approach will allow new
-   and better solutions to common pre-authentication problems to be used
-   by existing mechanisms as they are developed.
-
-   This document specifies a framework for Kerberos pre-authentication
-   mechanisms.  It defines the common set of functions that pre-
-   authentication mechanisms perform as well as how these functions
-   affect the state of the request and reply.  In addition several
-   common tools needed by pre-authentication mechanisms are provided.
-   Unlike [RFC3961], this framework is not complete--it does not
-   describe all the inputs and outputs for the pre-authentication
-   mechanisms.  Pre-Authentication mechanism designers should try to be
-   consistent with this framework because doing so will make their
-   mechanisms easier to implement.  Kerberos implementations are likely
-   to have plugin architectures for pre-authentication; such
-   architectures are likely to support mechanisms that follow this
-   framework plus commonly used extensions.  This framework also
-   facilitates combining multiple pre-authentication mechanisms, each of
-   which may represent an authentication factor, into a single multi-
-   factor pre-authentication mechanism.
-
-   One of these common tools is the flexible authentication secure
-   tunneling (FAST) padata type.  FAST provides a protected channel
-   between the client and the KDC, and it can optionally deliver key
-   material used to strengthen the reply key within the protected
-   channel.  Based on FAST, pre-authentication mechanisms can extend
-   Kerberos with ease, to support, for example, password authenticated
-   key exchange (PAKE) protocols with zero knowledge password proof
-   (ZKPP) [EKE] [IEEE1363.2].  Any pre-authentication mechanism can be
-   encapsulated in the FAST messages as defined in Section 6.5.  A pre-
-   authentication type carried within FAST is called a FAST factor.
-   Creating a FAST factor is the easiest path to create a new pre-
-   authentication mechanism.  FAST factors are significantly easier to
-
-
-
-Hartman & Zhu           Expires January 30, 2010                [Page 5]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   analyze from a security standpoint than other pre-authentication
-   mechanisms.
-
-   Mechanism designers should design FAST factors, instead of new pre-
-   authentication mechanisms outside of FAST.
-
-
-2.  Conventions and Terminology Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   This document should be read only after reading the documents
-   describing the Kerberos cryptography framework [RFC3961] and the core
-   Kerberos protocol [RFC4120].  This document may freely use
-   terminology and notation from these documents without reference or
-   further explanation.
-
-   The word padata is used as a shorthand for pre-authentication data.
-
-   A conversation is the set of all authentication messages exchanged
-   between the client and the client's Authentication Service (AS) in
-   order to authenticate the client principal.  A conversation as
-   defined here consists of all messages that are necessary to complete
-   the authentication between the client and the client's AS.  In the
-   Ticket Exchange Service (TGS) exchange, a conversation consists of
-   the request message and the reply message.  The term conversation is
-   defined here for both AS and TGS for convenience of discussion.  See
-   Section 6.3 for specific rules on the extent of a conversation in the
-   AS-REQ case.  Prior to this framework, implementations needed to use
-   implementation-specific heuristics to determine the extent of a
-   conversation.
-
-   If the KDC reply in an AS exchange is verified, the KDC is
-   authenticated by the client.  In this document, verification of the
-   KDC reply is used as a synonym of authentication of the KDC.
-
-
-3.  Model for Pre-Authentication
-
-   When a Kerberos client wishes to obtain a ticket using the
-   authentication server, it sends an initial Authentication Service
-   (AS) request.  If pre-authentication is required but not being used,
-   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
-   Alternatively, if the client knows what pre-authentication to use, it
-   MAY optimize away a round-trip and send an initial request with
-   padata included in the initial request.  If the client includes the
-
-
-
-Hartman & Zhu           Expires January 30, 2010                [Page 6]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   padata computed using the wrong pre-authentication mechanism or
-   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
-   indication of what padata should have been included.  In that case,
-   the client MUST retry with no padata and examine the error data of
-   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
-   authentication information in the accompanying error data of
-   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
-   then retry.
-
-   The conventional KDC maintains no state between two requests;
-   subsequent requests may even be processed by a different KDC.  On the
-   other hand, the client treats a series of exchanges with KDCs as a
-   single conversation.  Each exchange accumulates state and hopefully
-   brings the client closer to a successful authentication.
-
-   These models for state management are in apparent conflict.  For many
-   of the simpler pre-authentication scenarios, the client uses one
-   round trip to find out what mechanisms the KDC supports.  Then the
-   next request contains sufficient pre-authentication for the KDC to be
-   able to return a successful reply.  For these simple scenarios, the
-   client only sends one request with pre-authentication data and so the
-   conversation is trivial.  For more complex conversations, the KDC
-   needs to provide the client with a cookie to include in future
-   requests to capture the current state of the authentication session.
-   Handling of multiple round-trip mechanisms is discussed in
-   Section 6.3.
-
-   This framework specifies the behavior of Kerberos pre-authentication
-   mechanisms used to identify users or to modify the reply key used to
-   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
-   extensions to Kerberos that have nothing to do with proving the
-   identity of the user or establishing a reply key.  Such extensions
-   are outside the scope of this framework.  However mechanisms that do
-   accomplish these goals should follow this framework.
-
-   This framework specifies the minimum state that a Kerberos
-   implementation needs to maintain while handling a request in order to
-   process pre-authentication.  It also specifies how Kerberos
-   implementations process the padata at each step of the AS request
-   process.
-
-3.1.  Information Managed by the Pre-authentication Model
-
-   The following information is maintained by the client and KDC as each
-   request is being processed:
-
-
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010                [Page 7]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   o  The reply key used to encrypt the KDC reply
-
-   o  How strongly the identity of the client has been authenticated
-
-   o  Whether the reply key has been used in this conversation
-
-   o  Whether the reply key has been replaced in this conversation
-
-   o  Whether the origin of the KDC reply can be verified by the client
-      (i.e. whether the KDC is authenticated to the client)
-
-
-   Conceptually, the reply key is initially the long-term key of the
-   principal.  However, principals can have multiple long-term keys
-   because of support for multiple encryption types, salts and
-   string2key parameters.  As described in Section 5.2.7.5 of the
-   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
-   the client what types of keys are available.  Thus in full
-   generality, the reply key in the pre-authentication model is actually
-   a set of keys.  At the beginning of a request, it is initialized to
-   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
-   the KDC.  If multiple reply keys are available, the client chooses
-   which one to use.  Thus the client does not need to treat the reply
-   key as a set.  At the beginning of a request, the client picks a key
-   to use.
-
-   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
-   INFO2 element.  Since the KDC already knows the client's list of
-   supported enctypes from the request, no interoperability problems are
-   created by choosing a single possible reply key.  This way, the KDC
-   implementation avoids the complexity of treating the reply key as a
-   set.
-
-   When the padata in the request is verified by the KDC, then the
-   client is known to have that key, therefore the KDC SHOULD pick the
-   same key as the reply key.
-
-   At the beginning of handling a message on both the client and the
-   KDC, the client's identity is not authenticated.  A mechanism may
-   indicate that it has successfully authenticated the client's
-   identity.  This information is useful to keep track of on the client
-   in order to know what pre-authentication mechanisms should be used.
-   The KDC needs to keep track of whether the client is authenticated
-   because the primary purpose of pre-authentication is to authenticate
-   the client identity before issuing a ticket.  The handling of
-   authentication strength using various authentication mechanisms is
-   discussed in Section 6.6.
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010                [Page 8]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   Initially the reply key has not been used.  A pre-authentication
-   mechanism that uses the reply key to encrypt or checksum some data in
-   the generation of new keys MUST indicate that the reply key is used.
-   This state is maintained by the client and the KDC to enforce the
-   security requirement stated in Section 4.3 that the reply key SHOULD
-   NOT be replaced after it is used.
-
-   Initially the reply key has not been replaced.  If a mechanism
-   implements the Replace Reply Key facility discussed in Section 4.3,
-   then the state MUST be updated to indicate that the reply key has
-   been replaced.  Once the reply key has been replaced, knowledge of
-   the reply key is insufficient to authenticate the client.  The reply
-   key is marked replaced in exactly the same situations as the KDC
-   reply is marked as not being verified to the client principal.
-   However, while mechanisms can verify the KDC reply to the client,
-   once the reply key is replaced, then the reply key remains replaced
-   for the remainder of the conversation.
-
-   Without pre-authentication, the client knows that the KDC reply is
-   authentic and has not been modified because it is encrypted in a
-   long-term key of the client.  Only the KDC and the client know that
-   key.  So at the start of a conversation, the KDC reply is presumed to
-   be verified using the client's long-term key.  It should be noted
-   that in this document, verifying the KDC reply means authenticating
-   the KDC, and these phrases are used interchangeably.  Any pre-
-   authentication mechanism that sets a new reply key not based on the
-   principal's long-term secret MUST either verify the KDC reply some
-   other way or indicate that the reply is not verified.  If a mechanism
-   indicates that the reply is not verified then the client
-   implementation MUST return an error unless a subsequent mechanism
-   verifies the reply.  The KDC needs to track this state so it can
-   avoid generating a reply that is not verified.
-
-   In this specification, KDC verification/authentication refers to the
-   level of authentication of the KDC to the client provided by RFC
-   4120.  There is a stronger form of KDC verification that, while
-   sometimes important in Kerberos deployments is not addressed in this
-   specification: the typical Kerberos request does not provide a way
-   for the client machine to know that it is talking to the correct KDC.
-   Someone who can inject packets into the network between the client
-   machine and the KDC and who knows the password that the user will
-   give to the client machine can generate a KDC reply that will decrypt
-   properly.  So, if the client machine needs to authenticate that the
-   user is in fact the named principal, then the client machine needs to
-   do a TGS request for itself as a service.  Some pre-authentication
-   mechanisms may provide a way for the client machine to authenticate
-   the KDC.  Examples of this include signing the reply that can be
-   verified using a well-known public key or providing a ticket for the
-
-
-
-Hartman & Zhu           Expires January 30, 2010                [Page 9]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   client machine as a service.
-
-3.2.  Initial Pre-authentication Required Error
-
-   Typically a client starts a conversation by sending an initial
-   request with no pre-authentication.  If the KDC requires pre-
-   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
-   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
-   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED
-   (defined in Section 6.3) for pre-authentication configurations that
-   use multi-round-trip mechanisms; see Section 3.4 for details of that
-   case.
-
-   The KDC needs to choose which mechanisms to offer the client.  The
-   client needs to be able to choose what mechanisms to use from the
-   first message.  For example consider the KDC that will accept
-   mechanism A followed by mechanism B or alternatively the single
-   mechanism C. A client that supports A and C needs to know that it
-   should not bother trying A.
-
-   Mechanisms can either be sufficient on their own or can be part of an
-   authentication set--a group of mechanisms that all need to
-   successfully complete in order to authenticate a client.  Some
-   mechanisms may only be useful in authentication sets; others may be
-   useful alone or in authentication sets.  For the second group of
-   mechanisms, KDC policy dictates whether the mechanism will be part of
-   an authentication set, offered alone, or both.  For each mechanism
-   that is offered alone (even if it is also offered in an
-   authentication set), the KDC includes the pre-authentication type ID
-   of the mechanism in the padata sequence returned in the
-   KDC_ERR_PREAUTH_REQUIRED error.  Mechanisms that are only offered as
-   part of an authentication set are not directly represented in the
-   padata sequence returned in the KDC_ERR_PREAUTH_REQUIRED error,
-   although they are represented in the PA-AUTHENTICATION-SET sequence.
-
-   The KDC SHOULD NOT send data that is encrypted in the long-term
-   password-based key of the principal.  Doing so has the same security
-   exposures as the Kerberos protocol without pre-authentication.  There
-   are few situations where the KDC needs to expose cipher text
-   encrypted in a weak key before the client has proven knowledge of
-   that key, and pre-authentication is desirable.
-
-3.3.  Client to KDC
-
-   This description assumes that a client has already received a
-   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
-   optimistic pre-authentication then the client needs to guess values
-   for the information it would normally receive from that error
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 10]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   response or use cached information obtained in prior interactions
-   with the KDC.
-
-   The client starts by initializing the pre-authentication state as
-   specified.  It then processes the padata in the
-   KDC_ERR_PREAUTH_REQUIRED.
-
-   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
-   client MAY ignore any padata it chooses unless doing so violates a
-   specification to which the client conforms.  Clients conforming to
-   this specification MUST NOT ignore the padata defined in Section 6.3.
-   Clients SHOULD process padata unrelated to this framework or other
-   means of authenticating the user.  Clients SHOULD choose one
-   authentication set or mechanism that could lead to authenticating the
-   user and ignore the rest.  Since the list of mechanisms offered by
-   the KDC is in the decreasing preference order, clients typically
-   choose the first mechanism or authentication set that the client can
-   usefully perform.  If a client chooses to ignore a padata it MUST NOT
-   process the padata, allow the padata to affect the pre-authentication
-   state, nor respond to the padata.
-
-   For each padata the client chooses to process, the client processes
-   the padata and modifies the pre-authentication state as required by
-   that mechanism.  Padata are processed in the order received from the
-   KDC.
-
-   After processing the padata in the KDC error, the client generates a
-   new request.  It processes the pre-authentication mechanisms in the
-   order in which they will appear in the next request, updating the
-   state as appropriate.  The request is sent when it is complete.
-
-3.4.  KDC to Client
-
-   When a KDC receives an AS request from a client, it needs to
-   determine whether it will respond with an error or an AS reply.
-   There are many causes for an error to be generated that have nothing
-   to do with pre-authentication; they are discussed in the core
-   Kerberos specification.
-
-   From the standpoint of evaluating the pre-authentication, the KDC
-   first starts by initializing the pre-authentication state.  If a PA-
-   FX-COOKIE pre-authentication data item is present, it is processed
-   first; see Section 6.3 for a definition.  It then processes the
-   padata in the request.  As mentioned in Section 3.3, the KDC MAY
-   ignore padata that is inappropriate for the configuration and MUST
-   ignore padata of an unknown type.  The KDC MUST NOT ignore padata of
-   types used in previous messages.  For example, if a KDC issues a
-   KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 11]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   KDC cannot ignore padata of type x received in an AS-REQ message from
-   the client.
-
-   At this point the KDC decides whether it will issue an error or a
-   reply.  Typically a KDC will issue a reply if the client's identity
-   has been authenticated to a sufficient degree.
-
-   In the case of a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error, the KDC
-   first starts by initializing the pre-authentication state.  Then it
-   processes any padata in the client's request in the order provided by
-   the client.  Mechanisms that are not understood by the KDC are
-   ignored.  Next, it generates padata for the error response, modifying
-   the pre-authentication state appropriately as each mechanism is
-   processed.  The KDC chooses the order in which it will generate
-   padata (and thus the order of padata in the response), but it needs
-   to modify the pre-authentication state consistently with the choice
-   of order.  For example, if some mechanism establishes an
-   authenticated client identity, then the subsequent mechanisms in the
-   generated response receive this state as input.  After the padata is
-   generated, the error response is sent.  Typically the errors with the
-   code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED in a conversation will
-   include KDC state as discussed in Section 6.3.
-
-   To generate a final reply, the KDC generates the padata modifying the
-   pre-authentication state as necessary.  Then it generates the final
-   response, encrypting it in the current pre-authentication reply key.
-
-
-4.  Pre-Authentication Facilities
-
-   Pre-Authentication mechanisms can be thought of as providing various
-   conceptual facilities.  This serves two useful purposes.  First,
-   mechanism authors can choose only to solve one specific small
-   problem.  It is often useful for a mechanism designed to offer key
-   management not to directly provide client authentication but instead
-   to allow one or more other mechanisms to handle this need.  Secondly,
-   thinking about the abstract services that a mechanism provides yields
-   a minimum set of security requirements that all mechanisms providing
-   that facility must meet.  These security requirements are not
-   complete; mechanisms will have additional security requirements based
-   on the specific protocol they employ.
-
-   A mechanism is not constrained to only offering one of these
-   facilities.  While such mechanisms can be designed and are sometimes
-   useful, many pre-authentication mechanisms implement several
-   facilities.  By combining multiple facilities in a single mechanism,
-   it is often easier to construct a secure, simple solution than by
-   solving the problem in full generality.  Even when mechanisms provide
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 12]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   multiple facilities, they need to meet the security requirements for
-   all the facilities they provide.  If the FAST factor approach is
-   used, it is likely that one or a small number of facilities can be
-   provided by a single mechanism without complicating the security
-   analysis.
-
-   According to Kerberos extensibility rules (Section 1.5 of the
-   Kerberos specification [RFC4120]), an extension MUST NOT change the
-   semantics of a message unless a recipient is known to understand that
-   extension.  Because a client does not know that the KDC supports a
-   particular pre-authentication mechanism when it sends an initial
-   request, a pre-authentication mechanism MUST NOT change the semantics
-   of the request in a way that will break a KDC that does not
-   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
-   clients that affect the core semantics unless the client has
-   indicated support for the message.
-
-   The only state in this model that would break the interpretation of a
-   message is changing the expected reply key.  If one mechanism changed
-   the reply key and a later mechanism used that reply key, then a KDC
-   that interpreted the second mechanism but not the first would fail to
-   interpret the request correctly.  In order to avoid this problem,
-   extensions that change core semantics are typically divided into two
-   parts.  The first part proposes a change to the core semantic--for
-   example proposes a new reply key.  The second part acknowledges that
-   the extension is understood and that the change takes effect.
-   Section 4.2 discusses how to design mechanisms that modify the reply
-   key to be split into a proposal and acceptance without requiring
-   additional round trips to use the new reply key in subsequent pre-
-   authentication.  Other changes in the state described in Section 3.1
-   can safely be ignored by a KDC that does not understand a mechanism.
-   Mechanisms that modify the behavior of the request outside the scope
-   of this framework need to carefully consider the Kerberos
-   extensibility rules to avoid similar problems.
-
-4.1.  Client-authentication Facility
-
-   The client authentication facility proves the identity of a user to
-   the KDC before a ticket is issued.  Examples of mechanisms
-   implementing this facility include the encrypted timestamp facility
-   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
-   Mechanisms that provide this facility are expected to mark the client
-   as authenticated.
-
-   Mechanisms implementing this facility SHOULD require the client to
-   prove knowledge of the reply key before transmitting a successful KDC
-   reply.  Otherwise, an attacker can intercept the pre-authentication
-   exchange and get a reply to attack.  One way of proving the client
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 13]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   knows the reply key is to implement the Replace Reply Key facility
-   along with this facility.  The PKINIT mechanism [RFC4556] implements
-   Client Authentication alongside Replace Reply Key.
-
-   If the reply key has been replaced, then mechanisms such as
-   encrypted-timestamp that rely on knowledge of the reply key to
-   authenticate the client MUST NOT be used.
-
-4.2.  Strengthening-reply-key Facility
-
-   Particularly when dealing with keys based on passwords, it is
-   desirable to increase the strength of the key by adding additional
-   secrets to it.  Examples of sources of additional secrets include the
-   results of a Diffie-Hellman key exchange or key bits from the output
-   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
-   be first combined with the existing reply key and then converted to a
-   protocol key using tools defined in Section 6.1.
-
-   Typically a mechanism implementing this facility will know that the
-   other side of the exchange supports the facility before the reply key
-   is changed.  For example, a mechanism might need to learn the
-   certificate for a KDC before encrypting a new key in the public key
-   belonging to that certificate.  However, if a mechanism implementing
-   this facility wishes to modify the reply key before knowing that the
-   other party in the exchange supports the mechanism, it proposes
-   modifying the reply key.  The other party then includes a message
-   indicating that the proposal is accepted if it is understood and
-   meets policy.  In many cases it is desirable to use the new reply key
-   for client authentication and for other facilities.  Waiting for the
-   other party to accept the proposal and actually modify the reply key
-   state would add an additional round trip to the exchange.  Instead,
-   mechanism designers are encouraged to include a typed hole for
-   additional padata in the message that proposes the reply key change.
-   The padata included in the typed hole are generated assuming the new
-   reply key.  If the other party accepts the proposal, then these
-   padata are considered as an inner level.  As with the outer level,
-   one authentication set or mechanism is typically chosen for client
-   authentication, along with auxiliary mechanisms such as KDC cookies,
-   and other mechanisms are ignored.  When mechanisms include such a
-   container, the hint provided for use in authentication sets (as
-   defined in Section 6.4) MUST contain a sequence of inner mechanisms
-   along with hints for those mechanisms.  The party generating the
-   proposal can determine whether the padata were processed based on
-   whether the proposal for the reply key is accepted.
-
-   The specific formats of the proposal message, including where padata
-   are included is a matter for the mechanism specification.  Similarly,
-   the format of the message accepting the proposal is mechanism-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 14]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   specific.
-
-   Mechanisms implementing this facility and including a typed hole for
-   additional padata MUST checksum that padata using a keyed checksum or
-   encrypt the padata.  This requirement protects against modification
-   of the contents of the typed hole.  By modifying these contents an
-   attacker might be able to choose which mechanism is used to
-   authenticate the client, or to convince a party to provide text
-   encrypted in a key that the attacker had manipulated.  It is
-   important that mechanisms strengthen the reply key enough that using
-   it to checksum padata is appropriate.
-
-4.3.  Replacing-reply-key Facility
-
-   The Replace Reply Key facility replaces the key in which a successful
-   AS reply will be encrypted.  This facility can only be used in cases
-   where knowledge of the reply key is not used to authenticate the
-   client.  The new reply key MUST be communicated to the client and the
-   KDC in a secure manner.  This facility MUST NOT be used if there can
-   be a man-in-the-middle between the client and the KDC.  Mechanisms
-   implementing this facility MUST mark the reply key as replaced in the
-   pre-authentication state.  Mechanisms implementing this facility MUST
-   either provide a mechanism to verify the KDC reply to the client or
-   mark the reply as unverified in the pre-authentication state.
-   Mechanisms implementing this facility SHOULD NOT be used if a
-   previous mechanism has used the reply key.
-
-   As with the strengthening-reply-key facility, Kerberos extensibility
-   rules require that the reply key not be changed unless both sides of
-   the exchange understand the extension.  In the case of this facility
-   it will likely be the case for both sides to know that the facility
-   is available by the time that the new key is available to be used.
-   However, mechanism designers can use a container for padata in a
-   proposal message as discussed in Section 4.2 if appropriate.
-
-4.4.  KDC-authentication Facility
-
-   This facility verifies that the reply comes from the expected KDC.
-   In traditional Kerberos, the KDC and the client share a key, so if
-   the KDC reply can be decrypted then the client knows that a trusted
-   KDC responded.  Note that the client machine cannot trust the client
-   unless the machine is presented with a service ticket for it
-   (typically the machine can retrieve this ticket by itself).  However,
-   if the reply key is replaced, some mechanism is required to verify
-   the KDC.  Pre-authentication mechanisms providing this facility allow
-   a client to determine that the expected KDC has responded even after
-   the reply key is replaced.  They mark the pre-authentication state as
-   having been verified.
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 15]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-5.  Requirements for Pre-Authentication Mechanisms
-
-   This section lists requirements for specifications of pre-
-   authentication mechanisms.
-
-   For each message in the pre-authentication mechanism, the
-   specification describes the pa-type value to be used and the contents
-   of the message.  The processing of the message by the sender and
-   recipient is also specified.  This specification needs to include all
-   modifications to the pre-authentication state.
-
-   Generally mechanisms have a message that can be sent in the error
-   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
-   authentication set.  If the client needs information such as trusted
-   certificate authorities in order to determine if it can use the
-   mechanism, then this information should be in that message.  In
-   addition, such mechanisms should also define a pa-hint to be included
-   in authentication sets.  Often, the same information included in the
-   padata-value is appropriate to include in the pa-hint (as defined in
-   Section 6.4).
-
-   In order to ease security analysis the mechanism specification should
-   describe what facilities from this document are offered by the
-   mechanism.  For each facility, the security consideration section of
-   the mechanism specification should show that the security
-   requirements of that facility are met.  This requirement is
-   applicable to any FAST factor that provides authentication
-   information.
-
-   Significant problems have resulted in the specification of Kerberos
-   protocols because much of the KDC exchange is not protected against
-   alteration.  The security considerations section should discuss
-   unauthenticated plaintext attacks.  It should either show that
-   plaintext is protected or discuss what harm an attacker could do by
-   modifying the plaintext.  It is generally acceptable for an attacker
-   to be able to cause the protocol negotiation to fail by modifying
-   plaintext.  More significant attacks should be evaluated carefully.
-
-   As discussed in Section 6.3, there is no guarantee that a client will
-   use the same KDCs for all messages in a conversation.  The mechanism
-   specification needs to show why the mechanism is secure in this
-   situation.  The hardest problem to deal with, especially for
-   challenge/response mechanisms is to make sure that the same response
-   cannot be replayed against two KDCs while allowing the client to talk
-   to any KDC.
-
-
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 16]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-6.  Tools for Use in Pre-Authentication Mechanisms
-
-   This section describes common tools needed by multiple pre-
-   authentication mechanisms.  By using these tools mechanism designers
-   can use a modular approach to specify mechanism details and ease
-   security analysis.
-
-6.1.  Combining Keys
-
-   Frequently a weak key needs to be combined with a stronger key before
-   use.  For example, passwords are typically limited in size and
-   insufficiently random, therefore it is desirable to increase the
-   strength of the keys based on passwords by adding additional secrets.
-   Additional source of secrecy may come from hardware tokens.
-
-   This section provides standard ways to combine two keys into one.
-
-   KRB-FX-CF1() is defined to combine two pass-phrases.
-
-       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
-       KRB-FX-CF1(x, y) := x || y
-
-   Where || denotes concatenation.  The strength of the final key is
-   roughly the total strength of the individual keys being combined
-   assuming that the string_to_key() function [RFC3961] uses all its
-   input evenly.
-
-   An example usage of KRB-FX-CF1() is when a device provides random but
-   short passwords, the password is often combined with a personal
-   identification number (PIN).  The password and the PIN can be
-   combined using KRB-FX-CF1().
-
-   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
-   function defined in [RFC3961].
-
-   Given two input keys, K1 and K2, where K1 and K2 can be of two
-   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
-   follows:
-
-       KRB-FX-CF2(protocol key, protocol key, octet string,
-                 octet string)  ->  (protocol key)
-
-       PRF+(K1, pepper1) -> octet-string-1
-       PRF+(K2, pepper2) -> octet-string-2
-       KRB-FX-CF2(K1, K2, pepper1, pepper2) :=
-              random-to-key(octet-string-1 ^ octet-string-2)
-
-   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 17]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   follows:
-
-    PRF+(protocol key, octet string) -> (octet string)
-
-    PRF+(key, shared-info) := pseudo-random( key,  1 || shared-info ) ||
-                  pseudo-random( key, 2 || shared-info ) ||
-                  pseudo-random( key, 3 || shared-info ) || ...
-
-   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
-   integer.  The pseudo-random() operation is specified by the enctype
-   of the protocol key.  PRF+() uses the counter to generate enough bits
-   as needed by the random-to-key() [RFC3961] function for the
-   encryption type specified for the resulting key; unneeded bits are
-   removed from the tail.  Unless otherwise specified, the resulting
-   enctype of KRB-FX-CF2 is the enctype of k1.
-
-   Mechanism designers MUST specify the values for the input parameter
-   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
-   pepper1 and pepper2 MUST be distinct so that if the two keys being
-   combined are the same, the resulting key is not a trivial key.
-
-6.2.  Protecting Requests/Responses
-
-   Mechanism designers SHOULD protect clear text portions of pre-
-   authentication data.  Various denial of service attacks and downgrade
-   attacks against Kerberos are possible unless plaintexts are somehow
-   protected against modification.  An early design goal of Kerberos
-   Version 5 [RFC4120] was to avoid encrypting more of the
-   authentication exchange that was required.  (Version 4 doubly-
-   encrypted the encrypted part of a ticket in a KDC reply, for
-   example.)  This minimization of encryption reduces the load on the
-   KDC and busy servers.  Also, during the initial design of Version 5,
-   the existence of legal restrictions on the export of cryptography
-   made it desirable to minimize of the number of uses of encryption in
-   the protocol.  Unfortunately, performing this minimization created
-   numerous instances of unauthenticated security-relevant plaintext
-   fields.
-
-   If there is more than one round trip for an authentication exchange,
-   mechanism designers need to allow either the client or the KDC to
-   provide a checksum of all the messages exchanged on the wire in the
-   conversation, and the checksum is then verified by the receiver.
-
-   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
-
-   Primitives defined in [RFC3961] are RECOMMENDED for integrity
-   protection and confidentiality.  Mechanisms based on these primitives
-   are crypto-agile as the result of using [RFC3961] along with
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 18]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   [RFC4120].  The advantage afforded by crypto-agility is the ability
-   to incrementally deploy a fix specific to a particular algorithm thus
-   avoid a multi-year standardization and deployment cycle, when real
-   attacks do arise against that algorithm.
-
-   Note that data used by FAST factors (defined in Section 6.5) is
-   encrypted in a protected channel, thus they do not share the un-
-   authenticated-text issues with mechanisms designed as full-blown pre-
-   authentication mechanisms.
-
-6.3.  Managing States for the KDC
-
-   Kerberos KDCs are stateless in that there is no requirement that
-   clients will choose the same KDC for the second request in a
-   conversation.  Proxies or other intermediate nodes may also influence
-   KDC selection.  So, each request from a client to a KDC must include
-   sufficient information that the KDC can regenerate any needed state.
-   This is accomplished by giving the client a potentially long opaque
-   cookie in responses to include in future requests in the same
-   conversation.  The KDC MAY respond that a conversation is too old and
-   needs to restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
-
-       KDC_ERR_PREAUTH_EXPIRED            90
-
-   When a client receives this error, the client SHOULD abort the
-   existing conversation, and restart a new one.
-
-   An example, where more than one message from the client is needed, is
-   when the client is authenticated based on a challenge-response
-   scheme.  In that case, the KDC needs to keep track of the challenge
-   issued for a client authentication request.
-
-   The PA-FX-COOKIE padata type is defined in this section to facilitate
-   state management in the AS exchange.  This padata is sent by the KDC
-   when the KDC requires state for a future transaction.  The client
-   includes this opaque token in the next message in the conversation.
-   The token may be relatively large; clients MUST be prepared for
-   tokens somewhat larger than the size of all messages in a
-   conversation.
-
-       PA-FX-COOKIE                       133
-           -- Stateless cookie that is not tied to a specific KDC.
-
-   The corresponding padata-value field [RFC4120] contains an opaque
-   token that will be echoed by the client in its response to an error
-   from the KDC.
-
-   The cookie token is generated by the KDC and transmitted in a PA-FX-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 19]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   COOKIE pre-authentication data item of a KRB-ERROR message.  The
-   client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data
-   element into the next message of the same conversation.  The content
-   of the cookie field is a local matter of the KDC.  As a result, it is
-   not generally possible to mix KDC implementations from different
-   vendors in the same realm.  However the KDC MUST construct the cookie
-   token in such a manner that a malicious client cannot subvert the
-   authentication process by manipulating the token.  The KDC
-   implementation needs to consider expiration of tokens, key rollover
-   and other security issues in token design.  The content of the cookie
-   field is likely specific to the pre-authentication mechanisms used to
-   authenticate the client.  If a client authentication response can be
-   replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an
-   expiration in the cookie is RECOMMENDED to prevent the response being
-   presented indefinitely.
-
-   If at least one more message for a mechanism or a mechanism set is
-   expected by the KDC, the KDC returns a
-   KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error with a PA-FX-COOKIE to
-   identify the conversation with the client according to Section 3.2.
-   The cookie is not expected to stay constant for a conversation: the
-   KDC is expected to generate a new cookie for each message.
-
-        KDC_ERR_MORE_PREAUTH_DATA_REQUIRED   91
-
-   A client MAY throw away the state associated with a conversation and
-   begin a new conversation by discarding its state and not including a
-   cookie in the first message of a conversation.  KDCs that comply with
-   this specification MUST include a cookie in a response when the
-   client can continue the conversation.  In particular, a KDC MUST
-   include a cookie in a KDC_ERR_PREAUTH_REQUIRED or
-   KDC_ERR_MORE_PREAUTH_DATA_REQUIRED.  KDCs SHOULD include a cookie in
-   errors containing additional information allowing a client to retry.
-   One reasonable strategy for meeting these requirements is to always
-   include a cookie in KDC errors.
-
-   A KDC MAY indicate that it is terminating a conversation by not
-   including a cookie in a response.  When FAST is used, clients can
-   assume that the absence of a cookie means that the KDC is ending the
-   conversation.  Clients also need to deal with KDCs prior to this
-   specification that do not include cookies; if cookies nor FAST are
-   used in a conversation, the absence of a cookie is not a strong
-   indication that the KDC is terminating the conversation.
-
-6.4.  Pre-authentication Set
-
-   If all mechanisms in a group need to successfully complete in order
-   to authenticate a client, the client and the KDC SHOULD use the PA-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 20]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   AUTHENTICATION-SET padata element.
-
-        PA-AUTHENTICATION-SET              134
-
-   A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
-   encoding of the PA-AUTHENTICATION-SET structure:
-
-        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-            pa-type      [0] Int32,
-                -- same as padata-type.
-            pa-hint      [1] OCTET STRING OPTIONAL,
-            pa-value     [2] OCTET STRING OPTIONAL,
-            ...
-        }
-
-   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
-   contains the corresponding value of padata-type in PA-DATA [RFC4120].
-   Associated with the pa-type is a pa-hint, which is an octet-string
-   specified by the pre-authentication mechanism.  This hint may provide
-   information for the client which helps it determine whether the
-   mechanism can be used.  For example a public-key mechanism might
-   include the certificate authorities it trusts in the hint info.  Most
-   mechanisms today do not specify hint info; if a mechanism does not
-   specify hint info the KDC MUST NOT send a hint for that mechanism.
-   To allow future revisions of mechanism specifications to add hint
-   info, clients MUST ignore hint info received for mechanisms that the
-   client believes do not support hint info.  The pa-value element of
-   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
-   first padata-value from the KDC to the client.  If the client chooses
-   this authentication set then the client MUST process this pa-value.
-   The pa-value element MUST be absent for all but the first entry in
-   the authentication set.  Clients MUST ignore pa-value for the second
-   and following entries in the authentication set.
-
-   If the client chooses an authentication set, then its first AS-REQ
-   message MUST contain a PA-AUTH-SET-SELECTED padata element.  This
-   element contains the encoding of the PA-AUTHENTICATION-SET sequence
-   received from the KDC corresponding to the authentication set that is
-   chosen.  The client MUST use the same octet values received from the
-   KDC; it cannot re-encode the sequence.  This allows KDCs to use bit-
-   wise comparison to identify the selected authentication set.  The PA-
-   AUTH-SET-SELECTED padata element MUST come before any padata elements
-   from the authentication set in the padata sequence in the AS-REQ
-   message.  The client MAY cache authentication sets from prior
-   messages and use them to construct an optimistic initial AS-REQ.  If
-   the KDC receives a PA-AUTH-SET-SELECTED padata element that does not
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 21]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   correspond to an authentication set that it would offer, then the KDC
-   returns the KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The e-data
-   in this error contains a sequence of padata just as for the
-   KDC_ERR_PREAUTH_REQUIRED error.
-
-
-         PA-AUTH-SET-SELECTED                   135
-         KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
-
-   The PA-AUTHENTICATION-SET appears only in the first message from the
-   KDC to the client.  In particular, the client MAY fail if the
-   authentication mechanism sets change as the conversation progresses.
-   Clients MAY assume that the hints provided in the authentication set
-   contain enough information that the client knows what user interface
-   elements need to be displayed during the entire authentication
-   conversation.  Exceptional circumstances such as expired passwords or
-   expired accounts may require that additional user interface be
-   displayed.  Mechanism designers needs to carefully consider the
-   design of their hints so that the client has this information.  This
-   way, clients can construct necessary dialogue boxes or wizards based
-   on the authentication set and can present a coherent user interface.
-   Current standards for user interface do not provide an acceptable
-   experience when the client has to ask additional questions later in
-   the conversation.
-
-   When indicating which sets of pre-authentication mechanisms are
-   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
-   for each pre-authentication mechanism set.
-
-   The client sends the padata-value for the first mechanism it picks in
-   the pre-authentication set, when the first mechanism completes, the
-   client and the KDC will proceed with the second mechanism, and so on
-   until all mechanisms complete successfully.  The PA-FX-COOKIE as
-   defined in Section 6.3 MUST be sent by the KDC.  One reason for this
-   requirement is so that the conversation can continue if the
-   conversation involves multiple KDCs.  KDCs MUST support clients that
-   do not include a cookie because they optimistically choose an
-   authentication set, although they MAY always return
-   KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in that
-   message.  Clients that support PA-AUTHENTICATION-SET MUST support PA-
-   FX-COOKIE.
-
-   Before the authentication succeeds and a ticket is returned, the
-   message that the client sends is an AS_REQ and the message that the
-   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
-   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_REQUIRED as defined
-   in Section 6.3 and the accompanying e-data contains the DER encoding
-   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 22]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   the METHOD-DATA.  If there is no padata, the e-data field is absent
-   in the KRB-ERROR message.
-
-   If the client sends the last message for a given mechanism, then the
-   KDC sends the first message for the next mechanism.  If the next
-   mechanism does not start with a KDC-side challenge, then the KDC
-   includes a padata item with the appropriate pa-type and an empty pa-
-   data.
-
-   If the KDC sends the last message for a particular mechanism, the KDC
-   also includes the first padata for the next mechanism.
-
-6.5.  Definition of Kerberos FAST Padata
-
-   As described in [RFC4120], Kerberos is vulnerable to offline
-   dictionary attacks.  An attacker can request an AS-REP and try
-   various passwords to see if they can decrypt the resulting ticket.
-   RFC 4120 provides the encrypted timestamp pre-authentication method
-   that ameliorates the situation somewhat by requiring that an attacker
-   observe a successful authentication.  However stronger security is
-   desired in many environments.  The Kerberos FAST pre-authentication
-   padata defined in this section provides a tool to significantly
-   reduce vulnerability to offline dictionary attack.  When combined
-   with encrypted challenge, FAST requires an attacker to mount a
-   successful man-in-the-middle attack to observe ciphertext.  When
-   combined with host keys, FAST can even protect against active
-   attacks.  FAST also provides solutions to common problems for pre-
-   authentication mechanisms such as binding of the request and the
-   reply, freshness guarantee of the authentication.  FAST itself,
-   however, does not authenticate the client or the KDC, instead, it
-   provides a typed hole to allow pre-authentication data be tunneled.
-   A pre-authentication data element used within FAST is called a FAST
-   factor.  A FAST factor captures the minimal work required for
-   extending Kerberos to support a new pre-authentication scheme.
-
-   A FAST factor MUST NOT be used outside of FAST unless its
-   specification explicitly allows so.  The typed holes in FAST messages
-   can also be used as generic holes for other padata that are not
-   intended to prove the client's identity, or establish the reply key.
-
-   New pre-authentication mechanisms SHOULD be designed as FAST factors,
-   instead of full-blown pre-authentication mechanisms.
-
-   FAST factors that are pre-authentication mechanisms MUST meet the
-   requirements in Section 5.
-
-   FAST employs an armoring scheme.  The armor can be a Ticket Granting
-   Ticket (TGT) obtained by the client's machine using the host keys to
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 23]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   pre-authenticate with the KDC, or an anonymous TGT obtained based on
-   anonymous PKINIT [KRB-ANON] [RFC4556].
-
-   The rest of this section describes the types of armors and the syntax
-   of the messages used by FAST.  Conforming implementations MUST
-   support Kerberos FAST padata.
-
-   Any FAST armor scheme MUST provide a fresh armor key for each
-   conversation.  Clients and KDCs can assume that if a message is
-   encrypted and integrity protected with a given armor key then it is
-   part of the conversation using that armor key.
-
-   All KDCs in a realm MUST support FAST if FAST is offered by any KDC
-   as a pre-authentication mechanism.
-
-6.5.1.  FAST Armors
-
-   An armor key is used to encrypt pre-authentication data in the FAST
-   request and the response.  The KrbFastArmor structure is defined to
-   identify the armor key.  This structure contains the following two
-   fields: the armor-type identifies the type of armors, and the armor-
-   value is an OCTET STRING that contains the description of the armor
-   scheme and the armor key.
-
-        KrbFastArmor ::= SEQUENCE {
-            armor-type   [0] Int32,
-                -- Type of the armor.
-            armor-value  [1] OCTET STRING,
-                -- Value of the armor.
-            ...
-        }
-
-   The value of the armor key is a matter of the armor type
-   specification.  Only one armor type is defined in this document.
-
-        FX_FAST_ARMOR_AP_REQUEST           1
-
-   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
-
-   Conforming implementations MUST implement the
-   FX_FAST_ARMOR_AP_REQUEST armor type.  If a FAST KDC receives an
-   unknown armor type it MUST respond with KDC_ERR_PREAUTH_FAILED.
-
-   An armor type may be appropriate for use in armoring AS requests,
-   armoring TGS requests or both.  TGS armor types MUST authenticate the
-   client to to the KDC, typically by binding the TGT subsession key to
-   the armor key.  As discussed below, it is desirable for AS armor
-   types to authenticate the KDC to the client, but this is not
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 24]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   required.
-
-   FAST implementations MUST maintain state about whether the armor
-   mechanism authenticates the KDC.  If it does not, then a fast factor
-   that authenticates the KDC MUST be used if the reply key is replaced.
-
-6.5.1.1.  Ticket-based Armors
-
-   This is a ticket-based armoring scheme.  The armor-type is
-   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
-   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
-   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
-   The armor key is defined by the following function:
-
-       armor_key = KRB-FX-CF2( subkey, ticket_session_key,
-                   "subkeyarmor", "ticketarmor" )
-
-   The `ticket_session_key' is the session key from the ticket in the
-   ap-req.  The `subkey' is the ap-req subkey.  This construction
-   guarantees that both the KDC (through the session key) and the client
-   (through the subkey) contribute to the armor key.
-
-   The server name field of the armor ticket MUST identify the TGS of
-   the target realm.  Here are three common ways in the decreasing
-   preference order how an armor TGT SHOULD be obtained:
-
-   1.  If the client is authenticating from a host machine whose
-       Kerberos realm has an authentication path to the client's realm,
-       the host machine obtains a TGT by using the host keys.  If the
-       client's realm is different than the realm of the local host, the
-       machine then obtains a cross-realm TGT to the client's realm as
-       the armor ticket.  Otherwise, the host's primary TGT is the armor
-       ticket.
-
-   2.  If the client's host machine cannot obtain a host ticket strictly
-       based on RFC4120, but the KDC has an asymmetric signing key whose
-       binding with the expected KDC can be verified by the client, the
-       client can use anonymous PKINIT [KRB-ANON] [RFC4556] to
-       authenticate the KDC and obtain an anonymous TGT as the armor
-       ticket.  The armor ticket can also be a cross-realm TGT obtained
-       based on the initial primary TGT obtained using anonymous PKINIT
-       with KDC authentication.
-
-   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
-       TGT without KDC authentication and that TGT is the armor ticket.
-       Note that this mode of operation is vulnerable to man-in-the-
-       middle attacks at the time of obtaining the initial anonymous
-       armor TGT.
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 25]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   If anonymous PKINIT is used to obtain the armor ticket, the KDC
-   cannot know whether its signing key can be verified by the client,
-   hence the KDC MUST be marked as unverified from the KDC's point of
-   view while the client could be able to authenticate the KDC by
-   verifying the KDC's signing key is bound with the expected KDC.  The
-   client needs to carefully consider the risk and benefit tradeoffs
-   associated with active attacks before exposing cipher text encrypted
-   using the user's long-term secrets when the armor does not
-   authenticate the KDC.
-
-   The TGS MUST reject a request if there is an AD-fx-fast-armor (TBD)
-   element in the authenticator of the pa-tgs-req padata or if the
-   ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-
-   armor authorization data element.  These tickets and authenticators
-   MAY be used as FAST armor tickets but not to obtain a ticket via the
-   TGS.  This authorization data is used in a system where the
-   encryption of the user's pre-authentication data is performed in an
-   unprivileged user process.  A privileged process can provide to the
-   user process a host ticket, an authenticator for use with that
-   ticket, and the sub session key contained in the authenticator.  In
-   order for the host process to ensure that the host ticket is not
-   accidentally or intentionally misused, (i.e. the user process might
-   use the host ticket to authenticate as the host), it MUST include a
-   critical authorization data element of the type AD-fx-fast-armor when
-   providing the authenticator or in the enc-authorization-data field of
-   the TGS request used to obtain the TGT.  The corresponding ad-data
-   field of the AD-fx-fast-armor element is empty.
-
-   Only implicit armors are allowed in the TGS.
-
-6.5.2.  FAST Request
-
-   A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
-   authentication padata.  The corresponding padata-value field
-   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
-   REQUEST.  As with all pre-authentication types, the KDC SHOULD
-   advertise PA-FX-FAST in a PREAUTH_REQUIRED error.  KDCs MUST send the
-   advertisement of pa-fx-fast with an empty pa-value.  Clients MUST
-   ignore the pa-value of PA-FX-FAST in an initial PREAUTH_REQUIRED
-   error.  FAST is not expected to be used in an authentication set:
-   clients will typically use FAST padata if available and this decision
-   should not depend on what other pre-authentication methods are
-   available.  As such, no pa-hint is defined for FAST at this time.
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 26]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-       PA-FX-FAST                         136
-           -- Padata type for Kerberos FAST
-
-       PA-FX-FAST-REQUEST ::= CHOICE {
-           armored-data [0] KrbFastArmoredReq,
-           ...
-       }
-
-       KrbFastArmoredReq ::= SEQUENCE {
-           armor        [0] KrbFastArmor OPTIONAL,
-               -- Contains the armor that identifies the armor key.
-               -- MUST be present in AS-REQ.
-           req-checksum [1] Checksum,
-               -- For AS, contains the checksum performed over the type
-               -- KDC-REQ-BODY for the req-body field of the KDC-REQ
-               -- structure;
-               -- For TGS, contains the checksum performed over the type
-               -- AP-REQ in the PA-TGS-REQ padata.
-               -- The checksum key is the armor key, the checksum
-               -- type is the required checksum type for the enctype of
-               -- the armor key, and the key usage number is
-               -- KEY_USAGE_FAST_REQ_CHKSUM.
-           enc-fast-req [2] EncryptedData, -- KrbFastReq --
-               -- The encryption key is the armor key, and the key usage
-               -- number is KEY_USAGE_FAST_ENC.
-           ...
-       }
-
-       KEY_USAGE_FAST_REQ_CHKSUM          50
-       KEY_USAGE_FAST_ENC                 51
-
-   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
-   The KrbFastArmoredReq encapsulates the encrypted padata.
-
-   The enc-fast-req field contains an encrypted KrbFastReq structure.
-   The armor key is used to encrypt the KrbFastReq structure, and the
-   key usage number for that encryption is KEY_USAGE_FAST_ENC.
-
-   The armor key is selected as follows:
-
-   o  In an AS request, the armor field in the KrbFastArmoredReq
-      structure MUST be present and the armor key is identified
-      according to the specification of the armor type.
-
-   o  There are two possibilities for armor for a TGS request.  If the
-      ticket presented in the PA-TGS-REQ authenticator is a TGT, then
-      the client SHOULD NOT include the armor field in the Krbfastreq
-      and a subkey MUST be included in the PA-TGS-REQ authenticator.  In
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 27]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-      this case, the armor key is the same armor key that would be
-      computed if the TGS-REQ authenticator was used in a
-      FX_FAST_ARMOR_AP_REQUEST armor.  Clients MAY present a non-TGT in
-      the PA-TGS-REQ authenticator and omit the armor field, in which
-      case the armor key is the same that would be computed if the
-      authenticator were used in a FX_FAST_ARMOR_AP_REQUEST armor.  This
-      is the only case where a ticket other than a TGT can be used to
-      establish an armor key; even though the armor key is computed the
-      same as a FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used as an
-      armor ticket in FX_FAST_ARMOR_AP_REQUEST.  Alternatively, a client
-      MAY use an armor type defined in the future for use with the TGS
-      request.
-
-   The req-checksum field contains a checksum computed differently for
-   AS and TGS.  For an AS-REQ, it is performed over the type KDC-REQ-
-   BODY for the req-body field of the KDC-REQ structure of the
-   containing message; for an TGS-REQ, it is performed over the type AP-
-   REQ in the PA-TGS-REQ padata of the TGS request.  The checksum key is
-   the armor key, and the checksum type is the required checksum type
-   for the enctype of the armor key per [RFC3961].  This checksum MUST
-   be a keyed checksume and it is included in order to bind the FAST
-   padata to the outer request.  A KDC that implements FAST will ignore
-   the outer request, but including a checksum is relatively cheap and
-   may prevent confusing behavior.
-
-   The KrbFastReq structure contains the following information:
-
-        KrbFastReq ::= SEQUENCE {
-            fast-options [0] FastOptions,
-                -- Additional options.
-            padata       [1] SEQUENCE OF PA-DATA,
-                -- padata typed holes.
-            req-body     [2] KDC-REQ-BODY,
-                -- Contains the KDC request body as defined in Section
-                -- 5.4.1 of [RFC4120].
-                -- This req-body field is preferred over the outer field
-                -- in the KDC request.
-             ...
-        }
-
-   The fast-options field indicates various options that are to modify
-   the behavior of the KDC.  The following options are defined:
-
-        FastOptions ::= KerberosFlags
-            -- reserved(0),
-            -- hide-client-names(1),
-            -- kdc-follow-referrals(16)
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 28]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-     Bits    Name                    Description
-    -----------------------------------------------------------------
-     0     RESERVED              Reserved for future expansion of this
-                                 field.
-     1     hide-client-names     Requesting the KDC to hide client
-                                 names in the KDC response, as
-                                 described next in this section.
-     16    kdc-follow-referrals  Requesting the KDC to follow referrals.
-
-   Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are
-   critical options.  If the KDC does not support a critical option, it
-   MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and
-   there is no accompanying e-data defined in this document for this
-   error code.  Bit 16 and onward (with bit 16 included) are non-
-   critical options.  KDCs conforming to this specification ignore
-   unknown non-critical options.
-
-        KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
-
-   The hide-client-names Option
-
-      The Kerberos response defined in [RFC4120] contains the client
-      identity in clear text, This makes traffic analysis
-      straightforward.  The hide-client-names option is designed to
-      complicate traffic analysis.  If the hide-client-names option is
-      set, the KDC implementing PA-FX-FAST MUST identify the client as
-      the anonymous principal [KRB-ANON] in the KDC reply and the error
-      response.  Hence this option is set by the client if it wishes to
-      conceal the client identity in the KDC response.  A conforming KDC
-      ignores the client principal name in the outer KDC-REQ-BODY field,
-      and identifies the client using the cname and crealm fields in the
-      req-body field of the KrbFastReq structure.
-
-   The kdc-follow-referrals Option
-
-      The Kerberos client described in [RFC4120] has to request referral
-      TGTs along the authentication path in order to get a service
-      ticket for the target service.  The Kerberos client described in
-      the [REFERRALS] needs to contact the AS specified in the error
-      response in order to complete client referrals.  The kdc-follow-
-      referrals option is designed to minimize the number of messages
-      that need to be processed by the client.  This option is useful
-      when, for example, the client may contact the KDC via a satellite
-      link that has high network latency, or the client has limited
-      computational capabilities.  If the kdc-follow-referrals option is
-      set, the KDC MAY act as the client to follow TGS referrals
-      [REFERRALS], and return the service ticket to the named server
-      principal in the client request using the reply key expected by
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 29]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-      the client.  That is, rather than returning a referral, the KDC
-      follows that referral by contacting a remote KDC and processing
-      the referral.  The kdc-referrals option can be implemented when
-      the KDC knows the reply key.  The KDC can ignore kdc-referrals
-      option when it does not understand it or it does not allow this
-      option based on local policy.  The client SHOULD be capable of
-      processing the KDC responses when this option is not honored by
-      the KDC.  Clients SHOULD use TCP to contact a KDC if this option
-      is going to be used to avoid problems when the client's UDP
-      retransmit algorithm has timeouts insufficient to allow the KDC to
-      interact with remote KDCs.
-
-   The padata field contains a list of PA-DATA structures as described
-   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
-   FAST factors.  They can also be used as generic typed-holes to
-   contain data not intended for proving the client's identity or
-   establishing a reply key, but for protocol extensibility.  If the KDC
-   supports the PA-FX-FAST-REQUEST padata, unless otherwise specified,
-   the client MUST place any padata that is otherwise in the outer KDC
-   request body into this field.  In a TGS request, PA-TGS-REQ padata is
-   not included in this field and it is present in the outer KDC request
-   body.
-
-   The KDC-REQ-BODY in the FAST structure is used in preference to the
-   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-
-   REQ-BODY structure SHOULD be filled in for backwards compatibility
-   with KDCs that do not support FAST.  A conforming KDC ignores the
-   outer KDC-REQ-BODY field in the KDC request.  Pre-authentication data
-   methods such as [RFC4556] that include a checksum of the KDC-REQ-BODY
-   should checksum the KDC-REQ-BODY in the FAST structure.
-
-   In a TGS request, a client MAY include the AD-fx-fast-used authdata
-   either in the pa-tgs-req authenticator or in the authorization data
-   in the pa-tgs-req ticket.  If the KDC receives this authorization
-   data but does not find a FAST padata then it MUST return
-   KRB_APP_ERR_MODIFIED.
-
-6.5.3.  FAST Response
-
-   The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST
-   padata element in the KDC reply.  In the case of an error, the PA-FX-
-   FAST padata is included in the KDC responses according to
-   Section 6.5.4.
-
-   The corresponding padata-value field [RFC4120] for the PA-FX-FAST in
-   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
-   FAST-REPLY.
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 30]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-      PA-FX-FAST-REPLY ::= CHOICE {
-          armored-data [0] KrbFastArmoredRep,
-          ...
-      }
-
-      KrbFastArmoredRep ::= SEQUENCE {
-          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
-              -- The encryption key is the armor key in the request, and
-              -- the key usage number is KEY_USAGE_FAST_REP.
-          ...
-      }
-      KEY_USAGE_FAST_REP                 52
-
-   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
-   structure.  The KrbFastArmoredRep structure encapsulates the padata
-   in the KDC reply in the encrypted form.  The KrbFastResponse is
-   encrypted with the armor key used in the corresponding request, and
-   the key usage number is KEY_USAGE_FAST_REP.
-
-   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
-   KDC response MUST support a local policy that rejects the response.
-   Clients MAY also support policies that fall back to other mechanisms
-   or that do not use pre-authentication when FAST is unavailable.  It
-   is important to consider the potential downgrade attacks when
-   deploying such a policy.
-
-   The KrbFastResponse structure contains the following information:
-
-       KrbFastResponse ::= SEQUENCE {
-           padata         [0] SEQUENCE OF PA-DATA,
-               -- padata typed holes.
-           strengthen-key [1] EncryptionKey OPTIONAL,
-               -- This, if present, strengthens the reply key for AS and
-               -- TGS. MUST be present for TGS.
-               -- MUST be absent in KRB-ERROR.
-           finished       [2] KrbFastFinished OPTIONAL,
-               -- Present in AS or TGS reply; absent otherwise.
-           nonce          [3] UInt32,
-               -- Nonce from the client request.
-           ...
-  }
-
-   The padata field in the KrbFastResponse structure contains a list of
-   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
-   PA-DATA structures are used to carry data advancing the exchange
-   specific for the FAST factors.  They can also be used as generic
-   typed-holes for protocol extensibility.  Unless otherwise specified,
-   the KDC MUST include any padata that is otherwise in the outer KDC-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 31]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   REP structure into this field.  The padata field in the KDC reply
-   structure outside of the PA-FX-FAST-REPLY structure typically
-   includes only the PA-FX- FAST-REPLY padata.
-
-   The strengthen-key field provides a mechanism for the KDC to
-   strengthen the reply key.  If set, the reply key is strengthened
-   after all padata items are processed.  Let padata-reply-key be the
-   reply key after padata processing.
-
-   reply-key = KRB-FX-CF2(strengthen-key, padata-reply-key,
-                         "strengthenkey", "replykey")
-
-   The strengthen-key field MAY be set in an AS reply; it MUST be set in
-   a TGS reply; it must be absent in an error reply.  The strengthen key
-   is required in a TGS reply so that an attacker cannot remove the FAST
-   PADATA from a TGS reply, causing the KDC to appear not to support
-   FAST.
-
-   The finished field contains a KrbFastFinished structure.  It is
-   filled by the KDC in the final message in the conversation.  This
-   field is present in an AS-REP or a TGS-REP when a ticket is returned,
-   and it is not present in an error reply.
-
-   The KrbFastFinished structure contains the following information:
-
-       KrbFastFinished ::= SEQUENCE {
-           timestamp       [0] KerberosTime,
-           usec            [1] Microseconds,
-               -- timestamp and usec represent the time on the KDC when
-               -- the reply was generated.
-           crealm          [2] Realm,
-           cname           [3] PrincipalName,
-               -- Contains the client realm and the client name.
-           ticket-checksum [4] Checksum,
-               -- checksum of the ticket in the KDC-REP  using the armor
-               -- and the key usage is KEY_USAGE_FAST_FINISH.
-               -- The checksum type is the required checksum type
-               -- of the armor key.
-           ...
-       }
-       KEY_USAGE_FAST_FINISHED            53
-
-   The timestamp and usec fields represent the time on the KDC when the
-   reply ticket was generated, these fields have the same semantics as
-   the corresponding-identically-named fields in Section 5.6.1 of
-   [RFC4120].  The client MUST use the KDC's time in these fields
-   thereafter when using the returned ticket.  Note that the KDC's time
-   in AS-REP may not match the authtime in the reply ticket if the kdc-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 32]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   follow-referrals option is requested and honored by the KDC.  The
-   client need not confirm that the timestamp returned is within
-   allowable clock skew: the armor key guarantees that the reply is
-   fresh.  The client MAY trust the time stamp returned.
-
-   The cname and crealm fields identify the authenticated client.  If
-   facilities described in [REFERRALS] are used, the authenticated
-   client may differ from the client in the FAST request.
-
-   The ticket-checksum is a checksum of the issued ticket.  The checksum
-   key is the armor key, and the checksum type is the required checksum
-   type of the enctype of that key, and the key usage number is
-   KEY_USAGE_FAST_FINISHED.
-
-   When FAST padata is included, the PA-FX-COOKIE padata as defined in
-   Section 6.3 MUST be included in the padata sequence in the
-   KrbFastResponse sequence if the KDC expects at least one more message
-   from the client in order to complete the authentication.
-
-   The nonce field in the KrbFastResponse contains the value of the
-   nonce field in the KDC-REQ of the corresponding client request and it
-   binds the KDC response with the client request.  The client MUST
-   verify that this nonce value in the reply matches with that of the
-   request and reject the KDC reply otherwise.  To prevent the response
-   from one message in a conversation from being replayed to a request
-   in another message, clients SHOULD use a new nonce for each message
-   in a conversation.
-
-6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
-
-   If the Kerberos FAST padata was included in the request, unless
-   otherwise specified, the e-data field of the KRB-ERROR message
-   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
-   [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA.  The KDC
-   MUST include all the padata elements such as PA-ETYPE-INFO2 and
-   padata elements that indicate acceptable pre-authentication
-   mechanisms [RFC4120] in the KrbFastResponse structure.
-
-   The KDC MUST also include a PA-FX-ERROR padata item in the
-   KRBFastResponse structure.  The padata-value element of this sequence
-   is the ASN.1 DER encoding of the type KRB-ERROR.  The e-data field
-   MUST be absent in the PA-FX-ERROR padata.  All other fields should be
-   the same as the outer KRB-ERROR.  The client ignores the outer error
-   and uses the combination of the padata in the KRBFastResponse and the
-   error information in the PA-FX-ERROR.
-
-              PA-FX-ERROR                        137
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 33]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   If the Kerberos FAST padata is included in the request but not
-   included in the error reply, it is a matter of the local policy on
-   the client to accept the information in the error message without
-   integrity protection.  The client SHOULD however process the KDC
-   errors as the result of the KDC's inability to accept the AP_REQ
-   armor and potentially retry another request with a different armor
-   when applicable.  The Kerberos client MAY process an error message
-   without a PA-FX-FAST-REPLY, if that is only intended to return better
-   error information to the application, typically for trouble-shooting
-   purposes.
-
-   In the cases where the e-data field of the KRB-ERROR message is
-   expected to carry a TYPED-DATA [RFC4120] element, then that
-   information should be transmitted in a pa-data element within the
-   KRBFastResponse structure.  The padata-type is the same as the data-
-   type would be in the typed data element and the padata-value is the
-   same as the data-value.  As discussed in Section 8, data-types and
-   padata-types are drawn from the same namespace.  For example, the
-   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
-   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
-   [RFC4556].
-
-6.5.5.  Outer and Inner Requests
-
-   Typically, a client will know that FAST is being used before a
-   request containing PA-FX-FAST is sent.  So, the outer AS request
-   typically only includes one pa-data item: PA-FX-FAST.  The client MAY
-   include additional pa-data, but the KDC MUST ignore the outer request
-   body and any padata besides PA-FX-FAST if and only if PA-FX-FAST is
-   processed.  In the case of the TGS request, the outer request should
-   include PA-FX-FAST and PA-TGS-REQ.
-
-   When an AS generates a response, all padata besides PA-FX-FAST should
-   be included in PA-FX-FAST.  The client MUST ignore other padata
-   outside of PA-FX-FAST.
-
-6.5.6.  The Encrypted Challenge FAST Factor
-
-   The encrypted challenge FAST factor authenticates a client using the
-   client's long-term key.  This factor works similarly to the encrypted
-   time stamp pre-authentication option described in [RFC4120].  The
-   word challenge is used instead of timestamp because while the
-   timestamp is used as an initial challenge, if the KDC and client do
-   not have synchronized time, then the KDC can provide updated time to
-   the client to use as a challenge.  The client encrypts a structure
-   containing a timestamp in the challenge key.  The challenge key used
-   by the client to send a message to the KDC is KRB-FX-
-   CF2(armor_key,long_term_key, "clientchallengearmor",
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 34]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   "challengelongterm").  The challenge key used by the KDC encrypting
-   to the client is KRB-FX-CF2(armor_key, long_term_key,
-   "kdcchallengearmor", "challengelongterm").  Because the armor key is
-   fresh and random, the challenge key is fresh and random.  The only
-   purpose of the timestamp is to limit the validity of the
-   authentication so that a request cannot be replayed.  A client MAY
-   base the timestamp on the KDC time in a KDC error and need not
-   maintain accurate time synchronization itself.  If a client bases its
-   time on an untrusted source, an attacker may trick the client into
-   producing an authentication request that is valid at some future
-   time.  The attacker may be able to use this authentication request to
-   make it appear that a client has authenticated at that future time.
-   If ticket-based armor is used, then the lifetime of the ticket will
-   limit the window in which an attacker can make the client appear to
-   have authenticated.  For many situations, the ability of an attacker
-   to cause a client to appear to have authenticated is not a
-   significant concern; the ability to avoid requiring time
-   synchronization on clients is more valuable.
-
-   The client sends a padata of type PA-ENCRYPTED-CHALLENGE.  The
-   corresponding padata-value contains the DER encoding of ASN.1 type
-   EncryptedChallenge.
-
-      EncryptedChallenge ::= EncryptedData
-              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
-
-      PA-ENCRYPTED-CHALLENGE          138
-      KEY_USAGE_ENC_CHALLENGE_CLIENT  54
-      KEY_USAGE_ENC_CHALLENGE_KDC     55
-
-   The client includes some time stamp reasonably close to the KDC's
-   current time and encrypts it in the challenge key.  Clients MAY use
-   the current time; doing so prevents the exposure where an attacker
-   can cause a client to appear to authenticate in the future.  The
-   client sends the request including this factor.
-
-   On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE fast
-   factor, the KDC decrypts the timestamp.  If the decryption fails the
-   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in
-   the KRBFastResponse in the error.  The KDC confirms that the
-   timestamp falls within its current clock skew returning
-   KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see if the
-   encrypted challenge is a replay.  The KDC MUST NOT consider two
-   encrypted challenges replays simply because the time stamps are the
-   same; to be a replay, the ciphertext MUST be identical.  Allowing
-   clients to re-use time stamps avoids requiring that clients maintain
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 35]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   state about which time stamps have been used.
-
-   If the KDC accepts the encrypted challenge, it MUST include a padata
-   element of type PA-ENCRYPTED-CHALLENGE.  The KDC encrypts its current
-   time in the challenge key.  The KDC MUST strengthen the reply key
-   before issuing a ticket.  The client MUST check that the timestamp
-   decrypts properly.  The client MAY check that the timestamp is within
-   the window of acceptable clock skew for the client.  The client MUST
-   NOT require that the timestamp be identical to the timestamp in the
-   issued credentials or the returned message.
-
-   The encrypted challenge FAST factor provides the following
-   facilities: client-authentication and KDC authentication.  This FAST
-   factor also takes advantage of the FAST facility to strengthen the
-   reply key.  It does not provide the replacing-reply-key facility.
-   The security considerations section of this document provides an
-   explanation why the security requirements are met.
-
-   The encrypted challenge FAST factor can be useful in an
-   authentication set.  No pa-hint is defined because the only
-   information needed by this mechanism is information contained in the
-   PA-ETYPE-INFO2 pre-authentication data.  KDCs are already required to
-   send PA-ETYPE-INFO2.  If KDCs were not required to send PA-ETYPE-
-   INFO2 then that information would need to be part of a hint for
-   encrypted challenge.
-
-   Conforming implementations MUST support the encrypted challenge FAST
-   factor.
-
-6.6.  Authentication Strength Indication
-
-   Implementations that have pre-authentication mechanisms offering
-   significantly different strengths of client authentication MAY choose
-   to keep track of the strength of the authentication used as an input
-   into policy decisions.  For example, some principals might require
-   strong pre-authentication, while less sensitive principals can use
-   relatively weak forms of pre-authentication like encrypted timestamp.
-
-   An AuthorizationData data type AD-Authentication-Strength is defined
-   for this purpose.
-
-        AD-authentication-strength         70
-
-   The corresponding ad-data field contains the DER encoding of the pre-
-   authentication data set as defined in Section 6.4.  This set contains
-   all the pre-authentication mechanisms that were used to authenticate
-   the client.  If only one pre-authentication mechanism was used to
-   authenticate the client, the pre-authentication set contains one
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 36]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   element.
-
-   The AD-authentication-strength element MUST be included in the AD-IF-
-   RELEVANT, thus it can be ignored if it is unknown to the receiver.
-
-
-7.  Assigned Constants
-
-   The pre-authentication framework and FAST involve using a number of
-   Kerberos protocol constants.  This section lists protocol constants
-   first introduced in this specification drawn from registries not
-   managed by IANA.  Many of these registries would best be managed by
-   IANA; that is a known issue that is out of scope for this document.
-   The constants described in this section have been accounted for and
-   will appear in the next revision of the Kerberos core specification
-   or in a document creating IANA registries.
-
-   Section 8 creates IANA registries for a different set of constants
-   used by the extensions described in this document.
-
-7.1.  New Errors
-
-           KDC_ERR_PREAUTH_EXPIRED                 90
-           KDC_ERR_MORE_PREAUTH_DATA_REQUIRED      91
-           KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET  92
-           KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
-
-7.2.  Key Usage Numbers
-
-           KEY_USAGE_FAST_REQ_CHKSUM               50
-           KEY_USAGE_FAST_ENC                      51
-           KEY_USAGE_FAST_REP                      52
-           KEY_USAGE_FAST_FINISHED                 53
-           KEY_USAGE_ENC_CHALLENGE_CLIENT          54
-           KEY_USAGE_ENC_CHALLENGE_KDC             55
-
-7.3.  Authorization Data Elements
-
-           AD-authentication-strength              70
-           AD-fx-fast-armor                        71
-           AD-fx-fast-used                         72
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 37]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-7.4.  New PA-DATA Types
-
-           PA-FX-COOKIE                            133
-           PA-AUTHENTICATION-SET                   134
-           PA-AUTH-SET-SELECTED                    135
-           PA-FX-FAST                              136
-           PA-FX-ERROR                             137
-           PA-ENCRYPTED-CHALLENGE                  138
-
-
-8.  IANA Considerations
-
-   This document creates a number of IANA registries.  These registries
-   should all be located under
-   http://www.iana.org/assignments/kerberos-parameters.
-
-8.1.  Pre-authentication and Typed Data
-
-   RFC 4120 defines pre-authentication data, which can be included in a
-   KDC request or response in order to authenticate the client or extend
-   the protocol.  In addition, it defines Typed-Data which is an
-   extension mechanism for errors.  Both pre-authentication data and
-   typed data are carried as a 32-bit signed integer along with an octet
-   string.  The encoding of typed data and pre-authentication data is
-   slightly different.  However the types for pre-authentication data
-   and typed-data are drawn from the same namespace.  By convention,
-   registrations starting with TD- are typed data and registration
-   starting with PA- are pre-authentication data.  It is important that
-   these data types be drawn from the same namespace, because some
-   errors where it would be desirable to include typed data require the
-   e-data field to be formatted as pre-authentication data.
-
-   When Kerberos FAST is used, pre-authentication data encoding is
-   always used.
-
-   There is one apparently conflicting registration between typed data
-   and pre-authentication data.  PA-GET-FROM-TYPED-DATA and TD-PADATA
-   are both assigned the value 22.  However this registration is simply
-   a mechanism to include an element of the other encoding.  The use of
-   both should be deprecated.
-
-   This document creates a registry for pre-authentication and typed
-   data.  The registration procedures are as follows.  Expert review for
-   pre-authentication mechanisms designed to authenticate users, KDCs,
-   or establish the reply key.  The expert first determines that the
-   purpose of the method is to authenticate clients, KDCs, or to
-   establish the reply key.  If so, expert review is appropriate.  The
-   expert evaluates the security and interoperability of the
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 38]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   specification.
-
-   IETF review is required if the expert believes that the pre-
-   authentication method is broader than these three areas.  Pre-
-   authentication methods that change the Kerberos state machine or
-   otherwise make significant changes to the Kerberos protocol should be
-   standards track RFCs.  A concern that a particular method needs to be
-   a standards track RFC may be raised as an objection during IETF
-   review.
-
-      Type                Value    Reference
-  ----------------------------------------------------------------------
-  PA-TGS-REQ                 1    RFC 4120
-  PA-ENC-TIMESTAMP           2    RFC 4120
-  PA-PW-SALT                 3    RFC 4120
-  [reserved]                 4
-  PA-ENC-UNIX-TIME           5    (deprecated)
-  PA-SANDIA-SECUREID         6
-  PA-SESAME                  7
-  PA-OSF-DCE                 8
-  PA-CYBERSAFE-SECUREID      9
-  PA-AFS3-SALT               10
-  PA-ETYPE-INFO              11   RFC 4120
-  PA-SAM-CHALLENGE           12   (sam/otp)
-  PA-SAM-RESPONSE            13   (sam/otp)
-  PA-PK-AS-REQ_OLD           14   draft-ietf-cat-kerberos-pk-init-09
-  PA-PK-AS-REP_OLD           15   draft-ietf-cat-kerberos-pk-init-09
-  PA-PK-AS-REQ               16   RFC 4556
-  PA-PK-AS-REP               17   RFC 4556
-  PA-PK-OCSP-RESPONSE        18   RFC 4557
-  PA-ETYPE-INFO2             19   RFC 4120
-  PA-USE-SPECIFIED-KVNO      20
-  PA-SVR-REFERRAL-INFO       20   (referrals)
-  PA-SAM-REDIRECT            21   (sam/otp)
-  PA-GET-FROM-TYPED-DATA     22   (embedded in typed data)
-  TD-PADATA                  22   (embeds padata)
-  PA-SAM-ETYPE-INFO          23   (sam/otp)
-  PA-ALT-PRINC               24   (crawdad@fnal.gov)
-  PA-SERVER-REFERRAL         25   (referrals)
-  PA-SAM-CHALLENGE2          30   (kenh@pobox.com)
-  PA-SAM-RESPONSE2           31   (kenh@pobox.com)
-  PA-EXTRA-TGT               41   Reserved extra TGT
-  TD-PKINIT-CMS-CERTIFICATES 101  CertificateSet from CMS
-  TD-KRB-PRINCIPAL           102  PrincipalName
-  TD-KRB-REALM               103  Realm
-  TD-TRUSTED-CERTIFIERS      104  PKINIT
-  TD-CERTIFICATE-INDEX       105  PKINIT
-  TD-APP-DEFINED-ERROR       106  Application specific
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 39]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-  TD-REQ-NONCE               107  INTEGER
-  TD-REQ-SEQ                 108  INTEGER
-  PA-PAC-REQUEST             128  MS-KILE
-  PA-FOR_USER                129  MS-KILE
-  PA-FOR-X509-USER           130  MS-KILE
-  PA-FOR-CHECK_DUPS          131  MS-KILE
-  PA-AS-CHECKSUM             132  MS-KILE
-  PA-FX-COOKIE               133  draft-ietf-krb-wg-preauth-framework
-  PA-AUTHENTICATION-SET      134  draft-ietf-krb-wg-preauth-framework
-  PA-AUTH-SET-SELECTED       135  draft-ietf-krb-wg-preauth-framework
-  PA-FX-FAST                 136  draft-ietf-krb-wg-preauth-framework
-  PA-FX-ERROR                137  draft-ietf-krb-wg-preauth-framework
-  PA-ENCRYPTED-CHALLENGE     138  draft-ietf-krb-wg-preauth-framework
-  PA-OTP-CHALLENGE           141  (gareth.richards@rsa.com)
-  PA-OTP-REQUEST             142  (gareth.richards@rsa.com)
-  PA-OTP-CONFIRM             143  (gareth.richards@rsa.com)
-  PA-OTP-PIN-CHANGE          144  (gareth.richards@rsa.com)
-  PA-EPAK-AS-REQ             145  (sshock@gmail.com)
-  PA-EPAK-AS-REP             146  (sshock@gmail.com>)
-  PA_PKINIT_KX               147  draft-ietf-krb-wg-anon
-  PA_PKU2U_NAME              148  draft-zhu-pku2u
-  PA-SUPPORTED-ETYPES        165  MS-KILE
-  PA-EXTENDED_ERROR          166  MS-KILE
-
-8.2.  Fast Armor Types
-
-   FAST armor types are defined in Section 6.5.1.  A FAST armor type is
-   a signed 32-bit integer.  FAST armor types are assigned by standards
-   action.
-
-          Type    Name                   Description
-        ------------------------------------------------------------
-          0                              Reserved.
-          1   FX_FAST_ARMOR_AP_REQUEST   Ticket armor using an ap-req.
-
-8.3.  FAST Options
-
-   A FAST request includes a set of bit flags to indicate additional
-   options.  Bits 0-15 are critical; other bits are non-critical.
-   Assigning bits greater than 31 may require special support in
-   implementations.  Assignment of FAST options requires standards
-   action.
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 40]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-      Type    Name                   Description
-     -------------------------------------------------------------------
-      0     RESERVED               Reserved for future expansion of this
-                                   field.
-      1     hide-client-names      Requesting the KDC to hide client
-                                   names in the KDC response
-      16    kdc-follow-referrals   Requesting the KDC to follow
-                                   referrals
-
-
-9.  Security Considerations
-
-   The kdc-referrals option in the Kerberos FAST padata requests the KDC
-   to act as the client to follow referrals.  This can overload the KDC.
-   To limit the damages of denial of service using this option, KDCs MAY
-   restrict the number of simultaneous active requests with this option
-   for any given client principal.
-
-   Regarding to the facilities provided by the Encrypted Challenge FAST
-   factor, the challenge key is derived from the client secrets and
-   because the client secrets are known only to the client and the KDC,
-   the verification of the EncryptedChallenge structure proves the
-   client's identity, the verification of the EncryptedChallenge
-   structure in the KDC reply proves that the expected KDC responded.
-   Therefore, the Encrypted Challenge FAST factor as a pre-
-   authentication mechanism offers the following facilities: client-
-   authentication and KDC-authentication.  There is no un-authenticated
-   clear text introduced by the Encrypted Challenge FAST factor.
-
-   FAST provides an encrypted tunnel over which pre-authentication
-   conversations can take place.  In addition, FAST optionally
-   authenticates the KDC to the client.  It is the responsibility of
-   FAST factors to authenticate the client to the KDC.  Care MUST be
-   taken to design FAST factors such that they are bound to the
-   conversation.  If this is not done, a man-in-the-middle may be able
-   to cut&paste a fast factor from one conversation to another.  The
-   easiest way to do this is to bind each fast factor to the armor key
-   which is guaranteed to be unique for each conversation.
-
-   The anonymous pkinit mode for obtaining an armor ticket does not
-   always authenticate the KDC to the client before the conversation
-   begins.  Tracking the KDC verified state guarantees that by the end
-   of the conversation, the client has authenticated the KDC.  However
-   fast factor designers need to consider the implications of using
-   their factor when the KDC has not yet been authenticated.  If this
-   proves problematic in an environment, then the particular fast factor
-   should not be used with anonymous PKINIT.
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 41]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   Existing pre-authentication mechanisms are believed to be at least as
-   secure when used with FAST as they are when used outside of FAST.
-   One part of this security is making sure that when pre-authentication
-   methods checksum the request, they checksum the inner request rather
-   than the outer request.  If the mechanism checksummed the outer
-   request, a man-in-the-middle could observe it outside a FAST tunnel
-   and then cut&paste it into a FAST exchange where the inner rather
-   than outer request would be used to select attributes of the issued
-   ticket.  Such attacks would typically invalidate auditing information
-   or create a situation where the client and KDC disagree about what
-   ticket is issued.  However, such attacks are unlikely to allow an
-   attacker who would not be able to authenticate as a principal to do
-   so.  Even so, FAST is believed to defend against these attacks in
-   existing legacy mechanism.  However since there is no standard for
-   how legacy mechanisms bind the request to the pre-authentication or
-   provide integrity protection, security analysis can be difficult.  In
-   some cases FAST may significantly improve the integrity protection of
-   legacy mechanisms.
-
-   The security of the TGS exchange depends on authenticating the client
-   to the KDC.  In the AS exchange, this is done using pre-
-   authentication data or FAST factors.  In the TGS exchange, this is
-   done by presenting a TGT and by using the session (or sub-session)
-   key in constructing the request.  Because FAST uses a request body in
-   the inner request, encrypted in the armor key, rather than the
-   request body in the outer request, it is critical that establishing
-   the armor key be tied to the authentication of the client to the KDC.
-   If this is not done, an attacker could manipulate the options
-   requested in the TGS request, for example requesting a ticket with
-   different validity or addresses.  The easiest way to bind the armor
-   key to the authentication of the client to the KDC is for the armor
-   key to depend on the sub-session key of the TGT.  This is done with
-   the implicit TGS armor supported by this specification.  Future armor
-   types designed for use with the TGS MUST either bind their armor keys
-   to the TGT or provide another mechanism to authenticate the client to
-   the KDC.
-
-
-10.  Acknowledgements
-
-   Sam Hartman would like to thank the MIT Kerberos Consortium for its
-   funding of his time on this project.
-
-   Several suggestions from Jeffrey Hutzelman based on early revisions
-   of this documents led to significant improvements of this document.
-
-   The proposal to ask one KDC to chase down the referrals and return
-   the final ticket is based on requirements in [ID.CROSS].
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 42]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-   Joel Webber had a proposal for a mechanism similar to FAST that
-   created a protected tunnel for Kerberos pre-authentication.
-
-   Srinivas Cheruku and Greg Hudson provided valuable review comments.
-
-
-11.  References
-
-11.1.  Normative References
-
-   [KRB-ANON]
-              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
-              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-11.2.  Informative References
-
-   [EKE]      Bellovin, S. and M. Merritt, "Augmented Encrypted Key
-              Exchange: A Password-Based Protocol Secure Against
-              Dictionary Attacks and Password File Compromise,
-              Proceedings of the 1st ACM Conference on Computer and
-              Communications Security, ACM Press.", November 1993.
-
-   [ID.CROSS]
-              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
-              Statement on the Operation of Kerberos in a Specific
-              System", draft-sakane-krb-cross-problem-statement-02.txt
-              (work in progress), April 2007.
-
-   [IEEE1363.2]
-              IEEE, "IEEE P1363.2: Password-Based Public-Key
-              Cryptography", 2004.
-
-   [KRB-WG.SAM]
-              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
-              "Integrating Single-use Authentication Mechanisms with
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 43]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
-              progress), October 2003.
-
-   [REFERRALS]
-              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
-              Locate Kerberos Realms",
-              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
-              progress), 2007.
-
-
-Appendix A.  Test Vectors for KRB-FX-CF2
-
-   This informative appendix presents test vectors for the KRB-FX-CF2
-   function.  Test vectors are presented for several encryption types.
-   In all cases the first key (k1) is the result of string-to-
-   key("key1", "key1", default_parameters) and the second key (k2) is
-   the result of string-to-key("key2", "key2", default_parameters).
-   Both keys are of the same enctype.  The presented test vector is the
-   hexadecimal encoding of the key produced by KRB-FX-CF2(k1, k2, "a",
-   "b").  The peppers are one-octet ASCII strings.
-
-   In performing interoperability testing, there was significant
-   ambiguity surrounding [RFC3961] pseudo-random operations.  These test
-   vectors assume that the AES pseudo-random operation is aes-
-   ecb(trunc128(sha-1(input))) where trunc128 truncates its input to
-   128-bits.  The 3DES pseudo-random operation is assumed to be des3-
-   cbc(trunc128(sha-1(input))).  The DES pseudo-random operation is
-   assumed to be des-cbc(md5(input)).  As specified in RFC 4757, the RC4
-   pseudo-random operation is hmac-sha1(input).
-
-   These test vectors were produced with revision 22359 of the MIT
-   Kerberos sources.  The AES 256 and AES 128 test vectors have been
-   confirmed by multiple other implementors.  The RC4 test vectors have
-   been confirmed by one other implementor.  The triple DES test vectors
-   have also been confirmed.
-
-
-   aes 128 (enctype 17): 97df97e4b798b29eb31ed7280287a92a
-   AES256 (enctype 18): 4d6ca4e629785c1f01baf55e2e548566
-                        b9617ae3a96868c337cb93b5e72b1c7b
-   3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01
-   RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672
-
-
-Appendix B.  Change History
-
-   RFC editor, please remove this section before publication.
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 44]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-B.1.  Changes since 12
-
-      Per comment from Greg Hudson, KDC_ERR_MORE_PREAUTH_DATA_REQUIRED
-      instead of KDC_ERR_MORE_PREAUTH_DATA_NEEDED
-      Use pa-authentication-set-selected not pa-auth-set-selected
-      Update discussion of KDC verification (Love)
-      Remove explicit TGS armor, note that TGS armor must authenticate
-      the client to the KDC, describe in security considerations.
-
-B.2.  Changes since 11
-
-      Checksum the inner request body in methods like PKINIT, not the
-      outer request body.  Per mailing list discussion, this change
-      addresses a potential security weakness.
-      Add additional security considerations text
-
-B.3.  Changes since 10
-
-      The checksum member of the KrbFastFinished sequence has been
-      removed.  A nonce field has been added to KrbFastResponse.
-      The cookie no longer needs to be outside of FAST.  In fact, some
-      security guarantees depend on the cookie being inside FAST now
-      that the finish checksum has been removed.  Affected that change.
-      Replace the rep-key field in KrbFastResponse with the strengthen-
-      key field.  Per mailing list discussion, there are security
-      advantages to strengthening the reply key.
-      Clarify handling of authentication sets.
-      Include the AD-fx-fast-used authorization data type.
-      Include note about random nonces.
-
-B.4.  Changes since 09
-
-      Clarify conversations by defining for TGS and by describing how
-      cookies form conversation boundaries.
-      Simplify text surrounding when finish is included: always for AS
-      and TGS reply, never for error.
-      Fill in IANA and constants
-
-B.5.  Changes since 08
-
-      Fix a number of typos
-      Rename anonymous flag to hide-client-name; rename kdc-referals to
-      kdc-follow-referrals
-      Clarify how anonymous pkinit interacts with KDC verified.
-      Introduce AD-fx-fast-armor authorization data to deal with
-      unprivileged processes constructing KDC requests.  Note that a TGT
-      is always used for armor tickets if the armor field is present; if
-      you proxy or validate you'll end up with a TGT armor ticket and
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 45]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-      another ticket in the pa-tgs-req.  Alternatively you can simply
-      use the other ticket in the PA-TGS-REQ; weak consensus within WG.
-      All KDCs in a realm MUST support FAST if it is to be offered.
-      The cookie message is always generated by the KDC.
-      Note that the client can trust and need not verify the time stamp
-      in the finish message.  This can seed the client's idea of KDC
-      time.
-      Note that the client name in the finish message may differ from
-      the name in the request if referrals are used.
-      Note that KDCs should advertize fast in preauth_required errors.
-      Armor key is constructed using KRB-FX-CF2.  This is true even in
-      the TGS case; there is no security reason to do this.  Using the
-      subkey as done in draft 08 would be fine, but the current text
-      uses the same procedure both in the TGS and AS case.
-      Use a different challenge key in each direction in the encrypted
-      challenge option.
-      Note that the KDC should process PA-FX-COOKIE before other padata.
-      KRB-FX-CF2 uses k1's enctype for the result; change around calling
-      order so we pass in subkeys and armor keys as k1 in preference to
-      long-term keys or ticket session keys.
-      Clarify the relationship between authentication sets and cookies.
-      A cookie may not be needed in the first message.  Clarify how this
-      interacts with optimistic clients.
-      Remove text raising a concern that RFC 3961 may permit ciphertext
-      transformations that do not change plaintext: discussion on the
-      list came to the conclusion that RFC 3961 does not permit this.
-      Remove binding key concept; use the armor key instead.  The cookie
-      becomes just an octet string.
-      Include PA-FX-ERROR to protect the error information per Dublin.
-      Returning preauth_failed in the failed to decrypt encrypted
-      challenge seems fine; remove the issue marker
-      Add a section describing what goes in the inner and outer request.
-      I believe it is redundant but found it useful while putting
-      together an implementation proposal.
-      Use hyphen rather than underscore in the constants for pre-
-      authentication data to be consistent with RFC 4120.
-      Add a ticket-checksum to the finished message
-      Remove redundant KEY_USAGE_FAST_ARMOR.
-      Add protocol constants section for non-IANA registrations and
-      flesh out IANA section.
-      Clarify that kdc-req-body checksums should always use the outer
-      body even for mechanisms like PKINIT that include their own (now
-      redundant) checksum.
-      Remove mechanism for encapsulating typed data in padata; just
-      reflect the value.
-
-
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 46]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-B.6.  Changes since 07
-
-      Propose replacement of authenticated timestamp with encrypted
-      challenge.  The desire to avoid clients needing time
-      synchronization and to simply the factor.
-      Add a requirement that any FAST armor scheme must provide a fresh
-      key for each conversation.  This allows us to assume that anything
-      encrypted/integrity protected in the right key is fresh and not
-      subject to cross-conversation cut and paste.
-      Removed heartbeat padata.  The KDC will double up messages if it
-      needs to; the client simply sends its message and waits for the
-      next response.
-      Define PA-auth-SET-SELECTED
-      Clarify a KDC cannot ignore padata is has claimed to support
-
-B.7.  Changes since 06
-
-      Note that even for replace reply key it is likely that the side
-      using the mechanism will know that the other side supports it.
-      Since it is reasonably unlikely we'll need a container mechanism
-      other than FAST itself, we don't need to optimize for that case.
-      So, we want to optimize for implementation simplicity.  Thus if
-      you do have such a container mechanism interacting with
-      authentication sets we'll assume that the hint need to describe
-      hints for all contained mechanisms.  This closes out a long-
-      standing issue.
-      Write up what Sam believes is the consensus on UI and prompts in
-      the authentication set: clients MAY assume that they have all the
-      UI information they need.
-
-
-Appendix C.  ASN.1 module
-
-      KerberosPreauthFramework {
-            iso(1) identified-organization(3) dod(6) internet(1)
-            security(5) kerberosV5(2) modules(4) preauth-framework(3)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      IMPORTS
-           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
-           Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
-           Microseconds, KerberosFlags
-                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                  dod(6) internet(1) security(5) kerberosV5(2)
-                  modules(4) krb5spec2(2) };
-                  -- as defined in RFC 4120.
-
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 47]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-      PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-      PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-          pa-type      [0] Int32,
-              -- same as padata-type.
-          pa-hint      [1] OCTET STRING OPTIONAL,
-          pa-value     [2] OCTET STRING OPTIONAL,
-          ...
-      }
-
-      KrbFastArmor ::= SEQUENCE {
-          armor-type   [0] Int32,
-              -- Type of the armor.
-          armor-value  [1] OCTET STRING,
-              -- Value of the armor.
-          ...
-      }
-
-      PA-FX-FAST-REQUEST ::= CHOICE {
-          armored-data [0] KrbFastArmoredReq,
-          ...
-      }
-
-      KrbFastArmoredReq ::= SEQUENCE {
-          armor        [0] KrbFastArmor OPTIONAL,
-              -- Contains the armor that identifies the armor key.
-              -- MUST be present in AS-REQ.
-          req-checksum [1] Checksum,
-              -- For AS, contains the checksum performed over the type
-              -- KDC-REQ-BODY for the req-body field of the KDC-REQ
-              -- structure;
-              -- For TGS, contains the checksum performed over the type
-              -- AP-REQ in the PA-TGS-REQ padata.
-              -- The checksum key is the armor key, the checksum
-              -- type is the required checksum type for the enctype of
-              -- the armor key, and the key usage number is
-              -- KEY_USAGE_FAST_REQ_CHKSUM.
-          enc-fast-req [2] EncryptedData, -- KrbFastReq --
-              -- The encryption key is the armor key, and the key usage
-              -- number is KEY_USAGE_FAST_ENC.
-          ...
-      }
-
-      KrbFastReq ::= SEQUENCE {
-          fast-options [0] FastOptions,
-              -- Additional options.
-          padata       [1] SEQUENCE OF PA-DATA,
-              -- padata typed holes.
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 48]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-          req-body     [2] KDC-REQ-BODY,
-              -- Contains the KDC request body as defined in Section
-              -- 5.4.1 of [RFC4120].
-              -- This req-body field is preferred over the outer field
-              -- in the KDC request.
-           ...
-      }
-
-      FastOptions ::= KerberosFlags
-          -- reserved(0),
-          -- hide-client-names(1),
-          -- kdc-follow-referrals(16)
-
-      PA-FX-FAST-REPLY ::= CHOICE {
-          armored-data [0] KrbFastArmoredRep,
-          ...
-      }
-
-      KrbFastArmoredRep ::= SEQUENCE {
-          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
-              -- The encryption key is the armor key in the request, and
-              -- the key usage number is KEY_USAGE_FAST_REP.
-          ...
-      }
-
-      KrbFastResponse ::= SEQUENCE {
-          padata         [0] SEQUENCE OF PA-DATA,
-              -- padata typed holes.
-          strengthen-key [1] EncryptionKey OPTIONAL,
-              -- This, if present, strengthens the reply key for AS and
-              -- TGS.  MUST be present for TGS
-              -- MUST be absent in KRB-ERROR.
-          finished       [2] KrbFastFinished OPTIONAL,
-              -- Present in AS or TGS reply; absent otherwise.
-          nonce          [3] UInt32,
-              -- Nonce from the client request.
-          ...
-      }
-
-      KrbFastFinished ::= SEQUENCE {
-          timestamp       [0] KerberosTime,
-          usec            [1] Microseconds,
-              -- timestamp and usec represent the time on the KDC when
-              -- the reply was generated.
-          crealm          [2] Realm,
-          cname           [3] PrincipalName,
-              -- Contains the client realm and the client name.
-          ticket-checksum [4] Checksum,
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 49]
-
-Internet-Draft         Kerberos Preauth Framework              July 2009
-
-
-              -- checksum of the ticket in the KDC-REP  using the armor
-              -- and the key usage is KEY_USAGE_FAST_FINISH.
-              -- The checksum type is the required checksum type
-              -- of the armor key.
-          ...
-      }
-
-      EncryptedChallenge ::= EncryptedData
-              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
-      END
-
-
-Authors' Addresses
-
-   Sam hartman
-   Painless Security
-
-   Email: hartmans-ietf@mit.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires January 30, 2010               [Page 50]
-
-
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-14.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-14.txt
deleted file mode 100644
index 588b87adb..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-14.txt
+++ /dev/null
@@ -1,2801 +0,0 @@
-
-
-
-Kerberos Working Group                                        S. Hartman
-Internet-Draft                                         Painless Security
-Updates: 4120 (if approved)                                       L. Zhu
-Intended status: Standards Track                   Microsoft Corporation
-Expires: February 13, 2010                               August 12, 2009
-
-
-        A Generalized Framework for Kerberos Pre-Authentication
-                 draft-ietf-krb-wg-preauth-framework-14
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on February 13, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   Kerberos is a protocol for verifying the identity of principals
-   (e.g., a workstation user or a network server) on an open network.
-
-
-
-Hartman & Zhu           Expires February 13, 2010               [Page 1]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   The Kerberos protocol provides a mechanism called pre-authentication
-   for proving the identity of a principal and for better protecting the
-   long-term secrets of the principal.
-
-   This document describes a model for Kerberos pre-authentication
-   mechanisms.  The model describes what state in the Kerberos request a
-   pre-authentication mechanism is likely to change.  It also describes
-   how multiple pre-authentication mechanisms used in the same request
-   will interact.
-
-   This document also provides common tools needed by multiple pre-
-   authentication mechanisms.  One of these tools is a secure channel
-   between the client and the KDC with a reply key strengthening
-   mechanism; this secure channel can be used to protect the
-   authentication exchange thus eliminate offline dictionary attacks.
-   With these tools, it is relatively straightforward to chain multiple
-   authentication mechanisms, utilize a different key management system,
-   or support a new key agreement algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010               [Page 2]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Conventions and Terminology Used in This Document  . . . . . .  6
-   3.  Model for Pre-Authentication . . . . . . . . . . . . . . . . .  6
-     3.1.  Information Managed by the Pre-authentication Model  . . .  7
-     3.2.  Initial Pre-authentication Required Error  . . . . . . . . 10
-     3.3.  Client to KDC  . . . . . . . . . . . . . . . . . . . . . . 10
-     3.4.  KDC to Client  . . . . . . . . . . . . . . . . . . . . . . 11
-   4.  Pre-Authentication Facilities  . . . . . . . . . . . . . . . . 12
-     4.1.  Client-authentication Facility . . . . . . . . . . . . . . 13
-     4.2.  Strengthening-reply-key Facility . . . . . . . . . . . . . 14
-     4.3.  Replacing-reply-key Facility . . . . . . . . . . . . . . . 15
-     4.4.  KDC-authentication Facility  . . . . . . . . . . . . . . . 15
-   5.  Requirements for Pre-Authentication Mechanisms . . . . . . . . 16
-   6.  Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 17
-     6.1.  Combining Keys . . . . . . . . . . . . . . . . . . . . . . 17
-     6.2.  Protecting Requests/Responses  . . . . . . . . . . . . . . 18
-     6.3.  Managing States for the KDC  . . . . . . . . . . . . . . . 19
-     6.4.  Pre-authentication Set . . . . . . . . . . . . . . . . . . 20
-     6.5.  Definition of Kerberos FAST Padata . . . . . . . . . . . . 23
-       6.5.1.  FAST Armors  . . . . . . . . . . . . . . . . . . . . . 24
-       6.5.2.  FAST Request . . . . . . . . . . . . . . . . . . . . . 26
-       6.5.3.  FAST Response  . . . . . . . . . . . . . . . . . . . . 30
-       6.5.4.  Authenticated Kerberos Error Messages using
-               Kerberos FAST  . . . . . . . . . . . . . . . . . . . . 33
-       6.5.5.  Outer and Inner Requests . . . . . . . . . . . . . . . 34
-       6.5.6.  The Encrypted Challenge FAST Factor  . . . . . . . . . 34
-     6.6.  Authentication Strength Indication . . . . . . . . . . . . 36
-   7.  Assigned Constants . . . . . . . . . . . . . . . . . . . . . . 37
-     7.1.  New Errors . . . . . . . . . . . . . . . . . . . . . . . . 37
-     7.2.  Key Usage Numbers  . . . . . . . . . . . . . . . . . . . . 37
-     7.3.  Authorization Data Elements  . . . . . . . . . . . . . . . 37
-     7.4.  New PA-DATA Types  . . . . . . . . . . . . . . . . . . . . 38
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
-     8.1.  Pre-authentication and Typed Data  . . . . . . . . . . . . 38
-     8.2.  Fast Armor Types . . . . . . . . . . . . . . . . . . . . . 40
-     8.3.  FAST Options . . . . . . . . . . . . . . . . . . . . . . . 40
-   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 41
-   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 43
-     11.2. Informative References . . . . . . . . . . . . . . . . . . 43
-   Appendix A.  Test Vectors for KRB-FX-CF2 . . . . . . . . . . . . . 44
-   Appendix B.  Change History  . . . . . . . . . . . . . . . . . . . 45
-     B.1.  Changes since 13 . . . . . . . . . . . . . . . . . . . . . 45
-     B.2.  Changes since 12 . . . . . . . . . . . . . . . . . . . . . 45
-     B.3.  Changes since 11 . . . . . . . . . . . . . . . . . . . . . 45
-
-
-
-Hartman & Zhu           Expires February 13, 2010               [Page 3]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-     B.4.  Changes since 10 . . . . . . . . . . . . . . . . . . . . . 45
-     B.5.  Changes since 09 . . . . . . . . . . . . . . . . . . . . . 45
-     B.6.  Changes since 08 . . . . . . . . . . . . . . . . . . . . . 46
-     B.7.  Changes since 07 . . . . . . . . . . . . . . . . . . . . . 47
-     B.8.  Changes since 06 . . . . . . . . . . . . . . . . . . . . . 47
-   Appendix C.  ASN.1 module  . . . . . . . . . . . . . . . . . . . . 47
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010               [Page 4]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-1.  Introduction
-
-   The core Kerberos specification [RFC4120] treats pre-authentication
-   data as an opaque typed hole in the messages to the KDC that may
-   influence the reply key used to encrypt the KDC reply.  This
-   generality has been useful: pre-authentication data is used for a
-   variety of extensions to the protocol, many outside the expectations
-   of the initial designers.  However, this generality makes designing
-   more common types of pre-authentication mechanisms difficult.  Each
-   mechanism needs to specify how it interacts with other mechanisms.
-   Also, problems like combining a key with the long-term secrets or
-   proving the identity of the user are common to multiple mechanisms.
-   Where there are generally well-accepted solutions to these problems,
-   it is desirable to standardize one of these solutions so mechanisms
-   can avoid duplication of work.  In other cases, a modular approach to
-   these problems is appropriate.  The modular approach will allow new
-   and better solutions to common pre-authentication problems to be used
-   by existing mechanisms as they are developed.
-
-   This document specifies a framework for Kerberos pre-authentication
-   mechanisms.  It defines the common set of functions that pre-
-   authentication mechanisms perform as well as how these functions
-   affect the state of the request and reply.  In addition several
-   common tools needed by pre-authentication mechanisms are provided.
-   Unlike [RFC3961], this framework is not complete--it does not
-   describe all the inputs and outputs for the pre-authentication
-   mechanisms.  Pre-Authentication mechanism designers should try to be
-   consistent with this framework because doing so will make their
-   mechanisms easier to implement.  Kerberos implementations are likely
-   to have plugin architectures for pre-authentication; such
-   architectures are likely to support mechanisms that follow this
-   framework plus commonly used extensions.  This framework also
-   facilitates combining multiple pre-authentication mechanisms, each of
-   which may represent an authentication factor, into a single multi-
-   factor pre-authentication mechanism.
-
-   One of these common tools is the flexible authentication secure
-   tunneling (FAST) padata type.  FAST provides a protected channel
-   between the client and the KDC, and it can optionally deliver key
-   material used to strengthen the reply key within the protected
-   channel.  Based on FAST, pre-authentication mechanisms can extend
-   Kerberos with ease, to support, for example, password authenticated
-   key exchange (PAKE) protocols with zero knowledge password proof
-   (ZKPP) [EKE] [IEEE1363.2].  Any pre-authentication mechanism can be
-   encapsulated in the FAST messages as defined in Section 6.5.  A pre-
-   authentication type carried within FAST is called a FAST factor.
-   Creating a FAST factor is the easiest path to create a new pre-
-   authentication mechanism.  FAST factors are significantly easier to
-
-
-
-Hartman & Zhu           Expires February 13, 2010               [Page 5]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   analyze from a security standpoint than other pre-authentication
-   mechanisms.
-
-   Mechanism designers should design FAST factors, instead of new pre-
-   authentication mechanisms outside of FAST.
-
-
-2.  Conventions and Terminology Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   This document should be read only after reading the documents
-   describing the Kerberos cryptography framework [RFC3961] and the core
-   Kerberos protocol [RFC4120].  This document may freely use
-   terminology and notation from these documents without reference or
-   further explanation.
-
-   The word padata is used as a shorthand for pre-authentication data.
-
-   A conversation is the set of all authentication messages exchanged
-   between the client and the client's Authentication Service (AS) in
-   order to authenticate the client principal.  A conversation as
-   defined here consists of all messages that are necessary to complete
-   the authentication between the client and the client's AS.  In the
-   Ticket Exchange Service (TGS) exchange, a conversation consists of
-   the request message and the reply message.  The term conversation is
-   defined here for both AS and TGS for convenience of discussion.  See
-   Section 6.3 for specific rules on the extent of a conversation in the
-   AS-REQ case.  Prior to this framework, implementations needed to use
-   implementation-specific heuristics to determine the extent of a
-   conversation.
-
-   If the KDC reply in an AS exchange is verified, the KDC is
-   authenticated by the client.  In this document, verification of the
-   KDC reply is used as a synonym of authentication of the KDC.
-
-
-3.  Model for Pre-Authentication
-
-   When a Kerberos client wishes to obtain a ticket using the
-   authentication server, it sends an initial Authentication Service
-   (AS) request.  If pre-authentication is required but not being used,
-   then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error.
-   Alternatively, if the client knows what pre-authentication to use, it
-   MAY optimize away a round-trip and send an initial request with
-   padata included in the initial request.  If the client includes the
-
-
-
-Hartman & Zhu           Expires February 13, 2010               [Page 6]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   padata computed using the wrong pre-authentication mechanism or
-   incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no
-   indication of what padata should have been included.  In that case,
-   the client MUST retry with no padata and examine the error data of
-   the KDC_ERR_PREAUTH_REQUIRED error.  If the KDC includes pre-
-   authentication information in the accompanying error data of
-   KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data, and
-   then retry.
-
-   The conventional KDC maintains no state between two requests;
-   subsequent requests may even be processed by a different KDC.  On the
-   other hand, the client treats a series of exchanges with KDCs as a
-   single conversation.  Each exchange accumulates state and hopefully
-   brings the client closer to a successful authentication.
-
-   These models for state management are in apparent conflict.  For many
-   of the simpler pre-authentication scenarios, the client uses one
-   round trip to find out what mechanisms the KDC supports.  Then the
-   next request contains sufficient pre-authentication for the KDC to be
-   able to return a successful reply.  For these simple scenarios, the
-   client only sends one request with pre-authentication data and so the
-   conversation is trivial.  For more complex conversations, the KDC
-   needs to provide the client with a cookie to include in future
-   requests to capture the current state of the authentication session.
-   Handling of multiple round-trip mechanisms is discussed in
-   Section 6.3.
-
-   This framework specifies the behavior of Kerberos pre-authentication
-   mechanisms used to identify users or to modify the reply key used to
-   encrypt the KDC reply.  The PA-DATA typed hole may be used to carry
-   extensions to Kerberos that have nothing to do with proving the
-   identity of the user or establishing a reply key.  Such extensions
-   are outside the scope of this framework.  However mechanisms that do
-   accomplish these goals should follow this framework.
-
-   This framework specifies the minimum state that a Kerberos
-   implementation needs to maintain while handling a request in order to
-   process pre-authentication.  It also specifies how Kerberos
-   implementations process the padata at each step of the AS request
-   process.
-
-3.1.  Information Managed by the Pre-authentication Model
-
-   The following information is maintained by the client and KDC as each
-   request is being processed:
-
-
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010               [Page 7]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   o  The reply key used to encrypt the KDC reply
-
-   o  How strongly the identity of the client has been authenticated
-
-   o  Whether the reply key has been used in this conversation
-
-   o  Whether the reply key has been replaced in this conversation
-
-   o  Whether the origin of the KDC reply can be verified by the client
-      (i.e. whether the KDC is authenticated to the client)
-
-
-   Conceptually, the reply key is initially the long-term key of the
-   principal.  However, principals can have multiple long-term keys
-   because of support for multiple encryption types, salts and
-   string2key parameters.  As described in Section 5.2.7.5 of the
-   Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify
-   the client what types of keys are available.  Thus in full
-   generality, the reply key in the pre-authentication model is actually
-   a set of keys.  At the beginning of a request, it is initialized to
-   the set of long-term keys advertised in the PA-ETYPE-INFO2 element on
-   the KDC.  If multiple reply keys are available, the client chooses
-   which one to use.  Thus the client does not need to treat the reply
-   key as a set.  At the beginning of a request, the client picks a key
-   to use.
-
-   KDC implementations MAY choose to offer only one key in the PA-ETYPE-
-   INFO2 element.  Since the KDC already knows the client's list of
-   supported enctypes from the request, no interoperability problems are
-   created by choosing a single possible reply key.  This way, the KDC
-   implementation avoids the complexity of treating the reply key as a
-   set.
-
-   When the padata in the request is verified by the KDC, then the
-   client is known to have that key, therefore the KDC SHOULD pick the
-   same key as the reply key.
-
-   At the beginning of handling a message on both the client and the
-   KDC, the client's identity is not authenticated.  A mechanism may
-   indicate that it has successfully authenticated the client's
-   identity.  This information is useful to keep track of on the client
-   in order to know what pre-authentication mechanisms should be used.
-   The KDC needs to keep track of whether the client is authenticated
-   because the primary purpose of pre-authentication is to authenticate
-   the client identity before issuing a ticket.  The handling of
-   authentication strength using various authentication mechanisms is
-   discussed in Section 6.6.
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010               [Page 8]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   Initially the reply key has not been used.  A pre-authentication
-   mechanism that uses the reply key to encrypt or checksum some data in
-   the generation of new keys MUST indicate that the reply key is used.
-   This state is maintained by the client and the KDC to enforce the
-   security requirement stated in Section 4.3 that the reply key SHOULD
-   NOT be replaced after it is used.
-
-   Initially the reply key has not been replaced.  If a mechanism
-   implements the Replace Reply Key facility discussed in Section 4.3,
-   then the state MUST be updated to indicate that the reply key has
-   been replaced.  Once the reply key has been replaced, knowledge of
-   the reply key is insufficient to authenticate the client.  The reply
-   key is marked replaced in exactly the same situations as the KDC
-   reply is marked as not being verified to the client principal.
-   However, while mechanisms can verify the KDC reply to the client,
-   once the reply key is replaced, then the reply key remains replaced
-   for the remainder of the conversation.
-
-   Without pre-authentication, the client knows that the KDC reply is
-   authentic and has not been modified because it is encrypted in a
-   long-term key of the client.  Only the KDC and the client know that
-   key.  So at the start of a conversation, the KDC reply is presumed to
-   be verified using the client's long-term key.  It should be noted
-   that in this document, verifying the KDC reply means authenticating
-   the KDC, and these phrases are used interchangeably.  Any pre-
-   authentication mechanism that sets a new reply key not based on the
-   principal's long-term secret MUST either verify the KDC reply some
-   other way or indicate that the reply is not verified.  If a mechanism
-   indicates that the reply is not verified then the client
-   implementation MUST return an error unless a subsequent mechanism
-   verifies the reply.  The KDC needs to track this state so it can
-   avoid generating a reply that is not verified.
-
-   In this specification, KDC verification/authentication refers to the
-   level of authentication of the KDC to the client provided by RFC
-   4120.  There is a stronger form of KDC verification that, while
-   sometimes important in Kerberos deployments is not addressed in this
-   specification: the typical Kerberos request does not provide a way
-   for the client machine to know that it is talking to the correct KDC.
-   Someone who can inject packets into the network between the client
-   machine and the KDC and who knows the password that the user will
-   give to the client machine can generate a KDC reply that will decrypt
-   properly.  So, if the client machine needs to authenticate that the
-   user is in fact the named principal, then the client machine needs to
-   do a TGS request for itself as a service.  Some pre-authentication
-   mechanisms may provide a way for the client machine to authenticate
-   the KDC.  Examples of this include signing the reply that can be
-   verified using a well-known public key or providing a ticket for the
-
-
-
-Hartman & Zhu           Expires February 13, 2010               [Page 9]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   client machine as a service.
-
-3.2.  Initial Pre-authentication Required Error
-
-   Typically a client starts a conversation by sending an initial
-   request with no pre-authentication.  If the KDC requires pre-
-   authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message.
-   After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code,
-   the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED
-   (defined in Section 6.3) for pre-authentication configurations that
-   use multi-round-trip mechanisms; see Section 3.4 for details of that
-   case.
-
-   The KDC needs to choose which mechanisms to offer the client.  The
-   client needs to be able to choose what mechanisms to use from the
-   first message.  For example consider the KDC that will accept
-   mechanism A followed by mechanism B or alternatively the single
-   mechanism C. A client that supports A and C needs to know that it
-   should not bother trying A.
-
-   Mechanisms can either be sufficient on their own or can be part of an
-   authentication set--a group of mechanisms that all need to
-   successfully complete in order to authenticate a client.  Some
-   mechanisms may only be useful in authentication sets; others may be
-   useful alone or in authentication sets.  For the second group of
-   mechanisms, KDC policy dictates whether the mechanism will be part of
-   an authentication set, offered alone, or both.  For each mechanism
-   that is offered alone (even if it is also offered in an
-   authentication set), the KDC includes the pre-authentication type ID
-   of the mechanism in the padata sequence returned in the
-   KDC_ERR_PREAUTH_REQUIRED error.  Mechanisms that are only offered as
-   part of an authentication set are not directly represented in the
-   padata sequence returned in the KDC_ERR_PREAUTH_REQUIRED error,
-   although they are represented in the PA-AUTHENTICATION-SET sequence.
-
-   The KDC SHOULD NOT send data that is encrypted in the long-term
-   password-based key of the principal.  Doing so has the same security
-   exposures as the Kerberos protocol without pre-authentication.  There
-   are few situations where the KDC needs to expose cipher text
-   encrypted in a weak key before the client has proven knowledge of
-   that key, and pre-authentication is desirable.
-
-3.3.  Client to KDC
-
-   This description assumes that a client has already received a
-   KDC_ERR_PREAUTH_REQUIRED from the KDC.  If the client performs
-   optimistic pre-authentication then the client needs to guess values
-   for the information it would normally receive from that error
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 10]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   response or use cached information obtained in prior interactions
-   with the KDC.
-
-   The client starts by initializing the pre-authentication state as
-   specified.  It then processes the padata in the
-   KDC_ERR_PREAUTH_REQUIRED.
-
-   When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the
-   client MAY ignore any padata it chooses unless doing so violates a
-   specification to which the client conforms.  Clients conforming to
-   this specification MUST NOT ignore the padata defined in Section 6.3.
-   Clients SHOULD process padata unrelated to this framework or other
-   means of authenticating the user.  Clients SHOULD choose one
-   authentication set or mechanism that could lead to authenticating the
-   user and ignore the rest.  Since the list of mechanisms offered by
-   the KDC is in the decreasing preference order, clients typically
-   choose the first mechanism or authentication set that the client can
-   usefully perform.  If a client chooses to ignore a padata it MUST NOT
-   process the padata, allow the padata to affect the pre-authentication
-   state, nor respond to the padata.
-
-   For each padata the client chooses to process, the client processes
-   the padata and modifies the pre-authentication state as required by
-   that mechanism.  Padata are processed in the order received from the
-   KDC.
-
-   After processing the padata in the KDC error, the client generates a
-   new request.  It processes the pre-authentication mechanisms in the
-   order in which they will appear in the next request, updating the
-   state as appropriate.  The request is sent when it is complete.
-
-3.4.  KDC to Client
-
-   When a KDC receives an AS request from a client, it needs to
-   determine whether it will respond with an error or an AS reply.
-   There are many causes for an error to be generated that have nothing
-   to do with pre-authentication; they are discussed in the core
-   Kerberos specification.
-
-   From the standpoint of evaluating the pre-authentication, the KDC
-   first starts by initializing the pre-authentication state.  If a PA-
-   FX-COOKIE pre-authentication data item is present, it is processed
-   first; see Section 6.3 for a definition.  It then processes the
-   padata in the request.  As mentioned in Section 3.3, the KDC MAY
-   ignore padata that is inappropriate for the configuration and MUST
-   ignore padata of an unknown type.  The KDC MUST NOT ignore padata of
-   types used in previous messages.  For example, if a KDC issues a
-   KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 11]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   KDC cannot ignore padata of type x received in an AS-REQ message from
-   the client.
-
-   At this point the KDC decides whether it will issue an error or a
-   reply.  Typically a KDC will issue a reply if the client's identity
-   has been authenticated to a sufficient degree.
-
-   In the case of a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error, the KDC
-   first starts by initializing the pre-authentication state.  Then it
-   processes any padata in the client's request in the order provided by
-   the client.  Mechanisms that are not understood by the KDC are
-   ignored.  Next, it generates padata for the error response, modifying
-   the pre-authentication state appropriately as each mechanism is
-   processed.  The KDC chooses the order in which it will generate
-   padata (and thus the order of padata in the response), but it needs
-   to modify the pre-authentication state consistently with the choice
-   of order.  For example, if some mechanism establishes an
-   authenticated client identity, then the subsequent mechanisms in the
-   generated response receive this state as input.  After the padata is
-   generated, the error response is sent.  Typically the errors with the
-   code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED in a conversation will
-   include KDC state as discussed in Section 6.3.
-
-   To generate a final reply, the KDC generates the padata modifying the
-   pre-authentication state as necessary.  Then it generates the final
-   response, encrypting it in the current pre-authentication reply key.
-
-
-4.  Pre-Authentication Facilities
-
-   Pre-Authentication mechanisms can be thought of as providing various
-   conceptual facilities.  This serves two useful purposes.  First,
-   mechanism authors can choose only to solve one specific small
-   problem.  It is often useful for a mechanism designed to offer key
-   management not to directly provide client authentication but instead
-   to allow one or more other mechanisms to handle this need.  Secondly,
-   thinking about the abstract services that a mechanism provides yields
-   a minimum set of security requirements that all mechanisms providing
-   that facility must meet.  These security requirements are not
-   complete; mechanisms will have additional security requirements based
-   on the specific protocol they employ.
-
-   A mechanism is not constrained to only offering one of these
-   facilities.  While such mechanisms can be designed and are sometimes
-   useful, many pre-authentication mechanisms implement several
-   facilities.  By combining multiple facilities in a single mechanism,
-   it is often easier to construct a secure, simple solution than by
-   solving the problem in full generality.  Even when mechanisms provide
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 12]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   multiple facilities, they need to meet the security requirements for
-   all the facilities they provide.  If the FAST factor approach is
-   used, it is likely that one or a small number of facilities can be
-   provided by a single mechanism without complicating the security
-   analysis.
-
-   According to Kerberos extensibility rules (Section 1.5 of the
-   Kerberos specification [RFC4120]), an extension MUST NOT change the
-   semantics of a message unless a recipient is known to understand that
-   extension.  Because a client does not know that the KDC supports a
-   particular pre-authentication mechanism when it sends an initial
-   request, a pre-authentication mechanism MUST NOT change the semantics
-   of the request in a way that will break a KDC that does not
-   understand that mechanism.  Similarly, KDCs MUST NOT send messages to
-   clients that affect the core semantics unless the client has
-   indicated support for the message.
-
-   The only state in this model that would break the interpretation of a
-   message is changing the expected reply key.  If one mechanism changed
-   the reply key and a later mechanism used that reply key, then a KDC
-   that interpreted the second mechanism but not the first would fail to
-   interpret the request correctly.  In order to avoid this problem,
-   extensions that change core semantics are typically divided into two
-   parts.  The first part proposes a change to the core semantic--for
-   example proposes a new reply key.  The second part acknowledges that
-   the extension is understood and that the change takes effect.
-   Section 4.2 discusses how to design mechanisms that modify the reply
-   key to be split into a proposal and acceptance without requiring
-   additional round trips to use the new reply key in subsequent pre-
-   authentication.  Other changes in the state described in Section 3.1
-   can safely be ignored by a KDC that does not understand a mechanism.
-   Mechanisms that modify the behavior of the request outside the scope
-   of this framework need to carefully consider the Kerberos
-   extensibility rules to avoid similar problems.
-
-4.1.  Client-authentication Facility
-
-   The client authentication facility proves the identity of a user to
-   the KDC before a ticket is issued.  Examples of mechanisms
-   implementing this facility include the encrypted timestamp facility
-   defined in Section 5.2.7.2 of the Kerberos specification [RFC4120].
-   Mechanisms that provide this facility are expected to mark the client
-   as authenticated.
-
-   Mechanisms implementing this facility SHOULD require the client to
-   prove knowledge of the reply key before transmitting a successful KDC
-   reply.  Otherwise, an attacker can intercept the pre-authentication
-   exchange and get a reply to attack.  One way of proving the client
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 13]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   knows the reply key is to implement the Replace Reply Key facility
-   along with this facility.  The PKINIT mechanism [RFC4556] implements
-   Client Authentication alongside Replace Reply Key.
-
-   If the reply key has been replaced, then mechanisms such as
-   encrypted-timestamp that rely on knowledge of the reply key to
-   authenticate the client MUST NOT be used.
-
-4.2.  Strengthening-reply-key Facility
-
-   Particularly when dealing with keys based on passwords, it is
-   desirable to increase the strength of the key by adding additional
-   secrets to it.  Examples of sources of additional secrets include the
-   results of a Diffie-Hellman key exchange or key bits from the output
-   of a smart card [KRB-WG.SAM].  Typically these additional secrets can
-   be first combined with the existing reply key and then converted to a
-   protocol key using tools defined in Section 6.1.
-
-   Typically a mechanism implementing this facility will know that the
-   other side of the exchange supports the facility before the reply key
-   is changed.  For example, a mechanism might need to learn the
-   certificate for a KDC before encrypting a new key in the public key
-   belonging to that certificate.  However, if a mechanism implementing
-   this facility wishes to modify the reply key before knowing that the
-   other party in the exchange supports the mechanism, it proposes
-   modifying the reply key.  The other party then includes a message
-   indicating that the proposal is accepted if it is understood and
-   meets policy.  In many cases it is desirable to use the new reply key
-   for client authentication and for other facilities.  Waiting for the
-   other party to accept the proposal and actually modify the reply key
-   state would add an additional round trip to the exchange.  Instead,
-   mechanism designers are encouraged to include a typed hole for
-   additional padata in the message that proposes the reply key change.
-   The padata included in the typed hole are generated assuming the new
-   reply key.  If the other party accepts the proposal, then these
-   padata are considered as an inner level.  As with the outer level,
-   one authentication set or mechanism is typically chosen for client
-   authentication, along with auxiliary mechanisms such as KDC cookies,
-   and other mechanisms are ignored.  When mechanisms include such a
-   container, the hint provided for use in authentication sets (as
-   defined in Section 6.4) MUST contain a sequence of inner mechanisms
-   along with hints for those mechanisms.  The party generating the
-   proposal can determine whether the padata were processed based on
-   whether the proposal for the reply key is accepted.
-
-   The specific formats of the proposal message, including where padata
-   are included is a matter for the mechanism specification.  Similarly,
-   the format of the message accepting the proposal is mechanism-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 14]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   specific.
-
-   Mechanisms implementing this facility and including a typed hole for
-   additional padata MUST checksum that padata using a keyed checksum or
-   encrypt the padata.  This requirement protects against modification
-   of the contents of the typed hole.  By modifying these contents an
-   attacker might be able to choose which mechanism is used to
-   authenticate the client, or to convince a party to provide text
-   encrypted in a key that the attacker had manipulated.  It is
-   important that mechanisms strengthen the reply key enough that using
-   it to checksum padata is appropriate.
-
-4.3.  Replacing-reply-key Facility
-
-   The Replace Reply Key facility replaces the key in which a successful
-   AS reply will be encrypted.  This facility can only be used in cases
-   where knowledge of the reply key is not used to authenticate the
-   client.  The new reply key MUST be communicated to the client and the
-   KDC in a secure manner.  This facility MUST NOT be used if there can
-   be a man-in-the-middle between the client and the KDC.  Mechanisms
-   implementing this facility MUST mark the reply key as replaced in the
-   pre-authentication state.  Mechanisms implementing this facility MUST
-   either provide a mechanism to verify the KDC reply to the client or
-   mark the reply as unverified in the pre-authentication state.
-   Mechanisms implementing this facility SHOULD NOT be used if a
-   previous mechanism has used the reply key.
-
-   As with the strengthening-reply-key facility, Kerberos extensibility
-   rules require that the reply key not be changed unless both sides of
-   the exchange understand the extension.  In the case of this facility
-   it will likely be the case for both sides to know that the facility
-   is available by the time that the new key is available to be used.
-   However, mechanism designers can use a container for padata in a
-   proposal message as discussed in Section 4.2 if appropriate.
-
-4.4.  KDC-authentication Facility
-
-   This facility verifies that the reply comes from the expected KDC.
-   In traditional Kerberos, the KDC and the client share a key, so if
-   the KDC reply can be decrypted then the client knows that a trusted
-   KDC responded.  Note that the client machine cannot trust the client
-   unless the machine is presented with a service ticket for it
-   (typically the machine can retrieve this ticket by itself).  However,
-   if the reply key is replaced, some mechanism is required to verify
-   the KDC.  Pre-authentication mechanisms providing this facility allow
-   a client to determine that the expected KDC has responded even after
-   the reply key is replaced.  They mark the pre-authentication state as
-   having been verified.
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 15]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-5.  Requirements for Pre-Authentication Mechanisms
-
-   This section lists requirements for specifications of pre-
-   authentication mechanisms.
-
-   For each message in the pre-authentication mechanism, the
-   specification describes the pa-type value to be used and the contents
-   of the message.  The processing of the message by the sender and
-   recipient is also specified.  This specification needs to include all
-   modifications to the pre-authentication state.
-
-   Generally mechanisms have a message that can be sent in the error
-   data of the KDC_ERR_PREAUTH_REQUIRED error message or in an
-   authentication set.  If the client needs information such as trusted
-   certificate authorities in order to determine if it can use the
-   mechanism, then this information should be in that message.  In
-   addition, such mechanisms should also define a pa-hint to be included
-   in authentication sets.  Often, the same information included in the
-   padata-value is appropriate to include in the pa-hint (as defined in
-   Section 6.4).
-
-   In order to ease security analysis the mechanism specification should
-   describe what facilities from this document are offered by the
-   mechanism.  For each facility, the security consideration section of
-   the mechanism specification should show that the security
-   requirements of that facility are met.  This requirement is
-   applicable to any FAST factor that provides authentication
-   information.
-
-   Significant problems have resulted in the specification of Kerberos
-   protocols because much of the KDC exchange is not protected against
-   alteration.  The security considerations section should discuss
-   unauthenticated plaintext attacks.  It should either show that
-   plaintext is protected or discuss what harm an attacker could do by
-   modifying the plaintext.  It is generally acceptable for an attacker
-   to be able to cause the protocol negotiation to fail by modifying
-   plaintext.  More significant attacks should be evaluated carefully.
-
-   As discussed in Section 6.3, there is no guarantee that a client will
-   use the same KDCs for all messages in a conversation.  The mechanism
-   specification needs to show why the mechanism is secure in this
-   situation.  The hardest problem to deal with, especially for
-   challenge/response mechanisms is to make sure that the same response
-   cannot be replayed against two KDCs while allowing the client to talk
-   to any KDC.
-
-
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 16]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-6.  Tools for Use in Pre-Authentication Mechanisms
-
-   This section describes common tools needed by multiple pre-
-   authentication mechanisms.  By using these tools mechanism designers
-   can use a modular approach to specify mechanism details and ease
-   security analysis.
-
-6.1.  Combining Keys
-
-   Frequently a weak key needs to be combined with a stronger key before
-   use.  For example, passwords are typically limited in size and
-   insufficiently random, therefore it is desirable to increase the
-   strength of the keys based on passwords by adding additional secrets.
-   Additional source of secrecy may come from hardware tokens.
-
-   This section provides standard ways to combine two keys into one.
-
-   KRB-FX-CF1() is defined to combine two pass-phrases.
-
-       KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
-       KRB-FX-CF1(x, y) := x || y
-
-   Where || denotes concatenation.  The strength of the final key is
-   roughly the total strength of the individual keys being combined
-   assuming that the string_to_key() function [RFC3961] uses all its
-   input evenly.
-
-   An example usage of KRB-FX-CF1() is when a device provides random but
-   short passwords, the password is often combined with a personal
-   identification number (PIN).  The password and the PIN can be
-   combined using KRB-FX-CF1().
-
-   KRB-FX-CF2() combines two protocol keys based on the pseudo-random()
-   function defined in [RFC3961].
-
-   Given two input keys, K1 and K2, where K1 and K2 can be of two
-   different enctypes, the output key of KRB-FX-CF2(), K3, is derived as
-   follows:
-
-       KRB-FX-CF2(protocol key, protocol key, octet string,
-                 octet string)  ->  (protocol key)
-
-       PRF+(K1, pepper1) -> octet-string-1
-       PRF+(K2, pepper2) -> octet-string-2
-       KRB-FX-CF2(K1, K2, pepper1, pepper2) :=
-              random-to-key(octet-string-1 ^ octet-string-2)
-
-   Where ^ denotes the exclusive-OR operation.  PRF+() is defined as
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 17]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   follows:
-
-    PRF+(protocol key, octet string) -> (octet string)
-
-    PRF+(key, shared-info) := pseudo-random( key,  1 || shared-info ) ||
-                  pseudo-random( key, 2 || shared-info ) ||
-                  pseudo-random( key, 3 || shared-info ) || ...
-
-   Here the counter value 1, 2, 3 and so on are encoded as a one-octet
-   integer.  The pseudo-random() operation is specified by the enctype
-   of the protocol key.  PRF+() uses the counter to generate enough bits
-   as needed by the random-to-key() [RFC3961] function for the
-   encryption type specified for the resulting key; unneeded bits are
-   removed from the tail.  Unless otherwise specified, the resulting
-   enctype of KRB-FX-CF2 is the enctype of k1.
-
-   Mechanism designers MUST specify the values for the input parameter
-   pepper1 and pepper2 when combining two keys using KRB-FX-CF2().  The
-   pepper1 and pepper2 MUST be distinct so that if the two keys being
-   combined are the same, the resulting key is not a trivial key.
-
-6.2.  Protecting Requests/Responses
-
-   Mechanism designers SHOULD protect clear text portions of pre-
-   authentication data.  Various denial of service attacks and downgrade
-   attacks against Kerberos are possible unless plaintexts are somehow
-   protected against modification.  An early design goal of Kerberos
-   Version 5 [RFC4120] was to avoid encrypting more of the
-   authentication exchange that was required.  (Version 4 doubly-
-   encrypted the encrypted part of a ticket in a KDC reply, for
-   example.)  This minimization of encryption reduces the load on the
-   KDC and busy servers.  Also, during the initial design of Version 5,
-   the existence of legal restrictions on the export of cryptography
-   made it desirable to minimize of the number of uses of encryption in
-   the protocol.  Unfortunately, performing this minimization created
-   numerous instances of unauthenticated security-relevant plaintext
-   fields.
-
-   If there is more than one round trip for an authentication exchange,
-   mechanism designers need to allow either the client or the KDC to
-   provide a checksum of all the messages exchanged on the wire in the
-   conversation, and the checksum is then verified by the receiver.
-
-   New mechanisms MUST NOT be hard-wired to use a specific algorithm.
-
-   Primitives defined in [RFC3961] are RECOMMENDED for integrity
-   protection and confidentiality.  Mechanisms based on these primitives
-   are crypto-agile as the result of using [RFC3961] along with
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 18]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   [RFC4120].  The advantage afforded by crypto-agility is the ability
-   to incrementally deploy a fix specific to a particular algorithm thus
-   avoid a multi-year standardization and deployment cycle, when real
-   attacks do arise against that algorithm.
-
-   Note that data used by FAST factors (defined in Section 6.5) is
-   encrypted in a protected channel, thus they do not share the un-
-   authenticated-text issues with mechanisms designed as full-blown pre-
-   authentication mechanisms.
-
-6.3.  Managing States for the KDC
-
-   Kerberos KDCs are stateless in that there is no requirement that
-   clients will choose the same KDC for the second request in a
-   conversation.  Proxies or other intermediate nodes may also influence
-   KDC selection.  So, each request from a client to a KDC must include
-   sufficient information that the KDC can regenerate any needed state.
-   This is accomplished by giving the client a potentially long opaque
-   cookie in responses to include in future requests in the same
-   conversation.  The KDC MAY respond that a conversation is too old and
-   needs to restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
-
-       KDC_ERR_PREAUTH_EXPIRED            90
-
-   When a client receives this error, the client SHOULD abort the
-   existing conversation, and restart a new one.
-
-   An example, where more than one message from the client is needed, is
-   when the client is authenticated based on a challenge-response
-   scheme.  In that case, the KDC needs to keep track of the challenge
-   issued for a client authentication request.
-
-   The PA-FX-COOKIE padata type is defined in this section to facilitate
-   state management in the AS exchange.  This padata is sent by the KDC
-   when the KDC requires state for a future transaction.  The client
-   includes this opaque token in the next message in the conversation.
-   The token may be relatively large; clients MUST be prepared for
-   tokens somewhat larger than the size of all messages in a
-   conversation.
-
-       PA-FX-COOKIE                       133
-           -- Stateless cookie that is not tied to a specific KDC.
-
-   The corresponding padata-value field [RFC4120] contains an opaque
-   token that will be echoed by the client in its response to an error
-   from the KDC.
-
-   The cookie token is generated by the KDC and transmitted in a PA-FX-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 19]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   COOKIE pre-authentication data item of a KRB-ERROR message.  The
-   client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data
-   element into the next message of the same conversation.  The content
-   of the cookie field is a local matter of the KDC.  As a result, it is
-   not generally possible to mix KDC implementations from different
-   vendors in the same realm.  However the KDC MUST construct the cookie
-   token in such a manner that a malicious client cannot subvert the
-   authentication process by manipulating the token.  The KDC
-   implementation needs to consider expiration of tokens, key rollover
-   and other security issues in token design.  The content of the cookie
-   field is likely specific to the pre-authentication mechanisms used to
-   authenticate the client.  If a client authentication response can be
-   replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an
-   expiration in the cookie is RECOMMENDED to prevent the response being
-   presented indefinitely.
-
-   If at least one more message for a mechanism or a mechanism set is
-   expected by the KDC, the KDC returns a
-   KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error with a PA-FX-COOKIE to
-   identify the conversation with the client according to Section 3.2.
-   The cookie is not expected to stay constant for a conversation: the
-   KDC is expected to generate a new cookie for each message.
-
-        KDC_ERR_MORE_PREAUTH_DATA_REQUIRED   91
-
-   A client MAY throw away the state associated with a conversation and
-   begin a new conversation by discarding its state and not including a
-   cookie in the first message of a conversation.  KDCs that comply with
-   this specification MUST include a cookie in a response when the
-   client can continue the conversation.  In particular, a KDC MUST
-   include a cookie in a KDC_ERR_PREAUTH_REQUIRED or
-   KDC_ERR_MORE_PREAUTH_DATA_REQUIRED.  KDCs SHOULD include a cookie in
-   errors containing additional information allowing a client to retry.
-   One reasonable strategy for meeting these requirements is to always
-   include a cookie in KDC errors.
-
-   A KDC MAY indicate that it is terminating a conversation by not
-   including a cookie in a response.  When FAST is used, clients can
-   assume that the absence of a cookie means that the KDC is ending the
-   conversation.  Clients also need to deal with KDCs prior to this
-   specification that do not include cookies; if cookies nor FAST are
-   used in a conversation, the absence of a cookie is not a strong
-   indication that the KDC is terminating the conversation.
-
-6.4.  Pre-authentication Set
-
-   If all mechanisms in a group need to successfully complete in order
-   to authenticate a client, the client and the KDC SHOULD use the PA-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 20]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   AUTHENTICATION-SET padata element.
-
-        PA-AUTHENTICATION-SET              134
-
-   A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER
-   encoding of the PA-AUTHENTICATION-SET structure:
-
-        PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-        PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-            pa-type      [0] Int32,
-                -- same as padata-type.
-            pa-hint      [1] OCTET STRING OPTIONAL,
-            pa-value     [2] OCTET STRING OPTIONAL,
-            ...
-        }
-
-   The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure
-   contains the corresponding value of padata-type in PA-DATA [RFC4120].
-   Associated with the pa-type is a pa-hint, which is an octet-string
-   specified by the pre-authentication mechanism.  This hint may provide
-   information for the client which helps it determine whether the
-   mechanism can be used.  For example a public-key mechanism might
-   include the certificate authorities it trusts in the hint info.  Most
-   mechanisms today do not specify hint info; if a mechanism does not
-   specify hint info the KDC MUST NOT send a hint for that mechanism.
-   To allow future revisions of mechanism specifications to add hint
-   info, clients MUST ignore hint info received for mechanisms that the
-   client believes do not support hint info.  The pa-value element of
-   the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the
-   first padata-value from the KDC to the client.  If the client chooses
-   this authentication set then the client MUST process this pa-value.
-   The pa-value element MUST be absent for all but the first entry in
-   the authentication set.  Clients MUST ignore pa-value for the second
-   and following entries in the authentication set.
-
-   If the client chooses an authentication set, then its first AS-REQ
-   message MUST contain a PA-AUTH-SET-SELECTED padata element.  This
-   element contains the encoding of the PA-AUTHENTICATION-SET sequence
-   received from the KDC corresponding to the authentication set that is
-   chosen.  The client MUST use the same octet values received from the
-   KDC; it cannot re-encode the sequence.  This allows KDCs to use bit-
-   wise comparison to identify the selected authentication set.  The PA-
-   AUTH-SET-SELECTED padata element MUST come before any padata elements
-   from the authentication set in the padata sequence in the AS-REQ
-   message.  The client MAY cache authentication sets from prior
-   messages and use them to construct an optimistic initial AS-REQ.  If
-   the KDC receives a PA-AUTH-SET-SELECTED padata element that does not
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 21]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   correspond to an authentication set that it would offer, then the KDC
-   returns the KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error.  The e-data
-   in this error contains a sequence of padata just as for the
-   KDC_ERR_PREAUTH_REQUIRED error.
-
-
-         PA-AUTH-SET-SELECTED                   135
-         KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
-
-   The PA-AUTHENTICATION-SET appears only in the first message from the
-   KDC to the client.  In particular, the client MAY fail if the
-   authentication mechanism sets change as the conversation progresses.
-   Clients MAY assume that the hints provided in the authentication set
-   contain enough information that the client knows what user interface
-   elements need to be displayed during the entire authentication
-   conversation.  Exceptional circumstances such as expired passwords or
-   expired accounts may require that additional user interface be
-   displayed.  Mechanism designers needs to carefully consider the
-   design of their hints so that the client has this information.  This
-   way, clients can construct necessary dialogue boxes or wizards based
-   on the authentication set and can present a coherent user interface.
-   Current standards for user interface do not provide an acceptable
-   experience when the client has to ask additional questions later in
-   the conversation.
-
-   When indicating which sets of pre-authentication mechanisms are
-   supported, the KDC includes a PA-AUTHENTICATION-SET padata element
-   for each pre-authentication mechanism set.
-
-   The client sends the padata-value for the first mechanism it picks in
-   the pre-authentication set, when the first mechanism completes, the
-   client and the KDC will proceed with the second mechanism, and so on
-   until all mechanisms complete successfully.  The PA-FX-COOKIE as
-   defined in Section 6.3 MUST be sent by the KDC.  One reason for this
-   requirement is so that the conversation can continue if the
-   conversation involves multiple KDCs.  KDCs MUST support clients that
-   do not include a cookie because they optimistically choose an
-   authentication set, although they MAY always return
-   KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in that
-   message.  Clients that support PA-AUTHENTICATION-SET MUST support PA-
-   FX-COOKIE.
-
-   Before the authentication succeeds and a ticket is returned, the
-   message that the client sends is an AS_REQ and the message that the
-   KDC sends is a KRB-ERROR message.  The error code in the KRB-ERROR
-   message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_REQUIRED as defined
-   in Section 6.3 and the accompanying e-data contains the DER encoding
-   of ASN.1 type METHOD-DATA.  The KDC includes the padata elements in
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 22]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   the METHOD-DATA.  If there is no padata, the e-data field is absent
-   in the KRB-ERROR message.
-
-   If the client sends the last message for a given mechanism, then the
-   KDC sends the first message for the next mechanism.  If the next
-   mechanism does not start with a KDC-side challenge, then the KDC
-   includes a padata item with the appropriate pa-type and an empty pa-
-   data.
-
-   If the KDC sends the last message for a particular mechanism, the KDC
-   also includes the first padata for the next mechanism.
-
-6.5.  Definition of Kerberos FAST Padata
-
-   As described in [RFC4120], Kerberos is vulnerable to offline
-   dictionary attacks.  An attacker can request an AS-REP and try
-   various passwords to see if they can decrypt the resulting ticket.
-   RFC 4120 provides the encrypted timestamp pre-authentication method
-   that ameliorates the situation somewhat by requiring that an attacker
-   observe a successful authentication.  However stronger security is
-   desired in many environments.  The Kerberos FAST pre-authentication
-   padata defined in this section provides a tool to significantly
-   reduce vulnerability to offline dictionary attack.  When combined
-   with encrypted challenge, FAST requires an attacker to mount a
-   successful man-in-the-middle attack to observe ciphertext.  When
-   combined with host keys, FAST can even protect against active
-   attacks.  FAST also provides solutions to common problems for pre-
-   authentication mechanisms such as binding of the request and the
-   reply, freshness guarantee of the authentication.  FAST itself,
-   however, does not authenticate the client or the KDC, instead, it
-   provides a typed hole to allow pre-authentication data be tunneled.
-   A pre-authentication data element used within FAST is called a FAST
-   factor.  A FAST factor captures the minimal work required for
-   extending Kerberos to support a new pre-authentication scheme.
-
-   A FAST factor MUST NOT be used outside of FAST unless its
-   specification explicitly allows so.  The typed holes in FAST messages
-   can also be used as generic holes for other padata that are not
-   intended to prove the client's identity, or establish the reply key.
-
-   New pre-authentication mechanisms SHOULD be designed as FAST factors,
-   instead of full-blown pre-authentication mechanisms.
-
-   FAST factors that are pre-authentication mechanisms MUST meet the
-   requirements in Section 5.
-
-   FAST employs an armoring scheme.  The armor can be a Ticket Granting
-   Ticket (TGT) obtained by the client's machine using the host keys to
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 23]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   pre-authenticate with the KDC, or an anonymous TGT obtained based on
-   anonymous PKINIT [KRB-ANON] [RFC4556].
-
-   The rest of this section describes the types of armors and the syntax
-   of the messages used by FAST.  Conforming implementations MUST
-   support Kerberos FAST padata.
-
-   Any FAST armor scheme MUST provide a fresh armor key for each
-   conversation.  Clients and KDCs can assume that if a message is
-   encrypted and integrity protected with a given armor key then it is
-   part of the conversation using that armor key.
-
-   All KDCs in a realm MUST support FAST if FAST is offered by any KDC
-   as a pre-authentication mechanism.
-
-6.5.1.  FAST Armors
-
-   An armor key is used to encrypt pre-authentication data in the FAST
-   request and the response.  The KrbFastArmor structure is defined to
-   identify the armor key.  This structure contains the following two
-   fields: the armor-type identifies the type of armors, and the armor-
-   value is an OCTET STRING that contains the description of the armor
-   scheme and the armor key.
-
-        KrbFastArmor ::= SEQUENCE {
-            armor-type   [0] Int32,
-                -- Type of the armor.
-            armor-value  [1] OCTET STRING,
-                -- Value of the armor.
-            ...
-        }
-
-   The value of the armor key is a matter of the armor type
-   specification.  Only one armor type is defined in this document.
-
-        FX_FAST_ARMOR_AP_REQUEST           1
-
-   The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
-
-   Conforming implementations MUST implement the
-   FX_FAST_ARMOR_AP_REQUEST armor type.  If a FAST KDC receives an
-   unknown armor type it MUST respond with KDC_ERR_PREAUTH_FAILED.
-
-   An armor type may be appropriate for use in armoring AS requests,
-   armoring TGS requests or both.  TGS armor types MUST authenticate the
-   client to to the KDC, typically by binding the TGT subsession key to
-   the armor key.  As discussed below, it is desirable for AS armor
-   types to authenticate the KDC to the client, but this is not
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 24]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   required.
-
-   FAST implementations MUST maintain state about whether the armor
-   mechanism authenticates the KDC.  If it does not, then a fast factor
-   that authenticates the KDC MUST be used if the reply key is replaced.
-
-6.5.1.1.  Ticket-based Armors
-
-   This is a ticket-based armoring scheme.  The armor-type is
-   FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER
-   encoded AP-REQ.  The ticket in the AP-REQ is called an armor ticket
-   or an armor TGT.  The subkey field in the AP-REQ MUST be present.
-   The armor key is defined by the following function:
-
-       armor_key = KRB-FX-CF2( subkey, ticket_session_key,
-                   "subkeyarmor", "ticketarmor" )
-
-   The `ticket_session_key' is the session key from the ticket in the
-   ap-req.  The `subkey' is the ap-req subkey.  This construction
-   guarantees that both the KDC (through the session key) and the client
-   (through the subkey) contribute to the armor key.
-
-   The server name field of the armor ticket MUST identify the TGS of
-   the target realm.  Here are three common ways in the decreasing
-   preference order how an armor TGT SHOULD be obtained:
-
-   1.  If the client is authenticating from a host machine whose
-       Kerberos realm has an authentication path to the client's realm,
-       the host machine obtains a TGT by using the host keys.  If the
-       client's realm is different than the realm of the local host, the
-       machine then obtains a cross-realm TGT to the client's realm as
-       the armor ticket.  Otherwise, the host's primary TGT is the armor
-       ticket.
-
-   2.  If the client's host machine cannot obtain a host ticket strictly
-       based on RFC4120, but the KDC has an asymmetric signing key whose
-       binding with the expected KDC can be verified by the client, the
-       client can use anonymous PKINIT [KRB-ANON] [RFC4556] to
-       authenticate the KDC and obtain an anonymous TGT as the armor
-       ticket.  The armor ticket can also be a cross-realm TGT obtained
-       based on the initial primary TGT obtained using anonymous PKINIT
-       with KDC authentication.
-
-   3.  Otherwise, the client uses anonymous PKINIT to get an anonymous
-       TGT without KDC authentication and that TGT is the armor ticket.
-       Note that this mode of operation is vulnerable to man-in-the-
-       middle attacks at the time of obtaining the initial anonymous
-       armor TGT.
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 25]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   If anonymous PKINIT is used to obtain the armor ticket, the KDC
-   cannot know whether its signing key can be verified by the client,
-   hence the KDC MUST be marked as unverified from the KDC's point of
-   view while the client could be able to authenticate the KDC by
-   verifying the KDC's signing key is bound with the expected KDC.  The
-   client needs to carefully consider the risk and benefit tradeoffs
-   associated with active attacks before exposing cipher text encrypted
-   using the user's long-term secrets when the armor does not
-   authenticate the KDC.
-
-   The TGS MUST reject a request if there is an AD-fx-fast-armor (TBD)
-   element in the authenticator of the pa-tgs-req padata or if the
-   ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-
-   armor authorization data element.  These tickets and authenticators
-   MAY be used as FAST armor tickets but not to obtain a ticket via the
-   TGS.  This authorization data is used in a system where the
-   encryption of the user's pre-authentication data is performed in an
-   unprivileged user process.  A privileged process can provide to the
-   user process a host ticket, an authenticator for use with that
-   ticket, and the sub session key contained in the authenticator.  In
-   order for the host process to ensure that the host ticket is not
-   accidentally or intentionally misused, (i.e. the user process might
-   use the host ticket to authenticate as the host), it MUST include a
-   critical authorization data element of the type AD-fx-fast-armor when
-   providing the authenticator or in the enc-authorization-data field of
-   the TGS request used to obtain the TGT.  The corresponding ad-data
-   field of the AD-fx-fast-armor element is empty.
-
-   Only implicit armors are allowed in the TGS at this time.
-
-6.5.2.  FAST Request
-
-   A padata type PA-FX-FAST is defined for the Kerberos FAST pre-
-   authentication padata.  The corresponding padata-value field
-   [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-
-   REQUEST.  As with all pre-authentication types, the KDC SHOULD
-   advertise PA-FX-FAST in a PREAUTH_REQUIRED error.  KDCs MUST send the
-   advertisement of pa-fx-fast with an empty pa-value.  Clients MUST
-   ignore the pa-value of PA-FX-FAST in an initial PREAUTH_REQUIRED
-   error.  FAST is not expected to be used in an authentication set:
-   clients will typically use FAST padata if available and this decision
-   should not depend on what other pre-authentication methods are
-   available.  As such, no pa-hint is defined for FAST at this time.
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 26]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-       PA-FX-FAST                         136
-           -- Padata type for Kerberos FAST
-
-       PA-FX-FAST-REQUEST ::= CHOICE {
-           armored-data [0] KrbFastArmoredReq,
-           ...
-       }
-
-       KrbFastArmoredReq ::= SEQUENCE {
-           armor        [0] KrbFastArmor OPTIONAL,
-               -- Contains the armor that identifies the armor key.
-               -- MUST be present in AS-REQ.
-           req-checksum [1] Checksum,
-               -- For AS, contains the checksum performed over the type
-               -- KDC-REQ-BODY for the req-body field of the KDC-REQ
-               -- structure;
-               -- For TGS, contains the checksum performed over the type
-               -- AP-REQ in the PA-TGS-REQ padata.
-               -- The checksum key is the armor key, the checksum
-               -- type is the required checksum type for the enctype of
-               -- the armor key, and the key usage number is
-               -- KEY_USAGE_FAST_REQ_CHKSUM.
-           enc-fast-req [2] EncryptedData, -- KrbFastReq --
-               -- The encryption key is the armor key, and the key usage
-               -- number is KEY_USAGE_FAST_ENC.
-           ...
-       }
-
-       KEY_USAGE_FAST_REQ_CHKSUM          50
-       KEY_USAGE_FAST_ENC                 51
-
-   The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type.
-   The KrbFastArmoredReq encapsulates the encrypted padata.
-
-   The enc-fast-req field contains an encrypted KrbFastReq structure.
-   The armor key is used to encrypt the KrbFastReq structure, and the
-   key usage number for that encryption is KEY_USAGE_FAST_ENC.
-
-   The armor key is selected as follows:
-
-   o  In an AS request, the armor field in the KrbFastArmoredReq
-      structure MUST be present and the armor key is identified
-      according to the specification of the armor type.
-
-   o  There are two possibilities for armor for a TGS request.  If the
-      ticket presented in the PA-TGS-REQ authenticator is a TGT, then
-      the client SHOULD NOT include the armor field in the Krbfastreq
-      and a subkey MUST be included in the PA-TGS-REQ authenticator.  In
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 27]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-      this case, the armor key is the same armor key that would be
-      computed if the TGS-REQ authenticator was used in a
-      FX_FAST_ARMOR_AP_REQUEST armor.  Clients MAY present a non-TGT in
-      the PA-TGS-REQ authenticator and omit the armor field, in which
-      case the armor key is the same that would be computed if the
-      authenticator were used in a FX_FAST_ARMOR_AP_REQUEST armor.  This
-      is the only case where a ticket other than a TGT can be used to
-      establish an armor key; even though the armor key is computed the
-      same as a FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used as an
-      armor ticket in FX_FAST_ARMOR_AP_REQUEST.  Alternatively, a client
-      MAY use an armor type defined in the future for use with the TGS
-      request.
-
-   The req-checksum field contains a checksum computed differently for
-   AS and TGS.  For an AS-REQ, it is performed over the type KDC-REQ-
-   BODY for the req-body field of the KDC-REQ structure of the
-   containing message; for an TGS-REQ, it is performed over the type AP-
-   REQ in the PA-TGS-REQ padata of the TGS request.  The checksum key is
-   the armor key, and the checksum type is the required checksum type
-   for the enctype of the armor key per [RFC3961].  This checksum MUST
-   be a keyed checksume and it is included in order to bind the FAST
-   padata to the outer request.  A KDC that implements FAST will ignore
-   the outer request, but including a checksum is relatively cheap and
-   may prevent confusing behavior.
-
-   The KrbFastReq structure contains the following information:
-
-        KrbFastReq ::= SEQUENCE {
-            fast-options [0] FastOptions,
-                -- Additional options.
-            padata       [1] SEQUENCE OF PA-DATA,
-                -- padata typed holes.
-            req-body     [2] KDC-REQ-BODY,
-                -- Contains the KDC request body as defined in Section
-                -- 5.4.1 of [RFC4120].
-                -- This req-body field is preferred over the outer field
-                -- in the KDC request.
-             ...
-        }
-
-   The fast-options field indicates various options that are to modify
-   the behavior of the KDC.  The following options are defined:
-
-        FastOptions ::= KerberosFlags
-            -- reserved(0),
-            -- hide-client-names(1),
-            -- kdc-follow-referrals(16)
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 28]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-     Bits    Name                    Description
-    -----------------------------------------------------------------
-     0     RESERVED              Reserved for future expansion of this
-                                 field.
-     1     hide-client-names     Requesting the KDC to hide client
-                                 names in the KDC response, as
-                                 described next in this section.
-     16    kdc-follow-referrals  Requesting the KDC to follow referrals.
-
-   Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are
-   critical options.  If the KDC does not support a critical option, it
-   MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and
-   there is no accompanying e-data defined in this document for this
-   error code.  Bit 16 and onward (with bit 16 included) are non-
-   critical options.  KDCs conforming to this specification ignore
-   unknown non-critical options.
-
-        KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
-
-   The hide-client-names Option
-
-      The Kerberos response defined in [RFC4120] contains the client
-      identity in clear text, This makes traffic analysis
-      straightforward.  The hide-client-names option is designed to
-      complicate traffic analysis.  If the hide-client-names option is
-      set, the KDC implementing PA-FX-FAST MUST identify the client as
-      the anonymous principal [KRB-ANON] in the KDC reply and the error
-      response.  Hence this option is set by the client if it wishes to
-      conceal the client identity in the KDC response.  A conforming KDC
-      ignores the client principal name in the outer KDC-REQ-BODY field,
-      and identifies the client using the cname and crealm fields in the
-      req-body field of the KrbFastReq structure.
-
-   The kdc-follow-referrals Option
-
-      The Kerberos client described in [RFC4120] has to request referral
-      TGTs along the authentication path in order to get a service
-      ticket for the target service.  The Kerberos client described in
-      the [REFERRALS] needs to contact the AS specified in the error
-      response in order to complete client referrals.  The kdc-follow-
-      referrals option is designed to minimize the number of messages
-      that need to be processed by the client.  This option is useful
-      when, for example, the client may contact the KDC via a satellite
-      link that has high network latency, or the client has limited
-      computational capabilities.  If the kdc-follow-referrals option is
-      set, the KDC MAY act as the client to follow TGS referrals
-      [REFERRALS], and return the service ticket to the named server
-      principal in the client request using the reply key expected by
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 29]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-      the client.  That is, rather than returning a referral, the KDC
-      follows that referral by contacting a remote KDC and processing
-      the referral.  The kdc-referrals option can be implemented when
-      the KDC knows the reply key.  The KDC can ignore kdc-referrals
-      option when it does not understand it or it does not allow this
-      option based on local policy.  The client SHOULD be capable of
-      processing the KDC responses when this option is not honored by
-      the KDC.  Clients SHOULD use TCP to contact a KDC if this option
-      is going to be used to avoid problems when the client's UDP
-      retransmit algorithm has timeouts insufficient to allow the KDC to
-      interact with remote KDCs.
-
-   The padata field contains a list of PA-DATA structures as described
-   in Section 5.2.7 of [RFC4120].  These PA-DATA structures can contain
-   FAST factors.  They can also be used as generic typed-holes to
-   contain data not intended for proving the client's identity or
-   establishing a reply key, but for protocol extensibility.  If the KDC
-   supports the PA-FX-FAST-REQUEST padata, unless otherwise specified,
-   the client MUST place any padata that is otherwise in the outer KDC
-   request body into this field.  In a TGS request, PA-TGS-REQ padata is
-   not included in this field and it is present in the outer KDC request
-   body.
-
-   The KDC-REQ-BODY in the FAST structure is used in preference to the
-   KDC-REQ-BODY outside of the FAST pre-authentication.  The outer KDC-
-   REQ-BODY structure SHOULD be filled in for backwards compatibility
-   with KDCs that do not support FAST.  A conforming KDC ignores the
-   outer KDC-REQ-BODY field in the KDC request.  Pre-authentication data
-   methods such as [RFC4556] that include a checksum of the KDC-REQ-BODY
-   should checksum the KDC-REQ-BODY in the FAST structure.
-
-   In a TGS request, a client MAY include the AD-fx-fast-used authdata
-   either in the pa-tgs-req authenticator or in the authorization data
-   in the pa-tgs-req ticket.  If the KDC receives this authorization
-   data but does not find a FAST padata then it MUST return
-   KRB_APP_ERR_MODIFIED.
-
-6.5.3.  FAST Response
-
-   The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST
-   padata element in the KDC reply.  In the case of an error, the PA-FX-
-   FAST padata is included in the KDC responses according to
-   Section 6.5.4.
-
-   The corresponding padata-value field [RFC4120] for the PA-FX-FAST in
-   the KDC response contains the DER encoding of the ASN.1 type PA-FX-
-   FAST-REPLY.
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 30]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-      PA-FX-FAST-REPLY ::= CHOICE {
-          armored-data [0] KrbFastArmoredRep,
-          ...
-      }
-
-      KrbFastArmoredRep ::= SEQUENCE {
-          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
-              -- The encryption key is the armor key in the request, and
-              -- the key usage number is KEY_USAGE_FAST_REP.
-          ...
-      }
-      KEY_USAGE_FAST_REP                 52
-
-   The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep
-   structure.  The KrbFastArmoredRep structure encapsulates the padata
-   in the KDC reply in the encrypted form.  The KrbFastResponse is
-   encrypted with the armor key used in the corresponding request, and
-   the key usage number is KEY_USAGE_FAST_REP.
-
-   The Kerberos client who does not receive a PA-FX-FAST-REPLY in the
-   KDC response MUST support a local policy that rejects the response.
-   Clients MAY also support policies that fall back to other mechanisms
-   or that do not use pre-authentication when FAST is unavailable.  It
-   is important to consider the potential downgrade attacks when
-   deploying such a policy.
-
-   The KrbFastResponse structure contains the following information:
-
-       KrbFastResponse ::= SEQUENCE {
-           padata         [0] SEQUENCE OF PA-DATA,
-               -- padata typed holes.
-           strengthen-key [1] EncryptionKey OPTIONAL,
-               -- This, if present, strengthens the reply key for AS and
-               -- TGS. MUST be present for TGS.
-               -- MUST be absent in KRB-ERROR.
-           finished       [2] KrbFastFinished OPTIONAL,
-               -- Present in AS or TGS reply; absent otherwise.
-           nonce          [3] UInt32,
-               -- Nonce from the client request.
-           ...
-  }
-
-   The padata field in the KrbFastResponse structure contains a list of
-   PA-DATA structures as described in Section 5.2.7 of [RFC4120].  These
-   PA-DATA structures are used to carry data advancing the exchange
-   specific for the FAST factors.  They can also be used as generic
-   typed-holes for protocol extensibility.  Unless otherwise specified,
-   the KDC MUST include any padata that is otherwise in the outer KDC-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 31]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   REP structure into this field.  The padata field in the KDC reply
-   structure outside of the PA-FX-FAST-REPLY structure typically
-   includes only the PA-FX- FAST-REPLY padata.
-
-   The strengthen-key field provides a mechanism for the KDC to
-   strengthen the reply key.  If set, the reply key is strengthened
-   after all padata items are processed.  Let padata-reply-key be the
-   reply key after padata processing.
-
-   reply-key = KRB-FX-CF2(strengthen-key, padata-reply-key,
-                         "strengthenkey", "replykey")
-
-   The strengthen-key field MAY be set in an AS reply; it MUST be set in
-   a TGS reply; it must be absent in an error reply.  The strengthen key
-   is required in a TGS reply so that an attacker cannot remove the FAST
-   PADATA from a TGS reply, causing the KDC to appear not to support
-   FAST.
-
-   The finished field contains a KrbFastFinished structure.  It is
-   filled by the KDC in the final message in the conversation.  This
-   field is present in an AS-REP or a TGS-REP when a ticket is returned,
-   and it is not present in an error reply.
-
-   The KrbFastFinished structure contains the following information:
-
-       KrbFastFinished ::= SEQUENCE {
-           timestamp       [0] KerberosTime,
-           usec            [1] Microseconds,
-               -- timestamp and usec represent the time on the KDC when
-               -- the reply was generated.
-           crealm          [2] Realm,
-           cname           [3] PrincipalName,
-               -- Contains the client realm and the client name.
-           ticket-checksum [4] Checksum,
-               -- checksum of the ticket in the KDC-REP  using the armor
-               -- and the key usage is KEY_USAGE_FAST_FINISH.
-               -- The checksum type is the required checksum type
-               -- of the armor key.
-           ...
-       }
-       KEY_USAGE_FAST_FINISHED            53
-
-   The timestamp and usec fields represent the time on the KDC when the
-   reply ticket was generated, these fields have the same semantics as
-   the corresponding-identically-named fields in Section 5.6.1 of
-   [RFC4120].  The client MUST use the KDC's time in these fields
-   thereafter when using the returned ticket.  Note that the KDC's time
-   in AS-REP may not match the authtime in the reply ticket if the kdc-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 32]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   follow-referrals option is requested and honored by the KDC.  The
-   client need not confirm that the timestamp returned is within
-   allowable clock skew: the armor key guarantees that the reply is
-   fresh.  The client MAY trust the time stamp returned.
-
-   The cname and crealm fields identify the authenticated client.  If
-   facilities described in [REFERRALS] are used, the authenticated
-   client may differ from the client in the FAST request.
-
-   The ticket-checksum is a checksum of the issued ticket.  The checksum
-   key is the armor key, and the checksum type is the required checksum
-   type of the enctype of that key, and the key usage number is
-   KEY_USAGE_FAST_FINISHED.
-
-   When FAST padata is included, the PA-FX-COOKIE padata as defined in
-   Section 6.3 MUST be included in the padata sequence in the
-   KrbFastResponse sequence if the KDC expects at least one more message
-   from the client in order to complete the authentication.
-
-   The nonce field in the KrbFastResponse contains the value of the
-   nonce field in the KDC-REQ of the corresponding client request and it
-   binds the KDC response with the client request.  The client MUST
-   verify that this nonce value in the reply matches with that of the
-   request and reject the KDC reply otherwise.  To prevent the response
-   from one message in a conversation from being replayed to a request
-   in another message, clients SHOULD use a new nonce for each message
-   in a conversation.
-
-6.5.4.  Authenticated Kerberos Error Messages using Kerberos FAST
-
-   If the Kerberos FAST padata was included in the request, unless
-   otherwise specified, the e-data field of the KRB-ERROR message
-   [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA
-   [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA.  The KDC
-   MUST include all the padata elements such as PA-ETYPE-INFO2 and
-   padata elements that indicate acceptable pre-authentication
-   mechanisms [RFC4120] in the KrbFastResponse structure.
-
-   The KDC MUST also include a PA-FX-ERROR padata item in the
-   KRBFastResponse structure.  The padata-value element of this sequence
-   is the ASN.1 DER encoding of the type KRB-ERROR.  The e-data field
-   MUST be absent in the PA-FX-ERROR padata.  All other fields should be
-   the same as the outer KRB-ERROR.  The client ignores the outer error
-   and uses the combination of the padata in the KRBFastResponse and the
-   error information in the PA-FX-ERROR.
-
-              PA-FX-ERROR                        137
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 33]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   If the Kerberos FAST padata is included in the request but not
-   included in the error reply, it is a matter of the local policy on
-   the client to accept the information in the error message without
-   integrity protection.  The client SHOULD however process the KDC
-   errors as the result of the KDC's inability to accept the AP_REQ
-   armor and potentially retry another request with a different armor
-   when applicable.  The Kerberos client MAY process an error message
-   without a PA-FX-FAST-REPLY, if that is only intended to return better
-   error information to the application, typically for trouble-shooting
-   purposes.
-
-   In the cases where the e-data field of the KRB-ERROR message is
-   expected to carry a TYPED-DATA [RFC4120] element, then that
-   information should be transmitted in a pa-data element within the
-   KRBFastResponse structure.  The padata-type is the same as the data-
-   type would be in the typed data element and the padata-value is the
-   same as the data-value.  As discussed in Section 8, data-types and
-   padata-types are drawn from the same namespace.  For example, the
-   TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR
-   message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE
-   [RFC4556].
-
-6.5.5.  Outer and Inner Requests
-
-   Typically, a client will know that FAST is being used before a
-   request containing PA-FX-FAST is sent.  So, the outer AS request
-   typically only includes one pa-data item: PA-FX-FAST.  The client MAY
-   include additional pa-data, but the KDC MUST ignore the outer request
-   body and any padata besides PA-FX-FAST if and only if PA-FX-FAST is
-   processed.  In the case of the TGS request, the outer request should
-   include PA-FX-FAST and PA-TGS-REQ.
-
-   When an AS generates a response, all padata besides PA-FX-FAST should
-   be included in PA-FX-FAST.  The client MUST ignore other padata
-   outside of PA-FX-FAST.
-
-6.5.6.  The Encrypted Challenge FAST Factor
-
-   The encrypted challenge FAST factor authenticates a client using the
-   client's long-term key.  This factor works similarly to the encrypted
-   time stamp pre-authentication option described in [RFC4120].  The
-   word challenge is used instead of timestamp because while the
-   timestamp is used as an initial challenge, if the KDC and client do
-   not have synchronized time, then the KDC can provide updated time to
-   the client to use as a challenge.  The client encrypts a structure
-   containing a timestamp in the challenge key.  The challenge key used
-   by the client to send a message to the KDC is KRB-FX-
-   CF2(armor_key,long_term_key, "clientchallengearmor",
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 34]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   "challengelongterm").  The challenge key used by the KDC encrypting
-   to the client is KRB-FX-CF2(armor_key, long_term_key,
-   "kdcchallengearmor", "challengelongterm").  Because the armor key is
-   fresh and random, the challenge key is fresh and random.  The only
-   purpose of the timestamp is to limit the validity of the
-   authentication so that a request cannot be replayed.  A client MAY
-   base the timestamp on the KDC time in a KDC error and need not
-   maintain accurate time synchronization itself.  If a client bases its
-   time on an untrusted source, an attacker may trick the client into
-   producing an authentication request that is valid at some future
-   time.  The attacker may be able to use this authentication request to
-   make it appear that a client has authenticated at that future time.
-   If ticket-based armor is used, then the lifetime of the ticket will
-   limit the window in which an attacker can make the client appear to
-   have authenticated.  For many situations, the ability of an attacker
-   to cause a client to appear to have authenticated is not a
-   significant concern; the ability to avoid requiring time
-   synchronization on clients is more valuable.
-
-   The client sends a padata of type PA-ENCRYPTED-CHALLENGE.  The
-   corresponding padata-value contains the DER encoding of ASN.1 type
-   EncryptedChallenge.
-
-      EncryptedChallenge ::= EncryptedData
-              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
-
-      PA-ENCRYPTED-CHALLENGE          138
-      KEY_USAGE_ENC_CHALLENGE_CLIENT  54
-      KEY_USAGE_ENC_CHALLENGE_KDC     55
-
-   The client includes some time stamp reasonably close to the KDC's
-   current time and encrypts it in the challenge key.  Clients MAY use
-   the current time; doing so prevents the exposure where an attacker
-   can cause a client to appear to authenticate in the future.  The
-   client sends the request including this factor.
-
-   On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE fast
-   factor, the KDC decrypts the timestamp.  If the decryption fails the
-   KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in
-   the KRBFastResponse in the error.  The KDC confirms that the
-   timestamp falls within its current clock skew returning
-   KRB_APP_ERR_SKEW if not.  The KDC then SHOULD check to see if the
-   encrypted challenge is a replay.  The KDC MUST NOT consider two
-   encrypted challenges replays simply because the time stamps are the
-   same; to be a replay, the ciphertext MUST be identical.  Allowing
-   clients to re-use time stamps avoids requiring that clients maintain
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 35]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   state about which time stamps have been used.
-
-   If the KDC accepts the encrypted challenge, it MUST include a padata
-   element of type PA-ENCRYPTED-CHALLENGE.  The KDC encrypts its current
-   time in the challenge key.  The KDC MUST strengthen the reply key
-   before issuing a ticket.  The client MUST check that the timestamp
-   decrypts properly.  The client MAY check that the timestamp is within
-   the window of acceptable clock skew for the client.  The client MUST
-   NOT require that the timestamp be identical to the timestamp in the
-   issued credentials or the returned message.
-
-   The encrypted challenge FAST factor provides the following
-   facilities: client-authentication and KDC authentication.  This FAST
-   factor also takes advantage of the FAST facility to strengthen the
-   reply key.  It does not provide the replacing-reply-key facility.
-   The security considerations section of this document provides an
-   explanation why the security requirements are met.
-
-   The encrypted challenge FAST factor can be useful in an
-   authentication set.  No pa-hint is defined because the only
-   information needed by this mechanism is information contained in the
-   PA-ETYPE-INFO2 pre-authentication data.  KDCs are already required to
-   send PA-ETYPE-INFO2.  If KDCs were not required to send PA-ETYPE-
-   INFO2 then that information would need to be part of a hint for
-   encrypted challenge.
-
-   Conforming implementations MUST support the encrypted challenge FAST
-   factor.
-
-6.6.  Authentication Strength Indication
-
-   Implementations that have pre-authentication mechanisms offering
-   significantly different strengths of client authentication MAY choose
-   to keep track of the strength of the authentication used as an input
-   into policy decisions.  For example, some principals might require
-   strong pre-authentication, while less sensitive principals can use
-   relatively weak forms of pre-authentication like encrypted timestamp.
-
-   An AuthorizationData data type AD-Authentication-Strength is defined
-   for this purpose.
-
-        AD-authentication-strength         70
-
-   The corresponding ad-data field contains the DER encoding of the pre-
-   authentication data set as defined in Section 6.4.  This set contains
-   all the pre-authentication mechanisms that were used to authenticate
-   the client.  If only one pre-authentication mechanism was used to
-   authenticate the client, the pre-authentication set contains one
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 36]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   element.
-
-   The AD-authentication-strength element MUST be included in the AD-IF-
-   RELEVANT, thus it can be ignored if it is unknown to the receiver.
-
-
-7.  Assigned Constants
-
-   The pre-authentication framework and FAST involve using a number of
-   Kerberos protocol constants.  This section lists protocol constants
-   first introduced in this specification drawn from registries not
-   managed by IANA.  Many of these registries would best be managed by
-   IANA; that is a known issue that is out of scope for this document.
-   The constants described in this section have been accounted for and
-   will appear in the next revision of the Kerberos core specification
-   or in a document creating IANA registries.
-
-   Section 8 creates IANA registries for a different set of constants
-   used by the extensions described in this document.
-
-7.1.  New Errors
-
-           KDC_ERR_PREAUTH_EXPIRED                 90
-           KDC_ERR_MORE_PREAUTH_DATA_REQUIRED      91
-           KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET  92
-           KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS   93
-
-7.2.  Key Usage Numbers
-
-           KEY_USAGE_FAST_REQ_CHKSUM               50
-           KEY_USAGE_FAST_ENC                      51
-           KEY_USAGE_FAST_REP                      52
-           KEY_USAGE_FAST_FINISHED                 53
-           KEY_USAGE_ENC_CHALLENGE_CLIENT          54
-           KEY_USAGE_ENC_CHALLENGE_KDC             55
-
-7.3.  Authorization Data Elements
-
-           AD-authentication-strength              70
-           AD-fx-fast-armor                        71
-           AD-fx-fast-used                         72
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 37]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-7.4.  New PA-DATA Types
-
-           PA-FX-COOKIE                            133
-           PA-AUTHENTICATION-SET                   134
-           PA-AUTH-SET-SELECTED                    135
-           PA-FX-FAST                              136
-           PA-FX-ERROR                             137
-           PA-ENCRYPTED-CHALLENGE                  138
-
-
-8.  IANA Considerations
-
-   This document creates a number of IANA registries.  These registries
-   should all be located under
-   http://www.iana.org/assignments/kerberos-parameters.
-
-8.1.  Pre-authentication and Typed Data
-
-   RFC 4120 defines pre-authentication data, which can be included in a
-   KDC request or response in order to authenticate the client or extend
-   the protocol.  In addition, it defines Typed-Data which is an
-   extension mechanism for errors.  Both pre-authentication data and
-   typed data are carried as a 32-bit signed integer along with an octet
-   string.  The encoding of typed data and pre-authentication data is
-   slightly different.  However the types for pre-authentication data
-   and typed-data are drawn from the same namespace.  By convention,
-   registrations starting with TD- are typed data and registration
-   starting with PA- are pre-authentication data.  It is important that
-   these data types be drawn from the same namespace, because some
-   errors where it would be desirable to include typed data require the
-   e-data field to be formatted as pre-authentication data.
-
-   When Kerberos FAST is used, pre-authentication data encoding is
-   always used.
-
-   There is one apparently conflicting registration between typed data
-   and pre-authentication data.  PA-GET-FROM-TYPED-DATA and TD-PADATA
-   are both assigned the value 22.  However this registration is simply
-   a mechanism to include an element of the other encoding.  The use of
-   both should be deprecated.
-
-   This document creates a registry for pre-authentication and typed
-   data.  The registration procedures are as follows.  Expert review for
-   pre-authentication mechanisms designed to authenticate users, KDCs,
-   or establish the reply key.  The expert first determines that the
-   purpose of the method is to authenticate clients, KDCs, or to
-   establish the reply key.  If so, expert review is appropriate.  The
-   expert evaluates the security and interoperability of the
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 38]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   specification.
-
-   IETF review is required if the expert believes that the pre-
-   authentication method is broader than these three areas.  Pre-
-   authentication methods that change the Kerberos state machine or
-   otherwise make significant changes to the Kerberos protocol should be
-   standards track RFCs.  A concern that a particular method needs to be
-   a standards track RFC may be raised as an objection during IETF
-   review.
-
-      Type                Value    Reference
-  ----------------------------------------------------------------------
-  PA-TGS-REQ                 1    RFC 4120
-  PA-ENC-TIMESTAMP           2    RFC 4120
-  PA-PW-SALT                 3    RFC 4120
-  [reserved]                 4
-  PA-ENC-UNIX-TIME           5    (deprecated)
-  PA-SANDIA-SECUREID         6
-  PA-SESAME                  7
-  PA-OSF-DCE                 8
-  PA-CYBERSAFE-SECUREID      9
-  PA-AFS3-SALT               10
-  PA-ETYPE-INFO              11   RFC 4120
-  PA-SAM-CHALLENGE           12   (sam/otp)
-  PA-SAM-RESPONSE            13   (sam/otp)
-  PA-PK-AS-REQ_OLD           14   draft-ietf-cat-kerberos-pk-init-09
-  PA-PK-AS-REP_OLD           15   draft-ietf-cat-kerberos-pk-init-09
-  PA-PK-AS-REQ               16   RFC 4556
-  PA-PK-AS-REP               17   RFC 4556
-  PA-PK-OCSP-RESPONSE        18   RFC 4557
-  PA-ETYPE-INFO2             19   RFC 4120
-  PA-USE-SPECIFIED-KVNO      20
-  PA-SVR-REFERRAL-INFO       20   (referrals)
-  PA-SAM-REDIRECT            21   (sam/otp)
-  PA-GET-FROM-TYPED-DATA     22   (embedded in typed data)
-  TD-PADATA                  22   (embeds padata)
-  PA-SAM-ETYPE-INFO          23   (sam/otp)
-  PA-ALT-PRINC               24   (crawdad@fnal.gov)
-  PA-SERVER-REFERRAL         25   (referrals)
-  PA-SAM-CHALLENGE2          30   (kenh@pobox.com)
-  PA-SAM-RESPONSE2           31   (kenh@pobox.com)
-  PA-EXTRA-TGT               41   Reserved extra TGT
-  TD-PKINIT-CMS-CERTIFICATES 101  CertificateSet from CMS
-  TD-KRB-PRINCIPAL           102  PrincipalName
-  TD-KRB-REALM               103  Realm
-  TD-TRUSTED-CERTIFIERS      104  PKINIT
-  TD-CERTIFICATE-INDEX       105  PKINIT
-  TD-APP-DEFINED-ERROR       106  Application specific
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 39]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-  TD-REQ-NONCE               107  INTEGER
-  TD-REQ-SEQ                 108  INTEGER
-  PA-PAC-REQUEST             128  MS-KILE
-  PA-FOR_USER                129  MS-KILE
-  PA-FOR-X509-USER           130  MS-KILE
-  PA-FOR-CHECK_DUPS          131  MS-KILE
-  PA-AS-CHECKSUM             132  MS-KILE
-  PA-FX-COOKIE               133  draft-ietf-krb-wg-preauth-framework
-  PA-AUTHENTICATION-SET      134  draft-ietf-krb-wg-preauth-framework
-  PA-AUTH-SET-SELECTED       135  draft-ietf-krb-wg-preauth-framework
-  PA-FX-FAST                 136  draft-ietf-krb-wg-preauth-framework
-  PA-FX-ERROR                137  draft-ietf-krb-wg-preauth-framework
-  PA-ENCRYPTED-CHALLENGE     138  draft-ietf-krb-wg-preauth-framework
-  PA-OTP-CHALLENGE           141  (gareth.richards@rsa.com)
-  PA-OTP-REQUEST             142  (gareth.richards@rsa.com)
-  PA-OTP-CONFIRM             143  (gareth.richards@rsa.com)
-  PA-OTP-PIN-CHANGE          144  (gareth.richards@rsa.com)
-  PA-EPAK-AS-REQ             145  (sshock@gmail.com)
-  PA-EPAK-AS-REP             146  (sshock@gmail.com>)
-  PA_PKINIT_KX               147  draft-ietf-krb-wg-anon
-  PA_PKU2U_NAME              148  draft-zhu-pku2u
-  PA-SUPPORTED-ETYPES        165  MS-KILE
-  PA-EXTENDED_ERROR          166  MS-KILE
-
-8.2.  Fast Armor Types
-
-   FAST armor types are defined in Section 6.5.1.  A FAST armor type is
-   a signed 32-bit integer.  FAST armor types are assigned by standards
-   action.
-
-          Type    Name                   Description
-        ------------------------------------------------------------
-          0                              Reserved.
-          1   FX_FAST_ARMOR_AP_REQUEST   Ticket armor using an ap-req.
-
-8.3.  FAST Options
-
-   A FAST request includes a set of bit flags to indicate additional
-   options.  Bits 0-15 are critical; other bits are non-critical.
-   Assigning bits greater than 31 may require special support in
-   implementations.  Assignment of FAST options requires standards
-   action.
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 40]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-      Type    Name                   Description
-     -------------------------------------------------------------------
-      0     RESERVED               Reserved for future expansion of this
-                                   field.
-      1     hide-client-names      Requesting the KDC to hide client
-                                   names in the KDC response
-      16    kdc-follow-referrals   Requesting the KDC to follow
-                                   referrals
-
-
-9.  Security Considerations
-
-   The kdc-referrals option in the Kerberos FAST padata requests the KDC
-   to act as the client to follow referrals.  This can overload the KDC.
-   To limit the damages of denial of service using this option, KDCs MAY
-   restrict the number of simultaneous active requests with this option
-   for any given client principal.
-
-   Regarding to the facilities provided by the Encrypted Challenge FAST
-   factor, the challenge key is derived from the client secrets and
-   because the client secrets are known only to the client and the KDC,
-   the verification of the EncryptedChallenge structure proves the
-   client's identity, the verification of the EncryptedChallenge
-   structure in the KDC reply proves that the expected KDC responded.
-   Therefore, the Encrypted Challenge FAST factor as a pre-
-   authentication mechanism offers the following facilities: client-
-   authentication and KDC-authentication.  There is no un-authenticated
-   clear text introduced by the Encrypted Challenge FAST factor.
-
-   FAST provides an encrypted tunnel over which pre-authentication
-   conversations can take place.  In addition, FAST optionally
-   authenticates the KDC to the client.  It is the responsibility of
-   FAST factors to authenticate the client to the KDC.  Care MUST be
-   taken to design FAST factors such that they are bound to the
-   conversation.  If this is not done, a man-in-the-middle may be able
-   to cut&paste a fast factor from one conversation to another.  The
-   easiest way to do this is to bind each fast factor to the armor key
-   which is guaranteed to be unique for each conversation.
-
-   The anonymous pkinit mode for obtaining an armor ticket does not
-   always authenticate the KDC to the client before the conversation
-   begins.  Tracking the KDC verified state guarantees that by the end
-   of the conversation, the client has authenticated the KDC.  However
-   fast factor designers need to consider the implications of using
-   their factor when the KDC has not yet been authenticated.  If this
-   proves problematic in an environment, then the particular fast factor
-   should not be used with anonymous PKINIT.
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 41]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   Existing pre-authentication mechanisms are believed to be at least as
-   secure when used with FAST as they are when used outside of FAST.
-   One part of this security is making sure that when pre-authentication
-   methods checksum the request, they checksum the inner request rather
-   than the outer request.  If the mechanism checksummed the outer
-   request, a man-in-the-middle could observe it outside a FAST tunnel
-   and then cut&paste it into a FAST exchange where the inner rather
-   than outer request would be used to select attributes of the issued
-   ticket.  Such attacks would typically invalidate auditing information
-   or create a situation where the client and KDC disagree about what
-   ticket is issued.  However, such attacks are unlikely to allow an
-   attacker who would not be able to authenticate as a principal to do
-   so.  Even so, FAST is believed to defend against these attacks in
-   existing legacy mechanism.  However since there is no standard for
-   how legacy mechanisms bind the request to the pre-authentication or
-   provide integrity protection, security analysis can be difficult.  In
-   some cases FAST may significantly improve the integrity protection of
-   legacy mechanisms.
-
-   The security of the TGS exchange depends on authenticating the client
-   to the KDC.  In the AS exchange, this is done using pre-
-   authentication data or FAST factors.  In the TGS exchange, this is
-   done by presenting a TGT and by using the session (or sub-session)
-   key in constructing the request.  Because FAST uses a request body in
-   the inner request, encrypted in the armor key, rather than the
-   request body in the outer request, it is critical that establishing
-   the armor key be tied to the authentication of the client to the KDC.
-   If this is not done, an attacker could manipulate the options
-   requested in the TGS request, for example requesting a ticket with
-   different validity or addresses.  The easiest way to bind the armor
-   key to the authentication of the client to the KDC is for the armor
-   key to depend on the sub-session key of the TGT.  This is done with
-   the implicit TGS armor supported by this specification.  Future armor
-   types designed for use with the TGS MUST either bind their armor keys
-   to the TGT or provide another mechanism to authenticate the client to
-   the KDC.
-
-
-10.  Acknowledgements
-
-   Sam Hartman would like to thank the MIT Kerberos Consortium for its
-   funding of his time on this project.
-
-   Several suggestions from Jeffrey Hutzelman based on early revisions
-   of this documents led to significant improvements of this document.
-
-   The proposal to ask one KDC to chase down the referrals and return
-   the final ticket is based on requirements in [ID.CROSS].
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 42]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-   Joel Webber had a proposal for a mechanism similar to FAST that
-   created a protected tunnel for Kerberos pre-authentication.
-
-   Srinivas Cheruku and Greg Hudson provided valuable review comments.
-
-
-11.  References
-
-11.1.  Normative References
-
-   [KRB-ANON]
-              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
-              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-11.2.  Informative References
-
-   [EKE]      Bellovin, S. and M. Merritt, "Augmented Encrypted Key
-              Exchange: A Password-Based Protocol Secure Against
-              Dictionary Attacks and Password File Compromise,
-              Proceedings of the 1st ACM Conference on Computer and
-              Communications Security, ACM Press.", November 1993.
-
-   [ID.CROSS]
-              Sakane, S., Zrelli, S., and M. Ishiyama , "Problem
-              Statement on the Operation of Kerberos in a Specific
-              System", draft-sakane-krb-cross-problem-statement-02.txt
-              (work in progress), April 2007.
-
-   [IEEE1363.2]
-              IEEE, "IEEE P1363.2: Password-Based Public-Key
-              Cryptography", 2004.
-
-   [KRB-WG.SAM]
-              Hornstein, K., Renard, K., Neuman, C., and G. Zorn,
-              "Integrating Single-use Authentication Mechanisms with
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 43]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-              Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in
-              progress), October 2003.
-
-   [REFERRALS]
-              Raeburn, K. and L. Zhu, "Generating KDC Referrals to
-              Locate Kerberos Realms",
-              draft-ietf-krb-wg-kerberos-referrals-10.txt (work in
-              progress), 2007.
-
-
-Appendix A.  Test Vectors for KRB-FX-CF2
-
-   This informative appendix presents test vectors for the KRB-FX-CF2
-   function.  Test vectors are presented for several encryption types.
-   In all cases the first key (k1) is the result of string-to-
-   key("key1", "key1", default_parameters) and the second key (k2) is
-   the result of string-to-key("key2", "key2", default_parameters).
-   Both keys are of the same enctype.  The presented test vector is the
-   hexadecimal encoding of the key produced by KRB-FX-CF2(k1, k2, "a",
-   "b").  The peppers are one-octet ASCII strings.
-
-   In performing interoperability testing, there was significant
-   ambiguity surrounding [RFC3961] pseudo-random operations.  These test
-   vectors assume that the AES pseudo-random operation is aes-
-   ecb(trunc128(sha-1(input))) where trunc128 truncates its input to
-   128-bits.  The 3DES pseudo-random operation is assumed to be des3-
-   cbc(trunc128(sha-1(input))).  The DES pseudo-random operation is
-   assumed to be des-cbc(md5(input)).  As specified in RFC 4757, the RC4
-   pseudo-random operation is hmac-sha1(input).
-
-   Interoperability testing also demonstrated ambiguity surrounding the
-   DES random-to-key operation.  The random-to-key operation is assumed
-   to be distribute 56 bits into high-7-bits of 8 octets and generate
-   parity.
-
-   These test vectors were produced with revision 22359 of the MIT
-   Kerberos sources.  The AES 256 and AES 128 test vectors have been
-   confirmed by multiple other implementors.  The RC4 test vectors have
-   been confirmed by one other implementor.  The DES and triple DES test
-   vectors have not been confirmed.
-
-
-   aes 128 (enctype 17): 97df97e4b798b29eb31ed7280287a92a
-   AES256 (enctype 18): 4d6ca4e629785c1f01baf55e2e548566
-                        b9617ae3a96868c337cb93b5e72b1c7b
-   DES (enctype 1): 43bae3738c9467e6
-   3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01
-   RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 44]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-Appendix B.  Change History
-
-   RFC editor, please remove this section before publication.
-
-B.1.  Changes since 13
-
-      Restore DES test vectors; their removal was not mentioned in 13.
-      Clarify that only implicit TGS armor is defined at this time.  In
-      the future we may define explicit TGS armor.
-
-B.2.  Changes since 12
-
-      Per comment from Greg Hudson, KDC_ERR_MORE_PREAUTH_DATA_REQUIRED
-      instead of KDC_ERR_MORE_PREAUTH_DATA_NEEDED
-      Use pa-authentication-set-selected not pa-auth-set-selected
-      Update discussion of KDC verification (Love)
-      Remove explicit TGS armor, note that TGS armor must authenticate
-      the client to the KDC, describe in security considerations.
-
-B.3.  Changes since 11
-
-      Checksum the inner request body in methods like PKINIT, not the
-      outer request body.  Per mailing list discussion, this change
-      addresses a potential security weakness.
-      Add additional security considerations text
-
-B.4.  Changes since 10
-
-      The checksum member of the KrbFastFinished sequence has been
-      removed.  A nonce field has been added to KrbFastResponse.
-      The cookie no longer needs to be outside of FAST.  In fact, some
-      security guarantees depend on the cookie being inside FAST now
-      that the finish checksum has been removed.  Affected that change.
-      Replace the rep-key field in KrbFastResponse with the strengthen-
-      key field.  Per mailing list discussion, there are security
-      advantages to strengthening the reply key.
-      Clarify handling of authentication sets.
-      Include the AD-fx-fast-used authorization data type.
-      Include note about random nonces.
-
-B.5.  Changes since 09
-
-      Clarify conversations by defining for TGS and by describing how
-      cookies form conversation boundaries.
-      Simplify text surrounding when finish is included: always for AS
-      and TGS reply, never for error.
-
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 45]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-      Fill in IANA and constants
-
-B.6.  Changes since 08
-
-      Fix a number of typos
-      Rename anonymous flag to hide-client-name; rename kdc-referals to
-      kdc-follow-referrals
-      Clarify how anonymous pkinit interacts with KDC verified.
-      Introduce AD-fx-fast-armor authorization data to deal with
-      unprivileged processes constructing KDC requests.  Note that a TGT
-      is always used for armor tickets if the armor field is present; if
-      you proxy or validate you'll end up with a TGT armor ticket and
-      another ticket in the pa-tgs-req.  Alternatively you can simply
-      use the other ticket in the PA-TGS-REQ; weak consensus within WG.
-      All KDCs in a realm MUST support FAST if it is to be offered.
-      The cookie message is always generated by the KDC.
-      Note that the client can trust and need not verify the time stamp
-      in the finish message.  This can seed the client's idea of KDC
-      time.
-      Note that the client name in the finish message may differ from
-      the name in the request if referrals are used.
-      Note that KDCs should advertize fast in preauth_required errors.
-      Armor key is constructed using KRB-FX-CF2.  This is true even in
-      the TGS case; there is no security reason to do this.  Using the
-      subkey as done in draft 08 would be fine, but the current text
-      uses the same procedure both in the TGS and AS case.
-      Use a different challenge key in each direction in the encrypted
-      challenge option.
-      Note that the KDC should process PA-FX-COOKIE before other padata.
-      KRB-FX-CF2 uses k1's enctype for the result; change around calling
-      order so we pass in subkeys and armor keys as k1 in preference to
-      long-term keys or ticket session keys.
-      Clarify the relationship between authentication sets and cookies.
-      A cookie may not be needed in the first message.  Clarify how this
-      interacts with optimistic clients.
-      Remove text raising a concern that RFC 3961 may permit ciphertext
-      transformations that do not change plaintext: discussion on the
-      list came to the conclusion that RFC 3961 does not permit this.
-      Remove binding key concept; use the armor key instead.  The cookie
-      becomes just an octet string.
-      Include PA-FX-ERROR to protect the error information per Dublin.
-      Returning preauth_failed in the failed to decrypt encrypted
-      challenge seems fine; remove the issue marker
-      Add a section describing what goes in the inner and outer request.
-      I believe it is redundant but found it useful while putting
-      together an implementation proposal.
-
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 46]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-      Use hyphen rather than underscore in the constants for pre-
-      authentication data to be consistent with RFC 4120.
-      Add a ticket-checksum to the finished message
-      Remove redundant KEY_USAGE_FAST_ARMOR.
-      Add protocol constants section for non-IANA registrations and
-      flesh out IANA section.
-      Clarify that kdc-req-body checksums should always use the outer
-      body even for mechanisms like PKINIT that include their own (now
-      redundant) checksum.
-      Remove mechanism for encapsulating typed data in padata; just
-      reflect the value.
-
-B.7.  Changes since 07
-
-      Propose replacement of authenticated timestamp with encrypted
-      challenge.  The desire to avoid clients needing time
-      synchronization and to simply the factor.
-      Add a requirement that any FAST armor scheme must provide a fresh
-      key for each conversation.  This allows us to assume that anything
-      encrypted/integrity protected in the right key is fresh and not
-      subject to cross-conversation cut and paste.
-      Removed heartbeat padata.  The KDC will double up messages if it
-      needs to; the client simply sends its message and waits for the
-      next response.
-      Define PA-auth-SET-SELECTED
-      Clarify a KDC cannot ignore padata is has claimed to support
-
-B.8.  Changes since 06
-
-      Note that even for replace reply key it is likely that the side
-      using the mechanism will know that the other side supports it.
-      Since it is reasonably unlikely we'll need a container mechanism
-      other than FAST itself, we don't need to optimize for that case.
-      So, we want to optimize for implementation simplicity.  Thus if
-      you do have such a container mechanism interacting with
-      authentication sets we'll assume that the hint need to describe
-      hints for all contained mechanisms.  This closes out a long-
-      standing issue.
-      Write up what Sam believes is the consensus on UI and prompts in
-      the authentication set: clients MAY assume that they have all the
-      UI information they need.
-
-
-Appendix C.  ASN.1 module
-
-      KerberosPreauthFramework {
-            iso(1) identified-organization(3) dod(6) internet(1)
-            security(5) kerberosV5(2) modules(4) preauth-framework(3)
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 47]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      IMPORTS
-           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum,
-           Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY,
-           Microseconds, KerberosFlags
-                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                  dod(6) internet(1) security(5) kerberosV5(2)
-                  modules(4) krb5spec2(2) };
-                  -- as defined in RFC 4120.
-
-
-      PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
-
-      PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
-          pa-type      [0] Int32,
-              -- same as padata-type.
-          pa-hint      [1] OCTET STRING OPTIONAL,
-          pa-value     [2] OCTET STRING OPTIONAL,
-          ...
-      }
-
-      KrbFastArmor ::= SEQUENCE {
-          armor-type   [0] Int32,
-              -- Type of the armor.
-          armor-value  [1] OCTET STRING,
-              -- Value of the armor.
-          ...
-      }
-
-      PA-FX-FAST-REQUEST ::= CHOICE {
-          armored-data [0] KrbFastArmoredReq,
-          ...
-      }
-
-      KrbFastArmoredReq ::= SEQUENCE {
-          armor        [0] KrbFastArmor OPTIONAL,
-              -- Contains the armor that identifies the armor key.
-              -- MUST be present in AS-REQ.
-          req-checksum [1] Checksum,
-              -- For AS, contains the checksum performed over the type
-              -- KDC-REQ-BODY for the req-body field of the KDC-REQ
-              -- structure;
-              -- For TGS, contains the checksum performed over the type
-              -- AP-REQ in the PA-TGS-REQ padata.
-              -- The checksum key is the armor key, the checksum
-              -- type is the required checksum type for the enctype of
-              -- the armor key, and the key usage number is
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 48]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-              -- KEY_USAGE_FAST_REQ_CHKSUM.
-          enc-fast-req [2] EncryptedData, -- KrbFastReq --
-              -- The encryption key is the armor key, and the key usage
-              -- number is KEY_USAGE_FAST_ENC.
-          ...
-      }
-
-      KrbFastReq ::= SEQUENCE {
-          fast-options [0] FastOptions,
-              -- Additional options.
-          padata       [1] SEQUENCE OF PA-DATA,
-              -- padata typed holes.
-          req-body     [2] KDC-REQ-BODY,
-              -- Contains the KDC request body as defined in Section
-              -- 5.4.1 of [RFC4120].
-              -- This req-body field is preferred over the outer field
-              -- in the KDC request.
-           ...
-      }
-
-      FastOptions ::= KerberosFlags
-          -- reserved(0),
-          -- hide-client-names(1),
-          -- kdc-follow-referrals(16)
-
-      PA-FX-FAST-REPLY ::= CHOICE {
-          armored-data [0] KrbFastArmoredRep,
-          ...
-      }
-
-      KrbFastArmoredRep ::= SEQUENCE {
-          enc-fast-rep      [0] EncryptedData, -- KrbFastResponse --
-              -- The encryption key is the armor key in the request, and
-              -- the key usage number is KEY_USAGE_FAST_REP.
-          ...
-      }
-
-      KrbFastResponse ::= SEQUENCE {
-          padata         [0] SEQUENCE OF PA-DATA,
-              -- padata typed holes.
-          strengthen-key [1] EncryptionKey OPTIONAL,
-              -- This, if present, strengthens the reply key for AS and
-              -- TGS.  MUST be present for TGS
-              -- MUST be absent in KRB-ERROR.
-          finished       [2] KrbFastFinished OPTIONAL,
-              -- Present in AS or TGS reply; absent otherwise.
-          nonce          [3] UInt32,
-              -- Nonce from the client request.
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 49]
-
-Internet-Draft         Kerberos Preauth Framework            August 2009
-
-
-          ...
-      }
-
-      KrbFastFinished ::= SEQUENCE {
-          timestamp       [0] KerberosTime,
-          usec            [1] Microseconds,
-              -- timestamp and usec represent the time on the KDC when
-              -- the reply was generated.
-          crealm          [2] Realm,
-          cname           [3] PrincipalName,
-              -- Contains the client realm and the client name.
-          ticket-checksum [4] Checksum,
-              -- checksum of the ticket in the KDC-REP  using the armor
-              -- and the key usage is KEY_USAGE_FAST_FINISH.
-              -- The checksum type is the required checksum type
-              -- of the armor key.
-          ...
-      }
-
-      EncryptedChallenge ::= EncryptedData
-              -- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-              -- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-              -- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
-      END
-
-
-Authors' Addresses
-
-   Sam hartman
-   Painless Security
-
-   Email: hartmans-ietf@mit.edu
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-
-Hartman & Zhu           Expires February 13, 2010              [Page 50]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-00.txt b/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-00.txt
deleted file mode 100644
index 036c67506..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-00.txt
+++ /dev/null
@@ -1,6049 +0,0 @@
-
-
-INTERNET-DRAFT                                                    Tom Yu
-draft-ietf-krb-wg-rfc1510ter-00.txt                                  MIT
-Expires: 25 July 2005                                    21 January 2005
-
-        The Kerberos Network Authentication Service (Version 5)
-
-Status of This Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   or will be disclosed, and any of which I become aware will be
-   disclosed, in accordance with RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-
-      http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-
-      http://www.ietf.org/shadow.html
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).  All Rights Reserved.
-
-Abstract
-
-   This document describes version 5 of the Kerberos network
-   authentication protocol.  It describes a framework to allow for
-   extensions to be made to the protocol without creating
-   interoperability problems.
-
-Key Words for Requirements
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
-   to be interpreted as described in RFC 2119.
-
-
-
-
-Yu                         Expires: Jul 2005                    [Page 1]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-Table of Contents
-
-   Status of This Memo ..............................................  1
-   Copyright Notice .................................................  1
-   Abstract .........................................................  1
-   Key Words for Requirements .......................................  1
-   Table of Contents ................................................  2
-   1.  Introduction .................................................  5
-   1.1.  Kerberos Protocol Overview .................................  5
-   1.2.  Document Organization ......................................  6
-   2.  Compatibility Considerations .................................  6
-   2.1.  Extensibility ..............................................  7
-   2.2.  Compatibility with RFC 1510 ................................  7
-   2.3.  Backwards Compatibility ....................................  7
-   2.4.  1.4.2. Sending Extensible Messages .........................  8
-   2.5.  Criticality ................................................  8
-   2.6.  Authenticating Cleartext Portions of Messages ..............  9
-   2.7.  Capability Negotiation ..................................... 10
-   3.  Use of ASN.1 in Kerberos ..................................... 10
-   3.1.  Module Header .............................................. 11
-   3.2.  Top-Level Type ............................................. 11
-   3.3.  Previously Unused ASN.1 Notation (informative) ............. 12
-   3.3.1.  Parameterized Types ...................................... 12
-   3.3.2.  COMPONENTS OF Notation ................................... 12
-   3.3.3.  Constraints .............................................. 12
-   3.4.  New Types .................................................. 13
-   4.  Basic Types .................................................. 14
-   4.1.  Constrained Integer Types .................................. 14
-   4.2.  KerberosTime ............................................... 15
-   4.3.  KerberosString ............................................. 15
-   4.4.  Language Tags .............................................. 16
-   4.5.  KerberosFlags .............................................. 16
-   4.6.  Typed Holes ................................................ 16
-   4.7.  HostAddress and HostAddresses .............................. 17
-   4.7.1.  Internet (IPv4) Addresses ................................ 17
-   4.7.2.  Internet (IPv6) Addresses ................................ 17
-   4.7.3.  DECnet Phase IV addresses ................................ 18
-   4.7.4.  Netbios addresses ........................................ 18
-   4.7.5.  Directional Addresses .................................... 18
-   5.  Principals ................................................... 19
-   5.1.  Name Types ................................................. 19
-   5.2.  Principal Type Definition .................................. 19
-   5.3.  Principal Name Reuse ....................................... 20
-   5.4.  Realm Names ................................................ 20
-   5.5.  Printable Representations of Principal Names ............... 21
-   5.6.  Ticket-Granting Service Principal .......................... 21
-   5.6.1.  Cross-Realm TGS Principals ............................... 21
-   6.  Types Relating to Encryption ................................. 21
-   6.1.  Assigned Numbers for Encryption ............................ 22
-   6.1.1.  EType .................................................... 22
-   6.1.2.  Key Usages ............................................... 22
-
-Yu                         Expires: Jul 2005                    [Page 2]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   6.2.  Which Key to Use ........................................... 23
-   6.3.  EncryptionKey .............................................. 24
-   6.4.  EncryptedData .............................................. 24
-   6.5.  Checksums .................................................. 25
-   6.5.1.  ChecksumOf ............................................... 26
-   6.5.2.  Signed ................................................... 27
-   7.  Tickets ...................................................... 27
-   7.1.  Timestamps ................................................. 28
-   7.2.  Ticket Flags ............................................... 28
-   7.2.1.  Flags Relating to Initial Ticket Acquisition ............. 29
-   7.2.2.  Invalid Tickets .......................................... 29
-   7.2.3.  OK as Delegate ........................................... 30
-   7.2.4.  Renewable Tickets ........................................ 30
-   7.2.5.  Postdated Tickets ........................................ 31
-   7.2.6.  Proxiable and Proxy Tickets .............................. 32
-   7.2.7.  Forwarded and Forwardable Tickets ........................ 33
-   7.3.  Transited Realms ........................................... 34
-   7.4.  Authorization Data ......................................... 34
-   7.4.1.  AD-IF-RELEVANT ........................................... 35
-   7.4.2.  AD-KDCIssued ............................................. 35
-   7.4.3.  AD-AND-OR ................................................ 37
-   7.4.4.  AD-MANDATORY-FOR-KDC ..................................... 37
-   7.5.  Encrypted Part of Ticket ................................... 37
-   7.6.  Cleartext Part of Ticket ................................... 38
-   8.  Credential Acquisition ....................................... 40
-   8.1.  KDC-REQ .................................................... 40
-   8.2.  PA-DATA .................................................... 46
-   8.3.  KDC-REQ Processing ......................................... 46
-   8.3.1.  Handling Replays ......................................... 46
-   8.3.2.  Request Validation ....................................... 47
-   8.3.2.1.  AS-REQ Authentication .................................. 47
-   8.3.2.2.  TGS-REQ Authentication ................................. 47
-   8.3.2.3.  Principal Validation ................................... 47
-   8.3.2.4.  Checking For Revoked or Invalid Tickets ................ 48
-   8.3.3.  Timestamp Handling ....................................... 48
-   8.3.3.1.  AS-REQ Timestamp Processing ............................ 49
-   8.3.3.2.  TGS-REQ Timestamp Processing ........................... 49
-   8.3.4.  Handling Transited Realms ................................ 50
-   8.3.5.  Address Processing ....................................... 50
-   8.3.6.  Ticket Flag Processing ................................... 51
-   8.3.7.  Key Selection ............................................ 52
-   8.3.7.1.  Reply Key and Session Key Selection .................... 52
-   8.3.7.2.  Ticket Key Selection ................................... 52
-   8.4.  KDC-REP .................................................... 52
-   8.5.  Reply Validation ........................................... 55
-   8.6.  IP Transports .............................................. 55
-   8.6.1.  UDP/IP transport ......................................... 55
-   8.6.2.  TCP/IP transport ......................................... 56
-   8.6.3.  KDC Discovery on IP Networks ............................. 57
-   8.6.3.1.  DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 57
-   8.6.3.2.  DNS SRV records for KDC location ....................... 58
-
-Yu                         Expires: Jul 2005                    [Page 3]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP
-                Networks ............................................ 58
-   9.  Errors ....................................................... 58
-   10.  Session Key Exchange ........................................ 61
-   10.1.  AP-REQ .................................................... 61
-   10.2.  AP-REP .................................................... 63
-   11.  Session Key Use ............................................. 65
-   11.1.  KRB-SAFE .................................................. 65
-   11.2.  KRB-PRIV .................................................. 65
-   11.3.  KRB-CRED .................................................. 66
-   12.  Security Considerations ..................................... 67
-   12.1.  Time Synchronization ...................................... 67
-   12.2.  Replays ................................................... 67
-   12.3.  Principal Name Reuse ...................................... 67
-   12.4.  Password Guessing ......................................... 67
-   12.5.  Forward Secrecy ........................................... 67
-   12.6.  Authorization ............................................. 68
-   12.7.  Login Authentication ...................................... 68
-   13.  IANA Considerations ......................................... 68
-   14.  Acknowledgments ............................................. 69
-   Appendices ....................................................... 69
-   A.  ASN.1 Module (Normative) ..................................... 69
-   B.  Kerberos and Character Encodings (Informative) ...............103
-   C.  Kerberos History (Informative) ...............................104
-   D.  Notational Differences from [KCLAR] ..........................105
-   Normative References .............................................106
-   Informative References ...........................................106
-   Author's Address .................................................108
-   Full Copyright Statement .........................................108
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                    [Page 4]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-1.  Introduction
-
-   The Kerberos network authentication protocol is a trusted-third-party
-   protocol utilizing symmetric-key cryptography.  It assumes that all
-   communications between parties in the protocol may be arbitrarily
-   tampered with or monitored, and that the security of the overall
-   system depends only on the effectiveness of the cryptographic
-   techniques and the secrecy of the cryptographic keys used.  The
-   Kerberos protocol authenticates an application client's identity to
-   an application server, and likewise authenticates the application
-   server's identity to the application client.  These assurances are
-   made possible by the client and the server sharing secrets with the
-   trusted third party: the Kerberos server, also known as the Key
-   Distribution Center (KDC).  In addition, the protocol establishes an
-   ephemeral shared secret (the session key) between the client and the
-   server, allowing the protection of further communications between
-   them.
-
-   The Kerberos protocol, as originally specified, provides insufficient
-   means for extending the protocol in a backwards-compatible way.  This
-   deficiency has caused problems for interoperability.  This document
-   describes a framework which enables backwards-compatible extensions
-   to the Kerberos protocol.
-
-1.1.  Kerberos Protocol Overview
-
-   Kerberos comprises three main sub-protocols: credentials acquisition,
-   session key exchange, and session key usage.  A client acquires
-   credentials by asking the KDC for a credential for a service; the KDC
-   issues the credential, which contains a ticket and a session key.
-   The ticket, containing the client's identity, timestamps, expiration
-   time, and a session key, is a encrypted in a key known to the
-   application server.  The KDC encrypts the credential using a key
-   known to the client, and transmits the credential to the client.
-
-   There are two means of requesting credentials: the Authentication
-   Service (AS) exchange, and the Ticket-Granting Service (TGS)
-   exchange.  In the typical AS exchange, a client uses a password-
-   derived key to decrypt the response.  In the TGS exchange, the KDC
-   behaves as an application server; the client authenticates to the TGS
-   by using a Ticket-Granting Ticket (TGT).  The client usually obtains
-   the TGT by using the AS exchange.
-
-   Session key exchange consists of the client transmitting the ticket
-   to the application server, accompanied by an authenticator.  The
-   authenticator contains a timestamp and additional data encrypted
-   using the ticket's session key.  The application server decrypts the
-   ticket, extracting the session key.  The application server then uses
-   the session key to decrypt the authenticator.  Upon successful
-   decryption of the authenticator, the application server knows that
-   the data in the authenticator were sent by the client named in the
-
-Yu                         Expires: Jul 2005                    [Page 5]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   associated ticket.  Additionally, since authenticators expire more
-   quickly than tickets, the application server has some assurance that
-   the transaction is not a replay.  The application server may send an
-   encrypted acknowledgment to the client, verifying its identity to the
-   client.
-
-   Once session key exchange has occurred, the client and server may use
-   the established session key to protect further traffic.  This
-   protection may consist of protection of integrity only, or of
-   protection of confidentiality and integrity.  Additional measures
-   exist for a client to securely forward credentials to a server.
-
-   The entire scheme depends on loosely synchronized clocks.
-   Synchronization of the clock on the KDC with the application server
-   clock allows the application server to accurately determine whether a
-   credential is expired.  Likewise, synchronization of the clock on the
-   client with the application server clock prevents replay attacks
-   utilizing the same credential.  Careful design of the application
-   protocol may allow replay prevention without requiring client-server
-   clock synchronization.
-
-   After establishing a session key, application client and the
-   application server can exchange Kerberos protocol messages that use
-   the session key to protect the integrity or confidentiality of
-   communications between the client and the server.  Additionally, the
-   client may forward credentials to the application server.
-
-   The credentials acquisition protocol takes place over specific,
-   defined transports (UDP and TCP).  Application protocols define which
-   transport to use for the session key establishment protocol and for
-   messages using the session key; the application may choose to perform
-   its own encapsulation of the Kerberos messages, for example.
-
-1.2.  Document Organization
-
-   The remainder of this document begins by describing the general
-   frameworks for protocol extensibility, including whether to interpret
-   unknown extensions as critical.  It then defines the protocol
-   messages and exchanges.
-
-   The definition of the Kerberos protocol uses Abstract Syntax Notation
-   One (ASN.1) [X680], which specifies notation for describing the
-   abstract content of protocol messages.  This document defines a
-   number of base types using ASN.1; these base types subsequently
-   appear in multiple types which define actual protocol messages.
-   Definitions of principal names and of tickets, which are central to
-   the protocol, also appear preceding the protocol message definitions.
-
-
-
-
-
-Yu                         Expires: Jul 2005                    [Page 6]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-2.  Compatibility Considerations
-
-2.1.  Extensibility
-
-   In the past, significant interoperability problems have resulted from
-   conflicting assumptions about how the Kerberos protocol can be
-   extended.  As the deployed base of Kerberos grows, the ability to
-   extend the Kerberos protocol becomes more important.  In order to
-   ensure that vendors and the IETF can extend the protocol while
-   maintaining backwards compatibility, this document outlines a
-   framework for extending Kerberos.
-
-   Kerberos provides two general mechanisms for protocol extensibility.
-   Many protocol messages, including some defined in RFC 1510, contain
-   typed holes--sub-messages containing an octet string along with an
-   integer that identifies how to interpret the octet string.  The
-   integer identifiers are registered centrally, but can be used both
-   for vendor extensions and for extensions standardized in the IETF.
-   This document adds typed holes to a number of messages which
-   previously lacked typed holes.
-
-   Many new messages defined in this document also contain ASN.1
-   extension markers.  These markers allow future revisions of this
-   document to add additional elements to messages, for cases where
-   typed holes are inadequate for some reason.  Because tag numbers and
-   position in a sequence need to be coordinated in order to maintain
-   interoperability, implementations MUST NOT include ASN.1 extensions
-   except when those extensions are specified by IETF standards-track
-   documents.
-
-2.2.  Compatibility with RFC 1510
-
-   Implementations of RFC 1510 did not use extensible ASN.1 types.
-   Sending additional fields not in RFC 1510 to these implementations
-   results in undefined behavior.  Examples of this behavior are known
-   to include discarding messages with no error indications.
-
-   Where messages have been changed since RFC 1510, ASN.1 CHOICE types
-   are used; one alternative of the CHOICE provides a message which is
-   wire-encoding compatible with RFC 1510, and the other alternative
-   provides the new, extensible message.
-
-   Implementations sending new messages MUST ensure that the recipient
-   supports these new messages.  Along with each extensible message is a
-   guideline for when that message MAY be used.  IF that guideline is
-   followed, then the recipient is guaranteed to understand the message.
-
-2.3.  Backwards Compatibility
-
-   This document describes two sets (for the most part) of ASN.1 types.
-   The first set of types is wire-encoding compatible with RFC 1510 and
-
-Yu                         Expires: Jul 2005                    [Page 7]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   [KCLAR].  The second set of types is the set of types enabling
-   extensibility.  This second set may be referred to as
-   "extensibility-enabled types". [ need to make this consistent
-   throughout? ]
-
-   A major difference between the new extensibility-enabled types and
-   the types for RFC 1510 compatibility is that the extensibility-
-   enabled types allow for the use of UTF-8 encodings in various
-   character strings in the protocol.  Each party in the protocol must
-   have some knowledge of the capabilities of the other parties in the
-   protocol.  There are methods for establishing this knowledge without
-   necessarily requiring explicit configuration.
-
-   An extensibility-enabled client can detect whether a KDC supports the
-   extensibility-enabled types by requesting an extensibility-enabled
-   reply.  If the KDC replies with an extensibility-enabled reply, the
-   client knows that the KDC supports extensibility.  If the KDC issues
-   an extensibility-enabled ticket, the client knows that the service
-   named in the ticket is extensibility-enabled.
-
-2.4.  1.4.2. Sending Extensible Messages
-
-   Care must be taken to make sure that old implementations can
-   understand messages sent to them even if they do not understand an
-   extension that is used.  Unless the sender knows the extension is
-   supported, the extension cannot change the semantics of the core
-   message or previously defined extensions.
-
-   For example, an extension including key information necessary to
-   decrypt the encrypted part of a KDC-REP could only be used in
-   situations where the recipient was known to support the extension.
-   Thus when designing such extensions it is important to provide a way
-   for the recipient to notify the sender of support for the extension.
-   For example in the case of an extension that changes the KDC-REP
-   reply key, the client could indicate support for the extension by
-   including a padata element in the AS-REQ sequence.  The KDC should
-   only use the extension if this padata element is present in the AS-
-   REQ.  Even if policy requires the use of the extension, it is better
-   to return an error indicating that the extension is required than to
-   use the extension when the recipient may not support it; debugging
-   why implementations do not interoperate is easier when errors are
-   returned.
-
-2.5.  Criticality
-
-   Recipients of unknown message extensions (including typed holes, new
-   flags, and ASN.1 extension elements) should preserve the encoding of
-   the extension but otherwise ignore the presence of the extension;
-   i.e., unknown extensions SHOULD be treated as non-critical.  If a
-   copy of the message is used later--for example, when a Ticket
-   received in a KDC-REP is later used in an AP-REQ--then the unknown
-
-Yu                         Expires: Jul 2005                    [Page 8]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   extensions MUST be included.
-
-   An implementation SHOULD NOT reject a request merely because it does
-   not understand some element of the request.  As a related
-   consequence, implementations SHOULD handle communicating with other
-   implementations which do not implement some requested options.  This
-   may require designers of options to provide means to determine
-   whether an option has been rejected, not understood, or (perhaps
-   maliciously) deleted or modified in transit.
-
-   There is one exception to non-criticality described above: if an
-   unknown authorization data element is received by a server either in
-   an AP-REQ or in a Ticket contained in an AP-REQ, then the
-   authentication SHOULD fail.  Authorization data is intended to
-   restrict the use of a ticket.  If the service cannot determine
-   whether the restriction applies to that service then a security
-   weakness may result if authentication succeeds.  Authorization
-   elements meant to be truly optional can be enclosed in the AD-IF-
-   RELEVANT element.
-
-   Many RFC 1510 implementations ignore unknown authorization data
-   elements.  Depending on these implementations to honor authorization
-   data restrictions may create a security weakness.
-
-2.6.  Authenticating Cleartext Portions of Messages
-
-   Various denial of service attacks and downgrade attacks against
-   Kerberos are possible unless plaintexts are somehow protected against
-   modification.  An early design goal of Kerberos Version 5 was to
-   avoid encrypting more of the authentication exchange that was
-   required.  (Version 4 doubly-encrypted the encrypted part of a ticket
-   in a KDC reply, for example.)  This minimization of encryption
-   reduces the load on the KDC and busy servers.  Also, during the
-   initial design of Version 5, the existence of legal restrictions on
-   the export of cryptography made it desirable to minimize of the
-   number of uses of encryption in the protocol.  Unfortunately,
-   performing this minimization created numerous instances of
-   unauthenticated security-relevant plaintext fields.
-
-   The extensible variants of the messages described in this document
-   wrap the actual message in an ASN.1 sequence containing a keyed
-   checksum of the contents of the message.  Guidelines in [XXX] section
-   3 specify when the checksum MUST be included and what key MUST be
-   used.  Guidelines on when to include a checksum are never ambiguous:
-   a particular PDU is never correct both with and without a checksum.
-   With the exception of the KRB-ERROR message, receiving
-   implementations MUST reject messages where a checksum is included and
-   not expected or where a checksum is expected but not included.  The
-   receiving implementation does not always have sufficient information
-   to know whether a KRB-ERROR should contain a checksum.  Even so,
-   KRB-ERROR messages with invalid checksums MUST be rejected and
-
-Yu                         Expires: Jul 2005                    [Page 9]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   implementations MAY consider the presence or absence of a checksum
-   when evaluating whether to trust the error.
-
-   This authenticated cleartext protection is provided only in the
-   extensible variants of the messages; it is never used when
-   communicating with an RFC 1510 implementation.
-
-2.7.  Capability Negotiation
-
-   Kerberos is a three-party protocol.  Each of the three parties
-   involved needs a means of detecting the capabilities supported by the
-   others.  Two of the parties, the KDC and the application server, do
-   not communicate directly in the Kerberos protocol.  Communicating
-   capabilities from the KDC to the application server requires using a
-   ticket as an intermediary.
-
-   The main capability requiring negotiation is the support of the
-   extensibility framework described in this document.  Negotiation of
-   this capability while remaining compatible with RFC 1510
-   implementations is possible.  The main complication is that the
-   client needs to know whether the application server supports the
-   extensibility framework prior to sending any message to the
-   application server.  This can be accomplished if the KDC has
-   knowledge of whether an application server supports the extensibility
-   framework.
-
-   Client software advertizes its capabilities when requesting
-   credentials from the KDC.  If the KDC recognizes the capabilities, it
-   acknowledges this fact to the client in its reply.  In addition, if
-   the KDC has knowledge that the application server supports certain
-   capabilities, it also communicates this knowledge to the client in
-   its reply.  The KDC can encode its own capabilities in the ticket so
-   that the application server may discover these capabilities.  The
-   client advertizes its capabilities to the application server when it
-   initiates authentication to the application server.
-
-3.  Use of ASN.1 in Kerberos
-
-   Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
-   Even though ASN.1 theoretically allows the description of protocol
-   messages to be independent of the encoding rules used to encode the
-   messages, Kerberos messages MUST be encoded with DER.  Subtleties in
-   the semantics of the notation, such as whether tags carry any
-   semantic content to the application, may cause the use of other ASN.1
-   encoding rules to be problematic.
-
-   Implementors not using existing ASN.1 tools (e.g., compilers or
-   support libraries) are cautioned to thoroughly read and understand
-   the actual ASN.1 specification to ensure correct implementation
-   behavior.  There is more complexity in the notation than is
-   immediately obvious, and some tutorials and guides to ASN.1 are
-
-Yu                         Expires: Jul 2005                   [Page 10]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   misleading or erroneous.  Recommended tutorials and guides include
-   [Dub00], [Lar99], though there is still no substitute for reading the
-   actual ASN.1 specification.
-
-3.1.  Module Header
-
-   The type definitions in this document assume an ASN.1 module
-   definition of the following form:
-
-      KerberosV5Spec3 {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2) modules(4) krb5spec3(4)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      -- Rest of definitions here
-
-      END
-
-   This specifies that the tagging context for the module will be
-   explicit and that automatic tagging is not done.
-
-   Some other publications [RFC1510] [RFC1964] erroneously specify an
-   object identifier (OID) having an incorrect value of "5" for the
-   "dod" component of the OID.  In the case of RFC 1964, use of the
-   "correct" OID value would result in a change in the wire protocol;
-   therefore, the RFC 1964 OID remains unchanged for now.
-
-3.2.  Top-Level Type
-
-   The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
-   Data Units or PDUs) which an application may directly reference.
-   Applications SHOULD NOT transmit any types other than those which are
-   alternatives of the KRB-PDU CHOICE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 11]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- top-level type
-      --
-      -- Applications should not directly reference any types
-      -- other than KRB-PDU and its component types.
-      --
-      KRB-PDU         ::= CHOICE {
-          ticket      Ticket,
-          as-req      AS-REQ,
-          as-rep      AS-REP,
-          tgs-req     TGS-REQ,
-          tgs-rep     TGS-REP,
-          ap-req      AP-REQ,
-          ap-rep      AP-REP,
-          krb-safe    KRB-SAFE,
-          krb-priv    KRB-PRIV,
-          krb-cred    KRB-CRED,
-          tgt-req     TGT-REQ,
-          krb-error   KRB-ERROR,
-          ...
-      }
-
-
-3.3.  Previously Unused ASN.1 Notation (informative)
-
-   Some aspects of ASN.1 notation used in this document were not used in
-   [KCLAR], and may be unfamiliar to some readers.  This subsection is
-   informative; for normative definitions of the notation, see the
-   actual ASN.1 specifications [X680], [X682], [X683].
-
-3.3.1.  Parameterized Types
-
-   This document uses ASN.1 parameterized types [X683] to make
-   definitions of types more readable.  For some types, some or all of
-   the parameters are advisory, i.e., they are not encoded in any form
-   for transmission in a protocol message.  These advisory parameters
-   can describe implementation behavior associated with the type.
-
-3.3.2.  COMPONENTS OF Notation
-
-   The "COMPONENTS OF" notation, used to define the RFC 1510
-   compatibility types, extracts all of the component types of an ASN.1
-   SEQUENCE type.  The extension marker (the "..." notation) and any
-   extension components are not extracted by "COMPONENTS OF".  The
-   "COMPONENTS OF" notation permits concise definition of multiple types
-   which have many components in common with each other.
-
-3.3.3.  Constraints
-
-   This document uses ASN.1 constraints, including the
-   "UserDefinedConstraint" notation [X682].  Some constraints can be
-   handled automatically by tools that can parse them.  Uses of the
-
-Yu                         Expires: Jul 2005                   [Page 12]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will
-   typically need to have behavior manually coded; the notation provides
-   a formalized way of conveying intended implementation behavior.
-
-   The "WITH COMPONENTS" constraint notation allows constraints to apply
-   to component types of a SEQUENCE type.  This constraint notation
-   effectively allows constraints to "reach into" a type to constrain
-   its component types.
-
-3.4.  New Types
-
-   This document defines a number of ASN.1 types which are new since
-   [KCLAR].  The names of these types will typically have a suffix like
-   "Ext", indicating that the types are intended to support
-   extensibility.  Types original to RFC 1510 and [KCLAR] have been
-   renamed to have a suffix like "1510".  The "Ext" and "1510" types
-   often contain a number of common elements; these common elements have
-   a suffix like "Common".  The "1510" types have various ASN.1
-   constraints applied to them; the constraints limit the possible
-   values of the "1510" types to those permitted by RFC 1510 or by
-   [KCLAR].  The "Ext" types may have different constraints, typically
-   to force string values to be sent as UTF-8.
-
-   For example, consider
-
-      -- example "common" type
-      Foo-Common      ::= SEQUENCE {
-          a           [0] INTEGER,
-          b           [1] OCTET STRING,
-          ...,
-          c           [2] INTEGER,
-          ...
-      }
-
-      -- example "RFC 1510 compatibility" type
-      Foo-1510        ::= SEQUENCE {
-          -- the COMPONENTS OF notation drops the extension marker
-          -- and all extension additions.
-          COMPONENTS OF Foo-Common
-      }
-
-      -- example "extensibility-enabled" type
-      Foo-Ext         ::= Foo-Common
-
-   where "Foo-Common" is a common type used to define both the "1510"
-   and "Ext" versions of a type.  "Foo-1510" is the RFC 1510 version of
-   the type, while "Foo-Ext" is the extensible version.  "Foo-1510" does
-   not contain the extension marker, nor does it contain the extension
-   component "c".  The type "Foo-1510" is equivalent to "Foo-1510-
-   Equiv", shown below.
-
-
-Yu                         Expires: Jul 2005                   [Page 13]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- example type equivalent to Foo-1510
-      Foo-1510-Equiv  ::= SEQUENCE {
-          a           [0] INTEGER,
-          b           [1] OCTET STRING
-      }
-
-
-4.  Basic Types
-
-   These "basic" Kerberos ASN.1 types appear in multiple other Kerberos
-   types.
-
-4.1.  Constrained Integer Types
-
-   In RFC 1510, many types contained references to the unconstrained
-   INTEGER type.  Since an unconstrained INTEGER can contain almost any
-   possible abstract integer value, most of the unconstrained references
-   to INTEGER in RFC 1510 were constrained to 32 bits or smaller in
-   [KCLAR].
-
-      -- signed values representable in 32 bits
-      --
-      -- These are often used as assigned numbers for various things.
-      Int32           ::= INTEGER (-2147483648..2147483647)
-
-   The "Int32" type often contains an assigned number identifying the
-   contents of a typed hole.  Unless otherwise stated, non-negative
-   values are registered, and negative values are available for local
-   use.
-
-      -- unsigned 32 bit values
-      UInt32          ::= INTEGER (0..4294967295)
-
-   The "UInt32" type is used in some places where an unsigned 32-bit
-   integer is needed.
-
-      -- unsigned 64 bit values
-      UInt64          ::= INTEGER (0..18446744073709551615)
-
-   The "UInt64" type is used in places where 32 bits of precision may
-   provide inadequate security.
-
-      -- sequence numbers
-      SeqNum          ::= UInt64
-
-   Sequence numbers were constrained to 32 bits in [KCLAR], but this
-   document allows for 64-bit sequence numbers.
-
-      -- nonces
-      Nonce           ::= UInt64
-
-
-Yu                         Expires: Jul 2005                   [Page 14]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   Likewise, nonces were constrained to 32 bits in [KCLAR], but expanded
-   to 64 bits here.
-
-      -- microseconds
-      Microseconds    ::= INTEGER (0..999999)
-
-   The "microseconds" type is intended to carry the microseconds part of
-   a time value.
-
-4.2.  KerberosTime
-
-      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
-                              -- MUST NOT include fractional seconds
-      })
-
-   The timestamps used in Kerberos are encoded as GeneralizedTimes.  A
-   KerberosTime value MUST NOT include any fractional portions of the
-   seconds.  As required by the DER, it further MUST NOT include any
-   separators, and it specifies the UTC time zone (Z).  Example: The
-   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
-   November 1985 is "19851106210627Z".
-
-4.3.  KerberosString
-
-      -- used for names and for error messages
-      KerberosString  ::= CHOICE {
-          ia5         GeneralString (IA5String),
-          utf8        UTF8String,
-          ...         -- no extension may be sent
-                      -- to an rfc1510 implementation --
-      }
-
-   The KerberosString type is used for character strings in various
-   places in the Kerberos protocol.  For compatibility with RFC 1510,
-   GeneralString values constrained to IA5String (US-ASCII) are
-   permitted in messages exchanged with RFC 1510 implementations.  The
-   new protocol messages contain strings encoded as UTF-8, and these
-   strings MUST be normalized using [SASLPREP].  KerberosString values
-   are present in principal names and in error messages.  Control
-   characters SHOULD NOT be used in principal names, and used with
-   caution in error messages.
-
-      -- IA5 choice only; useful for constraints
-      KerberosStringIA5       ::= KerberosString
-          (WITH COMPONENTS { ia5 PRESENT })
-
-      -- IA5 excluded; useful for constraints
-      KerberosStringExt       ::= KerberosString
-          (WITH COMPONENTS { ia5 ABSENT })
-
-   KerberosStringIA5 requires the use of the "ia5" alternative, while
-
-Yu                         Expires: Jul 2005                   [Page 15]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   KerberosStringExt forbids it.  These types appear in ASN.1
-   constraints on messages.
-
-   For detailed background regarding the history of character string use
-   in Kerberos, as well as discussion of some compatibility issues, see
-   Appendix B.
-
-4.4.  Language Tags
-
-      -- used for language tags
-      LangTag ::= PrintableString
-          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
-
-   The "LangTag" type is used to specify language tags for localization
-   purposes, using the [RFC3066] format.
-
-4.5.  KerberosFlags
-
-   For several message types, a specific constrained bit string type,
-   KerberosFlags, is used.
-
-      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
-          (CONSTRAINED BY {
-          -- MUST be a valid value of -- NamedBits
-          -- but if the value to be sent would be truncated to shorter
-          -- than 32 bits according to DER, the value MUST be padded
-          -- with trailing zero bits to 32 bits.  Otherwise, no
-          -- trailing zero bits may be present.
-
-      })
-
-
-   The actual bit string type encoded in Kerberos messages does not use
-   named bits.  The advisory parameter of the KerberosFlags type names a
-   bit string type defined using named bits, whose value is encoded as
-   if it were a bit string with unnamed bits.  This practice is
-   necessary because the DER require trailing zero bits to be removed
-   when encoding bit strings defined using named bits.  Existing
-   implementations of Kerberos send exactly 32 bits rather than
-   truncating, so the size constraint requires the transmission of at
-   least 32 bits.  Trailing zero bits beyond the first 32 bits are
-   truncated.
-
-4.6.  Typed Holes
-
-      -- Typed hole identifiers
-      TH-id           ::= CHOICE {
-          int32               Int32,
-          rel-oid             RELATIVE-OID
-      }
-
-
-Yu                         Expires: Jul 2005                   [Page 16]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   The "TH-id" type is a generalized means to identify the contents of a
-   typed hole.  The "int32" alternative may be used for simple integer
-   assignments, in the same manner as "Int32", while the "rel-oid"
-   alternative may be used for hierarchical delegation.
-
-4.7.  HostAddress and HostAddresses
-
-      AddrType        ::= Int32
-
-      HostAddress     ::= SEQUENCE  {
-          addr-type   [0] AddrType,
-          address     [1] OCTET STRING
-      }
-
-      -- NOTE: HostAddresses is always used as an OPTIONAL field and
-      -- should not be a zero-length SEQUENCE OF.
-      --
-      -- The extensible messages explicitly constrain this to be
-      -- non-empty.
-      HostAddresses   ::= SEQUENCE OF HostAddress
-
-
-   addr-type
-        This field specifies the type of address that follows.
-
-   address
-        This field encodes a single address of the type identified by
-        "addr-type".
-
-   All negative values for the host address type are reserved for local
-   use.  All non-negative values are reserved for officially assigned
-   type fields and interpretations.
-
-
-      addr-type |     meaning
-      __________|______________
-              2 |   IPv4
-              3 |   directional
-             12 |   DECnet
-             20 |   NetBIOS
-             24 |   IPv6
-
-
-
-4.7.1.  Internet (IPv4) Addresses
-
-   Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
-   MSB order (most significant byte first). The IPv4 loopback address
-   SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is
-   two (2).
-
-
-Yu                         Expires: Jul 2005                   [Page 17]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-4.7.2.  Internet (IPv6) Addresses
-
-   IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, encoded
-   in MSB order (most significant byte first). The type of IPv6
-   addresses is twenty-four (24). The following addresses MUST NOT
-   appear in any Kerberos PDU:
-
-      * the Unspecified Address
-
-      * the Loopback Address
-
-      * Link-Local addresses
-
-   This restriction applies to the inclusion in the address fields of
-   Kerberos PDUs, but not to the address fields of packets that might
-   carry such PDUs.  The restriction is necessary because the use of an
-   address with non-global scope could allow the acceptance of a message
-   sent from a node that may have the same address, but which is not the
-   host intended by the entity that added the restriction.  If the
-   link-local address type needs to be used for communication, then the
-   address restriction in tickets must not be used (i.e. addressless
-   tickets must be used).
-
-   IPv4-mapped IPv6 addresses MUST be represented as addresses of type
-   2.
-
-4.7.3.  DECnet Phase IV addresses
-
-   DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order.
-   The type of DECnet Phase IV addresses is twelve (12).
-
-4.7.4.  Netbios addresses
-
-   Netbios addresses are 16-octet addresses typically composed of 1 to
-   15 alphanumeric characters and padded with the US-ASCII SPC character
-   (code 32).  The 16th octet MUST be the US-ASCII NUL character (code
-   0).  The type of Netbios addresses is twenty (20).
-
-4.7.5.  Directional Addresses
-
-   In many environments, including the sender address in KRB-SAFE and
-   KRB-PRIV messages is undesirable because the addresses may be changed
-   in transport by network address translators. However, if these
-   addresses are removed, the messages may be subject to a reflection
-   attack in which a message is reflected back to its originator. The
-   directional address type provides a way to avoid transport addresses
-   and reflection attacks.  Directional addresses are encoded as four
-   byte unsigned integers in network byte order.  If the message is
-   originated by the party sending the original AP-REQ message, then an
-   address of 0 SHOULD be used. If the message is originated by the
-   party to whom that AP-REQ was sent, then the address 1 SHOULD be
-
-Yu                         Expires: Jul 2005                   [Page 18]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   used.  Applications involving multiple parties can specify the use of
-   other addresses.
-
-   Directional addresses MUST only be used for the sender address field
-   in the KRB-SAFE or KRB-PRIV messages.  They MUST NOT be used as a
-   ticket address or in a AP-REQ message.  This address type SHOULD only
-   be used in situations where the sending party knows that the
-   receiving party supports the address type.  This generally means that
-   directional addresses may only be used when the application protocol
-   requires their support.  Directional addresses are type (3).
-
-5.  Principals
-
-   Principals are participants in the Kerberos protocol.  A "realm"
-   consists of principals in one administrative domain, served by one
-   KDC (or one replicated set of KDCs).  Each principal name has an
-   arbitrary number of components, though typical principal names will
-   only have one or two components.  A principal name is meant to be
-   readable by and meaningful to humans, especially in a realm lacking a
-   centrally adminstered authorization infrastructure.
-
-5.1.  Name Types
-
-   Each PrincipalName has NameType indicating what sort of name it is.
-   The name-type SHOULD be treated as a hint.  Ignoring the name type,
-   no two names can be the same (i.e., at least one of the components,
-   or the realm, must be different).
-
-      -- assigned numbers for name types (used in principal names)
-      NameType        ::= Int32
-
-      -- Name type not known
-      nt-unknown              NameType ::= 0
-      -- Just the name of the principal as in DCE, or for users
-      nt-principal            NameType ::= 1
-      -- Service and other unique instance (krbtgt)
-      nt-srv-inst             NameType ::= 2
-      -- Service with host name as instance (telnet, rcommands)
-      nt-srv-hst              NameType ::= 3
-      -- Service with host as remaining components
-      nt-srv-xhst             NameType ::= 4
-      -- Unique ID
-      nt-uid                  NameType ::= 5
-      -- Encoded X.509 Distingished name [RFC 2253]
-      nt-x500-principal       NameType ::= 6
-      -- Name in form of SMTP email name (e.g. user@foo.com)
-      nt-smtp-name            NameType ::= 7
-      -- Enterprise name - may be mapped to principal name
-      nt-enterprise           NameType ::= 10
-
-
-
-Yu                         Expires: Jul 2005                   [Page 19]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-5.2.  Principal Type Definition
-
-      PrincipalName   ::= SEQUENCE {
-          name-type   [0] NameType,
-          -- May have zero elements, or individual elements may be
-          -- zero-length, but this is NOT RECOMMENDED.
-          name-string [1] SEQUENCE OF KerberosString
-      }
-
-
-   name-type
-        hint of the type of name that follows
-
-   name-string
-        The "name-string" encodes a sequence of components that form a
-        name, each component encoded as a KerberosString.  Taken
-        together, a PrincipalName and a Realm form a principal
-        identifier.  Most PrincipalNames will have only a few components
-        (typically one or two).
-
-5.3.  Principal Name Reuse
-
-   Realm administrators SHOULD use extreme caution when considering
-   reusing a principal name.  A service administrator might explicitly
-   enter principal names into a local access control list (ACL) for the
-   service.  If such local ACLs exist independently of a centrally
-   administered authorization infrastructure, realm administrators
-   SHOULD NOT reuse principal names until confirming that all extant ACL
-   entries referencing that principal name have been updated.  Failure
-   to perform this check can result in a security vulnerability, as a
-   new principal can inadvertently inherit unauthorized privileges upon
-   receiving a reused principal name.  An organization whose Kerberos-
-   authenticated services all use a centrally-adminstered authorization
-   infrastructure may not need to take these precautions regarding
-   principal name reuse.
-
-5.4.  Realm Names
-
-      Realm           ::= KerberosString
-
-      -- IA5 only
-      RealmIA5        ::= Realm (KerberosStringIA5)
-
-      -- IA5 excluded
-      RealmExt        ::= Realm (KerberosStringExt)
-
-
-   Kerberos realm names are KerberosStrings.  Realms MUST NOT contain a
-   character with the code 0 (the US-ASCII NUL).  Most realms will
-   usually consist of several components separated by periods (.), in
-   the style of Internet Domain Names, or separated by slashes (/) in
-
-Yu                         Expires: Jul 2005                   [Page 20]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   the style of X.500 names.
-
-5.5.  Printable Representations of Principal Names
-
-   [ perhaps non-normative? ]
-
-   The printable form of a principal name consists of the concatenation
-   of components of the PrincipalName value using the slash character
-   (/), followed by an at-sign (@), followed by the realm name.  Any
-   occurrence of a backslash (\), slash (/) or at-sign (@) in the
-   PrincipalName value is quoted by a backslash.
-
-5.6.  Ticket-Granting Service Principal
-
-   The PrincipalName value corresponding to a ticket-granting service
-   has two components: the first component is the string "krbtgt", and
-   the second component is the realm name of the TGS which will accept a
-   ticket-granting ticket having this service principal name.  The realm
-   name of service always indicates which realm issued the ticket.  A
-   ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
-   obtaining tickets in the same realm would have the following ASN.1
-   values for its "realm" and "sname" components, respectively:
-
-      -- Example Realm and PrincipalName for a TGS
-
-      tgtRealm1       Realm ::= ia5 : "A.EXAMPLE.COM"
-
-      tgtPrinc1       PrincipalName ::= {
-          name-type nt-srv-inst,
-          name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
-      }
-
-   Its printable representation would be written as
-   "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
-
-5.6.1.  Cross-Realm TGS Principals
-
-   It is possible for a principal in one realm to authenticate to a
-   service in another realm.  A KDC can issue a cross-realm ticket-
-   granting ticket to allow one of its principals to authenticate to a
-   service in a foreign realm.  For example, the TGS principal
-   "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
-   client principal in the realm A.EXAMPLE.COM to authenticate to a
-   service in the realm B.EXAMPLE.COM.  When the KDC for B.EXAMPLE.COM
-   issues a ticket to a client originating in A.EXAMPLE.COM, the
-   client's realm name remains "A.EXAMPLE.COM", even though the service
-   principal will have the realm "B.EXAMPLE.COM".
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 21]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-6.  Types Relating to Encryption
-
-   Many Kerberos protocol messages contain encrypted encodings of
-   various data types.  Some Kerberos protocol messages also contain
-   checksums (signatures) of encodings of various types.
-
-6.1.  Assigned Numbers for Encryption
-
-   Encryption algorithm identifiers and key usages both have assigned
-   numbers, described in [KCRYPTO].
-
-6.1.1.  EType
-
-   EType is the integer type for assigned numbers for encryption
-   algorithms.  Defined in [KCRYPTO].
-
-      -- Assigned numbers denoting encryption mechanisms.
-      EType ::= Int32
-
-      -- assigned numbers for encryption schemes
-      et-des-cbc-crc                  EType ::= 1
-      et-des-cbc-md4                  EType ::= 2
-      et-des-cbc-md5                  EType ::= 3
-      --     [reserved]                         4
-      et-des3-cbc-md5                 EType ::= 5
-      --     [reserved]                         6
-      et-des3-cbc-sha1                EType ::= 7
-      et-dsaWithSHA1-CmsOID           EType ::= 9
-      et-md5WithRSAEncryption-CmsOID  EType ::= 10
-      et-sha1WithRSAEncryption-CmsOID EType ::= 11
-      et-rc2CBC-EnvOID                EType ::= 12
-      et-rsaEncryption-EnvOID         EType ::= 13
-      et-rsaES-OAEP-ENV-OID           EType ::= 14
-      et-des-ede3-cbc-Env-OID         EType ::= 15
-      et-des3-cbc-sha1-kd             EType ::= 16
-      -- AES
-      et-aes128-cts-hmac-sha1-96      EType ::= 17
-      -- AES
-      et-aes256-cts-hmac-sha1-96      EType ::= 18
-      -- Microsoft
-      et-rc4-hmac                     EType ::= 23
-      -- Microsoft
-      et-rc4-hmac-exp                 EType ::= 24
-      -- opaque; PacketCable
-      et-subkey-keymaterial           EType ::= 65
-
-
-6.1.2.  Key Usages
-
-   KeyUsage is the integer type for assigned numbers for key usages.
-   Key usage values are inputs to the encryption and decryption
-
-Yu                         Expires: Jul 2005                   [Page 22]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   functions described in [KCRYPTO].
-
-      -- Assigned numbers denoting key usages.
-      KeyUsage ::= UInt32
-
-      --
-      -- Actual identifier names are provisional and subject to
-      -- change.
-      --
-      ku-pa-enc-ts                    KeyUsage ::= 1
-      ku-Ticket                       KeyUsage ::= 2
-      ku-EncASRepPart                 KeyUsage ::= 3
-      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
-      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
-      ku-pa-TGSReq-cksum              KeyUsage ::= 6
-      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
-      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
-      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
-      ku-Authenticator-cksum          KeyUsage ::= 10
-      ku-APReq-authenticator          KeyUsage ::= 11
-      ku-EncAPRepPart                 KeyUsage ::= 12
-      ku-EncKrbPrivPart               KeyUsage ::= 13
-      ku-EncKrbCredPart               KeyUsage ::= 14
-      ku-KrbSafe-cksum                KeyUsage ::= 15
-      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
-
-
-      -- The following numbers are provisional...
-      -- conflicts may exist elsewhere.
-      ku-Ticket-cksum                 KeyUsage ::= 25
-      ku-ASReq-cksum                  KeyUsage ::= 26
-      ku-TGSReq-cksum                 KeyUsage ::= 27
-      ku-ASRep-cksum                  KeyUsage ::= 28
-      ku-TGSRep-cksum                 KeyUsage ::= 29
-      ku-APReq-cksum                  KeyUsage ::= 30
-      ku-APRep-cksum                  KeyUsage ::= 31
-      ku-KrbCred-cksum                KeyUsage ::= 32
-      ku-KrbError-cksum               KeyUsage ::= 33
-      ku-KDCRep-cksum                 KeyUsage ::= 34
-
-
-6.2.  Which Key to Use
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 23]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- KeyToUse identifies which key is to be used to encrypt or
-      -- sign a given value.
-      --
-      -- Values of KeyToUse are never actually transmitted over the
-      -- wire, or even used directly by the implementation in any
-      -- way, as key usages are; it exists primarily to identify
-      -- which key gets used for what purpose.  Thus, the specific
-      -- numeric values associated with this type are irrelevant.
-      KeyToUse        ::= ENUMERATED {
-          -- unspecified
-          key-unspecified,
-          -- server long term key
-          key-server,
-          -- client long term key
-          key-client,
-          -- key selected by KDC for encryption of a KDC-REP
-          key-kdc-rep,
-          -- session key from ticket
-          key-session,
-          -- subsession key negotiated via AP-REQ/AP-REP
-          key-subsession,
-          ...
-      }
-
-
-6.3.  EncryptionKey
-
-   The "EncryptionKey" type holds an encryption key.
-
-      EncryptionKey   ::= SEQUENCE {
-          keytype     [0] EType,
-          keyvalue    [1] OCTET STRING
-      }
-
-
-   keytype
-        This "EType" identifies the encryption algorithm, described in
-        [KCRYPTO].
-
-   keyvalue
-        Contains the actual key.
-
-6.4.  EncryptedData
-
-   The "EncryptedData" type contains the encryption of another data
-   type.  The recipient uses fields within EncryptedData to determine
-   which key to use for decryption.
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 24]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-
-      -- "Type" specifies which ASN.1 type is encrypted to the
-      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
-      -- keys of which one key may be used to encrypt the data.
-      -- "KeyUsages" specifies a set of key usages, one of which may
-      -- be used to encrypt.
-      --
-      -- None of the parameters is transmitted over the wire.
-      EncryptedData {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          etype       [0] EType,
-          kvno        [1] UInt32 OPTIONAL,
-          cipher      [2] OCTET STRING (CONSTRAINED BY {
-              -- must be encryption of --
-              OCTET STRING (CONTAINING Type),
-              -- with one of the keys -- KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          }),
-          ...
-      }
-
-
-
-   KeyUsages
-        Advisory parameter indicating which key usage to use when
-        encrypting the ciphertext.  If "KeyUsages" indicate multiple
-        "KeyUsage" values, the detailed description of the containing
-        message will indicate which key to use under which conditions.
-
-   Type
-        Advisory parameter indicating the ASN.1 type whose DER encoding
-        is the plaintext encrypted into the EncryptedData.
-
-   Keys
-        Advisory parameter indicating which key to use to perform the
-        encryption.  If "Keys" indicate multiple "KeyToUse" values, the
-        detailed description of the containing message will indicate
-        which key to use under which conditions.
-
-   KeyUsages
-        Advisory parameter indicating which "KeyUsage" value is used to
-        encrypt.  If "KeyUsages" indicates multiple "KeyUsage" values,
-        the detailed description of the containing message will indicate
-        which key usage to use under which conditions.
-
-6.5.  Checksums
-
-   Several types contain checksums (actually signatures) of data.
-
-
-Yu                         Expires: Jul 2005                   [Page 25]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      CksumType       ::= Int32
-
-      -- The parameters specify which key to use to produce the
-      -- signature, as well as which key usage to use.  The
-      -- parameters are not actually sent over the wire.
-      Checksum {
-          KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksumtype   [0] CksumType,
-          checksum    [1] OCTET STRING (CONSTRAINED BY {
-              -- signed using one of the keys --
-              KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          })
-      }
-
-
-   CksumType
-        Integer type for assigned numbers for signature algorithms.
-        Defined in [KCRYPTO]
-
-   Keys
-        As in EncryptedData
-
-   KeyUsages
-        As in EncryptedData
-
-   cksumtype
-        Signature algorithm used to produce the signature.
-
-   checksum
-        The actual checksum.
-
-6.5.1.  ChecksumOf
-
-   ChecksumOf is similar to "Checksum", but specifies which type is
-   signed.
-
-      -- a Checksum that must contain the checksum
-      -- of a particular type
-      ChecksumOf {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
-          ...,
-          checksum (CONSTRAINED BY {
-              -- must be checksum of --
-              OCTET STRING (CONTAINING Type)
-          })
-      })
-
-
-Yu                         Expires: Jul 2005                   [Page 26]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   Type
-        Indicates the ASN.1 type whose DER encoding is signed.
-
-6.5.2.  Signed
-
-   Signed is similar to "ChecksumOf", but contains an actual instance of
-   the type being signed in addition to the signature.
-
-      -- parameterized type for wrapping authenticated plaintext
-      Signed {
-          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksum       [0] ChecksumOf {
-              InnerType, Keys, KeyUsages
-          } OPTIONAL,
-          inner       [1] InnerType,
-          ...
-      }
-
-
-7.  Tickets
-
-   [ A large number of items described here are duplicated in the
-   sections describing KDC-REQ processing.  Should find a way to avoid
-   this duplication. ]
-
-   A ticket binds a principal name to a session key.  The important
-   fields of a ticket are in the encrypted part.  The components in
-   common between the RFC 1510 and the extensible versions are
-
-      EncTicketPartCommon ::= SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] Realm,
-          cname               [3] PrincipalName,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-   crealm
-        This field contains the client's realm.
-
-   cname
-        This field contains the client's name.
-
-Yu                         Expires: Jul 2005                   [Page 27]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   caddr
-        This field lists the network addresses (if absent, all addresses
-        are permitted) from which the ticket is valid.
-
-   Descriptions of the other fields appear in the following sections.
-
-7.1.  Timestamps
-
-   Three of the ticket timestamps may be requested from the KDC.  The
-   timestamps may differ from those requested, depending on site policy.
-
-   authtime
-        The time at which the client authenticated, as recorded by the
-        KDC.
-
-   starttime
-        The earliest time when the ticket is valid.  If not present, the
-        ticket is valid starting at the authtime.  This is requested as
-        the "from" field of KDC-REQ-BODY-COMMON.
-
-   endtime
-        This time is requested in the "till" field of KDC-REQ-BODY-
-        COMMON.  Contains the time after which the ticket will not be
-        honored (its expiration time).  Note that individual services
-        MAY place their own limits on the life of a ticket and MAY
-        reject tickets which have not yet expired.  As such, this is
-        really an upper bound on the expiration time for the ticket.
-
-   renew-till
-        This time is requested in the "rtime" field of KDC-REQ-BODY-
-        COMMON.  It is only present in tickets that have the "renewable"
-        flag set in the flags field.  It indicates the maximum endtime
-        that may be included in a renewal.  It can be thought of as the
-        absolute expiration time for the ticket, including all renewals.
-
-7.2.  Ticket Flags
-
-   A number of flags may be set in the ticket, further defining some of
-   its capabilities.  Some of these flags map to flags in a KDC request.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 28]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
-
-      TicketFlagsBits ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          may-postdate        (5),
-          postdated           (6),
-          invalid             (7),
-          renewable           (8),
-          initial             (9),
-          pre-authent         (10),
-          hw-authent          (11),
-          transited-policy-checked (12),
-          ok-as-delegate      (13),
-          anonymous           (14),
-          cksummed-ticket     (15)
-      }
-
-
-7.2.1.  Flags Relating to Initial Ticket Acquisition
-
-   [ adapted KCLAR 2.1. ]
-
-   Several flags indicate the details of how the initial ticket was
-   acquired.
-
-   initial
-        The "initial" flag indicates that a ticket was issued using the
-        AS protocol, rather than issued based on a ticket-granting
-        ticket.  Application servers (e.g., a password-changing program)
-        requiring a client's definite knowledge of its secret key can
-        insist that this flag be set in any tickets they accept, thus
-        being assured that the client's key was recently presented to
-        the application client.
-
-   pre-authent
-        The "pre-authent" flag indicates that some sort of pre-
-        authentication was used during the AS exchange.
-
-   hw-authent
-        The "hw-authent" flag indicates that some sort of hardware-based
-        pre-authentication occurred during the AS exchange.
-
-   Both the "pre-authent" and the "hw-authent" flags may be present with
-   or without the "initial" flag; such tickets with the "initial" flag
-   clear are ones which are derived from initial tickets with the "pre-
-   authent" or "hw-authent" flags set.
-
-
-Yu                         Expires: Jul 2005                   [Page 29]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-7.2.2.  Invalid Tickets
-
-   [ KCLAR 2.2. ]
-
-   The "invalid" flag indicates that a ticket is invalid.  Application
-   servers MUST reject tickets which have this flag set.  A postdated
-   ticket will be issued in this form.  Invalid tickets MUST be
-   validated by the KDC before use, by presenting them to the KDC in a
-   TGS request with the "validate" option specified.  The KDC will only
-   validate tickets after their starttime has passed.  The validation is
-   required so that postdated tickets which have been stolen before
-   their starttime can be rendered permanently invalid (through a hot-
-   list mechanism -- see Section 8.3.2.4).
-
-7.2.3.  OK as Delegate
-
-   [ KCLAR 2.8. ]
-
-   The "ok-as-delegate" flag provides a way for a KDC to communicate
-   local realm policy to a client regarding whether the service for
-   which the ticket is issued is trusted to accept delegated
-   credentials.  For some applications, a client may need to delegate
-   credentials to a service to act on its behalf in contacting other
-   services.  The ability of a client to obtain a service ticket for a
-   service conveys no information to the client about whether the
-   service should be trusted to accept delegated credentials.
-
-   The copy of the ticket flags visible to the client may have the "ok-
-   as-delegate" flag set to indicate to the client that the service
-   specified in the ticket has been determined by policy of the realm to
-   be a suitable recipient of delegation.  A client can use the presence
-   of this flag to help it make a decision whether to delegate
-   credentials (either grant a proxy or a forwarded ticket-granting
-   ticket) to this service.  It is acceptable to ignore the value of
-   this flag.  When setting this flag, an administrator should consider
-   the security and placement of the server on which the service will
-   run, as well as whether the service requires the use of delegated
-   credentials.
-
-7.2.4.  Renewable Tickets
-
-   [ adapted KCLAR 2.3. ]
-
-   The "renewable" flag indicates whether the ticket may be renewed.
-
-   Renewable tickets can be used to mitigate the consequences of ticket
-   theft.  Applications may desire to hold credentials which can be
-   valid for long periods of time.  However, this can expose the
-   credentials to potential theft for equally long periods, and those
-   stolen credentials would be valid until the expiration time of the
-   ticket(s).  Simply using short-lived tickets and obtaining new ones
-
-Yu                         Expires: Jul 2005                   [Page 30]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   periodically would require the application to have long-term access
-   to the client's secret key, which is an even greater risk.
-
-   Renewable tickets have two "expiration times": the first is when the
-   current instance of the ticket expires, and the second is the latest
-   permissible value for an individual expiration time.  An application
-   client must periodically present an unexpired renewable ticket to the
-   KDC, setting the "renew" option in the KDC request.  The KDC will
-   issue a new ticket with a new session key and a later expiration
-   time.  All other fields of the ticket are left unmodified by the
-   renewal process.  When the latest permissible expiration time
-   arrives, the ticket expires permanently.  At each renewal, the KDC
-   MAY consult a hot-list to determine if the ticket had been reported
-   stolen since its last renewal; it will refuse to renew such stolen
-   tickets, and thus the usable lifetime of stolen tickets is reduced.
-
-   The "renewable" flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can usually be ignored by application
-   servers.  However, some particularly careful application servers MAY
-   disallow renewable tickets.
-
-   If a renewable ticket is not renewed by its expiration time, the KDC
-   will not renew the ticket.  The "renewable" flag is clear by default,
-   but a client can request it be set by setting the "renewable" option
-   in the AS-REQ message.  If it is set, then the "renew-till" field in
-   the ticket contains the time after which the ticket may not be
-   renewed.
-
-7.2.5.  Postdated Tickets
-
-   postdated
-        indicates a ticket which has been postdated
-
-   may-postdate
-        indicates that postdated tickets may be issued based on this
-        ticket
-
-   [ KCLAR 2.4. ]
-
-   Applications may occasionally need to obtain tickets for use much
-   later, e.g., a batch submission system would need tickets to be valid
-   at the time the batch job is serviced.  However, it is dangerous to
-   hold valid tickets in a batch queue, since they will be on-line
-   longer and more prone to theft.  Postdated tickets provide a way to
-   obtain these tickets from the KDC at job submission time, but to
-   leave them "dormant" until they are activated and validated by a
-   further request of the KDC.  If a ticket theft were reported in the
-   interim, the KDC would refuse to validate the ticket, and the thief
-   would be foiled.
-
-
-
-Yu                         Expires: Jul 2005                   [Page 31]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   The "may-postdate" flag in a ticket is normally only interpreted by
-   the TGS.  It can be ignored by application servers.  This flag MUST
-   be set in a ticket-granting ticket in order for the KDC to issue a
-   postdated ticket based on the presented ticket.  It is reset by
-   default; it MAY be requested by a client by setting the "allow-
-   postdate" option in the AS-REQ [?also TGS-REQ?] message.  This flag
-   does not allow a client to obtain a postdated ticket-granting ticket;
-   postdated ticket-granting tickets can only by obtained by requesting
-   the postdating in the AS-REQ message.  The life (endtime minus
-   starttime) of a postdated ticket will be the remaining life of the
-   ticket-granting ticket at the time of the request, unless the
-   "renewable" option is also set, in which case it can be the full life
-   (endtime minus starttime) of the ticket-granting ticket.  The KDC MAY
-   limit how far in the future a ticket may be postdated.
-
-   The "postdated" flag indicates that a ticket has been postdated.  The
-   application server can check the authtime field in the ticket to see
-   when the original authentication occurred.  Some services MAY choose
-   to reject postdated tickets, or they may only accept them within a
-   certain period after the original authentication.  When the KDC
-   issues a "postdated" ticket, it will also be marked as "invalid", so
-   that the application client MUST present the ticket to the KDC for
-   validation before use.
-
-7.2.6.  Proxiable and Proxy Tickets
-
-   proxy
-        indicates a proxy ticket
-
-   proxiable
-        indicates that proxy tickets may be issued based on this ticket
-
-   [ KCLAR 2.5. ]
-
-   It may be necessary for a principal to allow a service to perform an
-   operation on its behalf.  The service must be able to take on the
-   identity of the client, but only for a particular purpose.  A
-   principal can allow a service to take on the principal's identity for
-   a particular purpose by granting it a proxy.
-
-   The process of granting a proxy using the "proxy" and "proxiable"
-   flags is used to provide credentials for use with specific services.
-   Though conceptually also a proxy, users wishing to delegate their
-   identity in a form usable for all purposes MUST use the ticket
-   forwarding mechanism described in the next section to forward a
-   ticket-granting ticket.
-
-   The "proxiable" flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can be ignored by application servers.
-   When set, this flag tells the ticket-granting server that it is OK to
-   issue a new ticket (but not a ticket-granting ticket) with a
-
-Yu                         Expires: Jul 2005                   [Page 32]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   different network address based on this ticket.  This flag is set if
-   requested by the client on initial authentication.  By default, the
-   client will request that it be set when requesting a ticket-granting
-   ticket, and reset when requesting any other ticket.
-
-   This flag allows a client to pass a proxy to a server to perform a
-   remote request on its behalf (e.g. a print service client can give
-   the print server a proxy to access the client's files on a particular
-   file server in order to satisfy a print request).
-
-   In order to complicate the use of stolen credentials, Kerberos
-   tickets may contain a set of network addresses from which they are
-   valid.  When granting a proxy, the client MUST specify the new
-   network address from which the proxy is to be used, or indicate that
-   the proxy is to be issued for use from any address.
-
-   The "proxy" flag is set in a ticket by the TGS when it issues a proxy
-   ticket.  Application servers MAY check this flag and at their option
-   they MAY require additional authentication from the agent presenting
-   the proxy in order to provide an audit trail.
-
-7.2.7.  Forwarded and Forwardable Tickets
-
-   forwarded
-        indicates a forwarded ticket
-
-   forwardable
-        indicates that forwarded tickets may be issued based on this
-        ticket
-
-   [ KCLAR 2.6. ]
-
-   Authentication forwarding is an instance of a proxy where the service
-   that is granted is complete use of the client's identity.  An example
-   where it might be used is when a user logs in to a remote system and
-   wants authentication to work from that system as if the login were
-   local.
-
-   The "forwardable" flag in a ticket is normally only interpreted by
-   the ticket-granting service.  It can be ignored by application
-   servers.  The "forwardable" flag has an interpretation similar to
-   that of the "proxiable" flag, except ticket-granting tickets may also
-   be issued with different network addresses.  This flag is reset by
-   default, but users MAY request that it be set by setting the
-   "forwardable" option in the AS request when they request their
-   initial ticket-granting ticket.
-
-   This flag allows for authentication forwarding without requiring the
-   user to enter a password again.  If the flag is not set, then
-   authentication forwarding is not permitted, but the same result can
-   still be achieved if the user engages in the AS exchange specifying
-
-Yu                         Expires: Jul 2005                   [Page 33]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   the requested network addresses and supplies a password.
-
-   The "forwarded" flag is set by the TGS when a client presents a
-   ticket with the "forwardable" flag set and requests a forwarded
-   ticket by specifying the "forwarded" KDC option and supplying a set
-   of addresses for the new ticket.  It is also set in all tickets
-   issued based on tickets with the "forwarded" flag set.  Application
-   servers may choose to process "forwarded" tickets differently than
-   non-forwarded tickets.
-
-   If addressless tickets are forwarded from one system to another,
-   clients SHOULD still use this option to obtain a new TGT in order to
-   have different session keys on the different systems.
-
-7.3.  Transited Realms
-
-   [ KCLAR 2.7., plus new stuff ]
-
-7.4.  Authorization Data
-
-   [ KCLAR 5.2.6. ]
-
-      ADType          ::= TH-id
-
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-          ad-type             [0] ADType,
-          ad-data             [1] OCTET STRING
-      }
-
-
-   ad-type
-        This field identifies the contents of the ad-data.  All negative
-        values are reserved for local use.  Non-negative values are
-        reserved for registered use.
-
-   ad-data
-        This field contains authorization data to be interpreted
-        according to the value of the corresponding ad-type field.
-
-   Each sequence of ADType and OCTET STRING is referred to as an
-   authorization element.  Elements MAY be application specific,
-   however, there is a common set of recursive elements that should be
-   understood by all implementations.  These elements contain other
-   AuthorizationData, and the interpretation of the encapsulating
-   element determines which enclosed elements must be interpreted, and
-   which may be ignored.
-
-   Depending on the meaning of the encapsulating element, the
-   encapsulated AuthorizationData may be ignored, interpreted as issued
-   directly by the KDC, or be stored in a separate plaintext part of the
-   ticket.  The types of the encapsulating elements are specified as
-
-Yu                         Expires: Jul 2005                   [Page 34]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   part of the Kerberos protocol because behavior based on these
-   container elements should be understood across implementations, while
-   other elements need only be understood by the applications which they
-   affect.
-
-   Authorization data elements are considered critical if present in a
-   ticket or authenticator.  Unless encapsulated in a known
-   authorization data element modifying the criticality of the elements
-   it contains, an application server MUST reject the authentication of
-   a client whose AP-REQ or ticket contains an unrecognized
-   authorization data element.  Authorization data is intended to
-   restrict the use of a ticket.  If the service cannot determine
-   whether it is the target of a restriction, a security weakness may
-   exist if the ticket can be used for that service.  Authorization
-   elements that are truly optional can be enclosed in AD-IF-RELEVANT
-   element.
-
-
-      ad-type |           contents of ad-data
-      ________|_______________________________________
-            1 |   DER encoding of AD-IF-RELEVANT
-            4 |   DER encoding of AD-KDCIssued
-            5 |   DER encoding of AD-AND-OR
-            8 |   DER encoding of AD-MANDATORY-FOR-KDC
-
-
-
-7.4.1.  AD-IF-RELEVANT
-
-      ad-if-relevant          ADType ::= int32 : 1
-
-      -- Encapsulates another AuthorizationData.
-      -- Intended for application servers; receiving application servers
-      -- MAY ignore.
-      AD-IF-RELEVANT          ::= AuthorizationData
-
-   AD elements encapsulated within the if-relevant element are intended
-   for interpretation only by application servers that understand the
-   particular ad-type of the embedded element. Application servers that
-   do not understand the type of an element embedded within the if-
-   relevant element MAY ignore the uninterpretable element. This element
-   promotes interoperability across implementations which may have local
-   extensions for authorization.  The ad-type for AD-IF-RELEVANT is (1).
-
-7.4.2.  AD-KDCIssued
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 35]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- KDC-issued privilege attributes
-      ad-kdcissued            ADType ::= int32 : 4
-
-      AD-KDCIssued            ::= SEQUENCE {
-          ad-checksum [0] ChecksumOf {
-                              AuthorizationData, { key-session },
-                              { ku-ad-KDCIssued-cksum }},
-          i-realm     [1] Realm OPTIONAL,
-          i-sname     [2] PrincipalName OPTIONAL,
-          elements    [3] AuthorizationData
-      }
-
-
-   ad-checksum
-        A cryptographic checksum computed over the DER encoding of the
-        AuthorizationData in the "elements" field, keyed with the
-        session key.  Its checksumtype is the mandatory checksum type
-        for the encryption type of the session key, and its key usage
-        value is 19.
-
-   i-realm, i-sname
-        The name of the issuing principal if different from the KDC
-        itself.  This field would be used when the KDC can verify the
-        authenticity of elements signed by the issuing principal and it
-        allows this KDC to notify the application server of the validity
-        of those elements.
-
-   elements
-        AuthorizationData issued by the KDC.
-
-   The KDC-issued ad-data field is intended to provide a means for
-   Kerberos credentials to embed within themselves privilege attributes
-   and other mechanisms for positive authorization, amplifying the
-   privileges of the principal beyond what it would have if using
-   credentials without such an authorization-data element.
-
-   This amplification of privileges cannot be provided without this
-   element because the definition of the authorization-data field allows
-   elements to be added at will by the bearer of a TGT at the time that
-   they request service tickets and elements may also be added to a
-   delegated ticket by inclusion in the authenticator.
-
-   For KDC-issued elements this is prevented because the elements are
-   signed by the KDC by including a checksum encrypted using the
-   server's key (the same key used to encrypt the ticket -- or a key
-   derived from that key).  AuthorizationData encapsulated with in the
-   AD-KDCIssued element MUST be ignored by the application server if
-   this "signature" is not present.  Further, AuthorizationData
-   encapsulated within this element from a ticket-granting ticket MAY be
-   interpreted by the KDC, and used as a basis according to policy for
-   including new signed elements within derivative tickets, but they
-
-Yu                         Expires: Jul 2005                   [Page 36]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   will not be copied to a derivative ticket directly.  If they are
-   copied directly to a derivative ticket by a KDC that is not aware of
-   this element, the signature will not be correct for the application
-   ticket elements, and the field will be ignored by the application
-   server.
-
-   This element and the elements it encapsulates MAY be safely ignored
-   by applications, application servers, and KDCs that do not implement
-   this element.
-
-   The ad-type for AD-KDC-ISSUED is (4).
-
-7.4.3.  AD-AND-OR
-
-      ad-and-or               ADType ::= int32 : 5
-
-      AD-AND-OR               ::= SEQUENCE {
-          condition-count     [0] INTEGER,
-          elements            [1] AuthorizationData
-      }
-
-
-   When restrictive AD elements are encapsulated within the and-or
-   element, the and-or element is considered satisfied if and only if at
-   least the number of encapsulated elements specified in condition-
-   count are satisfied.  Therefore, this element MAY be used to
-   implement an "or" operation by setting the condition-count field to
-   1, and it MAY specify an "and" operation by setting the condition
-   count to the number of embedded elements. Application servers that do
-   not implement this element MUST reject tickets that contain
-   authorization data elements of this type.
-
-   The ad-type for AD-AND-OR is (5).
-
-7.4.4.  AD-MANDATORY-FOR-KDC
-
-      -- KDCs MUST interpret any AuthorizationData wrapped in this.
-      ad-mandatory-for-kdc            ADType ::= int32 : 8
-      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
-
-   AD elements encapsulated within the mandatory-for-kdc element are to
-   be interpreted by the KDC.  KDCs that do not understand the type of
-   an element embedded within the mandatory-for-kdc element MUST reject
-   the request.
-
-   The ad-type for AD-MANDATORY-FOR-KDC is (8).
-
-7.5.  Encrypted Part of Ticket
-
-   The complete definition of the encrypted part is
-
-
-Yu                         Expires: Jul 2005                   [Page 37]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- Encrypted part of ticket
-      EncTicketPart ::= CHOICE {
-          rfc1510     [APPLICATION 3] EncTicketPart1510,
-          ext         [APPLICATION 5] EncTicketPartExt
-      }
-
-   with the common portion being
-
-      EncTicketPartCommon ::= SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] Realm,
-          cname               [3] PrincipalName,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-   The encrypted part of the backwards-compatibility form of a ticket
-   is:
-
-      EncTicketPart1510 ::= SEQUENCE {
-          COMPONENTS OF EncTicketPartCommon
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-   The encrypted part of the extensible form of a ticket is:
-
-      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          crealm (RealmExt),
-          cname (PrincipalNameExt),
-          -- explicitly constrain caddr to be non-empty if present
-          caddr (SIZE (1..MAX)),
-          -- forbid empty authorization-data encodings
-          authorization-data (SIZE (1..MAX))
-      })
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 38]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-7.6.  Cleartext Part of Ticket
-
-   The complete definition of Ticket is:
-
-      Ticket          ::= CHOICE {
-          rfc1510     [APPLICATION 1] Ticket1510,
-          ext         [APPLICATION 4] Signed {
-              TicketExt, { key-server }, { ku-Ticket-cksum }
-          }
-      }
-
-   with the common portion being:
-
-      -- takes a parameter specifying which type gets encrypted
-      TicketCommon { EncPart } ::= SEQUENCE {
-          tkt-vno     [0] INTEGER (5),
-          realm       [1] Realm,
-          sname       [2] PrincipalName,
-          enc-part    [3] EncryptedData {
-              EncPart, { key-server }, { ku-Ticket }
-          },
-          ...,
-          extensions          [4] TicketExtensions OPTIONAL,
-          ...
-      }
-
-
-   The "sname" field provides the name of the target service principal
-   in cleartext, as a hint to aid the server in choosing the correct
-   decryption key.
-
-   The backwards-compatibility form of Ticket is:
-
-      Ticket1510 ::= SEQUENCE {
-          COMPONENTS OF TicketCommon { EncTicketPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          realm (RealmIA5),
-          sname (PrincipalNameIA5)
-      })
-
-   The extensible form of Ticket is:
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 39]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      TicketExt ::= [APPLICATION 4] TicketCommon {
-          EncTicketPartExt
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          realm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-   TicketExtensions, which may only be present in the extensible form of
-   Ticket, are a cleartext typed hole for extension use.
-   AuthorizationData already provides an encrypted typed hole.
-
-      TEType                  ::= TH-id
-
-      -- ticket extensions: for TicketExt only
-      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          te-type             [0] TEType,
-          te-data             [1] OCTET STRING
-      }
-
-
-   A client will only receive an extensible Ticket if the application
-   server supports extensibility.
-
-8.  Credential Acquisition
-
-   There are two exchanges that can be used for acquiring credentials:
-   the AS exchange and the TGS exchange.  These exchanges have many
-   similarities, and this document describes them in parallel, noting
-   which behaviors are specific to one type of exchange.  The AS request
-   (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
-   (KDC-REQ).  Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
-   are forms of KDC replies (KDC-REP).
-
-   The credentials acquisition protocol operates over specific
-   transports.  Additionally, specific methods exist to permit a client
-   to discover the KDC host with which to communicate.
-
-8.1.  KDC-REQ
-
-   The KDC-REQ has a large number of fields in common between the RFC
-   1510 and the extensible versions.  The KDC-REQ type itself is never
-   directly encoded; it is always a part of a AS-REQ or a TGS-REQ.
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 40]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KDC-REQ-COMMON  ::= SEQUENCE {
-      -- NOTE: first tag is [1], not [0]
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
-                                   | 12 -- TGS-REQ.rfc1510 --
-                                   | 6 -- AS-REQ.ext --
-                                   | 8 -- TGS-REQ.ext -- ),
-          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
-          -- NOTE: not empty
-      }
-
-
-      KDC-REQ-BODY-COMMON     ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalName OPTIONAL
-          -- Used only in AS-REQ --,
-
-          realm               [2] Realm
-          -- Server's realm; also client's in AS-REQ --,
-
-          sname               [3] PrincipalName OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime OPTIONAL
-          -- was required in rfc1510;
-          -- still required for compat versions
-          -- of messages --,
-
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --,
-          ...
-          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
-                              LangTag OPTIONAL,
-          ...
-      }
-
-
-   Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of
-   an EncTicketPartCommon.  The KDC copies most of them unchanged,
-   provided that the requested values meet site policy.
-
-Yu                         Expires: Jul 2005                   [Page 41]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   kdc-options
-        These flags do not correspond directly to "flags" in
-        EncTicketPartCommon.
-
-   cname
-        This field is copied to the "cname" field in
-        EncTicketPartCommon.  The "cname" field is required in an AS-
-        REQ; the client places its own name here.  In a TGS-REQ, the
-        "cname" in the ticket in the AP-REQ takes precedence.
-
-   realm
-        This field is the server's realm, and also holds the client's
-        realm in an AS-REQ.
-
-   sname
-        The "sname" field indicates the server's name.  It may be absent
-        in a TGS-REQ which requests user-to-user authentication, in
-        which case the "sname" of the issued ticket will be taken from
-        the included additional ticket.
-
-   The "from", "till", and "rtime" fields correspond to the "starttime",
-   "endtime", and "renew-till" fields of EncTicketPartCommon.
-
-   addresses
-        This field corresponds to the "caddr" field of
-        EncTicketPartCommon.
-
-   enc-authorization-data
-        For TGS-REQ, this field contains authorization data encrypted
-        using either the TGT session key or the AP-REQ subsession key;
-        the KDC may copy these into the "authorization-data" field of
-        EncTicketPartCommon if policy permits.
-
-   lang-tags
-        Only present in the extensible messages.  Specifies the set of
-        languages which the client is willing to accept in error
-        messages.
-
-   KDC options used in a KDC-REQ are:
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 42]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
-
-      KDCOptionsBits  ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          allow-postdate      (5),
-          postdated           (6),
-          unused7             (7),
-          renewable           (8),
-          unused9             (9),
-          unused10            (10),
-          unused11            (11),
-          unused12            (12),
-          unused13            (13),
-          requestanonymous    (14),
-          canonicalize        (15),
-          disable-transited-check (26),
-          renewable-ok        (27),
-          enc-tkt-in-skey     (28),
-          renew               (30),
-          validate            (31)
-          -- XXX need "need ticket1" flag?
-      }
-
-   Different options apply to different phases of KDC-REQ processing.
-
-   The backwards-compatibility form of a KDC-REQ is:
-
-      KDC-REQ-1510    ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-1510
-      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
-
-   The extensible form of a KDC-REQ is:
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      KDC-REQ-EXT     ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-EXT,
-          ...
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (6 | 8),
-          padata (SIZE (1..MAX))
-      })
-
-   The backwards-compatibility form of a KDC-REQ-BODY is:
-
-Yu                         Expires: Jul 2005                   [Page 43]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KDC-REQ-BODY-1510 ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-BODY-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          cname (PrincipalNameIA5),
-          realm (RealmIA5),
-          sname (PrincipalNameIA5),
-          till PRESENT,
-          nonce (UInt32)
-      })
-
-   The extensible form of a KDC-REQ-BODY is:
-
-      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
-      (WITH COMPONENTS {
-          ...,
-          cname (PrincipalNameExt),
-          realm (RealmExt),
-          sname (PrincipalNameExt),
-          addresses (SIZE (1..MAX)),
-          enc-authorization-data (EncryptedData {
-              AuthorizationData (SIZE (1..MAX)),
-              { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          }),
-          additional-tickets (SIZE (1..MAX))
-      })
-
-   The AS-REQ is:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 44]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      AS-REQ  ::= CHOICE {
-          rfc1510     [APPLICATION 10] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (10),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          }),
-          ext         [APPLICATION 6]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as
-              -- outside, to prevent possible substitution attacks.
-              [APPLICATION 6] KDC-REQ-EXT,
-              -- not sure this is correct key to use; do we even want
-              -- to sign AS-REQ?
-              { key-client },
-              { ku-ASReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (6),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          })
-      }
-
-   A client SHOULD NOT send the extensible AS-REQ alternative to a KDC
-   if the client does not know that the KDC supports the extensibility
-   framework.  A client SHOULD send the extensible AS-REQ alternative in
-   a PA-AS-REQ PA-DATA.  A KDC supporting extensibility will treat the
-   AS-REQ contained within the PA-AS-REQ as the actual AS-REQ.  [ XXX
-   what if their contents conflict? ]
-
-   The TGS-REQ is:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 45]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      TGS-REQ ::= CHOICE {
-          rfc1510     [APPLICATION 12] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (12),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          }),
-          ext         [APPLICATION 8]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as
-              -- outside, to prevent possible substitution attacks.
-              [APPLICATION 8] KDC-REQ-EXT,
-              { key-session }, { ku-TGSReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (8),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          })
-      }
-
-
-8.2.  PA-DATA
-
-   PA-DATA have multiple uses in the Kerberos protocol.  They may pre-
-   authenticate an AS-REQ; they may also modify several of the
-   encryption keys used in a KDC-REP.  PA-DATA may also provide "hints"
-   to the client about which long-term key (usually password-derived) to
-   use.  PA-DATA may also include "hints" about which pre-authentication
-   mechanisms to use, or include data for input into a pre-
-   authentication mechanism.
-
-   [ XXX enumerate standard padata here ]
-
-8.3.  KDC-REQ Processing
-
-   Processing of a KDC-REQ proceeds through several steps.  An
-   implementation need not perform these steps exactly as described, as
-   long as it behaves as if the steps were performed as described.  The
-   KDC performs replay handling upon receiving the request; it then
-   validates the request, adjusts timestamps, and selects the keys used
-   in the reply.  It copies data from the request into the issued
-   ticket, adjusting the values to conform with its policies.  The KDC
-   then transmits the reply to the client.
-
-8.3.1.  Handling Replays
-
-   Because Kerberos can run over unreliable transports such as UDP, the
-   KDC MUST be prepared to retransmit responses in case they are lost.
-   If a KDC receives a request identical to one it has recently
-
-Yu                         Expires: Jul 2005                   [Page 46]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   successfully processed, the KDC MUST respond with a KDC-REP message
-   rather than a replay error.  In order to reduce the amount of
-   ciphertext given to a potential attacker, KDCs MAY send the same
-   response generated when the request was first handled.  KDCs MUST
-   obey this replay behavior even if the actual transport in use is
-   reliable.  If the AP-REQ which authenticates a TGS-REQ is a replay,
-   and the entire request is not identical to a recently successfully
-   processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
-   appropriate for AP-REQ processing.
-
-8.3.2.  Request Validation
-
-8.3.2.1.  AS-REQ Authentication
-
-   Site policy determines whether a given client principal is required
-   to provide some pre-authentication prior to receiving an AS-REP.
-   Since the default reply key is typically the client's long-term
-   password-based key, an attacker may easily request known plaintext
-   (in the form of an AS-REP) upon which to mount a dictionary attack.
-   Pre-authentication can limit the possibility of such an attack.
-
-   If site policy requires pre-authentication for a client principal,
-   and no pre-authentication is provided, the KDC returns the error
-   "kdc-err-preauth-required".  Accompanying this error are "e-data"
-   which include hints telling the client which pre-authentication
-   mechanisms to use, or data for input to pre-authentication mechanisms
-   (e.g., input to challenge-response systems).  If pre-authentication
-   fails, the KDC returns the error "kdc-err-preauth-failed".
-
-   [ may need additional changes based on Sam's preauth draft ]
-
-8.3.2.2.  TGS-REQ Authentication
-
-   A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
-   tgs-req".  The KDC MUST validate the checksum in the Authenticator of
-   the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
-   BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
-   request.  [ padata not signed by authenticator! ] Any error from the
-   AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
-   The service principal in the ticket of the AP-REQ may be a ticket-
-   granting service principal, or a normal application service
-   principal.  A ticket which is not a ticket-granting ticket MUST NOT
-   be used to issue a ticket for any service other than the one named in
-   the ticket.  In this case, the "renew", "validate", or "proxy" [?also
-   forwarded?]  option must be set in the request.
-
-8.3.2.3.  Principal Validation
-
-   If the client principal in an AS-REQ is unknown, the KDC returns the
-   error "kdc-err-c-principal-unknown".  If the server principal in a
-   KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
-
-Yu                         Expires: Jul 2005                   [Page 47]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   unknown".
-
-8.3.2.4.  Checking For Revoked or Invalid Tickets
-
-   [ KCLAR 3.3.3.1 ]
-
-   Whenever a request is made to the ticket-granting server, the
-   presented ticket(s) is(are) checked against a hot-list of tickets
-   which have been canceled.  This hot-list might be implemented by
-   storing a range of issue timestamps for "suspect tickets"; if a
-   presented ticket had an authtime in that range, it would be rejected.
-   In this way, a stolen ticket-granting ticket or renewable ticket
-   cannot be used to gain additional tickets (renewals or otherwise)
-   once the theft has been reported to the KDC for the realm in which
-   the server resides.  Any normal ticket obtained before it was
-   reported stolen will still be valid (because they require no
-   interaction with the KDC), but only until their normal expiration
-   time.  If TGTs have been issued for cross-realm authentication, use
-   of the cross-realm TGT will not be affected unless the hot-list is
-   propagated to the KDCs for the realms for which such cross-realm
-   tickets were issued.
-
-   If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
-   issue any ticket unless the TGS-REQ requests the "validate" option.
-
-8.3.3.  Timestamp Handling
-
-   [ some aspects of timestamp handling, especially regarding postdating
-   and renewal, are difficult to read in KCLAR... needs closer
-   examination here ]
-
-   Processing of "starttime" (requested in the "from" field) differs
-   depending on whether the "postdated" option is set in the request.
-   If the "postdated" option is not set, and the requested "starttime"
-   is in the future beyond the window of acceptable clock skew, the KDC
-   returns the error "kdc-err-cannot-postdate".  If the "postdated"
-   option is not set, and the requested "starttime" is absent or does
-   not indicate a time in the future beyond the acceptable clock skew,
-   the KDC sets the "starttime" to the KDC's current time.  The
-   "postdated" option MUST NOT be honored if the ticket is being
-   requested by TGS-REQ and the "may-postdate" is not set in the TGT.
-   Otherwise, if the "postdated" option is set, and site policy permits,
-   the KDC sets the "starttime" as requested, and sets the "invalid"
-   flag in the new ticket.
-
-   The "till" field is required in the RFC 1510 version of the KDC-REQ.
-   If the "till" field is equal to "19700101000000Z" (midnight, January
-   1, 1970), the KDC SHOULD behave as if the "till" field were absent.
-
-   The KDC MUST NOT issue a ticket whose "starttime", "endtime", or
-   "renew-till" time is later than the "renew-till" time of the ticket
-
-Yu                         Expires: Jul 2005                   [Page 48]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   from which it is derived.
-
-8.3.3.1.  AS-REQ Timestamp Processing
-
-   In the AS exchange, the "authtime" of a ticket is set to the local
-   time at the KDC.
-
-   The "endtime" of the ticket will be set to the earlier of the
-   requested "till" time and a time determined by local policy, possibly
-   determined using factors specific to the realm or principal.  For
-   example, the expiration time MAY be set to the earliest of the
-   following:
-
-      * the expiration time ("till" value) requested
-
-      * the ticket's start time plus the maximum allowable lifetime
-        associated with the client principal from the authentication
-        server's database
-
-      * the ticket's start time plus the maximum allowable lifetime
-        associated with the server principal
-
-      * the ticket's start time plus the maximum lifetime set by the
-        policy of the local realm
-
-   If the requested expiration time minus the start time (as determined
-   above) is less than a site-determined minimum lifetime, an error
-   message with code "kdc-err-never-valid" is returned.  If the
-   requested expiration time for the ticket exceeds what was determined
-   as above, and if the "renewable-ok" option was requested, then the
-   "renewable" flag is set in the new ticket, and the "renew-till" value
-   is set as if the "renewable" option were requested.
-
-   If the "renewable" option has been requested or if the "renewable-ok"
-   option has been set and a renewable ticket is to be issued, then the
-   "renew-till" field MAY be set to the earliest of:
-
-      * its requested value
-
-      * the start time of the ticket plus the minimum of the two maximum
-        renewable lifetimes associated with the principals' database
-        entries
-
-      * the start time of the ticket plus the maximum renewable lifetime
-        set by the policy of the local realm
-
-8.3.3.2.  TGS-REQ Timestamp Processing
-
-   In the TGS exchange, the KDC sets the "authtime" to that of the
-   ticket in the AP-REQ authenticating the TGS-REQ.  [?application
-   server can print a ticket for itself with a spoofed authtime.
-
-Yu                         Expires: Jul 2005                   [Page 49]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   security issues for hot-list?] [ MIT implementation may change
-   authtime of renewed tickets; needs check... ]
-
-   If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ
-   requests an "endtime" (in the "till" field), then the "endtime" of
-   the new ticket is set to the minimum of
-
-      * the requested "endtime" value,
-
-      * the "endtime" in the TGT, and
-
-      * an "endtime" determined by site policy on ticket lifetimes.
-
-   If the new ticket is a renewal, the "endtime" of the new ticket is
-   bounded by the minimum of
-
-      * the requested "endtime" value,
-
-      * the value of the "renew-till" value of the old,
-
-      * the "starttime" of the new ticket plus the lifetime (endtime
-        minus starttime) of the old ticket, i.e., the lifetime of the
-        new ticket may not exceed that of the ticket being renewed [
-        adapted from KCLAR 3.3.3. ], and
-
-      * an "endtime" determined by site policy on ticket lifetimes.
-
-   When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
-   a "starttime", "endtime", or "renew-till" time later than the
-   "renew-till" time of the TGT.
-
-8.3.4.  Handling Transited Realms
-
-   The KDC checks the ticket in a TGS-REQ against site policy, unless
-   the "disable-transited-check" option is set in the TGS-REQ.  If site
-   policy permits the transit path in the TGS-REQ ticket, the KDC sets
-   the "transited-policy-checked" flag in the issued ticket.  If the
-   "disable-transited-check" option is set, the issued ticket will have
-   the "transited-policy-checked" flag cleared.
-
-8.3.5.  Address Processing The requested "addresses" in the KDC-REQ are
-   copied into the issued ticket.  If the "addresses" field is absent or
-   empty in a TGS-REQ, the KDC copies addresses from the ticket in the
-   TGS-REQ into the issued ticket, unless the either "forwarded" or
-   "proxy" option is set.  If the "forwarded" option is set, and the
-   ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies
-   the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the
-   issued ticket.  The KDC behaves similarly if the "proxy" option is
-   set in the TGS-REQ and the "proxiable" flag is set in the ticket.
-   The "proxy" option will not be honored on requests for additional
-   ticket-granting tickets.
-
-Yu                         Expires: Jul 2005                   [Page 50]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-8.3.6.  Ticket Flag Processing
-
-   Many kdc-options request that the KDC set a corresponding flag in the
-   issued ticket.  kdc-options marked with an asterisk (*) in the
-   following table do not directly request the corresponding ticket flag
-   and therefore require special handling.
-
-
-             kdc-option       |    ticket flag affected
-      ________________________|__________________________
-      forwardable             |  forwardable
-      forwarded               |  forwarded
-      proxiable               |  proxiable
-      proxy                   |  proxy
-      allow-postdate          |  may-postdate
-      postdated               |  postdated
-      renewable               |  renewable
-      requestanonymous        |  anonymous
-      canonicalize            |  -
-      disable-transited-check*|  transited-policy-checked
-      renewable-ok*           |  renewable
-      enc-tkt-in-skey         |  -
-      renew                   |  -
-      validate*               |  invalid
-
-
-
-   forwarded
-        The KDC sets the "forwarded" flag in the issued ticket if the
-        "forwarded" option is set in the TGS-REQ and the "forwardable"
-        flag is set in the TGS-REQ ticket.
-
-   proxy
-        The KDC sets the "proxy" flag in the issued ticket if the
-        "proxy" option is set in the TGS-REQ and the "proxiable" flag is
-        set in the TGS-REQ ticket.
-
-   disable-transited-check
-        The handling of the "disable-transited-check" kdc-option is
-        described in Section 8.3.4.
-
-   renewable-ok
-        The handling of the "renewable-ok" kdc-option is described in
-        Section 8.3.3.1.
-
-   enc-tkt-in-skey
-        This flag modifies ticket key selection to use the session key
-        of an additional ticket included in the TGS-REQ, for the purpose
-        of user-to-user authentication.
-
-
-
-Yu                         Expires: Jul 2005                   [Page 51]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   validate
-        If the "validate" kdc-option is set in a TGS-REQ, and the
-        "starttime" has passed, the KDC will clear the "invalid" bit on
-        the ticket before re-issuing it.
-
-8.3.7.  Key Selection
-
-   Three keys are involved in creating a KDC-REP.  The reply key
-   encrypts the encrypted part of the KDC-REP.  The session key is
-   stored in the encrypted part of the ticket, and is also present in
-   the encrypted part of the KDC-REP so that the client can retrieve it.
-   The ticket key is used to encrypt the ticket.  These keys all have
-   initial values for a given exchange; pre-authentication and other
-   extension mechanisms may change the value used for any of these keys.
-
-   [ again, may need changes based on Sam's preauth draft ]
-
-8.3.7.1.  Reply Key and Session Key Selection
-
-   The set of encryption types which the client will understand appears
-   in the "etype" field of KDC-REQ-BODY-COMMON.  The KDC limits the set
-   of possible reply keys and the set of session key encryption types
-   based on the "etype" field.
-
-   For the AS exchange, the reply key is initially a long-term key of
-   the client, limited to those encryption types listed in the "etype"
-   field.  The KDC SHOULD use the first valid strong "etype" for which
-   an encryption key is available.  For the TGS exchange, the reply key
-   is initially the subsession key of the Authenticator.  If the
-   Authenticator subsesion key is absent, the reply key is initially the
-   session key of the ticket used to authenticate the TGS-REQ.
-
-   The session key is initially randomly generated, and has an
-   encryption type which both the client and the server will understand.
-   Typically, the KDC has prior knowledge of which encryption types the
-   server will understand.  It selects the first valid strong "etype"
-   listed the request which the server also will understand.
-
-8.3.7.2.  Ticket Key Selection
-
-   The ticket key is initially the long-term key of the service.  The
-   "enc-tkt-in-skey" option requests user-to-user authentication, where
-   the ticket encryption key of the issued ticket is set equal to the
-   session key of the additional ticket in the request.
-
-8.4.  KDC-REP
-
-   The important parts of the KDC-REP are encrypted.
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 52]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
-      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
-
-      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
-      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
-
-      EncKDCRepPartCom        ::= SEQUENCE {
-          key                 [0] EncryptionKey,
-          last-req            [1] LastReq,
-          nonce               [2] Nonce,
-          key-expiration      [3] KerberosTime OPTIONAL,
-          flags               [4] TicketFlags,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          srealm              [9] Realm,
-          sname               [10] PrincipalName,
-          caddr               [11] HostAddresses OPTIONAL,
-          ...
-      }
-
-      EncKDCRepPart1510       ::= SEQUENCE {
-          COMPONENTS OF EncKDCRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          srealm (RealmIA5),
-          sname (PrincipalNameIA5),
-          nonce UInt32 })
-
-      EncKdcRepPartExt        ::= EncKDCRepPartCom (WITH COMPONENTS {
-          ...,
-          srealm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-   Most of the fields of EncKDCRepPartCom are duplicates of the
-   corresponding fields in the returned ticket.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 53]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
-                                   13 -- TGS.rfc1510 -- |
-                                   7 -- AS-REP.ext -- |
-                                   9 -- TGS-REP.ext -- ),
-          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
-          crealm      [3] Realm,
-          cname       [4] PrincipalName,
-          ticket      [5] Ticket,
-
-          enc-part    [6] EncryptedData {
-              EncPart,
-              { key-reply },
-              -- maybe reach into EncryptedData in AS-REP/TGS-REP
-              -- definitions to apply constraints on key usages?
-              { ku-EncASRepPart -- if AS-REP -- |
-                ku-EncTGSRepPart-subkey -- if TGS-REP and
-                                        -- using Authenticator
-                                        -- session key -- |
-                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
-                                         -- subsession key -- }
-          },
-
-          ...,
-          -- In extensible version, KDC signs original request
-          -- to avoid replay attacks against client.
-          req-cksum   [7] ChecksumOf { CHOICE {
-              as-req          AS-REQ,
-              tgs-req         TGS-REQ
-          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
-          lang-tag    [8] LangTag OPTIONAL,
-          ...
-      }
-
-
-      KDC-REP-1510 { EncPart } ::= SEQUENCE {
-          COMPONENTS OF KDC-REP-COMMON { EncPart }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (11 | 13),
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 54]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
-      (WITH COMPONENTS {
-          ...,
-          msg-type (7 | 9),
-          crealm (RealmExt),
-          cname (PrincipalNameExt)
-      })
-
-
-   req-cksum
-        Signature of the original request using the reply key, to avoid
-        replay attacks against the client, among other things.  Only
-        present in the extensible version of KDC-REP.
-
-           AS-REP          ::= CHOICE {
-               rfc1510     [APPLICATION 11] KDC-REP-1510 {
-                   EncASRepPart1510
-               } (WITH COMPONENTS { ..., msg-type (11) }),
-               ext         [APPLICATION  7]  Signed {
-                   [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
-                   { key-reply }, { ku-ASRep-cksum }
-               } (WITH COMPONENTS { ..., msg-type (7) })
-           }
-
-
-           TGS-REP         ::= CHOICE {
-               rfc1510     [APPLICATION 13] KDC-REP-1510 {
-                   EncTGSRepPart1510
-               } (WITH COMPONENTS { ..., msg-type (13) }),
-               ext         [APPLICATION  9]  Signed {
-                   [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
-                   { key-reply }, { ku-TGSRep-cksum }
-               } (WITH COMPONENTS { ..., msg-type (9) })
-           }
-
-
-   The extensible versions of AS-REQ and TGS-REQ are signed with the
-   reply key, to prevent an attacker from performing a delayed denial-
-   of-service attack by substituting the ticket.
-
-8.5.  Reply Validation
-
-   [ signature verification ]
-
-8.6.  IP Transports
-
-   [ KCLAR 7.2 ]
-
-   Kerberos defines two IP transport mechanisms for the credentials
-   acquisition protocol: UDP/IP and TCP/IP.
-
-
-Yu                         Expires: Jul 2005                   [Page 55]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-8.6.1.  UDP/IP transport
-
-   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
-   requests and SHOULD listen for such requests on port 88 (decimal)
-   unless specifically configured to listen on an alternative UDP port.
-   Alternate ports MAY be used when running multiple KDCs for multiple
-   realms on the same host.
-
-   Kerberos clients supporting IP transports SHOULD support the sending
-   of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to
-   identify the IP address and port to which they will send their
-   request.
-
-   When contacting a KDC for a KRB_KDC_REQ request using UDP/IP
-   transport, the client shall send a UDP datagram containing only an
-   encoding of the request to the KDC. The KDC will respond with a reply
-   datagram containing only an encoding of the reply message (either a
-   KRB-ERROR or a KDC-REP) to the sending port at the sender's IP
-   address. The response to a request made through UDP/IP transport MUST
-   also use UDP/IP transport. If the response can not be handled using
-   UDP (for example because it is too large), the KDC MUST return "krb-
-   err-response-too-big", forcing the client to retry the request using
-   the TCP transport.
-
-8.6.2.  TCP/IP transport
-
-   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
-   requests and SHOULD listen for such requests on port 88 (decimal)
-   unless specifically configured to listen on an alternate TCP port.
-   Alternate ports MAY be used when running multiple KDCs for multiple
-   realms on the same host.
-
-   Clients MUST support the sending of TCP requests, but MAY choose to
-   initially try a request using the UDP transport. Clients SHOULD use
-   KDC discovery (Section 8.6.3) to identify the IP address and port to
-   which they will send their request.
-
-   Implementation note: Some extensions to the Kerberos protocol will
-   not succeed if any client or KDC not supporting the TCP transport is
-   involved.  Implementations of RFC 1510 were not required to support
-   TCP/IP transports.
-
-   When the KDC-REQ message is sent to the KDC over a TCP stream, the
-   response (KDC-REP or KRB-ERROR message) MUST be returned to the
-   client on the same TCP stream that was established for the request.
-   The KDC MAY close the TCP stream after sending a response, but MAY
-   leave the stream open for a reasonable period of time if it expects a
-   followup. Care must be taken in managing TCP/IP connections on the
-   KDC to prevent denial of service attacks based on the number of open
-   TCP/IP connections.
-
-
-Yu                         Expires: Jul 2005                   [Page 56]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   The client MUST be prepared to have the stream closed by the KDC at
-   anytime after the receipt of a response.  A stream closure SHOULD NOT
-   be treated as a fatal error.  Instead, if multiple exchanges are
-   required (e.g., certain forms of pre-authentication) the client may
-   need to establish a new connection when it is ready to send
-   subsequent messages.  A client MAY close the stream after receiving a
-   response, and SHOULD close the stream if it does not expect to send
-   followup messages.
-
-   A client MAY send multiple requests before receiving responses,
-   though it must be prepared to handle the connection being closed
-   after the first response.
-
-   Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over
-   the TCP stream is preceded by the length of the request as 4 octets
-   in network byte order. The high bit of the length is reserved for
-   future expansion and MUST currently be set to zero.  If a KDC that
-   does not understand how to interpret a set high bit of the length
-   encoding receives a request with the high order bit of the length
-   set, it MUST return a KRB-ERROR message with the error "krb-err-
-   field-toolong" and MUST close the TCP stream.
-
-   If multiple requests are sent over a single TCP connection, and the
-   KDC sends multiple responses, the KDC is not required to send the
-   responses in the order of the corresponding requests.  This may
-   permit some implementations to send each response as soon as it is
-   ready even if earlier requests are still being processed (for
-   example, waiting for a response from an external device or database).
-
-8.6.3.  KDC Discovery on IP Networks
-
-   Kerberos client implementations MUST provide a means for the client
-   to determine the location of the Kerberos Key Distribution Centers
-   (KDCs).  Traditionally, Kerberos implementations have stored such
-   configuration information in a file on each client machine.
-   Experience has shown this method of storing configuration information
-   presents problems with out-of-date information and scaling problems,
-   especially when using cross-realm authentication. This section
-   describes a method for using the Domain Name System [RFC 1035] for
-   storing KDC location information.
-
-8.6.3.1.  DNS vs. Kerberos - Case Sensitivity of Realm Names
-
-   In Kerberos, realm names are case sensitive.  While it is strongly
-   encouraged that all realm names be all upper case this recommendation
-   has not been adopted by all sites.  Some sites use all lower case
-   names and other use mixed case.  DNS, on the other hand, is case
-   insensitive for queries.  Since the realm names "MYREALM", "myrealm",
-   and "MyRealm" are all different, but resolve the same in the domain
-   name system, it is necessary that only one of the possible
-   combinations of upper and lower case characters be used in realm
-
-Yu                         Expires: Jul 2005                   [Page 57]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   names.
-
-8.6.3.2.  DNS SRV records for KDC location
-
-   KDC location information is to be stored using the DNS SRV RR [RFC
-   2782].  The format of this RR is as follows:
-
-      _Service._Proto.Realm TTL Class SRV Priority Weight Port Target
-
-   The Service name for Kerberos is always "kerberos".
-
-   The Proto can be one of "udp", "tcp". If these SRV records are to be
-   used, both "udp" and "tcp" records MUST be specified for all KDC
-   deployments.
-
-   The Realm is the Kerberos realm that this record corresponds to.  The
-   realm MUST be a domain style realm name.
-
-   TTL, Class, SRV, Priority, Weight, and Target have the standard
-   meaning as defined in RFC 2782.
-
-   As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
-   records SHOULD be the value assigned to "kerberos" by the Internet
-   Assigned Number Authority: 88 (decimal) unless the KDC is configured
-   to listen on an alternate TCP port.
-
-   Implementation note: Many existing client implementations do not
-   support KDC Discovery and are configured to send requests to the IANA
-   assigned port (88 decimal), so it is strongly recommended that KDCs
-   be configured to listen on that port.
-
-8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP Networks
-
-   These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
-   Kerberos servers, kdc1.example.com and kdc2.example.com.  Queries
-   should be directed to kdc1.example.com first as per the specified
-   priority.  Weights are not used in these sample records.
-
-      _kerberos._udp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
-      _kerberos._udp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
-      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
-      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
-
-
-9.  Errors
-
-   The KRB-ERROR message is returned by the KDC if an error occurs
-   during credentials acquisition.  It may also be returned by an
-   application server if an error occurs during authentication.
-
-
-
-Yu                         Expires: Jul 2005                   [Page 58]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      ErrCode ::= Int32
-
-      KRB-ERROR       ::= CHOICE {
-          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
-          ext         [APPLICATION 23] Signed {
-              KRB-ERROR-EXT, { ku-KrbError-cksum } }
-      }
-
-
-   The extensible KRB-ERROR is only signed if there has been a key
-   negotiated with its recipient.  KRB-ERROR messages sent in response
-   to AS-REQ messages will probably not be signed unless a
-   preauthentication mechanism has negotiated a key.  (Signing using a
-   client's long-term key can expose ciphertext to dictionary attacks.)
-
-   The parts of a KRB-ERROR common to both the backwards-compatibility
-   and the extensibile messages are
-
-      KRB-ERROR-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (30 | 23),
-          ctime       [2] KerberosTime OPTIONAL,
-          cusec       [3] Microseconds OPTIONAL,
-          stime       [4] KerberosTime,
-          susec       [5] Microseconds,
-          error-code  [6] ErrCode,
-          crealm      [7] Realm OPTIONAL,
-          cname       [8] PrincipalName OPTIONAL,
-          realm       [9] Realm -- Correct realm --,
-          sname       [10] PrincipalName -- Correct name --,
-          e-text      [11] KerberosString OPTIONAL,
-          e-data      [12] OCTET STRING OPTIONAL,
-          ...,
-          typed-data          [13] TYPED-DATA OPTIONAL,
-          nonce               [14] Nonce OPTIONAL,
-          lang-tag            [15] LangTag OPTIONAL,
-          ...
-      }
-
-
-      KRB-ERROR-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-ERROR-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (30)
-      })
-
-
-      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
-          (WITH COMPONENTS { ..., msg-type (23) })
-
-
-Yu                         Expires: Jul 2005                   [Page 59]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   ctime, cusec
-        Client's time, if known from a KDC-REQ or AP-REQ.
-
-   stime, susec
-        KDC or application server's current time.
-
-   error-code
-        Numeric error code designating the error.
-
-   crealm, cname
-        Client's realm and name, if known.
-
-   realm, sname
-        server's realm and name. [ XXX what if these aren't known? ]
-
-   e-text
-        Human-readable text providing additional details for the error.
-
-   e-data
-        This field contains additional data about the error for use by
-        the client to help it recover from or handle the error. If the
-        "error-code" is "kdc-err-preauth-required", then the e-data
-        field will contain an encoding of a sequence of padata fields,
-        each corresponding to an acceptable pre-authentication method
-        and optionally containing data for the method:
-
-           METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-
-        For error codes defined in this document other than "kdc-err-
-        preauth-required", the format and contents of the e-data field
-        are implementation-defined.  Similarly, for future error codes,
-        the format and contents of the e-data field are implementation-
-        defined unless specified.
-
-   lang-tag
-        Indicates the language of the message in the "e-text" field.  It
-        is only present in the extensible KRB-ERROR.
-
-   nonce
-        is the nonce from a KDC-REQ.  It is only present in the
-        extensible KRB-ERROR.
-
-   typed-data
-        TYPED-DATA is a typed hole allowing for additional data to be
-        returned in error conditions, since "e-data" is insufficiently
-        flexible for some purposes.  TYPED-DATA is only present in the
-        extensible KRB-ERROR.
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 60]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-           TDType ::= TH-id
-
-           TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-               data-type   [0] TDType,
-               data-value  [1] OCTET STRING OPTIONAL
-           }
-
-
-10.  Session Key Exchange
-
-   Session key exchange consists of the AP-REQ and AP-REP messages.  The
-   client sends the AP-REQ message, and the service responds with an
-   AP-REP message if mutual authentication is desired.  Following
-   session key exchange, the client and service share a secret session
-   key, or possibly a subsesion key, which can be used to protect
-   further communications.  Additionally, the session key exchange
-   process can establish initial sequence numbers which the client and
-   service can use to detect replayed messages.
-
-10.1.  AP-REQ
-
-   An AP-REQ message contains a ticket and a authenticator.  The
-   authenticator is ciphertext encrypted with the session key contained
-   in the ticket.  The plaintext contents of the authenticator are:
-
-      -- plaintext of authenticator
-      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-          authenticator-vno   [0] INTEGER (5),
-          crealm              [1] Realm,
-          cname               [2] PrincipalName,
-          cksum               [3] Checksum {{ key-session },
-              { ku-Authenticator-cksum |
-                ku-pa-TGSReq-cksum }} OPTIONAL,
-          cusec               [4] Microseconds,
-          ctime               [5] KerberosTime,
-          subkey              [6] EncryptionKey OPTIONAL,
-          seq-number          [7] SeqNum OPTIONAL,
-          authorization-data  [8] AuthorizationData OPTIONAL
-      }
-
-   The common parts between the RFC 1510 and the extensible versions of
-   the AP-REQ are:
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 61]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      AP-REQ-COMMON   ::= SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14 | 18),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket,
-          authenticator       [4] EncryptedData {
-              Authenticator,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          },
-          ...,
-          extensions          [5] ApReqExtensions OPTIONAL,
-          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
-                                      OF LangTag OPTIONAL,
-          ...
-      }
-
-   The complete definition of AP-REQ is:
-
-      AP-REQ          ::= CHOICE {
-          rfc1510     [APPLICATION 14] AP-REQ-1510,
-          ext         [APPLICATION 18] Signed {
-              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
-          }
-      }
-
-
-      AP-REQ-COMMON   ::= SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14 | 18),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket,
-          authenticator       [4] EncryptedData {
-              Authenticator,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          },
-          ...,
-          extensions          [5] ApReqExtensions OPTIONAL,
-          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
-                                      OF LangTag OPTIONAL,
-          ...
-      }
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 62]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      AP-REQ-1510 ::= SEQUENCE {
-          COMPONENTS OF AP-REQ-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (14),
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmIA5),
-                  cname (PrincipalNameIA5),
-                  seqnum (UInt32)
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-      AP-REQ-EXT      ::= AP-REQ-COMMON
-      (WITH COMPONENTS {
-          ...,
-          msg-type (18),
-          -- The following constraints on Authenticator assume that
-          -- we want to restrict the use of AP-REQ-EXT with TicketExt
-          -- only, since that is the only way we can enforce UTF-8.
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmExt),
-                  cname (PrincipalNameExt),
-                  authorization-data (SIZE (1..MAX))
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-      APOptions       ::= KerberosFlags { APOptionsBits }
-
-      APOptionsBits ::= BIT STRING {
-          reserved            (0),
-          use-session-key     (1),
-          mutual-required     (2)
-      }
-
-
-10.2.  AP-REP
-
-   An AP-REP message provides mutual authentication of the service to
-   the client.
-
-      EncAPRepPart    ::= CHOICE {
-          rfc1510     [APPLICATION 27] EncAPRepPart1510,
-          ext         [APPLICATION 31] EncAPRepPartExt
-      }
-
-
-Yu                         Expires: Jul 2005                   [Page 63]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      EncAPRepPartCom          ::= SEQUENCE {
-          ctime               [0] KerberosTime,
-          cusec               [1] Microseconds,
-          subkey              [2] EncryptionKey OPTIONAL,
-          seq-number          [3] SeqNum OPTIONAL,
-          ...,
-          authorization-data  [4] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-      EncAPRepPart1510        ::= SEQUENCE {
-          COMPONENTS OF ENCAPRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          seq-number (UInt32),
-          authorization-data ABSENT
-      })
-
-
-      EncAPRepPartExt         ::= EncAPRepPartCom
-
-
-      AP-REP          ::= CHOICE {
-          rfc1510     [APPLICATION 15] AP-REP-1510,
-          ext         [APPLICATION 19] Signed {
-              AP-REP-EXT,
-              { key-session | key-subsession }, { ku-APRep-cksum }}
-      }
-
-
-      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (15 | 19),
-          enc-part    [2] EncryptedData {
-              EncPart,
-              { key-session | key-subsession }, { ku-EncAPRepPart }},
-          ...,
-          extensions          [3] ApRepExtensions OPTIONAL,
-          ...
-      }
-
-
-      AP-REP-1510     ::= SEQUENCE {
-          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (15)
-      })
-
-
-
-Yu                         Expires: Jul 2005                   [Page 64]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
-          EncAPRepPartExt
-      } (WITH COMPONENTS { ..., msg-type (19) })
-
-
-11.  Session Key Use
-
-   Once a session key has been established, the client and server can
-   use several kinds of messages to securely transmit data.  KRB-SAFE
-   provides integrity protection for application data, while KRB-PRIV
-   provides confidentiality along with integrity protection.  The KRB-
-   CRED message provides a means of securely forwarding credentials from
-   the client host to the server host.
-
-11.1.  KRB-SAFE
-
-   The KRB-SAFE message provides integrity protection for an included
-   cleartext message.
-
-      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
-      -- allow us to  make safe-body optional, allowing for a GSS-MIC
-      -- sort of message.
-      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (20),
-          safe-body   [2] KRB-SAFE-BODY,
-          cksum       [3] ChecksumOf {
-              KRB-SAFE-BODY,
-              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-      KRB-SAFE-BODY   ::= SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress,
-          r-address   [5] HostAddress OPTIONAL,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-11.2.  KRB-PRIV
-
-   The KRB-PRIV message provides confidentiality and integrity
-   protection.
-
-
-Yu                         Expires: Jul 2005                   [Page 65]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (21),
-          enc-part    [3] EncryptedData {
-              EncKrbPrivPart,
-              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
-          ...
-      }
-
-
-      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress -- sender's addr --,
-          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-11.3.  KRB-CRED
-
-   The KRB-CRED message provides a means of securely transferring
-   credentials from the client to the service.
-
-      KRB-CRED        ::= CHOICE {
-          rfc1510     [APPLICATION 22] KRB-CRED-1510,
-          ext         [APPLICATION 24] Signed {
-              KRB-CRED-EXT,
-              { key-session | key-subsession }, { ku-KrbCred-cksum }}
-      }
-
-
-      KRB-CRED-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (22 | 24),
-          tickets     [2] SEQUENCE OF Ticket,
-          enc-part    [3] EncryptedData {
-              EncKrbCredPart,
-              { key-session | key-subsession }, { ku-EncKrbCredPart }},
-          ...
-      }
-
-
-      KRB-CRED-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-CRED-COMMON
-      } (WITH COMPONENTS { ..., msg-type (22) })
-
-
-
-Yu                         Expires: Jul 2005                   [Page 66]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
-          (WITH COMPONENTS { ..., msg-type (24) })
-
-
-      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-          ticket-info [0] SEQUENCE OF KrbCredInfo,
-          nonce       [1] Nonce OPTIONAL,
-          timestamp   [2] KerberosTime OPTIONAL,
-          usec        [3] Microseconds OPTIONAL,
-          s-address   [4] HostAddress OPTIONAL,
-          r-address   [5] HostAddress OPTIONAL
-      }
-
-
-      KrbCredInfo     ::= SEQUENCE {
-          key         [0] EncryptionKey,
-          prealm      [1] Realm OPTIONAL,
-          pname       [2] PrincipalName OPTIONAL,
-          flags       [3] TicketFlags OPTIONAL,
-          authtime    [4] KerberosTime OPTIONAL,
-          starttime   [5] KerberosTime OPTIONAL,
-          endtime     [6] KerberosTime OPTIONAL,
-          renew-till  [7] KerberosTime OPTIONAL,
-          srealm      [8] Realm OPTIONAL,
-          sname       [9] PrincipalName OPTIONAL,
-          caddr       [10] HostAddresses OPTIONAL
-      }
-
-
-12.  Security Considerations
-
-12.1.  Time Synchronization
-
-   Time synchronization between the KDC and application servers is
-   necessary to prevent acceptance of expired tickets.
-
-   Time synchronization is needed between application servers and
-   clients to prevent replay attacks if a replay cache is being used.
-   If negotiated subsession keys are used to encrypt application data,
-   replay caches may not be necessary.
-
-12.2.  Replays
-
-12.3.  Principal Name Reuse
-
-   See Section 5.3.
-
-12.4.  Password Guessing
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 67]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-12.5.  Forward Secrecy
-
-   [from KCLAR 10.; needs some rewriting]
-
-   The Kerberos protocol in its basic form does not provide perfect
-   forward secrecy for communications.  If traffic has been recorded by
-   an eavesdropper, then messages encrypted using the KRB-PRIV message,
-   or messages encrypted using application-specific encryption under
-   keys exchanged using Kerberos can be decrypted if any of the user's,
-   application server's, or KDC's key is subsequently discovered.  This
-   is because the session key used to encrypt such messages is
-   transmitted over the network encrypted in the key of the application
-   server, and also encrypted under the session key from the user's
-   ticket-granting ticket when returned to the user in the TGS-REP
-   message.  The session key from the ticket-granting ticket was sent to
-   the user in the AS-REP message encrypted in the user's secret key,
-   and embedded in the ticket-granting ticket, which was encrypted in
-   the key of the KDC.  Application requiring perfect forward secrecy
-   must exchange keys through mechanisms that provide such assurance,
-   but may use Kerberos for authentication of the encrypted channel
-   established through such other means.
-
-12.6.  Authorization
-
-   As an authentication service, Kerberos provides a means of verifying
-   the identity of principals on a network.  Kerberos does not, by
-   itself, provide authorization.  Applications SHOULD NOT accept the
-   mere issuance of a service ticket by the Kerberos server as granting
-   authority to use the service.
-
-12.7.  Login Authentication
-
-   Some applications, particularly those which provide login access when
-   provided with a password, SHOULD NOT treat successful acquisition of
-   credentials as sufficient proof of the user's identity.  An attacker
-   posing as a user could generate an illegitimate KDC-REP message which
-   decrypts properly.  To authenticate a user logging on to a local
-   system, the credentials obtained SHOULD be used in a TGS exchange to
-   obtain credentials for a local service.  Successful use of those
-   credentials to authenticate to the local service assures that the
-   initially obtained credentials are from a valid KDC.
-
-13.  IANA Considerations
-
-   [ needs more work ]
-
-   Each use of Int32 in this document defines a number space.  [ XXX
-   enumerate these ] Negative numbers are reserved for private use;
-   local and experimental extensions should use these values.  Zero is
-   reserved and may not be assigned.
-
-
-Yu                         Expires: Jul 2005                   [Page 68]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   Typed hole contents may be identified by either Int32 values or by
-   RELATIVE-OID values.  Since RELATIVE-OIDs define a hierarchical
-   namespace, assignments to the top level of the RELATIVE-OID space may
-   be made on a first-come, first-served basis.
-
-14.  Acknowledgments
-
-   Much of the text here is adapted from draft-ietf-krb-wg-kerberos-
-   clarifications-07.  The description of the general form of the
-   extensibility framework was derived from text by Sam Hartman.
-
-Appendices
-
-A.  ASN.1 Module (Normative)
-
-      KerberosV5Spec3 {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2) modules(4) krb5spec3(4)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-
-      -- OID arc for KerberosV5
-      --
-      -- This OID may be used to identify Kerberos protocol messages
-      -- encapsulated in other protocols.
-      --
-      -- This OID also designates the OID arc for KerberosV5-related
-      -- OIDs.
-      --
-      -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
-      -- OID.
-      id-krb5         OBJECT IDENTIFIER ::= {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2)
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 69]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- top-level type
-      --
-      -- Applications should not directly reference any types
-      -- other than KRB-PDU and its component types.
-      --
-      KRB-PDU         ::= CHOICE {
-          ticket      Ticket,
-          as-req      AS-REQ,
-          as-rep      AS-REP,
-          tgs-req     TGS-REQ,
-          tgs-rep     TGS-REP,
-          ap-req      AP-REQ,
-          ap-rep      AP-REP,
-          krb-safe    KRB-SAFE,
-          krb-priv    KRB-PRIV,
-          krb-cred    KRB-CRED,
-          tgt-req     TGT-REQ,
-          krb-error   KRB-ERROR,
-          ...
-      }
-
-
-      --
-      -- *** basic types
-      --
-
-
-      -- signed values representable in 32 bits
-      --
-      -- These are often used as assigned numbers for various things.
-      Int32           ::= INTEGER (-2147483648..2147483647)
-
-
-      -- Typed hole identifiers
-      TH-id           ::= CHOICE {
-          int32               Int32,
-          rel-oid             RELATIVE-OID
-      }
-
-
-      -- unsigned 32 bit values
-      UInt32          ::= INTEGER (0..4294967295)
-
-
-      -- unsigned 64 bit values
-      UInt64          ::= INTEGER (0..18446744073709551615)
-
-
-      -- sequence numbers
-      SeqNum          ::= UInt64
-
-
-Yu                         Expires: Jul 2005                   [Page 70]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- nonces
-      Nonce           ::= UInt64
-
-
-      -- microseconds
-      Microseconds    ::= INTEGER (0..999999)
-
-
-      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
-                              -- MUST NOT include fractional seconds
-      })
-
-
-      -- used for names and for error messages
-      KerberosString  ::= CHOICE {
-          ia5         GeneralString (IA5String),
-          utf8        UTF8String,
-          ...         -- no extension may be sent
-                      -- to an rfc1510 implementation --
-      }
-
-
-      -- IA5 choice only; useful for constraints
-      KerberosStringIA5       ::= KerberosString
-          (WITH COMPONENTS { ia5 PRESENT })
-
-      -- IA5 excluded; useful for constraints
-      KerberosStringExt       ::= KerberosString
-          (WITH COMPONENTS { ia5 ABSENT })
-
-
-      -- used for language tags
-      LangTag ::= PrintableString
-          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 71]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- assigned numbers for name types (used in principal names)
-      NameType        ::= Int32
-
-      -- Name type not known
-      nt-unknown              NameType ::= 0
-      -- Just the name of the principal as in DCE, or for users
-      nt-principal            NameType ::= 1
-      -- Service and other unique instance (krbtgt)
-      nt-srv-inst             NameType ::= 2
-      -- Service with host name as instance (telnet, rcommands)
-      nt-srv-hst              NameType ::= 3
-      -- Service with host as remaining components
-      nt-srv-xhst             NameType ::= 4
-      -- Unique ID
-      nt-uid                  NameType ::= 5
-      -- Encoded X.509 Distingished name [RFC 2253]
-      nt-x500-principal       NameType ::= 6
-      -- Name in form of SMTP email name (e.g. user@foo.com)
-      nt-smtp-name            NameType ::= 7
-      -- Enterprise name - may be mapped to principal name
-      nt-enterprise           NameType ::= 10
-
-
-      PrincipalName   ::= SEQUENCE {
-          name-type   [0] NameType,
-          -- May have zero elements, or individual elements may be
-          -- zero-length, but this is NOT RECOMMENDED.
-          name-string [1] SEQUENCE OF KerberosString
-      }
-
-
-      -- IA5 only
-      PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS {
-          ...,
-          name-string (WITH COMPONENT (KerberosStringIA5))
-      })
-
-      -- IA5 excluded
-      PrincipalNameExt ::= PrincpalName (WITH COMPONENTS {
-          ...,
-          name-string (WITH COMPONENT (KerberosStringExt))
-      })
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 72]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      Realm           ::= KerberosString
-
-      -- IA5 only
-      RealmIA5        ::= Realm (KerberosStringIA5)
-
-      -- IA5 excluded
-      RealmExt        ::= Realm (KerberosStringExt)
-
-
-      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
-          (CONSTRAINED BY {
-          -- MUST be a valid value of -- NamedBits
-          -- but if the value to be sent would be truncated to shorter
-          -- than 32 bits according to DER, the value MUST be padded
-          -- with trailing zero bits to 32 bits.  Otherwise, no
-          -- trailing zero bits may be present.
-
-      })
-
-
-      AddrType        ::= Int32
-
-      HostAddress     ::= SEQUENCE  {
-          addr-type   [0] AddrType,
-          address     [1] OCTET STRING
-      }
-
-      -- NOTE: HostAddresses is always used as an OPTIONAL field and
-      -- should not be a zero-length SEQUENCE OF.
-      --
-      -- The extensible messages explicitly constrain this to be
-      -- non-empty.
-      HostAddresses   ::= SEQUENCE OF HostAddress
-
-
-      --
-      -- *** crypto-related types and assignments
-      --
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 73]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- Assigned numbers denoting encryption mechanisms.
-      EType ::= Int32
-
-      -- assigned numbers for encryption schemes
-      et-des-cbc-crc                  EType ::= 1
-      et-des-cbc-md4                  EType ::= 2
-      et-des-cbc-md5                  EType ::= 3
-      --     [reserved]                         4
-      et-des3-cbc-md5                 EType ::= 5
-      --     [reserved]                         6
-      et-des3-cbc-sha1                EType ::= 7
-      et-dsaWithSHA1-CmsOID           EType ::= 9
-      et-md5WithRSAEncryption-CmsOID  EType ::= 10
-      et-sha1WithRSAEncryption-CmsOID EType ::= 11
-      et-rc2CBC-EnvOID                EType ::= 12
-      et-rsaEncryption-EnvOID         EType ::= 13
-      et-rsaES-OAEP-ENV-OID           EType ::= 14
-      et-des-ede3-cbc-Env-OID         EType ::= 15
-      et-des3-cbc-sha1-kd             EType ::= 16
-      -- AES
-      et-aes128-cts-hmac-sha1-96      EType ::= 17
-      -- AES
-      et-aes256-cts-hmac-sha1-96      EType ::= 18
-      -- Microsoft
-      et-rc4-hmac                     EType ::= 23
-      -- Microsoft
-      et-rc4-hmac-exp                 EType ::= 24
-      -- opaque; PacketCable
-      et-subkey-keymaterial           EType ::= 65
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 74]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- Assigned numbers denoting key usages.
-      KeyUsage ::= UInt32
-
-      --
-      -- Actual identifier names are provisional and subject to
-      -- change.
-      --
-      ku-pa-enc-ts                    KeyUsage ::= 1
-      ku-Ticket                       KeyUsage ::= 2
-      ku-EncASRepPart                 KeyUsage ::= 3
-      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
-      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
-      ku-pa-TGSReq-cksum              KeyUsage ::= 6
-      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
-      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
-      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
-      ku-Authenticator-cksum          KeyUsage ::= 10
-      ku-APReq-authenticator          KeyUsage ::= 11
-      ku-EncAPRepPart                 KeyUsage ::= 12
-      ku-EncKrbPrivPart               KeyUsage ::= 13
-      ku-EncKrbCredPart               KeyUsage ::= 14
-      ku-KrbSafe-cksum                KeyUsage ::= 15
-      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
-
-
-      -- The following numbers are provisional...
-      -- conflicts may exist elsewhere.
-      ku-Ticket-cksum                 KeyUsage ::= 25
-      ku-ASReq-cksum                  KeyUsage ::= 26
-      ku-TGSReq-cksum                 KeyUsage ::= 27
-      ku-ASRep-cksum                  KeyUsage ::= 28
-      ku-TGSRep-cksum                 KeyUsage ::= 29
-      ku-APReq-cksum                  KeyUsage ::= 30
-      ku-APRep-cksum                  KeyUsage ::= 31
-      ku-KrbCred-cksum                KeyUsage ::= 32
-      ku-KrbError-cksum               KeyUsage ::= 33
-      ku-KDCRep-cksum                 KeyUsage ::= 34
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 75]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- KeyToUse identifies which key is to be used to encrypt or
-      -- sign a given value.
-      --
-      -- Values of KeyToUse are never actually transmitted over the
-      -- wire, or even used directly by the implementation in any
-      -- way, as key usages are; it exists primarily to identify
-      -- which key gets used for what purpose.  Thus, the specific
-      -- numeric values associated with this type are irrelevant.
-      KeyToUse        ::= ENUMERATED {
-          -- unspecified
-          key-unspecified,
-          -- server long term key
-          key-server,
-          -- client long term key
-          key-client,
-          -- key selected by KDC for encryption of a KDC-REP
-          key-kdc-rep,
-          -- session key from ticket
-          key-session,
-          -- subsession key negotiated via AP-REQ/AP-REP
-          key-subsession,
-          ...
-      }
-
-
-      EncryptionKey   ::= SEQUENCE {
-          keytype     [0] EType,
-          keyvalue    [1] OCTET STRING
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 76]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-
-      -- "Type" specifies which ASN.1 type is encrypted to the
-      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
-      -- keys of which one key may be used to encrypt the data.
-      -- "KeyUsages" specifies a set of key usages, one of which may
-      -- be used to encrypt.
-      --
-      -- None of the parameters is transmitted over the wire.
-      EncryptedData {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          etype       [0] EType,
-          kvno        [1] UInt32 OPTIONAL,
-          cipher      [2] OCTET STRING (CONSTRAINED BY {
-              -- must be encryption of --
-              OCTET STRING (CONTAINING Type),
-              -- with one of the keys -- KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          }),
-          ...
-      }
-
-
-
-      CksumType       ::= Int32
-
-      -- The parameters specify which key to use to produce the
-      -- signature, as well as which key usage to use.  The
-      -- parameters are not actually sent over the wire.
-      Checksum {
-          KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksumtype   [0] CksumType,
-          checksum    [1] OCTET STRING (CONSTRAINED BY {
-              -- signed using one of the keys --
-              KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          })
-      }
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 77]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- a Checksum that must contain the checksum
-      -- of a particular type
-      ChecksumOf {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
-          ...,
-          checksum (CONSTRAINED BY {
-              -- must be checksum of --
-              OCTET STRING (CONTAINING Type)
-          })
-      })
-
-
-      -- parameterized type for wrapping authenticated plaintext
-      Signed {
-          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksum       [0] ChecksumOf {
-              InnerType, Keys, KeyUsages
-          } OPTIONAL,
-          inner       [1] InnerType,
-          ...
-      }
-
-
-      --
-      -- *** Tickets
-      --
-
-
-      Ticket          ::= CHOICE {
-          rfc1510     [APPLICATION 1] Ticket1510,
-          ext         [APPLICATION 4] Signed {
-              TicketExt, { key-server }, { ku-Ticket-cksum }
-          }
-      }
-
-
-      -- takes a parameter specifying which type gets encrypted
-      TicketCommon { EncPart } ::= SEQUENCE {
-          tkt-vno     [0] INTEGER (5),
-          realm       [1] Realm,
-          sname       [2] PrincipalName,
-          enc-part    [3] EncryptedData {
-              EncPart, { key-server }, { ku-Ticket }
-          },
-          ...,
-          extensions          [4] TicketExtensions OPTIONAL,
-          ...
-      }
-
-
-Yu                         Expires: Jul 2005                   [Page 78]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      Ticket1510 ::= SEQUENCE {
-          COMPONENTS OF TicketCommon { EncTicketPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          realm (RealmIA5),
-          sname (PrincipalNameIA5)
-      })
-
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      TicketExt ::= [APPLICATION 4] TicketCommon {
-          EncTicketPartExt
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          realm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-      -- Encrypted part of ticket
-      EncTicketPart ::= CHOICE {
-          rfc1510     [APPLICATION 3] EncTicketPart1510,
-          ext         [APPLICATION 5] EncTicketPartExt
-      }
-
-
-      EncTicketPartCommon ::= SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] Realm,
-          cname               [3] PrincipalName,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 79]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      EncTicketPart1510 ::= SEQUENCE {
-          COMPONENTS OF EncTicketPartCommon
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-
-      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          crealm (RealmExt),
-          cname (PrincipalNameExt),
-          -- explicitly constrain caddr to be non-empty if present
-          caddr (SIZE (1..MAX)),
-          -- forbid empty authorization-data encodings
-          authorization-data (SIZE (1..MAX))
-      })
-
-
-      --
-      -- *** Authorization Data
-      --
-
-
-      ADType          ::= TH-id
-
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-          ad-type             [0] ADType,
-          ad-data             [1] OCTET STRING
-      }
-
-
-      ad-if-relevant          ADType ::= int32 : 1
-
-      -- Encapsulates another AuthorizationData.
-      -- Intended for application servers; receiving application servers
-      -- MAY ignore.
-      AD-IF-RELEVANT          ::= AuthorizationData
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 80]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- KDC-issued privilege attributes
-      ad-kdcissued            ADType ::= int32 : 4
-
-      AD-KDCIssued            ::= SEQUENCE {
-          ad-checksum [0] ChecksumOf {
-                              AuthorizationData, { key-session },
-                              { ku-ad-KDCIssued-cksum }},
-          i-realm     [1] Realm OPTIONAL,
-          i-sname     [2] PrincipalName OPTIONAL,
-          elements    [3] AuthorizationData
-      }
-
-
-      ad-and-or               ADType ::= int32 : 5
-
-      AD-AND-OR               ::= SEQUENCE {
-          condition-count     [0] INTEGER,
-          elements            [1] AuthorizationData
-      }
-
-
-      -- KDCs MUST interpret any AuthorizationData wrapped in this.
-      ad-mandatory-for-kdc            ADType ::= int32 : 8
-      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
-
-
-      TrType                  ::= TH-id -- must be registered
-
-      -- encoded Transited field
-      TransitedEncoding       ::= SEQUENCE {
-          tr-type     [0] TrType,
-          contents    [1] OCTET STRING
-      }
-
-
-      TEType                  ::= TH-id
-
-      -- ticket extensions: for TicketExt only
-      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          te-type             [0] TEType,
-          te-data             [1] OCTET STRING
-      }
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 81]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
-
-      TicketFlagsBits ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          may-postdate        (5),
-          postdated           (6),
-          invalid             (7),
-          renewable           (8),
-          initial             (9),
-          pre-authent         (10),
-          hw-authent          (11),
-          transited-policy-checked (12),
-          ok-as-delegate      (13),
-          anonymous           (14),
-          cksummed-ticket     (15)
-      }
-
-
-      --
-      -- *** KDC protocol
-      --
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 82]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      AS-REQ  ::= CHOICE {
-          rfc1510     [APPLICATION 10] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (10),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          }),
-          ext         [APPLICATION 6]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as
-              -- outside, to prevent possible substitution attacks.
-              [APPLICATION 6] KDC-REQ-EXT,
-              -- not sure this is correct key to use; do we even want
-              -- to sign AS-REQ?
-              { key-client },
-              { ku-ASReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (6),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          })
-      }
-
-
-      TGS-REQ ::= CHOICE {
-          rfc1510     [APPLICATION 12] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (12),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          }),
-          ext         [APPLICATION 8]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as
-              -- outside, to prevent possible substitution attacks.
-              [APPLICATION 8] KDC-REQ-EXT,
-              { key-session }, { ku-TGSReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (8),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          })
-      }
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 83]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KDC-REQ-COMMON  ::= SEQUENCE {
-      -- NOTE: first tag is [1], not [0]
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
-                                   | 12 -- TGS-REQ.rfc1510 --
-                                   | 6 -- AS-REQ.ext --
-                                   | 8 -- TGS-REQ.ext -- ),
-          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
-          -- NOTE: not empty
-      }
-
-
-      KDC-REQ-1510    ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-1510
-      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
-
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      KDC-REQ-EXT     ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-EXT,
-          ...
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (6 | 8),
-          padata (SIZE (1..MAX))
-      })
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 84]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KDC-REQ-BODY-COMMON     ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalName OPTIONAL
-          -- Used only in AS-REQ --,
-
-          realm               [2] Realm
-          -- Server's realm; also client's in AS-REQ --,
-
-          sname               [3] PrincipalName OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime OPTIONAL
-          -- was required in rfc1510;
-          -- still required for compat versions
-          -- of messages --,
-
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --,
-          ...
-          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
-                              LangTag OPTIONAL,
-          ...
-      }
-
-
-      KDC-REQ-BODY-1510 ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-BODY-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          cname (PrincipalNameIA5),
-          realm (RealmIA5),
-          sname (PrincipalNameIA5),
-          till PRESENT,
-          nonce (UInt32)
-      })
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 85]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
-      (WITH COMPONENTS {
-          ...,
-          cname (PrincipalNameExt),
-          realm (RealmExt),
-          sname (PrincipalNameExt),
-          addresses (SIZE (1..MAX)),
-          enc-authorization-data (EncryptedData {
-              AuthorizationData (SIZE (1..MAX)),
-              { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          }),
-          additional-tickets (SIZE (1..MAX))
-      })
-
-
-      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
-
-      KDCOptionsBits  ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          allow-postdate      (5),
-          postdated           (6),
-          unused7             (7),
-          renewable           (8),
-          unused9             (9),
-          unused10            (10),
-          unused11            (11),
-          unused12            (12),
-          unused13            (13),
-          requestanonymous    (14),
-          canonicalize        (15),
-          disable-transited-check (26),
-          renewable-ok        (27),
-          enc-tkt-in-skey     (28),
-          renew               (30),
-          validate            (31)
-          -- XXX need "need ticket1" flag?
-      }
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 86]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      AS-REP          ::= CHOICE {
-          rfc1510     [APPLICATION 11] KDC-REP-1510 {
-              EncASRepPart1510
-          } (WITH COMPONENTS { ..., msg-type (11) }),
-          ext         [APPLICATION  7]  Signed {
-              [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
-              { key-reply }, { ku-ASRep-cksum }
-          } (WITH COMPONENTS { ..., msg-type (7) })
-      }
-
-
-      TGS-REP         ::= CHOICE {
-          rfc1510     [APPLICATION 13] KDC-REP-1510 {
-              EncTGSRepPart1510
-          } (WITH COMPONENTS { ..., msg-type (13) }),
-          ext         [APPLICATION  9]  Signed {
-              [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
-              { key-reply }, { ku-TGSRep-cksum }
-          } (WITH COMPONENTS { ..., msg-type (9) })
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 87]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
-                                   13 -- TGS.rfc1510 -- |
-                                   7 -- AS-REP.ext -- |
-                                   9 -- TGS-REP.ext -- ),
-          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
-          crealm      [3] Realm,
-          cname       [4] PrincipalName,
-          ticket      [5] Ticket,
-
-          enc-part    [6] EncryptedData {
-              EncPart,
-              { key-reply },
-              -- maybe reach into EncryptedData in AS-REP/TGS-REP
-              -- definitions to apply constraints on key usages?
-              { ku-EncASRepPart -- if AS-REP -- |
-                ku-EncTGSRepPart-subkey -- if TGS-REP and
-                                        -- using Authenticator
-                                        -- session key -- |
-                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
-                                         -- subsession key -- }
-          },
-
-          ...,
-          -- In extensible version, KDC signs original request
-          -- to avoid replay attacks against client.
-          req-cksum   [7] ChecksumOf { CHOICE {
-              as-req          AS-REQ,
-              tgs-req         TGS-REQ
-          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
-          lang-tag    [8] LangTag OPTIONAL,
-          ...
-      }
-
-
-      KDC-REP-1510 { EncPart } ::= SEQUENCE {
-          COMPONENTS OF KDC-REP-COMMON { EncPart }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (11 | 13),
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 88]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
-      (WITH COMPONENTS {
-          ...,
-          msg-type (7 | 9),
-          crealm (RealmExt),
-          cname (PrincipalNameExt)
-      })
-
-
-      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
-      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
-
-      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
-      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
-
-      EncKDCRepPartCom        ::= SEQUENCE {
-          key                 [0] EncryptionKey,
-          last-req            [1] LastReq,
-          nonce               [2] Nonce,
-          key-expiration      [3] KerberosTime OPTIONAL,
-          flags               [4] TicketFlags,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          srealm              [9] Realm,
-          sname               [10] PrincipalName,
-          caddr               [11] HostAddresses OPTIONAL,
-          ...
-      }
-
-      EncKDCRepPart1510       ::= SEQUENCE {
-          COMPONENTS OF EncKDCRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          srealm (RealmIA5),
-          sname (PrincipalNameIA5),
-          nonce UInt32 })
-
-      EncKdcRepPartExt        ::= EncKDCRepPartCom (WITH COMPONENTS {
-          ...,
-          srealm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 89]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      LRType          ::=     TH-id
-      LastReq         ::=     SEQUENCE OF SEQUENCE {
-          lr-type     [0] LRType,
-          lr-value    [1] KerberosTime
-      }
-
-
-      --
-      -- *** preauth
-      --
-
-
-      PaDataType      ::= TH-id
-      PaDataOID       ::= RELATIVE-OID
-
-      PA-DATA ::= SEQUENCE {
-          -- NOTE: first tag is [1], not [0]
-          padata-type         [1] PaDataType,
-          padata-value        [2] OCTET STRING
-      }
-
-
-      -- AP-REQ authenticating a TGS-REQ
-      pa-tgs-req              PaDataType ::= int32 : 1
-      PA-TGS-REQ              ::= AP-REQ
-
-
-      -- Encrypted timestamp preauth
-      -- Encryption key used is client's long-term key.
-      pa-enc-timestamp        PaDataType ::= int32 : 2
-
-      PA-ENC-TIMESTAMP ::= EncryptedData {
-          PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
-      }
-
-      PA-ENC-TS-ENC           ::= SEQUENCE {
-              patimestamp     [0] KerberosTime -- client's time --,
-              pausec          [1] Microseconds OPTIONAL
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 90]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- Hints returned in AS-REP or KRB-ERROR to help client
-      -- choose a password-derived key, either for preauthentication
-      -- or for decryption of the reply.
-      pa-etype-info           PaDataType ::= int32 : 11
-
-      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
-
-      ETYPE-INFO-ENTRY        ::= SEQUENCE {
-              etype           [0] EType,
-              salt            [1] OCTET STRING OPTIONAL
-      }
-
-
-      -- Similar to etype-info, but with parameters provided for
-      -- the string-to-key function.
-      pa-etype-info2          PaDataType ::= int32 : 19
-
-      ETYPE-INFO2             ::= SEQUENCE (SIZE (1..MAX))
-                                      OF ETYPE-INFO-ENTRY
-
-      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
-              etype           [0] EType,
-              salt            [1] KerberosString OPTIONAL,
-              s2kparams       [2] OCTET STRING OPTIONAL
-      }
-
-
-      -- Obsolescent.  Salt for client's long-term key.
-      -- Its character encoding is unspecified.
-      pa-pw-salt              PaDataType ::= int32 : 3
-      -- The "padata-value" does not encode an ASN.1 type.
-      -- Instead, "padata-value" must consist of the salt string to
-      -- be used by the client, in an unspecified character
-      -- encoding.
-
-
-      -- An extensible AS-REQ may be sent as a padata in a
-      -- non-extensible AS-REQ to allow for backwards compatibility.
-      pa-as-req               PaDataType ::= int32 : 42 -- provisional
-      PA-AS-REQ               ::= AS-REQ (WITH COMPONENTS ext)
-
-
-      --
-      -- *** Session key exchange
-      --
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 91]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      AP-REQ          ::= CHOICE {
-          rfc1510     [APPLICATION 14] AP-REQ-1510,
-          ext         [APPLICATION 18] Signed {
-              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
-          }
-      }
-
-
-      AP-REQ-COMMON   ::= SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14 | 18),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket,
-          authenticator       [4] EncryptedData {
-              Authenticator,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          },
-          ...,
-          extensions          [5] ApReqExtensions OPTIONAL,
-          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
-                                      OF LangTag OPTIONAL,
-          ...
-      }
-
-
-      AP-REQ-1510 ::= SEQUENCE {
-          COMPONENTS OF AP-REQ-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (14),
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmIA5),
-                  cname (PrincipalNameIA5),
-                  seqnum (UInt32)
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 92]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      AP-REQ-EXT      ::= AP-REQ-COMMON
-      (WITH COMPONENTS {
-          ...,
-          msg-type (18),
-          -- The following constraints on Authenticator assume that
-          -- we want to restrict the use of AP-REQ-EXT with TicketExt
-          -- only, since that is the only way we can enforce UTF-8.
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmExt),
-                  cname (PrincipalNameExt),
-                  authorization-data (SIZE (1..MAX))
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-      ApReqExtType    ::= TH-id
-
-      ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          apReqExt-Type       [0] ApReqExtType,
-          apReqExt-Data       [1] OCTET STRING
-      }
-
-
-      APOptions       ::= KerberosFlags { APOptionsBits }
-
-      APOptionsBits ::= BIT STRING {
-          reserved            (0),
-          use-session-key     (1),
-          mutual-required     (2)
-      }
-
-
-      -- plaintext of authenticator
-      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-          authenticator-vno   [0] INTEGER (5),
-          crealm              [1] Realm,
-          cname               [2] PrincipalName,
-          cksum               [3] Checksum {{ key-session },
-              { ku-Authenticator-cksum |
-                ku-pa-TGSReq-cksum }} OPTIONAL,
-          cusec               [4] Microseconds,
-          ctime               [5] KerberosTime,
-          subkey              [6] EncryptionKey OPTIONAL,
-          seq-number          [7] SeqNum OPTIONAL,
-          authorization-data  [8] AuthorizationData OPTIONAL
-      }
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 93]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      AP-REP          ::= CHOICE {
-          rfc1510     [APPLICATION 15] AP-REP-1510,
-          ext         [APPLICATION 19] Signed {
-              AP-REP-EXT,
-              { key-session | key-subsession }, { ku-APRep-cksum }}
-      }
-
-
-      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (15 | 19),
-          enc-part    [2] EncryptedData {
-              EncPart,
-              { key-session | key-subsession }, { ku-EncAPRepPart }},
-          ...,
-          extensions          [3] ApRepExtensions OPTIONAL,
-          ...
-      }
-
-
-      AP-REP-1510     ::= SEQUENCE {
-          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (15)
-      })
-
-
-      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
-          EncAPRepPartExt
-      } (WITH COMPONENTS { ..., msg-type (19) })
-
-
-      ApRepExtType    ::= TH-id
-
-      ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          apRepExt-Type       [0] ApRepExtType,
-          apRepExt-Data       [1] OCTET STRING
-      }
-
-
-      EncAPRepPart    ::= CHOICE {
-          rfc1510     [APPLICATION 27] EncAPRepPart1510,
-          ext         [APPLICATION 31] EncAPRepPartExt
-      }
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 94]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      EncAPRepPart1510        ::= SEQUENCE {
-          COMPONENTS OF ENCAPRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          seq-number (UInt32),
-          authorization-data ABSENT
-      })
-
-
-      EncAPRepPartExt         ::= EncAPRepPartCom
-
-
-      EncAPRepPartCom          ::= SEQUENCE {
-          ctime               [0] KerberosTime,
-          cusec               [1] Microseconds,
-          subkey              [2] EncryptionKey OPTIONAL,
-          seq-number          [3] SeqNum OPTIONAL,
-          ...,
-          authorization-data  [4] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-      --
-      -- *** Application messages
-      --
-
-
-      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
-      -- allow us to  make safe-body optional, allowing for a GSS-MIC
-      -- sort of message.
-      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (20),
-          safe-body   [2] KRB-SAFE-BODY,
-          cksum       [3] ChecksumOf {
-              KRB-SAFE-BODY,
-              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 95]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KRB-SAFE-BODY   ::= SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress,
-          r-address   [5] HostAddress OPTIONAL,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (21),
-          enc-part    [3] EncryptedData {
-              EncKrbPrivPart,
-              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
-          ...
-      }
-
-
-      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress -- sender's addr --,
-          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-      KRB-CRED        ::= CHOICE {
-          rfc1510     [APPLICATION 22] KRB-CRED-1510,
-          ext         [APPLICATION 24] Signed {
-              KRB-CRED-EXT,
-              { key-session | key-subsession }, { ku-KrbCred-cksum }}
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 96]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KRB-CRED-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (22 | 24),
-          tickets     [2] SEQUENCE OF Ticket,
-          enc-part    [3] EncryptedData {
-              EncKrbCredPart,
-              { key-session | key-subsession }, { ku-EncKrbCredPart }},
-          ...
-      }
-
-
-      KRB-CRED-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-CRED-COMMON
-      } (WITH COMPONENTS { ..., msg-type (22) })
-
-
-      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
-          (WITH COMPONENTS { ..., msg-type (24) })
-
-
-      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-          ticket-info [0] SEQUENCE OF KrbCredInfo,
-          nonce       [1] Nonce OPTIONAL,
-          timestamp   [2] KerberosTime OPTIONAL,
-          usec        [3] Microseconds OPTIONAL,
-          s-address   [4] HostAddress OPTIONAL,
-          r-address   [5] HostAddress OPTIONAL
-      }
-
-
-      KrbCredInfo     ::= SEQUENCE {
-          key         [0] EncryptionKey,
-          prealm      [1] Realm OPTIONAL,
-          pname       [2] PrincipalName OPTIONAL,
-          flags       [3] TicketFlags OPTIONAL,
-          authtime    [4] KerberosTime OPTIONAL,
-          starttime   [5] KerberosTime OPTIONAL,
-          endtime     [6] KerberosTime OPTIONAL,
-          renew-till  [7] KerberosTime OPTIONAL,
-          srealm      [8] Realm OPTIONAL,
-          sname       [9] PrincipalName OPTIONAL,
-          caddr       [10] HostAddresses OPTIONAL
-      }
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 97]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      TGT-REQ         ::= [APPLICATION 16] SEQUENCE {
-          pvno            [0] INTEGER (5),
-          msg-type        [1] INTEGER (16),
-          sname           [2] PrincipalName OPTIONAL,
-          srealm          [3] Realm OPTIONAL,
-          ...
-      }
-
-
-      --
-      -- *** Error messages
-      --
-
-
-      ErrCode ::= Int32
-
-      KRB-ERROR       ::= CHOICE {
-          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
-          ext         [APPLICATION 23] Signed {
-              KRB-ERROR-EXT, { ku-KrbError-cksum } }
-      }
-
-
-      KRB-ERROR-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (30 | 23),
-          ctime       [2] KerberosTime OPTIONAL,
-          cusec       [3] Microseconds OPTIONAL,
-          stime       [4] KerberosTime,
-          susec       [5] Microseconds,
-          error-code  [6] ErrCode,
-          crealm      [7] Realm OPTIONAL,
-          cname       [8] PrincipalName OPTIONAL,
-          realm       [9] Realm -- Correct realm --,
-          sname       [10] PrincipalName -- Correct name --,
-          e-text      [11] KerberosString OPTIONAL,
-          e-data      [12] OCTET STRING OPTIONAL,
-          ...,
-          typed-data          [13] TYPED-DATA OPTIONAL,
-          nonce               [14] Nonce OPTIONAL,
-          lang-tag            [15] LangTag OPTIONAL,
-          ...
-      }
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 98]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      KRB-ERROR-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-ERROR-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (30)
-      })
-
-
-      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
-          (WITH COMPONENTS { ..., msg-type (23) })
-
-
-      METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-
-      TDType ::= TH-id
-
-      TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-          data-type   [0] TDType,
-          data-value  [1] OCTET STRING OPTIONAL
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                   [Page 99]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      --
-      -- *** Error codes
-      --
-
-      -- No error
-      kdc-err-none                          ErrCode ::= 0
-      -- Client's entry in database has expired
-      kdc-err-name-exp                      ErrCode ::= 1
-      -- Server's entry in database has expired
-      kdc-err-service-exp                   ErrCode ::= 2
-      -- Requested protocol version number not supported
-      kdc-err-bad-pvno                      ErrCode ::= 3
-      -- Client's key encrypted in old master key
-      kdc-err-c-old-mast-kvno               ErrCode ::= 4
-      -- Server's key encrypted in old master key
-      kdc-err-s-old-mast-kvno               ErrCode ::= 5
-      -- Client not found in Kerberos database
-      kdc-err-c-principal-unknown           ErrCode ::= 6
-      -- Server not found in Kerberos database
-      kdc-err-s-principal-unknown           ErrCode ::= 7
-      -- Multiple principal entries in database
-      kdc-err-principal-not-unique          ErrCode ::= 8
-      -- The client or server has a null key
-      kdc-err-null-key                      ErrCode ::= 9
-      -- Ticket not eligible for postdating
-      kdc-err-cannot-postdate               ErrCode ::= 10
-      -- Requested start time is later than end time
-      kdc-err-never-valid                   ErrCode ::= 11
-      -- KDC policy rejects request
-      kdc-err-policy                        ErrCode ::= 12
-      -- KDC cannot accommodate requested option
-      kdc-err-badoption                     ErrCode ::= 13
-      -- KDC has no support for encryption type
-      kdc-err-etype-nosupp                  ErrCode ::= 14
-      -- KDC has no support for checksum type
-      kdc-err-sumtype-nosupp                ErrCode ::= 15
-      -- KDC has no support for padata type
-      kdc-err-padata-type-nosupp            ErrCode ::= 16
-      -- KDC has no support for transited type
-      kdc-err-trtype-nosupp                 ErrCode ::= 17
-      -- Clients credentials have been revoked
-      kdc-err-client-revoked                ErrCode ::= 18
-      -- Credentials for server have been revoked
-      kdc-err-service-revoked               ErrCode ::= 19
-      -- TGT has been revoked
-      kdc-err-tgt-revoked                   ErrCode ::= 20
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                  [Page 100]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- Client not yet valid - try again later
-      kdc-err-client-notyet                 ErrCode ::= 21
-      -- Server not yet valid - try again later
-      kdc-err-service-notyet                ErrCode ::= 22
-      -- Password has expired - change password to reset
-      kdc-err-key-expired                   ErrCode ::= 23
-      -- Pre-authentication information was invalid
-      kdc-err-preauth-failed                ErrCode ::= 24
-      -- Additional pre-authenticationrequired
-      kdc-err-preauth-required              ErrCode ::= 25
-      -- Requested server and ticket don't match
-      kdc-err-server-nomatch                ErrCode ::= 26
-      -- Server principal valid for user2user only
-      kdc-err-must-use-user2user            ErrCode ::= 27
-      -- KDC Policy rejects transited path
-      kdc-err-path-not-accpeted             ErrCode ::= 28
-      -- A service is not available
-      kdc-err-svc-unavailable               ErrCode ::= 29
-      -- Integrity check on decrypted field failed
-      krb-ap-err-bad-integrity              ErrCode ::= 31
-      -- Ticket expired
-      krb-ap-err-tkt-expired                ErrCode ::= 32
-      -- Ticket not yet valid
-      krb-ap-err-tkt-nyv                    ErrCode ::= 33
-      -- Request is a replay
-      krb-ap-err-repeat                     ErrCode ::= 34
-      -- The ticket isn't for us
-      krb-ap-err-not-us                     ErrCode ::= 35
-      -- Ticket and authenticator don't match
-      krb-ap-err-badmatch                   ErrCode ::= 36
-      -- Clock skew too great
-      krb-ap-err-skew                       ErrCode ::= 37
-      -- Incorrect net address
-      krb-ap-err-badaddr                    ErrCode ::= 38
-      -- Protocol version mismatch
-      krb-ap-err-badversion                 ErrCode ::= 39
-      -- Invalid msg type
-      krb-ap-err-msg-type                   ErrCode ::= 40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                  [Page 101]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- Message stream modified
-      krb-ap-err-modified                   ErrCode ::= 41
-      -- Message out of order
-      krb-ap-err-badorder                   ErrCode ::= 42
-      -- Specified version of key is not available
-      krb-ap-err-badkeyver                  ErrCode ::= 44
-      -- Service key not available
-      krb-ap-err-nokey                      ErrCode ::= 45
-      -- Mutual authentication failed
-      krb-ap-err-mut-fail                   ErrCode ::= 46
-      -- Incorrect message direction
-      krb-ap-err-baddirection               ErrCode ::= 47
-      -- Alternative authentication method required
-      krb-ap-err-method                     ErrCode ::= 48
-      -- Incorrect sequence number in message
-      krb-ap-err-badseq                     ErrCode ::= 49
-      -- Inappropriate type of checksum in message
-      krb-ap-err-inapp-cksum                ErrCode ::= 50
-      -- Policy rejects transited path
-      krb-ap-path-not-accepted              ErrCode ::= 51
-      -- Response too big for UDP, retry with TCP
-      krb-err-response-too-big              ErrCode ::= 52
-      -- Generic error (description in e-text)
-      krb-err-generic                       ErrCode ::= 60
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                  [Page 102]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-      -- Field is too long for this implementation
-      krb-err-field-toolong                 ErrCode ::= 61
-      -- Reserved for PKINIT
-      kdc-error-client-not-trusted          ErrCode ::= 62
-      -- Reserved for PKINIT
-      kdc-error-kdc-not-trusted             ErrCode ::= 63
-      -- Reserved for PKINIT
-      kdc-error-invalid-sig                 ErrCode ::= 64
-      -- Reserved for PKINIT
-      kdc-err-key-too-weak                  ErrCode ::= 65
-      -- Reserved for PKINIT
-      kdc-err-certificate-mismatch          ErrCode ::= 66
-      -- No TGT available to validate USER-TO-USER
-      krb-ap-err-no-tgt                     ErrCode ::= 67
-      -- USER-TO-USER TGT issued different KDC
-      kdc-err-wrong-realm                   ErrCode ::= 68
-      -- Ticket must be for USER-TO-USER
-      krb-ap-err-user-to-user-required      ErrCode ::= 69
-      -- Reserved for PKINIT
-      kdc-err-cant-verify-certificate       ErrCode ::= 70
-      -- Reserved for PKINIT
-      kdc-err-invalid-certificate           ErrCode ::= 71
-      -- Reserved for PKINIT
-      kdc-err-revoked-certificate           ErrCode ::= 72
-      -- Reserved for PKINIT
-      kdc-err-revocation-status-unknown     ErrCode ::= 73
-      -- Reserved for PKINIT
-      kdc-err-revocation-status-unavailable ErrCode ::= 74
-
-
-      END
-
-
-B.  Kerberos and Character Encodings (Informative)
-
-   [adapted from KCLAR 5.2.1]
-
-   The original specification of the Kerberos protocol in RFC 1510 uses
-   GeneralString in numerous places for human-readable string data.
-   Historical implementations of Kerberos cannot utilize the full power
-   of GeneralString.  This ASN.1 type requires the use of designation
-   and invocation escape sequences as specified in ISO 2022 | ECMA-35
-   [ISO2022] to switch character sets, and the default character set
-   that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
-   International Reference Version (IRV) (aka U.S. ASCII), which mostly
-   works.
-
-   ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3)
-   and two Control-function code elements (C0..C1).  DER previously
-   [X690-1997] prohibited the designation of character sets as any but
-   the G0 and C0 sets.  This had the side effect of prohibiting the use
-
-Yu                         Expires: Jul 2005                  [Page 103]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any
-   other character-sets that utilize a 96-character set, since it is
-   prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code
-   element.  Recent revisions to the ASN.1 standards resolve this
-   contradiction.
-
-   In practice, many implementations treat RFC 1510 GeneralStrings as if
-   they were 8-bit strings of whichever character set the implementation
-   defaults to, without regard for correct usage of character-set
-   designation escape sequences.  The default character set is often
-   determined by the current user's operating system dependent locale.
-   At least one major implementation places unescaped UTF-8 encoded
-   Unicode characters in the GeneralString.  This failure to conform to
-   the GeneralString specifications results in interoperability issues
-   when conflicting character encodings are utilized by the Kerberos
-   clients, services, and KDC.
-
-   This unfortunate situation is the result of improper documentation of
-   the restrictions of the ASN.1 GeneralString type in prior Kerberos
-   specifications.
-
-   [the following should probably be rewritten and moved into the
-   principal name section]
-
-   For compatibility, implementations MAY choose to accept GeneralString
-   values that contain characters other than those permitted by
-   IA5String, but they should be aware that character set designation
-   codes will likely be absent, and that the encoding should probably be
-   treated as locale-specific in almost every way.  Implementations MAY
-   also choose to emit GeneralString values that are beyond those
-   permitted by IA5String, but should be aware that doing so is
-   extraordinarily risky from an interoperability perspective.
-
-   Some existing implementations use GeneralString to encode unescaped
-   locale-specific characters.  This is a violation of the ASN.1
-   standard.  Most of these implementations encode US-ASCII in the left-
-   hand half, so as long the implementation transmits only US-ASCII, the
-   ASN.1 standard is not violated in this regard.  As soon as such an
-   implementation encodes unescaped locale-specific characters with the
-   high bit set, it violates the ASN.1 standard.
-
-   Other implementations have been known to use GeneralString to contain
-   a UTF-8 encoding.  This also violates the ASN.1 standard, since UTF-8
-   is a different encoding, not a 94 or 96 character "G" set as defined
-   by ISO 2022.  It is believed that these implementations do not even
-   use the ISO 2022 escape sequence to change the character encoding.
-   Even if implementations were to announce the change of encoding by
-   using that escape sequence, the ASN.1 standard prohibits the use of
-   any escape sequences other than those used to designate/invoke "G" or
-   "C" sets allowed by GeneralString.
-
-
-Yu                         Expires: Jul 2005                  [Page 104]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-C.  Kerberos History (Informative)
-
-   [Adapted from KCLAR "BACKGROUND"]
-
-   The Kerberos model is based in part on Needham and Schroeder's
-   trusted third-party authentication protocol [NS78] and on
-   modifications suggested by Denning and Sacco [DS81].  The original
-   design and implementation of Kerberos Versions 1 through 4 was the
-   work of two former Project Athena staff members, Steve Miller of
-   Digital Equipment Corporation and Clifford Neuman (now at the
-   Information Sciences Institute of the University of Southern
-   California), along with Jerome Saltzer, Technical Director of Project
-   Athena, and Jeffrey Schiller, MIT Campus Network Manager.  Many other
-   members of Project Athena have also contributed to the work on
-   Kerberos.
-
-   Version 5 of the Kerberos protocol (described in this document) has
-   evolved from Version 4 based on new requirements and desires for
-   features not available in Version 4.  The design of Version 5 of the
-   Kerberos protocol was led by Clifford Neuman and John Kohl with much
-   input from the community.  The development of the MIT reference
-   implementation was led at MIT by John Kohl and Theodore Ts'o, with
-   help and contributed code from many others.  Since RFC1510 was
-   issued, extensions and revisions to the protocol have been proposed
-   by many individuals.  Some of these proposals are reflected in this
-   document.  Where such changes involved significant effort, the
-   document cites the contribution of the proposer.
-
-   Reference implementations of both version 4 and version 5 of Kerberos
-   are publicly available and commercial implementations have been
-   developed and are widely used.  Details on the differences between
-   Kerberos Versions 4 and 5 can be found in [KNT94].
-
-D.  Notational Differences from [KCLAR]
-
-   [ possible point for discussion ]
-
-   [KCLAR] uses notational conventions slightly different from this
-   document.  As a derivative of RFC 1510, the text of [KCLAR] uses C-
-   language style identifier names for defined values.  In ASN.1
-   notation, identifiers referencing defined values must begin with a
-   lowercase letter and contain hyphen (-) characters rather than
-   underscore (_) characters, while identifiers referencing types begin
-   with an uppercase letter.  [KCLAR] and RFC 1510 use all-uppercase
-   identifiers with underscores to identify defined values.  This has
-   the potential to create confusion, but neither document defines
-   values using actual ASN.1 value-assignment notation.
-
-   It is debatable whether it is advantageous to write all identifier
-   names (regardless of their ASN.1 token type) in all-uppercase letters
-   for the purpose of emphasis in running text.  The alternative is to
-
-Yu                         Expires: Jul 2005                  [Page 105]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   use double-quote characters (") when ambiguity is possible.
-
-Normative References
-
-   [ISO646]
-        "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
-
-   [ISO2022]
-        "Information technology -- Character code structure and
-        extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
-
-   [KCRYPTO]
-        K. Raeburn, "Encryption and Checksum Specifications for Kerberos
-        5", draft-ietf-krb-wg-crypto-07.txt, work in progress.
-
-   [RFC2119]
-        S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
-        Requirement Levels", March 1997.
-
-   [RFC3660]
-        H. Alvestrand, "Tags for the Identification of Languages",
-        RFC 3660, January 2001.
-
-   [SASLPREP]
-        Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names
-        and passwords", draft-ietf-sasl-saslprep-10.txt, work in
-        progress.
-
-   [X680]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Specification of basic notation", ITU-T Recommendation X.680
-        (2002) | ISO/IEC 8824-1:2002.
-
-   [X682]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Constraint specification", ITU-T Recommendation X.682 (2002) |
-        ISO/IEC 8824-3:2002.
-
-   [X683]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Parameterization of ASN.1 specifications", ITU-T Recommendation
-        X.683 (2002) | ISO/IEC 8824-4:2002.
-
-   [X690]
-        "Information technology -- ASN.1 encoding Rules: Specification
-        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
-        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
-        X.690 (2002) | ISO/IEC 8825-1:2002.
-
-
-
-
-Yu                         Expires: Jul 2005                  [Page 106]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-Informative References
-
-   [DS81]
-        Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
-        Distribution Protocols," Communications of the ACM, Vol. 24(8),
-        pp. 533-536 (August 1981).
-
-   [Dub00]
-        Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
-        Systems", Elsevier-Morgan Kaufmann, 2000.
-        <http://www.oss.com/asn1/dubuisson.html>
-
-   [ISO8859-1]
-        "Information technology -- 8-bit single-byte coded graphic
-        character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859-
-        1:1998.
-
-   [KCLAR]
-        Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos
-        Network Authentication Service (V5)", draft-ietf-krb-wg-
-        kerberos-clarifications-07.txt, work in progress.
-
-   [KNT94]
-        John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
-        Evolution of the Kerberos Authentication System".  In
-        Distributed Open Systems, pages 78-94.  IEEE Computer Society
-        Press, 1994.
-
-   [Lar96]
-        John Larmouth, "Understanding OSI", International Thomson
-        Computer Press, 1996.
-        <http://www.isi.salford.ac.uk/books/osi.html>
-
-   [Lar99]
-        John Larmouth, "ASN.1 Complete",  Elsevier-Morgan Kaufmann,
-        1999.  <http://www.oss.com/asn1/larmouth.html>
-
-   [NS78]
-        Roger M. Needham and Michael D. Schroeder, "Using Encryption for
-        Authentication in Large Networks of Computers", Communications
-        of the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
-
-   [RFC1510]
-        J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
-        Service (v5)", RFC1510, September 1993, Status: Proposed
-        Standard.
-
-   [RFC1964]
-        J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
-        June 1996, Status: Proposed Standard.
-
-
-Yu                         Expires: Jul 2005                  [Page 107]
-
-Internet-Draft               rfc1510ter-00                   21 Jan 2005
-
-   [X690-2002]
-        "Information technology -- ASN.1 encoding rules: Specification
-        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
-        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
-        X.690 (2002) | ISO/IEC 8825-1:2002.
-
-Author's Address
-
-   Tom Yu
-   77 Massachusetts Ave
-   Cambridge, MA 02139
-   USA
-   tlyu@mit.edu
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Jul 2005                  [Page 108]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-01.txt b/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-01.txt
deleted file mode 100644
index 5728927e4..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-01.txt
+++ /dev/null
@@ -1,6049 +0,0 @@
-
-
-INTERNET-DRAFT                                                    Tom Yu
-draft-ietf-krb-wg-rfc1510ter-01.txt                                  MIT
-Expires: 19 March 2005                                 15 September 2005
-
-        The Kerberos Network Authentication Service (Version 5)
-
-Status of This Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-
-      http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-
-      http://www.ietf.org/shadow.html
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).  All Rights Reserved.
-
-Abstract
-
-   This document describes version 5 of the Kerberos network
-   authentication protocol.  It describes a framework to allow for
-   extensions to be made to the protocol without creating
-   interoperability problems.
-
-Key Words for Requirements
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
-   to be interpreted as described in RFC 2119.
-
-
-
-
-Yu                         Expires: Mar 2005                    [Page 1]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-Table of Contents
-
-   Status of This Memo ..............................................  1
-   Copyright Notice .................................................  1
-   Abstract .........................................................  1
-   Key Words for Requirements .......................................  1
-   Table of Contents ................................................  2
-   1.  Introduction .................................................  5
-   1.1.  Kerberos Protocol Overview .................................  5
-   1.2.  Document Organization ......................................  6
-   2.  Compatibility Considerations .................................  6
-   2.1.  Extensibility ..............................................  7
-   2.2.  Compatibility with RFC 1510 ................................  7
-   2.3.  Backwards Compatibility ....................................  7
-   2.4.  1.4.2. Sending Extensible Messages .........................  8
-   2.5.  Criticality ................................................  8
-   2.6.  Authenticating Cleartext Portions of Messages ..............  9
-   2.7.  Capability Negotiation ..................................... 10
-   3.  Use of ASN.1 in Kerberos ..................................... 10
-   3.1.  Module Header .............................................. 11
-   3.2.  Top-Level Type ............................................. 11
-   3.3.  Previously Unused ASN.1 Notation (informative) ............. 12
-   3.3.1.  Parameterized Types ...................................... 12
-   3.3.2.  COMPONENTS OF Notation ................................... 12
-   3.3.3.  Constraints .............................................. 12
-   3.4.  New Types .................................................. 13
-   4.  Basic Types .................................................. 14
-   4.1.  Constrained Integer Types .................................. 14
-   4.2.  KerberosTime ............................................... 15
-   4.3.  KerberosString ............................................. 15
-   4.4.  Language Tags .............................................. 16
-   4.5.  KerberosFlags .............................................. 16
-   4.6.  Typed Holes ................................................ 16
-   4.7.  HostAddress and HostAddresses .............................. 17
-   4.7.1.  Internet (IPv4) Addresses ................................ 17
-   4.7.2.  Internet (IPv6) Addresses ................................ 17
-   4.7.3.  DECnet Phase IV addresses ................................ 18
-   4.7.4.  Netbios addresses ........................................ 18
-   4.7.5.  Directional Addresses .................................... 18
-   5.  Principals ................................................... 19
-   5.1.  Name Types ................................................. 19
-   5.2.  Principal Type Definition .................................. 19
-   5.3.  Principal Name Reuse ....................................... 20
-   5.4.  Realm Names ................................................ 20
-   5.5.  Printable Representations of Principal Names ............... 21
-   5.6.  Ticket-Granting Service Principal .......................... 21
-   5.6.1.  Cross-Realm TGS Principals ............................... 21
-   6.  Types Relating to Encryption ................................. 21
-   6.1.  Assigned Numbers for Encryption ............................ 22
-   6.1.1.  EType .................................................... 22
-   6.1.2.  Key Usages ............................................... 22
-
-Yu                         Expires: Mar 2005                    [Page 2]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   6.2.  Which Key to Use ........................................... 23
-   6.3.  EncryptionKey .............................................. 24
-   6.4.  EncryptedData .............................................. 24
-   6.5.  Checksums .................................................. 25
-   6.5.1.  ChecksumOf ............................................... 26
-   6.5.2.  Signed ................................................... 27
-   7.  Tickets ...................................................... 27
-   7.1.  Timestamps ................................................. 28
-   7.2.  Ticket Flags ............................................... 28
-   7.2.1.  Flags Relating to Initial Ticket Acquisition ............. 29
-   7.2.2.  Invalid Tickets .......................................... 29
-   7.2.3.  OK as Delegate ........................................... 30
-   7.2.4.  Renewable Tickets ........................................ 30
-   7.2.5.  Postdated Tickets ........................................ 31
-   7.2.6.  Proxiable and Proxy Tickets .............................. 32
-   7.2.7.  Forwarded and Forwardable Tickets ........................ 33
-   7.3.  Transited Realms ........................................... 34
-   7.4.  Authorization Data ......................................... 34
-   7.4.1.  AD-IF-RELEVANT ........................................... 35
-   7.4.2.  AD-KDCIssued ............................................. 35
-   7.4.3.  AD-AND-OR ................................................ 37
-   7.4.4.  AD-MANDATORY-FOR-KDC ..................................... 37
-   7.5.  Encrypted Part of Ticket ................................... 37
-   7.6.  Cleartext Part of Ticket ................................... 38
-   8.  Credential Acquisition ....................................... 40
-   8.1.  KDC-REQ .................................................... 40
-   8.2.  PA-DATA .................................................... 46
-   8.3.  KDC-REQ Processing ......................................... 46
-   8.3.1.  Handling Replays ......................................... 46
-   8.3.2.  Request Validation ....................................... 47
-   8.3.2.1.  AS-REQ Authentication .................................. 47
-   8.3.2.2.  TGS-REQ Authentication ................................. 47
-   8.3.2.3.  Principal Validation ................................... 47
-   8.3.2.4.  Checking For Revoked or Invalid Tickets ................ 48
-   8.3.3.  Timestamp Handling ....................................... 48
-   8.3.3.1.  AS-REQ Timestamp Processing ............................ 49
-   8.3.3.2.  TGS-REQ Timestamp Processing ........................... 49
-   8.3.4.  Handling Transited Realms ................................ 50
-   8.3.5.  Address Processing ....................................... 50
-   8.3.6.  Ticket Flag Processing ................................... 51
-   8.3.7.  Key Selection ............................................ 52
-   8.3.7.1.  Reply Key and Session Key Selection .................... 52
-   8.3.7.2.  Ticket Key Selection ................................... 52
-   8.4.  KDC-REP .................................................... 52
-   8.5.  Reply Validation ........................................... 55
-   8.6.  IP Transports .............................................. 55
-   8.6.1.  UDP/IP transport ......................................... 55
-   8.6.2.  TCP/IP transport ......................................... 56
-   8.6.3.  KDC Discovery on IP Networks ............................. 57
-   8.6.3.1.  DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 57
-   8.6.3.2.  DNS SRV records for KDC location ....................... 58
-
-Yu                         Expires: Mar 2005                    [Page 3]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP
-                Networks ............................................ 58
-   9.  Errors ....................................................... 58
-   10.  Session Key Exchange ........................................ 61
-   10.1.  AP-REQ .................................................... 61
-   10.2.  AP-REP .................................................... 63
-   11.  Session Key Use ............................................. 65
-   11.1.  KRB-SAFE .................................................. 65
-   11.2.  KRB-PRIV .................................................. 65
-   11.3.  KRB-CRED .................................................. 66
-   12.  Security Considerations ..................................... 67
-   12.1.  Time Synchronization ...................................... 67
-   12.2.  Replays ................................................... 67
-   12.3.  Principal Name Reuse ...................................... 67
-   12.4.  Password Guessing ......................................... 67
-   12.5.  Forward Secrecy ........................................... 67
-   12.6.  Authorization ............................................. 68
-   12.7.  Login Authentication ...................................... 68
-   13.  IANA Considerations ......................................... 68
-   14.  Acknowledgments ............................................. 69
-   Appendices ....................................................... 69
-   A.  ASN.1 Module (Normative) ..................................... 69
-   B.  Kerberos and Character Encodings (Informative) ...............103
-   C.  Kerberos History (Informative) ...............................104
-   D.  Notational Differences from [KCLAR] ..........................105
-   Normative References .............................................106
-   Informative References ...........................................106
-   Author's Address .................................................108
-   Copyright Statement ..............................................108
-   Intellectual Property Statement ..................................108
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                    [Page 4]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-1.  Introduction
-
-   The Kerberos network authentication protocol is a trusted-third-party
-   protocol utilizing symmetric-key cryptography.  It assumes that all
-   communications between parties in the protocol may be arbitrarily
-   tampered with or monitored, and that the security of the overall
-   system depends only on the effectiveness of the cryptographic
-   techniques and the secrecy of the cryptographic keys used.  The
-   Kerberos protocol authenticates an application client's identity to
-   an application server, and likewise authenticates the application
-   server's identity to the application client.  These assurances are
-   made possible by the client and the server sharing secrets with the
-   trusted third party: the Kerberos server, also known as the Key
-   Distribution Center (KDC).  In addition, the protocol establishes an
-   ephemeral shared secret (the session key) between the client and the
-   server, allowing the protection of further communications between
-   them.
-
-   The Kerberos protocol, as originally specified, provides insufficient
-   means for extending the protocol in a backwards-compatible way.  This
-   deficiency has caused problems for interoperability.  This document
-   describes a framework which enables backwards-compatible extensions
-   to the Kerberos protocol.
-
-1.1.  Kerberos Protocol Overview
-
-   Kerberos comprises three main sub-protocols: credentials acquisition,
-   session key exchange, and session key usage.  A client acquires
-   credentials by asking the KDC for a credential for a service; the KDC
-   issues the credential, which contains a ticket and a session key.
-   The ticket, containing the client's identity, timestamps, expiration
-   time, and a session key, is a encrypted in a key known to the
-   application server.  The KDC encrypts the credential using a key
-   known to the client, and transmits the credential to the client.
-
-   There are two means of requesting credentials: the Authentication
-   Service (AS) exchange, and the Ticket-Granting Service (TGS)
-   exchange.  In the typical AS exchange, a client uses a password-
-   derived key to decrypt the response.  In the TGS exchange, the KDC
-   behaves as an application server; the client authenticates to the TGS
-   by using a Ticket-Granting Ticket (TGT).  The client usually obtains
-   the TGT by using the AS exchange.
-
-   Session key exchange consists of the client transmitting the ticket
-   to the application server, accompanied by an authenticator.  The
-   authenticator contains a timestamp and additional data encrypted
-   using the ticket's session key.  The application server decrypts the
-   ticket, extracting the session key.  The application server then uses
-   the session key to decrypt the authenticator.  Upon successful
-   decryption of the authenticator, the application server knows that
-   the data in the authenticator were sent by the client named in the
-
-Yu                         Expires: Mar 2005                    [Page 5]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   associated ticket.  Additionally, since authenticators expire more
-   quickly than tickets, the application server has some assurance that
-   the transaction is not a replay.  The application server may send an
-   encrypted acknowledgment to the client, verifying its identity to the
-   client.
-
-   Once session key exchange has occurred, the client and server may use
-   the established session key to protect further traffic.  This
-   protection may consist of protection of integrity only, or of
-   protection of confidentiality and integrity.  Additional measures
-   exist for a client to securely forward credentials to a server.
-
-   The entire scheme depends on loosely synchronized clocks.
-   Synchronization of the clock on the KDC with the application server
-   clock allows the application server to accurately determine whether a
-   credential is expired.  Likewise, synchronization of the clock on the
-   client with the application server clock prevents replay attacks
-   utilizing the same credential.  Careful design of the application
-   protocol may allow replay prevention without requiring client-server
-   clock synchronization.
-
-   After establishing a session key, application client and the
-   application server can exchange Kerberos protocol messages that use
-   the session key to protect the integrity or confidentiality of
-   communications between the client and the server.  Additionally, the
-   client may forward credentials to the application server.
-
-   The credentials acquisition protocol takes place over specific,
-   defined transports (UDP and TCP).  Application protocols define which
-   transport to use for the session key establishment protocol and for
-   messages using the session key; the application may choose to perform
-   its own encapsulation of the Kerberos messages, for example.
-
-1.2.  Document Organization
-
-   The remainder of this document begins by describing the general
-   frameworks for protocol extensibility, including whether to interpret
-   unknown extensions as critical.  It then defines the protocol
-   messages and exchanges.
-
-   The definition of the Kerberos protocol uses Abstract Syntax Notation
-   One (ASN.1) [X680], which specifies notation for describing the
-   abstract content of protocol messages.  This document defines a
-   number of base types using ASN.1; these base types subsequently
-   appear in multiple types which define actual protocol messages.
-   Definitions of principal names and of tickets, which are central to
-   the protocol, also appear preceding the protocol message definitions.
-
-
-
-
-
-Yu                         Expires: Mar 2005                    [Page 6]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-2.  Compatibility Considerations
-
-2.1.  Extensibility
-
-   In the past, significant interoperability problems have resulted from
-   conflicting assumptions about how the Kerberos protocol can be
-   extended.  As the deployed base of Kerberos grows, the ability to
-   extend the Kerberos protocol becomes more important.  In order to
-   ensure that vendors and the IETF can extend the protocol while
-   maintaining backwards compatibility, this document outlines a
-   framework for extending Kerberos.
-
-   Kerberos provides two general mechanisms for protocol extensibility.
-   Many protocol messages, including some defined in RFC 1510, contain
-   typed holes--sub-messages containing an octet string along with an
-   integer that identifies how to interpret the octet string.  The
-   integer identifiers are registered centrally, but can be used both
-   for vendor extensions and for extensions standardized in the IETF.
-   This document adds typed holes to a number of messages which
-   previously lacked typed holes.
-
-   Many new messages defined in this document also contain ASN.1
-   extension markers.  These markers allow future revisions of this
-   document to add additional elements to messages, for cases where
-   typed holes are inadequate for some reason.  Because tag numbers and
-   position in a sequence need to be coordinated in order to maintain
-   interoperability, implementations MUST NOT include ASN.1 extensions
-   except when those extensions are specified by IETF standards-track
-   documents.
-
-2.2.  Compatibility with RFC 1510
-
-   Implementations of RFC 1510 did not use extensible ASN.1 types.
-   Sending additional fields not in RFC 1510 to these implementations
-   results in undefined behavior.  Examples of this behavior are known
-   to include discarding messages with no error indications.
-
-   Where messages have been changed since RFC 1510, ASN.1 CHOICE types
-   are used; one alternative of the CHOICE provides a message which is
-   wire-encoding compatible with RFC 1510, and the other alternative
-   provides the new, extensible message.
-
-   Implementations sending new messages MUST ensure that the recipient
-   supports these new messages.  Along with each extensible message is a
-   guideline for when that message MAY be used.  IF that guideline is
-   followed, then the recipient is guaranteed to understand the message.
-
-2.3.  Backwards Compatibility
-
-   This document describes two sets (for the most part) of ASN.1 types.
-   The first set of types is wire-encoding compatible with RFC 1510 and
-
-Yu                         Expires: Mar 2005                    [Page 7]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   [KCLAR].  The second set of types is the set of types enabling
-   extensibility.  This second set may be referred to as
-   "extensibility-enabled types". [ need to make this consistent
-   throughout? ]
-
-   A major difference between the new extensibility-enabled types and
-   the types for RFC 1510 compatibility is that the extensibility-
-   enabled types allow for the use of UTF-8 encodings in various
-   character strings in the protocol.  Each party in the protocol must
-   have some knowledge of the capabilities of the other parties in the
-   protocol.  There are methods for establishing this knowledge without
-   necessarily requiring explicit configuration.
-
-   An extensibility-enabled client can detect whether a KDC supports the
-   extensibility-enabled types by requesting an extensibility-enabled
-   reply.  If the KDC replies with an extensibility-enabled reply, the
-   client knows that the KDC supports extensibility.  If the KDC issues
-   an extensibility-enabled ticket, the client knows that the service
-   named in the ticket is extensibility-enabled.
-
-2.4.  1.4.2. Sending Extensible Messages
-
-   Care must be taken to make sure that old implementations can
-   understand messages sent to them even if they do not understand an
-   extension that is used.  Unless the sender knows the extension is
-   supported, the extension cannot change the semantics of the core
-   message or previously defined extensions.
-
-   For example, an extension including key information necessary to
-   decrypt the encrypted part of a KDC-REP could only be used in
-   situations where the recipient was known to support the extension.
-   Thus when designing such extensions it is important to provide a way
-   for the recipient to notify the sender of support for the extension.
-   For example in the case of an extension that changes the KDC-REP
-   reply key, the client could indicate support for the extension by
-   including a padata element in the AS-REQ sequence.  The KDC should
-   only use the extension if this padata element is present in the AS-
-   REQ.  Even if policy requires the use of the extension, it is better
-   to return an error indicating that the extension is required than to
-   use the extension when the recipient may not support it; debugging
-   why implementations do not interoperate is easier when errors are
-   returned.
-
-2.5.  Criticality
-
-   Recipients of unknown message extensions (including typed holes, new
-   flags, and ASN.1 extension elements) should preserve the encoding of
-   the extension but otherwise ignore the presence of the extension;
-   i.e., unknown extensions SHOULD be treated as non-critical.  If a
-   copy of the message is used later--for example, when a Ticket
-   received in a KDC-REP is later used in an AP-REQ--then the unknown
-
-Yu                         Expires: Mar 2005                    [Page 8]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   extensions MUST be included.
-
-   An implementation SHOULD NOT reject a request merely because it does
-   not understand some element of the request.  As a related
-   consequence, implementations SHOULD handle communicating with other
-   implementations which do not implement some requested options.  This
-   may require designers of options to provide means to determine
-   whether an option has been rejected, not understood, or (perhaps
-   maliciously) deleted or modified in transit.
-
-   There is one exception to non-criticality described above: if an
-   unknown authorization data element is received by a server either in
-   an AP-REQ or in a Ticket contained in an AP-REQ, then the
-   authentication SHOULD fail.  Authorization data is intended to
-   restrict the use of a ticket.  If the service cannot determine
-   whether the restriction applies to that service then a security
-   weakness may result if authentication succeeds.  Authorization
-   elements meant to be truly optional can be enclosed in the AD-IF-
-   RELEVANT element.
-
-   Many RFC 1510 implementations ignore unknown authorization data
-   elements.  Depending on these implementations to honor authorization
-   data restrictions may create a security weakness.
-
-2.6.  Authenticating Cleartext Portions of Messages
-
-   Various denial of service attacks and downgrade attacks against
-   Kerberos are possible unless plaintexts are somehow protected against
-   modification.  An early design goal of Kerberos Version 5 was to
-   avoid encrypting more of the authentication exchange that was
-   required.  (Version 4 doubly-encrypted the encrypted part of a ticket
-   in a KDC reply, for example.)  This minimization of encryption
-   reduces the load on the KDC and busy servers.  Also, during the
-   initial design of Version 5, the existence of legal restrictions on
-   the export of cryptography made it desirable to minimize of the
-   number of uses of encryption in the protocol.  Unfortunately,
-   performing this minimization created numerous instances of
-   unauthenticated security-relevant plaintext fields.
-
-   The extensible variants of the messages described in this document
-   wrap the actual message in an ASN.1 sequence containing a keyed
-   checksum of the contents of the message.  Guidelines in [XXX] section
-   3 specify when the checksum MUST be included and what key MUST be
-   used.  Guidelines on when to include a checksum are never ambiguous:
-   a particular PDU is never correct both with and without a checksum.
-   With the exception of the KRB-ERROR message, receiving
-   implementations MUST reject messages where a checksum is included and
-   not expected or where a checksum is expected but not included.  The
-   receiving implementation does not always have sufficient information
-   to know whether a KRB-ERROR should contain a checksum.  Even so,
-   KRB-ERROR messages with invalid checksums MUST be rejected and
-
-Yu                         Expires: Mar 2005                    [Page 9]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   implementations MAY consider the presence or absence of a checksum
-   when evaluating whether to trust the error.
-
-   This authenticated cleartext protection is provided only in the
-   extensible variants of the messages; it is never used when
-   communicating with an RFC 1510 implementation.
-
-2.7.  Capability Negotiation
-
-   Kerberos is a three-party protocol.  Each of the three parties
-   involved needs a means of detecting the capabilities supported by the
-   others.  Two of the parties, the KDC and the application server, do
-   not communicate directly in the Kerberos protocol.  Communicating
-   capabilities from the KDC to the application server requires using a
-   ticket as an intermediary.
-
-   The main capability requiring negotiation is the support of the
-   extensibility framework described in this document.  Negotiation of
-   this capability while remaining compatible with RFC 1510
-   implementations is possible.  The main complication is that the
-   client needs to know whether the application server supports the
-   extensibility framework prior to sending any message to the
-   application server.  This can be accomplished if the KDC has
-   knowledge of whether an application server supports the extensibility
-   framework.
-
-   Client software advertizes its capabilities when requesting
-   credentials from the KDC.  If the KDC recognizes the capabilities, it
-   acknowledges this fact to the client in its reply.  In addition, if
-   the KDC has knowledge that the application server supports certain
-   capabilities, it also communicates this knowledge to the client in
-   its reply.  The KDC can encode its own capabilities in the ticket so
-   that the application server may discover these capabilities.  The
-   client advertizes its capabilities to the application server when it
-   initiates authentication to the application server.
-
-3.  Use of ASN.1 in Kerberos
-
-   Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
-   Even though ASN.1 theoretically allows the description of protocol
-   messages to be independent of the encoding rules used to encode the
-   messages, Kerberos messages MUST be encoded with DER.  Subtleties in
-   the semantics of the notation, such as whether tags carry any
-   semantic content to the application, may cause the use of other ASN.1
-   encoding rules to be problematic.
-
-   Implementors not using existing ASN.1 tools (e.g., compilers or
-   support libraries) are cautioned to thoroughly read and understand
-   the actual ASN.1 specification to ensure correct implementation
-   behavior.  There is more complexity in the notation than is
-   immediately obvious, and some tutorials and guides to ASN.1 are
-
-Yu                         Expires: Mar 2005                   [Page 10]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   misleading or erroneous.  Recommended tutorials and guides include
-   [Dub00], [Lar99], though there is still no substitute for reading the
-   actual ASN.1 specification.
-
-3.1.  Module Header
-
-   The type definitions in this document assume an ASN.1 module
-   definition of the following form:
-
-      KerberosV5Spec3 {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2) modules(4) krb5spec3(4)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      -- Rest of definitions here
-
-      END
-
-   This specifies that the tagging context for the module will be
-   explicit and that automatic tagging is not done.
-
-   Some other publications [RFC1510] [RFC1964] erroneously specify an
-   object identifier (OID) having an incorrect value of "5" for the
-   "dod" component of the OID.  In the case of RFC 1964, use of the
-   "correct" OID value would result in a change in the wire protocol;
-   therefore, the RFC 1964 OID remains unchanged for now.
-
-3.2.  Top-Level Type
-
-   The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
-   Data Units or PDUs) which an application may directly reference.
-   Applications SHOULD NOT transmit any types other than those which are
-   alternatives of the KRB-PDU CHOICE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 11]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- top-level type
-      --
-      -- Applications should not directly reference any types
-      -- other than KRB-PDU and its component types.
-      --
-      KRB-PDU         ::= CHOICE {
-          ticket      Ticket,
-          as-req      AS-REQ,
-          as-rep      AS-REP,
-          tgs-req     TGS-REQ,
-          tgs-rep     TGS-REP,
-          ap-req      AP-REQ,
-          ap-rep      AP-REP,
-          krb-safe    KRB-SAFE,
-          krb-priv    KRB-PRIV,
-          krb-cred    KRB-CRED,
-          tgt-req     TGT-REQ,
-          krb-error   KRB-ERROR,
-          ...
-      }
-
-
-3.3.  Previously Unused ASN.1 Notation (informative)
-
-   Some aspects of ASN.1 notation used in this document were not used in
-   [KCLAR], and may be unfamiliar to some readers.  This subsection is
-   informative; for normative definitions of the notation, see the
-   actual ASN.1 specifications [X680], [X682], [X683].
-
-3.3.1.  Parameterized Types
-
-   This document uses ASN.1 parameterized types [X683] to make
-   definitions of types more readable.  For some types, some or all of
-   the parameters are advisory, i.e., they are not encoded in any form
-   for transmission in a protocol message.  These advisory parameters
-   can describe implementation behavior associated with the type.
-
-3.3.2.  COMPONENTS OF Notation
-
-   The "COMPONENTS OF" notation, used to define the RFC 1510
-   compatibility types, extracts all of the component types of an ASN.1
-   SEQUENCE type.  The extension marker (the "..." notation) and any
-   extension components are not extracted by "COMPONENTS OF".  The
-   "COMPONENTS OF" notation permits concise definition of multiple types
-   which have many components in common with each other.
-
-3.3.3.  Constraints
-
-   This document uses ASN.1 constraints, including the
-   "UserDefinedConstraint" notation [X682].  Some constraints can be
-   handled automatically by tools that can parse them.  Uses of the
-
-Yu                         Expires: Mar 2005                   [Page 12]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will
-   typically need to have behavior manually coded; the notation provides
-   a formalized way of conveying intended implementation behavior.
-
-   The "WITH COMPONENTS" constraint notation allows constraints to apply
-   to component types of a SEQUENCE type.  This constraint notation
-   effectively allows constraints to "reach into" a type to constrain
-   its component types.
-
-3.4.  New Types
-
-   This document defines a number of ASN.1 types which are new since
-   [KCLAR].  The names of these types will typically have a suffix like
-   "Ext", indicating that the types are intended to support
-   extensibility.  Types original to RFC 1510 and [KCLAR] have been
-   renamed to have a suffix like "1510".  The "Ext" and "1510" types
-   often contain a number of common elements; these common elements have
-   a suffix like "Common".  The "1510" types have various ASN.1
-   constraints applied to them; the constraints limit the possible
-   values of the "1510" types to those permitted by RFC 1510 or by
-   [KCLAR].  The "Ext" types may have different constraints, typically
-   to force string values to be sent as UTF-8.
-
-   For example, consider
-
-      -- example "common" type
-      Foo-Common      ::= SEQUENCE {
-          a           [0] INTEGER,
-          b           [1] OCTET STRING,
-          ...,
-          c           [2] INTEGER,
-          ...
-      }
-
-      -- example "RFC 1510 compatibility" type
-      Foo-1510        ::= SEQUENCE {
-          -- the COMPONENTS OF notation drops the extension marker
-          -- and all extension additions.
-          COMPONENTS OF Foo-Common
-      }
-
-      -- example "extensibility-enabled" type
-      Foo-Ext         ::= Foo-Common
-
-   where "Foo-Common" is a common type used to define both the "1510"
-   and "Ext" versions of a type.  "Foo-1510" is the RFC 1510 version of
-   the type, while "Foo-Ext" is the extensible version.  "Foo-1510" does
-   not contain the extension marker, nor does it contain the extension
-   component "c".  The type "Foo-1510" is equivalent to "Foo-1510-
-   Equiv", shown below.
-
-
-Yu                         Expires: Mar 2005                   [Page 13]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- example type equivalent to Foo-1510
-      Foo-1510-Equiv  ::= SEQUENCE {
-          a           [0] INTEGER,
-          b           [1] OCTET STRING
-      }
-
-
-4.  Basic Types
-
-   These "basic" Kerberos ASN.1 types appear in multiple other Kerberos
-   types.
-
-4.1.  Constrained Integer Types
-
-   In RFC 1510, many types contained references to the unconstrained
-   INTEGER type.  Since an unconstrained INTEGER can contain almost any
-   possible abstract integer value, most of the unconstrained references
-   to INTEGER in RFC 1510 were constrained to 32 bits or smaller in
-   [KCLAR].
-
-      -- signed values representable in 32 bits
-      --
-      -- These are often used as assigned numbers for various things.
-      Int32           ::= INTEGER (-2147483648..2147483647)
-
-   The "Int32" type often contains an assigned number identifying the
-   contents of a typed hole.  Unless otherwise stated, non-negative
-   values are registered, and negative values are available for local
-   use.
-
-      -- unsigned 32 bit values
-      UInt32          ::= INTEGER (0..4294967295)
-
-   The "UInt32" type is used in some places where an unsigned 32-bit
-   integer is needed.
-
-      -- unsigned 64 bit values
-      UInt64          ::= INTEGER (0..18446744073709551615)
-
-   The "UInt64" type is used in places where 32 bits of precision may
-   provide inadequate security.
-
-      -- sequence numbers
-      SeqNum          ::= UInt64
-
-   Sequence numbers were constrained to 32 bits in [KCLAR], but this
-   document allows for 64-bit sequence numbers.
-
-      -- nonces
-      Nonce           ::= UInt64
-
-
-Yu                         Expires: Mar 2005                   [Page 14]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   Likewise, nonces were constrained to 32 bits in [KCLAR], but expanded
-   to 64 bits here.
-
-      -- microseconds
-      Microseconds    ::= INTEGER (0..999999)
-
-   The "microseconds" type is intended to carry the microseconds part of
-   a time value.
-
-4.2.  KerberosTime
-
-      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
-                              -- MUST NOT include fractional seconds
-      })
-
-   The timestamps used in Kerberos are encoded as GeneralizedTimes.  A
-   KerberosTime value MUST NOT include any fractional portions of the
-   seconds.  As required by the DER, it further MUST NOT include any
-   separators, and it specifies the UTC time zone (Z).  Example: The
-   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
-   November 1985 is "19851106210627Z".
-
-4.3.  KerberosString
-
-      -- used for names and for error messages
-      KerberosString  ::= CHOICE {
-          ia5         GeneralString (IA5String),
-          utf8        UTF8String,
-          ...         -- no extension may be sent
-                      -- to an rfc1510 implementation --
-      }
-
-   The KerberosString type is used for character strings in various
-   places in the Kerberos protocol.  For compatibility with RFC 1510,
-   GeneralString values constrained to IA5String (US-ASCII) are
-   permitted in messages exchanged with RFC 1510 implementations.  The
-   new protocol messages contain strings encoded as UTF-8, and these
-   strings MUST be normalized using [SASLPREP].  KerberosString values
-   are present in principal names and in error messages.  Control
-   characters SHOULD NOT be used in principal names, and used with
-   caution in error messages.
-
-      -- IA5 choice only; useful for constraints
-      KerberosStringIA5       ::= KerberosString
-          (WITH COMPONENTS { ia5 PRESENT })
-
-      -- IA5 excluded; useful for constraints
-      KerberosStringExt       ::= KerberosString
-          (WITH COMPONENTS { ia5 ABSENT })
-
-   KerberosStringIA5 requires the use of the "ia5" alternative, while
-
-Yu                         Expires: Mar 2005                   [Page 15]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   KerberosStringExt forbids it.  These types appear in ASN.1
-   constraints on messages.
-
-   For detailed background regarding the history of character string use
-   in Kerberos, as well as discussion of some compatibility issues, see
-   Appendix B.
-
-4.4.  Language Tags
-
-      -- used for language tags
-      LangTag ::= PrintableString
-          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
-
-   The "LangTag" type is used to specify language tags for localization
-   purposes, using the [RFC3066] format.
-
-4.5.  KerberosFlags
-
-   For several message types, a specific constrained bit string type,
-   KerberosFlags, is used.
-
-      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
-          (CONSTRAINED BY {
-          -- MUST be a valid value of -- NamedBits
-          -- but if the value to be sent would be truncated to shorter
-          -- than 32 bits according to DER, the value MUST be padded
-          -- with trailing zero bits to 32 bits.  Otherwise, no
-          -- trailing zero bits may be present.
-
-      })
-
-
-   The actual bit string type encoded in Kerberos messages does not use
-   named bits.  The advisory parameter of the KerberosFlags type names a
-   bit string type defined using named bits, whose value is encoded as
-   if it were a bit string with unnamed bits.  This practice is
-   necessary because the DER require trailing zero bits to be removed
-   when encoding bit strings defined using named bits.  Existing
-   implementations of Kerberos send exactly 32 bits rather than
-   truncating, so the size constraint requires the transmission of at
-   least 32 bits.  Trailing zero bits beyond the first 32 bits are
-   truncated.
-
-4.6.  Typed Holes
-
-      -- Typed hole identifiers
-      TH-id           ::= CHOICE {
-          int32               Int32,
-          rel-oid             RELATIVE-OID
-      }
-
-
-Yu                         Expires: Mar 2005                   [Page 16]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   The "TH-id" type is a generalized means to identify the contents of a
-   typed hole.  The "int32" alternative may be used for simple integer
-   assignments, in the same manner as "Int32", while the "rel-oid"
-   alternative may be used for hierarchical delegation.
-
-4.7.  HostAddress and HostAddresses
-
-      AddrType        ::= Int32
-
-      HostAddress     ::= SEQUENCE  {
-          addr-type   [0] AddrType,
-          address     [1] OCTET STRING
-      }
-
-      -- NOTE: HostAddresses is always used as an OPTIONAL field and
-      -- should not be a zero-length SEQUENCE OF.
-      --
-      -- The extensible messages explicitly constrain this to be
-      -- non-empty.
-      HostAddresses   ::= SEQUENCE OF HostAddress
-
-
-   addr-type
-        This field specifies the type of address that follows.
-
-   address
-        This field encodes a single address of the type identified by
-        "addr-type".
-
-   All negative values for the host address type are reserved for local
-   use.  All non-negative values are reserved for officially assigned
-   type fields and interpretations.
-
-
-      addr-type |     meaning
-      __________|______________
-              2 |   IPv4
-              3 |   directional
-             12 |   DECnet
-             20 |   NetBIOS
-             24 |   IPv6
-
-
-
-4.7.1.  Internet (IPv4) Addresses
-
-   Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
-   MSB order (most significant byte first). The IPv4 loopback address
-   SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is
-   two (2).
-
-
-Yu                         Expires: Mar 2005                   [Page 17]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-4.7.2.  Internet (IPv6) Addresses
-
-   IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, encoded
-   in MSB order (most significant byte first). The type of IPv6
-   addresses is twenty-four (24). The following addresses MUST NOT
-   appear in any Kerberos PDU:
-
-      * the Unspecified Address
-
-      * the Loopback Address
-
-      * Link-Local addresses
-
-   This restriction applies to the inclusion in the address fields of
-   Kerberos PDUs, but not to the address fields of packets that might
-   carry such PDUs.  The restriction is necessary because the use of an
-   address with non-global scope could allow the acceptance of a message
-   sent from a node that may have the same address, but which is not the
-   host intended by the entity that added the restriction.  If the
-   link-local address type needs to be used for communication, then the
-   address restriction in tickets must not be used (i.e. addressless
-   tickets must be used).
-
-   IPv4-mapped IPv6 addresses MUST be represented as addresses of type
-   2.
-
-4.7.3.  DECnet Phase IV addresses
-
-   DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order.
-   The type of DECnet Phase IV addresses is twelve (12).
-
-4.7.4.  Netbios addresses
-
-   Netbios addresses are 16-octet addresses typically composed of 1 to
-   15 alphanumeric characters and padded with the US-ASCII SPC character
-   (code 32).  The 16th octet MUST be the US-ASCII NUL character (code
-   0).  The type of Netbios addresses is twenty (20).
-
-4.7.5.  Directional Addresses
-
-   In many environments, including the sender address in KRB-SAFE and
-   KRB-PRIV messages is undesirable because the addresses may be changed
-   in transport by network address translators. However, if these
-   addresses are removed, the messages may be subject to a reflection
-   attack in which a message is reflected back to its originator. The
-   directional address type provides a way to avoid transport addresses
-   and reflection attacks.  Directional addresses are encoded as four
-   byte unsigned integers in network byte order.  If the message is
-   originated by the party sending the original AP-REQ message, then an
-   address of 0 SHOULD be used. If the message is originated by the
-   party to whom that AP-REQ was sent, then the address 1 SHOULD be
-
-Yu                         Expires: Mar 2005                   [Page 18]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   used.  Applications involving multiple parties can specify the use of
-   other addresses.
-
-   Directional addresses MUST only be used for the sender address field
-   in the KRB-SAFE or KRB-PRIV messages.  They MUST NOT be used as a
-   ticket address or in a AP-REQ message.  This address type SHOULD only
-   be used in situations where the sending party knows that the
-   receiving party supports the address type.  This generally means that
-   directional addresses may only be used when the application protocol
-   requires their support.  Directional addresses are type (3).
-
-5.  Principals
-
-   Principals are participants in the Kerberos protocol.  A "realm"
-   consists of principals in one administrative domain, served by one
-   KDC (or one replicated set of KDCs).  Each principal name has an
-   arbitrary number of components, though typical principal names will
-   only have one or two components.  A principal name is meant to be
-   readable by and meaningful to humans, especially in a realm lacking a
-   centrally adminstered authorization infrastructure.
-
-5.1.  Name Types
-
-   Each PrincipalName has NameType indicating what sort of name it is.
-   The name-type SHOULD be treated as a hint.  Ignoring the name type,
-   no two names can be the same (i.e., at least one of the components,
-   or the realm, must be different).
-
-      -- assigned numbers for name types (used in principal names)
-      NameType        ::= Int32
-
-      -- Name type not known
-      nt-unknown              NameType ::= 0
-      -- Just the name of the principal as in DCE, or for users
-      nt-principal            NameType ::= 1
-      -- Service and other unique instance (krbtgt)
-      nt-srv-inst             NameType ::= 2
-      -- Service with host name as instance (telnet, rcommands)
-      nt-srv-hst              NameType ::= 3
-      -- Service with host as remaining components
-      nt-srv-xhst             NameType ::= 4
-      -- Unique ID
-      nt-uid                  NameType ::= 5
-      -- Encoded X.509 Distingished name [RFC 2253]
-      nt-x500-principal       NameType ::= 6
-      -- Name in form of SMTP email name (e.g. user@foo.com)
-      nt-smtp-name            NameType ::= 7
-      -- Enterprise name - may be mapped to principal name
-      nt-enterprise           NameType ::= 10
-
-
-
-Yu                         Expires: Mar 2005                   [Page 19]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-5.2.  Principal Type Definition
-
-      PrincipalName   ::= SEQUENCE {
-          name-type   [0] NameType,
-          -- May have zero elements, or individual elements may be
-          -- zero-length, but this is NOT RECOMMENDED.
-          name-string [1] SEQUENCE OF KerberosString
-      }
-
-
-   name-type
-        hint of the type of name that follows
-
-   name-string
-        The "name-string" encodes a sequence of components that form a
-        name, each component encoded as a KerberosString.  Taken
-        together, a PrincipalName and a Realm form a principal
-        identifier.  Most PrincipalNames will have only a few components
-        (typically one or two).
-
-5.3.  Principal Name Reuse
-
-   Realm administrators SHOULD use extreme caution when considering
-   reusing a principal name.  A service administrator might explicitly
-   enter principal names into a local access control list (ACL) for the
-   service.  If such local ACLs exist independently of a centrally
-   administered authorization infrastructure, realm administrators
-   SHOULD NOT reuse principal names until confirming that all extant ACL
-   entries referencing that principal name have been updated.  Failure
-   to perform this check can result in a security vulnerability, as a
-   new principal can inadvertently inherit unauthorized privileges upon
-   receiving a reused principal name.  An organization whose Kerberos-
-   authenticated services all use a centrally-adminstered authorization
-   infrastructure may not need to take these precautions regarding
-   principal name reuse.
-
-5.4.  Realm Names
-
-      Realm           ::= KerberosString
-
-      -- IA5 only
-      RealmIA5        ::= Realm (KerberosStringIA5)
-
-      -- IA5 excluded
-      RealmExt        ::= Realm (KerberosStringExt)
-
-
-   Kerberos realm names are KerberosStrings.  Realms MUST NOT contain a
-   character with the code 0 (the US-ASCII NUL).  Most realms will
-   usually consist of several components separated by periods (.), in
-   the style of Internet Domain Names, or separated by slashes (/) in
-
-Yu                         Expires: Mar 2005                   [Page 20]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   the style of X.500 names.
-
-5.5.  Printable Representations of Principal Names
-
-   [ perhaps non-normative? ]
-
-   The printable form of a principal name consists of the concatenation
-   of components of the PrincipalName value using the slash character
-   (/), followed by an at-sign (@), followed by the realm name.  Any
-   occurrence of a backslash (\), slash (/) or at-sign (@) in the
-   PrincipalName value is quoted by a backslash.
-
-5.6.  Ticket-Granting Service Principal
-
-   The PrincipalName value corresponding to a ticket-granting service
-   has two components: the first component is the string "krbtgt", and
-   the second component is the realm name of the TGS which will accept a
-   ticket-granting ticket having this service principal name.  The realm
-   name of service always indicates which realm issued the ticket.  A
-   ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
-   obtaining tickets in the same realm would have the following ASN.1
-   values for its "realm" and "sname" components, respectively:
-
-      -- Example Realm and PrincipalName for a TGS
-
-      tgtRealm1       Realm ::= ia5 : "A.EXAMPLE.COM"
-
-      tgtPrinc1       PrincipalName ::= {
-          name-type nt-srv-inst,
-          name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
-      }
-
-   Its printable representation would be written as
-   "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
-
-5.6.1.  Cross-Realm TGS Principals
-
-   It is possible for a principal in one realm to authenticate to a
-   service in another realm.  A KDC can issue a cross-realm ticket-
-   granting ticket to allow one of its principals to authenticate to a
-   service in a foreign realm.  For example, the TGS principal
-   "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
-   client principal in the realm A.EXAMPLE.COM to authenticate to a
-   service in the realm B.EXAMPLE.COM.  When the KDC for B.EXAMPLE.COM
-   issues a ticket to a client originating in A.EXAMPLE.COM, the
-   client's realm name remains "A.EXAMPLE.COM", even though the service
-   principal will have the realm "B.EXAMPLE.COM".
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 21]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-6.  Types Relating to Encryption
-
-   Many Kerberos protocol messages contain encrypted encodings of
-   various data types.  Some Kerberos protocol messages also contain
-   checksums (signatures) of encodings of various types.
-
-6.1.  Assigned Numbers for Encryption
-
-   Encryption algorithm identifiers and key usages both have assigned
-   numbers, described in [KCRYPTO].
-
-6.1.1.  EType
-
-   EType is the integer type for assigned numbers for encryption
-   algorithms.  Defined in [KCRYPTO].
-
-      -- Assigned numbers denoting encryption mechanisms.
-      EType ::= Int32
-
-      -- assigned numbers for encryption schemes
-      et-des-cbc-crc                  EType ::= 1
-      et-des-cbc-md4                  EType ::= 2
-      et-des-cbc-md5                  EType ::= 3
-      --     [reserved]                         4
-      et-des3-cbc-md5                 EType ::= 5
-      --     [reserved]                         6
-      et-des3-cbc-sha1                EType ::= 7
-      et-dsaWithSHA1-CmsOID           EType ::= 9
-      et-md5WithRSAEncryption-CmsOID  EType ::= 10
-      et-sha1WithRSAEncryption-CmsOID EType ::= 11
-      et-rc2CBC-EnvOID                EType ::= 12
-      et-rsaEncryption-EnvOID         EType ::= 13
-      et-rsaES-OAEP-ENV-OID           EType ::= 14
-      et-des-ede3-cbc-Env-OID         EType ::= 15
-      et-des3-cbc-sha1-kd             EType ::= 16
-      -- AES
-      et-aes128-cts-hmac-sha1-96      EType ::= 17
-      -- AES
-      et-aes256-cts-hmac-sha1-96      EType ::= 18
-      -- Microsoft
-      et-rc4-hmac                     EType ::= 23
-      -- Microsoft
-      et-rc4-hmac-exp                 EType ::= 24
-      -- opaque; PacketCable
-      et-subkey-keymaterial           EType ::= 65
-
-
-6.1.2.  Key Usages
-
-   KeyUsage is the integer type for assigned numbers for key usages.
-   Key usage values are inputs to the encryption and decryption
-
-Yu                         Expires: Mar 2005                   [Page 22]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   functions described in [KCRYPTO].
-
-      -- Assigned numbers denoting key usages.
-      KeyUsage ::= UInt32
-
-      --
-      -- Actual identifier names are provisional and subject to
-      -- change.
-      --
-      ku-pa-enc-ts                    KeyUsage ::= 1
-      ku-Ticket                       KeyUsage ::= 2
-      ku-EncASRepPart                 KeyUsage ::= 3
-      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
-      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
-      ku-pa-TGSReq-cksum              KeyUsage ::= 6
-      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
-      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
-      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
-      ku-Authenticator-cksum          KeyUsage ::= 10
-      ku-APReq-authenticator          KeyUsage ::= 11
-      ku-EncAPRepPart                 KeyUsage ::= 12
-      ku-EncKrbPrivPart               KeyUsage ::= 13
-      ku-EncKrbCredPart               KeyUsage ::= 14
-      ku-KrbSafe-cksum                KeyUsage ::= 15
-      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
-
-
-      -- The following numbers are provisional...
-      -- conflicts may exist elsewhere.
-      ku-Ticket-cksum                 KeyUsage ::= 25
-      ku-ASReq-cksum                  KeyUsage ::= 26
-      ku-TGSReq-cksum                 KeyUsage ::= 27
-      ku-ASRep-cksum                  KeyUsage ::= 28
-      ku-TGSRep-cksum                 KeyUsage ::= 29
-      ku-APReq-cksum                  KeyUsage ::= 30
-      ku-APRep-cksum                  KeyUsage ::= 31
-      ku-KrbCred-cksum                KeyUsage ::= 32
-      ku-KrbError-cksum               KeyUsage ::= 33
-      ku-KDCRep-cksum                 KeyUsage ::= 34
-
-
-6.2.  Which Key to Use
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 23]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- KeyToUse identifies which key is to be used to encrypt or
-      -- sign a given value.
-      --
-      -- Values of KeyToUse are never actually transmitted over the
-      -- wire, or even used directly by the implementation in any
-      -- way, as key usages are; it exists primarily to identify
-      -- which key gets used for what purpose.  Thus, the specific
-      -- numeric values associated with this type are irrelevant.
-      KeyToUse        ::= ENUMERATED {
-          -- unspecified
-          key-unspecified,
-          -- server long term key
-          key-server,
-          -- client long term key
-          key-client,
-          -- key selected by KDC for encryption of a KDC-REP
-          key-kdc-rep,
-          -- session key from ticket
-          key-session,
-          -- subsession key negotiated via AP-REQ/AP-REP
-          key-subsession,
-          ...
-      }
-
-
-6.3.  EncryptionKey
-
-   The "EncryptionKey" type holds an encryption key.
-
-      EncryptionKey   ::= SEQUENCE {
-          keytype     [0] EType,
-          keyvalue    [1] OCTET STRING
-      }
-
-
-   keytype
-        This "EType" identifies the encryption algorithm, described in
-        [KCRYPTO].
-
-   keyvalue
-        Contains the actual key.
-
-6.4.  EncryptedData
-
-   The "EncryptedData" type contains the encryption of another data
-   type.  The recipient uses fields within EncryptedData to determine
-   which key to use for decryption.
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 24]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-
-      -- "Type" specifies which ASN.1 type is encrypted to the
-      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
-      -- keys of which one key may be used to encrypt the data.
-      -- "KeyUsages" specifies a set of key usages, one of which may
-      -- be used to encrypt.
-      --
-      -- None of the parameters is transmitted over the wire.
-      EncryptedData {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          etype       [0] EType,
-          kvno        [1] UInt32 OPTIONAL,
-          cipher      [2] OCTET STRING (CONSTRAINED BY {
-              -- must be encryption of --
-              OCTET STRING (CONTAINING Type),
-              -- with one of the keys -- KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          }),
-          ...
-      }
-
-
-
-   KeyUsages
-        Advisory parameter indicating which key usage to use when
-        encrypting the ciphertext.  If "KeyUsages" indicate multiple
-        "KeyUsage" values, the detailed description of the containing
-        message will indicate which key to use under which conditions.
-
-   Type
-        Advisory parameter indicating the ASN.1 type whose DER encoding
-        is the plaintext encrypted into the EncryptedData.
-
-   Keys
-        Advisory parameter indicating which key to use to perform the
-        encryption.  If "Keys" indicate multiple "KeyToUse" values, the
-        detailed description of the containing message will indicate
-        which key to use under which conditions.
-
-   KeyUsages
-        Advisory parameter indicating which "KeyUsage" value is used to
-        encrypt.  If "KeyUsages" indicates multiple "KeyUsage" values,
-        the detailed description of the containing message will indicate
-        which key usage to use under which conditions.
-
-6.5.  Checksums
-
-   Several types contain checksums (actually signatures) of data.
-
-
-Yu                         Expires: Mar 2005                   [Page 25]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      CksumType       ::= Int32
-
-      -- The parameters specify which key to use to produce the
-      -- signature, as well as which key usage to use.  The
-      -- parameters are not actually sent over the wire.
-      Checksum {
-          KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksumtype   [0] CksumType,
-          checksum    [1] OCTET STRING (CONSTRAINED BY {
-              -- signed using one of the keys --
-              KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          })
-      }
-
-
-   CksumType
-        Integer type for assigned numbers for signature algorithms.
-        Defined in [KCRYPTO]
-
-   Keys
-        As in EncryptedData
-
-   KeyUsages
-        As in EncryptedData
-
-   cksumtype
-        Signature algorithm used to produce the signature.
-
-   checksum
-        The actual checksum.
-
-6.5.1.  ChecksumOf
-
-   ChecksumOf is similar to "Checksum", but specifies which type is
-   signed.
-
-      -- a Checksum that must contain the checksum
-      -- of a particular type
-      ChecksumOf {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
-          ...,
-          checksum (CONSTRAINED BY {
-              -- must be checksum of --
-              OCTET STRING (CONTAINING Type)
-          })
-      })
-
-
-Yu                         Expires: Mar 2005                   [Page 26]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   Type
-        Indicates the ASN.1 type whose DER encoding is signed.
-
-6.5.2.  Signed
-
-   Signed is similar to "ChecksumOf", but contains an actual instance of
-   the type being signed in addition to the signature.
-
-      -- parameterized type for wrapping authenticated plaintext
-      Signed {
-          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksum       [0] ChecksumOf {
-              InnerType, Keys, KeyUsages
-          } OPTIONAL,
-          inner       [1] InnerType,
-          ...
-      }
-
-
-7.  Tickets
-
-   [ A large number of items described here are duplicated in the
-   sections describing KDC-REQ processing.  Should find a way to avoid
-   this duplication. ]
-
-   A ticket binds a principal name to a session key.  The important
-   fields of a ticket are in the encrypted part.  The components in
-   common between the RFC 1510 and the extensible versions are
-
-      EncTicketPartCommon ::= SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] Realm,
-          cname               [3] PrincipalName,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-   crealm
-        This field contains the client's realm.
-
-   cname
-        This field contains the client's name.
-
-Yu                         Expires: Mar 2005                   [Page 27]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   caddr
-        This field lists the network addresses (if absent, all addresses
-        are permitted) from which the ticket is valid.
-
-   Descriptions of the other fields appear in the following sections.
-
-7.1.  Timestamps
-
-   Three of the ticket timestamps may be requested from the KDC.  The
-   timestamps may differ from those requested, depending on site policy.
-
-   authtime
-        The time at which the client authenticated, as recorded by the
-        KDC.
-
-   starttime
-        The earliest time when the ticket is valid.  If not present, the
-        ticket is valid starting at the authtime.  This is requested as
-        the "from" field of KDC-REQ-BODY-COMMON.
-
-   endtime
-        This time is requested in the "till" field of KDC-REQ-BODY-
-        COMMON.  Contains the time after which the ticket will not be
-        honored (its expiration time).  Note that individual services
-        MAY place their own limits on the life of a ticket and MAY
-        reject tickets which have not yet expired.  As such, this is
-        really an upper bound on the expiration time for the ticket.
-
-   renew-till
-        This time is requested in the "rtime" field of KDC-REQ-BODY-
-        COMMON.  It is only present in tickets that have the "renewable"
-        flag set in the flags field.  It indicates the maximum endtime
-        that may be included in a renewal.  It can be thought of as the
-        absolute expiration time for the ticket, including all renewals.
-
-7.2.  Ticket Flags
-
-   A number of flags may be set in the ticket, further defining some of
-   its capabilities.  Some of these flags map to flags in a KDC request.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 28]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
-
-      TicketFlagsBits ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          may-postdate        (5),
-          postdated           (6),
-          invalid             (7),
-          renewable           (8),
-          initial             (9),
-          pre-authent         (10),
-          hw-authent          (11),
-          transited-policy-checked (12),
-          ok-as-delegate      (13),
-          anonymous           (14),
-          cksummed-ticket     (15)
-      }
-
-
-7.2.1.  Flags Relating to Initial Ticket Acquisition
-
-   [ adapted KCLAR 2.1. ]
-
-   Several flags indicate the details of how the initial ticket was
-   acquired.
-
-   initial
-        The "initial" flag indicates that a ticket was issued using the
-        AS protocol, rather than issued based on a ticket-granting
-        ticket.  Application servers (e.g., a password-changing program)
-        requiring a client's definite knowledge of its secret key can
-        insist that this flag be set in any tickets they accept, thus
-        being assured that the client's key was recently presented to
-        the application client.
-
-   pre-authent
-        The "pre-authent" flag indicates that some sort of pre-
-        authentication was used during the AS exchange.
-
-   hw-authent
-        The "hw-authent" flag indicates that some sort of hardware-based
-        pre-authentication occurred during the AS exchange.
-
-   Both the "pre-authent" and the "hw-authent" flags may be present with
-   or without the "initial" flag; such tickets with the "initial" flag
-   clear are ones which are derived from initial tickets with the "pre-
-   authent" or "hw-authent" flags set.
-
-
-Yu                         Expires: Mar 2005                   [Page 29]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-7.2.2.  Invalid Tickets
-
-   [ KCLAR 2.2. ]
-
-   The "invalid" flag indicates that a ticket is invalid.  Application
-   servers MUST reject tickets which have this flag set.  A postdated
-   ticket will be issued in this form.  Invalid tickets MUST be
-   validated by the KDC before use, by presenting them to the KDC in a
-   TGS request with the "validate" option specified.  The KDC will only
-   validate tickets after their starttime has passed.  The validation is
-   required so that postdated tickets which have been stolen before
-   their starttime can be rendered permanently invalid (through a hot-
-   list mechanism -- see Section 8.3.2.4).
-
-7.2.3.  OK as Delegate
-
-   [ KCLAR 2.8. ]
-
-   The "ok-as-delegate" flag provides a way for a KDC to communicate
-   local realm policy to a client regarding whether the service for
-   which the ticket is issued is trusted to accept delegated
-   credentials.  For some applications, a client may need to delegate
-   credentials to a service to act on its behalf in contacting other
-   services.  The ability of a client to obtain a service ticket for a
-   service conveys no information to the client about whether the
-   service should be trusted to accept delegated credentials.
-
-   The copy of the ticket flags visible to the client may have the "ok-
-   as-delegate" flag set to indicate to the client that the service
-   specified in the ticket has been determined by policy of the realm to
-   be a suitable recipient of delegation.  A client can use the presence
-   of this flag to help it make a decision whether to delegate
-   credentials (either grant a proxy or a forwarded ticket-granting
-   ticket) to this service.  It is acceptable to ignore the value of
-   this flag.  When setting this flag, an administrator should consider
-   the security and placement of the server on which the service will
-   run, as well as whether the service requires the use of delegated
-   credentials.
-
-7.2.4.  Renewable Tickets
-
-   [ adapted KCLAR 2.3. ]
-
-   The "renewable" flag indicates whether the ticket may be renewed.
-
-   Renewable tickets can be used to mitigate the consequences of ticket
-   theft.  Applications may desire to hold credentials which can be
-   valid for long periods of time.  However, this can expose the
-   credentials to potential theft for equally long periods, and those
-   stolen credentials would be valid until the expiration time of the
-   ticket(s).  Simply using short-lived tickets and obtaining new ones
-
-Yu                         Expires: Mar 2005                   [Page 30]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   periodically would require the application to have long-term access
-   to the client's secret key, which is an even greater risk.
-
-   Renewable tickets have two "expiration times": the first is when the
-   current instance of the ticket expires, and the second is the latest
-   permissible value for an individual expiration time.  An application
-   client must periodically present an unexpired renewable ticket to the
-   KDC, setting the "renew" option in the KDC request.  The KDC will
-   issue a new ticket with a new session key and a later expiration
-   time.  All other fields of the ticket are left unmodified by the
-   renewal process.  When the latest permissible expiration time
-   arrives, the ticket expires permanently.  At each renewal, the KDC
-   MAY consult a hot-list to determine if the ticket had been reported
-   stolen since its last renewal; it will refuse to renew such stolen
-   tickets, and thus the usable lifetime of stolen tickets is reduced.
-
-   The "renewable" flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can usually be ignored by application
-   servers.  However, some particularly careful application servers MAY
-   disallow renewable tickets.
-
-   If a renewable ticket is not renewed by its expiration time, the KDC
-   will not renew the ticket.  The "renewable" flag is clear by default,
-   but a client can request it be set by setting the "renewable" option
-   in the AS-REQ message.  If it is set, then the "renew-till" field in
-   the ticket contains the time after which the ticket may not be
-   renewed.
-
-7.2.5.  Postdated Tickets
-
-   postdated
-        indicates a ticket which has been postdated
-
-   may-postdate
-        indicates that postdated tickets may be issued based on this
-        ticket
-
-   [ KCLAR 2.4. ]
-
-   Applications may occasionally need to obtain tickets for use much
-   later, e.g., a batch submission system would need tickets to be valid
-   at the time the batch job is serviced.  However, it is dangerous to
-   hold valid tickets in a batch queue, since they will be on-line
-   longer and more prone to theft.  Postdated tickets provide a way to
-   obtain these tickets from the KDC at job submission time, but to
-   leave them "dormant" until they are activated and validated by a
-   further request of the KDC.  If a ticket theft were reported in the
-   interim, the KDC would refuse to validate the ticket, and the thief
-   would be foiled.
-
-
-
-Yu                         Expires: Mar 2005                   [Page 31]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   The "may-postdate" flag in a ticket is normally only interpreted by
-   the TGS.  It can be ignored by application servers.  This flag MUST
-   be set in a ticket-granting ticket in order for the KDC to issue a
-   postdated ticket based on the presented ticket.  It is reset by
-   default; it MAY be requested by a client by setting the "allow-
-   postdate" option in the AS-REQ [?also TGS-REQ?] message.  This flag
-   does not allow a client to obtain a postdated ticket-granting ticket;
-   postdated ticket-granting tickets can only by obtained by requesting
-   the postdating in the AS-REQ message.  The life (endtime minus
-   starttime) of a postdated ticket will be the remaining life of the
-   ticket-granting ticket at the time of the request, unless the
-   "renewable" option is also set, in which case it can be the full life
-   (endtime minus starttime) of the ticket-granting ticket.  The KDC MAY
-   limit how far in the future a ticket may be postdated.
-
-   The "postdated" flag indicates that a ticket has been postdated.  The
-   application server can check the authtime field in the ticket to see
-   when the original authentication occurred.  Some services MAY choose
-   to reject postdated tickets, or they may only accept them within a
-   certain period after the original authentication.  When the KDC
-   issues a "postdated" ticket, it will also be marked as "invalid", so
-   that the application client MUST present the ticket to the KDC for
-   validation before use.
-
-7.2.6.  Proxiable and Proxy Tickets
-
-   proxy
-        indicates a proxy ticket
-
-   proxiable
-        indicates that proxy tickets may be issued based on this ticket
-
-   [ KCLAR 2.5. ]
-
-   It may be necessary for a principal to allow a service to perform an
-   operation on its behalf.  The service must be able to take on the
-   identity of the client, but only for a particular purpose.  A
-   principal can allow a service to take on the principal's identity for
-   a particular purpose by granting it a proxy.
-
-   The process of granting a proxy using the "proxy" and "proxiable"
-   flags is used to provide credentials for use with specific services.
-   Though conceptually also a proxy, users wishing to delegate their
-   identity in a form usable for all purposes MUST use the ticket
-   forwarding mechanism described in the next section to forward a
-   ticket-granting ticket.
-
-   The "proxiable" flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can be ignored by application servers.
-   When set, this flag tells the ticket-granting server that it is OK to
-   issue a new ticket (but not a ticket-granting ticket) with a
-
-Yu                         Expires: Mar 2005                   [Page 32]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   different network address based on this ticket.  This flag is set if
-   requested by the client on initial authentication.  By default, the
-   client will request that it be set when requesting a ticket-granting
-   ticket, and reset when requesting any other ticket.
-
-   This flag allows a client to pass a proxy to a server to perform a
-   remote request on its behalf (e.g. a print service client can give
-   the print server a proxy to access the client's files on a particular
-   file server in order to satisfy a print request).
-
-   In order to complicate the use of stolen credentials, Kerberos
-   tickets may contain a set of network addresses from which they are
-   valid.  When granting a proxy, the client MUST specify the new
-   network address from which the proxy is to be used, or indicate that
-   the proxy is to be issued for use from any address.
-
-   The "proxy" flag is set in a ticket by the TGS when it issues a proxy
-   ticket.  Application servers MAY check this flag and at their option
-   they MAY require additional authentication from the agent presenting
-   the proxy in order to provide an audit trail.
-
-7.2.7.  Forwarded and Forwardable Tickets
-
-   forwarded
-        indicates a forwarded ticket
-
-   forwardable
-        indicates that forwarded tickets may be issued based on this
-        ticket
-
-   [ KCLAR 2.6. ]
-
-   Authentication forwarding is an instance of a proxy where the service
-   that is granted is complete use of the client's identity.  An example
-   where it might be used is when a user logs in to a remote system and
-   wants authentication to work from that system as if the login were
-   local.
-
-   The "forwardable" flag in a ticket is normally only interpreted by
-   the ticket-granting service.  It can be ignored by application
-   servers.  The "forwardable" flag has an interpretation similar to
-   that of the "proxiable" flag, except ticket-granting tickets may also
-   be issued with different network addresses.  This flag is reset by
-   default, but users MAY request that it be set by setting the
-   "forwardable" option in the AS request when they request their
-   initial ticket-granting ticket.
-
-   This flag allows for authentication forwarding without requiring the
-   user to enter a password again.  If the flag is not set, then
-   authentication forwarding is not permitted, but the same result can
-   still be achieved if the user engages in the AS exchange specifying
-
-Yu                         Expires: Mar 2005                   [Page 33]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   the requested network addresses and supplies a password.
-
-   The "forwarded" flag is set by the TGS when a client presents a
-   ticket with the "forwardable" flag set and requests a forwarded
-   ticket by specifying the "forwarded" KDC option and supplying a set
-   of addresses for the new ticket.  It is also set in all tickets
-   issued based on tickets with the "forwarded" flag set.  Application
-   servers may choose to process "forwarded" tickets differently than
-   non-forwarded tickets.
-
-   If addressless tickets are forwarded from one system to another,
-   clients SHOULD still use this option to obtain a new TGT in order to
-   have different session keys on the different systems.
-
-7.3.  Transited Realms
-
-   [ KCLAR 2.7., plus new stuff ]
-
-7.4.  Authorization Data
-
-   [ KCLAR 5.2.6. ]
-
-      ADType          ::= TH-id
-
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-          ad-type             [0] ADType,
-          ad-data             [1] OCTET STRING
-      }
-
-
-   ad-type
-        This field identifies the contents of the ad-data.  All negative
-        values are reserved for local use.  Non-negative values are
-        reserved for registered use.
-
-   ad-data
-        This field contains authorization data to be interpreted
-        according to the value of the corresponding ad-type field.
-
-   Each sequence of ADType and OCTET STRING is referred to as an
-   authorization element.  Elements MAY be application specific,
-   however, there is a common set of recursive elements that should be
-   understood by all implementations.  These elements contain other
-   AuthorizationData, and the interpretation of the encapsulating
-   element determines which enclosed elements must be interpreted, and
-   which may be ignored.
-
-   Depending on the meaning of the encapsulating element, the
-   encapsulated AuthorizationData may be ignored, interpreted as issued
-   directly by the KDC, or be stored in a separate plaintext part of the
-   ticket.  The types of the encapsulating elements are specified as
-
-Yu                         Expires: Mar 2005                   [Page 34]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   part of the Kerberos protocol because behavior based on these
-   container elements should be understood across implementations, while
-   other elements need only be understood by the applications which they
-   affect.
-
-   Authorization data elements are considered critical if present in a
-   ticket or authenticator.  Unless encapsulated in a known
-   authorization data element modifying the criticality of the elements
-   it contains, an application server MUST reject the authentication of
-   a client whose AP-REQ or ticket contains an unrecognized
-   authorization data element.  Authorization data is intended to
-   restrict the use of a ticket.  If the service cannot determine
-   whether it is the target of a restriction, a security weakness may
-   exist if the ticket can be used for that service.  Authorization
-   elements that are truly optional can be enclosed in AD-IF-RELEVANT
-   element.
-
-
-      ad-type |           contents of ad-data
-      ________|_______________________________________
-            1 |   DER encoding of AD-IF-RELEVANT
-            4 |   DER encoding of AD-KDCIssued
-            5 |   DER encoding of AD-AND-OR
-            8 |   DER encoding of AD-MANDATORY-FOR-KDC
-
-
-
-7.4.1.  AD-IF-RELEVANT
-
-      ad-if-relevant          ADType ::= int32 : 1
-
-      -- Encapsulates another AuthorizationData.
-      -- Intended for application servers; receiving application servers
-      -- MAY ignore.
-      AD-IF-RELEVANT          ::= AuthorizationData
-
-   AD elements encapsulated within the if-relevant element are intended
-   for interpretation only by application servers that understand the
-   particular ad-type of the embedded element. Application servers that
-   do not understand the type of an element embedded within the if-
-   relevant element MAY ignore the uninterpretable element. This element
-   promotes interoperability across implementations which may have local
-   extensions for authorization.  The ad-type for AD-IF-RELEVANT is (1).
-
-7.4.2.  AD-KDCIssued
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 35]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- KDC-issued privilege attributes
-      ad-kdcissued            ADType ::= int32 : 4
-
-      AD-KDCIssued            ::= SEQUENCE {
-          ad-checksum [0] ChecksumOf {
-                              AuthorizationData, { key-session },
-                              { ku-ad-KDCIssued-cksum }},
-          i-realm     [1] Realm OPTIONAL,
-          i-sname     [2] PrincipalName OPTIONAL,
-          elements    [3] AuthorizationData
-      }
-
-
-   ad-checksum
-        A cryptographic checksum computed over the DER encoding of the
-        AuthorizationData in the "elements" field, keyed with the
-        session key.  Its checksumtype is the mandatory checksum type
-        for the encryption type of the session key, and its key usage
-        value is 19.
-
-   i-realm, i-sname
-        The name of the issuing principal if different from the KDC
-        itself.  This field would be used when the KDC can verify the
-        authenticity of elements signed by the issuing principal and it
-        allows this KDC to notify the application server of the validity
-        of those elements.
-
-   elements
-        AuthorizationData issued by the KDC.
-
-   The KDC-issued ad-data field is intended to provide a means for
-   Kerberos credentials to embed within themselves privilege attributes
-   and other mechanisms for positive authorization, amplifying the
-   privileges of the principal beyond what it would have if using
-   credentials without such an authorization-data element.
-
-   This amplification of privileges cannot be provided without this
-   element because the definition of the authorization-data field allows
-   elements to be added at will by the bearer of a TGT at the time that
-   they request service tickets and elements may also be added to a
-   delegated ticket by inclusion in the authenticator.
-
-   For KDC-issued elements this is prevented because the elements are
-   signed by the KDC by including a checksum encrypted using the
-   server's key (the same key used to encrypt the ticket -- or a key
-   derived from that key).  AuthorizationData encapsulated with in the
-   AD-KDCIssued element MUST be ignored by the application server if
-   this "signature" is not present.  Further, AuthorizationData
-   encapsulated within this element from a ticket-granting ticket MAY be
-   interpreted by the KDC, and used as a basis according to policy for
-   including new signed elements within derivative tickets, but they
-
-Yu                         Expires: Mar 2005                   [Page 36]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   will not be copied to a derivative ticket directly.  If they are
-   copied directly to a derivative ticket by a KDC that is not aware of
-   this element, the signature will not be correct for the application
-   ticket elements, and the field will be ignored by the application
-   server.
-
-   This element and the elements it encapsulates MAY be safely ignored
-   by applications, application servers, and KDCs that do not implement
-   this element.
-
-   The ad-type for AD-KDC-ISSUED is (4).
-
-7.4.3.  AD-AND-OR
-
-      ad-and-or               ADType ::= int32 : 5
-
-      AD-AND-OR               ::= SEQUENCE {
-          condition-count     [0] INTEGER,
-          elements            [1] AuthorizationData
-      }
-
-
-   When restrictive AD elements are encapsulated within the and-or
-   element, the and-or element is considered satisfied if and only if at
-   least the number of encapsulated elements specified in condition-
-   count are satisfied.  Therefore, this element MAY be used to
-   implement an "or" operation by setting the condition-count field to
-   1, and it MAY specify an "and" operation by setting the condition
-   count to the number of embedded elements. Application servers that do
-   not implement this element MUST reject tickets that contain
-   authorization data elements of this type.
-
-   The ad-type for AD-AND-OR is (5).
-
-7.4.4.  AD-MANDATORY-FOR-KDC
-
-      -- KDCs MUST interpret any AuthorizationData wrapped in this.
-      ad-mandatory-for-kdc            ADType ::= int32 : 8
-      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
-
-   AD elements encapsulated within the mandatory-for-kdc element are to
-   be interpreted by the KDC.  KDCs that do not understand the type of
-   an element embedded within the mandatory-for-kdc element MUST reject
-   the request.
-
-   The ad-type for AD-MANDATORY-FOR-KDC is (8).
-
-7.5.  Encrypted Part of Ticket
-
-   The complete definition of the encrypted part is
-
-
-Yu                         Expires: Mar 2005                   [Page 37]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- Encrypted part of ticket
-      EncTicketPart ::= CHOICE {
-          rfc1510     [APPLICATION 3] EncTicketPart1510,
-          ext         [APPLICATION 5] EncTicketPartExt
-      }
-
-   with the common portion being
-
-      EncTicketPartCommon ::= SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] Realm,
-          cname               [3] PrincipalName,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-   The encrypted part of the backwards-compatibility form of a ticket
-   is:
-
-      EncTicketPart1510 ::= SEQUENCE {
-          COMPONENTS OF EncTicketPartCommon
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-   The encrypted part of the extensible form of a ticket is:
-
-      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          crealm (RealmExt),
-          cname (PrincipalNameExt),
-          -- explicitly constrain caddr to be non-empty if present
-          caddr (SIZE (1..MAX)),
-          -- forbid empty authorization-data encodings
-          authorization-data (SIZE (1..MAX))
-      })
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 38]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-7.6.  Cleartext Part of Ticket
-
-   The complete definition of Ticket is:
-
-      Ticket          ::= CHOICE {
-          rfc1510     [APPLICATION 1] Ticket1510,
-          ext         [APPLICATION 4] Signed {
-              TicketExt, { key-server }, { ku-Ticket-cksum }
-          }
-      }
-
-   with the common portion being:
-
-      -- takes a parameter specifying which type gets encrypted
-      TicketCommon { EncPart } ::= SEQUENCE {
-          tkt-vno     [0] INTEGER (5),
-          realm       [1] Realm,
-          sname       [2] PrincipalName,
-          enc-part    [3] EncryptedData {
-              EncPart, { key-server }, { ku-Ticket }
-          },
-          ...,
-          extensions          [4] TicketExtensions OPTIONAL,
-          ...
-      }
-
-
-   The "sname" field provides the name of the target service principal
-   in cleartext, as a hint to aid the server in choosing the correct
-   decryption key.
-
-   The backwards-compatibility form of Ticket is:
-
-      Ticket1510 ::= SEQUENCE {
-          COMPONENTS OF TicketCommon { EncTicketPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          realm (RealmIA5),
-          sname (PrincipalNameIA5)
-      })
-
-   The extensible form of Ticket is:
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 39]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      TicketExt ::= [APPLICATION 4] TicketCommon {
-          EncTicketPartExt
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          realm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-   TicketExtensions, which may only be present in the extensible form of
-   Ticket, are a cleartext typed hole for extension use.
-   AuthorizationData already provides an encrypted typed hole.
-
-      TEType                  ::= TH-id
-
-      -- ticket extensions: for TicketExt only
-      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          te-type             [0] TEType,
-          te-data             [1] OCTET STRING
-      }
-
-
-   A client will only receive an extensible Ticket if the application
-   server supports extensibility.
-
-8.  Credential Acquisition
-
-   There are two exchanges that can be used for acquiring credentials:
-   the AS exchange and the TGS exchange.  These exchanges have many
-   similarities, and this document describes them in parallel, noting
-   which behaviors are specific to one type of exchange.  The AS request
-   (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
-   (KDC-REQ).  Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
-   are forms of KDC replies (KDC-REP).
-
-   The credentials acquisition protocol operates over specific
-   transports.  Additionally, specific methods exist to permit a client
-   to discover the KDC host with which to communicate.
-
-8.1.  KDC-REQ
-
-   The KDC-REQ has a large number of fields in common between the RFC
-   1510 and the extensible versions.  The KDC-REQ type itself is never
-   directly encoded; it is always a part of a AS-REQ or a TGS-REQ.
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 40]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KDC-REQ-COMMON  ::= SEQUENCE {
-      -- NOTE: first tag is [1], not [0]
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
-                                   | 12 -- TGS-REQ.rfc1510 --
-                                   | 6 -- AS-REQ.ext --
-                                   | 8 -- TGS-REQ.ext -- ),
-          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
-          -- NOTE: not empty
-      }
-
-
-      KDC-REQ-BODY-COMMON     ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalName OPTIONAL
-          -- Used only in AS-REQ --,
-
-          realm               [2] Realm
-          -- Server's realm; also client's in AS-REQ --,
-
-          sname               [3] PrincipalName OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime OPTIONAL
-          -- was required in rfc1510;
-          -- still required for compat versions
-          -- of messages --,
-
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --,
-          ...
-          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
-                              LangTag OPTIONAL,
-          ...
-      }
-
-
-   Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of
-   an EncTicketPartCommon.  The KDC copies most of them unchanged,
-   provided that the requested values meet site policy.
-
-Yu                         Expires: Mar 2005                   [Page 41]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   kdc-options
-        These flags do not correspond directly to "flags" in
-        EncTicketPartCommon.
-
-   cname
-        This field is copied to the "cname" field in
-        EncTicketPartCommon.  The "cname" field is required in an AS-
-        REQ; the client places its own name here.  In a TGS-REQ, the
-        "cname" in the ticket in the AP-REQ takes precedence.
-
-   realm
-        This field is the server's realm, and also holds the client's
-        realm in an AS-REQ.
-
-   sname
-        The "sname" field indicates the server's name.  It may be absent
-        in a TGS-REQ which requests user-to-user authentication, in
-        which case the "sname" of the issued ticket will be taken from
-        the included additional ticket.
-
-   The "from", "till", and "rtime" fields correspond to the "starttime",
-   "endtime", and "renew-till" fields of EncTicketPartCommon.
-
-   addresses
-        This field corresponds to the "caddr" field of
-        EncTicketPartCommon.
-
-   enc-authorization-data
-        For TGS-REQ, this field contains authorization data encrypted
-        using either the TGT session key or the AP-REQ subsession key;
-        the KDC may copy these into the "authorization-data" field of
-        EncTicketPartCommon if policy permits.
-
-   lang-tags
-        Only present in the extensible messages.  Specifies the set of
-        languages which the client is willing to accept in error
-        messages.
-
-   KDC options used in a KDC-REQ are:
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 42]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
-
-      KDCOptionsBits  ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          allow-postdate      (5),
-          postdated           (6),
-          unused7             (7),
-          renewable           (8),
-          unused9             (9),
-          unused10            (10),
-          unused11            (11),
-          unused12            (12),
-          unused13            (13),
-          requestanonymous    (14),
-          canonicalize        (15),
-          disable-transited-check (26),
-          renewable-ok        (27),
-          enc-tkt-in-skey     (28),
-          renew               (30),
-          validate            (31)
-          -- XXX need "need ticket1" flag?
-      }
-
-   Different options apply to different phases of KDC-REQ processing.
-
-   The backwards-compatibility form of a KDC-REQ is:
-
-      KDC-REQ-1510    ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-1510
-      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
-
-   The extensible form of a KDC-REQ is:
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      KDC-REQ-EXT     ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-EXT,
-          ...
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (6 | 8),
-          padata (SIZE (1..MAX))
-      })
-
-   The backwards-compatibility form of a KDC-REQ-BODY is:
-
-Yu                         Expires: Mar 2005                   [Page 43]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KDC-REQ-BODY-1510 ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-BODY-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          cname (PrincipalNameIA5),
-          realm (RealmIA5),
-          sname (PrincipalNameIA5),
-          till PRESENT,
-          nonce (UInt32)
-      })
-
-   The extensible form of a KDC-REQ-BODY is:
-
-      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
-      (WITH COMPONENTS {
-          ...,
-          cname (PrincipalNameExt),
-          realm (RealmExt),
-          sname (PrincipalNameExt),
-          addresses (SIZE (1..MAX)),
-          enc-authorization-data (EncryptedData {
-              AuthorizationData (SIZE (1..MAX)),
-              { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          }),
-          additional-tickets (SIZE (1..MAX))
-      })
-
-   The AS-REQ is:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 44]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      AS-REQ  ::= CHOICE {
-          rfc1510     [APPLICATION 10] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (10),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          }),
-          ext         [APPLICATION 6]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as
-              -- outside, to prevent possible substitution attacks.
-              [APPLICATION 6] KDC-REQ-EXT,
-              -- not sure this is correct key to use; do we even want
-              -- to sign AS-REQ?
-              { key-client },
-              { ku-ASReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (6),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          })
-      }
-
-   A client SHOULD NOT send the extensible AS-REQ alternative to a KDC
-   if the client does not know that the KDC supports the extensibility
-   framework.  A client SHOULD send the extensible AS-REQ alternative in
-   a PA-AS-REQ PA-DATA.  A KDC supporting extensibility will treat the
-   AS-REQ contained within the PA-AS-REQ as the actual AS-REQ.  [ XXX
-   what if their contents conflict? ]
-
-   The TGS-REQ is:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 45]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      TGS-REQ ::= CHOICE {
-          rfc1510     [APPLICATION 12] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (12),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          }),
-          ext         [APPLICATION 8]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as
-              -- outside, to prevent possible substitution attacks.
-              [APPLICATION 8] KDC-REQ-EXT,
-              { key-session }, { ku-TGSReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (8),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          })
-      }
-
-
-8.2.  PA-DATA
-
-   PA-DATA have multiple uses in the Kerberos protocol.  They may pre-
-   authenticate an AS-REQ; they may also modify several of the
-   encryption keys used in a KDC-REP.  PA-DATA may also provide "hints"
-   to the client about which long-term key (usually password-derived) to
-   use.  PA-DATA may also include "hints" about which pre-authentication
-   mechanisms to use, or include data for input into a pre-
-   authentication mechanism.
-
-   [ XXX enumerate standard padata here ]
-
-8.3.  KDC-REQ Processing
-
-   Processing of a KDC-REQ proceeds through several steps.  An
-   implementation need not perform these steps exactly as described, as
-   long as it behaves as if the steps were performed as described.  The
-   KDC performs replay handling upon receiving the request; it then
-   validates the request, adjusts timestamps, and selects the keys used
-   in the reply.  It copies data from the request into the issued
-   ticket, adjusting the values to conform with its policies.  The KDC
-   then transmits the reply to the client.
-
-8.3.1.  Handling Replays
-
-   Because Kerberos can run over unreliable transports such as UDP, the
-   KDC MUST be prepared to retransmit responses in case they are lost.
-   If a KDC receives a request identical to one it has recently
-
-Yu                         Expires: Mar 2005                   [Page 46]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   successfully processed, the KDC MUST respond with a KDC-REP message
-   rather than a replay error.  In order to reduce the amount of
-   ciphertext given to a potential attacker, KDCs MAY send the same
-   response generated when the request was first handled.  KDCs MUST
-   obey this replay behavior even if the actual transport in use is
-   reliable.  If the AP-REQ which authenticates a TGS-REQ is a replay,
-   and the entire request is not identical to a recently successfully
-   processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
-   appropriate for AP-REQ processing.
-
-8.3.2.  Request Validation
-
-8.3.2.1.  AS-REQ Authentication
-
-   Site policy determines whether a given client principal is required
-   to provide some pre-authentication prior to receiving an AS-REP.
-   Since the default reply key is typically the client's long-term
-   password-based key, an attacker may easily request known plaintext
-   (in the form of an AS-REP) upon which to mount a dictionary attack.
-   Pre-authentication can limit the possibility of such an attack.
-
-   If site policy requires pre-authentication for a client principal,
-   and no pre-authentication is provided, the KDC returns the error
-   "kdc-err-preauth-required".  Accompanying this error are "e-data"
-   which include hints telling the client which pre-authentication
-   mechanisms to use, or data for input to pre-authentication mechanisms
-   (e.g., input to challenge-response systems).  If pre-authentication
-   fails, the KDC returns the error "kdc-err-preauth-failed".
-
-   [ may need additional changes based on Sam's preauth draft ]
-
-8.3.2.2.  TGS-REQ Authentication
-
-   A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
-   tgs-req".  The KDC MUST validate the checksum in the Authenticator of
-   the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
-   BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
-   request.  [ padata not signed by authenticator! ] Any error from the
-   AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
-   The service principal in the ticket of the AP-REQ may be a ticket-
-   granting service principal, or a normal application service
-   principal.  A ticket which is not a ticket-granting ticket MUST NOT
-   be used to issue a ticket for any service other than the one named in
-   the ticket.  In this case, the "renew", "validate", or "proxy" [?also
-   forwarded?]  option must be set in the request.
-
-8.3.2.3.  Principal Validation
-
-   If the client principal in an AS-REQ is unknown, the KDC returns the
-   error "kdc-err-c-principal-unknown".  If the server principal in a
-   KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
-
-Yu                         Expires: Mar 2005                   [Page 47]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   unknown".
-
-8.3.2.4.  Checking For Revoked or Invalid Tickets
-
-   [ KCLAR 3.3.3.1 ]
-
-   Whenever a request is made to the ticket-granting server, the
-   presented ticket(s) is(are) checked against a hot-list of tickets
-   which have been canceled.  This hot-list might be implemented by
-   storing a range of issue timestamps for "suspect tickets"; if a
-   presented ticket had an authtime in that range, it would be rejected.
-   In this way, a stolen ticket-granting ticket or renewable ticket
-   cannot be used to gain additional tickets (renewals or otherwise)
-   once the theft has been reported to the KDC for the realm in which
-   the server resides.  Any normal ticket obtained before it was
-   reported stolen will still be valid (because they require no
-   interaction with the KDC), but only until their normal expiration
-   time.  If TGTs have been issued for cross-realm authentication, use
-   of the cross-realm TGT will not be affected unless the hot-list is
-   propagated to the KDCs for the realms for which such cross-realm
-   tickets were issued.
-
-   If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
-   issue any ticket unless the TGS-REQ requests the "validate" option.
-
-8.3.3.  Timestamp Handling
-
-   [ some aspects of timestamp handling, especially regarding postdating
-   and renewal, are difficult to read in KCLAR... needs closer
-   examination here ]
-
-   Processing of "starttime" (requested in the "from" field) differs
-   depending on whether the "postdated" option is set in the request.
-   If the "postdated" option is not set, and the requested "starttime"
-   is in the future beyond the window of acceptable clock skew, the KDC
-   returns the error "kdc-err-cannot-postdate".  If the "postdated"
-   option is not set, and the requested "starttime" is absent or does
-   not indicate a time in the future beyond the acceptable clock skew,
-   the KDC sets the "starttime" to the KDC's current time.  The
-   "postdated" option MUST NOT be honored if the ticket is being
-   requested by TGS-REQ and the "may-postdate" is not set in the TGT.
-   Otherwise, if the "postdated" option is set, and site policy permits,
-   the KDC sets the "starttime" as requested, and sets the "invalid"
-   flag in the new ticket.
-
-   The "till" field is required in the RFC 1510 version of the KDC-REQ.
-   If the "till" field is equal to "19700101000000Z" (midnight, January
-   1, 1970), the KDC SHOULD behave as if the "till" field were absent.
-
-   The KDC MUST NOT issue a ticket whose "starttime", "endtime", or
-   "renew-till" time is later than the "renew-till" time of the ticket
-
-Yu                         Expires: Mar 2005                   [Page 48]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   from which it is derived.
-
-8.3.3.1.  AS-REQ Timestamp Processing
-
-   In the AS exchange, the "authtime" of a ticket is set to the local
-   time at the KDC.
-
-   The "endtime" of the ticket will be set to the earlier of the
-   requested "till" time and a time determined by local policy, possibly
-   determined using factors specific to the realm or principal.  For
-   example, the expiration time MAY be set to the earliest of the
-   following:
-
-      * the expiration time ("till" value) requested
-
-      * the ticket's start time plus the maximum allowable lifetime
-        associated with the client principal from the authentication
-        server's database
-
-      * the ticket's start time plus the maximum allowable lifetime
-        associated with the server principal
-
-      * the ticket's start time plus the maximum lifetime set by the
-        policy of the local realm
-
-   If the requested expiration time minus the start time (as determined
-   above) is less than a site-determined minimum lifetime, an error
-   message with code "kdc-err-never-valid" is returned.  If the
-   requested expiration time for the ticket exceeds what was determined
-   as above, and if the "renewable-ok" option was requested, then the
-   "renewable" flag is set in the new ticket, and the "renew-till" value
-   is set as if the "renewable" option were requested.
-
-   If the "renewable" option has been requested or if the "renewable-ok"
-   option has been set and a renewable ticket is to be issued, then the
-   "renew-till" field MAY be set to the earliest of:
-
-      * its requested value
-
-      * the start time of the ticket plus the minimum of the two maximum
-        renewable lifetimes associated with the principals' database
-        entries
-
-      * the start time of the ticket plus the maximum renewable lifetime
-        set by the policy of the local realm
-
-8.3.3.2.  TGS-REQ Timestamp Processing
-
-   In the TGS exchange, the KDC sets the "authtime" to that of the
-   ticket in the AP-REQ authenticating the TGS-REQ.  [?application
-   server can print a ticket for itself with a spoofed authtime.
-
-Yu                         Expires: Mar 2005                   [Page 49]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   security issues for hot-list?] [ MIT implementation may change
-   authtime of renewed tickets; needs check... ]
-
-   If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ
-   requests an "endtime" (in the "till" field), then the "endtime" of
-   the new ticket is set to the minimum of
-
-      * the requested "endtime" value,
-
-      * the "endtime" in the TGT, and
-
-      * an "endtime" determined by site policy on ticket lifetimes.
-
-   If the new ticket is a renewal, the "endtime" of the new ticket is
-   bounded by the minimum of
-
-      * the requested "endtime" value,
-
-      * the value of the "renew-till" value of the old,
-
-      * the "starttime" of the new ticket plus the lifetime (endtime
-        minus starttime) of the old ticket, i.e., the lifetime of the
-        new ticket may not exceed that of the ticket being renewed [
-        adapted from KCLAR 3.3.3. ], and
-
-      * an "endtime" determined by site policy on ticket lifetimes.
-
-   When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
-   a "starttime", "endtime", or "renew-till" time later than the
-   "renew-till" time of the TGT.
-
-8.3.4.  Handling Transited Realms
-
-   The KDC checks the ticket in a TGS-REQ against site policy, unless
-   the "disable-transited-check" option is set in the TGS-REQ.  If site
-   policy permits the transit path in the TGS-REQ ticket, the KDC sets
-   the "transited-policy-checked" flag in the issued ticket.  If the
-   "disable-transited-check" option is set, the issued ticket will have
-   the "transited-policy-checked" flag cleared.
-
-8.3.5.  Address Processing The requested "addresses" in the KDC-REQ are
-   copied into the issued ticket.  If the "addresses" field is absent or
-   empty in a TGS-REQ, the KDC copies addresses from the ticket in the
-   TGS-REQ into the issued ticket, unless the either "forwarded" or
-   "proxy" option is set.  If the "forwarded" option is set, and the
-   ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies
-   the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the
-   issued ticket.  The KDC behaves similarly if the "proxy" option is
-   set in the TGS-REQ and the "proxiable" flag is set in the ticket.
-   The "proxy" option will not be honored on requests for additional
-   ticket-granting tickets.
-
-Yu                         Expires: Mar 2005                   [Page 50]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-8.3.6.  Ticket Flag Processing
-
-   Many kdc-options request that the KDC set a corresponding flag in the
-   issued ticket.  kdc-options marked with an asterisk (*) in the
-   following table do not directly request the corresponding ticket flag
-   and therefore require special handling.
-
-
-             kdc-option       |    ticket flag affected
-      ________________________|__________________________
-      forwardable             |  forwardable
-      forwarded               |  forwarded
-      proxiable               |  proxiable
-      proxy                   |  proxy
-      allow-postdate          |  may-postdate
-      postdated               |  postdated
-      renewable               |  renewable
-      requestanonymous        |  anonymous
-      canonicalize            |  -
-      disable-transited-check*|  transited-policy-checked
-      renewable-ok*           |  renewable
-      enc-tkt-in-skey         |  -
-      renew                   |  -
-      validate*               |  invalid
-
-
-
-   forwarded
-        The KDC sets the "forwarded" flag in the issued ticket if the
-        "forwarded" option is set in the TGS-REQ and the "forwardable"
-        flag is set in the TGS-REQ ticket.
-
-   proxy
-        The KDC sets the "proxy" flag in the issued ticket if the
-        "proxy" option is set in the TGS-REQ and the "proxiable" flag is
-        set in the TGS-REQ ticket.
-
-   disable-transited-check
-        The handling of the "disable-transited-check" kdc-option is
-        described in Section 8.3.4.
-
-   renewable-ok
-        The handling of the "renewable-ok" kdc-option is described in
-        Section 8.3.3.1.
-
-   enc-tkt-in-skey
-        This flag modifies ticket key selection to use the session key
-        of an additional ticket included in the TGS-REQ, for the purpose
-        of user-to-user authentication.
-
-
-
-Yu                         Expires: Mar 2005                   [Page 51]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   validate
-        If the "validate" kdc-option is set in a TGS-REQ, and the
-        "starttime" has passed, the KDC will clear the "invalid" bit on
-        the ticket before re-issuing it.
-
-8.3.7.  Key Selection
-
-   Three keys are involved in creating a KDC-REP.  The reply key
-   encrypts the encrypted part of the KDC-REP.  The session key is
-   stored in the encrypted part of the ticket, and is also present in
-   the encrypted part of the KDC-REP so that the client can retrieve it.
-   The ticket key is used to encrypt the ticket.  These keys all have
-   initial values for a given exchange; pre-authentication and other
-   extension mechanisms may change the value used for any of these keys.
-
-   [ again, may need changes based on Sam's preauth draft ]
-
-8.3.7.1.  Reply Key and Session Key Selection
-
-   The set of encryption types which the client will understand appears
-   in the "etype" field of KDC-REQ-BODY-COMMON.  The KDC limits the set
-   of possible reply keys and the set of session key encryption types
-   based on the "etype" field.
-
-   For the AS exchange, the reply key is initially a long-term key of
-   the client, limited to those encryption types listed in the "etype"
-   field.  The KDC SHOULD use the first valid strong "etype" for which
-   an encryption key is available.  For the TGS exchange, the reply key
-   is initially the subsession key of the Authenticator.  If the
-   Authenticator subsesion key is absent, the reply key is initially the
-   session key of the ticket used to authenticate the TGS-REQ.
-
-   The session key is initially randomly generated, and has an
-   encryption type which both the client and the server will understand.
-   Typically, the KDC has prior knowledge of which encryption types the
-   server will understand.  It selects the first valid strong "etype"
-   listed the request which the server also will understand.
-
-8.3.7.2.  Ticket Key Selection
-
-   The ticket key is initially the long-term key of the service.  The
-   "enc-tkt-in-skey" option requests user-to-user authentication, where
-   the ticket encryption key of the issued ticket is set equal to the
-   session key of the additional ticket in the request.
-
-8.4.  KDC-REP
-
-   The important parts of the KDC-REP are encrypted.
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 52]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
-      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
-
-      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
-      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
-
-      EncKDCRepPartCom        ::= SEQUENCE {
-          key                 [0] EncryptionKey,
-          last-req            [1] LastReq,
-          nonce               [2] Nonce,
-          key-expiration      [3] KerberosTime OPTIONAL,
-          flags               [4] TicketFlags,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          srealm              [9] Realm,
-          sname               [10] PrincipalName,
-          caddr               [11] HostAddresses OPTIONAL,
-          ...
-      }
-
-      EncKDCRepPart1510       ::= SEQUENCE {
-          COMPONENTS OF EncKDCRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          srealm (RealmIA5),
-          sname (PrincipalNameIA5),
-          nonce UInt32 })
-
-      EncKdcRepPartExt        ::= EncKDCRepPartCom (WITH COMPONENTS {
-          ...,
-          srealm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-   Most of the fields of EncKDCRepPartCom are duplicates of the
-   corresponding fields in the returned ticket.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 53]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
-                                   13 -- TGS.rfc1510 -- |
-                                   7 -- AS-REP.ext -- |
-                                   9 -- TGS-REP.ext -- ),
-          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
-          crealm      [3] Realm,
-          cname       [4] PrincipalName,
-          ticket      [5] Ticket,
-
-          enc-part    [6] EncryptedData {
-              EncPart,
-              { key-reply },
-              -- maybe reach into EncryptedData in AS-REP/TGS-REP
-              -- definitions to apply constraints on key usages?
-              { ku-EncASRepPart -- if AS-REP -- |
-                ku-EncTGSRepPart-subkey -- if TGS-REP and
-                                        -- using Authenticator
-                                        -- session key -- |
-                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
-                                         -- subsession key -- }
-          },
-
-          ...,
-          -- In extensible version, KDC signs original request
-          -- to avoid replay attacks against client.
-          req-cksum   [7] ChecksumOf { CHOICE {
-              as-req          AS-REQ,
-              tgs-req         TGS-REQ
-          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
-          lang-tag    [8] LangTag OPTIONAL,
-          ...
-      }
-
-
-      KDC-REP-1510 { EncPart } ::= SEQUENCE {
-          COMPONENTS OF KDC-REP-COMMON { EncPart }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (11 | 13),
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 54]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
-      (WITH COMPONENTS {
-          ...,
-          msg-type (7 | 9),
-          crealm (RealmExt),
-          cname (PrincipalNameExt)
-      })
-
-
-   req-cksum
-        Signature of the original request using the reply key, to avoid
-        replay attacks against the client, among other things.  Only
-        present in the extensible version of KDC-REP.
-
-           AS-REP          ::= CHOICE {
-               rfc1510     [APPLICATION 11] KDC-REP-1510 {
-                   EncASRepPart1510
-               } (WITH COMPONENTS { ..., msg-type (11) }),
-               ext         [APPLICATION  7]  Signed {
-                   [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
-                   { key-reply }, { ku-ASRep-cksum }
-               } (WITH COMPONENTS { ..., msg-type (7) })
-           }
-
-
-           TGS-REP         ::= CHOICE {
-               rfc1510     [APPLICATION 13] KDC-REP-1510 {
-                   EncTGSRepPart1510
-               } (WITH COMPONENTS { ..., msg-type (13) }),
-               ext         [APPLICATION  9]  Signed {
-                   [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
-                   { key-reply }, { ku-TGSRep-cksum }
-               } (WITH COMPONENTS { ..., msg-type (9) })
-           }
-
-
-   The extensible versions of AS-REQ and TGS-REQ are signed with the
-   reply key, to prevent an attacker from performing a delayed denial-
-   of-service attack by substituting the ticket.
-
-8.5.  Reply Validation
-
-   [ signature verification ]
-
-8.6.  IP Transports
-
-   [ KCLAR 7.2 ]
-
-   Kerberos defines two IP transport mechanisms for the credentials
-   acquisition protocol: UDP/IP and TCP/IP.
-
-
-Yu                         Expires: Mar 2005                   [Page 55]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-8.6.1.  UDP/IP transport
-
-   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
-   requests and SHOULD listen for such requests on port 88 (decimal)
-   unless specifically configured to listen on an alternative UDP port.
-   Alternate ports MAY be used when running multiple KDCs for multiple
-   realms on the same host.
-
-   Kerberos clients supporting IP transports SHOULD support the sending
-   of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to
-   identify the IP address and port to which they will send their
-   request.
-
-   When contacting a KDC for a KRB_KDC_REQ request using UDP/IP
-   transport, the client shall send a UDP datagram containing only an
-   encoding of the request to the KDC. The KDC will respond with a reply
-   datagram containing only an encoding of the reply message (either a
-   KRB-ERROR or a KDC-REP) to the sending port at the sender's IP
-   address. The response to a request made through UDP/IP transport MUST
-   also use UDP/IP transport. If the response can not be handled using
-   UDP (for example because it is too large), the KDC MUST return "krb-
-   err-response-too-big", forcing the client to retry the request using
-   the TCP transport.
-
-8.6.2.  TCP/IP transport
-
-   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
-   requests and SHOULD listen for such requests on port 88 (decimal)
-   unless specifically configured to listen on an alternate TCP port.
-   Alternate ports MAY be used when running multiple KDCs for multiple
-   realms on the same host.
-
-   Clients MUST support the sending of TCP requests, but MAY choose to
-   initially try a request using the UDP transport. Clients SHOULD use
-   KDC discovery (Section 8.6.3) to identify the IP address and port to
-   which they will send their request.
-
-   Implementation note: Some extensions to the Kerberos protocol will
-   not succeed if any client or KDC not supporting the TCP transport is
-   involved.  Implementations of RFC 1510 were not required to support
-   TCP/IP transports.
-
-   When the KDC-REQ message is sent to the KDC over a TCP stream, the
-   response (KDC-REP or KRB-ERROR message) MUST be returned to the
-   client on the same TCP stream that was established for the request.
-   The KDC MAY close the TCP stream after sending a response, but MAY
-   leave the stream open for a reasonable period of time if it expects a
-   followup. Care must be taken in managing TCP/IP connections on the
-   KDC to prevent denial of service attacks based on the number of open
-   TCP/IP connections.
-
-
-Yu                         Expires: Mar 2005                   [Page 56]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   The client MUST be prepared to have the stream closed by the KDC at
-   anytime after the receipt of a response.  A stream closure SHOULD NOT
-   be treated as a fatal error.  Instead, if multiple exchanges are
-   required (e.g., certain forms of pre-authentication) the client may
-   need to establish a new connection when it is ready to send
-   subsequent messages.  A client MAY close the stream after receiving a
-   response, and SHOULD close the stream if it does not expect to send
-   followup messages.
-
-   A client MAY send multiple requests before receiving responses,
-   though it must be prepared to handle the connection being closed
-   after the first response.
-
-   Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over
-   the TCP stream is preceded by the length of the request as 4 octets
-   in network byte order. The high bit of the length is reserved for
-   future expansion and MUST currently be set to zero.  If a KDC that
-   does not understand how to interpret a set high bit of the length
-   encoding receives a request with the high order bit of the length
-   set, it MUST return a KRB-ERROR message with the error "krb-err-
-   field-toolong" and MUST close the TCP stream.
-
-   If multiple requests are sent over a single TCP connection, and the
-   KDC sends multiple responses, the KDC is not required to send the
-   responses in the order of the corresponding requests.  This may
-   permit some implementations to send each response as soon as it is
-   ready even if earlier requests are still being processed (for
-   example, waiting for a response from an external device or database).
-
-8.6.3.  KDC Discovery on IP Networks
-
-   Kerberos client implementations MUST provide a means for the client
-   to determine the location of the Kerberos Key Distribution Centers
-   (KDCs).  Traditionally, Kerberos implementations have stored such
-   configuration information in a file on each client machine.
-   Experience has shown this method of storing configuration information
-   presents problems with out-of-date information and scaling problems,
-   especially when using cross-realm authentication. This section
-   describes a method for using the Domain Name System [RFC 1035] for
-   storing KDC location information.
-
-8.6.3.1.  DNS vs. Kerberos - Case Sensitivity of Realm Names
-
-   In Kerberos, realm names are case sensitive.  While it is strongly
-   encouraged that all realm names be all upper case this recommendation
-   has not been adopted by all sites.  Some sites use all lower case
-   names and other use mixed case.  DNS, on the other hand, is case
-   insensitive for queries.  Since the realm names "MYREALM", "myrealm",
-   and "MyRealm" are all different, but resolve the same in the domain
-   name system, it is necessary that only one of the possible
-   combinations of upper and lower case characters be used in realm
-
-Yu                         Expires: Mar 2005                   [Page 57]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   names.
-
-8.6.3.2.  DNS SRV records for KDC location
-
-   KDC location information is to be stored using the DNS SRV RR [RFC
-   2782].  The format of this RR is as follows:
-
-      _Service._Proto.Realm TTL Class SRV Priority Weight Port Target
-
-   The Service name for Kerberos is always "kerberos".
-
-   The Proto can be one of "udp", "tcp". If these SRV records are to be
-   used, both "udp" and "tcp" records MUST be specified for all KDC
-   deployments.
-
-   The Realm is the Kerberos realm that this record corresponds to.  The
-   realm MUST be a domain style realm name.
-
-   TTL, Class, SRV, Priority, Weight, and Target have the standard
-   meaning as defined in RFC 2782.
-
-   As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
-   records SHOULD be the value assigned to "kerberos" by the Internet
-   Assigned Number Authority: 88 (decimal) unless the KDC is configured
-   to listen on an alternate TCP port.
-
-   Implementation note: Many existing client implementations do not
-   support KDC Discovery and are configured to send requests to the IANA
-   assigned port (88 decimal), so it is strongly recommended that KDCs
-   be configured to listen on that port.
-
-8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP Networks
-
-   These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
-   Kerberos servers, kdc1.example.com and kdc2.example.com.  Queries
-   should be directed to kdc1.example.com first as per the specified
-   priority.  Weights are not used in these sample records.
-
-      _kerberos._udp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
-      _kerberos._udp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
-      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
-      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
-
-
-9.  Errors
-
-   The KRB-ERROR message is returned by the KDC if an error occurs
-   during credentials acquisition.  It may also be returned by an
-   application server if an error occurs during authentication.
-
-
-
-Yu                         Expires: Mar 2005                   [Page 58]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      ErrCode ::= Int32
-
-      KRB-ERROR       ::= CHOICE {
-          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
-          ext         [APPLICATION 23] Signed {
-              KRB-ERROR-EXT, { ku-KrbError-cksum } }
-      }
-
-
-   The extensible KRB-ERROR is only signed if there has been a key
-   negotiated with its recipient.  KRB-ERROR messages sent in response
-   to AS-REQ messages will probably not be signed unless a
-   preauthentication mechanism has negotiated a key.  (Signing using a
-   client's long-term key can expose ciphertext to dictionary attacks.)
-
-   The parts of a KRB-ERROR common to both the backwards-compatibility
-   and the extensibile messages are
-
-      KRB-ERROR-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (30 | 23),
-          ctime       [2] KerberosTime OPTIONAL,
-          cusec       [3] Microseconds OPTIONAL,
-          stime       [4] KerberosTime,
-          susec       [5] Microseconds,
-          error-code  [6] ErrCode,
-          crealm      [7] Realm OPTIONAL,
-          cname       [8] PrincipalName OPTIONAL,
-          realm       [9] Realm -- Correct realm --,
-          sname       [10] PrincipalName -- Correct name --,
-          e-text      [11] KerberosString OPTIONAL,
-          e-data      [12] OCTET STRING OPTIONAL,
-          ...,
-          typed-data          [13] TYPED-DATA OPTIONAL,
-          nonce               [14] Nonce OPTIONAL,
-          lang-tag            [15] LangTag OPTIONAL,
-          ...
-      }
-
-
-      KRB-ERROR-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-ERROR-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (30)
-      })
-
-
-      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
-          (WITH COMPONENTS { ..., msg-type (23) })
-
-
-Yu                         Expires: Mar 2005                   [Page 59]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   ctime, cusec
-        Client's time, if known from a KDC-REQ or AP-REQ.
-
-   stime, susec
-        KDC or application server's current time.
-
-   error-code
-        Numeric error code designating the error.
-
-   crealm, cname
-        Client's realm and name, if known.
-
-   realm, sname
-        server's realm and name. [ XXX what if these aren't known? ]
-
-   e-text
-        Human-readable text providing additional details for the error.
-
-   e-data
-        This field contains additional data about the error for use by
-        the client to help it recover from or handle the error. If the
-        "error-code" is "kdc-err-preauth-required", then the e-data
-        field will contain an encoding of a sequence of padata fields,
-        each corresponding to an acceptable pre-authentication method
-        and optionally containing data for the method:
-
-           METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-
-        For error codes defined in this document other than "kdc-err-
-        preauth-required", the format and contents of the e-data field
-        are implementation-defined.  Similarly, for future error codes,
-        the format and contents of the e-data field are implementation-
-        defined unless specified.
-
-   lang-tag
-        Indicates the language of the message in the "e-text" field.  It
-        is only present in the extensible KRB-ERROR.
-
-   nonce
-        is the nonce from a KDC-REQ.  It is only present in the
-        extensible KRB-ERROR.
-
-   typed-data
-        TYPED-DATA is a typed hole allowing for additional data to be
-        returned in error conditions, since "e-data" is insufficiently
-        flexible for some purposes.  TYPED-DATA is only present in the
-        extensible KRB-ERROR.
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 60]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-           TDType ::= TH-id
-
-           TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-               data-type   [0] TDType,
-               data-value  [1] OCTET STRING OPTIONAL
-           }
-
-
-10.  Session Key Exchange
-
-   Session key exchange consists of the AP-REQ and AP-REP messages.  The
-   client sends the AP-REQ message, and the service responds with an
-   AP-REP message if mutual authentication is desired.  Following
-   session key exchange, the client and service share a secret session
-   key, or possibly a subsesion key, which can be used to protect
-   further communications.  Additionally, the session key exchange
-   process can establish initial sequence numbers which the client and
-   service can use to detect replayed messages.
-
-10.1.  AP-REQ
-
-   An AP-REQ message contains a ticket and a authenticator.  The
-   authenticator is ciphertext encrypted with the session key contained
-   in the ticket.  The plaintext contents of the authenticator are:
-
-      -- plaintext of authenticator
-      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-          authenticator-vno   [0] INTEGER (5),
-          crealm              [1] Realm,
-          cname               [2] PrincipalName,
-          cksum               [3] Checksum {{ key-session },
-              { ku-Authenticator-cksum |
-                ku-pa-TGSReq-cksum }} OPTIONAL,
-          cusec               [4] Microseconds,
-          ctime               [5] KerberosTime,
-          subkey              [6] EncryptionKey OPTIONAL,
-          seq-number          [7] SeqNum OPTIONAL,
-          authorization-data  [8] AuthorizationData OPTIONAL
-      }
-
-   The common parts between the RFC 1510 and the extensible versions of
-   the AP-REQ are:
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 61]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      AP-REQ-COMMON   ::= SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14 | 18),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket,
-          authenticator       [4] EncryptedData {
-              Authenticator,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          },
-          ...,
-          extensions          [5] ApReqExtensions OPTIONAL,
-          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
-                                      OF LangTag OPTIONAL,
-          ...
-      }
-
-   The complete definition of AP-REQ is:
-
-      AP-REQ          ::= CHOICE {
-          rfc1510     [APPLICATION 14] AP-REQ-1510,
-          ext         [APPLICATION 18] Signed {
-              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
-          }
-      }
-
-
-      AP-REQ-COMMON   ::= SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14 | 18),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket,
-          authenticator       [4] EncryptedData {
-              Authenticator,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          },
-          ...,
-          extensions          [5] ApReqExtensions OPTIONAL,
-          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
-                                      OF LangTag OPTIONAL,
-          ...
-      }
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 62]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      AP-REQ-1510 ::= SEQUENCE {
-          COMPONENTS OF AP-REQ-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (14),
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmIA5),
-                  cname (PrincipalNameIA5),
-                  seqnum (UInt32)
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-      AP-REQ-EXT      ::= AP-REQ-COMMON
-      (WITH COMPONENTS {
-          ...,
-          msg-type (18),
-          -- The following constraints on Authenticator assume that
-          -- we want to restrict the use of AP-REQ-EXT with TicketExt
-          -- only, since that is the only way we can enforce UTF-8.
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmExt),
-                  cname (PrincipalNameExt),
-                  authorization-data (SIZE (1..MAX))
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-      APOptions       ::= KerberosFlags { APOptionsBits }
-
-      APOptionsBits ::= BIT STRING {
-          reserved            (0),
-          use-session-key     (1),
-          mutual-required     (2)
-      }
-
-
-10.2.  AP-REP
-
-   An AP-REP message provides mutual authentication of the service to
-   the client.
-
-      EncAPRepPart    ::= CHOICE {
-          rfc1510     [APPLICATION 27] EncAPRepPart1510,
-          ext         [APPLICATION 31] EncAPRepPartExt
-      }
-
-
-Yu                         Expires: Mar 2005                   [Page 63]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      EncAPRepPartCom          ::= SEQUENCE {
-          ctime               [0] KerberosTime,
-          cusec               [1] Microseconds,
-          subkey              [2] EncryptionKey OPTIONAL,
-          seq-number          [3] SeqNum OPTIONAL,
-          ...,
-          authorization-data  [4] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-      EncAPRepPart1510        ::= SEQUENCE {
-          COMPONENTS OF ENCAPRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          seq-number (UInt32),
-          authorization-data ABSENT
-      })
-
-
-      EncAPRepPartExt         ::= EncAPRepPartCom
-
-
-      AP-REP          ::= CHOICE {
-          rfc1510     [APPLICATION 15] AP-REP-1510,
-          ext         [APPLICATION 19] Signed {
-              AP-REP-EXT,
-              { key-session | key-subsession }, { ku-APRep-cksum }}
-      }
-
-
-      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (15 | 19),
-          enc-part    [2] EncryptedData {
-              EncPart,
-              { key-session | key-subsession }, { ku-EncAPRepPart }},
-          ...,
-          extensions          [3] ApRepExtensions OPTIONAL,
-          ...
-      }
-
-
-      AP-REP-1510     ::= SEQUENCE {
-          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (15)
-      })
-
-
-
-Yu                         Expires: Mar 2005                   [Page 64]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
-          EncAPRepPartExt
-      } (WITH COMPONENTS { ..., msg-type (19) })
-
-
-11.  Session Key Use
-
-   Once a session key has been established, the client and server can
-   use several kinds of messages to securely transmit data.  KRB-SAFE
-   provides integrity protection for application data, while KRB-PRIV
-   provides confidentiality along with integrity protection.  The KRB-
-   CRED message provides a means of securely forwarding credentials from
-   the client host to the server host.
-
-11.1.  KRB-SAFE
-
-   The KRB-SAFE message provides integrity protection for an included
-   cleartext message.
-
-      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
-      -- allow us to  make safe-body optional, allowing for a GSS-MIC
-      -- sort of message.
-      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (20),
-          safe-body   [2] KRB-SAFE-BODY,
-          cksum       [3] ChecksumOf {
-              KRB-SAFE-BODY,
-              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-      KRB-SAFE-BODY   ::= SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress,
-          r-address   [5] HostAddress OPTIONAL,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-11.2.  KRB-PRIV
-
-   The KRB-PRIV message provides confidentiality and integrity
-   protection.
-
-
-Yu                         Expires: Mar 2005                   [Page 65]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (21),
-          enc-part    [3] EncryptedData {
-              EncKrbPrivPart,
-              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
-          ...
-      }
-
-
-      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress -- sender's addr --,
-          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-11.3.  KRB-CRED
-
-   The KRB-CRED message provides a means of securely transferring
-   credentials from the client to the service.
-
-      KRB-CRED        ::= CHOICE {
-          rfc1510     [APPLICATION 22] KRB-CRED-1510,
-          ext         [APPLICATION 24] Signed {
-              KRB-CRED-EXT,
-              { key-session | key-subsession }, { ku-KrbCred-cksum }}
-      }
-
-
-      KRB-CRED-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (22 | 24),
-          tickets     [2] SEQUENCE OF Ticket,
-          enc-part    [3] EncryptedData {
-              EncKrbCredPart,
-              { key-session | key-subsession }, { ku-EncKrbCredPart }},
-          ...
-      }
-
-
-      KRB-CRED-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-CRED-COMMON
-      } (WITH COMPONENTS { ..., msg-type (22) })
-
-
-
-Yu                         Expires: Mar 2005                   [Page 66]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
-          (WITH COMPONENTS { ..., msg-type (24) })
-
-
-      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-          ticket-info [0] SEQUENCE OF KrbCredInfo,
-          nonce       [1] Nonce OPTIONAL,
-          timestamp   [2] KerberosTime OPTIONAL,
-          usec        [3] Microseconds OPTIONAL,
-          s-address   [4] HostAddress OPTIONAL,
-          r-address   [5] HostAddress OPTIONAL
-      }
-
-
-      KrbCredInfo     ::= SEQUENCE {
-          key         [0] EncryptionKey,
-          prealm      [1] Realm OPTIONAL,
-          pname       [2] PrincipalName OPTIONAL,
-          flags       [3] TicketFlags OPTIONAL,
-          authtime    [4] KerberosTime OPTIONAL,
-          starttime   [5] KerberosTime OPTIONAL,
-          endtime     [6] KerberosTime OPTIONAL,
-          renew-till  [7] KerberosTime OPTIONAL,
-          srealm      [8] Realm OPTIONAL,
-          sname       [9] PrincipalName OPTIONAL,
-          caddr       [10] HostAddresses OPTIONAL
-      }
-
-
-12.  Security Considerations
-
-12.1.  Time Synchronization
-
-   Time synchronization between the KDC and application servers is
-   necessary to prevent acceptance of expired tickets.
-
-   Time synchronization is needed between application servers and
-   clients to prevent replay attacks if a replay cache is being used.
-   If negotiated subsession keys are used to encrypt application data,
-   replay caches may not be necessary.
-
-12.2.  Replays
-
-12.3.  Principal Name Reuse
-
-   See Section 5.3.
-
-12.4.  Password Guessing
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 67]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-12.5.  Forward Secrecy
-
-   [from KCLAR 10.; needs some rewriting]
-
-   The Kerberos protocol in its basic form does not provide perfect
-   forward secrecy for communications.  If traffic has been recorded by
-   an eavesdropper, then messages encrypted using the KRB-PRIV message,
-   or messages encrypted using application-specific encryption under
-   keys exchanged using Kerberos can be decrypted if any of the user's,
-   application server's, or KDC's key is subsequently discovered.  This
-   is because the session key used to encrypt such messages is
-   transmitted over the network encrypted in the key of the application
-   server, and also encrypted under the session key from the user's
-   ticket-granting ticket when returned to the user in the TGS-REP
-   message.  The session key from the ticket-granting ticket was sent to
-   the user in the AS-REP message encrypted in the user's secret key,
-   and embedded in the ticket-granting ticket, which was encrypted in
-   the key of the KDC.  Application requiring perfect forward secrecy
-   must exchange keys through mechanisms that provide such assurance,
-   but may use Kerberos for authentication of the encrypted channel
-   established through such other means.
-
-12.6.  Authorization
-
-   As an authentication service, Kerberos provides a means of verifying
-   the identity of principals on a network.  Kerberos does not, by
-   itself, provide authorization.  Applications SHOULD NOT accept the
-   mere issuance of a service ticket by the Kerberos server as granting
-   authority to use the service.
-
-12.7.  Login Authentication
-
-   Some applications, particularly those which provide login access when
-   provided with a password, SHOULD NOT treat successful acquisition of
-   credentials as sufficient proof of the user's identity.  An attacker
-   posing as a user could generate an illegitimate KDC-REP message which
-   decrypts properly.  To authenticate a user logging on to a local
-   system, the credentials obtained SHOULD be used in a TGS exchange to
-   obtain credentials for a local service.  Successful use of those
-   credentials to authenticate to the local service assures that the
-   initially obtained credentials are from a valid KDC.
-
-13.  IANA Considerations
-
-   [ needs more work ]
-
-   Each use of Int32 in this document defines a number space.  [ XXX
-   enumerate these ] Negative numbers are reserved for private use;
-   local and experimental extensions should use these values.  Zero is
-   reserved and may not be assigned.
-
-
-Yu                         Expires: Mar 2005                   [Page 68]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   Typed hole contents may be identified by either Int32 values or by
-   RELATIVE-OID values.  Since RELATIVE-OIDs define a hierarchical
-   namespace, assignments to the top level of the RELATIVE-OID space may
-   be made on a first-come, first-served basis.
-
-14.  Acknowledgments
-
-   Much of the text here is adapted from draft-ietf-krb-wg-kerberos-
-   clarifications-07.  The description of the general form of the
-   extensibility framework was derived from text by Sam Hartman.
-
-Appendices
-
-A.  ASN.1 Module (Normative)
-
-      KerberosV5Spec3 {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2) modules(4) krb5spec3(4)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-
-      -- OID arc for KerberosV5
-      --
-      -- This OID may be used to identify Kerberos protocol messages
-      -- encapsulated in other protocols.
-      --
-      -- This OID also designates the OID arc for KerberosV5-related
-      -- OIDs.
-      --
-      -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
-      -- OID.
-      id-krb5         OBJECT IDENTIFIER ::= {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2)
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 69]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- top-level type
-      --
-      -- Applications should not directly reference any types
-      -- other than KRB-PDU and its component types.
-      --
-      KRB-PDU         ::= CHOICE {
-          ticket      Ticket,
-          as-req      AS-REQ,
-          as-rep      AS-REP,
-          tgs-req     TGS-REQ,
-          tgs-rep     TGS-REP,
-          ap-req      AP-REQ,
-          ap-rep      AP-REP,
-          krb-safe    KRB-SAFE,
-          krb-priv    KRB-PRIV,
-          krb-cred    KRB-CRED,
-          tgt-req     TGT-REQ,
-          krb-error   KRB-ERROR,
-          ...
-      }
-
-
-      --
-      -- *** basic types
-      --
-
-
-      -- signed values representable in 32 bits
-      --
-      -- These are often used as assigned numbers for various things.
-      Int32           ::= INTEGER (-2147483648..2147483647)
-
-
-      -- Typed hole identifiers
-      TH-id           ::= CHOICE {
-          int32               Int32,
-          rel-oid             RELATIVE-OID
-      }
-
-
-      -- unsigned 32 bit values
-      UInt32          ::= INTEGER (0..4294967295)
-
-
-      -- unsigned 64 bit values
-      UInt64          ::= INTEGER (0..18446744073709551615)
-
-
-      -- sequence numbers
-      SeqNum          ::= UInt64
-
-
-Yu                         Expires: Mar 2005                   [Page 70]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- nonces
-      Nonce           ::= UInt64
-
-
-      -- microseconds
-      Microseconds    ::= INTEGER (0..999999)
-
-
-      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
-                              -- MUST NOT include fractional seconds
-      })
-
-
-      -- used for names and for error messages
-      KerberosString  ::= CHOICE {
-          ia5         GeneralString (IA5String),
-          utf8        UTF8String,
-          ...         -- no extension may be sent
-                      -- to an rfc1510 implementation --
-      }
-
-
-      -- IA5 choice only; useful for constraints
-      KerberosStringIA5       ::= KerberosString
-          (WITH COMPONENTS { ia5 PRESENT })
-
-      -- IA5 excluded; useful for constraints
-      KerberosStringExt       ::= KerberosString
-          (WITH COMPONENTS { ia5 ABSENT })
-
-
-      -- used for language tags
-      LangTag ::= PrintableString
-          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 71]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- assigned numbers for name types (used in principal names)
-      NameType        ::= Int32
-
-      -- Name type not known
-      nt-unknown              NameType ::= 0
-      -- Just the name of the principal as in DCE, or for users
-      nt-principal            NameType ::= 1
-      -- Service and other unique instance (krbtgt)
-      nt-srv-inst             NameType ::= 2
-      -- Service with host name as instance (telnet, rcommands)
-      nt-srv-hst              NameType ::= 3
-      -- Service with host as remaining components
-      nt-srv-xhst             NameType ::= 4
-      -- Unique ID
-      nt-uid                  NameType ::= 5
-      -- Encoded X.509 Distingished name [RFC 2253]
-      nt-x500-principal       NameType ::= 6
-      -- Name in form of SMTP email name (e.g. user@foo.com)
-      nt-smtp-name            NameType ::= 7
-      -- Enterprise name - may be mapped to principal name
-      nt-enterprise           NameType ::= 10
-
-
-      PrincipalName   ::= SEQUENCE {
-          name-type   [0] NameType,
-          -- May have zero elements, or individual elements may be
-          -- zero-length, but this is NOT RECOMMENDED.
-          name-string [1] SEQUENCE OF KerberosString
-      }
-
-
-      -- IA5 only
-      PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS {
-          ...,
-          name-string (WITH COMPONENT (KerberosStringIA5))
-      })
-
-      -- IA5 excluded
-      PrincipalNameExt ::= PrincpalName (WITH COMPONENTS {
-          ...,
-          name-string (WITH COMPONENT (KerberosStringExt))
-      })
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 72]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      Realm           ::= KerberosString
-
-      -- IA5 only
-      RealmIA5        ::= Realm (KerberosStringIA5)
-
-      -- IA5 excluded
-      RealmExt        ::= Realm (KerberosStringExt)
-
-
-      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
-          (CONSTRAINED BY {
-          -- MUST be a valid value of -- NamedBits
-          -- but if the value to be sent would be truncated to shorter
-          -- than 32 bits according to DER, the value MUST be padded
-          -- with trailing zero bits to 32 bits.  Otherwise, no
-          -- trailing zero bits may be present.
-
-      })
-
-
-      AddrType        ::= Int32
-
-      HostAddress     ::= SEQUENCE  {
-          addr-type   [0] AddrType,
-          address     [1] OCTET STRING
-      }
-
-      -- NOTE: HostAddresses is always used as an OPTIONAL field and
-      -- should not be a zero-length SEQUENCE OF.
-      --
-      -- The extensible messages explicitly constrain this to be
-      -- non-empty.
-      HostAddresses   ::= SEQUENCE OF HostAddress
-
-
-      --
-      -- *** crypto-related types and assignments
-      --
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 73]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- Assigned numbers denoting encryption mechanisms.
-      EType ::= Int32
-
-      -- assigned numbers for encryption schemes
-      et-des-cbc-crc                  EType ::= 1
-      et-des-cbc-md4                  EType ::= 2
-      et-des-cbc-md5                  EType ::= 3
-      --     [reserved]                         4
-      et-des3-cbc-md5                 EType ::= 5
-      --     [reserved]                         6
-      et-des3-cbc-sha1                EType ::= 7
-      et-dsaWithSHA1-CmsOID           EType ::= 9
-      et-md5WithRSAEncryption-CmsOID  EType ::= 10
-      et-sha1WithRSAEncryption-CmsOID EType ::= 11
-      et-rc2CBC-EnvOID                EType ::= 12
-      et-rsaEncryption-EnvOID         EType ::= 13
-      et-rsaES-OAEP-ENV-OID           EType ::= 14
-      et-des-ede3-cbc-Env-OID         EType ::= 15
-      et-des3-cbc-sha1-kd             EType ::= 16
-      -- AES
-      et-aes128-cts-hmac-sha1-96      EType ::= 17
-      -- AES
-      et-aes256-cts-hmac-sha1-96      EType ::= 18
-      -- Microsoft
-      et-rc4-hmac                     EType ::= 23
-      -- Microsoft
-      et-rc4-hmac-exp                 EType ::= 24
-      -- opaque; PacketCable
-      et-subkey-keymaterial           EType ::= 65
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 74]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- Assigned numbers denoting key usages.
-      KeyUsage ::= UInt32
-
-      --
-      -- Actual identifier names are provisional and subject to
-      -- change.
-      --
-      ku-pa-enc-ts                    KeyUsage ::= 1
-      ku-Ticket                       KeyUsage ::= 2
-      ku-EncASRepPart                 KeyUsage ::= 3
-      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
-      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
-      ku-pa-TGSReq-cksum              KeyUsage ::= 6
-      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
-      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
-      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
-      ku-Authenticator-cksum          KeyUsage ::= 10
-      ku-APReq-authenticator          KeyUsage ::= 11
-      ku-EncAPRepPart                 KeyUsage ::= 12
-      ku-EncKrbPrivPart               KeyUsage ::= 13
-      ku-EncKrbCredPart               KeyUsage ::= 14
-      ku-KrbSafe-cksum                KeyUsage ::= 15
-      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
-
-
-      -- The following numbers are provisional...
-      -- conflicts may exist elsewhere.
-      ku-Ticket-cksum                 KeyUsage ::= 25
-      ku-ASReq-cksum                  KeyUsage ::= 26
-      ku-TGSReq-cksum                 KeyUsage ::= 27
-      ku-ASRep-cksum                  KeyUsage ::= 28
-      ku-TGSRep-cksum                 KeyUsage ::= 29
-      ku-APReq-cksum                  KeyUsage ::= 30
-      ku-APRep-cksum                  KeyUsage ::= 31
-      ku-KrbCred-cksum                KeyUsage ::= 32
-      ku-KrbError-cksum               KeyUsage ::= 33
-      ku-KDCRep-cksum                 KeyUsage ::= 34
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 75]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- KeyToUse identifies which key is to be used to encrypt or
-      -- sign a given value.
-      --
-      -- Values of KeyToUse are never actually transmitted over the
-      -- wire, or even used directly by the implementation in any
-      -- way, as key usages are; it exists primarily to identify
-      -- which key gets used for what purpose.  Thus, the specific
-      -- numeric values associated with this type are irrelevant.
-      KeyToUse        ::= ENUMERATED {
-          -- unspecified
-          key-unspecified,
-          -- server long term key
-          key-server,
-          -- client long term key
-          key-client,
-          -- key selected by KDC for encryption of a KDC-REP
-          key-kdc-rep,
-          -- session key from ticket
-          key-session,
-          -- subsession key negotiated via AP-REQ/AP-REP
-          key-subsession,
-          ...
-      }
-
-
-      EncryptionKey   ::= SEQUENCE {
-          keytype     [0] EType,
-          keyvalue    [1] OCTET STRING
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 76]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-
-      -- "Type" specifies which ASN.1 type is encrypted to the
-      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
-      -- keys of which one key may be used to encrypt the data.
-      -- "KeyUsages" specifies a set of key usages, one of which may
-      -- be used to encrypt.
-      --
-      -- None of the parameters is transmitted over the wire.
-      EncryptedData {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          etype       [0] EType,
-          kvno        [1] UInt32 OPTIONAL,
-          cipher      [2] OCTET STRING (CONSTRAINED BY {
-              -- must be encryption of --
-              OCTET STRING (CONTAINING Type),
-              -- with one of the keys -- KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          }),
-          ...
-      }
-
-
-
-      CksumType       ::= Int32
-
-      -- The parameters specify which key to use to produce the
-      -- signature, as well as which key usage to use.  The
-      -- parameters are not actually sent over the wire.
-      Checksum {
-          KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksumtype   [0] CksumType,
-          checksum    [1] OCTET STRING (CONSTRAINED BY {
-              -- signed using one of the keys --
-              KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          })
-      }
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 77]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- a Checksum that must contain the checksum
-      -- of a particular type
-      ChecksumOf {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
-          ...,
-          checksum (CONSTRAINED BY {
-              -- must be checksum of --
-              OCTET STRING (CONTAINING Type)
-          })
-      })
-
-
-      -- parameterized type for wrapping authenticated plaintext
-      Signed {
-          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksum       [0] ChecksumOf {
-              InnerType, Keys, KeyUsages
-          } OPTIONAL,
-          inner       [1] InnerType,
-          ...
-      }
-
-
-      --
-      -- *** Tickets
-      --
-
-
-      Ticket          ::= CHOICE {
-          rfc1510     [APPLICATION 1] Ticket1510,
-          ext         [APPLICATION 4] Signed {
-              TicketExt, { key-server }, { ku-Ticket-cksum }
-          }
-      }
-
-
-      -- takes a parameter specifying which type gets encrypted
-      TicketCommon { EncPart } ::= SEQUENCE {
-          tkt-vno     [0] INTEGER (5),
-          realm       [1] Realm,
-          sname       [2] PrincipalName,
-          enc-part    [3] EncryptedData {
-              EncPart, { key-server }, { ku-Ticket }
-          },
-          ...,
-          extensions          [4] TicketExtensions OPTIONAL,
-          ...
-      }
-
-
-Yu                         Expires: Mar 2005                   [Page 78]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      Ticket1510 ::= SEQUENCE {
-          COMPONENTS OF TicketCommon { EncTicketPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          realm (RealmIA5),
-          sname (PrincipalNameIA5)
-      })
-
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      TicketExt ::= [APPLICATION 4] TicketCommon {
-          EncTicketPartExt
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          realm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-      -- Encrypted part of ticket
-      EncTicketPart ::= CHOICE {
-          rfc1510     [APPLICATION 3] EncTicketPart1510,
-          ext         [APPLICATION 5] EncTicketPartExt
-      }
-
-
-      EncTicketPartCommon ::= SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] Realm,
-          cname               [3] PrincipalName,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 79]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      EncTicketPart1510 ::= SEQUENCE {
-          COMPONENTS OF EncTicketPartCommon
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-
-      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          crealm (RealmExt),
-          cname (PrincipalNameExt),
-          -- explicitly constrain caddr to be non-empty if present
-          caddr (SIZE (1..MAX)),
-          -- forbid empty authorization-data encodings
-          authorization-data (SIZE (1..MAX))
-      })
-
-
-      --
-      -- *** Authorization Data
-      --
-
-
-      ADType          ::= TH-id
-
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-          ad-type             [0] ADType,
-          ad-data             [1] OCTET STRING
-      }
-
-
-      ad-if-relevant          ADType ::= int32 : 1
-
-      -- Encapsulates another AuthorizationData.
-      -- Intended for application servers; receiving application servers
-      -- MAY ignore.
-      AD-IF-RELEVANT          ::= AuthorizationData
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 80]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- KDC-issued privilege attributes
-      ad-kdcissued            ADType ::= int32 : 4
-
-      AD-KDCIssued            ::= SEQUENCE {
-          ad-checksum [0] ChecksumOf {
-                              AuthorizationData, { key-session },
-                              { ku-ad-KDCIssued-cksum }},
-          i-realm     [1] Realm OPTIONAL,
-          i-sname     [2] PrincipalName OPTIONAL,
-          elements    [3] AuthorizationData
-      }
-
-
-      ad-and-or               ADType ::= int32 : 5
-
-      AD-AND-OR               ::= SEQUENCE {
-          condition-count     [0] INTEGER,
-          elements            [1] AuthorizationData
-      }
-
-
-      -- KDCs MUST interpret any AuthorizationData wrapped in this.
-      ad-mandatory-for-kdc            ADType ::= int32 : 8
-      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
-
-
-      TrType                  ::= TH-id -- must be registered
-
-      -- encoded Transited field
-      TransitedEncoding       ::= SEQUENCE {
-          tr-type     [0] TrType,
-          contents    [1] OCTET STRING
-      }
-
-
-      TEType                  ::= TH-id
-
-      -- ticket extensions: for TicketExt only
-      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          te-type             [0] TEType,
-          te-data             [1] OCTET STRING
-      }
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 81]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
-
-      TicketFlagsBits ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          may-postdate        (5),
-          postdated           (6),
-          invalid             (7),
-          renewable           (8),
-          initial             (9),
-          pre-authent         (10),
-          hw-authent          (11),
-          transited-policy-checked (12),
-          ok-as-delegate      (13),
-          anonymous           (14),
-          cksummed-ticket     (15)
-      }
-
-
-      --
-      -- *** KDC protocol
-      --
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 82]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      AS-REQ  ::= CHOICE {
-          rfc1510     [APPLICATION 10] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (10),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          }),
-          ext         [APPLICATION 6]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as
-              -- outside, to prevent possible substitution attacks.
-              [APPLICATION 6] KDC-REQ-EXT,
-              -- not sure this is correct key to use; do we even want
-              -- to sign AS-REQ?
-              { key-client },
-              { ku-ASReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (6),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          })
-      }
-
-
-      TGS-REQ ::= CHOICE {
-          rfc1510     [APPLICATION 12] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (12),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          }),
-          ext         [APPLICATION 8]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as
-              -- outside, to prevent possible substitution attacks.
-              [APPLICATION 8] KDC-REQ-EXT,
-              { key-session }, { ku-TGSReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (8),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          })
-      }
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 83]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KDC-REQ-COMMON  ::= SEQUENCE {
-      -- NOTE: first tag is [1], not [0]
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
-                                   | 12 -- TGS-REQ.rfc1510 --
-                                   | 6 -- AS-REQ.ext --
-                                   | 8 -- TGS-REQ.ext -- ),
-          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
-          -- NOTE: not empty
-      }
-
-
-      KDC-REQ-1510    ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-1510
-      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
-
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      KDC-REQ-EXT     ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-EXT,
-          ...
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (6 | 8),
-          padata (SIZE (1..MAX))
-      })
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 84]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KDC-REQ-BODY-COMMON     ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalName OPTIONAL
-          -- Used only in AS-REQ --,
-
-          realm               [2] Realm
-          -- Server's realm; also client's in AS-REQ --,
-
-          sname               [3] PrincipalName OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime OPTIONAL
-          -- was required in rfc1510;
-          -- still required for compat versions
-          -- of messages --,
-
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --,
-          ...
-          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
-                              LangTag OPTIONAL,
-          ...
-      }
-
-
-      KDC-REQ-BODY-1510 ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-BODY-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          cname (PrincipalNameIA5),
-          realm (RealmIA5),
-          sname (PrincipalNameIA5),
-          till PRESENT,
-          nonce (UInt32)
-      })
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 85]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
-      (WITH COMPONENTS {
-          ...,
-          cname (PrincipalNameExt),
-          realm (RealmExt),
-          sname (PrincipalNameExt),
-          addresses (SIZE (1..MAX)),
-          enc-authorization-data (EncryptedData {
-              AuthorizationData (SIZE (1..MAX)),
-              { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          }),
-          additional-tickets (SIZE (1..MAX))
-      })
-
-
-      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
-
-      KDCOptionsBits  ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          allow-postdate      (5),
-          postdated           (6),
-          unused7             (7),
-          renewable           (8),
-          unused9             (9),
-          unused10            (10),
-          unused11            (11),
-          unused12            (12),
-          unused13            (13),
-          requestanonymous    (14),
-          canonicalize        (15),
-          disable-transited-check (26),
-          renewable-ok        (27),
-          enc-tkt-in-skey     (28),
-          renew               (30),
-          validate            (31)
-          -- XXX need "need ticket1" flag?
-      }
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 86]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      AS-REP          ::= CHOICE {
-          rfc1510     [APPLICATION 11] KDC-REP-1510 {
-              EncASRepPart1510
-          } (WITH COMPONENTS { ..., msg-type (11) }),
-          ext         [APPLICATION  7]  Signed {
-              [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
-              { key-reply }, { ku-ASRep-cksum }
-          } (WITH COMPONENTS { ..., msg-type (7) })
-      }
-
-
-      TGS-REP         ::= CHOICE {
-          rfc1510     [APPLICATION 13] KDC-REP-1510 {
-              EncTGSRepPart1510
-          } (WITH COMPONENTS { ..., msg-type (13) }),
-          ext         [APPLICATION  9]  Signed {
-              [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
-              { key-reply }, { ku-TGSRep-cksum }
-          } (WITH COMPONENTS { ..., msg-type (9) })
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 87]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
-                                   13 -- TGS.rfc1510 -- |
-                                   7 -- AS-REP.ext -- |
-                                   9 -- TGS-REP.ext -- ),
-          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
-          crealm      [3] Realm,
-          cname       [4] PrincipalName,
-          ticket      [5] Ticket,
-
-          enc-part    [6] EncryptedData {
-              EncPart,
-              { key-reply },
-              -- maybe reach into EncryptedData in AS-REP/TGS-REP
-              -- definitions to apply constraints on key usages?
-              { ku-EncASRepPart -- if AS-REP -- |
-                ku-EncTGSRepPart-subkey -- if TGS-REP and
-                                        -- using Authenticator
-                                        -- session key -- |
-                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
-                                         -- subsession key -- }
-          },
-
-          ...,
-          -- In extensible version, KDC signs original request
-          -- to avoid replay attacks against client.
-          req-cksum   [7] ChecksumOf { CHOICE {
-              as-req          AS-REQ,
-              tgs-req         TGS-REQ
-          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
-          lang-tag    [8] LangTag OPTIONAL,
-          ...
-      }
-
-
-      KDC-REP-1510 { EncPart } ::= SEQUENCE {
-          COMPONENTS OF KDC-REP-COMMON { EncPart }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (11 | 13),
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 88]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
-      (WITH COMPONENTS {
-          ...,
-          msg-type (7 | 9),
-          crealm (RealmExt),
-          cname (PrincipalNameExt)
-      })
-
-
-      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
-      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
-
-      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
-      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
-
-      EncKDCRepPartCom        ::= SEQUENCE {
-          key                 [0] EncryptionKey,
-          last-req            [1] LastReq,
-          nonce               [2] Nonce,
-          key-expiration      [3] KerberosTime OPTIONAL,
-          flags               [4] TicketFlags,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          srealm              [9] Realm,
-          sname               [10] PrincipalName,
-          caddr               [11] HostAddresses OPTIONAL,
-          ...
-      }
-
-      EncKDCRepPart1510       ::= SEQUENCE {
-          COMPONENTS OF EncKDCRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          srealm (RealmIA5),
-          sname (PrincipalNameIA5),
-          nonce UInt32 })
-
-      EncKdcRepPartExt        ::= EncKDCRepPartCom (WITH COMPONENTS {
-          ...,
-          srealm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 89]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      LRType          ::=     TH-id
-      LastReq         ::=     SEQUENCE OF SEQUENCE {
-          lr-type     [0] LRType,
-          lr-value    [1] KerberosTime
-      }
-
-
-      --
-      -- *** preauth
-      --
-
-
-      PaDataType      ::= TH-id
-      PaDataOID       ::= RELATIVE-OID
-
-      PA-DATA ::= SEQUENCE {
-          -- NOTE: first tag is [1], not [0]
-          padata-type         [1] PaDataType,
-          padata-value        [2] OCTET STRING
-      }
-
-
-      -- AP-REQ authenticating a TGS-REQ
-      pa-tgs-req              PaDataType ::= int32 : 1
-      PA-TGS-REQ              ::= AP-REQ
-
-
-      -- Encrypted timestamp preauth
-      -- Encryption key used is client's long-term key.
-      pa-enc-timestamp        PaDataType ::= int32 : 2
-
-      PA-ENC-TIMESTAMP ::= EncryptedData {
-          PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
-      }
-
-      PA-ENC-TS-ENC           ::= SEQUENCE {
-              patimestamp     [0] KerberosTime -- client's time --,
-              pausec          [1] Microseconds OPTIONAL
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 90]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- Hints returned in AS-REP or KRB-ERROR to help client
-      -- choose a password-derived key, either for preauthentication
-      -- or for decryption of the reply.
-      pa-etype-info           PaDataType ::= int32 : 11
-
-      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
-
-      ETYPE-INFO-ENTRY        ::= SEQUENCE {
-              etype           [0] EType,
-              salt            [1] OCTET STRING OPTIONAL
-      }
-
-
-      -- Similar to etype-info, but with parameters provided for
-      -- the string-to-key function.
-      pa-etype-info2          PaDataType ::= int32 : 19
-
-      ETYPE-INFO2             ::= SEQUENCE (SIZE (1..MAX))
-                                      OF ETYPE-INFO-ENTRY
-
-      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
-              etype           [0] EType,
-              salt            [1] KerberosString OPTIONAL,
-              s2kparams       [2] OCTET STRING OPTIONAL
-      }
-
-
-      -- Obsolescent.  Salt for client's long-term key.
-      -- Its character encoding is unspecified.
-      pa-pw-salt              PaDataType ::= int32 : 3
-      -- The "padata-value" does not encode an ASN.1 type.
-      -- Instead, "padata-value" must consist of the salt string to
-      -- be used by the client, in an unspecified character
-      -- encoding.
-
-
-      -- An extensible AS-REQ may be sent as a padata in a
-      -- non-extensible AS-REQ to allow for backwards compatibility.
-      pa-as-req               PaDataType ::= int32 : 42 -- provisional
-      PA-AS-REQ               ::= AS-REQ (WITH COMPONENTS ext)
-
-
-      --
-      -- *** Session key exchange
-      --
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 91]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      AP-REQ          ::= CHOICE {
-          rfc1510     [APPLICATION 14] AP-REQ-1510,
-          ext         [APPLICATION 18] Signed {
-              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
-          }
-      }
-
-
-      AP-REQ-COMMON   ::= SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14 | 18),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket,
-          authenticator       [4] EncryptedData {
-              Authenticator,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          },
-          ...,
-          extensions          [5] ApReqExtensions OPTIONAL,
-          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
-                                      OF LangTag OPTIONAL,
-          ...
-      }
-
-
-      AP-REQ-1510 ::= SEQUENCE {
-          COMPONENTS OF AP-REQ-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (14),
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmIA5),
-                  cname (PrincipalNameIA5),
-                  seqnum (UInt32)
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 92]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      AP-REQ-EXT      ::= AP-REQ-COMMON
-      (WITH COMPONENTS {
-          ...,
-          msg-type (18),
-          -- The following constraints on Authenticator assume that
-          -- we want to restrict the use of AP-REQ-EXT with TicketExt
-          -- only, since that is the only way we can enforce UTF-8.
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmExt),
-                  cname (PrincipalNameExt),
-                  authorization-data (SIZE (1..MAX))
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-      ApReqExtType    ::= TH-id
-
-      ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          apReqExt-Type       [0] ApReqExtType,
-          apReqExt-Data       [1] OCTET STRING
-      }
-
-
-      APOptions       ::= KerberosFlags { APOptionsBits }
-
-      APOptionsBits ::= BIT STRING {
-          reserved            (0),
-          use-session-key     (1),
-          mutual-required     (2)
-      }
-
-
-      -- plaintext of authenticator
-      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-          authenticator-vno   [0] INTEGER (5),
-          crealm              [1] Realm,
-          cname               [2] PrincipalName,
-          cksum               [3] Checksum {{ key-session },
-              { ku-Authenticator-cksum |
-                ku-pa-TGSReq-cksum }} OPTIONAL,
-          cusec               [4] Microseconds,
-          ctime               [5] KerberosTime,
-          subkey              [6] EncryptionKey OPTIONAL,
-          seq-number          [7] SeqNum OPTIONAL,
-          authorization-data  [8] AuthorizationData OPTIONAL
-      }
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 93]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      AP-REP          ::= CHOICE {
-          rfc1510     [APPLICATION 15] AP-REP-1510,
-          ext         [APPLICATION 19] Signed {
-              AP-REP-EXT,
-              { key-session | key-subsession }, { ku-APRep-cksum }}
-      }
-
-
-      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (15 | 19),
-          enc-part    [2] EncryptedData {
-              EncPart,
-              { key-session | key-subsession }, { ku-EncAPRepPart }},
-          ...,
-          extensions          [3] ApRepExtensions OPTIONAL,
-          ...
-      }
-
-
-      AP-REP-1510     ::= SEQUENCE {
-          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (15)
-      })
-
-
-      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
-          EncAPRepPartExt
-      } (WITH COMPONENTS { ..., msg-type (19) })
-
-
-      ApRepExtType    ::= TH-id
-
-      ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          apRepExt-Type       [0] ApRepExtType,
-          apRepExt-Data       [1] OCTET STRING
-      }
-
-
-      EncAPRepPart    ::= CHOICE {
-          rfc1510     [APPLICATION 27] EncAPRepPart1510,
-          ext         [APPLICATION 31] EncAPRepPartExt
-      }
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 94]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      EncAPRepPart1510        ::= SEQUENCE {
-          COMPONENTS OF ENCAPRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          seq-number (UInt32),
-          authorization-data ABSENT
-      })
-
-
-      EncAPRepPartExt         ::= EncAPRepPartCom
-
-
-      EncAPRepPartCom          ::= SEQUENCE {
-          ctime               [0] KerberosTime,
-          cusec               [1] Microseconds,
-          subkey              [2] EncryptionKey OPTIONAL,
-          seq-number          [3] SeqNum OPTIONAL,
-          ...,
-          authorization-data  [4] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-      --
-      -- *** Application messages
-      --
-
-
-      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
-      -- allow us to  make safe-body optional, allowing for a GSS-MIC
-      -- sort of message.
-      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (20),
-          safe-body   [2] KRB-SAFE-BODY,
-          cksum       [3] ChecksumOf {
-              KRB-SAFE-BODY,
-              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 95]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KRB-SAFE-BODY   ::= SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress,
-          r-address   [5] HostAddress OPTIONAL,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (21),
-          enc-part    [3] EncryptedData {
-              EncKrbPrivPart,
-              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
-          ...
-      }
-
-
-      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress -- sender's addr --,
-          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-      KRB-CRED        ::= CHOICE {
-          rfc1510     [APPLICATION 22] KRB-CRED-1510,
-          ext         [APPLICATION 24] Signed {
-              KRB-CRED-EXT,
-              { key-session | key-subsession }, { ku-KrbCred-cksum }}
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 96]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KRB-CRED-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (22 | 24),
-          tickets     [2] SEQUENCE OF Ticket,
-          enc-part    [3] EncryptedData {
-              EncKrbCredPart,
-              { key-session | key-subsession }, { ku-EncKrbCredPart }},
-          ...
-      }
-
-
-      KRB-CRED-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-CRED-COMMON
-      } (WITH COMPONENTS { ..., msg-type (22) })
-
-
-      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
-          (WITH COMPONENTS { ..., msg-type (24) })
-
-
-      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-          ticket-info [0] SEQUENCE OF KrbCredInfo,
-          nonce       [1] Nonce OPTIONAL,
-          timestamp   [2] KerberosTime OPTIONAL,
-          usec        [3] Microseconds OPTIONAL,
-          s-address   [4] HostAddress OPTIONAL,
-          r-address   [5] HostAddress OPTIONAL
-      }
-
-
-      KrbCredInfo     ::= SEQUENCE {
-          key         [0] EncryptionKey,
-          prealm      [1] Realm OPTIONAL,
-          pname       [2] PrincipalName OPTIONAL,
-          flags       [3] TicketFlags OPTIONAL,
-          authtime    [4] KerberosTime OPTIONAL,
-          starttime   [5] KerberosTime OPTIONAL,
-          endtime     [6] KerberosTime OPTIONAL,
-          renew-till  [7] KerberosTime OPTIONAL,
-          srealm      [8] Realm OPTIONAL,
-          sname       [9] PrincipalName OPTIONAL,
-          caddr       [10] HostAddresses OPTIONAL
-      }
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 97]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      TGT-REQ         ::= [APPLICATION 16] SEQUENCE {
-          pvno            [0] INTEGER (5),
-          msg-type        [1] INTEGER (16),
-          sname           [2] PrincipalName OPTIONAL,
-          srealm          [3] Realm OPTIONAL,
-          ...
-      }
-
-
-      --
-      -- *** Error messages
-      --
-
-
-      ErrCode ::= Int32
-
-      KRB-ERROR       ::= CHOICE {
-          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
-          ext         [APPLICATION 23] Signed {
-              KRB-ERROR-EXT, { ku-KrbError-cksum } }
-      }
-
-
-      KRB-ERROR-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (30 | 23),
-          ctime       [2] KerberosTime OPTIONAL,
-          cusec       [3] Microseconds OPTIONAL,
-          stime       [4] KerberosTime,
-          susec       [5] Microseconds,
-          error-code  [6] ErrCode,
-          crealm      [7] Realm OPTIONAL,
-          cname       [8] PrincipalName OPTIONAL,
-          realm       [9] Realm -- Correct realm --,
-          sname       [10] PrincipalName -- Correct name --,
-          e-text      [11] KerberosString OPTIONAL,
-          e-data      [12] OCTET STRING OPTIONAL,
-          ...,
-          typed-data          [13] TYPED-DATA OPTIONAL,
-          nonce               [14] Nonce OPTIONAL,
-          lang-tag            [15] LangTag OPTIONAL,
-          ...
-      }
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 98]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      KRB-ERROR-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-ERROR-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (30)
-      })
-
-
-      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
-          (WITH COMPONENTS { ..., msg-type (23) })
-
-
-      METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-
-      TDType ::= TH-id
-
-      TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-          data-type   [0] TDType,
-          data-value  [1] OCTET STRING OPTIONAL
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                   [Page 99]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      --
-      -- *** Error codes
-      --
-
-      -- No error
-      kdc-err-none                          ErrCode ::= 0
-      -- Client's entry in database has expired
-      kdc-err-name-exp                      ErrCode ::= 1
-      -- Server's entry in database has expired
-      kdc-err-service-exp                   ErrCode ::= 2
-      -- Requested protocol version number not supported
-      kdc-err-bad-pvno                      ErrCode ::= 3
-      -- Client's key encrypted in old master key
-      kdc-err-c-old-mast-kvno               ErrCode ::= 4
-      -- Server's key encrypted in old master key
-      kdc-err-s-old-mast-kvno               ErrCode ::= 5
-      -- Client not found in Kerberos database
-      kdc-err-c-principal-unknown           ErrCode ::= 6
-      -- Server not found in Kerberos database
-      kdc-err-s-principal-unknown           ErrCode ::= 7
-      -- Multiple principal entries in database
-      kdc-err-principal-not-unique          ErrCode ::= 8
-      -- The client or server has a null key
-      kdc-err-null-key                      ErrCode ::= 9
-      -- Ticket not eligible for postdating
-      kdc-err-cannot-postdate               ErrCode ::= 10
-      -- Requested start time is later than end time
-      kdc-err-never-valid                   ErrCode ::= 11
-      -- KDC policy rejects request
-      kdc-err-policy                        ErrCode ::= 12
-      -- KDC cannot accommodate requested option
-      kdc-err-badoption                     ErrCode ::= 13
-      -- KDC has no support for encryption type
-      kdc-err-etype-nosupp                  ErrCode ::= 14
-      -- KDC has no support for checksum type
-      kdc-err-sumtype-nosupp                ErrCode ::= 15
-      -- KDC has no support for padata type
-      kdc-err-padata-type-nosupp            ErrCode ::= 16
-      -- KDC has no support for transited type
-      kdc-err-trtype-nosupp                 ErrCode ::= 17
-      -- Clients credentials have been revoked
-      kdc-err-client-revoked                ErrCode ::= 18
-      -- Credentials for server have been revoked
-      kdc-err-service-revoked               ErrCode ::= 19
-      -- TGT has been revoked
-      kdc-err-tgt-revoked                   ErrCode ::= 20
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                  [Page 100]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- Client not yet valid - try again later
-      kdc-err-client-notyet                 ErrCode ::= 21
-      -- Server not yet valid - try again later
-      kdc-err-service-notyet                ErrCode ::= 22
-      -- Password has expired - change password to reset
-      kdc-err-key-expired                   ErrCode ::= 23
-      -- Pre-authentication information was invalid
-      kdc-err-preauth-failed                ErrCode ::= 24
-      -- Additional pre-authenticationrequired
-      kdc-err-preauth-required              ErrCode ::= 25
-      -- Requested server and ticket don't match
-      kdc-err-server-nomatch                ErrCode ::= 26
-      -- Server principal valid for user2user only
-      kdc-err-must-use-user2user            ErrCode ::= 27
-      -- KDC Policy rejects transited path
-      kdc-err-path-not-accpeted             ErrCode ::= 28
-      -- A service is not available
-      kdc-err-svc-unavailable               ErrCode ::= 29
-      -- Integrity check on decrypted field failed
-      krb-ap-err-bad-integrity              ErrCode ::= 31
-      -- Ticket expired
-      krb-ap-err-tkt-expired                ErrCode ::= 32
-      -- Ticket not yet valid
-      krb-ap-err-tkt-nyv                    ErrCode ::= 33
-      -- Request is a replay
-      krb-ap-err-repeat                     ErrCode ::= 34
-      -- The ticket isn't for us
-      krb-ap-err-not-us                     ErrCode ::= 35
-      -- Ticket and authenticator don't match
-      krb-ap-err-badmatch                   ErrCode ::= 36
-      -- Clock skew too great
-      krb-ap-err-skew                       ErrCode ::= 37
-      -- Incorrect net address
-      krb-ap-err-badaddr                    ErrCode ::= 38
-      -- Protocol version mismatch
-      krb-ap-err-badversion                 ErrCode ::= 39
-      -- Invalid msg type
-      krb-ap-err-msg-type                   ErrCode ::= 40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                  [Page 101]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- Message stream modified
-      krb-ap-err-modified                   ErrCode ::= 41
-      -- Message out of order
-      krb-ap-err-badorder                   ErrCode ::= 42
-      -- Specified version of key is not available
-      krb-ap-err-badkeyver                  ErrCode ::= 44
-      -- Service key not available
-      krb-ap-err-nokey                      ErrCode ::= 45
-      -- Mutual authentication failed
-      krb-ap-err-mut-fail                   ErrCode ::= 46
-      -- Incorrect message direction
-      krb-ap-err-baddirection               ErrCode ::= 47
-      -- Alternative authentication method required
-      krb-ap-err-method                     ErrCode ::= 48
-      -- Incorrect sequence number in message
-      krb-ap-err-badseq                     ErrCode ::= 49
-      -- Inappropriate type of checksum in message
-      krb-ap-err-inapp-cksum                ErrCode ::= 50
-      -- Policy rejects transited path
-      krb-ap-path-not-accepted              ErrCode ::= 51
-      -- Response too big for UDP, retry with TCP
-      krb-err-response-too-big              ErrCode ::= 52
-      -- Generic error (description in e-text)
-      krb-err-generic                       ErrCode ::= 60
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Mar 2005                  [Page 102]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-      -- Field is too long for this implementation
-      krb-err-field-toolong                 ErrCode ::= 61
-      -- Reserved for PKINIT
-      kdc-error-client-not-trusted          ErrCode ::= 62
-      -- Reserved for PKINIT
-      kdc-error-kdc-not-trusted             ErrCode ::= 63
-      -- Reserved for PKINIT
-      kdc-error-invalid-sig                 ErrCode ::= 64
-      -- Reserved for PKINIT
-      kdc-err-key-too-weak                  ErrCode ::= 65
-      -- Reserved for PKINIT
-      kdc-err-certificate-mismatch          ErrCode ::= 66
-      -- No TGT available to validate USER-TO-USER
-      krb-ap-err-no-tgt                     ErrCode ::= 67
-      -- USER-TO-USER TGT issued different KDC
-      kdc-err-wrong-realm                   ErrCode ::= 68
-      -- Ticket must be for USER-TO-USER
-      krb-ap-err-user-to-user-required      ErrCode ::= 69
-      -- Reserved for PKINIT
-      kdc-err-cant-verify-certificate       ErrCode ::= 70
-      -- Reserved for PKINIT
-      kdc-err-invalid-certificate           ErrCode ::= 71
-      -- Reserved for PKINIT
-      kdc-err-revoked-certificate           ErrCode ::= 72
-      -- Reserved for PKINIT
-      kdc-err-revocation-status-unknown     ErrCode ::= 73
-      -- Reserved for PKINIT
-      kdc-err-revocation-status-unavailable ErrCode ::= 74
-
-
-      END
-
-
-B.  Kerberos and Character Encodings (Informative)
-
-   [adapted from KCLAR 5.2.1]
-
-   The original specification of the Kerberos protocol in RFC 1510 uses
-   GeneralString in numerous places for human-readable string data.
-   Historical implementations of Kerberos cannot utilize the full power
-   of GeneralString.  This ASN.1 type requires the use of designation
-   and invocation escape sequences as specified in ISO 2022 | ECMA-35
-   [ISO2022] to switch character sets, and the default character set
-   that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
-   International Reference Version (IRV) (aka U.S. ASCII), which mostly
-   works.
-
-   ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3)
-   and two Control-function code elements (C0..C1).  DER previously
-   [X690-1997] prohibited the designation of character sets as any but
-   the G0 and C0 sets.  This had the side effect of prohibiting the use
-
-Yu                         Expires: Mar 2005                  [Page 103]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any
-   other character-sets that utilize a 96-character set, since it is
-   prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code
-   element.  Recent revisions to the ASN.1 standards resolve this
-   contradiction.
-
-   In practice, many implementations treat RFC 1510 GeneralStrings as if
-   they were 8-bit strings of whichever character set the implementation
-   defaults to, without regard for correct usage of character-set
-   designation escape sequences.  The default character set is often
-   determined by the current user's operating system dependent locale.
-   At least one major implementation places unescaped UTF-8 encoded
-   Unicode characters in the GeneralString.  This failure to conform to
-   the GeneralString specifications results in interoperability issues
-   when conflicting character encodings are utilized by the Kerberos
-   clients, services, and KDC.
-
-   This unfortunate situation is the result of improper documentation of
-   the restrictions of the ASN.1 GeneralString type in prior Kerberos
-   specifications.
-
-   [the following should probably be rewritten and moved into the
-   principal name section]
-
-   For compatibility, implementations MAY choose to accept GeneralString
-   values that contain characters other than those permitted by
-   IA5String, but they should be aware that character set designation
-   codes will likely be absent, and that the encoding should probably be
-   treated as locale-specific in almost every way.  Implementations MAY
-   also choose to emit GeneralString values that are beyond those
-   permitted by IA5String, but should be aware that doing so is
-   extraordinarily risky from an interoperability perspective.
-
-   Some existing implementations use GeneralString to encode unescaped
-   locale-specific characters.  This is a violation of the ASN.1
-   standard.  Most of these implementations encode US-ASCII in the left-
-   hand half, so as long the implementation transmits only US-ASCII, the
-   ASN.1 standard is not violated in this regard.  As soon as such an
-   implementation encodes unescaped locale-specific characters with the
-   high bit set, it violates the ASN.1 standard.
-
-   Other implementations have been known to use GeneralString to contain
-   a UTF-8 encoding.  This also violates the ASN.1 standard, since UTF-8
-   is a different encoding, not a 94 or 96 character "G" set as defined
-   by ISO 2022.  It is believed that these implementations do not even
-   use the ISO 2022 escape sequence to change the character encoding.
-   Even if implementations were to announce the change of encoding by
-   using that escape sequence, the ASN.1 standard prohibits the use of
-   any escape sequences other than those used to designate/invoke "G" or
-   "C" sets allowed by GeneralString.
-
-
-Yu                         Expires: Mar 2005                  [Page 104]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-C.  Kerberos History (Informative)
-
-   [Adapted from KCLAR "BACKGROUND"]
-
-   The Kerberos model is based in part on Needham and Schroeder's
-   trusted third-party authentication protocol [NS78] and on
-   modifications suggested by Denning and Sacco [DS81].  The original
-   design and implementation of Kerberos Versions 1 through 4 was the
-   work of two former Project Athena staff members, Steve Miller of
-   Digital Equipment Corporation and Clifford Neuman (now at the
-   Information Sciences Institute of the University of Southern
-   California), along with Jerome Saltzer, Technical Director of Project
-   Athena, and Jeffrey Schiller, MIT Campus Network Manager.  Many other
-   members of Project Athena have also contributed to the work on
-   Kerberos.
-
-   Version 5 of the Kerberos protocol (described in this document) has
-   evolved from Version 4 based on new requirements and desires for
-   features not available in Version 4.  The design of Version 5 of the
-   Kerberos protocol was led by Clifford Neuman and John Kohl with much
-   input from the community.  The development of the MIT reference
-   implementation was led at MIT by John Kohl and Theodore Ts'o, with
-   help and contributed code from many others.  Since RFC1510 was
-   issued, extensions and revisions to the protocol have been proposed
-   by many individuals.  Some of these proposals are reflected in this
-   document.  Where such changes involved significant effort, the
-   document cites the contribution of the proposer.
-
-   Reference implementations of both version 4 and version 5 of Kerberos
-   are publicly available and commercial implementations have been
-   developed and are widely used.  Details on the differences between
-   Kerberos Versions 4 and 5 can be found in [KNT94].
-
-D.  Notational Differences from [KCLAR]
-
-   [ possible point for discussion ]
-
-   [KCLAR] uses notational conventions slightly different from this
-   document.  As a derivative of RFC 1510, the text of [KCLAR] uses C-
-   language style identifier names for defined values.  In ASN.1
-   notation, identifiers referencing defined values must begin with a
-   lowercase letter and contain hyphen (-) characters rather than
-   underscore (_) characters, while identifiers referencing types begin
-   with an uppercase letter.  [KCLAR] and RFC 1510 use all-uppercase
-   identifiers with underscores to identify defined values.  This has
-   the potential to create confusion, but neither document defines
-   values using actual ASN.1 value-assignment notation.
-
-   It is debatable whether it is advantageous to write all identifier
-   names (regardless of their ASN.1 token type) in all-uppercase letters
-   for the purpose of emphasis in running text.  The alternative is to
-
-Yu                         Expires: Mar 2005                  [Page 105]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   use double-quote characters (") when ambiguity is possible.
-
-Normative References
-
-   [ISO646]
-        "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
-
-   [ISO2022]
-        "Information technology -- Character code structure and
-        extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
-
-   [KCRYPTO]
-        K. Raeburn, "Encryption and Checksum Specifications for Kerberos
-        5", draft-ietf-krb-wg-crypto-07.txt, work in progress.
-
-   [RFC2119]
-        S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
-        Requirement Levels", March 1997.
-
-   [RFC3660]
-        H. Alvestrand, "Tags for the Identification of Languages",
-        RFC 3660, January 2001.
-
-   [SASLPREP]
-        Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names
-        and passwords", draft-ietf-sasl-saslprep-10.txt, work in
-        progress.
-
-   [X680]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Specification of basic notation", ITU-T Recommendation X.680
-        (2002) | ISO/IEC 8824-1:2002.
-
-   [X682]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Constraint specification", ITU-T Recommendation X.682 (2002) |
-        ISO/IEC 8824-3:2002.
-
-   [X683]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Parameterization of ASN.1 specifications", ITU-T Recommendation
-        X.683 (2002) | ISO/IEC 8824-4:2002.
-
-   [X690]
-        "Information technology -- ASN.1 encoding Rules: Specification
-        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
-        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
-        X.690 (2002) | ISO/IEC 8825-1:2002.
-
-
-
-
-Yu                         Expires: Mar 2005                  [Page 106]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-Informative References
-
-   [DS81]
-        Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
-        Distribution Protocols," Communications of the ACM, Vol. 24(8),
-        pp. 533-536 (August 1981).
-
-   [Dub00]
-        Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
-        Systems", Elsevier-Morgan Kaufmann, 2000.
-        <http://www.oss.com/asn1/dubuisson.html>
-
-   [ISO8859-1]
-        "Information technology -- 8-bit single-byte coded graphic
-        character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859-
-        1:1998.
-
-   [KCLAR]
-        Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos
-        Network Authentication Service (V5)", draft-ietf-krb-wg-
-        kerberos-clarifications-07.txt, work in progress.
-
-   [KNT94]
-        John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
-        Evolution of the Kerberos Authentication System".  In
-        Distributed Open Systems, pages 78-94.  IEEE Computer Society
-        Press, 1994.
-
-   [Lar96]
-        John Larmouth, "Understanding OSI", International Thomson
-        Computer Press, 1996.
-        <http://www.isi.salford.ac.uk/books/osi.html>
-
-   [Lar99]
-        John Larmouth, "ASN.1 Complete",  Elsevier-Morgan Kaufmann,
-        1999.  <http://www.oss.com/asn1/larmouth.html>
-
-   [NS78]
-        Roger M. Needham and Michael D. Schroeder, "Using Encryption for
-        Authentication in Large Networks of Computers", Communications
-        of the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
-
-   [RFC1510]
-        J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
-        Service (v5)", RFC1510, September 1993, Status: Proposed
-        Standard.
-
-   [RFC1964]
-        J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
-        June 1996, Status: Proposed Standard.
-
-
-Yu                         Expires: Mar 2005                  [Page 107]
-
-Internet-Draft               rfc1510ter-01                   15 Sep 2005
-
-   [X690-2002]
-        "Information technology -- ASN.1 encoding rules: Specification
-        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
-        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
-        X.690 (2002) | ISO/IEC 8825-1:2002.
-
-Author's Address
-
-   Tom Yu
-   77 Massachusetts Ave
-   Cambridge, MA 02139
-   USA
-   tlyu@mit.edu
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Yu                         Expires: Mar 2005                  [Page 108]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-03.txt b/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-03.txt
deleted file mode 100644
index 009e8bd2b..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-03.txt
+++ /dev/null
@@ -1,6217 +0,0 @@
-
-
-INTERNET-DRAFT                                                    Tom Yu
-draft-ietf-krb-wg-rfc1510ter-03.txt                                  MIT
-Expires: 26 Apr 2006                                     23 October 2006
-
-        The Kerberos Network Authentication Service (Version 5)
-
-Status of This Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-
-      http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-
-      http://www.ietf.org/shadow.html
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).  All Rights Reserved.
-
-Abstract
-
-   This document describes version 5 of the Kerberos network
-   authentication protocol.  It describes a framework to allow for
-   extensions to be made to the protocol without creating
-   interoperability problems.
-
-Key Words for Requirements
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
-   to be interpreted as described in RFC 2119.
-
-
-
-
-Yu                         Expires: Apr 2007                    [Page 1]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-Table of Contents
-
-   Status of This Memo ..............................................  1
-   Copyright Notice .................................................  1
-   Abstract .........................................................  1
-   Key Words for Requirements .......................................  1
-   Table of Contents ................................................  2
-   1.  Introduction .................................................  5
-   1.1.  Kerberos Protocol Overview .................................  5
-   1.2.  Document Organization ......................................  6
-   2.  Compatibility Considerations .................................  6
-   2.1.  Extensibility ..............................................  7
-   2.2.  Compatibility with RFC 1510 ................................  7
-   2.3.  Backwards Compatibility ....................................  7
-   2.4.  Sending Extensible Messages ................................  8
-   2.5.  Criticality ................................................  8
-   2.6.  Authenticating Cleartext Portions of Messages ..............  9
-   2.7.  Capability Negotiation ..................................... 10
-   2.7.1.  KDC protocol ............................................. 10
-   2.7.2.  Application protocol ..................................... 11
-   2.8.  Strings .................................................... 11
-   3.  Use of ASN.1 in Kerberos ..................................... 11
-   3.1.  Module Header .............................................. 12
-   3.2.  Top-Level Type ............................................. 12
-   3.3.  Previously Unused ASN.1 Notation (informative) ............. 13
-   3.3.1.  Parameterized Types ...................................... 13
-   3.3.2.  Constraints .............................................. 13
-   3.4.  New Types .................................................. 13
-   4.  Basic Types .................................................. 14
-   4.1.  Constrained Integer Types .................................. 14
-   4.2.  KerberosTime ............................................... 15
-   4.3.  KerberosString ............................................. 15
-   4.4.  Language Tags .............................................. 16
-   4.5.  KerberosFlags .............................................. 16
-   4.6.  Typed Holes ................................................ 17
-   4.7.  HostAddress and HostAddresses .............................. 17
-   4.7.1.  Internet (IPv4) Addresses ................................ 18
-   4.7.2.  Internet (IPv6) Addresses ................................ 18
-   4.7.3.  DECnet Phase IV addresses ................................ 18
-   4.7.4.  Netbios addresses ........................................ 18
-   4.7.5.  Directional Addresses .................................... 18
-   5.  Principals ................................................... 19
-   5.1.  Name Types ................................................. 19
-   5.2.  Principal Type Definition .................................. 20
-   5.3.  Principal Name Reuse ....................................... 21
-   5.4.  Best Common Practice Recommendations for the Processing
-            of Principal Names Consisting of Internationalized
-            Domain Names:  .......................................... 21
-   5.5.  Realm Names ................................................ 22
-   5.6.  Best Common Practice Recommendations for the Processing
-            of Internationalized Domain-Style Realm Names:  ......... 22
-
-Yu                         Expires: Apr 2007                    [Page 2]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   5.7.  Printable Representations of Principal Names ............... 23
-   5.8.  Ticket-Granting Service Principal .......................... 23
-   5.8.1.  Cross-Realm TGS Principals ............................... 24
-   6.  Types Relating to Encryption ................................. 24
-   6.1.  Assigned Numbers for Encryption ............................ 24
-   6.1.1.  EType .................................................... 24
-   6.1.2.  Key Usages ............................................... 25
-   6.2.  Which Key to Use ........................................... 26
-   6.3.  EncryptionKey .............................................. 27
-   6.4.  EncryptedData .............................................. 27
-   6.5.  Checksums .................................................. 28
-   6.5.1.  ChecksumOf ............................................... 29
-   6.5.2.  Signed ................................................... 30
-   7.  Tickets ...................................................... 30
-   7.1.  Timestamps ................................................. 31
-   7.2.  Ticket Flags ............................................... 32
-   7.2.1.  Flags Relating to Initial Ticket Acquisition ............. 32
-   7.2.2.  Invalid Tickets .......................................... 33
-   7.2.3.  OK as Delegate ........................................... 33
-   7.2.4.  Renewable Tickets ........................................ 34
-   7.2.5.  Postdated Tickets ........................................ 34
-   7.2.6.  Proxiable and Proxy Tickets .............................. 35
-   7.2.7.  Forwarded and Forwardable Tickets ........................ 36
-   7.3.  Transited Realms ........................................... 37
-   7.4.  Authorization Data ......................................... 37
-   7.4.1.  AD-IF-RELEVANT ........................................... 38
-   7.4.2.  AD-KDCIssued ............................................. 39
-   7.4.3.  AD-AND-OR ................................................ 40
-   7.4.4.  AD-MANDATORY-FOR-KDC ..................................... 40
-   7.5.  Encrypted Part of Ticket ................................... 41
-   7.6.  Cleartext Part of Ticket ................................... 41
-   8.  Credential Acquisition ....................................... 43
-   8.1.  KDC-REQ .................................................... 43
-   8.2.  PA-DATA .................................................... 50
-   8.3.  KDC-REQ Processing ......................................... 50
-   8.3.1.  Handling Replays ......................................... 50
-   8.3.2.  Request Validation ....................................... 51
-   8.3.2.1.  AS-REQ Authentication .................................. 51
-   8.3.2.2.  TGS-REQ Authentication ................................. 51
-   8.3.2.3.  Principal Validation ................................... 51
-   8.3.2.4.  Checking For Revoked or Invalid Tickets ................ 51
-   8.3.3.  Timestamp Handling ....................................... 52
-   8.3.3.1.  AS-REQ Timestamp Processing ............................ 52
-   8.3.3.2.  TGS-REQ Timestamp Processing ........................... 53
-   8.3.4.  Handling Transited Realms ................................ 54
-   8.3.5.  Address Processing ....................................... 54
-   8.3.6.  Ticket Flag Processing ................................... 54
-   8.3.7.  Key Selection ............................................ 56
-   8.3.7.1.  Reply Key and Session Key Selection .................... 56
-   8.3.7.2.  Ticket Key Selection ................................... 56
-   8.4.  KDC-REP .................................................... 56
-
-Yu                         Expires: Apr 2007                    [Page 3]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   8.5.  Reply Validation ........................................... 60
-   8.6.  IP Transports .............................................. 60
-   8.6.1.  UDP/IP transport ......................................... 60
-   8.6.2.  TCP/IP transport ......................................... 60
-   8.6.3.  KDC Discovery on IP Networks ............................. 62
-   8.6.3.1.  DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 62
-   8.6.3.2.  DNS SRV records for KDC location ....................... 62
-   8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP
-                Networks ............................................ 63
-   9.  Errors ....................................................... 63
-   10.  Session Key Exchange ........................................ 65
-   10.1.  AP-REQ .................................................... 66
-   10.2.  AP-REP .................................................... 67
-   11.  Session Key Use ............................................. 69
-   11.1.  KRB-SAFE .................................................. 69
-   11.2.  KRB-PRIV .................................................. 69
-   11.3.  KRB-CRED .................................................. 70
-   12.  Security Considerations ..................................... 71
-   12.1.  Time Synchronization ...................................... 71
-   12.2.  Replays ................................................... 71
-   12.3.  Principal Name Reuse ...................................... 72
-   12.4.  Password Guessing ......................................... 72
-   12.5.  Forward Secrecy ........................................... 72
-   12.6.  Authorization ............................................. 72
-   12.7.  Login Authentication ...................................... 72
-   13.  IANA Considerations ......................................... 72
-   14.  Acknowledgments ............................................. 73
-   Appendices ....................................................... 73
-   A.  ASN.1 Module (Normative) ..................................... 73
-   B.  Kerberos and Character Encodings (Informative) ...............105
-   C.  Kerberos History (Informative) ...............................107
-   D.  Notational Differences from [KCLAR] ..........................107
-   Normative References .............................................108
-   Informative References ...........................................109
-   Author's Address .................................................110
-   Copyright Statement ..............................................110
-   Intellectual Property Statement ..................................110
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                    [Page 4]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-1.  Introduction
-
-   The Kerberos network authentication protocol is a trusted-third-party
-   protocol utilizing symmetric-key cryptography.  It assumes that all
-   communications between parties in the protocol may be arbitrarily
-   tampered with or monitored, and that the security of the overall
-   system depends only on the effectiveness of the cryptographic
-   techniques and the secrecy of the cryptographic keys used.  The
-   Kerberos protocol authenticates an application client's identity to
-   an application server, and likewise authenticates the application
-   server's identity to the application client.  These assurances are
-   made possible by the client and the server sharing secrets with the
-   trusted third party: the Kerberos server, also known as the Key
-   Distribution Center (KDC).  In addition, the protocol establishes an
-   ephemeral shared secret (the session key) between the client and the
-   server, allowing the protection of further communications between
-   them.
-
-   The Kerberos protocol, as originally specified, provides insufficient
-   means for extending the protocol in a backwards-compatible way.  This
-   deficiency has caused problems for interoperability.  This document
-   describes a framework which enables backwards-compatible extensions
-   to the Kerberos protocol.
-
-1.1.  Kerberos Protocol Overview
-
-   Kerberos comprises three main sub-protocols: credentials acquisition,
-   session key exchange, and session key usage.  A client acquires
-   credentials by asking the KDC for a credential for a service; the KDC
-   issues the credential, which contains a ticket and a session key.
-   The ticket, containing the client's identity, timestamps, expiration
-   time, and a session key, is a encrypted in a key known to the
-   application server.  The KDC encrypts the credential using a key
-   known to the client, and transmits the credential to the client.
-
-   There are two means of requesting credentials: the Authentication
-   Service (AS) exchange, and the Ticket-Granting Service (TGS)
-   exchange.  In the typical AS exchange, a client uses a password-
-   derived key to decrypt the response.  In the TGS exchange, the KDC
-   behaves as an application server; the client authenticates to the TGS
-   by using a Ticket-Granting Ticket (TGT).  The client usually obtains
-   the TGT by using the AS exchange.
-
-   Session key exchange consists of the client transmitting the ticket
-   to the application server, accompanied by an authenticator.  The
-   authenticator contains a timestamp and additional data encrypted
-   using the ticket's session key.  The application server decrypts the
-   ticket, extracting the session key.  The application server then uses
-   the session key to decrypt the authenticator.  Upon successful
-   decryption of the authenticator, the application server knows that
-   the data in the authenticator were sent by the client named in the
-
-Yu                         Expires: Apr 2007                    [Page 5]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   associated ticket.  Additionally, since authenticators expire more
-   quickly than tickets, the application server has some assurance that
-   the transaction is not a replay.  The application server may send an
-   encrypted acknowledgment to the client, verifying its identity to the
-   client.
-
-   Once session key exchange has occurred, the client and server may use
-   the established session key to protect further traffic.  This
-   protection may consist of protection of integrity only, or of
-   protection of confidentiality and integrity.  Additional measures
-   exist for a client to securely forward credentials to a server.
-
-   The entire scheme depends on loosely synchronized clocks.
-   Synchronization of the clock on the KDC with the application server
-   clock allows the application server to accurately determine whether a
-   credential is expired.  Likewise, synchronization of the clock on the
-   client with the application server clock prevents replay attacks
-   utilizing the same credential.  Careful design of the application
-   protocol may allow replay prevention without requiring client-server
-   clock synchronization.
-
-   After establishing a session key, application client and the
-   application server can exchange Kerberos protocol messages that use
-   the session key to protect the integrity or confidentiality of
-   communications between the client and the server.  Additionally, the
-   client may forward credentials to the application server.
-
-   The credentials acquisition protocol takes place over specific,
-   defined transports (UDP and TCP).  Application protocols define which
-   transport to use for the session key establishment protocol and for
-   messages using the session key; the application may choose to perform
-   its own encapsulation of the Kerberos messages, for example.
-
-1.2.  Document Organization
-
-   The remainder of this document begins by describing the general
-   frameworks for protocol extensibility, including whether to interpret
-   unknown extensions as critical.  It then defines the protocol
-   messages and exchanges.
-
-   The definition of the Kerberos protocol uses Abstract Syntax Notation
-   One (ASN.1) [X680], which specifies notation for describing the
-   abstract content of protocol messages.  This document defines a
-   number of base types using ASN.1; these base types subsequently
-   appear in multiple types which define actual protocol messages.
-   Definitions of principal names and of tickets, which are central to
-   the protocol, also appear preceding the protocol message definitions.
-
-
-
-
-
-Yu                         Expires: Apr 2007                    [Page 6]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-2.  Compatibility Considerations
-
-2.1.  Extensibility
-
-   In the past, significant interoperability problems have resulted from
-   conflicting assumptions about how the Kerberos protocol can be
-   extended.  As the deployed base of Kerberos grows, the ability to
-   extend the Kerberos protocol becomes more important.  In order to
-   ensure that vendors and the IETF can extend the protocol while
-   maintaining backwards compatibility, this document outlines a
-   framework for extending Kerberos.
-
-   Kerberos provides two general mechanisms for protocol extensibility.
-   Many protocol messages, including some defined in RFC 1510, contain
-   typed holes--sub-messages containing an octet string along with an
-   integer that identifies how to interpret the octet string.  The
-   integer identifiers are registered centrally, but can be used both
-   for vendor extensions and for extensions standardized in the IETF.
-   This document adds typed holes to a number of messages which
-   previously lacked typed holes.
-
-   Many new messages defined in this document also contain ASN.1
-   extension markers.  These markers allow future revisions of this
-   document to add additional elements to messages, for cases where
-   typed holes are inadequate for some reason.  Because tag numbers and
-   position in a sequence need to be coordinated in order to maintain
-   interoperability, implementations MUST NOT include ASN.1 extensions
-   except when those extensions are specified by IETF standards-track
-   documents.
-
-2.2.  Compatibility with RFC 1510
-
-   Implementations of RFC 1510 did not use extensible ASN.1 types.
-   Sending additional fields not in RFC 1510 to these implementations
-   results in undefined behavior.  Examples of this behavior are known
-   to include discarding messages with no error indications.
-
-   Where messages have been changed since RFC 1510, ASN.1 CHOICE types
-   are used; one alternative of the CHOICE provides a message which is
-   wire-encoding compatible with RFC 1510, and the other alternative
-   provides the new, extensible message.
-
-   Implementations sending new messages MUST ensure that the recipient
-   supports these new messages.  Along with each extensible message is a
-   guideline for when that message MAY be used.  If that guideline is
-   followed, then the recipient is guaranteed to understand the message.
-
-2.3.  Backwards Compatibility
-
-   This document describes two sets (for the most part) of ASN.1 types.
-   The first set of types is wire-encoding compatible with RFC 1510 and
-
-Yu                         Expires: Apr 2007                    [Page 7]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   [KCLAR].  The second set of types is the set of types enabling
-   extensibility.  This second set may be referred to as
-   "extensibility-enabled types". [ need to make this consistent
-   throughout? ]
-
-   A major difference between the new extensibility-enabled types and
-   the types for RFC 1510 compatibility is that the extensibility-
-   enabled types allow for the use of UTF-8 encodings in various
-   character strings in the protocol.  Each party in the protocol must
-   have some knowledge of the capabilities of the other parties in the
-   protocol.  There are methods for establishing this knowledge without
-   necessarily requiring explicit configuration.
-
-   An extensibility-enabled client can detect whether a KDC supports the
-   extensibility-enabled types by requesting an extensibility-enabled
-   reply.  If the KDC replies with an extensibility-enabled reply, the
-   client knows that the KDC supports extensibility.  If the KDC issues
-   an extensibility-enabled ticket, the client knows that the service
-   named in the ticket is extensibility-enabled.
-
-2.4.  Sending Extensible Messages
-
-   Care must be taken to make sure that old implementations can
-   understand messages sent to them even if they do not understand an
-   extension that is used.  Unless the sender knows the extension is
-   supported, the extension cannot change the semantics of the core
-   message or previously defined extensions.
-
-   For example, an extension including key information necessary to
-   decrypt the encrypted part of a KDC-REP could only be used in
-   situations where the recipient was known to support the extension.
-   Thus when designing such extensions it is important to provide a way
-   for the recipient to notify the sender of support for the extension.
-   For example in the case of an extension that changes the KDC-REP
-   reply key, the client could indicate support for the extension by
-   including a padata element in the AS-REQ sequence.  The KDC should
-   only use the extension if this padata element is present in the AS-
-   REQ.  Even if policy requires the use of the extension, it is better
-   to return an error indicating that the extension is required than to
-   use the extension when the recipient may not support it; debugging
-   why implementations do not interoperate is easier when errors are
-   returned.
-
-2.5.  Criticality
-
-   Recipients of unknown message extensions (including typed holes, new
-   flags, and ASN.1 extension elements) should preserve the encoding of
-   the extension but otherwise ignore the presence of the extension;
-   i.e., unknown extensions SHOULD be treated as non-critical.  If a
-   copy of the message is used later--for example, when a Ticket
-   received in a KDC-REP is later used in an AP-REQ--then the unknown
-
-Yu                         Expires: Apr 2007                    [Page 8]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   extensions MUST be included.
-
-   An implementation SHOULD NOT reject a request merely because it does
-   not understand some element of the request.  As a related
-   consequence, implementations SHOULD handle communicating with other
-   implementations which do not implement some requested options.  This
-   may require designers of options to provide means to determine
-   whether an option has been rejected, not understood, or (perhaps
-   maliciously) deleted or modified in transit.
-
-   There is one exception to non-criticality described above: if an
-   unknown authorization data element is received by a server either in
-   an AP-REQ or in a Ticket contained in an AP-REQ, then the
-   authentication SHOULD fail.  Authorization data is intended to
-   restrict the use of a ticket.  If the service cannot determine
-   whether the restriction applies to that service then a security
-   weakness may result if authentication succeeds.  Authorization
-   elements meant to be truly optional can be enclosed in the AD-IF-
-   RELEVANT element.
-
-   Many RFC 1510 implementations ignore unknown authorization data
-   elements.  Depending on these implementations to honor authorization
-   data restrictions may create a security weakness.
-
-2.6.  Authenticating Cleartext Portions of Messages
-
-   Various denial of service attacks and downgrade attacks against
-   Kerberos are possible unless plaintexts are somehow protected against
-   modification.  An early design goal of Kerberos Version 5 was to
-   avoid encrypting more of the authentication exchange that was
-   required.  (Version 4 doubly-encrypted the encrypted part of a ticket
-   in a KDC reply, for example.)  This minimization of encryption
-   reduces the load on the KDC and busy servers.  Also, during the
-   initial design of Version 5, the existence of legal restrictions on
-   the export of cryptography made it desirable to minimize of the
-   number of uses of encryption in the protocol.  Unfortunately,
-   performing this minimization created numerous instances of
-   unauthenticated security-relevant plaintext fields.
-
-   The extensible variants of the messages described in this document
-   wrap the actual message in an ASN.1 sequence containing a keyed
-   checksum of the contents of the message.  Guidelines in [XXX] section
-   3 specify when the checksum MUST be included and what key MUST be
-   used.  Guidelines on when to include a checksum are never ambiguous:
-   a particular PDU is never correct both with and without a checksum.
-   With the exception of the KRB-ERROR message, receiving
-   implementations MUST reject messages where a checksum is included and
-   not expected or where a checksum is expected but not included.  The
-   receiving implementation does not always have sufficient information
-   to know whether a KRB-ERROR should contain a checksum.  Even so,
-   KRB-ERROR messages with invalid checksums MUST be rejected and
-
-Yu                         Expires: Apr 2007                    [Page 9]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   implementations MAY consider the presence or absence of a checksum
-   when evaluating whether to trust the error.
-
-   This authenticated cleartext protection is provided only in the
-   extensible variants of the messages; it is never used when
-   communicating with an RFC 1510 implementation.
-
-2.7.  Capability Negotiation
-
-   Kerberos is a three-party protocol.  Each of the three parties
-   involved needs a means of detecting the capabilities supported by the
-   others.  Two of the parties, the KDC and the application server, do
-   not communicate directly in the Kerberos protocol.  Communicating
-   capabilities from the KDC to the application server requires using a
-   ticket as an intermediary.
-
-   The main capability requiring negotiation is the support of the
-   extensibility framework described in this document.  Negotiation of
-   this capability while remaining compatible with RFC 1510
-   implementations is possible.  The main complication is that the
-   client needs to know whether the application server supports the
-   extensibility framework prior to sending any message to the
-   application server.  This can be accomplished if the KDC has
-   knowledge of whether an application server supports the extensibility
-   framework.
-
-   Client software advertizes its capabilities when requesting
-   credentials from the KDC.  If the KDC recognizes the capabilities, it
-   acknowledges this fact to the client in its reply.  In addition, if
-   the KDC has knowledge that the application server supports certain
-   capabilities, it also communicates this knowledge to the client in
-   its reply.  The KDC can encode its own capabilities in the ticket so
-   that the application server may discover these capabilities.  The
-   client advertizes its capabilities to the application server when it
-   initiates authentication to the application server.
-
-2.7.1.  KDC protocol
-
-   A client may send an AS-REQ-EXT if it has prior knowledge that the
-   KDC in question will accept it.  (possibly via a TCP extension?)
-   Otherwise, the client will send an AS-REQ-1510 with the AS-REQ-EXT
-   inside preauthentication data.  The client will always know whether
-   to send TGS-REQ-EXT because (as in the application protocol) it knows
-   the type of the associated Ticket.  (Note: could be a problem with
-   non-TGT tickets)
-
-   The KDC will send AS-REP-EXT or TGS-REP-EXT if the client's message
-   is extensible; otherwise, it will send AS-REP-1510 or TGS-REP-1510.
-   The Ticket contained within the AS-REP-EXT or TGS-REP-EXT will be a
-   TicketExt if the application server supports it; otherwise, it will
-   be a Ticket1510.  AS-REP-1510 and TGS-REP-1510 always contain a
-
-Yu                         Expires: Apr 2007                   [Page 10]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   Ticket1510.  The EncTicketPart will depend on the server's
-   capability; the client cannot distinguish EncTicketPart1510 from
-   EncTicketPartExt.
-
-   KDCs within a realm should be uniform in advertized capability for
-   extensible messages.  A KDC SHOULD only issue a TicketExt TGT if all
-   KDCs support it.  Similarly, a client receiving a TicketExt knows
-   that all instances of the application service will accept extensible
-   messages.
-
-2.7.2.  Application protocol
-
-   The client knows whether the application server supports AP-REQ-EXT
-   because it can distinguish Ticket1510 from TicketExt.  The server
-   knows the client's capability due to the format of the AP-REQ.
-
-2.8.  Strings
-
-   Some implementations of RFC 1510 do not limit princpal names and
-   realm names to ASCII characters.  As a result, migration difficulties
-   resulting from legacy non-ASCII principal and realm names can arise.
-   Is it reasonable to assume that any legacy non-ASCII character can be
-   uniquely represented in Unicode?
-
-   This may result in a situation where various parties of the protocol
-   need to know alternate, possibly multiple, legacy non-ASCII names for
-   principals and also to know how they map into Unicode.  An
-   application server needs to know all possible legacy encodings of its
-   name if it receives a "mixed" ticket. (Ticket1510 containing
-   EncTicketPartExt) It also needs to be able to compare a legacy
-   encoding of a client principal against the normalized UTF-8 encoding
-   when checking the client's principal name in the Authenticator
-   against the one contained in the EncTicketPart.  This check can be
-   avoided if the application protocol does not require a replay cache.
-
-3.  Use of ASN.1 in Kerberos
-
-   Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
-   Even though ASN.1 theoretically allows the description of protocol
-   messages to be independent of the encoding rules used to encode the
-   messages, Kerberos messages MUST be encoded with DER.  Subtleties in
-   the semantics of the notation, such as whether tags carry any
-   semantic content to the application, may cause the use of other ASN.1
-   encoding rules to be problematic.
-
-   Implementors not using existing ASN.1 tools (e.g., compilers or
-   support libraries) are cautioned to thoroughly read and understand
-   the actual ASN.1 specification to ensure correct implementation
-   behavior.  There is more complexity in the notation than is
-   immediately obvious, and some tutorials and guides to ASN.1 are
-   misleading or erroneous.  Recommended tutorials and guides include
-
-Yu                         Expires: Apr 2007                   [Page 11]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   [Dub00], [Lar99], though there is still no substitute for reading the
-   actual ASN.1 specification.
-
-3.1.  Module Header
-
-   The type definitions in this document assume an ASN.1 module
-   definition of the following form:
-
-      KerberosV5Spec3 {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2) modules(4) krb5spec3(4)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      -- Rest of definitions here
-
-      END
-
-   This specifies that the tagging context for the module will be
-   explicit and that automatic tagging is not done.
-
-   Some other publications [RFC1510] [RFC1964] erroneously specify an
-   object identifier (OID) having an incorrect value of "5" for the
-   "dod" component of the OID.  In the case of RFC 1964, use of the
-   "correct" OID value would result in a change in the wire protocol;
-   therefore, the RFC 1964 OID remains unchanged for now.
-
-3.2.  Top-Level Type
-
-   The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
-   Data Units or PDUs) which an application may directly reference.
-   Applications SHOULD NOT transmit any types other than those which are
-   alternatives of the KRB-PDU CHOICE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 12]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- top-level type
-      --
-      -- Applications should not directly reference any types
-      -- other than KRB-PDU and its component types.
-      --
-      KRB-PDU         ::= CHOICE {
-          ticket      Ticket,
-          as-req      AS-REQ,
-          as-rep      AS-REP,
-          tgs-req     TGS-REQ,
-          tgs-rep     TGS-REP,
-          ap-req      AP-REQ,
-          ap-rep      AP-REP,
-          krb-safe    KRB-SAFE,
-          krb-priv    KRB-PRIV,
-          krb-cred    KRB-CRED,
-          tgt-req     TGT-REQ,
-          krb-error   KRB-ERROR,
-          ...
-      }
-
-
-3.3.  Previously Unused ASN.1 Notation (informative)
-
-   Some aspects of ASN.1 notation used in this document were not used in
-   [KCLAR], and may be unfamiliar to some readers.  This subsection is
-   informative; for normative definitions of the notation, see the
-   actual ASN.1 specifications [X680], [X682], [X683].
-
-3.3.1.  Parameterized Types
-
-   This document uses ASN.1 parameterized types [X683] to make
-   definitions of types more readable.  For some types, some or all of
-   the parameters are advisory, i.e., they are not encoded in any form
-   for transmission in a protocol message.  These advisory parameters
-   can describe implementation behavior associated with the type.
-
-3.3.2.  Constraints
-
-   This document uses ASN.1 constraints, including the
-   "UserDefinedConstraint" notation [X682].  Some constraints can be
-   handled automatically by tools that can parse them.  Uses of the
-   "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will
-   typically need to have behavior manually coded; the notation provides
-   a formalized way of conveying intended implementation behavior.
-
-   The "WITH COMPONENTS" constraint notation allows constraints to apply
-   to component types of a SEQUENCE type.  This constraint notation
-   effectively allows constraints to "reach into" a type to constrain
-   its component types.
-
-
-Yu                         Expires: Apr 2007                   [Page 13]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-3.4.  New Types
-
-   This document defines a number of ASN.1 types which are new since
-   [KCLAR].  The names of these types will typically have a suffix like
-   "Ext", indicating that the types are intended to support
-   extensibility.  Types original to RFC 1510 and [KCLAR] have been
-   renamed to have a suffix like "1510".  The "Ext" and "1510" types
-   often contain a number of common elements, but differ primarily in
-   the way strings are encoded.
-
-4.  Basic Types
-
-   These "basic" Kerberos ASN.1 types appear in multiple other Kerberos
-   types.
-
-4.1.  Constrained Integer Types
-
-   In RFC 1510, many types contained references to the unconstrained
-   INTEGER type.  Since an unconstrained INTEGER can contain almost any
-   possible abstract integer value, most of the unconstrained references
-   to INTEGER in RFC 1510 were constrained to 32 bits or smaller in
-   [KCLAR].
-
-      -- signed values representable in 32 bits
-      --
-      -- These are often used as assigned numbers for various things.
-      Int32           ::= INTEGER (-2147483648..2147483647)
-
-   The "Int32" type often contains an assigned number identifying the
-   contents of a typed hole.  Unless otherwise stated, non-negative
-   values are registered, and negative values are available for local
-   use.
-
-      -- unsigned 32 bit values
-      UInt32          ::= INTEGER (0..4294967295)
-
-   The "UInt32" type is used in some places where an unsigned 32-bit
-   integer is needed.
-
-      -- unsigned 64 bit values
-      UInt64          ::= INTEGER (0..18446744073709551615)
-
-   The "UInt64" type is used in places where 32 bits of precision may
-   provide inadequate security.
-
-      -- sequence numbers
-      SeqNum          ::= UInt64
-
-   Sequence numbers were constrained to 32 bits in [KCLAR], but this
-   document allows for 64-bit sequence numbers.
-
-
-Yu                         Expires: Apr 2007                   [Page 14]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- nonces
-      Nonce           ::= UInt64
-
-   Likewise, nonces were constrained to 32 bits in [KCLAR], but expanded
-   to 64 bits here.
-
-      -- microseconds
-      Microseconds    ::= INTEGER (0..999999)
-
-   The "microseconds" type is intended to carry the microseconds part of
-   a time value.
-
-4.2.  KerberosTime
-
-      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
-                              -- MUST NOT include fractional seconds
-      })
-
-   The timestamps used in Kerberos are encoded as GeneralizedTimes.  A
-   KerberosTime value MUST NOT include any fractional portions of the
-   seconds.  As required by the DER, it further MUST NOT include any
-   separators, and it specifies the UTC time zone (Z).  Example: The
-   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
-   November 1985 is "19851106210627Z".
-
-4.3.  KerberosString
-
-      -- used for names and for error messages
-      KerberosString  ::= CHOICE {
-          ia5         GeneralString (IA5String),
-          utf8        UTF8String,
-          ...         -- no extension may be sent
-                      -- to an rfc1510 implementation --
-      }
-
-   The KerberosString type is used for character strings in various
-   places in the Kerberos protocol.  For compatibility with RFC 1510,
-   GeneralString values constrained to IA5String (US-ASCII) are
-   permitted in messages exchanged with RFC 1510 implementations.  The
-   new protocol messages contain strings encoded as UTF-8, and these
-   strings MUST be normalized using [SASLPREP].  KerberosString values
-   are present in principal names and in error messages.  Control
-   characters SHOULD NOT be used in principal names, and used with
-   caution in error messages.
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 15]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- IA5 choice only; useful for constraints
-      KerberosStringIA5       ::= KerberosString
-          (WITH COMPONENTS { ia5 PRESENT })
-
-      -- IA5 excluded; useful for constraints
-      KerberosStringExt       ::= KerberosString
-          (WITH COMPONENTS { ia5 ABSENT })
-
-   KerberosStringIA5 requires the use of the "ia5" alternative, while
-   KerberosStringExt forbids it.  These types appear in ASN.1
-   constraints on messages.
-
-   For detailed background regarding the history of character string use
-   in Kerberos, as well as discussion of some compatibility issues, see
-   Appendix B.
-
-4.4.  Language Tags
-
-      -- used for language tags
-      LangTag ::= PrintableString
-          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
-
-   The "LangTag" type is used to specify language tags for localization
-   purposes, using the [RFC3066] format.
-
-4.5.  KerberosFlags
-
-   For several message types, a specific constrained bit string type,
-   KerberosFlags, is used.
-
-      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
-          (CONSTRAINED BY {
-          -- MUST be a valid value of -- NamedBits
-          -- but if the value to be sent would be truncated to shorter
-          -- than 32 bits according to DER, the value MUST be padded
-          -- with trailing zero bits to 32 bits.  Otherwise, no
-          -- trailing zero bits may be present.
-
-      })
-
-
-   The actual bit string type encoded in Kerberos messages does not use
-   named bits.  The advisory parameter of the KerberosFlags type names a
-   bit string type defined using named bits, whose value is encoded as
-   if it were a bit string with unnamed bits.  This practice is
-   necessary because the DER require trailing zero bits to be removed
-   when encoding bit strings defined using named bits.  Existing
-   implementations of Kerberos send exactly 32 bits rather than
-   truncating, so the size constraint requires the transmission of at
-   least 32 bits.  Trailing zero bits beyond the first 32 bits are
-   truncated.
-
-Yu                         Expires: Apr 2007                   [Page 16]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-4.6.  Typed Holes
-
-      -- Typed hole identifiers
-      TH-id           ::= CHOICE {
-          int32               Int32,
-          rel-oid             RELATIVE-OID
-      }
-
-   The "TH-id" type is a generalized means to identify the contents of a
-   typed hole.  The "int32" alternative may be used for simple integer
-   assignments, in the same manner as "Int32", while the "rel-oid"
-   alternative may be used for hierarchical delegation.
-
-4.7.  HostAddress and HostAddresses
-
-      AddrType        ::= Int32
-
-      HostAddress     ::= SEQUENCE  {
-          addr-type   [0] AddrType,
-          address     [1] OCTET STRING
-      }
-
-      -- NOTE: HostAddresses is always used as an OPTIONAL field and
-      -- should not be a zero-length SEQUENCE OF.
-      --
-      -- The extensible messages explicitly constrain this to be
-      -- non-empty.
-      HostAddresses   ::= SEQUENCE OF HostAddress
-
-
-   addr-type
-        This field specifies the type of address that follows.
-
-   address
-        This field encodes a single address of the type identified by
-        "addr-type".
-
-   All negative values for the host address type are reserved for local
-   use.  All non-negative values are reserved for officially assigned
-   type fields and interpretations.
-
-
-      addr-type |     meaning
-      __________|______________
-              2 |   IPv4
-              3 |   directional
-             12 |   DECnet
-             20 |   NetBIOS
-             24 |   IPv6
-
-
-
-Yu                         Expires: Apr 2007                   [Page 17]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-4.7.1.  Internet (IPv4) Addresses
-
-   Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
-   MSB order (most significant byte first). The IPv4 loopback address
-   SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is
-   two (2).
-
-4.7.2.  Internet (IPv6) Addresses
-
-   IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, encoded
-   in MSB order (most significant byte first). The type of IPv6
-   addresses is twenty-four (24). The following addresses MUST NOT
-   appear in any Kerberos PDU:
-
-      * the Unspecified Address
-
-      * the Loopback Address
-
-      * Link-Local addresses
-
-   This restriction applies to the inclusion in the address fields of
-   Kerberos PDUs, but not to the address fields of packets that might
-   carry such PDUs.  The restriction is necessary because the use of an
-   address with non-global scope could allow the acceptance of a message
-   sent from a node that may have the same address, but which is not the
-   host intended by the entity that added the restriction.  If the
-   link-local address type needs to be used for communication, then the
-   address restriction in tickets must not be used (i.e. addressless
-   tickets must be used).
-
-   IPv4-mapped IPv6 addresses MUST be represented as addresses of type
-   2.
-
-4.7.3.  DECnet Phase IV addresses
-
-   DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order.
-   The type of DECnet Phase IV addresses is twelve (12).
-
-4.7.4.  Netbios addresses
-
-   Netbios addresses are 16-octet addresses typically composed of 1 to
-   15 alphanumeric characters and padded with the US-ASCII SPC character
-   (code 32).  The 16th octet MUST be the US-ASCII NUL character (code
-   0).  The type of Netbios addresses is twenty (20).
-
-4.7.5.  Directional Addresses
-
-   In many environments, including the sender address in KRB-SAFE and
-   KRB-PRIV messages is undesirable because the addresses may be changed
-   in transport by network address translators. However, if these
-   addresses are removed, the messages may be subject to a reflection
-
-Yu                         Expires: Apr 2007                   [Page 18]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   attack in which a message is reflected back to its originator. The
-   directional address type provides a way to avoid transport addresses
-   and reflection attacks.  Directional addresses are encoded as four
-   byte unsigned integers in network byte order.  If the message is
-   originated by the party sending the original AP-REQ message, then an
-   address of 0 SHOULD be used. If the message is originated by the
-   party to whom that AP-REQ was sent, then the address 1 SHOULD be
-   used.  Applications involving multiple parties can specify the use of
-   other addresses.
-
-   Directional addresses MUST only be used for the sender address field
-   in the KRB-SAFE or KRB-PRIV messages.  They MUST NOT be used as a
-   ticket address or in a AP-REQ message.  This address type SHOULD only
-   be used in situations where the sending party knows that the
-   receiving party supports the address type.  This generally means that
-   directional addresses may only be used when the application protocol
-   requires their support.  Directional addresses are type (3).
-
-5.  Principals
-
-   Principals are participants in the Kerberos protocol.  A "realm"
-   consists of principals in one administrative domain, served by one
-   KDC (or one replicated set of KDCs).  Each principal name has an
-   arbitrary number of components, though typical principal names will
-   only have one or two components.  A principal name is meant to be
-   readable by and meaningful to humans, especially in a realm lacking a
-   centrally adminstered authorization infrastructure.
-
-5.1.  Name Types
-
-   Each PrincipalName has NameType indicating what sort of name it is.
-   The name-type SHOULD be treated as a hint.  Ignoring the name type,
-   no two names can be the same (i.e., at least one of the components,
-   or the realm, must be different).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 19]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- assigned numbers for name types (used in principal names)
-      NameType        ::= Int32
-
-      -- Name type not known
-      nt-unknown              NameType ::= 0
-      -- Just the name of the principal as in DCE, or for users
-      nt-principal            NameType ::= 1
-      -- Service and other unique instance (krbtgt)
-      nt-srv-inst             NameType ::= 2
-      -- Service with host name as instance (telnet, rcommands)
-      nt-srv-hst              NameType ::= 3
-      -- Service with host as remaining components
-      nt-srv-xhst             NameType ::= 4
-      -- Unique ID
-      nt-uid                  NameType ::= 5
-      -- Encoded X.509 Distingished name [RFC 2253]
-      nt-x500-principal       NameType ::= 6
-      -- Name in form of SMTP email name (e.g. user@foo.com)
-      nt-smtp-name            NameType ::= 7
-      -- Enterprise name - may be mapped to principal name
-      nt-enterprise           NameType ::= 10
-
-
-5.2.  Principal Type Definition
-
-   The "PrincipalName" type takes a parameter to constrain which string
-   type it contains.
-
-      PrincipalName { StrType }       ::= SEQUENCE {
-          name-type   [0] NameType,
-          -- May have zero elements, or individual elements may be
-          -- zero-length, but this is NOT RECOMMENDED.
-          name-string [1] SEQUENCE OF KerberosString (StrType)
-      }
-
-
-   The constrained types have their own names.
-
-      -- IA5 only
-      PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 }
-      -- IA5 excluded
-      PrincipalNameExt ::= PrincipalName { KerberosStringExt }
-      -- Either one?
-      PrincipalNameEither ::= PrincipalName { KerberosString }
-
-
-   name-type
-        hint of the type of name that follows
-
-   name-string
-        The "name-string" encodes a sequence of components that form a
-
-Yu                         Expires: Apr 2007                   [Page 20]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-        name, each component encoded as a KerberosString.  Taken
-        together, a PrincipalName and a Realm form a principal
-        identifier.  Most PrincipalNames will have only a few components
-        (typically one or two).
-
-5.3.  Principal Name Reuse
-
-   Realm administrators SHOULD use extreme caution when considering
-   reusing a principal name.  A service administrator might explicitly
-   enter principal names into a local access control list (ACL) for the
-   service.  If such local ACLs exist independently of a centrally
-   administered authorization infrastructure, realm administrators
-   SHOULD NOT reuse principal names until confirming that all extant ACL
-   entries referencing that principal name have been updated.  Failure
-   to perform this check can result in a security vulnerability, as a
-   new principal can inadvertently inherit unauthorized privileges upon
-   receiving a reused principal name.  An organization whose Kerberos-
-   authenticated services all use a centrally-adminstered authorization
-   infrastructure may not need to take these precautions regarding
-   principal name reuse.
-
-5.4.  Best Common Practice Recommendations for the Processing of
-   Principal Names Consisting of Internationalized Domain Names:
-
-   Kerberos principals are often created for the purpose of
-   authenticating a service located on a machine identified by an domain
-   name.  Unfortunately, once a principal name is created it is
-   impossible to know the source from which the resulting KerberosString
-   was derived.  It is therefore required that principal names
-   containing internationalized domain names be processed via the
-   following procedure:
-
-   *  ensure that the IDN component must be a valid domain name as per
-      the rules of IDNA [RFC3490]
-
-   *  separate the IDN component into labels separated by any of the
-      Full Stop characters
-
-   *  fold all Full Stop characters to Full Stop (0x002E)
-
-   *  for each label (perform all steps):
-
-      o  if the label begins with an ACE prefix as registered with IANA,
-         the prefix will be removed and the rest of the label will be
-         converted from the ACE representation to Unicode [need
-         reference]
-
-      o  if the label consists of one or more internationalized
-         characters separately apply the NamePrep and then the SASLprep
-         string preparation methods.
-
-
-Yu                         Expires: Apr 2007                   [Page 21]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      o  if the label consists of zero internalizationalized characters,
-         the label is to be lower-cased
-
-      o  if the output of the two methods match, continue on to the next
-         label; otherwise reject the principal name as invalid
-
-   *  the result of a valid principal name component derived from an IDN
-      is the joining of the individual string prepared labels separated
-      by the Full Stop (0x002E)
-
-5.5.  Realm Names
-
-         Realm { StrType }       ::= KerberosString (StrType)
-
-         -- IA5 only
-         RealmIA5                ::= Realm { KerberosStringIA5 }
-
-         -- IA5 excluded
-         RealmExt                ::= Realm { KerberosStringExt }
-
-         -- Either
-         RealmEither             ::= Realm { KerberosString }
-
-
-
-   Kerberos realm names are KerberosStrings.  Realms MUST NOT contain a
-   character with the code 0 (the US-ASCII NUL).  Most realms will
-   usually consist of several components separated by periods (.), in
-   the style of Internet Domain Names, or separated by slashes (/) in
-   the style of X.500 names.
-
-5.6.  Best Common Practice Recommendations for the Processing of
-   Internationalized Domain-Style Realm Names:
-
-   Domain Style Realm names are defined as all realm names whose
-   components are separated by Full Stop (0x002E) (aka periods, '.') and
-   contain neither colons, name containing one or more internationalized
-   characters (not included in US-ASCII), this procedure must be used:
-
-   *  the realm name must be a valid domain name as per the rules of
-      IDNA [RFC3490]
-
-   *  the following string preparation routine must be followed:
-
-      -  separate the string into components separated by any of the
-         Full Stop characters
-
-      -  fold all Full Stop characters to Full Stop (0x002E)
-
-      -  for each component (perform all steps):
-
-
-Yu                         Expires: Apr 2007                   [Page 22]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-         o  if the component begins with an ACE prefix as registered
-            with IANA, the prefix will be removed and the rest of the
-            component will be converted from the ACE representation to
-            Unicode [need reference]
-
-         o  if the component consists of one or more internationalized
-            characters separately apply the NamePrep and SASLprep string
-            preparation methods.
-
-            if the output of the two methods match, continue on to the
-            next component; otherwise reject the realm name as invalid
-
-      -  the result of a valid realm name is the joining of the
-         individual string prepared components separated by the Full
-         Stop (0x002E)
-
-   In [KCLAR], the recommendation is that all domain style realm names
-   be represented in uppercase.  This recommendation is modified in the
-   following manner.  All components of domain style realm names not
-   including internationalized characters should be upper-cased.  All
-   components of domain style realm names including internationalized
-   characters must be lower-cased.  (The lower case representation of
-   internationalized components is enforced by the requirement that the
-   output of NamePrep and StringPrep string preparation must be
-   equivalent.)
-
-5.7.  Printable Representations of Principal Names
-
-   [ perhaps non-normative? ]
-
-   The printable form of a principal name consists of the concatenation
-   of components of the PrincipalName value using the slash character
-   (/), followed by an at-sign (@), followed by the realm name.  Any
-   occurrence of a backslash (\), slash (/) or at-sign (@) in the
-   PrincipalName value is quoted by a backslash.
-
-5.8.  Ticket-Granting Service Principal
-
-   The PrincipalName value corresponding to a ticket-granting service
-   has two components: the first component is the string "krbtgt", and
-   the second component is the realm name of the TGS which will accept a
-   ticket-granting ticket having this service principal name.  The realm
-   name of service always indicates which realm issued the ticket.  A
-   ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
-   obtaining tickets in the same realm would have the following ASN.1
-   values for its "realm" and "sname" components, respectively:
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 23]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- Example Realm and PrincipalName for a TGS
-
-      tgtRealm1       Realm ::= ia5 : "A.EXAMPLE.COM"
-
-      tgtPrinc1       PrincipalName ::= {
-          name-type nt-srv-inst,
-          name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
-      }
-
-   Its printable representation would be written as
-   "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
-
-5.8.1.  Cross-Realm TGS Principals
-
-   It is possible for a principal in one realm to authenticate to a
-   service in another realm.  A KDC can issue a cross-realm ticket-
-   granting ticket to allow one of its principals to authenticate to a
-   service in a foreign realm.  For example, the TGS principal
-   "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
-   client principal in the realm A.EXAMPLE.COM to authenticate to a
-   service in the realm B.EXAMPLE.COM.  When the KDC for B.EXAMPLE.COM
-   issues a ticket to a client originating in A.EXAMPLE.COM, the
-   client's realm name remains "A.EXAMPLE.COM", even though the service
-   principal will have the realm "B.EXAMPLE.COM".
-
-6.  Types Relating to Encryption
-
-   Many Kerberos protocol messages contain encrypted encodings of
-   various data types.  Some Kerberos protocol messages also contain
-   checksums (signatures) of encodings of various types.
-
-6.1.  Assigned Numbers for Encryption
-
-   Encryption algorithm identifiers and key usages both have assigned
-   numbers, described in [KCRYPTO].
-
-6.1.1.  EType
-
-   EType is the integer type for assigned numbers for encryption
-   algorithms.  Defined in [KCRYPTO].
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 24]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- Assigned numbers denoting encryption mechanisms.
-      EType ::= Int32
-
-      -- assigned numbers for encryption schemes
-      et-des-cbc-crc                  EType ::= 1
-      et-des-cbc-md4                  EType ::= 2
-      et-des-cbc-md5                  EType ::= 3
-      --     [reserved]                         4
-      et-des3-cbc-md5                 EType ::= 5
-      --     [reserved]                         6
-      et-des3-cbc-sha1                EType ::= 7
-      et-dsaWithSHA1-CmsOID           EType ::= 9
-      et-md5WithRSAEncryption-CmsOID  EType ::= 10
-      et-sha1WithRSAEncryption-CmsOID EType ::= 11
-      et-rc2CBC-EnvOID                EType ::= 12
-      et-rsaEncryption-EnvOID         EType ::= 13
-      et-rsaES-OAEP-ENV-OID           EType ::= 14
-      et-des-ede3-cbc-Env-OID         EType ::= 15
-      et-des3-cbc-sha1-kd             EType ::= 16
-      -- AES
-      et-aes128-cts-hmac-sha1-96      EType ::= 17
-      -- AES
-      et-aes256-cts-hmac-sha1-96      EType ::= 18
-      -- Microsoft
-      et-rc4-hmac                     EType ::= 23
-      -- Microsoft
-      et-rc4-hmac-exp                 EType ::= 24
-      -- opaque; PacketCable
-      et-subkey-keymaterial           EType ::= 65
-
-
-6.1.2.  Key Usages
-
-   KeyUsage is the integer type for assigned numbers for key usages.
-   Key usage values are inputs to the encryption and decryption
-   functions described in [KCRYPTO].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 25]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- Assigned numbers denoting key usages.
-      KeyUsage ::= UInt32
-
-      --
-      -- Actual identifier names are provisional and subject to
-      -- change.
-      --
-      ku-pa-enc-ts                    KeyUsage ::= 1
-      ku-Ticket                       KeyUsage ::= 2
-      ku-EncASRepPart                 KeyUsage ::= 3
-      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
-      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
-      ku-pa-TGSReq-cksum              KeyUsage ::= 6
-      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
-      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
-      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
-      ku-Authenticator-cksum          KeyUsage ::= 10
-      ku-APReq-authenticator          KeyUsage ::= 11
-      ku-EncAPRepPart                 KeyUsage ::= 12
-      ku-EncKrbPrivPart               KeyUsage ::= 13
-      ku-EncKrbCredPart               KeyUsage ::= 14
-      ku-KrbSafe-cksum                KeyUsage ::= 15
-      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
-
-
-      -- The following numbers are provisional...
-      -- conflicts may exist elsewhere.
-      ku-Ticket-cksum                 KeyUsage ::= 29
-      ku-ASReq-cksum                  KeyUsage ::= 30
-      ku-TGSReq-cksum                 KeyUsage ::= 31
-      ku-ASRep-cksum                  KeyUsage ::= 32
-      ku-TGSRep-cksum                 KeyUsage ::= 33
-      ku-APReq-cksum                  KeyUsage ::= 34
-      ku-APRep-cksum                  KeyUsage ::= 35
-      ku-KrbCred-cksum                KeyUsage ::= 36
-      ku-KrbError-cksum               KeyUsage ::= 37
-      ku-KDCRep-cksum                 KeyUsage ::= 38
-
-      ku-kg-acceptor-seal             KeyUsage ::= 22
-      ku-kg-acceptor-sign             KeyUsage ::= 23
-      ku-kg-intiator-seal             KeyUsage ::= 24
-      ku-kg-intiator-sign             KeyUsage ::= 25
-
-      -- KeyUsage values 25..27 used by hardware preauth?
-
-      -- for KINK
-      ku-kink-encrypt                 KeyUsage ::= 39
-      ku-kink-cksum                   KeyUsage ::= 40
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 26]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-6.2.  Which Key to Use
-
-      -- KeyToUse identifies which key is to be used to encrypt or
-      -- sign a given value.
-      --
-      -- Values of KeyToUse are never actually transmitted over the
-      -- wire, or even used directly by the implementation in any
-      -- way, as key usages are; it exists primarily to identify
-      -- which key gets used for what purpose.  Thus, the specific
-      -- numeric values associated with this type are irrelevant.
-      KeyToUse        ::= ENUMERATED {
-          -- unspecified
-          key-unspecified,
-          -- server long term key
-          key-server,
-          -- client long term key
-          key-client,
-          -- key selected by KDC for encryption of a KDC-REP
-          key-kdc-rep,
-          -- session key from ticket
-          key-session,
-          -- subsession key negotiated via AP-REQ/AP-REP
-          key-subsession,
-          ...
-      }
-
-
-6.3.  EncryptionKey
-
-   The "EncryptionKey" type holds an encryption key.
-
-      EncryptionKey   ::= SEQUENCE {
-          keytype     [0] EType,
-          keyvalue    [1] OCTET STRING
-      }
-
-
-   keytype
-        This "EType" identifies the encryption algorithm, described in
-        [KCRYPTO].
-
-   keyvalue
-        Contains the actual key.
-
-6.4.  EncryptedData
-
-   The "EncryptedData" type contains the encryption of another data
-   type.  The recipient uses fields within EncryptedData to determine
-   which key to use for decryption.
-
-
-
-Yu                         Expires: Apr 2007                   [Page 27]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-
-      -- "Type" specifies which ASN.1 type is encrypted to the
-      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
-      -- keys of which one key may be used to encrypt the data.
-      -- "KeyUsages" specifies a set of key usages, one of which may
-      -- be used to encrypt.
-      --
-      -- None of the parameters is transmitted over the wire.
-      EncryptedData {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          etype       [0] EType,
-          kvno        [1] UInt32 OPTIONAL,
-          cipher      [2] OCTET STRING (CONSTRAINED BY {
-              -- must be encryption of --
-              OCTET STRING (CONTAINING Type),
-              -- with one of the keys -- KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          }),
-          ...
-      }
-
-
-
-   KeyUsages
-        Advisory parameter indicating which key usage to use when
-        encrypting the ciphertext.  If "KeyUsages" indicate multiple
-        "KeyUsage" values, the detailed description of the containing
-        message will indicate which key to use under which conditions.
-
-   Type
-        Advisory parameter indicating the ASN.1 type whose DER encoding
-        is the plaintext encrypted into the EncryptedData.
-
-   Keys
-        Advisory parameter indicating which key to use to perform the
-        encryption.  If "Keys" indicate multiple "KeyToUse" values, the
-        detailed description of the containing message will indicate
-        which key to use under which conditions.
-
-   KeyUsages
-        Advisory parameter indicating which "KeyUsage" value is used to
-        encrypt.  If "KeyUsages" indicates multiple "KeyUsage" values,
-        the detailed description of the containing message will indicate
-        which key usage to use under which conditions.
-
-6.5.  Checksums
-
-   Several types contain checksums (actually signatures) of data.
-
-
-Yu                         Expires: Apr 2007                   [Page 28]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      CksumType       ::= Int32
-
-      -- The parameters specify which key to use to produce the
-      -- signature, as well as which key usage to use.  The
-      -- parameters are not actually sent over the wire.
-      Checksum {
-          KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksumtype   [0] CksumType,
-          checksum    [1] OCTET STRING (CONSTRAINED BY {
-              -- signed using one of the keys --
-              KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          })
-      }
-
-
-   CksumType
-        Integer type for assigned numbers for signature algorithms.
-        Defined in [KCRYPTO]
-
-   Keys
-        As in EncryptedData
-
-   KeyUsages
-        As in EncryptedData
-
-   cksumtype
-        Signature algorithm used to produce the signature.
-
-   checksum
-        The actual checksum.
-
-6.5.1.  ChecksumOf
-
-   ChecksumOf is similar to "Checksum", but specifies which type is
-   signed.
-
-      -- a Checksum that must contain the checksum
-      -- of a particular type
-      ChecksumOf {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
-          ...,
-          checksum (CONSTRAINED BY {
-              -- must be checksum of --
-              OCTET STRING (CONTAINING Type)
-          })
-      })
-
-
-Yu                         Expires: Apr 2007                   [Page 29]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   Type
-        Indicates the ASN.1 type whose DER encoding is signed.
-
-6.5.2.  Signed
-
-   Signed is similar to "ChecksumOf", but contains an actual instance of
-   the type being signed in addition to the signature.
-
-      -- parameterized type for wrapping authenticated plaintext
-      Signed {
-          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksum       [0] ChecksumOf {
-              InnerType, Keys, KeyUsages
-          } OPTIONAL,
-          inner       [1] InnerType,
-          ...
-      }
-
-
-7.  Tickets
-
-   [ A large number of items described here are duplicated in the
-   sections describing KDC-REQ processing.  Should find a way to avoid
-   this duplication. ]
-
-   A ticket binds a principal name to a session key.  The important
-   fields of a ticket are in the encrypted part.
-
-      -- Encrypted part of ticket
-      EncTicketPart   ::= CHOICE {
-          rfc1510     EncTicketPart1510,
-          ext         EncTicketPartExt
-      }
-
-
-      EncTicketPart1510       ::= [APPLICATION 3] SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] RealmIA5,
-          cname               [3] PrincipalNameIA5,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL
-      }
-
-
-
-Yu                         Expires: Apr 2007                   [Page 30]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      EncTicketPartExt        ::= [APPLICATION 5] SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] RealmExt,
-          cname               [3] PrincipalNameExt,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...,
-      }
-
-
-   crealm
-        This field contains the client's realm.
-
-   cname
-        This field contains the client's name.
-
-   caddr
-        This field lists the network addresses (if absent, all addresses
-        are permitted) from which the ticket is valid.
-
-   Descriptions of the other fields appear in the following sections.
-
-7.1.  Timestamps
-
-   Three of the ticket timestamps may be requested from the KDC.  The
-   timestamps may differ from those requested, depending on site policy.
-
-   authtime
-        The time at which the client authenticated, as recorded by the
-        KDC.
-
-   starttime
-        The earliest time when the ticket is valid.  If not present, the
-        ticket is valid starting at the authtime.  This is requested as
-        the "from" field of KDC-REQ-BODY.
-
-   endtime
-        This time is requested in the "till" field of KDC-REQ-BODY.
-        Contains the time after which the ticket will not be honored
-        (its expiration time).  Note that individual services MAY place
-        their own limits on the life of a ticket and MAY reject tickets
-        which have not yet expired.  As such, this is really an upper
-        bound on the expiration time for the ticket.
-
-
-
-Yu                         Expires: Apr 2007                   [Page 31]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   renew-till
-        This time is requested in the "rtime" field of KDC-REQ-BODY.  It
-        is only present in tickets that have the "renewable" flag set in
-        the flags field.  It indicates the maximum endtime that may be
-        included in a renewal.  It can be thought of as the absolute
-        expiration time for the ticket, including all renewals.
-
-7.2.  Ticket Flags
-
-   A number of flags may be set in the ticket, further defining some of
-   its capabilities.  Some of these flags map to flags in a KDC request.
-
-      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
-
-      TicketFlagsBits ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          may-postdate        (5),
-          postdated           (6),
-          invalid             (7),
-          renewable           (8),
-          initial             (9),
-          pre-authent         (10),
-          hw-authent          (11),
-          transited-policy-checked (12),
-          ok-as-delegate      (13),
-          anonymous           (14),
-          cksummed-ticket     (15)
-      }
-
-
-7.2.1.  Flags Relating to Initial Ticket Acquisition
-
-   [ adapted KCLAR 2.1. ]
-
-   Several flags indicate the details of how the initial ticket was
-   acquired.
-
-   initial
-        The "initial" flag indicates that a ticket was issued using the
-        AS protocol, rather than issued based on a ticket-granting
-        ticket.  Application servers (e.g., a password-changing program)
-        requiring a client's definite knowledge of its secret key can
-        insist that this flag be set in any tickets they accept, thus
-        being assured that the client's key was recently presented to
-        the application client.
-
-
-
-Yu                         Expires: Apr 2007                   [Page 32]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   pre-authent
-        The "pre-authent" flag indicates that some sort of pre-
-        authentication was used during the AS exchange.
-
-   hw-authent
-        The "hw-authent" flag indicates that some sort of hardware-based
-        pre-authentication occurred during the AS exchange.
-
-   Both the "pre-authent" and the "hw-authent" flags may be present with
-   or without the "initial" flag; such tickets with the "initial" flag
-   clear are ones which are derived from initial tickets with the "pre-
-   authent" or "hw-authent" flags set.
-
-7.2.2.  Invalid Tickets
-
-   [ KCLAR 2.2. ]
-
-   The "invalid" flag indicates that a ticket is invalid.  Application
-   servers MUST reject tickets which have this flag set.  A postdated
-   ticket will be issued in this form.  Invalid tickets MUST be
-   validated by the KDC before use, by presenting them to the KDC in a
-   TGS request with the "validate" option specified.  The KDC will only
-   validate tickets after their starttime has passed.  The validation is
-   required so that postdated tickets which have been stolen before
-   their starttime can be rendered permanently invalid (through a hot-
-   list mechanism -- see Section 8.3.2.4).
-
-7.2.3.  OK as Delegate
-
-   [ KCLAR 2.8. ]
-
-   The "ok-as-delegate" flag provides a way for a KDC to communicate
-   local realm policy to a client regarding whether the service for
-   which the ticket is issued is trusted to accept delegated
-   credentials.  For some applications, a client may need to delegate
-   credentials to a service to act on its behalf in contacting other
-   services.  The ability of a client to obtain a service ticket for a
-   service conveys no information to the client about whether the
-   service should be trusted to accept delegated credentials.
-
-   The copy of the ticket flags visible to the client may have the "ok-
-   as-delegate" flag set to indicate to the client that the service
-   specified in the ticket has been determined by policy of the realm to
-   be a suitable recipient of delegation.  A client can use the presence
-   of this flag to help it make a decision whether to delegate
-   credentials (either grant a proxy or a forwarded ticket-granting
-   ticket) to this service.  It is acceptable to ignore the value of
-   this flag.  When setting this flag, an administrator should consider
-   the security and placement of the server on which the service will
-   run, as well as whether the service requires the use of delegated
-   credentials.
-
-Yu                         Expires: Apr 2007                   [Page 33]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-7.2.4.  Renewable Tickets
-
-   [ adapted KCLAR 2.3. ]
-
-   The "renewable" flag indicates whether the ticket may be renewed.
-
-   Renewable tickets can be used to mitigate the consequences of ticket
-   theft.  Applications may desire to hold credentials which can be
-   valid for long periods of time.  However, this can expose the
-   credentials to potential theft for equally long periods, and those
-   stolen credentials would be valid until the expiration time of the
-   ticket(s).  Simply using short-lived tickets and obtaining new ones
-   periodically would require the application to have long-term access
-   to the client's secret key, which is an even greater risk.
-
-   Renewable tickets have two "expiration times": the first is when the
-   current instance of the ticket expires, and the second is the latest
-   permissible value for an individual expiration time.  An application
-   client must periodically present an unexpired renewable ticket to the
-   KDC, setting the "renew" option in the KDC request.  The KDC will
-   issue a new ticket with a new session key and a later expiration
-   time.  All other fields of the ticket are left unmodified by the
-   renewal process.  When the latest permissible expiration time
-   arrives, the ticket expires permanently.  At each renewal, the KDC
-   MAY consult a hot-list to determine if the ticket had been reported
-   stolen since its last renewal; it will refuse to renew such stolen
-   tickets, and thus the usable lifetime of stolen tickets is reduced.
-
-   The "renewable" flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can usually be ignored by application
-   servers.  However, some particularly careful application servers MAY
-   disallow renewable tickets.
-
-   If a renewable ticket is not renewed by its expiration time, the KDC
-   will not renew the ticket.  The "renewable" flag is clear by default,
-   but a client can request it be set by setting the "renewable" option
-   in the AS-REQ message.  If it is set, then the "renew-till" field in
-   the ticket contains the time after which the ticket may not be
-   renewed.
-
-7.2.5.  Postdated Tickets
-
-   postdated
-        indicates a ticket which has been postdated
-
-   may-postdate
-        indicates that postdated tickets may be issued based on this
-        ticket
-
-   [ KCLAR 2.4. ]
-
-
-Yu                         Expires: Apr 2007                   [Page 34]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   Applications may occasionally need to obtain tickets for use much
-   later, e.g., a batch submission system would need tickets to be valid
-   at the time the batch job is serviced.  However, it is dangerous to
-   hold valid tickets in a batch queue, since they will be on-line
-   longer and more prone to theft.  Postdated tickets provide a way to
-   obtain these tickets from the KDC at job submission time, but to
-   leave them "dormant" until they are activated and validated by a
-   further request of the KDC.  If a ticket theft were reported in the
-   interim, the KDC would refuse to validate the ticket, and the thief
-   would be foiled.
-
-   The "may-postdate" flag in a ticket is normally only interpreted by
-   the TGS.  It can be ignored by application servers.  This flag MUST
-   be set in a ticket-granting ticket in order for the KDC to issue a
-   postdated ticket based on the presented ticket.  It is reset by
-   default; it MAY be requested by a client by setting the "allow-
-   postdate" option in the AS-REQ [?also TGS-REQ?] message.  This flag
-   does not allow a client to obtain a postdated ticket-granting ticket;
-   postdated ticket-granting tickets can only by obtained by requesting
-   the postdating in the AS-REQ message.  The life (endtime minus
-   starttime) of a postdated ticket will be the remaining life of the
-   ticket-granting ticket at the time of the request, unless the
-   "renewable" option is also set, in which case it can be the full life
-   (endtime minus starttime) of the ticket-granting ticket.  The KDC MAY
-   limit how far in the future a ticket may be postdated.
-
-   The "postdated" flag indicates that a ticket has been postdated.  The
-   application server can check the authtime field in the ticket to see
-   when the original authentication occurred.  Some services MAY choose
-   to reject postdated tickets, or they may only accept them within a
-   certain period after the original authentication.  When the KDC
-   issues a "postdated" ticket, it will also be marked as "invalid", so
-   that the application client MUST present the ticket to the KDC for
-   validation before use.
-
-7.2.6.  Proxiable and Proxy Tickets
-
-   proxy
-        indicates a proxy ticket
-
-   proxiable
-        indicates that proxy tickets may be issued based on this ticket
-
-   [ KCLAR 2.5. ]
-
-   It may be necessary for a principal to allow a service to perform an
-   operation on its behalf.  The service must be able to take on the
-   identity of the client, but only for a particular purpose.  A
-   principal can allow a service to take on the principal's identity for
-   a particular purpose by granting it a proxy.
-
-
-Yu                         Expires: Apr 2007                   [Page 35]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   The process of granting a proxy using the "proxy" and "proxiable"
-   flags is used to provide credentials for use with specific services.
-   Though conceptually also a proxy, users wishing to delegate their
-   identity in a form usable for all purposes MUST use the ticket
-   forwarding mechanism described in the next section to forward a
-   ticket-granting ticket.
-
-   The "proxiable" flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can be ignored by application servers.
-   When set, this flag tells the ticket-granting server that it is OK to
-   issue a new ticket (but not a ticket-granting ticket) with a
-   different network address based on this ticket.  This flag is set if
-   requested by the client on initial authentication.  By default, the
-   client will request that it be set when requesting a ticket-granting
-   ticket, and reset when requesting any other ticket.
-
-   This flag allows a client to pass a proxy to a server to perform a
-   remote request on its behalf (e.g. a print service client can give
-   the print server a proxy to access the client's files on a particular
-   file server in order to satisfy a print request).
-
-   In order to complicate the use of stolen credentials, Kerberos
-   tickets may contain a set of network addresses from which they are
-   valid.  When granting a proxy, the client MUST specify the new
-   network address from which the proxy is to be used, or indicate that
-   the proxy is to be issued for use from any address.
-
-   The "proxy" flag is set in a ticket by the TGS when it issues a proxy
-   ticket.  Application servers MAY check this flag and at their option
-   they MAY require additional authentication from the agent presenting
-   the proxy in order to provide an audit trail.
-
-7.2.7.  Forwarded and Forwardable Tickets
-
-   forwarded
-        indicates a forwarded ticket
-
-   forwardable
-        indicates that forwarded tickets may be issued based on this
-        ticket
-
-   [ KCLAR 2.6. ]
-
-   Authentication forwarding is an instance of a proxy where the service
-   that is granted is complete use of the client's identity.  An example
-   where it might be used is when a user logs in to a remote system and
-   wants authentication to work from that system as if the login were
-   local.
-
-   The "forwardable" flag in a ticket is normally only interpreted by
-   the ticket-granting service.  It can be ignored by application
-
-Yu                         Expires: Apr 2007                   [Page 36]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   servers.  The "forwardable" flag has an interpretation similar to
-   that of the "proxiable" flag, except ticket-granting tickets may also
-   be issued with different network addresses.  This flag is reset by
-   default, but users MAY request that it be set by setting the
-   "forwardable" option in the AS request when they request their
-   initial ticket-granting ticket.
-
-   This flag allows for authentication forwarding without requiring the
-   user to enter a password again.  If the flag is not set, then
-   authentication forwarding is not permitted, but the same result can
-   still be achieved if the user engages in the AS exchange specifying
-   the requested network addresses and supplies a password.
-
-   The "forwarded" flag is set by the TGS when a client presents a
-   ticket with the "forwardable" flag set and requests a forwarded
-   ticket by specifying the "forwarded" KDC option and supplying a set
-   of addresses for the new ticket.  It is also set in all tickets
-   issued based on tickets with the "forwarded" flag set.  Application
-   servers may choose to process "forwarded" tickets differently than
-   non-forwarded tickets.
-
-   If addressless tickets are forwarded from one system to another,
-   clients SHOULD still use this option to obtain a new TGT in order to
-   have different session keys on the different systems.
-
-7.3.  Transited Realms
-
-   [ KCLAR 2.7., plus new stuff ]
-
-7.4.  Authorization Data
-
-   [ KCLAR 5.2.6. ]
-
-      ADType          ::= TH-id
-
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-          ad-type             [0] ADType,
-          ad-data             [1] OCTET STRING
-      }
-
-
-   ad-type
-        This field identifies the contents of the ad-data.  All negative
-        values are reserved for local use.  Non-negative values are
-        reserved for registered use.
-
-   ad-data
-        This field contains authorization data to be interpreted
-        according to the value of the corresponding ad-type field.
-
-
-
-Yu                         Expires: Apr 2007                   [Page 37]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   Each sequence of ADType and OCTET STRING is referred to as an
-   authorization element.  Elements MAY be application specific,
-   however, there is a common set of recursive elements that should be
-   understood by all implementations.  These elements contain other
-   AuthorizationData, and the interpretation of the encapsulating
-   element determines which enclosed elements must be interpreted, and
-   which may be ignored.
-
-   Depending on the meaning of the encapsulating element, the
-   encapsulated AuthorizationData may be ignored, interpreted as issued
-   directly by the KDC, or be stored in a separate plaintext part of the
-   ticket.  The types of the encapsulating elements are specified as
-   part of the Kerberos protocol because behavior based on these
-   container elements should be understood across implementations, while
-   other elements need only be understood by the applications which they
-   affect.
-
-   Authorization data elements are considered critical if present in a
-   ticket or authenticator.  Unless encapsulated in a known
-   authorization data element modifying the criticality of the elements
-   it contains, an application server MUST reject the authentication of
-   a client whose AP-REQ or ticket contains an unrecognized
-   authorization data element.  Authorization data is intended to
-   restrict the use of a ticket.  If the service cannot determine
-   whether it is the target of a restriction, a security weakness may
-   exist if the ticket can be used for that service.  Authorization
-   elements that are truly optional can be enclosed in AD-IF-RELEVANT
-   element.
-
-
-      ad-type |           contents of ad-data
-      ________|_______________________________________
-            1 |   DER encoding of AD-IF-RELEVANT
-            4 |   DER encoding of AD-KDCIssued
-            5 |   DER encoding of AD-AND-OR
-            8 |   DER encoding of AD-MANDATORY-FOR-KDC
-
-
-
-7.4.1.  AD-IF-RELEVANT
-
-      ad-if-relevant          ADType ::= int32 : 1
-
-      -- Encapsulates another AuthorizationData.
-      -- Intended for application servers; receiving application servers
-      -- MAY ignore.
-      AD-IF-RELEVANT          ::= AuthorizationData
-
-   AD elements encapsulated within the if-relevant element are intended
-   for interpretation only by application servers that understand the
-   particular ad-type of the embedded element. Application servers that
-
-Yu                         Expires: Apr 2007                   [Page 38]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   do not understand the type of an element embedded within the if-
-   relevant element MAY ignore the uninterpretable element. This element
-   promotes interoperability across implementations which may have local
-   extensions for authorization.  The ad-type for AD-IF-RELEVANT is (1).
-
-7.4.2.  AD-KDCIssued
-
-      -- KDC-issued privilege attributes
-      ad-kdcissued            ADType ::= int32 : 4
-
-      AD-KDCIssued            ::= SEQUENCE {
-          ad-checksum [0] ChecksumOf {
-                              AuthorizationData, { key-session },
-                              { ku-ad-KDCIssued-cksum }},
-          i-realm     [1] Realm OPTIONAL,
-          i-sname     [2] PrincipalName OPTIONAL,
-          elements    [3] AuthorizationData
-      }
-
-
-   ad-checksum
-        A cryptographic checksum computed over the DER encoding of the
-        AuthorizationData in the "elements" field, keyed with the
-        session key.  Its checksumtype is the mandatory checksum type
-        for the encryption type of the session key, and its key usage
-        value is 19.
-
-   i-realm, i-sname
-        The name of the issuing principal if different from the KDC
-        itself.  This field would be used when the KDC can verify the
-        authenticity of elements signed by the issuing principal and it
-        allows this KDC to notify the application server of the validity
-        of those elements.
-
-   elements
-        AuthorizationData issued by the KDC.
-
-   The KDC-issued ad-data field is intended to provide a means for
-   Kerberos credentials to embed within themselves privilege attributes
-   and other mechanisms for positive authorization, amplifying the
-   privileges of the principal beyond what it would have if using
-   credentials without such an authorization-data element.
-
-   This amplification of privileges cannot be provided without this
-   element because the definition of the authorization-data field allows
-   elements to be added at will by the bearer of a TGT at the time that
-   they request service tickets and elements may also be added to a
-   delegated ticket by inclusion in the authenticator.
-
-   For KDC-issued elements this is prevented because the elements are
-   signed by the KDC by including a checksum encrypted using the
-
-Yu                         Expires: Apr 2007                   [Page 39]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   server's key (the same key used to encrypt the ticket -- or a key
-   derived from that key).  AuthorizationData encapsulated with in the
-   AD-KDCIssued element MUST be ignored by the application server if
-   this "signature" is not present.  Further, AuthorizationData
-   encapsulated within this element from a ticket-granting ticket MAY be
-   interpreted by the KDC, and used as a basis according to policy for
-   including new signed elements within derivative tickets, but they
-   will not be copied to a derivative ticket directly.  If they are
-   copied directly to a derivative ticket by a KDC that is not aware of
-   this element, the signature will not be correct for the application
-   ticket elements, and the field will be ignored by the application
-   server.
-
-   This element and the elements it encapsulates MAY be safely ignored
-   by applications, application servers, and KDCs that do not implement
-   this element.
-
-   The ad-type for AD-KDC-ISSUED is (4).
-
-7.4.3.  AD-AND-OR
-
-      ad-and-or               ADType ::= int32 : 5
-
-      AD-AND-OR               ::= SEQUENCE {
-          condition-count     [0] Int32,
-          elements            [1] AuthorizationData
-      }
-
-
-   When restrictive AD elements are encapsulated within the and-or
-   element, the and-or element is considered satisfied if and only if at
-   least the number of encapsulated elements specified in condition-
-   count are satisfied.  Therefore, this element MAY be used to
-   implement an "or" operation by setting the condition-count field to
-   1, and it MAY specify an "and" operation by setting the condition
-   count to the number of embedded elements. Application servers that do
-   not implement this element MUST reject tickets that contain
-   authorization data elements of this type.
-
-   The ad-type for AD-AND-OR is (5).
-
-7.4.4.  AD-MANDATORY-FOR-KDC
-
-      -- KDCs MUST interpret any AuthorizationData wrapped in this.
-      ad-mandatory-for-kdc            ADType ::= int32 : 8
-      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
-
-   AD elements encapsulated within the mandatory-for-kdc element are to
-   be interpreted by the KDC.  KDCs that do not understand the type of
-   an element embedded within the mandatory-for-kdc element MUST reject
-   the request.
-
-Yu                         Expires: Apr 2007                   [Page 40]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   The ad-type for AD-MANDATORY-FOR-KDC is (8).
-
-7.5.  Encrypted Part of Ticket
-
-   The complete definition of the encrypted part is
-
-      -- Encrypted part of ticket
-      EncTicketPart   ::= CHOICE {
-          rfc1510     EncTicketPart1510,
-          ext         EncTicketPartExt
-      }
-
-
-   The encrypted part of the backwards-compatibility form of a ticket
-   is:
-
-      EncTicketPart1510       ::= [APPLICATION 3] SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] RealmIA5,
-          cname               [3] PrincipalNameIA5,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL
-      }
-
-   The encrypted part of the extensible form of a ticket is:
-
-      EncTicketPartExt        ::= [APPLICATION 5] SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] RealmExt,
-          cname               [3] PrincipalNameExt,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...,
-      }
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 41]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-7.6.  Cleartext Part of Ticket
-
-   The complete definition of Ticket is:
-
-      Ticket          ::= CHOICE {
-          rfc1510     Ticket1510,
-          ext         TicketExt
-      }
-
-
-   The "sname" field provides the name of the target service principal
-   in cleartext, as a hint to aid the server in choosing the correct
-   decryption key.
-
-   The backwards-compatibility form of Ticket is:
-
-      Ticket1510      ::= [APPLICATION 1] SEQUENCE {
-          tkt-vno     [0] INTEGER (5),
-          realm       [1] RealmIA5,
-          sname       [2] PrincipalNameIA5,
-          enc-part    [3] EncryptedData {
-              EncTicketPart1510, { key-server }, { ku-Ticket }
-          }
-      }
-
-   The extensible form of Ticket is:
-
-      TicketExt       ::= [APPLICATION 4] Signed {
-          [APPLICATION 4] SEQUENCE {
-              tkt-vno     [0] INTEGER (5),
-              realm       [1] RealmExt,
-              sname       [2] PrincipalNameExt,
-              enc-part    [3] EncryptedData {
-                  EncTicketPartExt, { key-server }, { ku-Ticket }
-              },
-              ...,
-              extensions          [4] TicketExtensions OPTIONAL,
-              ...
-          },
-          { key-ticket }, { ku-Ticket-cksum }
-      }
-
-
-   TicketExtensions, which may only be present in the extensible form of
-   Ticket, are a cleartext typed hole for extension use.
-   AuthorizationData already provides an encrypted typed hole.
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 42]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      TEType                  ::= TH-id
-
-      -- ticket extensions: for TicketExt only
-      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          te-type             [0] TEType,
-          te-data             [1] OCTET STRING
-      }
-
-
-   A client will only receive an extensible Ticket if the application
-   server supports extensibility.
-
-8.  Credential Acquisition
-
-   There are two exchanges that can be used for acquiring credentials:
-   the AS exchange and the TGS exchange.  These exchanges have many
-   similarities, and this document describes them in parallel, noting
-   which behaviors are specific to one type of exchange.  The AS request
-   (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
-   (KDC-REQ).  Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
-   are forms of KDC replies (KDC-REP).
-
-   The credentials acquisition protocol operates over specific
-   transports.  Additionally, specific methods exist to permit a client
-   to discover the KDC host with which to communicate.
-
-8.1.  KDC-REQ
-
-   The KDC-REQ has a large number of fields in common between the RFC
-   1510 and the extensible versions.  The KDC-REQ type itself is never
-   directly encoded; it is always a part of a AS-REQ or a TGS-REQ.
-
-      KDC-REQ-1510    ::= SEQUENCE {
-      -- NOTE: first tag is [1], not [0]
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (  10 -- AS-REQ --
-                                   | 12 -- TGS-REQ -- ),
-          padata      [3] SEQUENCE OF PA-DATA OPTIONAL,
-          req-body    [4] KDC-REQ-BODY-1510
-      }
-
-
-      KDC-REQ-EXT     ::= SEQUENCE {
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (  6 -- AS-REQ --
-                                   | 8 -- TGS-REQ -- ),
-          padata      [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL,
-          req-body    [4] KDC-REQ-BODY-EXT,
-          ...
-      }
-
-
-Yu                         Expires: Apr 2007                   [Page 43]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KDC-REQ-BODY-1510       ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalNameIA5 OPTIONAL
-          -- Used only in AS-REQ --,
-
-          realm               [2] RealmIA5
-          -- Server's realm; also client's in AS-REQ --,
-
-          sname               [3] PrincipalNameIA5 OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime,
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce32,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 44]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KDC-REQ-BODY-EXT        ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalName OPTIONAL
-          -- Used only in AS-REQ --,
-
-          realm               [2] Realm
-          -- Server's realm; also client's in AS-REQ --,
-
-          sname               [3] PrincipalName OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime OPTIONAL
-          -- was required in rfc1510;
-          -- still required for compat versions
-          -- of messages --,
-
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --,
-          ...
-          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
-                              LangTag OPTIONAL,
-          ...
-      }
-
-
-   Many fields of KDC-REQ-BODY correspond directly to fields of an
-   EncTicketPart.  The KDC copies most of them unchanged, provided that
-   the requested values meet site policy.
-
-   kdc-options
-        These flags do not correspond directly to "flags" in
-        EncTicketPart.
-
-   cname
-        This field is copied to the "cname" field in EncTicketPart.  The
-        "cname" field is required in an AS-REQ; the client places its
-        own name here.  In a TGS-REQ, the "cname" in the ticket in the
-        AP-REQ takes precedence.
-
-
-
-Yu                         Expires: Apr 2007                   [Page 45]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   realm
-        This field is the server's realm, and also holds the client's
-        realm in an AS-REQ.
-
-   sname
-        The "sname" field indicates the server's name.  It may be absent
-        in a TGS-REQ which requests user-to-user authentication, in
-        which case the "sname" of the issued ticket will be taken from
-        the included additional ticket.
-
-   The "from", "till", and "rtime" fields correspond to the "starttime",
-   "endtime", and "renew-till" fields of EncTicketPart.
-
-   addresses
-        This field corresponds to the "caddr" field of EncTicketPart.
-
-   enc-authorization-data
-        For TGS-REQ, this field contains authorization data encrypted
-        using either the TGT session key or the AP-REQ subsession key;
-        the KDC may copy these into the "authorization-data" field of
-        EncTicketPart if policy permits.
-
-   lang-tags
-        Only present in the extensible messages.  Specifies the set of
-        languages which the client is willing to accept in error
-        messages.
-
-   KDC options used in a KDC-REQ are:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 46]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
-
-      KDCOptionsBits  ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          allow-postdate      (5),
-          postdated           (6),
-          unused7             (7),
-          renewable           (8),
-          unused9             (9),
-          unused10            (10),
-          unused11            (11),
-          unused12            (12),
-          unused13            (13),
-          requestanonymous    (14),
-          canonicalize        (15),
-          disable-transited-check (26),
-          renewable-ok        (27),
-          enc-tkt-in-skey     (28),
-          renew               (30),
-          validate            (31)
-          -- XXX need "need ticket1" flag?
-      }
-
-   Different options apply to different phases of KDC-REQ processing.
-
-   The backwards-compatibility form of a KDC-REQ is:
-
-      KDC-REQ-1510    ::= SEQUENCE {
-      -- NOTE: first tag is [1], not [0]
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (  10 -- AS-REQ --
-                                   | 12 -- TGS-REQ -- ),
-          padata      [3] SEQUENCE OF PA-DATA OPTIONAL,
-          req-body    [4] KDC-REQ-BODY-1510
-      }
-
-   The extensible form of a KDC-REQ is:
-
-      KDC-REQ-EXT     ::= SEQUENCE {
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (  6 -- AS-REQ --
-                                   | 8 -- TGS-REQ -- ),
-          padata      [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL,
-          req-body    [4] KDC-REQ-BODY-EXT,
-          ...
-      }
-
-
-Yu                         Expires: Apr 2007                   [Page 47]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   The backwards-compatibility form of a KDC-REQ-BODY is:
-
-      KDC-REQ-BODY-1510       ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalNameIA5 OPTIONAL
-          -- Used only in AS-REQ --,
-
-          realm               [2] RealmIA5
-          -- Server's realm; also client's in AS-REQ --,
-
-          sname               [3] PrincipalNameIA5 OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime,
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce32,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --
-      }
-
-   The extensible form of a KDC-REQ-BODY is:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 48]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KDC-REQ-BODY-EXT        ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalName OPTIONAL
-          -- Used only in AS-REQ --,
-
-          realm               [2] Realm
-          -- Server's realm; also client's in AS-REQ --,
-
-          sname               [3] PrincipalName OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime OPTIONAL
-          -- was required in rfc1510;
-          -- still required for compat versions
-          -- of messages --,
-
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --,
-          ...
-          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
-                              LangTag OPTIONAL,
-          ...
-      }
-
-   The AS-REQ is:
-
-      AS-REQ  ::= CHOICE {
-          rfc1510     AS-REQ-1510,
-          ext         AS-REQ-EXT
-      }
-      AS-REQ-1510     ::= [APPLICATION 10] KDC-REQ-1510
-          -- AS-REQ must include client name
-
-      AS-REQ-EXT      ::= [APPLICATION 6] Signed {
-          [APPLICATION 6] KDC-REQ-EXT, { key-client }, { ku-ASReq-cksum }
-      }
-      -- AS-REQ must include client name
-
-   A client SHOULD NOT send the extensible AS-REQ alternative to a KDC
-   if the client does not know that the KDC supports the extensibility
-
-Yu                         Expires: Apr 2007                   [Page 49]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   framework.  A client SHOULD send the extensible AS-REQ alternative in
-   a PA-AS-REQ PA-DATA.  A KDC supporting extensibility will treat the
-   AS-REQ contained within the PA-AS-REQ as the actual AS-REQ.  [ XXX
-   what if their contents conflict? ]
-
-   The TGS-REQ is:
-
-      TGS-REQ ::= CHOICE {
-          rfc1510     TGS-REQ-1510,
-          ext         TGS-REQ-EXT
-      }
-
-      TGS-REQ-1510    ::= [APPLICATION 12] KDC-REQ-1510
-
-      TGS-REQ-EXT     ::= [APPLICATION 8] Signed {
-          [APPLICATION 8] KDC-REQ-EXT, { key-session }, { ku-TGSReq-cksum }
-      }
-
-
-8.2.  PA-DATA
-
-   PA-DATA have multiple uses in the Kerberos protocol.  They may pre-
-   authenticate an AS-REQ; they may also modify several of the
-   encryption keys used in a KDC-REP.  PA-DATA may also provide "hints"
-   to the client about which long-term key (usually password-derived) to
-   use.  PA-DATA may also include "hints" about which pre-authentication
-   mechanisms to use, or include data for input into a pre-
-   authentication mechanism.
-
-   [ XXX enumerate standard padata here ]
-
-8.3.  KDC-REQ Processing
-
-   Processing of a KDC-REQ proceeds through several steps.  An
-   implementation need not perform these steps exactly as described, as
-   long as it behaves as if the steps were performed as described.  The
-   KDC performs replay handling upon receiving the request; it then
-   validates the request, adjusts timestamps, and selects the keys used
-   in the reply.  It copies data from the request into the issued
-   ticket, adjusting the values to conform with its policies.  The KDC
-   then transmits the reply to the client.
-
-8.3.1.  Handling Replays
-
-   Because Kerberos can run over unreliable transports such as UDP, the
-   KDC MUST be prepared to retransmit responses in case they are lost.
-   If a KDC receives a request identical to one it has recently
-   successfully processed, the KDC MUST respond with a KDC-REP message
-   rather than a replay error.  In order to reduce the amount of
-   ciphertext given to a potential attacker, KDCs MAY send the same
-   response generated when the request was first handled.  KDCs MUST
-
-Yu                         Expires: Apr 2007                   [Page 50]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   obey this replay behavior even if the actual transport in use is
-   reliable.  If the AP-REQ which authenticates a TGS-REQ is a replay,
-   and the entire request is not identical to a recently successfully
-   processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
-   appropriate for AP-REQ processing.
-
-8.3.2.  Request Validation
-
-8.3.2.1.  AS-REQ Authentication
-
-   Site policy determines whether a given client principal is required
-   to provide some pre-authentication prior to receiving an AS-REP.
-   Since the default reply key is typically the client's long-term
-   password-based key, an attacker may easily request known plaintext
-   (in the form of an AS-REP) upon which to mount a dictionary attack.
-   Pre-authentication can limit the possibility of such an attack.
-
-   If site policy requires pre-authentication for a client principal,
-   and no pre-authentication is provided, the KDC returns the error
-   "kdc-err-preauth-required".  Accompanying this error are "e-data"
-   which include hints telling the client which pre-authentication
-   mechanisms to use, or data for input to pre-authentication mechanisms
-   (e.g., input to challenge-response systems).  If pre-authentication
-   fails, the KDC returns the error "kdc-err-preauth-failed".
-
-   [ may need additional changes based on Sam's preauth draft ]
-
-8.3.2.2.  TGS-REQ Authentication
-
-   A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
-   tgs-req".  The KDC MUST validate the checksum in the Authenticator of
-   the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
-   BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
-   request.  [ padata not signed by authenticator! ] Any error from the
-   AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
-   The service principal in the ticket of the AP-REQ may be a ticket-
-   granting service principal, or a normal application service
-   principal.  A ticket which is not a ticket-granting ticket MUST NOT
-   be used to issue a ticket for any service other than the one named in
-   the ticket.  In this case, the "renew", "validate", or "proxy" [?also
-   forwarded?]  option must be set in the request.
-
-8.3.2.3.  Principal Validation
-
-   If the client principal in an AS-REQ is unknown, the KDC returns the
-   error "kdc-err-c-principal-unknown".  If the server principal in a
-   KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
-   unknown".
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 51]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-8.3.2.4.  Checking For Revoked or Invalid Tickets
-
-   [ KCLAR 3.3.3.1 ]
-
-   Whenever a request is made to the ticket-granting server, the
-   presented ticket(s) is(are) checked against a hot-list of tickets
-   which have been canceled.  This hot-list might be implemented by
-   storing a range of issue timestamps for "suspect tickets"; if a
-   presented ticket had an authtime in that range, it would be rejected.
-   In this way, a stolen ticket-granting ticket or renewable ticket
-   cannot be used to gain additional tickets (renewals or otherwise)
-   once the theft has been reported to the KDC for the realm in which
-   the server resides.  Any normal ticket obtained before it was
-   reported stolen will still be valid (because they require no
-   interaction with the KDC), but only until their normal expiration
-   time.  If TGTs have been issued for cross-realm authentication, use
-   of the cross-realm TGT will not be affected unless the hot-list is
-   propagated to the KDCs for the realms for which such cross-realm
-   tickets were issued.
-
-   If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
-   issue any ticket unless the TGS-REQ requests the "validate" option.
-
-8.3.3.  Timestamp Handling
-
-   [ some aspects of timestamp handling, especially regarding postdating
-   and renewal, are difficult to read in KCLAR... needs closer
-   examination here ]
-
-   Processing of "starttime" (requested in the "from" field) differs
-   depending on whether the "postdated" option is set in the request.
-   If the "postdated" option is not set, and the requested "starttime"
-   is in the future beyond the window of acceptable clock skew, the KDC
-   returns the error "kdc-err-cannot-postdate".  If the "postdated"
-   option is not set, and the requested "starttime" is absent or does
-   not indicate a time in the future beyond the acceptable clock skew,
-   the KDC sets the "starttime" to the KDC's current time.  The
-   "postdated" option MUST NOT be honored if the ticket is being
-   requested by TGS-REQ and the "may-postdate" is not set in the TGT.
-   Otherwise, if the "postdated" option is set, and site policy permits,
-   the KDC sets the "starttime" as requested, and sets the "invalid"
-   flag in the new ticket.
-
-   The "till" field is required in the RFC 1510 version of the KDC-REQ.
-   If the "till" field is equal to "19700101000000Z" (midnight, January
-   1, 1970), the KDC SHOULD behave as if the "till" field were absent.
-
-   The KDC MUST NOT issue a ticket whose "starttime", "endtime", or
-   "renew-till" time is later than the "renew-till" time of the ticket
-   from which it is derived.
-
-
-Yu                         Expires: Apr 2007                   [Page 52]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-8.3.3.1.  AS-REQ Timestamp Processing
-
-   In the AS exchange, the "authtime" of a ticket is set to the local
-   time at the KDC.
-
-   The "endtime" of the ticket will be set to the earlier of the
-   requested "till" time and a time determined by local policy, possibly
-   determined using factors specific to the realm or principal.  For
-   example, the expiration time MAY be set to the earliest of the
-   following:
-
-      * the expiration time ("till" value) requested
-
-      * the ticket's start time plus the maximum allowable lifetime
-        associated with the client principal from the authentication
-        server's database
-
-      * the ticket's start time plus the maximum allowable lifetime
-        associated with the server principal
-
-      * the ticket's start time plus the maximum lifetime set by the
-        policy of the local realm
-
-   If the requested expiration time minus the start time (as determined
-   above) is less than a site-determined minimum lifetime, an error
-   message with code "kdc-err-never-valid" is returned.  If the
-   requested expiration time for the ticket exceeds what was determined
-   as above, and if the "renewable-ok" option was requested, then the
-   "renewable" flag is set in the new ticket, and the "renew-till" value
-   is set as if the "renewable" option were requested.
-
-   If the "renewable" option has been requested or if the "renewable-ok"
-   option has been set and a renewable ticket is to be issued, then the
-   "renew-till" field MAY be set to the earliest of:
-
-      * its requested value
-
-      * the start time of the ticket plus the minimum of the two maximum
-        renewable lifetimes associated with the principals' database
-        entries
-
-      * the start time of the ticket plus the maximum renewable lifetime
-        set by the policy of the local realm
-
-8.3.3.2.  TGS-REQ Timestamp Processing
-
-   In the TGS exchange, the KDC sets the "authtime" to that of the
-   ticket in the AP-REQ authenticating the TGS-REQ.  [?application
-   server can print a ticket for itself with a spoofed authtime.
-   security issues for hot-list?] [ MIT implementation may change
-   authtime of renewed tickets; needs check... ]
-
-Yu                         Expires: Apr 2007                   [Page 53]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ
-   requests an "endtime" (in the "till" field), then the "endtime" of
-   the new ticket is set to the minimum of
-
-      * the requested "endtime" value,
-
-      * the "endtime" in the TGT, and
-
-      * an "endtime" determined by site policy on ticket lifetimes.
-
-   If the new ticket is a renewal, the "endtime" of the new ticket is
-   bounded by the minimum of
-
-      * the requested "endtime" value,
-
-      * the value of the "renew-till" value of the old,
-
-      * the "starttime" of the new ticket plus the lifetime (endtime
-        minus starttime) of the old ticket, i.e., the lifetime of the
-        new ticket may not exceed that of the ticket being renewed [
-        adapted from KCLAR 3.3.3. ], and
-
-      * an "endtime" determined by site policy on ticket lifetimes.
-
-   When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
-   a "starttime", "endtime", or "renew-till" time later than the
-   "renew-till" time of the TGT.
-
-8.3.4.  Handling Transited Realms
-
-   The KDC checks the ticket in a TGS-REQ against site policy, unless
-   the "disable-transited-check" option is set in the TGS-REQ.  If site
-   policy permits the transit path in the TGS-REQ ticket, the KDC sets
-   the "transited-policy-checked" flag in the issued ticket.  If the
-   "disable-transited-check" option is set, the issued ticket will have
-   the "transited-policy-checked" flag cleared.
-
-8.3.5.  Address Processing The requested "addresses" in the KDC-REQ are
-   copied into the issued ticket.  If the "addresses" field is absent or
-   empty in a TGS-REQ, the KDC copies addresses from the ticket in the
-   TGS-REQ into the issued ticket, unless the either "forwarded" or
-   "proxy" option is set.  If the "forwarded" option is set, and the
-   ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies
-   the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the
-   issued ticket.  The KDC behaves similarly if the "proxy" option is
-   set in the TGS-REQ and the "proxiable" flag is set in the ticket.
-   The "proxy" option will not be honored on requests for additional
-   ticket-granting tickets.
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 54]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-8.3.6.  Ticket Flag Processing
-
-   Many kdc-options request that the KDC set a corresponding flag in the
-   issued ticket.  kdc-options marked with an asterisk (*) in the
-   following table do not directly request the corresponding ticket flag
-   and therefore require special handling.
-
-
-             kdc-option       |    ticket flag affected
-      ________________________|__________________________
-      forwardable             |  forwardable
-      forwarded               |  forwarded
-      proxiable               |  proxiable
-      proxy                   |  proxy
-      allow-postdate          |  may-postdate
-      postdated               |  postdated
-      renewable               |  renewable
-      requestanonymous        |  anonymous
-      canonicalize            |  -
-      disable-transited-check*|  transited-policy-checked
-      renewable-ok*           |  renewable
-      enc-tkt-in-skey         |  -
-      renew                   |  -
-      validate*               |  invalid
-
-
-
-   forwarded
-        The KDC sets the "forwarded" flag in the issued ticket if the
-        "forwarded" option is set in the TGS-REQ and the "forwardable"
-        flag is set in the TGS-REQ ticket.
-
-   proxy
-        The KDC sets the "proxy" flag in the issued ticket if the
-        "proxy" option is set in the TGS-REQ and the "proxiable" flag is
-        set in the TGS-REQ ticket.
-
-   disable-transited-check
-        The handling of the "disable-transited-check" kdc-option is
-        described in Section 8.3.4.
-
-   renewable-ok
-        The handling of the "renewable-ok" kdc-option is described in
-        Section 8.3.3.1.
-
-   enc-tkt-in-skey
-        This flag modifies ticket key selection to use the session key
-        of an additional ticket included in the TGS-REQ, for the purpose
-        of user-to-user authentication.
-
-
-
-Yu                         Expires: Apr 2007                   [Page 55]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   validate
-        If the "validate" kdc-option is set in a TGS-REQ, and the
-        "starttime" has passed, the KDC will clear the "invalid" bit on
-        the ticket before re-issuing it.
-
-8.3.7.  Key Selection
-
-   Three keys are involved in creating a KDC-REP.  The reply key
-   encrypts the encrypted part of the KDC-REP.  The session key is
-   stored in the encrypted part of the ticket, and is also present in
-   the encrypted part of the KDC-REP so that the client can retrieve it.
-   The ticket key is used to encrypt the ticket.  These keys all have
-   initial values for a given exchange; pre-authentication and other
-   extension mechanisms may change the value used for any of these keys.
-
-   [ again, may need changes based on Sam's preauth draft ]
-
-8.3.7.1.  Reply Key and Session Key Selection
-
-   The set of encryption types which the client will understand appears
-   in the "etype" field of KDC-REQ-BODY.  The KDC limits the set of
-   possible reply keys and the set of session key encryption types based
-   on the "etype" field.
-
-   For the AS exchange, the reply key is initially a long-term key of
-   the client, limited to those encryption types listed in the "etype"
-   field.  The KDC SHOULD use the first valid strong "etype" for which
-   an encryption key is available.  For the TGS exchange, the reply key
-   is initially the subsession key of the Authenticator.  If the
-   Authenticator subsesion key is absent, the reply key is initially the
-   session key of the ticket used to authenticate the TGS-REQ.
-
-   The session key is initially randomly generated, and has an
-   encryption type which both the client and the server will understand.
-   Typically, the KDC has prior knowledge of which encryption types the
-   server will understand.  It selects the first valid strong "etype"
-   listed the request which the server also will understand.
-
-8.3.7.2.  Ticket Key Selection
-
-   The ticket key is initially the long-term key of the service.  The
-   "enc-tkt-in-skey" option requests user-to-user authentication, where
-   the ticket encryption key of the issued ticket is set equal to the
-   session key of the additional ticket in the request.
-
-8.4.  KDC-REP
-
-   The important parts of the KDC-REP are encrypted.
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 56]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
-      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
-
-      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
-      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
-
-      EncKDCRepPart1510       ::= SEQUENCE {
-          key                 [0] EncryptionKey,
-          last-req            [1] LastReq,
-          nonce               [2] Nonce32,
-          key-expiration      [3] KerberosTime OPTIONAL,
-          flags               [4] TicketFlags,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          srealm              [9] RealmIA5,
-          sname               [10] PrincipalNameIA5,
-          caddr               [11] HostAddresses OPTIONAL
-      }
-
-      EncKDCRepPartExt        ::= SEQUENCE {
-          key                 [0] EncryptionKey,
-          last-req            [1] LastReq,
-          nonce               [2] Nonce,
-          key-expiration      [3] KerberosTime OPTIONAL,
-          flags               [4] TicketFlags,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          srealm              [9] Realm,
-          sname               [10] PrincipalName,
-          caddr               [11] HostAddresses OPTIONAL,
-          ...
-      }
-
-
-   Most of the fields of EncKDCRepPartCom are duplicates of the
-   corresponding fields in the returned ticket.
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 57]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KDC-REP-1510 { EncPart } ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
-                                   13 -- TGS.rfc1510 -- ),
-          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
-          crealm      [3] RealmIA5,
-          cname       [4] PrincipalNameIA5,
-          ticket      [5] Ticket,
-
-          enc-part    [6] EncryptedData {
-              EncPart,
-              { key-reply },
-              -- maybe reach into EncryptedData in AS-REP/TGS-REP
-              -- definitions to apply constraints on key usages?
-              { ku-EncASRepPart -- if AS-REP -- |
-                ku-EncTGSRepPart-subkey -- if TGS-REP and
-                                        -- using Authenticator
-                                        -- session key -- |
-                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
-                                         -- subsession key -- }
-          }
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 58]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KDC-REP-EXT { EncPart } ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (7 -- AS-REP.ext -- |
-                                   9 -- TGS-REP.ext -- ),
-          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
-          crealm      [3] RealmExt,
-          cname       [4] PrincipalNameExt,
-          ticket      [5] Ticket,
-
-          enc-part    [6] EncryptedData {
-              EncPart,
-              { key-reply },
-              -- maybe reach into EncryptedData in AS-REP/TGS-REP
-              -- definitions to apply constraints on key usages?
-              { ku-EncASRepPart -- if AS-REP -- |
-                ku-EncTGSRepPart-subkey -- if TGS-REP and
-                                        -- using Authenticator
-                                        -- session key -- |
-                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
-                                         -- subsession key -- }
-          },
-
-          ...,
-          -- In extensible version, KDC signs original request
-          -- to avoid replay attacks against client.
-          req-cksum   [7] ChecksumOf { CHOICE {
-              as-req          AS-REQ,
-              tgs-req         TGS-REQ
-          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
-          lang-tag    [8] LangTag OPTIONAL,
-          ...
-      }
-
-
-   req-cksum
-        Signature of the original request using the reply key, to avoid
-        replay attacks against the client, among other things.  Only
-        present in the extensible version of KDC-REP.
-
-           AS-REP          ::= CHOICE {
-               rfc1510     AS-REP-1510,
-               ext         AS-REP-EXT
-           }
-           AS-REP-1510     ::= [APPLICATION 11] KDC-REP-1510
-           AS-REP-EXT      ::= [APPLICATION 7] Signed {
-               [APPLICATION 7] KDC-REP-EXT,
-               { key-reply }, { ku-ASRep-cksum }
-           }
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 59]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-           TGS-REP         ::= CHOICE {
-               rfc1510     TGS-REP-1510,
-               ext         TGS-REP-EXT
-           }
-           TGS-REP-1510    ::= [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart1510 }
-           TGS-REP-EXT     ::= [APPLICATION 9] Signed {
-               [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
-               { key-reply }, { ku-TGSRep-cksum }
-           }
-
-
-   The extensible versions of AS-REQ and TGS-REQ are signed with the
-   reply key, to prevent an attacker from performing a delayed denial-
-   of-service attack by substituting the ticket.
-
-8.5.  Reply Validation
-
-   [ signature verification ]
-
-8.6.  IP Transports
-
-   [ KCLAR 7.2 ]
-
-   Kerberos defines two IP transport mechanisms for the credentials
-   acquisition protocol: UDP/IP and TCP/IP.
-
-8.6.1.  UDP/IP transport
-
-   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
-   requests and SHOULD listen for such requests on port 88 (decimal)
-   unless specifically configured to listen on an alternative UDP port.
-   Alternate ports MAY be used when running multiple KDCs for multiple
-   realms on the same host.
-
-   Kerberos clients supporting IP transports SHOULD support the sending
-   of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to
-   identify the IP address and port to which they will send their
-   request.
-
-   When contacting a KDC for a KRB_KDC_REQ request using UDP/IP
-   transport, the client shall send a UDP datagram containing only an
-   encoding of the request to the KDC. The KDC will respond with a reply
-   datagram containing only an encoding of the reply message (either a
-   KRB-ERROR or a KDC-REP) to the sending port at the sender's IP
-   address. The response to a request made through UDP/IP transport MUST
-   also use UDP/IP transport. If the response can not be handled using
-   UDP (for example because it is too large), the KDC MUST return "krb-
-   err-response-too-big", forcing the client to retry the request using
-   the TCP transport.
-
-
-
-Yu                         Expires: Apr 2007                   [Page 60]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-8.6.2.  TCP/IP transport
-
-   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
-   requests and SHOULD listen for such requests on port 88 (decimal)
-   unless specifically configured to listen on an alternate TCP port.
-   Alternate ports MAY be used when running multiple KDCs for multiple
-   realms on the same host.
-
-   Clients MUST support the sending of TCP requests, but MAY choose to
-   initially try a request using the UDP transport. Clients SHOULD use
-   KDC discovery (Section 8.6.3) to identify the IP address and port to
-   which they will send their request.
-
-   Implementation note: Some extensions to the Kerberos protocol will
-   not succeed if any client or KDC not supporting the TCP transport is
-   involved.  Implementations of RFC 1510 were not required to support
-   TCP/IP transports.
-
-   When the KDC-REQ message is sent to the KDC over a TCP stream, the
-   response (KDC-REP or KRB-ERROR message) MUST be returned to the
-   client on the same TCP stream that was established for the request.
-   The KDC MAY close the TCP stream after sending a response, but MAY
-   leave the stream open for a reasonable period of time if it expects a
-   followup. Care must be taken in managing TCP/IP connections on the
-   KDC to prevent denial of service attacks based on the number of open
-   TCP/IP connections.
-
-   The client MUST be prepared to have the stream closed by the KDC at
-   anytime after the receipt of a response.  A stream closure SHOULD NOT
-   be treated as a fatal error.  Instead, if multiple exchanges are
-   required (e.g., certain forms of pre-authentication) the client may
-   need to establish a new connection when it is ready to send
-   subsequent messages.  A client MAY close the stream after receiving a
-   response, and SHOULD close the stream if it does not expect to send
-   followup messages.
-
-   A client MAY send multiple requests before receiving responses,
-   though it must be prepared to handle the connection being closed
-   after the first response.
-
-   Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over
-   the TCP stream is preceded by the length of the request as 4 octets
-   in network byte order. The high bit of the length is reserved for
-   future expansion and MUST currently be set to zero.  If a KDC that
-   does not understand how to interpret a set high bit of the length
-   encoding receives a request with the high order bit of the length
-   set, it MUST return a KRB-ERROR message with the error "krb-err-
-   field-toolong" and MUST close the TCP stream.
-
-   If multiple requests are sent over a single TCP connection, and the
-   KDC sends multiple responses, the KDC is not required to send the
-
-Yu                         Expires: Apr 2007                   [Page 61]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   responses in the order of the corresponding requests.  This may
-   permit some implementations to send each response as soon as it is
-   ready even if earlier requests are still being processed (for
-   example, waiting for a response from an external device or database).
-
-8.6.3.  KDC Discovery on IP Networks
-
-   Kerberos client implementations MUST provide a means for the client
-   to determine the location of the Kerberos Key Distribution Centers
-   (KDCs).  Traditionally, Kerberos implementations have stored such
-   configuration information in a file on each client machine.
-   Experience has shown this method of storing configuration information
-   presents problems with out-of-date information and scaling problems,
-   especially when using cross-realm authentication. This section
-   describes a method for using the Domain Name System [RFC 1035] for
-   storing KDC location information.
-
-8.6.3.1.  DNS vs. Kerberos - Case Sensitivity of Realm Names
-
-   In Kerberos, realm names are case sensitive.  While it is strongly
-   encouraged that all realm names be all upper case this recommendation
-   has not been adopted by all sites.  Some sites use all lower case
-   names and other use mixed case.  DNS, on the other hand, is case
-   insensitive for queries.  Since the realm names "MYREALM", "myrealm",
-   and "MyRealm" are all different, but resolve the same in the domain
-   name system, it is necessary that only one of the possible
-   combinations of upper and lower case characters be used in realm
-   names.
-
-8.6.3.2.  DNS SRV records for KDC location
-
-   KDC location information is to be stored using the DNS SRV RR [RFC
-   2782].  The format of this RR is as follows:
-
-      _Service._Proto.Realm TTL Class SRV Priority Weight Port Target
-
-   The Service name for Kerberos is always "kerberos".
-
-   The Proto can be one of "udp", "tcp". If these SRV records are to be
-   used, both "udp" and "tcp" records MUST be specified for all KDC
-   deployments.
-
-   The Realm is the Kerberos realm that this record corresponds to.  The
-   realm MUST be a domain style realm name.
-
-   TTL, Class, SRV, Priority, Weight, and Target have the standard
-   meaning as defined in RFC 2782.
-
-   As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
-   records SHOULD be the value assigned to "kerberos" by the Internet
-   Assigned Number Authority: 88 (decimal) unless the KDC is configured
-
-Yu                         Expires: Apr 2007                   [Page 62]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   to listen on an alternate TCP port.
-
-   Implementation note: Many existing client implementations do not
-   support KDC Discovery and are configured to send requests to the IANA
-   assigned port (88 decimal), so it is strongly recommended that KDCs
-   be configured to listen on that port.
-
-8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP Networks
-
-   These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
-   Kerberos servers, kdc1.example.com and kdc2.example.com.  Queries
-   should be directed to kdc1.example.com first as per the specified
-   priority.  Weights are not used in these sample records.
-
-      _kerberos._udp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
-      _kerberos._udp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
-      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
-      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
-
-
-9.  Errors
-
-   The KRB-ERROR message is returned by the KDC if an error occurs
-   during credentials acquisition.  It may also be returned by an
-   application server if an error occurs during authentication.
-
-      ErrCode ::= Int32
-
-      KRB-ERROR       ::= CHOICE {
-          rfc1510     KRB-ERROR-1510,
-          ext         KRB-ERROR-EXT
-      }
-
-
-   The extensible KRB-ERROR is only signed if there has been a key
-   negotiated with its recipient.  KRB-ERROR messages sent in response
-   to AS-REQ messages will probably not be signed unless a
-   preauthentication mechanism has negotiated a key.  (Signing using a
-   client's long-term key can expose ciphertext to dictionary attacks.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 63]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KRB-ERROR-1510 ::= [APPLICATION 30] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (30),
-          ctime       [2] KerberosTime OPTIONAL,
-          cusec       [3] Microseconds OPTIONAL,
-          stime       [4] KerberosTime,
-          susec       [5] Microseconds,
-          error-code  [6] ErrCode,
-          crealm      [7] RealmIA5 OPTIONAL,
-          cname       [8] PrincipalNameIA5 OPTIONAL,
-          realm       [9] RealmIA5 -- Correct realm --,
-          sname       [10] PrincipalNameIA5 -- Correct name --,
-          e-text      [11] KerberosString OPTIONAL,
-          e-data      [12] OCTET STRING OPTIONAL
-      }
-
-
-      KRB-ERROR-EXT ::= [APPLICATION 23] Signed {
-          [APPLICATION 23] SEQUENCE{
-              pvno        [0] INTEGER (5),
-              msg-type    [1] INTEGER (23),
-              ctime       [2] KerberosTime OPTIONAL,
-              cusec       [3] Microseconds OPTIONAL,
-              stime       [4] KerberosTime,
-              susec       [5] Microseconds,
-              error-code  [6] ErrCode,
-              crealm      [7] Realm OPTIONAL,
-              cname       [8] PrincipalName OPTIONAL,
-              realm       [9] Realm -- Correct realm --,
-              sname       [10] PrincipalName -- Correct name --,
-              e-text      [11] KerberosString OPTIONAL,
-              e-data      [12] OCTET STRING OPTIONAL,
-              ...,
-              typed-data          [13] TYPED-DATA OPTIONAL,
-              nonce               [14] Nonce OPTIONAL,
-              lang-tag            [15] LangTag OPTIONAL,
-              ...
-          }, { }, { ku-KrbError-cksum }
-      }
-
-
-   ctime, cusec
-        Client's time, if known from a KDC-REQ or AP-REQ.
-
-   stime, susec
-        KDC or application server's current time.
-
-   error-code
-        Numeric error code designating the error.
-
-
-
-Yu                         Expires: Apr 2007                   [Page 64]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   crealm, cname
-        Client's realm and name, if known.
-
-   realm, sname
-        server's realm and name. [ XXX what if these aren't known? ]
-
-   e-text
-        Human-readable text providing additional details for the error.
-
-   e-data
-        This field contains additional data about the error for use by
-        the client to help it recover from or handle the error. If the
-        "error-code" is "kdc-err-preauth-required", then the e-data
-        field will contain an encoding of a sequence of padata fields,
-        each corresponding to an acceptable pre-authentication method
-        and optionally containing data for the method:
-
-           METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-
-        For error codes defined in this document other than "kdc-err-
-        preauth-required", the format and contents of the e-data field
-        are implementation-defined.  Similarly, for future error codes,
-        the format and contents of the e-data field are implementation-
-        defined unless specified.
-
-   lang-tag
-        Indicates the language of the message in the "e-text" field.  It
-        is only present in the extensible KRB-ERROR.
-
-   nonce
-        is the nonce from a KDC-REQ.  It is only present in the
-        extensible KRB-ERROR.
-
-   typed-data
-        TYPED-DATA is a typed hole allowing for additional data to be
-        returned in error conditions, since "e-data" is insufficiently
-        flexible for some purposes.  TYPED-DATA is only present in the
-        extensible KRB-ERROR.
-
-           TDType ::= TH-id
-
-           TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-               data-type   [0] TDType,
-               data-value  [1] OCTET STRING OPTIONAL
-           }
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 65]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-10.  Session Key Exchange
-
-   Session key exchange consists of the AP-REQ and AP-REP messages.  The
-   client sends the AP-REQ message, and the service responds with an
-   AP-REP message if mutual authentication is desired.  Following
-   session key exchange, the client and service share a secret session
-   key, or possibly a subsesion key, which can be used to protect
-   further communications.  Additionally, the session key exchange
-   process can establish initial sequence numbers which the client and
-   service can use to detect replayed messages.
-
-10.1.  AP-REQ
-
-   An AP-REQ message contains a ticket and a authenticator.  The
-   authenticator is ciphertext encrypted with the session key contained
-   in the ticket.  The plaintext contents of the authenticator are:
-
-      -- plaintext of authenticator
-      Authenticator1510       ::= [APPLICATION 2] SEQUENCE  {
-          authenticator-vno   [0] INTEGER (5),
-          crealm              [1] RealmIA5,
-          cname               [2] PrincipalNameIA5,
-          cksum               [3] Checksum {{ key-session },
-              { ku-Authenticator-cksum |
-                ku-pa-TGSReq-cksum }} OPTIONAL,
-          cusec               [4] Microseconds,
-          ctime               [5] KerberosTime,
-          subkey              [6] EncryptionKey OPTIONAL,
-          seq-number          [7] SeqNum32 OPTIONAL,
-          authorization-data  [8] AuthorizationData OPTIONAL
-      }
-
-      AuthenticatorExt        ::= [APPLICATION 35] SEQUENCE  {
-          authenticator-vno   [0] INTEGER (5),
-          crealm              [1] RealmExt,
-          cname               [2] PrincipalNameExt,
-          cksum               [3] Checksum {{ key-session },
-              { ku-Authenticator-cksum |
-                ku-pa-TGSReq-cksum }} OPTIONAL,
-          cusec               [4] Microseconds,
-          ctime               [5] KerberosTime,
-          subkey              [6] EncryptionKey OPTIONAL,
-          seq-number          [7] SeqNum OPTIONAL,
-          authorization-data  [8] AuthorizationData OPTIONAL,
-          ...
-      }
-
-   The complete definition of AP-REQ is:
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 66]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      AP-REQ          ::= CHOICE {
-          rfc1510     AP-REQ-1510,
-          ext         AP-REQ-EXT
-      }
-
-
-      AP-REQ-1510      ::= [APPLICATION 14] SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket1510,
-          authenticator       [4] EncryptedData {
-              Authenticator1510,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          }
-      }
-
-
-      AP-REQ-EXT      ::= [APPLICATION 18] Signed {
-          [APPLICATION 18] SEQUENCE {
-              pvno                [0] INTEGER (5),
-              msg-type            [1] INTEGER (18),
-              ap-options          [2] APOptions,
-              ticket              [3] Ticket,
-              authenticator       [4] EncryptedData {
-                  AuthenticatorExt,
-                  { key-session },
-                  { ku-APReq-authenticator |
-                    ku-pa-TGSReq-authenticator }
-              },
-              ...,
-              extensions          [5] ApReqExtensions OPTIONAL,
-              lang-tag            [6] SEQUENCE (SIZE (1..MAX))
-                                      OF LangTag OPTIONAL,
-              ...
-          }, { key-session }, { ku-APReq-cksum }
-      }
-
-
-      APOptions       ::= KerberosFlags { APOptionsBits }
-
-      APOptionsBits ::= BIT STRING {
-          reserved            (0),
-          use-session-key     (1),
-          mutual-required     (2)
-      }
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 67]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-10.2.  AP-REP
-
-   An AP-REP message provides mutual authentication of the service to
-   the client.
-
-      EncAPRepPart    ::= CHOICE {
-          rfc1510     EncAPRepPart1510,
-          ext         EncAPRepPartExt
-      }
-
-
-      EncAPRepPart1510        ::= [APPLICATION 27] SEQUENCE {
-          ctime               [0] KerberosTime,
-          cusec               [1] Microseconds,
-          subkey              [2] EncryptionKey OPTIONAL,
-          seq-number          [3] SeqNum32 OPTIONAL
-      }
-
-
-      EncAPRepPartExt         ::= [APPLICATION 31] SEQUENCE {
-          ctime               [0] KerberosTime,
-          cusec               [1] Microseconds,
-          subkey              [2] EncryptionKey OPTIONAL,
-          seq-number          [3] SeqNum OPTIONAL,
-          ...,
-          authorization-data  [4] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-      AP-REP          ::= CHOICE {
-          rfc1510     AP-REP-1510,
-          ext         AP-REP-EXT
-      }
-
-
-      AP-REP-1510     ::= [APPLICATION 15] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (15),
-          enc-part    [2] EncryptedData {
-              EncApRepPart1510,
-              { key-session | key-subsession }, { ku-EncAPRepPart }}
-      }
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 68]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      AP-REP-EXT      ::= [APPLICATION 19] Signed {
-          [APPLICATION 19] SEQUENCE {
-              pvno        [0] INTEGER (5),
-              msg-type    [1] INTEGER (19),
-              enc-part    [2] EncryptedData {
-                  EncAPRepPartExt,
-                  { key-session | key-subsession }, { ku-EncAPRepPart }},
-              ...,
-              extensions          [3] ApRepExtensions OPTIONAL,
-              ...
-          }, { key-session | key-subsession }, { ku-APRep-cksum }
-      }
-
-
-11.  Session Key Use
-
-   Once a session key has been established, the client and server can
-   use several kinds of messages to securely transmit data.  KRB-SAFE
-   provides integrity protection for application data, while KRB-PRIV
-   provides confidentiality along with integrity protection.  The KRB-
-   CRED message provides a means of securely forwarding credentials from
-   the client host to the server host.
-
-11.1.  KRB-SAFE
-
-   The KRB-SAFE message provides integrity protection for an included
-   cleartext message.
-
-      KRB-SAFE        ::= CHOICE {
-          rfc1510     KRB-SAFE-1510,
-          ext         KRB-SAFE-EXT
-      }
-
-
-      KRB-SAFE-BODY   ::= SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress,
-          r-address   [5] HostAddress OPTIONAL,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-11.2.  KRB-PRIV
-
-   The KRB-PRIV message provides confidentiality and integrity
-   protection.
-
-
-Yu                         Expires: Apr 2007                   [Page 69]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (21),
-          enc-part    [3] EncryptedData {
-              EncKrbPrivPart,
-              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
-          ...
-      }
-
-
-      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress -- sender's addr --,
-          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-11.3.  KRB-CRED
-
-   The KRB-CRED message provides a means of securely transferring
-   credentials from the client to the service.
-
-      KRB-CRED        ::= CHOICE {
-          rfc1510     KRB-CRED-1510,
-          ext         KRB-CRED-EXT
-
-      }
-
-
-      KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (22),
-          tickets     [2] SEQUENCE OF Ticket,
-          enc-part    [3] EncryptedData {
-              EncKrbCredPart,
-              { key-session | key-subsession }, { ku-EncKrbCredPart }}
-      }
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 70]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KRB-CRED-EXT    ::= [APPLICATION 24] Signed {
-          [APPLICATION 24] SEQUENCE {
-              pvno        [0] INTEGER (5),
-              msg-type    [1] INTEGER (24),
-              tickets     [2] SEQUENCE OF Ticket,
-              enc-part    [3] EncryptedData {
-                  EncKrbCredPart,
-                  { key-session | key-subsession }, { ku-EncKrbCredPart }},
-              ...
-          }, { key-session | key-subsession }, { ku-KrbCred-cksum }
-      }
-
-
-
-      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-          ticket-info [0] SEQUENCE OF KrbCredInfo,
-          nonce       [1] Nonce OPTIONAL,
-          timestamp   [2] KerberosTime OPTIONAL,
-          usec        [3] Microseconds OPTIONAL,
-          s-address   [4] HostAddress OPTIONAL,
-          r-address   [5] HostAddress OPTIONAL
-      }
-
-
-      KrbCredInfo     ::= SEQUENCE {
-          key         [0] EncryptionKey,
-          prealm      [1] Realm OPTIONAL,
-          pname       [2] PrincipalName OPTIONAL,
-          flags       [3] TicketFlags OPTIONAL,
-          authtime    [4] KerberosTime OPTIONAL,
-          starttime   [5] KerberosTime OPTIONAL,
-          endtime     [6] KerberosTime OPTIONAL,
-          renew-till  [7] KerberosTime OPTIONAL,
-          srealm      [8] Realm OPTIONAL,
-          sname       [9] PrincipalName OPTIONAL,
-          caddr       [10] HostAddresses OPTIONAL
-      }
-
-
-12.  Security Considerations
-
-12.1.  Time Synchronization
-
-   Time synchronization between the KDC and application servers is
-   necessary to prevent acceptance of expired tickets.
-
-   Time synchronization is needed between application servers and
-   clients to prevent replay attacks if a replay cache is being used.
-   If negotiated subsession keys are used to encrypt application data,
-   replay caches may not be necessary.
-
-
-Yu                         Expires: Apr 2007                   [Page 71]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-12.2.  Replays
-
-12.3.  Principal Name Reuse
-
-   See Section 5.3.
-
-12.4.  Password Guessing
-
-12.5.  Forward Secrecy
-
-   [from KCLAR 10.; needs some rewriting]
-
-   The Kerberos protocol in its basic form does not provide perfect
-   forward secrecy for communications.  If traffic has been recorded by
-   an eavesdropper, then messages encrypted using the KRB-PRIV message,
-   or messages encrypted using application-specific encryption under
-   keys exchanged using Kerberos can be decrypted if any of the user's,
-   application server's, or KDC's key is subsequently discovered.  This
-   is because the session key used to encrypt such messages is
-   transmitted over the network encrypted in the key of the application
-   server, and also encrypted under the session key from the user's
-   ticket-granting ticket when returned to the user in the TGS-REP
-   message.  The session key from the ticket-granting ticket was sent to
-   the user in the AS-REP message encrypted in the user's secret key,
-   and embedded in the ticket-granting ticket, which was encrypted in
-   the key of the KDC.  Application requiring perfect forward secrecy
-   must exchange keys through mechanisms that provide such assurance,
-   but may use Kerberos for authentication of the encrypted channel
-   established through such other means.
-
-12.6.  Authorization
-
-   As an authentication service, Kerberos provides a means of verifying
-   the identity of principals on a network.  Kerberos does not, by
-   itself, provide authorization.  Applications SHOULD NOT accept the
-   mere issuance of a service ticket by the Kerberos server as granting
-   authority to use the service.
-
-12.7.  Login Authentication
-
-   Some applications, particularly those which provide login access when
-   provided with a password, SHOULD NOT treat successful acquisition of
-   credentials as sufficient proof of the user's identity.  An attacker
-   posing as a user could generate an illegitimate KDC-REP message which
-   decrypts properly.  To authenticate a user logging on to a local
-   system, the credentials obtained SHOULD be used in a TGS exchange to
-   obtain credentials for a local service.  Successful use of those
-   credentials to authenticate to the local service assures that the
-   initially obtained credentials are from a valid KDC.
-
-
-
-Yu                         Expires: Apr 2007                   [Page 72]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-13.  IANA Considerations
-
-   [ needs more work ]
-
-   Each use of Int32 in this document defines a number space.  [ XXX
-   enumerate these ] Negative numbers are reserved for private use;
-   local and experimental extensions should use these values.  Zero is
-   reserved and may not be assigned.
-
-   Typed hole contents may be identified by either Int32 values or by
-   RELATIVE-OID values.  Since RELATIVE-OIDs define a hierarchical
-   namespace, assignments to the top level of the RELATIVE-OID space may
-   be made on a first-come, first-served basis.
-
-14.  Acknowledgments
-
-   Much of the text here is adapted from draft-ietf-krb-wg-kerberos-
-   clarifications-07.  The description of the general form of the
-   extensibility framework was derived from text by Sam Hartman.  Some
-   text concerning internationalization of internationalized domain
-   names in principal names and realm names was contributed by Jeffrey
-   Altman and Jeffrey Hutzelman.
-
-Appendices
-
-A.  ASN.1 Module (Normative)
-
-      KerberosV5Spec3 {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2) modules(4) krb5spec3(4)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-
-      -- OID arc for KerberosV5
-      --
-      -- This OID may be used to identify Kerberos protocol messages
-      -- encapsulated in other protocols.
-      --
-      -- This OID also designates the OID arc for KerberosV5-related
-      -- OIDs.
-      --
-      -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
-      -- OID.
-      id-krb5         OBJECT IDENTIFIER ::= {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2)
-      }
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 73]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- top-level type
-      --
-      -- Applications should not directly reference any types
-      -- other than KRB-PDU and its component types.
-      --
-      KRB-PDU         ::= CHOICE {
-          ticket      Ticket,
-          as-req      AS-REQ,
-          as-rep      AS-REP,
-          tgs-req     TGS-REQ,
-          tgs-rep     TGS-REP,
-          ap-req      AP-REQ,
-          ap-rep      AP-REP,
-          krb-safe    KRB-SAFE,
-          krb-priv    KRB-PRIV,
-          krb-cred    KRB-CRED,
-          tgt-req     TGT-REQ,
-          krb-error   KRB-ERROR,
-          ...
-      }
-
-
-      --
-      -- *** basic types
-      --
-
-
-      -- signed values representable in 32 bits
-      --
-      -- These are often used as assigned numbers for various things.
-      Int32           ::= INTEGER (-2147483648..2147483647)
-
-
-      -- Typed hole identifiers
-      TH-id           ::= CHOICE {
-          int32               Int32,
-          rel-oid             RELATIVE-OID
-      }
-
-
-      -- unsigned 32 bit values
-      UInt32          ::= INTEGER (0..4294967295)
-
-
-      -- unsigned 64 bit values
-      UInt64          ::= INTEGER (0..18446744073709551615)
-
-
-      -- sequence numbers
-      SeqNum          ::= UInt64
-
-
-Yu                         Expires: Apr 2007                   [Page 74]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- nonces
-      Nonce           ::= UInt64
-
-
-      -- microseconds
-      Microseconds    ::= INTEGER (0..999999)
-
-
-      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
-                              -- MUST NOT include fractional seconds
-      })
-
-
-      -- used for names and for error messages
-      KerberosString  ::= CHOICE {
-          ia5         GeneralString (IA5String),
-          utf8        UTF8String,
-          ...         -- no extension may be sent
-                      -- to an rfc1510 implementation --
-      }
-
-
-      -- IA5 choice only; useful for constraints
-      KerberosStringIA5       ::= KerberosString
-          (WITH COMPONENTS { ia5 PRESENT })
-
-      -- IA5 excluded; useful for constraints
-      KerberosStringExt       ::= KerberosString
-          (WITH COMPONENTS { ia5 ABSENT })
-
-
-      -- used for language tags
-      LangTag ::= PrintableString
-          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 75]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- assigned numbers for name types (used in principal names)
-      NameType        ::= Int32
-
-      -- Name type not known
-      nt-unknown              NameType ::= 0
-      -- Just the name of the principal as in DCE, or for users
-      nt-principal            NameType ::= 1
-      -- Service and other unique instance (krbtgt)
-      nt-srv-inst             NameType ::= 2
-      -- Service with host name as instance (telnet, rcommands)
-      nt-srv-hst              NameType ::= 3
-      -- Service with host as remaining components
-      nt-srv-xhst             NameType ::= 4
-      -- Unique ID
-      nt-uid                  NameType ::= 5
-      -- Encoded X.509 Distingished name [RFC 2253]
-      nt-x500-principal       NameType ::= 6
-      -- Name in form of SMTP email name (e.g. user@foo.com)
-      nt-smtp-name            NameType ::= 7
-      -- Enterprise name - may be mapped to principal name
-      nt-enterprise           NameType ::= 10
-
-
-      PrincipalName { StrType }       ::= SEQUENCE {
-          name-type   [0] NameType,
-          -- May have zero elements, or individual elements may be
-          -- zero-length, but this is NOT RECOMMENDED.
-          name-string [1] SEQUENCE OF KerberosString (StrType)
-      }
-
-
-      -- IA5 only
-      PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 }
-      -- IA5 excluded
-      PrincipalNameExt ::= PrincipalName { KerberosStringExt }
-      -- Either one?
-      PrincipalNameEither ::= PrincipalName { KerberosString }
-
-
-      Realm { StrType }       ::= KerberosString (StrType)
-
-      -- IA5 only
-      RealmIA5                ::= Realm { KerberosStringIA5 }
-
-      -- IA5 excluded
-      RealmExt                ::= Realm { KerberosStringExt }
-
-      -- Either
-      RealmEither             ::= Realm { KerberosString }
-
-
-
-Yu                         Expires: Apr 2007                   [Page 76]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
-          (CONSTRAINED BY {
-          -- MUST be a valid value of -- NamedBits
-          -- but if the value to be sent would be truncated to shorter
-          -- than 32 bits according to DER, the value MUST be padded
-          -- with trailing zero bits to 32 bits.  Otherwise, no
-          -- trailing zero bits may be present.
-
-      })
-
-
-      AddrType        ::= Int32
-
-      HostAddress     ::= SEQUENCE  {
-          addr-type   [0] AddrType,
-          address     [1] OCTET STRING
-      }
-
-      -- NOTE: HostAddresses is always used as an OPTIONAL field and
-      -- should not be a zero-length SEQUENCE OF.
-      --
-      -- The extensible messages explicitly constrain this to be
-      -- non-empty.
-      HostAddresses   ::= SEQUENCE OF HostAddress
-
-
-      --
-      -- *** crypto-related types and assignments
-      --
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 77]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- Assigned numbers denoting encryption mechanisms.
-      EType ::= Int32
-
-      -- assigned numbers for encryption schemes
-      et-des-cbc-crc                  EType ::= 1
-      et-des-cbc-md4                  EType ::= 2
-      et-des-cbc-md5                  EType ::= 3
-      --     [reserved]                         4
-      et-des3-cbc-md5                 EType ::= 5
-      --     [reserved]                         6
-      et-des3-cbc-sha1                EType ::= 7
-      et-dsaWithSHA1-CmsOID           EType ::= 9
-      et-md5WithRSAEncryption-CmsOID  EType ::= 10
-      et-sha1WithRSAEncryption-CmsOID EType ::= 11
-      et-rc2CBC-EnvOID                EType ::= 12
-      et-rsaEncryption-EnvOID         EType ::= 13
-      et-rsaES-OAEP-ENV-OID           EType ::= 14
-      et-des-ede3-cbc-Env-OID         EType ::= 15
-      et-des3-cbc-sha1-kd             EType ::= 16
-      -- AES
-      et-aes128-cts-hmac-sha1-96      EType ::= 17
-      -- AES
-      et-aes256-cts-hmac-sha1-96      EType ::= 18
-      -- Microsoft
-      et-rc4-hmac                     EType ::= 23
-      -- Microsoft
-      et-rc4-hmac-exp                 EType ::= 24
-      -- opaque; PacketCable
-      et-subkey-keymaterial           EType ::= 65
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 78]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- Assigned numbers denoting key usages.
-      KeyUsage ::= UInt32
-
-      --
-      -- Actual identifier names are provisional and subject to
-      -- change.
-      --
-      ku-pa-enc-ts                    KeyUsage ::= 1
-      ku-Ticket                       KeyUsage ::= 2
-      ku-EncASRepPart                 KeyUsage ::= 3
-      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
-      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
-      ku-pa-TGSReq-cksum              KeyUsage ::= 6
-      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
-      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
-      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
-      ku-Authenticator-cksum          KeyUsage ::= 10
-      ku-APReq-authenticator          KeyUsage ::= 11
-      ku-EncAPRepPart                 KeyUsage ::= 12
-      ku-EncKrbPrivPart               KeyUsage ::= 13
-      ku-EncKrbCredPart               KeyUsage ::= 14
-      ku-KrbSafe-cksum                KeyUsage ::= 15
-      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
-
-
-      -- The following numbers are provisional...
-      -- conflicts may exist elsewhere.
-      ku-Ticket-cksum                 KeyUsage ::= 29
-      ku-ASReq-cksum                  KeyUsage ::= 30
-      ku-TGSReq-cksum                 KeyUsage ::= 31
-      ku-ASRep-cksum                  KeyUsage ::= 32
-      ku-TGSRep-cksum                 KeyUsage ::= 33
-      ku-APReq-cksum                  KeyUsage ::= 34
-      ku-APRep-cksum                  KeyUsage ::= 35
-      ku-KrbCred-cksum                KeyUsage ::= 36
-      ku-KrbError-cksum               KeyUsage ::= 37
-      ku-KDCRep-cksum                 KeyUsage ::= 38
-
-      ku-kg-acceptor-seal             KeyUsage ::= 22
-      ku-kg-acceptor-sign             KeyUsage ::= 23
-      ku-kg-intiator-seal             KeyUsage ::= 24
-      ku-kg-intiator-sign             KeyUsage ::= 25
-
-      -- KeyUsage values 25..27 used by hardware preauth?
-
-      -- for KINK
-      ku-kink-encrypt                 KeyUsage ::= 39
-      ku-kink-cksum                   KeyUsage ::= 40
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 79]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- KeyToUse identifies which key is to be used to encrypt or
-      -- sign a given value.
-      --
-      -- Values of KeyToUse are never actually transmitted over the
-      -- wire, or even used directly by the implementation in any
-      -- way, as key usages are; it exists primarily to identify
-      -- which key gets used for what purpose.  Thus, the specific
-      -- numeric values associated with this type are irrelevant.
-      KeyToUse        ::= ENUMERATED {
-          -- unspecified
-          key-unspecified,
-          -- server long term key
-          key-server,
-          -- client long term key
-          key-client,
-          -- key selected by KDC for encryption of a KDC-REP
-          key-kdc-rep,
-          -- session key from ticket
-          key-session,
-          -- subsession key negotiated via AP-REQ/AP-REP
-          key-subsession,
-          ...
-      }
-
-
-      EncryptionKey   ::= SEQUENCE {
-          keytype     [0] EType,
-          keyvalue    [1] OCTET STRING
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 80]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-
-      -- "Type" specifies which ASN.1 type is encrypted to the
-      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
-      -- keys of which one key may be used to encrypt the data.
-      -- "KeyUsages" specifies a set of key usages, one of which may
-      -- be used to encrypt.
-      --
-      -- None of the parameters is transmitted over the wire.
-      EncryptedData {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          etype       [0] EType,
-          kvno        [1] UInt32 OPTIONAL,
-          cipher      [2] OCTET STRING (CONSTRAINED BY {
-              -- must be encryption of --
-              OCTET STRING (CONTAINING Type),
-              -- with one of the keys -- KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          }),
-          ...
-      }
-
-
-
-      CksumType       ::= Int32
-
-      -- The parameters specify which key to use to produce the
-      -- signature, as well as which key usage to use.  The
-      -- parameters are not actually sent over the wire.
-      Checksum {
-          KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksumtype   [0] CksumType,
-          checksum    [1] OCTET STRING (CONSTRAINED BY {
-              -- signed using one of the keys --
-              KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          })
-      }
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 81]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- a Checksum that must contain the checksum
-      -- of a particular type
-      ChecksumOf {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
-          ...,
-          checksum (CONSTRAINED BY {
-              -- must be checksum of --
-              OCTET STRING (CONTAINING Type)
-          })
-      })
-
-
-      -- parameterized type for wrapping authenticated plaintext
-      Signed {
-          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksum       [0] ChecksumOf {
-              InnerType, Keys, KeyUsages
-          } OPTIONAL,
-          inner       [1] InnerType,
-          ...
-      }
-
-
-      --
-      -- *** Tickets
-      --
-
-
-      Ticket          ::= CHOICE {
-          rfc1510     Ticket1510,
-          ext         TicketExt
-      }
-
-
-      Ticket1510      ::= [APPLICATION 1] SEQUENCE {
-          tkt-vno     [0] INTEGER (5),
-          realm       [1] RealmIA5,
-          sname       [2] PrincipalNameIA5,
-          enc-part    [3] EncryptedData {
-              EncTicketPart1510, { key-server }, { ku-Ticket }
-          }
-      }
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 82]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      TicketExt       ::= [APPLICATION 4] Signed {
-          [APPLICATION 4] SEQUENCE {
-              tkt-vno     [0] INTEGER (5),
-              realm       [1] RealmExt,
-              sname       [2] PrincipalNameExt,
-              enc-part    [3] EncryptedData {
-                  EncTicketPartExt, { key-server }, { ku-Ticket }
-              },
-              ...,
-              extensions          [4] TicketExtensions OPTIONAL,
-              ...
-          },
-          { key-ticket }, { ku-Ticket-cksum }
-      }
-
-
-      -- Encrypted part of ticket
-      EncTicketPart   ::= CHOICE {
-          rfc1510     EncTicketPart1510,
-          ext         EncTicketPartExt
-      }
-
-
-      EncTicketPart1510       ::= [APPLICATION 3] SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] RealmIA5,
-          cname               [3] PrincipalNameIA5,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 83]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      EncTicketPartExt        ::= [APPLICATION 5] SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] RealmExt,
-          cname               [3] PrincipalNameExt,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...,
-      }
-
-
-      --
-      -- *** Authorization Data
-      --
-
-
-      ADType          ::= TH-id
-
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-          ad-type             [0] ADType,
-          ad-data             [1] OCTET STRING
-      }
-
-
-      ad-if-relevant          ADType ::= int32 : 1
-
-      -- Encapsulates another AuthorizationData.
-      -- Intended for application servers; receiving application servers
-      -- MAY ignore.
-      AD-IF-RELEVANT          ::= AuthorizationData
-
-
-      -- KDC-issued privilege attributes
-      ad-kdcissued            ADType ::= int32 : 4
-
-      AD-KDCIssued            ::= SEQUENCE {
-          ad-checksum [0] ChecksumOf {
-                              AuthorizationData, { key-session },
-                              { ku-ad-KDCIssued-cksum }},
-          i-realm     [1] Realm OPTIONAL,
-          i-sname     [2] PrincipalName OPTIONAL,
-          elements    [3] AuthorizationData
-      }
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 84]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      ad-and-or               ADType ::= int32 : 5
-
-      AD-AND-OR               ::= SEQUENCE {
-          condition-count     [0] Int32,
-          elements            [1] AuthorizationData
-      }
-
-
-      -- KDCs MUST interpret any AuthorizationData wrapped in this.
-      ad-mandatory-for-kdc            ADType ::= int32 : 8
-      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
-
-
-      ad-initial-verified-cas         ADType ::= int32 : 9
-
-
-      TrType                  ::= TH-id -- must be registered
-
-      -- encoded Transited field
-      TransitedEncoding       ::= SEQUENCE {
-          tr-type     [0] TrType,
-          contents    [1] OCTET STRING
-      }
-
-
-      TEType                  ::= TH-id
-
-      -- ticket extensions: for TicketExt only
-      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          te-type             [0] TEType,
-          te-data             [1] OCTET STRING
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 85]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
-
-      TicketFlagsBits ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          may-postdate        (5),
-          postdated           (6),
-          invalid             (7),
-          renewable           (8),
-          initial             (9),
-          pre-authent         (10),
-          hw-authent          (11),
-          transited-policy-checked (12),
-          ok-as-delegate      (13),
-          anonymous           (14),
-          cksummed-ticket     (15)
-      }
-
-
-      --
-      -- *** KDC protocol
-      --
-
-
-      AS-REQ  ::= CHOICE {
-          rfc1510     AS-REQ-1510,
-          ext         AS-REQ-EXT
-      }
-      AS-REQ-1510     ::= [APPLICATION 10] KDC-REQ-1510
-          -- AS-REQ must include client name
-
-      AS-REQ-EXT      ::= [APPLICATION 6] Signed {
-          [APPLICATION 6] KDC-REQ-EXT, { key-client }, { ku-ASReq-cksum }
-      }
-      -- AS-REQ must include client name
-
-
-      TGS-REQ ::= CHOICE {
-          rfc1510     TGS-REQ-1510,
-          ext         TGS-REQ-EXT
-      }
-
-      TGS-REQ-1510    ::= [APPLICATION 12] KDC-REQ-1510
-
-      TGS-REQ-EXT     ::= [APPLICATION 8] Signed {
-          [APPLICATION 8] KDC-REQ-EXT, { key-session }, { ku-TGSReq-cksum }
-      }
-
-
-Yu                         Expires: Apr 2007                   [Page 86]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KDC-REQ-1510    ::= SEQUENCE {
-      -- NOTE: first tag is [1], not [0]
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (  10 -- AS-REQ --
-                                   | 12 -- TGS-REQ -- ),
-          padata      [3] SEQUENCE OF PA-DATA OPTIONAL,
-          req-body    [4] KDC-REQ-BODY-1510
-      }
-
-
-      KDC-REQ-EXT     ::= SEQUENCE {
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (  6 -- AS-REQ --
-                                   | 8 -- TGS-REQ -- ),
-          padata      [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL,
-          req-body    [4] KDC-REQ-BODY-EXT,
-          ...
-      }
-
-
-      KDC-REQ-BODY-1510       ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalNameIA5 OPTIONAL
-          -- Used only in AS-REQ --,
-
-          realm               [2] RealmIA5
-          -- Server's realm; also client's in AS-REQ --,
-
-          sname               [3] PrincipalNameIA5 OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime,
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce32,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --
-      }
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 87]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KDC-REQ-BODY-EXT        ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalName OPTIONAL
-          -- Used only in AS-REQ --,
-
-          realm               [2] Realm
-          -- Server's realm; also client's in AS-REQ --,
-
-          sname               [3] PrincipalName OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime OPTIONAL
-          -- was required in rfc1510;
-          -- still required for compat versions
-          -- of messages --,
-
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --,
-          ...
-          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
-                              LangTag OPTIONAL,
-          ...
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 88]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
-
-      KDCOptionsBits  ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          allow-postdate      (5),
-          postdated           (6),
-          unused7             (7),
-          renewable           (8),
-          unused9             (9),
-          unused10            (10),
-          unused11            (11),
-          unused12            (12),
-          unused13            (13),
-          requestanonymous    (14),
-          canonicalize        (15),
-          disable-transited-check (26),
-          renewable-ok        (27),
-          enc-tkt-in-skey     (28),
-          renew               (30),
-          validate            (31)
-          -- XXX need "need ticket1" flag?
-      }
-
-
-      AS-REP          ::= CHOICE {
-          rfc1510     AS-REP-1510,
-          ext         AS-REP-EXT
-      }
-      AS-REP-1510     ::= [APPLICATION 11] KDC-REP-1510
-      AS-REP-EXT      ::= [APPLICATION 7] Signed {
-          [APPLICATION 7] KDC-REP-EXT,
-          { key-reply }, { ku-ASRep-cksum }
-      }
-
-
-      TGS-REP         ::= CHOICE {
-          rfc1510     TGS-REP-1510,
-          ext         TGS-REP-EXT
-      }
-      TGS-REP-1510    ::= [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart1510 }
-      TGS-REP-EXT     ::= [APPLICATION 9] Signed {
-          [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
-          { key-reply }, { ku-TGSRep-cksum }
-      }
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 89]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KDC-REP-1510 { EncPart } ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
-                                   13 -- TGS.rfc1510 -- ),
-          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
-          crealm      [3] RealmIA5,
-          cname       [4] PrincipalNameIA5,
-          ticket      [5] Ticket,
-
-          enc-part    [6] EncryptedData {
-              EncPart,
-              { key-reply },
-              -- maybe reach into EncryptedData in AS-REP/TGS-REP
-              -- definitions to apply constraints on key usages?
-              { ku-EncASRepPart -- if AS-REP -- |
-                ku-EncTGSRepPart-subkey -- if TGS-REP and
-                                        -- using Authenticator
-                                        -- session key -- |
-                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
-                                         -- subsession key -- }
-          }
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 90]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KDC-REP-EXT { EncPart } ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (7 -- AS-REP.ext -- |
-                                   9 -- TGS-REP.ext -- ),
-          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
-          crealm      [3] RealmExt,
-          cname       [4] PrincipalNameExt,
-          ticket      [5] Ticket,
-
-          enc-part    [6] EncryptedData {
-              EncPart,
-              { key-reply },
-              -- maybe reach into EncryptedData in AS-REP/TGS-REP
-              -- definitions to apply constraints on key usages?
-              { ku-EncASRepPart -- if AS-REP -- |
-                ku-EncTGSRepPart-subkey -- if TGS-REP and
-                                        -- using Authenticator
-                                        -- session key -- |
-                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
-                                         -- subsession key -- }
-          },
-
-          ...,
-          -- In extensible version, KDC signs original request
-          -- to avoid replay attacks against client.
-          req-cksum   [7] ChecksumOf { CHOICE {
-              as-req          AS-REQ,
-              tgs-req         TGS-REQ
-          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
-          lang-tag    [8] LangTag OPTIONAL,
-          ...
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 91]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
-      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
-
-      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
-      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
-
-      EncKDCRepPart1510       ::= SEQUENCE {
-          key                 [0] EncryptionKey,
-          last-req            [1] LastReq,
-          nonce               [2] Nonce32,
-          key-expiration      [3] KerberosTime OPTIONAL,
-          flags               [4] TicketFlags,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          srealm              [9] RealmIA5,
-          sname               [10] PrincipalNameIA5,
-          caddr               [11] HostAddresses OPTIONAL
-      }
-
-      EncKDCRepPartExt        ::= SEQUENCE {
-          key                 [0] EncryptionKey,
-          last-req            [1] LastReq,
-          nonce               [2] Nonce,
-          key-expiration      [3] KerberosTime OPTIONAL,
-          flags               [4] TicketFlags,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          srealm              [9] Realm,
-          sname               [10] PrincipalName,
-          caddr               [11] HostAddresses OPTIONAL,
-          ...
-      }
-
-
-      LRType          ::=     TH-id
-      LastReq         ::=     SEQUENCE OF SEQUENCE {
-          lr-type     [0] LRType,
-          lr-value    [1] KerberosTime
-      }
-
-
-      --
-      -- *** preauth
-      --
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 92]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      PaDataType      ::= TH-id
-      PaDataOID       ::= RELATIVE-OID
-
-      PA-DATA ::= SEQUENCE {
-          -- NOTE: first tag is [1], not [0]
-          padata-type         [1] PaDataType,
-          padata-value        [2] OCTET STRING
-      }
-
-
-      -- AP-REQ authenticating a TGS-REQ
-      pa-tgs-req              PaDataType ::= int32 : 1
-      PA-TGS-REQ              ::= AP-REQ
-
-
-      -- Encrypted timestamp preauth
-      -- Encryption key used is client's long-term key.
-      pa-enc-timestamp        PaDataType ::= int32 : 2
-
-      PA-ENC-TIMESTAMP ::= EncryptedData {
-          PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
-      }
-
-      PA-ENC-TS-ENC           ::= SEQUENCE {
-              patimestamp     [0] KerberosTime -- client's time --,
-              pausec          [1] Microseconds OPTIONAL
-      }
-
-
-      -- Hints returned in AS-REP or KRB-ERROR to help client
-      -- choose a password-derived key, either for preauthentication
-      -- or for decryption of the reply.
-      pa-etype-info           PaDataType ::= int32 : 11
-
-      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
-
-      ETYPE-INFO-ENTRY        ::= SEQUENCE {
-              etype           [0] EType,
-              salt            [1] OCTET STRING OPTIONAL
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 93]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- Similar to etype-info, but with parameters provided for
-      -- the string-to-key function.
-      pa-etype-info2          PaDataType ::= int32 : 19
-
-      ETYPE-INFO2             ::= SEQUENCE (SIZE (1..MAX))
-                                      OF ETYPE-INFO-ENTRY
-
-      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
-              etype           [0] EType,
-              salt            [1] KerberosString OPTIONAL,
-              s2kparams       [2] OCTET STRING OPTIONAL
-      }
-
-
-      -- Obsolescent.  Salt for client long-term key
-      -- Its character encoding is unspecified.
-      pa-pw-salt              PaDataType ::= int32 : 3
-
-      -- The "padata-value" does not encode an ASN.1 type.
-      -- Instead, "padata-value" must consist of the salt string to
-      -- be used by the client, in an unspecified character
-      -- encoding.
-
-
-      -- An extensible AS-REQ may be sent as a padata in a
-      -- non-extensible AS-REQ to allow for backwards compatibility.
-      pa-as-req               PaDataType ::= int32 : 42 -- provisional
-      PA-AS-REQ               ::= AS-REQ (WITH COMPONENTS ext)
-
-
-      --
-      -- *** Session key exchange
-      --
-
-
-      AP-REQ          ::= CHOICE {
-          rfc1510     AP-REQ-1510,
-          ext         AP-REQ-EXT
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 94]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      AP-REQ-1510      ::= [APPLICATION 14] SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket1510,
-          authenticator       [4] EncryptedData {
-              Authenticator1510,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          }
-      }
-
-
-      AP-REQ-EXT      ::= [APPLICATION 18] Signed {
-          [APPLICATION 18] SEQUENCE {
-              pvno                [0] INTEGER (5),
-              msg-type            [1] INTEGER (18),
-              ap-options          [2] APOptions,
-              ticket              [3] Ticket,
-              authenticator       [4] EncryptedData {
-                  AuthenticatorExt,
-                  { key-session },
-                  { ku-APReq-authenticator |
-                    ku-pa-TGSReq-authenticator }
-              },
-              ...,
-              extensions          [5] ApReqExtensions OPTIONAL,
-              lang-tag            [6] SEQUENCE (SIZE (1..MAX))
-                                      OF LangTag OPTIONAL,
-              ...
-          }, { key-session }, { ku-APReq-cksum }
-      }
-
-
-      ApReqExtType    ::= TH-id
-
-      ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          apReqExt-Type       [0] ApReqExtType,
-          apReqExt-Data       [1] OCTET STRING
-      }
-
-
-      APOptions       ::= KerberosFlags { APOptionsBits }
-
-      APOptionsBits ::= BIT STRING {
-          reserved            (0),
-          use-session-key     (1),
-          mutual-required     (2)
-      }
-
-
-Yu                         Expires: Apr 2007                   [Page 95]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- plaintext of authenticator
-      Authenticator1510       ::= [APPLICATION 2] SEQUENCE  {
-          authenticator-vno   [0] INTEGER (5),
-          crealm              [1] RealmIA5,
-          cname               [2] PrincipalNameIA5,
-          cksum               [3] Checksum {{ key-session },
-              { ku-Authenticator-cksum |
-                ku-pa-TGSReq-cksum }} OPTIONAL,
-          cusec               [4] Microseconds,
-          ctime               [5] KerberosTime,
-          subkey              [6] EncryptionKey OPTIONAL,
-          seq-number          [7] SeqNum32 OPTIONAL,
-          authorization-data  [8] AuthorizationData OPTIONAL
-      }
-
-      AuthenticatorExt        ::= [APPLICATION 35] SEQUENCE  {
-          authenticator-vno   [0] INTEGER (5),
-          crealm              [1] RealmExt,
-          cname               [2] PrincipalNameExt,
-          cksum               [3] Checksum {{ key-session },
-              { ku-Authenticator-cksum |
-                ku-pa-TGSReq-cksum }} OPTIONAL,
-          cusec               [4] Microseconds,
-          ctime               [5] KerberosTime,
-          subkey              [6] EncryptionKey OPTIONAL,
-          seq-number          [7] SeqNum OPTIONAL,
-          authorization-data  [8] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-      AP-REP          ::= CHOICE {
-          rfc1510     AP-REP-1510,
-          ext         AP-REP-EXT
-      }
-
-
-      AP-REP-1510     ::= [APPLICATION 15] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (15),
-          enc-part    [2] EncryptedData {
-              EncApRepPart1510,
-              { key-session | key-subsession }, { ku-EncAPRepPart }}
-      }
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 96]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      AP-REP-EXT      ::= [APPLICATION 19] Signed {
-          [APPLICATION 19] SEQUENCE {
-              pvno        [0] INTEGER (5),
-              msg-type    [1] INTEGER (19),
-              enc-part    [2] EncryptedData {
-                  EncAPRepPartExt,
-                  { key-session | key-subsession }, { ku-EncAPRepPart }},
-              ...,
-              extensions          [3] ApRepExtensions OPTIONAL,
-              ...
-          }, { key-session | key-subsession }, { ku-APRep-cksum }
-      }
-
-
-      ApRepExtType    ::= TH-id
-
-      ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          apRepExt-Type       [0] ApRepExtType,
-          apRepExt-Data       [1] OCTET STRING
-      }
-
-
-      EncAPRepPart    ::= CHOICE {
-          rfc1510     EncAPRepPart1510,
-          ext         EncAPRepPartExt
-      }
-
-
-      EncAPRepPart1510        ::= [APPLICATION 27] SEQUENCE {
-          ctime               [0] KerberosTime,
-          cusec               [1] Microseconds,
-          subkey              [2] EncryptionKey OPTIONAL,
-          seq-number          [3] SeqNum32 OPTIONAL
-      }
-
-
-      EncAPRepPartExt         ::= [APPLICATION 31] SEQUENCE {
-          ctime               [0] KerberosTime,
-          cusec               [1] Microseconds,
-          subkey              [2] EncryptionKey OPTIONAL,
-          seq-number          [3] SeqNum OPTIONAL,
-          ...,
-          authorization-data  [4] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-      --
-      -- *** Application messages
-      --
-
-
-Yu                         Expires: Apr 2007                   [Page 97]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KRB-SAFE        ::= CHOICE {
-          rfc1510     KRB-SAFE-1510,
-          ext         KRB-SAFE-EXT
-      }
-
-
-      KRB-SAFE-1510   ::= [APPLICATION 20] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (20),
-          safe-body   [2] KRB-SAFE-BODY,
-          cksum       [3] ChecksumOf {
-              KRB-SAFE-BODY,
-              { key-session | key-subsession }, { ku-KrbSafe-cksum }}
-      }
-
-
-      -- Has safe-body optional to allow for GSS-MIC type functionality
-      KRB-SAFE-EXT    ::= [APPLICATION 34] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (20),
-          safe-body   [2] KRB-SAFE-BODY OPTIONAL,
-          cksum       [3] ChecksumOf {
-              KRB-SAFE-BODY,
-              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
-          ...
-      }
-
-
-      KRB-SAFE-BODY   ::= SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress,
-          r-address   [5] HostAddress OPTIONAL,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (21),
-          enc-part    [3] EncryptedData {
-              EncKrbPrivPart,
-              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
-          ...
-      }
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 98]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress -- sender's addr --,
-          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-      KRB-CRED        ::= CHOICE {
-          rfc1510     KRB-CRED-1510,
-          ext         KRB-CRED-EXT
-
-      }
-
-
-      KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (22),
-          tickets     [2] SEQUENCE OF Ticket,
-          enc-part    [3] EncryptedData {
-              EncKrbCredPart,
-              { key-session | key-subsession }, { ku-EncKrbCredPart }}
-      }
-
-
-      KRB-CRED-EXT    ::= [APPLICATION 24] Signed {
-          [APPLICATION 24] SEQUENCE {
-              pvno        [0] INTEGER (5),
-              msg-type    [1] INTEGER (24),
-              tickets     [2] SEQUENCE OF Ticket,
-              enc-part    [3] EncryptedData {
-                  EncKrbCredPart,
-                  { key-session | key-subsession }, { ku-EncKrbCredPart }},
-              ...
-          }, { key-session | key-subsession }, { ku-KrbCred-cksum }
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                   [Page 99]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-          ticket-info [0] SEQUENCE OF KrbCredInfo,
-          nonce       [1] Nonce OPTIONAL,
-          timestamp   [2] KerberosTime OPTIONAL,
-          usec        [3] Microseconds OPTIONAL,
-          s-address   [4] HostAddress OPTIONAL,
-          r-address   [5] HostAddress OPTIONAL
-      }
-
-
-      KrbCredInfo     ::= SEQUENCE {
-          key         [0] EncryptionKey,
-          prealm      [1] Realm OPTIONAL,
-          pname       [2] PrincipalName OPTIONAL,
-          flags       [3] TicketFlags OPTIONAL,
-          authtime    [4] KerberosTime OPTIONAL,
-          starttime   [5] KerberosTime OPTIONAL,
-          endtime     [6] KerberosTime OPTIONAL,
-          renew-till  [7] KerberosTime OPTIONAL,
-          srealm      [8] Realm OPTIONAL,
-          sname       [9] PrincipalName OPTIONAL,
-          caddr       [10] HostAddresses OPTIONAL
-      }
-
-
-      TGT-REQ         ::= [APPLICATION 16] SEQUENCE {
-          pvno            [0] INTEGER (5),
-          msg-type        [1] INTEGER (16),
-          sname           [2] PrincipalName OPTIONAL,
-          srealm          [3] Realm OPTIONAL,
-          ...
-      }
-
-
-      --
-      -- *** Error messages
-      --
-
-
-      ErrCode ::= Int32
-
-      KRB-ERROR       ::= CHOICE {
-          rfc1510     KRB-ERROR-1510,
-          ext         KRB-ERROR-EXT
-      }
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                  [Page 100]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      KRB-ERROR-1510 ::= [APPLICATION 30] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (30),
-          ctime       [2] KerberosTime OPTIONAL,
-          cusec       [3] Microseconds OPTIONAL,
-          stime       [4] KerberosTime,
-          susec       [5] Microseconds,
-          error-code  [6] ErrCode,
-          crealm      [7] RealmIA5 OPTIONAL,
-          cname       [8] PrincipalNameIA5 OPTIONAL,
-          realm       [9] RealmIA5 -- Correct realm --,
-          sname       [10] PrincipalNameIA5 -- Correct name --,
-          e-text      [11] KerberosString OPTIONAL,
-          e-data      [12] OCTET STRING OPTIONAL
-      }
-
-
-      KRB-ERROR-EXT ::= [APPLICATION 23] Signed {
-          [APPLICATION 23] SEQUENCE{
-              pvno        [0] INTEGER (5),
-              msg-type    [1] INTEGER (23),
-              ctime       [2] KerberosTime OPTIONAL,
-              cusec       [3] Microseconds OPTIONAL,
-              stime       [4] KerberosTime,
-              susec       [5] Microseconds,
-              error-code  [6] ErrCode,
-              crealm      [7] Realm OPTIONAL,
-              cname       [8] PrincipalName OPTIONAL,
-              realm       [9] Realm -- Correct realm --,
-              sname       [10] PrincipalName -- Correct name --,
-              e-text      [11] KerberosString OPTIONAL,
-              e-data      [12] OCTET STRING OPTIONAL,
-              ...,
-              typed-data          [13] TYPED-DATA OPTIONAL,
-              nonce               [14] Nonce OPTIONAL,
-              lang-tag            [15] LangTag OPTIONAL,
-              ...
-          }, { }, { ku-KrbError-cksum }
-      }
-
-
-      METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-
-      TDType ::= TH-id
-
-      TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-          data-type   [0] TDType,
-          data-value  [1] OCTET STRING OPTIONAL
-      }
-
-
-Yu                         Expires: Apr 2007                  [Page 101]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      td-dh-parameters        TDType ::= int32 : 109
-
-
-      --
-      -- *** Error codes
-      --
-
-      -- No error
-      kdc-err-none                          ErrCode ::= 0
-      -- Client's entry in database has expired
-      kdc-err-name-exp                      ErrCode ::= 1
-      -- Server's entry in database has expired
-      kdc-err-service-exp                   ErrCode ::= 2
-      -- Requested protocol version number not supported
-      kdc-err-bad-pvno                      ErrCode ::= 3
-      -- Client's key encrypted in old master key
-      kdc-err-c-old-mast-kvno               ErrCode ::= 4
-      -- Server's key encrypted in old master key
-      kdc-err-s-old-mast-kvno               ErrCode ::= 5
-      -- Client not found in Kerberos database
-      kdc-err-c-principal-unknown           ErrCode ::= 6
-      -- Server not found in Kerberos database
-      kdc-err-s-principal-unknown           ErrCode ::= 7
-      -- Multiple principal entries in database
-      kdc-err-principal-not-unique          ErrCode ::= 8
-      -- The client or server has a null key
-      kdc-err-null-key                      ErrCode ::= 9
-      -- Ticket not eligible for postdating
-      kdc-err-cannot-postdate               ErrCode ::= 10
-      -- Requested start time is later than end time
-      kdc-err-never-valid                   ErrCode ::= 11
-      -- KDC policy rejects request
-      kdc-err-policy                        ErrCode ::= 12
-      -- KDC cannot accommodate requested option
-      kdc-err-badoption                     ErrCode ::= 13
-      -- KDC has no support for encryption type
-      kdc-err-etype-nosupp                  ErrCode ::= 14
-      -- KDC has no support for checksum type
-      kdc-err-sumtype-nosupp                ErrCode ::= 15
-      -- KDC has no support for padata type
-      kdc-err-padata-type-nosupp            ErrCode ::= 16
-      -- KDC has no support for transited type
-      kdc-err-trtype-nosupp                 ErrCode ::= 17
-      -- Clients credentials have been revoked
-      kdc-err-client-revoked                ErrCode ::= 18
-      -- Credentials for server have been revoked
-      kdc-err-service-revoked               ErrCode ::= 19
-      -- TGT has been revoked
-      kdc-err-tgt-revoked                   ErrCode ::= 20
-
-
-
-Yu                         Expires: Apr 2007                  [Page 102]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- Client not yet valid - try again later
-      kdc-err-client-notyet                 ErrCode ::= 21
-      -- Server not yet valid - try again later
-      kdc-err-service-notyet                ErrCode ::= 22
-      -- Password has expired - change password to reset
-      kdc-err-key-expired                   ErrCode ::= 23
-      -- Pre-authentication information was invalid
-      kdc-err-preauth-failed                ErrCode ::= 24
-      -- Additional pre-authenticationrequired
-      kdc-err-preauth-required              ErrCode ::= 25
-      -- Requested server and ticket don't match
-      kdc-err-server-nomatch                ErrCode ::= 26
-      -- Server principal valid for user2user only
-      kdc-err-must-use-user2user            ErrCode ::= 27
-      -- KDC Policy rejects transited path
-      kdc-err-path-not-accpeted             ErrCode ::= 28
-      -- A service is not available
-      kdc-err-svc-unavailable               ErrCode ::= 29
-      -- Integrity check on decrypted field failed
-      krb-ap-err-bad-integrity              ErrCode ::= 31
-      -- Ticket expired
-      krb-ap-err-tkt-expired                ErrCode ::= 32
-      -- Ticket not yet valid
-      krb-ap-err-tkt-nyv                    ErrCode ::= 33
-      -- Request is a replay
-      krb-ap-err-repeat                     ErrCode ::= 34
-      -- The ticket isn't for us
-      krb-ap-err-not-us                     ErrCode ::= 35
-      -- Ticket and authenticator don't match
-      krb-ap-err-badmatch                   ErrCode ::= 36
-      -- Clock skew too great
-      krb-ap-err-skew                       ErrCode ::= 37
-      -- Incorrect net address
-      krb-ap-err-badaddr                    ErrCode ::= 38
-      -- Protocol version mismatch
-      krb-ap-err-badversion                 ErrCode ::= 39
-      -- Invalid msg type
-      krb-ap-err-msg-type                   ErrCode ::= 40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                  [Page 103]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- Message stream modified
-      krb-ap-err-modified                   ErrCode ::= 41
-      -- Message out of order
-      krb-ap-err-badorder                   ErrCode ::= 42
-      -- Specified version of key is not available
-      krb-ap-err-badkeyver                  ErrCode ::= 44
-      -- Service key not available
-      krb-ap-err-nokey                      ErrCode ::= 45
-      -- Mutual authentication failed
-      krb-ap-err-mut-fail                   ErrCode ::= 46
-      -- Incorrect message direction
-      krb-ap-err-baddirection               ErrCode ::= 47
-      -- Alternative authentication method required
-      krb-ap-err-method                     ErrCode ::= 48
-      -- Incorrect sequence number in message
-      krb-ap-err-badseq                     ErrCode ::= 49
-      -- Inappropriate type of checksum in message
-      krb-ap-err-inapp-cksum                ErrCode ::= 50
-      -- Policy rejects transited path
-      krb-ap-path-not-accepted              ErrCode ::= 51
-      -- Response too big for UDP, retry with TCP
-      krb-err-response-too-big              ErrCode ::= 52
-      -- Generic error (description in e-text)
-      krb-err-generic                       ErrCode ::= 60
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                  [Page 104]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-      -- Field is too long for this implementation
-      krb-err-field-toolong                 ErrCode ::= 61
-      -- Reserved for PKINIT
-      kdc-error-client-not-trusted          ErrCode ::= 62
-      -- Reserved for PKINIT
-      kdc-error-kdc-not-trusted             ErrCode ::= 63
-      -- Reserved for PKINIT
-      kdc-error-invalid-sig                 ErrCode ::= 64
-      -- Reserved for PKINIT
-      kdc-err-key-too-weak                  ErrCode ::= 65
-      -- Reserved for PKINIT
-      kdc-err-certificate-mismatch          ErrCode ::= 66
-      -- No TGT available to validate USER-TO-USER
-      krb-ap-err-no-tgt                     ErrCode ::= 67
-      -- USER-TO-USER TGT issued different KDC
-      kdc-err-wrong-realm                   ErrCode ::= 68
-      -- Ticket must be for USER-TO-USER
-      krb-ap-err-user-to-user-required      ErrCode ::= 69
-      -- Reserved for PKINIT
-      kdc-err-cant-verify-certificate       ErrCode ::= 70
-      -- Reserved for PKINIT
-      kdc-err-invalid-certificate           ErrCode ::= 71
-      -- Reserved for PKINIT
-      kdc-err-revoked-certificate           ErrCode ::= 72
-      -- Reserved for PKINIT
-      kdc-err-revocation-status-unknown     ErrCode ::= 73
-      -- Reserved for PKINIT
-      kdc-err-revocation-status-unavailable ErrCode ::= 74
-      -- Reserved for PKINIT
-      kdc-err-client-name-mismatch          ErrCode ::= 75
-      --  Reserved for PKINIT
-      kdc-err-kdc-name-mismatch             ErrCode ::= 76
-      --  Reserved for PKINIT
-      kdc-err-inconsistent-key-purpose      ErrCode ::= 77
-      --  Reserved for PKINIT
-      kdc-err-digest-in-cert-not-accepted   ErrCode ::= 78
-      --  Reserved for PKINIT
-      kdc-err-pa-checksum-must-be-included  ErrCode ::= 79
-      --  Reserved for PKINIT
-      kdc-err-digest-in-signed-data-not-accepted ErrCode ::= 80
-      --  Reserved for PKINIT
-      kdc-err-public-key-encryption-not-supported ErrCode ::= 81
-
-
-      END
-
-
-B.  Kerberos and Character Encodings (Informative)
-
-   [adapted from KCLAR 5.2.1]
-
-
-Yu                         Expires: Apr 2007                  [Page 105]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   The original specification of the Kerberos protocol in RFC 1510 uses
-   GeneralString in numerous places for human-readable string data.
-   Historical implementations of Kerberos cannot utilize the full power
-   of GeneralString.  This ASN.1 type requires the use of designation
-   and invocation escape sequences as specified in ISO 2022 | ECMA-35
-   [ISO2022] to switch character sets, and the default character set
-   that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
-   International Reference Version (IRV) (aka U.S. ASCII), which mostly
-   works.
-
-   ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3)
-   and two Control-function code elements (C0..C1).  DER previously
-   [X690-1997] prohibited the designation of character sets as any but
-   the G0 and C0 sets.  This had the side effect of prohibiting the use
-   of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any
-   other character-sets that utilize a 96-character set, since it is
-   prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code
-   element.  Recent revisions to the ASN.1 standards resolve this
-   contradiction.
-
-   In practice, many implementations treat RFC 1510 GeneralStrings as if
-   they were 8-bit strings of whichever character set the implementation
-   defaults to, without regard for correct usage of character-set
-   designation escape sequences.  The default character set is often
-   determined by the current user's operating system dependent locale.
-   At least one major implementation places unescaped UTF-8 encoded
-   Unicode characters in the GeneralString.  This failure to conform to
-   the GeneralString specifications results in interoperability issues
-   when conflicting character encodings are utilized by the Kerberos
-   clients, services, and KDC.
-
-   This unfortunate situation is the result of improper documentation of
-   the restrictions of the ASN.1 GeneralString type in prior Kerberos
-   specifications.
-
-   [the following should probably be rewritten and moved into the
-   principal name section]
-
-   For compatibility, implementations MAY choose to accept GeneralString
-   values that contain characters other than those permitted by
-   IA5String, but they should be aware that character set designation
-   codes will likely be absent, and that the encoding should probably be
-   treated as locale-specific in almost every way.  Implementations MAY
-   also choose to emit GeneralString values that are beyond those
-   permitted by IA5String, but should be aware that doing so is
-   extraordinarily risky from an interoperability perspective.
-
-   Some existing implementations use GeneralString to encode unescaped
-   locale-specific characters.  This is a violation of the ASN.1
-   standard.  Most of these implementations encode US-ASCII in the left-
-   hand half, so as long the implementation transmits only US-ASCII, the
-
-Yu                         Expires: Apr 2007                  [Page 106]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   ASN.1 standard is not violated in this regard.  As soon as such an
-   implementation encodes unescaped locale-specific characters with the
-   high bit set, it violates the ASN.1 standard.
-
-   Other implementations have been known to use GeneralString to contain
-   a UTF-8 encoding.  This also violates the ASN.1 standard, since UTF-8
-   is a different encoding, not a 94 or 96 character "G" set as defined
-   by ISO 2022.  It is believed that these implementations do not even
-   use the ISO 2022 escape sequence to change the character encoding.
-   Even if implementations were to announce the change of encoding by
-   using that escape sequence, the ASN.1 standard prohibits the use of
-   any escape sequences other than those used to designate/invoke "G" or
-   "C" sets allowed by GeneralString.
-
-C.  Kerberos History (Informative)
-
-   [Adapted from KCLAR "BACKGROUND"]
-
-   The Kerberos model is based in part on Needham and Schroeder's
-   trusted third-party authentication protocol [NS78] and on
-   modifications suggested by Denning and Sacco [DS81].  The original
-   design and implementation of Kerberos Versions 1 through 4 was the
-   work of two former Project Athena staff members, Steve Miller of
-   Digital Equipment Corporation and Clifford Neuman (now at the
-   Information Sciences Institute of the University of Southern
-   California), along with Jerome Saltzer, Technical Director of Project
-   Athena, and Jeffrey Schiller, MIT Campus Network Manager.  Many other
-   members of Project Athena have also contributed to the work on
-   Kerberos.
-
-   Version 5 of the Kerberos protocol (described in this document) has
-   evolved from Version 4 based on new requirements and desires for
-   features not available in Version 4.  The design of Version 5 of the
-   Kerberos protocol was led by Clifford Neuman and John Kohl with much
-   input from the community.  The development of the MIT reference
-   implementation was led at MIT by John Kohl and Theodore Ts'o, with
-   help and contributed code from many others.  Since RFC1510 was
-   issued, extensions and revisions to the protocol have been proposed
-   by many individuals.  Some of these proposals are reflected in this
-   document.  Where such changes involved significant effort, the
-   document cites the contribution of the proposer.
-
-   Reference implementations of both version 4 and version 5 of Kerberos
-   are publicly available and commercial implementations have been
-   developed and are widely used.  Details on the differences between
-   Kerberos Versions 4 and 5 can be found in [KNT94].
-
-D.  Notational Differences from [KCLAR]
-
-   [ possible point for discussion ]
-
-
-Yu                         Expires: Apr 2007                  [Page 107]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   [KCLAR] uses notational conventions slightly different from this
-   document.  As a derivative of RFC 1510, the text of [KCLAR] uses C-
-   language style identifier names for defined values.  In ASN.1
-   notation, identifiers referencing defined values must begin with a
-   lowercase letter and contain hyphen (-) characters rather than
-   underscore (_) characters, while identifiers referencing types begin
-   with an uppercase letter.  [KCLAR] and RFC 1510 use all-uppercase
-   identifiers with underscores to identify defined values.  This has
-   the potential to create confusion, but neither document defines
-   values using actual ASN.1 value-assignment notation.
-
-   It is debatable whether it is advantageous to write all identifier
-   names (regardless of their ASN.1 token type) in all-uppercase letters
-   for the purpose of emphasis in running text.  The alternative is to
-   use double-quote characters (") when ambiguity is possible.
-
-Normative References
-
-   [ISO646]
-        "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
-
-   [ISO2022]
-        "Information technology -- Character code structure and
-        extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
-
-   [KCRYPTO]
-        K. Raeburn, "Encryption and Checksum Specifications for Kerberos
-        5", draft-ietf-krb-wg-crypto-07.txt, work in progress.
-
-   [RFC2119]
-        S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
-        Requirement Levels", March 1997.
-
-   [RFC3660]
-        H. Alvestrand, "Tags for the Identification of Languages",
-        RFC 3660, January 2001.
-
-   [SASLPREP]
-        Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names
-        and passwords", draft-ietf-sasl-saslprep-10.txt, work in
-        progress.
-
-   [X680]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Specification of basic notation", ITU-T Recommendation X.680
-        (2002) | ISO/IEC 8824-1:2002.
-
-   [X682]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Constraint specification", ITU-T Recommendation X.682 (2002) |
-        ISO/IEC 8824-3:2002.
-
-Yu                         Expires: Apr 2007                  [Page 108]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   [X683]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Parameterization of ASN.1 specifications", ITU-T Recommendation
-        X.683 (2002) | ISO/IEC 8824-4:2002.
-
-   [X690]
-        "Information technology -- ASN.1 encoding Rules: Specification
-        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
-        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
-        X.690 (2002) | ISO/IEC 8825-1:2002.
-
-Informative References
-
-   [DS81]
-        Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
-        Distribution Protocols," Communications of the ACM, Vol. 24(8),
-        pp. 533-536 (August 1981).
-
-   [Dub00]
-        Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
-        Systems", Elsevier-Morgan Kaufmann, 2000.
-        <http://www.oss.com/asn1/dubuisson.html>
-
-   [ISO8859-1]
-        "Information technology -- 8-bit single-byte coded graphic
-        character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859-
-        1:1998.
-
-   [KCLAR]
-        Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos
-        Network Authentication Service (V5)", draft-ietf-krb-wg-
-        kerberos-clarifications-07.txt, work in progress.
-
-   [KNT94]
-        John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
-        Evolution of the Kerberos Authentication System".  In
-        Distributed Open Systems, pages 78-94.  IEEE Computer Society
-        Press, 1994.
-
-   [Lar96]
-        John Larmouth, "Understanding OSI", International Thomson
-        Computer Press, 1996.
-        <http://www.isi.salford.ac.uk/books/osi.html>
-
-   [Lar99]
-        John Larmouth, "ASN.1 Complete",  Elsevier-Morgan Kaufmann,
-        1999.  <http://www.oss.com/asn1/larmouth.html>
-
-   [NS78]
-        Roger M. Needham and Michael D. Schroeder, "Using Encryption for
-        Authentication in Large Networks of Computers", Communications
-
-Yu                         Expires: Apr 2007                  [Page 109]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-        of the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
-
-   [RFC1510]
-        J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
-        Service (v5)", RFC1510, September 1993, Status: Proposed
-        Standard.
-
-   [RFC1964]
-        J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
-        June 1996, Status: Proposed Standard.
-
-   [X690-2002]
-        "Information technology -- ASN.1 encoding rules: Specification
-        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
-        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
-        X.690 (2002) | ISO/IEC 8825-1:2002.
-
-Author's Address
-
-   Tom Yu
-   77 Massachusetts Ave
-   Cambridge, MA 02139
-   USA
-   tlyu@mit.edu
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-
-Yu                         Expires: Apr 2007                  [Page 110]
-
-Internet-Draft               rfc1510ter-03                   23 Oct 2006
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2007                  [Page 111]
-
-
diff --git a/doc/standardisation/draft-ietf-krb-wg-tcp-expansion-00.txt b/doc/standardisation/draft-ietf-krb-wg-tcp-expansion-00.txt
deleted file mode 100644
index abb6787b2..000000000
--- a/doc/standardisation/draft-ietf-krb-wg-tcp-expansion-00.txt
+++ /dev/null
@@ -1,392 +0,0 @@
-
-
-
-Network Working Group                                       S. Josefsson
-Internet-Draft                                                       SJD
-Updates: 4120 (if approved)                                 May 10, 2006
-Expires: November 11, 2006
-
-
-Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over
-                                  TCP
-                   draft-ietf-krb-wg-tcp-expansion-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on November 11, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes an extensibility mechanism for the Kerberos
-   v5 protocol when used over TCP transports.
-
-
-
-
-
-
-
-
-Josefsson               Expires November 11, 2006               [Page 1]
-
-Internet-Draft          Kerberos V5 TCP extension               May 2006
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions used in this document . . . . . . . . . . . . . . . 3
-   3.  Extension Mechanism for TCP transport . . . . . . . . . . . . . 3
-   4.  Interoperability Consideration  . . . . . . . . . . . . . . . . 4
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
-   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
-   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
-   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
-   Appendix A.  Copying conditions . . . . . . . . . . . . . . . . . . 5
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires November 11, 2006               [Page 2]
-
-Internet-Draft          Kerberos V5 TCP extension               May 2006
-
-
-1.  Introduction
-
-   The Kerberos 5 [3] specification, in section 7.2.2, reserve the high
-   order bit in the initial length field for TCP transport for future
-   expansion.  This document update [3] to describe the behaviour when
-   that bit is set.  This mechanism is intended for extensions that are
-   specific for the TCP transport.
-
-
-2.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [1].
-
-
-3.  Extension Mechanism for TCP transport
-
-   The reserved high bit of the request length field is used to signal
-   the use of this extension mechanism.  When the reserved high bit is
-   set, the remaining 31 bits of the initial 4 octets are interpreted as
-   a bitmap.  Each bit in the bitmask can be used to request a
-   particular extension.  The 31 bits form the "extension bitmask".  It
-   is expected that other documents will describe the details associated
-   with particular bits.
-
-   A 4-octet value with only the high bit set, and thus the extension
-   bitmask all zeros, is called a PROBE.  A client may send a probe to
-   find out which extensions a KDC support.  A client may also set
-   particular bits in the extension bitmask directly, if it does not
-   need to query the KDC for available extensions before deciding which
-   extension to request.
-
-   If a KDC receive a PROBE, or if a KDC does not support all extensions
-   corresponding to set bits in the extension bitmask, the KDC MUST
-   return 4 octets with the high bit set, and with the remaining bitmask
-   indicate which extensions it supports.  The KDC SHOULD NOT close the
-   connection, and SHOULD wait for the client to then send a second
-   4-octet value, with the high bit set and the remaining bits as the
-   bitmask, to request a particular extension.  If the second 4-octet
-   value is a PROBE or an unsupported extension, the KDC MUST close the
-   connection.  This is used by the client to shutdown a session when
-   the KDC did not support a, by the client, required extension.
-
-   Resource avaibility considerations may influence whether, and for how
-   long, the KDC will wait for the client to send requests.
-
-   The behaviour when more than one non-high bit is set depends on the
-
-
-
-Josefsson               Expires November 11, 2006               [Page 3]
-
-Internet-Draft          Kerberos V5 TCP extension               May 2006
-
-
-   particular extension mechanisms.  If a requested extension (bit X)
-   does not specify how it interact with another requested extensions
-   (bit Y), the KDC MUST treat the request as a PROBE or unsupported
-   extension, and proceed as above.
-
-   Each extension MUST describe the structure of protocol data beyond
-   the length field, and the behaviour of the client and KDC.  If an
-   extension mechanism reserve multiple bits, it MUST describe how they
-   interact.
-
-
-4.  Interoperability Consideration
-
-   Implementations with support for TCP that do not claim to conform to
-   RFC 4120 may not handle the high bit correctly.  Behaviour may
-   include closing the TCP connection without any response, and logging
-   an error message in the KDC log.  When this was written, this problem
-   existed in modern versions of popular implementations.
-   Implementations experiencing trouble getting the expected responses
-   from a server SHOULD assume that it does not support this extension
-   mechanism.  Clients MAY remember this semi-permanently, to avoid
-   excessive logging in the server.  Care should be taken to avoid
-   unexpected behaviour for the user when the KDC is eventually
-   upgraded.  Implementations MAY also provide a way to enable and
-   disable this extension on a per-realm basis.  How to handle these
-   backwards compatibility quirks are in general left unspecified.
-
-
-5.  Security Considerations
-
-   Because the initial length field is not protected, it is possible for
-   an active attacker (i.e., one that is able to modify traffic between
-   the client and the KDC) to make it appear to the client that the
-   server does not support this extension mechanism.  Client and KDC
-   policies can be used to reject connections that does not use any
-   expansion.
-
-
-6.  IANA Considerations
-
-   IANA needs to create a new registry for "Kerberos 5 TCP Extensions".
-   The initial contents of this registry should be:
-
-   [[RFC Editor: Replace xxxx below with the number of this RFC.]]
-
-   Bit #         Meaning                             Reference
-   -----         -------                             ---------
-   0..29         AVAILABLE for registration.
-
-
-
-Josefsson               Expires November 11, 2006               [Page 4]
-
-Internet-Draft          Kerberos V5 TCP extension               May 2006
-
-
-   30            RESERVED.                           RFC XXXX
-
-   IANA will register values 0 to 29 after IESG Approval, as defined in
-   BCP 64 [2].  Assigning value 30 requires a Standards Action that
-   update or obsolete this document.
-
-
-7.  Acknowledgements
-
-   Thanks to Andrew Bartlett who pointed out that some implementations
-   (MIT Kerberos and Heimdal) did not follow RFC 4120 properly with
-   regards to the high bit, which resulted in an Interoperability
-   Consideration.
-
-   Nicolas Williams and Jeffrey Hutzelman provided comments that
-   improved the document.
-
-8.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [3]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
-        Network Authentication Service (V5)", RFC 4120, July 2005.
-
-
-Appendix A.  Copying conditions
-
-   Copyright (C) 2005, 2006 Simon Josefsson
-
-   Regarding this entire document or any portion of it, the author makes
-   no guarantees and is not responsible for any damage resulting from
-   its use.  The author grants irrevocable permission to anyone to use,
-   modify, and distribute it in any way that does not diminish the
-   rights of anyone else to use, modify, and distribute it, provided
-   that redistributed derivative works do not contain misleading author
-   or version information.  Derivative works need not be licensed under
-   similar terms.
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires November 11, 2006               [Page 5]
-
-Internet-Draft          Kerberos V5 TCP extension               May 2006
-
-
-Author's Address
-
-   Simon Josefsson
-   SJD
-
-   Email: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires November 11, 2006               [Page 6]
-
-Internet-Draft          Kerberos V5 TCP extension               May 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Josefsson               Expires November 11, 2006               [Page 7]
-
diff --git a/doc/standardisation/draft-ietf-sasl-gs2-11.txt b/doc/standardisation/draft-ietf-sasl-gs2-11.txt
deleted file mode 100644
index f9316e6c4..000000000
--- a/doc/standardisation/draft-ietf-sasl-gs2-11.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-
-Network Working Group                                       S. Josefsson
-Internet-Draft                                                    SJD AB
-Intended status: Standards Track                             N. Williams
-Expires: September 24, 2009                             Sun Microsystems
-                                                          March 23, 2009
-
-
-       Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
-                         draft-ietf-sasl-gs2-11
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.  This document may contain material
-   from IETF Documents or IETF Contributions published or made publicly
-   available before November 10, 2008.  The person(s) controlling the
-   copyright in some of this material may not have granted the IETF
-   Trust the right to allow modifications of such material outside the
-   IETF Standards Process.  Without obtaining an adequate license from
-   the person(s) controlling the copyright in such materials, this
-   document may not be modified outside the IETF Standards Process, and
-   derivative works of it may not be created outside the IETF Standards
-   Process, except to format it for publication as an RFC or to
-   translate it into languages other than English.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 24, 2009.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009               [Page 1]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Abstract
-
-   This document describes how to use a Generic Security Service
-   Application Program Interface (GSS-API) mechanism in the the Simple
-   Authentication and Security Layer (SASL) framework.  This is done by
-   defining a new SASL mechanism family, called GS2.  This mechanism
-   family offers a number of improvements over the previous "SASL/
-   GSSAPI" mechanism: it is more general, uses fewer messages for the
-   authentication phase in some cases, and supports negotiable use of
-   channel binding.  Only GSS-API mechanisms that support channel
-   binding are supported.
-
-   See <http://josefsson.org/sasl-gs2-*/> for more information.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009               [Page 2]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Conventions used in this document  . . . . . . . . . . . . . .  5
-   3.  Mechanism name . . . . . . . . . . . . . . . . . . . . . . . .  5
-     3.1.  Generating SASL mechanism names from GSS-API OIDs  . . . .  5
-     3.2.  Computing mechanism names manually . . . . . . . . . . . .  5
-     3.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  6
-   4.  SASL Authentication Exchange Message Format  . . . . . . . . .  7
-     4.1.  SASL Messages  . . . . . . . . . . . . . . . . . . . . . .  7
-   5.  Channel Bindings . . . . . . . . . . . . . . . . . . . . . . .  9
-   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-   7.  Authentication Conditions  . . . . . . . . . . . . . . . . . . 11
-   8.  GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 11
-   9.  Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   10. GSS_Mechanism_SASLname call  . . . . . . . . . . . . . . . . . 11
-     10.1. gss_mechanism_saslname . . . . . . . . . . . . . . . . . . 13
-   11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 13
-     11.1. gss_inquire_mech_for_saslname  . . . . . . . . . . . . . . 15
-   12. Security Layers  . . . . . . . . . . . . . . . . . . . . . . . 15
-   13. Interoperability with the SASL "GSSAPI" mechanism  . . . . . . 16
-     13.1. The interoperability problem . . . . . . . . . . . . . . . 16
-     13.2. Resolving the problem  . . . . . . . . . . . . . . . . . . 16
-     13.3. Additional Recommendations . . . . . . . . . . . . . . . . 16
-   14. Mechanisms that negotiate other mechanisms . . . . . . . . . . 17
-     14.1. The interoperability problem . . . . . . . . . . . . . . . 17
-     14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 17
-     14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 17
-   15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
-   16. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
-   17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
-   18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
-     18.1. Normative References . . . . . . . . . . . . . . . . . . . 19
-     18.2. Informative References . . . . . . . . . . . . . . . . . . 20
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009               [Page 3]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-1.  Introduction
-
-   Generic Security Service Application Program Interface (GSS-API)
-   [RFC2743] is a framework that provides security services to
-   applications using a variety of authentication "mechanisms".  Simple
-   Authentication and Security Layer (SASL) [RFC4422] is a framework to
-   provide authentication and "security layers" for connection based
-   protocols, also using a variety of mechanisms.  This document
-   describes how to use a GSS-API mechanism as though it were a SASL
-   mechanism.  This facility is called "GS2" -- a moniker that indicates
-   that this is the second GSS-API->SASL mechanism bridge.  The original
-   GSS-API->SASL mechanism bridge was specified by [RFC2222], now
-   [RFC4752]; we shall sometimes refer to the original bridge as "GS1"
-   in this document.
-
-   All GSS-API mechanisms are implicitly registered for use within SASL
-   by this specification.  The SASL mechanisms defined in this document
-   are known as the "GS2 family of mechanisms".
-
-   The GS1 bridge failed to gain wide deployment for any GSS-API
-   mechanism other than The "Kerberos V GSS-API mechanism" [RFC1964]
-   [RFC4121], and has a number of problems that lead us to desire a new
-   bridge.  Specifically: a) GS1 was not round-trip optimized, b) GS1
-   did not support channel binding [RFC5056].  These problems and the
-   opportunity to create the next SASL password-based mechanism, SCRAM
-   [I-D.newman-auth-scram], as a GSS-API mechanism used by SASL
-   applications via GS2, provide the motivation for GS2.
-
-   In particular, the current consensus of the SASL community appears to
-   be that SASL "security layers" (i.e., confidentiality and integrity
-   protection of application data after authentication) are too complex
-   and, since SASL applications tend to have an option to run over a
-   Transport Layer Security (TLS) [RFC5246] channel, redundant and best
-   replaced with channel binding.
-
-   GS2 is designed to be as simple as possible.  It adds to GSS-API
-   security context token exchanges only the bare minimum to support
-   SASL semantics and negotiation of use of channel binding.
-   Specifically, GS2 adds a small header (2 bytes or 4 bytes plus the
-   length of the client requested SASL authorization ID (authzid)) to
-   the initial context token and to the application channel binding
-   data, and it uses SASL mechanism negotiation to implement channel
-   binding negotiation.  All GS2 plaintext is protected via the use of
-   GSS-API channel binding.  Additionally, to simplify the
-   implementation of GS2 mechanisms for implementors who will not
-   implement a GSS-API framework, we compress the initial security
-   context token header required by [RFC2743] (see section 3.1).
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009               [Page 4]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-2.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  Mechanism name
-
-3.1.  Generating SASL mechanism names from GSS-API OIDs
-
-   There are two SASL mechanism names for any GSS-API mechanism used
-   through this facility.  One denotes that the server supports channel
-   binding.  The other denotes that it does not.
-
-   The SASL mechanism name for a GSS-API mechanism is that which is
-   provided by that mechanism when it was specified, if one was
-   specified.  This name denotes that the server does not support
-   channel binding.  Add the suffix "-PLUS" and the resulting name
-   denotes that the server does support channel binding.  SASL
-   implementations can use the GSS_Mechanism_Name call (see below) to
-   query for the SASL mechanism name of a GSS-API mechanism.
-
-   For GSS-API mechanisms whose SASL names are not defined together with
-   the GSS-API mechanism or in this document, the SASL mechanism name is
-   concatenation of the string "GS2-" and the Base32 encoding [RFC4648]
-   (with an upper case alphabet) of the first 55 bits of the binary
-   SHA-1 hash [FIPS.180-1.1995] string computed over the ASN.1 DER
-   encoding [CCITT.X690.2002], including the tag and length octets, of
-   the GSS-API mechanism's Object Identifier.  The Base32 rules on
-   padding characters and characters outside of the base32 alphabet are
-   not relevant to this use of Base32.  If any padding or non-alphabet
-   characters are encountered, the name is not a GS2 family mechanism
-   name.  This name denotes that the server does not support channel
-   binding.  Add the suffix "-PLUS" and the resulting name denotes that
-   the server does support channel binding.
-
-3.2.  Computing mechanism names manually
-
-   The hash-derived GS2 SASL mechanism name may be computed manually.
-   This is useful when the set of supported GSS-API mechanisms is known
-   in advance.  It also obliterate the need to implement Base32, SHA-1
-   and DER in the SASL mechanism.  The computed mechanism name can be
-   used directly in the implementation, and the implementation need not
-   concern itself with that the mechanism is part of a mechanism family.
-
-
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009               [Page 5]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-3.3.  Examples
-
-   The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1.  The
-   ASN.1 DER encoding of the OID, including the tag and length, is (in
-   hex) 06 07 2b 06 01 05 05 01 01.  The SHA-1 hash of the ASN.1 DER
-   encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56
-   27 86 61 ad.  Convert the first 7 octets to binary, drop the last
-   bit, and re-group them in groups of 5, and convert them back to
-   decimal, which results in these computations:
-
-   hex:
-   1c f8 f4 2b 5a 9f 80
-
-   binary:
-   00011100 11111000 11110100 00101011 01011010
-   10011111 1000000
-
-   binary in groups of 5:
-   00011 10011 11100 01111 01000 01010 11010 11010
-   10011 11110 00000
-
-   decimal of each group:
-   3 19 28 15 8 10 26 26 19 30 0
-
-   base32 encoding:
-   D T 4 P I K 2 2 T 6 A
-
-   The last step translate each decimal value using table 3 in Base32
-   [RFC4648].  Thus the SASL mechanism name for the SPKM-1 GSSAPI
-   mechanism is "GS2-DT4PIK22T6A".
-
-   The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is
-   1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48
-   86 F7 12 01 02 02.  The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa
-   93 25 51 6a fc ff 04 b0 43 60.  Convert the first ten octets to
-   binary, and re-group them in groups of 5, and convert them back to
-   decimal, which results in these computations:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009               [Page 6]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-   hex:
-   82 d2 73 25 76 6b d6
-
-   binary:
-   10000010 11010010 01110011 00100101 01110110
-   01101011 1101011
-
-   binary in groups of 5:
-   10000 01011 01001 00111 00110 01001 01011 10110
-   01101 01111 01011
-
-   decimal of each group:
-   16 11 9 7 6 9 11 22 13 15 11
-
-   base32 encoding:
-   Q L J H G J L W N P L
-
-   The last step translate each decimal value using table 3 in Base32
-   [RFC4648].  Thus the SASL mechanism name for the Kerberos V5 GSSAPI
-   mechanism would be "GS2-QLJHGJLWNPL" and (because this mechanism
-   supports channel binding) "GS2-QLJHGJLWNPL-PLUS".  But instead, we
-   assign the Kerberos V mechanism a non-hash-derived mechanism name:
-   "KerberosV-GS2" and "KerberosV-GS2-PLUS" (see Section 15).
-
-
-4.  SASL Authentication Exchange Message Format
-
-4.1.  SASL Messages
-
-   During the SASL authentication exchange for GS2, a number of messages
-   following the following format is sent between the client and server.
-   This number is the same as the number of context tokens that the GSS-
-   API mechanism would normally require in order to establish a security
-   context (or to fail to do so).
-
-   Note that when using a GS2 mechanism the SASL client is always a GSS-
-   API initiator and the SASL server is always a GSS-API acceptor.  Thus
-   the SASL client calls GSS_Init_sec_context() and the server calls
-   GSS_Accept_sec_context().
-
-   All the SASL authentication messages exchanged are exactly the same
-   as the security context tokens of the GSS-API mechanism, except for
-   the initial security context token.
-
-   Also, the server SHOULD refrain from sending GSS-API error tokens
-   (tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
-   along with a major status code other than GSS_S_COMPLETE or
-   GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
-
-
-
-Josefsson & Williams   Expires September 24, 2009               [Page 7]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-   The initial security context token is modified as follows:
-   o  The [RFC2743] section 3.1 initial context token header MUST be
-      removed if present, and its presence is noted (see below).  On the
-      server side this header MUST be recomputed and restored prior to
-      passing the token to GSS_Accept_sec_context().
-   o  A GS2 header MUST be prefixed to the resulting initial context
-      token.  This header has the form given below in ABNF [RFC5234].
-
-      UTF8-1-safe    = %x01-2B / %x2D-3C / %x3E-7F
-                       ;; As UTF8-1 in RFC 3629 except
-                       ;; NUL, "=", and ",".
-      UTF8-2         = <as defined in RFC 3629 (STD 63)>
-      UTF8-3         = <as defined in RFC 3629 (STD 63)>
-      UTF8-4         = <as defined in RFC 3629 (STD 63)>
-      UTF8-char-safe = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
-
-      saslname     = 1*(UTF8-char-safe / "=2C" / "=3D")
-      gs2-authzid  = "a=" saslname
-                        ;; GS2 has to transport an authzid since
-                        ;; the GSS-API has no equivalent
-      gs2-std-mech = "F"
-                        ;; "F" means the mechanism is NOT is a
-                        ;; standard GSS-API mechanism in that the
-                        ;; RFC2743 section 3.1 header was missing
-      gs2-cb-flag  = "n" / "y" / "p"
-                        ;; GS2 channel binding (CB) flag
-                        ;; "n" -> client does not support CB
-                        ;; "y" -> client supports CB, thinks the server
-                        ;;           does not
-                        ;; "p" -> client supports and used CB
-      gs2-header   = [gs2-std-mech] gs2-cb-flag [gs2-authzid] ","
-                        ;; The GS2 header is gs2-header.
-                        ;; gs2-std-mech is present if the GSS-API
-                        ;; mechanism's initial context token did not
-                        ;; have the standard header defined in
-                        ;; [RFC2743] section 3.1.
-
-   The GS2 header is also prepended to the application's channel binding
-   data.  If the application did not provide channel binding data then
-   the GS2 header is used as though it were application-provided channel
-   binding data.
-
-   The "gs2-authzid" holds the SASL authorization identity.  It is
-   encoded using UTF-8 [RFC3629] with three exceptions:
-   o  The NUL characters is forbidden as required by section 3.4.1 of
-      [RFC4422].
-
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009               [Page 8]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-   o  The server MUST replace any occurance of "," (comma) in the string
-      with "=2C".
-   o  The server MUST replace any occurance of "=" (comma) in the string
-      with "=3D".
-
-   If a server sends a string that does not conform to this syntax, the
-   client MUST reject authentication.
-
-
-5.  Channel Bindings
-
-   If the server supports channel binding then it must list both forms
-   of the SASL mechanism name for each GSS-API mechanism supported via
-   GS2 (i.e., GSS-API mechanisms that support channel binding).
-
-   If the client supports channel binding and the server does not (i.e.,
-   the server did not advertise the -PLUS names) then the client MUST
-   either fail authentication or it MUST set the channel binding flag in
-   the GS2 initial security context token to "y" and MUST NOT include
-   application channel binding data in the GSS-API channel binding input
-   to GSS_Init_sec_context().
-
-   If the client supports channel binding and the server also does then
-   the client MUST set the channel binding flag in the GS2 initial
-   security context token to "p" and MUST include application channel
-   binding data in the GSS-API channel binding input to
-   GSS_Init_sec_context().
-
-   If the client does not support channel binding then it MUST set the
-   channel binding flag in the GS2 initial security context token to "n"
-   and MUST NOT include application channel binding data in the GSS-API
-   channel binding input to GSS_Init_sec_context().
-
-   Upon receipt of the initial authentication message the server checks
-   the channel binding flag in the GS2 header and constructs a channel
-   binding data input for GSS_Accept_sec_context() accordingly.  If the
-   client channel binding flag was "n" then the server MUST NOT include
-   application channel binding data in the GSS-API channel binding input
-   to GSS_Accept_sec_context().  If the client channel binding flag was
-   "y" and the server does support channel binding then the server MUST
-   fail authentication.  If the client channel binding flag was "p" the
-   server MUST include application channel binding data in the GSS-API
-   channel binding input to GSS_Accept_sec_context().
-
-   For more discussions of channel bindings, and the syntax of the
-   channel binding data for various security protocols, see [RFC5056].
-
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009               [Page 9]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-6.  Examples
-
-   Example #1: a one round-trip GSS-API context token exchange, no
-   channel binding, optional authzid given.
-
-         C: Request authentication exchange
-         S: Empty Challenge
-         C: nauthzid=someuser, <initial context token with standard
-                                header removed>
-         S: Send reply context token as is
-         C: Empty message
-         S: Outcome of authentication exchange
-
-   Example #2: a one and one half round-trip GSS-API context token
-   exchange.
-
-         C: Request authentication exchange
-         S: Empty Challenge
-         C: nauthzid=someuser, <initial context token with standard
-                                header removed>
-         S: Send reply context token as is
-         C: Send reply context token as is
-         S: Outcome of authentication exchange
-
-   Example #3: a two round-trip GSS-API context token exchange.
-
-         C: Request authentication exchange
-         S: Empty Challenge
-         C: nauthzid=someuser, <initial context token with standard
-                                header removed>
-         S: Send reply context token as is
-         C: Send reply context token as is
-         S: Send reply context token as is
-         C: Empty message
-         S: Outcome of authentication exchange
-
-   Example #4: using channel binding.
-
-         C: Request authentication exchange
-         S: Empty Challenge
-         C: yauthzid=someuser, <initial context token with standard
-                                header removed>
-         S: Send reply context token as is
-         ...
-
-   GSS-API authentication is always initiated by the client.  The SASL
-   framework allows either the client and server to initiate
-   authentication.  In GS2 the server will send an initial empty
-
-
-
-Josefsson & Williams   Expires September 24, 2009              [Page 10]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-   challenge (zero byte string) if it has not yet received a token from
-   the client.  See section 3 of [RFC4422].
-
-
-7.  Authentication Conditions
-
-   Authentication MUST NOT succeed if any one of the following
-   conditions are true:
-
-   o  GSS_Init/Accept_sec_context() return anything other than
-      GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.
-   o  If the client's GS2 channel binding flag was "y" and the server
-      supports channel binding.
-   o  If the client requires use of channel binding and the server did
-      not advertise support for channel binding.
-   o  Authorization of client principal (i.e., src_name in
-      GSS_Accept_sec_context()) to requested authzid failed.
-   o  If the client is not authorized to the requested authzid or an
-      authzid could not be derived from the client's initiator principal
-      name.
-
-
-8.  GSS-API Parameters
-
-   GS2 does not use any GSS-API per-message tokens.  Therefore the
-   setting of req_flags related to per-message tokens is irrelevant.
-
-
-9.  Naming
-
-   There's no requirement that any particular GSS-API name-types be
-   used.  However, typically SASL servers will have host-based acceptor
-   principal names (see [RFC2743] section 4.1) and clients will
-   typically have username initiator principal names (see [RFC2743]
-   section 4.2).
-
-
-10.  GSS_Mechanism_SASLname call
-
-   To allow SASL implementations to query for the SASL mechanism name of
-   a GSS-API mechanism, we specify a new GSS-API function for this
-   purpose.
-
-
-
-
-
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009              [Page 11]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-      Inputs:
-
-      o desired_mech OBJECT IDENTIFIER
-
-      Outputs:
-
-      o sasl_mech_name OCTET STRING -- SASL name for this mechanism
-        (really, ASCII)
-
-      o mech_name UTF-8 STRING -- name of this mechanism, possibly
-        localized
-
-      o mech_description UTF-8 STRING -- possibly localized
-        description of this mechanism.
-
-      Return major_status codes:
-
-      o  GSS_S_COMPLETE indicates successful completion, and that output
-         parameters holds correct information.
-
-      o  GSS_S_BAD_MECH indicates that a disred_mech was unsupported by
-         the GSS-API implementation.
-
-      The GSS_Mechanism_SASLname call is used to get the SASL mechanism
-      name for a GSS-API mechanism.  It also returns a name and
-      description of the mechanism in a human readable form.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009              [Page 12]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-10.1.  gss_mechanism_saslname
-
-   The C binding for the GSS_Mechanism_SASLname call is as follows.
-
-     OM_uint32 gss_mechanism_saslname(
-       OM_uint32     *minor_status,
-       const gss_OID  desired_mech,
-       gss_buffer_t   sasl_mech_name,
-       gss_buffer_t   mech_name,
-       gss_buffer_t   mech_description,
-     );
-
-     Purpose:
-
-     Output the SASL mechanism name of a GSS-API mechanism.  Also output
-     a name and description of the mechanism in a human readable form.
-
-     Parameters:
-
-     minor_status      Integer, modify
-                       Mechanism specific status code.
-
-     Function value:   GSS status code
-
-     GSS_S_COMPLETE    Successful completion
-
-     GSS_S_BAD_MECH    The desired_mech OID is unsupported
-
-
-11.  GSS_Inquire_mech_for_SASLname call
-
-   To allow SASL clients to more efficiently identify which GSS-API
-   mechanism a particular SASL mechanism name refers to we specify a new
-   GSS-API utility function for this purpose.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009              [Page 13]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-      Inputs:
-
-      o sasl_mech_name OCTET STRING -- SASL name of mechanism
-        (really, ASCII)
-
-      Outputs:
-
-      o  mech_type OBJECT IDENTIFIER -- must be explicit mechanism,
-         and not "default" specifier
-
-      Return major_status codes:
-
-      o  GSS_S_COMPLETE indicates successful completion, and that output
-         parameters holds correct information.
-
-      o  GSS_S_BAD_MECH indicates that no supported GSS-API mechanism
-         had the indicated sasl_mech_name.
-
-      The GSS_Inquire_mech_for_SASLname call is used to get the GSS-API
-      mechanism OID associated with a SASL mechanism name.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009              [Page 14]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-11.1.  gss_inquire_mech_for_saslname
-
-   The C binding for the GSS_Inquire_mech_for_SASLname call is as
-   follows.
-
-      OM_uint32 gss_inquire_mech_for_saslname(
-        OM_uint32           *minor_status,
-        const gss_buffer_t   sasl_mech_name,
-        gss_OID             *mech_type
-      );
-
-      Purpose:
-
-      Output GSS-API mechanism OID of mechanism associated with given
-      sasl_mech_name.
-
-      Parameters:
-
-      minor_status      Integer, modify
-                        Mechanism specific status code.
-
-      Function value:   GSS status code
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_BAD_MECH    The desired_mech OID is unsupported
-
-
-12.  Security Layers
-
-   GS2 does not currently support SASL security layers.  Applications
-   that need integrity protection or confidentiality and integrity
-   protection MUST use either channel binding to a secure external
-   channel or a SASL mechanism that does provide security layers.
-
-   NOTE WELL: the GS2 client's first authentication message MUST always
-   start with "F", "n", "y" or "p", otherwise the server MUST fail
-   authentication.  This will allow us to add support for security
-   layers in the future if it were to become necessary.  Note that
-   adding security layer support to GS2 must not break existing SASL/GS2
-   applications, which can be accomplished by making security layers
-   optional.
-
-   [A sketch of how to add sec layer support...  Add a way for the
-   client to: a) make an offer of sec layers and max buffer, b) make an
-   opportunistic selection of sec layer and buffer size, both in the
-   first client authentication message, and starting with a character
-   other than "F", "n", "y" or "p".  The server could accept the
-
-
-
-Josefsson & Williams   Expires September 24, 2009              [Page 15]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-   opportunistic proposal (reply token prefixed with a byte indicating
-   acceptance) or reject it along with an indication of the server's
-   acceptable sec layers and max buffer size.  In the latter case the
-   GSS-API security context token exchange must be abandoned and
-   recommenced, although this would be a detail of the GS2 bridge not
-   exposed to the SASL application.  The negotiation would be protected
-   via GSS channel binding, as with the rest of GS2.]
-
-
-13.  Interoperability with the SASL "GSSAPI" mechanism
-
-   The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL
-   under the name "GSSAPI", see GSSAPI mechanism [RFC4752].  The
-   Kerberos V5 mechanism may also be used with the GS2 family.  This
-   causes an interopability problem, which is discussed and resolved
-   below.
-
-13.1.  The interoperability problem
-
-   The SASL "GSSAPI" mechanism is not wire-compatible with the Kerberos
-   V GSS-API mechanism used as a SASL GS2 mechanism.
-
-   If a client (or server) only support Kerberos V5 under the "GSSAPI"
-   name and the server (or client) only support Kerberos V5 under the
-   GS2 family, the mechanism negotiation will fail.
-
-13.2.  Resolving the problem
-
-   If the Kerberos V5 mechanism is supported under GS2 in a server, the
-   server SHOULD also support Kerberos V5 through the "GSSAPI"
-   mechanism, to avoid interoperability problems with older clients.
-
-   Reasons for violating this recommendation may include security
-   considerations regarding the absent features in the GS2 mechanism.
-   The SASL "GSSAPI" mechanism lacks support for channel bindings, which
-   means that using an external secure channel may not be sufficient
-   protection against active attackers (see [RFC5056], [mitm]).
-
-13.3.  Additional Recommendations
-
-   If the application requires security layers then it MUST prefer the
-   SASL "GSSAPI" mechanism over "KerberosV-GS2".
-
-   If the application can use channel binding to an external channel
-   then it is RECOMMENDED that it select Kerberos V5 through the GS2
-   mechanism rather than the "GSSAPI" mechanism.
-
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009              [Page 16]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-14.  Mechanisms that negotiate other mechanisms
-
-   A GSS-API mechanism that negotiate other mechanisms interact badly
-   with the SASL mechanism negotiation.  There are two problems.  The
-   first is an interoperability problem and the second is a security
-   concern.  The problems are described and resolved below.
-
-14.1.  The interoperability problem
-
-   If a client implement GSS-API mechanism X, potentially negotiated
-   through a GSS-API mechanism Y, and the server also implement GSS-API
-   mechanism X negotiated through a GSS-API mechanism Z, the
-   authentication negotiation will fail.
-
-14.2.  Security problem
-
-   If a client's policy is to first prefer GSSAPI mechanism X, then non-
-   GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports
-   mechanisms Y and Z but not X, then if the client attempts to
-   negotiate mechanism X by using a GSS-API mechanism that negotiate
-   other mechanisms (such as SPNEGO), it may end up using mechanism Z
-   when it ideally should have used mechanism Y. For this reason, the
-   use of GSS-API mechanisms that negotiate other mechanisms are
-   disallowed under GS2.
-
-14.3.  Resolving the problems
-
-   GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
-   with the GS2 SASL mechanism.  Specifically SPNEGO [RFC4178] MUST NOT
-   be used as a GS2 mechanism.  To make this easier for SASL
-   implementations we assign a symbolic SASL mechanism name to the
-   SPNEGO GSS-API mechanism: "SPNEGO".  SASL client implementations MUST
-   NOT choose the SPNEGO mechanism under any circumstances.  [What about
-   SASL apps that don't do mechanism negotiation?  Probably none exist.
-   But if any did then presumably it would OK to use the SPNEGO
-   mechanism, no? -Nico]
-
-   The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech()
-   [I-D.ietf-kitten-extended-mech-inquiry] can be used to identify such
-   mechanisms.
-
-
-15.  IANA Considerations
-
-   The SASL names for the Kerberos V GSS-API mechanism [RFC4121]
-   [RFC1964] used via GS2 SHALL be "KerberosV-GS2" and "KerberosV-GS2-
-   PLUS".
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009              [Page 17]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-   The SASL names for the SPNEGO GSS-API mechanism used via GS2 SHALL be
-   "SPNEGO" and "SPNEGO-PLUS".  As described in Section 14 the SASL
-   "SPNEGO" and "SPNEGO-PLUS" MUST NOT be used.  These names are
-   provided as a convienience for SASL library implementors.
-
-   The IANA is advised that SASL mechanism names starting with "GS2-"
-   are reserved for SASL mechanisms which conform to this document.  The
-   IANA is directed to place a statement to that effect in the sasl-
-   mechanisms registry.
-
-   The IANA is further advised that SASL mechanisms MUST NOT end in
-   "-PLUS" except as a version of another mechanism name simply suffixed
-   with "-PLUS".
-
-     Subject: Registration of SASL mechanism GS2-*
-     SASL mechanism prefix: GS2-
-     Security considerations: RFC [THIS-DOC]
-     Published specification: RFC [THIS-DOC]
-     Person & email address to contact for further information:
-       Simon Josefsson <simon@josefsson.org>
-     Intended usage: COMMON
-     Owner/Change controller: iesg@ietf.org
-     Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.
-
-
-16.  Security Considerations
-
-   Security issues are also discussed throughout this memo.
-
-   The security provided by a GS2 mechanism depends on the security of
-   the GSS-API mechanism.  The GS2 mechanism family depends on channel
-   binding support, so GSS-API mechanisms that do not support channel
-   binding cannot be successfully used as SASL mechanisms via the GS2
-   bridge.
-
-   Because GS2 does not support security layers it is strongly
-   RECOMMENDED that channel binding to a secure external channel be
-   used.  Successful channel binding eliminates the possibility of man-
-   in-the-middle (MITM) attacks, provided that the external channel and
-   its channel binding data are secure and provided that the GSS-API
-   mechanism used is secure.  Authentication failure because of channel
-   binding failure may indicate that an MITM attack was attempted, but
-   note that a real MITM attacker would likely attempt to close the
-   connection to the client or simulate network partition , thus MITM
-   attack detection is heuristic.
-
-   Use of channel binding will also protect the SASL mechanism
-   negotiation -- if there is no MITM then the external secure channel
-
-
-
-Josefsson & Williams   Expires September 24, 2009              [Page 18]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-   will have protected the SASL mechanism negotiation.
-
-   The channel binding data MAY be sent (byt the actual GSS-API
-   mechanism used) without confidentiality protection and knowledge of
-   it is assumed to provide no advantage to an MITM (who can, in any
-   case, compute the channel binding data independently).  If the
-   external channel does not provide confidentiality protection and the
-   GSS-API mechanism does not provide confidentiality protection for the
-   channel binding data, then passive attackers (eavesdroppers) can
-   recover the channel binding data.  See [RFC5056].
-
-   When constructing the input_name_string for GSS_Import_name() with
-   the GSS_C_NT_HOSTBASED_SERVICE name type, the client SHOULD NOT
-   canonicalize the server's fully qualified domain name using an
-   insecure or untrusted directory service, such as the Domain Name
-   System [RFC1034] without DNSSEC [RFC4033].
-
-   GS2 does not directly use any cryptographic algorithms, therefore it
-   is automatically "algorithm agile", or, as agile as the GSS-API
-   mechanisms that are available for use in SASL apoplications via GS2.
-
-   The security considerations of SASL [RFC4422], the GSS-API [RFC2743],
-   channel binding [RFC5056], any external channels (such as TLS,
-   [RFC5246], channel binding types (see the IANA channel binding type
-   registry), and GSS-API mechanisms (such as the Kerberos V mechanism
-   [RFC4121] [RFC1964]), may also apply.
-
-
-17.  Acknowledgements
-
-   The history of GS2 can be traced to the "GSSAPI" mechanism originally
-   specified by RFC2222.  This document was derived from
-   draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with
-   significant contributions from John G. Myers, although the majority
-   of this document has been rewritten by the current authors.
-
-   Contributions of many members of the SASL mailing list are gratefully
-   acknowledged.  In particular, ideas and feedback from Sam Hartman,
-   Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved the document
-   and the protocol.
-
-
-18.  References
-
-18.1.  Normative References
-
-   [FIPS.180-1.1995]
-              National Institute of Standards and Technology, "Secure
-
-
-
-Josefsson & Williams   Expires September 24, 2009              [Page 19]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-              Hash Standard", FIPS PUB 180-1, April 1995,
-              <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
-              10646", STD 63, RFC 3629, November 2003.
-
-   [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
-              Security Layer (SASL)", RFC 4422, June 2006.
-
-   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
-              Encodings", RFC 4648, October 2006.
-
-   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
-              Channels", RFC 5056, November 2007.
-
-   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
-              Specifications: ABNF", STD 68, RFC 5234, January 2008.
-
-   [CCITT.X690.2002]
-              International International Telephone and Telegraph
-              Consultative Committee, "ASN.1 encoding rules:
-              Specification of basic encoding Rules (BER), Canonical
-              encoding rules (CER) and Distinguished encoding rules
-              (DER)", CCITT Recommendation X.690, July 2002.
-
-18.2.  Informative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
-              (SPKM)", RFC 2025, October 1996.
-
-   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
-              (SASL)", RFC 2222, October 1997.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-
-
-Josefsson & Williams   Expires September 24, 2009              [Page 20]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
-              Simple and Protected Generic Security Service Application
-              Program Interface (GSS-API) Negotiation Mechanism",
-              RFC 4178, October 2005.
-
-   [RFC4752]  Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
-              Authentication and Security Layer (SASL) Mechanism",
-              RFC 4752, November 2006.
-
-   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
-
-   [I-D.newman-auth-scram]
-              Menon-Sen, A., Melnikov, A., and C. Newman, "Salted
-              Challenge Response (SCRAM) SASL Mechanism",
-              draft-newman-auth-scram-10 (work in progress),
-              February 2009.
-
-   [I-D.ietf-kitten-extended-mech-inquiry]
-              Williams, N., "Extended Generic Security Service Mechanism
-              Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-04
-              (work in progress), March 2008.
-
-   [mitm]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
-              in Tunneled Authentication",
-              WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
-
-
-Authors' Addresses
-
-   Simon Josefsson
-   SJD AB
-   Hagagatan 24
-   Stockholm  113 47
-   SE
-
-   Email: simon@josefsson.org
-   URI:   http://josefsson.org/
-
-
-
-
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009              [Page 21]
-
-Internet-Draft                 SASL GS2-*                     March 2009
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   USA
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson & Williams   Expires September 24, 2009              [Page 22]
-
diff --git a/doc/standardisation/draft-ietf-sasl-scram-04.txt b/doc/standardisation/draft-ietf-sasl-scram-04.txt
deleted file mode 100644
index b6245b6a5..000000000
--- a/doc/standardisation/draft-ietf-sasl-scram-04.txt
+++ /dev/null
@@ -1,1905 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                       A. Menon-Sen
-Internet-Draft                                    Oryx Mail Systems GmbH
-Intended status: Standards Track                             A. Melnikov
-Expires: February 1, 2010                                      Isode Ltd
-                                                               C. Newman
-                                                             N. Williams
-                                                        Sun Microsystems
-                                                           July 31, 2009
-
-
-            Salted Challenge Response (SCRAM) SASL Mechanism
-                      draft-ietf-sasl-scram-04.txt
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on February 1, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010                [Page 1]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-Abstract
-
-   The secure authentication mechanism most widely deployed and used by
-   Internet application protocols is the transmission of clear-text
-   passwords over a channel protected by Transport Layer Security (TLS).
-   There are some significant security concerns with that mechanism,
-   which could be addressed by the use of a challenge response
-   authentication mechanism protected by TLS.  Unfortunately, the
-   challenge response mechanisms presently on the standards track all
-   fail to meet requirements necessary for widespread deployment, and
-   have had success only in limited use.
-
-   This specification describes a family of Simple Authentication and
-   Security Layer (SASL, RFC 4422) authentication mechanisms called the
-   Salted Challenge Response Authentication Mechanism (SCRAM), which
-   addresses the security concerns and meets the deployability
-   requirements.  When used in combination with TLS or an equivalent
-   security layer, a mechanism from this family could improve the
-   status-quo for application protocol authentication and provide a
-   suitable choice for a mandatory-to-implement mechanism for future
-   application protocol standards.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010                [Page 2]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-Table of Contents
-
-   1.          Conventions Used in This Document  . . . . . . . . . .  4
-   1.1.        Terminology  . . . . . . . . . . . . . . . . . . . . .  4
-   1.2.        Notation . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.          Introduction . . . . . . . . . . . . . . . . . . . . .  7
-   3.          SCRAM Algorithm Overview . . . . . . . . . . . . . . .  9
-   4.          SCRAM Mechanism Names  . . . . . . . . . . . . . . . . 10
-   5.          SCRAM Authentication Exchange  . . . . . . . . . . . . 11
-   5.1.        SCRAM Attributes . . . . . . . . . . . . . . . . . . . 12
-   6.          Channel Binding  . . . . . . . . . . . . . . . . . . . 15
-   6.1.        Default Channel Binding  . . . . . . . . . . . . . . . 16
-   7.          Formal Syntax  . . . . . . . . . . . . . . . . . . . . 17
-   8.          SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 20
-   8.1.        GSS-API Principal Name Types for SCRAM . . . . . . . . 20
-   8.2.        GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 20
-   8.3.        GSS_Pseudo_random() for SCRAM  . . . . . . . . . . . . 21
-   9.          Security Considerations  . . . . . . . . . . . . . . . 22
-   10.         IANA Considerations  . . . . . . . . . . . . . . . . . 24
-   11.         Acknowledgements . . . . . . . . . . . . . . . . . . . 26
-   Appendix A. Other Authentication Mechanisms  . . . . . . . . . . . 27
-   Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 28
-   Appendix C. Internet-Draft Change History  . . . . . . . . . . . . 29
-   12.         References . . . . . . . . . . . . . . . . . . . . . . 31
-   12.1.       Normative References . . . . . . . . . . . . . . . . . 31
-   12.2.       Normative References for GSS-API implementors  . . . . 31
-   12.3.       Informative References . . . . . . . . . . . . . . . . 32
-               Authors' Addresses . . . . . . . . . . . . . . . . . . 34
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010                [Page 3]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-1.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   Formal syntax is defined by [RFC5234] including the core rules
-   defined in Appendix B of [RFC5234].
-
-   Example lines prefaced by "C:" are sent by the client and ones
-   prefaced by "S:" by the server.  If a single "C:" or "S:" label
-   applies to multiple lines, then the line breaks between those lines
-   are for editorial clarity only, and are not part of the actual
-   protocol exchange.
-
-1.1.  Terminology
-
-   This document uses several terms defined in [RFC4949] ("Internet
-   Security Glossary") including the following: authentication,
-   authentication exchange, authentication information, brute force,
-   challenge-response, cryptographic hash function, dictionary attack,
-   eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,
-   one-way encryption function, password, replay attack and salt.
-   Readers not familiar with these terms should use that glossary as a
-   reference.
-
-   Some clarifications and additional definitions follow:
-
-   o  Authentication information: Information used to verify an identity
-      claimed by a SCRAM client.  The authentication information for a
-      SCRAM identity consists of salt, iteration count, the "StoredKey"
-      and "ServerKey" (as defined in the algorithm overview) for each
-      supported cryptographic hash function.
-
-   o  Authentication database: The database used to look up the
-      authentication information associated with a particular identity.
-      For application protocols, LDAPv3 (see [RFC4510]) is frequently
-      used as the authentication database.  For network-level protocols
-      such as PPP or 802.11x, the use of RADIUS is more common.
-
-   o  Base64: An encoding mechanism defined in [RFC4648] which converts
-      an octet string input to a textual output string which can be
-      easily displayed to a human.  The use of base64 in SCRAM is
-      restricted to the canonical form with no whitespace.
-
-   o  Octet: An 8-bit byte.
-
-   o  Octet string: A sequence of 8-bit bytes.
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010                [Page 4]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-   o  Salt: A random octet string that is combined with a password
-      before applying a one-way encryption function.  This value is used
-      to protect passwords that are stored in an authentication
-      database.
-
-1.2.  Notation
-
-   The pseudocode description of the algorithm uses the following
-   notations:
-
-   o  ":=": The variable on the left hand side represents the octet
-      string resulting from the expression on the right hand side.
-
-   o  "+": Octet string concatenation.
-
-   o  "[ ]": A portion of an expression enclosed in "[" and "]" may not
-      be included in the result under some circumstances.  See the
-      associated text for a description of those circumstances.
-
-   o  HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in
-      [RFC2104]) using the octet string represented by "key" as the key
-      and the octet string "str" as the input string.  The size of the
-      result is the hash result size for the hash function in use.  For
-      example, it is 20 octets for SHA-1 (see [RFC3174]).
-
-   o  H(str): Apply the cryptographic hash function to the octet string
-      "str", producing an octet string as a result.  The size of the
-      result depends on the hash result size for the hash function in
-      use.
-
-   o  XOR: Apply the exclusive-or operation to combine the octet string
-      on the left of this operator with the octet string on the right of
-      this operator.  The length of the output and each of the two
-      inputs will be the same for this use.
-
-   o  Hi(str, salt):
-
-
-
-      U0   := HMAC(str, salt + INT(1))
-      U1   := HMAC(str, U0)
-      U2   := HMAC(str, U1)
-      ...
-      Ui-1 := HMAC(str, Ui-2)
-      Ui   := HMAC(str, Ui-1)
-
-      Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010                [Page 5]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-      where "i" is the iteration count, "+" is the string concatenation
-      operator and INT(g) is a four-octet encoding of the integer g,
-      most significant octet first.
-
-   o  This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and
-      with dkLen == output length of HMAC() == output length of H().
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010                [Page 6]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-2.  Introduction
-
-   This specification describes a family of authentication mechanisms
-   called the Salted Challenge Response Authentication Mechanism (SCRAM)
-   which addresses the requirements necessary to deploy a challenge-
-   response mechanism more widely than past attempts.  When used in
-   combination with Transport Layer Security (TLS, see [RFC5246]) or an
-   equivalent security layer, a mechanism from this family could improve
-   the status-quo for application protocol authentication and provide a
-   suitable choice for a mandatory-to-implement mechanism for future
-   application protocol standards.
-
-   For simplicity, this family of mechanisms does not presently include
-   negotiation of a security layer [RFC4422].  It is intended to be used
-   with an external security layer such as that provided by TLS or SSH,
-   with optional channel binding [RFC5056] to the external security
-   layer.
-
-   SCRAM is specified herein as a pure Simple Authentication and
-   Security Layer (SASL) [RFC4422] mechanism, but it conforms to the new
-   bridge between SASL and the Generic Security Services Application
-   Programming Interface (GSS-API) called "GS2" [I-D.ietf-sasl-gs2].
-   This means that this document defines both, a SASL mechanism and a
-   GSS-API mechanism.
-
-   SCRAM provides the following protocol features:
-
-   o  The authentication information stored in the authentication
-      database is not sufficient by itself to impersonate the client.
-      The information is salted to prevent a pre-stored dictionary
-      attack if the database is stolen.
-
-   o  The server does not gain the ability to impersonate the client to
-      other servers (with an exception for server-authorized proxies).
-
-   o  The mechanism permits the use of a server-authorized proxy without
-      requiring that proxy to have super-user rights with the back-end
-      server.
-
-   o  Mutual authentication is supported, but only the client is named
-      (i.e., the server has no name).
-
-   A separate document defines a standard LDAPv3 [RFC4510] attribute
-   that enables storage of the SCRAM authentication information in LDAP.
-   See [I-D.melnikov-sasl-scram-ldap].
-
-   For an in-depth discussion of why other challenge response mechanisms
-   are not considered sufficient, see appendix A.  For more information
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010                [Page 7]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-   about the motivations behind the design of this mechanism, see
-   appendix B.
-
-   Comments regarding this draft may be sent either to the
-   ietf-sasl@imc.org mailing list or to the authors.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010                [Page 8]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-3.  SCRAM Algorithm Overview
-
-   Note that this section omits some details, such as client and server
-   nonces.  See Section 5 for more details.
-
-   To begin with, the SCRAM client is in possession of a username and
-   password.  It sends the username to the server, which retrieves the
-   corresponding authentication information, i.e. a salt, StoredKey,
-   ServerKey and the iteration count i.  (Note that a server
-   implementation may chose to use the same iteration count for all
-   accounts.)  The server sends the salt and the iteration count to the
-   client, which then computes the following values and sends a
-   ClientProof to the server:
-
-
-      SaltedPassword  := Hi(password, salt)
-      ClientKey       := HMAC(SaltedPassword, "Client Key")
-      StoredKey       := H(ClientKey)
-      AuthMessage     := client-first-message-bare + "," +
-                         server-first-message + "," +
-                         client-final-message-without-proof
-      ClientSignature := HMAC(StoredKey, AuthMessage)
-      ClientProof     := ClientKey XOR ClientSignature
-      ServerKey       := HMAC(SaltedPassword, "Server Key")
-      ServerSignature := HMAC(ServerKey, AuthMessage)
-
-
-   The server authenticates the client by computing the ClientSignature,
-   exclusive-ORing that with the ClientProof to recover the ClientKey
-   and verifying the correctness of the ClientKey by applying the hash
-   function and comparing the result to the StoredKey.  If the ClientKey
-   is correct, this proves that the client has access to the user's
-   password.
-
-   Similarly, the client authenticates the server by computing the
-   ServerSignature and comparing it to the value sent by the server.  If
-   the two are equal, it proves that the server had access to the user's
-   ServerKey.
-
-   The AuthMessage is computed by concatenating messages from the
-   authentication exchange.  The format of these messages is defined in
-   Section 7.
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010                [Page 9]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-4.  SCRAM Mechanism Names
-
-   A SCRAM mechanism name is a string "SCRAM-" followed by the
-   uppercased name of the underlying hash function taken from the IANA
-   "Hash Function Textual Names" registry (see http://www.iana.org),
-   optionally followed by the suffix "-PLUS" (see below).  Note that
-   SASL mechanism names are limited to 20 characters, which means that
-   only hash function names with lengths shorter or equal to 9
-   characters (20-length("SCRAM-")-length("-PLUS") can be used.  For
-   cases when the underlying hash function name is longer than 9
-   characters, an alternative 9 character (or shorter) name can be used
-   to construct the corresponding SCRAM mechanism name, as long as this
-   alternative name doesn't conflict with any other hash function name
-   from the IANA "Hash Function Textual Names" registry.
-
-   For interoperability, all SCRAM clients and servers MUST implement
-   the SCRAM-SHA-1 authentication mechanism, i.e. an authentication
-   mechanism from the SCRAM family that uses the SHA-1 hash function as
-   defined in [RFC3174].
-
-   The "-PLUS" suffix is used only when the server supports channel
-   binding to the external channel.  If the server supports channel
-   binding, it will advertise both the "bare" and "plus" versions of
-   whatever mechanisms it supports (e.g., if the server supports only
-   SCRAM with SHA-1 then it will advertise support for both SCRAM-SHA-1
-   and SCRAM-SHA-1-PLUS); if the server does not support channel
-   binding, then it will advertise only the "bare" version of the
-   mechanism (e.g., only SCRAM-SHA-1).  The "-PLUS" exists to allow
-   negotiation of the use of channel binding.  See Section 6.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 10]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-5.  SCRAM Authentication Exchange
-
-   SCRAM is a SASL mechanism whose client response and server challenge
-   messages are text-based messages containing one or more attribute-
-   value pairs separated by commas.  Each attribute has a one-letter
-   name.  The messages and their attributes are described in
-   Section 5.1, and defined in Section 7.
-
-   This is a simple example of a SCRAM-SHA-1 authentication exchange
-   when the client doesn't support channel bindings:
-
-
-      C: n,,n=Chris Newman,r=ClientNonce
-      S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
-      C: c=biwsCg==,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
-      S: v=WxPv/siO5l+qxN4
-
-
-   [[anchor5: Note that the all hashes above are fake and will be fixed
-   during AUTH48.]]
-
-   With channel-binding data sent by the client this might look like
-   this (see [tls-server-end-point] for the definition of tls-server-
-   end-point TLS channel binding):
-
-
-      C: p=tls-server-end-point,,n=Chris Newman,r=ClientNonce
-      S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
-      C: c=cD10bHMtc2VydmVyLWVuZC1wb2ludCwsy1hFtXOnZ+ySrQM6srFp
-         l/77uqvtxrg7nBY1BetEr/g=,r=ClientNonceServerNonce,p=Wx
-         Pv/siO5l+qxN4
-      S: v=WxPv/siO5l+qxN4
-
-
-   [[anchor6: Note that all hashes above are fake and will be fixed
-   during AUTH48.]]
-
-   First, the client sends a message containing:
-
-   o  a GS2 header consisting of a flag indicating whether channel
-      binding is supported-but-not-used, not supported, or used, and an
-      optional SASL authorization identity;
-
-   o  SCRAM username and a random, unique nonce attributes.
-
-   Note that the client's first message will always start with "n", "y"
-   or "p", otherwise the message is invalid and authentication MUST
-   fail.  This is important, as it allows for GS2 extensibility (e.g.,
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 11]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-   to add support for security layers).
-
-   In response, the server sends the user's iteration count i, the
-   user's salt, and appends its own nonce to the client-specified one.
-   The client then responds with the same nonce and a ClientProof
-   computed using the selected hash function as explained earlier.  The
-   server verifies the nonce and the proof, verifies that the
-   authorization identity (if supplied by the client in the first
-   message) is authorized to act as the authentication identity, and,
-   finally, it responds with a ServerSignature, concluding the
-   authentication exchange.  The client then authenticates the server by
-   computing the ServerSignature and comparing it to the value sent by
-   the server.  If the two are different, the client MUST consider the
-   authentication exchange to be unsuccessful and it might have to drop
-   the connection.
-
-5.1.  SCRAM Attributes
-
-   This section describes the permissible attributes, their use, and the
-   format of their values.  All attribute names are single US-ASCII
-   letters and are case-sensitive.
-
-   Note that the order of attributes in client or server messages is
-   fixed, with the exception of extension attributes (described by the
-   "extensions" ABNF production), which can appear in any order in the
-   designated positions.  See the ABNF section for authoritative
-   reference.
-
-   o  a: This is an optional attribute, and is part of the GS2
-      [I-D.ietf-sasl-gs2] bridge between the GSS-API and SASL.  This
-      attribute specifies an authorization identity.  A client may
-      include it in its first message to the server if it wants to
-      authenticate as one user, but subsequently act as a different
-      user.  This is typically used by an administrator to perform some
-      management task on behalf of another user, or by a proxy in some
-      situations.
-
-         Upon the receipt of this value the server verifies its
-         correctness according to the used SASL protocol profile.
-         Failed verification results in failed authentication exchange.
-
-         If this attribute is omitted (as it normally would be), the
-         authorization identity is assumed to be derived from the
-         username specified with the (required) "n" attribute.
-
-         The server always authenticates the user specified by the "n"
-         attribute.  If the "a" attribute specifies a different user,
-         the server associates that identity with the connection after
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 12]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-         successful authentication and authorization checks.
-
-         The syntax of this field is the same as that of the "n" field
-         with respect to quoting of '=' and ','.
-
-   o  n: This attribute specifies the name of the user whose password is
-      used for authentication (a.k.a. "authentication identity"
-      [RFC4422]).  A client MUST include it in its first message to the
-      server.  If the "a" attribute is not specified (which would
-      normally be the case), this username is also the identity which
-      will be associated with the connection subsequent to
-      authentication and authorization.
-
-         Before sending the username to the server, the client MUST
-         prepare the username using the "SASLPrep" profile [RFC4013] of
-         the "stringprep" algorithm [RFC3454].  If the preparation of
-         the username fails or results in an empty string, the client
-         SHOULD abort the authentication exchange (*).
-
-         (*) An interactive client can request a repeated entry of the
-         username value.
-
-         Upon receipt of the username by the server, the server SHOULD
-         prepare it using the "SASLPrep" profile [RFC4013] of the
-         "stringprep" algorithm [RFC3454].  If the preparation of the
-         username fails or results in an empty string, the server SHOULD
-         abort the authentication exchange.
-
-         The characters ',' or '=' in usernames are sent as '=2C' and
-         '=3D' respectively.  If the server receives a username which
-         contains '=' not followed by either '2C' or '3D', then the
-         server MUST fail the authentication.
-
-   o  m: This attribute is reserved for future extensibility.  In this
-      version of SCRAM, its presence in a client or a server message
-      MUST cause authentication failure when the attribute is parsed by
-      the other end.
-
-   o  r: This attribute specifies a sequence of random printable
-      characters excluding ',' which forms the nonce used as input to
-      the hash function.  No quoting is applied to this string.  As
-      described earlier, the client supplies an initial value in its
-      first message, and the server augments that value with its own
-      nonce in its first response.  It is important that this value be
-      different for each authentication.  The client MUST verify that
-      the initial part of the nonce used in subsequent messages is the
-      same as the nonce it initially specified.  The server MUST verify
-      that the nonce sent by the client in the second message is the
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 13]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-      same as the one sent by the server in its first message.
-
-   o  c: This REQUIRED attribute specifies base64-encoded of a header
-      and the channel-binding data.  It is sent by the client in its
-      second authentication message.  The header consist of:
-
-      *  the GS2 header from the client's first message (recall: a
-         channel binding flag and an optional authzid).  This header is
-         going to include channel binding type prefix (see [RFC5056]),
-         if and only if the client is using channel binding;
-
-      *  followed by the external channel's channel binding data, if and
-         only if the client is using channel binding.
-
-   o  s: This attribute specifies the base64-encoded salt used by the
-      server for this user.  It is sent by the server in its first
-      message to the client.
-
-   o  i: This attribute specifies an iteration count for the selected
-      hash function and user, and MUST be sent by the server along with
-      the user's salt.
-
-         For SCRAM-SHA-1/SCRAM-SHA-1-PLUS SASL mechanism servers SHOULD
-         announce a hash iteration-count of at least 4096.  Note that a
-         client implementation MAY cache SaltedPassword/ClientKey for
-         later reauthentication to the same service, as it is likely
-         that the server is going to advertise the same salt value upon
-         reauthentication.  This might be useful for mobile clients
-         where CPU usage is a concern.
-
-   o  p: This attribute specifies a base64-encoded ClientProof.  The
-      client computes this value as described in the overview and sends
-      it to the server.
-
-   o  v: This attribute specifies a base64-encoded ServerSignature.  It
-      is sent by the server in its final message, and is used by the
-      client to verify that the server has access to the user's
-      authentication information.  This value is computed as explained
-      in the overview.
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 14]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-6.  Channel Binding
-
-   SCRAM supports channel binding to external secure channels, such as
-   TLS.  Clients and servers may or may not support channel binding,
-   therefore the use of channel binding is negotiable.  SCRAM does not
-   provide security layers, however, therefore it is imperative that
-   SCRAM provide integrity protection for the negotiation of channel
-   binding.
-
-   Use of channel binding is negotiated as follows:
-
-   o  Servers SHOULD advertise both non-PLUS (SCRAM-<hash-function>) and
-      the PLUS-variant (SCRAM-<hash-function>-PLUS) SASL mechanism
-      names.  If the server cannot support channel binding, it MAY
-      advertise only the non-PLUS variant.  If the server would never
-      succeed authentication of the non-PLUS variant due to policy
-      reasons, it MAY advertise only the PLUS-variant.
-
-   o  If the client negotiates mechanisms then the client MUST select
-      SCRAM-<hash-function>-PLUS if offered by the server and the client
-      wants to select SCRAM with the given hash function.  Otherwise
-      (the client does not negotiate mechanisms), if the client has no
-      prior knowledge about mechanisms supported by the server and
-      wasn't explicitly configured to use a particular variant of the
-      SCRAM mechanism, then it MUST select only SCRAM-<hash-function>
-      (not suffixed with "-PLUS").
-
-   o  If the client supports channel binding and the server appears to
-      support it (i.e., the client sees SCRAM-<hash-function>-PLUS), or
-      if the client wishes to use channel binding but the client does
-      not negotiate mechanisms, then the client MUST set the GS2 channel
-      binding flag to "p" in order to indicate the channel binding type
-      it is using and it MUST include the channel binding data for the
-      external channel in the computation of the "c=" attribute (see
-      Section 5.1).
-
-   o  If the client supports channel binding but the server does not
-      appear to (i.e., the client did not see SCRAM-<hash-function>-
-      PLUS) then the client MUST either fail authentication or it MUST
-      choose the non-PLUS mechanism and set the GS2 channel binding flag
-      to "y" and MUST NOT include channel binding data for the external
-      channel in the computation of the "c=" attribute (see
-      Section 5.1).
-
-   o  If the client does not support channel binding then the client
-      MUST set the GS2 channel binding flag to "n" and MUST NOT include
-      channel binding data for the external channel in the computation
-      of the "c=" attribute (see Section 5.1).
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 15]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-   o  Upon receipt of the client first message the server checks the GS2
-      channel binding flag (gs2-cb-flag).
-
-      *  If the flag is set to "y" and the server supports channel
-         binding the server MUST fail authentication.  This is because
-         if the client sets the GS2 channel binding flag set to "y" then
-         the client must have believed that the server did not support
-         channel binding -- if the server did in fact support channel
-         binding then this is an indication that there has been a
-         downgrade attack (e.g., an attacker changed the server's
-         mechanism list to exclude the -PLUS suffixed SCRAM mechanism
-         name(s)).
-
-      *  If the channel binding flag was "p" and the server does not
-         support the indicated channel binding type then the server MUST
-         fail authentication.
-
-   The server MUST always validate the client's "c=" field.  The server
-   does this by constructing the value of the "c=" attribute and then
-   checking that it matches the client's c= attribute value.
-
-   For more discussions of channel bindings, and the syntax of the
-   channel binding data for various security protocols, see [RFC5056].
-
-6.1.  Default Channel Binding
-
-   A default channel binding type agreement process for all SASL
-   application protocols that do not provide their own channel binding
-   type agreement is provided as follows.
-
-   'tls-unique' is the default channel binding type for any application
-   that doesn't specify one.
-
-   Servers MUST implement the "tls-unique" [tls-unique]
-   [I-D.altman-tls-channel-bindings] channel binding type, if they
-   implement any channel binding.  Clients SHOULD implement the "tls-
-   unique" [tls-unique] [I-D.altman-tls-channel-bindings] channel
-   binding type, if they implement any channel binding.  Clients and
-   servers SHOULD choose the highest- layer/innermost end-to-end TLS
-   channel as the channel to bind to.
-
-   Servers MUST choose the channel binding type indicated by the client,
-   or fail authentication if they don't support it.
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 16]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-7.  Formal Syntax
-
-   The following syntax specification uses the Augmented Backus-Naur
-   Form (ABNF) notation as specified in [RFC5234].  "UTF8-2", "UTF8-3"
-   and "UTF8-4" non-terminal are defined in [RFC3629].
-
-
-     ALPHA = <as defined in RFC 5234 appendix B.1>
-     DIGIT = <as defined in RFC 5234 appendix B.1>
-     UTF8-2 = <as defined in RFC 3629 (STD 63)>
-     UTF8-3 = <as defined in RFC 3629 (STD 63)>
-     UTF8-4 = <as defined in RFC 3629 (STD 63)>
-
-     attr-val        = ALPHA "=" value
-                       ;; Generic syntax of any attribute sent
-                       ;; by server or client
-
-     value           = 1*value-char
-
-     value-safe-char = %x01-2B / %x2D-3C / %x3E-7F /
-                       UTF8-2 / UTF8-3 / UTF8-4
-                       ;; UTF8-char except NUL, "=", and ",".
-
-     value-char      = value-safe-char / "="
-
-     base64-char     = ALPHA / DIGIT / "/" / "+"
-
-     base64-4        = 4base64-char
-
-     base64-3        = 3base64-char "="
-
-     base64-2        = 2base64-char "=="
-
-     base64          = *base64-4 [base64-3 / base64-2]
-
-     posit-number = %x31-39 *DIGIT
-                       ;; A positive number
-
-     saslname        = 1*(value-safe-char / "=2C" / "=3D")
-                       ;; Conforms to <value>
-
-     authzid         = "a=" saslname
-                       ;; Protocol specific.
-
-     cb-name         = 1*(ALPHA / DIGIT / "." / "-")
-                        ;; See RFC 5056 section 7.
-                        ;; E.g. "tls-server-end-point" or
-                        ;; "tls-unique"
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 17]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-     gs2-cbind-flag  = "p=" cb-name / "n" / "y"
-                       ;; "n" -> client doesn't support channel binding
-                       ;; "y" -> client does support channel binding
-                       ;;        but thinks the server does not.
-                       ;; "p" -> client requires channel binding.
-                       ;; The selected channel binding follows "p=".
-
-     gs2-header      = gs2-cbind-flag "," [ authzid ] ","
-                       ;; GS2 header for SCRAM
-                       ;; (the actual GS2 header includes an optional
-                       ;; flag to indicate that the GSS mechanism is not
-                       ;; "standard" but since SCRAM is "standard" we
-                       ;; don't include that flag).
-
-     username        = "n=" saslname
-                       ;; Usernames are prepared using SASLPrep.
-
-     reserved-mext  = "m=" 1*(value-char)
-                       ;; Reserved for signalling mandatory extensions.
-                       ;; The exact syntax will be defined in
-                       ;; the future.
-
-     channel-binding = "c=" base64
-                       ;; base64 encoding of cbind-input
-
-     proof           = "p=" base64
-
-     nonce           = "r=" c-nonce [s-nonce]
-                       ;; Second part provided by server.
-
-     c-nonce         = value
-
-     s-nonce         = value
-
-     salt            = "s=" base64
-
-     verifier        = "v=" base64
-                       ;; base-64 encoded ServerSignature.
-
-     iteration-count = "i=" posit-number
-                       ;; A positive number
-
-     client-first-message-bare =
-                       [reserved-mext ","]
-                       username "," nonce ["," extensions]
-
-     client-first-message =
-                       gs2-header client-first-message-bare
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 18]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-     server-first-message =
-                       [reserved-mext ","] nonce "," salt ","
-                       iteration-count ["," extensions]
-
-     client-final-message-without-proof =
-                       channel-binding "," nonce [","
-                       extensions]
-
-     client-final-message =
-                       client-final-message-without-proof "," proof
-
-     gss-server-error = "e=" value
-     server-final-message = gss-server-error /
-                       verifier ["," extensions]
-                       ;; The error message is only for the GSS-API
-                       ;; form of SCRAM, and it is OPTIONAL to
-                       ;; implement it.
-
-     extensions = attr-val *("," attr-val)
-                       ;; All extensions are optional,
-                       ;; i.e. unrecognized attributes
-                       ;; not defined in this document
-                       ;; MUST be ignored.
-
-     cbind-data    = 1*OCTET
-
-     cbind-input   = gs2-header [ cbind-data ]
-                       ;; cbind-data MUST be present for
-                       ;; gs2-cbind-flag of "p" and MUST be absent
-                       ;; for "y" or "n".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 19]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-8.  SCRAM as a GSS-API Mechanism
-
-   This section and its sub-sections and all normative references of it
-   not referenced elsewhere in this document are INFORMATIONAL for SASL
-   implementors, but they are NORMATIVE for GSS-API implementors.
-
-   SCRAM is actually also GSS-API mechanism.  The messages are the same,
-   but a) the GS2 header on the client's first message and channel
-   binding data is excluded when SCRAM is used as a GSS-API mechanism,
-   and b) the RFC2743 section 3.1 initial context token header is
-   prefixed to the client's first authentication message (context
-   token).
-
-   The GSS-API mechanism OID for SCRAM is <TBD> (see Section 10).
-
-8.1.  GSS-API Principal Name Types for SCRAM
-
-   SCRAM does not name acceptors.  Therefore only GSS_C_NO_NAME and
-   names of type GSS_C_NT_ANONYMOUS shall be allowed as the target name
-   input of GSS_Init_sec_context() when using a SCRAM mechanism.
-
-   SCRAM supports only a single name type for initiators:
-   GSS_C_NT_USER_NAME.  GSS_C_NT_USER_NAME is the default name type for
-   SCRAM.
-
-   There is no name canonicalization procedure for SCRAM beyond applying
-   SASLprep as described in Section 5.1.
-
-   The query, display and exported name syntax for SCRAM principal names
-   is the same: there is no syntax -- SCRAM principal names are free-
-   form.  (The exported name token does, of course, conform to [RFC2743]
-   section 3.2, but the "NAME" part of the token is just a SCRAM user
-   name.)
-
-8.2.  GSS-API Per-Message Tokens for SCRAM
-
-   The per-message tokens for SCRAM as a GSS-API mechanism SHALL be the
-   same as those for the Kerberos V GSS-API mechanism [RFC4121], using
-   the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962].
-
-   The 128-bit session key SHALL be derived by using the least
-   significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API session
-   key" || ClientKey || AuthMessage).
-
-   SCRAM does support PROT_READY, and is PROT_READY on the initiator
-   side first upon receipt of the server's reply to the initial security
-   context token.
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 20]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-8.3.  GSS_Pseudo_random() for SCRAM
-
-   The GSS_Pseudo_random() [RFC4401] for SCRAM SHALL be the same as for
-   the Kerberos V GSS-API mechanism [RFC4402].  There is no acceptor-
-   asserted sub-session key for SCRAM, thus GSS_C_PRF_KEY_FULL and
-   GSS_C_PRF_KEY_PARTIAL are equivalent for SCRAM's GSS_Pseudo_random().
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 21]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-9.  Security Considerations
-
-   If the authentication exchange is performed without a strong security
-   layer, then a passive eavesdropper can gain sufficient information to
-   mount an offline dictionary or brute-force attack which can be used
-   to recover the user's password.  The amount of time necessary for
-   this attack depends on the cryptographic hash function selected, the
-   strength of the password and the iteration count supplied by the
-   server.  An external security layer with strong encryption will
-   prevent this attack.
-
-   If the external security layer used to protect the SCRAM exchange
-   uses an anonymous key exchange, then the SCRAM channel binding
-   mechanism can be used to detect a man-in-the-middle attack on the
-   security layer and cause the authentication to fail as a result.
-   However, the man-in-the-middle attacker will have gained sufficient
-   information to mount an offline dictionary or brute-force attack.
-   For this reason, SCRAM includes the ability to increase the iteration
-   count over time.
-
-   If the authentication information is stolen from the authentication
-   database, then an offline dictionary or brute-force attack can be
-   used to recover the user's password.  The use of salt mitigates this
-   attack somewhat by requiring a separate attack on each password.
-   Authentication mechanisms which protect against this attack are
-   available (e.g., the EKE class of mechanisms).  RFC 2945 [RFC2945] is
-   an example of such technology.  There are IPR disclosures at
-   http://datatracker.ietf.org/ipr/ that mention RFC 2945.
-
-   If an attacker obtains the authentication information from the
-   authentication repository and either eavesdrops on one authentication
-   exchange or impersonates a server, the attacker gains the ability to
-   impersonate that user to all servers providing SCRAM access using the
-   same hash function, password, iteration count and salt.  For this
-   reason, it is important to use randomly-generated salt values.
-
-   SCRAM does not negotiate a hash function to use.  Hash function
-   negotiation is left to the SASL mechanism negotiation.  It is
-   important that clients be able to sort a locally available list of
-   mechanisms by preference so that the client may pick the most
-   preferred of a server's advertised mechanism list.  This preference
-   order is not specified here as it is a local matter.  The preference
-   order should include objective and subjective notions of mechanism
-   cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be
-   preferred over SCRAM with SHA-1).
-
-   Note that to protect the SASL mechanism negotiation applications
-   normally must list the server mechs twice: once before and once after
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 22]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-   authentication, the latter using security layers.  Since SCRAM does
-   not provide security layers the only ways to protect the mechanism
-   negotiation are: a) use channel binding to an external channel, or b)
-   use an external channel that authenticates a user-provided server
-   name.
-
-   SCRAM does not protect against downgrade attacks of channel binding
-   types.  The complexities of negotiation a channel binding type, and
-   handling down-grade attacks in that negotiation, was intentionally
-   left out of scope for this document.
-
-   A hostile server can perform a computational denial-of-service attack
-   on clients by sending a big iteration count value.
-
-   See [RFC4086] for more information about generating randomness.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 23]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-10.  IANA Considerations
-
-   IANA is requested to add the following family of SASL mechanisms to
-   the SASL Mechanism registry established by [RFC4422]:
-
-
-   To: iana@iana.org
-   Subject: Registration of a new SASL family SCRAM
-
-   SASL mechanism name (or prefix for the family): SCRAM-*
-   Security considerations: Section 7 of [RFCXXXX]
-   Published specification (optional, recommended): [RFCXXXX]
-   Person & email address to contact for further information:
-    IETF SASL WG <ietf-sasl@imc.org>
-   Intended usage: COMMON
-   Owner/Change controller: IESG <iesg@ietf.org>
-   Note: Members of this family must be explicitly registered
-   using the "IETF Consensus" registration procedure.
-   Reviews must be requested on the SASL WG mailing list.
-
-
-   "IETF Consensus" registration procedure MUST be used for registering
-   new mechanisms in this family.  The SASL mailing list
-   <ietf-sasl@imc.org> (or a successor designated by the responsible
-   Security AD) MUST be used for soliciting reviews on such
-   registrations.
-
-   Note to future SCRAM- mechanism designers: each new SCRAM- SASL
-   mechanism MUST be explicitly registered with IANA and MUST comply
-   with SCRAM- mechanism naming convention defined in Section 4 of this
-   document.
-
-   IANA is requested to add the following entries to the SASL Mechanism
-   registry established by [RFC4422]:
-
-
-   To: iana@iana.org
-   Subject: Registration of a new SASL mechanism SCRAM-SHA-1
-
-   SASL mechanism name (or prefix for the family): SCRAM-SHA-1
-   Security considerations: Section 7 of [RFCXXXX]
-   Published specification (optional, recommended): [RFCXXXX]
-   Person & email address to contact for further information:
-    IETF SASL WG <ietf-sasl@imc.org>
-   Intended usage: COMMON
-   Owner/Change controller: IESG <iesg@ietf.org>
-   Note:
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 24]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-   To: iana@iana.org
-   Subject: Registration of a new SASL mechanism SCRAM-SHA-1-PLUS
-
-   SASL mechanism name (or prefix for the family): SCRAM-SHA-1-PLUS
-   Security considerations: Section 7 of [RFCXXXX]
-   Published specification (optional, recommended): [RFCXXXX]
-   Person & email address to contact for further information:
-    IETF SASL WG <ietf-sasl@imc.org>
-   Intended usage: COMMON
-   Owner/Change controller: IESG <iesg@ietf.org>
-   Note:
-
-
-   This document also requests IANA to assign a GSS-API mechanism OID
-   for SCRAM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 25]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-11.  Acknowledgements
-
-   This document benefited from discussions on the SASL WG mailing list.
-   The authors would like to specially thank Dave Cridland, Simon
-   Josefsson and Jeffrey Hutzelman for their contributions to this
-   document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 26]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-Appendix A.  Other Authentication Mechanisms
-
-   The DIGEST-MD5 [I-D.ietf-sasl-digest-to-historic] mechanism has
-   proved to be too complex to implement and test, and thus has poor
-   interoperability.  The security layer is often not implemented, and
-   almost never used; everyone uses TLS instead.  For a more complete
-   list of problems with DIGEST-MD5 which lead to the creation of SCRAM
-   see [I-D.ietf-sasl-digest-to-historic].
-
-   The CRAM-MD5 SASL mechanism, while widely deployed has also some
-   problems, in particular it is missing some modern SASL features such
-   as support for internationalized usernames and passwords, support for
-   passing of authorization identity, support for channel bindings.  It
-   also doesn't support server authentication.  For a more complete list
-   of problems with CRAM-MD5 see [I-D.ietf-sasl-crammd5-to-historic].
-
-   The PLAIN [RFC4616] SASL mechanism allows a malicious server or
-   eavesdropper to impersonate the authenticating user to any other
-   server for which the user has the same password.  It also sends the
-   password in the clear over the network, unless TLS is used.  Server
-   authentication is not supported.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 27]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-Appendix B.  Design Motivations
-
-   The following design goals shaped this document.  Note that some of
-   the goals have changed since the initial version of the document.
-
-   o  The SASL mechanism has all modern SASL features: support for
-      internationalized usernames and passwords, support for passing of
-      authorization identity, support for channel bindings.
-
-   o  The protocol supports mutual authentication.
-
-   o  The authentication information stored in the authentication
-      database is not sufficient by itself to impersonate the client.
-
-   o  The server does not gain the ability to impersonate the client to
-      other servers (with an exception for server-authorized proxies),
-      unless such other servers allow SCRAM authentication and use the
-      same salt and iteration count for the user.
-
-   o  The mechanism is extensible, but [hopefully] not overengineered in
-      this respect.
-
-   o  Easier to implement than DIGEST-MD5 in both clients and servers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 28]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-Appendix C.  Internet-Draft Change History
-
-   (RFC Editor: Please delete everything after this point)
-
-   Changes since -10
-
-   o  Converted the source for this I-D to XML.
-
-   o  Added text to make SCRAM compliant with the new GS2 design.
-
-   o  Added text on channel binding negotiation.
-
-   o  Added text on channel binding, including a reference to RFC5056.
-
-   o  Added text on SCRAM as a GSS-API mechanism.  This noted as not
-      relevant to SASL-only implementors -- the normative references for
-      SCRAM as a GSS-API mechanism are segregated as well.
-
-   Changes since -07
-
-   o  Updated References.
-
-   o  Clarified purpose of the m= attribute.
-
-   o  Fixed a problem with authentication/authorization identity's ABNF
-      not allowing for some characters.
-
-   o  Updated ABNF for nonce to show client-generated and server-
-      generated parts.
-
-   o  Only register SCRAM-SHA-1 with IANA and require explicit
-      registrations of all other SCRAM- mechanisms.
-
-   Changes since -06
-
-   o  Removed hash negotiation from SCRAM and turned it into a family of
-      SASL mechanisms.
-
-   o  Start using "Hash Function Textual Names" IANA registry for SCRAM
-      mechanism naming.
-
-   o  Fixed definition of Hi(str, salt) to be consistent with [RFC2898].
-
-   o  Clarified extensibility of SCRAM: added m= attribute (for future
-      mandatory extensions) and specified that all unrecognized
-      attributes must be ignored.
-
-   Changes since -05
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 29]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-   o  Changed the mandatory to implement hash algorithm to SHA-1 (as per
-      WG consensus).
-
-   o  Added text about use of SASLPrep for username canonicalization/
-      validation.
-
-   o  Clarified that authorization identity is canonicalized/verified
-      according to SASL protocol profile.
-
-   o  Clarified that iteration count is per-user.
-
-   o  Clarified how clients select the authentication function.
-
-   o  Added IANA registration for the new mechanism.
-
-   o  Added missing normative references (UTF-8, SASLPrep).
-
-   o  Various editorial changes based on comments from Hallvard B
-      Furuseth, Nico William and Simon Josefsson.
-
-   Changes since -04
-
-   o  Update Base64 and Security Glossary references.
-
-   o  Add Formal Syntax section.
-
-   o  Don't bother with "v=".
-
-   o  Make MD5 mandatory to implement.  Suggest i=128.
-
-   Changes since -03
-
-   o  Seven years have passed, in which it became clear that DIGEST-MD5
-      suffered from unacceptably bad interoperability, so SCRAM-MD5 is
-      now back from the dead.
-
-   o  Be hash agnostic, so MD5 can be replaced more easily.
-
-   o  General simplification.
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 30]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-12.  References
-
-12.1.  Normative References
-
-   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
-              (SHA1)", RFC 3174, September 2001.
-
-   [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
-              Internationalized Strings ("stringprep")", RFC 3454,
-              December 2002.
-
-   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
-              10646", STD 63, RFC 3629, November 2003.
-
-   [RFC4013]  Zeilenga, K., "SASLprep: Stringprep Profile for User Names
-              and Passwords", RFC 4013, February 2005.
-
-   [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
-              Security Layer (SASL)", RFC 4422, June 2006.
-
-   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
-              Encodings", RFC 4648, October 2006.
-
-   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
-              Channels", RFC 5056, November 2007.
-
-   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
-              Specifications: ABNF", STD 68, RFC 5234, January 2008.
-
-12.2.  Normative References for GSS-API implementors
-
-   [I-D.ietf-sasl-gs2]
-              Josefsson, S. and N. Williams, "Using GSS-API Mechanisms
-              in SASL: The GS2 Mechanism Family", draft-ietf-sasl-gs2-12
-              (work in progress), April 2009.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
-              Encryption for Kerberos 5", RFC 3962, February 2005.
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 31]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-              Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
-              Extension for the Generic Security Service Application
-              Program Interface (GSS-API)", RFC 4401, February 2006.
-
-   [RFC4402]  Williams, N., "A Pseudo-Random Function (PRF) for the
-              Kerberos V Generic Security Service Application Program
-              Interface (GSS-API) Mechanism", RFC 4402, February 2006.
-
-   [tls-unique]
-              Zhu, L., "Registration of TLS unique channel binding
-              (generic)", IANA http://www.iana.org/assignments/
-              channel-binding-types/tls-unique, July 2008.
-
-12.3.  Informative References
-
-   [I-D.altman-tls-channel-bindings]
-              Altman, J., Williams, N., and L. Zhu, "Channel Bindings
-              for TLS", draft-altman-tls-channel-bindings-05 (work in
-              progress), June 2009.
-
-   [I-D.ietf-sasl-crammd5-to-historic]
-              Zeilenga, K., "CRAM-MD5 to Historic",
-              draft-ietf-sasl-crammd5-to-historic-00 (work in progress),
-              November 2008.
-
-   [I-D.ietf-sasl-digest-to-historic]
-              Melnikov, A., "Moving DIGEST-MD5 to Historic",
-              draft-ietf-sasl-digest-to-historic-00 (work in progress),
-              July 2008.
-
-   [I-D.melnikov-sasl-scram-ldap]
-              Melnikov, A., "LDAP schema for storing SCRAM secrets",
-              draft-melnikov-sasl-scram-ldap-02 (work in progress),
-              July 2009.
-
-   [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
-              Specification Version 2.0", RFC 2898, September 2000.
-
-   [RFC2945]  Wu, T., "The SRP Authentication and Key Exchange System",
-              RFC 2945, September 2000.
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 32]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-   [RFC4510]  Zeilenga, K., "Lightweight Directory Access Protocol
-              (LDAP): Technical Specification Road Map", RFC 4510,
-              June 2006.
-
-   [RFC4616]  Zeilenga, K., "The PLAIN Simple Authentication and
-              Security Layer (SASL) Mechanism", RFC 4616, August 2006.
-
-   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
-              RFC 4949, August 2007.
-
-   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
-
-   [tls-server-end-point]
-              Zhu, L., "Registration of TLS server end-point channel
-              bindings", IANA http://www.iana.org/assignments/
-              channel-binding-types/tls-server-end-point, July 2008.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 33]
-
-Internet-Draft                    SCRAM                        July 2009
-
-
-Authors' Addresses
-
-   Abhijit Menon-Sen
-   Oryx Mail Systems GmbH
-
-   Email: ams@oryx.com
-
-
-   Alexey Melnikov
-   Isode Ltd
-
-   Email: Alexey.Melnikov@isode.com
-
-
-   Chris Newman
-   Sun Microsystems
-   1050 Lakes Drive
-   West Covina, CA  91790
-   USA
-
-   Email: chris.newman@sun.com
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   USA
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.       Expires February 1, 2010               [Page 34]
-
-
diff --git a/doc/standardisation/draft-jaganathan-rc4-hmac-00.txt b/doc/standardisation/draft-jaganathan-rc4-hmac-00.txt
deleted file mode 100644
index 895600302..000000000
--- a/doc/standardisation/draft-jaganathan-rc4-hmac-00.txt
+++ /dev/null
@@ -1,1233 +0,0 @@
-
-
-
-Internet Engineering Task Force                            K. Jaganathan
-Internet-Draft                                                    L. Zhu
-Expires: January 9, 2006                                       J. Brezak
-                                                   Microsoft Corporation
-                                                            July 8, 2005
-
-
-                 The RC4-HMAC Kerberos encryption type
-                    draft-jaganathan-rc4-hmac-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 9, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   The Microsoft Windows 2000 implementation of Kerberos introduces a
-   new encryption type based on the RC4 encryption algorithm and using
-   an MD5 HMAC for checksum.  This is offered as an alternative to using
-   the existing DES based encryption types.
-
-   The RC4-HMAC encryption types are used to ease upgrade of existing
-   Windows NT environments, provide strong crypto (128-bit key lengths),
-
-
-
-Jaganathan, et al.       Expires January 9, 2006                [Page 1]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-   and provide exportable (meet United States government export
-   restriction requirements) encryption.  This document describes the
-   implementation of those encryption types.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
-   3.  Key Generation . . . . . . . . . . . . . . . . . . . . . . . .  5
-   4.  Basic Operations . . . . . . . . . . . . . . . . . . . . . . .  6
-   5.  Checksum Types . . . . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Encryption Types . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  Key Strength Negotiation . . . . . . . . . . . . . . . . . . . 12
-   8.  GSSAPI Kerberos V5 Mechanism Type  . . . . . . . . . . . . . . 13
-     8.1   Mechanism Specific Changes . . . . . . . . . . . . . . . . 13
-     8.2   GSSAPI MIC Semantics . . . . . . . . . . . . . . . . . . . 14
-     8.3   GSSAPI WRAP Semantics  . . . . . . . . . . . . . . . . . . 16
-   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
-   10.   Normative References . . . . . . . . . . . . . . . . . . . . 20
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
-       Intellectual Property and Copyright Statements . . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006                [Page 2]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-1.  Introduction
-
-   The Microsoft Windows 2000 implementation of Kerberos contains new
-   encryption and checksum types for two reasons: for export reasons
-   early in the development process, 56 bit DES encryption could not be
-   exported, and because upon upgrade from Windows NT 4.0 to Windows
-   2000, accounts will not have the appropriate DES keying material to
-   do the standard DES encryption.  Furthermore, 3DES is not available
-   for export, and there was a desire to use a single flavor of
-   encryption in the product for both US and international products.
-
-   As a result, there are two new encryption types and one new checksum
-   type introduced in Microsoft Windows 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006                [Page 3]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006                [Page 4]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-3.  Key Generation
-
-   On upgrade from existing Windows NT domains, the user accounts would
-   not have a DES based key available to enable the use of DES base
-   encryption types specified in RFC 1510.  The key used for RC4-HMAC is
-   the same as the existing Windows NT key (NT Password Hash) for
-   compatibility reasons.  Once the account password is changed, the DES
-   based keys are created and maintained.  Once the DES keys are
-   available DES based encryption types can be used with Kerberos.
-
-   The RC4-HMAC String to key function is defined as follow:
-
-      String2Key(password)
-
-           K = MD4(UNICODE(password))
-
-   The RC4-HMAC keys are generated by using the Windows UNICODE version
-   of the password.  Each Windows UNICODE character is encoded in
-   little-endian format of 2 octets each.  Then performing an MD4
-   [RFC1320] hash operation on just the UNICODE characters of the
-   password (not including the terminating zero octets).
-
-   For an account with a password of "foo", this String2Key("foo") will
-   return:
-
-           0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe,
-           0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006                [Page 5]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-4.  Basic Operations
-
-   The MD5 HMAC function is defined in [RFC2104].  It is used in this
-   encryption type for checksum operations.  Refer to [RFC2104] for
-   details on its operation.  In this document this function is referred
-   to as HMAC(Key, Data) returning the checksum using the specified key
-   on the data.
-
-   The basic MD5 hash operation is used in this encryption type and
-   defined in [RFC1321].  In this document this function is referred to
-   as MD5(Data) returning the checksum of the data.
-
-   RC4 is a stream cipher licensed by RSA Data Security .  In this
-   document the function is referred to as RC4(Key, Data) returning the
-   encrypted data using the specified key on the data.
-
-   These encryption types use key derivation.  With each message, the
-   message type (T) is used as a component of the keying material.  This
-   table summarizes the different key derivation values used in the
-   various operations.  Note that these differ from the key derivations
-   used in other Kerberos encryption types.  T = the message type,
-   encoded as a little-endian four byte integer.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006                [Page 6]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-          1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with
-          the client key (T=1)
-          2.  AS-REP Ticket and TGS-REP Ticket (includes TGS session key
-          or application session key), encrypted with the service key
-          (T=2)
-          3.  AS-REP encrypted part (includes TGS session key or
-          application session key), encrypted with the client key (T=8)
-          4.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the
-          TGS session key (T=4)
-          5.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the
-          TGS authenticator subkey (T=5)
-          6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
-          keyed with the TGS session key (T=6)
-          7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes
-          TGS authenticator subkey), encrypted with the TGS session key
-           T=7)
-          8.  TGS-REP encrypted part (includes application session key),
-          encrypted with the TGS session key (T=8)
-          9.  TGS-REP encrypted part (includes application session key),
-          encrypted with the TGS authenticator subkey (T=8)
-          10.  AP-REQ Authenticator cksum, keyed with the application
-          session key (T=10)
-          11.  AP-REQ Authenticator (includes application authenticator
-          subkey), encrypted with the application session key (T=11)
-          12.  AP-REP encrypted part (includes application session
-          subkey), encrypted with the application session key (T=12)
-          13.  KRB-PRIV encrypted part, encrypted with a key chosen by
-          the application. Also for data encrypted with GSS Wrap (T=13)
-          14.  KRB-CRED encrypted part, encrypted with a key chosen by
-          the application (T=14)
-          15.  KRB-SAFE cksum, keyed with a key chosen by the
-          application. Also for data signed in GSS MIC (T=15)
-
-          Relative to RFC-1964 key uses:
-
-         T = 0 in the generation of sequence number for the MIC token
-         T = 0 in the generation of sequence number for the WRAP token
-         T = 0 in the generation of encrypted data for the WRAPPED token
-
-   All strings in this document are ASCII unless otherwise specified.
-   The lengths of ASCII encoded character strings include the trailing
-   terminator character (0).  The concat(a,b,c,...) function will return
-   the logical concatenation (left to right) of the values of the
-   arguments.  The nonce(n) function returns a pseudo-random number of
-   "n" octets.
-
-
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006                [Page 7]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-5.  Checksum Types
-
-   There is one checksum type used in this encryption type.  The
-   Kerberos constant for this type is:
-
-           #define KERB_CHECKSUM_HMAC_MD5 (-138)
-
-      The function is defined as follows:
-
-      K - is the Key
-      T - the message type, encoded as a little-endian four byte integer
-
-      CHKSUM(K, T, data)
-
-           Ksign = HMAC(K, "signaturekey")  //includes zero octet at end
-           tmp = MD5(concat(T, data))
-           CHKSUM = HMAC(Ksign, tmp)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006                [Page 8]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-6.  Encryption Types
-
-   There are two encryption types used in these encryption types.  The
-   Kerberos constants for these types are:
-
-           #define KERB_ETYPE_RC4_HMAC             23
-           #define KERB_ETYPE_RC4_HMAC_EXP         24
-
-   The basic encryption function is defined as follow:
-
-     T = the message type, encoded as a little-endian four byte integer.
-
-           OCTET L40[14] = "fortybits";
-           OCTET SK = "signaturekey";
-
-      The header field on the encrypted data in KDC messages is:
-
-           typedef struct _RC4_MDx_HEADER {
-               OCTET Checksum[16];
-               OCTET Confounder[8];
-           } RC4_MDx_HEADER, *PRC4_MDx_HEADER;
-
-
-           ENCRYPT (K, export, T, data)
-           {
-               struct EDATA {
-                   struct HEADER {
-                           OCTET Checksum[16];
-                           OCTET Confounder[8];
-                   } Header;
-                   OCTET Data[0];
-               } edata;
-
-               if (export){
-                   *((DWORD *)(L40+10)) = T;
-                   HMAC (K, L40, 10 + 4, K1);
-               }
-               else
-               {
-                   HMAC (K, &T, 4, K1);
-               }
-               memcpy (K2, K1, 16);
-               if (export) memset (K1+7, 0xAB, 9);
-
-               nonce (edata.Confounder, 8);
-               memcpy (edata.Data, data);
-
-               edata.Checksum = HMAC (K2, edata);
-
-
-
-Jaganathan, et al.       Expires January 9, 2006                [Page 9]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-               K3 = HMAC (K1, edata.Checksum);
-
-               RC4 (K3, edata.Confounder);
-               RC4 (K3, data.Data);
-           }
-
-           DECRYPT (K, export, T, edata)
-           {
-               // edata looks like
-               struct EDATA {
-                   struct HEADER {
-                           OCTET Checksum[16];
-                           OCTET Confounder[8];
-                   } Header;
-                   OCTET Data[0];
-               } edata;
-
-               if (export){
-                   *((DWORD *)(L40+10)) = T;
-                   HMAC (K, L40, 14, K1);
-               }
-               else
-               {
-                   HMAC (K, &T, 4, K1);
-               }
-               memcpy (K2, K1, 16);
-               if (export) memset (K1+7, 0xAB, 9);
-
-               K3 = HMAC (K1, edata.Checksum);
-
-               RC4 (K3, edata.Confounder);
-               RC4 (K3, edata.Data);
-
-
-               // verify generated and received checksums
-             checksum = HMAC (K2, concat(edata.Confounder, edata.Data));
-               if (checksum != edata.Checksum)
-                   printf("CHECKSUM ERROR  !!!!!!\n");
-           }
-
-   The KDC message is encrypted using the ENCRYPT function not including
-   the Checksum in the RC4_MDx_HEADER.
-
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States.
-   It is now used to recognize that the key length is of "exportable"
-   length.  In this description, the key size is actually 56-bits.
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006               [Page 10]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-   The pseudo-random operation [RFC3961] for both enctypes above is
-   defined as follows:
-
-           pseudo-random(K, S) = HMAC-SHA1(K, S)
-
-   where K is the protocol key and S is the input octet string.  HMAC-
-   SHA1 is defined in [RFC2104] and the output of HMAC-SHA1 is the 20-
-   octet digest.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006               [Page 11]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-7.  Key Strength Negotiation
-
-   A Kerberos client and server can negotiate over key length if they
-   are using mutual authentication.  If the client is unable to perform
-   full strength encryption, it may propose a key in the "subkey" field
-   of the authenticator, using a weaker encryption type.  The server
-   must then either return the same key or suggest its own key in the
-   subkey field of the AP reply message.  The key used to encrypt data
-   is derived from the key returned by the server.  If the client is
-   able to perform strong encryption but the server is not, it may
-   propose a subkey in the AP reply without first being sent a subkey in
-   the authenticator.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006               [Page 12]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-8.  GSSAPI Kerberos V5 Mechanism Type
-
-8.1   Mechanism Specific Changes
-
-   The GSSAPI per-message tokens also require new checksum and
-   encryption types.  The GSS-API per-message tokens are adapted to
-   support these new encryption types.  See [RFC1964] Section 1.2.2.
-
-   The only support quality of protection is:
-
-         #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0
-
-   When using this RC4 based encryption type, the sequence number is
-   always sent in big-endian rather than little-endian order.
-
-   The Windows 2000 implementation also defines new GSSAPI flags in the
-   initial token passed when initializing a security context.  These
-   flags are passed in the checksum field of the authenticator.  See
-   [RFC1964] Section 1.1.1.
-
-   GSS_C_DCE_STYLE - This flag was added for use with Microsoft's
-   implementation of DCE RPC, which initially expected three legs of
-   authentication.  Setting this flag causes an extra AP reply to be
-   sent from the client back to the server after receiving the server's
-   AP reply.  In addition, the context negotiation tokens do not have
-   GSSAPI per message tokens - they are raw AP messages that do not
-   include object identifiers.
-
-           #define GSS_C_DCE_STYLE                 0x1000
-
-   GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the
-   server that it should only allow the server application to identify
-   the client by name and ID, but not to impersonate the client.
-
-           #define GSS_C_IDENTIFY_FLAG             0x2000
-
-   GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the
-   client wants to be informed of extended error information.  In
-   particular, Windows 2000 status codes may be returned in the data
-   field of a Kerberos error message.  This allows the client to
-   understand a server failure more precisely.  In addition, the server
-   may return errors to the client that are normally handled at the
-   application layer in the server, in order to let the client try to
-   recover.  After receiving an error message, the client may attempt to
-   resubmit an AP request.
-
-           #define GSS_C_EXTENDED_ERROR_FLAG       0x4000
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006               [Page 13]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-   These flags are only used if a client is aware of these conventions
-   when using the SSPI on the Windows platform; they are not generally
-   used by default.
-
-   When NetBIOS addresses are used in the GSSAPI, they are identified by
-   the GSS_C_AF_NETBIOS value.  This value is defined as:
-
-           #define GSS_C_AF_NETBIOS                0x14
-
-   NetBios addresses are 16-octet addresses typically composed of 1 to
-   15 characters, trailing blank (ASCII char 20) filled, with a 16-th
-   octet of 0x0.
-
-8.2   GSSAPI MIC Semantics
-
-   The GSSAPI checksum type and algorithm is defined in Section 5.  Only
-   the first 8 octets of the checksum are used.  The resulting checksum
-   is stored in the SGN_CKSUM field .  See [RFC1964] Section 1.2 for
-   GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE).
-
-   The GSS_GetMIC token has the following format:
-
-        Byte no         Name        Description
-        0..1           TOK_ID     Identification field.
-                                  Tokens emitted by GSS_GetMIC() contain
-                                  the hex value 01 01 in this field.
-        2..3           SGN_ALG    Integrity algorithm indicator.
-                                  11 00 - HMAC
-        4..7           Filler     Contains ff ff ff ff
-        8..15          SND_SEQ    Sequence number field.
-        16..23         SGN_CKSUM  Checksum of "to-be-signed data",
-                                  calculated according to algorithm
-                                  specified in SGN_ALG field.
-
-   The MIC mechanism used for GSS MIC based messages is as follow:
-
-           GetMIC(Kss, direction, export, seq_num, data)
-           {
-                   struct Token {
-                          struct Header {
-                                 OCTET TOK_ID[2];
-                                 OCTET SGN_ALG[2];
-                                 OCTET Filler[4];
-                            };
-                          OCTET SND_SEQ[8];
-                          OCTET SGN_CKSUM[8];
-                   } Token;
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006               [Page 14]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-                   Token.TOK_ID = 01 01;
-                   Token.SGN_SLG = 11 00;
-                   Token.Filler = ff ff ff ff;
-
-                   // Create the sequence number
-
-                   if (direction == sender_is_initiator)
-                   {
-                           memset(Token.SEND_SEQ+4, 0xff, 4)
-                   }
-                   else if (direction == sender_is_acceptor)
-                   {
-                           memset(Token.SEND_SEQ+4, 0, 4)
-                   }
-                   Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24;
-                   Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16;
-                   Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8;
-                   Token.SEND_SEQ[3] = (seq_num & 0x000000ff);
-
-                   // Derive signing key from session key
-
-                   Ksign = HMAC(Kss, "signaturekey");
-                                     // length includes terminating null
-
-                   // Generate checksum of message - SGN_CKSUM
-                   //   Key derivation salt = 15
-
-                   Sgn_Cksum = MD5((int32)15, Token.Header, data);
-
-                   // Save first 8 octets of HMAC Sgn_Cksum
-
-                   Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
-                   memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
-
-                   // Encrypt the sequence number
-
-                   // Derive encryption key for the sequence number
-                   //   Key derivation salt = 0
-
-                   if (exportable)
-                   {
-                           Kseq = HMAC(Kss, "fortybits", (int32)0);
-                                        // len includes terminating null
-                           memset(Kseq+7, 0xab, 7)
-                   }
-                   else
-                   {
-                            Kseq = HMAC(Kss, (int32)0);
-
-
-
-Jaganathan, et al.       Expires January 9, 2006               [Page 15]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-                   }
-                   Kseq = HMAC(Kseq, Token.SGN_CKSUM);
-
-                   // Encrypt the sequence number
-
-                   RC4(Kseq, Token.SND_SEQ);
-           }
-
-
-8.3   GSSAPI WRAP Semantics
-
-   There are two encryption keys for GSSAPI message tokens, one that is
-   128 bits in strength, and one that is 56 bits in strength as defined
-   in Section 6.
-
-   All padding is rounded up to 1 byte.  One byte is needed to say that
-   there is 1 byte of padding.  The DES based mechanism type uses 8 byte
-   padding.  See [RFC1964] Section 1.2.2.3.
-
-   The RC4-HMAC GSS_Wrap() token has the following format:
-
-
-      Byte no          Name         Description
-        0..1           TOK_ID       Identification field.
-                                    Tokens emitted by GSS_Wrap() contain
-                                    the hex value 02 01 in this field.
-        2..3           SGN_ALG      Checksum algorithm indicator.
-                                    11 00 - HMAC
-        4..5           SEAL_ALG     ff ff - none
-                                    00 00 - DES-CBC
-                                    10 00 - RC4
-        6..7           Filler       Contains ff ff
-        8..15          SND_SEQ      Encrypted sequence number field.
-        16..23         SGN_CKSUM    Checksum of plaintext padded data,
-                                    calculated according to algorithm
-                                    specified in SGN_ALG field.
-        24..31         Confounder   Random confounder
-        32..last       Data         encrypted or plaintext padded data
-
-   The encryption mechanism used for GSS wrap based messages is as
-   follow:
-
-
-           WRAP(Kss, encrypt, direction, export, seq_num, data)
-           {
-                   struct Token {          // 32 octets
-                          struct Header {
-                                 OCTET TOK_ID[2];
-
-
-
-Jaganathan, et al.       Expires January 9, 2006               [Page 16]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-                                 OCTET SGN_ALG[2];
-                                 OCTET SEAL_ALG[2];
-                                 OCTET Filler[2];
-                          };
-                          OCTET SND_SEQ[8];
-                          OCTET SGN_CKSUM[8];
-                            OCTET Confounder[8];
-                   } Token;
-
-
-                   Token.TOK_ID = 02 01;
-                   Token.SGN_SLG = 11 00;
-                   Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00;
-                   Token.Filler = ff ff;
-
-                   // Create the sequence number
-
-                   if (direction == sender_is_initiator)
-                   {
-                           memset(&Token.SEND_SEQ[4], 0xff, 4)
-                   }
-                   else if (direction == sender_is_acceptor)
-                   {
-                           memset(&Token.SEND_SEQ[4], 0, 4)
-                   }
-                   Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24;
-                   Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16;
-                   Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8;
-                   Token.SEND_SEQ[3] = (seq_num & 0x000000ff);
-
-                   // Generate random confounder
-
-                   nonce(&Token.Confounder, 8);
-
-                   // Derive signing key from session key
-
-                   Ksign = HMAC(Kss, "signaturekey");
-
-                   // Generate checksum of message -
-                   //  SGN_CKSUM + Token.Confounder
-                   //   Key derivation salt = 15
-
-                   Sgn_Cksum = MD5((int32)15, Token.Header,
-                                   Token.Confounder);
-
-                   // Derive encryption key for data
-                   //   Key derivation salt = 0
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006               [Page 17]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-                   for (i = 0; i < 16; i++) Klocal[i] = Kss[i] ^ 0xF0;
-                                                           // XOR
-                   if (exportable)
-                   {
-                           Kcrypt = HMAC(Klocal, "fortybits", (int32)0);
-                                       // len includes terminating null
-                           memset(Kcrypt+7, 0xab, 7);
-                   }
-                   else
-                   {
-                           Kcrypt = HMAC(Klocal, (int32)0);
-                     }
-
-                   // new encryption key salted with seq
-
-                   Kcrypt = HMAC(Kcrypt, (int32)seq);
-
-                   // Encrypt confounder (if encrypting)
-
-                   if (encrypt)
-                           RC4(Kcrypt, Token.Confounder);
-
-                   // Sum the data buffer
-
-                   Sgn_Cksum += MD5(data);         // Append to checksum
-
-                   // Encrypt the data (if encrypting)
-
-                   if (encrypt)
-                           RC4(Kcrypt, data);
-
-                   // Save first 8 octets of HMAC Sgn_Cksum
-
-                   Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
-                   memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
-
-                   // Derive encryption key for the sequence number
-                   //   Key derivation salt = 0
-
-                   if (exportable)
-                   {
-                           Kseq = HMAC(Kss, "fortybits", (int32)0);
-                                       // len includes terminating null
-                           memset(Kseq+7, 0xab, 7)
-                   }
-                   else
-                   {
-                           Kseq = HMAC(Kss, (int32)0);
-
-
-
-Jaganathan, et al.       Expires January 9, 2006               [Page 18]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-                   }
-                   Kseq = HMAC(Kseq, Token.SGN_CKSUM);
-
-                   // Encrypt the sequence number
-
-                   RC4(Kseq, Token.SND_SEQ);
-
-                   // Encrypted message = Token + Data
-           }
-
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States.
-   It is now used to recognize that the key length is of "exportable"
-   length.  In this description, the key size is actually 56-bits.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006               [Page 19]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-9.  Security Considerations
-
-   Care must be taken in implementing this encryption type because it
-   uses a stream cipher.  If a different IV isn't used in each direction
-   when using a session key, the encryption is weak.  By using the
-   sequence number as an IV, this is avoided.
-
-10.  Normative References
-
-   [RFC1320]  Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320,
-              April 1992.
-
-   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-              April 1992.
-
-   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
-              Authentication Service (V5)", RFC 1510, September 1993.
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-
-Authors' Addresses
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006               [Page 20]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   John Brezak
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: jbrezak@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006               [Page 21]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Jaganathan, et al.       Expires January 9, 2006               [Page 22]
-
-
diff --git a/doc/standardisation/draft-jaganathan-rc4-hmac-01.txt b/doc/standardisation/draft-jaganathan-rc4-hmac-01.txt
deleted file mode 100644
index 1550e35de..000000000
--- a/doc/standardisation/draft-jaganathan-rc4-hmac-01.txt
+++ /dev/null
@@ -1,1177 +0,0 @@
-
-
-
-Internet Engineering Task Force                            K. Jaganathan
-Internet-Draft                                                    L. Zhu
-Expires: January 19, 2006                                      J. Brezak
-                                                   Microsoft Corporation
-                                                           July 18, 2005
-
-
-                 The RC4-HMAC Kerberos encryption type
-                    draft-jaganathan-rc4-hmac-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   The Microsoft Windows 2000 implementation of Kerberos introduces a
-   new encryption type based on the RC4 encryption algorithm and using
-   an MD5 HMAC for checksum.  This is offered as an alternative to using
-   the existing DES based encryption types.
-
-   The RC4-HMAC encryption types are used to ease upgrade of existing
-   Windows NT environments, provide strong crypto (128-bit key lengths),
-
-
-
-Jaganathan, et al.      Expires January 19, 2006                [Page 1]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-   and provide exportable (meet United States government export
-   restriction requirements) encryption.  This document describes the
-   implementation of those encryption types
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
-   3.  Key Generation . . . . . . . . . . . . . . . . . . . . . . . .  5
-   4.  Basic Operations . . . . . . . . . . . . . . . . . . . . . . .  6
-   5.  Checksum Types . . . . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Encryption Types . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  Key Strength Negotiation . . . . . . . . . . . . . . . . . . . 11
-   8.  GSSAPI Kerberos V5 Mechanism Type  . . . . . . . . . . . . . . 12
-     8.1   Mechanism Specific Changes . . . . . . . . . . . . . . . . 12
-     8.2   GSSAPI MIC Semantics . . . . . . . . . . . . . . . . . . . 13
-     8.3   GSSAPI WRAP Semantics  . . . . . . . . . . . . . . . . . . 15
-   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
-   10.   Normative References . . . . . . . . . . . . . . . . . . . . 19
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
-       Intellectual Property and Copyright Statements . . . . . . . . 21
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006                [Page 2]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-1.  Introduction
-
-   The Microsoft Windows 2000 implementation of Kerberos contains new
-   encryption and checksum types for two reasons: for export reasons
-   early in the development process, 56 bit DES encryption could not be
-   exported, and because upon upgrade from Windows NT 4.0 to Windows
-   2000, accounts will not have the appropriate DES keying material to
-   do the standard DES encryption.  Furthermore, 3DES is not available
-   for export, and there was a desire to use a single flavor of
-   encryption in the product for both US and international products.
-
-   As a result, there are two new encryption types and one new checksum
-   type introduced in Microsoft Windows 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006                [Page 3]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006                [Page 4]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-3.  Key Generation
-
-   On upgrade from existing Windows NT domains, the user accounts would
-   not have a DES based key available to enable the use of DES base
-   encryption types specified in RFC 4120.  The key used for RC4-HMAC is
-   the same as the existing Windows NT key (NT Password Hash) for
-   compatibility reasons.  Once the account password is changed, the DES
-   based keys are created and maintained.  Once the DES keys are
-   available DES based encryption types can be used with Kerberos.
-
-   The RC4-HMAC String to key function is defined as follow:
-
-      String2Key(password)
-
-           K = MD4(UNICODE(password))
-
-   The RC4-HMAC keys are generated by using the Windows UNICODE version
-   of the password.  Each Windows UNICODE character is encoded in
-   little-endian format of 2 octets each.  Then performing an MD4
-   [RFC1320] hash operation on just the UNICODE characters of the
-   password (not including the terminating zero octets).
-
-   For an account with a password of "foo", this String2Key("foo") will
-   return:
-
-           0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe,
-           0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006                [Page 5]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-4.  Basic Operations
-
-   The MD5 HMAC function is defined in [RFC2104].  It is used in this
-   encryption type for checksum operations.  Refer to[RFC2104]for
-   details on its operation.  In this document this function is referred
-   to as HMAC(Key, Data) returning the checksum using the specified key
-   on the data.
-
-   The basic MD5 hash operation is used in this encryption type and
-   defined in [RFC1321].  In this document this function is referred to
-   as MD5(Data) returning the checksum of the data.
-
-   RC4 is a stream cipher licensed by RSA Data Security .  In this
-   document the function is referred to as RC4(Key, Data) returning the
-   encrypted data using the specified key on the data.
-
-   These encryption types use key derivation.  With each message, the
-   message type (T) is used as a component of the keying material.  This
-   table summarizes the different key derivation values used in the
-   various operations.  Note that these differ from the key derivations
-   used in other Kerberos encryption types.  T = the message type,
-   encoded as a little-endian four byte integer.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006                [Page 6]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-          1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with
-          the client key (T=1)
-          2.  AS-REP Ticket and TGS-REP Ticket (includes TGS session key
-          or application session key), encrypted with the service key
-          (T=2)
-          3.  AS-REP encrypted part (includes TGS session key or
-          application session key), encrypted with the client key (T=8)
-          4.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the
-          TGS session key (T=4)
-          5.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the
-          TGS authenticator subkey (T=5)
-          6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
-          keyed with the TGS session key (T=6)
-          7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes
-          TGS authenticator subkey), encrypted with the TGS session key
-           T=7)
-          8.  TGS-REP encrypted part (includes application session key),
-          encrypted with the TGS session key (T=8)
-          9.  TGS-REP encrypted part (includes application session key),
-          encrypted with the TGS authenticator subkey (T=8)
-          10.  AP-REQ Authenticator cksum, keyed with the application
-          session key (T=10)
-          11.  AP-REQ Authenticator (includes application authenticator
-          subkey), encrypted with the application session key (T=11)
-          12.  AP-REP encrypted part (includes application session
-          subkey), encrypted with the application session key (T=12)
-          13.  KRB-PRIV encrypted part, encrypted with a key chosen by
-          the application. Also for data encrypted with GSS Wrap (T=13)
-          14.  KRB-CRED encrypted part, encrypted with a key chosen by
-          the application (T=14)
-          15.  KRB-SAFE cksum, keyed with a key chosen by the
-          application. Also for data signed in GSS MIC (T=15)
-
-          Relative to RFC-4121 key uses:
-
-         T = 0 in the generation of sequence number for the MIC token
-         T = 0 in the generation of sequence number for the WRAP token
-         T = 0 in the generation of encrypted data for the WRAPPED token
-
-   All strings in this document are ASCII unless otherwise specified.
-   The lengths of ASCII encoded character strings include the trailing
-   terminator character (0).  The concat(a,b,c,...) function will return
-   the logical concatenation (left to right) of the values of the
-   arguments.  The nonce(n) function returns a pseudo-random number of
-   "n" octets.
-
-
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006                [Page 7]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-5.  Checksum Types
-
-   There is one checksum type used in this encryption type.  The
-   Kerberos constant for this type is:
-
-           #define KERB_CHECKSUM_HMAC_MD5 (-138)
-
-      The function is defined as follows:
-
-      K - is the Key
-      T - the message type, encoded as a little-endian four byte integer
-
-      CHKSUM(K, T, data)
-
-           Ksign = HMAC(K, "signaturekey")  //includes zero octet at end
-           tmp = MD5(concat(T, data))
-           CHKSUM = HMAC(Ksign, tmp)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006                [Page 8]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-6.  Encryption Types
-
-   There are two encryption types used in these encryption types.  The
-   Kerberos constants for these types are:
-
-           #define KERB_ETYPE_RC4_HMAC             23
-           #define KERB_ETYPE_RC4_HMAC_EXP         24
-
-   The basic encryption function is defined as follow:
-
-     T = the message type, encoded as a little-endian four byte integer.
-
-           OCTET L40[14] = "fortybits";
-           OCTET SK = "signaturekey";
-
-      The header field on the encrypted data in KDC messages is:
-
-           typedef struct _RC4_MDx_HEADER {
-               OCTET Checksum[16];
-               OCTET Confounder[8];
-           } RC4_MDx_HEADER, *PRC4_MDx_HEADER;
-
-
-           ENCRYPT (K, export, T, data)
-           {
-               struct EDATA {
-                   struct HEADER {
-                           OCTET Checksum[16];
-                           OCTET Confounder[8];
-                   } Header;
-                   OCTET Data[0];
-               } edata;
-
-               if (export){
-                   *((DWORD *)(L40+10)) = T;
-                   HMAC (K, L40, 10 + 4, K1);
-               }
-               else
-               {
-                   HMAC (K, "&"T, 4, K1);
-               }
-               memcpy (K2, K1, 16);
-               if (export) memset (K1+7, 0xAB, 9);
-
-               nonce (edata.Confounder, 8);
-               memcpy (edata.Data, data);
-
-               edata.Checksum = HMAC (K2, edata);
-
-
-
-Jaganathan, et al.      Expires January 19, 2006                [Page 9]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-               K3 = HMAC (K1, edata.Checksum);
-
-               RC4 (K3, edata.Confounder);
-               RC4 (K3, data.Data);
-           }
-
-           DECRYPT (K, export, T, edata)
-           {
-               // edata looks like
-               struct EDATA {
-                   struct HEADER {
-                           OCTET Checksum[16];
-                           OCTET Confounder[8];
-                   } Header;
-                   OCTET Data[0];
-               } edata;
-
-               if (export){
-                   *((DWORD *)(L40+10)) = T;
-                   HMAC (K, L40, 14, K1);
-               }
-               else
-               {
-                   HMAC (K, "&"T, 4, K1);
-               }
-               memcpy (K2, K1, 16);
-               if (export) memset (K1+7, 0xAB, 9);
-
-               K3 = HMAC (K1, edata.Checksum);
-
-               RC4 (K3, edata.Confounder);
-               RC4 (K3, edata.Data);
-
-
-               // verify generated and received checksums
-             checksum = HMAC (K2, concat(edata.Confounder, edata.Data));
-               if (checksum != edata.Checksum)
-                   printf("CHECKSUM ERROR  !!!!!!\n");
-           }
-
-   The KDC message is encrypted using the ENCRYPT function not including
-   the Checksum in the RC4_MDx_HEADER.
-
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States.
-   It is now used to recognize that the key length is of "exportable"
-   length.  In this description, the key size is actually 56-bits.
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006               [Page 10]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-7.  Key Strength Negotiation
-
-   TA Kerberos client and server can negotiate over key length if they
-   are using mutual authentication.  If the client is unable to perform
-   full strength encryption, it may propose a key in the "subkey" field
-   of the authenticator, using a weaker encryption type.  The server
-   must then either return the same key or suggest its own key in the
-   subkey field of the AP reply message.  The key used to encrypt data
-   is derived from the key returned by the server.  If the client is
-   able to perform strong encryption but the server is not, it may
-   propose a subkey in the AP reply without first being sent a subkey in
-   the authenticator.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006               [Page 11]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-8.  GSSAPI Kerberos V5 Mechanism Type
-
-8.1   Mechanism Specific Changes
-
-   The GSSAPI per-message tokens also require new checksum and
-   encryption types.  The GSS-API per-message tokens are adapted to
-   support these new encryption types .  See [RFC4121] .
-
-   The only support quality of protection is:
-
-         #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0
-
-   When using this RC4 based encryption type, the sequence number is
-   always sent in big-endian rather than little-endian order.
-
-   The Windows 2000 implementation also defines new GSSAPI flags in the
-   initial token passed when initializing a security context.  These
-   flags are passed in the checksum field of the authenticator.  See
-   [RFC4121] .
-
-   GSS_C_DCE_STYLE - This flag was added for use with Microsoft's
-   implementation of DCE RPC, which initially expected three legs of
-   authentication.  Setting this flag causes an extra AP reply to be
-   sent from the client back to the server after receiving the serverAEs
-   AP reply.  In addition, the context negotiation tokens do not have
-   GSSAPI per message tokens - they are raw AP messages that do not
-   include object identifiers.
-
-           #define GSS_C_DCE_STYLE                 0x1000
-
-   GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the
-   server that it should only allow the server application to identify
-   the client by name and ID, but not to impersonate the client.
-
-           #define GSS_C_IDENTIFY_FLAG             0x2000
-
-   GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the
-   client wants to be informed of extended error information.  In
-   particular, Windows 2000 status codes may be returned in the data
-   field of a Kerberos error message.  This allows the client to
-   understand a server failure more precisely.  In addition, the server
-   may return errors to the client that are normally handled at the
-   application layer in the server, in order to let the client try to
-   recover.  After receiving an error message, the client may attempt to
-   resubmit an AP request.
-
-           #define GSS_C_EXTENDED_ERROR_FLAG       0x4000
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006               [Page 12]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-   These flags are only used if a client is aware of these conventions
-   when using the SSPI on the Windows platform; they are not generally
-   used by default.
-
-   When NetBIOS addresses are used in the GSSAPI, they are identified by
-   the GSS_C_AF_NETBIOS value.  This value is defined as:
-
-           #define GSS_C_AF_NETBIOS                0x14
-
-   NetBios addresses are 16-octet addresses typically composed of 1 to
-   15 characters, trailing blank (ASCII char 20) filled, with a 16-th
-   octet of 0x0.
-
-8.2   GSSAPI MIC Semantics
-
-   The GSSAPI checksum type and algorithm is defined in Section 5.  Only
-   the first 8 octets of the checksum are used.  The resulting checksum
-   is stored in the SGN_CKSUM field .  See [RFC4121] for GSS_GetMIC()
-   and GSS_Wrap(conf_flag=FALSE).
-
-   The GSS_GetMIC token has the following format:
-
-        Byte no         Name       Description
-        0..1           TOK_ID     Identification field.
-                                  Tokens emitted by GSS_GetMIC() contain
-                                  the hex value 01 01 in this field.
-        2..3           SGN_ALG    Integrity algorithm indicator.
-                                  11 00 - HMAC
-        4..7           Filler     Contains ff ff ff ff
-        8..15          SND_SEQ    Sequence number field.
-        6..23         SGN_CKSUM  Checksum of "to-be-signed data",
-                                 calculated according to algorithm
-                                 specified in SGN_ALG field.
-
-   The MIC mechanism used for GSS MIC based messages is as follow:
-
-           GetMIC(Kss, direction, export, seq_num, data)
-           {
-                   struct Token {
-                          struct Header {
-                                 OCTET TOK_ID[2];
-                                 OCTET SGN_ALG[2];
-                                 OCTET Filler[4];
-                            };
-                          OCTET SND_SEQ[8];
-                          OCTET SGN_CKSUM[8];
-                   } Token;
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006               [Page 13]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-                   Token.TOK_ID = 01 01;
-                   Token.SGN_SLG = 11 00;
-                   Token.Filler = ff ff ff ff;
-
-                   // Create the sequence number
-
-                   if (direction == sender_is_initiator)
-                   {
-                           memset(Token.SEND_SEQ+4, 0xff, 4)
-                   }
-                   else if (direction == sender_is_acceptor)
-                   {
-                           memset(Token.SEND_SEQ+4, 0, 4)
-                   }
-                   Token.SEND_SEQ[0] = (seq_num "&" 0xff000000) >> 24;
-                   Token.SEND_SEQ[1] = (seq_num "&" 0x00ff0000) >> 16;
-                   Token.SEND_SEQ[2] = (seq_num "&" 0x0000ff00) >> 8;
-                   Token.SEND_SEQ[3] = (seq_num "&" 0x000000ff);
-
-                   // Derive signing key from session key
-
-                   Ksign = HMAC(Kss, "signaturekey");
-                                     // length includes terminating null
-
-                   // Generate checksum of message - SGN_CKSUM
-                   //   Key derivation salt = 15
-
-                   Sgn_Cksum = MD5((int32)15, Token.Header, data);
-
-                   // Save first 8 octets of HMAC Sgn_Cksum
-
-                   Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
-                   memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
-
-                   // Encrypt the sequence number
-
-                   // Derive encryption key for the sequence number
-                   //   Key derivation salt = 0
-
-                   if (exportable)
-                   {
-                           Kseq = HMAC(Kss, "fortybits", (int32)0);
-                                        // len includes terminating null
-                           memset(Kseq+7, 0xab, 7)
-                   }
-                   else
-                   {
-                            Kseq = HMAC(Kss, (int32)0);
-
-
-
-Jaganathan, et al.      Expires January 19, 2006               [Page 14]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-                   }
-                   Kseq = HMAC(Kseq, Token.SGN_CKSUM);
-
-                   // Encrypt the sequence number
-
-                   RC4(Kseq, Token.SND_SEQ);
-           }
-
-
-8.3   GSSAPI WRAP Semantics
-
-   There are two encryption keys for GSSAPI message tokens, one that is
-   128 bits in strength, and one that is 56 bits in strength as defined
-   in Section 6.
-
-   All padding is rounded up to 1 byte.  One byte is needed to say that
-   there is 1 byte of padding.  The DES based mechanism type uses 8 byte
-   padding.  See [RFC4121] .
-
-   The RC4-HMAC GSS_Wrap() token has the following format:
-
-
-      Byte no          Name         Description
-        0..1           TOK_ID       Identification field.
-                                    Tokens emitted by GSS_Wrap() contain
-                                    the hex value 02 01 in this field.
-        2..3           SGN_ALG      Checksum algorithm indicator.
-                                    11 00 - HMAC
-        4..5           SEAL_ALG     ff ff - none
-                                    00 00 - DES-CBC
-                                    10 00 - RC4
-        6..7           Filler       Contains ff ff
-        8..15          SND_SEQ      Encrypted sequence number field.
-        16..23         SGN_CKSUM    Checksum of plaintext padded data,
-                                    calculated according to algorithm
-                                    specified in SGN_ALG field.
-        24..31         Confounder   Random confounder
-        32..last       Data         encrypted or plaintext padded data
-
-   The encryption mechanism used for GSS wrap based messages is as
-   follow:
-
-
-           WRAP(Kss, encrypt, direction, export, seq_num, data)
-           {
-                   struct Token {          // 32 octets
-                          struct Header {
-                                 OCTET TOK_ID[2];
-
-
-
-Jaganathan, et al.      Expires January 19, 2006               [Page 15]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-                                 OCTET SGN_ALG[2];
-                                 OCTET SEAL_ALG[2];
-                                 OCTET Filler[2];
-                          };
-                          OCTET SND_SEQ[8];
-                          OCTET SGN_CKSUM[8];
-                            OCTET Confounder[8];
-                   } Token;
-
-
-                   Token.TOK_ID = 02 01;
-                   Token.SGN_SLG = 11 00;
-                   Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00;
-                   Token.Filler = ff ff;
-
-                   // Create the sequence number
-
-                   if (direction == sender_is_initiator)
-                   {
-                           memset("&"Token.SEND_SEQ[4], 0xff, 4)
-                   }
-                   else if (direction == sender_is_acceptor)
-                   {
-                           memset("&"Token.SEND_SEQ[4], 0, 4)
-                   }
-                   Token.SEND_SEQ[0] = (seq_num "&" 0xff000000) >> 24;
-                   Token.SEND_SEQ[1] = (seq_num "&" 0x00ff0000) >> 16;
-                   Token.SEND_SEQ[2] = (seq_num "&" 0x0000ff00) >> 8;
-                   Token.SEND_SEQ[3] = (seq_num "&" 0x000000ff);
-
-                   // Generate random confounder
-
-                   nonce("&"Token.Confounder, 8);
-
-                   // Derive signing key from session key
-
-                   Ksign = HMAC(Kss, "signaturekey");
-
-                   // Generate checksum of message -
-                   //  SGN_CKSUM + Token.Confounder
-                   //   Key derivation salt = 15
-
-                   Sgn_Cksum = MD5((int32)15, Token.Header,
-                                   Token.Confounder);
-
-                   // Derive encryption key for data
-                   //   Key derivation salt = 0
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006               [Page 16]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-                   for (i = 0; i "<" 16; i++) Klocal[i] = Kss[i] ^ 0xF0;
-           // XOR
-                   if (exportable)
-                   {
-                           Kcrypt = HMAC(Klocal, "fortybits", (int32)0);
-                                       // len includes terminating null
-                           memset(Kcrypt+7, 0xab, 7);
-                   }
-                   else
-                   {
-                           Kcrypt = HMAC(Klocal, (int32)0);
-                     }
-
-                   // new encryption key salted with seq
-
-                   Kcrypt = HMAC(Kcrypt, (int32)seq);
-
-                   // Encrypt confounder (if encrypting)
-
-                   if (encrypt)
-                           RC4(Kcrypt, Token.Confounder);
-
-                   // Sum the data buffer
-
-                   Sgn_Cksum += MD5(data);         // Append to checksum
-
-                   // Encrypt the data (if encrypting)
-
-                   if (encrypt)
-                           RC4(Kcrypt, data);
-
-                   // Save first 8 octets of HMAC Sgn_Cksum
-
-                   Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
-                   memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
-
-                   // Derive encryption key for the sequence number
-                   //   Key derivation salt = 0
-
-                   if (exportable)
-                   {
-                           Kseq = HMAC(Kss, "fortybits", (int32)0);
-                                       // len includes terminating null
-                           memset(Kseq+7, 0xab, 7)
-                   }
-                   else
-                   {
-                           Kseq = HMAC(Kss, (int32)0);
-
-
-
-Jaganathan, et al.      Expires January 19, 2006               [Page 17]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-                   }
-                   Kseq = HMAC(Kseq, Token.SGN_CKSUM);
-
-                   // Encrypt the sequence number
-
-                   RC4(Kseq, Token.SND_SEQ);
-
-                   // Encrypted message = Token + Data
-           }
-
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States.
-   It is now used to recognize that the key length is of "exportable"
-   length.  In this description, the key size is actually 56-bits.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006               [Page 18]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-9.  Security Considerations
-
-   Care must be taken in implementing this encryption type because it
-   uses a stream cipher.  If a different IV isn't used in each direction
-   when using a session key, the encryption is weak.  By using the
-   sequence number as an IV, this is avoided.  The Windows
-   implementation of Kerberos uses a minimum RC4 key strength of 128
-   bits.  A discussion of the security considerations when using HMACs
-   is present in  [RFC2104] .
-
-10.  Normative References
-
-   [RFC1320]  Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320,
-              April 1992.
-
-   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-              April 1992.
-
-   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-
-Authors' Addresses
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006               [Page 19]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   John Brezak
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: jbrezak@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006               [Page 20]
-
-Internet-Draft    The RC4-HMAC Kerberos encryption type        July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Jaganathan, et al.      Expires January 19, 2006               [Page 21]
-
-
diff --git a/doc/standardisation/draft-josefsson-kerberos5-starttls-00.txt b/doc/standardisation/draft-josefsson-kerberos5-starttls-00.txt
deleted file mode 100644
index e5be859ae..000000000
--- a/doc/standardisation/draft-josefsson-kerberos5-starttls-00.txt
+++ /dev/null
@@ -1,447 +0,0 @@
-Network Working Group                                       S. Josefsson
-Internet-Draft                                         November 13, 2004
-Expires: May 14, 2005
-
-
-          Using Transport Layer Security (TLS) with Kerberos 5
-                 draft-josefsson-kerberos5-starttls-00
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on May 14, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document specify how the Transport Layer Security (TLS) protocol
-   is used in conjunction with the Kerberos 5 protocol.
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires May 14, 2005                  [Page 1]
-
-Internet-Draft         Using TLS with Kerberos 5           November 2004
-
-
-Table of Contents
-
-   1.  Introduction and Background  . . . . . . . . . . . . . . . . .  3
-   2.  Extension Mechanism for TCP/IP transport . . . . . . . . . . .  4
-   3.  Kerberos 5 STARTTLS Extension  . . . . . . . . . . . . . . . .  4
-     3.1   STARTTLS requested by client (extension 1) . . . . . . . .  4
-     3.2   STARTTLS request accepted by server (extension 2)  . . . .  5
-     3.3   Proceeding after successful TLS negotiation  . . . . . . .  5
-     3.4   Proceeding after failed TLS negotiation  . . . . . . . . .  5
-     3.5   STARTTLS aware KDC Discovery . . . . . . . . . . . . . . .  5
-     3.6   Initial Authentication via TLS . . . . . . . . . . . . . .  5
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-   5.1   Normative References . . . . . . . . . . . . . . . . . . . .  6
-   5.2   Informative References . . . . . . . . . . . . . . . . . . .  6
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  7
-       Intellectual Property and Copyright Statements . . . . . . . .  8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires May 14, 2005                  [Page 2]
-
-Internet-Draft         Using TLS with Kerberos 5           November 2004
-
-
-1.  Introduction and Background
-
-   This document describe how Shishi, a Kerberos 5 [1] implementation,
-   upgrade communication between clients and Key Distribution Centers
-   (KDCs) to use the Transport Layer Security (TLS) [2] protocol.
-
-   The TLS protocol offer integrity and privacy protected exchanges that
-   can be authentication using X.509 certificates, OpenPGP keys [6], and
-   user name and passwords via SRP [5].
-
-   An inconclusive list of the motivation for using TLS with Kerberos 5
-   is given below.
-
-   o  Explicit server authentication of the KDC to the client.  In
-      traditional Kerberos 5, authentication of the KDC is proved as a
-      side effect that the KDC knows your encryption key (i.e., your
-      password).
-
-   o  Flexible authentication against KDC.  Kerberos 5 assume the user
-      knows a key (usually in the form of a password).  Sometimes
-      external factors make this hard to fulfill.  In some situations,
-      users are equipped with smart cards with a RSA authentication key.
-      In others, users have a OpenPGP client on their desktop, with a
-      public OpenPGP key known to the server.  In some situations, the
-      policy may be that password authentication may only be done
-      through SRP.
-
-   o  Kerberos exchanges are privacy protected.  Part of many Kerberos
-      packets are transfered without privacy protection (i.e.,
-      encryption).  That part contains information, such as the client
-      principal name, the server principal name, the encryption types
-      supported by the client, the lifetime of tickets, etc.  Revealing
-      such information is, in some threat models, considered a problem.
-
-   o  Prevents downgrade attacks affecting encryption types.  The
-      encryption type of the ticket in KDC-REQ are sent in the clear in
-      Kerberos 5.  This allows an attacker to replace the encryption
-      type with a compromised mechanisms, e.g.  56-bit DES.  Since
-      clients in general cannot know the encryption types other servers
-      support, it is difficult for the client to detect if there was a
-      man-in-the-middle or if the remote server simply did not support a
-      stronger mechanism.  Clients could chose to refuse 56-bit DES
-      altogether, but in some environments this leads to operational
-      difficulties.
-
-   o  The TLS protocol has been studied by many parties.  In some threat
-      models, the designer prefer to reduce the number of protocols that
-      can hurt the overall system security if they are compromised.
-
-
-
-Josefsson                 Expires May 14, 2005                  [Page 3]
-
-Internet-Draft         Using TLS with Kerberos 5           November 2004
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [4].
-
-2.  Extension Mechanism for TCP/IP transport
-
-   Kerberos 5 require Key Distribution Centers (KDCs) to accept requests
-   over TCP.  Each request and response is prefixed by 4 octets,
-   encoding an integer in network byte order, that indicate the length
-   of the packet.  The high bit of the 4 octet length field was reserved
-   for future expansion.  Servers that do not understand how to
-   interpret a set high bit are required to return a KRB-ERROR with the
-   KRB_ERR_FIELD_TOOLONG error code, and to close the TCP stream.
-
-   We will use the reserved bit to provide an extension mechanism.  When
-   the reserved high bit is set, the remaining 31 bits of the 4 octets
-   are treated as an extensible typed hole, and thus form a 31 bit
-   integer enumerating various extensions.  Each of the values indicate
-   a specific extended operation mode, two of which are used and defined
-   here, and the rest are left for others to use.
-
-   If the KDC do not understand a requested extension, it MUST return a
-   KRB-ERROR with a KRB_ERR_FIELD_TOOLONG value (prefixed by the 4 octet
-   length integer, with the high bit clear, as usual) and close the TCP
-   stream.
-
-   The following table specify the meaning of the 31 lower bits in the 4
-   octet field, when the high bit is set:
-
-   0               RESERVED.
-   1               STARTTLS requested by client.
-   2               STARTTLS request accepted by server.
-   3...2147483647  AVAILABLE for registration (via bug-shishi@josefsson.org)
-.
-   2147483648      RESERVED.
-
-
-3.  Kerberos 5 STARTTLS Extension
-
-3.1  STARTTLS requested by client (extension 1)
-
-   When this message is sent by the client, the client is requesting the
-   server to start TLS negotiation on the TCP stream.  The client MUST
-   NOT start TLS negotiation immediately.  Instead, the client wait for
-   either a KRB-ERROR (sent normally, prefixed by a 4 octet length
-   integer) indicating the server do not understand the set high bit, or
-   4 octets which is to be interpreted as an integer in network byte
-   order, where the high bit is set and the remaining 31 bit are
-   interpreted as an integer specifying ``STARTTLS request accepted by
-
-
-
-Josefsson                 Expires May 14, 2005                  [Page 4]
-
-Internet-Draft         Using TLS with Kerberos 5           November 2004
-
-
-   server'' (extension 2).  In the first case, the client infer that the
-   server do not understand (or wish to support) STARTTLS, and can
-   re-try using normal TCP, if unprotected Kerberos 5 exchanges are
-   acceptable to the client policy.  In the latter case, it should
-   invoke TLS negotiation on the stream.  If any other data is received,
-   the client MUST close the TCP stream.
-
-3.2  STARTTLS request accepted by server (extension 2)
-
-   This message should be sent by the server when it has received the
-   extension 1 message.  The message is an acknowledgment of the
-   client's request to initiate STARTTLS on the channel.  The server
-   MUST then invoke a TLS negotiation.
-
-3.3  Proceeding after successful TLS negotiation
-
-   If the TLS negotiation ended successfully, possibly also considering
-   client or server policies, the exchange within the TLS protected
-   stream is performed like normal UDP Kerberos 5 exchanges, i.e., there
-   is no TCP 4 octet length field before each packet.  Instead each
-   Kerberos packet MUST be sent within one TLS record, so the
-   application can use the TLS record length as the Kerberos 5 packet
-   length.
-
-3.4  Proceeding after failed TLS negotiation
-
-   If the TLS negotiation fails, possibly due to client or server policy
-   (e.g., inadequate support of encryption types in TLS, or lack of
-   client or server authentication) the entity that detect the failure
-   MUST disconnected the connection.  It is expected that any error
-   messages that explain the error condition is transfered by TLS.
-
-3.5  STARTTLS aware KDC Discovery
-
-   Section 7.2.3 of Kerberos 5 [1] describe how Domain Name System (DNS)
-   SRV records [3] can be used to find the address of an KDC.  To locate
-   a KDC that support the STARTTLS extension, we use the "_tls" domain.
-   For example:
-
-   _kerberos._tls._tcp.EXAMPLE.COM.   IN      SRV     0 0 88 kdc1.example.com.
-   _kerberos._tls._tcp.EXAMPLE.COM.   IN      SRV     1 0 88 kdc2.example.com.
-
-
-3.6  Initial Authentication via TLS
-
-   The server MAY consider the authentication performed by the TLS
-   exchange as sufficient to issue Kerberos 5 tickets to the client,
-   without requiring, e.g., pre-authentication.  However, it is not an
-
-
-
-Josefsson                 Expires May 14, 2005                  [Page 5]
-
-Internet-Draft         Using TLS with Kerberos 5           November 2004
-
-
-   error to require or use pre-authentication as well.
-
-   The client may also indicate that it wishes to use TLS both for
-   authentication and data protection by using the NULL encryption type
-   in its request.  The server can decide from its local policy whether
-   or not issuing tickets based solely on TLS authentication, and
-   whether NULL encryption within TLS, is acceptable or not.
-
-4.  Security Considerations
-
-   Because the initial token is not protected, it is possible for an
-   active attacker to make it appear to the client that the server do
-   not support this extension.  It is up to client configuration to
-   disallow non-TLS connections, if that vulnerability is deemed
-   unacceptable.  For interoperability, we suggest the default behaviour
-   should be to allow automatic fall back to TCP or UDP.
-
-   The security considerations of both TLS and Kerberos 5 are inherited.
-   Using TLS for authentication and/or data protection together with
-   Kerberos alter the authentication logic fundamentally.  Thus, it may
-   be that even if the TLS and Kerberos 5 protocols and implementations
-   were secure, the combination of TLS and Kerberos 5 described here
-   could be insecure.
-
-   No channel bindings are provided in the Kerberos messages.  It is an
-   open question whether, and how, this could be solved.  One idea for
-   solving this may be to specify a new encryption algorithm in Kerberos
-   5 that is similar to the NULL encryption algorithm, but also include
-   the TLS session identifier.
-
-5.  References
-
-5.1  Normative References
-
-   [1]  Neuman, C., "The Kerberos Network Authentication Service (V5)",
-        draft-ietf-krb-wg-kerberos-clarifications-07 (work in progress),
-        September 2004.
-
-   [2]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-        2246, January 1999.
-
-   [3]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
-        specifying the location of services (DNS SRV)", RFC 2782,
-        February 2000.
-
-5.2  Informative References
-
-   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-
-
-
-Josefsson                 Expires May 14, 2005                  [Page 6]
-
-Internet-Draft         Using TLS with Kerberos 5           November 2004
-
-
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [5]  Taylor, D., "Using SRP for TLS Authentication",
-        draft-ietf-tls-srp-08 (work in progress), August 2004.
-
-   [6]  Mavroyanopoulos, N., "Using OpenPGP keys for TLS
-        authentication", draft-ietf-tls-openpgp-keys-05 (work in
-        progress), April 2004.
-
-
-Author's Address
-
-   Simon Josefsson
-
-   EMail: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires May 14, 2005                  [Page 7]
-
-Internet-Draft         Using TLS with Kerberos 5           November 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set for
-th therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Josefsson                 Expires May 14, 2005                  [Page 8]
\ No newline at end of file
diff --git a/doc/standardisation/draft-josefsson-kerberos5-starttls-01.txt b/doc/standardisation/draft-josefsson-kerberos5-starttls-01.txt
deleted file mode 100644
index 35a790dbb..000000000
--- a/doc/standardisation/draft-josefsson-kerberos5-starttls-01.txt
+++ /dev/null
@@ -1,672 +0,0 @@
-
-
-
-Network Working Group                                       S. Josefsson
-Internet-Draft                                                       SJD
-Intended status: Standards Track                         October 4, 2006
-Expires: April 7, 2007
-
-
-   Using Kerberos V5 over the Transport Layer Security (TLS) protocol
-                 draft-josefsson-kerberos5-starttls-01
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 7, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires April 7, 2007                 [Page 1]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-Abstract
-
-   This document specify how the Kerberos V5 protocol can be transported
-   over the Transport Layer Security (TLS) protocol, to provide
-   additional security features.
-
-
-Table of Contents
-
-   1.  Introduction and Background  . . . . . . . . . . . . . . . . .  3
-   2.  Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . .  5
-   3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-   4.  STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . .  7
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires April 7, 2007                 [Page 2]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-1.  Introduction and Background
-
-   This document describe how a Kerberos V5 [2] implementation may
-   upgrade communication between clients and Key Distribution Centers
-   (KDCs) to use the Transport Layer Security (TLS) [4] protocol.
-
-   The TLS protocol offer integrity and privacy protected exchanges that
-   can be authentication using X.509 certificates, OpenPGP keys [7], and
-   user name and passwords via SRP [6].
-
-   There are several reasons to use Kerberos V5 over TLS.
-
-   o  Kerberos exchanges are privacy protected.  Part of many Kerberos
-      packets are transfered without privacy protection (i.e.,
-      encryption).  That part contains information, such as the client
-      principal name, the server principal name, the encryption types
-      supported by the client, the lifetime of tickets, etc.  Revealing
-      such information is, in some threat models, considered a problem.
-
-
-   o  Prevents downgrade attacks affecting encryption types.  The
-      encryption type of the ticket in KDC-REQ are sent in the clear in
-      Kerberos 5.  This allows an attacker to replace the encryption
-      type with a compromised mechanisms, e.g., 56-bit DES.  Since
-      clients in general cannot know the encryption types other servers
-      support, it is difficult for the client to detect if there was a
-      man-in-the-middle or if the remote server simply did not support a
-      stronger mechanism.  Clients could chose to refuse, e.g., 56-bit
-      DES altogether, but in some environments this leads to operational
-      difficulties.
-
-
-   o  Additional authentication against the KDC.  In some situations,
-      users are equipped with smart cards with a RSA authentication key.
-      In others, users have a OpenPGP client on their desktop, with a
-      public OpenPGP key known to the server.  In some situations, the
-      policy may be that password authentication may only be done
-      through SRP.
-
-
-   o  The TLS protocol has been studied by many parties.  In some threat
-      models, the designer prefer to reduce the number of protocols that
-      can hurt the overall system security if they are compromised.
-
-
-   o  Explicit server authentication of the KDC to the client.  In
-      traditional Kerberos 5, authentication of the KDC is proved as a
-      side effect that the KDC knows your encryption key (i.e., your
-
-
-
-Josefsson                 Expires April 7, 2007                 [Page 3]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-      password).
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [1].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires April 7, 2007                 [Page 4]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-2.  Kerberos V5 STARTTLS Extension
-
-   The STARTTLS extension uses the Kerberos V5 TCP extension mechanism
-   [3].  The extension uses bit #TBD in the extension bitmask.
-
-   The protocol is as follows.  After the server has sent the 4-octet
-   value 0x00000000 to indicate support of this extension, the stream
-   will be controlled by the TLS protocol and its framing.  The TLS
-   protocol is initiated by the client.
-
-   Typically, the client initiate the TLS handshake protocol by sending
-   a client hello, and the server responds, and the handshake continues
-   until it either succeed or fails.
-
-   If for any reason the handshake fails, the STARTTLS protocol will
-   also fail, and the TLS error is used as the error indication.
-
-   If the handshake succeeds, the Kerberos V5 authentication protocol is
-   performed within the protected TLS channel, like a normal TCP
-   Kerberos V5 exchange.  In particular, this means that every Kerberos
-   V5 packet will be prefixed by a 4-octet length field, that indicate
-   the length of the Kerberos V5 packet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires April 7, 2007                 [Page 5]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-3.  Examples
-
-   A complete packet flow for a successful AS-REQ/REP exchange protected
-   by this mechanism will be as follows.  The "STARTTLS-bit" is a
-   4-octet value with only the bit allocated for this extension set.
-
-       Client                                               Server
-
-        [ Kerberos V5 TCP extension mechanism negotiation starts ]
-
-       [0x70000000 & STARTTLS-bit]  -------->
-                                                       [0x00000000]
-                                    <--------
-
-                            [ TLS negotiation starts ]
-
-
-       ClientHello                  -------->
-                                                       ServerHello
-                                                      Certificate*
-                                                ServerKeyExchange*
-                                               CertificateRequest*
-                                    <--------      ServerHelloDone
-       Certificate*
-       ClientKeyExchange
-       CertificateVerify*
-       [ChangeCipherSpec]
-       Finished                     -------->
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-
-                       [ Kerberos V5 negotiation starts ]
-
-       Kerberos V5 AS-REQ           -------->
-                                                Kerberos V5 AS-REP
-                                    <--------
-
-       * Indicates optional or situation-dependent messages that are not
-         always sent.
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires April 7, 2007                 [Page 6]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-4.  STARTTLS aware KDC Discovery
-
-   Section 7.2.3 of Kerberos V5 [2] describe how Domain Name System
-   (DNS) SRV records [5] can be used to find the address of an KDC.
-   Using the terminology of Section 7.2.3 of RFC 4120, we define a new
-   Proto of "tls" to indicate that the particular KDC is intended to
-   support this STARTTLS extension.  The Service, Realm, TTL, Class,
-   SRV, Priority, Weight, Port and Target have the same meaning as in
-   RFC 4120.
-
-   For example:
-
-   _kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
-   _kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires April 7, 2007                 [Page 7]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-5.  IANA Considerations
-
-   The IANA is requested to allocate a bit in the "Kerberos TCP
-   Extensions" registry for the extension described in this document, as
-   per [3].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires April 7, 2007                 [Page 8]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-6.  Security Considerations
-
-   The security considerations in Kerberos V5, TLS, and the extension
-   mechanism framework are inherited.
-
-   To protect against the inherent downgrade attack in the extension
-   framework, it is suggested that implementations offer a policy to
-   require that this extension is successfully negotiated.  For
-   interoperability with implementations that do not support this
-   extension, it is suggested that the policy is disabled by default.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires April 7, 2007                 [Page 9]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-7.  References
-
-7.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
-        Network Authentication Service (V5)", RFC 4120, July 2005.
-
-   [3]  Josefsson, S., "Extended Kerberos Version 5 Key Distribution
-        Center (KDC) Exchanges Over  TCP",
-        draft-ietf-krb-wg-tcp-expansion-01 (work in progress),
-        September 2006.
-
-   [4]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
-        Protocol Version 1.1", RFC 4346, April 2006.
-
-   [5]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
-        specifying the location of services (DNS SRV)", RFC 2782,
-        February 2000.
-
-7.2.  Informative References
-
-   [6]  Taylor, D., "Using SRP for TLS Authentication",
-        draft-ietf-tls-srp-12 (work in progress), June 2006.
-
-   [7]  Mavroyanopoulos, N., "Using OpenPGP keys for TLS
-        authentication", draft-ietf-tls-openpgp-keys-10 (work in
-        progress), June 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires April 7, 2007                [Page 10]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-Author's Address
-
-   Simon Josefsson
-   SJD
-
-   Email: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires April 7, 2007                [Page 11]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Josefsson                 Expires April 7, 2007                [Page 12]
-
diff --git a/doc/standardisation/draft-josefsson-kerberos5-starttls-02.txt b/doc/standardisation/draft-josefsson-kerberos5-starttls-02.txt
deleted file mode 100644
index 5793b7053..000000000
--- a/doc/standardisation/draft-josefsson-kerberos5-starttls-02.txt
+++ /dev/null
@@ -1,672 +0,0 @@
-
-
-
-Network Working Group                                       S. Josefsson
-Internet-Draft                                                       SJD
-Intended status: Standards Track                        October 21, 2006
-Expires: April 24, 2007
-
-
-   Using Kerberos V5 over the Transport Layer Security (TLS) protocol
-                 draft-josefsson-kerberos5-starttls-02
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 24, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires April 24, 2007                 [Page 1]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-Abstract
-
-   This document specify how the Kerberos V5 protocol can be transported
-   over the Transport Layer Security (TLS) protocol, to provide
-   additional security features.
-
-
-Table of Contents
-
-   1.  Introduction and Background  . . . . . . . . . . . . . . . . .  3
-   2.  Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . .  5
-   3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-   4.  STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . .  7
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires April 24, 2007                 [Page 2]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-1.  Introduction and Background
-
-   This document describe how a Kerberos V5 [2] implementation may
-   upgrade communication between clients and Key Distribution Centers
-   (KDCs) to use the Transport Layer Security (TLS) [4] protocol.
-
-   The TLS protocol offer integrity and privacy protected exchanges that
-   can be authentication using X.509 certificates, OpenPGP keys [7], and
-   user name and passwords via SRP [6].
-
-   There are several reasons to use Kerberos V5 over TLS.
-
-   o  Prevents downgrade attacks affecting, e.g., encryption types and
-      pre-auth data negotiation.  The encryption type field in KDC-REQ,
-      and the METHOD-DATA field with the requested pre-auth types from
-      the server in KDC_ERR_PREAUTH_REQUIRED errors in KDC-REP, are sent
-      without integrity or privacy protection in Kerberos 5.  This
-      allows an attacker to replace the encryption type with a
-      compromised encryption type, e.g., 56-bit DES, or request that
-      clients should use a broken pre-auth type.  Since clients in
-      general cannot know the encryption types other servers support, or
-      the pre-auth types servers prefer or require, it is difficult for
-      the client to detect if there was a man-in-the-middle or if the
-      remote server simply did not support a stronger encryption type or
-      preferred another pre-auth type.
-
-
-   o  Kerberos exchanges are privacy protected.  Part of many Kerberos
-      packets are transfered without privacy protection (i.e.,
-      encryption).  That part contains information, such as the client
-      principal name, the server principal name, the encryption types
-      supported by the client, the lifetime of tickets, etc.  Revealing
-      such information is, in some threat models, considered a problem.
-
-
-   o  Additional authentication against the KDC.  In some situations,
-      users are equipped with smart cards with a RSA authentication key.
-      In others, users have a OpenPGP client on their desktop, with a
-      public OpenPGP key known to the server.
-
-   o  The TLS protocol has been studied by many parties.  In some threat
-      models, the designer prefer to reduce the number of protocols that
-      can hurt the overall system security if they are compromised.
-
-
-   o  Explicit server authentication of the KDC to the client.  In
-      traditional Kerberos 5, authentication of the KDC is proved as a
-      side effect that the KDC knows your encryption key (i.e., your
-
-
-
-Josefsson                Expires April 24, 2007                 [Page 3]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-      password).
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [1].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires April 24, 2007                 [Page 4]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-2.  Kerberos V5 STARTTLS Extension
-
-   The STARTTLS extension uses the Kerberos V5 TCP extension mechanism
-   [3].  The extension uses bit #TBD in the extension bitmask.
-
-   The protocol is as follows.  After the server has sent the 4-octet
-   value 0x00000000 to indicate support of this extension, the stream
-   will be controlled by the TLS protocol and its framing.  The TLS
-   protocol is initiated by the client.
-
-   Typically, the client initiate the TLS handshake protocol by sending
-   a client hello, and the server responds, and the handshake continues
-   until it either succeed or fails.
-
-   If for any reason the handshake fails, the STARTTLS protocol will
-   also fail, and the TLS error is used as the error indication.
-
-   If the handshake succeeds, the Kerberos V5 authentication protocol is
-   performed within the protected TLS channel, like a normal TCP
-   Kerberos V5 exchange.  In particular, this means that every Kerberos
-   V5 packet will be prefixed by a 4-octet length field, that indicate
-   the length of the Kerberos V5 packet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires April 24, 2007                 [Page 5]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-3.  Examples
-
-   A complete packet flow for a successful AS-REQ/REP exchange protected
-   by this mechanism will be as follows.  The "STARTTLS-bit" is a
-   4-octet value with only the bit allocated for this extension set.
-
-       Client                                               Server
-
-        [ Kerberos V5 TCP extension mechanism negotiation starts ]
-
-       [0x70000000 & STARTTLS-bit]  -------->
-                                                       [0x00000000]
-                                    <--------
-
-                            [ TLS negotiation starts ]
-
-
-       ClientHello                  -------->
-                                                       ServerHello
-                                                      Certificate*
-                                                ServerKeyExchange*
-                                               CertificateRequest*
-                                    <--------      ServerHelloDone
-       Certificate*
-       ClientKeyExchange
-       CertificateVerify*
-       [ChangeCipherSpec]
-       Finished                     -------->
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-
-                       [ Kerberos V5 negotiation starts ]
-
-       4 octet length field
-       Kerberos V5 AS-REQ           -------->
-                                                4 octet length field
-                                                Kerberos V5 AS-REP
-                                    <--------
-
-       * Indicates optional or situation-dependent messages that are not
-         always sent.
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires April 24, 2007                 [Page 6]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-4.  STARTTLS aware KDC Discovery
-
-   Section 7.2.3 of Kerberos V5 [2] describe how Domain Name System
-   (DNS) SRV records [5] can be used to find the address of an KDC.
-   Using the terminology of Section 7.2.3 of RFC 4120, we define a new
-   Proto of "tls" to indicate that the particular KDC is intended to
-   support this STARTTLS extension.  The Service, Realm, TTL, Class,
-   SRV, Priority, Weight, Port and Target have the same meaning as in
-   RFC 4120.
-
-   For example:
-
-   _kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
-   _kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires April 24, 2007                 [Page 7]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-5.  IANA Considerations
-
-   The IANA is requested to allocate a bit in the "Kerberos TCP
-   Extensions" registry for the extension described in this document, as
-   per [3].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires April 24, 2007                 [Page 8]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-6.  Security Considerations
-
-   The security considerations in Kerberos V5, TLS, and the extension
-   mechanism framework are inherited.
-
-   To protect against the inherent downgrade attack in the extension
-   framework, it is suggested that implementations offer a policy to
-   require that this extension is successfully negotiated.  For
-   interoperability with implementations that do not support this
-   extension, it is suggested that the policy is disabled by default.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires April 24, 2007                 [Page 9]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-7.  References
-
-7.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
-        Network Authentication Service (V5)", RFC 4120, July 2005.
-
-   [3]  Josefsson, S., "Extended Kerberos Version 5 Key Distribution
-        Center (KDC) Exchanges Over TCP",
-        draft-ietf-krb-wg-tcp-expansion-01 (work in progress),
-        September 2006.
-
-   [4]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
-        Protocol Version 1.1", RFC 4346, April 2006.
-
-   [5]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
-        specifying the location of services (DNS SRV)", RFC 2782,
-        February 2000.
-
-7.2.  Informative References
-
-   [6]  Taylor, D., "Using SRP for TLS Authentication",
-        draft-ietf-tls-srp-12 (work in progress), June 2006.
-
-   [7]  Mavroyanopoulos, N., "Using OpenPGP keys for TLS
-        authentication", draft-ietf-tls-openpgp-keys-10 (work in
-        progress), June 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires April 24, 2007                [Page 10]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-Author's Address
-
-   Simon Josefsson
-   SJD
-
-   Email: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires April 24, 2007                [Page 11]
-
-Internet-Draft       Protecting Kerberos V5 with TLS        October 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Josefsson                Expires April 24, 2007                [Page 12]
-
diff --git a/doc/standardisation/draft-josefsson-kerberos5-starttls-07.txt b/doc/standardisation/draft-josefsson-kerberos5-starttls-07.txt
deleted file mode 100644
index e8b2d1788..000000000
--- a/doc/standardisation/draft-josefsson-kerberos5-starttls-07.txt
+++ /dev/null
@@ -1,784 +0,0 @@
-
-
-
-Network Working Group                                       S. Josefsson
-Internet-Draft                                                    SJD AB
-Intended status: Informational                             July 31, 2009
-Expires: February 1, 2010
-
-
-   Using Kerberos V5 over the Transport Layer Security (TLS) protocol
-                 draft-josefsson-kerberos5-starttls-07
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.  This document may contain material
-   from IETF Documents or IETF Contributions published or made publicly
-   available before November 10, 2008.  The person(s) controlling the
-   copyright in some of this material may not have granted the IETF
-   Trust the right to allow modifications of such material outside the
-   IETF Standards Process.  Without obtaining an adequate license from
-   the person(s) controlling the copyright in such materials, this
-   document may not be modified outside the IETF Standards Process, and
-   derivative works of it may not be created outside the IETF Standards
-   Process, except to format it for publication as an RFC or to
-   translate it into languages other than English.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on February 1, 2010.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-
-
-
-Josefsson               Expires February 1, 2010                [Page 1]
-
-Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
-
-
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires February 1, 2010                [Page 2]
-
-Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
-
-
-Abstract
-
-   This document specify how the Kerberos V5 protocol can be transported
-   over the Transport Layer Security (TLS) protocol, to provide
-   additional security features.
-
-
-Table of Contents
-
-   1.  Introduction and Background  . . . . . . . . . . . . . . . . .  4
-   2.  Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . .  6
-   3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
-   4.  STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . .  8
-   5.  Server Certificates  . . . . . . . . . . . . . . . . . . . . .  9
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
-     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires February 1, 2010                [Page 3]
-
-Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
-
-
-1.  Introduction and Background
-
-   This document describe how a Kerberos V5 [RFC4120] implementation may
-   upgrade communication between clients and Key Distribution Centers
-   (KDCs) to use the Transport Layer Security (TLS) [RFC5246] protocol.
-
-   The TLS protocol offer integrity and privacy protected exchanges that
-   can be authentication using X.509 certificates, OpenPGP keys
-   [RFC5081], and user name and passwords via SRP [RFC5054].
-
-   There are several reasons to use Kerberos V5 over TLS.
-
-   o  Prevents downgrade attacks affecting, e.g., encryption types and
-      pre-auth data negotiation.  The encryption type field in KDC-REQ,
-      and the METHOD-DATA field with the requested pre-auth types from
-      the server in KDC_ERR_PREAUTH_REQUIRED errors in KDC-REP, are sent
-      without integrity or privacy protection in Kerberos 5.  This
-      allows an active attacker to replace the encryption type with a
-      compromised encryption type, e.g., 56-bit DES, or request that
-      clients should use a broken pre-auth type.  Since clients in
-      general cannot know the encryption types other servers support, or
-      the pre-auth types servers prefer or require, it is difficult for
-      the client to detect if there was a man-in-the-middle or if the
-      remote server simply did not support a stronger encryption type or
-      preferred another pre-auth type.
-
-   o  Kerberos exchanges are privacy protected.  Part of many Kerberos
-      packets are transferred without privacy protection (i.e.,
-      encryption).  That part contains information, such as the client
-      principal name, the server principal name, the encryption types
-      supported by the client, the lifetime of tickets, etc.  Revealing
-      such information is, in some threat models, considered a problem.
-
-   o  Additional authentication against the KDC.  In some situations,
-      users are equipped with smart cards with a RSA authentication key.
-      In others, users have a OpenPGP client on their desktop, with a
-      public OpenPGP key known to the server.
-
-   o  The TLS protocol has been studied by many parties.  In some threat
-      models, the designer prefer to reduce the number of protocols that
-      can hurt the overall system security if they are compromised.
-
-   o  Explicit server authentication of the KDC to the client.  In
-      traditional Kerberos 5, authentication of the KDC is proved as a
-      side effect that the KDC knows your encryption key (i.e., your
-      password).
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-
-
-
-Josefsson               Expires February 1, 2010                [Page 4]
-
-Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
-
-
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires February 1, 2010                [Page 5]
-
-Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
-
-
-2.  Kerberos V5 STARTTLS Extension
-
-   The STARTTLS extension uses the Kerberos V5 TCP extension mechanism
-   [RFC5021].  The extension uses bit #TBD in the extension bitmask.
-
-   The protocol is as follows.  After the server has sent the 4-octet
-   value 0x00000000 to indicate support of this extension, the stream
-   will be controlled by the TLS protocol and its framing.  The TLS
-   protocol is initiated by the client.
-
-   Typically, the client initiate the TLS handshake protocol by sending
-   a client hello, and the server responds, and the handshake continues
-   until it either succeed or fails.
-
-   If for any reason the handshake fails, the STARTTLS protocol will
-   also fail, and the TLS error is used as the error indication.  In
-   this case, no further messages can be exchanged over the same TCP
-   session.
-
-   If the handshake succeeds, the Kerberos V5 authentication protocol is
-   performed within the protected TLS channel, like a normal TCP
-   Kerberos V5 exchange.  In particular, this means that every Kerberos
-   V5 packet will be prefixed by a 4-octet length field, that indicate
-   the length of the Kerberos V5 packet.
-
-   When no further Kerberos V5 messages needs to be transferred in the
-   TLS session, the TLS session MUST be shut down properly using the
-   close_notify alert.  When the TLS session is shut down, the TCP
-   connection cannot be re-used to send any further data and MUST be
-   closed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires February 1, 2010                [Page 6]
-
-Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
-
-
-3.  Examples
-
-   A complete packet flow for a successful AS-REQ/REP exchange protected
-   by this mechanism will be as follows.  The "STARTTLS-bit" is a
-   4-octet value with only the bit allocated for this extension set.
-
-       Client                                               Server
-
-        [ Kerberos V5 TCP extension mechanism negotiation starts ]
-
-       [0x70000000 & STARTTLS-bit]  -------->
-                                                       [0x00000000]
-                                    <--------
-
-                            [ TLS negotiation starts ]
-
-
-       ClientHello                  -------->
-                                                       ServerHello
-                                                      Certificate*
-                                                ServerKeyExchange*
-                                               CertificateRequest*
-                                    <--------      ServerHelloDone
-       Certificate*
-       ClientKeyExchange
-       CertificateVerify*
-       [ChangeCipherSpec]
-       Finished                     -------->
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-
-                       [ Kerberos V5 negotiation starts ]
-
-       4 octet length field
-       Kerberos V5 AS-REQ           -------->
-                                                4 octet length field
-                                                Kerberos V5 AS-REP
-                                    <--------
-
-       * Indicates optional or situation-dependent messages that are not
-         always sent.
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires February 1, 2010                [Page 7]
-
-Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
-
-
-4.  STARTTLS aware KDC Discovery
-
-   Section 7.2.3 of Kerberos V5 [RFC4120] describe how Domain Name
-   System (DNS) SRV records [RFC2782] can be used to find the address of
-   an KDC.  We define a new Proto of "tls" to indicate that the
-   particular KDC is intended to support this STARTTLS extension.  The
-   Service, Realm, TTL, Class, SRV, Priority, Weight, Port and Target
-   have the same meaning as in RFC 4120.
-
-   For example:
-
-   _kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
-   _kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires February 1, 2010                [Page 8]
-
-Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
-
-
-5.  Server Certificates
-
-   The TLS protocol may be used in a mode that provides server
-   authentication using, for example, X.509 and OpenPGP.
-
-   The Kerberos V5 STARTTLS protocol do not require clients to verify
-   the server certificate.  The goal is that support for TLS in Kerberos
-   V5 clients should be as easy to implement and deploy as support for
-   UDP/TCP.  Use of TLS, even without server certificate validation,
-   protects against some attacks that Kerberos V5 over UDP/TCP do not.
-   Requiring server certificates to be used at all times would enable
-   attacks in those situations.
-
-   Many client environments do not have secure long-term storage, which
-   is required to validate certificates.  This makes it impossible to
-   use server certificate validation on a large number of client
-   systems.
-
-   When clients have the ability, they need to be able to validate the
-   server certificate.  For this reason, if a KDC presents a X.509
-   server certificate over TLS, it MUST contain an otherName Subject
-   Alternative Name (SAN) identified using a type-id of id-krb5starttls-
-   san.  The intention is to bind the server certificate to the Kerberos
-   realm for the purpose of using Kerberos V5 STARTTLS.  The value field
-   of the otherName should contain the realm as the "Realm" ASN.1 type.
-
-          id-krb5starttls-san OBJECT IDENTIFIER ::=
-            { iso(1) identified-organization(3) dod(6) internet(1)
-              private(4) enterprise(1) gnu(11591)
-              shishi(6) krb5starttls-san(1) }
-
-   To validate a server certificate, the client MAY use local
-   configuration (e.g., a list that map realm names to a copy of the
-   server's certificate) and compare that with the authentication
-   information provided from the server via TLS.  For illustration, the
-   server certificate could be a X.509 certificate or an OpenPGP key.
-   In this mode, the client need no processing related to id-
-   krb5starttls-san.
-
-   When the server presents a X.509 server certificate, clients MAY use
-   "Certification Path Validation" as described in [RFC5280] to validate
-   the KDC server certificate.  In addition, unless the client can
-   otherwise verify that the server certificate is bound to the KDC of
-   the target realm, the client MUST verify that the server certificate
-   contains the id-krb5starttls-san SAN and that the value is identical
-   to the intended Kerberos realm.
-
-
-
-
-
-Josefsson               Expires February 1, 2010                [Page 9]
-
-Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
-
-
-6.  IANA Considerations
-
-   The IANA is requested to allocate a bit in the "Kerberos TCP
-   Extensions" registry for the extension described in this document, as
-   per [RFC5021].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires February 1, 2010               [Page 10]
-
-Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
-
-
-7.  Acknowledgements
-
-   Jeffrey Hutzelman and Sam Hartman provided comments that improved the
-   protocol and document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires February 1, 2010               [Page 11]
-
-Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
-
-
-8.  Security Considerations
-
-   The security considerations in Kerberos V5, TLS, and the Kerberos V5
-   TCP extension mechanism are inherited.
-
-   Note that TLS does not protect against Man-In-The-Middle (MITM)
-   attacks unless clients verify the KDC's credentials (X.509
-   certificate, OpenPGP key, etc) correctly.
-
-   If server authentication is used, some information about the server
-   (such as its name) is visible to passive attackers.
-
-   To protect against the inherent downgrade attack in the extension
-   framework, implementations SHOULD offer a policy mode that requires
-   this extension to always be successfully negotiated, for a particular
-   realm, or generally.  For interoperability with implementations that
-   do not support this extension, the policy mode SHOULD be disabled by
-   default.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires February 1, 2010               [Page 12]
-
-Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
-
-
-9.  References
-
-9.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
-              specifying the location of services (DNS SRV)", RFC 2782,
-              February 2000.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
-
-   [RFC5021]  Josefsson, S., "Extended Kerberos Version 5 Key
-              Distribution Center (KDC) Exchanges over TCP", RFC 5021,
-              August 2007.
-
-   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
-              Housley, R., and W. Polk, "Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 5280, May 2008.
-
-9.2.  Informative References
-
-   [RFC5054]  Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
-              "Using the Secure Remote Password (SRP) Protocol for TLS
-              Authentication", RFC 5054, November 2007.
-
-   [RFC5081]  Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
-              Layer Security (TLS) Authentication", RFC 5081,
-              November 2007.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires February 1, 2010               [Page 13]
-
-Internet-Draft       Protecting Kerberos V5 with TLS           July 2009
-
-
-Author's Address
-
-   Simon Josefsson
-   Simon Josefsson Datakonsult AB
-   Hagagatan 24
-   Stockholm  113 47
-   Sweden
-
-   Email: simon@josefsson.org
-   URI:   http://josefsson.org/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires February 1, 2010               [Page 14]
-
diff --git a/doc/standardisation/draft-josefsson-krb-tcp-expansion-02.txt b/doc/standardisation/draft-josefsson-krb-tcp-expansion-02.txt
deleted file mode 100644
index 3225b10d9..000000000
--- a/doc/standardisation/draft-josefsson-krb-tcp-expansion-02.txt
+++ /dev/null
@@ -1,392 +0,0 @@
-
-
-
-Network Working Group                                       S. Josefsson
-Internet-Draft                                                       SJD
-Updates: 4120 (if approved)                               April 23, 2006
-Expires: October 25, 2006
-
-
-Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over
-                                  TCP
-                  draft-josefsson-krb-tcp-expansion-02
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on October 25, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes an extensibility mechanism for the Kerberos
-   v5 protocol when used over TCP transports.
-
-
-
-
-
-
-
-
-Josefsson               Expires October 25, 2006                [Page 1]
-
-Internet-Draft          Kerberos V5 TCP extension             April 2006
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions used in this document . . . . . . . . . . . . . . . 3
-   3.  Extension Mechanism for TCP transport . . . . . . . . . . . . . 3
-   4.  Interoperability Consideration  . . . . . . . . . . . . . . . . 4
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
-   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
-   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
-   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
-   Appendix A.  Copying conditions . . . . . . . . . . . . . . . . . . 5
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires October 25, 2006                [Page 2]
-
-Internet-Draft          Kerberos V5 TCP extension             April 2006
-
-
-1.  Introduction
-
-   The Kerberos 5 [3] specification, in section 7.2.2, reserve the high
-   order bit in the initial length field for TCP transport for future
-   expansion.  This document update [3] to describe the behaviour when
-   that bit is set.  This mechanism is intended for extensions that are
-   specific for the TCP transport.
-
-
-2.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [1].
-
-
-3.  Extension Mechanism for TCP transport
-
-   The reserved high bit of the request length field is used to signal
-   the use of this extension mechanism.  When the reserved high bit is
-   set, the remaining 31 bits of the initial 4 octets are interpreted as
-   a bitmap.  Each bit in the bitmask can be used to request a
-   particular extension.  The 31 bits form the "extension bitmask".  It
-   is expected that other documents will describe the details associated
-   with particular bits.
-
-   A 4-octet value with only the high bit set, and thus the extension
-   bitmask all zeros, is called a PROBE.  A client may send a probe to
-   find out which extensions a KDC support.  A client may also set
-   particular bits in the extension bitmask directly, if it does not
-   need to query the KDC for available extensions before deciding which
-   extension to request.
-
-   If a KDC receive a PROBE, or if a KDC does not support all extensions
-   corresponding to set bits in the extension bitmask, the KDC MUST
-   return 4 octets with the high bit set, and with the remaining bitmask
-   indicate which extensions it supports.  The KDC MUST NOT close the
-   connection, and MUST wait for the client to then send a second
-   4-octet value, with the high bit set and the remaining bits as the
-   bitmask, to request a particular extension.  If the second 4-octet
-   value is a PROBE or an unsupported extension, the KDC MUST close the
-   connection.  This is used by the client to shutdown a session when
-   the KDC did not support a, by the client, required extension.
-
-   The behaviour when more than one non-high bit is set depends on the
-   particular extension mechanisms.  If a requested extension (bit X)
-   does not specify how it interact with another requested extensions
-   (bit Y), the KDC MUST treat the request as a PROBE or unsupported
-
-
-
-Josefsson               Expires October 25, 2006                [Page 3]
-
-Internet-Draft          Kerberos V5 TCP extension             April 2006
-
-
-   extension, and proceed as above.
-
-   Each extension MUST describe the structure of protocol data beyond
-   the length field, and the behaviour of the client and KDC.  If an
-   extension mechanism reserve multiple bits, it MUST describe how they
-   interact.
-
-
-4.  Interoperability Consideration
-
-   Implementations with support for TCP that do not claim to conform to
-   RFC 4120 may not handle the high bit correctly.  Behaviour may
-   include closing the TCP connection without any response, and logging
-   an error message in the KDC log.  When this was written, this problem
-   existed in modern versions of popular implementations.
-   Implementations experiencing trouble getting the expected responses
-   from a server SHOULD assume that it does not support this extension
-   mechanism.  Clients MAY remember this semi-permanently, to avoid
-   excessive logging in the server.  Care should be taken to avoid
-   unexpected behaviour for the user when the KDC is eventually
-   upgraded.  How to handle these backwards compatibility quirks are in
-   general left unspecified.
-
-
-5.  Security Considerations
-
-   Because the initial length field is not protected, it is possible for
-   an active attacker (i.e., one that is able to modify traffic between
-   the client and the KDC) to make it appear to the client that the
-   server does not support this extension mechanism.  Client and KDC
-   policies can be used to reject connections that does not use any
-   expansion.
-
-
-6.  IANA Considerations
-
-   IANA needs to create a new registry for "Kerberos 5 TCP Extensions".
-   The initial contents of this registry should be:
-
-   [[RFC Editor: Replace xxxx below with the number of this RFC.]]
-
-   Bit #         Meaning                             Reference
-   -----         -------                             ---------
-   0..29         AVAILABLE for registration.
-   30            RESERVED.                           RFC XXXX
-
-   IANA will register values 0 to 29 after IESG Approval, as defined in
-   BCP 64 [2].  Assigning value 30 requires a Standards Action.
-
-
-
-Josefsson               Expires October 25, 2006                [Page 4]
-
-Internet-Draft          Kerberos V5 TCP extension             April 2006
-
-
-7.  Acknowledgements
-
-   Thanks to Andrew Bartlett who pointed out that some implementations
-   (MIT Kerberos and Heimdal) did not follow RFC 4120 properly with
-   regards to the high bit, which resulted in an Interoperability
-   Consideration.
-
-   Nicolas Williams and Jeffrey Hutzelman provided comments that
-   improved the document.
-
-8.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [3]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
-        Network Authentication Service (V5)", RFC 4120, July 2005.
-
-
-Appendix A.  Copying conditions
-
-   Regarding this entire document or any portion of it, the author makes
-   no guarantees and is not responsible for any damage resulting from
-   its use.  The author grants irrevocable permission to anyone to use,
-   modify, and distribute it in any way that does not diminish the
-   rights of anyone else to use, modify, and distribute it, provided
-   that redistributed derivative works do not contain misleading author
-   or version information.  Derivative works need not be licensed under
-   similar terms.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires October 25, 2006                [Page 5]
-
-Internet-Draft          Kerberos V5 TCP extension             April 2006
-
-
-Author's Address
-
-   Simon Josefsson
-   SJD
-
-   Email: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson               Expires October 25, 2006                [Page 6]
-
-Internet-Draft          Kerberos V5 TCP extension             April 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Josefsson               Expires October 25, 2006                [Page 7]
-
diff --git a/doc/standardisation/draft-josefsson-sasl-kerberos5-01.txt b/doc/standardisation/draft-josefsson-sasl-kerberos5-01.txt
deleted file mode 100644
index 4f527d61f..000000000
--- a/doc/standardisation/draft-josefsson-sasl-kerberos5-01.txt
+++ /dev/null
@@ -1,1120 +0,0 @@
-
-
-Network Working Group                                       S. Josefsson
-Internet-Draft                                          February 2, 2003
-Expires: August 3, 2003
-
-
-                      A Kerberos 5 SASL Mechanism
-                   draft-josefsson-sasl-kerberos5-01
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at http://
-   www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on August 3, 2003.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document specifies a Simple Authentication and Security Layer
-   (SASL) [3] mechanism for Kerberos 5 Client/Server Authentication [1],
-   with optional initial Authentication Service (AS) and/or
-   Ticket-Granting-Service (TGS) exchanges.
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires August 3, 2003                 [Page 1]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Document Changes . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Kerberos Version 5 Mechanism . . . . . . . . . . . . . . . . .  3
-   4.  Theory Of Operation  . . . . . . . . . . . . . . . . . . . . .  6
-   4.1 Infrastructure Mode  . . . . . . . . . . . . . . . . . . . . .  6
-   4.2 Proxied Infrastructure Mode  . . . . . . . . . . . . . . . . .  6
-   4.3 Non-Infrastructure Mode  . . . . . . . . . . . . . . . . . . .  7
-   5.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
-       Normative References . . . . . . . . . . . . . . . . . . . . . 17
-       Informative References . . . . . . . . . . . . . . . . . . . . 17
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
-       Intellectual Property and Copyright Statements . . . . . . . . 19
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires August 3, 2003                 [Page 2]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-1. Introduction
-
-   Kerberos 5 provides client and optional server authentication,
-   usually employing symmetric encryption and a trusted (symmetric) key
-   distribution center.  Specifying Kerberos 5 authentication for each
-   network protocol where there is a need to use Kerberos 5 is a tedious
-   task.  However, as many protocols already specify support for the
-   SASL framework, by specifying a Kerberos 5 SASL mechanism, support
-   for Kerberos 5 in many protocols is accomplished.  Even for protocols
-   that do not support SASL, specifying SASL support (and thereby
-   implicitly Kerberos 5) is often advantageous over specifying Kerberos
-   5 support directly.  The advantages include better flexibility if or
-   when new Kerberos versions are released, and perhaps more commonly,
-   when circumstances demand that other authentication methods
-   (supported by SASL) should be used.
-
-   It should be mentioned that Kerberos 5 authentication via SASL is
-   already possible, by using the Generic Security Service Application
-   Program Interface [6] framework.  However, GSSAPI adds some amount of
-   overhead, both in terms of code complexity, code size and additional
-   network round trips.  More importantly, GSSAPI do not support the
-   authentication steps (AS and TGS).  These are some of the motivation
-   behind this "slimmer" Kerberos 5 SASL mechanism.
-
-2. Document Changes
-
-   Modification since -00:
-
-   * The way data is encoded in the
-     AP-REQ.Authenticator.authorization-data field is corrected and
-     elaborated.
-
-   * The incorrect sentence about including application data in the
-     AP-REP is removed.
-
-   * The "Theory of operation" section now includes three modes;
-     Infrastructure, Proxied Infrastructure, and Non-Infrastructure
-     modes.
-
-   * The example section now contains a complete dump from an
-     implementation.
-
-
-3. Kerberos Version 5 Mechanism
-
-   The mechanism name associated with Kerberos version 5 is
-   "KERBEROS_V5".  The exchange consists of one initial server packet
-   (containing some parameters and a challenge, described below), and
-
-
-
-Josefsson                Expires August 3, 2003                 [Page 3]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-   then an unfixed number of messages containing Kerberos 5 packets,
-   with the last exchange being an AP-REQ, and optional AP-REP, for the
-   desired SASL service on a format described below.
-
-   The normal packet exchange, after the required initial server packet,
-   are one optional AS-REQ and AS-REP exchange, one optional TGS-REQ and
-   TGS-REP exchange and then the AP-REQ packet and optional AP-REP
-   reply.  The only steps that are required by this SASL mechanism is
-   the initial server packet and the final AP-REQ and optional AP-REP
-   exchange.  The AP-REP is sent when and only when mutual
-   authentication is required.  The AP-REQ is for the SASL service that
-   is requested.  The AP-REQ must contain authenticated application data
-   on a format described below.  The AS and TGS exchanges is usually
-   used by clients to acquire the proper tickets required for the AP
-   phase.  It is not expected that any other Kerberos 5 packets will be
-   exchanged, but this mechanism do not disallow such packets in order
-   to make it possible to use this SASL mechanism with future Kerberos
-   extensions.
-
-   As discussed above, the client is allowed to send any valid Kerberos
-   5 message and the server should handle any message, subject to local
-   policy restrictions.  If the server do not understand the meaning of
-   a packet or do not wish to respond to it (e.g., it cannot proxy a
-   TGS-REQ), it SHOULD respond with a empty response and await further
-   packets.  Reasons for aborting the authentication phase instead of
-   sending an empty response includes if the number of received packets
-   exceeds a pre-defined limit.  AS-REQ and TGS-REQ packets destined for
-   non-local Kerberos Key Distribution Centers (KDCs) is proxied to the
-   correct server by the SASL server.  No provisions are made in the
-   protocol to allow the client to specify the addresses of the KDCs,
-   instead the SASL server is required to discover this information
-   (usually by static configuration or by using DNS).  It is legitimate
-   for the SASL server to abort the authentication phase with an error
-   saying that the indicated realm was not found or is restricted by
-   policy (i.e., a policy that only permits local KDC requests is
-   permitted).
-
-   Since it is expected that clients may not yet have IP addresses when
-   they invoke this SASL mechanism (invoking this mechanism may be one
-   step in acquiring an IP address), clients commonly leave the address
-   fields in the AS-REQ empty.
-
-   The initial server packet should contain one octet containing a bit
-   mask of supported security layers, four octets indicating the maximum
-   cipher-text buffer size the server is able to receive (or 0 if no
-   security layers are supported) in network byte order, and then 16
-   octets containing random data (see [4] on how random data might be
-   generated).
-
-
-
-Josefsson                Expires August 3, 2003                 [Page 4]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-   The last exchange must be an AP-REQ for the desired SASL service,
-   optionally followed by an AP-REP.  The SASL service is translated
-   into a Kerberos principal and realm as follows: The first element of
-   the principal is the service name specified in the protocol that uses
-   SASL.  The second element is the address of the SASL server, usually
-   expressed as a hostname.  The SASL realm should be the Kerberos realm
-   of the server.  The checksum value in the "cksum" field in the
-   Authenticator in the AP-REQ is computed on a string where the first
-   octet indicate the desired security layer requested by the client (a
-   bitmask with one bit set, which must also be set in the security
-   layer bitmask offered by the server), the next four octets indicate
-   the maximum cipher-text buffer size the client is able to receive in
-   network byte order (or 0 if a security layer is not indicated by the
-   first octet), followed by the entire initial server packet, in turn
-   followed by the desired authorization identity (which can be empty to
-   indicate that the authorization identity should be the same as the
-   authentication identity in the Kerberos ticket stored in the AP-REQ).
-   This same string is also to be included in the authorization-data
-   field of the Authenticator, with an ad-type of -1.
-
-   Upon decrypting and verifying the ticket and authenticator (i.e.,
-   standard AP-REQ processing), the server extracts the
-   authorization-data value from the Authenticator and checks that the
-   checksum in the authenticator is correct.  It then proceeds to check
-   that the server security layer bit mask, server maximum cipher-text
-   buffer size, and the random data equals the data provided in the
-   initial server challenge.  The server verify that the client selected
-   a security layer that was offered, and that the client maximum buffer
-   is 0 if no security layer was chosen.  The server must also verify
-   that the principal identified in the Kerberos ticket is authorized to
-   connect to the service as the authorization identity specified by the
-   client (or, if absent, the username denoted by the ticket principal).
-   Unless the client requested mutual authentication, the authentication
-   process is complete.
-
-   If the client requested mutual authentication, the server constructs
-   an AP-REP according to Kerberos 5.
-
-   The security layers and their corresponding bit-masks are as follows:
-
-         Bit 0 No security layer
-         Bit 1 Integrity (KRB-SAFE) protection
-         Bit 2 Privacy (KRB-PRIV) protection
-         Bit 3 Mutual authentication is required (AP option MUTUAL-
-               REQUIRED must also be present).
-
-   Other bit-masks may be defined in the future; bits which are not
-   understood must be negotiated off.
-
-
-
-Josefsson                Expires August 3, 2003                 [Page 5]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-4. Theory Of Operation
-
-   This section describes, for illustration only, three common scenarios
-   where this mechanism can be used.
-
-4.1 Infrastructure Mode
-
-   Normally a SASL server is an application server such as a mail
-   system.  The server is configured to belong to at least one Kerberos
-   5 realm, and the server shares a symmetric key with the Kerberos 5
-   Key Distribution Center in that realm.  The server cannot perform the
-   initial Kerberos AS and TGS operation itself, but a KDC is needed for
-   that operation.  Once the user acquired credentials the server is
-   able to carry out the AP-REQ/AP-REP phase using its symmetric key.
-   The steps are as follows:
-
-   0) Server sends initial token.
-
-   * Client acquires a ticket for the server using an out-of-band request
-     to the KDC. Client generates the AP-REQ using the ticket for the
-     server.
-
-   1) Client sends AP-REQ to the server.
-
-   * Server parses AP-REQ, and if required the AP-REP is generated.
-
-   2) [Optional] Server sends AP-REP to the client.
-
-   * [Optional] Client parses AP-REP.
-
-   As can be seen, round-trip wise this is optimal, possibly bar the
-   initial token, although in IMAP it does not cause an additional
-   round-trip, and other protocols may be similar.
-
-4.2 Proxied Infrastructure Mode
-
-   If the client for some reason cannot carry out the communication with
-   the KDC itself, or for some other reason the server is in a better
-   position than the client to communicate with the KDC, the server can
-   proxy that part of the exchange via the server using the SASL
-   framework.  The server effectively acts as a proxy.  Note that the
-   packets that are sent are identical to those in the first example,
-   they are only routed differently.  The steps are as follows:
-
-
-
-
-
-
-
-
-Josefsson                Expires August 3, 2003                 [Page 6]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-   0) Server sends initial token.
-
-   * Client constructs AS-REQ using username and realm supplied by user,
-     in order to acquire a ticket granting ticket.
-
-   1) Client sends AS-REQ to server.
-
-   * Server finds address of KDC and forwards the AS-REQ to and waits for
-     the AS-REP response from the KDC.
-
-   2) Server sends AS-REP to client.
-
-   * Client parses AS-REP and constructs a TGS-REQ using the ticket
-     granting ticket encryption key, in order to acquire a ticket for the
-     server.
-
-   3) Client sends TGS-REQ to server.
-
-   * Server finds address of KDC and forwards the TGS-REQ to and waits
-     for the TGS-REP response from the KDC.
-
-   4) Server sends TGS-REP to client.
-
-   * Client parses TGS-REP and generates the AP-REQ using the session
-     encryption key.
-
-   5) Client sends AP-REQ to server.
-
-   * Server parses AP-REQ and if required the AP-REP is generated.
-
-   6) [Optional] Server sends AP-REP.
-
-   * [Optional] Client parses AP-REP.
-
-   If efficiency as a concern, and the client have no other use of a
-   ticket granting ticket for the realm, step 3 and 4 can be skipped by
-   asking for a ticket for the server directly in the AS-REQ.
-
-   Note that the client in subsequent connections may try to re-use the
-   ticket negotiated if it is still valid.
-
-4.3 Non-Infrastructure Mode
-
-   Kerberos 5 is usually a distributed security system, but we wish to
-   point out that this Kerberos 5 SASL mechanism may be used in a
-   standalone SASL server to provide the security advantages that the
-   Kerberos 5 Authentication Service (AS) provides over other methods.
-
-
-
-
-Josefsson                Expires August 3, 2003                 [Page 7]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-   Specifically, the SASL server may use a legacy password database such
-   as a CRAM-MD5 clear text password file to generate Kerberos 5
-   principals "on the fly".  Authentication may thus proceed as follows:
-
-   0) Server sends initial token.
-
-   * Client constructs AS-REQ using username supplied by user, in order
-     to acquire a ticket for the server directly.  The realm can be
-     predetermined by administrators, or simply the hostname of the
-     server.
-
-   1) Client sends AS-REQ to server.
-
-   * Server parses AS-REQ and generates AS-REP based on password in
-     database. The AS-REQ embeds a ticket for the server.
-
-   2) Server sends AS-REP to client.
-
-   * Client parses AS-REP and extracts the ticket and generates an AP-REQ
-     using the session encryption key.
-
-   3) Client sends AP-REQ to server.
-
-   * Server parses AP-REQ and if required, generates the AP-REP.
-
-   4) [Optional] Server sends AP-REP to client.
-
-   * [Optional] Client parses AP-REP.
-
-   This may be extended further, i.e.  by using the password and
-   Kerberos 5 pre-authentication in step 1.
-
-   Note that the client in subsequent connections may try to re-use the
-   ticket negotiated if it is still valid.
-
-5. Example
-
-   The following is one Kerberos version 5 login scenario for the IMAP4
-   protocol, in the non-infrastructure mode.  Note that the line breaks
-   are for editorial clarity.
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires August 3, 2003                 [Page 8]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-        S: * OK IMAP4rev1 server
-        C: . AUTHENTICATE KERBEROS_V5
-        S: + CQAAAADp6+ONC2vcprRbmH2J95Gh
-        C: an4wfKEDAgEFogMCAQqkcDBuoAcDBQAAAAAAoRAwDqADAgEAoQcwBRsDamFzog
-           sbCWxvY2FsaG9zdKMcMBqgAwIBAKETMBEbBGltYXAbCWxvY2FsaG9zdKURGA8y
-           MDAzMDIwMjE2NDE0M1qnBgIEVAbYn6gLMAkCARECARACAQM=
-        S: + a4IBzDCCAcigAwIBBaEDAgELowsbCWxvY2FsaG9zdKQQMA6gAwIBAKEHMAUb
-           A2phc6WB5GGB4TCB3qADAgEFoQsbCWxvY2FsaG9zdKIcMBqgAwIBAaETMBEbBG
-           ltYXAbCWxvY2FsaG9zdKOBqzCBqKADAgESooGgBIGdeBv2/NG1EgTMMMcHaVY3
-           f2w6y+bA56cVP8Toh+A3XFvTw8JFqAJVFGDm3MBrrSFOYcN8/8WY8T1cm0jq68
-           TcsiMh8y9KbWyeLJZedCVLLIfP1JgsSbBkZ7NLBFYCEEKvoGz2lMAuyJSh4+zT
-           L/NbcoIJq2ynCS965JKWWXl4rcBZPKBn5YUoU71dRK4/+HFrBoHejr6UHwVKd/
-           y0TaaBtTCBsqADAgERooGqBIGnYP7dngXFL2/hUWEs5PxGwlmvpWzGHWyh2QJ7
-           52eFj1tUpU3qT1NGgfVq2BVVWGDSVTO1vgDrkKCSDQwzkrqfwoZh4t6tt5tAPn
-           MCx2VDGyOu4Uv4PUsw4+uEevqkQRczpCsZT+y7pX7CxWHtytT3vLXNA6sANGnu
-           O7v7gTO+MGxzNvhVgMlujT2dkVgvCviVgJNuVef1VLVJWYM/zc4tuPaPaWToZJ
-           c=
-        C: boIBvjCCAbqgAwIBBaEDAgEOogcDBQAEAAAAo4HkYYHhMIHeoAMCAQWhCxsJbG
-           9jYWxob3N0ohwwGqADAgEBoRMwERsEaW1hcBsJbG9jYWxob3N0o4GrMIGooAMC
-           ARKigaAEgZ14G/b80bUSBMwwxwdpVjd/bDrL5sDnpxU/xOiH4DdcW9PDwkWoAl
-           UUYObcwGutIU5hw3z/xZjxPVybSOrrxNyyIyHzL0ptbJ4sll50JUssh8/UmCxJ
-           sGRns0sEVgIQQq+gbPaUwC7IlKHj7NMv81tyggmrbKcJL3rkkpZZeXitwFk8oG
-           flhShTvV1Erj/4cWsGgd6OvpQfBUp3/LRNpIG9MIG6oAMCARGhAwIBAaKBrQSB
-           qjE+doGGFMaz8g+nKl45qG5BPxzql0jXI5YMS+JqDeNBJIKasB0v9wMzXP9t8L
-           62PLsanqpow5bxAUtl/Dc8hqvc0cB+cC1P8RTgb0upMqzxTristf7goWRhQgTJ
-           OOwKJp/ZftZOkSdTHBQZL8StYuYe/6RkKkgnkUMK10VSec/YamG+5s37GvoRPG
-           Hu126PTyjXs3EziFqf6HT9Da/NJnDClFL8+nnlVFVt
-        S: + b2IwYKADAgEFoQMCAQ+iVDBSoAMCARGhAwIBAKJGBESTDM1z2PF5cUYOBmOW
-           IouXfHWtQzYzj1JFsJMV/CHMTmBrJavImHjR24f9WyCNOvmJMAWeHHOV9Jtpj6
-           rFt/ytas4U0g==
-        C:
-        S: . OK AUTHENTICATE KERBEROS_V5 authentication successful
-
-   The service requested is "imap/localhost" in the realm "localhost".
-   The password used was "foo", yielding an aes256-cts-hmac-sha1-96
-   encryption key of
-   0x6aefbaf05423cbc0fb44a41cc221783d7f52b764cca41fe2a05ad6d3bc7a67ea.
-
-   The first packet specify that mutual authentication and no integrity
-   or privacy layer (hence a zero maximum buffer size) and some random
-   data.
-
-   The second packet contains the AS-REQ, expanded as follows:
-
-
-
-
-
-
-
-
-Josefsson                Expires August 3, 2003                 [Page 9]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-   name:KDC-REQ  type:SEQUENCE
-     name:pvno  type:INTEGER  value:0x05
-     name:msg-type  type:INTEGER  value:0x0a
-     name:req-body  type:SEQUENCE
-       name:kdc-options  type:BIT_STR  value(32):00000000
-       name:cname  type:SEQUENCE
-         name:name-type  type:INTEGER  value:0x00
-         name:name-string  type:SEQ_OF
-           name:NULL  type:GENERALSTRING
-           name:?1  type:GENERALSTRING  value:6a6173
-       name:realm  type:GENERALSTRING  value:6c6f63616c686f7374
-       name:sname  type:SEQUENCE
-         name:name-type  type:INTEGER  value:0x00
-         name:name-string  type:SEQ_OF
-           name:NULL  type:GENERALSTRING
-           name:?1  type:GENERALSTRING  value:696d6170
-           name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
-       name:till  type:TIME  value:20030202164143Z
-       name:nonce  type:INTEGER  value:0x5406d89f
-       name:etype  type:SEQ_OF
-         name:NULL  type:INTEGER
-         name:?1  type:INTEGER  value:0x11
-         name:?2  type:INTEGER  value:0x10
-         name:?3  type:INTEGER  value:0x03
-   -----BEGIN SHISHI KDC-REQ-----
-   an4wfKEDAgEFogMCAQqkcDBuoAcDBQAAAAAAoRAwDqADAgEAoQcwBRsDamFzogsb
-   CWxvY2FsaG9zdKMcMBqgAwIBAKETMBEbBGltYXAbCWxvY2FsaG9zdKURGA8yMDAz
-   MDIwMjE2NDE0M1qnBgIEVAbYn6gLMAkCARECARACAQM=
-   -----END SHISHI KDC-REQ-----
-
-   The third packet contains the AS-REP, expanded as follows:
-
-   name:KDC-REP  type:SEQUENCE
-     name:pvno  type:INTEGER  value:0x05
-     name:msg-type  type:INTEGER  value:0x0b
-     name:crealm  type:GENERALSTRING  value:6c6f63616c686f7374
-     name:cname  type:SEQUENCE
-       name:name-type  type:INTEGER  value:0x00
-       name:name-string  type:SEQ_OF
-         name:NULL  type:GENERALSTRING
-         name:?1  type:GENERALSTRING  value:6a6173
-     name:ticket  type:SEQUENCE
-       name:tkt-vno  type:INTEGER  value:0x05
-       name:realm  type:GENERALSTRING  value:6c6f63616c686f7374
-       name:sname  type:SEQUENCE
-         name:name-type  type:INTEGER  value:0x01
-         name:name-string  type:SEQ_OF
-           name:NULL  type:GENERALSTRING
-
-
-
-Josefsson                Expires August 3, 2003                [Page 10]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-           name:?1  type:GENERALSTRING  value:696d6170
-           name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
-       name:enc-part  type:SEQUENCE
-         name:etype  type:INTEGER  value:0x12
-         name:cipher  type:OCT_STR  value:781bf6fcd1b51204cc30c7076956377
-         f6c3acbe6c0e7a7153fc4e887e0375c5bd3c3c245a802551460e6dcc06bad214
-         e61c37cffc598f13d5c9b48eaebc4dcb22321f32f4a6d6c9e2c965e74254b2c8
-         7cfd4982c49b06467b34b0456021042afa06cf694c02ec894a1e3ecd32ff35b7
-         28209ab6ca7092f7ae49296597978adc0593ca067e5852853bd5d44ae3ff8716
-         b0681de8ebe941f054a77fcb44d
-     name:enc-part  type:SEQUENCE
-       name:etype  type:INTEGER  value:0x11
-       name:cipher  type:OCT_STR  value:60fedd9e05c52f6fe151612ce4fc46c25
-       9afa56cc61d6ca1d9027be767858f5b54a54dea4f534681f56ad815555860d2553
-       3b5be00eb90a0920d0c3392ba9fc28661e2deadb79b403e7302c765431b23aee14
-       bf83d4b30e3eb847afaa4411733a42b194fecbba57ec2c561edcad4f7bcb5cd03a
-       b003469ee3bbbfb8133be306c7336f85580c96e8d3d9d91582f0af89580936e55e
-       7f554b54959833fcdce2db8f68f6964e86497
-   -----BEGIN SHISHI KDC-REP-----
-   a4IBzDCCAcigAwIBBaEDAgELowsbCWxvY2FsaG9zdKQQMA6gAwIBAKEHMAUbA2ph
-   c6WB5GGB4TCB3qADAgEFoQsbCWxvY2FsaG9zdKIcMBqgAwIBAaETMBEbBGltYXAb
-   CWxvY2FsaG9zdKOBqzCBqKADAgESooGgBIGdeBv2/NG1EgTMMMcHaVY3f2w6y+bA
-   56cVP8Toh+A3XFvTw8JFqAJVFGDm3MBrrSFOYcN8/8WY8T1cm0jq68TcsiMh8y9K
-   bWyeLJZedCVLLIfP1JgsSbBkZ7NLBFYCEEKvoGz2lMAuyJSh4+zTL/NbcoIJq2yn
-   CS965JKWWXl4rcBZPKBn5YUoU71dRK4/+HFrBoHejr6UHwVKd/y0TaaBtTCBsqAD
-   AgERooGqBIGnYP7dngXFL2/hUWEs5PxGwlmvpWzGHWyh2QJ752eFj1tUpU3qT1NG
-   gfVq2BVVWGDSVTO1vgDrkKCSDQwzkrqfwoZh4t6tt5tAPnMCx2VDGyOu4Uv4PUsw
-   4+uEevqkQRczpCsZT+y7pX7CxWHtytT3vLXNA6sANGnuO7v7gTO+MGxzNvhVgMlu
-   jT2dkVgvCviVgJNuVef1VLVJWYM/zc4tuPaPaWToZJc=
-   -----END SHISHI KDC-REP-----
-
-   After extracting the AS-REP, the EncASRepPart and Ticket are as
-   follows:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires August 3, 2003                [Page 11]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-   name:EncKDCRepPart  type:SEQUENCE
-     name:key  type:SEQUENCE
-       name:keytype  type:INTEGER  value:0x11
-       name:keyvalue  type:OCT_STR  value:517fe065071c845c425b5b18c4236618
-     name:last-req  type:SEQ_OF
-       name:NULL  type:SEQUENCE
-         name:lr-type  type:INTEGER
-         name:lr-value  type:TIME
-     name:nonce  type:INTEGER  value:0x5406d89f
-     name:flags  type:BIT_STR  value(3):20
-     name:authtime  type:TIME  value:20030202162503Z
-     name:endtime  type:TIME  value:20030202164143Z
-     name:srealm  type:GENERALSTRING  value:6c6f63616c686f7374
-     name:sname  type:SEQUENCE
-       name:name-type  type:INTEGER  value:0x01
-       name:name-string  type:SEQ_OF
-         name:NULL  type:GENERALSTRING
-         name:?1  type:GENERALSTRING  value:696d6170
-         name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
-   -----BEGIN SHISHI EncKDCRepPart-----
-   MIGAoBswGaADAgERoRIEEFF/4GUHHIRcQltbGMQjZhihAjAAogYCBFQG2J+kBAMC
-   BSClERgPMjAwMzAyMDIxNjI1MDNapxEYDzIwMDMwMjAyMTY0MTQzWqkLGwlsb2Nh
-   bGhvc3SqHDAaoAMCAQGhEzARGwRpbWFwGwlsb2NhbGhvc3Q=
-   -----END SHISHI EncKDCRepPart-----
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires August 3, 2003                [Page 12]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-   name:Ticket  type:SEQUENCE
-     name:tkt-vno  type:INTEGER  value:0x05
-     name:realm  type:GENERALSTRING  value:6c6f63616c686f7374
-     name:sname  type:SEQUENCE
-       name:name-type  type:INTEGER  value:0x01
-       name:name-string  type:SEQ_OF
-         name:NULL  type:GENERALSTRING
-         name:?1  type:GENERALSTRING  value:696d6170
-         name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
-     name:enc-part  type:SEQUENCE
-       name:etype  type:INTEGER  value:0x12
-       name:cipher  type:OCT_STR  value:781bf6fcd1b51204cc30c7076956377f6
-       c3acbe6c0e7a7153fc4e887e0375c5bd3c3c245a802551460e6dcc06bad214e61c
-       37cffc598f13d5c9b48eaebc4dcb22321f32f4a6d6c9e2c965e74254b2c87cfd49
-       82c49b06467b34b0456021042afa06cf694c02ec894a1e3ecd32ff35b728209ab6
-       ca7092f7ae49296597978adc0593ca067e5852853bd5d44ae3ff8716b0681de8eb
-       e941f054a77fcb44d
-   -----BEGIN SHISHI Ticket-----
-   YYHhMIHeoAMCAQWhCxsJbG9jYWxob3N0ohwwGqADAgEBoRMwERsEaW1hcBsJbG9j
-   YWxob3N0o4GrMIGooAMCARKigaAEgZ14G/b80bUSBMwwxwdpVjd/bDrL5sDnpxU/
-   xOiH4DdcW9PDwkWoAlUUYObcwGutIU5hw3z/xZjxPVybSOrrxNyyIyHzL0ptbJ4s
-   ll50JUssh8/UmCxJsGRns0sEVgIQQq+gbPaUwC7IlKHj7NMv81tyggmrbKcJL3rk
-   kpZZeXitwFk8oGflhShTvV1Erj/4cWsGgd6OvpQfBUp3/LRN
-   -----END SHISHI Ticket-----
-
-   The third packet contains the AP-REQ, expanded as follows:
-
-   name:AP-REQ  type:SEQUENCE
-     name:pvno  type:INTEGER  value:0x05
-     name:msg-type  type:INTEGER  value:0x0e
-     name:ap-options  type:BIT_STR  value(32):04000000
-     name:ticket  type:SEQUENCE
-       name:tkt-vno  type:INTEGER  value:0x05
-       name:realm  type:GENERALSTRING  value:6c6f63616c686f7374
-       name:sname  type:SEQUENCE
-         name:name-type  type:INTEGER  value:0x01
-         name:name-string  type:SEQ_OF
-           name:NULL  type:GENERALSTRING
-           name:?1  type:GENERALSTRING  value:696d6170
-           name:?2  type:GENERALSTRING  value:6c6f63616c686f7374
-       name:enc-part  type:SEQUENCE
-         name:etype  type:INTEGER  value:0x12
-         name:cipher  type:OCT_STR  value:781bf6fcd1b51204cc30c7076956377
-         f6c3acbe6c0e7a7153fc4e887e0375c5bd3c3c245a802551460e6dcc06bad214
-         e61c37cffc598f13d5c9b48eaebc4dcb22321f32f4a6d6c9e2c965e74254b2c8
-         7cfd4982c49b06467b34b0456021042afa06cf694c02ec894a1e3ecd32ff35b7
-         28209ab6ca7092f7ae49296597978adc0593ca067e5852853bd5d44ae3ff8716
-         b0681de8ebe941f054a77fcb44d
-
-
-
-Josefsson                Expires August 3, 2003                [Page 13]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-     name:authenticator  type:SEQUENCE
-       name:etype  type:INTEGER  value:0x11
-       name:kvno  type:INTEGER  value:0x01
-       name:cipher  type:OCT_STR  value:313e76818614c6b3f20fa72a5e39a86e4
-       13f1cea9748d723960c4be26a0de34124829ab01d2ff703335cff6df0beb63cbb1
-       a9eaa68c396f1014b65fc373c86abdcd1c07e702d4ff114e06f4ba932acf14eb8a
-       cb5fee0a164614204c938ec0a269fd97ed64e9127531c14192fc4ad62e61effa46
-       42a482791430ad7455279cfd86a61bee6cdfb1afa113c61eed76e8f4f28d7b3713
-       3885a9fe874fd0dafcd2670c29452fcfa79e554556d
-   -----BEGIN SHISHI AP-REQ-----
-   boIBvjCCAbqgAwIBBaEDAgEOogcDBQAEAAAAo4HkYYHhMIHeoAMCAQWhCxsJbG9j
-   YWxob3N0ohwwGqADAgEBoRMwERsEaW1hcBsJbG9jYWxob3N0o4GrMIGooAMCARKi
-   gaAEgZ14G/b80bUSBMwwxwdpVjd/bDrL5sDnpxU/xOiH4DdcW9PDwkWoAlUUYObc
-   wGutIU5hw3z/xZjxPVybSOrrxNyyIyHzL0ptbJ4sll50JUssh8/UmCxJsGRns0sE
-   VgIQQq+gbPaUwC7IlKHj7NMv81tyggmrbKcJL3rkkpZZeXitwFk8oGflhShTvV1E
-   rj/4cWsGgd6OvpQfBUp3/LRNpIG9MIG6oAMCARGhAwIBAaKBrQSBqjE+doGGFMaz
-   8g+nKl45qG5BPxzql0jXI5YMS+JqDeNBJIKasB0v9wMzXP9t8L62PLsanqpow5bx
-   AUtl/Dc8hqvc0cB+cC1P8RTgb0upMqzxTristf7goWRhQgTJOOwKJp/ZftZOkSdT
-   HBQZL8StYuYe/6RkKkgnkUMK10VSec/YamG+5s37GvoRPGHu126PTyjXs3EziFqf
-   6HT9Da/NJnDClFL8+nnlVFVt
-   -----END SHISHI AP-REQ-----
-
-   After extracting the AP-REP, the Authenticator is as follows:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires August 3, 2003                [Page 14]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-   name:Authenticator  type:SEQUENCE
-     name:authenticator-vno  type:INTEGER  value:0x05
-     name:crealm  type:GENERALSTRING  value:6c6f63616c686f7374
-     name:cname  type:SEQUENCE
-       name:name-type  type:INTEGER  value:0x01
-       name:name-string  type:SEQ_OF
-         name:NULL  type:GENERALSTRING
-         name:?1  type:GENERALSTRING  value:6a6173
-     name:cksum  type:SEQUENCE
-       name:cksumtype  type:INTEGER  value:0x0a
-       name:checksum  type:OCT_STR  value:15843a44f4f5f71746cc32e8
-     name:cusec  type:INTEGER  value:0x07480d
-     name:ctime  type:TIME  value:20030202162507Z
-     name:authorization-data  type:SEQ_OF
-       name:NULL  type:SEQUENCE
-         name:ad-type  type:INTEGER
-         name:ad-data  type:OCT_STR
-       name:?1  type:SEQUENCE
-         name:ad-type  type:INTEGER  value:0xff
-         name:ad-data  type:OCT_STR  value:09000000000900000000e9ebe38d0b
-         6bdca6b45b987d89f791a1
-   -----BEGIN SHISHI Authenticator-----
-   YoGDMIGAoAMCAQWhCxsJbG9jYWxob3N0ohAwDqADAgEBoQcwBRsDamFzoxcwFaAD
-   AgEKoQ4EDBWEOkT09fcXRswy6KQFAgMHSA2lERgPMjAwMzAyMDIxNjI1MDdaqCcw
-   JTAjoAMCAf+hHAQaCQAAAAAJAAAAAOnr440La9ymtFuYfYn3kaE=
-   -----END SHISHI Authenticator-----
-
-   The fourth packet contains the AP-REP, expanded as follows:
-
-   name:AP-REP  type:SEQUENCE
-     name:pvno  type:INTEGER  value:0x05
-     name:msg-type  type:INTEGER  value:0x0f
-     name:enc-part  type:SEQUENCE
-       name:etype  type:INTEGER  value:0x11
-       name:kvno  type:INTEGER  value:0x00
-       name:cipher  type:OCT_STR  value:930ccd73d8f17971460e066396228b977
-       c75ad4336338f5245b09315fc21cc4e606b25abc89878d1db87fd5b208d3af9893
-       0059e1c7395f49b698faac5b7fcad6ace14d2
-   -----BEGIN SHISHI AP-REP-----
-   b2IwYKADAgEFoQMCAQ+iVDBSoAMCARGhAwIBAKJGBESTDM1z2PF5cUYOBmOWIouX
-   fHWtQzYzj1JFsJMV/CHMTmBrJavImHjR24f9WyCNOvmJMAWeHHOV9Jtpj6rFt/yt
-   as4U0g==
-   -----END SHISHI AP-REP-----
-
-   After extracting the AP-REP, the EncAPRepPart is as follows:
-
-
-
-
-
-
-Josefsson                Expires August 3, 2003                [Page 15]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-   name:EncAPRepPart  type:SEQUENCE
-     name:ctime  type:TIME  value:20030202162507Z
-     name:cusec  type:INTEGER  value:0x07480d
-   -----BEGIN SHISHI EncAPRepPart-----
-   exwwGqARGA8yMDAzMDIwMjE2MjUwN1qhBQIDB0gN
-   -----END SHISHI EncAPRepPart-----
-
-
-6. Security Considerations
-
-   The authentication phase is believed to be no less secure than the
-   Client/Server Authentication exchange described in the Kerberos 5
-   protocol.
-
-   If no security layer is negotiated, the connection is subject to
-   active man-in-the-middle attackers that hijack the connection after
-   authentication has been completed.
-
-   When security layers are used, it is believed that the communication
-   channel negotiated by this specification is no less secure than the
-   KRB_SAFE and KRB_PRIV primitives.  In other words, it is believed
-   that if an attack that breaches integrity or privacy of this
-   mechanism, the same attack also applies to the Kerberos 5
-   specification, and vice versa.
-
-   Server implementations should be aware that the proxy function can be
-   abused, and MAY implement precaution against this if it is considered
-   a threat.  Useful precautions include limiting the size and number of
-   packets forwarded, and to abort the SASL exchange when the limit is
-   reached.
-
-   Server implementations should make sure the method to look up KDC for
-   the client indicated realm does not cause security problems.  In
-   particular, trusting unprotected DNS lookups to find the KDC of a
-   realm may be considered as dangerous by a server.
-
-   The forward-compatibility behavior of returning empty responses to
-   unsupported commands may be abused as a covert channel.
-
-   The reason for the client to send, in the Authenticator checksum
-   field, not only the server random number but the entire initial
-   server packet with the security layer bitmask and maximum cipher-text
-   buffer size accepted by server, is to prevent an attacker from
-   downgrading the security layer and preference for mutual
-   authentication ultimately selected.  The random number ties the
-   client and server to the same network session, prevent
-   man-in-the-middle attacks assuming a Kerberos 5 security layer is
-   chosen and that the Kerberos 5 security layer is secure.
-
-
-
-Josefsson                Expires August 3, 2003                [Page 16]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-   Generating AS-REP using a legacy password database requires
-   calculating the string2key operation.  This may be a costly operation
-   (in particular for the recent AES ciphers), so servers should either
-   pre-calculate and store the key once or take precautions against
-   opening itself up to a Denial Of Service attack which exhausts CPU
-   power on the server.
-
-   The security considerations of Kerberos 5 and SASL are inherited.
-   Some immediate consequences of this follows (this is an inconclusive
-   summary):
-
-   Note that some of the Kerberos 5 encryption types are considered
-   weak, implementations must decide which algorithms are trusted.
-
-   Note that the encryption types indicated in AS-REQ/TGS-REQ are not
-   integrity protected, so an attacker may downgrade the encryption keys
-   ultimately used.
-
-   Note that Kerberos 5 do not authorize users, it only authenticate
-   users.  Applications using this mechanism must thus perform checks,
-   not described in detail in this document, to make sure the
-   authenticated user is authorized to the service she is requesting.
-
-   Note that the SASL framework is subject to "downgrade" attacks where
-   an attacker forces a weaker SASL mechanism to be used.  The use of,
-   e.g., TLS [5] can be used to mitigate this.
-
-   Note that clients should use the server name exactly as the user
-   specified, or at least abstain from canonicalizing the server name
-   with insecure mechanisms such as unprotected DNS.
-
-Normative References
-
-   [1]  Kohl, J. and B. Neuman, "The Kerberos Network Authentication
-        Service (V5)", RFC 1510, September 1993.
-
-   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [3]  Myers, J., "Simple Authentication and Security Layer (SASL)",
-        RFC 2222, October 1997.
-
-Informative References
-
-   [4]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-        Recommendations for Security", RFC 1750, December 1994.
-
-   [5]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
-
-
-
-Josefsson                Expires August 3, 2003                [Page 17]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-        P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
-        1999.
-
-   [6]  Linn, J., "Generic Security Service Application Program
-        Interface Version 2, Update 1", RFC 2743, January 2000.
-
-
-Author's Address
-
-   Simon Josefsson
-   Drottningholmsv. 70
-   Stockholm  112 42
-   Sweden
-
-   EMail: simon@josefsson.org
-
-Acknowledgments
-
-   Text and ideas was borrowed from the Kerberos version 4 SASL
-   mechanism in RFC 2222.  Lawrence Greenfield suggested adding a
-   security consideration about server name canonicalization.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires August 3, 2003                [Page 18]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Josefsson                Expires August 3, 2003                [Page 19]
-
-Internet-Draft        A Kerberos 5 SASL Mechanism          February 2003
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                Expires August 3, 2003                [Page 20]
-
diff --git a/doc/standardisation/draft-kamada-krb-client-friendly-cross-02.txt b/doc/standardisation/draft-kamada-krb-client-friendly-cross-02.txt
deleted file mode 100644
index 3bcc4816c..000000000
--- a/doc/standardisation/draft-kamada-krb-client-friendly-cross-02.txt
+++ /dev/null
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    Ken'ichi Kamada
-INTERNET-DRAFT                                            Shoichi Sakane
-Expires: January 10, 2008                  Yokogawa Electric Corporation
-                                                            July 9, 2007
-
-
-            Client-Friendly Cross-Realm Model for Kerberos 5
-             draft-kamada-krb-client-friendly-cross-02.txt
-
-
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft expires on January 10, 2008.
-
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-
-
-
-
-
-
-
-
-
-Kamada and Sakane                                               [Page 1]
-
-Internet-Draft         Client-Friendly Cross-Realm             July 2007
-
-
-Abstract
-
-   This document proposes a cross-realm traversal model, which is
-   suitable for resource-limited clients, for Kerberos Version 5.  This
-   model provides a way to move the cost of consecutive Ticket-Granting
-   Service (TGS) exchanges from clients to Key Distribution Centers
-   (KDCs) and a way to reduce the traversal cost by generating a direct
-   inter-realm relationship between two realms.  The document describes
-   behavior of clients and KDCs, but does not specify any wire format,
-   which need to be specified separately.
-
-
-Table of Contents
-
-    1. Introduction .................................................  3
-    2. Problems on Client Performance ...............................  3
-       2.1. Long Authentication Path ................................  4
-       2.2. Client-Centric Ticketing ................................  4
-    3. Proposal of Client-Friendly Cross-Realm Model ................  4
-       3.1. Temporary Inter-Realm Relationship Generation Mode ......  5
-       3.2. Attorney Ticketing Mode .................................  6
-       3.3. Combination of the Two Modes ............................  7
-    4. Advantage of The Proposed Model for Deployment ...............  8
-       4.1. Compatibility with Traditional Kerberos Deployment ......  8
-       4.2. Orthogonality of the Two Modes ..........................  8
-    5. Front-End Protocol for Attorney Ticketing Mode ...............  9
-    6. Related Protocols Currently Proposed ......................... 10
-       6.1. PKCROSS ................................................. 10
-       6.2. XTGS .................................................... 10
-    7. Interoperability Considerations .............................. 10
-    8. Security Considerations ...................................... 11
-       8.1. Denial of Service (DoS) ................................. 11
-       8.2. Ticketing Policy ........................................ 11
-    9. IANA Considerations .......................................... 12
-   10. Acknowledgments .............................................. 12
-   11. References ................................................... 12
-       11.1. Normative References ................................... 12
-       11.2. Informative References ................................. 12
-   Authors' Addresses ............................................... 13
-   Full Copyright Statement ......................................... 13
-   Intellectual Property Statement .................................. 13
-
-
-
-
-
-
-
-
-
-
-Kamada and Sakane                                               [Page 2]
-
-Internet-Draft         Client-Friendly Cross-Realm             July 2007
-
-
-1.  Introduction
-
-   Kerberos Version 5 [RFC4120] has a concept of cross-realm
-   authentication so that principals in different realms can
-   authenticate each other.  However in the current cross-realm model,
-   each client has to traverse the authentication path, and the burden
-   of the traversal is not negligible for clients with limited
-   resources, e.g., computational speed or power supply [CRPS].
-
-   In the current cross-realm operation, a client obtains a service
-   ticket for a remote principal in the following steps:
-
-   1)  N TGSes to get cross-realm TGTs in order to traverse the
-       intermediate realms, where N is the number of transit, and
-
-   2)  One TGS to get the final service ticket.
-
-   That is, the client needs to perform N + 1 transactions to obtain a
-   ticket for the remote service.
-
-   This document proposes a new cross-realm model, which consists of
-   "temporary inter-realm relationship generation mode" and "attorney
-   ticketing mode".  The former is intended to reduce transit cost
-   itself, and the latter is to move the cost from clients to KDCs.  The
-   document describes behavior of clients and KDCs, but does not specify
-   any wire format, which need to be specified separately.
-
-   Terms defined in section 1.7 of RFC 4120 are used throughout this
-   document.
-
-
-2.  Problems on Client Performance
-
-   In the current model of cross-realm operation, a client has to
-   transit all realms on the path to the destination realm.  When the
-   source realm and the destination realm have a direct inter-realm
-   relationship, a client is able to obtain a service ticket with two
-   TGS transactions (one for a cross-realm TGT and another for the
-   service ticket).  When the realms have a multi-hop relationship, a
-   client must transit the intermediate realms before it obtains the
-   service ticket.  That is, the client's task increases in proportion
-   to the distance of the relationship.
-
-   Two issues can be observed here behind the client load, which are
-   described in the following subsections.
-
-
-
-
-
-
-Kamada and Sakane                                               [Page 3]
-
-Internet-Draft         Client-Friendly Cross-Realm             July 2007
-
-
-2.1.  Long Authentication Path
-
-   When a client wants to get a service ticket for a remote realm, it
-   must transit to the remote realm by traversing the intermediate
-   realms on the authentication path to the remote realm.  The result of
-   traversal is cached as a cross-realm TGT, but it is nothing more than
-   a per-client optimization.  Thus all clients accessing a remote realm
-   must pay the cost separately, even if their resources are limited.
-   For a long authentication path, the cost of the whole system becomes
-   large.
-
-2.2.  Client-Centric Ticketing
-
-   In Kerberos, any service tickets or cross-realm TGTs are issued via
-   TGS, where a client present a ticket for the TGS and obtains a next
-   ticket.  Currently, all TGS transactions are initiated by the client
-   and it needs to get all necessary cross-realm TGTs iteratively before
-   the final service ticket.  This process is a burden to a resource-
-   limited client.
-
-
-3.  Proposal of Client-Friendly Cross-Realm Model
-
-   In this section, two modes of operation are introduced, "Temporary
-   Inter-Realm Relationship Generation Mode" and "Attorney Ticketing
-   Mode", to solve the issues described in the previous section.  These
-   two modes are designed to be independent, that is, can be used
-   separately or in combination.
-
-   Temporary Inter-Realm Relationship Generation Mode solves the issue
-   of the long authentication path.  In this mode, if the source realm
-   and the destination realm do not have a direct inter-realm
-   relationship, the source KDC traverses the authentication path by
-   itself, contacts with the remote KDC, and generates a direct inter-
-   realm relationship between them.  After that, the source KDC can
-   issue direct inter-realm TGTs for the destination realm.  The purpose
-   of this mode is to reduce the traversal cost itself by caching the
-   result of traversal.
-
-   Attorney Ticketing Mode solves the issue of the client-centric
-   ticketing.  Consecutive TGS transactions to get cross-realm TGTs
-   and/or a final service ticket are initiated by a client in the
-   traditional Kerberos, whereas a KDC undertake that process in this
-   mode.  The purpose of this mode is to shift the cost of TGSes from a
-   client to a KDC.  This does not reduce the cost itself.
-
-
-
-
-
-
-Kamada and Sakane                                               [Page 4]
-
-Internet-Draft         Client-Friendly Cross-Realm             July 2007
-
-
-3.1.  Temporary Inter-Realm Relationship Generation Mode
-
-   Temporary inter-realm relationship generation mode enables a KDC to
-   issue an inter-realm TGT directly to a remote KDC with which the KDC
-   doesn't preshare an inter-realm key.  To issue an inter-realm TGT
-   directly, a temporary inter-realm key needs to be provided somehow.
-   To achieve that, the local KDC obtains a special ticket for the
-   remote KDC and uses its session key as an inter-realm key.  This
-   methodology was introduced by PKCROSS [PKCROSS].  In this document,
-   that special ticket is called as an "inter-KDC ticket", and an inter-
-   realm TGT generated from an inter-KDC ticket is called as a "direct
-   inter-realm TGT".
-
-   How does the local KDC reach the remote KDC is out of scope of this
-   model, but we can easily come up with 1) traversing a long
-   authentication path if available or 2) using PKINIT.  In the context
-   of this model, PKCROSS is interpreted as a combination of this mode
-   and PKINIT.
-
-   This document does not standardize a specific protocol, but an inter-
-   KDC ticket will have the following form:
-
-   -  its sname has a special form (PKCROSS proposes
-      "pkcross/realm@REALM", but it would be better to use a more
-      general name than "pkcross"),
-
-   and a direct inter-realm TGT will have the following form:
-
-   -  its TicketExtensions field [KRBEXT] contains the inter-KDC ticket,
-      and
-
-   -  it is protected by the session key (or the sub-session key) of the
-      inter-KDC ticket.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamada and Sakane                                               [Page 5]
-
-Internet-Draft         Client-Friendly Cross-Realm             July 2007
-
-
-         client C                KDC-L          KDC-I          KDC-R
-         --------                -----          -----          -----
-
-      1.    --------TGS-REQ-------->
-      2.                           [Reach to KDC-R in any way.]
-                                   [Below is an example of PKCROSS.]
-                                   ------------PKINIT------------>
-                                   <----------XTKT(L,R)-----------
-      3.    <--TKT(C,R)w/XTKT(L,R)--
-      4.    ----------------------TGS-REQ------------------------>
-      5.    <---------------------TKT(C,S)------------------------
-
-      [Note: TKT(x,y) means a ticket whose cname is x and sname is y.  ]
-      [      XTKT is an inter-KDC ticket.  See PKCROSS.                ]
-      [      The client C and KDC-L belong to the local realm L.       ]
-      [      The KDC-I is a KDC of an intermediate realm I.            ]
-      [      The KDC-R is a KDC of the remote realm R.                 ]
-
-      1. The client C sends a normal TGS-REQ to KDC-L, requesting
-         a cross-realm TGT to KDC-R.
-      2. KDC-L reaches KDC-R in any way and obtains a XTKT.
-         There is no standardized way to achieve this step yet.
-         PKCROSS is one candidate.  We could also standardize a way
-         in which KDC-L normally transits to KDC-R and obtains an XTKT.
-      3. KDC-L generates a cross-realm TGT that is from C to KDC-R
-         and returns to it to C.
-      4. The same with the traditional cross-realm TGS.
-      5. The same with the traditional cross-realm TGS.
-
-        Figure 1: Message Flow of Temporary Inter-Realm Relationship
-                  Generation
-
-3.2.  Attorney Ticketing Mode
-
-   Traditionally, a Kerberos client repeats TGS transactions until it
-   gets the final ticket.  For example, it has a TGT for its own realm
-   and wants to get a ticket for a service in 3-hop neighbor realm, then
-   it will:
-
-   1)  Present the TGT and get a cross-realm TGT for the next realm,
-
-   2)  Present the 1st cross-realm TGT and get a cross-realm TGT for the
-       2nd next realm,
-
-   3)  Present the 2nd cross-realm TGT and get a cross-realm TGT for the
-       final realm, and
-
-
-
-
-
-Kamada and Sakane                                               [Page 6]
-
-Internet-Draft         Client-Friendly Cross-Realm             July 2007
-
-
-   4)  Present the final cross-realm TGT and get a service ticket.
-
-   Attorney ticketing mode enables the client to delegate the KDC to
-   perform all transactions listed above on behalf of the client.  An
-   example message flow is shown in Figure 2.  The client entrust the
-   KDC with its TGT (step 1).  The KDC "impersonates" the client and
-   performs all necessary TGS transactions (steps 2 to 4), and returns
-   the final ticket to the client (step 5).
-
-         client C                KDC-L          KDC-I          KDC-R
-         --------                -----          -----          -----
-
-      1.    --------TGS-REQ-------->
-      2.                        TKT(C,I)
-      3.                           ----TGS-REQ---->
-                                   <---TKT(C,R)----
-      4.                           ------------TGS-REQ----------->
-                                   <-----------TKT(C,S)-----------
-      5.    <-------TKT(C,S)--------
-
-      1. The client C sends a special TGS-REQ, which indicates attorney
-         ticketing mode requesting a service ticket for a server S
-         instead of a cross-realm TGT, to KDC-L.
-      2. KDC-L internally generates a cross-realm TGT that is from C
-         to KDC-I, but does not return it to C.
-      3. KDC-L uses the generated cross-realm TGT by itself, and sends
-         a TGS-REQ to KDC-I, which requests a cross-realm TGT from C
-         to KDC-R.
-      4. KDC-L use the obtained cross-realm TGT by itself, and sends
-         a TGS-REQ to KDC-R, which requests a service ticket from C
-         to S.
-      5. KDC-L returns the final service ticket to C.
-
-             Figure 2: Message Flow of Attorney Ticketing Mode
-
-3.3.  Combination of the Two Modes
-
-   Figure 3 shows a typical message flow when the temporary inter-realm
-   relationship generation mode and the attorney ticketing mode are used
-   in combination.  The figure shows the case of the initial contact, so
-   a transaction to obtain an inter-KDC ticket is shown (step 2), but it
-   is infrequently used because the XTKT is cached.  Usually, only two
-   round-trips do all the work.
-
-
-
-
-
-
-
-
-Kamada and Sakane                                               [Page 7]
-
-Internet-Draft         Client-Friendly Cross-Realm             July 2007
-
-
-         client C                KDC-L          KDC-I          KDC-R
-         --------                -----          -----          -----
-
-      1.    --------TGS-REQ-------->
-      2.                           [Temporary inter-realm relationship
-                                   generation mode runs here.]
-                                   ------------PKINIT------------>
-                                   <----------XTKT(L,R)-----------
-      3.                           [Attorney ticketing mode runs here.]
-                           TKT(C,R)w/XTKT(L,R)
-      4.                           ------------TGS-REQ----------->
-                                   <-----------TKT(C,S)-----------
-      5.    <-------TKT(C,S)--------
-
-       Figure 3: Message Flow When Temporary Inter-Realm Relationship
-                 Generation Mode and Attorney Ticketing Mode
-                 Are Combined
-
-
-4.  Advantage of The Proposed Model for Deployment
-
-4.1.  Compatibility with Traditional Kerberos Deployment
-
-   Temporary inter-realm relationship generation involves only KDCs.
-   From the viewpoint of a client (and a server), it seems that there is
-   a direct inter-realm relationship between two realms.  This means
-   that temporary inter-realm relationship generation mode needs to be
-   deployed only in KDCs.  This property is advantageous, because it
-   does not affect large installed base of clients.  One impeding factor
-   in practice is that some existing implementations cannot handle
-   ticket extensions transparently.  This is further discussed in
-   Interoperability Considerations section.
-
-   Attorney ticketing mode involves only a client and its local KDC.
-   From the viewpoint of the remote KDC, TGS-REQs from a KDC as an
-   attorney cannot be distinguished from those from a "genuine" client
-   (except caddr; see Interoperability Considerations section).
-   Resulting service ticket is identical to the traditional one, so the
-   remote server has nothing to do with this mode.  In short, attorney
-   ticketing mode can be deployed in local realm, independently of the
-   remote deployment.  The merit of this property is large, because
-   remote realms are often in different administration.
-
-4.2.  Orthogonality of the Two Modes
-
-   Temporary inter-realm relationship generation mode and attorney
-   ticketing mode are independent concepts.  Both can be implemented
-   separately or can be used in combination.  When they are combined,
-
-
-
-Kamada and Sakane                                               [Page 8]
-
-Internet-Draft         Client-Friendly Cross-Realm             July 2007
-
-
-   the load of clients are shifted to KDCs and additional load of KDCs
-   are minimized, thus efficient cross-realm environment is achieved.
-
-
-5.  Front-End Protocol for Attorney Ticketing Mode
-
-   This document does not specify wire-level protocol, which will be
-   done in another document.  This section provides some candidates for
-   the protocol, which is used to request attorney ticketing mode from a
-   KDC (Figure 4).  This protocol can be used for other than attorney
-   ticketing mode, as long as the KDC's behavior for clients is
-   identical to the mode.
-
-     +------+             +-------+
-     |client|------------>|  KDC  |-------------> cross-realm cloud
-     +------+             +-------+  Cross-realm
-        Front-end protocol           traversal by KDC
-        to request a final           (Attorney Ticketing Mode)
-        ticket in one shot
-                                       or
-
-                                   -------------> remote KDC (directly)
-                                     XTGSP
-
-                                       or
-
-                                   ------------->
-                                     Whatever the KDC chooses
-
-          Figure 4: Front-End Protocol for Attorney Ticketing Mode
-
-   Candidate 1: Implicit Signaling
-
-      A client simply requests a final ticket to the local KDC.  If the
-      KDC supports this implicit protocol, it will process the request.
-      If not, KDC_ERR_S_PRINCIPAL_UNKNOWN will be returned.  A possible
-      drawback is that if a requested final ticket is for a TGS, the KDC
-      does not know whether the client expects normal mode or attorney
-      mode.  In addition, implicit signaling can conflict with future
-      extensions.
-
-   Candidate 2: Explicit Signaling
-
-      A flag in KDCOptions or pre-authentication can be used to request
-      attorney mode.
-      [[what happens if not supported?]]
-
-
-
-
-
-Kamada and Sakane                                               [Page 9]
-
-Internet-Draft         Client-Friendly Cross-Realm             July 2007
-
-
-6.  Related Protocols Currently Proposed
-
-6.1.  PKCROSS
-
-   PKCROSS will be usable as a protocol for temporary inter-realm
-   relationship generation mode.
-
-6.2.  XTGS
-
-   The purpose of XTGS protocol is similar to that of this model, but
-   the behavior is somewhat different [XTGS].  If XTGS is viewed from
-   the perspective of this model, it blends the two modes indivisibly to
-   reduce the number of messages between KDCs as far as possible at the
-   price of the abstraction of cross-realm TGTs and inter-KDC tickets.
-
-   Once a front-end (i.e., between a client and a KDC) protocol to
-   request attorney ticketing mode is standardized, XTGS can be used as
-   an opaque back-end.
-
-
-7.  Interoperability Considerations
-
-   User-to-user mode
-      The protocol for the attorney mode should be able to indicate
-      user-to-user authentication.
-
-   The addresses field in TGS-REQ
-      This field is copied into the caddr field in EncTicketPart, so if
-      this field is used in a TGS-REQ, the resulting ticket can be used
-      only from the specified addresses.  When the local KDC receives a
-      TGS-REQ requesting attorney mode, it should copy the addresses
-      field only into the final TGS-REQ in the attorney process.  It
-      must not copy the field into TGS-REQs to intermediate KDCs,
-      because resulting tickets are to be used by the local KDC instead
-      of the client.
-
-   Opacity of ticket extensions
-      The ticket extensions defined in rfc1510ter [KRBEXT] extends the
-      Ticket ASN.1 type, which is visible to clients.  This is not a
-      problem if a client implementation treats a Ticket as an opaque
-      data, and there are such implementations, but unfortunately the
-      major free implementations do not.  On the other hand, there is a
-      proposal of etype-based ticket extensions [TKTEXTALT].  It
-      encapsulates cleartext bits in the enc-part component of a Ticket.
-      It should not have any problems of opacity.
-
-   [[negotiation of various parameters]]
-
-
-
-
-Kamada and Sakane                                              [Page 10]
-
-Internet-Draft         Client-Friendly Cross-Realm             July 2007
-
-
-   [[If there are multiple authentication paths and a client has enough
-   knowledge, it could choose which path to take.  With attorney
-   ticketing mode, it cannot because it is up to the KDC to select the
-   path.  Is this a problem?  With temporary inter-realm relationship
-   generation mode, it can as before.]]
-
-   [[co-existence with the plain Kerberos; attorney ticketing mode
-   client vs. non-attorney KDC; inter-realm generating local KDC vs.
-   non-generating remote KDC]]
-
-   [[anything to do with referral?]]
-
-   [[when a KDC in attorney mode receives a KRB-ERROR?]]
-
-
-8.  Security Considerations
-
-8.1.  Denial of Service (DoS)
-
-   A KDC that implements attorney ticketing mode needs to initiate
-   multiple TGS-REQ upon a request from a client.  This means that the
-   KDC will have some states in it and may suffer from DoS attacks.
-
-   Fortunately, attorney ticketing mode can be requested in TGS-REQ,
-   which is only available to authenticated clients, thus, any untrusted
-   party cannot exploit this statefulness.
-
-8.2.  Ticketing Policy
-
-   Attorney ticketing mode changes nothing about the messages sent to
-   the intermediate and remote KDCs.  Those KDCs will not notice the
-   difference and their ticketing process have nothing to be changed.
-
-   Temporary inter-realm relationship generation mode dynamically
-   generates new authentication paths.  This means that KDCs that are
-   involved in the transit of a client are different from those that
-   would be involved if this mode were not used.
-
-   -  Parameters of cross-realm TGTs (lifetime and flags) for a new
-      relationship need to be dynamically transferred (a la PKCROSS).
-
-   -  How to handle the transited fields in inter-KDC tickets, direct
-      inter-realm tickets, and service tickets?
-
-   -  Where the remote KDC adds AuthorizationData and the end-server
-      checks it: there is no problem because it is a local matter of the
-      remote realm.
-
-
-
-
-Kamada and Sakane                                              [Page 11]
-
-Internet-Draft         Client-Friendly Cross-Realm             July 2007
-
-
-   -  Where an intermediate KDC adds AuthorizationData: traditionally it
-      is added in a cross-realm TGT and propagated to the service
-      ticket; now it will be propagated to the inter-KDC ticket.  Should
-      AuthorizationData in an inter-KDC ticket be copied into a cross-
-      realm TGT or not?  Even if it is copied, AuthorizationData on
-      inter-KDC ticket cannot represent per-client information, so if it
-      is necessary, temporary inter-realm relationship generation mode
-      must not be used.
-
-
-9.  IANA Considerations
-
-   This document has no actions for IANA.
-
-
-10.  Acknowledgments
-
-   The authors would like to acknowledge Saber Zrelli, Masahiro
-   Ishiyama, Atsushi Inoue, Kazunori Miyazawa, and Nobuo Okabe for
-   contributions to this document.
-
-
-11.  References
-
-11.1.  Normative References
-
-   [KRBEXT]      Yu, T., "The Kerberos Network Authentication Service
-                 (Version 5)", draft-ietf-krb-wg-rfc1510ter-04, Work in
-                 Progress, March 2007.
-
-   [RFC4120]     Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-                 Kerberos Network Authentication Service (V5)", RFC
-                 4120, July 2005.
-
-11.2.  Informative References
-
-   [CRPS]        Sakane, S., Zrelli, S., M. Ishiyama, "Problem statement
-                 on the cross-realm operation of Kerberos in a specific
-                 system", draft-sakane-krb-cross-problem-statement-02,
-                 Work in Progress, April 2007.
-
-   [PKCROSS]     Hur, M. et al., "Public Key Cryptography for Cross-
-                 Realm Authentication in Kerberos", draft-ietf-cat-
-                 kerberos-pk-cross-08 (expired), Work in Progress,
-                 November 2001.
-
-   [TKTEXTALT]   Message-ID: <tslfy54akcb.fsf@mit.edu>.
-
-
-
-
-Kamada and Sakane                                              [Page 12]
-
-Internet-Draft         Client-Friendly Cross-Realm             July 2007
-
-
-   [XTGS]        Zrelli, S. et al., "XTGSP, the Inter-TGS protocol for
-                 cross-realm operations in Kerberos", draft-zrelli-krb-
-                 xtgsp-01, Work in Progress, March 2007.
-
-Authors' Addresses
-
-   Ken'ichi Kamada
-   Shoichi Sakane
-   Yokogawa Electric Corporation
-   2-9-32 Nakacho, Musashino-shi,
-   Tokyo 180-8750 Japan
-   E-mail: Ken-ichi.Kamada@jp.yokogawa.com,
-           Shouichi.Sakane@jp.yokogawa.com
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-
-Kamada and Sakane                                              [Page 13]
-
-Internet-Draft         Client-Friendly Cross-Realm             July 2007
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamada and Sakane                                              [Page 14]
-
diff --git a/doc/standardisation/draft-lha-kitten-deleg-policy-00.txt b/doc/standardisation/draft-lha-kitten-deleg-policy-00.txt
deleted file mode 100644
index 64b0e8d3a..000000000
--- a/doc/standardisation/draft-lha-kitten-deleg-policy-00.txt
+++ /dev/null
@@ -1,672 +0,0 @@
-
-
-
-Network Working Group                               L. Hornquist Astrand
-Internet-Draft                                               Apple, Inc.
-Intended status: Standards Track                              S. Hartman
-Expires: February 14, 2009                        Painless Security, LLC
-                                                         August 13, 2008
-
-
-                GSS-API: Delegate if approved by policy
-                  draft-lha-gssapi-delegate-policy-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on February 14, 2009.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 1]
-
-Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
-
-
-Abstract
-
-   Several GSS-API applications work in a multi-tiered architecture,
-   where the server takes advantage of delegated user credentials to act
-   on behalf of the user and contact additional servers.  In effect, the
-   server acts as an agent on behalf of the user.  Examples include web
-   applications that need to access e-mail or file servers as well as
-   CIFs file servers.  However, delegating the ability to act as a user
-   to a party who is not sufficiently trusted is problematic from a
-   security standpoint.  Kerberos provides a flag called OK-AS-DELEGATE
-   that allows the administrator of a Kerberos realm to communicate that
-   a particular service is trusted for delegation.  This specification
-   adds support for this flag and similar facilities in other
-   authentication mechanisms to GSS-API (RFC 2743).
-
-
-Table of Contents
-
-   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  GSS-API flag, c binding  . . . . . . . . . . . . . . . . . . .  5
-   4.  GSS-API behavior . . . . . . . . . . . . . . . . . . . . . . .  6
-   5.  GSS-API behavior . . . . . . . . . . . . . . . . . . . . . . .  7
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 2]
-
-Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
-
-
-1.  Requirements Notation
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 3]
-
-Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
-
-
-2.  Introduction
-
-   Several GSS-API applications work in a multi-tiered architecture,
-   where the server takes advantage of delegated user credentials to act
-   on behalf of the user and contact additional servers.  In effect, the
-   server acts as an agent on behalf of the user.  Examples include web
-   applications that need to access e-mail or file servers as well as
-   CIFs file servers.  However, delegating the ability to act as a user
-   to a party who is not sufficiently trusted is problematic from a
-   security standpoint.
-
-   Today, GSS-API [RFC2743] leaves the determination of whether
-   delegation is desired to the client application.  If the client sets
-   the deleg_req_flag to gss_init_sec_context then the application
-   requests delegation.  This requires client applications to know what
-   services should be trusted for delegation.  In some cases, however, a
-   central authority is in a better position to know what services
-   should receive delegation than the client application.  Some
-   mechanisms such as Kerberos [RFC4121] have a facility to allow a
-   realm administrator to communicate that a particular service is a
-   valid target for delegation.  In Kerberos, the KDC can set the OK-AS-
-   DELEGATE flag in issued tickets.  However even in such a case,
-   delegating to services for applications that do not need delegation
-   is problematic.  So, it is desirable for a GSS-API client to be able
-   to request delegation if and only-if central policy reccomends
-   delegation to the given target.
-
-   This specification adds a new input flag to GSS_Init_sec_context to
-   request delegation when approved by central policy.  In addition, a
-   constant value to be used in the GSS-API C bindings [RFC2744] is
-   defined.  Finally, the behavior for the Kerberos mechanism [RFC4121]
-   is specified.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 4]
-
-Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
-
-
-3.  GSS-API flag, c binding
-
-   The GSS_Init_sec_context API is extended to gain a new input flag: if
-   the deleg_policy_req flag is set, then delegation should be performed
-   if recommended by central policy.  In addition, the C bindings are
-   extended to define the following constant to represent this new flag.
-
-
-
-   #define GSS_C_DELEG_POLICY_FLAG 32768
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 5]
-
-Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
-
-
-4.  GSS-API behavior
-
-   As before, if the GSS_C_DELEG_FLAG is set, the GSS-API mechanism
-   tries to delegate.  Output ret_flags contains the flag
-   GSS_C_DELEG_FLAG if delegation is successful.
-
-   If the GSS_C_DELEG_POLICY_FLAG is set, the code delegates only if the
-   mechanism policy allows delegation.  If delegation is done, the
-   output flag ret_flags contain both GSS_C_DELEG_FLAG and
-   GSS_C_DELEG_POLICY_FLAG on the initator and GSS_C_DELEG_FLAG on the
-   acceptor.
-
-   If both GSS_C_DELEG_FLAG and GSS_C_DELEG_POLICY_FLAG are set, then
-   delegation is attempted.  However GSS_C_DELEG_POLICY_FLAG is only set
-   in ret_flags on the initiator if GSS_C_DELEG_POLICY_FLAG would have
-   been sufficient to request delegation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 6]
-
-Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
-
-
-5.  GSS-API behavior
-
-   If the GSS_C_DELEG_POLICY_FLAG is set, the Kerberos GSS-API mechanism
-   will only delegate if ok-as-delegate is set [RFC4120] in the service
-   ticket.  Other policy checks MAY be applied.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 7]
-
-Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
-
-
-6.  Security Considerations
-
-   Introduce a flag what allows client to get help from the KDC when to
-   delegate to servers, will limit what servers that client delegate
-   too.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 8]
-
-Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
-
-
-7.  IANA Considerations
-
-   This section needs to be revised to be consistent with the kitten
-   IANA draft.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Hartman  Expires February 14, 2009          [Page 9]
-
-Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
-
-
-8.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Hartman  Expires February 14, 2009         [Page 10]
-
-Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
-
-
-Authors' Addresses
-
-   Love Hornquist Astrand
-   Apple, Inc.
-
-   Email: lha@apple.com
-
-
-   Sam Hartman
-   Painless Security, LLC
-
-   Email: hartmans-ietf@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand & Hartman  Expires February 14, 2009         [Page 11]
-
-Internet-Draft   GSS-API: Delegate if approved by policy     August 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Hornquist Astrand & Hartman  Expires February 14, 2009         [Page 12]
-
diff --git a/doc/standardisation/draft-lha-krb-wg-ticket-extensions-00.txt b/doc/standardisation/draft-lha-krb-wg-ticket-extensions-00.txt
deleted file mode 100644
index e43aadee3..000000000
--- a/doc/standardisation/draft-lha-krb-wg-ticket-extensions-00.txt
+++ /dev/null
@@ -1,728 +0,0 @@
-
-
-
-Network Working Group                               L. Hornquist Astrand
-Internet-Draft                                                Apple, Inc
-Intended status: Standards Track                         August 13, 2008
-Expires: February 14, 2009
-
-
-                       Kerberos ticket extensions
-                 draft-lha-krb-wg-ticket-extensions-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on February 14, 2009.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand       Expires February 14, 2009               [Page 1]
-
-Internet-Draft         Kerberos ticket extensions            August 2008
-
-
-Abstract
-
-   The Kerberos protocol does not allow ticket extensions.  This make it
-   harder to deploy features like referrals and PKCROSS.
-
-   Since the Kerberos protocol did not specified extensibility for the
-   Ticket structure and the current implementations are aware of the
-   contents of tickets, the extension protocol cannot simply extend the
-   Ticket ASN.1 structure.  Instead, the extension data needs to be
-   hidden inside the ticket.
-
-
-Table of Contents
-
-   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
-   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  How to request a new assignment for a ticket extension . . . .  6
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
-   Appendix A.  Ticket-extensions ASN.1 Module  . . . . . . . . . . . 11
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
-   Intellectual Property and Copyright Statements . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand       Expires February 14, 2009               [Page 2]
-
-Internet-Draft         Kerberos ticket extensions            August 2008
-
-
-1.  Requirements Notation
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand       Expires February 14, 2009               [Page 3]
-
-Internet-Draft         Kerberos ticket extensions            August 2008
-
-
-2.  Protocol
-
-   The ticket and enc-part as defined by [RFC4120] is defined as follow:
-
-
-   Ticket          ::= [APPLICATION 1] SEQUENCE {
-           tkt-vno         [0] INTEGER (5),
-           realm           [1] Realm,
-           sname           [2] PrincipalName,
-           enc-part        [3] EncryptedData -- EncTicketPart
-   }
-
-   EncryptedData   ::= SEQUENCE {
-           etype   [0] Int32 -- EncryptionType --,
-           kvno    [1] UInt32 OPTIONAL,
-           cipher  [2] OCTET STRING -- ciphertext
-   }
-
-
-
-   This document uses the special encryption type etype-TBETicket to
-   signal that enc-part.cipher contains the DER-encoded TBETicket
-   structure, instead of an encrypted EncTicketPart.
-
-
-
-   etype-TBETicket INTEGER ::= 4711 -- TBA XXX --
-
-   krb5int32  ::= INTEGER (-2147483648..2147483647)
-
-   TBETicket ::= SEQUENCE {
-           etype           [0] krb5int32 -- EncryptionType --,
-           cipher          [1] OCTET STRING
-           extensions      [2] SEQUENCE OF TicketExtension OPTIONAL
-
-   }
-
-   TicketExtension ::= SEQUENCE {
-           te-type [0] krb5int32,
-           te-data [1] OCTET STRING
-           te-csum [2] Checksum OPTIONAL
-   }
-
-
-   The content of cipher data and encryption type fields is moved inside
-   TBETicket.
-
-   Negative ticket extensions types (te-type) is private extensions and
-
-
-
-Hornquist Astrand       Expires February 14, 2009               [Page 4]
-
-Internet-Draft         Kerberos ticket extensions            August 2008
-
-
-   MUST only be used for experimentation.
-
-   The te-type field is specificing the type of the content in te-data.
-   Unknown te-types MUST be ignored both by the client and the server.
-
-   The te-csum field is optional for the type, when in use by type type
-   specifed in te-type, the key have to be specifed (usually the session
-   key of the ticket) and the key usage number.
-
-   The KDC MUST only return this extension in the AS-REQ if all other
-   KDCs for the same realm also supports this extension.
-
-   The KDC MUST only return this extension in the TGS-REQ to server the
-   KDC knows supports these extension.  This includes both cross realm
-   tickets and service tickets.
-
-   The KDC MAY return extended tickets to servers supporting ticket
-   extensions even if the extended ticket does not contain any
-   extensions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand       Expires February 14, 2009               [Page 5]
-
-Internet-Draft         Kerberos ticket extensions            August 2008
-
-
-3.  How to request a new assignment for a ticket extension
-
-   When anyone is writing a internet-draft for which a new assignment
-   for te-type is needed/wanted under the ticket extension, then the
-   proper way to do so is as follows:
-
-
-         EXAMPLE-MODULE DEFINITIONS ::= BEGIN
-
-         krb5-ticket-extension-Name ::= INTEGER nnn
-         -- IANA: please assign nnn
-         -- RFC-Editor: replace nnn with IANA-assigned
-         --             number and remove this note
-         END
-
-
-   IANA: Don't do note above, its an example, remove this note RFC-
-   Editor: Don't do note above, its an example, remove this note IANA
-   will assign the number as part of the RFC publication process.
-
-   When reviewing the document, the reviewer should take sure to check
-   that if te-csum is used, the siging key and key usage is specifed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand       Expires February 14, 2009               [Page 6]
-
-Internet-Draft         Kerberos ticket extensions            August 2008
-
-
-4.  Security Considerations
-
-   This document describes how to extend Kerberos tickets to include
-   additional data in the ticket.  This does have a security
-   implications since the extension data in the TBETicket is only
-   optionally signed, not encrypted and is not replay protected.  It is
-   up to the consumers of this interface to make sure its used safely.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand       Expires February 14, 2009               [Page 7]
-
-Internet-Draft         Kerberos ticket extensions            August 2008
-
-
-5.  Acknowledgements
-
-   Thanks to Leif Johansson, and Kamada Ken'ichi for reviewing the
-   document and provided suggestions for improvements.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand       Expires February 14, 2009               [Page 8]
-
-Internet-Draft         Kerberos ticket extensions            August 2008
-
-
-6.  IANA Considerations
-
-   There are currently no ticket extensions.  Future ticket extensions
-   will be published at:
-
-
-         http://www.iana.org/assignments/NNNNNNNN
-         -- IANA: please name registry, proposal: krb5-ticket-extensions
-
-
-   IANA is requested to maintain this registry for future assignments.
-   New assignments can only be made via Specification Required as
-   described in [RFC2434].
-
-   IANA will assign the number as part of the RFC publication process.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand       Expires February 14, 2009               [Page 9]
-
-Internet-Draft         Kerberos ticket extensions            August 2008
-
-
-7.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-              October 1998.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand       Expires February 14, 2009              [Page 10]
-
-Internet-Draft         Kerberos ticket extensions            August 2008
-
-
-Appendix A.  Ticket-extensions ASN.1 Module
-
-
-
-KerberosV5-TicketExtensions {
-       iso(1) identified-organization(3) dod(6) internet(1)
-       security(5) kerberosV5(2) modules(4) ticket-extensions(TBA)
---- XXX who is the registerar for this number ?
-} DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-IMPORTS
-        -- as defined in RFC 4120
-        Int32, Checksum
-                FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                     dod(6) internet(1) security(5) kerberosV5(2)
-                     modules(4) krb5spec2(2) }
-
-
-etype-TBETicket INTEGER ::= 4711 -- XXX TBA --
-
-TBETicket ::= SEQUENCE {
-        etype           [0] Int32 -- EncryptionType --,
-        cipher          [1] OCTET STRING
-        extensions      [2] SEQUENCE OF TicketExtension OPTIONAL
-}
-
-TicketExtension ::= SEQUENCE {
-        te-type [0] krb5int32,
-        te-data [1] OCTET STRING
-        te-csum [2] Checksum
-}
-
-END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand       Expires February 14, 2009              [Page 11]
-
-Internet-Draft         Kerberos ticket extensions            August 2008
-
-
-Author's Address
-
-   Love Hornquist Astrand
-   Apple, Inc
-   Cupertino
-   USA
-
-   Email: lha@apple.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hornquist Astrand       Expires February 14, 2009              [Page 12]
-
-Internet-Draft         Kerberos ticket extensions            August 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Hornquist Astrand       Expires February 14, 2009              [Page 13]
-
diff --git a/doc/standardisation/draft-morris-java-gssapi-update-for-csharp-00.txt b/doc/standardisation/draft-morris-java-gssapi-update-for-csharp-00.txt
deleted file mode 100644
index d65d8fb08..000000000
--- a/doc/standardisation/draft-morris-java-gssapi-update-for-csharp-00.txt
+++ /dev/null
@@ -1,249 +0,0 @@
-
-
-GSSAPI Java CSharp                                             C. Morris
-INTERNET-DRAFT                                               Novell, Inc.
-draft-morris-java-gssapi-update-for-csharp-00.txt     comorris@novell.com
-Expires 10 March 2004                                           July 2004
-
-
-         Generic Security Service API Version 2 : Java & C# Bindings
-
-Status of this Memo
-
-   Comments should be submitted to comorris@novell.com.
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed, or
-   will be disclosed, and any of which I become aware will be disclosed,
-   in accordance with RFC 3668.
-
-   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 a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-Abstract
-
-   The Generic Security Services Application Program Interface (GSS-API)
-   offers application programmers uniform access to security services
-   atop a variety of underlying cryptographic mechanisms. This document
-   proposes an update to RFC 2853, Generic Security Service API Version 
-   2 : Java Bindings, to include C# bindings.
-
-4.17.  C# Modifications
-
-   This section describes the language dependent modifications necessary
-   to implement the interface in C#. 
-   
-4.17.1   C# Assembly Name
-
-   The C# namespace is org.ietf.gss. See section 4.17.5 for an example.
-   
-4.17.2   C# Class Definitions
-   
-   All class definitions & methods remain the same as specified in the 
-   Java bindings.
-   
-4.17.3   C# Data Types
-
-   All data types remain the same.
-
-4.17.4   C# Exception Handling
-
-   All exception codes remain the same as specified in the Java bindings.
-   However, C# does not have a 'throws' statement. Therefore, method prototypes do
-   not include the exception type. For example,
-   
-   Java method prototype :
-   
-      public abstract GSSName createName(String nameStr, Oid nameType)
-         throws GSSException;
-  
-   Equivalent C# method prototype :
-  
-      public abstract GSSName createName(String nameStr, Oid nameType);
-    
-   C# does implement the throw and catch keywords, for example:
-   
-      public class GSSName createName(String nameStr, Oid nameType)
-      {
-         int majorCode = 0;
-         ...
-         
-         majorCode = validateParms(nameStr, nameType);
-         
-         if (majorCode)
-            throw new GSSException(majorCode);
-            
-         ...
-      }
-
-
-4.17.5   C# Example Code
-
-   Client example : 
-   
-   using ietf.org.gss;
-
-   class GssapiClient
-   {
-      private static TcpClient client;
-      private static NetworkStream stream;
-
-	   static void Main(string[] args)
-	   {
-		   Connect("127.0.0.1", "message from client");
-
-	   try
-	   {
-	      GSSManager manager = GSSManager.getInstance();
-
-	      Oid krb5Mechanism = new Oid("1.2.840.113554.1.2.2");
-	      Oid krb5PrincipalNameType = new Oid("1.2.840.113554.1.2.2.1");
-
-	      // Optionally Identify who the client wishes to be
-	      // GSSName name = manager.createName("test@gsserver", GSSName.NT_USER_NAME);
-      	
-	      // Obtain default credential
-	      GSSCredential userCreds = manager.createCredential(GSSCredential.INITIATE_ONLY);
-	      GSSName name = userCreds.getName(krb5PrincipalNameType);
-
-	      Console.WriteLine("Just acquired credentials for " + name.toString());
-
-	      int acceptLife = userCreds.getRemainingAcceptLifetime(new Oid("2.3.4"));
-	      int initLife   = userCreds.getRemainingInitLifetime(new Oid("1..3."));
-	      int remLife    = userCreds.getRemainingLifetime();
-	      int usage      = userCreds.getUsage();
-   	   
-	      GSSName namea = userCreds.getName();
-	      Oid[] oa = userCreds.getMechs();
-
-         // Instantiate and initialize a security context that will be
-         // established with the server
-	      GSSContext context = manager.createContext(name,
-						      krb5Mechanism,
-						      userCreds,
-						      GSSContext.DEFAULT_LIFETIME);
-
-	      userCreds.dispose();
-
-	      // Optionally Set Context Options, must be done before iniSecContext call
-	      context.requestMutualAuth(true);
-	      context.requestConf(true);
-	      context.requestInteg(true);
-	      context.requestSequenceDet(true);
-	      context.requestCredDeleg(true);
-
-	      MemoryStream ins = new MemoryStream();
-	      MemoryStream outs = new MemoryStream();
-
-	      // loop until context is setup and no more tokens to receive
-	      while (!context.isEstablished())
-	      {
-   	      outs = new MemoryStream();
-	         context.initSecContext(ins, outs);
-
-	         // send token if present
-	         if (outs.Length > 0)
-	         {
-		         Console.WriteLine("Sending token...");
-		         sendToken(outs);
-	         }
-
-	         // check if we should expect more tokens
-	         if (context.isEstablished())
-		         break;
-
-	         // another token expected from peer
-	         Console.WriteLine("Still expecting another token from server...");
-	         ins = recvToken();
-	      }
-
-	      //
-	      // display context information
-	      //
-
-	      // Did the server authenticate back to client?
-	      Console.WriteLine("\n{0} Mutual Authentication", 
-	      context.getMutualAuthState() ? "Using" : "Not using");
-	      Console.WriteLine("Credentials were delegated = " 
-   	      + context.getCredDelegState());
-	      Console.WriteLine("Remaining lifetime in seconds = " 
-	         + context.getLifetime());
-	      Console.WriteLine("Context mechanism = " + context.getMech());
-	      Console.WriteLine("Initiator = " + context.getSrcName().toString());
-	      Console.WriteLine("Acceptor = " + context.getTargName().toString());
-	      Console.WriteLine("Confidentiality (i.e., privacy) is {0}available", 
-	      context.getConfState() ? "" : "not ");
-	      Console.WriteLine("Integrity is {0}available", 
-	      context.getIntegState() ? "" : "not ");
-	      Console.WriteLine("Is initiator = " + context.isInitiator());
-	      Console.WriteLine("Is transferable = " + context.isTransferable());
-	      Console.WriteLine("Is protReady = " + context.isProtReady());
-	      Console.WriteLine("ReplayDetState = " + 
-	      context.getReplayDetState());
-	      Console.WriteLine("SequenceDetState = " + 
-	      context.getSequenceDetState());
-
-	      // perform wrap on an application supplied message
-	      // using QOP = 0, and requesting privacy service
-
-	      MessageProp msgProp = new MessageProp(0, true);
-	      byte [] message = System.Text.Encoding.ASCII.GetBytes("Hello GSS-API!");
-	      byte [] token = System.Text.Encoding.ASCII.GetBytes("tok");
-
-	      // Byte aray method is equivalent to stream method
-	      //byte []token = context.wrap(message, 0, appMsg.length, msgProp);
-	      //sendToken(token);
-
-	      ins = new MemoryStream();
-	      outs = new MemoryStream();
-	      ins.Write(token, 0, token.Length);
-	      context.getMIC(ins, outs, msgProp);
-	      sendToken(outs);
-
-	      outs = new MemoryStream();
-	      outs.Write(message, 0, message.Length);
-	      sendToken(outs);
-
-	      ins = new MemoryStream();
-	      outs = new MemoryStream();
-	      ins.Write(message, 0, message.Length);
-	      context.wrap(ins, outs, msgProp);
-	      sendToken(outs);
-
-         // Optionally export context to another thead
-	      GSSContext ctx = manager.createContext(context.export());
-	      Console.WriteLine("New context isTransferable = " + ctx.isTransferable());
-	      Console.WriteLine("New context isInitiator = " +ctx.isInitiator());
-	      Console.WriteLine("New context protReady = " +ctx.isProtReady());
-	      Console.WriteLine("New context srcName = " +ctx.getSrcName().toString());
-	      Console.WriteLine("New context targName = " +ctx.getTargName().toString());
-
-	      // release the local-end of the context
-	      ctx.dispose();
-
-	      stream.Close();
-	      Console.WriteLine("Leaving...");
-	   }
-	   catch (GSSException e)
-	   {
-	      Console.WriteLine(e.getMessage());
-	      Console.WriteLine(e.StackTrace);
-	   }
-	}
-
-
-Expires 10 March 2004                                 
-
-
diff --git a/doc/standardisation/draft-ms-krb-wg-gssapi-cfx-00.txt b/doc/standardisation/draft-ms-krb-wg-gssapi-cfx-00.txt
deleted file mode 100644
index 0f959cb8e..000000000
--- a/doc/standardisation/draft-ms-krb-wg-gssapi-cfx-00.txt
+++ /dev/null
@@ -1,461 +0,0 @@
-
-
-
-<Kerberos Working Group>                                      Larry Zhu 
-Internet Draft                                                Microsoft 
-Updates: 1964                                        Karthik Jaganathan 
-Category: Standards Track                                     Microsoft 
-draft-ietf-krb-wg-gssapi-cfx-00.txt                     August 16, 2003 
-                                             Expires: February 16, 2004 
- 
-  Crypto Profile Based Support for the Inclusion of New Encryption and 
-        Checksum Algorithms in the Kerberos V5 GSSAPI Mechanism 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-      all provisions of Section 10 of RFC2026 [1].  
-    
-   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."  
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-    
-1. Abstract 
-    
-   [KCRYPTO] introduced a generic framework for the inclusion of new 
-   encryption and checksum algorithms to be used in the Kerberos V5 
-   protocol.  [AES-KRB5] describes a crypto profile (per [KCRYPTO]) for 
-   AES.  This document introduces a generic method for adding new 
-   crypto-systems to the GSSAPI-KerberosV5 mechanism based on crypto 
-   profiles as defined in [KCRYPTO].  It also describes the use of AES 
-   encryption for GSSAPI as an example of this new method. 
-    
-    
-2. Conventions used in this document 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
- 
-    
-3. Introduction 
-    
-   [GSSAPI-KRB5] describes the GSSAPI mechanism for Kerberos V5. It 
-   defines the format of context initiation, per-message and context 
-   deletion tokens.  When adding new crypto system support, the 
-
-  
-Zhu              Standards Trace - February 16, 2003                1 
-          Crypto Profile Support for Kerberos GSSAPI      August 2003 
- 
- 
-   approach taken in [GSSAPI-KRB5] is to add algorithm identifiers for 
-   each new cryptosystem.   
-    
-   The approach taken in this document is to use the same encryption 
-   and checksum algorithms specified by the crypto profile for the 
-   session key or subkey that is created during context negotiation.  
-   Message layouts of the per-message and context deletion tokens are 
-   revised to remove algorithm indicators and add extra information to 
-   support the generic crypto framework [KCRYPTO]. 
-    
-   "Newer" encryption and checksum types MUST use the new token formats 
-   defined in this document.  Older encryption and checksum types SHALL 
-   NOT use these new token formats.  The term "newer" is more precisely 
-   defined in [KRBCLAR]. 
-    
-   Note that in this document, "AES" is used for brevity to refer 
-   loosely to either aes128-cts-hmac-sha1-96 or aes256-cts-hmac-sha1-96 
-   as defined in [AES-KRB5]. 
-    
-4. Quality of Protection and Algorithm Identifiers 
- 
-   The GSSAPI specification [GSSAPI] provides for QOP values that can 
-   be used by the application to request a certain type of encryption 
-   or signing.  A zero QOP value is used to indicate the "default" 
-   protection; applications which use the default QOP are not 
-   guaranteed to be portable across implementations or even inter-
-   operate with different deployment configurations of the same 
-   implementation. Using an algorithm that is different from the one 
-   for which the key is defined may not be appropriate. Therefore, when 
-   the new method in this document is used, the QOP value is ignored. 
-    
-   The encryption and checksum algorithms in per-message and context 
-   deletion tokens are now implicitly defined by the algorithms 
-   associated with the session and subkey. Algorithms identifiers are 
-   therefore no longer needed and removed from the token headers. 
-    
-5. Key Derivation 
-    
-   To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 
-   "entropy-preserving" derived keys, for different purposes or key 
-   usages, from a base key or protocol key.  This document defines four 
-   key usage values below for signing and sealing messages: 
-    
-        Name                       value 
-      ------------------------------------- 
-      KG-USAGE-ACCEPTOR-SIGN         22 
-      KG-USAGE-ACCEPTOR-SEAL         23 
-      KG-USAGE-INITIATOR-SIGN        24 
-      KG-USAGE-INITIATOR-SEAL        25 
-          
-    
-   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 
-   used as the usage number in the key derivation function for deriving 
-   keys to be used in MIC and context deletion tokens, and KG-USAGE-
-Zhu              Standards Track - February 16, 2004                2 
-          Crypto Profile Support for Kerberos GSSAPI      August 2003 
- 
- 
-   ACCEPTOR-SEAL is used for Wrap tokens; similarly when the sender is 
-   the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage 
-   number in the key derivation function for MIC and context deletion 
-   tokens, KG-USAGE-INITIATOR-SEAL is used for Wrap Tokens.  Even if 
-   the Wrap token does not provide for confidentiality the same usage 
-   values specified above are used. 
-    
-6. Token Formats and Definitions 
-    
-   The new token formats defined in this document are designed to 
-   accommodate the requirements of newer crypto systems.  Certain 
-   implementations of GSSAPI, such as SSPI, allow for "scatter-gather" 
-   and in-place encryption, mostly by leveraging low level details of 
-   crypto systems.  The token layouts have been designed to satisfy the 
-   above requirements without incurring significant performance 
-   penalties or loosing generality.   
-    
-   The design along with the rationale behind it, is discussed in 
-   detail in the following sections. 
-    
-6.1. Sequence Number and Direction Indicators 
- 
-   The sequence number for any per-message or context deletion token is 
-   a 64 bit integer (expressed in big endian order). One separate byte 
-   is used as the directional indicator: the hex value FF if the sender 
-   is the context acceptor, 00 otherwise. Both the sequence number and 
-   the directional indicator are protected as specified in section 6.2.  
- 
-6.2. Encryption and Checksum Operations 
-    
-   The encryption algorithms defined by the crypto profiles provide for 
-   integrity protection. Therefore no separate checksum is needed.  
-    
-   In Wrap tokens that provide for confidentiality, the "header" (the 
-   first 16 bytes of the Wrap token) is appended to the plaintext data 
-   before encryption.  Hence the resulting Wrap token is {"header" | 
-   encrypt(plaintext-data | "header")}, where encrypt() is the 
-   encryption operation defined in the crypto profile. In Wrap tokens 
-   that do not provide for confidentiality, the checksum is calculated 
-   over the plaintext data concatenated with the token header (the 
-   first 16 bytes of the Wrap token).  Hence the resulting Wrap token 
-   is {"header" | plaintext-data | get_mic(plaintext-data | "header")}, 
-   where get_mic() is the checksum operation defined in the crypto 
-   profile. The parameters for the key and the cipher-state in the 
-   encrypt() and get_mic() operations have been omitted for brevity.  
-    
-   The resulting Wrap tokens bind the data to the token header, 
-   including the sequence number, directional indicator, and the 
-   rotation count. 
- 
-  [With AEAD, Wrap tokens with confidentiality do not need to encrypt 
-  the header and the overhead can be reduced slightly] 
-   
-
-Zhu              Standards Track - February 16, 2004                3 
-          Crypto Profile Support for Kerberos GSSAPI      August 2003 
- 
- 
-  For MIC tokens, the checksum is first calculated over the token 
-  header (the first 16 bytes of the MIC token) and then the to-be-
-  signed plaintext data.   
-   
-  For context deletion tokens, the checksum is calculated over the 
-  token header (the first 16 bytes of the context deletion token). 
-   
-  When AES is used, the checksum algorithm is HMAC_SHA1_96 and the 
-  checksum size is 12 bytes.  Data is pre-pended with a 16 byte 
-  confounder before encryption, and no padding is needed. 
-   
-6.3. RRC Field 
- 
-   A new field, called "RRC" (Right Rotation Count), is added to allow 
-   the data to be encrypted in place.  The resulting Wrap token in the 
-   previous section, excluding the first 16 bytes of the token header, 
-   is rotated to the right by "RRC" bytes.  The net result is that 
-   "RRC" bytes of trailing octets are moved toward the header.  
-   Consider the following as an example of this rotation operation: 
-   Assume that the RRC value is 3 and the token before the rotation is 
-   {"header" | aa | bb | cc | dd | ee | ff | gg | hh}, the token after 
-   rotation would be {"header" | ff | gg | hh | aa | bb | cc | dd | ee 
-   }, where {aa | bb | cc |...| hh} is used to indicate the byte 
-   sequence. 
-  
-   The RRC field is expressed as a two octet integer in big endian 
-   order. 
-    
-   The rotation count value is chosen by the sender based on 
-   implementation details, and the receiver MUST be able to interpret 
-   all possible rotation count values. 
-  
-6.4. EC Field 
- 
-   The decryption operation in the crypto profile may not always return 
-   the exact length of the plaintext data.  An "EC"(Extra Count) field 
-   is added to the Wrap() token header to indicate the number of bytes 
-   that have been added to the end of the plaintext data before 
-   encryption.  The "EC" field is a two byte integer expressed in big 
-   endian order and it should be 00 00 if confidentiality is not 
-   provided for by the Wrap tokens. 
-    
-6.5. Seal Field 
- 
-  The Seal field in Wrap tokens is used to indicate whether 
-  confidentiality is provided for.  If confidentiality is provided for 
-  by the Wrap token, this field contains the hex value FF, otherwise it 
-  contains the hex value 00. 
- 
-6.6. Message Layout for Per-message and Context Deletion Tokens 
-    
-   The new message layouts are as follows. 
-    
-   MIC Token: 
-Zhu              Standards Track - February 16, 2004                4 
-          Crypto Profile Support for Kerberos GSSAPI      August 2003 
- 
- 
-    
-      Byte no           Name             Description 
-       0..1            TOK_ID         Identification field. 
-                                      Tokens emitted by GSS_GetMIC()  
-                                      contain the hex value 04 04 in 
-                                      this field. 
-       2..2            Direction      Hex value FF if the sender is the  
-                                      context acceptor, 00 otherwise.    
-       3..7            Filler         Contains 5 bytes of hex value FF. 
-       8..15           SND_SEQ        Sequence number field in  
-                                      cleartext, in big endian order.  
-       16..            SGN_CKSUM      Checksum of byte 0..15 and the 
-                                      "to-be-signed" data, where the 
-                                      checksum algorithm is defined by      
-                                      the crypto profile for the  
-                                      session key or subkey. 
- 
-    
-   The Filler field is included in the checksum calculation for 
-   simplicity.  This is common to both MIC and context deletion token 
-   checksum calculations. 
- 
-   Wrap Token: 
-    
-      Byte no             Name           Description 
-       0..1            TOK_ID       Identification field. 
-                                    Tokens emitted by GSS_Wrap()                     
-                                    contain the hex value 05 04  
-                                    in this field. 
-       2..2            Direction    Hex value FF if the sender is the  
-                                    context acceptor, 00 otherwise.    
-       3..3            Seal         Confidentiality indicator: hex  
-                                    value FF if confidentiality is  
-                                    provided for, 00 otherwise. 
-       4..5            EC           Contains the "extra count" field,   
-                                    in big endian order as described in  
-                                    section 6.4. 
-       6..7            RRC          Contains the "right rotation                      
-                                    count" in big endian order, as  
-                                    described in section 6.3. 
-       8..15           SND_SEQ      Sequence number field in                      
-                                    cleartext, in big endian order. 
-       16..            Data         Encrypted or plaintext data, as  
-                                    described in section 6.2, where  
-                                    the encryption or checksum  
-                                    algorithm is defined by the crypto  
-                                    profile for the session key or  
-                                    subkey. 
-                                    
-                                   
-   Context Deletion Token:       
-    
-      Byte no          Name           Description 
-Zhu              Standards Track - February 16, 2004                5 
-          Crypto Profile Support for Kerberos GSSAPI      August 2003 
- 
- 
-       0..1           TOK_ID        Identification field. 
-                                    Tokens emitted by 
-                                    GSS_Delete_sec_context() contain 
-                                    the hex value 04 05 in this  
-                                    field. 
-       2..2           Direction     Hex value FF if the sender is the  
-                                    context acceptor, 00 otherwise.    
-       3..7           Filler        Contains 5 bytes of hex value FF. 
-       8..15          SND_SEQ       Sequence number field in  
-                                    cleartext, in big endian order.  
-       16..           SGN_CKSUM     Checksum of byte 0..15, where the 
-                                    checksum algorithm is defined by      
-                                    the crypto profile for the  
-                                    session key or subkey. 
-    
-                                   
-7. Backwards compatibility considerations 
- 
-   The new token formats defined in this document will only be 
-   recognized by new implementations.  A MIC or wrap token generated 
-   with the algorithms defined in this document will not be recognized 
-   by an older implementation that only recognizes the algorithms 
-   defined in [GSSAPI-KRB5].  To address this, implementations can 
-   always use the explicit sign or seal algorithm in [GSSAPI-KRB5] when 
-   the key type corresponds to those algorithms.  An alternative 
-   approach might be to retry sending the message with the sign or seal 
-   algorithm explicitly defined as in [GSSAPI-KRB5]. However this would 
-   require the use of a mechanism such as [SPNEGO] to securely 
-   negotiate the algorithm or the use out of band mechanism to choose 
-   appropriate algorithms.  For this reason, it is RECOMMENDED that the 
-   use of the new token formats defined in this document be confined 
-   only for "newer encryption and checksum" described by a crypto 
-   profile.  
- 
-8. Security Considerations 
- 
-   It is possible that the KDC returns a session-key type that is not 
-   supported by the GSSAPI implementation (either on the client and the 
-   server). In this case the implementation MUST not try to use the key 
-   with a supported cryptosystem. This will ensure that no security 
-   weaknesses arise due to the use of an inappropriate key with an 
-   encryption algorithm. 
-    
-   In addition the security problem described in [3DES] arising from 
-   the use of a service implementation with a GSSAPI mechanism 
-   supporting only DES and a Kerberos mechanism supporting both DES and 
-   Triple DES is actually a more generic one.  It arises whenever the 
-   GSSAPI implementation does not support a stronger cryptosystem 
-   supported by the Kerberos mechanism.  KDC administrators desiring to 
-   limit the session key types to support interoperability with such 
-   GSSAPI implementations should carefully weigh the reduction in 
-   protection offered by such mechanisms against the benefits of 
-   interoperability. 
-Zhu              Standards Track - February 16, 2004                6 
-          Crypto Profile Support for Kerberos GSSAPI      August 2003 
- 
- 
-    
-   It is recommended by some cryptographers that the output of a 
-   checksum used with an encryption algorithm should have the same 
-   strength as the key in use.  In this regard standardization work for 
-   SHA-256 and SHA-512 to be used with AES is currently in progress. 
-   This document retains the use of HMAC_SHA1_96 as specified in the 
-   [AES-KRB5] draft.  The use of SHA-256 or SHA-512 with AES will 
-   require new crypto profiles and there should not be any further 
-   changes needed to this document.  
-    
-9. Acknowledgments 
- 
-   
-  The authors wish to acknowledge the contributions from the following 
-  individuals:  
- 
-  Ken Raeburn and Nicolas Willams corrected many of our errors in the 
-  use of generic profiles and were instrumental in the creation of this 
-  draft. Sam Hartman and Ken Raeburn suggested the "floating trailer" 
-  idea.   
-   
-  Sam Hartman and Nicolas Williams recommended the replacing our 
-  earlier key derivation function for directional keys with different 
-  key usage numbers for each direction as well as retaining the 
-  directional bit for maximum compatibility.   
-   
-  Paul Leach provided numerous suggestions and comments. Scott Field, 
-  Richard Ward, Dan Simon also provided valuable inputs on this draft. 
- 
-10. References 
-    
-   [AES] National Institute of Standards and Technology, U.S. 
-   Department of Commerce, "Advanced Encryption Standard", Federal 
-   Information Processing Standards Publication 197, Washington, DC, 
-   November 2001. 
-    
-   [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
-   raeburn-krb-rijndael-krb-05.txt, June, 2003. Work in progress. 
-    
-   [DES3] Raeburn, K., "Triple-DES Support for the Kerberos 5 GSSAPI    
-   Mechanism", draft-raeburn-gssapi-krb5-3des-XX.txt in the MIT    
-   distribution, June 2000. 
-    
-    
-   [GSSAPI] Linn, J., "Generic Security Service Application Program    
-   Interface Version 2, Update 1", RFC 2743, January, 2000. 
-    
-   [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",    
-   RFC 1964, June, 1996. 
-    
-   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 
-   Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003. Work in 
-   progress.  
-
-Zhu              Standards Track - February 16, 2004                7 
-          Crypto Profile Support for Kerberos GSSAPI      August 2003 
- 
- 
-    
-   [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,    
-   Raeburn, K., "The Kerveros Network Authentication Service (V5)",    
-   http://www.isi.edu/people/bcn/draft-kerberos-rev.html/krb-
-   clarifications-00-020222.txt, February,2002. Work in progress. 
-    
-   [SPNEGO] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
-   Negotiation Mechanism.", RFC 2478, December 1998. 
-    
-11. Author's Address 
-    
-   Larry Zhu 
-   One Microsoft Way 
-   Redmond, WA 98052 - USA 
-   EMail: LZhu@microsoft.com 
- 
-   Karthik Jaganathan 
-   One Microsoft Way 
-   Redmond, WA 98052 - USA 
-   EMail: karthikj@microsoft.com 
- 
-    
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu              Standards Track - February 16, 2004                8 
diff --git a/doc/standardisation/draft-newman-auth-scram-09.txt b/doc/standardisation/draft-newman-auth-scram-09.txt
deleted file mode 100644
index 915b9adea..000000000
--- a/doc/standardisation/draft-newman-auth-scram-09.txt
+++ /dev/null
@@ -1,1080 +0,0 @@
-

-

-

-

-

-

-Network Working Group                                  Abhijit Menon-Sen

-Internet-Draft                                    Oryx Mail Systems GmbH

-Intended Status: Proposed Standard                          Chris Newman

-Expires: August 2009                                    Sun Microsystems

-                                                         Alexey Melnikov

-                                                               Isode Ltd

-                                                       February 15, 2009

-

-

-            Salted Challenge Response (SCRAM) SASL Mechanism

-

-                     draft-newman-auth-scram-09.txt

-

-

-Status of this Memo

-

-    This Internet-Draft is submitted to IETF in full conformance with

-    the provisions of BCP 78 and BCP 79.

-

-    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."

-

-    The list of current Internet-Drafts can be accessed at

-    http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-

-    Draft Shadow Directories can be accessed at

-    http://www.ietf.org/shadow.html.

-

-    This Internet-Draft expires in July 2009.

-

-

-Copyright Notice

-

-    Copyright (c) 2009 IETF Trust and the persons identified as the

-    document authors.  All rights reserved.

-

-    This document is subject to BCP 78 and the IETF Trust's Legal

-    Provisions Relating to IETF Documents

-    (http://trustee.ietf.org/license-info) in effect on the date of

-    publication of this document.  Please review these documents

-    carefully, as they describe your rights and restrictions with

-    respect to this document.

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 1]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-Abstract

-

-    The secure authentication mechanism most widely deployed and used by

-    Internet application protocols is the transmission of clear-text

-    passwords over a channel protected by Transport Layer Security

-    (TLS).  There are some significant security concerns with that

-    mechanism, which could be addressed by the use of a challenge

-    response authentication mechanism protected by TLS. Unfortunately,

-    the challenge response mechanisms presently on the standards track

-    all fail to meet requirements necessary for widespread deployment,

-    and have had success only in limited use.

-

-    This specification describes a family of authentication mechanisms

-    called the Salted Challenge Response Authentication Mechanism

-    (SCRAM), which addresses the security concerns and meets the

-    deployability requirements. When used in combination with TLS or an

-    equivalent security layer, a mechanism from this family could

-    improve the status-quo for application protocol authentication and

-    provide a suitable choice for a mandatory-to-implement mechanism for

-    future application protocol standards.

-

-

-1. Conventions Used in This Document

-

-    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

-    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

-    document are to be interpreted as described in [RFC2119].

-

-    Formal syntax is defined by [RFC5234] including the core rules

-    defined in Appendix B of [RFC5234].

-

-    Example lines prefaced by "C:" are sent by the client and ones

-    prefaced by "S:" by the server. If a single "C:" or "S:" label

-    applies to multiple lines, then the line breaks between those lines

-    are for editorial clarity only, and are not part of the actual

-    protocol exchange.

-

-

-1.1. Terminology

-

-    This document uses several terms defined in [RFC4949] ("Internet

-    Security Glossary") including the following: authentication,

-    authentication exchange, authentication information, brute force,

-    challenge-response, cryptographic hash function, dictionary attack,

-    eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,

-    one-way encryption function, password, replay attack and salt.

-    Readers not familiar with these terms should use that glossary as a

-    reference.

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 2]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-    Some clarifications and additional definitions follow:

-

-    - Authentication information: Information used to verify an identity

-      claimed by a SCRAM client. The authentication information for a

-      SCRAM identity consists of salt, iteration count, the "StoredKey"

-      and "ServerKey" (as defined in the algorithm overview) for each

-      supported cryptographic hash function.

-

-    - Authentication database: The database used to look up the

-      authentication information associated with a particular identity.

-      For application protocols, LDAPv3 (see [RFC4510]) is frequently

-      used as the authentication database. For network-level protocols

-      such as PPP or 802.11x, the use of RADIUS is more common.

-

-    - Base64: An encoding mechanism defined in [RFC4648] which converts

-      an octet string input to a textual output string which can be

-      easily displayed to a human. The use of base64 in SCRAM is

-      restricted to the canonical form with no whitespace.

-

-    - Octet: An 8-bit byte.

-

-    - Octet string: A sequence of 8-bit bytes.

-

-    - Salt: A random octet string that is combined with a password

-      before applying a one-way encryption function. This value is used

-      to protect passwords that are stored in an authentication

-      database.

-

-

-1.2. Notation

-

-    The pseudocode description of the algorithm uses the following

-    notations:

-

-    - ":=": The variable on the left hand side represents the octet

-      string resulting from the expression on the right hand side.

-

-    - "+": Octet string concatenation.

-

-    - "[ ]": A portion of an expression enclosed in "[" and "]" may not

-      be included in the result under some circumstances. See the

-      associated text for a description of those circumstances.

-

-    - HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in

-      [RFC2104]) using the octet string represented by "key" as the key

-      and the octet string "str" as the input string. The size of the

-      result is the hash result size for the hash function in use. For

-      example, it is 20 octets for SHA-1 (see [RFC3174]).

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 3]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-    - H(str): Apply the cryptographic hash function to the octet string

-      "str", producing an octet string as a result. The size of the

-      result depends on the hash result size for the hash function in

-      use.

-

-    - XOR: Apply the exclusive-or operation to combine the octet string

-      on the left of this operator with the octet string on the right of

-      this operator. The length of the output and each of the two inputs

-      will be the same for this use.

-

-    - Hi(str, salt):

-

-         U0   := HMAC(str, salt || INT(1))

-         U1   := HMAC(str, U0)

-         U2   := HMAC(str, U1)

-         ...

-         Ui-1 := HMAC(str, Ui-2)

-         Ui   := HMAC(str, Ui-1)

-

-         Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui

-      where "i" is the iteration count, "||" is the string concatenation

-      operator and INT(g) is a four-octet encoding of the integer g,

-      most significant octet first.

-

-      This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and

-      with dkLen == output length of HMAC() == output length of H().

-

-

-

-2. Introduction

-

-    This specification describes a family of authentication mechanisms

-    called the Salted Challenge Response Authentication Mechanism

-    (SCRAM) which addresses the requirements necessary to deploy a

-    challenge-response mechanism more widely than past attempts. When

-    used in combination with Transport Layer Security (TLS, see [TLS])

-    or an equivalent security layer, a mechanism from this family could

-    improve the status-quo for application protocol authentication and

-    provide a suitable choice for a mandatory-to-implement mechanism for

-    future application protocol standards.

-

-    For simplicity, this family of mechanism does not presently include

-    negotiation of a security layer. It is intended to be used with an

-    external security layer such as that provided by TLS or SSH.

-

-    SCRAM provides the following protocol features:

-

-    - The authentication information stored in the authentication

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 4]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-      database is not sufficient by itself to impersonate the client.

-      The information is salted to prevent a pre-stored dictionary

-      attack if the database is stolen.

-

-    - The server does not gain the ability to impersonate the client to

-      other servers (with an exception for server-authorized proxies).

-

-    - The mechanism permits the use of a server-authorized proxy without

-      requiring that proxy to have super-user rights with the back-end

-      server.

-

-    - A standard attribute is defined to enable storage of the

-      authentication information in LDAPv3 (see [RFC4510]).

-

-    - Both the client and server can be authenticated by the protocol.

-

-    For an in-depth discussion of why other challenge response

-    mechanisms are not considered sufficient, see appendix A. For more

-    information about the motivations behind the design of this

-    mechanism, see appendix B.

-

-    Comments regarding this draft may be sent either to the ietf-

-    sasl@imc.org mailing list or to the authors.

-

-

-3. SCRAM Algorithm Overview

-

-    Note that this section omits some details, such as client and server

-    nonces.  See Section 5 for more details.

-

-    To begin with, the client is in possession of a username and

-    password.  It sends the username to the server, which retrieves the

-    corresponding authentication information, i.e. a salt, StoredKey,

-    ServerKey and the iteration count i. (Note that a server

-    implementation may chose to use the same iteration count for all

-    account.) The server sends the salt and the iteration count to the

-    client, which then computes the following values and sends a

-    ClientProof to the server:

-

-        SaltedPassword  := Hi(password, salt)

-        ClientKey       := H(SaltedPassword)

-        StoredKey       := H(ClientKey)

-        AuthMessage     := client-first-message + "," +

-                           server-first-message + "," +

-                           final-client-message-without-proof

-        ClientSignature := HMAC(StoredKey, AuthMessage)

-        ClientProof     := ClientKey XOR ClientSignature

-        ServerKey       := HMAC(SaltedPassword, salt)

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 5]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-        ServerSignature := HMAC(ServerKey, AuthMessage)

-

-    The server authenticates the client by computing the

-    ClientSignature, exclusive-ORing that with the ClientProof to

-    recover the ClientKey and verifying the correctness of the ClientKey

-    by applying the hash function and comparing the result to the

-    StoredKey. If the ClientKey is correct, this proves that the client

-    has access to the user's password.

-

-    Similarly, the client authenticates the server by computing the

-    ServerSignature and comparing it to the value sent by the server.

-    If the two are equal, it proves that the server had access to the

-    user's ServerKey.

-

-    The AuthMessage is computed by concatenating messages from the

-    authentication exchange. The format of these messages is defined in

-    the Formal Syntax section.

-

-

-4. SCRAM mechanism names

-

-    A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the

-    uppercased name of the underlying hashed function taken from the

-    IANA "Hash Function Textual Names" registry (see

-    http://www.iana.org).

-

-    For interoperability, all SCRAM clients and servers MUST implement

-    the SCRAM-HMAC-SHA-1 authentication mechanism, i.e. an

-    authentication mechanism from the SCRAM family that uses the SHA-1

-    hash function as defined in [RFC3174].

-

-

-5. SCRAM Authentication Exchange

-

-    SCRAM is a text protocol where the client and server exchange

-    messages containing one or more attribute-value pairs separated by

-    commas. Each attribute has a one-letter name. The messages and their

-    attributes are described in section 5.1, and defined in the Formal

-    Syntax section.

-

-    This is a simple example of a SCRAM-HMAC-SHA-1 authentication

-    exchange:

-        C: n=Chris Newman,r=ClientNonce

-        S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128

-        C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4

-        S: v=WxPv/siO5l+qxN4

-

-    With channel-binding data sent by the client this might look like this:

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 6]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-        C: n=Chris Newman,r=ClientNonce

-        S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128

-        C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4

-        S: v=WxPv/siO5l+qxN4

-

-    <<Note that the channel-bind data above, as well as all hashes are fake>>

-

-    First, the client sends a message containing the username, and a

-    random, unique nonce. In response, the server sends the user's

-    iteration count i, the user's salt, and appends its own nonce to the

-    client-specified one.  The client then responds with the same nonce

-    and a ClientProof computed using the selected hash function as

-    explained earlier.  In this step the client can also include an

-    optional authorization identity.  The server verifies the nonce and

-    the proof, verifies that the authorization identity (if supplied by

-    the client in the second message) is authorized to act as the

-    authentication identity, and, finally, it responds with a

-    ServerSignature, concluding the authentication exchange. The client

-    then authenticates the server by computing the ServerSignature and

-    comparing it to the value sent by the server.  If the two are

-    different, the client MUST consider the authentication exchange to

-    be unsuccessful and it might have to drop the connection.

-

-

-5.1 SCRAM attributes

-

-    This section describes the permissible attributes, their use, and

-    the format of their values. All attribute names are single US-ASCII

-    letters and are case-sensitive.

-

-    - a: This optional attribute specifies an authorization identity. A

-      client may include it in its second message to the server if it

-      wants to authenticate as one user, but subsequently act as a

-      different user.  This is typically used by an administrator to

-      perform some management task on behalf of another user, or by a

-      proxy in some situations.

-

-      Upon the receipt of this value the server verifies its correctness

-      according to the used SASL protocol profile. Failed verification

-      results in failed authentication exchange.

-

-      If this attribute is omitted (as it normally would be), or

-      specified with an empty value, the authorization identity is

-      assumed to be derived from the username specified with the

-      (required) "n" attribute.

-

-      The server always authenticates the user specified by the "n"

-      attribute.  If the "a" attribute specifies a different user, the

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 7]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-      server associates that identity with the connection after

-      successful authentication and authorization checks.

-

-      The syntax of this field is the same as that of the "n" field with

-      respect to quoting of '=' and ','.

-

-    - n: This attribute specifies the name of the user whose password is

-      used for authentication. A client must include it in its first

-      message to the server. If the "a" attribute is not specified

-      (which would normally be the case), this username is also the

-      identity which will be associated with the connection subsequent

-      to authentication and authorization.

-

-      Before sending the username to the server, the client MUST prepare

-      the username using the "SASLPrep" profile [SASLPrep] of the

-      "stringprep" algorithm [RFC3454]. If the preparation of the

-      username fails or results in an empty string, the client SHOULD

-      abort the authentication exchange (*).

-

-      (*) An interactive client can request a repeated entry of the

-      username value.

-

-      Upon receipt of the username by the server, the server SHOULD

-      prepare it using the "SASLPrep" profile [SASLPrep] of the

-      "stringprep" algorithm [RFC3454]. If the preparation of the

-      username fails or results in an empty string, the server SHOULD

-      abort the authentication exchange.

-

-      The characters ',' or '=' in usernames are sent as '=2C' and '=3D'

-      respectively. If the server receives a username which contains '='

-      not followed by either '2C' or '3D', then the server MUST fail the

-      authentication.

-

-    - m: This attribute is reserved for future extensibility.  In this

-      version of SCRAM, its presence in a client or a server message

-      MUST cause authentication failure when the attribute is parsed by

-      the other end.

-

-    - r: This attribute specifies a sequence of random printable

-      characters excluding ',' which forms the nonce used as input to

-      the hash function.  No quoting is applied to this string (unless

-      the binding of SCRAM to a particular protocol states otherwise).

-      As described earlier, the client supplies an initial value in its

-      first message, and the server augments that value with its own

-      nonce in its first response. It is important that this be value

-      different for each authentication. The client MUST verify that the

-      initial part of the nonce used in subsequent messages is the same

-      as the nonce it initially specified. The server MUST verify that

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 8]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-      the nonce sent by the client in the second message is the same as

-      the one sent by the server in its first message.

-

-    - c: This optional attribute specifies base64-encoded channel-

-      binding data. It is sent by the client in the second step. If

-      specified by the client, if the server supports the specified

-      channel binding type and if the server can't verify it, then the

-      server MUST fail the authentication exchange.  Whether this

-      attribute is included, and the meaning and contents of the

-      channel-binding data depends on the external security layer in

-      use. This is necessary to detect a man-in-the-middle attack on the

-      security layer.

-

-    - s: This attribute specifies the base64-encoded salt used by the

-      server for this user. It is sent by the server in its first

-      message to the client.

-

-    - i: This attribute specifies an iteration count for the selected

-      hash function and user, and must be sent by the server along with

-      the user's salt.

-

-      For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a hash

-      iteration-count of at least 128.

-

-    - p: This attribute specifies a base64-encoded ClientProof. The

-      client computes this value as described in the overview and sends

-      it to the server.

-

-    - v: This attribute specifies a base64-encoded ServerSignature. It

-      is sent by the server in its final message, and may be used by the

-      client to verify that the server has access to the user's

-      authentication information. This value is computed as explained in

-      the overview.

-

-

-6. Formal Syntax

-

-    The following syntax specification uses the Augmented Backus-Naur

-    Form (ABNF) notation as specified in [RFC5234].  "UTF8-2", "UTF8-3"

-    and "UTF8-4" non-terminal are defined in [UTF-8].

-

-      generic-message = attr-val *("," attr-val)

-                        ;; Generic syntax of any server challenge

-                        ;; or client response

-

-      attr-val        = ALPHA "=" value

-

-      value           = *(value-char)

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 9]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-      value-safe-char = %01-2B / %2D-3C / %3E-7F /

-                        UTF8-2 / UTF-3 / UTF8-4

-                        ;; UTF8-char except NUL, "=", and ",".

-

-      value-char      = value-safe-char / "="

-

-      base64-char     = ALPHA / DIGIT / "/" / "+"

-

-      base64-4        = 4*4(base64-char)

-

-      base64-3        = 3*3(base64-char) "="

-

-      base64-2        = 2*2(base64-char) "=="

-

-      base64          = *(base64-4) [base64-3 / base64-2]

-

-      posit-number = (%x31-39) *DIGIT

-                        ;; A positive number

-

-      saslname        = 1*(value-safe-char / "=2C" / "=3D")

-                        ;; Conforms to <value>

-

-      authzid         = "a=" saslname

-                        ;; Protocol specific.

-

-      username        = "n=" saslname

-                        ;; Usernames are prepared using SASLPrep.

-

-      reserved-mext  = "m=" 1*(value-char)

-                        ;; Reserved for signalling mandatory extensions.

-                        ;; The exact syntax will be defined in

-                        ;; the future.

-

-      channel-binding = "c=" base64

-

-      proof           = "p=" base64

-

-      nonce           = "r=" c-nonce [s-nonce]

-                        ;; Second part provided by server.

-

-      c-nonce         = value

-

-      s-nonce         = value

-

-      salt            = "s=" base64

-

-      verifier        = "v=" base64

-                        ;; base-64 encoded ServerSignature.

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 10]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-      iteration-count = "i=" posit-number

-                        ;; A positive number

-

-      client-first-message =

-                        [reserved-mext ","] username "," nonce [","

-                        extensions]

-

-      server-first-message =

-                        [reserved-mext ","] nonce "," salt ","

-                        iteration-count ["," extensions]

-

-      client-final-message-without-proof =

-                        [authzid ","] [channel-binding ","] nonce [","

-                        extensions]

-

-      client-final-message =

-                        client-final-message-without-proof "," proof

-

-      server-final-message =

-                        verifier ["," extensions]

-

-      extensions = attr-val *("," attr-val)

-                        ;; All extensions are optional,

-                        ;; i.e. unrecognized attributes

-                        ;; not defined in this document

-                        ;; MUST be ignored.

-

-

-7. Security Considerations

-

-    If the authentication exchange is performed without a strong

-    security layer, then a passive eavesdropper can gain sufficient

-    information to mount an offline dictionary or brute-force attack

-    which can be used to recover the user's password. The amount of time

-    necessary for this attack depends on the cryptographic hash function

-    selected, the strength of the password and the iteration count

-    supplied by the server. An external security layer with strong

-    encryption will prevent this attack.

-

-    If the external security layer used to protect the SCRAM exchange

-    uses an anonymous key exchange, then the SCRAM channel binding

-    mechanism can be used to detect a man-in-the-middle attack on the

-    security layer and cause the authentication to fail as a result.

-    However, the man-in-the-middle attacker will have gained sufficient

-    information to mount an offline dictionary or brute-force attack.

-    For this reason, SCRAM includes the ability to increase the

-    iteration count over time.

-

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 11]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-    If the authentication information is stolen from the authentication

-    database, then an offline dictionary or brute-force attack can be

-    used to recover the user's password. The use of salt mitigates this

-    attack somewhat by requiring a separate attack on each password.

-    Authentication mechanisms which protect against this attack are

-    available (e.g., the EKE class of mechanisms), but the patent

-    situation is presently unclear.

-

-    If an attacker obtains the authentication information from the

-    authentication repository and either eavesdrops on one

-    authentication exchange or impersonates a server, the attacker gains

-    the ability to impersonate that user to all servers providing SCRAM

-    access using the same hash function, password, iteration count and

-    salt.  For this reason, it is important to use randomly-generated

-    salt values.

-

-    If the server detects (from the value of the client-specified "h"

-    attribute) that both endpoints support a stronger hash function that

-    the one the client actually chooses to use, then it SHOULD treat

-    this as a downgrade attack and reject the authentication attempt.

-

-    A hostile server can perform a computational denial-of-service

-    attack on clients by sending a big iteration count value.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 12]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-8. IANA considerations

-

-    IANA is requested to add the following entry to the SASL Mechanism

-    registry established by [RFC4422]:

-

-    To: iana@iana.org

-    Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1

-

-    SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1

-    Security considerations: Section 7 of [RFCXXXX]

-    Published specification (optional, recommended): [RFCXXXX]

-    Person & email address to contact for further information:

-     IETF SASL WG <ietf-sasl@imc.org>

-    Intended usage: COMMON

-    Owner/Change controller: IESG <iesg@ietf.org>

-    Note:

-

-    Note that even though this document defines a family of SCRAM-HMAC

-    mechanisms, it doesn't register a family of SCRAM-HMAC mechanisms in

-    the SASL Mechanisms registry. IANA is requested to prevent future

-    registrations of SASL mechanisms starting with SCRAM-HMAC- without

-    consulting the SASL mailing list <ietf-sasl@imc.org> first.

-

-    Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC

-    SASL mechanism MUST be explicitly registered with IANA and MUST

-    comply with SCRAM-HMAC mechanism naming convention defined in

-    Section 4 of this document.

-

-

-

-9. Acknowedgements

-

-    The authors would like to thank Dave Cridland for his contributions

-    to this document.

-

-

-10. Normative References

-

-    [RFC4648]  Josefsson, "The Base16, Base32, and Base64 Data

-               Encodings", RFC 4648, SJD, October 2006.

-

-    [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO

-               10646", STD 63, RFC 3629, November 2003.

-

-    [RFC2104]  Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for

-               Message Authentication", IBM, February 1997.

-

-    [RFC2119]  Bradner, "Key words for use in RFCs to Indicate

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 13]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-               Requirement Levels", RFC 2119, Harvard University, March

-               1997.

-

-    [RFC3174]  Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC

-               3174, Motorola, September 2001

-

-    [RFC5234]  Crocker, Overell, "Augmented BNF for Syntax

-               Specifications: ABNF", RFC 5234, January 2008.

-

-    [RFC4422]  Melnikov, Zeilenga, "Simple Authentication and Security

-               Layer (SASL)", RFC 4422, Isode Limited, June 2006.

-

-    [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user

-               names and passwords", RFC 4013, February 2005.

-

-    [RFC3454] Hoffman, P., Blanchet, M., "Preparation of

-               Internationalized Strings ("stringprep")", RFC 3454,

-               December 2002.

-

-

-

-11. Informative References

-

-    [RFC2195]  Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension

-               for Simple Challenge/Response", RFC 2195, MCI, September

-               1997.

-

-    [RFC2202]  Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",

-               RFC 2202, IBM, September 1997

-

-    [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography

-               Specification Version 2.0", RFC 2898, September 2000.

-

-    [TLS]  Dierks, Rescorla, "The Transport Layer Security (TLS)

-               Protocol, Version 1.2", RFC 5246, August 2008.

-

-    [RFC4949]  Shirey, "Internet Security Glossary, Version 2", RFC

-               4949, FYI 0036, August 2007.

-

-    [RFC4086]  Eastlake, Schiller, Crocker, "Randomness Requirements for

-               Security", RFC 4086, BCP 0106, Motorola Laboratories,

-               June 2005.

-

-    [RFC4510]  Zeilenga, "Lightweight Directory Access Protocol (LDAP):

-               Technical Specification Road Map", RFC 4510, June 2006.

-

-    [DIGEST-MD5] Leach, P. and C. Newman , "Using Digest Authentication

-               as a SASL Mechanism", RFC 2831, May 2000.  <<Also draft-

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 14]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-               ietf-sasl-rfc2831bis-12.txt>>

-

-    [DIGEST-HISTORIC] Melnikov, "Moving DIGEST-MD5 to Historic", work in

-               progress, draft-ietf-sasl-digest-to-historic-00.txt, July

-               2008

-

-    [CRAM-HISTORIC] Zeilenga, "CRAM-MD5 to Historic", work in progress,

-               draft-ietf-sasl-crammd5-to-historic-00.txt, November

-               2008.

-

-    [PLAIN] Zeilenga, "The PLAIN Simple Authentication and Security

-               Layer (SASL) Mechanism" RFC 4616, August 2006.

-

-

-12. Authors' Addresses

-

-    Abhijit Menon-Sen

-    Oryx Mail Systems GmbH

-

-    Email: ams@oryx.com

-

-

-    Alexey Melnikov

-    Isode Ltd

-

-    EMail: Alexey.Melnikov@isode.com

-

-

-    Chris Newman

-    Sun Microsystems

-    1050 Lakes Drive

-    West Covina, CA 91790

-    USA

-

-    Email: chris.newman@sun.com

-

-

-Appendix A: Other Authentication Mechanisms

-

-    The DIGEST-MD5 [DIGEST-MD5] mechanism has proved to be too complex

-    to implement and test, and thus has poor interoperability. The

-    security layer is often not implemented, and almost never used;

-    everyone uses TLS instead.  For a more complete list of problems

-    with DIGEST-MD5 which lead to the creation of SCRAM see [DIGEST-

-    HISTORIC].

-

-    The CRAM-MD5 SASL mechanism, while widely deployed has also some

-    problems, in particular it is missing some modern SASL features such

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 15]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-    as support for internationalized usernames and passwords, support

-    for passing of authorization identity, support for channel bindings.

-    It also doesn't support server authentication.  For a more complete

-    list of problems with CRAM-MD5 see [CRAM-HISTORIC].

-

-    The PLAIN [PLAIN] SASL mechanism allows a malicious server or

-    eavesdropper to impersonate the authenticating user to any other

-    server for which the user has the same password. It also sends the

-    password in the clear over the network, unless TLS is used. Server

-    authentication is not supported.

-

-

-Appendix B: Design Motivations

-

-    The following design goals shaped this document. Note that some of

-    the goals have changed since the initial version of the document.

-

-      The SASL mechanism has all modern SASL features: support for

-      internationalized usernames and passwords, support for passing of

-      authorization identity, support for channel bindings.

-

-      Both the client and server can be authenticated by the protocol.

-

-      The authentication information stored in the authentication

-      database is not sufficient by itself to impersonate the client.

-

-      <<The server does not gain the ability to impersonate the client

-      to other servers (with an exception for server-authorized

-      proxies).>>

-

-      The mechanism is extensible, but [hopefully] not overengineered in

-      this respect.

-

-      Easier to implement than DIGEST-MD5 in both clients and servers.

-

-

-Appendix C: SCRAM Examples

-

-    <<To be written.>>

-

-

-

-

-

-

-

-

-

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 16]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-        (RFC Editor: Please delete everything after this point)

-

-

-Open Issues

-

-    - The appendices need to be written.

-

-    - Should the server send a base64-encoded ServerSignature for the

-      value of the "v" attribute, or should it compute a ServerProof the

-      way the client computes a ClientProof?

-

-

-Changes since -07

-

-    Updated References.

-

-    Clarified purpose of the m= attribute.

-

-    Fixed a problem with authentication/authorization identity's ABNF

-      not allowing for some characters.

-

-    Updated ABNF for nonce to show client-generated and server-generated

-      parts.

-

-    Only register SCRAM-HMAC-SHA-1 with IANA and require explicit

-      registrations of all other SCRAM-HMAC- mechanisms.

-

-

-

-Changes since -06

-

-    Removed hash negotiation from SCRAM and turned it into a family of

-      SASL mechanisms.

-

-    Start using "Hash Function Textual Names" IANA registry for SCRAM

-      mechanism naming.

-

-    Fixed definition of Hi(str, salt) to be consistent with [RFC2898].

-

-    Clarified extensibility of SCRAM: added m= attribute (for future

-      mandatory extensions) and specified that all unrecognized

-      attributes must be ignored.

-

-

-

-Changes since -05

-

-    Changed the mandatory to implement hash algorithm to SHA-1 (as per

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 17]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-      WG consensus).

-

-    Added text about use of SASLPrep for username

-      canonicalization/validation.

-

-    Clarified that authorization identity is canonicalized/verified

-      according to SASL protocol profile.

-

-    Clarified that iteration count is per-user.

-

-    Clarified how clients select the authentication function.

-

-    Added IANA registration for the new mechanism.

-

-    Added missing normative references (UTF-8, SASLPrep).

-

-    Various editorial changes based on comments from Hallvard B

-      Furuseth, Nico William and Simon Josefsson.

-

-

-

-Changes since -04

-

-    - Update Base64 and Security Glossary references.

-

-    - Add Formal Syntax section.

-

-    - Don't bother with "v=".

-

-    - Make MD5 mandatory to implement. Suggest i=128.

-

-

-

-Changes since -03

-

-    - Seven years have passed, in which it became clear that DIGEST-MD5

-      suffered from unacceptably bad interoperability, so SCRAM-MD5 is

-      now back from the dead.

-

-    - Be hash agnostic, so MD5 can be replaced more easily.

-

-    - General simplification.

-

-

-

-

-

-

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 18]

-

-

diff --git a/doc/standardisation/draft-newman-auth-scram-10.txt b/doc/standardisation/draft-newman-auth-scram-10.txt
deleted file mode 100644
index 640046e32..000000000
--- a/doc/standardisation/draft-newman-auth-scram-10.txt
+++ /dev/null
@@ -1,1080 +0,0 @@
-

-

-

-

-

-

-Network Working Group                                  Abhijit Menon-Sen

-Internet-Draft                                    Oryx Mail Systems GmbH

-Intended Status: Proposed Standard                          Chris Newman

-Expires: August 2009                                    Sun Microsystems

-                                                         Alexey Melnikov

-                                                               Isode Ltd

-                                                       February 21, 2009

-

-

-            Salted Challenge Response (SCRAM) SASL Mechanism

-

-                     draft-newman-auth-scram-10.txt

-

-

-Status of this Memo

-

-    This Internet-Draft is submitted to IETF in full conformance with

-    the provisions of BCP 78 and BCP 79.

-

-    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."

-

-    The list of current Internet-Drafts can be accessed at

-    http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-

-    Draft Shadow Directories can be accessed at

-    http://www.ietf.org/shadow.html.

-

-    This Internet-Draft expires in July 2009.

-

-

-Copyright Notice

-

-    Copyright (c) 2009 IETF Trust and the persons identified as the

-    document authors.  All rights reserved.

-

-    This document is subject to BCP 78 and the IETF Trust's Legal

-    Provisions Relating to IETF Documents

-    (http://trustee.ietf.org/license-info) in effect on the date of

-    publication of this document.  Please review these documents

-    carefully, as they describe your rights and restrictions with

-    respect to this document.

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 1]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-Abstract

-

-    The secure authentication mechanism most widely deployed and used by

-    Internet application protocols is the transmission of clear-text

-    passwords over a channel protected by Transport Layer Security

-    (TLS).  There are some significant security concerns with that

-    mechanism, which could be addressed by the use of a challenge

-    response authentication mechanism protected by TLS. Unfortunately,

-    the challenge response mechanisms presently on the standards track

-    all fail to meet requirements necessary for widespread deployment,

-    and have had success only in limited use.

-

-    This specification describes a family of authentication mechanisms

-    called the Salted Challenge Response Authentication Mechanism

-    (SCRAM), which addresses the security concerns and meets the

-    deployability requirements. When used in combination with TLS or an

-    equivalent security layer, a mechanism from this family could

-    improve the status-quo for application protocol authentication and

-    provide a suitable choice for a mandatory-to-implement mechanism for

-    future application protocol standards.

-

-

-1. Conventions Used in This Document

-

-    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

-    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

-    document are to be interpreted as described in [RFC2119].

-

-    Formal syntax is defined by [RFC5234] including the core rules

-    defined in Appendix B of [RFC5234].

-

-    Example lines prefaced by "C:" are sent by the client and ones

-    prefaced by "S:" by the server. If a single "C:" or "S:" label

-    applies to multiple lines, then the line breaks between those lines

-    are for editorial clarity only, and are not part of the actual

-    protocol exchange.

-

-

-1.1. Terminology

-

-    This document uses several terms defined in [RFC4949] ("Internet

-    Security Glossary") including the following: authentication,

-    authentication exchange, authentication information, brute force,

-    challenge-response, cryptographic hash function, dictionary attack,

-    eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,

-    one-way encryption function, password, replay attack and salt.

-    Readers not familiar with these terms should use that glossary as a

-    reference.

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 2]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-    Some clarifications and additional definitions follow:

-

-    - Authentication information: Information used to verify an identity

-      claimed by a SCRAM client. The authentication information for a

-      SCRAM identity consists of salt, iteration count, the "StoredKey"

-      and "ServerKey" (as defined in the algorithm overview) for each

-      supported cryptographic hash function.

-

-    - Authentication database: The database used to look up the

-      authentication information associated with a particular identity.

-      For application protocols, LDAPv3 (see [RFC4510]) is frequently

-      used as the authentication database. For network-level protocols

-      such as PPP or 802.11x, the use of RADIUS is more common.

-

-    - Base64: An encoding mechanism defined in [RFC4648] which converts

-      an octet string input to a textual output string which can be

-      easily displayed to a human. The use of base64 in SCRAM is

-      restricted to the canonical form with no whitespace.

-

-    - Octet: An 8-bit byte.

-

-    - Octet string: A sequence of 8-bit bytes.

-

-    - Salt: A random octet string that is combined with a password

-      before applying a one-way encryption function. This value is used

-      to protect passwords that are stored in an authentication

-      database.

-

-

-1.2. Notation

-

-    The pseudocode description of the algorithm uses the following

-    notations:

-

-    - ":=": The variable on the left hand side represents the octet

-      string resulting from the expression on the right hand side.

-

-    - "+": Octet string concatenation.

-

-    - "[ ]": A portion of an expression enclosed in "[" and "]" may not

-      be included in the result under some circumstances. See the

-      associated text for a description of those circumstances.

-

-    - HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in

-      [RFC2104]) using the octet string represented by "key" as the key

-      and the octet string "str" as the input string. The size of the

-      result is the hash result size for the hash function in use. For

-      example, it is 20 octets for SHA-1 (see [RFC3174]).

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 3]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-    - H(str): Apply the cryptographic hash function to the octet string

-      "str", producing an octet string as a result. The size of the

-      result depends on the hash result size for the hash function in

-      use.

-

-    - XOR: Apply the exclusive-or operation to combine the octet string

-      on the left of this operator with the octet string on the right of

-      this operator. The length of the output and each of the two inputs

-      will be the same for this use.

-

-    - Hi(str, salt):

-

-         U0   := HMAC(str, salt + INT(1))

-         U1   := HMAC(str, U0)

-         U2   := HMAC(str, U1)

-         ...

-         Ui-1 := HMAC(str, Ui-2)

-         Ui   := HMAC(str, Ui-1)

-

-         Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui

-      where "i" is the iteration count, "+" is the string concatenation

-      operator and INT(g) is a four-octet encoding of the integer g,

-      most significant octet first.

-

-      This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and

-      with dkLen == output length of HMAC() == output length of H().

-

-

-

-2. Introduction

-

-    This specification describes a family of authentication mechanisms

-    called the Salted Challenge Response Authentication Mechanism

-    (SCRAM) which addresses the requirements necessary to deploy a

-    challenge-response mechanism more widely than past attempts. When

-    used in combination with Transport Layer Security (TLS, see [TLS])

-    or an equivalent security layer, a mechanism from this family could

-    improve the status-quo for application protocol authentication and

-    provide a suitable choice for a mandatory-to-implement mechanism for

-    future application protocol standards.

-

-    For simplicity, this family of mechanism does not presently include

-    negotiation of a security layer. It is intended to be used with an

-    external security layer such as that provided by TLS or SSH.

-

-    SCRAM provides the following protocol features:

-

-    - The authentication information stored in the authentication

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 4]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-      database is not sufficient by itself to impersonate the client.

-      The information is salted to prevent a pre-stored dictionary

-      attack if the database is stolen.

-

-    - The server does not gain the ability to impersonate the client to

-      other servers (with an exception for server-authorized proxies).

-

-    - The mechanism permits the use of a server-authorized proxy without

-      requiring that proxy to have super-user rights with the back-end

-      server.

-

-    - A standard attribute is defined to enable storage of the

-      authentication information in LDAPv3 (see [RFC4510]).

-

-    - Both the client and server can be authenticated by the protocol.

-

-    For an in-depth discussion of why other challenge response

-    mechanisms are not considered sufficient, see appendix A. For more

-    information about the motivations behind the design of this

-    mechanism, see appendix B.

-

-    Comments regarding this draft may be sent either to the ietf-

-    sasl@imc.org mailing list or to the authors.

-

-

-3. SCRAM Algorithm Overview

-

-    Note that this section omits some details, such as client and server

-    nonces.  See Section 5 for more details.

-

-    To begin with, the client is in possession of a username and

-    password.  It sends the username to the server, which retrieves the

-    corresponding authentication information, i.e. a salt, StoredKey,

-    ServerKey and the iteration count i. (Note that a server

-    implementation may chose to use the same iteration count for all

-    account.) The server sends the salt and the iteration count to the

-    client, which then computes the following values and sends a

-    ClientProof to the server:

-

-        SaltedPassword  := Hi(password, salt)

-        ClientKey       := H(SaltedPassword)

-        StoredKey       := H(ClientKey)

-        AuthMessage     := client-first-message + "," +

-                           server-first-message + "," +

-                           client-final-message-without-proof

-        ClientSignature := HMAC(StoredKey, AuthMessage)

-        ClientProof     := ClientKey XOR ClientSignature

-        ServerKey       := HMAC(SaltedPassword, salt)

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 5]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-        ServerSignature := HMAC(ServerKey, AuthMessage)

-

-    The server authenticates the client by computing the

-    ClientSignature, exclusive-ORing that with the ClientProof to

-    recover the ClientKey and verifying the correctness of the ClientKey

-    by applying the hash function and comparing the result to the

-    StoredKey. If the ClientKey is correct, this proves that the client

-    has access to the user's password.

-

-    Similarly, the client authenticates the server by computing the

-    ServerSignature and comparing it to the value sent by the server.

-    If the two are equal, it proves that the server had access to the

-    user's ServerKey.

-

-    The AuthMessage is computed by concatenating messages from the

-    authentication exchange. The format of these messages is defined in

-    the Formal Syntax section.

-

-

-4. SCRAM mechanism names

-

-    A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the

-    uppercased name of the underlying hashed function taken from the

-    IANA "Hash Function Textual Names" registry (see

-    http://www.iana.org).

-

-    For interoperability, all SCRAM clients and servers MUST implement

-    the SCRAM-HMAC-SHA-1 authentication mechanism, i.e. an

-    authentication mechanism from the SCRAM family that uses the SHA-1

-    hash function as defined in [RFC3174].

-

-

-5. SCRAM Authentication Exchange

-

-    SCRAM is a text protocol where the client and server exchange

-    messages containing one or more attribute-value pairs separated by

-    commas. Each attribute has a one-letter name. The messages and their

-    attributes are described in section 5.1, and defined in the Formal

-    Syntax section.

-

-    This is a simple example of a SCRAM-HMAC-SHA-1 authentication

-    exchange:

-        C: n=Chris Newman,r=ClientNonce

-        S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128

-        C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4

-        S: v=WxPv/siO5l+qxN4

-

-    With channel-binding data sent by the client this might look like this:

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 6]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-        C: n=Chris Newman,r=ClientNonce

-        S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128

-        C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4

-        S: v=WxPv/siO5l+qxN4

-

-    <<Note that the channel-bind data above, as well as all hashes are fake>>

-

-    First, the client sends a message containing the username, and a

-    random, unique nonce. In response, the server sends the user's

-    iteration count i, the user's salt, and appends its own nonce to the

-    client-specified one.  The client then responds with the same nonce

-    and a ClientProof computed using the selected hash function as

-    explained earlier.  In this step the client can also include an

-    optional authorization identity.  The server verifies the nonce and

-    the proof, verifies that the authorization identity (if supplied by

-    the client in the second message) is authorized to act as the

-    authentication identity, and, finally, it responds with a

-    ServerSignature, concluding the authentication exchange. The client

-    then authenticates the server by computing the ServerSignature and

-    comparing it to the value sent by the server.  If the two are

-    different, the client MUST consider the authentication exchange to

-    be unsuccessful and it might have to drop the connection.

-

-

-5.1 SCRAM attributes

-

-    This section describes the permissible attributes, their use, and

-    the format of their values. All attribute names are single US-ASCII

-    letters and are case-sensitive.

-

-    - a: This optional attribute specifies an authorization identity. A

-      client may include it in its second message to the server if it

-      wants to authenticate as one user, but subsequently act as a

-      different user.  This is typically used by an administrator to

-      perform some management task on behalf of another user, or by a

-      proxy in some situations.

-

-      Upon the receipt of this value the server verifies its correctness

-      according to the used SASL protocol profile. Failed verification

-      results in failed authentication exchange.

-

-      If this attribute is omitted (as it normally would be), or

-      specified with an empty value, the authorization identity is

-      assumed to be derived from the username specified with the

-      (required) "n" attribute.

-

-      The server always authenticates the user specified by the "n"

-      attribute.  If the "a" attribute specifies a different user, the

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 7]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-      server associates that identity with the connection after

-      successful authentication and authorization checks.

-

-      The syntax of this field is the same as that of the "n" field with

-      respect to quoting of '=' and ','.

-

-    - n: This attribute specifies the name of the user whose password is

-      used for authentication. A client must include it in its first

-      message to the server. If the "a" attribute is not specified

-      (which would normally be the case), this username is also the

-      identity which will be associated with the connection subsequent

-      to authentication and authorization.

-

-      Before sending the username to the server, the client MUST prepare

-      the username using the "SASLPrep" profile [SASLPrep] of the

-      "stringprep" algorithm [RFC3454]. If the preparation of the

-      username fails or results in an empty string, the client SHOULD

-      abort the authentication exchange (*).

-

-      (*) An interactive client can request a repeated entry of the

-      username value.

-

-      Upon receipt of the username by the server, the server SHOULD

-      prepare it using the "SASLPrep" profile [SASLPrep] of the

-      "stringprep" algorithm [RFC3454]. If the preparation of the

-      username fails or results in an empty string, the server SHOULD

-      abort the authentication exchange.

-

-      The characters ',' or '=' in usernames are sent as '=2C' and '=3D'

-      respectively. If the server receives a username which contains '='

-      not followed by either '2C' or '3D', then the server MUST fail the

-      authentication.

-

-    - m: This attribute is reserved for future extensibility.  In this

-      version of SCRAM, its presence in a client or a server message

-      MUST cause authentication failure when the attribute is parsed by

-      the other end.

-

-    - r: This attribute specifies a sequence of random printable

-      characters excluding ',' which forms the nonce used as input to

-      the hash function.  No quoting is applied to this string (<<unless

-      the binding of SCRAM to a particular protocol states otherwise>>).

-      As described earlier, the client supplies an initial value in its

-      first message, and the server augments that value with its own

-      nonce in its first response. It is important that this be value

-      different for each authentication. The client MUST verify that the

-      initial part of the nonce used in subsequent messages is the same

-      as the nonce it initially specified. The server MUST verify that

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 8]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-      the nonce sent by the client in the second message is the same as

-      the one sent by the server in its first message.

-

-    - c: This optional attribute specifies base64-encoded channel-

-      binding data. It is sent by the client in the second step. If

-      specified by the client, if the server supports the specified

-      channel binding type and if the server can't verify it, then the

-      server MUST fail the authentication exchange.  Whether this

-      attribute is included, and the meaning and contents of the

-      channel-binding data depends on the external security layer in

-      use. This is necessary to detect a man-in-the-middle attack on the

-      security layer.

-

-    - s: This attribute specifies the base64-encoded salt used by the

-      server for this user. It is sent by the server in its first

-      message to the client.

-

-    - i: This attribute specifies an iteration count for the selected

-      hash function and user, and must be sent by the server along with

-      the user's salt.

-

-      For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a hash

-      iteration-count of at least 128.

-

-    - p: This attribute specifies a base64-encoded ClientProof. The

-      client computes this value as described in the overview and sends

-      it to the server.

-

-    - v: This attribute specifies a base64-encoded ServerSignature. It

-      is sent by the server in its final message, and may be used by the

-      client to verify that the server has access to the user's

-      authentication information. This value is computed as explained in

-      the overview.

-

-

-6. Formal Syntax

-

-    The following syntax specification uses the Augmented Backus-Naur

-    Form (ABNF) notation as specified in [RFC5234].  "UTF8-2", "UTF8-3"

-    and "UTF8-4" non-terminal are defined in [UTF-8].

-

-      generic-message = attr-val *("," attr-val)

-                        ;; Generic syntax of any server challenge

-                        ;; or client response

-

-      attr-val        = ALPHA "=" value

-

-      value           = 1*(value-char)

-

-

-

-Menon-Sen & Co             Expires August 2009                FF[Page 9]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-      value-safe-char = %01-2B / %2D-3C / %3E-7F /

-                        UTF8-2 / UTF-3 / UTF8-4

-                        ;; UTF8-char except NUL, "=", and ",".

-

-      value-char      = value-safe-char / "="

-

-      base64-char     = ALPHA / DIGIT / "/" / "+"

-

-      base64-4        = 4*4(base64-char)

-

-      base64-3        = 3*3(base64-char) "="

-

-      base64-2        = 2*2(base64-char) "=="

-

-      base64          = *(base64-4) [base64-3 / base64-2]

-

-      posit-number = (%x31-39) *DIGIT

-                        ;; A positive number

-

-      saslname        = 1*(value-safe-char / "=2C" / "=3D")

-                        ;; Conforms to <value>

-

-      authzid         = "a=" saslname

-                        ;; Protocol specific.

-

-      username        = "n=" saslname

-                        ;; Usernames are prepared using SASLPrep.

-

-      reserved-mext  = "m=" 1*(value-char)

-                        ;; Reserved for signalling mandatory extensions.

-                        ;; The exact syntax will be defined in

-                        ;; the future.

-

-      channel-binding = "c=" base64

-

-      proof           = "p=" base64

-

-      nonce           = "r=" c-nonce [s-nonce]

-                        ;; Second part provided by server.

-

-      c-nonce         = value

-

-      s-nonce         = value

-

-      salt            = "s=" base64

-

-      verifier        = "v=" base64

-                        ;; base-64 encoded ServerSignature.

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 10]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-      iteration-count = "i=" posit-number

-                        ;; A positive number

-

-      client-first-message =

-                        [reserved-mext ","] username "," nonce [","

-                        extensions]

-

-      server-first-message =

-                        [reserved-mext ","] nonce "," salt ","

-                        iteration-count ["," extensions]

-

-      client-final-message-without-proof =

-                        [authzid ","] [channel-binding ","] nonce [","

-                        extensions]

-

-      client-final-message =

-                        client-final-message-without-proof "," proof

-

-      server-final-message =

-                        verifier ["," extensions]

-

-      extensions = attr-val *("," attr-val)

-                        ;; All extensions are optional,

-                        ;; i.e. unrecognized attributes

-                        ;; not defined in this document

-                        ;; MUST be ignored.

-

-

-7. Security Considerations

-

-    If the authentication exchange is performed without a strong

-    security layer, then a passive eavesdropper can gain sufficient

-    information to mount an offline dictionary or brute-force attack

-    which can be used to recover the user's password. The amount of time

-    necessary for this attack depends on the cryptographic hash function

-    selected, the strength of the password and the iteration count

-    supplied by the server. An external security layer with strong

-    encryption will prevent this attack.

-

-    If the external security layer used to protect the SCRAM exchange

-    uses an anonymous key exchange, then the SCRAM channel binding

-    mechanism can be used to detect a man-in-the-middle attack on the

-    security layer and cause the authentication to fail as a result.

-    However, the man-in-the-middle attacker will have gained sufficient

-    information to mount an offline dictionary or brute-force attack.

-    For this reason, SCRAM includes the ability to increase the

-    iteration count over time.

-

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 11]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-    If the authentication information is stolen from the authentication

-    database, then an offline dictionary or brute-force attack can be

-    used to recover the user's password. The use of salt mitigates this

-    attack somewhat by requiring a separate attack on each password.

-    Authentication mechanisms which protect against this attack are

-    available (e.g., the EKE class of mechanisms), but the patent

-    situation is presently unclear.

-

-    If an attacker obtains the authentication information from the

-    authentication repository and either eavesdrops on one

-    authentication exchange or impersonates a server, the attacker gains

-    the ability to impersonate that user to all servers providing SCRAM

-    access using the same hash function, password, iteration count and

-    salt.  For this reason, it is important to use randomly-generated

-    salt values.

-

-    If the server detects (from the value of the client-specified "h"

-    attribute) that both endpoints support a stronger hash function that

-    the one the client actually chooses to use, then it SHOULD treat

-    this as a downgrade attack and reject the authentication attempt.

-

-    A hostile server can perform a computational denial-of-service

-    attack on clients by sending a big iteration count value.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 12]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-8. IANA considerations

-

-    IANA is requested to add the following entry to the SASL Mechanism

-    registry established by [RFC4422]:

-

-    To: iana@iana.org

-    Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1

-

-    SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1

-    Security considerations: Section 7 of [RFCXXXX]

-    Published specification (optional, recommended): [RFCXXXX]

-    Person & email address to contact for further information:

-     IETF SASL WG <ietf-sasl@imc.org>

-    Intended usage: COMMON

-    Owner/Change controller: IESG <iesg@ietf.org>

-    Note:

-

-    Note that even though this document defines a family of SCRAM-HMAC

-    mechanisms, it doesn't register a family of SCRAM-HMAC mechanisms in

-    the SASL Mechanisms registry. IANA is requested to prevent future

-    registrations of SASL mechanisms starting with SCRAM-HMAC- without

-    consulting the SASL mailing list <ietf-sasl@imc.org> first.

-

-    Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC

-    SASL mechanism MUST be explicitly registered with IANA and MUST

-    comply with SCRAM-HMAC mechanism naming convention defined in

-    Section 4 of this document.

-

-

-

-9. Acknowedgements

-

-    The authors would like to thank Dave Cridland for his contributions

-    to this document.

-

-

-10. Normative References

-

-    [RFC4648]  Josefsson, "The Base16, Base32, and Base64 Data

-               Encodings", RFC 4648, SJD, October 2006.

-

-    [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO

-               10646", STD 63, RFC 3629, November 2003.

-

-    [RFC2104]  Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for

-               Message Authentication", IBM, February 1997.

-

-    [RFC2119]  Bradner, "Key words for use in RFCs to Indicate

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 13]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-               Requirement Levels", RFC 2119, Harvard University, March

-               1997.

-

-    [RFC3174]  Eastlake, Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC

-               3174, Motorola, September 2001

-

-    [RFC5234]  Crocker, Overell, "Augmented BNF for Syntax

-               Specifications: ABNF", RFC 5234, January 2008.

-

-    [RFC4422]  Melnikov, Zeilenga, "Simple Authentication and Security

-               Layer (SASL)", RFC 4422, Isode Limited, June 2006.

-

-    [SASLPrep] Zeilenga, K., "SASLprep: Stringprep profile for user

-               names and passwords", RFC 4013, February 2005.

-

-    [RFC3454] Hoffman, P., Blanchet, M., "Preparation of

-               Internationalized Strings ("stringprep")", RFC 3454,

-               December 2002.

-

-

-

-11. Informative References

-

-    [RFC2195]  Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension

-               for Simple Challenge/Response", RFC 2195, MCI, September

-               1997.

-

-    [RFC2202]  Cheng, Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",

-               RFC 2202, IBM, September 1997

-

-    [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography

-               Specification Version 2.0", RFC 2898, September 2000.

-

-    [TLS]  Dierks, Rescorla, "The Transport Layer Security (TLS)

-               Protocol, Version 1.2", RFC 5246, August 2008.

-

-    [RFC4949]  Shirey, "Internet Security Glossary, Version 2", RFC

-               4949, FYI 0036, August 2007.

-

-    [RFC4086]  Eastlake, Schiller, Crocker, "Randomness Requirements for

-               Security", RFC 4086, BCP 0106, Motorola Laboratories,

-               June 2005.

-

-    [RFC4510]  Zeilenga, "Lightweight Directory Access Protocol (LDAP):

-               Technical Specification Road Map", RFC 4510, June 2006.

-

-    [DIGEST-MD5] Leach, P. and C. Newman , "Using Digest Authentication

-               as a SASL Mechanism", RFC 2831, May 2000.  <<Also draft-

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 14]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-               ietf-sasl-rfc2831bis-12.txt>>

-

-    [DIGEST-HISTORIC] Melnikov, "Moving DIGEST-MD5 to Historic", work in

-               progress, draft-ietf-sasl-digest-to-historic-00.txt, July

-               2008

-

-    [CRAM-HISTORIC] Zeilenga, "CRAM-MD5 to Historic", work in progress,

-               draft-ietf-sasl-crammd5-to-historic-00.txt, November

-               2008.

-

-    [PLAIN] Zeilenga, "The PLAIN Simple Authentication and Security

-               Layer (SASL) Mechanism" RFC 4616, August 2006.

-

-

-12. Authors' Addresses

-

-    Abhijit Menon-Sen

-    Oryx Mail Systems GmbH

-

-    Email: ams@oryx.com

-

-

-    Alexey Melnikov

-    Isode Ltd

-

-    EMail: Alexey.Melnikov@isode.com

-

-

-    Chris Newman

-    Sun Microsystems

-    1050 Lakes Drive

-    West Covina, CA 91790

-    USA

-

-    Email: chris.newman@sun.com

-

-

-Appendix A: Other Authentication Mechanisms

-

-    The DIGEST-MD5 [DIGEST-MD5] mechanism has proved to be too complex

-    to implement and test, and thus has poor interoperability. The

-    security layer is often not implemented, and almost never used;

-    everyone uses TLS instead.  For a more complete list of problems

-    with DIGEST-MD5 which lead to the creation of SCRAM see [DIGEST-

-    HISTORIC].

-

-    The CRAM-MD5 SASL mechanism, while widely deployed has also some

-    problems, in particular it is missing some modern SASL features such

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 15]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-    as support for internationalized usernames and passwords, support

-    for passing of authorization identity, support for channel bindings.

-    It also doesn't support server authentication.  For a more complete

-    list of problems with CRAM-MD5 see [CRAM-HISTORIC].

-

-    The PLAIN [PLAIN] SASL mechanism allows a malicious server or

-    eavesdropper to impersonate the authenticating user to any other

-    server for which the user has the same password. It also sends the

-    password in the clear over the network, unless TLS is used. Server

-    authentication is not supported.

-

-

-Appendix B: Design Motivations

-

-    The following design goals shaped this document. Note that some of

-    the goals have changed since the initial version of the document.

-

-      The SASL mechanism has all modern SASL features: support for

-      internationalized usernames and passwords, support for passing of

-      authorization identity, support for channel bindings.

-

-      Both the client and server can be authenticated by the protocol.

-

-      The authentication information stored in the authentication

-      database is not sufficient by itself to impersonate the client.

-

-      <<The server does not gain the ability to impersonate the client

-      to other servers (with an exception for server-authorized

-      proxies).>>

-

-      The mechanism is extensible, but [hopefully] not overengineered in

-      this respect.

-

-      Easier to implement than DIGEST-MD5 in both clients and servers.

-

-

-Appendix C: SCRAM Examples

-

-    <<To be written.>>

-

-

-

-

-

-

-

-

-

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 16]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-        (RFC Editor: Please delete everything after this point)

-

-

-Open Issues

-

-    - The appendices need to be written.

-

-    - Should the server send a base64-encoded ServerSignature for the

-      value of the "v" attribute, or should it compute a ServerProof the

-      way the client computes a ClientProof?

-

-

-Changes since -07

-

-    Updated References.

-

-    Clarified purpose of the m= attribute.

-

-    Fixed a problem with authentication/authorization identity's ABNF

-      not allowing for some characters.

-

-    Updated ABNF for nonce to show client-generated and server-generated

-      parts.

-

-    Only register SCRAM-HMAC-SHA-1 with IANA and require explicit

-      registrations of all other SCRAM-HMAC- mechanisms.

-

-

-

-Changes since -06

-

-    Removed hash negotiation from SCRAM and turned it into a family of

-      SASL mechanisms.

-

-    Start using "Hash Function Textual Names" IANA registry for SCRAM

-      mechanism naming.

-

-    Fixed definition of Hi(str, salt) to be consistent with [RFC2898].

-

-    Clarified extensibility of SCRAM: added m= attribute (for future

-      mandatory extensions) and specified that all unrecognized

-      attributes must be ignored.

-

-

-

-Changes since -05

-

-    Changed the mandatory to implement hash algorithm to SHA-1 (as per

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 17]

-

-

-

-

-

-Internet-draft                                             February 2009

-

-

-      WG consensus).

-

-    Added text about use of SASLPrep for username

-      canonicalization/validation.

-

-    Clarified that authorization identity is canonicalized/verified

-      according to SASL protocol profile.

-

-    Clarified that iteration count is per-user.

-

-    Clarified how clients select the authentication function.

-

-    Added IANA registration for the new mechanism.

-

-    Added missing normative references (UTF-8, SASLPrep).

-

-    Various editorial changes based on comments from Hallvard B

-      Furuseth, Nico William and Simon Josefsson.

-

-

-

-Changes since -04

-

-    - Update Base64 and Security Glossary references.

-

-    - Add Formal Syntax section.

-

-    - Don't bother with "v=".

-

-    - Make MD5 mandatory to implement. Suggest i=128.

-

-

-

-Changes since -03

-

-    - Seven years have passed, in which it became clear that DIGEST-MD5

-      suffered from unacceptably bad interoperability, so SCRAM-MD5 is

-      now back from the dead.

-

-    - Be hash agnostic, so MD5 can be replaced more easily.

-

-    - General simplification.

-

-

-

-

-

-

-

-

-

-Menon-Sen & Co             Expires August 2009               FF[Page 18]

-

-

diff --git a/doc/standardisation/draft-newman-auth-scram-11.txt b/doc/standardisation/draft-newman-auth-scram-11.txt
deleted file mode 100644
index 4b6abfb02..000000000
--- a/doc/standardisation/draft-newman-auth-scram-11.txt
+++ /dev/null
@@ -1,1904 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                       A. Menon-Sen
-Internet-Draft                                    Oryx Mail Systems GmbH
-Intended status: Standards Track                             A. Melnikov
-Expires: September 24, 2009                                    Isode Ltd
-                                                               C. Newman
-                                                             N. Williams
-                                                        Sun Microsystems
-                                                          March 23, 2009
-
-
-            Salted Challenge Response (SCRAM) SASL Mechanism
-                     draft-newman-auth-scram-11.txt
-
-Status of this Memo
-
-   This Internet-Draft is submitted to IETF in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 24, 2009.
-
-Copyright Notice
-
-   Copyright (c) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009               [Page 1]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-Abstract
-
-   The secure authentication mechanism most widely deployed and used by
-   Internet application protocols is the transmission of clear-text
-   passwords over a channel protected by Transport Layer Security (TLS).
-   There are some significant security concerns with that mechanism,
-   which could be addressed by the use of a challenge response
-   authentication mechanism protected by TLS.  Unfortunately, the
-   challenge response mechanisms presently on the standards track all
-   fail to meet requirements necessary for widespread deployment, and
-   have had success only in limited use.
-
-   This specification describes a family of authentication mechanisms
-   called the Salted Challenge Response Authentication Mechanism
-   (SCRAM), which addresses the security concerns and meets the
-   deployability requirements.  When used in combination with TLS or an
-   equivalent security layer, a mechanism from this family could improve
-   the status-quo for application protocol authentication and provide a
-   suitable choice for a mandatory-to-implement mechanism for future
-   application protocol standards.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009               [Page 2]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-Table of Contents
-
-   1.          Conventions Used in This Document  . . . . . . . . . .  4
-   1.1.        Terminology  . . . . . . . . . . . . . . . . . . . . .  4
-   1.2.        Notation . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.          Introduction . . . . . . . . . . . . . . . . . . . . .  7
-   3.          SCRAM Algorithm Overview . . . . . . . . . . . . . . .  9
-   4.          SCRAM Mechanism Names  . . . . . . . . . . . . . . . . 10
-   5.          SCRAM Authentication Exchange  . . . . . . . . . . . . 11
-   5.1.        SCRAM Attributes . . . . . . . . . . . . . . . . . . . 12
-   6.          Channel Binding  . . . . . . . . . . . . . . . . . . . 15
-   6.1.        Channel Binding to TLS Channels  . . . . . . . . . . . 16
-   7.          Formal Syntax  . . . . . . . . . . . . . . . . . . . . 17
-   8.          SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 20
-   8.1.        GSS-API Principal Name Types for SCRAM . . . . . . . . 20
-   8.2.        GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 20
-   8.3.        GSS_Pseudo_random() for SCRAM  . . . . . . . . . . . . 21
-   9.          Security Considerations  . . . . . . . . . . . . . . . 22
-   10.         IANA Considerations  . . . . . . . . . . . . . . . . . 24
-   11.         Acknowledgements . . . . . . . . . . . . . . . . . . . 25
-   Appendix A. Other Authentication Mechanisms  . . . . . . . . . . . 26
-   Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 27
-   Appendix C. SCRAM Examples and Internet-Draft Change History . . . 28
-   12.         References . . . . . . . . . . . . . . . . . . . . . . 31
-   12.1.       Normative References . . . . . . . . . . . . . . . . . 31
-   12.2.       Normative References for GSS-API implementors  . . . . 31
-   12.3.       Informative References . . . . . . . . . . . . . . . . 32
-               Authors' Addresses . . . . . . . . . . . . . . . . . . 34
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009               [Page 3]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-1.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   Formal syntax is defined by [RFC5234] including the core rules
-   defined in Appendix B of [RFC5234].
-
-   Example lines prefaced by "C:" are sent by the client and ones
-   prefaced by "S:" by the server.  If a single "C:" or "S:" label
-   applies to multiple lines, then the line breaks between those lines
-   are for editorial clarity only, and are not part of the actual
-   protocol exchange.
-
-1.1.  Terminology
-
-   This document uses several terms defined in [RFC4949] ("Internet
-   Security Glossary") including the following: authentication,
-   authentication exchange, authentication information, brute force,
-   challenge-response, cryptographic hash function, dictionary attack,
-   eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,
-   one-way encryption function, password, replay attack and salt.
-   Readers not familiar with these terms should use that glossary as a
-   reference.
-
-   Some clarifications and additional definitions follow:
-
-   o  Authentication information: Information used to verify an identity
-      claimed by a SCRAM client.  The authentication information for a
-      SCRAM identity consists of salt, iteration count, the "StoredKey"
-      and "ServerKey" (as defined in the algorithm overview) for each
-      supported cryptographic hash function.
-
-   o  Authentication database: The database used to look up the
-      authentication information associated with a particular identity.
-      For application protocols, LDAPv3 (see [RFC4510]) is frequently
-      used as the authentication database.  For network-level protocols
-      such as PPP or 802.11x, the use of RADIUS is more common.
-
-   o  Base64: An encoding mechanism defined in [RFC4648] which converts
-      an octet string input to a textual output string which can be
-      easily displayed to a human.  The use of base64 in SCRAM is
-      restricted to the canonical form with no whitespace.
-
-   o  Octet: An 8-bit byte.
-
-   o  Octet string: A sequence of 8-bit bytes.
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009               [Page 4]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-   o  Salt: A random octet string that is combined with a password
-      before applying a one-way encryption function.  This value is used
-      to protect passwords that are stored in an authentication
-      database.
-
-1.2.  Notation
-
-   The pseudocode description of the algorithm uses the following
-   notations:
-
-   o  ":=": The variable on the left hand side represents the octet
-      string resulting from the expression on the right hand side.
-
-   o  "+": Octet string concatenation.
-
-   o  "[ ]": A portion of an expression enclosed in "[" and "]" may not
-      be included in the result under some circumstances.  See the
-      associated text for a description of those circumstances.
-
-   o  HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in
-      [RFC2104]) using the octet string represented by "key" as the key
-      and the octet string "str" as the input string.  The size of the
-      result is the hash result size for the hash function in use.  For
-      example, it is 20 octets for SHA-1 (see [RFC3174]).
-
-   o  H(str): Apply the cryptographic hash function to the octet string
-      "str", producing an octet string as a result.  The size of the
-      result depends on the hash result size for the hash function in
-      use.
-
-   o  XOR: Apply the exclusive-or operation to combine the octet string
-      on the left of this operator with the octet string on the right of
-      this operator.  The length of the output and each of the two
-      inputs will be the same for this use.
-
-   o  Hi(str, salt):
-
-
-
-      U0   := HMAC(str, salt + INT(1))
-      U1   := HMAC(str, U0)
-      U2   := HMAC(str, U1)
-      ...
-      Ui-1 := HMAC(str, Ui-2)
-      Ui   := HMAC(str, Ui-1)
-
-      Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009               [Page 5]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-      where "i" is the iteration count, "+" is the string concatenation
-      operator and INT(g) is a four-octet encoding of the integer g,
-      most significant octet first.
-
-   o  This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and
-      with dkLen == output length of HMAC() == output length of H().
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009               [Page 6]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-2.  Introduction
-
-   This specification describes a family of authentication mechanisms
-   called the Salted Challenge Response Authentication Mechanism (SCRAM)
-   which addresses the requirements necessary to deploy a challenge-
-   response mechanism more widely than past attempts.  When used in
-   combination with Transport Layer Security (TLS, see [RFC5246]) or an
-   equivalent security layer, a mechanism from this family could improve
-   the status-quo for application protocol authentication and provide a
-   suitable choice for a mandatory-to-implement mechanism for future
-   application protocol standards.
-
-   For simplicity, this family of mechanism does not presently include
-   negotiation of a security layer.  It is intended to be used with an
-   external security layer such as that provided by TLS or SSH, with
-   optional channel binding [RFC5056] to the external security layer.
-
-   SCRAM is specified herein as a pure Simple Authentication and
-   Security Layer (SASL) [RFC4422] mechanism, but it conforms to the new
-   bridge between SASL and the Generic Security Services Application
-   Programming Interface (GSS-API) called "GS2" [ref-needed].  This
-   means that SCRAM is actually both, a GSS-API and SASL mechanism.
-
-   SCRAM provides the following protocol features:
-
-   o  The authentication information stored in the authentication
-      database is not sufficient by itself to impersonate the client.
-      The information is salted to prevent a pre-stored dictionary
-      attack if the database is stolen.
-
-   o  The server does not gain the ability to impersonate the client to
-      other servers (with an exception for server-authorized proxies).
-
-   o  The mechanism permits the use of a server-authorized proxy without
-      requiring that proxy to have super-user rights with the back-end
-      server.
-
-   o  A standard attribute is defined to enable storage of the
-      authentication information in LDAPv3 (see [RFC4510]).
-
-   o  Mutual authentication is supported, but only the client is named
-      (i.e., the server has no name).
-
-   For an in-depth discussion of why other challenge response mechanisms
-   are not considered sufficient, see appendix A.  For more information
-   about the motivations behind the design of this mechanism, see
-   appendix B.
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009               [Page 7]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-   Comments regarding this draft may be sent either to the
-   ietf-sasl@imc.org mailing list or to the authors.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009               [Page 8]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-3.  SCRAM Algorithm Overview
-
-   Note that this section omits some details, such as client and server
-   nonces.  See Section 5 for more details.
-
-   To begin with, the client is in possession of a username and
-   password.  It sends the username to the server, which retrieves the
-   corresponding authentication information, i.e. a salt, StoredKey,
-   ServerKey and the iteration count i.  (Note that a server
-   implementation may chose to use the same iteration count for all
-   account.)  The server sends the salt and the iteration count to the
-   client, which then computes the following values and sends a
-   ClientProof to the server:
-
-
-      SaltedPassword  := Hi(password, salt)
-      ClientKey       := H(SaltedPassword)
-      StoredKey       := H(ClientKey)
-      AuthMessage     := client-first-message + "," +
-                         server-first-message + "," +
-                         client-final-message-without-proof
-      ClientSignature := HMAC(StoredKey, AuthMessage)
-      ClientProof     := ClientKey XOR ClientSignature
-      ServerKey       := HMAC(SaltedPassword, salt)
-      ServerSignature := HMAC(ServerKey, AuthMessage)
-
-
-   The server authenticates the client by computing the ClientSignature,
-   exclusive-ORing that with the ClientProof to recover the ClientKey
-   and verifying the correctness of the ClientKey by applying the hash
-   function and comparing the result to the StoredKey.  If the ClientKey
-   is correct, this proves that the client has access to the user's
-   password.
-
-   Similarly, the client authenticates the server by computing the
-   ServerSignature and comparing it to the value sent by the server.  If
-   the two are equal, it proves that the server had access to the user's
-   ServerKey.
-
-   The AuthMessage is computed by concatenating messages from the
-   authentication exchange.  The format of these messages is defined in
-   Section 7.
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009               [Page 9]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-4.  SCRAM Mechanism Names
-
-   A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the
-   uppercased name of the underlying hashed function taken from the IANA
-   "Hash Function Textual Names" registry (see http://www.iana.org),
-   optionally followed by the suffix "-PLUS" (see below)..
-
-   For interoperability, all SCRAM clients and servers MUST implement
-   the SCRAM-HMAC-SHA-1 authentication mechanism, i.e. an authentication
-   mechanism from the SCRAM family that uses the SHA-1 hash function as
-   defined in [RFC3174].
-
-   The "-PLUS" suffix is used only when the server supports channel
-   binding to the external channel.  In this case the server will
-   advertise both, SCRAM-HMAC-SHA-1 and SCRAM-HMAC-SHA-1-PLUS, otherwise
-   the server will advertise only SCRAM-HMAC-SHA-1.  The "-PLUS" exists
-   to allow negotiation of the use of channel binding.  See Section 6.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 10]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-5.  SCRAM Authentication Exchange
-
-   SCRAM is a text protocol where the client and server exchange
-   messages containing one or more attribute-value pairs separated by
-   commas.  Each attribute has a one-letter name.  The messages and
-   their attributes are described in Section 5.1, and defined in
-   Section 7.
-
-   This is a simple example of a SCRAM-HMAC-SHA-1 authentication
-   exchange:
-
-
-      C: n,n=Chris Newman,r=ClientNonce
-      S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
-      C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
-      S: v=WxPv/siO5l+qxN4
-
-
-   With channel-binding data sent by the client this might look like
-   this:
-
-
-      C: p,n=Chris Newman,r=ClientNonce
-      S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
-      C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
-      S: v=WxPv/siO5l+qxN4
-
-
-   <<Note that the channel-bind data above, as well as all hashes are
-   fake>>
-
-   First, the client sends a message containing:
-
-   o  a GS2 header consisting of a flag indicating whether channel
-      binding is supported-but-not-used, not supported, or used, and the
-      SASL authzid (optional);
-
-   o  SCRAM username and client nonce attributes.
-
-   Note that the client's first message will always start with "n", "y"
-   or "p", otherwise the message is invalid and authentication MUST
-   fail.  This is important, as it allows for GS2 extensibility (e.g.,
-   to add support for security layers).
-
-   In response, the server sends the user's iteration count i, the
-   user's salt, and appends its own nonce to the client-specified one.
-   The client then responds with the same nonce and a ClientProof
-   computed using the selected hash function as explained earlier.  In
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 11]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-   this step the client can also include an optional authorization
-   identity.  The server verifies the nonce and the proof, verifies that
-   the authorization identity (if supplied by the client in the second
-   message) is authorized to act as the authentication identity, and,
-   finally, it responds with a ServerSignature, concluding the
-   authentication exchange.  The client then authenticates the server by
-   computing the ServerSignature and comparing it to the value sent by
-   the server.  If the two are different, the client MUST consider the
-   authentication exchange to be unsuccessful and it might have to drop
-   the connection.
-
-5.1.  SCRAM Attributes
-
-   This section describes the permissible attributes, their use, and the
-   format of their values.  All attribute names are single US-ASCII
-   letters and are case-sensitive.
-
-   o  a: This is an optional attribute, and is part of the GS2 [ref-
-      needed] bridge between the GSS-API and SASL.  This attribute
-      specifies an authorization identity.  A client may include it in
-      its second message to the server if it wants to authenticate as
-      one user, but subsequently act as a different user.  This is
-      typically used by an administrator to perform some management task
-      on behalf of another user, or by a proxy in some situations.
-
-         Upon the receipt of this value the server verifies its
-         correctness according to the used SASL protocol profile.
-         Failed verification results in failed authentication exchange.
-
-         If this attribute is omitted (as it normally would be), or
-         specified with an empty value, the authorization identity is
-         assumed to be derived from the username specified with the
-         (required) "n" attribute.
-
-         The server always authenticates the user specified by the "n"
-         attribute.  If the "a" attribute specifies a different user,
-         the server associates that identity with the connection after
-         successful authentication and authorization checks.
-
-         The syntax of this field is the same as that of the "n" field
-         with respect to quoting of '=' and ','.
-
-   o  n: This attribute specifies the name of the user whose password is
-      used for authentication.  A client must include it in its first
-      message to the server.  If the "a" attribute is not specified
-      (which would normally be the case), this username is also the
-      identity which will be associated with the connection subsequent
-      to authentication and authorization.
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 12]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-         Before sending the username to the server, the client MUST
-         prepare the username using the "SASLPrep" profile [RFC4013] of
-         the "stringprep" algorithm [RFC3454].  If the preparation of
-         the username fails or results in an empty string, the client
-         SHOULD abort the authentication exchange (*).
-
-         (*) An interactive client can request a repeated entry of the
-         username value.
-
-         Upon receipt of the username by the server, the server SHOULD
-         prepare it using the "SASLPrep" profile [RFC4013] of the
-         "stringprep" algorithm [RFC3454].  If the preparation of the
-         username fails or results in an empty string, the server SHOULD
-         abort the authentication exchange.
-
-         The characters ',' or '=' in usernames are sent as '=2C' and
-         '=3D' respectively.  If the server receives a username which
-         contains '=' not followed by either '2C' or '3D', then the
-         server MUST fail the authentication.
-
-   o  m: This attribute is reserved for future extensibility.  In this
-      version of SCRAM, its presence in a client or a server message
-      MUST cause authentication failure when the attribute is parsed by
-      the other end.
-
-   o  r: This attribute specifies a sequence of random printable
-      characters excluding ',' which forms the nonce used as input to
-      the hash function.  No quoting is applied to this string (<<unless
-      the binding of SCRAM to a particular protocol states otherwise>>).
-      As described earlier, the client supplies an initial value in its
-      first message, and the server augments that value with its own
-      nonce in its first response.  It is important that this be value
-      different for each authentication.  The client MUST verify that
-      the initial part of the nonce used in subsequent messages is the
-      same as the nonce it initially specified.  The server MUST verify
-      that the nonce sent by the client in the second message is the
-      same as the one sent by the server in its first message.
-
-   o  c: This REQUIRED attribute specifies base64-encoded of a header
-      and the channel-binding data.  It is sent by the client in its
-      second authentication message.  The header consist of:
-
-      *  the GS2 header from the client's first message (recall: a
-         channel binding flag and an optional authzid);
-
-      *  followed by the external channel's channel binding type prefix
-         (see [RFC5056], if and only if the client is using channel
-         binding;
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 13]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-      *  followed by the external channel's channel binding data, if and
-         only if the client is using channel binding.
-
-   o  s: This attribute specifies the base64-encoded salt used by the
-      server for this user.  It is sent by the server in its first
-      message to the client.
-
-   o  i: This attribute specifies an iteration count for the selected
-      hash function and user, and must be sent by the server along with
-      the user's salt.
-
-         For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a
-         hash iteration-count of at least 128.
-
-   o  p: This attribute specifies a base64-encoded ClientProof.  The
-      client computes this value as described in the overview and sends
-      it to the server.
-
-   o  v: This attribute specifies a base64-encoded ServerSignature.  It
-      is sent by the server in its final message, and is used by the
-      client to verify that the server has access to the user's
-      authentication information.  This value is computed as explained
-      in the overview.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 14]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-6.  Channel Binding
-
-   SCRAM supports channel binding to external secure channels, such as
-   TLS.  Clients and servers may or may not support channel binding,
-   therefore the use of channel binding is negotiable.  SCRAM does not
-   provide security layers, however, therefore it is imperative that
-   SCRAM provide integrity protection for the negotiation of channel
-   binding.
-
-   Use of channel binding is negotiated as follows:
-
-   o  The server advertises support for channel binding by advertising
-      both, SCRAM-HMAC-<hash-function> and SCRAM-HMAC-<hash-function>-
-      PLUS.
-
-   o  If the client negotiates mechanisms then client MUST select SCRAM-
-      HMAC-<hash-function>-PLUS if offered by the server.  Otherwise, if
-      the client does not negotiate mechanisms then it MUST select only
-      SCRAM-HMAC-<hash-function> (not suffixed with "-PLUS").
-
-   o  If the client and server both support channel binding, or if the
-      client wishes to use channel binding but the client does not
-      negotiate mechanisms, the client MUST set the GS2 channel binding
-      flag to "p" and MUST include channel binding data for the external
-      channel in the computation of the "c=" attribute (see
-      Section 5.1).
-
-   o  If the client supports channel binding but the server does not
-      then the client MUST set the GS2 channel binding flag to "y" and
-      MUST NOT include channel binding data for the external channel in
-      the computation of the "c=" attribute (see Section 5.1).
-
-   o  If the client does not support channel binding then the client
-      MUST set the GS2 channel binding flag to "n" and MUST NOT include
-      channel binding data for the external channel in the computation
-      of the "c=" attribute (see Section 5.1).
-
-   o  If the server receives a client first message with the GS2 channel
-      binding flag set to "y" and the server supports channel binding
-      the server MUST fail authentication.  This is because if the
-      client sets the GS2 channel binding flag set to "y" then the
-      client must have believed that the server did not support channel
-      binding -- if the server did in fact support channel binding then
-      this is an indication that there has been a downgrade attack
-      (e.g., an attacker changed the server's mechanism list to exclude
-      the -PLUS suffixed SCRAM mechanism name(s)).
-
-   The server MUST always validate the client's "c=" field.  The server
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 15]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-   does this by constructing the value of the "c=" attribute and then
-   checking that it matches the client's c= attribute value.
-
-6.1.  Channel Binding to TLS Channels
-
-   If an external TLS channel is to be bound into the SCRAM
-   authentication, and if the channel was established using a server
-   certificate to authenticate the server, then the SCRAM client and
-   server MUST use the 'tls-server-end-point' channel binding type.  See
-   the IANA Channel Binding Types registry.
-
-   If an external TLS channel is to be bound into the SCRAM
-   authentication, and if the channel was established without the use of
-   any server certificate to authenticate the server, then the SCRAM
-   client and server MUST use the 'tls-unique' channel binding type.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 16]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-7.  Formal Syntax
-
-   The following syntax specification uses the Augmented Backus-Naur
-   Form (ABNF) notation as specified in [RFC5234].  "UTF8-2", "UTF8-3"
-   and "UTF8-4" non-terminal are defined in [RFC3629].
-
-
-     ALPHA = <as defined in RFC 5234 appendix B.1>
-     DIGIT = <as defined in RFC 5234 appendix B.1>
-     UTF8-2 = <as defined in RFC 3629 (STD 63)>
-     UTF8-3 = <as defined in RFC 3629 (STD 63)>
-     UTF8-4 = <as defined in RFC 3629 (STD 63)>
-
-     generic-message = attr-val *("," attr-val)
-                       ;; Generic syntax of any server challenge
-                       ;; or client response
-
-     attr-val        = ALPHA "=" value
-
-     value           = *value-char
-
-     value-safe-char = %x01-2B / %x2D-3C / %x3E-7F /
-                       UTF8-2 / UTF8-3 / UTF8-4
-                       ;; UTF8-char except NUL, "=", and ",".
-
-     value-char      = value-safe-char / "="
-
-     base64-char     = ALPHA / DIGIT / "/" / "+"
-
-     base64-4        = 4base64-char
-
-     base64-3        = 3base64-char "="
-
-     base64-2        = 2base64-char "=="
-
-     base64          = *base64-4 [base64-3 / base64-2]
-
-     posit-number = %x31-39 *DIGIT
-                       ;; A positive number
-
-     saslname        = 1*(value-safe-char / "=2C" / "=3D")
-                       ;; Conforms to <value>
-
-     authzid         = "a=" saslname
-                       ;; Protocol specific.
-
-     gs2-cbind-flag  = "n" / "y" / "p"
-                       ;; "n" -> client doesn't support channel binding
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 17]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-                       ;; "y" -> client does support channel binding
-                       ;;        but thinks the server does not.
-                       ;; "p" -> client requires channel binding
-     gs2-header      = gs2-cbind-flag [ authzid ] ","
-                       ;; GS2 header for SCRAM
-                       ;; (the actual GS2 header includes an optional
-                       ;; flag to indicate that the GSS mechanism is not
-                       ;; "standard" but since SCRAM is "standard" we
-                       ;; don't include that flag).
-
-     username        = "n=" saslname
-                       ;; Usernames are prepared using SASLPrep.
-
-     reserved-mext  = "m=" 1*(value-char)
-                       ;; Reserved for signalling mandatory extensions.
-                       ;; The exact syntax will be defined in
-                       ;; the future.
-
-     ;;cbind-type    = value
-     ;;cbind-input   = gs2-header [ value ":" cbind-data ]
-     channel-binding = "c=" base64
-                       ;; base64 encoding of cbind-input
-
-     proof           = "p=" base64
-
-     nonce           = "r=" c-nonce [s-nonce]
-                       ;; Second part provided by server.
-
-     c-nonce         = value
-
-     s-nonce         = value
-
-     salt            = "s=" base64
-
-     verifier        = "v=" base64
-                       ;; base-64 encoded ServerSignature.
-
-     iteration-count = "i=" posit-number
-                       ;; A positive number
-
-     client-first-message =
-                       gs2-header [reserved-mext ","]
-                       username "," nonce ["," extensions]
-
-     server-first-message =
-                       [reserved-mext ","] nonce "," salt ","
-                       iteration-count ["," extensions]
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 18]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-     client-final-message-without-proof =
-                       [channel-binding ","] nonce [","
-                       extensions]
-
-     client-final-message =
-                       client-final-message-without-proof "," proof
-
-     gss-server-error = "e=" value
-     server-final-message = gss-server-error /
-                       verifier ["," extensions]
-                       ;; The error message is only for the GSS-API
-                       ;; form of SCRAM, and it is OPTIONAL to
-                       ;; implement it.
-
-     extensions = attr-val *("," attr-val)
-                       ;; All extensions are optional,
-                       ;; i.e. unrecognized attributes
-                       ;; not defined in this document
-                       ;; MUST be ignored.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 19]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-8.  SCRAM as a GSS-API Mechanism
-
-   This section and its sub-sections and all normative references of it
-   not referenced elsewhere in this document are INFORMATIONAL for SASL
-   implementors, but they are NORMATIVE for GSS-API implementors.
-
-   SCRAM is actually also GSS-API mechanism.  The messages are the same,
-   but a) the GS2 header on the client's first message and channel
-   binding data is excluded when SCRAM is used as a GSS-API mechanism,
-   and b) the RFC2743 section 3.1 initial context token header is
-   prefixed to the client's first authentication message (context
-   token).
-
-   The GSS-API mechanism OID for SCRAM is <TBD> (see Section 10).
-
-8.1.  GSS-API Principal Name Types for SCRAM
-
-   SCRAM does not name acceptors.  Therefore only GSS_C_NO_NAME and
-   names of type GSS_C_NT_ANONYMOUS shall be allowed as the target name
-   input of GSS_Init_sec_context() when using a SCRAM mechanism.
-
-   SCRAM supports only a single name type for initiators:
-   GSS_C_NT_USER_NAME.  GSS_C_NT_USER_NAME is the default name type for
-   SCRAM.
-
-   There is no name canonicalization procedure for SCRAM beyond applying
-   SASLprep as described in Section 5.1.
-
-   The query, display and exported name syntax for SCRAM principal names
-   is the same: there is no syntax -- SCRAM principal names are free-
-   form.  (The exported name token does, of course, conform to [RFC2743]
-   section 3.2, but the "NAME" part of the token is just a SCRAM user
-   name.)
-
-8.2.  GSS-API Per-Message Tokens for SCRAM
-
-   The per-message tokens for SCRAM as a GSS-API mechanism SHALL BE the
-   same as those for the Kerberos V GSS-API mechanism [RFC4121], using
-   the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962].
-
-   The 128-bit session key SHALL be derived by using the least
-   significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API session
-   key" || ClientKey || AuthMessage).
-
-   SCRAM does support PROT_READY, and is PROT_READY on the initiator
-   side first upon receipt of the server's reply to the initial security
-   context token.
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 20]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-8.3.  GSS_Pseudo_random() for SCRAM
-
-   The GSS_Pseudo_random() [RFC4401] for SCRAM SHALL be the same as for
-   the Kerberos V GSS-API mechanism [RFC4402].  There is no acceptor-
-   asserted sub-session key for SCRAM, thus GSS_C_PRF_KEY_FULL and
-   GSS_C_PRF_KEY_PARTIAL are equivalent for SCRAM's GSS_Pseudo_random().
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 21]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-9.  Security Considerations
-
-   If the authentication exchange is performed without a strong security
-   layer, then a passive eavesdropper can gain sufficient information to
-   mount an offline dictionary or brute-force attack which can be used
-   to recover the user's password.  The amount of time necessary for
-   this attack depends on the cryptographic hash function selected, the
-   strength of the password and the iteration count supplied by the
-   server.  An external security layer with strong encryption will
-   prevent this attack.
-
-   If the external security layer used to protect the SCRAM exchange
-   uses an anonymous key exchange, then the SCRAM channel binding
-   mechanism can be used to detect a man-in-the-middle attack on the
-   security layer and cause the authentication to fail as a result.
-   However, the man-in-the-middle attacker will have gained sufficient
-   information to mount an offline dictionary or brute-force attack.
-   For this reason, SCRAM includes the ability to increase the iteration
-   count over time.
-
-   If the authentication information is stolen from the authentication
-   database, then an offline dictionary or brute-force attack can be
-   used to recover the user's password.  The use of salt mitigates this
-   attack somewhat by requiring a separate attack on each password.
-   Authentication mechanisms which protect against this attack are
-   available (e.g., the EKE class of mechanisms), but the patent
-   situation is presently unclear.
-
-   If an attacker obtains the authentication information from the
-   authentication repository and either eavesdrops on one authentication
-   exchange or impersonates a server, the attacker gains the ability to
-   impersonate that user to all servers providing SCRAM access using the
-   same hash function, password, iteration count and salt.  For this
-   reason, it is important to use randomly-generated salt values.
-
-   SCRAM does not negotiate a hash function to use.  Hash function
-   negotiation is left to the SASL mechanism negotiation.  It is
-   important that clients be able to sort a locally available list of
-   mechanisms by preference so that the client may pick the most
-   preferred of a server's advertised mechanism list.  This preference
-   order is not specified here as it is a local matter.  The preference
-   order should include objective and subjective notions of mechanism
-   cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be
-   preferred over SCRAM with SHA-1).
-
-   Note that to protect the SASL mechanism negotiation applications
-   normally must list the server mechs twice: once before and once after
-   authentication, the latter using security layers.  Since SCRAM does
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 22]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-   not provide security layers the only ways to protect the mechanism
-   negotiation are: a) use channel binding to an external channel, or b)
-   use an external channel that authenticates a user-provided server
-   name.
-
-   A hostile server can perform a computational denial-of-service attack
-   on clients by sending a big iteration count value.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 23]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-10.  IANA Considerations
-
-   IANA is requested to add the following entries to the SASL Mechanism
-   registry established by [RFC4422]:
-
-
-   To: iana@iana.org
-   Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1
-
-   SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1
-   Security considerations: Section 7 of [RFCXXXX]
-   Published specification (optional, recommended): [RFCXXXX]
-   Person & email address to contact for further information:
-    IETF SASL WG <ietf-sasl@imc.org>
-   Intended usage: COMMON
-   Owner/Change controller: IESG <iesg@ietf.org>
-   Note:
-
-   To: iana@iana.org
-   Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1-PLUS
-
-   SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1-PLUS
-   Security considerations: Section 7 of [RFCXXXX]
-   Published specification (optional, recommended): [RFCXXXX]
-   Person & email address to contact for further information:
-    IETF SASL WG <ietf-sasl@imc.org>
-   Intended usage: COMMON
-   Owner/Change controller: IESG <iesg@ietf.org>
-   Note:
-
-
-   Note that even though this document defines a family of SCRAM-HMAC
-   mechanisms, it doesn't register a family of SCRAM-HMAC mechanisms in
-   the SASL Mechanisms registry.  IANA is requested to prevent future
-   registrations of SASL mechanisms starting with SCRAM-HMAC- without
-   consulting the SASL mailing list <ietf-sasl@imc.org> first.
-
-   Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC
-   SASL mechanism MUST be explicitly registered with IANA and MUST
-   comply with SCRAM-HMAC mechanism naming convention defined in
-   Section 4 of this document.
-
-   We hereby request that IANA assign a GSS-API mechanism OID for SCRAM.
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 24]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-11.  Acknowledgements
-
-   The authors would like to thank Dave Cridland for his contributions
-   to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 25]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-Appendix A.  Other Authentication Mechanisms
-
-   The DIGEST-MD5 [I-D.ietf-sasl-digest-to-historic] mechanism has
-   proved to be too complex to implement and test, and thus has poor
-   interoperability.  The security layer is often not implemented, and
-   almost never used; everyone uses TLS instead.  For a more complete
-   list of problems with DIGEST-MD5 which lead to the creation of SCRAM
-   see [I-D.ietf-sasl-digest-to-historic].
-
-   The CRAM-MD5 SASL mechanism, while widely deployed has also some
-   problems, in particular it is missing some modern SASL features such
-   as support for internationalized usernames and passwords, support for
-   passing of authorization identity, support for channel bindings.  It
-   also doesn't support server authentication.  For a more complete list
-   of problems with CRAM-MD5 see [I-D.ietf-sasl-crammd5-to-historic].
-
-   The PLAIN [RFC4616] SASL mechanism allows a malicious server or
-   eavesdropper to impersonate the authenticating user to any other
-   server for which the user has the same password.  It also sends the
-   password in the clear over the network, unless TLS is used.  Server
-   authentication is not supported.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 26]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-Appendix B.  Design Motivations
-
-   The DIGEST-MD5 [I-D.ietf-sasl-digest-to-historic] mechanism has
-   proved to be too complex to implement and test, and thus has poor
-   interoperability.  The security layer is often not implemented, and
-   almost never used; everyone uses TLS instead.  For a more complete
-   list of problems with DIGEST-MD5 which lead to the creation of SCRAM
-   see [I-D.ietf-sasl-digest-to-historic].
-
-   The CRAM-MD5 SASL mechanism, while widely deployed has also some
-   problems, in particular it is missing some modern SASL features such
-   as support for internationalized usernames and passwords, support for
-   passing of authorization identity, support for channel bindings.  It
-   also doesn't support server authentication.  For a more complete list
-   of problems with CRAM-MD5 see [I-D.ietf-sasl-crammd5-to-historic].
-
-   The PLAIN [RFC4616] SASL mechanism allows a malicious server or
-   eavesdropper to impersonate the authenticating user to any other
-   server for which the user has the same password.  It also sends the
-   password in the clear over the network, unless TLS is used.  Server
-   authentication is not supported.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 27]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-Appendix C.  SCRAM Examples and Internet-Draft Change History
-
-   <<To be written.>>
-
-   (RFC Editor: Please delete everything after this point)
-
-   Open Issues
-
-   o  The appendices need to be written.
-
-   o  Should the server send a base64-encoded ServerSignature for the
-      value of the "v" attribute, or should it compute a ServerProof the
-      way the client computes a ClientProof?
-
-   Changes since -10
-
-   o  Converted the source for this I-D to XML.
-
-   o  Added text to make SCRAM compliant with the new GS2 design.
-
-   o  Added text on channel binding negotiation.
-
-   o  Added text on channel binding, including a reference to RFC5056.
-
-   o  Added text on SCRAM as a GSS-API mechanism.  This noted as not
-      relevant to SASL-only implementors -- the normative references for
-      SCRAM as a GSS-API mechanism are segregated as well.
-
-   Changes since -07
-
-   o  Updated References.
-
-   o  Clarified purpose of the m= attribute.
-
-   o  Fixed a problem with authentication/authorization identity's ABNF
-      not allowing for some characters.
-
-   o  Updated ABNF for nonce to show client-generated and server-
-      generated parts.
-
-   o  Only register SCRAM-HMAC-SHA-1 with IANA and require explicit
-      registrations of all other SCRAM-HMAC- mechanisms.
-
-   Changes since -06
-
-   o  Removed hash negotiation from SCRAM and turned it into a family of
-      SASL mechanisms.
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 28]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-   o  Start using "Hash Function Textual Names" IANA registry for SCRAM
-      mechanism naming.
-
-   o  Fixed definition of Hi(str, salt) to be consistent with [RFC2898].
-
-   o  Clarified extensibility of SCRAM: added m= attribute (for future
-      mandatory extensions) and specified that all unrecognized
-      attributes must be ignored.
-
-   Changes since -05
-
-   o  Changed the mandatory to implement hash algorithm to SHA-1 (as per
-      WG consensus).
-
-   o  Added text about use of SASLPrep for username canonicalization/
-      validation.
-
-   o  Clarified that authorization identity is canonicalized/verified
-      according to SASL protocol profile.
-
-   o  Clarified that iteration count is per-user.
-
-   o  Clarified how clients select the authentication function.
-
-   o  Added IANA registration for the new mechanism.
-
-   o  Added missing normative references (UTF-8, SASLPrep).
-
-   o  Various editorial changes based on comments from Hallvard B
-      Furuseth, Nico William and Simon Josefsson.
-
-   Changes since -04
-
-   o  Update Base64 and Security Glossary references.
-
-   o  Add Formal Syntax section.
-
-   o  Don't bother with "v=".
-
-   o  Make MD5 mandatory to implement.  Suggest i=128.
-
-   Changes since -03
-
-   o  Seven years have passed, in which it became clear that DIGEST-MD5
-      suffered from unacceptably bad interoperability, so SCRAM-MD5 is
-      now back from the dead.
-
-   o  Be hash agnostic, so MD5 can be replaced more easily.
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 29]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-   o  General simplification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 30]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-12.  References
-
-12.1.  Normative References
-
-   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
-              (SHA1)", RFC 3174, September 2001.
-
-   [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
-              Internationalized Strings ("stringprep")", RFC 3454,
-              December 2002.
-
-   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
-              10646", STD 63, RFC 3629, November 2003.
-
-   [RFC4013]  Zeilenga, K., "SASLprep: Stringprep Profile for User Names
-              and Passwords", RFC 4013, February 2005.
-
-   [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
-              Security Layer (SASL)", RFC 4422, June 2006.
-
-   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
-              Encodings", RFC 4648, October 2006.
-
-   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
-              Channels", RFC 5056, November 2007.
-
-   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
-              Specifications: ABNF", STD 68, RFC 5234, January 2008.
-
-12.2.  Normative References for GSS-API implementors
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
-              Encryption for Kerberos 5", RFC 3962, February 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 31]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
-              Extension for the Generic Security Service Application
-              Program Interface (GSS-API)", RFC 4401, February 2006.
-
-   [RFC4402]  Williams, N., "A Pseudo-Random Function (PRF) for the
-              Kerberos V Generic Security Service Application Program
-              Interface (GSS-API) Mechanism", RFC 4402, February 2006.
-
-12.3.  Informative References
-
-   [I-D.ietf-sasl-crammd5-to-historic]
-              Zeilenga, K., "CRAM-MD5 to Historic",
-              draft-ietf-sasl-crammd5-to-historic-00 (work in progress),
-              November 2008.
-
-   [I-D.ietf-sasl-digest-to-historic]
-              Melnikov, A., "Moving DIGEST-MD5 to Historic",
-              draft-ietf-sasl-digest-to-historic-00 (work in progress),
-              July 2008.
-
-   [I-D.ietf-sasl-rfc2831bis]
-              Melnikov, A., "Using Digest Authentication as a SASL
-              Mechanism", draft-ietf-sasl-rfc2831bis-12 (work in
-              progress), March 2007.
-
-   [RFC2195]  Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
-              AUTHorize Extension for Simple Challenge/Response",
-              RFC 2195, September 1997.
-
-   [RFC2202]  Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
-              SHA-1", RFC 2202, September 1997.
-
-   [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
-              Specification Version 2.0", RFC 2898, September 2000.
-
-   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-              Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [RFC4510]  Zeilenga, K., "Lightweight Directory Access Protocol
-              (LDAP): Technical Specification Road Map", RFC 4510,
-              June 2006.
-
-   [RFC4616]  Zeilenga, K., "The PLAIN Simple Authentication and
-              Security Layer (SASL) Mechanism", RFC 4616, August 2006.
-
-   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
-              RFC 4949, August 2007.
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 32]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 33]
-
-Internet-Draft                    SCRAM                       March 2009
-
-
-Authors' Addresses
-
-   Abhijit Menon-Sen
-   Oryx Mail Systems GmbH
-
-   Email: ams@oryx.com
-
-
-   Alexey Melnikov
-   Isode Ltd
-
-   Email: Alexey.Melnikov@isode.com
-
-
-   Chris Newman
-   Sun Microsystems
-   1050 Lakes Drive
-   West Covina, CA  91790
-   USA
-
-   Email: chris.newman@sun.com
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   USA
-
-   Email: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Menon-Sen, et al.      Expires September 24, 2009              [Page 34]
-
diff --git a/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt b/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt
deleted file mode 100644
index 24325fdbd..000000000
--- a/doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt
+++ /dev/null
@@ -1,281 +0,0 @@
-CAT Working Group                                           K. Raeburn
-Internet-draft                                                     MIT
-Category:                                                July 14, 2000
-Updates: RFC 1964
-Document: draft-raeburn-cat-gssapi-krb5-3des-00.txt
-
-        Triple-DES Support for the Kerberos 5 GSSAPI Mechanism
-
-Status of this Memo
- 
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026 [RFC2026]. 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."
-     
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-
-   The MIT Kerberos 5 release version 1.2 includes support for
-   triple-DES with key derivation [KrbRev].  Recent work by the EFF
-   [EFF] has demonstrated the vulnerability of single-DES mechanisms
-   to brute-force attacks by sufficiently motivated and well-funded
-   parties.
-
-   The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5]
-   specifically enumerates encryption and checksum types,
-   independently of how such schemes may be used in Kerberos.  In the
-   long run, a new Kerberos-based mechanism, which does not require
-   separately enumerating for the GSSAPI mechanism each of the
-   encryption types defined by Kerberos, appears to be a better
-   approach.  Efforts to produce such a specification are under way.
-
-   In the interest of providing increased security in the interim,
-   however, MIT is proposing adding support for triple-DES to the
-   existing mechanism, as described here.
-
-2. Conventions Used in this Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
-   this document are to be interpreted as described in RFC 2119.
-
-3. New Algorithm Identifiers
-
-   One new sealing algorithm is defined, for use in WRAP tokens:
-
-   02 00 - DES3-KD
-
-   This algorithm uses triple-DES with key derivation, with a usage
-   value KG_USAGE_SEAL.  Padding is still to 8-byte multiples, and the
-   IV for encrypting application data is zero.
-
-   One new signing algorithm is defined, for use in MIC, Wrap, and
-   Delete tokens:
-
-   04 00 - HMAC SHA1 DES3-KD
-
-   This algorithm generates an HMAC using SHA-1 and a derived DES3 key
-   with usage KG_USAGE_SIGN, as (ought to be described) in [KrbRev].
-
-   [XXX: The current [KrbRev] description refers to expired I-Ds from
-   Marc Horowitz.  The text in [KrbRev] may be inadequate to produce
-   an interoperable implementation.]
-
-   The checksum size for this algorithm is 20 octets.  See section 5.3
-   below for the use of checksum lengths of other than eight bytes.
-
-4. Key Derivation
-
-   For purposes of key derivation, we add three new usage values to the
-   list defined in [KrbRev]; one for signing messages, one for
-   sealing messages, and one for encrypting sequence numbers:
-
-   #define KG_USAGE_SEAL 22
-   #define KG_USAGE_SIGN 23
-   #define KG_USAGE_SEQ  24
-
-5. Adjustments to Previous Definitions
-
-5.1. Quality of Protection
-
-   The GSSAPI specification [GSSAPI] says that a zero QOP value
-   indicates the "default".  The original specification for the
-   Kerberos 5 mechanism says that a zero QOP value (or a QOP value
-   with the appropriate bits clear) means DES encryption.
-
-   Rather than continue to force the use of plain DES when the
-   application doesn't use mechanism-specific QOP values, the better
-   choice appears to be to redefine the DES QOP value as some non-zero
-   value, and define a triple-DES value as well.  Then a zero value
-   continues to imply the default, which would be triple-DES
-   protection when given a triple-DES session key.
-
-   Our values are:
-
-   GSS_KRB5_INTEG_C_QOP_HMAC_SHA1        0x0004
-            /* SHA-1 checksum encrypted with key derivation */
-
-   GSS_KRB5_CONF_C_QOP_DES               0x0100
-            /* plain DES encryption */
-   GSS_KRB5_CONF_C_QOP_DES3_KD           0x0200
-            /* triple-DES with key derivation */
-
-   Rather than open the question of whether to specify means for
-   deriving a key of one type given a key of another type, and the
-   security implications of whether to generate a long key from a
-   shorter one, our implementation will simply return an error if the
-   QOP value specified does not correspond to the session key type.
-
-   [Implementation note: MIT's code does not implement QoP, and
-   returns an error for any non-zero QoP value.]
-
-5.2. MIC Sequence Number Encryption
-
-   The sequence numbers are encrypted in the context key (as defined
-   in [GSSAPI-KRB5] -- this will be either the Kerberos session key or
-   asubkey provided by the context initiator), using whatever
-   encryption system is designated by the type of that context key.
-   The IV is formed from the first N bytes of the SGN_CKSUM field,
-   where N is the number of bytes needed for the IV.  (With all
-   algorithms described here and in [GSSAPI-KRB5], the checksum is at
-   least as large as the IV.)
-
-5.3. Message Layout
-
-   Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an
-   checksum field SGN_CKSUM.  In [GSSAPI-KRB5], this field was
-   specified as being 8 bytes long.  We now change this size to be
-   "defined by the checksum algorithm", and retroactively amend the
-   descriptions of all the checksum algorithms described in
-   [GSSAPI-KRB5] to explicitly specify 8-byte output.  Application
-   data continues to immediately follow the checksum field in the Wrap
-   token.
-
-   The revised message descriptions are thus:
-
-   MIC:
-
-   Byte no          Name           Description
-    0..1           TOK_ID          Identification field.
-    2..3           SGN_ALG         Integrity algorithm indicator.
-    4..7           Filler          Contains ff ff ff ff
-    8..15          SND_SEQ         Sequence number field.
-    16..s+15       SGN_CKSUM       Checksum of "to-be-signed data",
-                                   calculated according to algorithm
-                                   specified in SGN_ALG field.
-
-   Wrap:
-
-   Byte no          Name           Description
-    0..1           TOK_ID          Identification field.
-                                   Tokens emitted by GSS_Wrap() contain
-                                   the hex value 02 01 in this field.
-    2..3           SGN_ALG         Checksum algorithm indicator.
-    4..5           SEAL_ALG        Sealing algorithm indicator.
-    6..7           Filler          Contains ff ff
-    8..15          SND_SEQ         Encrypted sequence number field.
-    16..s+15       SGN_CKSUM       Checksum of plaintext padded data,
-                                   calculated according to algorithm
-                                   specified in SGN_ALG field.
-    s+16..last     Data            encrypted or plaintext padded data
-
-   Where "s" indicates the size of the checksum.
-
-   As indicated above in section 2, we define the HMAC SHA1 DES3-KD
-   checksum algorithm to produce a 20-byte output, so encrypted data
-   begins at byte 36.
-
-6. Backwards Compatibility Considerations
-
-   The context initiator SHOULD request of the KDC credentials using
-   session-key cryptosystem types supported by that implementation; if
-   the only types returned by the KDC are not supported by the
-   mechanism implementation, it MUST indicate a failure.  This may
-   seem obvious, but early implementations of both Kerberos and the
-   GSSAPI Kerberos mechanism supported only DES keys, so the
-   cryptosystem compatibility question was easy to overlook.
-
-   Under the current mechanism, no negotiation of algorithm types
-   occurs, so server-side (acceptor) implementations cannot request
-   that clients not use algorithm types not understood by the server.
-   However, administration of the server's Kerberos data has to be
-   done in communication with the KDC, and it is from the KDC that the
-   client will request credentials.  The KDC could therefore be tasked
-   with limiting session keys for a given service to types actually
-   supported by the Kerberos and GSSAPI software on the server.
-
-   This does have a drawback for cases where a service principal name
-   is used both for GSSAPI-based and non-GSSAPI-based communication,
-   if the GSSAPI implementation does not understand triple-DES but the
-   Kerberos implementation does.  It means that triple-DES session
-   keys cannot be issued for that service principal, which keeps the
-   protection of non-GSSAPI services weaker than necessary.  However,
-   in the most recent MIT releases thus far, while triple-DES support
-   has been present, it has required additional work to enable, so it
-   is not likely to be in use for many services.
-
-   It would also be possible to have clients attempt to get single-DES
-   session keys before trying to get triple-DES session keys, and have
-   the KDC refuse to issue the single-DES keys only for the most
-   critical of services, for which single-DES protection is considered
-   inadequate.  However, that would eliminate the possibility of
-   connecting with the more secure cryptosystem to any service that
-   can be accessed with the weaker cryptosystem.
-
-   We have chosen to go with the former approach, putting the burden
-   on the KDC administration and gaining the best protection possible
-   for GSSAPI services, possibly at the cost of protection of
-   non-GSSAPI Kerberos services running earlier versions of the
-   software.
-
-6. Security Considerations
-
-   Various tradeoffs arise regarding the mixing of new and old
-   software, or GSSAPI-based and non-GSSAPI Kerberos authentication.
-   They are discussed in section 5.
-
-7. References
-
-   [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of
-   Encryption Research, Wiretap Politics, and Chip Design", O'Reilly &
-   Associates, Inc., May, 1998.
-
-   [GSSAPI] Linn, J., "Generic Security Service Application Program
-   Interface Version 2, Update 1", RFC 2743, January, 2000.
-
-   [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-   RFC 1964, June, 1996.
-
-   [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
-   Authentication Service (V5)",
-   draft-ietf-cat-kerberos-revisions-05.txt, March 10, 2000.
-
-   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
-   3", RFC 2026, October, 1996.
-
-8. Author's Address
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-
-9. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this   
-   document itself may not be modified in any way, such as by removing   
-   the copyright notice or references to the Internet Society or other   
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
diff --git a/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt b/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt
deleted file mode 100644
index 64ca1ac49..000000000
--- a/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Kerberos Working Group                                        K. Raeburn
-Category: Informational                                              MIT
-Document: draft-raeburn-krb-gssapi-krb5-3des-01.txt    November 24, 2000
-
-
-         Triple-DES Support for the Kerberos 5 GSSAPI Mechanism
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026 [1]. 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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-1. Abstract
-
-   The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5] specifically
-   enumerates encryption and checksum types, independently of how such
-   schemes may be used in Kerberos.  In the long run, a new Kerberos-
-   based mechanism, which does not require separately enumerating for
-   the GSSAPI mechanism each of the various encryption types defined by
-   Kerberos, is probably a better approach.  Various people have
-   expressed interest in designing one, but the work has not yet been
-   completed.
-
-   The MIT Kerberos 5 release version 1.2 includes support for triple-
-   DES with key derivation [KrbRev].  Recent work by the EFF [EFF] has
-   demonstrated the vulnerability of single-DES mechanisms to brute-
-   force attacks by sufficiently motivated and well-funded parties.  So,
-   in the interest of providing increased security in the near term, MIT
-   is adding support for triple-DES to the existing mechanism
-   implementation we ship, as an interim measure.
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 1]
-
-INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
-
-
-2. New Algorithm Identifiers
-
-   One new sealing algorithm is defined, for use in Wrap tokens.
-
-
-   +--------------------------------------------------------------------+
-   |          name                                octet values          |
-   +--------------------------------------------------------------------+
-   |         DES3-KD                                 02 00              |
-   +--------------------------------------------------------------------+
-
-   This algorithm uses triple-DES with key derivation, with a usage
-   value KG_USAGE_SEAL.  (Unlike the EncryptedData definition in
-   [KrbRev], no integrity protection is needed, so this is "raw" triple-
-   DES, with no checksum attached to the encrypted data.)  Padding is
-   still to 8-byte multiples, and the IV for encrypting application data
-   is zero.
-
-   One new signing algorithm is defined, for use in MIC, Wrap, and
-   Delete tokens.
-
-
-   +--------------------------------------------------------------------+
-   |             name                               octet values        |
-   +--------------------------------------------------------------------+
-   |       HMAC SHA1 DES3-KD                           04 00            |
-   +--------------------------------------------------------------------+
-
-   This algorithm generates an HMAC using SHA-1 and a derived DES3 key
-   with usage KG_USAGE_SIGN, as described in [KrbRev].
-
-   [N.B.: The current [KrbRev] description refers to expired I-Ds from
-   Marc Horowitz.  The text in [KrbRev] may be inadequate to produce an
-   interoperable implementation.]
-
-   The checksum size for this algorithm is 20 octets.  See section 4.3
-   below for the use of checksum lengths of other than eight bytes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 2]
-
-INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
-
-
-3. Key Derivation
-
-   For purposes of key derivation, we add three new usage values to the
-   list defined in [KrbRev]; one for signing messages, one for sealing
-   messages, and one for encrypting sequence numbers:
-
-
-   +--------------------------------------------------------------------+
-   |             name                                    value          |
-   +--------------------------------------------------------------------+
-   |         KG_USAGE_SEAL                                22            |
-   |         KG_USAGE_SIGN                                23            |
-   |         KG_USAGE_SEQ                                 24            |
-   +--------------------------------------------------------------------+
-
-4. Adjustments to Previous Definitions
-
-4.1. Quality of Protection
-
-   The GSSAPI specification [GSSAPI] says that a zero QOP value
-   indicates the "default".  The original specification for the Kerberos
-   5 mechanism says that a zero QOP value (or a QOP value with the
-   appropriate bits clear) means DES encryption.
-
-   Rather than forcing the use of plain DES when the application doesn't
-   use mechanism-specific QOP values, we redefine the explicit DES QOP
-   value as a non-zero value, and define a triple-DES value as well.
-   Then a zero value continues to imply the default, which would be
-   triple-DES protection when given a triple-DES session key.
-
-   Our values are:
-
-   +--------------------------------------------------------------------+
-   |             name                  value      meaning               |
-   +--------------------------------------------------------------------+
-   | GSS_KRB5_INTEG_C_QOP_HMAC_SHA1    0x0004     SHA-1 HMAC, using     |
-   |                                              key derivation        |
-   |                                                                    |
-   |    GSS_KRB5_CONF_C_QOP_DES        0x0100     plain DES encryption  |
-   |                                                                    |
-   |  GSS_KRB5_CONF_C_QOP_DES3_KD      0x0200     triple-DES with key   |
-   |                                              derivation            |
-   +--------------------------------------------------------------------+
-
-   Rather than attempt to specify a generic mechanism for deriving a key
-   of one type given a key of another type, and evaluate the security
-   implications of using a short key to generate a longer key to satisfy
-   the requested quality of protection, our implementation will simply
-
-
-
-Raeburn                                                         [Page 3]
-
-INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
-
-
-   return an error if the nonzero QOP value specified does not
-   correspond to the session key type.
-
-4.2. MIC Sequence Number Encryption
-
-   The sequence numbers are encrypted in the context key (as defined in
-   [GSSAPI-KRB5] -- this will be either the Kerberos session key or
-   asubkey provided by the context initiator), using whatever encryption
-   system is designated by the type of that context key.  The IV is
-   formed from the first N bytes of the SGN_CKSUM field, where N is the
-   number of bytes needed for the IV.  (With all algorithms described
-   here and in [GSSAPI-KRB5], the checksum is at least as large as the
-   IV.)
-
-4.3. Message Layout
-
-   Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an
-   checksum field SGN_CKSUM.  In [GSSAPI-KRB5], this field was specified
-   as being 8 bytes long.  We now change this size to be "defined by the
-   checksum algorithm", and retroactively amend the descriptions of all
-   the checksum algorithms described in [GSSAPI-KRB5] to explicitly
-   specify 8-byte output.  Application data continues to immediately
-   follow the checksum field in the Wrap token.
-
-   The revised message descriptions are thus:
-
-   MIC token:
-
-   Byte #             Name                Description
-   ----------------------------------------------------------------------
-    0..1              TOK_ID              Identification field.
-    2..3              SGN_ALG             Integrity algorithm indicator.
-    4..7              Filler              Contains ff ff ff ff
-    8..15             SND_SEQ             Sequence number field.
-   16..s+15           SGN_CKSUM           Checksum of "to-be-signed
-                                          data", calculated according to
-                                          algorithm specified in SGN_ALG
-                                          field.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 4]
-
-INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
-
-
-   Wrap token:
-
-   Byte #           Name             Description
-   ----------------------------------------------------------------------
-    0..1            TOK_ID           Identification field.  Tokens
-                                     emitted by GSS_Wrap() contain the
-                                     hex value 02 01 in this field.
-    2..3            SGN_ALG          Checksum algorithm indicator.
-    4..5            SEAL_ALG         Sealing algorithm indicator.
-    6..7            Filler           Contains ff ff
-    8..15           SND_SEQ          Encrypted sequence number field.
-   16..s+15         SGN_CKSUM        Checksum of plaintext padded data,
-                                     calculated according to algorithm
-                                     specified in SGN_ALG field.
-   s+16..last       Data             encrypted or plaintext padded data
-
-
-   Where "s" indicates the size of the checksum.
-
-   As indicated above in section 2, we define the HMAC SHA1 DES3-KD
-   checksum algorithm to produce a 20-byte output, so encrypted data
-   begins at byte 36.
-
-5. Backwards Compatibility Considerations
-
-   The context initiator should request of the KDC credentials using
-   session-key cryptosystem types supported by that implementation; if
-   the only types returned by the KDC are not supported by the mechanism
-   implementation, it should indicate a failure.  This may seem obvious,
-   but early implementations of both Kerberos and the GSSAPI Kerberos
-   mechanism supported only DES keys, so the cryptosystem compatibility
-   question was easy to overlook.
-
-   Under the current mechanism, no negotiation of algorithm types
-   occurs, so server-side (acceptor) implementations cannot request that
-   clients not use algorithm types not understood by the server.
-   However, administration of the server's Kerberos data (e.g., the
-   service key) has to be done in communication with the KDC, and it is
-   from the KDC that the client will request credentials.  The KDC could
-   therefore be tasked with limiting session keys for a given service to
-   types actually supported by the Kerberos and GSSAPI software on the
-   server.
-
-   This does have a drawback for cases where a service principal name is
-   used both for GSSAPI-based and non-GSSAPI-based communication (most
-   notably the "host" service key), if the GSSAPI implementation does
-   not understand triple-DES but the Kerberos implementation does.  It
-   means that triple-DES session keys cannot be issued for that service
-
-
-
-Raeburn                                                         [Page 5]
-
-INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
-
-
-   principal, which keeps the protection of non-GSSAPI services weaker
-   than necessary.
-
-   It would also be possible to have clients attempt to get single-DES
-   session keys before trying to get triple-DES session keys, and have
-   the KDC refuse to issue the single-DES keys only for the most
-   critical of services, for which single-DES protection is considered
-   inadequate.  However, that would eliminate the possibility of
-   connecting with the more secure cryptosystem to any service that can
-   be accessed with the weaker cryptosystem.
-
-   For MIT's 1.2 release, we chose to go with the former approach,
-   putting the burden on the KDC administration and gaining the best
-   protection possible for GSSAPI services, possibly at the cost of
-   weaker protection of non-GSSAPI Kerberos services running earlier
-   versions of the software.
-
-6. Security Considerations
-
-   Various tradeoffs arise regarding the mixing of new and old software,
-   or GSSAPI-based and non-GSSAPI Kerberos authentication.  They are
-   discussed in section 5.
-
-7. References
-
-   [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of
-   Encryption Research, Wiretap Politics, and Chip Design", O'Reilly &
-   Associates, Inc., May, 1998.
-
-   [GSSAPI] Linn, J., "Generic Security Service Application Program
-   Interface Version 2, Update 1", RFC 2743, January, 2000.
-
-   [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-   RFC 1964, June, 1996.
-
-   [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
-   Authentication Service (V5)", draft-ietf-cat-kerberos-
-   revisions-06.txt, July 4, 2000.
-
-8. Author's Address
-
-   Kenneth Raeburn Massachusetts Institute of Technology 77
-   Massachusetts Avenue Cambridge, MA 02139
-
-9. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-
-
-
-Raeburn                                                         [Page 6]
-
-INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
-
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-10. Document Change History
-
->From -00 to -01:
-
-   Converted master to GNU troff and tbl, rewriting tables in the
-   process.
-
-   Specify informational category only.  Modify some text to emphasize
-   that this document intends to describe MIT's extensions.
-
-   Point out that while EncryptedData for 3des-kd includes a checksum,
-   DES3-KD GSS encryption does not.
-
-   Shorten backwards-compatibility descriptions a little.
-
-   Submit to Kerberos working group rather than CAT.
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 7]
-
diff --git a/doc/standardisation/draft-raeburn-krb-rijndael-krb-02.txt b/doc/standardisation/draft-raeburn-krb-rijndael-krb-02.txt
deleted file mode 100644
index 6b9989f87..000000000
--- a/doc/standardisation/draft-raeburn-krb-rijndael-krb-02.txt
+++ /dev/null
@@ -1,618 +0,0 @@
-
-
-
-
-
-
-
-
-
-Kerberos Working Group                                        K. Raeburn
-Document: draft-raeburn-krb-rijndael-krb-02.txt                      MIT
-                                                        November 1, 2002
-                                                     expires May 1, 2003
-
-                     AES Encryption for Kerberos 5
-
-Abstract
-
-   Recently the US National Institute of Standards and Technology chose
-   a new Advanced Encryption Standard [AES], which is significantly
-   faster and (it is believed) more secure than the old DES algorithm.
-   This document is a specification for the addition of this algorithm
-   to the Kerberos cryptosystem suite [KCRYPTO].
-
-   Comments should be sent to the author, or to the IETF Kerberos
-   working group (ietf-krb-wg@anl.gov).
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026 [RFC2026]. 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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-1. Introduction
-
-   This document defines encryption key and checksum types for Kerberos
-   5 using the AES algorithm recently chosen by NIST.  These new types
-   support 128-bit block encryption, and key sizes of 128 or 256 bits.
-
-   Using the "simplified profile" of [KCRYPTO], we can define a pair of
-   encryption and checksum schemes.  AES is used with cipher text
-   stealing to avoid message expansion, and SHA-1 [SHA1] is the
-
-
-
-Raeburn                                                         [Page 1]
-
-INTERNET DRAFT                                             November 2002
-
-
-   associated checksum function.
-
-2. Conventions Used in this Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119.
-
-3. Protocol Key Representation
-
-   The profile in [KCRYPTO] treats keys and random octet strings as
-   conceptually different.  But since the AES key space is dense, we can
-   use any bit string as a key.  We use the byte representation for the
-   key described in [AES], where the first bit of the bit string is the
-   high bit of the first byte of the byte string (octet string)
-   representation.
-
-4. Key Generation From Pass Phrases or Random Data
-
-   Given the above format for keys, we can generate keys from the
-   appropriate amounts of random data (128 or 256 bits) by simply
-   copying the input string.
-
-   To generate an encryption key from a pass phrase and salt string, we
-   use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters
-   indicated below, to generate an intermediate key (of the same length
-   as the desired final key), which is then passed into the DK function
-   with the 8-octet ASCII string "kerberos" as is done for des3-cbc-
-   hmac-sha1-kd in [KCRYPTO].  (In [KCRYPTO] terms, the PBKDF2 function
-   produces a "random octet string", hence the application of the
-   random-to-key function even though it's effectively a simple identity
-   operation.)  The resulting key is the user's long-term key for use
-   with the encryption algorithm in question.
-
-    tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
-    key = DK(tkey, "kerberos")
-
-   The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the
-   passphrase and salt, as described in Appendix B.1 to PKCS#5.
-
-   The number of iterations is specified by the string-to-key parameters
-   supplied.  The parameter string is four octets indicating an unsigned
-   number in big-endian order.  This is the number of iterations to be
-   performed.  If the value is 00 00 00 00, the number of iterations to
-   be performed is 4294967296 (2**32).  (Thus the minimum expressable
-   iteration count is 1.)
-
-   For environments where slower hardware is the norm, implementations
-
-
-
-Raeburn                                                         [Page 2]
-
-INTERNET DRAFT                                             November 2002
-
-
-   may wish to limit the number of iterations to prevent a spoofed
-   response from consuming lots of client-side CPU time; it is
-   recommended that this bound be no less than 50000.  Even for
-   environments with fast hardware, 4 billion iterations is likely to
-   take a fairly long time; much larger bounds might still be enforced,
-   and it might be wise for implementations to permit interruption of
-   this operation by the user if the environment allows for it.
-
-   If the string-to-key parameters are not supplied, the default value
-   to be used is 00 00 b0 00 (decimal 45056, indicating 45056
-   iterations, which takes slightly under 1 second on a 300MHz Pentium
-   II in tests run by the author).
-
-   Sample test vectors are given in the appendix.
-
-5. Cipher Text Stealing
-
-   Cipher block chaining is used to encrypt messages.  Unlike previous
-   Kerberos cryptosystems, we use cipher text stealing to handle the
-   possibly partial final block of the message.
-
-   Cipher text stealing is described on pages 195-196 of [AC], and
-   section 8 of [RC5]; it has the advantage that no message expansion is
-   done during encryption of messages of arbitrary sizes as is typically
-   done in CBC mode with padding.
-
-   Cipher text stealing, as defined in [RC5], assumes that more than one
-   block of plain text is available.  Since a one-block confounder is
-   added in the simplified profile of [KCRYPTO], and [KCRYPTO] requires
-   that the message to be encrypted cannot be empty, the minimum length
-   to be encrypted is one block plus one byte.  Thus we do not need to
-   do anything special to meet this constraint.
-
-   For consistency, cipher text stealing is always used for the last two
-   blocks of the data to be encrypted, as in [RC5].  If the data length
-   is a multiple of the block size, this is equivalent to plain CBC mode
-   with the last two cipher text blocks swapped.
-
-   A test vector is given in the appendix.
-
-6. Kerberos Algorithm Profile Parameters
-
-   This is a summary of the parameters to be used with the simplified
-   algorithm profile described in [KCRYPTO]:
-
-
-
-
-
-
-
-Raeburn                                                         [Page 3]
-
-INTERNET DRAFT                                             November 2002
-
-
-   +--------------------------------------------------------------------+
-   |               protocol key format       128- or 256-bit string     |
-   |                                                                    |
-   |            string-to-key function       PBKDF2+DK with variable    |
-   |                                         iteration count (see       |
-   |                                         above)                     |
-   |                                                                    |
-   |  default string-to-key parameters       00 09                      |
-   |                                                                    |
-   |        key-generation seed length       key size                   |
-   |                                                                    |
-   |            random-to-key function       identity function          |
-   |                                                                    |
-   |                  hash function, H       SHA-1                      |
-   |                                                                    |
-   |               HMAC output size, h       12 octets (96 bits)        |
-   |                                                                    |
-   |                confounder size, c       16 octets                  |
-   |                                                                    |
-   |             message block size, m       1 octet                    |
-   |                                                                    |
-   |  encryption/decryption functions,       AES in CBC-CTS mode with   |
-   |  E and D                                zero ivec                  |
-   +--------------------------------------------------------------------+
-
-   Using this profile with each key size gives us two each of encryption
-   and checksum algorithm definitions.
-
-7. Assigned Numbers
-
-   The following encryption type numbers are assigned:
-
-   +--------------------------------------------------------------------+
-   |                         encryption types                           |
-   +--------------------------------------------------------------------+
-   |         type name                  etype value          key size   |
-   +--------------------------------------------------------------------+
-   |   aes128-cts-hmac-sha1-96              17                 128      |
-   |   aes256-cts-hmac-sha1-96              18                 256      |
-   +--------------------------------------------------------------------+
-
-   The following checksum type numbers are assigned:
-
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 4]
-
-INTERNET DRAFT                                             November 2002
-
-
-   +--------------------------------------------------------------------+
-   |                          checksum types                            |
-   +--------------------------------------------------------------------+
-   |        type name                 sumtype value           length    |
-   +--------------------------------------------------------------------+
-   |    hmac-sha1-96-aes128                10                   96      |
-   |    hmac-sha1-96-aes256                11                   96      |
-   +--------------------------------------------------------------------+
-
-   These checksum types will be used with the corresponding encryption
-   types defined above.
-
-8. Recommendations
-
-   Both new cryptosystems are RECOMMENDED.  They should be more secure
-   than DES cryptosystems, and much faster than triple-DES.
-
-9. Security Considerations
-
-   This new algorithm has not been around long enough to receive the
-   decades of intense analysis that DES has received.  It is possible
-   that some weakness exists that has not been found by the
-   cryptographers analyzing these algorithms before and during the AES
-   selection process.
-
-   The use of the HMAC function has drawbacks for certain pass phrase
-   lengths.  For example, a pass phrase longer than the hash function
-   block size (64 bytes, for SHA-1) is hashed to a smaller size (20
-   bytes) before applying the main HMAC algorithm.  However, entropy is
-   generally sparse in pass phrases, especially in long ones, so this
-   may not be a problem in the rare cases of users with long pass
-   phrases.
-
-   Also, generating a 256-bit key from a pass phrase of any length may
-   be deceptive, since the effective entropy in pass-phrase-derived key
-   cannot be nearly that large.
-
-   The iteration count in PBKDF2 appears to be useful primarily as a
-   constant multiplier for the amount of work required for an attacker
-   using brute-force methods.  Unfortunately, it also multiplies, by the
-   same amount, the work needed by a legitimate user with a valid
-   password.  Thus the work factor imposed on an attacker (who may have
-   many powerful workstations at his disposal) must be balanced against
-   the work factor imposed on the legitimate user (who may have a PDA or
-   cell phone); the available computing power on either side increases
-   as time goes on, as well.  A better way to deal with the brute-force
-   attack is through preauthentication mechanisms that provide better
-   protection of, the user's long-term key.  Use of such mechanisms is
-
-
-
-Raeburn                                                         [Page 5]
-
-INTERNET DRAFT                                             November 2002
-
-
-   out of scope for this document.
-
-   Any benefit against other attacks specific to the HMAC or SHA-1
-   algorithms is probably achieved with a fairly small number of
-   iterations.
-
-   Cipher text stealing mode, since it requires no additional padding,
-   will reveal the exact length of each message being encrypted, rather
-   than merely bounding it to a small range of possible lengths as in
-   CBC mode.  Such obfuscation should not be relied upon at higher
-   levels in any case; if the length must be obscured from an outside
-   observer, it should be done by intentionally varying the length of
-   the message to be encrypted.
-
-   The author is not a cryptographer.  Caveat emptor.
-
-10. IANA Considerations
-
-   None.
-
-11. Acknowledgements
-
-   Thanks to John Brezak, Gerardo Diaz Cuellar and Marcus Watts for
-   feedback on earlier versions of this document.
-
-12. Normative References
-
-   [AC] Schneier, B., "Applied Cryptography", second edition, John Wiley
-   and Sons, New York, 1996.
-
-   [AES] National Institute of Standards and Technology, U.S. Department
-   of Commerce, "Advanced Encryption Standard", Federal Information
-   Processing Standards Publication 197, Washington, DC, November 2001.
-
-   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
-   Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002.  Work in
-   progress.
-
-   [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography
-   Specification Version 2.0", RFC 2898, September 2000.
-
-   [RC5] Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
-   RC5-CTS Algorithms", RFC 2040, October 1996.
-
-   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
-   3", RFC 2026, October 1996.
-
-   [SHA1] National Institute of Standards and Technology, U.S.
-
-
-
-Raeburn                                                         [Page 6]
-
-INTERNET DRAFT                                             November 2002
-
-
-   Department of Commerce, "Secure Hash Standard", Federal Information
-   Processing Standards Publication 180-1, Washington, DC, April 1995.
-
-13. Informative References
-
-   [PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 3211,
-   December 2001.
-
-14. Author's Address
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-   raeburn@mit.edu
-
-15. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-A. Sample test vectors
-
-   Sample values for the string-to-key function are included below.
-
-
-
-
-Raeburn                                                         [Page 7]
-
-INTERNET DRAFT                                             November 2002
-
-
-   Iteration count = 1
-   Pass phrase = "password"
-   Salt = "ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
-   128-bit AES key:
-       42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15
-   256-bit PBKDF2 output:
-       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
-       0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37
-   256-bit AES key:
-       fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b
-       bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61
-
-   Iteration count = 2
-   Pass phrase = "password"
-   Salt="ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
-   128-bit AES key:
-       c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13
-   256-bit PBKDF2 output:
-       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
-       a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86
-   256-bit AES key:
-       a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61
-       02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff
-
-   Iteration count = 1200
-   Pass phrase = "password"
-   Salt = "ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
-   128-bit AES key:
-       4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a
-   256-bit PBKDF2 output:
-       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
-       a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13
-   256-bit AES key:
-       55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7
-       54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 8]
-
-INTERNET DRAFT                                             November 2002
-
-
-   Iteration count = 5
-   Pass phrase = "password"
-   Salt=0x1234567878563412
-   128-bit PBKDF2 output:
-       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
-   128-bit AES key:
-       e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e
-   256-bit PBKDF2 output:
-       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
-       3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee
-   256-bit AES key:
-       97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c
-       ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31
-   (This test is based on values given in [PECMS].)
-
-   Iteration count = 1200
-   Pass phrase = (64 characters)
-     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
-   Salt="pass phrase equals block size"
-   128-bit PBKDF2 output:
-       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
-   128-bit AES key:
-       59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed
-   256-bit PBKDF2 output:
-       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
-       c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1
-   256-bit AES key:
-       89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0
-       56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34
-
-   Iteration count = 1200
-   Pass phrase = (65 characters)
-     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
-   Salt = "pass phrase exceeds block size"
-   128-bit PBKDF2 output:
-       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
-   128-bit AES key:
-       cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d
-   256-bit PBKDF2 output:
-       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
-       1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a
-   256-bit AES key:
-       d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2
-       14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b
-
-
-
-
-
-
-
-Raeburn                                                         [Page 9]
-
-INTERNET DRAFT                                             November 2002
-
-
-   Iteration count = 50
-   Pass phrase = g-clef (0xf09d849e)
-   Salt = "EXAMPLE.COMpianist"
-   128-bit PBKDF2 output:
-       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
-   128-bit AES key:
-       f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5
-   256-bit PBKDF2 output:
-       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
-       e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52
-   256-bit AES key:
-       4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c
-       57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e
-
-   Some test vectors for CBC with cipher text stealing, using an initial
-   vector of all-zero.
-
-   AES 128-bit key:
-       63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20
-   Output:
-       c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
-       97
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20
-   Output:
-       fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-   Output:
-       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 10]
-
-INTERNET DRAFT                                             November 2002
-
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c
-   Output:
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-       b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
-       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
-   Output:
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-       9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
-       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
-       61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e
-   Output:
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-       48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
-       9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 11]
diff --git a/doc/standardisation/draft-raeburn-krb-rijndael-krb-03.txt b/doc/standardisation/draft-raeburn-krb-rijndael-krb-03.txt
deleted file mode 100644
index 70395f2ba..000000000
--- a/doc/standardisation/draft-raeburn-krb-rijndael-krb-03.txt
+++ /dev/null
@@ -1,674 +0,0 @@
-
-
-
-
-
-
-
-
-
-Kerberos Working Group                                        K. Raeburn
-Document: draft-raeburn-krb-rijndael-krb-03.txt                      MIT
-                                                       February 24, 2003
-                                                 expires August 24, 2003
-
-                     AES Encryption for Kerberos 5
-
-Abstract
-
-   Recently the US National Institute of Standards and Technology chose
-   a new Advanced Encryption Standard [AES], which is significantly
-   faster and (it is believed) more secure than the old DES algorithm.
-   This document is a specification for the addition of this algorithm
-   to the Kerberos cryptosystem suite [KCRYPTO].
-
-   Comments should be sent to the author, or to the IETF Kerberos
-   working group (ietf-krb-wg@anl.gov).
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026 [RFC2026]. 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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-1. Introduction
-
-   This document defines encryption key and checksum types for Kerberos
-   5 using the AES algorithm recently chosen by NIST.  These new types
-   support 128-bit block encryption, and key sizes of 128 or 256 bits.
-
-   Using the "simplified profile" of [KCRYPTO], we can define a pair of
-   encryption and checksum schemes.  AES is used with cipher text
-   stealing to avoid message expansion, and SHA-1 [SHA1] is the
-
-
-
-Raeburn                                                         [Page 1]
-
-INTERNET DRAFT                                             February 2003
-
-
-   associated checksum function.
-
-2. Conventions Used in this Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119.
-
-3. Protocol Key Representation
-
-   The profile in [KCRYPTO] treats keys and random octet strings as
-   conceptually different.  But since the AES key space is dense, we can
-   use any bit string of appropriate length as a key.  We use the byte
-   representation for the key described in [AES], where the first bit of
-   the bit string is the high bit of the first byte of the byte string
-   (octet string) representation.
-
-4. Key Generation From Pass Phrases or Random Data
-
-   Given the above format for keys, we can generate keys from the
-   appropriate amounts of random data (128 or 256 bits) by simply
-   copying the input string.
-
-   To generate an encryption key from a pass phrase and salt string, we
-   use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters
-   indicated below, to generate an intermediate key (of the same length
-   as the desired final key), which is then passed into the DK function
-   with the 8-octet ASCII string "kerberos" as is done for des3-cbc-
-   hmac-sha1-kd in [KCRYPTO].  (In [KCRYPTO] terms, the PBKDF2 function
-   produces a "random octet string", hence the application of the
-   random-to-key function even though it's effectively a simple identity
-   operation.)  The resulting key is the user's long-term key for use
-   with the encryption algorithm in question.
-
-    tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
-    key = DK(tkey, "kerberos")
-
-   The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the
-   passphrase and salt, as described in Appendix B.1 to PKCS#5.
-
-   The number of iterations is specified by the string-to-key parameters
-   supplied.  The parameter string is four octets indicating an unsigned
-   number in big-endian order.  This is the number of iterations to be
-   performed.  If the value is 00 00 00 00, the number of iterations to
-   be performed is 4294967296 (2**32).  (Thus the minimum expressable
-   iteration count is 1.)
-
-   For environments where slower hardware is the norm, implementations
-
-
-
-Raeburn                                                         [Page 2]
-
-INTERNET DRAFT                                             February 2003
-
-
-   may wish to limit the number of iterations to prevent a spoofed
-   response from consuming lots of client-side CPU time; it is
-   recommended that this bound be no less than 50000.  Even for
-   environments with fast hardware, 4 billion iterations is likely to
-   take a fairly long time; much larger bounds might still be enforced,
-   and it might be wise for implementations to permit interruption of
-   this operation by the user if the environment allows for it.
-
-   If the string-to-key parameters are not supplied, the default value
-   to be used is 00 00 b0 00 (decimal 45056, indicating 45056
-   iterations, which takes slightly under 1 second on a 300MHz Pentium
-   II in tests run by the author).
-
-   Sample test vectors are given in the appendix.
-
-5. Cipher Text Stealing
-
-   Cipher block chaining is used to encrypt messages.  Unlike previous
-   Kerberos cryptosystems, we use cipher text stealing to handle the
-   possibly partial final block of the message.
-
-   Cipher text stealing is described on pages 195-196 of [AC], and
-   section 8 of [RC5]; it has the advantage that no message expansion is
-   done during encryption of messages of arbitrary sizes as is typically
-   done in CBC mode with padding.
-
-   Cipher text stealing, as defined in [RC5], assumes that more than one
-   block of plain text is available.  If exactly one block is to be
-   encrypted, that block is simply encrypted with AES (also known as ECB
-   mode).  Input of less than one block is padded at the end to one
-   block; the values of the padding bits are unspecified.
-   (Implementations may use all-zero padding, but protocols should not
-   rely on the result being deterministic.  Implementations may use
-   random padding, but protocols should not rely on the result not being
-   deterministic.  Note that in most cases, the Kerberos encryption
-   profile will add a random confounder independent of this padding.)
-
-   For consistency, cipher text stealing is always used for the last two
-   blocks of the data to be encrypted, as in [RC5].  If the data length
-   is a multiple of the block size, this is equivalent to plain CBC mode
-   with the last two cipher text blocks swapped.
-
-   A test vector is given in the appendix.
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 3]
-
-INTERNET DRAFT                                             February 2003
-
-
-6. Kerberos Algorithm Profile Parameters
-
-   This is a summary of the parameters to be used with the simplified
-   algorithm profile described in [KCRYPTO]:
-
-   +--------------------------------------------------------------------+
-   |               protocol key format       128- or 256-bit string     |
-   |                                                                    |
-   |            string-to-key function       PBKDF2+DK with variable    |
-   |                                         iteration count (see       |
-   |                                         above)                     |
-   |                                                                    |
-   |  default string-to-key parameters       00 00 b0 00                |
-   |                                                                    |
-   |        key-generation seed length       key size                   |
-   |                                                                    |
-   |            random-to-key function       identity function          |
-   |                                                                    |
-   |                  hash function, H       SHA-1                      |
-   |                                                                    |
-   |               HMAC output size, h       12 octets (96 bits)        |
-   |                                                                    |
-   |             message block size, m       1 octet                    |
-   |                                                                    |
-   |  encryption/decryption functions,       AES in CBC-CTS mode with   |
-   |  E and D                                zero ivec (cipher block    |
-   |                                         size 16 octets)            |
-   +--------------------------------------------------------------------+
-
-   Using this profile with each key size gives us two each of encryption
-   and checksum algorithm definitions.
-
-7. Assigned Numbers
-
-   The following encryption type numbers are assigned:
-
-   +--------------------------------------------------------------------+
-   |                         encryption types                           |
-   +--------------------------------------------------------------------+
-   |         type name                  etype value          key size   |
-   +--------------------------------------------------------------------+
-   |   aes128-cts-hmac-sha1-96              17                 128      |
-   |   aes256-cts-hmac-sha1-96              18                 256      |
-   +--------------------------------------------------------------------+
-
-   The following checksum type numbers are assigned:
-
-
-
-
-
-Raeburn                                                         [Page 4]
-
-INTERNET DRAFT                                             February 2003
-
-
-   +--------------------------------------------------------------------+
-   |                          checksum types                            |
-   +--------------------------------------------------------------------+
-   |        type name                 sumtype value           length    |
-   +--------------------------------------------------------------------+
-   |    hmac-sha1-96-aes128                15                   96      |
-   |    hmac-sha1-96-aes256                16                   96      |
-   +--------------------------------------------------------------------+
-
-   These checksum types will be used with the corresponding encryption
-   types defined above.
-
-8. Security Considerations
-
-   This new algorithm has not been around long enough to receive the
-   decades of intense analysis that DES has received.  It is possible
-   that some weakness exists that has not been found by the
-   cryptographers analyzing these algorithms before and during the AES
-   selection process.
-
-   The use of the HMAC function has drawbacks for certain pass phrase
-   lengths.  For example, a pass phrase longer than the hash function
-   block size (64 bytes, for SHA-1) is hashed to a smaller size (20
-   bytes) before applying the main HMAC algorithm.  However, entropy is
-   generally sparse in pass phrases, especially in long ones, so this
-   may not be a problem in the rare cases of users with long pass
-   phrases.
-
-   Also, generating a 256-bit key from a pass phrase of any length may
-   be deceptive, since the effective entropy in pass-phrase-derived key
-   cannot be nearly that large.
-
-   The iteration count in PBKDF2 appears to be useful primarily as a
-   constant multiplier for the amount of work required for an attacker
-   using brute-force methods.  Unfortunately, it also multiplies, by the
-   same amount, the work needed by a legitimate user with a valid
-   password.  Thus the work factor imposed on an attacker (who may have
-   many powerful workstations at his disposal) must be balanced against
-   the work factor imposed on the legitimate user (who may have a PDA or
-   cell phone); the available computing power on either side increases
-   as time goes on, as well.  A better way to deal with the brute-force
-   attack is through preauthentication mechanisms that provide better
-   protection of, the user's long-term key.  Use of such mechanisms is
-   out of scope for this document.
-
-   If the PBKDF2 iteration count can be spoofed by an intruder on the
-   network, and the limit on the accepted iteration count is very high,
-   the intruder may be able to introduce a form of denial of service
-
-
-
-Raeburn                                                         [Page 5]
-
-INTERNET DRAFT                                             February 2003
-
-
-   attack against the client by sending a very high iteration count,
-   causing the client to spend a great deal of CPU time computing an
-   incorrect key.
-
-   Any benefit against other attacks specific to the HMAC or SHA-1
-   algorithms is probably achieved with a fairly small number of
-   iterations.
-
-   Cipher text stealing mode, since it requires no additional padding in
-   most cases, will reveal the exact length of each message being
-   encrypted, rather than merely bounding it to a small range of
-   possible lengths as in CBC mode.  Such obfuscation should not be
-   relied upon at higher levels in any case; if the length must be
-   obscured from an outside observer, it should be done by intentionally
-   varying the length of the message to be encrypted.
-
-   The author is not a cryptographer.  Caveat emptor.
-
-9. IANA Considerations
-
-   None.
-
-10. Acknowledgements
-
-   Thanks to John Brezak, Gerardo Diaz Cuellar and Marcus Watts for
-   feedback on earlier versions of this document.
-
-11. Normative References
-
-   [AC] Schneier, B., "Applied Cryptography", second edition, John Wiley
-   and Sons, New York, 1996.
-
-   [AES] National Institute of Standards and Technology, U.S. Department
-   of Commerce, "Advanced Encryption Standard", Federal Information
-   Processing Standards Publication 197, Washington, DC, November 2001.
-
-   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
-   Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002.  Work in
-   progress.
-
-   [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography
-   Specification Version 2.0", RFC 2898, September 2000.
-
-   [RC5] Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
-   RC5-CTS Algorithms", RFC 2040, October 1996.
-
-   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
-   3", RFC 2026, October 1996.
-
-
-
-Raeburn                                                         [Page 6]
-
-INTERNET DRAFT                                             February 2003
-
-
-   [SHA1] National Institute of Standards and Technology, U.S.
-   Department of Commerce, "Secure Hash Standard", Federal Information
-   Processing Standards Publication 180-1, Washington, DC, April 1995.
-
-12. Informative References
-
-   [PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 3211,
-   December 2001.
-
-13. Author's Address
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-   raeburn@mit.edu
-
-14. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-A. Sample test vectors
-
-   Sample values for the string-to-key function are included below.
-
-
-
-Raeburn                                                         [Page 7]
-
-INTERNET DRAFT                                             February 2003
-
-
-   Iteration count = 1
-   Pass phrase = "password"
-   Salt = "ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
-   128-bit AES key:
-       42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15
-   256-bit PBKDF2 output:
-       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
-       0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37
-   256-bit AES key:
-       fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b
-       bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61
-
-   Iteration count = 2
-   Pass phrase = "password"
-   Salt="ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
-   128-bit AES key:
-       c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13
-   256-bit PBKDF2 output:
-       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
-       a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86
-   256-bit AES key:
-       a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61
-       02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff
-
-   Iteration count = 1200
-   Pass phrase = "password"
-   Salt = "ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
-   128-bit AES key:
-       4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a
-   256-bit PBKDF2 output:
-       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
-       a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13
-   256-bit AES key:
-       55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7
-       54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 8]
-
-INTERNET DRAFT                                             February 2003
-
-
-   Iteration count = 5
-   Pass phrase = "password"
-   Salt=0x1234567878563412
-   128-bit PBKDF2 output:
-       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
-   128-bit AES key:
-       e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e
-   256-bit PBKDF2 output:
-       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
-       3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee
-   256-bit AES key:
-       97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c
-       ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31
-   (This test is based on values given in [PECMS].)
-
-   Iteration count = 1200
-   Pass phrase = (64 characters)
-     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
-   Salt="pass phrase equals block size"
-   128-bit PBKDF2 output:
-       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
-   128-bit AES key:
-       59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed
-   256-bit PBKDF2 output:
-       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
-       c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1
-   256-bit AES key:
-       89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0
-       56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34
-
-   Iteration count = 1200
-   Pass phrase = (65 characters)
-     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
-   Salt = "pass phrase exceeds block size"
-   128-bit PBKDF2 output:
-       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
-   128-bit AES key:
-       cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d
-   256-bit PBKDF2 output:
-       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
-       1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a
-   256-bit AES key:
-       d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2
-       14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b
-
-
-
-
-
-
-
-Raeburn                                                         [Page 9]
-
-INTERNET DRAFT                                             February 2003
-
-
-   Iteration count = 50
-   Pass phrase = g-clef (0xf09d849e)
-   Salt = "EXAMPLE.COMpianist"
-   128-bit PBKDF2 output:
-       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
-   128-bit AES key:
-       f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5
-   256-bit PBKDF2 output:
-       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
-       e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52
-   256-bit AES key:
-       4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c
-       57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e
-
-   Some test vectors for CBC with cipher text stealing, using an initial
-   vector of all-zero.
-
-   AES 128-bit key:
-       63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20
-   Output:
-       c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
-       97
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20
-   Output:
-       fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-   Output:
-       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 10]
-
-INTERNET DRAFT                                             February 2003
-
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c
-   Output:
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-       b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
-       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
-   Output:
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-       9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
-       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
-       61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e
-   Output:
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-       48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
-       9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
-
-Document History (delete before RFC publication)
-
-   Major changes from -02 to -03:
-
-   Describe encryption of data of one block or less.
-
-   Fix default string-to-key parameters in table to agree with text.
-
-   Remove Recommendations section; the Kerberos RFC will cover
-   recommendations and requirements.
-
-   Restore change history, added notes to RFC editor saying to remove
-   it, and update the [KCRYPTO] entry in Normative References.
-
-   Delete confounder size, since it's gone from the simplified profile
-   in crypto-03.
-
-   Change checksum numbers, since Assar Westerlund says 10 is in use.
-
-
-
-
-Raeburn                                                        [Page 11]
-
-INTERNET DRAFT                                             February 2003
-
-
-   Add Security Consideration about denial of service caused by very
-   high spoofed iteration count.
-
-   Major changes from -01 to -02:
-
-   Add test vectors.
-
-   Drop 192/384-bit variants.  Prevailing opinion seems to be that
-   128-bit keys are good for speed, and 256-bit for paranoia, and no one
-   cares about the intermediate sizes.
-
-   Update for new string-to-key params per new Kerberos crypto draft and
-   discussions during the IETF conferences at Salt Lake City, December,
-   2001, and Minneapolis, March, 2002.
-
-   Drop Serpent and Twofish; Rijndael is the only one people care about.
-   Use "AES" in preference to "Rijndael".
-
-   Use cipher text stealing mode intead of plain CBC, and add -cts to
-   the algorithm names.
-
-   Drop SHA-2, stick with SHA-1.  New test cases to exercise boundary
-   conditions in HMAC used in string-to-key.
-
-   Split References into Normative/Informative.
-
-   Major changes from -00:
-
-   Define different types based on key/hash sizes, with hash size always
-   twice key size.  Use simplified profile of revised section 6 of
-   RFC1510bis.  Drop "-kd" from the names.
-
-   Use PKCS#5 instead of simple hash.  Changed string-to-key vector to
-   use some "Appendix Z" cases also submitted for kerberos-revisions.
-
-Notes to RFC Editor
-
-   Assuming this document goes through Last Call along with the Kerberos
-   crypto framework draft, the reference entry for [KCRYPTO] will list
-   the draft name, not the RFC number.  This should be replaced with the
-   RFC info.
-
-   The "Document History" section should be deleted, as should this one.
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 12]
diff --git a/doc/standardisation/draft-raeburn-krb-rijndael-krb-05.txt b/doc/standardisation/draft-raeburn-krb-rijndael-krb-05.txt
deleted file mode 100644
index 38ef593a6..000000000
--- a/doc/standardisation/draft-raeburn-krb-rijndael-krb-05.txt
+++ /dev/null
@@ -1,730 +0,0 @@
-
-
-
-
-
-
-
-
-
-Kerberos Working Group                                        K. Raeburn
-Document: draft-raeburn-krb-rijndael-krb-05.txt                      MIT
-                                                           June 20, 2003
-                                               expires December 20, 2003
-
-                     AES Encryption for Kerberos 5
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026 [RFC2026]. 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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-Abstract
-
-   Recently the US National Institute of Standards and Technology chose
-   a new Advanced Encryption Standard, which is significantly faster and
-   (it is believed) more secure than the old DES algorithm.  This
-   document is a specification for the addition of this algorithm to the
-   Kerberos cryptosystem suite.
-
-   Comments should be sent to the author, or to the IETF Kerberos
-   working group (ietf-krb-wg@anl.gov).
-
-1. Introduction
-
-   This document defines encryption key and checksum types for Kerberos
-   5 using the AES algorithm recently chosen by NIST.  These new types
-   support 128-bit block encryption, and key sizes of 128 or 256 bits.
-
-
-
-
-
-
-
-Raeburn                                                         [Page 1]
-
-INTERNET DRAFT                                                 June 2003
-
-
-   Using the "simplified profile" of [KCRYPTO], we can define a pair of
-   encryption and checksum schemes.  AES is used with cipher text
-   stealing to avoid message expansion, and SHA-1 [SHA1] is the
-   associated checksum function.
-
-2. Conventions Used in this Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119.
-
-3. Protocol Key Representation
-
-   The profile in [KCRYPTO] treats keys and random octet strings as
-   conceptually different.  But since the AES key space is dense, we can
-   use any bit string of appropriate length as a key.  We use the byte
-   representation for the key described in [AES], where the first bit of
-   the bit string is the high bit of the first byte of the byte string
-   (octet string) representation.
-
-4. Key Generation From Pass Phrases or Random Data
-
-   Given the above format for keys, we can generate keys from the
-   appropriate amounts of random data (128 or 256 bits) by simply
-   copying the input string.
-
-   To generate an encryption key from a pass phrase and salt string, we
-   use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters
-   indicated below, to generate an intermediate key (of the same length
-   as the desired final key), which is then passed into the DK function
-   with the 8-octet ASCII string "kerberos" as is done for des3-cbc-
-   hmac-sha1-kd in [KCRYPTO].  (In [KCRYPTO] terms, the PBKDF2 function
-   produces a "random octet string", hence the application of the
-   random-to-key function even though it's effectively a simple identity
-   operation.)  The resulting key is the user's long-term key for use
-   with the encryption algorithm in question.
-
-    tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
-    key = DK(tkey, "kerberos")
-
-   The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the
-   passphrase and salt, as described in Appendix B.1 to PKCS#5.
-
-   The number of iterations is specified by the string-to-key parameters
-   supplied.  The parameter string is four octets indicating an unsigned
-   number in big-endian order.  This is the number of iterations to be
-   performed.  If the value is 00 00 00 00, the number of iterations to
-   be performed is 4294967296 (2**32).  (Thus the minimum expressable
-
-
-
-Raeburn                                                         [Page 2]
-
-INTERNET DRAFT                                                 June 2003
-
-
-   iteration count is 1.)
-
-   For environments where slower hardware is the norm, implementations
-   may wish to limit the number of iterations to prevent a spoofed
-   response from consuming lots of client-side CPU time; it is
-   recommended that this bound be no less than 50000.  Even for
-   environments with fast hardware, 4 billion iterations is likely to
-   take a fairly long time; much larger bounds might still be enforced,
-   and it might be wise for implementations to permit interruption of
-   this operation by the user if the environment allows for it.
-
-   If the string-to-key parameters are not supplied, the value used is
-   00 00 10 00 (decimal 4096, indicating 4096 iterations).
-
-   Note that this is NOT a requirement, nor even a recommendation, for
-   this value to be used in "optimistic preauthentication" (e.g.,
-   attempting timestamp-based preauthentication using the user's long-
-   term key, without having first communicated with the KDC) in the
-   absence of additional information, nor as a default value for sites
-   to use for their principals' long-term keys in their Kerberos
-   database.  It is simply the interpretation of the absence of the
-   string-to-key parameter field when the KDC has had an opportunity to
-   provide it.
-
-   Sample test vectors are given in the appendix.
-
-5. Cipher Text Stealing
-
-   Cipher block chaining is used to encrypt messages.  Unlike previous
-   Kerberos cryptosystems, we use cipher text stealing to handle the
-   possibly partial final block of the message.
-
-   Cipher text stealing is described on pages 195-196 of [AC], and
-   section 8 of [RC5]; it has the advantage that no message expansion is
-   done during encryption of messages of arbitrary sizes as is typically
-   done in CBC mode with padding.
-
-   Cipher text stealing, as defined in [RC5], assumes that more than one
-   block of plain text is available.  If exactly one block is to be
-   encrypted, that block is simply encrypted with AES (also known as ECB
-   mode).  Input of less than one block is padded at the end to one
-   block; the values of the padding bits are unspecified.
-   (Implementations may use all-zero padding, but protocols should not
-   rely on the result being deterministic.  Implementations may use
-   random padding, but protocols should not rely on the result not being
-   deterministic.  Note that in most cases, the Kerberos encryption
-   profile will add a random confounder independent of this padding.)
-
-
-
-
-Raeburn                                                         [Page 3]
-
-INTERNET DRAFT                                                 June 2003
-
-
-   For consistency, cipher text stealing is always used for the last two
-   blocks of the data to be encrypted, as in [RC5].  If the data length
-   is a multiple of the block size, this is equivalent to plain CBC mode
-   with the last two cipher text blocks swapped.
-
-   A test vector is given in the appendix.
-
-6. Kerberos Algorithm Profile Parameters
-
-   This is a summary of the parameters to be used with the simplified
-   algorithm profile described in [KCRYPTO]:
-
-   +--------------------------------------------------------------------+
-   |               protocol key format       128- or 256-bit string     |
-   |                                                                    |
-   |            string-to-key function       PBKDF2+DK with variable    |
-   |                                         iteration count (see       |
-   |                                         above)                     |
-   |                                                                    |
-   |  default string-to-key parameters       00 00 10 00                |
-   |                                                                    |
-   |        key-generation seed length       key size                   |
-   |                                                                    |
-   |            random-to-key function       identity function          |
-   |                                                                    |
-   |                  hash function, H       SHA-1                      |
-   |                                                                    |
-   |               HMAC output size, h       12 octets (96 bits)        |
-   |                                                                    |
-   |             message block size, m       1 octet                    |
-   |                                                                    |
-   |  encryption/decryption functions,       AES in CBC-CTS mode with   |
-   |  E and D                                zero ivec (cipher block    |
-   |                                         size 16 octets)            |
-   +--------------------------------------------------------------------+
-
-   Using this profile with each key size gives us two each of encryption
-   and checksum algorithm definitions.
-
-7. Assigned Numbers
-
-   The following encryption type numbers are assigned:
-
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 4]
-
-INTERNET DRAFT                                                 June 2003
-
-
-   +--------------------------------------------------------------------+
-   |                         encryption types                           |
-   +--------------------------------------------------------------------+
-   |         type name                  etype value          key size   |
-   +--------------------------------------------------------------------+
-   |   aes128-cts-hmac-sha1-96              17                 128      |
-   |   aes256-cts-hmac-sha1-96              18                 256      |
-   +--------------------------------------------------------------------+
-
-   The following checksum type numbers are assigned:
-
-   +--------------------------------------------------------------------+
-   |                          checksum types                            |
-   +--------------------------------------------------------------------+
-   |        type name                 sumtype value           length    |
-   +--------------------------------------------------------------------+
-   |    hmac-sha1-96-aes128                15                   96      |
-   |    hmac-sha1-96-aes256                16                   96      |
-   +--------------------------------------------------------------------+
-
-   These checksum types will be used with the corresponding encryption
-   types defined above.
-
-8. Security Considerations
-
-   This new algorithm has not been around long enough to receive the
-   decades of intense analysis that DES has received.  It is possible
-   that some weakness exists that has not been found by the
-   cryptographers analyzing these algorithms before and during the AES
-   selection process.
-
-   The use of the HMAC function has drawbacks for certain pass phrase
-   lengths.  For example, a pass phrase longer than the hash function
-   block size (64 bytes, for SHA-1) is hashed to a smaller size (20
-   bytes) before applying the main HMAC algorithm.  However, entropy is
-   generally sparse in pass phrases, especially in long ones, so this
-   may not be a problem in the rare cases of users with long pass
-   phrases.
-
-   Also, generating a 256-bit key from a pass phrase of any length may
-   be deceptive, since the effective entropy in pass-phrase-derived key
-   cannot be nearly that large.
-
-   The iteration count in PBKDF2 appears to be useful primarily as a
-   constant multiplier for the amount of work required for an attacker
-   using brute-force methods.  Unfortunately, it also multiplies, by the
-   same amount, the work needed by a legitimate user with a valid
-   password.  Thus the work factor imposed on an attacker (who may have
-
-
-
-Raeburn                                                         [Page 5]
-
-INTERNET DRAFT                                                 June 2003
-
-
-   many powerful workstations at his disposal) must be balanced against
-   the work factor imposed on the legitimate user (who may have a PDA or
-   cell phone); the available computing power on either side increases
-   as time goes on, as well.  A better way to deal with the brute-force
-   attack is through preauthentication mechanisms that provide better
-   protection of the user's long-term key.  Use of such mechanisms is
-   out of scope for this document.
-
-   If a site does wish to use this means of protection against a brute-
-   force attack, the iteration count should be chosen based on the
-   facilities expected to be available to an attacker, and the amount of
-   work the attacker should be required to perform to acquire the key or
-   password.
-
-   As an example:
-
-      The author's tests on a 2GHz Pentium 4 system indicated that in
-      one second, nearly 90000 iterations could be done, producing a
-      256-bit key.  This was using the SHA-1 assembly implementation
-      from OpenSSL, and a pre-release version of the PBKDF2 code for
-      MIT's Kerberos package, on a single system.  No attempt was made
-      to do multiple hashes in parallel, so we assume an attacker doing
-      so can probably do at least 100000 iterations per second --
-      rounded up to 2**17, for ease of calculation.  For simplicity, we
-      also assume the final AES encryption step costs nothing.
-
-      Paul Leach estimates [LEACH] that a password-cracking dictionary
-      may have on the order of 2**21 entries, with capitalization,
-      punctuation, and other variations contributing perhaps a factor of
-      2**11, giving a ballpark estimate of 2**32.
-
-      Thus, for a known iteration count N and a known salt string, an
-      attacker with some number of computers comparable to the author's
-      would need roughly N*2**15 CPU seconds to convert the entire
-      dictionary plus variations into keys.
-
-      An attacker using a dozen such computers for a month would have
-      roughly 2**25 CPU seconds available.  So using 2**12 (4096)
-      iterations would mean an attacker with a dozen such computers
-      dedicated to a brute-force attack against a single key (actually,
-      any password-derived keys sharing the same salt and iteration
-      count) would process all the variations of the dictionary entries
-      in four months, and on average, would likely find the user's
-      password in two months.
-
-      Thus, if this form of attack is of concern, an iteration count a
-      few orders of magnitude higher should be chosen, and users should
-      be required to change their passwords every few months.  Perhaps
-
-
-
-Raeburn                                                         [Page 6]
-
-INTERNET DRAFT                                                 June 2003
-
-
-      several orders of magnitude, since many users will tend to use the
-      shorter and simpler passwords (as much as they can get away with,
-      given a site's password quality checks) that the attacker would
-      likely try first.
-
-      Since this estimate is based on currently available CPU power, the
-      iteration counts used for this mode of defense should be increased
-      over time, at perhaps 40%-60% each year or so.
-
-      Note that if the attacker has a large amount of storage available,
-      intermediate results could be cached, saving a lot of work for the
-      next attack with the same salt and a greater number of iterations
-      than had been run at the point where the intermediate results were
-      saved.  Thus, it would be wise to generate a new random salt
-      string when passwords are changed.  The default salt string,
-      derived from the principal name, only protects against the use of
-      one dictionary of keys against multiple users.
-
-   If the PBKDF2 iteration count can be spoofed by an intruder on the
-   network, and the limit on the accepted iteration count is very high,
-   the intruder may be able to introduce a form of denial of service
-   attack against the client by sending a very high iteration count,
-   causing the client to spend a great deal of CPU time computing an
-   incorrect key.
-
-   An intruder spoofing the KDC reply, providing a low iteration count,
-   and reading the client's reply from the network may be able to reduce
-   the work needed in the brute-force attack outlined above.  Thus,
-   implementations may wish to enforce lower bounds on the number of
-   iterations that will be used.
-
-   Since threat models and typical end-user equipment will vary widely
-   from site to site, allowing site-specific configuration of such
-   bounds is recommended.
-
-   Any benefit against other attacks specific to the HMAC or SHA-1
-   algorithms is probably achieved with a fairly small number of
-   iterations.
-
-   In the "optimistic preauthentication" case mentioned in section 3,
-   the client may attempt to produce a key without first communicating
-   with the KDC.  If the client has no additional information, it can
-   only guess as to the iteration count to be used.  Even such
-   heuristics as "iteration count X was used to acquire tickets for the
-   same principal only N hours ago" can be wrong.  Given the
-   recommendation above for increasing the iteration counts used over
-   time, it is impossible to recommend any specific default value for
-   this case; allowing site-local configuration is recommended.  (If the
-
-
-
-Raeburn                                                         [Page 7]
-
-INTERNET DRAFT                                                 June 2003
-
-
-   lower and upper bound checks described above are implemented, the
-   default count for optimistic preauthentication should be between
-   those bounds.)
-
-   Cipher text stealing mode, since it requires no additional padding in
-   most cases, will reveal the exact length of each message being
-   encrypted, rather than merely bounding it to a small range of
-   possible lengths as in CBC mode.  Such obfuscation should not be
-   relied upon at higher levels in any case; if the length must be
-   obscured from an outside observer, it should be done by intentionally
-   varying the length of the message to be encrypted.
-
-   The author is not a cryptographer.  Caveat emptor.
-
-9. IANA Considerations
-
-   None.
-
-10. Acknowledgements
-
-   Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul
-   Leach, Marcus Watts and others for feedback on earlier versions of
-   this document.
-
-A. Sample test vectors
-
-   Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are
-   included below.
-
-   Iteration count = 1
-   Pass phrase = "password"
-   Salt = "ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
-   128-bit AES key:
-       42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15
-   256-bit PBKDF2 output:
-       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
-       0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37
-   256-bit AES key:
-       fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b
-       bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61
-
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 8]
-
-INTERNET DRAFT                                                 June 2003
-
-
-   Iteration count = 2
-   Pass phrase = "password"
-   Salt="ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
-   128-bit AES key:
-       c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13
-   256-bit PBKDF2 output:
-       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
-       a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86
-   256-bit AES key:
-       a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61
-       02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff
-
-   Iteration count = 1200
-   Pass phrase = "password"
-   Salt = "ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
-   128-bit AES key:
-       4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a
-   256-bit PBKDF2 output:
-       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
-       a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13
-   256-bit AES key:
-       55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7
-       54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a
-
-   Iteration count = 5
-   Pass phrase = "password"
-   Salt=0x1234567878563412
-   128-bit PBKDF2 output:
-       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
-   128-bit AES key:
-       e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e
-   256-bit PBKDF2 output:
-       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
-       3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee
-   256-bit AES key:
-       97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c
-       ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31
-   (This test is based on values given in [PECMS].)
-
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 9]
-
-INTERNET DRAFT                                                 June 2003
-
-
-   Iteration count = 1200
-   Pass phrase = (64 characters)
-     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
-   Salt="pass phrase equals block size"
-   128-bit PBKDF2 output:
-       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
-   128-bit AES key:
-       59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed
-   256-bit PBKDF2 output:
-       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
-       c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1
-   256-bit AES key:
-       89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0
-       56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34
-
-   Iteration count = 1200
-   Pass phrase = (65 characters)
-     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
-   Salt = "pass phrase exceeds block size"
-   128-bit PBKDF2 output:
-       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
-   128-bit AES key:
-       cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d
-   256-bit PBKDF2 output:
-       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
-       1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a
-   256-bit AES key:
-       d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2
-       14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b
-
-   Iteration count = 50
-   Pass phrase = g-clef (0xf09d849e)
-   Salt = "EXAMPLE.COMpianist"
-   128-bit PBKDF2 output:
-       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
-   128-bit AES key:
-       f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5
-   256-bit PBKDF2 output:
-       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
-       e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52
-   256-bit AES key:
-       4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c
-       57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e
-
-   Some test vectors for CBC with cipher text stealing, using an initial
-   vector of all-zero.
-
-
-
-
-
-Raeburn                                                        [Page 10]
-
-INTERNET DRAFT                                                 June 2003
-
-
-   AES 128-bit key:
-       63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20
-   Output:
-       c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
-       97
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20
-   Output:
-       fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-   Output:
-       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c
-   Output:
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-       b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
-       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
-   Output:
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-       9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
-       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 11]
-
-INTERNET DRAFT                                                 June 2003
-
-
-   Input:
-       49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-       20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-       68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
-       61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e
-   Output:
-       97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-       39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-       48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
-       9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
-
-Normative References
-
-   [AC] Schneier, B., "Applied Cryptography", second edition, John Wiley
-   and Sons, New York, 1996.
-
-   [AES] National Institute of Standards and Technology, U.S. Department
-   of Commerce, "Advanced Encryption Standard", Federal Information
-   Processing Standards Publication 197, Washington, DC, November 2001.
-
-   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
-   Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002.  Work in
-   progress.
-
-   [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography
-   Specification Version 2.0", RFC 2898, September 2000.
-
-   [RC5] Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
-   RC5-CTS Algorithms", RFC 2040, October 1996.
-
-   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
-   3", RFC 2026, October 1996.
-
-   [SHA1] National Institute of Standards and Technology, U.S.
-   Department of Commerce, "Secure Hash Standard", Federal Information
-   Processing Standards Publication 180-1, Washington, DC, April 1995.
-
-Informative References
-
-   [LEACH] Leach, P., email to IETF Kerberos working group mailing list,
-   5 May 2003, ftp://ftp.ietf.org/ietf-mail-archive/krb-wg/2003-05.mail.
-
-   [PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 3211,
-   December 2001.
-
-
-
-
-
-
-
-Raeburn                                                        [Page 12]
-
-INTERNET DRAFT                                                 June 2003
-
-
-Author's Address
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-   raeburn@mit.edu
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-Notes to RFC Editor
-
-   Assuming this document goes through Last Call along with the Kerberos
-   crypto framework draft, the reference entry for [KCRYPTO] will list
-   the draft name, not the RFC number.  This should be replaced with the
-   RFC info.
-
-   Remove Kerberos working group contact info from the Abstract; it's
-   right for the draft, but not the final RFC.
-
-
-
-
-
-
-Raeburn                                                        [Page 13]
diff --git a/doc/standardisation/draft-raeburn-krb-rijndael-krb-07.txt b/doc/standardisation/draft-raeburn-krb-rijndael-krb-07.txt
deleted file mode 100644
index c0d9ba60d..000000000
--- a/doc/standardisation/draft-raeburn-krb-rijndael-krb-07.txt
+++ /dev/null
@@ -1,959 +0,0 @@
-Kerberos Working Group                                        K. Raeburn
-Document: draft-raeburn-krb-rijndael-krb-07.txt                      MIT
-                                                           July 19, 2004
-                                                expires January 19, 2005
-
-
-                     AES Encryption for Kerberos 5
-
-
-Status of this Memo
-
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 10 of RFC2026.  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."
-
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-
-   The US National Institute of Standards and Technology has chosen a
-   new Advanced Encryption Standard, which is significantly faster and
-   (it is believed) more secure than the old DES algorithm.  This
-   document is a specification for the addition of this algorithm to the
-   Kerberos cryptosystem suite.
-
-
-1. Introduction
-
-
-   This document defines encryption key and checksum types for Kerberos
-   5 using the AES algorithm recently chosen by NIST.  These new types
-   support 128-bit block encryption, and key sizes of 128 or 256 bits.
-
-
-   Using the "simplified profile" of [KCRYPTO], we can define a pair of
-   encryption and checksum schemes.  AES is used with cipher text
-   stealing to avoid message expansion, and SHA-1 [SHA1] is the
-   associated checksum function.
-
-
-
-
-
-
-Raeburn                                                         [Page 1]
-INTERNET DRAFT                                                 July 2004
-
-
-
-2. Conventions Used in this Document
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [KEYWORDS].
-
-
-3. Protocol Key Representation
-
-
-   The profile in [KCRYPTO] treats keys and random octet strings as
-   conceptually different.  But since the AES key space is dense, we can
-   use any bit string of appropriate length as a key.  We use the byte
-   representation for the key described in [AES], where the first bit of
-   the bit string is the high bit of the first byte of the byte string
-   (octet string) representation.
-
-
-4. Key Generation From Pass Phrases or Random Data
-
-
-   Given the above format for keys, we can generate keys from the
-   appropriate amounts of random data (128 or 256 bits) by simply
-   copying the input string.
-
-
-   To generate an encryption key from a pass phrase and salt string, we
-   use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters
-   indicated below, to generate an intermediate key (of the same length
-   as the desired final key), which is then passed into the DK function
-   with the 8-octet ASCII string "kerberos" as is done for des3-cbc-
-   hmac-sha1-kd in [KCRYPTO].  (In [KCRYPTO] terms, the PBKDF2 function
-   produces a "random octet string", hence the application of the
-   random-to-key function even though it's effectively a simple identity
-   operation.)  The resulting key is the user's long-term key for use
-   with the encryption algorithm in question.
-
-
-    tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
-    key = DK(tkey, "kerberos")
-
-
-   The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the
-   passphrase and salt, as described in Appendix B.1 to PKCS#5.
-
-
-   The number of iterations is specified by the string-to-key parameters
-   supplied.  The parameter string is four octets indicating an unsigned
-   number in big-endian order.  This is the number of iterations to be
-   performed.  If the value is 00 00 00 00, the number of iterations to
-   be performed is 4294967296 (2**32).  (Thus the minimum expressable
-   iteration count is 1.)
-
-
-   For environments where slower hardware is the norm, implementations
-   of protocols such as Kerberos may wish to limit the number of
-   iterations to prevent a spoofed response supplied by an attacker from
-
-
-
-
-Raeburn                                                         [Page 2]
-INTERNET DRAFT                                                 July 2004
-
-
-
-   consuming lots of client-side CPU time; if such a limit is
-   implemented, it SHOULD be no less than 50000.  Even for environments
-   with fast hardware, 4 billion iterations is likely to take a fairly
-   long time; much larger bounds might still be enforced, and it might
-   be wise for implementations to permit interruption of this operation
-   by the user if the environment allows for it.
-
-
-   If the string-to-key parameters are not supplied, the value used is
-   00 00 10 00 (decimal 4096, indicating 4096 iterations).
-
-
-   Note that this is not a requirement, nor even a recommendation, for
-   this value to be used in "optimistic preauthentication" (e.g.,
-   attempting timestamp-based preauthentication using the user's long-
-   term key, without having first communicated with the KDC) in the
-   absence of additional information, nor as a default value for sites
-   to use for their principals' long-term keys in their Kerberos
-   database.  It is simply the interpretation of the absence of the
-   string-to-key parameter field when the KDC has had an opportunity to
-   provide it.
-
-
-   Sample test vectors are given in appendix B.
-
-
-5. Cipher Text Stealing
-
-
-   Cipher block chaining is used to encrypt messages.  Unlike previous
-   Kerberos cryptosystems, we use cipher text stealing to handle the
-   possibly partial final block of the message.
-
-
-   Cipher text stealing is described on pages 195-196 of [AC], and
-   section 8 of [RC5]; it has the advantage that no message expansion is
-   done during encryption of messages of arbitrary sizes as is typically
-   done in CBC mode with padding.  Some errata for [RC5] are listed in
-   appendix A, and are considered part of the cipher text stealing
-   technique as used here.
-
-
-   Cipher text stealing, as defined in [RC5], assumes that more than one
-   block of plain text is available.  If exactly one block is to be
-   encrypted, that block is simply encrypted with AES (also known as ECB
-   mode).  Input of less than one block is padded at the end to one
-   block; the values of the padding bits are unspecified.
-   (Implementations MAY use all-zero padding, but protocols MUST NOT
-   rely on the result being deterministic.  Implementations MAY use
-   random padding, but protocols MUST NOT rely on the result not being
-   deterministic.  Note that in most cases, the Kerberos encryption
-   profile will add a random confounder independent of this padding.)
-
-
-   For consistency, cipher text stealing is always used for the last two
-   blocks of the data to be encrypted, as in [RC5].  If the data length
-
-
-
-
-Raeburn                                                         [Page 3]
-INTERNET DRAFT                                                 July 2004
-
-
-
-   is a multiple of the block size, this is equivalent to plain CBC mode
-   with the last two cipher text blocks swapped.
-
-
-   A test vector is given in appendix B.
-
-
-   The initial vector carried out from one encryption for use in a
-   following encryption is the next to last block of the encryption
-   output; this is the encrypted form of the last plaintext block.  When
-   decrypting, the next to last block of the supplied ciphertext is
-   carried forward as the next initial vector.
-
-
-6. Kerberos Algorithm Profile Parameters
-
-
-   This is a summary of the parameters to be used with the simplified
-   algorithm profile described in [KCRYPTO]:
-
-
-   +--------------------------------------------------------------------+
-   |               protocol key format        128- or 256-bit string    |
-   |                                                                    |
-   |            string-to-key function        PBKDF2+DK with variable   |
-   |                                          iteration count (see      |
-   |                                          above)                    |
-   |                                                                    |
-   |  default string-to-key parameters        00 00 10 00               |
-   |                                                                    |
-   |        key-generation seed length        key size                  |
-   |                                                                    |
-   |            random-to-key function        identity function         |
-   |                                                                    |
-   |                  hash function, H        SHA-1                     |
-   |                                                                    |
-   |               HMAC output size, h        12 octets (96 bits)       |
-   |                                                                    |
-   |             message block size, m        1 octet                   |
-   |                                                                    |
-   |  encryption/decryption functions,        AES in CBC-CTS mode       |
-   |  E and D                                 (cipher block size 16     |
-   |                                          octets), with next to     |
-   |                                          last block as CBC-style   |
-   |                                          ivec                      |
-   +--------------------------------------------------------------------+
-
-
-   Using this profile with each key size gives us two each of encryption
-   and checksum algorithm definitions.
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 4]
-INTERNET DRAFT                                                 July 2004
-
-
-
-7. Assigned Numbers
-
-
-   The following encryption type numbers are assigned:
-
-
-   +--------------------------------------------------------------------+
-   |                         encryption types                           |
-   +--------------------------------------------------------------------+
-   |         type name                  etype value          key size   |
-   +--------------------------------------------------------------------+
-   |   aes128-cts-hmac-sha1-96              17                 128      |
-   |   aes256-cts-hmac-sha1-96              18                 256      |
-   +--------------------------------------------------------------------+
-
-
-   The following checksum type numbers are assigned:
-
-
-   +--------------------------------------------------------------------+
-   |                          checksum types                            |
-   +--------------------------------------------------------------------+
-   |        type name                 sumtype value           length    |
-   +--------------------------------------------------------------------+
-   |    hmac-sha1-96-aes128                15                   96      |
-   |    hmac-sha1-96-aes256                16                   96      |
-   +--------------------------------------------------------------------+
-
-
-   These checksum types will be used with the corresponding encryption
-   types defined above.
-
-
-8. Security Considerations
-
-
-   This new algorithm has not been around long enough to receive the
-   decades of intense analysis that DES has received.  It is possible
-   that some weakness exists that has not been found by the
-   cryptographers analyzing these algorithms before and during the AES
-   selection process.
-
-
-   The use of the HMAC function has drawbacks for certain pass phrase
-   lengths.  For example, a pass phrase longer than the hash function
-   block size (64 bytes, for SHA-1) is hashed to a smaller size (20
-   bytes) before applying the main HMAC algorithm.  However, entropy is
-   generally sparse in pass phrases, especially in long ones, so this
-   may not be a problem in the rare cases of users with long pass
-   phrases.
-
-
-   Also, generating a 256-bit key from a pass phrase of any length may
-   be deceptive, since the effective entropy in pass-phrase-derived key
-   cannot be nearly that large, given the properties of the string-to-
-   key function described here.
-
-
-
-
-
-Raeburn                                                         [Page 5]
-INTERNET DRAFT                                                 July 2004
-
-
-
-   The iteration count in PBKDF2 appears to be useful primarily as a
-   constant multiplier for the amount of work required for an attacker
-   using brute-force methods.  Unfortunately, it also multiplies, by the
-   same amount, the work needed by a legitimate user with a valid
-   password.  Thus the work factor imposed on an attacker (who may have
-   many powerful workstations at his disposal) must be balanced against
-   the work factor imposed on the legitimate user (who may have a PDA or
-   cell phone); the available computing power on either side increases
-   as time goes on, as well.  A better way to deal with the brute-force
-   attack is through preauthentication mechanisms that provide better
-   protection of the user's long-term key.  Use of such mechanisms is
-   out of scope for this document.
-
-
-   If a site does wish to use this means of protection against a brute-
-   force attack, the iteration count should be chosen based on the
-   facilities available to both attacker and legitimate user, and the
-   amount of work the attacker should be required to perform to acquire
-   the key or password.
-
-
-   As an example:
-
-
-      The author's tests on a 2GHz Pentium 4 system indicated that in
-      one second, nearly 90000 iterations could be done, producing a
-      256-bit key.  This was using the SHA-1 assembly implementation
-      from OpenSSL, and a pre-release version of the PBKDF2 code for
-      MIT's Kerberos package, on a single system.  No attempt was made
-      to do multiple hashes in parallel, so we assume an attacker doing
-      so can probably do at least 100000 iterations per second --
-      rounded up to 2**17, for ease of calculation.  For simplicity, we
-      also assume the final AES encryption step costs nothing.
-
-
-      Paul Leach estimates [LEACH] that a password-cracking dictionary
-      may have on the order of 2**21 entries, with capitalization,
-      punctuation, and other variations contributing perhaps a factor of
-      2**11, giving a ballpark estimate of 2**32.
-
-
-      Thus, for a known iteration count N and a known salt string, an
-      attacker with some number of computers comparable to the author's
-      would need roughly N*2**15 CPU seconds to convert the entire
-      dictionary plus variations into keys.
-
-
-      An attacker using a dozen such computers for a month would have
-      roughly 2**25 CPU seconds available.  So using 2**12 (4096)
-      iterations would mean an attacker with a dozen such computers
-      dedicated to a brute-force attack against a single key (actually,
-      any password-derived keys sharing the same salt and iteration
-      count) would process all the variations of the dictionary entries
-      in four months, and on average, would likely find the user's
-
-
-
-
-Raeburn                                                         [Page 6]
-INTERNET DRAFT                                                 July 2004
-
-
-
-      password in two months.
-
-
-      Thus, if this form of attack is of concern, an iteration count a
-      few orders of magnitude higher should be chosen, and users should
-      be required to change their passwords every few months.  Perhaps
-      several orders of magnitude, since many users will tend to use the
-      shorter and simpler passwords (as much as they can get away with,
-      given a site's password quality checks) that the attacker would
-      likely try first.
-
-
-      Since this estimate is based on currently available CPU power, the
-      iteration counts used for this mode of defense should be increased
-      over time, at perhaps 40%-60% each year or so.
-
-
-      Note that if the attacker has a large amount of storage available,
-      intermediate results could be cached, saving a lot of work for the
-      next attack with the same salt and a greater number of iterations
-      than had been run at the point where the intermediate results were
-      saved.  Thus, it would be wise to generate a new random salt
-      string when passwords are changed.  The default salt string,
-      derived from the principal name, only protects against the use of
-      one dictionary of keys against multiple users.
-
-
-   If the PBKDF2 iteration count can be spoofed by an intruder on the
-   network, and the limit on the accepted iteration count is very high,
-   the intruder may be able to introduce a form of denial of service
-   attack against the client by sending a very high iteration count,
-   causing the client to spend a great deal of CPU time computing an
-   incorrect key.
-
-
-   An intruder spoofing the KDC reply, providing a low iteration count,
-   and reading the client's reply from the network may be able to reduce
-   the work needed in the brute-force attack outlined above.  Thus,
-   implementations may wish to enforce lower bounds on the number of
-   iterations that will be used.
-
-
-   Since threat models and typical end-user equipment will vary widely
-   from site to site, allowing site-specific configuration of such
-   bounds is recommended.
-
-
-   Any benefit against other attacks specific to the HMAC or SHA-1
-   algorithms is probably achieved with a fairly small number of
-   iterations.
-
-
-   In the "optimistic preauthentication" case mentioned in section 3,
-   the client may attempt to produce a key without first communicating
-   with the KDC.  If the client has no additional information, it can
-   only guess as to the iteration count to be used.  Even such
-
-
-
-
-Raeburn                                                         [Page 7]
-INTERNET DRAFT                                                 July 2004
-
-
-
-   heuristics as "iteration count X was used to acquire tickets for the
-   same principal only N hours ago" can be wrong.  Given the
-   recommendation above for increasing the iteration counts used over
-   time, it is impossible to recommend any specific default value for
-   this case; allowing site-local configuration is recommended.  (If the
-   lower and upper bound checks described above are implemented, the
-   default count for optimistic preauthentication should be between
-   those bounds.)
-
-
-   Cipher text stealing mode, since it requires no additional padding in
-   most cases, will reveal the exact length of each message being
-   encrypted, rather than merely bounding it to a small range of
-   possible lengths as in CBC mode.  Such obfuscation should not be
-   relied upon at higher levels in any case; if the length must be
-   obscured from an outside observer, it should be done by intentionally
-   varying the length of the message to be encrypted.
-
-
-9. IANA Considerations
-
-
-   Kerberos encryption and checksum type values used in section 7 were
-   previously reserved in [KCRYPTO] for the mechanisms defined in this
-   document.  The registries should be updated to list this document as
-   the reference.
-
-
-10. Acknowledgements
-
-
-   Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul
-   Leach, Marcus Watts, Larry Zhu and others for feedback on earlier
-   versions of this document.
-
-
-A. Errata for RFC 2040 section 8
-
-
-   (Copied from the RFC Editor's errata web site on July 8, 2004.)
-
-
-   Reported By: Bob Baldwin; baldwin@plusfive.com
-   Date: Fri, 26 Mar 2004 06:49:02 -0800
-
-
-   In Section 8, Description of RC5-CTS, of the encryption method, it says:
-
-
-       1. Exclusive-or Pn-1 with the previous ciphertext
-          block, Cn-2, to create Xn-1.
-
-
-   It should say:
-
-
-       1. Exclusive-or Pn-1 with the previous ciphertext
-          block, Cn-2, to create Xn-1.  For short messages where
-          Cn-2 does not exist, use IV.
-
-
-
-
-
-Raeburn                                                         [Page 8]
-INTERNET DRAFT                                                 July 2004
-
-
-
-   Reported By: Bob Baldwin; baldwin@plusfive.com
-   Date: Mon, 22 Mar 2004 20:26:40 -0800
-
-
-   In Section 8, first paragraph, second sentence says:
-
-
-       This mode handles any length of plaintext and produces ciphertext
-       whose length matches the plaintext length.
-
-
-   In Section 8, first paragraph, second sentence should read:
-
-
-       This mode handles any length of plaintext longer than one
-       block and produces ciphertext whose length matches the
-       plaintext length.
-
-
-   In Section 8, step 6 of the decryption method says:
-
-
-       6. Decrypt En to create Pn-1.
-
-
-   In Section 8, step 6 of the decryption method should read:
-
-
-       6. Decrypt En and exclusive-or with Cn-2 to create Pn-1.
-          For short messages where Cn-2 does not exist, use the IV.
-
-
-B. Sample test vectors
-
-
-   Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are
-   included below.
-
-
-   Iteration count = 1
-   Pass phrase = "password"
-   Salt = "ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
-   128-bit AES key:
-       42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15
-   256-bit PBKDF2 output:
-       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
-       0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37
-   256-bit AES key:
-       fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b
-       bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                         [Page 9]
-INTERNET DRAFT                                                 July 2004
-
-
-
-   Iteration count = 2
-   Pass phrase = "password"
-   Salt="ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
-   128-bit AES key:
-       c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13
-   256-bit PBKDF2 output:
-       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
-       a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86
-   256-bit AES key:
-       a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61
-       02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff
-
-
-   Iteration count = 1200
-   Pass phrase = "password"
-   Salt = "ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
-   128-bit AES key:
-       4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a
-   256-bit PBKDF2 output:
-       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
-       a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13
-   256-bit AES key:
-       55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7
-       54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a
-
-
-   Iteration count = 5
-   Pass phrase = "password"
-   Salt=0x1234567878563412
-   128-bit PBKDF2 output:
-       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
-   128-bit AES key:
-       e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e
-   256-bit PBKDF2 output:
-       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
-       3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee
-   256-bit AES key:
-       97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c
-       ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31
-   (This test is based on values given in [PECMS].)
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 10]
-INTERNET DRAFT                                                 July 2004
-
-
-
-   Iteration count = 1200
-   Pass phrase = (64 characters)
-     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
-   Salt="pass phrase equals block size"
-   128-bit PBKDF2 output:
-       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
-   128-bit AES key:
-       59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed
-   256-bit PBKDF2 output:
-       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
-       c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1
-   256-bit AES key:
-       89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0
-       56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34
-
-
-   Iteration count = 1200
-   Pass phrase = (65 characters)
-     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
-   Salt = "pass phrase exceeds block size"
-   128-bit PBKDF2 output:
-       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
-   128-bit AES key:
-       cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d
-   256-bit PBKDF2 output:
-       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
-       1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a
-   256-bit AES key:
-       d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2
-       14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b
-
-
-   Iteration count = 50
-   Pass phrase = g-clef (0xf09d849e)
-   Salt = "EXAMPLE.COMpianist"
-   128-bit PBKDF2 output:
-       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
-   128-bit AES key:
-       f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5
-   256-bit PBKDF2 output:
-       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
-       e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52
-   256-bit AES key:
-       4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c
-       57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e
-
-
-   Some test vectors for CBC with cipher text stealing, using an initial
-   vector of all-zero.
-
-
-
-
-
-
-Raeburn                                                        [Page 11]
-INTERNET DRAFT                                                 July 2004
-
-
-
-   AES 128-bit key:
-     0000:  63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69
-
-
-   IV:
-     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-   Input:
-     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-     0010:  20
-   Output:
-     0000:  c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
-     0010:  97
-   Next IV:
-     0000:  c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
-
-
-   IV:
-     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-   Input:
-     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20
-   Output:
-     0000:  fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
-     0010:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5
-   Next IV:
-     0000:  fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
-
-
-   IV:
-     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-   Input:
-     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-   Output:
-     0000:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-     0010:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-   Next IV:
-     0000:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-
-
-   IV:
-     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-   Input:
-     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-     0020:  68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c
-   Output:
-     0000:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-     0010:  b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
-     0020:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5
-   Next IV:
-     0000:  b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
-
-
-
-
-Raeburn                                                        [Page 12]
-INTERNET DRAFT                                                 July 2004
-
-
-
-   IV:
-     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-   Input:
-     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-     0020:  68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
-   Output:
-     0000:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-     0010:  9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
-     0020:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-   Next IV:
-     0000:  9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
-
-
-   IV:
-     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-   Input:
-     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-     0020:  68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
-     0030:  61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e
-   Output:
-     0000:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-     0010:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-     0020:  48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
-     0030:  9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
-   Next IV:
-     0000:  48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
-
-
-Normative References
-
-
-   [AC] Schneier, B., "Applied Cryptography", second edition, John Wiley
-   and Sons, New York, 1996.
-
-
-   [AES] National Institute of Standards and Technology, U.S. Department
-   of Commerce, "Advanced Encryption Standard", Federal Information
-   Processing Standards Publication 197, Washington, DC, November 2001.
-
-
-   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
-   Kerberos 5", draft-ietf-krb-wg-crypto-01.txt, May, 2002.  Work in
-   progress.
-
-
-   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
-   Requirement Levels", RFC 2119, March 1997.
-
-
-   [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography
-   Specification Version 2.0", RFC 2898, September 2000.
-
-
-   [RC5] Baldwin, R, and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and
-
-
-
-
-Raeburn                                                        [Page 13]
-INTERNET DRAFT                                                 July 2004
-
-
-
-   RC5-CTS Algorithms", RFC 2040, October 1996.
-
-
-   [SHA1] National Institute of Standards and Technology, U.S.
-   Department of Commerce, "Secure Hash Standard", Federal Information
-   Processing Standards Publication 180-1, Washington, DC, April 1995.
-
-
-Informative References
-
-
-   [LEACH] Leach, P., email to IETF Kerberos working group mailing list,
-   5 May 2003, ftp://ftp.ietf.org/ietf-mail-archive/krb-wg/2003-05.mail.
-
-
-   [PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 3211,
-   December 2001.
-
-
-Author's Address
-
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-   raeburn@mit.edu
-
-
-IPR notices
-
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 14]
-INTERNET DRAFT                                                 July 2004
-
-
-
-Full Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-Notes to RFC Editor
-
-
-   The reference entry for [KCRYPTO] lists the draft name, not the RFC
-   number.  This should be replaced with the RFC info when available.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                                                        [Page 15] 
\ No newline at end of file
diff --git a/doc/standardisation/draft-richards-otp-kerberos-00.txt b/doc/standardisation/draft-richards-otp-kerberos-00.txt
deleted file mode 100644
index 963136a97..000000000
--- a/doc/standardisation/draft-richards-otp-kerberos-00.txt
+++ /dev/null
@@ -1,728 +0,0 @@
-
-
-
-Network Working Group                                        G. Richards
-Internet-Draft                                      RSA Security UK Ltd.
-Expires: December 4, 2006                                   June 2, 2006
-
-
-                              OTP Kerberos
-                      draft-richards-otp-kerberos-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on December 4, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   The Kerberos protocol provides a framework authenticating a client
-   using the exchange of pre-authentication data.  This document
-   describes the use of this framework to carry out One Time Password
-   (OTP) authentication.
-
-
-
-
-
-
-
-
-Richards                Expires December 4, 2006                [Page 1]
-
-Internet-Draft                OTP Kerberos                     June 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Usage Overview . . . . . . . . . . . . . . . . . . . . . . . .  3
-     2.1.  Pre-Authentication . . . . . . . . . . . . . . . . . . . .  3
-     2.2.  PIN Change . . . . . . . . . . . . . . . . . . . . . . . .  4
-     2.3.  OTP Hardening  . . . . . . . . . . . . . . . . . . . . . .  4
-     2.4.  Key Derivation . . . . . . . . . . . . . . . . . . . . . .  5
-   3.  OTP Kerberos Types . . . . . . . . . . . . . . . . . . . . . .  6
-     3.1.  PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . .  6
-     3.2.  PA-OTP-RESPONSE  . . . . . . . . . . . . . . . . . . . . .  7
-     3.3.  PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . .  8
-     3.4.  PA-ENC-PIN . . . . . . . . . . . . . . . . . . . . . . . .  9
-   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
-     5.1.  Active attacks . . . . . . . . . . . . . . . . . . . . . .  9
-     5.2.  Denial of service attacks  . . . . . . . . . . . . . . . .  9
-     5.3.  Use of Hardening Value . . . . . . . . . . . . . . . . . . 10
-   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
-     6.2.  Informative References . . . . . . . . . . . . . . . . . . 11
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
-   Intellectual Property and Copyright Statements . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richards                Expires December 4, 2006                [Page 2]
-
-Internet-Draft                OTP Kerberos                     June 2006
-
-
-1.  Introduction
-
-   A One-Time Password (OTP) token may be a handheld hardware device, a
-   hardware device connected to a personal computer through an
-   electronic interface such as USB, or a software module resident on a
-   personal computer, which generates one-time passwords that may be
-   used to authenticate a user towards some service.  This document
-   describes an extensions to Kerberos V5 [RFC4120] to support pre-
-   authentication using a OTPs.
-
-   In this proposal, the KDC sends the client information on which token
-   to be used and how the OTP is to be generated.  The client then uses
-   the OTP value instead of the conventional password to generate the
-   timestamp encryption key and sends the encrypted timestamp along with
-   information on the OTP to the KDC in in pre-authentication data of a
-   KRB_AS_REQ.  The KDC then uses the OTP information provided by the
-   client to generate the same encryption key, allowing it to verify the
-   timestamp.
-
-   This proposal is partially based upon previous work on integrating
-   single-use authentication mechanisms into Kerberos [NeZoHo98] and
-   uses the existing password-change extensions to handle PIN change as
-   described in [RFC3244].
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   << This is the first draft of this document and so is liable to
-   change significantly. >>
-
-
-2.  Usage Overview
-
-2.1.  Pre-Authentication
-
-   The approach uses pre-authentication data in KRB_AS_REQ, KRB_AS_REP
-   and KRB_ERROR.  The client begins by sending an initial KRB_AS_REQ to
-   the KDC possibly containing pre-authentication data such as the
-   standard Kerberos password data.  The KDC will then determine in an
-   implementation dependent fashion whether OTP authentication is
-   required and if it is, it will respond with a KRB_ERROR message with:
-
-   o  An error code of KDC_ERR_PREAUTH_REQUIRED
-   o  An e-data field containing PA-DATA with a PA-OTP-CHALLENGE.
-
-   The PA-OTP-CHALLENGE contains information on the type of OTP required
-   and the token to be used to generate it.  The client uses this
-
-
-
-Richards                Expires December 4, 2006                [Page 3]
-
-Internet-Draft                OTP Kerberos                     June 2006
-
-
-   information to locate the token and generate the OTP which is used,
-   instead of the user's password, to generate an encryption key and
-   encrypt a timestamp.
-
-   The encrypted timestamp is then sent to the KDC as pre-auth data in a
-   second KRB_AS_REQ in the standard manner but additional information
-   on the OTP and the key derivation is also sent in a PA-OTP-RESPONSE.
-
-   The KDC then uses the information in the PA-OTP-RESPONSE to generate
-   the same key as the client allowing it to validate the encrypted
-   timestamp.  If the validation succeeds then the KDC returns the TGT
-   in a KRB_AS_REP.
-
-2.2.  PIN Change
-
-   If, following successful validation of a PA-OTP-RESPONSE in a
-   KRB_AS_REQ, the KDC requires that the user changes their PIN then it
-   will return PA-DATA of type PA-OTP-PIN-CHANGE in the KRB_AS_REP.
-   This pre-auth data can be used to return a new PIN to the user if the
-   KDC has updated the PIN or to indicate to the user that they must
-   change their PIN.
-
-   In the latter case, user PIN change shall be handled by a PIN change
-   service supporting the ChangePasswdData in a KRB_AP_REQ as described
-   in [RFC3244].  If such a user PIN change is required then the KDC
-   SHALL return a TGT in the KRB_AS_REP but it is RECOMMENDED that it
-   only issues tickets for the PIN change service until the PIN has been
-   changed.
-
-2.3.  OTP Hardening
-
-   Since OTPs may be relatively short, it is important to slow down an
-   attacker sufficiently so that it is economically unattractive to
-   brute-force search for an OTP given an observed OTP-Kerberos
-   exchange.  One way to do this is to derive the Kerberos user key from
-   the OTP instead of the password in the same manner as described in
-   [RFC3962] but to use a high number of iterated hashes of the OTP in
-   the PBKDF2 key derivation function from [RFC2898].  Another is for
-   the client to include a hardening value unknown to the attacker in
-   the key derivation.
-
-   Unlike the a traditional "salt" value which is normally sent in the
-   clear, this hardening value will instead be transferred from the KDC
-   to the client in encrypted form.  When the client receives a PA-OTP-
-   CHALLENGE from a KDC it will search for an associated hardening
-   value.  If it finds a value then it will use it in the key derivation
-   as specified in Section 2.4.
-
-
-
-
-Richards                Expires December 4, 2006                [Page 4]
-
-Internet-Draft                OTP Kerberos                     June 2006
-
-
-   The use of a hardening value will influence the iteration count used
-   by the client in the random-to-key calculation.  The value sent by
-   the KDC in the s2kparams of the ETYPE-INFO2 pre-authentication type
-   specifies the value used if there is no hardening value stored on the
-   client for the server.  If the client has a hardening value stored
-   for the server, then the iteration count of 1 SHOULD be used as the
-   security of the scheme is provided through the hardening value.  If
-   the client does not have a hardening value stored, then it SHOULD set
-   the iteration count in the key derivation to the maximum value that
-   is both supported by the KDC and permitted by any local policy
-   constraints.  The identifier of any hardening value used and the
-   value of the iteration count are sent by the client to the KDC in a
-   PA-OTP_RESPONSE included in the KRB_AS_REQ.
-
-   When the KDC receives a PA-OTP-RESPONSE, it will use the identifier
-   to locate the hardening value.  If a hardening value is found then it
-   will be used along with the iterationCount to generate the user key.
-   If the hardening value identifier is omitted then only the
-   iterationCount SHALL be used.  If a hardening value identifier is
-   included but the corresponding value could not be found then the KDC
-   SHALL respond with a KDC_ERR_PREAUTH_REQUIRED error as described
-   above but SHALL set the noHardening flag in the PA-OTP-CHALLENGE.
-
-   The hardening value to be used by the client in the next KRB_AS_REQ
-   will be sent by the KDC in a PA-OTP-CONFIRM contained in the
-   KRB_AS_REP.  The inclusion of a PA-OTP-CONFIRM is only REQUIRED if
-   the client did not use a hardening value to generate the timestamp
-   encryption key.  However, it is RECOMMENDED that it be included in
-   all such responses to ensure that a new hardening value is used in
-   all client requests.
-
-2.4.  Key Derivation
-
-   The encryption key used to encrypt the time stamp SHALL be generated
-   using the PBKDF2 password-based key derivation function as specified
-   in [RFC3962].  Conformant KDCs MUST support at least one of the
-   encryption types aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96
-   defined in [RFC3962] and MUST return PA-ETYPE-INFO2 pre-
-   authentication types with the corresponding etype values.
-
-   In order to use the hardening scheme described in Section 2.3, the
-   information provided by the KDC in the ETYPE-INFO2 pre-authentication
-   type SHALL be used by the client as follows:
-
-   o  If the client does not have a hardening value associated with the
-      KDC then the number of iterations specified in the s2kparams SHALL
-      be used.  If the client has a hardening value then an iteration
-      count of 1 SHALL be used instead.
-
-
-
-Richards                Expires December 4, 2006                [Page 5]
-
-Internet-Draft                OTP Kerberos                     June 2006
-
-
-   o  The salt value SHALL have the hardening value concatenated if
-      there is one associated with the KDC.
-
-             tkey = random-to-key(PBKDF2(OTP, salt|hardening,
-                           iteration_count, key_length))
-             key = DK(tkey, "kerberos")
-
-
-3.  OTP Kerberos Types
-
-3.1.  PA-OTP-CHALLENGE
-
-   This is a pre-authentication type sent by the KDC to the client in a
-   KRB_ERROR.  It contains information for the client on how to generate
-   an OTP and how to use the OTP in the generation of the key used to
-   encrypt the pre-authentication data.
-
-             PA-OTP-CHALLENGE ::= SEQUENCE {
-               flags            ChallengeFlags
-               otp-challenge[0] OCTET STRING OPTIONAL,
-               otp-length   [1] INTEGER      OPTIONAL,
-               otp-service  [2] UTF8String   OPTIONAL,
-               otp-keyID    [3] OCTET STRING OPTIONAL,
-               otp-algID    [4] INTEGER      OPTIONAL
-             }
-             ChallengeFlags ::= KerberosFlags
-             -- noHardening (0),
-
-   noHardening
-      If the noHardening flag is set then the client MUST NOT use any
-      stored hardening value in the key derivation.  Instead, it MUST
-      use the iteration count provided by the KDC.
-   otp-challenge
-      The otp-challenge is used by the KDC to send a challenge value for
-      use in the OTP calculation.  The challenge is an optional octet
-      string that SHOULD be uniquely generated for each request it is
-      present in, and SHOULD be eight octets or longer when present.
-      When the challenge is not present, the OTP will be calculated on
-      the current token state only.  The client MAY ignore a provided
-      challenge if and only if the OTP token the client is interacting
-      with is not capable of including a challenge in the OTP
-      calculation.  In this case, KDC policies will determine whether to
-      accept a provided OTP value or not.
-
-
-
-
-
-
-
-
-Richards                Expires December 4, 2006                [Page 6]
-
-Internet-Draft                OTP Kerberos                     June 2006
-
-
-   otp-length
-      The otp-length is used by the KDC to specify the desired length of
-      the generated OTP.
-
-   otp-service
-      An identifier of the service supported by the KDC.  This value can
-      be used by the client to locate information such as the hardening
-      value and OTP key to use.
-
-   otp-keyID
-      The identifier of the OTP key to be used in the OTP calculation.
-      If this value is not present then the client SHOULD use other
-      values such as the otp-service and otp-algiID to locate the
-      appropriate key.
-   otp-algID
-      The identifier of the algorithm to use when generating the OTP.
-
-3.2.  PA-OTP-RESPONSE
-
-   This is a pre-authentication type sent by the client to the KDC in a
-   KRB_AS_REQ containing the encrypted pre-authentication data.  It
-   contains information on the OTP used and how the key was generated
-   that encrypts the pre-authentication data.  This information will
-   then allow the KDC to generate the same key and validate the pre-
-   authentication data.
-
-             PA-OTP-RESPONSE ::= SEQUENCE {
-               iterationCount[0] INTEGER      OPTIONAL,
-               identifier    [1] OCTET STRING OPTIONAL,
-               otp-challenge [2] OCTET STRING OPTIONAL,
-               otp-time      [2] KerberosTime OPTIONAL,
-               otp-counter   [3] OCTET STRING OPTIONAL,
-               otp-format    [4] OTPFormat    OPTIONAL,
-               otp-keyID     [5] OCTET STRING OPTIONAL
-             }
-
-             OTPFormat ::= INTEGER {
-                 decimal(0),
-                 hexadecimal(1),
-                 alphanumeric(2),
-                 binary(3)
-             }
-
-   iterationCount
-      The actual value of the iteration count used by the client in the
-      key derivation.  If omitted then the specified or default
-      iteration count is used.  If present then it will generally be
-      less than the value used in the string-to-key parameters if a
-
-
-
-Richards                Expires December 4, 2006                [Page 7]
-
-Internet-Draft                OTP Kerberos                     June 2006
-
-
-      hardening value is used.
-
-   identifier
-      An octet string identifying the hardening value used by the client
-      in the key derivation.  If omitted then no hardening was used.
-
-   otp-challenge
-      Value used by the client to send the challenge used in the OTP
-      calculation.  It MUST be sent to the KDC if and only if the value
-      would otherwise be unknown to the KDC.  For example, the token or
-      client modified or generated challenge.
-
-   otp-time
-      Value used by the client to send the time used in the OTP
-      calculation.
-
-   otp-counter
-      The counter value used in the OTP calculation.  Use of this
-      element is OPTIONAL but it MAY be used by a client to simplify the
-      OTP calculations of the KDC to contain the counter value as
-      reported by the OTP token.
-
-   otp-format
-      The format of the generated OTP.
-
-   otp-keyID
-      The identifier of the OTP key used.
-
-3.3.  PA-OTP-CONFIRM
-
-   Pre-authentication type returned by the KDC in a KRB_AS_REP if the
-   client requires a new hardening value.
-
-             PA-OTP-CONFIRM ::= SEQUENCE {
-               identifier        OCTET STRING,
-               encHardeningValue EncryptedData  -- EncHardeningValue
-             }
-             EncHardeningValue ::= OCTET STRING SIZE (16..MAX)
-
-   identifier
-      An octet string identifying the hardening value used by the client
-      in the key derivation.
-
-   encHardeningValue
-      The hardening value that the client SHOULD use in future key
-      derivations.  It is encrypted as described in section 5.2.9 of
-      [RFC4120] using the current user key as derived by the KDC from
-      the OTP.
-
-
-
-Richards                Expires December 4, 2006                [Page 8]
-
-Internet-Draft                OTP Kerberos                     June 2006
-
-
-3.4.  PA-ENC-PIN
-
-   Pre-authentication type returned by the KDC in a KRB_AS_REP if the
-   user must change their PIN or if the user's PIN has been changed.
-
-             PA-ENC-PIN     ::= EncryptedData -- PA-ENC-PIN-ENC
-             PA-ENC-PIN-ENC ::= SEQUENCE {
-               flags         PinFlags
-               pin       [0] UTF8String OPTIONAL
-               minLength [1] INTEGER    OPTIONAL
-               maxLength [2] INTEGER    OPTIONAL
-             }
-
-             PinFlags ::= KerberosFlags
-             -- systemSetPin (0)
-
-   If the systemSetPin flag is set then the pin field MUST be present
-   and the presence of this pre-auth type indicates that the user's PIN
-   has been changed to the value contained within the pin field.
-
-   If the pin field is omitted then this pre-auth type indicates that
-   the user must change their PIN using the PIN change service and that
-   the KDC will only issue tickets for the PIN change service until the
-   PIN has been changed.
-
-   If the pin field is present and the systemPin flag is not set then
-   the user must change their PIN subject to the restrictions of the
-   other fields or may alternatively use the returned PIN.
-
-
-4.  IANA Considerations
-
-   A registry may be required for the otp-AlgID values as introduced in
-   Section 3.1.  No other IANA actions are anticipated.
-
-
-5.  Security Considerations
-
-5.1.  Active attacks
-
-   <<TBD: Could an attacker change the iteration count in the PA-
-   ETYPE_INFO2? >>
-
-5.2.  Denial of service attacks
-
-   An active attacker may replace the iteration count value in the PA-
-   OTP-RESPONSE sent by the client to slow down an authentication
-   server.  Authentication servers SHOULD protect against this, e.g. by
-
-
-
-Richards                Expires December 4, 2006                [Page 9]
-
-Internet-Draft                OTP Kerberos                     June 2006
-
-
-   disregarding PA-OTP-RESPONSE elements with an iteration count value
-   higher than some pre- or dynamically- (depending on load) set number.
-
-5.3.  Use of Hardening Value
-
-   As described in Section 2.3, the use of a hardening value will slow
-   down an attacker's search for a matching OTP.  The ability to
-   transfer a hardening value in encrypted form from the KDC to the
-   client means that, even though there may be an initial computational
-   cost for the KDC to authenticate the user due to a high iteration
-   count, subsequent authentications will be efficient, while at the
-   same time more secure, since a pre-shared, 128 bits long, hardening
-   value will not be easily found by an attacker.
-
-   If a client does not have a hardening value for a KDC then it will
-   have to generate the user key using only an iteration count.  An
-   attacker observing such a KRB_AS_REQ may, depending on available
-   resources, be able to successfully attack that request.  Once the
-   correct OTP has been found, eavesdropping on the KDC's PA_OTP_CONFIRM
-   will potentially give the attacker access to the server-provided
-   hardening value.  For this reason, initial exchanges with KDC servers
-   SHOULD occur in a secure environment, and if not, the iteration count
-   MUST be significantly higher than for messages where a pre-shared
-   hardening value is used.  The lifetime of this value must also be
-   calculated with this in mind.  Finally, the value MUST be securely
-   stored by the client and the KDC, associated with the user.
-
-
-6.  References
-
-6.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
-              Specification Version 2.0", RFC 2898, September 2000.
-
-   [RFC3244]  Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows
-              2000 Kerberos Change Password and Set Password Protocols",
-              RFC 3244, February 2002.
-
-   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
-              Encryption for Kerberos 5", RFC 3962, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-
-
-Richards                Expires December 4, 2006               [Page 10]
-
-Internet-Draft                OTP Kerberos                     June 2006
-
-
-6.2.  Informative References
-
-   [NeZoHo98]
-              Neuman, C., Zorn, G., Trostle, J., and K. Horstein,
-              "Integrating Single-use Authentication Mechanisms with
-              Kerberos", draft-ietf-cat-kerberos-password-04 (work in
-              progress), November 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richards                Expires December 4, 2006               [Page 11]
-
-Internet-Draft                OTP Kerberos                     June 2006
-
-
-Author's Address
-
-   Gareth Richards
-   RSA Security UK Ltd.
-   RSA House
-   Western Road
-   Bracknell, Berkshire  RG12 1RT
-   UK
-
-   Email: grichards@rsasecurity.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richards                Expires December 4, 2006               [Page 12]
-
-Internet-Draft                OTP Kerberos                     June 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Richards                Expires December 4, 2006               [Page 13]
-
diff --git a/doc/standardisation/draft-richards-otp-kerberos-01.txt b/doc/standardisation/draft-richards-otp-kerberos-01.txt
deleted file mode 100644
index 5db9c39f8..000000000
--- a/doc/standardisation/draft-richards-otp-kerberos-01.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-
-Network Working Group                                        G. Richards
-Internet-Draft                         RSA, The Security Division of EMC
-Intended status: Standards Track                        October 11, 2006
-Expires: April 14, 2007
-
-
-                              OTP Kerberos
-                     draft-richards-otp-kerberos-01
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 14, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   The Kerberos protocol provides a framework authenticating a client
-   using the exchange of pre-authentication data.  This document
-   describes the use of this framework to carry out One Time Password
-   (OTP) authentication.
-
-
-
-
-
-
-
-Richards                 Expires April 14, 2007                 [Page 1]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Usage Overview . . . . . . . . . . . . . . . . . . . . . . . .  3
-     2.1.  Pre-Authentication . . . . . . . . . . . . . . . . . . . .  3
-     2.2.  PIN Change . . . . . . . . . . . . . . . . . . . . . . . .  4
-     2.3.  Re-Synchronization . . . . . . . . . . . . . . . . . . . .  4
-   3.  Pre-Authentication Protocol Details  . . . . . . . . . . . . .  4
-     3.1.  Shared Secret  . . . . . . . . . . . . . . . . . . . . . .  4
-     3.2.  Client Request . . . . . . . . . . . . . . . . . . . . . .  5
-     3.3.  KDC Challenge  . . . . . . . . . . . . . . . . . . . . . .  5
-     3.4.  Client Response  . . . . . . . . . . . . . . . . . . . . .  7
-     3.5.  Verifying the pre-auth Data  . . . . . . . . . . . . . . .  7
-     3.6.  Updating the Secret  . . . . . . . . . . . . . . . . . . .  9
-   4.  Reply Key Generation Algorithms  . . . . . . . . . . . . . . .  9
-     4.1.  Using the OTP Value Directly . . . . . . . . . . . . . . .  9
-     4.2.  Hardening the OTP Value  . . . . . . . . . . . . . . . . .  9
-       4.2.1.  Using an Iteration Count . . . . . . . . . . . . . . . 10
-       4.2.2.  Using a Shared Secret and OTP  . . . . . . . . . . . . 10
-       4.2.3.  Using a Password and OTP . . . . . . . . . . . . . . . 11
-     4.3.  Generating the Key without the OTP . . . . . . . . . . . . 11
-       4.3.1.  Using the Password . . . . . . . . . . . . . . . . . . 11
-       4.3.2.  Using a Shared Secret  . . . . . . . . . . . . . . . . 11
-   5.  OTP Kerberos Types . . . . . . . . . . . . . . . . . . . . . . 12
-     5.1.  PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 12
-     5.2.  PA-OTP-RESPONSE  . . . . . . . . . . . . . . . . . . . . . 13
-     5.3.  PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 16
-     5.4.  PA-ENC-PIN . . . . . . . . . . . . . . . . . . . . . . . . 16
-     5.5.  OTPChalKeyParam  . . . . . . . . . . . . . . . . . . . . . 17
-     5.6.  OTPRespKeyParam  . . . . . . . . . . . . . . . . . . . . . 18
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
-     7.1.  Active attacks . . . . . . . . . . . . . . . . . . . . . . 19
-     7.2.  Denial of service attacks  . . . . . . . . . . . . . . . . 19
-     7.3.  Use of a Shared Secret Value . . . . . . . . . . . . . . . 19
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
-     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
-     8.2.  Informative References . . . . . . . . . . . . . . . . . . 20
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
-   Intellectual Property and Copyright Statements . . . . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-Richards                 Expires April 14, 2007                 [Page 2]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-1.  Introduction
-
-   A One-Time Password (OTP) token may be a handheld hardware device, a
-   hardware device connected to a personal computer through an
-   electronic interface such as USB or a software module resident on a
-   personal computer.  All these devices generate one-time passwords
-   that may be used to authenticate a user towards some service.  This
-   document describes extensions to Kerberos V5 [RFC4120] to support
-   pre-authentication using an OTP.
-
-   In this proposal, the KDC sends the client a random nonce,
-   information on which OTP token is to be used, how the OTP is to be
-   generated using that token and how the Reply Key is to be generated.
-   The Reply Key is then used to encrypt the nonce value and the
-   encrypted value is returned to the KDC as the pre-authentication
-   data.  Depending on whether the KDC can obtain the OTP value, the OTP
-   value is either used in the generation of the Reply Key or is
-   encrypted using the key and returned to the KDC along with the
-   encrypted nonce.  The encrypted nonce, an optional encrypted OTP
-   value and information on how the Reply Key and OTP value were
-   generated are sent to the KDC and used by the KDC to generate the
-   same Reply Key and decrypt and verify the nonce.
-
-   This proposal is partially based upon previous work on integrating
-   single-use authentication mechanisms into Kerberos [HoReNeZo04] and
-   uses the existing password-change extensions to handle PIN change as
-   described in [RFC3244].
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   << This is an early draft of this document and so is liable to change
-   significantly. >>
-
-
-2.  Usage Overview
-
-2.1.  Pre-Authentication
-
-   The approach uses pre-authentication data in KRB_AS_REQ, KRB_AS_REP
-   and KRB_ERROR.  The client begins by sending an initial KRB_AS_REQ to
-   the KDC that may contain pre-authentication data such as the standard
-   Kerberos password data.  The KDC will then determine, in an
-   implementation dependent fashion, whether OTP authentication is
-   required and if it is, it will respond with a KRB_ERROR message
-   containing a PA-OTP-CHALLENGE in the PA-DATA.
-
-
-
-
-Richards                 Expires April 14, 2007                 [Page 3]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-   The PA-OTP-CHALLENGE contains information on how the OTP should be
-   generated, how the Reply Key should be generated and a nonce.  The
-   client uses this information to locate the token and generate the
-   OTP, generate the Reply Key and then encrypt the nonce using the
-   generated key.  Depending on the type of OTP, the Reply Key may be
-   generated using the OTP value or alternatively, the generated OTP
-   will instead be encrypted along with the nonce using the key.
-
-   The encrypted nonce along with information on how the OTP and Reply
-   Key were generated are then sent to the KDC in a PA-OTP-RESPONSE PA-
-   DATA element.  The KDC then uses this information to generate the
-   same key as the client, allowing it to verify the pre-authentication
-   by decrypting the nonce.  If the validation succeeds then the KDC
-   returns the TGT in a KRB_AS_REP.
-
-2.2.  PIN Change
-
-   If, following successful validation of a PA-OTP-RESPONSE in a
-   KRB_AS_REQ, the KDC requires that the user changes their PIN then it
-   will return PA-DATA of type PA-OTP-PIN-CHANGE in the KRB_AS_REP.
-   This pre-auth data can be used to return a new PIN to the user if the
-   KDC has updated the PIN or to indicate to the user that they must
-   change their PIN.
-
-   In the latter case, user PIN change shall be handled by a PIN change
-   service supporting the ChangePasswdData in a KRB_AP_REQ as described
-   in [RFC3244].  If such a user PIN change is required then the KDC
-   SHALL return a TGT in the KRB_AS_REP but it is RECOMMENDED that it
-   only issues tickets for the PIN change service until the PIN has been
-   changed.
-
-2.3.  Re-Synchronization
-
-   It is possible with time and event-based tokens, that the client and
-   OTP server will loose synchronization.  If, when processing a PA-OTP-
-   RESPONSE, the pre-authentication validation fails for this reason
-   then the KDC SHALL return a KRB_ERROR message containing a PA-OTP-
-   CHALLENGE in the PA-DATA with the "nextOTP" flag set.  The setting of
-   this flag will cause the client to re-try the authentication using
-   the OTP for the next token "state".
-
-
-3.  Pre-Authentication Protocol Details
-
-3.1.  Shared Secret
-
-   The method of deriving the Reply Key shall depend upon:
-
-
-
-
-Richards                 Expires April 14, 2007                 [Page 4]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-   o  Whether the OTP is of sufficiently high entropy to generate the
-      key alone.
-
-   o  Whether the OTP has insufficient entropy and so must be
-      strengthened.
-
-   o  Whether the OTP value used can be obtained by the KDC.
-
-   If the OTP value is of low entropy then it is important to slow down
-   an attacker sufficiently to make it economically unattractive to
-   brute-force search for an OTP given an observed OTP-Kerberos
-   exchange.  If the OTP value cannot be obtained by the KDC then it
-   cannot be used in the derivation of the Reply Key but shall be
-   encrypted using the generated key rather than used to derive the key
-   and so the Reply Key must be derived from some other value.  Both of
-   these issues can be solved using shared secret value known by the
-   client and KDC but unknown to the attacker.
-
-   This protocol supports the following types of secret:
-
-   o  A pre-shared secret can be established between the client and KDC
-      and stored on the client.
-
-   o  Diffie-Hellman key agreement (as defined in [RFC2631]) can be used
-      to establish a shared secret value ZZ.  The server's public key,
-      and the base and prime are stored on the client.
-
-   The pre-shared secret value or the Diffie-Hellman shared secret
-   value, ZZ, are converted to a value of the required length for the
-   encryption scheme's random-to-key function using the n-fold function
-   (both defined in [RFC3961]).
-
-3.2.  Client Request
-
-   The client begins by sending an initial KRB_AS_REQ possibly
-   containing other pre-authentication data.  If the KDC determines that
-   OTP-based pre-authentication is required and the request does not
-   contain a PA-OTP-RESPONSE then it will respond as described in
-   Section 3.3.
-
-   Alternatively, if the client has all the necessary information, it
-   MAY construct a PA-OTP-RESPONSE as described in Section 3.4 and
-   include it in the initial request.
-
-3.3.  KDC Challenge
-
-   If the user is required to authenticate using an OTP then the KDC
-   SHALL respond to the initial KRB_AS_REQ with a KRB_ERROR containing:
-
-
-
-Richards                 Expires April 14, 2007                 [Page 5]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-   o  An error code of KDC_ERR_PREAUTH_REQUIRED
-
-   o  An e-data field containing PA-DATA with a PA-OTP-CHALLENGE.
-
-   The PA-OTP-CHALLENGE SHALL contain a nonce value to be encrypted by
-   the generated Reply Key and it MAY also contain information on how
-   the OTP value is to be generated and information on how the Reply Key
-   is to be generated in an otp-keyParam element.
-
-   Use of the otp-keyParam element is OPTIONAL.  If it is not present
-   the Reply Key SHALL be generated directly from the OTP value as
-   specified in Section 4.1 and the OTP value SHALL NOT be included in
-   the client response.
-
-   If the otp-keyParam element is present and the "sendOTP" flag is set
-   then the OTP value MUST NOT be used in the generation of the Reply
-   Key but it must instead be returned to the KDC encrypted using the
-   key.  The Reply Key MUST be derived using one of the methods
-   described in Section 4.3.  If the "sendOTP" flag is not set then the
-   OTP value is to be used in the key derivation then the client MUST
-   use one of the methods described in Section 4.2.
-
-   The otp-keyParam element will control the use of a shared secret in
-   the key derivation.  If the "noSecret" flag is set the the client
-   MUST NOT use a secret value in the key derivation.  If the "noSecret"
-   flag is not set and secret identifier is present then the client MUST
-   NOT use any other secret value.  If the "noSecret" flag is not set
-   and a secret identifier is not present then the client MAY still use
-   a value if there is a value associated with the KDC.
-
-   If the "noSecret" flag is not set and the client can locate a secret
-   value for the KDC then the Reply Key will be generated using one of
-   the following methods:
-
-   o  If the OTP is to be included in the key derivation then the key
-      SHALL be derived as specified in Section 4.2.2.
-
-   o  If the OTP is to be sent encrypted in the response then the key
-      SHALL be derived as specified in Section 4.3.2.
-
-   If the client fails to find a shared secret for the KDC or the
-   "noSecret" flag was set in the challenge then the Reply Key will be
-   generated using one of the following methods:
-
-   o  If the OTP is to be used in the key derivation then the KDC MAY
-      specify an iteration count.  If such a value is specified then the
-      key SHALL be derived from the OTP as described in Section 4.2.1.
-
-
-
-
-Richards                 Expires April 14, 2007                 [Page 6]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-   o  If the OTP is to be used in the key derivation but an iteration
-      count was not specified then the key SHALL be derived from the OTP
-      value and the user's Kerberos password as described in
-      Section 4.2.3.
-
-   o  If the OTP is to be sent encrypted then the key SHALL be derived
-      from the user's Kerberos password as described in section
-      Section 4.3.1.
-
-3.4.  Client Response
-
-   The client will use the generated Reply Key to encrypt the nonce from
-   the KDC challenge and, if required, to encrypt the OTP value.  This
-   encrypted data SHALL be sent to the KDC in the otp-encData of a PA-
-   OTP-RESPONSE PA-DATA element included in a KRB_AS_REQ.
-
-   This response MAY also include information on how the Reply Key was
-   generated in an optional otp-keyParam element.  The client MUST NOT
-   include this element if the Reply Key was generated directly from the
-   OTP value.  The element MUST be included if the Reply Key was
-   generated using either a secret value or an iteration count and
-   contain the secret identifier and iteration count value.  If the
-   Reply Key was generated using a password then the element MUST be
-   present and MUST be empty.
-
-   The response SHOULD also include information on the generated OTP
-   value.
-
-3.5.  Verifying the pre-auth Data
-
-   If KRB_AS_REQ contains a PA-OTP-RESPONSE then the KDC will then use
-   the information in the otp-keyParam to generate the same Reply Key
-   and decrypt the encrypted nonce contained in the otp-encData.
-
-   If the encrypted OTP value is not included in the otp-encData then
-   the Reply Key was generated using the OTP value.  The KDC SHALL
-   therefore use the OTP information in the PA-OTP-RESPONSE to obtain
-   the OTP value for the user and use the value along with the
-   information in the otp-keyParam to generate the Reply Key. This
-   information SHALL be used as follows:
-
-   o  If the otp-keyParam is not present then the Reply Key SHALL be
-      generated directly from the OTP value as described in Section 4.1.
-
-   o  If the otp-keyParam is present but empty then the Reply Key SHALL
-      be generated using the OTP value and the user's Kerberos Password
-      as described in Section 4.2.3.
-
-
-
-
-Richards                 Expires April 14, 2007                 [Page 7]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-   o  If the otp-keyParam is present and contains a secret identifier
-      then the Reply Key SHALL be generated using the OTP value and the
-      secret value as described in Section 4.2.2.
-
-      If the identified secret value can not be found then the KDC SHALL
-      respond with a KDC_ERR_PREAUTH_REQUIRED error as described above
-      but SHALL set the "noSecret" flag in the PA-OTP-CHALLENGE.
-
-   o  if the otp-keyParam is present and contains an iteration count
-      then the Reply Key shall be generated from the OTP value using the
-      iteration count value as described in Section 4.2.1.
-
-   If the encrypted OTP value is included in the otp-encData then the
-   Reply Key was not generated using the OTP value but was instead used
-   to encrypt the OTP value.  The KDC SHALL therefore use the
-   information in the otp-keyParam to generate the Reply Key and decrypt
-   the OTP value.  It SHALL then validate the decrypted value using the
-   OTP information included in the response and fail the authentication
-   if the value is not valid.
-
-   This Reply Key SHALL be generated as follows:
-
-   o  If the otp-keyParam is not present the the KDC SHALL fail the pre-
-      authentication with an error of KDC_ERR_PREAUTH_FAILED.
-
-      If the otp-keyParam is omitted then the Reply Key was generated
-      directly from the OTP value and so is an error if the OTP value is
-      encrypted using the key.
-
-   o  If the otp-keyParam is present but empty then the Reply Key SHALL
-      be generated using the user's Kerberos Password as described in
-      Section 4.3.1.
-
-   o  If the otp-keyParam is present and contains a secret identifier
-      then the Reply Key SHALL be generated using the secret value as
-      described in Section 4.3.2.
-
-      If the identified secret value can not be found then the KDC SHALL
-      respond with a KDC_ERR_PREAUTH_REQUIRED error as described above
-      but SHALL set the "noSecret" flag in the PA-OTP-CHALLENGE.
-
-   o  If the otp-keyParam is present and contains an iteration count
-      then the KDC SHALL fail the authentication with an error of
-      KDC_ERR_PREAUTH_FAILED.
-
-
-
-
-
-
-
-Richards                 Expires April 14, 2007                 [Page 8]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-3.6.  Updating the Secret
-
-   The secret value can be pre-configured on the client but MAY also be
-   transferred from the KDC to the client in encrypted form in the PA-
-   OTP-CONFIRM of the KRB_AS_REP.  If a client receives a new secret
-   value in this way then it MUST update any stored value associated
-   with the KDC.
-
-
-4.  Reply Key Generation Algorithms
-
-4.1.  Using the OTP Value Directly
-
-   If only the OTP value is to be used then the Reply Key SHALL be
-   generated by passing the OTP value through string-to-key (defined in
-   [RFC3961]).
-
-             K = string-to-key(OTP)
-
-   The salt and additional parameters for string-to-key will be as
-   defined in section 3.1.3 of [RFC4120].
-
-4.2.  Hardening the OTP Value
-
-   If the OTP value requires strengthening then several methods shall be
-   supported.
-
-   o  The OTP can be used on its own in the key derivation but run
-      through an iteration process many times as described in
-      Section 4.2.1.
-
-   o  A secret value, shared between the KDC and client can be used
-      along with the OTP value to derive the key as described in
-      Section 4.2.2.
-
-   o  The user's Kerberos password can be used along with the OTP value
-      in the key derivation as described in Section 4.2.3.
-
-   A shared secret can only be used if the client supports the storing
-   of persistent values and has such a value stored.  The other two
-   methods could be used to establish a secret value or when client are
-   not capable of storing such values.
-
-   <<Is there value in another mode which uses the Kerberos password in
-   conjunction with an iteration-hardened OTP value?>>
-
-
-
-
-
-
-Richards                 Expires April 14, 2007                 [Page 9]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-4.2.1.  Using an Iteration Count
-
-   An initial key is generated by running the OTP value through string-
-   to-key.
-
-             K = string-to-key(OTP)
-
-   The following key generation process is then repeated iteration count
-   times with the resulting key being used as the protocol key for the
-   next iteration.
-
-   A sequence of octets, R, is produced from K by iterating over calls
-   to the function pseudo-random (defined in [RFC3961]) and appending
-   the results until at least the number of bits required by random-to-
-   key have been produced.  If the result of the iteration is longer
-   than the required length then the result shall be truncated.
-
-   The octet string parameter for pseudo-random shall be the ASCII
-   string "CombineA" with the loop number appended.  This string has the
-   following byte value:
-
-      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x41}
-
-   A new key is then generated by running R through random-to-key.
-
-             K = random-to-key(R)
-
-4.2.2.  Using a Shared Secret and OTP
-
-   Two intermediate keys, K1 and K2, shall be generated by running the
-   OTP value once through string-to-key and the shared secret through
-   random-to-key.
-
-             K1 = random-to-key(shared secret)
-             K2 = string-to-key(OTP)
-
-   Two sequences of octets, R1 and R2, are then produced from K1 and K2
-   by iterating over calls to pseudo-random and appending the results
-   until the required number of bits have been generated for random-to-
-   key.  If the result of the iteration is longer than the required
-   length then the result shall be truncated.
-
-   The octet string parameter for pseudo-random shall be the ASCII
-   string "CombineA" for K1 and "CombineB" for K2 with the loop number
-   appended.  These have the following byte values:
-
-
-
-
-
-
-Richards                 Expires April 14, 2007                [Page 10]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x41}
-      {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x42}
-
-   The final key is then generated by combining R1 and R2 using
-   exclusive-OR and running the result through random-to-key.
-
-             K = random-to-key(R1 ^ R2)
-
-   << Check on issue around combining DES keys. >>
-
-4.2.3.  Using a Password and OTP
-
-   Two intermediate keys, K1 and K2, shall be generated by running the
-   OTP and password through string-to-key.
-
-             K1 = string-to-key(Password)
-             K2 = string-to-key(OTP)
-
-   The same process as described in Section 4.2.2 is then used to derive
-   the final reply key.
-
-4.3.  Generating the Key without the OTP
-
-   If the OTP value cannot be used in the derivation of the reply key
-   then this protocol supports the following options:
-
-   o  A secret value, shared between the KDC and client can be used to
-      derive the key as described in Section 4.3.2.
-
-   o  The user's Kerberos password can be used in the key derivation as
-      described in Section 4.3.1.
-
-   A shared secret can only be used if the client supports the storing
-   of persistent values and has such a value stored.  The password-only
-   method could be used to establish a secret value or when clients are
-   not capable of storing such values.
-
-4.3.1.  Using the Password
-
-   The Reply Key SHALL be generated by passing the password value
-   through string-to-key (defined in [RFC3961]).
-
-4.3.2.  Using a Shared Secret
-
-   The reply key shall be generated by running the shared secret value
-   through random-to-key.
-
-             K = random-to-key(shared secret)
-
-
-
-Richards                 Expires April 14, 2007                [Page 11]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-5.  OTP Kerberos Types
-
-5.1.  PA-OTP-CHALLENGE
-
-   This is a pre-authentication type sent by the KDC to the client in a
-   KRB_ERROR.  It contains information for the client on how to generate
-   the OTP and reply key.
-
-             PA-OTP-CHALLENGE ::= SEQUENCE {
-               otp-flags         OTPFlags,
-               otp-nonce         UInt32,
-               otp-etype         INTEGER,
-               otp-track-id  [0] OCTET STRING    OPTIONAL,
-               otp-challenge [1] OCTET STRING    OPTIONAL,
-               otp-length    [2] INTEGER         OPTIONAL,
-               otp-service   [3] UTF8String      OPTIONAL,
-               otp-keyID     [4] OCTET STRING    OPTIONAL,
-               otp-algID     [5] INTEGER         OPTIONAL,
-               otp-keyParam  [6] OTPChalKeyParam OPTIONAL
-             }
-
-             OTPFlags ::= KerberosFlags
-             -- nextOTP (0)
-
-   otp-flags
-      If the "nextOTP" flag is set then the OTP calculated SHALL be
-      based on the next token "state" rather than the current one.  As
-      an example, for a time-based token, this means the next time slot.
-      For an event-based token, this could mean the next counter value,
-      if counter values are used.
-
-   otp-nonce
-      A KDC-supplied nonce value to be encrypted by the client in the
-      PA-OTP-RESPONSE.
-
-   otp-etype
-      The encryption type to be used by the client for all encrypted
-      fields in the PA-OTP-RESPONSE.
-
-   otp-track-id
-      This optional element is used by the KDC to link a client response
-      to the corresponding KDC challenge.  If present, this element MUST
-      be copied by the client to the corresponding element in the PA-
-      OTP-RESPONSE.
-
-
-
-
-
-
-
-Richards                 Expires April 14, 2007                [Page 12]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-   otp-challenge
-      The otp-challenge is used by the KDC to send a challenge value for
-      use in the OTP calculation.  The challenge is an optional octet
-      string that SHOULD be uniquely generated for each request it is
-      present in, and SHOULD be eight octets or longer when present.
-      When the challenge is not present, the OTP will be calculated on
-      the current token state only.  The client MAY ignore a provided
-      challenge if and only if the OTP token the client is interacting
-      with is not capable of including a challenge in the OTP
-      calculation.  In this case, KDC policies will determine whether to
-      accept a provided OTP value or not.
-
-   otp-length
-      The otp-length is used by the KDC to specify the desired length of
-      the generated OTP.
-
-   otp-service
-      An identifier of the service supported by the KDC.  This value can
-      be used by the client to locate information such as the shared
-      secret value and OTP key to use.
-
-   otp-keyID
-      The identifier of the OTP key to be used in the OTP calculation.
-      If this value is not present then the client SHOULD use other
-      values such as the otp-service and otp-algID to locate the
-      appropriate key.
-
-   otp-algID
-      The identifier of the algorithm to use when generating the OTP.
-
-   otp-keyParam
-      Information on how the Reply Key should be generated from the OTP
-      and shared secret.  If the value is not present then the reply key
-      MUST be generated directly from the OTP value.
-
-   <<TBD: Should a checksum be added to allow the client to verify the
-   challenge?>>
-
-5.2.  PA-OTP-RESPONSE
-
-   This is a pre-authentication type sent by the client to the KDC in a
-   KRB_AS_REQ containing the encrypted pre-authentication data.  It
-   contains information on the OTP used and how the key was generated
-   that encrypts the pre-authentication data.  This information will
-   then allow the KDC to generate the same key and validate the pre-
-   authentication data.
-
-
-
-
-
-Richards                 Expires April 14, 2007                [Page 13]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-             PA-OTP-RESPONSE ::= SEQUENCE {
-               otp-flags         OTPFlags,
-               otp-nonce         UInt32,
-               otp-encData       EncryptedData,
-                                      -- PA-ENC-RESPONSE
-                                      -- Key usage of <<TBD>>
-               otp-track-id  [0] OCTET STRING    OPTIONAL,
-               otp-challenge [1] OCTET STRING    OPTIONAL,
-               otp-time      [2] KerberosTime    OPTIONAL,
-               otp-counter   [3] OCTET STRING    OPTIONAL,
-               otp-format    [4] OTPFormat       OPTIONAL,
-               otp-keyID     [5] OCTET STRING    OPTIONAL,
-               otp-keyParam  [6] OTPRespKeyParam OPTIONAL
-             }
-
-
-
-             OTPFormat ::= INTEGER {
-               decimal(0),
-               hexadecimal(1),
-               alphanumeric(2),
-               binary(3)
-             }
-
-
-
-             PA-ENC-RESPONSE ::= SEQUENCE {
-               nonce     OCTET STRING OPTIONAL,
-               otp   [0] OCTET STRING OPTIONAL
-             }
-
-   otp-flags
-      If the "nextOTP" flag is set then the OTP was calculated based on
-      the next token "state" rather than the current one.  This flag
-      MUST be set if and only if it was set in a corresponding PA-OTP-
-      CHALLENGE.
-
-   otp-nonce
-      The nonce value encrypted in the otp-encData.  If the PA-OTP-
-      RESPONSE is sent as a result of a PA-OTP_CHALLENGE then the value
-      MUST be a copy of the corresponding value in the challenge.  If no
-      challenge was received then the nonce value MUST be generated by
-      the client.
-
-
-
-
-
-
-
-
-Richards                 Expires April 14, 2007                [Page 14]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-   otp-track-id
-      This element MUST be included if and only if an otp-track-id was
-      included in the corresponding PA-OTP-CHALLENGE.  If included, then
-      the value MUST be copied from the PA-OTP-CHALLENGE.
-
-   otp-challenge
-      Value used by the client to send the challenge used in the OTP
-      calculation.  It MUST be sent to the KDC if and only if the value
-      would otherwise be unknown to the KDC.  For example, the token or
-      client modified or generated challenge.
-
-   otp-time
-      Value used by the client to send the time used in the OTP
-      calculation.
-
-   otp-counter
-      The counter value used in the OTP calculation.  Use of this
-      element is OPTIONAL but it MAY be used by a client to simplify the
-      OTP calculations of the KDC to contain the counter value as
-      reported by the OTP token.
-
-   otp-format
-      The format of the generated OTP.
-
-   otp-keyID
-      The identifier of the OTP key used.
-
-   otp-keyParam
-      Information on how the reply key was generated from the OTP and
-      shared secret.  If the value is not present then the reply key was
-      generated directly from the OTP value.
-
-   otp-encData
-      The otp-encData field contains the result of the pre-
-      authentication process and is encrypted using the generated Reply
-      Key. The fields of this element are populated as follows:
-
-      nonce
-         The value of otp-nonce.
-
-      otp
-         The generated OTP value.  Present if the "sendOTP" flag is set
-         in the challenge.
-
-   <<TBD: Does the response need something such as an encrypted
-   timestamp to protect against replay?>>
-
-
-
-
-
-Richards                 Expires April 14, 2007                [Page 15]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-5.3.  PA-OTP-CONFIRM
-
-   This is a pre-authentication type returned by the KDC in a KRB_AS_REP
-   if the client requires a new shared secret value.  The value is
-   encrypted as described in section 5.2.9 of [RFC4120] using the
-   current reply key as derived by the KDC from the OTP.
-
-             PA-OTP-CONFIRM ::= SEQUENCE {
-               identifier      OCTET STRING,
-               newSecretValue  EncryptedData  -- OTPNewSecret
-                                              -- Key usage of <<TBD>>
-             }
-
-             OTPNewSecret ::= CHOICE {
-               sharedSecret [0] OCTET STRING,
-               dhParams     [1] DHParam
-             }
-
-             DHParam ::= SEQUENCE {
-               dhParameter DHParameter,
-               dhPublic    INTEGER
-             }
-
-   identifier
-      An octet string identifying the new secret value.
-
-   newSecretValue
-      The new secret data encrypted using the current Reply Key. The
-      encrypted data can be of one of the following types:
-
-      sharedSecret
-         A random bit string.
-
-      dhParams
-         A Diffie-Hellman public value, prime and modulus.
-
-5.4.  PA-ENC-PIN
-
-   Pre-authentication type returned by the KDC in a KRB_AS_REP if the
-   user must change their PIN or if the user's PIN has been changed.
-
-
-
-
-
-
-
-
-
-
-
-Richards                 Expires April 14, 2007                [Page 16]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-             PA-ENC-PIN     ::= EncryptedData -- PA-ENC-PIN-ENC
-                                              -- Key usage of <<TBD>>
-             PA-ENC-PIN-ENC ::= SEQUENCE {
-               flags         PinFlags,
-               pin       [0] UTF8String OPTIONAL,
-               minLength [1] INTEGER    OPTIONAL,
-               maxLength [2] INTEGER    OPTIONAL
-             }
-
-             PinFlags ::= KerberosFlags
-               -- systemSetPin (0)
-
-   If the "systemSetPin" flag is set then the user's PIN has been
-   changed and the new PIN value is contained in the pin field.  The PIN
-   field MUST therefore be present.
-
-   If the "systemSetPin" flag is not set then the user's PIN has not
-   been changed by the server but it MUST instead be changed by the user
-   using the PIN change service.  Restrictions on the size of the PIN
-   MAY be given by the minLength and maxLength fields.  If the pin field
-   is present then it contains a PIN value that MAY be used by the user
-   when changing the PIN.  The KDC MAY only issue tickets for the PIN
-   change service until the PIN has been changed.
-
-5.5.  OTPChalKeyParam
-
-   This data type can optionally be included by the KDC in a PA-OTP-
-   CHALLENGE to instruct the client on how to generate the reply key.
-
-   This value is included in the challenge if the OTP generated by the
-   token is too weak to be used alone in the generation of the key.
-
-             OTPChalKeyParam ::= SEQUENCE {
-               flags              ChallengeFlags,
-               identifer      [0] OCTET STRING OPTIONAL,
-               iterationCount [1] INTEGER OPTIONAL
-             }
-
-             ChallengeFlags ::= KerberosFlags
-               -- sendOTP  (0)
-               -- noSecret (1)
-
-   flags
-      Flags controlling the generation of the Reply Key.
-
-
-
-
-
-
-
-Richards                 Expires April 14, 2007                [Page 17]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-      sendOTP
-         If the "sendOTP" flag is set then the client MUST NOT use the
-         OTP value to generate the reply key.  It must instead use the
-         generated key to encrypt the OTP value and include the
-         encrypted value in the PA-OTP-RESPONSE.
-
-      noSecret
-         If the "noSecret" flag is set then the client MUST NOT use any
-         stored secret value in the derivation of the Reply Key. If the
-         "sendOTP" flag is also set then the Kerberos password MUST be
-         used.  If the "sendOTP" flag is not set then the iteration
-         count MUST be used if it is present or the Kerberos password
-         MUST be used if the iteration count is not specified.
-
-   identifier
-      Name of the secret that the client SHOULD use to generate the
-      reply key.
-
-      If a secret is specified but cannot be located by the client and
-      an iteration count is specified then the client should generate
-      the key using the iteration count.  If a secret value is specified
-      and cannot be located and an iteration count is not specified then
-      the reply key MUST be generated using the user's Kerberos
-      password.
-
-   iterationCount
-      This value contains the iteration count to use when the generated
-      OTP value is used in the derivation of the reply key.  This value
-      is used by the client if a shared secret is not specified or is
-      specified but cannot be found.  The value has no meaning if the
-      "sendOTP" flag is set.
-
-5.6.  OTPRespKeyParam
-
-   This data type can optionally be included by the client in a PA-OTP-
-   RESPONSE to inform the KDC of how the reply key was generated.
-
-             OTPRespKeyParam ::= SEQUENCE {
-               iterationCount [0] INTEGER OPTIONAL,
-               secret SEQUENCE {
-                 identifier       OCTET STRING,
-                 dhPublic     [1] INTEGER OPTIONAL
-               }
-             }
-
-
-
-
-
-
-
-Richards                 Expires April 14, 2007                [Page 18]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-   iterationCount
-      The actual value of the iteration count used by the client in the
-      key derivation.  If omitted then no iteration was used in the
-      derivation of the reply key.
-
-   secret
-      Information on the secret used in the key derivation.  If this
-      value is omitted then no shared secret was used.
-
-      identifier
-         An octet string identifying the shared secret value used by the
-         client in the key derivation.
-      dhPublic
-         The client's Diffie-Hellman public key.  Present only if a
-         Diffie-Hellman secret was used.
-
-
-6.  IANA Considerations
-
-   A registry may be required for the otp-AlgID values as introduced in
-   Section 5.1.  No other IANA actions are anticipated.
-
-
-7.  Security Considerations
-
-7.1.  Active attacks
-
-   <<TBS >>
-
-7.2.  Denial of service attacks
-
-   An active attacker may replace the iteration count value in the PA-
-   OTP-RESPONSE sent by the client to slow down an authentication
-   server.  Authentication servers SHOULD protect against this, e.g. by
-   disregarding PA-OTP-RESPONSE elements with an iteration count value
-   higher than some pre- or dynamically- (depending on load) set number.
-
-7.3.  Use of a Shared Secret Value
-
-   As described in Section 3.1, the use of a shared secret value will
-   slow down an attacker's search for a matching OTP.  The ability to
-   transfer such a value in encrypted form from the KDC to the client
-   means that, even though there may be an initial computational cost
-   for the KDC to authenticate the user if an iteration count is used,
-   subsequent authentications will be efficient, while at the same time
-   more secure, since a pre-shared, value will not be easily found by an
-   attacker.
-
-
-
-
-Richards                 Expires April 14, 2007                [Page 19]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-   If a client does not have a pre-configured secret value for a KDC
-   then it will have to generate the Reply Key using an iteration count
-   or the Kerberos password.  If an iteration count is used then an
-   attacker observing such a KRB_AS_REQ may, depending on available
-   resources, be able to successfully attack that request.  Once the
-   correct OTP has been found, eavesdropping on the KDC's PA_OTP_CONFIRM
-   will potentially give the attacker access to the server-provided
-   secret value.  For this reason, initial exchanges with KDC servers
-   SHOULD occur in a secure environment and the lifetime of this value
-   must also be calculated with this in mind.  Finally, the value MUST
-   be securely stored by the client and the KDC, associated with the
-   user.
-
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
-              RFC 2631, June 1999.
-
-   [RFC3244]  Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows
-              2000 Kerberos Change Password and Set Password Protocols",
-              RFC 3244, February 2002.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-8.2.  Informative References
-
-   [HoReNeZo04]
-              Horstein, K., Renard, K., Neuman, C., and G. Zorn,
-              "Integrating Single-use Authentication Mechanisms with
-              Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in
-              progress), July 2004.
-
-
-
-
-
-
-
-
-
-Richards                 Expires April 14, 2007                [Page 20]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-Author's Address
-
-   Gareth Richards
-   RSA, The Security Division of EMC
-   RSA House
-   Western Road
-   Bracknell, Berkshire  RG12 1RT
-   UK
-
-   Email: grichards@rsa.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richards                 Expires April 14, 2007                [Page 21]
-
-Internet-Draft                OTP Kerberos                  October 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Richards                 Expires April 14, 2007                [Page 22]
-
diff --git a/doc/standardisation/draft-sakane-krb-cross-problem-statement-01.txt b/doc/standardisation/draft-sakane-krb-cross-problem-statement-01.txt
deleted file mode 100644
index d70f3c9dc..000000000
--- a/doc/standardisation/draft-sakane-krb-cross-problem-statement-01.txt
+++ /dev/null
@@ -1,731 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                                 S. Sakane
-Expires: April 29, 2007                          Yokogawa Electric Corp.
-                                                               S. Zrelli
-                                                                   JAIST
-                                                             M. Ishiyama
-                                                           Toshiba Corp.
-                                                        October 26, 2006
-
-
-             Problem statement on the cross-realm operation
-                    of Kerberos in a specific system
-            draft-sakane-krb-cross-problem-statement-01.txt
-
-
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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".
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-   This Internet-Draft expires in April 29, 2007.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-
-
-
-
-
-S.Sakane, et al.                                                [Page 1]
-
-Internet-Draft                                              October 2006
-
-
-Abstract
-
-   There are some issues when the cross-realm operation of the Kerberos
-   Version 5 [RFC4120] is employed into the specific systems.  This
-   document describes some manners of the real example, and lists
-   requirements of the operation in such real system.  Then it clarifies
-   issues when we apply the cross-realm operation to such specific
-   system.
-
-
-
-Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [RFC2119].
-
-   It is assumed that the readers are familiar with the terms and
-   concepts described in the Kerberos Version 5 [RFC4120].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-S.Sakane, et al.                                                [Page 2]
-
-Internet-Draft                                              October 2006
-
-
-Table of Contents
-
-    1. Introduction .................................................  4
-    2. Kerberos system ..............................................  4
-       2.1. Kerberos basic operation ................................  4
-       2.2. Cross-realm operation ...................................  5
-    3. Manner of operations in the real environment .................  6
-    4. Requirement ..................................................  7
-    5. Issues .......................................................  8
-       5.1. Scalability of the direct trust model ...................  8
-       5.2. Exposure to DoS Attacks .................................  8
-       5.3. No PFS in case of the indirect trust model ..............  9
-       5.4. Unreliability of authentication chain ...................  9
-       5.5. Client's performance ....................................  9
-       5.6. Pre-authentication problem in roaming scenarios ......... 10
-    6. Implementation consideration ................................. 10
-    7. IANA Considerations .......................................... 11
-    8. Security Considerations ...................................... 11
-    9. Acknowledgments .............................................. 11
-   10. References ................................................... 11
-       10.1. Normative References ................................... 11
-       10.2. Informative References ................................. 11
-   Authors' Addresses ............................................... 12
-   Full Copyright Statement ......................................... 12
-   Intellectual Property Statement .................................. 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-S.Sakane, et al.                                                [Page 3]
-
-Internet-Draft                                              October 2006
-
-
-1.  Introduction
-
-   The Kerberos Version 5 is a widely deployed mechanism that a server
-   can authenticate a client access.  Each client belongs to a managed
-   domain called realm.  Kerberos supports the authentication in case of
-   situation that a client and a server belong to different realms.
-   This is called the cross-realm operation.
-
-   Meanwhile, there are lots of manners of operation in the real system,
-   where Kerberos could be applied.  Sometimes, there are several
-   managed domain in such system.  and it requires the authentication
-   mechanism over the different managed domains.  When the cross-realm
-   operation of Kerberos is applied to such specific systems, some
-   issues come out.
-
-   This document briefly describes the Kerberos Version 5 system and the
-   cross-realm operation.  Then, it describes two real systems that can
-   be applied the Kerberos system, and describes nine requirements of
-   those systems in term both of management and operation.  Finally, it
-   lists six issues of the cross-realm operation when it is applied to
-   those system.
-
-   Note that it might not describe whole of issues of the cross-realm
-   operation.  It also does not propose any solution to solve issues
-   described in this document.  In further step, we have to analyze, and
-   compare candidates of solutions.  This work will be in another
-   document.
-
-   This document is assumed that the readers are familiar with the terms
-   and concepts described in the Kerberos Version 5 [RFC4120].
-
-
-2.  Kerberos system
-
-
-2.1.  Kerberos basic operation
-
-   Kerberos [RFC4120] is a widely deployed authentication system.  The
-   authentication process in Kerberos involves principals and a Key
-   Distribution Center (KDC).  The principals can be users or services.
-   Each KDC maintains a principals database and shares a secret key with
-   each registered principal.
-
-   The authentication process allows a user to acquire the needed
-   credentials from the KDC.  These credentials allow services to
-   authenticate the users before granting them access to the resources.
-   An important part of the credentials are called Tickets.  There are
-   two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket.
-
-
-
-S.Sakane, et al.                                                [Page 4]
-
-Internet-Draft                                              October 2006
-
-
-   The TGT is obtained periodically from the KDC and has a limited limit
-   after which it expires and the user must renew it.  The TGT is used
-   to obtain the other kind of tickets, Service Tickets.  The user
-   obtains a TGT from the Authentication Service (AS), a logical
-   component of the KDC.  The process of obtaining a TGT is referred to
-   as 'AS exchange'.  When a TGT request is issued by an user, the AS
-   responds by sending a reply packet containing the credentials which
-   consists of the TGT along with a random key called 'TGS Session Key'.
-   The TGT contains a set of information encrypted using a secret key
-   associated with a special service referred to as TGS (Ticket Granting
-   Service).  The TGS session key is encrypted using the user's key so
-   that the user can obtain the TGS session key only if she knows the
-   secret key shared with the KDC.  The TGT then is used to obtain
-   Service Tickets from the Ticket Granting Service (TGS)- the second
-   component of the KDC.  The process of obtaining service tickets is
-   referred to as 'TGS exchange'.  The request for a service ticket
-   consists on a packet containing a TGT and an 'Authenticator'.  The
-   Authenticator is encrypted using the TGS session key and contains the
-   identity of the user as well as time stamps (for protection against
-   replay attacks).  After decrypting the TGT (which was encrypted by
-   the AS using the TGS's secret key), the TGS extracts the TGS session
-   key.  Using that session key, it decrypts the Authenticator and
-   authenticates the user.  Then, the TGS issues credentials requested
-   by the user.  These credentials consist on a service ticket and a
-   session key that will be used to authenticate the user with the
-   desired application service.
-
-
-2.2.  Cross-realm operation
-
-   The Kerberos protocol provides the cross-realm authentication
-   capabilities.  This allows users to obtain service tickets to access
-   services in foreign realms.  In order to access such services, the
-   users first contact their home KDC asking for a TGT that will be used
-   with the TGS of the foreign realm.  If the home realm and the foreign
-   realm share keys and have an established trust relationship, the home
-   KDC delivers the requested TGT.
-
-   However, if the home realm does not share cross-realm keys with the
-   foreign realm, the home KDC will provide a TGT that can be used with
-   an intermediary foreign realm that is likely to be sharing cross-
-   realm keys with the target realm.  The client can use this
-   'intermediary TGT' to communicate with the intermediary KDC which
-   will iterate the actions taken by the home KDC: If the intermediary
-   KDC does not share cross-realm keys with the target foreign realm it
-   will point the user to another intermediary KDC (just as in the first
-   exchange between the user and its home KDC).  However, in the other
-   case (when it shares cross- realm keys with the target realm), the
-
-
-
-S.Sakane, et al.                                                [Page 5]
-
-Internet-Draft                                              October 2006
-
-
-   intermediary KDC will issue a TGT that can be used with the KDC of
-   the target realm.  After obtaining a TGT for the desired foreign
-   realm, the client uses it to obtain service tickets from the TGS of
-   the foreign realm.  Finally, the user access the service using the
-   service ticket.
-
-   When the realms belong to the same institution, a chain of trust can
-   be determined by the client or the KDC by following the DNS domain
-   hierarchy and supposing that the parent domains share keys with all
-   its child sub-domains.  However, because the inter-realm trust model
-   is not necessarily constructing the hierarchic approach anytime, the
-   trust path must be specified manually.  When intermediary realms are
-   involved, the success of the cross-realm operation completely depends
-   on the realms that are part of the authentication path.
-
-
-3.  Manner of operations in the real environment
-
-   This section describes examples of operation in the real environment.
-   And it also describes its requirement in term of both management and
-   operation.  These requirements make the issues easier understanding.
-   We refers to the world's largest petrochemical company [SHELLCHEM].
-   It produces bulk petrochemicals and their delivery to large
-   industrial customers.  There are 43 typical plants of the company all
-   over the world.  They are managed by the operation sites placed in 35
-   countries.  This section shows two examples of them.
-
-   One is the CSPC (CNOOC and Shell Petrochemical Company Limited)
-   [CSPC], an example of the centralized plant.  The CSPC is a joint
-   enterprise of CNOOC and SHELL.  Its plant is one of the hugest
-   systems of a petrochemical industry placed in the area of 3.4 square
-   meters in the north coast of Daya Bay, Guangdong, which is at the
-   southeast of China.  3,000 network segments are established in the
-   system.  16,000 control devices are connected to the local area
-   network.  These devices belong to different 9 sub systems, A control
-   device has some control points, which are controlled and monitored by
-   other devices remotely.  There are 200,000 control points in all.
-   They are controlled by 3 different control center.
-
-   Another is the NAM (Nederlandse Aardolie Maatschappij), an example of
-   the distributed plant system.  The NAM is a partnership enterprise of
-   Shell and Exxon.  It is a plant system group that geographically
-   distributes to scatter in the area of 863 square meters of
-   Netherlands.  26 plants, each is named "cluster", are scattered in
-   the area.  They are connected each other by a private ATM WAN.  Each
-   cluster has approximately 500-1,000 control devices.  These devices
-   are managed by each local control center in each cluster.  In the
-   entire system of the NAM, there are one million control points.
-
-
-
-S.Sakane, et al.                                                [Page 6]
-
-Internet-Draft                                              October 2006
-
-
-   The end control devices in the both of the systems are basically
-   connected to a local network by a twisted pair cable, which is a low
-   band-width of 32 kbps.  Every system supposes that no ad-hoc device
-   is never connected to the system since they are well designed before
-   they are implemented.  Low clock CPU, for example H8 [RNSS-H8] and
-   M16C [RNSS-M16C], are employed by many control devices.  Furthermore,
-   to suppress power consumption, these CPU may be lowered the number of
-   clocks.  A controller in this system collects condition of device
-   from multiple control devices, and the system uses them to make a
-   decision how to control devices.  If it took time for data to reach,
-   they could not be associated.  The travel time of data from the
-   device to the controller is demanded within 1 second.  A part of the
-   operation, like control of these system, maintenance, and the
-   environmental monitoring, is consigned to an external organization.
-   Agents who are consigned walk around the plant to get their
-   information, or watch the plant from a remote site.  Currently, each
-   plant is independently operated.  However, it is not impossible to
-   monitor and control all of plants distributed in the world.
-
-
-4.  Requirement
-
-   This section listed requirements derived from the previous section.
-   There are seven requirements in term of management domain separation.
-
-   A-1  It is necessary to allow different independent management
-        domains to coexist because two or more organizations enter to
-        the system.
-
-   A-2  It is necessary to allow a management domain to delegate its
-        management authority to its sub domains or another management
-        domain because the plants are distributed to the wide area.
-
-   A-3  It is necessary that a device controls other devices that belong
-        to a same domain from remote because the plants are distributed
-        to the wide area.
-
-   A-4  It is necessary that a device controls other devices that belong
-        to a different domain from local.
-
-   A-5  It is necessary that a device controls other devices that belong
-        to a different domain from remote.
-
-   A-6  It is necessary for the agents who are consigned to watch and
-        control the device at the plant, which is different domain from
-        the agents' one.
-
-   Because of above requirements, the cross-realm operation of Kerberos
-
-
-
-S.Sakane, et al.                                                [Page 7]
-
-Internet-Draft                                              October 2006
-
-
-   seems suitable for this system.  The requirements derived from other
-   viewpoints is listed as follows.
-
-   B-1  It is demanded to reduce the management cost as much as
-        possible.
-
-   B-2  The communication for observing and controlling devices must
-        have confidentiality and integrity.  And, it is necessary to
-        think about the threat of other security like the DoS attack.
-
-   B-3  It is necessary to consider the processing performance of the
-        device.  And, it is necessary to suppress the power consumption
-        of the device.
-
-   B-4  It is necessary to consider bandwidth of the communication.
-
-
-5.  Issues
-
-   This section lists the issues in the cross-realm operation when we
-   consider the above requirements.
-
-
-5.1.  Scalability of the direct trust model
-
-   In the direct relationship of trust between each realm, the realms
-   involved in the cross-realm operation share keys and their respective
-   TGS principals are registered in each other's KDC.  When direct trust
-   relationships are used, the KDC of each realm must maintain keys with
-   all foreign realms.  This can become a cumbersome task when the
-   number of realms increase.  This also increases maintenance cost.
-
-   This issue will happen as a by-product of a result meeting the
-   requirements A-1 and A-2, and is related to B-1.
-
-
-5.2.  Exposure to DoS Attacks
-
-   One of the assumption made when allowing the cross-realm operation in
-   Kerberos is that users can communicate with KDCs located in remote
-   realms.  This practice introduces security threats because KDCs are
-   open to the public network.  Administrators may think of restricting
-   the access to the KDC to the trusted realms only.  However, this
-   approach is not scalable and does not really protect the KDC.
-   Indeed, when the remote realms have several IP prefixes (e.g. control
-   centers or outsourcing companies, located world wide), then the
-   administrator of the local KDC must collect the list of prefixes that
-   belong to these organization.  The filtering rules must then
-
-
-
-S.Sakane, et al.                                                [Page 8]
-
-Internet-Draft                                              October 2006
-
-
-   explicitly allow the incoming traffic from any host that belongs to
-   one of these prefixes.  This makes the administrator's tasks more
-   complicated and prone to human errors.  And also, the maintenance
-   cost increases.  On the other hand, when ranges of external IP
-   addresses are allowed to communicate with the KDC, the risk of
-   becoming target to attacks from remote malicious users increases.
-
-   This issue will happen as a result meeting the requirements A-3, A-4
-   and A-5.  And it is related to B-1 and B-2.
-
-
-5.3.  No PFS in case of the indirect trust model
-
-   In [SPECCROSS], any KDC in the authentication path can learn the
-   session key that will be used between the client and the desired
-   service.  This means that any intermediary realm is able to spoof the
-   identity either of the service or the client as well as to eavesdrop
-   on the communication between the client and the server.
-
-   This issue will happen as a by-product of a result meeting the
-   requirements A-1 and A-2, and is related to B-2.
-
-
-5.4.  Unreliability of authentication chain
-
-   When the relationship of trust is constructed like a chain or
-   hierarchical, the authentication path is not dependable since it
-   strongly depends on intermediary realms that might not be under the
-   same authority.  If any of the realms in the authentication path is
-   not available, then the principals of the end-realms can not perform
-   the cross-realm operation.
-
-   The end-point realms do not have full control and responsibility of
-   the success of the operations even if their respective KDCs are fully
-   functional.  Dependability of a system decreases if the system relies
-   on uncontrolled components.  We can not be sure at 100% about the
-   result of the authentication since we do not know how is it going in
-   intermediary realms.
-
-   This issue will happen as a by-product of a result meeting the
-   requirements A-1 and A-2, and is related to B-2.
-
-
-5.5.  Client's performance
-
-   In the cross-realm operation, Kerberos clients have to perform TGS
-   exchanges with all the KDCs in the trust path, including the home KDC
-   and the target KDC.  TGS exchange requires cryptographic operations.
-
-
-
-S.Sakane, et al.                                                [Page 9]
-
-Internet-Draft                                              October 2006
-
-
-   This exchange demands important processing time especially when the
-   client has limited computational capabilities.  The overhead of these
-   cross-realm exchanges grows into unacceptable delays.
-
-   We ported the MIT Kerberos library (version 1.2.4), implemented a
-   Kerberos client on our original board with H8 (16-bit, 20MHz), and
-   measured the process time of each Kerberos message.  It takes 195
-   milliseconds to perform a TGS exchange with the on-board H/W crypto
-   engine.  Indeed, this result seems reasonable to the requirement of
-   the response time for the control network.  However, we did not
-   modify the clock speed of the H8 during our measurement.  The
-   processing time must be slower in a real environment because H8 is
-   used with lowered clock speed in such system.  Also, the delays can
-   grow to unacceptable delays when the number of intermediary realms
-   increases.
-
-   This issue will happen as a by-product of a result meeting the
-   requirements A-1 and A-2, and is related to B-3.
-
-
-5.6.  Pre-authentication problem in roaming scenarios
-
-   In roaming scenarios, the client needs to contact her home KDC to
-   obtain a cross-realm TGT for the local (or visited) realm.  However,
-   the policy of the network access providers or the gateway in the
-   local network usually does not allow clients to communicate with
-   hosts in the Internet unless they provide valid authentication
-   credentials.  In this manner, the client encounters a chicken-and-egg
-   problem where two resources are interdependent; the Internet
-   connection is needed to contact the home KDC and for obtaining
-   credentials, and on the other hand, the Internet connection is only
-   granted for clients who have valid credentials.  As a result, the
-   Kerberos protocol can not be used as it is for authenticating roaming
-   clients requesting network access.
-
-   This issue will happen as a result meeting the requirements A-6.
-
-
-6.  Implementation consideration
-
-   This document just describes issues of the cross-realm operation in
-   the specific systems.  However, there are important matters to be
-   considered, when we solve these issues and implement solution.
-   Solution must not introduce new problem.  Solution should use
-   existing components or protocols as much as possible, should not
-   introduce any definition of new component.  Solution must not require
-   a KDC to have any additional process.  You must not forget that there
-   would be a trade-off matter anytime.  So an implementation may not
-
-
-
-S.Sakane, et al.                                               [Page 10]
-
-Internet-Draft                                              October 2006
-
-
-   solve all of the problems stated in this document.
-
-
-7.  IANA Considerations
-
-   This document makes no request of IANA.
-
-
-8.  Security Considerations
-
-   This document just clarifies some issues of the cross-realm operation
-   of the Kerberos V system.  There is especially not describing
-   security.  Some troubles might be caused to your system by malicious
-   user who misuses the description of this document if it dares to say.
-
-
-9.  Acknowledgments
-
-   The authors are very grateful to Nobuo Okabe, Kazunori Miyazawa,
-   Ken'ichi Kamada and Atsushi Inoue.  They gave us lots of comments and
-   input for this document.
-
-
-10.  References
-
-
-10.1.  Normative References
-
-   [RFC4120]     Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-                 Kerberos Network Authentication Service (V5)", RFC
-                 4120, July 2005.
-
-
-10.2.  Informative References
-
-   [CSPC]        http://www.shellchemicals.com/news/1,1098,72-news_id=
-                 531,00.html
-
-   [RNSS-H8]     http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing.
-                 jsp&fp=/products/mpumcu/h8_family/
-
-   [RNSS-M16C]   http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi
-                 ng.jsp&fp=/products/mpumcu/m16c_family/
-
-   [RFC2119]     S.Bradner, "Key words for use in RFCs to Indicate
-                 Requirement Levels", RFC 2119, March 1997.
-
-
-
-
-
-S.Sakane, et al.                                               [Page 11]
-
-Internet-Draft                                              October 2006
-
-
-   [SHELLCHEM]   http://www.shellchemicals.com/home/1,1098,-1,00.html
-
-   [SPECCROSS]   I. Cervesato and A. Jaggard and A. Scedrov and C.
-                 Walstad, "Specifying Kerberos 5 Cross-Realm
-                 Authentication", Fifth Workshop on Issues in the Theory
-                 of Security, Jan 2005.
-
-Authors' Addresses
-
-   Shoichi Sakane
-   Yokogawa Electric Corporation
-   2-9-32 Nakacho, Musashino-shi,
-   Tokyo  180-8750 Japan
-   E-mail: Shouichi.Sakane@jp.yokogawa.com,
-
-
-   Saber Zrelli
-   Japan Advanced Institute of Science and Technology
-   1-1 Asahidai, Nomi,
-   Ishikawa  923-1292 Japan
-   E-mail: zrelli@jaist.ac.jp
-
-
-   Masahiro Ishiyama
-   Toshiba Corporation
-   1, komukai-toshiba-cho, Saiwai-ku,
-   Kawasaki  212-8582 Japan
-   E-mail: masahiro@isl.rdc.toshiba.co.jp
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-S.Sakane, et al.                                               [Page 12]
-
-Internet-Draft                                              October 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-S.Sakane, et al.                                               [Page 13]
-
diff --git a/doc/standardisation/draft-sakane-krb-cross-problem-statement-03.txt b/doc/standardisation/draft-sakane-krb-cross-problem-statement-03.txt
deleted file mode 100644
index 2ac425ada..000000000
--- a/doc/standardisation/draft-sakane-krb-cross-problem-statement-03.txt
+++ /dev/null
@@ -1,731 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                                 S. Sakane
-Intended Status: Informational                   Yokogawa Electric Corp.
-Expires: January 10, 2008                                      S. Zrelli
-                                                                   JAIST
-                                                             M. Ishiyama
-                                                           Toshiba Corp.
-                                                            July 9, 2007
-
-
-             Problem statement on the cross-realm operation
-                    of Kerberos in a specific system
-            draft-sakane-krb-cross-problem-statement-03.txt
-
-
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-   This Internet-Draft expires in January 10, 2008.
-
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-
-
-
-
-
-S.Sakane, et al.                                                [Page 1]
-
-Internet-Draft                                                 July 2007
-
-
-Abstract
-
-   There are some issues when the cross-realm operation of the Kerberos
-   Version 5 [RFC4120] is employed into actual specific systems.  This
-   document describes some examples of actual systems, and lists
-   requirements and restriction of the operation in such system.  Then
-   it describes issues when we apply the cross-realm operation to such
-   system.
-
-
-
-Conventions used in this document
-
-   It is assumed that the readers are familiar with the terms and
-   concepts described in the Kerberos Version 5 [RFC4120].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-S.Sakane, et al.                                                [Page 2]
-
-Internet-Draft                                                 July 2007
-
-
-Table of Contents
-
-    1. Introduction .................................................  4
-    2. Kerberos system ..............................................  4
-       2.1. Kerberos basic operation ................................  4
-       2.2. Cross-realm operation ...................................  5
-    3. Example of actual environment ................................  6
-    4. Requirements .................................................  7
-    5. Issues .......................................................  8
-       5.1. Unreliability of authentication chain ...................  8
-       5.2. No PFS in case of the indirect trust model ..............  8
-       5.3. Scalability of the direct trust model ...................  9
-       5.4. Exposure to DoS Attacks .................................  9
-       5.5. Client's performance ....................................  9
-       5.6. Pre-authentication problem in roaming scenarios ......... 10
-    6. Implementation consideration ................................. 10
-    7. IANA Considerations .......................................... 11
-    8. Security Considerations ...................................... 11
-    9. Acknowledgments .............................................. 11
-   10. References ................................................... 11
-       10.1. Normative References ................................... 11
-       10.2. Informative References ................................. 11
-   Authors' Addresses ............................................... 12
-   Full Copyright Statement ......................................... 12
-   Intellectual Property Statement .................................. 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-S.Sakane, et al.                                                [Page 3]
-
-Internet-Draft                                                 July 2007
-
-
-1.  Introduction
-
-   The Kerberos Version 5 is a widely deployed mechanism that a server
-   can authenticate a client access.  Each client belongs to a managed
-   domain called realm.  Kerberos supports the authentication in case of
-   situation that a client and a server belong to different realms.
-   This is called the cross-realm operation.
-
-   Meanwhile, there are lots of manners of operation in actual systems,
-   where Kerberos could be applied.  Large system or distributed system
-   are typically split into several managed domain.  The reason is, for
-   example, geographical reason or different management policy.  Even in
-   such system, an authentication mechanism over the different managed
-   domains is required.  When the cross-realm operation of Kerberos is
-   applied to such systems, some issues come out.
-
-   This document briefly describes the Kerberos Version 5 system and the
-   cross-realm operation.  Then, it describes two actual systems that
-   could be applied the Kerberos system, and describes seven
-   requirements of those systems in term both of management and
-   operation.  Finally, it lists six issues of the cross-realm operation
-   when it is applied to those system.
-
-   Note that this document might not describe whole of issues of the
-   cross-realm operation.  It also does not propose any solution to
-   solve issues which described in this document.  In further step, we
-   have to analyze the issues, define problems and explore the
-   solutions.  This work will be in another document.
-
-   This document is assumed that the readers are familiar with the terms
-   and concepts described in the Kerberos Version 5 [RFC4120].
-
-
-2.  Kerberos system
-
-
-2.1.  Kerberos basic operation
-
-   Kerberos [RFC4120] is a widely deployed authentication system.  The
-   authentication process in Kerberos involves principals and a Key
-   Distribution Center (KDC).  The principals can be users or services.
-   Each KDC maintains a principals database and shares a secret key with
-   each registered principal.
-
-   The authentication process allows a user to acquire the needed
-   credentials from the KDC.  These credentials allow services to
-   authenticate the users before granting them access to the resources.
-   An important part of the credentials are called Tickets.  There are
-
-
-
-S.Sakane, et al.                                                [Page 4]
-
-Internet-Draft                                                 July 2007
-
-
-   two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket.
-   The TGT is obtained periodically from the KDC and has a limited limit
-   after which it expires and the user must renew it.  The TGT is used
-   to obtain the other kind of tickets, Service Tickets.  The user
-   obtains a TGT from the Authentication Service (AS), a logical
-   component of the KDC.  The process of obtaining a TGT is referred to
-   as 'AS exchange'.  When a TGT request is issued by an user, the AS
-   responds by sending a reply packet containing the credentials which
-   consists of the TGT along with a random key called 'TGS Session Key'.
-   The TGT contains a set of information encrypted using a secret key
-   associated with a special service referred to as TGS (Ticket Granting
-   Service).  The TGS session key is encrypted using the user's key so
-   that the user can obtain the TGS session key only if she knows the
-   secret key shared with the KDC.  The TGT then is used to obtain
-   Service Tickets from the Ticket Granting Service (TGS)- the second
-   component of the KDC.  The process of obtaining service tickets is
-   referred to as 'TGS exchange'.  The request for a service ticket
-   consists on a packet containing a TGT and an 'Authenticator'.  The
-   Authenticator is encrypted using the TGS session key and contains the
-   identity of the user as well as time stamps (for protection against
-   replay attacks).  After decrypting the TGT (which was encrypted by
-   the AS using the TGS's secret key), the TGS extracts the TGS session
-   key.  Using that session key, it decrypts the Authenticator and
-   authenticates the user.  Then, the TGS issues credentials requested
-   by the user.  These credentials consist on a service ticket and a
-   session key that will be used to authenticate the user with the
-   desired application service.
-
-
-2.2.  Cross-realm operation
-
-   The Kerberos protocol provides the cross-realm authentication
-   capabilities.  This allows users to obtain service tickets to access
-   services in foreign realms.  In order to access such services, the
-   users first contact their home KDC asking for a TGT that will be used
-   with the TGS of the foreign realm.  If the home realm and the foreign
-   realm share keys and have an established trust relationship, the home
-   KDC delivers the requested TGT.
-
-   However, if the home realm does not share inter-realm keys with the
-   foreign realm, the home KDC will provide a TGT that can be used with
-   an intermediary foreign realm that is likely to be sharing inter-
-   realm keys with the target realm.  The client can use this
-   'intermediary TGT' to communicate with the intermediary KDC which
-   will iterate the actions taken by the home KDC.  If the intermediary
-   KDC does not share inter-realm keys with the target foreign realm it
-   will point the user to another intermediary KDC (just as in the first
-   exchange between the user and its home KDC).  However, in the other
-
-
-
-S.Sakane, et al.                                                [Page 5]
-
-Internet-Draft                                                 July 2007
-
-
-   case (when it shares inter-realm keys with the target realm), the
-   intermediary KDC will issue a TGT that can be used with the KDC of
-   the target realm.  After obtaining a TGT for the desired foreign
-   realm, the client uses it to obtain service tickets from the TGS of
-   the foreign realm.  Finally, the user access the service using the
-   service ticket.
-
-   When the realms belong to the same institution, a chain of trust can
-   be determined by the client or the KDC by following the DNS domain
-   hierarchy and supposing that the parent domains share keys with all
-   its child sub-domains.  However, because the inter-realm trust model
-   is not necessarily constructing the hierarchic approach anytime, the
-   trust path must be specified manually.  When intermediary realms are
-   involved, the success of the cross-realm operation completely depends
-   on the realms that are part of the authentication path.
-
-
-3.  Example of actual environment
-
-   In order to help understanding both requirements and restriction,
-   this section describes scale and operation of actual systems, where
-   it is possible to apply Kerberos.
-
-   We refer to actual petrochemical enterprise [SHELLCHEM], and show two
-   examples among its plants.  The enterprise produces bulk
-   petrochemicals and their delivery to large industrial customers.
-   There are 43 typical plants of the enterprise all over the world.
-   They are managed by the operation sites placed in 35 countries.  This
-   section shows two examples of them.
-
-   One is an example of a centralized system [CSPC].  CSPC is operated
-   by a joint enterprise of two companies.  This system is one of the
-   largest systems of this enterprise in the world.  This is placed in
-   the area of 3.4 square kilo meters in the north coast of Daya Bay,
-   Guangdong, which is at the southeast of China.  3,000 network
-   segments are established in the system.  16,000 control devices are
-   connected to the local area network.  These devices belong to
-   different 9 sub systems, A control device has some control points,
-   which are controlled and monitored by other devices remotely.  There
-   are 200,000 control points in all.  They are controlled by 3
-   different control center.
-
-   Another example is a distributed system [NAM].  The NAM (Nederlandse
-   Aardolie Maatschappij) is operated by a partnership company of two
-   enterprises that represent the oil company.  This system is
-   constituted by some plants that are geographically distributed within
-   the range of 863 square kilometers in the northern part of
-   Netherlands.  26 plants, each is named "cluster", are scattered in
-
-
-
-S.Sakane, et al.                                                [Page 6]
-
-Internet-Draft                                                 July 2007
-
-
-   the area.  They are connected each other by a private ATM WAN.  Each
-   cluster has approximately 500-1,000 control devices.  These devices
-   are managed by each local control center in each cluster.  In the
-   entire system of the NAM, there are one million control points.
-
-   In the both of the systems, the end devices are basically connected
-   to a local network by a twisted pair cable, which is a low band-width
-   of 32 kbps.  Low clock CPU, for example H8 [RNSS-H8] and M16C [RNSS-
-   M16C], are employed by many control devices.  Furthermore, to
-   suppress power consumption, these CPU may be lowered the number of
-   clocks.  Because there is a requirement of the explosion-proof.  The
-   requirement restricts the amount of total energy in the device.
-
-   A device on the network collects data from other devices which are
-   monitoring condition of the system.  The device uses the data to make
-   a decision how to control another devices.  And then the device gives
-   more than one instruction that controls other devices.  If it took
-   time for data to reach, they could not be associated.  The travel
-   time of data from the device to the other device is demanded within 1
-   second at least.
-
-   A part of the operation, like control of these system, maintenance,
-   and the environmental monitoring, is consigned to an external
-   organization.  Agents who are consigned walk around the plant to get
-   their information, or watch the plant from a remote site.
-
-
-4.  Requirements
-
-   This section lists the requirements derived from the previous
-   section.  R-1, R-2, R-3 and R-4 are related to the management of the
-   divided system.  R-5, R-6 and R-7 are related to the restriction to
-   such industrial network.
-
-
-   R-1  It is necessary to partition a management domain into some
-        domains.  Or it is necessary to delegate a management authority
-        to another independent management domain.
-
-   R-2  It is necessary to allow different independent management
-        domains to coexist on the same network because two or more
-        organizations need to enter into the system and to management
-        it.
-
-   R-3  It is necessary that a device controls other devices that belong
-        to a different domain.
-
-
-
-
-
-S.Sakane, et al.                                                [Page 7]
-
-Internet-Draft                                                 July 2007
-
-
-   R-4  It is necessary to consider that a device is not always
-        geographically or network topologically close to the other
-        devices even when the devices belong to a same management
-        domain.
-
-   R-5  It is demanded to reduce the management cost as much as
-        possible.
-
-   R-6  It is necessary to consider the processing performance of the
-        device.  And, it is necessary to suppress the power consumption
-        of the device.
-
-   R-7  It is necessary to consider bandwidth of the communication.
-
-
-5.  Issues
-
-   This section lists the issues in the cross-realm operation when we
-   apply the Kerberos version 5 into the system described in the section
-   3, and consider the system applied the Kerberos with the requirements
-   described in the section 4.
-
-
-5.1.  Unreliability of authentication chain
-
-   When the relationship of trust is constructed like a chain or
-   hierarchical, the authentication path is not dependable since it
-   strongly depends on intermediary realms that might not be under the
-   same authority.  If any of the realms in the authentication path is
-   not available, then the principals of the end-realms can not perform
-   the cross-realm operation.
-
-   The end-point realms do not have full control and responsibility of
-   the success of the operations even if their respective KDCs are fully
-   functional.  Dependability of a system decreases if the system relies
-   on uncontrolled components.  We can not be sure at 100% about the
-   result of the authentication since we do not know how is it going in
-   intermediary realms.
-
-   This issue will happen as a by-product of a result meeting the
-   requirements R-1 and R-2.
-
-
-5.2.  No PFS in case of the indirect trust model
-
-   In [SPECCROSS], any KDC in the authentication path can learn the
-   session key that will be used between the client and the desired
-   service.  This means that any intermediary realm is able to spoof the
-
-
-
-S.Sakane, et al.                                                [Page 8]
-
-Internet-Draft                                                 July 2007
-
-
-   identity either of the service or the client as well as to eavesdrop
-   on the communication between the client and the server.
-
-   This issue will happen as a by-product of a result meeting the
-   requirements R-1 and R-2.
-
-
-5.3.  Scalability of the direct trust model
-
-   In the direct relationship of trust between each realm, the realms
-   involved in the cross-realm operation share keys and their respective
-   TGS principals are registered in each other's KDC.  When direct trust
-   relationships are used, the KDC of each realm must maintain keys with
-   all foreign realms.  This can become a cumbersome task when the
-   number of realms increase.  This also increases maintenance cost.
-
-   This issue will happen as a by-product of a result meeting the
-   requirements R-1, R-2 and R-5.
-
-
-5.4.  Exposure to DoS Attacks
-
-   One of the assumption made when allowing the cross-realm operation in
-   Kerberos is that users can communicate with KDCs located in remote
-   realms.  This practice introduces security threats because KDCs are
-   open to the public network.  Administrators may think of restricting
-   the access to the KDC to the trusted realms only.  However, this
-   approach is not scalable and does not really protect the KDC.
-   Indeed, when the remote realms have several IP prefixes (e.g. control
-   centers or outsourcing companies, located world wide), then the
-   administrator of the local KDC must collect the list of prefixes that
-   belong to these organization.  The filtering rules must then
-   explicitly allow the incoming traffic from any host that belongs to
-   one of these prefixes.  This makes the administrator's tasks more
-   complicated and prone to human errors.  And also, the maintenance
-   cost increases.  On the other hand, when ranges of external IP
-   addresses are allowed to communicate with the KDC, the risk of
-   becoming target to attacks from remote malicious users increases.
-
-
-5.5.  Client's performance
-
-   In the cross-realm operation, Kerberos clients have to perform TGS
-   exchanges with all the KDCs in the trust path, including the home KDC
-   and the target KDC.  TGS exchange requires cryptographic operations.
-   This exchange demands important processing time especially when the
-   client has limited computational capabilities.  The overhead of these
-   cross-realm exchanges grows into unacceptable delays.
-
-
-
-S.Sakane, et al.                                                [Page 9]
-
-Internet-Draft                                                 July 2007
-
-
-   We ported the MIT Kerberos library (version 1.2.4), implemented a
-   Kerberos client on our original board with H8 (16-bit, 20MHz), and
-   measured the process time of each Kerberos message [KRBIMPL].  It
-   takes 195 milliseconds to perform a TGS exchange with the on-board
-   H/W crypto engine.  Indeed, this result seems reasonable to the
-   requirement of the response time for the control network.  However,
-   we did not modify the clock speed of the H8 during our measurement.
-   The processing time must be slower in a actual environment because H8
-   is used with lowered clock speed in such system.  Also, the delays
-   can grow to unacceptable delays when the number of intermediary
-   realms increases.
-
-   This issue will happen as a by-product of a result meeting the
-   requirements R-1, R-2, R-6 and R-7.
-
-
-5.6.  Pre-authentication problem in roaming scenarios
-
-   In roaming scenarios, the client needs to contact her home KDC to
-   obtain a cross-realm TGT for the local (or visited) realm.  However,
-   the policy of the network access providers or the gateway in the
-   local network usually does not allow clients to communicate with
-   hosts in the Internet unless they provide valid authentication
-   credentials.  In this manner, the client encounters a chicken-and-egg
-   problem where two resources are interdependent; the Internet
-   connection is needed to contact the home KDC and for obtaining
-   credentials, and on the other hand, the Internet connection is only
-   granted for clients who have valid credentials.  As a result, the
-   Kerberos protocol can not be used as it is for authenticating roaming
-   clients requesting network access.
-
-   This issue will happen as a result meeting the requirements R-3 and
-   R-4.
-
-
-6.  Implementation consideration
-
-   This document just describes issues of the cross-realm operation.
-   However, there are important matters to be considered, when we solve
-   these issues and implement solution.  Solution must not introduce new
-   problem.  Solution should use existing components or protocols as
-   much as possible, should not introduce any definition of new
-   component.  Solution must not require a KDC to have any additional
-   process.  You must not forget that there would be a trade-off matter
-   anytime.  So an implementation may not solve all of the problems
-   stated in this document.
-
-
-
-
-
-S.Sakane, et al.                                               [Page 10]
-
-Internet-Draft                                                 July 2007
-
-
-7.  IANA Considerations
-
-   This document makes no request of IANA.
-
-
-8.  Security Considerations
-
-   This document just clarifies some issues of the cross-realm operation
-   of the Kerberos V system.  There is especially not describing
-   security.  Some troubles might be caused to your system by malicious
-   user who misuses the description of this document if it dares to say.
-
-
-9.  Acknowledgments
-
-   The authors are very grateful to Nobuo Okabe, Kazunori Miyazawa,
-   Ken'ichi Kamada and Atsushi Inoue.  They gave us lots of comments and
-   input for this document.
-
-
-10.  References
-
-
-10.1.  Normative References
-
-   [RFC4120]     Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-                 Kerberos Network Authentication Service (V5)", RFC
-                 4120, July 2005.
-
-
-10.2.  Informative References
-
-   [CSPC]        http://www.shellchemicals.com/news/1,1098,72-news_id=
-                 531,00.html
-
-   [KRBIMPL]     "A Prototype of a Secure Autonomous Bootstrap Mechanism
-                 for Control Networks", Nobuo Okabe, Shoichi Sakane,
-                 Masahiro Ishiyama, Atsushi Inoue and Hiroshi Esaki,
-                 SAINT, pp. 56-62, IEEE Computer Society, 2006.
-
-   [NAM]         http://www.nam.nl/
-
-   [RNSS-H8]     http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing.
-                 jsp&fp=/products/mpumcu/h8_family/
-
-   [RNSS-M16C]   http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi
-                 ng.jsp&fp=/products/mpumcu/m16c_family/
-
-
-
-
-S.Sakane, et al.                                               [Page 11]
-
-Internet-Draft                                                 July 2007
-
-
-   [SHELLCHEM]   http://www.shellchemicals.com/home/1,1098,-1,00.html
-
-   [SPECCROSS]   I. Cervesato and A. Jaggard and A. Scedrov and C.
-                 Walstad, "Specifying Kerberos 5 Cross-Realm
-                 Authentication", Fifth Workshop on Issues in the Theory
-                 of Security, Jan 2005.
-
-Authors' Addresses
-
-   Shoichi Sakane
-   Yokogawa Electric Corporation
-   2-9-32 Nakacho, Musashino-shi,
-   Tokyo  180-8750 Japan
-   E-mail: Shouichi.Sakane@jp.yokogawa.com,
-
-
-   Saber Zrelli
-   Japan Advanced Institute of Science and Technology
-   1-1 Asahidai, Nomi,
-   Ishikawa  923-1292 Japan
-   E-mail: zrelli@jaist.ac.jp
-
-
-   Masahiro Ishiyama
-   Toshiba Corporation
-   1, komukai-toshiba-cho, Saiwai-ku,
-   Kawasaki  212-8582 Japan
-   E-mail: masahiro@isl.rdc.toshiba.co.jp
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-S.Sakane, et al.                                               [Page 12]
-
-Internet-Draft                                                 July 2007
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-S.Sakane, et al.                                               [Page 13]
-
diff --git a/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt b/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt
deleted file mode 100644
index 321c5ba09..000000000
--- a/doc/standardisation/draft-smedvinsky-dhc-kerbauth-01.txt
+++ /dev/null
@@ -1,929 +0,0 @@
-
-
-DHC Working Group                                          S. Medvinsky
-Internet Draft                                                 Motorola
-Document: <draft-smedvinsky-dhc-kerbauth-01.txt>
-Category: Standards Track                                    P.Lalwaney
-Expires: January 2001                                             Nokia
-
-                                                              July 2000
-
-
-        Kerberos V Authentication Mode for Uninitialized Clients
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   The distribution of this memo is unlimited.  It is filed as <draft-
-   smedvinsky-dhc-kerbauth-01.txt>, and expires January 2001. Please
-   send comments to the authors.
-
-
-
-1. Abstract
-
-   The Dynamic Host Configuration Protocol (DHCP) [1] includes an
-   option that allows authentication of all DHCP messages, as specified
-   in [2].  This document specifies a DHCP authentication mode based on
-   Kerberos V tickets. This provides mutual authentication between a
-   DHCP client and server, as well as authentication of all DHCP
-   messages.
-
-   This document specifies Kerberos message exchanges between an
-   uninitialized client and the KDC (Key Distribution Center) using an
-   IAKERB proxy [7] so that the Kerberos key management phase is
-   decoupled from, and precedes the address allocation and network
-   configuration phase that uses the DHCP authentication option.  In
-   order to make use of the IAKERB proxy, this document specifies a
-   transport mechanism that works with an uninitialized client (i.e. a
-
-Kerberos V Authentication Mode for Uninitialized Clients     July 2000
-
-
-   client without an assigned IP address). In addition, the document
-   specifies the format of the Kerberos authenticator to be used with
-   the DHCP authentication option.
-
-2. Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
-   this document are to be interpreted as described in RFC-2119.
-
-3. Introduction
-
-   3.1 Terminology
-
-   o "DHCP client"
-
-   A DHCP client is an Internet host using DHCP to obtain configuration
-   parameters such as a network address.
-
-   o "DHCP server"
-
-   A DHCP server is an Internet host that returns configuration
-   parameters to DHCP clients.
-
-   O "Ticket"
-
-   A Kerberos term for a record that helps a client authenticate itself
-   to a server; it contains the client's identity, a session key, a
-   timestamp, and other information, all sealed using the server's
-   secret key. It only serves to authenticate a client when presented
-   along with a fresh Authenticator.
-
-   o "Key Distribution Center"
-
-   Key Distribution Center, a network service that supplies tickets and
-   temporary session keys; or an instance of that service or the host
-   on which it runs. The KDC services both initial ticket and Ticket-
-   Granting Ticket (TGT) requests. The initial ticket portion is
-   sometimes referred to as the Authentication Server (or service. The
-   Ticket-Granting Ticket portion is sometimes referred to as the
-   Ticket-Granting Server (or service).
-
-   o "Realm"
-
-   A Kerberos administrative domain that represents a group of
-   principals registered at a KDC.  A single KDC may be responsible for
-   one or more realms.  A fully qualified principal name includes a
-   realm name along with a principal name unique within that realm.
-
-3.2 Protocol Overview
-
-
-
-S. Medvinsky, P. Lalwaney                                          -2-        
-
-Kerberos V Authentication Mode for Uninitialized Clients     July 2000
-
-
-   DHCP as defined in [1] defines the protocol exchanges for a client
-   to obtain its IP address and network configuration information from
-   a DHCP Server. Kerberos V5 as described in [6] defines the protocol
-   and message exchanges to mutually authenticate two parties. It is
-   our goal to provide authentication support for DHCP using Kerberos.
-   This implies that the Kerberos key management exchange has to take
-   place before a client gets its IP address from the DHCP Server.
-   Kerberos assumes that the client has a network address and can
-   contact the Key Distribution Center to obtain its credentials for
-   authenticated communication with an application server.
-
-   In this specification we utilize the key exchange using an IAKERB
-   proxy described in [7]. This does not require any changes to either
-   the IAKERB or the Kerberos V5 specification.  This document also
-   specifies a particular transport that allows an uninitialized client
-   to contact an IAKERB proxy.
-
-   The Kerberos ticket returned from the key management exchange
-   discussed in Section 5 of this document is passed to the DHCP Server
-   inside the DHCP authentication option with the new Kerberos
-   authenticator type. This is described in Section 6 of this draft.
-
-
-3.3 Related Work
-
-   A prior Internet Draft [3] outlined the use of Kerberos-based
-   authentication for DHCP. The proposal tightly coupled the Kerberos
-   client state machines and the DHCP client state machines. As a
-   result, the Kerberos key management messages were carried in DHCP
-   messages, along with the Kerberos authenticators. In addition, the
-   first DHCP message exchange (request, offer) is not authenticated.
-
-   We propose a protocol exchange where Kerberos key management is
-   decoupled from and precedes authenticated DHCP exchanges. This
-   implies that the Kerberos ticket returned in the initial key
-   management exchange could be used to authenticate servers assigning
-   addresses by non-DHCP address assignment mechanisms like RSIP [4]
-   and for service specific parameter provisioning mechanisms using SLP
-   [5].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-S. Medvinsky, P. Lalwaney                                          -3-        
-
-Kerberos V Authentication Mode for Uninitialized Clients     July 2000
-
-
-
-4. System Architecture
-
-
-     Client
-    --------                            --------
-   |        |   5.Authenticated DHCP   |        |
-   |  DHCP  |<------------------------>| DHCP   |
-   | client |                          | server |
-   |        |                          |        |
-   |        |                          |        |
-   |Kerberos|                          |        |
-   | Client |                          |        |
-    --------                            --------
-       ^
-       |
-       |
-       |
-       |                                -------
-        ------------------------------>|       |
-         Kerberos Key Mgmt             | Proxy |
-         messages:                     |       |
-          1. AS Request  / 2.AS Reply   -------
-          3. TGS Request / 4.TGS Reply     ^
-                                           | Kerberos
-                                           | Key Mgmt messages
-                                           v (1, 2, 3, 4)
-                                        --------
-                                       |        |
-                                       |  KDC   |
-                                       |        |
-                                        --------
-
-     Figure 1: System blocks and message interactions between them
-
-
-   In this architecture, the DHCP client obtains a Kerberos ticket from
-   the Key Distribution Center (KDC) using standard Kerberos messages,
-   as specified in [6].  The client, however, contacts the KDC via a
-   proxy server, according to the IAKERB mechanism, described in [7].
-   The are several reasons why a client has to go through this proxy in
-   order to contact the KDC:
-
-  a)The client may not know the host address of the KDC and may be
-     sending its first request message as a broadcast on a local
-     network.  The KDC may not be located on the local network, and
-     even if it were - it will be unable to communicate with a client
-     without an IP address.  This document describes a specific
-     mechanism that may be used by a client to communicate with the
-     Kerberos proxy.
-
-
-
-S. Medvinsky, P. Lalwaney                                          -4-        
-
-Kerberos V Authentication Mode for Uninitialized Clients     July 2000
-
-
-  b)The client may not know its Kerberos realm name.  The proxy is
-     able to fill in the missing client realm name in an AS Request
-     message, as specified in IAKERB.  Note that in the case that
-     PKINIT pre-authenticator is used [8], the realm name in the AS
-     Request may be the KDC realm name and not the clientÆs realm name.
-
-  c) The client does not know the realm name of the DHCP server.
-
-     According to IAKERB, when the client sends a TGS Request with a
-     missing server realm name, the proxy will return to the client an
-     error message containing the missing realm name.
-
-     Note that in this case the proxy could return the client a wrong
-     realm name and the client could be fooled into obtaining a ticket
-     for the wrong DHCP server (on the same local network).  However,
-     the wrong DHCP server must still be a registered principal in a
-     KDC database.  In some circumstances this may be an acceptable
-     compromise.  Also, see the security considerations section.
-
-     IAKERB describes the proxy as part of an application server - the
-     DHCP server in this case.  However, in this document we are not
-     requiring the proxy to be integrated with the DHCP server.  The
-     same IAKERB mechanisms apply in the more general case, where the
-     proxy is an independent application.  This proxy, however, MUST be
-     reachable by a client via a local network broadcast.
-
-     After a client has obtained a Kerberos ticket for the DHCP server,
-     it will use it as part of an authentication option in the DHCP
-     messages.  The only extension to the DHCP protocol is the addition
-     of a new authenticator type based on Kerberos tickets.
-
-4.1 Cross-Realm Authentication
-
-   Figure 1 shows a client communicating with a single KDC via a proxy.
-   However, the DHCP clientÆs realm may be different from the DHCP
-   serverÆs realm.  In that case, the client may need to first contact
-   the KDC in its local realm to obtain a cross-realm TGT.  Then, the
-   client would use the cross-realm TGT to contact the KDC in the DHCP
-   serverÆs realm, as specified in [6].
-
-   In the following example a client doesnÆt know its realm or the DHCP
-   serverÆs realm, which happens to be different from the clientÆs
-   realm.  Here are the steps in obtaining the ticket for the DHCP
-   server (based on [6] and [7]):
-
-        1) The client sends AS Request with NULL realm to the proxy.
-        2) The proxy fills in the realm and forwards the AS Request to
-           the KDC in the clientÆs realm.
-        3) The KDC issues a TGT and sends back an AS Reply to the
-           proxy.
-        4) The proxy forwards AS Reply to the client.
-
-
-S. Medvinsky, P. Lalwaney                                          -5-        
-
-Kerberos V Authentication Mode for Uninitialized Clients     July 2000
-
-
-        5) The client sends TGS Request for a principal name "dhcpsrvr"
-           with NULL realm to the proxy.
-        6) The proxy returns KRB_AP_ERR_REALM_REQUIRED error with the
-           DHCP serverÆs realm to the client.
-        7) The client sends another TGS Request for a cross-realm TGT
-           to the proxy.
-        8) The proxy forwards the TGS Request to the KDC in the
-           clientÆs realm.
-        9) The KDC issues a cross-realm TGT and sends back a TGS Reply
-           to the proxy.
-       10) The proxy forwards TGS Reply to the client.
-       11) The client sends a TGS Request to the proxy for a principal
-       "dhcpsrvr" with the realm name filled in, using a cross-realm
-       TGT.
-       12) The proxy forwards TGS Request to the KDC in the DHCP      
-       server's realm.
-       13) The KDC issues a ticket for the DHCP server and sends TGS
-       Reply back to the proxy.
-       14) The proxy forwards TGS Reply to the client.
-
-   In a most general case, the client may need to contact any number of
-   KDCs in different realms before it can get a ticket for the DHCP
-   server.  In each case, the client would contact a KDC via the proxy
-   server, as specified in Section 5 of this document.
-
-4.2 Public Key Authentication
-
-   This specification also allows clients to perform public key
-   authentication to the KDC, based on the PKINIT specification [8].
-   In this case, the size of an AS Request and AS Reply messages is
-   likely to exceed the size of typical link MTU's.
-
-   Here is an example, where PKINIT is used by a DHCP client that is
-   not a registered principal in the KDC principal database:
-
-        1) The client sends AS Request with a PKINIT Request pre-
-           authenticator to the proxy.  This includes the clientÆs
-           signature and X.509 certificate.  The KDC realm field is
-           left as NULL.
-        2) The proxy fills in the realm and forwards the AS Request to
-           the KDC in the filled in realm.  This is the realm of the
-           DHCP server.  Here, the clientÆs realm is the name of a
-           Certification Authority - not the same as the KDC realm.
-        3) The KDC issues a TGT and sends back an AS Reply with a
-           PKINIT Reply pre-authenticator to the proxy.
-        4) The proxy forwards the AS Reply to the client.
-        5) The client sends TGS Request for a principal name "dhcpsrvr"
-           with the realm found in the TGT to the proxy.
-        6) The proxy forwards TGS Request to the KDC in the DHCP
-           serverÆs realm.
-        7) The KDC issues a ticket for the DHCP server and sends TGS
-           Reply back to the proxy.
-
-S. Medvinsky, P. Lalwaney                                          -6-        
-
-Kerberos V Authentication Mode for Uninitialized Clients     July 2000
-
-
-        8) The proxy forwards TGS Reply to the client.
-
-
-   5. Key Management Exchange that Precedes Network Address Allocation
-
-   An uninitialized host (e.g. on power-on and reset) does not have a
-   network address. It does have a link layer address or hardware
-   address. At this time, the client may not have any information on
-   its realm or the realm of the address allocation server (DHCP
-   Server).
-
-   In the Kerberos key management exchange, a client gets its ticket
-   granting ticket (TGT) by contacting the Authentication Server in the
-   KDC using the AS_Request / Reply messages (shown as messages 1 and 2
-   in Figure 1). The client then contacts the Ticket Granting Server in
-   the KDC to get the DHCP server ticket (to be used for mutual
-   authentication with the DHCP server) using the TGS_REQ / TGS_REP
-   messages (shown as messages 3 and 4 in the above figure).  It is
-   also possible for the client to obtain a DHCP server ticket directly
-   with the AS Request / Reply exchange, without the use of the TGT.
-
-   In the use of Kerberos for DHCP authentication, the client (a) does
-   not have an IP/network address (b) does not know he KDCÆs IP address
-   (c) the KDC may not be on the local network and (d) the client may
-   not know the DHCP ServerÆs IP address and realm.  We therefore
-   require a Kerberos proxy on the local network to accept broadcast
-   Kerberos request messages (AS_REQ and TGS_REQ) from uninitialized
-   clients and relay them to the appropriate KDC.
-
-   The uninitialized client formulates a broadcast AS_REQ or TGS_REQ as
-   follows:
-
-   The request payload contains the client hardware address in
-   addresses field with a negative value for the address type. Kerberos
-   v5 [6] allows for the usage of negative address types for "local"
-   use. Note that IAKERB [7] discourages the use of the addresses field
-   as network addresses may not be known or may change in situation
-   where proxies are used. In this draft we incorporate the negative
-   values permitted in the Kerberos transport in the address type field
-   of both the AS_REQ and TGS_REQ messages. The negative value SHOULD
-   be the negative number of the hardware address type "htype" value
-   (from assigned numbers RFC) used in RFC 2131. The address field of
-   the message contains the clients hardware address.
-
-   The request payload is UDP encapsulated and addressed to port 88 on
-   the server/proxy. The UDP source port is selected by the client. The
-   source and destination network addresses are the all-zeroÆs address
-   and the broadcast address, respectively. For IPv4, the source IP
-   address is set to 0.0.0.0 and the destination IP address is set to
-   255.255.255.255. The data link layer header source address
-   corresponds to the link layer/hardware address of the client. The
-
-
-S. Medvinsky, P. Lalwaney                                          -7-        
-
-Kerberos V Authentication Mode for Uninitialized Clients     July 2000
-
-
-   destination link layer address is the broadcast address at the link
-   layer (e.g. for Ethernet the address is ffffffff).
-
-   In the case where AS_REQ message contains a PKINIT pre-authenticator
-   for public key-based client authentication (based on [8]), the
-   message will probably not fit into a single UDP packet given typical
-   link MTU's.
-
-   It is assumed that the proxy server on a network is configured with
-   a list of KDCÆs, their realms and their IP addresses. The proxy
-   server will act as a client to the KDC and forward standard Kerberos
-   messages to/from the KDC using unicast UDP or TCP transport
-   mechanisms, according to [6].
-
-   Upon receiving a broadcast request from a client, the proxy MUST
-   record the clientÆs hardware address that appears as the source
-   address on the frame as well as in the addresses field of the
-   request message. Based on the realm of the KDC specified in the
-   request, the proxy determines the KDC to which this message is
-   relayed as a unicast message from the proxy to the KDC.  In the case
-   that the client left the KDC realm name as NULL, it is up to the
-   proxy to first determine the correct realm name and fill it in the
-   request (according to [7]).
-
-   On receiving a request, the KDC formulates a response (AS_REP or
-   TGS_REP). It includes the clientÆs addresses field in the encrypted
-   part of the ticket (according to [6]). This response is unicast to
-   the proxy.
-
-   Upon receiving the reply, the proxy MUST first determine the
-   previously saved hardware address of the client.  The proxy
-   broadcasts the reply on its local network. This is a network layer
-   broadcast. At the link level, it uses the hardware address obtained
-   from the addresses field of the request.
-
-   The client on receiving the response (link layer destination address
-   as its hardware address, network layer address is the broadcast
-   address) must verify that the hardware address in the ticket
-   corresponds to its link layer address.
-
-   Upon receiving a TGS_REP (or an AS_REP with the application server
-   ticket) from the proxy, the client will have enough information to
-   securely communicate with the application server (the DHCP Server in
-   this case), as specified in the following section.
-
-
-
-
-
-
-
-
-
-S. Medvinsky, P. Lalwaney                                          -8-        
-
-Kerberos V Authentication Mode for Uninitialized Clients     July 2000
-
-
-    6. Authenticated Message Exchange Between the DHCP Client and the
-   DHCP Server
-
-   The ticket returned in the TGS response is used by the DHCP client
-   in the construction of the Kerberos authenticator.  The Kerberos
-   ticket serves two purposes: to establish a shared session key with
-   the DHCP server, and is also included as part of a Kerberos
-   authenticator in the DHCP request.
-
-   If the size of the authenticator is greater than 255 bytes, the DHCP
-   authentication option is repeated multiple times.  When the values
-   of all the authentication options are concatenated together, they
-   will make up the complete authenticator.
-
-   Once the session key is established, the Kerberos structure
-   containing the ticket (AP REQ) can be omitted from the authenticator
-   for subsequent messages sent by both the DHCP client and the DHCP
-   server.
-
-   The Kerberos authenticator for a DHCP request message is specified
-   below:
-
-   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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |     Code      |    Length     |    Protocol   |   Algorithm   |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                                                               |
-   +              Replay Detection (64 bits)                       +
-   |                                                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                                                               |
-   +              Authentication token (n octets)           ...    +
-   |                                                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   The format of this authenticator is in accordance with [2]. The code
-   for the authentication option is TBD, and the length field contains
-   the length of the remainder of the option, starting with the
-   protocol field.
-
-   The value of the protocol field for this authenticator MUST be set
-   to 2.
-
-   The algorithm field MUST take one of the following values:
-        1 - HMAC-MD5
-        2 - HMAC-SHA-1
-
-   Replay protection field is a monotonically increasing counter field.
-   When the Kerberos AP REQ structure is present in the authenticator
-   the counter may be set to any value.  The AP REQ contains its own
-   replay protection mechanism in the form of a timestamp.
-
-S. Medvinsky, P. Lalwaney                                          -9-        
-
-Kerberos V Authentication Mode for Uninitialized Clients     July 2000
-
-
-
-   Once the session key has been established and the AP REQ is not
-   included in the authenticator, this field MUST be monotonically
-   increasing in the messages sent by the client.
-
-   Kerberos authenticator token consists of type-length-value
-   attributes:
-
-   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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |     Type      |  Reserved     |       Payload Length          |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                           attribute value...
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   The following attributes are included in the Kerberos authenticator
-   token:
-
-   Type         Attribute Name          Value
-   --------------------------------------------------------------------
-   0            Message Integrity Code  Depends on the value of the
-                                        algorithm field.  Its length is
-                                        16 bytes for HMAC-MD5 [9, 10]
-                                        and 20 bytes for HMAC-SHA-1
-                                        [11, 10].  The HMAC key must be
-                                        derived from Kerberos session
-                                        key found in the Kerberos
-                                        ticket according to the key
-                                        derivation rules in [6]:
-
-                                          HMAC Key = DK(sess key,
-                                                      key usage | 0x99)
-
-                                        Here, DK is defined in [12] and
-                                        the key usage value for DHCP is
-                                        TBD.
-
-                                        The HMAC is calculated over the
-                                        entire DHCP message. The
-                                        Message Integrity Code
-                                        attribute MUST be set to all 0s
-                                        for the computation of the
-                                        HMAC.  Because a DHCP relay
-                                        agent may alter the values of
-                                        the 'giaddr' and 'hops' fields
-                                        in the DHCP message, the
-                                        contents of those two fields
-                                        MUST also be set to zero for
-                                        the computation of the HMAC.
-                                        Rules specified in Section 3 of
-                                        [2] for the exclusion and
-
-S. Medvinsky, P. Lalwaney                                         -10-        
-
-Kerberos V Authentication Mode for Uninitialized Clients     July 2000
-
-
-                                        processing of the relay agent
-                                        information are applicable here
-                                        too.
-
-                                        This field MUST always be
-                                        present in the Kerberos
-                                        authenticator.
-
-   1            AP_REQ                  ASN.1 encoding of a Kerberos
-                                        AP_REQ message, as specified
-                                        in [6]. This MUST be included
-                                        by the client when establishing
-                                        a new session key.  In all
-                                        other cases, this attribute
-                                        MUST be omitted.
-
-   AP_REQ contains the Kerberos ticket for the DHCP server and also
-   contains information needed by the DHCP server to authenticate the
-   client.  After verifying the AP_REQ and decrypting the Kerberos
-   ticket, the DHCP server is able to extract a session key which it
-   now shares with the DHCP client.
-
-   The Kerberos authenticator token contains its own replay protection
-   mechanism inside the AP_REQ structure.  The AP_REQ contains a
-   timestamp that must be within an agreed upon time window at the DHCP
-   server.  However, this does not require the DHCP clients to maintain
-   an accurate clock between reboots.  Kerberos allows clients to
-   synchronize their clock with the KDC with the help of Kerberos
-   KRB_AP_ERR_SKEW error message, as specified in [6].
-
-   The DHCP server MUST save both the session key and its associated
-   expiration time found in the Kerberos ticket.  Up until the
-   expiration time, the server must accept client requests with the
-   Kerberos authenticator that does not include the AP REQ, using the
-   saved session key in calculating HMAC values.
-
-   The Kerberos authenticator inside all DHCP server responses MUST NOT
-   contain the AP REQ and MUST use the saved Kerberos session key in
-   calculating HMAC values.
-
-   When the session key expires, it is the client's responsibility to
-   obtain a new ticket from the KDC and to include an AP REQ inside the
-   Kerberos authenticator for the next DHCP request message.
-
-
-
-
-
-
-
-
-
-
-S. Medvinsky, P. Lalwaney                                         -11-        
-
-Kerberos V Authentication Mode for Uninitialized Clients     July 2000
-
-
-7. Detailed message flows for Kerberos and DHCP message Exchanges
-
-   The following flow depicts the Kerberos exchange in which a AS REQ
-   message is used to directly request the DHCP Server ticket. There
-   are no changes to transport mechanisms below when the additional
-   phase of using TGS requests/responses with TGTÆs is used.
-
-   Client                         IAKERB Proxy                 KDC
-
-   KB-client-------- AS_REQ ------>
-
-   AS REQ Address type = - (htype)
-   AS REQ Address= hw address
-
-   src UDP port = senders port
-   destination UDP port = 88
-
-   src IP = 0.0.0.0
-   destination IP = 255.255.255.255
-
-   src link layer address =
-   clientÆs HW/link address [e.g Ethernet address]
-
-   destination link layer address =
-   link broadcast address [e.g. ffffffff for Ethernet]
-
-
-                                         --------------------------->
-                                            (unicast to UDP port 88)
-
-
-
-                                          <--------------------------
-                                             (unicast AS REP)
-                                         Encrypted portion of ticket
-                                         Includes clients HW address
-
-
-      <---------------AS_REP -----------
-
-
-     Ticket includes clientÆs hardware address
-
-     src UDP port = 88
-     destination UDP port = copied from src port in AS_REQ
-
-     src IP = ProxyÆs IP address
-     destination IP = 255.255.255.255
-
-     src link layer address = ProxyÆs HW/link address
-     destination link layer address =
-         ClientÆs link layer address from AS_REQ
-
-
-S. Medvinsky, P. Lalwaney                                         -12-        
-
-Kerberos V Authentication Mode for Uninitialized Clients     July 2000
-
-
-
-
-
-    The client uses the ticket received from the KDC in the DHCP
-Authentication option as described in Section 6.
-
-
-     Client
-     DHCP-client                                   DHCP Server
-
-             ------DHCPDISCOVER ---->
-             (Auth Protocol = 2, includes Kerberos
-              authenticator with AP REQ )
-                                   -----------------------------------
-                                   |  HMAC  |     AP   REQ           |
-                                    ----------------------------------
-                                            | Ticket| Client Authent |
-                                            --------------------------
-
-                                         1. Server decrypts ticket
-                                         (inside AP REQ) with service
-                                         key
-                                         2. Server decrypts client
-                                         authenticator (inside AP REQ)
-                                         and checks content and
-                                         checksum to validate the
-                                         client.
-                                         3. Recompute HMAC with session
-                                         key and compare.
-
-
-          <-------DHCPOFFER----------
-          (Auth Protocol = 2, no AP REQ )
-
-
-
-         ---------DHCPREQUEST------->
-         (Auth Protocol = 2, no AP REQ)
-
-
-          <--------DHCPACK-------------
-           (Auth Protocol = 2, no AP REQ )
-
-
-
-
-8. Security Considerations
-
-   DHCP clients that do not know the DHCP serverÆs realm name will get
-   it from the proxy, as specified in IAKERB [7].  Since the proxy is
-   not authenticated, a DHCP client can be fooled into obtaining a
-   ticket for the wrong DHCP server in the wrong realm.
-
-S. Medvinsky, P. Lalwaney                                         -13-        
-
-Kerberos V Authentication Mode for Uninitialized Clients     July 2000
-
-
-
-   This could happen when the client leaves out the server realm name
-   in a TGS Request message to the proxy.  It is also possible,
-   however, for a client to directly request a DHCP server ticket with
-   an AS Request message.  In those cases, the same situation occurs
-   when the client leaves out the realm name in an AS Request.
-
-   This wrong DHCP server is still registered as a valid principal in a
-   database of a KDC that can be trusted by the client.  In some
-   circumstances a client may assume that a DHCP server that is a
-   Kerberos principal registered with a trusted KDC will not attempt to
-   deliberately misconfigure a client.
-
-   This specification provides a tradeoff between:
-
-        1) The DHCP clients knowing DHCP serverÆs realm ahead of time,
-           which provides for full 2-way authentication at the cost of
-           an additional configuration parameter.
-        2) The DHCP clients not requiring any additional configuration
-           information, besides a password or a key (and a public key
-           certificate if PKINIT is used).  This is at the cost of not
-           being able to fully authenticate the identity of the DHCP
-           server.
-
-
-
-9. References
-
-
-   [1]Droms, R., Arbaugh, W., "Dynamic Host Configuration Protocol",
-      RFC 2131, Bucknell University, March 1997.
-
-   [2]Droms, R., Arbaugh, W., "Authentication for DHCP Messages",
-      draft-ietf-dhc-authentication-13.txt, June 2000.
-
-   [3]Hornstein, K., Lemon, T., "DHCP Authentication Via Kerberos V",
-      draft-hornstein-dhc-kerbauth-02.txt, February 2000.
-
-   [4]Borella, M., Grabelsky, D., Lo, J., Tuniguchi, K., "Realm
-      Specific IP: Protocol Specification ", draft-ietf-nat-rsip-
-      protocol-06.txt, March 2000.
-
-   [5]Guttman, E., Perkins, C., Veizades, J., Day, M., "Service
-      Location Protocol, Version 2", RFC 2608, June 1999.
-
-   [6]Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
-      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
-      05.txt, March 2000.
-
-
-
-
-
-S. Medvinsky, P. Lalwaney                                         -14-        
-
-Kerberos V Authentication Mode for Uninitialized Clients     July 2000
-
-
-
-   [7]Swift, M., Trostle, J., "Initial Authentication and Pass Through
-      Authentication Using Kerberos V5 and the GSS-API (IAKERB)",
-      draft-ietf-cat-iakerb-03.txt, September 1999.
-
-   [8]Tung, B., C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray,
-      J. Trostle, "Public Key Cryptography for Initial Authentication
-      in Kerberos", draft-ietf-cat-pk-init-11.txt, March 2000.
-
-   [9]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
-      1992.
-
-   [10]Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
-      Message Authentication," RFC 2104, February 1997.
-
-   [11]NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995.
-
-   [12]Horowitz, M., "Key Derivation for Authentication, Integrity, and
-      Privacy", draft-horowitz-key-derivation-02.txt, August 1998.
-
-   [13]Bradner, S. "The Internet Standards Process -- Revision 3", RFC
-   2026.
-
-
-
- 10. Author's Addresses
-
-   Sasha Medvinsky
-   Motorola
-   6450 Sequence Drive
-   San Diego, CA 92121
-   Email: smedvinsky@gi.com
-
-   Poornima Lalwaney
-   Nokia
-   12278 Scripps Summit Drive
-   San Diego, CA  92131
-   Email: poornima.lalwaney@nokia.com
-
-
-11. Expiration
-
-   This memo is filed as <draft-smedvinsky-dhc-kerbauth-01.txt>, and
-   expires January 1, 2001.
-
-
-
-12. Intellectual Property Notices
-
-
-
-
-
-
-S. Medvinsky, P. Lalwaney                                         -15-        
-
-Kerberos V Authentication Mode for Uninitialized Clients    March 2000
-
-
-      This section contains two notices as required by [13] for
-   standards track documents.  Per [13], section 10.4(A):
-
-     The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights. Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11. Copies of
-   claims of rights made available for publication and any assurances
-   of licenses to be made available, or the result of an attempt made
-   to obtain a general license or permission for the use of such
-   proprietary rights by implementers or users of this specification
-   can be obtained from the IETF Secretariat.
-
-      Per [13] section 10.4(D):
-
-      The IETF has been notified of intellectual property rights
-   claimed in regard to some or all of the specification contained in
-   this document.  For more information consult the online list of
-   claimed rights.
-
-   13. Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph
-   are included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.  The limited permissions granted above are perpetual and
-   will not be revoked by the Internet Society or its successors or
-   assigns. This document and the information contained herein is
-   provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
-   INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-S. Medvinsky, P. Lalwaney                                         -16-
-
\ No newline at end of file
diff --git a/doc/standardisation/draft-srp.txt b/doc/standardisation/draft-srp.txt
deleted file mode 100644
index 9c4cc954d..000000000
--- a/doc/standardisation/draft-srp.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                             Love Hornquist Astrand
-<draft-hornquist-astrand-krb-wg-srp.txt>          Stockholms universitet
-Internet-Draft                                            December, 2003
-Expire in six months
-
-            Using SRP for Initial Authentication in Kerberos
-
-Status of this Memo
-
-ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt
-
-   This memo provides information for the Internet community. ...
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved. ...
-
-
-Abstract
-
-   This document describes how to use SRP as a preauthentication
-   mechanism in Kerberos 5 [RFC1510].  This mechanism makes the initial
-   ticket request and response secure against dictionary attacks on
-   users passwords.
-
-Introduction
-
-   Kerberos without preauthentication make the protocol susceptible to
-   both to password dictionary attacks on initial tickets.  There are
-   several pre-authentication mechanisms that tries to solve and/or
-   minimize this problem.
-
-   Encrypted time stamp have the same problem as Kerberos without
-   preauthentication, opportunities of the attacker to get key material
-   is only fewer.  SAM require hardware token and typically, for most
-   SAM types, still require the user to have a password since they don't
-   provide enough key-material for Kerberos to encrypt the response
-   with.  PKINIT large and complicated, and like SAM often require
-   hardware.  Extra-tgt requires infrastructure to use, a key/bootstrap
-   must be present on each host that the users are expected to use.
-
-   The dictionary attack can also be solved by forcing the users to
-   select good password.
-
-   XXX Jacques' DH preauth ?
-   XXX tls protected as-req
-
-   SRP, Secure Remote Password protocol, [RFC2945], is a password
-
-
-
-Hornquist Astrand                                               [Page 1]
-
-Internet Draft                                            December, 2003
-
-
-   authentication and key-exchange protocol that can be used over
-   untrusted networks.  SRP is designed to be resistable to dictionary
-   attacks (both by passive and active attackers).
-
-Specification
-
-   This document is based on SRP-6.
-
-   XXX read and think about rfc2944 (SRP over telnet)
-
-   SRP + Kerberos 5 preauthentication
-
-   Krb-srp-cookie in the protocol to enable the server be stateless.
-
-   TBA KRB-SRP-PREAUTH number
-
-   - Client send the AS-REQ
-
-   - Server looks up the principal, and finds N, g, v, salt, H.  Then
-   the server generates the random number b and calculate B.  All
-   operations are performed modulus N.
-
-        B = 3v + g^b
-
-   and sends back a KRB-SRP-CHALLENGE md-data in a KRB-ERROR. If the
-   server is stateless, it can store the information (encrypted) it
-   needs in krb-srp-cookie.
-
-   - If the client chooses to use the SRP preauthentication mechanism it
-   sends back KRB-SRP-CLIENT-RESPONSE.  If krb-srp-cookie is present in
-   KRB-SRP-CHALLENGE its copied to KRB-SRP-CLIENT-RESPONSE.  The client
-   generates the random number a and calculates
-
-        A = g^a
-        S = (B - 3g^x)^(a+ux)
-        M1 = H(DER(A) | DER(B) | DER(S))
-
-   u is H(DER(A) | DER(B)), where DER(n) is the n encoded with the
-   integer tag.
-
-   The client then it calculates the shared key K
-
-        K = s-to-key-bytes(S)
-
-   KRB-SRP-CLIENT-RESPONSE-ENC-DATA is filled in by the client,
-   encrypted with the shared key K
-
-   XXX should a keyed checksum just be used instead ?
-
-
-
-Hornquist Astrand                                               [Page 2]
-
-Internet Draft                                            December, 2003
-
-
-   XXX does this replace the need for M1
-
-   - When the server receives the KRB-SRP-CLIENT-RESPONSE response it
-   calculates
-
-        S = (Av^u)^b
-
-   and the shared key K,
-
-        K = s-to-key-bytes(S)
-
-   verifies the content in krb-srp-enc, and M1.  If everything checks
-   out ok, the server sends back the AS-REP.  The key that the AS-REP is
-   encrypted with is the SRP session key, K.
-
-   XXX Should the server send back M2 ?
-
-   s-to-key defined as:
-
-        b = DER(S)
-        if length of b is even, drop first char
-        b1 = H(b[0] | b[2] | b[4] | ...)
-        b2 = H(b[1] | b[3] | b[5] | ...)
-        K = random-to-key(b1 | b2).
-
-   random-to-key is the random to key function in [KCRYPTO].
-
-ASN.1 specification
-
-   XXX Krb-Nonce
-
-   KERBEROS-PREAUTH-SRP DEFINITIONS ::=
-
-   BEGIN
-
-   IMPORTS Checksum, Krb-Nonce FROM krb5;
-
-   KRB-SRP-CHALLENGE ::= SEQUENCE {
-           krb-srp-salt[0]         OCTET STRING,
-           krb-srp-N[1]            INTEGER,
-           krb-srp-g[2]            INTEGER,
-           krb-srp-B[3]            INTEGER,
-           krb-srp-hash[4]         OBJECT IDENTIFIER,
-           krb-srp-flags[5]        INTEGER (SIZE 4),
-           krb-srp-cookie[6]       OCTET STRING OPTIONAL -- must include nonce ?
-   }
-
-   -- flags: "use combined s2k + srp key" ?
-
-
-
-Hornquist Astrand                                               [Page 3]
-
-Internet Draft                                            December, 2003
-
-
-   KRB-SRP-CLIENT-RESPONSE ::= SEQUENCE {
-           krb-srp-A[0]            INTEGER,
-           krb-srp-M1[1]           OCTET STRING,
-           krb-srp-hash[2]         OBJECT IDENTIFIER,
-           krb-srp-enc[3]          EncryptedData, -- bind nonce to pa
-           krb-srp-cookie[4]       OCTET STRING OPTIONAL
-   }
-
-   KRB-SRP-CLIENT-RESPONSE-ENC-DATA :: SEQUENCE {
-           krb-srp-checksum[0]     Checksum,
-           krb-srp-flags[1]        INTEGER (SIZE 4),
-           krb-srp-nonce[2]        Krb-Nonce
-   }
-
-   KRB-SRP-SERVER-RESPONSE ::= SEQUENCE {
-           krb-srp-M2[0]           OCTET STRING
-   }
-
-   END
-
-Issues
-
-   send group/generator by name ?
-
-   how to bind request to pa data ?
-
-   what key should be used, the key from SRP, or the compiled key from
-   s2k + SRP, right now its a flag.
-
-Requirements on the KDC
-
-   The KDC needs to know more information for each principal.  At least
-   the KDC needs to store:
-
-   N, the safe prime
-   g, the generator
-   v, the password verifier
-   salt, that salt that the principal used to form the verifier, v
-   H, hash function used to form the verifier, v
-
-   Also, since the KDC no longer have a list of keys, and thus an
-   implicit list what encryption types the principal is allowed use, it
-   needs to have a list for all the encryption types a user is allowed
-   to use with SRP preauthentication mechanism.
-
-Security considerations
-
-   SRP
-
-
-
-Hornquist Astrand                                               [Page 4]
-
-Internet Draft                                            December, 2003
-
-
-   see Security considerations in Nisses SSH SRP draft.
-
-   Kerberos
-
-   Preauthentication
-
-   SRP preauthentication mechanism doesn't require the client to compute
-   something before the server sends "expensive" cryptographic
-   operations.
-
-   Preauthentication have the problem that the response is not
-   authenticated, so a active attacker can modify that response from the
-   KDC to remove SRP to have the client choose a weaker initial
-   authentication method.
-
-References
-
-   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
-   Authentication Service (V5)", RFC 1510, September 1993.
-
-   [SRP] T. Wu, "The Secure Remote Password Protocol", In Proceedings of
-   the 1998 ISOC Network and Distributed System Security Symposium, San
-   Diego, CA, pp. 97-111.
-
-   [RFC2945] Wu, T, "The SRP Authentication and Key Exchange System",
-   RFC2945, September 2000.
-
-   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
-   Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003.  Work in
-   progress.
-
-Author's Address
-
-   Love Hornquist Astrand
-   Enheten for it och media
-   Stockholms universitet
-   S-106 91  STOCKHOLM
-   SWEDEN
-
-   EMail: lha@it.su.se
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved. ...
-
-
-
-
-
-
-
-Hornquist Astrand                                               [Page 5]
-
diff --git a/doc/standardisation/draft-swift-win2k-krb-referrals-00.txt b/doc/standardisation/draft-swift-win2k-krb-referrals-00.txt
deleted file mode 100644
index f5d1c4c2e..000000000
--- a/doc/standardisation/draft-swift-win2k-krb-referrals-00.txt
+++ /dev/null
@@ -1,412 +0,0 @@
-CAT Working Group                                              M. Swift 
-Internet Draft                                                Microsoft 
-Document: draft-swift-win2k-krb-referrals-00.txt           October 1999 
-Category: Informational                                                 
- 
- 
-           Generating KDC Referrals to locate Kerberos realms 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1].  
-    
-   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."  
-    
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   The draft documents a new method for a Kerberos Key Distribution 
-   Center (KDC) to respond to client requests for tickets as is used in 
-   Microsoft's Windows 2000 implementation of Kerberos. The KDC will 
-   handle requests for principals in other realms by returning either a 
-   referral error or a cross-realm TGT to another realm on the referral 
-   path. 
-    
-2. Conventions used in this document 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-    
-3. Introduction 
-    
-   The Kerberos TGS and AS protocols, as defined in RFC 1510 [3], 
-   require that client software be able to parse principal names into a 
-   realm and an account portion. However, if a site want to deploy a 
-   Kerberos realm infrastructure separately from its DNS 
-   infrastructure, Kerberos must be able to handle the case where the 
-   client software does not know what realm contains a given service or 
-   user principal name. In addition, the current protocol requires the 
-   client to know the hierarchy of realms by explicitly asking for a 
-
-  
-Swift                  Category - Informational                      1 
-
-                            KDC Referrals                October 1999 
- 
- 
-   referral to a specific realm rather than letting the KDC pick the 
-   next realm on the referral path. 
-    
-   To rectify these problems, this draft introduces three new kinds of 
-   KDC referrals: 
-    
-   1. AS ticket referrals, in which the client doesnÆt know which realm 
-     contains a user account. 
-   2. TGS ticket referrals, in which the client doesnÆt know which realm 
-     contains a server account. 
-   3. Cross realm shortcut referrals, in which the KDC chooses the next 
-     path on a referral chain 
-    
-4. Realm Organization Model 
-    
-   This draft assumes that the world of principals is arranged on 
-   multiple levels: the realm, the enterprise, and the world. A KDC may 
-   issue tickets for any principal in its realm or cross-realm tickets 
-   for realms with which it has a direct trust relationship. The KDC 
-   also has access to a trusted directory or name service that can 
-   resolve any name from within its enterprise into a realm. This 
-   trusted name service removes the need to use an untrusted DNS lookup 
-   for name resolution. 
-    
-   For example, consider the following configuration, where lines 
-   indicate trust relationships: 
-    
-                  MS.COM  
-                /        \ 
-               /          \ 
-        OFFICE.MS.COM    NT.MS.COM 
-    
-   In this configuration, all users in the MS.COM enterprise could have 
-   a principal name such as alice@ms.com, with the same realm portion. 
-   In addition, servers at MS.COM should be able to have DNS host names 
-   from any DNS domain independent of what Kerberos realm their 
-   principal resides in. 
-    
-5. Principal Names 
-    
-5.1 Service Principal Names 
-    
-   The standard Kerberos model in RFC 1510 [3] gives each Kerberos 
-   principal a single name. However, if a service is reachable by 
-   several addresses, it may be useful for a principal to have multiple 
-   names. Consider a service running on a multi-homed machine. Rather 
-   than requiring a separate principal and password for each name it 
-   exports, a single account with multiple names could be used. 
-    
-   Multiple names are also useful for services in that clients need not 
-   perform DNS lookups to resolve a host name into a full DNS address. 
-   Instead, the service may have a name for each of its supported host 
-   names, including its IP address. Nonetheless, it is still convenient 
-  
-Swift                  Category - Informational                      2 
-
-                            KDC Referrals                October 1999 
- 
- 
-   for the service to not have to be aware of all these names. Thus a 
-   new name may be added to DNS for a service by updating DNS and the 
-   KDC database without having to notify the service. In addition, it 
-   implies that these aliases are globally unique: they do not include 
-   a specifier dictating what domain contains the principal. Thus, an 
-   alias for a server is of the form "name/name/name" and may be 
-   transmitted as any name type. 
-    
-5.2 Client Principal Names 
-    
-   Similarly, a client account may also have multiple principal names. 
-   More useful, though, is a globally unique name that allows 
-   unification of email and security principal names. For example, all 
-   users at Microsoft may have a client principal name of the form 
-   "joe@MS.COM" even though the principals are contained in multiple 
-   realms. This global name is again an alias for the true client 
-   principal name, which is indicates what realm contains the 
-   principal. Thus, accounts "alice" in the realm ntdev.MS.COM and 
-   "bob" in office.MS.COM may logon as "alice@MS.COM" and "bob@MS.COM". 
-   This change requires a new client principal name type, as the AS-REQ 
-   message only contains a single realm field, and the realm portion of 
-   this name doesn't correspond to any realm security realm. Thus, the 
-   entire name "alice@MS.COM" is transmitted in the client name field 
-   of the AS-REQ message, with a name type of KRB-NT-ENTERPRISE-
-   PRINCIPAL. 
-    
-        #define KRB-NT-ENTERPRISE-PRINCIPAL     10 
-    
-5.3 Name Canonicalization 
-    
-   In order to support name aliases, the Kerberos client must 
-   explicitly request the name-canonicalization KDC option (bit 12) in 
-   the ticket flags for the TGS-REQ. This option is an indicator to the 
-   KDC that if it fails to find the name in the local database as a 
-   normal principal name, it should try to look the name up as an alias 
-   both locally and in a global directory. This flag indicates to the 
-   KDC that the client is prepared to receive a reply with a different 
-   client or server principal name than the request. Thus, the 
-   KDCOptions types is redefined as: 
-    
-        KDCOptions ::=   BIT STRING { 
-                          reserved(0), 
-                          forwardable(1), 
-                          forwarded(2), 
-                          proxiable(3), 
-                          proxy(4), 
-                          allow-postdate(5), 
-                          postdated(6), 
-                          unused7(7), 
-                          renewable(8), 
-                          unused9(9), 
-                          unused10(10), 
-                          unused11(11), 
-  
-Swift                  Category - Informational                      3 
-
-                            KDC Referrals                October 1999 
- 
- 
-                          name-canonicalize(12), 
-                          renewable-ok(27), 
-                          enc-tkt-in-skey(28), 
-                          renew(30), 
-                          validate(31) 
-         } 
-    
-6. Client Referrals 
-    
-   The simplest form of ticket referral is for a user requesting a 
-   ticket using an AS-REQ. In this case, the client machine will send 
-   the AS request to a convenient realm, probably either the realm of 
-   the client machine or the realm portion of the client name. In the 
-   case of the name Alice@MS.COM, the client may optimistically choose 
-   to send the request to MS.COM. The client will send the string 
-   "alice@MS.COM" in the client principal name field using the KRB-NT-
-   ENTERPRISE-PRINCIPAL name type. The KDC will try to lookup the name 
-   in its local account database. If the account is present, it will 
-   return a KDC reply structure with the appropriate ticket. If the 
-   account is not present and the name-canonicalize option is 
-   requested, it will try to lookup the entire name (Alice@MS.COM) in 
-   the global directory. If this lookup is unsuccessful, it will return 
-   the error KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup is successful, 
-   it will return an error KDC_ERR_WRONG_REALM (0x44) and in the error 
-   message, the cname and crealm field will contain the client name and 
-   the true realm of the client. If the KDC contains the account 
-   locally, it will return a normal ticket. The client name and realm 
-   portions of the ticket and KDC reply message will be the client's 
-   true name in the realm, not the globally unique name. 
-    
-   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 
-   new AS request to the realm specified by the crealm field of the 
-   error message. 
- 
-7. Server Referrals 
-    
-   The server referral mechanism is a bit more complex than the client 
-   referral mechanism. The primary problem is that the KDC must return 
-   a referral ticket rather than an error message, so it must include 
-   in the TGS response information about what realm contains the 
-   service. This is done by returning information about the server name 
-   in the pre-auth data field of the KDC reply. 
-    
-   If the KDC resolves the server principal name into a principal in 
-   its realm, it may return a normal ticket. If the name-canonicalize 
-   bit is not set, then the KDC should only look up the name as a 
-   normal principal name. Otherwise, it should search all aliases as 
-   well. The server principal name in both the ticket and the KDC reply 
-   should be the true server principal name instead of one of the 
-   aliases. This prevents the application server from needing to know 
-   about all its aliases. 
-    
-
-  
-Swift                  Category - Informational                      4 
-
-                            KDC Referrals                October 1999 
- 
- 
-   If the KDC doesnÆt find the principal locally but is able to 
-   resolved it into a realm from the global directory, then it should 
-   return a cross-realm ticket granting ticket to the next hop on the 
-   trust path towards that realm. In this case, the KDC will return the 
-   server realm as a PA data type. The data itself is an ASN.1 encoded 
-   structure containing the server's realm, and if known, true 
-   principal name. The preauthentication data type is KRB5-PADATA-
-   SERVER-REFERRAL-INFO. 
-    
-        #define KRB5-PADATA-SERVER-REFERRAL-INFO        20 
-         
-        KERB-PA-SERV-REFERRAL   ::= SEQUENCE { 
-                referred-server-name[1]   KERB-PRINCIPAL-NAME OPTIONAL, 
-                referred-server-realm[0]  KERB-REALM 
-        } 
-    
-   The client may use the referred-server-name field to tell if it 
-   already has a ticket to the server in its ticket cache. 
-    
-   The client can use this information to request a chain of cross-
-   realm ticket granting tickets until it reaches this realm, and can 
-   then expect to receive a valid service ticket. 
-    
-8. Cross Realm Routing 
-    
-   The current Kerberos protocol requires the client libraries to 
-   explicitly request a cross-realm TGT for each pair of realms on a 
-   referral chain. As a result, the client machines need to be aware of 
-   the trust hierarchy and of any short-cut trusts (those that arenÆt 
-   parent-child trusts). This requires a lot of configuration on the 
-   client. Instead, the client should be able to request a TGT to the 
-   target realm from each realm on the route. The KDC will determine 
-   the best path for the client and return a cross-realm TGT. The 
-   client software has to be aware that a request for a cross-realm TGT 
-   may return a TGT for a realm different from the one requested. 
-    
-9. Security Considerations 
- 
-   The original Kerberos specification stated that the server principal 
-   name in the KDC reply was the same as the server name in the 
-   request. These protocol changes break that assumption, so the client 
-   may be vulnerable to a denial of service attack by an attacker that 
-   replays replies from previous requests. It can verify that the 
-   request was one of its own by checking the client-address field or 
-   authtime field, though, so the damage is limited. 
-    
-10. References 
-    
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
- 
-  
-Swift                  Category - Informational                      5 
-
-                            KDC Referrals                October 1999 
- 
- 
- 
-   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   3  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
-      Service (V5)", RFC 1510, September 1993 
-    
-    
-10. Author's Addresses 
-    
-   Michael Swift 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: mikesw@microsoft.com 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                      6 
-
-                            KDC Referrals                October 1999 
- 
- 
-    
-Full Copyright Statement 
- 
-   Copyright (C) The Internet Society (1999).  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this   
-   document itself may not be modified in any way, such as by removing   
-   the copyright notice or references to the Internet Society or other   
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
-    
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                      7 
-
\ No newline at end of file
diff --git a/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt b/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt
deleted file mode 100644
index 85d745684..000000000
--- a/doc/standardisation/draft-swift-win2k-krb-referrals-01.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-This Internet-Draft has expired and is no longer available.
-
-Unrevised documents placed in the Internet-Drafts directories have a
-maximum life of six months. After that time, they must be updated, or
-they will be deleted. This document was deleted on July 17, 2000.
diff --git a/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt b/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt
deleted file mode 100644
index 929fdfce2..000000000
--- a/doc/standardisation/draft-swift-win2k-krb-user2user-01.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-Kerberos Working Group                                         M. Swift 
-Internet Draft                                         University of WA 
-Document: draft-swift-win2k-krb-user2user-01.txt              J. Brezak 
-Category: Informational                                       Microsoft 
-                                                               P. Moore 
-                                                    Sandia National Labs
-                                                              March 2001 
-
- 
-           User to User Kerberos Authentication using GSS-API 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1].  
-    
-   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."  
-    
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   This draft documents a simple extension to the Kerberos GSS-API 
-   mechanism to support user to user authentication both in the case 
-   where the client application explicitly requests user to user 
-   authentication and when it does not know whether the server supports 
-   user to user authentication. 
-    
-2. Conventions used in this document 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-    
-    
-3. Introduction 
-    
-   The Kerberos user to user authentication mechanism allows for a 
-   client application to connect to a service that is not in possession 
-   of a long term secret key. Instead, the session ticket from the 
-   KERB-AP-REQ is encrypted using the session key from the service's 
-   ticket granting ticket. According to RFC 1510 [3]: 
-    
-
-  
-Swift                  Category - Informational                      1 
-
-
-
-
-
-
-
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
-        If the ENC-TKT-IN-SKEY option has been specified and an 
-        additional ticket has been included in the request, the KDC 
-        will decrypt the additional ticket using the key for the server 
-        to which the additional ticket was issued and verify that it is 
-        a ticket-granting ticket. If the request succeeds, the session 
-        key from the additional ticket will be used to encrypt the new 
-        ticket that is issued instead of using the key of the server 
-        for which the new ticket will be used (This allows easy 
-        implementation of user-to-user authentication, which uses 
-        ticket-granting ticket session keys in lieu of secret server 
-        keys in situations where such secret keys could be easily 
-        compromised). 
-    
-   RFC2078 [5], in section 5.2, discusses a ôDouble-TGT K-5ö mechanism 
-   and scenario, but not in the detail required in order to implement 
-   the mechanism.  The RFC for the Kerberos V5 GSS-API mechanism at the 
-   time this draft was prepared, RFC 1964 [4] does not support user-to-
-   user authentication.  
-    
-   This draft provides details as to mechanism type, token identifiers, 
-   messages and message types sufficient to document an implementation 
-   of user-to-user authentication in Kerberos GSS-API.  It follows the 
-   scenario described in RFC2078. 
-    
-   The approach documented in this draft has been used to support user-
-   to-user authentication in the Microsoft Windows 2000 SSPI with the 
-   Kerberos V5 protocol, and in a patched Kerberos V5 implementation 
-   being used to support a computing grid at Sandia, Lawrence 
-   Livermore, and Los Alamos National Laboratories. 
-    
-4. User to User as a New Mechanism 
-    
-   A new mechanism OID may be used to establish a user-to-user session: 
-    
-        {iso(1) member-body(2) United States(840) mit(113554) 
-        infosys(1) gssapi(2) krb5(2) usertouser(3)}  
-    
-   In the case that the client application knows that the server 
-   requires user-to-user authentication, then the initial call to 
-   GSS_Init_Sec_Context will request this mechanism. This new mechanism 
-   is used with a token exchange that extends the conventional Kerberos 
-   GSS-API protocol by adding an additional round trip to request the 
-   TGT from the service. As with all Kerberos GSS-API messages, the 
-   following tokens are encapsulated in the GSS-API framing. The first 
-   token of the exchange will have an innerContextToken with a 2-octet 
-   TOK_ID field containing 04 00 (KERB-TGT-REQUEST) followed by a 
-   Kerberos V5 message as follows: 
-    
-        KERB-TGT-REQUEST ::= SEQUENCE { 
-                pvno[0]                         INTEGER, 
-                msg-type[1]                     INTEGER, 
-                server-name[2]                  PrincipalName OPTIONAL, 
-                realm[3]                        Realm OPTIONAL 
-  
-Swift                  Category - Informational                      2 
-
-
-
-
-
-
-
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
-        } 
-         
-   The TGT request consists of four fields: 
-    
-        pvno and msg-type are as defined in RFC1510 section 5.4.1. msg-
-                type is KRB_TGT_REQ (16). 
-         
-        server-name : this field optionally contains the name of the 
-                server. If the client application doesn't know the 
-                server name this can be left blank and the server 
-                application will pick the appropriate server 
-                credentials which may be the default credential. 
-         
-        realm : this field optionally contains the realm of the server. 
-                If the client application doesn't know the server realm 
-                this field can be left blank and the server application 
-                will pick the appropriate server credentials which may 
-                be the server's default realm. 
-         
-   The server name and realm are included to allow a server application 
-   to act for multiple principles in different realms and to choose 
-   which credentials to use. 
-    
-   The response to the KERB-TGT-REQUEST message will be a 
-   KERB_TGT_REPLY token which will have an innerContextToken with a 2-
-   octet TOK_ID field containing 04 01 (KERB-TGT-REPLY) followed by a 
-   Kerberos V5 message as follows: 
-    
-        KERB-TGT-REPLY ::= SEQUENCE { 
-                pvno[0]                         INTEGER, 
-                msg-type[1]                     INTEGER, 
-                ticket[2]                       Ticket 
-                } 
-    
-   The TGT reply contains the following fields: 
-    
-        pvno and msg-type are as defined in RFC1510 section 5.4.1. msg-
-                type is KRB_TGT_REP (17) 
-         
-        ticket : contains the TGT for the service specified by the 
-                server name and realm passed by the client or the 
-                default service. 
-    
-   If the service does not possess a ticket granting ticket, it should 
-   return the error KRB_AP_ERR_NO_TGT (0x43). 
-    
-   If the server name and realm in the KERB-TGT-REQUEST message do not 
-   match the name of the service, then the service should return the 
-   error KRB_AP_ERR_NOT_US. 
-    
-   Following the exchange of the TGT request messages, the initiator 
-   requests a ticket to the service from the KDC using a KERB-TGS-REQ 
-   with the KDCoption ENC-TKT-IN_SKEY and the second ticket in the 
-  
-Swift                  Category - Informational                      3 
-
-
-
-
-
-
-
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
-   additional-tickets of the KDC-REQ-BODY. Upon receipt of the TGS-REP 
-   the rest of the authentication identical to the Kerberos GSS-API 
-   mechanism defined in RFC 1964 [4]. 
-    
-5. User-to-User when applied via KDC policy 
-    
-   Implementations MAY support the ability apply a policy on a user 
-   account such that the KDC will not allow conventional service ticket 
-   requests, and when presented with a KERB_TGS_REQ that does not 
-   contain a second ticket with an ENC_TKT_IN_SKEY KDCoption will 
-   respond with a KRB-ERROR with the msg-type 
-   KDC_ERR_MUST_USE_USER2USER (or KRB5PLACEHOLD_27). 
-    
-   In this case, the client need not explicitly request user-to-user in 
-   order to get a user-to-user connection. Implementations may use this 
-   error code to set a flag and return a GSS_C_CONTINUE_NEEDED so that 
-   the next round uses the mechanism described in section 4.   
-    
-6. User to User when applied by server policy 
-    
-   In the case that the client application doesn't know that a service 
-   requires user-to-user authentication, and requests and receives a 
-   conventional KRB_AP_REP, the client will send the KRB_AP_REP 
-   request, and the server will respond with a KRB_ERROR token as 
-   described in RFC1964, with a msg-type of 
-   KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally 
-   pass the TGT in the data field of this error message. In response to 
-   this error, the initiator sets flags and returns a 
-   GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism 
-   described in section 4. 
-    
-7. Security Considerations 
- 
-   These extensions simply enable an existing Kerberos 5 authentication 
-   protocol so that it may be used from GSSAPI. 
-    
-   There is some risk in a server handing out its ticket-granting-
-   ticket to any client that requests it, in that it gives an attacker 
-   a piece of encrypted material to decrypt. However, the same material 
-   may be obtained from listening to any legitimate client connection. 
-    
-   It should be noted here that the exchange described in section 6 
-   requires that the KDC provide tickets for user accounts, which will 
-   contain known plaintext encrypted in the usersÆ private key. The 
-   risk associated with this is entirely mitigated where a KDC supports 
-   the KDC_MUST_USE_USER2USER feature, which allows a restriction on 
-   user accounts to ensure that all tickets for that account are 
-   encrypted in the TGT session key, and not the long term key of the 
-   user. 
-    
-8. References 
-    
-
-  
-Swift                  Category - Informational                      4 
-
-
-
-
-
-
-
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   3  J. Kohl, C. Neuman, "The Kerberos Network Authentication 
-      Service(V5)",  RFC 1510. 
-    
-   4  J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964 
-    
-   5  J. Linn, ôGeneric Security Service Application Program Interface, 
-      Version 2ö, RFC 2078 
-    
-9. Author's Addresses 
-    
-   Michael Swift 
-   University of Washington 
-   Seattle, Washington 
-   Email: mikesw@cs.washington.edu 
-    
-   John Brezak 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@microsoft.com 
-    
-   Patrick Moore 
-   Sandia National Laboratories 
-   PO Box 5800 Mail Stop 
-   Albuquerque, New Mexico 
-   Email: pcmoore@sandia.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                      5 
-
-
-
-
-
-
-
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
-    
- Full Copyright Statement 
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this   
-   document itself may not be modified in any way, such as by removing   
-   the copyright notice or references to the Internet Society or other   
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
-    
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                      6 
-
-
-
-
-
-
-
diff --git a/doc/standardisation/draft-swift-win2k-krb-user2user-02.txt b/doc/standardisation/draft-swift-win2k-krb-user2user-02.txt
deleted file mode 100644
index c0424bf7e..000000000
--- a/doc/standardisation/draft-swift-win2k-krb-user2user-02.txt
+++ /dev/null
@@ -1,354 +0,0 @@
-
-
-Kerberos Working Group                                         M. Swift 
-Internet Draft                                         University of WA 
-Document: draft-swift-win2k-krb-user2user-02.txt              J. Brezak 
-Category: Informational                                       Microsoft 
-                                                               P. Moore 
-                                                    Sandia National Labs
-                                                              April 2001 
- 
-
-           User to User Kerberos Authentication using GSS-API 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1].  
-    
-   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."  
-    
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   This draft documents a simple extension to the Kerberos GSS-API 
-   mechanism to support user to user authentication both in the case 
-   where the client application explicitly requests user to user 
-   authentication and when it does not know whether the server supports 
-   user to user authentication. 
-    
-2. Conventions used in this document 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-    
-    
-3. Introduction 
-    
-   The Kerberos user to user authentication mechanism allows for a 
-   client application to connect to a service that is not in possession 
-   of a long term secret key. Instead, the session ticket from the 
-   KERB-AP-REQ is encrypted using the session key from the service's 
-   ticket granting ticket. According to RFC 1510 [3]: 
-    
-
-  
-Swift                  Category - Informational                      1 
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
-        If the ENC-TKT-IN-SKEY option has been specified and an 
-        additional ticket has been included in the request, the KDC 
-        will decrypt the additional ticket using the key for the server 
-        to which the additional ticket was issued and verify that it is 
-        a ticket-granting ticket. If the request succeeds, the session 
-        key from the additional ticket will be used to encrypt the new 
-        ticket that is issued instead of using the key of the server 
-        for which the new ticket will be used (This allows easy 
-        implementation of user-to-user authentication, which uses 
-        ticket-granting ticket session keys in lieu of secret server 
-        keys in situations where such secret keys could be easily 
-        compromised). 
-    
-   RFC2078 [5], in section 5.2, discusses a "Double-TGT K-5" mechanism 
-   and scenario, but not in the detail required in order to implement 
-   the mechanism.  The RFC for the Kerberos V5 GSS-API mechanism at the 
-   time this draft was prepared, RFC 1964 [4] does not support user-to-
-   user authentication.  
-    
-   This draft provides details as to mechanism type, token identifiers, 
-   messages and message types sufficient to document an implementation 
-   of user-to-user authentication in Kerberos GSS-API.  It follows the 
-   scenario described in RFC2078. 
-    
-   The approach documented in this draft has been used to support user-
-   to-user authentication in the Microsoft Windows 2000 SSPI with the 
-   Kerberos V5 protocol, and in a patched Kerberos V5 implementation 
-   being used to support a computing grid at Sandia, Lawrence 
-   Livermore, and Los Alamos National Laboratories. 
-    
-4. User to User as a New Mechanism 
-    
-   A new mechanism OID may be used to establish a user-to-user session: 
-    
-        {iso(1) member-body(2) United States(840) mit(113554) 
-        infosys(1) gssapi(2) krb5(2) usertouser(3)}  
-    
-   In the case that the client application knows that the server 
-   requires user-to-user authentication, then the initial call to 
-   GSS_Init_Sec_Context will request this mechanism. This new mechanism 
-   is used with a token exchange that extends the conventional Kerberos 
-   GSS-API protocol by adding an additional round trip to request the 
-   TGT from the service. As with all Kerberos GSS-API messages, the 
-   following tokens are encapsulated in the GSS-API framing. The first 
-   token of the exchange will have an innerContextToken with a 2-octet 
-   TOK_ID field containing 04 00 (KERB-TGT-REQUEST) followed by a 
-   Kerberos V5 message as follows: 
-    
-        KERB-TGT-REQUEST ::= SEQUENCE { 
-                pvno[0]                         INTEGER, 
-                msg-type[1]                     INTEGER, 
-                server-name[2]                  PrincipalName OPTIONAL, 
-                realm[3]                        Realm OPTIONAL 
-  
-Swift                  Category - Informational                      2 
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
-        } 
-         
-   The TGT request consists of four fields: 
-    
-        pvno and msg-type are as defined in RFC1510 section 5.4.1. msg-
-                type is KRB_TGT_REQ (16). 
-         
-        server-name : this field optionally contains the name of the 
-                server. If the client application doesn't know the 
-                server name this can be left blank and the server 
-                application will pick the appropriate server 
-                credentials which may be the default credential. 
-         
-        realm : this field optionally contains the realm of the server. 
-                If the client application doesn't know the server realm 
-                this field can be left blank and the server application 
-                will pick the appropriate server credentials which may 
-                be the server's default realm. 
-         
-   The server name and realm are included to allow a server application 
-   to act for multiple principles in different realms and to choose 
-   which credentials to use. 
-    
-   The response to the KERB-TGT-REQUEST message will be a 
-   KERB_TGT_REPLY token which will have an innerContextToken with a 2-
-   octet TOK_ID field containing 04 01 (KERB-TGT-REPLY) followed by a 
-   Kerberos V5 message as follows: 
-    
-        KERB-TGT-REPLY ::= SEQUENCE { 
-                pvno[0]                         INTEGER, 
-                msg-type[1]                     INTEGER, 
-                ticket[2]                       Ticket 
-                } 
-    
-   The TGT reply contains the following fields: 
-    
-        pvno and msg-type are as defined in RFC1510 section 5.4.1. msg-
-                type is KRB_TGT_REP (17) 
-         
-        ticket : contains the TGT for the service specified by the 
-                server name and realm passed by the client or the 
-                default service. 
-    
-   If the service does not possess a ticket granting ticket, it should 
-   return the error KRB_AP_ERR_NO_TGT (0x43). 
-    
-   If the server name and realm in the KERB-TGT-REQUEST message do not 
-   match the name of the service, then the service should return the 
-   error KRB_AP_ERR_NOT_US. 
-    
-   Following the exchange of the TGT request messages, the initiator 
-   requests a ticket to the service from the KDC using a KERB-TGS-REQ 
-   with the KDCoption ENC-TKT-IN_SKEY and the second ticket in the 
-  
-Swift                  Category - Informational                      3 
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
-   additional-tickets of the KDC-REQ-BODY. Upon receipt of the TGS-REP 
-   the rest of the authentication identical to the Kerberos GSS-API 
-   mechanism defined in RFC 1964 [4]. 
-    
-5. User-to-User when applied via KDC policy 
-    
-   Implementations MAY support the ability apply a policy on a user 
-   account such that the KDC will not allow conventional service ticket 
-   requests, and when presented with a KERB_TGS_REQ that does not 
-   contain a second ticket with an ENC_TKT_IN_SKEY KDCoption will 
-   respond with a KRB-ERROR with the msg-type 
-   KDC_ERR_MUST_USE_USER2USER (or KRB5PLACEHOLD_27). 
-    
-   In this case, the client need not explicitly request user-to-user in 
-   order to get a user-to-user connection. Implementations may use this 
-   error code to set a flag and return a GSS_C_CONTINUE_NEEDED so that 
-   the next round uses the mechanism described in section 4.   
-    
-6. User to User when applied by server policy 
-    
-   In the case that the client application doesn't know that a service 
-   requires user-to-user authentication, and requests and receives a 
-   conventional KRB_AP_REP, the client will send the KRB_AP_REP 
-   request, and the server will respond with a KRB_ERROR token as 
-   described in RFC1964, with a msg-type of 
-   KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally 
-   pass the TGT in the data field of this error message. In response to 
-   this error, the initiator sets flags and returns a 
-   GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism 
-   described in section 4. 
-    
-7. Security Considerations 
- 
-   These extensions simply enable an existing Kerberos 5 authentication 
-   protocol so that it may be used from GSSAPI. 
-    
-   There is some risk in a server handing out its ticket-granting-
-   ticket to any client that requests it, in that it gives an attacker 
-   a piece of encrypted material to decrypt. However, the same material 
-   may be obtained from listening to any legitimate client connection. 
-    
-   It should be noted here that the exchange described in section 6 
-   requires that the KDC provide tickets for user accounts, which will 
-   contain known plaintext encrypted in the usersÆ private key. The 
-   risk associated with this is entirely mitigated where a KDC supports 
-   the KDC_MUST_USE_USER2USER feature, which allows a restriction on 
-   user accounts to ensure that all tickets for that account are 
-   encrypted in the TGT session key, and not the long term key of the 
-   user. 
-    
-8. References 
-    
-
-  
-Swift                  Category - Informational                      4 
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   3  J. Kohl, C. Neuman, "The Kerberos Network Authentication 
-      Service(V5)",  RFC 1510. 
-    
-   4  J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964 
-    
-   5  J. Linn, "Generic Security Service Application Program Interface, 
-      Version 2", RFC 2078 
-    
-9. Author's Addresses 
-    
-   Michael Swift 
-   University of Washington 
-   Seattle, Washington 
-   Email: mikesw@cs.washington.edu 
-    
-   John Brezak 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@microsoft.com 
-    
-   Patrick Moore 
-   Sandia National Laboratories 
-   PO Box 5800 Mail Stop 
-   Albuquerque, New Mexico 
-   Email: pcmoore@sandia.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                      5 
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
-    
- Full Copyright Statement 
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this   
-   document itself may not be modified in any way, such as by removing   
-   the copyright notice or references to the Internet Society or other   
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
-    
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                      6 
-
diff --git a/doc/standardisation/draft-swift-win2k-krb-user2user-03.txt b/doc/standardisation/draft-swift-win2k-krb-user2user-03.txt
deleted file mode 100644
index b4cd288b4..000000000
--- a/doc/standardisation/draft-swift-win2k-krb-user2user-03.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-Kerberos Working Group                                         M. Swift 
-Internet Draft                                         University of WA 
-Document: draft-swift-win2k-krb-user2user-03.txt              J. Brezak 
-Category: Informational                                       Microsoft 
-                                                               P. Moore 
-                                                    Sandia National Labs
-                                                           October 2001 
- 
- 
-           User to User Kerberos Authentication using GSS-API 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1].  
-    
-   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."  
-    
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   This draft documents a simple extension to the Kerberos GSS-API 
-   mechanism to support user to user authentication both in the case 
-   where the client application explicitly requests user to user 
-   authentication and when it does not know whether the server supports 
-   user to user authentication. 
-    
-2. Conventions used in this document 
-    
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-    
-    
-3. Introduction 
-    
-   The Kerberos user to user authentication mechanism allows for a 
-   client application to connect to a service that is not in possession 
-   of a long term secret key. Instead, the session ticket from the 
-   KERB-AP-REQ is encrypted using the session key from the service's 
-   ticket granting ticket. According to RFC 1510 [3]: 
-    
-
-  
-Swift                  Category - Informational                      1 
-
-
-
-
-
-
-
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
-        If the ENC-TKT-IN-SKEY option has been specified and an 
-        additional ticket has been included in the request, the KDC 
-        will decrypt the additional ticket using the key for the server 
-        to which the additional ticket was issued and verify that it is 
-        a ticket-granting ticket. If the request succeeds, the session 
-        key from the additional ticket will be used to encrypt the new 
-        ticket that is issued instead of using the key of the server 
-        for which the new ticket will be used (This allows easy 
-        implementation of user-to-user authentication, which uses 
-        ticket-granting ticket session keys in lieu of secret server 
-        keys in situations where such secret keys could be easily 
-        compromised). 
-    
-   RFC2078 [5], in section 5.2, discusses a "Double-TGT K-5" mechanism 
-   and scenario, but not in the detail required in order to implement 
-   the mechanism.  The RFC for the Kerberos V5 GSS-API mechanism at the 
-   time this draft was prepared, RFC 1964 [4] does not support user-to-
-   user authentication.  
-    
-   This draft provides details as to mechanism type, token identifiers, 
-   messages and message types sufficient to document an implementation 
-   of user-to-user authentication in Kerberos GSS-API.  It follows the 
-   scenario described in RFC2078. 
-    
-   The approach documented in this draft has been used to support user-
-   to-user authentication in the Microsoft Windows 2000 SSPI with the 
-   Kerberos V5 protocol, and in a patched Kerberos V5 implementation 
-   being used to support a computing grid at Sandia, Lawrence 
-   Livermore, and Los Alamos National Laboratories. 
-    
-4. User to User as a New Mechanism 
-    
-   A new mechanism OID may be used to establish a user-to-user session: 
-    
-        {iso(1) member-body(2) United States(840) mit(113554) 
-        infosys(1) gssapi(2) krb5(2) usertouser(3)}  
-    
-   In the case that the client application knows that the server 
-   requires user-to-user authentication, then the initial call to 
-   GSS_Init_Sec_Context will request this mechanism. This new mechanism 
-   is used with a token exchange that extends the conventional Kerberos 
-   GSS-API protocol by adding an additional round trip to request the 
-   TGT from the service. As with all Kerberos GSS-API messages, the 
-   following tokens are encapsulated in the GSS-API framing. The first 
-   token of the exchange will have an innerContextToken with a 2-octet 
-   TOK_ID field containing 04 00 (KERB-TGT-REQUEST) followed by a 
-   Kerberos V5 message as follows: 
-    
-        KERB-TGT-REQUEST ::= SEQUENCE { 
-                pvno[0]                         INTEGER, 
-                msg-type[1]                     INTEGER, 
-                server-name[2]                  PrincipalName OPTIONAL, 
-                realm[3]                        Realm OPTIONAL 
-  
-Swift                  Category - Informational                      2 
-
-
-
-
-
-
-
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
-        } 
-         
-   The TGT request consists of four fields: 
-    
-        pvno and msg-type are as defined in RFC1510 section 5.4.1. msg-
-                type is KRB_TGT_REQ (16). 
-         
-        server-name : this field optionally contains the name of the 
-                server. If the client application doesn't know the 
-                server name this can be left blank and the server 
-                application will pick the appropriate server 
-                credentials which may be the default credential. 
-         
-        realm : this field optionally contains the realm of the server. 
-                If the client application doesn't know the server realm 
-                this field can be left blank and the server application 
-                will pick the appropriate server credentials which may 
-                be the server's default realm. 
-         
-   The server name and realm are included to allow a server application 
-   to act for multiple principles in different realms and to choose 
-   which credentials to use. 
-    
-   The response to the KERB-TGT-REQUEST message will be a 
-   KERB_TGT_REPLY token which will have an innerContextToken with a 2-
-   octet TOK_ID field containing 04 01 (KERB-TGT-REPLY) followed by a 
-   Kerberos V5 message as follows: 
-    
-        KERB-TGT-REPLY ::= SEQUENCE { 
-                pvno[0]                         INTEGER, 
-                msg-type[1]                     INTEGER, 
-                ticket[2]                       Ticket 
-                } 
-    
-   The TGT reply contains the following fields: 
-    
-        pvno and msg-type are as defined in RFC1510 section 5.4.1. msg-
-                type is KRB_TGT_REP (17) 
-         
-        ticket : contains the TGT for the service specified by the 
-                server name and realm passed by the client or the 
-                default service. 
-    
-   If the service does not possess a ticket granting ticket, it should 
-   return the error KRB_AP_ERR_NO_TGT (0x43). 
-    
-   If the server name and realm in the KERB-TGT-REQUEST message do not 
-   match the name of the service, then the service should return the 
-   error KRB_AP_ERR_NOT_US. 
-    
-   Following the exchange of the TGT request messages, the initiator 
-   requests a ticket to the service from the KDC using a KERB-TGS-REQ 
-   with the KDCoption ENC-TKT-IN_SKEY and the second ticket in the 
-  
-Swift                  Category - Informational                      3 
-
-
-
-
-
-
-
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
-   additional-tickets of the KDC-REQ-BODY. Upon receipt of the TGS-REP 
-   the rest of the authentication identical to the Kerberos GSS-API 
-   mechanism defined in RFC 1964 [4]. 
-    
-5. User-to-User when applied via KDC policy 
-    
-   Implementations MAY support the ability apply a policy on a user 
-   account such that the KDC will not allow conventional service ticket 
-   requests, and when presented with a KERB_TGS_REQ that does not 
-   contain a second ticket with an ENC_TKT_IN_SKEY KDCoption will 
-   respond with a KRB-ERROR with the msg-type 
-   KDC_ERR_MUST_USE_USER2USER (or KRB5PLACEHOLD_27). 
-    
-   In this case, the client need not explicitly request user-to-user in 
-   order to get a user-to-user connection. Implementations may use this 
-   error code to set a flag and return a GSS_C_CONTINUE_NEEDED so that 
-   the next round uses the mechanism described in section 4.   
-    
-6. User to User when applied by server policy 
-    
-   In the case that the client application doesn't know that a service 
-   requires user-to-user authentication, and requests and receives a 
-   conventional KRB_AP_REP, the client will send the KRB_AP_REP 
-   request, and the server will respond with a KRB_ERROR token as 
-   described in RFC1964, with a msg-type of 
-   KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally 
-   pass the TGT in the data field of this error message. In response to 
-   this error, the initiator sets flags and returns a 
-   GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism 
-   described in section 4. 
-    
-7. Security Considerations 
- 
-   These extensions simply enable an existing Kerberos 5 authentication 
-   protocol so that it may be used from GSSAPI. 
-    
-   There is some risk in a server handing out its ticket-granting-
-   ticket to any client that requests it, in that it gives an attacker 
-   a piece of encrypted material to decrypt. However, the same material 
-   may be obtained from listening to any legitimate client connection. 
-    
-   It should be noted here that the exchange described in section 6 
-   requires that the KDC provide tickets for user accounts, which will 
-   contain known plaintext encrypted in the usersÆ private key. The 
-   risk associated with this is entirely mitigated where a KDC supports 
-   the KDC_MUST_USE_USER2USER feature, which allows a restriction on 
-   user accounts to ensure that all tickets for that account are 
-   encrypted in the TGT session key, and not the long term key of the 
-   user. 
-    
-8. References 
-    
-
-  
-Swift                  Category - Informational                      4 
-
-
-
-
-
-
-
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   3  J. Kohl, C. Neuman, "The Kerberos Network Authentication 
-      Service(V5)",  RFC 1510. 
-    
-   4  J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964 
-    
-   5  J. Linn, "Generic Security Service Application Program Interface, 
-      Version 2", RFC 2078 
-    
-9. Author's Addresses 
-    
-   Michael Swift 
-   University of Washington 
-   Seattle, Washington 
-   Email: mikesw@cs.washington.edu 
-    
-   John Brezak 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@microsoft.com 
-    
-   Patrick Moore 
-   Sandia National Laboratories 
-   PO Box 5800 Mail Stop 
-   Albuquerque, New Mexico 
-   Email: pcmoore@sandia.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                      5 
-
-
-
-
-
-
-
-
-                 User to User Kerberos Authentication     October 1999 
- 
- 
-    
-Full Copyright Statement 
- 
-   Copyright (C) The Internet Society (1999).  All Rights Reserved. 
-    
-   This document and translations of it may be copied and furnished to 
-   others, and derivative works that comment on or otherwise explain it 
-   or assist in its implementation may be prepared, copied, published 
-   and distributed, in whole or in part, without restriction of any 
-   kind, provided that the above copyright notice and this paragraph 
-   are included on all such copies and derivative works.  However, this   
-   document itself may not be modified in any way, such as by removing   
-   the copyright notice or references to the Internet Society or other   
-   Internet organizations, except as needed for the purpose of 
-   developing Internet standards in which case the procedures for 
-   copyrights defined in the Internet Standards process must be 
-   followed, or as required to translate it into languages other than 
-   English. 
-    
-   The limited permissions granted above are perpetual and will not be 
-   revoked by the Internet Society or its successors or assigns. 
-    
-   This document and the information contained herein is provided on an 
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
-    
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                      6 
-
-
-
-
-
-
-
diff --git a/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt b/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt
deleted file mode 100644
index 68c170b49..000000000
--- a/doc/standardisation/draft-thomas-snmpv3-kerbusm-00.txt
+++ /dev/null
@@ -1,1140 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT   Kerberized USM Keying    M. Thomas
-                                          Cisco Systems
-                                          K. McCloghrie
-                                          Cisco Systems
-                                          July 13, 2000
-
-
-
-
-
-
-                         Kerberized USM Keying
-
-                   draft-thomas-snmpv3-kerbusm-00.txt
-
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.  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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-Abstract
-
-   The KerbUSM MIB provides a means of leveraging a trusted third party
-   authentication and authorization mechanism using Kerberos for SNMP V3
-   USM users and their associated VACM views. The MIB encodes the normal
-   Kerberos AP-REQ and AP-REP means of both authenticating and creating
-   a shared secret between the SNMP V3 Manager and Agent.
-
-The SNMP Management Framework
-
-   The SNMP Management Framework presently consists of five major
-   components:  An overall architecture, described in RFC 2571
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 1]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-   [RFC2571].  Mechanisms for describing and naming objects and events
-   for the purpose of management.  The first version of this Structure
-   of Management Information (SMI) is called SMIv1 and described in STD
-   16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
-   [RFC1215].  The second version, called SMIv2, is described in STD 58,
-   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
-   [RFC2580].  Message protocols for transferring management
-   information.  The first version of the SNMP message protocol is
-   called SNMPv1 and described in STD 15, RFC 1157 [RFC1157].  A second
-   version of the SNMP message protocol, which is not an Internet
-   standards track protocol, is called SNMPv2c and described in RFC 1901
-   [RFC1901] and RFC 1906 [RFC1906].  The third version of the message
-   protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC
-   2572 [RFC2572] and RFC 2574 [RFC2574].  Protocol operations for
-   accessing management information.  The first set of protocol
-   operations and associated PDU formats is described in STD 15, RFC
-   1157 [RFC1157].  A second set of protocol operations and associated
-   PDU formats is described in RFC 1905 [RFC1905].  A set of fundamental
-   applications described in RFC 2573 [RFC2573] and the view-based
-   access control mechanism described in RFC 2575 [RFC2575].
-
-   A more detailed introduction to the current SNMP Management Framework
-   can be found in RFC 2570 [RFC2570].
-
-   Managed objects are accessed via a virtual information store, termed
-   the Management Information Base or MIB.  Objects in the MIB are
-   defined using the mechanisms defined in the SMI.
-
-   This memo specifies a MIB module that is compliant to the SMIv2.  A
-   MIB conforming to the SMIv1 can be produced through the appropriate
-   translations.  The resulting translated MIB must be semantically
-   equivalent, except where objects or events are omitted because no
-   translation is possible (use of Counter64).  Some machine readable
-   information in SMIv2 will be converted into textual descriptions in
-   SMIv1 during the translation process.  However, this loss of machine
-   readable information is not considered to change the semantics of the
-   MIB.
-
-
-Introduction
-
-   The User based Security Model of SNMP V3 (USM) [2] provides a means
-   of associating different users with different access privileges of
-   the various MIB's that an agent supports. In conjunction with the
-   View based Access Control Model of SNMP V3 (VACM) [3], SNMP V3
-   provides a means of providing resistance from various threats both
-   from outside attacks such as spoofing, and inside attacks such as an
-   user having, say, SET access to MIB variable for which they are not
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 2]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-   authorized.
-
-   SNMP V3, unfortunately, does not specify a means of doing key
-   distribution between the managers and the agents. For small numbers
-   of agents and managers, the O(n*m) manual keying is a cumbersome, but
-   possibly tractable problem. For a large number of agents with
-   distribution of managers, the key distribution quickly goes from
-   cumbersome to unmanageable. Also: there is always the lingering
-   concern of the security precautions taken for keys on either local
-   management stations, or even directories.
-
-   Kerberos [1] provides a means of centralizing key management into an
-   authentication and authorization server known as a Key Distribution
-   Center (KDC).  At a minimum, Kerberos changes the key distribution
-   problem from a O(n*m) problem to a O(n) problem since keys are shared
-   between the KDC and the Kerberos principals rather directly between
-   each host pair. Kerberos also provides a means to use public key
-   based authentication which can be used to further scale down the
-   number of pre-shared secrets required. Furthermore, a KDC is intended
-   and explicitly expected to be a standalone server which is managed
-   with a much higher level of security concern than a management
-   station or even a central directory which may host many services and
-   thus be exposed to many more possible vectors of attack.
-
-   The MIB defined in this memo describes a means of using the desirable
-   properties of Kerberos within the context of SNMP V3. Kerberos
-   defines a standardized means of communicating with the KDC as well as
-   a standard format of Kerberos tickets which Kerberos principals
-   exchange in order to authenticate to one another. The actual means of
-   exchanging tickets, however, is left as application specific. This
-   MIB defines the SNMP MIB designed to transport Kerberos tickets and
-   by doing so set up SNMP V3 USM keys for authentication and privacy.
-
-   It should be noted that using Kerberos does introduce reliance on a
-   key network element, the KDC. This flies in the face of one of SNMP's
-   dictums of working when the network is misbehaving. While this is a
-   valid concern, the risk of reliance on the KDC can be significantly
-   diminished with a few common sense actions. Since Kerberos tickets
-   can have long life times (days, weeks) a manager of key network
-   elements can and should maintain Kerberos tickets well ahead ticket
-   expiration so that likelihood of not being able to rekey a session
-   while the network is misbehaving is minimized. For non-critical, but
-   high fanout elements such as user CPE, etc, requiring a pre-fetched
-   ticket may not be practical, which puts the KDC into the critical
-   path. However, if all KDC's are unreachable, the non-critical network
-   elements are probably the least of the worries.
-
-
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 3]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-Operation
-
-   The normal Kerberos application ticket exchange is accomplished by  a
-   client  first  fetching  a  service ticket from a KDC for the service
-   principal and then sending an AP-REQ  to  a  server  to  authenticate
-   itself  to  the  server. The server then sends a AP-REP to finish the
-   exchange. This MIB maps Kerberos' concept of client and  server  into
-   the  SNMP  V3  concept  of  Manager and Agent by designating that the
-   Kerberos Client is the SNMP V3 Agent. Although  it  could  be  argued
-   that an Agent is really a server, in practice there may be many, many
-   agents and relatively few managers. Also: Kerberos clients  may  make
-   use  of  public  key authentication as defined in [4], and it is very
-   advantageous to take advantage of that capability for  Agents  rather
-   than Managers.
-
-   The MIB is intended to be stateless and map USM users to Kerberos
-   principals. This mapping is explicitly done by putting a Kerberos
-   principal name into the usmUserSecurityName in the usmUser MIB and
-   instatiating the krbUsmMibEntry for the usmUserEntry. MIB variables
-   are accessed with INFORM's or TRAP PDU's and SET's to perform a
-   normal Kerberos AP-REQ/AP-REP exchange transaction which causes the
-   keys for a USM user to be derived and installed. The basic structure
-   of the MIB is a table which augements usmUserEntry's with a Kerberos
-   principal name as well as the transaction varbinds. In the normal
-   case, multiple varbinds should be sent in a single PDU which prevents
-   various race conditions, as well as increasing efficiency.
-
-   It should be noted that this MIB is silent on the subject of how the
-   Agent and Manager find the KDC. In practice, this may be either
-   statically provisioned or use either DNS SRV records (RFC 2782) or
-   Service Location (RFC 2608). This MIB is does not provide for a means
-   of doing cipher suite negotiation either. It is expected that the
-   choices for ciphers in the USM MIB will reflect site specific choices
-   for ciphers. This matches well with the general philosophy of
-   centralized keying.
-
-Keying Transactions
-
-   The following shows an error free transaction:
-
-   Note: optional steps or parameters are shown like [ ]
-
-
-
-
-
-
-
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 4]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-
-    Agent                       Manager                            KDC
- +--                                                               --+
- | 1) <-------------------------------                               |
- |     SET (krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx;      |
- |          [ krbUsmPrinTable[usmUserName].krbUsmMibTgt =            |
- |                                  TGT[usmUserSecurityName] ]);     |
- |                                                                   |
- | 2) ------------------------------->                               |
- |    Response                                                       |
- +--                     (optional)                                --+
-
-   3) --------------------------------------------------------------->
-        TGS-REQ (krbUsmPrinTable[usmUserName].krbUsmMibMgrPrinName
-                 [, krbUsmPrinTable[usmUserName].krbUsmMibTgt]);
-
-   4) <--------------------------------------------------------------
-        Tick[usmUserSecurityName] = TGS-REP ();
-
-   5)  ------------------------------>
-        INFORM (krbUsmPrinTable[usmUserName].krbUsmMibApReq =
-                   AP_REQ[Tick[usmUserSecurityName]];
-                   [ krbUsmPrinTable[usmUserName].krbUsmMibNonce = xxxx]);
-
-   6)  <------------------------------
-        SET (krbUsmPrinTable[usmUserName].krbUsmMibApRep = AP_REP[]);
-
-
-   7)  ------------------------------>
-       Response
-
-
-   The above flow translates to:
-
-
-   1)  This step is used when the Manager does not currently have a ses-
-       sion with the Agent but wishes to start one. The Manager MAY
-       place a ticket granting ticket into the krbUsmMibMgrTgt varbind
-       in the same PDU as the krbUsmMibNonce if it does not share a
-       secret with the KDC (as would be the case if the Manager used
-       PKinit to do initial authentication with the KDC).
-
-
-   2)  This step acknowledges the SET. There are no MIB specific errors
-       which can happen here.
-
-
-   3)  If the Agent is not already in possession of a service ticket for
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 5]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-       the Manager in its ticket cache, it MUST request a service ticket
-       from the Agent's KDC for the service principal given by
-       krbUsmMibMgrPrinName in the row that the krbUsmMibNonce was SET
-       in, optionally adding a krbUsmMibMgrTgt.  If the TGT is speci-
-       fied, the Manager's TGT must be placed in the additional-tickets
-       field with the ENC-TKT-IN-SKEY option set in the TGS-REQ to
-       obtain a service ticket (see section 3.3.3 of [1]).
-
-       Note:   a Kerberos TGS-REQ is but one way to obtain a service
-               ticket. An Agent may use any normal Kerberos means to
-               obtain the service ticket. This flow has also elided ini-
-               tial authentication (ie, AS-REQ) and any cross realm con-
-               siderations, though those may be necessary prerequisites
-               to obtaining the service ticket.
-
-   4)  If step 3 was performed, this step receives the ticket or an
-       error from the KDC.
-
-
-   5)  This step sends a krbUsmMibApReq to the Manager via an INFORM or
-       TRAP PDU.  If the message is the result of a request by the
-       Manager, krbUsmMibNonce received from the Manager MUST be sent in
-       the same PDU. If the Manager did not initiate the transaction,
-       the Agent MUST NOT send a krbUsmMibNonce varbind. The Agent also
-       MUST check krbUsmMibUnsolicitedNotify is not false, otherwise it
-       MUST abort the transaction.  All krbUsmMibApReq's MUST contain a
-       sequence nonce so that the resulting krbUsmMibApRep can provide a
-       proof of the freshness of the message to prevent replay attacks.
-
-       If the Agent encounters an error either generated by the KDC or
-       internally, the Agent MUST send an INFORM or TRAP PDU indicating
-       the error in the form of a KRB-ERROR placed in krbUsmMibApReq
-       with the same rules applied to krbUsmMibNonce and krbUsmMibUnsol-
-       icitedNotify above. If the Agent suspects that it is being
-       attacked by a purported Manager which is generating many failed
-       TGS-REQ's to the KDC, it SHOULD meter its TGS-REQ transactions
-       for that Manager to the KDC using an exponential backoff mechan-
-       ism truncated at 10 seconds.
-
-
-
-   6)  Upon recepit of an INFORM or TRAP PDU with a krbUsmMibApReq, a
-       Manager may accept the AP-REQ. If it is accompanied with a
-       krbUsmMibNonce it MUST correlate it with any outstanding transac-
-       tions using its stored nonce for the transaction. If it does not
-       correlate with a current nonce, the request MUST be rejected as
-       it may be a replay.
-
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 6]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-       If the Manager chooses to reject an unsolicited keying request,
-       it SHOULD send a WrongValue Error to the Agent with the krbUsmMi-
-       bApReq as the subject of the WrongValue. If an Agent receives a
-       WrongValue Error from a Manager it MUST cease retransmission of
-       the INFORM or TRAP PDU's so as to mitigate event avalanches by
-       Agents. There is a possible denial of service attack here, but it
-       must be weighed against the larger problem of network congestion,
-       flapping, etc. Therefore, if the Agent finds that it cannot can-
-       cel an unsolicited Notify (ie, it must be reliable), it MUST use
-       a truncated exponential backoff mechanism with the maximum trun-
-       cation interval set to 10 minutes.
-
-       Otherwise, the Manager MUST send a SET PDU to the Agent which
-       contains a krbUsmMibApRep.
-
-
-   7)  If the Agent detects an error (including detecting replays) in
-       the final AP-REP, it MUST send a WrongValue error with a pointer
-       to the krbUsmMibApRep varbind to indicate its inability to estab-
-       lish the security association. Otherwise, receipt of the positive
-       acknowledgement from the final SET indicates to the Manager that
-       the proper keys have been installed on the Agent in the USM MIB.
-
-Unsolicited Agent Keying Requests
-
-   An Agent may find that it needs to set up a security association for
-   a USM user in order to notify a Manager of some event. When the Agent
-   engine receives a request for a notify, it SHOULD check to see if
-   keying material has been established for the user and that the keying
-   material is valid. If the keying material is not valid and the USM
-   user has been tagged as being a Kerberos principal in a realm, the
-   Agent SHOULD first try to instantiate a security association by
-   obtaining a service ticket for the USM User and follow steps 3-7 of
-   the flow above. This insures that the USM User will have proper key-
-   ing material and providing a mechanism to allow for casual security
-   associations to be built up and torn down. This is especially useful
-   for Agents which may not normally need to be under constant Manager
-   supervision, such as the case with high fan out user residential CPE
-   and other SNMP managed "appliances". In all cases, the Agent MUST NOT
-   send an unsolicited Notify if krbUsmUnsolicitedNotify is set to
-   false.
-
-   How the Agent obtains the Manager's address, how it determines
-   whether a Manager, realm, and whether it can be keyed using this MIB
-   is outside of the scope of this memo.
-
-   Note:   Although the MIB allows for a Manager to set up a session
-           using User-User mode of Kerberos by sending a TGT along with
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 7]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-           the nonce, this, is limited to Manager initiated sessions
-           only since there is no easy way to store the Manager's ticket
-           in the MIB since it is publicly writable and as such would be
-           subject to denial of service attacks. Another method might be
-           to have the Agent send a krbUsmMibNonce to the Manager which
-           would tell it to instigate a session. Overall, it seems like
-           a marginal feature to allow a PKinit authenticated user be
-           the target of unsolicited informs and it would complicate the
-           transactions. For this reason, this scenario has been omitted
-           in favor of simplicity.
-
-Retransmissions
-
-   Since this MIB defines not only variables, but transactions, discus-
-   sion of the retransmission state machine is in order. There are two
-   similar but different state machines for the Manager Solicited and
-   Agent Unsolicited transactions.  There is one timer Timeout which
-   SHOULD take into consideration round trip considerations and MUST
-   implement a truncated exponential backoff mechanism. In addition, in
-   the case where an Agent makes an unsolicited Agent keying request,
-   the Agent SHOULD perform an initial random backoff if the keying
-   request to the Manager may result in a restart avalanche. A suitable
-   method is described in section 4.3.4 of [5].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 8]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-
-Manager Solicited Retransmission State Machine
-
-                Timeout
-                 +---+
-                 |   |
-                 |   V
-              +-----------+ Set-Ack (2) +----------+
-              |           |------------>|          |
-              | Set-Nonce |             |  Ap-Req  |
-              |   (1)     |<------------|   (5)    |
-              +-----------+   Timeout   +----------+
-                   ^                         |
-                   |                         | Set-Ap-Rep
-                   |      +----------+       |  (6)
-                   +------|          |<------+
-                  Timeout | Estab-wt |
-                          |   (7)    |
-                          +----------+
-                               |
-                               |  Set-Ap-Rep-Ack (7)
-                               V
-                          +----------+
-                          |          |
-                          |  Estab   |
-                          |          |
-
-                          +----------+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00             [Page 9]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-
-Agent Unsolicited Retransmission State Machine
-
-                             Timeout
-                              +---+
-                              |   |
-                              |   V
-                          +----------+
-                          |          |
-                   +----> |  Ap-Req  |-------+
-                   |      |   (5)    |       |
-                   |      +----------+       |
-                   |                         |
-                   |                         | Set-Ap-Rep
-                   |      +----------+       |  (6)
-                   +------|          |<------+
-                  Timeout | Estab-wt |
-                          |   (7)    |
-                          +----------+
-                               |
-                               |  Set-Ap-Rep-Ack (7)
-                               V
-                          +----------+
-                          |          |
-                          |  Estab   |
-                          |          |
-                          +----------+
-
-Session Duration and Failures
-
-   The KerbUsmMib uses the ticket lifetime to determine the life of the
-   USM session. The Agent MUST keep track of whether the ticket which
-   instigated the session is valid whenever it forms PDU's for that par-
-   ticular user. If a session expires, or if it wasn't valid to begin
-   with (from the Agent's perspective), the Agent MUST reject the PDU by
-   sending a XXX Error [mat: help me here Keith... what does USM say
-   about this?].
-
-   Kerberos also inherently implies adding state to the Agent and
-   Manager since they share not only a key, but a lifetime associated
-   with that key. This is in some sense soft state because failure of an
-   Agent will cause it to reject PDU's for Managers with whom it does
-   not share a secret. The Manager can use the Error PDU's as an indica-
-   tion that it needs to reauthenticate with the Agent, taking care not
-   to loop. The Manager is even easier: when it reboots, it can either
-   check its credential cache to reconstruct state or cause the Agent to
-   reauthenticate to the Manager with its service ticket by initiating a
-   authentication transaction with the manager.
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 10]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-Manager Collisions
-
-   Managers may freely set up keys for different USM users using this
-   MIB without problem since they access different rows in the krbUsm-
-   PrinTable. However, multiple Managers trying to set up keys for the
-   same USM user is possible but discouraged. The requirement for the
-   Manager is that they MUST share the same service key with the KDC so
-   that they can all decrypt the same service ticket. There are two race
-   conditions, however, which are not well handled:
-
-
-
-1)  At the end of a ticket lifetime, one manager may request the agent
-    to refresh its service ticket causing a new session key to be
-    installed for the USM user leaving the other managers with stale
-    keys. The workaround here is that the Agent will reject the stale
-    manager's PDU's which should inform them to do their own rekeying
-    operations.
-
-
-2)  If multiple managers try to access the same row at the same time,
-    the Agent SHOULD try to keep the transactions separate based on the
-    nonce values. The Managers or the Agents SHOULD NOT break the
-    krbUsmMibNonce and any other additional varbinds into separate PDU's
-    as this may result in a meta stable state. Given normal MTU sizes,
-    this should not be an issue in practice, and this should  at worst
-    devolve into the case above.
-
-   In all cases, the krbUsmMibNonce MUST be the last value to be
-   transmitted, though its position within a PDU is unimportant.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 11]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-
-   KrbUSM MIB
-
-   KRB-USM-MIB DEFINITIONS ::= BEGIN
-   IMPORTS
-       MODULE-IDENTITY,
-       OBJECT-TYPE, OBJECT-IDENTITY,
-       snmpModules, Counter32, Unsigned32 FROM SNMPv2-SMI
-       TruthValue, DisplayString          FROM SNMPv2-TC
-       usmUserEntry                       FROM SNMP-USER-BASED-SM-MIB
-
-
-
-   krbUsmMib MODULE-IDENTITY
-           LAST-UPDATED "00071300Z"
-           ORGANIZATION "IETF SNMP V3 Working Group"
-           CONTACT-INFO
-             "Michael Thomas
-              Cisco Systems
-              375 E Tasman Drive
-              San Jose, Ca 95134
-              Phone: +1 408-525-5386
-              Fax: +1 801-382-5284
-              email: mat@cisco.com"
-           DESCRIPTION
-              "This MIB contains the MIB variables to
-               exchange Kerberos credentials and a session
-               key to be used to authenticate and set up
-               USM keys"
-
-           ::= { snmpModules nnn }   -- not sure what needs to be here.
-   krbUsmMibObjects OBJECT INDENTIFIER ::= { krbUsmMib 1 }
-
-   krbUsmMibAuthInAttemps
-               SYNTAX      Counter32
-               MAX-ACCESS  read-only
-               STATUS      current
-               DESCRIPTION
-                   "Counter of the number of Kerberos
-                    authorization attempts as defined by
-                    receipt of a PDU from a Manager with a
-                     krbUsmMibNonce set in the principal table."
-               ::= { krbUsmMibObjects 1 }
-
-   krbUsmMibAuthOutAttemps
-               SYNTAX      Counter32
-               MAX-ACCESS  read-only
-               STATUS      current
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 12]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-               DESCRIPTION
-                   "Counter of the number of unsolicited Kerberos
-                    authorization attempts as defined by
-                    an Agent sending an INFORM or TRAP PDU with a
-                    krbUsmMibApRep but without krbUsmApMibNonce
-                    varbind."
-               ::= { krbUsmMibObjects 2 }
-   krbUsmMibAuthInFail
-               SYNTAX      Counter32
-               MAX-ACCESS  read-only
-               STATUS      current
-               DESCRIPTION
-                   "Counter of the number of Kerberos
-                    authorization failures as defined by
-                    a Manager setting the krbUsmMibNonce
-                    in the principal table which results
-                    in some sort of failure to install keys
-                    in the requested USM user entry."
-               ::= { krbUsmMibObjects 3 }
-
-   krbUsmMibAuthOutFail
-               SYNTAX      Counter32
-               MAX-ACCESS  read-only
-               STATUS      current
-               DESCRIPTION
-                   "Counter of the number of unsolicited Kerberos
-                    authorization failures as defined by
-                    an Agent sending an INFORM or TRAP PDU with a
-                    krbUsmMibApRep but without a krbUsmMibNonce
-                    varbind which does not result in keys being
-                    installed for that USM user entry."
-               ::= { krbUsmMibObjects 4 }
-
-   krbUsmMibPrinTable OBJECT-TYPE
-               SYNTAX      SEQUENCE OF krbUsmMibEntry
-               MAX-ACCESS  not-accessible
-               STATUS      current
-               DESCRIPTION
-                   "Table which maps Kerberos principals with USM
-                    users as well as the per user variables to key
-                    up sessions"
-               ::= { krbUsmMibObjects 5 }
-
-   krbUsmMibPrinEntry OBJECT-TYPE
-               SYNTAX     KrbUsmMibPrinEntry
-               MAX-ACCESS  not-accessible
-               STATUS      current
-               DESCRIPTION
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 13]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-                   "an entry into the krbMibPrinTable which is a
-                    parallel table to UsmUserEntry table"
-               AUGMENTS { usmUserEntry }
-               ::= { krbUsmMibPrinTable 1 }
-
-   KrbUsmMibPrinEntry SEQUENCE
-    {
-                   krbUsmMibApReq                  OCTET STRING,
-                   krbUsmMibApRep                  OCTET STRING,
-                   krbUsmMibNonce                  OCTET STRING,
-                   krbUsmMibMgrTGT                 OCTET STRING,
-                   krbUsmMibUnsolicitedNotify      TruthValue,
-    }
-
-
-   krbUsmMibApReq OBJECT-TYPE
-               SYNTAX      OCTET STRING
-               MAX-ACCESS  accessible-for-notify
-               STATUS      current
-               DESCRIPTION
-                   "This variable contains a DER encoded Kerberos
-                    AP-REQ or KRB-ERROR for the USM user which is
-                    to be keyed. This is sent from the Agent to
-                    the Manager in an INFORM or TRAP request.
-                    KRB-ERROR MUST only be sent to the Manager
-                    if it is in response to a keying request from
-                    the Manager.
-                   "
-               ::= { krbUsmMibPrinEntry 1 }
-
-   krbUsmMibApRep OBJECT-TYPE
-               SYNTAX      OCTET STRING
-               MAX-ACCESS  read-write
-               STATUS      current
-               DESCRIPTION
-                   "This variable contains the DER encoded response
-                    to an AP-REQ. This variable is SET by the
-                    Manager to acknowledge receipt of an AP-REQ. If
-                    krbUsmMibApRep contains a Kerberos AP-REP, the
-                    Agent must derive keys from the session key
-                    of the Kerberos ticket in the AP-REQ and place
-                    them in the USM database in a manner specified
-                    by [RFC2574]. If the Manager detects an error,
-                    it will instead place a KRB-ERROR in this
-                    variable to inform the Agent of the error.
-
-                    This variable is in effect a write-only variable.
-                    attempts to read this variable will result in a
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 14]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-                    null octet string being returned"
-               ::= { krbUsmMibPrinEntry 2 }
-
-   krbUsmMibNonce OBJECT-TYPE
-               SYNTAX      OCTET STRING
-               MAX-ACCESS  read-write
-               STATUS      current
-               DESCRIPTION
-                   "SET'ing a krbUsmMibnonce allows a Manager to
-                    determine whether an INFORM or TRAP from an
-                    Agent is an outstanding keying request, or
-                    unsolicited from the Agent. The Manager
-                    initiates keying for a particular USM user
-                    by writing a nonce into the row for which
-                    desires to establish a security association.
-                    The nonce is an ASCII string of the form
-                    ``host:port?nonce'' where:
-
-                    host:  is either an FQDN, or valid ipv4 or ipv6
-                           numerical notation of the Manager which
-                           desires to initiate keying
-                    port:  is the destination port at which that the
-                           Manager may be contacted
-                    nonce: is a number generated by the Manager to
-                           correlate the transaction
-
-                    The same nonce MUST be sent to the Manager in a
-                    subsequent INFORM or TRAP with a krbUsmApReq.
-                    The Agent MUST use the host address and port
-                    supplied in the nonce as the destination of a
-                    subsequent INFORM or TRAP. Unsolicited keying
-                    requests MUST NOT contain a nonce, and should
-                    instead use the destination stored Notifies of
-                    this type.
-
-                    Nonces MUST be highly collision resistant either
-                    using a time based method or a suitable random
-                    number generator. Managers MUST never create
-                    nonces which are 0.
-
-                    This variable is in effect a write-only variable.
-                    Attempts to read this variable will result in a
-                    nonce of value 0 being returned"
-
-
-               ::= { krbUsmMibPrinEntry 3 }
-
-
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 15]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-   krbUsmMibMgrTgt OBJECT-TYPE
-               SYNTAX      OCTET STRING
-               MAX-ACCESS  read-write
-               STATUS      current
-               DESCRIPTION
-                   "If the Manager does not possess a symmetric
-                    key with the KDC as would be the case with
-                    a Manager using PKinit for authentication,
-                    the Manager MUST SET its DER encoded ticket
-                    granting ticket into KrbUsmMgrTgt along
-                    with krbUsmMibNonce.
-
-                    The agent will then attach the Manager's TGT
-                    into the additional tickets field of the
-                    TGS-REQ message to the KDC to get a User-User
-                    service ticket.
-
-                    This variable is in effect a write-only variable.
-                    Attempts to read this variable will result in a
-                    null octet string being returned"
-               ::= { krbUsmMibPrinEntry 4 }
-
-
-   krbUsmMibUnsolicitedNotify OBJECT-TYPE
-               SYNTAX      TruthValue
-               MAX-ACCESS  read-write
-               STATUS      current
-               DESCRIPTION
-                   "If this variable is false, the Agent MUST NOT
-                    send unsolicited INFORM or TRAP PDU's to the
-                    Manager.
-
-                    Attempts to SET this variable by the no-auth
-                    no-priv user MUST be rejected."
-               ::= { krbUsmMibPrinEntry 5 }
-
-   --
-   -- Conformance section... nothing optional.
-
-   krbUsmMibCompliences MODULE-COMPLIANCE
-               STATUS       current
-               DESCRIPTION "The compliance statement for SNMP
-                            engines whichimplement the KRB-USM-MIB
-                   "
-               MODULE       -- this module
-                       MANDATORY-GROUPS { krbUsmMib }
-       ::= { krbUsmMibCompliances 1 }
-
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 16]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-   END
-
-
-Key Derivation
-
-   The session key provides the basis for the keying material for the
-   USM user specified in the AP-REQ.  The actual keys for use for the
-   authentication and privacy are produced using the cryptographic hash-
-   ing function used to protect the ticket itself.  The keying material
-   is derived using this function, F(key, salt), using successive
-   interations of F over the salt string "SNMPV3RULZ%d", where %d is a
-   monotonic counter starting at zero. The bits are taken directly from
-   the successive interations to produce two keys of appropriate size
-   (as specified in the USM user row) for the authentication transform
-   first, and the privacy transform second. If the authentication
-   transform is null, the first bits of the derived key are used for the
-   privacy transform.
-
-Security Considerations
-
-   Various elements of this MIB must be readable and writable as the
-   no-auth, no-priv user. Unless specifically necessary for the key
-   negotiation, elements of this MIB SHOULD be protected by VACM views
-   which limit access. In particular, there is no reason anything in
-   this MIB should be visible to a no-auth, no-priv user with the excep-
-   tion of KrbUsmMibApReq, KrbUsmMibApRep, KrbUsmMibNonce, and
-   KrbUsmMibMgrTgt, and then only with the restrictions placed on them
-   in the MIB. As such, probing attacks are still possible, but should
-   not be profitable: all of the writable variables with interesting
-   information in them are defined in such a way as to be write only.
-
-   There are some interesting denial of service attacks which are possi-
-   ble by attackers spoofing managers and putting load on the KDC to
-   generate unnecessary tickets. For large numbers or agents this could
-   be problematic. This can probably be mitigated by the KDC prioritiz-
-   ing TGS-REQ's though.
-
-
-References
-
-[1]         The CAT Working Group,  J.  Kohl,  C.Neuman,  "The  Kerberos
-            Network  Authentication  Service  (V5)", RFC 1510, September
-            1993
-
-[2]         The SNMPV3 Working Group, U.  Blumenthal,  B.  Wijnen,  "The
-            User-based Security Model of SNMP V3", RFC 2574, April 1999
-
-[3]         The SNMPV3 Working Group, B. Wijnen, R. Presuhn,
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 17]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-            K.McCloghrie, "The View-based Access Control Model of SNMP
-            V3", RFC 2575, April 1999
-
-[4]         The CAT Working Group, Tung, et al, "Public Key Cryptography
-            for Initial Authentication in Kerberos", draft-ietf-cat-pk-
-            init-11, November 1999
-
-[5]         Arango, et al, "Media Gateway Control Protocl (MGCP)", RFC
-            2705, October 1999
-
-
-[RFC2571]   Harrington, D., Presuhn, R., and B. Wijnen, An Architecture
-            for Describing SNMP Management Frameworks, RFC 2571, April
-            1999.
-
-[RFC1155]   Rose, M., and K. McCloghrie, Structure and Identification of
-            Management Information for TCP/IP-based Internets, STD 16,
-            RFC 1155, May 1990.
-
-[RFC1212]   Rose, M., and K. McCloghrie, Concise MIB Definitions, STD
-            16, RFC 1212, March 1991.
-
-[RFC1215]   M. Rose, A Convention for Defining Traps for use with the
-            SNMP, RFC 1215, March 1991.
-
-[RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
-            Rose, M., and S. Waldbusser, Structure of Management Infor-
-            mation Version 2 (SMIv2), STD 58, RFC 2578, April 1999.
-
-[RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
-            Rose, M., and S. Waldbusser, Textual Conventions for SMIv2,
-            STD 58, RFC 2579, April 1999.
-
-[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
-            Rose, M., and S. Waldbusser, Conformance Statements for
-            SMIv2, STD 58, RFC 2580, April 1999.
-
-[RFC1157]   Case, J., Fedor, M., Schoffstall, M., and J. Davin, Simple
-            Network Management Protocol, STD 15, RFC 1157, May 1990.
-
-[RFC1901]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
-            Introduction to Community-based SNMPv2, RFC 1901, January
-            1996.
-
-[RFC1906]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Tran-
-            sport Mappings for Version 2 of the Simple Network Manage-
-            ment Protocol (SNMPv2), RFC 1906, January 1996.
-
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 18]
-
-
-
-
-
-INTERNET-DRAFT           Kerberized USM Keying              13 July 2000
-
-
-[RFC2572]   Case, J., Harrington D., Presuhn R., and B. Wijnen, Message
-            Processing and Dispatching for the Simple Network Management
-            Protocol (SNMP), RFC 2572, April 1999.
-
-[RFC2574]   Blumenthal, U., and B. Wijnen, User-based Security Model
-            (USM) for version 3 of the Simple Network Management Proto-
-            col (SNMPv3), RFC 2574, April 1999.
-
-[RFC1905]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, Pro-
-            tocol Operations for Version 2 of the Simple Network Manage-
-            ment Protocol (SNMPv2), RFC 1905, January 1996.
-
-[RFC2573]   Levi, D., Meyer, P., and B. Stewart, SNMPv3 Applications,
-            RFC 2573, April 1999.
-
-[RFC2575]   Wijnen, B., Presuhn, R., and K. McCloghrie, View-based
-            Access Control Model (VACM) for the Simple Network Manage-
-            ment Protocol (SNMP), RFC 2575, April 1999.
-
-[RFC2570]   Case, J., Mundy, R., Partain, D., and B. Stewart, Introduc-
-            tion to Version 3 of the Internet-standard Network Manage-
-            ment Framework, RFC 2570, April 1999.
-
-Author's Address
-
-          Michael Thomas
-          Cisco Systems
-          375 E Tasman Rd
-          San Jose, Ca, 95134, USA
-          Tel: +1 408-525-5386
-          email: mat@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomas               draft-thomas-snmpv3-kerbusm-00            [Page 19]
-
-
diff --git a/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt b/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt
deleted file mode 100644
index b89108a53..000000000
--- a/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-CAT Working Group                                     Mike Swift 
-draft-trostle-win2k-cat-kerberos-set-passwd-00.txt    Microsoft               
-February 2000                                         Jonathan Trostle
-Category: Informational                               Cisco Systems
-                                                      John Brezak
-                                                      Microsoft
-
-         Extending Change Password for Setting Kerberos Passwords
-
-
-0. Status Of This Memo
-
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026. 
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   Comments and suggestions on this document are encouraged.  Comments 
-   on this document should be sent to the CAT working group discussion 
-   list:
-                       ietf-cat-wg@stanford.edu
-
-1. Abstract
-
-   The Kerberos [1] change password protocol [2], does not allow for 
-   an administrator to set a password for a new user. This functionality
-   is useful in some environments, and this proposal extends [2] to
-   allow password setting. The changes are: adding new fields to the 
-   request message to indicate the principal which is having its 
-   password set, not requiring the initial flag in the service ticket, 
-   using a new protocol version number, and adding three new result 
-   codes. 
-   
-2. The Protocol
-
-   The service must accept requests on UDP port 464 and TCP port 464 as 
-   well. The protocol consists of a single request message followed by 
-   a single reply message.  For UDP transport, each message must be fully 
-   contained in a single UDP packet.
-
-   For TCP transport, there is a 4 octet header in network byte order
-   precedes the message and specifies the length of the message. This
-
-   requirement is consistent with the TCP transport header in 1510bis.
-
-Request Message
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |         message length        |    protocol version number    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |          AP_REQ length        |         AP_REQ data           /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      /                        KRB-PRIV message                       /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   All 16 bit fields are in big-endian order. 
-
-   message length field: contains the number of bytes in the message 
-   including this field.
-
-   protocol version number: contains the hex constant 0xff80 (big-endian 
-   integer).
-
-   AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, 
-   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
-   message.
-
-   AP-REQ data: (see [1]) The AP-REQ message must be for the service 
-   principal kadmin/changepw@REALM, where REALM is the REALM of the user 
-   who wishes to change/set his password. The ticket in the AP-REQ must 
-   must include a subkey in the Authenticator. To enable setting of 
-   passwords, it is not required that the initial flag be set in the 
-   Kerberos service ticket.
-
-   KRB-PRIV message (see [1]) This KRB-PRIV message must be generated 
-   using the subkey from the authenticator in the AP-REQ data. 
-
-   The user-data component of the message consists of the following ASN.1 
-   structure encoded as an OCTET STRING:
-
-   ChangePasswdData ::=  SEQUENCE {
-                       newpasswd[0]   OCTET STRING,
-                       targname[2]    PrincipalName OPTIONAL,
-                       targrealm[3]   Realm OPTIONAL
-                       }  
-
-   The server must verify the AP-REQ message, check whether the client 
-   principal in the ticket is authorized to set/change the password 
-   (either for that principal, or for the principal in the targname 
-   field if present), and decrypt the new password. The server also 
-   checks whether the initial flag is required for this request, 
-   replying with status 0x0007 if it is not set and should be. An 
-   authorization failure is cause to respond with status 0x0005. For 
-   forward compatibility, the server should be prepared to ignore fields 
-   after targrealm in the structure that it does not understand. 
-
-   The newpasswd field contains the cleartext password, and the server 
-   should apply any local policy checks including password policy checks. 
-   The server then generates the appropriate keytypes from the password
-
-   and stores them in the KDC database. If all goes well, status 0x0000 
-   is returned to the client in the reply message (see below).
-
-Reply Message
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |         message length        |    protocol version number    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |          AP_REP length        |         AP-REP data           /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      /                         KRB-PRIV message                      /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-   All 16 bit fields are in big-endian order. 
-
-   message length field: contains the number of bytes in the message 
-   including this field.
-
-   protocol version number: contains the hex constant 0x0001 (big-endian 
-   integer). (The reply message has the same format as in [2]).
-
-   AP-REP length: length of AP-REP data, in bytes. If the length is zero, 
-   then the last field contains a KRB-ERROR message instead of a KRB-PRIV 
-   message.
-
-   AP-REP data: the AP-REP is the response to the AP-REQ in the request 
-   packet.
-   
-   KRB-PRIV from [2]: This KRB-PRIV message must be generated using the 
-   subkey in the authenticator in the AP-REQ data.
-
-   The server will respond with a KRB-PRIV message unless it cannot
-   decode the client AP-REQ or KRB-PRIV message, in which case it will
-   respond with a KRB-ERROR message. NOTE: Unlike change password version
-   1, the KRB-ERROR message will be sent back without any encapsulation.
-
-   The user-data component of the KRB-PRIV message, or e-data component 
-   of the KRB-ERROR message, must consist of the following data.
-
-       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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |          result code          |        result string          /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-      result code (16 bits) (result codes 0-4 are from [2]):
-         The result code must have one of the following values (big-
-         endian integer):
-         KRB5_KPASSWD_SUCCESS      0 request succeeds (This value is not 
-                                     allowed in a KRB-ERROR message)
-         KRB5_KPASSWD_MALFORMED    1 request fails due to being malformed
-         KRB5_KPASSWD_HARDERROR    2 request fails due to "hard" error in
-                                     processing the request (for example, 
-                                     there is a resource or other problem 
-                                     causing the request to fail)
-
-         KRB5_KPASSWD_AUTHERROR    3 request fails due to an error in 
-                                     authentication processing
-         KRB5_KPASSWD_SOFTERROR    4 request fails due to a "soft" error 
-                                     in processing the request 
-         KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
-         KRB5_KPASSWD_BAD_VERSION  6 protocol version unsupported
-         KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
-         0xFFFF if the request fails for some other reason.
-         Although only a few non-zero result codes are specified here,
-         the client should accept any non-zero result code as indicating
-         failure.
-      result string - from [2]:
-         This field should contain information which the server thinks
-         might be useful to the user, such as feedback about policy
-         failures.  The string must be encoded in UTF-8.  It may be
-         omitted if the server does not wish to include it.  If it is
-         present, the client should display the string to the user.
-         This field is analogous to the string which follows the numeric
-         code in SMTP, FTP, and similar protocols.
-
-3. References
- 
-   [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
-   Service (V5). Request for Comments 1510.
-
-   [2] M. Horowitz. Kerberos Change Password Protocol.
-   ftp://ds.internic.net/internet-drafts/
-   draft-ietf-cat-kerb-chg-password-02.txt
-
-4. Expiration Date
-
-   This draft expires in August 2000.   
-
-5. Authors' Addresses
-
-   Jonathan Trostle
-   Cisco Systems
-   170 W. Tasman Dr.
-   San Jose, CA 95134
-   Email: jtrostle@cisco.com
-
-   Mike Swift 
-   1 Microsoft Way
-   Redmond, WA 98052
-   mikesw@microsoft.com
-
-   John Brezak
-   1 Microsoft Way
-   Redmond, WA 98052
-   jbrezak@microsoft.com
diff --git a/doc/standardisation/draft-tso-telnet-krb5-04.txt b/doc/standardisation/draft-tso-telnet-krb5-04.txt
deleted file mode 100644
index e9611e395..000000000
--- a/doc/standardisation/draft-tso-telnet-krb5-04.txt
+++ /dev/null
@@ -1,327 +0,0 @@
-Network Working Group                                    T. Ts'o, Editor
-Internet-Draft                     Massachusetts Institute of Technology
-draft-tso-telnet-krb5-04.txt                                  April 2000
-
-               Telnet Authentication: Kerberos Version 5
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.  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 mate-
-   rial or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119.
-
-0. Abstract
-
-   This document describes how Kerberos Version 5 [1] is used with the
-   telnet protocol.   It describes an telnet authentication sub-option
-   to be used with the telnet authentication option [2].   This mecha-
-   nism can also used to provide keying material to provide data confi-
-   dentiality services in conjuction with the telnet encryption option
-   [3].
-
-1. Command Names and Codes
-
-   Authentication Types
-
-      KERBEROS_V5    2
-
-   Sub-option Commands
-
-                           Expires Sept 2000                    [Page 1]
-
-Internet-Draft        Kerberos Version 5 for Telnet           April 2000
-
-      AUTH               0
-      REJECT             1
-      ACCEPT             2
-      RESPONSE           3
-      FORWARD            4
-      FORWARD_ACCEPT     5
-      FORWARD_REJECT     6
-
-2.  Command Meanings
-
-   IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5
-   KRB_AP_REQ message> IAC SE
-
-      This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the
-      remote side of the connection.  The first octet of the <authenti-
-      cation-type-pair> value is KERBEROS_V5, to indicate that Version 5
-      of Kerberos is being used.  The Kerberos V5 authenticator in the
-      KRB_AP_REQ message     must contain a Kerberos V5 checksum of the
-      two-byte authentication type pair.  This checksum must be verified
-      by the server to assure that the authentication type pair was cor-
-      rectly negotiated.  The Kerberos V5 authenticator must also in-
-      clude the optional subkey field, which shall be filled in with a
-      randomly chosen key.  This key shall be used for encryption pur-
-      poses if encryption is negotiated, and shall be used as the nego-
-      tiated session key (i.e., used as keyid 0) for the purposes of the
-      telnet encryption option; if the subkey is not filled in, then the
-      ticket session key will be used instead.
-
-      If data confidentiality services is desired the ENCRYPT_US-
-      ING_TELOPT flag must be set in the authentication-type-pair as
-      specified in [2].
-
-   IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE
-
-      This command indicates that the authentication was successful.
-
-      If the AUTH_HOW_MUTUAL bit is set in the second octet of the au-
-      thentication-type-pair, the RESPONSE command must be sent before
-      the ACCEPT command is sent.
-
-   IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <op-
-   tional reason for rejection> IAC SE
-
-      This command indicates that the authentication was not successful,
-      and if there is any more data in the sub-option, it is an ASCII
-      text message of the reason for the rejection.
-
-   IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE
-   <KRB_AP_REP message> IAC SE
-
-                           Expires Sept 2000                    [Page 2]
-
-Internet-Draft        Kerberos Version 5 for Telnet           April 2000
-
-      This command is used to perform mutual authentication.  It is only
-      used when the AUTH_HOW_MUTUAL bit is set in the second octet of
-      the authentication-type-pair.  After an AUTH command is verified,
-      a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP
-      message to perform the mutual authentication.
-
-   IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED
-   message> IAC SE
-
-      This command is used to forward kerberos credentials for use by
-      the remote session.  The credentials are passed as a Kerberos V5
-      KRB_CRED message which includes, among other things, the forwarded
-      Kerberos ticket and a session key associated with the ticket. Part
-      of the KRB_CRED message is encrypted in the key previously ex-
-      changed for the telnet session by the AUTH suboption.
-
-   IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC
-   SE
-
-      This command indicates that the credential forwarding was success-
-      ful.
-
-   IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT <op-
-   tional reason for rejection> IAC SE
-
-      This command indicates that the credential forwarding was not suc-
-      cessful, and if there is any more data in the sub-option, it is an
-      ASCII text message of the reason for the rejection.
-
-3.  Implementation Rules
-
-   If the second octet of the authentication-type-pair has the AUTH_WHO
-   bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial
-   AUTH command, and the server responds with either ACCEPT or REJECT.
-   In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the serv-
-   er will send a RESPONSE before it sends the ACCEPT.
-
-   If the second octet of the authentication-type-pair has the AUTH_WHO
-   bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial
-   AUTH command, and the client responds with either ACCEPT or REJECT.
-   In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the
-   client will send a RESPONSE before it sends the ACCEPT.
-
-   The Kerberos principal used by the server will generally be of the
-   form "host/<hostname>@realm".  That is, the first component of the
-   Kerberos principal is "host"; the second component is the fully qual-
-   ified lower-case hostname of the server; and the realm is the Ker-
-   beros realm to which the server belongs.
-
-                           Expires Sept 2000                    [Page 3]
-
-Internet-Draft        Kerberos Version 5 for Telnet           April 2000
-
-   Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP
-   messages, the KRB_CRED structure, or the optional rejection text
-   string must be doubled as specified in [4].  Otherwise the following
-   byte might be mis-interpreted as a Telnet command.
-
-4.  Examples
-
-   User "joe" may wish to log in as user "pete" on machine "foo".  If
-   "pete" has set things up on "foo" to allow "joe" access to his ac-
-   count, then the client would send IAC SB AUTHENTICATION NAME "pete"
-   IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE>
-   IAC SE
-
-   The server would then authenticate the user as "joe" from the
-   KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by
-   Kerberos, and if "pete" has allowed "joe" to use his account, the
-   server would then continue the authentication sequence by sending a
-   RESPONSE (to do mutual authentication, if it was requested) followed
-   by the ACCEPT.
-
-   If forwarding has been requested, the client then sends IAC SB AU-
-   THENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED structure
-   with credentials to be forwarded> IAC SE.  If the server succeeds in
-   reading the forwarded credentials, the server sends FORWARD_ACCEPT
-   else, a FORWARD_REJECT is sent back.
-
-       Client                           Server
-                                        IAC DO AUTHENTICATION
-       IAC WILL AUTHENTICATION
-
-       [ The server is now free to request authentication information.
-         ]
-
-                                        IAC SB AUTHENTICATION SEND
-                                        KERBEROS_V5 CLIENT|MUTUAL
-                                        KERBEROS_V5 CLIENT|ONE_WAY IAC
-                                        SE
-
-       [ The server has requested mutual Version 5 Kerberos
-         authentication.  If mutual authentication is not supported,
-         then the server is willing to do one-way authentication.
-
-         The client will now respond with the name of the user that it
-         wants to log in as, and the Kerberos ticket.  ]
-
-       IAC SB AUTHENTICATION NAME
-       "pete" IAC SE
-       IAC SB AUTHENTICATION IS
-       KERBEROS_V5 CLIENT|MUTUAL AUTH
-       <KRB_AP_REQ message> IAC SE
-
-                           Expires Sept 2000                    [Page 4]
-
-Internet-Draft        Kerberos Version 5 for Telnet           April 2000
-
-       [ Since mutual authentication is desired, the server sends across
-         a RESPONSE to prove that it really is the right server.  ]
-
-                                        IAC SB AUTHENTICATION REPLY
-                                        KERBEROS_V5 CLIENT|MUTUAL
-                                        RESPONSE <KRB_AP_REP message>
-                                        IAC SE
-
-       [ The server responds with an ACCEPT command to state that the
-         authentication was successful.  ]
-
-                                        IAC SB AUTHENTICATION REPLY KER-
-                                        BEROS_V5 CLIENT|MUTUAL ACCEPT
-                                        IAC SE
-
-       [ If so requested, the client now sends the FORWARD command to
-         forward credentials to the remote site.  ]
-
-       IAC SB AUTHENTICATION IS KER-
-       BEROS_V5 CLIENT|MUTUAL
-       FORWARD <KRB_CRED message> IAC
-       SE
-
-       [ The server responds with a FORWARD_ACCEPT command to state that
-         the credential forwarding was successful.  ]
-
-                           Expires Sept 2000                    [Page 5]
-
-Internet-Draft        Kerberos Version 5 for Telnet           April 2000
-
-                                        IAC SB AUTHENTICATION REPLY KER-
-                                        BEROS_V5 CLIENT|MUTUAL FOR-
-                                        WARD_ACCEPT IAC SE
-
-5. Security Considerations
-
-   The selection of the random session key in the Kerberos V5 authenti-
-   cator is critical, since this key will be used for encrypting the
-   telnet data stream if encryption is enabled.  It is strongly advised
-   that the random key selection be done using cryptographic techniques
-   that involve the Kerberos ticket's session key.  For example, using
-   the current time, encrypting it with the ticket session key, and then
-   correcting for key parity is a strong way to generate a subsession
-   key, since the ticket session key is assumed to be never disclosed to
-   an attacker.
-
-   Care should be taken before forwarding a user's Kerberos credentials
-   to the remote server.  If the remote server is not trustworthy, this
-   could result in the user's credentials being compromised.  Hence, the
-   user interface should not forward credentials by default; it would be
-   far safer to either require the user to explicitly request creden-
-   tials forwarding for each connection, or to have a trusted list of
-   hosts for which credentials forwarding is enabled, but to not enable
-   credentials forwarding by default for all machines.
-
-6. IANA Considerations
-
-   The authentication type KERBEROS_V5 and its associated suboption values
-   are registered with IANA.  Any suboption values used to extend 
-   the protocol as described in this document must be registered
-   with IANA before use.  IANA is instructed not to issue new suboption
-   values without submission of documentation of their use.
-
-7. Acknowledgments
-
-   This document was originally written by Dave Borman of Cray Research,
-   Inc.  Theodore Ts'o of MIT revised it to reflect the latest implemen-
-   tation experience.  Cliff Neuman and Prasad Upasani of USC's Informa-
-   tion Sciences Institute developed the credential forwarding support.
-
-   In addition, the contributions of the Telnet Working Group are also
-   gratefully acknowledged.
-
-8. References
-
-   [1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Sys-
-       tem (V5)", RFC 1510, USC/Information Sciences Institute, Septem-
-       ber 1993.
-
-   [2] Internet Engineering Task Force, "Telnet Authentication", draft-
-       tso-telnet-auth-enc-04.txt, T. Ts'o, Editor, VA Linux Systems,
-           April 2000.
-
-   [3] Internet Engineering Task Force, "Telnet Data Encryption Option",
-       draft-tso-telnet-encryption-04.txt, T. Ts'o, Editor, VA Linux
-       Systems,     April 2000.
-
-   [4] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC
-
-                           Expires Sept 2000                    [Page 6]
-
-Internet-Draft        Kerberos Version 5 for Telnet           April 2000
-
-       855, STD 8, USC/Information Sciences Institute, May 1983.
-
-Editor's Address
-
-   Theodore Ts'o
-   Massachusetts Institute of Technology
-   MIT Room E40-343
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-
-   Phone: (617) 253-8091
-   EMail: tytso@mit.edu
-
-                           Expires Sept 2000                    [Page 7]
-
-
-    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
-                 The Kermit Project * Columbia University
-              612 West 115th St #716 * New York, NY * 10025
-  http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org
-
-
diff --git a/doc/standardisation/draft-williams-gssapi-domain-based-names-00.txt b/doc/standardisation/draft-williams-gssapi-domain-based-names-00.txt
deleted file mode 100644
index f310a0236..000000000
--- a/doc/standardisation/draft-williams-gssapi-domain-based-names-00.txt
+++ /dev/null
@@ -1,557 +0,0 @@
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: December 30, 2004                                     July 2004
-
-
-
-            GSS-API Domain-Based Service Names and Name Type
-            draft-williams-gssapi-domain-based-names-00.txt
-
-
-Status of this Memo
-
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-
-   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."
-
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-   This Internet-Draft will expire on December 30, 2004.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-
-Abstract
-
-
-   This document describes domainname-based service principal names and
-   the corresponding name type for the GSS-API.
-
-
-   Domain-based service names are similar to host-based service names,
-   but using a domain name (not necessarily and Internat domain name)
-   instead of or in addition to a hostname.  The primary purpose of
-   domain-based service names is to provide a way to name clustered
-   services after the domain which they service, thereby allowing their
-   clients to authorize the service's servers based on authentication of
-   their names.
-
-
-
-
-Williams               Expires December 30, 2004                [Page 1]
-Internet-Draft           GSS Domain Based Names                July 2004
-
-
-
-Table of Contents
-
-
-   1. Conventions used in this document  . . . . . . . . . . . . . . . 3
-   2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
-   3. Name Type OID and Symbolic Name  . . . . . . . . . . . . . . . . 5
-   4. Query and Display Syntaxes . . . . . . . . . . . . . . . . . . . 6
-   5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-   6. Security Considerations  . . . . . . . . . . . . . . . . . . . . 8
-   7. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
-      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
-      Intellectual Property and Copyright Statements . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 2]
-Internet-Draft           GSS Domain Based Names                July 2004
-
-
-
-1.  Conventions used in this document
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 3]
-Internet-Draft           GSS Domain Based Names                July 2004
-
-
-
-2.  Introduction
-
-
-   The use of hostbased principal names for domain-wide services
-   presents the problem of how to distinguish between an instance of a
-   hostbased service that is authorized to respond for a domain and one
-   that isn't.
-
-
-   Consider LDAP.  LDAP with SASL and the Kerberos V GSS-API mechanism
-   uses a hostbased principal with a service name of "ldap", a
-   reasonable approach, provided there is only one logical LDAP
-   directory in a Kerberos realm's domain, and that all ldap servers in
-   that realm serve that one LDAP directory.  If there were other LDAP
-   directories, then clients could not tell which service is authorized
-   to serve which directory, not without assuming a secure method for
-   finding LDAP servers (e.g., DNSSEC).  This is a significant, and
-   oft-unstated restriction on users of LDAP.
-
-
-   Domain based names can eliminate this problem by allowing LDAP
-   service names to indicate which LDAP directory they are authorized to
-   serve.
-
-
-   A domain-based name consists of three required elements:
-   o  a service name
-   o  a domain name
-   o  a hostname
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 4]
-Internet-Draft           GSS Domain Based Names                July 2004
-
-
-
-3.  Name Type OID and Symbolic Name
-
-
-   The new name type has an OID of
-      [NOTE:  OID assignment to be made with IANA.]
-
-
-      {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6)
-      gss-domain-based(5)}
-
-
-   The recommended symbolic name for this GSS-API name type is
-   "GSS_C_NT_DOMAINBASED_SERVICE".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 5]
-Internet-Draft           GSS Domain Based Names                July 2004
-
-
-
-4.  Query and Display Syntaxes
-
-
-   There is a single syntax that applies to both query and display forms
-   of domain-based names.  (We ignore string profile matters here as the
-   GSS-API's, and its mechanisms' use of character strings are out of
-   scope for this document.)
-
-
-   The syntax is:
-      domain-based-name :=
-         | <service> '@' <domain> '@' <hostname>
-         | <service> '@@' <hostname>
-
-
-   The domain name element is only optional in the query syntax of
-   domain-based names.
-
-
-   A missing domain name is always to be added by the GSS-API mechanisms
-   during name canonicalization, using whatever default values are
-   appropriate for the mechanisms.
-
-
-   Therefore the display form of domain-based MNs (see [RFC2743]) MUST
-   include all three elements of domain-based names.
-
-
-   Note that for Internet domain names the trailing '.' is not and MUST
-   NOT be included in the domain name (or hostname) parts of the display
-   form GSS-API domain-based MNs.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 6]
-Internet-Draft           GSS Domain Based Names                July 2004
-
-
-
-5.  Examples
-
-
-   o  ldap@@ds1.example.tld
-   o  ldap@example.tld@ds1.example.tld
-
-
-   o  kadmin@@kdc1.example.tld
-   o  kadmin@example.tld@kdc1.example.tld
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 7]
-Internet-Draft           GSS Domain Based Names                July 2004
-
-
-
-6.  Security Considerations
-
-
-   Use of GSS-API domain-based names may not be negotiable by some
-   GSS-API mechanisms, and some acceptors may not support GSS-API
-   domain-based names.  In such cases initiators are left to fallback on
-   the use of hostbased names, in which case the initiators MUST also
-   verify that the acceptor's hostbased name is authorized to provide
-   the given service for the domain that the initiator had wanted.
-
-
-   The above security consideration also applies to all GSS-API
-   initiators who lack support for domain-based service names.
-
-
-7  Normative
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-
-Author's Address
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 8]
-Internet-Draft           GSS Domain Based Names                July 2004
-
-
-
-Intellectual Property Statement
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams               Expires December 30, 2004                [Page 9] 
\ No newline at end of file
diff --git a/doc/standardisation/draft-williams-gssapi-extensions-iana-00.txt b/doc/standardisation/draft-williams-gssapi-extensions-iana-00.txt
deleted file mode 100644
index 6184b6491..000000000
--- a/doc/standardisation/draft-williams-gssapi-extensions-iana-00.txt
+++ /dev/null
@@ -1,617 +0,0 @@
-
-
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: December 30, 2004                                     July 2004
-
-
-     Namespace Considerations and Registries for GSS-API Extensions
-              draft-williams-gssapi-extensions-iana-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on December 30, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This document describes the ways in which the GSS-API may be extended
-   and directs the creation of IANA registries for GSS-API namespaces
-   that may be affected by any extensions.
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 1]
-
-Internet-Draft      GSS-API Namespace Considerations           July 2004
-
-
-Table of Contents
-
-   1. Conventions used in this document  . . . . . . . . . . . . . .   3
-   2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   4
-   3. Extensions to the GSS-API  . . . . . . . . . . . . . . . . . .   5
-   4. Generic GSS-API Namespaces . . . . . . . . . . . . . . . . . .   6
-   5. Language Binding-Specific GSS-API Namespaces . . . . . . . . .   7
-   6. Extension-Specific GSS-API Namespaces  . . . . . . . . . . . .   8
-   7. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .   9
-   8. Security Considerations  . . . . . . . . . . . . . . . . . . .  10
-   9. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
-      Author's Address . . . . . . . . . . . . . . . . . . . . . . .  10
-      Intellectual Property and Copyright Statements . . . . . . . .  11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 2]
-
-Internet-Draft      GSS-API Namespace Considerations           July 2004
-
-
-1.  Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 3]
-
-Internet-Draft      GSS-API Namespace Considerations           July 2004
-
-
-2.  Introduction
-
-   There is a need for generic and mechanism-specific extensions to the
-   Generic Security Services Application Programming Interface
-   (GSS-API).  As such extensions are designed and standardized, both at
-   the IETF and elsewhere, there is a non-trivial risk of namespace
-   pollution and conflicts.  To avoid this we set out guidelines for
-   extending the GSS-API and create IANA registries of GSS-API
-   namespaces.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 4]
-
-Internet-Draft      GSS-API Namespace Considerations           July 2004
-
-
-3.  Extensions to the GSS-API
-
-   Extensions to the GSS-API can be categorized as follows:
-   o  Generic
-   o  Implementation-specific
-   o  Mechanism-specific
-   o  Language binding-specific
-   o  Any combination of two or all three of the last three
-
-   Extensions to the GSS-API may be purely semantic, without effect on
-   the GSS-API's namespaces.  Or they may introduce new functions,
-   constants, types, etc...; these clearly affect the GSS-API
-   namespaces.
-
-   Extensions that affect the GSS-API namespaces should be registered
-   with the IANA< along with their specific effects on the GSS-API
-   namespaces.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 5]
-
-Internet-Draft      GSS-API Namespace Considerations           July 2004
-
-
-4.  Generic GSS-API Namespaces
-
-   All the function, constant and type names, as well as all the
-   constant values specified in the base GSS-API specification for the
-   basic generic GSS-API namespace.
-
-   The generic GSS-API namespaces are:
-   o  Type names
-   o  Function names
-   o  Constant names for each type
-   o  Constant values for each type
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 6]
-
-Internet-Draft      GSS-API Namespace Considerations           July 2004
-
-
-5.  Language Binding-Specific GSS-API Namespaces
-
-   <Add text; discuss header, module, library, class namespaces and
-   whatever else comes up that is language-specific and appropriate for
-   registration with the IANA.>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 7]
-
-Internet-Draft      GSS-API Namespace Considerations           July 2004
-
-
-6.  Extension-Specific GSS-API Namespaces
-
-   Extensions to the GSS-API may create additional namespaces.  IANA
-   registries SHOULD be created for any such new namespaces.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 8]
-
-Internet-Draft      GSS-API Namespace Considerations           July 2004
-
-
-7.  IANA Considerations
-
-   The following registries should be established upon publication of
-   this document as an RFC:
-   o  GSS-API Type Name Registry
-   o  GSS-API Function Name Registry
-   o  GSS-API Constant Name Registry
-   o  GSS-API Constant Value Registry
-   o  GSS-API Class/Header/Library/Module Name Registry
-
-   Entries in these registries should consist of:
-   o  Namespace name
-   o  Symbol name or prefix, OR value or value range.
-   o  [optional] Reference to normative reference for the registration.
-   o  [optional] Programming language
-   o  [optional] Entry sub-type (e.g., "header name")
-   o  [optional] Mechanism OID(s) and/or OID prefix(es) associated with
-      the entry
-   o  [optional] Magic
-   o  [optional] Expert Review (body or people who reviewed the
-      registration)
-   o  [optional] Description (in English)
-
-   <Add text on guidelines for IANA consideration of registration
-   applications, particularly with respect to entries w/o normative
-   references, "magic" entries (e.g., special values of 'time' types
-   which indicate something other than absolute or relative time, such
-   as GSS_C_INDEFINITE), expert review requirements for registrations w/
-   o normative references, etc....>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 9]
-
-Internet-Draft      GSS-API Namespace Considerations           July 2004
-
-
-8.  Security Considerations
-
-   This document has no security considerations.
-
-9  Normative
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 10]
-
-Internet-Draft      GSS-API Namespace Considerations           July 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams               Expires December 30, 2004               [Page 11]
-
-
diff --git a/doc/standardisation/draft-williams-gssapi-prf-00.txt b/doc/standardisation/draft-williams-gssapi-prf-00.txt
deleted file mode 100644
index 097ce8515..000000000
--- a/doc/standardisation/draft-williams-gssapi-prf-00.txt
+++ /dev/null
@@ -1,498 +0,0 @@
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: December 30, 2004                                    S. Hartman
-                                                                     MIT
-                                                               July 2004
-
-
-
-                  A PRF API extension for the GSS-API
-                    draft-williams-gssapi-prf-00.txt
-
-
-Status of this Memo
-
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-
-   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."
-
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-   This Internet-Draft will expire on December 30, 2004.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-
-Abstract
-
-
-   This document defines a Pseudo-Random Function (PRF) extension to the
-   GSS-API for keying application protocols given an established GSS-API
-   security context.
-
-
-
-
-
-
-
-
-
-Williams & Hartman     Expires December 30, 2004                [Page 1]
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-
-Table of Contents
-
-
-   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . .  5
-   3.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
-   5.  Normative  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  6
-       Intellectual Property and Copyright Statements . . . . . . . .  8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams & Hartman     Expires December 30, 2004                [Page 2]
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-
-1.  Conventions used in this document
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams & Hartman     Expires December 30, 2004                [Page 3]
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-
-2.  Introduction
-
-
-   A need has arisen for users of the GSS-API to key applications'
-   cryptographic protocols using established GSS-API security contexts.
-   Such applications can use the GSS-API for authentication, but not for
-   transport security (for whatever reasons), and since the GSS-API does
-   not provide a method for obtaining keying material from established
-   security contexts such applications cannot make effective use of the
-   GSS-API.
-
-
-   To address this need we define a PRF extension to the GSS-API.
-
-
-   At this point EAP may be the primary consumer of this extension.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams & Hartman     Expires December 30, 2004                [Page 4]
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-
-3.  GSS_Pseudo_random()
-
-
-   Inputs:
-
-
-   o  context CONTEXT handle,
-   o  prf_in OCTET STRING
-
-
-   Outputs:
-
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  prf_out OCTET STRING
-
-
-   Return major_status codes:
-   o  GSS_S_COMPLETE indicates no error.
-   o  GSS_S_NO_CONTEXT indicates that a null context has been provided
-      as input.
-   o  GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
-      provided as input.
-   o  GSS_S_FAILURE indicates failure or lack of support; the minor
-      status code may provide additional information.
-
-
-   This function applies the context's mechanism's keyed PRF function to
-   the input data (prf_in), keyed with key material associated with the
-   given security context and outputs the result (prf_out).
-
-
-3.1  C-Bindings
-
-
-   OM_uint32 gss_pseudo_random(
-     OM_uint32                  *minor_status,
-     gss_ctx_id_t                       context,
-     const gss_buffer_t         prf_in,
-     gss_buffer_t            prf_out
-   );
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams & Hartman     Expires December 30, 2004                [Page 5]
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-
-4.  Security Considerations
-
-
-   GSS mechanisms' PRF functions should use a key derived from contexts'
-   session keys and should preserve the forward security properties of
-   the mechanisms' key exchanges.
-
-
-   Care should be taken in properly designing a mechanism's PRF
-   function.  Cryptographic hash functions which do not provide strong
-   collision resistance should not be used, except through HMAC.
-
-
-   GSS mechanisms' PRF functions may output fewer octets than the
-   application may need, therefore GSS-API applications that use
-   GSS_Pseudo_random() may require a "PRF+" construction based on
-   GSS_Pseudo_random().
-
-
-   [Question:  Should GSS_Pseudo_random() have an input roughly
-   corresponding to the "key usage" used for key derivation in Kerberos
-   V?]
-
-
-5  Normative
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-
-Authors' Addresses
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-   Sam Hartman
-   Massachussets Institute of Technology
-   ...
-   ..., MA  ...
-   US
-
-
-
-
-
-Williams & Hartman     Expires December 30, 2004                [Page 6]
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-
-   EMail: hartmans@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams & Hartman     Expires December 30, 2004                [Page 7]
-Internet-Draft      A PRF Extension for the GSS-API            July 2004
-
-
-
-Intellectual Property Statement
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams & Hartman     Expires December 30, 2004                [Page 8] 
\ No newline at end of file
diff --git a/doc/standardisation/draft-williams-gssapi-store-deleg-creds-01.txt b/doc/standardisation/draft-williams-gssapi-store-deleg-creds-01.txt
deleted file mode 100644
index b14696e42..000000000
--- a/doc/standardisation/draft-williams-gssapi-store-deleg-creds-01.txt
+++ /dev/null
@@ -1,466 +0,0 @@
-
-INTERNET-DRAFT                                          Nicolas Williams
-                                                        Sun Microsystems
-                                                          September 2003
-
-
-
-           GSS-APIv2 Extension for Storing Delegated Credentials
-             <draft-williams-gssapi-store-deleg-creds-01.txt>
-
-
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026 [RFC2026].
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This draft expires on January 30th, 2004. Please send comments to
-   the authors.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document defines a new function for the GSS-API which allows
-   applications to store delegated (and other) credentials in the
-   implicit GSS-API credential store.  This is needed for GSS-API
-   applications to use delegated credentials as they would use other
-   credentials.
-
-Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-N. Williams							[Page 1]
-
-DRAFT		GSS_Store_cred()			Expires March 2004
-
-
-Table of Contents
-
-   1  Introduction
-   2  GSS_Store_cred()
-   2.1  C-Bindings for GSS_Store_cred()
-   3  Examples
-   4  Security Considerations
-   5  References
-   5.1  Normative References
-   6  Author's Address
-
-1  Introduction
-
-   The GSS-API [RFC2743] clearly assumes that credentials exist in an
-   implicit store whence they can be acquired using GSS_Acquire_cred()
-   and GSS_Add_cred() or through use of the default credential.
-   Multiple credential stores may exist on a given host, but only one
-   store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
-   given time.
-
-   [NOTE:  This assumption can be seen in sections 1.1.1.2 and 1.1.1.3
-           of RFC2743 as well as in section 3.5 of RFC2744.
-
-	   Note to the RFC editor: please remove this note before
-	   publication.]
-
-   Applications may be able to change the credential store from which
-   credentials can be acquired, either by changing user contexts (where
-   the applications have the privilege to do so) or by other means
-   (where a user may have multiple credential stores).
-
-   Some GSS-API acceptor applications always change user contexts, after
-   accepting a GSS-API security context and making appropriate
-   authorization checks, to the user context corresponding to the
-   initiator principal name or to a context requested by the initiator.
-   The means by which credential stores are managed are generally beyond
-   the scope of the GSS-API.
-
-   In the case of delegated credential handles however, such credentials
-   do not exist in the acceptor's credential store or in the credential
-   stores of the user contexts to which the acceptor application might
-   change - which is precisely the raison d'etre of credential
-   delegation.  But the GSS-API provides no mechanism by which delegated
-   credential handles can be made available for acquisition through
-   GSS_Acquire_cred()/GSS_Add_cred().  The GSS-API also does not provide
-   any credential import/export interfaces like the GSS-API context
-   import/export interfaces.
-
-   Thus acceptors are limited to making only direct use of delegated
-   credential handles and only with GSS_Init_sec_context(),
-   GSS_Inquire_cred*() and GSS_Release_cred().  This limitation is
-   particularly onerous on Unix systems where a call to exec() to
-
-N. Williams							[Page 2]
-
-DRAFT		GSS_Store_cred()			Expires March 2004
-
-   replace the process image obliterates the delegated credentials
-   handle.  
-
-   [NOTE:  Delegated credentials are practically unusable on Unix
-	   implementations of Secure Shell (SSHv2) servers, except where
-	   there are extended interfaces for dealing with delegated
-	   credentials, which to date have always been
-	   mechanism-specific interfaces.
-
-	   Note to the RFC editor: please remove this note before
-	   publication.]
-
-   In order to make delegated credentials generally as useful as
-   credentials that can be acquired with GSS_Acquire_cred() and
-   GSS_Add_cred() a primitive is needed which allows storing of
-   credentials in the implicit credential store.  This primitive we call
-   "GSS_Store_cred()."
-
-   [NOTE:  Simon Wilkinson's patches to OpenSSH for GSS-API sport a
-           simple internal interface for storing delegated credentials
-	   in users' credential store - this internal interface wraps
-	   around two mechanism specific internal interfaces for storing
-	   GSI and Kerberos V credentials.
-
-	   Simon's code shows that:
-
-	   a) a generic method is needed for making delegated
-	      credentials available for indirect use through acquisition
-	      (as opposed to just using the actual delegated cred
-	      handle)
-
-           b) it is possible to design and implement such a generic
-	      method for storing delegated credentials.
-
-	   No new concepts are added to the GSS-API by this document,
-	   but the implicit existence of a credential store in the
-	   background is made explicit, and a deficiency of the GSS-API
-	   is corrected.
-
-	   Compare this to the GGF proposal which includes a credential
-	   import/export facility (like the existing context import/
-	   export facility), but with an option to export as
-	   "environment variables," meaning something like "store these
-	   input creds in some new credential store and then tell me the
-	   name of that credential store through some output environment
-	   variable"[*].  Thus, the GGF export-cred-to-environment-
-	   variable proposal adds knowledge of environment variables to
-	   the GSS-API, which this proposal does not.  Note that a
-	   credential import/export facility along the lines of the
-	   existing context import/export facility may be useful and
-	   complements the GSS_Store_cred() interface; in fact, with
-	   GSS_Store_cred() it should be possible to remove the
-	   'option_req' input parameter and export-to-env-var features
-
-N. Williams							[Page 3]
-
-DRAFT		GSS_Store_cred()			Expires March 2004
-
-	   of the GGF's GSS_Export_cred() credential export proposal.
-
-	   [*]  For the exact semantics see section 1.2, paragraph 6 of
-	        draft-engert-ggf-gss-extensions-00.txt
-
-	   One side effect of GSS_Store_cred(), however, is that it
-	   allows applications that can switch their current credential
-	   store to move credentials from one store to the other; this
-	   is a direct result of making it possible to store a
-	   credential given a GSS-API credential handle.  Perhaps there
-	   should be some text allowing, or recommending, that
-	   implementations of GSS_Store_cred() allow only the storage of
-	   credentials acquired through credential delegation.
-
-	   Note to the RFC editor: please remove this note before
-	   publication.]
-
-2  GSS_Store_cred()
-
-   Inputs:
-
-   o  input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
-   -- NOT be GSS_C_NO_CREDENTIAL
-
-   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-   -- 2=ACCEPT-ONLY
-
-   o  desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID
-   -- then store all the elements of the input_cred_handle, otherwise
-   -- store only the element of the corresponding mechanism
-
-   o  overwrite_cred BOOLEAN, -- if TRUE replace any credential for the
-   -- same principal in the credential store
-
-   o  default_cred BOOLEAN -- if TRUE make the stored credential
-   -- available as the default credential (for acquisition with
-   -- GSS_C_NO_NAME as the desired name or for use as
-   -- GSS_C_NO_CREDENTIAL)
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
-   -- mechanism OIDs for which credential elements were successfully
-   -- stored
-
-   o  cred_usage_stored INTEGER -- like cred_usage, but indicates what
-   -- kind of credential was stored (useful when the cred_usage input
-   -- parameter is set to INITIATE-AND-ACCEPT)
-
-
-N. Williams							[Page 4]
-
-DRAFT		GSS_Store_cred()			Expires March 2004
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the credentials were successfully
-   stored.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials
-   had expired or expired before they could be stored.
-
-   o  GSS_S_NO_CRED indicates that no input credentials were given.
-
-   o  GSS_S_UNAVAILABLE indicates that the credential store is not
-   available.
-
-   o  GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
-   credential could not be stored because a credential for the same
-   principal exists in the current credential store and the
-   overwrite_cred input argument was FALSE.
-
-   o  GSS_S_FAILURE indicates that the credential could not be stored
-   for some other reason.  The minor status code may provide more
-   information if a non-GSS_C_NULL_OID desired_mech_element was given.
-
-   GSS_Store_cred() is used to store, in the current credential store, a
-   given credential that has either been acquired from a different
-   credential store or been accepted as a delegated credential.
-
-   Specific mechanism elements of a credential can be stored one at a
-   time by specifying a non-GSS_C_NULL_OID mechanism OID as the
-   desired_mech_element input argument, in which case the minor status
-   output SHOULD have a mechanism-specific value when the major status
-   is not GSS_S_COMPLETE.
-
-   The initiator, acceptor or both usages of the input credential may be
-   stored as per the cred_usage input argument.
-
-   The credential elements that were actually stored, when the major
-   status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
-   and mech_elements_stored function outputs.
-
-   If credentials already exist in the current store for the principal
-   of the input_cred_handle, then those credentials are not replaced
-   with the input credentials unless the overwrite_cred input argument
-   is TRUE.
-
-   Finally, if the current credential store has no default credential
-   (that is, no credential that could be acquired for GSS_C_NO_NAME) or
-   if the default_cred input argument is TRUE, and the input credential
-   can be successfully stored, then the input credential will be
-   available for acquisition with GSS_C_NO_NAME as the desired name
-   input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as
-   GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(),
-   GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and
-   GSS_Accept_sec_context().
-
-N. Williams							[Page 5]
-
-DRAFT		GSS_Store_cred()			Expires March 2004
-
-
-2.1  C-Bindings for GSS_Store_cred()
-
-   The C-bindings for GSS_Store_cred() make use of types from and are
-   designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
-
-   OM_uint32 gss_store_cred(
-      OM_uint32         *minor_status,
-      gss_cred_id_t     input_cred,
-      gss_cred_usage_t  cred_usage,
-      const gss_OID     desired_mech,
-      OM_uint32         overwrite_cred,
-      OM_uint32         default_cred,
-      gss_OID_set       *elements_stored,
-      gss_cred_usage_t  *cred_usage_stored)
-
-   The two boolean arguments, 'overwrite_cred' and 'default_cred' are
-   typed as OM_uint32; 0 corresponds to FALSE, non-zero values
-   correspond to TRUE.
-
-3  Examples
-
-   The intended usage of GSS_Store_cred() is to make delegated
-   credentials available to child processes of GSS-API acceptor
-   applications.  Example pseudo-code:
-
-   /*
-    * <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE, an
-    * initiator name (hereafter, "src_name") and a delegated credential
-    * handle (hereafter "deleg_cred").>
-    *
-    * <"requested_username" is a username derived from the initiator
-    * name or explicitly requested by the initiator application.>
-    */
-   ...
-
-   if (authorize_gss_client(src_name, requested_username)) {
-      /*
-       * For Unix-type platforms this may mean calling setuid() and it
-       * may or may not also mean setting/unsetting such environment
-       * variables as KRB5CCNAME and what not.
-       */
-      if (change_user_context(requested_username))
-         (void) gss_store_creds(&minor_status, deleg_cred,
-				GSS_C_INITIATE, actual_mech,
-				0, 1, NULL, NULL);
-      }
-      else ...
-   }
-   else ...
-
-4  Security Considerations
-
-
-N. Williams							[Page 6]
-
-DRAFT		GSS_Store_cred()			Expires March 2004
-
-   Acceptor applications MUST only store delegated credentials into
-   appropriate credential stores and only after proper authorization of
-   the authenticated initiator principal to the requested service(s).
-
-   Acceptor applications that have no use for delegated credentials MUST
-   release them (such acceptor applications that use the GSS-API
-   C-Bindings may simply provide a NULL value for the
-   delegated_cred_handle argument to gss_accept_sec_context()).
-
-5  References
-
-5.1  Normative References
-
-   [RFC2026]
-      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
-      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
-      Practice.
-
-   [RFC2119]
-      S. Bradner, RFC2119 (BCP14):  "Key words for use in RFCs to
-      Indicate Requirement Levels," March 1997, Status: Best Current
-      Practice.
-
-   [RFC2743]
-      J. Linn, RFC2743: "Generic Security Service Application Program
-      Interface Version 2, Update 1," January 2000, Status: Proposed
-      Standard.
-
-   [RFC2744]
-      J. Wray, RFC2744: "Generic Security Service API Version 2 :
-      C-bindings," January 2000, Status: Proposed Standard.
-
-6  Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX 78727
-   Email: Nicolas.Williams@sun.com
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-
-N. Williams							[Page 7]
-
-DRAFT		GSS_Store_cred()			Expires March 2004
-
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-N. Williams							[Page 8]
diff --git a/doc/standardisation/draft-williams-gssapi-v3-guide-to-00.txt b/doc/standardisation/draft-williams-gssapi-v3-guide-to-00.txt
deleted file mode 100644
index c7d879b04..000000000
--- a/doc/standardisation/draft-williams-gssapi-v3-guide-to-00.txt
+++ /dev/null
@@ -1,1200 +0,0 @@
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: December 30, 2004                                     July 2004
-
-
-
-                         Guide to the GSS-APIv3
-                draft-williams-gssapi-v3-guide-to-00.txt
-
-
-Status of this Memo
-
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-
-   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."
-
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-   This Internet-Draft will expire on December 30, 2004.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-
-Abstract
-
-
-   Extensions to the GSS-APIv2 are needed for a number of reasons.  This
-   documents describes the extensions being proposed, the resons,
-   possible future directions, and portability, IANA and security
-   considerations.  This document does not define any protocol or
-   interface and is purely informational.
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 1]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-Table of Contents
-
-
-   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  A Pseudo-Mechanism OID for the GSS-API Itself  . . . . . . . .  5
-   4.  Mechanism Attribute Inquiry Facilities . . . . . . . . . . . .  6
-   5.  Security Context Extensibility Extensions  . . . . . . . . . .  7
-   6.  Credential Extensibility Extensions  . . . . . . . . . . . . .  8
-   7.  Credential Export/Import . . . . . . . . . . . . . . . . . . .  9
-   8.  GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 10
-   9.  Pseudo-Mechanism Stacking  . . . . . . . . . . . . . . . . . . 11
-   10. Naming Extensions  . . . . . . . . . . . . . . . . . . . . . . 12
-   11. Additional Name Types  . . . . . . . . . . . . . . . . . . . . 13
-   12. GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . . 14
-   13. Channel Bindings Specifications  . . . . . . . . . . . . . . . 15
-   14. Semantic and Miscallaneous Extensions  . . . . . . . . . . . . 16
-   15. Portability Considerations . . . . . . . . . . . . . . . . . . 17
-   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
-   17. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
-   18. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
-       Intellectual Property and Copyright Statements . . . . . . . . 20
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 2]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-1.  Conventions used in this document
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 3]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-2.  Introduction
-
-
-   [NOTE: the references section is current fairly empty; the various
-   KITTEN WG work items will be added to this I-D in a subsequent
-   revision.]
-
-
-   Since the advent of the GSS-APIv2 it has come to be used in a number
-   of Internet (and other) protocols and a number of implementations
-   exist.  In that time implementors and protocol designers have come to
-   understand both, the GSS-API's strengths, and its shortcommings; we
-   believe now that a number of extensions to the GSS-API are needed.
-   Here these proposed extensions, forming what we may call the GSS-API
-   version 3, are described at a high-level.;
-
-
-   Some of these extensions are intended to facilitate further
-   extensions, so that further major revisions to the GSS-API may not be
-   necessary.  Others are intended to fill voids in the the GSS-APIv2.
-
-
-   The extensions being proposed are:
-      A pseudo-mechanism OID for the GSS-API itself
-      Mechanism attribute inquiry facilities
-      Security context extensibility extensions
-      Credential extensibility extensions
-      Credential export/import
-      GSS_Store_cred(), for making delegated credentials available for
-      acquisition
-      Pseudo-mechanism stacking
-      Naming extensions, to facilitate authorization by identifiers
-      other than names
-      Additional name types, specifically domain-based naming
-      A pseudo-random function interface
-      Channel bindings specifications
-      Semantic extensions relating to thread- and/or fork-safety
-      [Have I missed anything?  I have a feeling I have.  Re-keying?]
-      ...
-
-
-   Additionally, because we foresee future minor extensions, including,
-   specifically, extensions which may impact the various namespaces
-   associated with APIs (symbol names, constant values, class names,
-   etc...) we also propose the establishment of IANA registries for
-   these namespaces.
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 4]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-3.  A Pseudo-Mechanism OID for the GSS-API Itself
-
-
-   A mechanism OID is assigned to identify and refer to the GSS-API
-   iself.  This is necessary to enable the use of extended inquiry
-   interfaces to inquire about features of a GSS-API implementation
-   specifically, apart from actual mechanisms.
-
-
-   But also, this OID is needed for better error handling, so that minor
-   status codes produced in generic contexts that lack a mechanism OID
-   can be distinguished from minor status codes for a "default"
-   mechanism and properly displayed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 5]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-4.  Mechanism Attribute Inquiry Facilities
-
-
-   In the course of designing a pseudo-mechanism stacking facility, as
-   well as while considering the impact of all of these extensions on
-   portability, a need for interfaces through which to discover or
-   inquire by features provided by GSS-API mechanisms was discovered.
-
-
-   The proposed mechanism attribute inquiry interfaces consist of:
-      GSS_Inquire_mech_attrs_for_mech()
-      GSS_Indicate_mechs_by_mech_attrs()
-      GSS_Display_mech_attr()
-
-
-   These extensions facilitate portability by allowing GSS-APIv3
-   applications to discover the features provided by a given
-   implementation of the GSS-API or any mechanisms.  These extensions
-   are also useful in facilitating stackable pseudo-mechanisms.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 6]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-5.  Security Context Extensibility Extensions
-
-
-   In order to facilitate future security context options we introduce a
-   GSS_Create_sec_context() interface that creates a security context
-   object, for use with extensions and with GSS_Init_sec_context(),
-   GSS_Accept_sec_context(), and GSS_Inquire_sec_context().  Such
-   security contexts are in a non-established state until they are
-   established through the use of GSS_Init_sec_context() or
-   GSS_Accept_sec_context().
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 7]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-6.  Credential Extensibility Extensions
-
-
-   In order to facilitate future extensions to GSS credentials we
-   introduce a GSS_Create_credential(), similar to
-   GSS_Create_sec_context(), interface that creates an "empty"
-   credential.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 8]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-7.  Credential Export/Import
-
-
-   To allow for passing of credentials between different "session
-   contexts," between different hosts, or for storage of post-dated
-   credentials, we introduce a credential export/import facility, much
-   like the security context export/import facility of the GSS-APIv2.
-
-
-   Together with credential extensibility and other extensions this
-   facility may allow for:
-      Credential delegation at any time
-      Post-dated credentials, and storage of the such for subsequent
-      use.
-      ...?
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 9]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-8.  GSS_Store_cred()
-
-
-   This extension fills a void in the GSS-APIv2 where delegated
-   credentials could not be used except in the context of the same
-   process that received them.  With this extension acceptor
-   applications can now make delegated credentials available for use,
-   with GSS_Acquire_cred() et.  al., in other process contexts.
-
-
-   [Manipulation of "credential stores" is (may be?) out of scope for
-   this document.]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 10]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-9.  Pseudo-Mechanism Stacking
-
-
-   A number of pseudo-mechanisms are being proposed which are designed
-   to "stack" atop other mechanisms.  The possiblities are many,
-   including: a compression mechanism, a perfect forward security
-   mechanism, an many others.
-
-
-   The GSS-APIv2 only had concrete mechanisms and one pseudo-mechanism
-   (SPNEGO) available.  With this proposal the mechanism taxonomy is
-   quite expanded:
-      Concrete mechanisms (e.g., the Kerberos V mechanism)
-      Composite mechanisms (a concrete mechanism composed with one or
-      more stackable pseudo-mechanisms)
-      Stackable pseudo-mechanisms
-      Other pseudo-mechanisms (e.g., SPNEGO, the GSS-API itself)
-
-
-   Although composed mechanisms may be made available for use by
-   GSS-APIv2 applications without any further extensions, use of
-   stackable pseudo-mechanisms can complicate mechanism negotiation;
-   additionally, discovery of mechanisms appropriate for use in one or
-   another context would require hard-coding information about them in
-   GSS-APIv2 applications.  Extensions to the GSS-APIv2 could facilitate
-   use of composite.
-
-
-   The mechanism attribute inquiry facilities, together with the
-   forllowing additional interfaces, provide for a complete interface to
-   mechanism composition and for managing the complexity of mechanism
-   negotiation:
-      GSS_Compose_oid()
-      GSS_Decompose_oid()
-      GSS_Release_oid()
-      GSS_Indicate_negotiable_mechs()
-      GSS_Negotiate_mechs()
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 11]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-10.  Naming Extensions
-
-
-   Some applications make use of exported names, as produced by
-   GSS_Export_name(), to create/manage/evaluate access control lists; we
-   call this name-based authorization.
-
-
-   Exported names typically encode names that are meant for display to
-   humans, not internal identifiers.
-
-
-   In practice this creates a number of problems.  E.g., the referential
-   integrity of such access control lists is hard to maintain as
-   principals are added, removed, renamed or old principal names reused.
-
-
-   Additionally, some mechanisms may lack a notion of a "canonical" name
-   for some or all of their principals.  Such mechanisms cannot be used
-   by applications that rely on name-based authorization.
-
-
-   <Describe the proposed extensions in this area.>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 12]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-11.  Additional Name Types
-
-
-   <Decribe domain-based names and the need for them.>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 13]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-12.  GSS_Pseudo_random()
-
-
-   <Decribe GSS_Pseudo_random() and the need for it.>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 14]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-13.  Channel Bindings Specifications
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 15]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-14.  Semantic and Miscallaneous Extensions
-
-
-   The GSS-APIv2 specifications say nothing about the thread-safety,
-   much less the fork-safety, of the GSS-API.  Thread-safety and
-   fork-safety are, after all, platform- and/or language-specific
-   matters.  But as support for multi-threading spreads the matter of
-   thread-safety cannot be avoided.  The matter of fork-safety is
-   specific to platforms that provide a "fork()" function, or similar.
-
-
-   <describe the GSS-APIv3's thread-safety requirements>
-
-
-   <reference the portability considerations section>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 16]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-15.  Portability Considerations
-
-
-   The potential for additional generic, mechanism-specific, language
-   binding-specific and, most importantly, semantic extensions to the
-   GSS-APIv3 may create application portability problems.  The mechanism
-   attribute inquiry facilities of the GSS-APIv3 and the
-   pseudo-mechanism OID for the GSS-API itself double as a run-time
-   facility for discovery of feature availability.  Run-time feature
-   discovery facilities, in turn, can be used at application build-time
-   as well by building small applications to display the available
-   features.
-
-
-   <...>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 17]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-16.  IANA Considerations
-
-
-   <Describe the namespace issues associated with future minor
-   extensions to the GSS-APIv3 and the IANA registries to be created to
-   cope with them.>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 18]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-17.  Security Considerations
-
-
-   <...>
-
-
-18  Normative
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-
-Author's Address
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004               [Page 19]
-Internet-Draft           Guide to the GSS-APIv3                July 2004
-
-
-
-Intellectual Property Statement
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams               Expires December 30, 2004               [Page 20] 
\ No newline at end of file
diff --git a/doc/standardisation/draft-williams-krb5-gssapi-domain-based-names-00.txt b/doc/standardisation/draft-williams-krb5-gssapi-domain-based-names-00.txt
deleted file mode 100644
index 51f154e0a..000000000
--- a/doc/standardisation/draft-williams-krb5-gssapi-domain-based-names-00.txt
+++ /dev/null
@@ -1,432 +0,0 @@
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: December 30, 2004                                     July 2004
-
-
-
-   GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS
-                               Mechanism
-          draft-williams-krb5-gssapi-domain-based-names-00.txt
-
-
-Status of this Memo
-
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-
-   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."
-
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-   This Internet-Draft will expire on December 30, 2004.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-
-Abstract
-
-
-   This document describes the mapping of GSS-API domainname-based
-   service principal names onto Kerberos V principal names.
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 1]
-Internet-Draft        Kerberos Domain Based Names              July 2004
-
-
-
-Table of Contents
-
-
-   1. Conventions used in this document  . . . . . . . . . . . . . . . 3
-   2. Domain-Based Names for the Kerberos V GSS-API Mechanism  . . . . 4
-   3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
-   4. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
-   5. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-      Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
-      Intellectual Property and Copyright Statements . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 2]
-Internet-Draft        Kerberos Domain Based Names              July 2004
-
-
-
-1.  Conventions used in this document
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 3]
-Internet-Draft        Kerberos Domain Based Names              July 2004
-
-
-
-2.  Domain-Based Names for the Kerberos V GSS-API Mechanism
-
-
-   In accordance with [DOMAIN-BASED-NAMES] this document provides the
-   mechanism-specific details needed to implement GSS-API [RFC2743]
-   domain-based service names with the Kerberos V GSS-API mechanism
-   [RFC1964].
-
-
-   GSS_C_NT_DOMAINBASED_SERVICE name are mapped to Kerberos V principal
-   names as follows:
-   o  the <service> name becomes the first (0th) component of the
-      Kerberos V principal name;
-   o  the <domain> name becomes the second component of the Kerberos V
-      principal name; if the <domain> name is missing in the GSS name
-      then a default domain name MUST be substituted (though no
-      mechanism for determining this default is given here; this is an
-      implementation-specific detail);
-   o  the <hostname>, if present, becomes the third component of the
-      Kerberos V principal name;
-   o  the realm of the resulting principal name is that which
-      corresponds to the domain name, treated as a hostname, or, if none
-      can be determined in this way, then the realm of the hostname, if
-      present, and, finally, if that is not possible, the default realm
-      for the GSS-API caller.
-
-
-   The same name canonicalization considerations and methods as used
-   elsewhere in the Kerberos V GSS-API mechanism [RFC1964] and Kerberos
-   V [RFC1510] in general apply here.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 4]
-Internet-Draft        Kerberos Domain Based Names              July 2004
-
-
-
-3.  Examples
-
-
-   o  "ldap@@ds1.example.tld" may map to "ldap/example.tld/
-      ds1.example.tld@EXAMPLE.TLD"
-   o  "ldap@example.tld@ds1.example.tld" may map to "ldap/example.tld/
-      ds1.example.tld@EXAMPLE.TLD"
-
-
-   o  "kadmin@@kdc1.example.tld" may map to "kadmin/example.tld/
-      kdc1.example.tld@EXAMPLE.TLD"
-   o  "kadmin@example.tld@kdc1.example.tld" may map to "kadmin/
-      example.tld/kdc1.example.tld@EXAMPLE.TLD"
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 5]
-Internet-Draft        Kerberos Domain Based Names              July 2004
-
-
-
-4.  Security Considerations
-
-
-   See [DOMAIN-BASED-NAMES].
-
-
-5  Normative
-
-
-   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
-              Authentication Service (V5)", RFC 1510, September 1993.
-
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
-              1964, June 1996.
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-
-
-Author's Address
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams               Expires December 30, 2004                [Page 6]
-Internet-Draft        Kerberos Domain Based Names              July 2004
-
-
-
-Intellectual Property Statement
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams               Expires December 30, 2004                [Page 7] 
\ No newline at end of file
diff --git a/doc/standardisation/draft-williams-krb5-gssapi-prf-00.txt b/doc/standardisation/draft-williams-krb5-gssapi-prf-00.txt
deleted file mode 100644
index ca588cd73..000000000
--- a/doc/standardisation/draft-williams-krb5-gssapi-prf-00.txt
+++ /dev/null
@@ -1,373 +0,0 @@
-NETWORK WORKING GROUP                                        N. Williams
-Internet-Draft                                                       Sun
-Expires: December 30, 2004                                    S. Hartman
-                                                                     MIT
-                                                               July 2004
-
-
-
-               A PRF for the Kerberos V GSS-API Mechanism
-                 draft-williams-krb5-gssapi-prf-00.txt
-
-
-Status of this Memo
-
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-
-   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."
-
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-   This Internet-Draft will expire on December 30, 2004.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-
-Abstract
-
-
-   This document defines the Pseudo-Random Function (PRF) for the
-   Kerberos V GSS-API mechanism, based on the PRF defined for the
-   Kerberos V cryptographic framework, for keying application protocols
-   given an established Kerberos V GSS-API security context.
-
-
-
-
-
-
-
-
-Williams & Hartman     Expires December 30, 2004                [Page 1]
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-
-Table of Contents
-
-
-   1. Conventions used in this document  . . . . . . . . . . . . . . . 3
-   2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
-   3. Security Considerations  . . . . . . . . . . . . . . . . . . . . 5
-   4. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
-      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
-      Intellectual Property and Copyright Statements . . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams & Hartman     Expires December 30, 2004                [Page 2]
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-
-1.  Conventions used in this document
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams & Hartman     Expires December 30, 2004                [Page 3]
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-
-2.  Introduction
-
-
-   The GSS-API PRF function for the Kerberos V mechanism shall be the
-   output of the enctype's PRF function keyed with the negotiated
-   session key of the security context (e.g., the acceptor's subkey) and
-   key usage X (TBD).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams & Hartman     Expires December 30, 2004                [Page 4]
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-
-3.  Security Considerations
-
-
-   Kerberos V enctypes' PRF functions should use a key derived from
-   contexts' session keys and should preserve the forward security
-   properties of the mechanisms' key exchanges.
-
-
-   Care should be taken in properly designing a mechanism's PRF
-   function.  Cryptographic hash functions which do not provide strong
-   collision resistance should not be used, except through HMAC.
-
-
-4  Normative
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-
-Authors' Addresses
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-   Sam Hartman
-   Massachussets Institute of Technology
-   ...
-   ..., MA  ...
-   US
-
-
-   EMail: hartmans@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-Williams & Hartman     Expires December 30, 2004                [Page 5]
-Internet-Draft       A PRF for the Kerberos V Mech             July 2004
-
-
-
-Intellectual Property Statement
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Williams & Hartman     Expires December 30, 2004                [Page 6] 
\ No newline at end of file
diff --git a/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-00.txt b/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-00.txt
deleted file mode 100644
index dd9023495..000000000
--- a/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-00.txt
+++ /dev/null
@@ -1,3585 +0,0 @@
-
-
-INTERNET-DRAFT                                                    Tom Yu
-draft-yu-krb-wg-kerberos-extensions-00.txt                           MIT
-Expires: 09 August 2004                                 09 February 2004
-
-        The Kerberos Network Authentication Service (Version 5)
-
-Status of This Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC 2026.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-
-      http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-
-      http://www.ietf.org/shadow.html
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This document describes version 5 of the Kerberos network
-   authentication protocol.  It describes changes to the protocol which
-   allow for extensions to be made to the protocol without creating
-   interoperability problems.
-
-   [ This document is a VERY rough draft.  Many sections are not yet
-   fully filled out.  The main purpose is to illustrate the beginnings
-   of a new document structure as a starting point. ]
-
-Key Words for Requirements
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
-   to be interpreted as described in RFC 2119.
-
-
-Yu                          Expires: Aug 2004                   [Page 1]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-Table of Contents
-
-   Status of This Memo .......................................  1
-   Copyright Notice ..........................................  1
-   Abstract ..................................................  1
-   Key Words for Requirements ................................  1
-   Table of Contents .........................................  2
-   1.  Introduction ..........................................  4
-   1.1.  Kerberos Protocol Overview ..........................  4
-   1.2.  Overview of Document ................................  5
-   2.  Extensibility .........................................  5
-   3.  Criticality ...........................................  6
-   4.  Use of ASN.1 ..........................................  6
-   4.1.  Module Header .......................................  6
-   4.2.  Top-Level Type ......................................  7
-   4.3.  Parameterized Types .................................  7
-   4.4.  Constraints .........................................  8
-   4.5.  New Types ...........................................  8
-   5.  Basic Types ...........................................  8
-   5.1.  Constrained Integer Types ...........................  8
-   5.2.  KerberosTime ........................................  9
-   5.3.  KerberosString ......................................  9
-   6.  Principals ............................................ 10
-   6.1.  Name Types .......................................... 10
-   6.2.  Principal Name Reuse ................................ 11
-   7.  Types Relating to Encryption .......................... 11
-   7.1.  EncryptedData ....................................... 11
-   7.2.  EncryptionKey ....................................... 13
-   7.3.  Checksums ........................................... 13
-   7.3.1.  ChecksumOf ........................................ 14
-   7.3.2.  Signed ............................................ 15
-   8.  Tickets ............................................... 15
-   8.1.  Timestamps .......................................... 16
-   8.2.  Ticket Flags ........................................ 16
-   8.2.1.  Flags Relating to Initial Ticket Acquisition ...... 17
-   8.2.2.  Invalid Tickets ................................... 17
-   8.2.3.  OK as Delegate .................................... 18
-   8.3.  Renewable Tickets ................................... 18
-   8.4.  Postdated Tickets ................................... 19
-   8.5.  Proxiable and Proxy Tickets ......................... 20
-   8.6.  Forwardable Tickets ................................. 21
-   8.7.  Transited Realms .................................... 21
-   8.8.  Authorization Data .................................. 21
-   8.9.  Encrypted Part of Ticket ............................ 21
-   8.10.  Cleartext Part of Ticket ........................... 22
-   9.  Credential Acquisition ................................ 23
-   9.1.  KDC-REQ ............................................. 24
-   9.2.  PA-DATA ............................................. 26
-   9.3.  KDC-REQ Processing .................................. 26
-   9.3.1.  Handling Replays .................................. 26
-   9.3.2.  Request Validation ................................ 26
-
-Yu                          Expires: Aug 2004                   [Page 2]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   9.3.2.1.  AS-REQ Authentication ........................... 27
-   9.3.2.2.  TGS-REQ Authentication .......................... 27
-   9.3.2.3.  Principal Validation ............................ 27
-   9.3.3.  Timestamp Handling ................................ 27
-   9.3.3.1.  AS-REQ Timestamp Processing ..................... 28
-   9.3.3.2.  TGS-REQ Timestamp Processing .................... 29
-   9.3.4.  Key Selection ..................................... 29
-   9.3.5.  Checking For Revoked Tickets ...................... 30
-   9.4.  Reply Validation .................................... 30
-   10.  Application Authentication ........................... 30
-   11.  Session Key Use ...................................... 30
-   11.1.  KRB-SAFE ........................................... 30
-   11.2.  KRB-PRIV ........................................... 30
-   11.3.  KRB-CRED ........................................... 30
-   12.  Security Considerations .............................. 30
-   12.1.  Time Synchronization ............................... 30
-   12.2.  Replays ............................................ 30
-   12.3.  Principal Name Reuse ............................... 30
-   12.4.  Password Guessing .................................. 30
-   12.5.  Forward Secrecy .................................... 30
-   12.6.  Authorization ...................................... 31
-   12.7.  Login Authentication ............................... 31
-   Appendices ................................................ 31
-   A.  ASN.1 Module (Normative) .............................. 31
-   B.  Kerberos and Character Encodings (Informative) ........ 60
-   C.  Kerberos History (Informative) ........................ 62
-   Normative References ...................................... 62
-   Informative References .................................... 63
-   Acknowledgments ........................................... 63
-   Author's Address .......................................... 63
-   Full Copyright Statement .................................. 63
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                   [Page 3]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-1.  Introduction
-
-   The Kerberos network authentication protocol is a trusted third-party
-   protocol utilizing symmetric-key cryptography.  It assumes that all
-   communications between parties in the protocol may be arbitrarily
-   tampered with or monitored, and that the security of the overall
-   system depends only on the effectiveness of the cryptographic
-   techniques and the secrecy of the keys used.  The protocol
-   authenticates an application client's identity to an application
-   server, and likewise authenticates the application server's identity
-   to the application client.  These assurances are made possible by the
-   client and the server sharing secrets with the trusted third party:
-   the Kerberos server, also known as the Key Distribution Center (KDC).
-   In addition, the protocol establishes an ephemeral shared secret (the
-   session key) between the client and the server, allowing the
-   protection of further communications between them.
-
-1.1.  Kerberos Protocol Overview
-
-   Kerberos comprises three main sub-protocols: credentials acquisition,
-   application authentication, and session key usage.  A client acquires
-   credentials by asking the for KDC a credential for a service; the KDC
-   issues the credential, consisting of a ticket and a session key.  The
-   ticket, containing the client's identity, timestamps, expiration
-   time, and a session key, is a encrypted in a key known to the
-   application server.  The KDC encrypts the credential using a key
-   known to the client, and transmits the credential to the client.
-
-   There are two means of requesting credentials: the Authentication
-   Service (AS) exchange, and the Ticket-Granting Service (TGS)
-   exchange.  The AS exchange typically involves a client using a
-   password-derived key to decrypt the response.  The TGS exchange
-   involves the KDC behaving as an application, which the client
-   authenticates to using a Ticket-Granting Ticket (TGT).  The client
-   usually obtains the TGT by using the AS exchange.
-
-   Application authentication consists of the client establishing the
-   session key with the application server by transmitting the ticket to
-   the application server, along with an authenticator.  The
-   authenticator contains a timestamp and additional data encrypted
-   using the ticket's session key.  The application server decrypts the
-   ticket, extracting the session key.  The application server then uses
-   the session key to decrypt the authenticator.  Upon successful
-   decryption of the authenticator, the application server knows that
-   the data in the authenticator were sent by the client named in the
-   associated ticket.  Additionally, since authenticators expire more
-   quickly than tickets, the application server has some assurance that
-   the transaction is not a replay.  The application server may send an
-   encrypted acknowledgment to the client, verifying its identity to the
-   client.
-
-
-Yu                          Expires: Aug 2004                   [Page 4]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   Once application authentication has occurred, the client and server
-   may use the established session key to protect further traffic.  This
-   protection may consist of protection of integrity only, or of
-   protection of confidentiality and integrity.  Additional measures
-   exist for a client to forward credentials to a server.
-
-   The entire scheme depends on loosely synchronized clocks.
-   Synchronization of the clock on the KDC with the application server
-   clock allows the application server to accurately determine whether a
-   credential is expired.  Likewise, synchronization of the clock on the
-   client with the application server clock prevents replay attacks
-   utilizing the same credential.  Careful design of the application
-   protocol may allow replay prevention without requiring client-server
-   clock synchronization.
-
-   Following the establishment of a session key between the application
-   client and the application server, the Kerberos protocol provides
-   messages that use the session key to protect the integrity or
-   confidentiality of communications between the client and the server.
-   Additionally, the client may forward credentials to the application
-   server.
-
-   The credentials acquisition protocol takes place over specific,
-   defined transports (UDP and TCP).  Application protocols define which
-   transport to use for the session key establishment protocol and for
-   messages using the session key; the application may choose to perform
-   its own encapsulation of the Kerberos messages, for example.
-
-1.2.  Overview of Document
-
-   The remainder of this document begins by describing the general
-   frameworks for protocol extensibility, including whether to interpret
-   unknown extensions as critical.  It then defines the protocol
-   messages and exchanges.
-
-   The definition of the Kerberos protocol uses Abstract Syntax Notation
-   One (ASN.1) [X680], which specifies notation for describing the
-   abstract content of protocol messages.  This document defines a
-   number of base types using ASN.1; these base types subsequently
-   appear in multiple types which define actual protocol messages.
-   Definitions of principal names and of tickets, which are central to
-   the protocol, also appear preceding the protocol message definitions.
-
-2.  Extensibility
-
-   As originally defined in [RFC1510], the Kerberos protocol does not
-   readily allow for backwards-compatible extensions to the protocol.
-   Various proposals to extend the Kerberos protocol have appeared since
-   RFC 1510, many of them creating problems for backwards compatibility.
-   This document adopts the technique of creating new extensible types
-   which encode to messages which are very similar to RFC 1510 messages
-
-Yu                          Expires: Aug 2004                   [Page 5]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   on the wire.  This similarity allows implementors to use shared code
-   paths for encoding and decoding both new and old messages.
-
-   The protocol defined in RFC 1510 already contains some elements
-   allowing for limited backwards-compatible extensions to the protocol.
-   Most of these elements consist of "typed holes"; these are octet
-   strings whose contents have types defined by an assigned number.
-   This document adds a number of typed holes to types which have
-   previously lacked typed holes.  This document also describes
-   procedures for the IETF to use the extensibility model of ASN.1 make
-   further backwards-compatible extensions of the Kerberos protocol, if
-   typed holes prove inadequate for some desired extension.
-
-3.  Criticality
-
-   In general, implementations SHOULD treat unknown extension, flags,
-   etc. as non-critical; i.e., they should ignore them when they do not
-   understand them.  Exceptions are clearly marked.  An implementation
-   SHOULD NOT reject a request merely because it does not understand
-   some element of the request.  As a related consequence,
-   implementations SHOULD handle talking to other implementations which
-   do not implement some requested options.  This may require designers
-   of extensions or options to provide means detect whether extensions
-   or options are rejected, or whether such extensions or options are
-   merely not understood, or (perhaps maliciously) deleted in transit.
-
-4.  Use of ASN.1
-
-   Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
-   Even though ASN.1 theoretically allows the description of protocol
-   messages to be independent of the encoding rules used to encode the
-   messages, Kerberos messages MUST be encoded with DER.  Subtleties in
-   the semantics of the notation, such as whether tags carry any
-   semantic content to the application, may cause the use of other ASN.1
-   encoding rules to be problematic.
-
-   Implementors not using existing ASN.1 compilers or support libraries
-   are cautioned to thoroughly read and understand the actual ASN.1
-   specification to ensure correct implementation behavior.  There is
-   more complexity in the notation than is immediately obvious, and some
-   tutorials and guides to ASN.1 are misleading or erroneous.
-
-4.1.  Module Header
-
-   The type definitions in this section assume an ASN.1 module
-   definition of the following form:
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                   [Page 6]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      KerberosV5Spec3 {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2) modules(4) krb5spec3(4)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      -- Rest of definitions here
-
-      END
-
-   This specifies that the tagging context for the module will be
-   explicit and that automatic tagging is not done.
-
-   Some other publications [RFC1510] [RFC1964] erroneously specify an
-   object identifier (OID) having an incorrect value of "5" for the
-   "dod" component of the OID.  In the case of RFC 1964, use of the
-   "correct" OID value would result in a change in the wire protocol;
-   therefore, the RFC 1964 OID remains unchanged for now.
-
-4.2.  Top-Level Type
-
-   The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
-   Data Units or PDUs) which an application may directly reference.
-   Applications SHOULD NOT transmit any types other than those which are
-   alternatives of the KRB-PDU CHOICE.
-
-      -- top-level type
-      --
-      -- Applications should not directly reference any types
-      -- other than KRB-PDU and its component types.
-      --
-      KRB-PDU         ::= CHOICE {
-          ticket      Ticket,
-          as-req      AS-REQ,
-          as-rep      AS-REP,
-          tgs-req     TGS-REQ,
-          tgs-rep     TGS-REP,
-          ap-req      AP-REQ,
-          ap-rep      AP-REP,
-          krb-safe    KRB-SAFE,
-          krb-priv    KRB-PRIV,
-          krb-cred    KRB-CRED,
-          tgt-req     TGT-REQ,
-          krb-error   KRB-ERROR,
-          ...
-      }
-
-
-4.3.  Parameterized Types
-
-   This document uses ASN.1 parameterized types [X683] to make
-   definitions of types more readable.  For some types, some or all of
-
-Yu                          Expires: Aug 2004                   [Page 7]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   the parameters are advisory, i.e., they are not encoded in any form
-   for transmission in a protocol message.  These advisory parameters
-   can describe implementation behavior associated with the type.
-
-4.4.  Constraints
-
-   This document uses ASN.1 constraints, including the
-   "UserDefinedConstraint" syntax [X682].  Some constraints can be
-   handled automatically by tools that can parse them.  Uses of the
-   "UserDefinedConstraint" syntax (the "CONSTRAINED BY" syntax) will
-   typically need to have behavior manually coded; these uses provide a
-   formalized way of conveying intended implementation behavior.
-
-4.5.  New Types
-
-   This document defines a number of new ASN.1 types.  The names of
-   these types will typically have a suffix like "Ext", indicating that
-   the types are intended to support extensibility.  Types original to
-   RFC 1510 have been renamed to have a suffix like "1510".  The "Ext"
-   and "1510" types often contain a number of common elements; these
-   common elements have a suffix like "Common".  The "1510" types have
-   various ASN.1 constraints applied to them; the constraints limit the
-   possible values of the "1510" types to those permitted by RFC 1510 or
-   by [KCLAR].  The "Ext" types may have different constraints,
-   typically to force string values to be sent as UTF-8.
-
-5.  Basic Types
-
-   Certain ASN.1 types in Kerberos appear in numerous other types.
-
-5.1.  Constrained Integer Types
-
-   In [RFC1510], many types contained references to the unconstrained
-   INTEGER type.  Since an unconstrained INTEGER may contain any
-   possible abstract integer value, most of the unconstrained references
-   to INTEGER in [RFC1510] have been constrained to 32 bits or smaller.
-
-      -- signed values representable in 32 bits
-      --
-      -- These are often used as assigned numbers for various things.
-      Int32           ::= INTEGER (-2147483648..2147483647)
-
-      -- unsigned 32 bit values
-      UInt32          ::= INTEGER (0..4294967295)
-
-   The "Int32" type often contains an assigned number identifying the
-   type of a protocol element.  Unless otherwise stated, non-negative
-   values are registered, and negative values are available for local
-   use.
-
-
-
-Yu                          Expires: Aug 2004                   [Page 8]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      -- microseconds
-      Microseconds    ::= INTEGER (0..999999)
-
-
-      -- sequence numbers
-      --
-      -- We may want to increase this to 2**64 and define a UInt64
-      -- type.
-      SeqNum          ::= UInt32
-
-
-      -- nonces
-      --
-      -- Likewise, we may want to make this UInt64.
-      Nonce           ::= UInt32
-
-   While these types have different abstract types from their
-   equivalents in [RFC1510], their DER encodings remain identical.
-
-5.2.  KerberosTime
-
-      -- must not have fractional seconds
-      KerberosTime    ::= GeneralizedTime
-
-   The timestamps used in Kerberos are encoded as GeneralizedTimes. A
-   KerberosTime value MUST NOT include any fractional portions of the
-   seconds.  As required by the DER, it further MUST NOT include any
-   separators, and it specifies the UTC time zone (Z). Example: The only
-   valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
-   November 1985 is "19851106210627Z".
-
-5.3.  KerberosString
-
-      -- used for names and for error messages
-      KerberosString  ::= CHOICE {
-          ia5         GeneralString (IA5String),
-          utf8        UTF8String,
-          ...         -- no extension may be sent
-                      -- to an rfc1510 implementation --
-      }
-
-   The KerberosString type is used for strings in various places in the
-   Kerberos protocol.  For compatibility with RFC 1510, GeneralString
-   values constrained to IA5String (US-ASCII) are permitted in messages
-   exchanged with RFC 1510 implementations.  The new protocol messages
-   contain strings encoded as UTF-8.  KerberosString values are present
-   in principal names and in error messages.  Control characters SHOULD
-   NOT be used in principal names, and used with caution in error
-   messages.
-
-
-
-Yu                          Expires: Aug 2004                   [Page 9]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   For detailed background regarding the history of character string use
-   in Kerberos, as well as discussion of some compatibility issues, see
-   Appendix B.
-
-6.  Principals
-
-   Principals are participants in the Kerberos protocol.  A "realm"
-   consists of principals in one administrative domain, served by one
-   KDC (or one replicated set of KDCs).  Each principal name has an
-   arbitrary number of components, though typical principal names will
-   only have one or two components.  A principal name is meant to be
-   readable by and meaningful to humans, especially in a realm lacking a
-   centrally adminstered authorization infrastructure.
-
-      Realm           ::= KerberosString
-
-      PrincipalName   ::= SEQUENCE {
-          name-type   [0] NameType,
-          -- May have zero elements, or individual elements may be
-          -- zero-length, but this is not recommended.
-          name-string [1] SEQUENCE OF KerberosString
-      }
-
-      -- assigned numbers for name types (used in principal names)
-      NameType        ::= Int32
-
-
-   Kerberos realm names are KerberosStrings.  Realms MUST NOT contain a
-   character with the code 0 (the US-ASCII NUL).  Most realms will
-   usually consist of several components separated by periods (.), in
-   the style of Internet Domain Names, or separated by slashes (/) in
-   the style of X.500 names.
-
-   name-type
-        Specifies the type of name that follows.  The name-type SHOULD
-        be treated as a hint. Ignoring the name type, no two names can
-        be the same (i.e., at least one of the components, or the realm,
-        must be different).
-
-   name-string
-        Encodes a sequence of components that form a name, each
-        component encoded as a KerberosString.  Taken together, a
-        PrincipalName and a Realm form a principal identifier.  Most
-        PrincipalNames will have only a few components (typically one or
-        two).
-
-6.1.  Name Types
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 10]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      -- Name type not known
-      nt-unknown              NameType ::= 0
-      -- Just the name of the principal as in DCE, or for users
-      nt-principal            NameType ::= 1
-      -- Service and other unique instance (krbtgt)
-      nt-srv-inst             NameType ::= 2
-      -- Service with host name as instance (telnet, rcommands)
-      nt-srv-hst              NameType ::= 3
-      -- Service with host as remaining components
-      nt-srv-xhst             NameType ::= 4
-      -- Unique ID
-      nt-uid                  NameType ::= 5
-      -- Encoded X.509 Distingished name [RFC 2253]
-      nt-x500-principal       NameType ::= 6
-      -- Name in form of SMTP email name (e.g. user@foo.com)
-      nt-smtp-name            NameType ::= 7
-      -- Enterprise name - may be mapped to principal name
-      nt-enterprise           NameType ::= 10
-
-
-6.2.  Principal Name Reuse
-
-   Realm administrators SHOULD use extreme caution when considering
-   reusing a principal name.  A service administrator might explicitly
-   enter principal names into a local access control list (ACL) for the
-   service.  If such local ACLs exist independently of a centrally
-   administered authorization infrastructure, realm administrators
-   SHOULD NOT reuse principal names until confirming that all extant ACL
-   entries referencing that principal name have been updated.  Failure
-   to perform this check can result in a security vulnerability, as a
-   new principal can inadvertently inherit unauthorized privileges upon
-   receiving a reused principal name.  An organization whose Kerberos-
-   authenticated services all use a centrally-adminstered authorization
-   infrastructure may not need to take these precautions regarding
-   principal name reuse.
-
-7.  Types Relating to Encryption
-
-   Many Kerberos protocol messages contain encryptions of various data
-   types.  Kerberos protocol messages also contain checksums
-   (signatures) of various types.
-
-7.1.  EncryptedData
-
-   The "EncryptedData" type contains the encryption of another data
-   type.  The recipient uses fields within EncryptedData to determine
-   which key to use for decryption.
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 11]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      -- "Type" specifies which ASN.1 type is encrypted to the
-      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
-      -- keys of which one key may be used to encrypt the data.
-      -- "KeyUsages" specifies a set of key usages, one of which may
-      -- be used to encrypt.
-      --
-      -- None of the parameters is transmitted over the wire.
-      EncryptedData { Type, KeyToUse:Keys, KeyUsage:KeyUsages } ::=
-      SEQUENCE {
-          etype       [0] EType,
-          kvno        [1] UInt32 OPTIONAL,
-          cipher      [2] OCTET STRING (CONSTRAINED BY {
-              -- must be encryption of --
-              OCTET STRING (CONTAINING Type),
-              -- with one of the keys -- KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          }),
-          ...
-      }
-
-      -- Assigned numbers denoting encryption mechanisms.
-      EType ::= Int32
-
-      -- Assigned numbers denoting key usages.
-      KeyUsage ::= UInt32
-
-
-   EType
-        Integer type for assigned numbers for encryption algorithms.
-        Defined in [KCRYPTO]
-
-   KeyUsage
-        Integer type for assigned numbers for key usages.  Key usage
-        values are inputs to the encryption and decryption functions
-        described in [KCRYPTO].
-
-   Type
-        Advisory parameter indicating the ASN.1 type whose DER encoding
-        is the plaintext encrypted into the EncryptedData.
-
-   Keys
-        Advisory parameter indicating which key to use to perform the
-        encryption.  If "Keys" indicate multiple "KeyToUse" values, the
-        detailed description of the containing message will indicate
-        which key to use under which conditions.
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 12]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-           -- KeyToUse identifies which key is to be used to encrypt or
-           -- sign a given value.
-           --
-           -- Values of KeyToUse are never actually transmitted over the
-           -- wire, or even used directly by the implementation in any
-           -- way, as key usages are; it exists primarily to identify
-           -- which key gets used for what purpose.  Thus, the specific
-           -- numeric values associated with this type are irrelevant.
-           KeyToUse        ::= ENUMERATED {
-               -- unspecified
-               key-unspecified,
-               -- server long term key
-               key-server,
-               -- client long term key
-               key-client,
-               -- key selected by KDC for encryption of a KDC-REP
-               key-kdc-rep,
-               -- session key from ticket
-               key-session,
-               -- subsession key negotiated via AP-REQ/AP-REP
-               key-subsession,
-               ...
-           }
-
-
-   KeyUsages
-        Advisory parameter indicating which "KeyUsage" value is used to
-        encrypt.  If "KeyUsages" indicates multiple "KeyUsage" values,
-        the detailed description of the containing message will indicate
-        which key usage to use under which conditions.
-
-7.2.  EncryptionKey
-
-   The "EncryptionKey" type holds an encryption key.
-
-      EncryptionKey   ::= SEQUENCE {
-          keytype     [0] EType,
-          keyvalue    [1] OCTET STRING
-      }
-
-
-   keytype
-        This "EType" identifies the encryption algorithm, described in
-        [KCRYPTO].
-
-   keyvalue
-        Contains the actual key.
-
-7.3.  Checksums
-
-
-
-Yu                          Expires: Aug 2004                  [Page 13]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   Several types contain checksums (actually signatures) of data.
-
-      CksumType       ::= Int32
-
-      -- The parameters specify which key to use to produce the
-      -- signature, as well as which key usage to use.  The
-      -- parameters are not actually sent over the wire.
-      Checksum { KeyToUse:Keys, KeyUsage:KeyUsages } ::= SEQUENCE {
-          cksumtype   [0] CksumType,
-          checksum    [1] OCTET STRING (CONSTRAINED BY {
-              -- signed using one of the keys --
-              KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          })
-      }
-
-
-   CksumType
-        Integer type for assigned numbers for signature algorithms.
-        Defined in [KCRYPTO]
-
-   Keys
-        As in EncryptedData
-
-   KeyUsages
-        As in EncryptedData
-
-   cksumtype
-        Signature algorithm used to produce the signature.
-
-   checksum
-        The actual checksum.
-
-7.3.1.  ChecksumOf
-
-   ChecksumOf is like "Checksum", but specifies which type is signed.
-
-      -- a Checksum that must contain the checksum of a particular type
-      ChecksumOf { Type, KeyToUse:Keys, KeyUsage:KeyUsages } ::=
-      Checksum { Keys, KeyUsages }
-      (WITH COMPONENTS {
-          ...,
-          checksum (CONSTRAINED BY {
-              -- must be checksum of --
-              OCTET STRING (CONTAINING Type)
-          })
-      })
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 14]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   Type
-        Indicates the ASN.1 type whose DER encoding is signed.
-
-7.3.2.  Signed
-
-   Signed is like "ChecksumOf", but contains an actual instance of the
-   type being signed in addition to the signature.
-
-      -- parameterized type for wrapping authenticated plaintext
-      Signed { InnerType, KeyToUse:Keys, KeyUsage:KeyUsages } ::=
-      SEQUENCE {
-          cksum       [0] ChecksumOf
-                              { InnerType, Keys, KeyUsages } OPTIONAL,
-          inner       [1] InnerType,
-          ...
-      }
-
-
-8.  Tickets
-
-   The important fields of a ticket are in the encrypted part.  The
-   components in common between the RFC 1510 and the extensible versions
-   are
-
-      EncTicketPartCommon ::= SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] Realm,
-          cname               [3] PrincipalName,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-   crealm
-        This field contains the client's realm.
-
-   cname
-        This field contains the client's name.
-
-   caddr
-        This field lists the network addresses (if absent, all addresses
-        are permitted) from which the ticket is valid.
-
-
-
-Yu                          Expires: Aug 2004                  [Page 15]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   Descriptions of the other fields appear in the following sections.
-
-8.1.  Timestamps
-
-   Three of the ticket timestamps may be requested from the KDC.  The
-   timestamps may differ from those requested, depending on site policy.
-
-   authtime
-        The time at which the client authenticated, as recorded by the
-        KDC.
-
-   starttime
-        The earliest time when the ticket is valid.  If not present, the
-        ticket is valid starting at the authtime.  This is requested as
-        the "from" field of KDC-REQ-BODY-COMMON.
-
-   endtime
-        This time is requested in the "till" field of KDC-REQ-BODY-
-        COMMON.  Contains the time after which the ticket will not be
-        honored (its expiration time).  Note that individual services
-        MAY place their own limits on the life of a ticket and MAY
-        reject tickets which have not yet expired.  As such, this is
-        really an upper bound on the expiration time for the ticket.
-
-   renew-till
-        This time is requested in the "rtime" field of KDC-REQ-BODY-
-        COMMON.  It is only present in tickets that have the "renewable"
-        flag set in the flags field.  It indicates the maximum endtime
-        that may be included in a renewal.  It can be thought of as the
-        absolute expiration time for the ticket, including all renewals.
-
-8.2.  Ticket Flags
-
-   A number of flags may be set in the ticket, further defining some of
-   its capabilities.  Some of these flags map to flags in a KDC request.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 16]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
-
-      TicketFlagsBits ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          may-postdate        (5),
-          postdated           (6),
-          invalid             (7),
-          renewable           (8),
-          initial             (9),
-          pre-authent         (10),
-          hw-authent          (11),
-          transited-policy-checked (12),
-          ok-as-delegate      (13),
-          anonymous           (14),
-          cksummed-ticket     (15)
-      }
-
-
-8.2.1.  Flags Relating to Initial Ticket Acquisition
-
-   [ adapted KCLAR 2.1. ]
-
-   Several flags indicate the details of how the initial ticket was
-   acquired.
-
-   initial
-        The "initial" flag indicates that a ticket was issued using the
-        AS protocol, rather than issued based on a ticket-granting
-        ticket.  Application servers (e.g., a password-changing program)
-        requiring a client's definite knowledge of its secret keycan
-        insist that this flag be set in any tickets they accept, and
-        thus be assured that the client's key was recently presented to
-        the application client.
-
-   pre-authent
-        The "pre-authent" flag indicates that some sort of pre-
-        authentication was used during the AS exchange.
-
-   hw-authent
-        The "hw-authent" flag indicates that some sort of hardware-based
-        pre-authentication occurred during the AS exchange.
-
-   Both the "pre-authent" and the "hw-authent" flags may be present with
-   or without the "initial" flag; such tickets with the "initial" flag
-   clear are ones which are derived from initial tickets with the "pre-
-   authent" or "hw-authent" flags set.
-
-
-Yu                          Expires: Aug 2004                  [Page 17]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-8.2.2.  Invalid Tickets
-
-   [ KCLAR 2.2. ]
-
-   The "invalid" flag indicates that a ticket is invalid.  Application
-   servers MUST reject tickets which have this flag set.  A postdated
-   ticket will be issued in this form.  Invalid tickets MUST be
-   validated by the KDC before use, by presenting them to the KDC in a
-   TGS request with the "validate" option specified.  The KDC will only
-   validate tickets after their starttime has passed.  The validation is
-   required so that postdated tickets which have been stolen before
-   their starttime can be rendered permanently invalid (through a hot-
-   list mechanism -- see Section 9.3.5).
-
-8.2.3.  OK as Delegate
-
-   [ KCLAR 2.8. ]
-
-   For some applications a client may need to delegate authority to a
-   server to act on its behalf in contacting other services.  This
-   requires that the client forward credentials to an intermediate
-   server.  The ability for a client to obtain a service ticket to a
-   server conveys no information to the client about whether the server
-   should be trusted to accept delegated credentials.  The "ok-as-
-   delegate" flag provides a way for a KDC to communicate local realm
-   policy to a client regarding whether an intermediate server is
-   trusted to accept such credentials.
-
-   The copy of the ticket flags visible to the client may have the "ok-
-   as-delegate" flag set to indicate to the client that the server
-   specified in the ticket has been determined by policy of the realm to
-   be a suitable recipient of delegation.  A client can use the presence
-   of this flag to help it make a decision whether to delegate
-   credentials (either grant a proxy or a forwarded ticket-granting
-   ticket) to this server.  It is acceptable to ignore the value of this
-   flag.  When setting this flag, an administrator should consider the
-   security and placement of the server on which the service will run,
-   as well as whether the service requires the use of delegated
-   credentials.
-
-8.3.  Renewable Tickets
-
-   [ adapted KCLAR 2.3. ]
-
-   Renewable tickets can be used to mitigate the consequences of ticket
-   theft.  Applications may desire to hold tickets which can be valid
-   for long periods of time.  However, this can expose their credentials
-   to potential theft for equally long periods, and those stolen
-   credentials would be valid until the expiration time of the
-   ticket(s).  Simply using short-lived tickets and obtaining new ones
-   periodically would require the client to have long-term access to its
-
-Yu                          Expires: Aug 2004                  [Page 18]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   secret key, an even greater risk.
-
-   Renewable tickets have two "expiration times": the first is when the
-   current instance of the ticket expires, and the second is the latest
-   permissible value for an individual expiration time.  An application
-   client must periodically (i.e., before it expires) present a
-   renewable ticket to the KDC, with the "renew" option set in the KDC
-   request.  The KDC will issue a new ticket with a new session key and
-   a later expiration time.  All other fields of the ticket are left
-   unmodified by the renewal process.  When the latest permissible
-   expiration time arrives, the ticket expires permanently.  At each
-   renewal, the KDC MAY consult a hot-list to determine if the ticket
-   had been reported stolen since its last renewal; it will refuse to
-   renew such stolen tickets, and thus the usable lifetime of stolen
-   tickets is reduced.
-
-   The "renewable" flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can usually be ignored by application
-   servers.  However, some particularly careful application servers MAY
-   disallow renewable tickets.
-
-   If a renewable ticket is not renewed by its expiration time, the KDC
-   will not renew the ticket.  The "renewable" flag is clear by default,
-   but a client can request it be set by setting the "renewable" option
-   in the AS-REQ message. If it is set, then the "renew-till" field in
-   the ticket contains the time after which the ticket may not be
-   renewed.
-
-8.4.  Postdated Tickets
-
-   [ KCLAR 2.4. ]
-
-   Applications may occasionally need to obtain tickets for use much
-   later, e.g., a batch submission system would need tickets to be valid
-   at the time the batch job is serviced.  However, it is dangerous to
-   hold valid tickets in a batch queue, since they will be on-line
-   longer and more prone to theft.  Postdated tickets provide a way to
-   obtain these tickets from the KDC at job submission time, but to
-   leave them "dormant" until they are activated and validated by a
-   further request of the KDC. If a ticket theft were reported in the
-   interim, the KDC would refuse to validate the ticket, and the thief
-   would be foiled.
-
-   The "may-postdate" flag in a ticket is normally only interpreted by
-   the TGS. It can be ignored by application servers.  This flag MUST be
-   set in a ticket-granting ticket in order for the KDC to issue a
-   postdated ticket based on the presented ticket.  It is reset by
-   default; it MAY be requested by a client by setting the "allow-
-   postdate" option in the AS-REQ [?also TGS-REQ?] message.  This flag
-   does not allow a client to obtain a postdated ticket-granting ticket;
-   postdated ticket-granting tickets can only by obtained by requesting
-
-Yu                          Expires: Aug 2004                  [Page 19]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   the postdating in the AS-REQ message.  The life (endtime-starttime)
-   of a postdated ticket will be the remaining life of the ticket-
-   granting ticket at the time of the request, unless the "renewable"
-   option is also set, in which case it can be the full life (endtime-
-   starttime) of the ticket-granting ticket. The KDC MAY limit how far
-   in the future a ticket may be postdated.
-
-   The "postdated" flag indicates that a ticket has been postdated. The
-   application server can check the authtime field in the ticket to see
-   when the original authentication occurred.  Some services MAY choose
-   to reject postdated tickets, or they may only accept them within a
-   certain period after the original authentication. When the KDC issues
-   a "postdated" ticket, it will also be marked as "invalid", so that
-   the application client MUST present the ticket to the KDC for
-   validation before use.
-
-8.5.  Proxiable and Proxy Tickets
-
-   [ KCLAR 2.5. ]
-
-   At times it may be necessary for a principal to allow a service to
-   perform an operation on its behalf.  The service must be able to take
-   on the identity of the client, but only for a particular purpose. A
-   principal can allow a service to take on the principal's identity for
-   a particular purpose by granting it a proxy.
-
-   The process of granting a proxy using the "proxy" and "proxiable"
-   flags is used to provide credentials for use with specific services.
-   Though conceptually also a proxy, users wishing to delegate their
-   identity in a form usable for all purposes MUST use the ticket
-   forwarding mechanism described in the next section to forward a
-   ticket-granting ticket.
-
-   The "proxiable" flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can be ignored by application servers.
-   When set, this flag tells the ticket-granting server that it is OK to
-   issue a new ticket (but not a ticket-granting ticket) with a
-   different network address based on this ticket.  This flag is set if
-   requested by the client on initial authentication.  By default, the
-   client will request that it be set when requesting a ticket-granting
-   ticket, and reset when requesting any other ticket.
-
-   This flag allows a client to pass a proxy to a server to perform a
-   remote request on its behalf (e.g. a print service client can give
-   the print server a proxy to access the client's files on a particular
-   file server in order to satisfy a print request).
-
-   In order to complicate the use of stolen credentials, Kerberos
-   tickets may contain a set of network addresses from which they are
-   valid. When granting a proxy, the client MUST specify the new network
-   address from which the proxy is to be used, or indicate that the
-
-Yu                          Expires: Aug 2004                  [Page 20]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   proxy is to be issued for use from any address.
-
-   The "proxy" flag is set in a ticket by the TGS when it issues a proxy
-   ticket.  Application servers MAY check this flag and at their option
-   they MAY require additional authentication from the agent presenting
-   the proxy in order to provide an audit trail.
-
-8.6.  Forwardable Tickets
-
-   [ KCLAR 2.6. ]
-
-8.7.  Transited Realms
-
-   [ KCLAR 2.7., plus new stuff ]
-
-8.8.  Authorization Data
-
-8.9.  Encrypted Part of Ticket
-
-   The complete definition of the encrypted part is
-
-      -- Encrypted part of ticket
-      EncTicketPart ::= CHOICE {
-          rfc1510     [APPLICATION 3] EncTicketPart1510,
-          ext         [APPLICATION 5] EncTicketPartExt
-      }
-
-
-      EncTicketPart1510 ::= SEQUENCE {
-          -- effectively drops the extension marker
-          COMPONENTS OF EncTicketPartCommon
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          crealm (WITH COMPONENTS { ia5 PRESENT }),
-          cname (WITH COMPONENTS {
-              ...,
-              name-string (WITH COMPONENT
-                           (WITH COMPONENTS { ia5 PRESENT }))
-          })
-      })
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 21]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      EncTicketPartExt ::= EncTicketPartCommon
-      (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          crealm (WITH COMPONENTS { ia5 ABSENT }),
-          cname (WITH COMPONENTS {
-              ...,
-              name-string (WITH COMPONENT
-                           (WITH COMPONENTS { ia5 ABSENT }))
-          }),
-          -- explicitly constrain caddr to be non-empty if present
-          caddr (SIZE (1..MAX)),
-          -- explicitly constrain authorization-data to be non-empty
-          -- if present
-          authorization-data (SIZE (1..MAX))
-      })
-
-
-8.10.  Cleartext Part of Ticket
-
-      Ticket          ::= CHOICE {
-          rfc1510     [APPLICATION 1] Ticket1510,
-          ext         [APPLICATION 4] Signed {
-              TicketExt, { key-server }, { ku-Ticket-cksum }
-          }
-      }
-
-
-      -- takes a parameter specifying which type gets encrypted
-      TicketCommon { EncPart } ::= SEQUENCE {
-          tkt-vno     [0] INTEGER (5),
-          realm       [1] Realm,
-          sname       [2] PrincipalName,
-          enc-part    [3] EncryptedData {
-              EncPart, { key-server }, { ku-Ticket }
-          },
-          extensions          [4] TicketExtensions OPTIONAL,
-          ...
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 22]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      Ticket1510 ::= SEQUENCE {
-          -- "COMPONENTS OF" drops the extension marker from
-          -- TicketCommon
-          COMPONENTS OF TicketCommon { EncTicketPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          realm (WITH COMPONENTS { ia5 PRESENT }),
-          sname (WITH COMPONENTS {
-              ...,
-              name-string (WITH COMPONENT
-                           (WITH COMPONENTS { ia5 PRESENT }))
-          }),
-          extensions ABSENT
-      })
-
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      TicketExt ::= [APPLICATION 4] TicketCommon
-      (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          realm (WITH COMPONENTS { ia5 ABSENT }),
-          sname (WITH COMPONENTS {
-              ...,
-              name-string (WITH COMPONENT
-                           (WITH COMPONENTS { ia5 ABSENT }))
-          })
-      })
-
-
-      TEType                  ::= Int32
-
-      TICKETEXTENSION         ::= TYPEDHOLE { TEType }
-
-      -- ticket extensions: for TicketExt only
-      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          te-type             [0] TICKETEXTENSION.&id
-                                      ({TicketExtension-Set}),
-          te-data             [1] OCTET STRING (TICKETEXTENSION.&Type)
-                                      ({TicketExtension-Set}{@te-type})
-      }
-
-      -- no mandatory ticket extensions currently
-      TicketExtensionSet TICKETEXTENSION ::= { ... }
-
-
-9.  Credential Acquisition
-
-
-
-Yu                          Expires: Aug 2004                  [Page 23]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   There are two exchanges that can be used for acquiring credentials:
-   the AS exchange and the TGS exchange.  These exchanges have many
-   similarities, and this document describes them in parallel, noting
-   which behaviors are specific to one type of exchange.  The AS request
-   (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
-   (KDC-REQ).  Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
-   are forms of KDC replies (KDC-REP).
-
-9.1.  KDC-REQ
-
-   The KDC-REQ has a large number of fields in common between the RFC
-   1510 and the extensible versions.
-
-      KDC-REQ-COMMON  ::= SEQUENCE {
-      -- NOTE: first tag is [1], not [0]
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
-                                   | 12 -- TGS-REQ.rfc1510 --
-                                   | 6 -- AS-REQ.ext --
-                                   | 8 -- TGS-REQ.ext -- ),
-          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
-          -- NOTE: not empty
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 24]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      KDC-REQ-BODY-COMMON     ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalName OPTIONAL
-          -- Used only in AS-REQ --,
-
-          realm               [2] Realm
-          -- Server's realm; also client's in AS-REQ --,
-
-          sname               [3] PrincipalName OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime OPTIONAL
-          -- was required in rfc1510;
-          -- still required for compat versions
-          -- of messages --,
-
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --,
-          ...
-      }
-
-
-   Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of
-   an EncTicketPartCommon.  The KDC copies most of them unchanged,
-   provided that their values meet site policy.
-
-   kdc-options
-        These flags do not correspond directly to "flags" in
-        EncTicketPartCommon.  [ insert mapping table here ]
-
-   cname
-        This field is copied to the "cname" field in
-        EncTicketPartCommon.  The "cname" field is required in an AS-
-        REQ; the client places its own name here.  In a TGS-REQ, the
-        "cname" in the ticket in the AP-REQ takes precedence.
-
-   realm
-        This field is the server's realm, and also holds the client's
-        realm in an AS-REQ.
-
-
-Yu                          Expires: Aug 2004                  [Page 25]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   The "from", "till", and "rtime" fields correspond to the "starttime",
-   "endtime", and "renew-till" fields of EncTicketPartCommon.
-
-   addresses
-        This field corresponds to the "caddr" field of
-        EncTicketPartCommon.
-
-   enc-authorization-data
-        For TGS-REQ, this field contains authorization data encrypted
-        using either the TGT session key or the AP-REQ subsession key;
-        these may be copied into the "authorization-data" field of
-        EncTicketPartCommon if policy permits.
-
-9.2.  PA-DATA
-
-   PA-DATA have multiple uses in the Kerberos protocol.  They may pre-
-   authenticate an AS-REQ; they may also modify several of the
-   encryption keys used in a KDC-REP.  PA-DATA may also provide "hints"
-   to the client about which long-term key (usually password-derived) to
-   use.  PA-DATA may also include "hints" about which pre-authentication
-   mechanisms to use, or include data for input into a pre-
-   authentication mechanism.
-
-9.3.  KDC-REQ Processing
-
-   Processing of a KDC-REQ proceeds through several steps.  An
-   implementation need not perform these steps exactly as described, as
-   long as the resulting behavior is as if the steps were performed as
-   described.  The KDC performs replay handling on receipt of the
-   request; it then validates the request, adjusts timestamps, and
-   selects the keys used in the reply.  It copies data from the request
-   into the issued ticket, adjusting for policy.  The KDC then transmits
-   the reply to the client.
-
-9.3.1.  Handling Replays
-
-   Because Kerberos can run over unreliable transports such as UDP, the
-   KDC MUST be prepared to retransmit responses in case they are lost.
-   If a KDC receives a request identical to one it has recently
-   successfully processed, the KDC MUST respond with an KDC-REP message
-   rather than a replay error.  In order to reduce the amount of
-   ciphertext given to a potential attacker, KDCs MAY send the same
-   response generated when the request was first handled.  KDCs MUST
-   obey this replay behavior even if the actual transport in use is
-   reliable.  If the AP-REQ which authenticates a TGS-REQ is a replay,
-   and the entire request is not identical to a recently successfully
-   processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
-   appropriate for AP-REQ processing.
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 26]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-9.3.2.  Request Validation
-
-9.3.2.1.  AS-REQ Authentication
-
-   Site policy determines whether a given client principal is required
-   to provide some pre-authentication prior to receiving an AS-REP.
-   Since the default reply key is typically the client's long-term
-   password-based key, an attacker may easily request known plaintext
-   (in the form of an AS-REP) upon which to mount a dictionary attack.
-   Pre-authentication can limit the possibility of such an attack.
-
-   If site policy requires pre-authentication for a client principal,
-   and no pre-authentication is provided, the KDC returns the error
-   "kdc-err-preauth-required".  Accompanying this error are "e-data"
-   which include hints telling the client which pre-authentication
-   mechanisms to use, or data for input to pre-authentication mechanisms
-   (e.g., input to challenge-response systems).  If pre-authentication
-   fails, the KDC returns the error "kdc-err-preauth-failed".
-
-   [ may need additional changes based on Sam's preauth draft ]
-
-9.3.2.2.  TGS-REQ Authentication
-
-   A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
-   tgs-req".  The KDC MUST validate the checksum in the Authenticator of
-   the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
-   BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
-   request.  [ padata not signed by authenticator! ] Any error from the
-   AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
-   The service principal in the ticket of the AP-REQ may be a ticket-
-   granting service principal, or a normal application service
-   principal.  An AP-REQ ticket which is not a ticket-granting ticket
-   MUST NOT be used to issue a ticket for any service other than the one
-   named in the ticket.  In this case, the "renew", "validate", or
-   "proxy" [?also forwarded?]  option must be set in the request.
-
-9.3.2.3.  Principal Validation
-
-   If the client principal in an AS-REQ is unknown, the KDC returns the
-   error "kdc-err-c-principal-unknown".  If the server principal is
-   unknown, the KDC returns the error "kdc-err-c-principal-unknown".
-
-9.3.3.  Timestamp Handling
-
-   [ some aspects of timestamp handling, especially regarding postdating
-   and renewal, are difficult to read in KCLAR... needs closer
-   examination here ]
-
-   For the AS exchange, the "authtime" of a ticket is set to the local
-   time at the KDC.  For the TGS exchange, the KDC sets the "authtime"
-   to that of the ticket in the AP-REQ authenticating the TGS-REQ.
-
-Yu                          Expires: Aug 2004                  [Page 27]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   [?application server can spoof the authtime.  security issues for
-   hot-list?] [ MIT implementation may change authtime of renewed
-   tickets; needs check... ]
-
-   Processing of "starttime" (requested in the "from" field) differs
-   depending on whether the "postdated" option is set in the request.
-   If the "postdated" option is not set, and the requested "starttime"
-   is in the future beyond the window of acceptable clock skew, the KDC
-   returns the error "kdc-err-cannot-postdate".  If the "postdated"
-   option is not set, and the requested "starttime" is absent or does
-   not indicate a time in the future beyond the acceptable clock skew,
-   the KDC sets the "starttime" to the KDC's current time.  The
-   "postdated" option MUST NOT be honored if the ticket is being
-   requested by TGS-REQ and the "may-postdate" is not set in the TGT.
-   Otherwise, if the "postdated" option is set, and site policy permits,
-   the KDC sets the "starttime" as requested, and sets the "invalid"
-   flag in the new ticket.
-
-9.3.3.1.  AS-REQ Timestamp Processing
-
-   The "endtime" of the ticket will be set to the earlier of the
-   requested "till" time and a time determined by local policy, possibly
-   determined using factors specific to the realm or principal. For
-   example, the expiration time MAY be set to the earliest of the
-   following:
-
-   *    The expiration time (till) requested.
-
-   *    The ticket's start time plus the maximum allowable lifetime
-        associated with the client principal from the authentication
-        server's database.
-
-   *    The ticket's start time plus the maximum allowable lifetime
-        associated with the server principal.
-
-   *    The ticket's start time plus the maximum lifetime set by the
-        policy of the local realm.
-
-   If the requested expiration time minus the start time (as determined
-   above) is less than a site-determined minimum lifetime, an error
-   message with code "kdc-err-never-valid" is returned. If the requested
-   expiration time for the ticket exceeds what was determined as above,
-   and if the "renewable-ok" option was requested, then the "renewable"
-   flag is set in the new ticket, and the "renew-till" value is set as
-   if the "renewable" option were requested.
-
-   If the "renewable" option has been requested or if the "renewable-ok"
-   option has been set and a renewable ticket is to be issued, then the
-   renew-till field MAY be set to the earliest of:
-
-
-
-Yu                          Expires: Aug 2004                  [Page 28]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   *    Its requested value.
-
-   *    The start time of the ticket plus the minimum of the two maximum
-        renewable lifetimes associated with the principals' database
-        entries.
-
-   *    The start time of the ticket plus the maximum renewable lifetime
-        set by the policy of the local realm.
-
-9.3.3.2.  TGS-REQ Timestamp Processing
-
-   If the TGS-REQ has the TGT in its AP-REQ, and the TGS-REQ requests an
-   "endtime" (in the "till" field), then the "endtime" of the new ticket
-   is set to the minimum of (a) the requested "endtime" value, (b) the
-   "endtime" in the TGT, and (c) an "endtime" determined by site policy
-   on ticket lifetimes.  If the new ticket is a renewal, the "endtime"
-   of the new ticket is bounded by (a) the requested "endtime" value,
-   (b) the value of the "renew-till" value of the old, and (c) the
-   "starttime" of the new ticket plus the life (endtime - starttime) of
-   the old ticket.  [ the previous sentence is a bit confusing; adapted
-   from KCLAR 3.3.3. ]
-
-   When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
-   a "starttime", "endtime", or "renew-till" time later than the "renew-
-   till" time of the TGT.
-
-9.3.4.  Key Selection
-
-   Three keys are involved in creating a KDC-REP.  The reply key is used
-   to encrypt the encrypted part of the KDC-REP.  The session key is
-   stored in the encrypted part of the ticket, and is also present in
-   the part of the reply which is visible to the client.  The ticket key
-   is used to encrypt the ticket.  These keys all have initial values
-   for a given exchange; pre-authentication and other extension
-   mechanisms may change the value used for any of these keys.
-
-   [ again, may need changes based on Sam's preauth draft ]
-
-   The set of encryption types the client will understand appears in the
-   "etype" field of KDC-REQ-BODY-COMMON.  The KDC limits the set of
-   possible reply keys and the set of session key encryption types based
-   on the "etype" field.
-
-   For the AS exchange, the reply key is initially a long-term key of
-   the client, limited to those encryption types specified by the
-   "etype" field.  The KDC SHOULD use the first valid strong "etype" for
-   which an encryption key is available.  For the TGS exchange, the
-   reply key is initially the subsession key of the Authenticator, or,
-   if that is not present, the session key of the ticket used to
-   authenticate the TGS-REQ.
-
-
-Yu                          Expires: Aug 2004                  [Page 29]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   The ticket key is initially the long-term key of the service.  User-
-   to-user authentication sets the ticket key to be the session key of
-   the additional ticket in the request.
-
-   The session key is initially randomly generated, and has an
-   encryption type which both the client and the server will understand.
-   Typically, the KDC has prior knowledge of which encryption types the
-   server will understand.  It selects the first valid strong "etype"
-   listed the request which the server also will understand.
-
-9.3.5.  Checking For Revoked Tickets
-
-9.4.  Reply Validation
-
-10.  Application Authentication
-
-11.  Session Key Use
-
-11.1.  KRB-SAFE
-
-11.2.  KRB-PRIV
-
-11.3.  KRB-CRED
-
-12.  Security Considerations
-
-12.1.  Time Synchronization
-
-   Time synchronization between the KDC and application servers is
-   necessary to prevent acceptance of expired tickets.
-
-   Time synchronization is needed between application servers and
-   clients to prevent replay attacks if a replay cache is being used.
-   If negotiated subsession keys are used to encrypt application data,
-   replay caches may not be necessary.
-
-12.2.  Replays
-
-12.3.  Principal Name Reuse
-
-   See Section 6.2.
-
-12.4.  Password Guessing
-
-12.5.  Forward Secrecy
-
-   [from KCLAR 10.; needs some rewriting]
-
-   The Kerberos protocol in its basic form does not provide perfect
-   forward secrecy for communications.  If traffic has been recorded by
-   an eavesdropper, then messages encrypted using the KRB-PRIV message,
-
-Yu                          Expires: Aug 2004                  [Page 30]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   or messages encrypted using application-specific encryption under
-   keys exchanged using Kerberos can be decrypted if any of the user's,
-   application server's, or KDC's key is subsequently discovered.  This
-   is because the session key used to encrypt such messages is
-   transmitted over the network encrypted in the key of the application
-   server, and also encrypted under the session key from the user's
-   ticket-granting ticket when returned to the user in the TGS-REP
-   message.  The session key from the ticket-granting ticket was sent to
-   the user in the AS-REP message encrypted in the user's secret key,
-   and embedded in the ticket-granting ticket, which was encrypted in
-   the key of the KDC.  Application requiring perfect forward secrecy
-   must exchange keys through mechanisms that provide such assurance,
-   but may use Kerberos for authentication of the encrypted channel
-   established through such other means.
-
-12.6.  Authorization
-
-   As an authentication service, Kerberos provides a means of verifying
-   the identity of principals on a network.  Kerberos does not, by
-   itself, provide authorization.  Applications SHOULD NOT accept the
-   mere issuance of a service ticket by the Kerberos server as granting
-   authority to use the service.
-
-12.7.  Login Authentication
-
-   Some applications, particularly those which provide login access when
-   provided with a password, SHOULD NOT treat successful acquisition of
-   credentials as sufficient proof of the user's identity.  An attacker
-   posing as a user could generate an illegitimate KDC-REP message which
-   decrypts properly.  To authenticate a user logging on to a local
-   system, the credentials obtained SHOULD be used in a TGS exchange to
-   obtain credentials for a local service.  Successful use of those
-   credentials to authenticate to the local service assures that the
-   initially obtained credentials are from a valid KDC.
-
-Appendices
-
-A.  ASN.1 Module (Normative)
-
-      KerberosV5Spec3 {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2) modules(4) krb5spec3(4)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 31]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      -- OID arc for KerberosV5
-      --
-      -- This OID may be used to identify Kerberos protocol messages
-      -- encapsulated in other protocols.
-      --
-      -- This OID also designates the OID arc for KerberosV5-related
-      -- OIDs.
-      --
-      -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
-      -- OID.
-      id-krb5         OBJECT IDENTIFIER ::= {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2)
-      }
-
-
-      -- top-level type
-      --
-      -- Applications should not directly reference any types
-      -- other than KRB-PDU and its component types.
-      --
-      KRB-PDU         ::= CHOICE {
-          ticket      Ticket,
-          as-req      AS-REQ,
-          as-rep      AS-REP,
-          tgs-req     TGS-REQ,
-          tgs-rep     TGS-REP,
-          ap-req      AP-REQ,
-          ap-rep      AP-REP,
-          krb-safe    KRB-SAFE,
-          krb-priv    KRB-PRIV,
-          krb-cred    KRB-CRED,
-          tgt-req     TGT-REQ,
-          krb-error   KRB-ERROR,
-          ...
-      }
-
-
-      --
-      -- *** basic types
-      --
-
-
-      -- signed values representable in 32 bits
-      --
-      -- These are often used as assigned numbers for various things.
-      Int32           ::= INTEGER (-2147483648..2147483647)
-
-      -- unsigned 32 bit values
-      UInt32          ::= INTEGER (0..4294967295)
-
-
-Yu                          Expires: Aug 2004                  [Page 32]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      -- microseconds
-      Microseconds    ::= INTEGER (0..999999)
-
-
-      -- sequence numbers
-      --
-      -- We may want to increase this to 2**64 and define a UInt64
-      -- type.
-      SeqNum          ::= UInt32
-
-
-      -- nonces
-      --
-      -- Likewise, we may want to make this UInt64.
-      Nonce           ::= UInt32
-
-
-      -- must not have fractional seconds
-      KerberosTime    ::= GeneralizedTime
-
-
-      -- used for names and for error messages
-      KerberosString  ::= CHOICE {
-          ia5         GeneralString (IA5String),
-          utf8        UTF8String,
-          ...         -- no extension may be sent
-                      -- to an rfc1510 implementation --
-      }
-
-
-      -- used for language tags
-      LangTag ::= PrintableString (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
-
-
-      Realm           ::= KerberosString
-
-      PrincipalName   ::= SEQUENCE {
-          name-type   [0] NameType,
-          -- May have zero elements, or individual elements may be
-          -- zero-length, but this is not recommended.
-          name-string [1] SEQUENCE OF KerberosString
-      }
-
-      -- assigned numbers for name types (used in principal names)
-      NameType        ::= Int32
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 33]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      -- Name type not known
-      nt-unknown              NameType ::= 0
-      -- Just the name of the principal as in DCE, or for users
-      nt-principal            NameType ::= 1
-      -- Service and other unique instance (krbtgt)
-      nt-srv-inst             NameType ::= 2
-      -- Service with host name as instance (telnet, rcommands)
-      nt-srv-hst              NameType ::= 3
-      -- Service with host as remaining components
-      nt-srv-xhst             NameType ::= 4
-      -- Unique ID
-      nt-uid                  NameType ::= 5
-      -- Encoded X.509 Distingished name [RFC 2253]
-      nt-x500-principal       NameType ::= 6
-      -- Name in form of SMTP email name (e.g. user@foo.com)
-      nt-smtp-name            NameType ::= 7
-      -- Enterprise name - may be mapped to principal name
-      nt-enterprise           NameType ::= 10
-
-
-      -- Yet another refinement to kludge around historical
-      -- implementation bugs... we still send at least 32 bits, but
-      -- this parameterized type allows us to actually use named bit
-      -- string syntax to define flags, sort of.
-      KerberosFlags { NamedBits }
-          ::= BIT STRING (SIZE (32..MAX))
-          (CONSTRAINED BY {
-          -- must be a valid value of -- NamedBits
-          -- but if the value to be sent would otherwise be shorter
-          -- than 32 bits, it must be padded with trailing zero bits
-          -- to 32 bits.  Otherwise, no trailing zero bits may be
-          -- present.
-      })
-
-
-      AddrType        ::= Int32
-
-      HostAddress     ::= SEQUENCE  {
-          addr-type   [0] AddrType,
-          address     [1] OCTET STRING
-      }
-
-      -- NOTE: HostAddresses is always used as an OPTIONAL field and
-      -- should not be a zero-length SEQUENCE OF.
-      --
-      -- The extensible messages explicitly constrain this to be
-      -- non-empty.
-      HostAddresses   ::= SEQUENCE OF HostAddress
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 34]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      --
-      -- *** typed hole support
-      --
-
-
-      -- Object class for generic typed holes, e.g., padata,
-      -- authorizationdata.
-      --
-      -- Its parameter specifies the name of integer type used as a
-      -- unique identifier; usually this type is an aliased Int32.
-      --
-      -- Usually, the &Type field will be an OctetstringHole, but if
-      -- there is a need to use a non-ASN.1 encoded type, it may be
-      -- simply an OCTET STRING, possibly with some comments
-      -- describing its contents.
-      TYPEDHOLE { IntType } ::= CLASS {
-          &id-int     IntType UNIQUE,
-          &id-oid     RELATIVE-OID UNIQUE OPTIONAL,
-          &Type,
-          &desc       ObjectDescriptor OPTIONAL
-      } WITH SYNTAX {
-          SYNTAX              &Type
-          IDENTIFIED BY       &id-int
-          [ OID               &id-oid ]
-          [ DESCRIPTION       &desc ]
-      }
-
-
-      -- An octet string wrapping another ASN.1 type.
-      OctetstringHole { Type } ::= OCTET STRING (CONTAINING Type)
-
-
-      --
-      -- *** crypto-related types and assignments
-      --
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 35]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      --
-      -- Actual identifier names are provisional and subject to
-      -- change.
-      --
-      ku-pa-enc-ts                    KeyUsage ::= 1
-      ku-Ticket                       KeyUsage ::= 2
-      ku-EncASRepPart                 KeyUsage ::= 3
-      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
-      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
-      ku-pa-TGSReq-cksum              KeyUsage ::= 6
-      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
-      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
-      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
-      ku-Authenticator-cksum          KeyUsage ::= 10
-      ku-APReq-authenticator          KeyUsage ::= 11
-      ku-EncAPRepPart                 KeyUsage ::= 12
-      ku-EncKrbPrivPart               KeyUsage ::= 13
-      ku-EncKrbCredPart               KeyUsage ::= 14
-      ku-KrbSafe-cksum                KeyUsage ::= 15
-      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
-
-
-      -- The following numbers are provisional... conflicts may exist elsewhere.
-      ku-Ticket-cksum                 KeyUsage ::= 25
-      ku-ASReq-cksum                  KeyUsage ::= 26
-      ku-TGSReq-cksum                 KeyUsage ::= 27
-      ku-ASRep-cksum                  KeyUsage ::= 28
-      ku-TGSRep-cksum                 KeyUsage ::= 29
-      ku-APReq-cksum                  KeyUsage ::= 30
-      ku-APRep-cksum                  KeyUsage ::= 31
-      ku-KrbCred-cksum                KeyUsage ::= 32
-      ku-KrbError-cksum               KeyUsage ::= 33
-      ku-KDCRep-cksum                 KeyUsage ::= 34
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 36]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      -- assigned numbers for encryption schemes
-      et-des-cbc-crc                  EType ::= 1
-      et-des-cbc-md4                  EType ::= 2
-      et-des-cbc-md5                  EType ::= 3
-      --     [reserved]                         4
-      et-des3-cbc-md5                 EType ::= 5
-      --     [reserved]                         6
-      et-des3-cbc-sha1                EType ::= 7
-      et-dsaWithSHA1-CmsOID           EType ::= 9
-      et-md5WithRSAEncryption-CmsOID  EType ::= 10
-      et-sha1WithRSAEncryption-CmsOID EType ::= 11
-      et-rc2CBC-EnvOID                EType ::= 12
-      et-rsaEncryption-EnvOID         EType ::= 13
-      et-rsaES-OAEP-ENV-OID           EType ::= 14
-      et-des-ede3-cbc-Env-OID         EType ::= 15
-      et-des3-cbc-sha1-kd             EType ::= 16
-      et-aes128-cts-hmac-sha1-96      EType ::= 17 -- AES
-      et-aes256-cts-hmac-sha1-96      EType ::= 18 -- AES
-      et-rc4-hmac                     EType ::= 23 -- Microsoft
-      et-rc4-hmac-exp                 EType ::= 24 -- Microsoft
-      et-subkey-keymaterial           EType ::= 65 -- opaque; PacketCable
-
-
-      -- "Type" specifies which ASN.1 type is encrypted to the
-      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
-      -- keys of which one key may be used to encrypt the data.
-      -- "KeyUsages" specifies a set of key usages, one of which may
-      -- be used to encrypt.
-      --
-      -- None of the parameters is transmitted over the wire.
-      EncryptedData { Type, KeyToUse:Keys, KeyUsage:KeyUsages } ::=
-      SEQUENCE {
-          etype       [0] EType,
-          kvno        [1] UInt32 OPTIONAL,
-          cipher      [2] OCTET STRING (CONSTRAINED BY {
-              -- must be encryption of --
-              OCTET STRING (CONTAINING Type),
-              -- with one of the keys -- KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          }),
-          ...
-      }
-
-      -- Assigned numbers denoting encryption mechanisms.
-      EType ::= Int32
-
-      -- Assigned numbers denoting key usages.
-      KeyUsage ::= UInt32
-
-
-
-Yu                          Expires: Aug 2004                  [Page 37]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      -- KeyToUse identifies which key is to be used to encrypt or
-      -- sign a given value.
-      --
-      -- Values of KeyToUse are never actually transmitted over the
-      -- wire, or even used directly by the implementation in any
-      -- way, as key usages are; it exists primarily to identify
-      -- which key gets used for what purpose.  Thus, the specific
-      -- numeric values associated with this type are irrelevant.
-      KeyToUse        ::= ENUMERATED {
-          -- unspecified
-          key-unspecified,
-          -- server long term key
-          key-server,
-          -- client long term key
-          key-client,
-          -- key selected by KDC for encryption of a KDC-REP
-          key-kdc-rep,
-          -- session key from ticket
-          key-session,
-          -- subsession key negotiated via AP-REQ/AP-REP
-          key-subsession,
-          ...
-      }
-
-
-      EncryptionKey   ::= SEQUENCE {
-          keytype     [0] EType,
-          keyvalue    [1] OCTET STRING
-      }
-
-
-      CksumType       ::= Int32
-
-      -- The parameters specify which key to use to produce the
-      -- signature, as well as which key usage to use.  The
-      -- parameters are not actually sent over the wire.
-      Checksum { KeyToUse:Keys, KeyUsage:KeyUsages } ::= SEQUENCE {
-          cksumtype   [0] CksumType,
-          checksum    [1] OCTET STRING (CONSTRAINED BY {
-              -- signed using one of the keys --
-              KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          })
-      }
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 38]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      -- a Checksum that must contain the checksum of a particular type
-      ChecksumOf { Type, KeyToUse:Keys, KeyUsage:KeyUsages } ::=
-      Checksum { Keys, KeyUsages }
-      (WITH COMPONENTS {
-          ...,
-          checksum (CONSTRAINED BY {
-              -- must be checksum of --
-              OCTET STRING (CONTAINING Type)
-          })
-      })
-
-
-      -- parameterized type for wrapping authenticated plaintext
-      Signed { InnerType, KeyToUse:Keys, KeyUsage:KeyUsages } ::=
-      SEQUENCE {
-          cksum       [0] ChecksumOf
-                              { InnerType, Keys, KeyUsages } OPTIONAL,
-          inner       [1] InnerType,
-          ...
-      }
-
-
-      --
-      -- *** Tickets
-      --
-
-
-      Ticket          ::= CHOICE {
-          rfc1510     [APPLICATION 1] Ticket1510,
-          ext         [APPLICATION 4] Signed {
-              TicketExt, { key-server }, { ku-Ticket-cksum }
-          }
-      }
-
-
-      -- takes a parameter specifying which type gets encrypted
-      TicketCommon { EncPart } ::= SEQUENCE {
-          tkt-vno     [0] INTEGER (5),
-          realm       [1] Realm,
-          sname       [2] PrincipalName,
-          enc-part    [3] EncryptedData {
-              EncPart, { key-server }, { ku-Ticket }
-          },
-          extensions          [4] TicketExtensions OPTIONAL,
-          ...
-      }
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 39]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      Ticket1510 ::= SEQUENCE {
-          -- "COMPONENTS OF" drops the extension marker from
-          -- TicketCommon
-          COMPONENTS OF TicketCommon { EncTicketPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          realm (WITH COMPONENTS { ia5 PRESENT }),
-          sname (WITH COMPONENTS {
-              ...,
-              name-string (WITH COMPONENT
-                           (WITH COMPONENTS { ia5 PRESENT }))
-          }),
-          extensions ABSENT
-      })
-
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      TicketExt ::= [APPLICATION 4] TicketCommon
-      (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          realm (WITH COMPONENTS { ia5 ABSENT }),
-          sname (WITH COMPONENTS {
-              ...,
-              name-string (WITH COMPONENT
-                           (WITH COMPONENTS { ia5 ABSENT }))
-          })
-      })
-
-
-      -- Encrypted part of ticket
-      EncTicketPart ::= CHOICE {
-          rfc1510     [APPLICATION 3] EncTicketPart1510,
-          ext         [APPLICATION 5] EncTicketPartExt
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 40]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      EncTicketPartCommon ::= SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] Realm,
-          cname               [3] PrincipalName,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-      EncTicketPart1510 ::= SEQUENCE {
-          -- effectively drops the extension marker
-          COMPONENTS OF EncTicketPartCommon
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          crealm (WITH COMPONENTS { ia5 PRESENT }),
-          cname (WITH COMPONENTS {
-              ...,
-              name-string (WITH COMPONENT
-                           (WITH COMPONENTS { ia5 PRESENT }))
-          })
-      })
-
-
-      EncTicketPartExt ::= EncTicketPartCommon
-      (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          crealm (WITH COMPONENTS { ia5 ABSENT }),
-          cname (WITH COMPONENTS {
-              ...,
-              name-string (WITH COMPONENT
-                           (WITH COMPONENTS { ia5 ABSENT }))
-          }),
-          -- explicitly constrain caddr to be non-empty if present
-          caddr (SIZE (1..MAX)),
-          -- explicitly constrain authorization-data to be non-empty
-          -- if present
-          authorization-data (SIZE (1..MAX))
-      })
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 41]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      --
-      -- *** Authorization Data
-      --
-
-
-      ADType          ::= Int32
-
-      AUTHDATA        ::= TYPEDHOLE { ADType }
-
-      -- NOTE: AuthorizationData is always used as an OPTIONAL field and
-      -- should not be a zero-length SEQUENCE OF.
-      --
-      -- The extensible messages explicitly constrain this to be non-empty.
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-          ad-type             [0] AUTHDATA.&id-int ({Authdata-Set}),
-          ad-data             [1] OCTET STRING (AUTHDATA.&Type)
-                                      ({Authdata-Set}{@ad-type})
-      }
-
-
-      -- Mandatory AuthorizationData
-      Authdata-Set AUTHDATA ::= {
-          ad-if-relevant |
-          ad-kdcissued |
-          ad-and-or |
-          ad-mandatory-for-kdc ,
-          ...
-      }
-
-
-      ad-if-relevant AUTHDATA ::= {
-          SYNTAX              OctetstringHole { AuthorizationData }
-          IDENTIFIED BY       1
-          DESCRIPTION
-          "Encapsulates another AuthorizationData.
-      Intended for application servers; receiving application servers
-      MAY ignore."
-      }
-
-
-      ad-kdcissued AUTHDATA ::= {
-          SYNTAX              OctetstringHole { AD-KDCIssued }
-          IDENTIFIED BY       4
-          DESCRIPTION "KDC-issued privilege attributes"
-      }
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 42]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      AD-KDCIssued            ::= SEQUENCE {
-          ad-checksum [0] ChecksumOf {
-              AuthorizationData, { key-session },
-              { ku-ad-KDCIssued-cksum }},
-          i-realm     [1] Realm OPTIONAL,
-          i-sname     [2] PrincipalName OPTIONAL,
-          elements    [3] AuthorizationData
-      }
-
-
-      AD-AND-OR               ::= SEQUENCE {
-          condition-count     [0] INTEGER,
-          elements            [1] AuthorizationData
-      }
-
-
-      AD-MANDATORY-FOR-KDC    ::= AuthorizationData
-
-
-      ad-and-or AUTHDATA ::= {
-          SYNTAX              OctetstringHole { AD-AND-OR }
-          IDENTIFIED BY       5
-          DESCRIPTION "And/Or"
-      }
-
-      AD-AND-OR               ::= SEQUENCE {
-              condition-count [0] INTEGER,
-              elements        [1] AuthorizationData
-      }
-
-
-      ad-mandatory-for-kdc AUTHDATA ::= {
-          SYNTAX              OctetstringHole { AuthorizationData }
-          IDENTIFIED BY       8
-          DESCRIPTION "KDCs MUST interpret any AuthorizationData
-      wrapped in this."
-      }
-
-
-      TrType                  ::= Int32 -- must be registered
-
-      -- encoded Transited field
-      TransitedEncoding       ::= SEQUENCE {
-          tr-type     [0] TrType,
-          contents    [1] OCTET STRING
-      }
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 43]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      TEType                  ::= Int32
-
-      TICKETEXTENSION         ::= TYPEDHOLE { TEType }
-
-      -- ticket extensions: for TicketExt only
-      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          te-type             [0] TICKETEXTENSION.&id
-                                      ({TicketExtension-Set}),
-          te-data             [1] OCTET STRING (TICKETEXTENSION.&Type)
-                                      ({TicketExtension-Set}{@te-type})
-      }
-
-      -- no mandatory ticket extensions currently
-      TicketExtensionSet TICKETEXTENSION ::= { ... }
-
-
-      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
-
-      TicketFlagsBits ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          may-postdate        (5),
-          postdated           (6),
-          invalid             (7),
-          renewable           (8),
-          initial             (9),
-          pre-authent         (10),
-          hw-authent          (11),
-          transited-policy-checked (12),
-          ok-as-delegate      (13),
-          anonymous           (14),
-          cksummed-ticket     (15)
-      }
-
-
-      --
-      -- *** KDC protocol
-      --
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 44]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      AS-REQ  ::= CHOICE {
-          rfc1510     [APPLICATION 10] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (10),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          }),
-          ext         [APPLICATION 6]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as outside,
-              -- to prevent possible substitution attacks.
-              [APPLICATION 6] KDC-REQ-EXT,
-              -- not sure this is correct key to use; do we even want
-              -- to sign AS-REQ?
-              { key-client },
-              { ku-ASReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (6),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          })
-      }
-
-
-      TGS-REQ ::= CHOICE {
-          rfc1510     [APPLICATION 12] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (12),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          }),
-          ext         [APPLICATION 8]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as outside,
-              -- to prevent possible substitution attacks.
-              [APPLICATION 8] KDC-REQ-EXT,
-              { key-session }, { ku-TGSReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (8),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          })
-      }
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 45]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      KDC-REQ-COMMON  ::= SEQUENCE {
-      -- NOTE: first tag is [1], not [0]
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
-                                   | 12 -- TGS-REQ.rfc1510 --
-                                   | 6 -- AS-REQ.ext --
-                                   | 8 -- TGS-REQ.ext -- ),
-          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
-          -- NOTE: not empty
-      }
-
-
-      KDC-REQ-1510    ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-1510
-      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
-
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      KDC-REQ-EXT     ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-EXT,
-          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF LangTag OPTIONAL,
-          ...
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (6 | 8),
-          padata (SIZE (1..MAX))
-      })
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 46]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      KDC-REQ-BODY-COMMON     ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalName OPTIONAL
-          -- Used only in AS-REQ --,
-
-          realm               [2] Realm
-          -- Server's realm; also client's in AS-REQ --,
-
-          sname               [3] PrincipalName OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime OPTIONAL
-          -- was required in rfc1510;
-          -- still required for compat versions
-          -- of messages --,
-
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --,
-          ...
-      }
-
-
-      KDC-REQ-BODY-1510 ::= SEQUENCE {
-          -- effectively drops the extension marker
-          COMPONENTS OF KDC-REQ-BODY-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          cname (WITH COMPONENTS {
-              ...,
-              name-string (WITH COMPONENT
-                           (WITH COMPONENTS { ia5 PRESENT }))
-          }),
-          realm (WITH COMPONENTS { ia5 PRESENT }),
-          sname (WITH COMPONENTS {
-              ...,
-              name-string (WITH COMPONENT
-                           (WITH COMPONENTS { ia5 PRESENT }))
-          }),
-          till PRESENT
-      })
-
-Yu                          Expires: Aug 2004                  [Page 47]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
-      (WITH COMPONENTS {
-          ...,
-          cname (WITH COMPONENTS {
-              ...,
-              name-string (WITH COMPONENT
-                           (WITH COMPONENTS { ia5 ABSENT }))
-          }),
-          realm (WITH COMPONENTS { ia5 ABSENT }),
-          sname (WITH COMPONENTS {
-              ...,
-              name-string (WITH COMPONENT
-                           (WITH COMPONENTS { ia5 ABSENT }))
-          }),
-          addresses (SIZE (1..MAX)),
-          enc-authorization-data (EncryptedData {
-              AuthorizationData (SIZE (1..MAX)),
-              { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          }),
-          additional-tickets (SIZE (1..MAX))
-      })
-
-
-      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
-      KDCOptionsBits ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          allow-postdate      (5),
-          postdated           (6),
-          unused7             (7),
-          renewable           (8),
-          unused9             (9),
-          unused10            (10),
-          unused11            (11),
-          unused12            (12),
-          unused13            (13),
-          requestanonymous    (14),
-          canonicalize        (15),
-          disable-transited-check (26),
-          renewable-ok        (27),
-          enc-tkt-in-skey     (28),
-          renew               (30),
-          validate            (31)
-          -- XXX need "need ticket1" flag?
-      }
-
-
-Yu                          Expires: Aug 2004                  [Page 48]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      AS-REP          ::= CHOICE {
-          rfc1510     [APPLICATION 11] KDC-REP-1510 { EncASRepPart }
-          (WITH COMPONENTS { ..., msg-type (11) }),
-          ext         [APPLICATION  7]  Signed {
-              [APPLICATION 7] KDC-REP-EXT { EncASRepPart },
-              { key-reply }, { ku-ASRep-cksum }
-          } (WITH COMPONENTS { ..., msg-type (7) })
-      }
-
-
-      TGS-REP         ::= CHOICE {
-          rfc1510     [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart }
-          (WITH COMPONENTS { ..., msg-type (13) }),
-          ext         [APPLICATION  9]  Signed {
-              [APPLICATION 9] KDC-REP-EXT { EncTGSRepPart },
-              { key-reply }, { ku-TGSRep-cksum }
-          } (WITH COMPONENTS { ..., msg-type (9) })
-      }
-
-
-      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
-                                   13 -- TGS.rfc1510 -- |
-                                   7 -- AS-REP.ext -- |
-                                   9 -- TGS-REP.ext -- ),
-          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
-          crealm      [3] Realm,
-          cname       [4] PrincipalName,
-          ticket      [5] Ticket,
-          enc-part    [6] EncryptedData {
-              EncPart,
-              { key-reply },
-              -- maybe reach into EncryptedData in AS-REP/TGS-REP definitions
-              -- to apply constraints on key usages?
-              { ku-EncASRepPart -- if AS-REP -- |
-                ku-EncTGSRepPart-subkey -- if TGS-REP and using --
-                                        -- Authenticator session key -- |
-                ku-EncTGSRepPart-sesskey -- if TGS-REP and using --
-                                         -- subsession key -- }
-          },
-          -- In extensible version, KDC signs original request
-          -- to avoid replay attacks agaginst client.
-          req-cksum   [7] ChecksumOf { CHOICE {
-              as-req          AS-REQ,
-              tgs-req         TGS-REQ
-          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
-          lang-tag    [8] LangTag OPTIONAL,
-          ...
-      }
-
-
-Yu                          Expires: Aug 2004                  [Page 49]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      KDC-REP-1510 { EncPart } ::= SEQUENCE {
-          -- effectively drops the extension marker
-          COMPONENTS OF KDC-REP-COMMON { EncPart }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (11 | 13),
-          crealm (WITH COMPONENTS { ia5 PRESENT}),
-          cname (WITH COMPONENTS {
-              ...,
-              name-string (WITH COMPONENT
-                           (WITH COMPONENTS { ia5 PRESENT }))
-          }),
-          req-cksum ABSENT,
-          lang-tag ABSENT
-      })
-
-
-      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
-      (WITH COMPONENTS {
-          ...,
-          msg-type (7 | 9),
-          crealm (WITH COMPONENTS { ia5 ABSENT }),
-          cname (WITH COMPONENTS {
-              ...,
-              name-string (WITH COMPONENT
-                           (WITH COMPONENTS { ia5 ABSENT }))
-          })
-      })
-
-
-      EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
-      EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
-
-      EncKDCRepPart   ::= SEQUENCE {
-          key                 [0] EncryptionKey,
-          last-req            [1] LastReq,
-          nonce               [2] Nonce,
-          key-expiration      [3] KerberosTime OPTIONAL,
-          flags               [4] TicketFlags,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          srealm              [9] Realm,
-          sname               [10] PrincipalName,
-          caddr               [11] HostAddresses OPTIONAL,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementation
-      }
-
-
-
-Yu                          Expires: Aug 2004                  [Page 50]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      -- convert to use object class?
-      LRType          ::=     Int32
-      LastReq         ::=     SEQUENCE OF SEQUENCE {
-          lr-type     [0] LRType,
-          lr-value    [1] KerberosTime
-      }
-
-
-      --
-      -- *** preauth
-      --
-
-
-      PaDataType ::= Int32
-
-      -- TYPEDHOLE class that uses PaDataType as its unique ID type.
-      PADATA-OBJ ::= TYPEDHOLE { PaDataType }
-
-      PA-DATA ::= SEQUENCE {
-          -- NOTE: first tag is [1], not [0]
-          padata-type         [1] CHOICE {
-              -- example of possible use of RELATIVE-OIDs
-              int     PADATA-OBJ.&id-int ({PaDataSet}),
-              oid     PADATA-OBJ.&id-oid ({PaDataSet}{@int})
-          },
-          padata-value        [2] OCTET STRING (PADATA-OBJ.&Type)
-                                      ({PaDataSet}{@padata-type.int})
-      }
-
-
-      PaDataSet PADATA-OBJ ::= {
-          pa-tgs-req |
-          pa-enc-timestamp |
-          pa-etype-info |
-          pa-etype-info2 |
-          pa-pw-salt |
-          pa-as-req ,
-          ...
-      }
-
-
-      pa-tgs-req PADATA-OBJ ::= {
-          SYNTAX              OctetstringHole { AP-REQ }
-          IDENTIFIED BY       1
-          DESCRIPTION
-          "AP-REQ authenticating a TGS-REQ"
-      }
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 51]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      pa-enc-timestamp PADATA-OBJ ::= {
-          SYNTAX              OctetstringHole { PA-ENC-TIMESTAMP }
-          IDENTIFIED BY       2
-          DESCRIPTION
-          "Encrypted timestamp preauth;
-      Encryption key used is client's long-term key."
-      }
-
-      PA-ENC-TIMESTAMP ::= EncryptedData {
-          PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
-      }
-
-      PA-ENC-TS-ENC           ::= SEQUENCE {
-              patimestamp     [0] KerberosTime -- client's time --,
-              pausec          [1] Microseconds OPTIONAL
-      }
-
-
-      pa-etype-info PADATA-OBJ ::= {
-          SYNTAX              OctetstringHole { ETYPE-INFO }
-          IDENTIFIED BY       11
-          DESCRIPTION
-          "Hints returned in AS-REP or KRB-ERROR to help client
-      choose a password-derived key, either for preauthentication or
-      for decryption of the reply."
-      }
-
-      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
-
-      ETYPE-INFO-ENTRY        ::= SEQUENCE {
-              etype           [0] EType,
-              salt            [1] OCTET STRING OPTIONAL
-      }
-
-
-      pa-etype-info2 PADATA-OBJ ::= {
-          SYNTAX              OctetstringHole { ETYPE-INFO2 }
-          IDENTIFIED BY       19
-          DESCRIPTION
-          "Similar to etype-info, but with parameters provided for
-      the string-to-key function."
-      }
-
-      ETYPE-INFO2             ::= SEQUENCE (SIZE (1..MAX))
-                                      OF ETYPE-INFO-ENTRY
-
-      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
-              etype           [0] EType,
-              salt            [1] KerberosString OPTIONAL,
-              s2kparams       [2] OCTET STRING OPTIONAL
-      }
-
-Yu                          Expires: Aug 2004                  [Page 52]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      pa-pw-salt PADATA-OBJ ::= {
-          SYNTAX              OCTET STRING (CONSTRAINED BY {
-            -- Must consist of the salt string to be used by the
-            -- client, in an unspecified character encoding. -- })
-          IDENTIFIED BY       3
-          DESCRIPTION
-          "Obsolescent.  Salt for client's long-term key.
-      Its character encoding is unspecified."
-      }
-
-
-      pa-as-req PADATA-OBJ ::= {
-          SYNTAX              OctetstringHole { AS-REQ
-                                                (WITH COMPONENTS {
-                                                    ext }) }
-          IDENTIFIED BY       42 -- provisional
-          DESCRIPTION
-          "An extensible AS-REQ may be sent as a padata in a
-      non-extensible AS-REQ to allow for backwards compatibility."
-      }
-
-
-      --
-      -- *** Application session setup
-      --
-
-
-      AP-REQ          ::= CHOICE {
-          rfc1510     [APPLICATION 14] AP-REQ-1510,
-          ext         [APPLICATION 18] Signed {
-              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
-          }
-      }
-
-
-      AP-REQ-COMMON   ::= SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14 | 18),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket,
-          authenticator       [4] EncryptedData {
-              Authenticator,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          },
-          extensions          [5] ApReqExtensions OPTIONAL,
-          ...
-      }
-
-
-
-Yu                          Expires: Aug 2004                  [Page 53]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      AP-REQ-1510 ::= SEQUENCE {
-          -- effectively drops the extension marker
-          COMPONENTS OF AP-REQ-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (14),
-          extensions ABSENT
-      })
-
-
-      AP-REQ-EXT      ::= AP-REQ-COMMON
-      (WITH COMPONENTS {
-          ...,
-          msg-type (18),
-          -- The following constraints on Authenticator assume that
-          -- we want to restrict the use of AP-REQ-EXT with TicketExt only,
-          -- since that is the only way we can enforce UTF-8.
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (WITH COMPONENTS { ia5 ABSENT }),
-                  cname (WITH COMPONENTS {
-                      ...,
-                      name-string (WITH COMPONENT
-                                   (WITH COMPONENTS { ia5 ABSENT }))
-                  }),
-                  authorization-data (SIZE (1..MAX))
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-      ApReqExtType    ::= Int32
-
-      ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          apReqExt-Type       [0] ApReqExtType,
-          apReqExt-Data       [1] OCTET STRING
-      }
-
-
-      APOptions       ::= KerberosFlags { APOptionsBits }
-
-      APOptionsBits ::= BIT STRING {
-          reserved            (0),
-          use-session-key     (1),
-          mutual-required     (2)
-      }
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 54]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      -- plaintext of authenticator
-      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-          authenticator-vno   [0] INTEGER (5),
-          crealm              [1] Realm,
-          cname               [2] PrincipalName,
-          cksum               [3] Checksum {{ key-session },
-              { ku-Authenticator-cksum |
-                ku-pa-TGSReq-cksum }} OPTIONAL,
-          cusec               [4] Microseconds,
-          ctime               [5] KerberosTime,
-          subkey              [6] EncryptionKey OPTIONAL,
-          seq-number          [7] SeqNum OPTIONAL,
-          authorization-data  [8] AuthorizationData OPTIONAL
-      }
-
-
-      AP-REP          ::= CHOICE {
-          rfc1510     [APPLICATION 15] AP-REP-1510,
-          ext         [APPLICATION 19] Signed {
-              AP-REP-EXT,
-              { key-session | key-subsession }, { ku-APRep-cksum }}
-      }
-
-
-      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (15 | 19),
-          enc-part    [2] EncryptedData {
-              EncPart,
-              { key-session | key-subsession }, { ku-EncAPRepPart }},
-          extensions          [3] ApRepExtensions OPTIONAL,
-          ...
-      }
-
-
-      AP-REP-1510     ::= SEQUENCE {
-          -- effectively drops the extension marker
-          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (15),
-          extensions ABSENT
-      })
-
-
-      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
-          EncAPRepPartExt }
-      (WITH COMPONENTS { ..., msg-type (19) })
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 55]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      ApRepExtType    ::= Int32
-
-      -- convert to use object class?
-      ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          apRepExt-Type       [0] ApRepExtType,
-          apRepExt-Data       [1] OCTET STRING
-      }
-
-
-      EncAPRepPart    ::= CHOICE {
-          rfc1510     [APPLICATION 27] EncAPRepPart1510,
-          ext         [APPLICATION 31] EncAPRepPartExt
-      }
-
-
-      EncAPRepPart1510        ::= SEQUENCE {
-          COMPONENTS OF ENCAPRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          authorization-data ABSENT
-      })
-
-
-      EncAPRepPartExt         ::= EncAPRepPartCom
-
-
-      EncAPRepPartCom          ::= SEQUENCE {
-          ctime               [0] KerberosTime,
-          cusec               [1] Microseconds,
-          subkey              [2] EncryptionKey OPTIONAL,
-          seq-number          [3] SeqNum OPTIONAL,
-          authorization-data  [4] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-      --
-      -- *** Application messages
-      --
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 56]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      -- Do we chew up another tag for KRB-SAFE-EXT?  That would allow us to
-      -- make safe-body optional, allowing for a GSS-MIC sort of message.
-      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (20),
-          safe-body   [2] KRB-SAFE-BODY,
-          cksum       [3] ChecksumOf {
-              KRB-SAFE-BODY,
-              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-      KRB-SAFE-BODY   ::= SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress,
-          r-address   [5] HostAddress OPTIONAL,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (21),
-          enc-part    [3] EncryptedData {
-              EncKrbPrivPart,
-              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
-          ...
-      }
-
-
-      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress -- sender's addr --,
-          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 57]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      KRB-CRED        ::= CHOICE {
-          rfc1510     [APPLICATION 22] KRB-CRED-1510,
-          ext         [APPLICATION 24] Signed {
-              KRB-CRED-EXT,
-              { key-session | key-subsession }, { ku-KrbCred-cksum }}
-      }
-
-
-      KRB-CRED-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (22 | 24),
-          tickets     [2] SEQUENCE OF Ticket,
-          enc-part    [3] EncryptedData {
-              EncKrbCredPart,
-              { key-session | key-subsession }, { ku-EncKrbCredPart }},
-          ...
-      }
-
-
-      KRB-CRED-1510 ::= SEQUENCE {
-          -- effectively drops the extension marker
-          COMPONENTS OF KRB-CRED-COMMON
-      } (WITH COMPONENTS { ..., msg-type (22) })
-
-
-      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
-      (WITH COMPONENTS { ..., msg-type (24) })
-
-
-      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-          ticket-info [0] SEQUENCE OF KrbCredInfo,
-          nonce       [1] Nonce OPTIONAL,
-          timestamp   [2] KerberosTime OPTIONAL,
-          usec        [3] Microseconds OPTIONAL,
-          s-address   [4] HostAddress OPTIONAL,
-          r-address   [5] HostAddress OPTIONAL
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 58]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      KrbCredInfo     ::= SEQUENCE {
-          key         [0] EncryptionKey,
-          prealm      [1] Realm OPTIONAL,
-          pname       [2] PrincipalName OPTIONAL,
-          flags       [3] TicketFlags OPTIONAL,
-          authtime    [4] KerberosTime OPTIONAL,
-          starttime   [5] KerberosTime OPTIONAL,
-          endtime     [6] KerberosTime OPTIONAL,
-          renew-till  [7] KerberosTime OPTIONAL,
-          srealm      [8] Realm OPTIONAL,
-          sname       [9] PrincipalName OPTIONAL,
-          caddr       [10] HostAddresses OPTIONAL
-      }
-
-
-      TGT-REQ         ::= [APPLICATION 16] SEQUENCE {
-          pvno            [0] INTEGER (5),
-          msg-type        [1] INTEGER (16),
-          sname           [2] PrincipalName OPTIONAL,
-          srealm          [3] Realm OPTIONAL,
-          ...
-      }
-
-
-      --
-      -- *** Error messages
-      --
-
-
-      ErrCode ::= Int32
-
-      KRB-ERROR       ::= CHOICE {
-          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
-          ext         [APPLICATION 23] Signed {
-              KRB-ERROR-EXT, { ku-KrbError-cksum } }
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 59]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-      KRB-ERROR-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (30 | 23),
-          ctime       [2] KerberosTime OPTIONAL,
-          cusec       [3] Microseconds OPTIONAL,
-          stime       [4] KerberosTime,
-          susec       [5] Microseconds,
-          error-code  [6] ErrCode,
-          crealm      [7] Realm OPTIONAL,
-          cname       [8] PrincipalName OPTIONAL,
-          realm       [9] Realm -- Correct realm --,
-          sname       [10] PrincipalName -- Correct name --,
-          e-text      [11] KerberosString OPTIONAL,
-          e-data      [12] OCTET STRING OPTIONAL,
-          typed-data          [13] TYPED-DATA OPTIONAL,
-          nonce               [14] Nonce OPTIONAL,
-          lang-tag            [15] LangTag OPTIONAL,
-          ...
-      }
-
-
-      KRB-ERROR-1510 ::= SEQUENCE {
-          -- effectively drops the extension marker
-          COMPONENTS OF KRB-ERROR-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (30),
-          typed-data ABSENT,
-          nonce ABSENT,
-          lang-tag ABSENT
-      })
-
-
-      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
-      (WITH COMPONENTS { ..., msg-type (23) })
-
-
-      TDType ::= Int32
-
-      -- convert to information object class later
-      TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-          data-type   [0] TDType,
-          data-value  [1] OCTET STRING OPTIONAL
-      }
-
-
-      END
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 60]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-B.  Kerberos and Character Encodings (Informative)
-
-   [adapted from KCLAR 5.2.1]
-
-   The original specification of the Kerberos protocol in RFC 1510 uses
-   GeneralString in numerous places for human-readable string data.
-   Historical implementations of Kerberos cannot utilize the full power
-   of GeneralString.  This ASN.1 type requires the use of designation
-   and invocation escape sequences as specified in ISO-2022/ECMA-35
-   [ISO-2022/ECMA-35] to switch character sets, and the default
-   character set that is designated as G0 is the ISO-646/ECMA-6
-   [ISO-646,ECMA-6] International Reference Version (IRV) (aka U.S.
-   ASCII), which mostly works.
-
-   ISO-2022/ECMA-35 defines four character-set code elements (G0..G3)
-   and two Control-function code elements (C0..C1).  DER previously
-   prohibited the designation of character sets as any but the G0 and C0
-   sets.  This had the side effect of prohibiting the use of ISO-8859
-   (ISO Latin) [ISO-8859] character-sets or any other character-sets
-   that utilize a 96-character set, since it is prohibited by
-   ISO-2022/ECMA-35 to designate them as the G0 code element.  Recent
-   revisions to the ASN.1 standards resolve this contradiction.
-
-   In practice, many implementations treat RFC 1510 GeneralStrings as if
-   they were 8-bit strings of whichever character set the implementation
-   defaults to, without regard for correct usage of character-set
-   designation escape sequences.  The default character set is often
-   determined by the current user's operating system dependent locale.
-   At least one major implementation places unescaped UTF-8 encoded
-   Unicode characters in the GeneralString.  This failure to conform to
-   the GeneralString specifications results in interoperability issues
-   when conflicting character encodings are utilized by the Kerberos
-   clients, services, and KDC.
-
-   This unfortunate situation is the result of improper documentation of
-   the restrictions of the ASN.1 GeneralString type in prior Kerberos
-   specifications.
-
-   [the following should probably be rewritten and moved into the
-   principal name section]
-
-   For compatibility, implementations MAY choose to accept GeneralString
-   values that contain characters other than those permitted by
-   IA5String, but they should be aware that character set designation
-   codes will likely be absent, and that the encoding should probably be
-   treated as locale-specific in almost every way. Implementations MAY
-   also choose to emit GeneralString values that are beyond those
-   permitted by IA5String, but should be aware that doing so is
-   extraordinarily risky from an interoperability perspective.
-
-
-
-Yu                          Expires: Aug 2004                  [Page 61]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   Some existing implementations use GeneralString to encode unescaped
-   locale-specific characters. This is a violation of the ASN.1
-   standard. Most of these implementations encode US-ASCII in the left-
-   hand half, so as long the implementation transmits only US-ASCII, the
-   ASN.1 standard is not violated in this regard. As soon as such an
-   implementation encodes unescaped locale-specific characters with the
-   high bit set, it violates the ASN.1 standard.
-
-   Other implementations have been known to use GeneralString to contain
-   a UTF-8 encoding.  This also violates the ASN.1 standard, since UTF-8
-   is a different encoding, not a 94 or 96 character "G" set as defined
-   by ISO 2022.  It is believed that these implementations do not even
-   use the ISO 2022 escape sequence to change the character encoding.
-   Even if implementations were to announce the change of encoding by
-   using that escape sequence, the ASN.1 standard prohibits the use of
-   any escape sequences other than those used to designate/invoke "G" or
-   "C" sets allowed by GeneralString.
-
-C.  Kerberos History (Informative)
-
-   [Adapted from KCLAR "BACKGROUND"]
-
-   The Kerberos model is based in part on Needham and Schroeder's
-   trusted third-party authentication protocol [NS78] and on
-   modifications suggested by Denning and Sacco [DS81].  The original
-   design and implementation of Kerberos Versions 1 through 4 was the
-   work of two former Project Athena staff members, Steve Miller of
-   Digital Equipment Corporation and Clifford Neuman (now at the
-   Information Sciences Institute of the University of Southern
-   California), along with Jerome Saltzer, Technical Director of Project
-   Athena, and Jeffrey Schiller, MIT Campus Network Manager.  Many other
-   members of Project Athena have also contributed to the work on
-   Kerberos.
-
-   Version 5 of the Kerberos protocol (described in this document) has
-   evolved from Version 4 based on new requirements and desires for
-   features not available in Version 4. The design of Version 5 of the
-   Kerberos protocol was led by Clifford Neuman and John Kohl with much
-   input from the community.  The development of the MIT reference
-   implementation was led at MIT by John Kohl and Theodore Ts'o, with
-   help and contributed code from many others. Since RFC1510 was issued,
-   extensions and revisions to the protocol have been proposed by many
-   individuals.  Some of these proposals are reflected in this document.
-   Where such changes involved significant effort, the document cites
-   the contribution of the proposer.
-
-   Reference implementations of both version 4 and version 5 of Kerberos
-   are publicly available and commercial implementations have been
-   developed and are widely used. Details on the differences between
-   Kerberos Versions 4 and 5 can be found in [KNT94].
-
-
-Yu                          Expires: Aug 2004                  [Page 62]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-Normative References
-
-   [KCRYPTO]
-
-   [RFC2119]
-
-   [X680]
-
-   [X681]
-
-   [X682]
-
-   [X683]
-
-   [X690]
-
-Informative References
-
-   [DS81]
-
-   [KCLAR]
-
-   [KNT94]
-
-   [NS78]
-
-   [RFC1510]
-
-   [RFC1964]
-
-   [ISO8859]
-
-Acknowledgments
-
-   Some stuff lifted from draft-ietf-krb-wg-kerberos-clarifications-04.
-
-Author's Address
-
-   Tom Yu
-   77 Massachusetts Ave
-   Cambridge, MA 02139
-   USA
-   tlyu@mit.edu
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-
-Yu                          Expires: Aug 2004                  [Page 63]
-
-Internet-Draft            yu-krb-extensions-00               09 Feb 2004
-
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Aug 2004                  [Page 64]
-
-
diff --git a/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-01.txt b/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-01.txt
deleted file mode 100644
index 426693193..000000000
--- a/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-01.txt
+++ /dev/null
@@ -1,5127 +0,0 @@
-INTERNET-DRAFT                                                    Tom Yu
-draft-yu-krb-wg-kerberos-extensions-01.txt                           MIT
-Expires: 19 Jan 2005                                        19 July 2004
-
-
-        The Kerberos Network Authentication Service (Version 5)
-
-
-Status of This Memo
-
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   or will be disclosed, and any of which I become aware will be
-   disclosed, in accordance with RFC 3668.
-
-
-   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."
-
-
-   The list of current Internet-Drafts can be accessed at
-
-
-      http://www.ietf.org/ietf/1id-abstracts.txt
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-
-
-      http://www.ietf.org/shadow.html
-
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-
-Abstract
-
-
-   This document describes version 5 of the Kerberos network
-   authentication protocol.  It describes changes to the protocol which
-   allow for extensions to be made to the protocol without creating
-   interoperability problems.
-
-
-Key Words for Requirements
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
-   to be interpreted as described in RFC 2119.
-
-
-
-
-
-Yu                          Expires: Jan 2005                   [Page 1]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-Table of Contents
-
-
-   Status of This Memo .......................................  1
-   Copyright Notice ..........................................  1
-   Abstract ..................................................  1
-   Key Words for Requirements ................................  1
-   Table of Contents .........................................  2
-   1.  Introduction ..........................................  4
-   1.1.  Kerberos Protocol Overview ..........................  4
-   1.2.  Overview of Document ................................  5
-   2.  Extensibility .........................................  5
-   3.  Backwards Compatibility ...............................  6
-   4.  Criticality ...........................................  6
-   5.  Use of ASN.1 in Kerberos ..............................  6
-   5.1.  Module Header .......................................  7
-   5.2.  Top-Level Type ......................................  7
-   5.3.  Previously Unused ASN.1 Notation ....................  8
-   5.3.1.  Parameterized Types ...............................  8
-   5.3.2.  COMPONENTS OF Notation ............................  8
-   5.3.3.  Constraints .......................................  8
-   5.4.  New Types ...........................................  9
-   6.  Basic Types ........................................... 10
-   6.1.  Constrained Integer Types ........................... 10
-   6.2.  KerberosTime ........................................ 11
-   6.3.  KerberosString ...................................... 11
-   7.  Principals ............................................ 11
-   7.1.  Name Types .......................................... 12
-   7.2.  Principal Type Definition ........................... 12
-   7.3.  Principal Name Reuse ................................ 13
-   7.4.  Realm Names ......................................... 13
-   7.5.  Printable Representations of Principal Names ........ 13
-   7.6.  Ticket-Granting Service Principal ................... 13
-   7.6.1.  Cross-Realm TGS Principals ........................ 14
-   8.  Types Relating to Encryption .......................... 14
-   8.1.  Assigned Numbers for Encryption ..................... 14
-   8.1.1.  EType ............................................. 14
-   8.1.2.  Key Usages ........................................ 15
-   8.2.  Which Key to Use .................................... 16
-   8.3.  EncryptionKey ....................................... 17
-   8.4.  EncryptedData ....................................... 17
-   8.5.  Checksums ........................................... 18
-   8.5.1.  ChecksumOf ........................................ 19
-   8.5.2.  Signed ............................................ 20
-   9.  Tickets ............................................... 20
-   9.1.  Timestamps .......................................... 21
-   9.2.  Ticket Flags ........................................ 21
-   9.2.1.  Flags Relating to Initial Ticket Acquisition ...... 22
-   9.2.2.  Invalid Tickets ................................... 22
-   9.2.3.  OK as Delegate .................................... 23
-   9.3.  Renewable Tickets ................................... 23
-   9.4.  Postdated Tickets ................................... 24
-
-
-Yu                          Expires: Jan 2005                   [Page 2]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   9.5.  Proxiable and Proxy Tickets ......................... 25
-   9.6.  Forwardable Tickets ................................. 26
-   9.7.  Transited Realms .................................... 27
-   9.8.  Authorization Data .................................. 27
-   9.9.  Encrypted Part of Ticket ............................ 27
-   9.10.  Cleartext Part of Ticket ........................... 28
-   10.  Credential Acquisition ............................... 28
-   10.1.  KDC-REQ ............................................ 29
-   10.2.  PA-DATA ............................................ 31
-   10.3.  KDC-REQ Processing ................................. 31
-   10.3.1.  Handling Replays ................................. 31
-   10.3.2.  Request Validation ............................... 32
-   10.3.2.1.  AS-REQ Authentication .......................... 32
-   10.3.2.2.  TGS-REQ Authentication ......................... 32
-   10.3.2.3.  Principal Validation ........................... 32
-   10.3.2.4.  Checking For Revoked or Invalid Tickets ........ 32
-   10.3.3.  Timestamp Handling ............................... 33
-   10.3.3.1.  AS-REQ Timestamp Processing .................... 33
-   10.3.3.2.  TGS-REQ Timestamp Processing ................... 34
-   10.3.4.  Handling Transited Realms ........................ 35
-   10.3.5.  Address Processing ............................... 35
-   10.3.6.  Ticket Flag Processing ........................... 35
-   10.3.7.  Key Selection .................................... 36
-   10.3.7.1.  Reply Key and Session Key Selection ............ 37
-   10.3.7.2.  Ticket Key Selection ........................... 37
-   10.4.  Reply Validation ................................... 37
-   11.  Session Key Exchange ................................. 37
-   11.1.  AP-REQ ............................................. 37
-   11.2.  AP-REP ............................................. 40
-   12.  Session Key Use ...................................... 41
-   12.1.  KRB-SAFE ........................................... 41
-   12.2.  KRB-PRIV ........................................... 42
-   12.3.  KRB-CRED ........................................... 42
-   13.  Security Considerations .............................. 43
-   13.1.  Time Synchronization ............................... 43
-   13.2.  Replays ............................................ 44
-   13.3.  Principal Name Reuse ............................... 44
-   13.4.  Password Guessing .................................. 44
-   13.5.  Forward Secrecy .................................... 44
-   13.6.  Authorization ...................................... 44
-   13.7.  Login Authentication ............................... 44
-   14.  Acknowledgments ...................................... 45
-   Appendices ................................................ 45
-   A.  ASN.1 Module (Normative) .............................. 45
-   B.  Kerberos and Character Encodings (Informative) ........ 76
-   C.  Kerberos History (Informative) ........................ 77
-   D.  Notational Differences from [KCLAR] ................... 78
-   Normative References ...................................... 79
-   Informative References .................................... 79
-   Author's Address .......................................... 80
-   Full Copyright Statement .................................. 80
-
-
-Yu                          Expires: Jan 2005                   [Page 3]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-1.  Introduction
-
-
-   The Kerberos network authentication protocol is a trusted third-party
-   protocol utilizing symmetric-key cryptography.  It assumes that all
-   communications between parties in the protocol may be arbitrarily
-   tampered with or monitored, and that the security of the overall
-   system depends only on the effectiveness of the cryptographic
-   techniques and the secrecy of the keys used.  The protocol
-   authenticates an application client's identity to an application
-   server, and likewise authenticates the application server's identity
-   to the application client.  These assurances are made possible by the
-   client and the server sharing secrets with the trusted third party:
-   the Kerberos server, also known as the Key Distribution Center (KDC).
-   In addition, the protocol establishes an ephemeral shared secret (the
-   session key) between the client and the server, allowing the
-   protection of further communications between them.
-
-
-1.1.  Kerberos Protocol Overview
-
-
-   Kerberos comprises three main sub-protocols: credentials acquisition,
-   session key exchange, and session key usage.  A client acquires
-   credentials by asking the KDC for a credential for a service; the KDC
-   issues the credential, which contains a ticket and a session key.
-   The ticket, containing the client's identity, timestamps, expiration
-   time, and a session key, is a encrypted in a key known to the
-   application server.  The KDC encrypts the credential using a key
-   known to the client, and transmits the credential to the client.
-
-
-   There are two means of requesting credentials: the Authentication
-   Service (AS) exchange, and the Ticket-Granting Service (TGS)
-   exchange.  In the typical AS exchange, a client uses a password-
-   derived key to decrypt the response.  In the TGS exchange, the KDC
-   behaves as an application, which the client authenticates to using a
-   Ticket-Granting Ticket (TGT).  The client usually obtains the TGT by
-   using the AS exchange.
-
-
-   Session key exchange consists of the client transmitting the ticket
-   to the application server, accompanied by an authenticator.  The
-   authenticator contains a timestamp and additional data encrypted
-   using the ticket's session key.  The application server decrypts the
-   ticket, extracting the session key.  The application server then uses
-   the session key to decrypt the authenticator.  Upon successful
-   decryption of the authenticator, the application server knows that
-   the data in the authenticator were sent by the client named in the
-   associated ticket.  Additionally, since authenticators expire more
-   quickly than tickets, the application server has some assurance that
-   the transaction is not a replay.  The application server may send an
-   encrypted acknowledgment to the client, verifying its identity to the
-   client.
-
-
-
-
-Yu                          Expires: Jan 2005                   [Page 4]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   Once session key exchange has occurred, the client and server may use
-   the established session key to protect further traffic.  This
-   protection may consist of protection of integrity only, or of
-   protection of confidentiality and integrity.  Additional measures
-   exist for a client to securely forward credentials to a server.
-
-
-   The entire scheme depends on loosely synchronized clocks.
-   Synchronization of the clock on the KDC with the application server
-   clock allows the application server to accurately determine whether a
-   credential is expired.  Likewise, synchronization of the clock on the
-   client with the application server clock prevents replay attacks
-   utilizing the same credential.  Careful design of the application
-   protocol may allow replay prevention without requiring client-server
-   clock synchronization.
-
-
-   After establishing a session key, application client and the
-   application server can exchange Kerberos protocol messages that use
-   the session key to protect the integrity or confidentiality of
-   communications between the client and the server.  Additionally, the
-   client may forward credentials to the application server.
-
-
-   The credentials acquisition protocol takes place over specific,
-   defined transports (UDP and TCP).  Application protocols define which
-   transport to use for the session key establishment protocol and for
-   messages using the session key; the application may choose to perform
-   its own encapsulation of the Kerberos messages, for example.
-
-
-1.2.  Overview of Document
-
-
-   The remainder of this document begins by describing the general
-   frameworks for protocol extensibility, including whether to interpret
-   unknown extensions as critical.  It then defines the protocol
-   messages and exchanges.
-
-
-   The definition of the Kerberos protocol uses Abstract Syntax Notation
-   One (ASN.1) [X680], which specifies notation for describing the
-   abstract content of protocol messages.  This document defines a
-   number of base types using ASN.1; these base types subsequently
-   appear in multiple types which define actual protocol messages.
-   Definitions of principal names and of tickets, which are central to
-   the protocol, also appear preceding the protocol message definitions.
-
-
-2.  Extensibility
-
-
-   As originally defined in RFC 1510, the Kerberos protocol does not
-   readily allow for backwards-compatible extensions to the protocol.
-   Various proposals to extend the Kerberos protocol have appeared since
-   RFC 1510, many of them creating problems for backwards compatibility.
-   This document adopts the technique of creating new extensible types
-   which encode to messages which are very similar to RFC 1510 messages
-   on the wire.  This similarity allows implementors to use shared code
-
-
-Yu                          Expires: Jan 2005                   [Page 5]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   paths for encoding and decoding both new and old messages.
-
-
-   The protocol defined in RFC 1510 already contains some elements
-   allowing for limited backwards-compatible extensions to the protocol.
-   Most of these elements consist of "typed holes"; these are octet
-   strings having associated assigned numbers indicating the intended
-   interpretation of the octet string.  This document typed holes to
-   some types which have previously lacked typed holes.  This document
-   also describes procedures for the IETF to use the extensibility model
-   of ASN.1 to make further backwards-compatible extensions of the
-   Kerberos protocol, if typed holes prove inadequate for some desired
-   extension.
-
-
-3.  Backwards Compatibility
-
-
-   This document describes two sets (for the most part) of ASN.1 types.
-   The first set of types is wire-encoding compatible with RFC 1510 and
-   [KCLAR].  The second set of types is the set of types enabling
-   extensibility.  This second set may be referred to as "extensibility-
-   enabled types". [ need to make this consistent throughout? ]
-
-
-   A major difference between the new extensibility-enabled types and
-   the types for RFC 1510 compatibility is that the extensibility-
-   enabled types allow for the use of UTF-8 encodings in various
-   character strings in the protocol.  Each party in the protocol must
-   have some knowledge of the capabilities of the other parties in the
-   protocol.  There are methods for establishing this knowledge without
-   necessarily requiring explicit configuration.
-
-
-   An extensibility-enabled client can detect whether a KDC supports the
-   extensibility-enabled types by requesting an extensibility-enabled
-   reply.  If the KDC replies with an extensibility-enabled reply, the
-   client knows that the KDC supports extensibility.  If the KDC issues
-   an extensibility-enabled ticket, the client knows that the service
-   named in the ticket is extensibility-enabled.
-
-
-4.  Criticality
-
-
-   In general, implementations SHOULD treat unknown extension, flags,
-   etc. as non-critical; i.e., they should ignore them when they do not
-   understand them.  Exceptions are clearly marked.  An implementation
-   SHOULD NOT reject a request merely because it does not understand
-   some element of the request.  As a related consequence,
-   implementations SHOULD handle talking to other implementations which
-   do not implement some requested options.  This may require designers
-   of extensions or options to provide means to detect whether
-   extensions or options are rejected, or whether such extensions or
-   options are merely not understood, or whether such extensions or
-   options are (perhaps maliciously) deleted or modified in transit.
-
-
-
-
-Yu                          Expires: Jan 2005                   [Page 6]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-5.  Use of ASN.1 in Kerberos
-
-
-   Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
-   Even though ASN.1 theoretically allows the description of protocol
-   messages to be independent of the encoding rules used to encode the
-   messages, Kerberos messages MUST be encoded with DER.  Subtleties in
-   the semantics of the notation, such as whether tags carry any
-   semantic content to the application, may cause the use of other ASN.1
-   encoding rules to be problematic.
-
-
-   Implementors not using existing ASN.1 tools (e.g., compilers or
-   support libraries) are cautioned to thoroughly read and understand
-   the actual ASN.1 specification to ensure correct implementation
-   behavior.  There is more complexity in the notation than is
-   immediately obvious, and some tutorials and guides to ASN.1 are
-   misleading or erroneous.  Recommended tutorials and guides include
-   [Dub00], [Lar99], though there is still no substitute for reading the
-   actual ASN.1 specification.
-
-
-5.1.  Module Header
-
-
-   The type definitions in this document assume an ASN.1 module
-   definition of the following form:
-
-
-      KerberosV5Spec3 {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2) modules(4) krb5spec3(4)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-
-      -- Rest of definitions here
-
-
-      END
-
-
-   This specifies that the tagging context for the module will be
-   explicit and that automatic tagging is not done.
-
-
-   Some other publications [RFC1510] [RFC1964] erroneously specify an
-   object identifier (OID) having an incorrect value of "5" for the
-   "dod" component of the OID.  In the case of RFC 1964, use of the
-   "correct" OID value would result in a change in the wire protocol;
-   therefore, the RFC 1964 OID remains unchanged for now.
-
-
-5.2.  Top-Level Type
-
-
-   The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
-   Data Units or PDUs) which an application may directly reference.
-   Applications SHOULD NOT transmit any types other than those which are
-   alternatives of the KRB-PDU CHOICE.
-
-
-
-
-
-Yu                          Expires: Jan 2005                   [Page 7]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- top-level type
-      --
-      -- Applications should not directly reference any types
-      -- other than KRB-PDU and its component types.
-      --
-      KRB-PDU         ::= CHOICE {
-          ticket      Ticket,
-          as-req      AS-REQ,
-          as-rep      AS-REP,
-          tgs-req     TGS-REQ,
-          tgs-rep     TGS-REP,
-          ap-req      AP-REQ,
-          ap-rep      AP-REP,
-          krb-safe    KRB-SAFE,
-          krb-priv    KRB-PRIV,
-          krb-cred    KRB-CRED,
-          tgt-req     TGT-REQ,
-          krb-error   KRB-ERROR,
-          ...
-      }
-
-
-
-5.3.  Previously Unused ASN.1 Notation
-
-
-   Some aspects of ASN.1 notation used in this document were not used in
-   [KCLAR], and may be unfamiliar to some readers.
-
-
-5.3.1.  Parameterized Types
-
-
-   This document uses ASN.1 parameterized types [X683] to make
-   definitions of types more readable.  For some types, some or all of
-   the parameters are advisory, i.e., they are not encoded in any form
-   for transmission in a protocol message.  These advisory parameters
-   can describe implementation behavior associated with the type.
-
-
-5.3.2.  COMPONENTS OF Notation
-
-
-   The "COMPONENTS OF" notation, used to define the RFC 1510
-   compatibility types, extracts all of the component types of an ASN.1
-   SEQUENCE type.  The extension marker (the "..." notation) and any
-   extension components are not extracted by "COMPONENTS OF".  The
-   "COMPONENTS OF" notation permits concise definition of multiple types
-   which have many components in common with each other.
-
-
-5.3.3.  Constraints
-
-
-   This document uses ASN.1 constraints, including the
-   "UserDefinedConstraint" syntax [X682].  Some constraints can be
-   handled automatically by tools that can parse them.  Uses of the
-   "UserDefinedConstraint" syntax (the "CONSTRAINED BY" syntax) will
-   typically need to have behavior manually coded; these uses provide a
-
-
-Yu                          Expires: Jan 2005                   [Page 8]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   formalized way of conveying intended implementation behavior.
-
-
-   The "WITH COMPONENTS" constraint notation allows constraints to apply
-   to component types of a SEQUENCE type.  This constraint notation
-   effectively allows constraints to "reach into" a type to constrain
-   its component types.
-
-
-5.4.  New Types
-
-
-   This document defines a number of ASN.1 types which are new since
-   RFC 1510.  The names of these types will typically have a suffix like
-   "Ext", indicating that the types are intended to support
-   extensibility.  Types original to RFC 1510 have been renamed to have
-   a suffix like "1510".  The "Ext" and "1510" types often contain a
-   number of common elements; these common elements have a suffix like
-   "Common".  The "1510" types have various ASN.1 constraints applied to
-   them; the constraints limit the possible values of the "1510" types
-   to those permitted by RFC 1510 or by [KCLAR].  The "Ext" types may
-   have different constraints, typically to force string values to be
-   sent as UTF-8.
-
-
-   For example, consider
-
-
-      -- example "common" type
-      Foo-Common      ::= SEQUENCE {
-          a           [0] INTEGER,
-          b           [1] OCTET STRING,
-          ...,
-          c           [2] INTEGER,
-          ...
-      }
-
-
-      -- example "RFC 1510 compatibility" type
-      Foo-1510        ::= SEQUENCE {
-          -- the COMPONENTS OF notation drops the extension marker
-          -- and all extension additions.
-          COMPONENTS OF Foo-Common
-      }
-
-
-      -- example "extensibility-enabled" type
-      Foo-Ext         ::= Foo-Common
-
-
-   where "Foo-Common" is a common type used to define both the "1510"
-   and "Ext" versions of a type.  "Foo-1510" is the RFC 1510 version of
-   the type, while "Foo-Ext" is the extensible version.  "Foo-1510" does
-   not contain the extension marker, nor does it contain the extension
-   component "c".  The type "Foo-1510" is equivalent to
-   "Foo-1510-Equiv", shown below.
-
-
-
-
-
-Yu                          Expires: Jan 2005                   [Page 9]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- example type equivalent to Foo-1510
-      Foo-1510-Equiv  ::= SEQUENCE {
-          a           [0] INTEGER,
-          b           [1] OCTET STRING
-      }
-
-
-
-6.  Basic Types
-
-
-   Certain ASN.1 types in Kerberos appear repeatedly in other Kerberos
-   types.
-
-
-6.1.  Constrained Integer Types
-
-
-   In RFC 1510, many types contained references to the unconstrained
-   INTEGER type.  Since an unconstrained INTEGER may contain any
-   possible abstract integer value, most of the unconstrained references
-   to INTEGER in RFC 1510 have been constrained to 32 bits or smaller.
-
-
-      -- signed values representable in 32 bits
-      --
-      -- These are often used as assigned numbers for various things.
-      Int32           ::= INTEGER (-2147483648..2147483647)
-
-
-      -- unsigned 32 bit values
-      UInt32          ::= INTEGER (0..4294967295)
-
-
-   The "Int32" type often contains an assigned number identifying the
-   type of a protocol element.  Unless otherwise stated, non-negative
-   values are registered, and negative values are available for local
-   use.
-
-
-      -- unsigned 64 bit values
-      UInt64          ::= INTEGER (0..18446744073709551615)
-
-
-   The "UInt64" type is used in places where 32 bits of precision may
-   provide inadequate security.
-
-
-      -- microseconds
-      Microseconds    ::= INTEGER (0..999999)
-
-
-
-      -- sequence numbers
-      SeqNum          ::= UInt64
-
-
-
-      -- nonces
-      Nonce           ::= UInt64
-
-
-   While these types have different abstract types from their
-   equivalents in RFC 1510, their DER encodings remain identical.
-
-
-Yu                          Expires: Jan 2005                  [Page 10]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   Nonces and sequence numbers are constrained to 32 bits in the
-   RFC 1510 backwards-compatibility types.
-
-
-6.2.  KerberosTime
-
-
-      -- must not have fractional seconds
-      KerberosTime    ::= GeneralizedTime
-
-
-   The timestamps used in Kerberos are encoded as GeneralizedTimes.  A
-   KerberosTime value MUST NOT include any fractional portions of the
-   seconds.  As required by the DER, it further MUST NOT include any
-   separators, and it specifies the UTC time zone (Z).  Example: The
-   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
-   November 1985 is "19851106210627Z".
-
-
-6.3.  KerberosString
-
-
-      -- used for names and for error messages
-      KerberosString  ::= CHOICE {
-          ia5         GeneralString (IA5String),
-          utf8        UTF8String,
-          ...         -- no extension may be sent
-                      -- to an rfc1510 implementation --
-      }
-
-
-   The KerberosString type is used for strings in various places in the
-   Kerberos protocol.  For compatibility with RFC 1510, GeneralString
-   values constrained to IA5String (US-ASCII) are permitted in messages
-   exchanged with RFC 1510 implementations.  The new protocol messages
-   contain strings encoded as UTF-8.  KerberosString values are present
-   in principal names and in error messages.  Control characters SHOULD
-   NOT be used in principal names, and used with caution in error
-   messages.
-
-
-      -- IA5 choice only; useful for constraints
-      KerberosStringIA5       ::= KerberosString
-          (WITH COMPONENTS { ia5 PRESENT })
-
-
-      -- IA5 excluded; useful for constraints
-      KerberosStringExt       ::= KerberosString
-          (WITH COMPONENTS { ia5 ABSENT })
-
-
-   KerberosStringIA5 and KerberosStringExt respectively force and forbid
-   the use of the "ia5" alternative.  These types are used as
-   constraints on other types for backwards compatibility purposes.
-
-
-   For detailed background regarding the history of character string use
-   in Kerberos, as well as discussion of some compatibility issues, see
-   Appendix B.
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 11]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-7.  Principals
-
-
-   Principals are participants in the Kerberos protocol.  A "realm"
-   consists of principals in one administrative domain, served by one
-   KDC (or one replicated set of KDCs).  Each principal name has an
-   arbitrary number of components, though typical principal names will
-   only have one or two components.  A principal name is meant to be
-   readable by and meaningful to humans, especially in a realm lacking a
-   centrally adminstered authorization infrastructure.
-
-
-7.1.  Name Types
-
-
-   Each Principal has NameType indicating what sort of name it is.  The
-   name-type SHOULD be treated as a hint.  Ignoring the name type, no
-   two names can be the same (i.e., at least one of the components, or
-   the realm, must be different).
-
-
-      -- assigned numbers for name types (used in principal names)
-      NameType        ::= Int32
-
-
-      -- Name type not known
-      nt-unknown              NameType ::= 0
-      -- Just the name of the principal as in DCE, or for users
-      nt-principal            NameType ::= 1
-      -- Service and other unique instance (krbtgt)
-      nt-srv-inst             NameType ::= 2
-      -- Service with host name as instance (telnet, rcommands)
-      nt-srv-hst              NameType ::= 3
-      -- Service with host as remaining components
-      nt-srv-xhst             NameType ::= 4
-      -- Unique ID
-      nt-uid                  NameType ::= 5
-      -- Encoded X.509 Distingished name [RFC 2253]
-      nt-x500-principal       NameType ::= 6
-      -- Name in form of SMTP email name (e.g. user@foo.com)
-      nt-smtp-name            NameType ::= 7
-      -- Enterprise name - may be mapped to principal name
-      nt-enterprise           NameType ::= 10
-
-
-
-7.2.  Principal Type Definition
-
-
-      PrincipalName   ::= SEQUENCE {
-          name-type   [0] NameType,
-          -- May have zero elements, or individual elements may be
-          -- zero-length, but this is not recommended.
-          name-string [1] SEQUENCE OF KerberosString
-      }
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 12]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   name-type
-        hint of the type of name that follows
-
-
-   name-string
-        The "name-string" encodes a sequence of components that form a
-        name, each component encoded as a KerberosString.  Taken
-        together, a PrincipalName and a Realm form a principal
-        identifier.  Most PrincipalNames will have only a few components
-        (typically one or two).
-
-
-7.3.  Principal Name Reuse
-
-
-   Realm administrators SHOULD use extreme caution when considering
-   reusing a principal name.  A service administrator might explicitly
-   enter principal names into a local access control list (ACL) for the
-   service.  If such local ACLs exist independently of a centrally
-   administered authorization infrastructure, realm administrators
-   SHOULD NOT reuse principal names until confirming that all extant ACL
-   entries referencing that principal name have been updated.  Failure
-   to perform this check can result in a security vulnerability, as a
-   new principal can inadvertently inherit unauthorized privileges upon
-   receiving a reused principal name.  An organization whose Kerberos-
-   authenticated services all use a centrally-adminstered authorization
-   infrastructure may not need to take these precautions regarding
-   principal name reuse.
-
-
-7.4.  Realm Names
-
-
-      Realm           ::= KerberosString
-
-
-      -- IA5 only
-      RealmIA5        ::= Realm (KerberosStringIA5)
-
-
-      -- IA5 excluded
-      RealmExt        ::= Realm (KerberosStringExt)
-
-
-
-   Kerberos realm names are KerberosStrings.  Realms MUST NOT contain a
-   character with the code 0 (the US-ASCII NUL).  Most realms will
-   usually consist of several components separated by periods (.), in
-   the style of Internet Domain Names, or separated by slashes (/) in
-   the style of X.500 names.
-
-
-7.5.  Printable Representations of Principal Names
-
-
-   [ perhaps non-normative? ]
-
-
-   The printable form of a principal name consists of the concatenation
-   of components of the PrincipalName value using the slash character
-   (/), followed by an at-sign (@), followed by the realm name.
-
-
-
-Yu                          Expires: Jan 2005                  [Page 13]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-7.6.  Ticket-Granting Service Principal
-
-
-   The PrincipalName value corresponding to a ticket-granting service
-   has two components: the first component is the string "krbtgt", and
-   the second component is the realm name of the TGS which will accept a
-   ticket-granting ticket having this service principal name.  The realm
-   name of service always indicates which realm issued the ticket.  A
-   ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
-   obtaining tickets in the same realm would have the following ASN.1
-   values for its "realm" and "sname" components, respectively:
-
-
-      -- Example Realm and PrincipalName for a TGS
-
-
-      tgtRealm1       Realm ::= ia5 : "A.EXAMPLE.COM"
-
-
-      tgtPrinc1       PrincipalName ::= {
-          name-type nt-srv-inst,
-          name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
-      }
-
-
-   Its printable representation would be written as
-   "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
-
-
-7.6.1.  Cross-Realm TGS Principals
-
-
-   It is possible for a principal in one realm to authenticate to a
-   service in another realm.  A KDC can issue a cross-realm ticket-
-   granting ticket to allow one of its principals to authenticate to a
-   service in a foreign realm.  For example, the TGS principal
-   "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
-   client principal in the realm A.EXAMPLE.COM to authenticate to a
-   service in the realm B.EXAMPLE.COM.  When the KDC for B.EXAMPLE.COM
-   issues a ticket to a client originating in A.EXAMPLE.COM, the
-   client's realm name remains "A.EXAMPLE.COM", even though the service
-   principal will have the realm "B.EXAMPLE.COM".
-
-
-8.  Types Relating to Encryption
-
-
-   Many Kerberos protocol messages contain encryptions of various data
-   types.  Kerberos protocol messages also contain checksums
-   (signatures) of various types.
-
-
-8.1.  Assigned Numbers for Encryption
-
-
-   Encryption algorithm identifiers and key usages both have assigned
-   numbers, described in [KCRYPTO].
-
-
-8.1.1.  EType
-
-
-   EType is the integer type for assigned numbers for encryption
-   algorithms.  Defined in [KCRYPTO].
-
-
-Yu                          Expires: Jan 2005                  [Page 14]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- Assigned numbers denoting encryption mechanisms.
-      EType ::= Int32
-
-
-      -- assigned numbers for encryption schemes
-      et-des-cbc-crc                  EType ::= 1
-      et-des-cbc-md4                  EType ::= 2
-      et-des-cbc-md5                  EType ::= 3
-      --     [reserved]                         4
-      et-des3-cbc-md5                 EType ::= 5
-      --     [reserved]                         6
-      et-des3-cbc-sha1                EType ::= 7
-      et-dsaWithSHA1-CmsOID           EType ::= 9
-      et-md5WithRSAEncryption-CmsOID  EType ::= 10
-      et-sha1WithRSAEncryption-CmsOID EType ::= 11
-      et-rc2CBC-EnvOID                EType ::= 12
-      et-rsaEncryption-EnvOID         EType ::= 13
-      et-rsaES-OAEP-ENV-OID           EType ::= 14
-      et-des-ede3-cbc-Env-OID         EType ::= 15
-      et-des3-cbc-sha1-kd             EType ::= 16
-      -- AES
-      et-aes128-cts-hmac-sha1-96      EType ::= 17
-      -- AES
-      et-aes256-cts-hmac-sha1-96      EType ::= 18
-      -- Microsoft
-      et-rc4-hmac                     EType ::= 23
-      -- Microsoft
-      et-rc4-hmac-exp                 EType ::= 24
-      -- opaque; PacketCable
-      et-subkey-keymaterial           EType ::= 65
-
-
-
-8.1.2.  Key Usages
-
-
-   KeyUsage is the integer type for assigned numbers for key usages.
-   Key usage values are inputs to the encryption and decryption
-   functions described in [KCRYPTO].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 15]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- Assigned numbers denoting key usages.
-      KeyUsage ::= UInt32
-
-
-      --
-      -- Actual identifier names are provisional and subject to
-      -- change.
-      --
-      ku-pa-enc-ts                    KeyUsage ::= 1
-      ku-Ticket                       KeyUsage ::= 2
-      ku-EncASRepPart                 KeyUsage ::= 3
-      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
-      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
-      ku-pa-TGSReq-cksum              KeyUsage ::= 6
-      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
-      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
-      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
-      ku-Authenticator-cksum          KeyUsage ::= 10
-      ku-APReq-authenticator          KeyUsage ::= 11
-      ku-EncAPRepPart                 KeyUsage ::= 12
-      ku-EncKrbPrivPart               KeyUsage ::= 13
-      ku-EncKrbCredPart               KeyUsage ::= 14
-      ku-KrbSafe-cksum                KeyUsage ::= 15
-      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
-
-
-
-      -- The following numbers are provisional...
-      -- conflicts may exist elsewhere.
-      ku-Ticket-cksum                 KeyUsage ::= 25
-      ku-ASReq-cksum                  KeyUsage ::= 26
-      ku-TGSReq-cksum                 KeyUsage ::= 27
-      ku-ASRep-cksum                  KeyUsage ::= 28
-      ku-TGSRep-cksum                 KeyUsage ::= 29
-      ku-APReq-cksum                  KeyUsage ::= 30
-      ku-APRep-cksum                  KeyUsage ::= 31
-      ku-KrbCred-cksum                KeyUsage ::= 32
-      ku-KrbError-cksum               KeyUsage ::= 33
-      ku-KDCRep-cksum                 KeyUsage ::= 34
-
-
-
-8.2.  Which Key to Use
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 16]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- KeyToUse identifies which key is to be used to encrypt or
-      -- sign a given value.
-      --
-      -- Values of KeyToUse are never actually transmitted over the
-      -- wire, or even used directly by the implementation in any
-      -- way, as key usages are; it exists primarily to identify
-      -- which key gets used for what purpose.  Thus, the specific
-      -- numeric values associated with this type are irrelevant.
-      KeyToUse        ::= ENUMERATED {
-          -- unspecified
-          key-unspecified,
-          -- server long term key
-          key-server,
-          -- client long term key
-          key-client,
-          -- key selected by KDC for encryption of a KDC-REP
-          key-kdc-rep,
-          -- session key from ticket
-          key-session,
-          -- subsession key negotiated via AP-REQ/AP-REP
-          key-subsession,
-          ...
-      }
-
-
-
-8.3.  EncryptionKey
-
-
-   The "EncryptionKey" type holds an encryption key.
-
-
-      EncryptionKey   ::= SEQUENCE {
-          keytype     [0] EType,
-          keyvalue    [1] OCTET STRING
-      }
-
-
-
-   keytype
-        This "EType" identifies the encryption algorithm, described in
-        [KCRYPTO].
-
-
-   keyvalue
-        Contains the actual key.
-
-
-8.4.  EncryptedData
-
-
-   The "EncryptedData" type contains the encryption of another data
-   type.  The recipient uses fields within EncryptedData to determine
-   which key to use for decryption.
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 17]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-
-      -- "Type" specifies which ASN.1 type is encrypted to the
-      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
-      -- keys of which one key may be used to encrypt the data.
-      -- "KeyUsages" specifies a set of key usages, one of which may
-      -- be used to encrypt.
-      --
-      -- None of the parameters is transmitted over the wire.
-      EncryptedData {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          etype       [0] EType,
-          kvno        [1] UInt32 OPTIONAL,
-          cipher      [2] OCTET STRING (CONSTRAINED BY {
-              -- must be encryption of --
-              OCTET STRING (CONTAINING Type),
-              -- with one of the keys -- KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          }),
-          ...
-      }
-
-
-
-
-   KeyUsages
-        Advisory parameter indicating which key usage to use when
-        encrypting the ciphertext.  If "KeyUsages" indicate multiple
-        "KeyUsage" values, the detailed description of the containing
-        message will indicate which key to use under which conditions.
-
-
-   Type
-        Advisory parameter indicating the ASN.1 type whose DER encoding
-        is the plaintext encrypted into the EncryptedData.
-
-
-   Keys
-        Advisory parameter indicating which key to use to perform the
-        encryption.  If "Keys" indicate multiple "KeyToUse" values, the
-        detailed description of the containing message will indicate
-        which key to use under which conditions.
-
-
-   KeyUsages
-        Advisory parameter indicating which "KeyUsage" value is used to
-        encrypt.  If "KeyUsages" indicates multiple "KeyUsage" values,
-        the detailed description of the containing message will indicate
-        which key usage to use under which conditions.
-
-
-8.5.  Checksums
-
-
-   Several types contain checksums (actually signatures) of data.
-
-
-
-Yu                          Expires: Jan 2005                  [Page 18]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      CksumType       ::= Int32
-
-
-      -- The parameters specify which key to use to produce the
-      -- signature, as well as which key usage to use.  The
-      -- parameters are not actually sent over the wire.
-      Checksum {
-          KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksumtype   [0] CksumType,
-          checksum    [1] OCTET STRING (CONSTRAINED BY {
-              -- signed using one of the keys --
-              KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          })
-      }
-
-
-
-   CksumType
-        Integer type for assigned numbers for signature algorithms.
-        Defined in [KCRYPTO]
-
-
-   Keys
-        As in EncryptedData
-
-
-   KeyUsages
-        As in EncryptedData
-
-
-   cksumtype
-        Signature algorithm used to produce the signature.
-
-
-   checksum
-        The actual checksum.
-
-
-8.5.1.  ChecksumOf
-
-
-   ChecksumOf is like "Checksum", but specifies which type is signed.
-
-
-      -- a Checksum that must contain the checksum
-      -- of a particular type
-      ChecksumOf {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
-          ...,
-          checksum (CONSTRAINED BY {
-              -- must be checksum of --
-              OCTET STRING (CONTAINING Type)
-          })
-      })
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 19]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   Type
-        Indicates the ASN.1 type whose DER encoding is signed.
-
-
-8.5.2.  Signed
-
-
-   Signed is like "ChecksumOf", but contains an actual instance of the
-   type being signed in addition to the signature.
-
-
-      -- parameterized type for wrapping authenticated plaintext
-      Signed {
-          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksum       [0] ChecksumOf {
-              InnerType, Keys, KeyUsages
-          } OPTIONAL,
-          inner       [1] InnerType,
-          ...
-      }
-
-
-
-9.  Tickets
-
-
-   [ A large number of items described here are duplicated in the
-   sections describing KDC-REQ processing.  Should find a way to avoid
-   this duplication. ]
-
-
-   A ticket binds a principal name to a session key.  The important
-   fields of a ticket are in the encrypted part.  The components in
-   common between the RFC 1510 and the extensible versions are
-
-
-      EncTicketPartCommon ::= SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] Realm,
-          cname               [3] PrincipalName,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-
-   crealm
-        This field contains the client's realm.
-
-
-   cname
-        This field contains the client's name.
-
-
-Yu                          Expires: Jan 2005                  [Page 20]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   caddr
-        This field lists the network addresses (if absent, all addresses
-        are permitted) from which the ticket is valid.
-
-
-   Descriptions of the other fields appear in the following sections.
-
-
-9.1.  Timestamps
-
-
-   Three of the ticket timestamps may be requested from the KDC.  The
-   timestamps may differ from those requested, depending on site policy.
-
-
-   authtime
-        The time at which the client authenticated, as recorded by the
-        KDC.
-
-
-   starttime
-        The earliest time when the ticket is valid.  If not present, the
-        ticket is valid starting at the authtime.  This is requested as
-        the "from" field of KDC-REQ-BODY-COMMON.
-
-
-   endtime
-        This time is requested in the "till" field of KDC-REQ-BODY-
-        COMMON.  Contains the time after which the ticket will not be
-        honored (its expiration time).  Note that individual services
-        MAY place their own limits on the life of a ticket and MAY
-        reject tickets which have not yet expired.  As such, this is
-        really an upper bound on the expiration time for the ticket.
-
-
-   renew-till
-        This time is requested in the "rtime" field of KDC-REQ-BODY-
-        COMMON.  It is only present in tickets that have the "renewable"
-        flag set in the flags field.  It indicates the maximum endtime
-        that may be included in a renewal.  It can be thought of as the
-        absolute expiration time for the ticket, including all renewals.
-
-
-9.2.  Ticket Flags
-
-
-   A number of flags may be set in the ticket, further defining some of
-   its capabilities.  Some of these flags map to flags in a KDC request.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 21]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
-
-
-      TicketFlagsBits ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          may-postdate        (5),
-          postdated           (6),
-          invalid             (7),
-          renewable           (8),
-          initial             (9),
-          pre-authent         (10),
-          hw-authent          (11),
-          transited-policy-checked (12),
-          ok-as-delegate      (13),
-          anonymous           (14),
-          cksummed-ticket     (15)
-      }
-
-
-
-9.2.1.  Flags Relating to Initial Ticket Acquisition
-
-
-   [ adapted KCLAR 2.1. ]
-
-
-   Several flags indicate the details of how the initial ticket was
-   acquired.
-
-
-   initial
-        The "initial" flag indicates that a ticket was issued using the
-        AS protocol, rather than issued based on a ticket-granting
-        ticket.  Application servers (e.g., a password-changing program)
-        requiring a client's definite knowledge of its secret key can
-        insist that this flag be set in any tickets they accept, thus
-        being assured that the client's key was recently presented to
-        the application client.
-
-
-   pre-authent
-        The "pre-authent" flag indicates that some sort of pre-
-        authentication was used during the AS exchange.
-
-
-   hw-authent
-        The "hw-authent" flag indicates that some sort of hardware-based
-        pre-authentication occurred during the AS exchange.
-
-
-   Both the "pre-authent" and the "hw-authent" flags may be present with
-   or without the "initial" flag; such tickets with the "initial" flag
-   clear are ones which are derived from initial tickets with the "pre-
-   authent" or "hw-authent" flags set.
-
-
-
-Yu                          Expires: Jan 2005                  [Page 22]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-9.2.2.  Invalid Tickets
-
-
-   [ KCLAR 2.2. ]
-
-
-   The "invalid" flag indicates that a ticket is invalid.  Application
-   servers MUST reject tickets which have this flag set.  A postdated
-   ticket will be issued in this form.  Invalid tickets MUST be
-   validated by the KDC before use, by presenting them to the KDC in a
-   TGS request with the "validate" option specified.  The KDC will only
-   validate tickets after their starttime has passed.  The validation is
-   required so that postdated tickets which have been stolen before
-   their starttime can be rendered permanently invalid (through a hot-
-   list mechanism -- see Section 10.3.2.4).
-
-
-9.2.3.  OK as Delegate
-
-
-   [ KCLAR 2.8. ]
-
-
-   The "ok-as-delegate" flag provides a way for a KDC to communicate
-   local realm policy to a client regarding whether the service for
-   which the ticket is issued is trusted to accept delegated
-   credentials.  For some applications, a client may need to delegate
-   credentials to a service to act on its behalf in contacting other
-   services.  The ability of a client to obtain a service ticket for a
-   service conveys no information to the client about whether the
-   service should be trusted to accept delegated credentials.
-
-
-   The copy of the ticket flags visible to the client may have the "ok-
-   as-delegate" flag set to indicate to the client that the service
-   specified in the ticket has been determined by policy of the realm to
-   be a suitable recipient of delegation.  A client can use the presence
-   of this flag to help it make a decision whether to delegate
-   credentials (either grant a proxy or a forwarded ticket-granting
-   ticket) to this service.  It is acceptable to ignore the value of
-   this flag.  When setting this flag, an administrator should consider
-   the security and placement of the server on which the service will
-   run, as well as whether the service requires the use of delegated
-   credentials.
-
-
-9.3.  Renewable Tickets
-
-
-   [ adapted KCLAR 2.3. ]
-
-
-   The "renewable" flag indicates whether the ticket may be renewed.
-
-
-   Renewable tickets can be used to mitigate the consequences of ticket
-   theft.  Applications may desire to hold credentials which can be
-   valid for long periods of time.  However, this can expose the
-   credentials to potential theft for equally long periods, and those
-   stolen credentials would be valid until the expiration time of the
-   ticket(s).  Simply using short-lived tickets and obtaining new ones
-
-
-Yu                          Expires: Jan 2005                  [Page 23]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   periodically would require the application to have long-term access
-   to the client's secret key, which is an even greater risk.
-
-
-   Renewable tickets have two "expiration times": the first is when the
-   current instance of the ticket expires, and the second is the latest
-   permissible value for an individual expiration time.  An application
-   client must periodically present an unexpired renewable ticket to the
-   KDC, setting the "renew" option in the KDC request.  The KDC will
-   issue a new ticket with a new session key and a later expiration
-   time.  All other fields of the ticket are left unmodified by the
-   renewal process.  When the latest permissible expiration time
-   arrives, the ticket expires permanently.  At each renewal, the KDC
-   MAY consult a hot-list to determine if the ticket had been reported
-   stolen since its last renewal; it will refuse to renew such stolen
-   tickets, and thus the usable lifetime of stolen tickets is reduced.
-
-
-   The "renewable" flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can usually be ignored by application
-   servers.  However, some particularly careful application servers MAY
-   disallow renewable tickets.
-
-
-   If a renewable ticket is not renewed by its expiration time, the KDC
-   will not renew the ticket.  The "renewable" flag is clear by default,
-   but a client can request it be set by setting the "renewable" option
-   in the AS-REQ message.  If it is set, then the "renew-till" field in
-   the ticket contains the time after which the ticket may not be
-   renewed.
-
-
-9.4.  Postdated Tickets
-
-
-   postdated
-        indicates a ticket which has been postdated
-
-
-   may-postdate
-        indicates that postdated tickets may be issued based on this
-        ticket
-
-
-   [ KCLAR 2.4. ]
-
-
-   Applications may occasionally need to obtain tickets for use much
-   later, e.g., a batch submission system would need tickets to be valid
-   at the time the batch job is serviced.  However, it is dangerous to
-   hold valid tickets in a batch queue, since they will be on-line
-   longer and more prone to theft.  Postdated tickets provide a way to
-   obtain these tickets from the KDC at job submission time, but to
-   leave them "dormant" until they are activated and validated by a
-   further request of the KDC.  If a ticket theft were reported in the
-   interim, the KDC would refuse to validate the ticket, and the thief
-   would be foiled.
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 24]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   The "may-postdate" flag in a ticket is normally only interpreted by
-   the TGS.  It can be ignored by application servers.  This flag MUST
-   be set in a ticket-granting ticket in order for the KDC to issue a
-   postdated ticket based on the presented ticket.  It is reset by
-   default; it MAY be requested by a client by setting the "allow-
-   postdate" option in the AS-REQ [?also TGS-REQ?] message.  This flag
-   does not allow a client to obtain a postdated ticket-granting ticket;
-   postdated ticket-granting tickets can only by obtained by requesting
-   the postdating in the AS-REQ message.  The life (endtime minus
-   starttime) of a postdated ticket will be the remaining life of the
-   ticket-granting ticket at the time of the request, unless the
-   "renewable" option is also set, in which case it can be the full life
-   (endtime minus starttime) of the ticket-granting ticket.  The KDC MAY
-   limit how far in the future a ticket may be postdated.
-
-
-   The "postdated" flag indicates that a ticket has been postdated.  The
-   application server can check the authtime field in the ticket to see
-   when the original authentication occurred.  Some services MAY choose
-   to reject postdated tickets, or they may only accept them within a
-   certain period after the original authentication.  When the KDC
-   issues a "postdated" ticket, it will also be marked as "invalid", so
-   that the application client MUST present the ticket to the KDC for
-   validation before use.
-
-
-9.5.  Proxiable and Proxy Tickets
-
-
-   proxy
-        indicates a proxy ticket
-
-
-   proxiable
-        indicates that proxy tickets may be issued based on this ticket
-
-
-   [ KCLAR 2.5. ]
-
-
-   It may be necessary for a principal to allow a service to perform an
-   operation on its behalf.  The service must be able to take on the
-   identity of the client, but only for a particular purpose.  A
-   principal can allow a service to take on the principal's identity for
-   a particular purpose by granting it a proxy.
-
-
-   The process of granting a proxy using the "proxy" and "proxiable"
-   flags is used to provide credentials for use with specific services.
-   Though conceptually also a proxy, users wishing to delegate their
-   identity in a form usable for all purposes MUST use the ticket
-   forwarding mechanism described in the next section to forward a
-   ticket-granting ticket.
-
-
-   The "proxiable" flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can be ignored by application servers.
-   When set, this flag tells the ticket-granting server that it is OK to
-   issue a new ticket (but not a ticket-granting ticket) with a
-
-
-Yu                          Expires: Jan 2005                  [Page 25]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   different network address based on this ticket.  This flag is set if
-   requested by the client on initial authentication.  By default, the
-   client will request that it be set when requesting a ticket-granting
-   ticket, and reset when requesting any other ticket.
-
-
-   This flag allows a client to pass a proxy to a server to perform a
-   remote request on its behalf (e.g. a print service client can give
-   the print server a proxy to access the client's files on a particular
-   file server in order to satisfy a print request).
-
-
-   In order to complicate the use of stolen credentials, Kerberos
-   tickets may contain a set of network addresses from which they are
-   valid.  When granting a proxy, the client MUST specify the new
-   network address from which the proxy is to be used, or indicate that
-   the proxy is to be issued for use from any address.
-
-
-   The "proxy" flag is set in a ticket by the TGS when it issues a proxy
-   ticket.  Application servers MAY check this flag and at their option
-   they MAY require additional authentication from the agent presenting
-   the proxy in order to provide an audit trail.
-
-
-9.6.  Forwardable Tickets
-
-
-   forwarded
-        indicates a forwarded ticket
-
-
-   forwardable
-        indicates that forwarded tickets may be issued based on this
-        ticket
-
-
-   [ KCLAR 2.6. ]
-
-
-   Authentication forwarding is an instance of a proxy where the service
-   that is granted is complete use of the client's identity.  An example
-   where it might be used is when a user logs in to a remote system and
-   wants authentication to work from that system as if the login were
-   local.
-
-
-   The "forwardable" flag in a ticket is normally only interpreted by
-   the ticket-granting service.  It can be ignored by application
-   servers.  The "forwardable" flag has an interpretation similar to
-   that of the "proxiable" flag, except ticket-granting tickets may also
-   be issued with different network addresses.  This flag is reset by
-   default, but users MAY request that it be set by setting the
-   "forwardable" option in the AS request when they request their
-   initial ticket-granting ticket.
-
-
-   This flag allows for authentication forwarding without requiring the
-   user to enter a password again.  If the flag is not set, then
-   authentication forwarding is not permitted, but the same result can
-   still be achieved if the user engages in the AS exchange specifying
-
-
-Yu                          Expires: Jan 2005                  [Page 26]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   the requested network addresses and supplies a password.
-
-
-   The "forwarded" flag is set by the TGS when a client presents a
-   ticket with the "forwardable" flag set and requests a forwarded
-   ticket by specifying the "forwarded" KDC option and supplying a set
-   of addresses for the new ticket.  It is also set in all tickets
-   issued based on tickets with the "forwarded" flag set.  Application
-   servers may choose to process "forwarded" tickets differently than
-   non-forwarded tickets.
-
-
-   If addressless tickets are forwarded from one system to another,
-   clients SHOULD still use this option to obtain a new TGT in order to
-   have different session keys on the different systems.
-
-
-9.7.  Transited Realms
-
-
-   [ KCLAR 2.7., plus new stuff ]
-
-
-9.8.  Authorization Data
-
-
-9.9.  Encrypted Part of Ticket
-
-
-   The complete definition of the encrypted part is
-
-
-      -- Encrypted part of ticket
-      EncTicketPart ::= CHOICE {
-          rfc1510     [APPLICATION 3] EncTicketPart1510,
-          ext         [APPLICATION 5] EncTicketPartExt
-      }
-
-
-
-      EncTicketPart1510 ::= SEQUENCE {
-          COMPONENTS OF EncTicketPartCommon
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-
-
-      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          crealm (RealmExt),
-          cname (PrincipalNameExt),
-          -- explicitly constrain caddr to be non-empty if present
-          caddr (SIZE (1..MAX)),
-          -- forbid empty authorization-data encodings
-          authorization-data (SIZE (1..MAX))
-      })
-
-
-Yu                          Expires: Jan 2005                  [Page 27]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-9.10.  Cleartext Part of Ticket
-
-
-      Ticket          ::= CHOICE {
-          rfc1510     [APPLICATION 1] Ticket1510,
-          ext         [APPLICATION 4] Signed {
-              TicketExt, { key-server }, { ku-Ticket-cksum }
-          }
-      }
-
-
-
-      -- takes a parameter specifying which type gets encrypted
-      TicketCommon { EncPart } ::= SEQUENCE {
-          tkt-vno     [0] INTEGER (5),
-          realm       [1] Realm,
-          sname       [2] PrincipalName,
-          enc-part    [3] EncryptedData {
-              EncPart, { key-server }, { ku-Ticket }
-          },
-          ...,
-          extensions          [4] TicketExtensions OPTIONAL,
-          ...
-      }
-
-
-
-      Ticket1510 ::= SEQUENCE {
-          COMPONENTS OF TicketCommon { EncTicketPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          realm (RealmIA5),
-          sname (PrincipalNameIA5)
-      })
-
-
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      TicketExt ::= [APPLICATION 4] TicketCommon {
-          EncTicketPartExt
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          realm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-
-10.  Credential Acquisition
-
-
-   There are two exchanges that can be used for acquiring credentials:
-   the AS exchange and the TGS exchange.  These exchanges have many
-   similarities, and this document describes them in parallel, noting
-
-
-Yu                          Expires: Jan 2005                  [Page 28]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   which behaviors are specific to one type of exchange.  The AS request
-   (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
-   (KDC-REQ).  Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
-   are forms of KDC replies (KDC-REP).
-
-
-10.1.  KDC-REQ
-
-
-   The KDC-REQ has a large number of fields in common between the RFC
-   1510 and the extensible versions.
-
-
-      KDC-REQ-COMMON  ::= SEQUENCE {
-      -- NOTE: first tag is [1], not [0]
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
-                                   | 12 -- TGS-REQ.rfc1510 --
-                                   | 6 -- AS-REQ.ext --
-                                   | 8 -- TGS-REQ.ext -- ),
-          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
-          -- NOTE: not empty
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 29]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      KDC-REQ-BODY-COMMON     ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalName OPTIONAL
-          -- Used only in AS-REQ --,
-
-
-          realm               [2] Realm
-          -- Server's realm; also client's in AS-REQ --,
-
-
-          sname               [3] PrincipalName OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime OPTIONAL
-          -- was required in rfc1510;
-          -- still required for compat versions
-          -- of messages --,
-
-
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --,
-          ...
-      }
-
-
-
-   Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of
-   an EncTicketPartCommon.  The KDC copies most of them unchanged,
-   provided that their values meet site policy.
-
-
-   kdc-options
-        These flags do not correspond directly to "flags" in
-        EncTicketPartCommon.
-
-
-   cname
-        This field is copied to the "cname" field in
-        EncTicketPartCommon.  The "cname" field is required in an AS-
-        REQ; the client places its own name here.  In a TGS-REQ, the
-        "cname" in the ticket in the AP-REQ takes precedence.
-
-
-   realm
-        This field is the server's realm, and also holds the client's
-        realm in an AS-REQ.
-
-
-
-Yu                          Expires: Jan 2005                  [Page 30]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   sname
-        The "sname" field indicates the server's name.  It may be absent
-        in a TGS-REQ which requests user-to-user authentication, in
-        which case the "sname" of the issued ticket will be taken from
-        the included additional ticket.
-
-
-   The "from", "till", and "rtime" fields correspond to the "starttime",
-   "endtime", and "renew-till" fields of EncTicketPartCommon.
-
-
-   addresses
-        This field corresponds to the "caddr" field of
-        EncTicketPartCommon.
-
-
-   enc-authorization-data
-        For TGS-REQ, this field contains authorization data encrypted
-        using either the TGT session key or the AP-REQ subsession key;
-        the KDC may copy these into the "authorization-data" field of
-        EncTicketPartCommon if policy permits.
-
-
-10.2.  PA-DATA
-
-
-   PA-DATA have multiple uses in the Kerberos protocol.  They may pre-
-   authenticate an AS-REQ; they may also modify several of the
-   encryption keys used in a KDC-REP.  PA-DATA may also provide "hints"
-   to the client about which long-term key (usually password-derived) to
-   use.  PA-DATA may also include "hints" about which pre-authentication
-   mechanisms to use, or include data for input into a pre-
-   authentication mechanism.
-
-
-10.3.  KDC-REQ Processing
-
-
-   Processing of a KDC-REQ proceeds through several steps.  An
-   implementation need not perform these steps exactly as described, as
-   long as it behaves as if the steps were performed as described.  The
-   KDC performs replay handling upon receiving the request; it then
-   validates the request, adjusts timestamps, and selects the keys used
-   in the reply.  It copies data from the request into the issued
-   ticket, adjusting the values to conform with its policies.  The KDC
-   then transmits the reply to the client.
-
-
-10.3.1.  Handling Replays
-
-
-   Because Kerberos can run over unreliable transports such as UDP, the
-   KDC MUST be prepared to retransmit responses in case they are lost.
-   If a KDC receives a request identical to one it has recently
-   successfully processed, the KDC MUST respond with a KDC-REP message
-   rather than a replay error.  In order to reduce the amount of
-   ciphertext given to a potential attacker, KDCs MAY send the same
-   response generated when the request was first handled.  KDCs MUST
-   obey this replay behavior even if the actual transport in use is
-   reliable.  If the AP-REQ which authenticates a TGS-REQ is a replay,
-
-
-Yu                          Expires: Jan 2005                  [Page 31]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   and the entire request is not identical to a recently successfully
-   processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
-   appropriate for AP-REQ processing.
-
-
-10.3.2.  Request Validation
-
-
-10.3.2.1.  AS-REQ Authentication
-
-
-   Site policy determines whether a given client principal is required
-   to provide some pre-authentication prior to receiving an AS-REP.
-   Since the default reply key is typically the client's long-term
-   password-based key, an attacker may easily request known plaintext
-   (in the form of an AS-REP) upon which to mount a dictionary attack.
-   Pre-authentication can limit the possibility of such an attack.
-
-
-   If site policy requires pre-authentication for a client principal,
-   and no pre-authentication is provided, the KDC returns the error
-   "kdc-err-preauth-required".  Accompanying this error are "e-data"
-   which include hints telling the client which pre-authentication
-   mechanisms to use, or data for input to pre-authentication mechanisms
-   (e.g., input to challenge-response systems).  If pre-authentication
-   fails, the KDC returns the error "kdc-err-preauth-failed".
-
-
-   [ may need additional changes based on Sam's preauth draft ]
-
-
-10.3.2.2.  TGS-REQ Authentication
-
-
-   A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
-   tgs-req".  The KDC MUST validate the checksum in the Authenticator of
-   the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
-   BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
-   request.  [ padata not signed by authenticator! ] Any error from the
-   AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
-   The service principal in the ticket of the AP-REQ may be a ticket-
-   granting service principal, or a normal application service
-   principal.  A ticket which is not a ticket-granting ticket MUST NOT
-   be used to issue a ticket for any service other than the one named in
-   the ticket.  In this case, the "renew", "validate", or "proxy" [?also
-   forwarded?]  option must be set in the request.
-
-
-10.3.2.3.  Principal Validation
-
-
-   If the client principal in an AS-REQ is unknown, the KDC returns the
-   error "kdc-err-c-principal-unknown".  If the server principal in a
-   KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
-   unknown".
-
-
-10.3.2.4.  Checking For Revoked or Invalid Tickets
-
-
-   [ KCLAR 3.3.3.1 ]
-
-
-
-Yu                          Expires: Jan 2005                  [Page 32]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   Whenever a request is made to the ticket-granting server, the
-   presented ticket(s) is(are) checked against a hot-list of tickets
-   which have been canceled.  This hot-list might be implemented by
-   storing a range of issue timestamps for "suspect tickets"; if a
-   presented ticket had an authtime in that range, it would be rejected.
-   In this way, a stolen ticket-granting ticket or renewable ticket
-   cannot be used to gain additional tickets (renewals or otherwise)
-   once the theft has been reported to the KDC for the realm in which
-   the server resides.  Any normal ticket obtained before it was
-   reported stolen will still be valid (because they require no
-   interaction with the KDC), but only until their normal expiration
-   time.  If TGTs have been issued for cross-realm authentication, use
-   of the cross-realm TGT will not be affected unless the hot-list is
-   propagated to the KDCs for the realms for which such cross-realm
-   tickets were issued.
-
-
-   If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
-   issue any ticket unless the TGS-REQ requests the "validate" option.
-
-
-10.3.3.  Timestamp Handling
-
-
-   [ some aspects of timestamp handling, especially regarding postdating
-   and renewal, are difficult to read in KCLAR... needs closer
-   examination here ]
-
-
-   Processing of "starttime" (requested in the "from" field) differs
-   depending on whether the "postdated" option is set in the request.
-   If the "postdated" option is not set, and the requested "starttime"
-   is in the future beyond the window of acceptable clock skew, the KDC
-   returns the error "kdc-err-cannot-postdate".  If the "postdated"
-   option is not set, and the requested "starttime" is absent or does
-   not indicate a time in the future beyond the acceptable clock skew,
-   the KDC sets the "starttime" to the KDC's current time.  The
-   "postdated" option MUST NOT be honored if the ticket is being
-   requested by TGS-REQ and the "may-postdate" is not set in the TGT.
-   Otherwise, if the "postdated" option is set, and site policy permits,
-   the KDC sets the "starttime" as requested, and sets the "invalid"
-   flag in the new ticket.
-
-
-   The "till" field is required in the RFC 1510 version of the KDC-REQ.
-   If the "till" field is equal to "19700101000000Z" (midnight, January
-   1, 1970), the KDC SHOULD behave as if the "till" field were absent.
-
-
-   The KDC MUST NOT issue a ticket whose "starttime", "endtime", or
-   "renew-till" time is later than the "renew-till" time of the ticket
-   from which it is derived.
-
-
-10.3.3.1.  AS-REQ Timestamp Processing
-
-
-   In the AS exchange, the "authtime" of a ticket is set to the local
-   time at the KDC.
-
-
-Yu                          Expires: Jan 2005                  [Page 33]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   The "endtime" of the ticket will be set to the earlier of the
-   requested "till" time and a time determined by local policy, possibly
-   determined using factors specific to the realm or principal.  For
-   example, the expiration time MAY be set to the earliest of the
-   following:
-
-
-      * the expiration time ("till" value) requested
-
-
-      * the ticket's start time plus the maximum allowable lifetime
-        associated with the client principal from the authentication
-        server's database
-
-
-      * the ticket's start time plus the maximum allowable lifetime
-        associated with the server principal
-
-
-      * the ticket's start time plus the maximum lifetime set by the
-        policy of the local realm
-
-
-   If the requested expiration time minus the start time (as determined
-   above) is less than a site-determined minimum lifetime, an error
-   message with code "kdc-err-never-valid" is returned.  If the
-   requested expiration time for the ticket exceeds what was determined
-   as above, and if the "renewable-ok" option was requested, then the
-   "renewable" flag is set in the new ticket, and the "renew-till" value
-   is set as if the "renewable" option were requested.
-
-
-   If the "renewable" option has been requested or if the "renewable-ok"
-   option has been set and a renewable ticket is to be issued, then the
-   "renew-till" field MAY be set to the earliest of:
-
-
-      * its requested value
-
-
-      * the start time of the ticket plus the minimum of the two maximum
-        renewable lifetimes associated with the principals' database
-        entries
-
-
-      * the start time of the ticket plus the maximum renewable lifetime
-        set by the policy of the local realm
-
-
-10.3.3.2.  TGS-REQ Timestamp Processing
-
-
-   In the TGS exchange, the KDC sets the "authtime" to that of the
-   ticket in the AP-REQ authenticating the TGS-REQ.  [?application
-   server can print a ticket for itself with a spoofed authtime.
-   security issues for hot-list?] [ MIT implementation may change
-   authtime of renewed tickets; needs check... ]
-
-
-   If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ
-   requests an "endtime" (in the "till" field), then the "endtime" of
-   the new ticket is set to the minimum of
-
-
-
-Yu                          Expires: Jan 2005                  [Page 34]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      * the requested "endtime" value,
-
-
-      * the "endtime" in the TGT, and
-
-
-      * an "endtime" determined by site policy on ticket lifetimes.
-
-
-   If the new ticket is a renewal, the "endtime" of the new ticket is
-   bounded by the minimum of
-
-
-      * the requested "endtime" value,
-
-
-      * the value of the "renew-till" value of the old,
-
-
-      * the "starttime" of the new ticket plus the lifetime (endtime
-        minus starttime) of the old ticket, i.e., the lifetime of the
-        new ticket may not exceed that of the ticket being renewed [
-        adapted from KCLAR 3.3.3. ], and
-
-
-      * an "endtime" determined by site policy on ticket lifetimes.
-
-
-   When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
-   a "starttime", "endtime", or "renew-till" time later than the "renew-
-   till" time of the TGT.
-
-
-10.3.4.  Handling Transited Realms
-
-
-   The KDC checks the ticket in a TGS-REQ against site policy, unless
-   the "disable-transited-check" option is set in the TGS-REQ.  If site
-   policy permits the transit path in the TGS-REQ ticket, the KDC sets
-   the "transited-policy-checked" flag in the issued ticket.  If the
-   "disable-transited-check" option is set, the issued ticket will have
-   the "transited-policy-checked" flag cleared.
-
-
-10.3.5.  Address Processing The requested "addresses" in the KDC-REQ are
-   copied into the issued ticket.  If the "addresses" field is absent or
-   empty in a TGS-REQ, the KDC copies addresses from the ticket in the
-   TGS-REQ into the issued ticket, unless the either "forwarded" or
-   "proxy" option is set.  If the "forwarded" option is set, and the
-   ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies
-   the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the
-   issued ticket.  The KDC behaves similarly if the "proxy" option is
-   set in the TGS-REQ and the "proxiable" flag is set in the ticket.
-   The "proxy" option will not be honored on requests for additional
-   ticket-granting tickets.
-
-
-10.3.6.  Ticket Flag Processing
-
-
-   Many kdc-options request that the KDC set a corresponding flag in the
-   issued ticket.  kdc-options marked with an asterisk (*) in the
-   following table do not directly request the corresponding ticket flag
-   and therefore require special handling.
-
-
-Yu                          Expires: Jan 2005                  [Page 35]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-                                     |
-                   kdc-option        |   ticket flag affected
-            -------------------------+--------------------------
-            forwardable              | forwardable
-            forwarded                | forwarded
-            proxiable                | proxiable
-            proxy                    | proxy
-            allow-postdate           | may-postdate
-            postdated                | postdated
-            renewable                | renewable
-            requestanonymous         | anonymous
-            canonicalize             | -
-            disable-transited-check* | transited-policy-checked
-            renewable-ok*            | renewable
-            enc-tkt-in-skey          | -
-            renew                    | -
-            validate*                | invalid
-
-
-
-   forwarded
-        The KDC sets the "forwarded" flag in the issued ticket if the
-        "forwarded" option is set in the TGS-REQ and the "forwardable"
-        flag is set in the TGS-REQ ticket.
-
-
-   proxy
-        The KDC sets the "proxy" flag in the issued ticket if the
-        "proxy" option is set in the TGS-REQ and the "proxiable" flag is
-        set in the TGS-REQ ticket.
-
-
-   disable-transited-check
-        The handling of the "disable-transited-check" kdc-option is
-        described in Section 10.3.4.
-
-
-   renewable-ok
-        The handling of the "renewable-ok" kdc-option is described in
-        Section 10.3.3.1.
-
-
-   validate
-        If the "validate" kdc-option is set in a TGS-REQ, and the
-        "starttime" has passed, the KDC will clear the "invalid" bit on
-        the ticket before re-issuing it.
-
-
-10.3.7.  Key Selection
-
-
-   Three keys are involved in creating a KDC-REP.  The reply key
-   encrypts the encrypted part of the KDC-REP.  The session key is
-   stored in the encrypted part of the ticket, and is also present in
-   the encrypted part of the KDC-REP so that the client can retrieve it.
-   The ticket key is used to encrypt the ticket.  These keys all have
-   initial values for a given exchange; pre-authentication and other
-   extension mechanisms may change the value used for any of these keys.
-
-
-
-Yu                          Expires: Jan 2005                  [Page 36]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   [ again, may need changes based on Sam's preauth draft ]
-
-
-10.3.7.1.  Reply Key and Session Key Selection
-
-
-   The set of encryption types which the client will understand appears
-   in the "etype" field of KDC-REQ-BODY-COMMON.  The KDC limits the set
-   of possible reply keys and the set of session key encryption types
-   based on the "etype" field.
-
-
-   For the AS exchange, the reply key is initially a long-term key of
-   the client, limited to those encryption types listed in the "etype"
-   field.  The KDC SHOULD use the first valid strong "etype" for which
-   an encryption key is available.  For the TGS exchange, the reply key
-   is initially the subsession key of the Authenticator.  If the
-   Authenticator subsesion key is absent, the reply key is initially the
-   session key of the ticket used to authenticate the TGS-REQ.
-
-
-   The session key is initially randomly generated, and has an
-   encryption type which both the client and the server will understand.
-   Typically, the KDC has prior knowledge of which encryption types the
-   server will understand.  It selects the first valid strong "etype"
-   listed the request which the server also will understand.
-
-
-10.3.7.2.  Ticket Key Selection
-
-
-   The ticket key is initially the long-term key of the service.  The
-   "enc-tkt-in-skey" option requests user-to-user authentication, where
-   the ticket encryption key of the issued ticket is set equal to the
-   session key of the additional ticket in the request.
-
-
-10.4.  Reply Validation
-
-
-11.  Session Key Exchange
-
-
-   Session key exchange consists of the AP-REQ and AP-REP messages.  The
-   client sends the AP-REQ message, and the service responds with an AP-
-   REP message if mutual authentication is desired.  Following session
-   key exchange, the client and service share a secret session key, or
-   possibly a subsesion key, which can be used to protect further
-   communications.  Additionally, the session key exchange process can
-   establish initial sequence numbers which the client and service can
-   use to detect replayed messages.
-
-
-11.1.  AP-REQ
-
-
-   An AP-REQ message contains a ticket and a authenticator.  The
-   authenticator is ciphertext encrypted with the session key contained
-   in the ticket.  The plaintext contents of the authenticator are:
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 37]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- plaintext of authenticator
-      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-          authenticator-vno   [0] INTEGER (5),
-          crealm              [1] Realm,
-          cname               [2] PrincipalName,
-          cksum               [3] Checksum {{ key-session },
-              { ku-Authenticator-cksum |
-                ku-pa-TGSReq-cksum }} OPTIONAL,
-          cusec               [4] Microseconds,
-          ctime               [5] KerberosTime,
-          subkey              [6] EncryptionKey OPTIONAL,
-          seq-number          [7] SeqNum OPTIONAL,
-          authorization-data  [8] AuthorizationData OPTIONAL
-      }
-
-
-   The common parts between the RFC 1510 and the extensible versions of
-   the AP-REQ are:
-
-
-      AP-REQ-COMMON   ::= SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14 | 18),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket,
-          authenticator       [4] EncryptedData {
-              Authenticator,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          },
-          ...,
-          extensions          [5] ApReqExtensions OPTIONAL,
-          ...
-      }
-
-
-   The complete definition of AP-REQ is:
-
-
-      AP-REQ          ::= CHOICE {
-          rfc1510     [APPLICATION 14] AP-REQ-1510,
-          ext         [APPLICATION 18] Signed {
-              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
-          }
-      }
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 38]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      AP-REQ-COMMON   ::= SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14 | 18),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket,
-          authenticator       [4] EncryptedData {
-              Authenticator,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          },
-          ...,
-          extensions          [5] ApReqExtensions OPTIONAL,
-          ...
-      }
-
-
-
-      AP-REQ-1510 ::= SEQUENCE {
-          COMPONENTS OF AP-REQ-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (14),
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmIA5),
-                  cname (PrincipalNameIA5),
-                  seqnum (UInt32)
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-
-      AP-REQ-EXT      ::= AP-REQ-COMMON
-      (WITH COMPONENTS {
-          ...,
-          msg-type (18),
-          -- The following constraints on Authenticator assume that
-          -- we want to restrict the use of AP-REQ-EXT with TicketExt
-          -- only, since that is the only way we can enforce UTF-8.
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmExt),
-                  cname (PrincipalNameExt),
-                  authorization-data (SIZE (1..MAX))
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 39]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      APOptions       ::= KerberosFlags { APOptionsBits }
-
-
-      APOptionsBits ::= BIT STRING {
-          reserved            (0),
-          use-session-key     (1),
-          mutual-required     (2)
-      }
-
-
-
-11.2.  AP-REP
-
-
-      EncAPRepPart    ::= CHOICE {
-          rfc1510     [APPLICATION 27] EncAPRepPart1510,
-          ext         [APPLICATION 31] EncAPRepPartExt
-      }
-
-
-
-      EncAPRepPartCom          ::= SEQUENCE {
-          ctime               [0] KerberosTime,
-          cusec               [1] Microseconds,
-          subkey              [2] EncryptionKey OPTIONAL,
-          seq-number          [3] SeqNum OPTIONAL,
-          ...,
-          authorization-data  [4] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-
-      EncAPRepPart1510        ::= SEQUENCE {
-          COMPONENTS OF ENCAPRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          seq-number (UInt32),
-          authorization-data ABSENT
-      })
-
-
-
-      EncAPRepPartExt         ::= EncAPRepPartCom
-
-
-
-      AP-REP          ::= CHOICE {
-          rfc1510     [APPLICATION 15] AP-REP-1510,
-          ext         [APPLICATION 19] Signed {
-              AP-REP-EXT,
-              { key-session | key-subsession }, { ku-APRep-cksum }}
-      }
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 40]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (15 | 19),
-          enc-part    [2] EncryptedData {
-              EncPart,
-              { key-session | key-subsession }, { ku-EncAPRepPart }},
-          ...,
-          extensions          [3] ApRepExtensions OPTIONAL,
-          ...
-      }
-
-
-
-      AP-REP-1510     ::= SEQUENCE {
-          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (15)
-      })
-
-
-
-      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
-          EncAPRepPartExt
-      } (WITH COMPONENTS { ..., msg-type (19) })
-
-
-
-12.  Session Key Use
-
-
-12.1.  KRB-SAFE
-
-
-      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
-      -- allow us to  make safe-body optional, allowing for a GSS-MIC
-      -- sort of message.
-      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (20),
-          safe-body   [2] KRB-SAFE-BODY,
-          cksum       [3] ChecksumOf {
-              KRB-SAFE-BODY,
-              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 41]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      KRB-SAFE-BODY   ::= SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress,
-          r-address   [5] HostAddress OPTIONAL,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-12.2.  KRB-PRIV
-
-
-      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (21),
-          enc-part    [3] EncryptedData {
-              EncKrbPrivPart,
-              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
-          ...
-      }
-
-
-
-      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress -- sender's addr --,
-          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-12.3.  KRB-CRED
-
-
-      KRB-CRED        ::= CHOICE {
-          rfc1510     [APPLICATION 22] KRB-CRED-1510,
-          ext         [APPLICATION 24] Signed {
-              KRB-CRED-EXT,
-              { key-session | key-subsession }, { ku-KrbCred-cksum }}
-      }
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 42]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      KRB-CRED-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (22 | 24),
-          tickets     [2] SEQUENCE OF Ticket,
-          enc-part    [3] EncryptedData {
-              EncKrbCredPart,
-              { key-session | key-subsession }, { ku-EncKrbCredPart }},
-          ...
-      }
-
-
-
-      KRB-CRED-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-CRED-COMMON
-      } (WITH COMPONENTS { ..., msg-type (22) })
-
-
-
-      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
-          (WITH COMPONENTS { ..., msg-type (24) })
-
-
-
-      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-          ticket-info [0] SEQUENCE OF KrbCredInfo,
-          nonce       [1] Nonce OPTIONAL,
-          timestamp   [2] KerberosTime OPTIONAL,
-          usec        [3] Microseconds OPTIONAL,
-          s-address   [4] HostAddress OPTIONAL,
-          r-address   [5] HostAddress OPTIONAL
-      }
-
-
-
-      KrbCredInfo     ::= SEQUENCE {
-          key         [0] EncryptionKey,
-          prealm      [1] Realm OPTIONAL,
-          pname       [2] PrincipalName OPTIONAL,
-          flags       [3] TicketFlags OPTIONAL,
-          authtime    [4] KerberosTime OPTIONAL,
-          starttime   [5] KerberosTime OPTIONAL,
-          endtime     [6] KerberosTime OPTIONAL,
-          renew-till  [7] KerberosTime OPTIONAL,
-          srealm      [8] Realm OPTIONAL,
-          sname       [9] PrincipalName OPTIONAL,
-          caddr       [10] HostAddresses OPTIONAL
-      }
-
-
-
-13.  Security Considerations
-
-
-13.1.  Time Synchronization
-
-
-   Time synchronization between the KDC and application servers is
-   necessary to prevent acceptance of expired tickets.
-
-
-Yu                          Expires: Jan 2005                  [Page 43]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   Time synchronization is needed between application servers and
-   clients to prevent replay attacks if a replay cache is being used.
-   If negotiated subsession keys are used to encrypt application data,
-   replay caches may not be necessary.
-
-
-13.2.  Replays
-
-
-13.3.  Principal Name Reuse
-
-
-   See Section 7.3.
-
-
-13.4.  Password Guessing
-
-
-13.5.  Forward Secrecy
-
-
-   [from KCLAR 10.; needs some rewriting]
-
-
-   The Kerberos protocol in its basic form does not provide perfect
-   forward secrecy for communications.  If traffic has been recorded by
-   an eavesdropper, then messages encrypted using the KRB-PRIV message,
-   or messages encrypted using application-specific encryption under
-   keys exchanged using Kerberos can be decrypted if any of the user's,
-   application server's, or KDC's key is subsequently discovered.  This
-   is because the session key used to encrypt such messages is
-   transmitted over the network encrypted in the key of the application
-   server, and also encrypted under the session key from the user's
-   ticket-granting ticket when returned to the user in the TGS-REP
-   message.  The session key from the ticket-granting ticket was sent to
-   the user in the AS-REP message encrypted in the user's secret key,
-   and embedded in the ticket-granting ticket, which was encrypted in
-   the key of the KDC.  Application requiring perfect forward secrecy
-   must exchange keys through mechanisms that provide such assurance,
-   but may use Kerberos for authentication of the encrypted channel
-   established through such other means.
-
-
-13.6.  Authorization
-
-
-   As an authentication service, Kerberos provides a means of verifying
-   the identity of principals on a network.  Kerberos does not, by
-   itself, provide authorization.  Applications SHOULD NOT accept the
-   mere issuance of a service ticket by the Kerberos server as granting
-   authority to use the service.
-
-
-13.7.  Login Authentication
-
-
-   Some applications, particularly those which provide login access when
-   provided with a password, SHOULD NOT treat successful acquisition of
-   credentials as sufficient proof of the user's identity.  An attacker
-   posing as a user could generate an illegitimate KDC-REP message which
-   decrypts properly.  To authenticate a user logging on to a local
-   system, the credentials obtained SHOULD be used in a TGS exchange to
-
-
-Yu                          Expires: Jan 2005                  [Page 44]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   obtain credentials for a local service.  Successful use of those
-   credentials to authenticate to the local service assures that the
-   initially obtained credentials are from a valid KDC.
-
-
-14.  Acknowledgments
-
-
-   Some stuff lifted from draft-ietf-krb-wg-kerberos-clarifications-06.
-
-
-Appendices
-
-
-A.  ASN.1 Module (Normative)
-
-
-      KerberosV5Spec3 {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2) modules(4) krb5spec3(4)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-
-
-      -- OID arc for KerberosV5
-      --
-      -- This OID may be used to identify Kerberos protocol messages
-      -- encapsulated in other protocols.
-      --
-      -- This OID also designates the OID arc for KerberosV5-related
-      -- OIDs.
-      --
-      -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
-      -- OID.
-      id-krb5         OBJECT IDENTIFIER ::= {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2)
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 45]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- top-level type
-      --
-      -- Applications should not directly reference any types
-      -- other than KRB-PDU and its component types.
-      --
-      KRB-PDU         ::= CHOICE {
-          ticket      Ticket,
-          as-req      AS-REQ,
-          as-rep      AS-REP,
-          tgs-req     TGS-REQ,
-          tgs-rep     TGS-REP,
-          ap-req      AP-REQ,
-          ap-rep      AP-REP,
-          krb-safe    KRB-SAFE,
-          krb-priv    KRB-PRIV,
-          krb-cred    KRB-CRED,
-          tgt-req     TGT-REQ,
-          krb-error   KRB-ERROR,
-          ...
-      }
-
-
-
-      --
-      -- *** basic types
-      --
-
-
-
-      -- signed values representable in 32 bits
-      --
-      -- These are often used as assigned numbers for various things.
-      Int32           ::= INTEGER (-2147483648..2147483647)
-
-
-      -- unsigned 32 bit values
-      UInt32          ::= INTEGER (0..4294967295)
-
-
-
-      -- unsigned 64 bit values
-      UInt64          ::= INTEGER (0..18446744073709551615)
-
-
-
-      -- microseconds
-      Microseconds    ::= INTEGER (0..999999)
-
-
-
-      -- sequence numbers
-      SeqNum          ::= UInt64
-
-
-
-      -- nonces
-      Nonce           ::= UInt64
-
-
-
-Yu                          Expires: Jan 2005                  [Page 46]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- must not have fractional seconds
-      KerberosTime    ::= GeneralizedTime
-
-
-
-      -- used for names and for error messages
-      KerberosString  ::= CHOICE {
-          ia5         GeneralString (IA5String),
-          utf8        UTF8String,
-          ...         -- no extension may be sent
-                      -- to an rfc1510 implementation --
-      }
-
-
-
-      -- IA5 choice only; useful for constraints
-      KerberosStringIA5       ::= KerberosString
-          (WITH COMPONENTS { ia5 PRESENT })
-
-
-      -- IA5 excluded; useful for constraints
-      KerberosStringExt       ::= KerberosString
-          (WITH COMPONENTS { ia5 ABSENT })
-
-
-
-      -- used for language tags
-      LangTag ::= PrintableString
-          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
-
-
-
-      -- assigned numbers for name types (used in principal names)
-      NameType        ::= Int32
-
-
-      -- Name type not known
-      nt-unknown              NameType ::= 0
-      -- Just the name of the principal as in DCE, or for users
-      nt-principal            NameType ::= 1
-      -- Service and other unique instance (krbtgt)
-      nt-srv-inst             NameType ::= 2
-      -- Service with host name as instance (telnet, rcommands)
-      nt-srv-hst              NameType ::= 3
-      -- Service with host as remaining components
-      nt-srv-xhst             NameType ::= 4
-      -- Unique ID
-      nt-uid                  NameType ::= 5
-      -- Encoded X.509 Distingished name [RFC 2253]
-      nt-x500-principal       NameType ::= 6
-      -- Name in form of SMTP email name (e.g. user@foo.com)
-      nt-smtp-name            NameType ::= 7
-      -- Enterprise name - may be mapped to principal name
-      nt-enterprise           NameType ::= 10
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 47]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      PrincipalName   ::= SEQUENCE {
-          name-type   [0] NameType,
-          -- May have zero elements, or individual elements may be
-          -- zero-length, but this is not recommended.
-          name-string [1] SEQUENCE OF KerberosString
-      }
-
-
-
-      -- IA5 only
-      PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS {
-          ...,
-          name-string (WITH COMPONENT (KerberosStringIA5))
-      })
-
-
-      -- IA5 excluded
-      PrincipalNameExt ::= PrincpalName (WITH COMPONENTS {
-          ...,
-          name-string (WITH COMPONENT (KerberosStringExt))
-      })
-
-
-
-      Realm           ::= KerberosString
-
-
-      -- IA5 only
-      RealmIA5        ::= Realm (KerberosStringIA5)
-
-
-      -- IA5 excluded
-      RealmExt        ::= Realm (KerberosStringExt)
-
-
-
-      -- Yet another refinement to kludge around historical
-      -- implementation bugs... we still send at least 32 bits, but
-      -- this parameterized type allows us to actually use named bit
-      -- string syntax to define flags, sort of.
-      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
-          (CONSTRAINED BY {
-          -- must be a valid value of -- NamedBits
-          -- but if the value to be sent would otherwise be shorter
-          -- than 32 bits, it must be padded with trailing zero bits
-          -- to 32 bits.  Otherwise, no trailing zero bits may be
-          -- present.
-      })
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 48]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      AddrType        ::= Int32
-
-
-      HostAddress     ::= SEQUENCE  {
-          addr-type   [0] AddrType,
-          address     [1] OCTET STRING
-      }
-
-
-      -- NOTE: HostAddresses is always used as an OPTIONAL field and
-      -- should not be a zero-length SEQUENCE OF.
-      --
-      -- The extensible messages explicitly constrain this to be
-      -- non-empty.
-      HostAddresses   ::= SEQUENCE OF HostAddress
-
-
-
-      --
-      -- *** crypto-related types and assignments
-      --
-
-
-
-      -- Assigned numbers denoting encryption mechanisms.
-      EType ::= Int32
-
-
-      -- assigned numbers for encryption schemes
-      et-des-cbc-crc                  EType ::= 1
-      et-des-cbc-md4                  EType ::= 2
-      et-des-cbc-md5                  EType ::= 3
-      --     [reserved]                         4
-      et-des3-cbc-md5                 EType ::= 5
-      --     [reserved]                         6
-      et-des3-cbc-sha1                EType ::= 7
-      et-dsaWithSHA1-CmsOID           EType ::= 9
-      et-md5WithRSAEncryption-CmsOID  EType ::= 10
-      et-sha1WithRSAEncryption-CmsOID EType ::= 11
-      et-rc2CBC-EnvOID                EType ::= 12
-      et-rsaEncryption-EnvOID         EType ::= 13
-      et-rsaES-OAEP-ENV-OID           EType ::= 14
-      et-des-ede3-cbc-Env-OID         EType ::= 15
-      et-des3-cbc-sha1-kd             EType ::= 16
-      -- AES
-      et-aes128-cts-hmac-sha1-96      EType ::= 17
-      -- AES
-      et-aes256-cts-hmac-sha1-96      EType ::= 18
-      -- Microsoft
-      et-rc4-hmac                     EType ::= 23
-      -- Microsoft
-      et-rc4-hmac-exp                 EType ::= 24
-      -- opaque; PacketCable
-      et-subkey-keymaterial           EType ::= 65
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 49]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- Assigned numbers denoting key usages.
-      KeyUsage ::= UInt32
-
-
-      --
-      -- Actual identifier names are provisional and subject to
-      -- change.
-      --
-      ku-pa-enc-ts                    KeyUsage ::= 1
-      ku-Ticket                       KeyUsage ::= 2
-      ku-EncASRepPart                 KeyUsage ::= 3
-      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
-      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
-      ku-pa-TGSReq-cksum              KeyUsage ::= 6
-      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
-      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
-      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
-      ku-Authenticator-cksum          KeyUsage ::= 10
-      ku-APReq-authenticator          KeyUsage ::= 11
-      ku-EncAPRepPart                 KeyUsage ::= 12
-      ku-EncKrbPrivPart               KeyUsage ::= 13
-      ku-EncKrbCredPart               KeyUsage ::= 14
-      ku-KrbSafe-cksum                KeyUsage ::= 15
-      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
-
-
-
-      -- The following numbers are provisional...
-      -- conflicts may exist elsewhere.
-      ku-Ticket-cksum                 KeyUsage ::= 25
-      ku-ASReq-cksum                  KeyUsage ::= 26
-      ku-TGSReq-cksum                 KeyUsage ::= 27
-      ku-ASRep-cksum                  KeyUsage ::= 28
-      ku-TGSRep-cksum                 KeyUsage ::= 29
-      ku-APReq-cksum                  KeyUsage ::= 30
-      ku-APRep-cksum                  KeyUsage ::= 31
-      ku-KrbCred-cksum                KeyUsage ::= 32
-      ku-KrbError-cksum               KeyUsage ::= 33
-      ku-KDCRep-cksum                 KeyUsage ::= 34
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 50]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- KeyToUse identifies which key is to be used to encrypt or
-      -- sign a given value.
-      --
-      -- Values of KeyToUse are never actually transmitted over the
-      -- wire, or even used directly by the implementation in any
-      -- way, as key usages are; it exists primarily to identify
-      -- which key gets used for what purpose.  Thus, the specific
-      -- numeric values associated with this type are irrelevant.
-      KeyToUse        ::= ENUMERATED {
-          -- unspecified
-          key-unspecified,
-          -- server long term key
-          key-server,
-          -- client long term key
-          key-client,
-          -- key selected by KDC for encryption of a KDC-REP
-          key-kdc-rep,
-          -- session key from ticket
-          key-session,
-          -- subsession key negotiated via AP-REQ/AP-REP
-          key-subsession,
-          ...
-      }
-
-
-
-      EncryptionKey   ::= SEQUENCE {
-          keytype     [0] EType,
-          keyvalue    [1] OCTET STRING
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 51]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-
-      -- "Type" specifies which ASN.1 type is encrypted to the
-      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
-      -- keys of which one key may be used to encrypt the data.
-      -- "KeyUsages" specifies a set of key usages, one of which may
-      -- be used to encrypt.
-      --
-      -- None of the parameters is transmitted over the wire.
-      EncryptedData {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          etype       [0] EType,
-          kvno        [1] UInt32 OPTIONAL,
-          cipher      [2] OCTET STRING (CONSTRAINED BY {
-              -- must be encryption of --
-              OCTET STRING (CONTAINING Type),
-              -- with one of the keys -- KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          }),
-          ...
-      }
-
-
-
-
-      CksumType       ::= Int32
-
-
-      -- The parameters specify which key to use to produce the
-      -- signature, as well as which key usage to use.  The
-      -- parameters are not actually sent over the wire.
-      Checksum {
-          KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksumtype   [0] CksumType,
-          checksum    [1] OCTET STRING (CONSTRAINED BY {
-              -- signed using one of the keys --
-              KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          })
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 52]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- a Checksum that must contain the checksum
-      -- of a particular type
-      ChecksumOf {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
-          ...,
-          checksum (CONSTRAINED BY {
-              -- must be checksum of --
-              OCTET STRING (CONTAINING Type)
-          })
-      })
-
-
-
-      -- parameterized type for wrapping authenticated plaintext
-      Signed {
-          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksum       [0] ChecksumOf {
-              InnerType, Keys, KeyUsages
-          } OPTIONAL,
-          inner       [1] InnerType,
-          ...
-      }
-
-
-
-      --
-      -- *** Tickets
-      --
-
-
-
-      Ticket          ::= CHOICE {
-          rfc1510     [APPLICATION 1] Ticket1510,
-          ext         [APPLICATION 4] Signed {
-              TicketExt, { key-server }, { ku-Ticket-cksum }
-          }
-      }
-
-
-
-      -- takes a parameter specifying which type gets encrypted
-      TicketCommon { EncPart } ::= SEQUENCE {
-          tkt-vno     [0] INTEGER (5),
-          realm       [1] Realm,
-          sname       [2] PrincipalName,
-          enc-part    [3] EncryptedData {
-              EncPart, { key-server }, { ku-Ticket }
-          },
-          ...,
-          extensions          [4] TicketExtensions OPTIONAL,
-          ...
-      }
-
-
-
-Yu                          Expires: Jan 2005                  [Page 53]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      Ticket1510 ::= SEQUENCE {
-          COMPONENTS OF TicketCommon { EncTicketPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          realm (RealmIA5),
-          sname (PrincipalNameIA5)
-      })
-
-
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      TicketExt ::= [APPLICATION 4] TicketCommon {
-          EncTicketPartExt
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          realm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-
-      -- Encrypted part of ticket
-      EncTicketPart ::= CHOICE {
-          rfc1510     [APPLICATION 3] EncTicketPart1510,
-          ext         [APPLICATION 5] EncTicketPartExt
-      }
-
-
-
-      EncTicketPartCommon ::= SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] Realm,
-          cname               [3] PrincipalName,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 54]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      EncTicketPart1510 ::= SEQUENCE {
-          COMPONENTS OF EncTicketPartCommon
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-
-
-      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          crealm (RealmExt),
-          cname (PrincipalNameExt),
-          -- explicitly constrain caddr to be non-empty if present
-          caddr (SIZE (1..MAX)),
-          -- forbid empty authorization-data encodings
-          authorization-data (SIZE (1..MAX))
-      })
-
-
-
-      --
-      -- *** Authorization Data
-      --
-
-
-
-      ADType          ::= Int32
-
-
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-          ad-type             [0] ADType,
-          ad-data             [1] OCTET STRING
-      }
-
-
-
-      ad-if-relevant          ADType ::= 1
-
-
-      -- Encapsulates another AuthorizationData.
-      -- Intended for application servers; receiving application servers
-      -- MAY ignore.
-      AD-IF-RELEVANT          ::= AuthorizationData
-      }
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 55]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- KDC-issued privilege attributes
-      ad-kdcissued            ADType ::= 4
-
-
-      AD-KDCIssued            ::= SEQUENCE {
-          ad-checksum [0] ChecksumOf {
-                              AuthorizationData, { key-session },
-                              { ku-ad-KDCIssued-cksum }},
-          i-realm     [1] Realm OPTIONAL,
-          i-sname     [2] PrincipalName OPTIONAL,
-          elements    [3] AuthorizationData
-      }
-
-
-
-      ad-and-or               ADType ::= 5
-
-
-      AD-AND-OR               ::= SEQUENCE {
-          condition-count     [0] INTEGER,
-          elements            [1] AuthorizationData
-      }
-
-
-
-      -- KDCs MUST interpret any AuthorizationData wrapped in this.
-      ad-mandatory-for-kdc            ADType ::= 8
-      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
-
-
-
-      TrType                  ::= Int32 -- must be registered
-
-
-      -- encoded Transited field
-      TransitedEncoding       ::= SEQUENCE {
-          tr-type     [0] TrType,
-          contents    [1] OCTET STRING
-      }
-
-
-
-      TEType                  ::= Int32
-
-
-      -- ticket extensions: for TicketExt only
-      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          te-type             [0] TEType,
-          te-data             [1] OCTET STRING
-      }
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 56]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
-
-
-      TicketFlagsBits ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          may-postdate        (5),
-          postdated           (6),
-          invalid             (7),
-          renewable           (8),
-          initial             (9),
-          pre-authent         (10),
-          hw-authent          (11),
-          transited-policy-checked (12),
-          ok-as-delegate      (13),
-          anonymous           (14),
-          cksummed-ticket     (15)
-      }
-
-
-
-      --
-      -- *** KDC protocol
-      --
-
-
-
-      AS-REQ  ::= CHOICE {
-          rfc1510     [APPLICATION 10] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (10),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          }),
-          ext         [APPLICATION 6]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as
-              -- outside, to prevent possible substitution attacks.
-              [APPLICATION 6] KDC-REQ-EXT,
-              -- not sure this is correct key to use; do we even want
-              -- to sign AS-REQ?
-              { key-client },
-              { ku-ASReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (6),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          })
-      }
-
-
-Yu                          Expires: Jan 2005                  [Page 57]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      TGS-REQ ::= CHOICE {
-          rfc1510     [APPLICATION 12] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (12),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          }),
-          ext         [APPLICATION 8]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as
-              -- outside, to prevent possible substitution attacks.
-              [APPLICATION 8] KDC-REQ-EXT,
-              { key-session }, { ku-TGSReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (8),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          })
-      }
-
-
-
-      KDC-REQ-COMMON  ::= SEQUENCE {
-      -- NOTE: first tag is [1], not [0]
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
-                                   | 12 -- TGS-REQ.rfc1510 --
-                                   | 6 -- AS-REQ.ext --
-                                   | 8 -- TGS-REQ.ext -- ),
-          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
-          -- NOTE: not empty
-      }
-
-
-
-      KDC-REQ-1510    ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-1510
-      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 58]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      KDC-REQ-EXT     ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-EXT,
-          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
-                              LangTag OPTIONAL,
-          ...
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (6 | 8),
-          padata (SIZE (1..MAX))
-      })
-
-
-
-      KDC-REQ-BODY-COMMON     ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalName OPTIONAL
-          -- Used only in AS-REQ --,
-
-
-          realm               [2] Realm
-          -- Server's realm; also client's in AS-REQ --,
-
-
-          sname               [3] PrincipalName OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime OPTIONAL
-          -- was required in rfc1510;
-          -- still required for compat versions
-          -- of messages --,
-
-
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --,
-          ...
-      }
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 59]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      KDC-REQ-BODY-1510 ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-BODY-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          cname (PrincipalNameIA5),
-          realm (RealmIA5),
-          sname (PrincipalNameIA5),
-          till PRESENT,
-          nonce (UInt32)
-      })
-
-
-
-      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
-      (WITH COMPONENTS {
-          ...,
-          cname (PrincipalNameExt),
-          realm (RealmExt),
-          sname (PrincipalNameExt),
-          addresses (SIZE (1..MAX)),
-          enc-authorization-data (EncryptedData {
-              AuthorizationData (SIZE (1..MAX)),
-              { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          }),
-          additional-tickets (SIZE (1..MAX))
-      })
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 60]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
-      KDCOptionsBits ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          allow-postdate      (5),
-          postdated           (6),
-          unused7             (7),
-          renewable           (8),
-          unused9             (9),
-          unused10            (10),
-          unused11            (11),
-          unused12            (12),
-          unused13            (13),
-          requestanonymous    (14),
-          canonicalize        (15),
-          disable-transited-check (26),
-          renewable-ok        (27),
-          enc-tkt-in-skey     (28),
-          renew               (30),
-          validate            (31)
-          -- XXX need "need ticket1" flag?
-      }
-
-
-
-      AS-REP          ::= CHOICE {
-          rfc1510     [APPLICATION 11] KDC-REP-1510 {
-              EncASRepPart1510
-          } (WITH COMPONENTS { ..., msg-type (11) }),
-          ext         [APPLICATION  7]  Signed {
-              [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
-              { key-reply }, { ku-ASRep-cksum }
-          } (WITH COMPONENTS { ..., msg-type (7) })
-      }
-
-
-
-      TGS-REP         ::= CHOICE {
-          rfc1510     [APPLICATION 13] KDC-REP-1510 {
-              EncTGSRepPart1510
-          } (WITH COMPONENTS { ..., msg-type (13) }),
-          ext         [APPLICATION  9]  Signed {
-              [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
-              { key-reply }, { ku-TGSRep-cksum }
-          } (WITH COMPONENTS { ..., msg-type (9) })
-      }
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 61]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
-                                   13 -- TGS.rfc1510 -- |
-                                   7 -- AS-REP.ext -- |
-                                   9 -- TGS-REP.ext -- ),
-          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
-          crealm      [3] Realm,
-          cname       [4] PrincipalName,
-          ticket      [5] Ticket,
-          enc-part    [6] EncryptedData {
-              EncPart,
-              { key-reply },
-              -- maybe reach into EncryptedData in AS-REP/TGS-REP
-              -- definitions to apply constraints on key usages?
-              { ku-EncASRepPart -- if AS-REP -- |
-                ku-EncTGSRepPart-subkey -- if TGS-REP and
-                                        -- using Authenticator
-                                        -- session key -- |
-                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
-                                         -- subsession key -- }
-          },
-          ...,
-          -- In extensible version, KDC signs original request
-          -- to avoid replay attacks agaginst client.
-          req-cksum   [7] ChecksumOf { CHOICE {
-              as-req          AS-REQ,
-              tgs-req         TGS-REQ
-          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
-          lang-tag    [8] LangTag OPTIONAL,
-          ...
-      }
-
-
-
-      KDC-REP-1510 { EncPart } ::= SEQUENCE {
-          COMPONENTS OF KDC-REP-COMMON { EncPart }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (11 | 13),
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-
-
-      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
-      (WITH COMPONENTS {
-          ...,
-          msg-type (7 | 9),
-          crealm (RealmExt),
-          cname (PrincipalNameExt)
-      })
-
-
-Yu                          Expires: Jan 2005                  [Page 62]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
-      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
-
-
-      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
-      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
-
-
-      EncKDCRepPartCom        ::= SEQUENCE {
-          key                 [0] EncryptionKey,
-          last-req            [1] LastReq,
-          nonce               [2] Nonce,
-          key-expiration      [3] KerberosTime OPTIONAL,
-          flags               [4] TicketFlags,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          srealm              [9] Realm,
-          sname               [10] PrincipalName,
-          caddr               [11] HostAddresses OPTIONAL,
-          ...
-      }
-
-
-      EncKDCRepPart1510       ::= SEQUENCE {
-          COMPONENTS OF EncKDCRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          srealm (RealmIA5),
-          sname (PrincipalNameIA5),
-          nonce UInt32 })
-
-
-      EncKdcRepPartExt        ::= EncKDCRepPartCom (WITH COMPONENTS {
-          ...,
-          srealm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-
-      LRType          ::=     Int32
-      LastReq         ::=     SEQUENCE OF SEQUENCE {
-          lr-type     [0] LRType,
-          lr-value    [1] KerberosTime
-      }
-
-
-
-      --
-      -- *** preauth
-      --
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 63]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      PaDataType      ::= Int32
-      PaDataOID       ::= RELATIVE-OID
-
-
-      PA-DATA ::= SEQUENCE {
-          -- NOTE: first tag is [1], not [0]
-          padata-type         [1] CHOICE {
-                              int     PaDataType,
-                              -- example of possible use
-                              -- of RELATIVE-OIDs
-                              oid     PaDataOID
-          },
-          padata-value        [2] OCTET STRING
-      }
-
-
-
-      PaDataSet PADATA-OBJ ::= {
-          pa-tgs-req |
-          pa-enc-timestamp |
-          pa-etype-info |
-          pa-etype-info2 |
-          pa-pw-salt |
-          pa-as-req ,
-          ...
-      }
-
-
-
-      -- AP-REQ authenticating a TGS-REQ
-      pa-tgs-req              PaDataType ::= 1
-      PA-TGS-REQ              ::= AP-REQ
-
-
-
-      -- Encrypted timestamp preauth
-      -- Encryption key used is client's long-term key.
-      pa-enc-timestamp        PaDataType ::= 2
-
-
-      PA-ENC-TIMESTAMP ::= EncryptedData {
-          PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
-      }
-
-
-      PA-ENC-TS-ENC           ::= SEQUENCE {
-              patimestamp     [0] KerberosTime -- client's time --,
-              pausec          [1] Microseconds OPTIONAL
-      }
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 64]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- Hints returned in AS-REP or KRB-ERROR to help client
-      -- choose a password-derived key, either for preauthentication
-      -- or for decryption of the reply.
-      pa-etype-info           PaDataType ::= 11
-
-
-      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
-
-
-      ETYPE-INFO-ENTRY        ::= SEQUENCE {
-              etype           [0] EType,
-              salt            [1] OCTET STRING OPTIONAL
-      }
-
-
-
-      -- Similar to etype-info, but with parameters provided for
-      -- the string-to-key function.
-      pa-etype-info2          PaDataType ::= 19
-
-
-      ETYPE-INFO2             ::= SEQUENCE (SIZE (1..MAX))
-                                      OF ETYPE-INFO-ENTRY
-
-
-      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
-              etype           [0] EType,
-              salt            [1] KerberosString OPTIONAL,
-              s2kparams       [2] OCTET STRING OPTIONAL
-      }
-
-
-
-      -- Obsolescent.  Salt for client's long-term key.
-      -- Its character encoding is unspecified.
-      pa-pw-salt              PaDataType ::= 3
-      -- The "padata-value" does not encode an ASN.1 type.
-      -- Instead, "padata-value" must consist of the salt string to
-      -- be used by the client, in an unspecified character
-      -- encoding.
-      }
-
-
-
-      -- An extensible AS-REQ may be sent as a padata in a
-      -- non-extensible AS-REQ to allow for backwards compatibility.
-      pa-as-req               PaDataType ::= 42 -- provisional
-      PA-AS-REQ               ::= AS-REQ (WITH COMPONENTS ext)
-
-
-
-      --
-      -- *** Session key exchange
-      --
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 65]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      AP-REQ          ::= CHOICE {
-          rfc1510     [APPLICATION 14] AP-REQ-1510,
-          ext         [APPLICATION 18] Signed {
-              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
-          }
-      }
-
-
-
-      AP-REQ-COMMON   ::= SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14 | 18),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket,
-          authenticator       [4] EncryptedData {
-              Authenticator,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          },
-          ...,
-          extensions          [5] ApReqExtensions OPTIONAL,
-          ...
-      }
-
-
-
-      AP-REQ-1510 ::= SEQUENCE {
-          COMPONENTS OF AP-REQ-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (14),
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmIA5),
-                  cname (PrincipalNameIA5),
-                  seqnum (UInt32)
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 66]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      AP-REQ-EXT      ::= AP-REQ-COMMON
-      (WITH COMPONENTS {
-          ...,
-          msg-type (18),
-          -- The following constraints on Authenticator assume that
-          -- we want to restrict the use of AP-REQ-EXT with TicketExt
-          -- only, since that is the only way we can enforce UTF-8.
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmExt),
-                  cname (PrincipalNameExt),
-                  authorization-data (SIZE (1..MAX))
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-
-      ApReqExtType    ::= Int32
-
-
-      ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          apReqExt-Type       [0] ApReqExtType,
-          apReqExt-Data       [1] OCTET STRING
-      }
-
-
-
-      APOptions       ::= KerberosFlags { APOptionsBits }
-
-
-      APOptionsBits ::= BIT STRING {
-          reserved            (0),
-          use-session-key     (1),
-          mutual-required     (2)
-      }
-
-
-
-      -- plaintext of authenticator
-      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-          authenticator-vno   [0] INTEGER (5),
-          crealm              [1] Realm,
-          cname               [2] PrincipalName,
-          cksum               [3] Checksum {{ key-session },
-              { ku-Authenticator-cksum |
-                ku-pa-TGSReq-cksum }} OPTIONAL,
-          cusec               [4] Microseconds,
-          ctime               [5] KerberosTime,
-          subkey              [6] EncryptionKey OPTIONAL,
-          seq-number          [7] SeqNum OPTIONAL,
-          authorization-data  [8] AuthorizationData OPTIONAL
-      }
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 67]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      AP-REP          ::= CHOICE {
-          rfc1510     [APPLICATION 15] AP-REP-1510,
-          ext         [APPLICATION 19] Signed {
-              AP-REP-EXT,
-              { key-session | key-subsession }, { ku-APRep-cksum }}
-      }
-
-
-
-      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (15 | 19),
-          enc-part    [2] EncryptedData {
-              EncPart,
-              { key-session | key-subsession }, { ku-EncAPRepPart }},
-          ...,
-          extensions          [3] ApRepExtensions OPTIONAL,
-          ...
-      }
-
-
-
-      AP-REP-1510     ::= SEQUENCE {
-          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (15)
-      })
-
-
-
-      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
-          EncAPRepPartExt
-      } (WITH COMPONENTS { ..., msg-type (19) })
-
-
-
-      ApRepExtType    ::= Int32
-
-
-      ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          apRepExt-Type       [0] ApRepExtType,
-          apRepExt-Data       [1] OCTET STRING
-      }
-
-
-
-      EncAPRepPart    ::= CHOICE {
-          rfc1510     [APPLICATION 27] EncAPRepPart1510,
-          ext         [APPLICATION 31] EncAPRepPartExt
-      }
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 68]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      EncAPRepPart1510        ::= SEQUENCE {
-          COMPONENTS OF ENCAPRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          seq-number (UInt32),
-          authorization-data ABSENT
-      })
-
-
-
-      EncAPRepPartExt         ::= EncAPRepPartCom
-
-
-
-      EncAPRepPartCom          ::= SEQUENCE {
-          ctime               [0] KerberosTime,
-          cusec               [1] Microseconds,
-          subkey              [2] EncryptionKey OPTIONAL,
-          seq-number          [3] SeqNum OPTIONAL,
-          ...,
-          authorization-data  [4] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-
-      --
-      -- *** Application messages
-      --
-
-
-
-      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
-      -- allow us to  make safe-body optional, allowing for a GSS-MIC
-      -- sort of message.
-      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (20),
-          safe-body   [2] KRB-SAFE-BODY,
-          cksum       [3] ChecksumOf {
-              KRB-SAFE-BODY,
-              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 69]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      KRB-SAFE-BODY   ::= SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress,
-          r-address   [5] HostAddress OPTIONAL,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (21),
-          enc-part    [3] EncryptedData {
-              EncKrbPrivPart,
-              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
-          ...
-      }
-
-
-
-      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress -- sender's addr --,
-          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-      KRB-CRED        ::= CHOICE {
-          rfc1510     [APPLICATION 22] KRB-CRED-1510,
-          ext         [APPLICATION 24] Signed {
-              KRB-CRED-EXT,
-              { key-session | key-subsession }, { ku-KrbCred-cksum }}
-      }
-
-
-
-      KRB-CRED-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (22 | 24),
-          tickets     [2] SEQUENCE OF Ticket,
-          enc-part    [3] EncryptedData {
-              EncKrbCredPart,
-              { key-session | key-subsession }, { ku-EncKrbCredPart }},
-          ...
-      }
-
-
-Yu                          Expires: Jan 2005                  [Page 70]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      KRB-CRED-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-CRED-COMMON
-      } (WITH COMPONENTS { ..., msg-type (22) })
-
-
-
-      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
-          (WITH COMPONENTS { ..., msg-type (24) })
-
-
-
-      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-          ticket-info [0] SEQUENCE OF KrbCredInfo,
-          nonce       [1] Nonce OPTIONAL,
-          timestamp   [2] KerberosTime OPTIONAL,
-          usec        [3] Microseconds OPTIONAL,
-          s-address   [4] HostAddress OPTIONAL,
-          r-address   [5] HostAddress OPTIONAL
-      }
-
-
-
-      KrbCredInfo     ::= SEQUENCE {
-          key         [0] EncryptionKey,
-          prealm      [1] Realm OPTIONAL,
-          pname       [2] PrincipalName OPTIONAL,
-          flags       [3] TicketFlags OPTIONAL,
-          authtime    [4] KerberosTime OPTIONAL,
-          starttime   [5] KerberosTime OPTIONAL,
-          endtime     [6] KerberosTime OPTIONAL,
-          renew-till  [7] KerberosTime OPTIONAL,
-          srealm      [8] Realm OPTIONAL,
-          sname       [9] PrincipalName OPTIONAL,
-          caddr       [10] HostAddresses OPTIONAL
-      }
-
-
-
-      TGT-REQ         ::= [APPLICATION 16] SEQUENCE {
-          pvno            [0] INTEGER (5),
-          msg-type        [1] INTEGER (16),
-          sname           [2] PrincipalName OPTIONAL,
-          srealm          [3] Realm OPTIONAL,
-          ...
-      }
-
-
-
-      --
-      -- *** Error messages
-      --
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 71]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      ErrCode ::= Int32
-
-
-      KRB-ERROR       ::= CHOICE {
-          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
-          ext         [APPLICATION 23] Signed {
-              KRB-ERROR-EXT, { ku-KrbError-cksum } }
-      }
-
-
-
-      KRB-ERROR-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (30 | 23),
-          ctime       [2] KerberosTime OPTIONAL,
-          cusec       [3] Microseconds OPTIONAL,
-          stime       [4] KerberosTime,
-          susec       [5] Microseconds,
-          error-code  [6] ErrCode,
-          crealm      [7] Realm OPTIONAL,
-          cname       [8] PrincipalName OPTIONAL,
-          realm       [9] Realm -- Correct realm --,
-          sname       [10] PrincipalName -- Correct name --,
-          e-text      [11] KerberosString OPTIONAL,
-          e-data      [12] OCTET STRING OPTIONAL,
-          ...,
-          typed-data          [13] TYPED-DATA OPTIONAL,
-          nonce               [14] Nonce OPTIONAL,
-          lang-tag            [15] LangTag OPTIONAL,
-          ...
-      }
-
-
-
-      KRB-ERROR-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-ERROR-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (30)
-      })
-
-
-
-      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
-          (WITH COMPONENTS { ..., msg-type (23) })
-
-
-
-      TDType ::= Int32
-
-
-      TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-          data-type   [0] TDType,
-          data-value  [1] OCTET STRING OPTIONAL
-      }
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 72]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      --
-      -- *** Error codes
-      --
-
-
-      -- No error
-      kdc-err-none                          ErrCode ::= 0
-      -- Client's entry in database has expired
-      kdc-err-name-exp                      ErrCode ::= 1
-      -- Server's entry in database has expired
-      kdc-err-service-exp                   ErrCode ::= 2
-      -- Requested protocol version number not supported
-      kdc-err-bad-pvno                      ErrCode ::= 3
-      -- Client's key encrypted in old master key
-      kdc-err-c-old-mast-kvno               ErrCode ::= 4
-      -- Server's key encrypted in old master key
-      kdc-err-s-old-mast-kvno               ErrCode ::= 5
-      -- Client not found in Kerberos database
-      kdc-err-c-principal-unknown           ErrCode ::= 6
-      -- Server not found in Kerberos database
-      kdc-err-s-principal-unknown           ErrCode ::= 7
-      -- Multiple principal entries in database
-      kdc-err-principal-not-unique          ErrCode ::= 8
-      -- The client or server has a null key
-      kdc-err-null-key                      ErrCode ::= 9
-      -- Ticket not eligible for postdating
-      kdc-err-cannot-postdate               ErrCode ::= 10
-      -- Requested start time is later than end time
-      kdc-err-never-valid                   ErrCode ::= 11
-      -- KDC policy rejects request
-      kdc-err-policy                        ErrCode ::= 12
-      -- KDC cannot accommodate requested option
-      kdc-err-badoption                     ErrCode ::= 13
-      -- KDC has no support for encryption type
-      kdc-err-etype-nosupp                  ErrCode ::= 14
-      -- KDC has no support for checksum type
-      kdc-err-sumtype-nosupp                ErrCode ::= 15
-      -- KDC has no support for padata type
-      kdc-err-padata-type-nosupp            ErrCode ::= 16
-      -- KDC has no support for transited type
-      kdc-err-trtype-nosupp                 ErrCode ::= 17
-      -- Clients credentials have been revoked
-      kdc-err-client-revoked                ErrCode ::= 18
-      -- Credentials for server have been revoked
-      kdc-err-service-revoked               ErrCode ::= 19
-      -- TGT has been revoked
-      kdc-err-tgt-revoked                   ErrCode ::= 20
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 73]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- Client not yet valid - try again later
-      kdc-err-client-notyet                 ErrCode ::= 21
-      -- Server not yet valid - try again later
-      kdc-err-service-notyet                ErrCode ::= 22
-      -- Password has expired - change password to reset
-      kdc-err-key-expired                   ErrCode ::= 23
-      -- Pre-authentication information was invalid
-      kdc-err-preauth-failed                ErrCode ::= 24
-      -- Additional pre-authenticationrequired
-      kdc-err-preauth-required              ErrCode ::= 25
-      -- Requested server and ticket don't match
-      kdc-err-server-nomatch                ErrCode ::= 26
-      -- Server principal valid for user2user only
-      kdc-err-must-use-user2user            ErrCode ::= 27
-      -- KDC Policy rejects transited path
-      kdc-err-path-not-accpeted             ErrCode ::= 28
-      -- A service is not available
-      kdc-err-svc-unavailable               ErrCode ::= 29
-      -- Integrity check on decrypted field failed
-      krb-ap-err-bad-integrity              ErrCode ::= 31
-      -- Ticket expired
-      krb-ap-err-tkt-expired                ErrCode ::= 32
-      -- Ticket not yet valid
-      krb-ap-err-tkt-nyv                    ErrCode ::= 33
-      -- Request is a replay
-      krb-ap-err-repeat                     ErrCode ::= 34
-      -- The ticket isn't for us
-      krb-ap-err-not-us                     ErrCode ::= 35
-      -- Ticket and authenticator don't match
-      krb-ap-err-badmatch                   ErrCode ::= 36
-      -- Clock skew too great
-      krb-ap-err-skew                       ErrCode ::= 37
-      -- Incorrect net address
-      krb-ap-err-badaddr                    ErrCode ::= 38
-      -- Protocol version mismatch
-      krb-ap-err-badversion                 ErrCode ::= 39
-      -- Invalid msg type
-      krb-ap-err-msg-type                   ErrCode ::= 40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 74]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- Message stream modified
-      krb-ap-err-modified                   ErrCode ::= 41
-      -- Message out of order
-      krb-ap-err-badorder                   ErrCode ::= 42
-      -- Specified version of key is not available
-      krb-ap-err-badkeyver                  ErrCode ::= 44
-      -- Service key not available
-      krb-ap-err-nokey                      ErrCode ::= 45
-      -- Mutual authentication failed
-      krb-ap-err-mut-fail                   ErrCode ::= 46
-      -- Incorrect message direction
-      krb-ap-err-baddirection               ErrCode ::= 47
-      -- Alternative authentication method required
-      krb-ap-err-method                     ErrCode ::= 48
-      -- Incorrect sequence number in message
-      krb-ap-err-badseq                     ErrCode ::= 49
-      -- Inappropriate type of checksum in message
-      krb-ap-err-inapp-cksum                ErrCode ::= 50
-      -- Policy rejects transited path
-      krb-ap-path-not-accepted              ErrCode ::= 51
-      -- Response too big for UDP, retry with TCP
-      krb-err-response-too-big              ErrCode ::= 52
-      -- Generic error (description in e-text)
-      krb-err-generic                       ErrCode ::= 60
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 75]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-      -- Field is too long for this implementation
-      krb-err-field-toolong                 ErrCode ::= 61
-      -- Reserved for PKINIT
-      kdc-error-client-not-trusted          ErrCode ::= 62
-      -- Reserved for PKINIT
-      kdc-error-kdc-not-trusted             ErrCode ::= 63
-      -- Reserved for PKINIT
-      kdc-error-invalid-sig                 ErrCode ::= 64
-      -- Reserved for PKINIT
-      kdc-err-key-too-weak                  ErrCode ::= 65
-      -- Reserved for PKINIT
-      kdc-err-certificate-mismatch          ErrCode ::= 66
-      -- No TGT available to validate USER-TO-USER
-      krb-ap-err-no-tgt                     ErrCode ::= 67
-      -- USER-TO-USER TGT issued different KDC
-      kdc-err-wrong-realm                   ErrCode ::= 68
-      -- Ticket must be for USER-TO-USER
-      krb-ap-err-user-to-user-required      ErrCode ::= 69
-      -- Reserved for PKINIT
-      kdc-err-cant-verify-certificate       ErrCode ::= 70
-      -- Reserved for PKINIT
-      kdc-err-invalid-certificate           ErrCode ::= 71
-      -- Reserved for PKINIT
-      kdc-err-revoked-certificate           ErrCode ::= 72
-      -- Reserved for PKINIT
-      kdc-err-revocation-status-unknown     ErrCode ::= 73
-      -- Reserved for PKINIT
-      kdc-err-revocation-status-unavailable ErrCode ::= 74
-
-
-
-      END
-
-
-
-B.  Kerberos and Character Encodings (Informative)
-
-
-   [adapted from KCLAR 5.2.1]
-
-
-   The original specification of the Kerberos protocol in RFC 1510 uses
-   GeneralString in numerous places for human-readable string data.
-   Historical implementations of Kerberos cannot utilize the full power
-   of GeneralString.  This ASN.1 type requires the use of designation
-   and invocation escape sequences as specified in ISO 2022 | ECMA-35
-   [ISO2022] to switch character sets, and the default character set
-   that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
-   International Reference Version (IRV) (aka U.S. ASCII), which mostly
-   works.
-
-
-   ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3)
-   and two Control-function code elements (C0..C1).  DER previously
-   [X690-1997] prohibited the designation of character sets as any but
-   the G0 and C0 sets.  This had the side effect of prohibiting the use
-
-
-Yu                          Expires: Jan 2005                  [Page 76]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any
-   other character-sets that utilize a 96-character set, since it is
-   prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code
-   element.  Recent revisions to the ASN.1 standards resolve this
-   contradiction.
-
-
-   In practice, many implementations treat RFC 1510 GeneralStrings as if
-   they were 8-bit strings of whichever character set the implementation
-   defaults to, without regard for correct usage of character-set
-   designation escape sequences.  The default character set is often
-   determined by the current user's operating system dependent locale.
-   At least one major implementation places unescaped UTF-8 encoded
-   Unicode characters in the GeneralString.  This failure to conform to
-   the GeneralString specifications results in interoperability issues
-   when conflicting character encodings are utilized by the Kerberos
-   clients, services, and KDC.
-
-
-   This unfortunate situation is the result of improper documentation of
-   the restrictions of the ASN.1 GeneralString type in prior Kerberos
-   specifications.
-
-
-   [the following should probably be rewritten and moved into the
-   principal name section]
-
-
-   For compatibility, implementations MAY choose to accept GeneralString
-   values that contain characters other than those permitted by
-   IA5String, but they should be aware that character set designation
-   codes will likely be absent, and that the encoding should probably be
-   treated as locale-specific in almost every way.  Implementations MAY
-   also choose to emit GeneralString values that are beyond those
-   permitted by IA5String, but should be aware that doing so is
-   extraordinarily risky from an interoperability perspective.
-
-
-   Some existing implementations use GeneralString to encode unescaped
-   locale-specific characters.  This is a violation of the ASN.1
-   standard.  Most of these implementations encode US-ASCII in the left-
-   hand half, so as long the implementation transmits only US-ASCII, the
-   ASN.1 standard is not violated in this regard.  As soon as such an
-   implementation encodes unescaped locale-specific characters with the
-   high bit set, it violates the ASN.1 standard.
-
-
-   Other implementations have been known to use GeneralString to contain
-   a UTF-8 encoding.  This also violates the ASN.1 standard, since UTF-8
-   is a different encoding, not a 94 or 96 character "G" set as defined
-   by ISO 2022.  It is believed that these implementations do not even
-   use the ISO 2022 escape sequence to change the character encoding.
-   Even if implementations were to announce the change of encoding by
-   using that escape sequence, the ASN.1 standard prohibits the use of
-   any escape sequences other than those used to designate/invoke "G" or
-   "C" sets allowed by GeneralString.
-
-
-
-Yu                          Expires: Jan 2005                  [Page 77]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-C.  Kerberos History (Informative)
-
-
-   [Adapted from KCLAR "BACKGROUND"]
-
-
-   The Kerberos model is based in part on Needham and Schroeder's
-   trusted third-party authentication protocol [NS78] and on
-   modifications suggested by Denning and Sacco [DS81].  The original
-   design and implementation of Kerberos Versions 1 through 4 was the
-   work of two former Project Athena staff members, Steve Miller of
-   Digital Equipment Corporation and Clifford Neuman (now at the
-   Information Sciences Institute of the University of Southern
-   California), along with Jerome Saltzer, Technical Director of Project
-   Athena, and Jeffrey Schiller, MIT Campus Network Manager.  Many other
-   members of Project Athena have also contributed to the work on
-   Kerberos.
-
-
-   Version 5 of the Kerberos protocol (described in this document) has
-   evolved from Version 4 based on new requirements and desires for
-   features not available in Version 4.  The design of Version 5 of the
-   Kerberos protocol was led by Clifford Neuman and John Kohl with much
-   input from the community.  The development of the MIT reference
-   implementation was led at MIT by John Kohl and Theodore Ts'o, with
-   help and contributed code from many others.  Since RFC1510 was
-   issued, extensions and revisions to the protocol have been proposed
-   by many individuals.  Some of these proposals are reflected in this
-   document.  Where such changes involved significant effort, the
-   document cites the contribution of the proposer.
-
-
-   Reference implementations of both version 4 and version 5 of Kerberos
-   are publicly available and commercial implementations have been
-   developed and are widely used.  Details on the differences between
-   Kerberos Versions 4 and 5 can be found in [KNT94].
-
-
-D.  Notational Differences from [KCLAR]
-
-
-   [ possible point for discussion ]
-
-
-   [KCLAR] uses notational conventions slightly different from this
-   document.  As a derivative of RFC 1510, the text of [KCLAR] uses C-
-   language style identifier names for defined values.  In ASN.1
-   notation, identifiers referencing defined values must begin with a
-   lowercase letter and contain hyphen (-) characters rather than
-   underscore (_) characters, while identifiers referencing types begin
-   with an uppercase letter.  [KCLAR] and RFC 1510 use all-uppercase
-   identifiers with underscores to identify defined values.  This has
-   the potential to create confusion, but neither document defines
-   values using actual ASN.1 value-assignment notation.
-
-
-   It is debatable whether it is advantageous to write all identifier
-   names (regardless of their ASN.1 token type) in all-uppercase letters
-   for the purpose of emphasis in running text.  The alternative is to
-
-
-Yu                          Expires: Jan 2005                  [Page 78]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   use double-quote characters (") when ambiguity is possible.
-
-
-Normative References
-
-
-   [ISO646]
-        "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
-
-
-   [ISO2022]
-        "Information technology -- Character code structure and
-        extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
-
-
-   [KCRYPTO]
-        draft-ietf-krb-wg-crypto-07.txt
-
-
-   [RFC2119]
-        S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
-        Requirement Levels", March 1997.
-
-
-   [X680]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Specification of basic notation", ITU-T Recommendation X.680
-        (2002) | ISO/IEC 8824-1:2002.
-
-
-   [X682]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Constraint specification", ITU-T Recommendation X.682 (2002) |
-        ISO/IEC 8824-3:2002.
-
-
-   [X683]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Parameterization of ASN.1 specifications", ITU-T Recommendation
-        X.683 (2002) | ISO/IEC 8824-4:2002.
-
-
-   [X690]
-        "Information technology -- ASN.1 encoding Rules: Specification
-        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
-        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
-        X.690 (2002) | ISO/IEC 8825-1:2002.
-
-
-Informative References
-
-
-   [DS81]
-        Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
-        Distribution Protocols," Communications of the ACM, Vol. 24(8),
-        pp. 533-536 (August 1981).
-
-
-   [Dub00]
-        Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
-        Systems", Elsevier-Morgan Kaufmann, 2000.
-        <http://www.oss.com/asn1/dubuisson.html>
-
-
-
-Yu                          Expires: Jan 2005                  [Page 79]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-   [ISO8859-1]
-        "Information technology -- 8-bit single-byte coded graphic
-        character sets -- Part 1: Latin alphabet No. 1", ISO/IEC
-        8859-1:1998.
-
-
-   [KCLAR]
-        draft-ietf-krb-wg-kerberos-clarifications-06.txt
-
-
-   [KNT94]
-        John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
-        Evolution of the Kerberos Authentication System".  In
-        Distributed Open Systems, pages 78-94.  IEEE Computer Society
-        Press, 1994.
-
-
-   [Lar96]
-        John Larmouth, "Understanding OSI", International Thomson
-        Computer Press, 1996.
-        <http://www.isi.salford.ac.uk/books/osi.html>
-
-
-   [Lar99]
-        John Larmouth, "ASN.1 Complete",  Elsevier-Morgan Kaufmann,
-        1999.  <http://www.oss.com/asn1/larmouth.html>
-
-
-   [NS78]
-        Roger M. Needham and Michael D. Schroeder, "Using Encryption for
-        Authentication in Large Networks of Computers", Communications
-        of the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
-
-
-   [RFC1510]
-        J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
-        Service (v5)", RFC1510, September 1993, Status: Proposed
-        Standard.
-
-
-   [RFC1964]
-        J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
-        June 1996, Status: Proposed Standard.
-
-
-   [X690-1997]
-        "Information technology -- ASN.1 encoding rules: Specification
-        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
-        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
-        X.690 (1997) | ISO/IEC 8825-1:1998.
-
-
-Author's Address
-
-
-   Tom Yu
-   77 Massachusetts Ave
-   Cambridge, MA 02139
-   USA
-   tlyu@mit.edu
-
-
-
-Yu                          Expires: Jan 2005                  [Page 80]
-Internet-Draft            yu-krb-extensions-01               19 Jul 2004
-
-
-Full Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                          Expires: Jan 2005                  [Page 81] 
\ No newline at end of file
diff --git a/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-02.txt b/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-02.txt
deleted file mode 100644
index 52f736b16..000000000
--- a/doc/standardisation/draft-yu-krb-wg-kerberos-extensions-02.txt
+++ /dev/null
@@ -1,6867 +0,0 @@
-INTERNET-DRAFT                                                    Tom Yu
-draft-yu-krb-wg-kerberos-extensions-02.txt                           MIT
-Expires: 25 April 2005                                   25 October 2004
-
-
-        The Kerberos Network Authentication Service (Version 5)
-
-
-Status of This Memo
-
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   or will be disclosed, and any of which I become aware will be
-   disclosed, in accordance with RFC 3668.
-
-
-   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."
-
-
-   The list of current Internet-Drafts can be accessed at
-
-
-      http://www.ietf.org/ietf/1id-abstracts.txt
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-
-
-      http://www.ietf.org/shadow.html
-
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-
-Abstract
-
-
-   This document describes version 5 of the Kerberos network
-   authentication protocol.  It describes a framework to allow for
-   extensions to be made to the protocol without creating
-   interoperability problems.
-
-
-Key Words for Requirements
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
-   to be interpreted as described in RFC 2119.
-
-
-
-
-
-Yu                         Expires: Apr 2005                    [Page 1]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-Table of Contents
-
-
-   Status of This Memo ..............................................  1
-   Copyright Notice .................................................  1
-   Abstract .........................................................  1
-   Key Words for Requirements .......................................  1
-   Table of Contents ................................................  2
-   1.  Introduction .................................................  5
-   1.1.  Kerberos Protocol Overview .................................  5
-   1.2.  Document Organization ......................................  6
-   2.  Compatibility Considerations .................................  6
-   2.1.  Extensibility ..............................................  7
-   2.2.  Compatibility with RFC 1510 ................................  7
-   2.3.  Backwards Compatibility ....................................  7
-   2.4.  1.4.2. Sending Extensible Messages .........................  8
-   2.5.  Criticality ................................................  8
-   2.6.  Authenticating Cleartext Portions of Messages ..............  9
-   2.7.  Capability Negotiation ..................................... 10
-   3.  Use of ASN.1 in Kerberos ..................................... 10
-   3.1.  Module Header .............................................. 11
-   3.2.  Top-Level Type ............................................. 11
-   3.3.  Previously Unused ASN.1 Notation (informative) ............. 12
-   3.3.1.  Parameterized Types ...................................... 12
-   3.3.2.  COMPONENTS OF Notation ................................... 12
-   3.3.3.  Constraints .............................................. 12
-   3.4.  New Types .................................................. 13
-   4.  Basic Types .................................................. 14
-   4.1.  Constrained Integer Types .................................. 14
-   4.2.  KerberosTime ............................................... 15
-   4.3.  KerberosString ............................................. 15
-   4.4.  Language Tags .............................................. 16
-   4.5.  KerberosFlags .............................................. 16
-   4.6.  Typed Holes ................................................ 16
-   4.7.  HostAddress and HostAddresses .............................. 17
-   4.7.1.  Internet (IPv4) Addresses ................................ 17
-   4.7.2.  Internet (IPv6) Addresses ................................ 17
-   4.7.3.  DECnet Phase IV addresses ................................ 18
-   4.7.4.  Netbios addresses ........................................ 18
-   4.7.5.  Directional Addresses .................................... 18
-   5.  Principals ................................................... 19
-   5.1.  Name Types ................................................. 19
-   5.2.  Principal Type Definition .................................. 19
-   5.3.  Principal Name Reuse ....................................... 20
-   5.4.  Realm Names ................................................ 20
-   5.5.  Printable Representations of Principal Names ............... 21
-   5.6.  Ticket-Granting Service Principal .......................... 21
-   5.6.1.  Cross-Realm TGS Principals ............................... 21
-   6.  Types Relating to Encryption ................................. 21
-   6.1.  Assigned Numbers for Encryption ............................ 22
-   6.1.1.  EType .................................................... 22
-   6.1.2.  Key Usages ............................................... 22
-
-
-Yu                         Expires: Apr 2005                    [Page 2]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   6.2.  Which Key to Use ........................................... 23
-   6.3.  EncryptionKey .............................................. 24
-   6.4.  EncryptedData .............................................. 24
-   6.5.  Checksums .................................................. 25
-   6.5.1.  ChecksumOf ............................................... 26
-   6.5.2.  Signed ................................................... 27
-   7.  Tickets ...................................................... 27
-   7.1.  Timestamps ................................................. 28
-   7.2.  Ticket Flags ............................................... 28
-   7.2.1.  Flags Relating to Initial Ticket Acquisition ............. 29
-   7.2.2.  Invalid Tickets .......................................... 29
-   7.2.3.  OK as Delegate ........................................... 30
-   7.2.4.  Renewable Tickets ........................................ 30
-   7.2.5.  Postdated Tickets ........................................ 31
-   7.2.6.  Proxiable and Proxy Tickets .............................. 32
-   7.2.7.  Forwarded and Forwardable Tickets ........................ 33
-   7.3.  Transited Realms ........................................... 34
-   7.4.  Authorization Data ......................................... 34
-   7.4.1.  AD-IF-RELEVANT ........................................... 35
-   7.4.2.  AD-KDCIssued ............................................. 35
-   7.4.3.  AD-AND-OR ................................................ 37
-   7.4.4.  AD-MANDATORY-FOR-KDC ..................................... 37
-   7.5.  Encrypted Part of Ticket ................................... 37
-   7.6.  Cleartext Part of Ticket ................................... 38
-   8.  Credential Acquisition ....................................... 40
-   8.1.  KDC-REQ .................................................... 40
-   8.2.  PA-DATA .................................................... 46
-   8.3.  KDC-REQ Processing ......................................... 46
-   8.3.1.  Handling Replays ......................................... 46
-   8.3.2.  Request Validation ....................................... 47
-   8.3.2.1.  AS-REQ Authentication .................................. 47
-   8.3.2.2.  TGS-REQ Authentication ................................. 47
-   8.3.2.3.  Principal Validation ................................... 47
-   8.3.2.4.  Checking For Revoked or Invalid Tickets ................ 48
-   8.3.3.  Timestamp Handling ....................................... 48
-   8.3.3.1.  AS-REQ Timestamp Processing ............................ 49
-   8.3.3.2.  TGS-REQ Timestamp Processing ........................... 49
-   8.3.4.  Handling Transited Realms ................................ 50
-   8.3.5.  Address Processing ....................................... 50
-   8.3.6.  Ticket Flag Processing ................................... 51
-   8.3.7.  Key Selection ............................................ 52
-   8.3.7.1.  Reply Key and Session Key Selection .................... 52
-   8.3.7.2.  Ticket Key Selection ................................... 52
-   8.4.  KDC-REP .................................................... 52
-   8.5.  Reply Validation ........................................... 55
-   8.6.  IP Transports .............................................. 55
-   8.6.1.  UDP/IP transport ......................................... 55
-   8.6.2.  TCP/IP transport ......................................... 56
-   8.6.3.  KDC Discovery on IP Networks ............................. 57
-   8.6.3.1.  DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 57
-   8.6.3.2.  DNS SRV records for KDC location ....................... 58
-
-
-Yu                         Expires: Apr 2005                    [Page 3]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP
-                Networks ............................................ 58
-   9.  Errors ....................................................... 58
-   10.  Session Key Exchange ........................................ 61
-   10.1.  AP-REQ .................................................... 61
-   10.2.  AP-REP .................................................... 63
-   11.  Session Key Use ............................................. 65
-   11.1.  KRB-SAFE .................................................. 65
-   11.2.  KRB-PRIV .................................................. 65
-   11.3.  KRB-CRED .................................................. 66
-   12.  Security Considerations ..................................... 67
-   12.1.  Time Synchronization ...................................... 67
-   12.2.  Replays ................................................... 67
-   12.3.  Principal Name Reuse ...................................... 67
-   12.4.  Password Guessing ......................................... 67
-   12.5.  Forward Secrecy ........................................... 67
-   12.6.  Authorization ............................................. 68
-   12.7.  Login Authentication ...................................... 68
-   13.  IANA Considerations ......................................... 68
-   14.  Acknowledgments ............................................. 69
-   Appendices ....................................................... 69
-   A.  ASN.1 Module (Normative) ..................................... 69
-   B.  Kerberos and Character Encodings (Informative) ...............103
-   C.  Kerberos History (Informative) ...............................104
-   D.  Notational Differences from [KCLAR] ..........................105
-   Normative References .............................................106
-   Informative References ...........................................106
-   Author's Address .................................................108
-   Full Copyright Statement .........................................108
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                    [Page 4]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-1.  Introduction
-
-
-   The Kerberos network authentication protocol is a trusted-third-party
-   protocol utilizing symmetric-key cryptography.  It assumes that all
-   communications between parties in the protocol may be arbitrarily
-   tampered with or monitored, and that the security of the overall
-   system depends only on the effectiveness of the cryptographic
-   techniques and the secrecy of the cryptographic keys used.  The
-   Kerberos protocol authenticates an application client's identity to
-   an application server, and likewise authenticates the application
-   server's identity to the application client.  These assurances are
-   made possible by the client and the server sharing secrets with the
-   trusted third party: the Kerberos server, also known as the Key
-   Distribution Center (KDC).  In addition, the protocol establishes an
-   ephemeral shared secret (the session key) between the client and the
-   server, allowing the protection of further communications between
-   them.
-
-
-   The Kerberos protocol, as originally specified, provides insufficient
-   means for extending the protocol in a backwards-compatible way.  This
-   deficiency has caused problems for interoperability.  This document
-   describes a framework which enables backwards-compatible extensions
-   to the Kerberos protocol.
-
-
-1.1.  Kerberos Protocol Overview
-
-
-   Kerberos comprises three main sub-protocols: credentials acquisition,
-   session key exchange, and session key usage.  A client acquires
-   credentials by asking the KDC for a credential for a service; the KDC
-   issues the credential, which contains a ticket and a session key.
-   The ticket, containing the client's identity, timestamps, expiration
-   time, and a session key, is a encrypted in a key known to the
-   application server.  The KDC encrypts the credential using a key
-   known to the client, and transmits the credential to the client.
-
-
-   There are two means of requesting credentials: the Authentication
-   Service (AS) exchange, and the Ticket-Granting Service (TGS)
-   exchange.  In the typical AS exchange, a client uses a password-
-   derived key to decrypt the response.  In the TGS exchange, the KDC
-   behaves as an application server; the client authenticates to the TGS
-   by using a Ticket-Granting Ticket (TGT).  The client usually obtains
-   the TGT by using the AS exchange.
-
-
-   Session key exchange consists of the client transmitting the ticket
-   to the application server, accompanied by an authenticator.  The
-   authenticator contains a timestamp and additional data encrypted
-   using the ticket's session key.  The application server decrypts the
-   ticket, extracting the session key.  The application server then uses
-   the session key to decrypt the authenticator.  Upon successful
-   decryption of the authenticator, the application server knows that
-   the data in the authenticator were sent by the client named in the
-
-
-Yu                         Expires: Apr 2005                    [Page 5]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   associated ticket.  Additionally, since authenticators expire more
-   quickly than tickets, the application server has some assurance that
-   the transaction is not a replay.  The application server may send an
-   encrypted acknowledgment to the client, verifying its identity to the
-   client.
-
-
-   Once session key exchange has occurred, the client and server may use
-   the established session key to protect further traffic.  This
-   protection may consist of protection of integrity only, or of
-   protection of confidentiality and integrity.  Additional measures
-   exist for a client to securely forward credentials to a server.
-
-
-   The entire scheme depends on loosely synchronized clocks.
-   Synchronization of the clock on the KDC with the application server
-   clock allows the application server to accurately determine whether a
-   credential is expired.  Likewise, synchronization of the clock on the
-   client with the application server clock prevents replay attacks
-   utilizing the same credential.  Careful design of the application
-   protocol may allow replay prevention without requiring client-server
-   clock synchronization.
-
-
-   After establishing a session key, application client and the
-   application server can exchange Kerberos protocol messages that use
-   the session key to protect the integrity or confidentiality of
-   communications between the client and the server.  Additionally, the
-   client may forward credentials to the application server.
-
-
-   The credentials acquisition protocol takes place over specific,
-   defined transports (UDP and TCP).  Application protocols define which
-   transport to use for the session key establishment protocol and for
-   messages using the session key; the application may choose to perform
-   its own encapsulation of the Kerberos messages, for example.
-
-
-1.2.  Document Organization
-
-
-   The remainder of this document begins by describing the general
-   frameworks for protocol extensibility, including whether to interpret
-   unknown extensions as critical.  It then defines the protocol
-   messages and exchanges.
-
-
-   The definition of the Kerberos protocol uses Abstract Syntax Notation
-   One (ASN.1) [X680], which specifies notation for describing the
-   abstract content of protocol messages.  This document defines a
-   number of base types using ASN.1; these base types subsequently
-   appear in multiple types which define actual protocol messages.
-   Definitions of principal names and of tickets, which are central to
-   the protocol, also appear preceding the protocol message definitions.
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                    [Page 6]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-2.  Compatibility Considerations
-
-
-2.1.  Extensibility
-
-
-   In the past, significant interoperability problems have resulted from
-   conflicting assumptions about how the Kerberos protocol can be
-   extended.  As the deployed base of Kerberos grows, the ability to
-   extend the Kerberos protocol becomes more important.  In order to
-   ensure that vendors and the IETF can extend the protocol while
-   maintaining backwards compatibility, this document outlines a
-   framework for extending Kerberos.
-
-
-   Kerberos provides two general mechanisms for protocol extensibility.
-   Many protocol messages, including some defined in RFC 1510, contain
-   typed holes--sub-messages containing an octet string along with an
-   integer that identifies how to interpret the octet string.  The
-   integer identifiers are registered centrally, but can be used both
-   for vendor extensions and for extensions standardized in the IETF.
-   This document adds typed holes to a number of messages which
-   previously lacked typed holes.
-
-
-   Many new messages defined in this document also contain ASN.1
-   extension markers.  These markers allow future revisions of this
-   document to add additional elements to messages, for cases where
-   typed holes are inadequate for some reason.  Because tag numbers and
-   position in a sequence need to be coordinated in order to maintain
-   interoperability, implementations MUST NOT include ASN.1 extensions
-   except when those extensions are specified by IETF standards-track
-   documents.
-
-
-2.2.  Compatibility with RFC 1510
-
-
-   Implementations of RFC 1510 did not use extensible ASN.1 types.
-   Sending additional fields not in RFC 1510 to these implementations
-   results in undefined behavior.  Examples of this behavior are known
-   to include discarding messages with no error indications.
-
-
-   Where messages have been changed since RFC 1510, ASN.1 CHOICE types
-   are used; one alternative of the CHOICE provides a message which is
-   wire-encoding compatible with RFC 1510, and the other alternative
-   provides the new, extensible message.
-
-
-   Implementations sending new messages MUST ensure that the recipient
-   supports these new messages.  Along with each extensible message is a
-   guideline for when that message MAY be used.  IF that guideline is
-   followed, then the recipient is guaranteed to understand the message.
-
-
-2.3.  Backwards Compatibility
-
-
-   This document describes two sets (for the most part) of ASN.1 types.
-   The first set of types is wire-encoding compatible with RFC 1510 and
-
-
-Yu                         Expires: Apr 2005                    [Page 7]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   [KCLAR].  The second set of types is the set of types enabling
-   extensibility.  This second set may be referred to as
-   "extensibility-enabled types". [ need to make this consistent
-   throughout? ]
-
-
-   A major difference between the new extensibility-enabled types and
-   the types for RFC 1510 compatibility is that the extensibility-
-   enabled types allow for the use of UTF-8 encodings in various
-   character strings in the protocol.  Each party in the protocol must
-   have some knowledge of the capabilities of the other parties in the
-   protocol.  There are methods for establishing this knowledge without
-   necessarily requiring explicit configuration.
-
-
-   An extensibility-enabled client can detect whether a KDC supports the
-   extensibility-enabled types by requesting an extensibility-enabled
-   reply.  If the KDC replies with an extensibility-enabled reply, the
-   client knows that the KDC supports extensibility.  If the KDC issues
-   an extensibility-enabled ticket, the client knows that the service
-   named in the ticket is extensibility-enabled.
-
-
-2.4.  1.4.2. Sending Extensible Messages
-
-
-   Care must be taken to make sure that old implementations can
-   understand messages sent to them even if they do not understand an
-   extension that is used.  Unless the sender knows the extension is
-   supported, the extension cannot change the semantics of the core
-   message or previously defined extensions.
-
-
-   For example, an extension including key information necessary to
-   decrypt the encrypted part of a KDC-REP could only be used in
-   situations where the recipient was known to support the extension.
-   Thus when designing such extensions it is important to provide a way
-   for the recipient to notify the sender of support for the extension.
-   For example in the case of an extension that changes the KDC-REP
-   reply key, the client could indicate support for the extension by
-   including a padata element in the AS-REQ sequence.  The KDC should
-   only use the extension if this padata element is present in the AS-
-   REQ.  Even if policy requires the use of the extension, it is better
-   to return an error indicating that the extension is required than to
-   use the extension when the recipient may not support it; debugging
-   why implementations do not interoperate is easier when errors are
-   returned.
-
-
-2.5.  Criticality
-
-
-   Recipients of unknown message extensions (including typed holes, new
-   flags, and ASN.1 extension elements) should preserve the encoding of
-   the extension but otherwise ignore the presence of the extension;
-   i.e., unknown extensions SHOULD be treated as non-critical.  If a
-   copy of the message is used later--for example, when a Ticket
-   received in a KDC-REP is later used in an AP-REQ--then the unknown
-
-
-Yu                         Expires: Apr 2005                    [Page 8]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   extensions MUST be included.
-
-
-   An implementation SHOULD NOT reject a request merely because it does
-   not understand some element of the request.  As a related
-   consequence, implementations SHOULD handle communicating with other
-   implementations which do not implement some requested options.  This
-   may require designers of options to provide means to determine
-   whether an option has been rejected, not understood, or (perhaps
-   maliciously) deleted or modified in transit.
-
-
-   There is one exception to non-criticality described above: if an
-   unknown authorization data element is received by a server either in
-   an AP-REQ or in a Ticket contained in an AP-REQ, then the
-   authentication SHOULD fail.  Authorization data is intended to
-   restrict the use of a ticket.  If the service cannot determine
-   whether the restriction applies to that service then a security
-   weakness may result if authentication succeeds.  Authorization
-   elements meant to be truly optional can be enclosed in the AD-IF-
-   RELEVANT element.
-
-
-   Many RFC 1510 implementations ignore unknown authorization data
-   elements.  Depending on these implementations to honor authorization
-   data restrictions may create a security weakness.
-
-
-2.6.  Authenticating Cleartext Portions of Messages
-
-
-   Various denial of service attacks and downgrade attacks against
-   Kerberos are possible unless plaintexts are somehow protected against
-   modification.  An early design goal of Kerberos Version 5 was to
-   avoid encrypting more of the authentication exchange that was
-   required.  (Version 4 doubly-encrypted the encrypted part of a ticket
-   in a KDC reply, for example.)  This minimization of encryption
-   reduces the load on the KDC and busy servers.  Also, during the
-   initial design of Version 5, the existence of legal restrictions on
-   the export of cryptography made it desirable to minimize of the
-   number of uses of encryption in the protocol.  Unfortunately,
-   performing this minimization created numerous instances of
-   unauthenticated security-relevant plaintext fields.
-
-
-   The extensible variants of the messages described in this document
-   wrap the actual message in an ASN.1 sequence containing a keyed
-   checksum of the contents of the message.  Guidelines in [XXX] section
-   3 specify when the checksum MUST be included and what key MUST be
-   used.  Guidelines on when to include a checksum are never ambiguous:
-   a particular PDU is never correct both with and without a checksum.
-   With the exception of the KRB-ERROR message, receiving
-   implementations MUST reject messages where a checksum is included and
-   not expected or where a checksum is expected but not included.  The
-   receiving implementation does not always have sufficient information
-   to know whether a KRB-ERROR should contain a checksum.  Even so,
-   KRB-ERROR messages with invalid checksums MUST be rejected and
-
-
-Yu                         Expires: Apr 2005                    [Page 9]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   implementations MAY consider the presence or absence of a checksum
-   when evaluating whether to trust the error.
-
-
-   This authenticated cleartext protection is provided only in the
-   extensible variants of the messages; it is never used when
-   communicating with an RFC 1510 implementation.
-
-
-2.7.  Capability Negotiation
-
-
-   Kerberos is a three-party protocol.  Each of the three parties
-   involved needs a means of detecting the capabilities supported by the
-   others.  Two of the parties, the KDC and the application server, do
-   not communicate directly in the Kerberos protocol.  Communicating
-   capabilities from the KDC to the application server requires using a
-   ticket as an intermediary.
-
-
-   The main capability requiring negotiation is the support of the
-   extensibility framework described in this document.  Negotiation of
-   this capability while remaining compatible with RFC 1510
-   implementations is possible.  The main complication is that the
-   client needs to know whether the application server supports the
-   extensibility framework prior to sending any message to the
-   application server.  This can be accomplished if the KDC has
-   knowledge of whether an application server supports the extensibility
-   framework.
-
-
-   Client software advertizes its capabilities when requesting
-   credentials from the KDC.  If the KDC recognizes the capabilities, it
-   acknowledges this fact to the client in its reply.  In addition, if
-   the KDC has knowledge that the application server supports certain
-   capabilities, it also communicates this knowledge to the client in
-   its reply.  The KDC can encode its own capabilities in the ticket so
-   that the application server may discover these capabilities.  The
-   client advertizes its capabilities to the application server when it
-   initiates authentication to the application server.
-
-
-3.  Use of ASN.1 in Kerberos
-
-
-   Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690].
-   Even though ASN.1 theoretically allows the description of protocol
-   messages to be independent of the encoding rules used to encode the
-   messages, Kerberos messages MUST be encoded with DER.  Subtleties in
-   the semantics of the notation, such as whether tags carry any
-   semantic content to the application, may cause the use of other ASN.1
-   encoding rules to be problematic.
-
-
-   Implementors not using existing ASN.1 tools (e.g., compilers or
-   support libraries) are cautioned to thoroughly read and understand
-   the actual ASN.1 specification to ensure correct implementation
-   behavior.  There is more complexity in the notation than is
-   immediately obvious, and some tutorials and guides to ASN.1 are
-
-
-Yu                         Expires: Apr 2005                   [Page 10]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   misleading or erroneous.  Recommended tutorials and guides include
-   [Dub00], [Lar99], though there is still no substitute for reading the
-   actual ASN.1 specification.
-
-
-3.1.  Module Header
-
-
-   The type definitions in this document assume an ASN.1 module
-   definition of the following form:
-
-
-      KerberosV5Spec3 {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2) modules(4) krb5spec3(4)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-
-      -- Rest of definitions here
-
-
-      END
-
-
-   This specifies that the tagging context for the module will be
-   explicit and that automatic tagging is not done.
-
-
-   Some other publications [RFC1510] [RFC1964] erroneously specify an
-   object identifier (OID) having an incorrect value of "5" for the
-   "dod" component of the OID.  In the case of RFC 1964, use of the
-   "correct" OID value would result in a change in the wire protocol;
-   therefore, the RFC 1964 OID remains unchanged for now.
-
-
-3.2.  Top-Level Type
-
-
-   The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol
-   Data Units or PDUs) which an application may directly reference.
-   Applications SHOULD NOT transmit any types other than those which are
-   alternatives of the KRB-PDU CHOICE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 11]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- top-level type
-      --
-      -- Applications should not directly reference any types
-      -- other than KRB-PDU and its component types.
-      --
-      KRB-PDU         ::= CHOICE {
-          ticket      Ticket,
-          as-req      AS-REQ,
-          as-rep      AS-REP,
-          tgs-req     TGS-REQ,
-          tgs-rep     TGS-REP,
-          ap-req      AP-REQ,
-          ap-rep      AP-REP,
-          krb-safe    KRB-SAFE,
-          krb-priv    KRB-PRIV,
-          krb-cred    KRB-CRED,
-          tgt-req     TGT-REQ,
-          krb-error   KRB-ERROR,
-          ...
-      }
-
-
-
-3.3.  Previously Unused ASN.1 Notation (informative)
-
-
-   Some aspects of ASN.1 notation used in this document were not used in
-   [KCLAR], and may be unfamiliar to some readers.  This subsection is
-   informative; for normative definitions of the notation, see the
-   actual ASN.1 specifications [X680], [X682], [X683].
-
-
-3.3.1.  Parameterized Types
-
-
-   This document uses ASN.1 parameterized types [X683] to make
-   definitions of types more readable.  For some types, some or all of
-   the parameters are advisory, i.e., they are not encoded in any form
-   for transmission in a protocol message.  These advisory parameters
-   can describe implementation behavior associated with the type.
-
-
-3.3.2.  COMPONENTS OF Notation
-
-
-   The "COMPONENTS OF" notation, used to define the RFC 1510
-   compatibility types, extracts all of the component types of an ASN.1
-   SEQUENCE type.  The extension marker (the "..." notation) and any
-   extension components are not extracted by "COMPONENTS OF".  The
-   "COMPONENTS OF" notation permits concise definition of multiple types
-   which have many components in common with each other.
-
-
-3.3.3.  Constraints
-
-
-   This document uses ASN.1 constraints, including the
-   "UserDefinedConstraint" notation [X682].  Some constraints can be
-   handled automatically by tools that can parse them.  Uses of the
-
-
-Yu                         Expires: Apr 2005                   [Page 12]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will
-   typically need to have behavior manually coded; the notation provides
-   a formalized way of conveying intended implementation behavior.
-
-
-   The "WITH COMPONENTS" constraint notation allows constraints to apply
-   to component types of a SEQUENCE type.  This constraint notation
-   effectively allows constraints to "reach into" a type to constrain
-   its component types.
-
-
-3.4.  New Types
-
-
-   This document defines a number of ASN.1 types which are new since
-   [KCLAR].  The names of these types will typically have a suffix like
-   "Ext", indicating that the types are intended to support
-   extensibility.  Types original to RFC 1510 and [KCLAR] have been
-   renamed to have a suffix like "1510".  The "Ext" and "1510" types
-   often contain a number of common elements; these common elements have
-   a suffix like "Common".  The "1510" types have various ASN.1
-   constraints applied to them; the constraints limit the possible
-   values of the "1510" types to those permitted by RFC 1510 or by
-   [KCLAR].  The "Ext" types may have different constraints, typically
-   to force string values to be sent as UTF-8.
-
-
-   For example, consider
-
-
-      -- example "common" type
-      Foo-Common      ::= SEQUENCE {
-          a           [0] INTEGER,
-          b           [1] OCTET STRING,
-          ...,
-          c           [2] INTEGER,
-          ...
-      }
-
-
-      -- example "RFC 1510 compatibility" type
-      Foo-1510        ::= SEQUENCE {
-          -- the COMPONENTS OF notation drops the extension marker
-          -- and all extension additions.
-          COMPONENTS OF Foo-Common
-      }
-
-
-      -- example "extensibility-enabled" type
-      Foo-Ext         ::= Foo-Common
-
-
-   where "Foo-Common" is a common type used to define both the "1510"
-   and "Ext" versions of a type.  "Foo-1510" is the RFC 1510 version of
-   the type, while "Foo-Ext" is the extensible version.  "Foo-1510" does
-   not contain the extension marker, nor does it contain the extension
-   component "c".  The type "Foo-1510" is equivalent to "Foo-1510-
-   Equiv", shown below.
-
-
-
-Yu                         Expires: Apr 2005                   [Page 13]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- example type equivalent to Foo-1510
-      Foo-1510-Equiv  ::= SEQUENCE {
-          a           [0] INTEGER,
-          b           [1] OCTET STRING
-      }
-
-
-
-4.  Basic Types
-
-
-   These "basic" Kerberos ASN.1 types appear in multiple other Kerberos
-   types.
-
-
-4.1.  Constrained Integer Types
-
-
-   In RFC 1510, many types contained references to the unconstrained
-   INTEGER type.  Since an unconstrained INTEGER can contain almost any
-   possible abstract integer value, most of the unconstrained references
-   to INTEGER in RFC 1510 were constrained to 32 bits or smaller in
-   [KCLAR].
-
-
-      -- signed values representable in 32 bits
-      --
-      -- These are often used as assigned numbers for various things.
-      Int32           ::= INTEGER (-2147483648..2147483647)
-
-
-   The "Int32" type often contains an assigned number identifying the
-   contents of a typed hole.  Unless otherwise stated, non-negative
-   values are registered, and negative values are available for local
-   use.
-
-
-      -- unsigned 32 bit values
-      UInt32          ::= INTEGER (0..4294967295)
-
-
-   The "UInt32" type is used in some places where an unsigned 32-bit
-   integer is needed.
-
-
-      -- unsigned 64 bit values
-      UInt64          ::= INTEGER (0..18446744073709551615)
-
-
-   The "UInt64" type is used in places where 32 bits of precision may
-   provide inadequate security.
-
-
-      -- sequence numbers
-      SeqNum          ::= UInt64
-
-
-   Sequence numbers were constrained to 32 bits in [KCLAR], but this
-   document allows for 64-bit sequence numbers.
-
-
-      -- nonces
-      Nonce           ::= UInt64
-
-
-
-Yu                         Expires: Apr 2005                   [Page 14]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   Likewise, nonces were constrained to 32 bits in [KCLAR], but expanded
-   to 64 bits here.
-
-
-      -- microseconds
-      Microseconds    ::= INTEGER (0..999999)
-
-
-   The "microseconds" type is intended to carry the microseconds part of
-   a time value.
-
-
-4.2.  KerberosTime
-
-
-      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
-                              -- MUST NOT include fractional seconds
-      })
-
-
-   The timestamps used in Kerberos are encoded as GeneralizedTimes.  A
-   KerberosTime value MUST NOT include any fractional portions of the
-   seconds.  As required by the DER, it further MUST NOT include any
-   separators, and it specifies the UTC time zone (Z).  Example: The
-   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
-   November 1985 is "19851106210627Z".
-
-
-4.3.  KerberosString
-
-
-      -- used for names and for error messages
-      KerberosString  ::= CHOICE {
-          ia5         GeneralString (IA5String),
-          utf8        UTF8String,
-          ...         -- no extension may be sent
-                      -- to an rfc1510 implementation --
-      }
-
-
-   The KerberosString type is used for character strings in various
-   places in the Kerberos protocol.  For compatibility with RFC 1510,
-   GeneralString values constrained to IA5String (US-ASCII) are
-   permitted in messages exchanged with RFC 1510 implementations.  The
-   new protocol messages contain strings encoded as UTF-8, and these
-   strings MUST be normalized using [SASLPREP].  KerberosString values
-   are present in principal names and in error messages.  Control
-   characters SHOULD NOT be used in principal names, and used with
-   caution in error messages.
-
-
-      -- IA5 choice only; useful for constraints
-      KerberosStringIA5       ::= KerberosString
-          (WITH COMPONENTS { ia5 PRESENT })
-
-
-      -- IA5 excluded; useful for constraints
-      KerberosStringExt       ::= KerberosString
-          (WITH COMPONENTS { ia5 ABSENT })
-
-
-   KerberosStringIA5 requires the use of the "ia5" alternative, while
-
-
-Yu                         Expires: Apr 2005                   [Page 15]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   KerberosStringExt forbids it.  These types appear in ASN.1
-   constraints on messages.
-
-
-   For detailed background regarding the history of character string use
-   in Kerberos, as well as discussion of some compatibility issues, see
-   Appendix B.
-
-
-4.4.  Language Tags
-
-
-      -- used for language tags
-      LangTag ::= PrintableString
-          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
-
-
-   The "LangTag" type is used to specify language tags for localization
-   purposes, using the [RFC3066] format.
-
-
-4.5.  KerberosFlags
-
-
-   For several message types, a specific constrained bit string type,
-   KerberosFlags, is used.
-
-
-      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
-          (CONSTRAINED BY {
-          -- MUST be a valid value of -- NamedBits
-          -- but if the value to be sent would be truncated to shorter
-          -- than 32 bits according to DER, the value MUST be padded
-          -- with trailing zero bits to 32 bits.  Otherwise, no
-          -- trailing zero bits may be present.
-
-
-      })
-
-
-
-   The actual bit string type encoded in Kerberos messages does not use
-   named bits.  The advisory parameter of the KerberosFlags type names a
-   bit string type defined using named bits, whose value is encoded as
-   if it were a bit string with unnamed bits.  This practice is
-   necessary because the DER require trailing zero bits to be removed
-   when encoding bit strings defined using named bits.  Existing
-   implementations of Kerberos send exactly 32 bits rather than
-   truncating, so the size constraint requires the transmission of at
-   least 32 bits.  Trailing zero bits beyond the first 32 bits are
-   truncated.
-
-
-4.6.  Typed Holes
-
-
-      -- Typed hole identifiers
-      TH-id           ::= CHOICE {
-          int32               Int32,
-          rel-oid             RELATIVE-OID
-      }
-
-
-
-Yu                         Expires: Apr 2005                   [Page 16]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   The "TH-id" type is a generalized means to identify the contents of a
-   typed hole.  The "int32" alternative may be used for simple integer
-   assignments, in the same manner as "Int32", while the "rel-oid"
-   alternative may be used for hierarchical delegation.
-
-
-4.7.  HostAddress and HostAddresses
-
-
-      AddrType        ::= Int32
-
-
-      HostAddress     ::= SEQUENCE  {
-          addr-type   [0] AddrType,
-          address     [1] OCTET STRING
-      }
-
-
-      -- NOTE: HostAddresses is always used as an OPTIONAL field and
-      -- should not be a zero-length SEQUENCE OF.
-      --
-      -- The extensible messages explicitly constrain this to be
-      -- non-empty.
-      HostAddresses   ::= SEQUENCE OF HostAddress
-
-
-
-   addr-type
-        This field specifies the type of address that follows.
-
-
-   address
-        This field encodes a single address of the type identified by
-        "addr-type".
-
-
-   All negative values for the host address type are reserved for local
-   use.  All non-negative values are reserved for officially assigned
-   type fields and interpretations.
-
-
-
-      addr-type |     meaning
-      __________|______________
-              2 |   IPv4
-              3 |   directional
-             12 |   DECnet
-             20 |   NetBIOS
-             24 |   IPv6
-
-
-
-
-4.7.1.  Internet (IPv4) Addresses
-
-
-   Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
-   MSB order (most significant byte first). The IPv4 loopback address
-   SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is
-   two (2).
-
-
-
-Yu                         Expires: Apr 2005                   [Page 17]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-4.7.2.  Internet (IPv6) Addresses
-
-
-   IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, encoded
-   in MSB order (most significant byte first). The type of IPv6
-   addresses is twenty-four (24). The following addresses MUST NOT
-   appear in any Kerberos PDU:
-
-
-      * the Unspecified Address
-
-
-      * the Loopback Address
-
-
-      * Link-Local addresses
-
-
-   This restriction applies to the inclusion in the address fields of
-   Kerberos PDUs, but not to the address fields of packets that might
-   carry such PDUs.  The restriction is necessary because the use of an
-   address with non-global scope could allow the acceptance of a message
-   sent from a node that may have the same address, but which is not the
-   host intended by the entity that added the restriction.  If the
-   link-local address type needs to be used for communication, then the
-   address restriction in tickets must not be used (i.e. addressless
-   tickets must be used).
-
-
-   IPv4-mapped IPv6 addresses MUST be represented as addresses of type
-   2.
-
-
-4.7.3.  DECnet Phase IV addresses
-
-
-   DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order.
-   The type of DECnet Phase IV addresses is twelve (12).
-
-
-4.7.4.  Netbios addresses
-
-
-   Netbios addresses are 16-octet addresses typically composed of 1 to
-   15 alphanumeric characters and padded with the US-ASCII SPC character
-   (code 32).  The 16th octet MUST be the US-ASCII NUL character (code
-   0).  The type of Netbios addresses is twenty (20).
-
-
-4.7.5.  Directional Addresses
-
-
-   In many environments, including the sender address in KRB-SAFE and
-   KRB-PRIV messages is undesirable because the addresses may be changed
-   in transport by network address translators. However, if these
-   addresses are removed, the messages may be subject to a reflection
-   attack in which a message is reflected back to its originator. The
-   directional address type provides a way to avoid transport addresses
-   and reflection attacks.  Directional addresses are encoded as four
-   byte unsigned integers in network byte order.  If the message is
-   originated by the party sending the original AP-REQ message, then an
-   address of 0 SHOULD be used. If the message is originated by the
-   party to whom that AP-REQ was sent, then the address 1 SHOULD be
-
-
-Yu                         Expires: Apr 2005                   [Page 18]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   used.  Applications involving multiple parties can specify the use of
-   other addresses.
-
-
-   Directional addresses MUST only be used for the sender address field
-   in the KRB-SAFE or KRB-PRIV messages.  They MUST NOT be used as a
-   ticket address or in a AP-REQ message.  This address type SHOULD only
-   be used in situations where the sending party knows that the
-   receiving party supports the address type.  This generally means that
-   directional addresses may only be used when the application protocol
-   requires their support.  Directional addresses are type (3).
-
-
-5.  Principals
-
-
-   Principals are participants in the Kerberos protocol.  A "realm"
-   consists of principals in one administrative domain, served by one
-   KDC (or one replicated set of KDCs).  Each principal name has an
-   arbitrary number of components, though typical principal names will
-   only have one or two components.  A principal name is meant to be
-   readable by and meaningful to humans, especially in a realm lacking a
-   centrally adminstered authorization infrastructure.
-
-
-5.1.  Name Types
-
-
-   Each PrincipalName has NameType indicating what sort of name it is.
-   The name-type SHOULD be treated as a hint.  Ignoring the name type,
-   no two names can be the same (i.e., at least one of the components,
-   or the realm, must be different).
-
-
-      -- assigned numbers for name types (used in principal names)
-      NameType        ::= Int32
-
-
-      -- Name type not known
-      nt-unknown              NameType ::= 0
-      -- Just the name of the principal as in DCE, or for users
-      nt-principal            NameType ::= 1
-      -- Service and other unique instance (krbtgt)
-      nt-srv-inst             NameType ::= 2
-      -- Service with host name as instance (telnet, rcommands)
-      nt-srv-hst              NameType ::= 3
-      -- Service with host as remaining components
-      nt-srv-xhst             NameType ::= 4
-      -- Unique ID
-      nt-uid                  NameType ::= 5
-      -- Encoded X.509 Distingished name [RFC 2253]
-      nt-x500-principal       NameType ::= 6
-      -- Name in form of SMTP email name (e.g. user@foo.com)
-      nt-smtp-name            NameType ::= 7
-      -- Enterprise name - may be mapped to principal name
-      nt-enterprise           NameType ::= 10
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 19]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-5.2.  Principal Type Definition
-
-
-      PrincipalName   ::= SEQUENCE {
-          name-type   [0] NameType,
-          -- May have zero elements, or individual elements may be
-          -- zero-length, but this is NOT RECOMMENDED.
-          name-string [1] SEQUENCE OF KerberosString
-      }
-
-
-
-   name-type
-        hint of the type of name that follows
-
-
-   name-string
-        The "name-string" encodes a sequence of components that form a
-        name, each component encoded as a KerberosString.  Taken
-        together, a PrincipalName and a Realm form a principal
-        identifier.  Most PrincipalNames will have only a few components
-        (typically one or two).
-
-
-5.3.  Principal Name Reuse
-
-
-   Realm administrators SHOULD use extreme caution when considering
-   reusing a principal name.  A service administrator might explicitly
-   enter principal names into a local access control list (ACL) for the
-   service.  If such local ACLs exist independently of a centrally
-   administered authorization infrastructure, realm administrators
-   SHOULD NOT reuse principal names until confirming that all extant ACL
-   entries referencing that principal name have been updated.  Failure
-   to perform this check can result in a security vulnerability, as a
-   new principal can inadvertently inherit unauthorized privileges upon
-   receiving a reused principal name.  An organization whose Kerberos-
-   authenticated services all use a centrally-adminstered authorization
-   infrastructure may not need to take these precautions regarding
-   principal name reuse.
-
-
-5.4.  Realm Names
-
-
-      Realm           ::= KerberosString
-
-
-      -- IA5 only
-      RealmIA5        ::= Realm (KerberosStringIA5)
-
-
-      -- IA5 excluded
-      RealmExt        ::= Realm (KerberosStringExt)
-
-
-
-   Kerberos realm names are KerberosStrings.  Realms MUST NOT contain a
-   character with the code 0 (the US-ASCII NUL).  Most realms will
-   usually consist of several components separated by periods (.), in
-   the style of Internet Domain Names, or separated by slashes (/) in
-
-
-Yu                         Expires: Apr 2005                   [Page 20]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   the style of X.500 names.
-
-
-5.5.  Printable Representations of Principal Names
-
-
-   [ perhaps non-normative? ]
-
-
-   The printable form of a principal name consists of the concatenation
-   of components of the PrincipalName value using the slash character
-   (/), followed by an at-sign (@), followed by the realm name.  Any
-   occurrence of a backslash (\), slash (/) or at-sign (@) in the
-   PrincipalName value is quoted by a backslash.
-
-
-5.6.  Ticket-Granting Service Principal
-
-
-   The PrincipalName value corresponding to a ticket-granting service
-   has two components: the first component is the string "krbtgt", and
-   the second component is the realm name of the TGS which will accept a
-   ticket-granting ticket having this service principal name.  The realm
-   name of service always indicates which realm issued the ticket.  A
-   ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for
-   obtaining tickets in the same realm would have the following ASN.1
-   values for its "realm" and "sname" components, respectively:
-
-
-      -- Example Realm and PrincipalName for a TGS
-
-
-      tgtRealm1       Realm ::= ia5 : "A.EXAMPLE.COM"
-
-
-      tgtPrinc1       PrincipalName ::= {
-          name-type nt-srv-inst,
-          name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" }
-      }
-
-
-   Its printable representation would be written as
-   "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM".
-
-
-5.6.1.  Cross-Realm TGS Principals
-
-
-   It is possible for a principal in one realm to authenticate to a
-   service in another realm.  A KDC can issue a cross-realm ticket-
-   granting ticket to allow one of its principals to authenticate to a
-   service in a foreign realm.  For example, the TGS principal
-   "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a
-   client principal in the realm A.EXAMPLE.COM to authenticate to a
-   service in the realm B.EXAMPLE.COM.  When the KDC for B.EXAMPLE.COM
-   issues a ticket to a client originating in A.EXAMPLE.COM, the
-   client's realm name remains "A.EXAMPLE.COM", even though the service
-   principal will have the realm "B.EXAMPLE.COM".
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 21]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-6.  Types Relating to Encryption
-
-
-   Many Kerberos protocol messages contain encrypted encodings of
-   various data types.  Some Kerberos protocol messages also contain
-   checksums (signatures) of encodings of various types.
-
-
-6.1.  Assigned Numbers for Encryption
-
-
-   Encryption algorithm identifiers and key usages both have assigned
-   numbers, described in [KCRYPTO].
-
-
-6.1.1.  EType
-
-
-   EType is the integer type for assigned numbers for encryption
-   algorithms.  Defined in [KCRYPTO].
-
-
-      -- Assigned numbers denoting encryption mechanisms.
-      EType ::= Int32
-
-
-      -- assigned numbers for encryption schemes
-      et-des-cbc-crc                  EType ::= 1
-      et-des-cbc-md4                  EType ::= 2
-      et-des-cbc-md5                  EType ::= 3
-      --     [reserved]                         4
-      et-des3-cbc-md5                 EType ::= 5
-      --     [reserved]                         6
-      et-des3-cbc-sha1                EType ::= 7
-      et-dsaWithSHA1-CmsOID           EType ::= 9
-      et-md5WithRSAEncryption-CmsOID  EType ::= 10
-      et-sha1WithRSAEncryption-CmsOID EType ::= 11
-      et-rc2CBC-EnvOID                EType ::= 12
-      et-rsaEncryption-EnvOID         EType ::= 13
-      et-rsaES-OAEP-ENV-OID           EType ::= 14
-      et-des-ede3-cbc-Env-OID         EType ::= 15
-      et-des3-cbc-sha1-kd             EType ::= 16
-      -- AES
-      et-aes128-cts-hmac-sha1-96      EType ::= 17
-      -- AES
-      et-aes256-cts-hmac-sha1-96      EType ::= 18
-      -- Microsoft
-      et-rc4-hmac                     EType ::= 23
-      -- Microsoft
-      et-rc4-hmac-exp                 EType ::= 24
-      -- opaque; PacketCable
-      et-subkey-keymaterial           EType ::= 65
-
-
-
-6.1.2.  Key Usages
-
-
-   KeyUsage is the integer type for assigned numbers for key usages.
-   Key usage values are inputs to the encryption and decryption
-
-
-Yu                         Expires: Apr 2005                   [Page 22]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   functions described in [KCRYPTO].
-
-
-      -- Assigned numbers denoting key usages.
-      KeyUsage ::= UInt32
-
-
-      --
-      -- Actual identifier names are provisional and subject to
-      -- change.
-      --
-      ku-pa-enc-ts                    KeyUsage ::= 1
-      ku-Ticket                       KeyUsage ::= 2
-      ku-EncASRepPart                 KeyUsage ::= 3
-      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
-      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
-      ku-pa-TGSReq-cksum              KeyUsage ::= 6
-      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
-      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
-      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
-      ku-Authenticator-cksum          KeyUsage ::= 10
-      ku-APReq-authenticator          KeyUsage ::= 11
-      ku-EncAPRepPart                 KeyUsage ::= 12
-      ku-EncKrbPrivPart               KeyUsage ::= 13
-      ku-EncKrbCredPart               KeyUsage ::= 14
-      ku-KrbSafe-cksum                KeyUsage ::= 15
-      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
-
-
-
-      -- The following numbers are provisional...
-      -- conflicts may exist elsewhere.
-      ku-Ticket-cksum                 KeyUsage ::= 25
-      ku-ASReq-cksum                  KeyUsage ::= 26
-      ku-TGSReq-cksum                 KeyUsage ::= 27
-      ku-ASRep-cksum                  KeyUsage ::= 28
-      ku-TGSRep-cksum                 KeyUsage ::= 29
-      ku-APReq-cksum                  KeyUsage ::= 30
-      ku-APRep-cksum                  KeyUsage ::= 31
-      ku-KrbCred-cksum                KeyUsage ::= 32
-      ku-KrbError-cksum               KeyUsage ::= 33
-      ku-KDCRep-cksum                 KeyUsage ::= 34
-
-
-
-6.2.  Which Key to Use
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 23]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- KeyToUse identifies which key is to be used to encrypt or
-      -- sign a given value.
-      --
-      -- Values of KeyToUse are never actually transmitted over the
-      -- wire, or even used directly by the implementation in any
-      -- way, as key usages are; it exists primarily to identify
-      -- which key gets used for what purpose.  Thus, the specific
-      -- numeric values associated with this type are irrelevant.
-      KeyToUse        ::= ENUMERATED {
-          -- unspecified
-          key-unspecified,
-          -- server long term key
-          key-server,
-          -- client long term key
-          key-client,
-          -- key selected by KDC for encryption of a KDC-REP
-          key-kdc-rep,
-          -- session key from ticket
-          key-session,
-          -- subsession key negotiated via AP-REQ/AP-REP
-          key-subsession,
-          ...
-      }
-
-
-
-6.3.  EncryptionKey
-
-
-   The "EncryptionKey" type holds an encryption key.
-
-
-      EncryptionKey   ::= SEQUENCE {
-          keytype     [0] EType,
-          keyvalue    [1] OCTET STRING
-      }
-
-
-
-   keytype
-        This "EType" identifies the encryption algorithm, described in
-        [KCRYPTO].
-
-
-   keyvalue
-        Contains the actual key.
-
-
-6.4.  EncryptedData
-
-
-   The "EncryptedData" type contains the encryption of another data
-   type.  The recipient uses fields within EncryptedData to determine
-   which key to use for decryption.
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 24]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-
-      -- "Type" specifies which ASN.1 type is encrypted to the
-      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
-      -- keys of which one key may be used to encrypt the data.
-      -- "KeyUsages" specifies a set of key usages, one of which may
-      -- be used to encrypt.
-      --
-      -- None of the parameters is transmitted over the wire.
-      EncryptedData {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          etype       [0] EType,
-          kvno        [1] UInt32 OPTIONAL,
-          cipher      [2] OCTET STRING (CONSTRAINED BY {
-              -- must be encryption of --
-              OCTET STRING (CONTAINING Type),
-              -- with one of the keys -- KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          }),
-          ...
-      }
-
-
-
-
-   KeyUsages
-        Advisory parameter indicating which key usage to use when
-        encrypting the ciphertext.  If "KeyUsages" indicate multiple
-        "KeyUsage" values, the detailed description of the containing
-        message will indicate which key to use under which conditions.
-
-
-   Type
-        Advisory parameter indicating the ASN.1 type whose DER encoding
-        is the plaintext encrypted into the EncryptedData.
-
-
-   Keys
-        Advisory parameter indicating which key to use to perform the
-        encryption.  If "Keys" indicate multiple "KeyToUse" values, the
-        detailed description of the containing message will indicate
-        which key to use under which conditions.
-
-
-   KeyUsages
-        Advisory parameter indicating which "KeyUsage" value is used to
-        encrypt.  If "KeyUsages" indicates multiple "KeyUsage" values,
-        the detailed description of the containing message will indicate
-        which key usage to use under which conditions.
-
-
-6.5.  Checksums
-
-
-   Several types contain checksums (actually signatures) of data.
-
-
-
-Yu                         Expires: Apr 2005                   [Page 25]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      CksumType       ::= Int32
-
-
-      -- The parameters specify which key to use to produce the
-      -- signature, as well as which key usage to use.  The
-      -- parameters are not actually sent over the wire.
-      Checksum {
-          KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksumtype   [0] CksumType,
-          checksum    [1] OCTET STRING (CONSTRAINED BY {
-              -- signed using one of the keys --
-              KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          })
-      }
-
-
-
-   CksumType
-        Integer type for assigned numbers for signature algorithms.
-        Defined in [KCRYPTO]
-
-
-   Keys
-        As in EncryptedData
-
-
-   KeyUsages
-        As in EncryptedData
-
-
-   cksumtype
-        Signature algorithm used to produce the signature.
-
-
-   checksum
-        The actual checksum.
-
-
-6.5.1.  ChecksumOf
-
-
-   ChecksumOf is similar to "Checksum", but specifies which type is
-   signed.
-
-
-      -- a Checksum that must contain the checksum
-      -- of a particular type
-      ChecksumOf {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
-          ...,
-          checksum (CONSTRAINED BY {
-              -- must be checksum of --
-              OCTET STRING (CONTAINING Type)
-          })
-      })
-
-
-
-Yu                         Expires: Apr 2005                   [Page 26]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   Type
-        Indicates the ASN.1 type whose DER encoding is signed.
-
-
-6.5.2.  Signed
-
-
-   Signed is similar to "ChecksumOf", but contains an actual instance of
-   the type being signed in addition to the signature.
-
-
-      -- parameterized type for wrapping authenticated plaintext
-      Signed {
-          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksum       [0] ChecksumOf {
-              InnerType, Keys, KeyUsages
-          } OPTIONAL,
-          inner       [1] InnerType,
-          ...
-      }
-
-
-
-7.  Tickets
-
-
-   [ A large number of items described here are duplicated in the
-   sections describing KDC-REQ processing.  Should find a way to avoid
-   this duplication. ]
-
-
-   A ticket binds a principal name to a session key.  The important
-   fields of a ticket are in the encrypted part.  The components in
-   common between the RFC 1510 and the extensible versions are
-
-
-      EncTicketPartCommon ::= SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] Realm,
-          cname               [3] PrincipalName,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-
-   crealm
-        This field contains the client's realm.
-
-
-   cname
-        This field contains the client's name.
-
-
-Yu                         Expires: Apr 2005                   [Page 27]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   caddr
-        This field lists the network addresses (if absent, all addresses
-        are permitted) from which the ticket is valid.
-
-
-   Descriptions of the other fields appear in the following sections.
-
-
-7.1.  Timestamps
-
-
-   Three of the ticket timestamps may be requested from the KDC.  The
-   timestamps may differ from those requested, depending on site policy.
-
-
-   authtime
-        The time at which the client authenticated, as recorded by the
-        KDC.
-
-
-   starttime
-        The earliest time when the ticket is valid.  If not present, the
-        ticket is valid starting at the authtime.  This is requested as
-        the "from" field of KDC-REQ-BODY-COMMON.
-
-
-   endtime
-        This time is requested in the "till" field of KDC-REQ-BODY-
-        COMMON.  Contains the time after which the ticket will not be
-        honored (its expiration time).  Note that individual services
-        MAY place their own limits on the life of a ticket and MAY
-        reject tickets which have not yet expired.  As such, this is
-        really an upper bound on the expiration time for the ticket.
-
-
-   renew-till
-        This time is requested in the "rtime" field of KDC-REQ-BODY-
-        COMMON.  It is only present in tickets that have the "renewable"
-        flag set in the flags field.  It indicates the maximum endtime
-        that may be included in a renewal.  It can be thought of as the
-        absolute expiration time for the ticket, including all renewals.
-
-
-7.2.  Ticket Flags
-
-
-   A number of flags may be set in the ticket, further defining some of
-   its capabilities.  Some of these flags map to flags in a KDC request.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 28]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
-
-
-      TicketFlagsBits ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          may-postdate        (5),
-          postdated           (6),
-          invalid             (7),
-          renewable           (8),
-          initial             (9),
-          pre-authent         (10),
-          hw-authent          (11),
-          transited-policy-checked (12),
-          ok-as-delegate      (13),
-          anonymous           (14),
-          cksummed-ticket     (15)
-      }
-
-
-
-7.2.1.  Flags Relating to Initial Ticket Acquisition
-
-
-   [ adapted KCLAR 2.1. ]
-
-
-   Several flags indicate the details of how the initial ticket was
-   acquired.
-
-
-   initial
-        The "initial" flag indicates that a ticket was issued using the
-        AS protocol, rather than issued based on a ticket-granting
-        ticket.  Application servers (e.g., a password-changing program)
-        requiring a client's definite knowledge of its secret key can
-        insist that this flag be set in any tickets they accept, thus
-        being assured that the client's key was recently presented to
-        the application client.
-
-
-   pre-authent
-        The "pre-authent" flag indicates that some sort of pre-
-        authentication was used during the AS exchange.
-
-
-   hw-authent
-        The "hw-authent" flag indicates that some sort of hardware-based
-        pre-authentication occurred during the AS exchange.
-
-
-   Both the "pre-authent" and the "hw-authent" flags may be present with
-   or without the "initial" flag; such tickets with the "initial" flag
-   clear are ones which are derived from initial tickets with the "pre-
-   authent" or "hw-authent" flags set.
-
-
-
-Yu                         Expires: Apr 2005                   [Page 29]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-7.2.2.  Invalid Tickets
-
-
-   [ KCLAR 2.2. ]
-
-
-   The "invalid" flag indicates that a ticket is invalid.  Application
-   servers MUST reject tickets which have this flag set.  A postdated
-   ticket will be issued in this form.  Invalid tickets MUST be
-   validated by the KDC before use, by presenting them to the KDC in a
-   TGS request with the "validate" option specified.  The KDC will only
-   validate tickets after their starttime has passed.  The validation is
-   required so that postdated tickets which have been stolen before
-   their starttime can be rendered permanently invalid (through a hot-
-   list mechanism -- see Section 8.3.2.4).
-
-
-7.2.3.  OK as Delegate
-
-
-   [ KCLAR 2.8. ]
-
-
-   The "ok-as-delegate" flag provides a way for a KDC to communicate
-   local realm policy to a client regarding whether the service for
-   which the ticket is issued is trusted to accept delegated
-   credentials.  For some applications, a client may need to delegate
-   credentials to a service to act on its behalf in contacting other
-   services.  The ability of a client to obtain a service ticket for a
-   service conveys no information to the client about whether the
-   service should be trusted to accept delegated credentials.
-
-
-   The copy of the ticket flags visible to the client may have the "ok-
-   as-delegate" flag set to indicate to the client that the service
-   specified in the ticket has been determined by policy of the realm to
-   be a suitable recipient of delegation.  A client can use the presence
-   of this flag to help it make a decision whether to delegate
-   credentials (either grant a proxy or a forwarded ticket-granting
-   ticket) to this service.  It is acceptable to ignore the value of
-   this flag.  When setting this flag, an administrator should consider
-   the security and placement of the server on which the service will
-   run, as well as whether the service requires the use of delegated
-   credentials.
-
-
-7.2.4.  Renewable Tickets
-
-
-   [ adapted KCLAR 2.3. ]
-
-
-   The "renewable" flag indicates whether the ticket may be renewed.
-
-
-   Renewable tickets can be used to mitigate the consequences of ticket
-   theft.  Applications may desire to hold credentials which can be
-   valid for long periods of time.  However, this can expose the
-   credentials to potential theft for equally long periods, and those
-   stolen credentials would be valid until the expiration time of the
-   ticket(s).  Simply using short-lived tickets and obtaining new ones
-
-
-Yu                         Expires: Apr 2005                   [Page 30]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   periodically would require the application to have long-term access
-   to the client's secret key, which is an even greater risk.
-
-
-   Renewable tickets have two "expiration times": the first is when the
-   current instance of the ticket expires, and the second is the latest
-   permissible value for an individual expiration time.  An application
-   client must periodically present an unexpired renewable ticket to the
-   KDC, setting the "renew" option in the KDC request.  The KDC will
-   issue a new ticket with a new session key and a later expiration
-   time.  All other fields of the ticket are left unmodified by the
-   renewal process.  When the latest permissible expiration time
-   arrives, the ticket expires permanently.  At each renewal, the KDC
-   MAY consult a hot-list to determine if the ticket had been reported
-   stolen since its last renewal; it will refuse to renew such stolen
-   tickets, and thus the usable lifetime of stolen tickets is reduced.
-
-
-   The "renewable" flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can usually be ignored by application
-   servers.  However, some particularly careful application servers MAY
-   disallow renewable tickets.
-
-
-   If a renewable ticket is not renewed by its expiration time, the KDC
-   will not renew the ticket.  The "renewable" flag is clear by default,
-   but a client can request it be set by setting the "renewable" option
-   in the AS-REQ message.  If it is set, then the "renew-till" field in
-   the ticket contains the time after which the ticket may not be
-   renewed.
-
-
-7.2.5.  Postdated Tickets
-
-
-   postdated
-        indicates a ticket which has been postdated
-
-
-   may-postdate
-        indicates that postdated tickets may be issued based on this
-        ticket
-
-
-   [ KCLAR 2.4. ]
-
-
-   Applications may occasionally need to obtain tickets for use much
-   later, e.g., a batch submission system would need tickets to be valid
-   at the time the batch job is serviced.  However, it is dangerous to
-   hold valid tickets in a batch queue, since they will be on-line
-   longer and more prone to theft.  Postdated tickets provide a way to
-   obtain these tickets from the KDC at job submission time, but to
-   leave them "dormant" until they are activated and validated by a
-   further request of the KDC.  If a ticket theft were reported in the
-   interim, the KDC would refuse to validate the ticket, and the thief
-   would be foiled.
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 31]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   The "may-postdate" flag in a ticket is normally only interpreted by
-   the TGS.  It can be ignored by application servers.  This flag MUST
-   be set in a ticket-granting ticket in order for the KDC to issue a
-   postdated ticket based on the presented ticket.  It is reset by
-   default; it MAY be requested by a client by setting the "allow-
-   postdate" option in the AS-REQ [?also TGS-REQ?] message.  This flag
-   does not allow a client to obtain a postdated ticket-granting ticket;
-   postdated ticket-granting tickets can only by obtained by requesting
-   the postdating in the AS-REQ message.  The life (endtime minus
-   starttime) of a postdated ticket will be the remaining life of the
-   ticket-granting ticket at the time of the request, unless the
-   "renewable" option is also set, in which case it can be the full life
-   (endtime minus starttime) of the ticket-granting ticket.  The KDC MAY
-   limit how far in the future a ticket may be postdated.
-
-
-   The "postdated" flag indicates that a ticket has been postdated.  The
-   application server can check the authtime field in the ticket to see
-   when the original authentication occurred.  Some services MAY choose
-   to reject postdated tickets, or they may only accept them within a
-   certain period after the original authentication.  When the KDC
-   issues a "postdated" ticket, it will also be marked as "invalid", so
-   that the application client MUST present the ticket to the KDC for
-   validation before use.
-
-
-7.2.6.  Proxiable and Proxy Tickets
-
-
-   proxy
-        indicates a proxy ticket
-
-
-   proxiable
-        indicates that proxy tickets may be issued based on this ticket
-
-
-   [ KCLAR 2.5. ]
-
-
-   It may be necessary for a principal to allow a service to perform an
-   operation on its behalf.  The service must be able to take on the
-   identity of the client, but only for a particular purpose.  A
-   principal can allow a service to take on the principal's identity for
-   a particular purpose by granting it a proxy.
-
-
-   The process of granting a proxy using the "proxy" and "proxiable"
-   flags is used to provide credentials for use with specific services.
-   Though conceptually also a proxy, users wishing to delegate their
-   identity in a form usable for all purposes MUST use the ticket
-   forwarding mechanism described in the next section to forward a
-   ticket-granting ticket.
-
-
-   The "proxiable" flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can be ignored by application servers.
-   When set, this flag tells the ticket-granting server that it is OK to
-   issue a new ticket (but not a ticket-granting ticket) with a
-
-
-Yu                         Expires: Apr 2005                   [Page 32]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   different network address based on this ticket.  This flag is set if
-   requested by the client on initial authentication.  By default, the
-   client will request that it be set when requesting a ticket-granting
-   ticket, and reset when requesting any other ticket.
-
-
-   This flag allows a client to pass a proxy to a server to perform a
-   remote request on its behalf (e.g. a print service client can give
-   the print server a proxy to access the client's files on a particular
-   file server in order to satisfy a print request).
-
-
-   In order to complicate the use of stolen credentials, Kerberos
-   tickets may contain a set of network addresses from which they are
-   valid.  When granting a proxy, the client MUST specify the new
-   network address from which the proxy is to be used, or indicate that
-   the proxy is to be issued for use from any address.
-
-
-   The "proxy" flag is set in a ticket by the TGS when it issues a proxy
-   ticket.  Application servers MAY check this flag and at their option
-   they MAY require additional authentication from the agent presenting
-   the proxy in order to provide an audit trail.
-
-
-7.2.7.  Forwarded and Forwardable Tickets
-
-
-   forwarded
-        indicates a forwarded ticket
-
-
-   forwardable
-        indicates that forwarded tickets may be issued based on this
-        ticket
-
-
-   [ KCLAR 2.6. ]
-
-
-   Authentication forwarding is an instance of a proxy where the service
-   that is granted is complete use of the client's identity.  An example
-   where it might be used is when a user logs in to a remote system and
-   wants authentication to work from that system as if the login were
-   local.
-
-
-   The "forwardable" flag in a ticket is normally only interpreted by
-   the ticket-granting service.  It can be ignored by application
-   servers.  The "forwardable" flag has an interpretation similar to
-   that of the "proxiable" flag, except ticket-granting tickets may also
-   be issued with different network addresses.  This flag is reset by
-   default, but users MAY request that it be set by setting the
-   "forwardable" option in the AS request when they request their
-   initial ticket-granting ticket.
-
-
-   This flag allows for authentication forwarding without requiring the
-   user to enter a password again.  If the flag is not set, then
-   authentication forwarding is not permitted, but the same result can
-   still be achieved if the user engages in the AS exchange specifying
-
-
-Yu                         Expires: Apr 2005                   [Page 33]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   the requested network addresses and supplies a password.
-
-
-   The "forwarded" flag is set by the TGS when a client presents a
-   ticket with the "forwardable" flag set and requests a forwarded
-   ticket by specifying the "forwarded" KDC option and supplying a set
-   of addresses for the new ticket.  It is also set in all tickets
-   issued based on tickets with the "forwarded" flag set.  Application
-   servers may choose to process "forwarded" tickets differently than
-   non-forwarded tickets.
-
-
-   If addressless tickets are forwarded from one system to another,
-   clients SHOULD still use this option to obtain a new TGT in order to
-   have different session keys on the different systems.
-
-
-7.3.  Transited Realms
-
-
-   [ KCLAR 2.7., plus new stuff ]
-
-
-7.4.  Authorization Data
-
-
-   [ KCLAR 5.2.6. ]
-
-
-      ADType          ::= TH-id
-
-
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-          ad-type             [0] ADType,
-          ad-data             [1] OCTET STRING
-      }
-
-
-
-   ad-type
-        This field identifies the contents of the ad-data.  All negative
-        values are reserved for local use.  Non-negative values are
-        reserved for registered use.
-
-
-   ad-data
-        This field contains authorization data to be interpreted
-        according to the value of the corresponding ad-type field.
-
-
-   Each sequence of ADType and OCTET STRING is referred to as an
-   authorization element.  Elements MAY be application specific,
-   however, there is a common set of recursive elements that should be
-   understood by all implementations.  These elements contain other
-   AuthorizationData, and the interpretation of the encapsulating
-   element determines which enclosed elements must be interpreted, and
-   which may be ignored.
-
-
-   Depending on the meaning of the encapsulating element, the
-   encapsulated AuthorizationData may be ignored, interpreted as issued
-   directly by the KDC, or be stored in a separate plaintext part of the
-   ticket.  The types of the encapsulating elements are specified as
-
-
-Yu                         Expires: Apr 2005                   [Page 34]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   part of the Kerberos protocol because behavior based on these
-   container elements should be understood across implementations, while
-   other elements need only be understood by the applications which they
-   affect.
-
-
-   Authorization data elements are considered critical if present in a
-   ticket or authenticator.  Unless encapsulated in a known
-   authorization data element modifying the criticality of the elements
-   it contains, an application server MUST reject the authentication of
-   a client whose AP-REQ or ticket contains an unrecognized
-   authorization data element.  Authorization data is intended to
-   restrict the use of a ticket.  If the service cannot determine
-   whether it is the target of a restriction, a security weakness may
-   exist if the ticket can be used for that service.  Authorization
-   elements that are truly optional can be enclosed in AD-IF-RELEVANT
-   element.
-
-
-
-      ad-type |           contents of ad-data
-      ________|_______________________________________
-            1 |   DER encoding of AD-IF-RELEVANT
-            4 |   DER encoding of AD-KDCIssued
-            5 |   DER encoding of AD-AND-OR
-            8 |   DER encoding of AD-MANDATORY-FOR-KDC
-
-
-
-
-7.4.1.  AD-IF-RELEVANT
-
-
-      ad-if-relevant          ADType ::= int32 : 1
-
-
-      -- Encapsulates another AuthorizationData.
-      -- Intended for application servers; receiving application servers
-      -- MAY ignore.
-      AD-IF-RELEVANT          ::= AuthorizationData
-
-
-   AD elements encapsulated within the if-relevant element are intended
-   for interpretation only by application servers that understand the
-   particular ad-type of the embedded element. Application servers that
-   do not understand the type of an element embedded within the if-
-   relevant element MAY ignore the uninterpretable element. This element
-   promotes interoperability across implementations which may have local
-   extensions for authorization.  The ad-type for AD-IF-RELEVANT is (1).
-
-
-7.4.2.  AD-KDCIssued
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 35]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- KDC-issued privilege attributes
-      ad-kdcissued            ADType ::= int32 : 4
-
-
-      AD-KDCIssued            ::= SEQUENCE {
-          ad-checksum [0] ChecksumOf {
-                              AuthorizationData, { key-session },
-                              { ku-ad-KDCIssued-cksum }},
-          i-realm     [1] Realm OPTIONAL,
-          i-sname     [2] PrincipalName OPTIONAL,
-          elements    [3] AuthorizationData
-      }
-
-
-
-   ad-checksum
-        A cryptographic checksum computed over the DER encoding of the
-        AuthorizationData in the "elements" field, keyed with the
-        session key.  Its checksumtype is the mandatory checksum type
-        for the encryption type of the session key, and its key usage
-        value is 19.
-
-
-   i-realm, i-sname
-        The name of the issuing principal if different from the KDC
-        itself.  This field would be used when the KDC can verify the
-        authenticity of elements signed by the issuing principal and it
-        allows this KDC to notify the application server of the validity
-        of those elements.
-
-
-   elements
-        AuthorizationData issued by the KDC.
-
-
-   The KDC-issued ad-data field is intended to provide a means for
-   Kerberos credentials to embed within themselves privilege attributes
-   and other mechanisms for positive authorization, amplifying the
-   privileges of the principal beyond what it would have if using
-   credentials without such an authorization-data element.
-
-
-   This amplification of privileges cannot be provided without this
-   element because the definition of the authorization-data field allows
-   elements to be added at will by the bearer of a TGT at the time that
-   they request service tickets and elements may also be added to a
-   delegated ticket by inclusion in the authenticator.
-
-
-   For KDC-issued elements this is prevented because the elements are
-   signed by the KDC by including a checksum encrypted using the
-   server's key (the same key used to encrypt the ticket -- or a key
-   derived from that key).  AuthorizationData encapsulated with in the
-   AD-KDCIssued element MUST be ignored by the application server if
-   this "signature" is not present.  Further, AuthorizationData
-   encapsulated within this element from a ticket-granting ticket MAY be
-   interpreted by the KDC, and used as a basis according to policy for
-   including new signed elements within derivative tickets, but they
-
-
-Yu                         Expires: Apr 2005                   [Page 36]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   will not be copied to a derivative ticket directly.  If they are
-   copied directly to a derivative ticket by a KDC that is not aware of
-   this element, the signature will not be correct for the application
-   ticket elements, and the field will be ignored by the application
-   server.
-
-
-   This element and the elements it encapsulates MAY be safely ignored
-   by applications, application servers, and KDCs that do not implement
-   this element.
-
-
-   The ad-type for AD-KDC-ISSUED is (4).
-
-
-7.4.3.  AD-AND-OR
-
-
-      ad-and-or               ADType ::= int32 : 5
-
-
-      AD-AND-OR               ::= SEQUENCE {
-          condition-count     [0] INTEGER,
-          elements            [1] AuthorizationData
-      }
-
-
-
-   When restrictive AD elements are encapsulated within the and-or
-   element, the and-or element is considered satisfied if and only if at
-   least the number of encapsulated elements specified in condition-
-   count are satisfied.  Therefore, this element MAY be used to
-   implement an "or" operation by setting the condition-count field to
-   1, and it MAY specify an "and" operation by setting the condition
-   count to the number of embedded elements. Application servers that do
-   not implement this element MUST reject tickets that contain
-   authorization data elements of this type.
-
-
-   The ad-type for AD-AND-OR is (5).
-
-
-7.4.4.  AD-MANDATORY-FOR-KDC
-
-
-      -- KDCs MUST interpret any AuthorizationData wrapped in this.
-      ad-mandatory-for-kdc            ADType ::= int32 : 8
-      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
-
-
-   AD elements encapsulated within the mandatory-for-kdc element are to
-   be interpreted by the KDC.  KDCs that do not understand the type of
-   an element embedded within the mandatory-for-kdc element MUST reject
-   the request.
-
-
-   The ad-type for AD-MANDATORY-FOR-KDC is (8).
-
-
-7.5.  Encrypted Part of Ticket
-
-
-   The complete definition of the encrypted part is
-
-
-
-Yu                         Expires: Apr 2005                   [Page 37]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- Encrypted part of ticket
-      EncTicketPart ::= CHOICE {
-          rfc1510     [APPLICATION 3] EncTicketPart1510,
-          ext         [APPLICATION 5] EncTicketPartExt
-      }
-
-
-   with the common portion being
-
-
-      EncTicketPartCommon ::= SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] Realm,
-          cname               [3] PrincipalName,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-
-   The encrypted part of the backwards-compatibility form of a ticket
-   is:
-
-
-      EncTicketPart1510 ::= SEQUENCE {
-          COMPONENTS OF EncTicketPartCommon
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-
-   The encrypted part of the extensible form of a ticket is:
-
-
-      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          crealm (RealmExt),
-          cname (PrincipalNameExt),
-          -- explicitly constrain caddr to be non-empty if present
-          caddr (SIZE (1..MAX)),
-          -- forbid empty authorization-data encodings
-          authorization-data (SIZE (1..MAX))
-      })
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 38]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-7.6.  Cleartext Part of Ticket
-
-
-   The complete definition of Ticket is:
-
-
-      Ticket          ::= CHOICE {
-          rfc1510     [APPLICATION 1] Ticket1510,
-          ext         [APPLICATION 4] Signed {
-              TicketExt, { key-server }, { ku-Ticket-cksum }
-          }
-      }
-
-
-   with the common portion being:
-
-
-      -- takes a parameter specifying which type gets encrypted
-      TicketCommon { EncPart } ::= SEQUENCE {
-          tkt-vno     [0] INTEGER (5),
-          realm       [1] Realm,
-          sname       [2] PrincipalName,
-          enc-part    [3] EncryptedData {
-              EncPart, { key-server }, { ku-Ticket }
-          },
-          ...,
-          extensions          [4] TicketExtensions OPTIONAL,
-          ...
-      }
-
-
-
-   The "sname" field provides the name of the target service principal
-   in cleartext, as a hint to aid the server in choosing the correct
-   decryption key.
-
-
-   The backwards-compatibility form of Ticket is:
-
-
-      Ticket1510 ::= SEQUENCE {
-          COMPONENTS OF TicketCommon { EncTicketPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          realm (RealmIA5),
-          sname (PrincipalNameIA5)
-      })
-
-
-   The extensible form of Ticket is:
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 39]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      TicketExt ::= [APPLICATION 4] TicketCommon {
-          EncTicketPartExt
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          realm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-
-   TicketExtensions, which may only be present in the extensible form of
-   Ticket, are a cleartext typed hole for extension use.
-   AuthorizationData already provides an encrypted typed hole.
-
-
-      TEType                  ::= TH-id
-
-
-      -- ticket extensions: for TicketExt only
-      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          te-type             [0] TEType,
-          te-data             [1] OCTET STRING
-      }
-
-
-
-   A client will only receive an extensible Ticket if the application
-   server supports extensibility.
-
-
-8.  Credential Acquisition
-
-
-   There are two exchanges that can be used for acquiring credentials:
-   the AS exchange and the TGS exchange.  These exchanges have many
-   similarities, and this document describes them in parallel, noting
-   which behaviors are specific to one type of exchange.  The AS request
-   (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests
-   (KDC-REQ).  Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP)
-   are forms of KDC replies (KDC-REP).
-
-
-   The credentials acquisition protocol operates over specific
-   transports.  Additionally, specific methods exist to permit a client
-   to discover the KDC host with which to communicate.
-
-
-8.1.  KDC-REQ
-
-
-   The KDC-REQ has a large number of fields in common between the RFC
-   1510 and the extensible versions.  The KDC-REQ type itself is never
-   directly encoded; it is always a part of a AS-REQ or a TGS-REQ.
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 40]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KDC-REQ-COMMON  ::= SEQUENCE {
-      -- NOTE: first tag is [1], not [0]
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
-                                   | 12 -- TGS-REQ.rfc1510 --
-                                   | 6 -- AS-REQ.ext --
-                                   | 8 -- TGS-REQ.ext -- ),
-          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
-          -- NOTE: not empty
-      }
-
-
-
-      KDC-REQ-BODY-COMMON     ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalName OPTIONAL
-          -- Used only in AS-REQ --,
-
-
-          realm               [2] Realm
-          -- Server's realm; also client's in AS-REQ --,
-
-
-          sname               [3] PrincipalName OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime OPTIONAL
-          -- was required in rfc1510;
-          -- still required for compat versions
-          -- of messages --,
-
-
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --,
-          ...
-          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
-                              LangTag OPTIONAL,
-          ...
-      }
-
-
-
-   Many fields of KDC-REQ-BODY-COMMON correspond directly to fields of
-   an EncTicketPartCommon.  The KDC copies most of them unchanged,
-   provided that the requested values meet site policy.
-
-
-Yu                         Expires: Apr 2005                   [Page 41]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   kdc-options
-        These flags do not correspond directly to "flags" in
-        EncTicketPartCommon.
-
-
-   cname
-        This field is copied to the "cname" field in
-        EncTicketPartCommon.  The "cname" field is required in an AS-
-        REQ; the client places its own name here.  In a TGS-REQ, the
-        "cname" in the ticket in the AP-REQ takes precedence.
-
-
-   realm
-        This field is the server's realm, and also holds the client's
-        realm in an AS-REQ.
-
-
-   sname
-        The "sname" field indicates the server's name.  It may be absent
-        in a TGS-REQ which requests user-to-user authentication, in
-        which case the "sname" of the issued ticket will be taken from
-        the included additional ticket.
-
-
-   The "from", "till", and "rtime" fields correspond to the "starttime",
-   "endtime", and "renew-till" fields of EncTicketPartCommon.
-
-
-   addresses
-        This field corresponds to the "caddr" field of
-        EncTicketPartCommon.
-
-
-   enc-authorization-data
-        For TGS-REQ, this field contains authorization data encrypted
-        using either the TGT session key or the AP-REQ subsession key;
-        the KDC may copy these into the "authorization-data" field of
-        EncTicketPartCommon if policy permits.
-
-
-   lang-tags
-        Only present in the extensible messages.  Specifies the set of
-        languages which the client is willing to accept in error
-        messages.
-
-
-   KDC options used in a KDC-REQ are:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 42]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
-
-
-      KDCOptionsBits  ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          allow-postdate      (5),
-          postdated           (6),
-          unused7             (7),
-          renewable           (8),
-          unused9             (9),
-          unused10            (10),
-          unused11            (11),
-          unused12            (12),
-          unused13            (13),
-          requestanonymous    (14),
-          canonicalize        (15),
-          disable-transited-check (26),
-          renewable-ok        (27),
-          enc-tkt-in-skey     (28),
-          renew               (30),
-          validate            (31)
-          -- XXX need "need ticket1" flag?
-      }
-
-
-   Different options apply to different phases of KDC-REQ processing.
-
-
-   The backwards-compatibility form of a KDC-REQ is:
-
-
-      KDC-REQ-1510    ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-1510
-      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
-
-
-   The extensible form of a KDC-REQ is:
-
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      KDC-REQ-EXT     ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-EXT,
-          ...
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (6 | 8),
-          padata (SIZE (1..MAX))
-      })
-
-
-   The backwards-compatibility form of a KDC-REQ-BODY is:
-
-
-Yu                         Expires: Apr 2005                   [Page 43]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KDC-REQ-BODY-1510 ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-BODY-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          cname (PrincipalNameIA5),
-          realm (RealmIA5),
-          sname (PrincipalNameIA5),
-          till PRESENT,
-          nonce (UInt32)
-      })
-
-
-   The extensible form of a KDC-REQ-BODY is:
-
-
-      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
-      (WITH COMPONENTS {
-          ...,
-          cname (PrincipalNameExt),
-          realm (RealmExt),
-          sname (PrincipalNameExt),
-          addresses (SIZE (1..MAX)),
-          enc-authorization-data (EncryptedData {
-              AuthorizationData (SIZE (1..MAX)),
-              { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          }),
-          additional-tickets (SIZE (1..MAX))
-      })
-
-
-   The AS-REQ is:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 44]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      AS-REQ  ::= CHOICE {
-          rfc1510     [APPLICATION 10] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (10),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          }),
-          ext         [APPLICATION 6]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as
-              -- outside, to prevent possible substitution attacks.
-              [APPLICATION 6] KDC-REQ-EXT,
-              -- not sure this is correct key to use; do we even want
-              -- to sign AS-REQ?
-              { key-client },
-              { ku-ASReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (6),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          })
-      }
-
-
-   A client SHOULD NOT send the extensible AS-REQ alternative to a KDC
-   if the client does not know that the KDC supports the extensibility
-   framework.  A client SHOULD send the extensible AS-REQ alternative in
-   a PA-AS-REQ PA-DATA.  A KDC supporting extensibility will treat the
-   AS-REQ contained within the PA-AS-REQ as the actual AS-REQ.  [ XXX
-   what if their contents conflict? ]
-
-
-   The TGS-REQ is:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 45]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      TGS-REQ ::= CHOICE {
-          rfc1510     [APPLICATION 12] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (12),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          }),
-          ext         [APPLICATION 8]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as
-              -- outside, to prevent possible substitution attacks.
-              [APPLICATION 8] KDC-REQ-EXT,
-              { key-session }, { ku-TGSReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (8),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          })
-      }
-
-
-
-8.2.  PA-DATA
-
-
-   PA-DATA have multiple uses in the Kerberos protocol.  They may pre-
-   authenticate an AS-REQ; they may also modify several of the
-   encryption keys used in a KDC-REP.  PA-DATA may also provide "hints"
-   to the client about which long-term key (usually password-derived) to
-   use.  PA-DATA may also include "hints" about which pre-authentication
-   mechanisms to use, or include data for input into a pre-
-   authentication mechanism.
-
-
-   [ XXX enumerate standard padata here ]
-
-
-8.3.  KDC-REQ Processing
-
-
-   Processing of a KDC-REQ proceeds through several steps.  An
-   implementation need not perform these steps exactly as described, as
-   long as it behaves as if the steps were performed as described.  The
-   KDC performs replay handling upon receiving the request; it then
-   validates the request, adjusts timestamps, and selects the keys used
-   in the reply.  It copies data from the request into the issued
-   ticket, adjusting the values to conform with its policies.  The KDC
-   then transmits the reply to the client.
-
-
-8.3.1.  Handling Replays
-
-
-   Because Kerberos can run over unreliable transports such as UDP, the
-   KDC MUST be prepared to retransmit responses in case they are lost.
-   If a KDC receives a request identical to one it has recently
-
-
-Yu                         Expires: Apr 2005                   [Page 46]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   successfully processed, the KDC MUST respond with a KDC-REP message
-   rather than a replay error.  In order to reduce the amount of
-   ciphertext given to a potential attacker, KDCs MAY send the same
-   response generated when the request was first handled.  KDCs MUST
-   obey this replay behavior even if the actual transport in use is
-   reliable.  If the AP-REQ which authenticates a TGS-REQ is a replay,
-   and the entire request is not identical to a recently successfully
-   processed request, the KDC SHOULD return "krb-ap-err-repeat", as is
-   appropriate for AP-REQ processing.
-
-
-8.3.2.  Request Validation
-
-
-8.3.2.1.  AS-REQ Authentication
-
-
-   Site policy determines whether a given client principal is required
-   to provide some pre-authentication prior to receiving an AS-REP.
-   Since the default reply key is typically the client's long-term
-   password-based key, an attacker may easily request known plaintext
-   (in the form of an AS-REP) upon which to mount a dictionary attack.
-   Pre-authentication can limit the possibility of such an attack.
-
-
-   If site policy requires pre-authentication for a client principal,
-   and no pre-authentication is provided, the KDC returns the error
-   "kdc-err-preauth-required".  Accompanying this error are "e-data"
-   which include hints telling the client which pre-authentication
-   mechanisms to use, or data for input to pre-authentication mechanisms
-   (e.g., input to challenge-response systems).  If pre-authentication
-   fails, the KDC returns the error "kdc-err-preauth-failed".
-
-
-   [ may need additional changes based on Sam's preauth draft ]
-
-
-8.3.2.2.  TGS-REQ Authentication
-
-
-   A TGS-REQ has an accompanying AP-REQ, which is included in the "pa-
-   tgs-req".  The KDC MUST validate the checksum in the Authenticator of
-   the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ-
-   BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the
-   request.  [ padata not signed by authenticator! ] Any error from the
-   AP-REQ validation process SHOULD be returned in a KRB-ERROR message.
-   The service principal in the ticket of the AP-REQ may be a ticket-
-   granting service principal, or a normal application service
-   principal.  A ticket which is not a ticket-granting ticket MUST NOT
-   be used to issue a ticket for any service other than the one named in
-   the ticket.  In this case, the "renew", "validate", or "proxy" [?also
-   forwarded?]  option must be set in the request.
-
-
-8.3.2.3.  Principal Validation
-
-
-   If the client principal in an AS-REQ is unknown, the KDC returns the
-   error "kdc-err-c-principal-unknown".  If the server principal in a
-   KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal-
-
-
-Yu                         Expires: Apr 2005                   [Page 47]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   unknown".
-
-
-8.3.2.4.  Checking For Revoked or Invalid Tickets
-
-
-   [ KCLAR 3.3.3.1 ]
-
-
-   Whenever a request is made to the ticket-granting server, the
-   presented ticket(s) is(are) checked against a hot-list of tickets
-   which have been canceled.  This hot-list might be implemented by
-   storing a range of issue timestamps for "suspect tickets"; if a
-   presented ticket had an authtime in that range, it would be rejected.
-   In this way, a stolen ticket-granting ticket or renewable ticket
-   cannot be used to gain additional tickets (renewals or otherwise)
-   once the theft has been reported to the KDC for the realm in which
-   the server resides.  Any normal ticket obtained before it was
-   reported stolen will still be valid (because they require no
-   interaction with the KDC), but only until their normal expiration
-   time.  If TGTs have been issued for cross-realm authentication, use
-   of the cross-realm TGT will not be affected unless the hot-list is
-   propagated to the KDCs for the realms for which such cross-realm
-   tickets were issued.
-
-
-   If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT
-   issue any ticket unless the TGS-REQ requests the "validate" option.
-
-
-8.3.3.  Timestamp Handling
-
-
-   [ some aspects of timestamp handling, especially regarding postdating
-   and renewal, are difficult to read in KCLAR... needs closer
-   examination here ]
-
-
-   Processing of "starttime" (requested in the "from" field) differs
-   depending on whether the "postdated" option is set in the request.
-   If the "postdated" option is not set, and the requested "starttime"
-   is in the future beyond the window of acceptable clock skew, the KDC
-   returns the error "kdc-err-cannot-postdate".  If the "postdated"
-   option is not set, and the requested "starttime" is absent or does
-   not indicate a time in the future beyond the acceptable clock skew,
-   the KDC sets the "starttime" to the KDC's current time.  The
-   "postdated" option MUST NOT be honored if the ticket is being
-   requested by TGS-REQ and the "may-postdate" is not set in the TGT.
-   Otherwise, if the "postdated" option is set, and site policy permits,
-   the KDC sets the "starttime" as requested, and sets the "invalid"
-   flag in the new ticket.
-
-
-   The "till" field is required in the RFC 1510 version of the KDC-REQ.
-   If the "till" field is equal to "19700101000000Z" (midnight, January
-   1, 1970), the KDC SHOULD behave as if the "till" field were absent.
-
-
-   The KDC MUST NOT issue a ticket whose "starttime", "endtime", or
-   "renew-till" time is later than the "renew-till" time of the ticket
-
-
-Yu                         Expires: Apr 2005                   [Page 48]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   from which it is derived.
-
-
-8.3.3.1.  AS-REQ Timestamp Processing
-
-
-   In the AS exchange, the "authtime" of a ticket is set to the local
-   time at the KDC.
-
-
-   The "endtime" of the ticket will be set to the earlier of the
-   requested "till" time and a time determined by local policy, possibly
-   determined using factors specific to the realm or principal.  For
-   example, the expiration time MAY be set to the earliest of the
-   following:
-
-
-      * the expiration time ("till" value) requested
-
-
-      * the ticket's start time plus the maximum allowable lifetime
-        associated with the client principal from the authentication
-        server's database
-
-
-      * the ticket's start time plus the maximum allowable lifetime
-        associated with the server principal
-
-
-      * the ticket's start time plus the maximum lifetime set by the
-        policy of the local realm
-
-
-   If the requested expiration time minus the start time (as determined
-   above) is less than a site-determined minimum lifetime, an error
-   message with code "kdc-err-never-valid" is returned.  If the
-   requested expiration time for the ticket exceeds what was determined
-   as above, and if the "renewable-ok" option was requested, then the
-   "renewable" flag is set in the new ticket, and the "renew-till" value
-   is set as if the "renewable" option were requested.
-
-
-   If the "renewable" option has been requested or if the "renewable-ok"
-   option has been set and a renewable ticket is to be issued, then the
-   "renew-till" field MAY be set to the earliest of:
-
-
-      * its requested value
-
-
-      * the start time of the ticket plus the minimum of the two maximum
-        renewable lifetimes associated with the principals' database
-        entries
-
-
-      * the start time of the ticket plus the maximum renewable lifetime
-        set by the policy of the local realm
-
-
-8.3.3.2.  TGS-REQ Timestamp Processing
-
-
-   In the TGS exchange, the KDC sets the "authtime" to that of the
-   ticket in the AP-REQ authenticating the TGS-REQ.  [?application
-   server can print a ticket for itself with a spoofed authtime.
-
-
-Yu                         Expires: Apr 2005                   [Page 49]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   security issues for hot-list?] [ MIT implementation may change
-   authtime of renewed tickets; needs check... ]
-
-
-   If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ
-   requests an "endtime" (in the "till" field), then the "endtime" of
-   the new ticket is set to the minimum of
-
-
-      * the requested "endtime" value,
-
-
-      * the "endtime" in the TGT, and
-
-
-      * an "endtime" determined by site policy on ticket lifetimes.
-
-
-   If the new ticket is a renewal, the "endtime" of the new ticket is
-   bounded by the minimum of
-
-
-      * the requested "endtime" value,
-
-
-      * the value of the "renew-till" value of the old,
-
-
-      * the "starttime" of the new ticket plus the lifetime (endtime
-        minus starttime) of the old ticket, i.e., the lifetime of the
-        new ticket may not exceed that of the ticket being renewed [
-        adapted from KCLAR 3.3.3. ], and
-
-
-      * an "endtime" determined by site policy on ticket lifetimes.
-
-
-   When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with
-   a "starttime", "endtime", or "renew-till" time later than the
-   "renew-till" time of the TGT.
-
-
-8.3.4.  Handling Transited Realms
-
-
-   The KDC checks the ticket in a TGS-REQ against site policy, unless
-   the "disable-transited-check" option is set in the TGS-REQ.  If site
-   policy permits the transit path in the TGS-REQ ticket, the KDC sets
-   the "transited-policy-checked" flag in the issued ticket.  If the
-   "disable-transited-check" option is set, the issued ticket will have
-   the "transited-policy-checked" flag cleared.
-
-
-8.3.5.  Address Processing The requested "addresses" in the KDC-REQ are
-   copied into the issued ticket.  If the "addresses" field is absent or
-   empty in a TGS-REQ, the KDC copies addresses from the ticket in the
-   TGS-REQ into the issued ticket, unless the either "forwarded" or
-   "proxy" option is set.  If the "forwarded" option is set, and the
-   ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies
-   the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the
-   issued ticket.  The KDC behaves similarly if the "proxy" option is
-   set in the TGS-REQ and the "proxiable" flag is set in the ticket.
-   The "proxy" option will not be honored on requests for additional
-   ticket-granting tickets.
-
-
-Yu                         Expires: Apr 2005                   [Page 50]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-8.3.6.  Ticket Flag Processing
-
-
-   Many kdc-options request that the KDC set a corresponding flag in the
-   issued ticket.  kdc-options marked with an asterisk (*) in the
-   following table do not directly request the corresponding ticket flag
-   and therefore require special handling.
-
-
-
-             kdc-option       |    ticket flag affected
-      ________________________|__________________________
-      forwardable             |  forwardable
-      forwarded               |  forwarded
-      proxiable               |  proxiable
-      proxy                   |  proxy
-      allow-postdate          |  may-postdate
-      postdated               |  postdated
-      renewable               |  renewable
-      requestanonymous        |  anonymous
-      canonicalize            |  -
-      disable-transited-check*|  transited-policy-checked
-      renewable-ok*           |  renewable
-      enc-tkt-in-skey         |  -
-      renew                   |  -
-      validate*               |  invalid
-
-
-
-
-   forwarded
-        The KDC sets the "forwarded" flag in the issued ticket if the
-        "forwarded" option is set in the TGS-REQ and the "forwardable"
-        flag is set in the TGS-REQ ticket.
-
-
-   proxy
-        The KDC sets the "proxy" flag in the issued ticket if the
-        "proxy" option is set in the TGS-REQ and the "proxiable" flag is
-        set in the TGS-REQ ticket.
-
-
-   disable-transited-check
-        The handling of the "disable-transited-check" kdc-option is
-        described in Section 8.3.4.
-
-
-   renewable-ok
-        The handling of the "renewable-ok" kdc-option is described in
-        Section 8.3.3.1.
-
-
-   enc-tkt-in-skey
-        This flag modifies ticket key selection to use the session key
-        of an additional ticket included in the TGS-REQ, for the purpose
-        of user-to-user authentication.
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 51]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   validate
-        If the "validate" kdc-option is set in a TGS-REQ, and the
-        "starttime" has passed, the KDC will clear the "invalid" bit on
-        the ticket before re-issuing it.
-
-
-8.3.7.  Key Selection
-
-
-   Three keys are involved in creating a KDC-REP.  The reply key
-   encrypts the encrypted part of the KDC-REP.  The session key is
-   stored in the encrypted part of the ticket, and is also present in
-   the encrypted part of the KDC-REP so that the client can retrieve it.
-   The ticket key is used to encrypt the ticket.  These keys all have
-   initial values for a given exchange; pre-authentication and other
-   extension mechanisms may change the value used for any of these keys.
-
-
-   [ again, may need changes based on Sam's preauth draft ]
-
-
-8.3.7.1.  Reply Key and Session Key Selection
-
-
-   The set of encryption types which the client will understand appears
-   in the "etype" field of KDC-REQ-BODY-COMMON.  The KDC limits the set
-   of possible reply keys and the set of session key encryption types
-   based on the "etype" field.
-
-
-   For the AS exchange, the reply key is initially a long-term key of
-   the client, limited to those encryption types listed in the "etype"
-   field.  The KDC SHOULD use the first valid strong "etype" for which
-   an encryption key is available.  For the TGS exchange, the reply key
-   is initially the subsession key of the Authenticator.  If the
-   Authenticator subsesion key is absent, the reply key is initially the
-   session key of the ticket used to authenticate the TGS-REQ.
-
-
-   The session key is initially randomly generated, and has an
-   encryption type which both the client and the server will understand.
-   Typically, the KDC has prior knowledge of which encryption types the
-   server will understand.  It selects the first valid strong "etype"
-   listed the request which the server also will understand.
-
-
-8.3.7.2.  Ticket Key Selection
-
-
-   The ticket key is initially the long-term key of the service.  The
-   "enc-tkt-in-skey" option requests user-to-user authentication, where
-   the ticket encryption key of the issued ticket is set equal to the
-   session key of the additional ticket in the request.
-
-
-8.4.  KDC-REP
-
-
-   The important parts of the KDC-REP are encrypted.
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 52]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
-      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
-
-
-      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
-      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
-
-
-      EncKDCRepPartCom        ::= SEQUENCE {
-          key                 [0] EncryptionKey,
-          last-req            [1] LastReq,
-          nonce               [2] Nonce,
-          key-expiration      [3] KerberosTime OPTIONAL,
-          flags               [4] TicketFlags,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          srealm              [9] Realm,
-          sname               [10] PrincipalName,
-          caddr               [11] HostAddresses OPTIONAL,
-          ...
-      }
-
-
-      EncKDCRepPart1510       ::= SEQUENCE {
-          COMPONENTS OF EncKDCRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          srealm (RealmIA5),
-          sname (PrincipalNameIA5),
-          nonce UInt32 })
-
-
-      EncKdcRepPartExt        ::= EncKDCRepPartCom (WITH COMPONENTS {
-          ...,
-          srealm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-
-   Most of the fields of EncKDCRepPartCom are duplicates of the
-   corresponding fields in the returned ticket.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 53]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
-                                   13 -- TGS.rfc1510 -- |
-                                   7 -- AS-REP.ext -- |
-                                   9 -- TGS-REP.ext -- ),
-          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
-          crealm      [3] Realm,
-          cname       [4] PrincipalName,
-          ticket      [5] Ticket,
-
-
-          enc-part    [6] EncryptedData {
-              EncPart,
-              { key-reply },
-              -- maybe reach into EncryptedData in AS-REP/TGS-REP
-              -- definitions to apply constraints on key usages?
-              { ku-EncASRepPart -- if AS-REP -- |
-                ku-EncTGSRepPart-subkey -- if TGS-REP and
-                                        -- using Authenticator
-                                        -- session key -- |
-                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
-                                         -- subsession key -- }
-          },
-
-
-          ...,
-          -- In extensible version, KDC signs original request
-          -- to avoid replay attacks against client.
-          req-cksum   [7] ChecksumOf { CHOICE {
-              as-req          AS-REQ,
-              tgs-req         TGS-REQ
-          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
-          lang-tag    [8] LangTag OPTIONAL,
-          ...
-      }
-
-
-
-      KDC-REP-1510 { EncPart } ::= SEQUENCE {
-          COMPONENTS OF KDC-REP-COMMON { EncPart }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (11 | 13),
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 54]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
-      (WITH COMPONENTS {
-          ...,
-          msg-type (7 | 9),
-          crealm (RealmExt),
-          cname (PrincipalNameExt)
-      })
-
-
-
-   req-cksum
-        Signature of the original request using the reply key, to avoid
-        replay attacks against the client, among other things.  Only
-        present in the extensible version of KDC-REP.
-
-
-           AS-REP          ::= CHOICE {
-               rfc1510     [APPLICATION 11] KDC-REP-1510 {
-                   EncASRepPart1510
-               } (WITH COMPONENTS { ..., msg-type (11) }),
-               ext         [APPLICATION  7]  Signed {
-                   [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
-                   { key-reply }, { ku-ASRep-cksum }
-               } (WITH COMPONENTS { ..., msg-type (7) })
-           }
-
-
-
-           TGS-REP         ::= CHOICE {
-               rfc1510     [APPLICATION 13] KDC-REP-1510 {
-                   EncTGSRepPart1510
-               } (WITH COMPONENTS { ..., msg-type (13) }),
-               ext         [APPLICATION  9]  Signed {
-                   [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
-                   { key-reply }, { ku-TGSRep-cksum }
-               } (WITH COMPONENTS { ..., msg-type (9) })
-           }
-
-
-
-   The extensible versions of AS-REQ and TGS-REQ are signed with the
-   reply key, to prevent an attacker from performing a delayed denial-
-   of-service attack by substituting the ticket.
-
-
-8.5.  Reply Validation
-
-
-   [ signature verification ]
-
-
-8.6.  IP Transports
-
-
-   [ KCLAR 7.2 ]
-
-
-   Kerberos defines two IP transport mechanisms for the credentials
-   acquisition protocol: UDP/IP and TCP/IP.
-
-
-
-Yu                         Expires: Apr 2005                   [Page 55]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-8.6.1.  UDP/IP transport
-
-
-   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
-   requests and SHOULD listen for such requests on port 88 (decimal)
-   unless specifically configured to listen on an alternative UDP port.
-   Alternate ports MAY be used when running multiple KDCs for multiple
-   realms on the same host.
-
-
-   Kerberos clients supporting IP transports SHOULD support the sending
-   of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to
-   identify the IP address and port to which they will send their
-   request.
-
-
-   When contacting a KDC for a KRB_KDC_REQ request using UDP/IP
-   transport, the client shall send a UDP datagram containing only an
-   encoding of the request to the KDC. The KDC will respond with a reply
-   datagram containing only an encoding of the reply message (either a
-   KRB-ERROR or a KDC-REP) to the sending port at the sender's IP
-   address. The response to a request made through UDP/IP transport MUST
-   also use UDP/IP transport. If the response can not be handled using
-   UDP (for example because it is too large), the KDC MUST return "krb-
-   err-response-too-big", forcing the client to retry the request using
-   the TCP transport.
-
-
-8.6.2.  TCP/IP transport
-
-
-   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
-   requests and SHOULD listen for such requests on port 88 (decimal)
-   unless specifically configured to listen on an alternate TCP port.
-   Alternate ports MAY be used when running multiple KDCs for multiple
-   realms on the same host.
-
-
-   Clients MUST support the sending of TCP requests, but MAY choose to
-   initially try a request using the UDP transport. Clients SHOULD use
-   KDC discovery (Section 8.6.3) to identify the IP address and port to
-   which they will send their request.
-
-
-   Implementation note: Some extensions to the Kerberos protocol will
-   not succeed if any client or KDC not supporting the TCP transport is
-   involved.  Implementations of RFC 1510 were not required to support
-   TCP/IP transports.
-
-
-   When the KDC-REQ message is sent to the KDC over a TCP stream, the
-   response (KDC-REP or KRB-ERROR message) MUST be returned to the
-   client on the same TCP stream that was established for the request.
-   The KDC MAY close the TCP stream after sending a response, but MAY
-   leave the stream open for a reasonable period of time if it expects a
-   followup. Care must be taken in managing TCP/IP connections on the
-   KDC to prevent denial of service attacks based on the number of open
-   TCP/IP connections.
-
-
-
-Yu                         Expires: Apr 2005                   [Page 56]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   The client MUST be prepared to have the stream closed by the KDC at
-   anytime after the receipt of a response.  A stream closure SHOULD NOT
-   be treated as a fatal error.  Instead, if multiple exchanges are
-   required (e.g., certain forms of pre-authentication) the client may
-   need to establish a new connection when it is ready to send
-   subsequent messages.  A client MAY close the stream after receiving a
-   response, and SHOULD close the stream if it does not expect to send
-   followup messages.
-
-
-   A client MAY send multiple requests before receiving responses,
-   though it must be prepared to handle the connection being closed
-   after the first response.
-
-
-   Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over
-   the TCP stream is preceded by the length of the request as 4 octets
-   in network byte order. The high bit of the length is reserved for
-   future expansion and MUST currently be set to zero.  If a KDC that
-   does not understand how to interpret a set high bit of the length
-   encoding receives a request with the high order bit of the length
-   set, it MUST return a KRB-ERROR message with the error "krb-err-
-   field-toolong" and MUST close the TCP stream.
-
-
-   If multiple requests are sent over a single TCP connection, and the
-   KDC sends multiple responses, the KDC is not required to send the
-   responses in the order of the corresponding requests.  This may
-   permit some implementations to send each response as soon as it is
-   ready even if earlier requests are still being processed (for
-   example, waiting for a response from an external device or database).
-
-
-8.6.3.  KDC Discovery on IP Networks
-
-
-   Kerberos client implementations MUST provide a means for the client
-   to determine the location of the Kerberos Key Distribution Centers
-   (KDCs).  Traditionally, Kerberos implementations have stored such
-   configuration information in a file on each client machine.
-   Experience has shown this method of storing configuration information
-   presents problems with out-of-date information and scaling problems,
-   especially when using cross-realm authentication. This section
-   describes a method for using the Domain Name System [RFC 1035] for
-   storing KDC location information.
-
-
-8.6.3.1.  DNS vs. Kerberos - Case Sensitivity of Realm Names
-
-
-   In Kerberos, realm names are case sensitive.  While it is strongly
-   encouraged that all realm names be all upper case this recommendation
-   has not been adopted by all sites.  Some sites use all lower case
-   names and other use mixed case.  DNS, on the other hand, is case
-   insensitive for queries.  Since the realm names "MYREALM", "myrealm",
-   and "MyRealm" are all different, but resolve the same in the domain
-   name system, it is necessary that only one of the possible
-   combinations of upper and lower case characters be used in realm
-
-
-Yu                         Expires: Apr 2005                   [Page 57]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   names.
-
-
-8.6.3.2.  DNS SRV records for KDC location
-
-
-   KDC location information is to be stored using the DNS SRV RR [RFC
-   2782].  The format of this RR is as follows:
-
-
-      _Service._Proto.Realm TTL Class SRV Priority Weight Port Target
-
-
-   The Service name for Kerberos is always "kerberos".
-
-
-   The Proto can be one of "udp", "tcp". If these SRV records are to be
-   used, both "udp" and "tcp" records MUST be specified for all KDC
-   deployments.
-
-
-   The Realm is the Kerberos realm that this record corresponds to.  The
-   realm MUST be a domain style realm name.
-
-
-   TTL, Class, SRV, Priority, Weight, and Target have the standard
-   meaning as defined in RFC 2782.
-
-
-   As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV
-   records SHOULD be the value assigned to "kerberos" by the Internet
-   Assigned Number Authority: 88 (decimal) unless the KDC is configured
-   to listen on an alternate TCP port.
-
-
-   Implementation note: Many existing client implementations do not
-   support KDC Discovery and are configured to send requests to the IANA
-   assigned port (88 decimal), so it is strongly recommended that KDCs
-   be configured to listen on that port.
-
-
-8.6.3.3.  KDC Discovery for Domain Style Realm Names on IP Networks
-
-
-   These are DNS records for a Kerberos realm EXAMPLE.COM. It has two
-   Kerberos servers, kdc1.example.com and kdc2.example.com.  Queries
-   should be directed to kdc1.example.com first as per the specified
-   priority.  Weights are not used in these sample records.
-
-
-      _kerberos._udp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
-      _kerberos._udp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
-      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   0 0 88 kdc1.example.com.
-      _kerberos._tcp.EXAMPLE.COM.   IN   SRV   1 0 88 kdc2.example.com.
-
-
-
-9.  Errors
-
-
-   The KRB-ERROR message is returned by the KDC if an error occurs
-   during credentials acquisition.  It may also be returned by an
-   application server if an error occurs during authentication.
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 58]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      ErrCode ::= Int32
-
-
-      KRB-ERROR       ::= CHOICE {
-          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
-          ext         [APPLICATION 23] Signed {
-              KRB-ERROR-EXT, { ku-KrbError-cksum } }
-      }
-
-
-
-   The extensible KRB-ERROR is only signed if there has been a key
-   negotiated with its recipient.  KRB-ERROR messages sent in response
-   to AS-REQ messages will probably not be signed unless a
-   preauthentication mechanism has negotiated a key.  (Signing using a
-   client's long-term key can expose ciphertext to dictionary attacks.)
-
-
-   The parts of a KRB-ERROR common to both the backwards-compatibility
-   and the extensibile messages are
-
-
-      KRB-ERROR-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (30 | 23),
-          ctime       [2] KerberosTime OPTIONAL,
-          cusec       [3] Microseconds OPTIONAL,
-          stime       [4] KerberosTime,
-          susec       [5] Microseconds,
-          error-code  [6] ErrCode,
-          crealm      [7] Realm OPTIONAL,
-          cname       [8] PrincipalName OPTIONAL,
-          realm       [9] Realm -- Correct realm --,
-          sname       [10] PrincipalName -- Correct name --,
-          e-text      [11] KerberosString OPTIONAL,
-          e-data      [12] OCTET STRING OPTIONAL,
-          ...,
-          typed-data          [13] TYPED-DATA OPTIONAL,
-          nonce               [14] Nonce OPTIONAL,
-          lang-tag            [15] LangTag OPTIONAL,
-          ...
-      }
-
-
-
-      KRB-ERROR-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-ERROR-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (30)
-      })
-
-
-
-      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
-          (WITH COMPONENTS { ..., msg-type (23) })
-
-
-
-Yu                         Expires: Apr 2005                   [Page 59]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   ctime, cusec
-        Client's time, if known from a KDC-REQ or AP-REQ.
-
-
-   stime, susec
-        KDC or application server's current time.
-
-
-   error-code
-        Numeric error code designating the error.
-
-
-   crealm, cname
-        Client's realm and name, if known.
-
-
-   realm, sname
-        server's realm and name. [ XXX what if these aren't known? ]
-
-
-   e-text
-        Human-readable text providing additional details for the error.
-
-
-   e-data
-        This field contains additional data about the error for use by
-        the client to help it recover from or handle the error. If the
-        "error-code" is "kdc-err-preauth-required", then the e-data
-        field will contain an encoding of a sequence of padata fields,
-        each corresponding to an acceptable pre-authentication method
-        and optionally containing data for the method:
-
-
-           METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-
-
-        For error codes defined in this document other than "kdc-err-
-        preauth-required", the format and contents of the e-data field
-        are implementation-defined.  Similarly, for future error codes,
-        the format and contents of the e-data field are implementation-
-        defined unless specified.
-
-
-   lang-tag
-        Indicates the language of the message in the "e-text" field.  It
-        is only present in the extensible KRB-ERROR.
-
-
-   nonce
-        is the nonce from a KDC-REQ.  It is only present in the
-        extensible KRB-ERROR.
-
-
-   typed-data
-        TYPED-DATA is a typed hole allowing for additional data to be
-        returned in error conditions, since "e-data" is insufficiently
-        flexible for some purposes.  TYPED-DATA is only present in the
-        extensible KRB-ERROR.
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 60]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-           TDType ::= TH-id
-
-
-           TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-               data-type   [0] TDType,
-               data-value  [1] OCTET STRING OPTIONAL
-           }
-
-
-
-10.  Session Key Exchange
-
-
-   Session key exchange consists of the AP-REQ and AP-REP messages.  The
-   client sends the AP-REQ message, and the service responds with an
-   AP-REP message if mutual authentication is desired.  Following
-   session key exchange, the client and service share a secret session
-   key, or possibly a subsesion key, which can be used to protect
-   further communications.  Additionally, the session key exchange
-   process can establish initial sequence numbers which the client and
-   service can use to detect replayed messages.
-
-
-10.1.  AP-REQ
-
-
-   An AP-REQ message contains a ticket and a authenticator.  The
-   authenticator is ciphertext encrypted with the session key contained
-   in the ticket.  The plaintext contents of the authenticator are:
-
-
-      -- plaintext of authenticator
-      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-          authenticator-vno   [0] INTEGER (5),
-          crealm              [1] Realm,
-          cname               [2] PrincipalName,
-          cksum               [3] Checksum {{ key-session },
-              { ku-Authenticator-cksum |
-                ku-pa-TGSReq-cksum }} OPTIONAL,
-          cusec               [4] Microseconds,
-          ctime               [5] KerberosTime,
-          subkey              [6] EncryptionKey OPTIONAL,
-          seq-number          [7] SeqNum OPTIONAL,
-          authorization-data  [8] AuthorizationData OPTIONAL
-      }
-
-
-   The common parts between the RFC 1510 and the extensible versions of
-   the AP-REQ are:
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 61]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      AP-REQ-COMMON   ::= SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14 | 18),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket,
-          authenticator       [4] EncryptedData {
-              Authenticator,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          },
-          ...,
-          extensions          [5] ApReqExtensions OPTIONAL,
-          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
-                                      OF LangTag OPTIONAL,
-          ...
-      }
-
-
-   The complete definition of AP-REQ is:
-
-
-      AP-REQ          ::= CHOICE {
-          rfc1510     [APPLICATION 14] AP-REQ-1510,
-          ext         [APPLICATION 18] Signed {
-              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
-          }
-      }
-
-
-
-      AP-REQ-COMMON   ::= SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14 | 18),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket,
-          authenticator       [4] EncryptedData {
-              Authenticator,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          },
-          ...,
-          extensions          [5] ApReqExtensions OPTIONAL,
-          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
-                                      OF LangTag OPTIONAL,
-          ...
-      }
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 62]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      AP-REQ-1510 ::= SEQUENCE {
-          COMPONENTS OF AP-REQ-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (14),
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmIA5),
-                  cname (PrincipalNameIA5),
-                  seqnum (UInt32)
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-
-      AP-REQ-EXT      ::= AP-REQ-COMMON
-      (WITH COMPONENTS {
-          ...,
-          msg-type (18),
-          -- The following constraints on Authenticator assume that
-          -- we want to restrict the use of AP-REQ-EXT with TicketExt
-          -- only, since that is the only way we can enforce UTF-8.
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmExt),
-                  cname (PrincipalNameExt),
-                  authorization-data (SIZE (1..MAX))
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-
-      APOptions       ::= KerberosFlags { APOptionsBits }
-
-
-      APOptionsBits ::= BIT STRING {
-          reserved            (0),
-          use-session-key     (1),
-          mutual-required     (2)
-      }
-
-
-
-10.2.  AP-REP
-
-
-   An AP-REP message provides mutual authentication of the service to
-   the client.
-
-
-      EncAPRepPart    ::= CHOICE {
-          rfc1510     [APPLICATION 27] EncAPRepPart1510,
-          ext         [APPLICATION 31] EncAPRepPartExt
-      }
-
-
-
-Yu                         Expires: Apr 2005                   [Page 63]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      EncAPRepPartCom          ::= SEQUENCE {
-          ctime               [0] KerberosTime,
-          cusec               [1] Microseconds,
-          subkey              [2] EncryptionKey OPTIONAL,
-          seq-number          [3] SeqNum OPTIONAL,
-          ...,
-          authorization-data  [4] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-
-      EncAPRepPart1510        ::= SEQUENCE {
-          COMPONENTS OF ENCAPRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          seq-number (UInt32),
-          authorization-data ABSENT
-      })
-
-
-
-      EncAPRepPartExt         ::= EncAPRepPartCom
-
-
-
-      AP-REP          ::= CHOICE {
-          rfc1510     [APPLICATION 15] AP-REP-1510,
-          ext         [APPLICATION 19] Signed {
-              AP-REP-EXT,
-              { key-session | key-subsession }, { ku-APRep-cksum }}
-      }
-
-
-
-      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (15 | 19),
-          enc-part    [2] EncryptedData {
-              EncPart,
-              { key-session | key-subsession }, { ku-EncAPRepPart }},
-          ...,
-          extensions          [3] ApRepExtensions OPTIONAL,
-          ...
-      }
-
-
-
-      AP-REP-1510     ::= SEQUENCE {
-          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (15)
-      })
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 64]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
-          EncAPRepPartExt
-      } (WITH COMPONENTS { ..., msg-type (19) })
-
-
-
-11.  Session Key Use
-
-
-   Once a session key has been established, the client and server can
-   use several kinds of messages to securely transmit data.  KRB-SAFE
-   provides integrity protection for application data, while KRB-PRIV
-   provides confidentiality along with integrity protection.  The KRB-
-   CRED message provides a means of securely forwarding credentials from
-   the client host to the server host.
-
-
-11.1.  KRB-SAFE
-
-
-   The KRB-SAFE message provides integrity protection for an included
-   cleartext message.
-
-
-      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
-      -- allow us to  make safe-body optional, allowing for a GSS-MIC
-      -- sort of message.
-      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (20),
-          safe-body   [2] KRB-SAFE-BODY,
-          cksum       [3] ChecksumOf {
-              KRB-SAFE-BODY,
-              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-      KRB-SAFE-BODY   ::= SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress,
-          r-address   [5] HostAddress OPTIONAL,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-11.2.  KRB-PRIV
-
-
-   The KRB-PRIV message provides confidentiality and integrity
-   protection.
-
-
-
-Yu                         Expires: Apr 2005                   [Page 65]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (21),
-          enc-part    [3] EncryptedData {
-              EncKrbPrivPart,
-              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
-          ...
-      }
-
-
-
-      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress -- sender's addr --,
-          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-11.3.  KRB-CRED
-
-
-   The KRB-CRED message provides a means of securely transferring
-   credentials from the client to the service.
-
-
-      KRB-CRED        ::= CHOICE {
-          rfc1510     [APPLICATION 22] KRB-CRED-1510,
-          ext         [APPLICATION 24] Signed {
-              KRB-CRED-EXT,
-              { key-session | key-subsession }, { ku-KrbCred-cksum }}
-      }
-
-
-
-      KRB-CRED-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (22 | 24),
-          tickets     [2] SEQUENCE OF Ticket,
-          enc-part    [3] EncryptedData {
-              EncKrbCredPart,
-              { key-session | key-subsession }, { ku-EncKrbCredPart }},
-          ...
-      }
-
-
-
-      KRB-CRED-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-CRED-COMMON
-      } (WITH COMPONENTS { ..., msg-type (22) })
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 66]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
-          (WITH COMPONENTS { ..., msg-type (24) })
-
-
-
-      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-          ticket-info [0] SEQUENCE OF KrbCredInfo,
-          nonce       [1] Nonce OPTIONAL,
-          timestamp   [2] KerberosTime OPTIONAL,
-          usec        [3] Microseconds OPTIONAL,
-          s-address   [4] HostAddress OPTIONAL,
-          r-address   [5] HostAddress OPTIONAL
-      }
-
-
-
-      KrbCredInfo     ::= SEQUENCE {
-          key         [0] EncryptionKey,
-          prealm      [1] Realm OPTIONAL,
-          pname       [2] PrincipalName OPTIONAL,
-          flags       [3] TicketFlags OPTIONAL,
-          authtime    [4] KerberosTime OPTIONAL,
-          starttime   [5] KerberosTime OPTIONAL,
-          endtime     [6] KerberosTime OPTIONAL,
-          renew-till  [7] KerberosTime OPTIONAL,
-          srealm      [8] Realm OPTIONAL,
-          sname       [9] PrincipalName OPTIONAL,
-          caddr       [10] HostAddresses OPTIONAL
-      }
-
-
-
-12.  Security Considerations
-
-
-12.1.  Time Synchronization
-
-
-   Time synchronization between the KDC and application servers is
-   necessary to prevent acceptance of expired tickets.
-
-
-   Time synchronization is needed between application servers and
-   clients to prevent replay attacks if a replay cache is being used.
-   If negotiated subsession keys are used to encrypt application data,
-   replay caches may not be necessary.
-
-
-12.2.  Replays
-
-
-12.3.  Principal Name Reuse
-
-
-   See Section 5.3.
-
-
-12.4.  Password Guessing
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 67]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-12.5.  Forward Secrecy
-
-
-   [from KCLAR 10.; needs some rewriting]
-
-
-   The Kerberos protocol in its basic form does not provide perfect
-   forward secrecy for communications.  If traffic has been recorded by
-   an eavesdropper, then messages encrypted using the KRB-PRIV message,
-   or messages encrypted using application-specific encryption under
-   keys exchanged using Kerberos can be decrypted if any of the user's,
-   application server's, or KDC's key is subsequently discovered.  This
-   is because the session key used to encrypt such messages is
-   transmitted over the network encrypted in the key of the application
-   server, and also encrypted under the session key from the user's
-   ticket-granting ticket when returned to the user in the TGS-REP
-   message.  The session key from the ticket-granting ticket was sent to
-   the user in the AS-REP message encrypted in the user's secret key,
-   and embedded in the ticket-granting ticket, which was encrypted in
-   the key of the KDC.  Application requiring perfect forward secrecy
-   must exchange keys through mechanisms that provide such assurance,
-   but may use Kerberos for authentication of the encrypted channel
-   established through such other means.
-
-
-12.6.  Authorization
-
-
-   As an authentication service, Kerberos provides a means of verifying
-   the identity of principals on a network.  Kerberos does not, by
-   itself, provide authorization.  Applications SHOULD NOT accept the
-   mere issuance of a service ticket by the Kerberos server as granting
-   authority to use the service.
-
-
-12.7.  Login Authentication
-
-
-   Some applications, particularly those which provide login access when
-   provided with a password, SHOULD NOT treat successful acquisition of
-   credentials as sufficient proof of the user's identity.  An attacker
-   posing as a user could generate an illegitimate KDC-REP message which
-   decrypts properly.  To authenticate a user logging on to a local
-   system, the credentials obtained SHOULD be used in a TGS exchange to
-   obtain credentials for a local service.  Successful use of those
-   credentials to authenticate to the local service assures that the
-   initially obtained credentials are from a valid KDC.
-
-
-13.  IANA Considerations
-
-
-   [ needs more work ]
-
-
-   Each use of Int32 in this document defines a number space.  [ XXX
-   enumerate these ] Negative numbers are reserved for private use;
-   local and experimental extensions should use these values.  Zero is
-   reserved and may not be assigned.
-
-
-
-Yu                         Expires: Apr 2005                   [Page 68]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   Typed hole contents may be identified by either Int32 values or by
-   RELATIVE-OID values.  Since RELATIVE-OIDs define a hierarchical
-   namespace, assignments to the top level of the RELATIVE-OID space may
-   be made on a first-come, first-served basis.
-
-
-14.  Acknowledgments
-
-
-   Much of the text here is adapted from draft-ietf-krb-wg-kerberos-
-   clarifications-07.  The description of the general form of the
-   extensibility framework was derived from text by Sam Hartman.
-
-
-Appendices
-
-
-A.  ASN.1 Module (Normative)
-
-
-      KerberosV5Spec3 {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2) modules(4) krb5spec3(4)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-
-
-      -- OID arc for KerberosV5
-      --
-      -- This OID may be used to identify Kerberos protocol messages
-      -- encapsulated in other protocols.
-      --
-      -- This OID also designates the OID arc for KerberosV5-related
-      -- OIDs.
-      --
-      -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its
-      -- OID.
-      id-krb5         OBJECT IDENTIFIER ::= {
-          iso(1) identified-organization(3) dod(6) internet(1)
-          security(5) kerberosV5(2)
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 69]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- top-level type
-      --
-      -- Applications should not directly reference any types
-      -- other than KRB-PDU and its component types.
-      --
-      KRB-PDU         ::= CHOICE {
-          ticket      Ticket,
-          as-req      AS-REQ,
-          as-rep      AS-REP,
-          tgs-req     TGS-REQ,
-          tgs-rep     TGS-REP,
-          ap-req      AP-REQ,
-          ap-rep      AP-REP,
-          krb-safe    KRB-SAFE,
-          krb-priv    KRB-PRIV,
-          krb-cred    KRB-CRED,
-          tgt-req     TGT-REQ,
-          krb-error   KRB-ERROR,
-          ...
-      }
-
-
-
-      --
-      -- *** basic types
-      --
-
-
-
-      -- signed values representable in 32 bits
-      --
-      -- These are often used as assigned numbers for various things.
-      Int32           ::= INTEGER (-2147483648..2147483647)
-
-
-
-      -- Typed hole identifiers
-      TH-id           ::= CHOICE {
-          int32               Int32,
-          rel-oid             RELATIVE-OID
-      }
-
-
-
-      -- unsigned 32 bit values
-      UInt32          ::= INTEGER (0..4294967295)
-
-
-
-      -- unsigned 64 bit values
-      UInt64          ::= INTEGER (0..18446744073709551615)
-
-
-
-      -- sequence numbers
-      SeqNum          ::= UInt64
-
-
-
-Yu                         Expires: Apr 2005                   [Page 70]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- nonces
-      Nonce           ::= UInt64
-
-
-
-      -- microseconds
-      Microseconds    ::= INTEGER (0..999999)
-
-
-
-      KerberosTime    ::= GeneralizedTime (CONSTRAINED BY {
-                              -- MUST NOT include fractional seconds
-      })
-
-
-
-      -- used for names and for error messages
-      KerberosString  ::= CHOICE {
-          ia5         GeneralString (IA5String),
-          utf8        UTF8String,
-          ...         -- no extension may be sent
-                      -- to an rfc1510 implementation --
-      }
-
-
-
-      -- IA5 choice only; useful for constraints
-      KerberosStringIA5       ::= KerberosString
-          (WITH COMPONENTS { ia5 PRESENT })
-
-
-      -- IA5 excluded; useful for constraints
-      KerberosStringExt       ::= KerberosString
-          (WITH COMPONENTS { ia5 ABSENT })
-
-
-
-      -- used for language tags
-      LangTag ::= PrintableString
-          (FROM ("A".."Z" | "a".."z" | "0".."9" | "-"))
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 71]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- assigned numbers for name types (used in principal names)
-      NameType        ::= Int32
-
-
-      -- Name type not known
-      nt-unknown              NameType ::= 0
-      -- Just the name of the principal as in DCE, or for users
-      nt-principal            NameType ::= 1
-      -- Service and other unique instance (krbtgt)
-      nt-srv-inst             NameType ::= 2
-      -- Service with host name as instance (telnet, rcommands)
-      nt-srv-hst              NameType ::= 3
-      -- Service with host as remaining components
-      nt-srv-xhst             NameType ::= 4
-      -- Unique ID
-      nt-uid                  NameType ::= 5
-      -- Encoded X.509 Distingished name [RFC 2253]
-      nt-x500-principal       NameType ::= 6
-      -- Name in form of SMTP email name (e.g. user@foo.com)
-      nt-smtp-name            NameType ::= 7
-      -- Enterprise name - may be mapped to principal name
-      nt-enterprise           NameType ::= 10
-
-
-
-      PrincipalName   ::= SEQUENCE {
-          name-type   [0] NameType,
-          -- May have zero elements, or individual elements may be
-          -- zero-length, but this is NOT RECOMMENDED.
-          name-string [1] SEQUENCE OF KerberosString
-      }
-
-
-
-      -- IA5 only
-      PrincipalNameIA5 ::= PrincipalName (WITH COMPONENTS {
-          ...,
-          name-string (WITH COMPONENT (KerberosStringIA5))
-      })
-
-
-      -- IA5 excluded
-      PrincipalNameExt ::= PrincpalName (WITH COMPONENTS {
-          ...,
-          name-string (WITH COMPONENT (KerberosStringExt))
-      })
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 72]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      Realm           ::= KerberosString
-
-
-      -- IA5 only
-      RealmIA5        ::= Realm (KerberosStringIA5)
-
-
-      -- IA5 excluded
-      RealmExt        ::= Realm (KerberosStringExt)
-
-
-
-      KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX))
-          (CONSTRAINED BY {
-          -- MUST be a valid value of -- NamedBits
-          -- but if the value to be sent would be truncated to shorter
-          -- than 32 bits according to DER, the value MUST be padded
-          -- with trailing zero bits to 32 bits.  Otherwise, no
-          -- trailing zero bits may be present.
-
-
-      })
-
-
-
-      AddrType        ::= Int32
-
-
-      HostAddress     ::= SEQUENCE  {
-          addr-type   [0] AddrType,
-          address     [1] OCTET STRING
-      }
-
-
-      -- NOTE: HostAddresses is always used as an OPTIONAL field and
-      -- should not be a zero-length SEQUENCE OF.
-      --
-      -- The extensible messages explicitly constrain this to be
-      -- non-empty.
-      HostAddresses   ::= SEQUENCE OF HostAddress
-
-
-
-      --
-      -- *** crypto-related types and assignments
-      --
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 73]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- Assigned numbers denoting encryption mechanisms.
-      EType ::= Int32
-
-
-      -- assigned numbers for encryption schemes
-      et-des-cbc-crc                  EType ::= 1
-      et-des-cbc-md4                  EType ::= 2
-      et-des-cbc-md5                  EType ::= 3
-      --     [reserved]                         4
-      et-des3-cbc-md5                 EType ::= 5
-      --     [reserved]                         6
-      et-des3-cbc-sha1                EType ::= 7
-      et-dsaWithSHA1-CmsOID           EType ::= 9
-      et-md5WithRSAEncryption-CmsOID  EType ::= 10
-      et-sha1WithRSAEncryption-CmsOID EType ::= 11
-      et-rc2CBC-EnvOID                EType ::= 12
-      et-rsaEncryption-EnvOID         EType ::= 13
-      et-rsaES-OAEP-ENV-OID           EType ::= 14
-      et-des-ede3-cbc-Env-OID         EType ::= 15
-      et-des3-cbc-sha1-kd             EType ::= 16
-      -- AES
-      et-aes128-cts-hmac-sha1-96      EType ::= 17
-      -- AES
-      et-aes256-cts-hmac-sha1-96      EType ::= 18
-      -- Microsoft
-      et-rc4-hmac                     EType ::= 23
-      -- Microsoft
-      et-rc4-hmac-exp                 EType ::= 24
-      -- opaque; PacketCable
-      et-subkey-keymaterial           EType ::= 65
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 74]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- Assigned numbers denoting key usages.
-      KeyUsage ::= UInt32
-
-
-      --
-      -- Actual identifier names are provisional and subject to
-      -- change.
-      --
-      ku-pa-enc-ts                    KeyUsage ::= 1
-      ku-Ticket                       KeyUsage ::= 2
-      ku-EncASRepPart                 KeyUsage ::= 3
-      ku-TGSReqAuthData-sesskey       KeyUsage ::= 4
-      ku-TGSReqAuthData-subkey        KeyUsage ::= 5
-      ku-pa-TGSReq-cksum              KeyUsage ::= 6
-      ku-pa-TGSReq-authenticator      KeyUsage ::= 7
-      ku-EncTGSRepPart-sesskey        KeyUsage ::= 8
-      ku-EncTGSRepPart-subkey         KeyUsage ::= 9
-      ku-Authenticator-cksum          KeyUsage ::= 10
-      ku-APReq-authenticator          KeyUsage ::= 11
-      ku-EncAPRepPart                 KeyUsage ::= 12
-      ku-EncKrbPrivPart               KeyUsage ::= 13
-      ku-EncKrbCredPart               KeyUsage ::= 14
-      ku-KrbSafe-cksum                KeyUsage ::= 15
-      ku-ad-KDCIssued-cksum           KeyUsage ::= 19
-
-
-
-      -- The following numbers are provisional...
-      -- conflicts may exist elsewhere.
-      ku-Ticket-cksum                 KeyUsage ::= 25
-      ku-ASReq-cksum                  KeyUsage ::= 26
-      ku-TGSReq-cksum                 KeyUsage ::= 27
-      ku-ASRep-cksum                  KeyUsage ::= 28
-      ku-TGSRep-cksum                 KeyUsage ::= 29
-      ku-APReq-cksum                  KeyUsage ::= 30
-      ku-APRep-cksum                  KeyUsage ::= 31
-      ku-KrbCred-cksum                KeyUsage ::= 32
-      ku-KrbError-cksum               KeyUsage ::= 33
-      ku-KDCRep-cksum                 KeyUsage ::= 34
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 75]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- KeyToUse identifies which key is to be used to encrypt or
-      -- sign a given value.
-      --
-      -- Values of KeyToUse are never actually transmitted over the
-      -- wire, or even used directly by the implementation in any
-      -- way, as key usages are; it exists primarily to identify
-      -- which key gets used for what purpose.  Thus, the specific
-      -- numeric values associated with this type are irrelevant.
-      KeyToUse        ::= ENUMERATED {
-          -- unspecified
-          key-unspecified,
-          -- server long term key
-          key-server,
-          -- client long term key
-          key-client,
-          -- key selected by KDC for encryption of a KDC-REP
-          key-kdc-rep,
-          -- session key from ticket
-          key-session,
-          -- subsession key negotiated via AP-REQ/AP-REP
-          key-subsession,
-          ...
-      }
-
-
-
-      EncryptionKey   ::= SEQUENCE {
-          keytype     [0] EType,
-          keyvalue    [1] OCTET STRING
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 76]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-
-      -- "Type" specifies which ASN.1 type is encrypted to the
-      -- ciphertext in the EncryptedData.  "Keys" specifies a set of
-      -- keys of which one key may be used to encrypt the data.
-      -- "KeyUsages" specifies a set of key usages, one of which may
-      -- be used to encrypt.
-      --
-      -- None of the parameters is transmitted over the wire.
-      EncryptedData {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          etype       [0] EType,
-          kvno        [1] UInt32 OPTIONAL,
-          cipher      [2] OCTET STRING (CONSTRAINED BY {
-              -- must be encryption of --
-              OCTET STRING (CONTAINING Type),
-              -- with one of the keys -- KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          }),
-          ...
-      }
-
-
-
-
-      CksumType       ::= Int32
-
-
-      -- The parameters specify which key to use to produce the
-      -- signature, as well as which key usage to use.  The
-      -- parameters are not actually sent over the wire.
-      Checksum {
-          KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksumtype   [0] CksumType,
-          checksum    [1] OCTET STRING (CONSTRAINED BY {
-              -- signed using one of the keys --
-              KeyToUse:Keys,
-              -- with key usage being one of --
-              KeyUsage:KeyUsages
-          })
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 77]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- a Checksum that must contain the checksum
-      -- of a particular type
-      ChecksumOf {
-          Type, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS {
-          ...,
-          checksum (CONSTRAINED BY {
-              -- must be checksum of --
-              OCTET STRING (CONTAINING Type)
-          })
-      })
-
-
-
-      -- parameterized type for wrapping authenticated plaintext
-      Signed {
-          InnerType, KeyToUse:Keys, KeyUsage:KeyUsages
-      } ::= SEQUENCE {
-          cksum       [0] ChecksumOf {
-              InnerType, Keys, KeyUsages
-          } OPTIONAL,
-          inner       [1] InnerType,
-          ...
-      }
-
-
-
-      --
-      -- *** Tickets
-      --
-
-
-
-      Ticket          ::= CHOICE {
-          rfc1510     [APPLICATION 1] Ticket1510,
-          ext         [APPLICATION 4] Signed {
-              TicketExt, { key-server }, { ku-Ticket-cksum }
-          }
-      }
-
-
-
-      -- takes a parameter specifying which type gets encrypted
-      TicketCommon { EncPart } ::= SEQUENCE {
-          tkt-vno     [0] INTEGER (5),
-          realm       [1] Realm,
-          sname       [2] PrincipalName,
-          enc-part    [3] EncryptedData {
-              EncPart, { key-server }, { ku-Ticket }
-          },
-          ...,
-          extensions          [4] TicketExtensions OPTIONAL,
-          ...
-      }
-
-
-
-Yu                         Expires: Apr 2005                   [Page 78]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      Ticket1510 ::= SEQUENCE {
-          COMPONENTS OF TicketCommon { EncTicketPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          realm (RealmIA5),
-          sname (PrincipalNameIA5)
-      })
-
-
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      TicketExt ::= [APPLICATION 4] TicketCommon {
-          EncTicketPartExt
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          realm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-
-      -- Encrypted part of ticket
-      EncTicketPart ::= CHOICE {
-          rfc1510     [APPLICATION 3] EncTicketPart1510,
-          ext         [APPLICATION 5] EncTicketPartExt
-      }
-
-
-
-      EncTicketPartCommon ::= SEQUENCE {
-          flags               [0] TicketFlags,
-          key                 [1] EncryptionKey,
-          crealm              [2] Realm,
-          cname               [3] PrincipalName,
-          transited           [4] TransitedEncoding,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          caddr               [9] HostAddresses OPTIONAL,
-          authorization-data  [10] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 79]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      EncTicketPart1510 ::= SEQUENCE {
-          COMPONENTS OF EncTicketPartCommon
-      } (WITH COMPONENTS {
-          ...,
-          -- explicitly force IA5 in strings
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-
-
-      EncTicketPartExt ::= EncTicketPartCommon (WITH COMPONENTS {
-          ...,
-          -- explicitly force UTF-8 in strings
-          crealm (RealmExt),
-          cname (PrincipalNameExt),
-          -- explicitly constrain caddr to be non-empty if present
-          caddr (SIZE (1..MAX)),
-          -- forbid empty authorization-data encodings
-          authorization-data (SIZE (1..MAX))
-      })
-
-
-
-      --
-      -- *** Authorization Data
-      --
-
-
-
-      ADType          ::= TH-id
-
-
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-          ad-type             [0] ADType,
-          ad-data             [1] OCTET STRING
-      }
-
-
-
-      ad-if-relevant          ADType ::= int32 : 1
-
-
-      -- Encapsulates another AuthorizationData.
-      -- Intended for application servers; receiving application servers
-      -- MAY ignore.
-      AD-IF-RELEVANT          ::= AuthorizationData
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 80]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- KDC-issued privilege attributes
-      ad-kdcissued            ADType ::= int32 : 4
-
-
-      AD-KDCIssued            ::= SEQUENCE {
-          ad-checksum [0] ChecksumOf {
-                              AuthorizationData, { key-session },
-                              { ku-ad-KDCIssued-cksum }},
-          i-realm     [1] Realm OPTIONAL,
-          i-sname     [2] PrincipalName OPTIONAL,
-          elements    [3] AuthorizationData
-      }
-
-
-
-      ad-and-or               ADType ::= int32 : 5
-
-
-      AD-AND-OR               ::= SEQUENCE {
-          condition-count     [0] INTEGER,
-          elements            [1] AuthorizationData
-      }
-
-
-
-      -- KDCs MUST interpret any AuthorizationData wrapped in this.
-      ad-mandatory-for-kdc            ADType ::= int32 : 8
-      AD-MANDATORY-FOR-KDC            ::= AuthorizationData
-
-
-
-      TrType                  ::= TH-id -- must be registered
-
-
-      -- encoded Transited field
-      TransitedEncoding       ::= SEQUENCE {
-          tr-type     [0] TrType,
-          contents    [1] OCTET STRING
-      }
-
-
-
-      TEType                  ::= TH-id
-
-
-      -- ticket extensions: for TicketExt only
-      TicketExtensions        ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          te-type             [0] TEType,
-          te-data             [1] OCTET STRING
-      }
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 81]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      TicketFlags     ::= KerberosFlags { TicketFlagsBits }
-
-
-      TicketFlagsBits ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          may-postdate        (5),
-          postdated           (6),
-          invalid             (7),
-          renewable           (8),
-          initial             (9),
-          pre-authent         (10),
-          hw-authent          (11),
-          transited-policy-checked (12),
-          ok-as-delegate      (13),
-          anonymous           (14),
-          cksummed-ticket     (15)
-      }
-
-
-
-      --
-      -- *** KDC protocol
-      --
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 82]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      AS-REQ  ::= CHOICE {
-          rfc1510     [APPLICATION 10] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (10),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          }),
-          ext         [APPLICATION 6]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as
-              -- outside, to prevent possible substitution attacks.
-              [APPLICATION 6] KDC-REQ-EXT,
-              -- not sure this is correct key to use; do we even want
-              -- to sign AS-REQ?
-              { key-client },
-              { ku-ASReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (6),
-              -- AS-REQ must include client name
-              req-body (WITH COMPONENTS { ..., cname PRESENT })
-          })
-      }
-
-
-
-      TGS-REQ ::= CHOICE {
-          rfc1510     [APPLICATION 12] KDC-REQ-1510
-          (WITH COMPONENTS {
-              ...,
-              msg-type (12),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          }),
-          ext         [APPLICATION 8]  Signed {
-              -- APPLICATION tag goes inside Signed{} as well as
-              -- outside, to prevent possible substitution attacks.
-              [APPLICATION 8] KDC-REQ-EXT,
-              { key-session }, { ku-TGSReq-cksum }
-          }
-          (WITH COMPONENTS {
-              ...,
-              msg-type  (8),
-              -- client name optional in TGS-REQ
-              req-body (WITH COMPONENTS { ..., cname ABSENT })
-          })
-      }
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 83]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KDC-REQ-COMMON  ::= SEQUENCE {
-      -- NOTE: first tag is [1], not [0]
-          pvno        [1] INTEGER (5),
-          msg-type    [2] INTEGER (10 -- AS-REQ.rfc1510 --
-                                   | 12 -- TGS-REQ.rfc1510 --
-                                   | 6 -- AS-REQ.ext --
-                                   | 8 -- TGS-REQ.ext -- ),
-          padata      [3] SEQUENCE OF PA-DATA OPTIONAL
-          -- NOTE: not empty
-      }
-
-
-
-      KDC-REQ-1510    ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-1510
-      } (WITH COMPONENTS { ..., msg-type (10 | 12) })
-
-
-
-      -- APPLICATION tag goes inside Signed{} as well as outside,
-      -- to prevent possible substitution attacks.
-      KDC-REQ-EXT     ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-COMMON,
-          req-body    [4] KDC-REQ-BODY-EXT,
-          ...
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (6 | 8),
-          padata (SIZE (1..MAX))
-      })
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 84]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KDC-REQ-BODY-COMMON     ::= SEQUENCE {
-          kdc-options         [0] KDCOptions,
-          cname               [1] PrincipalName OPTIONAL
-          -- Used only in AS-REQ --,
-
-
-          realm               [2] Realm
-          -- Server's realm; also client's in AS-REQ --,
-
-
-          sname               [3] PrincipalName OPTIONAL,
-          from                [4] KerberosTime OPTIONAL,
-          till                [5] KerberosTime OPTIONAL
-          -- was required in rfc1510;
-          -- still required for compat versions
-          -- of messages --,
-
-
-          rtime               [6] KerberosTime OPTIONAL,
-          nonce               [7] Nonce,
-          etype               [8] SEQUENCE OF EType
-          -- in preference order --,
-
-
-          addresses           [9] HostAddresses OPTIONAL,
-          enc-authorization-data      [10] EncryptedData {
-              AuthorizationData, { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          } OPTIONAL,
-
-
-          additional-tickets  [11] SEQUENCE OF Ticket OPTIONAL
-          -- NOTE: not empty --,
-          ...
-          lang-tags   [5] SEQUENCE (SIZE (1..MAX)) OF
-                              LangTag OPTIONAL,
-          ...
-      }
-
-
-
-      KDC-REQ-BODY-1510 ::= SEQUENCE {
-          COMPONENTS OF KDC-REQ-BODY-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          cname (PrincipalNameIA5),
-          realm (RealmIA5),
-          sname (PrincipalNameIA5),
-          till PRESENT,
-          nonce (UInt32)
-      })
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 85]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KDC-REQ-BODY-EXT        ::= KDC-REQ-BODY-COMMON
-      (WITH COMPONENTS {
-          ...,
-          cname (PrincipalNameExt),
-          realm (RealmExt),
-          sname (PrincipalNameExt),
-          addresses (SIZE (1..MAX)),
-          enc-authorization-data (EncryptedData {
-              AuthorizationData (SIZE (1..MAX)),
-              { key-session | key-subsession },
-              { ku-TGSReqAuthData-subkey |
-                ku-TGSReqAuthData-sesskey }
-          }),
-          additional-tickets (SIZE (1..MAX))
-      })
-
-
-
-      KDCOptions      ::= KerberosFlags { KDCOptionsBits }
-
-
-      KDCOptionsBits  ::= BIT STRING {
-          reserved            (0),
-          forwardable         (1),
-          forwarded           (2),
-          proxiable           (3),
-          proxy               (4),
-          allow-postdate      (5),
-          postdated           (6),
-          unused7             (7),
-          renewable           (8),
-          unused9             (9),
-          unused10            (10),
-          unused11            (11),
-          unused12            (12),
-          unused13            (13),
-          requestanonymous    (14),
-          canonicalize        (15),
-          disable-transited-check (26),
-          renewable-ok        (27),
-          enc-tkt-in-skey     (28),
-          renew               (30),
-          validate            (31)
-          -- XXX need "need ticket1" flag?
-      }
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 86]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      AS-REP          ::= CHOICE {
-          rfc1510     [APPLICATION 11] KDC-REP-1510 {
-              EncASRepPart1510
-          } (WITH COMPONENTS { ..., msg-type (11) }),
-          ext         [APPLICATION  7]  Signed {
-              [APPLICATION 7] KDC-REP-EXT { EncASRepPartExt },
-              { key-reply }, { ku-ASRep-cksum }
-          } (WITH COMPONENTS { ..., msg-type (7) })
-      }
-
-
-
-      TGS-REP         ::= CHOICE {
-          rfc1510     [APPLICATION 13] KDC-REP-1510 {
-              EncTGSRepPart1510
-          } (WITH COMPONENTS { ..., msg-type (13) }),
-          ext         [APPLICATION  9]  Signed {
-              [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt },
-              { key-reply }, { ku-TGSRep-cksum }
-          } (WITH COMPONENTS { ..., msg-type (9) })
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 87]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KDC-REP-COMMON { EncPart } ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (11 -- AS-REP.rfc1510 -- |
-                                   13 -- TGS.rfc1510 -- |
-                                   7 -- AS-REP.ext -- |
-                                   9 -- TGS-REP.ext -- ),
-          padata      [2] SEQUENCE OF PA-DATA OPTIONAL,
-          crealm      [3] Realm,
-          cname       [4] PrincipalName,
-          ticket      [5] Ticket,
-
-
-          enc-part    [6] EncryptedData {
-              EncPart,
-              { key-reply },
-              -- maybe reach into EncryptedData in AS-REP/TGS-REP
-              -- definitions to apply constraints on key usages?
-              { ku-EncASRepPart -- if AS-REP -- |
-                ku-EncTGSRepPart-subkey -- if TGS-REP and
-                                        -- using Authenticator
-                                        -- session key -- |
-                ku-EncTGSRepPart-sesskey -- if TGS-REP and using
-                                         -- subsession key -- }
-          },
-
-
-          ...,
-          -- In extensible version, KDC signs original request
-          -- to avoid replay attacks against client.
-          req-cksum   [7] ChecksumOf { CHOICE {
-              as-req          AS-REQ,
-              tgs-req         TGS-REQ
-          }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL,
-          lang-tag    [8] LangTag OPTIONAL,
-          ...
-      }
-
-
-
-      KDC-REP-1510 { EncPart } ::= SEQUENCE {
-          COMPONENTS OF KDC-REP-COMMON { EncPart }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (11 | 13),
-          crealm (RealmIA5),
-          cname (PrincipalNameIA5)
-      })
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 88]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KDC-REP-EXT { EncPart } ::= KDC-REP-COMMON { EncPart }
-      (WITH COMPONENTS {
-          ...,
-          msg-type (7 | 9),
-          crealm (RealmExt),
-          cname (PrincipalNameExt)
-      })
-
-
-
-      EncASRepPart1510        ::= [APPLICATION 25] EncKDCRepPart1510
-      EncTGSRepPart1510       ::= [APPLICATION 26] EncKDCRepPart1510
-
-
-      EncASRepPartExt         ::= [APPLICATION 32] EncKDCRepPartExt
-      EncTGSRepPartExt        ::= [APPLICATION 33] EncKDCRepPartExt
-
-
-      EncKDCRepPartCom        ::= SEQUENCE {
-          key                 [0] EncryptionKey,
-          last-req            [1] LastReq,
-          nonce               [2] Nonce,
-          key-expiration      [3] KerberosTime OPTIONAL,
-          flags               [4] TicketFlags,
-          authtime            [5] KerberosTime,
-          starttime           [6] KerberosTime OPTIONAL,
-          endtime             [7] KerberosTime,
-          renew-till          [8] KerberosTime OPTIONAL,
-          srealm              [9] Realm,
-          sname               [10] PrincipalName,
-          caddr               [11] HostAddresses OPTIONAL,
-          ...
-      }
-
-
-      EncKDCRepPart1510       ::= SEQUENCE {
-          COMPONENTS OF EncKDCRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          srealm (RealmIA5),
-          sname (PrincipalNameIA5),
-          nonce UInt32 })
-
-
-      EncKdcRepPartExt        ::= EncKDCRepPartCom (WITH COMPONENTS {
-          ...,
-          srealm (RealmExt),
-          sname (PrincipalNameExt)
-      })
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 89]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      LRType          ::=     TH-id
-      LastReq         ::=     SEQUENCE OF SEQUENCE {
-          lr-type     [0] LRType,
-          lr-value    [1] KerberosTime
-      }
-
-
-
-      --
-      -- *** preauth
-      --
-
-
-
-      PaDataType      ::= TH-id
-      PaDataOID       ::= RELATIVE-OID
-
-
-      PA-DATA ::= SEQUENCE {
-          -- NOTE: first tag is [1], not [0]
-          padata-type         [1] PaDataType,
-          padata-value        [2] OCTET STRING
-      }
-
-
-
-      -- AP-REQ authenticating a TGS-REQ
-      pa-tgs-req              PaDataType ::= int32 : 1
-      PA-TGS-REQ              ::= AP-REQ
-
-
-
-      -- Encrypted timestamp preauth
-      -- Encryption key used is client's long-term key.
-      pa-enc-timestamp        PaDataType ::= int32 : 2
-
-
-      PA-ENC-TIMESTAMP ::= EncryptedData {
-          PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts }
-      }
-
-
-      PA-ENC-TS-ENC           ::= SEQUENCE {
-              patimestamp     [0] KerberosTime -- client's time --,
-              pausec          [1] Microseconds OPTIONAL
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 90]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- Hints returned in AS-REP or KRB-ERROR to help client
-      -- choose a password-derived key, either for preauthentication
-      -- or for decryption of the reply.
-      pa-etype-info           PaDataType ::= int32 : 11
-
-
-      ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
-
-
-      ETYPE-INFO-ENTRY        ::= SEQUENCE {
-              etype           [0] EType,
-              salt            [1] OCTET STRING OPTIONAL
-      }
-
-
-
-      -- Similar to etype-info, but with parameters provided for
-      -- the string-to-key function.
-      pa-etype-info2          PaDataType ::= int32 : 19
-
-
-      ETYPE-INFO2             ::= SEQUENCE (SIZE (1..MAX))
-                                      OF ETYPE-INFO-ENTRY
-
-
-      ETYPE-INFO2-ENTRY       ::= SEQUENCE {
-              etype           [0] EType,
-              salt            [1] KerberosString OPTIONAL,
-              s2kparams       [2] OCTET STRING OPTIONAL
-      }
-
-
-
-      -- Obsolescent.  Salt for client's long-term key.
-      -- Its character encoding is unspecified.
-      pa-pw-salt              PaDataType ::= int32 : 3
-      -- The "padata-value" does not encode an ASN.1 type.
-      -- Instead, "padata-value" must consist of the salt string to
-      -- be used by the client, in an unspecified character
-      -- encoding.
-
-
-
-      -- An extensible AS-REQ may be sent as a padata in a
-      -- non-extensible AS-REQ to allow for backwards compatibility.
-      pa-as-req               PaDataType ::= int32 : 42 -- provisional
-      PA-AS-REQ               ::= AS-REQ (WITH COMPONENTS ext)
-
-
-
-      --
-      -- *** Session key exchange
-      --
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 91]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      AP-REQ          ::= CHOICE {
-          rfc1510     [APPLICATION 14] AP-REQ-1510,
-          ext         [APPLICATION 18] Signed {
-              AP-REQ-EXT, { key-session }, { ku-APReq-cksum }
-          }
-      }
-
-
-
-      AP-REQ-COMMON   ::= SEQUENCE {
-          pvno                [0] INTEGER (5),
-          msg-type            [1] INTEGER (14 | 18),
-          ap-options          [2] APOptions,
-          ticket              [3] Ticket,
-          authenticator       [4] EncryptedData {
-              Authenticator,
-              { key-session },
-              { ku-APReq-authenticator |
-                ku-pa-TGSReq-authenticator }
-          },
-          ...,
-          extensions          [5] ApReqExtensions OPTIONAL,
-          lang-tag            [6] SEQUENCE (SIZE (1..MAX))
-                                      OF LangTag OPTIONAL,
-          ...
-      }
-
-
-
-      AP-REQ-1510 ::= SEQUENCE {
-          COMPONENTS OF AP-REQ-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (14),
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmIA5),
-                  cname (PrincipalNameIA5),
-                  seqnum (UInt32)
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 92]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      AP-REQ-EXT      ::= AP-REQ-COMMON
-      (WITH COMPONENTS {
-          ...,
-          msg-type (18),
-          -- The following constraints on Authenticator assume that
-          -- we want to restrict the use of AP-REQ-EXT with TicketExt
-          -- only, since that is the only way we can enforce UTF-8.
-          authenticator (EncryptedData {
-              Authenticator (WITH COMPONENTS {
-                  ...,
-                  crealm (RealmExt),
-                  cname (PrincipalNameExt),
-                  authorization-data (SIZE (1..MAX))
-              }), { key-session }, { ku-APReq-authenticator }})
-      })
-
-
-
-      ApReqExtType    ::= TH-id
-
-
-      ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          apReqExt-Type       [0] ApReqExtType,
-          apReqExt-Data       [1] OCTET STRING
-      }
-
-
-
-      APOptions       ::= KerberosFlags { APOptionsBits }
-
-
-      APOptionsBits ::= BIT STRING {
-          reserved            (0),
-          use-session-key     (1),
-          mutual-required     (2)
-      }
-
-
-
-      -- plaintext of authenticator
-      Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-          authenticator-vno   [0] INTEGER (5),
-          crealm              [1] Realm,
-          cname               [2] PrincipalName,
-          cksum               [3] Checksum {{ key-session },
-              { ku-Authenticator-cksum |
-                ku-pa-TGSReq-cksum }} OPTIONAL,
-          cusec               [4] Microseconds,
-          ctime               [5] KerberosTime,
-          subkey              [6] EncryptionKey OPTIONAL,
-          seq-number          [7] SeqNum OPTIONAL,
-          authorization-data  [8] AuthorizationData OPTIONAL
-      }
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 93]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      AP-REP          ::= CHOICE {
-          rfc1510     [APPLICATION 15] AP-REP-1510,
-          ext         [APPLICATION 19] Signed {
-              AP-REP-EXT,
-              { key-session | key-subsession }, { ku-APRep-cksum }}
-      }
-
-
-
-      AP-REP-COMMON { EncPart }       ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (15 | 19),
-          enc-part    [2] EncryptedData {
-              EncPart,
-              { key-session | key-subsession }, { ku-EncAPRepPart }},
-          ...,
-          extensions          [3] ApRepExtensions OPTIONAL,
-          ...
-      }
-
-
-
-      AP-REP-1510     ::= SEQUENCE {
-          COMPONENTS OF AP-REP-COMMON { EncAPRepPart1510 }
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (15)
-      })
-
-
-
-      AP-REP-EXT      ::= [APPLICATION 19] AP-REP-COMMON {
-          EncAPRepPartExt
-      } (WITH COMPONENTS { ..., msg-type (19) })
-
-
-
-      ApRepExtType    ::= TH-id
-
-
-      ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
-          apRepExt-Type       [0] ApRepExtType,
-          apRepExt-Data       [1] OCTET STRING
-      }
-
-
-
-      EncAPRepPart    ::= CHOICE {
-          rfc1510     [APPLICATION 27] EncAPRepPart1510,
-          ext         [APPLICATION 31] EncAPRepPartExt
-      }
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 94]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      EncAPRepPart1510        ::= SEQUENCE {
-          COMPONENTS OF ENCAPRepPartCom
-      } (WITH COMPONENTS {
-          ...,
-          seq-number (UInt32),
-          authorization-data ABSENT
-      })
-
-
-
-      EncAPRepPartExt         ::= EncAPRepPartCom
-
-
-
-      EncAPRepPartCom          ::= SEQUENCE {
-          ctime               [0] KerberosTime,
-          cusec               [1] Microseconds,
-          subkey              [2] EncryptionKey OPTIONAL,
-          seq-number          [3] SeqNum OPTIONAL,
-          ...,
-          authorization-data  [4] AuthorizationData OPTIONAL,
-          ...
-      }
-
-
-
-      --
-      -- *** Application messages
-      --
-
-
-
-      -- Do we chew up another tag for KRB-SAFE-EXT?  That would
-      -- allow us to  make safe-body optional, allowing for a GSS-MIC
-      -- sort of message.
-      KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (20),
-          safe-body   [2] KRB-SAFE-BODY,
-          cksum       [3] ChecksumOf {
-              KRB-SAFE-BODY,
-              { key-session | key-subsession }, { ku-KrbSafe-cksum }},
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 95]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KRB-SAFE-BODY   ::= SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress,
-          r-address   [5] HostAddress OPTIONAL,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-      KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (21),
-          enc-part    [3] EncryptedData {
-              EncKrbPrivPart,
-              { key-session | key-subsession }, { ku-EncKrbPrivPart }},
-          ...
-      }
-
-
-
-      EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-          user-data   [0] OCTET STRING,
-          timestamp   [1] KerberosTime OPTIONAL,
-          usec        [2] Microseconds OPTIONAL,
-          seq-number  [3] SeqNum OPTIONAL,
-          s-address   [4] HostAddress -- sender's addr --,
-          r-address   [5] HostAddress OPTIONAL -- recip's addr --,
-          ...         -- ASN.1 extensions must be excluded
-                      -- when sending to rfc1510 implementations
-      }
-
-
-
-      KRB-CRED        ::= CHOICE {
-          rfc1510     [APPLICATION 22] KRB-CRED-1510,
-          ext         [APPLICATION 24] Signed {
-              KRB-CRED-EXT,
-              { key-session | key-subsession }, { ku-KrbCred-cksum }}
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 96]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KRB-CRED-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (22 | 24),
-          tickets     [2] SEQUENCE OF Ticket,
-          enc-part    [3] EncryptedData {
-              EncKrbCredPart,
-              { key-session | key-subsession }, { ku-EncKrbCredPart }},
-          ...
-      }
-
-
-
-      KRB-CRED-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-CRED-COMMON
-      } (WITH COMPONENTS { ..., msg-type (22) })
-
-
-
-      KRB-CRED-EXT    ::= [APPLICATION 24] KRB-CRED-COMMON
-          (WITH COMPONENTS { ..., msg-type (24) })
-
-
-
-      EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-          ticket-info [0] SEQUENCE OF KrbCredInfo,
-          nonce       [1] Nonce OPTIONAL,
-          timestamp   [2] KerberosTime OPTIONAL,
-          usec        [3] Microseconds OPTIONAL,
-          s-address   [4] HostAddress OPTIONAL,
-          r-address   [5] HostAddress OPTIONAL
-      }
-
-
-
-      KrbCredInfo     ::= SEQUENCE {
-          key         [0] EncryptionKey,
-          prealm      [1] Realm OPTIONAL,
-          pname       [2] PrincipalName OPTIONAL,
-          flags       [3] TicketFlags OPTIONAL,
-          authtime    [4] KerberosTime OPTIONAL,
-          starttime   [5] KerberosTime OPTIONAL,
-          endtime     [6] KerberosTime OPTIONAL,
-          renew-till  [7] KerberosTime OPTIONAL,
-          srealm      [8] Realm OPTIONAL,
-          sname       [9] PrincipalName OPTIONAL,
-          caddr       [10] HostAddresses OPTIONAL
-      }
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 97]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      TGT-REQ         ::= [APPLICATION 16] SEQUENCE {
-          pvno            [0] INTEGER (5),
-          msg-type        [1] INTEGER (16),
-          sname           [2] PrincipalName OPTIONAL,
-          srealm          [3] Realm OPTIONAL,
-          ...
-      }
-
-
-
-      --
-      -- *** Error messages
-      --
-
-
-
-      ErrCode ::= Int32
-
-
-      KRB-ERROR       ::= CHOICE {
-          rfc1510     [APPLICATION 30] KRB-ERROR-1510,
-          ext         [APPLICATION 23] Signed {
-              KRB-ERROR-EXT, { ku-KrbError-cksum } }
-      }
-
-
-
-      KRB-ERROR-COMMON ::= SEQUENCE {
-          pvno        [0] INTEGER (5),
-          msg-type    [1] INTEGER (30 | 23),
-          ctime       [2] KerberosTime OPTIONAL,
-          cusec       [3] Microseconds OPTIONAL,
-          stime       [4] KerberosTime,
-          susec       [5] Microseconds,
-          error-code  [6] ErrCode,
-          crealm      [7] Realm OPTIONAL,
-          cname       [8] PrincipalName OPTIONAL,
-          realm       [9] Realm -- Correct realm --,
-          sname       [10] PrincipalName -- Correct name --,
-          e-text      [11] KerberosString OPTIONAL,
-          e-data      [12] OCTET STRING OPTIONAL,
-          ...,
-          typed-data          [13] TYPED-DATA OPTIONAL,
-          nonce               [14] Nonce OPTIONAL,
-          lang-tag            [15] LangTag OPTIONAL,
-          ...
-      }
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 98]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      KRB-ERROR-1510 ::= SEQUENCE {
-          COMPONENTS OF KRB-ERROR-COMMON
-      } (WITH COMPONENTS {
-          ...,
-          msg-type (30)
-      })
-
-
-
-      KRB-ERROR-EXT ::= [APPLICATION 23] KRB-ERROR-COMMON
-          (WITH COMPONENTS { ..., msg-type (23) })
-
-
-
-      METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-
-
-      TDType ::= TH-id
-
-
-      TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-          data-type   [0] TDType,
-          data-value  [1] OCTET STRING OPTIONAL
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                   [Page 99]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      --
-      -- *** Error codes
-      --
-
-
-      -- No error
-      kdc-err-none                          ErrCode ::= 0
-      -- Client's entry in database has expired
-      kdc-err-name-exp                      ErrCode ::= 1
-      -- Server's entry in database has expired
-      kdc-err-service-exp                   ErrCode ::= 2
-      -- Requested protocol version number not supported
-      kdc-err-bad-pvno                      ErrCode ::= 3
-      -- Client's key encrypted in old master key
-      kdc-err-c-old-mast-kvno               ErrCode ::= 4
-      -- Server's key encrypted in old master key
-      kdc-err-s-old-mast-kvno               ErrCode ::= 5
-      -- Client not found in Kerberos database
-      kdc-err-c-principal-unknown           ErrCode ::= 6
-      -- Server not found in Kerberos database
-      kdc-err-s-principal-unknown           ErrCode ::= 7
-      -- Multiple principal entries in database
-      kdc-err-principal-not-unique          ErrCode ::= 8
-      -- The client or server has a null key
-      kdc-err-null-key                      ErrCode ::= 9
-      -- Ticket not eligible for postdating
-      kdc-err-cannot-postdate               ErrCode ::= 10
-      -- Requested start time is later than end time
-      kdc-err-never-valid                   ErrCode ::= 11
-      -- KDC policy rejects request
-      kdc-err-policy                        ErrCode ::= 12
-      -- KDC cannot accommodate requested option
-      kdc-err-badoption                     ErrCode ::= 13
-      -- KDC has no support for encryption type
-      kdc-err-etype-nosupp                  ErrCode ::= 14
-      -- KDC has no support for checksum type
-      kdc-err-sumtype-nosupp                ErrCode ::= 15
-      -- KDC has no support for padata type
-      kdc-err-padata-type-nosupp            ErrCode ::= 16
-      -- KDC has no support for transited type
-      kdc-err-trtype-nosupp                 ErrCode ::= 17
-      -- Clients credentials have been revoked
-      kdc-err-client-revoked                ErrCode ::= 18
-      -- Credentials for server have been revoked
-      kdc-err-service-revoked               ErrCode ::= 19
-      -- TGT has been revoked
-      kdc-err-tgt-revoked                   ErrCode ::= 20
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                  [Page 100]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- Client not yet valid - try again later
-      kdc-err-client-notyet                 ErrCode ::= 21
-      -- Server not yet valid - try again later
-      kdc-err-service-notyet                ErrCode ::= 22
-      -- Password has expired - change password to reset
-      kdc-err-key-expired                   ErrCode ::= 23
-      -- Pre-authentication information was invalid
-      kdc-err-preauth-failed                ErrCode ::= 24
-      -- Additional pre-authenticationrequired
-      kdc-err-preauth-required              ErrCode ::= 25
-      -- Requested server and ticket don't match
-      kdc-err-server-nomatch                ErrCode ::= 26
-      -- Server principal valid for user2user only
-      kdc-err-must-use-user2user            ErrCode ::= 27
-      -- KDC Policy rejects transited path
-      kdc-err-path-not-accpeted             ErrCode ::= 28
-      -- A service is not available
-      kdc-err-svc-unavailable               ErrCode ::= 29
-      -- Integrity check on decrypted field failed
-      krb-ap-err-bad-integrity              ErrCode ::= 31
-      -- Ticket expired
-      krb-ap-err-tkt-expired                ErrCode ::= 32
-      -- Ticket not yet valid
-      krb-ap-err-tkt-nyv                    ErrCode ::= 33
-      -- Request is a replay
-      krb-ap-err-repeat                     ErrCode ::= 34
-      -- The ticket isn't for us
-      krb-ap-err-not-us                     ErrCode ::= 35
-      -- Ticket and authenticator don't match
-      krb-ap-err-badmatch                   ErrCode ::= 36
-      -- Clock skew too great
-      krb-ap-err-skew                       ErrCode ::= 37
-      -- Incorrect net address
-      krb-ap-err-badaddr                    ErrCode ::= 38
-      -- Protocol version mismatch
-      krb-ap-err-badversion                 ErrCode ::= 39
-      -- Invalid msg type
-      krb-ap-err-msg-type                   ErrCode ::= 40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                  [Page 101]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- Message stream modified
-      krb-ap-err-modified                   ErrCode ::= 41
-      -- Message out of order
-      krb-ap-err-badorder                   ErrCode ::= 42
-      -- Specified version of key is not available
-      krb-ap-err-badkeyver                  ErrCode ::= 44
-      -- Service key not available
-      krb-ap-err-nokey                      ErrCode ::= 45
-      -- Mutual authentication failed
-      krb-ap-err-mut-fail                   ErrCode ::= 46
-      -- Incorrect message direction
-      krb-ap-err-baddirection               ErrCode ::= 47
-      -- Alternative authentication method required
-      krb-ap-err-method                     ErrCode ::= 48
-      -- Incorrect sequence number in message
-      krb-ap-err-badseq                     ErrCode ::= 49
-      -- Inappropriate type of checksum in message
-      krb-ap-err-inapp-cksum                ErrCode ::= 50
-      -- Policy rejects transited path
-      krb-ap-path-not-accepted              ErrCode ::= 51
-      -- Response too big for UDP, retry with TCP
-      krb-err-response-too-big              ErrCode ::= 52
-      -- Generic error (description in e-text)
-      krb-err-generic                       ErrCode ::= 60
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                  [Page 102]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-      -- Field is too long for this implementation
-      krb-err-field-toolong                 ErrCode ::= 61
-      -- Reserved for PKINIT
-      kdc-error-client-not-trusted          ErrCode ::= 62
-      -- Reserved for PKINIT
-      kdc-error-kdc-not-trusted             ErrCode ::= 63
-      -- Reserved for PKINIT
-      kdc-error-invalid-sig                 ErrCode ::= 64
-      -- Reserved for PKINIT
-      kdc-err-key-too-weak                  ErrCode ::= 65
-      -- Reserved for PKINIT
-      kdc-err-certificate-mismatch          ErrCode ::= 66
-      -- No TGT available to validate USER-TO-USER
-      krb-ap-err-no-tgt                     ErrCode ::= 67
-      -- USER-TO-USER TGT issued different KDC
-      kdc-err-wrong-realm                   ErrCode ::= 68
-      -- Ticket must be for USER-TO-USER
-      krb-ap-err-user-to-user-required      ErrCode ::= 69
-      -- Reserved for PKINIT
-      kdc-err-cant-verify-certificate       ErrCode ::= 70
-      -- Reserved for PKINIT
-      kdc-err-invalid-certificate           ErrCode ::= 71
-      -- Reserved for PKINIT
-      kdc-err-revoked-certificate           ErrCode ::= 72
-      -- Reserved for PKINIT
-      kdc-err-revocation-status-unknown     ErrCode ::= 73
-      -- Reserved for PKINIT
-      kdc-err-revocation-status-unavailable ErrCode ::= 74
-
-
-
-      END
-
-
-
-B.  Kerberos and Character Encodings (Informative)
-
-
-   [adapted from KCLAR 5.2.1]
-
-
-   The original specification of the Kerberos protocol in RFC 1510 uses
-   GeneralString in numerous places for human-readable string data.
-   Historical implementations of Kerberos cannot utilize the full power
-   of GeneralString.  This ASN.1 type requires the use of designation
-   and invocation escape sequences as specified in ISO 2022 | ECMA-35
-   [ISO2022] to switch character sets, and the default character set
-   that is designated as G0 is the ISO 646 | ECMA-6 [ISO646]
-   International Reference Version (IRV) (aka U.S. ASCII), which mostly
-   works.
-
-
-   ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3)
-   and two Control-function code elements (C0..C1).  DER previously
-   [X690-1997] prohibited the designation of character sets as any but
-   the G0 and C0 sets.  This had the side effect of prohibiting the use
-
-
-Yu                         Expires: Apr 2005                  [Page 103]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any
-   other character-sets that utilize a 96-character set, since it is
-   prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code
-   element.  Recent revisions to the ASN.1 standards resolve this
-   contradiction.
-
-
-   In practice, many implementations treat RFC 1510 GeneralStrings as if
-   they were 8-bit strings of whichever character set the implementation
-   defaults to, without regard for correct usage of character-set
-   designation escape sequences.  The default character set is often
-   determined by the current user's operating system dependent locale.
-   At least one major implementation places unescaped UTF-8 encoded
-   Unicode characters in the GeneralString.  This failure to conform to
-   the GeneralString specifications results in interoperability issues
-   when conflicting character encodings are utilized by the Kerberos
-   clients, services, and KDC.
-
-
-   This unfortunate situation is the result of improper documentation of
-   the restrictions of the ASN.1 GeneralString type in prior Kerberos
-   specifications.
-
-
-   [the following should probably be rewritten and moved into the
-   principal name section]
-
-
-   For compatibility, implementations MAY choose to accept GeneralString
-   values that contain characters other than those permitted by
-   IA5String, but they should be aware that character set designation
-   codes will likely be absent, and that the encoding should probably be
-   treated as locale-specific in almost every way.  Implementations MAY
-   also choose to emit GeneralString values that are beyond those
-   permitted by IA5String, but should be aware that doing so is
-   extraordinarily risky from an interoperability perspective.
-
-
-   Some existing implementations use GeneralString to encode unescaped
-   locale-specific characters.  This is a violation of the ASN.1
-   standard.  Most of these implementations encode US-ASCII in the left-
-   hand half, so as long the implementation transmits only US-ASCII, the
-   ASN.1 standard is not violated in this regard.  As soon as such an
-   implementation encodes unescaped locale-specific characters with the
-   high bit set, it violates the ASN.1 standard.
-
-
-   Other implementations have been known to use GeneralString to contain
-   a UTF-8 encoding.  This also violates the ASN.1 standard, since UTF-8
-   is a different encoding, not a 94 or 96 character "G" set as defined
-   by ISO 2022.  It is believed that these implementations do not even
-   use the ISO 2022 escape sequence to change the character encoding.
-   Even if implementations were to announce the change of encoding by
-   using that escape sequence, the ASN.1 standard prohibits the use of
-   any escape sequences other than those used to designate/invoke "G" or
-   "C" sets allowed by GeneralString.
-
-
-
-Yu                         Expires: Apr 2005                  [Page 104]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-C.  Kerberos History (Informative)
-
-
-   [Adapted from KCLAR "BACKGROUND"]
-
-
-   The Kerberos model is based in part on Needham and Schroeder's
-   trusted third-party authentication protocol [NS78] and on
-   modifications suggested by Denning and Sacco [DS81].  The original
-   design and implementation of Kerberos Versions 1 through 4 was the
-   work of two former Project Athena staff members, Steve Miller of
-   Digital Equipment Corporation and Clifford Neuman (now at the
-   Information Sciences Institute of the University of Southern
-   California), along with Jerome Saltzer, Technical Director of Project
-   Athena, and Jeffrey Schiller, MIT Campus Network Manager.  Many other
-   members of Project Athena have also contributed to the work on
-   Kerberos.
-
-
-   Version 5 of the Kerberos protocol (described in this document) has
-   evolved from Version 4 based on new requirements and desires for
-   features not available in Version 4.  The design of Version 5 of the
-   Kerberos protocol was led by Clifford Neuman and John Kohl with much
-   input from the community.  The development of the MIT reference
-   implementation was led at MIT by John Kohl and Theodore Ts'o, with
-   help and contributed code from many others.  Since RFC1510 was
-   issued, extensions and revisions to the protocol have been proposed
-   by many individuals.  Some of these proposals are reflected in this
-   document.  Where such changes involved significant effort, the
-   document cites the contribution of the proposer.
-
-
-   Reference implementations of both version 4 and version 5 of Kerberos
-   are publicly available and commercial implementations have been
-   developed and are widely used.  Details on the differences between
-   Kerberos Versions 4 and 5 can be found in [KNT94].
-
-
-D.  Notational Differences from [KCLAR]
-
-
-   [ possible point for discussion ]
-
-
-   [KCLAR] uses notational conventions slightly different from this
-   document.  As a derivative of RFC 1510, the text of [KCLAR] uses C-
-   language style identifier names for defined values.  In ASN.1
-   notation, identifiers referencing defined values must begin with a
-   lowercase letter and contain hyphen (-) characters rather than
-   underscore (_) characters, while identifiers referencing types begin
-   with an uppercase letter.  [KCLAR] and RFC 1510 use all-uppercase
-   identifiers with underscores to identify defined values.  This has
-   the potential to create confusion, but neither document defines
-   values using actual ASN.1 value-assignment notation.
-
-
-   It is debatable whether it is advantageous to write all identifier
-   names (regardless of their ASN.1 token type) in all-uppercase letters
-   for the purpose of emphasis in running text.  The alternative is to
-
-
-Yu                         Expires: Apr 2005                  [Page 105]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   use double-quote characters (") when ambiguity is possible.
-
-
-Normative References
-
-
-   [ISO646]
-        "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991.
-
-
-   [ISO2022]
-        "Information technology -- Character code structure and
-        extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994.
-
-
-   [KCRYPTO]
-        K. Raeburn, "Encryption and Checksum Specifications for Kerberos
-        5", draft-ietf-krb-wg-crypto-07.txt, work in progress.
-
-
-   [RFC2119]
-        S. Bradner, RFC2119: "Key words for use in RFC's to Indicate
-        Requirement Levels", March 1997.
-
-
-   [RFC3660]
-        H. Alvestrand, "Tags for the Identification of Languages",
-        RFC 3660, January 2001.
-
-
-   [SASLPREP]
-        Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names
-        and passwords", draft-ietf-sasl-saslprep-10.txt, work in
-        progress.
-
-
-   [X680]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Specification of basic notation", ITU-T Recommendation X.680
-        (2002) | ISO/IEC 8824-1:2002.
-
-
-   [X682]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Constraint specification", ITU-T Recommendation X.682 (2002) |
-        ISO/IEC 8824-3:2002.
-
-
-   [X683]
-        "Information technology -- Abstract Syntax Notation One (ASN.1):
-        Parameterization of ASN.1 specifications", ITU-T Recommendation
-        X.683 (2002) | ISO/IEC 8824-4:2002.
-
-
-   [X690]
-        "Information technology -- ASN.1 encoding Rules: Specification
-        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
-        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
-        X.690 (2002) | ISO/IEC 8825-1:2002.
-
-
-
-
-
-Yu                         Expires: Apr 2005                  [Page 106]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-Informative References
-
-
-   [DS81]
-        Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key
-        Distribution Protocols," Communications of the ACM, Vol. 24(8),
-        pp. 533-536 (August 1981).
-
-
-   [Dub00]
-        Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous
-        Systems", Elsevier-Morgan Kaufmann, 2000.
-        <http://www.oss.com/asn1/dubuisson.html>
-
-
-   [ISO8859-1]
-        "Information technology -- 8-bit single-byte coded graphic
-        character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859-
-        1:1998.
-
-
-   [KCLAR]
-        Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos
-        Network Authentication Service (V5)", draft-ietf-krb-wg-
-        kerberos-clarifications-07.txt, work in progress.
-
-
-   [KNT94]
-        John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The
-        Evolution of the Kerberos Authentication System".  In
-        Distributed Open Systems, pages 78-94.  IEEE Computer Society
-        Press, 1994.
-
-
-   [Lar96]
-        John Larmouth, "Understanding OSI", International Thomson
-        Computer Press, 1996.
-        <http://www.isi.salford.ac.uk/books/osi.html>
-
-
-   [Lar99]
-        John Larmouth, "ASN.1 Complete",  Elsevier-Morgan Kaufmann,
-        1999.  <http://www.oss.com/asn1/larmouth.html>
-
-
-   [NS78]
-        Roger M. Needham and Michael D. Schroeder, "Using Encryption for
-        Authentication in Large Networks of Computers", Communications
-        of the ACM, Vol. 21(12), pp. 993-999 (December, 1978).
-
-
-   [RFC1510]
-        J. Kohl and B. C. Neuman, "The Kerberos Network Authentication
-        Service (v5)", RFC1510, September 1993, Status: Proposed
-        Standard.
-
-
-   [RFC1964]
-        J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
-        June 1996, Status: Proposed Standard.
-
-
-
-Yu                         Expires: Apr 2005                  [Page 107]
-Internet-Draft            yu-krb-extensions-02               25 Oct 2004
-
-
-   [X690-2002]
-        "Information technology -- ASN.1 encoding rules: Specification
-        of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
-        and Distinguished Encoding Rules (DER)", ITU-T Recommendation
-        X.690 (2002) | ISO/IEC 8825-1:2002.
-
-
-Author's Address
-
-
-   Tom Yu
-   77 Massachusetts Ave
-   Cambridge, MA 02139
-   USA
-   tlyu@mit.edu
-
-
-Full Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yu                         Expires: Apr 2005                  [Page 108] 
\ No newline at end of file
diff --git a/doc/standardisation/draft-zhu-kerb-enctype-nego-00.txt b/doc/standardisation/draft-zhu-kerb-enctype-nego-00.txt
deleted file mode 100644
index 35d2f0709..000000000
--- a/doc/standardisation/draft-zhu-kerb-enctype-nego-00.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                                  P. Leach
-Expires: June 4, 2005                                      K. Jaganathan
-                                                   Microsoft Corporation
-                                                           December 2004
-
-
-              Kerberos Cryptosystem Negotiation Extension
-                     draft-zhu-kerb-enctype-nego-00
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on June 4, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document specifies an extension by Kerberos to negotiate new
-   encryption types between the client-server peers.
-
-
-
-
-
-
-Zhu, et al.               Expires June 4, 2005                  [Page 1]
-
-Internet-Draft             Enctype Negotiation             December 2004
-
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.   Conventions Used in This Document  . . . . . . . . . . . . .   4
-   3.   Negotiation Protocol . . . . . . . . . . . . . . . . . . . .   5
-   4.   Security Considerations  . . . . . . . . . . . . . . . . . .   6
-   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   7
-   6.   Normative References . . . . . . . . . . . . . . . . . . . .   7
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .   7
-   A.   Leveraging this Enctype Negotiation in Windows SPNEGO
-        Implementations  . . . . . . . . . . . . . . . . . . . . . .   9
-        Intellectual Property and Copyright Statements . . . . . . .  10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 4, 2005                  [Page 2]
-
-Internet-Draft             Enctype Negotiation             December 2004
-
-
-1.  Introduction
-
-   Under the current mechanism [CLAR], the KDC must limit the ticket
-   session key enctype chosen for a given service to one it believes is
-   supported by both the client and the server.  If both the client and
-   server understand a stronger enctype than is selected by the KDC,
-   they can not negotiate it.  As the result, the protection of
-   application traffic is often weaker than necessary when different
-   application software that support different set of enctypes can be
-   used by the same server principal.
-
-   This document specifies an extension to Kerberos to allow clients and
-   servers to negotiate a different and possible stronger cryptosystem
-   to be used in subsequent communication.
-
-   This extension utilizes an authorization data element in the
-   authenticator of the KRB_AP_REQ message [CLAR].  The client sends the
-   list of enctypes that it supports to the server, the server then
-   informs the client its choice.  The negotiated subkey is sent in the
-   KRB_AP_REP.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 4, 2005                  [Page 3]
-
-Internet-Draft             Enctype Negotiation             December 2004
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 4, 2005                  [Page 4]
-
-Internet-Draft             Enctype Negotiation             December 2004
-
-
-3.  Negotiation Protocol
-
-   If the client prefers an enctype over that of the service ticket
-   session key, then it MUST send the list of enctypes it supports
-   (including the one selected by the KDC), in decreasing preference
-   order.
-
-   The client sends the enctype list via the authorization-data of the
-   authenticator in the KRB_AP_REQ [CLAR].  A new authorization data
-   element type AD-ETYPE-NEGOTIATION (129) is defined.  This
-   authorization data element itself is enclosed in the AD-IF-RELEVANT
-   container, thus a correctly implemented server that does not
-   understand this element should ignore it [CLAR].  The value of this
-   authorization element contains the DER [X60] encoding of the
-   following ASN.1 type:
-
-           EtypeList ::= SEQUENCE OF Int32
-              -- the client's proposed enctype list in decreasing
-              -- preference order, favorite choice first
-
-   If the EtypeList is present and the server prefers an enctype from
-   the client's enctype list over that of the KRB_AP_REQ authenticator
-   subkey (if that is present) or the service ticket session key, the
-   server MUST create a subkey using that enctype.  This negotiated
-   subkey is sent in the subkey field of KRB_AP_REP message and it MUST
-   be used for subsequent communication.
-
-   Note that to preserve the quality of randomness provided by the KDC,
-   implementations of this protocol SHOULD consider using the service
-   ticket session key value as a source of additional entropy when
-   generating the negotiated subkey.  If the KRB_AP_REQ authenticator
-   subkey is present, it MAY also be used as a source of entropy.
-
-   The policy by which the client or the server chooses an enctype
-   (i.e., how the preference order for the supported enctypes is
-   selected) is an implementation-specific local matter.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 4, 2005                  [Page 5]
-
-Internet-Draft             Enctype Negotiation             December 2004
-
-
-4.  Security Considerations
-
-   The client's enctype list and the server's reply enctype are part of
-   encrypted data, thus the security considerations are the same as
-   those of the Kerberos encrypted data.
-
-   In all cases, the communicating peers are exposed to the denial of
-   service threat.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 4, 2005                  [Page 6]
-
-Internet-Draft             Enctype Negotiation             December 2004
-
-
-5.  IANA Considerations
-
-   No IANA actions are required for this document.
-
-6.  Normative References
-
-   [CLAR]     Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", August
-              2004.
-
-   [GSS-CFX]  Zhu, L., Jaganathan, K. and S. Hartman, "The Kerberos
-              Version 5 GSS-API Mechanism: Version 2", November 2004.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [SPNEGOBIS]
-              Zhu, L., Leach, P., Jaganathan, K., Hartman, S. and W.
-              Ingersoll, "The Simple and Protected GSS-API Negotiation
-              Mechanism", November 2004.
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Paul Leach
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: paulle@microsoft.com
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 4, 2005                  [Page 7]
-
-Internet-Draft             Enctype Negotiation             December 2004
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 4, 2005                  [Page 8]
-
-Internet-Draft             Enctype Negotiation             December 2004
-
-
-Appendix A.  Leveraging this Enctype Negotiation in Windows SPNEGO
-            Implementations
-
-   The SPNEGO implementations in Windows 2000, Windows XP and Windows
-   2003 do not generate or verify the mechlistMIC field when it is
-   required [SPNEGOBIS].
-
-   When the SPNEGO implementations that are updated according to
-   [SPNEGOBIS], an SSPI initiator or acceptor needs to determine if the
-   peer is updated, so that it can generate the mechlistMIC token when
-   the peer can process it.  With the bidirectional negotiation, the
-   updated SPNEGO implementation can achieve the following two goals:
-
-   o  It can remain backward compatible with legacy implementations, if
-      local policy allows unsafe and unprotected negotiation with
-      downlevel implementations when the mechlistMIC token exchange
-      would otherwise be required by [SPNEGOBIS].
-   o  The mechanism negotiation is protected according to [SPNEGOBIS]
-      when both peers are updated.
-
-   However, the updated SPNEGO implementation itself can not securely
-   inform the peer whether the local implementation is updated, thus it
-   has to obtain such information from the negotiated mechanism.
-
-   For Windows SPNEGO implementations, both the initiator and the
-   acceptor are assumed to have been updated if a "newer" [CLAR] or
-   different enctype is negotiated for use by the Kerberos GSS-API
-   mechanism.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires June 4, 2005                  [Page 9]
-
-Internet-Draft             Enctype Negotiation             December 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.               Expires June 4, 2005                 [Page 10]
-
-
diff --git a/doc/standardisation/draft-zhu-kerb-enctype-nego-01.txt b/doc/standardisation/draft-zhu-kerb-enctype-nego-01.txt
deleted file mode 100644
index 60be49b7a..000000000
--- a/doc/standardisation/draft-zhu-kerb-enctype-nego-01.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                                  P. Leach
-Expires: October 2, 2005                                   K. Jaganathan
-                                                   Microsoft Corporation
-                                                          March 31, 2005
-
-
-              Kerberos Cryptosystem Negotiation Extension
-                      draft-zhu-kerb-enctype-nego-01
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on October 2, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document specifies an extension by Kerberos to negotiate new
-   encryption types between the client-server peers.
-
-
-
-
-
-
-Zhu, et al.              Expires October 2, 2005                [Page 1]
-
-Internet-Draft             Enctype Negotiation                March 2005
-
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.   Conventions Used in This Document  . . . . . . . . . . . . . . 3
-   3.   Negotiation Extension  . . . . . . . . . . . . . . . . . . . . 3
-   4.   Security Considerations  . . . . . . . . . . . . . . . . . . . 4
-   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 4
-   6.   Normative References . . . . . . . . . . . . . . . . . . . . . 4
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5
-   A.   Leveraging this Enctype Negotiation in Windows SPNEGO
-        Implementations  . . . . . . . . . . . . . . . . . . . . . . . 5
-        Intellectual Property and Copyright Statements . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires October 2, 2005                [Page 2]
-
-Internet-Draft             Enctype Negotiation                March 2005
-
-
-1.  Introduction
-
-   Under the current mechanism [CLAR], the KDC must limit the ticket
-   session key enctype chosen for a given server to one it believes is
-   supported by both the client and the server.  If both the client and
-   server understand a stronger enctype than the one selected by the
-   KDC, they can not negotiate it.  As the result, the protection of
-   application traffic is often weaker than necessary when the server
-   can support different sets of enctypes depending on the server
-   application software being used.
-
-   This document specifies an extension to Kerberos to allow clients and
-   servers to negotiate a different and possible stronger cryptosystem
-   to be used in subsequent communication.
-
-   This extension utilizes an authorization data element in the
-   authenticator of the AP-REQ message [CLAR].  The client sends the
-   list of enctypes that it supports to the server, the server then
-   informs the client its choice.  The negotiated subkey is sent in the
-   AP-REP message [CLAR].
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-3.  Negotiation Extension
-
-   If the client prefers an enctype over that of the service ticket
-   session key, then it MUST send the list of enctypes it supports
-   (including the one selected by the KDC) in decreasing preference
-   order.
-
-   The client sends the enctype list via the authorization-data of the
-   authenticator in the AP-REQ [CLAR].  A new authorization data element
-   type AD-ETYPE-NEGOTIATION (129) is defined.  This authorization data
-   element itself is enclosed in the AD-IF-RELEVANT container, thus a
-   correctly implemented server that does not understand this element
-   should ignore it [CLAR].  The value of this authorization element
-   contains the DER [X60] encoding of the following ASN.1 type:
-
-           EtypeList ::= SEQUENCE OF Int32
-              -- Specifies the enctypes supported by the client.
-              -- This enctype list is in decreasing preference order
-              -- (favorite choice first).
-              -- Int32 is defined in [CLAR].
-
-
-
-
-Zhu, et al.              Expires October 2, 2005                [Page 3]
-
-Internet-Draft             Enctype Negotiation                March 2005
-
-
-   If the EtypeList is present and the server prefers an enctype from
-   the client's enctype list over that of the AP-REQ authenticator
-   subkey (if that is present) or the service ticket session key, the
-   server MUST create a subkey using that enctype.  This negotiated
-   subkey is sent in the subkey field of AP-REP message and it MUST be
-   used for subsequent communication.
-
-   This negotiation extension MUST NOT be used when the client does not
-   expect the subkey in the AP-REP message from the server.
-
-   Note that to preserve the quality of randomness provided by the KDC,
-   implementations of this extension SHOULD consider using the service
-   ticket session key value as a source of additional entropy when
-   generating the negotiated subkey.  If the AP-REQ authenticator subkey
-   is present, it MAY also be used as a source of entropy.
-
-   The policy by which the client or the server chooses an enctype
-   (i.e., how the preference order for the supported enctypes is
-   selected) is an implementation-specific local matter.
-
-4.  Security Considerations
-
-   The client's enctype list and the server's reply enctype are part of
-   encrypted data, thus the security considerations are the same as
-   those of the Kerberos encrypted data.
-
-   In all cases, the communicating peers are exposed to the denial of
-   service threat.
-
-5.  IANA Considerations
-
-   No IANA actions are required for this document.
-
-6.  Normative References
-
-   [CLAR]     RFC-Editor: To be replaced by RFC number for draft-ietf-
-              krb-wg-kerberos-clarifications.  Work in Progress. 
-                            
-   [GSS-CFX]  RFC-Editor: To be replaced by RFC number for draft-ietf-
-              krb-wg-gssapi-cfx.  Work in Progress. 
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-
-
-
-Zhu, et al.              Expires October 2, 2005                [Page 4]
-
-Internet-Draft             Enctype Negotiation                March 2005
-
-
-   [SPNEGOBIS]
-              RFC-Editor: To be replaced by RFC number for draft-ietf-
-              kitten-2478bis.  Work in progress.
-
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding Rules 
-              (BER), Canonical Encoding Rules (CER) and Distinguished 
-              Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 
-              ISO/IEC International Standard 8825-1:1998.
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Paul Leach
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: paulle@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-Appendix A.  Leveraging this Enctype Negotiation in Windows SPNEGO
-            Implementations
-
-   The SPNEGO implementations in Windows 2000, Windows XP and Windows
-   2003 do not generate or verify the mechlistMIC field when it is
-   required [SPNEGOBIS].
-
-   When the SPNEGO implementations that are updated according to
-   [SPNEGOBIS], an SSPI initiator or acceptor needs to determine if the
-   peer is updated, so that it can generate the mechlistMIC token when
-   the peer can process it.  With the bidirectional negotiation, the
-   updated SPNEGO implementation can achieve the following two goals:
-
-
-
-
-
-Zhu, et al.              Expires October 2, 2005                [Page 5]
-
-Internet-Draft             Enctype Negotiation                March 2005
-
-
-   o  It can remain backward compatible with legacy implementations, if
-      local policy allows unsafe and unprotected negotiation with
-      downlevel implementations when the mechlistMIC token exchange
-      would otherwise be required by [SPNEGOBIS].
-
-   o  The mechanism negotiation is protected according to [SPNEGOBIS]
-      when both peers are updated.
-
-   However, the updated SPNEGO implementation itself can not securely
-   inform the peer whether the local implementation is updated, thus it
-   has to obtain such information from the negotiated mechanism.
-
-   For Windows SPNEGO implementations, both the initiator and the
-   acceptor are assumed to have been updated if a "newer" [CLAR] or
-   different enctype is negotiated for use by the Kerberos GSS-API
-   mechanism.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires October 2, 2005                [Page 6]
-
-Internet-Draft             Enctype Negotiation                March 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.              Expires October 2, 2005                [Page 7]
-
-
diff --git a/doc/standardisation/draft-zhu-kerb-enctype-nego-03.txt b/doc/standardisation/draft-zhu-kerb-enctype-nego-03.txt
deleted file mode 100644
index dfc61bf65..000000000
--- a/doc/standardisation/draft-zhu-kerb-enctype-nego-03.txt
+++ /dev/null
@@ -1,397 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                                  P. Leach
-Updates: 4120 (if approved)                                K. Jaganathan
-Expires: January 20, 2006                          Microsoft Corporation
-                                                           July 19, 2005
-
-
-              Kerberos Cryptosystem Negotiation Extension
-                     draft-zhu-kerb-enctype-nego-03
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 20, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document specifies an extension to the Kerberos protocol where
-   the client can send a list of supported encryption types in
-   decreasing preference order, and the server then selects an
-   encryption type that is supported by both the client and the server.
-
-
-
-
-
-
-Zhu, et al.             Expires January 20, 2006                [Page 1]
-
-Internet-Draft             Enctype Negotiation                 July 2005
-
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.   Conventions Used in This Document  . . . . . . . . . . . . . . 3
-   3.   Negotiation Extension  . . . . . . . . . . . . . . . . . . . . 3
-   4.   Security Considerations  . . . . . . . . . . . . . . . . . . . 4
-   5.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
-   6.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 5
-   7.   Normative References . . . . . . . . . . . . . . . . . . . . . 5
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5
-        Intellectual Property and Copyright Statements . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires January 20, 2006                [Page 2]
-
-Internet-Draft             Enctype Negotiation                 July 2005
-
-
-1.  Introduction
-
-   Under the current mechanism [RFC4120], the KDC must limit the ticket
-   session key encryption type (enctype) chosen for a given server to
-   one it believes is supported by both the client and the server.  If
-   both the client and server understand a stronger enctype than the one
-   selected by the KDC, they can not negotiate it.  As the result, the
-   protection of application traffic is often weaker than necessary when
-   the server can support different sets of enctypes depending on the
-   server application software being used.
-
-   This document specifies an extension to the Kerberos protocol to
-   allow clients and servers to negotiate a different and possible
-   stronger cryptosystem to be used in subsequent communication.
-
-   This extension utilizes an authorization data element in the
-   authenticator of the AP-REQ message [RFC4120].  The client sends the
-   list of enctypes that it supports to the server, the server then
-   informs the client its choice.  The negotiated subkey is sent in the
-   AP-REP message [RFC4120].
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-3.  Negotiation Extension
-
-   If the client prefers an enctype over that of the service ticket
-   session key, then it sends the list of enctypes it supports
-   (including the one selected by the KDC) in decreasing preference
-   order.
-
-   The client sends the enctype list via the authorization-data of the
-   authenticator in the AP-REQ [RFC4120].  A new authorization data
-   element type AD-ETYPE-NEGOTIATION is defined.
-
-           AD-ETYPE-NEGOTIATION              129
-
-   This authorization data element itself is enclosed in the AD-IF-
-   RELEVANT container, thus a correctly implemented server that does not
-   understand this element should ignore it [RFC4120].  The value of
-   this authorization element contains the DER [X690] encoding of the
-   following ASN.1 type:
-
-
-
-
-
-
-Zhu, et al.             Expires January 20, 2006                [Page 3]
-
-Internet-Draft             Enctype Negotiation                 July 2005
-
-
-           EtypeList ::= SEQUENCE OF Int32
-              -- Specifies the enctypes supported by the client.
-              -- This enctype list is in decreasing preference order
-              -- (favorite choice first).
-              -- Int32 is defined in [RFC4120].
-
-   If the EtypeList is present and the server prefers an enctype from
-   the client's enctype list over that of the AP-REQ authenticator
-   subkey (if that is present) or the service ticket session key, the
-   server MUST create a subkey using that enctype.  This negotiated
-   subkey is sent in the subkey field of AP-REP message and it is then
-   used as the protocol key or base key [RFC3961] for subsequent
-   communication.
-
-   This negotiation extension SHOULD NOT be used when the client does
-   not expect the subkey in the AP-REP message from the server.
-
-   A note on key generation: The KDC has a strong Pseudo-Random Number
-   Generator (PRNG), as such the client can take advantage of the
-   randomness provided by the KDC by reusing the KDC key data when
-   generating keys.  Implementations SHOULD use the service ticket
-   session key value as a source of additional entropy when generating
-   the negotiated subkey.  If the AP-REQ authenticator subkey is
-   present, it MAY also be used as a source of entropy.
-
-   The server MAY ignore the preference order indicated by the client.
-   The policy by which the client or the server chooses an enctype
-   (i.e., how the preference order for the supported enctypes is
-   selected) is a local matter.
-
-4.  Security Considerations
-
-   The client's enctype list and the server's reply enctype are part of
-   encrypted data, thus the security considerations are the same as
-   those of the Kerberos encrypted data.
-
-   Both the EtypeList and the server's sub-session key are protected by
-   the session key or sub-session key used for the AP-REQ, and as a
-   result, if a key for a stronger enctype is negotiated underneath a
-   key for a weaker enctype, an attacker capable of breaking the weaker
-   enctype can also discover the key for the stronger enctype.  The
-   advantage of this extension is to minimize the amount of cipher text
-   encrypted under a weak enctype to which an attacker has access.
-
-5.  Acknowledgements
-
-   The authors would like to thank the following individuals for their
-   comments and suggestions: Luke Howard, Tom Yu, Love Hornquist
-
-
-
-Zhu, et al.             Expires January 20, 2006                [Page 4]
-
-Internet-Draft             Enctype Negotiation                 July 2005
-
-
-   Astrand, Sam Harman, Ken Raeburn and Martin Rex.
-
-6.  IANA Considerations
-
-   No IANA actions are required for this document.
-
-7.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding Rules 
-              (BER), Canonical Encoding Rules (CER) and Distinguished 
-              Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 
-              ISO/IEC International Standard 8825-1:1998.
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Paul Leach
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: paulle@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires January 20, 2006                [Page 5]
-
-Internet-Draft             Enctype Negotiation                 July 2005
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires January 20, 2006                [Page 6]
-
-Internet-Draft             Enctype Negotiation                 July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.             Expires January 20, 2006                [Page 7]
-
-
diff --git a/doc/standardisation/draft-zhu-negoex-01.txt b/doc/standardisation/draft-zhu-negoex-01.txt
deleted file mode 100644
index 21620a896..000000000
--- a/doc/standardisation/draft-zhu-negoex-01.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-

-

-NETWORK WORKING GROUP                                             L. Zhu

-Internet-Draft                                                 K. Damour

-Updates: 4178 (if approved)                                 D. McPherson

-Intended status: Informational                     Microsoft Corporation

-Expires: January 15, 2009                                  July 14, 2008

-

-

-          The Extended GSS-API Negotiation Mechanism (NEGOEX)

-                          draft-zhu-negoex-01

-

-Status of this Memo

-

-   By submitting this Internet-Draft, each author represents that any

-   applicable patent or other IPR claims of which he or she is aware

-   have been or will be disclosed, and any of which he or she becomes

-   aware will be disclosed, in accordance with Section 6 of BCP 79.

-

-   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."

-

-   The list of current Internet-Drafts can be accessed at

-   http://www.ietf.org/ietf/1id-abstracts.txt.

-

-   The list of Internet-Draft Shadow Directories can be accessed at

-   http://www.ietf.org/shadow.html.

-

-   This Internet-Draft will expire on January 15, 2009.

-

-Abstract

-

-   This document defines the Extended Generic Security Service

-   Application Program Interface (GSS-API) Negotiation Mechanism

-   (NegoEx).  NegoEx is a pseudo-security mechanism that logically

-   extends the SPNEGO protocol as defined in RFC4178.

-

-   The NegoEx protocol itself is a security mechanism negotiated by

-   SPNEGO.  When selected as the common mechanism, NegoEx OPTIONALLY

-   adds a pair of meta-data messages for each negotiated security

-   mechanism.  The meta-data exchange allows security mechanisms to

-   exchange auxiliary information such as trust configurations, thus

-   NegoEx provides additional flexibility than just exchanging object

-

-

-

-Zhu, et al.             Expires January 15, 2009                [Page 1]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-   identifiers in SPNEGO.

-

-   NegoEx preserves the optimistic token semantics of SPNEGO and applies

-   that recursively.  Consequently a context establishment mechanism

-   token can be included in the initial NegoEx message, and NegoEx does

-   not require an extra round-trip when the initiator's optimistic token

-   is accepted by the target.

-

-   Similar to SPNEGO, NegoEx defines a few new GSS-API extensions that a

-   security mechanism MUST support in order to be negotiated by NegoEx.

-   This document defines these GSS-API extensions.

-

-   Unlike SPNEGO however, NegoEx defines its own way for signing the

-   protocol messages in order to protect the protocol negotiation.  The

-   NegoEx message signing or verification can occur before the security

-   context for the negotiated real security mechanism is fully

-   established.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Zhu, et al.             Expires January 15, 2009                [Page 2]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-Table of Contents

-

-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

-   2.  Requirements Terminology . . . . . . . . . . . . . . . . . . .  6

-   3.  Presentation Language and Primitive Data Types . . . . . . . .  6

-     3.1.  Basic Block Size . . . . . . . . . . . . . . . . . . . . .  7

-     3.2.  Miscellaneous  . . . . . . . . . . . . . . . . . . . . . .  7

-     3.3.  Constants  . . . . . . . . . . . . . . . . . . . . . . . .  7

-     3.4.  Numbers  . . . . . . . . . . . . . . . . . . . . . . . . .  7

-     3.5.  Enum Types . . . . . . . . . . . . . . . . . . . . . . . .  7

-     3.6.  Typedef Declarations . . . . . . . . . . . . . . . . . . .  8

-     3.7.  Array Types  . . . . . . . . . . . . . . . . . . . . . . .  8

-     3.8.  Vector Types . . . . . . . . . . . . . . . . . . . . . . .  8

-     3.9.  Constructed Types  . . . . . . . . . . . . . . . . . . . .  9

-   4.  Cryptographic Computations . . . . . . . . . . . . . . . . . . 10

-   5.  The NegoEx Protocol  . . . . . . . . . . . . . . . . . . . . . 11

-     5.1.  Generation of the Initiator Initial Token  . . . . . . . . 11

-     5.2.  Receipt of the Initial Initiator Token and Generation

-           of the Initial Acceptor Response . . . . . . . . . . . . . 13

-     5.3.  Receipt of the Acceptor Initial Response and

-           Completion of Authentication after the Negotiation

-           Phrase . . . . . . . . . . . . . . . . . . . . . . . . . . 14

-     5.4.  Finalizing Negotiation . . . . . . . . . . . . . . . . . . 15

-     5.5.  High-level NegoEx Message Flow . . . . . . . . . . . . . . 15

-   6.  Supporting GSS-API Extensions  . . . . . . . . . . . . . . . . 16

-     6.1.  GSS_Query_meta_data  . . . . . . . . . . . . . . . . . . . 16

-     6.2.  GSS_Exchange_meta_data . . . . . . . . . . . . . . . . . . 16

-     6.3.  GSS_Query_mechanism_info . . . . . . . . . . . . . . . . . 16

-     6.4.  GSS_Query_context_attr . . . . . . . . . . . . . . . . . . 16

-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16

-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17

-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17

-   10. Normative References . . . . . . . . . . . . . . . . . . . . . 17

-   Appendix A.  Protocol Data Structures and Constant Values  . . . . 17

-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21

-   Intellectual Property and Copyright Statements . . . . . . . . . . 22

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Zhu, et al.             Expires January 15, 2009                [Page 3]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-1.  Introduction

-

-   If more than one GSS-API mechanism is shared between the initator and

-   the acceptor, the Simple and Protected (GSS-API) Negotiation

-   Mechanism (SPNEGO) as defined in [RFC4178] can be deployed to choose

-   a mutually preferred one.  This pseudo mechanism does well in the

-   most basic scenarios but suffers from a couple of drawbacks, notably:

-

-   o  First, the SPNEGO negotiation model is inefficient when

-      negotiating based on mechanism specific configuration information.

-      SPNEGO negotiation is based on exchanging object identifiers only,

-      and it does not allow exchange of auxiliary information in any

-      other from.  This is inefficient and often impractical in that one

-      object identifier effectively conveys only one bit of information.

-

-   o  Secondly, the SPNEGO negotiation model is inadequate when the

-      choice cannot be made by the acceptor in the initial response.  In

-      SPNEGO, the negotiation information is sent one-way from the

-      initiator for the acceptor to make a choice, and the acceptor must

-      choose one when it makes the initial response.  This negotiation

-      model is counter intuitive.  The selection of a security mechanism

-      is typically the result of selecting one type of credentials from

-      the available set, and the initiator typically does not wish to

-      reveal credentials information often associated with user

-      identities.  In practice, in order to operate in this model, the

-      Kerberos GSS-API mechanism [RFC4121] must acquire the context

-      establishment token in the initial call to GSS_Init_sec_context().

-      If the initiator fails to acquire the initial Kerberos GSS-API

-      context token, it must not offer Kerberos; otherwise the SPNEGO

-      context negotiation will fail without being able to select the

-      next available mechanism that could work.  Obtaining the initial

-      Kerberos GSS-API context token may require multiple round-trips of

-      network calls and the cost of the operation can be substantial.

-      It is suboptimal when multiple GSS-API mechanisms have to add the

-      extra cost that would not exist if the negotiated security

-      mechanism were selected based on configuration.

-

-   The Extended Generic Security Service Application Program Interface

-   (GSS-API) Negotiation Mechanism (NegoEx) is defined to address these

-   concerns.  NegoEx is a pseudo security mechanism that is negotiated

-   by SPNEGO, and when negotiated, it can recursively negotiate real

-   security mechanisms.

-

-   Any security mechanism negotiated by NegoEx MUST support integrity

-   protection.

-

-   The basic form of NegoEx works as follows:

-

-

-

-

-Zhu, et al.             Expires January 15, 2009                [Page 4]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-   1.  The initiator proposes a list of mechanisms in decreasing

-       preference order.  For each of these mechanism, NegoEx

-       OPTIOINALLY includes a mechanism specific meta-data token.  GSS-

-       API extensions are defined later in this document for NegoEx to

-       query the meta-data token for inclusion in the NegoEx message.

-

-   2.  The acceptor then passes the meta-data token from the initiator

-       to the intended security mechanism.  A meta-data token for a

-       security mechanism not supported on the acceptor side is ignored.

-       New GSS-API extensions are defined later in this document for a

-       security mechanism to consume the meta-data token.  When

-       processing the received meta-data tokens, a security mechanism

-       that reports a failure is removed from the set of mutually

-       supported mechanisms.  The acceptor then responds with the list

-       of mutually supported mechanisms in decreasing preference order.

-       For each of these mechanism, NegoEx again OPTIOINALLY supplies a

-       mechanism specific meta-data token in the response.  These meta-

-       data tokens are returned to NegoEx via new GSS-API extensions as

-       described in the initial step.

-

-   3.  The initiator then passes the meta-data tokens to the intended

-       security mechanisms by invoking the new GSS-API extensions.  When

-       processing the received meta-data token, a security mechanism

-       that reports a failure is removed from the set of mutually

-       supported mechanisms for this negotiation context.  The initiator

-       then selects one from the set of mutually-supported mechanisms.

-       If more than one security mechanism is available, unless

-       otherwise specified, the preferred one in the acceptor's

-       preference order SHOULD be selected.  Once the common security

-       mechanism is identified, the security mechanism may also

-       negotiate mechanism-specific options during its context

-       establishments.  This will be inside the mechanism tokens, and

-       invisible to the NegoEx protocol.

-

-   4.  The selected security mechanism provides keying materials to

-       NegoEx, and NegoEx then signs and verifies the negotiation NegoEx

-       messages to protect the negotiation.

-

-   5.  The initiator and the acceptor proceed to exchange tokens until

-       the GSS-API context for selected security mechanism is

-       established.  Once the security context is established, the per-

-       message tokens are generated and verified in accordance with the

-       selected security mechanism.

-

-   NegoEx does not work outside of SPNEGO.  When negotiated by SPNEGO,

-   NegoEx uses the concepts developed in the GSS-API specification

-   [RFC2743].  The negotiation data is encapsulated in context-level

-   tokens.  Therefore, callers of the GSS-API do not need to be aware of

-

-

-

-Zhu, et al.             Expires January 15, 2009                [Page 5]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-   the existence of the negotiation tokens but only of the SPENGO

-   pseudo-security mechanism.

-

-   In its basic form NegoEx requires at least one extra round-trip.

-   Network connection setup is a critical performance characteristic of

-   any network infrastructure and extra round trips over WAN links,

-   packet radio networks, etc. really make a difference.  In order to

-   avoid such an extra round trip the initial security token of the

-   preferred mechanism for the initiator may be embedded in the initial

-   NegoEx token.  The optimistic mechanism token may be accompanied by

-   the meta-data tokens and the optimistic mechanism token MUST be that

-   of the first mechanism in the list of the mechanisms proposed by the

-   initiator.  The NegoEx message that contains signatures for

-   protecting the NegoEx negotiation can also be included along with the

-   mechanism token.  If the target preferred mechanism matches the

-   initiator's preferred mechanism, and when the NegoEx negotiation

-   protection messages are included along with the mechanism token, no

-   additional round trips are incurred by using the NegoEx protocol with

-   SPNEGO.

-

-   NegoEx does not update the ASN.1 structures of SPNEGO in that a large

-   deployment of SPNEGO does not have the ASN.1 extensibility marker in

-   the message definition.  There is no change to the SPNEGO messages.

-

-   NegoEx does not use ASN.1 encoding and it uses simple C structures

-   encoded in little endian for all its messages.

-

-   The rest of the document is organized as follows: Section 3 defines

-   the encoding of NegoEx data structures and all the primitive data

-   types.  Section 4 describes the cryptographic framework required by

-   the NegoEx for protecting the NegoEx negotiation.  Section 5 defines

-   the NegoEx messages and the NegoEx protocol.  Section 6 defines the

-   new GSS-API extensions that a security mechanism MUST support in

-   order to be negotiated by NegoEx.  These then are followed by the

-   security considerations section.  Lastly Appendix A contains all the

-   protocol constructs and constants.

-

-

-2.  Requirements Terminology

-

-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

-   document are to be interpreted as described in [RFC2119].

-

-

-3.  Presentation Language and Primitive Data Types

-

-   The following very basic and somewhat casually defined presentation

-

-

-

-Zhu, et al.             Expires January 15, 2009                [Page 6]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-   syntax will be used in all NegoEx messages.  Although it resembles

-   the programming language "C" in its syntax, it would be risky to draw

-   too many parallels.  The purpose of this presentation language is to

-   document NegoEx only; it has no general application beyond that

-   particular goal.

-

-   This section also defines all the primitive data types.  The

-   semantics of the data types is explained in the next section.

-

-3.1.  Basic Block Size

-

-   The representation of all data items is explicitly specified.  The

-   basic data block size is one octet.  Multiple octet data items are

-   concatenations of octets, from left to right, from top to bottom

-   Unless otherwise specific a multi-octet numeric is in little endian

-   order with the least significant octet first.

-

-3.2.  Miscellaneous

-

-   Comments start with "//"' and continue until the end of the line.

-

-3.3.  Constants

-

-   Constants are denoted using "#define" followed by the symbolic name

-   and then the constant value.

-

-3.4.  Numbers

-

-   UCHAR is the data type for a one-octet number.

-

-   ULONG is the data type for a 4-octet number encoded in little enidan.

-

-   USHORT is the data type for a 2-octet number encoded in little

-   endian.

-

-   ULONG64 is the data type for a 8-octet number encoded in little

-   endian.

-

-   GUID is the data type for a 16-octet number encoded in little endian.

-

-3.5.  Enum Types

-

-   An enum type is the data type for a number with a small number of

-   permissible values.  An instance of an enum type is a 4-octet number

-   encoded in little endian.

-

-   The definition of an enum type follows the simple "C" convention.

-

-

-

-

-Zhu, et al.             Expires January 15, 2009                [Page 7]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-   MESSAGE_TYPE is an enum type defined as follows:

-

-       enum

-       {

-           MESSAGE_TYPE_INITIATOR_NEGO = 0,

-           MESSAGE_TYPE_ACCEPTOR_NEGO,

-           MESSAGE_TYPE_INITIATOR_META_DATA,

-           MESSAGE_TYPE_ACCEPTOR_META_DATA,

-           MESSAGE_TYPE_CHALLENGE,

-               // an exchange message from the acceptor

-           MESSAGE_TYPE_AP_REQUEST,

-               // an exchange message from the initiator

-           MESSAGE_TYPE_VERIFY,

-           MESSAGE_TYPE_ALERT,

-       } MESSAGE_TYPE;

-

-   MESSAGE_TYPE_INITIATOR_NEGO has the value 0, and MESSAGE_TYPE_ALERT

-   has the value 7.

-

-3.6.  Typedef Declarations

-

-   A typedef creates a synonym for the type.  This is used to create

-   more meaningful names for existing types.

-

-   The following two type synonyms are defined.

-

-   typedef GUID AUTH_SCHEME;

-   typedef GUID CONVERSATION_ID;

-

-3.7.  Array Types

-

-   Arrays are a data structure which holds multiple variables of the

-   same data type consecutively and the number of elements is fixed.  An

-   array is declared using "C" convention.  For example, the following

-   defines an array of 32 octets.

-

-   UCHAR Random[32];

-

-3.8.  Vector Types

-

-   Vectors are a data structure which holds multiple variables of the

-   same data type consecutively and the number of elements is not fixed.

-   A vector contains a fixed length header followed by a variable length

-   payload.  The header of a vector structure contains the count of

-   elements and the offset to the payload.  In this document all the

-   offset fields start from the beginning of the containing NegoEx

-   message.  The size of each element is specified by the vector type

-   definition.

-

-

-

-Zhu, et al.             Expires January 15, 2009                [Page 8]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-   The following vector types are defined.

-

-       struct

-       {

-           ULONG ByteArrayOffset; // each element contains an octet/byte

-           ULONG ByteArrayLength;

-       } BYTE_VECTOR;

-

-   BYTE_VECTOR encapsulates a variable length array of octets (or bytes)

-   that are stored consecutively.  Each element in is a byte (8 bits).

-

-       struct

-       {

-           ULONG AuthSchemeArrayOffset;

-                // each element contains an AUTH_SCHEME

-           USHORT AuthSchemeCount;

-       } AUTH_SCHEME_VECTOR;

-

-   AUTH_SCHEME_VECTOR encapsulates a variable length array of

-   AUTH_SCHEMEs that are stored consecutively.  Each element is a

-   structure of the type AUTH_SCHEME.

-

-       struct

-       {

-           ULONG ExtensionArrayOffset;

-               // each element contains an EXTENSION

-           USHORT ExtensionCount;

-       } EXTENSION_VECTOR;

-

-   EXTENSION_VECTOR encapsulates a variable length array of EXTENSIONs

-   that are stored consecutively.  Each element is a structure of the

-   type EXTENSION.

-

-3.9.  Constructed Types

-

-   Structure types may be constructed from primitive types for

-   convenience.  Each specification declares a new, unique type.  The

-   syntax for definition is much like that of C.

-

-         struct {

-             T1 f1;

-             T2 f2;

-             ...

-             Tn fn;

-         } T;

-

-

-   Structure definitions may be embedded.

-

-

-

-Zhu, et al.             Expires January 15, 2009                [Page 9]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-   The following types are defined as constructed types:

-

-       struct

-       {

-           ULONG ExtensionType; // negative extensions are critical

-           BYTE_VECTOR ExtensionValue;

-       } EXTENSION;

-

-   An extension has two fields.  The ExtensionType field indicates how

-   the extension data should be interpreted.  The ExtensionValue field

-   contains the extension data.

-

-       //

-       // schemes defined for the checksum in the VERIFY message

-       //

-

-       struct

-       {

-           ULONG cbHeaderLength;

-           ULONG ChecksumScheme;

-           ULONG ChecksumType; // in the case of RFC3961 scheme, this is

-             // the RFC3961 checksum type

-           BYTE_VECTOR ChecksumValue;

-       } CHECKSUM;

-

-   The CHECKSUM structure contains 4 fields.  The cbHeaderLength length

-   contains the length of the structure defintion in octets, and this

-   field has a value of 20.

-

-   The ChecksumScheme field describes how checksum is computed and

-   verified.  Currently only one value is defined.

-

-   #define CHECKSUM_SCHEME_RFC3961 1

-

-   When the value of the ChecksumScheme field is 1

-   (CHECKSUM_SCHEME_RFC3961), the ChecksumValue field contains a

-   sequence of octets computed according to [RFC3961] and the

-   ChecksumType field contains the checksum type value defined according

-   to [RFC3961].

-

-

-4.  Cryptographic Computations

-

-   The message signing and verification in NegoEx is based on [RFC3961].

-   [RFC3961] is used here as a generic framework and this application is

-   not Kerberos specific.

-

-   A security mechanism MUST support [RFC3961] in order to be negotiated

-

-

-

-Zhu, et al.             Expires January 15, 2009               [Page 10]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-   by NegoEx.

-

-

-5.  The NegoEx Protocol

-

-   This section describes the NegoEx protocol and it defines NegoEx

-   messages in the order that the messages can appear on the wire.  The

-   enum type MESSAGE_TYPE defined in Section 3.5 lists all NegoEx

-   message types.  A GSS-API context token for NegoEx consists of one or

-   more NegoEx messages.  If there are more than one NegoEx message,

-   these messages are concatenated together.  The smallest data unit for

-   NegoEx to compute the checksum for negotiation protection is a NegoEx

-   message.  Note that NegoEx is not a GSS-API mechanism itself and the

-   initial NegoEx context establishment token does not follow the

-   mechanism-independent token format defined in Section 3.1 of

-   [RFC2743].

-

-   A security mechanism negotiated by NegoEx is identified by a unique

-   identifier of the data type AUTH_SCHEME defined in Section 3.5.  The

-   value of the security mechanism is returned to NegoEx via the

-   GSS_Query_mechanism_info() GSS-API extension as defined in Section 6.

-

-   The object identifier of the NegoEx within SPNEGO is iso(1)

-   identified-organization(3) dod(6) internet(1) private(4)

-   enterprise(1) microsoft (311) security(2) mechanisms(2) negoex(30).

-   Note that NegoEx does not work outside of SPNEGO and it is not GSS-

-   API mechanism.

-

-5.1.  Generation of the Initiator Initial Token

-

-   The GSS-API initiator makes the first call to GSS_Init_sec_context()

-   with no input token, and the output token starts as a NEGO_MESSAGE

-   message with the MESSAGE_TYPE_INITIATOR_NEGO message type.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Zhu, et al.             Expires January 15, 2009               [Page 11]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-       struct

-       {

-           ULONG64 Signature; // contains MESSAGE_SIGNATURE

-           MESSAGE_TYPE MessageType;

-           ULONG SequenceNum; // the message sequence number of this,

-                  // conversation, starting with 0 and sequentially

-                  // incremented

-           ULONG cbHeaderLength; // the header length of this message,

-              // including the message specific header, excluding the

-              // payload

-           ULONG cbMessageLength; // the length of this message

-           CONVERSATION_ID ConversationId;

-       } MESSAGE_HEADER;

-

-       struct

-       {

-           MESSAGE_HEADER Header;

-                    // MESSAGE_TYPE_INITIATOR_NEGO for the initiator,

-                    // MESSAGE_TYPE_ACCEPTOR_NEGO for the acceptor

-           UCHAR Random[32];

-           ULONG64 ProtocolVersion;

-                   // version of the protocol, this contains 0

-           AUTH_SCHEME_VECTOR AuthSchemes;

-           EXTENSION_VECTOR Extensions;

-       } NEGO_MESSAGE;

-

-   The initiator randomly generates a ConversationID and fills the

-   common header.  The ConversationID in subsequent NegoEx messages MUST

-   remain the same.  The initiator also fills the Random field using a

-   secure random number generator.  The initiator fills the AuthSchemes

-   with available security mechanisms supported by the initiator in

-   decreasing preference order.

-

-   The extensions field contains NegoEx extensions for future

-   extensibility.  There is no extension defined in this document.  All

-   negative extension types (the highest bit is set to 1) are critical.

-   If the receiver does not understand a critical extension, the

-   authentication attempt must be rejected.

-

-   The initiator can OPTIONALLY include a meta-data token, one for each

-   available security mechanism.

-

-   A meta-data token is returned to NegoEx for a security mechanism

-   using GSS_Query_meta_data() extension as defined in Section 6.  A

-   meta-data token is encapsulated in an EXCHANGE message with the

-   message type MESSAGE_TYPE_INITIATOR_META_DATA.

-

-

-

-

-

-Zhu, et al.             Expires January 15, 2009               [Page 12]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-       struct

-       {

-           MESSAGE_HEADER Header;

-                // MESSAGE_TYPE_CHALLENGE for the acceptor,

-                // or MESSAGE_TYPE_AP_REQUEST for the initiator

-               // MESSAGE_TYPE_INITIATOR_META_DATA for

-               // the initiator metadata

-               // MESSAGE_TYPE_ACCEPTOR_META_DATA for

-               // the acceptor metadata

-           AUTH_SCHEME AuthScheme;

-           BYTE_VECTOR Exchange;

-               // contains the opaque handshake message for the

-               // authentication scheme

-       } EXCHANGE_MESSAGE;

-

-   The AuthScheme field signifies the security mechanism for which the

-   EXCHANGE message is targeted.  If a security mechanism fails to

-   produce the metadata token, it should be removed from the list of

-   supported security mechanism for this negotiation context.

-

-   If there are more than one exchange messages, the order in which the

-   exchange message is included bears no significance.  In other words,

-   the exchange messages are in an unordered set.  The NEGO_MESSAGE MAY

-   be followed by a set of MESSAGE_TYPE_INITIATOR_META_DATA messages as

-   described above, in which case all the NegoEx messages concatenated

-   are returned as a single input token.

-

-   The first mechanism in the initiator proposed list can OPTIONALLY

-   include its initial context context in an AP_REQUEST message.

-

-   Both an AP_REQUSET(short for MESSAGE_TYPE_AP_REQUEST) message and a

-   INITIATOR_META_DATA(short for MESSAGE_TYPE_INITIATOR_META_DATA)

-   message are instances of the EXCHANGE_MESSAGE structure with

-   different message type values.  An AP_REQUEST message contains the

-   type MESSAGE_TYPE_AP_REQUEST while an INITIATOR_META_DATA message

-   contains the type MESSAGE_TYPE_INITIATOR_META_DATA.

-

-5.2.  Receipt of the Initial Initiator Token and Generation of the

-      Initial Acceptor Response

-

-   Upon receipt of the NEGO_MESSAGE from the initiator, the acceptor

-   verifies the NEGO_MESSAGE to make sure it is well-formed.  The

-   acceptor then computes the list of authentication schemes that are

-   mutually supported by examining the set of security mechanisms

-   proposed by the initiator and the meta-data tokens from the

-   initiator.  The meta-data tokens are passed to the security mechanism

-   via GSS_Exchange_meta_data() as defined in Section 6.

-

-

-

-

-Zhu, et al.             Expires January 15, 2009               [Page 13]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-   The acceptor MUST examine the NegoEx extensions in the NEGO_MESSAGE.

-   If there is an unknown critical extension, the authentication must be

-   rejected.

-

-   The acceptor's response starts as a NEGO_MESSAGE but with the

-   MESSAGE_TYPE_ACCEPTOR_NEGO.  The AuthSchemes field contains the list

-   of mutually supported security mechanism in decreasing preference

-   order of the acceptor.  The acceptor does not need to honor the

-   preference order proposed by the initiator when computing its

-   preference list.

-

-   The acceptor can OPTIONALLY include a meta-data token, one for each

-   available security mechanism.

-

-   A meta-data token is returned to NegoEx for a security mechanism

-   using GSS_Query_meta_data() extension as defined in Section 6.  A

-   meta-data token is encapsulated in an EXCHANGE message with the

-   message type MESSAGE_TYPE_ACCEPTOR_META_DATA.  For a given security

-   mechanism if a meta-token is received from the initiator,

-   GSS_Query_meta_data() MUST be invoked on the acceptor side for that

-   security mechanism, and the output meta-data token, if present, MUST

-   be included in the NegoEx reply.

-

-5.3.  Receipt of the Acceptor Initial Response and Completion of

-      Authentication after the Negotiation Phrase

-

-   Upon receipt of the initial response from the acceptor, the initial

-   verifies the NEGO_MESSAGE to make sure it is well-formed.  The

-   initiator then computes the list of authentication schemes that are

-   mutually supported by examining the set of security mechanisms

-   returned by the acceptor and the meta-data tokens from the acceptor

-   The meta-data tokens are passed to the security mechanism via

-   GSS_Exchange_meta_data() as defined in Section 6.

-

-   The initiator MUST examine the NegoEx extensions in the NEGO_MESSAGE.

-   If there is an unknown critical extension, the authentication must be

-   rejected.

-

-   After the initial exchange of NEGO_MESSAGE messages, the initiator

-   MUST choose the negotiated security mechanism.  The negotiated

-   security mechanism cannot be changed once it is selected.

-

-   The initiator and the acceptor can then proceed to exchange handshake

-   messages as determined by the negotiated security mechanism until its

-   authentication context is established.  The context tokens of the

-   negotiated security mechanism are encapsulated in an

-   EXCHANGE_MESSAGE.  If the context token is from the initiator, the

-   EXCHANGE_MESSAGE message has the message type

-

-

-

-Zhu, et al.             Expires January 15, 2009               [Page 14]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-   MESSAGE_TYPE_AP_REQUEST; otherwise, the message type is

-   MESSAGE_TYPE_CHALLENGE.

-

-5.4.  Finalizing Negotiation

-

-   Whenever there is a shared key established returned by

-   GSS_Query_context_attr(NEGOEX_SESSION_KEYS) as defined in Section 6,,

-   a VERIFY message is produced and included in the output token.  The

-   returned protocol key is used as the base key in the parlance of

-   RFC3961 to sign all the NegoEx messages in the negotiation context.

-

-   A VERIFY message is a VERIFY_MESSAGE structure.  The AuthScheme field

-   signifies from which security mechanism the protocol key was

-   obtained.  The checksum is computed based on RFC3961 and the key

-   usage number is 23 for the message is signed by the initiator, 25

-   otherwise.  The checksum is performed over all the previous NegoEx

-   messages in the context negotiation.

-

-       struct

-       {

-           MESSAGE_HEADER Header; // MESSAGE_TYPE_VERIFY

-           AUTH_SCHEME AuthScheme;

-           CHECKSUM Checksum;

-                // contains the checksum of all the previously

-                // exchanged messages in the order they were sent.

-       } VERIFY_MESSAGE;

-

-   Note that the VERIFY_MESSAGE message can be included before the

-   security context for the negotiated security mechanism is fully

-   established.

-

-5.5.  High-level NegoEx Message Flow

-

-   The following text art summarizes the protocol message flow:

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Zhu, et al.             Expires January 15, 2009               [Page 15]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-  INITIATOR_NEGO

-  *INITIATOR_META_DATA

-  *AP_REQUEST

-                                    --------->

-                                                           ACCEPTOR_NEGO

-                                                    ACCEPTOR_META_DATA*+

-                                    ---------                CHALLENGE*

-

-                                        .

-                                        .

-  *AP_REQUEST

-  VERIFY                            --------->

-                                                              CHALLENGE*

-                                    --------                     VERIFY

-         * Indicates optional or situation-dependent messages that are

-           not always sent.

-         + Indicates there can be more than one instance.

-

-

-6.  Supporting GSS-API Extensions

-

-   This section defined all the required GSS-API extensions required by

-   NegoEx.

-

-6.1.  GSS_Query_meta_data

-

-   TBD.

-

-6.2.  GSS_Exchange_meta_data

-

-   TBD.

-

-6.3.  GSS_Query_mechanism_info

-

-   TBD.

-

-6.4.  GSS_Query_context_attr

-

-   TBD.

-

-

-7.  Security Considerations

-

-   TBD.

-

-

-

-

-

-

-

-Zhu, et al.             Expires January 15, 2009               [Page 16]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-8.  Acknowledgements

-

-   TBD.

-

-

-9.  IANA Considerations

-

-   There is no action required for IANA.

-

-

-10.  Normative References

-

-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

-              Requirement Levels", BCP 14, RFC 2119, March 1997.

-

-   [RFC2743]  Linn, J., "Generic Security Service Application Program

-              Interface Version 2, Update 1", RFC 2743, January 2000.

-

-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for

-              Kerberos 5", RFC 3961, February 2005.

-

-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The

-              Kerberos Network Authentication Service (V5)", RFC 4120,

-              July 2005.

-

-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos

-              Version 5 Generic Security Service Application Program

-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,

-              July 2005.

-

-   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The

-              Simple and Protected Generic Security Service Application

-              Program Interface (GSS-API) Negotiation Mechanism",

-              RFC 4178, October 2005.

-

-

-Appendix A.  Protocol Data Structures and Constant Values

-

-   This section complies all the protocol data structures and constant

-   values.

-

-       #define MESSAGE_SIGNATURE    0x535458454f47454ei64

-           // "NEGOEXTS"

-

-       struct

-       {

-           ULONG ByteArrayOffset; // each element contains a byte

-           ULONG ByteArrayLength;

-

-

-

-Zhu, et al.             Expires January 15, 2009               [Page 17]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-       } BYTE_VECTOR;

-

-       struct

-       {

-           ULONG AuthSchemeArrayOffset;

-               // each element contains an AUTH_SCHEME

-           USHORT AuthSchemeCount;

-       } AUTH_SCHEME_VECTOR;

-

-       struct

-       {

-           ULONG ExtensionArrayOffset;

-               // each element contains an EXTENSION

-           USHORT ExtensionCount;

-       } EXTENSION_VECTOR;

-

-       struct

-       {

-           ULONG ExtensionType; // negative extensions are critical

-           BYTE_VECTOR ExtensionValue;

-       } EXTENSION;

-

-       //

-       // schemes defined for the checksum in the VERIFY message

-       //

-

-       #define CHECKSUM_SCHEME_RFC3961  1

-

-       struct

-       {

-           ULONG cbHeaderLength;

-           ULONG ChecksumScheme;

-           ULONG ChecksumType; // in the case of RFC3961 scheme, this is

-              // the RFC3961 checksum type

-           BYTE_VECTOR ChecksumValue;

-       } CHECKSUM;

-

-       typedef GUID AUTH_SCHEME;

-       typedef GUID CONVERSATION_ID;

-

-       enum

-       {

-           MESSAGE_TYPE_INITIATOR_NEGO = 0,

-           MESSAGE_TYPE_ACCEPTOR_NEGO,

-           MESSAGE_TYPE_INITIATOR_META_DATA,

-           MESSAGE_TYPE_ACCEPTOR_META_DATA,

-           MESSAGE_TYPE_CHALLENGE,

-               // an exchange message from the acceptor

-

-

-

-Zhu, et al.             Expires January 15, 2009               [Page 18]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-           MESSAGE_TYPE_AP_REQUEST,

-               // an exchange message from the initiator

-           MESSAGE_TYPE_VERIFY,

-           MESSAGE_TYPE_ALERT,

-       } MESSAGE_TYPE;

-

-       struct

-       {

-           ULONG64 Signature; // contains MESSAGE_SIGNATURE

-           MESSAGE_TYPE MessageType;

-           ULONG SequenceNum; // the message sequence number of this,

-                  // conversation, starting with 0 and sequentially

-                  // incremented

-           ULONG cbHeaderLength; // the header length of this message,

-              // including the message specific header, excluding the

-              // payload

-           ULONG cbMessageLength; // the length of this message

-           CONVERSATION_ID ConversationId;

-       } MESSAGE_HEADER;

-

-       struct

-       {

-           MESSAGE_HEADER Header;

-                    // MESSAGE_TYPE_INITIATOR_NEGO for the initiator,

-                    // MESSAGE_TYPE_ACCEPTOR_NEGO for the acceptor

-           UCHAR Random[32];

-           ULONG64 ProtocolVersion;

-                   // version of the protocol, this contains 0

-           AUTH_SCHEME_VECTOR AuthSchemes;

-           EXTENSION_VECTOR Extensions;

-       } NEGO_MESSAGE;

-

-       struct

-       {

-           MESSAGE_HEADER Header;

-                // MESSAGE_TYPE_CHALLENGE for the acceptor,

-                // or MESSAGE_TYPE_AP_REQUEST for the initiator

-               // MESSAGE_TYPE_INITiATOR_META_DATA for

-               // the initiator metadata

-               // MESSAGE_TYPE_ACCEPTOR_META_DATA for

-               // the acceptor metadata

-           AUTH_SCHEME AuthScheme;

-           BYTE_VECTOR Exchange;

-               // contains the opaque handshake message for the

-               // authentication scheme

-       } EXCHANGE_MESSAGE;

-

-       struct

-

-

-

-Zhu, et al.             Expires January 15, 2009               [Page 19]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-       {

-           MESSAGE_HEADER Header; // MESSAGE_TYPE_VERIFY

-           AUTH_SCHEME AuthScheme;

-           CHECKSUM Checksum;

-                // contains the checksum of all the previously

-                // exchanged messages in the order they were sent.

-       } VERIFY_MESSAGE;

-

-       struct

-       {

-           ULONG AlertType;

-           BYTE_VECTOR AlertValue;

-       } ALERT;

-

-       //

-       // alert types

-       //

-

-       #define ALERT_TYPE_PULSE             1

-

-       //

-       // reason codes for the heartbeat message

-       //

-

-       #define ALERT_VERIFY_NO_KEY          1

-

-       struct

-       {

-           ULONG cbHeaderLength;

-           ULONG Reason;

-       } ALERT_PULSE;

-

-       struct

-       {

-           ULONG AlertArrayOffset; // the element is an ALERT

-           USHORT AlertCount; // contains the number of alerts

-       } ALERT_VECTOR;

-

-       struct

-       {

-           MESSAGE_HEADER Header;

-           AUTH_SCHEME AuthScheme;

-           ULONG ErrorCode; // an NTSTATUS code

-           ALERT_VECTOR Alerts;

-       } ALERT_MESSAGE;

-

-

-

-

-

-

-Zhu, et al.             Expires January 15, 2009               [Page 20]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-Authors' Addresses

-

-   Larry Zhu

-   Microsoft Corporation

-   One Microsoft Way

-   Redmond, WA  98052

-   US

-

-   Email: lzhu@microsoft.com

-

-

-   Kevin Damour

-   Microsoft Corporation

-   One Microsoft Way

-   Redmond, WA  98052

-   US

-

-   Email: kdamour@microsoft.com

-

-

-   Dave McPherson

-   Microsoft Corporation

-   One Microsoft Way

-   Redmond, WA  98052

-   US

-

-   Email: davemm@microsoft.com

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Zhu, et al.             Expires January 15, 2009               [Page 21]

-

-Internet-Draft                   NEGOEX                        July 2008

-

-

-Full Copyright Statement

-

-   Copyright (C) The IETF Trust (2008).

-

-   This document is subject to the rights, licenses and restrictions

-   contained in BCP 78, and except as set forth therein, the authors

-   retain all their rights.

-

-   This document and the information contained herein are provided on an

-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS

-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF

-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-Intellectual Property

-

-   The IETF takes no position regarding the validity or scope of any

-   Intellectual Property Rights or other rights that might be claimed to

-   pertain to the implementation or use of the technology described in

-   this document or the extent to which any license under such rights

-   might or might not be available; nor does it represent that it has

-   made any independent effort to identify any such rights.  Information

-   on the procedures with respect to rights in RFC documents can be

-   found in BCP 78 and BCP 79.

-

-   Copies of IPR disclosures made to the IETF Secretariat and any

-   assurances of licenses to be made available, or the result of an

-   attempt made to obtain a general license or permission for the use of

-   such proprietary rights by implementers or users of this

-   specification can be obtained from the IETF on-line IPR repository at

-   http://www.ietf.org/ipr.

-

-   The IETF invites any interested party to bring to its attention any

-   copyrights, patents or patent applications, or other proprietary

-   rights that may cover technology that may be required to implement

-   this standard.  Please address the information to the IETF at

-   ietf-ipr@ietf.org.

-

-

-

-

-

-

-

-

-

-

-

-Zhu, et al.             Expires January 15, 2009               [Page 22]

-

-

diff --git a/doc/standardisation/draft-zhu-pkinit-ecc-00.txt b/doc/standardisation/draft-zhu-pkinit-ecc-00.txt
deleted file mode 100644
index 94be6e2a6..000000000
--- a/doc/standardisation/draft-zhu-pkinit-ecc-00.txt
+++ /dev/null
@@ -1,610 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                             K. Jaganathan
-Expires: March 17, 2006                                        K. Lauter
-                                                   Microsoft Corporation
-                                                      September 13, 2005
-
-
-                         ECC Support for PKINIT
-                        draft-zhu-pkinit-ecc-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on March 17, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes the use of Elliptic Curve certificates,
-   Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman
-   (ECDH) key agreement within the framework of PKINIT - the Kerberos
-   Version 5 extension that provides for the use of public key
-   cryptography.
-
-
-
-
-
-Zhu, et al.              Expires March 17, 2006                 [Page 1]
-
-Internet-Draft           ECC Support for PKINIT           September 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Using Elliptic Curve Certificates and Elliptic Curve
-       Signature Schemes  . . . . . . . . . . . . . . . . . . . . . .  3
-   4.  Using ECDH Key Exchange  . . . . . . . . . . . . . . . . . . .  4
-   5.  Choosing the Domain Parameters and the Key Size  . . . . . . .  6
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
-     9.2.  Informative References . . . . . . . . . . . . . . . . . .  9
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
-   Intellectual Property and Copyright Statements . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires March 17, 2006                 [Page 2]
-
-Internet-Draft           ECC Support for PKINIT           September 2005
-
-
-1.  Introduction
-
-   Elliptic Curve Cryptography (ECC) is emerging as an attractive
-   public-key cryptosystem that provides security equivalent to
-   currently popular public-key mechanisms such as RSA and DSA with
-   smaller key sizes [LENSTRA] [NISTSP80057].
-
-   Currently [PKINIT] permits the use of ECC algorithms but it does not
-   specify how ECC parameters are chosen and how to derive the shared
-   key for key delivery using Elliptic Curve Diffie-Hellman (ECDH)
-   [IEEE1363].
-
-   This document describes how to use Elliptic Curve certificates,
-   Elliptic Curve signature schemes, and ECDH with [PKINIT].  However,
-   it should be noted that there is no syntactic or semantic change to
-   the existing [PKINIT] messages.  Both the client and the KDC
-   contribute one ECDH key pair using the key agrement protocol
-   described in this document.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  Using Elliptic Curve Certificates and Elliptic Curve Signature
-    Schemes
-
-   ECC certificates and signature schemes can be used in the
-   Cryptographic Message Syntax (CMS) [RFC3369] content type
-   'SignedData'.
-
-   X.509 certificates [RFC3280] containing ECC public keys or signed
-   using ECC signature schemes MUST comply with [RFC3279].
-
-   The elliptic curve domain parameters recommended in [X9.62],
-   [FIPS186-2], and [SECG] SHOULD be used.
-
-   The signatureAlgorithm field of the CMS data type SignerInfo can
-   contain one of the following ECC signature algorithm identifiers:
-
-      ecdsa-with-Sha1   [ECCPKALGS]
-      ecdsa-with-Sha256 [ECCPKALGS]
-      ecdsa-with-Sha384 [ECCPKALGS]
-      ecdsa-with-Sha512 [ECCPKALGS]
-
-
-
-
-Zhu, et al.              Expires March 17, 2006                 [Page 3]
-
-Internet-Draft           ECC Support for PKINIT           September 2005
-
-
-   The corresponding digestAlgorithm field contains one of the following
-   hash algorithm identifiers respectively:
-
-      id-sha1           [RFC3279]
-      id-sha256         [ECCPKALGS]
-      id-sha384         [ECCPKALGS]
-      id-sha512         [ECCPKALGS]
-
-   Namely id-sha1 MUST be used in conjunction with ecdsa-with-Sha1, id-
-   sha256 MUST be used in conjunction with ecdsa-with-Sha256, id-sha384
-   MUST be used in conjunction with ecdsa-with-Sha384, and id-sha512
-   MUST be used in conjunction with ecdsa-with-Sha512.
-
-   Implementations of this specfication MUST support ecdsa-with-Sha256
-   and SHOULD support ecdsa-with-Sha1.
-
-
-4.  Using ECDH Key Exchange
-
-   This section describes how ECDH can be used as the AS reply key
-   delivery method [PKINIT].  Note that the protocol description is
-   similar to that of Modular Exponential Diffie-Hellman (MODP DH), as
-   described in [PKINIT].
-
-   If the client wishes to use ECDH key agreement method, it encodes its
-   ECDH public key value and the domain parameters [IEEE1363] for its
-   ECDH public key in clientPublicValue of the PA-PK-AS-REQ message
-   [PKINIT].
-
-   As described in [PKINIT], the ECDH domain parameters for the client's
-   public key are specified in the algorithm field of the type
-   SubjectPublicKeyInfo [RFC3279] and the client's ECDH public key value
-   is mapped to a subjectPublicKey (a BIT STRING) according to
-   [RFC3279].
-
-   The following algorithm identifier is used to identify the client's
-   choice of the ECDH key agreement method for key delivery.
-
-        id-ecPublicKey (Elliptic Curve Diffie-Hellman [IEEE1363])
-
-   If the domain parameters are not accepted by the KDC, the KDC sends
-   back an error message [RFC4120] with the code
-   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED [PKINIT].  This error message
-   contains the list of domain parameters acceptable to the KDC.  This
-   list is encoded as TD-DH-PARAMETERS [PKINIT], and it is in the KDC's
-   decreasing preference order.  The client can then pick a set of
-   domain parameters from the list and retry the authentication.
-
-
-
-
-Zhu, et al.              Expires March 17, 2006                 [Page 4]
-
-Internet-Draft           ECC Support for PKINIT           September 2005
-
-
-   Both the client and the KDC MUST have local policy that specifies
-   which set of domain parameters are acceptable if they do not have a
-   priori knowledge of the chosen domain parameters.  The need for such
-   local policy is explained in Section 6.
-
-   If the ECDH domain parameters are accepted by the KDC, the KDC sends
-   back its ECDH public key value in the subjectPublicKey field of the
-   PA-PK-AS-REP message [PKINIT].
-
-   As described in [PKINIT], the KDC's ECDH public key value is encoded
-   as a BIT STRING according to [RFC3279].
-
-   Note that in the steps above, the client can indicate to the KDC that
-   it wishes to reuse ECDH keys or to allow the KDC to do so, by
-   including the clientDHNonce field in the request [PKINIT], and the
-   KDC can then reuse the ECDH keys and include serverDHNonce field in
-   the reply [PKINIT].  This logic is the same as that of the Modular
-   Exponential Diffie-Hellman key agreement method [PKINIT].
-
-   If ECDH is negotiated as the key delivery method, both the KDC and
-   the client calculate the shared secret value and derive the reply key
-   as follows:
-
-   1) Let DHSharedSecret be the x-coordinate of the shared secret value
-      (an elliptic curve point).  DHSharedSecret is the output of
-      operation ECSVDP-DH as described in Section 7.2.1 of [IEEE1363].
-
-   2) DHSharedSecret is first padded with leading zeros such that the
-      size of DHSharedSecret in octets is the same as that of the
-      modulus, then represented as a string of octets in big-endian
-      order.
-
-   3) The DHSharedSecret value derived above is used as input to the
-      octetstring2key() function to derive the AS reply key k, as
-      described in Section 3.2.3.1 of [PKINIT].
-
-   Both the client and KDC then proceed as described in [PKINIT] and
-   [RFC4120].
-
-   Lastly it should be noted that ECDH can be used with any certificates
-   and signature schemes.  However, a significant advantage of using
-   ECDH together with ECC certificates and signature schemes is that the
-   ECC domain parameters in the client or KDC certificates can be used.
-   This obviates the need of locally preconfigured domain parameters as
-   described in Section 6.
-
-
-
-
-
-
-Zhu, et al.              Expires March 17, 2006                 [Page 5]
-
-Internet-Draft           ECC Support for PKINIT           September 2005
-
-
-5.  Choosing the Domain Parameters and the Key Size
-
-   The domain parameters and the key size should be chosen so as to
-   provide sufficient cryptographic security [RFC3766].  The following
-   table, based on table 2 on page 63 of NIST SP800-57 part 1
-   [NISTSP80057], gives approximate comparable key sizes for symmetric-
-   and asymmetric-key cryptosystems based on the best-known algorithms
-   for attacking them.
-
-
-                 Symmetric    |  ECC       |   RSA
-                 -------------+----------- +------------
-                    80        |  160 - 223 |   1024
-                   112        |  224 - 255 |   2048
-                   128        |  256 - 383 |   3072
-                   192        |  384 - 511 |   7680
-                   256        |  512+      |  15360
-
-                Table 1: Comparable key sizes (in bits)
-
-   Thus, for example, when securing a 128-bit symmetric key, it is
-   prudent to use 256-bit Elliptic Curve Cryptography (ECC), e.g. group
-   P-256 (secp256r1) as described below.
-
-   A set of ECDH domain parameters is also known as a curve.  A curve is
-   a named curve if the domain paratmeters are well known and can be
-   identified by an Object Identifier, otherwise it is called a custom
-   curve.  [PKINIT] supports both named curves and custom curves, see
-   Section 6 on the tradeoff of choosing between named curves and custom
-   curves.
-
-   The named curves recommended in this document are also recommended by
-   NIST [FIPS186-2].  These fifteen ECC curves are given in the
-   following table [FIPS186-2] [SECG].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires March 17, 2006                 [Page 6]
-
-Internet-Draft           ECC Support for PKINIT           September 2005
-
-
-              Description                      SEC 2 OID
-              -----------------                ---------
-
-              ECPRGF192Random  group P-192     secp192r1
-              EC2NGF163Random  group B-163     sect163r2
-              EC2NGF163Koblitz group K-163     sect163k1
-
-              ECPRGF224Random  group P-224     secp224r1
-              EC2NGF233Random  group B-233     sect233r1
-              EC2NGF233Koblitz group K-233     sect233k1
-
-              ECPRGF256Random  group P-256     secp256r1
-              EC2NGF283Random  group B-283     sect283r1
-              EC2NGF283Koblitz group K-283     sect283k1
-
-              ECPRGF384Random  group P-384     secp384r1
-              EC2NGF409Random  group B-409     sect409r1
-              EC2NGF409Koblitz group K-409     sect409k1
-
-              ECPRGF521Random  group P-521     secp521r1
-              EC2NGF571Random  group B-571     sect571r1
-              EC2NGF571Koblitz group K-571     sect571k1
-
-
-6.  Security Considerations
-
-   Kerberos error messages are not integrity protected, as a result, the
-   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
-   with by an attacker so that the set of domain parameters selected
-   could be either weaker or not mutually preferred.  Local policy can
-   configure sets of domain parameters acceptable locally, or disallow
-   the negotiation of ECDH domain parameters.
-
-   Beyond elliptic curve size, the main issue is elliptic curve
-   structure.  As a general principle, it is more conservative to use
-   elliptic curves with as little algebraic structure as possible - thus
-   random curves are more conservative than special curves such as
-   Koblitz curves, and curves over F_p with p random are more
-   conservative than curves over F_p with p of a special form (and
-   curves over F_p with p random might be considered more conservative
-   than curves over F_2^m as there is no choice between multiple fields
-   of similar size for characteristic 2).  Note, however, that algebraic
-   structure can also lead to implementation efficiencies and
-   implementors and users may, therefore, need to balance conservatism
-   against a need for efficiency.  Concrete attacks are known against
-   only very few special classes of curves, such as supersingular
-   curves, and these classes are excluded from the ECC standards such as
-   [IEEE1363] and [X9.62].
-
-
-
-Zhu, et al.              Expires March 17, 2006                 [Page 7]
-
-Internet-Draft           ECC Support for PKINIT           September 2005
-
-
-   Another issue is the potential for catastrophic failures when a
-   single elliptic curve is widely used.  In this case, an attack on the
-   elliptic curve might result in the compromise of a large number of
-   keys.  Again, this concern may need to be balanced against efficiency
-   and interoperability improvements associated with widely-used curves.
-   Substantial additional information on elliptic curve choice can be
-   found in [IEEE1363], [X9.62] and [FIPS186-2].
-
-
-7.  IANA Considerations
-
-   No IANA actions are required for this document.
-
-
-8.  Acknowledgements
-
-   The following people have made significant contributions to this
-   draft: Paul Leach, Dan Simon, Kelvin Yiu, David Cross and Sam
-   Hartman.
-
-
-9.  References
-
-9.1.  Normative References
-
-   [ECCPKALGS]
-              RFC-Editor: To be replaced by RFC number for draft-ietf-
-              pkix-ecc-pkalgs.  Work in Progress.
-
-   [FIPS186-2]
-              NIST, "Digital Signature Standard", FIPS 186-2, 2000.
-
-   [IEEE1363]
-              IEEE, "Standard Specifications for Public Key Cryptography",
-              IEEE 1363, 2000.
-
-   [NISTSP80057]
-              NIST, "Recommendation on Key Management", 
-              http://csrc.nist.gov/publications/nistpubs/, SP 800-57,
-              August 2005.
-                            
-   [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
-              cat-kerberos-pk-init.  Work in Progress.
-
-
-Zhu, et al.              Expires March 17, 2006                 [Page 8]
-
-Internet-Draft           ECC Support for PKINIT           September 2005
-
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3369]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3369, August 2002.
-
-   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
-              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
-              RFC 3766, April 2004.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-              
-   [X9.62]    ANSI, "Public Key Cryptography For The Financial Services
-              Industry: The Elliptic Curve Digital Signature Algorithm
-              (ECDSA)", ANSI X9.62, 1998.
-
-9.2.  Informative References
-
-   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
-              Sizes", Journal of Cryptology 14 (2001) 255-293.
-
-   [SECG]     SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
-              <http://www.secg.org/>.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires March 17, 2006                 [Page 9]
-
-Internet-Draft           ECC Support for PKINIT           September 2005
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-   Kristin Lauter
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: klauter@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires March 17, 2006                [Page 10]
-
-Internet-Draft           ECC Support for PKINIT           September 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.              Expires March 17, 2006                [Page 11]
-
-
diff --git a/doc/standardisation/draft-zhu-pkinit-ecc-01.txt b/doc/standardisation/draft-zhu-pkinit-ecc-01.txt
deleted file mode 100644
index 37863bbd2..000000000
--- a/doc/standardisation/draft-zhu-pkinit-ecc-01.txt
+++ /dev/null
@@ -1,611 +0,0 @@
-
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                             K. Jaganathan
-Expires: September 3, 2006                                     K. Lauter
-                                                   Microsoft Corporation
-                                                           March 2, 2006
-
-
-                         ECC Support for PKINIT
-                        draft-zhu-pkinit-ecc-01
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on September 3, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes the use of Elliptic Curve certificates,
-   Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman
-   (ECDH) key agreement within the framework of PKINIT - the Kerberos
-   Version 5 extension that provides for the use of public key
-   cryptography.
-
-
-
-
-
-Zhu, et al.             Expires September 3, 2006               [Page 1]
-
-Internet-Draft           ECC Support for PKINIT               March 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Using Elliptic Curve Certificates and Elliptic Curve
-       Signature Schemes  . . . . . . . . . . . . . . . . . . . . . .  3
-   4.  Using ECDH Key Exchange  . . . . . . . . . . . . . . . . . . .  4
-   5.  Choosing the Domain Parameters and the Key Size  . . . . . . .  5
-   6.  Interoperability Requirements  . . . . . . . . . . . . . . . .  7
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     10.1.  Normative References  . . . . . . . . . . . . . . . . . .  8
-     10.2.  Informative References  . . . . . . . . . . . . . . . . .  9
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
-   Intellectual Property and Copyright Statements . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires September 3, 2006               [Page 2]
-
-Internet-Draft           ECC Support for PKINIT               March 2006
-
-
-1.  Introduction
-
-   Elliptic Curve Cryptography (ECC) is emerging as an attractive
-   public-key cryptosystem that provides security equivalent to
-   currently popular public-key mechanisms such as RSA and DSA with
-   smaller key sizes [LENSTRA] [NISTSP80057].
-
-   Currently [PKINIT] permits the use of ECC algorithms but it does not
-   specify how ECC parameters are chosen and how to derive the shared
-   key for key delivery using Elliptic Curve Diffie-Hellman (ECDH)
-   [IEEE1363] [X9.63].
-
-   This document describes how to use Elliptic Curve certificates,
-   Elliptic Curve signature schemes, and ECDH with [PKINIT].  However,
-   it should be noted that there is no syntactic or semantic change to
-   the existing [PKINIT] messages.  Both the client and the KDC
-   contribute one ECDH key pair using the key agrement protocol
-   described in this document.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  Using Elliptic Curve Certificates and Elliptic Curve Signature
-    Schemes
-
-   ECC certificates and signature schemes can be used in the
-   Cryptographic Message Syntax (CMS) [RFC3369] content type
-   'SignedData'.
-
-   X.509 certificates [RFC3280] containing ECC public keys or signed
-   using ECC signature schemes MUST comply with [RFC3279].
-
-   The elliptic curve domain parameters recommended in [X9.62],
-   [FIPS186-2], and [SECG] SHOULD be used.
-
-   The signatureAlgorithm field of the CMS data type SignerInfo can
-   contain one of the following ECC signature algorithm identifiers:
-
-      ecdsa-with-Sha1   [ECCPKALGS]
-      ecdsa-with-Sha256 [ECCPKALGS]
-      ecdsa-with-Sha384 [ECCPKALGS]
-      ecdsa-with-Sha512 [ECCPKALGS]
-
-
-
-
-Zhu, et al.             Expires September 3, 2006               [Page 3]
-
-Internet-Draft           ECC Support for PKINIT               March 2006
-
-
-   The corresponding digestAlgorithm field contains one of the following
-   hash algorithm identifiers respectively:
-
-      id-sha1           [RFC3279]
-      id-sha256         [ECCPKALGS]
-      id-sha384         [ECCPKALGS]
-      id-sha512         [ECCPKALGS]
-
-   Namely id-sha1 MUST be used in conjunction with ecdsa-with-Sha1, id-
-   sha256 MUST be used in conjunction with ecdsa-with-Sha256, id-sha384
-   MUST be used in conjunction with ecdsa-with-Sha384, and id-sha512
-   MUST be used in conjunction with ecdsa-with-Sha512.
-
-   Implementations of this specfication MUST support ecdsa-with-Sha256
-   and SHOULD support ecdsa-with-Sha1.
-
-
-4.  Using ECDH Key Exchange
-
-   This section describes how ECDH can be used as the AS reply key
-   delivery method [PKINIT].  Note that the protocol description here is
-   similar to that of Modular Exponential Diffie-Hellman (MODP DH), as
-   described in [PKINIT].
-
-   If the client wishes to use ECDH key agreement method, it encodes its
-   ECDH public key value and the domain parameters [IEEE1363] [X9.63]
-   for its ECDH public key in clientPublicValue of the PA-PK-AS-REQ
-   message [PKINIT].
-
-   As described in [PKINIT], the ECDH domain parameters for the client's
-   public key are specified in the algorithm field of the type
-   SubjectPublicKeyInfo [RFC3279] and the client's ECDH public key value
-   is mapped to a subjectPublicKey (a BIT STRING) according to
-   [RFC3279].
-
-   The following algorithm identifier is used to identify the client's
-   choice of the ECDH key agreement method for key delivery.
-
-        id-ecPublicKey (Elliptic Curve Diffie-Hellman [ECCPKALGS])
-
-   If the domain parameters are not accepted by the KDC, the KDC sends
-   back an error message [RFC4120] with the code
-   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED [PKINIT].  This error message
-   contains the list of domain parameters acceptable to the KDC.  This
-   list is encoded as TD-DH-PARAMETERS [PKINIT], and it is in the KDC's
-   decreasing preference order.  The client can then pick a set of
-   domain parameters from the list and retry the authentication.
-
-
-
-
-Zhu, et al.             Expires September 3, 2006               [Page 4]
-
-Internet-Draft           ECC Support for PKINIT               March 2006
-
-
-   Both the client and the KDC MUST have local policy that specifies
-   which set of domain parameters are acceptable if they do not have a
-   priori knowledge of the chosen domain parameters.  The need for such
-   local policy is explained in Section 7.
-
-   If the ECDH domain parameters are accepted by the KDC, the KDC sends
-   back its ECDH public key value in the subjectPublicKey field of the
-   PA-PK-AS-REP message [PKINIT].
-
-   As described in [PKINIT], the KDC's ECDH public key value is encoded
-   as a BIT STRING according to [RFC3279].
-
-   Note that in the steps above, the client can indicate to the KDC that
-   it wishes to reuse ECDH keys or to allow the KDC to do so, by
-   including the clientDHNonce field in the request [PKINIT], and the
-   KDC can then reuse the ECDH keys and include serverDHNonce field in
-   the reply [PKINIT].  This logic is the same as that of the Modular
-   Exponential Diffie-Hellman key agreement method [PKINIT].
-
-   If ECDH is negotiated as the key delivery method, then the PA-PK-AS-
-   REP and AS reply key are generated as in Section 3.2.3.1 of [PKINIT]
-   with the following difference: The DHSharedSecret is the x-coordinate
-   of the shared secret value (an elliptic curve point); DHSharedSecret
-   is the output of operation ECSVDP-DH as described in Section 7.2.1 of
-   [IEEE1363].
-
-   Both the client and KDC then proceed as described in [PKINIT] and
-   [RFC4120].
-
-   Lastly it should be noted that ECDH can be used with any certificates
-   and signature schemes.  However, a significant advantage of using
-   ECDH together with ECC certificates and signature schemes is that the
-   ECC domain parameters in the client or KDC certificates can be used.
-   This obviates the need of locally preconfigured domain parameters as
-   described in Section 7.
-
-
-5.  Choosing the Domain Parameters and the Key Size
-
-   The domain parameters and the key size should be chosen so as to
-   provide sufficient cryptographic security [RFC3766].  The following
-   table, based on table 2 on page 63 of NIST SP800-57 part 1
-   [NISTSP80057], gives approximate comparable key sizes for symmetric-
-   and asymmetric-key cryptosystems based on the best-known algorithms
-   for attacking them.
-
-
-
-
-
-
-Zhu, et al.             Expires September 3, 2006               [Page 5]
-
-Internet-Draft           ECC Support for PKINIT               March 2006
-
-
-                 Symmetric    |  ECC       |   RSA
-                 -------------+----------- +------------
-                    80        |  160 - 223 |   1024
-                   112        |  224 - 255 |   2048
-                   128        |  256 - 383 |   3072
-                   192        |  384 - 511 |   7680
-                   256        |  512+      |  15360
-
-                Table 1: Comparable key sizes (in bits)
-
-   Thus, for example, when securing a 128-bit symmetric key, it is
-   prudent to use 256-bit Elliptic Curve Cryptography (ECC), e.g. group
-   P-256 (secp256r1) as described below.
-
-   A set of ECDH domain parameters is also known as a curve.  A curve is
-   a named curve if the domain paratmeters are well known and can be
-   identified by an Object Identifier, otherwise it is called a custom
-   curve.  [PKINIT] supports both named curves and custom curves, see
-   Section 7 on the tradeoff of choosing between named curves and custom
-   curves.
-
-   The named curves recommended in this document are also recommended by
-   NIST [FIPS186-2].  These fifteen ECC curves are given in the
-   following table [FIPS186-2] [SECG].
-
-              Description                      SEC 2 OID
-              -----------------                ---------
-
-              ECPRGF192Random  group P-192     secp192r1
-              EC2NGF163Random  group B-163     sect163r2
-              EC2NGF163Koblitz group K-163     sect163k1
-
-              ECPRGF224Random  group P-224     secp224r1
-              EC2NGF233Random  group B-233     sect233r1
-              EC2NGF233Koblitz group K-233     sect233k1
-
-              ECPRGF256Random  group P-256     secp256r1
-              EC2NGF283Random  group B-283     sect283r1
-              EC2NGF283Koblitz group K-283     sect283k1
-
-              ECPRGF384Random  group P-384     secp384r1
-              EC2NGF409Random  group B-409     sect409r1
-              EC2NGF409Koblitz group K-409     sect409k1
-
-              ECPRGF521Random  group P-521     secp521r1
-              EC2NGF571Random  group B-571     sect571r1
-              EC2NGF571Koblitz group K-571     sect571k1
-
-
-
-
-Zhu, et al.             Expires September 3, 2006               [Page 6]
-
-Internet-Draft           ECC Support for PKINIT               March 2006
-
-
-6.  Interoperability Requirements
-
-   Implementations conforming to this specification MUST support curve
-   P-256 and P-384.
-
-
-7.  Security Considerations
-
-   Kerberos error messages are not integrity protected, as a result, the
-   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
-   with by an attacker so that the set of domain parameters selected
-   could be either weaker or not mutually preferred.  Local policy can
-   configure sets of domain parameters acceptable locally, or disallow
-   the negotiation of ECDH domain parameters.
-
-   Beyond elliptic curve size, the main issue is elliptic curve
-   structure.  As a general principle, it is more conservative to use
-   elliptic curves with as little algebraic structure as possible - thus
-   random curves are more conservative than special curves such as
-   Koblitz curves, and curves over F_p with p random are more
-   conservative than curves over F_p with p of a special form (and
-   curves over F_p with p random might be considered more conservative
-   than curves over F_2^m as there is no choice between multiple fields
-   of similar size for characteristic 2).  Note, however, that algebraic
-   structure can also lead to implementation efficiencies and
-   implementors and users may, therefore, need to balance conservatism
-   against a need for efficiency.  Concrete attacks are known against
-   only very few special classes of curves, such as supersingular
-   curves, and these classes are excluded from the ECC standards such as
-   [IEEE1363] and [X9.62].
-
-   Another issue is the potential for catastrophic failures when a
-   single elliptic curve is widely used.  In this case, an attack on the
-   elliptic curve might result in the compromise of a large number of
-   keys.  Again, this concern may need to be balanced against efficiency
-   and interoperability improvements associated with widely-used curves.
-   Substantial additional information on elliptic curve choice can be
-   found in [IEEE1363], [X9.62] and [FIPS186-2].
-
-
-8.  IANA Considerations
-
-   No IANA actions are required for this document.
-
-
-9.  Acknowledgements
-
-   The following people have made significant contributions to this
-
-
-
-Zhu, et al.             Expires September 3, 2006               [Page 7]
-
-Internet-Draft           ECC Support for PKINIT               March 2006
-
-
-   draft: Paul Leach, Dan Simon, Kelvin Yiu, David Cross, Sam Hartman,
-   Tolga Acar, and Stefan Santesson.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [ECCPKALGS]
-              RFC-Editor: To be replaced by RFC number for draft-ietf-
-              pkix-ecc-pkalgs.  Work in Progress.
-
-   [FIPS186-2]
-              NIST, "Digital Signature Standard", FIPS 186-2, 2000.
-
-   [IEEE1363]
-              IEEE, "Standard Specifications for Public Key Cryptography",
-              IEEE 1363, 2000.
-
-   [NISTSP80057]
-              NIST, "Recommendation on Key Management", 
-              http://csrc.nist.gov/publications/nistpubs/, SP 800-57,
-              August 2005.
-
-
-
-Zhu, et al.             Expires September 3, 2006               [Page 8]
-
-Internet-Draft           ECC Support for PKINIT               March 2006
-
-
-
-   [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
-              cat-kerberos-pk-init.  Work in Progress.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3369]  Housley, R., "Cryptographic Message Syntax (CMS)",
-              RFC 3369, August 2002.
-
-   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
-              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
-              RFC 3766, April 2004.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [X9.62]    ANSI, "Public Key Cryptography For The Financial Services
-              Industry: The Elliptic Curve Digital Signature Algorithm
-              (ECDSA)", ANSI X9.62, 1998.
-  
-   [X9.63]    ANSI, "Public Key Cryptography for the Financial Services 
-              Industry: Key Agreement and Key Transport using Elliptic 
-              Curve Cryptography", ANSI X9.63, 2001.
-              
-
-9.2.  Informative References
-
-   [LENSTRA]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 
-              Sizes", Journal of Cryptology 14 (2001) 255-293.
-
-   [SECG]     SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
-              <http://www.secg.org/>.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires September 3, 2006               [Page 9]
-
-Internet-Draft           ECC Support for PKINIT               March 2006
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: karthikj@microsoft.com
-
-
-   Kristin Lauter
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: klauter@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires September 3, 2006              [Page 10]
-
-Internet-Draft           ECC Support for PKINIT               March 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Zhu, et al.             Expires September 3, 2006              [Page 11]
-
-
diff --git a/doc/standardisation/draft-zhu-pku2u-00.txt b/doc/standardisation/draft-zhu-pku2u-00.txt
deleted file mode 100644
index 09030bcde..000000000
--- a/doc/standardisation/draft-zhu-pku2u-00.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                              A. Medvinsky
-Updates: 4120 (if approved)                        Microsoft Corporation
-Intended status: Standards Track                               J. Altman
-Expires: May 11, 2007                                  Secure End Points
-                                                        November 7, 2006
-
-
-  Public Key Cryptography based User to User Authentication - (PKU2U)
-                           draft-zhu-pku2u-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on May 11, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document defines the Public Key Cryptography based User to User
-   authentication protocol - PKU2U. PKU2U is based on RFC4456 and
-   RFC4120.  This enables peer to peer authentication using Kerberos
-   messages without requiring an online trusted third party.  In
-   addition, the binding of PKU2U for the Generic Security Service
-   Application Program Interface (GSS-API) per RFC2743 is defined based
-
-
-
-Zhu, et al.               Expires May 11, 2007                  [Page 1]
-
-Internet-Draft                    PKU2U                    November 2006
-
-
-   on RFC4121.
-
-
-Table of Contents
-
-   1  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2  Conventions Used in This Document  . . . . . . . . . . . . . . . 3
-   3  Protocol description . . . . . . . . . . . . . . . . . . . . . . 3
-   4  Security Considerations  . . . . . . . . . . . . . . . . . . . . 4
-   5  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
-   6  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 5
-   7  Normative References . . . . . . . . . . . . . . . . . . . . . . 5
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 5
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 11, 2007                  [Page 2]
-
-Internet-Draft                    PKU2U                    November 2006
-
-
-1  Introduction
-
-   Peer-to-peer systems are increasingly popular today.  In a peer-to-
-   peer system, all clients provide resources that contribute positively
-   to the total capacity of the overall system and there is no single
-   point of failure.  This distributed nature makes the system highly
-   scalable and robust.  In addition, the peer-to-peer system is self-
-   organized.  These enable services that just work.
-
-   In a peer-to-peer system, if the initiator can authenticate the
-   acceptor and then establish trust in the information received from
-   the peer, many attacks such as poisoning (e.g. providing data
-   contents are different from the description) and polluting (e.g.
-   inserting "bad" chunks/packets) can be mitigated or eliminated.
-   However, currently there is no interoperable GSS-API mechanism for
-   use in these environments.
-
-   The PKU2U protocol defined in this document extends PKINIT to support
-   peer-to-peer authentications without the use of Key Distribution
-   Center (KDC) [RFC4120].  Thus it enables peer to peer authentication
-   based on public key cryptography.  In addition, this document defines
-   the binding for GSS-API based on [RFC4121] and [WS-KERB], which makes
-   PKU2U readily available to the widely deployed GSS-API applications.
-
-
-2  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3  Protocol description
-
-   The PKU2U realm name is a reserved name that is defined according to
-   [KRB-NAME].  It has the value of "RESERVED:PKU2U".
-
-   PKU2U replaces the KDC in [RFC4556] with the identity of the
-   acceptor, and it updates the protocol with the following changes:
-
-   All the realm names in Kerberos messages are filled with the PKU2U
-   reserved realm.
-
-   The client name in AS-REQ [RFC4120] contains the name of the
-   initiator, and the server name contains the Kerberos name of the
-   acceptor.
-
-   The initiator signs the pre-authentication data as needed per
-
-
-
-Zhu, et al.               Expires May 11, 2007                  [Page 3]
-
-Internet-Draft                    PKU2U                    November 2006
-
-
-   [RFC4120] and constructs an AS-REQ, and then sends the request to the
-   acceptor using the same GSS-API encapsulation defined in [WS-KERB],
-   except the mechanism Objection Identifier (OID) for PKU2U is id-
-   kerberos-pku2u.
-
-      id-kerberos-pku2u ::=
-        { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
-          pku2u(7) }
-
-   The client fills out the realm field in the ProxyData [WS-KERB] using
-   the reserved PKU2U realm.  Upon receipt of the WS_KRB_PROXY message,
-   the GSS-API acceptor processes the Kerberos message (an AS-REQ) that
-   follows the WS_KRB_PROXY header.
-
-   The acceptor validates the pre-authentication data in the request per
-   Section 3.2.2 of [RFC4556] and it MUST verify the binding between the
-   client name and the client's signing key, if the pre-authentication
-   data in the request is signed.  The client's X.509 certificate, if
-   present, MUST contain id-pkinit-KPClientAuth [RFC4556] or id-kp-
-   clientAuth [RFC3280].  If the client is authenticated as expected,
-   the acceptor issues a service ticket to the initiator per [RFC4120].
-
-   Upon receipt of the reply, the initiator validates the pre-
-   authentication data in the reply per Section 3.2.4 of [RFC4556].  As
-   stated earlier, there is no KDC in PKU2U, thus the requirement of the
-   id-pkinit-KPKdc is not applicable when PKU2U is used.  The initiator
-   MUST verify the binding between the signing key in the reply and the
-   acceptor.  When the GSS-API acceptor is identified using the
-   targ_name parameter of the GSS_Init_sec_context() call, the signing
-   key MUST be bound with the targ_name.  The acceptor's X.509
-   certificate MUST contain id-kp-clientAuth [RFC3280] or id-kp-
-   serverAuth [RFC3280] or id-pkinit-KPClientAuth [RFC4556].
-
-   The Kerberos principal name form and the host-based service Name
-   described in [RFC1964] MUST be supported by conforming
-   implementations of this specification.
-
-   Once the AS-REP in the reply is accepted, the initiator can use the
-   obtained service to construct an AP-REQ and communicate with the
-   acceptor.  The rest of the protocol and the GSS-API binding are the
-   same as defined in [WS-KERB] and [RFC4121].
-
-
-4  Security Considerations
-
-   The security considerations in [RFC4556] apply here.  In addition,
-   the initiator and the acceptor MUST be able to verify the binding
-   between the signing key and the associated identity.
-
-
-
-Zhu, et al.               Expires May 11, 2007                  [Page 4]
-
-Internet-Draft                    PKU2U                    November 2006
-
-
-5  Acknowledgements
-
-   The authors would like thanks Jeffery Hutzelman for his comments with
-   regarding to unifying [WS-KERB] with PKU2U .
-
-
-6  IANA Considerations
-
-   Section 3 defines the PKU2U realm.  The IANA registry for the
-   reserved names should be updated to reference this document.
-
-
-7.  Normative References
-
-   [KRB-NAME] L. Zhu, "Additional Kerberos Naming Constraints", 
-              draft-ietf-krb-wg-naming, work in progress.
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
-              Simple and Protected Generic Security Service Application
-              Program Interface (GSS-API) Negotiation Mechanism",
-              RFC 4178, October 2005.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-
-
-
-Zhu, et al.               Expires May 11, 2007                  [Page 5]
-
-Internet-Draft                    PKU2U                    November 2006
-
-
-   [WS-KERB] L. Zhu, "Kerberos for Web Services", draft-zhu-ws-kerb, work
-             in progress.
-             
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Ari Medvinsky
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: arimed@microsoft.com
-
-
-   Jeffery
-   Secure End Points
-   612 West 115th Street Room 716
-   New York, NY  10025
-   US
-
-   Email: jaltman@secureendpoint.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.               Expires May 11, 2007                  [Page 6]
-
-Internet-Draft                    PKU2U                    November 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Zhu, et al.               Expires May 11, 2007                  [Page 7]
-
-
diff --git a/doc/standardisation/draft-zhu-pku2u-09.txt b/doc/standardisation/draft-zhu-pku2u-09.txt
deleted file mode 100644
index e6d1b75e7..000000000
--- a/doc/standardisation/draft-zhu-pku2u-09.txt
+++ /dev/null
@@ -1,1288 +0,0 @@
-

-

-NETWORK WORKING GROUP                                             L. Zhu

-Internet-Draft                                     Microsoft Corporation

-Intended status: Standards Track                               J. Altman

-Expires: May 7, 2009                                    Secure Endpoints

-                                                             N. Williams

-                                                                     Sun

-                                                        November 3, 2008

-

-

-  Public Key Cryptography Based User-to-User Authentication - (PKU2U)

-                           draft-zhu-pku2u-09

-

-Status of this Memo

-

-   By submitting this Internet-Draft, each author represents that any

-   applicable patent or other IPR claims of which he or she is aware

-   have been or will be disclosed, and any of which he or she becomes

-   aware will be disclosed, in accordance with Section 6 of BCP 79.

-

-   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."

-

-   The list of current Internet-Drafts can be accessed at

-   http://www.ietf.org/ietf/1id-abstracts.txt.

-

-   The list of Internet-Draft Shadow Directories can be accessed at

-   http://www.ietf.org/shadow.html.

-

-   This Internet-Draft will expire on May 7, 2009.

-

-Abstract

-

-   This document defines a Generic Security Services Application Program

-   Interface (GSS-API) mechanism based on Public Key Infrastructure

-   (PKI) - PKU2U. This mechanism is based on Kerberos V messages and the

-   Kerberos V GSS-API mechanism, but without requiring a Kerberos Key

-   Distribution Center (KDC).

-

-

-

-

-

-

-

-Zhu, et al.                Expires May 7, 2009                  [Page 1]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-Table of Contents

-

-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3

-   3.  The PKU2U Realm Name . . . . . . . . . . . . . . . . . . . . .  3

-   4.  The NULL Principal Name  . . . . . . . . . . . . . . . . . . .  4

-   5.  PKU2U Principal Naming . . . . . . . . . . . . . . . . . . . .  4

-     5.1.  GSS_C_NT_DN  . . . . . . . . . . . . . . . . . . . . . . .  6

-     5.2.  GSS_C_NT_HOSTNAME  . . . . . . . . . . . . . . . . . . . .  6

-     5.3.  GSS_C_NT_EMAIL_ADDR  . . . . . . . . . . . . . . . . . . .  7

-     5.4.  GSS_KRB5_NT_PRINCIPAL_NAME . . . . . . . . . . . . . . . .  7

-     5.5.  GSS_C_NT_ANONYMOUS . . . . . . . . . . . . . . . . . . . .  9

-     5.6.  GSS_C_NT_HOSTBASED_SERVICE - Matching Host-based

-           Principal Names to Acceptor Certificates . . . . . . . . .  9

-   6.  The Protocol Description and the Context Establishment

-       Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

-     6.1.  Context Token Derived from KRB_AS_REQ  . . . . . . . . . . 12

-     6.2.  Context Token Derived from KRB_AS_REP  . . . . . . . . . . 15

-     6.3.  Context Tokens Imported from RFC4121 . . . . . . . . . . . 16

-   7.  Guidelines for Credentials Selection . . . . . . . . . . . . . 17

-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18

-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19

-   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19

-   11. Normative References . . . . . . . . . . . . . . . . . . . . . 19

-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21

-   Intellectual Property and Copyright Statements . . . . . . . . . . 23

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Zhu, et al.                Expires May 7, 2009                  [Page 2]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-1.  Introduction

-

-   The Generic Security Services Application Programming Interface (GSS-

-   API) is a generic protocol and API for providing authentication and

-   session protection to applications.  It is generic in that it

-   supports multiple authentication mechanisms.  Today there exists only

-   one workable, widely deployed, standards-track GSS-API mechanism: the

-   Kerberos V GSS-API mechanism [RFC1964] [RFC4121], which is based on

-   Kerberos V [RFC4120].  There is a need to provide a GSS-API mechanism

-   which does not require Kerberos V Key Distribution Center (KDC)

-   infrastructure, and which supports the use of public key

-   cryptography, particularly Public Key Infrastructure (PKI) [RFC5280],

-   including the use of public key certificates without a PKI.

-

-   This document specifies such a mechanism: the Public Key User to User

-   mechanism (PKU2U).

-

-   PKU2U is based on building blocks taken from Kerberos V [RFC4120],

-   PKINIT, [RFC4556] (which in turn uses PKI [RFC5280]) building

-   blocks), and the Kerberos V GSS-API mechanism [RFC1964] [RFC4121].

-   In spite of using Kerberos V building blocks, PKU2U does not require

-   any Kerberos V KDC infrastructure.  And though PKU2U also uses PKI

-   building blocks, PKU2U can be used without a PKI by pre-sharing

-   certificates and/or pre-associating name/certificate bindings.

-

-   Therefore PKU2U can be used for true peer-to-peer authentication, as

-   well as for PKI-based authentication.

-

-

-2.  Conventions Used in This Document

-

-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

-   document are to be interpreted as described in [RFC2119].

-

-   In this document, the GSS-API initiator or acceptor is referred to as

-   the peer when the description is applicable to both the initiator and

-   the acceptor.

-

-

-3.  The PKU2U Realm Name

-

-   The PKU2U realm name is defined as a reserved Kerberos realm name per

-   [KRB-NAMING], and it has the value of "WELLKNOWN:PKU2U".

-

-   The PKU2U realm name has no meaning, but is intended to be used in

-   the Kebreros V Protocol Data Units (PDUs) that are re-used by PKU2U

-   wherever realm names are needed.  Unless otherwise specified, the

-

-

-

-Zhu, et al.                Expires May 7, 2009                  [Page 3]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   realm name in any Kerberos message used by PKU2U is the PKU2U realm

-   name.

-

-

-4.  The NULL Principal Name

-

-   The NULL Kerberos principal name is defined as a well-known Kerberos

-   principal name based on [KRB-NAMING].  The value of the name-type

-   field is KRB_NT_WELLKNOWN [KRB-NAMING], and the value of the name-

-   string field is a sequence of two KerberosString components:

-   "WELLKNOWN", "NULL".

-

-   The NULL Kerberos principal name is used in the Kerberos messages

-   where there is no Kerberos representation of the principal name, for

-   example, when the client name is a Distinguished Name.  When the NULL

-   principal name is used in the Kerberos messages, the principal name

-   is either not used or provided separately (for example in the

-   PA_PKU2U_NAME padata defined in Section 6.1).

-

-

-5.  PKU2U Principal Naming

-

-   The GSS-API targ_name supplied for the initiator MUST NOT be

-   GSS_C_NO_NAME in PKU2U.

-

-   PKU2U principal names can be Kerberos principal names, and they can

-   also be distiguished names, or subject alternative names [RFC5280] as

-   they appear in the certificate of any PKU2U peer, as well as any

-   names agreed to out of band that do not appear in the peer

-   certificates.

-

-   Certificates may be associated with multiple principal names.  This

-   presents problems for the GSS-API bindings of a PKI-based mechanism

-   because, for example, for any given, established GSS-API security

-   mechanism there can be only one initiator name, and one acceptor

-   name, and credential handles may be associated with only one name.

-   We resolve these problems as follows:

-

-   o  We define multiple GSS-API name types corresponding to several

-      GeneralName choices [RFC5280], along with syntaxes, display forms,

-      and exported name token formats for each.  For most of the name-

-      types listed below the exported name token formats consists of a

-      GeneralName with the usual exported name token header as per-

-      RFC2743.  Two name-types are shared with the Kerberos V mechanism

-      and use the Kerberos V mechanism's query and display syntaxes,

-      canonicalization rules, and exported name token format.

-

-

-

-

-

-Zhu, et al.                Expires May 7, 2009                  [Page 4]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   o  The cred_name of a credential handle acquired with

-      GSS_C_NT_NO_NAME as the desired_name SHOULD be the Distinguished

-      Name (DN) of the certificate underlying the credential.  If there

-      are multiple certificates and private keys, then either one MUST

-      be selected by local, implementation-specific means, or credential

-      acquisition with GSS_C_NT_NO_NAME MUST fail (implementers may

-      choose which of these two behaviors to provide).

-

-   o  When using desired_name values other than GSS_C_NT_NO_NAME for

-      credential handle acquisition then the implementation MUST use

-      exact matching of the given desired_name to a certificate's DN or

-      Subject Alternative Names (SANs) for all name-types given below,

-      except for GSS_C_NT_DN, where matching rules are fuzzier and given

-      below.  The names of a X.509 certificate will be compared to the

-      given desired_name in this order: certificate DN first, then SANs

-      in the order in which they appear in the certificate.  When

-      multiple certificates and private keys are available the order in

-      which the various certificates are searched is significant; no

-      canonical certificate collation order is defined herein.

-

-   o  The cred_name of a credential object acquired with a desired_name

-      other than GSS_C_NT_NO_NAME MUST be equal to the certificate DN or

-      SAN matched by the given desired_name.

-

-   o  We provide a method (see below) by which initiators can assert, in

-      their context tokens, one of these names of the initiator.  We

-      also provide a method of asserting names that do not appear in a

-      X.509 certificate, in which case the binding of X.509 certificate

-      to the asserted name is done out-of band.  The name to be

-      asserted, of course, is the cred_name of the cred_handle passed to

-      GSS_Init_sec_context().

-

-   o  The initiator's context tokens may also indicate what is the

-      expected name of the acceptor -- the targ_name passed in to

-      GSS_Init_sec_context().

-

-   o  No attempt is made to map Kerberos V realm names to trust anchor

-      certificate authority (CA) names.

-

-   o  We provide a method of matching host-based service principal names

-      to acceptor certificates, so that: a) initiators need not know the

-      particulars of an acceptor's certificates' names a priori, b)

-      acceptors can select a credential to accept a security context

-      with that the initiator will accept, c) existing certificates for

-      web servers, may be used as host-based service principal names as

-      though the service name were "HTTP".

-

-   Thus GSS-API initiator applications that use the GSS_C_NO_NAME as the

-

-

-

-Zhu, et al.                Expires May 7, 2009                  [Page 5]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   desired_name arguments of GSS_Acquire_cred() and GSS_Add_cred(), or

-   GSS_C_NO_CREDENTIAL as the cred argument of GSS_Init_sec_context()

-   will assert the selected X.509 certificate's subject DN, and that

-   X.509 certificate's subject DN will be the name returned by

-   GSS_Inquire_cred() and GSS_Inquire_cred_by_mech().

-

-   And portable GSS-API initiator applications using

-   GSS_C_NT_HOSTBASED_SERVICE for naming acceptors (i.e., for importing

-   a name to use as the targ_name input argument of

-   GSS_Init_sec_context()) will have a reasonable chance of success in

-   authenticating peers with X.509 certificates predating this

-   specification.

-

-5.1.  GSS_C_NT_DN

-

-   The name type GSS_C_NT_DN, with Object Identifier (OID) <TBD> (see

-   Section 10), is defined.  This corresponds to the 'directoryName'

-   choice of the 'GeneralName' Abstract Syntax Notation One (ASN.1)

-   [CCITT.X680.2002] type defined in [RFC5280].

-

-   The query syntax and display form for names of this type SHALL be as

-   described in [RFC4514].

-

-   As RFC4514 says, "[c]omparison of DNs for equality is to be performed

-   in accordance with the distinguishedNameMatch matching rule

-   [RFC4517]".

-

-   There is no reasonable way to canonicalize names of this type without

-   providing certificates to match query forms of GSS_C_NT_DN against,

-   such as in the form of a directory.  Therefore

-   GSS_Canonicalize_name() as applied to names imported with the

-   GSS_C_NT_DN name-type MUST search available certificate databases, or

-   directories, or MUST fail.  No method of locating and searching

-   directories for matching certificate DNs is specified herein.  Note

-   though that GSS_Inquire_cred_by_mech() and GSS_Inquire_sec_context()

-   can and, indeed, MUST return "mechanism names" (MN) (see [RFC2743]).

-

-   The exported name token format for names of this type SHALL be the

-   Distinguished Encoding Rules (DER) [CCITT.X680.2002]

-   [CCITT.X690.2002] encoding of a GeneralName with directoryName as the

-   choice.

-

-   Implementation support for this name type is REQUIRED.

-

-5.2.  GSS_C_NT_HOSTNAME

-

-   The name type GSS_C_NT_HOSTNAME, with OID <TBD>, is defined.  This

-   corresponds to the 'dNSName' choice of the 'GeneralName' ASN.1 type

-

-

-

-Zhu, et al.                Expires May 7, 2009                  [Page 6]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   defined in [RFC5280].

-

-   The query syntax for names of this type SHALL be a DNS name [RFC1034]

-   in either ACE or Unicode form [RFC3490].

-

-   The display and canonical form of names of this type SHALL be a DNS

-   domain name in ACE form, with character case folded down.

-   Canonicalization consists merely of applying the ToASCII() function

-   and case-folding the result.

-

-   The exported name token format for names of this type SHALL be the

-   DER encoding of a GeneralName with dNSName as the choice and the DNS

-   domain name in ACE form and case folded down.

-

-   Implementation support for this name type is OPTIONAL.

-

-5.3.  GSS_C_NT_EMAIL_ADDR

-

-   The name type GSS_C_NT_EMAIL_ADDR, with OID <TBD>, is defined.  This

-   corresponds to the 'rfc822Name' choice of the 'GeneralName' ASN.1

-   type defined in [RFC5280].

-

-   The query syntax and display form for names of this type SHALL be the

-   text representation of an 'addr-spec' as defined in [RFC0822].

-

-   The canonical form of names of this type SHALL be the query form with

-   case folded down.  Note that the domain name part of an addr-spec is

-   a "domain name slot" and so the canonicalization rules for

-   GSS_C_NT_HOSTNAME given above apply here as well.

-

-   The exported name token form for this name type SHALL be the DER-

-   encoding of a GeneralName with the rfc822Name choice.

-

-   Implementation support for this name type is OPTIONAL.

-

-5.4.  GSS_KRB5_NT_PRINCIPAL_NAME

-

-   PKU2U supports the use of GSS_KRB5_NT_PRINCIPAL_NAME names [RFC1964].

-

-   The query, display, canonical and exported name token forms of names

-   of this type SHALL be as specified in RFC4121.  The realm name part

-   of GSS_KRB5_NT_PRINCIPAL_NAME names is optional for the query syntax;

-   when canonicalized, names of this type lacking a realm name will have

-   the well-known PKU2U realm name affixed.

-

-   When the realm name of a GSS_KRB5_NT_PRINCIPAL_NAME NAME is defaulted

-   or otherwise is the well-known PKU2U realm name, then the "cname"' or

-   sname fields of the Kerberos V PDUs used to construct PKU2U security

-

-

-

-Zhu, et al.                Expires May 7, 2009                  [Page 7]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   context tokens MUST be set to the principal name part of the given

-   NAME.  Otherwise the PA_PKU2U_NAME pre-authentication data MUST be

-   used to indicate a name of id-pkinit-san type [RFC4556] corresponding

-   to the given NAME.  See Section 5.4.

-

-   No attempt is made to map Kerberos V realm names to trust anchor

-   certificate authority (CA) names.

-

-   Note that having more than one mechanism share name-types has

-   implications for multi-mechanism, pluggable GSS-API implementations

-   (commonly referred to as "mechglue").  Specifically:

-

-   o  It must be the responsibility of the mechanism, not of the

-      mechglue, to ensure that the standard exported name token header

-      (which includes a mechanism OID), is included in exported name

-      tokens.  The exported name token for a GSS_KRB5_NT_PRINCIPAL_NAME

-      MN produced by PKU2U would have PKU2U's mechanism OID in the

-      header.

-

-   o  A pluggable mechglue must be able to find a mechanism that can

-      import an exported name token if an available mechanism can

-      produce that exported name token.  For example, a pluggable

-      mechglue where PKU2U is available but where the Kerberos V

-      mechanism [RFC1964] is not should still be able to import exported

-      Kerberos V name tokens since PKU2U can create such tokens.  One

-      way to do this would be for the mechglue to try the mechanism

-      named in the exported name token header, if it is available, else

-      try all other available mechanisms until one succeeds or all fail.

-      It would be reasonable for a mechglue implementer to require that

-      the Kerberos V mechanism be available if PKU2U is too.

-

-   o  It must be possible for GSS_Acquire_cred(), GSS_Add_cred() to use

-      a Kerberos V "mechanism name" (MN; see [RFC2743]) as desired_name

-      argument value to acquire a PKU2U credential.  Similarly, it must

-      be possible to use a Kerberos V MN as the target_name in a call to

-      GSS_Init_sec_context with PKU2U as the mech OID.  A multi-

-      mechanism mechglue implementer would likely have a mechglue-layer

-      NAME object that internally keeps a reference to a NAME object

-      produced by the underlying mechanism, but a pluggable mechglue

-      could not expect two different mechanisms to be able to share

-      their internal NAME objects.  A clever implementer can work around

-      this by exporting the one mechanism's MN and then re-importing

-      using the target mechanism's GSS_Import_name() service function.

-

-   o  It must be possible for the credential inquiry functions (e.g.,

-      GSS_Inquire_cred() and GSS_Inquire_cred_by_mech()) to return a

-      cred_name that is an MN of a different mechanism than the

-      credential element being inquired.

-

-

-

-Zhu, et al.                Expires May 7, 2009                  [Page 8]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   Implementation support for this name type, with defaulted realm name

-   or with the PKU2U realm name is REQUIRED, but it is OPTIONAL for use

-   with any other realm names.

-

-5.5.  GSS_C_NT_ANONYMOUS

-

-   This is a generic GSS-API name-type.  Implementation support for this

-   name type is OPTIONAL.  See Section 6.1 for more information.

-

-   See [RFC2743] and [RFC2744] for more information about this name

-   type.

-

-   The PKU2U mechanism only supports anonymous initiators, not

-   acceptors.

-

-   Implementation support for this name type is RECOMMENDED.

-

-5.6.  GSS_C_NT_HOSTBASED_SERVICE - Matching Host-based Principal Names

-      to Acceptor Certificates

-

-   Support for GSS_C_NT_HOSTBASED_SERVICE names is REQUIRED as described

-   herein.

-

-   The query form of this name type is as per-RFC2743.  The canonical

-   and exported name token forms are as per-RFC1964.  The display form

-   of this name type is left unspecified, but should either be as per-

-   RFC2743 or the same as the display form for

-   GSS_KRB5_NT_PRINCIPAL_NAME [RFC1964].

-

-   Initiators using names of type GSS_C_NT_HOSTBASED_SERVICE to identify

-   target acceptors represent these names as Kerberos V principal names

-   as per [RFC1964] but with a well-known realm name of "WELLKNOWN:

-   PKU2U" (see Section 5.4).

-

-   Acceptors match such names to acceptor certificates as follows.

-   Initiators then match the certificate chosen by the acceptor in the

-   same manner.

-

-   Initiators can also assert host-based service names as the initiator

-   name.  In this case acceptors MUST also apply the matching rules

-   below, in order, to validate the initiator's assertion.

-

-   1.  If there is an out-of-band binding of the peer's host-based

-       service name to its certificate, then the certificate matches.

-

-   2.  If the peer has a certificate with an id-pkinit-san subject

-       alternative name matching the initiator-provided acceptor name,

-       then the X.509 certificate matches.

-

-

-

-Zhu, et al.                Expires May 7, 2009                  [Page 9]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   3.  If a X.509 certificate has a dNSName SAN that matches the

-       hostname part of the host-based service principal name, and

-       either the anyExtendedKeyUsage extended key usage (EKU), or no

-       EKU is present, or an EKU is present which corresponds to the

-       service part of the host-based service principal name, then the

-       X.509 certificate matches.  The id-kp-serverAuth EKU SHALL be

-       considered to match the 'HTTP' service name.  (See Section 10,

-       IANA considerations, where the GSS-API service name registry is

-       extended to include an EKU for each service name.)

-

-   4.  Implementations SHOULD, subject to local configuration, allow

-       matches where the single-component cn of the DN of a X.509

-       certificate matches the hostname part of the host-based service

-       name, for some or all service names.  This feature is needed to

-       allow the use of existing X.509 web certificates.

-

-   Implementation support for this name type as an acceptor name is

-   REQUIRED.  Implementation support for this name type as an initiator

-   name is OPTIONAL.

-

-

-6.  The Protocol Description and the Context Establishment Tokens

-

-   The PKU2U mechanism is a GSS-API mechanism based on [RFC4120],

-   [RFC4556] and [RFC4121].

-

-   The per-message tokens of the PKU2U mechanism are the same as those

-   of the Kerberos V GSS-API mechanism [RFC4121].

-

-   The GSS_Pseudo_random() function [RFC4401] of the PKU2U is the same

-   as that of the Kerberos V GSS-API mechanism [RFC4402].

-

-   The PKU2U security context token exchange consists of KRB_AS_REQ and

-   KRB_AS_REP (and KRB_ERROR) Kerberos KDC PDUs (with no changes to

-   their ASN.1 description, but with other minor changes/requirements

-   described below) as context tokens, with the acceptor as the KDC,

-   followed by context tokens from [RFC4121] using the Kerberos V Ticket

-   PDU issued by the acceptor-as-KDC.  PKINIT [RFC4556] is the only

-   acceptable pre-authentication method in this document.  Caching the

-   ticket issued by the acceptor allows subsequent security context

-   exchanges between the same to peers to use a single context token

-   round-trip -- a "fast reconnect" feature.

-

-   PKU2U differs from Kerberos V with PKINIT in several minor ways as

-   follows (this is not a complete list):

-

-

-

-

-

-

-Zhu, et al.                Expires May 7, 2009                 [Page 10]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   o  KDC PDUs are not exchanged as usual in Kerberos, but wrapped as

-      [the first two] GSS-API context tokens.

-

-   o  PKU2U does not use KDC certificates.

-

-   o  PKU2U adds pa-data types for carrying the initiator's assertion of

-      its name and the targ_name passed to GSS_Init_sec_context().

-

-   PKU2U differs from the Kerberos V GSS-API mechanism in several ways:

-

-   o  KDC PDUs are not exchanged as described in [RFC4120], but wrapped

-      as GSS-API context tokens.

-

-   o  PKU2U allows the use of principal names matching PKI naming (see

-      Section 5).  PKU2U does support the use of Kerberos V naming, but

-      requires only support of Kerberos V naming to a limited extent

-      (full support is optional).

-

-   o  PKU2U adds an extension [GSS-EXTS] to the RFC4121 initial context

-      token for binding the AP-REQ to the AS exchange that precedes is

-      (that is, when the initiator has to request a ticket from the

-      acceptor).

-

-   o  The number of round-trips can vary.  If the initiator already has

-      a ticket for the acceptor then the context token exchange will be

-      half a round-trip or one round-trip, as per RFC4121.  Otherwise

-      one or two round-trips are added for the AS exchanges needed to

-      acquire a ticket.  Note that two AS exchanges may be required when

-      the initiator's initial choice of X.509 certificate does not match

-      the acceptor's trust anchors, in which case the acceptor SHOULD

-      reply with a KRB-ERROR with TD-TRUSTED-CERTIFIERS indicating what

-      the acceptor's trust anchors are, and then the initiator can

-      engage in a second AS exchange within the same GSS-API context.

-

-   To recapitulate, the acceptor and the initiator communicate by

-   tunneling the authentication service exchange messages through the

-   use of the GSS-API tokens and application traffic.  In the event of

-   security context token loss, message duplication, or out of order

-   message delivery, the security context MUST fail to establish.

-

-   All security context establishment tokens MUST follow the

-   InitialContextToken syntax defined in Section 3.1 of [RFC2743].

-   PKU2U is identified by the Objection Identifier (OID) id-kerberos-

-   pku2u.

-

-

-

-

-

-

-

-Zhu, et al.                Expires May 7, 2009                 [Page 11]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   The PKU2U OID is:

-

-   id-kerberos-pku2u ::=

-   { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)

-   pku2u(7) }

-

-   All context establishment tokens consist of some Kerberos V PDU or

-   another, prefixed with a two-octet token type ID, and the

-   InitialContextToken header (see above).

-

-   The innerToken described in section 3.1 of [RFC2743] and subsequent

-   GSS-API mechanism tokens have the following formats: it starts with a

-   two-octet token-identifier (TOK_ID), followed by a Kerberos message.

-   The TOK_ID values for the AS-REQ message and the AS-REP message are

-   defined in the table blow:

-

-           Token         TOK_ID Value in Hex

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

-         KRB_AS_REQ          05 00

-         KRB_AS_REP          06 00

-

-   The TOK_ID values for all other Kerberos messages are the same as

-   defined in [RFC4121].

-

-   It should be noted that by using anonymous PKINIT [KRB-ANON], PKU2U

-   can authenticate the acceptor without revealing the initiator's

-   identity

-

-6.1.  Context Token Derived from KRB_AS_REQ

-

-   When the initiator does not have a service ticket to the acceptor, it

-   requests a ticket from the acceptor instead of from the KDC by

-   constructing a KRB_AS_REQ PDU [RFC4120] and using it as the context

-   token, with a token type ID prefixed.  This will be the initiator's

-   initial context token, therefore it MUST also have the standard

-   header bearing the OID of the mechanism being used (in this case,

-   PKU2U's OID).

-

-   The initiator MUST NOT set any KDC options in the 'kdc-options' field

-   of the AS-REQ.

-

-   The 'realm' field of the AS-REQ MUST be set to the PKU2U well-known

-   PKU2U realm name ("WELLKNOWN:PKU2U" [KRB-NAMING].

-

-   If the initiator wishes to assert a name of type

-   GSS_KRB5_NT_PRINCIPAL_NAME or GSS_C_NT_HOSTBASED_SERVICE, then it

-   MUST set the 'cname' field of the AS-REQ accordingly if and only if

-   the realm name part of the given name object is defaulted or the

-

-

-

-Zhu, et al.                Expires May 7, 2009                 [Page 12]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   well-known PKU2U realm name.  Otherwise the initiator MUST add a pa-

-   data element (see below) stating the name that the initiator wishes

-   to assert, it MUST set the cname field to the NULL principal name as

-   defined in Section 4.

-

-   If the targ_name passed to GSS_Init_sec_context() is of type

-   GSS_C_NT_HOSTBASED_NAME then the initiator sets the 'sname' field of

-   the AS-REQ to match the parsed name as per [RFC4121].  If the target

-   name does not have a representation as a Kerberos principal name per

-   [RFC1964], then the initiator MUST add a pa-data element (see below)

-   stating the given targ_name and the initiator MUST set the 'sname'

-   field of the AS-REQ to the NULL principal name as defined in

-   Section 4.

-

-   The padata used to convey initiator and target names is of type

-   PA_PKU2U_NAME <136> and it's value consists of the DER

-   [CCITT.X680.2002] [CCITT.X690.2002] encoding of the ASN.1 type

-   InitiatorNameAssertion (with explicit tagging).

-

-   InitiatorName ::= CHOICE {

-       -- -1 -> certificate DN

-       -- 0..16384 -> subjectAltName named by

-       --             this index

-       sanIndex INTEGER (-1..16384), -- DN or SAN

-       nameNotInCert GeneralName,    -- name not present in cert

-                                     -- (see RFC5280 for definition

-                                         of GeneralName)

-       ...

-   }

-

-   TargetName ::= CHOICE {

-       exportedTargName OTCET STRING, -- exported krb5 name

-       generalName [0] GeneralName,   -- all other PKI names

-                                      -- (tagged to distinguish

-                                      -- from nameNotInCert

-                                      -- choice of InitiatorName)

-       ...

-   }

-

-   InitiatorNameAssertion ::= SEQUENCE {

-       initiatorName InitiatorName OPTIONAL,

-       targetName TargetName OPTIONAL,

-       ...

-   }

-

-   The initiatorName, if present, contains the initiator's name.  The

-   initiator can fill out either the sanIndex field or the nameNotInCert

-   field to indicate the name of the initiator.

-

-

-

-Zhu, et al.                Expires May 7, 2009                 [Page 13]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   The sanIndex field, if present, is used to refer to either the

-   Distinguished Name or the SubjectAltName in the initiator's X.509

-   certificate.  A sanIndex value of -1 value refers to the initiator's

-   certificate's DN.  All other legal values of sanIndex refer to the

-   corresponding element of the SubjectAltName sequence.  A value of 0

-   means the first instance of GeneralName in the SubjectAltName

-   sequence, and 1 means the second, and so on.  If the sanIndex value

-   is equal or biger than the number of GeneralName elements in the

-   SubjectAltName, the security context establishment attempt MUST fail.

-

-   The nameNotInCert field, if present, contains the initiator's

-   GeneralName.

-

-   If an initiator name assertion is included, the acceptor MUST verify

-   that this asserted name is either present in the initiator's

-   certificate or otherwise bound to the initiator's certificate by out-

-   of-band provisioning (e.g., by a table lookup).  Failure to validate

-   the asserted initiator's name MUST cause GSS_Accept_sec_context() to

-   return an error and, optionally, to output a KRB_ERROR context token

-   as per-RFC4121.

-

-   The initiatorName field MUST NOT be present if the initiator is

-   anonymous or if the 'cname' field of the AS-REQ is not the NULL name

-   (see Section 4).

-

-   Target names passed to GSS_Init_sec_context() that can be represented

-   as Kerberos V principal names, namely, names of

-   GSS_KRB5_NT_PRINCIPAL_NAME and GSS_C_NT_HOSTBASED_SERVICE, MUST be

-   represented as the 'sname' field of the AS-REQ or as the

-   exportedTargName choice of TargetName (if the realm part is not the

-   PKU2U realm name).  The contents of the exportedTargName octet string

-   MUST be an exported name token for the Kerberos V mechanism

-   containing a Kerberos V principal name.

-

-   Other target names are represented as a generalName choice of

-   TargetName.  These may be present in an acceptor certificate, or

-   agreed out of band.

-

-   The acceptor MUST select an appropriate acceptor credential that

-   matches the AS-REQ's 'sname' (if not NULL) or the targetName provided

-   in the InitiatorNameAssertion, when present.

-

-   The targetName field MUST NOT be present if the 'sname' field of the

-   AS-REQ is not the NULL name.  The targetName field MUST be present if

-   the 'sname' field of the AS-REQ is the NULL name.

-

-   The PA_PKU2U_NAME padata SHOULD NOT be present when the initiatorName

-   and targetName both shouldn't be present.

-

-

-

-Zhu, et al.                Expires May 7, 2009                 [Page 14]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   Implementation note: the encrypted part of a PKU2U Ticket can be

-   anything at all since the only entity that will consumer a given

-   PKU2U Ticket is the same entity that issued it.  Implementers may

-   choose to use the traditional EncTicketPart ASN.1 type [RFC4120] and

-   DER encoding.

-

-6.2.  Context Token Derived from KRB_AS_REP

-

-   When the initiator's initial context token is a AS-REQ then the

-   acceptor MUST reply with either a KRB-ERROR token as per [RFC4121] or

-   a token derived from a KRB_AS_REP PDU [RFC4120] constructed to

-   respond to the initiator's KRB_AS_REQ.

-

-   The initiator MUST use PKINIT pre-authentication and the acceptor

-   MUST require it.  If the initiator does not use PKINIT pre-

-   authentication then the acceptor MUST respond with a KRB-ERROR and

-   indicate that PKINIT is required.

-

-   If the initiator's KRB_AS_REQ token is valid, and the asserted

-   initiator's name, if present, is bound with the initiator's

-   certificate, and the acceptor can select a certificate based on the

-   initiator's asserted targ_name, the acceptor then constructs a

-   KRB_AS_REP using PKINIT as described in [RFC4556], except that the

-   acceptor's certificate is used in the place of the KDC certificate.

-   If and only if the initiator's X.509 certficate is validated using

-   PKI, the acceptor SHOULD include an authorization element

-   AD_INITIAL_VERIFIED_CAS [RFC4556] in the returned ticket.  If an

-   InitiatorName is included in the PA_PKU2U_NAME padata in the request,

-   an authorization element of the type ad-pku2u-client-name <143> MUST

-   be included in the returned ticet and this authorization element

-   contains the DER encoded InitiatorName in the request.

-

-   The initiator then validates the KRB-AS-REP reply context token

-   according to Section 3.1.5 of [RFC4120] and Section 3.2.4 of

-   [RFC4556].  The inclusion of the EKU KeyPurposeId [RFC5280] id-

-   pkinit-KPKdc in the X.509 certificate in the response is not

-   applicable when PKU2U is used because there is no KDC involved in

-   this protocol.  The initiator MUST verify that the acceptor's

-   certificate is bound with the targ_name passed in to

-   GSS_Init_sec_context(), by verifying either the targ_name matches

-   with either the subject DN or one instance of the SubjectAltName name

-   in the acceptor's certificate, or otherwise the targ_name is bound

-   with the acceptor's certificate by out-of-band provisioning (e.g., by

-   a table lookup).  Failure to validate this name binding MUST cause

-   the authentication to be rejected.

-

-   The 'flags' field of the AS-REP MUST have only the 'initial' and

-   'pre-authent' flags set.

-

-

-

-Zhu, et al.                Expires May 7, 2009                 [Page 15]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   The 'authtime' field of the AS-REP MUST be set to the acceptor's

-   current time as it is when it formats the AS-REP.

-

-   Otherwise all other aspects of the AS-REP are as described in

-   [RFC4120].

-

-   The values of the tkt-vno, realm and 'sname' fields of the Ticket

-   issued by the acceptor are unspecified.  The initiator MUST NOT

-   examine them for correctness.  Cut-n-paste attacks are prevented by

-   the fact that PKU2U provides integrity protection for all cleartext

-   in Kerberos V PDUs used by PKU2U (and for the mechanism OID).

-

-6.3.  Context Tokens Imported from RFC4121

-

-   Once the initiator has a Kerberos V Ticket for the acceptor the

-   security context token exchange will continue with those of the

-   Kerberos V GSS-API mechanism [RFC4121] with the following

-   modifications:

-

-   o  The mechanism OID of PKU2U SHALL be used instead of that of the

-      Kerberos V GSS-API mechanism;

-

-   o  The 'crealm' field of the initiator's Authenticator MUST be set to

-      the PKU2U realm name and if the 'cname" field is the NULL

-      principal name, an authorization element of the type ad-pku2u-

-      client-name <143> MUST be included in the authenticator and this

-      authorization element contains the DER encoded InitiatorName in

-      the AS-REQ based on which the ticket was obtained;

-

-   o  The sub-session key MUST be used in the initiator's Authenticator;

-

-   o  The contents of the encrypted part of the Ticket can be

-      implementation specific since the only entity consuming it will be

-      the same entity that issues it;

-

-   o  If the initiator's initial context token is a KRB_AS_REQ token

-      (i.e., not KRB_AP_REQ token), then the Exts field in the

-      Authenticator of the KRB_AP_REQ-derived token MUST contain an

-      extension [GSS-EXTS] of the type GSS_EXTS_FINISHED <2> as defined

-      next in this section.

-

-   The 'cusec', 'ctime', 'seq-number' and 'authorization-data' fields of

-   the Authenticator are set as per [RFC4121] and [RFC4120].

-

-   The 'cksum' field of the Authenticator MUST be set as per [RFC4121].

-   The extension data of the GSS_EXTS_FINISHED extension type [GSS-EXTS]

-   contains the DER encoding of the ASN.1 structure KRB-FINISHED.

-

-

-

-

-Zhu, et al.                Expires May 7, 2009                 [Page 16]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   GSS_EXTS_FINISHED             2

-       --- The type for the checksum extension.

-

-   KRB-FINISHED ::= SEQUENCE {

-       gss-mic [1] Checksum,

-           -- Contains the checksum (RFC3961) of the GSS-API tokens

-           -- that have been exchanged between the initiator and the

-           -- acceptor and prior to the containing AP-REQ GSS-API token.

-           -- The checksum is performed over the GSS-API

-           -- context tokens in the order that the tokens were sent.

-        ...

-   }

-

-   The gss-mic field contains a Kerberos checksum [RFC3961] that is

-   computed over all the preceding context tokens of this GSS-API

-   context (including the InitialContextToken header), concatenated in

-   chronological order (note that GSS-API context token exchanges are

-   synchronous).  The checksum type is the required checksum type of the

-   enctype of the subkey in the authenticator, the protocol key for the

-   checksum operation is the authenticator subkey, and the key usage

-   number is KEY_USAGE_FINISHED <41>.

-

-   The acceptor MUST process the KRB_AP_REQ token as usual for RFC4121,

-   except that if the context token exchange included an AS exchange,

-   then the acceptor MUST also validate the GSS_EXTS_FINISHED and return

-   an error if it is not valid or not present.  But if a KRB_AP_REQ

-   context token is the initial context token then the acceptor MUST

-   return an error if GSS_EXTS_FINISHED is present.

-

-   The GSS_EXTS_FINISHED (along with the ticket) binds the second part

-   of the context token exchange to the first, and it binds the pa-data

-   used in the request as well (this needs to be done because PKINIT

-   does not bind pa-data other than PKINIT pa-data from the request).

-   GSS_EXTS_FINISHED also protects all otherwise unauthenticated

-   plaintext in Kerberos V PDUs.  Note that GSS_EXTS_FINISHED also

-   protects the mechanism OID in the InitialContextToken header.

-

-   The acceptor MUST verify that the ad-pku2u-client-name authorization

-   element is present in the authenticator if and only there is an

-   authorization element of the same type in the ticket and the values

-   of these two elements MUST match exactly based on bit-wise

-   comparison.

-

-

-7.  Guidelines for Credentials Selection

-

-   If a peer, either the initiator or the acceptor, has multiple pairs

-   of public-key private keys and certificates, a choice is to be made

-

-

-

-Zhu, et al.                Expires May 7, 2009                 [Page 17]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   in choosing the best fit.  The trustedCertifiers field in the PA-PK-

-   AS-REQ structure [RFC4556] SHOULD be filled by the initiator, to

-   provide hints for guiding the selection of an appropriate certificate

-   chain by the acceptor.

-

-   If the initiator's X.509 certificate cannot be validated according to

-   [RFC5280], the acceptor SHOULD send back the TD-TRUSTED-CERTIFIERS

-   structure [RFC4556] that provides hints for guiding the selection of

-   an appropriate certificate by the initiator.  In this case

-   GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED, and the

-   initiator gets to try again in its subsequent AS-REQ token.

-

-   The GSS-API does not provide a programming interface to make this

-   credential selection interactive, though implementers may provide

-   methods for user interaction related to credential selection and

-   acquisition (e.g., name and password/PIN prompts).  Whenever the

-   execution context allows for direct interaction of the mechanism with

-   the user then it is RECOMMENDED that implementations interact with

-   the user to select a credential whenever multiple credentials are

-   equally usable and no other mechanism is available to inform the

-   credential selection.

-

-   If the certificates cannot be selected interactively, multiple

-   certificates are equally usable, and there is no other mechanism

-   available for credential selection, then it is RECOMMENDED that

-   initiators fail the context.  Users should be able to retry using a

-   specific credential (this requires that distinct credentials have

-   distinct names that can be used to acquire each credential

-   separately).

-

-

-8.  Security Considerations

-

-   The security considerations in [RFC4120], [RFC4121], [RFC4556] and

-   [RFC5280] apply here.  This mechanism relaxes some requirements of

-   PKINIT and adds a device for protecting otherwise unauthenticated

-   plaintext in the protocol (see Section 6.3) -- it is crucial that

-   this device be faithfully implemented.  It is also crucial that both

-   the initiator and the acceptor MUST be able to verify the binding

-   between the signing key and the asserted identity.

-

-   Note that PKU2U is just as susceptible to replays of AP-REQs as the

-   traditional Kerberos V GSS-API mechanism [RFC4121], though only when

-   using an AP-REQ as the initial security context token.  It is

-   important, therefore, to use a replay cache to detect replays.

-

-

-

-

-

-

-Zhu, et al.                Expires May 7, 2009                 [Page 18]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-9.  Acknowledgements

-

-   The authors would like to thank Jeffrey Hutzelman for his insightful

-   comments on the earlier revisions of this document.

-

-   In addition, the following individuals have provided review comments

-   for this document: Sam Hartman, Leif Johansson, Olga Kornievskaia,

-   Martin Rex, and Sunil Gottumukkala.

-

-   Ari Medvinsky provided help in editing the initial revisions of this

-   document.

-

-   The text for the DN mapping is compiled from the email discussions

-   among the following individuals: Howard Chu, Martin Rex, Jeffrey

-   Hutzelman, Kevin Coffman, Henry B. Hotz, Leif Johansson, and Olga

-   Kornievskaia.  Howard and Jeffery clearly illustrated the challenges

-   in creating a unique mapping, while Nicolas and Martin demonstrated

-   the relevance and interactions to GSS-API and Kerberos.

-

-

-10.  IANA Considerations

-

-   This document defines the PKU2U realm and the place-holder well-known

-   principal name.  The IANA registry for the reserved names should be

-   updated to reference this document.  Two entries are added: one entry

-   for the well-known realm "WELLKNOWN:PKU2U", and another for the well-

-   known principal name "WELLKNOWN/NULL".

-

-   This document defines GSS_EXTS_FINISHED extension type.  The

-   corresponding IANA registry [GSS-EXTS] need to be updated to

-   reference this document.  The following single registration should be

-   added in the registry for "Kerberos V GSS-API mechanism extension

-   types": 2, "GSS-API token checksum", "Extension to provide a checksum

-   for GSS-API tokens", the RFC # of this document.

-

-   This document also instructs the IANA to extend the "SMI Security for

-   Name System Designators Codes (nametypes)" registry to include an OID

-   for each registration, and to allocate OIDs for the following GSS-API

-   name-types in that registry:

-   o  gss-distinguished-name (GSS_C_NT_DN)

-   o  gss-hostname (GSS_C_NT_HOSTNAME)

-   o  gss-IP-address (GSS_C_NT_IP_ADDR)

-   o  gss-e-mail-address (GSS_C_NT_EMAIL_ADDR)

-

-

-11.  Normative References

-

-   [CCITT.X680.2002]

-

-

-

-Zhu, et al.                Expires May 7, 2009                 [Page 19]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-              International International Telephone and Telegraph

-              Consultative Committee, "Abstract Syntax Notation One

-              (ASN.1): Specification of basic notation",

-              CCITT Recommendation X.680, July 2002.

-

-   [CCITT.X690.2002]

-              International International Telephone and Telegraph

-              Consultative Committee, "ASN.1 encoding rules:

-              Specification of basic encoding Rules (BER), Canonical

-              encoding rules (CER) and Distinguished encoding rules

-              (DER)", CCITT Recommendation X.690, July 2002.

-

-   [GSS-EXTS]

-              Emery, S., "Kerberos Version 5 GSS-API Channel Binding

-              Hash Agility", draft-ietf-krb-wg-gss-cb-hash-agility (work

-              in progress), 2007.

-

-   [KRB-ANON]

-              Zhu, L. and P. Leach, "Kerberos Anonymity Support",

-              draft-ietf-krb-wg-anon (work in progress), 2007.

-

-   [KRB-NAMING]

-              Zhu, L., "Additional Kerberos Naming Constraints",

-              draft-ietf-krb-wg-naming (work in progress), 2007.

-

-   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet

-              text messages", STD 11, RFC 822, August 1982.

-

-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",

-              STD 13, RFC 1034, November 1987.

-

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

-              RFC 1964, June 1996.

-

-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

-              Requirement Levels", BCP 14, RFC 2119, March 1997.

-

-   [RFC2743]  Linn, J., "Generic Security Service Application Program

-              Interface Version 2, Update 1", RFC 2743, January 2000.

-

-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :

-              C-bindings", RFC 2744, January 2000.

-

-   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,

-              "Internationalizing Domain Names in Applications (IDNA)",

-              RFC 3490, March 2003.

-

-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for

-

-

-

-Zhu, et al.                Expires May 7, 2009                 [Page 20]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-              Kerberos 5", RFC 3961, February 2005.

-

-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The

-              Kerberos Network Authentication Service (V5)", RFC 4120,

-              July 2005.

-

-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos

-              Version 5 Generic Security Service Application Program

-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,

-              July 2005.

-

-   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API

-              Extension for the Generic Security Service Application

-              Program Interface (GSS-API)", RFC 4401, February 2006.

-

-   [RFC4402]  Williams, N., "A Pseudo-Random Function (PRF) for the

-              Kerberos V Generic Security Service Application Program

-              Interface (GSS-API) Mechanism", RFC 4402, February 2006.

-

-   [RFC4514]  Zeilenga, K., "Lightweight Directory Access Protocol

-              (LDAP): String Representation of Distinguished Names",

-              RFC 4514, June 2006.

-

-   [RFC4517]  Legg, S., "Lightweight Directory Access Protocol (LDAP):

-              Syntaxes and Matching Rules", RFC 4517, June 2006.

-

-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial

-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.

-

-   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,

-              Housley, R., and W. Polk, "Internet X.509 Public Key

-              Infrastructure Certificate and Certificate Revocation List

-              (CRL) Profile", RFC 5280, May 2008.

-

-

-Authors' Addresses

-

-   Larry Zhu

-   Microsoft Corporation

-   One Microsoft Way

-   Redmond, WA  98052

-   US

-

-   Email: lzhu@microsoft.com

-

-

-

-

-

-

-

-Zhu, et al.                Expires May 7, 2009                 [Page 21]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-   Jeffery Altman

-   Secure Endpoints

-   255 W 94th St

-   New York, NY  10025

-   US

-

-   Email: jaltman@secure-endpoints.com

-

-

-   Nicolas Williams

-   Sun Microsystems

-   5300 Riata Trace Ct

-   Austin, TX  78727

-   US

-

-   Email: Nicolas.Williams@sun.com

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Zhu, et al.                Expires May 7, 2009                 [Page 22]

-

-Internet-Draft                    PKU2U                    November 2008

-

-

-Full Copyright Statement

-

-   Copyright (C) The IETF Trust (2008).

-

-   This document is subject to the rights, licenses and restrictions

-   contained in BCP 78, and except as set forth therein, the authors

-   retain all their rights.

-

-   This document and the information contained herein are provided on an

-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS

-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF

-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-Intellectual Property

-

-   The IETF takes no position regarding the validity or scope of any

-   Intellectual Property Rights or other rights that might be claimed to

-   pertain to the implementation or use of the technology described in

-   this document or the extent to which any license under such rights

-   might or might not be available; nor does it represent that it has

-   made any independent effort to identify any such rights.  Information

-   on the procedures with respect to rights in RFC documents can be

-   found in BCP 78 and BCP 79.

-

-   Copies of IPR disclosures made to the IETF Secretariat and any

-   assurances of licenses to be made available, or the result of an

-   attempt made to obtain a general license or permission for the use of

-   such proprietary rights by implementers or users of this

-   specification can be obtained from the IETF on-line IPR repository at

-   http://www.ietf.org/ipr.

-

-   The IETF invites any interested party to bring to its attention any

-   copyrights, patents or patent applications, or other proprietary

-   rights that may cover technology that may be required to implement

-   this standard.  Please address the information to the IETF at

-   ietf-ipr@ietf.org.

-

-

-

-

-

-

-

-

-

-

-

-Zhu, et al.                Expires May 7, 2009                 [Page 23]

-

-

diff --git a/doc/standardisation/draft-zhu-spnego-2478bis-00.txt b/doc/standardisation/draft-zhu-spnego-2478bis-00.txt
deleted file mode 100644
index d696f063e..000000000
--- a/doc/standardisation/draft-zhu-spnego-2478bis-00.txt
+++ /dev/null
@@ -1,1155 +0,0 @@
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                             K. Jaganathan
-Obsoletes: 2478 (if approved)                                    R. Ward
-Expires: April 18, 2005                            Microsoft Corporation
-                                                        October 18, 2004
-
-
-
-         The Simple and Protected GSS-API Negotiation Mechanism
-                      draft-zhu-spnego-2478bis-00
-
-
-Status of this Memo
-
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-
-   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."
-
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-   This Internet-Draft will expire on April 18, 2005.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).
-
-
-Abstract
-
-
-   This document specifies a security negotiation mechanism for the
-   Generic Security Service Application Program Interface (GSS-API)
-   which is described in RFC 2743.
-
-
-   This mechanism allows negotiating and choosing one security mechanism
-   from a common set of security mechanisms shared by GSS-API peers.
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                 [Page 1]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-   Once the common security mechanism is identified, the security
-   mechanism MAY also negotiate mechanism-specific options during its
-   context establishment, but that will be inside the mechanism tokens,
-   and invisible to this protocol.
-
-
-Table of Contents
-
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
-   3.  Negotiation Model  . . . . . . . . . . . . . . . . . . . . . .  5
-     3.1   Negotiation Description  . . . . . . . . . . . . . . . . .  5
-     3.2   Negotiation Procedure  . . . . . . . . . . . . . . . . . .  6
-   4.  Data Elements  . . . . . . . . . . . . . . . . . . . . . . . . 11
-     4.1   Mechanism Type . . . . . . . . . . . . . . . . . . . . . . 11
-     4.2   Negotiation Tokens . . . . . . . . . . . . . . . . . . . . 11
-       4.2.1   negTokenInit . . . . . . . . . . . . . . . . . . . . . 12
-       4.2.2   negTokenResp . . . . . . . . . . . . . . . . . . . . . 13
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
-   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
-   A.  Changes since RFC2478  . . . . . . . . . . . . . . . . . . . . 17
-       Intellectual Property and Copyright Statements . . . . . . . . 18
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                 [Page 2]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-1.  Introduction
-
-
-   The GSS-API [RFC2743] provides a generic interface which can be
-   layered atop different security mechanisms such that if communicating
-   peers acquire GSS-API credentials for the same security mechanism,
-   then a security context MAY be established between them (subject to
-   policy).  However, GSS-API doesn't prescribe the method by which
-   GSS-API peers can establish whether they have a common security
-   mechanism.
-
-
-   The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
-   defined here is a pseudo-security mechanism, represented by the
-   object identifier iso.org.dod.internet.security.mechanism.snego
-   (1.3.6.1.5.5.2) which enables GSS-API peers to determine in-band
-   whether their credentials share common GSS-API security mechanism(s),
-   and if so, to invoke normal security context establishment for a
-   selected common security mechanism.  This is most useful for
-   applications that are based on GSS-API implementations which support
-   multiple security mechanisms.
-
-
-   The simple and protected GSS-API mechanism negotiation is based on
-   the following negotiation model: the initiator proposes one security
-   mechanism or a list of security mechanisms in its preference order
-   (favorite choice first), the acceptor (the target) either accepts the
-   proposed security mechanism, or chooses one from the offered list, or
-   rejects the proposed value(s).  The target then informs the initiator
-   of its choice.
-
-
-   In order to avoid an extra round trip, the initial security token of
-   the preferred mechanism for the initiator SHOULD be embedded in the
-   initial negotiation token (as defined in Section 4.2).  If the target
-   preferred mechanism matches the initiator's preferred mechanism, no
-   additional round trips may be incurred by using the negotiation
-   protocol.
-
-
-   The negotiation is protected and all the underlying mechanisms
-   offered by the initiator MUST be capable of integrity protection.
-
-
-   The Simple and Protected GSS-API Negotiation Mechanism uses the
-   concepts developed in the GSS-API specification [RFC2743].  The
-   negotiation data is encapsulated in context-level tokens.  Therefore,
-   callers of the GSS-API do not need to be aware of the existence of
-   the negotiation tokens but only of the new pseudo-security mechanism.
-   A failure in the negotiation phase causes a major status code to be
-   returned: GSS_S_BAD_MECH.
-
-
-
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                 [Page 3]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-2.  Conventions Used in This Document
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                 [Page 4]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-3.  Negotiation Model
-
-
-3.1  Negotiation Description
-
-
-   Each OID represents one GSS-API mechanism or one variant of it.
-
-
-   The first negotiation token sent by the initiator contains an ordered
-   list of mechanisms (in preference order, favorite choice first), and
-   OPTIONALLY the initial security token for the preferred mechanism of
-   the initiator (i.e.  the first of the list).
-
-
-   The target then processes the token from the initiator.  This will
-   result in one of three possible states (as defined in Section 4.2.2):
-   accept_completed, accept_incomplete, or reject.  A reject state will
-   terminate the negotiation.  An accept_completed state indicates that
-   not only was the initiator-selected mechanism acceptable to the
-   target, but that the initial token was sufficient to complete the
-   authentication.  An accept_incomplete state indicates that the target
-   has selected a different mechanism or the preferred mechanism is
-   acceptable, but this mechanism requires at least one additional
-   message to complete the authentication.  The target MAY produce a
-   context level token for a reject state.
-
-
-   The first negotiation token sent by the acceptor contains the result
-   of the negotiation (accept_completed, accept_incomplete or reject)
-   and, in case of accept, the agreed security mechanism.  It MUST also
-   include the response mechanism token to the initial mechanism token
-   from the initiator, when the first proposed mechanism of the
-   initiator has been selected and an initial mechanism token was
-   provided by the initiator.  However, if the initiator's preferred
-   mechanism is not possible, the target will not emit a response
-   mechanism token in the first reply.
-
-
-   The policy by which the target chooses a mechanism is an
-   implementation-specific local matter.  In the absence of other
-   policy, the target MUST choose the first mechanism in the list for
-   which valid credentials are available.
-
-
-   The first negotiation token is the negTokenInit message and all
-   subsequent negotiation tokens are the negTokenResp message, as
-   defined in Section 4.2.
-
-
-   The use of partially-established contexts (as indicated by the
-   prot_ready_state in [RFC2743]), either for this mechanism or
-   mechanisms negotiated using this mechanism, is prohibited.
-
-
-
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                 [Page 5]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-3.2  Negotiation Procedure
-
-
-   The negotiation procedure is summarized as follows:
-
-
-   (a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
-      but requests (either explicitly, with the negotiation mechanism,
-      or through accepting a default, when the default is the
-      negotiation mechanism) that the Simple and Protected GSS-API
-      Negotiation Mechanism is used;
-
-
-   (b) The initiator GSS-API implementation emits a negotiation token
-      containing a list of supported security mechanisms for the
-      credentials used for this context establishment, and OPTIONALLY an
-      initial security token for the first mechanism from that list
-      (i.e.  the preferred mechanism), and indicates
-      GSS_S_CONTINUE_NEEDED status;
-
-
-   (c) The GSS-API initiator application sends the token to the target
-      application;
-
-
-   (d) The GSS-API target application deposits the token through
-      invoking GSS_Accept_sec_context.  The target GSS-API application
-      will do one of the following:
-
-
-      (I) If the initiator's preferred mechanism is accepted by the
-         target, an initial token is included in the first token from
-         the initiator, no further mechanism token from the initiator is
-         needed for the chosen mechanism to establish the security
-         context, (e.g.  when the authentication mechanism is unilateral
-         or mutual authentication has been performed and involves a
-         single token in either direction), and the initiator has not
-         sent a MIC token (the output token of the GSS_GetMIC() call
-         [RFC2743], the input to GSS_GetMIC() is the OTCET STRING field
-         representing the MechTypes in the initial NegTokenInit token),
-         of the mechanism list, the acceptor will do one of the
-         following:
-
-
-         1) If the initiator's preferred mechanism is accepted and there
-            is no policy on the target such that a different mechanism
-            other than the initiator's preferred mechanism could have
-            been selected given a different list of mechanisms,
-            GSS_Accept_sec_context() MUST indicate GSS_S_COMPLETE and it
-            MUST produce a negotiation token with the accept_completed
-            state, and with no MIC of the mechanism list.  This is
-            referred in this document as the Safe to Omit MIC (SOMIC)
-            rule number 1.  The resulting negotiation token MUST include
-            the security token if one is returned by the selected
-            mechanism;
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                 [Page 6]
-
-
-         2) If the initiator's preferred mechanism is accepted and there
-            is policy exists on the target such that a different
-            mechanism other than the initiator's preferred mechanism
-            could have been selected given a different list of
-            mechanisms, GSS_Accept_sec_context() MUST indicate
-            GSS_S_CONTINUE_NEEDED with the accept_incomplete state, and
-            a MIC MUST be generated by the target.  This MIC is to be
-            verified by the initiator and the result will be sent back
-            to the acceptor.  This is referred in this document as the
-            Safe to Omit MIC (SOMIC) rule number 2.  The resulting
-            negotiation token MUST include the security token if one is
-            returned by the selected mechanism.
-
-
-         3) If there is a MIC token and it is correct,
-            GSS_Accept_sec_context() MUST indicate GSS_S_COMPLETE with
-            no output token; If there is an incorrect MIC token,
-            GSS_Accept_sec_context() must indicate GSS_S_BAD_MIC status,
-            OPTIONALLY returning a negotiation token with the reject
-            state.
-
-
-      (II) If the initiator's preferred mechanism is accepted, and an
-         initial token from this mechanism is sent by the initiator, but
-         a failure is returned by the chosen mechanism,
-         GSS_Accept_sec_context() MUST report the failure and the
-         mech_type output parameter indicates the selected mechanism.
-         The target MUST produce a negotiation token with the reject
-         state if the selected mechanism returns a response token (e.g.
-         a KRB_ERROR when the Kerberos Version 5 GSS-API mechanism is
-         chosen [GSSAPICFX]);
-
-
-      (III) If the initiator's preferred mechanism is accepted, and an
-         initial token from this mechanism is sent by the initiator, but
-         at last one more initiator token need to be transferred to
-         establish the context, GSS_Accept_sec_context() MUST indicate
-         GSS_S_CONTINUE_NEEDED status, returning a negotiation token
-         with the accept_incomplete state, the response mechanism token,
-         and no MIC token.
-
-
-      (IV) If the initiator's preferred mechanism is accepted, but no
-         initial token from this mechanism is sent by the initiator,
-         GSS_Accept_sec_context() MUST indicate GSS_S_CONTINUE_NEEDED
-         status, returning a negotiation token with the
-         accept_incomplete state, the selected mechanism, no response
-         mechanism token or MIC token.
-
-
-      (V) If a proposed mechanism is accepted, and it is not the
-         initiator's preferred mechanism, GSS_Accept_sec_context() MUST
-         indicate GSS_S_CONTINUE_NEEDED status, returning a negotiation
-         token with the accept_incomplete state, the selected mechanism,
-         no response mechanism token or MIC token.  The negotiation will
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                 [Page 7]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-         be the agreed security mechanism if the negotiation is
-         successful.
-
-
-   (e) The GSS-API target application returns the negotiation token to
-      the initiator application;
-
-
-   (f) The GSS-API initiator application deposits the token through
-      invoking GSS_Init_sec_context().  The initiator will do one of the
-      following:
-
-
-      (I) When the negotiation token carries an accept_completed result,
-         the initiator MUST do one of the following:
-
-
-         1) If the selected mechanism is the initiator's preferred
-            mechanism, the initiator SHALL NOT reject the negotiation if
-            no MIC token is present.  This is referred in this document
-            as the Safe to Omit MIC ("SOMIC") rule number 3.  The
-            initiator MUST deposit the security token if one is
-            included, GSS_Init_sec_context() MUST indicate
-            GSS_S_BAD_MECH status if the context is not established
-            after this GSS_Init_sec_context() call.  If a MIC token is
-            present, the initiator MUST verify it and a GSS_S_BAD_MIC
-            must be returned if the MIC is incorrect;
-
-
-         2) If the selected mechanism is not the initiator's preferred
-            mechanism, and there is no or an incorrect MIC token,
-            GSS_Init_sec_context() MUST indicate GSS_S_BAD_MIC status.
-            This is referred in this document as the Safe to Omit MIC
-            ("SOMIC") rule number 4.
-
-
-      (II) When the negotiation token carries a reject result without a
-         response security token, GSS_Init_sec_context() MUST indicate
-         GSS_S_BAD_MECH status;
-
-
-      (III) When the negotiation token carries a reject result with a
-         response security token, the initiator MUST deposit the
-         security token, and GSS_Init_sec_context() MUST indicate a
-         failure status reported by the underlying mechanism, and the
-         output mech_type indicates the selected mechanism;
-
-
-      (IV) When the negotiation token carries an accept_incomplete
-         result and further mechanism tokens from the acceptor must be
-         transferred in order to complete context establishment,
-         GSS_Init_sec_context() MUST indicate GSS_S_CONTINUE_NEEDED
-         status, returning an output token with the accept_incomplete,
-         and the selected mechanism's context level token;
-
-
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                 [Page 8]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-      (V) When the negotiation token carries an accept_incomplete
-         result, no further mechanism token need to be transferred from
-         the acceptor to complete the context establishment, the
-         initiator MUST do one of the following:
-
-
-         1) If a MIC token was included, the initiator MUST verify it
-            and GSS_Init_sec_context() MUST indicate GSS_S_BAD_MIC if
-            the MIC is incorrect; GSS_Init_sec_context() MUST indicate
-            GSS_S_COMPLETE and produce a negotiation with the
-            accept_completed state if the MIC is correct.  This is
-            referred in this document as the Safe to Omit MIC ("SOMIC")
-            rule number 5;
-
-
-         2) If no MIC token was present, GSS_Init_sec_context() MUST
-            indicate GSS_S_BAD_MIC statue, This is referred in this
-            document as the Safe to Omit MIC ("SOMIC") rule number 6.
-
-
-   (g) The initiator application then sends the output_token to the
-      target if one is returned.  The security context initialization is
-      then continued according to the standard GSS-API conventions for
-      the selected mechanism, where the tokens of the selected mechanism
-      are encapsulated until the GSS_S_COMPLETE is returned for both the
-      initiator and the target.  When no further mechanism token is
-      needed to be transferred and the context for the chosen mechanism
-      is established, the initiator and the acceptor will need to either
-      apply the "SOMIC" rules above and skip MIC generation and
-      verification, or generate and verify the MIC token to protect the
-      negotiation.
-
-
-   (h) When GSS_S_CONTINUE_NEEDED is returned, the mech_type output
-      parameter is not yet valid.  When GSS_S_COMPLETE is returned, the
-      mech_type output parameter indicates the selected mechanism.
-
-
-   Note that the *_req_flag input parameters for context establishment
-   are relative to the selected mechanism, as are the *_state output
-   parameters.  i.e., these parameters are not applicable to the
-   negotiation process per se.
-
-
-   On receipt of a negotiation token on the target side, a GSS-API
-   implementation that does not support negotiation would indicate the
-   GSS_S_BAD_MECH status as if a particular basic security mechanism had
-   been requested but was not supported.
-
-
-   When GSS_Acquire_cred is invoked with the negotiation mechanism as
-   desired_mechs, an implementation-specific default credential is used
-   to carry on the negotiation.  A set of mechanisms as specified
-   locally by the system administrator is then available for
-   negotiation.  If there is a desire for the caller to make its own
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                 [Page 9]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-   choice, then an additional API has to be used as defined in [PRTSTK].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                [Page 10]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-4.  Data Elements
-
-
-   The type definitions in this section assume an ASN.1 module
-   definition of the following form:
-
-
-      SPNEGOASNOneSpec {
-            iso(1) identified-organization(3) dod(6) internet(1)
-            security(5) mechanism(5) snego (2)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-
-      -- rest of definitions here
-
-
-      END
-
-
-   This specifies that the tagging context for the module will be
-   explicit and non-automatic.
-
-
-   The encoding of SPNEGO protocol messages shall obey the Distinguished
-   Encoding Rules (DER) of ASN.1 as described in [X690].
-
-
-4.1  Mechanism Type
-
-
-           MechType ::= OBJECT IDENTIFIER
-             -- OID represents each security mechanism as suggested by
-             -- [RFC2743]
-
-
-
-4.2  Negotiation Tokens
-
-
-   The syntax of the initial negotiation tokens follows the
-   InitialContextToken syntax defined in [RFC2743].  The security
-   mechanism of the initial negotiation token is identified by the
-   Object Identifier in Section 1.  All subsequent tokens are not
-   encapsulated in the above generic token framing.
-
-
-   This section specifies the syntax of initial and subsequent context
-   level tokens.
-
-
-           NegotiationToken ::= CHOICE {
-               negTokenInit    [0] NegTokenInit,
-               negTokenResp    [1] negTokenResp
-           }
-
-
-           MechTypeList ::= SEQUENCE OF MechType
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                [Page 11]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-4.2.1  negTokenInit
-
-
-           NegTokenInit ::= SEQUENCE {
-               mechTypes       [0] MechTypeList,
-               reqFlags        [1] ContextFlags  OPTIONAL,
-               mechToken       [2] OCTET STRING  OPTIONAL,
-               mechListMIC     [3] OCTET STRING  OPTIONAL,
-               ...
-           }
-
-
-           ContextFlags ::= BIT STRING {
-               delegFlag       (0),
-               mutualFlag      (1),
-               replayFlag      (2),
-               sequenceFlag    (3),
-               anonFlag        (4),
-               confFlag        (5),
-               integFlag       (6)
-           }
-
-
-   This is the message for the initial negotiation token.
-
-
-   mechTypes
-
-
-         This field contains one or more security mechanisms in the
-         preference order (favorite choice first) supported by the
-         initiator (as indicated in the field mechTypes).
-
-
-   reqFlags
-
-
-         This field, if present, contains the service options that are
-         requested to establish the context.  The context flags SHOULD
-         be filled in from the req_flags parameter of
-         GSS_Init_sec_context().  This field SHALL NOT influence the
-         outcome of the negotiation.
-
-
-   mechToken
-
-
-         This field, is present, contains an optimistic negotiation
-         response.
-
-
-   mechListMIC
-
-
-         This field, if present, contains the result of a GSS_GetMIC()
-         [RFC2743] of the MechTypes field in the initial NegTokenInit
-         token.  It allows verifying that the list initially sent by the
-         initiator has been received unmodified by the target.
-
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                [Page 12]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-4.2.2  negTokenResp
-
-
-               NegTokenResp ::= SEQUENCE {
-                   negResult       [0] ENUMERATED {
-                       accept_completed    (0),
-                       accept_incomplete   (1),
-                       reject              (2)
-                       },
-                   supportedMech   [1] MechType      OPTIONAL,
-                   responseToken   [2] OCTET STRING  OPTIONAL,
-                   mechListMIC     [3] OCTET STRING  OPTIONAL,
-                       -- used only by the acceptor
-                   ...
-               }
-
-
-   This is the message for all the subsequent tokens.
-
-
-   negResult
-
-
-         Result of the negotiation exchange, specified by the target.
-         This can be:
-
-
-         accept_completed
-            A security mechanism is selected, and the context is
-            established for the sender;
-
-
-         accept_incomplete
-            Further exchanges are necessary;
-
-
-         reject
-            The sender reject the proposed security mechanism(s).
-
-
-         accept_completed indicates that a context has been successfully
-         established, while the result accept_incomplete indicates that
-         additional token exchanges are needed.
-
-
-         For those targets that support piggybacking the initial
-         mechToken, an optimistic negotiation response is possible and
-         includes in that case a responseToken which MAY continue the
-         authentication exchange (e.g.  when mutual authentication has
-         been requested or when unilateral authentication requires
-         several round trips).  Otherwise the responseToken is used to
-         carry the tokens specific to the mechanism selected.
-
-
-         The mechListMIC, when present, is a MIC computed over the
-         MechTypes using the mechanism list field in the initial token
-         (encoded in DER).
-
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                [Page 13]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-   supportedMech
-
-
-         This field is present and only present in the first
-         negTokenResp token.  It is a choice from the mechanisms offered
-         by the initiator.
-
-
-   responseToken
-
-
-         This field, if present, contains the security token of the
-         selected mechanism.
-
-
-   mechListMIC
-
-
-         This field, if present, contains the result of a GSS_GetMIC()
-         [RFC2743] of the MechTypes field in the initial NegTokenInit
-         token.  It allows verifying that the list initially sent by the
-         initiator has been received unmodified by the target.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                [Page 14]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-5.  Security Considerations
-
-
-   In order to produce the MIC for the mechanism list, the mechanism
-   MUST provide integirty protection.  When one of the mechanisms
-   proposed by the initiator does not support integrity protection, then
-   the negotiation is exposed to all threats a non secured service is
-   exposed.  In particular, an active attacker can force to use a
-   security mechanism which is not the common preferred one (when
-   multiple security mechanisms are shared between peers) but which is
-   acceptable anyway to the target, thus this mechanism does not support
-   selecting a mechanism that does not support integrity protection.
-
-
-   In any case, the communicating peers MAY be exposed to the denial of
-   service threat.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                [Page 15]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-6.  Acknowledgments
-
-
-   The authors wish to thank Paul Leach and Todd Stecher for theirs
-   comments and suggestions on earlier versions of this document.
-
-
-   Eric Baize and Denis Pinkas wrote the original SPNEGO specification
-   [RFC2478], of which some of the text has been retained in this
-   document.
-
-
-7  References
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
-              Negotiation Mechanism", RFC 2478, December 1998.
-
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-
-   [PRTSTK]   RFC-Editor: To be replaced by RFC number for draft-williams
-              -gssapi-stackable-pseudo-mechs.  Work in progress.
-              
-   [X690]     ASN.1 encoding rules: Specification of Basic Encoding Rules 
-              (BER), Canonical Encoding Rules (CER) and Distinguished 
-              Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 
-              ISO/IEC International Standard 8825-1:1998.
-
-
-Authors' Addresses
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-
-   EMail: lzhu@microsoft.com
-
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-
-   EMail: karthikj@microsoft.com
-
-
-
-   Richard B. Ward
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-
-   EMail: richardw@microsoft.com
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                [Page 16]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-Appendix A.  Changes since RFC2478
-
-
-      The following changes are designed to be compatible with an
-      incorrect implementation of RFC 2478 shipped in Windows 2000.  A
-      correct implementation of this protocol that negotiates the 2 leg
-      Kerberos GSS-API mechanism as the only available security
-      mechanism should be ale to interoperate with the implementation of
-      Windows 2000 when the mangled OID (1.2.840.48018.1.2.2) can be
-      used to identify Kerberos.
-
-
-      *  The negTokenTarg is changed to negTokenResp and it is now the
-         format for all subsequent negotiation messages.
-      *  negTokenInit is the message for the initial token and that
-         token only.
-      *  mechTypes in negTokenInit is no longer optional.
-      *  negResult is no longer optional in the negTokenResp token.
-      *  The initiator does not send the MIC token.
-      *  Add rules when it is safe to omit the MIC token.  Search for
-         SOMIC.
-
-
-      The following changes are to address the problems in RFC 2478.
-
-
-      *  reqFlags is not protected therefore it should not impact the
-         negotiation.
-      *  BER encoding is required.
-      *  GSS_GetMIC() input is clarified.
-      *  Nico's stackable pseudo mechanism draft is used to replace the
-         support APIs.
-      *  We no longer support negotiating mechanisms that do not provide
-         for integrity.  That support does not add security values but
-         blows up the interoperability test matrix.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                [Page 17]
-Internet-Draft       GSS-API Negotiation Mechanism          October 2004
-
-
-
-Intellectual Property Statement
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-Zhu, et al.              Expires April 18, 2005                [Page 18]
\ No newline at end of file
diff --git a/doc/standardisation/draft-zhu-ws-kerb-00.txt b/doc/standardisation/draft-zhu-ws-kerb-00.txt
deleted file mode 100644
index 95cb10332..000000000
--- a/doc/standardisation/draft-zhu-ws-kerb-00.txt
+++ /dev/null
@@ -1,528 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                     Microsoft Corporation
-Updates: 4120 (if approved)                             October 17, 2006
-Intended status: Standards Track
-Expires: April 20, 2007
-
-
-                       Kerberos for Web Services
-                          draft-zhu-ws-kerb-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 20, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document defines extensions to the Kerberos protocol and the
-   GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
-   exchange messages with the KDC using the GSS-API server as the proxy,
-   by encapsulating the Kerberos messages inside GSS-API tokens.  With
-   these extensions, Kerberos is suitable for securing communication
-   between the client and web services over the Internet.
-
-
-
-
-Zhu                      Expires April 20, 2007                 [Page 1]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
-   3.  GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . . 3
-   4.  Addresses in Tickets  . . . . . . . . . . . . . . . . . . . . . 6
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
-   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
-   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
-   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                      Expires April 20, 2007                 [Page 2]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-1.  Introduction
-
-   The Kerberos [RFC4120] pre-authentication framework [KRB-PAFW]
-   promises minimal or no exposure of weak client keys and strong client
-   authentication.  The Kerberos support of anonymity [KRB-ANON]
-   provides for privacy.  These advancements make Kerberos suitable over
-   the Internet.
-
-   The traditional client-push Kerberos protocol does not work well in
-   the Web services environments where the KDC is not accessible to the
-   client, but is accessible to the web server.  For example, the KDC is
-   commonly placed behind a firewall together with the application
-   server.  The lack of accessibility to the KDC by the client could
-   also occur are when the client does not have an IP address prior to
-   authenticating to an access point.
-
-   Generic Security Service Application Program Interface (GSS-API)
-   [RFC2743] allows security mechanisms exchange arbitrary messages
-   between the client and the server via the application traffic,
-   independent of the underlying transports.  A protocol based on
-   [RFC4121] is thus defined to allow the GSS-API client to exchange
-   Kerberos messages with the KDC by using the GSS-API server as the
-   proxy.  The server-pull model defined in this specification is
-   benefical for clients with limited processing power such as mobile
-   devices, or when the client and the server message exchange has high
-   network latency.
-
-           Client <---------> WS-KERB proxy <----------> KDC
-
-   The Kerberos client MUST use a pre-authentication mechanism such as
-   FAST [KRB-PAFW] to avoid exposure of long term client keys to the
-   server, before and after the server is authenticated, and hide the
-   client identity from adversary who can eavesdrop the application
-   traffic if such level of privacy is desirable.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  GSS-API Encapsulation
-
-   The mechanism Objection Identifier (OID) for GSS-API WS-KERB, in
-   accordance with the mechanism proposed by [RFC4178] for negotiating
-   protocol variations, is id-kerberos-ws:
-
-
-
-Zhu                      Expires April 20, 2007                 [Page 3]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-      id-kerberos-ws ::=
-        { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
-          webService(6) }
-
-   The first token of the GSS-API WS-KERB mechanism MUST have the
-   generic token framing described in section 3.1 of [RFC2743] with the
-   mechanism OID being id-kerberos-ws, and any subsequent GSS-API WS-
-   KERB token MUST NOT have this framing.
-
-   The GSS-API WS-KERB mechanism MUST always provide server
-   authentication, even if the client does not ask for it.  When server-
-   authentication is performed, the GSS-API server will always send back
-   an AP-REP, and as described later in this section this mechanism
-   provides integrity protection for all client-server proxy message
-   exchanges.
-
-   The innerToken described in section 3.1 of [RFC2743] and subsequent
-   GSS-API tokens have the following formats: it starts with a two-octet
-   token-identifier (TOK_ID), followed by a WS-KERB message or a
-   Kerberos message.
-
-
-             Token/Message       TOK_ID Value in Hex
-           -----------------------------------------
-             WS_KRB_PROXY         05 01
-
-   Only one WS-KERB specific message, namely the WS_KRB_PROXY message,
-   is defined in this document.  The TOK_ID values for [RFC4120]
-   Kerberos messages are the same as those defined for the GSS-API
-   Kerberos mechanism [RFC4121].
-
-   The message of the WS_KRB_PROXY type is defined as a WS-KRB-HEADER
-   structure immediately followed by a Kerberos message.  The Kerberos
-   message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, or a KRB-
-   ERROR as defined in [RFC4120].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                      Expires April 20, 2007                 [Page 4]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-           WS-KRB-HEADER ::= SEQUENCE {
-               pvno            [1] INTEGER (5) ,
-               msg-type        [2] INTEGER (23),
-               proxy-data      [3] ProxyData,
-               ...
-           }
-
-           ProxyData :: = SEQUENCE {
-               realm           [1] Realm,
-               cookie          [3] OCTET STRING OPTIONAL,
-                  -- opaque data, if sent by the server,
-                  -- MUST be copied by the client unchanged into
-                  -- the next WS-KERB message.
-               ...
-           }
-
-
-   The WS-KRB-HEADER structure and all the Kerberos messages MUST be
-   encoded using Abstract Syntax Notation One (ASN.1) Distinguished
-   Encoding Rules (DER) [X680] [X690].
-
-   The GSS-API WS-KERB client fills out the realm field in the ProxyData
-   of the first request with the client realm.  If the client does not
-   know the client realm [REFERALS], it MUST fill it out using the
-   client's default realm name such as the realm of the client host.
-   Typically the Kerberos message in the first WS_KRB_PROXY message from
-   the client is an AS-REQ message.
-
-   Upon receipt of the WS_KRB_PROXY message, the GSS-API WS-KERB server
-   MUST use the proxy-data in the message from the client to locate the
-   KDC and sends the encapsulated Kerberos message to that KDC.  In
-   order to reduce the number of roundtrips between the client and the
-   server, the server SHOULD process any message exchange with the KDC
-   if the exchange is unauthenticated, such as client-referral message
-   exchange [REFERALS].  If the server can not process the KDC response
-   by itself, for example when the knowledge of the client keys is
-   required, it sends back to the client the KDC reply message
-   encapsulated in a WS_KRB_PROXY message.  The server MUST fill out the
-   realm name whose KDC produced the response.  The server SHOULD use
-   the XKDC mechanism described in [KRB-PAFW] to allow the client's KDC
-   to obtain a service ticket to the server, thus further reduce the
-   number of roundtrips between the GSS-API client and the GSS-API
-   server.  The GSS-API server can send opaque data in the cookie field
-   of the WS-KRB-HEADER structure in the server reply to the client, in
-   order to, for example, reduce the amount of state information kept by
-   the GSS-API server.  The content and the encoding of the cookie field
-   is a local matter of the server.  The client MUST copy the verbatim
-   cookie from the previous server response, when the cookie is present,
-
-
-
-Zhu                      Expires April 20, 2007                 [Page 5]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-   whenever it sends an additional WS-KRB-PROXY message to the server.
-   The client processes the KDC response, and fills out the realm name
-   it believes to whom the server should send the encapsulated Kerberos
-   message.
-
-   When the client obtains a service ticket, the client then sends a
-   KRB_AP_REQ message to the server, and proceed as defined in
-   [RFC4121].  A GSS-API authenticator extension [GSS-EXTS] MUST be sent
-   by the client.  The extension type is 2 and the content is the ASN.1
-   DER encoding of the type Checksum.  The checksum is performed over
-   all GSS-API messages as exchanged between the client and the server
-   before the KRB_AP_REQ message, and in the order of the exchange.  The
-   checksum type is the required checksum type for the enctype of the
-   subkey in the authenticator, the protocol key is the authenticator
-   subkey, and the key usage number is TBA-1.  The server MUST verify
-   this checksum in the GSS-API authenticator extension, then respond
-   with an AP-REP extension [GSS-EXTS].  The AP-REP extension type is 2
-   and the the content is the ASN.1 DER encoding of the type Checksum.
-   This checksum is performed over all GSS-API messages as exchanged
-   between the client and the server before the KRB_AP_REQ message, and
-   in the order of the exchange.  The checksum type is the required
-   checksum type for the enctype of the authenticator subkey in the
-   request, and the protocol key is the authenticator subkey, and the
-   key usage number is TBA-2.  The client MUST then verify this
-   checksum.
-
-
-4.  Addresses in Tickets
-
-   In WS-KERB, the machine sending requests to the KDC is the GSS-API
-   server and not the client.  As a result, the client should not
-   include its addresses in any KDC requests for two reasons.  First,
-   the KDC may reject the forwarded request as being from the wrong
-   client.  Second, in the case of initial authentication for a dial-up
-   client, the client machine may not yet possess a network address.
-   Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and
-   TGS-REQ requests SHOULD be blank and the caddr field of the ticket
-   SHOULD similarly be left blank.
-
-
-5.  Security Considerations
-
-   Similar to other network access protocols, WS-KERB allows an
-   unauthenticated client (possibly outside the security perimeter of an
-   organization) to send messages that are proxied to interior servers.
-
-   In a scenario where DNS SRV RR's are being used to locate the KDC,
-   WS-KERB is being used, and an external attacker can modify DNS
-
-
-
-Zhu                      Expires April 20, 2007                 [Page 6]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-   responses to the WS-KERB proxy, there are several countermeasures to
-   prevent arbitrary messages from being sent to internal servers:
-
-   1.  KDC port numbers can be statically configured on the WS-KERB
-       proxy.  In this case, the messages will always be sent to KDC's.
-       For an organization that runs KDC's on a static port (usually
-       port 88) and does not run any other servers on the same port,
-       this countermeasure would be easy to administer and should be
-       effective.
-
-   2.  The proxy can do application level sanity checking and filtering.
-       This countermeasure should eliminate many of the above attacks.
-
-   3.  DNS security can be deployed.  This countermeasure is probably
-       overkill for this particular problem, but if an organization has
-       already deployed DNS security for other reasons, then it might
-       make sense to leverage it here.  Note that Kerberos could be used
-       to protect the DNS exchanges.  The initial DNS SRV KDC lookup by
-       the proxy will be unprotected, but an attack here is at most a
-       denial of service (the initial lookup will be for the proxy's KDC
-       to facilitate Kerberos protection of subsequent DNS exchanges
-       between itself and the DNS server).
-
-
-6.  Acknowledgements
-
-   The server-proxy idea is based on the early revisions of this
-   document written by Jonathan Trostle, Michael Swift, Bernard Aboba
-   and Glen Zorn.
-
-   The rest of the ideas mostly came from hallway conversations between
-   the author and Nicolas Williams.
-
-
-7.  IANA Considerations
-
-   There is no IANA action required for this document.
-
-
-8.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-
-
-
-Zhu                      Expires April 20, 2007                 [Page 7]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
-              Simple and Protected Generic Security Service Application
-              Program Interface (GSS-API) Negotiation Mechanism",
-              RFC 4178, October 2005.
-
-   [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity 
-              Support", draft-ietf-krb-wg-anon, work in progress.
-
-
-   [KRB-PAFW] Zhu, etl, "Kerberos Pre-Authentication framework", 
-              draft-ietf-krb-wg-preauth-framework, work in progress.
-              
-   [GSS-EXTS] Emery, S., draft-ietf-krb-wg-gss-cb-hash-agility, work in 
-              progess.
-
-   [REFERALS] Raeburn, K., "Generating KDC Referrals to Locate Kerberos 
-              Realms", draft-ietf-krb-wg-kerberos-referrals, work in
-              progress.
-              
-   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
-              Information technology - Abstract Syntax Notation One
-              (ASN.1): Specification of basic notation.
-
-   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
-              Information technology - ASN.1 encoding Rules:
-              Specification of Basic Encoding Rules (BER), Canonical
-              Encoding Rules (CER) and Distinguished Encoding Rules
-              (DER).
-
-
-Author's Address
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                      Expires April 20, 2007                 [Page 8]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Zhu                      Expires April 20, 2007                 [Page 9]
-
-
diff --git a/doc/standardisation/draft-zhu-ws-kerb-01.txt b/doc/standardisation/draft-zhu-ws-kerb-01.txt
deleted file mode 100644
index 7fa7075d3..000000000
--- a/doc/standardisation/draft-zhu-ws-kerb-01.txt
+++ /dev/null
@@ -1,505 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                     Microsoft Corporation
-Updates: 4120 (if approved)                                 October 2006
-Intended status: Standards Track
-Expires: April 4, 2007
-
-
-                       Kerberos for Web Services
-                          draft-zhu-ws-kerb-01
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on April 4, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document defines extensions to the Kerberos protocol and the
-   GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
-   exchange messages with the KDC using the GSS-API acceptor as the
-   proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
-   With these extensions, Kerberos is suitable for securing
-   communication between the client and web services over the Internet.
-
-
-
-
-Zhu                       Expires April 4, 2007                 [Page 1]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
-   3.  GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . . 3
-   4.  Addresses in Tickets  . . . . . . . . . . . . . . . . . . . . . 6
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
-   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
-   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
-   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                       Expires April 4, 2007                 [Page 2]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-1.  Introduction
-
-   The Kerberos [RFC4120] pre-authentication framework [KRB-PAFW]
-   promises minimal or no exposure of weak client keys and strong client
-   authentication.  The Kerberos support of anonymity [KRB-ANON]
-   provides for privacy.  These advancements make Kerberos suitable over
-   the Internet.
-
-   The traditional client-push Kerberos protocol does not work well in
-   the Web services environments where the KDC is not accessible to the
-   client, but is accessible to the web server.  For example, the KDC is
-   commonly placed behind a firewall together with the application
-   server.  The lack of accessibility to the KDC by the client could
-   also occur are when the client does not have an IP address prior to
-   authenticating to an access point.
-
-   Generic Security Service Application Program Interface (GSS-API)
-   [RFC2743] allows security mechanisms exchange arbitrary messages
-   between the initiator and the acceptor via the application traffic,
-   independent of the underlying transports.  A protocol based on
-   [RFC4121] is thus defined to allow the GSS-API initiator to exchange
-   Kerberos messages with the KDC by using the GSS-API acceptor as the
-   proxy.  The acceptor-pull model defined in this specification is
-   benefical for initiators with limited processing power such as mobile
-   devices, or when the transport layer between the initiator and the
-   acceptor has high network latency.
-
-           Client --------- WS-KERB proxy ---------- KDC
-
-   The Kerberos client MUST avoid exposure of long term client keys to
-   the GSS-API acceptor, before and after the Kerberos server is
-   authenticated.  This can be accomplished by using Kerberos-FAST [KRB-
-   PAFW].  Furthermore, the initiator can use the anonymous option as
-   defined in Section 6.5.2 of [KRB-PAFW], to hide the client identity
-   from adversary who can eavesdrop the application traffic.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  GSS-API Encapsulation
-
-   The mechanism Objection Identifier (OID) for GSS-API WS-KERB, in
-   accordance with the mechanism proposed by [RFC4178] for negotiating
-
-
-
-Zhu                       Expires April 4, 2007                 [Page 3]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-   protocol variations, is id-kerberos-ws.
-
-      id-kerberos-ws ::=
-        { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
-          webService(6) }
-
-   The first token of the GSS-API WS-KERB mechanism MUST have the
-   generic token framing described in section 3.1 of [RFC2743] with the
-   mechanism OID being id-kerberos-ws, and any subsequent GSS-API WS-
-   KERB token MUST NOT have this framing.
-
-   The GSS-API WS-KERB mechanism MUST always provide mutual
-   authentication, even if the initiator does not ask for it.  When
-   mutual-authentication is performed, the GSS-API acceptor will always
-   send back an AP-REP, and as described later in this section this
-   mechanism provides integrity protection for all initiator-acceptor
-   proxy message exchanges.
-
-   The innerToken described in section 3.1 of [RFC2743] and subsequent
-   GSS-API tokens have the following formats: it starts with a two-octet
-   token-identifier (TOK_ID), followed by a WS-KERB message or a
-   Kerberos message.
-
-
-             Token/Message       TOK_ID Value in Hex
-           -----------------------------------------
-             WS_KRB_PROXY         05 01
-
-   Only one WS-KERB specific message, namely the WS_KRB_PROXY message,
-   is defined in this document.  The TOK_ID values for [RFC4120]
-   Kerberos messages are the same as those defined for the GSS-API
-   Kerberos mechanism [RFC4121].
-
-   The message of the WS_KRB_PROXY type is defined as a WS-KRB-HEADER
-   structure immediately followed by a Kerberos message.  The Kerberos
-   message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, or a KRB-
-   ERROR as defined in [RFC4120].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                       Expires April 4, 2007                 [Page 4]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-           WS-KRB-HEADER ::= SEQUENCE {
-               proxy-data      [1] ProxyData,
-               ...
-           }
-
-           ProxyData :: = SEQUENCE {
-               realm           [1] Realm,
-               cookie          [3] OCTET STRING OPTIONAL,
-                  -- opaque data, if sent by the acceptor,
-                  -- MUST be copied by the client unchanged into
-                  -- the next WS-KERB message.
-               ...
-           }
-
-
-   The WS-KRB-HEADER structure and all the Kerberos messages MUST be
-   encoded using Abstract Syntax Notation One (ASN.1) Distinguished
-   Encoding Rules (DER) [X680] [X690].
-
-   The GSS-API initiator fills out the realm field in the ProxyData of
-   the first request with the client realm.  If the client does not know
-   the client realm [REFERALS], it MUST fill it out using the client's
-   default realm name such as the realm of the client host.  Typically
-   the Kerberos message in the first WS_KRB_PROXY message from the
-   client is an AS-REQ message.
-
-   Upon receipt of the WS_KRB_PROXY message, the GSS-API WS-KERB
-   acceptor MUST use the proxy-data in the message from the client to
-   locate the KDC and sends the encapsulated Kerberos message to that
-   KDC.  Unless otherwise specified, the acceptor can locate the KDC per
-   Section 7.2.3.2 of [RFC4120].
-
-   In order to reduce the number of roundtrips between the initiator and
-   the acceptor, the acceptor SHOULD process any message exchange with
-   the KDC if the exchange is unauthenticated, such as client-referral
-   message exchange [REFERALS].  If the acceptor can not process the KDC
-   response by itself, for example when the knowledge of the client keys
-   is required, it sends back to the client the KDC reply message
-   encapsulated in a WS_KRB_PROXY message.  The acceptor MUST fill out
-   the realm name whose KDC produced the response.  The acceptor SHOULD
-   use the kdc-referrals option described in Section 6.5.2 of [KRB-PAFW]
-   to allow the KDC of the client's realm to obtain a service ticket
-   addressed to the acceptor, thus further reduce the number of
-   roundtrips between the GSS-API initiator and the GSS-API acceptor.
-   The GSS-API acceptor can send opaque data in the cookie field of the
-   WS-KRB-HEADER structure in the reply from the acceptor to the
-   initiator, in order to, for example, to facilitate state managements
-   on the GSS-API acceptor.  The content and the encoding of the cookie
-
-
-
-Zhu                       Expires April 4, 2007                 [Page 5]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-   field is a local matter of the acceptor.  The initiator MUST copy the
-   verbatim cookie from the previous acceptor response, when the cookie
-   is present, whenever it sends an additional WS-KRB-PROXY message to
-   the acceptor.  The client processes the KDC response, and fills out
-   the realm name it believes to whom the acceptor should send the
-   encapsulated Kerberos message.
-
-   When the client obtains a service ticket, the initiator then sends a
-   KRB_AP_REQ message to the acceptor, and proceed as defined in
-   [RFC4121].  A GSS-API authenticator extension [GSS-EXTS] MUST be sent
-   by the initiator.  The extension type is 2 and the content is the
-   ASN.1 DER encoding of the type Checksum.  The checksum is performed
-   over all GSS-API messages as exchanged between the initiator and the
-   acceptor before the KRB_AP_REQ message, and in the order of the
-   exchange.  The checksum type is the required checksum type for the
-   enctype of the subkey in the authenticator, the protocol key is the
-   authenticator subkey, and the key usage number is TBA-1.  The
-   acceptor MUST verify this checksum in the GSS-API authenticator
-   extension, then respond with an AP-REP extension [GSS-EXTS].  The AP-
-   REP extension type is 2 and the the content is the ASN.1 DER encoding
-   of the type Checksum.  This checksum is performed over all GSS-API
-   messages as exchanged between the initiator and the acceptor before
-   the KRB_AP_REQ message, and in the order of the exchange.  The
-   checksum type is the required checksum type for the enctype of the
-   authenticator subkey in the request, and the protocol key is the
-   authenticator subkey, and the key usage number is TBA-2.  The
-   initiator MUST then verify this checksum.
-
-
-4.  Addresses in Tickets
-
-   In WS-KERB, the machine sending requests to the KDC is the GSS-API
-   acceptor and not the initiator.  As a result, the initiator should
-   not include its addresses in any KDC requests for two reasons.
-   First, the KDC may reject the forwarded request as being from the
-   wrong client.  Second, in the case of initial authentication for a
-   dial-up client, the client machine may not yet possess a network
-   address.  Hence, as allowed by [RFC4120], the addresses field of the
-   AS-REQ and TGS-REQ requests SHOULD be blank and the caddr field of
-   the ticket SHOULD similarly be left blank.
-
-
-5.  Security Considerations
-
-   Similar to other network access protocols, WS-KERB allows an
-   unauthenticated client (possibly outside the security perimeter of an
-   organization) to send messages that are proxied to interior servers.
-
-
-
-
-Zhu                       Expires April 4, 2007                 [Page 6]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-   In a scenario where DNS SRV RR's are being used to locate the KDC,
-   WS-KERB is being used, and an external attacker can modify DNS
-   responses to the WS-KERB proxy, there are several countermeasures to
-   prevent arbitrary messages from being sent to internal servers:
-
-   1.  KDC port numbers can be statically configured on the WS-KERB
-       proxy.  In this case, the messages will always be sent to KDC's.
-       For an organization that runs KDC's on a static port (usually
-       port 88) and does not run any other servers on the same port,
-       this countermeasure would be easy to administer and should be
-       effective.
-
-   2.  The proxy can do application level sanity checking and filtering.
-       This countermeasure should eliminate many of the above attacks.
-
-   3.  DNS security can be deployed.  This countermeasure is probably
-       overkill for this particular problem, but if an organization has
-       already deployed DNS security for other reasons, then it might
-       make sense to leverage it here.  Note that Kerberos could be used
-       to protect the DNS exchanges.  The initial DNS SRV KDC lookup by
-       the proxy will be unprotected, but an attack here is at most a
-       denial of service (the initial lookup will be for the proxy's KDC
-       to facilitate Kerberos protection of subsequent DNS exchanges
-       between itself and the DNS server).
-
-
-6.  Acknowledgements
-
-   The acceptor-proxy idea is based on the early revisions of this
-   document written by Jonathan Trostle, Michael Swift, Bernard Aboba
-   and Glen Zorn.
-
-   The rest of the ideas mostly came from hallway conversations between
-   the author and Nicolas Williams.
-
-
-7.  IANA Considerations
-
-   There is no IANA action required for this document.
-
-
-8.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-
-
-Zhu                       Expires April 4, 2007                 [Page 7]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
-              Simple and Protected Generic Security Service Application
-              Program Interface (GSS-API) Negotiation Mechanism",
-              RFC 4178, October 2005.
-
-   [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity 
-              Support", draft-ietf-krb-wg-anon, work in progress.
-
-   [KRB-PAFW] Zhu, etl, "Kerberos Pre-Authentication framework", 
-              draft-ietf-krb-wg-preauth-framework, work in progress.
-              
-   [GSS-EXTS] Emery, S., draft-ietf-krb-wg-gss-cb-hash-agility, work in 
-              progess.
-
-   [REFERALS] Raeburn, K., "Generating KDC Referrals to Locate Kerberos 
-              Realms", draft-ietf-krb-wg-kerberos-referrals, work in
-              progress.
-              
-   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
-              Information technology - Abstract Syntax Notation One
-              (ASN.1): Specification of basic notation.
-
-   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
-              Information technology - ASN.1 encoding Rules:
-              Specification of Basic Encoding Rules (BER), Canonical
-              Encoding Rules (CER) and Distinguished Encoding Rules
-              (DER).
-
-
-Author's Address
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-Zhu                       Expires April 4, 2007                 [Page 8]
-
-Internet-Draft                   WS-KERB                    October 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Zhu                       Expires April 4, 2007                 [Page 9]
-
-
diff --git a/doc/standardisation/draft-zhu-ws-kerb-03.txt b/doc/standardisation/draft-zhu-ws-kerb-03.txt
deleted file mode 100644
index 7b091af41..000000000
--- a/doc/standardisation/draft-zhu-ws-kerb-03.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                     Microsoft Corporation
-Updates: 4120 (if approved)                                    J. Altman
-Intended status: Standards Track                        Secure Endpoints
-Expires: January 10, 2008                                   July 9, 2007
-
-
- Initial and Pass Through Authentication Using Kerberos V5 and the GSS-
-                              API (IAKERB)
-                          draft-zhu-ws-kerb-03
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on January 10, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   This document defines extensions to the Kerberos protocol and the
-   GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
-   exchange messages with the KDC using the GSS-API acceptor as the
-   proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
-   With these extensions a client can obtain Kerberos tickets for
-   services where the KDC is not accessible to the client, but is
-
-
-
-Zhu & Altman            Expires January 10, 2008                [Page 1]
-
-Internet-Draft                   IAKERB                        July 2007
-
-
-   accessible to the application server.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  GSS-API Encapsulation  . . . . . . . . . . . . . . . . . . . .  3
-   4.  Addresses in Tickets . . . . . . . . . . . . . . . . . . . . .  7
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
-     8.2.  Informative references . . . . . . . . . . . . . . . . . .  9
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
-   Intellectual Property and Copyright Statements . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Altman            Expires January 10, 2008                [Page 2]
-
-Internet-Draft                   IAKERB                        July 2007
-
-
-1.  Introduction
-
-   When authenticating using Kerberos V5, clients obtain tickets from a
-   KDC and present them to services.  This model of operation cannot
-   work if the client does not have access to the KDC.  For example, in
-   remote access scenarios, the client must initially authenticate to an
-   access point in order to gain full access to the network.  Here the
-   client may be unable to directly contact the KDC either because it
-   does not have an IP address, or the access point packet filter does
-   not allow the client to send packets to the Internet before it
-   authenticates to the access point.
-
-   Recent advancements in extending Kerberos permit Kerberos
-   authentication to complete with the assistance of a proxy.  The
-   Kerberos [RFC4120] pre-authentication framework [KRB-PAFW] prevents
-   the exposure of weak client keys over the open network.  The Kerberos
-   support of anonymity [KRB-ANON] provides for privacy and further
-   complicates traffic analysis.  The kdc-referrals option defined in
-   [KRB-PAFW] may reduce the number of messages exchanged while
-   obtaining a ticket to exactly two even in cross-realm
-   authentications.
-
-   Building upon these Kerberos extensions, this document extends
-   [RFC4120] and [RFC4121] such that the client can communicate with the
-   KDC using a Generic Security Service Application Program Interface
-   (GSS-API) [RFC2743] acceptor as the proxy.  The GSS-API acceptor
-   relays the KDC request and reply messages between the client and the
-   KDC.  The GSS-API acceptor, when relaying the Kerberos messages, is
-   called an IAKERB proxy.  Consequently, IAKERB as defined in this
-   document requires the use of GSS-API.
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-3.  GSS-API Encapsulation
-
-   The mechanism Objection Identifier (OID) for GSS-API IAKERB, in
-   accordance with the mechanism proposed by [RFC4178] for negotiating
-   protocol variations, is id-kerberos-iakerb:
-
-      id-kerberos-iakerb ::=
-        { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
-          iakerb(5) }
-
-
-
-Zhu & Altman            Expires January 10, 2008                [Page 3]
-
-Internet-Draft                   IAKERB                        July 2007
-
-
-   The initial context establishment token of IAKERB MUST have the
-   generic token framing described in section 3.1 of [RFC2743] with the
-   mechanism OID being id-kerberos-iakerb, and any subsequent IAKERB
-   context establishment token MUST NOT have this token framing.
-
-   The client starts by constructing the ticket request, and if the
-   ticket request is being made to the KDC, the client, instead of
-   contacting the KDC directly, encapsulates the request message into
-   the output token of the GSS_Init_security_context() call and returns
-   GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more
-   token is required in order to establish the context.  The output
-   token is then passed for use as the input token to the
-   GSS_Accept_sec_context() call in accordance with GSS-API.  The GSS-
-   API acceptor extracts the Kerberos request in the input token,
-   locates the target KDC, and sends the request on behalf of the
-   client.  After receiving the KDC reply, the GSS-API acceptor then
-   encapsulates the reply message into the output token of
-   GSS_Accept_sec_context().  The GSS-API acceptor returns
-   GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more
-   token is required in order to establish the context.  The output
-   token is passed to the initiator in accordance with GSS-API.
-
-          Client <---------> IAKERB proxy <---------> KDC
-
-   The innerToken described in section 3.1 of [RFC2743] and subsequent
-   GSS-API mechanism tokens have the following formats: it starts with a
-   two-octet token-identifier (TOK_ID), followed by an IAKERB message or
-   a Kerberos message.
-
-   Only one IAKERB specific message, namely the IAKERB_PROXY message, is
-   defined in this document.  The TOK_ID values for Kerberos messages
-   are the same as defined in [RFC4121].
-
-                 Token          TOK_ID Value in Hex
-              --------------------------------------
-               IAKERB_PROXY           05 01
-
-   The content of the IAKERB_PROXY message is defined as an IAKERB-
-   HEADER structure immediately followed by a Kerberos message.  The
-   Kerberos message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP,
-   or a KRB-ERROR as defined in [RFC4120].
-
-
-
-
-
-
-
-
-
-
-Zhu & Altman            Expires January 10, 2008                [Page 4]
-
-Internet-Draft                   IAKERB                        July 2007
-
-
-           IAKERB-HEADER ::= SEQUENCE {
-               target-realm      [1] UTF8String,
-                  -- The name of the target realm.
-               cookie            [2] OCTET STRING OPTIONAL,
-                  -- Opaque data, if sent by the server,
-                  -- MUST be copied by the client verbatim into
-                  -- the next IAKRB_PROXY message.
-               ...
-           }
-
-   The IAKERB-HEADER structure and all the Kerberos messages MUST be
-   encoded using Abstract Syntax Notation One (ASN.1) Distinguished
-   Encoding Rules (DER) [X680] [X690].
-
-   The IAKERB client fills out the IAKERB-HEADER structure as follows:
-   the target-realm contains the realm name the ticket request is
-   addressed to.  In the initial message from the client, the cookie
-   field is absent.  The client MUST specify a target-realm.  If the
-   client does not know the realm of the client's true principal name
-   [REFERALS], it MUST specify a realm it knows.  This can be the realm
-   of the client's host.
-
-   Upon receipt of the IAKERB_PROXY message, the GSS-API acceptor
-   inspects the target-realm field in the IAKERB_HEADER, and locates a
-   KDC of that realm, and sends the ticket request to that KDC.
-
-   When the GSS-API acceptor is unable to obtain an IP address for a KDC
-   in the client's realm, it sends a KRB_ERROR message with the code
-   KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client and the context fails
-   to establish.  There is no accompanying error data defined in this
-   document for this error code.
-
-           KRB_AP_ERR_IAKERB_KDC_NOT_FOUND      85
-               -- The IAKERB proxy could not find a KDC.
-
-   When the GSS-API acceptor has an IP address for a KDC in the client
-   realm, but does not receive a response from any KDC in the realm
-   (including in response to retries), it sends a KRB_ERROR message with
-   the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client and the
-   context fails to establish.  There is no accompanying error data
-   defined in this document for this error code.
-
-           KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE    86
-               -- The KDC did not respond to the IAKERB proxy.
-
-   The IAKERB proxy can send opaque data in the cookie field of the
-   IAKERB-HEADER structure in the server reply to the client, in order
-   to, for example, minimize the amount of state information kept by the
-
-
-
-Zhu & Altman            Expires January 10, 2008                [Page 5]
-
-Internet-Draft                   IAKERB                        July 2007
-
-
-   GSS-API acceptor.  The content and the encoding of the cookie field
-   is a local matter of the IAKERB proxy.  The client MUST copy the
-   cookie verbatim from the previous server response whenever the cookie
-   is present into the subsequent tokens that contains an IAKERB_PROXY
-   message.
-
-   When the client obtained a service ticket, the client sends a
-   KRB_AP_REQ message to the server, and performs the client-server
-   application exchange as defined in [RFC4120] and [RFC4121].
-
-   For implementations comforming to this specification, the
-   authenticator subkey in the AP-REQ MUST alway be present, and the
-   Exts field in the GSS-API authenticator [GSS-EXTS] MUST contain an
-   extension of the type GSS_EXTS_IAKERB_FINISHED and the extension data
-   contains the ASN.1 DER encoding of the structure IAKERB-FINISHED.
-
-           GSS_EXTS_IAKERB_FINISHED             TBD
-                --- Data type for the IAKERB checksum.
-
-           IAKERB-FINISHED ::= {
-                iakerb-messages [1] Checksum,
-                    -- Contains the checksum of the GSS-API tokens
-                    -- exchanged between the initiator and the acceptor,
-                    -- and prior to the containing AP_REQ GSS-API token.
-                    -- The checksum is performed over the GSS-API tokens
-                    -- in the order that the tokens were sent.
-                 ...
-           }
-
-   The iakerb-messages field in the IAKERB-FINISHED structure contains a
-   checksum of all the GSS-API tokens exchanged between the initiator
-   and the acceptor, and prior to the GSS-API token containing the
-   AP_REQ.  This checksum is performed over these GSS-API tokens in the
-   order that the tokens were sent.  In the parlance of [RFC3961], the
-   checksum type is the required checksum type for the enctype of the
-   subkey in the authenticator, the protocol key for the checksum
-   operation is the authenticator subkey, and the key usage number is
-   KEY_USAGE_IAKERB_FINISHED.
-
-           KEY_USAGE_IAKERB_FINISHED            42
-
-   The GSS-API acceptor MUST then verify the checksum contained in the
-   GSS_EXTS_IAKERB_FINISHED extension.  This checksum provides integrity
-   protection for the messages exchanged including the unauthenticated
-   clear texts in the IAKERB-HEADER structure.
-
-   If the pre-authentication data is encrypted in the long-term
-   password-based key of the principal, the risk of security exposures
-
-
-
-Zhu & Altman            Expires January 10, 2008                [Page 6]
-
-Internet-Draft                   IAKERB                        July 2007
-
-
-   is significant.  Implementations SHOULD provide the AS_REQ armoring
-   as defined in [KRB-PAFW] unless an alternative protection is
-   deployed.  In addition, the anonymous Kerberos FAST option is
-   RECOMMENDED for the client to complicate traffic analysis.
-
-
-4.  Addresses in Tickets
-
-   In IAKERB, the machine sending requests to the KDC is the GSS-API
-   acceptor and not the client.  As a result, the client should not
-   include its addresses in any KDC requests for two reasons.  First,
-   the KDC may reject the forwarded request as being from the wrong
-   client.  Second, in the case of initial authentication for a dial-up
-   client, the client machine may not yet possess a network address.
-   Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and
-   TGS-REQ requests SHOULD be blank and the caddr field of the ticket
-   SHOULD similarly be left blank.
-
-
-5.  Security Considerations
-
-   A typical IAKERB client sends the AS_REQ with pre-authentication data
-   encrypted in the long-term keys of the user before the server is
-   authenticated.  This enables offline attacks by un-trusted servers.
-   To mitigate this threat, the client SHOULD use Kerberos
-   FAST[KRB-PAFW] and require KDC authentication to protect the user's
-   credentials.
-
-   The client name is in clear text in the authentication exchange
-   messages and ticket granting service exchanges according to [RFC4120]
-   whereas the client name is encrypted in client- server application
-   exchange messages.  By using the IAKERB proxy to relay the ticket
-   requests and responses, the client's identity could be revealed in
-   the client-server traffic where the same identity could have been
-   concealed if IAKERB were not used.  Hence, to complicate traffic
-   analysis and provide privacy for the IAKERB client, the IAKERB client
-   SHOULD request the anonymous Kerberos FAST option [KRB-PAFW].
-
-   Similar to other network access protocols, IAKERB allows an
-   unauthenticated client (possibly outside the security perimeter of an
-   organization) to send messages that are proxied to interior servers.
-
-   In a scenario where DNS SRV RR's are being used to locate the KDC,
-   IAKERB is being used, and an external attacker can modify DNS
-   responses to the IAKERB proxy, there are several countermeasures to
-   prevent arbitrary messages from being sent to internal servers:
-
-
-
-
-
-Zhu & Altman            Expires January 10, 2008                [Page 7]
-
-Internet-Draft                   IAKERB                        July 2007
-
-
-   1.  KDC port numbers can be statically configured on the IAKERB
-       proxy.  In this case, the messages will always be sent to KDC's.
-       For an organization that runs KDC's on a static port (usually
-       port 88) and does not run any other servers on the same port,
-       this countermeasure would be easy to administer and should be
-       effective.
-
-   2.  The proxy can do application level sanity checking and filtering.
-       This countermeasure should eliminate many of the above attacks.
-
-   3.  DNS security can be deployed.  This countermeasure is probably
-       overkill for this particular problem, but if an organization has
-       already deployed DNS security for other reasons, then it might
-       make sense to leverage it here.  Note that Kerberos could be used
-       to protect the DNS exchanges.  The initial DNS SRV KDC lookup by
-       the proxy will be unprotected, but an attack here is at most a
-       denial of service (the initial lookup will be for the proxy's KDC
-       to facilitate Kerberos protection of subsequent DNS exchanges
-       between itself and the DNS server).
-
-
-6.  Acknowledgements
-
-   Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote
-   earlier revision of this document.
-
-   The hallway conversations between Larry Zhu and Nicolas Williams
-   formed the basis of this document.
-
-
-7.  IANA Considerations
-
-   There is no IANA action required for this document.
-
-
-8.  References
-
-8.1.  Normative References
-
-   [GSS-EXTS]
-              Emery, S., "Kerberos Version 5 GSS-API Channel Binding
-              Hash Agility",
-              draft-ietf-krb-wg-gss-cb-hash-agility-03.txt (work in
-              progress), 2007.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-Zhu & Altman            Expires January 10, 2008                [Page 8]
-
-Internet-Draft                   IAKERB                        July 2007
-
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
-              Simple and Protected Generic Security Service Application
-              Program Interface (GSS-API) Negotiation Mechanism",
-              RFC 4178, October 2005.
-
-8.2.  Informative references
-
-   [KRB-ANON]
-              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
-              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
-
-   [KRB-PAFW]
-              Zhu, L. and S. Hartman, "A Generalized Framework for
-              Kerberos Pre-Authentication",
-              draft-ietf-krb-wg-preauth-framework-06.txt (work in
-              progress), 2007.
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-Zhu & Altman            Expires January 10, 2008                [Page 9]
-
-Internet-Draft                   IAKERB                        July 2007
-
-
-   Jeffery Altman
-   Secure Endpoints
-   255 W 94th St
-   New York, NY  10025
-   US
-
-   Email: jaltman@secure-endpoints.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Altman            Expires January 10, 2008               [Page 10]
-
-Internet-Draft                   IAKERB                        July 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Zhu & Altman            Expires January 10, 2008               [Page 11]
-
-
diff --git a/doc/standardisation/rc4-hmac.txt b/doc/standardisation/rc4-hmac.txt
deleted file mode 100644
index 9ebe39e0a..000000000
--- a/doc/standardisation/rc4-hmac.txt
+++ /dev/null
@@ -1,589 +0,0 @@
-CAT working group                                              M. Swift 
-Internet Draft                                                J. Brezak 
-Document: draft-brezak-win2k-krb-rc4-hmac-03.txt              Microsoft 
-Category: Informational                                       June 2000 
- 
- 
-           The Windows 2000 RC4-HMAC Kerberos encryption type 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [1]. 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." 
-     
-   The list of current Internet-Drafts can be accessed at 
-   http://www.ietf.org/ietf/1id-abstracts.txt  
-   The list of Internet-Draft Shadow Directories can be accessed at 
-   http://www.ietf.org/shadow.html. 
-    
-1. Abstract 
-    
-   The Windows 2000 implementation of Kerberos introduces a new 
-   encryption type based on the RC4 encryption algorithm and using an 
-   MD5 HMAC for checksum. This is offered as an alternative to using 
-   the existing DES based encryption types. 
-    
-   The RC4-HMAC encryption types are used to ease upgrade of existing 
-   Windows NT environments, provide strong crypto (128-bit key 
-   lengths), and provide exportable (meet United States government 
-   export restriction requirements) encryption. 
-    
-   The Windows 2000 implementation of Kerberos contains new encryption 
-   and checksum types for two reasons: for export reasons early in the 
-   development process, 56 bit DES encryption could not be exported, 
-   and because upon upgrade from Windows NT 4.0 to Windows 2000, 
-   accounts will not have the appropriate DES keying material to do the 
-   standard DES encryption. Furthermore, 3DES is not available for 
-   export, and there was a desire to use a single flavor of encryption 
-   in the product for both US and international products. 
-    
-   As a result, there are two new encryption types and one new checksum 
-   type introduced in Windows 2000. 
-    
-    
-2. Conventions used in this document 
-    
-
-  
-Swift                  Category - Informational                      1 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
-   this document are to be interpreted as described in RFC-2119 [2]. 
-    
-3. Key Generation 
-    
-   On upgrade from existing Windows NT domains, the user accounts would 
-   not have a DES based key available to enable the use of DES base 
-   encryption types specified in RFC 1510. The key used for RC4-HMAC is 
-   the same as the existing Windows NT key (NT Password Hash) for 
-   compatibility reasons. Once the account password is changed, the DES 
-   based keys are created and maintained. Once the DES keys are 
-   available DES based encryption types can be used with Kerberos.  
-    
-   The RC4-HMAC String to key function is defined as follow: 
-    
-   String2Key(password) 
-    
-        K = MD4(UNICODE(password)) 
-         
-   The RC4-HMAC keys are generated by using the Windows UNICODE version 
-   of the password. Each Windows UNICODE character is encoded in 
-   little-endian format of 2 octets each. Then performing an MD4 [6] 
-   hash operation on just the UNICODE characters of the password (not 
-   including the terminating zero octets). 
-    
-   For an account with a password of "foo", this String2Key("foo") will 
-   return: 
-    
-        0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe, 
-        0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc 
-    
-4. Basic Operations 
-    
-   The MD5 HMAC function is defined in [3]. It is used in this 
-   encryption type for checksum operations. Refer to [3] for details on 
-   its operation. In this document this function is referred to as 
-   HMAC(Key, Data) returning the checksum using the specified key on 
-   the data. 
-    
-   The basic MD5 hash operation is used in this encryption type and 
-   defined in [7]. In this document this function is referred to as 
-   MD5(Data) returning the checksum of the data. 
-    
-   RC4 is a stream cipher licensed by RSA Data Security [RSADSI]. A       
-   compatible cipher is described in [8]. In this document the function 
-   is referred to as RC4(Key, Data) returning the encrypted data using 
-   the specified key on the data. 
-    
-   These encryption types use key derivation as defined in [9] (RFC-
-   1510BIS) in Section titled "Key Derivation". With each message, the 
-   message type (T) is used as a component of the keying material. This 
-   summarizes the different key derivation values used in the various 
-  
-Swift                  Category - Informational                      2 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
-   operations. Note that these differ from the key derivations used in 
-   other Kerberos encryption types. 
-    
-        T = 1 for TS-ENC-TS in the AS-Request 
-        T = 8 for the AS-Reply  
-        T = 7 for the Authenticator in the TGS-Request 
-        T = 8 for the TGS-Reply  
-        T = 2 for the Server Ticket in the AP-Request 
-        T = 11 for the Authenticator in the AP-Request 
-        T = 12 for the Server returned AP-Reply 
-        T = 15 in the generation of checksum for the MIC token 
-        T = 0 in the generation of sequence number for the MIC token  
-        T = 13 in the generation of checksum for the WRAP token 
-        T = 0 in the generation of sequence number for the WRAP token  
-        T = 0 in the generation of encrypted data for the WRAPPED token 
-    
-   All strings in this document are ASCII unless otherwise specified. 
-   The lengths of ASCII encoded character strings include the trailing 
-   terminator character (0). 
-    
-   The concat(a,b,c,...) function will return the logical concatenation 
-   (left to right) of the values of the arguments. 
-    
-   The nonce(n) function returns a pseudo-random number of "n" octets. 
-    
-5. Checksum Types 
-    
-   There is one checksum type used in this encryption type. The 
-   Kerberos constant for this type is: 
-        #define KERB_CHECKSUM_HMAC_MD5 (-138) 
-    
-   The function is defined as follows: 
-    
-   K - is the Key 
-   T - the message type, encoded as a little-endian four byte integer 
-    
-   CHKSUM(K, T, data) 
-    
-        Ksign = HMAC(K, "signaturekey")  //includes zero octet at end 
-        tmp = MD5(concat(T, data)) 
-        CHKSUM = HMAC(Ksign, tmp) 
-    
-    
-6. Encryption Types 
-    
-   There are two encryption types used in these encryption types. The 
-   Kerberos constants for these types are: 
-        #define KERB_ETYPE_RC4_HMAC             23 
-        #define KERB_ETYPE_RC4_HMAC_EXP         24 
-    
-   The basic encryption function is defined as follow: 
-    
-   T = the message type, encoded as a little-endian four byte integer. 
-  
-Swift                  Category - Informational                      3 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
-    
-        BYTE L40[14] = "fortybits"; 
-        BYTE SK = "signaturekey"; 
-         
-        ENCRYPT (K, fRC4_EXP, T, data, data_len, edata, edata_len) 
-        { 
-            if (fRC4_EXP){ 
-                *((DWORD *)(L40+10)) = T; 
-                HMAC (K, L40, 10 + 4, K1); 
-            }else{ 
-                HMAC (K, &T, 4, K1); 
-            } 
-            memcpy (K2, K1, 16); 
-            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
-            add_8_random_bytes(data, data_len, conf_plus_data); 
-            HMAC (K2, conf_plus_data, 8 + data_len, checksum); 
-            HMAC (K1, checksum, 16, K3); 
-            RC4(K3, conf_plus_data, 8 + data_len, edata + 16); 
-            memcpy (edata, checksum, 16); 
-            edata_len = 16 + 8 + data_len; 
-        }         
-         
-        DECRYPT (K, fRC4_EXP, T, edata, edata_len, data, data_len) 
-        { 
-            if (fRC4_EXP){ 
-                *((DWORD *)(L40+10)) = T; 
-                HMAC (K, L40, 14, K1); 
-            }else{ 
-                HMAC (K, &T, 4, K1); 
-            } 
-            memcpy (K2, K1, 16); 
-            if (fRC4_EXP) memset (K1+7, 0xAB, 9); 
-            HMAC (K1, edata, 16, K3); // checksum is at edata 
-            RC4(K3, edata + 16, edata_len - 16, edata + 16); 
-            data_len = edata_len - 16 - 8; 
-            memcpy (data, edata + 16 + 8, data_len); 
-             
-            // verify generated and received checksums 
-            HMAC (K2, edata + 16, edata_len - 16, checksum); 
-            if (memcmp(edata, checksum, 16) != 0)  
-                printf("CHECKSUM ERROR  !!!!!!\n"); 
-        } 
-    
-   The header field on the encrypted data in KDC messages is: 
-    
-        typedef struct _RC4_MDx_HEADER { 
-            UCHAR Checksum[16]; 
-            UCHAR Confounder[8]; 
-        } RC4_MDx_HEADER, *PRC4_MDx_HEADER; 
-         
-   The KDC message is encrypted using the ENCRYPT function not 
-   including the Checksum in the RC4_MDx_HEADER. 
-    
-  
-Swift                  Category - Informational                      4 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States. 
-   It is now used to recognize that the key length is of "exportable" 
-   length. In this description, the key size is actually 56-bits. 
-    
-7. Key Strength Negotiation 
-    
-   A Kerberos client and server can negotiate over key length if they 
-   are using mutual authentication. If the client is unable to perform 
-   full strength encryption, it may propose a key in the "subkey" field 
-   of the authenticator, using a weaker encryption type. The server 
-   must then either return the same key or suggest its own key in the 
-   subkey field of the AP reply message. The key used to encrypt data 
-   is derived from the key returned by the server. If the client is 
-   able to perform strong encryption but the server is not, it may 
-   propose a subkey in the AP reply without first being sent a subkey 
-   in the authenticator. 
- 
-8. GSSAPI Kerberos V5 Mechanism Type  
- 
-8.1 Mechanism Specific Changes 
-    
-   The GSSAPI per-message tokens also require new checksum and 
-   encryption types. The GSS-API per-message tokens must be changed to 
-   support these new encryption types (See [5] Section 1.2.2). The 
-   sealing algorithm identifier (SEAL_ALG) for an RC4 based encryption 
-   is: 
-        Byte 4..5 SEAL_ALG      0x10 0x00 - RC4 
-    
-   The signing algorithm identifier (SGN_ALG) for MD5 HMAC is: 
-        Byte 2..3 SGN ALG       0x11 0x00 - HMAC 
-    
-   The only support quality of protection is: 
-        #define GSS_KRB5_INTEG_C_QOP_DEFAULT    0x0 
-    
-   In addition, when using an RC4 based encryption type, the sequence 
-   number is sent in big-endian rather than little-endian order. 
-    
-   The Windows 2000 implementation also defines new GSSAPI flags in the 
-   initial token passed when initializing a security context. These 
-   flags are passed in the checksum field of the authenticator (See [5] 
-   Section 1.1.1). 
-    
-   GSS_C_DCE_STYLE - This flag was added for use with Microsoft’s 
-   implementation of DCE RPC, which initially expected three legs of 
-   authentication. Setting this flag causes an extra AP reply to be 
-   sent from the client back to the server after receiving the server’s 
-   AP reply. In addition, the context negotiation tokens do not have 
-   GSSAPI framing - they are raw AP message and do not include object 
-   identifiers. 
-        #define GSS_C_DCE_STYLE                 0x1000 
-    
-
-  
-Swift                  Category - Informational                      5 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
-   GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the 
-   server that it should only allow the server application to identify 
-   the client by name and ID, but not to impersonate the client. 
-        #define GSS_C_IDENTIFY_FLAG             0x2000 
-         
-   GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the 
-   client wants to be informed of extended error information. In 
-   particular, Windows 2000 status codes may be returned in the data 
-   field of a Kerberos error message. This allows the client to 
-   understand a server failure more precisely. In addition, the server 
-   may return errors to the client that are normally handled at the 
-   application layer in the server, in order to let the client try to 
-   recover. After receiving an error message, the client may attempt to 
-   resubmit an AP request. 
-        #define GSS_C_EXTENDED_ERROR_FLAG       0x4000 
-    
-   These flags are only used if a client is aware of these conventions 
-   when using the SSPI on the Windows platform, they are not generally 
-   used by default. 
-    
-   When NetBIOS addresses are used in the GSSAPI, they are identified 
-   by the GSS_C_AF_NETBIOS value. This value is defined as: 
-        #define GSS_C_AF_NETBIOS                0x14 
-   NetBios addresses are 16-octet addresses typically composed of 1 to 
-                                                                 th
-   15 characters, trailing blank (ascii char 20) filled, with a 16  
-   octet of 0x0. 
-    
-8.2 GSSAPI Checksum Type 
-    
-   The GSSAPI checksum type and algorithm is defined in Section 5. Only 
-   the first 8 octets of the checksum are used. The resulting checksum 
-   is stored in the SGN_CKSUM field (See [5] Section 1.2) for 
-   GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE). 
-    
-        MIC (K, fRC4_EXP, seq_num, MIC_hdr, msg, msg_len, 
-             MIC_seq, MIC_checksum) 
-        { 
-            HMAC (K, SK, 13, K4); 
-            T = 15; 
-            memcpy (T_plus_hdr_plus_msg + 00, &T, 4); 
-            memcpy (T_plus_hdr_plus_msg + 04, MIC_hdr, 8);  
-                                                // 0101 1100 FFFFFFFF 
-            memcpy (T_plus_hdr_plus_msg + 12, msg, msg_len); 
-            MD5 (T_hdr_msg, 4 + 8 + msg_len, MD5_of_T_hdr_msg); 
-            HMAC (K4, MD5_of_T_hdr_msg, CHKSUM); 
-            memcpy (MIC_checksum, CHKSUM, 8); // use only first 8 bytes 
-          
-            T = 0; 
-            if (fRC4_EXP){  
-                *((DWORD *)(L40+10)) = T; 
-                HMAC (K, L40, 14, K5); 
-            }else{ 
-                HMAC (K, &T, 4, K5); 
-  
-Swift                  Category - Informational                      6 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
-            } 
-            if (fRC4_EXP) memset(K5+7, 0xAB, 9); 
-            HMAC(K5, MIT_checksum, 8, K6); 
-            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
-        //0x12345678 
-            copy_direction_flag (direction_flag, seq_plus_direction + 
-        4); //0x12345678FFFFFFFF 
-            RC4(K6, seq_plus_direction, 8, MIC_seq); 
-        } 
-    
-8.3 GSSAPI Encryption Types 
-    
-   There are two encryption types for GSSAPI message tokens, one that 
-   is 128 bits in strength, and one that is 56 bits in strength as 
-   defined in Section 6. 
-    
-   All padding is rounded up to 1 byte. One byte is needed to say that 
-   there is 1 byte of padding. The DES based mechanism type uses 8 byte 
-   padding. See [5] Section 1.2.2.3. 
-    
-   The encryption mechanism used for GSS wrap based messages is as 
-   follow: 
-    
-    
-        WRAP (K, fRC4_EXP, seq_num, WRAP_hdr, msg, msg_len, 
-              WRAP_seq, WRAP_checksum, edata, edata_len) 
-        { 
-            HMAC (K, SK, 13, K7); 
-            T = 13; 
-            PAD = 1; 
-            memcpy (T_hdr_conf_msg_pad + 00, &T, 4); 
-            memcpy (T_hdr_conf_msg_pad + 04, WRAP_hdr, 8); // 0101 1100 
-        FFFFFFFF 
-            memcpy (T_hdr_conf_msg_pad + 12, msg, msg_len); 
-            memcpy (T_hdr_conf_msg_pad + 12 + msg_len, &PAD, 1); 
-            MD5 (T_hdr_conf_msg_pad, 
-                 4 + 8 + 8 + msg_len + 1, 
-                 MD5_of_T_hdr_conf_msg_pad); 
-            HMAC (K7, MD5_of_T_hdr_conf_msg_pad, CHKSUM); 
-            memcpy (WRAP_checksum, CHKSUM, 8); // use only first 8 
-        bytes 
-          
-            T = 0; 
-            if (fRC4_EXP){  
-                *((DWORD *)(L40+10)) = T; 
-                HMAC (K, L40, 14, K8); 
-            }else{ 
-                HMAC (K, &T, 4, K8); 
-            } 
-            if (fRC4_EXP) memset(K8+7, 0xAB, 9); 
-            HMAC(K8, WRAP_checksum, 8, K9); 
-            copy_seq_num_in_big_endian(seq_num, seq_plus_direction); 
-        //0x12345678 
-  
-Swift                  Category - Informational                      7 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
-            copy_direction_flag (direction_flag, seq_plus_direction + 
-        4); //0x12345678FFFFFFFF 
-            RC4(K9, seq_plus_direction, 8, WRAP_seq); 
-          
-            for (i = 0; i < 16; i++) K10 [i] ^= 0xF0; // XOR each byte 
-        of key with 0xF0 
-            T = 0; 
-            if (fRC4_EXP){ 
-                *(DWORD *)(L40+10) = T; 
-                HMAC(K10, L40, 14, K11); 
-                memset(K11+7, 0xAB, 9); 
-            }else{ 
-                HMAC(K10, &T, 4, K11);  
-            } 
-            HMAC(K11, seq_num, 4, K12); 
-            RC4(K12, T_hdr_conf_msg_pad + 4 + 8, 8 + msg_len + 1, 
-        edata); /* skip T & hdr */ 
-            edata_len = 8 + msg_len + 1; // conf + msg_len + pad 
-         } 
-          
-    
-   The character constant "fortybits" evolved from the time when a 40-
-   bit key length was all that was exportable from the United States. 
-   It is now used to recognize that the key length is of "exportable" 
-   length. In this description, the key size is actually 56-bits. 
-    
-9. Security Considerations 
- 
-   Care must be taken in implementing this encryption type because it 
-   uses a stream cipher. If a different IV isn’t used in each direction 
-   when using a session key, the encryption is weak. By using the 
-   sequence number as an IV, this is avoided. 
-    
-10. Acknowledgements 
-    
-   We would like to thank Salil Dangi for the valuable input in 
-   refining the descriptions of the functions and review input. 
-     
-11. References 
- 
-   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
-      9, RFC 2026, October 1996. 
-    
-   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
-      Levels", BCP 14, RFC 2119, March 1997 
-    
-   3  Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed-Hashing for 
-      Message Authentication", RFC 2104, February 1997 
-    
-   4  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
-      Service (V5)", RFC 1510, September 1993 
- 
- 
-  
-Swift                  Category - Informational                      8 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type       June 2000 
- 
- 
- 
-   5  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC-1964, 
-      June 1996 
- 
-   6  R. Rivest, "The MD4 Message-Digest Algorithm", RFC-1320, April 
-      1992 
- 
-   7  R. Rivest, "The MD5 Message-Digest Algorithm", RFC-1321, April 
-      1992 
- 
-   8  Thayer, R. and K. Kaukonen, "A Stream Cipher Encryption             
-      Algorithm", Work in Progress. 
- 
-   9  RC4 is a proprietary encryption algorithm available under license 
-      from RSA Data Security Inc.  For licensing information, contact: 
-       
-         RSA Data Security, Inc. 
-         100 Marine Parkway 
-         Redwood City, CA 94065-1031 
- 
-   10 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 
-      Authentication Service (V5)", draft-ietf-cat-kerberos-revisions-
-      04.txt, June 25, 1999 
- 
-    
-12. Author's Addresses 
-    
-   Mike Swift 
-   Dept. of Computer Science 
-   Sieg Hall 
-   University of Washington 
-   Seattle, WA 98105 
-   Email: mikesw@cs.washington.edu  
-    
-   John Brezak 
-   Microsoft 
-   One Microsoft Way 
-   Redmond, Washington 
-   Email: jbrezak@microsoft.com 
-    
-    
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                      9 
-
-                Windows 2000 RC4-HMAC Kerberos E-Type    October 1999 
- 
- 
-    
-13. Full Copyright Statement 
- 
-   "Copyright (C) The Internet Society (2000). All Rights Reserved. 
-    
-   This document and translations of it may be copied and          
-   furnished to others, and derivative works that comment on or          
-   otherwise explain it or assist in its implementation may be          
-   prepared, copied, published and distributed, in whole or in          
-   part, without restriction of any kind, provided that the above          
-   copyright notice and this paragraph are included on all such          
-   copies and derivative works.  However, this document itself may          
-   not be modified in any way, such as by removing the copyright          
-   notice or references to the Internet Society or other Internet          
-   organizations, except as needed for the purpose of developing          
-   Internet standards in which case the procedures for copyrights          
-   defined in the Internet Standards process must be followed, or          
-   as required to translate it into languages other than English. 
-    
-   The limited permissions granted above are perpetual and will          
-   not be revoked by the Internet Society or its successors or          
-   assigns. 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Swift                  Category - Informational                     10 
-
diff --git a/doc/standardisation/rfc1508.txt b/doc/standardisation/rfc1508.txt
deleted file mode 100644
index 132b855e0..000000000
--- a/doc/standardisation/rfc1508.txt
+++ /dev/null
@@ -1,2747 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            J. Linn
-Request for Comments: 1508                         Geer Zolot Associates
-                                                          September 1993
-
-
-         Generic Security Service Application Program Interface
-
-Status of this Memo
-
-   This RFC 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" for the standardization state and status
-   of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This Generic Security Service Application Program Interface (GSS-API)
-   definition provides security services to callers in a generic
-   fashion, supportable with a range of underlying mechanisms and
-   technologies and hence allowing source-level portability of
-   applications to different environments. This specification defines
-   GSS-API services and primitives at a level independent of underlying
-   mechanism and programming language environment, and is to be
-   complemented by other, related specifications:
-
-        documents defining specific parameter bindings for particular
-        language environments
-
-        documents defining token formats, protocols, and procedures to
-        be implemented in order to realize GSS-API services atop
-        particular security mechanisms
-
-Table of Contents
-
-   1. GSS-API Characteristics and Concepts .......................    2
-   1.1. GSS-API Constructs .......................................    5
-   1.1.1.  Credentials ...........................................    5
-   1.1.2.  Tokens ................................................    6
-   1.1.3.  Security Contexts .....................................    7
-   1.1.4.  Mechanism Types .......................................    8
-   1.1.5.  Naming ................................................    9
-   1.1.6.  Channel Bindings ......................................   10
-   1.2.  GSS-API Features and Issues .............................   11
-   1.2.1.  Status Reporting ......................................   11
-   1.2.2.  Per-Message Security Service Availability .............   12
-   1.2.3.  Per-Message Replay Detection and Sequencing ...........   13
-   1.2.4.  Quality of Protection .................................   15
-
-
-
-Linn                                                            [Page 1]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   2. Interface Descriptions .....................................   15
-   2.1.  Credential management calls .............................   17
-   2.1.1.  GSS_Acquire_cred call .................................   17
-   2.1.2.  GSS_Release_cred call .................................   19
-   2.1.3.  GSS_Inquire_cred call .................................   20
-   2.2.  Context-level calls .....................................   21
-   2.2.1.  GSS_Init_sec_context call .............................   21
-   2.2.2.  GSS_Accept_sec_context call ...........................   26
-   2.2.3.  GSS_Delete_sec_context call ...........................   29
-   2.2.4.  GSS_Process_context_token call ........................   30
-   2.2.5.  GSS_Context_time call .................................   31
-   2.3.  Per-message calls .......................................   32
-   2.3.1.  GSS_Sign call .........................................   32
-   2.3.2.  GSS_Verify call .......................................   33
-   2.3.3.  GSS_Seal call .........................................   35
-   2.3.4.  GSS_Unseal call .......................................   36
-   2.4.  Support calls ...........................................   37
-   2.4.1.  GSS_Display_status call ...............................   37
-   2.4.2.  GSS_Indicate_mechs call ...............................   38
-   2.4.3.  GSS_Compare_name call .................................   38
-   2.4.4.  GSS_Display_name call .................................   39
-   2.4.5.  GSS_Import_name call ..................................   40
-   2.4.6.  GSS_Release_name call .................................   41
-   2.4.7.  GSS_Release_buffer call ...............................   41
-   2.4.8.  GSS_Release_oid_set call ..............................   42
-   3. Mechanism-Specific Example Scenarios .......................   42
-   3.1.  Kerberos V5, single-TGT .................................   43
-   3.2.  Kerberos V5, double-TGT .................................   43
-   3.3.  X.509 Authentication Framework ..........................   44
-   4. Related Activities .........................................   45
-   5. Acknowledgments ............................................   46
-   6. Security Considerations ....................................   46
-   7. Author's Address ...........................................   46
-   Appendix A ....................................................   47
-   Appendix B ....................................................   48
-   Appendix C ....................................................   49
-
-1. GSS-API Characteristics and Concepts
-
-   The operational paradigm in which GSS-API operates is as follows. A
-   typical GSS-API caller is itself a communications protocol, calling
-   on GSS-API in order to protect its communications with
-   authentication, integrity, and/or confidentiality security services.
-   A GSS-API caller accepts tokens provided to it by its local GSS-API
-   implementation and transfers the tokens to a peer on a remote system;
-   that peer passes the received tokens to its local GSS-API
-   implementation for processing. The security services available
-   through GSS-API in this fashion are implementable (and have been
-
-
-
-Linn                                                            [Page 2]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   implemented) over a range of underlying mechanisms based on secret-
-   key and public-key cryptographic technologies.
-
-   The GSS-API separates the operations of initializing a security
-   context between peers, achieving peer entity authentication (This
-   security service definition, and other definitions used in this
-   document, corresponds to that provided in International Standard ISO
-   7498-2-1988(E), Security Architecture.) (GSS_Init_sec_context() and
-   GSS_Accept_sec_context() calls), from the operations of providing
-   per-message data origin authentication and data integrity protection
-   (GSS_Sign() and GSS_Verify() calls) for messages subsequently
-   transferred in conjunction with that context. Per-message GSS_Seal()
-   and GSS_Unseal() calls provide the data origin authentication and
-   data integrity services which GSS_Sign() and GSS_Verify() offer, and
-   also support selection of confidentiality services as a caller
-   option.  Additional calls provide supportive functions to the GSS-
-   API's users.
-
-   The following paragraphs provide an example illustrating the
-   dataflows involved in use of the GSS-API by a client and server in a
-   mechanism-independent fashion, establishing a security context and
-   transferring a protected message. The example assumes that credential
-   acquisition has already been completed.  The example assumes that the
-   underlying authentication technology is capable of authenticating a
-   client to a server using elements carried within a single token, and
-   of authenticating the server to the client (mutual authentication)
-   with a single returned token; this assumption holds for presently-
-   documented CAT mechanisms but is not necessarily true for other
-   cryptographic technologies and associated protocols.
-
-   The client calls GSS_Init_sec_context()  to establish a security
-   context to the server identified by targ_name, and elects to set the
-   mutual_req_flag so that mutual authentication is performed in the
-   course of context establishment. GSS_Init_sec_context()  returns an
-   output_token to be passed to the server, and indicates
-   GSS_CONTINUE_NEEDED status pending completion of the mutual
-   authentication sequence. Had mutual_req_flag not been set, the
-   initial call to GSS_Init_sec_context()  would have returned
-   GSS_COMPLETE status. The client sends the output_token to the server.
-
-   The server passes the received token as the input_token parameter to
-   GSS_Accept_sec_context().  GSS_Accept_sec_context indicates
-   GSS_COMPLETE status, provides the client's authenticated identity in
-   the src_name result, and provides an output_token to be passed to the
-   client. The server sends the output_token to the client.
-
-   The client passes the received token as the input_token parameter to
-   a successor call to GSS_Init_sec_context(),  which processes data
-
-
-
-Linn                                                            [Page 3]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   included in the token in order to achieve mutual authentication from
-   the client's viewpoint. This call to GSS_Init_sec_context()  returns
-   GSS_COMPLETE status, indicating successful mutual authentication and
-   the completion of context establishment for this example.
-
-   The client generates a data message and passes it to GSS_Seal().
-   GSS_Seal() performs data origin authentication, data integrity, and
-   (optionally) confidentiality processing on the message and
-   encapsulates the result into output_message, indicating GSS_COMPLETE
-   status. The client sends the output_message to the server.
-
-   The server passes the received message to GSS_Unseal().  GSS_Unseal
-   inverts the encapsulation performed by GSS_Seal(),  deciphers the
-   message if the optional confidentiality feature was applied, and
-   validates the data origin authentication and data integrity checking
-   quantities. GSS_Unseal()  indicates successful validation by
-   returning GSS_COMPLETE status along with the resultant
-   output_message.
-
-   For purposes of this example, we assume that the server knows by
-   out-of-band means that this context will have no further use after
-   one protected message is transferred from client to server. Given
-   this premise, the server now calls GSS_Delete_sec_context() to flush
-   context-level information. GSS_Delete_sec_context() returns a
-   context_token for the server to pass to the client.
-
-   The client passes the returned context_token to
-   GSS_Process_context_token(),  which returns GSS_COMPLETE status after
-   deleting context-level information at the client system.
-
-   The GSS-API design assumes and addresses several basic goals,
-   including:
-
-      Mechanism independence: The GSS-API defines an interface to
-      cryptographically implemented strong authentication and other
-      security services at a generic level which is independent of
-      particular underlying mechanisms. For example, GSS-API-provided
-      services can be implemented by secret-key technologies (e.g.,
-      Kerberos) or public-key approaches (e.g., X.509).
-
-      Protocol environment independence: The GSS-API is independent of
-      the communications protocol suites with which it is employed,
-      permitting use in a broad range of protocol environments. In
-      appropriate environments, an intermediate implementation "veneer"
-      which is oriented to a particular communication protocol (e.g.,
-      Remote Procedure Call (RPC)) may be interposed between
-      applications which call that protocol and the GSS-API, thereby
-      invoking GSS-API facilities in conjunction with that protocol's
-
-
-
-Linn                                                            [Page 4]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-      communications invocations.
-
-      Protocol association independence: The GSS-API's security context
-      construct is independent of communications protocol association
-      constructs. This characteristic allows a single GSS-API
-      implementation to be utilized by a variety of invoking protocol
-      modules on behalf of those modules' calling applications. GSS-API
-      services can also be invoked directly by applications, wholly
-      independent of protocol associations.
-
-      Suitability to a range of implementation placements: GSS-API
-      clients are not constrained to reside within any Trusted Computing
-      Base (TCB) perimeter defined on a system where the GSS-API is
-      implemented; security services are specified in a manner suitable
-      to both intra-TCB and extra-TCB callers.
-
-1.1. GSS-API Constructs
-
-   This section describes the basic elements comprising the GSS-API.
-
-1.1.1.  Credentials
-
-   Credentials structures provide the prerequisites enabling peers to
-   establish security contexts with each other. A caller may designate
-   that its default credential be used for context establishment calls
-   without presenting an explicit handle to that credential.
-   Alternately, those GSS-API callers which need to make explicit
-   selection of particular credentials structures may make references to
-   those credentials through GSS-API-provided credential handles
-   ("cred_handles").
-
-   A single credential structure may be used for initiation of outbound
-   contexts and acceptance of inbound contexts. Callers needing to
-   operate in only one of these modes may designate this fact when
-   credentials are acquired for use, allowing underlying mechanisms to
-   optimize their processing and storage requirements. The credential
-   elements defined by a particular mechanism may contain multiple
-   cryptographic keys, e.g., to enable authentication and message
-   encryption to be performed with different algorithms.
-
-   A single credential structure may accommodate credential information
-   associated with multiple underlying mechanisms (mech_types); a
-   credential structure's contents will vary depending on the set of
-   mech_types supported by a particular GSS-API implementation.
-   Commonly, a single mech_type will be used for all security contexts
-   established by a particular initiator to a particular target; the
-   primary motivation for supporting credential sets representing
-   multiple mech_types is to allow initiators on systems which are
-
-
-
-Linn                                                            [Page 5]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   equipped to handle multiple types to initiate contexts to targets on
-   other systems which can accommodate only a subset of the set
-   supported at the initiator's system.
-
-   It is the responsibility of underlying system-specific mechanisms and
-   OS functions below the GSS-API to ensure that the ability to acquire
-   and use credentials associated with a given identity is constrained
-   to appropriate processes within a system. This responsibility should
-   be taken seriously by implementors, as the ability for an entity to
-   utilize a principal's credentials is equivalent to the entity's
-   ability to successfully assert that principal's identity.
-
-   Once a set of GSS-API credentials is established, the transferability
-   of that credentials set to other processes or analogous constructs
-   within a system is a local matter, not defined by the GSS-API. An
-   example local policy would be one in which any credentials received
-   as a result of login to a given user account, or of delegation of
-   rights to that account, are accessible by, or transferable to,
-   processes running under that account.
-
-   The credential establishment process (particularly when performed on
-   behalf of users rather than server processes) is likely to require
-   access to passwords or other quantities which should be protected
-   locally and exposed for the shortest time possible. As a result, it
-   will often be appropriate for preliminary credential establishment to
-   be performed through local means at user login time, with the
-   result(s) cached for subsequent reference. These preliminary
-   credentials would be set aside (in a system-specific fashion) for
-   subsequent use, either:
-
-      to be accessed by an invocation of the GSS-API GSS_Acquire_cred()
-      call, returning an explicit handle to reference that credential
-
-      as the default credentials installed on behalf of a process
-
-1.1.2. Tokens
-
-   Tokens are data elements transferred between GSS-API callers, and are
-   divided into two classes. Context-level tokens are exchanged in order
-   to establish and manage a security context between peers. Per-message
-   tokens are exchanged in conjunction with an established context to
-   provide protective security services for corresponding data messages.
-   The internal contents of both classes of tokens are specific to the
-   particular underlying mechanism used to support the GSS-API; Appendix
-   B of this document provides a uniform recommendation for designers of
-   GSS-API support mechanisms, encapsulating mechanism-specific
-   information along with a globally-interpretable mechanism identifier.
-
-
-
-
-Linn                                                            [Page 6]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   Tokens are opaque from the viewpoint of GSS-API callers. They are
-   generated within the GSS-API implementation at an end system,
-   provided to a GSS-API caller to be transferred to the peer GSS-API
-   caller at a remote end system, and processed by the GSS-API
-   implementation at that remote end system. Tokens may be output by
-   GSS-API primitives (and are to be transferred to GSS-API peers)
-   independent of the status indications which those primitives
-   indicate. Token transfer may take place in an in-band manner,
-   integrated into the same protocol stream used by the GSS-API callers
-   for other data transfers, or in an out-of-band manner across a
-   logically separate channel.
-
-   Development of GSS-API support primitives based on a particular
-   underlying cryptographic technique and protocol does not necessarily
-   imply that GSS-API callers invoking that GSS-API mechanism type will
-   be able to interoperate with peers invoking the same technique and
-   protocol outside the GSS-API paradigm.  For example, the format of
-   GSS-API tokens defined in conjunction with a particular mechanism,
-   and the techniques used to integrate those tokens into callers'
-   protocols, may not be the same as those used by non-GSS-API callers
-   of the same underlying technique.
-
-1.1.3.  Security Contexts
-
-   Security contexts are established between peers, using credentials
-   established locally in conjunction with each peer or received by
-   peers via delegation. Multiple contexts may exist simultaneously
-   between a pair of peers, using the same or different sets of
-   credentials. Coexistence of multiple contexts using different
-   credentials allows graceful rollover when credentials expire.
-   Distinction among multiple contexts based on the same credentials
-   serves applications by distinguishing different message streams in a
-   security sense.
-
-   The GSS-API is independent of underlying protocols and addressing
-   structure, and depends on its callers to transport GSS-API-provided
-   data elements. As a result of these factors, it is a caller
-   responsibility to parse communicated messages, separating GSS-API-
-   related data elements from caller-provided data.  The GSS-API is
-   independent of connection vs. connectionless orientation of the
-   underlying communications service.
-
-   No correlation between security context and communications protocol
-   association is dictated. (The optional channel binding facility,
-   discussed in Section 1.1.6 of this document, represents an
-   intentional exception to this rule, supporting additional protection
-   features within GSS-API supporting mechanisms.) This separation
-   allows the GSS-API to be used in a wide range of communications
-
-
-
-Linn                                                            [Page 7]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   environments, and also simplifies the calling sequences of the
-   individual calls. In many cases (depending on underlying security
-   protocol, associated mechanism, and availability of cached
-   information), the state information required for context setup can be
-   sent concurrently with initial signed user data, without interposing
-   additional message exchanges.
-
-1.1.4.  Mechanism Types
-
-   In order to successfully establish a security context with a target
-   peer, it is necessary to identify an appropriate underlying mechanism
-   type (mech_type) which both initiator and target peers support. The
-   definition of a mechanism embodies not only the use of a particular
-   cryptographic technology (or a hybrid or choice among alternative
-   cryptographic technologies), but also definition of the syntax and
-   semantics of data element exchanges which that mechanism will employ
-   in order to support security services.
-
-   It is recommended that callers initiating contexts specify the
-   "default" mech_type value, allowing system-specific functions within
-   or invoked by the GSS-API implementation to select the appropriate
-   mech_type, but callers may direct that a particular mech_type be
-   employed when necessary.
-
-   The means for identifying a shared mech_type to establish a security
-   context with a peer will vary in different environments and
-   circumstances; examples include (but are not limited to):
-
-      use of a fixed mech_type, defined by configuration, within an
-      environment
-
-      syntactic convention on a target-specific basis, through
-      examination of a target's name
-
-      lookup of a target's name in a naming service or other database in
-      order to identify mech_types supported by that target
-
-      explicit negotiation between GSS-API callers in advance of
-      security context setup
-
-   When transferred between GSS-API peers, mech_type specifiers (per
-   Appendix B, represented as Object Identifiers (OIDs)) serve to
-   qualify the interpretation of associated tokens. (The structure and
-   encoding of Object Identifiers is defined in ISO/IEC 8824,
-   "Specification of Abstract Syntax Notation One (ASN.1)" and in
-   ISO/IEC 8825, "Specification of Basic Encoding Rules for Abstract
-   Syntax Notation One (ASN.1)".) Use of hierarchically structured OIDs
-   serves to preclude ambiguous interpretation of mech_type specifiers.
-
-
-
-Linn                                                            [Page 8]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   The OID representing the DASS MechType, for example, is
-   1.3.12.2.1011.7.5.
-
-1.1.5.  Naming
-
-   The GSS-API avoids prescription of naming structures, treating the
-   names transferred across the interface in order to initiate and
-   accept security contexts as opaque octet string quantities.  This
-   approach supports the GSS-API's goal of implementability atop a range
-   of underlying security mechanisms, recognizing the fact that
-   different mechanisms process and authenticate names which are
-   presented in different forms. Generalized services offering
-   translation functions among arbitrary sets of naming environments are
-   outside the scope of the GSS-API; availability and use of local
-   conversion functions to translate among the naming formats supported
-   within a given end system is anticipated.
-
-   Two distinct classes of name representations are used in conjunction
-   with different GSS-API parameters:
-
-      a printable form (denoted by OCTET STRING), for acceptance from
-      and presentation to users; printable name forms are accompanied by
-      OID tags identifying the namespace to which they correspond
-
-      an internal form (denoted by INTERNAL NAME), opaque to callers and
-      defined by individual GSS-API implementations; GSS-API
-      implementations supporting multiple namespace types are
-      responsible for maintaining internal tags to disambiguate the
-      interpretation of particular names
-
-      Tagging of printable names allows GSS-API callers and underlying
-      GSS-API mechanisms to disambiguate name types and to determine
-      whether an associated name's type is one which they are capable of
-      processing, avoiding aliasing problems which could result from
-      misinterpreting a name of one type as a name of another type.
-
-   In addition to providing means for names to be tagged with types,
-   this specification defines primitives to support a level of naming
-   environment independence for certain calling applications. To provide
-   basic services oriented towards the requirements of callers which
-   need not themselves interpret the internal syntax and semantics of
-   names, GSS-API calls for name comparison (GSS_Compare_name()),
-   human-readable display (GSS_Display_name()),  input conversion
-   (GSS_Import_name()), and internal name deallocation
-   (GSS_Release_name())  functions are defined. (It is anticipated that
-   these proposed GSS-API calls will be implemented in many end systems
-   based on system-specific name manipulation primitives already extant
-   within those end systems; inclusion within the GSS-API is intended to
-
-
-
-Linn                                                            [Page 9]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   offer GSS-API callers a portable means to perform specific
-   operations, supportive of authorization and audit requirements, on
-   authenticated names.)
-
-   GSS_Import_name()  implementations can, where appropriate, support
-   more than one printable syntax corresponding to a given namespace
-   (e.g., alternative printable representations for X.500 Distinguished
-   Names), allowing flexibility for their callers to select among
-   alternative representations. GSS_Display_name() implementations
-   output a printable syntax selected as appropriate to their
-   operational environments; this selection is a local matter. Callers
-   desiring portability across alternative printable syntaxes should
-   refrain from implementing comparisons based on printable name forms
-   and should instead use the GSS_Compare_name()  call to determine
-   whether or not one internal-format name matches another.
-
-1.1.6.  Channel Bindings
-
-   The GSS-API accommodates the concept of caller-provided channel
-   binding ("chan_binding") information, used by GSS-API callers to bind
-   the establishment of a security context to relevant characteristics
-   (e.g., addresses, transformed representations of encryption keys) of
-   the underlying communications channel and of protection mechanisms
-   applied to that communications channel.  Verification by one peer of
-   chan_binding information provided by the other peer to a context
-   serves to protect against various active attacks. The caller
-   initiating a security context must determine the chan_binding values
-   before making the GSS_Init_sec_context()  call, and consistent values
-   must be provided by both peers to a context. Callers should not
-   assume that underlying mechanisms provide confidentiality protection
-   for channel binding information.
-
-   Use or non-use of the GSS-API channel binding facility is a caller
-   option, and GSS-API supporting mechanisms can support operation in an
-   environment where NULL channel bindings are presented. When non-NULL
-   channel bindings are used, certain mechanisms will offer enhanced
-   security value by interpreting the bindings' content (rather than
-   simply representing those bindings, or signatures computed on them,
-   within tokens) and will therefore depend on presentation of specific
-   data in a defined format. To this end, agreements among mechanism
-   implementors are defining conventional interpretations for the
-   contents of channel binding arguments, including address specifiers
-   (with content dependent on communications protocol environment) for
-   context initiators and acceptors. (These conventions are being
-   incorporated into related documents.) In order for GSS-API callers to
-   be portable across multiple mechanisms and achieve the full security
-   functionality available from each mechanism, it is strongly
-   recommended that GSS-API callers provide channel bindings consistent
-
-
-
-Linn                                                           [Page 10]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   with these conventions and those of the networking environment in
-   which they operate.
-
-1.2.  GSS-API Features and Issues
-
-   This section describes aspects of GSS-API operations, of the security
-   services which the GSS-API provides, and provides commentary on
-   design issues.
-
-1.2.1.  Status Reporting
-
-   Each GSS-API call provides two status return values. Major_status
-   values provide a mechanism-independent indication of call status
-   (e.g., GSS_COMPLETE, GSS_FAILURE, GSS_CONTINUE_NEEDED), sufficient to
-   drive normal control flow within the caller in a generic fashion.
-   Table 1 summarizes the defined major_status return codes in tabular
-   fashion.
-
-   Table 1: GSS-API Major Status Codes
-
-      FATAL ERROR CODES
-
-      GSS_BAD_BINDINGS             channel binding mismatch
-      GSS_BAD_MECH                 unsupported mechanism requested
-      GSS_BAD_NAME                 invalid name provided
-      GSS_BAD_NAMETYPE             name of unsupported type provided
-      GSS_BAD_STATUS               invalid input status selector
-      GSS_BAD_SIG                  token had invalid signature
-      GSS_CONTEXT_EXPIRED          specified security context expired
-      GSS_CREDENTIALS_EXPIRED      expired credentials detected
-      GSS_DEFECTIVE_CREDENTIAL     defective credential detected
-      GSS_DEFECTIVE_TOKEN          defective token detected
-      GSS_FAILURE                  failure, unspecified at GSS-API
-                                   level
-      GSS_NO_CONTEXT               no valid security context specified
-      GSS_NO_CRED                  no valid credentials provided
-
-      INFORMATORY STATUS CODES
-
-      GSS_COMPLETE                 normal completion
-      GSS_CONTINUE_NEEDED          continuation call to routine
-                                   required
-      GSS_DUPLICATE_TOKEN          duplicate per-message token
-                                   detected
-      GSS_OLD_TOKEN                timed-out per-message token
-                                   detected
-      GSS_UNSEQ_TOKEN              out-of-order per-message token
-                                   detected
-
-
-
-Linn                                                           [Page 11]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   Minor_status provides more detailed status information which may
-   include status codes specific to the underlying security mechanism.
-   Minor_status values are not specified in this document.
-
-   GSS_CONTINUE_NEEDED major_status returns, and optional message
-   outputs, are provided in GSS_Init_sec_context()  and
-   GSS_Accept_sec_context()  calls so that different mechanisms'
-   employment of different numbers of messages within their
-   authentication sequences need not be reflected in separate code paths
-   within calling applications. Instead, such cases are accomodated with
-   sequences of continuation calls to GSS_Init_sec_context()  and
-   GSS_Accept_sec_context().  The same mechanism is used to encapsulate
-   mutual authentication within the GSS-API's context initiation calls.
-
-   For mech_types which require interactions with third-party servers in
-   order to establish a security context, GSS-API context establishment
-   calls may block pending completion of such third-party interactions.
-   On the other hand, no GSS-API calls pend on serialized interactions
-   with GSS-API peer entities.  As a result, local GSS-API status
-   returns cannot reflect unpredictable or asynchronous exceptions
-   occurring at remote peers, and reflection of such status information
-   is a caller responsibility outside the GSS-API.
-
-1.2.2. Per-Message Security Service Availability
-
-   When a context is established, two flags are returned to indicate the
-   set of per-message protection security services which will be
-   available on the context:
-
-      the integ_avail flag indicates whether per-message integrity and
-      data origin authentication services are available
-
-      the conf_avail flag indicates whether per-message confidentiality
-      services are available, and will never be returned TRUE unless the
-      integ_avail flag is also returned TRUE
-
-      GSS-API callers desiring per-message security services should
-      check the values of these flags at context establishment time, and
-      must be aware that a returned FALSE value for integ_avail means
-      that invocation of GSS_Sign()  or GSS_Seal() primitives on the
-      associated context will apply no cryptographic protection to user
-      data messages.
-
-   The GSS-API per-message protection service primitives, as the
-   category name implies, are oriented to operation at the granularity
-   of protocol data units. They perform cryptographic operations on the
-   data units, transfer cryptographic control information in tokens,
-   and, in the case of GSS_Seal(), encapsulate the protected data unit.
-
-
-
-Linn                                                           [Page 12]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   As such, these primitives are not oriented to efficient data
-   protection for stream-paradigm protocols (e.g., Telnet) if
-   cryptography must be applied on an octet-by-octet basis.
-
-1.2.3. Per-Message Replay Detection and Sequencing
-
-   Certain underlying mech_types are expected to offer support for
-   replay detection and/or sequencing of messages transferred on the
-   contexts they support. These optionally-selectable protection
-   features are distinct from replay detection and sequencing features
-   applied to the context establishment operation itself; the presence
-   or absence of context-level replay or sequencing features is wholly a
-   function of the underlying mech_type's capabilities, and is not
-   selected or omitted as a caller option.
-
-   The caller initiating a context provides flags (replay_det_req_flag
-   and sequence_req_flag) to specify whether the use of per-message
-   replay detection and sequencing features is desired on the context
-   being established. The GSS-API implementation at the initiator system
-   can determine whether these features are supported (and whether they
-   are optionally selectable) as a function of mech_type, without need
-   for bilateral negotiation with the target. When enabled, these
-   features provide recipients with indicators as a result of GSS-API
-   processing of incoming messages, identifying whether those messages
-   were detected as duplicates or out-of-sequence. Detection of such
-   events does not prevent a suspect message from being provided to a
-   recipient; the appropriate course of action on a suspect message is a
-   matter of caller policy.
-
-   The semantics of the replay detection and sequencing services applied
-   to received messages, as visible across the interface which the GSS-
-   API provides to its clients, are as follows:
-
-   When replay_det_state is TRUE, the possible major_status returns for
-   well-formed and correctly signed messages are as follows:
-
-      1. GSS_COMPLETE indicates that the message was within the window
-      (of time or sequence space) allowing replay events to be detected,
-      and that the message was not a replay of a previously-processed
-      message within that window.
-
-      2. GSS_DUPLICATE_TOKEN indicates that the signature on the
-      received message was correct, but that the message was recognized
-      as a duplicate of a previously-processed message.
-
-      3. GSS_OLD_TOKEN indicates that the signature on the received
-      message was correct, but that the message is too old to be checked
-      for duplication.
-
-
-
-Linn                                                           [Page 13]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   When sequence_state is TRUE, the possible major_status returns for
-   well-formed and correctly signed messages are as follows:
-
-      1. GSS_COMPLETE indicates that the message was within the window
-      (of time or sequence space) allowing replay events to be detected,
-      and that the message was not a replay of a previously-processed
-      message within that window.
-
-      2. GSS_DUPLICATE_TOKEN indicates that the signature on the
-      received message was correct, but that the message was recognized
-      as a duplicate of a previously-processed message.
-
-      3. GSS_OLD_TOKEN indicates that the signature on the received
-      message was correct, but that the token is too old to be checked
-      for duplication.
-
-      4. GSS_UNSEQ_TOKEN indicates that the signature on the received
-      message was correct, but that it is earlier in a sequenced stream
-      than a message already processed on the context.  [Note:
-      Mechanisms can be architected to provide a stricter form of
-      sequencing service, delivering particular messages to recipients
-      only after all predecessor messages in an ordered stream have been
-      delivered.  This type of support is incompatible with the GSS-API
-      paradigm in which recipients receive all messages, whether in
-      order or not, and provide them (one at a time, without intra-GSS-
-      API message buffering) to GSS-API routines for validation.  GSS-
-      API facilities provide supportive functions, aiding clients to
-      achieve strict message stream integrity in an efficient manner in
-      conjunction with sequencing provisions in communications
-      protocols, but the GSS-API does not offer this level of message
-      stream integrity service by itself.]
-
-   As the message stream integrity features (especially sequencing) may
-   interfere with certain applications' intended communications
-   paradigms, and since support for such features is likely to be
-   resource intensive, it is highly recommended that mech_types
-   supporting these features allow them to be activated selectively on
-   initiator request when a context is established. A context initiator
-   and target are provided with corresponding indicators
-   (replay_det_state and sequence_state), signifying whether these
-   features are active on a given context.
-
-   An example mech_type supporting per-message replay detection could
-   (when replay_det_state is TRUE) implement the feature as follows: The
-   underlying mechanism would insert timestamps in data elements output
-   by GSS_Sign() and GSS_Seal(), and would maintain (within a time-
-   limited window) a cache (qualified by originator-recipient pair)
-   identifying received data elements processed by GSS_Verify() and
-
-
-
-Linn                                                           [Page 14]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   GSS_Unseal(). When this feature is active, exception status returns
-   (GSS_DUPLICATE_TOKEN, GSS_ OLD_TOKEN) will be provided when
-   GSS_Verify() or GSS_Unseal() is presented with a message which is
-   either a detected duplicate of a prior message or which is too old to
-   validate against a cache of recently received messages.
-
-1.2.4.  Quality of Protection
-
-   Some mech_types will provide their users with fine granularity
-   control over the means used to provide per-message protection,
-   allowing callers to trade off security processing overhead
-   dynamically against the protection requirements of particular
-   messages. A per-message quality-of-protection parameter (analogous to
-   quality-of-service, or QOS) selects among different QOP options
-   supported by that mechanism. On context establishment for a multi-QOP
-   mech_type, context-level data provides the prerequisite data for a
-   range of protection qualities.
-
-   It is expected that the majority of callers will not wish to exert
-   explicit mechanism-specific QOP control and will therefore request
-   selection of a default QOP. Definitions of, and choices among, non-
-   default QOP values are mechanism-specific, and no ordered sequences
-   of QOP values can be assumed equivalent across different mechanisms.
-   Meaningful use of non-default QOP values demands that callers be
-   familiar with the QOP definitions of an underlying mechanism or
-   mechanisms, and is therefore a non-portable construct.
-
-2.  Interface Descriptions
-
-   This section describes the GSS-API's service interface, dividing the
-   set of calls offered into four groups. Credential management calls
-   are related to the acquisition and release of credentials by
-   principals. Context-level calls are related to the management of
-   security contexts between principals. Per-message calls are related
-   to the protection of individual messages on established security
-   contexts. Support calls provide ancillary functions useful to GSS-API
-   callers. Table 2 groups and summarizes the calls in tabular fashion.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn                                                           [Page 15]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-      Table 2:  GSS-API Calls
-
-      CREDENTIAL MANAGEMENT
-
-      GSS_Acquire_cred             acquire credentials for use
-      GSS_Release_cred             release credentials after use
-      GSS_Inquire_cred             display information about
-                                   credentials
-
-      CONTEXT-LEVEL CALLS
-
-      GSS_Init_sec_context         initiate outbound security context
-      GSS_Accept_sec_context       accept inbound security context
-      GSS_Delete_sec_context       flush context when no longer needed
-      GSS_Process_context_token    process received control token on
-                                   context
-      GSS_Context_time             indicate validity time remaining on
-                                   context
-
-      PER-MESSAGE CALLS
-
-      GSS_Sign                     apply signature, receive as token
-                                   separate from message
-      GSS_Verify                   validate signature token along with
-                                   message
-      GSS_Seal                     sign, optionally encrypt,
-                                   encapsulate
-      GSS_Unseal                   decapsulate, decrypt if needed,
-                                   validate signature
-
-      SUPPORT CALLS
-
-      GSS_Display_status           translate status codes to printable
-                                   form
-      GSS_Indicate_mechs           indicate mech_types supported on
-                                   local system
-      GSS_Compare_name             compare two names for equality
-      GSS_Display_name             translate name to printable form
-      GSS_Import_name              convert printable name to
-                                   normalized form
-      GSS_Release_name             free storage of normalized-form
-                                   name
-      GSS_Release_buffer           free storage of printable name
-      GSS_Release_oid_set          free storage of OID set object
-
-
-
-
-
-
-
-Linn                                                           [Page 16]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-2.1.  Credential management calls
-
-   These GSS-API calls provide functions related to the management of
-   credentials. Their characterization with regard to whether or not
-   they may block pending exchanges with other network entities (e.g.,
-   directories or authentication servers) depends in part on OS-specific
-   (extra-GSS-API) issues, so is not specified in this document.
-
-   The GSS_Acquire_cred()  call is defined within the GSS-API in support
-   of application portability, with a particular orientation towards
-   support of portable server applications. It is recognized that (for
-   certain systems and mechanisms) credentials for interactive users may
-   be managed differently from credentials for server processes; in such
-   environments, it is the GSS-API implementation's responsibility to
-   distinguish these cases and the procedures for making this
-   distinction are a local matter. The GSS_Release_cred()  call provides
-   a means for callers to indicate to the GSS-API that use of a
-   credentials structure is no longer required. The GSS_Inquire_cred()
-   call allows callers to determine information about a credentials
-   structure.
-
-2.1.1.  GSS_Acquire_cred call
-
-   Inputs:
-
-   o  desired_name INTERNAL NAME, -NULL requests locally-determined
-      default
-
-   o  lifetime_req INTEGER,-in seconds; 0 requests default
-
-   o  desired_mechs SET OF OBJECT IDENTIFIER,-empty set requests
-      system-selected default
-
-   o  cred_usage INTEGER-0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-      2=ACCEPT-ONLY
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_cred_handle OCTET STRING,
-
-   o  actual_mechs SET OF OBJECT IDENTIFIER,
-
-   o  lifetime_rec INTEGER -in seconds, or reserved value for
-      INDEFINITE
-
-
-
-Linn                                                           [Page 17]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that requested credentials were
-      successfully established, for the duration indicated in
-      lifetime_rec, suitable for the usage requested in cred_usage, for
-      the set of mech_types indicated in actual_mechs, and that those
-      credentials can be referenced for subsequent use with the handle
-      returned in output_cred_handle.
-
-   o  GSS_BAD_MECH indicates that a mech_type unsupported by the GSS-API
-      implementation type was requested, causing the credential
-      establishment operation to fail.
-
-   o  GSS_BAD_NAMETYPE indicates that the provided desired_name is
-      uninterpretable or of a type unsupported by the supporting GSS-API
-      implementation, so no credentials could be established for the
-      accompanying desired_name.
-
-   o  GSS_BAD_NAME indicates that the provided desired_name is
-      inconsistent in terms of internally-incorporated type specifier
-      information, so no credentials could be established for the
-      accompanying desired_name.
-
-   o  GSS_FAILURE indicates that credential establishment failed for
-      reasons unspecified at the GSS-API level, including lack of
-      authorization to establish and use credentials associated with the
-      identity named in the input desired_name argument.
-
-   GSS_Acquire_cred()  is used to acquire credentials so that a
-   principal can (as a function of the input cred_usage parameter)
-   initiate and/or accept security contexts under the identity
-   represented by the desired_name input argument. On successful
-   completion, the returned output_cred_handle result provides a handle
-   for subsequent references to the acquired credentials.  Typically,
-   single-user client processes using only default credentials for
-   context establishment purposes will have no need to invoke this call.
-
-   A caller may provide the value NULL for desired_name, signifying a
-   request for credentials corresponding to a default principal
-   identity.  The procedures used by GSS-API implementations to select
-   the appropriate principal identity in response to this form of
-   request are local matters. It is possible that multiple pre-
-   established credentials may exist for the same principal identity
-   (for example, as a result of multiple user login sessions) when
-   GSS_Acquire_cred() is called; the means used in such cases to select
-   a specific credential are local matters.  The input lifetime_req
-   argument to GSS_Acquire_cred() may provide useful information for
-   local GSS-API implementations to employ in making this disambiguation
-
-
-
-Linn                                                           [Page 18]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   in a manner which will best satisfy a caller's intent.
-
-   The lifetime_rec result indicates the length of time for which the
-   acquired credentials will be valid, as an offset from the present. A
-   mechanism may return a reserved value indicating INDEFINITE if no
-   constraints on credential lifetime are imposed.  A caller of
-   GSS_Acquire_cred()  can request a length of time for which acquired
-   credentials are to be valid (lifetime_req argument), beginning at the
-   present, or can request credentials with a default validity interval.
-   (Requests for postdated credentials are not supported within the
-   GSS-API.) Certain mechanisms and implementations may bind in
-   credential validity period specifiers at a point preliminary to
-   invocation of the GSS_Acquire_cred() call (e.g., in conjunction with
-   user login procedures). As a result, callers requesting non-default
-   values for lifetime_req must recognize that such requests cannot
-   always be honored and must be prepared to accommodate the use of
-   returned credentials with different lifetimes as indicated in
-   lifetime_rec.
-
-   The caller of GSS_Acquire_cred() can explicitly specify a set of
-   mech_types which are to be accommodated in the returned credentials
-   (desired_mechs argument), or can request credentials for a system-
-   defined default set of mech_types. Selection of the system-specified
-   default set is recommended in the interests of application
-   portability. The actual_mechs return value may be interrogated by the
-   caller to determine the set of mechanisms with which the returned
-   credentials may be used.
-
-2.1.2.  GSS_Release_cred call
-
-   Input:
-
-   o  cred_handle OCTET STRING-NULL specifies default credentials
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that the credentials referenced by the
-      input cred_handle were released for purposes of subsequent access
-      by the caller. The effect on other processes which may be
-      authorized shared access to such credentials is a local matter.
-
-
-
-
-
-Linn                                                           [Page 19]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   o  GSS_NO_CRED indicates that no release operation was performed,
-      either because the input cred_handle was invalid or because the
-      caller lacks authorization to access the referenced credentials.
-
-   o  GSS_FAILURE indicates that the release operation failed for
-      reasons unspecified at the GSS-API level.
-
-   Provides a means for a caller to explicitly request that credentials
-   be released when their use is no longer required. Note that system-
-   specific credential management functions are also likely to exist,
-   for example to assure that credentials shared among processes are
-   properly deleted when all affected processes terminate, even if no
-   explicit release requests are issued by those processes.  Given the
-   fact that multiple callers are not precluded from gaining authorized
-   access to the same credentials, invocation of GSS_Release_cred()
-   cannot be assumed to delete a particular set of credentials on a
-   system-wide basis.
-
-2.1.3.  GSS_Inquire_cred call
-
-      Input:
-
-      o  cred_handle OCTET STRING -NULL specifies default credentials
-
-      Outputs:
-
-      o  major_status INTEGER,
-
-      o  minor_status INTEGER,
-
-      o  cred_name INTERNAL NAME,
-
-      o  lifetime_rec INTEGER -in seconds, or reserved value for
-         INDEFINITE
-
-      o  cred_usage INTEGER, -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-         2=ACCEPT-ONLY
-
-      o  mech_set SET OF OBJECT IDENTIFIER
-
-      Return major_status codes:
-
-      o  GSS_COMPLETE indicates that the credentials referenced by the
-         input cred_handle argument were valid, and that the output
-         cred_name, lifetime_rec, and cred_usage values represent,
-         respectively, the credentials' associated principal name,
-         remaining lifetime, suitable usage modes, and supported
-         mechanism types.
-
-
-
-Linn                                                           [Page 20]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-      o  GSS_NO_CRED indicates that no information could be returned
-         about the referenced credentials, either because the input
-         cred_handle was invalid or because the caller lacks
-         authorization to access the referenced credentials.
-
-      o  GSS_FAILURE indicates that the release operation failed for
-         reasons unspecified at the GSS-API level.
-
-   The GSS_Inquire_cred()  call is defined primarily for the use of
-   those callers which make use of default credentials rather than
-   acquiring credentials explicitly with GSS_Acquire_cred().  It enables
-   callers to determine a credential structure's associated principal
-   name, remaining validity period, usability for security context
-   initiation and/or acceptance, and supported mechanisms.
-
-2.2.  Context-level calls
-
-   This group of calls is devoted to the establishment and management of
-   security contexts between peers. A context's initiator calls
-   GSS_Init_sec_context(),  resulting in generation of a token which the
-   caller passes to the target. At the target, that token is passed to
-   GSS_Accept_sec_context().  Depending on the underlying mech_type and
-   specified options, additional token exchanges may be performed in the
-   course of context establishment; such exchanges are accommodated by
-   GSS_CONTINUE_NEEDED status returns from GSS_Init_sec_context()  and
-   GSS_Accept_sec_context().  Either party to an established context may
-   invoke GSS_Delete_sec_context()  to flush context information when a
-   context is no longer required. GSS_Process_context_token()  is used
-   to process received tokens carrying context-level control
-   information. GSS_Context_time()  allows a caller to determine the
-   length of time for which an established context will remain valid.
-
-2.2.1.  GSS_Init_sec_context call
-
-   Inputs:
-
-   o  claimant_cred_handle OCTET STRING, -NULL specifies "use
-      default"
-
-   o  input_context_handle INTEGER, -0 specifies "none assigned
-      yet"
-
-   o  targ_name INTERNAL NAME,
-
-   o  mech_type OBJECT IDENTIFIER, -NULL parameter specifies "use
-      default"
-
-   o  deleg_req_flag BOOLEAN,
-
-
-
-Linn                                                           [Page 21]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   o  mutual_req_flag BOOLEAN,
-
-   o  replay_det_req_flag BOOLEAN,
-
-   o  sequence_req_flag BOOLEAN,
-
-   o  lifetime_req INTEGER,-0 specifies default lifetime
-
-   o  chan_bindings OCTET STRING,
-
-   o  input_token OCTET STRING-NULL or token received from target
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_context_handle INTEGER,
-
-   o  mech_type OBJECT IDENTIFIER, -actual mechanism always
-      indicated, never NULL
-
-   o  output_token OCTET STRING, -NULL or token to pass to context
-      target
-
-   o  deleg_state BOOLEAN,
-
-   o  mutual_state BOOLEAN,
-
-   o  replay_det_state BOOLEAN,
-
-   o  sequence_state BOOLEAN,
-
-   o  conf_avail BOOLEAN,
-
-   o  integ_avail BOOLEAN,
-
-   o  lifetime_rec INTEGER - in seconds, or reserved value for
-      INDEFINITE
-
-   This call may block pending network interactions for those mech_types
-   in which an authentication server or other network entity must be
-   consulted on behalf of a context initiator in order to generate an
-   output_token suitable for presentation to a specified target.
-
-   Return major_status codes:
-
-
-
-
-Linn                                                           [Page 22]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   o  GSS_COMPLETE indicates that context-level information was
-      successfully initialized, and that the returned output_token will
-      provide sufficient information for the target to perform per-
-      message processing on the newly-established context.
-
-   o  GSS_CONTINUE_NEEDED indicates that control information in the
-      returned output_token must be sent to the target, and that a reply
-      must be received and passed as the input_token argument to a
-      continuation call to GSS_Init_sec_context(),  before per-message
-      processing can be performed in conjunction with this context.
-
-   o  GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
-      the input_token failed, preventing further processing from being
-      performed based on that token.
-
-   o  GSS_DEFECTIVE_CREDENTIAL indicates that consistency checks
-      performed on the credential structure referenced by
-      claimant_cred_handle failed, preventing further processing from
-      being performed using that credential structure.
-
-   o  GSS_BAD_SIG indicates that the received input_token contains an
-      incorrect signature, so context setup cannot be accomplished.
-
-   o  GSS_NO_CRED indicates that no context was established, either
-      because the input cred_handle was invalid, because the referenced
-      credentials are valid for context acceptor use only, or because
-      the caller lacks authorization to access the referenced
-      credentials.
-
-   o  GSS_CREDENTIALS_EXPIRED indicates that the credentials provided
-      through the input claimant_cred_handle argument are no longer
-      valid, so context establishment cannot be completed.
-
-   o  GSS_BAD_BINDINGS indicates that a mismatch between the caller-
-      provided chan_bindings and those extracted from the input_token
-      was detected, signifying a security-relevant event and preventing
-      context establishment. (This result will be returned by
-      GSS_Init_sec_context only for contexts where mutual_state is
-      TRUE.)
-
-   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
-      the input context_handle provided; this major status will be
-      returned only for successor calls following GSS_CONTINUE_NEEDED
-      status returns.
-
-   o  GSS_BAD_NAMETYPE indicates that the provided targ_name is of a
-      type uninterpretable or unsupported by the supporting GSS-API
-      implementation, so context establishment cannot be completed.
-
-
-
-Linn                                                           [Page 23]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   o  GSS_BAD_NAME indicates that the provided targ_name is inconsistent
-      in terms of internally-incorporated type specifier information, so
-      context establishment cannot be accomplished.
-
-   o  GSS_FAILURE indicates that context setup could not be accomplished
-      for reasons unspecified at the GSS-API level, and that no
-      interface-defined recovery action is available.
-
-   This routine is used by a context initiator, and ordinarily emits one
-   (or, for the case of a multi-step exchange, more than one)
-   output_token suitable for use by the target within the selected
-   mech_type's protocol. Using information in the credentials structure
-   referenced by claimant_cred_handle, GSS_Init_sec_context()
-   initializes the data structures required to establish a security
-   context with target targ_name. The claimant_cred_handle must
-   correspond to the same valid credentials structure on the initial
-   call to GSS_Init_sec_context()  and on any successor calls resulting
-   from GSS_CONTINUE_NEEDED status returns; different protocol sequences
-   modeled by the GSS_CONTINUE_NEEDED mechanism will require access to
-   credentials at different points in the context establishment
-   sequence.
-
-   The input_context_handle argument is 0, specifying "not yet
-   assigned", on the first GSS_Init_sec_context()  call relating to a
-   given context. That call returns an output_context_handle for future
-   references to this context. When continuation attempts to
-   GSS_Init_sec_context()  are needed to perform context establishment,
-   the previously-returned non-zero handle value is entered into the
-   input_context_handle argument and will be echoed in the returned
-   output_context_handle argument. On such continuation attempts (and
-   only on continuation attempts) the input_token value is used, to
-   provide the token returned from the context's target.
-
-   The chan_bindings argument is used by the caller to provide
-   information binding the security context to security-related
-   characteristics (e.g., addresses, cryptographic keys) of the
-   underlying communications channel. See Section 1.1.6 of this document
-   for more discussion of this argument's usage.
-
-   The input_token argument contains a message received from the target,
-   and is significant only on a call to GSS_Init_sec_context() which
-   follows a previous return indicating GSS_CONTINUE_NEEDED
-   major_status.
-
-   It is the caller's responsibility to establish a communications path
-   to the target, and to transmit any returned output_token (independent
-   of the accompanying returned major_status value) to the target over
-   that path. The output_token can, however, be transmitted along with
-
-
-
-Linn                                                           [Page 24]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   the first application-provided input message to be processed by
-   GSS_Sign() or GSS_Seal() in conjunction with a successfully-
-   established context.
-
-   The initiator may request various context-level functions through
-   input flags: the deleg_req_flag requests delegation of access rights,
-   the mutual_req_flag requests mutual authentication, the
-   replay_det_req_flag requests that replay detection features be
-   applied to messages transferred on the established context, and the
-   sequence_req_flag requests that sequencing be enforced. (See Section
-   1.2.3 for more information on replay detection and sequencing
-   features.)
-
-   Not all of the optionally-requestable features will be available in
-   all underlying mech_types; the corresponding return state values
-   (deleg_state, mutual_state, replay_det_state, sequence_state)
-   indicate, as a function of mech_type processing capabilities and
-   initiator-provided input flags, the set of features which will be
-   active on the context. These state indicators' values are undefined
-   unless the routine's major_status indicates COMPLETE. Failure to
-   provide the precise set of features requested by the caller does not
-   cause context establishment to fail; it is the caller's prerogative
-   to delete the context if the feature set provided is unsuitable for
-   the caller's use.  The returned mech_type value indicates the
-   specific mechanism employed on the context, and will never indicate
-   the value for "default".
-
-   The conf_avail return value indicates whether the context supports
-   per-message confidentiality services, and so informs the caller
-   whether or not a request for encryption through the conf_req_flag
-   input to GSS_Seal() can be honored. In similar fashion, the
-   integ_avail return value indicates whether per-message integrity
-   services are available (through either GSS_Sign() or GSS_Seal()) on
-   the established context.
-
-   The lifetime_req input specifies a desired upper bound for the
-   lifetime of the context to be established, with a value of 0 used to
-   request a default lifetime. The lifetime_rec return value indicates
-   the length of time for which the context will be valid, expressed as
-   an offset from the present; depending on mechanism capabilities,
-   credential lifetimes, and local policy, it may not correspond to the
-   value requested in lifetime_req.  If no constraints on context
-   lifetime are imposed, this may be indicated by returning a reserved
-   value representing INDEFINITE lifetime_req. The values of conf_avail,
-   integ_avail, and lifetime_rec are undefined unless the routine's
-   major_status indicates COMPLETE.
-
-   If the mutual_state is TRUE, this fact will be reflected within the
-
-
-
-Linn                                                           [Page 25]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   output_token. A call to GSS_Accept_sec_context() at the target in
-   conjunction with such a context will return a token, to be processed
-   by a continuation call to GSS_Init_sec_context(), in order to achieve
-   mutual authentication.
-
-2.2.2.  GSS_Accept_sec_context call
-
-   Inputs:
-
-   o  acceptor_cred_handle OCTET STRING,-NULL specifies "use
-      default"
-
-   o  input_context_handle INTEGER, -0 specifies "not yet assigned"
-
-   o  chan_bindings OCTET STRING,
-
-   o  input_token OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  src_name INTERNAL NAME,
-
-   o  mech_type OBJECT IDENTIFIER,
-
-   o  output_context_handle INTEGER,
-
-   o  deleg_state BOOLEAN,
-
-   o  mutual_state BOOLEAN,
-
-   o  replay_det_state BOOLEAN,
-
-   o  sequence_state BOOLEAN,
-
-   o  conf_avail BOOLEAN,
-
-   o  integ_avail BOOLEAN,
-
-   o  lifetime_rec INTEGER, - in seconds, or reserved value for
-      INDEFINITE
-
-   o  delegated_cred_handle OCTET STRING,
-
-   o  output_token OCTET STRING -NULL or token to pass to context
-
-
-
-Linn                                                           [Page 26]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-      initiator
-
-   This call may block pending network interactions for those mech_types
-   in which a directory service or other network entity must be
-   consulted on behalf of a context acceptor in order to validate a
-   received input_token.
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that context-level data structures were
-      successfully initialized, and that per-message processing can now
-      be performed in conjunction with this context.
-
-   o  GSS_CONTINUE_NEEDED indicates that control information in the
-      returned output_token must be sent to the initiator, and that a
-      response must be received and passed as the input_token argument
-      to a continuation call to GSS_Accept_sec_context(), before per-
-      message processing can be performed in conjunction with this
-      context.
-
-   o  GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
-      the input_token failed, preventing further processing from being
-      performed based on that token.
-
-   o  GSS_DEFECTIVE_CREDENTIAL indicates that consistency checks
-      performed on the credential structure referenced by
-      acceptor_cred_handle failed, preventing further processing from
-      being performed using that credential structure.
-
-   o  GSS_BAD_SIG indicates that the received input_token contains an
-      incorrect signature, so context setup cannot be accomplished.
-
-   o  GSS_DUPLICATE_TOKEN indicates that the signature on the received
-      input_token was correct, but that the input_token was recognized
-      as a duplicate of an input_token already processed. No new context
-      is established.
-
-   o  GSS_OLD_TOKEN indicates that the signature on the received
-      input_token was correct, but that the input_token is too old to be
-      checked for duplication against previously-processed input_tokens.
-      No new context is established.
-
-   o  GSS_NO_CRED indicates that no context was established, either
-      because the input cred_handle was invalid, because the referenced
-      credentials are valid for context initiator use only, or because
-      the caller lacks authorization to access the referenced
-      credentials.
-
-
-
-
-Linn                                                           [Page 27]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   o  GSS_CREDENTIALS_EXPIRED indicates that the credentials provided
-      through the input acceptor_cred_handle argument are no longer
-      valid, so context establishment cannot be completed.
-
-   o  GSS_BAD_BINDINGS indicates that a mismatch between the caller-
-      provided chan_bindings and those extracted from the input_token
-      was detected, signifying a security-relevant event and preventing
-      context establishment.
-
-   o GSS_NO_CONTEXT indicates that no valid context was recognized for
-      the input context_handle provided; this major status will be
-      returned only for successor calls following GSS_CONTINUE_NEEDED
-      status returns.
-
-   o  GSS_FAILURE indicates that context setup could not be accomplished
-      for reasons unspecified at the GSS-API level, and that no
-      interface-defined recovery action is available.
-
-   The GSS_Accept_sec_context()  routine is used by a context target.
-   Using information in the credentials structure referenced by the
-   input acceptor_cred_handle, it verifies the incoming input_token and
-   (following the successful completion of a context establishment
-   sequence) returns the authenticated src_name and the mech_type used.
-   The acceptor_cred_handle must correspond to the same valid
-   credentials structure on the initial call to GSS_Accept_sec_context()
-   and on any successor calls resulting from GSS_CONTINUE_NEEDED status
-   returns; different protocol sequences modeled by the
-   GSS_CONTINUE_NEEDED mechanism will require access to credentials at
-   different points in the context establishment sequence.
-
-   The input_context_handle argument is 0, specifying "not yet
-   assigned", on the first GSS_Accept_sec_context()  call relating to a
-   given context. That call returns an output_context_handle for future
-   references to this context; when continuation attempts to
-   GSS_Accept_sec_context()  are needed to perform context
-   establishment, that handle value will be entered into the
-   input_context_handle argument.
-
-   The chan_bindings argument is used by the caller to provide
-   information binding the security context to security-related
-   characteristics (e.g., addresses, cryptographic keys) of the
-   underlying communications channel. See Section 1.1.6 of this document
-   for more discussion of this argument's usage.
-
-   The returned state results (deleg_state, mutual_state,
-   replay_det_state, and sequence_state) reflect the same context state
-   values as returned to GSS_Init_sec_context()'s  caller at the
-   initiator system.
-
-
-
-Linn                                                           [Page 28]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   The conf_avail return value indicates whether the context supports
-   per-message confidentiality services, and so informs the caller
-   whether or not a request for encryption through the conf_req_flag
-   input to GSS_Seal()  can be honored. In similar fashion, the
-   integ_avail return value indicates whether per-message integrity
-   services are available (through either GSS_Sign()  or GSS_Seal())  on
-   the established context.
-
-   The lifetime_rec return value indicates the length of time for which
-   the context will be valid, expressed as an offset from the present.
-   The values of deleg_state, mutual_state, replay_det_state,
-   sequence_state, conf_avail, integ_avail, and lifetime_rec are
-   undefined unless the accompanying major_status indicates COMPLETE.
-
-   The delegated_cred_handle result is significant only when deleg_state
-   is TRUE, and provides a means for the target to reference the
-   delegated credentials. The output_token result, when non-NULL,
-   provides a context-level token to be returned to the context
-   initiator to continue a multi-step context establishment sequence. As
-   noted with GSS_Init_sec_context(),  any returned token should be
-   transferred to the context's peer (in this case, the context
-   initiator), independent of the value of the accompanying returned
-   major_status.
-
-   Note: A target must be able to distinguish a context-level
-   input_token, which is passed to GSS_Accept_sec_context(),  from the
-   per-message data elements passed to GSS_Verify()  or GSS_Unseal().
-   These data elements may arrive in a single application message, and
-   GSS_Accept_sec_context()  must be performed before per-message
-   processing can be performed successfully.
-
-2.2.3. GSS_Delete_sec_context call
-
-   Input:
-
-   o  context_handle INTEGER
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_context_token OCTET STRING
-
-   Return major_status codes:
-
-
-
-
-
-Linn                                                           [Page 29]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   o  GSS_COMPLETE indicates that the context was recognized, that
-      relevant context-specific information was flushed, and that the
-      returned output_context_token is ready for transfer to the
-      context's peer.
-
-   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
-      the input context_handle provide, so no deletion was performed.
-
-   o  GSS_FAILURE indicates that the context is recognized, but that the
-      GSS_Delete_sec_context()  operation could not be performed for
-      reasons unspecified at the GSS-API level.
-
-   This call may block pending network interactions for mech_types in
-   which active notification must be made to a central server when a
-   security context is to be deleted.
-
-   This call can be made by either peer in a security context, to flush
-   context-specific information and to return an output_context_token
-   which can be passed to the context's peer informing it that the
-   peer's corresponding context information can also be flushed. (Once a
-   context is established, the peers involved are expected to retain
-   cached credential and context-related information until the
-   information's expiration time is reached or until a
-   GSS_Delete_sec_context() call is made.) Attempts to perform per-
-   message processing on a deleted context will result in error returns.
-
-2.2.4.  GSS_Process_context_token call
-
-   Inputs:
-
-   o  context_handle INTEGER,
-
-   o  input_context_token OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that the input_context_token was
-      successfully processed in conjunction with the context referenced
-      by context_handle.
-
-   o  GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
-      the received context_token failed, preventing further processing
-
-
-
-Linn                                                           [Page 30]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-      from being performed with that token.
-
-   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
-      the input context_handle provided.
-
-   o  GSS_FAILURE indicates that the context is recognized, but that the
-      GSS_Process_context_token()  operation could not be performed for
-      reasons unspecified at the GSS-API level.
-
-   This call is used to process context_tokens received from a peer once
-   a context has been established, with corresponding impact on
-   context-level state information. One use for this facility is
-   processing of the context_tokens generated by
-   GSS_Delete_sec_context();  GSS_Process_context_token() will not block
-   pending network interactions for that purpose. Another use is to
-   process tokens indicating remote-peer context establishment failures
-   after the point where the local GSS-API implementation has already
-   indicated GSS_COMPLETE status.
-
-2.2.5.  GSS_Context_time call
-
-   Input:
-
-   o  context_handle INTEGER,
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  lifetime_rec INTEGER - in seconds, or reserved value for
-      INDEFINITE
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that the referenced context is valid, and
-      will remain valid for the amount of time indicated in
-      lifetime_rec.
-
-   o  GSS_CONTEXT_EXPIRED indicates that data items related to the
-      referenced context have expired.
-
-   o  GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
-      but that its associated credentials have expired.
-
-   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
-      the input context_handle provided.
-
-
-
-Linn                                                           [Page 31]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   o  GSS_FAILURE indicates that the requested operation failed for
-      reasons unspecified at the GSS-API level.
-
-   This call is used to determine the amount of time for which a
-   currently established context will remain valid.
-
-2.3.  Per-message calls
-
-   This group of calls is used to perform per-message protection
-   processing on an established security context. None of these calls
-   block pending network interactions. These calls may be invoked by a
-   context's initiator or by the context's target.  The four members of
-   this group should be considered as two pairs; the output from
-   GSS_Sign()  is properly input to GSS_Verify(),  and the output from
-   GSS_Seal() is properly input to GSS_Unseal().
-
-   GSS_Sign()  and GSS_Verify() support data origin authentication and
-   data integrity services. When GSS_Sign()  is invoked on an input
-   message, it yields a per-message token containing data items which
-   allow underlying mechanisms to provide the specified security
-   services. The original message, along with the generated per-message
-   token, is passed to the remote peer; these two data elements are
-   processed by GSS_Verify(),  which validates the message in
-   conjunction with the separate token.
-
-   GSS_Seal()  and GSS_Unseal() support caller-requested confidentiality
-   in addition to the data origin authentication and data integrity
-   services offered by GSS_Sign()  and GSS_Verify(). GSS_Seal()  outputs
-   a single data element, encapsulating optionally enciphered user data
-   as well as associated token data items.  The data element output from
-   GSS_Seal()  is passed to the remote peer and processed by
-   GSS_Unseal()  at that system. GSS_Unseal() combines decipherment (as
-   required) with validation of data items related to authentication and
-   integrity.
-
-2.3.1.  GSS_Sign call
-
-   Inputs:
-
-   o  context_handle INTEGER,
-
-   o  qop_req INTEGER,-0 specifies default QOP
-
-   o  message OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-
-
-Linn                                                           [Page 32]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   o  minor_status INTEGER,
-
-   o  per_msg_token OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that a signature, suitable for an
-      established security context, was successfully applied and that
-      the message and corresponding per_msg_token are ready for
-      transmission.
-
-   o  GSS_CONTEXT_EXPIRED indicates that context-related data items have
-      expired, so that the requested operation cannot be performed.
-
-   o  GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
-      but that its associated credentials have expired, so that the
-      requested operation cannot be performed.
-
-   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
-      the input context_handle provided.
-
-   o  GSS_FAILURE indicates that the context is recognized, but that the
-      requested operation could not be performed for reasons unspecified
-      at the GSS-API level.
-
-   Using the security context referenced by context_handle, apply a
-   signature to the input message (along with timestamps and/or other
-   data included in support of mech_type-specific mechanisms) and return
-   the result in per_msg_token. The qop_req parameter allows quality-
-   of-protection control. The caller passes the message and the
-   per_msg_token to the target.
-
-   The GSS_Sign()  function completes before the message and
-   per_msg_token is sent to the peer; successful application of
-   GSS_Sign()  does not guarantee that a corresponding GSS_Verify() has
-   been (or can necessarily be) performed successfully when the message
-   arrives at the destination.
-
-2.3.2.  GSS_Verify call
-
-   Inputs:
-
-   o  context_handle INTEGER,
-
-   o  message OCTET STRING,
-
-   o  per_msg_token OCTET STRING
-
-
-
-
-Linn                                                           [Page 33]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   Outputs:
-
-   o  qop_state INTEGER,
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that the message was successfully verified.
-
-   o  GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
-      the received per_msg_token failed, preventing further processing
-      from being performed with that token.
-
-   o  GSS_BAD_SIG indicates that the received per_msg_token contains an
-      incorrect signature for the message.
-
-   o  GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN values
-      appear in conjunction with the optional per-message replay
-      detection features described in Section 1.2.3; their semantics are
-      described in that section.
-
-   o  GSS_CONTEXT_EXPIRED indicates that context-related data items have
-      expired, so that the requested operation cannot be performed.
-
-   o  GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
-      but that its associated credentials have expired, so that the
-      requested operation cannot be performed.
-
-   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
-      the input context_handle provided.
-
-   o  GSS_FAILURE indicates that the context is recognized, but that the
-      GSS_Verify()  operation could not be performed for reasons
-      unspecified at the GSS-API level.
-
-   Using the security context referenced by context_handle, verify that
-   the input per_msg_token contains an appropriate signature for the
-   input message, and apply any active replay detection or sequencing
-   features. Return an indication of the quality-of-protection applied
-   to the processed message in the qop_state result.
-
-
-
-
-
-
-
-
-Linn                                                           [Page 34]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-2.3.3. GSS_Seal call
-
-   Inputs:
-
-   o  context_handle INTEGER,
-
-   o  conf_req_flag BOOLEAN,
-
-   o  qop_req INTEGER,-0 specifies default QOP
-
-   o  input_message OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  conf_state BOOLEAN,
-
-   o  output_message OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that the input_message was successfully
-      processed and that the output_message is ready for transmission.
-
-   o  GSS_CONTEXT_EXPIRED indicates that context-related data items have
-      expired, so that the requested operation cannot be performed.
-
-   o  GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
-      but that its associated credentials have expired, so that the
-      requested operation cannot be performed.
-
-   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
-      the input context_handle provided.
-
-   o  GSS_FAILURE indicates that the context is recognized, but that the
-      GSS_Seal()  operation could not be performed for reasons
-      unspecified at the GSS-API level.
-
-   Performs the data origin authentication and data integrity functions
-   of GSS_Sign().  If the input conf_req_flag is TRUE, requests that
-   confidentiality be applied to the input_message.  Confidentiality may
-   not be supported in all mech_types or by all implementations; the
-   returned conf_state flag indicates whether confidentiality was
-   provided for the input_message. The qop_req parameter allows
-   quality-of-protection control.
-
-
-
-Linn                                                           [Page 35]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   In all cases, the GSS_Seal()  call yields a single output_message
-   data element containing (optionally enciphered) user data as well as
-   control information.
-
-2.3.4. GSS_Unseal call
-
-   Inputs:
-
-   o  context_handle INTEGER,
-
-   o  input_message OCTET STRING
-
-   Outputs:
-
-   o  conf_state BOOLEAN,
-
-   o  qop_state INTEGER,
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_message OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that the input_message was successfully
-      processed and that the resulting output_message is available.
-
-   o  GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
-      the per_msg_token extracted from the input_message failed,
-      preventing further processing from being performed.
-
-   o  GSS_BAD_SIG indicates that an incorrect signature was detected for
-      the message.
-
-   o  GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN values
-      appear in conjunction with the optional per-message replay
-      detection features described in Section 1.2.3; their semantics are
-      described in that section.
-
-   o  GSS_CONTEXT_EXPIRED indicates that context-related data items have
-      expired, so that the requested operation cannot be performed.
-
-   o  GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
-      but that its associated credentials have expired, so that the
-      requested operation cannot be performed.
-
-
-
-
-Linn                                                           [Page 36]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   o  GSS_NO_CONTEXT indicates that no valid context was recognized for
-      the input context_handle provided.
-
-   o  GSS_FAILURE indicates that the context is recognized, but that the
-      GSS_Unseal()  operation could not be performed for reasons
-      unspecified at the GSS-API level.
-
-   Processes a data element generated (and optionally enciphered) by
-   GSS_Seal(),  provided as input_message. The returned conf_state value
-   indicates whether confidentiality was applied to the input_message.
-   If conf_state is TRUE, GSS_Unseal()  deciphers the input_message.
-   Returns an indication of the quality-of-protection applied to the
-   processed message in the qop_state result. GSS_Seal()  performs the
-   data integrity and data origin authentication checking functions of
-   GSS_Verify()  on the plaintext data. Plaintext data is returned in
-   output_message.
-
-2.4.  Support calls
-
-   This group of calls provides support functions useful to GSS-API
-   callers, independent of the state of established contexts. Their
-   characterization with regard to blocking or non-blocking status in
-   terms of network interactions is unspecified.
-
-2.4.1.  GSS_Display_status call
-
-   Inputs:
-
-   o  status_value INTEGER,-GSS-API major_status or minor_status
-      return value
-
-   o  status_type INTEGER,-1 if major_status, 2 if minor_status
-
-   o  mech_type OBJECT IDENTIFIER-mech_type to be used for minor_
-      status translation
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  status_string_set SET OF OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that a valid printable status
-      representation (possibly representing more than one status event
-
-
-
-Linn                                                           [Page 37]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-      encoded within the status_value) is available in the returned
-      status_string_set.
-
-   o  GSS_BAD_MECH indicates that translation in accordance with an
-      unsupported mech_type was requested, so translation could not be
-      performed.
-
-   o  GSS_BAD_STATUS indicates that the input status_value was invalid,
-      or that the input status_type carried a value other than 1 or 2,
-      so translation could not be performed.
-
-   o  GSS_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Provides a means for callers to translate GSS-API-returned major and
-   minor status codes into printable string representations.
-
-2.4.2.  GSS_Indicate_mechs call
-
-   Input:
-
-   o  (none)
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  mech_set SET OF OBJECT IDENTIFIER
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that a set of available mechanisms has
-      been returned in mech_set.
-
-   o  GSS_FAILURE indicates that the requested operation could not
-      be performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to determine the set of mechanism types available on
-   the local system. This call is intended for support of specialized
-   callers who need to request non-default mech_type sets from
-   GSS_Acquire_cred(),  and should not be needed by other callers.
-
-2.4.3.  GSS_Compare_name call
-
-   Inputs:
-
-
-
-
-Linn                                                           [Page 38]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   o  name1 INTERNAL NAME,
-
-   o  name2 INTERNAL NAME
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  name_equal BOOLEAN
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that name1 and name2 were comparable, and
-      that the name_equal result indicates whether name1 and name2 were
-      equal or unequal.
-
-   o  GSS_BAD_NAMETYPE indicates that one or both of name1 and name2
-      contained internal type specifiers uninterpretable by the
-      supporting GSS-API implementation, or that the two names' types
-      are different and incomparable, so the equality comparison could
-      not be completed.
-
-   o  GSS_BAD_NAME indicates that one or both of the input names was
-      ill-formed in terms of its internal type specifier, so the
-      equality comparison could not be completed.
-
-   o  GSS_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to compare two internal name representations for
-   equality.
-
-2.4.4.  GSS_Display_name call
-
-   Inputs:
-
-   o  name INTERNAL NAME
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  name_string OCTET STRING,
-
-
-
-
-Linn                                                           [Page 39]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   o  name_type OBJECT IDENTIFIER
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that a valid printable name representation
-      is available in the returned name_string.
-
-   o  GSS_BAD_NAMETYPE indicates that the provided name was of a type
-      uninterpretable by the supporting GSS-API implementation, so no
-      printable representation could be generated.
-
-   o  GSS_BAD_NAME indicates that the contents of the provided name were
-      inconsistent with the internally-indicated name type, so no
-      printable representation could be generated.
-
-   o  GSS_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to translate an internal name representation into a
-   printable form with associated namespace type descriptor. The syntax
-   of the printable form is a local matter.
-
-2.4.5.  GSS_Import_name call
-
-   Inputs:
-
-   o  input_name_string OCTET STRING,
-
-   o  input_name_type OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_name INTERNAL NAME
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that a valid name representation is output
-      in output_name and described by the type value in
-      output_name_type.
-
-   o  GSS_BAD_NAMETYPE indicates that the input_name_type is unsupported
-      by the GSS-API implementation, so the import operation could not
-      be completed.
-
-
-
-
-Linn                                                           [Page 40]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   o  GSS_BAD_NAME indicates that the provided input_name_string is
-      ill-formed in terms of the input_name_type, so the import
-      operation could not be completed.
-
-   o  GSS_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to provide a printable name representation, designate
-   the type of namespace in conjunction with which it should be parsed,
-   and convert that printable representation to an internal form
-   suitable for input to other GSS-API routines.  The syntax of the
-   input_name is a local matter.
-
-2.4.6. GSS_Release_name call
-
-   Inputs:
-
-   o  name INTERNAL NAME
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that the storage associated with the input
-      name was successfully released.
-
-   o  GSS_BAD_NAME indicates that the input name argument did not
-      contain a valid name.
-
-   o  GSS_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to release the storage associated with an internal
-   name representation.
-
-2.4.7. GSS_Release_buffer call
-
-   Inputs:
-
-   o  buffer OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-
-
-Linn                                                           [Page 41]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that the storage associated with the input
-      buffer was successfully released.
-
-   o  GSS_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to release the storage associated with an OCTET STRING
-   buffer allocated by another GSS-API call.
-
-2.4.8. GSS_Release_oid_set call
-
-   Inputs:
-
-   o  buffer SET OF OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_COMPLETE indicates that the storage associated with the input
-      object identifier set was successfully released.
-
-   o  GSS_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to release the storage associated with an object
-   identifier set object allocated by another GSS-API call.
-
-3.  Mechanism-Specific Example Scenarios
-
-   This section provides illustrative overviews of the use of various
-   candidate mechanism types to support the GSS-API. These discussions
-   are intended primarily for readers familiar with specific security
-   technologies, demonstrating how GSS-API functions can be used and
-   implemented by candidate underlying mechanisms. They should not be
-   regarded as constrictive to implementations or as defining the only
-   means through which GSS-API functions can be realized with a
-   particular underlying technology, and do not demonstrate all GSS-API
-   features with each technology.
-
-
-
-
-Linn                                                           [Page 42]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-3.1. Kerberos V5, single-TGT
-
-   OS-specific login functions yield a TGT to the local realm Kerberos
-   server; TGT is placed in a credentials structure for the client.
-   Client calls GSS_Acquire_cred()  to acquire a cred_handle in order to
-   reference the credentials for use in establishing security contexts.
-
-   Client calls GSS_Init_sec_context().  If the requested service is
-   located in a different realm, GSS_Init_sec_context()  gets the
-   necessary TGT/key pairs needed to traverse the path from local to
-   target realm; these data are placed in the owner's TGT cache. After
-   any needed remote realm resolution, GSS_Init_sec_context()  yields a
-   service ticket to the requested service with a corresponding session
-   key; these data are stored in conjunction with the context. GSS-API
-   code sends KRB_TGS_REQ request(s) and receives KRB_TGS_REP
-   response(s) (in the successful case) or KRB_ERROR.
-
-   Assuming success, GSS_Init_sec_context()  builds a Kerberos-formatted
-   KRB_AP_REQ message, and returns it in output_token.  The client sends
-   the output_token to the service.
-
-   The service passes the received token as the input_token argument to
-   GSS_Accept_sec_context(),  which verifies the authenticator, provides
-   the service with the client's authenticated name, and returns an
-   output_context_handle.
-
-   Both parties now hold the session key associated with the service
-   ticket, and can use this key in subsequent GSS_Sign(), GSS_Verify(),
-   GSS_Seal(), and GSS_Unseal() operations.
-
-3.2. Kerberos V5, double-TGT
-
-   TGT acquisition as above.
-
-   Note: To avoid unnecessary frequent invocations of error paths when
-   implementing the GSS-API atop Kerberos V5, it seems appropriate to
-   represent "single-TGT K-V5" and "double-TGT K-V5" with separate
-   mech_types, and this discussion makes that assumption.
-
-   Based on the (specified or defaulted) mech_type,
-   GSS_Init_sec_context()  determines that the double-TGT protocol
-   should be employed for the specified target. GSS_Init_sec_context()
-   returns GSS_CONTINUE_NEEDED major_status, and its returned
-   output_token contains a request to the service for the service's TGT.
-   (If a service TGT with suitably long remaining lifetime already
-   exists in a cache, it may be usable, obviating the need for this
-   step.) The client passes the output_token to the service.  Note: this
-   scenario illustrates a different use for the GSS_CONTINUE_NEEDED
-
-
-
-Linn                                                           [Page 43]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   status return facility than for support of mutual authentication;
-   note that both uses can coexist as successive operations within a
-   single context establishment operation.
-
-   The service passes the received token as the input_token argument to
-   GSS_Accept_sec_context(),  which recognizes it as a request for TGT.
-   (Note that current Kerberos V5 defines no intra-protocol mechanism to
-   represent such a request.) GSS_Accept_sec_context()  returns
-   GSS_CONTINUE_NEEDED major_status and provides the service's TGT in
-   its output_token. The service sends the output_token to the client.
-
-   The client passes the received token as the input_token argument to a
-   continuation of GSS_Init_sec_context(). GSS_Init_sec_context() caches
-   the received service TGT and uses it as part of a service ticket
-   request to the Kerberos authentication server, storing the returned
-   service ticket and session key in conjunction with the context.
-   GSS_Init_sec_context()  builds a Kerberos-formatted authenticator,
-   and returns it in output_token along with GSS_COMPLETE return
-   major_status. The client sends the output_token to the service.
-
-   Service passes the received token as the input_token argument to a
-   continuation call to GSS_Accept_sec_context().
-   GSS_Accept_sec_context()  verifies the authenticator, provides the
-   service with the client's authenticated name, and returns
-   major_status GSS_COMPLETE.
-
-   GSS_Sign(),  GSS_Verify(), GSS_Seal(), and GSS_Unseal()  as above.
-
-3.3.  X.509 Authentication Framework
-
-   This example illustrates use of the GSS-API in conjunction with
-   public-key mechanisms, consistent with the X.509 Directory
-   Authentication Framework.
-
-   The GSS_Acquire_cred()  call establishes a credentials structure,
-   making the client's private key accessible for use on behalf of the
-   client.
-
-   The client calls GSS_Init_sec_context(),  which interrogates the
-   Directory to acquire (and validate) a chain of public-key
-   certificates, thereby collecting the public key of the service.  The
-   certificate validation operation determines that suitable signatures
-   were applied by trusted authorities and that those certificates have
-   not expired. GSS_Init_sec_context()  generates a secret key for use
-   in per-message protection operations on the context, and enciphers
-   that secret key under the service's public key.
-
-   The enciphered secret key, along with an authenticator quantity
-
-
-
-Linn                                                           [Page 44]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   signed with the client's private key, is included in the output_token
-   from GSS_Init_sec_context().  The output_token also carries a
-   certification path, consisting of a certificate chain leading from
-   the service to the client; a variant approach would defer this path
-   resolution to be performed by the service instead of being asserted
-   by the client. The client application sends the output_token to the
-   service.
-
-   The service passes the received token as the input_token argument to
-   GSS_Accept_sec_context().  GSS_Accept_sec_context() validates the
-   certification path, and as a result determines a certified binding
-   between the client's distinguished name and the client's public key.
-   Given that public key, GSS_Accept_sec_context() can process the
-   input_token's authenticator quantity and verify that the client's
-   private key was used to sign the input_token. At this point, the
-   client is authenticated to the service. The service uses its private
-   key to decipher the enciphered secret key provided to it for per-
-   message protection operations on the context.
-
-   The client calls GSS_Sign()  or GSS_Seal() on a data message, which
-   causes per-message authentication, integrity, and (optional)
-   confidentiality facilities to be applied to that message. The service
-   uses the context's shared secret key to perform corresponding
-   GSS_Verify()  and GSS_Unseal() calls.
-
-4.  Related Activities
-
-   In order to implement the GSS-API atop existing, emerging, and future
-   security mechanisms:
-
-      object identifiers must be assigned to candidate GSS-API
-      mechanisms and the name types which they support
-
-      concrete data element formats must be defined for candidate
-      mechanisms
-
-   Calling applications must implement formatting conventions which will
-   enable them to distinguish GSS-API tokens from other data carried in
-   their application protocols.
-
-   Concrete language bindings are required for the programming
-   environments in which the GSS-API is to be employed; such bindings
-   for the C language are available in an associated RFC.
-
-
-
-
-
-
-
-
-Linn                                                           [Page 45]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-5.  Acknowledgments
-
-   This proposal is the result of a collaborative effort.
-   Acknowledgments are due to the many members of the IETF Security Area
-   Advisory Group (SAAG) and the Common Authentication Technology (CAT)
-   Working Group for their contributions at meetings and by electronic
-   mail. Acknowledgments are also due to Kannan Alagappan, Doug Barlow,
-   Bill Brown, Cliff Kahn, Charlie Kaufman, Butler Lampson, Richard
-   Pitkin, Joe Tardo, and John Wray of Digital Equipment Corporation,
-   and John Carr, John Kohl, Jon Rochlis, Jeff Schiller, and Ted T'so of
-   MIT and Project Athena.  Joe Pato and Bill Sommerfeld of HP/Apollo,
-   Walt Tuvell of OSF, and Bill Griffith and Mike Merritt of AT&T,
-   provided inputs which helped to focus and clarify directions.
-   Precursor work by Richard Pitkin, presented to meetings of the
-   Trusted Systems Interoperability Group (TSIG), helped to demonstrate
-   the value of a generic, mechanism-independent security service API.
-
-6. Security Considerations
-
-   Security issues are discussed throughout this memo.
-
-7. Author's Address
-
-   John Linn
-   Geer Zolot Associates
-   One Main St.
-   Cambridge, MA  02142  USA
-
-   Phone: +1 617.374.3700
-   Email: Linn@gza.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn                                                           [Page 46]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-APPENDIX  A
-
-PACS AND AUTHORIZATION SERVICES
-
-   Consideration has been given to modifying the GSS-API service
-   interface to recognize and manipulate Privilege Attribute
-   Certificates (PACs) as in ECMA 138, carrying authorization data as a
-   side effect of establishing a security context, but no such
-   modifications have been incorporated at this time. This appendix
-   provides rationale for this decision and discusses compatibility
-   alternatives between PACs and the GSS-API which do not require that
-   PACs be made visible to GSS-API callers.
-
-   Existing candidate mechanism types such as Kerberos and X.509 do not
-   incorporate PAC manipulation features, and exclusion of such
-   mechanisms from the set of candidates equipped to fully support the
-   GSS-API seems inappropriate. Inclusion (and GSS-API visibility) of a
-   feature supported by only a limited number of mechanisms could
-   encourage the development of ostensibly portable applications which
-   would in fact have only limited portability.
-
-   The status quo, in which PACs are not visible across the GSS-API
-   interface, does not preclude implementations in which PACs are
-   carried transparently, within the tokens defined and used for certain
-   mech_types, and stored within peers' credentials and context-level
-   data structures. While invisible to API callers, such PACs could be
-   used by operating system or other local functions as inputs in the
-   course of mediating access requests made by callers. This course of
-   action allows dynamic selection of PAC contents, if such selection is
-   administratively-directed rather than caller-directed.
-
-   In a distributed computing environment, authentication must span
-   different systems; the need for such authentication provides
-   motivation for GSS-API definition and usage. Heterogeneous systems in
-   a network can intercommunicate, with globally authenticated names
-   comprising the common bond between locally defined access control
-   policies. Access control policies to which authentication provides
-   inputs are often local, or specific to particular operating systems
-   or environments. If the GSS-API made particular authorization models
-   visible across its service interface, its scope of application would
-   become less general. The current GSS-API paradigm is consistent with
-   the precedent set by Kerberos, neither defining the interpretation of
-   authorization-related data nor enforcing access controls based on
-   such data.
-
-   The GSS-API is a general interface, whose callers may reside inside
-   or outside any defined TCB or NTCB boundaries. Given this
-   characteristic, it appears more realistic to provide facilities which
-
-
-
-Linn                                                           [Page 47]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-   provide "value-added" security services to its callers than to offer
-   facilities which enforce restrictions on those callers. Authorization
-   decisions must often be mediated below the GSS-API level in a local
-   manner against (or in spite of) applications, and cannot be
-   selectively invoked or omitted at those applications' discretion.
-   Given that the GSS-API's placement prevents it from providing a
-   comprehensive solution to the authorization issue, the value of a
-   partial contribution specific to particular authorization models is
-   debatable.
-
-APPENDIX  B
-
-MECHANISM-INDEPENDENT TOKEN FORMAT
-
-   This appendix specifies a mechanism-independent level of
-   encapsulating representation for the initial token of a GSS-API
-   context establishment sequence, incorporating an identifier of the
-   mechanism type to be used on that context. Use of this format (with
-   ASN.1-encoded data elements represented in BER, constrained in the
-   interests of parsing simplicity to the Distinguished Encoding Rule
-   (DER) BER subset defined in X.509, clause 8.7) is recommended to the
-   designers of GSS-API implementations based on various mechanisms, so
-   that tokens can be interpreted unambiguously at GSS-API peers. There
-   is no requirement that the mechanism-specific innerContextToken,
-   innerMsgToken, and sealedUserData data elements be encoded in ASN.1
-   BER.
-
-          -- optional top-level token definitions to
-          -- frame different mechanisms
-
-          GSS-API DEFINITIONS ::=
-
-          BEGIN
-
-          MechType ::= OBJECT IDENTIFIER
-          -- data structure definitions
-
-          -- callers must be able to distinguish among
-          -- InitialContextToken, SubsequentContextToken,
-          -- PerMsgToken, and SealedMessage data elements
-          -- based on the usage in which they occur
-
-          InitialContextToken ::=
-          -- option indication (delegation, etc.) indicated within
-          -- mechanism-specific token
-          [APPLICATION 0] IMPLICIT SEQUENCE {
-                  thisMech MechType,
-                  innerContextToken ANY DEFINED BY thisMech
-
-
-
-Linn                                                           [Page 48]
-
-RFC 1508               Generic Security Interface         September 1993
-
-
-                     -- contents mechanism-specific
-                  }
-
-          SubsequentContextToken ::= innerContextToken ANY
-          -- interpretation based on predecessor InitialContextToken
-
-          PerMsgToken ::=
-          -- as emitted by GSS_Sign and processed by GSS_Verify
-                  innerMsgToken ANY
-
-          SealedMessage ::=
-          -- as emitted by GSS_Seal and processed by GSS_Unseal
-          -- includes internal, mechanism-defined indicator
-          -- of whether or not encrypted
-                  sealedUserData ANY
-
-          END
-
-APPENDIX  C
-
-MECHANISM DESIGN CONSTRAINTS
-
-   The following constraints on GSS-API mechanism designs are adopted in
-   response to observed caller protocol requirements, and adherence
-   thereto is anticipated in subsequent descriptions of GSS-API
-   mechanisms to be documented in standards-track Internet
-   specifications.
-
-   Use of the approach defined in Appendix B of this specification,
-   applying a mechanism type tag to the InitialContextToken, is
-   required.
-
-   It is strongly recommended that mechanisms offering per-message
-   protection services also offer at least one of the replay detection
-   and sequencing services, as mechanisms offering neither of the latter
-   will fail to satisfy recognized requirements of certain candidate
-   caller protocols.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn                                                           [Page 49]
-
\ No newline at end of file
diff --git a/doc/standardisation/rfc1509.txt b/doc/standardisation/rfc1509.txt
deleted file mode 100644
index f36cd80e6..000000000
--- a/doc/standardisation/rfc1509.txt
+++ /dev/null
@@ -1,2691 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            J. Wray
-Request for Comments: 1509                 Digital Equipment Corporation
-                                                          September 1993
-
-
-               Generic Security Service API : C-bindings
-
-Status of this Memo
-
-   This RFC 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" for the standardization state and status
-   of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This document specifies C language bindings for the Generic Security
-   Service Application Program Interface (GSS-API), which is described
-   at a language-independent conceptual level in other documents.
-
-   The Generic Security Service Application Programming Interface (GSS-
-   API) provides security services to its callers, and is intended for
-   implementation atop alternative underlying cryptographic mechanisms.
-   Typically, GSS-API callers will be application protocols into which
-   security enhancements are integrated through invocation of services
-   provided by the GSS-API. The GSS-API allows a caller application to
-   authenticate a principal identity associated with a peer application,
-   to delegate rights to a peer, and to apply security services such as
-   confidentiality and integrity on a per-message basis.
-
-1. INTRODUCTION
-
-   The Generic Security Service Application Programming Interface [1]
-   provides security services to calling applications.  It allows a
-   communicating application to authenticate the user associated with
-   another application, to delegate rights to another application, and
-   to apply security services such as confidentiality and integrity on a
-   per-message basis.
-
-   There are four stages to using the GSSAPI:
-
-   (a) The application acquires a set of credentials with which it may
-       prove its identity to other processes.  The application's
-       credentials vouch for its global identity, which may or may not
-       be related to the local username under which it is running.
-
-
-
-
-
-Wray                                                            [Page 1]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-   (b) A pair of communicating applications establish a joint security
-       context using their credentials.  The security context is a
-       pair of GSSAPI data structures that contain shared state
-       information, which is required in order that per-message
-       security services may be provided.  As part of the
-       establishment of a security context, the context initiator is
-       authenticated to the responder, and may require that the
-       responder is authenticated in turn.  The initiator may
-       optionally give the responder the right to initiate further
-       security contexts.  This transfer of rights is termed
-       delegation, and is achieved by creating a set of credentials,
-       similar to those used by the originating application, but which
-       may be used by the responder.  To establish and maintain the
-       shared information that makes up the security context, certain
-       GSSAPI calls will return a token data structure, which is a
-       cryptographically protected opaque data type.  The caller of
-       such a GSSAPI routine is responsible for transferring the token
-       to the peer application, which should then pass it to a
-       corresponding GSSAPI routine which will decode it and extract
-       the information.
-
-   (c) Per-message services are invoked to apply either:
-
-       (i) integrity and data origin authentication, or
-
-       (ii) confidentiality, integrity and data origin authentication
-            to application data, which are treated by GSSAPI as
-            arbitrary octet-strings.  The application transmitting a
-            message that it wishes to protect will call the appropriate
-            GSSAPI routine (sign or seal) to apply protection, specifying
-            the appropriate security context, and send the result to the
-            receiving application.  The receiver will pass the received
-            data to the corresponding decoding routine (verify or unseal)
-            to remove the protection and validate the data.
-
-   (d) At the completion of a communications session (which may extend
-       across several connections), the peer applications call GSSAPI
-       routines to delete the security context.  Multiple contexts may
-       also be used (either successively or simultaneously) within a
-       single communications association.
-
-2. GSSAPI Routines
-
-   This section lists the functions performed by each of the GSSAPI
-   routines and discusses their major parameters, describing how they
-   are to be passed to the routines.  The routines are listed in figure
-   4-1.
-
-
-
-
-Wray                                                            [Page 2]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-                      Figure 4-1  GSSAPI Routines
-
-
-            Routine                               Function
-
-            gss_acquire_cred               Assume a global identity
-
-            gss_release_cred               Discard credentials
-
-            gss_init_sec_context           Initiate a security context
-                                           with a peer application
-
-            gss_accept_sec_context         Accept a security context
-                                           initiated by a peer
-                                           application
-
-            gss_process_context_token      Process a token on a security
-                                           context from a peer
-                                           application
-
-            gss_delete_sec_context         Discard a security context
-
-            gss_context_time               Determine for how long a
-                                           context will remain valid
-
-            gss_sign                       Sign a message; integrity
-                                           service
-
-            gss_verify                     Check signature on a message
-
-            gss_seal                       Sign (optionally encrypt) a
-                                           message; confidentiality
-                                           service
-
-            gss_unseal                     Verify (optionally decrypt)
-                                           message
-
-            gss_display_status             Convert an API status code
-                                           to text
-
-            gss_indicate_mechs             Determine underlying
-                                           authentication mechanism
-
-            gss_compare_name               Compare two internal-form
-                                           names
-
-            gss_display_name               Convert opaque name to text
-
-
-
-
-Wray                                                            [Page 3]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-            gss_import_name                Convert a textual name to
-                                           internal-form
-
-            gss_release_name               Discard an internal-form
-                                           name
-
-            gss_release_buffer             Discard a buffer
-
-            gss_release_oid_set            Discard a set of object
-                                           identifiers
-
-            gss_inquire_cred               Determine information about
-                                           a credential
-
-   Individual GSSAPI implementations may augment these routines by
-   providing additional mechanism-specific routines if required
-   functionality is not available from the generic forms.  Applications
-   are encouraged to use the generic routines wherever possible on
-   portability grounds.
-
-2.1. Data Types and Calling Conventions
-
-   The following conventions are used by the GSSAPI:
-
-2.1.1. Structured data types
-
-   Wherever these GSSAPI C-bindings describe structured data, only
-   fields that must be provided by all GSSAPI implementation are
-   documented.  Individual implementations may provide additional
-   fields, either for internal use within GSSAPI routines, or for use by
-   non-portable applications.
-
-2.1.2. Integer types
-
-   GSSAPI defines the following integer data type:
-
-                 OM_uint32      32-bit unsigned integer
-
-   Where guaranteed minimum bit-count is important, this portable data
-   type is used by the GSSAPI routine definitions. Individual GSSAPI
-   implementations will include appropriate typedef definitions to map
-   this type onto a built-in data type.
-
-2.1.3. String and similar data
-
-   Many of the GSSAPI routines take arguments and return values that
-   describe contiguous multiple-byte data.  All such data is passed
-   between the GSSAPI and the caller using the gss_buffer_t data type.
-
-
-
-Wray                                                            [Page 4]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-   This data type is a pointer to a buffer descriptor, which consists of
-   a length field that contains the total number of bytes in the datum,
-   and a value field which contains a pointer to the actual datum:
-
-                 typedef struct gss_buffer_desc_struct {
-                    size_t  length;
-                    void    *value;
-                 } gss_buffer_desc, *gss_buffer_t;
-
-   Storage for data passed to the application by a GSSAPI routine using
-   the gss_buffer_t conventions is allocated by the GSSAPI routine.  The
-   application may free this storage by invoking the gss_release_buffer
-   routine.  Allocation of the gss_buffer_desc object is always the
-   responsibility of the application;  Unused gss_buffer_desc objects
-   may be initialized to the value GSS_C_EMPTY_BUFFER.
-
-2.1.3.1. Opaque data types
-
-   Certain multiple-word data items are considered opaque data types at
-   the GSSAPI, because their internal structure has no significance
-   either to the GSSAPI or to the caller.  Examples of such opaque data
-   types are the input_token parameter to gss_init_sec_context (which is
-   opaque to the caller), and the input_message parameter to gss_seal
-   (which is opaque to the GSSAPI).  Opaque data is passed between the
-   GSSAPI and the application using the gss_buffer_t datatype.
-
-2.1.3.2. Character strings
-
-   Certain multiple-word data items may be regarded as simple ISO
-   Latin-1 character strings.  An example of this is the
-   input_name_buffer parameter to gss_import_name.  Some GSSAPI routines
-   also return character strings.  Character strings are passed between
-   the application and the GSSAPI using the gss_buffer_t datatype,
-   defined earlier.
-
-2.1.4. Object Identifiers
-
-   Certain GSSAPI procedures take parameters of the type gss_OID, or
-   Object identifier.  This is a type containing ISO-defined tree-
-   structured values, and is used by the GSSAPI caller to select an
-   underlying security mechanism.  A value of type gss_OID has the
-   following structure:
-
-                 typedef struct gss_OID_desc_struct {
-                    OM_uint32 length;
-                    void      *elements;
-                 } gss_OID_desc, *gss_OID;
-
-
-
-
-Wray                                                            [Page 5]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-   The elements field of this structure points to the first byte of an
-   octet string containing the ASN.1 BER encoding of the value of the
-   gss_OID.  The length field contains the number of bytes in this
-   value.  For example, the  gss_OID value corresponding to {iso(1)
-   identified- oganization(3) icd-ecma(12) member-company(2) dec(1011)
-   cryptoAlgorithms(7) SPX(5)} meaning SPX (Digital's X.509
-   authentication mechanism) has a length field of 7 and an elements
-   field pointing to seven octets containing the following octal values:
-   53,14,2,207,163,7,5. GSSAPI implementations should provide constant
-   gss_OID values to allow callers to request any supported mechanism,
-   although applications are encouraged on portability grounds to accept
-   the default mechanism.   gss_OID values should also be provided to
-   allow applications to specify particular name types (see section
-   2.1.10).  Applications should treat gss_OID_desc values returned by
-   GSSAPI routines as read-only.  In particular, the application should
-   not attempt to deallocate them.  The gss_OID_desc datatype is
-   equivalent to the X/Open OM_object_identifier datatype [2].
-
-2.1.5. Object Identifier Sets
-
-   Certain GSSAPI procedures take parameters of the type gss_OID_set.
-   This type represents one or more object identifiers (section 2.1.4).
-   A gss_OID_set object has the following structure:
-
-                 typedef struct gss_OID_set_desc_struct {
-                    int       count;
-                    gss_OID   elements;
-                 } gss_OID_set_desc, *gss_OID_set;
-
-   The count field contains the number of OIDs within the set.  The
-   elements field is a pointer to an array of gss_OID_desc objects, each
-   of which describes a single OID. gss_OID_set values are used to name
-   the available mechanisms supported by the GSSAPI, to request the use
-   of specific mechanisms, and to indicate which mechanisms a given
-   credential supports.  Storage associated with gss_OID_set values
-   returned to the application by the GSSAPI may be deallocated by the
-   gss_release_oid_set routine.
-
-2.1.6. Credentials
-
-   A credential handle is a caller-opaque atomic datum that identifies a
-   GSSAPI credential data structure.  It is represented by the caller-
-   opaque type gss_cred_id_t, which may be implemented as either an
-   arithmetic or a pointer type.  Credentials describe a principal, and
-   they give their holder the ability to act as that principal.  The
-   GSSAPI does not make the actual credentials available to
-   applications; instead the credential handle is used to identify a
-   particular credential, held internally by GSSAPI or underlying
-
-
-
-Wray                                                            [Page 6]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-   mechanism.  Thus the credential handle contains no security-relavent
-   information, and requires no special protection by the application.
-   Depending on the implementation, a given credential handle may refer
-   to different credentials when presented to the GSSAPI by different
-   callers.  Individual GSSAPI implementations should define both the
-   scope of a credential handle and the scope of a credential itself
-   (which must be at least as wide as that of a handle).  Possibilities
-   for credential handle scope include the process that acquired the
-   handle, the acquiring process and its children, or all processes
-   sharing some local identification information (e.g., UID).  If no
-   handles exist by which a given credential may be reached, the GSSAPI
-   may delete the credential.
-
-   Certain routines allow credential handle parameters to be omitted to
-   indicate the use of a default credential.  The mechanism by which a
-   default credential is established and its scope should be defined by
-   the individual GSSAPI implementation.
-
-2.1.7. Contexts
-
-   The gss_ctx_id_t data type contains a caller-opaque atomic value that
-   identifies one end of a GSSAPI security context.  It may be
-   implemented as either an arithmetic or a pointer type. Depending on
-   the implementation, a given gss_ctx_id_t value may refer to different
-   GSSAPI security contexts when presented to the GSSAPI by different
-   callers.  The security context holds state information about each end
-   of a peer communication, including cryptographic state information.
-   Individual GSSAPI implementations should define the scope of a
-   context.  Since no way is provided by which a new gss_ctx_id_t value
-   may be obtained for an existing context, the scope of a context
-   should be the same as the scope of a gss_ctx_id_t.
-
-2.1.8. Authentication tokens
-
-   A token is a caller-opaque type that GSSAPI uses to maintain
-   synchronization between the context data structures at each end of a
-   GSSAPI security context.  The token is a cryptographically protected
-   bit-string, generated by the underlying mechanism at one end of a
-   GSSAPI security context for use by the peer mechanism at the other
-   end.  Encapsulation (if required) and transfer of the token are the
-   responsibility of the peer applications.  A token is passed between
-   the GSSAPI and the application using the gss_buffer_t conventions.
-
-2.1.9. Status values
-
-   One or more status codes are returned by each GSSAPI routine.  Two
-   distinct sorts of status codes are returned.  These are termed GSS
-   status codes and Mechanism status codes.
-
-
-
-Wray                                                            [Page 7]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-2.1.9.1. GSS status codes
-
-   GSSAPI routines return GSS status codes as their OM_uint32 function
-   value.  These codes indicate errors that are independent of the
-   underlying mechanism used to provide the security service.  The
-   errors that can be indicated via a GSS status code are either generic
-   API routine errors (errors that are defined in the GSSAPI
-   specification) or calling errors (errors that are specific to these
-   bindings).
-
-   A GSS status code can indicate a single fatal generic API error from
-   the routine and a single calling error.  In addition, supplementary
-   status information may be indicated via the setting of bits in the
-   supplementary info field of a GSS status code.
-
-   These errors are encoded into the 32-bit GSS status code as follows:
-
-      MSB                                                        LSB
-      |------------------------------------------------------------|
-      | Calling Error | Routine Error  |    Supplementary Info     |
-      |------------------------------------------------------------|
-   Bit 31           24 23            16 15                        0
-
-   Hence if a GSSAPI routine returns a GSS status code whose upper 16
-   bits contain a non-zero value, the call failed.  If the calling error
-   field is non-zero, the invoking application's call of the routine was
-   erroneous.  Calling errors are defined in table 5-1.  If the routine
-   error field is non-zero, the routine failed for one of the routine-
-   specific reasons listed below in table 5-2.  Whether or not the upper
-   16 bits indicate a failure or a success, the routine may indicate
-   additional information by setting bits in the supplementary info
-   field of the status code.  The meaning of individual bits is listed
-   below in table 5-3.
-
-                     Table 5-1  Calling Errors
-
-              Name                    Value in        Meaning
-                                        Field
-         GSS_S_CALL_INACCESSIBLE_READ     1           A required input
-                                                      parameter could
-                                                      not be read.
-         GSS_S_CALL_INACCESSIBLE_WRITE    2           A required output
-                                                      parameter could
-                                                      not be written.
-         GSS_S_CALL_BAD_STRUCTURE         3           A parameter was
-                                                      malformed
-
-
-
-
-
-Wray                                                            [Page 8]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-                     Table 5-2  Routine Errors
-
-               Name             Value in       Meaning
-                                 Field
-
-         GSS_S_BAD_MECH             1      An unsupported mechanism was
-                                           requested
-         GSS_S_BAD_NAME             2      An invalid name was supplied
-         GSS_S_BAD_NAMETYPE         3      A supplied name was of an
-                                           unsupported type
-         GSS_S_BAD_BINDINGS         4      Incorrect channel bindings
-                                           were supplied
-         GSS_S_BAD_STATUS           5      An invalid status code was
-                                           supplied
-
-         GSS_S_BAD_SIG              6      A token had an invalid
-                                           signature
-         GSS_S_NO_CRED              7      No credentials were supplied
-         GSS_S_NO_CONTEXT           8      No context has been
-                                           established
-         GSS_S_DEFECTIVE_TOKEN      9      A token was invalid
-         GSS_S_DEFECTIVE_CREDENTIAL 10     A credential was invalid
-         GSS_S_CREDENTIALS_EXPIRED  11     The referenced credentials
-                                           have expired
-         GSS_S_CONTEXT_EXPIRED      12     The context has expired
-         GSS_S_FAILURE              13     Miscellaneous failure
-                                           (see text)
-
-                     Table 5-3  Supplementary Status Bits
-
-         Name                Bit Number         Meaning
-         GSS_S_CONTINUE_NEEDED   0 (LSB)  The routine must be called
-                                          again to complete its
-                                          function.
-                                          See routine documentation for
-                                          detailed description.
-         GSS_S_DUPLICATE_TOKEN   1        The token was a duplicate of
-                                          an earlier token
-         GSS_S_OLD_TOKEN         2        The token's validity period
-                                          has expired
-         GSS_S_UNSEQ_TOKEN       3        A later token has already been
-                                          processed
-
-   The routine documentation also uses the name GSS_S_COMPLETE, which is
-   a zero value, to indicate an absence of any API errors or
-   supplementary information bits.
-
-
-
-
-
-Wray                                                            [Page 9]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-   All GSS_S_xxx symbols equate to complete OM_uint32 status codes,
-   rather than to bitfield values.  For example, the actual value of the
-   symbol GSS_S_BAD_NAMETYPE (value 3 in the routine error field) is 3
-   << 16.
-
-   The macros GSS_CALLING_ERROR(), GSS_ROUTINE_ERROR() and
-   GSS_SUPPLEMENTARY_INFO() are provided, each of which takes a GSS
-   status code and removes all but the relevant field.  For example, the
-   value obtained by applying GSS_ROUTINE_ERROR to a status code removes
-   the calling errors and supplementary info fields, leaving only the
-   routine errors field.  The values delivered by these macros may be
-   directly compared with a GSS_S_xxx symbol of the appropriate type.
-   The macro GSS_ERROR() is also provided, which when applied to a GSS
-   status code returns a non-zero value if the status code indicated a
-   calling or routine error, and a zero value otherwise.
-
-   A GSSAPI implementation may choose to signal calling errors in a
-   platform-specific manner instead of, or in addition to the routine
-   value; routine errors and supplementary info should be returned via
-   routine status values only.
-
-2.1.9.2. Mechanism-specific status codes
-
-   GSSAPI routines return a minor_status parameter, which is used to
-   indicate specialized errors from the underlying security mechanism.
-   This parameter may contain a single mechanism-specific error,
-   indicated by a OM_uint32 value.
-
-   The minor_status parameter will always be set by a GSSAPI routine,
-   even if it returns a calling error or one of the generic API errors
-   indicated above as fatal, although other output parameters may remain
-   unset in such cases.  However, output parameters that are expected to
-   return pointers to storage allocated by a routine must always set set
-   by the routine, even in the event of an error, although in such cases
-   the GSSAPI routine may elect to set the returned parameter value to
-   NULL to indicate that no storage was actually allocated.  Any length
-   field associated with such pointers (as in a gss_buffer_desc
-   structure) should also be set to zero in such cases.
-
-   The GSS status code GSS_S_FAILURE is used to indicate that the
-   underlying mechanism detected an error for which no specific GSS
-   status code is defined.  The mechanism status code will provide more
-   details about the error.
-
-2.1.10. Names
-
-   A name is used to identify a person or entity.  GSSAPI authenticates
-   the relationship between a name and the entity claiming the name.
-
-
-
-Wray                                                           [Page 10]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-   Two distinct representations are defined for names:
-
-        (a) A printable form, for presentation to a user
-
-        (b) An internal form, for presentation at the API
-
-   The syntax of a printable name is defined by the GSSAPI
-   implementation, and may be dependent on local system configuration,
-   or on individual user preference.  The internal form provides a
-   canonical representation of the name that is independent of
-   configuration.
-
-   A given GSSAPI implementation may support names drawn from multiple
-   namespaces.  In such an implementation, the internal form of the name
-   must include fields that identify the namespace from which the name
-   is drawn.  The namespace from which a printable name is drawn is
-   specified by an accompanying object identifier.
-
-   Routines (gss_import_name and  gss_display_name) are provided to
-   convert names between their printable representations and the
-   gss_name_t type.  gss_import_name may support multiple syntaxes for
-   each supported namespace, allowing users the freedom to choose a
-   preferred name representation.  gss_display_name should use an
-   implementation-chosen preferred syntax for each supported name-type.
-
-   Comparison of internal-form names is accomplished via the
-   gss_compare_names routine.  This removes the need for the application
-   program to understand the syntaxes of the various printable names
-   that a given GSSAPI implementation may support.
-
-   Storage is allocated by routines that return gss_name_t values.  A
-   procedure, gss_release_name, is provided to free storage associated
-   with a name.
-
-2.1.11. Channel Bindings
-
-   GSSAPI supports the use of user-specified tags to identify a given
-   context to the peer application.  These tags are used to identify the
-   particular communications channel that carries the context.  Channel
-   bindings are communicated to the GSSAPI using the following
-   structure:
-
-
-
-
-
-
-
-
-
-
-Wray                                                           [Page 11]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-                 typedef struct gss_channel_bindings_struct {
-                    OM_uint32       initiator_addrtype;
-                    gss_buffer_desc initiator_address;
-                    OM_uint32       acceptor_addrtype;
-                    gss_buffer_desc acceptor_address;
-                    gss_buffer_desc application_data;
-                 } *gss_channel_bindings_t;
-
-   The initiator_addrtype and acceptor_addrtype fields denote the type
-   of addresses contained in the initiator_address and acceptor_address
-   buffers.  The address type should be one of the following:
-
-          GSS_C_AF_UNSPEC      Unspecified address type
-          GSS_C_AF_LOCAL       Host-local address type
-          GSS_C_AF_INET        DARPA Internet address type
-          GSS_C_AF_IMPLINK     ARPAnet IMP address type (eg IP)
-          GSS_C_AF_PUP         pup protocols (eg BSP) address type
-          GSS_C_AF_CHAOS       MIT CHAOS protocol address type
-          GSS_C_AF_NS          XEROX NS address type
-          GSS_C_AF_NBS         nbs address type
-          GSS_C_AF_ECMA        ECMA address type
-          GSS_C_AF_DATAKIT     datakit protocols address type
-          GSS_C_AF_CCITT       CCITT protocols (eg X.25)
-          GSS_C_AF_SNA         IBM SNA address type
-          GSS_C_AF_DECnet      DECnet address type
-          GSS_C_AF_DLI         Direct data link interface address type
-          GSS_C_AF_LAT         LAT address type
-          GSS_C_AF_HYLINK      NSC Hyperchannel address type
-          GSS_C_AF_APPLETALK   AppleTalk address type
-          GSS_C_AF_BSC         BISYNC 2780/3780 address type
-          GSS_C_AF_DSS         Distributed system services address type
-          GSS_C_AF_OSI         OSI TP4 address type
-          GSS_C_AF_X25         X25
-          GSS_C_AF_NULLADDR    No address specified
-
-   Note that these name address families rather than specific addressing
-   formats.  For address families that contain several alternative
-   address forms, the initiator_address and acceptor_address fields must
-   contain sufficient information to determine which address form is
-   used.  When not otherwise specified, addresses should be specified in
-   network byte-order.
-
-   Conceptually, the GSSAPI concatenates the initiator_addrtype,
-   initiator_address, acceptor_addrtype, acceptor_address and
-   application_data to form an octet string.  The mechanism signs this
-   octet string, and binds the signature to the context establishment
-   token emitted by gss_init_sec_context.  The same bindings are
-   presented by the context acceptor to gss_accept_sec_context, and a
-
-
-
-Wray                                                           [Page 12]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-   signature is calculated in the same way.  The calculated signature is
-   compared with that found in the token, and if the signatures differ,
-   gss_accept_sec_context will return a GSS_S_BAD_BINDINGS error, and
-   the context will not be established.  Some mechanisms may include the
-   actual channel binding data in the token (rather than just a
-   signature); applications should therefore not use confidential data
-   as channel-binding components.  Individual mechanisms may impose
-   additional constraints on addresses and address types that may appear
-   in channel bindings.  For example, a mechanism may verify that the
-   initiator_address field of the channel bindings presented to
-   gss_init_sec_context contains the correct network address of the host
-   system.
-
-2.1.12. Optional parameters
-
-   Various parameters are described as optional.  This means that they
-   follow a convention whereby a default value may be requested.  The
-   following conventions are used for omitted parameters.  These
-   conventions apply only to those parameters that are explicitly
-   documented as optional.
-
-2.1.12.1. gss_buffer_t types
-
-   Specify GSS_C_NO_BUFFER as a value.  For an input parameter this
-   signifies that default behavior is requested, while for an output
-   parameter it indicates that the information that would be returned
-   via the parameter is not required by the application.
-
-2.1.12.2. Integer types (input)
-
-   Individual parameter documentation lists values to be used to
-   indicate default actions.
-
-2.1.12.3. Integer types (output)
-
-   Specify NULL as the value for the pointer.
-
-2.1.12.4. Pointer types
-
-   Specify NULL as the value.
-
-2.1.12.5. Object IDs
-
-   Specify GSS_C_NULL_OID as the value.
-
-2.1.12.6. Object ID Sets
-
-   Specify GSS_C_NULL_OID_SET as the value.
-
-
-
-Wray                                                           [Page 13]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-2.1.12.7. Credentials
-
-   Specify GSS_C_NO_CREDENTIAL to use the default credential handle.
-
-2.1.12.8. Channel Bindings
-
-   Specify GSS_C_NO_CHANNEL_BINDINGS to indicate that channel bindings
-   are not to be used.
-
-3. GSSAPI routine descriptions
-
-2.1. gss_acquire_cred
-
-      OM_uint32  gss_acquire_cred (
-                     OM_uint32 *     minor_status,
-                     gss_name_t      desired_name,
-                     OM_uint32       time_req,
-                     gss_OID_set     desired_mechs,
-                     int             cred_usage,
-                     gss_cred_id_t * output_cred_handle,
-                     gss_OID_set *   actual_mechs,
-                      OM_int32 *      time_rec)
-   Purpose:
-
-   Allows an application to acquire a handle for a pre-existing
-   credential by name.  GSSAPI implementations must impose a local
-   access-control policy on callers of this routine to prevent
-   unauthorized callers from acquiring credentials to which they are not
-   entitled.  This routine is not intended to provide a "login to the
-   network" function, as such a function would result in the creation of
-   new credentials rather than merely acquiring a handle to existing
-   credentials.  Such functions, if required, should be defined in
-   implementation-specific extensions to the API.
-
-   If credential acquisition is time-consuming for a mechanism, the
-   mechanism may chooses to delay the actual acquisition until the
-   credential is required (e.g., by gss_init_sec_context or
-   gss_accept_sec_context).  Such mechanism-specific implementation
-   decisions should be invisible to the calling application; thus a call
-   of gss_inquire_cred immediately following the call of
-   gss_acquire_cred must return valid credential data, and may therefore
-   incur the overhead of a deferred credential acquisition.
-
-   Parameters:
-
-      desired_name      gss_name_t, read
-                        Name of principal whose credential
-                        should be acquired
-
-
-
-Wray                                                           [Page 14]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-      time_req          integer, read
-                        number of seconds that credentials
-                        should remain valid
-
-      desired_mechs     Set of Object IDs, read
-                        set of underlying security mechanisms that
-                        may be used.  GSS_C_NULL_OID_SET may be used
-                        to obtain an implementation-specific default.
-
-      cred_usage        integer, read
-                        GSS_C_BOTH - Credentials may be used
-                                     either to initiate or accept
-                                     security contexts.
-                        GSS_C_INITIATE - Credentials will only be
-                                         used to initiate security
-                                         contexts.
-                        GSS_C_ACCEPT - Credentials will only be used to
-                                       accept security contexts.
-
-      output_cred_handle   gss_cred_id_t, modify
-                           The returned credential handle.
-
-      actual_mechs      Set of Object IDs, modify, optional
-                        The set of mechanisms for which the
-                        credential is valid.  Specify NULL
-                        if not required.
-
-      time_rec          Integer, modify, optional
-                        Actual number of seconds for which the
-                        returned credentials will remain valid.  If the
-                        implementation does not support expiration of
-                        credentials, the value GSS_C_INDEFINITE will
-                        be returned. Specify NULL if not required
-
-      minor_status      Integer, modify
-                        Mechanism specific status code.
-   Function value:
-
-      GSS status code:
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_BAD_MECH    Unavailable mechanism requested
-
-      GSS_S_BAD_NAMETYPE Type contained within desired_name parameter is
-                        not supported
-
-      GSS_S_BAD_NAME    Value supplied for desired_name parameter is
-
-
-
-Wray                                                           [Page 15]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-                        ill-formed.
-
-      GSS_S_FAILURE     Unspecified failure.  The minor_status parameter
-                        contains more detailed information
-
-3.2. gss_release_cred
-
-      OM_uint32  gss_release_cred (
-                     OM_uint32 *     minor_status,
-                     gss_cred_id_t * cred_handle)
-
-   Purpose:
-
-   Informs GSSAPI that the specified credential handle is no longer
-   required by the process.  When all processes have released a
-   credential, it will be deleted.
-
-   Parameters:
-
-      cred_handle       gss_cred_id_t, modify, optional
-                        buffer containing opaque credential
-                        handle.  If  GSS_C_NO_CREDENTIAL  is supplied,
-                        the default credential will be released
-
-      minor_status      integer, modify
-                        Mechanism specific status code.
-
-   Function value:
-
-      GSS status code:
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_NO_CRED     Credentials could not be accessed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wray                                                           [Page 16]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-3.3. gss_init_sec_context
-
-      OM_uint32  gss_init_sec_context (
-                     OM_uint32 *     minor_status,
-                     gss_cred_id_t   claimant_cred_handle,
-                     gss_ctx_id_t *  context_handle,
-                     gss_name_t      target_name,
-                     gss_OID         mech_type,
-                     int             req_flags,
-                     int             time_req,
-                     gss_channel_bindings_t
-                                     input_chan_bindings,
-                     gss_buffer_t    input_token
-                     gss_OID *       actual_mech_type,
-                     gss_buffer_t    output_token,
-                     int *           ret_flags,
-                     OM_uint32 *     time_rec )
-
-   Purpose:
-
-   Initiates the establishment of a security context between the
-   application and a remote peer.  Initially, the input_token parameter
-   should be specified as GSS_C_NO_BUFFER.  The routine may return a
-   output_token which should be transferred to the peer application,
-   where the peer application will present it to gss_accept_sec_context.
-   If no token need be sent, gss_init_sec_context will indicate this by
-   setting the length field of the output_token argument to zero.  To
-   complete the context establishment, one or more reply tokens may be
-   required from the peer application; if so, gss_init_sec_context will
-   return a status indicating GSS_S_CONTINUE_NEEDED in which case it
-   should be called again when the reply token is received from the peer
-   application, passing the token to gss_init_sec_context via the
-   input_token parameters.
-
-   The values returned via the ret_flags and time_rec parameters are not
-   defined unless the routine returns GSS_S_COMPLETE.
-
-   Parameters:
-
-      claimant_cred_handle  gss_cred_id_t, read, optional
-                            handle for credentials claimed.  Supply
-                            GSS_C_NO_CREDENTIAL to use default
-                            credentials.
-
-      context_handle    gss_ctx_id_t, read/modify
-                        context handle for new context.  Supply
-                        GSS_C_NO_CONTEXT for first call; use value
-                        returned by first call in continuation calls.
-
-
-
-Wray                                                           [Page 17]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-      target_name       gss_name_t, read
-                        Name of target
-
-      mech_type         OID, read, optional
-                        Object ID of desired mechanism. Supply
-                        GSS_C_NULL_OID to obtain an implementation
-                        specific default
-
-      req_flags         bit-mask, read
-                        Contains four independent flags, each of
-                        which requests that the context support a
-                        specific service option.  Symbolic
-                        names are provided for each flag, and the
-                        symbolic names corresponding to the required
-                        flags should be logically-ORed
-                        together to form the bit-mask value.  The
-                        flags are:
-
-                        GSS_C_DELEG_FLAG
-                              True - Delegate credentials to remote peer
-                              False - Don't delegate
-                        GSS_C_MUTUAL_FLAG
-                              True - Request that remote peer
-                                     authenticate itself
-                              False - Authenticate self to remote peer
-                                      only
-                        GSS_C_REPLAY_FLAG
-                              True - Enable replay detection for signed
-                                     or sealed messages
-                              False - Don't attempt to detect
-                                      replayed messages
-                        GSS_C_SEQUENCE_FLAG
-                              True - Enable detection of out-of-sequence
-                                     signed or sealed messages
-                              False - Don't attempt to detect
-                                      out-of-sequence messages
-
-      time_req          integer, read
-                        Desired number of seconds for which context
-                        should remain valid.  Supply 0 to request a
-                        default validity period.
-
-      input_chan_bindings     channel bindings, read
-                              Application-specified bindings.  Allows
-                              application to securely bind channel
-                              identification information to the security
-                              context.
-
-
-
-
-Wray                                                           [Page 18]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-      input_token       buffer, opaque, read, optional (see text)
-                        Token received from peer application.
-                        Supply GSS_C_NO_BUFFER on initial call.
-
-      actual_mech_type  OID, modify
-                        actual mechanism used.
-
-      output_token      buffer, opaque, modify
-                        token to be sent to peer application.  If
-                        the length field of the returned buffer is
-                        zero, no token need be sent to the peer
-                        application.
-
-      ret_flags         bit-mask, modify
-                        Contains six independent flags, each of which
-                        indicates that the context supports a specific
-                        service option.  Symbolic names are provided
-                        for each flag, and the symbolic names
-                        corresponding to the required flags should be
-                        logically-ANDed with the ret_flags value to test
-                        whether a given option is supported by the
-                        context.  The flags are:
-
-                        GSS_C_DELEG_FLAG
-                              True - Credentials were delegated to
-                                     the remote peer
-                              False - No credentials were delegated
-                        GSS_C_MUTUAL_FLAG
-                              True - Remote peer has been asked to
-                                     authenticated itself
-                              False - Remote peer has not been asked to
-                                      authenticate itself
-                        GSS_C_REPLAY_FLAG
-                              True - replay of signed or sealed messages
-                                     will be detected
-                              False - replayed messages will not be
-                                      detected
-                        GSS_C_SEQUENCE_FLAG
-                              True - out-of-sequence signed or sealed
-                                     messages will be detected
-                              False - out-of-sequence messages will not
-                                      be detected
-                        GSS_C_CONF_FLAG
-                              True - Confidentiality service may be
-                                     invoked by calling seal routine
-                              False - No confidentiality service (via
-                                      seal) available. seal will provide
-                                      message encapsulation, data-origin
-
-
-
-Wray                                                           [Page 19]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-                                      authentication and integrity
-                                      services only.
-                        GSS_C_INTEG_FLAG
-                              True - Integrity service may be invoked by
-                                     calling either gss_sign or gss_seal
-                                     routines.
-                              False - Per-message integrity service
-                                      unavailable.
-
-      time_rec          integer, modify, optional
-                        number of seconds for which the context
-                        will remain valid. If the implementation does
-                        not support credential expiration, the value
-                        GSS_C_INDEFINITE will be returned.  Specify
-                        NULL if not required.
-
-      minor_status      integer, modify
-                        Mechanism specific status code.
-
-   Function value:
-
-   GSS status code:
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_CONTINUE_NEEDED Indicates that a token from the peer
-                     application is required to complete thecontext, and
-                     that gss_init_sec_context must be called again with
-                     that token.
-
-   GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks performed on
-                     the input_token failed
-
-   GSS_S_DEFECTIVE_CREDENTIAL Indicates that consistency checks
-                     performed on the credential failed.
-
-   GSS_S_NO_CRED     The supplied credentials were not valid for context
-                     initiation, or the credential handle did not
-                     reference any credentials.
-
-   GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired
-
-   GSS_S_BAD_BINDINGS The input_token contains different channel
-                     bindings to those specified via the
-                     input_chan_bindings parameter
-
-   GSS_S_BAD_SIG     The input_token contains an invalid signature, or a
-                     signature that could not be verified
-
-
-
-Wray                                                           [Page 20]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-   GSS_S_OLD_TOKEN   The input_token was too old.  This is a fatal error
-                     during context establishment
-
-   GSS_S_DUPLICATE_TOKEN The input_token is valid, but is a duplicate of
-                     a token already processed.  This is a fatal error
-                     during context establishment.
-
-   GSS_S_NO_CONTEXT  Indicates that the supplied context handle did not
-                     refer to a valid context
-
-   GSS_S_BAD_NAMETYPE The provided target_name parameter contained an
-                     invalid or unsupported type of name
-
-   GSS_S_BAD_NAME    The provided target_name parameter was ill-formed.
-
-   GSS_S_FAILURE     Failure.  See minor_status for more information
-
-3.4. gss_accept_sec_context
-
-      OM_uint32  gss_accept_sec_context (
-                     OM_uint32 *     minor_status,
-                     gss_ctx_id_t *  context_handle,
-                     gss_cred_id_t   verifier_cred_handle,
-                     gss_buffer_t    input_token_buffer
-                     gss_channel_bindings_t
-                                     input_chan_bindings,
-                     gss_name_t *    src_name,
-                     gss_OID *       mech_type,
-                     gss_buffer_t    output_token,
-                     int *           ret_flags,
-                     OM_uint32 *     time_rec,
-                     gss_cred_id_t * delegated_cred_handle)
-
-   Purpose:
-
-   Allows a remotely initiated security context between the application
-   and a remote peer to be established.  The routine may return a
-   output_token which should be transferred to the peer application,
-   where the peer application will present it to gss_init_sec_context.
-   If no token need be sent, gss_accept_sec_context will indicate this
-   by setting the length field of the output_token argument to zero.  To
-   complete the context establishment, one or more reply tokens may be
-   required from the peer application; if so, gss_accept_sec_context
-   will return a status flag of GSS_S_CONTINUE_NEEDED, in which case it
-   should be called again when the reply token is received from the peer
-   application, passing the token to gss_accept_sec_context via the
-   input_token parameters.
-
-
-
-
-Wray                                                           [Page 21]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-   The values returned via the src_name, ret_flags, time_rec, and
-   delegated_cred_handle parameters are not defined unless the routine
-   returns GSS_S_COMPLETE.
-
-   Parameters:
-
-      context_handle    gss_ctx_id_t, read/modify
-                        context handle for new context.  Supply
-                        GSS_C_NO_CONTEXT for first call; use value
-                        returned in subsequent calls.
-
-      verifier_cred_handle    gss_cred_id_t, read, optional
-                              Credential handle claimed by context
-      acceptor.
-                              Specify GSS_C_NO_CREDENTIAL to use default
-                              credentials.  If GSS_C_NO_CREDENTIAL is
-                              specified, but the caller has no default
-                              credentials established, an
-                              implementation-defined default credential
-                              may be used.
-
-      input_token_buffer      buffer, opaque, read
-                              token obtained from remote application
-
-      input_chan_bindings     channel bindings, read
-                              Application-specified bindings.  Allows
-                              application to securely bind channel
-                              identification information to the security
-                              context.
-
-      src_name          gss_name_t, modify, optional
-                        Authenticated name of context initiator.
-                        After use, this name should be deallocated by
-                        passing it to gss_release_name.  If not required,
-                        specify NULL.
-
-      mech_type         Object ID, modify
-                        Security mechanism used.  The returned
-                        OID value will be a pointer into static
-                        storage, and should be treated as read-only
-                        by the caller.
-
-      output_token      buffer, opaque, modify
-                        Token to be passed to peer application. If the
-                        length field of the returned token buffer is 0,
-                        then no token need be passed to the peer
-                        application.
-
-
-
-
-Wray                                                           [Page 22]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-      ret_flags         bit-mask, modify
-                        Contains six independent flags, each of
-                        which indicates that the context supports a
-                        specific service option.  Symbolic names are
-                        provided for each flag, and the symbolic names
-                        corresponding to the required flags
-                        should be logically-ANDed with the ret_flags
-                        value to test whether a given option is
-                        supported by the context.  The flags are:
-                        GSS_C_DELEG_FLAG
-                              True - Delegated credentials are available
-                                     via the delegated_cred_handle
-                                     parameter
-                              False - No credentials were delegated
-                        GSS_C_MUTUAL_FLAG
-                              True - Remote peer asked for mutual
-                                     authentication
-                              False - Remote peer did not ask for mutual
-                                      authentication
-                        GSS_C_REPLAY_FLAG
-                              True - replay of signed or sealed messages
-                                     will be detected
-                              False - replayed messages will not be
-                                      detected
-                        GSS_C_SEQUENCE_FLAG
-                              True - out-of-sequence signed or sealed
-                                     messages will be detected
-                              False - out-of-sequence messages will not
-                                      be detected
-                        GSS_C_CONF_FLAG
-                              True - Confidentiality service may be
-                                     invoked by calling seal routine
-                              False - No confidentiality service (via
-                                      seal) available. seal will
-                                      provide message encapsulation,
-                                      data-origin authentication and
-                                      integrity services only.
-                        GSS_C_INTEG_FLAG
-                              True - Integrity service may be invoked
-                                     by calling either gss_sign or
-                                     gss_seal routines.
-                              False - Per-message integrity service
-                                      unavailable.
-
-      time_rec          integer, modify, optional
-                        number of seconds for which the context
-                        will remain valid. Specify NULL if not required.
-
-
-
-
-Wray                                                           [Page 23]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-      delegated_cred_handle
-                        gss_cred_id_t, modify
-                        credential handle for credentials received from
-                        context initiator.  Only valid if deleg_flag in
-                        ret_flags is true.
-
-      minor_status      integer, modify
-                        Mechanism specific status code.
-
-   Function value:
-
-      GSS status code:
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_CONTINUE_NEEDED Indicates that a token from the peer
-                        application is required to complete the context,
-                        and that gss_accept_sec_context must be called
-                        again with that token.
-
-      GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks
-                        performed on the input_token failed.
-
-      GSS_S_DEFECTIVE_CREDENTIAL Indicates that consistency checks
-                        performed on the credential failed.
-
-      GSS_S_NO_CRED The supplied credentials were not valid for
-                        context acceptance, or the credential handle
-                        did not reference any credentials.
-
-      GSS_S_CREDENTIALS_EXPIRED The referenced credentials have
-                        expired.
-
-      GSS_S_BAD_BINDINGS The input_token contains different channel
-                        bindings to those specified via the
-                        input_chan_bindings parameter.
-
-      GSS_S_NO_CONTEXT Indicates that the supplied context handle did
-                       not refer to a valid context.
-
-      GSS_S_BAD_SIG    The input_token contains an invalid signature.
-
-      GSS_S_OLD_TOKEN   The input_token was too old.  This is a fatal
-                        error during context establishment.
-
-      GSS_S_DUPLICATE_TOKEN The input_token is valid, but is a
-                        duplicate of a token already processed.  This
-                        is a fatal error during context establishment.
-
-
-
-Wray                                                           [Page 24]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-      GSS_S_FAILURE     Failure.  See minor_status for more information.
-
-3.5. gss_process_context_token
-
-      OM_uint32  gss_process_context_token (
-                     OM_uint32 *     minor_status,
-                     gss_ctx_id_t    context_handle,
-                     gss_buffer_t    token_buffer)
-
-   Purpose:
-
-   Provides a way to pass a token to the security service.  Usually,
-   tokens are associated either with context establishment (when they
-   would be passed to gss_init_sec_context or gss_accept_sec_context) or
-   with per-message security service (when they would be passed to
-   gss_verify or gss_unseal).  Occasionally, tokens may be received at
-   other times, and gss_process_context_token allows such tokens to be
-   passed to the underlying security service for processing.  At
-   present, such additional tokens may only be generated by
-   gss_delete_sec_context.  GSSAPI implementation may use this service
-   to implement deletion of the security context.
-
-   Parameters:
-
-      context_handle    gss_ctx_id_t, read
-                        context handle of context on which token is to
-                        be processed
-
-      token_buffer      buffer, opaque, read
-                        pointer to first byte of token to process
-
-      minor_status      integer, modify
-                        Implementation specific status code.
-
-   Function value:
-
-      GSS status code:
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks
-                        performed on the token failed
-
-      GSS_S_FAILURE     Failure.  See minor_status for more information
-
-      GSS_S_NO_CONTEXT The context_handle did not refer to a valid
-                       context
-
-
-
-
-Wray                                                           [Page 25]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-3.6. gss_delete_sec_context
-
-      OM_uint32  gss_delete_sec_context (
-                     OM_uint32 *     minor_status,
-                     gss_ctx_id_t *  context_handle,
-                     gss_buffer_t    output_token)
-
-   Purpose:
-
-   Delete a security context.  gss_delete_sec_context will delete the
-   local data structures associated with the specified security context,
-   and generate an output_token, which when passed to the peer
-   gss_process_context_token will instruct it to do likewise.  No
-   further security services may be obtained using the context specified
-   by context_handle.
-
-   Parameters:
-
-      minor_status      integer, modify
-                        Mechanism specific status code.
-
-      context_handle    gss_ctx_id_t, modify
-                        context handle identifying context to delete.
-
-      output_token      buffer, opaque, modify
-                        token to be sent to remote application to
-                        instruct it to also delete the context
-
-   Function value:
-
-      GSS status code:
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_FAILURE     Failure, see minor_status for more information
-
-      GSS_S_NO_CONTEXT  No valid context was supplied
-
-3.7. gss_context_time
-
-      OM_uint32  gss_context_time (
-                     OM_uint32 *     minor_status,
-                     gss_ctx_id_t    context_handle,
-                     OM_uint32 *     time_rec)
-   Purpose:
-
-   Determines the number of seconds for which the specified context will
-   remain valid.
-
-
-
-Wray                                                           [Page 26]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-      Parameters:
-
-      minor_status      integer, modify
-                        Implementation specific status code.
-
-      context_handle    gss_ctx_id_t, read
-                        Identifies the context to be interrogated.
-
-      time_rec          integer, modify
-                        Number of seconds that the context will remain
-                        valid.  If the context has already expired,
-                        zero will be returned.
-   Function value:
-
-      GSS status code:
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_CONTEXT_EXPIRED The context has already expired
-
-      GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
-                        associated credentials have expired
-
-      GSS_S_NO_CONTEXT The context_handle parameter did not identify a
-                        valid context
-
-3.8. gss_sign
-
-      OM_uint32  gss_sign (
-                     OM_uint32 *     minor_status,
-                     gss_ctx_id_t    context_handle,
-                     int             qop_req,
-                     gss_buffer_t    message_buffer,
-                     gss_buffer_t    msg_token)
-   Purpose:
-
-   Generates a cryptographic signature for the supplied message, and
-   places the signature in a token for transfer to the peer application.
-   The qop_req parameter allows a choice between several cryptographic
-   algorithms, if supported by the chosen mechanism.
-
-   Parameters:
-
-      minor_status      integer, modify
-                        Implementation specific status code.
-
-      context_handle    gss_ctx_id_t, read
-                        identifies the context on which the message
-
-
-
-Wray                                                           [Page 27]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-                        will be sent
-
-      qop_req           integer, read, optional
-                        Specifies requested quality of protection.
-                        Callers are encouraged, on portability grounds,
-                        to accept the default quality of protection
-                        offered by the chosen mechanism, which may be
-                        requested by specifying GSS_C_QOP_DEFAULT for
-                        this parameter.  If an unsupported protection
-                        strength is requested, gss_sign will return a
-                        major_status of GSS_S_FAILURE.
-
-      message_buffer    buffer, opaque, read
-                        message to be signed
-
-      msg_token         buffer, opaque, modify
-                        buffer to receive token
-
-   Function value:
-
-      GSS status code:
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_CONTEXT_EXPIRED The context has already expired
-
-      GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
-                        associated credentials have expired
-
-      GSS_S_NO_CONTEXT  The context_handle parameter did not identify a
-                        valid context
-
-      GSS_S_FAILURE     Failure. See minor_status for more information.
-
-3.9. gss_verify
-
-      OM_uint32  gss_verify (
-                     OM_uint32 *     minor_status,
-                     gss_ctx_id_t    context_handle,
-                     gss_buffer_t    message_buffer,
-                     gss_buffer_t    token_buffer,
-                     int *           qop_state)
-   Purpose:
-
-   Verifies that a cryptographic signature, contained in the token
-   parameter, fits the supplied message.  The qop_state parameter allows
-   a message recipient to determine the strength of protection that was
-   applied to the message.
-
-
-
-Wray                                                           [Page 28]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-   Parameters:
-
-      minor_status      integer, modify
-                        Mechanism specific status code.
-
-      context_handle    gss_ctx_id_t, read
-                        identifies the context on which the message
-                        arrived
-
-      message_buffer    buffer, opaque, read
-                        message to be verified
-
-      token_buffer      buffer, opaque, read
-                        token associated with message
-
-      qop_state         integer, modify
-                        quality of protection gained from signature
-
-   Function value:
-
-      GSS status code:
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_DEFECTIVE_TOKEN The token failed consistency checks
-
-      GSS_S_BAD_SIG     The signature was incorrect
-
-      GSS_S_DUPLICATE_TOKEN The token was valid, and contained a correct
-                        signature for the message, but it had already
-                        been processed
-
-      GSS_S_OLD_TOKEN   The token was valid, and contained a correct
-                        signature for the message, but it is too old
-
-      GSS_S_UNSEQ_TOKEN The token was valid, and contained a correct
-                        signature for the message, but has been
-                        verified out of sequence; an earlier token has
-                        been signed or sealed by the remote
-                        application, but not yet been processed
-                        locally.
-
-      GSS_S_CONTEXT_EXPIRED The context has already expired
-
-      GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
-                        associated credentials have expired
-
-
-
-
-
-Wray                                                           [Page 29]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-      GSS_S_NO_CONTEXT  The context_handle parameter did not identify a
-                        valid context
-
-      GSS_S_FAILURE     Failure.  See minor_status for more information.
-
-3.10. gss_seal
-
-      OM_uint32  gss_seal (
-                     OM_uint32 *     minor_status,
-                     gss_ctx_id_t    context_handle,
-                     int             conf_req_flag,
-                     int             qop_req
-                     gss_buffer_t    input_message_buffer,
-                     int *           conf_state,
-                     gss_buffer_t    output_message_buffer)
-
-   Purpose:
-
-   Cryptographically signs and optionally encrypts the specified
-   input_message.  The output_message contains both the signature and
-   the message.  The qop_req parameter allows a choice between several
-   cryptographic algorithms, if supported by the chosen mechanism.
-
-   Parameters:
-
-      minor_status      integer, modify
-                        Mechanism specific status code.
-
-      context_handle    gss_ctx_id_t, read
-                        identifies the context on which the message
-                        will be sent
-
-      conf_req_flag     boolean, read
-                        True - Both confidentiality and integrity
-                               services are requested
-                        False - Only integrity service is requested
-
-      qop_req           integer, read, optional
-                        Specifies required quality of protection.  A
-                        mechanism-specific default may be requested by
-                        setting qop_req to GSS_C_QOP_DEFAULT.  If an
-                        unsupported protection strength is requested,
-                        gss_seal will return a major_status of
-                        GSS_S_FAILURE.
-
-      input_message_buffer   buffer, opaque, read
-                             message to be sealed
-
-
-
-
-Wray                                                           [Page 30]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-      conf_state        boolean, modify
-                        True - Confidentiality, data origin
-                               authentication and integrity services
-                               have been applied
-                        False - Integrity and data origin services only
-                                has been applied.
-
-      output_message_buffer  buffer, opaque, modify
-                             buffer to receive sealed message
-
-   Function value:
-
-      GSS status code:
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_CONTEXT_EXPIRED The context has already expired
-
-      GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
-                        associated credentials have expired
-
-      GSS_S_NO_CONTEXT  The context_handle parameter did not identify a
-                        valid context
-
-      GSS_S_FAILURE     Failure.  See minor_status for more information.
-
-3.11. gss_unseal
-
-      OM_uint32  gss_unseal (
-                     OM_uint32 *     minor_status,
-                     gss_ctx_id_t    context_handle,
-                     gss_buffer_t    input_message_buffer,
-                     gss_buffer_t    output_message_buffer,
-                     int *           conf_state,
-                     int *           qop_state)
-
-   Purpose:
-
-   Converts a previously sealed message back to a usable form, verifying
-   the embedded signature.  The conf_state parameter indicates whether
-   the message was encrypted; the qop_state parameter indicates the
-   strength of protection that was used to provide the confidentiality
-   and integrity services.
-
-   Parameters:
-
-      minor_status      integer, modify
-                        Mechanism specific status code.
-
-
-
-Wray                                                           [Page 31]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-      context_handle    gss_ctx_id_t, read
-                        identifies the context on which the message
-                        arrived
-
-      input_message_buffer   buffer, opaque, read
-                             sealed message
-
-      output_message_buffer  buffer, opaque, modify
-                             buffer to receive unsealed message
-
-      conf_state        boolean, modify
-                        True - Confidentiality and integrity protection
-                               were used
-                        False - Inteegrity service only was used
-
-      qop_state         integer, modify
-                        quality of protection gained from signature
-
-   Function value:
-
-      GSS status code:
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_DEFECTIVE_TOKEN The token failed consistency checks
-
-      GSS_S_BAD_SIG     The signature was incorrect
-
-      GSS_S_DUPLICATE_TOKEN The token was valid, and contained a
-                        correct signature for the message, but it had
-                        already been processed
-
-      GSS_S_OLD_TOKEN The token was valid, and contained a correct
-                        signature for the message, but it is too old
-
-      GSS_S_UNSEQ_TOKEN The token was valid, and contained a correct
-                        signature for the message, but has been
-                        verified out of sequence; an earlier token has
-                        been signed or sealed by the remote
-                        application, but not yet been processed
-                        locally.
-
-      GSS_S_CONTEXT_EXPIRED The context has already expired
-
-      GSS_S_CREDENTIALS_EXPIRED The context is recognized, but
-                        associated credentials have expired
-
-
-
-
-
-Wray                                                           [Page 32]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-      GSS_S_NO_CONTEXT  The context_handle parameter did not identify a
-                        valid context
-
-      GSS_S_FAILURE     Failure.  See minor_status for more information.
-
-3.12. gss_display_status
-
-      OM_uint32  gss_display_status (
-                     OM_uint32 *     minor_status,
-                     int             status_value,
-                     int             status_type,
-                     gss_OID         mech_type,
-                     int *           message_context,
-                     gss_buffer_t    status_string)
-
-   Purpose:
-
-   Allows an application to obtain a textual representation of a GSSAPI
-   status code, for display to the user or for logging purposes.  Since
-   some status values may indicate multiple errors, applications may
-   need to call gss_display_status multiple times, each call generating
-   a single text string.  The message_context parameter is used to
-   indicate which error message should be extracted from a given
-   status_value; message_context should be initialized to 0, and
-   gss_display_status will return a non-zero value if there are further
-   messages to extract.
-
-   Parameters:
-
-      minor_status      integer, modify
-                        Mechanism specific status code.
-
-      status_value      integer, read
-                        Status value to be converted
-
-      status_type       integer, read
-                        GSS_C_GSS_CODE - status_value is a GSS status
-                                         code
-                        GSS_C_MECH_CODE - status_value is a mechanism
-                                          status code
-
-      mech_type         Object ID, read, optional
-                        Underlying mechanism (used to interpret a
-                        minor status value) Supply GSS_C_NULL_OID to
-                        obtain the system default.
-
-      message_context   integer, read/modify
-                        Should be initialized to zero by caller
-
-
-
-Wray                                                           [Page 33]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-                        on first call.  If further messages are
-                        contained in the status_value parameter,
-                        message_context will be non-zero on return,
-                        and this value should be passed back to
-                        subsequent calls, along with the same
-                        status_value, status_type and mech_type
-                        parameters.
-
-      status_string     buffer, character string, modify
-                        textual interpretation of the status_value
-
-   Function value:
-
-      GSS status code:
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_BAD_MECH    Indicates that translation in accordance with
-                        an unsupported mechanism type was requested
-
-      GSS_S_BAD_STATUS The status value was not recognized, or the
-                        status type was neither GSS_C_GSS_CODE nor
-                        GSS_C_MECH_CODE.
-
-
-3.13. gss_indicate_mechs
-
-      OM_uint32  gss_indicate_mechs (
-                     OM_uint32 *     minor_status,
-                     gss_OID_set *   mech_set)
-
-   Purpose:
-
-         Allows an application to determine which underlying security
-         mechanisms are available.
-
-   Parameters:
-
-      minor_status      integer, modify
-                        Mechanism specific status code.
-
-      mech_set          set of Object IDs, modify
-                        set of implementation-supported mechanisms.
-                        The returned gss_OID_set value will be a
-                        pointer into static storage, and should be
-                        treated as read-only by the caller.
-
-
-
-
-
-Wray                                                           [Page 34]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-   Function value:
-
-      GSS status code:
-
-      GSS_S_COMPLETE    Successful completion
-
-3.14. gss_compare_name
-
-      OM_uint32  gss_compare_name (
-                     OM_uint32 *     minor_status,
-                     gss_name_t      name1,
-                     gss_name_t      name2,
-                     int *           name_equal)
-
-   Purpose:
-
-   Allows an application to compare two internal-form names to determine
-   whether they refer to the same entity.
-
-   Parameters:
-
-      minor_status      integer, modify
-                        Mechanism specific status code.
-
-      name1             gss_name_t, read
-                        internal-form  name
-
-      name2             gss_name_t, read
-                        internal-form  name
-
-      name_equal        boolean, modify
-                        True - names refer to same entity
-                        False - names refer to different entities
-                                (strictly, the names are not known to
-                                refer to the same identity).
-   Function value:
-
-      GSS status code:
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_BAD_NAMETYPE The type contained within either name1 or
-                        name2 was unrecognized, or the names were of
-                        incomparable types.
-
-      GSS_S_BAD_NAME    One or both of name1 or name2 was ill-formed
-
-
-
-
-
-Wray                                                           [Page 35]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-3.15. gss_display_name
-
-      OM_uint32  gss_display_name (
-                     OM_uint32 *     minor_status,
-                     gss_name_t      input_name,
-                     gss_buffer_t    output_name_buffer,
-                     gss_OID *       output_name_type)
-
-   Purpose:
-
-   Allows an application to obtain a textual representation of an opaque
-   internal-form  name for display purposes.  The syntax of a printable
-   name is defined by the GSSAPI implementation.
-
-   Parameters:
-
-      minor_status      integer, modify
-                        Mechanism specific status code.
-
-      input_name        gss_name_t, read
-                        name to be displayed
-
-      output_name_buffer   buffer, character-string, modify
-                           buffer to receive textual name string
-
-      output_name_type  Object ID, modify
-                        The type of the returned name.  The returned
-                        gss_OID will be a pointer into static storage,
-                        and should be treated as read-only by the caller
-
-   Function value:
-
-      GSS status code:
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_BAD_NAMETYPE The type of input_name was not recognized
-
-      GSS_S_BAD_NAME    input_name was ill-formed
-
-3.16. gss_import_name
-
-      OM_uint32 gss_import_name (
-                    OM_uint32 *     minor_status,
-                    gss_buffer_t    input_name_buffer,
-                    gss_OID         input_name_type,
-                    gss_name_t *    output_name)
-
-
-
-
-Wray                                                           [Page 36]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-   Purpose:
-
-   Convert a printable name to internal form.
-
-   Parameters:
-
-      minor_status      integer, modify
-                        Mechanism specific status code
-
-      input_name_buffer    buffer, character-string, read
-                           buffer containing printable name to convert
-
-      input_name_type   Object ID, read, optional
-                        Object Id specifying type of printable
-                        name.  Applications may specify either
-                        GSS_C_NULL_OID to use a local system-specific
-                        printable syntax, or an OID registered by the
-                        GSSAPI implementation to name a particular
-                        namespace.
-
-      output_name       gss_name_t, modify
-                        returned name in internal form
-
-   Function value:
-
-      GSS status code
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_BAD_NAMETYPE The input_name_type was unrecognized
-
-      GSS_S_BAD_NAME    The input_name parameter could not be
-                        interpreted as a name of the specified type
-
-3.17. gss_release_name
-
-      OM_uint32 gss_release_name (
-                    OM_uint32 *     minor_status,
-                    gss_name_t *    name)
-
-   Purpose:
-
-   Free GSSAPI-allocated storage associated with an internal form name.
-
-   Parameters:
-
-      minor_status      integer, modify
-                        Mechanism specific status code
-
-
-
-Wray                                                           [Page 37]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-      name              gss_name_t, modify
-                        The name to be deleted
-
-   Function value:
-
-      GSS status code
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_BAD_NAME    The name parameter did not contain a valid name
-
-3.18. gss_release_buffer
-
-      OM_uint32 gss_release_buffer (
-                    OM_uint32 *     minor_status,
-                    gss_buffer_t    buffer)
-
-   Purpose:
-
-   Free storage associated with a buffer format name.  The storage must
-   have been allocated by a GSSAPI routine.  In addition to freeing the
-   associated storage, the routine will zero the length field in the
-   buffer parameter.
-
-   Parameters:
-
-      minor_status      integer, modify
-                        Mechanism specific status code
-
-      buffer            buffer, modify
-                        The storage associated with the buffer will be
-                        deleted.  The gss_buffer_desc object will not
-                        be freed, but its length field will be zeroed.
-
-   Function value:
-
-      GSS status code
-
-      GSS_S_COMPLETE    Successful completion
-
-3.19. gss_release_oid_set
-
-      OM_uint32 gss_release_oid_set (
-                    OM_uint32 *     minor_status,
-                    gss_OID_set *   set)
-
-   Purpose:
-
-
-
-
-Wray                                                           [Page 38]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-   Free storage associated with a gss_OID_set object.  The storage must
-   have been allocated by a GSSAPI routine.
-
-   Parameters:
-
-      minor_status      integer, modify
-                        Mechanism specific status code
-
-      set               Set of Object IDs, modify
-                        The storage associated with the gss_OID_set
-                        will be deleted.
-
-   Function value:
-
-      GSS status code
-
-      GSS_S_COMPLETE    Successful completion
-
-3.20. gss_inquire_cred
-
-      OM_uint32 gss_inquire_cred (
-                    OM_uint32  *    minor_status,
-                    gss_cred_id_t   cred_handle,
-                    gss_name_t *    name,
-                    OM_uint32 *     lifetime,
-                    int *           cred_usage,
-                    gss_OID_set *   mechanisms )
-
-   Purpose:
-
-   Obtains information about a credential.  The caller must already have
-   obtained a handle that refers to the credential.
-
-   Parameters:
-
-      minor_status      integer, modify
-                        Mechanism specific status code
-
-      cred_handle       gss_cred_id_t, read
-                        A handle that refers to the target credential.
-                        Specify GSS_C_NO_CREDENTIAL to inquire about
-                        the default credential.
-
-      name              gss_name_t, modify
-                        The name whose identity the credential asserts.
-                        Specify NULL if not required.
-
-      lifetime          Integer, modify
-
-
-
-Wray                                                           [Page 39]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-                        The number of seconds for which the credential
-                        will remain valid.  If the credential has
-                        expired, this parameter will be set to zero.
-                        If the implementation does not support
-                        credential expiration, the value
-                        GSS_C_INDEFINITE will be returned.  Specify
-                        NULL if not required.
-
-      cred_usage        Integer, modify
-                        How the credential may be used.  One of the
-                        following:
-                           GSS_C_INITIATE
-                           GSS_C_ACCEPT
-                           GSS_C_BOTH
-                        Specify NULL if not required.
-
-      mechanisms        gss_OID_set, modify
-                        Set of mechanisms supported by the credential.
-                        Specify NULL if not required.
-
-   Function value:
-
-      GSS status code
-
-      GSS_S_COMPLETE    Successful completion
-
-      GSS_S_NO_CRED     The referenced credentials could not be
-                        accessed.
-
-      GSS_S_DEFECTIVE_CREDENTIAL The referenced credentials were
-                        invalid.
-
-      GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired.
-                        If the lifetime parameter was not passed as
-                        NULL, it will be set to 0.
-
-
-  #ifndef GSSAPI_H_
-  #define GSSAPI_H_
-
-  /*
-   * First, define the platform-dependent types.
-   */
-  typedef <platform-specific> OM_uint32;
-  typedef <platform-specific> gss_ctx_id_t;
-  typedef <platform-specific> gss_cred_id_t;
-  typedef <platform-specific> gss_name_t;
-
-
-
-
-Wray                                                           [Page 40]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-  /*
-   * Note that a platform supporting the xom.h X/Open header file
-   * may make use of that header for the definitions of OM_uint32
-   * and the structure to which gss_OID_desc equates.
-   */
-
-  typedef struct gss_OID_desc_struct {
-        OM_uint32 length;
-        void      *elements;
-  } gss_OID_desc, *gss_OID;
-
-  typedef struct gss_OID_set_desc_struct  {
-        int     count;
-        gss_OID elements;
-  } gss_OID_set_desc, *gss_OID_set;
-
-  typedef struct gss_buffer_desc_struct {
-        size_t length;
-        void *value;
-  } gss_buffer_desc, *gss_buffer_t;
-
-  typedef struct gss_channel_bindings_struct {
-        OM_uint32 initiator_addrtype;
-        gss_buffer_desc initiator_address;
-        OM_uint32 acceptor_addrtype;
-        gss_buffer_desc acceptor_address;
-        gss_buffer_desc application_data;
-  } *gss_channel_bindings_t;
-
-
-  /*
-   * Six independent flags each of which indicates that a context
-   * supports a specific service option.
-   */
-  #define GSS_C_DELEG_FLAG 1
-  #define GSS_C_MUTUAL_FLAG 2
-  #define GSS_C_REPLAY_FLAG 4
-  #define GSS_C_SEQUENCE_FLAG 8
-  #define GSS_C_CONF_FLAG 16
-  #define GSS_C_INTEG_FLAG 32
-
-
-  /*
-   * Credential usage options
-   */
-  #define GSS_C_BOTH 0
-  #define GSS_C_INITIATE 1
-  #define GSS_C_ACCEPT 2
-
-
-
-Wray                                                           [Page 41]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-  /*
-   * Status code types for gss_display_status
-   */
-  #define GSS_C_GSS_CODE 1
-  #define GSS_C_MECH_CODE 2
-
-  /*
-   * The constant definitions for channel-bindings address families
-   */
-  #define GSS_C_AF_UNSPEC     0;
-  #define GSS_C_AF_LOCAL      1;
-  #define GSS_C_AF_INET       2;
-  #define GSS_C_AF_IMPLINK    3;
-  #define GSS_C_AF_PUP        4;
-  #define GSS_C_AF_CHAOS      5;
-  #define GSS_C_AF_NS         6;
-  #define GSS_C_AF_NBS        7;
-  #define GSS_C_AF_ECMA       8;
-  #define GSS_C_AF_DATAKIT    9;
-  #define GSS_C_AF_CCITT      10;
-  #define GSS_C_AF_SNA        11;
-  #define GSS_C_AF_DECnet     12;
-  #define GSS_C_AF_DLI        13;
-  #define GSS_C_AF_LAT        14;
-  #define GSS_C_AF_HYLINK     15;
-  #define GSS_C_AF_APPLETALK  16;
-  #define GSS_C_AF_BSC        17;
-  #define GSS_C_AF_DSS        18;
-  #define GSS_C_AF_OSI        19;
-  #define GSS_C_AF_X25        21;
-
-  #define GSS_C_AF_NULLADDR   255;
-
-  #define GSS_C_NO_BUFFER ((gss_buffer_t) 0)
-  #define GSS_C_NULL_OID ((gss_OID) 0)
-  #define GSS_C_NULL_OID_SET ((gss_OID_set) 0)
-  #define GSS_C_NO_CONTEXT ((gss_ctx_id_t) 0)
-  #define GSS_C_NO_CREDENTIAL ((gss_cred_id_t) 0)
-  #define GSS_C_NO_CHANNEL_BINDINGS ((gss_channel_bindings_t) 0)
-  #define GSS_C_EMPTY_BUFFER {0, NULL}
-
-  /*
-   * Define the default Quality of Protection for per-message
-   * services.  Note that an implementation that offers multiple
-   * levels of QOP may either reserve a value (for example zero,
-   * as assumed here) to mean "default protection", or alternatively
-   * may simply equate GSS_C_QOP_DEFAULT to a specific explicit QOP
-   * value.
-
-
-
-Wray                                                           [Page 42]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-   */
-  #define GSS_C_QOP_DEFAULT 0
-
-  /*
-   * Expiration time of 2^32-1 seconds means infinite lifetime for a
-   * credential or security context
-   */
-  #define GSS_C_INDEFINITE 0xfffffffful
-
-
-  /* Major status codes */
-
-  #define GSS_S_COMPLETE 0
-
-  /*
-   * Some "helper" definitions to make the status code macros obvious.
-   */
-  #define GSS_C_CALLING_ERROR_OFFSET 24
-  #define GSS_C_ROUTINE_ERROR_OFFSET 16
-  #define GSS_C_SUPPLEMENTARY_OFFSET 0
-  #define GSS_C_CALLING_ERROR_MASK 0377ul
-  #define GSS_C_ROUTINE_ERROR_MASK 0377ul
-  #define GSS_C_SUPPLEMENTARY_MASK 0177777ul
-
-  /*
-   * The macros that test status codes for error conditions
-   */
-  #define GSS_CALLING_ERROR(x) \
-    (x & (GSS_C_CALLING_ERROR_MASK << GSS_C_CALLING_ERROR_OFFSET))
-  #define GSS_ROUTINE_ERROR(x) \
-    (x & (GSS_C_ROUTINE_ERROR_MASK << GSS_C_ROUTINE_ERROR_OFFSET))
-  #define GSS_SUPPLEMENTARY_INFO(x) \
-    (x & (GSS_C_SUPPLEMENTARY_MASK << GSS_C_SUPPLEMENTARY_OFFSET))
-  #define GSS_ERROR(x) \
-    ((GSS_CALLING_ERROR(x) != 0) || (GSS_ROUTINE_ERROR(x) != 0))
-
-
-  /*
-   * Now the actual status code definitions
-   */
-
-  /*
-   * Calling errors:
-   */
-  #define GSS_S_CALL_INACCESSIBLE_READ \
-                               (1ul << GSS_C_CALLING_ERROR_OFFSET)
-  #define GSS_S_CALL_INACCESSIBLE_WRITE \
-                               (2ul << GSS_C_CALLING_ERROR_OFFSET)
-
-
-
-Wray                                                           [Page 43]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-  #define GSS_S_CALL_BAD_STRUCTURE \
-                               (3ul << GSS_C_CALLING_ERROR_OFFSET)
-
-  /*
-   * Routine errors:
-   */
-  #define GSS_S_BAD_MECH (1ul << GSS_C_ROUTINE_ERROR_OFFSET)
-  #define GSS_S_BAD_NAME (2ul << GSS_C_ROUTINE_ERROR_OFFSET)
-  #define GSS_S_BAD_NAMETYPE (3ul << GSS_C_ROUTINE_ERROR_OFFSET)
-  #define GSS_S_BAD_BINDINGS (4ul << GSS_C_ROUTINE_ERROR_OFFSET)
-  #define GSS_S_BAD_STATUS (5ul << GSS_C_ROUTINE_ERROR_OFFSET)
-  #define GSS_S_BAD_SIG (6ul << GSS_C_ROUTINE_ERROR_OFFSET)
-  #define GSS_S_NO_CRED (7ul << GSS_C_ROUTINE_ERROR_OFFSET)
-  #define GSS_S_NO_CONTEXT (8ul << GSS_C_ROUTINE_ERROR_OFFSET)
-  #define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
-  #define GSS_S_DEFECTIVE_CREDENTIAL (10ul << GSS_C_ROUTINE_ERROR_OFFSET)
-  #define GSS_S_CREDENTIALS_EXPIRED (11ul << GSS_C_ROUTINE_ERROR_OFFSET)
-  #define GSS_S_CONTEXT_EXPIRED (12ul << GSS_C_ROUTINE_ERROR_OFFSET)
-  #define GSS_S_FAILURE (13ul << GSS_C_ROUTINE_ERROR_OFFSET)
-
-  /*
-   * Supplementary info bits:
-   */
-  #define GSS_S_CONTINUE_NEEDED (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 0))
-  #define GSS_S_DUPLICATE_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 1))
-  #define GSS_S_OLD_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 2))
-  #define GSS_S_UNSEQ_TOKEN (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 3))
-
-
-  /*
-   * Finally, function prototypes for the GSSAPI routines.
-   */
-
-  OM_uint32 gss_acquire_cred
-             (OM_uint32*,       /* minor_status */
-              gss_name_t,       /* desired_name */
-              OM_uint32,        /* time_req */
-              gss_OID_set,      /* desired_mechs */
-              int,              /* cred_usage */
-              gss_cred_id_t*,   /* output_cred_handle */
-              gss_OID_set*,     /* actual_mechs */
-              OM_uint32*        /* time_rec */
-             );
-
-  OM_uint32 gss_release_cred,
-             (OM_uint32*,       /* minor_status */
-              gss_cred_id_t*    /* cred_handle */
-             );
-
-
-
-Wray                                                           [Page 44]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-  OM_uint32 gss_init_sec_context
-             (OM_uint32*,       /* minor_status */
-              gss_cred_id_t,    /* claimant_cred_handle */
-              gss_ctx_id_t*,    /* context_handle */
-              gss_name_t,       /* target_name */
-              gss_OID,          /* mech_type */
-              int,              /* req_flags */
-              OM_uint32,        /* time_req */
-              gss_channel_bindings_t,
-                                /* input_chan_bindings */
-              gss_buffer_t,     /* input_token */
-              gss_OID*,         /* actual_mech_type */
-              gss_buffer_t,     /* output_token */
-              int*,             /* ret_flags */
-              OM_uint32*        /* time_rec */
-             );
-
-  OM_uint32 gss_accept_sec_context
-             (OM_uint32*,       /* minor_status */
-              gss_ctx_id_t*,    /* context_handle */
-              gss_cred_id_t,    /* verifier_cred_handle */
-              gss_buffer_t,     /* input_token_buffer */
-              gss_channel_bindings_t,
-                                /* input_chan_bindings */
-              gss_name_t*,      /* src_name */
-              gss_OID*,         /* mech_type */
-              gss_buffer_t,     /* output_token */
-              int*,             /* ret_flags */
-              OM_uint32*,       /* time_rec */
-              gss_cred_id_t*    /* delegated_cred_handle */
-             );
-
-  OM_uint32 gss_process_context_token
-             (OM_uint32*,       /* minor_status */
-              gss_ctx_id_t,     /* context_handle */
-              gss_buffer_t      /* token_buffer */
-             );
-
-  OM_uint32 gss_delete_sec_context
-             (OM_uint32*,       /* minor_status */
-              gss_ctx_id_t*,    /* context_handle */
-              gss_buffer_t      /* output_token */
-             );
-
-
-
-
-
-
-
-
-Wray                                                           [Page 45]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-  OM_uint32 gss_context_time
-             (OM_uint32*,       /* minor_status */
-              gss_ctx_id_t,     /* context_handle */
-              OM_uint32*        /* time_rec */
-             );
-
-  OM_uint32 gss_sign
-             (OM_uint32*,       /* minor_status */
-              gss_ctx_id_t,     /* context_handle */
-              int,              /* qop_req */
-              gss_buffer_t,     /* message_buffer */
-              gss_buffer_t      /* message_token */
-             );
-
-  OM_uitn32 gss_verify
-             (OM_uint32*,       /* minor_status */
-              gss_ctx_id_t,     /* context_handle */
-              gss_buffer_t,     /* message_buffer */
-              gss_buffer_t,     /* token_buffer */
-              int*              /* qop_state */
-             );
-
-  OM_uint32 gss_seal
-             (OM_uint32*,       /* minor_status */
-              gss_ctx_id_t,     /* context_handle */
-              int,              /* conf_req_flag */
-              int,              /* qop_req */
-              gss_buffer_t,     /* input_message_buffer */
-              int*,             /* conf_state */
-              gss_buffer_t      /* output_message_buffer */
-             );
-
-  OM_uint32 gss_unseal
-             (OM_uint32*,       /* minor_status */
-              gss_ctx_id_t,     /* context_handle */
-              gss_buffer_t,     /* input_message_buffer */
-              gss_buffer_t,     /* output_message_buffer */
-              int*,             /* conf_state */
-              int*              /* qop_state */
-             );
-
-
-
-
-
-
-
-
-
-
-
-Wray                                                           [Page 46]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-  OM_uint32 gss_display_status
-             (OM_uint32*,       /* minor_status */
-              OM_uint32,        /* status_value */
-              int,              /* status_type */
-              gss_OID,          /* mech_type */
-              int*,             /* message_context */
-              gss_buffer_t      /* status_string */
-             );
-
-  OM_uint32 gss_indicate_mechs
-             (OM_uint32*,       /* minor_status */
-              gss_OID_set*      /* mech_set */
-             );
-
-  OM_uint32 gss_compare_name
-             (OM_uint32*,       /* minor_status */
-              gss_name_t,       /* name1 */
-              gss_name_t,       /* name2 */
-              int*              /* name_equal */
-             );
-
-  OM_uint32 gss_display_name,
-             (OM_uint32*,      /* minor_status */
-              gss_name_t,      /* input_name */
-              gss_buffer_t,     /* output_name_buffer */
-              gss_OID*         /* output_name_type */
-             );
-
-  OM_uint32 gss_import_name
-             (OM_uint32*,       /* minor_status */
-              gss_buffer_t,     /* input_name_buffer */
-              gss_OID,          /* input_name_type */
-              gss_name_t*       /* output_name */
-             );
-
-  OM_uint32 gss_release_name
-             (OM_uint32*,       /* minor_status */
-              gss_name_t*       /* input_name */
-             );
-
-  OM_uint32 gss_release_buffer
-             (OM_uint32*,       /* minor_status */
-              gss_buffer_t      /* buffer */
-             );
-
-  OM_uint32 gss_release_oid_set
-             (OM_uint32*,       /* minor_status */
-              gss_OID_set*      /* set */
-
-
-
-Wray                                                           [Page 47]
-
-RFC 1509            GSSAPI - Overview and C bindings      September 1993
-
-
-             );
-
-  OM_uint32 gss_inquire_cred
-             (OM_uint32 *,      /* minor_status */
-              gss_cred_id_t,    /* cred_handle */
-              gss_name_t *,     /* name */
-              OM_uint32 *,      /* lifetime */
-              int *,            /* cred_usage */
-              gss_OID_set *     /* mechanisms */
-             );
-
-
-
-  #endif /* GSSAPI_H_ */
-
-References
-
-   [1] Linn, J., "Generic Security Service Application Program
-       Interface", RFC 1508, Geer Zolot Associate, September 1993.
-
-   [2] "OSI Object Management API Specification, Version 2.0 t", X.400
-       API Association & X/Open Company Limited, August 24, 1990.
-       Specification of datatypes and routines for manipulating
-       information objects.
-
-Security Considerations
-
-   Security issues are discussed throughout this memo.
-
-Author's Address
-
-   John Wray
-   Digital Equipment Corporation
-   550 King Street, LKG2-2/AA6
-   Littleton, MA  01460
-   USA
-
-   Phone: +1-508-486-5210
-   EMail: Wray@tuxedo.enet.dec.com
-
-
-
-
-
-
-
-
-
-
-
-
-Wray                                                           [Page 48]
-
\ No newline at end of file
diff --git a/doc/standardisation/rfc1510.txt b/doc/standardisation/rfc1510.txt
deleted file mode 100644
index bc810cc50..000000000
--- a/doc/standardisation/rfc1510.txt
+++ /dev/null
@@ -1,6275 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            J. Kohl
-Request for Comments: 1510                 Digital Equipment Corporation
-                                                               C. Neuman
-                                                                     ISI
-                                                          September 1993
-
-
-            The Kerberos Network Authentication Service (V5)
-
-Status of this Memo
-
-   This RFC 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" for the standardization state and status
-   of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This document gives an overview and specification of Version 5 of the
-   protocol for the Kerberos network authentication system. Version 4,
-   described elsewhere [1,2], is presently in production use at MIT's
-   Project Athena, and at other Internet sites.
-
-Overview
-
-   Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos,
-   Moira, and Zephyr are trademarks of the Massachusetts Institute of
-   Technology (MIT).  No commercial use of these trademarks may be made
-   without prior written permission of MIT.
-
-   This RFC describes the concepts and model upon which the Kerberos
-   network authentication system is based. It also specifies Version 5
-   of the Kerberos protocol.
-
-   The motivations, goals, assumptions, and rationale behind most design
-   decisions are treated cursorily; for Version 4 they are fully
-   described in the Kerberos portion of the Athena Technical Plan [1].
-   The protocols are under review, and are not being submitted for
-   consideration as an Internet standard at this time.  Comments are
-   encouraged.  Requests for addition to an electronic mailing list for
-   discussion of Kerberos, kerberos@MIT.EDU, may be addressed to
-   kerberos-request@MIT.EDU.  This mailing list is gatewayed onto the
-   Usenet as the group comp.protocols.kerberos.  Requests for further
-   information, including documents and code availability, may be sent
-   to info-kerberos@MIT.EDU.
-
-
-
-
-
-Kohl & Neuman                                                   [Page 1]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-Background
-
-   The Kerberos model is based in part on Needham and Schroeder's
-   trusted third-party authentication protocol [3] and on modifications
-   suggested by Denning and Sacco [4].  The original design and
-   implementation of Kerberos Versions 1 through 4 was the work of two
-   former Project Athena staff members, Steve Miller of Digital
-   Equipment Corporation and Clifford Neuman (now at the Information
-   Sciences Institute of the University of Southern California), along
-   with Jerome Saltzer, Technical Director of Project Athena, and
-   Jeffrey Schiller, MIT Campus Network Manager.  Many other members of
-   Project Athena have also contributed to the work on Kerberos.
-   Version 4 is publicly available, and has seen wide use across the
-   Internet.
-
-   Version 5 (described in this document) has evolved from Version 4
-   based on new requirements and desires for features not available in
-   Version 4.  Details on the differences between Kerberos Versions 4
-   and 5 can be found in [5].
-
-Table of Contents
-
-   1. Introduction .......................................    5
-   1.1. Cross-Realm Operation ............................    7
-   1.2. Environmental assumptions ........................    8
-   1.3. Glossary of terms ................................    9
-   2. Ticket flag uses and requests ......................   12
-   2.1. Initial and pre-authenticated tickets ............   12
-   2.2. Invalid tickets ..................................   12
-   2.3. Renewable tickets ................................   12
-   2.4. Postdated tickets ................................   13
-   2.5. Proxiable and proxy tickets ......................   14
-   2.6. Forwardable tickets ..............................   15
-   2.7. Other KDC options ................................   15
-   3. Message Exchanges ..................................   16
-   3.1. The Authentication Service Exchange ..............   16
-   3.1.1. Generation of KRB_AS_REQ message ...............   17
-   3.1.2. Receipt of KRB_AS_REQ message ..................   17
-   3.1.3. Generation of KRB_AS_REP message ...............   17
-   3.1.4. Generation of KRB_ERROR message ................   19
-   3.1.5. Receipt of KRB_AS_REP message ..................   19
-   3.1.6. Receipt of KRB_ERROR message ...................   20
-   3.2. The Client/Server Authentication Exchange ........   20
-   3.2.1. The KRB_AP_REQ message .........................   20
-   3.2.2. Generation of a KRB_AP_REQ message .............   20
-   3.2.3. Receipt of KRB_AP_REQ message ..................   21
-   3.2.4. Generation of a KRB_AP_REP message .............   23
-   3.2.5. Receipt of KRB_AP_REP message ..................   23
-
-
-
-Kohl & Neuman                                                   [Page 2]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   3.2.6. Using the encryption key .......................   24
-   3.3. The Ticket-Granting Service (TGS) Exchange .......   24
-   3.3.1. Generation of KRB_TGS_REQ message ..............   25
-   3.3.2. Receipt of KRB_TGS_REQ message .................   26
-   3.3.3. Generation of KRB_TGS_REP message ..............   27
-   3.3.3.1. Encoding the transited field .................   29
-   3.3.4. Receipt of KRB_TGS_REP message .................   31
-   3.4. The KRB_SAFE Exchange ............................   31
-   3.4.1. Generation of a KRB_SAFE message ...............   31
-   3.4.2. Receipt of KRB_SAFE message ....................   32
-   3.5. The KRB_PRIV Exchange ............................   33
-   3.5.1. Generation of a KRB_PRIV message ...............   33
-   3.5.2. Receipt of KRB_PRIV message ....................   33
-   3.6. The KRB_CRED Exchange ............................   34
-   3.6.1. Generation of a KRB_CRED message ...............   34
-   3.6.2. Receipt of KRB_CRED message ....................   34
-   4. The Kerberos Database ..............................   35
-   4.1. Database contents ................................   35
-   4.2. Additional fields ................................   36
-   4.3. Frequently Changing Fields .......................   37
-   4.4. Site Constants ...................................   37
-   5. Message Specifications .............................   38
-   5.1. ASN.1 Distinguished Encoding Representation ......   38
-   5.2. ASN.1 Base Definitions ...........................   38
-   5.3. Tickets and Authenticators .......................   42
-   5.3.1. Tickets ........................................   42
-   5.3.2. Authenticators .................................   47
-   5.4. Specifications for the AS and TGS exchanges ......   49
-   5.4.1. KRB_KDC_REQ definition .........................   49
-   5.4.2. KRB_KDC_REP definition .........................   56
-   5.5. Client/Server (CS) message specifications ........   58
-   5.5.1. KRB_AP_REQ definition ..........................   58
-   5.5.2. KRB_AP_REP definition ..........................   60
-   5.5.3. Error message reply ............................   61
-   5.6. KRB_SAFE message specification ...................   61
-   5.6.1. KRB_SAFE definition ............................   61
-   5.7. KRB_PRIV message specification ...................   62
-   5.7.1. KRB_PRIV definition ............................   62
-   5.8. KRB_CRED message specification ...................   63
-   5.8.1. KRB_CRED definition ............................   63
-   5.9. Error message specification ......................   65
-   5.9.1. KRB_ERROR definition ...........................   66
-   6. Encryption and Checksum Specifications .............   67
-   6.1. Encryption Specifications ........................   68
-   6.2. Encryption Keys ..................................   71
-   6.3. Encryption Systems ...............................   71
-   6.3.1. The NULL Encryption System (null) ..............   71
-   6.3.2. DES in CBC mode with a CRC-32 checksum (descbc-crc)71
-
-
-
-Kohl & Neuman                                                   [Page 3]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   6.3.3. DES in CBC mode with an MD4 checksum (descbc-md4)  72
-   6.3.4. DES in CBC mode with an MD5 checksum (descbc-md5)  72
-   6.4. Checksums ........................................   74
-   6.4.1. The CRC-32 Checksum (crc32) ....................   74
-   6.4.2. The RSA MD4 Checksum (rsa-md4) .................   75
-   6.4.3. RSA MD4 Cryptographic Checksum Using DES
-   (rsa-md4-des) .........................................   75
-   6.4.4. The RSA MD5 Checksum (rsa-md5) .................   76
-   6.4.5. RSA MD5 Cryptographic Checksum Using DES
-   (rsa-md5-des) .........................................   76
-   6.4.6. DES cipher-block chained checksum (des-mac)
-   6.4.7. RSA MD4 Cryptographic Checksum Using DES
-   alternative (rsa-md4-des-k) ...........................   77
-   6.4.8. DES cipher-block chained checksum alternative
-   (des-mac-k) ...........................................   77
-   7. Naming Constraints .................................   78
-   7.1. Realm Names ......................................   77
-   7.2. Principal Names ..................................   79
-   7.2.1. Name of server principals ......................   80
-   8. Constants and other defined values .................   80
-   8.1. Host address types ...............................   80
-   8.2. KDC messages .....................................   81
-   8.2.1. IP transport ...................................   81
-   8.2.2. OSI transport ..................................   82
-   8.2.3. Name of the TGS ................................   82
-   8.3. Protocol constants and associated values .........   82
-   9. Interoperability requirements ......................   86
-   9.1. Specification 1 ..................................   86
-   9.2. Recommended KDC values ...........................   88
-   10. Acknowledgments ...................................   88
-   11. References ........................................   89
-   12. Security Considerations ...........................   90
-   13. Authors' Addresses ................................   90
-   A. Pseudo-code for protocol processing ................   91
-   A.1. KRB_AS_REQ generation ............................   91
-   A.2. KRB_AS_REQ verification and KRB_AS_REP generation    92
-   A.3. KRB_AS_REP verification ..........................   95
-   A.4. KRB_AS_REP and KRB_TGS_REP common checks .........   96
-   A.5. KRB_TGS_REQ generation ...........................   97
-   A.6. KRB_TGS_REQ verification and KRB_TGS_REP generation  98
-   A.7. KRB_TGS_REP verification .........................  104
-   A.8. Authenticator generation .........................  104
-   A.9. KRB_AP_REQ generation ............................  105
-   A.10. KRB_AP_REQ verification .........................  105
-   A.11. KRB_AP_REP generation ...........................  106
-   A.12. KRB_AP_REP verification .........................  107
-   A.13. KRB_SAFE generation .............................  107
-   A.14. KRB_SAFE verification ...........................  108
-
-
-
-Kohl & Neuman                                                   [Page 4]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   A.15. KRB_SAFE and KRB_PRIV common checks .............  108
-   A.16. KRB_PRIV generation .............................  109
-   A.17. KRB_PRIV verification ...........................  110
-   A.18. KRB_CRED generation .............................  110
-   A.19. KRB_CRED verification ...........................  111
-   A.20. KRB_ERROR generation ............................  112
-
-1.  Introduction
-
-   Kerberos provides a means of verifying the identities of principals,
-   (e.g., a workstation user or a network server) on an open
-   (unprotected) network.  This is accomplished without relying on
-   authentication by the host operating system, without basing trust on
-   host addresses, without requiring physical security of all the hosts
-   on the network, and under the assumption that packets traveling along
-   the network can be read, modified, and inserted at will. (Note,
-   however, that many applications use Kerberos' functions only upon the
-   initiation of a stream-based network connection, and assume the
-   absence of any "hijackers" who might subvert such a connection.  Such
-   use implicitly trusts the host addresses involved.)  Kerberos
-   performs authentication under these conditions as a trusted third-
-   party authentication service by using conventional cryptography,
-   i.e., shared secret key.  (shared secret key - Secret and private are
-   often used interchangeably in the literature.  In our usage, it takes
-   two (or more) to share a secret, thus a shared DES key is a secret
-   key.  Something is only private when no one but its owner knows it.
-   Thus, in public key cryptosystems, one has a public and a private
-   key.)
-
-   The authentication process proceeds as follows: A client sends a
-   request to the authentication server (AS) requesting "credentials"
-   for a given server.  The AS responds with these credentials,
-   encrypted in the client's key.  The credentials consist of 1) a
-   "ticket" for the server and 2) a temporary encryption key (often
-   called a "session key").  The client transmits the ticket (which
-   contains the client's identity and a copy of the session key, all
-   encrypted in the server's key) to the server.  The session key (now
-   shared by the client and server) is used to authenticate the client,
-   and may optionally be used to authenticate the server.  It may also
-   be used to encrypt further communication between the two parties or
-   to exchange a separate sub-session key to be used to encrypt further
-   communication.
-
-   The implementation consists of one or more authentication servers
-   running on physically secure hosts.  The authentication servers
-   maintain a database of principals (i.e., users and servers) and their
-   secret keys. Code libraries provide encryption and implement the
-   Kerberos protocol.  In order to add authentication to its
-
-
-
-Kohl & Neuman                                                   [Page 5]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   transactions, a typical network application adds one or two calls to
-   the Kerberos library, which results in the transmission of the
-   necessary messages to achieve authentication.
-
-   The Kerberos protocol consists of several sub-protocols (or
-   exchanges).  There are two methods by which a client can ask a
-   Kerberos server for credentials.  In the first approach, the client
-   sends a cleartext request for a ticket for the desired server to the
-   AS. The reply is sent encrypted in the client's secret key. Usually
-   this request is for a ticket-granting ticket (TGT) which can later be
-   used with the ticket-granting server (TGS).  In the second method,
-   the client sends a request to the TGS.  The client sends the TGT to
-   the TGS in the same manner as if it were contacting any other
-   application server which requires Kerberos credentials.  The reply is
-   encrypted in the session key from the TGT.
-
-   Once obtained, credentials may be used to verify the identity of the
-   principals in a transaction, to ensure the integrity of messages
-   exchanged between them, or to preserve privacy of the messages.  The
-   application is free to choose whatever protection may be necessary.
-
-   To verify the identities of the principals in a transaction, the
-   client transmits the ticket to the server.  Since the ticket is sent
-   "in the clear" (parts of it are encrypted, but this encryption
-   doesn't thwart replay) and might be intercepted and reused by an
-   attacker, additional information is sent to prove that the message
-   was originated by the principal to whom the ticket was issued.  This
-   information (called the authenticator) is encrypted in the session
-   key, and includes a timestamp.  The timestamp proves that the message
-   was recently generated and is not a replay.  Encrypting the
-   authenticator in the session key proves that it was generated by a
-   party possessing the session key.  Since no one except the requesting
-   principal and the server know the session key (it is never sent over
-   the network in the clear) this guarantees the identity of the client.
-
-   The integrity of the messages exchanged between principals can also
-   be guaranteed using the session key (passed in the ticket and
-   contained in the credentials).  This approach provides detection of
-   both replay attacks and message stream modification attacks.  It is
-   accomplished by generating and transmitting a collision-proof
-   checksum (elsewhere called a hash or digest function) of the client's
-   message, keyed with the session key.  Privacy and integrity of the
-   messages exchanged between principals can be secured by encrypting
-   the data to be passed using the session key passed in the ticket, and
-   contained in the credentials.
-
-   The authentication exchanges mentioned above require read-only access
-   to the Kerberos database.  Sometimes, however, the entries in the
-
-
-
-Kohl & Neuman                                                   [Page 6]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   database must be modified, such as when adding new principals or
-   changing a principal's key.  This is done using a protocol between a
-   client and a third Kerberos server, the Kerberos Administration
-   Server (KADM).  The administration protocol is not described in this
-   document. There is also a protocol for maintaining multiple copies of
-   the Kerberos database, but this can be considered an implementation
-   detail and may vary to support different database technologies.
-
-1.1.  Cross-Realm Operation
-
-   The Kerberos protocol is designed to operate across organizational
-   boundaries.  A client in one organization can be authenticated to a
-   server in another.  Each organization wishing to run a Kerberos
-   server establishes its own "realm".  The name of the realm in which a
-   client is registered is part of the client's name, and can be used by
-   the end-service to decide whether to honor a request.
-
-   By establishing "inter-realm" keys, the administrators of two realms
-   can allow a client authenticated in the local realm to use its
-   authentication remotely (Of course, with appropriate permission the
-   client could arrange registration of a separately-named principal in
-   a remote realm, and engage in normal exchanges with that realm's
-   services. However, for even small numbers of clients this becomes
-   cumbersome, and more automatic methods as described here are
-   necessary).  The exchange of inter-realm keys (a separate key may be
-   used for each direction) registers the ticket-granting service of
-   each realm as a principal in the other realm.  A client is then able
-   to obtain a ticket-granting ticket for the remote realm's ticket-
-   granting service from its local realm. When that ticket-granting
-   ticket is used, the remote ticket-granting service uses the inter-
-   realm key (which usually differs from its own normal TGS key) to
-   decrypt the ticket-granting ticket, and is thus certain that it was
-   issued by the client's own TGS. Tickets issued by the remote ticket-
-   granting service will indicate to the end-service that the client was
-   authenticated from another realm.
-
-   A realm is said to communicate with another realm if the two realms
-   share an inter-realm key, or if the local realm shares an inter-realm
-   key with an intermediate realm that communicates with the remote
-   realm.  An authentication path is the sequence of intermediate realms
-   that are transited in communicating from one realm to another.
-
-   Realms are typically organized hierarchically. Each realm shares a
-   key with its parent and a different key with each child.  If an
-   inter-realm key is not directly shared by two realms, the
-   hierarchical organization allows an authentication path to be easily
-   constructed.  If a hierarchical organization is not used, it may be
-   necessary to consult some database in order to construct an
-
-
-
-Kohl & Neuman                                                   [Page 7]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   authentication path between realms.
-
-   Although realms are typically hierarchical, intermediate realms may
-   be bypassed to achieve cross-realm authentication through alternate
-   authentication paths (these might be established to make
-   communication between two realms more efficient).  It is important
-   for the end-service to know which realms were transited when deciding
-   how much faith to place in the authentication process. To facilitate
-   this decision, a field in each ticket contains the names of the
-   realms that were involved in authenticating the client.
-
-1.2.  Environmental assumptions
-
-   Kerberos imposes a few assumptions on the environment in which it can
-   properly function:
-
-   +    "Denial of service" attacks are not solved with Kerberos.  There
-        are places in these protocols where an intruder intruder can
-        prevent an application from participating in the proper
-        authentication steps.  Detection and solution of such attacks
-        (some of which can appear to be not-uncommon "normal" failure
-        modes for the system) is usually best left to the human
-        administrators and users.
-
-   +    Principals must keep their secret keys secret.  If an intruder
-        somehow steals a principal's key, it will be able to masquerade
-        as that principal or impersonate any server to the legitimate
-        principal.
-
-   +    "Password guessing" attacks are not solved by Kerberos.  If a
-        user chooses a poor password, it is possible for an attacker to
-        successfully mount an offline dictionary attack by repeatedly
-        attempting to decrypt, with successive entries from a
-        dictionary, messages obtained which are encrypted under a key
-        derived from the user's password.
-
-   +    Each host on the network must have a clock which is "loosely
-        synchronized" to the time of the other hosts; this
-        synchronization is used to reduce the bookkeeping needs of
-        application servers when they do replay detection.  The degree
-        of "looseness" can be configured on a per-server basis.  If the
-        clocks are synchronized over the network, the clock
-        synchronization protocol must itself be secured from network
-        attackers.
-
-   +    Principal identifiers are not recycled on a short-term basis.  A
-        typical mode of access control will use access control lists
-        (ACLs) to grant permissions to particular principals.  If a
-
-
-
-Kohl & Neuman                                                   [Page 8]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-        stale ACL entry remains for a deleted principal and the
-        principal identifier is reused, the new principal will inherit
-        rights specified in the stale ACL entry. By not re-using
-        principal identifiers, the danger of inadvertent access is
-        removed.
-
-1.3.  Glossary of terms
-
-   Below is a list of terms used throughout this document.
-
-
-   Authentication      Verifying the claimed identity of a
-                       principal.
-
-
-   Authentication header A record containing a Ticket and an
-                         Authenticator to be presented to a
-                         server as part of the authentication
-                         process.
-
-
-   Authentication path  A sequence of intermediate realms transited
-                        in the authentication process when
-                        communicating from one realm to another.
-
-   Authenticator       A record containing information that can
-                       be shown to have been recently generated
-                       using the session key known only by  the
-                       client and server.
-
-
-   Authorization       The process of determining whether a
-                       client may use a service, which objects
-                       the client is allowed to access, and the
-                       type of access allowed for each.
-
-
-   Capability          A token that grants the bearer permission
-                       to access an object or service.  In
-                       Kerberos, this might be a ticket whose
-                       use is restricted by the contents of the
-                       authorization data field, but which
-                       lists no network addresses, together
-                       with the session key necessary to use
-                       the ticket.
-
-
-
-
-
-
-Kohl & Neuman                                                   [Page 9]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   Ciphertext          The output of an encryption function.
-                       Encryption transforms plaintext into
-                       ciphertext.
-
-
-   Client              A process that makes use of a network
-                       service on behalf of a user.  Note that
-                       in some cases a Server may itself be a
-                       client of some other server (e.g., a
-                       print server may be a client of a file
-                       server).
-
-
-   Credentials         A ticket plus the secret session key
-                       necessary to successfully use that
-                       ticket in an authentication exchange.
-
-
-   KDC                 Key Distribution Center, a network service
-                       that supplies tickets and temporary
-                       session keys; or an instance of that
-                       service or the host on which it runs.
-                       The KDC services both initial ticket and
-                       ticket-granting ticket requests.  The
-                       initial ticket portion is sometimes
-                       referred to as the Authentication Server
-                       (or service).  The ticket-granting
-                       ticket portion is sometimes referred to
-                       as the ticket-granting server (or service).
-
-   Kerberos            Aside from the 3-headed dog guarding
-                       Hades, the name given to Project
-                       Athena's authentication service, the
-                       protocol used by that service, or the
-                       code used to implement the authentication
-                       service.
-
-
-   Plaintext           The input to an encryption function  or
-                       the output of a decryption function.
-                       Decryption transforms ciphertext into
-                       plaintext.
-
-
-   Principal           A uniquely named client or server
-                       instance that participates in a network
-                       communication.
-
-
-
-
-Kohl & Neuman                                                  [Page 10]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   Principal identifier The name used to uniquely identify each
-                        different principal.
-
-
-   Seal                To encipher a record containing several
-                       fields in such a way that the fields
-                       cannot be individually replaced without
-                       either knowledge of the encryption key
-                       or leaving evidence of tampering.
-
-
-   Secret key          An encryption key shared by a principal
-                       and the KDC, distributed outside the
-                       bounds of the system, with a long lifetime.
-                       In the case of a human user's
-                       principal, the secret key is derived
-                       from a password.
-
-
-   Server              A particular Principal which provides a
-                       resource to network clients.
-
-
-   Service             A resource provided to network clients;
-                       often provided by more than one server
-                       (for example, remote file service).
-
-
-   Session key         A temporary encryption key used between
-                       two principals, with a lifetime limited
-                       to the duration of a single login "session".
-
-
-   Sub-session key     A temporary encryption key used between
-                       two principals, selected and exchanged
-                       by the principals using the session key,
-                       and with a lifetime limited to the duration
-                       of a single association.
-
-
-   Ticket              A record that helps a client authenticate
-                       itself to a server; it contains the
-                       client's identity, a session key, a
-                       timestamp, and other information, all
-                       sealed using the server's secret key.
-                       It only serves to authenticate a client
-                       when presented along with a fresh
-                       Authenticator.
-
-
-
-Kohl & Neuman                                                  [Page 11]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-2.  Ticket flag uses and requests
-
-   Each Kerberos ticket contains a set of flags which are used to
-   indicate various attributes of that ticket.  Most flags may be
-   requested by a client when the ticket is obtained; some are
-   automatically turned on and off by a Kerberos server as required.
-   The following sections explain what the various flags mean, and gives
-   examples of reasons to use such a flag.
-
-2.1.  Initial and pre-authenticated tickets
-
-   The INITIAL flag indicates that a ticket was issued using the AS
-   protocol and not issued based on a ticket-granting ticket.
-   Application servers that want to require the knowledge of a client's
-   secret key (e.g., a passwordchanging program) can insist that this
-   flag be set in any tickets they accept, and thus be assured that the
-   client's key was recently presented to the application client.
-
-   The PRE-AUTHENT and HW-AUTHENT flags provide addition information
-   about the initial authentication, regardless of whether the current
-   ticket was issued directly (in which case INITIAL will also be set)
-   or issued on the basis of a ticket-granting ticket (in which case the
-   INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are
-   carried forward from the ticket-granting ticket).
-
-2.2.  Invalid tickets
-
-   The INVALID flag indicates that a ticket is invalid.  Application
-   servers must reject tickets which have this flag set.  A postdated
-   ticket will usually be issued in this form. Invalid tickets must be
-   validated by the KDC before use, by presenting them to the KDC in a
-   TGS request with the VALIDATE option specified.  The KDC will only
-   validate tickets after their starttime has passed.  The validation is
-   required so that postdated tickets which have been stolen before
-   their starttime can be rendered permanently invalid (through a hot-
-   list mechanism).
-
-2.3.  Renewable tickets
-
-   Applications may desire to hold tickets which can be valid for long
-   periods of time.  However, this can expose their credentials to
-   potential theft for equally long periods, and those stolen
-   credentials would be valid until the expiration time of the
-   ticket(s).  Simply using shortlived tickets and obtaining new ones
-   periodically would require the client to have long-term access to its
-   secret key, an even greater risk.  Renewable tickets can be used to
-   mitigate the consequences of theft.  Renewable tickets have two
-   "expiration times": the first is when the current instance of the
-
-
-
-Kohl & Neuman                                                  [Page 12]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   ticket expires, and the second is the latest permissible value for an
-   individual expiration time.  An application client must periodically
-   (i.e., before it expires) present a renewable ticket to the KDC, with
-   the RENEW option set in the KDC request.  The KDC will issue a new
-   ticket with a new session key and a later expiration time.  All other
-   fields of the ticket are left unmodified by the renewal process.
-   When the latest permissible expiration time arrives, the ticket
-   expires permanently.  At each renewal, the KDC may consult a hot-list
-   to determine if the ticket had been reported stolen since its last
-   renewal; it will refuse to renew such stolen tickets, and thus the
-   usable lifetime of stolen tickets is reduced.
-
-   The RENEWABLE flag in a ticket is normally only interpreted by the
-   ticket-granting service (discussed below in section 3.3).  It can
-   usually be ignored by application servers.  However, some
-   particularly careful application servers may wish to disallow
-   renewable tickets.
-
-   If a renewable ticket is not renewed by its  expiration time, the KDC
-   will not renew the ticket.  The RENEWABLE flag is reset by default,
-   but a client may request it be  set  by setting  the RENEWABLE option
-   in the KRB_AS_REQ message.  If it is set, then the renew-till field
-   in the ticket  contains the time after which the ticket may not be
-   renewed.
-
-2.4.  Postdated tickets
-
-   Applications may occasionally need to obtain tickets for use much
-   later, e.g., a batch submission system would need tickets to be valid
-   at the time the batch job is serviced.  However, it is dangerous to
-   hold valid tickets in a batch queue, since they will be on-line
-   longer and more prone to theft.  Postdated tickets provide a way to
-   obtain these tickets from the KDC at job submission time, but to
-   leave them "dormant" until they are activated and validated by a
-   further request of the KDC.  If a ticket theft were reported in the
-   interim, the KDC would refuse to validate the ticket, and the thief
-   would be foiled.
-
-   The MAY-POSTDATE flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can be ignored by application servers.
-   This flag must be set in a ticket-granting ticket in order to issue a
-   postdated ticket based on the presented ticket. It is reset by
-   default; it may be requested by a client by setting the ALLOW-
-   POSTDATE option in the KRB_AS_REQ message.  This flag does not allow
-   a client to obtain a postdated ticket-granting ticket; postdated
-   ticket-granting tickets can only by obtained by requesting the
-   postdating in the KRB_AS_REQ message.  The life (endtime-starttime)
-   of a postdated ticket will be the remaining life of the ticket-
-
-
-
-Kohl & Neuman                                                  [Page 13]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   granting ticket at the time of the request, unless the RENEWABLE
-   option is also set, in which case it can be the full life (endtime-
-   starttime) of the ticket-granting ticket.  The KDC may limit how far
-   in the future a ticket may be postdated.
-
-   The POSTDATED flag indicates that a ticket has been postdated.  The
-   application server can check the authtime field in the ticket to see
-   when the original authentication occurred.  Some services may choose
-   to reject postdated tickets, or they may only accept them within a
-   certain period after the original authentication. When the KDC issues
-   a POSTDATED ticket, it will also be marked as INVALID, so that the
-   application client must present the ticket to the KDC to be validated
-   before use.
-
-2.5.  Proxiable and proxy tickets
-
-   At times it may be necessary for a principal to allow a service  to
-   perform an operation on its behalf.  The service must be able to take
-   on the identity of the client, but only for  a particular purpose.  A
-   principal can allow a service to take on the principal's identity for
-   a particular purpose by granting it a proxy.
-
-   The PROXIABLE flag in a ticket is normally only interpreted by the
-   ticket-granting service. It can be ignored by application servers.
-   When set, this flag tells the ticket-granting server that it is OK to
-   issue a new ticket (but not a ticket-granting ticket) with a
-   different network address based on this ticket.  This flag is set by
-   default.
-
-   This flag allows a client to pass a proxy to a server to perform a
-   remote request on its behalf, e.g., a print service client can give
-   the print server a proxy to access the client's files on a particular
-   file server in order to satisfy a print request.
-
-   In order to complicate the use of stolen credentials, Kerberos
-   tickets are usually valid from only those network addresses
-   specifically included in the ticket (It is permissible to request or
-   issue tickets with no network addresses specified, but we do not
-   recommend it).  For this reason, a client wishing to grant a proxy
-   must request a new ticket valid for the network address of the
-   service to be granted the proxy.
-
-   The PROXY flag is set in a ticket by the  TGS  when  it issues a
-   proxy ticket.  Application servers may check this flag and require
-   additional authentication  from  the  agent presenting the proxy in
-   order to provide an audit trail.
-
-
-
-
-
-Kohl & Neuman                                                  [Page 14]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-2.6.  Forwardable tickets
-
-   Authentication forwarding is an instance of the proxy case where the
-   service is granted complete use of the client's identity.  An example
-   where it might be used is when a user logs in to a remote system and
-   wants authentication to work from that system as if the login were
-   local.
-
-   The FORWARDABLE flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can be ignored by application servers.
-   The FORWARDABLE flag has an interpretation similar to that of the
-   PROXIABLE flag, except ticket-granting tickets may also be issued
-   with different network addresses.  This flag is reset by default, but
-   users may request that it be set by setting the FORWARDABLE option in
-   the AS request when they request their initial ticket-granting
-   ticket.
-
-   This flag allows for authentication forwarding without requiring the
-   user to enter a password again.  If the flag is not set, then
-   authentication forwarding is not permitted, but the same end result
-   can still be achieved if the user engages in the AS exchange with the
-   requested network addresses and supplies a password.
-
-   The FORWARDED flag is set by the TGS when a client presents a ticket
-   with the FORWARDABLE flag set and requests it be set by specifying
-   the FORWARDED KDC option and supplying a set of addresses for the new
-   ticket.  It is also set in all tickets issued based on tickets with
-   the FORWARDED flag set.  Application servers may wish to process
-   FORWARDED tickets differently than non-FORWARDED tickets.
-
-2.7.  Other KDC options
-
-   There are two additional options which may be set in a client's
-   request of the KDC.  The RENEWABLE-OK option indicates that the
-   client will accept a renewable ticket if a ticket with the requested
-   life cannot otherwise be provided.  If a ticket with the requested
-   life cannot be provided, then the KDC may issue a renewable ticket
-   with a renew-till equal to the the requested endtime.  The value of
-   the renew-till field may still be adjusted by site-determined limits
-   or limits imposed by the individual principal or server.
-
-   The ENC-TKT-IN-SKEY option is honored only by the ticket-granting
-   service.  It indicates that the to-be-issued ticket for the end
-   server is to be encrypted in the session key from the additional
-   ticket-granting ticket provided with the request.  See section 3.3.3
-   for specific details.
-
-
-
-
-
-Kohl & Neuman                                                  [Page 15]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-3.  Message Exchanges
-
-   The following sections describe the interactions between network
-   clients and servers and the messages involved in those exchanges.
-
-3.1.  The Authentication Service Exchange
-
-                             Summary
-
-         Message direction       Message type    Section
-         1. Client to Kerberos   KRB_AS_REQ      5.4.1
-         2. Kerberos to client   KRB_AS_REP or   5.4.2
-                                 KRB_ERROR       5.9.1
-
-   The Authentication Service (AS) Exchange between the client and the
-   Kerberos Authentication Server is usually initiated by a client when
-   it wishes to obtain authentication credentials for a given server but
-   currently holds no credentials.  The client's secret key is used for
-   encryption and decryption.  This exchange is typically used at the
-   initiation of a login session, to obtain credentials for a Ticket-
-   Granting Server, which will subsequently be used to obtain
-   credentials for other servers (see section 3.3) without requiring
-   further use of the client's secret key.  This exchange is also used
-   to request credentials for services which must not be mediated
-   through the Ticket-Granting Service, but rather require a principal's
-   secret key, such as the password-changing service.  (The password-
-   changing request must not be honored unless the requester can provide
-   the old password (the user's current secret key).  Otherwise, it
-   would be possible for someone to walk up to an unattended session and
-   change another user's password.)  This exchange does not by itself
-   provide any assurance of the the identity of the user.  (To
-   authenticate a user logging on to a local system, the credentials
-   obtained in the AS exchange may first be used in a TGS exchange to
-   obtain credentials for a local server.  Those credentials must then
-   be verified by the local server through successful completion of the
-   Client/Server exchange.)
-
-   The exchange consists of two messages: KRB_AS_REQ from the client to
-   Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
-   messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
-
-   In the request, the client sends (in cleartext) its own identity and
-   the identity of the server for which it is requesting credentials.
-   The response, KRB_AS_REP, contains a ticket for the client to present
-   to the server, and a session key that will be shared by the client
-   and the server.  The session key and additional information are
-   encrypted in the client's secret key.  The KRB_AS_REP message
-   contains information which can be used to detect replays, and to
-
-
-
-Kohl & Neuman                                                  [Page 16]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   associate it with the message to which it replies.  Various errors
-   can occur; these are indicated by an error response (KRB_ERROR)
-   instead of the KRB_AS_REP response.  The error message is not
-   encrypted.  The KRB_ERROR message also contains information which can
-   be used to associate it with the message to which it replies.  The
-   lack of encryption in the KRB_ERROR message precludes the ability to
-   detect replays or fabrications of such messages.
-
-   In the normal case the authentication server does not know whether
-   the client is actually the principal named in the request.  It simply
-   sends a reply without knowing or caring whether they are the same.
-   This is acceptable because nobody but the principal whose identity
-   was given in the request will be able to use the reply. Its critical
-   information is encrypted in that principal's key.  The initial
-   request supports an optional field that can be used to pass
-   additional information that might be needed for the initial exchange.
-   This field may be used for preauthentication if desired, but the
-   mechanism is not currently specified.
-
-3.1.1. Generation of KRB_AS_REQ message
-
-   The client may specify a number of options in the initial request.
-   Among these options are whether preauthentication is to be performed;
-   whether the requested ticket is to be renewable, proxiable, or
-   forwardable; whether it should be postdated or allow postdating of
-   derivative tickets; and whether a renewable ticket will be accepted
-   in lieu of a non-renewable ticket if the requested ticket expiration
-   date cannot be satisfied by a nonrenewable ticket (due to
-   configuration constraints; see section 4).  See section A.1 for
-   pseudocode.
-
-   The client prepares the KRB_AS_REQ message and sends it to the KDC.
-
-3.1.2. Receipt of KRB_AS_REQ message
-
-   If all goes well, processing the KRB_AS_REQ message will result in
-   the creation of a ticket for the client to present to the server.
-   The format for the ticket is described in section 5.3.1.  The
-   contents of the ticket are determined as follows.
-
-3.1.3. Generation of KRB_AS_REP message
-
-   The authentication server looks up the client and server principals
-   named in the KRB_AS_REQ in its database, extracting their respective
-   keys.  If required, the server pre-authenticates the request, and if
-   the pre-authentication check fails, an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate
-   the requested encryption type, an error message with code
-
-
-
-Kohl & Neuman                                                  [Page 17]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it generates a "random"
-   session key ("Random" means that, among other things, it should be
-   impossible to guess the next session key based on knowledge of past
-   session keys.  This can only be achieved in a pseudo-random number
-   generator if it is based on cryptographic principles.  It would be
-   more desirable to use a truly random number generator, such as one
-   based on measurements of random physical phenomena.).
-
-   If the requested start time is absent or indicates a time in the
-   past, then the start time of the ticket is set to the authentication
-   server's current time. If it indicates a time in the future, but the
-   POSTDATED option has not been specified, then the error
-   KDC_ERR_CANNOT_POSTDATE is returned.  Otherwise the requested start
-   time is checked against the policy of the local realm (the
-   administrator might decide to prohibit certain types or ranges of
-   postdated tickets), and if acceptable, the ticket's start time is set
-   as requested and the INVALID flag is set in the new ticket. The
-   postdated ticket must be validated before use by presenting it to the
-   KDC after the start time has been reached.
-
-   The expiration time of the ticket will be set to the minimum of the
-   following:
-
-   +The expiration time (endtime) requested in the KRB_AS_REQ
-    message.
-
-   +The ticket's start time plus the maximum allowable lifetime
-    associated with the client principal (the authentication
-    server's database includes a maximum ticket lifetime field
-    in each principal's record; see section 4).
-
-   +The ticket's start time plus the maximum allowable lifetime
-    associated with the server principal.
-
-   +The ticket's start time plus the maximum lifetime set by
-    the policy of the local realm.
-
-   If the requested expiration time minus the start time (as determined
-   above) is less than a site-determined minimum lifetime, an error
-   message with code KDC_ERR_NEVER_VALID is returned.  If the requested
-   expiration time for the ticket exceeds what was determined as above,
-   and if the "RENEWABLE-OK" option was requested, then the "RENEWABLE"
-   flag is set in the new ticket, and the renew-till value is set as if
-   the "RENEWABLE" option were requested (the field and option names are
-   described fully in section 5.4.1).  If the RENEWABLE option has been
-   requested or if the RENEWABLE-OK option has been set and a renewable
-   ticket is to be issued, then the renew-till field is set to the
-   minimum of:
-
-
-
-Kohl & Neuman                                                  [Page 18]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   +Its requested value.
-
-   +The start time of the ticket plus the minimum of the two
-    maximum renewable lifetimes associated with the principals'
-    database entries.
-
-   +The start time of the ticket plus the maximum renewable
-    lifetime set by the policy of the local realm.
-
-   The flags field of the new ticket will have the following options set
-   if they have been requested and if the policy of the local realm
-   allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
-   If the new ticket is postdated (the start time is in the future), its
-   INVALID flag will also be set.
-
-   If all of the above succeed, the server formats a KRB_AS_REP message
-   (see section 5.4.2), copying the addresses in the request into the
-   caddr of the response, placing any required pre-authentication data
-   into the padata of the response, and encrypts the ciphertext part in
-   the client's key using the requested encryption method, and sends it
-   to the client.  See section A.2 for pseudocode.
-
-3.1.4. Generation of KRB_ERROR message
-
-   Several errors can occur, and the Authentication Server responds by
-   returning an error message, KRB_ERROR, to the client, with the
-   error-code and e-text fields set to appropriate values.  The error
-   message contents and details are described in Section 5.9.1.
-
-3.1.5. Receipt of KRB_AS_REP message
-
-   If the reply message type is KRB_AS_REP, then the client verifies
-   that the cname and crealm fields in the cleartext portion of the
-   reply match what it requested.  If any padata fields are present,
-   they may be used to derive the proper secret key to decrypt the
-   message.  The client decrypts the encrypted part of the response
-   using its secret key, verifies that the nonce in the encrypted part
-   matches the nonce it supplied in its request (to detect replays).  It
-   also verifies that the sname and srealm in the response match those
-   in the request, and that the host address field is also correct.  It
-   then stores the ticket, session key, start and expiration times, and
-   other information for later use.  The key-expiration field from the
-   encrypted part of the response may be checked to notify the user of
-   impending key expiration (the client program could then suggest
-   remedial action, such as a password change).  See section A.3 for
-   pseudocode.
-
-   Proper decryption of the KRB_AS_REP message is not sufficient to
-
-
-
-Kohl & Neuman                                                  [Page 19]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   verify the identity of the user; the user and an attacker could
-   cooperate to generate a KRB_AS_REP format message which decrypts
-   properly but is not from the proper KDC.  If the host wishes to
-   verify the identity of the user, it must require the user to present
-   application credentials which can be verified using a securely-stored
-   secret key.  If those credentials can be verified, then the identity
-   of the user can be assured.
-
-3.1.6. Receipt of KRB_ERROR message
-
-   If the reply message type is KRB_ERROR, then the client interprets it
-   as an error and performs whatever application-specific tasks are
-   necessary to recover.
-
-3.2.  The Client/Server Authentication Exchange
-
-                        Summary
-
-   Message direction                         Message type    Section
-   Client to Application server              KRB_AP_REQ      5.5.1
-   [optional] Application server to client   KRB_AP_REP or   5.5.2
-                                             KRB_ERROR       5.9.1
-
-   The client/server authentication (CS) exchange is used by network
-   applications to authenticate the client to the server and vice versa.
-   The client must have already acquired credentials for the server
-   using the AS or TGS exchange.
-
-3.2.1. The KRB_AP_REQ message
-
-   The KRB_AP_REQ contains authentication information which should be
-   part of the first message in an authenticated transaction.  It
-   contains a ticket, an authenticator, and some additional bookkeeping
-   information (see section 5.5.1 for the exact format).  The ticket by
-   itself is insufficient to authenticate a client, since tickets are
-   passed across the network in cleartext(Tickets contain both an
-   encrypted and unencrypted portion, so cleartext here refers to the
-   entire unit, which can be copied from one message and replayed in
-   another without any cryptographic skill.), so the authenticator is
-   used to prevent invalid replay of tickets by proving to the server
-   that the client knows the session key of the ticket and thus is
-   entitled to use it.  The KRB_AP_REQ message is referred to elsewhere
-   as the "authentication header."
-
-3.2.2. Generation of a KRB_AP_REQ message
-
-   When a client wishes to initiate authentication to a server, it
-   obtains (either through a credentials cache, the AS exchange, or the
-
-
-
-Kohl & Neuman                                                  [Page 20]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   TGS exchange) a ticket and session key for the desired service.  The
-   client may re-use any tickets it holds until they expire.  The client
-   then constructs a new Authenticator from the the system time, its
-   name, and optionally an application specific checksum, an initial
-   sequence number to be used in KRB_SAFE or KRB_PRIV messages, and/or a
-   session subkey to be used in negotiations for a session key unique to
-   this particular session.  Authenticators may not be re-used and will
-   be rejected if replayed to a server (Note that this can make
-   applications based on unreliable transports difficult to code
-   correctly, if the transport might deliver duplicated messages.  In
-   such cases, a new authenticator must be generated for each retry.).
-   If a sequence number is to be included, it should be randomly chosen
-   so that even after many messages have been exchanged it is not likely
-   to collide with other sequence numbers in use.
-
-   The client may indicate a requirement of mutual authentication or the
-   use of a session-key based ticket by setting the appropriate flag(s)
-   in the ap-options field of the message.
-
-   The Authenticator is encrypted in the session key and combined with
-   the ticket to form the KRB_AP_REQ message which is then sent to the
-   end server along with any additional application-specific
-   information.  See section A.9 for pseudocode.
-
-3.2.3. Receipt of KRB_AP_REQ message
-
-   Authentication is based on the server's current time of day (clocks
-   must be loosely synchronized), the authenticator, and the ticket.
-   Several errors are possible.  If an error occurs, the server is
-   expected to reply to the client with a KRB_ERROR message.  This
-   message may be encapsulated in the application protocol if its "raw"
-   form is not acceptable to the protocol. The format of error messages
-   is described in section 5.9.1.
-
-   The algorithm for verifying authentication information is as follows.
-   If the message type is not KRB_AP_REQ, the server returns the
-   KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket
-   in the KRB_AP_REQ is not one the server can use (e.g., it indicates
-   an old key, and the server no longer possesses a copy of the old
-   key), the KRB_AP_ERR_BADKEYVER error is returned.  If the USE-
-   SESSION-KEY flag is set in the ap-options field, it indicates to the
-   server that the ticket is encrypted in the session key from the
-   server's ticket-granting ticket rather than its secret key (This is
-   used for user-to-user authentication as described in [6]).  Since it
-   is possible for the server to be registered in multiple realms, with
-   different keys in each, the srealm field in the unencrypted portion
-   of the ticket in the KRB_AP_REQ is used to specify which secret key
-   the server should use to decrypt that ticket.  The KRB_AP_ERR_NOKEY
-
-
-
-Kohl & Neuman                                                  [Page 21]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   error code is returned if the server doesn't have the proper key to
-   decipher the ticket.
-
-   The ticket is decrypted using the version of the server's key
-   specified by the ticket.  If the decryption routines detect a
-   modification of the ticket (each encryption system must provide
-   safeguards to detect modified ciphertext; see section 6), the
-   KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that
-   different keys were used to encrypt and decrypt).
-
-   The authenticator is decrypted using the session key extracted from
-   the decrypted ticket.  If decryption shows it to have been modified,
-   the KRB_AP_ERR_BAD_INTEGRITY error is returned.  The name and realm
-   of the client from the ticket are compared against the same fields in
-   the authenticator.  If they don't match, the KRB_AP_ERR_BADMATCH
-   error is returned (they might not match, for example, if the wrong
-   session key was used to encrypt the authenticator).  The addresses in
-   the ticket (if any) are then searched for an address matching the
-   operating-system reported address of the client.  If no match is
-   found or the server insists on ticket addresses but none are present
-   in the ticket, the KRB_AP_ERR_BADADDR error is returned.
-
-   If the local (server) time and the client time in the authenticator
-   differ by more than the allowable clock skew (e.g., 5 minutes), the
-   KRB_AP_ERR_SKEW error is returned.  If the server name, along with
-   the client name, time and microsecond fields from the Authenticator
-   match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is
-   returned (Note that the rejection here is restricted to
-   authenticators from the same principal to the same server.  Other
-   client principals communicating with the same server principal should
-   not be have their authenticators rejected if the time and microsecond
-   fields happen to match some other client's authenticator.).  The
-   server must remember any authenticator presented within the allowable
-   clock skew, so that a replay attempt is guaranteed to fail. If a
-   server loses track of any authenticator presented within the
-   allowable clock skew, it must reject all requests until the clock
-   skew interval has passed.  This assures that any lost or re-played
-   authenticators will fall outside the allowable clock skew and can no
-   longer be successfully replayed (If this is not done, an attacker
-   could conceivably record the ticket and authenticator sent over the
-   network to a server, then disable the client's host, pose as the
-   disabled host, and replay the ticket and authenticator to subvert the
-   authentication.).  If a sequence number is provided in the
-   authenticator, the server saves it for later use in processing
-   KRB_SAFE and/or KRB_PRIV messages.  If a subkey is present, the
-   server either saves it for later use or uses it to help generate its
-   own choice for a subkey to be returned in a KRB_AP_REP message.
-
-
-
-
-Kohl & Neuman                                                  [Page 22]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   The server computes the age of the ticket: local (server) time minus
-   the start time inside the Ticket.  If the start time is later than
-   the current time by more than the allowable clock skew or if the
-   INVALID flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is
-   returned.  Otherwise, if the current time is later than end time by
-   more than the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error
-   is returned.
-
-   If all these checks succeed without an error, the server is assured
-   that the client possesses the credentials of the principal named in
-   the ticket and thus, the client has been authenticated to the server.
-   See section A.10 for pseudocode.
-
-3.2.4. Generation of a KRB_AP_REP message
-
-   Typically, a client's request will include both the authentication
-   information and its initial request in the same message, and the
-   server need not explicitly reply to the KRB_AP_REQ.  However, if
-   mutual authentication (not only authenticating the client to the
-   server, but also the server to the client) is being performed, the
-   KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options
-   field, and a KRB_AP_REP message is required in response.  As with the
-   error message, this message may be encapsulated in the application
-   protocol if its "raw" form is not acceptable to the application's
-   protocol.  The timestamp and microsecond field used in the reply must
-   be the client's timestamp and microsecond field (as provided in the
-   authenticator). [Note: In the Kerberos version 4 protocol, the
-   timestamp in the reply was the client's timestamp plus one.  This is
-   not necessary in version 5 because version 5 messages are formatted
-   in such a way that it is not possible to create the reply by
-   judicious message surgery (even in encrypted form) without knowledge
-   of the appropriate encryption keys.]  If a sequence number is to be
-   included, it should be randomly chosen as described above for the
-   authenticator.  A subkey may be included if the server desires to
-   negotiate a different subkey.  The KRB_AP_REP message is encrypted in
-   the session key extracted from the ticket.  See section A.11 for
-   pseudocode.
-
-3.2.5. Receipt of KRB_AP_REP message
-
-   If a KRB_AP_REP message is returned, the client uses the session key
-   from the credentials obtained for the server (Note that for
-   encrypting the KRB_AP_REP message, the sub-session key is not used,
-   even if present in the Authenticator.) to decrypt the message, and
-   verifies that the timestamp and microsecond fields match those in the
-   Authenticator it sent to the server.  If they match, then the client
-   is assured that the server is genuine. The sequence number and subkey
-   (if present) are retained for later use.  See section A.12 for
-
-
-
-Kohl & Neuman                                                  [Page 23]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   pseudocode.
-
-3.2.6. Using the encryption key
-
-   After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
-   server share an encryption key which can be used by the application.
-   The "true session key" to be used for KRB_PRIV, KRB_SAFE, or other
-   application-specific uses may be chosen by the application based on
-   the subkeys in the KRB_AP_REP message and the authenticator
-   (Implementations of the protocol may wish to provide routines to
-   choose subkeys based on session keys and random numbers and to
-   orchestrate a negotiated key to be returned in the KRB_AP_REP
-   message.).  In some cases, the use of this session key will be
-   implicit in the protocol; in others the method of use must be chosen
-   from a several alternatives.  We leave the protocol negotiations of
-   how to use the key (e.g., selecting an encryption or checksum type)
-   to the application programmer; the Kerberos protocol does not
-   constrain the implementation options.
-
-   With both the one-way and mutual authentication exchanges, the peers
-   should take care not to send sensitive information to each other
-   without proper assurances.  In particular, applications that require
-   privacy or integrity should use the KRB_AP_REP or KRB_ERROR responses
-   from the server to client to assure both client and server of their
-   peer's identity.  If an application protocol requires privacy of its
-   messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE
-   message (section 3.4) can be used to assure integrity.
-
-3.3.  The Ticket-Granting Service (TGS) Exchange
-
-                             Summary
-
-         Message direction       Message type     Section
-         1. Client to Kerberos   KRB_TGS_REQ      5.4.1
-         2. Kerberos to client   KRB_TGS_REP or   5.4.2
-                                 KRB_ERROR        5.9.1
-
-   The TGS exchange between a client and the Kerberos Ticket-Granting
-   Server is initiated by a client when it wishes to obtain
-   authentication credentials for a given server (which might be
-   registered in a remote realm), when it wishes to renew or validate an
-   existing ticket, or when it wishes to obtain a proxy ticket.  In the
-   first case, the client must already have acquired a ticket for the
-   Ticket-Granting Service using the AS exchange (the ticket-granting
-   ticket is usually obtained when a client initially authenticates to
-   the system, such as when a user logs in).  The message format for the
-   TGS exchange is almost identical to that for the AS exchange.  The
-   primary difference is that encryption and decryption in the TGS
-
-
-
-Kohl & Neuman                                                  [Page 24]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   exchange does not take place under the client's key.  Instead, the
-   session key from the ticket-granting ticket or renewable ticket, or
-   sub-session key from an Authenticator is used.  As is the case for
-   all application servers, expired tickets are not accepted by the TGS,
-   so once a renewable or ticket-granting ticket expires, the client
-   must use a separate exchange to obtain valid tickets.
-
-   The TGS exchange consists of two messages: A request (KRB_TGS_REQ)
-   from the client to the Kerberos Ticket-Granting Server, and a reply
-   (KRB_TGS_REP or KRB_ERROR).  The KRB_TGS_REQ message includes
-   information authenticating the client plus a request for credentials.
-   The authentication information consists of the authentication header
-   (KRB_AP_REQ) which includes the client's previously obtained ticket-
-   granting, renewable, or invalid ticket.  In the ticket-granting
-   ticket and proxy cases, the request may include one or more of: a
-   list of network addresses, a collection of typed authorization data
-   to be sealed in the ticket for authorization use by the application
-   server, or additional tickets (the use of which are described later).
-   The TGS reply (KRB_TGS_REP) contains the requested credentials,
-   encrypted in the session key from the ticket-granting ticket or
-   renewable ticket, or if present, in the subsession key from the
-   Authenticator (part of the authentication header). The KRB_ERROR
-   message contains an error code and text explaining what went wrong.
-   The KRB_ERROR message is not encrypted.  The KRB_TGS_REP message
-   contains information which can be used to detect replays, and to
-   associate it with the message to which it replies.  The KRB_ERROR
-   message also contains information which can be used to associate it
-   with the message to which it replies, but the lack of encryption in
-   the KRB_ERROR message precludes the ability to detect replays or
-   fabrications of such messages.
-
-3.3.1. Generation of KRB_TGS_REQ message
-
-   Before sending a request to the ticket-granting service, the client
-   must determine in which realm the application server is registered
-   [Note: This can be accomplished in several ways.  It might be known
-   beforehand (since the realm is part of the principal identifier), or
-   it might be stored in a nameserver.  Presently, however, this
-   information is obtained from a configuration file.  If the realm to
-   be used is obtained from a nameserver, there is a danger of being
-   spoofed if the nameservice providing the realm name is not
-   authenticated.  This might result in the use of a realm which has
-   been compromised, and would result in an attacker's ability to
-   compromise the authentication of the application server to the
-   client.].  If the client does not already possess a ticket-granting
-   ticket for the appropriate realm, then one must be obtained.  This is
-   first attempted by requesting a ticket-granting ticket for the
-   destination realm from the local Kerberos server (using the
-
-
-
-Kohl & Neuman                                                  [Page 25]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   KRB_TGS_REQ message recursively).  The Kerberos server may return a
-   TGT for the desired realm in which case one can proceed.
-   Alternatively, the Kerberos server may return a TGT for a realm which
-   is "closer" to the desired realm (further along the standard
-   hierarchical path), in which case this step must be repeated with a
-   Kerberos server in the realm specified in the returned TGT.  If
-   neither are returned, then the request must be retried with a
-   Kerberos server for a realm higher in the hierarchy.  This request
-   will itself require a ticket-granting ticket for the higher realm
-   which must be obtained by recursively applying these directions.
-
-   Once the client obtains a ticket-granting ticket for the appropriate
-   realm, it determines which Kerberos servers serve that realm, and
-   contacts one. The list might be obtained through a configuration file
-   or network service; as long as the secret keys exchanged by realms
-   are kept secret, only denial of service results from a false Kerberos
-   server.
-
-   As in the AS exchange, the client may specify a number of options in
-   the KRB_TGS_REQ message.  The client prepares the KRB_TGS_REQ
-   message, providing an authentication header as an element of the
-   padata field, and including the same fields as used in the KRB_AS_REQ
-   message along with several optional fields: the enc-authorization-
-   data field for application server use and additional tickets required
-   by some options.
-
-   In preparing the authentication header, the client can select a sub-
-   session key under which the response from the Kerberos server will be
-   encrypted (If the client selects a sub-session key, care must be
-   taken to ensure the randomness of the selected subsession key.  One
-   approach would be to generate a random number and XOR it with the
-   session key from the ticket-granting ticket.). If the sub-session key
-   is not specified, the session key from the ticket-granting ticket
-   will be used.  If the enc-authorization-data is present, it must be
-   encrypted in the sub-session key, if present, from the authenticator
-   portion of the authentication header, or if not present in the
-   session key from the ticket-granting ticket.
-
-   Once prepared, the message is sent to a Kerberos server for the
-   destination realm.  See section A.5 for pseudocode.
-
-3.3.2. Receipt of KRB_TGS_REQ message
-
-   The KRB_TGS_REQ message is processed in a manner similar to the
-   KRB_AS_REQ message, but there are many additional checks to be
-   performed.  First, the Kerberos server must determine which server
-   the accompanying ticket is for and it must select the appropriate key
-   to decrypt it. For a normal KRB_TGS_REQ message, it will be for the
-
-
-
-Kohl & Neuman                                                  [Page 26]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   ticket granting service, and the TGS's key will be used.  If the TGT
-   was issued by another realm, then the appropriate inter-realm key
-   must be used.  If the accompanying ticket is not a ticket granting
-   ticket for the current realm, but is for an application server in the
-   current realm, the RENEW, VALIDATE, or PROXY options are specified in
-   the request, and the server for which a ticket is requested is the
-   server named in the accompanying ticket, then the KDC will decrypt
-   the ticket in the authentication header using the key of the server
-   for which it was issued.  If no ticket can be found in the padata
-   field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
-
-   Once the accompanying ticket has been decrypted, the user-supplied
-   checksum in the Authenticator must be verified against the contents
-   of the request, and the message rejected if the checksums do not
-   match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum
-   is not keyed or not collision-proof (with an error code of
-   KRB_AP_ERR_INAPP_CKSUM).  If the checksum type is not supported, the
-   KDC_ERR_SUMTYPE_NOSUPP error is returned.  If the authorization-data
-   are present, they are decrypted using the sub-session key from the
-   Authenticator.
-
-   If any of the decryptions indicate failed integrity checks, the
-   KRB_AP_ERR_BAD_INTEGRITY error is returned.
-
-3.3.3. Generation of KRB_TGS_REP message
-
-   The KRB_TGS_REP message shares its format with the KRB_AS_REP
-   (KRB_KDC_REP), but with its type field set to KRB_TGS_REP.  The
-   detailed specification is in section 5.4.2.
-
-   The response will include a ticket for the requested server.  The
-   Kerberos database is queried to retrieve the record for the requested
-   server (including the key with which the ticket will be encrypted).
-   If the request is for a ticket granting ticket for a remote realm,
-   and if no key is shared with the requested realm, then the Kerberos
-   server will select the realm "closest" to the requested realm with
-   which it does share a key, and use that realm instead. This is the
-   only case where the response from the KDC will be for a different
-   server than that requested by the client.
-
-   By default, the address field, the client's name and realm, the list
-   of transited realms, the time of initial authentication, the
-   expiration time, and the authorization data of the newly-issued
-   ticket will be copied from the ticket-granting ticket (TGT) or
-   renewable ticket.  If the transited field needs to be updated, but
-   the transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error
-   is returned.
-
-
-
-
-Kohl & Neuman                                                  [Page 27]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   If the request specifies an endtime, then the endtime of the new
-   ticket is set to the minimum of (a) that request, (b) the endtime
-   from the TGT, and (c) the starttime of the TGT plus the minimum of
-   the maximum life for the application server and the maximum life for
-   the local realm (the maximum life for the requesting principal was
-   already applied when the TGT was issued).  If the new ticket is to be
-   a renewal, then the endtime above is replaced by the minimum of (a)
-   the value of the renew_till field of the ticket and (b) the starttime
-   for the new ticket plus the life (endtimestarttime) of the old
-   ticket.
-
-   If the FORWARDED option has been requested, then the resulting ticket
-   will contain the addresses specified by the client.  This option will
-   only be honored if the FORWARDABLE flag is set in the TGT.  The PROXY
-   option is similar; the resulting ticket will contain the addresses
-   specified by the client.  It will be honored only if the PROXIABLE
-   flag in the TGT is set.  The PROXY option will not be honored on
-   requests for additional ticket-granting tickets.
-
-   If the requested start time is absent or indicates a time in the
-   past, then the start time of the ticket is set to the authentication
-   server's current time.  If it indicates a time in the future, but the
-   POSTDATED option has not been specified or the MAY-POSTDATE flag is
-   not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is
-   returned.  Otherwise, if the ticket-granting ticket has the
-   MAYPOSTDATE flag set, then the resulting ticket will be postdated and
-   the requested starttime is checked against the policy of the local
-   realm. If acceptable, the ticket's start time is set as requested,
-   and the INVALID flag is set.  The postdated ticket must be validated
-   before use by presenting it to the KDC after the starttime has been
-   reached. However, in no case may the starttime, endtime, or renew-
-   till time of a newly-issued postdated ticket extend beyond the
-   renew-till time of the ticket-granting ticket.
-
-   If the ENC-TKT-IN-SKEY option has been specified and an additional
-   ticket has been included in the request, the KDC will decrypt the
-   additional ticket using the key for the server to which the
-   additional ticket was issued and verify that it is a ticket-granting
-   ticket.  If the name of the requested server is missing from the
-   request, the name of the client in the additional ticket will be
-   used.  Otherwise the name of the requested server will be compared to
-   the name of the client in the additional ticket and if different, the
-   request will be rejected.  If the request succeeds, the session key
-   from the additional ticket will be used to encrypt the new ticket
-   that is issued instead of using the key of the server for which the
-   new ticket will be used (This allows easy implementation of user-to-
-   user authentication [6], which uses ticket-granting ticket session
-   keys in lieu of secret server keys in situations where such secret
-
-
-
-Kohl & Neuman                                                  [Page 28]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   keys could be easily compromised.).
-
-   If the name of the server in the ticket that is presented to the KDC
-   as part of the authentication header is not that of the ticket-
-   granting server itself, and the server is registered in the realm of
-   the KDC, If the RENEW option is requested, then the KDC will verify
-   that the RENEWABLE flag is set in the ticket and that the renew_till
-   time is still in the future.  If the VALIDATE option is rqeuested,
-   the KDC will check that the starttime has passed and the INVALID flag
-   is set.  If the PROXY option is requested, then the KDC will check
-   that the PROXIABLE flag is set in the ticket.  If the tests succeed,
-   the KDC will issue the appropriate new ticket.
-
-   Whenever a request is made to the ticket-granting server, the
-   presented ticket(s) is(are) checked against a hot-list of tickets
-   which have been canceled.  This hot-list might be implemented by
-   storing a range of issue dates for "suspect tickets"; if a presented
-   ticket had an authtime in that range, it would be rejected.  In this
-   way, a stolen ticket-granting ticket or renewable ticket cannot be
-   used to gain additional tickets (renewals or otherwise) once the
-   theft has been reported.  Any normal ticket obtained before it was
-   reported stolen will still be valid (because they require no
-   interaction with the KDC), but only until their normal expiration
-   time.
-
-   The ciphertext part of the response in the KRB_TGS_REP message is
-   encrypted in the sub-session key from the Authenticator, if present,
-   or the session key key from the ticket-granting ticket.  It is not
-   encrypted using the client's secret key.  Furthermore, the client's
-   key's expiration date and the key version number fields are left out
-   since these values are stored along with the client's database
-   record, and that record is not needed to satisfy a request based on a
-   ticket-granting ticket.  See section A.6 for pseudocode.
-
-3.3.3.1.  Encoding the transited field
-
-   If the identity of the server in the TGT that is presented to the KDC
-   as part of the authentication header is that of the ticket-granting
-   service, but the TGT was issued from another realm, the KDC will look
-   up the inter-realm key shared with that realm and use that key to
-   decrypt the ticket.  If the ticket is valid, then the KDC will honor
-   the request, subject to the constraints outlined above in the section
-   describing the AS exchange.  The realm part of the client's identity
-   will be taken from the ticket-granting ticket.  The name of the realm
-   that issued the ticket-granting ticket will be added to the transited
-   field of the ticket to be issued.  This is accomplished by reading
-   the transited field from the ticket-granting ticket (which is treated
-   as an unordered set of realm names), adding the new realm to the set,
-
-
-
-Kohl & Neuman                                                  [Page 29]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   then constructing and writing out its encoded (shorthand) form (this
-   may involve a rearrangement of the existing encoding).
-
-   Note that the ticket-granting service does not add the name of its
-   own realm.  Instead, its responsibility is to add the name of the
-   previous realm.  This prevents a malicious Kerberos server from
-   intentionally leaving out its own name (it could, however, omit other
-   realms' names).
-
-   The names of neither the local realm nor the principal's realm are to
-   be included in the transited field.  They appear elsewhere in the
-   ticket and both are known to have taken part in authenticating the
-   principal.  Since the endpoints are not included, both local and
-   single-hop inter-realm authentication result in a transited field
-   that is empty.
-
-   Because the name of each realm transited  is  added  to this field,
-   it might potentially be very long.  To decrease the length of this
-   field, its contents are encoded.  The initially supported encoding is
-   optimized for the normal case of inter-realm communication: a
-   hierarchical arrangement of realms using either domain or X.500 style
-   realm names. This encoding (called DOMAIN-X500-COMPRESS) is now
-   described.
-
-   Realm names in the transited field are separated by a ",".  The ",",
-   "\", trailing "."s, and leading spaces (" ") are special characters,
-   and if they are part of a realm name, they must be quoted in the
-   transited field by preceding them with a "\".
-
-   A realm name ending with a "." is interpreted as  being prepended to
-   the previous realm.  For example, we can encode traversal of EDU,
-   MIT.EDU,  ATHENA.MIT.EDU,  WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
-
-              "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
-
-   Note that if ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were endpoints,
-   that they would not be included in this field, and we would have:
-
-              "EDU,MIT.,WASHINGTON.EDU"
-
-   A realm name beginning with a "/" is interpreted as being appended to
-   the previous realm (For the purpose of appending, the realm preceding
-   the first listed realm is considered to be the null realm ("")).  If
-   it is to stand by itself, then it should be preceded by a space ("
-   ").  For example, we can encode traversal of /COM/HP/APOLLO, /COM/HP,
-   /COM, and /COM/DEC as:
-
-              "/COM,/HP,/APOLLO, /COM/DEC".
-
-
-
-Kohl & Neuman                                                  [Page 30]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   Like the example above, if /COM/HP/APOLLO and /COM/DEC are endpoints,
-   they they would not be included in this field, and we would have:
-
-              "/COM,/HP"
-
-   A null subfield preceding or following a "," indicates that all
-   realms between the previous realm and the next realm have been
-   traversed (For the purpose of interpreting null subfields, the
-   client's realm is considered to precede those in the transited field,
-   and the server's realm is considered to follow them.). Thus, ","
-   means that all realms along the path between the client and the
-   server have been traversed.  ",EDU, /COM," means that that all realms
-   from the client's realm up to EDU (in a domain style hierarchy) have
-   been traversed, and that everything from /COM down to the server's
-   realm in an X.500 style has also been traversed.  This could occur if
-   the EDU realm in one hierarchy shares an inter-realm key directly
-   with the /COM realm in another hierarchy.
-
-3.3.4. Receipt of KRB_TGS_REP message
-
-   When the KRB_TGS_REP is received by the client, it is processed in
-   the same manner as the KRB_AS_REP processing described above.  The
-   primary difference is that the ciphertext part of the response must
-   be decrypted using the session key from the ticket-granting ticket
-   rather than the client's secret key.  See section A.7 for pseudocode.
-
-3.4.  The KRB_SAFE Exchange
-
-   The KRB_SAFE message may be used by clients requiring the ability to
-   detect modifications of messages they exchange.  It achieves this by
-   including a keyed collisionproof checksum of the user data and some
-   control information.  The checksum is keyed with an encryption key
-   (usually the last key negotiated via subkeys, or the session key if
-   no negotiation has occured).
-
-3.4.1. Generation of a KRB_SAFE message
-
-   When an application wishes to send a KRB_SAFE message, it collects
-   its data and the appropriate control information and computes a
-   checksum over them.  The checksum algorithm should be some sort of
-   keyed one-way hash function (such as the RSA-MD5-DES checksum
-   algorithm specified in section 6.4.5, or the DES MAC), generated
-   using the sub-session key if present, or the session key.  Different
-   algorithms may be selected by changing the checksum type in the
-   message.  Unkeyed or non-collision-proof checksums are not suitable
-   for this use.
-
-   The control information for the KRB_SAFE message includes both a
-
-
-
-Kohl & Neuman                                                  [Page 31]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   timestamp and a sequence number.  The designer of an application
-   using the KRB_SAFE message must choose at least one of the two
-   mechanisms.  This choice should be based on the needs of the
-   application protocol.
-
-   Sequence numbers are useful when all messages sent will be received
-   by one's peer.  Connection state is presently required to maintain
-   the session key, so maintaining the next sequence number should not
-   present an additional problem.
-
-   If the application protocol is expected to tolerate lost messages
-   without them being resent, the use of the timestamp is the
-   appropriate replay detection mechanism.  Using timestamps is also the
-   appropriate mechanism for multi-cast protocols where all of one's
-   peers share a common sub-session key, but some messages will be sent
-   to a subset of one's peers.
-
-   After computing the checksum, the client then transmits the
-   information and checksum to the recipient in the message format
-   specified in section 5.6.1.
-
-3.4.2. Receipt of KRB_SAFE message
-
-   When an application receives a KRB_SAFE message, it verifies it as
-   follows.  If any error occurs, an error code is reported for use by
-   the application.
-
-   The message is first checked by verifying that the protocol version
-   and type fields match the current version and KRB_SAFE, respectively.
-   A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
-   error.  The application verifies that the checksum used is a
-   collisionproof keyed checksum, and if it is not, a
-   KRB_AP_ERR_INAPP_CKSUM error is generated.  The recipient verifies
-   that the operating system's report of the sender's address matches
-   the sender's address in the message, and (if a recipient address is
-   specified or the recipient requires an address) that one of the
-   recipient's addresses appears as the recipient's address in the
-   message.  A failed match for either case generates a
-   KRB_AP_ERR_BADADDR error.  Then the timestamp and usec and/or the
-   sequence number fields are checked.  If timestamp and usec are
-   expected and not present, or they are present but not current, the
-   KRB_AP_ERR_SKEW error is generated.  If the server name, along with
-   the client name, time and microsecond fields from the Authenticator
-   match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is
-   generated.  If an incorrect sequence number is included, or a
-   sequence number is expected but not present, the KRB_AP_ERR_BADORDER
-   error is generated.  If neither a timestamp and usec or a sequence
-   number is present, a KRB_AP_ERR_MODIFIED error is generated.
-
-
-
-Kohl & Neuman                                                  [Page 32]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   Finally, the checksum is computed over the data and control
-   information, and if it doesn't match the received checksum, a
-   KRB_AP_ERR_MODIFIED error is generated.
-
-   If all the checks succeed, the application is assured that the
-   message was generated by its peer and was not modified in transit.
-
-3.5.  The KRB_PRIV Exchange
-
-   The KRB_PRIV message may be used by clients requiring confidentiality
-   and the ability to detect modifications of exchanged messages.  It
-   achieves this by encrypting the messages and adding control
-   information.
-
-3.5.1. Generation of a KRB_PRIV message
-
-   When an application wishes to send a KRB_PRIV message, it collects
-   its data and the appropriate control information (specified in
-   section 5.7.1) and encrypts them under an encryption key (usually the
-   last key negotiated via subkeys, or the session key if no negotiation
-   has occured).  As part of the control information, the client must
-   choose to use either a timestamp or a sequence number (or both); see
-   the discussion in section 3.4.1 for guidelines on which to use.
-   After the user data and control information are encrypted, the client
-   transmits the ciphertext and some "envelope" information to the
-   recipient.
-
-3.5.2. Receipt of KRB_PRIV message
-
-   When an application receives a KRB_PRIV message, it verifies it as
-   follows.  If any error occurs, an error code is reported for use by
-   the application.
-
-   The message is first checked by verifying that the protocol version
-   and type fields match the current version and KRB_PRIV, respectively.
-   A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
-   error.  The application then decrypts the ciphertext and processes
-   the resultant plaintext. If decryption shows the data to have been
-   modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated.  The
-   recipient verifies that the operating system's report of the sender's
-   address matches the sender's address in the message, and (if a
-   recipient address is specified or the recipient requires an address)
-   that one of the recipient's addresses appears as the recipient's
-   address in the message.  A failed match for either case generates a
-   KRB_AP_ERR_BADADDR error.  Then the timestamp and usec and/or the
-   sequence number fields are checked. If timestamp and usec are
-   expected and not present, or they are present but not current, the
-   KRB_AP_ERR_SKEW error is generated.  If the server name, along with
-
-
-
-Kohl & Neuman                                                  [Page 33]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   the client name, time and microsecond fields from the Authenticator
-   match any recently-seen such tuples, the KRB_AP_ERR_REPEAT error is
-   generated.  If an incorrect sequence number is included, or a
-   sequence number is expected but not present, the KRB_AP_ERR_BADORDER
-   error is generated.  If neither a timestamp and usec or a sequence
-   number is present, a KRB_AP_ERR_MODIFIED error is generated.
-
-   If all the checks succeed, the application can assume the message was
-   generated by its peer, and was securely transmitted (without
-   intruders able to see the unencrypted contents).
-
-3.6.  The KRB_CRED Exchange
-
-   The KRB_CRED message may be used by clients requiring the ability to
-   send Kerberos credentials from one host to another.  It achieves this
-   by sending the tickets together with encrypted data containing the
-   session keys and other information associated with the tickets.
-
-3.6.1. Generation of a KRB_CRED message
-
-   When an application wishes to send a KRB_CRED message it first (using
-   the KRB_TGS exchange) obtains credentials to be sent to the remote
-   host.  It then constructs a KRB_CRED message using the ticket or
-   tickets so obtained, placing the session key needed to use each
-   ticket in the key field of the corresponding KrbCredInfo sequence of
-   the encrypted part of the the KRB_CRED message.
-
-   Other information associated with each ticket and obtained during the
-   KRB_TGS exchange is also placed in the corresponding KrbCredInfo
-   sequence in the encrypted part of the KRB_CRED message.  The current
-   time and, if specifically required by the application the nonce, s-
-   address, and raddress fields, are placed in the encrypted part of the
-   KRB_CRED message which is then encrypted under an encryption key
-   previosuly exchanged in the KRB_AP exchange (usually the last key
-   negotiated via subkeys, or the session key if no negotiation has
-   occured).
-
-3.6.2. Receipt of KRB_CRED message
-
-   When an application receives a KRB_CRED message, it verifies it.  If
-   any error occurs, an error code is reported for use by the
-   application.  The message is verified by checking that the protocol
-   version and type fields match the current version and KRB_CRED,
-   respectively.  A mismatch generates a KRB_AP_ERR_BADVERSION or
-   KRB_AP_ERR_MSG_TYPE error.  The application then decrypts the
-   ciphertext and processes the resultant plaintext. If decryption shows
-   the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is
-   generated.
-
-
-
-Kohl & Neuman                                                  [Page 34]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   If present or required, the recipient verifies that the operating
-   system's report of the sender's address matches the sender's address
-   in the message, and that one of the recipient's addresses appears as
-   the recipient's address in the message.  A failed match for either
-   case generates a KRB_AP_ERR_BADADDR error.  The timestamp and usec
-   fields (and the nonce field if required) are checked next.  If the
-   timestamp and usec are not present, or they are present but not
-   current, the KRB_AP_ERR_SKEW error is generated.
-
-   If all the checks succeed, the application stores each of the new
-   tickets in its ticket cache together with the session key and other
-   information in the corresponding KrbCredInfo sequence from the
-   encrypted part of the KRB_CRED message.
-
-4.  The Kerberos Database
-
-   The Kerberos server must have access to a database containing the
-   principal identifiers and secret keys of principals to be
-   authenticated (The implementation of the Kerberos server need not
-   combine the database and the server on the same machine; it is
-   feasible to store the principal database in, say, a network name
-   service, as long as the entries stored therein are protected from
-   disclosure to and modification by unauthorized parties.  However, we
-   recommend against such strategies, as they can make system management
-   and threat analysis quite complex.).
-
-4.1.  Database contents
-
-   A database entry should contain at least the following fields:
-
-   Field                Value
-
-   name                 Principal's identifier
-   key                  Principal's secret key
-   p_kvno               Principal's key version
-   max_life             Maximum lifetime for Tickets
-   max_renewable_life   Maximum total lifetime for renewable
-                        Tickets
-
-   The name field is an encoding of the principal's identifier.  The key
-   field contains an encryption key.  This key is the principal's secret
-   key.  (The key can be encrypted before storage under a Kerberos
-   "master key" to protect it in case the database is compromised but
-   the master key is not.  In that case, an extra field must be added to
-   indicate the master key version used, see below.) The p_kvno field is
-   the key version number of the principal's secret key.  The max_life
-   field contains the maximum allowable lifetime (endtime - starttime)
-   for any Ticket issued for this principal.  The max_renewable_life
-
-
-
-Kohl & Neuman                                                  [Page 35]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   field contains the maximum allowable total lifetime for any renewable
-   Ticket issued for this principal.  (See section 3.1 for a description
-   of how these lifetimes are used in determining the lifetime of a
-   given Ticket.)
-
-   A server may provide KDC service to several realms, as long as the
-   database representation provides a mechanism to distinguish between
-   principal records with identifiers which differ only in the realm
-   name.
-
-   When an application server's key changes, if the change is routine
-   (i.e.,  not the result of disclosure of the old key), the old key
-   should be retained by the server until all tickets that had been
-   issued using that key have expired.  Because of this, it is possible
-   for several keys to be active for a single principal.  Ciphertext
-   encrypted in a principal's key is always tagged with the version of
-   the key that was used for encryption, to help the recipient find the
-   proper key for decryption.
-
-   When more than one key is active for a particular principal, the
-   principal will have more than one record in the Kerberos database.
-   The keys and key version numbers will differ between the records (the
-   rest of the fields may or may not be the same). Whenever Kerberos
-   issues a ticket, or responds to a request for initial authentication,
-   the most recent key (known by the Kerberos server) will be used for
-   encryption.  This is the key with the highest key version number.
-
-4.2.  Additional fields
-
-   Project Athena's KDC implementation uses additional fields in its
-   database:
-
-   Field        Value
-
-   K_kvno       Kerberos' key version
-   expiration   Expiration date for entry
-   attributes   Bit field of attributes
-   mod_date     Timestamp of last modification
-   mod_name     Modifying principal's identifier
-
-   The K_kvno field indicates the key version of the Kerberos master key
-   under which the principal's secret key is encrypted.
-
-   After an entry's expiration date has passed, the KDC will return an
-   error to any client attempting to gain tickets as or for the
-   principal.  (A database may want to maintain two expiration dates:
-   one for the principal, and one for the principal's current key.  This
-   allows password aging to work independently of the principal's
-
-
-
-Kohl & Neuman                                                  [Page 36]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   expiration date.  However, due to the limited space in the responses,
-   the KDC must combine the key expiration and principal expiration date
-   into a single value called "key_exp", which is used as a hint to the
-   user to take administrative action.)
-
-   The attributes field is a bitfield used to govern the operations
-   involving the principal.  This field might be useful in conjunction
-   with user registration procedures, for site-specific policy
-   implementations (Project Athena currently uses it for their user
-   registration process controlled by the system-wide database service,
-   Moira [7]), or to identify the "string to key" conversion algorithm
-   used for a principal's key.  (See the discussion of the padata field
-   in section 5.4.2 for details on why this can be useful.)  Other bits
-   are used to indicate that certain ticket options should not be
-   allowed in tickets encrypted under a principal's key (one bit each):
-   Disallow issuing postdated tickets, disallow issuing forwardable
-   tickets, disallow issuing tickets based on TGT authentication,
-   disallow issuing renewable tickets, disallow issuing proxiable
-   tickets, and disallow issuing tickets for which the principal is the
-   server.
-
-   The mod_date field contains the time of last modification of the
-   entry, and the mod_name field contains the name of the principal
-   which last modified the entry.
-
-4.3.  Frequently Changing Fields
-
-   Some KDC implementations may wish to maintain the last time that a
-   request was made by a particular principal.  Information that might
-   be maintained includes the time of the last request, the time of the
-   last request for a ticket-granting ticket, the time of the last use
-   of a ticket-granting ticket, or other times.  This information can
-   then be returned to the user in the last-req field (see section 5.2).
-
-   Other frequently changing information that can be maintained is the
-   latest expiration time for any tickets that have been issued using
-   each key.  This field would be used to indicate how long old keys
-   must remain valid to allow the continued use of outstanding tickets.
-
-4.4.  Site Constants
-
-   The KDC implementation should have the following configurable
-   constants or options, to allow an administrator to make and enforce
-   policy decisions:
-
-   + The minimum supported lifetime (used to determine whether the
-      KDC_ERR_NEVER_VALID error should be returned). This constant
-      should reflect reasonable expectations of round-trip time to the
-
-
-
-Kohl & Neuman                                                  [Page 37]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-      KDC, encryption/decryption time, and processing time by the client
-      and target server, and it should allow for a minimum "useful"
-      lifetime.
-
-   + The maximum allowable total (renewable) lifetime of a ticket
-      (renew_till - starttime).
-
-   + The maximum allowable lifetime of a ticket (endtime - starttime).
-
-   + Whether to allow the issue of tickets with empty address fields
-      (including the ability to specify that such tickets may only be
-      issued if the request specifies some authorization_data).
-
-   + Whether proxiable, forwardable, renewable or post-datable tickets
-      are to be issued.
-
-5.  Message Specifications
-
-   The following sections describe the exact contents and encoding of
-   protocol messages and objects.  The ASN.1 base definitions are
-   presented in the first subsection.  The remaining subsections specify
-   the protocol objects (tickets and authenticators) and messages.
-   Specification of encryption and checksum techniques, and the fields
-   related to them, appear in section 6.
-
-5.1.  ASN.1 Distinguished Encoding Representation
-
-   All uses of ASN.1 in Kerberos shall use the Distinguished Encoding
-   Representation of the data elements as described in the X.509
-   specification, section 8.7 [8].
-
-5.2.  ASN.1 Base Definitions
-
-   The following ASN.1 base definitions are used in the rest of this
-   section. Note that since the underscore character (_) is not
-   permitted in ASN.1 names, the hyphen (-) is used in its place for the
-   purposes of ASN.1 names.
-
-   Realm ::=           GeneralString
-   PrincipalName ::=   SEQUENCE {
-                       name-type[0]     INTEGER,
-                       name-string[1]   SEQUENCE OF GeneralString
-   }
-
-   Kerberos realms are encoded as GeneralStrings. Realms shall not
-   contain a character with the code 0 (the ASCII NUL).  Most realms
-   will usually consist of several components separated by periods (.),
-   in the style of Internet Domain Names, or separated by slashes (/) in
-
-
-
-Kohl & Neuman                                                  [Page 38]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   the style of X.500 names.  Acceptable forms for realm names are
-   specified in section 7.  A PrincipalName is a typed sequence of
-   components consisting of the following sub-fields:
-
-   name-type This field specifies the type of name that follows.
-             Pre-defined values for this field are
-             specified in section 7.2.  The name-type should be
-             treated as a hint.  Ignoring the name type, no two
-             names can be the same (i.e., at least one of the
-             components, or the realm, must be different).
-             This constraint may be eliminated in the future.
-
-   name-string This field encodes a sequence of components that
-               form a name, each component encoded as a General
-               String.  Taken together, a PrincipalName and a Realm
-               form a principal identifier.  Most PrincipalNames
-               will have only a few components (typically one or two).
-
-           KerberosTime ::=   GeneralizedTime
-                              -- Specifying UTC time zone (Z)
-
-   The timestamps used in Kerberos are encoded as GeneralizedTimes.  An
-   encoding shall specify the UTC time zone (Z) and shall not include
-   any fractional portions of the seconds.  It further shall not include
-   any separators.  Example: The only valid format for UTC time 6
-   minutes, 27 seconds after 9 pm on 6 November 1985 is 19851106210627Z.
-
-    HostAddress ::=     SEQUENCE  {
-                        addr-type[0]             INTEGER,
-                        address[1]               OCTET STRING
-    }
-
-    HostAddresses ::=   SEQUENCE OF SEQUENCE {
-                        addr-type[0]             INTEGER,
-                        address[1]               OCTET STRING
-    }
-
-
-   The host adddress encodings consists of two fields:
-
-   addr-type  This field specifies the type of  address that
-              follows. Pre-defined values for this field are
-              specified in section 8.1.
-
-
-   address   This field encodes a single address of type addr-type.
-
-   The two forms differ slightly. HostAddress contains exactly one
-
-
-
-Kohl & Neuman                                                  [Page 39]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   address; HostAddresses contains a sequence of possibly many
-   addresses.
-
-   AuthorizationData ::=   SEQUENCE OF SEQUENCE {
-                           ad-type[0]               INTEGER,
-                           ad-data[1]               OCTET STRING
-   }
-
-
-   ad-data   This field contains authorization data to be
-             interpreted according to the value of the
-             corresponding ad-type field.
-
-   ad-type   This field specifies the format for the ad-data
-             subfield.  All negative values are reserved for
-             local use.  Non-negative values are reserved for
-             registered use.
-
-                   APOptions ::=   BIT STRING {
-                                   reserved(0),
-                                   use-session-key(1),
-                                   mutual-required(2)
-                   }
-
-
-                   TicketFlags ::=   BIT STRING {
-                                     reserved(0),
-                                     forwardable(1),
-                                     forwarded(2),
-                                     proxiable(3),
-                                     proxy(4),
-                                     may-postdate(5),
-                                     postdated(6),
-                                     invalid(7),
-                                     renewable(8),
-                                     initial(9),
-                                     pre-authent(10),
-                                     hw-authent(11)
-                   }
-
-                  KDCOptions ::=   BIT STRING {
-                                   reserved(0),
-                                   forwardable(1),
-                                   forwarded(2),
-                                   proxiable(3),
-                                   proxy(4),
-                                   allow-postdate(5),
-                                   postdated(6),
-
-
-
-Kohl & Neuman                                                  [Page 40]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-                                   unused7(7),
-                                   renewable(8),
-                                   unused9(9),
-                                   unused10(10),
-                                   unused11(11),
-                                   renewable-ok(27),
-                                   enc-tkt-in-skey(28),
-                                   renew(30),
-                                   validate(31)
-                  }
-
-
-            LastReq ::=   SEQUENCE OF SEQUENCE {
-                          lr-type[0]               INTEGER,
-                          lr-value[1]              KerberosTime
-            }
-
-   lr-type   This field indicates how the following lr-value
-             field is to be interpreted.  Negative values indicate
-             that the information pertains only to the
-             responding server.  Non-negative values pertain to
-             all servers for the realm.
-
-             If the lr-type field is zero (0), then no information
-             is conveyed by the lr-value subfield.  If the
-             absolute value of the lr-type field is one (1),
-             then the lr-value subfield is the time of last
-             initial request for a TGT.  If it is two (2), then
-             the lr-value subfield is the time of last initial
-             request.  If it is three (3), then the lr-value
-             subfield is the time of issue for the newest
-             ticket-granting ticket used. If it is four (4),
-             then the lr-value subfield is the time of the last
-             renewal.  If it is five (5), then the lr-value
-             subfield is the time of last request (of any
-             type).
-
-   lr-value  This field contains the time of the last request.
-             The time must be interpreted according to the contents
-             of the accompanying lr-type subfield.
-
-   See section 6 for the definitions of Checksum, ChecksumType,
-   EncryptedData, EncryptionKey, EncryptionType, and KeyType.
-
-
-
-
-
-
-
-
-Kohl & Neuman                                                  [Page 41]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-5.3.  Tickets and Authenticators
-
-   This section describes the format and encryption parameters for
-   tickets and authenticators.  When a ticket or authenticator is
-   included in a protocol message it is treated as an opaque object.
-
-5.3.1. Tickets
-
-   A ticket is a record that helps a client authenticate to a service.
-   A Ticket contains the following information:
-
-Ticket ::=                    [APPLICATION 1] SEQUENCE {
-                              tkt-vno[0]                   INTEGER,
-                              realm[1]                     Realm,
-                              sname[2]                     PrincipalName,
-                              enc-part[3]                  EncryptedData
-}
--- Encrypted part of ticket
-EncTicketPart ::=     [APPLICATION 3] SEQUENCE {
-                      flags[0]             TicketFlags,
-                      key[1]               EncryptionKey,
-                      crealm[2]            Realm,
-                      cname[3]             PrincipalName,
-                      transited[4]         TransitedEncoding,
-                      authtime[5]          KerberosTime,
-                      starttime[6]         KerberosTime OPTIONAL,
-                      endtime[7]           KerberosTime,
-                      renew-till[8]        KerberosTime OPTIONAL,
-                      caddr[9]             HostAddresses OPTIONAL,
-                      authorization-data[10]   AuthorizationData OPTIONAL
-}
--- encoded Transited field
-TransitedEncoding ::=         SEQUENCE {
-                              tr-type[0]  INTEGER, -- must be registered
-                              contents[1]          OCTET STRING
-}
-
-   The encoding of EncTicketPart is encrypted in the key shared by
-   Kerberos and the end server (the server's secret key).  See section 6
-   for the format of the ciphertext.
-
-   tkt-vno   This field specifies the version number for the ticket
-             format.  This document describes version number 5.
-
-   realm     This field specifies the realm that issued a ticket.  It
-             also serves to identify the realm part of the server's
-             principal identifier.  Since a Kerberos server can only
-             issue tickets for servers within its realm, the two will
-
-
-
-Kohl & Neuman                                                  [Page 42]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-             always be identical.
-
-   sname     This field specifies the name part of the server's
-             identity.
-
-   enc-part  This field holds the encrypted encoding of the
-             EncTicketPart sequence.
-
-   flags     This field indicates which of various options were used or
-             requested when the ticket was issued.  It is a bit-field,
-             where the selected options are indicated by the bit being
-             set (1), and the unselected options and reserved fields
-             being reset (0).  Bit 0 is the most significant bit.  The
-             encoding of the bits is specified in section 5.2.  The
-             flags are described in more detail above in section 2.  The
-             meanings of the flags are:
-
-             Bit(s)    Name        Description
-
-             0         RESERVED    Reserved for future expansion of this
-                                   field.
-
-             1         FORWARDABLE The FORWARDABLE flag is normally only
-                                   interpreted by the TGS, and can be
-                                   ignored by end servers.  When set,
-                                   this flag tells the ticket-granting
-                                   server that it is OK to issue a new
-                                   ticket- granting ticket with a
-                                   different network address based on
-                                   the presented ticket.
-
-             2         FORWARDED   When set, this flag indicates that
-                                   the ticket has either been forwarded
-                                   or was issued based on authentication
-                                   involving a forwarded ticket-granting
-                                   ticket.
-
-             3         PROXIABLE   The PROXIABLE flag is normally only
-                                   interpreted by the TGS, and can be
-                                   ignored by end servers. The PROXIABLE
-                                   flag has an interpretation identical
-                                   to that of the FORWARDABLE flag,
-                                   except that the PROXIABLE flag tells
-                                   the ticket-granting server that only
-                                   non- ticket-granting tickets may be
-                                   issued with different network
-                                   addresses.
-
-
-
-
-Kohl & Neuman                                                  [Page 43]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-             4         PROXY      When set, this flag indicates that a
-                                   ticket is a proxy.
-
-             5         MAY-POSTDATE The MAY-POSTDATE flag is normally
-                                   only interpreted by the TGS, and can
-                                   be ignored by end servers.  This flag
-                                   tells the ticket-granting server that
-                                   a post- dated ticket may be issued
-                                   based on this ticket-granting ticket.
-
-             6         POSTDATED   This flag indicates that this ticket
-                                   has been postdated.  The end-service
-                                   can check the authtime field to see
-                                   when the original authentication
-                                   occurred.
-
-             7         INVALID     This flag indicates that a ticket is
-                                   invalid, and it must be validated by
-                                   the KDC before use.  Application
-                                   servers must reject tickets which
-                                   have this flag set.
-
-             8         RENEWABLE   The RENEWABLE flag is normally only
-                                   interpreted by the TGS, and can
-                                   usually be ignored by end servers
-                                   (some particularly careful servers
-                                   may wish to disallow renewable
-                                   tickets).  A renewable ticket can be
-                                   used to obtain a replacement ticket
-                                   that expires at a later date.
-
-             9         INITIAL     This flag indicates that this ticket
-                                   was issued using the AS protocol, and
-                                   not issued based on a ticket-granting
-                                   ticket.
-
-             10        PRE-AUTHENT This flag indicates that during
-                                   initial authentication, the client
-                                   was authenticated by the KDC before a
-                                   ticket was issued.  The strength of
-                                   the preauthentication method is not
-                                   indicated, but is acceptable to the
-                                   KDC.
-
-             11        HW-AUTHENT  This flag indicates that the protocol
-                                   employed for initial authentication
-                                   required the use of hardware expected
-                                   to be possessed solely by the named
-
-
-
-Kohl & Neuman                                                  [Page 44]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-                                   client.  The hardware authentication
-                                   method is selected by the KDC and the
-                                   strength of the method is not
-                                   indicated.
-
-             12-31     RESERVED    Reserved for future use.
-
-   key       This field exists in the ticket and the KDC response and is
-             used to pass the session key from Kerberos to the
-             application server and the client.  The field's encoding is
-             described in section 6.2.
-
-   crealm    This field contains the name of the realm in which the
-             client is registered and in which initial authentication
-             took place.
-
-   cname     This field contains the name part of the client's principal
-             identifier.
-
-   transited This field lists the names of the Kerberos realms that took
-             part in authenticating the user to whom this ticket was
-             issued.  It does not specify the order in which the realms
-             were transited.  See section 3.3.3.1 for details on how
-             this field encodes the traversed realms.
-
-   authtime  This field indicates the time of initial authentication for
-             the named principal.  It is the time of issue for the
-             original ticket on which this ticket is based.  It is
-             included in the ticket to provide additional information to
-             the end service, and  to provide  the necessary information
-             for implementation of a `hot list' service at the KDC.   An
-             end service that is particularly paranoid could refuse to
-             accept tickets for which the initial authentication
-             occurred "too far" in the past.
-
-             This field is also returned as part of the response from
-             the KDC.  When returned as part of the response to initial
-             authentication (KRB_AS_REP), this is the current time on
-             the Kerberos server (It is NOT recommended that this time
-             value be used to adjust the workstation's clock since the
-             workstation cannot reliably determine that such a
-             KRB_AS_REP actually came from the proper KDC in a timely
-             manner.).
-
-   starttime This field in the ticket specifies the time after which the
-             ticket is valid.  Together with endtime, this field
-             specifies the life of the ticket.   If it is absent from
-             the ticket, its value should be treated as that of the
-
-
-
-Kohl & Neuman                                                  [Page 45]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-             authtime field.
-
-   endtime   This field contains the time after which the ticket will
-             not be honored (its expiration time).  Note that individual
-             services may place their own limits on the life of a ticket
-             and may reject tickets which have not yet expired.  As
-             such, this is really an upper bound on the expiration time
-             for the ticket.
-
-   renew-till This field is only present in tickets that have the
-             RENEWABLE flag set in the flags field.  It indicates the
-             maximum endtime that may be included in a renewal.  It can
-             be thought of as the absolute expiration time for the
-             ticket, including all renewals.
-
-   caddr     This field in a ticket contains zero (if omitted) or more
-             (if present) host addresses.  These are the addresses from
-             which the ticket can be used.  If there are no addresses,
-             the ticket can be used from any location.  The decision
-             by the KDC to issue or by the end server to accept zero-
-             address tickets is a policy decision and is left to the
-             Kerberos and end-service administrators; they may refuse to
-             issue or accept such tickets.  The suggested and default
-             policy, however, is that such tickets will only be issued
-             or accepted when additional information that can be used to
-             restrict the use of the ticket is included in the
-             authorization_data field.  Such a ticket is a capability.
-
-             Network addresses are included in the ticket to make it
-             harder for an attacker to use stolen credentials. Because
-             the session key is not sent over the network in cleartext,
-             credentials can't be stolen simply by listening to the
-             network; an attacker has to gain access to the session key
-             (perhaps through operating system security breaches or a
-             careless user's unattended session) to make use of stolen
-             tickets.
-
-             It is important to note that the network address from which
-             a connection is received cannot be reliably determined.
-             Even if it could be, an attacker who has compromised the
-             client's workstation could use the credentials from there.
-             Including the network addresses only makes it more
-             difficult, not impossible, for an attacker to walk off with
-             stolen credentials and then use them from a "safe"
-             location.
-
-
-
-
-
-
-Kohl & Neuman                                                  [Page 46]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   authorization-data The authorization-data field is used to pass
-             authorization data from the principal on whose behalf a
-             ticket was issued to the application service.  If no
-             authorization data is included, this field will be left
-             out.  The data in this field are specific to the end
-             service.  It is expected that the field will contain the
-             names of service specific objects, and the rights to those
-             objects.  The format for this field is described in section
-             5.2.  Although Kerberos is not concerned with the format of
-             the contents of the subfields, it does carry type
-             information (ad-type).
-
-             By using the authorization_data field, a principal is able
-             to issue a proxy that is valid for a specific purpose.  For
-             example, a client wishing to print a file can obtain a file
-             server proxy to be passed to the print server.  By
-             specifying the name of the file in the authorization_data
-             field, the file server knows that the print server can only
-             use the client's rights when accessing the particular file
-             to be printed.
-
-             It is interesting to note that if one specifies the
-             authorization-data field of a proxy and leaves the host
-             addresses blank, the resulting ticket and session key can
-             be treated as a capability.  See [9] for some suggested
-             uses of this field.
-
-             The authorization-data field is optional and does not have
-             to be included in a ticket.
-
-5.3.2. Authenticators
-
-   An authenticator is a record sent with a ticket to a server to
-   certify the client's knowledge of the encryption key in the ticket,
-   to help the server detect replays, and to help choose a "true session
-   key" to use with the particular session.  The encoding is encrypted
-   in the ticket's session key shared by the client and the server:
-
--- Unencrypted authenticator
-Authenticator ::=    [APPLICATION 2] SEQUENCE    {
-               authenticator-vno[0]          INTEGER,
-               crealm[1]                     Realm,
-               cname[2]                      PrincipalName,
-               cksum[3]                      Checksum OPTIONAL,
-               cusec[4]                      INTEGER,
-               ctime[5]                      KerberosTime,
-               subkey[6]                     EncryptionKey OPTIONAL,
-               seq-number[7]                 INTEGER OPTIONAL,
-
-
-
-Kohl & Neuman                                                  [Page 47]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-               authorization-data[8]         AuthorizationData OPTIONAL
-                     }
-
-   authenticator-vno This field specifies the version number for the
-             format of the authenticator. This document specifies
-             version 5.
-
-   crealm and cname These fields are the same as those described for the
-             ticket in section 5.3.1.
-
-   cksum     This field contains a checksum of the the application data
-             that accompanies the KRB_AP_REQ.
-
-   cusec     This field contains the microsecond part of the client's
-             timestamp.  Its value (before encryption) ranges from 0 to
-             999999.  It often appears along with ctime.  The two fields
-             are used together to specify a reasonably accurate
-             timestamp.
-
-   ctime     This field contains the current time on the client's host.
-
-   subkey    This field contains the client's choice for an encryption
-             key which is to be used to protect this specific
-             application session. Unless an application specifies
-             otherwise, if this field is left out the session key from
-             the ticket will be used.
-
-   seq-number This optional field includes the initial sequence number
-             to be used by the KRB_PRIV or KRB_SAFE messages when
-             sequence numbers are used to detect replays (It may also be
-             used by application specific messages).  When included in
-             the authenticator this field specifies the initial sequence
-             number for messages from the client to the server.  When
-             included in the AP-REP message, the initial sequence number
-             is that for messages from the server to the client.  When
-             used in KRB_PRIV or KRB_SAFE messages, it is incremented by
-             one after each message is sent.
-
-             For sequence numbers to adequately support the detection of
-             replays they should be non-repeating, even across
-             connection boundaries. The initial sequence number should
-             be random and uniformly distributed across the full space
-             of possible sequence numbers, so that it cannot be guessed
-             by an attacker and so that it and the successive sequence
-             numbers do not repeat other sequences.
-
-
-
-
-
-
-Kohl & Neuman                                                  [Page 48]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   authorization-data This field is the same as described for the ticket
-             in section 5.3.1.  It is optional and will only appear when
-             additional restrictions are to be placed on the use of a
-             ticket, beyond those carried in the ticket itself.
-
-5.4.  Specifications for the AS and TGS exchanges
-
-   This section specifies the format of the messages used in exchange
-   between the client and the Kerberos server.  The format of possible
-   error messages appears in section 5.9.1.
-
-5.4.1. KRB_KDC_REQ definition
-
-   The KRB_KDC_REQ message has no type of its own.  Instead, its type is
-   one of KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is
-   for an initial ticket or an additional ticket.  In either case, the
-   message is sent from the client to the Authentication Server to
-   request credentials for a service.
-
-The message fields are:
-
-AS-REQ ::=         [APPLICATION 10] KDC-REQ
-TGS-REQ ::=        [APPLICATION 12] KDC-REQ
-
-KDC-REQ ::=        SEQUENCE {
-           pvno[1]               INTEGER,
-           msg-type[2]           INTEGER,
-           padata[3]             SEQUENCE OF PA-DATA OPTIONAL,
-           req-body[4]           KDC-REQ-BODY
-}
-
-PA-DATA ::=        SEQUENCE {
-           padata-type[1]        INTEGER,
-           padata-value[2]       OCTET STRING,
-                         -- might be encoded AP-REQ
-}
-
-KDC-REQ-BODY ::=   SEQUENCE {
-            kdc-options[0]       KDCOptions,
-            cname[1]             PrincipalName OPTIONAL,
-                         -- Used only in AS-REQ
-            realm[2]             Realm, -- Server's realm
-                         -- Also client's in AS-REQ
-            sname[3]             PrincipalName OPTIONAL,
-            from[4]              KerberosTime OPTIONAL,
-            till[5]              KerberosTime,
-            rtime[6]             KerberosTime OPTIONAL,
-            nonce[7]             INTEGER,
-
-
-
-Kohl & Neuman                                                  [Page 49]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-            etype[8]             SEQUENCE OF INTEGER, -- EncryptionType,
-                         -- in preference order
-            addresses[9]         HostAddresses OPTIONAL,
-            enc-authorization-data[10]   EncryptedData OPTIONAL,
-                         -- Encrypted AuthorizationData encoding
-            additional-tickets[11]       SEQUENCE OF Ticket OPTIONAL
-}
-
-   The fields in this message are:
-
-   pvno      This field is included in each message, and specifies the
-             protocol version number.  This document specifies protocol
-             version 5.
-
-   msg-type  This field indicates the type of a protocol message.  It
-             will almost always be the same as the application
-             identifier associated with a message.  It is included to
-             make the identifier more readily accessible to the
-             application.  For the KDC-REQ message, this type will be
-             KRB_AS_REQ or KRB_TGS_REQ.
-
-   padata    The padata (pre-authentication data) field contains a of
-             authentication information which may be needed before
-             credentials can be issued or decrypted.  In the case of
-             requests for additional tickets (KRB_TGS_REQ), this field
-             will include an element with padata-type of PA-TGS-REQ and
-             data of an authentication header (ticket-granting ticket
-             and authenticator). The checksum in the authenticator
-             (which must be collisionproof) is to be computed over the
-             KDC-REQ-BODY encoding.  In most requests for initial
-             authentication (KRB_AS_REQ) and most replies (KDC-REP), the
-             padata field will be left out.
-
-             This field may also contain information needed by certain
-             extensions to the Kerberos protocol.  For example, it might
-             be used to initially verify the identity of a client before
-             any response is returned.  This is accomplished with a
-             padata field with padata-type equal to PA-ENC-TIMESTAMP and
-             padata-value defined as follows:
-
-   padata-type     ::= PA-ENC-TIMESTAMP
-   padata-value    ::= EncryptedData -- PA-ENC-TS-ENC
-
-   PA-ENC-TS-ENC   ::= SEQUENCE {
-           patimestamp[0]               KerberosTime, -- client's time
-           pausec[1]                    INTEGER OPTIONAL
-   }
-
-
-
-
-Kohl & Neuman                                                  [Page 50]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-             with patimestamp containing the client's time and pausec
-             containing the microseconds which may be omitted if a
-             client will not generate more than one request per second.
-             The ciphertext (padata-value) consists of the PA-ENC-TS-ENC
-             sequence, encrypted using the client's secret key.
-
-             The padata field can also contain information needed to
-             help the KDC or the client select the key needed for
-             generating or decrypting the response.  This form of the
-             padata is useful for supporting the use of certain
-             "smartcards" with Kerberos.  The details of such extensions
-             are beyond the scope of this specification.  See [10] for
-             additional uses of this field.
-
-   padata-type The padata-type element of the padata field indicates the
-             way that the padata-value element is to be interpreted.
-             Negative values of padata-type are reserved for
-             unregistered use; non-negative values are used for a
-             registered interpretation of the element type.
-
-   req-body  This field is a placeholder delimiting the extent of the
-             remaining fields.  If a checksum is to be calculated over
-             the request, it is calculated over an encoding of the KDC-
-             REQ-BODY sequence which is enclosed within the req-body
-             field.
-
-   kdc-options This field appears in the KRB_AS_REQ and KRB_TGS_REQ
-             requests to the KDC and indicates the flags that the client
-             wants set on the tickets as well as other information that
-             is to modify the behavior of the KDC. Where appropriate,
-             the name of an option may be the same as the flag that is
-             set by that option.  Although in most case, the bit in the
-             options field will be the same as that in the flags field,
-             this is not guaranteed, so it is not acceptable to simply
-             copy the options field to the flags field.  There are
-             various checks that must be made before honoring an option
-             anyway.
-
-             The kdc_options field is a bit-field, where the selected
-             options are indicated by the bit being set (1), and the
-             unselected options and reserved fields being reset (0).
-             The encoding of the bits is specified in section 5.2.  The
-             options are described in more detail above in section 2.
-             The meanings of the options are:
-
-
-
-
-
-
-
-Kohl & Neuman                                                  [Page 51]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-             Bit(s)  Name         Description
-
-             0       RESERVED     Reserved for future expansion of this
-                                  field.
-
-             1       FORWARDABLE  The FORWARDABLE option indicates that
-                                  the ticket to be issued is to have its
-                                  forwardable flag set.  It may only be
-                                  set on the initial request, or in a
-                                  subsequent request if the ticket-
-                                  granting ticket on which it is based
-                                  is also forwardable.
-
-             2       FORWARDED    The FORWARDED option is only specified
-                                  in a request to the ticket-granting
-                                  server and will only be honored if the
-                                  ticket-granting ticket in the request
-                                  has its FORWARDABLE bit set.  This
-                                  option indicates that this is a
-                                  request for forwarding. The
-                                  address(es) of the host from which the
-                                  resulting ticket is to be valid are
-                                  included in the addresses field of the
-                                  request.
-
-
-             3       PROXIABLE    The PROXIABLE option indicates that
-                                  the ticket to be issued is to have its
-                                  proxiable flag set. It may only be set
-                                  on the initial request, or in a
-                                  subsequent request if the ticket-
-                                  granting ticket on which it is based
-                                  is also proxiable.
-
-             4       PROXY        The PROXY option indicates that this
-                                  is a request for a proxy.  This option
-                                  will only be honored if the ticket-
-                                  granting ticket in the request has its
-                                  PROXIABLE bit set.  The address(es) of
-                                  the host from which the resulting
-                                  ticket is to be valid are included in
-                                  the addresses field of the request.
-
-             5       ALLOW-POSTDATE The ALLOW-POSTDATE option indicates
-                                  that the ticket to be issued is to
-                                  have its MAY-POSTDATE flag set.  It
-                                  may only be set on the initial
-                                  request, or in a subsequent request if
-
-
-
-Kohl & Neuman                                                  [Page 52]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-                                  the ticket-granting ticket on which it
-                                  is based also has its MAY-POSTDATE
-                                  flag set.
-
-             6       POSTDATED    The POSTDATED option indicates that
-                                  this is a request for a postdated
-                                  ticket.  This option will only be
-                                  honored if the ticket-granting ticket
-                                  on which it is based has its MAY-
-                                  POSTDATE flag set.  The resulting
-                                  ticket will also have its INVALID flag
-                                  set, and that flag may be reset by a
-                                  subsequent request to the KDC after
-                                  the starttime in the ticket has been
-                                  reached.
-
-             7       UNUSED       This option is presently unused.
-
-             8       RENEWABLE    The RENEWABLE option indicates that
-                                  the ticket to be issued is to have its
-                                  RENEWABLE flag set.  It may only be
-                                  set on the initial request, or when
-                                  the ticket-granting ticket on which
-                                  the request is based is also
-                                  renewable.  If this option is
-                                  requested, then the rtime field in the
-                                  request contains the desired absolute
-                                  expiration time for the ticket.
-
-             9-26    RESERVED     Reserved for future use.
-
-             27      RENEWABLE-OK The RENEWABLE-OK option indicates that
-                                  a renewable ticket will be acceptable
-                                  if a ticket with the requested life
-                                  cannot otherwise be provided.  If a
-                                  ticket with the requested life cannot
-                                  be provided, then a renewable ticket
-                                  may be issued with a renew-till equal
-                                  to the the requested endtime.  The
-                                  value of the renew-till field may
-                                  still be limited by local limits, or
-                                  limits selected by the individual
-                                  principal or server.
-
-             28      ENC-TKT-IN-SKEY This option is used only by the
-                                  ticket-granting service.  The ENC-
-                                  TKT-IN-SKEY option indicates that the
-                                  ticket for the end server is to be
-
-
-
-Kohl & Neuman                                                  [Page 53]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-                                  encrypted in the session key from the
-                                  additional ticket-granting ticket
-                                  provided.
-
-             29      RESERVED     Reserved for future use.
-
-             30      RENEW        This option is used only by the
-                                  ticket-granting service.  The RENEW
-                                  option indicates that the present
-                                  request is for a renewal.  The ticket
-                                  provided is encrypted in the secret
-                                  key for the server on which it is
-                                  valid.  This option will only be
-                                  honored if the ticket to be renewed
-                                  has its RENEWABLE flag set and if the
-                                  time in its renew till field has not
-                                  passed.  The ticket to be renewed is
-                                  passed in the padata field as part of
-                                  the authentication header.
-
-             31      VALIDATE     This option is used only by the
-                                  ticket-granting service.  The VALIDATE
-                                  option indicates that the request is
-                                  to validate a postdated ticket.  It
-                                  will only be honored if the ticket
-                                  presented is postdated, presently has
-                                  its INVALID flag set, and would be
-                                  otherwise usable at this time.  A
-                                  ticket cannot be validated before its
-                                  starttime.  The ticket presented for
-                                  validation is encrypted in the key of
-                                  the server for which it is valid and
-                                  is passed in the padata field as part
-                                  of the authentication header.
-
-   cname and sname These fields are the same as those described for the
-             ticket in section 5.3.1.  sname may only be absent when the
-             ENC-TKT-IN-SKEY option is specified.  If absent, the name
-             of the server is taken from the name of the client in the
-             ticket passed as additional-tickets.
-
-   enc-authorization-data The enc-authorization-data, if present (and it
-             can only be present in the TGS_REQ form), is an encoding of
-             the desired authorization-data encrypted under the sub-
-             session key if present in the Authenticator, or
-             alternatively from the session key in the ticket-granting
-             ticket, both from the padata field in the KRB_AP_REQ.
-
-
-
-
-Kohl & Neuman                                                  [Page 54]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   realm     This field specifies the realm part of the server's
-             principal identifier. In the AS exchange, this is also the
-             realm part of the client's principal identifier.
-
-   from      This field is included in the KRB_AS_REQ and KRB_TGS_REQ
-             ticket requests when the requested ticket is to be
-             postdated.  It specifies the desired start time for the
-             requested ticket.
-
-   till      This field contains the expiration date requested by the
-             client in a ticket request.
-
-   rtime     This field is the requested renew-till time sent from a
-             client to the KDC in a ticket request.  It is optional.
-
-   nonce     This field is part of the KDC request and response.  It it
-             intended to hold a random number generated by the client.
-             If the same number is included in the encrypted response
-             from the KDC, it provides evidence that the response is
-             fresh and has not been replayed by an attacker.  Nonces
-             must never be re-used.  Ideally, it should be gen erated
-             randomly, but if the correct time is known, it may suffice
-             (Note, however, that if the time is used as the nonce, one
-             must make sure that the workstation time is monotonically
-             increasing.  If the time is ever reset backwards, there is
-             a small, but finite, probability that a nonce will be
-             reused.).
-
-   etype     This field specifies the desired encryption algorithm to be
-             used in the response.
-
-   addresses This field is included in the initial request for tickets,
-             and optionally included in requests for additional tickets
-             from the ticket-granting server.  It specifies the
-             addresses from which the requested ticket is to be valid.
-             Normally it includes the addresses for the client's host.
-             If a proxy is requested, this field will contain other
-             addresses.  The contents of this field are usually copied
-             by the KDC into the caddr field of the resulting ticket.
-
-   additional-tickets Additional tickets may be optionally included in a
-             request to the ticket-granting server.  If the ENC-TKT-IN-
-             SKEY option has been specified, then the session key from
-             the additional ticket will be used in place of the server's
-             key to encrypt the new ticket.  If more than one option
-             which requires additional tickets has been specified, then
-             the additional tickets are used in the order specified by
-             the ordering of the options bits (see kdc-options, above).
-
-
-
-Kohl & Neuman                                                  [Page 55]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   The application code will be either ten (10) or twelve (12) depending
-   on whether the request is for an initial ticket (AS-REQ) or for an
-   additional ticket (TGS-REQ).
-
-   The optional fields (addresses, authorization-data and additional-
-   tickets) are only included if necessary to perform the operation
-   specified in the kdc-options field.
-
-   It should be noted that in KRB_TGS_REQ, the protocol version number
-   appears twice and two different message types appear: the KRB_TGS_REQ
-   message contains these fields as does the authentication header
-   (KRB_AP_REQ) that is passed in the padata field.
-
-5.4.2. KRB_KDC_REP definition
-
-   The KRB_KDC_REP message format is used for the reply from the KDC for
-   either an initial (AS) request or a subsequent (TGS) request.  There
-   is no message type for KRB_KDC_REP.  Instead, the type will be either
-   KRB_AS_REP or KRB_TGS_REP.  The key used to encrypt the ciphertext
-   part of the reply depends on the message type.  For KRB_AS_REP, the
-   ciphertext is encrypted in the client's secret key, and the client's
-   key version number is included in the key version number for the
-   encrypted data.  For KRB_TGS_REP, the ciphertext is encrypted in the
-   sub-session key from the Authenticator, or if absent, the session key
-   from the ticket-granting ticket used in the request.  In that case,
-   no version number will be present in the EncryptedData sequence.
-
-   The KRB_KDC_REP message contains the following fields:
-
-   AS-REP ::=    [APPLICATION 11] KDC-REP
-   TGS-REP ::=   [APPLICATION 13] KDC-REP
-
-   KDC-REP ::=   SEQUENCE {
-                 pvno[0]                    INTEGER,
-                 msg-type[1]                INTEGER,
-                 padata[2]                  SEQUENCE OF PA-DATA OPTIONAL,
-                 crealm[3]                  Realm,
-                 cname[4]                   PrincipalName,
-                 ticket[5]                  Ticket,
-                 enc-part[6]                EncryptedData
-   }
-
-   EncASRepPart ::=    [APPLICATION 25[25]] EncKDCRepPart
-   EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart
-
-   EncKDCRepPart ::=   SEQUENCE {
-               key[0]                       EncryptionKey,
-               last-req[1]                  LastReq,
-
-
-
-Kohl & Neuman                                                  [Page 56]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-               nonce[2]                     INTEGER,
-               key-expiration[3]            KerberosTime OPTIONAL,
-               flags[4]                     TicketFlags,
-               authtime[5]                  KerberosTime,
-               starttime[6]                 KerberosTime OPTIONAL,
-               endtime[7]                   KerberosTime,
-               renew-till[8]                KerberosTime OPTIONAL,
-               srealm[9]                    Realm,
-               sname[10]                    PrincipalName,
-               caddr[11]                    HostAddresses OPTIONAL
-   }
-
-   NOTE: In EncASRepPart, the application code in the encrypted
-         part of a message provides an additional check that
-         the message was decrypted properly.
-
-   pvno and msg-type These fields are described above in section 5.4.1.
-             msg-type is either KRB_AS_REP or KRB_TGS_REP.
-
-   padata    This field is described in detail in section 5.4.1.  One
-             possible use for this field is to encode an alternate
-             "mix-in" string to be used with a string-to-key algorithm
-             (such as is described in section 6.3.2). This ability is
-             useful to ease transitions if a realm name needs to change
-             (e.g., when a company is acquired); in such a case all
-             existing password-derived entries in the KDC database would
-             be flagged as needing a special mix-in string until the
-             next password change.
-
-   crealm, cname, srealm and sname These fields are the same as those
-             described for the ticket in section 5.3.1.
-
-   ticket    The newly-issued ticket, from section 5.3.1.
-
-   enc-part  This field is a place holder for the ciphertext and related
-             information that forms the encrypted part of a message.
-             The description of the encrypted part of the message
-             follows each appearance of this field.  The encrypted part
-             is encoded as described in section 6.1.
-
-   key       This field is the same as described for the ticket in
-             section 5.3.1.
-
-   last-req  This field is returned by the KDC and specifies the time(s)
-             of the last request by a principal.  Depending on what
-             information is available, this might be the last time that
-             a request for a ticket-granting ticket was made, or the
-             last time that a request based on a ticket-granting ticket
-
-
-
-Kohl & Neuman                                                  [Page 57]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-             was successful.  It also might cover all servers for a
-             realm, or just the particular server. Some implementations
-             may display this information to the user to aid in
-             discovering unauthorized use of one's identity.  It is
-             similar in spirit to the last login time displayed when
-             logging into timesharing systems.
-
-   nonce     This field is described above in section 5.4.1.
-
-   key-expiration The key-expiration field is part of the response from
-             the KDC and specifies the time that the client's secret key
-             is due to expire.  The expiration might be the result of
-             password aging or an account expiration.  This field will
-             usually be left out of the TGS reply since the response to
-             the TGS request is encrypted in a session key and no client
-             information need be retrieved from the KDC database.  It is
-             up to the application client (usually the login program) to
-             take appropriate action (such as notifying the user) if the
-             expira    tion time is imminent.
-
-   flags, authtime, starttime, endtime, renew-till and caddr These
-             fields are duplicates of those found in the encrypted
-             portion of the attached ticket (see section 5.3.1),
-             provided so the client may verify they match the intended
-             request and to assist in proper ticket caching.  If the
-             message is of type KRB_TGS_REP, the caddr field will only
-             be filled in if the request was for a proxy or forwarded
-             ticket, or if the user is substituting a subset of the
-             addresses from the ticket granting ticket.  If the client-
-             requested addresses are not present or not used, then the
-             addresses contained in the ticket will be the same as those
-             included in the ticket-granting ticket.
-
-5.5.  Client/Server (CS) message specifications
-
-   This section specifies the format of the messages used for the
-   authentication of the client to the application server.
-
-5.5.1. KRB_AP_REQ definition
-
-   The KRB_AP_REQ message contains the Kerberos protocol version number,
-   the message type KRB_AP_REQ, an options field to indicate any options
-   in use, and the ticket and authenticator themselves.  The KRB_AP_REQ
-   message is often referred to as the "authentication header".
-
-   AP-REQ ::=      [APPLICATION 14] SEQUENCE {
-                   pvno[0]                       INTEGER,
-                   msg-type[1]                   INTEGER,
-
-
-
-Kohl & Neuman                                                  [Page 58]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-                   ap-options[2]                 APOptions,
-                   ticket[3]                     Ticket,
-                   authenticator[4]              EncryptedData
-   }
-
-   APOptions ::=   BIT STRING {
-                   reserved(0),
-                   use-session-key(1),
-                   mutual-required(2)
-   }
-
-   pvno and msg-type These fields are described above in section 5.4.1.
-             msg-type is KRB_AP_REQ.
-
-   ap-options This field appears in the application request (KRB_AP_REQ)
-             and affects the way the request is processed.  It is a
-             bit-field, where the selected options are indicated by the
-             bit being set (1), and the unselected options and reserved
-             fields being reset (0).  The encoding of the bits is
-             specified in section 5.2.  The meanings of the options are:
-
-             Bit(s)  Name           Description
-
-             0       RESERVED       Reserved for future expansion of
-                                  this field.
-
-             1       USE-SESSION-KEYThe USE-SESSION-KEY option indicates
-                                  that the ticket the client is
-                                  presenting to a server is encrypted in
-                                  the session key from the server's
-                                  ticket-granting ticket. When this
-                                  option is not specified, the ticket is
-                                  encrypted in the server's secret key.
-
-             2       MUTUAL-REQUIREDThe MUTUAL-REQUIRED option tells the
-                                  server that the client requires mutual
-                                  authentication, and that it must
-                                  respond with a KRB_AP_REP message.
-
-             3-31    RESERVED       Reserved for future use.
-
-   ticket    This field is a ticket authenticating the client to the
-             server.
-
-   authenticator This contains the authenticator, which includes the
-             client's choice of a subkey.  Its encoding is described in
-             section 5.3.2.
-
-
-
-
-Kohl & Neuman                                                  [Page 59]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-5.5.2.  KRB_AP_REP definition
-
-   The KRB_AP_REP message contains the Kerberos protocol version number,
-   the message type, and an encrypted timestamp. The message is sent in
-   in response to an application request (KRB_AP_REQ) where the mutual
-   authentication option has been selected in the ap-options field.
-
-   AP-REP ::=         [APPLICATION 15] SEQUENCE {
-              pvno[0]                   INTEGER,
-              msg-type[1]               INTEGER,
-              enc-part[2]               EncryptedData
-   }
-
-   EncAPRepPart ::=   [APPLICATION 27]     SEQUENCE {
-              ctime[0]                  KerberosTime,
-              cusec[1]                  INTEGER,
-              subkey[2]                 EncryptionKey OPTIONAL,
-              seq-number[3]             INTEGER OPTIONAL
-   }
-
-   NOTE: in EncAPRepPart, the application code in the encrypted part of
-   a message provides an additional check that the message was decrypted
-   properly.
-
-   The encoded EncAPRepPart is encrypted in the shared session key of
-   the ticket.  The optional subkey field can be used in an
-   application-arranged negotiation to choose a per association session
-   key.
-
-   pvno and msg-type These fields are described above in section 5.4.1.
-             msg-type is KRB_AP_REP.
-
-   enc-part  This field is described above in section 5.4.2.
-
-   ctime     This field contains the current time on the client's host.
-
-   cusec     This field contains the microsecond part of the client's
-             timestamp.
-
-   subkey    This field contains an encryption key which is to be used
-             to protect this specific application session.  See section
-             3.2.6 for specifics on how this field is used to negotiate
-             a key.  Unless an application specifies otherwise, if this
-             field is left out, the sub-session key from the
-             authenticator, or if also left out, the session key from
-             the ticket will be used.
-
-
-
-
-
-Kohl & Neuman                                                  [Page 60]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-5.5.3. Error message reply
-
-   If an error occurs while processing the application request, the
-   KRB_ERROR message will be sent in response.  See section 5.9.1 for
-   the format of the error message.  The cname and crealm fields may be
-   left out if the server cannot determine their appropriate values from
-   the corresponding KRB_AP_REQ message.  If the authenticator was
-   decipherable, the ctime and cusec fields will contain the values from
-   it.
-
-5.6.  KRB_SAFE message specification
-
-   This section specifies the format of a message that can be used by
-   either side (client or server) of an application to send a tamper-
-   proof message to its peer. It presumes that a session key has
-   previously been exchanged (for example, by using the
-   KRB_AP_REQ/KRB_AP_REP messages).
-
-5.6.1. KRB_SAFE definition
-
-   The KRB_SAFE message contains user data along with a collision-proof
-   checksum keyed with the session key.  The message fields are:
-
-   KRB-SAFE ::=        [APPLICATION 20] SEQUENCE {
-               pvno[0]               INTEGER,
-               msg-type[1]           INTEGER,
-               safe-body[2]          KRB-SAFE-BODY,
-               cksum[3]              Checksum
-   }
-
-   KRB-SAFE-BODY ::=   SEQUENCE {
-               user-data[0]          OCTET STRING,
-               timestamp[1]          KerberosTime OPTIONAL,
-               usec[2]               INTEGER OPTIONAL,
-               seq-number[3]         INTEGER OPTIONAL,
-               s-address[4]          HostAddress,
-               r-address[5]          HostAddress OPTIONAL
-   }
-
-   pvno and msg-type These fields are described above in section 5.4.1.
-             msg-type is KRB_SAFE.
-
-   safe-body This field is a placeholder for the body of the KRB-SAFE
-             message.  It is to be encoded separately and then have the
-             checksum computed over it, for use in the cksum field.
-
-   cksum     This field contains the checksum of the application data.
-             Checksum details are described in section 6.4.  The
-
-
-
-Kohl & Neuman                                                  [Page 61]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-             checksum is computed over the encoding of the KRB-SAFE-BODY
-             sequence.
-
-   user-data This field is part of the KRB_SAFE and KRB_PRIV messages
-             and contain the application specific data that is being
-             passed from the sender to the recipient.
-
-   timestamp This field is part of the KRB_SAFE and KRB_PRIV messages.
-             Its contents are the current time as known by the sender of
-             the message. By checking the timestamp, the recipient of
-             the message is able to make sure that it was recently
-             generated, and is not a replay.
-
-   usec      This field is part of the KRB_SAFE and KRB_PRIV headers.
-             It contains the microsecond part of the timestamp.
-
-   seq-number This field is described above in section 5.3.2.
-
-   s-address This field specifies the address in use by the sender of
-             the message.
-
-   r-address This field specifies the address in use by the recipient of
-             the message.  It may be omitted for some uses (such as
-             broadcast protocols), but the recipient may arbitrarily
-             reject such messages.  This field along with s-address can
-             be used to help detect messages which have been incorrectly
-             or maliciously delivered to the wrong recipient.
-
-5.7.  KRB_PRIV message specification
-
-   This section specifies the format of a message that can be used by
-   either side (client or server) of an application to securely and
-   privately send a message to its peer.  It presumes that a session key
-   has previously been exchanged (for example, by using the
-   KRB_AP_REQ/KRB_AP_REP messages).
-
-5.7.1. KRB_PRIV definition
-
-   The KRB_PRIV message contains user data encrypted in the Session Key.
-   The message fields are:
-
-   KRB-PRIV ::=         [APPLICATION 21] SEQUENCE {
-                pvno[0]                   INTEGER,
-                msg-type[1]               INTEGER,
-                enc-part[3]               EncryptedData
-   }
-
-
-
-
-
-Kohl & Neuman                                                  [Page 62]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   EncKrbPrivPart ::=   [APPLICATION 28] SEQUENCE {
-                user-data[0]              OCTET STRING,
-                timestamp[1]              KerberosTime OPTIONAL,
-                usec[2]                   INTEGER OPTIONAL,
-                seq-number[3]             INTEGER OPTIONAL,
-                s-address[4]              HostAddress, -- sender's addr
-                r-address[5]              HostAddress OPTIONAL
-                                                      -- recip's addr
-   }
-
-   NOTE: In EncKrbPrivPart, the application code in the encrypted part
-   of a message provides an additional check that the message was
-   decrypted properly.
-
-   pvno and msg-type These fields are described above in section 5.4.1.
-             msg-type is KRB_PRIV.
-
-   enc-part  This field holds an encoding of the EncKrbPrivPart sequence
-             encrypted under the session key (If supported by the
-             encryption method in use, an initialization vector may be
-             passed to the encryption procedure, in order to achieve
-             proper cipher chaining.  The initialization vector might
-             come from the last block of the ciphertext from the
-             previous KRB_PRIV message, but it is the application's
-             choice whether or not to use such an initialization vector.
-             If left out, the default initialization vector for the
-             encryption algorithm will be used.).  This encrypted
-             encoding is used for the enc-part field of the KRB-PRIV
-             message.  See section 6 for the format of the ciphertext.
-
-   user-data, timestamp, usec, s-address and r-address These fields are
-             described above in section 5.6.1.
-
-   seq-number This field is described above in section 5.3.2.
-
-5.8.  KRB_CRED message specification
-
-   This section specifies the format of a message that can be used to
-   send Kerberos credentials from one principal to another.  It is
-   presented here to encourage a common mechanism to be used by
-   applications when forwarding tickets or providing proxies to
-   subordinate servers.  It presumes that a session key has already been
-   exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages.
-
-5.8.1. KRB_CRED definition
-
-   The KRB_CRED message contains a sequence of tickets to be sent and
-   information needed to use the tickets, including the session key from
-
-
-
-Kohl & Neuman                                                  [Page 63]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   each.  The information needed to use the tickets is encryped under an
-   encryption key previously exchanged.  The message fields are:
-
-   KRB-CRED         ::= [APPLICATION 22]   SEQUENCE {
-                    pvno[0]                INTEGER,
-                    msg-type[1]            INTEGER, -- KRB_CRED
-                    tickets[2]             SEQUENCE OF Ticket,
-                    enc-part[3]            EncryptedData
-   }
-
-   EncKrbCredPart   ::= [APPLICATION 29]   SEQUENCE {
-                    ticket-info[0]         SEQUENCE OF KrbCredInfo,
-                    nonce[1]               INTEGER OPTIONAL,
-                    timestamp[2]           KerberosTime OPTIONAL,
-                    usec[3]                INTEGER OPTIONAL,
-                    s-address[4]           HostAddress OPTIONAL,
-                    r-address[5]           HostAddress OPTIONAL
-   }
-
-   KrbCredInfo      ::=                    SEQUENCE {
-                    key[0]                 EncryptionKey,
-                    prealm[1]              Realm OPTIONAL,
-                    pname[2]               PrincipalName OPTIONAL,
-                    flags[3]               TicketFlags OPTIONAL,
-                    authtime[4]            KerberosTime OPTIONAL,
-                    starttime[5]           KerberosTime OPTIONAL,
-                    endtime[6]             KerberosTime OPTIONAL
-                    renew-till[7]          KerberosTime OPTIONAL,
-                    srealm[8]              Realm OPTIONAL,
-                    sname[9]               PrincipalName OPTIONAL,
-                    caddr[10]              HostAddresses OPTIONAL
-   }
-
-
-   pvno and msg-type These fields are described above in section 5.4.1.
-             msg-type is KRB_CRED.
-
-   tickets
-               These are the tickets obtained from the KDC specifically
-             for use by the intended recipient.  Successive tickets are
-             paired with the corresponding KrbCredInfo sequence from the
-             enc-part of the KRB-CRED message.
-
-   enc-part  This field holds an encoding of the EncKrbCredPart sequence
-             encrypted under the session key shared between the sender
-             and the intended recipient.  This encrypted encoding is
-             used for the enc-part field of the KRB-CRED message.  See
-             section 6 for the format of the ciphertext.
-
-
-
-Kohl & Neuman                                                  [Page 64]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   nonce     If practical, an application may require the inclusion of a
-             nonce generated by the recipient of the message. If the
-             same value is included as the nonce in the message, it
-             provides evidence that the message is fresh and has not
-             been replayed by an attacker.  A nonce must never be re-
-             used; it should be generated randomly by the recipient of
-             the message and provided to the sender of the mes  sage in
-             an application specific manner.
-
-   timestamp and usec These fields specify the time that the KRB-CRED
-             message was generated.  The time is used to provide
-             assurance that the message is fresh.
-
-   s-address and r-address These fields are described above in section
-             5.6.1.  They are used optionally to provide additional
-             assurance of the integrity of the KRB-CRED message.
-
-   key       This field exists in the corresponding ticket passed by the
-             KRB-CRED message and is used to pass the session key from
-             the sender to the intended recipient.  The field's encoding
-             is described in section 6.2.
-
-   The following fields are optional.   If present, they can be
-   associated with the credentials in the remote ticket file.  If left
-   out, then it is assumed that the recipient of the credentials already
-   knows their value.
-
-   prealm and pname The name and realm of the delegated principal
-             identity.
-
-   flags, authtime,  starttime,  endtime, renew-till,  srealm, sname,
-             and caddr These fields contain the values of the
-             corresponding fields from the ticket found in the ticket
-             field.  Descriptions of the fields are identical to the
-             descriptions in the KDC-REP message.
-
-5.9.  Error message specification
-
-   This section specifies the format for the KRB_ERROR message.  The
-   fields included in the message are intended to return as much
-   information as possible about an error.  It is not expected that all
-   the information required by the fields will be available for all
-   types of errors.  If the appropriate information is not available
-   when the message is composed, the corresponding field will be left
-   out of the message.
-
-   Note that since the KRB_ERROR message is not protected by any
-   encryption, it is quite possible for an intruder to synthesize or
-
-
-
-Kohl & Neuman                                                  [Page 65]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   modify such a message.  In particular, this means that the client
-   should not use any fields in this message for security-critical
-   purposes, such as setting a system clock or generating a fresh
-   authenticator.  The message can be useful, however, for advising a
-   user on the reason for some failure.
-
-5.9.1. KRB_ERROR definition
-
-   The KRB_ERROR message consists of the following fields:
-
-   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
-   }
-
-   pvno and msg-type These fields are described above in section 5.4.1.
-             msg-type is KRB_ERROR.
-
-   ctime     This field is described above in section 5.4.1.
-
-   cusec     This field is described above in section 5.5.2.
-
-   stime     This field contains the current time on the server.  It is
-             of type KerberosTime.
-
-   susec     This field contains the microsecond part of the server's
-             timestamp.  Its value ranges from 0 to 999. It appears
-             along with stime. The two fields are used in conjunction to
-             specify a reasonably accurate timestamp.
-
-   error-code This field contains the error code returned by Kerberos or
-             the server when a request fails.  To interpret the value of
-             this field see the list of error codes in section 8.
-             Implementations are encouraged to provide for national
-             language support in the display of error messages.
-
-   crealm, cname, srealm and sname These fields are described above in
-
-
-
-Kohl & Neuman                                                  [Page 66]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-             section 5.3.1.
-
-   e-text    This field contains additional text to help explain the
-             error code associated with the failed request (for example,
-             it might include a principal name which was unknown).
-
-   e-data    This field contains additional data about the error for use
-             by the application to help it recover from or handle the
-             error.  If the errorcode is KDC_ERR_PREAUTH_REQUIRED, then
-             the e-data field will contain an encoding of a sequence of
-             padata fields, each corresponding to an acceptable pre-
-             authentication method and optionally containing data for
-             the method:
-
-      METHOD-DATA ::=    SEQUENCE of PA-DATA
-
-   If the error-code is KRB_AP_ERR_METHOD, then the e-data field will
-   contain an encoding of the following sequence:
-
-      METHOD-DATA ::=    SEQUENCE {
-                         method-type[0]   INTEGER,
-                         method-data[1]   OCTET STRING OPTIONAL
-       }
-
-   method-type will indicate the required alternate method; method-data
-   will contain any required additional information.
-
-6.  Encryption and Checksum Specifications
-
-   The Kerberos protocols described in this document are designed to use
-   stream encryption ciphers, which can be simulated using commonly
-   available block encryption ciphers, such as the Data Encryption
-   Standard [11], in conjunction with block chaining and checksum
-   methods [12].  Encryption is used to prove the identities of the
-   network entities participating in message exchanges.  The Key
-   Distribution Center for each realm is trusted by all principals
-   registered in that realm to store a secret key in confidence.  Proof
-   of knowledge of this secret key is used to verify the authenticity of
-   a principal.
-
-   The KDC uses the principal's secret key (in the AS exchange) or a
-   shared session key (in the TGS exchange) to encrypt responses to
-   ticket requests; the ability to obtain the secret key or session key
-   implies the knowledge of the appropriate keys and the identity of the
-   KDC. The ability of a principal to decrypt the KDC response and
-   present a Ticket and a properly formed Authenticator (generated with
-   the session key from the KDC response) to a service verifies the
-   identity of the principal; likewise the ability of the service to
-
-
-
-Kohl & Neuman                                                  [Page 67]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   extract the session key from the Ticket and prove its knowledge
-   thereof in a response verifies the identity of the service.
-
-   The Kerberos protocols generally assume that the encryption used is
-   secure from cryptanalysis; however, in some cases, the order of
-   fields in the encrypted portions of messages are arranged to minimize
-   the effects of poorly chosen keys.  It is still important to choose
-   good keys.  If keys are derived from user-typed passwords, those
-   passwords need to be well chosen to make brute force attacks more
-   difficult.  Poorly chosen keys still make easy targets for intruders.
-
-   The following sections specify the encryption and checksum mechanisms
-   currently defined for Kerberos.  The encodings, chaining, and padding
-   requirements for each are described.  For encryption methods, it is
-   often desirable to place random information (often referred to as a
-   confounder) at the start of the message.  The requirements for a
-   confounder are specified with each encryption mechanism.
-
-   Some encryption systems use a block-chaining method to improve the
-   the security characteristics of the ciphertext.  However, these
-   chaining methods often don't provide an integrity check upon
-   decryption.  Such systems (such as DES in CBC mode) must be augmented
-   with a checksum of the plaintext which can be verified at decryption
-   and used to detect any tampering or damage.  Such checksums should be
-   good at detecting burst errors in the input.  If any damage is
-   detected, the decryption routine is expected to return an error
-   indicating the failure of an integrity check. Each encryption type is
-   expected to provide and verify an appropriate checksum. The
-   specification of each encryption method sets out its checksum
-   requirements.
-
-   Finally, where a key is to be derived from a user's password, an
-   algorithm for converting the password to a key of the appropriate
-   type is included.  It is desirable for the string to key function to
-   be one-way, and for the mapping to be different in different realms.
-   This is important because users who are registered in more than one
-   realm will often use the same password in each, and it is desirable
-   that an attacker compromising the Kerberos server in one realm not
-   obtain or derive the user's key in another.
-
-   For a discussion of the integrity characteristics of the candidate
-   encryption and checksum methods considered for Kerberos, the the
-   reader is referred to [13].
-
-6.1.  Encryption Specifications
-
-   The following ASN.1 definition describes all encrypted messages.  The
-   enc-part field which appears in the unencrypted part of messages in
-
-
-
-Kohl & Neuman                                                  [Page 68]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   section 5 is a sequence consisting of an encryption type, an optional
-   key version number, and the ciphertext.
-
-   EncryptedData ::=   SEQUENCE {
-                       etype[0]     INTEGER, -- EncryptionType
-                       kvno[1]      INTEGER OPTIONAL,
-                       cipher[2]    OCTET STRING -- ciphertext
-   }
-
-   etype     This field identifies which encryption algorithm was used
-             to encipher the cipher.  Detailed specifications for
-             selected encryption types appear later in this section.
-
-   kvno      This field contains the version number of the key under
-             which data is encrypted.  It is only present in messages
-             encrypted under long lasting keys, such as principals'
-             secret keys.
-
-   cipher    This field contains the enciphered text, encoded as an
-             OCTET STRING.
-
-   The cipher field is generated by applying the specified encryption
-   algorithm to data composed of the message and algorithm-specific
-   inputs.  Encryption mechanisms defined for use with Kerberos must
-   take sufficient measures to guarantee the integrity of the plaintext,
-   and we recommend they also take measures to protect against
-   precomputed dictionary attacks.  If the encryption algorithm is not
-   itself capable of doing so, the protections can often be enhanced by
-   adding a checksum and a confounder.
-
-   The suggested format for the data to be encrypted includes a
-   confounder, a checksum, the encoded plaintext, and any necessary
-   padding.  The msg-seq field contains the part of the protocol message
-   described in section 5 which is to be encrypted.  The confounder,
-   checksum, and padding are all untagged and untyped, and their length
-   is exactly sufficient to hold the appropriate item.  The type and
-   length is implicit and specified by the particular encryption type
-   being used (etype).  The format for the data to be encrypted is
-   described in the following diagram:
-
-         +-----------+----------+-------------+-----+
-         |confounder |   check  |   msg-seq   | pad |
-         +-----------+----------+-------------+-----+
-
-   The format cannot be described in ASN.1, but for those who prefer an
-   ASN.1-like notation:
-
-
-
-
-
-Kohl & Neuman                                                  [Page 69]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-CipherText ::=   ENCRYPTED       SEQUENCE {
-         confounder[0]   UNTAGGED OCTET STRING(conf_length)     OPTIONAL,
-         check[1]        UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
-         msg-seq[2]      MsgSequence,
-         pad             UNTAGGED OCTET STRING(pad_length) OPTIONAL
-}
-
-   In the above specification, UNTAGGED OCTET STRING(length) is the
-   notation for an octet string with its tag and length removed.  It is
-   not a valid ASN.1 type.  The tag bits and length must be removed from
-   the confounder since the purpose of the confounder is so that the
-   message starts with random data, but the tag and its length are
-   fixed.  For other fields, the length and tag would be redundant if
-   they were included because they are specified by the encryption type.
-
-   One generates a random confounder of the appropriate length, placing
-   it in confounder; zeroes out check; calculates the appropriate
-   checksum over confounder, check, and msg-seq, placing the result in
-   check; adds the necessary padding; then encrypts using the specified
-   encryption type and the appropriate key.
-
-   Unless otherwise specified, a definition of an encryption algorithm
-   that specifies a checksum, a length for the confounder field, or an
-   octet boundary for padding uses this ciphertext format (The ordering
-   of the fields in the CipherText is important.  Additionally, messages
-   encoded in this format must include a length as part of the msg-seq
-   field.  This allows the recipient to verify that the message has not
-   been truncated.  Without a length, an attacker could use a chosen
-   plaintext attack to generate a message which could be truncated,
-   while leaving the checksum intact.  Note that if the msg-seq is an
-   encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length is
-   part of that encoding.). Those fields which are not specified will be
-   omitted.
-
-   In the interest of allowing all implementations using a particular
-   encryption type to communicate with all others using that type, the
-   specification of an encryption type defines any checksum that is
-   needed as part of the encryption process.  If an alternative checksum
-   is to be used, a new encryption type must be defined.
-
-   Some cryptosystems require additional information beyond the key and
-   the data to be encrypted. For example, DES, when used in cipher-
-   block-chaining mode, requires an initialization vector.  If required,
-   the description for each encryption type must specify the source of
-   such additional information.
-
-
-
-
-
-
-Kohl & Neuman                                                  [Page 70]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-6.2.  Encryption Keys
-
-   The sequence below shows the encoding of an encryption key:
-
-          EncryptionKey ::=   SEQUENCE {
-                              keytype[0]    INTEGER,
-                              keyvalue[1]   OCTET STRING
-          }
-
-   keytype   This field specifies the type of encryption key that
-             follows in the keyvalue field.  It will almost always
-             correspond to the encryption algorithm used to generate the
-             EncryptedData, though more than one algorithm may use the
-             same type of key (the mapping is many to one).  This might
-             happen, for example, if the encryption algorithm uses an
-             alternate checksum algorithm for an integrity check, or a
-             different chaining mechanism.
-
-   keyvalue  This field contains the key itself, encoded as an octet
-             string.
-
-   All negative values for the  encryption key type are reserved for
-   local use.  All non-negative values are reserved for officially
-   assigned type fields and interpretations.
-
-6.3.  Encryption Systems
-
-6.3.1. The NULL Encryption System (null)
-
-   If no encryption is in use, the encryption system is said to be the
-   NULL encryption system.  In the NULL encryption system there is no
-   checksum, confounder or padding.  The ciphertext is simply the
-   plaintext.  The NULL Key is used by the null encryption system and is
-   zero octets in length, with keytype zero (0).
-
-6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)
-
-   The des-cbc-crc encryption mode encrypts information under the Data
-   Encryption Standard [11] using the cipher block chaining mode [12].
-   A CRC-32 checksum (described in ISO 3309 [14]) is applied to the
-   confounder and message sequence (msg-seq) and placed in the cksum
-   field.  DES blocks are 8 bytes.  As a result, the data to be
-   encrypted (the concatenation of confounder, checksum, and message)
-   must be padded to an 8 byte boundary before encryption.  The details
-   of the encryption of this data are identical to those for the des-
-   cbc-md5 encryption mode.
-
-   Note that, since the CRC-32 checksum is not collisionproof, an
-
-
-
-Kohl & Neuman                                                  [Page 71]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   attacker could use a probabilistic chosenplaintext attack to generate
-   a valid message even if a confounder is used [13]. The use of
-   collision-proof checksums is recommended for environments where such
-   attacks represent a significant threat.  The use of the CRC-32 as the
-   checksum for ticket or authenticator is no longer mandated as an
-   interoperability requirement for Kerberos Version 5 Specification 1
-   (See section 9.1 for specific details).
-
-6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)
-
-   The des-cbc-md4 encryption mode encrypts information under the Data
-   Encryption Standard [11] using the cipher block chaining mode [12].
-   An MD4 checksum (described in [15]) is applied to the confounder and
-   message sequence (msg-seq) and placed in the cksum field.  DES blocks
-   are 8 bytes.  As a result, the data to be encrypted (the
-   concatenation of confounder, checksum, and message) must be padded to
-   an 8 byte boundary before encryption.  The details of the encryption
-   of this data are identical to those for the descbc-md5 encryption
-   mode.
-
-6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)
-
-   The des-cbc-md5 encryption mode encrypts information under the Data
-   Encryption Standard [11] using the cipher block chaining mode [12].
-   An MD5 checksum (described in [16]) is applied to the confounder and
-   message sequence (msg-seq) and placed in the cksum field.  DES blocks
-   are 8 bytes.  As a result, the data to be encrypted (the
-   concatenation of confounder, checksum, and message) must be padded to
-   an 8 byte boundary before encryption.
-
-   Plaintext and DES ciphtertext are encoded as 8-octet blocks which are
-   concatenated to make the 64-bit inputs for the DES algorithms.  The
-   first octet supplies the 8 most significant bits (with the octet's
-   MSbit used as the DES input block's MSbit, etc.), the second octet
-   the next 8 bits, ..., and the eighth octet supplies the 8 least
-   significant bits.
-
-   Encryption under DES using cipher block chaining requires an
-   additional input in the form of an initialization vector.  Unless
-   otherwise specified, zero should be used as the initialization
-   vector.  Kerberos' use of DES requires an 8-octet confounder.
-
-   The DES specifications identify some "weak" and "semiweak" keys;
-   those keys shall not be used for encrypting messages for use in
-   Kerberos.  Additionally, because of the way that keys are derived for
-   the encryption of checksums, keys shall not be used that yield "weak"
-   or "semi-weak" keys when eXclusive-ORed with the constant
-   F0F0F0F0F0F0F0F0.
-
-
-
-Kohl & Neuman                                                  [Page 72]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   A DES key is 8 octets of data, with keytype one (1).  This consists
-   of 56 bits of key, and 8 parity bits (one per octet).  The key is
-   encoded as a series of 8 octets written in MSB-first order. The bits
-   within the key are also encoded in MSB order.  For example, if the
-   encryption key is:
-   (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
-   B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the
-   parity bits, the first octet of the key would be B1,B2,...,B7,P1
-   (with B1 as the MSbit).  [See the FIPS 81 introduction for
-   reference.]
-
-   To generate a DES key from a text string (password), the text string
-   normally must have the realm and each component of the principal's
-   name appended(In some cases, it may be necessary to use a different
-   "mix-in" string for compatibility reasons; see the discussion of
-   padata in section 5.4.2.), then padded with ASCII nulls to an 8 byte
-   boundary.  This string is then fan-folded and eXclusive-ORed with
-   itself to form an 8 byte DES key.  The parity is corrected on the
-   key, and it is used to generate a DES CBC checksum on the initial
-   string (with the realm and name appended).  Next, parity is corrected
-   on the CBC checksum.  If the result matches a "weak" or "semiweak"
-   key as described in the DES specification, it is eXclusive-ORed with
-   the constant 00000000000000F0.  Finally, the result is returned as
-   the key.  Pseudocode follows:
-
-        string_to_key(string,realm,name) {
-             odd = 1;
-             s = string + realm;
-             for(each component in name) {
-                  s = s + component;
-             }
-             tempkey = NULL;
-             pad(s); /* with nulls to 8 byte boundary */
-             for(8byteblock in s) {
-                  if(odd == 0)  {
-                      odd = 1;
-                      reverse(8byteblock)
-                  }
-                  else odd = 0;
-                  tempkey = tempkey XOR 8byteblock;
-             }
-             fixparity(tempkey);
-             key = DES-CBC-check(s,tempkey);
-             fixparity(key);
-             if(is_weak_key_key(key))
-                  key = key XOR 0xF0;
-             return(key);
-        }
-
-
-
-Kohl & Neuman                                                  [Page 73]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-6.4.  Checksums
-
-   The following is the ASN.1 definition used for a checksum:
-
-            Checksum ::=   SEQUENCE {
-                           cksumtype[0]   INTEGER,
-                           checksum[1]    OCTET STRING
-            }
-
-   cksumtype This field indicates the algorithm used to generate the
-             accompanying checksum.
-
-   checksum  This field contains the checksum itself, encoded
-             as an octet string.
-
-   Detailed specification of selected checksum types appear later in
-   this section.  Negative values for the checksum type are reserved for
-   local use.  All non-negative values are reserved for officially
-   assigned type fields and interpretations.
-
-   Checksums used by Kerberos can be classified by two properties:
-   whether they are collision-proof, and whether they are keyed.  It is
-   infeasible to find two plaintexts which generate the same checksum
-   value for a collision-proof checksum.  A key is required to perturb
-   or initialize the algorithm in a keyed checksum.  To prevent
-   message-stream modification by an active attacker, unkeyed checksums
-   should only be used when the checksum and message will be
-   subsequently encrypted (e.g., the checksums defined as part of the
-   encryption algorithms covered earlier in this section).  Collision-
-   proof checksums can be made tamper-proof as well if the checksum
-   value is encrypted before inclusion in a message.  In such cases, the
-   composition of the checksum and the encryption algorithm must be
-   considered a separate checksum algorithm (e.g., RSA-MD5 encrypted
-   using DES is a new checksum algorithm of type RSA-MD5-DES).  For most
-   keyed checksums, as well as for the encrypted forms of collisionproof
-   checksums, Kerberos prepends a confounder before the checksum is
-   calculated.
-
-6.4.1. The CRC-32 Checksum (crc32)
-
-   The CRC-32 checksum calculates a checksum based on a cyclic
-   redundancy check as described in ISO 3309 [14].  The resulting
-   checksum is four (4) octets in length.  The CRC-32 is neither keyed
-   nor collision-proof.  The use of this checksum is not recommended.
-   An attacker using a probabilistic chosen-plaintext attack as
-   described in [13] might be able to generate an alternative message
-   that satisfies the checksum.  The use of collision-proof checksums is
-   recommended for environments where such attacks represent a
-
-
-
-Kohl & Neuman                                                  [Page 74]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   significant threat.
-
-6.4.2. The RSA MD4 Checksum (rsa-md4)
-
-   The RSA-MD4 checksum calculates a checksum using the RSA MD4
-   algorithm [15].  The algorithm takes as input an input message of
-   arbitrary length and produces as output a 128-bit (16 octet)
-   checksum.  RSA-MD4 is believed to be collision-proof.
-
-6.4.3. RSA MD4 Cryptographic Checksum Using DES (rsa-md4des)
-
-   The RSA-MD4-DES checksum calculates a keyed collisionproof checksum
-   by prepending an 8 octet confounder before the text, applying the RSA
-   MD4 checksum algorithm, and encrypting the confounder and the
-   checksum using DES in cipher-block-chaining (CBC) mode using a
-   variant of the key, where the variant is computed by eXclusive-ORing
-   the key with the constant F0F0F0F0F0F0F0F0 (A variant of the key is
-   used to limit the use of a key to a particular function, separating
-   the functions of generating a checksum from other encryption
-   performed using the session key.  The constant F0F0F0F0F0F0F0F0 was
-   chosen because it maintains key parity.  The properties of DES
-   precluded the use of the complement.  The same constant is used for
-   similar purpose in the Message Integrity Check in the Privacy
-   Enhanced Mail standard.).  The initialization vector should be zero.
-   The resulting checksum is 24 octets long (8 octets of which are
-   redundant).  This checksum is tamper-proof and believed to be
-   collision-proof.
-
-   The DES specifications identify some "weak keys"; those keys shall
-   not be used for generating RSA-MD4 checksums for use in Kerberos.
-
-   The format for the checksum is described in the following diagram:
-
-      +--+--+--+--+--+--+--+--
-      |  des-cbc(confounder
-      +--+--+--+--+--+--+--+--
-
-                    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-                        rsa-md4(confounder+msg),key=var(key),iv=0)  |
-                    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   The format cannot be described in ASN.1, but for those who prefer an
-   ASN.1-like notation:
-
-   rsa-md4-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                              confounder[0]   UNTAGGED OCTET STRING(8),
-                              check[1]        UNTAGGED OCTET STRING(16)
-   }
-
-
-
-Kohl & Neuman                                                  [Page 75]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-6.4.4. The RSA MD5 Checksum (rsa-md5)
-
-   The RSA-MD5 checksum calculates a checksum using the RSA MD5
-   algorithm [16].  The algorithm takes as input an input message of
-   arbitrary length and produces as output a 128-bit (16 octet)
-   checksum.  RSA-MD5 is believed to be collision-proof.
-
-6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5des)
-
-   The RSA-MD5-DES checksum calculates a keyed collisionproof checksum
-   by prepending an 8 octet confounder before the text, applying the RSA
-   MD5 checksum algorithm, and encrypting the confounder and the
-   checksum using DES in cipher-block-chaining (CBC) mode using a
-   variant of the key, where the variant is computed by eXclusive-ORing
-   the key with the constant F0F0F0F0F0F0F0F0.  The initialization
-   vector should be zero.  The resulting checksum is 24 octets long (8
-   octets of which are redundant).  This checksum is tamper-proof and
-   believed to be collision-proof.
-
-   The DES specifications identify some "weak keys"; those keys shall
-   not be used for encrypting RSA-MD5 checksums for use in Kerberos.
-
-   The format for the checksum is described in the following diagram:
-
-      +--+--+--+--+--+--+--+--
-      |  des-cbc(confounder
-      +--+--+--+--+--+--+--+--
-
-                     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-                         rsa-md5(confounder+msg),key=var(key),iv=0)  |
-                     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   The format cannot be described in ASN.1, but for those who prefer an
-   ASN.1-like notation:
-
-   rsa-md5-des-checksum ::=   ENCRYPTED       UNTAGGED SEQUENCE {
-                              confounder[0]   UNTAGGED OCTET STRING(8),
-                              check[1]        UNTAGGED OCTET STRING(16)
-   }
-
-6.4.6. DES cipher-block chained checksum (des-mac)
-
-   The DES-MAC checksum is computed by prepending an 8 octet confounder
-   to the plaintext, performing a DES CBC-mode encryption on the result
-   using the key and an initialization vector of zero, taking the last
-   block of the ciphertext, prepending the same confounder and
-   encrypting the pair using DES in cipher-block-chaining (CBC) mode
-   using a a variant of the key, where the variant is computed by
-
-
-
-Kohl & Neuman                                                  [Page 76]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   eXclusive-ORing the key with the constant F0F0F0F0F0F0F0F0.  The
-   initialization vector should be zero.  The resulting checksum is 128
-   bits (16 octets) long, 64 bits of which are redundant. This checksum
-   is tamper-proof and collision-proof.
-
-   The format for the checksum is described in the following diagram:
-
-      +--+--+--+--+--+--+--+--
-      |   des-cbc(confounder
-      +--+--+--+--+--+--+--+--
-
-                     +-----+-----+-----+-----+-----+-----+-----+-----+
-                       des-mac(conf+msg,iv=0,key),key=var(key),iv=0) |
-                     +-----+-----+-----+-----+-----+-----+-----+-----+
-
-   The format cannot be described in ASN.1, but for those who prefer an
-   ASN.1-like notation:
-
-   des-mac-checksum ::=    ENCRYPTED       UNTAGGED SEQUENCE {
-                           confounder[0]   UNTAGGED OCTET STRING(8),
-                           check[1]        UNTAGGED OCTET STRING(8)
-   }
-
-   The DES specifications identify some "weak" and "semiweak" keys;
-   those keys shall not be used for generating DES-MAC checksums for use
-   in Kerberos, nor shall a key be used whose veriant is "weak" or
-   "semi-weak".
-
-6.4.7. RSA MD4 Cryptographic Checksum Using DES alternative
-       (rsa-md4-des-k)
-
-   The RSA-MD4-DES-K checksum calculates a keyed collision-proof
-   checksum by applying the RSA MD4 checksum algorithm and encrypting
-   the results using DES in cipherblock-chaining (CBC) mode using a DES
-   key as both key and initialization vector. The resulting checksum is
-   16 octets long. This checksum is tamper-proof and believed to be
-   collision-proof.  Note that this checksum type is the old method for
-   encoding the RSA-MD4-DES checksum and it is no longer recommended.
-
-6.4.8. DES cipher-block chained checksum alternative (desmac-k)
-
-   The DES-MAC-K checksum is computed by performing a DES CBC-mode
-   encryption of the plaintext, and using the last block of the
-   ciphertext as the checksum value. It is keyed with an encryption key
-   and an initialization vector; any uses which do not specify an
-   additional initialization vector will use the key as both key and
-   initialization vector.  The resulting checksum is 64 bits (8 octets)
-   long. This checksum is tamper-proof and collision-proof.  Note that
-
-
-
-Kohl & Neuman                                                  [Page 77]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   this checksum type is the old method for encoding the DESMAC checksum
-   and it is no longer recommended.
-
-   The DES specifications identify some "weak keys"; those keys shall
-   not be used for generating DES-MAC checksums for use in Kerberos.
-
-7.  Naming Constraints
-
-7.1.  Realm Names
-
-   Although realm names are encoded as GeneralStrings and although a
-   realm can technically select any name it chooses, interoperability
-   across realm boundaries requires agreement on how realm names are to
-   be assigned, and what information they imply.
-
-   To enforce these conventions, each realm must conform to the
-   conventions itself, and it must require that any realms with which
-   inter-realm keys are shared also conform to the conventions and
-   require the same from its neighbors.
-
-   There are presently four styles of realm names: domain, X500, other,
-   and reserved.  Examples of each style follow:
-
-        domain:   host.subdomain.domain (example)
-          X500:   C=US/O=OSF (example)
-         other:   NAMETYPE:rest/of.name=without-restrictions (example)
-      reserved:   reserved, but will not conflict with above
-
-   Domain names must look like domain names: they consist of components
-   separated by periods (.) and they contain neither colons (:) nor
-   slashes (/).
-
-   X.500 names contain an equal (=) and cannot contain a colon (:)
-   before the equal.  The realm names for X.500 names will be string
-   representations of the names with components separated by slashes.
-   Leading and trailing slashes will not be included.
-
-   Names that fall into the other category must begin with a prefix that
-   contains no equal (=) or period (.) and the prefix must be followed
-   by a colon (:) and the rest of the name. All prefixes must be
-   assigned before they may be used.  Presently none are assigned.
-
-   The reserved category includes strings which do not fall into the
-   first three categories.  All names in this category are reserved. It
-   is unlikely that names will be assigned to this category unless there
-   is a very strong argument for not using the "other" category.
-
-   These rules guarantee that there will be no conflicts between the
-
-
-
-Kohl & Neuman                                                  [Page 78]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   various name styles.  The following additional constraints apply to
-   the assignment of realm names in the domain and X.500 categories: the
-   name of a realm for the domain or X.500 formats must either be used
-   by the organization owning (to whom it was assigned) an Internet
-   domain name or X.500 name, or in the case that no such names are
-   registered, authority to use a realm name may be derived from the
-   authority of the parent realm.  For example, if there is no domain
-   name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
-   authorize the creation of a realm with that name.
-
-   This is acceptable because the organization to which the parent is
-   assigned is presumably the organization authorized to assign names to
-   its children in the X.500 and domain name systems as well.  If the
-   parent assigns a realm name without also registering it in the domain
-   name or X.500 hierarchy, it is the parent's responsibility to make
-   sure that there will not in the future exists a name identical to the
-   realm name of the child unless it is assigned to the same entity as
-   the realm name.
-
-7.2.  Principal Names
-
-   As was the case for realm names, conventions are needed to ensure
-   that all agree on what information is implied by a principal name.
-   The name-type field that is part of the principal name indicates the
-   kind of information implied by the name.  The name-type should be
-   treated as a hint.  Ignoring the name type, no two names can be the
-   same (i.e., at least one of the components, or the realm, must be
-   different).  This constraint may be eliminated in the future.  The
-   following name types are defined:
-
-      name-type      value   meaning
-      NT-UNKNOWN       0     Name type not known
-      NT-PRINCIPAL     1     Just the name of the principal as in
-                             DCE, or for users
-      NT-SRV-INST      2     Service and other unique instance (krbtgt)
-      NT-SRV-HST       3     Service with host name as instance
-                             (telnet, rcommands)
-      NT-SRV-XHST      4     Service with host as remaining components
-      NT-UID           5     Unique ID
-
-   When a name implies no information other than its uniqueness at a
-   particular time the name type PRINCIPAL should be used.  The
-   principal name type should be used for users, and it might also be
-   used for a unique server.  If the name is a unique machine generated
-   ID that is guaranteed never to be reassigned then the name type of
-   UID should be used (note that it is generally a bad idea to reassign
-   names of any type since stale entries might remain in access control
-   lists).
-
-
-
-Kohl & Neuman                                                  [Page 79]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   If the first component of a name identifies a service and the
-   remaining components identify an instance of the service in a server
-   specified manner, then the name type of SRV-INST should be used.  An
-   example of this name type is the Kerberos ticket-granting ticket
-   which has a first component of krbtgt and a second component
-   identifying the realm for which the ticket is valid.
-
-   If instance is a single component following the service name and the
-   instance identifies the host on which the server is running, then the
-   name type SRV-HST should be used. This type is typically used for
-   Internet services such as telnet and the Berkeley R commands.  If the
-   separate components of the host name appear as successive components
-   following the name of the service, then the name type SRVXHST should
-   be used.  This type might be used to identify servers on hosts with
-   X.500 names where the slash (/) might otherwise be ambiguous.
-
-   A name type of UNKNOWN should be used when the form of the name is
-   not known. When comparing names, a name of type UNKNOWN will match
-   principals authenticated with names of any type.  A principal
-   authenticated with a name of type UNKNOWN, however, will only match
-   other names of type UNKNOWN.
-
-   Names of any type with an initial component of "krbtgt" are reserved
-   for the Kerberos ticket granting service.  See section 8.2.3 for the
-   form of such names.
-
-7.2.1. Name of server principals
-
-   The principal identifier for a server on a host will generally be
-   composed of two parts: (1) the realm of the KDC with which the server
-   is registered, and (2) a two-component name of type NT-SRV-HST if the
-   host name is an Internet domain name or a multi-component name of
-   type NT-SRV-XHST if the name of the host is of a form such as X.500
-   that allows slash (/) separators.  The first component of the two- or
-   multi-component name will identify the service and the latter
-   components will identify the host.  Where the name of the host is not
-   case sensitive (for example, with Internet domain names) the name of
-   the host must be lower case.  For services such as telnet and the
-   Berkeley R commands which run with system privileges, the first
-   component will be the string "host" instead of a service specific
-   identifier.
-
-8.  Constants and other defined values
-
-8.1.  Host address types
-
-   All negative values for the host address type are reserved for local
-   use.  All non-negative values are reserved for officially assigned
-
-
-
-Kohl & Neuman                                                  [Page 80]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   type fields and interpretations.
-
-   The values of the types for the following addresses are chosen to
-   match the defined address family constants in the Berkeley Standard
-   Distributions of Unix.  They can be found in <sys/socket.h> with
-   symbolic names AF_xxx (where xxx is an abbreviation of the address
-   family name).
-
-
-   Internet addresses
-
-      Internet addresses are 32-bit (4-octet) quantities, encoded in MSB
-      order.  The type of internet addresses is two (2).
-
-   CHAOSnet addresses
-
-      CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB
-      order.  The type of CHAOSnet addresses is five (5).
-
-   ISO addresses
-
-      ISO addresses are variable-length.  The type of ISO addresses is
-      seven (7).
-
-   Xerox Network Services (XNS) addresses
-
-      XNS addresses are 48-bit (6-octet) quantities, encoded in MSB
-      order.  The type of XNS addresses is six (6).
-
-   AppleTalk Datagram Delivery Protocol (DDP) addresses
-
-      AppleTalk DDP addresses consist of an 8-bit node number and a 16-
-      bit network number.  The first octet of the address is the node
-      number; the remaining two octets encode the network number in MSB
-      order. The type of AppleTalk DDP addresses is sixteen (16).
-
-   DECnet Phase IV addresses
-
-      DECnet Phase IV addresses are 16-bit addresses, encoded in LSB
-      order.  The type of DECnet Phase IV addresses is twelve (12).
-
-8.2.  KDC messages
-
-8.2.1. IP transport
-
-   When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request
-   using IP transport, the client shall send a UDP datagram containing
-   only an encoding of the request to port 88 (decimal) at the KDC's IP
-
-
-
-Kohl & Neuman                                                  [Page 81]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   address; the KDC will respond with a reply datagram containing only
-   an encoding of the reply message (either a KRB_ERROR or a
-   KRB_KDC_REP) to the sending port at the sender's IP address.
-
-8.2.2. OSI transport
-
-   During authentication of an OSI client to and OSI server, the mutual
-   authentication of an OSI server to an OSI client, the transfer of
-   credentials from an OSI client to an OSI server, or during exchange
-   of private or integrity checked messages, Kerberos protocol messages
-   may be treated as opaque objects and the type of the authentication
-   mechanism will be:
-
-   OBJECT IDENTIFIER ::= {iso (1), org(3), dod(5),internet(1),
-                          security(5), kerberosv5(2)}
-
-   Depending on the situation, the opaque object will be an
-   authentication header (KRB_AP_REQ), an authentication reply
-   (KRB_AP_REP), a safe message (KRB_SAFE), a private message
-   (KRB_PRIV), or a credentials message (KRB_CRED).  The opaque data
-   contains an application code as specified in the ASN.1 description
-   for each message.  The application code may be used by Kerberos to
-   determine the message type.
-
-8.2.3. Name of the TGS
-
-   The principal identifier of the ticket-granting service shall be
-   composed of three parts: (1) the realm of the KDC issuing the TGS
-   ticket (2) a two-part name of type NT-SRVINST, with the first part
-   "krbtgt" and the second part the name of the realm which will accept
-   the ticket-granting ticket.  For example, a ticket-granting ticket
-   issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
-   ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
-   (realm), ("krbtgt", "ATHENA.MIT.EDU") (name).  A ticket-granting
-   ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets
-   from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU"
-   (realm), ("krbtgt", "MIT.EDU") (name).
-
-8.3.  Protocol constants and associated values
-
-   The following tables list constants used in the protocol and defines
-   their meanings.
-
-
-
-
-
-
-
-
-
-Kohl & Neuman                                                  [Page 82]
-
-RFC 1510                        Kerberos                  September 1993
-
-
----------------+-----------+----------+----------------+---------------
-Encryption type|etype value|block size|minimum pad size|confounder size
----------------+-----------+----------+----------------+---------------
-NULL                0            1              0              0
-des-cbc-crc         1            8              4              8
-des-cbc-md4         2            8              0              8
-des-cbc-md5         3            8              0              8
-
--------------------------------+-------------------+-------------
-Checksum type                  |sumtype value      |checksum size
--------------------------------+-------------------+-------------
-CRC32                           1                   4
-rsa-md4                         2                   16
-rsa-md4-des                     3                   24
-des-mac                         4                   16
-des-mac-k                       5                   8
-rsa-md4-des-k                   6                   16
-rsa-md5                         7                   16
-rsa-md5-des                     8                   24
-
--------------------------------+-----------------
-padata type                    |padata-type value
--------------------------------+-----------------
-PA-TGS-REQ                      1
-PA-ENC-TIMESTAMP                2
-PA-PW-SALT                      3
-
--------------------------------+-------------
-authorization data type        |ad-type value
--------------------------------+-------------
-reserved values                 0-63
-OSF-DCE                         64
-SESAME                          65
-
--------------------------------+-----------------
-alternate authentication type  |method-type value
--------------------------------+-----------------
-reserved values                 0-63
-ATT-CHALLENGE-RESPONSE          64
-
--------------------------------+-------------
-transited encoding type        |tr-type value
--------------------------------+-------------
-DOMAIN-X500-COMPRESS            1
-reserved values                 all others
-
-
-
-
-
-
-Kohl & Neuman                                                  [Page 83]
-
-RFC 1510                        Kerberos                  September 1993
-
-
---------------+-------+-----------------------------------------
-Label         |Value  |Meaning or MIT code
---------------+-------+-----------------------------------------
-
-pvno             5     current Kerberos protocol version number
-
-message types
-
-KRB_AS_REQ      10     Request for initial authentication
-KRB_AS_REP      11     Response to KRB_AS_REQ request
-KRB_TGS_REQ     12     Request for authentication based on TGT
-KRB_TGS_REP     13     Response to KRB_TGS_REQ request
-KRB_AP_REQ      14     application request to server
-KRB_AP_REP      15     Response to KRB_AP_REQ_MUTUAL
-KRB_SAFE        20     Safe (checksummed) application message
-KRB_PRIV        21     Private (encrypted) application message
-KRB_CRED        22     Private (encrypted) message to forward
-                       credentials
-KRB_ERROR       30     Error response
-
-name types
-
-KRB_NT_UNKNOWN   0   Name type not known
-KRB_NT_PRINCIPAL 1   Just the name of the principal as in DCE, or
-                     for users
-KRB_NT_SRV_INST  2   Service and other unique instance (krbtgt)
-KRB_NT_SRV_HST   3   Service with host name as instance (telnet,
-                     rcommands)
-KRB_NT_SRV_XHST  4   Service with host as remaining components
-KRB_NT_UID       5   Unique ID
-
-error codes
-
-KDC_ERR_NONE                   0   No error
-KDC_ERR_NAME_EXP               1   Client's entry in database has
-                                   expired
-KDC_ERR_SERVICE_EXP            2   Server's entry in database has
-                                   expired
-KDC_ERR_BAD_PVNO               3   Requested protocol version number
-                                   not supported
-KDC_ERR_C_OLD_MAST_KVNO        4   Client's key encrypted in old
-                                   master key
-KDC_ERR_S_OLD_MAST_KVNO        5   Server's key encrypted in old
-                                   master key
-KDC_ERR_C_PRINCIPAL_UNKNOWN    6   Client not found in Kerberos database
-KDC_ERR_S_PRINCIPAL_UNKNOWN    7   Server not found in Kerberos database
-KDC_ERR_PRINCIPAL_NOT_UNIQUE   8   Multiple principal entries in
-                                   database
-
-
-
-Kohl & Neuman                                                  [Page 84]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-KDC_ERR_NULL_KEY               9   The client or server has a null key
-KDC_ERR_CANNOT_POSTDATE       10   Ticket not eligible for postdating
-KDC_ERR_NEVER_VALID           11   Requested start time is later than
-                                   end time
-KDC_ERR_POLICY                12   KDC policy rejects request
-KDC_ERR_BADOPTION             13   KDC cannot accommodate requested
-                                   option
-KDC_ERR_ETYPE_NOSUPP          14   KDC has no support for encryption
-                                   type
-KDC_ERR_SUMTYPE_NOSUPP        15   KDC has no support for checksum type
-KDC_ERR_PADATA_TYPE_NOSUPP    16   KDC has no support for padata type
-KDC_ERR_TRTYPE_NOSUPP         17   KDC has no support for transited type
-KDC_ERR_CLIENT_REVOKED        18   Clients credentials have been revoked
-KDC_ERR_SERVICE_REVOKED       19   Credentials for server have been
-                                   revoked
-KDC_ERR_TGT_REVOKED           20   TGT has been revoked
-KDC_ERR_CLIENT_NOTYET         21   Client not yet valid - try again
-                                   later
-KDC_ERR_SERVICE_NOTYET        22   Server not yet valid - try again
-                                   later
-KDC_ERR_KEY_EXPIRED           23   Password has expired - change
-                                   password to reset
-KDC_ERR_PREAUTH_FAILED        24   Pre-authentication information
-                                   was invalid
-KDC_ERR_PREAUTH_REQUIRED      25   Additional pre-authentication
-                                   required*
-KRB_AP_ERR_BAD_INTEGRITY      31   Integrity check on decrypted field
-                                   failed
-KRB_AP_ERR_TKT_EXPIRED        32   Ticket expired
-KRB_AP_ERR_TKT_NYV            33   Ticket not yet valid
-KRB_AP_ERR_REPEAT             34   Request is a replay
-KRB_AP_ERR_NOT_US             35   The ticket isn't for us
-KRB_AP_ERR_BADMATCH           36   Ticket and authenticator don't match
-KRB_AP_ERR_SKEW               37   Clock skew too great
-KRB_AP_ERR_BADADDR            38   Incorrect net address
-KRB_AP_ERR_BADVERSION         39   Protocol version mismatch
-KRB_AP_ERR_MSG_TYPE           40   Invalid msg type
-KRB_AP_ERR_MODIFIED           41   Message stream modified
-KRB_AP_ERR_BADORDER           42   Message out of order
-KRB_AP_ERR_BADKEYVER          44   Specified version of key is not
-                                   available
-KRB_AP_ERR_NOKEY              45   Service key not available
-KRB_AP_ERR_MUT_FAIL           46   Mutual authentication failed
-KRB_AP_ERR_BADDIRECTION       47   Incorrect message direction
-KRB_AP_ERR_METHOD             48   Alternative authentication method
-                                   required*
-KRB_AP_ERR_BADSEQ             49   Incorrect sequence number in message
-KRB_AP_ERR_INAPP_CKSUM        50   Inappropriate type of checksum in
-
-
-
-Kohl & Neuman                                                  [Page 85]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-                                   message
-KRB_ERR_GENERIC               60   Generic error (description in e-text)
-KRB_ERR_FIELD_TOOLONG         61   Field is too long for this
-                                   implementation
-
-   *This error carries additional information in the e-data field.  The
-   contents of the e-data field for this message is described in section
-   5.9.1.
-
-9.  Interoperability requirements
-
-   Version 5 of the Kerberos protocol supports a myriad of options.
-   Among these are multiple encryption and checksum types, alternative
-   encoding schemes for the transited field, optional mechanisms for
-   pre-authentication, the handling of tickets with no addresses,
-   options for mutual authentication, user to user authentication,
-   support for proxies, forwarding, postdating, and renewing tickets,
-   the format of realm names, and the handling of authorization data.
-
-   In order to ensure the interoperability of realms, it is necessary to
-   define a minimal configuration which must be supported by all
-   implementations.  This minimal configuration is subject to change as
-   technology does. For example, if at some later date it is discovered
-   that one of the required encryption or checksum algorithms is not
-   secure, it will be replaced.
-
-9.1.  Specification 1
-
-   This section defines the first specification of these options.
-   Implementations which are configured in this way can be said to
-   support Kerberos Version 5 Specification 1 (5.1).
-
-   Encryption and checksum methods
-
-   The following encryption and checksum mechanisms must be supported.
-   Implementations may support other mechanisms as well, but the
-   additional mechanisms may only be used when communicating with
-   principals known to also support them: Encryption: DES-CBC-MD5
-   Checksums: CRC-32, DES-MAC, DES-MAC-K, and DES-MD5
-
-   Realm Names
-
-   All implementations must understand hierarchical realms in both the
-   Internet Domain and the X.500 style.  When a ticket granting ticket
-   for an unknown realm is requested, the KDC must be able to determine
-   the names of the intermediate realms between the KDCs realm and the
-   requested realm.
-
-
-
-
-Kohl & Neuman                                                  [Page 86]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   Transited field encoding
-
-   DOMAIN-X500-COMPRESS (described in section 3.3.3.1) must be
-   supported.  Alternative encodings may be supported, but they may be
-   used only when that encoding is supported by ALL intermediate realms.
-
-   Pre-authentication methods
-
-   The TGS-REQ method must be supported.  The TGS-REQ method is not used
-   on the initial request. The PA-ENC-TIMESTAMP method must be supported
-   by clients but whether it is enabled by default may be determined on
-   a realm by realm basis. If not used in the initial request and the
-   error KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENCTIMESTAMP
-   as an acceptable method, the client should retry the initial request
-   using the PA-ENC-TIMESTAMP preauthentication method. Servers need not
-   support the PAENC-TIMESTAMP method, but if not supported the server
-   should ignore the presence of PA-ENC-TIMESTAMP pre-authentication in
-   a request.
-
-   Mutual authentication
-
-   Mutual authentication (via the KRB_AP_REP message) must be supported.
-
-   Ticket addresses and flags
-
-   All KDC's must pass on tickets that carry no addresses (i.e.,  if a
-   TGT contains no addresses, the KDC will return derivative tickets),
-   but each realm may set its own policy for issuing such tickets, and
-   each application server will set its own policy with respect to
-   accepting them. By default, servers should not accept them.
-
-   Proxies and forwarded tickets must be supported.  Individual realms
-   and application servers can set their own policy on when such tickets
-   will be accepted.
-
-   All implementations must recognize renewable and postdated tickets,
-   but need not actually implement them.  If these options are not
-   supported, the starttime and endtime in the ticket shall specify a
-   ticket's entire useful life.  When a postdated ticket is decoded by a
-   server, all implementations shall make the presence of the postdated
-   flag visible to the calling server.
-
-   User-to-user authentication
-
-   Support for user to user authentication (via the ENC-TKTIN-SKEY KDC
-   option) must be provided by implementations, but individual realms
-   may decide as a matter of policy to reject such requests on a per-
-   principal or realm-wide basis.
-
-
-
-Kohl & Neuman                                                  [Page 87]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   Authorization data
-
-   Implementations must pass all authorization data subfields from
-   ticket-granting tickets to any derivative tickets unless directed to
-   suppress a subfield as part of the definition of that registered
-   subfield type (it is never incorrect to pass on a subfield, and no
-   registered subfield types presently specify suppression at the KDC).
-
-   Implementations must make the contents of any authorization data
-   subfields available to the server when a ticket is used.
-   Implementations are not required to allow clients to specify the
-   contents of the authorization data fields.
-
-9.2.  Recommended KDC values
-
-   Following is a list of recommended values for a KDC implementation,
-   based on the list of suggested configuration constants (see section
-   4.4).
-
-   minimum lifetime                5 minutes
-
-   maximum renewable lifetime      1 week
-
-   maximum ticket lifetime         1 day
-
-   empty addresses                 only when suitable restrictions appear
-                                   in authorization data
-
-   proxiable, etc.                 Allowed.
-
-10.  Acknowledgments
-
-   Early versions of this document, describing version 4 of the
-   protocol, were written by Jennifer Steiner (formerly at Project
-   Athena); these drafts provided an excellent starting point for this
-   current version 5 specification.  Many people in the Internet
-   community have contributed ideas and suggested protocol changes for
-   version 5. Notable contributions came from Ted Anderson, Steve
-   Bellovin and Michael Merritt [17], Daniel Bernstein, Mike Burrows,
-   Donald Davis, Ravi Ganesan, Morrie Gasser, Virgil Gligor, Bill
-   Griffeth, Mark Lillibridge, Mark Lomas, Steve Lunt, Piers McMahon,
-   Joe Pato, William Sommerfeld, Stuart Stubblebine, Ralph Swick, Ted
-   T'so, and Stanley Zanarotti.  Many others commented and helped shape
-   this specification into its current form.
-
-
-
-
-
-
-
-Kohl & Neuman                                                  [Page 88]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-11.  References
-
-   [1]  Miller, S., Neuman, C., Schiller, J., and  J. Saltzer, "Section
-        E.2.1: Kerberos  Authentication and Authorization System",
-        M.I.T. Project Athena, Cambridge, Massachusetts, December 21,
-        1987.
-
-   [2]  Steiner, J., Neuman, C., and J. Schiller, "Kerberos: An
-        Authentication Service for Open Network Systems", pp. 191-202 in
-        Usenix Conference Proceedings, Dallas, Texas, February, 1988.
-
-   [3]  Needham, R., and M. Schroeder, "Using Encryption for
-        Authentication in Large Networks of Computers", Communications
-        of the ACM, Vol. 21 (12), pp. 993-999, December 1978.
-
-   [4]  Denning, D., and G. Sacco, "Time stamps in Key Distribution
-        Protocols", Communications of the ACM, Vol. 24 (8), pp. 533-536,
-        August 1981.
-
-   [5]  Kohl, J., Neuman, C., and T. Ts'o, "The Evolution of the
-        Kerberos Authentication Service", in an IEEE Computer Society
-        Text soon to be published, June 1992.
-
-   [6]  Davis, D., and R. Swick, "Workstation Services and Kerberos
-        Authentication at Project Athena", Technical Memorandum TM-424,
-        MIT Laboratory for Computer Science, February 1990.
-
-   [7]  Levine, P., Gretzinger, M, Diaz, J., Sommerfeld, W., and K.
-        Raeburn, "Section E.1: Service Management System, M.I.T.
-        Project Athena, Cambridge, Mas sachusetts (1987).
-
-   [8]  CCITT, Recommendation X.509: The Directory Authentication
-        Framework, December 1988.
-
-   [9]  Neuman, C., "Proxy-Based Authorization and Accounting for
-        Distributed Systems," in Proceedings of the 13th International
-        Conference on Distributed Computing Systems", Pittsburgh, PA,
-        May 1993.
-
-   [10] Pato, J., "Using Pre-Authentication to Avoid Password Guessing
-        Attacks", Open Software Foundation DCE Request for Comments 26,
-        December 1992.
-
-   [11] National Bureau of Standards, U.S. Department of Commerce, "Data
-        Encryption Standard", Federal Information Processing Standards
-        Publication 46, Washington, DC (1977).
-
-
-
-
-
-Kohl & Neuman                                                  [Page 89]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-   [12] National Bureau of Standards, U.S. Department of Commerce, "DES
-        Modes of Operation", Federal Information Processing Standards
-        Publication 81, Springfield, VA, December 1980.
-
-   [13] Stubblebine S., and V. Gligor, "On Message Integrity in
-        Cryptographic Protocols", in Proceedings of the IEEE Symposium
-        on Research in Security and Privacy, Oakland, California, May
-        1992.
-
-   [14] International Organization for Standardization, "ISO Information
-        Processing Systems - Data Communication High-Level Data Link
-        Control Procedure - Frame Structure", IS 3309, October 1984, 3rd
-        Edition.
-
-   [15] Rivest, R., "The MD4 Message Digest Algorithm", RFC 1320, MIT
-        Laboratory for Computer Science, April 1992.
-
-   [16] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, MIT
-        Laboratory for Computer Science, April 1992.
-
-   [17] Bellovin S., and M. Merritt, "Limitations of the Kerberos
-        Authentication System", Computer Communications Review, Vol.
-        20(5), pp. 119-132, October 1990.
-
-12.  Security Considerations
-
-   Security issues are discussed throughout this memo.
-
-13.  Authors' Addresses
-
-   John Kohl
-   Digital Equipment Corporation
-   110 Spit Brook Road, M/S ZKO3-3/U14
-   Nashua, NH  03062
-
-   Phone: 603-881-2481
-   EMail: jtkohl@zk3.dec.com
-
-
-   B. Clifford Neuman
-   USC/Information Sciences Institute
-   4676 Admiralty Way #1001
-   Marina del Rey, CA 90292-6695
-
-   Phone: 310-822-1511
-   EMail: bcn@isi.edu
-
-
-
-
-
-Kohl & Neuman                                                  [Page 90]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-A.  Pseudo-code for protocol processing
-
-   This appendix provides pseudo-code describing how the messages are to
-   be constructed and interpreted by clients and servers.
-
-A.1.  KRB_AS_REQ generation
-        request.pvno := protocol version; /* pvno = 5 */
-        request.msg-type := message type; /* type = KRB_AS_REQ */
-
-        if(pa_enc_timestamp_required) then
-                request.padata.padata-type = PA-ENC-TIMESTAMP;
-                get system_time;
-                padata-body.patimestamp,pausec = system_time;
-                encrypt padata-body into request.padata.padata-value
-                        using client.key; /* derived from password */
-        endif
-
-        body.kdc-options := users's preferences;
-        body.cname := user's name;
-        body.realm := user's realm;
-        body.sname := service's name; /* usually "krbtgt",
-                                         "localrealm" */
-        if (body.kdc-options.POSTDATED is set) then
-                body.from := requested starting time;
-        else
-                omit body.from;
-        endif
-        body.till := requested end time;
-        if (body.kdc-options.RENEWABLE is set) then
-                body.rtime := requested final renewal time;
-        endif
-        body.nonce := random_nonce();
-        body.etype := requested etypes;
-        if (user supplied addresses) then
-                body.addresses := user's addresses;
-        else
-                omit body.addresses;
-        endif
-        omit body.enc-authorization-data;
-        request.req-body := body;
-
-        kerberos := lookup(name of local kerberos server (or servers));
-        send(packet,kerberos);
-
-        wait(for response);
-        if (timed_out) then
-                retry or use alternate server;
-        endif
-
-
-
-Kohl & Neuman                                                  [Page 91]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-A.2.  KRB_AS_REQ verification and KRB_AS_REP generation
-        decode message into req;
-
-        client := lookup(req.cname,req.realm);
-        server := lookup(req.sname,req.realm);
-        get system_time;
-        kdc_time := system_time.seconds;
-
-        if (!client) then
-                /* no client in Database */
-                error_out(KDC_ERR_C_PRINCIPAL_UNKNOWN);
-        endif
-        if (!server) then
-                /* no server in Database */
-                error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
-        endif
-
-        if(client.pa_enc_timestamp_required and
-           pa_enc_timestamp not present) then
-                error_out(KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP));
-        endif
-
-        if(pa_enc_timestamp present) then
-                decrypt req.padata-value into decrypted_enc_timestamp
-                        using client.key;
-                        using auth_hdr.authenticator.subkey;
-                if (decrypt_error()) then
-                        error_out(KRB_AP_ERR_BAD_INTEGRITY);
-                if(decrypted_enc_timestamp is not within allowable
-                        skew) then error_out(KDC_ERR_PREAUTH_FAILED);
-                endif
-                if(decrypted_enc_timestamp and usec is replay)
-                        error_out(KDC_ERR_PREAUTH_FAILED);
-                endif
-                add decrypted_enc_timestamp and usec to replay cache;
-        endif
-
-        use_etype := first supported etype in req.etypes;
-
-        if (no support for req.etypes) then
-                error_out(KDC_ERR_ETYPE_NOSUPP);
-        endif
-
-        new_tkt.vno := ticket version; /* = 5 */
-        new_tkt.sname := req.sname;
-        new_tkt.srealm := req.srealm;
-        reset all flags in new_tkt.flags;
-
-
-
-
-Kohl & Neuman                                                  [Page 92]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-        /* It should be noted that local policy may affect the  */
-        /* processing of any of these flags.  For example, some */
-        /* realms may refuse to issue renewable tickets         */
-
-        if (req.kdc-options.FORWARDABLE is set) then
-                set new_tkt.flags.FORWARDABLE;
-        endif
-        if (req.kdc-options.PROXIABLE is set) then
-                set new_tkt.flags.PROXIABLE;
-        endif
-        if (req.kdc-options.ALLOW-POSTDATE is set) then
-                set new_tkt.flags.ALLOW-POSTDATE;
-        endif
-        if ((req.kdc-options.RENEW is set) or
-            (req.kdc-options.VALIDATE is set) or
-            (req.kdc-options.PROXY is set) or
-            (req.kdc-options.FORWARDED is set) or
-            (req.kdc-options.ENC-TKT-IN-SKEY is set)) then
-                error_out(KDC_ERR_BADOPTION);
-        endif
-
-        new_tkt.session := random_session_key();
-        new_tkt.cname := req.cname;
-        new_tkt.crealm := req.crealm;
-        new_tkt.transited := empty_transited_field();
-
-        new_tkt.authtime := kdc_time;
-
-        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
-                                      omitted */
-        endif
-        if (req.till = 0) then
-                till := infinity;
-        else
-                till := req.till;
-        endif
-
-        new_tkt.endtime := min(till,
-                              new_tkt.starttime+client.max_life,
-                              new_tkt.starttime+server.max_life,
-                              new_tkt.starttime+max_life_for_realm);
-
-
-
-Kohl & Neuman                                                  [Page 93]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-        if ((req.kdc-options.RENEWABLE-OK is set) and
-            (new_tkt.endtime < req.till)) then
-                /* we set the RENEWABLE option for later processing */
-                set req.kdc-options.RENEWABLE;
-                req.rtime := req.till;
-        endif
-
-        if (req.rtime = 0) then
-                rtime := infinity;
-        else
-                rtime := req.rtime;
-        endif
-
-        if (req.kdc-options.RENEWABLE is set) then
-                set new_tkt.flags.RENEWABLE;
-                new_tkt.renew-till := min(rtime,
-                new_tkt.starttime+client.max_rlife,
-                new_tkt.starttime+server.max_rlife,
-                new_tkt.starttime+max_rlife_for_realm);
-        else
-                omit new_tkt.renew-till; /* only present if RENEWABLE */
-        endif
-
-        if (req.addresses) then
-                new_tkt.caddr := req.addresses;
-        else
-                omit new_tkt.caddr;
-        endif
-
-        new_tkt.authorization_data := empty_authorization_data();
-
-        encode to-be-encrypted part of ticket into OCTET STRING;
-        new_tkt.enc-part := encrypt OCTET STRING
-            using etype_for_key(server.key), server.key, server.p_kvno;
-
-
-        /* Start processing the response */
-
-        resp.pvno := 5;
-        resp.msg-type := KRB_AS_REP;
-        resp.cname := req.cname;
-        resp.crealm := req.realm;
-        resp.ticket := new_tkt;
-
-        resp.key := new_tkt.session;
-        resp.last-req := fetch_last_request_info(client);
-        resp.nonce := req.nonce;
-        resp.key-expiration := client.expiration;
-
-
-
-Kohl & Neuman                                                  [Page 94]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-        resp.flags := new_tkt.flags;
-
-        resp.authtime := new_tkt.authtime;
-        resp.starttime := new_tkt.starttime;
-        resp.endtime := new_tkt.endtime;
-
-        if (new_tkt.flags.RENEWABLE) then
-                resp.renew-till := new_tkt.renew-till;
-        endif
-
-        resp.realm := new_tkt.realm;
-        resp.sname := new_tkt.sname;
-
-        resp.caddr := new_tkt.caddr;
-
-        encode body of reply into OCTET STRING;
-
-        resp.enc-part := encrypt OCTET STRING
-                         using use_etype, client.key, client.p_kvno;
-        send(resp);
-
-A.3.  KRB_AS_REP verification
-        decode response into resp;
-
-        if (resp.msg-type = KRB_ERROR) then
-                if(error = KDC_ERR_PREAUTH_REQUIRED(PA_ENC_TIMESTAMP))
-                        then set pa_enc_timestamp_required;
-                        goto KRB_AS_REQ;
-                endif
-                process_error(resp);
-                return;
-        endif
-
-        /* On error, discard the response, and zero the session key */
-        /* from the response immediately */
-
-        key = get_decryption_key(resp.enc-part.kvno, resp.enc-part.etype,
-                                 resp.padata);
-        unencrypted part of resp := decode of decrypt of resp.enc-part
-                                using resp.enc-part.etype and key;
-        zero(key);
-
-        if (common_as_rep_tgs_rep_checks fail) then
-                destroy resp.key;
-                return error;
-        endif
-
-        if near(resp.princ_exp) then
-
-
-
-Kohl & Neuman                                                  [Page 95]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-                print(warning message);
-        endif
-        save_for_later(ticket,session,client,server,times,flags);
-
-A.4.  KRB_AS_REP and KRB_TGS_REP common checks
-        if (decryption_error() or
-            (req.cname != resp.cname) or
-            (req.realm != resp.crealm) or
-            (req.sname != resp.sname) or
-            (req.realm != resp.realm) or
-            (req.nonce != resp.nonce) or
-            (req.addresses != resp.caddr)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-        /* make sure no flags are set that shouldn't be, and that  */
-        /* all that should be are set                              */
-        if (!check_flags_for_compatability(req.kdc-options,resp.flags))
-                then destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-        if ((req.from = 0) and
-            (resp.starttime is not within allowable skew)) then
-                destroy resp.key;
-                return KRB_AP_ERR_SKEW;
-        endif
-        if ((req.from != 0) and (req.from != resp.starttime)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-        if ((req.till != 0) and (resp.endtime > req.till)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-
-        if ((req.kdc-options.RENEWABLE is set) and
-            (req.rtime != 0) and (resp.renew-till > req.rtime)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-        endif
-        if ((req.kdc-options.RENEWABLE-OK is set) and
-            (resp.flags.RENEWABLE) and
-            (req.till != 0) and
-            (resp.renew-till > req.till)) then
-                destroy resp.key;
-                return KRB_AP_ERR_MODIFIED;
-
-
-
-Kohl & Neuman                                                  [Page 96]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-        endif
-
-A.5.  KRB_TGS_REQ generation
-        /* Note that make_application_request might have to     */
-        /* recursivly call this routine to get the appropriate  */
-        /* ticket-granting ticket                               */
-
-        request.pvno := protocol version; /* pvno = 5 */
-        request.msg-type := message type; /* type = KRB_TGS_REQ */
-
-        body.kdc-options := users's preferences;
-        /* If the TGT is not for the realm of the end-server  */
-        /* then the sname will be for a TGT for the end-realm */
-        /* and the realm of the requested ticket (body.realm) */
-        /* will be that of the TGS to which the TGT we are    */
-        /* sending applies                                    */
-        body.sname := service's name;
-        body.realm := service's realm;
-
-        if (body.kdc-options.POSTDATED is set) then
-                body.from := requested starting time;
-        else
-                omit body.from;
-        endif
-        body.till := requested end time;
-        if (body.kdc-options.RENEWABLE is set) then
-                body.rtime := requested final renewal time;
-        endif
-        body.nonce := random_nonce();
-        body.etype := requested etypes;
-        if (user supplied addresses) then
-                body.addresses := user's addresses;
-        else
-                omit body.addresses;
-        endif
-
-        body.enc-authorization-data := user-supplied data;
-        if (body.kdc-options.ENC-TKT-IN-SKEY) then
-                body.additional-tickets_ticket := second TGT;
-        endif
-
-        request.req-body := body;
-        check := generate_checksum (req.body,checksumtype);
-
-        request.padata[0].padata-type := PA-TGS-REQ;
-        request.padata[0].padata-value := create a KRB_AP_REQ using
-                                      the TGT and checksum
-
-
-
-
-Kohl & Neuman                                                  [Page 97]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-        /* add in any other padata as required/supplied */
-
-        kerberos := lookup(name of local kerberose server (or servers));
-        send(packet,kerberos);
-
-        wait(for response);
-        if (timed_out) then
-                retry or use alternate server;
-        endif
-
-A.6.  KRB_TGS_REQ verification and KRB_TGS_REP generation
-        /* note that reading the application request requires first
-        determining the server for which a ticket was issued, and
-        choosing the correct key for decryption.  The name of the
-        server appears in the plaintext part of the ticket. */
-
-        if (no KRB_AP_REQ in req.padata) then
-                error_out(KDC_ERR_PADATA_TYPE_NOSUPP);
-        endif
-        verify KRB_AP_REQ in req.padata;
-
-        /* Note that the realm in which the Kerberos server is
-        operating is determined by the instance from the
-        ticket-granting ticket.  The realm in the ticket-granting
-        ticket is the realm under which the ticket granting ticket was
-        issued.  It is possible for a single Kerberos server to
-        support more than one realm. */
-
-        auth_hdr := KRB_AP_REQ;
-        tgt := auth_hdr.ticket;
-
-        if (tgt.sname is not a TGT for local realm and is not
-                req.sname) then error_out(KRB_AP_ERR_NOT_US);
-
-        realm := realm_tgt_is_for(tgt);
-
-        decode remainder of request;
-
-        if (auth_hdr.authenticator.cksum is missing) then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-        if (auth_hdr.authenticator.cksum type is not supported) then
-                error_out(KDC_ERR_SUMTYPE_NOSUPP);
-        endif
-        if (auth_hdr.authenticator.cksum is not both collision-proof
-            and keyed)  then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-
-
-
-Kohl & Neuman                                                  [Page 98]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-        set computed_checksum := checksum(req);
-        if (computed_checksum != auth_hdr.authenticatory.cksum) then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        server := lookup(req.sname,realm);
-
-        if (!server) then
-                if (is_foreign_tgt_name(server)) then
-                        server := best_intermediate_tgs(server);
-                else
-                        /* no server in Database */
-                        error_out(KDC_ERR_S_PRINCIPAL_UNKNOWN);
-                endif
-        endif
-
-        session := generate_random_session_key();
-
-
-        use_etype := first supported etype in req.etypes;
-
-        if (no support for req.etypes) then
-                error_out(KDC_ERR_ETYPE_NOSUPP);
-        endif
-
-        new_tkt.vno := ticket version; /* = 5 */
-        new_tkt.sname := req.sname;
-        new_tkt.srealm := realm;
-        reset all flags in new_tkt.flags;
-
-        /* It should be noted that local policy may affect the  */
-        /* processing of any of these flags.  For example, some */
-        /* realms may refuse to issue renewable tickets         */
-
-        new_tkt.caddr := tgt.caddr;
-        resp.caddr := NULL; /* We only include this if they change */
-        if (req.kdc-options.FORWARDABLE is set) then
-                if (tgt.flags.FORWARDABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.FORWARDABLE;
-        endif
-        if (req.kdc-options.FORWARDED is set) then
-                if (tgt.flags.FORWARDABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.FORWARDED;
-                new_tkt.caddr := req.addresses;
-
-
-
-Kohl & Neuman                                                  [Page 99]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-                resp.caddr := req.addresses;
-        endif
-        if (tgt.flags.FORWARDED is set) then
-                set new_tkt.flags.FORWARDED;
-        endif
-
-        if (req.kdc-options.PROXIABLE is set) then
-                if (tgt.flags.PROXIABLE is reset)
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.PROXIABLE;
-        endif
-        if (req.kdc-options.PROXY is set) then
-                if (tgt.flags.PROXIABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.PROXY;
-                new_tkt.caddr := req.addresses;
-                resp.caddr := req.addresses;
-        endif
-
-        if (req.kdc-options.POSTDATE is set) then
-                if (tgt.flags.POSTDATE is reset)
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.POSTDATE;
-        endif
-        if (req.kdc-options.POSTDATED is set) then
-                if (tgt.flags.POSTDATE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                set new_tkt.flags.POSTDATED;
-                set new_tkt.flags.INVALID;
-                if (against_postdate_policy(req.from)) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-                new_tkt.starttime := req.from;
-        endif
-
-
-        if (req.kdc-options.VALIDATE is set) then
-                if (tgt.flags.INVALID is reset) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-                if (tgt.starttime > kdc_time) then
-                        error_out(KRB_AP_ERR_NYV);
-                endif
-                if (check_hot_list(tgt)) then
-
-
-
-Kohl & Neuman                                                 [Page 100]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-                        error_out(KRB_AP_ERR_REPEAT);
-                endif
-                tkt := tgt;
-                reset new_tkt.flags.INVALID;
-        endif
-
-        if (req.kdc-options.(any flag except ENC-TKT-IN-SKEY, RENEW,
-                             and those already processed) is set) then
-                error_out(KDC_ERR_BADOPTION);
-        endif
-
-        new_tkt.authtime := tgt.authtime;
-
-        if (req.kdc-options.RENEW is set) then
-          /* Note that if the endtime has already passed, the ticket */
-          /* would have been rejected in the initial authentication  */
-          /* stage, so there is no need to check again here          */
-                if (tgt.flags.RENEWABLE is reset) then
-                        error_out(KDC_ERR_BADOPTION);
-                endif
-                if (tgt.renew-till >= kdc_time) then
-                        error_out(KRB_AP_ERR_TKT_EXPIRED);
-                endif
-                tkt := tgt;
-                new_tkt.starttime := kdc_time;
-                old_life := tgt.endttime - tgt.starttime;
-                new_tkt.endtime := min(tgt.renew-till,
-                                       new_tkt.starttime + old_life);
-        else
-                new_tkt.starttime := kdc_time;
-                if (req.till = 0) then
-                        till := infinity;
-                else
-                        till := req.till;
-                endif
-                new_tkt.endtime := min(till,
-                                   new_tkt.starttime+client.max_life,
-                                   new_tkt.starttime+server.max_life,
-                                   new_tkt.starttime+max_life_for_realm,
-                                   tgt.endtime);
-
-                if ((req.kdc-options.RENEWABLE-OK is set) and
-                    (new_tkt.endtime < req.till) and
-                    (tgt.flags.RENEWABLE is set) then
-                        /* we set the RENEWABLE option for later  */
-                        /* processing                             */
-                        set req.kdc-options.RENEWABLE;
-                        req.rtime := min(req.till, tgt.renew-till);
-
-
-
-Kohl & Neuman                                                 [Page 101]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-                endif
-        endif
-
-        if (req.rtime = 0) then
-                rtime := infinity;
-        else
-                rtime := req.rtime;
-        endif
-
-        if ((req.kdc-options.RENEWABLE is set) and
-            (tgt.flags.RENEWABLE is set)) then
-                set new_tkt.flags.RENEWABLE;
-                new_tkt.renew-till := min(rtime,
-                new_tkt.starttime+client.max_rlife,
-                new_tkt.starttime+server.max_rlife,
-                new_tkt.starttime+max_rlife_for_realm,
-                tgt.renew-till);
-        else
-                new_tkt.renew-till := OMIT;
-                              /* leave the renew-till field out */
-        endif
-        if (req.enc-authorization-data is present) then
-                decrypt req.enc-authorization-data
-                        into    decrypted_authorization_data
-                        using auth_hdr.authenticator.subkey;
-                if (decrypt_error()) then
-                        error_out(KRB_AP_ERR_BAD_INTEGRITY);
-                endif
-        endif
-        new_tkt.authorization_data :=
-        req.auth_hdr.ticket.authorization_data +
-                                 decrypted_authorization_data;
-
-        new_tkt.key := session;
-        new_tkt.crealm := tgt.crealm;
-        new_tkt.cname := req.auth_hdr.ticket.cname;
-
-        if (realm_tgt_is_for(tgt) := tgt.realm) then
-                /* tgt issued by local realm */
-                new_tkt.transited := tgt.transited;
-        else
-                /* was issued for this realm by some other realm */
-                if (tgt.transited.tr-type not supported) then
-                        error_out(KDC_ERR_TRTYPE_NOSUPP);
-                endif
-                new_tkt.transited
-                   := compress_transited(tgt.transited + tgt.realm)
-        endif
-
-
-
-Kohl & Neuman                                                 [Page 102]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-        encode encrypted part of new_tkt into OCTET STRING;
-        if (req.kdc-options.ENC-TKT-IN-SKEY is set) then
-                if (server not specified) then
-                        server = req.second_ticket.client;
-                endif
-                if ((req.second_ticket is not a TGT) or
-                    (req.second_ticket.client != server)) then
-                        error_out(KDC_ERR_POLICY);
-                endif
-
-                new_tkt.enc-part := encrypt OCTET STRING using
-                        using etype_for_key(second-ticket.key),
-                                                      second-ticket.key;
-        else
-                new_tkt.enc-part := encrypt OCTET STRING
-                        using etype_for_key(server.key), server.key,
-                                                      server.p_kvno;
-        endif
-
-        resp.pvno := 5;
-        resp.msg-type := KRB_TGS_REP;
-        resp.crealm := tgt.crealm;
-        resp.cname := tgt.cname;
-        resp.ticket := new_tkt;
-
-        resp.key := session;
-        resp.nonce := req.nonce;
-        resp.last-req := fetch_last_request_info(client);
-        resp.flags := new_tkt.flags;
-
-        resp.authtime := new_tkt.authtime;
-        resp.starttime := new_tkt.starttime;
-        resp.endtime := new_tkt.endtime;
-
-        omit resp.key-expiration;
-
-        resp.sname := new_tkt.sname;
-        resp.realm := new_tkt.realm;
-
-        if (new_tkt.flags.RENEWABLE) then
-                resp.renew-till := new_tkt.renew-till;
-        endif
-
-
-        encode body of reply into OCTET STRING;
-
-        if (req.padata.authenticator.subkey)
-                resp.enc-part := encrypt OCTET STRING using use_etype,
-
-
-
-Kohl & Neuman                                                 [Page 103]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-                        req.padata.authenticator.subkey;
-        else resp.enc-part := encrypt OCTET STRING
-                              using use_etype, tgt.key;
-
-        send(resp);
-
-A.7.  KRB_TGS_REP verification
-        decode response into resp;
-
-        if (resp.msg-type = KRB_ERROR) then
-                process_error(resp);
-                return;
-        endif
-
-        /* On error, discard the response, and zero the session key from
-        the response immediately */
-
-        if (req.padata.authenticator.subkey)
-                unencrypted part of resp :=
-                        decode of decrypt of resp.enc-part
-                        using resp.enc-part.etype and subkey;
-        else unencrypted part of resp :=
-                        decode of decrypt of resp.enc-part
-                        using resp.enc-part.etype and tgt's session key;
-        if (common_as_rep_tgs_rep_checks fail) then
-                destroy resp.key;
-                return error;
-        endif
-
-        check authorization_data as necessary;
-        save_for_later(ticket,session,client,server,times,flags);
-
-A.8.  Authenticator generation
-        body.authenticator-vno := authenticator vno; /* = 5 */
-        body.cname, body.crealm := client name;
-        if (supplying checksum) then
-                body.cksum := checksum;
-        endif
-        get system_time;
-        body.ctime, body.cusec := system_time;
-        if (selecting sub-session key) then
-                select sub-session key;
-                body.subkey := sub-session key;
-        endif
-        if (using sequence numbers) then
-                select initial sequence number;
-                body.seq-number := initial sequence;
-        endif
-
-
-
-Kohl & Neuman                                                 [Page 104]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-A.9.  KRB_AP_REQ generation
-        obtain ticket and session_key from cache;
-
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_AP_REQ */
-
-        if (desired(MUTUAL_AUTHENTICATION)) then
-                set packet.ap-options.MUTUAL-REQUIRED;
-        else
-                reset packet.ap-options.MUTUAL-REQUIRED;
-        endif
-        if (using session key for ticket) then
-                set packet.ap-options.USE-SESSION-KEY;
-        else
-                reset packet.ap-options.USE-SESSION-KEY;
-        endif
-        packet.ticket := ticket; /* ticket */
-        generate authenticator;
-        encode authenticator into OCTET STRING;
-        encrypt OCTET STRING into packet.authenticator
-                             using session_key;
-
-A.10.  KRB_AP_REQ verification
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_AP_REQ) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        if (packet.ticket.tkt_vno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.ap_options.USE-SESSION-KEY is set) then
-                retrieve session key from ticket-granting ticket for
-                 packet.ticket.{sname,srealm,enc-part.etype};
-        else
-           retrieve service key for
-           packet.ticket.{sname,srealm,enc-part.etype,enc-part.skvno};
-        endif
-        if (no_key_available) then
-                if (cannot_find_specified_skvno) then
-                        error_out(KRB_AP_ERR_BADKEYVER);
-                else
-                        error_out(KRB_AP_ERR_NOKEY);
-                endif
-
-
-
-Kohl & Neuman                                                 [Page 105]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-        endif
-        decrypt packet.ticket.enc-part into decr_ticket
-                                       using retrieved key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        decrypt packet.authenticator into decr_authenticator
-                using decr_ticket.key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        if (decr_authenticator.{cname,crealm} !=
-            decr_ticket.{cname,crealm}) then
-                error_out(KRB_AP_ERR_BADMATCH);
-        endif
-        if (decr_ticket.caddr is present) then
-                if (sender_address(packet) is not in decr_ticket.caddr)
-                        then error_out(KRB_AP_ERR_BADADDR);
-                endif
-        elseif (application requires addresses) then
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if (not in_clock_skew(decr_authenticator.ctime,
-                              decr_authenticator.cusec)) then
-                error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(decr_authenticator.{ctime,cusec,cname,crealm}))
-                then error_out(KRB_AP_ERR_REPEAT);
-        endif
-        save_identifier(decr_authenticator.{ctime,cusec,cname,crealm});
-        get system_time;
-        if ((decr_ticket.starttime-system_time > CLOCK_SKEW) or
-            (decr_ticket.flags.INVALID is set)) then
-                /* it hasn't yet become valid */
-                error_out(KRB_AP_ERR_TKT_NYV);
-        endif
-        if (system_time-decr_ticket.endtime > CLOCK_SKEW) then
-                error_out(KRB_AP_ERR_TKT_EXPIRED);
-        endif
-        /* caller must check decr_ticket.flags for any pertinent */
-        /* details */
-        return(OK, decr_ticket, packet.ap_options.MUTUAL-REQUIRED);
-
-A.11.  KRB_AP_REP generation
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_AP_REP */
-        body.ctime := packet.ctime;
-        body.cusec := packet.cusec;
-
-
-
-Kohl & Neuman                                                 [Page 106]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-        if (selecting sub-session key) then
-                select sub-session key;
-                body.subkey := sub-session key;
-        endif
-        if (using sequence numbers) then
-                select initial sequence number;
-                body.seq-number := initial sequence;
-        endif
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part;
-
-A.12.  KRB_AP_REP verification
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_AP_REP) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        cleartext := decrypt(packet.enc-part)
-                     using ticket's session key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        if (cleartext.ctime != authenticator.ctime) then
-                error_out(KRB_AP_ERR_MUT_FAIL);
-        endif
-        if (cleartext.cusec != authenticator.cusec) then
-                error_out(KRB_AP_ERR_MUT_FAIL);
-        endif
-        if (cleartext.subkey is present) then
-                save cleartext.subkey for future use;
-        endif
-        if (cleartext.seq-number is present) then
-                save cleartext.seq-number for future verifications;
-        endif
-        return(AUTHENTICATION_SUCCEEDED);
-
-A.13.  KRB_SAFE generation
-        collect user data in buffer;
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_SAFE */
-
-
-
-Kohl & Neuman                                                 [Page 107]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-        body.user-data := buffer; /* DATA */
-        if (using timestamp) then
-                get system_time;
-                body.timestamp, body.usec := system_time;
-        endif
-        if (using sequence numbers) then
-                body.seq-number := sequence number;
-        endif
-        body.s-address := sender host addresses;
-        if (only one recipient) then
-                body.r-address := recipient host address;
-        endif
-        checksum.cksumtype := checksum type;
-        compute checksum over body;
-        checksum.checksum := checksum value; /* checksum.checksum */
-        packet.cksum := checksum;
-        packet.safe-body := body;
-
-A.14.  KRB_SAFE verification
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_SAFE) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-        if (packet.checksum.cksumtype is not both collision-proof
-                                             and keyed) then
-                error_out(KRB_AP_ERR_INAPP_CKSUM);
-        endif
-        if (safe_priv_common_checks_ok(packet)) then
-                set computed_checksum := checksum(packet.body);
-                if (computed_checksum != packet.checksum) then
-                        error_out(KRB_AP_ERR_MODIFIED);
-                endif
-                return (packet, PACKET_IS_GENUINE);
-        else
-                return common_checks_error;
-        endif
-
-A.15.  KRB_SAFE and KRB_PRIV common checks
-        if (packet.s-address != O/S_sender(packet)) then
-            /* O/S report of sender not who claims to have sent it */
-            error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if ((packet.r-address is present) and
-            (packet.r-address != local_host_address)) then
-
-
-
-Kohl & Neuman                                                 [Page 108]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-                /* was not sent to proper place */
-                error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if (((packet.timestamp is present) and
-             (not in_clock_skew(packet.timestamp,packet.usec))) or
-            (packet.timestamp is not present and timestamp expected))
-                then error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(packet.timestamp,packet.usec,packet.s-address))
-                then error_out(KRB_AP_ERR_REPEAT);
-        endif
-        if (((packet.seq-number is present) and
-             ((not in_sequence(packet.seq-number)))) or
-            (packet.seq-number is not present and sequence expected))
-                then error_out(KRB_AP_ERR_BADORDER);
-        endif
-        if (packet.timestamp not present and
-            packet.seq-number not present) then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        save_identifier(packet.{timestamp,usec,s-address},
-                        sender_principal(packet));
-
-        return PACKET_IS_OK;
-
-A.16.  KRB_PRIV generation
-        collect user data in buffer;
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_PRIV */
-
-        packet.enc-part.etype := encryption type;
-
-        body.user-data := buffer;
-        if (using timestamp) then
-                get system_time;
-                body.timestamp, body.usec := system_time;
-        endif
-        if (using sequence numbers) then
-                body.seq-number := sequence number;
-        endif
-        body.s-address := sender host addresses;
-        if (only one recipient) then
-                body.r-address := recipient host address;
-        endif
-
-
-
-
-Kohl & Neuman                                                 [Page 109]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part.cipher;
-
-A.17.  KRB_PRIV verification
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_PRIV) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-
-        cleartext := decrypt(packet.enc-part) using negotiated key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-
-        if (safe_priv_common_checks_ok(cleartext)) then
-            return(cleartext.DATA, PACKET_IS_GENUINE_AND_UNMODIFIED);
-        else
-                return common_checks_error;
-        endif
-
-A.18.  KRB_CRED generation
-        invoke KRB_TGS; /* obtain tickets to be provided to peer */
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_CRED */
-
-        for (tickets[n] in tickets to be forwarded) do
-                packet.tickets[n] = tickets[n].ticket;
-        done
-
-        packet.enc-part.etype := encryption type;
-
-        for (ticket[n] in tickets to be forwarded) do
-                body.ticket-info[n].key = tickets[n].session;
-                body.ticket-info[n].prealm = tickets[n].crealm;
-                body.ticket-info[n].pname = tickets[n].cname;
-                body.ticket-info[n].flags = tickets[n].flags;
-                body.ticket-info[n].authtime = tickets[n].authtime;
-                body.ticket-info[n].starttime = tickets[n].starttime;
-                body.ticket-info[n].endtime = tickets[n].endtime;
-                body.ticket-info[n].renew-till = tickets[n].renew-till;
-
-
-
-Kohl & Neuman                                                 [Page 110]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-                body.ticket-info[n].srealm = tickets[n].srealm;
-                body.ticket-info[n].sname = tickets[n].sname;
-                body.ticket-info[n].caddr = tickets[n].caddr;
-        done
-
-        get system_time;
-        body.timestamp, body.usec := system_time;
-
-        if (using nonce) then
-                body.nonce := nonce;
-        endif
-
-        if (using s-address) then
-                body.s-address := sender host addresses;
-        endif
-        if (limited recipients) then
-                body.r-address := recipient host address;
-        endif
-
-        encode body into OCTET STRING;
-
-        select encryption type;
-        encrypt OCTET STRING into packet.enc-part.cipher
-        using negotiated encryption key;
-
-A.19.  KRB_CRED verification
-        receive packet;
-        if (packet.pvno != 5) then
-                either process using other protocol spec
-                or error_out(KRB_AP_ERR_BADVERSION);
-        endif
-        if (packet.msg-type != KRB_CRED) then
-                error_out(KRB_AP_ERR_MSG_TYPE);
-        endif
-
-        cleartext := decrypt(packet.enc-part) using negotiated key;
-        if (decryption_error()) then
-                error_out(KRB_AP_ERR_BAD_INTEGRITY);
-        endif
-        if ((packet.r-address is present or required) and
-           (packet.s-address != O/S_sender(packet)) then
-            /* O/S report of sender not who claims to have sent it */
-            error_out(KRB_AP_ERR_BADADDR);
-        endif
-        if ((packet.r-address is present) and
-            (packet.r-address != local_host_address)) then
-                /* was not sent to proper place */
-                error_out(KRB_AP_ERR_BADADDR);
-
-
-
-Kohl & Neuman                                                 [Page 111]
-
-RFC 1510                        Kerberos                  September 1993
-
-
-        endif
-        if (not in_clock_skew(packet.timestamp,packet.usec)) then
-                error_out(KRB_AP_ERR_SKEW);
-        endif
-        if (repeated(packet.timestamp,packet.usec,packet.s-address))
-                then error_out(KRB_AP_ERR_REPEAT);
-        endif
-        if (packet.nonce is required or present) and
-           (packet.nonce != expected-nonce) then
-                error_out(KRB_AP_ERR_MODIFIED);
-        endif
-
-        for (ticket[n] in tickets that were forwarded) do
-                save_for_later(ticket[n],key[n],principal[n],
-                               server[n],times[n],flags[n]);
-        return
-
-A.20.  KRB_ERROR generation
-
-        /* assemble packet: */
-        packet.pvno := protocol version; /* 5 */
-        packet.msg-type := message type; /* KRB_ERROR */
-
-        get system_time;
-        packet.stime, packet.susec := system_time;
-        packet.realm, packet.sname := server name;
-
-        if (client time available) then
-                packet.ctime, packet.cusec := client_time;
-        endif
-        packet.error-code := error code;
-        if (client name available) then
-                packet.cname, packet.crealm := client name;
-        endif
-        if (error text available) then
-                packet.e-text := error text;
-        endif
-        if (error data available) then
-                packet.e-data := error data;
-        endif
-
-
-
-
-
-
-
-
-
-
-
-Kohl & Neuman                                                 [Page 112]
-
\ No newline at end of file
diff --git a/doc/standardisation/rfc1750.txt b/doc/standardisation/rfc1750.txt
deleted file mode 100644
index 56d478c7e..000000000
--- a/doc/standardisation/rfc1750.txt
+++ /dev/null
@@ -1,1683 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   D. Eastlake, 3rd
-Request for Comments: 1750                                           DEC
-Category: Informational                                       S. Crocker
-                                                               Cybercash
-                                                             J. Schiller
-                                                                     MIT
-                                                           December 1994
-
-
-                Randomness Recommendations for Security
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   Security systems today are built on increasingly strong cryptographic
-   algorithms that foil pattern analysis attempts. However, the security
-   of these systems is dependent on generating secret quantities for
-   passwords, cryptographic keys, and similar quantities.  The use of
-   pseudo-random processes to generate secret quantities can result in
-   pseudo-security.  The sophisticated attacker of these security
-   systems may find it easier to reproduce the environment that produced
-   the secret quantities, searching the resulting small set of
-   possibilities, than to locate the quantities in the whole of the
-   number space.
-
-   Choosing random quantities to foil a resourceful and motivated
-   adversary is surprisingly difficult.  This paper points out many
-   pitfalls in using traditional pseudo-random number generation
-   techniques for choosing such quantities.  It recommends the use of
-   truly random hardware techniques and shows that the existing hardware
-   on many systems can be used for this purpose.  It provides
-   suggestions to ameliorate the problem when a hardware solution is not
-   available.  And it gives examples of how large such quantities need
-   to be for some particular applications.
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 1]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-Acknowledgements
-
-   Comments on this document that have been incorporated were received
-   from (in alphabetic order) the following:
-
-        David M. Balenson (TIS)
-        Don Coppersmith (IBM)
-        Don T. Davis (consultant)
-        Carl Ellison (Stratus)
-        Marc Horowitz (MIT)
-        Christian Huitema (INRIA)
-        Charlie Kaufman (IRIS)
-        Steve Kent (BBN)
-        Hal Murray (DEC)
-        Neil Haller (Bellcore)
-        Richard Pitkin (DEC)
-        Tim Redmond (TIS)
-        Doug Tygar (CMU)
-
-Table of Contents
-
-   1. Introduction........................................... 3
-   2. Requirements........................................... 4
-   3. Traditional Pseudo-Random Sequences.................... 5
-   4. Unpredictability....................................... 7
-   4.1 Problems with Clocks and Serial Numbers............... 7
-   4.2 Timing and Content of External Events................  8
-   4.3 The Fallacy of Complex Manipulation..................  8
-   4.4 The Fallacy of Selection from a Large Database.......  9
-   5. Hardware for Randomness............................... 10
-   5.1 Volume Required...................................... 10
-   5.2 Sensitivity to Skew.................................. 10
-   5.2.1 Using Stream Parity to De-Skew..................... 11
-   5.2.2 Using Transition Mappings to De-Skew............... 12
-   5.2.3 Using FFT to De-Skew............................... 13
-   5.2.4 Using Compression to De-Skew....................... 13
-   5.3 Existing Hardware Can Be Used For Randomness......... 14
-   5.3.1 Using Existing Sound/Video Input................... 14
-   5.3.2 Using Existing Disk Drives......................... 14
-   6. Recommended Non-Hardware Strategy..................... 14
-   6.1 Mixing Functions..................................... 15
-   6.1.1 A Trivial Mixing Function.......................... 15
-   6.1.2 Stronger Mixing Functions.......................... 16
-   6.1.3 Diff-Hellman as a Mixing Function.................. 17
-   6.1.4 Using a Mixing Function to Stretch Random Bits..... 17
-   6.1.5 Other Factors in Choosing a Mixing Function........ 18
-   6.2 Non-Hardware Sources of Randomness................... 19
-   6.3 Cryptographically Strong Sequences................... 19
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 2]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   6.3.1 Traditional Strong Sequences....................... 20
-   6.3.2 The Blum Blum Shub Sequence Generator.............. 21
-   7. Key Generation Standards.............................. 22
-   7.1 US DoD Recommendations for Password Generation....... 23
-   7.2 X9.17 Key Generation................................. 23
-   8. Examples of Randomness Required....................... 24
-   8.1  Password Generation................................. 24
-   8.2 A Very High Security Cryptographic Key............... 25
-   8.2.1 Effort per Key Trial............................... 25
-   8.2.2 Meet in the Middle Attacks......................... 26
-   8.2.3 Other Considerations............................... 26
-   9. Conclusion............................................ 27
-   10. Security Considerations.............................. 27
-   References............................................... 28
-   Authors' Addresses....................................... 30
-
-1. Introduction
-
-   Software cryptography is coming into wider use.  Systems like
-   Kerberos, PEM, PGP, etc. are maturing and becoming a part of the
-   network landscape [PEM].  These systems provide substantial
-   protection against snooping and spoofing.  However, there is a
-   potential flaw.  At the heart of all cryptographic systems is the
-   generation of secret, unguessable (i.e., random) numbers.
-
-   For the present, the lack of generally available facilities for
-   generating such unpredictable numbers is an open wound in the design
-   of cryptographic software.  For the software developer who wants to
-   build a key or password generation procedure that runs on a wide
-   range of hardware, the only safe strategy so far has been to force
-   the local installation to supply a suitable routine to generate
-   random numbers.  To say the least, this is an awkward, error-prone
-   and unpalatable solution.
-
-   It is important to keep in mind that the requirement is for data that
-   an adversary has a very low probability of guessing or determining.
-   This will fail if pseudo-random data is used which only meets
-   traditional statistical tests for randomness or which is based on
-   limited range sources, such as clocks.  Frequently such random
-   quantities are determinable by an adversary searching through an
-   embarrassingly small space of possibilities.
-
-   This informational document suggests techniques for producing random
-   quantities that will be resistant to such attack.  It recommends that
-   future systems include hardware random number generation or provide
-   access to existing hardware that can be used for this purpose.  It
-   suggests methods for use if such hardware is not available.  And it
-   gives some estimates of the number of random bits required for sample
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 3]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   applications.
-
-2. Requirements
-
-   Probably the most commonly encountered randomness requirement today
-   is the user password. This is usually a simple character string.
-   Obviously, if a password can be guessed, it does not provide
-   security.  (For re-usable passwords, it is desirable that users be
-   able to remember the password.  This may make it advisable to use
-   pronounceable character strings or phrases composed on ordinary
-   words.  But this only affects the format of the password information,
-   not the requirement that the password be very hard to guess.)
-
-   Many other requirements come from the cryptographic arena.
-   Cryptographic techniques can be used to provide a variety of services
-   including confidentiality and authentication.  Such services are
-   based on quantities, traditionally called "keys", that are unknown to
-   and unguessable by an adversary.
-
-   In some cases, such as the use of symmetric encryption with the one
-   time pads [CRYPTO*] or the US Data Encryption Standard [DES], the
-   parties who wish to communicate confidentially and/or with
-   authentication must all know the same secret key.  In other cases,
-   using what are called asymmetric or "public key" cryptographic
-   techniques, keys come in pairs.  One key of the pair is private and
-   must be kept secret by one party, the other is public and can be
-   published to the world.  It is computationally infeasible to
-   determine the private key from the public key [ASYMMETRIC, CRYPTO*].
-
-   The frequency and volume of the requirement for random quantities
-   differs greatly for different cryptographic systems.  Using pure RSA
-   [CRYPTO*], random quantities are required when the key pair is
-   generated, but thereafter any number of messages can be signed
-   without any further need for randomness.  The public key Digital
-   Signature Algorithm that has been proposed by the US National
-   Institute of Standards and Technology (NIST) requires good random
-   numbers for each signature.  And encrypting with a one time pad, in
-   principle the strongest possible encryption technique, requires a
-   volume of randomness equal to all the messages to be processed.
-
-   In most of these cases, an adversary can try to determine the
-   "secret" key by trial and error.  (This is possible as long as the
-   key is enough smaller than the message that the correct key can be
-   uniquely identified.)  The probability of an adversary succeeding at
-   this must be made acceptably low, depending on the particular
-   application.  The size of the space the adversary must search is
-   related to the amount of key "information" present in the information
-   theoretic sense [SHANNON].  This depends on the number of different
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 4]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   secret values possible and the probability of each value as follows:
-
-                      -----
-                       \
-        Bits-of-info =  \  - p   * log  ( p  )
-                        /     i       2    i
-                       /
-                      -----
-
-   where i varies from 1 to the number of possible secret values and p
-   sub i is the probability of the value numbered i.  (Since p sub i is
-   less than one, the log will be negative so each term in the sum will
-   be non-negative.)
-
-   If there are 2^n different values of equal probability, then n bits
-   of information are present and an adversary would, on the average,
-   have to try half of the values, or 2^(n-1) , before guessing the
-   secret quantity.  If the probability of different values is unequal,
-   then there is less information present and fewer guesses will, on
-   average, be required by an adversary.  In particular, any values that
-   the adversary can know are impossible, or are of low probability, can
-   be initially ignored by an adversary, who will search through the
-   more probable values first.
-
-   For example, consider a cryptographic system that uses 56 bit keys.
-   If these 56 bit keys are derived by using a fixed pseudo-random
-   number generator that is seeded with an 8 bit seed, then an adversary
-   needs to search through only 256 keys (by running the pseudo-random
-   number generator with every possible seed), not the 2^56 keys that
-   may at first appear to be the case. Only 8 bits of "information" are
-   in these 56 bit keys.
-
-3. Traditional Pseudo-Random Sequences
-
-   Most traditional sources of random numbers use deterministic sources
-   of "pseudo-random" numbers.  These typically start with a "seed"
-   quantity and use numeric or logical operations to produce a sequence
-   of values.
-
-   [KNUTH] has a classic exposition on pseudo-random numbers.
-   Applications he mentions are simulation of natural phenomena,
-   sampling, numerical analysis, testing computer programs, decision
-   making, and games.  None of these have the same characteristics as
-   the sort of security uses we are talking about.  Only in the last two
-   could there be an adversary trying to find the random quantity.
-   However, in these cases, the adversary normally has only a single
-   chance to use a guessed value.  In guessing passwords or attempting
-   to break an encryption scheme, the adversary normally has many,
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 5]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   perhaps unlimited, chances at guessing the correct value and should
-   be assumed to be aided by a computer.
-
-   For testing the "randomness" of numbers, Knuth suggests a variety of
-   measures including statistical and spectral.  These tests check
-   things like autocorrelation between different parts of a "random"
-   sequence or distribution of its values.  They could be met by a
-   constant stored random sequence, such as the "random" sequence
-   printed in the CRC Standard Mathematical Tables [CRC].
-
-   A typical pseudo-random number generation technique, known as a
-   linear congruence pseudo-random number generator, is modular
-   arithmetic where the N+1th value is calculated from the Nth value by
-
-        V    = ( V  * a + b )(Mod c)
-         N+1      N
-
-   The above technique has a strong relationship to linear shift
-   register pseudo-random number generators, which are well understood
-   cryptographically [SHIFT*].  In such generators bits are introduced
-   at one end of a shift register as the Exclusive Or (binary sum
-   without carry) of bits from selected fixed taps into the register.
-
-   For example:
-
-      +----+     +----+     +----+                      +----+
-      | B  | <-- | B  | <-- | B  | <--  . . . . . . <-- | B  | <-+
-      |  0 |     |  1 |     |  2 |                      |  n |   |
-      +----+     +----+     +----+                      +----+   |
-        |                     |            |                     |
-        |                     |            V                  +-----+
-        |                     V            +----------------> |     |
-        V                     +-----------------------------> | XOR |
-        +---------------------------------------------------> |     |
-                                                              +-----+
-
-
-       V    = ( ( V  * 2 ) + B .xor. B ... )(Mod 2^n)
-        N+1         N         0       2
-
-   The goodness of traditional pseudo-random number generator algorithms
-   is measured by statistical tests on such sequences.  Carefully chosen
-   values of the initial V and a, b, and c or the placement of shift
-   register tap in the above simple processes can produce excellent
-   statistics.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 6]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   These sequences may be adequate in simulations (Monte Carlo
-   experiments) as long as the sequence is orthogonal to the structure
-   of the space being explored.  Even there, subtle patterns may cause
-   problems.  However, such sequences are clearly bad for use in
-   security applications.  They are fully predictable if the initial
-   state is known.  Depending on the form of the pseudo-random number
-   generator, the sequence may be determinable from observation of a
-   short portion of the sequence [CRYPTO*, STERN].  For example, with
-   the generators above, one can determine V(n+1) given knowledge of
-   V(n).  In fact, it has been shown that with these techniques, even if
-   only one bit of the pseudo-random values is released, the seed can be
-   determined from short sequences.
-
-   Not only have linear congruent generators been broken, but techniques
-   are now known for breaking all polynomial congruent generators
-   [KRAWCZYK].
-
-4. Unpredictability
-
-   Randomness in the traditional sense described in section 3 is NOT the
-   same as the unpredictability required for security use.
-
-   For example, use of a widely available constant sequence, such as
-   that from the CRC tables, is very weak against an adversary. Once
-   they learn of or guess it, they can easily break all security, future
-   and past, based on the sequence [CRC].  Yet the statistical
-   properties of these tables are good.
-
-   The following sections describe the limitations of some randomness
-   generation techniques and sources.
-
-4.1 Problems with Clocks and Serial Numbers
-
-   Computer clocks, or similar operating system or hardware values,
-   provide significantly fewer real bits of unpredictability than might
-   appear from their specifications.
-
-   Tests have been done on clocks on numerous systems and it was found
-   that their behavior can vary widely and in unexpected ways.  One
-   version of an operating system running on one set of hardware may
-   actually provide, say, microsecond resolution in a clock while a
-   different configuration of the "same" system may always provide the
-   same lower bits and only count in the upper bits at much lower
-   resolution.  This means that successive reads on the clock may
-   produce identical values even if enough time has passed that the
-   value "should" change based on the nominal clock resolution. There
-   are also cases where frequently reading a clock can produce
-   artificial sequential values because of extra code that checks for
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 7]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   the clock being unchanged between two reads and increases it by one!
-   Designing portable application code to generate unpredictable numbers
-   based on such system clocks is particularly challenging because the
-   system designer does not always know the properties of the system
-   clocks that the code will execute on.
-
-   Use of a hardware serial number such as an Ethernet address may also
-   provide fewer bits of uniqueness than one would guess.  Such
-   quantities are usually heavily structured and subfields may have only
-   a limited range of possible values or values easily guessable based
-   on approximate date of manufacture or other data.  For example, it is
-   likely that most of the Ethernet cards installed on Digital Equipment
-   Corporation (DEC) hardware within DEC were manufactured by DEC
-   itself, which significantly limits the range of built in addresses.
-
-   Problems such as those described above related to clocks and serial
-   numbers make code to produce unpredictable quantities difficult if
-   the code is to be ported across a variety of computer platforms and
-   systems.
-
-4.2 Timing and Content of External Events
-
-   It is possible to measure the timing and content of mouse movement,
-   key strokes, and similar user events.  This is a reasonable source of
-   unguessable data with some qualifications.  On some machines, inputs
-   such as key strokes are buffered.  Even though the user's inter-
-   keystroke timing may have sufficient variation and unpredictability,
-   there might not be an easy way to access that variation.  Another
-   problem is that no standard method exists to sample timing details.
-   This makes it hard to build standard software intended for
-   distribution to a large range of machines based on this technique.
-
-   The amount of mouse movement or the keys actually hit are usually
-   easier to access than timings but may yield less unpredictability as
-   the user may provide highly repetitive input.
-
-   Other external events, such as network packet arrival times, can also
-   be used with care.  In particular, the possibility of manipulation of
-   such times by an adversary must be considered.
-
-4.3 The Fallacy of Complex Manipulation
-
-   One strategy which may give a misleading appearance of
-   unpredictability is to take a very complex algorithm (or an excellent
-   traditional pseudo-random number generator with good statistical
-   properties) and calculate a cryptographic key by starting with the
-   current value of a computer system clock as the seed.  An adversary
-   who knew roughly when the generator was started would have a
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 8]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   relatively small number of seed values to test as they would know
-   likely values of the system clock.  Large numbers of pseudo-random
-   bits could be generated but the search space an adversary would need
-   to check could be quite small.
-
-   Thus very strong and/or complex manipulation of data will not help if
-   the adversary can learn what the manipulation is and there is not
-   enough unpredictability in the starting seed value.  Even if they can
-   not learn what the manipulation is, they may be able to use the
-   limited number of results stemming from a limited number of seed
-   values to defeat security.
-
-   Another serious strategy error is to assume that a very complex
-   pseudo-random number generation algorithm will produce strong random
-   numbers when there has been no theory behind or analysis of the
-   algorithm.  There is a excellent example of this fallacy right near
-   the beginning of chapter 3 in [KNUTH] where the author describes a
-   complex algorithm.  It was intended that the machine language program
-   corresponding to the algorithm would be so complicated that a person
-   trying to read the code without comments wouldn't know what the
-   program was doing.  Unfortunately, actual use of this algorithm
-   showed that it almost immediately converged to a single repeated
-   value in one case and a small cycle of values in another case.
-
-   Not only does complex manipulation not help you if you have a limited
-   range of seeds but blindly chosen complex manipulation can destroy
-   the randomness in a good seed!
-
-4.4 The Fallacy of Selection from a Large Database
-
-   Another strategy that can give a misleading appearance of
-   unpredictability is selection of a quantity randomly from a database
-   and assume that its strength is related to the total number of bits
-   in the database.  For example, typical USENET servers as of this date
-   process over 35 megabytes of information per day.  Assume a random
-   quantity was selected by fetching 32 bytes of data from a random
-   starting point in this data.  This does not yield 32*8 = 256 bits
-   worth of unguessability.  Even after allowing that much of the data
-   is human language and probably has more like 2 or 3 bits of
-   information per byte, it doesn't yield 32*2.5 = 80 bits of
-   unguessability.  For an adversary with access to the same 35
-   megabytes the unguessability rests only on the starting point of the
-   selection.  That is, at best, about 25 bits of unguessability in this
-   case.
-
-   The same argument applies to selecting sequences from the data on a
-   CD ROM or Audio CD recording or any other large public database.  If
-   the adversary has access to the same database, this "selection from a
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 9]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   large volume of data" step buys very little.  However, if a selection
-   can be made from data to which the adversary has no access, such as
-   system buffers on an active multi-user system, it may be of some
-   help.
-
-5. Hardware for Randomness
-
-   Is there any hope for strong portable randomness in the future?
-   There might be.  All that's needed is a physical source of
-   unpredictable numbers.
-
-   A thermal noise or radioactive decay source and a fast, free-running
-   oscillator would do the trick directly [GIFFORD].  This is a trivial
-   amount of hardware, and could easily be included as a standard part
-   of a computer system's architecture.  Furthermore, any system with a
-   spinning disk or the like has an adequate source of randomness
-   [DAVIS].  All that's needed is the common perception among computer
-   vendors that this small additional hardware and the software to
-   access it is necessary and useful.
-
-5.1 Volume Required
-
-   How much unpredictability is needed?  Is it possible to quantify the
-   requirement in, say, number of random bits per second?
-
-   The answer is not very much is needed.  For DES, the key is 56 bits
-   and, as we show in an example in Section 8, even the highest security
-   system is unlikely to require a keying material of over 200 bits.  If
-   a series of keys are needed, it can be generated from a strong random
-   seed using a cryptographically strong sequence as explained in
-   Section 6.3.  A few hundred random bits generated once a day would be
-   enough using such techniques.  Even if the random bits are generated
-   as slowly as one per second and it is not possible to overlap the
-   generation process, it should be tolerable in high security
-   applications to wait 200 seconds occasionally.
-
-   These numbers are trivial to achieve.  It could be done by a person
-   repeatedly tossing a coin.  Almost any hardware process is likely to
-   be much faster.
-
-5.2 Sensitivity to Skew
-
-   Is there any specific requirement on the shape of the distribution of
-   the random numbers?  The good news is the distribution need not be
-   uniform.  All that is needed is a conservative estimate of how non-
-   uniform it is to bound performance.  Two simple techniques to de-skew
-   the bit stream are given below and stronger techniques are mentioned
-   in Section 6.1.2 below.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 10]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-5.2.1 Using Stream Parity to De-Skew
-
-   Consider taking a sufficiently long string of bits and map the string
-   to "zero" or "one".  The mapping will not yield a perfectly uniform
-   distribution, but it can be as close as desired.  One mapping that
-   serves the purpose is to take the parity of the string.  This has the
-   advantages that it is robust across all degrees of skew up to the
-   estimated maximum skew and is absolutely trivial to implement in
-   hardware.
-
-   The following analysis gives the number of bits that must be sampled:
-
-   Suppose the ratio of ones to zeros is 0.5 + e : 0.5 - e, where e is
-   between 0 and 0.5 and is a measure of the "eccentricity" of the
-   distribution.  Consider the distribution of the parity function of N
-   bit samples.  The probabilities that the parity will be one or zero
-   will be the sum of the odd or even terms in the binomial expansion of
-   (p + q)^N, where p = 0.5 + e, the probability of a one, and q = 0.5 -
-   e, the probability of a zero.
-
-   These sums can be computed easily as
-
-                         N            N
-        1/2 * ( ( p + q )  + ( p - q )  )
-   and
-                         N            N
-        1/2 * ( ( p + q )  - ( p - q )  ).
-
-   (Which one corresponds to the probability the parity will be 1
-   depends on whether N is odd or even.)
-
-   Since p + q = 1 and p - q = 2e, these expressions reduce to
-
-                       N
-        1/2 * [1 + (2e) ]
-   and
-                       N
-        1/2 * [1 - (2e) ].
-
-   Neither of these will ever be exactly 0.5 unless e is zero, but we
-   can bring them arbitrarily close to 0.5.  If we want the
-   probabilities to be within some delta d of 0.5, i.e. then
-
-                            N
-        ( 0.5 + ( 0.5 * (2e)  ) )  <  0.5 + d.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 11]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Solving for N yields N > log(2d)/log(2e).  (Note that 2e is less than
-   1, so its log is negative.  Division by a negative number reverses
-   the sense of an inequality.)
-
-   The following table gives the length of the string which must be
-   sampled for various degrees of skew in order to come within 0.001 of
-   a 50/50 distribution.
-
-                       +---------+--------+-------+
-                       | Prob(1) |    e   |    N  |
-                       +---------+--------+-------+
-                       |   0.5   |  0.00  |    1  |
-                       |   0.6   |  0.10  |    4  |
-                       |   0.7   |  0.20  |    7  |
-                       |   0.8   |  0.30  |   13  |
-                       |   0.9   |  0.40  |   28  |
-                       |   0.95  |  0.45  |   59  |
-                       |   0.99  |  0.49  |  308  |
-                       +---------+--------+-------+
-
-   The last entry shows that even if the distribution is skewed 99% in
-   favor of ones, the parity of a string of 308 samples will be within
-   0.001 of a 50/50 distribution.
-
-5.2.2 Using Transition Mappings to De-Skew
-
-   Another technique, originally due to von Neumann [VON NEUMANN], is to
-   examine a bit stream as a sequence of non-overlapping pairs. You
-   could then discard any 00 or 11 pairs found, interpret 01 as a 0 and
-   10 as a 1.  Assume the probability of a 1 is 0.5+e and the
-   probability of a 0 is 0.5-e where e is the eccentricity of the source
-   and described in the previous section.  Then the probability of each
-   pair is as follows:
-
-            +------+-----------------------------------------+
-            | pair |            probability                  |
-            +------+-----------------------------------------+
-            |  00  | (0.5 - e)^2          =  0.25 - e + e^2  |
-            |  01  | (0.5 - e)*(0.5 + e)  =  0.25     - e^2  |
-            |  10  | (0.5 + e)*(0.5 - e)  =  0.25     - e^2  |
-            |  11  | (0.5 + e)^2          =  0.25 + e + e^2  |
-            +------+-----------------------------------------+
-
-   This technique will completely eliminate any bias but at the expense
-   of taking an indeterminate number of input bits for any particular
-   desired number of output bits.  The probability of any particular
-   pair being discarded is 0.5 + 2e^2 so the expected number of input
-   bits to produce X output bits is X/(0.25 - e^2).
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 12]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   This technique assumes that the bits are from a stream where each bit
-   has the same probability of being a 0 or 1 as any other bit in the
-   stream and that bits are not correlated, i.e., that the bits are
-   identical independent distributions.  If alternate bits were from two
-   correlated sources, for example, the above analysis breaks down.
-
-   The above technique also provides another illustration of how a
-   simple statistical analysis can mislead if one is not always on the
-   lookout for patterns that could be exploited by an adversary.  If the
-   algorithm were mis-read slightly so that overlapping successive bits
-   pairs were used instead of non-overlapping pairs, the statistical
-   analysis given is the same; however, instead of provided an unbiased
-   uncorrelated series of random 1's and 0's, it instead produces a
-   totally predictable sequence of exactly alternating 1's and 0's.
-
-5.2.3 Using FFT to De-Skew
-
-   When real world data consists of strongly biased or correlated bits,
-   it may still contain useful amounts of randomness.  This randomness
-   can be extracted through use of the discrete Fourier transform or its
-   optimized variant, the FFT.
-
-   Using the Fourier transform of the data, strong correlations can be
-   discarded.  If adequate data is processed and remaining correlations
-   decay, spectral lines approaching statistical independence and
-   normally distributed randomness can be produced [BRILLINGER].
-
-5.2.4 Using Compression to De-Skew
-
-   Reversible compression techniques also provide a crude method of de-
-   skewing a skewed bit stream.  This follows directly from the
-   definition of reversible compression and the formula in Section 2
-   above for the amount of information in a sequence.  Since the
-   compression is reversible, the same amount of information must be
-   present in the shorter output than was present in the longer input.
-   By the Shannon information equation, this is only possible if, on
-   average, the probabilities of the different shorter sequences are
-   more uniformly distributed than were the probabilities of the longer
-   sequences.  Thus the shorter sequences are de-skewed relative to the
-   input.
-
-   However, many compression techniques add a somewhat predicatable
-   preface to their output stream and may insert such a sequence again
-   periodically in their output or otherwise introduce subtle patterns
-   of their own.  They should be considered only a rough technique
-   compared with those described above or in Section 6.1.2.  At a
-   minimum, the beginning of the compressed sequence should be skipped
-   and only later bits used for applications requiring random bits.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 13]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-5.3 Existing Hardware Can Be Used For Randomness
-
-   As described below, many computers come with hardware that can, with
-   care, be used to generate truly random quantities.
-
-5.3.1 Using Existing Sound/Video Input
-
-   Increasingly computers are being built with inputs that digitize some
-   real world analog source, such as sound from a microphone or video
-   input from a camera.  Under appropriate circumstances, such input can
-   provide reasonably high quality random bits.  The "input" from a
-   sound digitizer with no source plugged in or a camera with the lens
-   cap on, if the system has enough gain to detect anything, is
-   essentially thermal noise.
-
-   For example, on a SPARCstation, one can read from the /dev/audio
-   device with nothing plugged into the microphone jack.  Such data is
-   essentially random noise although it should not be trusted without
-   some checking in case of hardware failure.  It will, in any case,
-   need to be de-skewed as described elsewhere.
-
-   Combining this with compression to de-skew one can, in UNIXese,
-   generate a huge amount of medium quality random data by doing
-
-        cat /dev/audio | compress - >random-bits-file
-
-5.3.2 Using Existing Disk Drives
-
-   Disk drives have small random fluctuations in their rotational speed
-   due to chaotic air turbulence [DAVIS].  By adding low level disk seek
-   time instrumentation to a system, a series of measurements can be
-   obtained that include this randomness. Such data is usually highly
-   correlated so that significant processing is needed, including FFT
-   (see section 5.2.3).  Nevertheless experimentation has shown that,
-   with such processing, disk drives easily produce 100 bits a minute or
-   more of excellent random data.
-
-   Partly offsetting this need for processing is the fact that disk
-   drive failure will normally be rapidly noticed.  Thus, problems with
-   this method of random number generation due to hardware failure are
-   very unlikely.
-
-6. Recommended Non-Hardware Strategy
-
-   What is the best overall strategy for meeting the requirement for
-   unguessable random numbers in the absence of a reliable hardware
-   source?  It is to obtain random input from a large number of
-   uncorrelated sources and to mix them with a strong mixing function.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 14]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Such a function will preserve the randomness present in any of the
-   sources even if other quantities being combined are fixed or easily
-   guessable.  This may be advisable even with a good hardware source as
-   hardware can also fail, though this should be weighed against any
-   increase in the chance of overall failure due to added software
-   complexity.
-
-6.1 Mixing Functions
-
-   A strong mixing function is one which combines two or more inputs and
-   produces an output where each output bit is a different complex non-
-   linear function of all the input bits.  On average, changing any
-   input bit will change about half the output bits.  But because the
-   relationship is complex and non-linear, no particular output bit is
-   guaranteed to change when any particular input bit is changed.
-
-   Consider the problem of converting a stream of bits that is skewed
-   towards 0 or 1 to a shorter stream which is more random, as discussed
-   in Section 5.2 above.  This is simply another case where a strong
-   mixing function is desired, mixing the input bits to produce a
-   smaller number of output bits.  The technique given in Section 5.2.1
-   of using the parity of a number of bits is simply the result of
-   successively Exclusive Or'ing them which is examined as a trivial
-   mixing function immediately below.  Use of stronger mixing functions
-   to extract more of the randomness in a stream of skewed bits is
-   examined in Section 6.1.2.
-
-6.1.1 A Trivial Mixing Function
-
-   A trivial example for single bit inputs is the Exclusive Or function,
-   which is equivalent to addition without carry, as show in the table
-   below.  This is a degenerate case in which the one output bit always
-   changes for a change in either input bit.  But, despite its
-   simplicity, it will still provide a useful illustration.
-
-                   +-----------+-----------+----------+
-                   |  input 1  |  input 2  |  output  |
-                   +-----------+-----------+----------+
-                   |     0     |     0     |     0    |
-                   |     0     |     1     |     1    |
-                   |     1     |     0     |     1    |
-                   |     1     |     1     |     0    |
-                   +-----------+-----------+----------+
-
-   If inputs 1 and 2 are uncorrelated and combined in this fashion then
-   the output will be an even better (less skewed) random bit than the
-   inputs.  If we assume an "eccentricity" e as defined in Section 5.2
-   above, then the output eccentricity relates to the input eccentricity
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 15]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   as follows:
-
-        e       = 2 * e        * e
-         output        input 1    input 2
-
-   Since e is never greater than 1/2, the eccentricity is always
-   improved except in the case where at least one input is a totally
-   skewed constant.  This is illustrated in the following table where
-   the top and left side values are the two input eccentricities and the
-   entries are the output eccentricity:
-
-     +--------+--------+--------+--------+--------+--------+--------+
-     |    e   |  0.00  |  0.10  |  0.20  |  0.30  |  0.40  |  0.50  |
-     +--------+--------+--------+--------+--------+--------+--------+
-     |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |
-     |  0.10  |  0.00  |  0.02  |  0.04  |  0.06  |  0.08  |  0.10  |
-     |  0.20  |  0.00  |  0.04  |  0.08  |  0.12  |  0.16  |  0.20  |
-     |  0.30  |  0.00  |  0.06  |  0.12  |  0.18  |  0.24  |  0.30  |
-     |  0.40  |  0.00  |  0.08  |  0.16  |  0.24  |  0.32  |  0.40  |
-     |  0.50  |  0.00  |  0.10  |  0.20  |  0.30  |  0.40  |  0.50  |
-     +--------+--------+--------+--------+--------+--------+--------+
-
-   However, keep in mind that the above calculations assume that the
-   inputs are not correlated.  If the inputs were, say, the parity of
-   the number of minutes from midnight on two clocks accurate to a few
-   seconds, then each might appear random if sampled at random intervals
-   much longer than a minute.  Yet if they were both sampled and
-   combined with xor, the result would be zero most of the time.
-
-6.1.2 Stronger Mixing Functions
-
-   The US Government Data Encryption Standard [DES] is an example of a
-   strong mixing function for multiple bit quantities.  It takes up to
-   120 bits of input (64 bits of "data" and 56 bits of "key") and
-   produces 64 bits of output each of which is dependent on a complex
-   non-linear function of all input bits.  Other strong encryption
-   functions with this characteristic can also be used by considering
-   them to mix all of their key and data input bits.
-
-   Another good family of mixing functions are the "message digest" or
-   hashing functions such as The US Government Secure Hash Standard
-   [SHS] and the MD2, MD4, MD5 [MD2, MD4, MD5] series.  These functions
-   all take an arbitrary amount of input and produce an output mixing
-   all the input bits. The MD* series produce 128 bits of output and SHS
-   produces 160 bits.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 16]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Although the message digest functions are designed for variable
-   amounts of input, DES and other encryption functions can also be used
-   to combine any number of inputs.  If 64 bits of output is adequate,
-   the inputs can be packed into a 64 bit data quantity and successive
-   56 bit keys, padding with zeros if needed, which are then used to
-   successively encrypt using DES in Electronic Codebook Mode [DES
-   MODES].  If more than 64 bits of output are needed, use more complex
-   mixing.  For example, if inputs are packed into three quantities, A,
-   B, and C, use DES to encrypt A with B as a key and then with C as a
-   key to produce the 1st part of the output, then encrypt B with C and
-   then A for more output and, if necessary, encrypt C with A and then B
-   for yet more output.  Still more output can be produced by reversing
-   the order of the keys given above to stretch things. The same can be
-   done with the hash functions by hashing various subsets of the input
-   data to produce multiple outputs.  But keep in mind that it is
-   impossible to get more bits of "randomness" out than are put in.
-
-   An example of using a strong mixing function would be to reconsider
-   the case of a string of 308 bits each of which is biased 99% towards
-   zero.  The parity technique given in Section 5.2.1 above reduced this
-   to one bit with only a 1/1000 deviance from being equally likely a
-   zero or one.  But, applying the equation for information given in
-   Section 2, this 308 bit sequence has 5 bits of information in it.
-   Thus hashing it with SHS or MD5 and taking the bottom 5 bits of the
-   result would yield 5 unbiased random bits as opposed to the single
-   bit given by calculating the parity of the string.
-
-6.1.3 Diffie-Hellman as a Mixing Function
-
-   Diffie-Hellman exponential key exchange is a technique that yields a
-   shared secret between two parties that can be made computationally
-   infeasible for a third party to determine even if they can observe
-   all the messages between the two communicating parties.  This shared
-   secret is a mixture of initial quantities generated by each of them
-   [D-H].  If these initial quantities are random, then the shared
-   secret contains the combined randomness of them both, assuming they
-   are uncorrelated.
-
-6.1.4 Using a Mixing Function to Stretch Random Bits
-
-   While it is not necessary for a mixing function to produce the same
-   or fewer bits than its inputs, mixing bits cannot "stretch" the
-   amount of random unpredictability present in the inputs.  Thus four
-   inputs of 32 bits each where there is 12 bits worth of
-   unpredicatability (such as 4,096 equally probable values) in each
-   input cannot produce more than 48 bits worth of unpredictable output.
-   The output can be expanded to hundreds or thousands of bits by, for
-   example, mixing with successive integers, but the clever adversary's
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 17]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   search space is still 2^48 possibilities.  Furthermore, mixing to
-   fewer bits than are input will tend to strengthen the randomness of
-   the output the way using Exclusive Or to produce one bit from two did
-   above.
-
-   The last table in Section 6.1.1 shows that mixing a random bit with a
-   constant bit with Exclusive Or will produce a random bit.  While this
-   is true, it does not provide a way to "stretch" one random bit into
-   more than one.  If, for example, a random bit is mixed with a 0 and
-   then with a 1, this produces a two bit sequence but it will always be
-   either 01 or 10.  Since there are only two possible values, there is
-   still only the one bit of original randomness.
-
-6.1.5 Other Factors in Choosing a Mixing Function
-
-   For local use, DES has the advantages that it has been widely tested
-   for flaws, is widely documented, and is widely implemented with
-   hardware and software implementations available all over the world
-   including source code available by anonymous FTP.  The SHS and MD*
-   family are younger algorithms which have been less tested but there
-   is no particular reason to believe they are flawed.  Both MD5 and SHS
-   were derived from the earlier MD4 algorithm.  They all have source
-   code available by anonymous FTP [SHS, MD2, MD4, MD5].
-
-   DES and SHS have been vouched for the the US National Security Agency
-   (NSA) on the basis of criteria that primarily remain secret.  While
-   this is the cause of much speculation and doubt, investigation of DES
-   over the years has indicated that NSA involvement in modifications to
-   its design, which originated with IBM, was primarily to strengthen
-   it.  No concealed or special weakness has been found in DES.  It is
-   almost certain that the NSA modification to MD4 to produce the SHS
-   similarly strengthened the algorithm, possibly against threats not
-   yet known in the public cryptographic community.
-
-   DES, SHS, MD4, and MD5 are royalty free for all purposes.  MD2 has
-   been freely licensed only for non-profit use in connection with
-   Privacy Enhanced Mail [PEM].  Between the MD* algorithms, some people
-   believe that, as with "Goldilocks and the Three Bears", MD2 is strong
-   but too slow, MD4 is fast but too weak, and MD5 is just right.
-
-   Another advantage of the MD* or similar hashing algorithms over
-   encryption algorithms is that they are not subject to the same
-   regulations imposed by the US Government prohibiting the unlicensed
-   export or import of encryption/decryption software and hardware.  The
-   same should be true of DES rigged to produce an irreversible hash
-   code but most DES packages are oriented to reversible encryption.
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 18]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-6.2 Non-Hardware Sources of Randomness
-
-   The best source of input for mixing would be a hardware randomness
-   such as disk drive timing affected by air turbulence, audio input
-   with thermal noise, or radioactive decay.  However, if that is not
-   available there are other possibilities.  These include system
-   clocks, system or input/output buffers, user/system/hardware/network
-   serial numbers and/or addresses and timing, and user input.
-   Unfortunately, any of these sources can produce limited or
-   predicatable values under some circumstances.
-
-   Some of the sources listed above would be quite strong on multi-user
-   systems where, in essence, each user of the system is a source of
-   randomness.  However, on a small single user system, such as a
-   typical IBM PC or Apple Macintosh, it might be possible for an
-   adversary to assemble a similar configuration.  This could give the
-   adversary inputs to the mixing process that were sufficiently
-   correlated to those used originally as to make exhaustive search
-   practical.
-
-   The use of multiple random inputs with a strong mixing function is
-   recommended and can overcome weakness in any particular input.  For
-   example, the timing and content of requested "random" user keystrokes
-   can yield hundreds of random bits but conservative assumptions need
-   to be made.  For example, assuming a few bits of randomness if the
-   inter-keystroke interval is unique in the sequence up to that point
-   and a similar assumption if the key hit is unique but assuming that
-   no bits of randomness are present in the initial key value or if the
-   timing or key value duplicate previous values.  The results of mixing
-   these timings and characters typed could be further combined with
-   clock values and other inputs.
-
-   This strategy may make practical portable code to produce good random
-   numbers for security even if some of the inputs are very weak on some
-   of the target systems.  However, it may still fail against a high
-   grade attack on small single user systems, especially if the
-   adversary has ever been able to observe the generation process in the
-   past.  A hardware based random source is still preferable.
-
-6.3 Cryptographically Strong Sequences
-
-   In cases where a series of random quantities must be generated, an
-   adversary may learn some values in the sequence.  In general, they
-   should not be able to predict other values from the ones that they
-   know.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 19]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   The correct technique is to start with a strong random seed, take
-   cryptographically strong steps from that seed [CRYPTO2, CRYPTO3], and
-   do not reveal the complete state of the generator in the sequence
-   elements.  If each value in the sequence can be calculated in a fixed
-   way from the previous value, then when any value is compromised, all
-   future values can be determined.  This would be the case, for
-   example, if each value were a constant function of the previously
-   used values, even if the function were a very strong, non-invertible
-   message digest function.
-
-   It should be noted that if your technique for generating a sequence
-   of key values is fast enough, it can trivially be used as the basis
-   for a confidentiality system.  If two parties use the same sequence
-   generating technique and start with the same seed material, they will
-   generate identical sequences.  These could, for example, be xor'ed at
-   one end with data being send, encrypting it, and xor'ed with this
-   data as received, decrypting it due to the reversible properties of
-   the xor operation.
-
-6.3.1 Traditional Strong Sequences
-
-   A traditional way to achieve a strong sequence has been to have the
-   values be produced by hashing the quantities produced by
-   concatenating the seed with successive integers or the like and then
-   mask the values obtained so as to limit the amount of generator state
-   available to the adversary.
-
-   It may also be possible to use an "encryption" algorithm with a
-   random key and seed value to encrypt and feedback some or all of the
-   output encrypted value into the value to be encrypted for the next
-   iteration.  Appropriate feedback techniques will usually be
-   recommended with the encryption algorithm.  An example is shown below
-   where shifting and masking are used to combine the cypher output
-   feedback.  This type of feedback is recommended by the US Government
-   in connection with DES [DES MODES].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 20]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-      +---------------+
-      |       V       |
-      |  |     n      |
-      +--+------------+
-            |      |           +---------+
-            |      +---------> |         |      +-----+
-         +--+                  | Encrypt | <--- | Key |
-         |           +-------- |         |      +-----+
-         |           |         +---------+
-         V           V
-      +------------+--+
-      |      V     |  |
-      |       n+1     |
-      +---------------+
-
-   Note that if a shift of one is used, this is the same as the shift
-   register technique described in Section 3 above but with the all
-   important difference that the feedback is determined by a complex
-   non-linear function of all bits rather than a simple linear or
-   polynomial combination of output from a few bit position taps.
-
-   It has been shown by Donald W. Davies that this sort of shifted
-   partial output feedback significantly weakens an algorithm compared
-   will feeding all of the output bits back as input.  In particular,
-   for DES, repeated encrypting a full 64 bit quantity will give an
-   expected repeat in about 2^63 iterations.  Feeding back anything less
-   than 64 (and more than 0) bits will give an expected repeat in
-   between 2**31 and 2**32 iterations!
-
-   To predict values of a sequence from others when the sequence was
-   generated by these techniques is equivalent to breaking the
-   cryptosystem or inverting the "non-invertible" hashing involved with
-   only partial information available.  The less information revealed
-   each iteration, the harder it will be for an adversary to predict the
-   sequence.  Thus it is best to use only one bit from each value.  It
-   has been shown that in some cases this makes it impossible to break a
-   system even when the cryptographic system is invertible and can be
-   broken if all of each generated value was revealed.
-
-6.3.2 The Blum Blum Shub Sequence Generator
-
-   Currently the generator which has the strongest public proof of
-   strength is called the Blum Blum Shub generator after its inventors
-   [BBS].  It is also very simple and is based on quadratic residues.
-   It's only disadvantage is that is is computationally intensive
-   compared with the traditional techniques give in 6.3.1 above.  This
-   is not a serious draw back if it is used for moderately infrequent
-   purposes, such as generating session keys.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 21]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Simply choose two large prime numbers, say p and q, which both have
-   the property that you get a remainder of 3 if you divide them by 4.
-   Let n = p * q.  Then you choose a random number x relatively prime to
-   n.  The initial seed for the generator and the method for calculating
-   subsequent values are then
-
-                   2
-        s    =  ( x  )(Mod n)
-         0
-
-                   2
-        s    = ( s   )(Mod n)
-         i+1      i
-
-   You must be careful to use only a few bits from the bottom of each s.
-   It is always safe to use only the lowest order bit.  If you use no
-   more than the
-
-                  log  ( log  ( s  ) )
-                     2      2    i
-
-   low order bits, then predicting any additional bits from a sequence
-   generated in this manner is provable as hard as factoring n.  As long
-   as the initial x is secret, you can even make n public if you want.
-
-   An intersting characteristic of this generator is that you can
-   directly calculate any of the s values.  In particular
-
-                     i
-               ( ( 2  )(Mod (( p - 1 ) * ( q - 1 )) ) )
-      s  = ( s                                          )(Mod n)
-       i      0
-
-   This means that in applications where many keys are generated in this
-   fashion, it is not necessary to save them all.  Each key can be
-   effectively indexed and recovered from that small index and the
-   initial s and n.
-
-7. Key Generation Standards
-
-   Several public standards are now in place for the generation of keys.
-   Two of these are described below.  Both use DES but any equally
-   strong or stronger mixing function could be substituted.
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 22]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-7.1 US DoD Recommendations for Password Generation
-
-   The United States Department of Defense has specific recommendations
-   for password generation [DoD].  They suggest using the US Data
-   Encryption Standard [DES] in Output Feedback Mode [DES MODES] as
-   follows:
-
-        use an initialization vector determined from
-             the system clock,
-             system ID,
-             user ID, and
-             date and time;
-        use a key determined from
-             system interrupt registers,
-             system status registers, and
-             system counters; and,
-        as plain text, use an external randomly generated 64 bit
-        quantity such as 8 characters typed in by a system
-        administrator.
-
-   The password can then be calculated from the 64 bit "cipher text"
-   generated in 64-bit Output Feedback Mode.  As many bits as are needed
-   can be taken from these 64 bits and expanded into a pronounceable
-   word, phrase, or other format if a human being needs to remember the
-   password.
-
-7.2 X9.17 Key Generation
-
-   The American National Standards Institute has specified a method for
-   generating a sequence of keys as follows:
-
-        s  is the initial 64 bit seed
-         0
-
-        g  is the sequence of generated 64 bit key quantities
-         n
-
-        k is a random key reserved for generating this key sequence
-
-        t is the time at which a key is generated to as fine a resolution
-            as is available (up to 64 bits).
-
-        DES ( K, Q ) is the DES encryption of quantity Q with key K
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 23]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-        g    = DES ( k, DES ( k, t ) .xor. s  )
-         n                                  n
-
-        s    = DES ( k, DES ( k, t ) .xor. g  )
-         n+1                                n
-
-   If g sub n is to be used as a DES key, then every eighth bit should
-   be adjusted for parity for that use but the entire 64 bit unmodified
-   g should be used in calculating the next s.
-
-8. Examples of Randomness Required
-
-   Below are two examples showing rough calculations of needed
-   randomness for security.  The first is for moderate security
-   passwords while the second assumes a need for a very high security
-   cryptographic key.
-
-8.1  Password Generation
-
-   Assume that user passwords change once a year and it is desired that
-   the probability that an adversary could guess the password for a
-   particular account be less than one in a thousand.  Further assume
-   that sending a password to the system is the only way to try a
-   password.  Then the crucial question is how often an adversary can
-   try possibilities.  Assume that delays have been introduced into a
-   system so that, at most, an adversary can make one password try every
-   six seconds.  That's 600 per hour or about 15,000 per day or about
-   5,000,000 tries in a year.  Assuming any sort of monitoring, it is
-   unlikely someone could actually try continuously for a year.  In
-   fact, even if log files are only checked monthly, 500,000 tries is
-   more plausible before the attack is noticed and steps taken to change
-   passwords and make it harder to try more passwords.
-
-   To have a one in a thousand chance of guessing the password in
-   500,000 tries implies a universe of at least 500,000,000 passwords or
-   about 2^29.  Thus 29 bits of randomness are needed. This can probably
-   be achieved using the US DoD recommended inputs for password
-   generation as it has 8 inputs which probably average over 5 bits of
-   randomness each (see section 7.1).  Using a list of 1000 words, the
-   password could be expressed as a three word phrase (1,000,000,000
-   possibilities) or, using case insensitive letters and digits, six
-   would suffice ((26+10)^6 = 2,176,782,336 possibilities).
-
-   For a higher security password, the number of bits required goes up.
-   To decrease the probability by 1,000 requires increasing the universe
-   of passwords by the same factor which adds about 10 bits.  Thus to
-   have only a one in a million chance of a password being guessed under
-   the above scenario would require 39 bits of randomness and a password
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 24]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   that was a four word phrase from a 1000 word list or eight
-   letters/digits.  To go to a one in 10^9 chance, 49 bits of randomness
-   are needed implying a five word phrase or ten letter/digit password.
-
-   In a real system, of course, there are also other factors.  For
-   example, the larger and harder to remember passwords are, the more
-   likely users are to write them down resulting in an additional risk
-   of compromise.
-
-8.2 A Very High Security Cryptographic Key
-
-   Assume that a very high security key is needed for symmetric
-   encryption / decryption between two parties.  Assume an adversary can
-   observe communications and knows the algorithm being used.  Within
-   the field of random possibilities, the adversary can try key values
-   in hopes of finding the one in use.  Assume further that brute force
-   trial of keys is the best the adversary can do.
-
-8.2.1 Effort per Key Trial
-
-   How much effort will it take to try each key?  For very high security
-   applications it is best to assume a low value of effort.  Even if it
-   would clearly take tens of thousands of computer cycles or more to
-   try a single key, there may be some pattern that enables huge blocks
-   of key values to be tested with much less effort per key.  Thus it is
-   probably best to assume no more than a couple hundred cycles per key.
-   (There is no clear lower bound on this as computers operate in
-   parallel on a number of bits and a poor encryption algorithm could
-   allow many keys or even groups of keys to be tested in parallel.
-   However, we need to assume some value and can hope that a reasonably
-   strong algorithm has been chosen for our hypothetical high security
-   task.)
-
-   If the adversary can command a highly parallel processor or a large
-   network of work stations, 2*10^10 cycles per second is probably a
-   minimum assumption for availability today.  Looking forward just a
-   couple years, there should be at least an order of magnitude
-   improvement.  Thus assuming 10^9 keys could be checked per second or
-   3.6*10^11 per hour or 6*10^13 per week or 2.4*10^14 per month is
-   reasonable.  This implies a need for a minimum of 51 bits of
-   randomness in keys to be sure they cannot be found in a month.  Even
-   then it is possible that, a few years from now, a highly determined
-   and resourceful adversary could break the key in 2 weeks (on average
-   they need try only half the keys).
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 25]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-8.2.2 Meet in the Middle Attacks
-
-   If chosen or known plain text and the resulting encrypted text are
-   available, a "meet in the middle" attack is possible if the structure
-   of the encryption algorithm allows it.  (In a known plain text
-   attack, the adversary knows all or part of the messages being
-   encrypted, possibly some standard header or trailer fields.  In a
-   chosen plain text attack, the adversary can force some chosen plain
-   text to be encrypted, possibly by "leaking" an exciting text that
-   would then be sent by the adversary over an encrypted channel.)
-
-   An oversimplified explanation of the meet in the middle attack is as
-   follows: the adversary can half-encrypt the known or chosen plain
-   text with all possible first half-keys, sort the output, then half-
-   decrypt the encoded text with all the second half-keys.  If a match
-   is found, the full key can be assembled from the halves and used to
-   decrypt other parts of the message or other messages.  At its best,
-   this type of attack can halve the exponent of the work required by
-   the adversary while adding a large but roughly constant factor of
-   effort.  To be assured of safety against this, a doubling of the
-   amount of randomness in the key to a minimum of 102 bits is required.
-
-   The meet in the middle attack assumes that the cryptographic
-   algorithm can be decomposed in this way but we can not rule that out
-   without a deep knowledge of the algorithm.  Even if a basic algorithm
-   is not subject to a meet in the middle attack, an attempt to produce
-   a stronger algorithm by applying the basic algorithm twice (or two
-   different algorithms sequentially) with different keys may gain less
-   added security than would be expected.  Such a composite algorithm
-   would be subject to a meet in the middle attack.
-
-   Enormous resources may be required to mount a meet in the middle
-   attack but they are probably within the range of the national
-   security services of a major nation.  Essentially all nations spy on
-   other nations government traffic and several nations are believed to
-   spy on commercial traffic for economic advantage.
-
-8.2.3 Other Considerations
-
-   Since we have not even considered the possibilities of special
-   purpose code breaking hardware or just how much of a safety margin we
-   want beyond our assumptions above, probably a good minimum for a very
-   high security cryptographic key is 128 bits of randomness which
-   implies a minimum key length of 128 bits.  If the two parties agree
-   on a key by Diffie-Hellman exchange [D-H], then in principle only
-   half of this randomness would have to be supplied by each party.
-   However, there is probably some correlation between their random
-   inputs so it is probably best to assume that each party needs to
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 26]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   provide at least 96 bits worth of randomness for very high security
-   if Diffie-Hellman is used.
-
-   This amount of randomness is beyond the limit of that in the inputs
-   recommended by the US DoD for password generation and could require
-   user typing timing, hardware random number generation, or other
-   sources.
-
-   It should be noted that key length calculations such at those above
-   are controversial and depend on various assumptions about the
-   cryptographic algorithms in use.  In some cases, a professional with
-   a deep knowledge of code breaking techniques and of the strength of
-   the algorithm in use could be satisfied with less than half of the
-   key size derived above.
-
-9. Conclusion
-
-   Generation of unguessable "random" secret quantities for security use
-   is an essential but difficult task.
-
-   We have shown that hardware techniques to produce such randomness
-   would be relatively simple.  In particular, the volume and quality
-   would not need to be high and existing computer hardware, such as
-   disk drives, can be used.  Computational techniques are available to
-   process low quality random quantities from multiple sources or a
-   larger quantity of such low quality input from one source and produce
-   a smaller quantity of higher quality, less predictable key material.
-   In the absence of hardware sources of randomness, a variety of user
-   and software sources can frequently be used instead with care;
-   however, most modern systems already have hardware, such as disk
-   drives or audio input, that could be used to produce high quality
-   randomness.
-
-   Once a sufficient quantity of high quality seed key material (a few
-   hundred bits) is available, strong computational techniques are
-   available to produce cryptographically strong sequences of
-   unpredicatable quantities from this seed material.
-
-10. Security Considerations
-
-   The entirety of this document concerns techniques and recommendations
-   for generating unguessable "random" quantities for use as passwords,
-   cryptographic keys, and similar security uses.
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 27]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-References
-
-   [ASYMMETRIC] - Secure Communications and Asymmetric Cryptosystems,
-   edited by Gustavus J. Simmons, AAAS Selected Symposium 69, Westview
-   Press, Inc.
-
-   [BBS] - A Simple Unpredictable Pseudo-Random Number Generator, SIAM
-   Journal on Computing, v. 15, n. 2, 1986, L. Blum, M. Blum, & M. Shub.
-
-   [BRILLINGER] - Time Series: Data Analysis and Theory, Holden-Day,
-   1981, David Brillinger.
-
-   [CRC] - C.R.C. Standard Mathematical Tables, Chemical Rubber
-   Publishing Company.
-
-   [CRYPTO1] - Cryptography: A Primer, A Wiley-Interscience Publication,
-   John Wiley & Sons, 1981, Alan G. Konheim.
-
-   [CRYPTO2] - Cryptography:  A New Dimension in Computer Data Security,
-   A Wiley-Interscience Publication, John Wiley & Sons, 1982, Carl H.
-   Meyer & Stephen M. Matyas.
-
-   [CRYPTO3] - Applied Cryptography: Protocols, Algorithms, and Source
-   Code in C, John Wiley & Sons, 1994, Bruce Schneier.
-
-   [DAVIS] - Cryptographic Randomness from Air Turbulence in Disk
-   Drives, Advances in Cryptology - Crypto '94, Springer-Verlag Lecture
-   Notes in Computer Science #839, 1984, Don Davis, Ross Ihaka, and
-   Philip Fenstermacher.
-
-   [DES] -  Data Encryption Standard, United States of America,
-   Department of Commerce, National Institute of Standards and
-   Technology, Federal Information Processing Standard (FIPS) 46-1.
-   - Data Encryption Algorithm, American National Standards Institute,
-   ANSI X3.92-1981.
-   (See also FIPS 112, Password Usage, which includes FORTRAN code for
-   performing DES.)
-
-   [DES MODES] - DES Modes of Operation, United States of America,
-   Department of Commerce, National Institute of Standards and
-   Technology, Federal Information Processing Standard (FIPS) 81.
-   - Data Encryption Algorithm - Modes of Operation, American National
-   Standards Institute, ANSI X3.106-1983.
-
-   [D-H] - New Directions in Cryptography, IEEE Transactions on
-   Information Technology, November, 1976, Whitfield Diffie and Martin
-   E. Hellman.
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 28]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   [DoD] - Password Management Guideline, United States of America,
-   Department of Defense, Computer Security Center, CSC-STD-002-85.
-   (See also FIPS 112, Password Usage, which incorporates CSC-STD-002-85
-   as one of its appendices.)
-
-   [GIFFORD] - Natural Random Number, MIT/LCS/TM-371, September 1988,
-   David K. Gifford
-
-   [KNUTH] - The Art of Computer Programming, Volume 2: Seminumerical
-   Algorithms, Chapter 3: Random Numbers. Addison Wesley Publishing
-   Company, Second Edition 1982, Donald E. Knuth.
-
-   [KRAWCZYK] - How to Predict Congruential Generators, Journal of
-   Algorithms, V. 13, N. 4, December 1992, H. Krawczyk
-
-   [MD2] - The MD2 Message-Digest Algorithm, RFC1319, April 1992, B.
-   Kaliski
-   [MD4] - The MD4 Message-Digest Algorithm, RFC1320, April 1992, R.
-   Rivest
-   [MD5] - The MD5 Message-Digest Algorithm, RFC1321, April 1992, R.
-   Rivest
-
-   [PEM] - RFCs 1421 through 1424:
-   - RFC 1424, Privacy Enhancement for Internet Electronic Mail: Part
-   IV: Key Certification and Related Services, 02/10/1993, B. Kaliski
-   - RFC 1423, Privacy Enhancement for Internet Electronic Mail: Part
-   III: Algorithms, Modes, and Identifiers, 02/10/1993, D. Balenson
-   - RFC 1422, Privacy Enhancement for Internet Electronic Mail: Part
-   II: Certificate-Based Key Management, 02/10/1993, S. Kent
-   - RFC 1421, Privacy Enhancement for Internet Electronic Mail: Part I:
-   Message Encryption and Authentication Procedures, 02/10/1993, J. Linn
-
-   [SHANNON] - The Mathematical Theory of Communication, University of
-   Illinois Press, 1963, Claude E. Shannon.  (originally from:  Bell
-   System Technical Journal, July and October 1948)
-
-   [SHIFT1] - Shift Register Sequences, Aegean Park Press, Revised
-   Edition 1982, Solomon W. Golomb.
-
-   [SHIFT2] - Cryptanalysis of Shift-Register Generated Stream Cypher
-   Systems, Aegean Park Press, 1984, Wayne G. Barker.
-
-   [SHS] - Secure Hash Standard, United States of American, National
-   Institute of Science and Technology, Federal Information Processing
-   Standard (FIPS) 180, April 1993.
-
-   [STERN] - Secret Linear Congruential Generators are not
-   Cryptograhically Secure, Proceedings of IEEE STOC, 1987, J. Stern.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 29]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   [VON NEUMANN] - Various techniques used in connection with random
-   digits, von Neumann's Collected Works, Vol. 5, Pergamon Press, 1963,
-   J. von Neumann.
-
-Authors' Addresses
-
-   Donald E. Eastlake 3rd
-   Digital Equipment Corporation
-   550 King Street, LKG2-1/BB3
-   Littleton, MA 01460
-
-   Phone:   +1 508 486 6577(w)  +1 508 287 4877(h)
-   EMail:   dee@lkg.dec.com
-
-
-   Stephen D. Crocker
-   CyberCash Inc.
-   2086 Hunters Crest Way
-   Vienna, VA 22181
-
-   Phone:   +1 703-620-1222(w)  +1 703-391-2651 (fax)
-   EMail:   crocker@cybercash.com
-
-
-   Jeffrey I. Schiller
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-
-   Phone:   +1 617 253 0161(w)
-   EMail:   jis@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 30]
-
diff --git a/doc/standardisation/rfc1831.txt b/doc/standardisation/rfc1831.txt
deleted file mode 100644
index 0556c9e83..000000000
--- a/doc/standardisation/rfc1831.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      R. Srinivasan
-Request for Comments: 1831                              Sun Microsystems
-Category: Standards Track                                    August 1995
-
-
-      RPC: Remote Procedure Call Protocol Specification Version 2
-
-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.
-
-ABSTRACT
-
-   This document describes the ONC Remote Procedure Call (ONC RPC
-   Version 2) protocol as it is currently deployed and accepted.  "ONC"
-   stands for "Open Network Computing".
-
-TABLE OF CONTENTS
-
-      1. INTRODUCTION                                              2
-      2. TERMINOLOGY                                               2
-      3. THE RPC MODEL                                             2
-      4. TRANSPORTS AND SEMANTICS                                  4
-      5. BINDING AND RENDEZVOUS INDEPENDENCE                       5
-      6. AUTHENTICATION                                            5
-      7. RPC PROTOCOL REQUIREMENTS                                 5
-      7.1 RPC Programs and Procedures                              6
-      7.2 Authentication                                           7
-      7.3 Program Number Assignment                                8
-      7.4 Other Uses of the RPC Protocol                           8
-      7.4.1 Batching                                               8
-      7.4.2 Broadcast Remote Procedure Calls                       8
-      8. THE RPC MESSAGE PROTOCOL                                  9
-      9. AUTHENTICATION PROTOCOLS                                 12
-      9.1 Null Authentication                                     13
-      10. RECORD MARKING STANDARD                                 13
-      11. THE RPC LANGUAGE                                        13
-      11.1 An Example Service Described in the RPC Language       13
-      11.2 The RPC Language Specification                         14
-      11.3 Syntax Notes                                           15
-      APPENDIX A: SYSTEM AUTHENTICATION                           16
-      REFERENCES                                                  17
-      Security Considerations                                     18
-      Author's Address                                            18
-
-
-
-Srinivasan                  Standards Track                     [Page 1]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-1. INTRODUCTION
-
-   This document specifies version two of the message protocol used in
-   ONC Remote Procedure Call (RPC).  The message protocol is specified
-   with the eXternal Data Representation (XDR) language [9].  This
-   document assumes that the reader is familiar with XDR.  It does not
-   attempt to justify remote procedure calls systems or describe their
-   use.  The paper by Birrell and Nelson [1] is recommended as an
-   excellent background for the remote procedure call concept.
-
-2. TERMINOLOGY
-
-   This document discusses clients, calls, servers, replies, services,
-   programs, procedures, and versions.  Each remote procedure call has
-   two sides: an active client side that makes the call to a server,
-   which sends back a reply.  A network service is a collection of one
-   or more remote programs.  A remote program implements one or more
-   remote procedures; the procedures, their parameters, and results are
-   documented in the specific program's protocol specification.  A
-   server may support more than one version of a remote program in order
-   to be compatible with changing protocols.
-
-   For example, a network file service may be composed of two programs.
-   One program may deal with high-level applications such as file system
-   access control and locking.  The other may deal with low-level file
-   input and output and have procedures like "read" and "write".  A
-   client of the network file service would call the procedures
-   associated with the two programs of the service on behalf of the
-   client.
-
-   The terms client and server only apply to a particular transaction; a
-   particular hardware entity (host) or software entity (process or
-   program) could operate in both roles at different times.  For
-   example, a program that supplies remote execution service could also
-   be a client of a network file service.
-
-3. THE RPC MODEL
-
-   The ONC RPC protocol is based on the remote procedure call model,
-   which is similar to the local procedure call model.  In the local
-   case, the caller places arguments to a procedure in some well-
-   specified location (such as a register window).  It then transfers
-   control to the procedure, and eventually regains control.  At that
-   point, the results of the procedure are extracted from the well-
-   specified location, and the caller continues execution.
-
-
-
-
-
-
-Srinivasan                  Standards Track                     [Page 2]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-   The remote procedure call model is similar.  One thread of control
-   logically winds through two processes: the caller's process, and a
-   server's process.  The caller process first sends a call message to
-   the server process and waits (blocks) for a reply message.  The call
-   message includes the procedure's parameters, and the reply message
-   includes the procedure's results.  Once the reply message is
-   received, the results of the procedure are extracted, and caller's
-   execution is resumed.
-
-   On the server side, a process is dormant awaiting the arrival of a
-   call message.  When one arrives, the server process extracts the
-   procedure's parameters, computes the results, sends a reply message,
-   and then awaits the next call message.
-
-   In this model, only one of the two processes is active at any given
-   time.  However, this model is only given as an example.  The ONC RPC
-   protocol makes no restrictions on the concurrency model implemented,
-   and others are possible.  For example, an implementation may choose
-   to have RPC calls be asynchronous, so that the client may do useful
-   work while waiting for the reply from the server.  Another
-   possibility is to have the server create a separate task to process
-   an incoming call, so that the original server can be free to receive
-   other requests.
-
-   There are a few important ways in which remote procedure calls differ
-   from local procedure calls:
-
-      1. Error handling: failures of the remote server or network must
-      be handled when using remote procedure calls.
-
-      2. Global variables and side-effects: since the server does not
-      have access to the client's address space, hidden arguments cannot
-      be passed as global variables or returned as side effects.
-
-      3. Performance:  remote procedures usually operate one or more
-      orders of magnitude slower than local procedure calls.
-
-      4. Authentication: since remote procedure calls can be transported
-      over unsecured networks, authentication may be necessary.
-      Authentication prevents one entity from masquerading as some other
-      entity.
-
-   The conclusion is that even though there are tools to automatically
-   generate client and server libraries for a given service, protocols
-   must still be designed carefully.
-
-
-
-
-
-
-Srinivasan                  Standards Track                     [Page 3]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-4. TRANSPORTS AND SEMANTICS
-
-   The RPC protocol can be implemented on several different transport
-   protocols.  The RPC protocol does not care how a message is passed
-   from one process to another, but only with specification and
-   interpretation of messages.  However, the application may wish to
-   obtain information about (and perhaps control over) the transport
-   layer through an interface not specified in this document.  For
-   example, the transport protocol may impose a restriction on the
-   maximum size of RPC messages, or it may be stream-oriented like TCP
-   with no size limit.  The client and server must agree on their
-   transport protocol choices.
-
-   It is important to point out that RPC does not try to implement any
-   kind of reliability and that the application may need to be aware of
-   the type of transport protocol underneath RPC.  If it knows it is
-   running on top of a reliable transport such as TCP [6], then most of
-   the work is already done for it.  On the other hand, if it is running
-   on top of an unreliable transport such as UDP [7], it must implement
-   its own time-out, retransmission, and duplicate detection policies as
-   the RPC protocol does not provide these services.
-
-   Because of transport independence, the RPC protocol does not attach
-   specific semantics to the remote procedures or their execution
-   requirements.  Semantics can be inferred from (but should be
-   explicitly specified by) the underlying transport protocol.  For
-   example, consider RPC running on top of an unreliable transport such
-   as UDP.  If an application retransmits RPC call messages after time-
-   outs, and does not receive a reply, it cannot infer anything about
-   the number of times the procedure was executed.  If it does receive a
-   reply, then it can infer that the procedure was executed at least
-   once.
-
-   A server may wish to remember previously granted requests from a
-   client and not regrant them in order to insure some degree of
-   execute-at-most-once semantics.  A server can do this by taking
-   advantage of the transaction ID that is packaged with every RPC
-   message.  The main use of this transaction ID is by the client RPC
-   entity in matching replies to calls.  However, a client application
-   may choose to reuse its previous transaction ID when retransmitting a
-   call.  The server may choose to remember this ID after executing a
-   call and not execute calls with the same ID in order to achieve some
-   degree of execute-at-most-once semantics.  The server is not allowed
-   to examine this ID in any other way except as a test for equality.
-
-   On the other hand, if using a "reliable" transport such as TCP, the
-   application can infer from a reply message that the procedure was
-   executed exactly once, but if it receives no reply message, it cannot
-
-
-
-Srinivasan                  Standards Track                     [Page 4]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-   assume that the remote procedure was not executed.  Note that even if
-   a connection-oriented protocol like TCP is used, an application still
-   needs time-outs and reconnection to handle server crashes.
-
-   There are other possibilities for transports besides datagram- or
-   connection-oriented protocols.  For example, a request-reply protocol
-   such as VMTP [2] is perhaps a natural transport for RPC.  ONC RPC
-   uses both TCP and UDP transport protocols.  Section 10 (RECORD
-   MARKING STANDARD) describes the mechanism employed by ONC RPC to
-   utilize a connection-oriented, stream-oriented transport such as TCP.
-
-5. BINDING AND RENDEZVOUS INDEPENDENCE
-
-   The act of binding a particular client to a particular service and
-   transport parameters is NOT part of this RPC protocol specification.
-   This important and necessary function is left up to some higher-level
-   software.
-
-   Implementors could think of the RPC protocol as the jump-subroutine
-   instruction ("JSR") of a network; the loader (binder) makes JSR
-   useful, and the loader itself uses JSR to accomplish its task.
-   Likewise, the binding software makes RPC useful, possibly using RPC
-   to accomplish this task.
-
-6. AUTHENTICATION
-
-   The RPC protocol provides the fields necessary for a client to
-   identify itself to a service, and vice-versa, in each call and reply
-   message.  Security and access control mechanisms can be built on top
-   of this message authentication.  Several different authentication
-   protocols can be supported.  A field in the RPC header indicates
-   which protocol is being used. More information on specific
-   authentication protocols is in section 9: "Authentication Protocols".
-
-7. RPC PROTOCOL REQUIREMENTS
-
-   The RPC protocol must provide for the following:
-
-      (1) Unique specification of a procedure to be called.
-      (2) Provisions for matching response messages to request messages.
-      (3) Provisions for authenticating the caller to service and
-          vice-versa.
-
-
-
-
-
-
-
-
-
-Srinivasan                  Standards Track                     [Page 5]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-   Besides these requirements, features that detect the following are
-   worth supporting because of protocol roll-over errors, implementation
-   bugs, user error, and network administration:
-
-      (1) RPC protocol mismatches.
-      (2) Remote program protocol version mismatches.
-      (3) Protocol errors (such as misspecification of a procedure's
-          parameters).
-      (4) Reasons why remote authentication failed.
-      (5) Any other reasons why the desired procedure was not called.
-
-7.1 RPC Programs and Procedures
-
-   The RPC call message has three unsigned integer fields -- remote
-   program number, remote program version number, and remote procedure
-   number -- which uniquely identify the procedure to be called.
-   Program numbers are administered by a central authority
-   (rpc@sun.com).  Once implementors have a program number, they can
-   implement their remote program; the first implementation would most
-   likely have the version number 1.  Because most new protocols evolve,
-   a version field of the call message identifies which version of the
-   protocol the caller is using.  Version numbers enable support of both
-   old and new protocols through the same server process.
-
-   The procedure number identifies the procedure to be called.  These
-   numbers are documented in the specific program's protocol
-   specification.  For example, a file service's protocol specification
-   may state that its procedure number 5 is "read" and procedure number
-   12 is "write".
-
-   Just as remote program protocols may change over several versions,
-   the actual RPC message protocol could also change.  Therefore, the
-   call message also has in it the RPC version number, which is always
-   equal to two for the version of RPC described here.
-
-   The reply message to a request message has enough information to
-   distinguish the following error conditions:
-
-      (1) The remote implementation of RPC does not support protocol
-      version 2.  The lowest and highest supported RPC version numbers
-      are returned.
-
-      (2) The remote program is not available on the remote system.
-
-      (3) The remote program does not support the requested version
-      number.  The lowest and highest supported remote program version
-      numbers are returned.
-
-
-
-
-Srinivasan                  Standards Track                     [Page 6]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-      (4) The requested procedure number does not exist.  (This is
-      usually a client side protocol or programming error.)
-
-      (5) The parameters to the remote procedure appear to be garbage
-      from the server's point of view.  (Again, this is usually caused
-      by a disagreement about the protocol between client and service.)
-
-7.2 Authentication
-
-   Provisions for authentication of caller to service and vice-versa are
-   provided as a part of the RPC protocol.  The call message has two
-   authentication fields, the credential and verifier.  The reply
-   message has one authentication field, the response verifier.  The RPC
-   protocol specification defines all three fields to be the following
-   opaque type (in the eXternal Data Representation (XDR) language [9]):
-
-      enum auth_flavor {
-         AUTH_NONE       = 0,
-         AUTH_SYS        = 1,
-         AUTH_SHORT      = 2
-         /* and more to be defined */
-      };
-
-      struct opaque_auth {
-         auth_flavor flavor;
-         opaque body<400>;
-      };
-
-   In other words, any "opaque_auth" structure is an "auth_flavor"
-   enumeration followed by up to 400 bytes which are opaque to
-   (uninterpreted by) the RPC protocol implementation.
-
-   The interpretation and semantics of the data contained within the
-   authentication fields is specified by individual, independent
-   authentication protocol specifications.  (Section 9 defines the
-   various authentication protocols.)
-
-   If authentication parameters were rejected, the reply message
-   contains information stating why they were rejected.
-
-
-
-
-
-
-
-
-
-
-
-
-Srinivasan                  Standards Track                     [Page 7]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-7.3 Program Number Assignment
-
-   Program numbers are given out in groups of hexadecimal 20000000
-   (decimal 536870912) according to the following chart:
-
-              0 - 1fffffff   defined by rpc@sun.com
-       20000000 - 3fffffff   defined by user
-       40000000 - 5fffffff   transient
-       60000000 - 7fffffff   reserved
-       80000000 - 9fffffff   reserved
-       a0000000 - bfffffff   reserved
-       c0000000 - dfffffff   reserved
-       e0000000 - ffffffff   reserved
-
-   The first group is a range of numbers administered by rpc@sun.com and
-   should be identical for all sites.  The second range is for
-   applications peculiar to a particular site.  This range is intended
-   primarily for debugging new programs.  When a site develops an
-   application that might be of general interest, that application
-   should be given an assigned number in the first range.  Application
-   developers may apply for blocks of RPC program numbers in the first
-   range by sending electronic mail to "rpc@sun.com".  The third group
-   is for applications that generate program numbers dynamically.  The
-   final groups are reserved for future use, and should not be used.
-
-7.4 Other Uses of the RPC Protocol
-
-   The intended use of this protocol is for calling remote procedures.
-   Normally, each call message is matched with a reply message.
-   However, the protocol itself is a message-passing protocol with which
-   other (non-procedure call) protocols can be implemented.
-
-7.4.1 Batching
-
-   Batching is useful when a client wishes to send an arbitrarily large
-   sequence of call messages to a server.  Batching typically uses
-   reliable byte stream protocols (like TCP) for its transport.  In the
-   case of batching, the client never waits for a reply from the server,
-   and the server does not send replies to batch calls.  A sequence of
-   batch calls is usually terminated by a legitimate remote procedure
-   call operation in order to flush the pipeline and get positive
-   acknowledgement.
-
-7.4.2 Broadcast Remote Procedure Calls
-
-   In broadcast protocols, the client sends a broadcast call to the
-   network and waits for numerous replies.  This requires the use of
-   packet-based protocols (like UDP) as its transport protocol.  Servers
-
-
-
-Srinivasan                  Standards Track                     [Page 8]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-   that support broadcast protocols usually respond only when the call
-   is successfully processed and are silent in the face of errors, but
-   this varies with the application.
-
-   The principles of broadcast RPC also apply to multicasting - an RPC
-   request can be sent to a multicast address.
-
-8. THE RPC MESSAGE PROTOCOL
-
-   This section defines the RPC message protocol in the XDR data
-   description language [9].
-
-      enum msg_type {
-         CALL  = 0,
-         REPLY = 1
-      };
-
-   A reply to a call message can take on two forms: The message was
-   either accepted or rejected.
-
-      enum reply_stat {
-         MSG_ACCEPTED = 0,
-         MSG_DENIED   = 1
-      };
-
-   Given that a call message was accepted, the following is the status
-   of an attempt to call a remote procedure.
-
-      enum accept_stat {
-         SUCCESS       = 0, /* RPC executed successfully             */
-         PROG_UNAVAIL  = 1, /* remote hasn't exported program        */
-         PROG_MISMATCH = 2, /* remote can't support version #        */
-         PROC_UNAVAIL  = 3, /* program can't support procedure       */
-         GARBAGE_ARGS  = 4, /* procedure can't decode params         */
-         SYSTEM_ERR    = 5  /* errors like memory allocation failure */
-      };
-
-   Reasons why a call message was rejected:
-
-      enum reject_stat {
-         RPC_MISMATCH = 0, /* RPC version number != 2          */
-         AUTH_ERROR = 1    /* remote can't authenticate caller */
-      };
-
-   Why authentication failed:
-
-      enum auth_stat {
-         AUTH_OK           = 0,  /* success                          */
-
-
-
-Srinivasan                  Standards Track                     [Page 9]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-         /*
-          * failed at remote end
-          */
-         AUTH_BADCRED      = 1,  /* bad credential (seal broken)     */
-         AUTH_REJECTEDCRED = 2,  /* client must begin new session    */
-         AUTH_BADVERF      = 3,  /* bad verifier (seal broken)       */
-         AUTH_REJECTEDVERF = 4,  /* verifier expired or replayed     */
-         AUTH_TOOWEAK      = 5,  /* rejected for security reasons    */
-         /*
-          * failed locally
-          */
-         AUTH_INVALIDRESP  = 6,  /* bogus response verifier          */
-         AUTH_FAILED       = 7   /* reason unknown                   */
-      };
-
-   The RPC message:
-
-   All messages start with a transaction identifier, xid, followed by a
-   two-armed discriminated union.  The union's discriminant is a
-   msg_type which switches to one of the two types of the message.  The
-   xid of a REPLY message always matches that of the initiating CALL
-   message.  NB: The xid field is only used for clients matching reply
-   messages with call messages or for servers detecting retransmissions;
-   the service side cannot treat this id as any type of sequence number.
-
-      struct rpc_msg {
-         unsigned int xid;
-         union switch (msg_type mtype) {
-         case CALL:
-            call_body cbody;
-         case REPLY:
-            reply_body rbody;
-         } body;
-      };
-
-   Body of an RPC call:
-
-   In version 2 of the RPC protocol specification, rpcvers must be equal
-   to 2.  The fields prog, vers, and proc specify the remote program,
-   its version number, and the procedure within the remote program to be
-   called.  After these fields are two authentication parameters:  cred
-   (authentication credential) and verf (authentication verifier).  The
-   two authentication parameters are followed by the parameters to the
-   remote procedure, which are specified by the specific program
-   protocol.
-
-   The purpose of the authentication verifier is to validate the
-   authentication credential.  Note that these two items are
-
-
-
-Srinivasan                  Standards Track                    [Page 10]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-   historically separate, but are always used together as one logical
-   entity.
-
-      struct call_body {
-         unsigned int rpcvers;       /* must be equal to two (2) */
-         unsigned int prog;
-         unsigned int vers;
-         unsigned int proc;
-         opaque_auth  cred;
-         opaque_auth  verf;
-         /* procedure specific parameters start here */
-      };
-
-   Body of a reply to an RPC call:
-
-      union reply_body switch (reply_stat stat) {
-      case MSG_ACCEPTED:
-         accepted_reply areply;
-      case MSG_DENIED:
-         rejected_reply rreply;
-      } reply;
-
-   Reply to an RPC call that was accepted by the server:
-
-   There could be an error even though the call was accepted.  The first
-   field is an authentication verifier that the server generates in
-   order to validate itself to the client.  It is followed by a union
-   whose discriminant is an enum accept_stat.  The SUCCESS arm of the
-   union is protocol specific.  The PROG_UNAVAIL, PROC_UNAVAIL,
-   GARBAGE_ARGS, and SYSTEM_ERR arms of the union are void.  The
-   PROG_MISMATCH arm specifies the lowest and highest version numbers of
-   the remote program supported by the server.
-
-      struct accepted_reply {
-         opaque_auth verf;
-         union switch (accept_stat stat) {
-         case SUCCESS:
-            opaque results[0];
-            /*
-             * procedure-specific results start here
-             */
-          case PROG_MISMATCH:
-             struct {
-                unsigned int low;
-                unsigned int high;
-             } mismatch_info;
-          default:
-             /*
-
-
-
-Srinivasan                  Standards Track                    [Page 11]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-              * Void.  Cases include PROG_UNAVAIL, PROC_UNAVAIL,
-              * GARBAGE_ARGS, and SYSTEM_ERR.
-              */
-             void;
-          } reply_data;
-      };
-
-   Reply to an RPC call that was rejected by the server:
-
-   The call can be rejected for two reasons: either the server is not
-   running a compatible version of the RPC protocol (RPC_MISMATCH), or
-   the server rejects the identity of the caller (AUTH_ERROR). In case
-   of an RPC version mismatch, the server returns the lowest and highest
-   supported RPC version numbers.  In case of invalid authentication,
-   failure status is returned.
-
-      union rejected_reply switch (reject_stat stat) {
-      case RPC_MISMATCH:
-         struct {
-            unsigned int low;
-            unsigned int high;
-         } mismatch_info;
-      case AUTH_ERROR:
-         auth_stat stat;
-      };
-
-9. AUTHENTICATION PROTOCOLS
-
-   As previously stated, authentication parameters are opaque, but
-   open-ended to the rest of the RPC protocol.  This section defines two
-   standard "flavors" of authentication.  Implementors are free to
-   invent new authentication types, with the same rules of flavor number
-   assignment as there is for program number assignment.  The "flavor"
-   of a credential or verifier refers to the value of the "flavor" field
-   in the opaque_auth structure. Flavor numbers, like RPC program
-   numbers, are also administered centrally, and developers may assign
-   new flavor numbers by applying through electronic mail to
-   "rpc@sun.com".  Credentials and verifiers are represented as variable
-   length opaque data (the "body" field in the opaque_auth structure).
-
-   In this document, two flavors of authentication are described.  Of
-   these, Null authentication (described in the next subsection) is
-   mandatory - it must be available in all implementations.  System
-   authentication is described in Appendix A.  It is strongly
-   recommended that implementors include System authentication in their
-   implementations.  Many applications use this style of authentication,
-   and availability of this flavor in an implementation will enhance
-   interoperability.
-
-
-
-Srinivasan                  Standards Track                    [Page 12]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-9.1 Null Authentication
-
-   Often calls must be made where the client does not care about its
-   identity or the server does not care who the client is.  In this
-   case, the flavor of the RPC message's credential, verifier, and reply
-   verifier is "AUTH_NONE".  Opaque data associated with "AUTH_NONE" is
-   undefined.  It is recommended that the length of the opaque data be
-   zero.
-
-10. RECORD MARKING STANDARD
-
-   When RPC messages are passed on top of a byte stream transport
-   protocol (like TCP), it is necessary to delimit one message from
-   another in order to detect and possibly recover from protocol errors.
-   This is called record marking (RM).  One RPC message fits into one RM
-   record.
-
-   A record is composed of one or more record fragments.  A record
-   fragment is a four-byte header followed by 0 to (2**31) - 1 bytes of
-   fragment data.  The bytes encode an unsigned binary number; as with
-   XDR integers, the byte order is from highest to lowest.  The number
-   encodes two values -- a boolean which indicates whether the fragment
-   is the last fragment of the record (bit value 1 implies the fragment
-   is the last fragment) and a 31-bit unsigned binary value which is the
-   length in bytes of the fragment's data.  The boolean value is the
-   highest-order bit of the header; the length is the 31 low-order bits.
-   (Note that this record specification is NOT in XDR standard form!)
-
-11. THE RPC LANGUAGE
-
-   Just as there was a need to describe the XDR data-types in a formal
-   language, there is also need to describe the procedures that operate
-   on these XDR data-types in a formal language as well.  The RPC
-   Language is an extension to the XDR language, with the addition of
-   "program", "procedure", and "version" declarations.  The following
-   example is used to describe the essence of the language.
-
-11.1 An Example Service Described in the RPC Language
-
-   Here is an example of the specification of a simple ping program.
-
-   program PING_PROG {
-         /*
-          * Latest and greatest version
-          */
-         version PING_VERS_PINGBACK {
-            void
-            PINGPROC_NULL(void) = 0;
-
-
-
-Srinivasan                  Standards Track                    [Page 13]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-            /*
-             * Ping the client, return the round-trip time
-             * (in microseconds). Returns -1 if the operation
-             * timed out.
-             */
-            int
-            PINGPROC_PINGBACK(void) = 1;
-         } = 2;
-
-         /*
-          * Original version
-          */
-         version PING_VERS_ORIG {
-            void
-            PINGPROC_NULL(void) = 0;
-         } = 1;
-      } = 1;
-
-      const PING_VERS = 2;      /* latest version */
-
-   The first version described is PING_VERS_PINGBACK with two
-   procedures, PINGPROC_NULL and PINGPROC_PINGBACK.  PINGPROC_NULL takes
-   no arguments and returns no results, but it is useful for computing
-   round-trip times from the client to the server and back again.  By
-   convention, procedure 0 of any RPC protocol should have the same
-   semantics, and never require any kind of authentication.  The second
-   procedure is used for the client to have the server do a reverse ping
-   operation back to the client, and it returns the amount of time (in
-   microseconds) that the operation used.  The next version,
-   PING_VERS_ORIG, is the original version of the protocol and it does
-   not contain PINGPROC_PINGBACK procedure. It is useful for
-   compatibility with old client programs, and as this program matures
-   it may be dropped from the protocol entirely.
-
-11.2 The RPC Language Specification
-
-   The RPC language is identical to the XDR language defined in RFC
-   1014, except for the added definition of a "program-def" described
-   below.
-
-   program-def:
-      "program" identifier "{"
-         version-def
-         version-def *
-      "}" "=" constant ";"
-
-   version-def:
-      "version" identifier "{"
-
-
-
-Srinivasan                  Standards Track                    [Page 14]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-          procedure-def
-          procedure-def *
-      "}" "=" constant ";"
-
-   procedure-def:
-      type-specifier identifier "(" type-specifier
-        ("," type-specifier )* ")" "=" constant ";"
-
-11.3 Syntax Notes
-
-   (1) The following keywords are added and cannot be used as
-   identifiers: "program" and "version";
-
-   (2) A version name cannot occur more than once within the scope of a
-   program definition. Nor can a version number occur more than once
-   within the scope of a program definition.
-
-   (3) A procedure name cannot occur more than once within the scope of
-   a version definition. Nor can a procedure number occur more than once
-   within the scope of version definition.
-
-   (4) Program identifiers are in the same name space as constant and
-   type identifiers.
-
-   (5) Only unsigned constants can be assigned to programs, versions and
-   procedures.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Srinivasan                  Standards Track                    [Page 15]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-APPENDIX A: SYSTEM AUTHENTICATION
-
-   The client may wish to identify itself, for example, as it is
-   identified on a UNIX(tm) system.  The flavor of the client credential
-   is "AUTH_SYS".  The opaque data constituting the credential encodes
-   the following structure:
-
-      struct authsys_parms {
-         unsigned int stamp;
-         string machinename<255>;
-         unsigned int uid;
-         unsigned int gid;
-         unsigned int gids<16>;
-      };
-
-   The "stamp" is an arbitrary ID which the caller machine may generate.
-   The "machinename" is the name of the caller's machine (like
-   "krypton").  The "uid" is the caller's effective user ID.  The "gid"
-   is the caller's effective group ID.  The "gids" is a counted array of
-   groups which contain the caller as a member.  The verifier
-   accompanying the credential should have "AUTH_NONE" flavor value
-   (defined above).  Note this credential is only unique within a
-   particular domain of machine names, uids, and gids.
-
-   The flavor value of the verifier received in the reply message from
-   the server may be "AUTH_NONE" or "AUTH_SHORT".  In the case of
-   "AUTH_SHORT", the bytes of the reply verifier's string encode an
-   opaque structure.  This new opaque structure may now be passed to the
-   server instead of the original "AUTH_SYS" flavor credential.  The
-   server may keep a cache which maps shorthand opaque structures
-   (passed back by way of an "AUTH_SHORT" style reply verifier) to the
-   original credentials of the caller.  The caller can save network
-   bandwidth and server cpu cycles by using the shorthand credential.
-
-   The server may flush the shorthand opaque structure at any time.  If
-   this happens, the remote procedure call message will be rejected due
-   to an authentication error.  The reason for the failure will be
-   "AUTH_REJECTEDCRED".  At this point, the client may wish to try the
-   original "AUTH_SYS" style of credential.
-
-   It should be noted that use of this flavor of authentication does not
-   guarantee any security for the users or providers of a service, in
-   itself.  The authentication provided by this scheme can be considered
-   legitimate only when applications using this scheme and the network
-   can be secured externally, and privileged transport addresses are
-   used for the communicating end-points (an example of this is the use
-   of privileged TCP/UDP ports in Unix systems - note that not all
-   systems enforce privileged transport address mechanisms).
-
-
-
-Srinivasan                  Standards Track                    [Page 16]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-REFERENCES
-
-   [1]  Birrell, A. D.  & Nelson, B. J., "Implementing Remote Procedure
-        Calls", XEROX CSL-83-7, October 1983.
-
-   [2]  Cheriton, D., "VMTP: Versatile Message Transaction Protocol",
-        Preliminary Version 0.3, Stanford University, January 1987.
-
-   [3]  Diffie & Hellman, "New Directions in Cryptography", IEEE
-        Transactions on Information Theory IT-22, November 1976.
-
-   [4]  Mills, D., "Network Time Protocol", RFC 1305, UDEL,
-        March 1992.
-
-   [5]  National Bureau of Standards, "Data Encryption Standard",
-        Federal Information Processing Standards Publication 46, January
-        1977.
-
-   [6]  Postel, J., "Transmission Control Protocol - DARPA Internet
-        Program Protocol Specification", STD 7, RFC 793, USC/Information
-        Sciences Institute, September 1981.
-
-   [7]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
-        USC/Information Sciences Institute, August 1980.
-
-   [8]  Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
-        RFC 1700, USC/Information Sciences Institute, October 1994.
-
-   [9]  Srinivasan, R., "XDR: External Data Representation Standard",
-        RFC 1832, Sun Microsystems, Inc., August 1995.
-
-   [10] Miller, S., Neuman, C., Schiller, J., and  J. Saltzer, "Section
-        E.2.1: Kerberos  Authentication and Authorization System",
-        M.I.T. Project Athena, Cambridge, Massachusetts, December 21,
-        1987.
-
-   [11] Steiner, J., Neuman, C., and J. Schiller, "Kerberos: An
-        Authentication Service for Open Network Systems", pp. 191-202 in
-        Usenix Conference Proceedings, Dallas, Texas, February 1988.
-
-   [12] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
-        Service (V5)", RFC 1510, Digital Equipment Corporation,
-        USC/Information Sciences Institute, September 1993.
-
-
-
-
-
-
-
-
-Srinivasan                  Standards Track                    [Page 17]
-
-RFC 1831        Remote Procedure Call Protocol Version 2     August 1995
-
-
-Security Considerations
-
-   Security issues are not discussed in this memo.
-
-Author's Address
-
-   Raj Srinivasan
-   Sun Microsystems, Inc.
-   ONC Technologies
-   2550 Garcia Avenue
-   M/S MTV-5-40
-   Mountain View, CA  94043
-   USA
-
-   Phone: 415-336-2478
-   Fax:   415-336-6015
-   EMail: raj@eng.sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Srinivasan                  Standards Track                    [Page 18]
-
diff --git a/doc/standardisation/rfc1964.txt b/doc/standardisation/rfc1964.txt
deleted file mode 100644
index f2960b961..000000000
--- a/doc/standardisation/rfc1964.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            J. Linn
-Request for Comments: 1964                       OpenVision Technologies
-Category: Standards Track                                      June 1996
-
-
-                The Kerberos Version 5 GSS-API Mechanism
-
-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.
-
-ABSTRACT
-
-   This specification defines protocols, procedures, and conventions to
-   be employed by peers implementing the Generic Security Service
-   Application Program Interface (as specified in RFCs 1508 and 1509)
-   when using Kerberos Version 5 technology (as specified in RFC 1510).
-
-ACKNOWLEDGMENTS
-
-   Much of the material in this memo is based on working documents
-   drafted by John Wray of Digital Equipment Corporation and on
-   discussions, implementation activities, and interoperability testing
-   involving Marc Horowitz, Ted Ts'o, and John Wray.  Particular thanks
-   are due to each of these individuals for their contributions towards
-   development and availability of GSS-API support within the Kerberos
-   Version 5 code base.
-
-1. Token Formats
-
-   This section discusses protocol-visible characteristics of the GSS-
-   API mechanism to be implemented atop Kerberos V5 security technology
-   per RFC-1508 and RFC-1510; it defines elements of protocol for
-   interoperability and is independent of language bindings per RFC-
-   1509.
-
-   Tokens transferred between GSS-API peers (for security context
-   management and per-message protection purposes) are defined.  The
-   data elements exchanged between a GSS-API endpoint implementation and
-   the Kerberos KDC are not specific to GSS-API usage and are therefore
-   defined within RFC-1510 rather than within this specification.
-
-
-
-
-
-
-Linn                        Standards Track                     [Page 1]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-   To support ongoing experimentation, testing, and evolution of the
-   specification, the Kerberos V5 GSS-API mechanism as defined in this
-   and any successor memos will be identified with the following Object
-   Identifier, as defined in RFC-1510, until the specification is
-   advanced to the level of Proposed Standard RFC:
-
-   {iso(1), org(3), dod(5), internet(1), security(5), kerberosv5(2)}
-
-   Upon advancement to the level of Proposed Standard RFC, the Kerberos
-   V5 GSS-API mechanism will be identified by an Object Identifier
-   having the value:
-
-   {iso(1) member-body(2) United States(840) mit(113554) infosys(1)
-   gssapi(2) krb5(2)}
-
-1.1. Context Establishment Tokens
-
-   Per RFC-1508, Appendix B, the initial context establishment token
-   will be enclosed within framing as follows:
-
-   InitialContextToken ::=
-   [APPLICATION 0] IMPLICIT SEQUENCE {
-           thisMech        MechType
-                   -- MechType is OBJECT IDENTIFIER
-                   -- representing "Kerberos V5"
-           innerContextToken ANY DEFINED BY thisMech
-                   -- contents mechanism-specific;
-                   -- ASN.1 usage within innerContextToken
-                   -- is not required
-           }
-
-   The innerContextToken of the initial context token will consist of a
-   Kerberos V5 KRB_AP_REQ message, preceded by a two-byte token-id
-   (TOK_ID) field, which shall contain the value 01 00.
-
-   The above GSS-API framing shall be applied to all tokens emitted by
-   the Kerberos V5 GSS-API mechanism, including KRB_AP_REP, KRB_ERROR,
-   context-deletion, and per-message tokens, not just to the initial
-   token in a context establishment sequence.  While not required by
-   RFC-1508, this enables implementations to perform enhanced error-
-   checking. The innerContextToken field of context establishment tokens
-   for the Kerberos V5 GSS-API mechanism will contain a Kerberos message
-   (KRB_AP_REQ, KRB_AP_REP or KRB_ERROR), preceded by a 2-byte TOK_ID
-   field containing 01 00 for KRB_AP_REQ messages, 02 00 for KRB_AP_REP
-   messages and 03 00 for KRB_ERROR messages.
-
-
-
-
-
-
-Linn                        Standards Track                     [Page 2]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-1.1.1. Initial Token
-
-   Relevant KRB_AP_REQ syntax (from RFC-1510) is as follows:
-
-   AP-REQ ::= [APPLICATION 14] SEQUENCE {
-           pvno [0]        INTEGER,        -- indicates Version 5
-           msg-type [1]    INTEGER,        -- indicates KRB_AP_REQ
-           ap-options[2]   APOptions,
-           ticket[3]       Ticket,
-           authenticator[4]        EncryptedData
-   }
-
-   APOptions ::= BIT STRING {
-           reserved (0),
-           use-session-key (1),
-           mutual-required (2)
-   }
-
-   Ticket ::= [APPLICATION 1] SEQUENCE {
-           tkt-vno [0]     INTEGER,        -- indicates Version 5
-           realm [1]       Realm,
-           sname [2]       PrincipalName,
-           enc-part [3]    EncryptedData
-   }
-
-   -- Encrypted part of ticket
-   EncTicketPart ::= [APPLICATION 3] SEQUENCE {
-           flags[0]        TicketFlags,
-           key[1]          EncryptionKey,
-           crealm[2]       Realm,
-           cname[3]        PrincipalName,
-           transited[4]    TransitedEncoding,
-           authtime[5]     KerberosTime,
-           starttime[6]    KerberosTime OPTIONAL,
-           endtime[7]      KerberosTime,
-           renew-till[8]   KerberosTime OPTIONAL,
-           caddr[9]        HostAddresses OPTIONAL,
-           authorization-data[10]  AuthorizationData OPTIONAL
-   }
-
-   -- Unencrypted authenticator
-   Authenticator ::= [APPLICATION 2] SEQUENCE  {
-           authenticator-vno[0]    INTEGER,
-           crealm[1]               Realm,
-           cname[2]                PrincipalName,
-           cksum[3]                Checksum OPTIONAL,
-           cusec[4]                INTEGER,
-           ctime[5]                KerberosTime,
-
-
-
-Linn                        Standards Track                     [Page 3]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-           subkey[6]               EncryptionKey OPTIONAL,
-           seq-number[7]           INTEGER OPTIONAL,
-           authorization-data[8]   AuthorizationData OPTIONAL
-   }
-
-   For purposes of this specification, the authenticator shall include
-   the optional sequence number, and the checksum field shall be used to
-   convey channel binding, service flags, and optional delegation
-   information.  The checksum will have a type of 0x8003 (a value being
-   registered within the Kerberos protocol specification), and a value
-   field of at least 24 bytes in length.  The length of the value field
-   is extended beyond 24 bytes if and only if an optional facility to
-   carry a Kerberos-defined KRB_CRED message for delegation purposes is
-   supported by an implementation and active on a context. When
-   delegation is active, a TGT with its FORWARDABLE flag set will be
-   transferred within the KRB_CRED message.
-
-   The checksum value field's format is as follows:
-
-   Byte    Name    Description
-   0..3    Lgth    Number of bytes in Bnd field;
-                   Currently contains hex 10 00 00 00
-                   (16, represented in little-endian form)
-   4..19   Bnd     MD5 hash of channel bindings, taken over all non-null
-                   components of bindings, in order of declaration.
-                   Integer fields within channel bindings are represented
-                   in little-endian order for the purposes of the MD5
-                   calculation.
-   20..23  Flags   Bit vector of context-establishment flags,
-                   with values consistent with RFC-1509, p. 41:
-                           GSS_C_DELEG_FLAG:       1
-                           GSS_C_MUTUAL_FLAG:      2
-                           GSS_C_REPLAY_FLAG:      4
-                           GSS_C_SEQUENCE_FLAG:    8
-                           GSS_C_CONF_FLAG:        16
-                           GSS_C_INTEG_FLAG:       32
-                   The resulting bit vector is encoded into bytes 20..23
-                   in little-endian form.
-   24..25  DlgOpt  The Delegation Option identifier (=1) [optional]
-   26..27  Dlgth   The length of the Deleg field. [optional]
-   28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional]
-
-   In computing the contents of the "Bnd" field, the following detailed
-   points apply:
-
-        (1) Each integer field shall be formatted into four bytes, using
-        little-endian byte ordering, for purposes of MD5 hash
-        computation.
-
-
-
-Linn                        Standards Track                     [Page 4]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-        (2) All input length fields within gss_buffer_desc elements of a
-        gss_channel_bindings_struct, even those which are zero-valued,
-        shall be included in the hash calculation; the value elements of
-        gss_buffer_desc elements shall be dereferenced, and the
-        resulting data shall be included within the hash computation,
-        only for the case of gss_buffer_desc elements having non-zero
-        length specifiers.
-
-        (3) If the caller passes the value GSS_C_NO_BINDINGS instead of
-        a valid channel bindings structure, the Bnd field shall be set
-        to 16 zero-valued bytes.
-
-   In the initial Kerberos V5 GSS-API mechanism token (KRB_AP_REQ token)
-   from initiator to target, the GSS_C_DELEG_FLAG, GSS_C_MUTUAL_FLAG,
-   GSS_C_REPLAY_FLAG, and GSS_C_SEQUENCE_FLAG values shall each be set
-   as the logical AND of the initiator's corresponding request flag to
-   GSS_Init_sec_context() and a Boolean indicator of whether that
-   optional service is available to GSS_Init_sec_context()'s caller.
-   GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG, for which no corresponding
-   context-level input indicator flags to GSS_Init_sec_context() exist,
-   shall each be set to indicate whether their respective per-message
-   protection services are available for use on the context being
-   established.
-
-   When input source address channel binding values are provided by a
-   caller (i.e., unless the input argument is GSS_C_NO_BINDINGS or the
-   source address specifier value within the input structure is
-   GSS_C_NULL_ADDRTYPE), and the corresponding token received from the
-   context's peer bears address restrictions, it is recommended that an
-   implementation of the Kerberos V5 GSS-API mechanism should check that
-   the source address as provided by the caller matches that in the
-   received token, and should return the GSS_S_BAD_BINDINGS major_status
-   value if a mismatch is detected. Note: discussion is ongoing about
-   the strength of recommendation to be made in this area, and on the
-   circumstances under which such a recommendation should be applicable;
-   implementors are therefore advised that changes on this matter may be
-   included in subsequent versions of this specification.
-
-1.1.2. Response Tokens
-
-   A context establishment sequence based on the Kerberos V5 mechanism
-   will perform one-way authentication (without confirmation or any
-   return token from target to initiator in response to the initiator's
-   KRB_AP_REQ) if the mutual_req bit is not set in the application's
-   call to GSS_Init_sec_context().  Applications requiring confirmation
-   that their authentication was successful should request mutual
-   authentication, resulting in a "mutual-required" indication within
-   KRB_AP_REQ APoptions and the setting of the mutual_req bit in the
-
-
-
-Linn                        Standards Track                     [Page 5]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-   flags field of the authenticator checksum.  In response to such a
-   request, the context target will reply to the initiator with a token
-   containing either a KRB_AP_REP or KRB_ERROR, completing the mutual
-   context establishment exchange.
-
-   Relevant KRB_AP_REP syntax is as follows:
-
-   AP-REP ::= [APPLICATION 15] SEQUENCE {
-           pvno [0]        INTEGER,        -- represents Kerberos V5
-           msg-type [1]    INTEGER,        -- represents KRB_AP_REP
-           enc-part [2]    EncryptedData
-   }
-
-   EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
-           ctime [0]       KerberosTime,
-           cusec [1]       INTEGER,
-           subkey [2]      EncryptionKey OPTIONAL,
-           seq-number [3]  INTEGER OPTIONAL
-   }
-
-   The optional seq-number element within the AP-REP's EncAPRepPart
-   shall be included.
-
-   The syntax of KRB_ERROR is 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
-   }
-
-   Values to be transferred in the error-code field of a KRB-ERROR
-   message are defined in [RFC-1510], not in this specification.
-
-
-
-
-
-
-
-
-Linn                        Standards Track                     [Page 6]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-1.2. Per-Message and Context Deletion Tokens
-
-   Three classes of tokens are defined in this section: "MIC" tokens,
-   emitted by calls to GSS_GetMIC() (formerly GSS_Sign()) and consumed
-   by calls to GSS_VerifyMIC() (formerly GSS_Verify()), "Wrap" tokens,
-   emitted by calls to GSS_Wrap() (formerly GSS_Seal()) and consumed by
-   calls to GSS_Unwrap() (formerly GSS_Unseal()), and context deletion
-   tokens, emitted by calls to GSS_Delete_sec_context() and consumed by
-   calls to GSS_Process_context_token().  Note: References to GSS-API
-   per-message routines in the remainder of this specification will be
-   based on those routines' newer recommended names rather than those
-   names' predecessors.
-
-   Several variants of cryptographic keys are used in generation and
-   processing of per-message tokens:
-
-        (1) context key: uses Kerberos session key (or subkey, if
-        present in authenticator emitted by context initiator) directly
-
-        (2) confidentiality key: forms variant of context key by
-        exclusive-OR with the hexadecimal constant f0f0f0f0f0f0f0f0.
-
-        (3) MD2.5 seed key: forms variant of context key by reversing
-        the bytes of the context key (i.e. if the original key is the
-        8-byte sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the seed key
-        will be {hh, gg, ff, ee, dd, cc, bb, aa}).
-
-1.2.1. Per-message Tokens - MIC
-
-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 as received.  The token has the following format:
-
-   Byte no          Name           Description
-    0..1           TOK_ID          Identification field.
-                                   Tokens emitted by GSS_GetMIC() contain
-                                   the hex value 01 01 in this field.
-    2..3           SGN_ALG         Integrity algorithm indicator.
-                                   00 00 - DES MAC MD5
-                                   01 00 - MD2.5
-                                   02 00 - DES MAC
-    4..7           Filler          Contains ff ff ff ff
-    8..15          SND_SEQ         Sequence number field.
-    16..23         SGN_CKSUM       Checksum of "to-be-signed data",
-                                   calculated according to algorithm
-                                   specified in SGN_ALG field.
-
-
-
-
-
-Linn                        Standards Track                     [Page 7]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-   GSS-API tokens must be encapsulated within the higher-level protocol
-   by the application; no embedded length field is necessary.
-
-1.2.1.1. Checksum
-
-   Checksum calculation procedure (common to all algorithms): Checksums
-   are calculated over the data field, logically prepended by the first
-   8 bytes of the plaintext packet header.  The resulting value binds
-   the data to the packet type and signature algorithm identifier
-   fields.
-
-   DES MAC MD5 algorithm: The checksum is formed by computing an MD5
-   [RFC-1321] hash over the plaintext data, and then computing a DES-CBC
-   MAC on the 16-byte MD5 result.  A standard 64-bit DES-CBC MAC is
-   computed per [FIPS-PUB-113], employing the context key and a zero IV.
-   The 8-byte result is stored in the SGN_CKSUM field.
-
-   MD2.5 algorithm: The checksum is formed by first DES-CBC encrypting a
-   16-byte zero-block, using a zero IV and a key formed by reversing the
-   bytes of the context key (i.e. if the original key is the 8-byte
-   sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be
-   {hh, gg, ff, ee, dd, cc, bb, aa}).   The resulting 16-byte value is
-   logically prepended to the to-be-signed data.  A standard MD5
-   checksum is calculated over the combined data, and the first 8 bytes
-   of the result are stored in the SGN_CKSUM field.  Note 1: we refer to
-   this algorithm informally as "MD2.5" to connote the fact that it uses
-   half of the 128 bits generated by MD5; use of only a subset of the
-   MD5 bits is intended to protect against the prospect that data could
-   be postfixed to an existing message with corresponding modifications
-   being made to the checksum.  Note 2: This algorithm is fairly novel
-   and has received more limited evaluation than that to which other
-   integrity algorithms have been subjected.  An initial, limited
-   evaluation indicates that it may be significantly weaker than DES MAC
-   MD5.
-
-   DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the
-   plaintext data per [FIPS-PUB-113], employing the context key and a
-   zero IV. Padding procedures to accomodate plaintext data lengths
-   which may not be integral multiples of 8 bytes are defined in [FIPS-
-   PUB-113].  The result is an 8-byte value, which is stored in the
-   SGN_CKSUM field.  Support for this algorithm may not be present in
-   all implementations.
-
-1.2.1.2. Sequence Number
-
-   Sequence number field: The 8 byte plaintext sequence number field is
-   formed from the sender's four-byte sequence number as follows.  If
-   the four bytes of the sender's sequence number are named s0, s1, s2
-
-
-
-Linn                        Standards Track                     [Page 8]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-   and s3 (from least to most significant), the plaintext sequence
-   number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
-   di), where 'di' is the direction-indicator (Hex 0 - sender is the
-   context initiator, Hex FF - sender is the context acceptor).  The
-   field is then DES-CBC encrypted using the context key and an IV
-   formed from the first 8 bytes of the previously calculated SGN_CKSUM
-   field. After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's
-   sequence number is incremented by one.
-
-   The receiver of the token will first verify the SGN_CKSUM field.  If
-   valid, the sequence number field may be decrypted and compared to the
-   expected sequence number.  The repetition of the (effectively 1-bit)
-   direction indicator within the sequence number field provides
-   redundancy so that the receiver may verify that the decryption
-   succeeded.
-
-   Since the checksum computation is used as an IV to the sequence
-   number decryption, attempts to splice a checksum and sequence number
-   from different messages will be detected.  The direction indicator
-   will detect packets that have been maliciously reflected.
-
-   The sequence number provides a basis for detection of replayed
-   tokens.  Replay detection can be performed using state information
-   retained on received sequence numbers, interpreted in conjunction
-   with the security context on which they arrive.
-
-   Provision of per-message replay and out-of-sequence detection
-   services is optional for implementations of the Kerberos V5 GSS-API
-   mechanism.  Further, it is recommended that implementations of the
-   Kerberos V5 GSS-API mechanism which offer these services should honor
-   a caller's request that the services be disabled on a context.
-   Specifically, if replay_det_req_flag is input FALSE, replay_det_state
-   should be returned FALSE and the GSS_DUPLICATE_TOKEN and
-   GSS_OLD_TOKEN stati should not be indicated as a result of duplicate
-   detection when tokens are processed; if sequence_req_flag is input
-   FALSE, sequence_state should be returned FALSE and
-   GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN stati should
-   not be indicated as a result of out-of-sequence detection when tokens
-   are processed.
-
-1.2.2. Per-message Tokens - Wrap
-
-   Use of the GSS_Wrap() call yields a token which encapsulates the
-   input user data (optionally encrypted) along with associated
-   integrity check quantities. The token emitted by GSS_Wrap() consists
-   of an integrity header whose format is identical to that emitted by
-   GSS_GetMIC() (except that the TOK_ID field contains the value 02 01),
-   followed by a body portion that contains either the plaintext data
-
-
-
-Linn                        Standards Track                     [Page 9]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-   (if SEAL_ALG = ff ff) or encrypted data for any other supported value
-   of SEAL_ALG.  Currently, only SEAL_ALG = 00 00 is supported, and
-   means that DES-CBC encryption is being used to protect the data.
-
-   The GSS_Wrap() token has the following format:
-
-   Byte no          Name           Description
-    0..1           TOK_ID          Identification field.
-                                   Tokens emitted by GSS_Wrap() contain
-                                   the hex value 02 01 in this field.
-    2..3           SGN_ALG         Checksum algorithm indicator.
-                                   00 00 - DES MAC MD5
-                                   01 00 - MD2.5
-                                   02 00 - DES MAC
-    4..5           SEAL_ALG        ff ff - none
-                                   00 00 - DES
-    6..7           Filler          Contains ff ff
-    8..15          SND_SEQ         Encrypted sequence number field.
-    16..23         SGN_CKSUM       Checksum of plaintext padded data,
-                                   calculated according to algorithm
-                                   specified in SGN_ALG field.
-    24..last       Data            encrypted or plaintext padded data
-
-   GSS-API tokens must be encapsulated within the higher-level protocol
-   by the application; no embedded length field is necessary.
-
-1.2.2.1. Checksum
-
-   Checksum calculation procedure (common to all algorithms): Checksums
-   are calculated over the plaintext padded data field, logically
-   prepended by the first 8 bytes of the plaintext packet header.  The
-   resulting signature binds the data to the packet type, protocol
-   version, and signature algorithm identifier fields.
-
-   DES MAC MD5 algorithm: The checksum is formed by computing an MD5
-   hash over the plaintext padded data, and then computing a DES-CBC MAC
-   on the 16-byte MD5 result.  A standard 64-bit DES-CBC MAC is computed
-   per [FIPS-PUB-113], employing the context key and a zero IV. The 8-
-   byte result is stored in the SGN_CKSUM field.
-
-   MD2.5 algorithm: The checksum is formed by first DES-CBC encrypting a
-   16-byte zero-block, using a zero IV and a key formed by reversing the
-   bytes of the context key (i.e., if the original key is the 8-byte
-   sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be
-   {hh, gg, ff, ee, dd, cc, bb, aa}). The resulting 16-byte value is
-   logically pre-pended to the "to-be-signed data".  A standard MD5
-   checksum is calculated over the combined data, and the first 8 bytes
-   of the result are stored in the SGN_CKSUM field.
-
-
-
-Linn                        Standards Track                    [Page 10]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-   DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the
-   plaintext padded data per [FIPS-PUB-113], employing the context key
-   and a zero IV. The plaintext padded data is already assured to be an
-   integral multiple of 8 bytes; no additional padding is required or
-   applied in order to accomplish MAC calculation.  The result is an 8-
-   byte value, which is stored in the SGN_CKSUM field.  Support for this
-   lgorithm may not be present in all implementations.
-
-1.2.2.2. Sequence Number
-
-   Sequence number field: The 8 byte plaintext sequence number field is
-   formed from the sender's four-byte sequence number as follows.  If
-   the four bytes of the sender's sequence number are named s0, s1, s2
-   and s3 (from least to most significant), the plaintext sequence
-   number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
-   di), where 'di' is the direction-indicator (Hex 0 - sender is the
-   context initiator, Hex FF - sender is the context acceptor).
-
-   The field is then DES-CBC encrypted using the context key and an IV
-   formed from the first 8 bytes of the SEAL_CKSUM field.
-
-   After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's
-   sequence numbers are incremented by one.
-
-1.2.2.3. Padding
-
-   Data padding: Before encryption and/or signature calculation,
-   plaintext data is padded to the next highest multiple of 8 bytes, by
-   appending between 1 and 8 bytes, the value of each such byte being
-   the total number of pad bytes.  For example, given data of length 20
-   bytes, four pad bytes will be appended, and each byte will contain
-   the hex value 04.  An 8-byte random confounder is prepended to the
-   data, and signatures are calculated over the resulting padded
-   plaintext.
-
-   After padding, the data is encrypted according to the algorithm
-   specified in the SEAL_ALG field.  For SEAL_ALG=DES (the only non-null
-   algorithm currently supported), the data is encrypted using DES-CBC,
-   with an IV of zero.  The key used is derived from the established
-   context key by XOR-ing the context key with the hexadecimal constant
-   f0f0f0f0f0f0f0f0.
-
-1.2.3. Context deletion token
-
-   The token emitted by GSS_Delete_sec_context() is based on the packet
-   format for tokens emitted by GSS_GetMIC().  The context-deletion
-   token has the following format:
-
-
-
-
-Linn                        Standards Track                    [Page 11]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-   Byte no          Name           Description
-    0..1           TOK_ID          Identification field.
-                                   Tokens emitted by
-                                   GSS_Delete_sec_context() contain
-                                   the hex value 01 02 in this field.
-    2..3           SGN_ALG         Integrity algorithm indicator.
-                                   00 00 - DES MAC MD5
-                                   01 00 - MD2.5
-                                   02 00 - DES MAC
-    4..7           Filler          Contains ff ff ff ff
-    8..15          SND_SEQ         Sequence number field.
-    16..23         SGN_CKSUM       Checksum of "to-be-signed data",
-                                   calculated according to algorithm
-                                   specified in SGN_ALG field.
-
-   SGN_ALG and SND_SEQ will be calculated as for tokens emitted by
-   GSS_GetMIC().  The SGN_CKSUM will be calculated as for tokens emitted
-   by GSS_GetMIC(), except that the user-data component of the "to-be-
-   signed" data will be a zero-length string.
-
-2. Name Types and Object Identifiers
-
-   This section discusses the name types which may be passed as input to
-   the Kerberos V5 GSS-API mechanism's GSS_Import_name() call, and their
-   associated identifier values.  It defines interface elements in
-   support of portability, and assumes use of C language bindings per
-   RFC-1509.  In addition to specifying OID values for name type
-   identifiers, symbolic names are included and recommended to GSS-API
-   implementors in the interests of convenience to callers.  It is
-   understood that not all implementations of the Kerberos V5 GSS-API
-   mechanism need support all name types in this list, and that
-   additional name forms will likely be added to this list over time.
-   Further, the definitions of some or all name types may later migrate
-   to other, mechanism-independent, specifications. The occurrence of a
-   name type in this specification is specifically not intended to
-   suggest that the type may be supported only by an implementation of
-   the Kerberos V5 mechanism.   In particular, the occurrence of the
-   string "_KRB5_" in the symbolic name strings constitutes a means to
-   unambiguously register the name strings, avoiding collision with
-   other documents; it is not meant to limit the name types' usage or
-   applicability.
-
-   For purposes of clarification to GSS-API implementors, this section's
-   discussion of some name forms describes means through which those
-   forms can be supported with existing Kerberos technology.  These
-   discussions are not intended to preclude alternative implementation
-   strategies for support of the name forms within Kerberos mechanisms
-   or mechanisms based on other technologies.  To enhance application
-
-
-
-Linn                        Standards Track                    [Page 12]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-   portability, implementors of mechanisms are encouraged to support
-   name forms as defined in this section, even if their mechanisms are
-   independent of Kerberos V5.
-
-2.1. Mandatory Name Forms
-
-   This section discusses name forms which are to be supported by all
-   conformant implementations of the Kerberos V5 GSS-API mechanism.
-
-2.1.1. Kerberos Principal Name Form
-
-   This name form shall be represented by the Object Identifier {iso(1)
-   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
-   krb5(2) krb5_name(1)}.  The recommended symbolic name for this type
-   is "GSS_KRB5_NT_PRINCIPAL_NAME".
-
-   This name type corresponds to the single-string representation of a
-   Kerberos name.  (Within the MIT Kerberos V5 implementation, such
-   names are parseable with the krb5_parse_name() function.)  The
-   elements included within this name representation are as follows,
-   proceeding from the beginning of the string:
-
-        (1) One or more principal name components; if more than one
-        principal name component is included, the components are
-        separated by `/`.  Arbitrary octets may be included within
-        principal name components, with the following constraints and
-        special considerations:
-
-           (1a) Any occurrence of the characters `@` or `/` within a
-           name component must be immediately preceded by the `\`
-           quoting character, to prevent interpretation as a component
-           or realm separator.
-
-           (1b) The ASCII newline, tab, backspace, and null characters
-           may occur directly within the component or may be
-           represented, respectively, by `\n`, `\t`, `\b`, or `\0`.
-
-           (1c) If the `\` quoting character occurs outside the contexts
-           described in (1a) and (1b) above, the following character is
-           interpreted literally.  As a special case, this allows the
-           doubled representation `\\` to represent a single occurrence
-           of the quoting character.
-
-           (1d) An occurrence of the `\` quoting character as the last
-           character of a component is illegal.
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 13]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-        (2) Optionally, a `@` character, signifying that a realm name
-        immediately follows. If no realm name element is included, the
-        local realm name is assumed.  The `/` , `:`, and null characters
-        may not occur within a realm name; the `@`, newline, tab, and
-        backspace characters may be included using the quoting
-        conventions described in (1a), (1b), and (1c) above.
-
-2.1.2. Host-Based Service Name Form
-
-   This name form has been incorporated at the mechanism-independent
-   GSS-API level as of GSS-API, Version 2.  This subsection retains the
-   Object Identifier and symbolic name assignments previously made at
-   the Kerberos V5 GSS-API mechanism level, and adopts the definition as
-   promoted to the mechanism-independent level.
-
-   This name form shall be represented by the Object Identifier {iso(1)
-   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
-   generic(1) service_name(4)}.  The previously recommended symbolic
-   name for this type is "GSS_KRB5_NT_HOSTBASED_SERVICE_NAME".  The
-   currently preferred symbolic name for this type is
-   "GSS_C_NT_HOSTBASED_SERVICE".
-
-   This name type is used to represent services associated with host
-   computers.  This name form is constructed using two elements,
-   "service" and "hostname", as follows:
-
-      service@hostname
-
-   When a reference to a name of this type is resolved, the "hostname"
-   is canonicalized by attempting a DNS lookup and using the fully-
-   qualified domain name which is returned, or by using the "hostname"
-   as provided if the DNS lookup fails.  The canonicalization operation
-   also maps the host's name into lower-case characters.
-
-   The "hostname" element may be omitted. If no "@" separator is
-   included, the entire name is interpreted as the service specifier,
-   with the "hostname" defaulted to the canonicalized name of the local
-   host.
-
-   Values for the "service" element will be registered with the IANA.
-
-2.1.3. Exported Name Object Form for Kerberos V5 Mechanism
-
-   Support for this name form is not required for GSS-V1
-   implementations, but will be required for use in conjunction with the
-   GSS_Export_name() call planned for GSS-API Version 2.  Use of this
-   name form will be signified by a "GSS-API Exported Name Object" OID
-   value which will be defined at the mechanism-independent level for
-
-
-
-Linn                        Standards Track                    [Page 14]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-   GSS-API Version 2.
-
-   This name type represents a self-describing object, whose framing
-   structure will be defined at the mechanism-independent level for
-   GSS-API Version 2.  When generated by the Kerberos V5 mechanism, the
-   Mechanism OID within the exportable name shall be that of the
-   Kerberos V5 mechanism.  The name component within the exportable name
-   shall be a contiguous string with structure as defined for the
-   Kerberos Principal Name Form.
-
-   In order to achieve a distinguished encoding for comparison purposes,
-   the following additional constraints are imposed on the export
-   operation:
-
-        (1) all occurrences of the characters `@`,  `/`, and `\` within
-        principal components or realm names shall be quoted with an
-        immediately-preceding `\`.
-
-        (2) all occurrences of the null, backspace, tab, or newline
-        characters within principal components or realm names will be
-        represented, respectively, with `\0`, `\b`, `\t`, or `\n`.
-
-        (3) the `\` quoting character shall not be emitted within an
-        exported name except to accomodate cases (1) and (2).
-
-2.2. Optional Name Forms
-
-   This section discusses additional name forms which may optionally be
-   supported by implementations of the Kerberos V5 GSS-API mechanism.
-   It is recognized that some of the name forms cited here are derived
-   from UNIX(tm) operating system platforms; some listed forms may be
-   irrelevant to non-UNIX platforms, and definition of additional forms
-   corresponding to such platforms may also be appropriate.  It is also
-   recognized that OS-specific functions outside GSS-API are likely to
-   exist in order to perform translations among these forms, and that
-   GSS-API implementations supporting these forms may themselves be
-   layered atop such OS-specific functions.  Inclusion of this support
-   within GSS-API implementations is intended as a convenience to
-   applications.
-
-2.2.1. User Name Form
-
-   This name form shall be represented by the Object Identifier {iso(1)
-   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
-   generic(1) user_name(1)}.  The recommended symbolic name for this
-   type is "GSS_KRB5_NT_USER_NAME".
-
-   This name type is used to indicate a named user on a local system.
-
-
-
-Linn                        Standards Track                    [Page 15]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-   Its interpretation is OS-specific.  This name form is constructed as:
-
-      username
-
-   Assuming that users' principal names are the same as their local
-   operating system names, an implementation of GSS_Import_name() based
-   on Kerberos V5 technology can process names of this form by
-   postfixing an "@" sign and the name of the local realm.
-
-2.2.2. Machine UID Form
-
-   This name form shall be represented by the Object Identifier {iso(1)
-   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
-   generic(1) machine_uid_name(2)}.  The recommended symbolic name for
-   this type is "GSS_KRB5_NT_MACHINE_UID_NAME".
-
-   This name type is used to indicate a numeric user identifier
-   corresponding to a user on a local system.  Its interpretation is
-   OS-specific.  The gss_buffer_desc representing a name of this type
-   should contain a locally-significant uid_t, represented in host byte
-   order.  The GSS_Import_name() operation resolves this uid into a
-   username, which is then treated as the User Name Form.
-
-2.2.3. String UID Form
-
-   This name form shall be represented by the Object Identifier {iso(1)
-   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
-   generic(1) string_uid_name(3)}.  The recommended symbolic name for
-   this type is "GSS_KRB5_NT_STRING_UID_NAME".
-
-   This name type is used to indicate a string of digits representing
-   the numeric user identifier of a user on a local system.  Its
-   interpretation is OS-specific. This name type is similar to the
-   Machine UID Form, except that the buffer contains a string
-   representing the uid_t.
-
-3. Credentials Management
-
-   The Kerberos V5 protocol uses different credentials (in the GSSAPI
-   sense) for initiating and accepting security contexts.  Normal
-   clients receive a ticket-granting ticket (TGT) and an associated
-   session key at "login" time; the pair of a TGT and its corresponding
-   session key forms a credential which is suitable for initiating
-   security contexts.  A ticket-granting ticket, its session key, and
-   any other (ticket, key) pairs obtained through use of the ticket-
-   granting-ticket, are typically stored in a Kerberos V5 credentials
-   cache, sometimes known as a ticket file.
-
-
-
-
-Linn                        Standards Track                    [Page 16]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-   The encryption key used by the Kerberos server to seal tickets for a
-   particular application service forms the credentials suitable for
-   accepting security contexts.  These service keys are typically stored
-   in a Kerberos V5 key table, or srvtab file.  In addition to their use
-   as accepting credentials, these service keys may also be used to
-   obtain initiating credentials for their service principal.
-
-   The Kerberos V5 mechanism's credential handle may contain references
-   to either or both types of credentials.  It is a local matter how the
-   Kerberos V5 mechanism implementation finds the appropriate Kerberos
-   V5 credentials cache or key table.
-
-   However, when the Kerberos V5 mechanism attempts to obtain initiating
-   credentials for a service principal which are not available in a
-   credentials cache, and the key for that service principal is
-   available in a Kerberos V5 key table, the mechanism should use the
-   service key to obtain initiating credentials for that service.  This
-   should be accomplished by requesting a ticket-granting-ticket from
-   the Kerberos Key Distribution Center (KDC), and decrypting the KDC's
-   reply using the service key.
-
-4. Parameter Definitions
-
-   This section defines parameter values used by the Kerberos V5 GSS-API
-   mechanism.  It defines interface elements in support of portability,
-   and assumes use of C language bindings per RFC-1509.
-
-4.1. Minor Status Codes
-
-   This section recommends common symbolic names for minor_status values
-   to be returned by the Kerberos V5 GSS-API mechanism.  Use of these
-   definitions will enable independent implementors to enhance
-   application portability across different implementations of the
-   mechanism defined in this specification.  (In all cases,
-   implementations of GSS_Display_status() will enable callers to
-   convert minor_status indicators to text representations.) Each
-   implementation should make available, through include files or other
-   means, a facility to translate these symbolic names into the concrete
-   values which a particular GSS-API implementation uses to represent
-   the minor_status values specified in this section.
-
-   It is recognized that this list may grow over time, and that the need
-   for additional minor_status codes specific to particular
-   implementations may arise.  It is recommended, however, that
-   implementations should return a minor_status value as defined on a
-   mechanism-wide basis within this section when that code is accurately
-   representative of reportable status rather than using a separate,
-   implementation-defined code.
-
-
-
-Linn                        Standards Track                    [Page 17]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-4.1.1. Non-Kerberos-specific codes
-
-   GSS_KRB5_S_G_BAD_SERVICE_NAME
-           /* "No @ in SERVICE-NAME name string" */
-   GSS_KRB5_S_G_BAD_STRING_UID
-           /* "STRING-UID-NAME contains nondigits" */
-   GSS_KRB5_S_G_NOUSER
-           /* "UID does not resolve to username" */
-   GSS_KRB5_S_G_VALIDATE_FAILED
-           /* "Validation error" */
-   GSS_KRB5_S_G_BUFFER_ALLOC
-           /* "Couldn't allocate gss_buffer_t data" */
-   GSS_KRB5_S_G_BAD_MSG_CTX
-           /* "Message context invalid" */
-   GSS_KRB5_S_G_WRONG_SIZE
-           /* "Buffer is the wrong size" */
-   GSS_KRB5_S_G_BAD_USAGE
-           /* "Credential usage type is unknown" */
-   GSS_KRB5_S_G_UNKNOWN_QOP
-           /* "Unknown quality of protection specified" */
-
-4.1.2. Kerberos-specific-codes
-
-   GSS_KRB5_S_KG_CCACHE_NOMATCH
-           /* "Principal in credential cache does not match desired name" */
-   GSS_KRB5_S_KG_KEYTAB_NOMATCH
-           /* "No principal in keytab matches desired name" */
-   GSS_KRB5_S_KG_TGT_MISSING
-           /* "Credential cache has no TGT" */
-   GSS_KRB5_S_KG_NO_SUBKEY
-           /* "Authenticator has no subkey" */
-   GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
-           /* "Context is already fully established" */
-   GSS_KRB5_S_KG_BAD_SIGN_TYPE
-           /* "Unknown signature type in token" */
-   GSS_KRB5_S_KG_BAD_LENGTH
-           /* "Invalid field length in token" */
-   GSS_KRB5_S_KG_CTX_INCOMPLETE
-           /* "Attempt to use incomplete security context" */
-
-4.2. Quality of Protection Values
-
-   This section defines Quality of Protection (QOP) values to be used
-   with the Kerberos V5 GSS-API mechanism as input to GSS_Wrap() and
-   GSS_GetMIC() routines in order to select among alternate integrity
-   and confidentiality algorithms. Additional QOP values may be added in
-   future versions of this specification.  Non-overlapping bit positions
-   are and will be employed in order that both integrity and
-
-
-
-Linn                        Standards Track                    [Page 18]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-   confidentiality QOP may be selected within a single parameter, via
-   inclusive-OR of the specified integrity and confidentiality values.
-
-4.2.1. Integrity Algorithms
-
-   The following Quality of Protection (QOP) values are currently
-   defined for the Kerberos V5 GSS-API mechanism, and are used to select
-   among alternate integrity checking algorithms.
-
-   GSS_KRB5_INTEG_C_QOP_MD5        (numeric value: 1)
-           /* Integrity using partial MD5 ("MD2.5") of plaintext */
-
-   GSS_KRB5_INTEG_C_QOP_DES_MD5    (numeric value: 2)
-           /* Integrity using DES MAC of MD5 of plaintext */
-
-   GSS_KRB5_INTEG_C_QOP_DES_MAC    (numeric value: 3)
-           /* Integrity using DES MAC of plaintext */
-
-4.2.2. Confidentiality Algorithms
-
-   Only one confidentiality QOP value is currently defined for the
-   Kerberos V5 GSS-API mechanism:
-
-   GSS_KRB5_CONF_C_QOP_DES         (numeric value: 0)
-           /* Confidentiality with DES */
-
-   Note: confidentiality QOP should be indicated only by GSS-API calls
-   capable of providing confidentiality services. If non-zero
-   confidentiality QOP values are defined in future to represent
-   different algorithms, therefore, the bit positions containing those
-   values should be cleared before being returned by implementations of
-   GSS_GetMIC() and GSS_VerifyMIC().
-
-4.3. Buffer Sizes
-
-   All implementations of this specification shall be capable of
-   accepting buffers of at least 16 Kbytes as input to GSS_GetMIC(),
-   GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting
-   the output_token generated by GSS_Wrap() for a 16 Kbyte input buffer
-   as input to GSS_Unwrap(). Support for larger buffer sizes is optional
-   but recommended.
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 19]
-
-RFC 1964               Kerberos Version 5 GSS-API              June 1996
-
-
-5. Security Considerations
-
-   Security issues are discussed throughout this memo.
-
-6. References
-
-
-   [RFC-1321]: Rivest, R., "The MD5 Message-Digest Algorithm", RFC
-   1321, April 1992.
-
-   [RFC-1508]: Linn, J., "Generic Security Service Application Program
-   Interface", RFC 1508, September 1993.
-
-   [RFC-1509]: Wray, J., "Generic Security Service Application Program
-   Interface: C-bindings", RFC 1509, September 1993.
-
-   [RFC-1510]: Kohl, J., and C. Neuman, "The Kerberos Network
-   Authentication Service (V5)", RFC 1510, September 1993.
-
-   [FIPS-PUB-113]: National Bureau of Standards, Federal Information
-   Processing Standard 113, "Computer Data Authentication", May 1985.
-
-AUTHOR'S ADDRESS
-
-   John Linn
-   OpenVision Technologies
-   One Main St.
-   Cambridge, MA  02142  USA
-
-   Phone: +1 617.374.2245
-   EMail: John.Linn@ov.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 20]
-
diff --git a/doc/standardisation/rfc2078.txt b/doc/standardisation/rfc2078.txt
deleted file mode 100644
index 1dd1e4aeb..000000000
--- a/doc/standardisation/rfc2078.txt
+++ /dev/null
@@ -1,4763 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           J. Linn
-Request for Comments: 2078                      OpenVision Technologies
-Category: Standards Track                                  January 1997
-Obsoletes: 1508
-
-
-   Generic Security Service Application Program Interface, Version 2
-
-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.
-
-Abstract
-
-   The Generic Security Service Application Program Interface (GSS-API),
-   as defined in RFC-1508, provides security services to callers in a
-   generic fashion, supportable with a range of underlying mechanisms
-   and technologies and hence allowing source-level portability of
-   applications to different environments. This specification defines
-   GSS-API services and primitives at a level independent of underlying
-   mechanism and programming language environment, and is to be
-   complemented by other, related specifications:
-
-      documents defining specific parameter bindings for particular
-      language environments
-
-      documents defining token formats, protocols, and procedures to be
-      implemented in order to realize GSS-API services atop particular
-      security mechanisms
-
-   This memo revises RFC-1508, making specific, incremental changes in
-   response to implementation experience and liaison requests. It is
-   intended, therefore, that this memo or a successor version thereto
-   will become the basis for subsequent progression of the GSS-API
-   specification on the standards track.
-
-Table of Contents
-
-   1: GSS-API Characteristics and Concepts..........................  3
-   1.1: GSS-API Constructs..........................................  6
-   1.1.1:  Credentials..............................................  6
-   1.1.1.1: Credential Constructs and Concepts......................  6
-   1.1.1.2: Credential Management...................................  7
-   1.1.1.3: Default Credential Resolution...........................  8
-
-
-
-Linn                        Standards Track                     [Page 1]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   1.1.2: Tokens....................................................  9
-   1.1.3:  Security Contexts........................................ 10
-   1.1.4:  Mechanism Types.......................................... 11
-   1.1.5:  Naming................................................... 12
-   1.1.6:  Channel Bindings......................................... 14
-   1.2:  GSS-API Features and Issues................................ 15
-   1.2.1:  Status Reporting......................................... 15
-   1.2.2: Per-Message Security Service Availability................. 17
-   1.2.3: Per-Message Replay Detection and Sequencing............... 18
-   1.2.4:  Quality of Protection.................................... 20
-   1.2.5: Anonymity Support......................................... 21
-   1.2.6: Initialization............................................ 22
-   1.2.7: Per-Message Protection During Context Establishment....... 22
-   1.2.8: Implementation Robustness................................. 23
-   2:  Interface Descriptions....................................... 23
-   2.1:  Credential management calls................................ 25
-   2.1.1:  GSS_Acquire_cred call.................................... 26
-   2.1.2:  GSS_Release_cred call.................................... 28
-   2.1.3:  GSS_Inquire_cred call.................................... 29
-   2.1.4:  GSS_Add_cred call........................................ 31
-   2.1.5:  GSS_Inquire_cred_by_mech call............................ 33
-   2.2:  Context-level calls........................................ 34
-   2.2.1:  GSS_Init_sec_context call................................ 34
-   2.2.2:  GSS_Accept_sec_context call.............................. 40
-   2.2.3:  GSS_Delete_sec_context call.............................. 44
-   2.2.4:  GSS_Process_context_token call........................... 46
-   2.2.5:  GSS_Context_time call.................................... 47
-   2.2.6:  GSS_Inquire_context call................................. 47
-   2.2.7:  GSS_Wrap_size_limit call................................. 49
-   2.2.8:  GSS_Export_sec_context call.............................. 50
-   2.2.9:  GSS_Import_sec_context call.............................. 52
-   2.3:  Per-message calls.......................................... 53
-   2.3.1:  GSS_GetMIC call.......................................... 54
-   2.3.2:  GSS_VerifyMIC call....................................... 55
-   2.3.3:  GSS_Wrap call............................................ 56
-   2.3.4:  GSS_Unwrap call.......................................... 58
-   2.4:  Support calls.............................................. 59
-   2.4.1:  GSS_Display_status call.................................. 60
-   2.4.2:  GSS_Indicate_mechs call.................................. 60
-   2.4.3:  GSS_Compare_name call.................................... 61
-   2.4.4:  GSS_Display_name call.................................... 62
-   2.4.5:  GSS_Import_name call..................................... 63
-   2.4.6:  GSS_Release_name call.................................... 64
-   2.4.7:  GSS_Release_buffer call.................................. 65
-   2.4.8:  GSS_Release_OID_set call................................. 65
-   2.4.9:  GSS_Create_empty_OID_set call............................ 66
-   2.4.10: GSS_Add_OID_set_member call.............................. 67
-   2.4.11: GSS_Test_OID_set_member call............................. 67
-
-
-
-Linn                        Standards Track                     [Page 2]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   2.4.12: GSS_Release_OID call..................................... 68
-   2.4.13: GSS_OID_to_str call...................................... 68
-   2.4.14: GSS_Str_to_OID call...................................... 69
-   2.4.15: GSS_Inquire_names_for_mech call.......................... 69
-   2.4.16: GSS_Inquire_mechs_for_name call.......................... 70
-   2.4.17: GSS_Canonicalize_name call............................... 71
-   2.4.18: GSS_Export_name call..................................... 72
-   2.4.19: GSS_Duplicate_name call.................................. 73
-   3: Data Structure Definitions for GSS-V2 Usage................... 73
-   3.1: Mechanism-Independent Token Format.......................... 74
-   3.2: Mechanism-Independent Exported Name Object Format........... 77
-   4: Name Type Definitions......................................... 77
-   4.1: Host-Based Service Name Form................................ 77
-   4.2: User Name Form.............................................. 78
-   4.3: Machine UID Form............................................ 78
-   4.4: String UID Form............................................. 79
-   5:  Mechanism-Specific Example Scenarios......................... 79
-   5.1: Kerberos V5, single-TGT..................................... 79
-   5.2: Kerberos V5, double-TGT..................................... 80
-   5.3:  X.509 Authentication Framework............................. 81
-   6:  Security Considerations...................................... 82
-   7:  Related Activities........................................... 82
-   Appendix A: Mechanism Design Constraints......................... 83
-   Appendix B: Compatibility with GSS-V1............................ 83
-
-1: GSS-API Characteristics and Concepts
-
-   GSS-API operates in the following paradigm.  A typical GSS-API caller
-   is itself a communications protocol, calling on GSS-API in order to
-   protect its communications with authentication, integrity, and/or
-   confidentiality security services.  A GSS-API caller accepts tokens
-   provided to it by its local GSS-API implementation and transfers the
-   tokens to a peer on a remote system; that peer passes the received
-   tokens to its local GSS-API implementation for processing. The
-   security services available through GSS-API in this fashion are
-   implementable (and have been implemented) over a range of underlying
-   mechanisms based on secret-key and public-key cryptographic
-   technologies.
-
-   The GSS-API separates the operations of initializing a security
-   context between peers, achieving peer entity authentication (This
-   security service definition, and other definitions used in this
-   document, corresponds to that provided in International Standard ISO
-   7498-2-1988(E), Security Architecture.) (GSS_Init_sec_context()  and
-   GSS_Accept_sec_context() calls), from the operations of providing
-   per-message data origin authentication and data integrity protection
-   (GSS_GetMIC()  and GSS_VerifyMIC()  calls) for messages subsequently
-   transferred in conjunction with that context.  When establishing a
-
-
-
-Linn                        Standards Track                     [Page 3]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   security context, the GSS-API enables a context initiator to
-   optionally permit its credentials to be delegated, meaning that the
-   context acceptor may initiate further security contexts on behalf of
-   the initiating caller. Per-message GSS_Wrap()  and GSS_Unwrap() calls
-   provide the data origin authentication and data integrity services
-   which GSS_GetMIC()  and GSS_VerifyMIC() offer, and also support
-   selection of confidentiality services as a caller option.  Additional
-   calls provide supportive functions to the GSS-API's users.
-
-   The following paragraphs provide an example illustrating the
-   dataflows involved in use of the GSS-API by a client and server in a
-   mechanism-independent fashion, establishing a security context and
-   transferring a protected message. The example assumes that credential
-   acquisition has already been completed.  The example assumes that the
-   underlying authentication technology is capable of authenticating a
-   client to a server using elements carried within a single token, and
-   of authenticating the server to the client (mutual authentication)
-   with a single returned token; this assumption holds for presently-
-   documented CAT mechanisms but is not necessarily true for other
-   cryptographic technologies and associated protocols.
-
-   The client calls GSS_Init_sec_context()  to establish a security
-   context to the server identified by targ_name, and elects to set the
-   mutual_req_flag so that mutual authentication is performed in the
-   course of context establishment. GSS_Init_sec_context()  returns an
-   output_token to be passed to the server, and indicates
-   GSS_S_CONTINUE_NEEDED status pending completion of the mutual
-   authentication sequence. Had mutual_req_flag not been set, the
-   initial call to GSS_Init_sec_context()  would have returned
-   GSS_S_COMPLETE status. The client sends the output_token to the
-   server.
-
-   The server passes the received token as the input_token parameter to
-   GSS_Accept_sec_context().  GSS_Accept_sec_context indicates
-   GSS_S_COMPLETE status, provides the client's authenticated identity
-   in the src_name result, and provides an output_token to be passed to
-   the client. The server sends the output_token to the client.
-
-   The client passes the received token as the input_token parameter to
-   a successor call to GSS_Init_sec_context(),  which processes data
-   included in the token in order to achieve mutual authentication from
-   the client's viewpoint. This call to GSS_Init_sec_context()  returns
-   GSS_S_COMPLETE status, indicating successful mutual authentication
-   and the completion of context establishment for this example.
-
-   The client generates a data message and passes it to GSS_Wrap().
-   GSS_Wrap() performs data origin authentication, data integrity, and
-   (optionally) confidentiality processing on the message and
-
-
-
-Linn                        Standards Track                     [Page 4]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   encapsulates the result into output_message, indicating
-   GSS_S_COMPLETE status. The client sends the output_message to the
-   server.
-
-   The server passes the received message to GSS_Unwrap().  GSS_Unwrap()
-   inverts the encapsulation performed by GSS_Wrap(),  deciphers the
-   message if the optional confidentiality feature was applied, and
-   validates the data origin authentication and data integrity checking
-   quantities. GSS_Unwrap()  indicates successful validation by
-   returning GSS_S_COMPLETE status along with the resultant
-   output_message.
-
-   For purposes of this example, we assume that the server knows by
-   out-of-band means that this context will have no further use after
-   one protected message is transferred from client to server. Given
-   this premise, the server now calls GSS_Delete_sec_context() to flush
-   context-level information.  Optionally, the server-side application
-   may provide a token buffer to GSS_Delete_sec_context(), to receive a
-   context_token to be transferred to the client in order to request
-   that client-side context-level information be deleted.
-
-   If a context_token is transferred, the client passes the
-   context_token to GSS_Process_context_token(), which returns
-   GSS_S_COMPLETE status after deleting context-level information at the
-   client system.
-
-   The GSS-API design assumes and addresses several basic goals,
-   including:
-
-      Mechanism independence: The GSS-API defines an interface to
-      cryptographically implemented strong authentication and other
-      security services at a generic level which is independent of
-      particular underlying mechanisms. For example, GSS-API-provided
-      services can be implemented by secret-key technologies (e.g.,
-      Kerberos) or public-key approaches (e.g., X.509).
-
-      Protocol environment independence: The GSS-API is independent of
-      the communications protocol suites with which it is employed,
-      permitting use in a broad range of protocol environments. In
-      appropriate environments, an intermediate implementation "veneer"
-      which is oriented to a particular communication protocol (e.g.,
-      Remote Procedure Call (RPC)) may be interposed between
-      applications which call that protocol and the GSS-API, thereby
-      invoking GSS-API facilities in conjunction with that protocol's
-      communications invocations.
-
-      Protocol association independence: The GSS-API's security context
-      construct is independent of communications protocol association
-
-
-
-Linn                        Standards Track                     [Page 5]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-      constructs. This characteristic allows a single GSS-API
-      implementation to be utilized by a variety of invoking protocol
-      modules on behalf of those modules' calling applications. GSS-API
-      services can also be invoked directly by applications, wholly
-      independent of protocol associations.
-
-      Suitability to a range of implementation placements: GSS-API
-      clients are not constrained to reside within any Trusted Computing
-      Base (TCB) perimeter defined on a system where the GSS-API is
-      implemented; security services are specified in a manner suitable
-      to both intra-TCB and extra-TCB callers.
-
-1.1: GSS-API Constructs
-
-   This section describes the basic elements comprising the GSS-API.
-
-1.1.1:  Credentials
-
-1.1.1.1: Credential Constructs and Concepts
-
-   Credentials provide the prerequisites which permit GSS-API peers to
-   establish security contexts with each other. A caller may designate
-   that the credential elements which are to be applied for context
-   initiation or acceptance be selected by default.  Alternately, those
-   GSS-API callers which need to make explicit selection of particular
-   credentials structures may make references to those credentials
-   through GSS-API-provided credential handles ("cred_handles").  In all
-   cases, callers' credential references are indirect, mediated by GSS-
-   API implementations and not requiring callers to access the selected
-   credential elements.
-
-   A single credential structure may be used to initiate outbound
-   contexts and to accept inbound contexts. Callers needing to operate
-   in only one of these modes may designate this fact when credentials
-   are acquired for use, allowing underlying mechanisms to optimize
-   their processing and storage requirements. The credential elements
-   defined by a particular mechanism may contain multiple cryptographic
-   keys, e.g., to enable authentication and message encryption to be
-   performed with different algorithms.
-
-   A GSS-API credential structure may contain multiple credential
-   elements, each containing mechanism-specific information for a
-   particular underlying mechanism (mech_type), but the set of elements
-   within a given credential structure represent a common entity.  A
-   credential structure's contents will vary depending on the set of
-   mech_types supported by a particular GSS-API implementation. Each
-   credential element identifies the data needed by its mechanism in
-   order to establish contexts on behalf of a particular principal, and
-
-
-
-Linn                        Standards Track                     [Page 6]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   may contain separate credential references for use in context
-   initiation and context acceptance.  Multiple credential elements
-   within a given credential having overlapping combinations of
-   mechanism, usage mode, and validity period are not permitted.
-
-   Commonly, a single mech_type will be used for all security contexts
-   established by a particular initiator to a particular target. A major
-   motivation for supporting credential sets representing multiple
-   mech_types is to allow initiators on systems which are equipped to
-   handle multiple types to initiate contexts to targets on other
-   systems which can accommodate only a subset of the set supported at
-   the initiator's system.
-
-1.1.1.2: Credential Management
-
-   It is the responsibility of underlying system-specific mechanisms and
-   OS functions below the GSS-API to ensure that the ability to acquire
-   and use credentials associated with a given identity is constrained
-   to appropriate processes within a system. This responsibility should
-   be taken seriously by implementors, as the ability for an entity to
-   utilize a principal's credentials is equivalent to the entity's
-   ability to successfully assert that principal's identity.
-
-   Once a set of GSS-API credentials is established, the transferability
-   of that credentials set to other processes or analogous constructs
-   within a system is a local matter, not defined by the GSS-API. An
-   example local policy would be one in which any credentials received
-   as a result of login to a given user account, or of delegation of
-   rights to that account, are accessible by, or transferable to,
-   processes running under that account.
-
-   The credential establishment process (particularly when performed on
-   behalf of users rather than server processes) is likely to require
-   access to passwords or other quantities which should be protected
-   locally and exposed for the shortest time possible. As a result, it
-   will often be appropriate for preliminary credential establishment to
-   be performed through local means at user login time, with the
-   result(s) cached for subsequent reference. These preliminary
-   credentials would be set aside (in a system-specific fashion) for
-   subsequent use, either:
-
-      to be accessed by an invocation of the GSS-API GSS_Acquire_cred()
-      call, returning an explicit handle to reference that credential
-
-      to comprise default credential elements to be installed, and to be
-      used when default credential behavior is requested on behalf of a
-      process
-
-
-
-
-Linn                        Standards Track                     [Page 7]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-1.1.1.3: Default Credential Resolution
-
-   The gss_init_sec_context and gss_accept_sec_context routines allow
-   the value GSS_C_NO_CREDENTIAL to be specified as their credential
-   handle parameter.  This special credential-handle indicates a desire
-   by the application to act as a default principal.  While individual
-   GSS-API implementations are free to determine such default behavior
-   as appropriate to the mechanism, the following default behavior by
-   these routines is recommended for portability:
-
-   GSS_Init_sec_context:
-
-      (i) If there is only a single principal capable of initiating
-      security contexts that the application is authorized to act on
-      behalf of, then that principal shall be used, otherwise
-
-      (ii) If the platform maintains a concept of a default network-
-      identity, and if the application is authorized to act on behalf of
-      that identity for the purpose of initiating security contexts,
-      then the principal corresponding to that identity shall be used,
-      otherwise
-
-      (iii) If the platform maintains a concept of a default local
-      identity, and provides a means to map local identities into
-      network-identities, and if the application is authorized to act on
-      behalf of the network-identity image of the default local identity
-      for the purpose of initiating security contexts, then the
-      principal corresponding to that identity shall be used, otherwise
-
-      (iv) A user-configurable default identity should be used.
-
-   GSS_Accept_sec_context:
-
-      (i) If there is only a single authorized principal identity
-      capable of accepting security contexts, then that principal shall
-      be used, otherwise
-
-      (ii) If the mechanism can determine the identity of the target
-      principal by examining the context-establishment token, and if the
-      accepting application is authorized to act as that principal for
-      the purpose of accepting security contexts, then that principal
-      identity shall be used, otherwise
-
-      (iii) If the mechanism supports context acceptance by any
-      principal, and mutual authentication was not requested, any
-      principal that the application is authorized to accept security
-      contexts under may be used, otherwise
-
-
-
-
-Linn                        Standards Track                     [Page 8]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-      (iv) A user-configurable default identity shall be used.
-
-   The purpose of the above rules is to allow security contexts to be
-   established by both initiator and acceptor using the default behavior
-   wherever possible.  Applications requesting default behavior are
-   likely to be more portable across mechanisms and platforms than ones
-   that use GSS_Acquire_cred to request a specific identity.
-
-1.1.2: Tokens
-
-   Tokens are data elements transferred between GSS-API callers, and are
-   divided into two classes. Context-level tokens are exchanged in order
-   to establish and manage a security context between peers. Per-message
-   tokens relate to an established context and are exchanged to provide
-   protective security services (i.e., data origin authentication,
-   integrity, and optional confidentiality) for corresponding data
-   messages.
-
-   The first context-level token obtained from GSS_Init_sec_context() is
-   required to indicate at its very beginning a globally-interpretable
-   mechanism identifier, i.e., an Object Identifier (OID) of the
-   security mechanism. The remaining part of this token as well as the
-   whole content of all other tokens are specific to the particular
-   underlying mechanism used to support the GSS-API. Section 3 of this
-   document provides, for designers of GSS-API support mechanisms, the
-   description of the header of the first context-level token which is
-   then followed by mechanism-specific information.
-
-   Tokens' contents are opaque from the viewpoint of GSS-API callers.
-   They are generated within the GSS-API implementation at an end
-   system, provided to a GSS-API caller to be transferred to the peer
-   GSS-API caller at a remote end system, and processed by the GSS-API
-   implementation at that remote end system. Tokens may be output by
-   GSS-API calls (and should be transferred to GSS-API peers) whether or
-   not the calls' status indicators indicate successful completion.
-   Token transfer may take place in an in-band manner, integrated into
-   the same protocol stream used by the GSS-API callers for other data
-   transfers, or in an out-of-band manner across a logically separate
-   channel.
-
-   Different GSS-API tokens are used for different purposes (e.g.,
-   context initiation, context acceptance, protected message data on an
-   established context), and it is the responsibility of a GSS-API
-   caller receiving tokens to distinguish their types, associate them
-   with corresponding security contexts, and pass them to appropriate
-   GSS-API processing routines.  Depending on the caller protocol
-   environment, this distinction may be accomplished in several ways.
-
-
-
-
-Linn                        Standards Track                     [Page 9]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   The following examples illustrate means through which tokens' types
-   may be distinguished:
-
-      - implicit tagging based on state information (e.g., all tokens on
-      a new association are considered to be context establishment
-      tokens until context establishment is completed, at which point
-      all tokens are considered to be wrapped data objects for that
-      context),
-
-      - explicit tagging at the caller protocol level,
-
-      - a hybrid of these approaches.
-
-   Commonly, the encapsulated data within a token includes internal
-   mechanism-specific tagging information, enabling mechanism-level
-   processing modules to distinguish tokens used within the mechanism
-   for different purposes.  Such internal mechanism-level tagging is
-   recommended to mechanism designers, and enables mechanisms to
-   determine whether a caller has passed a particular token for
-   processing by an inappropriate GSS-API routine.
-
-   Development of GSS-API support primitives based on a particular
-   underlying cryptographic technique and protocol (i.e., conformant to
-   a specific GSS-API mechanism definition) does not necessarily imply
-   that GSS-API callers using that GSS-API mechanism will be able to
-   interoperate with peers invoking the same technique and protocol
-   outside the GSS-API paradigm, or with peers implementing a different
-   GSS-API mechanism based on the same underlying technology.  The
-   format of GSS-API tokens defined in conjunction with a particular
-   mechanism, and the techniques used to integrate those tokens into
-   callers' protocols, may not be interoperable with the tokens used by
-   non-GSS-API callers of the same underlying technique.
-
-1.1.3:  Security Contexts
-
-   Security contexts are established between peers, using credentials
-   established locally in conjunction with each peer or received by
-   peers via delegation. Multiple contexts may exist simultaneously
-   between a pair of peers, using the same or different sets of
-   credentials. Coexistence of multiple contexts using different
-   credentials allows graceful rollover when credentials expire.
-   Distinction among multiple contexts based on the same credentials
-   serves applications by distinguishing different message streams in a
-   security sense.
-
-   The GSS-API is independent of underlying protocols and addressing
-   structure, and depends on its callers to transport GSS-API-provided
-   data elements. As a result of these factors, it is a caller
-
-
-
-Linn                        Standards Track                    [Page 10]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   responsibility to parse communicated messages, separating GSS-API-
-   related data elements from caller-provided data.  The GSS-API is
-   independent of connection vs. connectionless orientation of the
-   underlying communications service.
-
-   No correlation between security context and communications protocol
-   association is dictated. (The optional channel binding facility,
-   discussed in Section 1.1.6 of this document, represents an
-   intentional exception to this rule, supporting additional protection
-   features within GSS-API supporting mechanisms.) This separation
-   allows the GSS-API to be used in a wide range of communications
-   environments, and also simplifies the calling sequences of the
-   individual calls. In many cases (depending on underlying security
-   protocol, associated mechanism, and availability of cached
-   information), the state information required for context setup can be
-   sent concurrently with initial signed user data, without interposing
-   additional message exchanges.
-
-1.1.4:  Mechanism Types
-
-   In order to successfully establish a security context with a target
-   peer, it is necessary to identify an appropriate underlying mechanism
-   type (mech_type) which both initiator and target peers support. The
-   definition of a mechanism embodies not only the use of a particular
-   cryptographic technology (or a hybrid or choice among alternative
-   cryptographic technologies), but also definition of the syntax and
-   semantics of data element exchanges which that mechanism will employ
-   in order to support security services.
-
-   It is recommended that callers initiating contexts specify the
-   "default" mech_type value, allowing system-specific functions within
-   or invoked by the GSS-API implementation to select the appropriate
-   mech_type, but callers may direct that a particular mech_type be
-   employed when necessary.
-
-   The means for identifying a shared mech_type to establish a security
-   context with a peer will vary in different environments and
-   circumstances; examples include (but are not limited to):
-
-      use of a fixed mech_type, defined by configuration, within an
-      environment
-
-      syntactic convention on a target-specific basis, through
-      examination of a target's name
-
-      lookup of a target's name in a naming service or other database in
-      order to identify mech_types supported by that target
-
-
-
-
-Linn                        Standards Track                    [Page 11]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-      explicit negotiation between GSS-API callers in advance of
-      security context setup
-
-   When transferred between GSS-API peers, mech_type specifiers (per
-   Section 3, represented as Object Identifiers (OIDs)) serve to qualify
-   the interpretation of associated tokens. (The structure and encoding
-   of Object Identifiers is defined in ISO/IEC 8824, "Specification of
-   Abstract Syntax Notation One (ASN.1)" and in ISO/IEC 8825,
-   "Specification of Basic Encoding Rules for Abstract Syntax Notation
-   One (ASN.1)".) Use of hierarchically structured OIDs serves to
-   preclude ambiguous interpretation of mech_type specifiers. The OID
-   representing the DASS MechType, for example, is 1.3.12.2.1011.7.5,
-   and that of the Kerberos V5 mechanism, once advanced to the level of
-   Proposed Standard, will be 1.2.840.113554.1.2.2.
-
-1.1.5:  Naming
-
-   The GSS-API avoids prescribing naming structures, treating the names
-   which are transferred across the interface in order to initiate and
-   accept security contexts as opaque objects.  This approach supports
-   the GSS-API's goal of implementability atop a range of underlying
-   security mechanisms, recognizing the fact that different mechanisms
-   process and authenticate names which are presented in different
-   forms. Generalized services offering translation functions among
-   arbitrary sets of naming environments are outside the scope of the
-   GSS-API; availability and use of local conversion functions to
-   translate among the naming formats supported within a given end
-   system is anticipated.
-
-   Different classes of name representations are used in conjunction
-   with different GSS-API parameters:
-
-      - Internal form (denoted in this document by INTERNAL NAME),
-      opaque to callers and defined by individual GSS-API
-      implementations.  GSS-API implementations supporting multiple
-      namespace types must maintain internal tags to disambiguate the
-      interpretation of particular names.  A Mechanism Name (MN) is a
-      special case of INTERNAL NAME, guaranteed to contain elements
-      corresponding to one and only one mechanism; calls which are
-      guaranteed to emit MNs or which require MNs as input are so
-      identified within this specification.
-
-      - Contiguous string ("flat") form (denoted in this document by
-      OCTET STRING); accompanied by OID tags identifying the namespace
-      to which they correspond.  Depending on tag value, flat names may
-      or may not be printable strings for direct acceptance from and
-      presentation to users. Tagging of flat names allows GSS-API
-      callers and underlying GSS-API mechanisms to disambiguate name
-
-
-
-Linn                        Standards Track                    [Page 12]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-      types and to determine whether an associated name's type is one
-      which they are capable of processing, avoiding aliasing problems
-      which could result from misinterpreting a name of one type as a
-      name of another type.
-
-      - The GSS-API Exported Name Object, a special case of flat name
-      designated by a reserved OID value, carries a canonicalized form
-      of a name suitable for binary comparisons.
-
-   In addition to providing means for names to be tagged with types,
-   this specification defines primitives to support a level of naming
-   environment independence for certain calling applications. To provide
-   basic services oriented towards the requirements of callers which
-   need not themselves interpret the internal syntax and semantics of
-   names, GSS-API calls for name comparison (GSS_Compare_name()),
-   human-readable display (GSS_Display_name()), input conversion
-   (GSS_Import_name()), internal name deallocation (GSS_Release_name()),
-   and internal name duplication (GSS_Duplicate_name()) functions are
-   defined. (It is anticipated that these proposed GSS-API calls will be
-   implemented in many end systems based on system-specific name
-   manipulation primitives already extant within those end systems;
-   inclusion within the GSS-API is intended to offer GSS-API callers a
-   portable means to perform specific operations, supportive of
-   authorization and audit requirements, on authenticated names.)
-
-   GSS_Import_name() implementations can, where appropriate, support
-   more than one printable syntax corresponding to a given namespace
-   (e.g., alternative printable representations for X.500 Distinguished
-   Names), allowing flexibility for their callers to select among
-   alternative representations. GSS_Display_name() implementations
-   output a printable syntax selected as appropriate to their
-   operational environments; this selection is a local matter. Callers
-   desiring portability across alternative printable syntaxes should
-   refrain from implementing comparisons based on printable name forms
-   and should instead use the GSS_Compare_name()  call to determine
-   whether or not one internal-format name matches another.
-
-   The GSS_Canonicalize_name() and GSS_Export_name() calls enable
-   callers to acquire and process Exported Name Objects, canonicalized
-   and translated in accordance with the procedures of a particular
-   GSS-API mechanism.  Exported Name Objects can, in turn, be input to
-   GSS_Import_name(), yielding equivalent MNs. These facilities are
-   designed specifically to enable efficient storage and comparison of
-   names (e.g., for use in access control lists).
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 13]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   The following diagram illustrates the intended dataflow among name-
-   related GSS-API processing routines.
-
-                        GSS-API library defaults
-                               |
-                               |
-                               V                         text, for
-   text -------------->  internal_name (IN) -----------> display only
-         import_name()          /          display_name()
-                               /
-                              /
-                             /
-    accept_sec_context()    /
-          |                /
-          |               /
-          |              /  canonicalize_name()
-          |             /
-          |            /
-          |           /
-          |          /
-          |         /
-          |        |
-          V        V     <---------------------
-    single mechanism        import_name()         exported name: flat
-    internal_name (MN)                            binary "blob" usable
-                         ---------------------->  for access control
-                            export_name()
-
-1.1.6:  Channel Bindings
-
-   The GSS-API accommodates the concept of caller-provided channel
-   binding ("chan_binding") information.  Channel bindings are used to
-   strengthen the quality with which peer entity authentication is
-   provided during context establishment, by limiting the scope within
-   which an intercepted context establishment token can be reused by an
-   attacker. Specifically, they enable GSS-API callers to bind the
-   establishment of a security context to relevant characteristics
-   (e.g., addresses, transformed representations of encryption keys) of
-   the underlying communications channel, of protection mechanisms
-   applied to that communications channel, and to application-specific
-   data.
-
-   The caller initiating a security context must determine the
-   appropriate channel binding values to provide as input to the
-   GSS_Init_sec_context() call, and consistent values must be provided
-   to GSS_Accept_sec_context() by the context's target, in order for
-   both peers' GSS-API mechanisms to validate that received tokens
-   possess correct channel-related characteristics. Use or non-use of
-
-
-
-Linn                        Standards Track                    [Page 14]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   the GSS-API channel binding facility is a caller option.  GSS-API
-   mechanisms can operate in an environment where NULL channel bindings
-   are presented; mechanism implementors are encouraged, but not
-   required, to make use of caller-provided channel binding data within
-   their mechanisms. Callers should not assume that underlying
-   mechanisms provide confidentiality protection for channel binding
-   information.
-
-   When non-NULL channel bindings are provided by callers, certain
-   mechanisms can offer enhanced security value by interpreting the
-   bindings' content (rather than simply representing those bindings, or
-   integrity check values computed on them, within tokens) and will
-   therefore depend on presentation of specific data in a defined
-   format. To this end, agreements among mechanism implementors are
-   defining conventional interpretations for the contents of channel
-   binding arguments, including address specifiers (with content
-   dependent on communications protocol environment) for context
-   initiators and acceptors. (These conventions are being incorporated
-   in GSS-API mechanism specifications and into the GSS-API C language
-   bindings specification.) In order for GSS-API callers to be portable
-   across multiple mechanisms and achieve the full security
-   functionality which each mechanism can provide, it is strongly
-   recommended that GSS-API callers provide channel bindings consistent
-   with these conventions and those of the networking environment in
-   which they operate.
-
-1.2:  GSS-API Features and Issues
-
-   This section describes aspects of GSS-API operations, of the security
-   services which the GSS-API provides, and provides commentary on
-   design issues.
-
-1.2.1:  Status Reporting
-
-   Each GSS-API call provides two status return values. Major_status
-   values provide a mechanism-independent indication of call status
-   (e.g., GSS_S_COMPLETE, GSS_S_FAILURE, GSS_S_CONTINUE_NEEDED),
-   sufficient to drive normal control flow within the caller in a
-   generic fashion. Table 1 summarizes the defined major_status return
-   codes in tabular fashion.
-
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 15]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-Table 1: GSS-API Major Status Codes
-
-   FATAL ERROR CODES
-
-   GSS_S_BAD_BINDINGS            channel binding mismatch
-   GSS_S_BAD_MECH                unsupported mechanism requested
-   GSS_S_BAD_NAME                invalid name provided
-   GSS_S_BAD_NAMETYPE            name of unsupported type provided
-   GSS_S_BAD_STATUS              invalid input status selector
-   GSS_S_BAD_SIG                 token had invalid integrity check
-   GSS_S_CONTEXT_EXPIRED         specified security context expired
-   GSS_S_CREDENTIALS_EXPIRED     expired credentials detected
-   GSS_S_DEFECTIVE_CREDENTIAL    defective credential detected
-   GSS_S_DEFECTIVE_TOKEN         defective token detected
-   GSS_S_FAILURE                 failure, unspecified at GSS-API
-                                   level
-   GSS_S_NO_CONTEXT              no valid security context specified
-   GSS_S_NO_CRED                 no valid credentials provided
-   GSS_S_BAD_QOP                 unsupported QOP value
-   GSS_S_UNAUTHORIZED            operation unauthorized
-   GSS_S_UNAVAILABLE             operation unavailable
-   GSS_S_DUPLICATE_ELEMENT       duplicate credential element requested
-   GSS_S_NAME_NOT_MN             name contains multi-mechanism elements
-
-   INFORMATORY STATUS CODES
-
-   GSS_S_COMPLETE                normal completion
-   GSS_S_CONTINUE_NEEDED         continuation call to routine
-                                  required
-   GSS_S_DUPLICATE_TOKEN         duplicate per-message token
-                                  detected
-   GSS_S_OLD_TOKEN               timed-out per-message token
-                                  detected
-   GSS_S_UNSEQ_TOKEN             reordered (early) per-message token
-                                  detected
-   GSS_S_GAP_TOKEN               skipped predecessor token(s)
-                                  detected
-
-   Minor_status provides more detailed status information which may
-   include status codes specific to the underlying security mechanism.
-   Minor_status values are not specified in this document.
-
-   GSS_S_CONTINUE_NEEDED major_status returns, and optional message
-   outputs, are provided in GSS_Init_sec_context() and
-   GSS_Accept_sec_context()  calls so that different mechanisms'
-   employment of different numbers of messages within their
-   authentication sequences need not be reflected in separate code paths
-   within calling applications. Instead, such cases are accommodated
-
-
-
-Linn                        Standards Track                    [Page 16]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   with sequences of continuation calls to GSS_Init_sec_context()  and
-   GSS_Accept_sec_context().  The same mechanism is used to encapsulate
-   mutual authentication within the GSS-API's context initiation calls.
-
-   For mech_types which require interactions with third-party servers in
-   order to establish a security context, GSS-API context establishment
-   calls may block pending completion of such third-party interactions.
-
-   On the other hand, no GSS-API calls pend on serialized interactions
-   with GSS-API peer entities.  As a result, local GSS-API status
-   returns cannot reflect unpredictable or asynchronous exceptions
-   occurring at remote peers, and reflection of such status information
-   is a caller responsibility outside the GSS-API.
-
-1.2.2: Per-Message Security Service Availability
-
-   When a context is established, two flags are returned to indicate the
-   set of per-message protection security services which will be
-   available on the context:
-
-      the integ_avail flag indicates whether per-message integrity and
-      data origin authentication services are available
-
-      the conf_avail flag indicates whether per-message confidentiality
-      services are available, and will never be returned TRUE unless the
-      integ_avail flag is also returned TRUE
-
-      GSS-API callers desiring per-message security services should
-      check the values of these flags at context establishment time, and
-      must be aware that a returned FALSE value for integ_avail means
-      that invocation of GSS_GetMIC()  or GSS_Wrap() primitives on the
-      associated context will apply no cryptographic protection to user
-      data messages.
-
-   The GSS-API per-message integrity and data origin authentication
-   services provide assurance to a receiving caller that protection was
-   applied to a message by the caller's peer on the security context,
-   corresponding to the entity named at context initiation.  The GSS-API
-   per-message confidentiality service provides assurance to a sending
-   caller that the message's content is protected from access by
-   entities other than the context's named peer.
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 17]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   The GSS-API per-message protection service primitives, as the
-   category name implies, are oriented to operation at the granularity
-   of protocol data units. They perform cryptographic operations on the
-   data units, transfer cryptographic control information in tokens,
-   and, in the case of GSS_Wrap(), encapsulate the protected data unit.
-   As such, these primitives are not oriented to efficient data
-   protection for stream-paradigm protocols (e.g., Telnet) if
-   cryptography must be applied on an octet-by-octet basis.
-
-1.2.3: Per-Message Replay Detection and Sequencing
-
-   Certain underlying mech_types offer support for replay detection
-   and/or sequencing of messages transferred on the contexts they
-   support. These optionally-selectable protection features are distinct
-   from replay detection and sequencing features applied to the context
-   establishment operation itself; the presence or absence of context-
-   level replay or sequencing features is wholly a function of the
-   underlying mech_type's capabilities, and is not selected or omitted
-   as a caller option.
-
-   The caller initiating a context provides flags (replay_det_req_flag
-   and sequence_req_flag) to specify whether the use of per-message
-   replay detection and sequencing features is desired on the context
-   being established. The GSS-API implementation at the initiator system
-   can determine whether these features are supported (and whether they
-   are optionally selectable) as a function of mech_type, without need
-   for bilateral negotiation with the target. When enabled, these
-   features provide recipients with indicators as a result of GSS-API
-   processing of incoming messages, identifying whether those messages
-   were detected as duplicates or out-of-sequence. Detection of such
-   events does not prevent a suspect message from being provided to a
-   recipient; the appropriate course of action on a suspect message is a
-   matter of caller policy.
-
-   The semantics of the replay detection and sequencing services applied
-   to received messages, as visible across the interface which the GSS-
-   API provides to its clients, are as follows:
-
-   When replay_det_state is TRUE, the possible major_status returns for
-   well-formed and correctly signed messages are as follows:
-
-      1. GSS_S_COMPLETE indicates that the message was within the window
-      (of time or sequence space) allowing replay events to be detected,
-      and that the message was not a replay of a previously-processed
-      message within that window.
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 18]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-      2. GSS_S_DUPLICATE_TOKEN indicates that the cryptographic
-      checkvalue on the received message was correct, but that the
-      message was recognized as a duplicate of a previously-processed
-      message.
-
-      3. GSS_S_OLD_TOKEN indicates that the cryptographic checkvalue on
-      the received message was correct, but that the message is too old
-      to be checked for duplication.
-
-   When sequence_state is TRUE, the possible major_status returns for
-   well-formed and correctly signed messages are as follows:
-
-      1. GSS_S_COMPLETE indicates that the message was within the window
-      (of time or sequence space) allowing replay events to be detected,
-      that the message was not a replay of a previously-processed
-      message within that window, and that no predecessor sequenced
-      messages are missing relative to the last received message (if
-      any) processed on the context with a correct cryptographic
-      checkvalue.
-
-      2. GSS_S_DUPLICATE_TOKEN indicates that the integrity check value
-      on the received message was correct, but that the message was
-      recognized as a duplicate of a previously-processed message.
-
-      3. GSS_S_OLD_TOKEN indicates that the integrity check value on the
-      received message was correct, but that the token is too old to be
-      checked for duplication.
-
-      4. GSS_S_UNSEQ_TOKEN indicates that the cryptographic checkvalue
-      on the received message was correct, but that it is earlier in a
-      sequenced stream than a message already processed on the context.
-      [Note: Mechanisms can be architected to provide a stricter form of
-      sequencing service, delivering particular messages to recipients
-      only after all predecessor messages in an ordered stream have been
-      delivered.  This type of support is incompatible with the GSS-API
-      paradigm in which recipients receive all messages, whether in
-      order or not, and provide them (one at a time, without intra-GSS-
-      API message buffering) to GSS-API routines for validation.  GSS-
-      API facilities provide supportive functions, aiding clients to
-      achieve strict message stream integrity in an efficient manner in
-      conjunction with sequencing provisions in communications
-      protocols, but the GSS-API does not offer this level of message
-      stream integrity service by itself.]
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 19]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-      5. GSS_S_GAP_TOKEN indicates that the cryptographic checkvalue on
-      the received message was correct, but that one or more predecessor
-      sequenced messages have not been successfully processed relative
-      to the last received message (if any) processed on the context
-      with a correct cryptographic checkvalue.
-
-   As the message stream integrity features (especially sequencing) may
-   interfere with certain applications' intended communications
-   paradigms, and since support for such features is likely to be
-   resource intensive, it is highly recommended that mech_types
-   supporting these features allow them to be activated selectively on
-   initiator request when a context is established. A context initiator
-   and target are provided with corresponding indicators
-   (replay_det_state and sequence_state), signifying whether these
-   features are active on a given context.
-
-   An example mech_type supporting per-message replay detection could
-   (when replay_det_state is TRUE) implement the feature as follows: The
-   underlying mechanism would insert timestamps in data elements output
-   by GSS_GetMIC()  and GSS_Wrap(), and would maintain (within a time-
-   limited window) a cache (qualified by originator-recipient pair)
-   identifying received data elements processed by GSS_VerifyMIC()  and
-   GSS_Unwrap(). When this feature is active, exception status returns
-   (GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN) will be provided when
-   GSS_VerifyMIC()  or GSS_Unwrap() is presented with a message which is
-   either a detected duplicate of a prior message or which is too old to
-   validate against a cache of recently received messages.
-
-1.2.4:  Quality of Protection
-
-   Some mech_types provide their users with fine granularity control
-   over the means used to provide per-message protection, allowing
-   callers to trade off security processing overhead dynamically against
-   the protection requirements of particular messages. A per-message
-   quality-of-protection parameter (analogous to quality-of-service, or
-   QOS) selects among different QOP options supported by that mechanism.
-   On context establishment for a multi-QOP mech_type, context-level
-   data provides the prerequisite data for a range of protection
-   qualities.
-
-   It is expected that the majority of callers will not wish to exert
-   explicit mechanism-specific QOP control and will therefore request
-   selection of a default QOP. Definitions of, and choices among, non-
-   default QOP values are mechanism-specific, and no ordered sequences
-   of QOP values can be assumed equivalent across different mechanisms.
-   Meaningful use of non-default QOP values demands that callers be
-   familiar with the QOP definitions of an underlying mechanism or
-   mechanisms, and is therefore a non-portable construct.  The
-
-
-
-Linn                        Standards Track                    [Page 20]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   GSS_S_BAD_QOP major_status value is defined in order to indicate that
-   a provided QOP value is unsupported for a security context, most
-   likely because that value is unrecognized by the underlying
-   mechanism.
-
-1.2.5: Anonymity Support
-
-   In certain situations or environments, an application may wish to
-   authenticate a peer and/or protect communications using GSS-API per-
-   message services without revealing its own identity.  For example,
-   consider an application which provides read access to a research
-   database, and which permits queries by arbitrary requestors.  A
-   client of such a service might wish to authenticate the service, to
-   establish trust in the information received from it, but might not
-   wish to disclose its identity to the service for privacy reasons.
-
-   In ordinary GSS-API usage, a context initiator's identity is made
-   available to the context acceptor as part of the context
-   establishment process.  To provide for anonymity support, a facility
-   (input anon_req_flag to GSS_Init_sec_context()) is provided through
-   which context initiators may request that their identity not be
-   provided to the context acceptor.  Mechanisms are not required to
-   honor this request, but a caller will be informed (via returned
-   anon_state indicator from GSS_Init_sec_context()) whether or not the
-   request is honored. Note that authentication as the anonymous
-   principal does not necessarily imply that credentials are not
-   required in order to establish a context.
-
-   The following Object Identifier value is provided as a means to
-   identify anonymous names, and can be compared against in order to
-   determine, in a mechanism-independent fashion, whether a name refers
-   to an anonymous principal:
-
-   {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
-   3(gss-anonymous-name)}
-
-   The recommended symbolic name corresponding to this definition is
-   GSS_C_NT_ANONYMOUS.
-
-   Four possible combinations of anon_state and mutual_state are
-   possible, with the following results:
-
-      anon_state == FALSE, mutual_state == FALSE: initiator
-      authenticated to target.
-
-      anon_state == FALSE, mutual_state == TRUE: initiator authenticated
-      to target, target authenticated to initiator.
-
-
-
-
-Linn                        Standards Track                    [Page 21]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-      anon_state == TRUE, mutual_state == FALSE: initiator authenticated
-      as anonymous principal to target.
-
-      anon_state == TRUE, mutual_state == TRUE: initiator authenticated
-      as anonymous principal to target, target authenticated to
-      initiator.
-
-1.2.6: Initialization
-
-   No initialization calls (i.e., calls which must be invoked prior to
-   invocation of other facilities in the interface) are defined in GSS-
-   API.  As an implication of this fact, GSS-API implementations must
-   themselves be self-initializing.
-
-1.2.7: Per-Message Protection During Context Establishment
-
-   A facility is defined in GSS-V2 to enable protection and buffering of
-   data messages for later transfer while a security context's
-   establishment is in GSS_S_CONTINUE_NEEDED status, to be used in cases
-   where the caller side already possesses the necessary session key to
-   enable this processing. Specifically, a new state Boolean, called
-   prot_ready_state, is added to the set of information returned by
-   GSS_Init_sec_context(), GSS_Accept_sec_context(), and
-   GSS_Inquire_context().
-
-   For context establishment calls, this state Boolean is valid and
-   interpretable when the associated major_status is either
-   GSS_S_CONTINUE_NEEDED, or GSS_S_COMPLETE.  Callers of GSS-API (both
-   initiators and acceptors) can assume that per-message protection (via
-   GSS_Wrap(), GSS_Unwrap(), GSS_GetMIC() and GSS_VerifyMIC()) is
-   available and ready for use if either: prot_ready_state == TRUE, or
-   major_status == GSS_S_COMPLETE, though mutual authentication (if
-   requested) cannot be guaranteed until GSS_S_COMPLETE is returned.
-
-   This achieves full, transparent backward compatibility for GSS-API V1
-   callers, who need not even know of the existence of prot_ready_state,
-   and who will get the expected behavior from GSS_S_COMPLETE, but who
-   will not be able to use per-message protection before GSS_S_COMPLETE
-   is returned.
-
-   It is not a requirement that GSS-V2 mechanisms ever return TRUE
-   prot_ready_state before completion of context establishment (indeed,
-   some mechanisms will not evolve usable message protection keys,
-   especially at the context acceptor, before context establishment is
-   complete).  It is expected but not required that GSS-V2 mechanisms
-   will return TRUE prot_ready_state upon completion of context
-   establishment if they support per-message protection at all (however
-   GSS-V2 applications should not assume that TRUE prot_ready_state will
-
-
-
-Linn                        Standards Track                    [Page 22]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   always be returned together with the GSS_S_COMPLETE major_status,
-   since GSS-V2 implementations may continue to support GSS-V1 mechanism
-   code, which will never return TRUE prot_ready_state).
-
-   When prot_ready_state is returned TRUE, mechanisms shall also set
-   those context service indicator flags (deleg_state, mutual_state,
-   replay_det_state, sequence_state, anon_state, trans_state,
-   conf_avail, integ_avail) which represent facilities confirmed, at
-   that time, to be available on the context being established.  In
-   situations where prot_ready_state is returned before GSS_S_COMPLETE,
-   it is possible that additional facilities may be confirmed and
-   subsequently indicated when GSS_S_COMPLETE is returned.
-
-1.2.8: Implementation Robustness
-
-   This section recommends aspects of GSS-API implementation behavior in
-   the interests of overall robustness.
-
-   If a token is presented for processing on a GSS-API security context
-   and that token is determined to be invalid for that context, the
-   context's state should not be disrupted for purposes of processing
-   subsequent valid tokens.
-
-   Certain local conditions at a GSS-API implementation (e.g.,
-   unavailability of memory) may preclude, temporarily or permanently,
-   the successful processing of tokens on a GSS-API security context,
-   typically generating GSS_S_FAILURE major_status returns along with
-   locally-significant minor_status.  For robust operation under such
-   conditions, the following recommendations are made:
-
-      Failing calls should free any memory they allocate, so that
-      callers may retry without causing further loss of resources.
-
-      Failure of an individual call on an established context should not
-      preclude subsequent calls from succeeding on the same context.
-
-      Whenever possible, it should be possible for
-      GSS_Delete_sec_context() calls to be successfully processed even
-      if other calls cannot succeed, thereby enabling context-related
-      resources to be released.
-
-2:  Interface Descriptions
-
-   This section describes the GSS-API's service interface, dividing the
-   set of calls offered into four groups. Credential management calls
-   are related to the acquisition and release of credentials by
-   principals. Context-level calls are related to the management of
-   security contexts between principals. Per-message calls are related
-
-
-
-Linn                        Standards Track                    [Page 23]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   to the protection of individual messages on established security
-   contexts. Support calls provide ancillary functions useful to GSS-API
-   callers. Table 2 groups and summarizes the calls in tabular fashion.
-
-Table 2:  GSS-API Calls
-
-   CREDENTIAL MANAGEMENT
-
-   GSS_Acquire_cred             acquire credentials for use
-   GSS_Release_cred             release credentials after use
-   GSS_Inquire_cred             display information about
-                                credentials
-   GSS_Add_cred                 construct credentials incrementally
-   GSS_Inquire_cred_by_mech     display per-mechanism credential
-                                information
-
-   CONTEXT-LEVEL CALLS
-
-   GSS_Init_sec_context         initiate outbound security context
-   GSS_Accept_sec_context       accept inbound security context
-   GSS_Delete_sec_context       flush context when no longer needed
-   GSS_Process_context_token    process received control token on
-                                context
-   GSS_Context_time             indicate validity time remaining on
-                                      context
-   GSS_Inquire_context          display information about context
-   GSS_Wrap_size_limit          determine GSS_Wrap token size limit
-   GSS_Export_sec_context       transfer context to other process
-   GSS_Import_sec_context       import transferred context
-
-   PER-MESSAGE CALLS
-
-   GSS_GetMIC                   apply integrity check, receive as
-                                token separate from message
-   GSS_VerifyMIC                validate integrity check token
-                                along with message
-   GSS_Wrap                     sign, optionally encrypt,
-                                encapsulate
-   GSS_Unwrap                   decapsulate, decrypt if needed,
-                                validate integrity check
-
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 24]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   SUPPORT CALLS
-
-   GSS_Display_status           translate status codes to printable
-                                form
-   GSS_Indicate_mechs           indicate mech_types supported on
-                                local system
-   GSS_Compare_name             compare two names for equality
-   GSS_Display_name             translate name to printable form
-   GSS_Import_name              convert printable name to
-                                normalized form
-   GSS_Release_name             free storage of normalized-form
-                                name
-   GSS_Release_buffer           free storage of printable name
-   GSS_Release_OID              free storage of OID object
-   GSS_Release_OID_set          free storage of OID set object
-   GSS_Create_empty_OID_set     create empty OID set
-   GSS_Add_OID_set_member       add member to OID set
-   GSS_Test_OID_set_member      test if OID is member of OID set
-   GSS_OID_to_str               display OID as string
-   GSS_Str_to_OID               construct OID from string
-   GSS_Inquire_names_for_mech   indicate name types supported by
-                                mechanism
-   GSS_Inquire_mechs_for_name   indicates mechanisms supporting name
-                                type
-   GSS_Canonicalize_name        translate name to per-mechanism form
-   GSS_Export_name              externalize per-mechanism name
-   GSS_Duplicate_name           duplicate name object
-
-2.1:  Credential management calls
-
-   These GSS-API calls provide functions related to the management of
-   credentials. Their characterization with regard to whether or not
-   they may block pending exchanges with other network entities (e.g.,
-   directories or authentication servers) depends in part on OS-specific
-   (extra-GSS-API) issues, so is not specified in this document.
-
-   The GSS_Acquire_cred() call is defined within the GSS-API in support
-   of application portability, with a particular orientation towards
-   support of portable server applications. It is recognized that (for
-   certain systems and mechanisms) credentials for interactive users may
-   be managed differently from credentials for server processes; in such
-   environments, it is the GSS-API implementation's responsibility to
-   distinguish these cases and the procedures for making this
-   distinction are a local matter. The GSS_Release_cred()  call provides
-   a means for callers to indicate to the GSS-API that use of a
-   credentials structure is no longer required. The GSS_Inquire_cred()
-   call allows callers to determine information about a credentials
-   structure.  The GSS_Add_cred() call enables callers to append
-
-
-
-Linn                        Standards Track                    [Page 25]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   elements to an existing credential structure, allowing iterative
-   construction of a multi-mechanism credential. The
-   GSS_Inquire_cred_by_mech() call enables callers to extract per-
-   mechanism information describing a credentials structure.
-
-2.1.1:  GSS_Acquire_cred call
-
-   Inputs:
-
-   o  desired_name INTERNAL NAME, -NULL requests locally-determined
-      default
-
-   o  lifetime_req INTEGER,-in seconds; 0 requests default
-
-   o  desired_mechs SET OF OBJECT IDENTIFIER,-empty set requests
-      system-selected default
-
-   o  cred_usage INTEGER -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-      2=ACCEPT-ONLY
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_cred_handle CREDENTIAL HANDLE,
-
-   o  actual_mechs SET OF OBJECT IDENTIFIER,
-
-   o  lifetime_rec INTEGER -in seconds, or reserved value for
-      INDEFINITE
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that requested credentials were
-      successfully established, for the duration indicated in
-      lifetime_rec, suitable for the usage requested in cred_usage,
-      for the set of mech_types indicated in actual_mechs, and that
-      those credentials can be referenced for subsequent use with
-      the handle returned in output_cred_handle.
-
-   o  GSS_S_BAD_MECH indicates that a mech_type unsupported by the
-      GSS-API implementation type was requested, causing the
-      credential establishment operation to fail.
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 26]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_BAD_NAMETYPE indicates that the provided desired_name is
-      uninterpretable or of a type unsupported by the applicable
-      underlying GSS-API mechanism(s), so no credentials could be
-      established for the accompanying desired_name.
-
-   o  GSS_S_BAD_NAME indicates that the provided desired_name is
-      inconsistent in terms of internally-incorporated type specifier
-      information, so no credentials could be established for the
-      accompanying desired_name.
-
-   o  GSS_S_FAILURE indicates that credential establishment failed
-      for reasons unspecified at the GSS-API level, including lack
-      of authorization to establish and use credentials associated
-      with the identity named in the input desired_name argument.
-
-   GSS_Acquire_cred()  is used to acquire credentials so that a
-   principal can (as a function of the input cred_usage parameter)
-   initiate and/or accept security contexts under the identity
-   represented by the desired_name input argument. On successful
-   completion, the returned output_cred_handle result provides a handle
-   for subsequent references to the acquired credentials.  Typically,
-   single-user client processes requesting that default credential
-   behavior be applied for context establishment purposes will have no
-   need to invoke this call.
-
-   A caller may provide the value NULL for desired_name, signifying a
-   request for credentials corresponding to a principal identity
-   selected by default for the caller. The procedures used by GSS-API
-   implementations to select the appropriate principal identity in
-   response to such a request are local matters. It is possible that
-   multiple pre-established credentials may exist for the same principal
-   identity (for example, as a result of multiple user login sessions)
-   when GSS_Acquire_cred() is called; the means used in such cases to
-   select a specific credential are local matters.  The input
-   lifetime_req argument to GSS_Acquire_cred() may provide useful
-   information for local GSS-API implementations to employ in making
-   this disambiguation in a manner which will best satisfy a caller's
-   intent.
-
-   The lifetime_rec result indicates the length of time for which the
-   acquired credentials will be valid, as an offset from the present. A
-   mechanism may return a reserved value indicating INDEFINITE if no
-   constraints on credential lifetime are imposed.  A caller of
-   GSS_Acquire_cred()  can request a length of time for which acquired
-   credentials are to be valid (lifetime_req argument), beginning at the
-   present, or can request credentials with a default validity interval.
-   (Requests for postdated credentials are not supported within the
-   GSS-API.) Certain mechanisms and implementations may bind in
-
-
-
-Linn                        Standards Track                    [Page 27]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   credential validity period specifiers at a point preliminary to
-   invocation of the GSS_Acquire_cred() call (e.g., in conjunction with
-   user login procedures). As a result, callers requesting non-default
-   values for lifetime_req must recognize that such requests cannot
-   always be honored and must be prepared to accommodate the use of
-   returned credentials with different lifetimes as indicated in
-   lifetime_rec.
-
-   The caller of GSS_Acquire_cred()  can explicitly specify a set of
-   mech_types which are to be accommodated in the returned credentials
-   (desired_mechs argument), or can request credentials for a system-
-   defined default set of mech_types. Selection of the system-specified
-   default set is recommended in the interests of application
-   portability. The actual_mechs return value may be interrogated by the
-   caller to determine the set of mechanisms with which the returned
-   credentials may be used.
-
-2.1.2:  GSS_Release_cred call
-
-   Input:
-
-   o  cred_handle CREDENTIAL HANDLE - NULL specifies that
-      the credential elements used when default credential behavior
-      is requested be released.
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the credentials referenced by the
-      input cred_handle were released for purposes of subsequent
-      access by the caller. The effect on other processes which may
-      be authorized shared access to such credentials is a local
-      matter.
-
-   o  GSS_S_NO_CRED indicates that no release operation was
-      performed, either because the input cred_handle was invalid or
-      because the caller lacks authorization to access the
-      referenced credentials.
-
-   o  GSS_S_FAILURE indicates that the release operation failed for
-      reasons unspecified at the GSS-API level.
-
-
-
-
-
-Linn                        Standards Track                    [Page 28]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   Provides a means for a caller to explicitly request that credentials
-   be released when their use is no longer required. Note that system-
-   specific credential management functions are also likely to exist,
-   for example to assure that credentials shared among processes are
-   properly deleted when all affected processes terminate, even if no
-   explicit release requests are issued by those processes. Given the
-   fact that multiple callers are not precluded from gaining authorized
-   access to the same credentials, invocation of GSS_Release_cred()
-   cannot be assumed to delete a particular set of credentials on a
-   system-wide basis.
-
-2.1.3:  GSS_Inquire_cred call
-
-   Input:
-
-   o  cred_handle CREDENTIAL HANDLE -NULL specifies that the
-      credential elements used when default credential behavior is
-      requested are to be queried
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  cred_name INTERNAL NAME,
-
-   o  lifetime_rec INTEGER -in seconds, or reserved value for
-      INDEFINITE
-
-   o  cred_usage INTEGER, -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-      2=ACCEPT-ONLY
-
-   o  mech_set SET OF OBJECT IDENTIFIER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the credentials referenced by the
-      input cred_handle argument were valid, and that the output
-      cred_name, lifetime_rec, and cred_usage values represent,
-      respectively, the credentials' associated principal name,
-      remaining lifetime, suitable usage modes, and supported
-      mechanism types.
-
-   o  GSS_S_NO_CRED indicates that no information could be returned
-      about the referenced credentials, either because the input
-      cred_handle was invalid or because the caller lacks
-      authorization to access the referenced credentials.
-
-
-
-Linn                        Standards Track                    [Page 29]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that the referenced
-      credentials are invalid.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the referenced
-      credentials have expired.
-
-   o  GSS_S_FAILURE indicates that the operation failed for
-      reasons unspecified at the GSS-API level.
-
-   The GSS_Inquire_cred() call is defined primarily for the use of those
-   callers which request use of default credential behavior rather than
-   acquiring credentials explicitly with GSS_Acquire_cred().  It enables
-   callers to determine a credential structure's associated principal
-   name, remaining validity period, usability for security context
-   initiation and/or acceptance, and supported mechanisms.
-
-   For a multi-mechanism credential, the returned "lifetime" specifier
-   indicates the shortest lifetime of any of the mechanisms' elements in
-   the credential (for either context initiation or acceptance
-   purposes).
-
-   GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for
-   "cred_usage" if both of the following conditions hold:
-
-      (1) there exists in the credential an element which allows context
-      initiation using some mechanism
-
-      (2) there exists in the credential an element which allows context
-      acceptance using some mechanism (allowably, but not necessarily,
-      one of the same mechanism(s) qualifying for (1)).
-
-   If condition (1) holds but not condition (2), GSS_Inquire_cred()
-   should indicate INITIATE-ONLY for "cred_usage".  If condition (2)
-   holds but not condition (1), GSS_Inquire_cred() should indicate
-   ACCEPT-ONLY for "cred_usage".
-
-   Callers requiring finer disambiguation among available combinations
-   of lifetimes, usage modes, and mechanisms should call the
-   GSS_Inquire_cred_by_mech() routine, passing that routine one of the
-   mech OIDs returned by GSS_Inquire_cred().
-
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 30]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-2.1.4:  GSS_Add_cred call
-
-   Inputs:
-
-   o  input_cred_handle CREDENTIAL HANDLE - handle to credential
-      structure created with prior GSS_Acquire_cred() or
-      GSS_Add_cred() call, or NULL to append elements to the set
-      which are applied for the caller when default credential
-      behavior is specified.
-
-   o  desired_name INTERNAL NAME - NULL requests locally-determined
-      default
-
-   o  initiator_time_req INTEGER - in seconds; 0 requests default
-
-   o  acceptor_time_req INTEGER - in seconds; 0 requests default
-
-   o  desired_mech OBJECT IDENTIFIER
-
-   o  cred_usage INTEGER - 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-       2=ACCEPT-ONLY
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_cred_handle CREDENTIAL HANDLE, - NULL to request that
-      credential elements be added "in place" to the credential
-      structure  identified by input_cred_handle, non-NULL pointer
-      to request that a new credential structure and handle be created.
-
-   o  actual_mechs SET OF OBJECT IDENTIFIER,
-
-   o  initiator_time_rec INTEGER - in seconds, or reserved value for
-      INDEFINITE
-
-   o  acceptor_time_rec INTEGER - in seconds, or reserved value for
-      INDEFINITE
-
-   o  cred_usage INTEGER, -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-      2=ACCEPT-ONLY
-
-   o  mech_set SET OF OBJECT IDENTIFIER -- full set of mechanisms
-      supported by resulting credential.
-
-
-
-
-
-Linn                        Standards Track                    [Page 31]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the credentials referenced by
-      the input_cred_handle argument were valid, and that the
-      resulting credential from GSS_Add_cred() is valid for the
-      durations indicated in initiator_time_rec and acceptor_time_rec,
-      suitable for the usage requested in cred_usage, and for the
-      mechanisms indicated in actual_mechs.
-
-   o  GSS_S_DUPLICATE_ELEMENT indicates that the input desired_mech
-      specified a mechanism for which the referenced credential
-      already contained a credential element with overlapping
-      cred_usage and validity time specifiers.
-
-   o  GSS_S_BAD_MECH indicates that the input desired_mech specified
-      a mechanism unsupported by the GSS-API implementation, causing
-      the GSS_Add_cred() operation to fail.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the provided desired_name
-      is uninterpretable or of a type unsupported by the applicable
-      underlying GSS-API mechanism(s), so the GSS_Add_cred() operation
-      could not be performed for that name.
-
-   o  GSS_S_BAD_NAME indicates that the provided desired_name is
-      inconsistent in terms of internally-incorporated type specifier
-      information, so the GSS_Add_cred() operation could not be
-      performed for that name.
-
-   o  GSS_S_NO_CRED indicates that the input_cred_handle referenced
-      invalid or inaccessible credentials.
-
-   o  GSS_S_FAILURE indicates that the operation failed for
-      reasons unspecified at the GSS-API level, including lack of
-      authorization to establish or use credentials representing
-      the requested identity.
-
-   GSS_Add_cred() enables callers to construct credentials iteratively
-   by adding credential elements in successive operations, corresponding
-   to different mechanisms.  This offers particular value in multi-
-   mechanism environments, as the major_status and minor_status values
-   returned on each iteration are individually visible and can therefore
-   be interpreted unambiguously on a per-mechanism basis.
-
-   The same input desired_name, or default reference, should be used on
-   all GSS_Acquire_cred() and GSS_Add_cred() calls corresponding to a
-   particular credential.
-
-
-
-
-
-Linn                        Standards Track                    [Page 32]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-2.1.5:  GSS_Inquire_cred_by_mech call
-
-   Inputs:
-
-   o  cred_handle CREDENTIAL HANDLE  -- NULL specifies that the
-      credential elements used when default credential behavior is
-      requested are to be queried
-
-   o  mech_type OBJECT IDENTIFIER  -- specific mechanism for
-      which credentials are being queried
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  cred_name INTERNAL NAME, -- guaranteed to be MN
-
-   o  lifetime_rec_initiate INTEGER -- in seconds, or reserved value for
-      INDEFINITE
-
-   o  lifetime_rec_accept INTEGER -- in seconds, or reserved value for
-      INDEFINITE
-
-   o  cred_usage INTEGER, -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-      2=ACCEPT-ONLY
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the credentials referenced by the
-      input cred_handle argument were valid, that the mechanism
-      indicated by the input mech_type was represented with elements
-      within those credentials, and that the output cred_name,
-      lifetime_rec_initiate, lifetime_rec_accept, and cred_usage values
-      represent, respectively, the credentials' associated principal
-      name, remaining lifetimes, and suitable usage modes.
-
-   o  GSS_S_NO_CRED indicates that no information could be returned
-      about the referenced credentials, either because the input
-      cred_handle was invalid or because the caller lacks
-      authorization to access the referenced credentials.
-
-   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that the referenced
-      credentials are invalid.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the referenced
-      credentials have expired.
-
-
-
-Linn                        Standards Track                    [Page 33]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_BAD_MECH indicates that the referenced credentials do not
-      contain elements for the requested mechanism.
-
-   o  GSS_S_FAILURE indicates that the operation failed for reasons
-      unspecified at the GSS-API level.
-
-   The GSS_Inquire_cred_by_mech() call enables callers in multi-
-   mechanism environments to acquire specific data about available
-   combinations of lifetimes, usage modes, and mechanisms within a
-   credential structure.  The lifetime_rec_initiate result indicates the
-   available lifetime for context initiation purposes; the
-   lifetime_rec_accept result indicates the available lifetime for
-   context acceptance purposes.
-
-2.2:  Context-level calls
-
-   This group of calls is devoted to the establishment and management of
-   security contexts between peers. A context's initiator calls
-   GSS_Init_sec_context(),  resulting in generation of a token which the
-   caller passes to the target. At the target, that token is passed to
-   GSS_Accept_sec_context().  Depending on the underlying mech_type and
-   specified options, additional token exchanges may be performed in the
-   course of context establishment; such exchanges are accommodated by
-   GSS_S_CONTINUE_NEEDED status returns from GSS_Init_sec_context()  and
-   GSS_Accept_sec_context().
-
-   Either party to an established context may invoke
-   GSS_Delete_sec_context() to flush context information when a context
-   is no longer required. GSS_Process_context_token()  is used to
-   process received tokens carrying context-level control information.
-   GSS_Context_time()  allows a caller to determine the length of time
-   for which an established context will remain valid.
-   GSS_Inquire_context() returns status information describing context
-   characteristics. GSS_Wrap_size_limit() allows a caller to determine
-   the size of a token which will be generated by a GSS_Wrap()
-   operation.  GSS_Export_sec_context() and GSS_Import_sec_context()
-   enable transfer of active contexts between processes on an end
-   system.
-
-2.2.1:  GSS_Init_sec_context call
-
-   Inputs:
-
-   o  claimant_cred_handle CREDENTIAL HANDLE, -NULL specifies "use
-      default"
-
-   o  input_context_handle CONTEXT HANDLE, -0 specifies "none assigned
-      yet"
-
-
-
-Linn                        Standards Track                    [Page 34]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  targ_name INTERNAL NAME,
-
-   o  mech_type OBJECT IDENTIFIER, -NULL parameter specifies "use
-      default"
-
-   o  deleg_req_flag BOOLEAN,
-
-   o  mutual_req_flag BOOLEAN,
-
-   o  replay_det_req_flag BOOLEAN,
-
-   o  sequence_req_flag BOOLEAN,
-
-   o  anon_req_flag BOOLEAN,
-
-   o  lifetime_req INTEGER,-0 specifies default lifetime
-
-   o  chan_bindings OCTET STRING,
-
-   o  input_token OCTET STRING-NULL or token received from target
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_context_handle CONTEXT HANDLE,
-
-   o  mech_type OBJECT IDENTIFIER, -actual mechanism always
-      indicated, never NULL
-
-   o  output_token OCTET STRING, -NULL or token to pass to context
-      target
-
-   o  deleg_state BOOLEAN,
-
-   o  mutual_state BOOLEAN,
-
-   o  replay_det_state BOOLEAN,
-
-   o  sequence_state BOOLEAN,
-
-   o  anon_state BOOLEAN,
-
-   o  trans_state BOOLEAN,
-
-   o  prot_ready_state BOOLEAN, -- see Section 1.2.7
-
-
-
-Linn                        Standards Track                    [Page 35]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  conf_avail BOOLEAN,
-
-   o  integ_avail BOOLEAN,
-
-   o  lifetime_rec INTEGER - in seconds, or reserved value for
-      INDEFINITE
-
-   This call may block pending network interactions for those mech_types
-   in which an authentication server or other network entity must be
-   consulted on behalf of a context initiator in order to generate an
-   output_token suitable for presentation to a specified target.
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that context-level information was
-      successfully initialized, and that the returned output_token
-      will provide sufficient information for the target to perform
-      per-message processing on the newly-established context.
-
-   o  GSS_S_CONTINUE_NEEDED indicates that control information in the
-      returned output_token must be sent to the target, and that a
-      reply must be received and passed as the input_token argument
-      to a continuation call to GSS_Init_sec_context(),  before
-      per-message processing can be performed in conjunction with
-      this context.
-
-   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks
-      performed on the input_token failed, preventing further
-      processing from being performed based on that token.
-
-   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks
-      performed on the credential structure referenced by
-      claimant_cred_handle failed, preventing further processing from
-      being performed using that credential structure.
-
-   o  GSS_S_BAD_SIG indicates that the received input_token
-      contains an incorrect integrity check, so context setup cannot
-      be accomplished.
-
-   o  GSS_S_NO_CRED indicates that no context was established,
-      either because the input cred_handle was invalid, because the
-      referenced credentials are valid for context acceptor use
-      only, or because the caller lacks authorization to access the
-      referenced credentials.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the credentials
-      provided through the input claimant_cred_handle argument are no
-      longer valid, so context establishment cannot be completed.
-
-
-
-Linn                        Standards Track                    [Page 36]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_BAD_BINDINGS indicates that a mismatch between the
-      caller-provided chan_bindings and those extracted from the
-      input_token was detected, signifying a security-relevant
-      event and preventing context establishment. (This result will
-      be returned by GSS_Init_sec_context only for contexts where
-      mutual_state is TRUE.)
-
-   o  GSS_S_OLD_TOKEN indicates that the input_token is too old to
-      be checked for integrity. This is a fatal error during context
-      establishment.
-
-   o  GSS_S_DUPLICATE_TOKEN indicates that the input token has a
-      correct integrity check, but is a duplicate of a token already
-      processed. This is a fatal error during context establishment.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-      for the input context_handle provided; this major status will
-      be returned only for successor calls following GSS_S_CONTINUE_
-      NEEDED status returns.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the provided targ_name is
-      of a type uninterpretable or unsupported by the applicable
-      underlying GSS-API mechanism(s), so context establishment
-      cannot be completed.
-
-   o  GSS_S_BAD_NAME indicates that the provided targ_name is
-      inconsistent in terms of internally-incorporated type specifier
-      information, so context establishment cannot be accomplished.
-
-   o  GSS_S_BAD_MECH indicates receipt of a context establishment token
-      or of a caller request specifying a mechanism unsupported by
-      the local system or with the caller's active credentials
-
-   o  GSS_S_FAILURE indicates that context setup could not be
-      accomplished for reasons unspecified at the GSS-API level, and
-      that no interface-defined recovery action is available.
-
-   This routine is used by a context initiator, and ordinarily emits one
-   (or, for the case of a multi-step exchange, more than one)
-   output_token suitable for use by the target within the selected
-   mech_type's protocol. Using information in the credentials structure
-   referenced by claimant_cred_handle, GSS_Init_sec_context()
-   initializes the data structures required to establish a security
-   context with target targ_name. The targ_name may be any valid
-   INTERNAL NAME; it need not be an MN. The claimant_cred_handle must
-   correspond to the same valid credentials structure on the initial
-   call to GSS_Init_sec_context()  and on any successor calls resulting
-   from GSS_S_CONTINUE_NEEDED status returns; different protocol
-
-
-
-Linn                        Standards Track                    [Page 37]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   sequences modeled by the GSS_S_CONTINUE_NEEDED facility will require
-   access to credentials at different points in the context
-   establishment sequence.
-
-   The input_context_handle argument is 0, specifying "not yet
-   assigned", on the first GSS_Init_sec_context()  call relating to a
-   given context. If successful (i.e., if accompanied by major_status
-   GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and only if successful, the
-   initial GSS_Init_sec_context() call returns a non-zero
-   output_context_handle for use in future references to this context.
-   Once a non-zero output_context_handle has been returned, GSS-API
-   callers should call GSS_Delete_sec_context() to release context-
-   related resources if errors occur in later phases of context
-   establishment, or when an established context is no longer required.
-
-   When continuation attempts to GSS_Init_sec_context() are needed to
-   perform context establishment, the previously-returned non-zero
-   handle value is entered into the input_context_handle argument and
-   will be echoed in the returned output_context_handle argument. On
-   such continuation attempts (and only on continuation attempts) the
-   input_token value is used, to provide the token returned from the
-   context's target.
-
-   The chan_bindings argument is used by the caller to provide
-   information binding the security context to security-related
-   characteristics (e.g., addresses, cryptographic keys) of the
-   underlying communications channel. See Section 1.1.6 of this document
-   for more discussion of this argument's usage.
-
-   The input_token argument contains a message received from the target,
-   and is significant only on a call to GSS_Init_sec_context()  which
-   follows a previous return indicating GSS_S_CONTINUE_NEEDED
-   major_status.
-
-   It is the caller's responsibility to establish a communications path
-   to the target, and to transmit any returned output_token (independent
-   of the accompanying returned major_status value) to the target over
-   that path. The output_token can, however, be transmitted along with
-   the first application-provided input message to be processed by
-   GSS_GetMIC() or GSS_Wrap() in conjunction with a successfully-
-   established context.
-
-   The initiator may request various context-level functions through
-   input flags: the deleg_req_flag requests delegation of access rights,
-   the mutual_req_flag requests mutual authentication, the
-   replay_det_req_flag requests that replay detection features be
-   applied to messages transferred on the established context, and the
-   sequence_req_flag requests that sequencing be enforced. (See Section
-
-
-
-Linn                        Standards Track                    [Page 38]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   1.2.3 for more information on replay detection and sequencing
-   features.)  The anon_req_flag requests that the initiator's identity
-   not be transferred within tokens to be sent to the acceptor.
-
-   Not all of the optionally-requestable features will be available in
-   all underlying mech_types. The corresponding return state values
-   deleg_state, mutual_state, replay_det_state, and sequence_state
-   indicate, as a function of mech_type processing capabilities and
-   initiator-provided input flags, the set of features which will be
-   active on the context.  The returned trans_state value indicates
-   whether the context is transferable to other processes through use of
-   GSS_Export_sec_context().  These state indicators' values are
-   undefined unless either the routine's major_status indicates
-   GSS_S_COMPLETE, or TRUE prot_ready_state is returned along with
-   GSS_S_CONTINUE_NEEDED major_status; for the latter case, it is
-   possible that additional features, not confirmed or indicated along
-   with TRUE prot_ready_state, will be confirmed and indicated when
-   GSS_S_COMPLETE is subsequently returned.
-
-   The returned anon_state and prot_ready_state values are significant
-   for both GSS_S_COMPLETE and GSS_S_CONTINUE_NEEDED major_status
-   returns from GSS_Init_sec_context().  When anon_state is returned
-   TRUE, this indicates that neither the current token nor its
-   predecessors delivers or has delivered the initiator's identity.
-   Callers wishing to perform context establishment only if anonymity
-   support is provided should transfer a returned token from
-   GSS_Init_sec_context() to the peer only if it is accompanied by a
-   TRUE anon_state indicator.  When prot_ready_state is returned TRUE in
-   conjunction with GSS_S_CONTINUE_NEEDED major_status, this indicates
-   that per-message protection operations may be applied on the context:
-   see Section 1.2.7 for further discussion of this facility.
-
-   Failure to provide the precise set of features requested by the
-   caller does not cause context establishment to fail; it is the
-   caller's prerogative to delete the context if the feature set
-   provided is unsuitable for the caller's use.
-
-   The returned mech_type value indicates the specific mechanism
-   employed on the context, is valid only along with major_status
-   GSS_S_COMPLETE, and will never indicate the value for "default".
-   Note that, for the case of certain mechanisms which themselves
-   perform negotiation, the returned mech_type result may indicate
-   selection of a mechanism identified by an OID different than that
-   passed in the input mech_type argument.
-
-   The conf_avail return value indicates whether the context supports
-   per-message confidentiality services, and so informs the caller
-   whether or not a request for encryption through the conf_req_flag
-
-
-
-Linn                        Standards Track                    [Page 39]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   input to GSS_Wrap()  can be honored. In similar fashion, the
-   integ_avail return value indicates whether per-message integrity
-   services are available (through either GSS_GetMIC() or GSS_Wrap()) on
-   the established context. These state indicators' values are undefined
-   unless either the routine's major_status indicates GSS_S_COMPLETE, or
-   TRUE prot_ready_state is returned along with GSS_S_CONTINUE_NEEDED
-   major_status.
-
-   The lifetime_req input specifies a desired upper bound for the
-   lifetime of the context to be established, with a value of 0 used to
-   request a default lifetime. The lifetime_rec return value indicates
-   the length of time for which the context will be valid, expressed as
-   an offset from the present; depending on mechanism capabilities,
-   credential lifetimes, and local policy, it may not correspond to the
-   value requested in lifetime_req.  If no constraints on context
-   lifetime are imposed, this may be indicated by returning a reserved
-   value representing INDEFINITE lifetime_req. The value of lifetime_rec
-   is undefined unless the routine's major_status indicates
-   GSS_S_COMPLETE.
-
-   If the mutual_state is TRUE, this fact will be reflected within the
-   output_token. A call to GSS_Accept_sec_context()  at the target in
-   conjunction with such a context will return a token, to be processed
-   by a continuation call to GSS_Init_sec_context(),  in order to
-   achieve mutual authentication.
-
-2.2.2:  GSS_Accept_sec_context call
-
-   Inputs:
-
-   o  acceptor_cred_handle CREDENTIAL HANDLE, -- NULL specifies
-      "use default"
-
-   o  input_context_handle CONTEXT HANDLE, -- 0 specifies
-      "not yet assigned"
-
-   o  chan_bindings OCTET STRING,
-
-   o  input_token OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  src_name INTERNAL NAME, -- guaranteed to be MN
-
-
-
-
-Linn                        Standards Track                    [Page 40]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  mech_type OBJECT IDENTIFIER,
-
-   o  output_context_handle CONTEXT HANDLE,
-
-   o  deleg_state BOOLEAN,
-
-   o  mutual_state BOOLEAN,
-
-   o  replay_det_state BOOLEAN,
-
-   o  sequence_state BOOLEAN,
-
-   o  anon_state BOOLEAN,
-
-   o  trans_state BOOLEAN,
-
-   o  prot_ready_state BOOLEAN, -- see Section 1.2.7 for discussion
-
-   o  conf_avail BOOLEAN,
-
-   o  integ_avail BOOLEAN,
-
-   o  lifetime_rec INTEGER, - in seconds, or reserved value for
-      INDEFINITE
-
-   o  delegated_cred_handle CREDENTIAL HANDLE,
-
-   o  output_token OCTET STRING -NULL or token to pass to context
-      initiator
-
-   This call may block pending network interactions for those mech_types
-   in which a directory service or other network entity must be
-   consulted on behalf of a context acceptor in order to validate a
-   received input_token.
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that context-level data structures
-      were successfully initialized, and that per-message processing
-      can now be performed in conjunction with this context.
-
-   o  GSS_S_CONTINUE_NEEDED indicates that control information in the
-      returned output_token must be sent to the initiator, and that
-      a response must be received and passed as the input_token
-      argument to a continuation call to GSS_Accept_sec_context(),
-      before per-message processing can be performed in conjunction
-      with this context.
-
-
-
-
-Linn                        Standards Track                    [Page 41]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
-      on the input_token failed, preventing further processing from
-      being performed based on that token.
-
-   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks
-      performed on the credential structure referenced by
-      acceptor_cred_handle failed, preventing further processing from
-      being performed using that credential structure.
-
-   o  GSS_S_BAD_SIG indicates that the received input_token contains
-      an incorrect integrity check, so context setup cannot be
-      accomplished.
-
-   o  GSS_S_DUPLICATE_TOKEN indicates that the integrity check on the
-      received input_token was correct, but that the input_token
-      was recognized as a duplicate of an input_token already
-      processed. No new context is established.
-
-   o  GSS_S_OLD_TOKEN indicates that the integrity check on the received
-      input_token was correct, but that the input_token is too old
-      to be checked for duplication against previously-processed
-      input_tokens. No new context is established.
-
-   o  GSS_S_NO_CRED indicates that no context was established, either
-      because the input cred_handle was invalid, because the
-      referenced credentials are valid for context initiator use
-      only, or because the caller lacks authorization to access the
-      referenced credentials.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the credentials provided
-      through the input acceptor_cred_handle argument are no
-      longer valid, so context establishment cannot be completed.
-
-   o  GSS_S_BAD_BINDINGS indicates that a mismatch between the
-      caller-provided chan_bindings and those extracted from the
-      input_token was detected, signifying a security-relevant
-      event and preventing context establishment.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-      for the input context_handle provided; this major status will
-      be returned only for successor calls following GSS_S_CONTINUE_
-      NEEDED status returns.
-
-   o  GSS_S_BAD_MECH indicates receipt of a context establishment token
-      specifying a mechanism unsupported by the local system or with
-      the caller's active credentials.
-
-
-
-
-
-Linn                        Standards Track                    [Page 42]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_FAILURE indicates that context setup could not be
-      accomplished for reasons unspecified at the GSS-API level, and
-      that no interface-defined recovery action is available.
-
-   The GSS_Accept_sec_context()  routine is used by a context target.
-   Using information in the credentials structure referenced by the
-   input acceptor_cred_handle, it verifies the incoming input_token and
-   (following the successful completion of a context establishment
-   sequence) returns the authenticated src_name and the mech_type used.
-   The returned src_name is guaranteed to be an MN, processed by the
-   mechanism under which the context was established. The
-   acceptor_cred_handle must correspond to the same valid credentials
-   structure on the initial call to GSS_Accept_sec_context() and on any
-   successor calls resulting from GSS_S_CONTINUE_NEEDED status returns;
-   different protocol sequences modeled by the GSS_S_CONTINUE_NEEDED
-   mechanism will require access to credentials at different points in
-   the context establishment sequence.
-
-   The input_context_handle argument is 0, specifying "not yet
-   assigned", on the first GSS_Accept_sec_context()  call relating to a
-   given context.  If successful (i.e., if accompanied by major_status
-   GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and only if successful, the
-   initial GSS_Accept_sec_context() call returns a non-zero
-   output_context_handle for use in future references to this context.
-   Once a non-zero output_context_handle has been returned, GSS-API
-   callers should call GSS_Delete_sec_context() to release context-
-   related resources if errors occur in later phases of context
-   establishment, or when an established context is no longer required.
-
-   The chan_bindings argument is used by the caller to provide
-   information binding the security context to security-related
-   characteristics (e.g., addresses, cryptographic keys) of the
-   underlying communications channel. See Section 1.1.6 of this document
-   for more discussion of this argument's usage.
-
-   The returned state results (deleg_state, mutual_state,
-   replay_det_state, sequence_state, anon_state, trans_state, and
-   prot_ready_state) reflect the same information as described for
-   GSS_Init_sec_context(), and their values are significant under the
-   same return state conditions.
-
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 43]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   The conf_avail return value indicates whether the context supports
-   per-message confidentiality services, and so informs the caller
-   whether or not a request for encryption through the conf_req_flag
-   input to GSS_Wrap()  can be honored. In similar fashion, the
-   integ_avail return value indicates whether per-message integrity
-   services are available (through either GSS_GetMIC()  or GSS_Wrap())
-   on the established context.  These values are significant under the
-   same return state conditions as described under
-   GSS_Init_sec_context().
-
-   The lifetime_rec return value is significant only in conjunction with
-   GSS_S_COMPLETE major_status, and indicates the length of time for
-   which the context will be valid, expressed as an offset from the
-   present.
-
-   The mech_type return value indicates the specific mechanism employed
-   on the context, is valid only along with major_status GSS_S_COMPLETE,
-   and will never indicate the value for "default".
-
-   The delegated_cred_handle result is significant only when deleg_state
-   is TRUE, and provides a means for the target to reference the
-   delegated credentials. The output_token result, when non-NULL,
-   provides a context-level token to be returned to the context
-   initiator to continue a multi-step context establishment sequence. As
-   noted with GSS_Init_sec_context(),  any returned token should be
-   transferred to the context's peer (in this case, the context
-   initiator), independent of the value of the accompanying returned
-   major_status.
-
-   Note: A target must be able to distinguish a context-level
-   input_token, which is passed to GSS_Accept_sec_context(),  from the
-   per-message data elements passed to GSS_VerifyMIC()  or GSS_Unwrap().
-   These data elements may arrive in a single application message, and
-   GSS_Accept_sec_context()  must be performed before per-message
-   processing can be performed successfully.
-
-2.2.3: GSS_Delete_sec_context call
-
-   Input:
-
-   o  context_handle CONTEXT HANDLE
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-
-
-
-Linn                        Standards Track                    [Page 44]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  output_context_token OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the context was recognized, and that
-      relevant context-specific information was flushed.  If the caller
-      provides a non-null buffer to receive an output_context_token, and
-      the mechanism returns a non-NULL token into that buffer, the
-      returned output_context_token is ready for transfer to the
-      context's peer.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-      for the input context_handle provided, so no deletion was
-      performed.
-
-   o  GSS_S_FAILURE indicates that the context is recognized, but
-      that the GSS_Delete_sec_context()  operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   This call may block pending network interactions for mech_types in
-   which active notification must be made to a central server when a
-   security context is to be deleted.
-
-   This call can be made by either peer in a security context, to flush
-   context-specific information.  If a non-null output_context_token
-   parameter is provided by the caller, an output_context_token may be
-   returned to the caller.  If an output_context_token is provided to
-   the caller, it can be passed to the context's peer to inform the
-   peer's GSS-API implementation that the peer's corresponding context
-   information can also be flushed. (Once a context is established, the
-   peers involved are expected to retain cached credential and context-
-   related information until the information's expiration time is
-   reached or until a GSS_Delete_sec_context() call is made.)
-
-   The facility for context_token usage to signal context deletion is
-   retained for compatibility with GSS-API Version 1.  For current
-   usage, it is recommended that both peers to a context invoke
-   GSS_Delete_sec_context() independently, passing a null
-   output_context_token buffer to indicate that no context_token is
-   required.  Implementations of GSS_Delete_sec_context() should delete
-   relevant locally-stored context information.
-
-   Attempts to perform per-message processing on a deleted context will
-   result in error returns.
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 45]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-2.2.4:  GSS_Process_context_token call
-
-   Inputs:
-
-   o  context_handle CONTEXT HANDLE,
-
-   o  input_context_token OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the input_context_token was
-      successfully processed in conjunction with the context
-      referenced by context_handle.
-
-   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks
-      performed on the received context_token failed, preventing
-      further processing from being performed with that token.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-      for the input context_handle provided.
-
-   o  GSS_S_FAILURE indicates that the context is recognized, but
-      that the GSS_Process_context_token()  operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   This call is used to process context_tokens received from a peer once
-   a context has been established, with corresponding impact on
-   context-level state information. One use for this facility is
-   processing of the context_tokens generated by
-   GSS_Delete_sec_context();  GSS_Process_context_token() will not block
-   pending network interactions for that purpose. Another use is to
-   process tokens indicating remote-peer context establishment failures
-   after the point where the local GSS-API implementation has already
-   indicated GSS_S_COMPLETE status.
-
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 46]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-2.2.5:  GSS_Context_time call
-
-   Input:
-
-   o  context_handle CONTEXT HANDLE,
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  lifetime_rec INTEGER - in seconds, or reserved value for
-      INDEFINITE
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the referenced context is valid,
-      and will remain valid for the amount of time indicated in
-      lifetime_rec.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that data items related to the
-      referenced context have expired.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the context is
-      recognized, but that its associated credentials have expired.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-      for the input context_handle provided.
-
-   o  GSS_S_FAILURE indicates that the requested operation failed for
-       reasons unspecified at the GSS-API level.
-
-   This call is used to determine the amount of time for which a
-   currently established context will remain valid.
-
-2.2.6:   GSS_Inquire_context call
-
-   Input:
-
-   o  context_handle CONTEXT HANDLE,
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-
-
-
-Linn                        Standards Track                    [Page 47]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  src_name INTERNAL NAME,  -- name of context initiator,
-                               -- guaranteed to be MN
-
-   o  targ_name INTERNAL NAME,  -- name of context target,
-                                -- guaranteed to be MN
-
-
-   o  lifetime_rec INTEGER -- in seconds, or reserved value for
-      INDEFINITE,
-
-   o  mech_type OBJECT IDENTIFIER, -- the mechanism supporting this
-      security context
-
-   o  deleg_state BOOLEAN,
-
-   o  mutual_state BOOLEAN,
-
-   o  replay_det_state BOOLEAN,
-
-   o  sequence_state BOOLEAN,
-
-   o  anon_state BOOLEAN,
-
-   o  trans_state BOOLEAN,
-
-   o  prot_ready_state BOOLEAN,
-
-   o  conf_avail BOOLEAN,
-
-   o  integ_avail BOOLEAN,
-
-   o  locally_initiated BOOLEAN, -- TRUE if initiator, FALSE if acceptor
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the referenced context is valid
-      and that src_name, targ_name, lifetime_rec, mech_type, deleg_state,
-      mutual_state, replay_det_state, sequence_state, anon_state,
-      trans_state, prot_ready_state, conf_avail, integ_avail, and
-      locally_initiated return values describe the corresponding
-      characteristics of the context.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that the provided input
-      context_handle is recognized, but that the referenced context
-      has expired.  Return values other than major_status and
-      minor_status are undefined.
-
-
-
-
-
-Linn                        Standards Track                    [Page 48]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-      for the input context_handle provided. Return values other than
-      major_status and minor_status are undefined.
-
-   o  GSS_S_FAILURE indicates that the requested operation failed for
-     reasons unspecified at the GSS-API level. Return values other than
-         major_status and minor_status are undefined.
-
-   This call is used to extract information describing characteristics
-   of a security context.
-
-2.2.7:   GSS_Wrap_size_limit call
-
-   Inputs:
-
-   o  context_handle CONTEXT HANDLE,
-
-   o  qop INTEGER,
-
-   o  output_size INTEGER
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  max_input_size INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates a successful token size determination:
-   an input message with a length in octets equal to the
-   returned max_input_size value will, when passed to GSS_Wrap()
-   for processing on the context identified by the context_handle
-   parameter and with the quality of protection specifier provided
-   in the qop parameter, yield an output token no larger than the
-   value of the provided output_size parameter.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that the provided input
-   context_handle is recognized, but that the referenced context
-   has expired.  Return values other than major_status and
-   minor_status are undefined.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-   for the input context_handle provided. Return values other than
-   major_status and minor_status are undefined.
-
-
-
-
-Linn                        Standards Track                    [Page 49]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_BAD_QOP indicates that the provided QOP value is not
-   recognized or supported for the context.
-
-   o  GSS_S_FAILURE indicates that the requested operation failed for
-   reasons unspecified at the GSS-API level. Return values other than
-   major_status and minor_status are undefined.
-
-   This call is used to determine the largest input datum which may be
-   passed to GSS_Wrap() without yielding an output token larger than a
-   caller-specified value.
-
-2.2.8:   GSS_Export_sec_context call
-
-   Inputs:
-
-   o  context_handle CONTEXT HANDLE
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  interprocess_token OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the referenced context has been
-   successfully exported to a representation in the interprocess_token,
-   and is no longer available for use by the caller.
-
-   o  GSS_S_UNAVAILABLE indicates that the context export facility
-   is not available for use on the referenced context.  (This status
-   should occur only for contexts for which the trans_state value is
-   FALSE.) Return values other than major_status and minor_status are
-   undefined.
-
-   o GSS_S_CONTEXT_EXPIRED indicates that the provided input
-   context_handle is recognized, but that the referenced context has
-   expired.  Return values other than major_status and minor_status are
-   undefined.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-   for the input context_handle provided. Return values other than
-   major_status and minor_status are undefined.
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 50]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_FAILURE indicates that the requested operation failed for
-   reasons unspecified at the GSS-API level. Return values other than
-   major_status and minor_status are undefined.
-
-   This call generates an interprocess token for transfer to another
-   process within an end system, in order to transfer control of a
-   security context to that process.  The recipient of the interprocess
-   token will call GSS_Import_sec_context() to accept the transfer.  The
-   GSS_Export_sec_context() operation is defined for use only with
-   security contexts which are fully and successfully established (i.e.,
-   those for which GSS_Init_sec_context() and GSS_Accept_sec_context()
-   have returned GSS_S_COMPLETE major_status).
-
-   To ensure portability, a caller of GSS_Export_sec_context() must not
-   assume that a context may continue to be used once it has been
-   exported; following export, the context referenced by the
-   context_handle cannot be assumed to remain valid.  Further, portable
-   callers must not assume that a given interprocess token can be
-   imported by GSS_Import_sec_context() more than once, thereby creating
-   multiple instantiations of a single context.  GSS-API implementations
-   may detect and reject attempted multiple imports, but are not
-   required to do so.
-
-   The internal representation contained within the interprocess token
-   is an implementation-defined local matter.  Interprocess tokens
-   cannot be assumed to be transferable across different GSS-API
-   implementations.
-
-   It is recommended that GSS-API implementations adopt policies suited
-   to their operational environments in order to define the set of
-   processes eligible to import a context, but specific constraints in
-   this area are local matters.  Candidate examples include transfers
-   between processes operating on behalf of the same user identity, or
-   processes comprising a common job.  However, it may be impossible to
-   enforce such policies in some implementations.
-
-   In support of the above goals, implementations may protect the
-   transferred context data by using cryptography to protect data within
-   the interprocess token, or by using interprocess tokens as a means to
-   reference local interprocess communication facilities (protected by
-   other means) rather than storing the context data directly within the
-   tokens.
-
-   Transfer of an open context may, for certain mechanisms and
-   implementations, reveal data about the credential which was used to
-   establish the context.  Callers should, therefore, be cautious about
-   the trustworthiness of processes to which they transfer contexts.
-   Although the GSS-API implementation may provide its own set of
-
-
-
-Linn                        Standards Track                    [Page 51]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   protections over the exported context, the caller is responsible for
-   protecting the interprocess token from disclosure, and for taking
-   care that the context is transferred to an appropriate destination
-   process.
-
-2.2.9:   GSS_Import_sec_context call
-
-   Inputs:
-
-   o  interprocess_token OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  context_handle CONTEXT HANDLE
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the context represented by the
-   input interprocess_token has been successfully transferred to
-   the caller, and is available for future use via the output
-   context_handle.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that the context represented by
-   the input interprocess_token has expired. Return values other
-   than major_status and minor_status are undefined.
-
-   o  GSS_S_NO_CONTEXT indicates that the context represented by the
-   input interprocess_token was invalid. Return values other than
-   major_status and minor_status are undefined.
-
-   o  GSS_S_DEFECTIVE_TOKEN indicates that the input interprocess_token
-   was defective.  Return values other than major_status and
-   minor_status are undefined.
-
-   o  GSS_S_UNAVAILABLE indicates that the context import facility
-   is not available for use on the referenced context.  Return values
-   other than major_status and minor_status are undefined.
-
-   o  GSS_S_UNAUTHORIZED indicates that the context represented by
-   the input interprocess_token is unauthorized for transfer to the
-   caller. Return values other than major_status and minor_status
-   are undefined.
-
-
-
-
-
-Linn                        Standards Track                    [Page 52]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_FAILURE indicates that the requested operation failed for
-   reasons unspecified at the GSS-API level. Return values other than
-   major_status and minor_status are undefined.
-
-   This call processes an interprocess token generated by
-   GSS_Export_sec_context(), making the transferred context available
-   for use by the caller.  After a successful GSS_Import_sec_context()
-   operation, the imported context is available for use by the importing
-   process.
-
-   For further discussion of the security and authorization issues
-   regarding this call, please see the discussion in Section 2.2.8.
-
-2.3:  Per-message calls
-
-   This group of calls is used to perform per-message protection
-   processing on an established security context. None of these calls
-   block pending network interactions. These calls may be invoked by a
-   context's initiator or by the context's target.  The four members of
-   this group should be considered as two pairs; the output from
-   GSS_GetMIC()  is properly input to GSS_VerifyMIC(),  and the output
-   from GSS_Wrap() is properly input to GSS_Unwrap().
-
-   GSS_GetMIC() and GSS_VerifyMIC() support data origin authentication
-   and data integrity services. When GSS_GetMIC()  is invoked on an
-   input message, it yields a per-message token containing data items
-   which allow underlying mechanisms to provide the specified security
-   services. The original message, along with the generated per-message
-   token, is passed to the remote peer; these two data elements are
-   processed by GSS_VerifyMIC(),  which validates the message in
-   conjunction with the separate token.
-
-   GSS_Wrap() and GSS_Unwrap() support caller-requested confidentiality
-   in addition to the data origin authentication and data integrity
-   services offered by GSS_GetMIC()  and GSS_VerifyMIC(). GSS_Wrap()
-   outputs a single data element, encapsulating optionally enciphered
-   user data as well as associated token data items.  The data element
-   output from GSS_Wrap()  is passed to the remote peer and processed by
-   GSS_Unwrap()  at that system. GSS_Unwrap() combines decipherment (as
-   required) with validation of data items related to authentication and
-   integrity.
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 53]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-2.3.1:  GSS_GetMIC call
-
-   Note: This call is functionally equivalent to the GSS_Sign call as
-   defined in previous versions of this specification. In the interests
-   of backward compatibility, it is recommended that implementations
-   support this function under both names for the present; future
-   references to this function as GSS_Sign are deprecated.
-
-   Inputs:
-
-   o  context_handle CONTEXT HANDLE,
-
-   o  qop_req INTEGER,-0 specifies default QOP
-
-   o  message OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  per_msg_token OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that an integrity check, suitable for an
-      established security context, was successfully applied and
-      that the message and corresponding per_msg_token are ready
-      for transmission.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data
-      items have expired, so that the requested operation cannot be
-      performed.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the context is recognized,
-      but that its associated credentials have expired, so
-      that the requested operation cannot be performed.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-      for the input context_handle provided.
-
-   o  GSS_S_BAD_QOP indicates that the provided QOP value is not
-      recognized or supported for the context.
-
-   o  GSS_S_FAILURE indicates that the context is recognized, but
-      that the requested operation could not be performed for
-      reasons unspecified at the GSS-API level.
-
-
-
-Linn                        Standards Track                    [Page 54]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   Using the security context referenced by context_handle, apply an
-   integrity check to the input message (along with timestamps and/or
-   other data included in support of mech_type-specific mechanisms) and
-   return the result in per_msg_token. The qop_req parameter,
-   interpretation of which is discussed in Section 1.2.4, allows
-   quality-of-protection control. The caller passes the message and the
-   per_msg_token to the target.
-
-   The GSS_GetMIC()  function completes before the message and
-   per_msg_token is sent to the peer; successful application of
-   GSS_GetMIC()  does not guarantee that a corresponding GSS_VerifyMIC()
-   has been (or can necessarily be) performed successfully when the
-   message arrives at the destination.
-
-   Mechanisms which do not support per-message protection services
-   should return GSS_S_FAILURE if this routine is called.
-
-2.3.2:  GSS_VerifyMIC call
-
-   Note: This call is functionally equivalent to the GSS_Verify call as
-   defined in previous versions of this specification. In the interests
-   of backward compatibility, it is recommended that implementations
-   support this function under both names for the present; future
-   references to this function as GSS_Verify are deprecated.
-
-   Inputs:
-
-   o  context_handle CONTEXT HANDLE,
-
-   o  message OCTET STRING,
-
-   o  per_msg_token OCTET STRING
-
-   Outputs:
-
-   o  qop_state INTEGER,
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the message was successfully
-      verified.
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 55]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
-      on the received per_msg_token failed, preventing
-      further processing from being performed with that token.
-
-   o  GSS_S_BAD_SIG indicates that the received per_msg_token contains
-      an incorrect integrity check for the message.
-
-   o  GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN,
-      and GSS_S_GAP_TOKEN values appear in conjunction with the
-      optional per-message replay detection features described
-      in Section 1.2.3; their semantics are described in that section.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data
-      items have expired, so that the requested operation cannot be
-      performed.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the context is
-   recognized,
-      but that its associated credentials have expired, so
-      that the requested operation cannot be performed.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-      for the input context_handle provided.
-
-   o  GSS_S_FAILURE indicates that the context is recognized, but
-      that the GSS_VerifyMIC() operation could not be performed for
-      reasons unspecified at the GSS-API level.
-
-   Using the security context referenced by context_handle, verify that
-   the input per_msg_token contains an appropriate integrity check for
-   the input message, and apply any active replay detection or
-   sequencing features. Return an indication of the quality-of-
-   protection applied to the processed message in the qop_state result.
-   Since the GSS_VerifyMIC() routine never provides a confidentiality
-   service, its implementations should not return non-zero values in the
-   confidentiality fields of the output qop_state.
-
-   Mechanisms which do not support per-message protection services
-   should return GSS_S_FAILURE if this routine is called.
-
-2.3.3: GSS_Wrap call
-
-   Note: This call is functionally equivalent to the GSS_Seal call as
-   defined in previous versions of this specification. In the interests
-   of backward compatibility, it is recommended that implementations
-   support this function under both names for the present; future
-   references to this function as GSS_Seal are deprecated.
-
-
-
-
-Linn                        Standards Track                    [Page 56]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   Inputs:
-
-   o  context_handle CONTEXT HANDLE,
-
-   o  conf_req_flag BOOLEAN,
-
-   o  qop_req INTEGER,-0 specifies default QOP
-
-   o  input_message OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  conf_state BOOLEAN,
-
-   o  output_message OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the input_message was successfully
-      processed and that the output_message is ready for
-      transmission.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data
-      items have expired, so that the requested operation cannot be
-      performed.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the context is
-   recognized,
-      but that its associated credentials have expired, so
-      that the requested operation cannot be performed.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-      for the input context_handle provided.
-
-   o  GSS_S_BAD_QOP indicates that the provided QOP value is not
-      recognized or supported for the context.
-
-   o  GSS_S_FAILURE indicates that the context is recognized, but
-      that the GSS_Wrap()  operation could not be performed for
-      reasons unspecified at the GSS-API level.
-
-   Performs the data origin authentication and data integrity functions
-   of GSS_GetMIC().  If the input conf_req_flag is TRUE, requests that
-   confidentiality be applied to the input_message.  Confidentiality may
-
-
-
-Linn                        Standards Track                    [Page 57]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   not be supported in all mech_types or by all implementations; the
-   returned conf_state flag indicates whether confidentiality was
-   provided for the input_message. The qop_req parameter, interpretation
-   of which is discussed in Section 1.2.4, allows quality-of-protection
-   control.
-
-   In all cases, the GSS_Wrap()  call yields a single output_message
-   data element containing (optionally enciphered) user data as well as
-   control information.
-
-   Mechanisms which do not support per-message protection services
-   should return GSS_S_FAILURE if this routine is called.
-
-2.3.4: GSS_Unwrap call
-
-   Note: This call is functionally equivalent to the GSS_Unseal call as
-   defined in previous versions of this specification. In the interests
-   of backward compatibility, it is recommended that implementations
-   support this function under both names for the present; future
-   references to this function as GSS_Unseal are deprecated.
-
-   Inputs:
-
-   o  context_handle CONTEXT HANDLE,
-
-   o  input_message OCTET STRING
-
-   Outputs:
-
-   o  conf_state BOOLEAN,
-
-   o  qop_state INTEGER,
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_message OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the input_message was
-      successfully processed and that the resulting output_message is
-      available.
-
-   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
-      on the per_msg_token extracted from the input_message
-      failed, preventing further processing from being performed.
-
-
-
-Linn                        Standards Track                    [Page 58]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_BAD_SIG indicates that an incorrect integrity check was
-   detected
-      for the message.
-
-   o  GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN,
-      and GSS_S_GAP_TOKEN values appear in conjunction with the
-      optional per-message replay detection features described
-      in Section 1.2.3; their semantics are described in that section.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data
-      items have expired, so that the requested operation cannot be
-      performed.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the context is
-   recognized,
-      but that its associated credentials have expired, so
-      that the requested operation cannot be performed.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-      for the input context_handle provided.
-
-   o  GSS_S_FAILURE indicates that the context is recognized, but
-      that the GSS_Unwrap()  operation could not be performed for
-      reasons unspecified at the GSS-API level.
-
-   Processes a data element generated (and optionally enciphered) by
-   GSS_Wrap(),  provided as input_message. The returned conf_state value
-   indicates whether confidentiality was applied to the input_message.
-   If conf_state is TRUE, GSS_Unwrap()  deciphers the input_message.
-   Returns an indication of the quality-of-protection applied to the
-   processed message in the qop_state result. GSS_Wrap()  performs the
-   data integrity and data origin authentication checking functions of
-   GSS_VerifyMIC()  on the plaintext data. Plaintext data is returned in
-   output_message.
-
-   Mechanisms which do not support per-message protection services
-   should return GSS_S_FAILURE if this routine is called.
-
-2.4:  Support calls
-
-   This group of calls provides support functions useful to GSS-API
-   callers, independent of the state of established contexts. Their
-   characterization with regard to blocking or non-blocking status in
-   terms of network interactions is unspecified.
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 59]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-2.4.1:  GSS_Display_status call
-
-   Inputs:
-
-   o  status_value INTEGER,-GSS-API major_status or minor_status
-      return value
-
-   o  status_type INTEGER,-1 if major_status, 2 if minor_status
-
-   o  mech_type OBJECT IDENTIFIER-mech_type to be used for minor_
-      status translation
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  status_string_set SET OF OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that a valid printable status
-      representation (possibly representing more than one status event
-      encoded within the status_value) is available in the returned
-      status_string_set.
-
-   o  GSS_S_BAD_MECH indicates that translation in accordance with an
-      unsupported mech_type was requested, so translation could not
-      be performed.
-
-   o  GSS_S_BAD_STATUS indicates that the input status_value was
-      invalid, or that the input status_type carried a value other
-      than 1 or 2, so translation could not be performed.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not
-      be performed for reasons unspecified at the GSS-API level.
-
-   Provides a means for callers to translate GSS-API-returned major and
-   minor status codes into printable string representations.
-
-2.4.2:  GSS_Indicate_mechs call
-
-   Input:
-
-   o  (none)
-
-
-
-
-
-Linn                        Standards Track                    [Page 60]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  mech_set SET OF OBJECT IDENTIFIER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that a set of available mechanisms has
-      been returned in mech_set.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not
-      be performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to determine the set of mechanism types available on
-   the local system. This call is intended for support of specialized
-   callers who need to request non-default mech_type sets from
-   GSS_Acquire_cred(),  and should not be needed by other callers.
-
-2.4.3:  GSS_Compare_name call
-
-   Inputs:
-
-   o  name1 INTERNAL NAME,
-
-   o  name2 INTERNAL NAME
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  name_equal BOOLEAN
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that name1 and name2 were comparable,
-      and that the name_equal result indicates whether name1 and
-      name2 represent the same entity.
-
-   o  GSS_S_BAD_NAMETYPE indicates that one or both of name1 and
-      name2 contained internal type specifiers uninterpretable
-      by the applicable underlying GSS-API mechanism(s), or that
-      the two names' types are different and incomparable, so that
-      the comparison operation could not be completed.
-
-
-
-Linn                        Standards Track                    [Page 61]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_BAD_NAME indicates that one or both of the input names
-      was ill-formed in terms of its internal type specifier, so
-      the comparison operation could not be completed.
-
-   o  GSS_S_FAILURE indicates that the call's operation could not
-      be performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to compare two internal name representations to
-   determine whether they refer to the same entity.  If either name
-   presented to GSS_Compare_name() denotes an anonymous principal,
-   GSS_Compare_name() shall indicate FALSE.  It is not required that
-   either or both inputs name1 and name2 be MNs; for some
-   implementations and cases, GSS_S_BAD_NAMETYPE may be returned,
-   indicating name incomparability, for the case where neither input
-   name is an MN.
-
-2.4.4:  GSS_Display_name call
-
-   Inputs:
-
-   o  name INTERNAL NAME
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  name_string OCTET STRING,
-
-   o  name_type OBJECT IDENTIFIER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that a valid printable name
-      representation is available in the returned name_string.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the provided name was of a
-      type uninterpretable by the applicable underlying GSS-API
-      mechanism(s), so no printable representation could be generated.
-
-   o  GSS_S_BAD_NAME indicates that the contents of the provided name
-      were inconsistent with the internally-indicated name type, so
-      no printable representation could be generated.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not
-      be performed for reasons unspecified at the GSS-API level.
-
-
-
-
-Linn                        Standards Track                    [Page 62]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   Allows callers to translate an internal name representation into a
-   printable form with associated namespace type descriptor. The syntax
-   of the printable form is a local matter.
-
-   If the input name represents an anonymous identity, a reserved value
-   (GSS_C_NT_ANONYMOUS) shall be returned for name_type.
-
-2.4.5:  GSS_Import_name call
-
-   Inputs:
-
-   o  input_name_string OCTET STRING,
-
-   o  input_name_type OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_name INTERNAL NAME
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that a valid name representation is
-      output in output_name and described by the type value in
-      output_name_type.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the input_name_type is unsupported
-      by the applicable underlying GSS-API mechanism(s), so the import
-      operation could not be completed.
-
-   o  GSS_S_BAD_NAME indicates that the provided input_name_string
-      is ill-formed in terms of the input_name_type, so the import
-      operation could not be completed.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not
-      be performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to provide a name representation as a contiguous octet
-   string, designate the type of namespace in conjunction with which it
-   should be parsed, and convert that representation to an internal form
-   suitable for input to other GSS-API routines.  The syntax of the
-   input_name_string is defined in conjunction with its associated name
-   type; depending on the input_name_type, the associated
-   input_name_string may or may not be a printable string. Note: The
-   input_name_type argument serves to describe and qualify the
-
-
-
-Linn                        Standards Track                    [Page 63]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   interpretation of the associated input_name_string; it does not
-   specify the data type of the returned output_name.
-
-   If a mechanism claims support for a particular name type, its
-   GSS_Import_name() operation shall be able to accept all possible
-   values conformant to the external name syntax as defined for that
-   name type.  These imported values may correspond to:
-
-      (1) locally registered entities (for which credentials may be
-      acquired),
-
-      (2) non-local entities (for which local credentials cannot be
-      acquired, but which may be referenced as targets of initiated
-      security contexts or initiators of accepted security contexts), or
-      to
-
-      (3) neither of the above.
-
-   Determination of whether a particular name belongs to class (1), (2),
-   or (3) as described above is not guaranteed to be performed by the
-   GSS_Import_name() function.
-
-   The internal name generated by a GSS_Import_name() operation may be a
-   single-mechanism MN, and is likely to be an MN within a single-
-   mechanism implementation, but portable callers must not depend on
-   this property (and must not, therefore, assume that the output from
-   GSS_Import_name() can be passed directly to GSS_Export_name() without
-   first being processed through GSS_Canonicalize_name()).
-
-2.4.6: GSS_Release_name call
-
-   Inputs:
-
-   o  name INTERNAL NAME
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the storage associated with the
-      input name was successfully released.
-
-   o  GSS_S_BAD_NAME indicates that the input name argument did not
-      contain a valid name.
-
-
-
-Linn                        Standards Track                    [Page 64]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_FAILURE indicates that the requested operation could not
-      be performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to release the storage associated with an internal
-   name representation.  This call's specific behavior depends on the
-   language and programming environment within which a GSS-API
-   implementation operates, and is therefore detailed within applicable
-   bindings specifications; in particular, this call may be superfluous
-   within bindings where memory management is automatic.
-
-2.4.7: GSS_Release_buffer call
-
-   Inputs:
-
-   o  buffer OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the storage associated with the
-      input buffer was successfully released.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not
-      be performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to release the storage associated with an OCTET STRING
-   buffer allocated by another GSS-API call.  This call's specific
-   behavior depends on the language and programming environment within
-   which a GSS-API implementation operates, and is therefore detailed
-   within applicable bindings specifications; in particular, this call
-   may be superfluous within bindings where memory management is
-   automatic.
-
-2.4.8: GSS_Release_OID_set call
-
-   Inputs:
-
-   o  buffer SET OF OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-
-
-
-Linn                        Standards Track                    [Page 65]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the storage associated with the
-      input object identifier set was successfully released.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not
-      be performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to release the storage associated with an object
-   identifier set object allocated by another GSS-API call.  This call's
-   specific behavior depends on the language and programming environment
-   within which a GSS-API implementation operates, and is therefore
-   detailed within applicable bindings specifications; in particular,
-   this call may be superfluous within bindings where memory management
-   is automatic.
-
-2.4.9: GSS_Create_empty_OID_set call
-
-   Inputs:
-
-   o  (none)
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  oid_set SET OF OBJECT IDENTIFIER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates successful completion
-
-   o  GSS_S_FAILURE indicates that the operation failed
-
-   Creates an object identifier set containing no object identifiers, to
-   which members may be subsequently added using the
-   GSS_Add_OID_set_member() routine.  These routines are intended to be
-   used to construct sets of mechanism object identifiers, for input to
-   GSS_Acquire_cred().
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 66]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-2.4.10: GSS_Add_OID_set_member call
-
-   Inputs:
-
-   o  member_oid OBJECT IDENTIFIER,
-
-   o  oid_set SET OF OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates successful completion
-
-   o  GSS_S_FAILURE indicates that the operation failed
-
-   Adds an Object Identifier to an Object Identifier set.  This routine
-   is intended for use in conjunction with GSS_Create_empty_OID_set()
-   when constructing a set of mechanism OIDs for input to
-   GSS_Acquire_cred().
-
-2.4.11: GSS_Test_OID_set_member call
-
-   Inputs:
-
-   o  member OBJECT IDENTIFIER,
-
-   o  set SET OF OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  present BOOLEAN
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates successful completion
-
-   o  GSS_S_FAILURE indicates that the operation failed
-
-
-
-
-
-Linn                        Standards Track                    [Page 67]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   Interrogates an Object Identifier set to determine whether a
-   specified Object Identifier is a member.  This routine is intended to
-   be used with OID sets returned by GSS_Indicate_mechs(),
-   GSS_Acquire_cred(), and GSS_Inquire_cred().
-
-2.4.12: GSS_Release_OID call
-
-   Inputs:
-
-   o  oid OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates successful completion
-
-   o  GSS_S_FAILURE indicates that the operation failed
-
-   Allows the caller to release the storage associated with an OBJECT
-   IDENTIFIER buffer allocated by another GSS-API call. This call's
-   specific behavior depends on the language and programming environment
-   within which a GSS-API implementation operates, and is therefore
-   detailed within applicable bindings specifications; in particular,
-   this call may be superfluous within bindings where memory management
-   is automatic.
-
-2.4.13: GSS_OID_to_str call
-
-   Inputs:
-
-   o  oid OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  oid_str OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates successful completion
-
-
-
-Linn                        Standards Track                    [Page 68]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  GSS_S_FAILURE indicates that the operation failed
-
-   The function GSS_OID_to_str() returns a string representing the input
-   OID in numeric ASN.1 syntax format (curly-brace enclosed, space-
-   delimited, e.g., "{2 16 840 1 113687 1 2 1}"). The string is
-   releasable using GSS_Release_buffer(). If the input "oid" does not
-   represent a syntactically valid object identifier, GSS_S_FAILURE
-   status is returned and the returned oid_str result is NULL.
-
-2.4.14: GSS_Str_to_OID call
-
-   Inputs:
-
-   o  oid_str OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  oid OBJECT IDENTIFIER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates successful completion
-
-   o  GSS_S_FAILURE indicates that the operation failed
-
-   The function GSS_Str_to_OID() constructs and returns an OID from its
-   printable form; implementations should be able to accept the numeric
-   ASN.1 syntax form as described for GSS_OID_to_str(), and this form
-   should be used for portability, but implementations of this routine
-   may also accept other formats (e.g., "1.2.3.3"). The OID is suitable
-   for release using the function GSS_Release_OID(). If the input
-   oid_str cannot be translated into an OID, GSS_S_FAILURE status is
-   returned and the "oid" result is NULL.
-
-2.4.15:  GSS_Inquire_names_for_mech call
-
-   Input:
-
-   o  input_mech_type OBJECT IDENTIFIER, -- mechanism type
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-
-
-
-Linn                        Standards Track                    [Page 69]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   o  minor_status INTEGER,
-
-   o  name_type_set SET OF OBJECT IDENTIFIER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the output name_type_set contains
-      a list of name types which are supported by the locally available
-      mechanism identified by input_mech_type.
-
-   o  GSS_S_BAD_MECH indicates that the mechanism identified by
-      input_mech_type was unsupported within the local implementation,
-      causing the query to fail.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not
-      be performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to determine the set of name types which are
-   supportable by a specific locally-available mechanism.
-
-2.4.16: GSS_Inquire_mechs_for_name call
-
-   Inputs:
-
-   o  input_name INTERNAL NAME,
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  mech_types SET OF OBJECT IDENTIFIER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that a set of object identifiers,
-      corresponding to the set of mechanisms suitable for processing
-      the input_name, is available in mech_types.
-
-   o  GSS_S_BAD_NAME indicates that the input_name could not be
-      processed.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the type of the input_name
-      is unsupported by the GSS-API implementation.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not
-      be performed for reasons unspecified at the GSS-API level.
-
-
-
-Linn                        Standards Track                    [Page 70]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   This routine returns the mechanism set with which the input_name may
-   be processed.  After use, the mech_types object should be freed by
-   the caller via the GSS_Release_OID_set() call.  Note: it is
-   anticipated that implementations of GSS_Inquire_mechs_for_name() will
-   commonly operate based on type information describing the
-   capabilities of available mechanisms; it is not guaranteed that all
-   identified mechanisms will necessarily be able to canonicalize (via
-   GSS_Canonicalize_name()) a particular name.
-
-2.4.17: GSS_Canonicalize_name call
-
-   Inputs:
-
-   o  input_name INTERNAL NAME,
-
-   o  mech_type OBJECT IDENTIFIER  -- must be explicit mechanism,
-                                      not "default" specifier
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_name INTERNAL NAME
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that a mechanism-specific reduction of
-      the input_name, as processed by the mechanism identified by
-      mech_type, is available in output_name.
-
-   o  GSS_S_BAD_MECH indicates that the identified mechanism is
-      unsupported.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the input name does not
-      contain an element with suitable type for processing by the
-      identified mechanism.
-
-   o  GSS_S_BAD_NAME indicates that the input name contains an
-      element with suitable type for processing by the identified
-      mechanism, but that this element could not be processed
-      successfully.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not
-      be performed for reasons unspecified at the GSS-API level.
-
-
-
-
-
-Linn                        Standards Track                    [Page 71]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   This routine reduces a GSS-API internal name, which may in general
-   contain elements corresponding to multiple mechanisms, to a
-   mechanism-specific Mechanism Name (MN) by applying the translations
-   corresponding to the mechanism identified by mech_type.
-
-2.4.18: GSS_Export_name call
-
-   Inputs:
-
-   o  input_name INTERNAL NAME, -- required to be MN
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_name OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that a flat representation of the
-      input name is available in output_name.
-
-   o  GSS_S_NAME_NOT_MN indicates that the input name contained
-      elements corresponding to multiple mechanisms, so cannot
-      be exported into a single-mechanism flat form.
-
-   o  GSS_S_BAD_NAME indicates that the input name was an MN,
-      but could not be processed.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the input name was an MN,
-      but that its type is unsupported by the GSS-API implementation.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not
-      be performed for reasons unspecified at the GSS-API level.
-
-   This routine creates a flat name representation, suitable for
-   bytewise comparison or for input to GSS_Import_name() in conjunction
-   with the reserved GSS-API Exported Name Object OID, from a internal-
-   form Mechanism Name (MN) as emitted, e.g., by GSS_Canonicalize_name()
-   or GSS_Accept_sec_context().
-
-   The emitted GSS-API Exported Name Object is self-describing; no
-   associated parameter-level OID need be emitted by this call.  This
-   flat representation consists of a mechanism-independent wrapper
-   layer, defined in Section 3.2 of this document, enclosing a
-   mechanism-defined name representation.
-
-
-
-Linn                        Standards Track                    [Page 72]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   In all cases, the flat name output by GSS_Export_name() to correspond
-   to a particular input MN must be invariant over time within a
-   particular installation.
-
-   The GSS_S_NAME_NOT_MN status code is provided to enable
-   implementations to reject input names which are not MNs.  It is not,
-   however, required for purposes of conformance to this specification
-   that all non-MN input names must necessarily be rejected.
-
-2.4.19: GSS_Duplicate_name call
-
-   Inputs:
-
-   o  src_name INTERNAL NAME
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  dest_name INTERNAL NAME
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that dest_name references an internal
-      name object containing the same name as passed to src_name.
-
-   o  GSS_S_BAD_NAME indicates that the input name was invalid.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the input name's type
-      is unsupported by the GSS-API implementation.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not
-      be performed for reasons unspecified at the GSS-API level.
-
-   This routine takes input internal name src_name, and returns another
-   reference (dest_name) to that name which can be used even if src_name
-   is later freed.  (Note: This may be implemented by copying or through
-   use of reference counts.)
-
-3: Data Structure Definitions for GSS-V2 Usage
-
-   Subsections of this section define, for interoperability and
-   portability purposes, certain data structures for use with GSS-V2.
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 73]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-3.1: Mechanism-Independent Token Format
-
-   This section specifies a mechanism-independent level of encapsulating
-   representation for the initial token of a GSS-API context
-   establishment sequence, incorporating an identifier of the mechanism
-   type to be used on that context and enabling tokens to be interpreted
-   unambiguously at GSS-API peers. Use of this format is required for
-   initial context establishment tokens of Internet standards-track
-   GSS-API mechanisms; use in non-initial tokens is optional.
-
-   The encoding format for the token tag is derived from ASN.1 and DER
-   (per illustrative ASN.1 syntax included later within this
-   subsection), but its concrete representation is defined directly in
-   terms of octets rather than at the ASN.1 level in order to facilitate
-   interoperable implementation without use of general ASN.1 processing
-   code.  The token tag consists of the following elements, in order:
-
-      1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that
-      constructed form, definite length encoding follows.
-
-      2. Token length octets, specifying length of subsequent data
-      (i.e., the summed lengths of elements 3-5 in this list, and of the
-      mechanism-defined token object following the tag).  This element
-      comprises a variable number of octets:
-
-      2a. If the indicated value is less than 128, it shall be
-      represented in a single octet with bit 8 (high order) set to "0"
-      and the remaining bits representing the value.
-
-      2b. If the indicated value is 128 or more, it shall be represented
-      in two or more octets, with bit 8 of the first octet set to "1"
-      and the remaining bits of the first octet specifying the number of
-      additional octets.  The subsequent octets carry the value, 8 bits
-      per octet, most significant digit first.  The minimum number of
-      octets shall be used to encode the length (i.e., no octets
-      representing leading zeros shall be included within the length
-      encoding).
-
-      3. 0x06 -- Tag for OBJECT IDENTIFIER
-
-      4. Object identifier length -- length (number of octets) of the
-      encoded object identifier contained in element 5, encoded per
-      rules as described in 2a. and 2b. above.
-
-      5. Object identifier octets -- variable number of octets, encoded
-      per ASN.1 BER rules:
-
-
-
-
-
-Linn                        Standards Track                    [Page 74]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-      5a. The first octet contains the sum of two values: (1) the top-
-      level object identifier component, multiplied by 40 (decimal), and
-      (2) the second-level object identifier component.  This special
-      case is the only point within an object identifier encoding where
-      a single octet represents contents of more than one component.
-
-      5b. Subsequent octets, if required, encode successively-lower
-      components in the represented object identifier.  A component's
-      encoding may span multiple octets, encoding 7 bits per octet (most
-      significant bits first) and with bit 8 set to "1" on all but the
-      final octet in the component's encoding.  The minimum number of
-      octets shall be used to encode each component (i.e., no octets
-      representing leading zeros shall be included within a component's
-      encoding).
-
-      (Note: In many implementations, elements 3-5 may be stored and
-      referenced as a contiguous string constant.)
-
-   The token tag is immediately followed by a mechanism-defined token
-   object.  Note that no independent size specifier intervenes following
-   the object identifier value to indicate the size of the mechanism-
-   defined token object.  While ASN.1 usage within mechanism-defined
-   tokens is permitted, there is no requirement that the mechanism-
-   specific innerContextToken, innerMsgToken, and sealedUserData data
-   elements must employ ASN.1 BER/DER encoding conventions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 75]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   The following ASN.1 syntax is included for descriptive purposes only,
-   to illustrate structural relationships among token and tag objects.
-   For interoperability purposes, token and tag encoding shall be
-   performed using the concrete encoding procedures described earlier in
-   this subsection.
-
-       GSS-API DEFINITIONS ::=
-
-       BEGIN
-
-       MechType ::= OBJECT IDENTIFIER
-       -- data structure definitions
-
-       -- callers must be able to distinguish among
-       -- InitialContextToken, SubsequentContextToken,
-       -- PerMsgToken, and SealedMessage data elements
-       -- based on the usage in which they occur
-
-       InitialContextToken ::=
-       -- option indication (delegation, etc.) indicated within
-       -- mechanism-specific token
-       [APPLICATION 0] IMPLICIT SEQUENCE {
-               thisMech MechType,
-               innerContextToken ANY DEFINED BY thisMech
-                  -- contents mechanism-specific
-                  -- ASN.1 structure not required
-               }
-
-       SubsequentContextToken ::= innerContextToken ANY
-       -- interpretation based on predecessor InitialContextToken
-       -- ASN.1 structure not required
-
-       PerMsgToken ::=
-       -- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
-       -- ASN.1 structure not required
-               innerMsgToken ANY
-
-       SealedMessage ::=
-       -- as emitted by GSS_Wrap and processed by GSS_Unwrap
-       -- includes internal, mechanism-defined indicator
-       -- of whether or not encrypted
-       -- ASN.1 structure not required
-               sealedUserData ANY
-
-       END
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 76]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-3.2: Mechanism-Independent Exported Name Object Format
-
-   This section specifies a mechanism-independent level of encapsulating
-   representation for names exported via the GSS_Export_name() call,
-   including an object identifier representing the exporting mechanism.
-   The format of names encapsulated via this representation shall be
-   defined within individual mechanism drafts.  Name objects of this
-   type will be identified with the following Object Identifier:
-
-   {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
-   4(gss-api-exported-name)}
-
-   No name type OID is included in this mechanism-independent level of
-   format definition, since (depending on individual mechanism
-   specifications) the enclosed name may be implicitly typed or may be
-   explicitly typed using a means other than OID encoding.
-
-        Length    Name          Description
-
-        2               TOK_ID          Token Identifier
-                                        For exported name objects, this
-                                        must be hex 04 01.
-        2               MECH_OID_LEN    Length of the Mechanism OID
-        MECH_OID_LEN    MECH_OID        Mechanism OID, in DER
-        4               NAME_LEN        Length of name
-        NAME_LEN        NAME            Exported name; format defined in
-                                        applicable mechanism draft.
-
-4: Name Type Definitions
-
-   This section includes definitions for name types and associated
-   syntaxes which are defined in a mechanism-independent fashion at the
-   GSS-API level rather than being defined in individual mechanism
-   specifications.
-
-4.1: Host-Based Service Name Form
-
-   The following Object Identifier value is provided as a means to
-   identify this name form:
-
-   {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
-   2(gss-host-based-services)}
-
-   The recommended symbolic name for this type is
-   "GSS_C_NT_HOSTBASED_SERVICE".
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 77]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   This name type is used to represent services associated with host
-   computers.  This name form is constructed using two elements,
-   "service" and "hostname", as follows:
-
-                             service@hostname
-
-   When a reference to a name of this type is resolved, the "hostname"
-   is canonicalized by attempting a DNS lookup and using the fully-
-   qualified domain name which is returned, or by using the "hostname"
-   as provided if the DNS lookup fails.  The canonicalization operation
-   also maps the host's name into lower-case characters.
-
-   The "hostname" element may be omitted. If no "@" separator is
-   included, the entire name is interpreted as the service specifier,
-   with the "hostname" defaulted to the canonicalized name of the local
-   host.
-
-   Values for the "service" element are registered with the IANA.
-
-4.2: User Name Form
-
-   This name form shall be represented by the Object Identifier {iso(1)
-   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
-   generic(1) user_name(1)}. The recommended mechanism-independent
-   symbolic name for this type is "GSS_C_NT_USER_NAME". (Note: the same
-   name form and OID is defined within the Kerberos V5 GSS-API
-   mechanism, but the symbolic name recommended there begins with a
-   "GSS_KRB5_NT_" prefix.)
-
-   This name type is used to indicate a named user on a local system.
-   Its interpretation is OS-specific.  This name form is constructed as:
-
-                                 username
-
-4.3: Machine UID Form
-
-   This name form shall be represented by the Object Identifier {iso(1)
-   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
-   generic(1) machine_uid_name(2)}.  The recommended mechanism-
-   independent symbolic name for this type is
-   "GSS_C_NT_MACHINE_UID_NAME".  (Note: the same name form and OID is
-   defined within the Kerberos V5 GSS-API mechanism, but the symbolic
-   name recommended there begins with a "GSS_KRB5_NT_" prefix.)
-
-   This name type is used to indicate a numeric user identifier
-   corresponding to a user on a local system.  Its interpretation is
-   OS-specific.  The gss_buffer_desc representing a name of this type
-   should contain a locally-significant uid_t, represented in host byte
-
-
-
-Linn                        Standards Track                    [Page 78]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   order.  The GSS_Import_name() operation resolves this uid into a
-   username, which is then treated as the User Name Form.
-
-4.4: String UID Form
-
-   This name form shall be represented by the Object Identifier {iso(1)
-   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
-   generic(1) string_uid_name(3)}.  The recommended symbolic name for
-   this type is "GSS_C_NT_STRING_UID_NAME".  (Note: the same name form
-   and OID is defined within the Kerberos V5 GSS-API mechanism, but the
-   symbolic name recommended there begins with a "GSS_KRB5_NT_" prefix.)
-
-   This name type is used to indicate a string of digits representing
-   the numeric user identifier of a user on a local system.  Its
-   interpretation is OS-specific. This name type is similar to the
-   Machine UID Form, except that the buffer contains a string
-   representing the uid_t.
-
-5:  Mechanism-Specific Example Scenarios
-
-   This section provides illustrative overviews of the use of various
-   candidate mechanism types to support the GSS-API. These discussions
-   are intended primarily for readers familiar with specific security
-   technologies, demonstrating how GSS-API functions can be used and
-   implemented by candidate underlying mechanisms. They should not be
-   regarded as constrictive to implementations or as defining the only
-   means through which GSS-API functions can be realized with a
-   particular underlying technology, and do not demonstrate all GSS-API
-   features with each technology.
-
-5.1: Kerberos V5, single-TGT
-
-   OS-specific login functions yield a TGT to the local realm Kerberos
-   server; TGT is placed in a credentials structure for the client.
-   Client calls GSS_Acquire_cred()  to acquire a cred_handle in order to
-   reference the credentials for use in establishing security contexts.
-
-   Client calls GSS_Init_sec_context().  If the requested service is
-   located in a different realm, GSS_Init_sec_context()  gets the
-   necessary TGT/key pairs needed to traverse the path from local to
-   target realm; these data are placed in the owner's TGT cache. After
-   any needed remote realm resolution, GSS_Init_sec_context()  yields a
-   service ticket to the requested service with a corresponding session
-   key; these data are stored in conjunction with the context. GSS-API
-   code sends KRB_TGS_REQ request(s) and receives KRB_TGS_REP
-   response(s) (in the successful case) or KRB_ERROR.
-
-
-
-
-
-Linn                        Standards Track                    [Page 79]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   Assuming success, GSS_Init_sec_context()  builds a Kerberos-formatted
-   KRB_AP_REQ message, and returns it in output_token.  The client sends
-   the output_token to the service.
-
-   The service passes the received token as the input_token argument to
-   GSS_Accept_sec_context(),  which verifies the authenticator, provides
-   the service with the client's authenticated name, and returns an
-   output_context_handle.
-
-   Both parties now hold the session key associated with the service
-   ticket, and can use this key in subsequent GSS_GetMIC(),
-   GSS_VerifyMIC(),  GSS_Wrap(), and GSS_Unwrap() operations.
-
-5.2: Kerberos V5, double-TGT
-
-   TGT acquisition as above.
-
-   Note: To avoid unnecessary frequent invocations of error paths when
-   implementing the GSS-API atop Kerberos V5, it seems appropriate to
-   represent "single-TGT K-V5" and "double-TGT K-V5" with separate
-   mech_types, and this discussion makes that assumption.
-
-   Based on the (specified or defaulted) mech_type,
-   GSS_Init_sec_context()  determines that the double-TGT protocol
-   should be employed for the specified target. GSS_Init_sec_context()
-   returns GSS_S_CONTINUE_NEEDED major_status, and its returned
-   output_token contains a request to the service for the service's TGT.
-   (If a service TGT with suitably long remaining lifetime already
-   exists in a cache, it may be usable, obviating the need for this
-   step.) The client passes the output_token to the service.  Note: this
-   scenario illustrates a different use for the GSS_S_CONTINUE_NEEDED
-   status return facility than for support of mutual authentication;
-   note that both uses can coexist as successive operations within a
-   single context establishment operation.
-
-   The service passes the received token as the input_token argument to
-   GSS_Accept_sec_context(),  which recognizes it as a request for TGT.
-   (Note that current Kerberos V5 defines no intra-protocol mechanism to
-   represent such a request.) GSS_Accept_sec_context()  returns
-   GSS_S_CONTINUE_NEEDED major_status and provides the service's TGT in
-   its output_token. The service sends the output_token to the client.
-
-   The client passes the received token as the input_token argument to a
-   continuation of GSS_Init_sec_context(). GSS_Init_sec_context() caches
-   the received service TGT and uses it as part of a service ticket
-   request to the Kerberos authentication server, storing the returned
-   service ticket and session key in conjunction with the context.
-   GSS_Init_sec_context()  builds a Kerberos-formatted authenticator,
-
-
-
-Linn                        Standards Track                    [Page 80]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   and returns it in output_token along with GSS_S_COMPLETE return
-   major_status. The client sends the output_token to the service.
-
-   Service passes the received token as the input_token argument to a
-   continuation call to GSS_Accept_sec_context().
-   GSS_Accept_sec_context()  verifies the authenticator, provides the
-   service with the client's authenticated name, and returns
-   major_status GSS_S_COMPLETE.
-
-   GSS_GetMIC(),  GSS_VerifyMIC(), GSS_Wrap(), and GSS_Unwrap()  as
-   above.
-
-5.3:  X.509 Authentication Framework
-
-   This example illustrates use of the GSS-API in conjunction with
-   public-key mechanisms, consistent with the X.509 Directory
-   Authentication Framework.
-
-   The GSS_Acquire_cred()  call establishes a credentials structure,
-   making the client's private key accessible for use on behalf of the
-   client.
-
-   The client calls GSS_Init_sec_context(),  which interrogates the
-   Directory to acquire (and validate) a chain of public-key
-   certificates, thereby collecting the public key of the service.  The
-   certificate validation operation determines that suitable integrity
-   checks were applied by trusted authorities and that those
-   certificates have not expired. GSS_Init_sec_context()  generates a
-   secret key for use in per-message protection operations on the
-   context, and enciphers that secret key under the service's public
-   key.
-
-   The enciphered secret key, along with an authenticator quantity
-   signed with the client's private key, is included in the output_token
-   from GSS_Init_sec_context().  The output_token also carries a
-   certification path, consisting of a certificate chain leading from
-   the service to the client; a variant approach would defer this path
-   resolution to be performed by the service instead of being asserted
-   by the client. The client application sends the output_token to the
-   service.
-
-   The service passes the received token as the input_token argument to
-   GSS_Accept_sec_context().  GSS_Accept_sec_context() validates the
-   certification path, and as a result determines a certified binding
-   between the client's distinguished name and the client's public key.
-   Given that public key, GSS_Accept_sec_context() can process the
-   input_token's authenticator quantity and verify that the client's
-   private key was used to sign the input_token. At this point, the
-
-
-
-Linn                        Standards Track                    [Page 81]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   client is authenticated to the service. The service uses its private
-   key to decipher the enciphered secret key provided to it for per-
-   message protection operations on the context.
-
-   The client calls GSS_GetMIC()  or GSS_Wrap() on a data message, which
-   causes per-message authentication, integrity, and (optional)
-   confidentiality facilities to be applied to that message. The service
-   uses the context's shared secret key to perform corresponding
-   GSS_VerifyMIC()  and GSS_Unwrap() calls.
-
-6:  Security Considerations
-
-   Security issues are discussed throughout this memo.
-
-7:  Related Activities
-
-   In order to implement the GSS-API atop existing, emerging, and future
-   security mechanisms:
-
-      object identifiers must be assigned to candidate GSS-API
-      mechanisms and the name types which they support
-
-      concrete data element formats and processing procedures must be
-      defined for candidate mechanisms
-
-   Calling applications must implement formatting conventions which will
-   enable them to distinguish GSS-API tokens from other data carried in
-   their application protocols.
-
-   Concrete language bindings are required for the programming
-   environments in which the GSS-API is to be employed, as RFC-1509
-   defines for the C programming language and GSS-V1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 82]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-APPENDIX A
-
-MECHANISM DESIGN CONSTRAINTS
-
-   The following constraints on GSS-API mechanism designs are adopted in
-   response to observed caller protocol requirements, and adherence
-   thereto is anticipated in subsequent descriptions of GSS-API
-   mechanisms to be documented in standards-track Internet
-   specifications.
-
-   It is strongly recommended that mechanisms offering per-message
-   protection services also offer at least one of the replay detection
-   and sequencing services, as mechanisms offering neither of the latter
-   will fail to satisfy recognized requirements of certain candidate
-   caller protocols.
-
-APPENDIX B
-
-                         COMPATIBILITY WITH GSS-V1
-
-   It is the intent of this document to define an interface and
-   procedures which preserve compatibility between GSS-V1 (RFC-1508)
-   callers and GSS- V2 providers.  All calls defined in GSS-V1 are
-   preserved, and it has been a goal that GSS-V1 callers should be able
-   to operate atop GSS-V2 provider implementations.  Certain detailed
-   changes, summarized in this section, have been made in order to
-   resolve omissions identified in GSS-V1.
-
-   The following GSS-V1 constructs, while supported within GSS-V2, are
-   deprecated:
-
-      Names for per-message processing routines: GSS_Seal() deprecated
-      in favor of GSS_Wrap(); GSS_Sign() deprecated in favor of
-      GSS_GetMIC(); GSS_Unseal() deprecated in favor of GSS_Unwrap();
-      GSS_Verify() deprecated in favor of GSS_VerifyMIC().
-
-      GSS_Delete_sec_context() facility for context_token usage,
-      allowing mechanisms to signal context deletion, is retained for
-      compatibility with GSS-V1.  For current usage, it is recommended
-      that both peers to a context invoke GSS_Delete_sec_context()
-      independently, passing a null output_context_token buffer to
-      indicate that no context_token is required.  Implementations of
-      GSS_Delete_sec_context() should delete relevant locally-stored
-      context information.
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 83]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   This GSS-V2 specification adds the following calls which are not
-   present in GSS-V1:
-
-      Credential management calls: GSS_Add_cred(),
-      GSS_Inquire_cred_by_mech().
-
-      Context-level calls: GSS_Inquire_context(), GSS_Wrap_size_limit(),
-      GSS_Export_sec_context(), GSS_Import_sec_context().
-
-      Per-message calls: No new calls.  Existing calls have been renamed.
-
-      Support calls: GSS_Create_empty_OID_set(),
-      GSS_Add_OID_set_member(), GSS_Test_OID_set_member(),
-      GSS_Release_OID(), GSS_OID_to_str(), GSS_Str_to_OID(),
-      GSS_Inquire_names_for_mech(), GSS_Inquire_mechs_for_name(),
-      GSS_Canonicalize_name(), GSS_Export_name(), GSS_Duplicate_name().
-
-   This GSS-V2 specification introduces three new facilities applicable
-   to security contexts, indicated using the following context state
-   values which are not present in GSS-V1:
-
-      anon_state, set TRUE to indicate that a context's initiator is
-      anonymous from the viewpoint of the target; Section 1.2.5 of this
-      specification provides a summary description of the GSS-V2
-      anonymity support facility, support and use of which is optional.
-
-      prot_ready_state, set TRUE to indicate that a context may be used
-      for per-message protection before final completion of context
-      establishment; Section 1.2.7 of this specification provides a
-      summary description of the GSS-V2 facility enabling mechanisms to
-      selectively permit per-message protection during context
-      establishment, support and use of which is optional.
-
-      trans_state, set TRUE to indicate that a context is transferable to
-      another process using the GSS-V2 GSS_Export_sec_context() facility.
-
-   These state values are represented (at the C bindings level) in
-   positions within a bit vector which are unused in GSS-V1, and may be
-   safely ignored by GSS-V1 callers.
-
-   Relative to GSS-V1, GSS-V2 provides additional guidance to GSS-API
-   implementors in the following areas: implementation robustness,
-   credential management, behavior in multi-mechanism configurations,
-   naming support, and inclusion of optional sequencing services.  The
-   token tagging facility as defined in GSS-V2, Section 3.1, is now
-   described directly in terms of octets to facilitate interoperable
-   implementation without general ASN.1 processing code; the
-   corresponding ASN.1 syntax, included for descriptive purposes, is
-
-
-
-Linn                        Standards Track                    [Page 84]
-
-RFC 2078                        GSS-API                     January 1997
-
-
-   unchanged from that in GSS-V1. For use in conjunction with added
-   naming support facilities, a new Exported Name Object construct is
-   added.  Additional name types are introduced in Section 4.
-
-   This GSS-V2 specification adds the following major_status values
-   which are not defined in GSS-V1:
-
-     GSS_S_BAD_QOP                 unsupported QOP value
-     GSS_S_UNAUTHORIZED            operation unauthorized
-     GSS_S_UNAVAILABLE             operation unavailable
-     GSS_S_DUPLICATE_ELEMENT       duplicate credential element requested
-     GSS_S_NAME_NOT_MN             name contains multi-mechanism elements
-     GSS_S_GAP_TOKEN               skipped predecessor token(s)
-                                    detected
-
-   Of these added status codes, only two values are defined to be
-   returnable by calls existing in GSS-V1: GSS_S_BAD_QOP (returnable by
-   GSS_GetMIC() and GSS_Wrap()), and GSS_S_GAP_TOKEN (returnable by
-   GSS_VerifyMIC() and GSS_Unwrap()).
-
-   Additionally, GSS-V2 descriptions of certain calls present in GSS-V1
-   have been updated to allow return of additional major_status values
-   from the set as defined in GSS-V1: GSS_Inquire_cred() has
-   GSS_S_DEFECTIVE_CREDENTIAL and GSS_S_CREDENTIALS_EXPIRED defined as
-   returnable, GSS_Init_sec_context() has GSS_S_OLD_TOKEN,
-   GSS_S_DUPLICATE_TOKEN, and GSS_S_BAD_MECH defined as returnable, and
-   GSS_Accept_sec_context() has GSS_S_BAD_MECH defined as returnable.
-
-Author's Address
-
-   John Linn
-   OpenVision Technologies
-   One Main St.
-   Cambridge, MA  02142  USA
-
-   Phone: +1 617.374.2245
-   EMail: John.Linn@ov.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 85]
-
diff --git a/doc/standardisation/rfc2203.txt b/doc/standardisation/rfc2203.txt
deleted file mode 100644
index 2f6a8a0d0..000000000
--- a/doc/standardisation/rfc2203.txt
+++ /dev/null
@@ -1,1291 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          M. Eisler
-Request for Comments: 2203                                       A. Chiu
-Category: Standards Track                                        L. Ling
-                                                          September 1997
-
-
-                   RPCSEC_GSS Protocol Specification
-
-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.
-
-Abstract
-
-   This memo describes an ONC/RPC security flavor that allows RPC
-   protocols to access the Generic Security Services Application
-   Programming Interface (referred to henceforth as GSS-API).
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
-   2.  The ONC RPC Message Protocol . . . . . . . . . . . . . . . . . 2
-   3.  Flavor Number Assignment . . . . . . . . . . . . . . . . . . . 3
-   4.  New auth_stat Values . . . . . . . . . . . . . . . . . . . . . 3
-   5.  Elements of the RPCSEC_GSS Security Protocol . . . . . . . . . 3
-   5.1.  Version Selection  . . . . . . . . . . . . . . . . . . . . . 5
-   5.2.  Context Creation . . . . . . . . . . . . . . . . . . . . . . 5
-   5.2.1.  Mechanism and QOP Selection  . . . . . . . . . . . . . . . 5
-   5.2.2.  Context Creation Requests  . . . . . . . . . . . . . . . . 6
-   5.2.3.  Context Creation Responses . . . . . . . . . . . . . . . . 8
-   5.2.3.1.  Context Creation Response - Successful Acceptance  . . . 8
-   5.2.3.1.1.  Client Processing of Successful Context Creation
-               Responses  . . . . . . . . . . . . . . . . . . . . . . 9
-   5.2.3.2.  Context Creation Response - Unsuccessful Cases . . . . . 9
-   5.3.  RPC Data Exchange  . . . . . . . . . . . . . . . . . . . .  10
-   5.3.1.  RPC Request Header . . . . . . . . . . . . . . . . . . .  10
-   5.3.2.  RPC Request Data . . . . . . . . . . . . . . . . . . . .  11
-   5.3.2.1.  RPC Request Data - No Data Integrity . . . . . . . . .  11
-   5.3.2.2.  RPC Request Data - With Data Integrity . . . . . . . .  11
-   5.3.2.3.  RPC Request Data - With Data Privacy . . . . . . . . .  12
-   5.3.3.  Server Processing of RPC Data Requests . . . . . . . . .  12
-   5.3.3.1.  Context Management . . . . . . . . . . . . . . . . . .  12
-   5.3.3.2.  Server Reply - Request Accepted  . . . . . . . . . . .  14
-   5.3.3.3.  Server Reply - Request Denied  . . . . . . . . . . . .  15
-
-
-
-Eisler, et. al.             Standards Track                     [Page 1]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-   5.3.3.4.  Mapping of GSS-API Errors to Server Responses  . . . .  16
-   5.3.3.4.1.  GSS_GetMIC() Failure . . . . . . . . . . . . . . . .  16
-   5.3.3.4.2.  GSS_VerifyMIC() Failure  . . . . . . . . . . . . . .  16
-   5.3.3.4.3.  GSS_Unwrap() Failure . . . . . . . . . . . . . . . .  16
-   5.3.3.4.4.  GSS_Wrap() Failure . . . . . . . . . . . . . . . . .  16
-   5.4.  Context Destruction  . . . . . . . . . . . . . . . . . . .  17
-   6.  Set of GSS-API Mechanisms  . . . . . . . . . . . . . . . . .  17
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . .  18
-   7.1.  Privacy of Call Header . . . . . . . . . . . . . . . . . .  18
-   7.2.  Sequence Number Attacks  . . . . . . . . . . . . . . . . .  18
-   7.2.1.  Sequence Numbers Above the Window  . . . . . . . . . . .  18
-   7.2.2.  Sequence Numbers Within or Below the Window  . . . . . .  18
-   7.3.  Message Stealing Attacks . . . . . . . . . . . . . . . . .  19
-   Appendix A. GSS-API Major Status Codes . . . . . . . . . . . . .  20
-   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .  22
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  23
-
-1.  Introduction
-
-   This document describes the protocol used by the RPCSEC_GSS security
-   flavor.  Security flavors have been called authentication flavors for
-   historical reasons. This memo recognizes that there are two other
-   security services besides authentication, integrity, and privacy, and
-   so defines a new RPCSEC_GSS security flavor.
-
-   The protocol is described using the XDR language [Srinivasan-xdr].
-   The reader is assumed to be familiar with ONC RPC and the security
-   flavor mechanism [Srinivasan-rpc].  The reader is also assumed to be
-   familiar with the GSS-API framework [Linn].  The RPCSEC_GSS security
-   flavor uses GSS-API interfaces to provide security services that are
-   independent of the underlying security mechanism.
-
-2.  The ONC RPC Message Protocol
-
-   This memo refers to the following XDR types of the ONC RPC protocol,
-   which are described in the document entitled Remote Procedure Call
-   Protocol Specification Version 2 [Srinivasan-rpc]:
-
-      msg_type
-      reply_stat
-      auth_flavor
-      accept_stat
-      reject_stat
-      auth_stat
-      opaque_auth
-      rpc_msg
-      call_body
-      reply_body
-
-
-
-Eisler, et. al.             Standards Track                     [Page 2]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-      accepted_reply
-      rejected_reply
-
-3.  Flavor Number Assignment
-
-   The RPCSEC_GSS security flavor has been assigned the value of 6:
-
-      enum auth_flavor {
-          ...
-          RPCSEC_GSS = 6      /* RPCSEC_GSS security flavor */
-      };
-
-4.  New auth_stat Values
-
-   RPCSEC_GSS requires the addition of two new values to the auth_stat
-   enumerated type definition:
-
-      enum auth_stat {
-              ...
-              /*
-               * RPCSEC_GSS errors
-               */
-              RPCSEC_GSS_CREDPROBLEM = 13,
-              RPCSEC_GSS_CTXPROBLEM = 14
-      };
-
-   The descriptions of these two new values are defined later in this
-   memo.
-
-5.  Elements of the RPCSEC_GSS Security Protocol
-
-   An RPC session based on the RPCSEC_GSS security flavor consists of
-   three phases: context creation, RPC data exchange, and context
-   destruction.  In the following discussion, protocol elements for
-   these three phases are described.
-
-   The following description of the RPCSEC_GSS protocol uses some of the
-   definitions within XDR language description of the RPC protocol.
-
-   Context creation and destruction use control messages that are not
-   dispatched to service procedures registered by an RPC server.  The
-   program and version numbers used in these control messages are the
-   same as the RPC service's program and version numbers.  The procedure
-   number used is NULLPROC (zero).  A field in the credential
-   information (the gss_proc field which is defined in the
-   rpc_gss_cred_t structure below) specifies whether a message is to be
-   interpreted as a control message or a regular RPC message.  If this
-   field is set to RPCSEC_GSS_DATA, no control action is implied; in
-
-
-
-Eisler, et. al.             Standards Track                     [Page 3]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-   this case, it is a regular data message.  If this field is set to any
-   other value, a control action is implied.  This is described in the
-   following sections.
-
-   Just as with normal RPC data exchange messages, the transaction
-   identifier (the xid field in struct rpc_msg), should be set to unique
-   values on each call for context creation and context destruction.
-
-   The following definitions are used for describing the protocol.
-
-      /* RPCSEC_GSS control procedures */
-
-
-      enum rpc_gss_proc_t {
-              RPCSEC_GSS_DATA = 0,
-              RPCSEC_GSS_INIT = 1,
-              RPCSEC_GSS_CONTINUE_INIT = 2,
-              RPCSEC_GSS_DESTROY = 3
-      };
-
-      /* RPCSEC_GSS services */
-
-      enum rpc_gss_service_t {
-          /* Note: the enumerated value for 0 is reserved. */
-          rpc_gss_svc_none = 1,
-          rpc_gss_svc_integrity = 2,
-          rpc_gss_svc_privacy = 3
-      };
-
-      /* Credential */
-
-      /*
-       * Note: version 0 is reserved for possible future
-       * definition of a version negotiation protocol
-       *
-       */
-      #define RPCSEC_GSS_VERS_1 1
-
-      struct rpc_gss_cred_t {
-          union switch (unsigned int version) { /* version of
-                                                      RPCSEC_GSS */
-          case RPCSEC_GSS_VERS_1:
-              struct {
-                  rpc_gss_proc_t gss_proc;  /* control procedure */
-                  unsigned int seq_num;   /* sequence number */
-                  rpc_gss_service_t service; /* service used */
-                  opaque handle<>;       /* context handle */
-              } rpc_gss_cred_vers_1_t;
-
-
-
-Eisler, et. al.             Standards Track                     [Page 4]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-          }
-      };
-
-      /* Maximum sequence number value */
-
-      #define MAXSEQ 0x80000000
-
-5.1.  Version Selection
-
-   This document defines just one protocol version (RPCSEC_GSS_VERS_1).
-   The client should assume that the server supports RPCSEC_GSS_VERS_1
-   and issue a Context Creation message (as described in the section
-   RPCSEC_GSS_VERS_1, the RPC response will have a reply_stat of
-   MSG_DENIED, a rejection status of AUTH_ERROR, and an auth_stat of
-   AUTH_REJECTED_CRED.
-
-5.2.  Context Creation
-
-   Before RPC data is exchanged on a session using the RPCSEC_GSS
-   flavor, a context must be set up between the client and the server.
-   Context creation may involve zero or more RPC exchanges.  The number
-   of exchanges depends on the security mechanism.
-
-5.2.1.  Mechanism and QOP Selection
-
-   There is no facility in the RPCSEC_GSS protocol to negotiate GSS-API
-   mechanism identifiers or QOP values. At minimum, it is expected that
-   implementations of the RPCSEC_GSS protocol provide a means to:
-
-   *    specify mechanism identifiers, QOP values, and RPCSEC_GSS
-        service values on the client side, and to
-
-   *    enforce mechanism identifiers, QOP values, and RPCSEC_GSS
-        service values on a per-request basis on the server side.
-
-   It is necessary that above capabilities exist so that applications
-   have the means to conform the required set of required set of
-   <mechanism, QOP, service> tuples (See the section entitled Set of
-   GSS-API Mechanisms).  An application may negotiate <mechanism, QOP,
-   service> selection within its protocol or via an out of band
-   protocol. Hence it may be necessary for RPCSEC_GSS implementations to
-   provide programming interfaces for the specification and enforcement
-   of <mechanism, QOP, service>.
-
-   Additionally, implementations may depend on negotiation schemes
-   constructed as pseudo-mechanisms under the GSS-API.  Because such
-   schemes are below the GSS-API layer, the RPCSEC_GSS protocol, as
-   specified in this document, can make use of them.
-
-
-
-Eisler, et. al.             Standards Track                     [Page 5]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-5.2.2.  Context Creation Requests
-
-   The first RPC request from the client to the server initiates context
-   creation.  Within the RPC message protocol's call_body structure,
-   rpcvers is set to 2. prog and vers are always those for the service
-   being accessed.  The proc is always set to NULLPROC (zero).
-
-   Within the RPC message protocol's cred structure, flavor is set to
-   RPCSEC_GSS (6).  The opaque data of the cred structure (the body
-   field) constituting the credential encodes the rpc_gss_cred_t
-   structure defined previously.
-
-   The values of the fields contained in the rpc_gss_cred_t structure
-   are set as follows.  The version field is set to the version of the
-   RPCSEC_GSS protocol the client wants to use.  The remainder of this
-   memo documents version RPCSEC_GSS_VERS_1 of RPCSEC_GSS, and so the
-   version field would be set to RPCSEC_GSS_VERS_1.  The gss_proc field
-   must be set to RPCSEC_GSS_INIT for the first creation request.  In
-   subsequent creation requests, the gss_proc field must be set to
-   RPCSEC_GSS_CONTINUE_INIT.  In a creation request, the seq_num and
-   service fields are undefined and both must be ignored by the server.
-   In the first creation request, the handle field is NULL (opaque data
-   of zero length).  In subsequent creation requests, handle must be
-   equal to the value returned by the server.  The handle field serves
-   as the identifier for the context, and will not change for the
-   duration of the context, including responses to
-   RPCSEC_GSS_CONTINUE_INIT.
-
-   The verifier field in the RPC message header is also described by the
-   opaque_auth structure.  All creation requests have the NULL verifier
-   (AUTH_NONE flavor with zero length opaque data).
-
-   Following the verifier are the call data (procedure specific
-   parameters).  Note that the proc field of the call_body structure is
-   set to NULLPROC, and thus normally there would be zero octets
-   following the verifier.  However, since there is no RPC data exchange
-   during a context creation, it is safe to transfer information
-   following the verifier.  It is necessary to "overload" the call data
-   in this way, rather than pack the GSS-API token into the RPC header,
-   because RPC Version 2 restricts the amount of data that can be sent
-   in the header.  The opaque body of the credential and verifier fields
-   can be each at most 400 octets long, and GSS tokens can be longer
-   than 800 octets.
-
-
-
-
-
-
-
-
-Eisler, et. al.             Standards Track                     [Page 6]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-   The call data for a context creation request is described by the
-   following structure for all creation requests:
-
-      struct rpc_gss_init_arg {
-          opaque gss_token<>;
-      };
-
-   Here, gss_token is the token returned by the call to  GSS-API's
-   GSS_Init_sec_context() routine, opaquely encoded.  The value of this
-   field will likely be different in each creation request, if there is
-   more than one creation request.  If no token is returned by the call
-   to GSS_Init_sec_context(), the context must have been created
-   (assuming no errors), and there will not be any more creation
-   requests.
-
-   When GSS_Init_sec_context() is called, the parameters
-   replay_det_req_flag and sequence_req_flag must be turned off. The
-   reasons for this are:
-
-   *    ONC RPC can be used over unreliable transports and provides no
-        layer to reliably re-assemble messages. Thus it is possible for
-        gaps in message sequencing to occur, as well as out of order
-        messages.
-
-   *    RPC servers can be multi-threaded, and thus the order in which
-        GSS-API messages are signed or wrapped can be different from the
-        order in which the messages are verified or unwrapped, even if
-        the requests are sent on reliable transports.
-
-   *    To maximize convenience of implementation, the order in which an
-        ONC RPC entity will verify the header and verify/unwrap the body
-        of an RPC call or reply is left unspecified.
-
-   The RPCSEC_GSS protocol provides for protection from replay attack,
-   yet tolerates out-of-order delivery or processing of messages and
-   tolerates dropped requests.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eisler, et. al.             Standards Track                     [Page 7]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-5.2.3.  Context Creation Responses
-
-5.2.3.1.  Context Creation Response - Successful Acceptance
-
-   The response to a successful creation request has an MSG_ACCEPTED
-   response with a status of SUCCESS.  The results field encodes a
-   response with the following structure:
-
-      struct rpc_gss_init_res {
-              opaque handle<>;
-              unsigned int gss_major;
-              unsigned int gss_minor;
-              unsigned int seq_window;
-              opaque gss_token<>;
-      };
-
-   Here, handle is non-NULL opaque data that serves as the context
-   identifier. The client must use this value in all subsequent requests
-   whether control messages or otherwise).  The gss_major and gss_minor
-   fields contain the results of the call to GSS_Accept_sec_context()
-   executed by the server.  The values for the gss_major field are
-   defined in Appendix A of this document.  The values for the gss_minor
-   field are GSS-API mechanism specific and are defined in the
-   mechanism's specification.  If gss_major is not one of GSS_S_COMPLETE
-   or GSS_S_CONTINUE_NEEDED, the context setup has failed; in this case
-   handle and gss_token must be set to NULL by the server.  The value of
-   gss_minor is dependent on the value of gss_major and the security
-   mechanism used.  The gss_token field contains any token returned by
-   the GSS_Accept_sec_context() call executed by the server.  A token
-   may be returned for both successful values of gss_major.  If the
-   value is GSS_S_COMPLETE, it indicates that the server is not
-   expecting any more tokens, and the RPC Data Exchange phase must begin
-   on the subsequent request from the client. If the value is
-   GSS_S_CONTINUE_NEEDED, the server is expecting another token.  Hence
-   the client must send at least one more creation request (with
-   gss_proc set to RPCSEC_GSS_CONTINUE_INIT in the request's credential)
-   carrying the required token.
-
-   In a successful response, the seq_window field is set to the sequence
-   window length supported by the server for this context.  This window
-   specifies the maximum number of client requests that may be
-   outstanding for this context. The server will accept "seq_window"
-   requests at a time, and these may be out of order.  The client may
-   use this number to determine the number of threads that can
-   simultaneously send requests on this context.
-
-
-
-
-
-
-Eisler, et. al.             Standards Track                     [Page 8]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-   If gss_major is GSS_S_COMPLETE, the verifier's (the verf element in
-   the response) flavor field is set to RPCSEC_GSS, and the body field
-   set to the checksum of the seq_window (in network order). The QOP
-   used for this checksum is 0 (zero), which is the default QOP.  For
-   all other values of gss_major, a NULL verifier (AUTH_NONE flavor with
-   zero-length opaque data) is used.
-
-5.2.3.1.1.  Client Processing of Successful Context Creation Responses
-
-   If the value of gss_major in the response is GSS_S_CONTINUE_NEEDED,
-   then the client, per the GSS-API specification, must invoke
-   GSS_Init_sec_context() using the token returned in gss_token in the
-   context creation response. The client must then generate a context
-   creation request, with gss_proc set to RPCSEC_GSS_CONTINUE_INIT.
-
-   If the value of gss_major in the response is GSS_S_COMPLETE, and if
-   the client's previous invocation of GSS_Init_sec_context() returned a
-   gss_major value of GSS_S_CONTINUE_NEEDED, then the client, per the
-   GSS-API specification, must invoke GSS_Init_sec_context() using the
-   token returned in gss_token in the context creation response. If
-   GSS_Init_sec_context() returns GSS_S_COMPLETE, the context is
-   successfully set up, and the RPC data exchange phase must begin on
-   the subsequent request from the client.
-
-5.2.3.2.  Context Creation Response - Unsuccessful Cases
-
-   An MSG_ACCEPTED reply (to a creation request) with an acceptance
-   status of other than SUCCESS has a NULL verifier (flavor set to
-   AUTH_NONE, and zero length opaque data in the body field), and is
-   formulated as usual for different status values.
-
-   An MSG_DENIED reply (to a creation request) is also formulated as
-   usual.  Note that MSG_DENIED could be returned because the server's
-   RPC implementation does not recognize the RPCSEC_GSS security flavor.
-   RFC 1831 does not specify the appropriate reply status in this
-   instance, but common implementation practice appears to be to return
-   a rejection status of AUTH_ERROR with an auth_stat of
-   AUTH_REJECTEDCRED. Even though two new values (RPCSEC_GSS_CREDPROBLEM
-   and RPCSEC_GSS_CTXPROBLEM) have been defined for the auth_stat type,
-   neither of these two can be returned in responses to context creation
-   requests.  The auth_stat new values can be used for responses to
-   normal (data) requests.  This is described later.
-
-   MSG_DENIED might also be returned if the RPCSEC_GSS version number in
-   the credential is not supported on the server. In that case, the
-   server returns a rejection status of AUTH_ERROR, with an auth_stat of
-
-   AUTH_REJECTED_CRED.
-
-
-
-Eisler, et. al.             Standards Track                     [Page 9]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-5.3.  RPC Data Exchange
-
-   The data exchange phase is entered after a context has been
-   successfully set up. The format of the data exchanged depends on the
-   security service used for the request.  Although clients can change
-   the security service and QOP used on a per-request basis, this may
-   not be acceptable to all RPC services; some RPC services may "lock"
-   the data exchange phase into using the QOP and service used on the
-   first data exchange message.  For all three modes of service (no data
-   integrity, data integrity, data privacy), the RPC request header has
-   the same format.
-
-5.3.1.  RPC Request Header
-
-   The credential has the opaque_auth structure described earlier.  The
-   flavor field is set to RPCSEC_GSS.  The credential body is created by
-   XDR encoding the rpc_gss_cred_t structure listed earlier into an
-   octet stream, and then opaquely encoding this octet stream as the
-   body field.
-
-   Values of the fields contained in the rpc_gss_cred_t structure are
-   set as follows.  The version field is set to same version value that
-   was used to create the context, which within the scope of this memo
-   will always be RPCSEC_GSS_VERS_1.  The gss_proc field is set to
-   RPCSEC_GSS_DATA.  The service field is set to indicate the desired
-   service (one of rpc_gss_svc_none, rpc_gss_svc_integrity, or
-   rpc_gss_svc_privacy).  The handle field is set to the context handle
-   value received from the RPC server during context creation.  The
-   seq_num field can start at any value below MAXSEQ, and must be
-   incremented (by one or more) for successive requests.  Use of
-   sequence numbers is described in detail when server processing of the
-   request is discussed.
-
-   The verifier has the opaque_auth structure described earlier.  The
-   flavor field is set to RPCSEC_GSS.  The body field is set as follows.
-   The checksum of the RPC header (up to and including the credential)
-   is computed using the GSS_GetMIC() call with the desired QOP.  This
-   returns the checksum as an opaque octet stream and its length.  This
-   is encoded into the body field.  Note that the QOP is not explicitly
-   specified anywhere in the request.  It is implicit in the checksum or
-   encrypted data.  The same QOP value as is used for the header
-   checksum must also be used for the data (for checksumming or
-   encrypting), unless the service used for the request is
-   rpc_gss_svc_none.
-
-
-
-
-
-
-
-Eisler, et. al.             Standards Track                    [Page 10]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-5.3.2.  RPC Request Data
-
-5.3.2.1.  RPC Request Data - No Data Integrity
-
-   If the service specified is rpc_gss_svc_none, the data (procedure
-   arguments) are not integrity or privacy protected.  They are sent in
-   exactly the same way as they would be if the AUTH_NONE flavor were
-   used (following the verifier).  Note, however, that since the RPC
-   header is integrity protected, the sender will still be authenticated
-   in this case.
-
-5.3.2.2.  RPC Request Data - With Data Integrity
-
-   When data integrity is used, the request data is represented as
-   follows:
-
-      struct rpc_gss_integ_data {
-          opaque databody_integ<>;
-          opaque checksum<>;
-      };
-
-   The databody_integ field is created as follows.  A structure
-   consisting of a sequence number followed by the procedure arguments
-   is constructed. This is shown below as the type rpc_gss_data_t:
-
-      struct rpc_gss_data_t {
-          unsigned int seq_num;
-          proc_req_arg_t arg;
-      };
-
-   Here, seq_num must have the same value as in the credential.  The
-   type proc_req_arg_t is the procedure specific XDR type describing the
-   procedure arguments (and so is not specified here).  The octet stream
-   corresponding to the XDR encoded rpc_gss_data_t structure and its
-   length are placed in the databody_integ field. Note that because the
-   XDR type of databody_integ is opaque, the XDR encoding of
-   databody_integ will include an initial four octet length field,
-   followed by the XDR encoded octet stream of rpc_gss_data_t.
-
-   The checksum field represents the checksum of the XDR encoded octet
-   stream corresponding to the XDR encoded rpc_gss_data_t structure
-   (note, this is not the checksum of the databody_integ field).  This
-   is obtained using the GSS_GetMIC() call, with the same QOP as was
-   used to compute the header checksum (in the verifier). The
-
-
-
-
-
-
-
-Eisler, et. al.             Standards Track                    [Page 11]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-   GSS_GetMIC() call returns the checksum as an opaque octet stream and
-   its length. The checksum field of struct rpc_gss_integ_data has an
-   XDR type of opaque. Thus the checksum length from GSS_GetMIC() is
-   encoded as a four octet  length field, followed by the checksum,
-   padded to a multiple of four octets.
-
-5.3.2.3.  RPC Request Data - With Data Privacy
-
-   When data privacy is used, the request data is represented as
-   follows:
-
-      struct rpc_gss_priv_data {
-          opaque databody_priv<>
-      };
-
-   The databody_priv field is created as follows.  The rpc_gss_data_t
-   structure described earlier is constructed again in the same way as
-   for the case of data integrity.  Next, the GSS_Wrap() call is invoked
-   to encrypt the octet stream corresponding to the rpc_gss_data_t
-   structure, using the same value for QOP (argument qop_req to
-   GSS_Wrap()) as was used for the header checksum (in the verifier) and
-   conf_req_flag (an argument to GSS_Wrap()) of TRUE.  The GSS_Wrap()
-   call returns an opaque octet stream (representing the encrypted
-   rpc_gss_data_t structure) and its length, and this is encoded as the
-   databody_priv field. Since databody_priv has an XDR type of opaque,
-   the length returned by GSS_Wrap() is encoded as the four octet
-   length, followed by the encrypted octet stream (padded to a multiple
-   of four octets).
-
-5.3.3.  Server Processing of RPC Data Requests
-
-5.3.3.1.  Context Management
-
-   When a request is received by the server, the following are verified
-   to be acceptable:
-
-   *    the version number in the credential
-
-   *    the service specified in the credential
-
-   *    the context handle specified in the credential
-
-   *    the header checksum in the verifier (via GSS_VerifyMIC())
-
-   *    the sequence number (seq_num) specified in the credential (more
-        on this follows)
-
-
-
-
-
-Eisler, et. al.             Standards Track                    [Page 12]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-   The gss_proc field in the credential must be set to RPCSEC_GSS_DATA
-   for data requests (otherwise, the message will be interpreted as a
-   control message).
-
-   The server maintains a window of "seq_window" sequence numbers,
-   starting with the last sequence number seen and extending backwards.
-   If a sequence number higher than the last number seen is received
-   (AND if GSS_VerifyMIC() on the header checksum from the verifier
-   returns GSS_S_COMPLETE), the window is moved forward to the new
-   sequence number.  If the last sequence number seen is N, the server
-   is prepared to receive requests with sequence numbers in the range N
-   through (N - seq_window + 1), both inclusive.  If the sequence number
-   received falls below this range, it is silently discarded.  If the
-   sequence number is within this range, and the server has not seen it,
-   the request is accepted, and the server turns on a bit to "remember"
-   that this sequence number has been seen.  If the server determines
-   that it has already seen a sequence number within the window, the
-   request is silently discarded. The server should select a seq_window
-   value based on the number requests it expects to process
-   simultaneously. For example, in a threaded implementation seq_window
-   might be equal to the number of server threads. There are no known
-   security issues with selecting a large window. The primary issue is
-   how much space the server is willing to allocate to keep track of
-   requests received within the window.
-
-   The reason for discarding requests silently is that the server is
-   unable to determine if the duplicate or out of range request was due
-   to a sequencing problem in the client, network, or the operating
-   system, or due to some quirk in routing, or a replay attack by an
-   intruder.  Discarding the request allows the client to recover after
-   timing out, if indeed the duplication was unintentional or well
-   intended.  Note that a consequence of the silent discard is that
-   clients may increment the seq_num by more than one. The effect of
-   this is that the window will move forward more quickly. It is not
-   believed that there is any benefit to doing this.
-
-   Note that the sequence number algorithm requires that the client
-   increment the sequence number even if it is retrying a request with
-   the same RPC transaction identifier.  It is not infrequent for
-   clients to get into a situation where they send two or more attempts
-   and a slow server sends the reply for the first attempt. With
-   RPCSEC_GSS, each request and reply will have a unique sequence
-   number. If the client wishes to improve turn around time on the RPC
-   call, it can cache the RPCSEC_GSS sequence number of each request it
-   sends. Then when it receives a response with a matching RPC
-   transaction identifier, it can compute the checksum of each sequence
-   number in the cache to try to match the checksum in the reply's
-   verifier.
-
-
-
-Eisler, et. al.             Standards Track                    [Page 13]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-   The data is decoded according to the service specified in the
-   credential.  In the case of integrity or privacy, the server ensures
-   that the QOP value is acceptable, and that it is the same as that
-   used for the header checksum in the verifier.  Also, in the case of
-   integrity or privacy, the server will reject the message (with a
-   reply status of MSG_ACCEPTED, and an acceptance status of
-   GARBAGE_ARGS) if the sequence number embedded in the request body is
-   different from the sequence number in the credential.
-
-5.3.3.2.  Server Reply - Request Accepted
-
-   An MSG_ACCEPTED reply to a request in the data exchange phase will
-   have the verifier's (the verf element in the response) flavor field
-   set to RPCSEC_GSS, and the body field set to the checksum (the output
-   of GSS_GetMIC()) of the sequence number (in network order) of the
-   corresponding request.  The QOP used is the same as the QOP used for
-   the corresponding request.
-
-   If the status of the reply is not SUCCESS, the rest of the message is
-   formatted as usual.
-
-   If the status of the message is SUCCESS, the format of the rest of
-   the message depends on the service specified in the corresponding
-   request message. Basically, what follows the verifier in this case
-   are the procedure results, formatted in different ways depending on
-   the requested service.
-
-   If no data integrity was requested, the procedure results are
-   formatted as for the AUTH_NONE security flavor.
-
-   If data integrity was requested, the results are encoded in exactly
-   the same way as the procedure arguments were in the corresponding
-   request.  See the section 'RPC Request Data - With Data Integrity.'
-   The only difference is that the structure representing the
-   procedure's result - proc_res_arg_t - must be substituted in place of
-   the request argument structure proc_req_arg_t.  The QOP used for the
-   checksum must be the same as that used for constructing the reply
-   verifier.
-
-   If data privacy was requested, the results are encoded in exactly the
-   same way as the procedure arguments were in the corresponding
-   request.  See the section 'RPC Request Data - With Data Privacy.' The
-   QOP used for  encryption must be the same as that used for
-   constructing the reply verifier.
-
-
-
-
-
-
-
-Eisler, et. al.             Standards Track                    [Page 14]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-5.3.3.3.  Server Reply - Request Denied
-
-   An MSG_DENIED reply (to a data request) is formulated as usual.  Two
-   new values (RPCSEC_GSS_CREDPROBLEM and RPCSEC_GSS_CTXPROBLEM) have
-   been defined for the auth_stat type.  When the reason for denial of
-   the request is a reject_stat of AUTH_ERROR, one of the two new
-   auth_stat values could be returned in addition to the existing
-   values.  These two new values have special significance from the
-   existing reasons for denial of a request.
-
-   The server maintains a list of contexts for the clients that are
-   currently in session with it.  Normally, a context is destroyed when
-   the client ends the session corresponding to it.  However, due to
-   resource constraints, the server may destroy a context prematurely
-   (on an LRU basis, or if the server machine is rebooted, for example).
-   In this case, when a client request comes in, there may not be a
-   context corresponding to its handle. The server rejects the request,
-   with the reason RPCSEC_GSS_CREDPROBLEM in this case.  Upon receiving
-   this error, the client must refresh the context - that is,
-   reestablish it after destroying the old one - and try the request
-   again.  This error is also returned if the context handle matches
-   that of a different context that was allocated after the client's
-   context was destroyed (this will be detected by a failure in
-   verifying the header checksum).
-
-   If the GSS_VerifyMIC() call on the header checksum (contained in the
-   verifier) fails to return GSS_S_COMPLETE, the server rejects the
-   request and returns an auth_stat of RPCSEC_GSS_CREDPROBLEM.
-
-   When the client's sequence number exceeds the maximum the server will
-   allow, the server will reject the request with the reason
-   RPCSEC_GSS_CTXPROBLEM.  Also, if security credentials become stale
-   while in use (due to ticket expiry in the case of the Kerberos V5
-   mechanism, for example), the failures which result cause the
-   RPCSEC_GSS_CTXPROBLEM reason to be returned.  In these cases also,
-   the client must refresh the context, and retry the request.
-
-   For other errors, retrying will not rectify the problem and the
-   client must not refresh the context until the problem causing the
-   client request to be denied is rectified.
-
-   If the version field in the credential does not match the version of
-   RPCSEC_GSS that was used when the context was created, the
-   AUTH_BADCRED value is returned.
-
-   If there is a problem with the credential, such a bad length, illegal
-   control procedure, or an illegal service, the appropriate auth_stat
-   status is AUTH_BADCRED.
-
-
-
-Eisler, et. al.             Standards Track                    [Page 15]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-   Other errors can be returned as appropriate.
-
-5.3.3.4.  Mapping of GSS-API Errors to Server Responses
-
-   During the data exchange phase, the server may invoke GSS_GetMIC(),
-   GSS_VerifyMIC(), GSS_Unwrap(), and GSS_Wrap(). If any of these
-   routines fail to return GSS_S_COMPLETE, then various unsuccessful
-   responses can be returned. The are described as follows for each of
-   the aforementioned four interfaces.
-
-5.3.3.4.1.  GSS_GetMIC() Failure
-
-   When GSS_GetMIC() is called to generate the verifier in the response,
-   a failure results in an RPC response with a reply status of
-   MSG_DENIED, reject status of AUTH_ERROR and an auth status of
-   RPCSEC_GSS_CTXPROBLEM.
-
-   When GSS_GetMIC() is called to sign the call results (service is
-   rpc_gss_svc_integrity), a failure results in no RPC response being
-   sent. Since ONC RPC server applications will typically control when a
-   response is sent, the failure indication will be returned to the
-   server application and it can take appropriate action (such as
-   logging the error).
-
-5.3.3.4.2.  GSS_VerifyMIC() Failure
-
-   When GSS_VerifyMIC() is called to verify the verifier in request, a
-   failure results in an RPC response with a reply status of MSG_DENIED,
-   reject status of AUTH_ERROR and an auth status of
-   RPCSEC_GSS_CREDPROBLEM.
-
-   When GSS_VerifyMIC() is called to verify the call arguments (service
-   is rpc_gss_svc_integrity), a failure results in an RPC response with
-   a reply status of MSG_ACCEPTED, and an acceptance status of
-   GARBAGE_ARGS.
-
-5.3.3.4.3.  GSS_Unwrap() Failure
-
-   When GSS_Unwrap() is called to decrypt the call arguments (service is
-   rpc_gss_svc_privacy), a failure results in an RPC response with a
-   reply status of MSG_ACCEPTED, and an acceptance status of
-   GARBAGE_ARGS.
-
-5.3.3.4.4.  GSS_Wrap() Failure
-
-   When GSS_Wrap() is called to encrypt the call results (service is
-   rpc_gss_svc_privacy), a failure results in no RPC response being
-   sent. Since ONC RPC server applications will typically control when a
-
-
-
-Eisler, et. al.             Standards Track                    [Page 16]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-   response is sent, the failure indication will be returned to the
-   application and it can take appropriate action (such as logging the
-   error).
-
-5.4.  Context Destruction
-
-   When the client is done using the session, it must send a control
-   message informing the server that it no longer requires the context.
-   This message is formulated just like a data request packet, with the
-   following differences:  the credential has gss_proc set to
-   RPCSEC_GSS_DESTROY, the procedure specified in the header is
-   NULLPROC, and there are no procedure arguments.  The sequence number
-   in the request must be valid, and the header checksum in the verifier
-   must be valid, for the server to accept the message.  The server
-   sends a response as it would to a data request.  The client and
-   server must then destroy the context for the session.
-
-   If the request to destroy the context fails for some reason, the
-   client need not take any special action.  The server must be prepared
-   to deal with situations where clients never inform the server that
-   they no longer are in session and so don't need the server to
-   maintain a context.  An LRU mechanism or an aging mechanism should be
-   employed by the server to clean up in such cases.
-
-6.  Set of GSS-API Mechanisms
-
-   RPCSEC_GSS is effectively a "pass-through" to the GSS-API layer, and
-   as such it is inappropriate for the RPCSEC_GSS specification to
-   enumerate a minimum set of required security mechanisms and/or
-   quality of protections.
-
-   If an application protocol specification references RPCSEC_GSS, the
-   protocol specification must list a mandatory set of { mechanism, QOP,
-   service } triples, such that an implementation cannot claim
-   conformance to the protocol specification unless it implements the
-   set of triples. Within each triple, mechanism is a GSS-API security
-   mechanism, QOP is a valid quality-of-protection within the mechanism,
-   and service is either rpc_gss_svc_integrity or rpc_gss_svc_privacy.
-
-   For example, a network filing protocol built on RPC that depends on
-   RPCSEC_GSS for security, might require that Kerberos V5 with the
-   default QOP using the rpc_gss_svc_integrity service be supported by
-   implementations conforming to the network filing protocol
-   specification.
-
-
-
-
-
-
-
-Eisler, et. al.             Standards Track                    [Page 17]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-7.  Security Considerations
-
-7.1.  Privacy of Call Header
-
-   The reader will note that for the privacy option, only the call
-   arguments and results are encrypted. Information about the
-   application in the form of RPC program number, program version
-   number, and program procedure number is transmitted in the clear.
-   Encrypting these fields in the RPC call header would have changed the
-   size and format of the call header. This would have required revising
-   the RPC protocol which was beyond the scope of this proposal. Storing
-   the encrypted numbers in the credential would have obviated a
-   protocol change, but would have introduced more overloading of fields
-   and would have made implementations of RPC more complex. Even if the
-   fields were encrypted somehow, in most cases an attacker can
-   determine the program number and version number by examining the
-   destination address of the request and querying the rpcbind service
-   on the destination host [Srinivasan-bind].  In any case, even by not
-   encrypting the three numbers, RPCSEC_GSS still improves the state of
-   security over what existing RPC services have had available
-   previously. Implementors of new RPC services that are concerned about
-   this risk may opt to design in a "sub-procedure" field that is
-   included in the service specific call arguments.
-
-7.2.  Sequence Number Attacks
-
-7.2.1.  Sequence Numbers Above the Window
-
-   An attacker cannot coax the server into raising the sequence number
-   beyond the range the legitimate client is aware of (and thus engineer
-   a denial of server attack) without constructing an RPC request that
-   will pass the header checksum. If the cost of verifying the header
-   checksum is sufficiently large (depending on the speed of the
-   processor doing the checksum and the cost of checksum algorithm), it
-   is possible to envision a denial of service attack (vandalism, in the
-   form of wasting processing resources) whereby the attacker sends
-   requests that are above the window. The simplest method might be for
-   the attacker to monitor the network traffic and then choose a
-   sequence number that is far above the current sequence number. Then
-   the attacker can send bogus requests using the above window sequence
-   number.
-
-7.2.2.  Sequence Numbers Within or Below the Window
-
-   If the attacker sends requests that are within or below the window,
-   then even if the header checksum is successfully verified, the server
-   will silently discard the requests because the server assumes it has
-   already processed the request. In this case, a server can optimize by
-
-
-
-Eisler, et. al.             Standards Track                    [Page 18]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-   skipping the header checksum verification if the sequence number is
-   below the window, or if it is within the window, not attempt the
-   checksum verification if the sequence number has already been seen.
-
-7.3.  Message Stealing Attacks
-
-   This proposal does not address attacks where an attacker can block or
-   steal messages without being detected by the server. To implement
-   such protection would be tantamount to assuming a state in the RPC
-   service. RPCSEC_GSS does not worsen this situation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eisler, et. al.             Standards Track                    [Page 19]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-Appendix A. GSS-API Major Status Codes
-
-   The GSS-API definition [Linn] does not include numerical values for
-   the various GSS-API major status codes. It is expected that this will
-   be addressed in future RFC. Until then, this appendix defines the
-   values for each GSS-API major status code listed in the GSS-API
-   definition.  If in the future, the GSS-API definition defines values
-   for the codes that are different than what follows, then implementors
-   of RPCSEC_GSS will be obliged to map them into the values defined
-   below. If in the future, the GSS-API definition defines additional
-   status codes not defined below, then the RPCSEC_GSS definition will
-   subsume those additional values.
-
-   Here are the definitions of each GSS_S_* major status that the
-   implementor of RPCSEC_GSS can expect in the gss_major major field of
-   rpc_gss_init_res.  These definitions are not in RPC description
-   language form.  The numbers are in base 16 (hexadecimal):
-
-      GSS_S_COMPLETE                  0x00000000
-      GSS_S_CONTINUE_NEEDED           0x00000001
-      GSS_S_DUPLICATE_TOKEN           0x00000002
-      GSS_S_OLD_TOKEN                 0x00000004
-      GSS_S_UNSEQ_TOKEN               0x00000008
-      GSS_S_GAP_TOKEN                 0x00000010
-      GSS_S_BAD_MECH                  0x00010000
-      GSS_S_BAD_NAME                  0x00020000
-      GSS_S_BAD_NAMETYPE              0x00030000
-      GSS_S_BAD_BINDINGS              0x00040000
-      GSS_S_BAD_STATUS                0x00050000
-      GSS_S_BAD_MIC                   0x00060000
-      GSS_S_BAD_SIG                   0x00060000
-      GSS_S_NO_CRED                   0x00070000
-      GSS_S_NO_CONTEXT                0x00080000
-      GSS_S_DEFECTIVE_TOKEN           0x00090000
-      GSS_S_DEFECTIVE_CREDENTIAL      0x000a0000
-      GSS_S_CREDENTIALS_EXPIRED       0x000b0000
-      GSS_S_CONTEXT_EXPIRED           0x000c0000
-      GSS_S_FAILURE                   0x000d0000
-      GSS_S_BAD_QOP                   0x000e0000
-      GSS_S_UNAUTHORIZED              0x000f0000
-      GSS_S_UNAVAILABLE               0x00100000
-      GSS_S_DUPLICATE_ELEMENT         0x00110000
-      GSS_S_NAME_NOT_MN               0x00120000
-      GSS_S_CALL_INACCESSIBLE_READ    0x01000000
-      GSS_S_CALL_INACCESSIBLE_WRITE   0x02000000
-      GSS_S_CALL_BAD_STRUCTURE        0x03000000
-
-
-
-
-
-Eisler, et. al.             Standards Track                    [Page 20]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-   Note that the GSS-API major status is split into three fields as
-   follows:
-
-        Most Significant Bit                     Least Significant Bit
-        |------------------------------------------------------------|
-        | Calling Error | Routine Error  |    Supplementary Info     |
-        |------------------------------------------------------------|
-      Bit 31           24 23            16 15                        0
-
-   Up to one status in the Calling Error field can be logically ORed
-   with up to one status in the Routine Error field which in turn can be
-   logically ORed with zero or more statuses in the Supplementary Info
-   field. If the resulting major status has a non-zero Calling Error
-   and/or a non-zero Routine Error, then the applicable GSS-API
-   operation has failed.  For purposes of RPCSEC_GSS, this means that
-   the GSS_Accept_sec_context() call executed by the server has failed.
-
-   If the major status is equal GSS_S_COMPLETE, then this indicates the
-   absence of any Errors or Supplementary Info.
-
-   The meanings of most of the GSS_S_* status are defined in the GSS-API
-   definition, which the exceptions of:
-
-   GSS_S_BAD_MIC       This code has the same meaning as GSS_S_BAD_SIG.
-
-   GSS_S_CALL_INACCESSIBLE_READ
-                        A required input parameter could not be read.
-
-   GSS_S_CALL_INACCESSIBLE_WRITE
-                        A required input parameter could not be written.
-
-   GSS_S_CALL_BAD_STRUCTURE
-                       A parameter was malformed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eisler, et. al.             Standards Track                    [Page 21]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-Acknowledgements
-
-   Much of the protocol was based on the AUTH_GSSAPI security flavor
-   developed by Open Vision Technologies [Jaspan].  In particular, we
-   acknowledge Barry Jaspan, Marc Horowitz, John Linn, and Ellen
-   McDermott.
-
-   Raj Srinivasan designed RPCSEC_GSS [Eisler] with input from Mike
-   Eisler.  Raj, Roland Schemers, Lin Ling, and Alex Chiu contributed to
-   Sun Microsystems' implementation of RPCSEC_GSS.
-
-   Brent Callaghan, Marc Horowitz, Barry Jaspan, John Linn, Hilarie
-   Orman, Martin Rex, Ted Ts'o, and John Wroclawski analyzed the
-   specification and gave valuable feedback.
-
-   Steve Nahm and Kathy Slattery reviewed various drafts of this
-   specification.
-
-   Much of content of Appendix A was excerpted from John Wray's Work in
-   Progress on GSS-API Version 2 C-bindings.
-
-References
-
-   [Eisler]            Eisler, M., Schemers, R., and Srinivasan, R.
-                       (1996).  "Security Mechanism Independence in ONC
-                       RPC," Proceedings of the Sixth Annual USENIX
-                       Security Symposium, pp. 51-65.
-
-   [Jaspan]            Jaspan, B. (1995). "GSS-API Security for ONC
-                       RPC," `95 Proceedings of The Internet Society
-                       Symposium on Network and Distributed System
-                       Security, pp. 144- 151.
-
-   [Linn]              Linn, J., "Generic Security Service Application
-                       Program Interface, Version 2", RFC 2078, January
-                       1997.
-
-   [Srinivasan-bind]   Srinivasan, R., "Binding Protocols for
-                       ONC RPC Version 2", RFC 1833, August 1995.
-
-   [Srinivasan-rpc]    Srinivasan, R., "RPC: Remote Procedure Call
-                       Protocol Specification Version 2", RFC 1831,
-                       August 1995.
-
-   [Srinivasan-xdr]    Srinivasan, R., "XDR: External Data
-                       Representation Standard", RFC 1832, August 1995.
-
-
-
-
-
-Eisler, et. al.             Standards Track                    [Page 22]
-
-RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
-
-
-Authors' Addresses
-
-   Michael Eisler
-   Sun Microsystems, Inc.
-   M/S UCOS03
-   2550 Garcia Avenue
-   Mountain View, CA 94043
-
-   Phone: +1 (719) 599-9026
-   EMail: mre@eng.sun.com
-
-
-   Alex Chiu
-   Sun Microsystems, Inc.
-   M/S UMPK17-203
-   2550 Garcia Avenue
-   Mountain View, CA 94043
-
-   Phone: +1 (415) 786-6465
-   EMail: hacker@eng.sun.com
-
-
-   Lin Ling
-   Sun Microsystems, Inc.
-   M/S UMPK17-201
-   2550 Garcia Avenue
-   Mountain View, CA 94043
-
-   Phone: +1 (415) 786-5084
-   EMail: lling@eng.sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eisler, et. al.             Standards Track                    [Page 23]
-
diff --git a/doc/standardisation/rfc2228.txt b/doc/standardisation/rfc2228.txt
deleted file mode 100644
index 1fbfcbfa0..000000000
--- a/doc/standardisation/rfc2228.txt
+++ /dev/null
@@ -1,1515 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        M. Horowitz
-Request for Comments: 2228                              Cygnus Solutions
-Updates: 959                                                     S. Lunt
-Category: Standards Track                                       Bellcore
-                                                            October 1997
-
-                        FTP Security Extensions
-
-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 (1997).  All Rights Reserved.
-
-Abstract
-
-   This document defines extensions to the FTP specification STD 9, RFC
-   959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985).  These extensions
-   provide strong authentication, integrity, and confidentiality on both
-   the control and data channels with the introduction of new optional
-   commands, replies, and file transfer encodings.
-
-   The following new optional commands are introduced in this
-   specification:
-
-      AUTH (Authentication/Security Mechanism),
-      ADAT (Authentication/Security Data),
-      PROT (Data Channel Protection Level),
-      PBSZ (Protection Buffer Size),
-      CCC (Clear Command Channel),
-      MIC (Integrity Protected Command),
-      CONF (Confidentiality Protected Command), and
-      ENC (Privacy Protected Command).
-
-   A new class of reply types (6yz) is also introduced for protected
-   replies.
-
-   None of the above commands are required to be implemented, but
-   interdependencies exist.  These dependencies are documented with the
-   commands.
-
-   Note that this specification is compatible with STD 9, RFC 959.
-
-
-
-Horowitz & Lunt             Standards Track                     [Page 1]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-1.  Introduction
-
-   The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959
-   and in place on the Internet uses usernames and passwords passed in
-   cleartext to authenticate clients to servers (via the USER and PASS
-   commands).  Except for services such as "anonymous" FTP archives,
-   this represents a security risk whereby passwords can be stolen
-   through monitoring of local and wide-area networks.  This either aids
-   potential attackers through password exposure and/or limits
-   accessibility of files by FTP servers who cannot or will not accept
-   the inherent security risks.
-
-   Aside from the problem of authenticating users in a secure manner,
-   there is also the problem of authenticating servers, protecting
-   sensitive data and/or verifying its integrity.  An attacker may be
-   able to access valuable or sensitive data merely by monitoring a
-   network, or through active means may be able to delete or modify the
-   data being transferred so as to corrupt its integrity.  An active
-   attacker may also initiate spurious file transfers to and from a site
-   of the attacker's choice, and may invoke other commands on the
-   server.  FTP does not currently have any provision for the encryption
-   or verification of the authenticity of commands, replies, or
-   transferred data.  Note that these security services have value even
-   to anonymous file access.
-
-   Current practice for sending files securely is generally either:
-
-      1.  via FTP of files pre-encrypted under keys which are manually
-          distributed,
-
-      2.  via electronic mail containing an encoding of a file encrypted
-          under keys which are manually distributed,
-
-      3.  via a PEM message, or
-
-      4.  via the rcp command enhanced to use Kerberos.
-
-   None of these means could be considered even a de facto standard, and
-   none are truly interactive.  A need exists to securely transfer files
-   using FTP in a secure manner which is supported within the FTP
-   protocol in a consistent manner and which takes advantage of existing
-   security infrastructure and technology.  Extensions are necessary to
-   the FTP specification if these security services are to be introduced
-   into the protocol in an interoperable way.
-
-
-
-
-
-
-
-Horowitz & Lunt             Standards Track                     [Page 2]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-   Although the FTP control connection follows the Telnet protocol, and
-   Telnet has defined an authentication and encryption option [TELNET-
-   SEC], [RFC-1123] explicitly forbids the use of Telnet option
-   negotiation over the control connection (other than Synch and IP).
-
-   Also, the Telnet authentication and encryption option does not
-   provide for integrity protection only (without confidentiality), and
-   does not address the protection of the data channel.
-
-2.  FTP Security Overview
-
-   At the highest level, the FTP security extensions seek to provide an
-   abstract mechanism for authenticating and/or authorizing connections,
-   and integrity and/or confidentiality protecting commands, replies,
-   and data transfers.
-
-   In the context of FTP security, authentication is the establishment
-   of a client's identity and/or a server's identity in a secure way,
-   usually using cryptographic techniques.  The basic FTP protocol does
-   not have a concept of authentication.
-
-   Authorization is the process of validating a user for login.  The
-   basic authorization process involves the USER, PASS, and ACCT
-   commands.  With the FTP security extensions, authentication
-   established using a security mechanism may also be used to make the
-   authorization decision.
-
-   Without the security extensions, authentication of the client, as
-   this term is usually understood, never happens.  FTP authorization is
-   accomplished with a password, passed on the network in the clear as
-   the argument to the PASS command.  The possessor of this password is
-   assumed to be authorized to transfer files as the user named in the
-   USER command, but the identity of the client is never securely
-   established.
-
-   An FTP security interaction begins with a client telling the server
-   what security mechanism it wants to use with the AUTH command.  The
-   server will either accept this mechanism, reject this mechanism, or,
-   in the case of a server which does not implement the security
-   extensions, reject the command completely.  The client may try
-   multiple security mechanisms until it requests one which the server
-   accepts.  This allows a rudimentary form of negotiation to take
-   place.  (If more complex negotiation is desired, this may be
-   implemented as a security mechanism.)  The server's reply will
-   indicate if the client must respond with additional data for the
-
-
-
-
-
-
-Horowitz & Lunt             Standards Track                     [Page 3]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-   security mechanism to interpret.  If none is needed, this will
-   usually mean that the mechanism is one where the password (specified
-   by the PASS command) is to be interpreted differently, such as with a
-   token or one-time password system.
-
-   If the server requires additional security information, then the
-   client and server will enter into a security data exchange.  The
-   client will send an ADAT command containing the first block of
-   security data.  The server's reply will indicate if the data exchange
-   is complete, if there was an error, or if more data is needed.  The
-   server's reply can optionally contain security data for the client to
-   interpret.  If more data is needed, the client will send another ADAT
-   command containing the next block of data, and await the server's
-   reply.  This exchange can continue as many times as necessary.  Once
-   this exchange completes, the client and server have established a
-   security association.  This security association may include
-   authentication (client, server, or mutual) and keying information for
-   integrity and/or confidentiality, depending on the mechanism in use.
-
-   The term "security data" here is carefully chosen.  The purpose of
-   the security data exchange is to establish a security association,
-   which might not actually include any authentication at all, between
-   the client and the server as described above.  For instance, a
-   Diffie-Hellman exchange establishes a secret key, but no
-   authentication takes place.  If an FTP server has an RSA key pair but
-   the client does not, then the client can authenticate the server, but
-   the server cannot authenticate the client.
-
-   Once a security association is established, authentication which is a
-   part of this association may be used instead of or in addition to the
-   standard username/password exchange for authorizing a user to connect
-   to the server.  A username specified by the USER command is always
-   required to specify the identity to be used on the server.
-
-   In order to prevent an attacker from inserting or deleting commands
-   on the control stream, if the security association supports
-   integrity, then the server and client must use integrity protection
-   on the control stream, unless it first transmits a CCC command to
-   turn off this requirement.  Integrity protection is performed with
-   the MIC and ENC commands, and the 63z reply codes.  The CCC command
-   and its reply must be transmitted with integrity protection.
-   Commands and replies may be transmitted without integrity (that is,
-   in the clear or with confidentiality only) only if no security
-   association is established, the negotiated security association does
-   not support integrity, or the CCC command has succeeded.
-
-
-
-
-
-
-Horowitz & Lunt             Standards Track                     [Page 4]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-   Once the client and server have negotiated with the PBSZ command an
-   acceptable buffer size for encapsulating protected data over the data
-   channel, the security mechanism may also be used to protect data
-   channel transfers.
-
-   Policy is not specified by this document.  In particular, client and
-   server implementations may choose to implement restrictions on what
-   operations can be performed depending on the security association
-   which exists.  For example, a server may require that a client
-   authorize via a security mechanism rather than using a password,
-   require that the client provide a one-time password from a token,
-   require at least integrity protection on the command channel, or
-   require that certain files only be transmitted encrypted.  An
-   anonymous ftp client might refuse to do file transfers without
-   integrity protection in order to insure the validity of files
-   downloaded.
-
-   No particular set of functionality is required, except as
-   dependencies described in the next section.  This means that none of
-   authentication, integrity, or confidentiality are required of an
-   implementation, although a mechanism which does none of these is not
-   of much use.  For example, it is acceptable for a mechanism to
-   implement only integrity protection, one-way authentication and/or
-   encryption, encryption without any authentication or integrity
-   protection, or any other subset of functionality if policy or
-   technical considerations make this desirable.  Of course, one peer
-   might require as a matter of policy stronger protection than the
-   other is able to provide, preventing perfect interoperability.
-
-3.  New FTP Commands
-
-   The following commands are optional, but dependent on each other.
-   They are extensions to the FTP Access Control Commands.
-
-   The reply codes documented here are generally described as
-   recommended, rather than required.  The intent is that reply codes
-   describing the full range of success and failure modes exist, but
-   that servers be allowed to limit information presented to the client.
-   For example, a server might implement a particular security
-   mechanism, but have a policy restriction against using it.  The
-   server should respond with a 534 reply code in this case, but may
-   respond with a 504 reply code if it does not wish to divulge that the
-   disallowed mechanism is supported.  If the server does choose to use
-   a different reply code than the recommended one, it should try to use
-   a reply code which only differs in the last digit.  In all cases, the
-   server must use a reply code which is documented as returnable from
-   the command received, and this reply code must begin with the same
-   digit as the recommended reply code for the situation.
-
-
-
-Horowitz & Lunt             Standards Track                     [Page 5]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-   AUTHENTICATION/SECURITY MECHANISM (AUTH)
-
-      The argument field is a Telnet string identifying a supported
-      mechanism.  This string is case-insensitive.  Values must be
-      registered with the IANA, except that values beginning with "X-"
-      are reserved for local use.
-
-      If the server does not recognize the AUTH command, it must respond
-      with reply code 500.  This is intended to encompass the large
-      deployed base of non-security-aware ftp servers, which will
-      respond with reply code 500 to any unrecognized command.  If the
-      server does recognize the AUTH command but does not implement the
-      security extensions, it should respond with reply code 502.
-
-      If the server does not understand the named security mechanism, it
-      should respond with reply code 504.
-
-      If the server is not willing to accept the named security
-      mechanism, it should respond with reply code 534.
-
-      If the server is not able to accept the named security mechanism,
-      such as if a required resource is unavailable, it should respond
-      with reply code 431.
-
-      If the server is willing to accept the named security mechanism,
-      but requires security data, it must respond with reply code 334.
-
-      If the server is willing to accept the named security mechanism,
-      and does not require any security data, it must respond with reply
-      code 234.
-
-      If the server is responding with a 334 reply code, it may include
-      security data as described in the next section.
-
-      Some servers will allow the AUTH command to be reissued in order
-      to establish new authentication.  The AUTH command, if accepted,
-      removes any state associated with prior FTP Security commands.
-      The server must also require that the user reauthorize (that is,
-      reissue some or all of the USER, PASS, and ACCT commands) in this
-      case (see section 4 for an explanation of "authorize" in this
-      context).
-
-
-
-
-
-
-
-
-
-
-Horowitz & Lunt             Standards Track                     [Page 6]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-   AUTHENTICATION/SECURITY DATA (ADAT)
-
-      The argument field is a Telnet string representing base 64 encoded
-      security data (see Section 9, "Base 64 Encoding").  If a reply
-      code indicating success is returned, the server may also use a
-      string of the form "ADAT=base64data" as the text part of the reply
-      if it wishes to convey security data back to the client.
-
-      The data in both cases is specific to the security mechanism
-      specified by the previous AUTH command.  The ADAT command, and the
-      associated replies, allow the client and server to conduct an
-      arbitrary security protocol.  The security data exchange must
-      include enough information for both peers to be aware of which
-      optional features are available.  For example, if the client does
-      not support data encryption, the server must be made aware of
-      this, so it will know not to send encrypted command channel
-      replies.  It is strongly recommended that the security mechanism
-      provide sequencing on the command channel, to insure that commands
-      are not deleted, reordered, or replayed.
-
-      The ADAT command must be preceded by a successful AUTH command,
-      and cannot be issued once a security data exchange completes
-      (successfully or unsuccessfully), unless it is preceded by an AUTH
-      command to reset the security state.
-
-      If the server has not yet received an AUTH command, or if a prior
-      security data exchange completed, but the security state has not
-      been reset with an AUTH command, it should respond with reply code
-      503.
-
-      If the server cannot base 64 decode the argument, it should
-      respond with reply code 501.
-
-      If the server rejects the security data (if a checksum fails, for
-      instance), it should respond with reply code 535.
-
-      If the server accepts the security data, and requires additional
-      data, it should respond with reply code 335.
-
-      If the server accepts the security data, but does not require any
-      additional data (i.e., the security data exchange has completed
-      successfully), it must respond with reply code 235.
-
-      If the server is responding with a 235 or 335 reply code, then it
-      may include security data in the text part of the reply as
-      specified above.
-
-
-
-
-
-Horowitz & Lunt             Standards Track                     [Page 7]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-      If the ADAT command returns an error, the security data exchange
-      will fail, and the client must reset its internal security state.
-      If the client becomes unsynchronized with the server (for example,
-      the server sends a 234 reply code to an AUTH command, but the
-      client has more data to transmit), then the client must reset the
-      server's security state.
-
-   PROTECTION BUFFER SIZE (PBSZ)
-
-      The argument is a decimal integer representing the maximum size,
-      in bytes, of the encoded data blocks to be sent or received during
-      file transfer.  This number shall be no greater than can be
-      represented in a 32-bit unsigned integer.
-
-      This command allows the FTP client and server to negotiate a
-      maximum protected buffer size for the connection.  There is no
-      default size; the client must issue a PBSZ command before it can
-      issue the first PROT command.
-
-      The PBSZ command must be preceded by a successful security data
-      exchange.
-
-      If the server cannot parse the argument, or if it will not fit in
-      32 bits, it should respond with a 501 reply code.
-
-      If the server has not completed a security data exchange with the
-      client, it should respond with a 503 reply code.
-
-      Otherwise, the server must reply with a 200 reply code.  If the
-      size provided by the client is too large for the server, it must
-      use a string of the form "PBSZ=number" in the text part of the
-      reply to indicate a smaller buffer size.  The client and the
-      server must use the smaller of the two buffer sizes if both buffer
-      sizes are specified.
-
-   DATA CHANNEL PROTECTION LEVEL (PROT)
-
-      The argument is a single Telnet character code specifying the data
-      channel protection level.
-
-      This command indicates to the server what type of data channel
-      protection the client and server will be using.  The following
-      codes are assigned:
-
-         C - Clear
-         S - Safe
-         E - Confidential
-         P - Private
-
-
-
-Horowitz & Lunt             Standards Track                     [Page 8]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-      The default protection level if no other level is specified is
-      Clear.  The Clear protection level indicates that the data channel
-      will carry the raw data of the file transfer, with no security
-      applied.  The Safe protection level indicates that the data will
-      be integrity protected.  The Confidential protection level
-      indicates that the data will be confidentiality protected.  The
-      Private protection level indicates that the data will be integrity
-      and confidentiality protected.
-
-      It is reasonable for a security mechanism not to provide all data
-      channel protection levels.  It is also reasonable for a mechanism
-      to provide more protection at a level than is required (for
-      instance, a mechanism might provide Confidential protection, but
-      include integrity-protection in that encoding, due to API or other
-      considerations).
-
-      The PROT command must be preceded by a successful protection
-      buffer size negotiation.
-
-      If the server does not understand the specified protection level,
-      it should respond with reply code 504.
-
-      If the current security mechanism does not support the specified
-      protection level, the server should respond with reply code 536.
-
-      If the server has not completed a protection buffer size
-      negotiation with the client, it should respond with a 503 reply
-      code.
-
-      The PROT command will be rejected and the server should reply 503
-      if no previous PBSZ command was issued.
-
-      If the server is not willing to accept the specified protection
-      level, it should respond with reply code 534.
-
-      If the server is not able to accept the specified protection
-      level, such as if a required resource is unavailable, it should
-      respond with reply code 431.
-
-      Otherwise, the server must reply with a 200 reply code to indicate
-      that the specified protection level is accepted.
-
-   CLEAR COMMAND CHANNEL (CCC)
-
-      This command does not take an argument.
-
-
-
-
-
-
-Horowitz & Lunt             Standards Track                     [Page 9]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-      It is desirable in some environments to use a security mechanism
-      to authenticate and/or authorize the client and server, but not to
-      perform any integrity checking on the subsequent commands.  This
-      might be used in an environment where IP security is in place,
-      insuring that the hosts are authenticated and that TCP streams
-      cannot be tampered, but where user authentication is desired.
-
-      If unprotected commands are allowed on any connection, then an
-      attacker could insert a command on the control stream, and the
-      server would have no way to know that it was invalid.  In order to
-      prevent such attacks, once a security data exchange completes
-      successfully, if the security mechanism supports integrity, then
-      integrity (via the MIC or ENC command, and 631 or 632 reply) must
-      be used, until the CCC command is issued to enable non-integrity
-      protected control channel messages.  The CCC command itself must
-      be integrity protected.
-
-      Once the CCC command completes successfully, if a command is not
-      protected, then the reply to that command must also not be
-      protected.  This is to support interoperability with clients which
-      do not support protection once the CCC command has been issued.
-
-      This command must be preceded by a successful security data
-      exchange.
-
-      If the command is not integrity-protected, the server must respond
-      with a 533 reply code.
-
-      If the server is not willing to turn off the integrity
-      requirement, it should respond with a 534 reply code.
-
-      Otherwise, the server must reply with a 200 reply code to indicate
-      that unprotected commands and replies may now be used on the
-      command channel.
-
-   INTEGRITY PROTECTED COMMAND (MIC) and
-   CONFIDENTIALITY PROTECTED COMMAND (CONF) and
-   PRIVACY PROTECTED COMMAND (ENC)
-
-      The argument field of MIC is a Telnet string consisting of a base
-      64 encoded "safe" message produced by a security mechanism
-      specific message integrity procedure.  The argument field of CONF
-      is a Telnet string consisting of a base 64 encoded "confidential"
-      message produced by a security mechanism specific confidentiality
-      procedure.  The argument field of ENC is a Telnet string
-      consisting of a base 64 encoded "private" message produced by a
-      security mechanism specific message integrity and confidentiality
-      procedure.
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 10]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-      The server will decode and/or verify the encoded message.
-
-      This command must be preceded by a successful security data
-      exchange.
-
-      A server may require that the first command after a successful
-      security data exchange be CCC, and not implement the protection
-      commands at all.  In this case, the server should respond with a
-      502 reply code.
-
-      If the server cannot base 64 decode the argument, it should
-      respond with a 501 reply code.
-
-      If the server has not completed a security data exchange with the
-      client, it should respond with a 503 reply code.
-
-      If the server has completed a security data exchange with the
-      client using a mechanism which supports integrity, and requires a
-      CCC command due to policy or implementation limitations, it should
-      respond with a 503 reply code.
-
-      If the server rejects the command because it is not supported by
-      the current security mechanism, the server should respond with
-      reply code 537.
-
-      If the server rejects the command (if a checksum fails, for
-      instance), it should respond with reply code 535.
-
-      If the server is not willing to accept the command (if privacy is
-      required by policy, for instance, or if a CONF command is received
-      before a CCC command), it should respond with reply code 533.
-
-      Otherwise, the command will be interpreted as an FTP command.  An
-      end-of-line code need not be included, but if one is included, it
-      must be a Telnet end-of-line code, not a local end-of-line code.
-
-      The server may require that, under some or all circumstances, all
-      commands be protected.  In this case, it should make a 533 reply
-      to commands other than MIC, CONF, and ENC.
-
-4.  Login Authorization
-
-   The security data exchange may, among other things, establish the
-   identity of the client in a secure way to the server.  This identity
-   may be used as one input to the login authorization process.
-
-
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 11]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-   In response to the FTP login commands (AUTH, PASS, ACCT), the server
-   may choose to change the sequence of commands and replies specified
-   by RFC 959 as follows.  There are also some new replies available.
-
-   If the server is willing to allow the user named by the USER command
-   to log in based on the identity established by the security data
-   exchange, it should respond with reply code 232.
-
-   If the security mechanism requires a challenge/response password, it
-   should respond to the USER command with reply code 336.  The text
-   part of the reply should contain the challenge.  The client must
-   display the challenge to the user before prompting for the password
-   in this case.  This is particularly relevant to more sophisticated
-   clients or graphical user interfaces which provide dialog boxes or
-   other modal input.  These clients should be careful not to prompt for
-   the password before the username has been sent to the server, in case
-   the user needs the challenge in the 336 reply to construct a valid
-   password.
-
-5.  New FTP Replies
-
-   The new reply codes are divided into two classes.  The first class is
-   new replies made necessary by the new FTP Security commands.  The
-   second class is a new reply type to indicate protected replies.
-
-   5.1.  New individual reply codes
-
-      232 User logged in, authorized by security data exchange.
-      234 Security data exchange complete.
-      235 [ADAT=base64data]
-            ; This reply indicates that the security data exchange
-            ; completed successfully.  The square brackets are not
-            ; to be included in the reply, but indicate that
-            ; security data in the reply is optional.
-
-      334 [ADAT=base64data]
-            ; This reply indicates that the requested security mechanism
-            ; is ok, and includes security data to be used by the client
-            ; to construct the next command.  The square brackets are not
-            ; to be included in the reply, but indicate that
-            ; security data in the reply is optional.
-      335 [ADAT=base64data]
-            ; This reply indicates that the security data is
-            ; acceptable, and more is required to complete the
-            ; security data exchange.  The square brackets
-            ; are not to be included in the reply, but indicate
-            ; that security data in the reply is optional.
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 12]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-      336 Username okay, need password.  Challenge is "...."
-            ; The exact representation of the challenge should be chosen
-            ; by the mechanism to be sensible to the human user of the
-            ; system.
-
-      431 Need some unavailable resource to process security.
-
-      533 Command protection level denied for policy reasons.
-      534 Request denied for policy reasons.
-      535 Failed security check (hash, sequence, etc).
-      536 Requested PROT level not supported by mechanism.
-      537 Command protection level not supported by security mechanism.
-
-   5.2.  Protected replies.
-
-      One new reply type is introduced:
-
-         6yz   Protected reply
-
-            There are three reply codes of this type.  The first, reply
-            code 631 indicates an integrity protected reply.  The
-            second, reply code 632, indicates a confidentiality and
-            integrity protected reply.  the third, reply code 633,
-            indicates a confidentiality protected reply.
-
-            The text part of a 631 reply is a Telnet string consisting
-            of a base 64 encoded "safe" message produced by a security
-            mechanism specific message integrity procedure.  The text
-            part of a 632 reply is a Telnet string consisting of a base
-            64 encoded "private" message produced by a security
-            mechanism specific message confidentiality and integrity
-            procedure.  The text part of a 633 reply is a Telnet string
-            consisting of a base 64 encoded "confidential" message
-            produced by a security mechanism specific message
-            confidentiality procedure.
-
-            The client will decode and verify the encoded reply.  How
-            failures decoding or verifying replies are handled is
-            implementation-specific.  An end-of-line code need not be
-            included, but if one is included, it must be a Telnet end-
-            of-line code, not a local end-of-line code.
-
-            A protected reply may only be sent if a security data
-            exchange has succeeded.
-
-            The 63z reply may be a multiline reply.  In this case, the
-            plaintext reply must be broken up into a number of
-            fragments.  Each fragment must be protected, then base 64
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 13]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-            encoded in order into a separate line of the multiline
-            reply.  There need not be any correspondence between the
-            line breaks in the plaintext reply and the encoded reply.
-            Telnet end-of-line codes must appear in the plaintext of the
-            encoded reply, except for the final end-of-line code, which
-            is optional.
-
-            The multiline reply must be formatted more strictly than the
-            continuation specification in RFC 959.  In particular, each
-            line before the last must be formed by the reply code,
-            followed immediately by a hyphen, followed by a base 64
-            encoded fragment of the reply.
-
-            For example, if the plaintext reply is
-
-               123-First line
-               Second line
-                 234 A line beginning with numbers
-               123 The last line
-
-            then the resulting protected reply could be any of the
-            following (the first example has a line break only to fit
-            within the margins):
-
-  631 base64(protect("123-First line\r\nSecond line\r\n  234 A line
-  631-base64(protect("123-First line\r\n"))
-  631-base64(protect("Second line\r\n"))
-  631-base64(protect("  234 A line beginning with numbers\r\n"))
-  631 base64(protect("123 The last line"))
-
-  631-base64(protect("123-First line\r\nSecond line\r\n  234 A line b"))
-  631 base64(protect("eginning with numbers\r\n123 The last line\r\n"))
-
-6.  Data Channel Encapsulation
-
-   When data transfers are protected between the client and server (in
-   either direction), certain transformations and encapsulations must be
-   performed so that the recipient can properly decode the transmitted
-   file.
-
-   The sender must apply all protection services after transformations
-   associated with the representation type, file structure, and transfer
-   mode have been performed.  The data sent over the data channel is,
-   for the purposes of protection, to be treated as a byte stream.
-
-   When performing a data transfer in an authenticated manner, the
-   authentication checks are performed on individual blocks of the file,
-   rather than on the file as a whole. Consequently, it is possible for
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 14]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-   insertion attacks to insert blocks into the data stream (i.e.,
-   replays) that authenticate correctly, but result in a corrupted file
-   being undetected by the receiver. To guard against such attacks, the
-   specific security mechanism employed should include mechanisms to
-   protect against such attacks.  Many GSS-API mechanisms usable with
-   the specification in Appendix I, and the Kerberos mechanism in
-   Appendix II do so.
-
-   The sender must take the input byte stream, and break it up into
-   blocks such that each block, when encoded using a security mechanism
-   specific procedure, will be no larger than the buffer size negotiated
-   by the client with the PBSZ command.  Each block must be encoded,
-   then transmitted with the length of the encoded block prepended as a
-   four byte unsigned integer, most significant byte first.
-
-   When the end of the file is reached, the sender must encode a block
-   of zero bytes, and send this final block to the recipient before
-   closing the data connection.
-
-   The recipient will read the four byte length, read a block of data
-   that many bytes long, then decode and verify this block with a
-   security mechanism specific procedure.  This must be repeated until a
-   block encoding a buffer of zero bytes is received.  This indicates
-   the end of the encoded byte stream.
-
-   Any transformations associated with the representation type, file
-   structure, and transfer mode are to be performed by the recipient on
-   the byte stream resulting from the above process.
-
-   When using block transfer mode, the sender's (cleartext) buffer size
-   is independent of the block size.
-
-   The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or APPE
-   command if the current protection level is not at the level dictated
-   by the server's security requirements for the particular file
-   transfer.
-
-   If any data protection services fail at any time during data transfer
-   at the server end (including an attempt to send a buffer size greater
-   than the negotiated maximum), the server will send a 535 reply to the
-   data transfer command (either STOR, STOU, RETR, LIST, NLST, or APPE).
-
-
-
-
-
-
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 15]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-7.  Potential policy considerations
-
-   While there are no restrictions on client and server policy, there
-   are a few recommendations which an implementation should implement.
-
-    - Once a security data exchange takes place, a server should require
-      all commands be protected (with integrity and/or confidentiality),
-      and it should protect all replies.  Replies should use the same
-      level of protection as the command which produced them.  This
-      includes replies which indicate failure of the MIC, CONF, and ENC
-      commands.  In particular, it is not meaningful to require that
-      AUTH and ADAT be protected; it is meaningful and useful to require
-      that PROT and PBSZ be protected.  In particular, the use of CCC is
-      not recommended, but is defined in the interest of
-      interoperability between implementations which might desire such
-      functionality.
-
-    - A client should encrypt the PASS command whenever possible.  It is
-      reasonable for the server to refuse to accept a non-encrypted PASS
-      command if the server knows encryption is available.
-
-    - Although no security commands are required to be implemented, it
-      is recommended that an implementation provide all commands which
-      can be implemented, given the mechanisms supported and the policy
-      considerations of the site (export controls, for instance).
-
-8.  Declarative specifications
-
-   These sections are modelled after sections 5.3 and 5.4 of RFC 959,
-   which describe the same information, except for the standard FTP
-   commands and replies.
-
-   8.1.  FTP Security commands and arguments
-
-      AUTH <SP> <mechanism-name> <CRLF>
-      ADAT <SP> <base64data> <CRLF>
-      PROT <SP> <prot-code> <CRLF>
-      PBSZ <SP> <decimal-integer> <CRLF>
-      MIC <SP> <base64data> <CRLF>
-      CONF <SP> <base64data> <CRLF>
-      ENC <SP> <base64data> <CRLF>
-
-      <mechanism-name> ::= <string>
-      <base64data> ::= <string>
-              ; must be formatted as described in section 9
-      <prot-code> ::= C | S | E | P
-      <decimal-integer> ::= any decimal integer from 1 to (2^32)-1
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 16]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-   8.2.  Command-Reply sequences
-
-      Security Association Setup
-         AUTH
-            234
-            334
-            502, 504, 534, 431
-            500, 501, 421
-         ADAT
-            235
-            335
-            503, 501, 535
-            500, 501, 421
-      Data protection negotiation commands
-         PBSZ
-            200
-            503
-            500, 501, 421, 530
-         PROT
-            200
-            504, 536, 503, 534, 431
-            500, 501, 421, 530
-      Command channel protection commands
-         MIC
-            535, 533
-            500, 501, 421
-         CONF
-            535, 533
-            500, 501, 421
-         ENC
-            535, 533
-            500, 501, 421
-      Security-Enhanced login commands (only new replies listed)
-         USER
-            232
-            336
-      Data channel commands (only new replies listed)
-         STOR
-            534, 535
-         STOU
-            534, 535
-         RETR
-            534, 535
-
-
-
-
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 17]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-         LIST
-            534, 535
-         NLST
-            534, 535
-         APPE
-            534, 535
-
-      In addition to these reply codes, any security command can return
-      500, 501, 502, 533, or 421.  Any ftp command can return a reply
-      code encapsulated in a 631, 632, or 633 reply once a security data
-      exchange has completed successfully.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 18]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-9.  State Diagrams
-
-   This section includes a state diagram which demonstrates the flow of
-   authentication and authorization in a security enhanced FTP
-   implementation.  The rectangular blocks show states where the client
-   must issue a command, and the diamond blocks show states where the
-   server must issue a response.
-
-
-          ,------------------,  USER
-       __\| Unauthenticated  |_________\
-      |  /| (new connection) |         /|
-      |   `------------------'          |
-      |            |                    |
-      |            | AUTH               |
-      |            V                    |
-      |           / \                   |
-      | 4yz,5yz  /   \   234            |
-      |<--------<     >------------->.  |
-      |          \   /               |  |
-      |           \_/                |  |
-      |            |                 |  |
-      |            | 334             |  |
-      |            V                 |  |
-      |  ,--------------------,      |  |
-      |  | Need Security Data |<--.  |  |
-      |  `--------------------'   |  |  |
-      |            |              |  |  |
-      |            | ADAT         |  |  |
-      |            V              |  |  |
-      |           / \             |  |  |
-      | 4yz,5yz  /   \   335      |  |  |
-      `<--------<     >-----------'  |  |
-                 \   /               |  |
-                  \_/                |  |
-                   |                 |  |
-                   | 235             |  |
-                   V                 |  |
-           ,---------------.         |  |
-      ,--->| Authenticated |<--------'  |  After the client and server
-      |    `---------------'            |  have completed authenti-
-      |            |                    |  cation, command must be
-      |            | USER               |  integrity-protected if
-      |            |                    |  integrity is available.  The
-      |            |<-------------------'  CCC command may be issued to
-      |            V                       relax this restriction.
-
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 19]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-      |           / \
-      | 4yz,5yz  /   \   2yz
-      |<--------<     >------------->.
-      |          \   /               |
-      |           \_/                |
-      |            |                 |
-      |            | 3yz             |
-      |            V                 |
-      |    ,---------------.         |
-      |    | Need Password |         |
-      |    `---------------'         |
-      |            |                 |
-      |            | PASS            |
-      |            V                 |
-      |           / \                |
-      | 4yz,5yz  /   \   2yz         |
-      |<--------<     >------------->|
-      |          \   /               |
-      |           \_/                |
-      |            |                 |
-      |            | 3yz             |
-      |            V                 |
-      |    ,--------------.          |
-      |    | Need Account |          |
-      |    `--------------'          |
-      |            |                 |
-      |            | ACCT            |
-      |            V                 |
-      |           / \                |
-      | 4yz,5yz  /   \   2yz         |
-      `<--------<     >------------->|
-                 \   /               |
-                  \_/                |
-                   |                 |
-                   | 3yz             |
-                   V                 |
-             ,-------------.         |
-             | Authorized  |/________|
-             | (Logged in) |\
-             `-------------'
-
-
-
-
-
-
-
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 20]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-10.  Base 64 Encoding
-
-   Base 64 encoding is the same as the Printable Encoding described in
-   Section 4.3.2.4 of [RFC-1421], except that line breaks must not be
-   included. This encoding is defined as follows.
-
-   Proceeding from left to right, the bit string resulting from the
-   mechanism specific protection routine is encoded into characters
-   which are universally representable at all sites, though not
-   necessarily with the same bit patterns (e.g., although the character
-   "E" is represented in an ASCII-based system as hexadecimal 45 and as
-   hexadecimal C5 in an EBCDIC-based system, the local significance of
-   the two representations is equivalent).
-
-   A 64-character subset of International Alphabet IA5 is used, enabling
-   6 bits to be represented per printable character.  (The proposed
-   subset of characters is represented identically in IA5 and ASCII.)
-   The character "=" signifies a special processing function used for
-   padding within the printable encoding procedure.
-
-   The encoding process represents 24-bit groups of input bits as output
-   strings of 4 encoded characters.  Proceeding from left to right
-   across a 24-bit input group output from the security mechanism
-   specific message protection procedure, each 6-bit group is used as an
-   index into an array of 64 printable characters, namely "[A-Z][a-
-   z][0-9]+/".  The character referenced by the index is placed in the
-   output string.  These characters are selected so as to be universally
-   representable, and the set excludes characters with particular
-   significance to Telnet (e.g., "<CR>", "<LF>", IAC).
-
-   Special processing is performed if fewer than 24 bits are available
-   in an input group at the end of a message.  A full encoding quantum
-   is always completed at the end of a message.  When fewer than 24
-   input bits are available in an input group, zero bits are added (on
-   the right) to form an integral number of 6-bit groups.  Output
-   character positions which are not required to represent actual input
-   data are set to the character "=".  Since all canonically encoded
-   output is an integral number of octets, only the following cases can
-   arise: (1) the final quantum of encoding input is an integral
-   multiple of 24 bits; here, the final unit of encoded output will be
-   an integral multiple of 4 characters with no "=" padding, (2) the
-   final quantum of encoding input is exactly 8 bits; here, the final
-   unit of encoded output will be two characters followed by two "="
-   padding characters, or (3) the final quantum of encoding input is
-   exactly 16 bits; here, the final unit of encoded output will be three
-   characters followed by one "=" padding character.
-
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 21]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-   Implementors must keep in mind that the base 64 encodings in ADAT,
-   MIC, CONF, and ENC commands, and in 63z replies may be arbitrarily
-   long.  Thus, the entire line must be read before it can be processed.
-   Several successive reads on the control channel may be necessary.  It
-   is not appropriate to for a server to reject a command containing a
-   base 64 encoding simply because it is too long (assuming that the
-   decoding is otherwise well formed in the context in which it was
-   sent).
-
-   Case must not be ignored when reading commands and replies containing
-   base 64 encodings.
-
-11.  Security Considerations
-
-   This entire document deals with security considerations related to
-   the File Transfer Protocol.
-
-   Third party file transfers cannot be secured using these extensions,
-   since a security context cannot be established between two servers
-   using these facilities (no control connection exists between servers
-   over which to pass ADAT tokens).  Further work in this area is
-   deferred.
-
-12.  Acknowledgements
-
-   I would like to thank the members of the CAT WG, as well as all
-   participants in discussions on the "cat-ietf@mit.edu" mailing list,
-   for their contributions to this document.  I would especially like to
-   thank Sam Sjogren, John Linn, Ted Ts'o, Jordan Brown, Michael Kogut,
-   Derrick Brashear, John Gardiner Myers, Denis Pinkas, and Karri Balk
-   for their contributions to this work.  Of course, without Steve Lunt,
-   the author of the first six revisions of this document, it would not
-   exist at all.
-
-13.  References
-
-   [TELNET-SEC] Borman, D., "Telnet Authentication and Encryption
-      Option", Work in Progress.
-
-   [RFC-1123] Braden, R., "Requirements for Internet Hosts --
-      Application and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic
-      Mail: Part I: Message Encryption and Authentication Procedures",
-      RFC 1421, February 1993.
-
-
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 22]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-14.  Author's Address
-
-   Marc Horowitz
-   Cygnus Solutions
-   955 Massachusetts Avenue
-   Cambridge, MA 02139
-
-   Phone: +1 617 354 7688
-   EMail: marc@cygnus.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 23]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-Appendix I: Specification under the GSSAPI
-
-   In order to maximise the utility of new security mechanisms, it is
-   desirable that new mechanisms be implemented as GSSAPI mechanisms
-   rather than as FTP security mechanisms.  This will enable existing
-   ftp implementations to support the new mechanisms more easily, since
-   little or no code will need to be changed.  In addition, the
-   mechanism will be usable by other protocols, such as IMAP, which are
-   built on top of the GSSAPI, with no additional specification or
-   implementation work needed by the mechanism designers.
-
-   The security mechanism name (for the AUTH command) associated with
-   all mechanisms employing the GSSAPI is GSSAPI.  If the server
-   supports a security mechanism employing the GSSAPI, it must respond
-   with a 334 reply code indicating that an ADAT command is expected
-   next.
-
-   The client must begin the authentication exchange by calling
-   GSS_Init_Sec_Context, passing in 0 for input_context_handle
-   (initially), and a targ_name equal to output_name from
-   GSS_Import_Name called with input_name_type of Host-Based Service and
-   input_name_string of "ftp@hostname" where "hostname" is the fully
-   qualified host name of the server with all letters in lower case.
-   (Failing this, the client may try again using input_name_string of
-   "host@hostname".) The output_token must then be base 64 encoded and
-   sent to the server as the argument to an ADAT command.  If
-   GSS_Init_Sec_Context returns GSS_S_CONTINUE_NEEDED, then the client
-   must expect a token to be returned in the reply to the ADAT command.
-   This token must subsequently be passed to another call to
-   GSS_Init_Sec_Context.  In this case, if GSS_Init_Sec_Context returns
-   no output_token, then the reply code from the server for the previous
-   ADAT command must have been 235.  If GSS_Init_Sec_Context returns
-   GSS_S_COMPLETE, then no further tokens are expected from the server,
-   and the client must consider the server authenticated.
-
-   The server must base 64 decode the argument to the ADAT command and
-   pass the resultant token to GSS_Accept_Sec_Context as input_token,
-   setting acceptor_cred_handle to NULL (for "use default credentials"),
-   and 0 for input_context_handle (initially).  If an output_token is
-   returned, it must be base 64 encoded and returned to the client by
-   including "ADAT=base64string" in the text of the reply.  If
-   GSS_Accept_Sec_Context returns GSS_S_COMPLETE, the reply code must be
-   235, and the server must consider the client authenticated.  If
-   GSS_Accept_Sec_Context returns GSS_S_CONTINUE_NEEDED, the reply code
-   must be 335.  Otherwise, the reply code should be 535, and the text
-   of the reply should contain a descriptive error message.
-
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 24]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-   The chan_bindings input to GSS_Init_Sec_Context and
-   GSS_Accept_Sec_Context should use the client internet address and
-   server internet address as the initiator and acceptor addresses,
-   respectively.  The address type for both should be GSS_C_AF_INET. No
-   application data should be specified.
-
-   Since GSSAPI supports anonymous peers to security contexts, it is
-   possible that the client's authentication of the server does not
-   actually establish an identity.
-
-   The procedure associated with MIC commands, 631 replies, and Safe
-   file transfers is:
-
-      GSS_Wrap for the sender, with conf_flag == FALSE
-
-      GSS_Unwrap for the receiver
-
-   The procedure associated with ENC commands, 632 replies, and Private
-   file transfers is:
-
-      GSS_Wrap for the sender, with conf_flag == TRUE
-      GSS_Unwrap for the receiver
-
-   CONF commands and 633 replies are not supported.
-
-   Both the client and server should inspect the value of conf_avail to
-   determine whether the peer supports confidentiality services.
-
-   When the security state is reset (when AUTH is received a second
-   time, or when REIN is received), this should be done by calling the
-   GSS_Delete_sec_context function.
-
-Appendix II:  Specification under Kerberos version 4
-
-   The security mechanism name (for the AUTH command) associated with
-   Kerberos Version 4 is KERBEROS_V4.  If the server supports
-   KERBEROS_V4, it must respond with a 334 reply code indicating that an
-   ADAT command is expected next.
-
-   The client must retrieve a ticket for the Kerberos principal
-   "ftp.hostname@realm" by calling krb_mk_req(3) with a principal name
-   of "ftp", an instance equal to the first part of the canonical host
-   name of the server with all letters in lower case (as returned by
-   krb_get_phost(3)), the server's realm name (as returned by
-   krb_realmofhost(3)), and an arbitrary checksum.  The ticket must then
-   be base 64 encoded and sent as the argument to an ADAT command.
-
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 25]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-   If the "ftp" principal name is not a registered principal in the
-   Kerberos database, then the client may fall back on the "rcmd"
-   principal name (same instance and realm).  However, servers must
-   accept only one or the other of these principal names, and must not
-   be willing to accept either.  Generally, if the server has a key for
-   the "ftp" principal in its srvtab, then that principal only must be
-   used, otherwise the "rcmd" principal only must be used.
-
-   The server must base 64 decode the argument to the ADAT command and
-   pass the result to krb_rd_req(3).  The server must add one to the
-   checksum from the authenticator, convert the result to network byte
-   order (most significant byte first), and sign it using
-   krb_mk_safe(3), and base 64 encode the result.  Upon success, the
-   server must reply to the client with a 235 code and include
-   "ADAT=base64string" in the text of the reply.  Upon failure, the
-   server should reply 535.
-
-   Upon receipt of the 235 reply from the server, the client must parse
-   the text of the reply for the base 64 encoded data, decode it,
-   convert it from network byte order, and pass the result to
-   krb_rd_safe(3).  The client must consider the server authenticated if
-   the resultant checksum is equal to one plus the value previously
-   sent.
-
-   The procedure associated with MIC commands, 631 replies, and Safe
-   file transfers is:
-
-      krb_mk_safe(3) for the sender
-      krb_rd_safe(3) for the receiver
-
-   The procedure associated with ENC commands, 632 replies, and Private
-   file transfers is:
-
-      krb_mk_priv(3) for the sender
-      krb_rd_priv(3) for the receiver
-
-   CONF commands and 633 replies are not supported.
-
-   Note that this specification for KERBEROS_V4 contains no provision
-   for negotiating alternate means for integrity and confidentiality
-   routines.  Note also that the ADAT exchange does not convey whether
-   the peer supports confidentiality services.
-
-   In order to stay within the allowed PBSZ, implementors must take note
-   that a cleartext buffer will grow by 31 bytes when processed by
-   krb_mk_safe(3) and will grow by 26 bytes when processed by
-   krb_mk_priv(3).
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 26]
-
-RFC 2228                FTP Security Extensions             October 1997
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1997).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implmentation may be prepared, copied, published
-   andand distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Horowitz & Lunt             Standards Track                    [Page 27]
-
diff --git a/doc/standardisation/rfc2253.txt b/doc/standardisation/rfc2253.txt
deleted file mode 100644
index a7439eed7..000000000
--- a/doc/standardisation/rfc2253.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            M. Wahl
-Request for Comments: 2253                           Critical Angle Inc.
-Obsoletes: 1779                                                 S. Kille
-Category: Standards Track                                     Isode Ltd.
-                                                                T. Howes
-                                           Netscape Communications Corp.
-                                                           December 1997
-
-
-              Lightweight Directory Access Protocol (v3):
-           UTF-8 String Representation of Distinguished Names
-
-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 (1997).  All Rights Reserved.
-
-IESG Note
-
-   This document describes a directory access protocol that provides
-   both read and update access.  Update access requires secure
-   authentication, but this document does not mandate implementation of
-   any satisfactory authentication mechanisms.
-
-   In accordance with RFC 2026, section 4.4.1, this specification is
-   being approved by IESG as a Proposed Standard despite this
-   limitation, for the following reasons:
-
-   a. to encourage implementation and interoperability testing of
-      these protocols (with or without update access) before they
-      are deployed, and
-
-   b. to encourage deployment and use of these protocols in read-only
-      applications.  (e.g. applications where LDAPv3 is used as
-      a query language for directories which are updated by some
-      secure mechanism other than LDAP), and
-
-   c. to avoid delaying the advancement and deployment of other Internet
-      standards-track protocols which require the ability to query, but
-      not update, LDAPv3 directory servers.
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 1]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-   Readers are hereby warned that until mandatory authentication
-   mechanisms are standardized, clients and servers written according to
-   this specification which make use of update functionality are
-   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
-   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
-
-   Implementors are hereby discouraged from deploying LDAPv3 clients or
-   servers which implement the update functionality, until a Proposed
-   Standard for mandatory authentication in LDAPv3 has been approved and
-   published as an RFC.
-
-Abstract
-
-   The X.500 Directory uses distinguished names as the primary keys to
-   entries in the directory.  Distinguished Names are encoded in ASN.1
-   in the X.500 Directory protocols.  In the Lightweight Directory
-   Access Protocol, a string representation of distinguished names is
-   transferred.  This specification defines the string format for
-   representing names, which is designed to give a clean representation
-   of commonly used distinguished names, while being able to represent
-   any distinguished name.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [6].
-
-1.  Background
-
-   This specification assumes familiarity with X.500 [1], and the
-   concept of Distinguished Name.  It is important to have a common
-   format to be able to unambiguously represent a distinguished name.
-   The primary goal of this specification is ease of encoding and
-   decoding.  A secondary goal is to have names that are human readable.
-   It is not expected that LDAP clients with a human user interface
-   would display these strings directly to the user, but would most
-   likely be performing translations (such as expressing attribute type
-   names in one of the local national languages).
-
-2.  Converting DistinguishedName from ASN.1 to a String
-
-   In X.501 [2] the ASN.1 structure of distinguished name is defined as:
-
-       DistinguishedName ::= RDNSequence
-
-       RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 2]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-       RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
-        AttributeTypeAndValue
-
-       AttributeTypeAndValue ::= SEQUENCE {
-        type  AttributeType,
-        value AttributeValue }
-
-   The following sections define the algorithm for converting from an
-   ASN.1 structured representation to a UTF-8 string representation.
-
-2.1. Converting the RDNSequence
-
-   If the RDNSequence is an empty sequence, the result is the empty or
-   zero length string.
-
-   Otherwise, the output consists of the string encodings of each
-   RelativeDistinguishedName in the RDNSequence (according to 2.2),
-   starting with the last element of the sequence and moving backwards
-   toward the first.
-
-   The encodings of adjoining RelativeDistinguishedNames are separated
-   by a comma character (',' ASCII 44).
-
-2.2.  Converting RelativeDistinguishedName
-
-   When converting from an ASN.1 RelativeDistinguishedName to a string,
-   the output consists of the string encodings of each
-   AttributeTypeAndValue (according to 2.3), in any order.
-
-   Where there is a multi-valued RDN, the outputs from adjoining
-   AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
-   character.
-
-2.3.  Converting AttributeTypeAndValue
-
-   The AttributeTypeAndValue is encoded as the string representation of
-   the AttributeType, followed by an equals character ('=' ASCII 61),
-   followed by the string representation of the AttributeValue.  The
-   encoding of the AttributeValue is given in section 2.4.
-
-   If the AttributeType is in a published table of attribute types
-   associated with LDAP [4], then the type name string from that table
-   is used, otherwise it is encoded as the dotted-decimal encoding of
-   the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is
-   described in [3].  As an example, strings for a few of the attribute
-   types frequently seen in RDNs include:
-
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 3]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-                    String  X.500 AttributeType
-                    ------------------------------
-                    CN      commonName
-                    L       localityName
-                    ST      stateOrProvinceName
-                    O       organizationName
-                    OU      organizationalUnitName
-                    C       countryName
-                    STREET  streetAddress
-                    DC      domainComponent
-                    UID     userid
-
-2.4.  Converting an AttributeValue from ASN.1 to a String
-
-   If the AttributeValue is of a type which does not have a string
-   representation defined for it, then it is simply encoded as an
-   octothorpe character ('#' ASCII 35) followed by the hexadecimal
-   representation of each of the bytes of the BER encoding of the X.500
-   AttributeValue.  This form SHOULD be used if the AttributeType is of
-   the dotted-decimal form.
-
-   Otherwise, if the AttributeValue is of a type which has a string
-   representation, the value is converted first to a UTF-8 string
-   according to its syntax specification (see for example section 6 of
-   [4]).
-
-   If the UTF-8 string does not have any of the following characters
-   which need escaping, then that string can be used as the string
-   representation of the value.
-
-    o   a space or "#" character occurring at the beginning of the
-        string
-
-    o   a space character occurring at the end of the string
-
-    o   one of the characters ",", "+", """, "\", "<", ">" or ";"
-
-   Implementations MAY escape other characters.
-
-   If a character to be escaped is one of the list shown above, then it
-   is prefixed by a backslash ('\' ASCII 92).
-
-   Otherwise the character to be escaped is replaced by a backslash and
-   two hex digits, which form a single byte in the code of the
-   character.
-
-   Examples of the escaping mechanism are shown in section 5.
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 4]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-3. Parsing a String back to a Distinguished Name
-
-   The structure of the string is specified in a BNF grammar, based on
-   the grammar defined in RFC 822 [5].  Server implementations parsing a
-   DN string generated by an LDAPv2 client MUST also accept (and ignore)
-   the variants given in section 4 of this document.
-
-distinguishedName = [name]                    ; may be empty string
-
-name       = name-component *("," name-component)
-
-name-component = attributeTypeAndValue *("+" attributeTypeAndValue)
-
-attributeTypeAndValue = attributeType "=" attributeValue
-
-attributeType = (ALPHA 1*keychar) / oid
-keychar    = ALPHA / DIGIT / "-"
-
-oid        = 1*DIGIT *("." 1*DIGIT)
-
-attributeValue = string
-
-string     = *( stringchar / pair )
-             / "#" hexstring
-             / QUOTATION *( quotechar / pair ) QUOTATION ; only from v2
-
-quotechar     = <any character except "\" or QUOTATION >
-
-special    = "," / "=" / "+" / "<" /  ">" / "#" / ";"
-
-pair       = "\" ( special / "\" / QUOTATION / hexpair )
-stringchar = <any character except one of special, "\" or QUOTATION >
-
-hexstring  = 1*hexpair
-hexpair    = hexchar hexchar
-
-hexchar    = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
-             / "a" / "b" / "c" / "d" / "e" / "f"
-
-ALPHA      =  <any ASCII alphabetic character>
-                                         ; (decimal 65-90 and 97-122)
-DIGIT      =  <any ASCII decimal digit>  ; (decimal 48-57)
-QUOTATION  =  <the ASCII double quotation mark character '"' decimal 34>
-
-
-
-
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 5]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-4.  Relationship with RFC 1779 and LDAPv2
-
-   The syntax given in this document is more restrictive than the syntax
-   in RFC 1779.  Implementations parsing a string generated by an LDAPv2
-   client MUST accept the syntax of RFC 1779.  Implementations MUST NOT,
-   however, generate any of the RFC 1779 encodings which are not
-   described above in section 2.
-
-   Implementations MUST allow a semicolon character to be used instead
-   of a comma to separate RDNs in a distinguished name, and MUST also
-   allow whitespace characters to be present on either side of the comma
-   or semicolon.  The whitespace characters are ignored, and the
-   semicolon replaced with a comma.
-
-   Implementations MUST allow an oid in the attribute type to be
-   prefixed by one of the character strings "oid." or "OID.".
-
-   Implementations MUST allow for space (' ' ASCII 32) characters to be
-   present between name-component and ',', between attributeTypeAndValue
-   and '+', between attributeType and '=', and between '=' and
-   attributeValue.  These space characters are ignored when parsing.
-
-   Implementations MUST allow a value to be surrounded by quote ('"'
-   ASCII 34) characters, which are not part of the value.  Inside the
-   quoted value, the following characters can occur without any
-   escaping:
-
-                   ",", "=", "+", "<", ">", "#" and ";"
-
-5.  Examples
-
-   This notation is designed to be convenient for common forms of name.
-   This section gives a few examples of distinguished names written
-   using this notation.  First is a name containing three relative
-   distinguished names (RDNs):
-
-   CN=Steve Kille,O=Isode Limited,C=GB
-
-   Here is an example name containing three RDNs, in which the first RDN
-   is multi-valued:
-
-   OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
-
-   This example shows the method of quoting of a comma in an
-   organization name:
-
-   CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 6]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-   An example name in which a value contains a carriage return
-   character:
-
-   CN=Before\0DAfter,O=Test,C=GB
-
-   An example name in which an RDN was of an unrecognized type.  The
-   value is the BER encoding of an OCTET STRING containing two bytes
-   0x48 and 0x69.
-
-   1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
-
-   Finally, an example of an RDN surname value consisting of 5 letters:
-
-   Unicode Letter Description      10646 code UTF-8  Quoted
-   =============================== ========== ====== =======
-   LATIN CAPITAL LETTER L          U0000004C  0x4C   L
-   LATIN SMALL LETTER U            U00000075  0x75   u
-   LATIN SMALL LETTER C WITH CARON U0000010D  0xC48D \C4\8D
-   LATIN SMALL LETTER I            U00000069  0x69   i
-   LATIN SMALL LETTER C WITH ACUTE U00000107  0xC487 \C4\87
-
-   Could be written in printable ASCII (useful for debugging purposes):
-
-   SN=Lu\C4\8Di\C4\87
-
-6.  References
-
-   [1] The Directory -- overview of concepts, models and services.
-       ITU-T Rec. X.500(1993).
-
-   [2] The Directory -- Models. ITU-T Rec. X.501(1993).
-
-   [3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
-       Access  Protocol (v3)", RFC 2251, December 1997.
-
-   [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
-       Directory Access Protocol (v3): Attribute Syntax Definitions",
-       RFC 2252, December 1997.
-
-   [5] Crocker, D., "Standard of the Format of ARPA-Internet Text
-       Messages", STD 11, RFC 822, August 1982.
-
-   [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
-       Levels", RFC 2119.
-
-
-
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 7]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-7.  Security Considerations
-
-7.1. Disclosure
-
-   Distinguished Names typically consist of descriptive information
-   about the entries they name, which can be people, organizations,
-   devices or other real-world objects.  This frequently includes some
-   of the following kinds of information:
-
-   - the common name of the object (i.e. a person's full name)
-   - an email or TCP/IP address
-   - its physical location (country, locality, city, street address)
-   - organizational attributes (such as department name or affiliation)
-
-   Most countries have privacy laws regarding the publication of
-   information about people.
-
-7.2. Use of Distinguished Names in Security Applications
-
-   The transformations of an AttributeValue value from its X.501 form to
-   an LDAP string representation are not always reversible back to the
-   same BER or DER form.  An example of a situation which requires the
-   DER form of a distinguished name is the verification of an X.509
-   certificate.
-
-   For example, a distinguished name consisting of one RDN with one AVA,
-   in which the type is commonName and the value is of the TeletexString
-   choice with the letters 'Sam' would be represented in LDAP as the
-   string CN=Sam.  Another distinguished name in which the value is
-   still 'Sam' but of the PrintableString choice would have the same
-   representation CN=Sam.
-
-   Applications which require the reconstruction of the DER form of the
-   value SHOULD NOT use the string representation of attribute syntaxes
-   when converting a distinguished name to the LDAP format.  Instead,
-   they SHOULD use the hexadecimal form prefixed by the octothorpe ('#')
-   as described in the first paragraph of section 2.4.
-
-8.  Authors' Addresses
-
-   Mark Wahl
-   Critical Angle Inc.
-   4815 W. Braker Lane #502-385
-   Austin, TX 78759
-   USA
-
-   EMail:  M.Wahl@critical-angle.com
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 8]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-   Steve Kille
-   Isode Ltd.
-   The Dome
-   The Square
-   Richmond, Surrey
-   TW9 1DT
-   England
-
-   Phone:  +44-181-332-9091
-   EMail:  S.Kille@ISODE.COM
-
-
-   Tim Howes
-   Netscape Communications Corp.
-   501 E. Middlefield Rd, MS MV068
-   Mountain View, CA 94043
-   USA
-
-   Phone:  +1 650 937-3419
-   EMail:   howes@netscape.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 9]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-9.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1997).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al.              Proposed Standard                   [Page 10]
-
diff --git a/doc/standardisation/rfc2478.txt b/doc/standardisation/rfc2478.txt
deleted file mode 100644
index 83395577d..000000000
--- a/doc/standardisation/rfc2478.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         E. Baize
-Request for Comments: 2478                                   D. Pinkas
-Category: Standards Track                                         Bull
-                                                         December 1998
-
-
-         The Simple and Protected GSS-API Negotiation Mechanism
-
-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 (1998).  All Rights Reserved.
-
-1.  ABSTRACT
-
-   This document specifies a Security Negotiation Mechanism for the
-   Generic Security Service Application Program Interface (GSS-API)
-   which is described in [1].
-
-   The GSS-API provides a generic interface which can be layered atop
-   different security mechanisms such that if communicating peers
-   acquire GSS-API credentials for the same security mechanism, then a
-   security context may be established between them (subject to policy).
-   However, GSS-API doesn't prescribe the method by which GSS-API peers
-   can establish whether they have a common security mechanism.
-
-   The Simple and Protected GSS-API Negotiation Mechanism defined here
-   is a pseudo-security mechanism, represented by the object identifier
-   iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which
-   enables GSS-API peers to determine in-band whether their credentials
-   share common GSS-API security mechanism(s), and if so, to invoke
-   normal security context establishment for a selected common security
-   mechanism. This is most useful for applications that are based on
-   GSS-API implementations which support multiple security mechanisms.
-
-   This allows to negotiate different security mechanisms, different
-   options within a given security mechanism or different options from
-   several security mechanisms.
-
-
-
-
-
-
-Baize & Pinkas              Standards Track                     [Page 1]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-   Once the common security mechanism is identified, the security
-   mechanism may also negotiate mechanism-specific options during its
-   context establishment. This will be inside the mechanism tokens, and
-   invisible to the SPNEGO protocol.
-
-   The simple and protected GSS-API mechanism negotiation is based on
-   the following negotiation model : the initiator proposes one security
-   mechanism or an ordered list of security mechanisms, the target
-   either accepts the proposed security mechanism, or chooses one from
-   an offered set, or rejects the proposed value(s). The target then
-   informs the initiator of its choice.
-
-   In its basic form this protocol requires an extra-round trip. Network
-   connection setup is a critical performance characteristic of any
-   network infrastructure and extra round trips over WAN links, packet
-   radio networks, etc. really make a difference. In order to avoid such
-   an extra round trip the initial security token of the preferred
-   mechanism for the initiator may be embedded in the initial token. If
-   the target preferred mechanism matches the initiator's preferred
-   mechanism, no additional round trips are incurred by using the
-   negotiation protocol.
-
-   The simple and protected GSS-API mechanism negotiation provides a
-   technique to protect the negotiation that must be used when the
-   underlying mechanism selected by the target is capable of integrity
-   protection.
-
-   When all the mechanisms proposed by the initiator support integrity
-   protection or when the selected mechanism supports integrity
-   protection, then the negotiation mechanism becomes protected since
-   this guarantees that the appropriate mechanism supported by both
-   peers has been selected.
-
-   The Simple and Protected GSS-API Negotiation Mechanism uses the
-   concepts developed in the GSS-API specification [1]. The negotiation
-   data is encapsulated in context-level tokens. Therefore, callers of
-   the GSS-API do not need to be aware of the existence of the
-   negotiation tokens but only of the new pseudo-security mechanism. A
-   failure in the negotiation phase causes a major status code to be
-   returned: GSS_S_BAD_MECH.
-
-
-
-
-
-
-
-
-
-
-
-Baize & Pinkas              Standards Track                     [Page 2]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-2.  NEGOTIATION MODEL
-
-2.1.  Negotiation description
-
-   The model for security mechanism negotiation reuses a subset of the
-   concepts specified in [2].
-
-   Each OID represents one GSS-API mechanism or one variant of it.
-
-    -  When one security mechanism is proposed by the initiator, it
-       represents the only security mechanism supported or selected
-       (when the additional APIs defined in the Annex A are used) by the
-       initiator.
-
-    -  When several security mechanisms are proposed by the initiator,
-       they represent a set of security mechanisms supported or selected
-       (when the additional APIs defined in the Annex A are used) by the
-       initiator.
-
-   The first negotiation token sent by the initiator contains an ordered
-   list of mechanisms, a set of options (e.g. deleg, replay, conf flags)
-   that should be supported by the selected mechanism and optionally the
-   initial security token for the desired mechanism of the initiator
-   (i.e. the first of the list).
-
-   The first negotiation token sent by the target contains the result of
-   the negotiation (accept_completed, accept_incomplete or reject) and,
-   in case of accept, the agreed security mechanism. It may also include
-   the response to the initial security token from the initiator, when
-   the first proposed mechanism of the initiator has been selected. When
-   the first mechanism is acceptable to the target,it should respond to
-   the initial security token for the desired mechanism of the initiator
-   when it is present. However, if this is not possible, the target can
-   simply ignore it and omit the responseToken from the first reply.
-
-   Implementations that can piggyback the initial token will be rewarded
-   by faster connection setup.
-
-   In case of a successful negotiation, the security mechanism
-   represents the value suitable for the target, and picked up from the
-   list offered by the initiator.  The policy by which the target
-   chooses a mechanism is an implementation-specific local matter.  In
-   the absence of other policy, the target should chose the first
-   mechanism in the list for which valid credentials are available.
-
-   Once a mechanism has been selected, the tokens specific to the
-   selected mechanism are carried within the negotiation tokens (in the
-   mechToken for the initiator and in the responseToken for the target).
-
-
-
-Baize & Pinkas              Standards Track                     [Page 3]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-2.2.  Negotiation procedure
-
-   The negotiation procedure is summarised as follows:
-
-   (a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but
-       requests (either explicitly, with the negotiation mechanism, or
-       through accepting a default, when the default is the negotiation
-       mechanism) that the Simple and Protected GSS-API Negotiation
-       Mechanism be used;
-
-   (b) the initiator GSS-API implementation emits a negotiation token
-       containing a list of supported security mechanisms for the
-       credentials used for this context establishment, and optionally
-       an initial security token for the first mechanism from that list
-       (i.e. the preferred mechanism), and indicates
-       GSS_S_CONTINUE_NEEDED status;
-
-   (c) The GSS-API initiator sends the token to the target application;
-
-   (d) The GSS-API target deposits the token through invoking
-       GSS_Accept_sec_context. The target GSS-API implementation emits a
-       negotiation token containing which if any of the proposed
-       mechanisms it supports (or has selected).
-
-   If the mechanism selected by the target matches the preferred
-   mechanism identified by the initiator and the initiator provides a
-   mechToken, the negotiation token response may contain also an initial
-   security token from that mechanism.
-
-   If the preferred mechanism is accepted, GSS_Accept_sec_context()
-   indicates GSS_S_COMPLETE when unilateral or mutual authentication has
-   been performed and involves a single token in either direction.
-
-   If a proposed mechanism is accepted, and it was not the preferred
-   mechanism, or if the first negotiation token sent by the initiator
-   did not included a mechToken, then the negotiation token response
-   sent by the target may contain also a response token from that
-   mechanism which transmits mechanism-specific information (e.g. to
-   transmit a certificate). The initiator may ignore such an initial
-   token if it is not prepared to process it.
-
-   If a proposed mechanism other than the preferred mechanism is
-   accepted, or the preferred mechanism is accepted but involves
-   multiple exchanges (e.g. challenge-response authentication), then
-   GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED status.
-
-
-
-
-
-
-Baize & Pinkas              Standards Track                     [Page 4]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-   If the proposed mechanism(s) are rejected, GSS_Accept_sec_context()
-   indicates GSS_S_BAD_MECH status. The security context initialisation
-   has failed.
-
-   (e) The GSS-API target returns the token to the initiator
-       application;
-
-   (f) The GSS-API initiator deposits the token through invoking
-       GSS_Init_sec_context.
-
-   GSS_Init_sec_context() may then indicate GSS_S_CONTINUE_NEEDED,
-   GSS_S_COMPLETE or GSS_S_BAD_MECH status.
-
-      The GSS_S_BAD_MECH status is returned when the negotiation token
-      carries a reject result or when the negotiation token carries an
-      accept result and the mechanism selected by the target is not
-      included in the initial list sent by the initiator.
-
-      The GSS_S_BAD_MIC status is returned when the selected mechanism
-      supports a MIC token but the MIC computed over the list of
-      mechanisms sent by the initiator is missing or incorrect.
-
-      If the negotiation token carries a reject result, the context
-      establishment is impossible. For example, a rejection will occur
-      if the target doesn't support the initiator's proposed mechanism
-      type(s). Upon failure of the mechanism negotiation procedure, the
-      mech_type output parameter value is the negotiation mechanism
-      type.
-
-      The GSS_S_CONTINUE_NEEDED status is returned when the negotiation
-      token carries an accept result and further tokens must be
-      transferred in order to complete context establishment for the
-      selected mechanism. In that case GSS_Init_sec_context() returns an
-      initial context token as output_token (with the selected
-      mechanism's context token encapsulated within that output_token).
-
-      The initiator then sends the output_token to the target. The
-      security context initialisation is then continued according to the
-      standard GSS-API conventions for the selected mechanism, where the
-      tokens of the selected mechanism are encapsulated until the
-      GSS_S_COMPLETE is returned for both the initiator and the target.
-      When GSS_S_CONTINUE_NEEDED is returned, the mech_type output
-      parameter is not yet valid.
-
-      When GSS_S_COMPLETE is returned, the mech_type output parameter
-      indicates the selected mechanism. When the final negotiation token
-      does not contain a MIC, the initiator GSS-API implementation must
-      check the returned/selected mechanism is on the originally
-
-
-
-Baize & Pinkas              Standards Track                     [Page 5]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-      submitted list of mechanisms and also verify that the selected
-      mechanism is not able to support a MIC. When the final negotiation
-      token contains a MIC over the initial mechanisms list sent by the
-      initiator, the MIC must be verified.
-
-   Note that the *_req_flag input parameters for context establishment
-   are relative to the selected mechanism, as are the *_state output
-   parameters. i.e., these parameters are not applicable to the
-   negotiation process per se.
-
-   The initiator GSS-API calling application may need to know when the
-   negotiation exchanges were protected or not. For this, when
-   GSS_S_COMPLETE is returned, it can simply test the integ_avail flag.
-   When this flag is set it indicates that the negotiation was
-   protected.
-
-   On receipt of a negotiation token on the target side, a GSS-API
-   implementation that does not support negotiation would indicate the
-   GSS_S_BAD_MECH status as if a particular basic security mechanism had
-   been requested but was not supported.
-
-   When GSS_Acquire_cred is invoked with the negotiation mechanism as
-   desired_mechs, an implementation-specific default credential is used
-   to carry on the negotiation. A set of mechanisms as specified locally
-   by the system administrator is then available for negotiation. If
-   there is a desire for the caller to make its own choice, then an
-   additional API has to be used (see Appendix A).
-
-3.  DATA ELEMENTS
-
-3.1.  Mechanism Type
-
-   MechType::= OBJECT IDENTIFIER
-
-   mechType
-        Each security mechanism is as defined in [1].
-
-3.2.  Negotiation Tokens
-
-   The syntax of the negotiation tokens follows the InitialContextToken
-   syntax defined in [1]. The security mechanism of the initial
-   negotiation token is identified by the Object Identifier
-   iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).
-
-
-
-
-
-
-
-
-Baize & Pinkas              Standards Track                     [Page 6]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-3.2.1. Syntax
-
-   This section specifies the syntax of the corresponding
-   "innerContextToken" field for the first token and subsequent
-   negotiation tokens. During the mechanism negociation, the
-   "innerContextToken" field contains the ASN.1 structure
-   "NegociationToken" given below, encoded using the DER encoding
-   conventions.
-
-NegotiationToken ::= CHOICE {
-                              negTokenInit  [0]  NegTokenInit,
-                              negTokenTarg  [1]  NegTokenTarg }
-
-MechTypeList ::= SEQUENCE OF MechType
-
-NegTokenInit ::= SEQUENCE {
-                            mechTypes       [0] MechTypeList  OPTIONAL,
-                            reqFlags        [1] ContextFlags  OPTIONAL,
-                            mechToken       [2] OCTET STRING  OPTIONAL,
-                            mechListMIC     [3] OCTET STRING  OPTIONAL
-                         }
-
-ContextFlags ::= BIT STRING {
-        delegFlag       (0),
-        mutualFlag      (1),
-        replayFlag      (2),
-        sequenceFlag    (3),
-        anonFlag        (4),
-        confFlag        (5),
-        integFlag       (6)
-}
-
-negTokenInit
-     Negotiation token sent by the initiator to the target, which
-     contains, for the first token sent, one or more security mechanisms
-     supported by the initiator (as indicated in the field mechTypes)
-     and the service options (reqFlags) that are requested to establish
-     the context. The context flags should be filled in from the
-     req_flags parameter of init_sec_context().
-
-     The mechToken field is optional for the first token sent that all
-     target implementations would not have to support. However for those
-     targets that do support piggybacking the initial mechToken, an
-     optimistic negotiation response is possible. Otherwise the
-     mechToken is used to carry the tokens specific to the mechanism
-     selected.
-
-
-
-
-
-Baize & Pinkas              Standards Track                     [Page 7]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-     The mechListMIC is an optional field. In the case that the chosen
-     mechanism supports integrity, the initiator may optionally include
-     a mechListMIC which is the result of a GetMIC of the MechTypes in
-     the initial NegTokenInit and return GSS_S_COMPLETE.
-
-     When the chosen mechanism uses an odd number of messages, the final
-     mechanism token will be sent from the initiator to the acceptor. In
-     this case, there is a tradeoff between using the optimal number of
-     messages, or using an additional message from the acceptor to the
-     initiator in order to give the initiator assurance that no
-     modification of the initiator's mechanism list occurred. The
-     implementation can choose which tradeoff to make (see section 4.2.2
-     for further details for the processing of that field).
-
-NegTokenTarg ::= SEQUENCE {
-    negResult      [0] ENUMERATED {
-                            accept_completed    (0),
-                            accept_incomplete   (1),
-                            reject              (2) }          OPTIONAL,
-    supportedMech  [1] MechType                                OPTIONAL,
-    responseToken  [2] OCTET STRING                            OPTIONAL,
-    mechListMIC    [3] OCTET STRING                            OPTIONAL
-}
-
-negTokenTarg
-     Negotiation token returned by the target to the initiator which
-     contains, for the first token returned, a global negotiation result
-     and the security mechanism selected (if any).
-
-negResult
-     The result accept_completed indicates that a context has been
-     successfully established, while the result accept_incomplete
-     indicates that additional token exchanges are needed.
-
-          Note: For the case where (a) a single-token context setup is
-          used and (b) the preferred mechanism does not support the
-          integrity facility which would cause a mechListMIC to be
-          generated and enclosed, this feature allows to make a
-          difference between a mechToken sent by the initiator but not
-          processed by the target (accept_incomplete) and a mechToken
-          sent by the initiator and processed by the target
-          (accept_completed).
-
-     For those targets that support piggybacking the initial mechToken,
-     an optimistic negotiation response is possible and includes in that
-     case a responseToken which may continue the authentication exchange
-     (e.g. when mutual authentication has been requested or when
-     unilateral authentication requires several round trips). Otherwise
-
-
-
-Baize & Pinkas              Standards Track                     [Page 8]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-     the responseToken is used to carry the tokens specific to the
-     mechanism selected. For subsequent tokens (if any) returned by the
-     target, negResult, and supportedMech are not present.
-
-     For the last token returned by the target, the mechListMIC, when
-     present, is a MIC computed over the MechTypes using the selected
-     mechanism.
-
-negResult
-     Result of the negotiation exchange, specified by the target.
-
-     This can be either :
-
-          accept_completed
-               The target accepts the preferred security mechanism,
-                and the context is established for the target or,
-
-          accept_incomplete
-               The target accepts one of the proposed security
-               mechanisms and further exchanges are necessary, or,
-
-          reject
-               The target rejects all the proposed security
-               mechanisms.
-
-supportedMech
-     This field has to be present when negResult is "accept_completed"
-     or "accept_incomplete". It is a choice from the mechanisms offered
-     by the initiator.
-
-responseToken
-     This field may be used either to transmit the response to the
-     mechToken when sent by the initiator and when the first mechanism
-     from the list has been selected by the target or to carry the
-     tokens specific to the selected security mechanism.
-
-mechListMIC
-     If the selected mechanism is capable of integrity protection, this
-     field must be present in the last message of the negotiation,
-     (i.e., when the underlying mechanism returns a non-empty token and
-     a major status of GSS_S_COMPLETE); it contains the result of a
-     GetMIC of the MechTypes field in the initial NegTokenInit.  It
-     allows to verify that the list initially sent by the initiator has
-     been received unmodified by the target.
-
-
-
-
-
-
-
-Baize & Pinkas              Standards Track                     [Page 9]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-3.2.2. Processing of mechListMIC.
-
-   If the mechanism selected by the negotiation does not support
-   integrity, then no mechListMIC is included, otherwise a mechListMIC
-   must be used and validated as indicated below.
-
-   If the mechanism supports integrity and uses an even number of
-   messages, then the target must compute a MIC as described above, and
-   send this in the final NegTokenTarg along with the final mechToken.
-   The initiator when receiving the last token must require that the
-   mechListMIC field be present and valid. In the absence of a valid
-   mechListMIC, the negotiation must fail as if the last context
-   establishment token was invalid.
-
-   In the case that the chosen mechanism supports integrity and uses an
-   odd number of messages, the final mechanism token will be sent from
-   the initiator to the target. In this case, there is a tradeoff
-   between using the optimal number of messages, or using an additional
-   message from the target to the initiator in order to give the
-   initiator assurance that no modification of the initiator's mechanism
-   list occurred. The implementation can choose which tradeoff to make.
-
-   When generating the final NegTokenInit message, the NegTokenInit may
-   optionally include a mechListMIC which is the result of a GetMIC of
-   the MechTypes in the initial NegTokenInit and return GSS_S_COMPLETE.
-   The target must check the presence of the MIC computed over the
-   mechList sent in the initial NegTokenInit. Three cases may then be
-   considered:
-
-      1) If the mechListMIC is present and correct, then
-         GSS_S_COMPLETE is returned to the target with no token; the
-         context is established by the target.
-
-      2) If the mechListMIC is present but invalid, then the context
-         establishment must fail.  An error major status code is
-         returned to the target.
-
-      3) If the mechListMIC is not included in the final NegTokenInit,
-         then GSS_S_COMPLETE must be returned to the target with a
-         token. This token must be a NegTokenTarg, with a MIC included
-         as described above, and no responseToken.  The application will
-         then send this token back to the initiator, which must verify
-         that the mechListMIC field is present and valid.
-
-
-
-
-
-
-
-
-Baize & Pinkas              Standards Track                    [Page 10]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-         Note: If the MIC was originally sent by the initiator, but
-                thenafter deleted by an attacker, the target will send
-                back a token according to the description above, but the
-                initiator will be unable to process that returned token
-                and the context establishment must then fail.
-
-4.  EXAMPLES : SECURITY MECHANISM NEGOTIATION
-
-   Here are some examples of security mechanism negotiation between an
-   initiator (I) and a target (T).
-
-4.1.  Initial steps
-
-   (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
-
-   (I) invokes GSS_Init_sec_context() with :
-
-   Input
-     mech_type = OID for negotiation mechanism or NULL, if the
-     negotiation mechanism is the default mechanism.
-
-   Output
-     major_status = GSS_S_CONTINUE_NEEDED
-     output_token = negTokenInit
-
-   The negotiation token (negTokenInit) contains two security mechanisms
-   with :
-     mechType = GSS-MECH1 or
-     mechType = GSS-MECH2
-
-   (I) sends to (T) the negotiation token.
-
-4.2  Successful negotiation steps
-
-   (T) supports GSS-MECH2
-   (T) receives the negotiation token (negTokenInit) from (I)
-   (T) invokes GSS_Accept_sec_context() with :
-
-   Input
-        input_token = negTokenInit
-
-   Output
-        major_status = GSS_S_CONTINUE_NEEDED
-        output_token = negTokenTarg
-
-   The negotiation token (negTokenTarg) contains :
-        negResult = accept (the negotiation result)
-        supportedMech : mechType = GSS-MECH2
-
-
-
-Baize & Pinkas              Standards Track                    [Page 11]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-   (T) returns the negotiation token (negTokenTarg) to (I)
-   (I) invokes GSS_Init_sec_context() with :
-
-   Input
-        input_token = negTokenTarg
-
-   Output
-        major_status = GSS_S_COMPLETE
-        output_token = initialContextToken (initial context token
-                                            for GSS-MECH2)
-        mech_type = GSS-MECH2
-
-   The subsequent steps are security mechanism specific, and work as
-   specified in [1].  The output tokens from the security mechanism are
-   encapsulated in a NegTokenTarg message (with the supportedMech field
-   omitted, and the mechListMIC included with the last token).
-
-4.3.  Failed negotiation steps
-
-   (T) supports GSS-MECH3.
-   (T) receives the negotiation token (negTokenInit) from (I)
-   (T) invokes GSS_Accept_sec_context() with :
-
-   Input
-        input_token = negTokenInit
-
-   Output
-        major_status = GSS_S_BAD_MECH
-        output_token = negTokenTarg
-
-   The negotiation token (negTokenTarg) contains :
-
-        negResult = reject (the negotiation result)
-
-   (T) returns the negotiation token (negTokenTarg) to (I)
-   (I) invokes GSS_Init_sec_context() with :
-
-   Input
-        input_token = negTokenTarg
-
-   Output
-        major_status = GSS_S_BAD_MECH
-
-   The security context establishment has failed.
-
-
-
-
-
-
-
-Baize & Pinkas              Standards Track                    [Page 12]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-4.4 Successful Negotiation with preferred mechanism info
-
-   (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
-
-   (I) invokes GSS_Init_sec_context() with :
-
-   Input
-        mech_type = OID for negotiation mechanism or NULL, if the
-        negotiation mechanism is the default mechanism.
-
-   Output
-        major_status = GSS_S_CONTINUE_NEEDED
-        output_token = negTokenInit
-
-   The negotiation token (negTokenInit) contains two security mechanisms
-   with :
-        mechType = GSS-MECH1 or
-        mechType = GSS-MECH2
-
-        mechToken = output_token from GSS_Init_sec_context
-       ( first mechType) as described in [1]
-
-   (I) sends to (T) the negotiation token.
-
-   (T) supports GSS-MECH1.
-   (T) receives the negotiation token (negTokenInit) from (I)
-   (T) invokes GSS_Accept_sec_context() with :
-
-   Input
-        input_token = negTokenInit
-
-   Output
-        major_status = GSS_S_CONTINUE_NEEDED
-        output_token = negTokenTarg
-
-   The negotiation token (negTokenTarg) contains :
-        negResult = accept (the negotiation result)
-        supportedMech : mechType = GSS-MECH1
-
-        mechToken = output_token from
-                         GSS_Accept_sec_context(mechToken )
-
-   (T) returns the negotiation token (negTokenTarg) to (I)
-   (I) invokes GSS_Init_sec_context() with :
-
-   Input
-        input_token = negTokenTarg
-
-
-
-
-Baize & Pinkas              Standards Track                    [Page 13]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-   Output
-        major_status = GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED as needed
-        output_token = ContextToken (initial or subsequent context token
-                       for GSS-MECH1)
-        mech_type = GSS-MECH1
-
-   Specific implementations of the protocol can support the optimistic
-   negotiation by completing the security context establishment using the
-   agreed upon mechanism as described in [1].  As described above in
-   section 5.2, the output tokens from the security mechanisms are
-   encapsulated in a NegTokenTarg message (with the negResult and
-   supportedMech fields omitted, and the mechListMIC included with the
-   last token).
-
-5.  SECURITY CONSIDERATIONS
-
-   When the mechanism selected by the target from the list supplied by
-   the initiator supports integrity protection, then the negotiation is
-   protected.
-
-   When one of the mechanisms proposed by the initiator does not support
-   integrity protection, then the negotiation is exposed to all threats
-   a non secured service is exposed. In particular, an active attacker
-   can force to use a security mechanism which is not the common
-   preferred one (when multiple security mechanisms are shared between
-   peers) but which is acceptable anyway to the target.
-
-   In any case, the communicating peers may be exposed to the denial of
-   service threat.
-
-6.  ACKNOWLEDGMENTS
-
-   Acknowledgments are due to Stephen Farrell of SSE, Marc Horowitz of
-   Stonecast, John Linn of RSA Laboratories, Piers McMahon of Platinum
-   Technology, Tom Parker of ICL and Doug Rosenthal of EINet, for
-   reviewing earlier versions of this document and for providing useful
-   inputs. Acknowledgments are also due to Peter Brundrett of Microsoft
-   for his proposal for an optimistic negotiation, and for Bill
-   Sommerfeld of Epilogue Technology for his proposal for protecting the
-   negotiation.
-
-
-
-
-
-
-
-
-
-
-
-Baize & Pinkas              Standards Track                    [Page 14]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-APPENDIX A
-
-
-   GSS-API NEGOTIATION SUPPORT API
-
-   In order to provide to a GSS-API caller (either the initiator or the
-   target or both) the ability to choose among the set of supported
-   mechanisms a reduced set of mechanisms for negotiation, two
-   additional APIs are defined:
-
-   GSS_Get_neg_mechs() indicates the set of security mechanisms
-   available on the local system to the caller for negotiation.
-
-   GSS_Set_neg_mechs() specifies the set of security mechanisms to be
-   used on the local system by the caller for negotiation.
-
-A.1.  GSS_Set_neg_mechs call
-
-   Input:
-        cred_handle          CREDENTIAL HANDLE
-                             - NULL specifies default credentials
-        mech_set             SET OF OBJECT IDENTIFIER
-
-   Outputs:
-        major_status INTEGER,
-        minor_status INTEGER,
-
-   Return major_status codes :
-     GSS_S_COMPLETE indicates that the set of security mechanisms
-     available for negotiation has been set to mech_set. GSS_S_FAILURE
-     indicates that the requested operation could not be performed for
-     reasons unspecified at the GSS-API level.
-
-   Allows callers to specify the set of security mechanisms that may be
-   negotiated with the credential identified by cred_handle. This call
-   is intended for support of specialised callers who need to restrict
-   the set of negotiable security mechanisms from the set of all
-   security mechanisms available to the caller (based on available
-   credentials). Note that if more than one mechanism is specified in
-   mech_set, the order in which those mechanisms are specified implies a
-   relative mechanism preference for the target.
-
-
-
-
-
-
-
-
-
-
-Baize & Pinkas              Standards Track                    [Page 15]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-A.2.  GSS_Get_neg_mechs call
-
-   Input:
-        cred_handle    CREDENTIAL HANDLE
-                       - NULL specifies default credentials
-
-   Outputs:
-        major_status INTEGER,
-        minor_status INTEGER,
-        mech_set     SET OF OBJECT IDENTIFIER
-
-   Return major_status codes :
-        GSS_S_COMPLETE indicates that the set of security mechanisms
-        available for negotiation has been returned in
-        mech_option_set.
-        GSS_S_FAILURE indicates that the requested operation could not
-        be performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to determine the set of security mechanisms available
-   for negotiation with the credential identified by cred_handle. This
-   call is intended for support of specialised callers who need to
-   reduce the set of negotiable security mechanisms from the set of
-   supported security mechanisms available to the caller (based on
-   available credentials).
-
-   Note: The GSS_Indicate_mechs() function indicates the full set of
-   mechanism types available on the local system. Since this call has no
-   input parameter, the returned set is not necessarily available for
-   all credentials.
-
-REFERENCES
-
-   [1] Linn, J., "Generic Security Service Application Program
-       Interface", RFC 2078, January 1997.
-
-   [2] Standard ECMA-206, "Association Context Management including
-       Security Context Management", December 1993.  Available on
-       http://www.ecma.ch
-
-
-
-
-
-
-
-
-
-
-
-
-
-Baize & Pinkas              Standards Track                    [Page 16]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-AUTHORS' ADDRESSES
-
-   Eric Baize
-   Bull - 300 Concord Road
-   Billerica, MA 01821 - USA
-
-   Phone: +1 978 294 61 37
-   Fax: +1 978 294 61 09
-   EMail: Eric.Baize@bull.com
-
-
-   Denis Pinkas
-   Bull
-   Rue Jean-Jaures
-   BP 68
-   78340 Les Clayes-sous-Bois - FRANCE
-
-   Phone: +33 1 30 80 34 87
-   Fax: +33 1 30 80 33 21
-   EMail: Denis.Pinkas@bull.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Baize & Pinkas              Standards Track                    [Page 17]
-
-RFC 2478             GSS-API Negotiation Mechanism         December 1998
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Baize & Pinkas              Standards Track                    [Page 18]
-
diff --git a/doc/standardisation/rfc2743.txt b/doc/standardisation/rfc2743.txt
deleted file mode 100644
index e5da571ab..000000000
--- a/doc/standardisation/rfc2743.txt
+++ /dev/null
@@ -1,5659 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            J. Linn
-Request for Comments: 2743                              RSA Laboratories
-Obsoletes: 2078                                             January 2000
-Category: Standards Track
-
-
-         Generic Security Service Application Program Interface
-                          Version 2, Update 1
-
-
-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 (2000).  All Rights Reserved.
-
-Abstract
-
-   The Generic Security Service Application Program Interface (GSS-API),
-   Version 2, as defined in [RFC-2078], provides security services to
-   callers in a generic fashion, supportable with a range of underlying
-   mechanisms and technologies and hence allowing source-level
-   portability of applications to different environments. This
-   specification defines GSS-API services and primitives at a level
-   independent of underlying mechanism and programming language
-   environment, and is to be complemented by other, related
-   specifications:
-
-      documents defining specific parameter bindings for particular
-      language environments
-
-      documents defining token formats, protocols, and procedures to be
-      implemented in order to realize GSS-API services atop particular
-      security mechanisms
-
-   This memo obsoletes [RFC-2078], making specific, incremental changes
-   in response to implementation experience and liaison requests. It is
-   intended, therefore, that this memo or a successor version thereto
-   will become the basis for subsequent progression of the GSS-API
-   specification on the standards track.
-
-
-
-
-
-Linn                        Standards Track                     [Page 1]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-TABLE OF CONTENTS
-
-   1: GSS-API Characteristics and Concepts . . . . . . . . . . . .  4
-   1.1: GSS-API Constructs . . . . . . . . . . . . . . . . . . . .  6
-   1.1.1:  Credentials . . . . . . . . . . . . . . . . . . . . . .  6
-   1.1.1.1: Credential Constructs and Concepts . . . . . . . . . .  6
-   1.1.1.2: Credential Management  . . . . . . . . . . . . . . . .  7
-   1.1.1.3: Default Credential Resolution  . . . . . . . . . . . .  8
-   1.1.2: Tokens . . . . . . . . . . . . . . . . . . . . . . . . .  9
-   1.1.3:  Security Contexts . . . . . . . . . . . . . . . . . . . 11
-   1.1.4:  Mechanism Types . . . . . . . . . . . . . . . . . . . . 12
-   1.1.5:  Naming  . . . . . . . . . . . . . . . . . . . . . . . . 13
-   1.1.6:  Channel Bindings  . . . . . . . . . . . . . . . . . . . 16
-   1.2:  GSS-API Features and Issues . . . . . . . . . . . . . . . 17
-   1.2.1:  Status Reporting  and Optional Service Support  . . . . 17
-   1.2.1.1: Status Reporting . . . . . . . . . . . . . . . . . . . 17
-   1.2.1.2: Optional Service Support . . . . . . . . . . . . . . . 19
-   1.2.2: Per-Message Security Service Availability  . . . . . . . 20
-   1.2.3: Per-Message Replay Detection and Sequencing  . . . . . . 21
-   1.2.4:  Quality of Protection . . . . . . . . . . . . . . . . . 24
-   1.2.5: Anonymity Support  . . . . . . . . . . . . . . . . . . . 25
-   1.2.6: Initialization . . . . . . . . . . . . . . . . . . . . . 25
-   1.2.7: Per-Message Protection During Context Establishment  . . 26
-   1.2.8: Implementation Robustness  . . . . . . . . . . . . . . . 27
-   1.2.9: Delegation . . . . . . . . . . . . . . . . . . . . . . . 28
-   1.2.10: Interprocess Context Transfer . . . . . . . . . . . . . 28
-   2:  Interface Descriptions  . . . . . . . . . . . . . . . . . . 29
-   2.1:  Credential management calls . . . . . . . . . . . . . . . 31
-   2.1.1:  GSS_Acquire_cred call . . . . . . . . . . . . . . . . . 31
-   2.1.2:  GSS_Release_cred call . . . . . . . . . . . . . . . . . 34
-   2.1.3:  GSS_Inquire_cred call . . . . . . . . . . . . . . . . . 35
-   2.1.4:  GSS_Add_cred call . . . . . . . . . . . . . . . . . . . 37
-   2.1.5:  GSS_Inquire_cred_by_mech call . . . . . . . . . . . . . 40
-   2.2:  Context-level calls . . . . . . . . . . . . . . . . . . . 41
-   2.2.1:  GSS_Init_sec_context call . . . . . . . . . . . . . . . 42
-   2.2.2:  GSS_Accept_sec_context call . . . . . . . . . . . . . . 49
-   2.2.3:  GSS_Delete_sec_context call . . . . . . . . . . . . . . 53
-   2.2.4:  GSS_Process_context_token call  . . . . . . . . . . . . 54
-   2.2.5:  GSS_Context_time call . . . . . . . . . . . . . . . . . 55
-   2.2.6:  GSS_Inquire_context call  . . . . . . . . . . . . . . . 56
-   2.2.7:  GSS_Wrap_size_limit call  . . . . . . . . . . . . . . . 57
-   2.2.8:  GSS_Export_sec_context call . . . . . . . . . . . . . . 59
-   2.2.9:  GSS_Import_sec_context call . . . . . . . . . . . . . . 61
-   2.3:  Per-message calls . . . . . . . . . . . . . . . . . . . . 62
-   2.3.1:  GSS_GetMIC call . . . . . . . . . . . . . . . . . . . . 63
-   2.3.2:  GSS_VerifyMIC call  . . . . . . . . . . . . . . . . . . 64
-   2.3.3:  GSS_Wrap call . . . . . . . . . . . . . . . . . . . . . 65
-   2.3.4:  GSS_Unwrap call . . . . . . . . . . . . . . . . . . . . 66
-
-
-
-Linn                        Standards Track                     [Page 2]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   2.4:  Support calls . . . . . . . . . . . . . . . . . . . . . . 68
-   2.4.1:  GSS_Display_status call . . . . . . . . . . . . . . . . 68
-   2.4.2:  GSS_Indicate_mechs call . . . . . . . . . . . . . . . . 69
-   2.4.3:  GSS_Compare_name call . . . . . . . . . . . . . . . . . 70
-   2.4.4:  GSS_Display_name call . . . . . . . . . . . . . . . . . 71
-   2.4.5:  GSS_Import_name call  . . . . . . . . . . . . . . . . . 72
-   2.4.6:  GSS_Release_name call . . . . . . . . . . . . . . . . . 73
-   2.4.7:  GSS_Release_buffer call . . . . . . . . . . . . . . . . 74
-   2.4.8:  GSS_Release_OID_set call  . . . . . . . . . . . . . . . 74
-   2.4.9:  GSS_Create_empty_OID_set call . . . . . . . . . . . . . 75
-   2.4.10: GSS_Add_OID_set_member call . . . . . . . . . . . . . . 76
-   2.4.11: GSS_Test_OID_set_member call  . . . . . . . . . . . . . 76
-   2.4.12: GSS_Inquire_names_for_mech call . . . . . . . . . . . . 77
-   2.4.13: GSS_Inquire_mechs_for_name call . . . . . . . . . . . . 77
-   2.4.14: GSS_Canonicalize_name call  . . . . . . . . . . . . . . 78
-   2.4.15: GSS_Export_name call  . . . . . . . . . . . . . . . . . 79
-   2.4.16: GSS_Duplicate_name call . . . . . . . . . . . . . . . . 80
-   3: Data Structure Definitions for GSS-V2 Usage  . . . . . . . . 81
-   3.1: Mechanism-Independent Token Format . . . . . . . . . . . . 81
-   3.2: Mechanism-Independent Exported Name Object Format  . . . . 84
-   4: Name Type Definitions  . . . . . . . . . . . . . . . . . . . 85
-   4.1: Host-Based Service Name Form . . . . . . . . . . . . . . . 85
-   4.2: User Name Form . . . . . . . . . . . . . . . . . . . . . . 86
-   4.3: Machine UID Form . . . . . . . . . . . . . . . . . . . . . 87
-   4.4: String UID Form  . . . . . . . . . . . . . . . . . . . . . 87
-   4.5: Anonymous Nametype . . . . . . . . . . . . . . . . . . . . 87
-   4.6: GSS_C_NO_OID . . . . . . . . . . . . . . . . . . . . . . . 88
-   4.7: Exported Name Object . . . . . . . . . . . . . . . . . . . 88
-   4.8: GSS_C_NO_NAME  . . . . . . . . . . . . . . . . . . . . . . 88
-   5:  Mechanism-Specific Example Scenarios  . . . . . . . . . . . 88
-   5.1: Kerberos V5, single-TGT  . . . . . . . . . . . . . . . . . 89
-   5.2: Kerberos V5, double-TGT  . . . . . . . . . . . . . . . . . 89
-   5.3:  X.509 Authentication Framework  . . . . . . . . . . . . . 90
-   6:  Security Considerations . . . . . . . . . . . . . . . . . . 91
-   7:  Related Activities  . . . . . . . . . . . . . . . . . . . . 92
-   8:  Referenced Documents  . . . . . . . . . . . . . . . . . . . 93
-   Appendix A: Mechanism Design Constraints  . . . . . . . . . . . 94
-   Appendix B: Compatibility with GSS-V1 . . . . . . . . . . . . . 94
-   Appendix C: Changes Relative to RFC-2078  . . . . . . . . . . . 96
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . .100
-   Full Copyright Statement  . . . . . . . . . . . . . . . . . . .101
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                     [Page 3]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-1: GSS-API Characteristics and Concepts
-
-   GSS-API operates in the following paradigm.  A typical GSS-API caller
-   is itself a communications protocol, calling on GSS-API in order to
-   protect its communications with authentication, integrity, and/or
-   confidentiality security services.  A GSS-API caller accepts tokens
-   provided to it by its local GSS-API implementation and transfers the
-   tokens to a peer on a remote system; that peer passes the received
-   tokens to its local GSS-API implementation for processing. The
-   security services available through GSS-API in this fashion are
-   implementable (and have been implemented) over a range of underlying
-   mechanisms based on secret-key and public-key cryptographic
-   technologies.
-
-   The GSS-API separates the operations of initializing a security
-   context between peers, achieving peer entity authentication
-   (GSS_Init_sec_context() and GSS_Accept_sec_context() calls), from the
-   operations of providing per-message data origin authentication and
-   data integrity protection (GSS_GetMIC() and GSS_VerifyMIC() calls)
-   for messages subsequently transferred in conjunction with that
-   context.  (The definition for the peer entity authentication service,
-   and other definitions used in this document, corresponds to that
-   provided in [ISO-7498-2].) When establishing a security context, the
-   GSS-API enables a context initiator to optionally permit its
-   credentials to be delegated, meaning that the context acceptor may
-   initiate further security contexts on behalf of the initiating
-   caller. Per-message GSS_Wrap() and GSS_Unwrap() calls provide the
-   data origin authentication and data integrity services which
-   GSS_GetMIC() and GSS_VerifyMIC() offer, and also support selection of
-   confidentiality services as a caller option. Additional calls provide
-   supportive functions to the GSS-API's users.
-
-   The following paragraphs provide an example illustrating the
-   dataflows involved in use of the GSS-API by a client and server in a
-   mechanism-independent fashion, establishing a security context and
-   transferring a protected message. The example assumes that credential
-   acquisition has already been completed.  The example also assumes
-   that the underlying authentication technology is capable of
-   authenticating a client to a server using elements carried within a
-   single token, and of authenticating the server to the client (mutual
-   authentication) with a single returned token; this assumption holds
-   for some presently-documented CAT mechanisms but is not necessarily
-   true for other cryptographic technologies and associated protocols.
-
-   The client calls GSS_Init_sec_context() to establish a security
-   context to the server identified by targ_name, and elects to set the
-   mutual_req_flag so that mutual authentication is performed in the
-   course of context establishment. GSS_Init_sec_context() returns an
-
-
-
-Linn                        Standards Track                     [Page 4]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   output_token to be passed to the server, and indicates
-   GSS_S_CONTINUE_NEEDED status pending completion of the mutual
-   authentication sequence. Had mutual_req_flag not been set, the
-   initial call to GSS_Init_sec_context() would have returned
-   GSS_S_COMPLETE status. The client sends the output_token to the
-   server.
-
-   The server passes the received token as the input_token parameter to
-   GSS_Accept_sec_context().  GSS_Accept_sec_context indicates
-   GSS_S_COMPLETE status, provides the client's authenticated identity
-   in the src_name result, and provides an output_token to be passed to
-   the client. The server sends the output_token to the client.
-
-   The client passes the received token as the input_token parameter to
-   a successor call to GSS_Init_sec_context(), which processes data
-   included in the token in order to achieve mutual authentication from
-   the client's viewpoint. This call to GSS_Init_sec_context() returns
-   GSS_S_COMPLETE status, indicating successful mutual authentication
-   and the completion of context establishment for this example.
-
-   The client generates a data message and passes it to GSS_Wrap().
-   GSS_Wrap() performs data origin authentication, data integrity, and
-   (optionally) confidentiality processing on the message and
-   encapsulates the result into output_message, indicating
-   GSS_S_COMPLETE status. The client sends the output_message to the
-   server.
-
-   The server passes the received message to GSS_Unwrap().  GSS_Unwrap()
-   inverts the encapsulation performed by GSS_Wrap(), deciphers the
-   message if the optional confidentiality feature was applied, and
-   validates the data origin authentication and data integrity checking
-   quantities. GSS_Unwrap() indicates successful validation by returning
-   GSS_S_COMPLETE status along with the resultant output_message.
-
-   For purposes of this example, we assume that the server knows by
-   out-of-band means that this context will have no further use after
-   one protected message is transferred from client to server. Given
-   this premise, the server now calls GSS_Delete_sec_context() to flush
-   context-level information.  Optionally, the server-side application
-   may provide a token buffer to GSS_Delete_sec_context(), to receive a
-   context_token to be transferred to the client in order to request
-   that client-side context-level information be deleted.
-
-   If a context_token is transferred, the client passes the
-   context_token to GSS_Process_context_token(), which returns
-   GSS_S_COMPLETE status after deleting context-level information at the
-   client system.
-
-
-
-
-Linn                        Standards Track                     [Page 5]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   The GSS-API design assumes and addresses several basic goals,
-   including:
-
-      Mechanism independence: The GSS-API defines an interface to
-      cryptographically implemented strong authentication and other
-      security services at a generic level which is independent of
-      particular underlying mechanisms. For example, GSS-API-provided
-      services have been implemented using secret-key technologies
-      (e.g., Kerberos, per [RFC-1964]) and with public-key approaches
-      (e.g., SPKM, per [RFC-2025]).
-
-      Protocol environment independence: The GSS-API is independent of
-      the communications protocol suites with which it is employed,
-      permitting use in a broad range of protocol environments. In
-      appropriate environments, an intermediate implementation "veneer"
-      which is oriented to a particular communication protocol may be
-      interposed between applications which call that protocol and the
-      GSS-API (e.g., as defined in [RFC-2203] for Open Network Computing
-      Remote Procedure Call (RPC)), thereby invoking GSS-API facilities
-      in conjunction with that protocol's communications invocations.
-
-      Protocol association independence: The GSS-API's security context
-      construct is independent of communications protocol association
-      constructs. This characteristic allows a single GSS-API
-      implementation to be utilized by a variety of invoking protocol
-      modules on behalf of those modules' calling applications. GSS-API
-      services can also be invoked directly by applications, wholly
-      independent of protocol associations.
-
-      Suitability to a range of implementation placements: GSS-API
-      clients are not constrained to reside within any Trusted Computing
-      Base (TCB) perimeter defined on a system where the GSS-API is
-      implemented; security services are specified in a manner suitable
-      to both intra-TCB and extra-TCB callers.
-
-1.1: GSS-API Constructs
-
-   This section describes the basic elements comprising the GSS-API.
-
-1.1.1:  Credentials
-
-1.1.1.1: Credential Constructs and Concepts
-
-   Credentials provide the prerequisites which permit GSS-API peers to
-   establish security contexts with each other. A caller may designate
-   that the credential elements which are to be applied for context
-   initiation or acceptance be selected by default.  Alternately, those
-   GSS-API callers which need to make explicit selection of particular
-
-
-
-Linn                        Standards Track                     [Page 6]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   credentials structures may make references to those credentials
-   through GSS-API-provided credential handles ("cred_handles").  In all
-   cases, callers' credential references are indirect, mediated by GSS-
-   API implementations and not requiring callers to access the selected
-   credential elements.
-
-   A single credential structure may be used to initiate outbound
-   contexts and to accept inbound contexts. Callers needing to operate
-   in only one of these modes may designate this fact when credentials
-   are acquired for use, allowing underlying mechanisms to optimize
-   their processing and storage requirements. The credential elements
-   defined by a particular mechanism may contain multiple cryptographic
-   keys, e.g., to enable authentication and message encryption to be
-   performed with different algorithms.
-
-   A GSS-API credential structure may contain multiple credential
-   elements, each containing mechanism-specific information for a
-   particular underlying mechanism (mech_type), but the set of elements
-   within a given credential structure represent a common entity.  A
-   credential structure's contents will vary depending on the set of
-   mech_types supported by a particular GSS-API implementation. Each
-   credential element identifies the data needed by its mechanism in
-   order to establish contexts on behalf of a particular principal, and
-   may contain separate credential references for use in context
-   initiation and context acceptance.  Multiple credential elements
-   within a given credential having overlapping combinations of
-   mechanism, usage mode, and validity period are not permitted.
-
-   Commonly, a single mech_type will be used for all security contexts
-   established by a particular initiator to a particular target. A major
-   motivation for supporting credential sets representing multiple
-   mech_types is to allow initiators on systems which are equipped to
-   handle multiple types to initiate contexts to targets on other
-   systems which can accommodate only a subset of the set supported at
-   the initiator's system.
-
-1.1.1.2: Credential Management
-
-   It is the responsibility of underlying system-specific mechanisms and
-   OS functions below the GSS-API to ensure that the ability to acquire
-   and use credentials associated with a given identity is constrained
-   to appropriate processes within a system. This responsibility should
-   be taken seriously by implementors, as the ability for an entity to
-   utilize a principal's credentials is equivalent to the entity's
-   ability to successfully assert that principal's identity.
-
-
-
-
-
-
-Linn                        Standards Track                     [Page 7]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   Once a set of GSS-API credentials is established, the transferability
-   of that credentials set to other processes or analogous constructs
-   within a system is a local matter, not defined by the GSS-API. An
-   example local policy would be one in which any credentials received
-   as a result of login to a given user account, or of delegation of
-   rights to that account, are accessible by, or transferable to,
-   processes running under that account.
-
-   The credential establishment process (particularly when performed on
-   behalf of users rather than server processes) is likely to require
-   access to passwords or other quantities which should be protected
-   locally and exposed for the shortest time possible. As a result, it
-   will often be appropriate for preliminary credential establishment to
-   be performed through local means at user login time, with the
-   result(s) cached for subsequent reference. These preliminary
-   credentials would be set aside (in a system-specific fashion) for
-   subsequent use, either:
-
-      to be accessed by an invocation of the GSS-API GSS_Acquire_cred()
-      call, returning an explicit handle to reference that credential
-
-      to comprise default credential elements to be installed, and to be
-      used when default credential behavior is requested on behalf of a
-      process
-
-1.1.1.3: Default Credential Resolution
-
-   The GSS_Init_sec_context() and GSS_Accept_sec_context() routines
-   allow the value GSS_C_NO_CREDENTIAL to be specified as their
-   credential handle parameter.  This special credential handle
-   indicates a desire by the application to act as a default principal.
-   In support of application portability, support for the default
-   resolution behavior described below for initiator credentials
-   (GSS_Init_sec_context() usage) is mandated; support for the default
-   resolution behavior described below for acceptor credentials
-   (GSS_Accept_sec_context() usage) is recommended. If default
-   credential resolution fails, GSS_S_NO_CRED status is to be returned.
-
-      GSS_Init_sec_context:
-
-         (i) If there is only a single principal capable of initiating
-         security contexts that the application is authorized to act on
-         behalf of, then that principal shall be used, otherwise
-
-
-
-
-
-
-
-
-Linn                        Standards Track                     [Page 8]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-         (ii) If the platform maintains a concept of a default network-
-         identity, and if the application is authorized to act on behalf
-         of that identity for the purpose of initiating security
-         contexts, then the principal corresponding to that identity
-         shall be used, otherwise
-
-         (iii) If the platform maintains a concept of a default local
-         identity, and provides a means to map local identities into
-         network-identities, and if the application is authorized to act
-         on behalf of the network-identity image of the default local
-         identity for the purpose of initiating security contexts, then
-         the principal corresponding to that identity shall be used,
-         otherwise
-
-         (iv) A user-configurable default identity should be used.
-
-      GSS_Accept_sec_context:
-
-         (i) If there is only a single authorized principal identity
-         capable of accepting security contexts, then that principal
-         shall be used, otherwise
-
-         (ii) If the mechanism can determine the identity of the target
-         principal by examining the context-establishment token, and if
-         the accepting application is authorized to act as that
-         principal for the purpose of accepting security contexts, then
-         that principal identity shall be used, otherwise
-
-         (iii) If the mechanism supports context acceptance by any
-         principal, and mutual authentication was not requested, any
-         principal that the application is authorized to accept security
-         contexts under may be used, otherwise
-
-         (iv) A user-configurable default identity shall be used.
-
-   The purpose of the above rules is to allow security contexts to be
-   established by both initiator and acceptor using the default behavior
-   wherever possible.  Applications requesting default behavior are
-   likely to be more portable across mechanisms and platforms than those
-   that use GSS_Acquire_cred() to request a specific identity.
-
-1.1.2: Tokens
-
-   Tokens are data elements transferred between GSS-API callers, and are
-   divided into two classes. Context-level tokens are exchanged in order
-   to establish and manage a security context between peers. Per-message
-   tokens relate to an established context and are exchanged to provide
-
-
-
-
-Linn                        Standards Track                     [Page 9]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   protective security services (i.e., data origin authentication,
-   integrity, and optional confidentiality) for corresponding data
-   messages.
-
-   The first context-level token obtained from GSS_Init_sec_context() is
-   required to indicate at its very beginning a globally-interpretable
-   mechanism identifier, i.e., an Object Identifier (OID) of the
-   security mechanism. The remaining part of this token as well as the
-   whole content of all other tokens are specific to the particular
-   underlying mechanism used to support the GSS-API. Section 3.1 of this
-   document provides, for designers of GSS-API mechanisms, the
-   description of the header of the first context-level token which is
-   then followed by mechanism-specific information.
-
-   Tokens' contents are opaque from the viewpoint of GSS-API callers.
-   They are generated within the GSS-API implementation at an end
-   system, provided to a GSS-API caller to be transferred to the peer
-   GSS-API caller at a remote end system, and processed by the GSS-API
-   implementation at that remote end system.
-
-   Context-level tokens may be output by GSS-API calls (and should be
-   transferred to GSS-API peers) whether or not the calls' status
-   indicators indicate successful completion.  Per-message tokens, in
-   contrast, are to be returned only upon successful completion of per-
-   message calls. Zero-length tokens are never returned by GSS routines
-   for transfer to a peer. Token transfer may take place in an in-band
-   manner, integrated into the same protocol stream used by the GSS-API
-   callers for other data transfers, or in an out-of-band manner across
-   a logically separate channel.
-
-   Different GSS-API tokens are used for different purposes (e.g.,
-   context initiation, context acceptance, protected message data on an
-   established context), and it is the responsibility of a GSS-API
-   caller receiving tokens to distinguish their types, associate them
-   with corresponding security contexts, and pass them to appropriate
-   GSS-API processing routines.  Depending on the caller protocol
-   environment, this distinction may be accomplished in several ways.
-
-   The following examples illustrate means through which tokens' types
-   may be distinguished:
-
-      - implicit tagging based on state information (e.g., all tokens on
-      a new association are considered to be context establishment
-      tokens until context establishment is completed, at which point
-      all tokens are considered to be wrapped data objects for that
-      context),
-
-
-
-
-
-Linn                        Standards Track                    [Page 10]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-      - explicit tagging at the caller protocol level,
-
-      - a hybrid of these approaches.
-
-   Commonly, the encapsulated data within a token includes internal
-   mechanism-specific tagging information, enabling mechanism-level
-   processing modules to distinguish tokens used within the mechanism
-   for different purposes.  Such internal mechanism-level tagging is
-   recommended to mechanism designers, and enables mechanisms to
-   determine whether a caller has passed a particular token for
-   processing by an inappropriate GSS-API routine.
-
-   Development of GSS-API mechanisms based on a particular underlying
-   cryptographic technique and protocol (i.e., conformant to a specific
-   GSS-API mechanism definition) does not necessarily imply that GSS-API
-   callers using that GSS-API mechanism will be able to interoperate
-   with peers invoking the same technique and protocol outside the GSS-
-   API paradigm, or with peers implementing a different GSS-API
-   mechanism based on the same underlying technology.  The format of
-   GSS-API tokens defined in conjunction with a particular mechanism,
-   and the techniques used to integrate those tokens into callers'
-   protocols, may not be interoperable with the tokens used by non-GSS-
-   API callers of the same underlying technique.
-
-1.1.3:  Security Contexts
-
-   Security contexts are established between peers, using credentials
-   established locally in conjunction with each peer or received by
-   peers via delegation. Multiple contexts may exist simultaneously
-   between a pair of peers, using the same or different sets of
-   credentials. Coexistence of multiple contexts using different
-   credentials allows graceful rollover when credentials expire.
-   Distinction among multiple contexts based on the same credentials
-   serves applications by distinguishing different message streams in a
-   security sense.
-
-   The GSS-API is independent of underlying protocols and addressing
-   structure, and depends on its callers to transport GSS-API-provided
-   data elements. As a result of these factors, it is a caller
-   responsibility to parse communicated messages, separating GSS-API-
-   related data elements from caller-provided data.  The GSS-API is
-   independent of connection vs. connectionless orientation of the
-   underlying communications service.
-
-   No correlation between security context and communications protocol
-   association is dictated. (The optional channel binding facility,
-   discussed in Section 1.1.6 of this document, represents an
-   intentional exception to this rule, supporting additional protection
-
-
-
-Linn                        Standards Track                    [Page 11]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   features within GSS-API supporting mechanisms.) This separation
-   allows the GSS-API to be used in a wide range of communications
-   environments, and also simplifies the calling sequences of the
-   individual calls. In many cases (depending on underlying security
-   protocol, associated mechanism, and availability of cached
-   information), the state information required for context setup can be
-   sent concurrently with initial signed user data, without interposing
-   additional message exchanges.  Messages may be protected and
-   transferred in both directions on an established GSS-API security
-   context concurrently; protection of messages in one direction does
-   not interfere with protection of messages in the reverse direction.
-
-   GSS-API implementations are expected to retain inquirable context
-   data on a context until the context is released by a caller, even
-   after the context has expired, although underlying cryptographic data
-   elements may be deleted after expiration in order to limit their
-   exposure.
-
-1.1.4:  Mechanism Types
-
-   In order to successfully establish a security context with a target
-   peer, it is necessary to identify an appropriate underlying mechanism
-   type (mech_type) which both initiator and target peers support. The
-   definition of a mechanism embodies not only the use of a particular
-   cryptographic technology (or a hybrid or choice among alternative
-   cryptographic technologies), but also definition of the syntax and
-   semantics of data element exchanges which that mechanism will employ
-   in order to support security services.
-
-   It is recommended that callers initiating contexts specify the
-   "default" mech_type value, allowing system-specific functions within
-   or invoked by the GSS-API implementation to select the appropriate
-   mech_type, but callers may direct that a particular mech_type be
-   employed when necessary.
-
-   For GSS-API purposes, the phrase "negotiating mechanism" refers to a
-   mechanism which itself performs negotiation in order to select a
-   concrete mechanism which is shared between peers and is then used for
-   context establishment.  Only those mechanisms which are defined in
-   their specifications as negotiating mechanisms are to yield selected
-   mechanisms with different identifier values than the value which is
-   input by a GSS-API caller, except for the case of a caller requesting
-   the "default" mech_type.
-
-   The means for identifying a shared mech_type to establish a security
-   context with a peer will vary in different environments and
-   circumstances; examples include (but are not limited to):
-
-
-
-
-Linn                        Standards Track                    [Page 12]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-      use of a fixed mech_type, defined by configuration, within an
-      environment
-
-      syntactic convention on a target-specific basis, through
-      examination of a target's name lookup of a target's name in a
-      naming service or other database in order to identify mech_types
-      supported by that target
-
-      explicit negotiation between GSS-API callers in advance of
-      security context setup
-
-      use of a negotiating mechanism
-
-   When transferred between GSS-API peers, mech_type specifiers (per
-   Section 3 of this document, represented as Object Identifiers (OIDs))
-   serve to qualify the interpretation of associated tokens. (The
-   structure and encoding of Object Identifiers is defined in [ISOIEC-
-   8824] and [ISOIEC-8825].) Use of hierarchically structured OIDs
-   serves to preclude ambiguous interpretation of mech_type specifiers.
-   The OID representing the DASS ([RFC-1507]) MechType, for example, is
-   1.3.12.2.1011.7.5, and that of the Kerberos V5 mechanism ([RFC-
-   1964]), having been advanced to the level of Proposed Standard, is
-   1.2.840.113554.1.2.2.
-
-1.1.5:  Naming
-
-   The GSS-API avoids prescribing naming structures, treating the names
-   which are transferred across the interface in order to initiate and
-   accept security contexts as opaque objects.  This approach supports
-   the GSS-API's goal of implementability atop a range of underlying
-   security mechanisms, recognizing the fact that different mechanisms
-   process and authenticate names which are presented in different
-   forms. Generalized services offering translation functions among
-   arbitrary sets of naming environments are outside the scope of the
-   GSS-API; availability and use of local conversion functions to
-   translate among the naming formats supported within a given end
-   system is anticipated.
-
-   Different classes of name representations are used in conjunction
-   with different GSS-API parameters:
-
-      - Internal form (denoted in this document by INTERNAL NAME),
-      opaque to callers and defined by individual GSS-API
-      implementations.  GSS-API implementations supporting multiple
-      namespace types must maintain internal tags to disambiguate the
-      interpretation of particular names.  A Mechanism Name (MN) is a
-      special case of INTERNAL NAME, guaranteed to contain elements
-
-
-
-
-Linn                        Standards Track                    [Page 13]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-      corresponding to one and only one mechanism; calls which are
-      guaranteed to emit MNs or which require MNs as input are so
-      identified within this specification.
-
-      - Contiguous string ("flat") form (denoted in this document by
-      OCTET STRING); accompanied by OID tags identifying the namespace
-      to which they correspond.  Depending on tag value, flat names may
-      or may not be printable strings for direct acceptance from and
-      presentation to users. Tagging of flat names allows GSS-API
-      callers and underlying GSS-API mechanisms to disambiguate name
-      types and to determine whether an associated name's type is one
-      which they are capable of processing, avoiding aliasing problems
-      which could result from misinterpreting a name of one type as a
-      name of another type.
-
-      - The GSS-API Exported Name Object, a special case of flat name
-      designated by a reserved OID value, carries a canonicalized form
-      of a name suitable for binary comparisons.
-
-   In addition to providing means for names to be tagged with types,
-   this specification defines primitives to support a level of naming
-   environment independence for certain calling applications. To provide
-   basic services oriented towards the requirements of callers which
-   need not themselves interpret the internal syntax and semantics of
-   names, GSS-API calls for name comparison (GSS_Compare_name()),
-   human-readable display (GSS_Display_name()), input conversion
-   (GSS_Import_name()), internal name deallocation (GSS_Release_name()),
-   and internal name duplication (GSS_Duplicate_name()) functions are
-   defined. (It is anticipated that these proposed GSS-API calls will be
-   implemented in many end systems based on system-specific name
-   manipulation primitives already extant within those end systems;
-   inclusion within the GSS-API is intended to offer GSS-API callers a
-   portable means to perform specific operations, supportive of
-   authorization and audit requirements, on authenticated names.)
-
-   GSS_Import_name() implementations can, where appropriate, support
-   more than one printable syntax corresponding to a given namespace
-   (e.g., alternative printable representations for X.500 Distinguished
-   Names), allowing flexibility for their callers to select among
-   alternative representations. GSS_Display_name() implementations
-   output a printable syntax selected as appropriate to their
-   operational environments; this selection is a local matter. Callers
-   desiring portability across alternative printable syntaxes should
-   refrain from implementing comparisons based on printable name forms
-   and should instead use the GSS_Compare_name()  call to determine
-   whether or not one internal-format name matches another.
-
-
-
-
-
-Linn                        Standards Track                    [Page 14]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   When used in large access control lists, the overhead of invoking
-   GSS_Import_name() and GSS_Compare_name() on each name from the ACL
-   may be prohibitive.  As an alternative way of supporting this case,
-   GSS-API defines a special form of the contiguous string name which
-   may be compared directly (e.g., with memcmp()).  Contiguous names
-   suitable for comparison are generated by the GSS_Export_name()
-   routine, which requires an MN as input.  Exported names may be re-
-   imported by the GSS_Import_name() routine, and the resulting internal
-   name will also be an MN.  The symbolic constant GSS_C_NT_EXPORT_NAME
-   identifies the "export name" type. Structurally, an exported name
-   object consists of a header containing an OID identifying the
-   mechanism that authenticated the name, and a trailer containing the
-   name itself, where the syntax of the trailer is defined by the
-   individual mechanism specification.  The precise format of an
-   exported name is defined in Section 3.2 of this specification.
-
-   Note that the results obtained by using GSS_Compare_name() will in
-   general be different from those obtained by invoking
-   GSS_Canonicalize_name() and GSS_Export_name(), and then comparing the
-   exported names.  The first series of operations determines whether
-   two (unauthenticated) names identify the same principal; the second
-   whether a particular mechanism would authenticate them as the same
-   principal.  These two operations will in general give the same
-   results only for MNs.
-
-   The following diagram illustrates the intended dataflow among name-
-   related GSS-API processing routines.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 15]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-                        GSS-API library defaults
-                               |
-                               |
-                               V                         text, for
-   text -------------->  internal_name (IN) -----------> display only
-         import_name()          /          display_name()
-                               /
-                              /
-                             /
-    accept_sec_context()    /
-          |                /
-          |               /
-          |              /  canonicalize_name()
-          |             /
-          |            /
-          |           /
-          |          /
-          |         /
-          |        |
-          V        V     <---------------------
-    single mechanism        import_name()         exported name: flat
-    internal_name (MN)                            binary "blob" usable
-                         ---------------------->  for access control
-                            export_name()
-
-1.1.6:  Channel Bindings
-
-   The GSS-API accommodates the concept of caller-provided channel
-   binding ("chan_binding") information.  Channel bindings are used to
-   strengthen the quality with which peer entity authentication is
-   provided during context establishment, by limiting the scope within
-   which an intercepted context establishment token can be reused by an
-   attacker. Specifically, they enable GSS-API callers to bind the
-   establishment of a security context to relevant characteristics
-   (e.g., addresses, transformed representations of encryption keys) of
-   the underlying communications channel, of protection mechanisms
-   applied to that communications channel, and to application-specific
-   data.
-
-   The caller initiating a security context must determine the
-   appropriate channel binding values to provide as input to the
-   GSS_Init_sec_context() call, and consistent values must be provided
-   to GSS_Accept_sec_context() by the context's target, in order for
-   both peers' GSS-API mechanisms to validate that received tokens
-   possess correct channel-related characteristics. Use or non-use of
-   the GSS-API channel binding facility is a caller option.  GSS-API
-   mechanisms can operate in an environment where NULL channel bindings
-   are presented; mechanism implementors are encouraged, but not
-
-
-
-Linn                        Standards Track                    [Page 16]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   required, to make use of caller-provided channel binding data within
-   their mechanisms. Callers should not assume that underlying
-   mechanisms provide confidentiality protection for channel binding
-   information.
-
-   When non-NULL channel bindings are provided by callers, certain
-   mechanisms can offer enhanced security value by interpreting the
-   bindings' content (rather than simply representing those bindings, or
-   integrity check values computed on them, within tokens) and will
-   therefore depend on presentation of specific data in a defined
-   format. To this end, agreements among mechanism implementors are
-   defining conventional interpretations for the contents of channel
-   binding arguments, including address specifiers (with content
-   dependent on communications protocol environment) for context
-   initiators and acceptors. (These conventions are being incorporated
-   in GSS-API mechanism specifications and into the GSS-API C language
-   bindings specification.) In order for GSS-API callers to be portable
-   across multiple mechanisms and achieve the full security
-   functionality which each mechanism can provide, it is strongly
-   recommended that GSS-API callers provide channel bindings consistent
-   with these conventions and those of the networking environment in
-   which they operate.
-
-1.2:  GSS-API Features and Issues
-
-   This section describes aspects of GSS-API operations, of the security
-   services which the GSS-API provides, and provides commentary on
-   design issues.
-
-1.2.1:  Status Reporting and Optional Service Support
-
-1.2.1.1: Status Reporting
-
-   Each GSS-API call provides two status return values. Major_status
-   values provide a mechanism-independent indication of call status
-   (e.g., GSS_S_COMPLETE, GSS_S_FAILURE, GSS_S_CONTINUE_NEEDED),
-   sufficient to drive normal control flow within the caller in a
-   generic fashion. Table 1 summarizes the defined major_status return
-   codes in tabular fashion.
-
-   Sequencing-related informatory major_status codes
-   (GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, and
-   GSS_S_GAP_TOKEN) can be indicated in conjunction with either
-   GSS_S_COMPLETE or GSS_S_FAILURE status for GSS-API per-message calls.
-   For context establishment calls, these sequencing-related codes will
-   be indicated only in conjunction with GSS_S_FAILURE status (never in
-
-
-
-
-
-Linn                        Standards Track                    [Page 17]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   conjunction with GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and,
-   therefore, always correspond to fatal failures if encountered during
-   the context establishment phase.
-
-   Table 1: GSS-API Major Status Codes
-
-   FATAL ERROR CODES
-
-   GSS_S_BAD_BINDINGS            channel binding mismatch
-   GSS_S_BAD_MECH                unsupported mechanism requested
-   GSS_S_BAD_NAME                invalid name provided
-   GSS_S_BAD_NAMETYPE            name of unsupported type provided
-   GSS_S_BAD_STATUS              invalid input status selector
-   GSS_S_BAD_SIG                 token had invalid integrity check
-   GSS_S_BAD_MIC                   preferred alias for GSS_S_BAD_SIG
-   GSS_S_CONTEXT_EXPIRED         specified security context expired
-   GSS_S_CREDENTIALS_EXPIRED     expired credentials detected
-   GSS_S_DEFECTIVE_CREDENTIAL    defective credential detected
-   GSS_S_DEFECTIVE_TOKEN         defective token detected
-   GSS_S_FAILURE                 failure, unspecified at GSS-API
-                                   level
-   GSS_S_NO_CONTEXT              no valid security context specified
-   GSS_S_NO_CRED                 no valid credentials provided
-   GSS_S_BAD_QOP                 unsupported QOP value
-   GSS_S_UNAUTHORIZED            operation unauthorized
-   GSS_S_UNAVAILABLE             operation unavailable
-   GSS_S_DUPLICATE_ELEMENT       duplicate credential element requested
-   GSS_S_NAME_NOT_MN             name contains multi-mechanism elements
-
-   INFORMATORY STATUS CODES
-
-   GSS_S_COMPLETE                normal completion
-   GSS_S_CONTINUE_NEEDED         continuation call to routine
-                                  required
-   GSS_S_DUPLICATE_TOKEN         duplicate per-message token
-                                  detected
-   GSS_S_OLD_TOKEN               timed-out per-message token
-                                  detected
-   GSS_S_UNSEQ_TOKEN             reordered (early) per-message token
-                                  detected
-   GSS_S_GAP_TOKEN               skipped predecessor token(s)
-                                  detected
-
-   Minor_status provides more detailed status information which may
-   include status codes specific to the underlying security mechanism.
-   Minor_status values are not specified in this document.
-
-
-
-
-
-Linn                        Standards Track                    [Page 18]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   GSS_S_CONTINUE_NEEDED major_status returns, and optional message
-   outputs, are provided in GSS_Init_sec_context() and
-   GSS_Accept_sec_context() calls so that different mechanisms'
-   employment of different numbers of messages within their
-   authentication sequences need not be reflected in separate code paths
-   within calling applications. Instead, such cases are accommodated
-   with sequences of continuation calls to GSS_Init_sec_context()  and
-   GSS_Accept_sec_context().  The same facility is used to encapsulate
-   mutual authentication within the GSS-API's context initiation calls.
-
-   For mech_types which require interactions with third-party servers in
-   order to establish a security context, GSS-API context establishment
-   calls may block pending completion of such third-party interactions.
-   On the other hand, no GSS-API calls pend on serialized interactions
-   with GSS-API peer entities.  As a result, local GSS-API status
-   returns cannot reflect unpredictable or asynchronous exceptions
-   occurring at remote peers, and reflection of such status information
-   is a caller responsibility outside the GSS-API.
-
-1.2.1.2: Optional Service Support
-
-   A context initiator may request various optional services at context
-   establishment time. Each of these services is requested by setting a
-   flag in the req_flags input parameter to GSS_Init_sec_context().
-
-   The optional services currently defined are:
-
-      - Delegation - The (usually temporary) transfer of rights from
-      initiator to acceptor, enabling the acceptor to authenticate
-      itself as an agent of the initiator.
-
-      - Mutual Authentication - In addition to the initiator
-      authenticating its identity to the context acceptor, the context
-      acceptor should also authenticate itself to the initiator.
-
-      - Replay detection - In addition to providing message integrity
-      services, GSS_GetMIC() and GSS_Wrap() should include message
-      numbering information to enable GSS_VerifyMIC() and GSS_Unwrap()
-      to detect if a message has been duplicated.
-
-      - Out-of-sequence detection - In addition to providing message
-      integrity services, GSS_GetMIC() and GSS_Wrap() should include
-      message sequencing information to enable GSS_VerifyMIC() and
-      GSS_Unwrap() to detect if a message has been received out of
-      sequence.
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 19]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-      - Anonymous authentication - The establishment of the security
-      context should not reveal the initiator's identity to the context
-      acceptor.
-
-      - Available per-message confidentiality - requests that per-
-      message confidentiality services be available on the context.
-
-      - Available per-message integrity - requests that per-message
-      integrity services be available on the context.
-
-   Any currently undefined bits within such flag arguments should be
-   ignored by GSS-API implementations when presented by an application,
-   and should be set to zero when returned to the application by the
-   GSS-API implementation.
-
-   Some mechanisms may not support all optional services, and some
-   mechanisms may only support some services in conjunction with others.
-   Both GSS_Init_sec_context() and GSS_Accept_sec_context() inform the
-   applications which services will be available from the context when
-   the establishment phase is complete, via the ret_flags output
-   parameter.  In general, if the security mechanism is capable of
-   providing a requested service, it should do so, even if additional
-   services must be enabled in order to provide the requested service.
-   If the mechanism is incapable of providing a requested service, it
-   should proceed without the service, leaving the application to abort
-   the context establishment process if it considers the requested
-   service to be mandatory.
-
-   Some mechanisms may specify that support for some services is
-   optional, and that implementors of the mechanism need not provide it.
-   This is most commonly true of the confidentiality service, often
-   because of legal restrictions on the use of data-encryption, but may
-   apply to any of the services.  Such mechanisms are required to send
-   at least one token from acceptor to initiator during context
-   establishment when the initiator indicates a desire to use such a
-   service, so that the initiating GSS-API can correctly indicate
-   whether the service is supported by the acceptor's GSS-API.
-
-1.2.2: Per-Message Security Service Availability
-
-   When a context is established, two flags are returned to indicate the
-   set of per-message protection security services which will be
-   available on the context:
-
-      the integ_avail flag indicates whether per-message integrity and
-      data origin authentication services are available
-
-
-
-
-
-Linn                        Standards Track                    [Page 20]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-      the conf_avail flag indicates whether per-message confidentiality
-      services are available, and will never be returned TRUE unless the
-      integ_avail flag is also returned TRUE
-
-   GSS-API callers desiring per-message security services should check
-   the values of these flags at context establishment time, and must be
-   aware that a returned FALSE value for integ_avail means that
-   invocation of GSS_GetMIC() or GSS_Wrap() primitives on the associated
-   context will apply no cryptographic protection to user data messages.
-
-   The GSS-API per-message integrity and data origin authentication
-   services provide assurance to a receiving caller that protection was
-   applied to a message by the caller's peer on the security context,
-   corresponding to the entity named at context initiation.  The GSS-API
-   per-message confidentiality service provides assurance to a sending
-   caller that the message's content is protected from access by
-   entities other than the context's named peer.
-
-   The GSS-API per-message protection service primitives, as the
-   category name implies, are oriented to operation at the granularity
-   of protocol data units. They perform cryptographic operations on the
-   data units, transfer cryptographic control information in tokens,
-   and, in the case of GSS_Wrap(), encapsulate the protected data unit.
-   As such, these primitives are not oriented to efficient data
-   protection for stream-paradigm protocols (e.g., Telnet) if
-   cryptography must be applied on an octet-by-octet basis.
-
-1.2.3: Per-Message Replay Detection and Sequencing
-
-   Certain underlying mech_types offer support for replay detection
-   and/or sequencing of messages transferred on the contexts they
-   support. These optionally-selectable protection features are distinct
-   from replay detection and sequencing features applied to the context
-   establishment operation itself; the presence or absence of context-
-   level replay or sequencing features is wholly a function of the
-   underlying mech_type's capabilities, and is not selected or omitted
-   as a caller option.
-
-   The caller initiating a context provides flags (replay_det_req_flag
-   and sequence_req_flag) to specify whether the use of per-message
-   replay detection and sequencing features is desired on the context
-   being established. The GSS-API implementation at the initiator system
-   can determine whether these features are supported (and whether they
-   are optionally selectable) as a function of the selected mechanism,
-   without need for bilateral negotiation with the target. When enabled,
-   these features provide recipients with indicators as a result of
-   GSS-API processing of incoming messages, identifying whether those
-   messages were detected as duplicates or out-of-sequence. Detection of
-
-
-
-Linn                        Standards Track                    [Page 21]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   such events does not prevent a suspect message from being provided to
-   a recipient; the appropriate course of action on a suspect message is
-   a matter of caller policy.
-
-   The semantics of the replay detection and sequencing services applied
-   to received messages, as visible across the interface which the GSS-
-   API provides to its clients, are as follows:
-
-   When replay_det_state is TRUE, the possible major_status returns for
-   well-formed and correctly signed messages are as follows:
-
-      1. GSS_S_COMPLETE, without concurrent indication of
-      GSS_S_DUPLICATE_TOKEN or GSS_S_OLD_TOKEN, indicates that the
-      message was within the window (of time or sequence space) allowing
-      replay events to be detected, and that the message was not a
-      replay of a previously-processed message within that window.
-
-      2. GSS_S_DUPLICATE_TOKEN indicates that the cryptographic
-      checkvalue on the received message was correct, but that the
-      message was recognized as a duplicate of a previously-processed
-      message.  In addition to identifying duplicated tokens originated
-      by a context's peer, this status may also be used to identify
-      reflected copies of locally-generated tokens; it is recommended
-      that mechanism designers include within their protocols facilities
-      to detect and report such tokens.
-
-      3. GSS_S_OLD_TOKEN indicates that the cryptographic checkvalue on
-      the received message was correct, but that the message is too old
-      to be checked for duplication.
-
-   When sequence_state is TRUE, the possible major_status returns for
-   well-formed and correctly signed messages are as follows:
-
-      1. GSS_S_COMPLETE, without concurrent indication of
-      GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, or
-      GSS_S_GAP_TOKEN, indicates that the message was within the window
-      (of time or sequence space) allowing replay events to be detected,
-      that the message was not a replay of a previously-processed
-      message within that window, and that no predecessor sequenced
-      messages are missing relative to the last received message (if
-      any) processed on the context with a correct cryptographic
-      checkvalue.
-
-      2. GSS_S_DUPLICATE_TOKEN indicates that the integrity check value
-      on the received message was correct, but that the message was
-      recognized as a duplicate of a previously-processed message.  In
-      addition to identifying duplicated tokens originated by a
-      context's peer, this status may also be used to identify reflected
-
-
-
-Linn                        Standards Track                    [Page 22]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-      copies of locally-generated tokens; it is recommended that
-      mechanism designers include within their protocols facilities to
-      detect and report such tokens.
-
-      3. GSS_S_OLD_TOKEN indicates that the integrity check value on the
-      received message was correct, but that the token is too old to be
-      checked for duplication.
-
-      4. GSS_S_UNSEQ_TOKEN indicates that the cryptographic checkvalue
-      on the received message was correct, but that it is earlier in a
-      sequenced stream than a message already processed on the context.
-      [Note: Mechanisms can be architected to provide a stricter form of
-      sequencing service, delivering particular messages to recipients
-      only after all predecessor messages in an ordered stream have been
-      delivered.  This type of support is incompatible with the GSS-API
-      paradigm in which recipients receive all messages, whether in
-      order or not, and provide them (one at a time, without intra-GSS-
-      API message buffering) to GSS-API routines for validation.  GSS-
-      API facilities provide supportive functions, aiding clients to
-      achieve strict message stream integrity in an efficient manner in
-      conjunction with sequencing provisions in communications
-      protocols, but the GSS-API does not offer this level of message
-      stream integrity service by itself.]
-
-      5. GSS_S_GAP_TOKEN indicates that the cryptographic checkvalue on
-      the received message was correct, but that one or more predecessor
-      sequenced messages have not been successfully processed relative
-      to the last received message (if any) processed on the context
-      with a correct cryptographic checkvalue.
-
-   As the message stream integrity features (especially sequencing) may
-   interfere with certain applications' intended communications
-   paradigms, and since support for such features is likely to be
-   resource intensive, it is highly recommended that mech_types
-   supporting these features allow them to be activated selectively on
-   initiator request when a context is established. A context initiator
-   and target are provided with corresponding indicators
-   (replay_det_state and sequence_state), signifying whether these
-   features are active on a given context.
-
-   An example mech_type supporting per-message replay detection could
-   (when replay_det_state is TRUE) implement the feature as follows: The
-   underlying mechanism would insert timestamps in data elements output
-   by GSS_GetMIC() and GSS_Wrap(), and would maintain (within a time-
-   limited window) a cache (qualified by originator-recipient pair)
-   identifying received data elements processed by GSS_VerifyMIC() and
-   GSS_Unwrap(). When this feature is active, exception status returns
-   (GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN) will be provided when
-
-
-
-Linn                        Standards Track                    [Page 23]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   GSS_VerifyMIC() or GSS_Unwrap() is presented with a message which is
-   either a detected duplicate of a prior message or which is too old to
-   validate against a cache of recently received messages.
-
-1.2.4:  Quality of Protection
-
-   Some mech_types provide their users with fine granularity control
-   over the means used to provide per-message protection, allowing
-   callers to trade off security processing overhead dynamically against
-   the protection requirements of particular messages. A per-message
-   quality-of-protection parameter (analogous to quality-of-service, or
-   QOS) selects among different QOP options supported by that mechanism.
-   On context establishment for a multi-QOP mech_type, context-level
-   data provides the prerequisite data for a range of protection
-   qualities.
-
-   It is expected that the majority of callers will not wish to exert
-   explicit mechanism-specific QOP control and will therefore request
-   selection of a default QOP. Definitions of, and choices among, non-
-   default QOP values are mechanism-specific, and no ordered sequences
-   of QOP values can be assumed equivalent across different mechanisms.
-   Meaningful use of non-default QOP values demands that callers be
-   familiar with the QOP definitions of an underlying mechanism or
-   mechanisms, and is therefore a non-portable construct.  The
-   GSS_S_BAD_QOP major_status value is defined in order to indicate that
-   a provided QOP value is unsupported for a security context, most
-   likely because that value is unrecognized by the underlying
-   mechanism.
-
-   In the interests of interoperability, mechanisms which allow optional
-   support of particular QOP values shall satisfy one of the following
-   conditions.  Either:
-
-      (i) All implementations of the mechanism are required to be
-      capable of processing messages protected using any QOP value,
-      regardless of whether they can apply protection corresponding to
-      that QOP, or
-
-      (ii) The set of mutually-supported receiver QOP values must be
-      determined during context establishment, and messages may be
-      protected by either peer using only QOP values from this
-      mutually-supported set.
-
-   NOTE: (i) is just a special-case of (ii), where implementations are
-   required to support all QOP values on receipt.
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 24]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-1.2.5: Anonymity Support
-
-   In certain situations or environments, an application may wish to
-   authenticate a peer and/or protect communications using GSS-API per-
-   message services without revealing its own identity.  For example,
-   consider an application which provides read access to a research
-   database, and which permits queries by arbitrary requestors.  A
-   client of such a service might wish to authenticate the service, to
-   establish trust in the information received from it, but might not
-   wish to disclose its identity to the service for privacy reasons.
-
-   In ordinary GSS-API usage, a context initiator's identity is made
-   available to the context acceptor as part of the context
-   establishment process.  To provide for anonymity support, a facility
-   (input anon_req_flag to GSS_Init_sec_context()) is provided through
-   which context initiators may request that their identity not be
-   provided to the context acceptor.  Mechanisms are not required to
-   honor this request, but a caller will be informed (via returned
-   anon_state indicator from GSS_Init_sec_context()) whether or not the
-   request is honored. Note that authentication as the anonymous
-   principal does not necessarily imply that credentials are not
-   required in order to establish a context.
-
-   Section 4.5 of this document defines the Object Identifier value used
-   to identify an anonymous principal.
-
-   Four possible combinations of anon_state and mutual_state are
-   possible, with the following results:
-
-      anon_state == FALSE, mutual_state == FALSE: initiator
-      authenticated to target.
-
-      anon_state == FALSE, mutual_state == TRUE: initiator authenticated
-      to target, target authenticated to initiator.
-
-      anon_state == TRUE, mutual_state == FALSE: initiator authenticated
-      as anonymous principal to target.
-
-      anon_state == TRUE, mutual_state == TRUE: initiator authenticated
-      as anonymous principal to target, target authenticated to
-      initiator.
-
-1.2.6: Initialization
-
-   No initialization calls (i.e., calls which must be invoked prior to
-   invocation of other facilities in the interface) are defined in GSS-
-   API.  As an implication of this fact, GSS-API implementations must
-   themselves be self-initializing.
-
-
-
-Linn                        Standards Track                    [Page 25]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-1.2.7: Per-Message Protection During Context Establishment
-
-   A facility is defined in GSS-V2 to enable protection and buffering of
-   data messages for later transfer while a security context's
-   establishment is in GSS_S_CONTINUE_NEEDED status, to be used in cases
-   where the caller side already possesses the necessary session key to
-   enable this processing. Specifically, a new state Boolean, called
-   prot_ready_state, is added to the set of information returned by
-   GSS_Init_sec_context(), GSS_Accept_sec_context(), and
-   GSS_Inquire_context().
-
-   For context establishment calls, this state Boolean is valid and
-   interpretable when the associated major_status is either
-   GSS_S_CONTINUE_NEEDED, or GSS_S_COMPLETE.  Callers of GSS-API (both
-   initiators and acceptors) can assume that per-message protection (via
-   GSS_Wrap(), GSS_Unwrap(), GSS_GetMIC() and GSS_VerifyMIC()) is
-   available and ready for use if either: prot_ready_state == TRUE, or
-   major_status == GSS_S_COMPLETE, though mutual authentication (if
-   requested) cannot be guaranteed until GSS_S_COMPLETE is returned.
-   Callers making use of per-message protection services in advance of
-   GSS_S_COMPLETE status should be aware of the possibility that a
-   subsequent context establishment step may fail, and that certain
-   context data (e.g., mech_type) as returned for subsequent calls may
-   change.
-
-   This approach achieves full, transparent backward compatibility for
-   GSS-API V1 callers, who need not even know of the existence of
-   prot_ready_state, and who will get the expected behavior from
-   GSS_S_COMPLETE, but who will not be able to use per-message
-   protection before GSS_S_COMPLETE is returned.
-
-   It is not a requirement that GSS-V2 mechanisms ever return TRUE
-   prot_ready_state before completion of context establishment (indeed,
-   some mechanisms will not evolve usable message protection keys,
-   especially at the context acceptor, before context establishment is
-   complete).  It is expected but not required that GSS-V2 mechanisms
-   will return TRUE prot_ready_state upon completion of context
-   establishment if they support per-message protection at all (however
-   GSS-V2 applications should not assume that TRUE prot_ready_state will
-   always be returned together with the GSS_S_COMPLETE major_status,
-   since GSS-V2 implementations may continue to support GSS-V1 mechanism
-   code, which will never return TRUE prot_ready_state).
-
-   When prot_ready_state is returned TRUE, mechanisms shall also set
-   those context service indicator flags (deleg_state, mutual_state,
-   replay_det_state, sequence_state, anon_state, trans_state,
-   conf_avail, integ_avail) which represent facilities confirmed, at
-   that time, to be available on the context being established.  In
-
-
-
-Linn                        Standards Track                    [Page 26]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   situations where prot_ready_state is returned before GSS_S_COMPLETE,
-   it is possible that additional facilities may be confirmed and
-   subsequently indicated when GSS_S_COMPLETE is returned.
-
-1.2.8: Implementation Robustness
-
-   This section recommends aspects of GSS-API implementation behavior in
-   the interests of overall robustness.
-
-   Invocation of GSS-API calls is to incur no undocumented side effects
-   visible at the GSS-API level.
-
-   If a token is presented for processing on a GSS-API security context
-   and that token generates a fatal error in processing or is otherwise
-   determined to be invalid for that context, the context's state should
-   not be disrupted for purposes of processing subsequent valid tokens.
-
-   Certain local conditions at a GSS-API implementation (e.g.,
-   unavailability of memory) may preclude, temporarily or permanently,
-   the successful processing of tokens on a GSS-API security context,
-   typically generating GSS_S_FAILURE major_status returns along with
-   locally-significant minor_status.  For robust operation under such
-   conditions, the following recommendations are made:
-
-      Failing calls should free any memory they allocate, so that
-      callers may retry without causing further loss of resources.
-
-      Failure of an individual call on an established context should not
-      preclude subsequent calls from succeeding on the same context.
-
-      Whenever possible, it should be possible for
-      GSS_Delete_sec_context() calls to be successfully processed even
-      if other calls cannot succeed, thereby enabling context-related
-      resources to be released.
-
-   A failure of GSS_GetMIC() or GSS_Wrap() due to an attempt to use an
-   unsupported QOP will not interfere with context validity, nor shall
-   such a failure impact the ability of the application to subsequently
-   invoke GSS_GetMIC() or GSS_Wrap() using a supported QOP. Any state
-   information concerning sequencing of outgoing messages shall be
-   unchanged by an unsuccessful call of GSS_GetMIC() or GSS_Wrap().
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 27]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-1.2.9: Delegation
-
-   The GSS-API allows delegation to be controlled by the initiating
-   application via a Boolean parameter to GSS_Init_sec_context(), the
-   routine that establishes a security context.  Some mechanisms do not
-   support delegation, and for such mechanisms attempts by an
-   application to enable delegation are ignored.
-
-   The acceptor of a security context for which the initiator enabled
-   delegation will receive (via the delegated_cred_handle parameter of
-   GSS_Accept_sec_context()) a credential handle that contains the
-   delegated identity, and this credential handle may be used to
-   initiate subsequent GSS-API security contexts as an agent or delegate
-   of the initiator.  If the original initiator's identity is "A" and
-   the delegate's identity is "B", then, depending on the underlying
-   mechanism, the identity embodied by the delegated credential may be
-   either "A" or "B acting for A".
-
-   For many mechanisms that support delegation, a simple Boolean does
-   not provide enough control.  Examples of additional aspects of
-   delegation control that a mechanism might provide to an application
-   are duration of delegation, network addresses from which delegation
-   is valid, and constraints on the tasks that may be performed by a
-   delegate.  Such controls are presently outside the scope of the GSS-
-   API.  GSS-API implementations supporting mechanisms offering
-   additional controls should provide extension routines that allow
-   these controls to be exercised (perhaps by modifying the initiator's
-   GSS-API credential prior to its use in establishing a context).
-   However, the simple delegation control provided by GSS-API should
-   always be able to over-ride other mechanism-specific delegation
-   controls; if the application instructs GSS_Init_sec_context() that
-   delegation is not desired, then the implementation must not permit
-   delegation to occur.  This is an exception to the general rule that a
-   mechanism may enable services even if they are not requested;
-   delegation may only be provided at the explicit request of the
-   application.
-
-1.2.10: Interprocess Context Transfer
-
-   GSS-API V2 provides routines (GSS_Export_sec_context() and
-   GSS_Import_sec_context()) which allow a security context to be
-   transferred between processes on a single machine.  The most common
-   use for such a feature is a client-server design where the server is
-   implemented as a single process that accepts incoming security
-   contexts, which then launches child processes to deal with the data
-   on these contexts.  In such a design, the child processes must have
-   access to the security context data structure created within the
-
-
-
-
-Linn                        Standards Track                    [Page 28]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   parent by its call to GSS_Accept_sec_context() so that they can use
-   per-message protection services and delete the security context when
-   the communication session ends.
-
-   Since the security context data structure is expected to contain
-   sequencing information, it is impractical in general to share a
-   context between processes.  Thus GSS-API provides a call
-   (GSS_Export_sec_context()) that the process which currently owns the
-   context can call to declare that it has no intention to use the
-   context subsequently, and to create an inter-process token containing
-   information needed by the adopting process to successfully import the
-   context.  After successful completion of this call, the original
-   security context is made inaccessible to the calling process by GSS-
-   API, and any context handles referring to this context are no longer
-   valid.  The originating process transfers the inter-process token to
-   the adopting process, which passes it to GSS_Import_sec_context(),
-   and a fresh context handle is created such that it is functionally
-   identical to the original context.
-
-   The inter-process token may contain sensitive data from the original
-   security context (including cryptographic keys).  Applications using
-   inter-process tokens to transfer security contexts must take
-   appropriate steps to protect these tokens in transit.
-   Implementations are not required to support the inter-process
-   transfer of security contexts.  The ability to transfer a security
-   context is indicated when the context is created, by
-   GSS_Init_sec_context() or GSS_Accept_sec_context() indicating a TRUE
-   trans_state return value.
-
-2:  Interface Descriptions
-
-   This section describes the GSS-API's service interface, dividing the
-   set of calls offered into four groups. Credential management calls
-   are related to the acquisition and release of credentials by
-   principals. Context-level calls are related to the management of
-   security contexts between principals. Per-message calls are related
-   to the protection of individual messages on established security
-   contexts. Support calls provide ancillary functions useful to GSS-API
-   callers. Table 2 groups and summarizes the calls in tabular fashion.
-
-   Table 2:  GSS-API Calls
-
-   CREDENTIAL MANAGEMENT
-
-   GSS_Acquire_cred             acquire credentials for use
-   GSS_Release_cred             release credentials after use
-   GSS_Inquire_cred             display information about
-                                credentials
-
-
-
-Linn                        Standards Track                    [Page 29]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   GSS_Add_cred                 construct credentials incrementally
-   GSS_Inquire_cred_by_mech     display per-mechanism credential
-                                  information
-
-   CONTEXT-LEVEL CALLS
-
-   GSS_Init_sec_context         initiate outbound security context
-   GSS_Accept_sec_context       accept inbound security context
-   GSS_Delete_sec_context       flush context when no longer needed
-   GSS_Process_context_token    process received control token on
-                                  context
-   GSS_Context_time             indicate validity time remaining on
-                                     context
-   GSS_Inquire_context          display information about context
-   GSS_Wrap_size_limit          determine GSS_Wrap token size limit
-   GSS_Export_sec_context       transfer context to other process
-   GSS_Import_sec_context       import transferred context
-
-   PER-MESSAGE CALLS
-
-   GSS_GetMIC                   apply integrity check, receive as
-                                  token separate from message
-   GSS_VerifyMIC                validate integrity check token
-                                  along with message
-   GSS_Wrap                     sign, optionally encrypt,
-                                  encapsulate
-   GSS_Unwrap                   decapsulate, decrypt if needed,
-                                  validate integrity check
-
-   SUPPORT CALLS
-
-   GSS_Display_status           translate status codes to printable
-                                  form
-   GSS_Indicate_mechs           indicate mech_types supported on
-                                  local system
-   GSS_Compare_name             compare two names for equality
-   GSS_Display_name             translate name to printable form
-   GSS_Import_name              convert printable name to
-                                  normalized form
-   GSS_Release_name             free storage of normalized-form
-                                  name
-   GSS_Release_buffer           free storage of general GSS-allocated
-                                  object
-   GSS_Release_OID_set          free storage of OID set object
-   GSS_Create_empty_OID_set     create empty OID set
-   GSS_Add_OID_set_member       add member to OID set
-   GSS_Test_OID_set_member      test if OID is member of OID set
-   GSS_Inquire_names_for_mech   indicate name types supported by
-
-
-
-Linn                        Standards Track                    [Page 30]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-                                  mechanism
-   GSS_Inquire_mechs_for_name   indicates mechanisms supporting name
-                                  type
-   GSS_Canonicalize_name        translate name to per-mechanism form
-   GSS_Export_name              externalize per-mechanism name
-   GSS_Duplicate_name           duplicate name object
-
-2.1:  Credential management calls
-
-   These GSS-API calls provide functions related to the management of
-   credentials. Their characterization with regard to whether or not
-   they may block pending exchanges with other network entities (e.g.,
-   directories or authentication servers) depends in part on OS-specific
-   (extra-GSS-API) issues, so is not specified in this document.
-
-   The GSS_Acquire_cred() call is defined within the GSS-API in support
-   of application portability, with a particular orientation towards
-   support of portable server applications. It is recognized that (for
-   certain systems and mechanisms) credentials for interactive users may
-   be managed differently from credentials for server processes; in such
-   environments, it is the GSS-API implementation's responsibility to
-   distinguish these cases and the procedures for making this
-   distinction are a local matter. The GSS_Release_cred() call provides
-   a means for callers to indicate to the GSS-API that use of a
-   credentials structure is no longer required. The GSS_Inquire_cred()
-   call allows callers to determine information about a credentials
-   structure.  The GSS_Add_cred() call enables callers to append
-   elements to an existing credential structure, allowing iterative
-   construction of a multi-mechanism credential. The
-   GSS_Inquire_cred_by_mech() call enables callers to extract per-
-   mechanism information describing a credentials structure.
-
-2.1.1:  GSS_Acquire_cred call
-
-   Inputs:
-
-   o  desired_name INTERNAL NAME, -- NULL requests locally-determined
-   -- default
-
-   o  lifetime_req INTEGER, -- in seconds; 0 requests default
-
-   o  desired_mechs SET OF OBJECT IDENTIFIER, -- NULL requests
-   -- system-selected default
-
-   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-   -- 2=ACCEPT-ONLY
-
-
-
-
-
-Linn                        Standards Track                    [Page 31]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_cred_handle CREDENTIAL HANDLE, -- if returned non-NULL,
-   -- caller must release with GSS_Release_cred()
-
-   o  actual_mechs SET OF OBJECT IDENTIFIER, -- if returned non-NULL,
-   -- caller must release with GSS_Release_oid_set()
-
-   o  lifetime_rec INTEGER -- in seconds, or reserved value for
-   -- INDEFINITE
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that requested credentials were
-   successfully established, for the duration indicated in lifetime_rec,
-   suitable for the usage requested in cred_usage, for the set of
-   mech_types indicated in actual_mechs, and that those credentials can
-   be referenced for subsequent use with the handle returned in
-   output_cred_handle.
-
-   o  GSS_S_BAD_MECH indicates that a mech_type unsupported by the GSS-
-   API implementation type was requested, causing the credential
-   establishment operation to fail.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the provided desired_name is
-   uninterpretable or of a type unsupported by the applicable underlying
-   GSS-API mechanism(s), so no credentials could be established for the
-   accompanying desired_name.
-
-   o  GSS_S_BAD_NAME indicates that the provided desired_name is
-   inconsistent in terms of internally-incorporated type specifier
-   information, so no credentials could be established for the
-   accompanying desired_name.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that underlying credential
-   elements corresponding to the requested desired_name have expired, so
-   requested credentials could not be established.
-
-   o GSS_S_NO_CRED indicates that no credential elements corresponding
-   to the requested desired_name and usage could be accessed, so
-   requested credentials could not be established.  In particular, this
-   status should be returned upon temporary user-fixable conditions
-
-
-
-
-
-Linn                        Standards Track                    [Page 32]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   preventing successful credential establishment and upon lack of
-   authorization to establish and use credentials associated with the
-   identity named in the input desired_name argument.
-
-   o  GSS_S_FAILURE indicates that credential establishment failed for
-   reasons unspecified at the GSS-API level.
-
-   GSS_Acquire_cred() is used to acquire credentials so that a principal
-   can (as a function of the input cred_usage parameter) initiate and/or
-   accept security contexts under the identity represented by the
-   desired_name input argument. On successful completion, the returned
-   output_cred_handle result provides a handle for subsequent references
-   to the acquired credentials.  Typically, single-user client processes
-   requesting that default credential behavior be applied for context
-   establishment purposes will have no need to invoke this call.
-
-   A caller may provide the value NULL (GSS_C_NO_NAME) for desired_name,
-   which will be interpreted as a request for a credential handle that
-   will invoke default behavior when passed to GSS_Init_sec_context(),
-   if cred_usage is GSS_C_INITIATE or GSS_C_BOTH, or
-   GSS_Accept_sec_context(), if cred_usage is GSS_C_ACCEPT or
-   GSS_C_BOTH.  It is possible that multiple pre-established credentials
-   may exist for the same principal identity (for example, as a result
-   of multiple user login sessions) when GSS_Acquire_cred() is called;
-   the means used in such cases to select a specific credential are
-   local matters.  The input lifetime_req argument to GSS_Acquire_cred()
-   may provide useful information for local GSS-API implementations to
-   employ in making this disambiguation in a manner which will best
-   satisfy a caller's intent.
-
-   This routine is expected to be used primarily by context acceptors,
-   since implementations are likely to provide mechanism-specific ways
-   of obtaining GSS-API initiator credentials from the system login
-   process.  Some implementations may therefore not support the
-   acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via
-   GSS_Acquire_cred() for any name other than GSS_C_NO_NAME, or a name
-   resulting from applying GSS_Inquire_context() to an active context,
-   or a name resulting from applying GSS_Inquire_cred() against a
-   credential handle corresponding to default behavior. It is important
-   to recognize that the explicit name which is yielded by resolving a
-   default reference may change over time, e.g., as a result of local
-   credential element management operations outside GSS-API; once
-   resolved, however, the value of such an explicit name will remain
-   constant.
-
-   The lifetime_rec result indicates the length of time for which the
-   acquired credentials will be valid, as an offset from the present. A
-   mechanism may return a reserved value indicating INDEFINITE if no
-
-
-
-Linn                        Standards Track                    [Page 33]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   constraints on credential lifetime are imposed.  A caller of
-   GSS_Acquire_cred() can request a length of time for which acquired
-   credentials are to be valid (lifetime_req argument), beginning at the
-   present, or can request credentials with a default validity interval.
-   (Requests for postdated credentials are not supported within the
-   GSS-API.) Certain mechanisms and implementations may bind in
-   credential validity period specifiers at a point preliminary to
-   invocation of the GSS_Acquire_cred() call (e.g., in conjunction with
-   user login procedures). As a result, callers requesting non-default
-   values for lifetime_req must recognize that such requests cannot
-   always be honored and must be prepared to accommodate the use of
-   returned credentials with different lifetimes as indicated in
-   lifetime_rec.
-
-   The caller of GSS_Acquire_cred() can explicitly specify a set of
-   mech_types which are to be accommodated in the returned credentials
-   (desired_mechs argument), or can request credentials for a system-
-   defined default set of mech_types. Selection of the system-specified
-   default set is recommended in the interests of application
-   portability. The actual_mechs return value may be interrogated by the
-   caller to determine the set of mechanisms with which the returned
-   credentials may be used.
-
-2.1.2:  GSS_Release_cred call
-
-   Input:
-
-   o  cred_handle CREDENTIAL HANDLE -- if GSS_C_NO_CREDENTIAL
-   -- is specified, the call will complete successfully, but
-   -- will have no effect; no credential elements will be
-   -- released.
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the credentials referenced by the
-   input cred_handle were released for purposes of subsequent access by
-   the caller. The effect on other processes which may be authorized
-   shared access to such credentials is a local matter.
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 34]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  GSS_S_NO_CRED indicates that no release operation was performed,
-   either because the input cred_handle was invalid or because the
-   caller lacks authorization to access the referenced credentials.
-
-   o  GSS_S_FAILURE indicates that the release operation failed for
-   reasons unspecified at the GSS-API level.
-
-   Provides a means for a caller to explicitly request that credentials
-   be released when their use is no longer required. Note that system-
-   specific credential management functions are also likely to exist,
-   for example to assure that credentials shared among processes are
-   properly deleted when all affected processes terminate, even if no
-   explicit release requests are issued by those processes. Given the
-   fact that multiple callers are not precluded from gaining authorized
-   access to the same credentials, invocation of GSS_Release_cred()
-   cannot be assumed to delete a particular set of credentials on a
-   system-wide basis.
-
-2.1.3:  GSS_Inquire_cred call
-
-   Input:
-
-   o  cred_handle CREDENTIAL HANDLE -- if GSS_C_NO_CREDENTIAL
-   -- is specified, default initiator credentials are queried
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  cred_name INTERNAL NAME,  -- caller must release with
-   -- GSS_Release_name()
-
-   o  lifetime_rec INTEGER -- in seconds, or reserved value for
-   -- INDEFINITE
-
-   o  cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-   -- 2=ACCEPT-ONLY
-
-   o  mech_set SET OF OBJECT IDENTIFIER  -- caller must release
-   -- with GSS_Release_oid_set()
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 35]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the credentials referenced by the
-   input cred_handle argument were valid, and that the output cred_name,
-   lifetime_rec, and cred_usage values represent, respectively, the
-   credentials' associated principal name, remaining lifetime, suitable
-   usage modes, and supported mechanism types.
-
-   o  GSS_S_NO_CRED indicates that no information could be returned
-   about the referenced credentials, either because the input
-   cred_handle was invalid or because the caller lacks authorization to
-   access the referenced credentials.
-
-   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that the referenced
-   credentials are invalid.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the referenced
-   credentials have expired.
-
-   o  GSS_S_FAILURE indicates that the operation failed for reasons
-   unspecified at the GSS-API level.
-
-   The GSS_Inquire_cred() call is defined primarily for the use of those
-   callers which request use of default credential behavior rather than
-   acquiring credentials explicitly with GSS_Acquire_cred().  It enables
-   callers to determine a credential structure's associated principal
-   name, remaining validity period, usability for security context
-   initiation and/or acceptance, and supported mechanisms.
-
-   For a multi-mechanism credential, the returned "lifetime" specifier
-   indicates the shortest lifetime of any of the mechanisms' elements in
-   the credential (for either context initiation or acceptance
-   purposes).
-
-   GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for
-   "cred_usage" if both of the following conditions hold:
-
-      (1) there exists in the credential an element which allows context
-      initiation using some mechanism
-
-      (2) there exists in the credential an element which allows context
-      acceptance using some mechanism (allowably, but not necessarily,
-      one of the same mechanism(s) qualifying for (1)).
-
-   If condition (1) holds but not condition (2), GSS_Inquire_cred()
-   should indicate INITIATE-ONLY for "cred_usage".  If condition (2)
-   holds but not condition (1), GSS_Inquire_cred() should indicate
-   ACCEPT-ONLY for "cred_usage".
-
-
-
-Linn                        Standards Track                    [Page 36]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   Callers requiring finer disambiguation among available combinations
-   of lifetimes, usage modes, and mechanisms should call the
-   GSS_Inquire_cred_by_mech() routine, passing that routine one of the
-   mech OIDs returned by GSS_Inquire_cred().
-
-2.1.4:  GSS_Add_cred call
-
-   Inputs:
-
-   o  input_cred_handle CREDENTIAL HANDLE -- handle to credential
-   -- structure created with prior GSS_Acquire_cred() or
-   -- GSS_Add_cred() call; see text for definition of behavior
-   -- when GSS_C_NO_CREDENTIAL provided.
-
-   o  desired_name INTERNAL NAME
-
-   o  initiator_time_req INTEGER -- in seconds; 0 requests default
-
-   o  acceptor_time_req INTEGER -- in seconds; 0 requests default
-
-   o  desired_mech OBJECT IDENTIFIER
-
-   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-   -- 2=ACCEPT-ONLY
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_cred_handle CREDENTIAL HANDLE, -- NULL to request that
-   -- credential elements be added "in place" to the credential
-   -- structure identified by input_cred_handle,
-   -- non-NULL pointer to request that
-   -- a new credential structure and handle be created.
-   -- if credential handle returned, caller must release with
-   -- GSS_Release_cred()
-
-   o  actual_mechs SET OF OBJECT IDENTIFIER, -- if returned, caller must
-   -- release with GSS_Release_oid_set()
-
-   o  initiator_time_rec INTEGER -- in seconds, or reserved value for
-   -- INDEFINITE
-
-   o  acceptor_time_rec INTEGER -- in seconds, or reserved value for
-   -- INDEFINITE
-
-
-
-
-Linn                        Standards Track                    [Page 37]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-   -- 2=ACCEPT-ONLY
-
-   o  mech_set SET OF OBJECT IDENTIFIER -- full set of mechanisms
-   -- supported by resulting credential.
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the credentials referenced by the
-   input_cred_handle argument were valid, and that the resulting
-   credential from GSS_Add_cred() is valid for the durations indicated
-   in initiator_time_rec and acceptor_time_rec, suitable for the usage
-   requested in cred_usage, and for the mechanisms indicated in
-   actual_mechs.
-
-   o  GSS_S_DUPLICATE_ELEMENT indicates that the input desired_mech
-   specified a mechanism for which the referenced credential already
-   contained a credential element with overlapping cred_usage and
-   validity time specifiers.
-
-   o  GSS_S_BAD_MECH indicates that the input desired_mech specified a
-   mechanism unsupported by the GSS-API implementation, causing the
-   GSS_Add_cred() operation to fail.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the provided desired_name is
-   uninterpretable or of a type unsupported by the applicable underlying
-   GSS-API mechanism(s), so the GSS_Add_cred() operation could not be
-   performed for that name.
-
-   o  GSS_S_BAD_NAME indicates that the provided desired_name is
-   inconsistent in terms of internally-incorporated type specifier
-   information, so the GSS_Add_cred() operation could not be performed
-   for that name.
-
-   o  GSS_S_NO_CRED indicates that the input_cred_handle referenced
-   invalid or inaccessible credentials. In particular, this status
-   should be returned upon temporary user-fixable conditions preventing
-   successful credential establishment or upon lack of authorization to
-   establish or use credentials representing the requested identity.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that referenced credential
-   elements have expired, so the GSS_Add_cred() operation could not be
-   performed.
-
-   o  GSS_S_FAILURE indicates that the operation failed for reasons
-   unspecified at the GSS-API level.
-
-
-
-
-
-Linn                        Standards Track                    [Page 38]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   GSS_Add_cred() enables callers to construct credentials iteratively
-   by adding credential elements in successive operations, corresponding
-   to different mechanisms.  This offers particular value in multi-
-   mechanism environments, as the major_status and minor_status values
-   returned on each iteration are individually visible and can therefore
-   be interpreted unambiguously on a per-mechanism basis. A credential
-   element is identified by the name of the principal to which it
-   refers.  GSS-API implementations must impose a local access control
-   policy on callers of this routine to prevent unauthorized callers
-   from acquiring credential elements to which they are not entitled.
-   This routine is not intended to provide a "login to the network"
-   function, as such a function would involve the creation of new
-   mechanism-specific authentication data, rather than merely acquiring
-   a GSS-API handle to existing data.  Such functions, if required,
-   should be defined in implementation-specific extension routines.
-
-   If credential acquisition is time-consuming for a mechanism, the
-   mechanism may choose to delay the actual acquisition until the
-   credential is required (e.g. by GSS_Init_sec_context() or
-   GSS_Accept_sec_context()).  Such mechanism-specific implementation
-   decisions should be invisible to the calling application; thus a call
-   of GSS_Inquire_cred() immediately following the call of
-   GSS_Acquire_cred() must return valid credential data, and may
-   therefore incur the overhead of a deferred credential acquisition.
-
-   If GSS_C_NO_CREDENTIAL is specified as input_cred_handle, a non-NULL
-   output_cred_handle must be supplied.  For the case of
-   GSS_C_NO_CREDENTIAL as input_cred_handle, GSS_Add_cred() will create
-   the credential referenced by its output_cred_handle based on default
-   behavior.  That is, the call will have the same effect as if the
-   caller had previously called GSS_Acquire_cred(), specifying the same
-   usage and passing GSS_C_NO_NAME as the desired_name parameter
-   (thereby obtaining an explicit credential handle corresponding to
-   default behavior), had passed that credential handle to
-   GSS_Add_cred(), and had finally called GSS_Release_cred() on the
-   credential handle received from GSS_Acquire_cred().
-
-   This routine is expected to be used primarily by context acceptors,
-   since implementations are likely to provide mechanism-specific ways
-   of obtaining GSS-API initiator credentials from the system login
-   process.  Some implementations may therefore not support the
-   acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via
-   GSS_Acquire_cred() for any name other than GSS_C_NO_NAME, or a name
-   resulting from applying GSS_Inquire_context() to an active context,
-   or a name resulting from applying GSS_Inquire_cred() against a
-   credential handle corresponding to default behavior. It is important
-   to recognize that the explicit name which is yielded by resolving a
-   default reference may change over time, e.g., as a result of local
-
-
-
-Linn                        Standards Track                    [Page 39]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   credential element management operations outside GSS-API; once
-   resolved, however, the value of such an explicit name will remain
-   constant.
-
-   A caller may provide the value NULL (GSS_C_NO_NAME) for desired_name,
-   which will be interpreted as a request for a credential handle that
-   will invoke default behavior when passed to GSS_Init_sec_context(),
-   if cred_usage is GSS_C_INITIATE or GSS_C_BOTH, or
-   GSS_Accept_sec_context(), if cred_usage is GSS_C_ACCEPT or
-   GSS_C_BOTH.
-
-   The same input desired_name, or default reference, should be used on
-   all GSS_Acquire_cred() and GSS_Add_cred() calls corresponding to a
-   particular credential.
-
-2.1.5:  GSS_Inquire_cred_by_mech call
-
-   Inputs:
-
-   o  cred_handle CREDENTIAL HANDLE -- if GSS_C_NO_CREDENTIAL
-   -- specified, default initiator credentials are queried
-
-   o  mech_type OBJECT IDENTIFIER  -- specific mechanism for
-   -- which credentials are being queried
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  cred_name INTERNAL NAME, -- guaranteed to be MN; caller must
-   -- release with GSS_Release_name()
-
-   o  lifetime_rec_initiate INTEGER -- in seconds, or reserved value for
-   -- INDEFINITE
-
-   o  lifetime_rec_accept INTEGER -- in seconds, or reserved value for
-   -- INDEFINITE
-
-   o  cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-   -- 2=ACCEPT-ONLY
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the credentials referenced by the
-   input cred_handle argument were valid, that the mechanism indicated
-   by the input mech_type was represented with elements within those
-
-
-
-Linn                        Standards Track                    [Page 40]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   credentials, and that the output cred_name, lifetime_rec_initiate,
-   lifetime_rec_accept, and cred_usage values represent, respectively,
-   the credentials' associated principal name, remaining lifetimes, and
-   suitable usage modes.
-
-   o  GSS_S_NO_CRED indicates that no information could be returned
-   about the referenced credentials, either because the input
-   cred_handle was invalid or because the caller lacks authorization to
-   access the referenced credentials.
-
-   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that the referenced
-   credentials are invalid.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the referenced
-   credentials have expired.
-
-   o  GSS_S_BAD_MECH indicates that the referenced credentials do not
-   contain elements for the requested mechanism.
-
-   o  GSS_S_FAILURE indicates that the operation failed for reasons
-   unspecified at the GSS-API level.
-
-   The GSS_Inquire_cred_by_mech() call enables callers in multi-
-   mechanism environments to acquire specific data about available
-   combinations of lifetimes, usage modes, and mechanisms within a
-   credential structure.  The lifetime_rec_initiate result indicates the
-   available lifetime for context initiation purposes; the
-   lifetime_rec_accept result indicates the available lifetime for
-   context acceptance purposes.
-
-2.2:  Context-level calls
-
-   This group of calls is devoted to the establishment and management of
-   security contexts between peers. A context's initiator calls
-   GSS_Init_sec_context(), resulting in generation of a token which the
-   caller passes to the target. At the target, that token is passed to
-   GSS_Accept_sec_context(). Depending on the underlying mech_type and
-   specified options, additional token exchanges may be performed in the
-   course of context establishment; such exchanges are accommodated by
-   GSS_S_CONTINUE_NEEDED status returns from GSS_Init_sec_context() and
-   GSS_Accept_sec_context().
-
-   Either party to an established context may invoke
-   GSS_Delete_sec_context() to flush context information when a context
-   is no longer required. GSS_Process_context_token() is used to process
-   received tokens carrying context-level control information.
-   GSS_Context_time() allows a caller to determine the length of time
-   for which an established context will remain valid.
-
-
-
-Linn                        Standards Track                    [Page 41]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   GSS_Inquire_context() returns status information describing context
-   characteristics. GSS_Wrap_size_limit() allows a caller to determine
-   the size of a token which will be generated by a GSS_Wrap()
-   operation.  GSS_Export_sec_context() and GSS_Import_sec_context()
-   enable transfer of active contexts between processes on an end
-   system.
-
-2.2.1:  GSS_Init_sec_context call
-
-   Inputs:
-
-   o  claimant_cred_handle CREDENTIAL HANDLE, -- NULL specifies "use
-   -- default"
-
-   o  input_context_handle CONTEXT HANDLE, -- 0
-   -- (GSS_C_NO_CONTEXT) specifies "none assigned yet"
-
-   o  targ_name INTERNAL NAME,
-
-   o  mech_type OBJECT IDENTIFIER, -- NULL parameter specifies "use
-   -- default"
-
-   o  deleg_req_flag BOOLEAN,
-
-   o  mutual_req_flag BOOLEAN,
-
-   o  replay_det_req_flag BOOLEAN,
-
-   o  sequence_req_flag BOOLEAN,
-
-   o  anon_req_flag BOOLEAN,
-
-   o  conf_req_flag BOOLEAN,
-
-   o  integ_req_flag BOOLEAN,
-
-   o  lifetime_req INTEGER, -- 0 specifies default lifetime
-
-   o  chan_bindings OCTET STRING,
-
-   o  input_token OCTET STRING -- NULL or token received from target
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-
-
-
-Linn                        Standards Track                    [Page 42]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  output_context_handle CONTEXT HANDLE,  -- once returned non-NULL,
-   -- caller must release with GSS_Delete_sec_context()
-
-   o  mech_type OBJECT IDENTIFIER, -- actual mechanism always
-   -- indicated, never NULL; caller should treat as read-only
-   -- and should not attempt to release
-
-   o  output_token OCTET STRING, -- NULL or token to pass to context
-   -- target; caller must release with GSS_Release_buffer()
-
-   o  deleg_state BOOLEAN,
-
-   o  mutual_state BOOLEAN,
-
-   o  replay_det_state BOOLEAN,
-
-   o  sequence_state BOOLEAN,
-
-   o  anon_state BOOLEAN,
-
-   o  trans_state BOOLEAN,
-
-   o  prot_ready_state BOOLEAN, -- see Section 1.2.7
-
-   o  conf_avail BOOLEAN,
-
-   o  integ_avail BOOLEAN,
-
-   o  lifetime_rec INTEGER -- in seconds, or reserved value for
-   -- INDEFINITE
-
-   This call may block pending network interactions for those mech_types
-   in which an authentication server or other network entity must be
-   consulted on behalf of a context initiator in order to generate an
-   output_token suitable for presentation to a specified target.
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that context-level information was
-   successfully initialized, and that the returned output_token will
-   provide sufficient information for the target to perform per-message
-   processing on the newly-established context.
-
-   o  GSS_S_CONTINUE_NEEDED indicates that control information in the
-   returned output_token must be sent to the target, and that a reply
-   must be received and passed as the input_token argument
-
-
-
-
-
-Linn                        Standards Track                    [Page 43]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   to a continuation call to GSS_Init_sec_context(), before per-message
-   processing can be performed in conjunction with this context (unless
-   the prot_ready_state value is concurrently returned TRUE).
-
-   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
-   on the input_token failed, preventing further processing from being
-   performed based on that token.
-
-   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks
-   performed on the credential structure referenced by
-   claimant_cred_handle failed, preventing further processing from being
-   performed using that credential structure.
-
-   o  GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that the received
-   input_token contains an incorrect integrity check, so context setup
-   cannot be accomplished.
-
-   o  GSS_S_NO_CRED indicates that no context was established, either
-   because the input cred_handle was invalid, because the referenced
-   credentials are valid for context acceptor use only, because the
-   caller lacks authorization to access the referenced credentials, or
-   because the resolution of default credentials failed.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the credentials provided
-   through the input claimant_cred_handle argument are no longer valid,
-   so context establishment cannot be completed.
-
-   o  GSS_S_BAD_BINDINGS indicates that a mismatch between the caller-
-   provided chan_bindings and those extracted from the input_token was
-   detected, signifying a security-relevant event and preventing context
-   establishment. (This result will be returned by
-   GSS_Init_sec_context() only for contexts where mutual_state is TRUE.)
-
-   o  GSS_S_OLD_TOKEN indicates that the input_token is too old to be
-   checked for integrity. This is a fatal error during context
-   establishment.
-
-   o  GSS_S_DUPLICATE_TOKEN indicates that the input token has a correct
-   integrity check, but is a duplicate of a token already processed.
-   This is a fatal error during context establishment.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-   for the input context_handle provided; this major status will be
-   returned only for successor calls following GSS_S_CONTINUE_ NEEDED
-   status returns.
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 44]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  GSS_S_BAD_NAMETYPE indicates that the provided targ_name is of a
-   type uninterpretable or unsupported by the applicable underlying
-   GSS-API mechanism(s), so context establishment cannot be completed.
-
-   o  GSS_S_BAD_NAME indicates that the provided targ_name is
-   inconsistent in terms of internally-incorporated type specifier
-   information, so context establishment cannot be accomplished.
-
-   o  GSS_S_BAD_MECH indicates receipt of a context establishment token
-   or of a caller request specifying a mechanism unsupported by the
-   local system or with the caller's active credentials
-
-   o  GSS_S_FAILURE indicates that context setup could not be
-   accomplished for reasons unspecified at the GSS-API level, and that
-   no interface-defined recovery action is available.
-
-   This routine is used by a context initiator, and ordinarily emits an
-   output_token suitable for use by the target within the selected
-   mech_type's protocol.  For the case of a multi-step exchange, this
-   output_token will be one in a series, each generated by a successive
-   call. Using information in the credentials structure referenced by
-   claimant_cred_handle, GSS_Init_sec_context() initializes the data
-   structures required to establish a security context with target
-   targ_name.
-
-   The targ_name may be any valid INTERNAL NAME; it need not be an MN.
-   In addition to support for other name types, it is recommended (newly
-   as of GSS-V2, Update 1) that mechanisms be able to accept
-   GSS_C_NO_NAME as an input type for targ_name.  While recommended,
-   such support is not required, and it is recognized that not all
-   mechanisms can construct tokens without explicitly naming the context
-   target, even when mutual authentication of the target is not
-   obtained.  Callers wishing to make use of this facility and concerned
-   with portability should be aware that support for GSS_C_NO_NAME as
-   input targ_name type is unlikely to be provided within mechanism
-   definitions specified prior to GSS-V2, Update 1.
-
-   The claimant_cred_handle must correspond to the same valid
-   credentials structure on the initial call to GSS_Init_sec_context()
-   and on any successor calls resulting from GSS_S_CONTINUE_NEEDED
-   status returns; different protocol sequences modeled by the
-   GSS_S_CONTINUE_NEEDED facility will require access to credentials at
-   different points in the context establishment sequence.
-
-   The caller-provided input_context_handle argument is to be 0
-   (GSS_C_NO_CONTEXT), specifying "not yet assigned", on the first
-   GSS_Init_sec_context()  call relating to a given context. If
-   successful (i.e., if accompanied by major_status GSS_S_COMPLETE or
-
-
-
-Linn                        Standards Track                    [Page 45]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   GSS_S_CONTINUE_NEEDED), and only if successful, the initial
-   GSS_Init_sec_context() call returns a non-zero output_context_handle
-   for use in future references to this context.  Once a non-zero
-   output_context_handle has been returned, GSS-API callers should call
-   GSS_Delete_sec_context() to release context-related resources if
-   errors occur in later phases of context establishment, or when an
-   established context is no longer required. If GSS_Init_sec_context()
-   is passed the handle of a context which is already fully established,
-   GSS_S_FAILURE status is returned.
-
-   When continuation attempts to GSS_Init_sec_context() are needed to
-   perform context establishment, the previously-returned non-zero
-   handle value is entered into the input_context_handle argument and
-   will be echoed in the returned output_context_handle argument. On
-   such continuation attempts (and only on continuation attempts) the
-   input_token value is used, to provide the token returned from the
-   context's target.
-
-   The chan_bindings argument is used by the caller to provide
-   information binding the security context to security-related
-   characteristics (e.g., addresses, cryptographic keys) of the
-   underlying communications channel. See Section 1.1.6 of this document
-   for more discussion of this argument's usage.
-
-   The input_token argument contains a message received from the target,
-   and is significant only on a call to GSS_Init_sec_context() which
-   follows a previous return indicating GSS_S_CONTINUE_NEEDED
-   major_status.
-
-   It is the caller's responsibility to establish a communications path
-   to the target, and to transmit any returned output_token (independent
-   of the accompanying returned major_status value) to the target over
-   that path. The output_token can, however, be transmitted along with
-   the first application-provided input message to be processed by
-   GSS_GetMIC() or GSS_Wrap() in conjunction with a successfully-
-   established context. (Note: when the GSS-V2 prot_ready_state
-   indicator is returned TRUE, it can be possible to transfer a
-   protected message before context establishment is complete:  see also
-   Section 1.2.7)
-
-   The initiator may request various context-level functions through
-   input flags: the deleg_req_flag requests delegation of access rights,
-   the mutual_req_flag requests mutual authentication, the
-   replay_det_req_flag requests that replay detection features be
-   applied to messages transferred on the established context, and the
-   sequence_req_flag requests that sequencing be enforced. (See Section
-
-
-
-
-
-Linn                        Standards Track                    [Page 46]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   1.2.3 for more information on replay detection and sequencing
-   features.)  The anon_req_flag requests that the initiator's identity
-   not be transferred within tokens to be sent to the acceptor.
-
-   The conf_req_flag and integ_req_flag provide informatory inputs to
-   the GSS-API implementation as to whether, respectively, per-message
-   confidentiality and per-message integrity services will be required
-   on the context.  This information is important as an input to
-   negotiating mechanisms.  It is important to recognize, however, that
-   the inclusion of these flags (which are newly defined for GSS-V2)
-   introduces a backward incompatibility with callers implemented to
-   GSS-V1, where the flags were not defined.  Since no GSS-V1 callers
-   would set these flags, even if per-message services are desired,
-   GSS-V2 mechanism implementations which enable such services
-   selectively based on the flags' values may fail to provide them to
-   contexts established for GSS-V1 callers.  It may be appropriate under
-   certain circumstances, therefore, for such mechanism implementations
-   to infer these service request flags to be set if a caller is known
-   to be implemented to GSS-V1.
-
-   Not all of the optionally-requestable features will be available in
-   all underlying mech_types. The corresponding return state values
-   deleg_state, mutual_state, replay_det_state, and sequence_state
-   indicate, as a function of mech_type processing capabilities and
-   initiator-provided input flags, the set of features which will be
-   active on the context.  The returned trans_state value indicates
-   whether the context is transferable to other processes through use of
-   GSS_Export_sec_context().  These state indicators' values are
-   undefined unless either the routine's major_status indicates
-   GSS_S_COMPLETE, or TRUE prot_ready_state is returned along with
-   GSS_S_CONTINUE_NEEDED major_status; for the latter case, it is
-   possible that additional features, not confirmed or indicated along
-   with TRUE prot_ready_state, will be confirmed and indicated when
-   GSS_S_COMPLETE is subsequently returned.
-
-   The returned anon_state and prot_ready_state values are significant
-   for both GSS_S_COMPLETE and GSS_S_CONTINUE_NEEDED major_status
-   returns from GSS_Init_sec_context(). When anon_state is returned
-   TRUE, this indicates that neither the current token nor its
-   predecessors delivers or has delivered the initiator's identity.
-   Callers wishing to perform context establishment only if anonymity
-   support is provided should transfer a returned token from
-   GSS_Init_sec_context() to the peer only if it is accompanied by a
-   TRUE anon_state indicator.  When prot_ready_state is returned TRUE in
-   conjunction with GSS_S_CONTINUE_NEEDED major_status, this indicates
-   that per-message protection operations may be applied on the context:
-   see Section 1.2.7 for further discussion of this facility.
-
-
-
-
-Linn                        Standards Track                    [Page 47]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   Failure to provide the precise set of features requested by the
-   caller does not cause context establishment to fail; it is the
-   caller's prerogative to delete the context if the feature set
-   provided is unsuitable for the caller's use.
-
-   The returned mech_type value indicates the specific mechanism
-   employed on the context; it will never indicate the value for
-   "default".  A valid mech_type result must be returned along with a
-   GSS_S_COMPLETE status return; GSS-API implementations may (but are
-   not required to) also return mech_type along with predecessor calls
-   indicating GSS_S_CONTINUE_NEEDED status or (if a mechanism is
-   determinable) in conjunction with fatal error cases.  For the case of
-   mechanisms which themselves perform negotiation, the returned
-   mech_type result may indicate selection of a mechanism identified by
-   an OID different than that passed in the input mech_type argument,
-   and the returned value may change between successive calls returning
-   GSS_S_CONTINUE_NEEDED and the final call returning GSS_S_COMPLETE.
-
-   The conf_avail return value indicates whether the context supports
-   per-message confidentiality services, and so informs the caller
-   whether or not a request for encryption through the conf_req_flag
-   input to GSS_Wrap() can be honored. In similar fashion, the
-   integ_avail return value indicates whether per-message integrity
-   services are available (through either GSS_GetMIC() or GSS_Wrap()) on
-   the established context. These state indicators' values are undefined
-   unless either the routine's major_status indicates GSS_S_COMPLETE, or
-   TRUE prot_ready_state is returned along with GSS_S_CONTINUE_NEEDED
-   major_status.
-
-   The lifetime_req input specifies a desired upper bound for the
-   lifetime of the context to be established, with a value of 0 used to
-   request a default lifetime. The lifetime_rec return value indicates
-   the length of time for which the context will be valid, expressed as
-   an offset from the present; depending on mechanism capabilities,
-   credential lifetimes, and local policy, it may not correspond to the
-   value requested in lifetime_req.  If no constraints on context
-   lifetime are imposed, this may be indicated by returning a reserved
-   value representing INDEFINITE lifetime_req. The value of lifetime_rec
-   is undefined unless the routine's major_status indicates
-   GSS_S_COMPLETE.
-
-   If the mutual_state is TRUE, this fact will be reflected within the
-   output_token. A call to GSS_Accept_sec_context() at the target in
-   conjunction with such a context will return a token, to be processed
-   by a continuation call to GSS_Init_sec_context(), in order to achieve
-   mutual authentication.
-
-
-
-
-
-Linn                        Standards Track                    [Page 48]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-2.2.2:  GSS_Accept_sec_context call
-
-   Inputs:
-
-   o  acceptor_cred_handle CREDENTIAL HANDLE, -- NULL specifies
-   -- "use default"
-
-   o  input_context_handle CONTEXT HANDLE, -- 0
-   -- (GSS_C_NO_CONTEXT) specifies "not yet assigned"
-
-   o  chan_bindings OCTET STRING,
-
-   o  input_token OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  src_name INTERNAL NAME, -- guaranteed to be MN
-   -- once returned, caller must release with GSS_Release_name()
-
-   o  mech_type OBJECT IDENTIFIER, -- caller should treat as
-   -- read-only; does not need to be released
-
-   o  output_context_handle CONTEXT HANDLE, -- once returned
-   -- non-NULL in context establishment sequence, caller
-   -- must release with GSS_Delete_sec_context()
-
-   o  deleg_state BOOLEAN,
-
-   o  mutual_state BOOLEAN,
-
-   o  replay_det_state BOOLEAN,
-
-   o  sequence_state BOOLEAN,
-
-   o  anon_state BOOLEAN,
-
-   o  trans_state BOOLEAN,
-
-   o  prot_ready_state BOOLEAN, -- see Section 1.2.7 for discussion
-
-   o  conf_avail BOOLEAN,
-
-   o  integ_avail BOOLEAN,
-
-
-
-
-Linn                        Standards Track                    [Page 49]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  lifetime_rec INTEGER, -- in seconds, or reserved value for
-   -- INDEFINITE
-
-   o  delegated_cred_handle CREDENTIAL HANDLE, -- if returned non-NULL,
-   -- caller must release with GSS_Release_cred()
-
-   o  output_token OCTET STRING -- NULL or token to pass to context
-   -- initiator; if returned non-NULL, caller must release with
-   -- GSS_Release_buffer()
-
-   This call may block pending network interactions for those mech_types
-   in which a directory service or other network entity must be
-   consulted on behalf of a context acceptor in order to validate a
-   received input_token.
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that context-level data structures were
-   successfully initialized, and that per-message processing can now be
-   performed in conjunction with this context.
-
-   o  GSS_S_CONTINUE_NEEDED indicates that control information in the
-   returned output_token must be sent to the initiator, and that a
-   response must be received and passed as the input_token argument to a
-   continuation call to GSS_Accept_sec_context(), before per-message
-   processing can be performed in conjunction with this context.
-
-   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
-   on the input_token failed, preventing further processing from being
-   performed based on that token.
-
-   o  GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks
-   performed on the credential structure referenced by
-   acceptor_cred_handle failed, preventing further processing from being
-   performed using that credential structure.
-
-   o  GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that the received
-   input_token contains an incorrect integrity check, so context setup
-   cannot be accomplished.
-
-   o  GSS_S_DUPLICATE_TOKEN indicates that the integrity check on the
-   received input_token was correct, but that the input_token was
-   recognized as a duplicate of an input_token already processed. No new
-   context is established.
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 50]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  GSS_S_OLD_TOKEN indicates that the integrity check on the received
-   input_token was correct, but that the input_token is too old to be
-   checked for duplication against previously-processed input_tokens. No
-   new context is established.
-
-   o  GSS_S_NO_CRED indicates that no context was established, either
-   because the input cred_handle was invalid, because the referenced
-   credentials are valid for context initiator use only, because the
-   caller lacks authorization to access the referenced credentials, or
-   because the procedure for default credential resolution failed.
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the credentials provided
-   through the input acceptor_cred_handle argument are no longer valid,
-   so context establishment cannot be completed.
-
-   o  GSS_S_BAD_BINDINGS indicates that a mismatch between the caller-
-   provided chan_bindings and those extracted from the input_token was
-   detected, signifying a security-relevant event and preventing context
-   establishment.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-   for the input context_handle provided; this major status will be
-   returned only for successor calls following GSS_S_CONTINUE_ NEEDED
-   status returns.
-
-   o  GSS_S_BAD_MECH indicates receipt of a context establishment token
-   specifying a mechanism unsupported by the local system or with the
-   caller's active credentials.
-
-   o  GSS_S_FAILURE indicates that context setup could not be
-   accomplished for reasons unspecified at the GSS-API level, and that
-   no interface-defined recovery action is available.
-
-   The GSS_Accept_sec_context() routine is used by a context target.
-   Using information in the credentials structure referenced by the
-   input acceptor_cred_handle, it verifies the incoming input_token and
-   (following the successful completion of a context establishment
-   sequence) returns the authenticated src_name and the mech_type used.
-   The returned src_name is guaranteed to be an MN, processed by the
-   mechanism under which the context was established. The
-   acceptor_cred_handle must correspond to the same valid credentials
-   structure on the initial call to GSS_Accept_sec_context() and on any
-   successor calls resulting from GSS_S_CONTINUE_NEEDED status returns;
-   different protocol sequences modeled by the GSS_S_CONTINUE_NEEDED
-   mechanism will require access to credentials at different points in
-   the context establishment sequence.
-
-
-
-
-
-Linn                        Standards Track                    [Page 51]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   The caller-provided input_context_handle argument is to be 0
-   (GSS_C_NO_CONTEXT), specifying "not yet assigned", on the first
-   GSS_Accept_sec_context() call relating to a given context. If
-   successful (i.e., if accompanied by major_status GSS_S_COMPLETE or
-   GSS_S_CONTINUE_NEEDED), and only if successful, the initial
-   GSS_Accept_sec_context() call returns a non-zero
-   output_context_handle for use in future references to this context.
-   Once a non-zero output_context_handle has been returned, GSS-API
-   callers should call GSS_Delete_sec_context() to release context-
-   related resources if errors occur in later phases of context
-   establishment, or when an established context is no longer required.
-   If GSS_Accept_sec_context() is passed the handle of a context which
-   is already fully established, GSS_S_FAILURE status is returned.
-
-   The chan_bindings argument is used by the caller to provide
-   information binding the security context to security-related
-   characteristics (e.g., addresses, cryptographic keys) of the
-   underlying communications channel. See Section 1.1.6 of this document
-   for more discussion of this argument's usage.
-
-   The returned state results (deleg_state, mutual_state,
-   replay_det_state, sequence_state, anon_state, trans_state, and
-   prot_ready_state) reflect the same information as described for
-   GSS_Init_sec_context(), and their values are significant under the
-   same return state conditions.
-
-   The conf_avail return value indicates whether the context supports
-   per-message confidentiality services, and so informs the caller
-   whether or not a request for encryption through the conf_req_flag
-   input to GSS_Wrap() can be honored. In similar fashion, the
-   integ_avail return value indicates whether per-message integrity
-   services are available (through either GSS_GetMIC()  or GSS_Wrap())
-   on the established context.  These values are significant under the
-   same return state conditions as described under
-   GSS_Init_sec_context().
-
-   The lifetime_rec return value is significant only in conjunction with
-   GSS_S_COMPLETE major_status, and indicates the length of time for
-   which the context will be valid, expressed as an offset from the
-   present.
-
-   The returned mech_type value indicates the specific mechanism
-   employed on the context; it will never indicate the value for
-   "default".  A valid mech_type result must be returned whenever
-   GSS_S_COMPLETE status is indicated; GSS-API implementations may (but
-   are not required to) also return mech_type along with predecessor
-   calls indicating GSS_S_CONTINUE_NEEDED status or (if a mechanism is
-   determinable) in conjunction with fatal error cases.  For the case of
-
-
-
-Linn                        Standards Track                    [Page 52]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   mechanisms which themselves perform negotiation, the returned
-   mech_type result may indicate selection of a mechanism identified by
-   an OID different than that passed in the input mech_type argument,
-   and the returned value may change between successive calls returning
-   GSS_S_CONTINUE_NEEDED and the final call returning GSS_S_COMPLETE.
-
-   The delegated_cred_handle result is significant only when deleg_state
-   is TRUE, and provides a means for the target to reference the
-   delegated credentials. The output_token result, when non-NULL,
-   provides a context-level token to be returned to the context
-   initiator to continue a multi-step context establishment sequence. As
-   noted with GSS_Init_sec_context(), any returned token should be
-   transferred to the context's peer (in this case, the context
-   initiator), independent of the value of the accompanying returned
-   major_status.
-
-   Note: A target must be able to distinguish a context-level
-   input_token, which is passed to GSS_Accept_sec_context(), from the
-   per-message data elements passed to GSS_VerifyMIC()  or GSS_Unwrap().
-   These data elements may arrive in a single application message, and
-   GSS_Accept_sec_context() must be performed before per-message
-   processing can be performed successfully.
-
-2.2.3: GSS_Delete_sec_context call
-
-   Input:
-
-   o  context_handle CONTEXT HANDLE
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_context_token OCTET STRING
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the context was recognized, and that
-   relevant context-specific information was flushed.  If the caller
-   provides a non-null buffer to receive an output_context_token, and
-   the mechanism returns a non-NULL token into that buffer, the returned
-   output_context_token is ready for transfer to the context's peer.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-   for the input context_handle provided, so no deletion was performed.
-
-
-
-
-Linn                        Standards Track                    [Page 53]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  GSS_S_FAILURE indicates that the context is recognized, but that
-   the GSS_Delete_sec_context() operation could not be performed for
-   reasons unspecified at the GSS-API level.
-
-   This call can be made by either peer in a security context, to flush
-   context-specific information. Once a non-zero output_context_handle
-   has been returned by context establishment calls, GSS-API callers
-   should call GSS_Delete_sec_context() to release context-related
-   resources if errors occur in later phases of context establishment,
-   or when an established context is no longer required.  This call may
-   block pending network interactions for mech_types in which active
-   notification must be made to a central server when a security context
-   is to be deleted.
-
-   If a non-null output_context_token parameter is provided by the
-   caller, an output_context_token may be returned to the caller.  If an
-   output_context_token is provided to the caller, it can be passed to
-   the context's peer to inform the peer's GSS-API implementation that
-   the peer's corresponding context information can also be flushed.
-   (Once a context is established, the peers involved are expected to
-   retain cached credential and context-related information until the
-   information's expiration time is reached or until a
-   GSS_Delete_sec_context() call is made.)
-
-   The facility for context_token usage to signal context deletion is
-   retained for compatibility with GSS-API Version 1.  For current
-   usage, it is recommended that both peers to a context invoke
-   GSS_Delete_sec_context() independently, passing a null
-   output_context_token buffer to indicate that no context_token is
-   required.  Implementations of GSS_Delete_sec_context() should delete
-   relevant locally-stored context information.
-
-   Attempts to perform per-message processing on a deleted context will
-   result in error returns.
-
-2.2.4:  GSS_Process_context_token call
-
-   Inputs:
-
-   o  context_handle CONTEXT HANDLE,
-
-   o  input_context_token OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-
-
-Linn                        Standards Track                    [Page 54]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the input_context_token was
-   successfully processed in conjunction with the context referenced by
-   context_handle.
-
-   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
-   on the received context_token failed, preventing further processing
-   from being performed with that token.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-   for the input context_handle provided.
-
-   o  GSS_S_FAILURE indicates that the context is recognized, but that
-   the GSS_Process_context_token() operation could not be performed for
-   reasons unspecified at the GSS-API level.
-
-   This call is used to process context_tokens received from a peer once
-   a context has been established, with corresponding impact on
-   context-level state information. One use for this facility is
-   processing of the context_tokens generated by
-   GSS_Delete_sec_context(); GSS_Process_context_token() will not block
-   pending network interactions for that purpose. Another use is to
-   process tokens indicating remote-peer context establishment failures
-   after the point where the local GSS-API implementation has already
-   indicated GSS_S_COMPLETE status.
-
-2.2.5:  GSS_Context_time call
-
-   Input:
-
-   o  context_handle CONTEXT HANDLE,
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  lifetime_rec INTEGER -- in seconds, or reserved value for
-   -- INDEFINITE
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the referenced context is valid, and
-   will remain valid for the amount of time indicated in lifetime_rec.
-
-
-
-
-
-Linn                        Standards Track                    [Page 55]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that data items related to the
-   referenced context have expired.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-   for the input context_handle provided.
-
-   o  GSS_S_FAILURE indicates that the requested operation failed for
-   reasons unspecified at the GSS-API level.
-
-   This call is used to determine the amount of time for which a
-   currently established context will remain valid.
-
-2.2.6: GSS_Inquire_context call
-
-   Input:
-
-   o  context_handle CONTEXT HANDLE,
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  src_name INTERNAL NAME,  -- name of context initiator,
-   -- guaranteed to be MN;
-   -- caller must release with GSS_Release_name() if returned
-
-   o  targ_name INTERNAL NAME,  -- name of context target,
-   -- guaranteed to be MN;
-   -- caller must release with GSS_Release_name() if returned
-
-   o  lifetime_rec INTEGER -- in seconds, or reserved value for
-   -- INDEFINITE or EXPIRED
-
-   o  mech_type OBJECT IDENTIFIER, -- the mechanism supporting this
-   -- security context; caller should treat as read-only and not
-   -- attempt to release
-
-   o  deleg_state BOOLEAN,
-
-   o  mutual_state BOOLEAN,
-
-   o  replay_det_state BOOLEAN,
-
-   o  sequence_state BOOLEAN,
-
-   o  anon_state BOOLEAN,
-
-
-
-Linn                        Standards Track                    [Page 56]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  trans_state BOOLEAN,
-
-   o  prot_ready_state BOOLEAN,
-
-   o  conf_avail BOOLEAN,
-
-   o  integ_avail BOOLEAN,
-
-   o  locally_initiated BOOLEAN, -- TRUE if initiator, FALSE if acceptor
-
-   o  open BOOLEAN, -- TRUE if context fully established, FALSE
-   -- if partly established (in CONTINUE_NEEDED state)
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the referenced context is valid and
-   that deleg_state, mutual_state, replay_det_state, sequence_state,
-   anon_state, trans_state, prot_ready_state, conf_avail, integ_avail,
-   locally_initiated, and open return values describe the corresponding
-   characteristics of the context.  If open is TRUE, lifetime_rec is
-   also returned: if open is TRUE and the context peer's name is known,
-   src_name and targ_name are valid in addition to the values listed
-   above.  The mech_type value must be returned for contexts where open
-   is TRUE and may be returned for contexts where open is FALSE.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-   for the input context_handle provided. Return values other than
-   major_status and minor_status are undefined.
-
-   o  GSS_S_FAILURE indicates that the requested operation failed for
-   reasons unspecified at the GSS-API level. Return values other than
-   major_status and minor_status are undefined.
-
-   This call is used to extract information describing characteristics
-   of a security context.  Note that GSS-API implementations are
-   expected to retain inquirable context data on a context until the
-   context is released by a caller, even after the context has expired,
-   although underlying cryptographic data elements may be deleted after
-   expiration in order to limit their exposure.
-
-2.2.7:   GSS_Wrap_size_limit call
-
-   Inputs:
-
-   o  context_handle CONTEXT HANDLE,
-
-   o  conf_req_flag BOOLEAN,
-
-
-
-
-Linn                        Standards Track                    [Page 57]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  qop INTEGER,
-
-   o  output_size INTEGER
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  max_input_size INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates a successful token size determination:
-   an input message with a length in octets equal to the returned
-   max_input_size value will, when passed to GSS_Wrap() for processing
-   on the context identified by the context_handle parameter with the
-   confidentiality request state as provided in conf_req_flag and with
-   the quality of protection specifier provided in the qop parameter,
-   yield an output token no larger than the value of the provided
-   output_size parameter.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that the provided input
-   context_handle is recognized, but that the referenced context has
-   expired.  Return values other than major_status and minor_status are
-   undefined.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-   for the input context_handle provided. Return values other than
-   major_status and minor_status are undefined.
-
-   o  GSS_S_BAD_QOP indicates that the provided QOP value is not
-   recognized or supported for the context.
-
-   o  GSS_S_FAILURE indicates that the requested operation failed for
-   reasons unspecified at the GSS-API level. Return values other than
-   major_status and minor_status are undefined.
-
-   This call is used to determine the largest input datum which may be
-   passed to GSS_Wrap() without yielding an output token larger than a
-   caller-specified value.
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 58]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-2.2.8:   GSS_Export_sec_context call
-
-   Inputs:
-
-   o  context_handle CONTEXT HANDLE
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  interprocess_token OCTET STRING  -- caller must release
-   -- with GSS_Release_buffer()
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the referenced context has been
-   successfully exported to a representation in the interprocess_token,
-   and is no longer available for use by the caller.
-
-   o  GSS_S_UNAVAILABLE indicates that the context export facility is
-   not available for use on the referenced context.  (This status should
-   occur only for contexts for which the trans_state value is FALSE.)
-   Return values other than major_status and minor_status are undefined.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that the provided input
-   context_handle is recognized, but that the referenced context has
-   expired.  Return values other than major_status and minor_status are
-   undefined.
-
-   o  GSS_S_NO_CONTEXT indicates that no valid context was recognized
-   for the input context_handle provided. Return values other than
-   major_status and minor_status are undefined.
-
-   o  GSS_S_FAILURE indicates that the requested operation failed for
-   reasons unspecified at the GSS-API level. Return values other than
-   major_status and minor_status are undefined.
-
-   This call generates an interprocess token for transfer to another
-   process within an end system, in order to transfer control of a
-   security context to that process.  The recipient of the interprocess
-   token will call GSS_Import_sec_context() to accept the transfer.  The
-   GSS_Export_sec_context() operation is defined for use only with
-   security contexts which are fully and successfully established (i.e.,
-   those for which GSS_Init_sec_context() and GSS_Accept_sec_context()
-   have returned GSS_S_COMPLETE major_status).
-
-
-
-
-Linn                        Standards Track                    [Page 59]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   A successful GSS_Export_sec_context() operation deactivates the
-   security context for the calling process; for this case, the GSS-API
-   implementation shall deallocate all process-wide resources associated
-   with the security context and shall set the context_handle to
-   GSS_C_NO_CONTEXT.  In the event of an error that makes it impossible
-   to complete export of the security context, the GSS-API
-   implementation must not return an interprocess token and should
-   strive to leave the security context referenced by the context_handle
-   untouched.  If this is impossible, it is permissible for the
-   implementation to delete the security context, provided that it also
-   sets the context_handle parameter to GSS_C_NO_CONTEXT.
-
-   Portable callers must not assume that a given interprocess token can
-   be imported by GSS_Import_sec_context() more than once, thereby
-   creating multiple instantiations of a single context.  GSS-API
-   implementations may detect and reject attempted multiple imports, but
-   are not required to do so.
-
-   The internal representation contained within the interprocess token
-   is an implementation-defined local matter.  Interprocess tokens
-   cannot be assumed to be transferable across different GSS-API
-   implementations.
-
-   It is recommended that GSS-API implementations adopt policies suited
-   to their operational environments in order to define the set of
-   processes eligible to import a context, but specific constraints in
-   this area are local matters.  Candidate examples include transfers
-   between processes operating on behalf of the same user identity, or
-   processes comprising a common job.  However, it may be impossible to
-   enforce such policies in some implementations.
-
-   In support of the above goals, implementations may protect the
-   transferred context data by using cryptography to protect data within
-   the interprocess token, or by using interprocess tokens as a means to
-   reference local interprocess communication facilities (protected by
-   other means) rather than storing the context data directly within the
-   tokens.
-
-   Transfer of an open context may, for certain mechanisms and
-   implementations, reveal data about the credential which was used to
-   establish the context.  Callers should, therefore, be cautious about
-   the trustworthiness of processes to which they transfer contexts.
-   Although the GSS-API implementation may provide its own set of
-   protections over the exported context, the caller is responsible for
-   protecting the interprocess token from disclosure, and for taking
-   care that the context is transferred to an appropriate destination
-   process.
-
-
-
-
-Linn                        Standards Track                    [Page 60]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-2.2.9:   GSS_Import_sec_context call
-
-   Inputs:
-
-   o  interprocess_token OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  context_handle CONTEXT HANDLE  -- if successfully returned,
-   -- caller must release with GSS_Delete_sec_context()
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the context represented by the input
-   interprocess_token has been successfully transferred to the caller,
-   and is available for future use via the output context_handle.
-
-   o  GSS_S_NO_CONTEXT indicates that the context represented by the
-   input interprocess_token was invalid. Return values other than
-   major_status and minor_status are undefined.
-
-   o  GSS_S_DEFECTIVE_TOKEN indicates that the input interprocess_token
-   was defective.  Return values other than major_status and
-   minor_status are undefined.
-
-   o  GSS_S_UNAVAILABLE indicates that the context import facility is
-   not available for use on the referenced context.  Return values other
-   than major_status and minor_status are undefined.
-
-   o  GSS_S_UNAUTHORIZED indicates that the context represented by the
-   input interprocess_token is unauthorized for transfer to the caller.
-   Return values other than major_status and minor_status are undefined.
-
-   o  GSS_S_FAILURE indicates that the requested operation failed for
-   reasons unspecified at the GSS-API level. Return values other than
-   major_status and minor_status are undefined.
-
-   This call processes an interprocess token generated by
-   GSS_Export_sec_context(), making the transferred context available
-   for use by the caller.  After a successful GSS_Import_sec_context()
-   operation, the imported context is available for use by the importing
-   process. In particular, the imported context is usable for all per-
-   message operations and may be deleted or exported by its importer.
-   The inability to receive delegated credentials through
-
-
-
-Linn                        Standards Track                    [Page 61]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   gss_import_sec_context() precludes establishment of new contexts
-   based on information delegated to the importer's end system within
-   the context which is being imported, unless those delegated
-   credentials are obtained through separate routines (e.g., XGSS-API
-   calls) outside the GSS-V2 definition.
-
-   For further discussion of the security and authorization issues
-   regarding this call, please see the discussion in Section 2.2.8.
-
-2.3:  Per-message calls
-
-   This group of calls is used to perform per-message protection
-   processing on an established security context. None of these calls
-   block pending network interactions. These calls may be invoked by a
-   context's initiator or by the context's target.  The four members of
-   this group should be considered as two pairs; the output from
-   GSS_GetMIC() is properly input to GSS_VerifyMIC(), and the output
-   from GSS_Wrap() is properly input to GSS_Unwrap().
-
-   GSS_GetMIC() and GSS_VerifyMIC() support data origin authentication
-   and data integrity services. When GSS_GetMIC() is invoked on an input
-   message, it yields a per-message token containing data items which
-   allow underlying mechanisms to provide the specified security
-   services. The original message, along with the generated per-message
-   token, is passed to the remote peer; these two data elements are
-   processed by GSS_VerifyMIC(), which validates the message in
-   conjunction with the separate token.
-
-   GSS_Wrap() and GSS_Unwrap() support caller-requested confidentiality
-   in addition to the data origin authentication and data integrity
-   services offered by GSS_GetMIC() and GSS_VerifyMIC(). GSS_Wrap()
-   outputs a single data element, encapsulating optionally enciphered
-   user data as well as associated token data items.  The data element
-   output from GSS_Wrap() is passed to the remote peer and processed by
-   GSS_Unwrap() at that system. GSS_Unwrap() combines decipherment (as
-   required) with validation of data items related to authentication and
-   integrity.
-
-   Although zero-length tokens are never returned by GSS calls for
-   transfer to a context's peer, a zero-length object may be passed by a
-   caller into GSS_Wrap(), in which case the corresponding peer calling
-   GSS_Unwrap() on the transferred token will receive a zero-length
-   object as output from GSS_Unwrap().  Similarly, GSS_GetMIC() can be
-   called on an empty object, yielding a MIC which GSS_VerifyMIC() will
-   successfully verify against the active security context in
-   conjunction with a zero-length object.
-
-
-
-
-
-Linn                        Standards Track                    [Page 62]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-2.3.1:  GSS_GetMIC call
-
-   Note: This call is functionally equivalent to the GSS_Sign call as
-   defined in previous versions of this specification. In the interests
-   of backward compatibility, it is recommended that implementations
-   support this function under both names for the present; future
-   references to this function as GSS_Sign are deprecated.
-
-   Inputs:
-
-   o  context_handle CONTEXT HANDLE,
-
-   o  qop_req INTEGER, -- 0 specifies default QOP
-
-   o  message OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  per_msg_token OCTET STRING  -- caller must release
-   -- with GSS_Release_buffer()
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that an integrity check, suitable for an
-   established security context, was successfully applied and that the
-   message and corresponding per_msg_token are ready for transmission.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data items
-   have expired, so that the requested operation cannot be performed.
-
-   o  GSS_S_NO_CONTEXT indicates that no context was recognized for the
-   input context_handle provided.
-
-   o  GSS_S_BAD_QOP indicates that the provided QOP value is not
-   recognized or supported for the context.
-
-   o  GSS_S_FAILURE indicates that the context is recognized, but that
-   the requested operation could not be performed for reasons
-   unspecified at the GSS-API level.
-
-   Using the security context referenced by context_handle, apply an
-   integrity check to the input message (along with timestamps and/or
-   other data included in support of mech_type-specific mechanisms) and
-   (if GSS_S_COMPLETE status is indicated) return the result in
-
-
-
-Linn                        Standards Track                    [Page 63]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   per_msg_token. The qop_req parameter, interpretation of which is
-   discussed in Section 1.2.4, allows quality-of-protection control. The
-   caller passes the message and the per_msg_token to the target.
-
-   The GSS_GetMIC() function completes before the message and
-   per_msg_token is sent to the peer; successful application of
-   GSS_GetMIC() does not guarantee that a corresponding GSS_VerifyMIC()
-   has been (or can necessarily be) performed successfully when the
-   message arrives at the destination.
-
-   Mechanisms which do not support per-message protection services
-   should return GSS_S_FAILURE if this routine is called.
-
-2.3.2:  GSS_VerifyMIC call
-
-   Note: This call is functionally equivalent to the GSS_Verify call as
-   defined in previous versions of this specification. In the interests
-   of backward compatibility, it is recommended that implementations
-   support this function under both names for the present; future
-   references to this function as GSS_Verify are deprecated.
-
-   Inputs:
-
-   o  context_handle CONTEXT HANDLE,
-
-   o  message OCTET STRING,
-
-   o  per_msg_token OCTET STRING
-
-   Outputs:
-
-   o  qop_state INTEGER,
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the message was successfully
-   verified.
-
-   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
-   on the received per_msg_token failed, preventing further processing
-   from being performed with that token.
-
-   o  GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that the received
-   per_msg_token contains an incorrect integrity check for the message.
-
-
-
-Linn                        Standards Track                    [Page 64]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, and
-   GSS_S_GAP_TOKEN values appear in conjunction with the optional per-
-   message replay detection features described in Section 1.2.3; their
-   semantics are described in that section.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data items
-   have expired, so that the requested operation cannot be performed.
-
-   o  GSS_S_NO_CONTEXT indicates that no context was recognized for the
-   input context_handle provided.
-
-   o  GSS_S_FAILURE indicates that the context is recognized, but that
-   the GSS_VerifyMIC() operation could not be performed for reasons
-   unspecified at the GSS-API level.
-
-   Using the security context referenced by context_handle, verify that
-   the input per_msg_token contains an appropriate integrity check for
-   the input message, and apply any active replay detection or
-   sequencing features. Returns an indication of the quality-of-
-   protection applied to the processed message in the qop_state result.
-
-   Mechanisms which do not support per-message protection services
-   should return GSS_S_FAILURE if this routine is called.
-
-2.3.3: GSS_Wrap call
-
-   Note: This call is functionally equivalent to the GSS_Seal call as
-   defined in previous versions of this specification. In the interests
-   of backward compatibility, it is recommended that implementations
-   support this function under both names for the present; future
-   references to this function as GSS_Seal are deprecated.
-
-   Inputs:
-
-   o  context_handle CONTEXT HANDLE,
-
-   o  conf_req_flag BOOLEAN,
-
-   o  qop_req INTEGER, -- 0 specifies default QOP
-
-   o  input_message OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-
-
-
-Linn                        Standards Track                    [Page 65]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  conf_state BOOLEAN,
-
-   o  output_message OCTET STRING  -- caller must release with
-   -- GSS_Release_buffer()
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the input_message was successfully
-   processed and that the output_message is ready for transmission.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data items
-   have expired, so that the requested operation cannot be performed.
-
-   o  GSS_S_NO_CONTEXT indicates that no context was recognized for the
-   input context_handle provided.
-
-   o  GSS_S_BAD_QOP indicates that the provided QOP value is not
-   recognized or supported for the context.
-
-   o  GSS_S_FAILURE indicates that the context is recognized, but that
-   the GSS_Wrap() operation could not be performed for reasons
-   unspecified at the GSS-API level.
-
-   Performs the data origin authentication and data integrity functions
-   of GSS_GetMIC().  If the input conf_req_flag is TRUE, requests that
-   confidentiality be applied to the input_message.  Confidentiality may
-   not be supported in all mech_types or by all implementations; the
-   returned conf_state flag indicates whether confidentiality was
-   provided for the input_message. The qop_req parameter, interpretation
-   of which is discussed in Section 1.2.4, allows quality-of-protection
-   control.
-
-   When GSS_S_COMPLETE status is returned, the GSS_Wrap() call yields a
-   single output_message data element containing (optionally enciphered)
-   user data as well as control information.
-
-   Mechanisms which do not support per-message protection services
-   should return GSS_S_FAILURE if this routine is called.
-
-2.3.4: GSS_Unwrap call
-
-   Note: This call is functionally equivalent to the GSS_Unseal call as
-   defined in previous versions of this specification. In the interests
-   of backward compatibility, it is recommended that implementations
-   support this function under both names for the present; future
-   references to this function as GSS_Unseal are deprecated.
-
-
-
-
-
-Linn                        Standards Track                    [Page 66]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   Inputs:
-
-   o  context_handle CONTEXT HANDLE,
-
-   o  input_message OCTET STRING
-
-   Outputs:
-
-   o  conf_state BOOLEAN,
-
-   o  qop_state INTEGER,
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_message OCTET STRING  -- caller must release with
-   -- GSS_Release_buffer()
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the input_message was successfully
-   processed and that the resulting output_message is available.
-
-   o  GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
-   on the per_msg_token extracted from the input_message failed,
-   preventing further processing from being performed.
-
-   o  GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that an incorrect
-   integrity check was detected for the message.
-
-   o  GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, and
-   GSS_S_GAP_TOKEN values appear in conjunction with the optional per-
-   message replay detection features described in Section 1.2.3; their
-   semantics are described in that section.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that context-related data items
-   have expired, so that the requested operation cannot be performed.
-
-   o  GSS_S_NO_CONTEXT indicates that no context was recognized for the
-   input context_handle provided.
-
-   o  GSS_S_FAILURE indicates that the context is recognized, but that
-   the GSS_Unwrap() operation could not be performed for reasons
-   unspecified at the GSS-API level.
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 67]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   Processes a data element generated (and optionally enciphered) by
-   GSS_Wrap(), provided as input_message. The returned conf_state value
-   indicates whether confidentiality was applied to the input_message.
-   If conf_state is TRUE, GSS_Unwrap() has deciphered the input_message.
-   Returns an indication of the quality-of-protection applied to the
-   processed message in the qop_state result. GSS_Unwrap() performs the
-   data integrity and data origin authentication checking functions of
-   GSS_VerifyMIC() on the plaintext data. Plaintext data is returned in
-   output_message.
-
-   Mechanisms which do not support per-message protection services
-   should return GSS_S_FAILURE if this routine is called.
-
-2.4:  Support calls
-
-   This group of calls provides support functions useful to GSS-API
-   callers, independent of the state of established contexts. Their
-   characterization with regard to blocking or non-blocking status in
-   terms of network interactions is unspecified.
-
-2.4.1:  GSS_Display_status call
-
-   Inputs:
-
-   o  status_value INTEGER, -- GSS-API major_status or minor_status
-   -- return value
-
-   o  status_type INTEGER, -- 1 if major_status, 2 if minor_status
-
-   o  mech_type OBJECT IDENTIFIER -- mech_type to be used for
-   -- minor_status translation
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  status_string_set SET OF OCTET STRING  -- required calls for
-   -- release by caller are specific to language bindings
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that a valid printable status
-   representation (possibly representing more than one status event
-   encoded within the status_value) is available in the returned
-   status_string_set.
-
-
-
-
-Linn                        Standards Track                    [Page 68]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  GSS_S_BAD_MECH indicates that translation in accordance with an
-   unsupported mech_type was requested, so translation could not be
-   performed.
-
-   o  GSS_S_BAD_STATUS indicates that the input status_value was
-   invalid, or that the input status_type carried a value other than 1
-   or 2, so translation could not be performed.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-   performed for reasons unspecified at the GSS-API level.
-
-   Provides a means for callers to translate GSS-API-returned major and
-   minor status codes into printable string representations.  Note: some
-   language bindings may employ an iterative approach in order to emit
-   successive status components; this approach is acceptable but not
-   required for conformance with the current specification.
-
-   Although not contemplated in [RFC-2078], it has been observed that
-   some existing GSS-API implementations return GSS_S_CONTINUE_NEEDED
-   status when iterating through successive messages returned from
-   GSS_Display_status(). This behavior is deprecated;
-   GSS_S_CONTINUE_NEEDED should be returned only by
-   GSS_Init_sec_context() and GSS_Accept_sec_context().  For maximal
-   portability, however, it is recommended that defensive callers be
-   able to accept and ignore GSS_S_CONTINUE_NEEDED status if indicated
-   by GSS_Display_status() or any other call other than
-   GSS_Init_sec_context() or GSS_Accept_sec_context().
-
-2.4.2:  GSS_Indicate_mechs call
-
-   Input:
-
-   o  (none)
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  mech_set SET OF OBJECT IDENTIFIER  -- caller must release
-   -- with GSS_Release_oid_set()
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that a set of available mechanisms has
-   been returned in mech_set.
-
-
-
-
-Linn                        Standards Track                    [Page 69]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-   performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to determine the set of mechanism types available on
-   the local system. This call is intended for support of specialized
-   callers who need to request non-default mech_type sets from GSS-API
-   calls which accept input mechanism type specifiers.
-
-2.4.3:  GSS_Compare_name call
-
-   Inputs:
-
-   o  name1 INTERNAL NAME,
-
-   o  name2 INTERNAL NAME
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  name_equal BOOLEAN
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that name1 and name2 were comparable, and
-   that the name_equal result indicates whether name1 and name2
-   represent the same entity.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the two input names' types are
-   different and incomparable, so that the comparison operation could
-   not be completed.
-
-   o  GSS_S_BAD_NAME indicates that one or both of the input names was
-   ill-formed in terms of its internal type specifier, so the comparison
-   operation could not be completed.
-
-   o  GSS_S_FAILURE indicates that the call's operation could not be
-   performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to compare two internal name representations to
-   determine whether they refer to the same entity.  If either name
-   presented to GSS_Compare_name() denotes an anonymous principal,
-   GSS_Compare_name() shall indicate FALSE.  It is not required that
-   either or both inputs name1 and name2 be MNs; for some
-
-
-
-
-
-Linn                        Standards Track                    [Page 70]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   implementations and cases, GSS_S_BAD_NAMETYPE may be returned,
-   indicating name incomparability, for the case where neither input
-   name is an MN.
-
-2.4.4:  GSS_Display_name call
-
-   Inputs:
-
-   o  name INTERNAL NAME
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  name_string OCTET STRING, -- caller must release
-   -- with GSS_Release_buffer()
-
-   o  name_type OBJECT IDENTIFIER  -- caller should treat
-   -- as read-only; does not need to be released
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that a valid printable name
-   representation is available in the returned name_string.
-
-   o  GSS_S_BAD_NAME indicates that the contents of the provided name
-   were inconsistent with the internally-indicated name type, so no
-   printable representation could be generated.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-   performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to translate an internal name representation into a
-   printable form with associated namespace type descriptor. The syntax
-   of the printable form is a local matter.
-
-   If the input name represents an anonymous identity, a reserved value
-   (GSS_C_NT_ANONYMOUS) shall be returned for name_type.
-
-   The GSS_C_NO_OID name type is to be returned only when the
-   corresponding internal name was created through import with
-   GSS_C_NO_OID. It is acceptable for mechanisms to normalize names
-   imported with GSS_C_NO_OID into other supported types and, therefore,
-   to display them with types other than GSS_C_NO_OID.
-
-
-
-
-
-Linn                        Standards Track                    [Page 71]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-2.4.5:  GSS_Import_name call
-
-   Inputs:
-
-   o  input_name_string OCTET STRING,
-
-   o  input_name_type OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  output_name INTERNAL NAME  -- caller must release with
-   -- GSS_Release_name()
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that a valid name representation is
-   output in output_name and described by the type value in
-   output_name_type.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the input_name_type is
-   unsupported by the applicable underlying GSS-API mechanism(s), so the
-   import operation could not be completed.
-
-   o  GSS_S_BAD_NAME indicates that the provided input_name_string is
-   ill-formed in terms of the input_name_type, so the import operation
-   could not be completed.
-
-   o  GSS_S_BAD_MECH indicates that the input presented for import was
-   an exported name object and that its enclosed mechanism type was not
-   recognized or was unsupported by the GSS-API implementation.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-   performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to provide a name representation as a contiguous octet
-   string, designate the type of namespace in conjunction with which it
-   should be parsed, and convert that representation to an internal form
-   suitable for input to other GSS-API routines.  The syntax of the
-   input_name_string is defined in conjunction with its associated name
-   type; depending on the input_name_type, the associated
-   input_name_string may or may not be a printable string.  If the
-   input_name_type's value is GSS_C_NO_OID, a mechanism-specific default
-   printable syntax (which shall be specified in the corresponding GSS-
-   V2 mechanism specification) is assumed for the input_name_string;
-
-
-
-Linn                        Standards Track                    [Page 72]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   other input_name_type values as registered by GSS-API implementations
-   can be used to indicate specific non-default name syntaxes. Note: The
-   input_name_type argument serves to describe and qualify the
-   interpretation of the associated input_name_string; it does not
-   specify the data type of the returned output_name.
-
-   If a mechanism claims support for a particular name type, its
-   GSS_Import_name() operation shall be able to accept all possible
-   values conformant to the external name syntax as defined for that
-   name type.  These imported values may correspond to:
-
-      (1) locally registered entities (for which credentials may be
-      acquired),
-
-      (2) non-local entities (for which local credentials cannot be
-      acquired, but which may be referenced as targets of initiated
-      security contexts or initiators of accepted security contexts), or
-      to
-
-      (3) neither of the above.
-
-   Determination of whether a particular name belongs to class (1), (2),
-   or (3) as described above is not guaranteed to be performed by the
-   GSS_Import_name() function.
-
-   The internal name generated by a GSS_Import_name() operation may be a
-   single-mechanism MN, and is likely to be an MN within a single-
-   mechanism implementation, but portable callers must not depend on
-   this property (and must not, therefore, assume that the output from
-   GSS_Import_name() can be passed directly to GSS_Export_name() without
-   first being processed through GSS_Canonicalize_name()).
-
-2.4.6: GSS_Release_name call
-
-   Inputs:
-
-   o  name INTERNAL NAME
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the storage associated with the
-   input name was successfully released.
-
-
-
-Linn                        Standards Track                    [Page 73]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  GSS_S_BAD_NAME indicates that the input name argument did not
-   contain a valid name.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-   performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to release the storage associated with an internal
-   name representation.  This call's specific behavior depends on the
-   language and programming environment within which a GSS-API
-   implementation operates, and is therefore detailed within applicable
-   bindings specifications; in particular, implementation and invocation
-   of this call may be superfluous (and may be omitted) within bindings
-   where memory management is automatic.
-
-2.4.7: GSS_Release_buffer call
-
-   Inputs:
-
-   o  buffer OCTET STRING
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the storage associated with the
-   input buffer was successfully released.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-   performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to release the storage associated with an OCTET STRING
-   buffer allocated by another GSS-API call.  This call's specific
-   behavior depends on the language and programming environment within
-   which a GSS-API implementation operates, and is therefore detailed
-   within applicable bindings specifications; in particular,
-   implementation and invocation of this call may be superfluous (and
-   may be omitted) within bindings where memory management is automatic.
-
-2.4.8: GSS_Release_OID_set call
-
-   Inputs:
-
-   o  buffer SET OF OBJECT IDENTIFIER
-
-
-
-
-Linn                        Standards Track                    [Page 74]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the storage associated with the
-   input object identifier set was successfully released.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-   performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to release the storage associated with an object
-   identifier set object allocated by another GSS-API call.  This call's
-   specific behavior depends on the language and programming environment
-   within which a GSS-API implementation operates, and is therefore
-   detailed within applicable bindings specifications; in particular,
-   implementation and invocation of this call may be superfluous (and
-   may be omitted) within bindings where memory management is automatic.
-
-2.4.9: GSS_Create_empty_OID_set call
-
-   Inputs:
-
-   o  (none)
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  oid_set SET OF OBJECT IDENTIFIER  -- caller must release
-   -- with GSS_Release_oid_set()
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates successful completion
-
-   o  GSS_S_FAILURE indicates that the operation failed
-
-   Creates an object identifier set containing no object identifiers, to
-   which members may be subsequently added using the
-   GSS_Add_OID_set_member() routine.  These routines are intended to be
-   used to construct sets of mechanism object identifiers, for input to
-   GSS_Acquire_cred().
-
-
-
-Linn                        Standards Track                    [Page 75]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-2.4.10: GSS_Add_OID_set_member call
-
-   Inputs:
-
-   o  member_oid OBJECT IDENTIFIER,
-
-   o  oid_set SET OF OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates successful completion
-
-   o  GSS_S_FAILURE indicates that the operation failed
-
-   Adds an Object Identifier to an Object Identifier set.  This routine
-   is intended for use in conjunction with GSS_Create_empty_OID_set()
-   when constructing a set of mechanism OIDs for input to
-   GSS_Acquire_cred().
-
-2.4.11: GSS_Test_OID_set_member call
-
-   Inputs:
-
-   o  member OBJECT IDENTIFIER,
-
-   o  set SET OF OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  present BOOLEAN
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates successful completion
-
-   o  GSS_S_FAILURE indicates that the operation failed
-
-
-
-
-
-Linn                        Standards Track                    [Page 76]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   Interrogates an Object Identifier set to determine whether a
-   specified Object Identifier is a member.  This routine is intended to
-   be used with OID sets returned by GSS_Indicate_mechs(),
-   GSS_Acquire_cred(), and GSS_Inquire_cred().
-
-2.4.12:  GSS_Inquire_names_for_mech call
-
-   Input:
-
-   o  input_mech_type OBJECT IDENTIFIER, -- mechanism type
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  name_type_set SET OF OBJECT IDENTIFIER -- caller must release
-   -- with GSS_Release_oid_set()
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the output name_type_set contains a
-   list of name types which are supported by the locally available
-   mechanism identified by input_mech_type.
-
-   o  GSS_S_BAD_MECH indicates that the mechanism identified by
-   input_mech_type was unsupported within the local implementation,
-   causing the query to fail.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-   performed for reasons unspecified at the GSS-API level.
-
-   Allows callers to determine the set of name types which are
-   supportable by a specific locally-available mechanism.
-
-2.4.13: GSS_Inquire_mechs_for_name call
-
-   Inputs:
-
-   o  input_name INTERNAL NAME,
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-
-
-
-Linn                        Standards Track                    [Page 77]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  mech_types SET OF OBJECT IDENTIFIER  -- caller must release
-   -- with GSS_Release_oid_set()
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that a set of object identifiers,
-   corresponding to the set of mechanisms suitable for processing the
-   input_name, is available in mech_types.
-
-   o  GSS_S_BAD_NAME indicates that the input_name was ill-formed and
-   could not be processed.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the input_name parameter
-   contained an invalid name type or a name type unsupported by the
-   GSS-API implementation.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-   performed for reasons unspecified at the GSS-API level.
-
-   This routine returns the mechanism set with which the input_name may
-   be processed.
-
-   Each mechanism returned will recognize at least one element within
-   the name. It is permissible for this routine to be implemented within
-   a mechanism-independent GSS-API layer, using the type information
-   contained within the presented name, and based on registration
-   information provided by individual mechanism implementations.  This
-   means that the returned mech_types result may indicate that a
-   particular mechanism will understand a particular name when in fact
-   it would refuse to accept that name as input to
-   GSS_Canonicalize_name(), GSS_Init_sec_context(), GSS_Acquire_cred(),
-   or GSS_Add_cred(), due to some property of the particular name rather
-   than a property of the name type.  Thus, this routine should be used
-   only as a pre-filter for a call to a subsequent mechanism-specific
-   routine.
-
-2.4.14: GSS_Canonicalize_name call
-
-   Inputs:
-
-   o  input_name INTERNAL NAME,
-
-   o  mech_type OBJECT IDENTIFIER  -- must be explicit mechanism,
-   -- not "default" specifier or identifier of negotiating mechanism
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-
-
-Linn                        Standards Track                    [Page 78]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  minor_status INTEGER,
-
-   o  output_name INTERNAL NAME  -- caller must release with
-   -- GSS_Release_name()
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that a mechanism-specific reduction of
-   the input_name, as processed by the mechanism identified by
-   mech_type, is available in output_name.
-
-   o  GSS_S_BAD_MECH indicates that the identified mechanism is
-   unsupported for this operation; this may correspond either to a
-   mechanism wholly unsupported by the local GSS-API implementation or
-   to a negotiating mechanism with which the canonicalization operation
-   cannot be performed.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the input name does not contain
-   an element with suitable type for processing by the identified
-   mechanism.
-
-   o  GSS_S_BAD_NAME indicates that the input name contains an element
-   with suitable type for processing by the identified mechanism, but
-   that this element could not be processed successfully.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-   performed for reasons unspecified at the GSS-API level.
-
-   This routine reduces a GSS-API internal name input_name, which may in
-   general contain elements corresponding to multiple mechanisms, to a
-   mechanism-specific Mechanism Name (MN) output_name by applying the
-   translations corresponding to the mechanism identified by mech_type.
-   The contents of input_name are unaffected by the
-   GSS_Canonicalize_name() operation.  References to output_name will
-   remain valid until output_name is released, independent of whether or
-   not input_name is subsequently released.
-
-2.4.15: GSS_Export_name call
-
-   Inputs:
-
-   o  input_name INTERNAL NAME, -- required to be MN
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-
-
-Linn                        Standards Track                    [Page 79]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   o  output_name OCTET STRING  -- caller must release
-   -- with GSS_Release_buffer()
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that a flat representation of the input
-   name is available in output_name.
-
-   o  GSS_S_NAME_NOT_MN indicates that the input name contained elements
-   corresponding to multiple mechanisms, so cannot be exported into a
-   single-mechanism flat form.
-
-   o  GSS_S_BAD_NAME indicates that the input name was an MN, but could
-   not be processed.
-
-   o  GSS_S_BAD_NAMETYPE indicates that the input name was an MN, but
-   that its type is unsupported by the GSS-API implementation.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-   performed for reasons unspecified at the GSS-API level.
-
-   This routine creates a flat name representation, suitable for
-   bytewise comparison or for input to GSS_Import_name() in conjunction
-   with the reserved GSS-API Exported Name Object OID, from a internal-
-   form Mechanism Name (MN) as emitted, e.g., by GSS_Canonicalize_name()
-   or GSS_Accept_sec_context().
-
-   The emitted GSS-API Exported Name Object is self-describing; no
-   associated parameter-level OID need be emitted by this call.  This
-   flat representation consists of a mechanism-independent wrapper
-   layer, defined in Section 3.2 of this document, enclosing a
-   mechanism-defined name representation.
-
-   In all cases, the flat name output by GSS_Export_name() to correspond
-   to a particular input MN must be invariant over time within a
-   particular installation.
-
-   The GSS_S_NAME_NOT_MN status code is provided to enable
-   implementations to reject input names which are not MNs.  It is not,
-   however, required for purposes of conformance to this specification
-   that all non-MN input names must necessarily be rejected.
-
-2.4.16: GSS_Duplicate_name call
-
-   Inputs:
-
-   o  src_name INTERNAL NAME
-
-
-
-
-Linn                        Standards Track                    [Page 80]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  dest_name INTERNAL NAME  -- caller must release
-   -- with GSS_Release_name()
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that dest_name references an internal
-   name object containing the same name as passed to src_name.
-
-   o  GSS_S_BAD_NAME indicates that the input name was invalid.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-   performed for reasons unspecified at the GSS-API level.
-
-   This routine takes input internal name src_name, and returns another
-   reference (dest_name) to that name which can be used even if src_name
-   is later freed.  (Note: This may be implemented by copying or through
-   use of reference counts.)
-
-3: Data Structure Definitions for GSS-V2 Usage
-
-   Subsections of this section define, for interoperability and
-   portability purposes, certain data structures for use with GSS-V2.
-
-3.1: Mechanism-Independent Token Format
-
-   This section specifies a mechanism-independent level of encapsulating
-   representation for the initial token of a GSS-API context
-   establishment sequence, incorporating an identifier of the mechanism
-   type to be used on that context and enabling tokens to be interpreted
-   unambiguously at GSS-API peers. Use of this format is required for
-   initial context establishment tokens of Internet standards-track
-   GSS-API mechanisms; use in non-initial tokens is optional.
-
-   The encoding format for the token tag is derived from ASN.1 and DER
-   (per illustrative ASN.1 syntax included later within this
-   subsection), but its concrete representation is defined directly in
-   terms of octets rather than at the ASN.1 level in order to facilitate
-   interoperable implementation without use of general ASN.1 processing
-   code.  The token tag consists of the following elements, in order:
-
-      1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that
-      -- constructed form, definite length encoding follows.
-
-
-
-Linn                        Standards Track                    [Page 81]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-      2. Token length octets, specifying length of subsequent data
-      (i.e., the summed lengths of elements 3-5 in this list, and of the
-      mechanism-defined token object following the tag).  This element
-      comprises a variable number of octets:
-
-         2a. If the indicated value is less than 128, it shall be
-         represented in a single octet with bit 8 (high order) set to
-         "0" and the remaining bits representing the value.
-
-         2b. If the indicated value is 128 or more, it shall be
-         represented in two or more octets, with bit 8 of the first
-         octet set to "1" and the remaining bits of the first octet
-         specifying the number of additional octets.  The subsequent
-         octets carry the value, 8 bits per octet, most significant
-         digit first.  The minimum number of octets shall be used to
-         encode the length (i.e., no octets representing leading zeros
-         shall be included within the length encoding).
-
-      3. 0x06 -- Tag for OBJECT IDENTIFIER
-
-      4. Object identifier length -- length (number of octets) of
-      -- the encoded object identifier contained in element 5,
-      -- encoded per rules as described in 2a. and 2b. above.
-
-      5. Object identifier octets -- variable number of octets,
-      -- encoded per ASN.1 BER rules:
-
-         5a. The first octet contains the sum of two values: (1) the
-         top-level object identifier component, multiplied by 40
-         (decimal), and (2) the second-level object identifier
-         component.  This special case is the only point within an
-         object identifier encoding where a single octet represents
-         contents of more than one component.
-
-         5b. Subsequent octets, if required, encode successively-lower
-         components in the represented object identifier.  A component's
-         encoding may span multiple octets, encoding 7 bits per octet
-         (most significant bits first) and with bit 8 set to "1" on all
-         but the final octet in the component's encoding.  The minimum
-         number of octets shall be used to encode each component (i.e.,
-         no octets representing leading zeros shall be included within a
-         component's encoding).
-
-      (Note: In many implementations, elements 3-5 may be stored and
-      referenced as a contiguous string constant.)
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 82]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   The token tag is immediately followed by a mechanism-defined token
-   object.  Note that no independent size specifier intervenes following
-   the object identifier value to indicate the size of the mechanism-
-   defined token object.  While ASN.1 usage within mechanism-defined
-   tokens is permitted, there is no requirement that the mechanism-
-   specific innerContextToken, innerMsgToken, and sealedUserData data
-   elements must employ ASN.1 BER/DER encoding conventions.
-
-   The following ASN.1 syntax is included for descriptive purposes only,
-   to illustrate structural relationships among token and tag objects.
-   For interoperability purposes, token and tag encoding shall be
-   performed using the concrete encoding procedures described earlier in
-   this subsection.
-
-      GSS-API DEFINITIONS ::=
-
-      BEGIN
-
-      MechType ::= OBJECT IDENTIFIER
-      -- data structure definitions
-      -- callers must be able to distinguish among
-      -- InitialContextToken, SubsequentContextToken,
-      -- PerMsgToken, and SealedMessage data elements
-      -- based on the usage in which they occur
-
-      InitialContextToken ::=
-      -- option indication (delegation, etc.) indicated within
-      -- mechanism-specific token
-      [APPLICATION 0] IMPLICIT SEQUENCE {
-              thisMech MechType,
-              innerContextToken ANY DEFINED BY thisMech
-                 -- contents mechanism-specific
-                 -- ASN.1 structure not required
-              }
-
-      SubsequentContextToken ::= innerContextToken ANY
-      -- interpretation based on predecessor InitialContextToken
-      -- ASN.1 structure not required
-
-      PerMsgToken ::=
-      -- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
-      -- ASN.1 structure not required
-              innerMsgToken ANY
-
-      SealedMessage ::=
-      -- as emitted by GSS_Wrap and processed by GSS_Unwrap
-      -- includes internal, mechanism-defined indicator
-      -- of whether or not encrypted
-
-
-
-Linn                        Standards Track                    [Page 83]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-      -- ASN.1 structure not required
-              sealedUserData ANY
-
-      END
-
-3.2: Mechanism-Independent Exported Name Object Format
-
-   This section specifies a mechanism-independent level of encapsulating
-   representation for names exported via the GSS_Export_name() call,
-   including an object identifier representing the exporting mechanism.
-   The format of names encapsulated via this representation shall be
-   defined within individual mechanism drafts.  The Object Identifier
-   value to indicate names of this type is defined in Section 4.7 of
-   this document.
-
-   No name type OID is included in this mechanism-independent level of
-   format definition, since (depending on individual mechanism
-   specifications) the enclosed name may be implicitly typed or may be
-   explicitly typed using a means other than OID encoding.
-
-   The bytes within MECH_OID_LEN and NAME_LEN elements are represented
-   most significant byte first (equivalently, in IP network byte order).
-
-        Length    Name          Description
-
-        2               TOK_ID          Token Identifier
-                                        For exported name objects, this
-                                        must be hex 04 01.
-        2               MECH_OID_LEN    Length of the Mechanism OID
-        MECH_OID_LEN    MECH_OID        Mechanism OID, in DER
-        4               NAME_LEN        Length of name
-        NAME_LEN        NAME            Exported name; format defined in
-                                        applicable mechanism draft.
-
-   A concrete example of the contents of an exported name object,
-   derived from the Kerberos Version 5 mechanism, is as follows:
-
-   04 01 00 0B 06 09 2A 86 48 86 F7 12 01 02 02 hx xx xx xl pp qq ... zz
-
-   04 01        mandatory token identifier
-
-   00 0B        2-byte length of the immediately following DER-encoded
-                ASN.1 value of type OID, most significant octet first
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 84]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   06 09 2A 86 48 86 F7 12 01 02 02    DER-encoded ASN.1 value
-                                       of type OID; Kerberos V5
-                                       mechanism OID indicates
-                                       Kerberos V5 exported name
-
-          in Detail:      06                  Identifier octet (6=OID)
-                          09                           Length octet(s)
-                          2A 86 48 86 F7 12 01 02 02   Content octet(s)
-
-   hx xx xx xl   4-byte length of the immediately following exported
-                 name blob, most significant octet first
-
-   pp qq ... zz  exported name blob of specified length,
-                 bits and bytes specified in the
-                 (Kerberos 5) GSS-API v2 mechanism spec
-
-4: Name Type Definitions
-
-   This section includes definitions for name types and associated
-   syntaxes which are defined in a mechanism-independent fashion at the
-   GSS-API level rather than being defined in individual mechanism
-   specifications.
-
-4.1: Host-Based Service Name Form
-
-   This name form shall be represented by the Object Identifier:
-
-   {iso(1) member-body(2) United States(840) mit(113554) infosys(1)
-   "gssapi(2) generic(1) service_name(4)}.
-
-   The recommended symbolic name for this type is
-   "GSS_C_NT_HOSTBASED_SERVICE".
-
-   For reasons of compatibility with existing implementations, it is
-   recommended that this OID be used rather than the alternate value as
-   included in [RFC-2078]:
-
-   {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
-   2(gss-host-based-services)}
-
-   While it is not recommended that this alternate value be emitted on
-   output by GSS implementations, it is recommended that it be accepted
-   on input as equivalent to the recommended value.
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 85]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   This name type is used to represent services associated with host
-   computers.  Support for this name form is recommended to mechanism
-   designers in the interests of portability, but is not mandated by
-   this specification. This name form is constructed using two elements,
-   "service" and "hostname", as follows:
-
-   service@hostname
-
-   When a reference to a name of this type is resolved, the "hostname"
-   may (as an example implementation strategy) be canonicalized by
-   attempting a DNS lookup and using the fully-qualified domain name
-   which is returned, or by using the "hostname" as provided if the DNS
-   lookup fails.  The canonicalization operation also maps the host's
-   name into lower-case characters.
-
-   The "hostname" element may be omitted. If no "@" separator is
-   included, the entire name is interpreted as the service specifier,
-   with the "hostname" defaulted to the canonicalized name of the local
-   host.
-
-   Documents specifying means for GSS integration into a particular
-   protocol should state either:
-
-      (a) that a specific IANA-registered name associated with that
-      protocol shall be used for the "service" element (this admits, if
-      needed, the possibility that a single name can be registered and
-      shared among a related set of protocols), or
-
-      (b) that the generic name "host" shall be used for the "service"
-      element, or
-
-      (c) that, for that protocol, fallback in specified order (a, then
-      b) or (b, then a) shall be applied.
-
-   IANA registration of specific names per (a) should be handled in
-   accordance with the "Specification Required" assignment policy,
-   defined by BCP 26, RFC 2434 as follows: "Values and their meaning
-   must be documented in an RFC or other available reference, in
-   sufficient detail so that interoperability between independent
-   implementations is possible."
-
-4.2: User Name Form
-
-   This name form shall be represented by the Object Identifier {iso(1)
-   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
-   generic(1) user_name(1)}. The recommended mechanism-independent
-   symbolic name for this type is "GSS_C_NT_USER_NAME". (Note: the same
-
-
-
-
-Linn                        Standards Track                    [Page 86]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   name form and OID is defined within the Kerberos V5 GSS-API
-   mechanism, but the symbolic name recommended there begins with a
-   "GSS_KRB5_NT_" prefix.)
-
-   This name type is used to indicate a named user on a local system.
-   Its syntax and interpretation may be OS-specific. This name form is
-   constructed as:
-
-   username
-
-4.3: Machine UID Form
-
-   This name form shall be represented by the Object Identifier {iso(1)
-   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
-   generic(1) machine_uid_name(2)}.  The recommended mechanism-
-   independent symbolic name for this type is
-   "GSS_C_NT_MACHINE_UID_NAME".  (Note: the same name form and OID is
-   defined within the Kerberos V5 GSS-API mechanism, but the symbolic
-   name recommended there begins with a "GSS_KRB5_NT_" prefix.)
-
-   This name type is used to indicate a numeric user identifier
-   corresponding to a user on a local system.  Its interpretation is
-   OS-specific.  The gss_buffer_desc representing a name of this type
-   should contain a locally-significant user ID, represented in host
-   byte order.  The GSS_Import_name() operation resolves this uid into a
-   username, which is then treated as the User Name Form.
-
-4.4: String UID Form
-
-   This name form shall be represented by the Object Identifier {iso(1)
-   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
-   generic(1) string_uid_name(3)}.  The recommended symbolic name for
-   this type is "GSS_C_NT_STRING_UID_NAME".  (Note: the same name form
-   and OID is defined within the Kerberos V5 GSS-API mechanism, but the
-   symbolic name recommended there begins with a "GSS_KRB5_NT_" prefix.)
-
-   This name type is used to indicate a string of digits representing
-   the numeric user identifier of a user on a local system.  Its
-   interpretation is OS-specific. This name type is similar to the
-   Machine UID Form, except that the buffer contains a string
-   representing the user ID.
-
-4.5: Anonymous Nametype
-
-   The following Object Identifier value is provided as a means to
-   identify anonymous names, and can be compared against in order to
-   determine, in a mechanism-independent fashion, whether a name refers
-   to an anonymous principal:
-
-
-
-Linn                        Standards Track                    [Page 87]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
-   3(gss-anonymous-name)}
-
-   The recommended symbolic name corresponding to this definition is
-   GSS_C_NT_ANONYMOUS.
-
-4.6: GSS_C_NO_OID
-
-   The recommended symbolic name GSS_C_NO_OID corresponds to a null
-   input value instead of an actual object identifier.  Where specified,
-   it indicates interpretation of an associated name based on a
-   mechanism-specific default printable syntax.
-
-4.7: Exported Name Object
-
-   Name objects of the Mechanism-Independent Exported Name Object type,
-   as defined in Section 3.2 of this document, will be identified with
-   the following Object Identifier:
-
-   {1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
-   4(gss-api-exported-name)}
-
-   The recommended symbolic name corresponding to this definition is
-   GSS_C_NT_EXPORT_NAME.
-
-4.8: GSS_C_NO_NAME
-
-   The recommended symbolic name GSS_C_NO_NAME indicates that no name is
-   being passed within a particular value of a parameter used for the
-   purpose of transferring names. Note: GSS_C_NO_NAME is not an actual
-   name type, and is not represented by an OID; its acceptability in
-   lieu of an actual name is confined to specific calls
-   (GSS_Acquire_cred(), GSS_Add_cred(), and GSS_Init_sec_context()) with
-   usages as identified within this specification.
-
-5:  Mechanism-Specific Example Scenarios
-
-   This section provides illustrative overviews of the use of various
-   candidate mechanism types to support the GSS-API. These discussions
-   are intended primarily for readers familiar with specific security
-   technologies, demonstrating how GSS-API functions can be used and
-   implemented by candidate underlying mechanisms. They should not be
-   regarded as constrictive to implementations or as defining the only
-   means through which GSS-API functions can be realized with a
-   particular underlying technology, and do not demonstrate all GSS-API
-   features with each technology.
-
-
-
-
-
-Linn                        Standards Track                    [Page 88]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-5.1: Kerberos V5, single-TGT
-
-   OS-specific login functions yield a TGT to the local realm Kerberos
-   server; TGT is placed in a credentials structure for the client.
-   Client calls GSS_Acquire_cred()  to acquire a cred_handle in order to
-   reference the credentials for use in establishing security contexts.
-
-   Client calls GSS_Init_sec_context().  If the requested service is
-   located in a different realm, GSS_Init_sec_context()  gets the
-   necessary TGT/key pairs needed to traverse the path from local to
-   target realm; these data are placed in the owner's TGT cache. After
-   any needed remote realm resolution, GSS_Init_sec_context() yields a
-   service ticket to the requested service with a corresponding session
-   key; these data are stored in conjunction with the context. GSS-API
-   code sends KRB_TGS_REQ request(s) and receives KRB_TGS_REP
-   response(s) (in the successful case) or KRB_ERROR.
-
-   Assuming success, GSS_Init_sec_context()  builds a Kerberos-formatted
-   KRB_AP_REQ message, and returns it in output_token.  The client sends
-   the output_token to the service.
-
-   The service passes the received token as the input_token argument to
-   GSS_Accept_sec_context(),  which verifies the authenticator, provides
-   the service with the client's authenticated name, and returns an
-   output_context_handle.
-
-   Both parties now hold the session key associated with the service
-   ticket, and can use this key in subsequent GSS_GetMIC(),
-   GSS_VerifyMIC(),  GSS_Wrap(), and GSS_Unwrap() operations.
-
-5.2: Kerberos V5, double-TGT
-
-   TGT acquisition as above.
-
-   Note: To avoid unnecessary frequent invocations of error paths when
-   implementing the GSS-API atop Kerberos V5, it seems appropriate to
-   represent "single-TGT K-V5" and "double-TGT K-V5" with separate
-   mech_types, and this discussion makes that assumption.
-
-   Based on the (specified or defaulted) mech_type,
-   GSS_Init_sec_context()  determines that the double-TGT protocol
-   should be employed for the specified target. GSS_Init_sec_context()
-   returns GSS_S_CONTINUE_NEEDED major_status, and its returned
-   output_token contains a request to the service for the service's TGT.
-   (If a service TGT with suitably long remaining lifetime already
-   exists in a cache, it may be usable, obviating the need for this
-   step.) The client passes the output_token to the service.  Note: this
-   scenario illustrates a different use for the GSS_S_CONTINUE_NEEDED
-
-
-
-Linn                        Standards Track                    [Page 89]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   status return facility than for support of mutual authentication;
-   note that both uses can coexist as successive operations within a
-   single context establishment operation.
-
-   The service passes the received token as the input_token argument to
-   GSS_Accept_sec_context(),  which recognizes it as a request for TGT.
-   (Note that current Kerberos V5 defines no intra-protocol mechanism to
-   represent such a request.) GSS_Accept_sec_context() returns
-   GSS_S_CONTINUE_NEEDED major_status and provides the service's TGT in
-   its output_token. The service sends the output_token to the client.
-
-   The client passes the received token as the input_token argument to a
-   continuation of GSS_Init_sec_context(). GSS_Init_sec_context() caches
-   the received service TGT and uses it as part of a service ticket
-   request to the Kerberos authentication server, storing the returned
-   service ticket and session key in conjunction with the context.
-   GSS_Init_sec_context() builds a Kerberos-formatted authenticator, and
-   returns it in output_token along with GSS_S_COMPLETE return
-   major_status. The client sends the output_token to the service.
-
-   Service passes the received token as the input_token argument to a
-   continuation call to GSS_Accept_sec_context().
-   GSS_Accept_sec_context()  verifies the authenticator, provides the
-   service with the client's authenticated name, and returns
-   major_status GSS_S_COMPLETE.
-
-   GSS_GetMIC(),  GSS_VerifyMIC(), GSS_Wrap(), and GSS_Unwrap()  as
-   above.
-
-5.3:  X.509 Authentication Framework
-
-   This example illustrates use of the GSS-API in conjunction with
-   public-key mechanisms, consistent with the X.509 Directory
-   Authentication Framework.
-
-   The GSS_Acquire_cred() call establishes a credentials structure,
-   making the client's private key accessible for use on behalf of the
-   client.
-
-   The client calls GSS_Init_sec_context(), which interrogates the
-   Directory to acquire (and validate) a chain of public-key
-   certificates, thereby collecting the public key of the service.  The
-   certificate validation operation determines that suitable integrity
-   checks were applied by trusted authorities and that those
-   certificates have not expired. GSS_Init_sec_context() generates a
-   secret key for use in per-message protection operations on the
-   context, and enciphers that secret key under the service's public
-   key.
-
-
-
-Linn                        Standards Track                    [Page 90]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   The enciphered secret key, along with an authenticator quantity
-   signed with the client's private key, is included in the output_token
-   from GSS_Init_sec_context().  The output_token also carries a
-   certification path, consisting of a certificate chain leading from
-   the service to the client; a variant approach would defer this path
-   resolution to be performed by the service instead of being asserted
-   by the client. The client application sends the output_token to the
-   service.
-
-   The service passes the received token as the input_token argument to
-   GSS_Accept_sec_context(). GSS_Accept_sec_context() validates the
-   certification path, and as a result determines a certified binding
-   between the client's distinguished name and the client's public key.
-   Given that public key, GSS_Accept_sec_context() can process the
-   input_token's authenticator quantity and verify that the client's
-   private key was used to sign the input_token. At this point, the
-   client is authenticated to the service. The service uses its private
-   key to decipher the enciphered secret key provided to it for per-
-   message protection operations on the context.
-
-   The client calls GSS_GetMIC() or GSS_Wrap() on a data message, which
-   causes per-message authentication, integrity, and (optional)
-   confidentiality facilities to be applied to that message. The service
-   uses the context's shared secret key to perform corresponding
-   GSS_VerifyMIC()  and GSS_Unwrap() calls.
-
-6:  Security Considerations
-
-   This document specifies a service interface for security facilities
-   and services; as such, security considerations are considered
-   throughout the specification.  Nonetheless, it is appropriate to
-   summarize certain specific points relevant to GSS-API implementors
-   and calling applications.  Usage of the GSS-API interface does not in
-   itself provide security services or assurance; instead, these
-   attributes are dependent on the underlying mechanism(s) which support
-   a GSS-API implementation.  Callers must be attentive to the requests
-   made to GSS-API calls and to the status indicators returned by GSS-
-   API, as these specify the security service characteristics which
-   GSS-API will provide.  When the interprocess context transfer
-   facility is used, appropriate local controls should be applied to
-   constrain access to interprocess tokens and to the sensitive data
-   which they contain.
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 91]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-7:  Related Activities
-
-   In order to implement the GSS-API atop existing, emerging, and future
-   security mechanisms:
-
-      object identifiers must be assigned to candidate GSS-API
-      mechanisms and the name types which they support
-
-      concrete data element formats and processing procedures must be
-      defined for candidate mechanisms
-
-   Calling applications must implement formatting conventions which will
-   enable them to distinguish GSS-API tokens from other data carried in
-   their application protocols.
-
-   Concrete language bindings are required for the programming
-   environments in which the GSS-API is to be employed, as [RFC-1509]
-   defines for the C programming language and GSS-V1.  C Language
-   bindings for GSS-V2 are defined in [RFC-2744].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 92]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-8:  Referenced Documents
-
-   [ISO-7498-2]  International Standard ISO 7498-2-1988(E), Security
-                 Architecture.
-
-   [ISOIEC-8824] ISO/IEC 8824, "Specification of Abstract Syntax
-                 Notation One (ASN.1)".
-
-   [ISOIEC-8825] ISO/IEC 8825, "Specification of Basic Encoding Rules
-                 for Abstract Syntax Notation One (ASN.1)".)
-
-   [RFC-1507]:   Kaufman, C., "DASS: Distributed Authentication Security
-                 Service", RFC 1507, September 1993.
-
-   [RFC-1508]:   Linn, J., "Generic Security Service Application Program
-                 Interface", RFC 1508, September 1993.
-
-   [RFC-1509]:   Wray, J., "Generic Security Service API: C-bindings",
-                 RFC 1509, September 1993.
-
-   [RFC-1964]:   Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-                 RFC 1964, June 1996.
-
-   [RFC-2025]:   Adams, C., "The Simple Public-Key GSS-API Mechanism
-                 (SPKM)", RFC 2025, October 1996.
-
-   [RFC-2078]:   Linn, J., "Generic Security Service Application Program
-                 Interface, Version 2", RFC 2078, January 1997.
-
-   [RFC-2203]:   Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
-                 Specification", RFC 2203, September 1997.
-
-   [RFC-2744]:   Wray, J., "Generic Security Service API Version 2 :
-                 C-bindings", RFC 2744, January 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 93]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-APPENDIX A
-
-MECHANISM DESIGN CONSTRAINTS
-
-   The following constraints on GSS-API mechanism designs are adopted in
-   response to observed caller protocol requirements, and adherence
-   thereto is anticipated in subsequent descriptions of GSS-API
-   mechanisms to be documented in standards-track Internet
-   specifications.
-
-   It is strongly recommended that mechanisms offering per-message
-   protection services also offer at least one of the replay detection
-   and sequencing services, as mechanisms offering neither of the latter
-   will fail to satisfy recognized requirements of certain candidate
-   caller protocols.
-
-APPENDIX B
-
-COMPATIBILITY WITH GSS-V1
-
-   It is the intent of this document to define an interface and
-   procedures which preserve compatibility between GSS-V1 [RFC-1508]
-   callers and GSS-V2 providers.  All calls defined in GSS-V1 are
-   preserved, and it has been a goal that GSS-V1 callers should be able
-   to operate atop GSS-V2 provider implementations.  Certain detailed
-   changes, summarized in this section, have been made in order to
-   resolve omissions identified in GSS-V1.
-
-   The following GSS-V1 constructs, while supported within GSS-V2, are
-   deprecated:
-
-      Names for per-message processing routines: GSS_Seal() deprecated
-      in favor of GSS_Wrap(); GSS_Sign() deprecated in favor of
-      GSS_GetMIC(); GSS_Unseal() deprecated in favor of GSS_Unwrap();
-      GSS_Verify() deprecated in favor of GSS_VerifyMIC().
-
-      GSS_Delete_sec_context() facility for context_token usage,
-      allowing mechanisms to signal context deletion, is retained for
-      compatibility with GSS-V1.  For current usage, it is recommended
-      that both peers to a context invoke GSS_Delete_sec_context()
-      independently, passing a null output_context_token buffer to
-      indicate that no context_token is required.  Implementations of
-      GSS_Delete_sec_context() should delete relevant locally-stored
-      context information.
-
-   This GSS-V2 specification adds the following calls which are not
-   present in GSS-V1:
-
-
-
-
-Linn                        Standards Track                    [Page 94]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-      Credential management calls: GSS_Add_cred(),
-      GSS_Inquire_cred_by_mech().
-
-      Context-level calls: GSS_Inquire_context(), GSS_Wrap_size_limit(),
-      GSS_Export_sec_context(), GSS_Import_sec_context().
-
-      Per-message calls: No new calls.  Existing calls have been
-      renamed.
-
-      Support calls: GSS_Create_empty_OID_set(),
-      GSS_Add_OID_set_member(), GSS_Test_OID_set_member(),
-      GSS_Inquire_names_for_mech(), GSS_Inquire_mechs_for_name(),
-      GSS_Canonicalize_name(), GSS_Export_name(), GSS_Duplicate_name().
-
-   This GSS-V2 specification introduces three new facilities applicable
-   to security contexts, indicated using the following context state
-   values which are not present in GSS-V1:
-
-      anon_state, set TRUE to indicate that a context's initiator is
-      anonymous from the viewpoint of the target; Section 1.2.5 of this
-      specification provides a summary description of the GSS-V2
-      anonymity support facility, support and use of which is optional.
-
-      prot_ready_state, set TRUE to indicate that a context may be used
-      for per-message protection before final completion of context
-      establishment; Section 1.2.7 of this specification provides a
-      summary description of the GSS-V2 facility enabling mechanisms to
-      selectively permit per-message protection during context
-      establishment, support and use of which is optional.
-
-      trans_state, set TRUE to indicate that a context is transferable
-      to another process using the GSS-V2 GSS_Export_sec_context()
-      facility.
-
-   These state values are represented (at the C bindings level) in
-   positions within a bit vector which are unused in GSS-V1, and may be
-   safely ignored by GSS-V1 callers.
-
-   New conf_req_flag and integ_req_flag inputs are defined for
-   GSS_Init_sec_context(), primarily to provide information to
-   negotiating mechanisms.  This introduces a compatibility issue with
-   GSS-V1 callers, discussed in section 2.2.1 of this specification.
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                    [Page 95]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   Relative to GSS-V1, GSS-V2 provides additional guidance to GSS-API
-   implementors in the following areas: implementation robustness,
-   credential management, behavior in multi-mechanism configurations,
-   naming support, and inclusion of optional sequencing services.  The
-   token tagging facility as defined in GSS-V2, Section 3.1, is now
-   described directly in terms of octets to facilitate interoperable
-   implementation without general ASN.1 processing code; the
-   corresponding ASN.1 syntax, included for descriptive purposes, is
-   unchanged from that in GSS-V1. For use in conjunction with added
-   naming support facilities, a new Exported Name Object construct is
-   added.  Additional name types are introduced in Section 4.
-
-   This GSS-V2 specification adds the following major_status values
-   which are not defined in GSS-V1:
-
-        GSS_S_BAD_QOP                 unsupported QOP value
-        GSS_S_UNAUTHORIZED            operation unauthorized
-        GSS_S_UNAVAILABLE             operation unavailable
-        GSS_S_DUPLICATE_ELEMENT       duplicate credential element
-                                        requested
-        GSS_S_NAME_NOT_MN                   name contains multi-mechanism
-                                        elements
-        GSS_S_GAP_TOKEN               skipped predecessor token(s)
-                                        detected
-
-   Of these added status codes, only two values are defined to be
-   returnable by calls existing in GSS-V1: GSS_S_BAD_QOP (returnable by
-   GSS_GetMIC() and GSS_Wrap()), and GSS_S_GAP_TOKEN (returnable by
-   GSS_VerifyMIC() and GSS_Unwrap()).
-
-   Additionally, GSS-V2 descriptions of certain calls present in GSS-V1
-   have been updated to allow return of additional major_status values
-   from the set as defined in GSS-V1: GSS_Inquire_cred() has
-   GSS_S_DEFECTIVE_CREDENTIAL and GSS_S_CREDENTIALS_EXPIRED defined as
-   returnable, GSS_Init_sec_context() has GSS_S_OLD_TOKEN,
-   GSS_S_DUPLICATE_TOKEN, and GSS_S_BAD_MECH defined as returnable, and
-   GSS_Accept_sec_context() has GSS_S_BAD_MECH defined as returnable.
-
-APPENDIX C
-
-CHANGES RELATIVE TO RFC-2078
-
-   This document incorporates a number of changes relative to RFC-2078,
-   made primarily in response to implementation experience, for purposes
-   of alignment with the GSS-V2 C language bindings document, and to add
-   informative clarification.  This section summarizes technical changes
-   incorporated.
-
-
-
-
-Linn                        Standards Track                    [Page 96]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-   General:
-
-      Clarified usage of object release routines, and incorporated
-      statement that some may be omitted within certain operating
-      environments.
-
-      Removed GSS_Release_OID, GSS_OID_to_str(), and GSS_Str_to_OID()
-      routines.
-
-      Clarified circumstances under which zero-length tokens may validly
-      exist as inputs and outputs to/from GSS-API calls.
-
-      Added GSS_S_BAD_MIC status code as alias for GSS_S_BAD_SIG.
-
-      For GSS_Display_status(), deferred to language bindings the choice
-      of whether to return multiple status values in parallel or via
-      iteration, and added commentary deprecating return of
-      GSS_S_CONTINUE_NEEDED.
-
-      Adapted and incorporated clarifying material on optional service
-      support, delegation, and interprocess context transfer from C
-      bindings document.
-
-      Added and updated references to related documents, and to current
-      status of cited Kerberos mechanism OID.
-
-      Added general statement about GSS-API calls having no side effects
-      visible at the GSS-API level.
-
-   Context-related (including per-message protection issues):
-
-      Clarified GSS_Delete_sec_context() usage for partially-established
-      contexts.
-
-      Added clarification on GSS_Export_sec_context() and
-      GSS_Import_sec_context() behavior and context usage following an
-      export-import sequence.
-
-      Added informatory conf_req_flag, integ_req_flag inputs to
-      GSS_Init_sec_context().  (Note: this facility introduces a
-      backward incompatibility with GSS-V1 callers, discussed in Section
-      2.2.1; this implication was recognized and accepted in working
-      group discussion.)
-
-      Stated that GSS_S_FAILURE is to be returned if
-      GSS_Init_sec_context() or GSS_Accept_sec_context() is passed the
-      handle of a context which is already fully established.
-
-
-
-
-Linn                        Standards Track                    [Page 97]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-      Re GSS_Inquire_sec_context(), stated that src_name and targ_name
-      are not returned until GSS_S_COMPLETE status is reached; removed
-      use of GSS_S_CONTEXT_EXPIRED status code (replacing with EXPIRED
-      lifetime return value); stated requirement to retain inquirable
-      data until context released by caller; added result value
-      indicating whether or not context is fully open.
-
-      Added discussion of interoperability conditions for mechanisms
-      permitting optional support of QOPs. Removed reference to
-      structured QOP elements in GSS_Verify_MIC().
-
-      Added discussion of use of GSS_S_DUPLICATE_TOKEN status to
-      indicate reflected per-message tokens.
-
-      Clarified use of informational sequencing codes from per-message
-      protection calls in conjunction with GSS_S_COMPLETE and
-      GSS_S_FAILURE major_status returns, adjusting status code
-      descriptions accordingly.
-
-      Added specific statements about impact of GSS_GetMIC() and
-      GSS_Wrap() failures on context state information, and generalized
-      existing statements about impact of processing failures on
-      received per-message tokens.
-
-      For GSS_Init_sec_context() and GSS_Accept_sec_context(), permitted
-      returned mech_type to be valid before GSS_S_COMPLETE, recognizing
-      that the value may change on successive continuation calls in the
-      negotiated mechanism case.
-
-      Deleted GSS_S_CONTEXT_EXPIRED status from
-      GSS_Import_sec_context().
-
-      Added conf_req_flag input to GSS_Wrap_size_limit().
-
-      Stated requirement for mechanisms' support of per-message
-      protection services to be usable concurrently in both directions
-      on a context.
-
-   Credential-related:
-
-      For GSS_Acquire_cred() and GSS_Add_cred(), aligned with C bindings
-      statement of likely non-support for INITIATE or BOTH credentials
-      if input name is neither empty nor a name resulting from applying
-      GSS_Inquire_cred() against the default credential.  Further,
-      stated that an explicit name returned by GSS_Inquire_context()
-      should also be accepted.  Added commentary about potentially
-      time-variant results of default resolution and attendant
-      implications.  Aligned with C bindings re behavior when
-
-
-
-Linn                        Standards Track                    [Page 98]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-      GSS_C_NO_NAME provided for desired_name. In GSS_Acquire_cred(),
-      stated that NULL, rather than empty OID set, should be used for
-      desired_mechs in order to request default mechanism set.
-
-      Added GSS_S_CREDENTIALS_EXPIRED as returnable major_status for
-      GSS_Acquire_cred(), GSS_Add_cred(), also specifying GSS_S_NO_CRED
-      as appropriate return for temporary, user-fixable credential
-      unavailability.  GSS_Acquire_cred() and GSS_Add_cred() are also to
-      return GSS_S_NO_CRED if an authorization failure is encountered
-      upon credential acquisition.
-
-      Removed GSS_S_CREDENTIALS_EXPIRED status return from per-message
-      protection, GSS_Context_time(), and GSS_Inquire_context() calls.
-
-      For GSS_Add_cred(), aligned with C bindings' description of
-      behavior when addition of elements to the default credential is
-      requested.
-
-      Upgraded recommended default credential resolution algorithm to
-      status of requirement for initiator credentials.
-
-      For GSS_Release_cred(), GSS_Inquire_cred(), and
-      GSS_Inquire_cred_by_mech(), clarified behavior for input
-      GSS_C_NO_CREDENTIAL.
-
-   Name-related:
-
-      Aligned GSS_Inquire_mechs_for_name() description with C bindings.
-
-      Removed GSS_S_BAD_NAMETYPE status return from
-      GSS_Duplicate_name(), GSS_Display_name(); constrained its
-      applicability for GSS_Compare_name().
-
-      Aligned with C bindings statement re GSS_Import_name() behavior
-      with GSS_C_NO_OID input name type, and stated that GSS-V2
-      mechanism specifications are to define processing procedures
-      applicable to their mechanisms.  Also clarified GSS_C_NO_OID usage
-      with GSS_Display_name().
-
-      Downgraded reference to name canonicalization via DNS lookup to an
-      example.
-
-      For GSS_Canonicalize_name(), stated that neither negotiated
-      mechanisms nor the default mechanism are supported input
-      mech_types for this operation, and specified GSS_S_BAD_MECH status
-      to be returned in this case.  Clarified that the
-      GSS_Canonicalize_name() operation is non-destructive to its input
-      name.
-
-
-
-Linn                        Standards Track                    [Page 99]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-      Clarified semantics of GSS_C_NT_USER_NAME name type.
-
-      Added descriptions of additional name types.  Also added
-      discussion of GSS_C_NO_NAME and its constrained usage with
-      specific GSS calls.
-
-      Adapted and incorporated C bindings discussion about name
-      comparisons with exported name objects.
-
-      Added recommendation to mechanism designers for support of host-
-      based service name type, deferring any requirement statement to
-      individual mechanism specifications.  Added discussion of host-
-      based service's service name element and proposed approach for
-      IANA registration policy therefor.
-
-      Clarified byte ordering within exported name object.  Stated that
-      GSS_S_BAD_MECH is to be returned if, in the course of attempted
-      import of an exported name object, the name object's enclosed
-      mechanism type is unrecognized or unsupported.
-
-      Stated that mechanisms may optionally accept GSS_C_NO_NAME as an
-      input target name to GSS_Init_sec_context(), with comment that
-      such support is unlikely within mechanisms predating GSS-V2,
-      Update 1.
-
-AUTHOR'S ADDRESS
-
-   John Linn
-   RSA Laboratories
-   20 Crosby Drive
-   Bedford, MA  01730 USA
-
-   Phone: +1 781.687.7817
-   EMail: jlinn@rsasecurity.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                   [Page 100]
-
-RFC 2743                        GSS-API                     January 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Linn                        Standards Track                   [Page 101]
-
diff --git a/doc/standardisation/rfc2744.txt b/doc/standardisation/rfc2744.txt
deleted file mode 100644
index 7f0c61946..000000000
--- a/doc/standardisation/rfc2744.txt
+++ /dev/null
@@ -1,5659 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             J. Wray
-Request for Comments: 2744                                Iris Associates
-Obsoletes: 1509                                              January 2000
-Category: Standards Track
-
-
-          Generic Security Service API Version 2 : C-bindings
-
-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 (2000).  All Rights Reserved.
-
-Abstract
-
-   This document specifies C language bindings for Version 2, Update 1
-   of the Generic Security Service Application Program Interface (GSS-
-   API), which is described at a language-independent conceptual level
-   in RFC-2743 [GSSAPI].  It obsoletes RFC-1509, making specific
-   incremental changes in response to implementation experience and
-   liaison requests.  It is intended, therefore, that this memo or a
-   successor version thereof will become the basis for subsequent
-   progression of the GSS-API specification on the standards track.
-
-   The Generic Security Service Application Programming Interface
-   provides security services to its callers, and is intended for
-   implementation atop a variety of underlying cryptographic mechanisms.
-   Typically, GSS-API callers will be application protocols into which
-   security enhancements are integrated through invocation of services
-   provided by the GSS-API. The GSS-API allows a caller application to
-   authenticate a principal identity associated with a peer application,
-   to delegate rights to a peer, and to apply security services such as
-   confidentiality and integrity on a per-message basis.
-
-
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                     [Page 1]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-1.   Introduction
-
-   The Generic Security Service Application Programming Interface
-   [GSSAPI] provides security services to calling applications.  It
-   allows a communicating application to authenticate the user
-   associated with another application, to delegate rights to another
-   application, and to apply security services such as confidentiality
-   and integrity on a per-message basis.
-
-   There are four stages to using the GSS-API:
-
-   a) The application acquires a set of credentials with which it may
-      prove its identity to other processes. The application's
-      credentials vouch for its global identity, which may or may not be
-      related to any local username under which it may be running.
-
-   b) A pair of communicating applications establish a joint security
-      context using their credentials.  The security context is a pair
-      of GSS-API data structures that contain shared state information,
-      which is required in order that per-message security services may
-      be provided.  Examples of state that might be shared between
-      applications as part of a security context are cryptographic keys,
-      and message sequence numbers.  As part of the establishment of a
-      security context, the context initiator is authenticated to the
-      responder, and may require that the responder is authenticated in
-      turn.  The initiator may optionally give the responder the right
-      to initiate further security contexts, acting as an agent or
-      delegate of the initiator.  This transfer of rights is termed
-      delegation, and is achieved by creating a set of credentials,
-      similar to those used by the initiating application, but which may
-      be used by the responder.
-
-      To establish and maintain the shared information that makes up the
-      security context, certain GSS-API calls will return a token data
-      structure, which is an opaque data type that may contain
-      cryptographically protected data.  The caller of such a GSS-API
-      routine is responsible for transferring the token to the peer
-      application, encapsulated if necessary in an application-
-      application protocol.  On receipt of such a token, the peer
-      application should pass it to a corresponding GSS-API routine
-      which will decode the token and extract the information, updating
-      the security context state information accordingly.
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                     [Page 2]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   c) Per-message services are invoked to apply either:
-
-      integrity and data origin authentication, or confidentiality,
-      integrity and data origin authentication to application data,
-      which are treated by GSS-API as arbitrary octet-strings.  An
-      application transmitting a message that it wishes to protect will
-      call the appropriate GSS-API routine (gss_get_mic or gss_wrap) to
-      apply protection, specifying the appropriate security context, and
-      send the resulting token to the receiving application.  The
-      receiver will pass the received token (and, in the case of data
-      protected by gss_get_mic, the accompanying message-data) to the
-      corresponding decoding routine (gss_verify_mic or gss_unwrap) to
-      remove the protection and validate the data.
-
-   d) At the completion of a communications session (which may extend
-      across several transport connections), each application calls a
-      GSS-API routine to delete the security context.  Multiple contexts
-      may also be used (either successively or simultaneously) within a
-      single communications association, at the option of the
-      applications.
-
-2.   GSS-API Routines
-
-      This section lists the routines that make up the GSS-API, and
-      offers a brief description of the purpose of each routine.
-      Detailed descriptions of each routine are listed in alphabetical
-      order in section 5.
-
-   Table 2-1  GSS-API Credential-management Routines
-
-   Routine                Section              Function
-   -------                -------              --------
-   gss_acquire_cred           5.2  Assume a global identity; Obtain
-                                   a GSS-API credential handle for
-                                   pre-existing credentials.
-   gss_add_cred               5.3  Construct credentials
-                                   incrementally
-   gss_inquire_cred           5.21 Obtain information about a
-                                   credential
-   gss_inquire_cred_by_mech   5.22 Obtain per-mechanism information
-                                   about a credential.
-   gss_release_cred           5.27 Discard a credential handle.
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                     [Page 3]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Table 2-2  GSS-API Context-Level Routines
-
-   Routine                 Section              Function
-   -------                 -------              --------
-   gss_init_sec_context       5.19 Initiate a security context with
-                                   a peer application
-   gss_accept_sec_context     5.1  Accept a security context
-                                   initiated by a
-                                   peer application
-   gss_delete_sec_context     5.9  Discard a security context
-   gss_process_context_token  5.25 Process a token on a security
-                                   context from a peer application
-   gss_context_time           5.7  Determine for how long a context
-                                   will remain valid
-   gss_inquire_context        5.20 Obtain information about a
-                                   security context
-   gss_wrap_size_limit        5.34 Determine token-size limit for
-                                   gss_wrap on a context
-   gss_export_sec_context     5.14 Transfer a security context to
-                                   another process
-   gss_import_sec_context     5.17 Import a transferred context
-
-
-   Table 2-3  GSS-API Per-message Routines
-
-   Routine                 Section              Function
-   -------                 -------              --------
-   gss_get_mic                5.15 Calculate a cryptographic message
-                                   integrity code (MIC) for a
-                                   message; integrity service
-   gss_verify_mic             5.32 Check a MIC against a message;
-                                   verify integrity of a received
-                                   message
-   gss_wrap                   5.33 Attach a MIC to a message, and
-                                   optionally encrypt the message
-                                   content;
-                                   confidentiality service
-   gss_unwrap                 5.31 Verify a message with attached
-                                   MIC, and decrypt message content
-                                   if necessary.
-
-
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                     [Page 4]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Table 2-4  GSS-API Name manipulation Routines
-
-   Routine                 Section              Function
-   -------                 -------              --------
-   gss_import_name            5.16 Convert a contiguous string name
-                                   to internal-form
-   gss_display_name           5.10 Convert internal-form name to
-                                   text
-   gss_compare_name           5.6  Compare two internal-form names
-
-   gss_release_name           5.28 Discard an internal-form name
-   gss_inquire_names_for_mech 5.24 List the name-types supported by
-                                   the specified mechanism
-   gss_inquire_mechs_for_name 5.23 List mechanisms that support the
-                                   specified name-type
-   gss_canonicalize_name      5.5  Convert an internal name to an MN
-   gss_export_name            5.13 Convert an MN to export form
-   gss_duplicate_name         5.12 Create a copy of an internal name
-
-
-   Table 2-5  GSS-API Miscellaneous Routines
-
-   Routine                Section              Function
-   -------                -------              --------
-   gss_add_oid_set_member    5.4  Add an object identifier to
-                                  a set
-   gss_display_status        5.11 Convert a GSS-API status code
-                                  to text
-   gss_indicate_mechs        5.18 Determine available underlying
-                                  authentication mechanisms
-   gss_release_buffer        5.26 Discard a buffer
-   gss_release_oid_set       5.29 Discard a set of object
-                                  identifiers
-   gss_create_empty_oid_set  5.8  Create a set containing no
-                                  object identifiers
-   gss_test_oid_set_member   5.30 Determines whether an object
-                                       identifier is a member of a set.
-
-   Individual GSS-API implementations may augment these routines by
-   providing additional mechanism-specific routines if required
-   functionality is not available from the generic forms. Applications
-   are encouraged to use the generic routines wherever possible on
-   portability grounds.
-
-
-
-
-
-
-
-
-Wray                        Standards Track                     [Page 5]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-3.   Data Types and Calling Conventions
-
-   The following conventions are used by the GSS-API C-language
-   bindings:
-
-3.1. Integer types
-
-   GSS-API uses the following integer data type:
-
-   OM_uint32    32-bit unsigned integer
-
-   Where guaranteed minimum bit-count is important, this portable data
-   type is used by the GSS-API routine definitions.  Individual GSS-API
-   implementations will include appropriate typedef definitions to map
-   this type onto a built-in data type.  If the platform supports the
-   X/Open xom.h header file, the OM_uint32 definition contained therein
-   should be used; the GSS-API header file in Appendix A contains logic
-   that will detect the prior inclusion of xom.h, and will not attempt
-   to re-declare OM_uint32.  If the X/Open header file is not available
-   on the platform, the GSS-API implementation should use the smallest
-   natural unsigned integer type that provides at least 32 bits of
-   precision.
-
-3.2. String and similar data
-
-   Many of the GSS-API routines take arguments and return values that
-   describe contiguous octet-strings.  All such data is passed between
-   the GSS-API and the caller using the gss_buffer_t data type.  This
-   data type is a pointer to a buffer descriptor, which consists of a
-   length field that contains the total number of bytes in the datum,
-   and a value field which contains a pointer to the actual datum:
-
-   typedef struct gss_buffer_desc_struct {
-      size_t    length;
-      void      *value;
-   } gss_buffer_desc, *gss_buffer_t;
-
-   Storage for data returned to the application by a GSS-API routine
-   using the gss_buffer_t conventions is allocated by the GSS-API
-   routine.  The application may free this storage by invoking the
-   gss_release_buffer routine.  Allocation of the gss_buffer_desc object
-   is always the responsibility of the application;  unused
-   gss_buffer_desc objects may be initialized to the value
-   GSS_C_EMPTY_BUFFER.
-
-
-
-
-
-
-
-Wray                        Standards Track                     [Page 6]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-3.2.1. Opaque data types
-
-   Certain multiple-word data items are considered opaque data types at
-   the GSS-API, because their internal structure has no significance
-   either to the GSS-API or to the caller.  Examples of such opaque data
-   types are the input_token parameter to gss_init_sec_context (which is
-   opaque to the caller), and the input_message parameter to gss_wrap
-   (which is opaque to the GSS-API).  Opaque data is passed between the
-   GSS-API and the application using the gss_buffer_t datatype.
-
-3.2.2. Character strings
-
-   Certain multiple-word data items may be regarded as simple ISO
-   Latin-1 character strings.  Examples are the printable strings passed
-   to gss_import_name via the input_name_buffer parameter. Some GSS-API
-   routines also return character strings.  All such character strings
-   are passed between the application and the GSS-API implementation
-   using the gss_buffer_t datatype, which is a pointer to a
-   gss_buffer_desc object.
-
-   When a gss_buffer_desc object describes a printable string, the
-   length field of the gss_buffer_desc should only count printable
-   characters within the string.  In particular, a trailing NUL
-   character should NOT be included in the length count, nor should
-   either the GSS-API implementation or the application assume the
-   presence of an uncounted trailing NUL.
-
-3.3. Object Identifiers
-
-   Certain GSS-API procedures take parameters of the type gss_OID, or
-   Object identifier.  This is a type containing ISO-defined tree-
-   structured values, and is used by the GSS-API caller to select an
-   underlying security mechanism and to specify namespaces.  A value of
-   type gss_OID has the following structure:
-
-   typedef struct gss_OID_desc_struct {
-      OM_uint32   length;
-      void        *elements;
-   } gss_OID_desc, *gss_OID;
-
-   The elements field of this structure points to the first byte of an
-   octet string containing the ASN.1 BER encoding of the value portion
-   of the normal BER TLV encoding of the gss_OID.  The length field
-   contains the number of bytes in this value.  For example, the gss_OID
-   value corresponding to {iso(1) identified-organization(3) icd-
-   ecma(12) member-company(2) dec(1011) cryptoAlgorithms(7) DASS(5)},
-   meaning the DASS X.509 authentication mechanism, has a length field
-   of 7 and an elements field pointing to seven octets containing the
-
-
-
-Wray                        Standards Track                     [Page 7]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   following octal values: 53,14,2,207,163,7,5. GSS-API implementations
-   should provide constant gss_OID values to allow applications to
-   request any supported mechanism, although applications are encouraged
-   on portability grounds to accept the default mechanism.  gss_OID
-   values should also be provided to allow applications to specify
-   particular name types (see section 3.10).  Applications should treat
-   gss_OID_desc values returned by GSS-API routines as read-only.  In
-   particular, the application should not attempt to deallocate them
-   with free().  The gss_OID_desc datatype is equivalent to the X/Open
-   OM_object_identifier datatype[XOM].
-
-3.4. Object Identifier Sets
-
-   Certain GSS-API procedures take parameters of the type gss_OID_set.
-   This type represents one or more object identifiers (section 2.3).  A
-   gss_OID_set object has the following structure:
-
-   typedef struct gss_OID_set_desc_struct {
-      size_t    count;
-      gss_OID   elements;
-   } gss_OID_set_desc, *gss_OID_set;
-
-   The count field contains the number of OIDs within the set.  The
-   elements field is a pointer to an array of gss_OID_desc objects, each
-   of which describes a single OID.  gss_OID_set values are used to name
-   the available mechanisms supported by the GSS-API, to request the use
-   of specific mechanisms, and to indicate which mechanisms a given
-   credential supports.
-
-   All OID sets returned to the application by GSS-API are dynamic
-   objects (the gss_OID_set_desc, the "elements" array of the set, and
-   the "elements" array of each member OID are all dynamically
-   allocated), and this storage must be deallocated by the application
-   using the gss_release_oid_set() routine.
-
-3.5. Credentials
-
-   A credential handle is a caller-opaque atomic datum that identifies a
-   GSS-API credential data structure.  It is represented by the caller-
-   opaque type gss_cred_id_t, which should be implemented as a pointer
-   or arithmetic type.  If a pointer implementation is chosen, care must
-   be taken to ensure that two gss_cred_id_t values may be compared with
-   the == operator.
-
-   GSS-API credentials can contain mechanism-specific principal
-   authentication data for multiple mechanisms.  A GSS-API credential is
-   composed of a set of credential-elements, each of which is applicable
-   to a single mechanism.  A credential may contain at most one
-
-
-
-Wray                        Standards Track                     [Page 8]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   credential-element for each supported mechanism. A credential-element
-   identifies the data needed by a single mechanism to authenticate a
-   single principal, and conceptually contains two credential-references
-   that describe the actual mechanism-specific authentication data, one
-   to be used by GSS-API for initiating contexts,  and one to be used
-   for accepting contexts.  For mechanisms that do not distinguish
-   between acceptor and initiator credentials, both references would
-   point to the same underlying mechanism-specific authentication data.
-
-   Credentials describe a set of mechanism-specific principals, and give
-   their holder the ability to act as any of those principals. All
-   principal identities asserted by a single GSS-API credential should
-   belong to the same entity, although enforcement of this property is
-   an implementation-specific matter.  The GSS-API does not make the
-   actual credentials available to applications; instead a credential
-   handle is used to identify a particular credential, held internally
-   by GSS-API.  The combination of GSS-API credential handle and
-   mechanism identifies the principal whose identity will be asserted by
-   the credential when used with that mechanism.
-
-   The gss_init_sec_context and gss_accept_sec_context routines allow
-   the value GSS_C_NO_CREDENTIAL to be specified as their credential
-   handle parameter.  This special credential-handle indicates a desire
-   by the application to act as a default principal.  While individual
-   GSS-API implementations are free to determine such default behavior
-   as appropriate to the mechanism, the following default behavior by
-   these routines is recommended for portability:
-
-   gss_init_sec_context
-
-      1) If there is only a single principal capable of initiating
-         security contexts for the chosen mechanism that the application
-         is authorized to act on behalf of, then that principal shall be
-         used, otherwise
-
-      2) If the platform maintains a concept of a default network-
-         identity for the chosen mechanism, and if the application is
-         authorized to act on behalf of that identity for the purpose of
-         initiating security contexts, then the principal corresponding
-         to that identity shall be used, otherwise
-
-      3) If the platform maintains a concept of a default local
-         identity, and provides a means to map local identities into
-         network-identities for the chosen mechanism, and if the
-         application is authorized to act on behalf of the network-
-         identity image of the default local identity for the purpose of
-
-
-
-
-
-Wray                        Standards Track                     [Page 9]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-         initiating security contexts using the chosen mechanism, then
-         the principal corresponding to that identity shall be used,
-         otherwise
-
-      4) A user-configurable default identity should be used.
-
-   gss_accept_sec_context
-
-      1) If there is only a single authorized principal identity capable
-         of accepting security contexts for the chosen mechanism, then
-         that principal shall be used, otherwise
-
-      2) If the mechanism can determine the identity of the target
-         principal by examining the context-establishment token, and if
-         the accepting application is authorized to act as that
-         principal for the purpose of accepting security contexts using
-         the chosen mechanism, then that principal identity shall be
-         used, otherwise
-
-      3) If the mechanism supports context acceptance by any principal,
-         and if mutual authentication was not requested, any principal
-         that the application is authorized to accept security contexts
-         under using the chosen mechanism may be used, otherwise
-
-      4)A user-configurable default identity shall be used.
-
-   The purpose of the above rules is to allow security contexts to be
-   established by both initiator and acceptor using the default behavior
-   wherever possible.  Applications requesting default behavior are
-   likely to be more portable across mechanisms and platforms than ones
-   that use gss_acquire_cred to request a specific identity.
-
-3.6. Contexts
-
-   The gss_ctx_id_t data type contains a caller-opaque atomic value that
-   identifies one end of a GSS-API security context.  It should be
-   implemented as a pointer or arithmetic type.  If a pointer type is
-   chosen, care should be taken to ensure that two gss_ctx_id_t values
-   may be compared with the == operator.
-
-   The security context holds state information about each end of a peer
-   communication, including cryptographic state information.
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 10]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-3.7. Authentication tokens
-
-   A token is a caller-opaque type that GSS-API uses to maintain
-   synchronization between the context data structures at each end of a
-   GSS-API security context.  The token is a cryptographically protected
-   octet-string, generated by the underlying mechanism at one end of a
-   GSS-API security context for use by the peer mechanism at the other
-   end.  Encapsulation (if required) and transfer of the token are the
-   responsibility of the peer applications.  A token is passed between
-   the GSS-API and the application using the gss_buffer_t conventions.
-
-3.8. Interprocess tokens
-
-   Certain GSS-API routines are intended to transfer data between
-   processes in multi-process programs.  These routines use a caller-
-   opaque octet-string, generated by the GSS-API in one process for use
-   by the GSS-API in another process.  The calling application is
-   responsible for transferring such tokens between processes in an OS-
-   specific manner.  Note that, while GSS-API implementors are
-   encouraged to avoid placing sensitive information within interprocess
-   tokens, or to cryptographically protect them, many implementations
-   will be unable to avoid placing key material or other sensitive data
-   within them.  It is the application's responsibility to ensure that
-   interprocess tokens are protected in transit, and transferred only to
-   processes that are trustworthy. An interprocess token is passed
-   between the GSS-API and the application using the gss_buffer_t
-   conventions.
-
-3.9. Status values
-
-   Every GSS-API routine returns two distinct values to report status
-   information to the caller: GSS status codes and Mechanism status
-   codes.
-
-3.9.1. GSS status codes
-
-   GSS-API routines return GSS status codes as their OM_uint32 function
-   value.  These codes indicate errors that are independent of the
-   underlying mechanism(s) used to provide the security service.  The
-   errors that can be indicated via a GSS status code are either generic
-   API routine errors (errors that are defined in the GSS-API
-   specification) or calling errors (errors that are specific to these
-   language bindings).
-
-   A GSS status code can indicate a single fatal generic API error from
-   the routine and a single calling error.  In addition, supplementary
-   status information may be indicated via the setting of bits in the
-   supplementary info field of a GSS status code.
-
-
-
-Wray                        Standards Track                    [Page 11]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   These errors are encoded into the 32-bit GSS status code as follows:
-
-      MSB                                                        LSB
-      |------------------------------------------------------------|
-      |  Calling Error | Routine Error  |    Supplementary Info    |
-      |------------------------------------------------------------|
-   Bit 31            24 23            16 15                       0
-
-   Hence if a GSS-API routine returns a GSS status code whose upper 16
-   bits contain a non-zero value, the call failed.  If the calling error
-   field is non-zero, the invoking application's call of the routine was
-   erroneous.  Calling errors are defined in table 5-1.  If the routine
-   error field is non-zero, the routine failed for one of the routine-
-   specific reasons listed below in table 5-2.  Whether or not the upper
-   16 bits indicate a failure or a success, the routine may indicate
-   additional information by setting bits in the supplementary info
-   field of the status code. The meaning of individual bits is listed
-   below in table 5-3.
-
-   Table 3-1  Calling Errors
-
-   Name                   Value in field           Meaning
-   ----                   --------------           -------
-   GSS_S_CALL_INACCESSIBLE_READ  1       A required input parameter
-                                         could not be read
-   GSS_S_CALL_INACCESSIBLE_WRITE 2       A required output parameter
-                                          could not be written.
-   GSS_S_CALL_BAD_STRUCTURE      3       A parameter was malformed
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 12]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Table 3-2  Routine Errors
-
-   Name                   Value in field           Meaning
-   ----                   --------------           -------
-   GSS_S_BAD_MECH                1       An unsupported mechanism
-                                         was requested
-   GSS_S_BAD_NAME                2       An invalid name was
-                                         supplied
-   GSS_S_BAD_NAMETYPE            3       A supplied name was of an
-                                         unsupported type
-   GSS_S_BAD_BINDINGS            4       Incorrect channel bindings
-                                         were supplied
-   GSS_S_BAD_STATUS              5       An invalid status code was
-                                         supplied
-   GSS_S_BAD_MIC GSS_S_BAD_SIG   6       A token had an invalid MIC
-   GSS_S_NO_CRED                 7       No credentials were
-                                         supplied, or the
-                                         credentials were
-                                         unavailable or
-                                         inaccessible.
-   GSS_S_NO_CONTEXT              8       No context has been
-                                         established
-   GSS_S_DEFECTIVE_TOKEN         9       A token was invalid
-   GSS_S_DEFECTIVE_CREDENTIAL   10       A credential was invalid
-   GSS_S_CREDENTIALS_EXPIRED    11       The referenced credentials
-                                         have expired
-   GSS_S_CONTEXT_EXPIRED        12       The context has expired
-   GSS_S_FAILURE                13       Miscellaneous failure (see
-                                         text)
-   GSS_S_BAD_QOP                14       The quality-of-protection
-                                         requested could not be
-                                         provided
-   GSS_S_UNAUTHORIZED           15       The operation is forbidden
-                                         by local security policy
-   GSS_S_UNAVAILABLE            16       The operation or option is
-                                         unavailable
-   GSS_S_DUPLICATE_ELEMENT      17       The requested credential
-                                         element already exists
-   GSS_S_NAME_NOT_MN            18       The provided name was not a
-                                         mechanism name
-
-
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 13]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Table 3-3  Supplementary Status Bits
-
-   Name                   Bit Number           Meaning
-   ----                   ----------           -------
-   GSS_S_CONTINUE_NEEDED   0 (LSB)   Returned only by
-                                     gss_init_sec_context or
-                                     gss_accept_sec_context. The
-                                     routine must be called again
-                                     to complete its function.
-                                     See routine documentation for
-                                     detailed description
-   GSS_S_DUPLICATE_TOKEN   1         The token was a duplicate of
-                                     an earlier token
-   GSS_S_OLD_TOKEN         2         The token's validity period
-                                     has expired
-   GSS_S_UNSEQ_TOKEN       3         A later token has already been
-                                     processed
-   GSS_S_GAP_TOKEN         4         An expected per-message token
-                                     was not received
-
-   The routine documentation also uses the name GSS_S_COMPLETE, which is
-   a zero value, to indicate an absence of any API errors or
-   supplementary information bits.
-
-   All GSS_S_xxx symbols equate to complete OM_uint32 status codes,
-   rather than to bitfield values.  For example, the actual value of the
-   symbol GSS_S_BAD_NAMETYPE (value 3 in the routine error field) is
-   3<<16.  The macros GSS_CALLING_ERROR(), GSS_ROUTINE_ERROR() and
-   GSS_SUPPLEMENTARY_INFO() are provided, each of which takes a GSS
-   status code and removes all but the relevant field.  For example, the
-   value obtained by applying GSS_ROUTINE_ERROR to a status code removes
-   the calling errors and supplementary info fields, leaving only the
-   routine errors field.  The values delivered by these macros may be
-   directly compared with a GSS_S_xxx symbol of the appropriate type.
-   The macro GSS_ERROR() is also provided, which when applied to a GSS
-   status code returns a non-zero value if the status code indicated a
-   calling or routine error, and a zero value otherwise.  All macros
-   defined by GSS-API evaluate their argument(s) exactly once.
-
-   A GSS-API implementation may choose to signal calling errors in a
-   platform-specific manner instead of, or in addition to the routine
-   value;  routine errors and supplementary info should be returned via
-   major status values only.
-
-   The GSS major status code GSS_S_FAILURE is used to indicate that the
-   underlying mechanism detected an error for which no specific GSS
-   status code is defined.  The mechanism-specific status code will
-   provide more details about the error.
-
-
-
-Wray                        Standards Track                    [Page 14]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-3.9.2. Mechanism-specific status codes
-
-   GSS-API routines return a minor_status parameter, which is used to
-   indicate specialized errors from the underlying security mechanism.
-   This parameter may contain a single mechanism-specific error,
-   indicated by a OM_uint32 value.
-
-   The minor_status parameter will always be set by a GSS-API routine,
-   even if it returns a calling error or one of the generic API errors
-   indicated above as fatal, although most other output parameters may
-   remain unset in such cases.  However, output parameters that are
-   expected to return pointers to storage allocated by a routine must
-   always be set by the routine, even in the event of an error, although
-   in such cases the GSS-API routine may elect to set the returned
-   parameter value to NULL to indicate that no storage was actually
-   allocated.  Any length field associated with such pointers (as in a
-   gss_buffer_desc structure) should also be set to zero in such cases.
-
-3.10. Names
-
-   A name is used to identify a person or entity.  GSS-API authenticates
-   the relationship between a name and the entity claiming the name.
-
-   Since different authentication mechanisms may employ different
-   namespaces for identifying their principals, GSSAPI's naming support
-   is necessarily complex in multi-mechanism environments (or even in
-   some single-mechanism environments where the underlying mechanism
-   supports multiple namespaces).
-
-   Two distinct representations are defined for names:
-
-   An internal form.  This is the GSS-API "native" format for names,
-      represented by the implementation-specific gss_name_t type.  It is
-      opaque to GSS-API callers.  A single gss_name_t object may contain
-      multiple names from different namespaces, but all names should
-      refer to the same entity.  An example of such an internal name
-      would be the name returned from a call to the gss_inquire_cred
-      routine, when applied to a credential containing credential
-      elements for multiple authentication mechanisms employing
-      different namespaces.  This gss_name_t object will contain a
-      distinct name for the entity for each authentication mechanism.
-
-      For GSS-API implementations supporting multiple namespaces,
-      objects of type gss_name_t must contain sufficient information to
-      determine the namespace to which each primitive name belongs.
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 15]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Mechanism-specific contiguous octet-string forms.  A format
-      capable of containing a single name (from a single namespace).
-      Contiguous string names are always accompanied by an object
-      identifier specifying the namespace to which the name belongs, and
-      their format is dependent on the authentication mechanism that
-      employs the name.  Many, but not all, contiguous string names will
-      be printable, and may therefore be used by GSS-API applications
-      for communication with their users.
-
-   Routines (gss_import_name and gss_display_name) are provided to
-   convert names between contiguous string representations and the
-   internal gss_name_t type.  gss_import_name may support multiple
-   syntaxes for each supported namespace, allowing users the freedom to
-   choose a preferred name representation. gss_display_name should use
-   an implementation-chosen printable syntax for each supported name-
-   type.
-
-   If an application calls gss_display_name(), passing the internal name
-   resulting from a call to gss_import_name(), there is no guarantee the
-   the resulting contiguous string name will be the same as the original
-   imported string name.  Nor do name-space identifiers necessarily
-   survive unchanged after a journey through the internal name-form.  An
-   example of this might be a mechanism that authenticates X.500 names,
-   but provides an algorithmic mapping of Internet DNS names into X.500.
-   That mechanism's implementation of gss_import_name() might, when
-   presented with a DNS name, generate an internal name that contained
-   both the original DNS name and the equivalent X.500 name.
-   Alternatively, it might only store the X.500 name.  In the latter
-   case, gss_display_name() would most likely generate a printable X.500
-   name, rather than the original DNS name.
-
-   The process of authentication delivers to the context acceptor an
-   internal name.  Since this name has been authenticated by a single
-   mechanism, it contains only a single name (even if the internal name
-   presented by the context initiator to gss_init_sec_context had
-   multiple components).  Such names are termed internal mechanism
-   names, or "MN"s and the names emitted by gss_accept_sec_context() are
-   always of this type.  Since some applications may require MNs without
-   wanting to incur the overhead of an authentication operation, a
-   second function, gss_canonicalize_name(), is provided to convert a
-   general internal name into an MN.
-
-   Comparison of internal-form names may be accomplished via the
-   gss_compare_name() routine, which returns true if the two names being
-   compared refer to the same entity.  This removes the need for the
-   application program to understand the syntaxes of the various
-   printable names that a given GSS-API implementation may support.
-   Since GSS-API assumes that all primitive names contained within a
-
-
-
-Wray                        Standards Track                    [Page 16]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   given internal name refer to the same entity, gss_compare_name() can
-   return true if the two names have at least one primitive name in
-   common.  If the implementation embodies knowledge of equivalence
-   relationships between names taken from different namespaces, this
-   knowledge may also allow successful comparison of internal names
-   containing no overlapping primitive elements.
-
-   When used in large access control lists, the overhead of invoking
-   gss_import_name() and gss_compare_name() on each name from the ACL
-   may be prohibitive.  As an alternative way of supporting this case,
-   GSS-API defines a special form of the contiguous string name which
-   may be compared directly (e.g. with memcmp()).  Contiguous names
-   suitable for comparison are generated by the gss_export_name()
-   routine, which requires an MN as input.  Exported names may be re-
-   imported by the gss_import_name() routine, and the resulting internal
-   name will also be an MN.  The gss_OID constant GSS_C_NT_EXPORT_NAME
-   indentifies the "export name" type, and the value of this constant is
-   given in Appendix A.  Structurally, an exported name object consists
-   of a header containing an OID identifying the mechanism that
-   authenticated the name, and a trailer containing the name itself,
-   where the syntax of the trailer is defined by the individual
-   mechanism specification.   The precise format of an export name is
-   defined in the language-independent GSS-API specification [GSSAPI].
-
-   Note that the results obtained by using gss_compare_name() will in
-   general be different from those obtained by invoking
-   gss_canonicalize_name() and gss_export_name(), and then comparing the
-   exported names.  The first series of operation determines whether two
-   (unauthenticated) names identify the same principal; the second
-   whether a particular mechanism would authenticate them as the same
-   principal.  These two operations will in general give the same
-   results only for MNs.
-
-   The gss_name_t datatype should be implemented as a pointer type. To
-   allow the compiler to aid the application programmer by performing
-   type-checking, the use of (void *) is discouraged.  A pointer to an
-   implementation-defined type is the preferred choice.
-
-   Storage is allocated by routines that return gss_name_t values. A
-   procedure, gss_release_name, is provided to free storage associated
-   with an internal-form name.
-
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 17]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-3.11. Channel Bindings
-
-   GSS-API supports the use of user-specified tags to identify a given
-   context to the peer application.  These tags are intended to be used
-   to identify the particular communications channel that carries the
-   context.  Channel bindings are communicated to the GSS-API using the
-   following structure:
-
-   typedef struct gss_channel_bindings_struct {
-      OM_uint32       initiator_addrtype;
-      gss_buffer_desc initiator_address;
-      OM_uint32       acceptor_addrtype;
-      gss_buffer_desc acceptor_address;
-      gss_buffer_desc application_data;
-   } *gss_channel_bindings_t;
-
-   The initiator_addrtype and acceptor_addrtype fields denote the type
-   of addresses contained in the initiator_address and acceptor_address
-   buffers.  The address type should be one of the following:
-
-   GSS_C_AF_UNSPEC     Unspecified address type
-   GSS_C_AF_LOCAL      Host-local address type
-   GSS_C_AF_INET       Internet address type (e.g. IP)
-   GSS_C_AF_IMPLINK    ARPAnet IMP address type
-   GSS_C_AF_PUP        pup protocols (eg BSP) address type
-   GSS_C_AF_CHAOS      MIT CHAOS protocol address type
-   GSS_C_AF_NS         XEROX NS address type
-   GSS_C_AF_NBS        nbs address type
-   GSS_C_AF_ECMA       ECMA address type
-   GSS_C_AF_DATAKIT    datakit protocols address type
-   GSS_C_AF_CCITT      CCITT protocols
-   GSS_C_AF_SNA        IBM SNA address type
-   GSS_C_AF_DECnet     DECnet address type
-   GSS_C_AF_DLI        Direct data link interface address type
-   GSS_C_AF_LAT        LAT address type
-   GSS_C_AF_HYLINK     NSC Hyperchannel address type
-   GSS_C_AF_APPLETALK  AppleTalk address type
-   GSS_C_AF_BSC        BISYNC 2780/3780 address type
-   GSS_C_AF_DSS        Distributed system services address type
-   GSS_C_AF_OSI        OSI TP4 address type
-   GSS_C_AF_X25        X.25
-   GSS_C_AF_NULLADDR   No address specified
-
-   Note that these symbols name address families rather than specific
-   addressing formats.  For address families that contain several
-   alternative address forms, the initiator_address and acceptor_address
-   fields must contain sufficient information to determine which address
-
-
-
-
-Wray                        Standards Track                    [Page 18]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   form is used.  When not otherwise specified, addresses should be
-   specified in network byte-order (that is, native byte-ordering for
-   the address family).
-
-   Conceptually, the GSS-API concatenates the initiator_addrtype,
-   initiator_address, acceptor_addrtype, acceptor_address and
-   application_data to form an octet string.  The mechanism calculates a
-   MIC over this octet string, and binds the MIC to the context
-   establishment token emitted by gss_init_sec_context. The same
-   bindings are presented by the context acceptor to
-   gss_accept_sec_context, and a MIC is calculated in the same way. The
-   calculated MIC is compared with that found in the token, and if the
-   MICs differ, gss_accept_sec_context will return a GSS_S_BAD_BINDINGS
-   error, and the context will not be established.  Some mechanisms may
-   include the actual channel binding data in the token (rather than
-   just a MIC); applications should therefore not use confidential data
-   as channel-binding components.
-
-   Individual mechanisms may impose additional constraints on addresses
-   and address types that may appear in channel bindings.  For example,
-   a mechanism may verify that the initiator_address field of the
-   channel bindings presented to gss_init_sec_context contains the
-   correct network address of the host system.  Portable applications
-   should therefore ensure that they either provide correct information
-   for the address fields, or omit addressing information, specifying
-   GSS_C_AF_NULLADDR as the address-types.
-
-3.12. Optional parameters
-
-   Various parameters are described as optional.  This means that they
-   follow a convention whereby a default value may be requested.  The
-   following conventions are used for omitted parameters.  These
-   conventions apply only to those parameters that are explicitly
-   documented as optional.
-
-3.12.1. gss_buffer_t types
-
-   Specify GSS_C_NO_BUFFER as a value.  For an input parameter this
-   signifies that default behavior is requested, while for an output
-   parameter it indicates that the information that would be returned
-   via the parameter is not required by the application.
-
-3.12.2. Integer types (input)
-
-   Individual parameter documentation lists values to be used to
-   indicate default actions.
-
-
-
-
-
-Wray                        Standards Track                    [Page 19]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-3.12.3. Integer types (output)
-
-   Specify NULL as the value for the pointer.
-
-3.12.4. Pointer types
-
-   Specify NULL as the value.
-
-3.12.5. Object IDs
-
-   Specify GSS_C_NO_OID as the value.
-
-3.12.6. Object ID Sets
-
-   Specify GSS_C_NO_OID_SET as the value.
-
-3.12.7. Channel Bindings
-
-   Specify GSS_C_NO_CHANNEL_BINDINGS to indicate that channel bindings
-   are not to be used.
-
-4.   Additional Controls
-
-   This section discusses the optional services that a context initiator
-   may request of the GSS-API at context establishment. Each of these
-   services is requested by setting a flag in the req_flags input
-   parameter to gss_init_sec_context.
-
-   The optional services currently defined are:
-
-   Delegation - The (usually temporary) transfer of rights from
-       initiator to acceptor, enabling the acceptor to authenticate
-       itself as an agent of the initiator.
-
-   Mutual Authentication - In addition to the initiator authenticating
-       its identity to the context acceptor, the context acceptor should
-       also authenticate itself to the initiator.
-
-   Replay detection - In addition to providing message integrity
-       services, gss_get_mic and gss_wrap should include message
-       numbering information to enable gss_verify_mic and gss_unwrap to
-       detect if a message has been duplicated.
-
-   Out-of-sequence detection - In addition to providing message
-       integrity services, gss_get_mic and gss_wrap should include
-       message sequencing information to enable gss_verify_mic and
-       gss_unwrap to detect if a message has been received out of
-       sequence.
-
-
-
-Wray                        Standards Track                    [Page 20]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Anonymous authentication - The establishment of the security context
-       should not reveal the initiator's identity to the context
-       acceptor.
-
-   Any currently undefined bits within such flag arguments should be
-   ignored by GSS-API implementations when presented by an application,
-   and should be set to zero when returned to the application by the
-   GSS-API implementation.
-
-   Some mechanisms may not support all optional services, and some
-   mechanisms may only support some services in conjunction with others.
-   Both gss_init_sec_context and gss_accept_sec_context inform the
-   applications which services will be available from the context when
-   the establishment phase is complete, via the ret_flags output
-   parameter.  In general, if the security mechanism is capable of
-   providing a requested service, it should do so, even if additional
-   services must be enabled in order to provide the requested service.
-   If the mechanism is incapable of providing a requested service, it
-   should proceed without the service, leaving the application to abort
-   the context establishment process if it considers the requested
-   service to be mandatory.
-
-   Some mechanisms may specify that support for some services is
-   optional, and that implementors of the mechanism need not provide it.
-   This is most commonly true of the confidentiality service, often
-   because of legal restrictions on the use of data-encryption, but may
-   apply to any of the services.  Such mechanisms are required to send
-   at least one token from acceptor to initiator during context
-   establishment when the initiator indicates a desire to use such a
-   service, so that the initiating GSS-API can correctly indicate
-   whether the service is supported by the acceptor's GSS-API.
-
-4.1. Delegation
-
-   The GSS-API allows delegation to be controlled by the initiating
-   application via a boolean parameter to gss_init_sec_context(), the
-   routine that establishes a security context.  Some mechanisms do not
-   support delegation, and for such mechanisms attempts by an
-   application to enable delegation are ignored.
-
-   The acceptor of a security context for which the initiator enabled
-   delegation will receive (via the delegated_cred_handle parameter of
-   gss_accept_sec_context) a credential handle that contains the
-   delegated identity, and this credential handle may be used to
-   initiate subsequent GSS-API security contexts as an agent or delegate
-   of the initiator.  If the original initiator's identity is "A" and
-   the delegate's identity is "B", then, depending on the underlying
-   mechanism, the identity embodied by the delegated credential may be
-
-
-
-Wray                        Standards Track                    [Page 21]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   either "A" or "B acting for A".
-
-   For many mechanisms that support delegation, a simple boolean does
-   not provide enough control.  Examples of additional aspects of
-   delegation control that a mechanism might provide to an application
-   are duration of delegation, network addresses from which delegation
-   is valid, and constraints on the tasks that may be performed by a
-   delegate.  Such controls are presently outside the scope of the GSS-
-   API.  GSS-API implementations supporting mechanisms offering
-   additional controls should provide extension routines that allow
-   these controls to be exercised (perhaps by modifying the initiator's
-   GSS-API credential prior to its use in establishing a context).
-   However, the simple delegation control provided by GSS-API should
-   always be able to over-ride other mechanism-specific delegation
-   controls - If the application instructs gss_init_sec_context() that
-   delegation is not desired, then the implementation must not permit
-   delegation to occur. This is an exception to the general rule that a
-   mechanism may enable services even if they are not requested -
-   delegation may only be provided at the explicit request of the
-   application.
-
-4.2. Mutual authentication
-
-   Usually, a context acceptor will require that a context initiator
-   authenticate itself so that the acceptor may make an access-control
-   decision prior to performing a service for the initiator.  In some
-   cases, the initiator may also request that the acceptor authenticate
-   itself.  GSS-API allows the initiating application to request this
-   mutual authentication service by setting a flag when calling
-   gss_init_sec_context.
-
-   The initiating application is informed as to whether or not the
-   context acceptor has authenticated itself.  Note that some mechanisms
-   may not support mutual authentication, and other mechanisms may
-   always perform mutual authentication, whether or not the initiating
-   application requests it.  In particular, mutual authentication my be
-   required by some mechanisms in order to support replay or out-of-
-   sequence message detection, and for such mechanisms a request for
-   either of these services will automatically enable mutual
-   authentication.
-
-
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 22]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-4.3. Replay and out-of-sequence detection
-
-   The GSS-API may provide detection of mis-ordered message once a
-   security context has been established.  Protection may be applied to
-   messages by either application, by calling either gss_get_mic or
-   gss_wrap, and verified by the peer application by calling
-   gss_verify_mic or gss_unwrap.
-
-   gss_get_mic calculates a cryptographic MIC over an application
-   message, and returns that MIC in a token.  The application should
-   pass both the token and the message to the peer application, which
-   presents them to gss_verify_mic.
-
-   gss_wrap calculates a cryptographic MIC of an application message,
-   and places both the MIC and the message inside a single token.  The
-   Application should pass the token to the peer application, which
-   presents it to gss_unwrap to extract the message and verify the MIC.
-
-   Either pair of routines may be capable of detecting out-of-sequence
-   message delivery, or duplication of messages. Details of such mis-
-   ordered messages are indicated through supplementary status bits in
-   the major status code returned by gss_verify_mic or gss_unwrap.  The
-   relevant supplementary bits are:
-
-   GSS_S_DUPLICATE_TOKEN - The token is a duplicate of one that has
-                    already been received and processed.  Only
-                    contexts that claim to provide replay detection
-                    may set this bit.
-   GSS_S_OLD_TOKEN - The token is too old to determine whether or
-                    not it is a duplicate.  Contexts supporting
-                    out-of-sequence detection but not replay
-                    detection should always set this bit if
-                    GSS_S_UNSEQ_TOKEN is set; contexts that support
-                    replay detection should only set this bit if the
-                    token is so old that it cannot be checked for
-                    duplication.
-   GSS_S_UNSEQ_TOKEN - A later token has already been processed.
-   GSS_S_GAP_TOKEN - An earlier token has not yet been received.
-
-   A mechanism need not maintain a list of all tokens that have been
-   processed in order to support these status codes.  A typical
-   mechanism might retain information about only the most recent "N"
-   tokens processed, allowing it to distinguish duplicates and missing
-   tokens within the most recent "N" messages; the receipt of a token
-   older than the most recent "N" would result in a GSS_S_OLD_TOKEN
-   status.
-
-
-
-
-
-Wray                        Standards Track                    [Page 23]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-4.4. Anonymous Authentication
-
-   In certain situations, an application may wish to initiate the
-   authentication process to authenticate a peer, without revealing its
-   own identity.  As an example, consider an application providing
-   access to a database containing medical information, and offering
-   unrestricted access to the service.  A client of such a service might
-   wish to authenticate the service (in order to establish trust in any
-   information retrieved from it), but might not wish the service to be
-   able to obtain the client's identity (perhaps due to privacy concerns
-   about the specific inquiries, or perhaps simply to avoid being placed
-   on mailing-lists).
-
-   In normal use of the GSS-API, the initiator's identity is made
-   available to the acceptor as a result of the context establishment
-   process.  However, context initiators may request that their identity
-   not be revealed to the context acceptor. Many mechanisms do not
-   support anonymous authentication, and for such mechanisms the request
-   will not be honored.  An authentication token will be still be
-   generated, but the application is always informed if a requested
-   service is unavailable, and has the option to abort context
-   establishment if anonymity is valued above the other security
-   services that would require a context to be established.
-
-   In addition to informing the application that a context is
-   established anonymously (via the ret_flags outputs from
-   gss_init_sec_context and gss_accept_sec_context), the optional
-   src_name output from gss_accept_sec_context and gss_inquire_context
-   will, for such contexts, return a reserved internal-form name,
-   defined by the implementation.
-
-   When presented to gss_display_name, this reserved internal-form name
-   will result in a printable name that is syntactically distinguishable
-   from any valid principal name supported by the implementation,
-   associated with a name-type object identifier with the value
-   GSS_C_NT_ANONYMOUS, whose value us given in Appendix A.  The
-   printable form of an anonymous name should be chosen such that it
-   implies anonymity, since this name may appear in, for example, audit
-   logs.  For example, the string "<anonymous>" might be a good choice,
-   if no valid printable names supported by the implementation can begin
-   with "<" and end with ">".
-
-4.5. Confidentiality
-
-   If a context supports the confidentiality service, gss_wrap may be
-   used to encrypt application messages.  Messages are selectively
-   encrypted, under the control of the conf_req_flag input parameter to
-   gss_wrap.
-
-
-
-Wray                        Standards Track                    [Page 24]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-4.6. Inter-process context transfer
-
-   GSS-API V2 provides routines (gss_export_sec_context and
-   gss_import_sec_context) which allow a security context to be
-   transferred between processes on a single machine.  The most common
-   use for such a feature is a client-server design where the server is
-   implemented as a single process that accepts incoming security
-   contexts, which then launches child processes to deal with the data
-   on these contexts.  In such a design, the child processes must have
-   access to the security context data structure created within the
-   parent by its call to gss_accept_sec_context so that they can use
-   per-message protection services and delete the security context when
-   the communication session ends.
-
-   Since the security context data structure is expected to contain
-   sequencing information, it is impractical in general to share a
-   context between processes.  Thus GSS-API provides a call
-   (gss_export_sec_context) that the process which currently owns the
-   context can call to declare that it has no intention to use the
-   context subsequently, and to create an inter-process token containing
-   information needed by the adopting process to successfully import the
-   context.  After successful completion of gss_export_sec_context, the
-   original security context is made inaccessible to the calling process
-   by GSS-API, and any context handles referring to this context are no
-   longer valid.  The originating process transfers the inter-process
-   token to the adopting process, which passes it to
-   gss_import_sec_context, and a fresh gss_ctx_id_t is created such that
-   it is functionally identical to the original context.
-
-   The inter-process token may contain sensitive data from the original
-   security context (including cryptographic keys). Applications using
-   inter-process tokens to transfer security contexts must take
-   appropriate steps to protect these tokens in transit.
-
-   Implementations are not required to support the inter-process
-   transfer of security contexts.  The ability to transfer a security
-   context is indicated when the context is created, by
-   gss_init_sec_context or gss_accept_sec_context setting the
-   GSS_C_TRANS_FLAG bit in their ret_flags parameter.
-
-4.7. The use of incomplete contexts
-
-   Some mechanisms may allow the per-message services to be used before
-   the context establishment process is complete.  For example, a
-   mechanism may include sufficient information in its initial context-
-   level token for the context acceptor to immediately decode messages
-   protected with gss_wrap or gss_get_mic.  For such a mechanism, the
-   initiating application need not wait until subsequent context-level
-
-
-
-Wray                        Standards Track                    [Page 25]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   tokens have been sent and received before invoking the per-message
-   protection services.
-
-   The ability of a context to provide per-message services in advance
-   of complete context establishment is indicated by the setting of the
-   GSS_C_PROT_READY_FLAG bit in the ret_flags parameter from
-   gss_init_sec_context and gss_accept_sec_context. Applications wishing
-   to use per-message protection services on partially-established
-   contexts should check this flag before attempting to invoke gss_wrap
-   or gss_get_mic.
-
-5. GSS-API Routine Descriptions
-
-   In addition to the explicit major status codes documented here, the
-   code GSS_S_FAILURE may be returned by any routine, indicating an
-   implementation-specific or mechanism-specific error condition,
-   further details of which are reported via the minor_status parameter.
-
-5.1. gss_accept_sec_context
-
-   OM_uint32 gss_accept_sec_context (
-     OM_uint32           *minor_status,
-     gss_ctx_id_t        *context_handle,
-     const gss_cred_id_t acceptor_cred_handle,
-     const gss_buffer_t  input_token_buffer,
-     const gss_channel_bindings_t  input_chan_bindings,
-     const gss_name_t    *src_name,
-     gss_OID             *mech_type,
-     gss_buffer_t        output_token,
-     OM_uint32           *ret_flags,
-     OM_uint32           *time_rec,
-     gss_cred_id_t       *delegated_cred_handle)
-
-   Purpose:
-
-   Allows a remotely initiated security context between the application
-   and a remote peer to be established.  The routine may return a
-   output_token which should be transferred to the peer application,
-   where the peer application will present it to gss_init_sec_context.
-   If no token need be sent, gss_accept_sec_context will indicate this
-   by setting the length field of the output_token argument to zero.  To
-   complete the context establishment, one or more reply tokens may be
-   required from the peer application; if so, gss_accept_sec_context
-   will return a status flag of GSS_S_CONTINUE_NEEDED, in which case it
-   should be called again when the reply token is received from the peer
-   application, passing the token to gss_accept_sec_context via the
-   input_token parameters.
-
-
-
-
-Wray                        Standards Track                    [Page 26]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Portable applications should be constructed to use the token length
-   and return status to determine whether a token needs to be sent or
-   waited for.  Thus a typical portable caller should always invoke
-   gss_accept_sec_context within a loop:
-
-   gss_ctx_id_t context_hdl = GSS_C_NO_CONTEXT;
-
-   do {
-     receive_token_from_peer(input_token);
-     maj_stat = gss_accept_sec_context(&min_stat,
-                                       &context_hdl,
-                                       cred_hdl,
-                                       input_token,
-                                       input_bindings,
-                                       &client_name,
-                                       &mech_type,
-                                       output_token,
-                                       &ret_flags,
-                                       &time_rec,
-                                       &deleg_cred);
-     if (GSS_ERROR(maj_stat)) {
-       report_error(maj_stat, min_stat);
-     };
-     if (output_token->length != 0) {
-       send_token_to_peer(output_token);
-
-       gss_release_buffer(&min_stat, output_token);
-     };
-     if (GSS_ERROR(maj_stat)) {
-       if (context_hdl != GSS_C_NO_CONTEXT)
-         gss_delete_sec_context(&min_stat,
-                                &context_hdl,
-                                GSS_C_NO_BUFFER);
-       break;
-     };
-   } while (maj_stat & GSS_S_CONTINUE_NEEDED);
-
-   Whenever the routine returns a major status that includes the value
-   GSS_S_CONTINUE_NEEDED, the context is not fully established and the
-   following restrictions apply to the output parameters:
-
-   The value returned via the time_rec parameter is undefined Unless the
-   accompanying ret_flags parameter contains the bit
-   GSS_C_PROT_READY_FLAG, indicating that per-message services may be
-   applied in advance of a successful completion status, the value
-   returned via the mech_type parameter may be undefined until the
-   routine returns a major status value of GSS_S_COMPLETE.
-
-
-
-
-Wray                        Standards Track                    [Page 27]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   The values of the GSS_C_DELEG_FLAG,
-   GSS_C_MUTUAL_FLAG,GSS_C_REPLAY_FLAG, GSS_C_SEQUENCE_FLAG,
-   GSS_C_CONF_FLAG,GSS_C_INTEG_FLAG and GSS_C_ANON_FLAG bits returned
-   via the ret_flags parameter should contain the values that the
-   implementation expects would be valid if context establishment were
-   to succeed.
-
-   The values of the GSS_C_PROT_READY_FLAG and GSS_C_TRANS_FLAG bits
-   within ret_flags should indicate the actual state at the time
-   gss_accept_sec_context returns, whether or not the context is fully
-   established.
-
-   Although this requires that GSS-API implementations set the
-   GSS_C_PROT_READY_FLAG in the final ret_flags returned to a caller
-   (i.e. when accompanied by a GSS_S_COMPLETE status code), applications
-   should not rely on this behavior as the flag was not defined in
-   Version 1 of the GSS-API. Instead, applications should be prepared to
-   use per-message services after a successful context establishment,
-   according to the GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG values.
-
-   All other bits within the ret_flags argument should be set to zero.
-   While the routine returns GSS_S_CONTINUE_NEEDED, the values returned
-   via the ret_flags argument indicate the services that the
-   implementation expects to be available from the established context.
-
-   If the initial call of gss_accept_sec_context() fails, the
-   implementation should not create a context object, and should leave
-   the value of the context_handle parameter set to GSS_C_NO_CONTEXT to
-   indicate this.  In the event of a failure on a subsequent call, the
-   implementation is permitted to delete the "half-built" security
-   context (in which case it should set the context_handle parameter to
-   GSS_C_NO_CONTEXT), but the preferred behavior is to leave the
-   security context (and the context_handle parameter) untouched for the
-   application to delete (using gss_delete_sec_context).
-
-   During context establishment, the informational status bits
-   GSS_S_OLD_TOKEN and GSS_S_DUPLICATE_TOKEN indicate fatal errors, and
-   GSS-API mechanisms should always return them in association with a
-   routine error of GSS_S_FAILURE.  This requirement for pairing did not
-   exist in version 1 of the GSS-API specification, so applications that
-   wish to run over version 1 implementations must special-case these
-   codes.
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 28]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Parameters:
-
-   context_handle    gss_ctx_id_t, read/modify context handle for new
-                        context.  Supply GSS_C_NO_CONTEXT for first
-                        call; use value returned in subsequent calls.
-                        Once gss_accept_sec_context() has returned a
-                        value via this parameter, resources have been
-                        assigned to the corresponding context, and must
-                        be freed by the application after use with a
-                        call to gss_delete_sec_context().
-
-
-   acceptor_cred_handle  gss_cred_id_t, read Credential handle claimed
-                         by context acceptor. Specify
-                         GSS_C_NO_CREDENTIAL to accept the context as a
-                         default principal.  If GSS_C_NO_CREDENTIAL is
-                         specified, but no default acceptor principal is
-                         defined, GSS_S_NO_CRED will be returned.
-
-   input_token_buffer   buffer, opaque, read token obtained from remote
-                        application.
-
-   input_chan_bindings  channel bindings, read, optional Application-
-                        specified bindings.  Allows application to
-                        securely bind channel identification information
-                        to the security context.  If channel bindings
-                        are not used, specify GSS_C_NO_CHANNEL_BINDINGS.
-
-   src_name             gss_name_t, modify, optional Authenticated name
-                        of context initiator.  After use, this name
-                        should be deallocated by passing it to
-                        gss_release_name().  If not required, specify
-                        NULL.
-
-   mech_type            Object ID, modify, optional Security mechanism
-                        used.  The returned OID value will be a pointer
-                        into static storage, and should be treated as
-                        read-only by the caller (in particular, it does
-                        not need to be freed).  If not required, specify
-                        NULL.
-
-   output_token         buffer, opaque, modify Token to be passed to
-                        peer application.  If the length field of the
-                        returned token buffer is 0, then no token need
-                        be passed to the peer application.  If a non-
-                        zero length field is returned, the associated
-                        storage must be freed after use by the
-                        application with a call to gss_release_buffer().
-
-
-
-Wray                        Standards Track                    [Page 29]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   ret_flags            bit-mask, modify, optional Contains various
-                        independent flags, each of which indicates that
-                        the context supports a specific service option.
-                        If not needed, specify NULL.  Symbolic names are
-                        provided for each flag, and the symbolic names
-                        corresponding to the required flags should be
-                        logically-ANDed with the ret_flags value to test
-                        whether a given option is supported by the
-                        context.  The flags are:
-                        GSS_C_DELEG_FLAG
-                        True - Delegated credentials are available
-                               via the delegated_cred_handle
-                               parameter
-                        False - No credentials were delegated
-                        GSS_C_MUTUAL_FLAG
-                        True - Remote peer asked for mutual
-                               authentication
-                        False - Remote peer did not ask for mutual
-                                authentication
-                        GSS_C_REPLAY_FLAG
-                        True - replay of protected messages
-                               will be detected
-                        False - replayed messages will not be
-                                detected
-                        GSS_C_SEQUENCE_FLAG
-                        True - out-of-sequence protected
-                               messages will be detected
-                        False - out-of-sequence messages will not
-                                be detected
-                        GSS_C_CONF_FLAG
-                        True - Confidentiality service may be
-                               invoked by calling the gss_wrap
-                               routine
-                        False - No confidentiality service (via
-                                gss_wrap) available. gss_wrap will
-                                provide message encapsulation,
-                                data-origin authentication and
-                                integrity services only.
-                        GSS_C_INTEG_FLAG
-                        True - Integrity service may be invoked by
-                               calling either gss_get_mic or
-                               gss_wrap routines.
-                        False - Per-message integrity service
-                                unavailable.
-                        GSS_C_ANON_FLAG
-                        True - The initiator does not wish to
-                               be authenticated; the src_name
-                               parameter (if requested) contains
-
-
-
-Wray                        Standards Track                    [Page 30]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-                               an anonymous internal name.
-                        False - The initiator has been
-                                authenticated normally.
-                        GSS_C_PROT_READY_FLAG
-                        True - Protection services (as specified
-                               by the states of the GSS_C_CONF_FLAG
-                               and GSS_C_INTEG_FLAG) are available
-                               if the accompanying major status
-                               return value is either GSS_S_COMPLETE
-                               or GSS_S_CONTINUE_NEEDED.
-                        False - Protection services (as specified
-                                by the states of the GSS_C_CONF_FLAG
-                                and GSS_C_INTEG_FLAG) are available
-                                only if the accompanying major status
-                                return value is GSS_S_COMPLETE.
-                        GSS_C_TRANS_FLAG
-                        True - The resultant security context may
-                               be transferred to other processes via
-                               a call to gss_export_sec_context().
-                        False - The security context is not
-                                transferable.
-                        All other bits should be set to zero.
-
-   time_rec             Integer, modify, optional
-                        number of seconds for which the context will
-                        remain valid. Specify NULL if not required.
-
-   delegated_cred_handle
-                        gss_cred_id_t, modify, optional credential
-                        handle for credentials received from context
-                        initiator.  Only valid if deleg_flag in
-                        ret_flags is true, in which case an explicit
-                        credential handle (i.e. not GSS_C_NO_CREDENTIAL)
-                        will be returned; if deleg_flag is false,
-                        gss_accept_context() will set this parameter to
-                        GSS_C_NO_CREDENTIAL.  If a credential handle is
-                        returned, the associated resources must be
-                        released by the application after use with a
-                        call to gss_release_cred().  Specify NULL if not
-                        required.
-
-   minor_status         Integer, modify
-                        Mechanism specific status code.
-
-   GSS_S_CONTINUE_NEEDED Indicates that a token from the peer
-                         application is required to complete the
-                         context, and that gss_accept_sec_context must
-                         be called again with that token.
-
-
-
-Wray                        Standards Track                    [Page 31]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks performed on
-                         the input_token failed.
-
-   GSS_S_DEFECTIVE_CREDENTIAL Indicates that consistency checks
-                         performed on the credential failed.
-
-   GSS_S_NO_CRED     The supplied credentials were not valid for context
-                         acceptance, or the credential handle did not
-                         reference any credentials.
-
-   GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired.
-
-   GSS_S_BAD_BINDINGS  The input_token contains different channel
-                         bindings to those specified via the
-                         input_chan_bindings parameter.
-
-   GSS_S_NO_CONTEXT  Indicates that the supplied context handle did not
-                         refer to a valid context.
-
-   GSS_S_BAD_SIG     The input_token contains an invalid MIC.
-
-   GSS_S_OLD_TOKEN   The input_token was too old.  This is a fatal error
-                         during context establishment.
-
-   GSS_S_DUPLICATE_TOKEN The input_token is valid, but is a duplicate of
-                         a token already processed.  This is a fatal
-                         error during context establishment.
-
-   GSS_S_BAD_MECH    The received token specified a mechanism that is
-                         not supported by the implementation or the
-                         provided credential.
-
-5.2. gss_acquire_cred
-
-   OM_uint32 gss_acquire_cred (
-     OM_uint32         *minor_status,
-     const gss_name_t  desired_name,
-     OM_uint32         time_req,
-     const gss_OID_set desired_mechs,
-     gss_cred_usage_t  cred_usage,
-     gss_cred_id_t     *output_cred_handle,
-     gss_OID_set       *actual_mechs,
-     OM_uint32         *time_rec)
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 32]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Purpose:
-
-   Allows an application to acquire a handle for a pre-existing
-   credential by name.  GSS-API implementations must impose a local
-   access-control policy on callers of this routine to prevent
-   unauthorized callers from acquiring credentials to which they are not
-   entitled.  This routine is not intended to provide a "login to the
-   network" function, as such a function would involve the creation of
-   new credentials rather than merely acquiring a handle to existing
-   credentials.  Such functions, if required, should be defined in
-   implementation-specific extensions to the API.
-
-   If desired_name is GSS_C_NO_NAME, the call is interpreted as a
-   request for a credential handle that will invoke default behavior
-   when passed to gss_init_sec_context() (if cred_usage is
-   GSS_C_INITIATE or GSS_C_BOTH) or gss_accept_sec_context() (if
-   cred_usage is GSS_C_ACCEPT or GSS_C_BOTH).
-
-   Mechanisms should honor the desired_mechs parameter, and return a
-   credential that is suitable to use only with the requested
-   mechanisms.  An exception to this is the case where one underlying
-   credential element can be shared by multiple mechanisms; in this case
-   it is permissible for an implementation to indicate all mechanisms
-   with which the credential element may be used.  If desired_mechs is
-   an empty set, behavior is undefined.
-
-   This routine is expected to be used primarily by context acceptors,
-   since implementations are likely to provide mechanism-specific ways
-   of obtaining GSS-API initiator credentials from the system login
-   process.  Some implementations may therefore not support the
-   acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via
-   gss_acquire_cred for any name other than GSS_C_NO_NAME, or a name
-   produced by applying either gss_inquire_cred to a valid credential,
-   or gss_inquire_context to an active context.
-
-   If credential acquisition is time-consuming for a mechanism, the
-   mechanism may choose to delay the actual acquisition until the
-   credential is required (e.g. by gss_init_sec_context or
-   gss_accept_sec_context).  Such mechanism-specific implementation
-   decisions should be invisible to the calling application; thus a call
-   of gss_inquire_cred immediately following the call of
-   gss_acquire_cred must return valid credential data, and may therefore
-   incur the overhead of a deferred credential acquisition.
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 33]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Parameters:
-
-   desired_name      gss_name_t, read
-                     Name of principal whose credential
-                     should be acquired
-
-   time_req          Integer, read, optional
-                     number of seconds that credentials
-                     should remain valid. Specify GSS_C_INDEFINITE
-                     to request that the credentials have the maximum
-                     permitted lifetime.
-
-   desired_mechs     Set of Object IDs, read, optional
-                     set of underlying security mechanisms that
-                     may be used.  GSS_C_NO_OID_SET may be used
-                     to obtain an implementation-specific default.
-
-   cred_usage        gss_cred_usage_t, read
-                     GSS_C_BOTH - Credentials may be used
-                        either to initiate or accept
-                        security contexts.
-                     GSS_C_INITIATE - Credentials will only be
-                        used to initiate security contexts.
-                     GSS_C_ACCEPT - Credentials will only be used to
-                        accept security contexts.
-
-   output_cred_handle  gss_cred_id_t, modify
-                       The returned credential handle.  Resources
-                       associated with this credential handle must
-                       be released by the application after use
-                       with a call to gss_release_cred().
-
-   actual_mechs      Set of Object IDs, modify, optional
-                     The set of mechanisms for which the
-                     credential is valid.  Storage associated
-                     with the returned OID-set must be released by
-                     the application after use with a call to
-                     gss_release_oid_set().  Specify NULL if not
-                     required.
-
-   time_rec          Integer, modify, optional
-                     Actual number of seconds for which the
-                     returned credentials will remain valid.  If the
-                     implementation does not support expiration of
-                     credentials, the value GSS_C_INDEFINITE will
-                     be returned. Specify NULL if not required
-
-
-
-
-
-Wray                        Standards Track                    [Page 34]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   minor_status      Integer, modify
-                     Mechanism specific status code.
-
-   Function value:  GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_BAD_MECH    Unavailable mechanism requested
-
-   GSS_S_BAD_NAMETYPE Type contained within desired_name parameter
-                      is not supported
-
-   GSS_S_BAD_NAME    Value supplied for desired_name parameter is ill
-                     formed.
-
-   GSS_S_CREDENTIALS_EXPIRED The credentials could not be acquired
-                             Because they have expired.
-
-   GSS_S_NO_CRED     No credentials were found for the specified name.
-
-5.3. gss_add_cred
-
-   OM_uint32 gss_add_cred (
-     OM_uint32           *minor_status,
-     const gss_cred_id_t input_cred_handle,
-     const gss_name_t    desired_name,
-     const gss_OID       desired_mech,
-     gss_cred_usage_t    cred_usage,
-     OM_uint32           initiator_time_req,
-     OM_uint32           acceptor_time_req,
-     gss_cred_id_t       *output_cred_handle,
-     gss_OID_set         *actual_mechs,
-     OM_uint32           *initiator_time_rec,
-     OM_uint32           *acceptor_time_rec)
-
-   Purpose:
-
-   Adds a credential-element to a credential.  The credential-element is
-   identified by the name of the principal to which it refers.  GSS-API
-   implementations must impose a local access-control policy on callers
-   of this routine to prevent unauthorized callers from acquiring
-   credential-elements to which they are not entitled. This routine is
-   not intended to provide a "login to the network" function, as such a
-   function would involve the creation of new mechanism-specific
-   authentication data, rather than merely acquiring a GSS-API handle to
-   existing data.  Such functions, if required, should be defined in
-   implementation-specific extensions to the API.
-
-
-
-
-Wray                        Standards Track                    [Page 35]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   If desired_name is GSS_C_NO_NAME, the call is interpreted as a
-   request to add a credential element that will invoke default behavior
-   when passed to gss_init_sec_context() (if cred_usage is
-   GSS_C_INITIATE or GSS_C_BOTH) or gss_accept_sec_context() (if
-   cred_usage is GSS_C_ACCEPT or GSS_C_BOTH).
-
-   This routine is expected to be used primarily by context acceptors,
-   since implementations are likely to provide mechanism-specific ways
-   of obtaining GSS-API initiator credentials from the system login
-   process.  Some implementations may therefore not support the
-   acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via
-   gss_acquire_cred for any name other than GSS_C_NO_NAME, or a name
-   produced by applying either gss_inquire_cred to a valid credential,
-   or gss_inquire_context to an active context.
-
-   If credential acquisition is time-consuming for a mechanism, the
-   mechanism may choose to delay the actual acquisition until the
-   credential is required (e.g. by gss_init_sec_context or
-   gss_accept_sec_context).  Such mechanism-specific implementation
-   decisions should be invisible to the calling application; thus a call
-   of gss_inquire_cred immediately following the call of gss_add_cred
-   must return valid credential data, and may therefore incur the
-   overhead of a deferred credential acquisition.
-
-   This routine can be used to either compose a new credential
-   containing all credential-elements of the original in addition to the
-   newly-acquire credential-element, or to add the new credential-
-   element to an existing credential. If NULL is specified for the
-   output_cred_handle parameter argument, the new credential-element
-   will be added to the credential identified by input_cred_handle; if a
-   valid pointer is specified for the output_cred_handle parameter, a
-   new credential handle will be created.
-
-   If GSS_C_NO_CREDENTIAL is specified as the input_cred_handle,
-   gss_add_cred will compose a credential (and set the
-   output_cred_handle parameter accordingly) based on default behavior.
-   That is, the call will have the same effect as if the application had
-   first made a call to gss_acquire_cred(), specifying the same usage
-   and passing GSS_C_NO_NAME as the desired_name parameter to obtain an
-   explicit credential handle embodying default behavior, passed this
-   credential handle to gss_add_cred(), and finally called
-   gss_release_cred() on the first credential handle.
-
-   If GSS_C_NO_CREDENTIAL is specified as the input_cred_handle
-   parameter, a non-NULL output_cred_handle must be supplied.
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 36]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code.
-
-   input_cred_handle gss_cred_id_t, read, optional
-                     The credential to which a credential-element
-                     will be added.  If GSS_C_NO_CREDENTIAL is
-                     specified, the routine will compose the new
-                     credential based on default behavior (see
-                     description above).  Note that, while the
-                     credential-handle is not modified by
-                     gss_add_cred(), the underlying credential
-                     will be modified if output_credential_handle
-                     is NULL.
-
-   desired_name      gss_name_t, read.
-                     Name of principal whose credential
-                     should be acquired.
-
-   desired_mech      Object ID, read
-                     Underlying security mechanism with which the
-                     credential may be used.
-
-   cred_usage        gss_cred_usage_t, read
-                     GSS_C_BOTH - Credential may be used
-                     either to initiate or accept
-                     security contexts.
-                     GSS_C_INITIATE - Credential will only be
-                                      used to initiate security
-                                      contexts.
-                     GSS_C_ACCEPT - Credential will only be used to
-                                    accept security contexts.
-
-   initiator_time_req Integer, read, optional
-                      number of seconds that the credential
-                      should remain valid for initiating security
-                      contexts.  This argument is ignored if the
-                      composed credentials are of type GSS_C_ACCEPT.
-                      Specify GSS_C_INDEFINITE to request that the
-                      credentials have the maximum permitted
-                      initiator lifetime.
-
-   acceptor_time_req Integer, read, optional
-                     number of seconds that the credential
-                     should remain valid for accepting security
-                     contexts.  This argument is ignored if the
-                     composed credentials are of type GSS_C_INITIATE.
-
-
-
-Wray                        Standards Track                    [Page 37]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-                     Specify GSS_C_INDEFINITE to request that the
-                     credentials have the maximum permitted initiator
-                     lifetime.
-
-   output_cred_handle gss_cred_id_t, modify, optional
-                      The returned credential handle, containing
-                      the new credential-element and all the
-                      credential-elements from input_cred_handle.
-                      If a valid pointer to a gss_cred_id_t is
-                      supplied for this parameter, gss_add_cred
-                      creates a new credential handle containing all
-                      credential-elements from the input_cred_handle
-                      and the newly acquired credential-element; if
-                      NULL is specified for this parameter, the newly
-                      acquired credential-element will be added
-                      to the credential identified by input_cred_handle.
-
-                      The resources associated with any credential
-                      handle returned via this parameter must be
-                      released by the application after use with a
-                      call to gss_release_cred().
-
-   actual_mechs      Set of Object IDs, modify, optional
-                     The complete set of mechanisms for which
-                     the new credential is valid.  Storage for
-                     the returned OID-set must be freed by the
-                     application after use with a call to
-                     gss_release_oid_set(). Specify NULL if
-                     not required.
-
-   initiator_time_rec Integer, modify, optional
-                      Actual number of seconds for which the
-                      returned credentials will remain valid for
-                      initiating contexts using the specified
-                      mechanism.  If the implementation or mechanism
-                      does not support expiration of credentials, the
-                      value GSS_C_INDEFINITE will be returned. Specify
-                      NULL if not required
-
-   acceptor_time_rec Integer, modify, optional
-                     Actual number of seconds for which the
-                     returned credentials will remain valid for
-                     accepting security contexts using the specified
-                     mechanism.  If the implementation or mechanism
-                     does not support expiration of credentials, the
-                     value GSS_C_INDEFINITE will be returned. Specify
-                     NULL if not required
-
-
-
-
-Wray                        Standards Track                    [Page 38]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_BAD_MECH    Unavailable mechanism requested
-
-   GSS_S_BAD_NAMETYPE Type contained within desired_name parameter
-                     is not supported
-
-   GSS_S_BAD_NAME    Value supplied for desired_name parameter is
-                     ill-formed.
-
-   GSS_S_DUPLICATE_ELEMENT The credential already contains an element
-                     for the requested mechanism with overlapping
-                     usage and validity period.
-
-   GSS_S_CREDENTIALS_EXPIRED The required credentials could not be
-                     added because they have expired.
-
-   GSS_S_NO_CRED     No credentials were found for the specified name.
-
-5.4. gss_add_oid_set_member
-
-   OM_uint32 gss_add_oid_set_member (
-     OM_uint32       *minor_status,
-     const gss_OID   member_oid,
-     gss_OID_set     *oid_set)
-
-   Purpose:
-
-   Add an Object Identifier to an Object Identifier set.  This routine
-   is intended for use in conjunction with gss_create_empty_oid_set when
-   constructing a set of mechanism OIDs for input to gss_acquire_cred.
-   The oid_set parameter must refer to an OID-set that was created by
-   GSS-API (e.g. a set returned by gss_create_empty_oid_set()). GSS-API
-   creates a copy of the member_oid and inserts this copy into the set,
-   expanding the storage allocated to the OID-set's elements array if
-   necessary.  The routine may add the new member OID anywhere within
-   the elements array, and implementations should verify that the new
-   member_oid is not already contained within the elements array; if the
-   member_oid is already present, the oid_set should remain unchanged.
-
-   Parameters:
-
-      minor_status      Integer, modify
-                        Mechanism specific status code
-
-
-
-
-
-Wray                        Standards Track                    [Page 39]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-      member_oid        Object ID, read
-                        The object identifier to copied into
-                        the set.
-
-      oid_set           Set of Object ID, modify
-                        The set in which the object identifier
-                        should be inserted.
-
-   Function value:   GSS status code
-
-      GSS_S_COMPLETE    Successful completion
-
-5.5. gss_canonicalize_name
-
-   OM_uint32 gss_canonicalize_name (
-     OM_uint32        *minor_status,
-     const gss_name_t input_name,
-     const gss_OID    mech_type,
-     gss_name_t       *output_name)
-
-   Purpose:
-
-   Generate a canonical mechanism name (MN) from an arbitrary internal
-   name.  The mechanism name is the name that would be returned to a
-   context acceptor on successful authentication of a context where the
-   initiator used the input_name in a successful call to
-   gss_acquire_cred, specifying an OID set containing <mech_type> as its
-   only member, followed by a call to gss_init_sec_context, specifying
-   <mech_type> as the authentication mechanism.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code
-
-   input_name        gss_name_t, read
-                     The name for which a canonical form is
-                     desired
-
-   mech_type         Object ID, read
-                     The authentication mechanism for which the
-                     canonical form of the name is desired.  The
-                     desired mechanism must be specified explicitly;
-                     no default is provided.
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 40]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   output_name       gss_name_t, modify
-                     The resultant canonical name.  Storage
-                     associated with this name must be freed by
-                     the application after use with a call to
-                     gss_release_name().
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion.
-
-   GSS_S_BAD_MECH    The identified mechanism is not supported.
-
-   GSS_S_BAD_NAMETYPE The provided internal name contains no elements
-                     that could be processed by the specified
-                     mechanism.
-
-   GSS_S_BAD_NAME    The provided internal name was ill-formed.
-
-5.6. gss_compare_name
-
-   OM_uint32 gss_compare_name (
-     OM_uint32        *minor_status,
-     const gss_name_t name1,
-     const gss_name_t name2,
-     int              *name_equal)
-
-   Purpose:
-
-   Allows an application to compare two internal-form names to determine
-   whether they refer to the same entity.
-
-   If either name presented to gss_compare_name denotes an anonymous
-   principal, the routines should indicate that the two names do not
-   refer to the same identity.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code.
-
-   name1             gss_name_t, read
-                     internal-form name
-
-   name2             gss_name_t, read
-                     internal-form name
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 41]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   name_equal        boolean, modify
-                     non-zero - names refer to same entity
-                     zero - names refer to different entities
-                           (strictly, the names are not known
-                           to refer to the same identity).
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_BAD_NAMETYPE The two names were of incomparable types.
-
-   GSS_S_BAD_NAME    One or both of name1 or name2 was ill-formed.
-
-5.7. gss_context_time
-
-   OM_uint32 gss_context_time (
-     OM_uint32          *minor_status,
-     const gss_ctx_id_t context_handle,
-     OM_uint32          *time_rec)
-
-   Purpose:
-
-   Determines the number of seconds for which the specified context will
-   remain valid.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Implementation specific status code.
-
-   context_handle    gss_ctx_id_t, read
-                     Identifies the context to be interrogated.
-
-   time_rec          Integer, modify
-                     Number of seconds that the context will remain
-                     valid.  If the context has already expired,
-                     zero will be returned.
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_CONTEXT_EXPIRED The context has already expired
-
-   GSS_S_NO_CONTEXT  The context_handle parameter did not identify
-                     a valid context
-
-
-
-
-Wray                        Standards Track                    [Page 42]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-5.8. gss_create_empty_oid_set
-
-   OM_uint32 gss_create_empty_oid_set (
-     OM_uint32    *minor_status,
-     gss_OID_set  *oid_set)
-
-   Purpose:
-
-   Create an object-identifier set containing no object identifiers, to
-   which members may be subsequently added using the
-   gss_add_oid_set_member() routine.  These routines are intended to be
-   used to construct sets of mechanism object identifiers, for input to
-   gss_acquire_cred.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code
-
-   oid_set           Set of Object IDs, modify
-                     The empty object identifier set.
-                     The routine will allocate the
-                     gss_OID_set_desc object, which the
-                     application must free after use with
-                     a call to gss_release_oid_set().
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-5.9. gss_delete_sec_context
-
-   OM_uint32 gss_delete_sec_context (
-     OM_uint32    *minor_status,
-     gss_ctx_id_t *context_handle,
-     gss_buffer_t output_token)
-
-   Purpose:
-
-   Delete a security context.  gss_delete_sec_context will delete the
-   local data structures associated with the specified security context,
-   and may generate an output_token, which when passed to the peer
-   gss_process_context_token will instruct it to do likewise.  If no
-   token is required by the mechanism, the GSS-API should set the length
-   field of the output_token (if provided) to zero.  No further security
-   services may be obtained using the context specified by
-   context_handle.
-
-
-
-
-Wray                        Standards Track                    [Page 43]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   In addition to deleting established security contexts,
-   gss_delete_sec_context must also be able to delete "half-built"
-   security contexts resulting from an incomplete sequence of
-   gss_init_sec_context()/gss_accept_sec_context() calls.
-
-   The output_token parameter is retained for compatibility with version
-   1 of the GSS-API.  It is recommended that both peer applications
-   invoke gss_delete_sec_context passing the value GSS_C_NO_BUFFER for
-   the output_token parameter, indicating that no token is required, and
-   that gss_delete_sec_context should simply delete local context data
-   structures.  If the application does pass a valid buffer to
-   gss_delete_sec_context, mechanisms are encouraged to return a zero-
-   length token, indicating that no peer action is necessary, and that
-   no token should be transferred by the application.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code.
-
-   context_handle    gss_ctx_id_t, modify
-                     context handle identifying context to delete.
-                     After deleting the context, the GSS-API will set
-                     this context handle to GSS_C_NO_CONTEXT.
-
-   output_token      buffer, opaque, modify, optional
-                     token to be sent to remote application to
-                     instruct it to also delete the context.  It
-                     is recommended that applications specify
-                     GSS_C_NO_BUFFER for this parameter, requesting
-                     local deletion only.  If a buffer parameter is
-                     provided by the application, the mechanism may
-                     return a token in it;  mechanisms that implement
-                     only local deletion should set the length field of
-                     this token to zero to indicate to the application
-                     that no token is to be sent to the peer.
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_NO_CONTEXT  No valid context was supplied
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 44]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-5.10.gss_display_name
-
-   OM_uint32 gss_display_name (
-     OM_uint32        *minor_status,
-     const gss_name_t input_name,
-     gss_buffer_t     output_name_buffer,
-     gss_OID          *output_name_type)
-
-   Purpose:
-
-   Allows an application to obtain a textual representation of an opaque
-   internal-form  name for display purposes.  The syntax of a printable
-   name is defined by the GSS-API implementation.
-
-   If input_name denotes an anonymous principal, the implementation
-   should return the gss_OID value GSS_C_NT_ANONYMOUS as the
-   output_name_type, and a textual name that is syntactically distinct
-   from all valid supported printable names in output_name_buffer.
-
-   If input_name was created by a call to gss_import_name, specifying
-   GSS_C_NO_OID as the name-type, implementations that employ lazy
-   conversion between name types may return GSS_C_NO_OID via the
-   output_name_type parameter.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code.
-
-   input_name        gss_name_t, read
-                     name to be displayed
-
-   output_name_buffer  buffer, character-string, modify
-                     buffer to receive textual name string.
-                     The application must free storage associated
-                     with this name after use with a call to
-                     gss_release_buffer().
-
-   output_name_type  Object ID, modify, optional
-                     The type of the returned name.  The returned
-                     gss_OID will be a pointer into static storage,
-                     and should be treated as read-only by the caller
-                     (in particular, the application should not attempt
-                     to free it). Specify NULL if not required.
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 45]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_BAD_NAME    input_name was ill-formed
-
-5.11.gss_display_status
-
-   OM_uint32 gss_display_status (
-     OM_uint32      *minor_status,
-     OM_uint32      status_value,
-     int            status_type,
-     const gss_OID  mech_type,
-     OM_uint32      *message_context,
-     gss_buffer_t   status_string)
-
-   Purpose:
-
-   Allows an application to obtain a textual representation of a GSS-API
-   status code, for display to the user or for logging purposes.  Since
-   some status values may indicate multiple conditions, applications may
-   need to call gss_display_status multiple times, each call generating
-   a single text string.  The message_context parameter is used by
-   gss_display_status to store state information about which error
-   messages have already been extracted from a given status_value;
-   message_context must be initialized to 0 by the application prior to
-   the first call, and gss_display_status will return a non-zero value
-   in this parameter if there are further messages to extract.
-
-   The message_context parameter contains all state information required
-   by gss_display_status in order to extract further messages from the
-   status_value;  even when a non-zero value is returned in this
-   parameter, the application is not required to call gss_display_status
-   again unless subsequent messages are desired.  The following code
-   extracts all messages from a given status code and prints them to
-   stderr:
-
-   OM_uint32 message_context;
-   OM_uint32 status_code;
-   OM_uint32 maj_status;
-   OM_uint32 min_status;
-   gss_buffer_desc status_string;
-
-          ...
-
-   message_context = 0;
-
-   do {
-
-
-
-Wray                        Standards Track                    [Page 46]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-     maj_status = gss_display_status (
-                     &min_status,
-                     status_code,
-                     GSS_C_GSS_CODE,
-                     GSS_C_NO_OID,
-                     &message_context,
-                     &status_string)
-
-     fprintf(stderr,
-             "%.*s\n",
-            (int)status_string.length,
-
-            (char *)status_string.value);
-
-     gss_release_buffer(&min_status, &status_string);
-
-   } while (message_context != 0);
-
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code.
-
-   status_value      Integer, read
-                     Status value to be converted
-
-   status_type       Integer, read
-                     GSS_C_GSS_CODE - status_value is a GSS status
-                     code
-
-   GSS_C_MECH_CODE - status_value is a mechanism
-                     status code
-
-   mech_type         Object ID, read, optional
-                     Underlying mechanism (used to interpret a
-                     minor status value) Supply GSS_C_NO_OID to
-                     obtain the system default.
-
-   message_context   Integer, read/modify
-                     Should be initialized to zero by the
-                     application prior to the first call.
-                     On return from gss_display_status(),
-                     a non-zero status_value parameter indicates
-                     that additional messages may be extracted
-                     from the status code via subsequent calls
-
-
-
-
-
-Wray                        Standards Track                    [Page 47]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-                     to gss_display_status(), passing the same
-                     status_value, status_type, mech_type, and
-                     message_context parameters.
-
-   status_string     buffer, character string, modify
-                     textual interpretation of the status_value.
-                     Storage associated with this parameter must
-                     be freed by the application after use with
-                     a call to gss_release_buffer().
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_BAD_MECH    Indicates that translation in accordance with
-                     an unsupported mechanism type was requested
-
-   GSS_S_BAD_STATUS  The status value was not recognized, or the
-                     status type was neither GSS_C_GSS_CODE nor
-                     GSS_C_MECH_CODE.
-
-5.12. gss_duplicate_name
-
-   OM_uint32 gss_duplicate_name (
-     OM_uint32        *minor_status,
-     const gss_name_t src_name,
-     gss_name_t       *dest_name)
-
-   Purpose:
-
-   Create an exact duplicate of the existing internal name src_name.
-   The new dest_name will be independent of src_name (i.e. src_name and
-   dest_name must both be released, and the release of one shall not
-   affect the validity of the other).
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code.
-
-   src_name          gss_name_t, read
-                     internal name to be duplicated.
-
-   dest_name         gss_name_t, modify
-                     The resultant copy of <src_name>.
-                     Storage associated with this name must
-                     be freed by the application after use
-                     with a call to gss_release_name().
-
-
-
-Wray                        Standards Track                    [Page 48]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_BAD_NAME    The src_name parameter was ill-formed.
-
-5.13. gss_export_name
-
-   OM_uint32 gss_export_name (
-     OM_uint32        *minor_status,
-     const gss_name_t input_name,
-     gss_buffer_t     exported_name)
-
-   Purpose:
-
-   To produce a canonical contiguous string representation of a
-   mechanism name (MN), suitable for direct comparison (e.g. with
-   memcmp) for use in authorization functions (e.g. matching entries in
-   an access-control list).  The <input_name> parameter must specify a
-   valid MN (i.e. an internal name generated by gss_accept_sec_context
-   or by gss_canonicalize_name).
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code
-
-   input_name        gss_name_t, read
-                     The MN to be exported
-
-   exported_name     gss_buffer_t, octet-string, modify
-                     The canonical contiguous string form of
-                     <input_name>.  Storage associated with
-                     this string must freed by the application
-                     after use with gss_release_buffer().
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_NAME_NOT_MN The provided internal name was not a mechanism
-                     name.
-
-   GSS_S_BAD_NAME    The provided internal name was ill-formed.
-
-   GSS_S_BAD_NAMETYPE The internal name was of a type not supported
-                     by the GSS-API implementation.
-
-
-
-
-Wray                        Standards Track                    [Page 49]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-5.14. gss_export_sec_context
-
-   OM_uint32 gss_export_sec_context (
-     OM_uint32    *minor_status,
-     gss_ctx_id_t *context_handle,
-     gss_buffer_t interprocess_token)
-
-   Purpose:
-
-   Provided to support the sharing of work between multiple processes.
-   This routine will typically be used by the context-acceptor, in an
-   application where a single process receives incoming connection
-   requests and accepts security contexts over them, then passes the
-   established context to one or more other processes for message
-   exchange. gss_export_sec_context() deactivates the security context
-   for the calling process and creates an interprocess token which, when
-   passed to gss_import_sec_context in another process, will re-activate
-   the context in the second process. Only a single instantiation of a
-   given context may be active at any one time; a subsequent attempt by
-   a context exporter to access the exported security context will fail.
-
-   The implementation may constrain the set of processes by which the
-   interprocess token may be imported, either as a function of local
-   security policy, or as a result of implementation decisions.  For
-   example, some implementations may constrain contexts to be passed
-   only between processes that run under the same account, or which are
-   part of the same process group.
-
-   The interprocess token may contain security-sensitive information
-   (for example cryptographic keys).  While mechanisms are encouraged to
-   either avoid placing such sensitive information within interprocess
-   tokens, or to encrypt the token before returning it to the
-   application, in a typical object-library GSS-API implementation this
-   may not be possible. Thus the application must take care to protect
-   the interprocess token, and ensure that any process to which the
-   token is transferred is trustworthy.
-
-   If creation of the interprocess token is successful, the
-   implementation shall deallocate all process-wide resources associated
-   with the security context, and set the context_handle to
-   GSS_C_NO_CONTEXT.  In the event of an error that makes it impossible
-   to complete the export of the security context, the implementation
-   must not return an interprocess token, and should strive to leave the
-   security context referenced by the context_handle parameter
-   untouched.  If this is impossible, it is permissible for the
-   implementation to delete the security context, providing it also sets
-   the context_handle parameter to GSS_C_NO_CONTEXT.
-
-
-
-
-Wray                        Standards Track                    [Page 50]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code
-
-   context_handle    gss_ctx_id_t, modify
-                     context handle identifying the context to
-                     transfer.
-
-   interprocess_token   buffer, opaque, modify
-                        token to be transferred to target process.
-                        Storage associated with this token must be
-                        freed by the application after use with a
-                        call to gss_release_buffer().
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_CONTEXT_EXPIRED The context has expired
-
-   GSS_S_NO_CONTEXT  The context was invalid
-
-   GSS_S_UNAVAILABLE The operation is not supported.
-
-5.15. gss_get_mic
-
-   OM_uint32 gss_get_mic (
-     OM_uint32          *minor_status,
-     const gss_ctx_id_t context_handle,
-     gss_qop_t             qop_req,
-     const gss_buffer_t message_buffer,
-     gss_buffer_t       msg_token)
-
-   Purpose:
-
-   Generates a cryptographic MIC for the supplied message, and places
-   the MIC in a token for transfer to the peer application. The qop_req
-   parameter allows a choice between several cryptographic algorithms,
-   if supported by the chosen mechanism.
-
-   Since some application-level protocols may wish to use tokens emitted
-   by gss_wrap() to provide "secure framing", implementations must
-   support derivation of MICs from zero-length messages.
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 51]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Implementation specific status code.
-
-   context_handle    gss_ctx_id_t, read
-                     identifies the context on which the message
-                     will be sent
-
-   qop_req           gss_qop_t, read, optional
-                     Specifies requested quality of protection.
-                     Callers are encouraged, on portability grounds,
-                     to accept the default quality of protection
-                     offered by the chosen mechanism, which may be
-                     requested by specifying GSS_C_QOP_DEFAULT for
-                     this parameter.  If an unsupported protection
-                     strength is requested, gss_get_mic will return a
-                     major_status of GSS_S_BAD_QOP.
-
-   message_buffer    buffer, opaque, read
-                     message to be protected
-
-   msg_token         buffer, opaque, modify
-                     buffer to receive token.  The application must
-                     free storage associated with this buffer after
-                     use with a call to gss_release_buffer().
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_CONTEXT_EXPIRED The context has already expired
-
-   GSS_S_NO_CONTEXT  The context_handle parameter did not identify
-                     a valid context
-
-   GSS_S_BAD_QOP     The specified QOP is not supported by the
-                     mechanism.
-
-5.16. gss_import_name
-
-   OM_uint32 gss_import_name (
-     OM_uint32          *minor_status,
-     const gss_buffer_t input_name_buffer,
-     const gss_OID      input_name_type,
-     gss_name_t         *output_name)
-
-
-
-
-
-Wray                        Standards Track                    [Page 52]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Purpose:
-
-   Convert a contiguous string name to internal form.  In general, the
-   internal name returned (via the <output_name> parameter) will not be
-   an MN; the exception to this is if the <input_name_type> indicates
-   that the contiguous string provided via the <input_name_buffer>
-   parameter is of type GSS_C_NT_EXPORT_NAME, in which case the returned
-   internal name will be an MN for the mechanism that exported the name.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code
-
-   input_name_buffer  buffer, octet-string, read
-                     buffer containing contiguous string name to convert
-
-   input_name_type   Object ID, read, optional
-                     Object ID specifying type of printable
-                     name.  Applications may specify either
-                     GSS_C_NO_OID to use a mechanism-specific
-                     default printable syntax, or an OID recognized
-                     by the GSS-API implementation to name a
-                     specific namespace.
-
-   output_name       gss_name_t, modify
-                     returned name in internal form.  Storage
-                     associated with this name must be freed
-                     by the application after use with a call
-                     to gss_release_name().
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_BAD_NAMETYPE The input_name_type was unrecognized
-
-   GSS_S_BAD_NAME    The input_name parameter could not be interpreted
-                     as a name of the specified type
-
-   GSS_S_BAD_MECH    The input name-type was GSS_C_NT_EXPORT_NAME,
-                     but the mechanism contained within the
-                     input-name is not supported
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 53]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-5.17. gss_import_sec_context
-
-   OM_uint32 gss_import_sec_context (
-     OM_uint32          *minor_status,
-     const gss_buffer_t interprocess_token,
-     gss_ctx_id_t       *context_handle)
-
-   Purpose:
-
-   Allows a process to import a security context established by another
-   process.  A given interprocess token may be imported only once.  See
-   gss_export_sec_context.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code
-
-   interprocess_token  buffer, opaque, modify
-                       token received from exporting process
-
-   context_handle    gss_ctx_id_t, modify
-                     context handle of newly reactivated context.
-                     Resources associated with this context handle
-                     must be released by the application after use
-                     with a call to gss_delete_sec_context().
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion.
-
-   GSS_S_NO_CONTEXT  The token did not contain a valid context
-   reference.
-
-   GSS_S_DEFECTIVE_TOKEN The token was invalid.
-
-   GSS_S_UNAVAILABLE The operation is unavailable.
-
-   GSS_S_UNAUTHORIZED Local policy prevents the import of this context
-                      by the current process.
-
-5.18. gss_indicate_mechs
-
-   OM_uint32 gss_indicate_mechs (
-     OM_uint32   *minor_status,
-     gss_OID_set *mech_set)
-
-
-
-
-
-Wray                        Standards Track                    [Page 54]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Purpose:
-
-   Allows an application to determine which underlying security
-   mechanisms are available.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code.
-
-   mech_set          set of Object IDs, modify
-                     set of implementation-supported mechanisms.
-                     The returned gss_OID_set value will be a
-                     dynamically-allocated OID set, that should
-                     be released by the caller after use with a
-                     call to gss_release_oid_set().
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-5.19. gss_init_sec_context
-
-   OM_uint32 gss_init_sec_context (
-     OM_uint32                    *minor_status,
-     const gss_cred_id_t          initiator_cred_handle,
-     gss_ctx_id_t                 *context_handle,\
-     const gss_name_t             target_name,
-     const gss_OID                mech_type,
-     OM_uint32                    req_flags,
-     OM_uint32                    time_req,
-     const gss_channel_bindings_t input_chan_bindings,
-     const gss_buffer_t           input_token
-     gss_OID                      *actual_mech_type,
-     gss_buffer_t                 output_token,
-     OM_uint32                    *ret_flags,
-     OM_uint32                    *time_rec )
-
-   Purpose:
-
-   Initiates the establishment of a security context between the
-   application and a remote peer.  Initially, the input_token parameter
-   should be specified either as GSS_C_NO_BUFFER, or as a pointer to a
-   gss_buffer_desc object whose length field contains the value zero.
-   The routine may return a output_token which should be transferred to
-   the peer application, where the peer application will present it to
-   gss_accept_sec_context.  If no token need be sent,
-   gss_init_sec_context will indicate this by setting the length field
-
-
-
-Wray                        Standards Track                    [Page 55]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   of the output_token argument to zero. To complete the context
-   establishment, one or more reply tokens may be required from the peer
-   application; if so, gss_init_sec_context will return a status
-   containing the supplementary information bit GSS_S_CONTINUE_NEEDED.
-   In this case, gss_init_sec_context should be called again when the
-   reply token is received from the peer application, passing the reply
-   token to gss_init_sec_context via the input_token parameters.
-
-   Portable applications should be constructed to use the token length
-   and return status to determine whether a token needs to be sent or
-   waited for.  Thus a typical portable caller should always invoke
-   gss_init_sec_context within a loop:
-
-   int context_established = 0;
-   gss_ctx_id_t context_hdl = GSS_C_NO_CONTEXT;
-          ...
-   input_token->length = 0;
-
-   while (!context_established) {
-     maj_stat = gss_init_sec_context(&min_stat,
-                                     cred_hdl,
-                                     &context_hdl,
-                                     target_name,
-                                     desired_mech,
-                                     desired_services,
-                                     desired_time,
-                                     input_bindings,
-                                     input_token,
-                                     &actual_mech,
-                                     output_token,
-                                     &actual_services,
-                                     &actual_time);
-     if (GSS_ERROR(maj_stat)) {
-       report_error(maj_stat, min_stat);
-     };
-
-     if (output_token->length != 0) {
-       send_token_to_peer(output_token);
-       gss_release_buffer(&min_stat, output_token)
-     };
-     if (GSS_ERROR(maj_stat)) {
-
-       if (context_hdl != GSS_C_NO_CONTEXT)
-         gss_delete_sec_context(&min_stat,
-                                &context_hdl,
-                                GSS_C_NO_BUFFER);
-       break;
-     };
-
-
-
-Wray                        Standards Track                    [Page 56]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-     if (maj_stat & GSS_S_CONTINUE_NEEDED) {
-       receive_token_from_peer(input_token);
-     } else {
-       context_established = 1;
-     };
-   };
-
-   Whenever the routine returns a major status that includes the value
-   GSS_S_CONTINUE_NEEDED, the context is not fully established and the
-   following restrictions apply to the output parameters:
-
-      The value returned via the time_rec parameter is undefined Unless
-      the accompanying ret_flags parameter contains the bit
-      GSS_C_PROT_READY_FLAG, indicating that per-message services may be
-      applied in advance of a successful completion status, the value
-      returned via the actual_mech_type parameter is undefined until the
-      routine returns a major status value of GSS_S_COMPLETE.
-
-      The values of the GSS_C_DELEG_FLAG, GSS_C_MUTUAL_FLAG,
-      GSS_C_REPLAY_FLAG, GSS_C_SEQUENCE_FLAG, GSS_C_CONF_FLAG,
-      GSS_C_INTEG_FLAG and GSS_C_ANON_FLAG bits returned via the
-      ret_flags parameter should contain the values that the
-      implementation expects would be valid if context establishment
-      were to succeed.  In particular, if the application has requested
-      a service such as delegation or anonymous authentication via the
-      req_flags argument, and such a service is unavailable from the
-      underlying mechanism, gss_init_sec_context should generate a token
-      that will not provide the service, and indicate via the ret_flags
-      argument that the service will not be supported.  The application
-      may choose to abort the context establishment by calling
-      gss_delete_sec_context (if it cannot continue in the absence of
-      the service), or it may choose to transmit the token and continue
-      context establishment (if the service was merely desired but not
-      mandatory).
-
-      The values of the GSS_C_PROT_READY_FLAG and GSS_C_TRANS_FLAG bits
-      within ret_flags should indicate the actual state at the time
-      gss_init_sec_context returns, whether or not the context is fully
-      established.
-
-      GSS-API implementations that support per-message protection are
-      encouraged to set the GSS_C_PROT_READY_FLAG in the final ret_flags
-      returned to a caller (i.e. when accompanied by a GSS_S_COMPLETE
-      status code).  However, applications should not rely on this
-      behavior as the flag was not defined in Version 1 of the GSS-API.
-      Instead, applications should determine what per-message services
-      are available after a successful context establishment according
-      to the GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG values.
-
-
-
-Wray                        Standards Track                    [Page 57]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-      All other bits within the ret_flags argument should be set to
-      zero.
-
-   If the initial call of gss_init_sec_context() fails, the
-   implementation should not create a context object, and should leave
-   the value of the context_handle parameter set to GSS_C_NO_CONTEXT to
-   indicate this.  In the event of a failure on a subsequent call, the
-   implementation is permitted to delete the "half-built" security
-   context (in which case it should set the context_handle parameter to
-   GSS_C_NO_CONTEXT), but the preferred behavior is to leave the
-   security context untouched for the application to delete (using
-   gss_delete_sec_context).
-
-   During context establishment, the informational status bits
-   GSS_S_OLD_TOKEN and GSS_S_DUPLICATE_TOKEN indicate fatal errors, and
-   GSS-API mechanisms should always return them in association with a
-   routine error of GSS_S_FAILURE.  This requirement for pairing did not
-   exist in version 1 of the GSS-API specification, so applications that
-   wish to run over version 1 implementations must special-case these
-   codes.
-
-   Parameters:
-
-   minor_status      Integer,  modify
-                     Mechanism specific status code.
-
-   initiator_cred_handle  gss_cred_id_t, read, optional
-                          handle for credentials claimed.  Supply
-                          GSS_C_NO_CREDENTIAL to act as a default
-                          initiator principal.  If no default
-                          initiator is defined, the function will
-                          return GSS_S_NO_CRED.
-
-   context_handle    gss_ctx_id_t, read/modify
-                     context handle for new context.  Supply
-                     GSS_C_NO_CONTEXT for first call; use value
-                     returned by first call in continuation calls.
-                     Resources associated with this context-handle
-                     must be released by the application after use
-                     with a call to gss_delete_sec_context().
-
-   target_name       gss_name_t, read
-                     Name of target
-
-   mech_type         OID, read, optional
-                     Object ID of desired mechanism. Supply
-                     GSS_C_NO_OID to obtain an implementation
-                     specific default
-
-
-
-Wray                        Standards Track                    [Page 58]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   req_flags         bit-mask, read
-                     Contains various independent flags, each of
-                     which requests that the context support a
-                     specific service option.  Symbolic
-                     names are provided for each flag, and the
-                     symbolic names corresponding to the required
-                     flags should be logically-ORed
-                     together to form the bit-mask value.  The
-                     flags are:
-
-                     GSS_C_DELEG_FLAG
-                       True - Delegate credentials to remote peer
-                       False - Don't delegate
-
-                     GSS_C_MUTUAL_FLAG
-                       True - Request that remote peer
-                              authenticate itself
-                       False - Authenticate self to remote peer
-                               only
-
-                     GSS_C_REPLAY_FLAG
-                       True - Enable replay detection for
-                              messages protected with gss_wrap
-                              or gss_get_mic
-                       False - Don't attempt to detect
-                               replayed messages
-
-                     GSS_C_SEQUENCE_FLAG
-                       True - Enable detection of out-of-sequence
-                              protected messages
-                       False - Don't attempt to detect
-                               out-of-sequence messages
-
-                     GSS_C_CONF_FLAG
-                       True - Request that confidentiality service
-                              be made available (via gss_wrap)
-                       False - No per-message confidentiality service
-                               is required.
-
-                     GSS_C_INTEG_FLAG
-                       True - Request that integrity service be
-                              made available (via gss_wrap or
-                              gss_get_mic)
-                       False - No per-message integrity service
-                               is required.
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 59]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-                     GSS_C_ANON_FLAG
-                       True - Do not reveal the initiator's
-                              identity to the acceptor.
-                       False - Authenticate normally.
-
-   time_req          Integer, read, optional
-                     Desired number of seconds for which context
-                     should remain valid.  Supply 0 to request a
-                     default validity period.
-
-   input_chan_bindings  channel bindings, read, optional
-                        Application-specified bindings.  Allows
-                        application to securely bind channel
-                        identification information to the security
-                        context.  Specify GSS_C_NO_CHANNEL_BINDINGS
-                        if channel bindings are not used.
-
-   input_token       buffer, opaque, read, optional (see text)
-                     Token received from peer application.
-                     Supply GSS_C_NO_BUFFER, or a pointer to
-                     a buffer containing the value GSS_C_EMPTY_BUFFER
-                     on initial call.
-
-   actual_mech_type  OID, modify, optional
-                     Actual mechanism used.  The OID returned via
-                     this parameter will be a pointer to static
-                     storage that should be treated as read-only;
-                     In particular the application should not attempt
-                     to free it.  Specify NULL if not required.
-
-   output_token      buffer, opaque, modify
-                     token to be sent to peer application.  If
-                     the length field of the returned buffer is
-                     zero, no token need be sent to the peer
-                     application.  Storage associated with this
-                     buffer must be freed by the application
-                     after use with a call to gss_release_buffer().
-
-   ret_flags         bit-mask, modify, optional
-                     Contains various independent flags, each of which
-                     indicates that the context supports a specific
-                     service option.  Specify NULL if not
-                     required.  Symbolic names are provided
-                     for each flag, and the symbolic names
-                     corresponding to the required flags should be
-                     logically-ANDed with the ret_flags value to test
-                     whether a given option is supported by the
-                     context.  The flags are:
-
-
-
-Wray                        Standards Track                    [Page 60]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-                     GSS_C_DELEG_FLAG
-                       True - Credentials were delegated to
-                              the remote peer
-                       False - No credentials were delegated
-
-                     GSS_C_MUTUAL_FLAG
-                       True - The remote peer has authenticated
-                              itself.
-                       False - Remote peer has not authenticated
-                               itself.
-
-                     GSS_C_REPLAY_FLAG
-                       True - replay of protected messages
-                              will be detected
-                       False - replayed messages will not be
-                               detected
-
-                     GSS_C_SEQUENCE_FLAG
-                       True - out-of-sequence protected
-                              messages will be detected
-                       False - out-of-sequence messages will
-                               not be detected
-
-                     GSS_C_CONF_FLAG
-                       True - Confidentiality service may be
-                              invoked by calling gss_wrap routine
-                       False - No confidentiality service (via
-                               gss_wrap) available. gss_wrap will
-                               provide message encapsulation,
-                               data-origin authentication and
-                               integrity services only.
-
-                     GSS_C_INTEG_FLAG
-                       True - Integrity service may be invoked by
-                              calling either gss_get_mic or gss_wrap
-                              routines.
-                       False - Per-message integrity service
-                               unavailable.
-
-                     GSS_C_ANON_FLAG
-                       True - The initiator's identity has not been
-                              revealed, and will not be revealed if
-                              any emitted token is passed to the
-                              acceptor.
-                       False - The initiator's identity has been or
-                               will be authenticated normally.
-
-                     GSS_C_PROT_READY_FLAG
-
-
-
-Wray                        Standards Track                    [Page 61]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-                       True - Protection services (as specified
-                              by the states of the GSS_C_CONF_FLAG
-                              and GSS_C_INTEG_FLAG) are available for
-                              use if the accompanying major status
-                              return value is either GSS_S_COMPLETE or
-                              GSS_S_CONTINUE_NEEDED.
-                       False - Protection services (as specified
-                               by the states of the GSS_C_CONF_FLAG
-                               and GSS_C_INTEG_FLAG) are available
-                               only if the accompanying major status
-                               return value is GSS_S_COMPLETE.
-
-                     GSS_C_TRANS_FLAG
-                       True - The resultant security context may
-                              be transferred to other processes via
-                              a call to gss_export_sec_context().
-                       False - The security context is not
-                               transferable.
-
-                     All other bits should be set to zero.
-
-   time_rec          Integer, modify, optional
-                     number of seconds for which the context
-                     will remain valid. If the implementation does
-                     not support context expiration, the value
-                     GSS_C_INDEFINITE will be returned.  Specify
-                     NULL if not required.
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_CONTINUE_NEEDED Indicates that a token from the peer
-                         application is required to complete the
-                         context, and that gss_init_sec_context
-                         must be called again with that token.
-
-   GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks performed
-                         on the input_token failed
-
-   GSS_S_DEFECTIVE_CREDENTIAL Indicates that consistency checks
-                              performed on the credential failed.
-
-   GSS_S_NO_CRED     The supplied credentials were not valid for
-                     context initiation, or the credential handle
-                     did not reference any credentials.
-
-   GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired
-
-
-
-Wray                        Standards Track                    [Page 62]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   GSS_S_BAD_BINDINGS The input_token contains different channel
-                      bindings to those specified via the
-                      input_chan_bindings parameter
-
-   GSS_S_BAD_SIG     The input_token contains an invalid MIC, or a MIC
-                     that could not be verified
-
-   GSS_S_OLD_TOKEN   The input_token was too old.  This is a fatal
-                     error during context establishment
-
-   GSS_S_DUPLICATE_TOKEN The input_token is valid, but is a duplicate
-                         of a token already processed.  This is a
-                         fatal error during context establishment.
-
-   GSS_S_NO_CONTEXT  Indicates that the supplied context handle did
-                     not refer to a valid context
-
-   GSS_S_BAD_NAMETYPE The provided target_name parameter contained an
-                      invalid or unsupported type of name
-
-   GSS_S_BAD_NAME    The provided target_name parameter was ill-formed.
-
-   GSS_S_BAD_MECH    The specified mechanism is not supported by the
-                     provided credential, or is unrecognized by the
-                     implementation.
-
-5.20. gss_inquire_context
-
-   OM_uint32 gss_inquire_context (
-     OM_uint32          *minor_status,
-     const gss_ctx_id_t context_handle,
-     gss_name_t         *src_name,
-     gss_name_t         *targ_name,
-     OM_uint32          *lifetime_rec,
-     gss_OID            *mech_type,
-     OM_uint32          *ctx_flags,
-     int                *locally_initiated,
-     int                *open )
-
-   Purpose:
-
-   Obtains information about a security context.  The caller must
-   already have obtained a handle that refers to the context, although
-   the context need not be fully established.
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 63]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code
-
-   context_handle    gss_ctx_id_t, read
-                     A handle that refers to the security context.
-
-   src_name          gss_name_t, modify, optional
-                     The name of the context initiator.
-                     If the context was established using anonymous
-                     authentication, and if the application invoking
-                     gss_inquire_context is the context acceptor,
-                     an anonymous name will be returned.  Storage
-                     associated with this name must be freed by the
-                     application after use with a call to
-                     gss_release_name().  Specify NULL if not
-                     required.
-
-   targ_name         gss_name_t, modify, optional
-                     The name of the context acceptor.
-                     Storage associated with this name must be
-                     freed by the application after use with a call
-                     to gss_release_name().  If the context acceptor
-                     did not authenticate itself, and if the initiator
-                     did not specify a target name in its call to
-                     gss_init_sec_context(), the value GSS_C_NO_NAME
-                     will be returned.  Specify NULL if not required.
-
-   lifetime_rec      Integer, modify, optional
-                     The number of seconds for which the context
-                     will remain valid.  If the context has
-                     expired, this parameter will be set to zero.
-                     If the implementation does not support
-                     context expiration, the value
-                     GSS_C_INDEFINITE will be returned.  Specify
-                     NULL if not required.
-
-   mech_type         gss_OID, modify, optional
-                     The security mechanism providing the
-                     context.  The returned OID will be a
-                     pointer to static storage that should
-                     be treated as read-only by the application;
-                     in particular the application should not
-                     attempt to free it.  Specify NULL if not
-                     required.
-
-
-
-
-
-Wray                        Standards Track                    [Page 64]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   ctx_flags         bit-mask, modify, optional
-                     Contains various independent flags, each of
-                     which indicates that the context supports
-                     (or is expected to support, if ctx_open is
-                     false) a specific service option.  If not
-                     needed, specify NULL.  Symbolic names are
-                     provided for each flag, and the symbolic names
-                     corresponding to the required flags
-                     should be logically-ANDed with the ret_flags
-                     value to test whether a given option is
-                     supported by the context.  The flags are:
-
-                     GSS_C_DELEG_FLAG
-                       True - Credentials were delegated from
-                              the initiator to the acceptor.
-                       False - No credentials were delegated
-
-                     GSS_C_MUTUAL_FLAG
-                       True - The acceptor was authenticated
-                              to the initiator
-                       False - The acceptor did not authenticate
-                               itself.
-
-                     GSS_C_REPLAY_FLAG
-                       True - replay of protected messages
-                              will be detected
-                       False - replayed messages will not be
-                               detected
-
-                     GSS_C_SEQUENCE_FLAG
-                       True - out-of-sequence protected
-                              messages will be detected
-                       False - out-of-sequence messages will not
-                               be detected
-
-                     GSS_C_CONF_FLAG
-                       True - Confidentiality service may be invoked
-                              by calling gss_wrap routine
-                       False - No confidentiality service (via
-                               gss_wrap) available. gss_wrap will
-                               provide message encapsulation,
-                               data-origin authentication and
-                               integrity services only.
-
-                     GSS_C_INTEG_FLAG
-                       True - Integrity service may be invoked by
-                              calling either gss_get_mic or gss_wrap
-                              routines.
-
-
-
-Wray                        Standards Track                    [Page 65]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-                       False - Per-message integrity service
-                               unavailable.
-
-                     GSS_C_ANON_FLAG
-                       True - The initiator's identity will not
-                              be revealed to the acceptor.
-                              The src_name parameter (if
-                              requested) contains an anonymous
-                              internal name.
-                       False - The initiator has been
-                               authenticated normally.
-
-                     GSS_C_PROT_READY_FLAG
-                       True - Protection services (as specified
-                              by the states of the GSS_C_CONF_FLAG
-                              and GSS_C_INTEG_FLAG) are available
-                              for use.
-                       False - Protection services (as specified
-                               by the states of the GSS_C_CONF_FLAG
-                               and GSS_C_INTEG_FLAG) are available
-                               only if the context is fully
-                               established (i.e. if the open parameter
-                               is non-zero).
-
-                     GSS_C_TRANS_FLAG
-                       True - The resultant security context may
-                              be transferred to other processes via
-                              a call to gss_export_sec_context().
-                       False - The security context is not
-                               transferable.
-
-   locally_initiated Boolean, modify
-                     Non-zero if the invoking application is the
-                     context initiator.
-                     Specify NULL if not required.
-
-   open              Boolean, modify
-                     Non-zero if the context is fully established;
-                     Zero if a context-establishment token
-                     is expected from the peer application.
-                     Specify NULL if not required.
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_NO_CONTEXT  The referenced context could not be accessed.
-
-
-
-
-Wray                        Standards Track                    [Page 66]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-5.21. gss_inquire_cred
-
-   OM_uint32 gss_inquire_cred (
-     OM_uint32           *minor_status,
-     const gss_cred_id_t cred_handle,
-     gss_name_t          *name,
-     OM_uint32           *lifetime,
-     gss_cred_usage_t    *cred_usage,
-     gss_OID_set         *mechanisms )
-
-   Purpose:
-
-   Obtains information about a credential.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code
-
-   cred_handle       gss_cred_id_t, read
-                     A handle that refers to the target credential.
-                     Specify GSS_C_NO_CREDENTIAL to inquire about
-                     the default initiator principal.
-
-   name              gss_name_t, modify, optional
-                     The name whose identity the credential asserts.
-                     Storage associated with this name should be freed
-                     by the application after use with a call to
-                     gss_release_name().  Specify NULL if not required.
-
-   lifetime          Integer, modify, optional
-                     The number of seconds for which the credential
-                     will remain valid.  If the credential has
-                     expired, this parameter will be set to zero.
-                     If the implementation does not support
-                     credential expiration, the value
-                     GSS_C_INDEFINITE will be returned.  Specify
-                     NULL if not required.
-
-   cred_usage        gss_cred_usage_t, modify, optional
-                     How the credential may be used.  One of the
-                     following:
-                     GSS_C_INITIATE
-                     GSS_C_ACCEPT
-                     GSS_C_BOTH
-                     Specify NULL if not required.
-
-
-
-
-
-Wray                        Standards Track                    [Page 67]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   mechanisms        gss_OID_set, modify, optional
-                     Set of mechanisms supported by the credential.
-                     Storage associated with this OID set must be
-                     freed by the application after use with a call
-                     to gss_release_oid_set().  Specify NULL if not
-                     required.
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_NO_CRED     The referenced credentials could not be accessed.
-
-   GSS_S_DEFECTIVE_CREDENTIAL The referenced credentials were invalid.
-
-   GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired.
-                     If the lifetime parameter was not passed as NULL,
-                     it will be set to 0.
-
-5.22. gss_inquire_cred_by_mech
-
-   OM_uint32 gss_inquire_cred_by_mech (
-     OM_uint32           *minor_status,
-     const gss_cred_id_t cred_handle,
-     const gss_OID       mech_type,
-     gss_name_t          *name,
-     OM_uint32           *initiator_lifetime,
-     OM_uint32           *acceptor_lifetime,
-     gss_cred_usage_t    *cred_usage )
-
-   Purpose:
-
-   Obtains per-mechanism information about a credential.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code
-
-   cred_handle       gss_cred_id_t, read
-                     A handle that refers to the target credential.
-                     Specify GSS_C_NO_CREDENTIAL to inquire about
-                     the default initiator principal.
-
-   mech_type         gss_OID, read
-                     The mechanism for which information should be
-                     returned.
-
-
-
-
-Wray                        Standards Track                    [Page 68]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   name              gss_name_t, modify, optional
-                     The name whose identity the credential asserts.
-                     Storage associated with this name must be
-                     freed by the application after use with a call
-                     to gss_release_name().  Specify NULL if not
-                     required.
-
-   initiator_lifetime  Integer, modify, optional
-                     The number of seconds for which the credential
-                     will remain capable of initiating security contexts
-                     under the specified mechanism.  If the credential
-                     can no longer be used to initiate contexts, or if
-                     the credential usage for this mechanism is
-                     GSS_C_ACCEPT, this parameter will be set to zero.
-                     If the implementation does not support expiration
-                     of initiator credentials, the value
-                     GSS_C_INDEFINITE will be returned.  Specify NULL
-                     if not required.
-
-   acceptor_lifetime Integer, modify, optional
-                     The number of seconds for which the credential
-                     will remain capable of accepting security contexts
-                     under the specified mechanism.  If the credential
-                     can no longer be used to accept contexts, or if
-                     the credential usage for this mechanism is
-                     GSS_C_INITIATE, this parameter will be set to zero.
-
-                     If the implementation does not support expiration
-                     of acceptor credentials, the value GSS_C_INDEFINITE
-                     will be returned.  Specify NULL if not required.
-
-   cred_usage        gss_cred_usage_t, modify, optional
-                     How the credential may be used with the specified
-                     mechanism.  One of the following:
-                       GSS_C_INITIATE
-                       GSS_C_ACCEPT
-                       GSS_C_BOTH
-                     Specify NULL if not required.
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_NO_CRED     The referenced credentials could not be accessed.
-
-   GSS_S_DEFECTIVE_CREDENTIAL The referenced credentials were invalid.
-
-
-
-
-
-Wray                        Standards Track                    [Page 69]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   GSS_S_CREDENTIALS_EXPIRED The referenced credentials have expired.
-                    If the lifetime parameter was not passed as NULL,
-                    it will be set to 0.
-
-5.23. gss_inquire_mechs_for_name
-
-   OM_uint32 gss_inquire_mechs_for_name (
-     OM_uint32        *minor_status,
-     const gss_name_t input_name,
-     gss_OID_set      *mech_types )
-
-   Purpose:
-
-   Returns the set of mechanisms supported by the GSS-API implementation
-   that may be able to process the specified name.
-
-   Each mechanism returned will recognize at least one element within
-   the name.  It is permissible for this routine to be implemented
-   within a mechanism-independent GSS-API layer, using the type
-   information contained within the presented name, and based on
-   registration information provided by individual mechanism
-   implementations.  This means that the returned mech_types set may
-   indicate that a particular mechanism will understand the name when in
-   fact it would refuse to accept the name as input to
-   gss_canonicalize_name, gss_init_sec_context, gss_acquire_cred or
-   gss_add_cred (due to some property of the specific name, as opposed
-   to the name type).  Thus this routine should be used only as a pre-
-   filter for a call to a subsequent mechanism-specific routine.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Implementation specific status code.
-
-   input_name        gss_name_t, read
-                     The name to which the inquiry relates.
-
-   mech_types        gss_OID_set, modify
-                     Set of mechanisms that may support the
-                     specified name.  The returned OID set
-                     must be freed by the caller after use
-                     with a call to gss_release_oid_set().
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_BAD_NAME    The input_name parameter was ill-formed.
-
-
-
-Wray                        Standards Track                    [Page 70]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   GSS_S_BAD_NAMETYPE The input_name parameter contained an invalid or
-                      unsupported type of name
-
-5.24. gss_inquire_names_for_mech
-
-   OM_uint32 gss_inquire_names_for_mech (
-     OM_uint32     *minor_status,
-     const gss_OID mechanism,
-     gss_OID_set   *name_types)
-
-   Purpose:
-
-   Returns the set of nametypes supported by the specified mechanism.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Implementation specific status code.
-
-   mechanism         gss_OID, read
-                     The mechanism to be interrogated.
-
-   name_types        gss_OID_set, modify
-                     Set of name-types supported by the specified
-                     mechanism.  The returned OID set must be
-                     freed by the application after use with a
-                     call to gss_release_oid_set().
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-5.25. gss_process_context_token
-
-   OM_uint32 gss_process_context_token (
-     OM_uint32          *minor_status,
-     const gss_ctx_id_t context_handle,
-     const gss_buffer_t token_buffer)
-
-        Purpose:
-
-   Provides a way to pass an asynchronous token to the security service.
-   Most context-level tokens are emitted and processed synchronously by
-   gss_init_sec_context and gss_accept_sec_context, and the application
-   is informed as to whether further tokens are expected by the
-   GSS_C_CONTINUE_NEEDED major status bit.  Occasionally, a mechanism
-   may need to emit a context-level token at a point when the peer
-   entity is not expecting a token.  For example, the initiator's final
-
-
-
-Wray                        Standards Track                    [Page 71]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   call to gss_init_sec_context may emit a token and return a status of
-   GSS_S_COMPLETE, but the acceptor's call to gss_accept_sec_context may
-   fail.  The acceptor's mechanism may wish to send a token containing
-   an error indication to the initiator, but the initiator is not
-   expecting a token at this point, believing that the context is fully
-   established.  Gss_process_context_token provides a way to pass such a
-   token to the mechanism at any time.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Implementation specific status code.
-
-   context_handle    gss_ctx_id_t, read
-                     context handle of context on which token is to
-                     be processed
-
-   token_buffer      buffer, opaque, read
-                     token to process
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks performed
-                     on the token failed
-
-   GSS_S_NO_CONTEXT  The context_handle did not refer to a valid context
-
-5.26. gss_release_buffer
-
-   OM_uint32 gss_release_buffer (
-     OM_uint32    *minor_status,
-     gss_buffer_t buffer)
-
-   Purpose:
-
-   Free storage associated with a buffer.  The storage must have been
-   allocated by a GSS-API routine.  In addition to freeing the
-   associated storage, the routine will zero the length field in the
-   descriptor to which the buffer parameter refers, and implementations
-   are encouraged to additionally set the pointer field in the
-   descriptor to NULL.  Any buffer object returned by a GSS-API routine
-   may be passed to gss_release_buffer (even if there is no storage
-   associated with the buffer).
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 72]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code
-
-   buffer            buffer, modify
-                     The storage associated with the buffer will be
-                     deleted.  The gss_buffer_desc object will not
-                     be freed, but its length field will be zeroed.
-
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-5.27. gss_release_cred
-
-   OM_uint32 gss_release_cred (
-     OM_uint32     *minor_status,
-     gss_cred_id_t *cred_handle)
-
-   Purpose:
-
-   Informs GSS-API that the specified credential handle is no longer
-   required by the application, and frees associated resources.
-   Implementations are encouraged to set the cred_handle to
-   GSS_C_NO_CREDENTIAL on successful completion of this call.
-
-   Parameters:
-
-   cred_handle       gss_cred_id_t, modify, optional
-                     Opaque handle identifying credential
-                     to be released.  If GSS_C_NO_CREDENTIAL
-                     is supplied, the routine will complete
-                     successfully, but will do nothing.
-
-   minor_status      Integer, modify
-                     Mechanism specific status code.
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_NO_CRED     Credentials could not be accessed.
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 73]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-5.28. gss_release_name
-
-   OM_uint32 gss_release_name (
-     OM_uint32  *minor_status,
-     gss_name_t *name)
-
-   Purpose:
-
-   Free GSSAPI-allocated storage associated with an internal-form name.
-   Implementations are encouraged to set the name to GSS_C_NO_NAME on
-   successful completion of this call.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code
-
-   name              gss_name_t, modify
-                     The name to be deleted
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_BAD_NAME    The name parameter did not contain a valid name
-
-5.29. gss_release_oid_set
-
-   OM_uint32 gss_release_oid_set (
-     OM_uint32   *minor_status,
-     gss_OID_set *set)
-
-   Purpose:
-
-   Free storage associated with a GSSAPI-generated gss_OID_set object.
-   The set parameter must refer to an OID-set that was returned from a
-   GSS-API routine.  gss_release_oid_set() will free the storage
-   associated with each individual member OID, the OID set's elements
-   array, and the gss_OID_set_desc.
-
-   Implementations are encouraged to set the gss_OID_set parameter to
-   GSS_C_NO_OID_SET on successful completion of this routine.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code
-
-
-
-
-Wray                        Standards Track                    [Page 74]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   set               Set of Object IDs, modify
-                     The storage associated with the gss_OID_set
-                     will be deleted.
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-5.30. gss_test_oid_set_member
-
-   OM_uint32 gss_test_oid_set_member (
-     OM_uint32         *minor_status,
-     const gss_OID     member,
-     const gss_OID_set set,
-     int               *present)
-
-   Purpose:
-
-   Interrogate an Object Identifier set to determine whether a specified
-   Object Identifier is a member.  This routine is intended to be used
-   with OID sets returned by gss_indicate_mechs(), gss_acquire_cred(),
-   and gss_inquire_cred(), but will also work with user-generated sets.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code
-
-   member            Object ID, read
-                     The object identifier whose presence
-                     is to be tested.
-
-   set               Set of Object ID, read
-                     The Object Identifier set.
-
-   present           Boolean, modify
-                     non-zero if the specified OID is a member
-                     of the set, zero if not.
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 75]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-5.31. gss_unwrap
-
-   OM_uint32 gss_unwrap (
-     OM_uint32          *minor_status,
-     const gss_ctx_id_t context_handle,
-     const gss_buffer_t input_message_buffer,
-     gss_buffer_t       output_message_buffer,
-     int                *conf_state,
-     gss_qop_t          *qop_state)
-
-   Purpose:
-
-   Converts a message previously protected by gss_wrap back to a usable
-   form, verifying the embedded MIC.  The conf_state parameter indicates
-   whether the message was encrypted; the qop_state parameter indicates
-   the strength of protection that was used to provide the
-   confidentiality and integrity services.
-
-   Since some application-level protocols may wish to use tokens emitted
-   by gss_wrap() to provide "secure framing", implementations must
-   support the wrapping and unwrapping of zero-length messages.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code.
-
-   context_handle    gss_ctx_id_t, read
-                     Identifies the context on which the message
-                     arrived
-
-   input_message_buffer  buffer, opaque, read
-                     protected message
-
-   output_message_buffer  buffer, opaque, modify
-                     Buffer to receive unwrapped message.
-                     Storage associated with this buffer must
-                     be freed by the application after use use
-                     with a call to gss_release_buffer().
-
-   conf_state        boolean, modify, optional
-                     Non-zero - Confidentiality and integrity
-                                protection were used
-                     Zero - Integrity service only was used
-                     Specify NULL if not required
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 76]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   qop_state         gss_qop_t, modify, optional
-                     Quality of protection provided.
-                     Specify NULL if not required
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_DEFECTIVE_TOKEN The token failed consistency checks
-
-   GSS_S_BAD_SIG     The MIC was incorrect
-
-   GSS_S_DUPLICATE_TOKEN The token was valid, and contained a correct
-                         MIC for the message, but it had already been
-                         processed
-
-   GSS_S_OLD_TOKEN   The token was valid, and contained a correct MIC
-                     for the message, but it is too old to check for
-                     duplication.
-
-   GSS_S_UNSEQ_TOKEN The token was valid, and contained a correct MIC
-                     for the message, but has been verified out of
-                     sequence; a later token has already been
-                     received.
-
-   GSS_S_GAP_TOKEN   The token was valid, and contained a correct MIC
-                     for the message, but has been verified out of
-                     sequence; an earlier expected token has not yet
-                     been received.
-
-   GSS_S_CONTEXT_EXPIRED The context has already expired
-
-   GSS_S_NO_CONTEXT  The context_handle parameter did not identify
-                     a valid context
-
-5.32. gss_verify_mic
-
-   OM_uint32 gss_verify_mic (
-     OM_uint32          *minor_status,
-     const gss_ctx_id_t context_handle,
-     const gss_buffer_t message_buffer,
-     const gss_buffer_t token_buffer,
-     gss_qop_t          *qop_state)
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 77]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Purpose:
-
-   Verifies that a cryptographic MIC, contained in the token parameter,
-   fits the supplied message.  The qop_state parameter allows a message
-   recipient to determine the strength of protection that was applied to
-   the message.
-
-   Since some application-level protocols may wish to use tokens emitted
-   by gss_wrap() to provide "secure framing", implementations must
-   support the calculation and verification of MICs over zero-length
-   messages.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code.
-
-   context_handle    gss_ctx_id_t, read
-                     Identifies the context on which the message
-                     arrived
-
-   message_buffer    buffer, opaque, read
-                     Message to be verified
-
-   token_buffer      buffer, opaque, read
-                     Token associated with message
-
-   qop_state         gss_qop_t, modify, optional
-                     quality of protection gained from MIC
-                     Specify NULL if not required
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_DEFECTIVE_TOKEN The token failed consistency checks
-
-   GSS_S_BAD_SIG     The MIC was incorrect
-
-   GSS_S_DUPLICATE_TOKEN The token was valid, and contained a correct
-                     MIC for the message, but it had already been
-                     processed
-
-   GSS_S_OLD_TOKEN   The token was valid, and contained a correct MIC
-                     for the message, but it is too old to check for
-                     duplication.
-
-
-
-
-
-Wray                        Standards Track                    [Page 78]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   GSS_S_UNSEQ_TOKEN The token was valid, and contained a correct MIC
-                     for the message, but has been verified out of
-                     sequence; a later token has already been received.
-
-   GSS_S_GAP_TOKEN   The token was valid, and contained a correct MIC
-                     for the message, but has been verified out of
-                     sequence; an earlier expected token has not yet
-                     been received.
-
-   GSS_S_CONTEXT_EXPIRED The context has already expired
-
-   GSS_S_NO_CONTEXT  The context_handle parameter did not identify a
-                     valid context
-
-5.33. gss_wrap
-
-   OM_uint32 gss_wrap (
-     OM_uint32          *minor_status,
-     const gss_ctx_id_t context_handle,
-     int               conf_req_flag,
-     gss_qop_t          qop_req
-     const gss_buffer_t input_message_buffer,
-     int                *conf_state,
-     gss_buffer_t       output_message_buffer )
-
-   Purpose:
-
-   Attaches a cryptographic MIC and optionally encrypts the specified
-   input_message.  The output_message contains both the MIC and the
-   message.  The qop_req parameter allows a choice between several
-   cryptographic algorithms, if supported by the chosen mechanism.
-
-   Since some application-level protocols may wish to use tokens emitted
-   by gss_wrap() to provide "secure framing", implementations must
-   support the wrapping of zero-length messages.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code.
-
-   context_handle    gss_ctx_id_t, read
-                     Identifies the context on which the message
-                     will be sent
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 79]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   conf_req_flag     boolean, read
-                     Non-zero - Both confidentiality and integrity
-                                services are requested
-                     Zero - Only integrity service is requested
-
-   qop_req           gss_qop_t, read, optional
-                     Specifies required quality of protection.  A
-                     mechanism-specific default may be requested by
-                     setting qop_req to GSS_C_QOP_DEFAULT.  If an
-                     unsupported protection strength is requested,
-                     gss_wrap will return a major_status of
-                     GSS_S_BAD_QOP.
-
-   input_message_buffer  buffer, opaque, read
-                     Message to be protected
-
-   conf_state        boolean, modify, optional
-                     Non-zero - Confidentiality, data origin
-                                authentication and integrity
-                                services have been applied
-                     Zero - Integrity and data origin services only
-                            has been applied.
-                     Specify NULL if not required
-
-   output_message_buffer  buffer, opaque, modify
-                     Buffer to receive protected message.
-                     Storage associated with this message must
-                     be freed by the application after use with
-                     a call to gss_release_buffer().
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_CONTEXT_EXPIRED The context has already expired
-
-   GSS_S_NO_CONTEXT  The context_handle parameter did not identify a
-                     valid context
-
-   GSS_S_BAD_QOP     The specified QOP is not supported by the
-                     mechanism.
-
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 80]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-5.34. gss_wrap_size_limit
-
-   OM_uint32 gss_wrap_size_limit (
-     OM_uint32          *minor_status,
-     const gss_ctx_id_t context_handle,
-     int                conf_req_flag,
-     gss_qop_t          qop_req,
-     OM_uint32          req_output_size,
-     OM_uint32          *max_input_size)
-
-   Purpose:
-
-   Allows an application to determine the maximum message size that, if
-   presented to gss_wrap with the same conf_req_flag and qop_req
-   parameters, will result in an output token containing no more than
-   req_output_size bytes.
-
-   This call is intended for use by applications that communicate over
-   protocols that impose a maximum message size.  It enables the
-   application to fragment messages prior to applying protection.
-
-   GSS-API implementations are recommended but not required to detect
-   invalid QOP values when gss_wrap_size_limit() is called. This routine
-   guarantees only a maximum message size, not the availability of
-   specific QOP values for message protection.
-
-   Successful completion of this call does not guarantee that gss_wrap
-   will be able to protect a message of length max_input_size bytes,
-   since this ability may depend on the availability of system resources
-   at the time that gss_wrap is called.  However, if the implementation
-   itself imposes an upper limit on the length of messages that may be
-   processed by gss_wrap, the implementation should not return a value
-   via max_input_bytes that is greater than this length.
-
-   Parameters:
-
-   minor_status      Integer, modify
-                     Mechanism specific status code
-
-   context_handle    gss_ctx_id_t, read
-                     A handle that refers to the security over
-                     which the messages will be sent.
-
-   conf_req_flag     Boolean, read
-                     Indicates whether gss_wrap will be asked
-                     to apply confidentiality protection in
-
-
-
-
-
-Wray                        Standards Track                    [Page 81]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-                     addition to integrity protection.  See
-                     the routine description for gss_wrap
-                     for more details.
-
-   qop_req           gss_qop_t, read
-                     Indicates the level of protection that
-                     gss_wrap will be asked to provide.  See
-                     the routine description for gss_wrap for
-                     more details.
-
-   req_output_size   Integer, read
-                     The desired maximum size for tokens emitted
-                     by gss_wrap.
-
-   max_input_size    Integer, modify
-                     The maximum input message size that may
-                     be presented to gss_wrap in order to
-                     guarantee that the emitted token shall
-                     be no larger than req_output_size bytes.
-
-   Function value:   GSS status code
-
-   GSS_S_COMPLETE    Successful completion
-
-   GSS_S_NO_CONTEXT  The referenced context could not be accessed.
-
-   GSS_S_CONTEXT_EXPIRED The context has expired.
-
-   GSS_S_BAD_QOP     The specified QOP is not supported by the
-                     mechanism.
-
-6.   Security Considerations
-
-   This document specifies a service interface for security facilities
-   and services; as such, security considerations appear throughout the
-   specification. Nonetheless, it is appropriate to summarize certain
-   specific points relevant to GSS-API implementors and calling
-   applications. Usage of the GSS-API interface does not in itself
-   provide security services or assurance; instead, these attributes are
-   dependent on the underlying mechanism(s) which support a GSS-API
-   implementation. Callers must be attentive to the requests made to
-   GSS-API calls and to the status indicators returned by GSS-API, as
-   these specify the security service characteristics which GSS-API will
-   provide. When the interprocess context transfer facility is used,
-   appropriate local controls should be applied to constrain access to
-   interprocess tokens and to the sensitive data which they contain.
-
-
-
-
-
-Wray                        Standards Track                    [Page 82]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   Appendix A. GSS-API C header file gssapi.h
-
-   C-language GSS-API implementations should include a copy of the
-   following header-file.
-
-   #ifndef GSSAPI_H_
-   #define GSSAPI_H_
-
-
-
-   /*
-    * First, include stddef.h to get size_t defined.
-    */
-   #include <stddef.h>
-
-   /*
-    * If the platform supports the xom.h header file, it should be
-    * included here.
-    */
-   #include <xom.h>
-
-
-   /*
-    * Now define the three implementation-dependent types.
-    */
-   typedef <platform-specific> gss_ctx_id_t;
-   typedef <platform-specific> gss_cred_id_t;
-   typedef <platform-specific> gss_name_t;
-
-   /*
-    * The following type must be defined as the smallest natural
-    * unsigned integer supported by the platform that has at least
-    * 32 bits of precision.
-    */
-   typedef <platform-specific> gss_uint32;
-
-
-   #ifdef OM_STRING
-   /*
-    * We have included the xom.h header file.  Verify that OM_uint32
-    * is defined correctly.
-    */
-
-   #if sizeof(gss_uint32) != sizeof(OM_uint32)
-   #error Incompatible definition of OM_uint32 from xom.h
-   #endif
-
-   typedef OM_object_identifier gss_OID_desc, *gss_OID;
-
-
-
-Wray                        Standards Track                    [Page 83]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   #else
-
-   /*
-    * We can't use X/Open definitions, so roll our own.
-    */
-
-   typedef gss_uint32 OM_uint32;
-
-   typedef struct gss_OID_desc_struct {
-     OM_uint32 length;
-     void      *elements;
-   } gss_OID_desc, *gss_OID;
-
-   #endif
-
-   typedef struct gss_OID_set_desc_struct  {
-     size_t     count;
-     gss_OID    elements;
-   } gss_OID_set_desc, *gss_OID_set;
-
-   typedef struct gss_buffer_desc_struct {
-     size_t length;
-     void *value;
-   } gss_buffer_desc, *gss_buffer_t;
-
-   typedef struct gss_channel_bindings_struct {
-     OM_uint32 initiator_addrtype;
-     gss_buffer_desc initiator_address;
-     OM_uint32 acceptor_addrtype;
-     gss_buffer_desc acceptor_address;
-     gss_buffer_desc application_data;
-   } *gss_channel_bindings_t;
-
-   /*
-    * For now, define a QOP-type as an OM_uint32
-    */
-   typedef OM_uint32 gss_qop_t;
-
-   typedef int gss_cred_usage_t;
-
-   /*
-    * Flag bits for context-level services.
-    */
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 84]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   #define GSS_C_DELEG_FLAG      1
-   #define GSS_C_MUTUAL_FLAG     2
-   #define GSS_C_REPLAY_FLAG     4
-   #define GSS_C_SEQUENCE_FLAG   8
-   #define GSS_C_CONF_FLAG       16
-   #define GSS_C_INTEG_FLAG      32
-   #define GSS_C_ANON_FLAG       64
-   #define GSS_C_PROT_READY_FLAG 128
-   #define GSS_C_TRANS_FLAG      256
-
-   /*
-    * Credential usage options
-    */
-   #define GSS_C_BOTH     0
-   #define GSS_C_INITIATE 1
-   #define GSS_C_ACCEPT   2
-
-   /*
-    * Status code types for gss_display_status
-    */
-   #define GSS_C_GSS_CODE  1
-   #define GSS_C_MECH_CODE 2
-
-   /*
-    * The constant definitions for channel-bindings address families
-    */
-   #define GSS_C_AF_UNSPEC     0
-   #define GSS_C_AF_LOCAL      1
-   #define GSS_C_AF_INET       2
-   #define GSS_C_AF_IMPLINK    3
-   #define GSS_C_AF_PUP        4
-   #define GSS_C_AF_CHAOS      5
-   #define GSS_C_AF_NS         6
-   #define GSS_C_AF_NBS        7
-   #define GSS_C_AF_ECMA       8
-   #define GSS_C_AF_DATAKIT    9
-   #define GSS_C_AF_CCITT      10
-   #define GSS_C_AF_SNA        11
-   #define GSS_C_AF_DECnet     12
-   #define GSS_C_AF_DLI        13
-   #define GSS_C_AF_LAT        14
-   #define GSS_C_AF_HYLINK     15
-   #define GSS_C_AF_APPLETALK  16
-   #define GSS_C_AF_BSC        17
-   #define GSS_C_AF_DSS        18
-   #define GSS_C_AF_OSI        19
-   #define GSS_C_AF_X25        21
-
-
-
-
-Wray                        Standards Track                    [Page 85]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   #define GSS_C_AF_NULLADDR   255
-
-   /*
-    * Various Null values
-    */
-   #define GSS_C_NO_NAME ((gss_name_t) 0)
-   #define GSS_C_NO_BUFFER ((gss_buffer_t) 0)
-   #define GSS_C_NO_OID ((gss_OID) 0)
-   #define GSS_C_NO_OID_SET ((gss_OID_set) 0)
-   #define GSS_C_NO_CONTEXT ((gss_ctx_id_t) 0)
-   #define GSS_C_NO_CREDENTIAL ((gss_cred_id_t) 0)
-   #define GSS_C_NO_CHANNEL_BINDINGS ((gss_channel_bindings_t) 0)
-   #define GSS_C_EMPTY_BUFFER {0, NULL}
-
-   /*
-    * Some alternate names for a couple of the above
-    * values.  These are defined for V1 compatibility.
-    */
-   #define GSS_C_NULL_OID GSS_C_NO_OID
-   #define GSS_C_NULL_OID_SET GSS_C_NO_OID_SET
-
-   /*
-    * Define the default Quality of Protection for per-message
-    * services.  Note that an implementation that offers multiple
-    * levels of QOP may define GSS_C_QOP_DEFAULT to be either zero
-    * (as done here) to mean "default protection", or to a specific
-    * explicit QOP value.  However, a value of 0 should always be
-    * interpreted by a GSS-API implementation as a request for the
-    * default protection level.
-    */
-   #define GSS_C_QOP_DEFAULT 0
-
-   /*
-    * Expiration time of 2^32-1 seconds means infinite lifetime for a
-    * credential or security context
-    */
-   #define GSS_C_INDEFINITE 0xfffffffful
-
-   /*
-    * The implementation must reserve static storage for a
-    * gss_OID_desc object containing the value
-    * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
-    * "\x01\x02\x01\x01"},
-    * corresponding to an object-identifier value of
-    * {iso(1) member-body(2) United States(840) mit(113554)
-    * infosys(1) gssapi(2) generic(1) user_name(1)}.  The constant
-    * GSS_C_NT_USER_NAME should be initialized to point
-    * to that gss_OID_desc.
-
-
-
-Wray                        Standards Track                    [Page 86]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-    */
-   extern gss_OID GSS_C_NT_USER_NAME;
-
-   /*
-    * The implementation must reserve static storage for a
-    * gss_OID_desc object containing the value
-    * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
-    *              "\x01\x02\x01\x02"},
-    * corresponding to an object-identifier value of
-    * {iso(1) member-body(2) United States(840) mit(113554)
-    * infosys(1) gssapi(2) generic(1) machine_uid_name(2)}.
-    * The constant GSS_C_NT_MACHINE_UID_NAME should be
-    * initialized to point to that gss_OID_desc.
-    */
-   extern gss_OID GSS_C_NT_MACHINE_UID_NAME;
-
-   /*
-    * The implementation must reserve static storage for a
-    * gss_OID_desc object containing the value
-    * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
-    *              "\x01\x02\x01\x03"},
-    * corresponding to an object-identifier value of
-    * {iso(1) member-body(2) United States(840) mit(113554)
-    * infosys(1) gssapi(2) generic(1) string_uid_name(3)}.
-    * The constant GSS_C_NT_STRING_UID_NAME should be
-    * initialized to point to that gss_OID_desc.
-    */
-   extern gss_OID GSS_C_NT_STRING_UID_NAME;
-
-   /*
-    * The implementation must reserve static storage for a
-    * gss_OID_desc object containing the value
-    * {6, (void *)"\x2b\x06\x01\x05\x06\x02"},
-    * corresponding to an object-identifier value of
-    * {iso(1) org(3) dod(6) internet(1) security(5)
-    * nametypes(6) gss-host-based-services(2)).  The constant
-    * GSS_C_NT_HOSTBASED_SERVICE_X should be initialized to point
-    * to that gss_OID_desc.  This is a deprecated OID value, and
-    * implementations wishing to support hostbased-service names
-    * should instead use the GSS_C_NT_HOSTBASED_SERVICE OID,
-    * defined below, to identify such names;
-    * GSS_C_NT_HOSTBASED_SERVICE_X should be accepted a synonym
-    * for GSS_C_NT_HOSTBASED_SERVICE when presented as an input
-    * parameter, but should not be emitted by GSS-API
-    * implementations
-    */
-   extern gss_OID GSS_C_NT_HOSTBASED_SERVICE_X;
-
-
-
-
-Wray                        Standards Track                    [Page 87]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   /*
-    * The implementation must reserve static storage for a
-    * gss_OID_desc object containing the value
-    * {10, (void *)"\x2a\x86\x48\x86\xf7\x12"
-    *              "\x01\x02\x01\x04"}, corresponding to an
-    * object-identifier value of {iso(1) member-body(2)
-    * Unites States(840) mit(113554) infosys(1) gssapi(2)
-    * generic(1) service_name(4)}.  The constant
-    * GSS_C_NT_HOSTBASED_SERVICE should be initialized
-    * to point to that gss_OID_desc.
-    */
-   extern gss_OID GSS_C_NT_HOSTBASED_SERVICE;
-
-   /*
-    * The implementation must reserve static storage for a
-    * gss_OID_desc object containing the value
-    * {6, (void *)"\x2b\x06\01\x05\x06\x03"},
-    * corresponding to an object identifier value of
-    * {1(iso), 3(org), 6(dod), 1(internet), 5(security),
-    * 6(nametypes), 3(gss-anonymous-name)}.  The constant
-    * and GSS_C_NT_ANONYMOUS should be initialized to point
-    * to that gss_OID_desc.
-    */
-   extern gss_OID GSS_C_NT_ANONYMOUS;
-
-
-   /*
-    * The implementation must reserve static storage for a
-    * gss_OID_desc object containing the value
-    * {6, (void *)"\x2b\x06\x01\x05\x06\x04"},
-    * corresponding to an object-identifier value of
-    * {1(iso), 3(org), 6(dod), 1(internet), 5(security),
-    * 6(nametypes), 4(gss-api-exported-name)}.  The constant
-    * GSS_C_NT_EXPORT_NAME should be initialized to point
-    * to that gss_OID_desc.
-    */
-   extern gss_OID GSS_C_NT_EXPORT_NAME;
-
-
-   /* Major status codes */
-
-   #define GSS_S_COMPLETE 0
-
-   /*
-    * Some "helper" definitions to make the status code macros obvious.
-    */
-   #define GSS_C_CALLING_ERROR_OFFSET 24
-   #define GSS_C_ROUTINE_ERROR_OFFSET 16
-
-
-
-Wray                        Standards Track                    [Page 88]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   #define GSS_C_SUPPLEMENTARY_OFFSET 0
-   #define GSS_C_CALLING_ERROR_MASK 0377ul
-   #define GSS_C_ROUTINE_ERROR_MASK 0377ul
-   #define GSS_C_SUPPLEMENTARY_MASK 0177777ul
-
-   /*
-    * The macros that test status codes for error conditions.
-    * Note that the GSS_ERROR() macro has changed slightly from
-    * the V1 GSS-API so that it now evaluates its argument
-    * only once.
-    */
-   #define GSS_CALLING_ERROR(x) \
-    (x & (GSS_C_CALLING_ERROR_MASK << GSS_C_CALLING_ERROR_OFFSET))
-   #define GSS_ROUTINE_ERROR(x) \
-    (x & (GSS_C_ROUTINE_ERROR_MASK << GSS_C_ROUTINE_ERROR_OFFSET))
-   #define GSS_SUPPLEMENTARY_INFO(x) \
-    (x & (GSS_C_SUPPLEMENTARY_MASK << GSS_C_SUPPLEMENTARY_OFFSET))
-   #define GSS_ERROR(x) \
-    (x & ((GSS_C_CALLING_ERROR_MASK << GSS_C_CALLING_ERROR_OFFSET) | \
-          (GSS_C_ROUTINE_ERROR_MASK << GSS_C_ROUTINE_ERROR_OFFSET)))
-
-   /*
-    * Now the actual status code definitions
-    */
-
-   /*
-    * Calling errors:
-
-    */
-   #define GSS_S_CALL_INACCESSIBLE_READ \
-   (1ul << GSS_C_CALLING_ERROR_OFFSET)
-   #define GSS_S_CALL_INACCESSIBLE_WRITE \
-   (2ul << GSS_C_CALLING_ERROR_OFFSET)
-   #define GSS_S_CALL_BAD_STRUCTURE \
-   (3ul << GSS_C_CALLING_ERROR_OFFSET)
-
-   /*
-    * Routine errors:
-    */
-   #define GSS_S_BAD_MECH             (1ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_BAD_NAME             (2ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_BAD_NAMETYPE         (3ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_BAD_BINDINGS         (4ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_BAD_STATUS           (5ul <<
-
-
-
-Wray                        Standards Track                    [Page 89]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_BAD_SIG              (6ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_BAD_MIC GSS_S_BAD_SIG
-   #define GSS_S_NO_CRED              (7ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_NO_CONTEXT           (8ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_DEFECTIVE_TOKEN      (9ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_DEFECTIVE_CREDENTIAL (10ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_CREDENTIALS_EXPIRED  (11ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_CONTEXT_EXPIRED      (12ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_FAILURE              (13ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_BAD_QOP              (14ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_UNAUTHORIZED         (15ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_UNAVAILABLE          (16ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_DUPLICATE_ELEMENT    (17ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-   #define GSS_S_NAME_NOT_MN          (18ul <<
-   GSS_C_ROUTINE_ERROR_OFFSET)
-
-   /*
-    * Supplementary info bits:
-    */
-   #define GSS_S_CONTINUE_NEEDED \
-            (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 0))
-   #define GSS_S_DUPLICATE_TOKEN \
-            (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 1))
-   #define GSS_S_OLD_TOKEN \
-            (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 2))
-   #define GSS_S_UNSEQ_TOKEN \
-            (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 3))
-   #define GSS_S_GAP_TOKEN \
-            (1ul << (GSS_C_SUPPLEMENTARY_OFFSET + 4))
-
-   /*
-    * Finally, function prototypes for the GSS-API routines.
-    */
-
-
-
-
-
-Wray                        Standards Track                    [Page 90]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   OM_uint32 gss_acquire_cred
-                 (OM_uint32 ,             /*  minor_status */
-                  const gss_name_t,       /* desired_name */
-                  OM_uint32,              /* time_req */
-                  const gss_OID_set,      /* desired_mechs */
-                  gss_cred_usage_t,       /* cred_usage */
-                  gss_cred_id_t ,         /* output_cred_handle */
-                  gss_OID_set ,           /* actual_mechs */
-                  OM_uint32 *             /* time_rec */
-                 );
-
-   OM_uint32 gss_release_cred
-                 (OM_uint32 ,             /* minor_status */
-                  gss_cred_id_t *         /* cred_handle */
-                 );
-
-   OM_uint32 gss_init_sec_context
-                 (OM_uint32 ,             /* minor_status */
-                  const gss_cred_id_t,    /* initiator_cred_handle */
-                  gss_ctx_id_t ,          /* context_handle */
-                  const gss_name_t,       /* target_name */
-                  const gss_OID,          /* mech_type */
-                  OM_uint32,              /* req_flags */
-                  OM_uint32,              /* time_req */
-                  const gss_channel_bindings_t,
-                                          /* input_chan_bindings */
-                  const gss_buffer_t,     /* input_token */
-                  gss_OID ,               /* actual_mech_type */
-                  gss_buffer_t,           /* output_token */
-                  OM_uint32 ,             /* ret_flags */
-                  OM_uint32 *             /* time_rec */
-                 );
-
-   OM_uint32 gss_accept_sec_context
-                 (OM_uint32 ,             /* minor_status */
-                  gss_ctx_id_t ,          /* context_handle */
-                  const gss_cred_id_t,    /* acceptor_cred_handle */
-                  const gss_buffer_t,     /* input_token_buffer */
-                  const gss_channel_bindings_t,
-                                          /* input_chan_bindings */
-                  gss_name_t ,            /* src_name */
-                  gss_OID ,               /* mech_type */
-                  gss_buffer_t,           /* output_token */
-                  OM_uint32 ,             /* ret_flags */
-                  OM_uint32 ,             /* time_rec */
-                  gss_cred_id_t *         /* delegated_cred_handle */
-                 );
-
-
-
-
-Wray                        Standards Track                    [Page 91]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   OM_uint32 gss_process_context_token
-                 (OM_uint32 ,             /* minor_status */
-                  const gss_ctx_id_t,     /* context_handle */
-                  const gss_buffer_t      /* token_buffer */
-                 );
-
-   OM_uint32 gss_delete_sec_context
-                 (OM_uint32 ,             /* minor_status */
-                  gss_ctx_id_t ,          /* context_handle */
-                  gss_buffer_t            /* output_token */
-                 );
-
-   OM_uint32 gss_context_time
-                 (OM_uint32 ,             /* minor_status */
-                  const gss_ctx_id_t,     /* context_handle */
-                  OM_uint32 *             /* time_rec */
-                 );
-
-   OM_uint32 gss_get_mic
-                 (OM_uint32 ,             /* minor_status */
-                  const gss_ctx_id_t,     /* context_handle */
-                  gss_qop_t,              /* qop_req */
-                  const gss_buffer_t,     /* message_buffer */
-                  gss_buffer_t            /* message_token */
-                 );
-
-   OM_uint32 gss_verify_mic
-                 (OM_uint32 ,             /* minor_status */
-                  const gss_ctx_id_t,     /* context_handle */
-                  const gss_buffer_t,     /* message_buffer */
-                  const gss_buffer_t,     /* token_buffer */
-                  gss_qop_t *             /* qop_state */
-                 );
-
-   OM_uint32 gss_wrap
-                 (OM_uint32 ,             /* minor_status */
-                  const gss_ctx_id_t,     /* context_handle */
-                  int,                    /* conf_req_flag */
-                  gss_qop_t,              /* qop_req */
-                  const gss_buffer_t,     /* input_message_buffer */
-                  int ,                   /* conf_state */
-                  gss_buffer_t            /* output_message_buffer */
-                 );
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 92]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   OM_uint32 gss_unwrap
-                 (OM_uint32 ,             /* minor_status */
-                  const gss_ctx_id_t,     /* context_handle */
-                  const gss_buffer_t,     /* input_message_buffer */
-                  gss_buffer_t,           /* output_message_buffer */
-                  int ,                   /* conf_state */
-                  gss_qop_t *             /* qop_state */
-                 );
-
-
-
-   OM_uint32 gss_display_status
-                 (OM_uint32 ,             /* minor_status */
-                  OM_uint32,              /* status_value */
-                  int,                    /* status_type */
-                  const gss_OID,          /* mech_type */
-                  OM_uint32 ,             /* message_context */
-                  gss_buffer_t            /* status_string */
-                 );
-
-   OM_uint32 gss_indicate_mechs
-                 (OM_uint32 ,             /* minor_status */
-                  gss_OID_set *           /* mech_set */
-                 );
-
-   OM_uint32 gss_compare_name
-                 (OM_uint32 ,             /* minor_status */
-                  const gss_name_t,       /* name1 */
-                  const gss_name_t,       /* name2 */
-                  int *                   /* name_equal */
-                 );
-
-   OM_uint32 gss_display_name
-                 (OM_uint32 ,             /* minor_status */
-                  const gss_name_t,       /* input_name */
-                  gss_buffer_t,           /* output_name_buffer */
-                  gss_OID *               /* output_name_type */
-                 );
-
-   OM_uint32 gss_import_name
-                 (OM_uint32 ,             /* minor_status */
-                  const gss_buffer_t,     /* input_name_buffer */
-                  const gss_OID,          /* input_name_type */
-                  gss_name_t *            /* output_name */
-                 );
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 93]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   OM_uint32 gss_export_name
-                 (OM_uint32,              /* minor_status */
-                  const gss_name_t,       /* input_name */
-                  gss_buffer_t            /* exported_name */
-                 );
-
-   OM_uint32 gss_release_name
-                 (OM_uint32 *,            /* minor_status */
-                  gss_name_t *            /* input_name */
-                 );
-
-   OM_uint32 gss_release_buffer
-                 (OM_uint32 ,             /* minor_status */
-                  gss_buffer_t            /* buffer */
-                 );
-
-   OM_uint32 gss_release_oid_set
-                 (OM_uint32 ,             /* minor_status */
-                  gss_OID_set *           /* set */
-                 );
-
-   OM_uint32 gss_inquire_cred
-                 (OM_uint32 ,             /* minor_status */
-                  const gss_cred_id_t,    /* cred_handle */
-                  gss_name_t ,            /* name */
-                  OM_uint32 ,             /* lifetime */
-                  gss_cred_usage_t ,      /* cred_usage */
-                  gss_OID_set *           /* mechanisms */
-                 );
-
-   OM_uint32 gss_inquire_context (
-                  OM_uint32 ,             /* minor_status */
-                  const gss_ctx_id_t,     /* context_handle */
-                  gss_name_t ,            /* src_name */
-                  gss_name_t ,            /* targ_name */
-                  OM_uint32 ,             /* lifetime_rec */
-                  gss_OID ,               /* mech_type */
-                  OM_uint32 ,             /* ctx_flags */
-                  int ,                   /* locally_initiated */
-                  int *                   /* open */
-                 );
-
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 94]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   OM_uint32 gss_wrap_size_limit (
-                  OM_uint32 ,             /* minor_status */
-                  const gss_ctx_id_t,     /* context_handle */
-                  int,                    /* conf_req_flag */
-                  gss_qop_t,              /* qop_req */
-                  OM_uint32,              /* req_output_size */
-                  OM_uint32 *             /* max_input_size */
-                 );
-
-   OM_uint32 gss_add_cred (
-                  OM_uint32 ,             /* minor_status */
-                  const gss_cred_id_t,    /* input_cred_handle */
-                  const gss_name_t,       /* desired_name */
-                  const gss_OID,          /* desired_mech */
-                  gss_cred_usage_t,       /* cred_usage */
-                  OM_uint32,              /* initiator_time_req */
-                  OM_uint32,              /* acceptor_time_req */
-                  gss_cred_id_t ,         /* output_cred_handle */
-                  gss_OID_set ,           /* actual_mechs */
-                  OM_uint32 ,             /* initiator_time_rec */
-                  OM_uint32 *             /* acceptor_time_rec */
-                 );
-
-   OM_uint32 gss_inquire_cred_by_mech (
-                  OM_uint32 ,             /* minor_status */
-                  const gss_cred_id_t,    /* cred_handle */
-                  const gss_OID,          /* mech_type */
-                  gss_name_t ,            /* name */
-                  OM_uint32 ,             /* initiator_lifetime */
-                  OM_uint32 ,             /* acceptor_lifetime */
-                  gss_cred_usage_t *      /* cred_usage */
-                 );
-
-   OM_uint32 gss_export_sec_context (
-                  OM_uint32 ,             /* minor_status */
-                  gss_ctx_id_t ,          /* context_handle */
-                  gss_buffer_t            /* interprocess_token */
-                 );
-
-   OM_uint32 gss_import_sec_context (
-                  OM_uint32 ,             /* minor_status */
-                  const gss_buffer_t,     /* interprocess_token */
-                  gss_ctx_id_t *          /* context_handle */
-                 );
-
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 95]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   OM_uint32 gss_create_empty_oid_set (
-                  OM_uint32 ,             /* minor_status */
-                  gss_OID_set *           /* oid_set */
-                 );
-
-   OM_uint32 gss_add_oid_set_member (
-                  OM_uint32 ,             /* minor_status */
-                  const gss_OID,          /* member_oid */
-                  gss_OID_set *           /* oid_set */
-                 );
-
-   OM_uint32 gss_test_oid_set_member (
-                  OM_uint32 ,             /* minor_status */
-                  const gss_OID,          /* member */
-                  const gss_OID_set,      /* set */
-                  int *                   /* present */
-                 );
-
-   OM_uint32 gss_inquire_names_for_mech (
-                  OM_uint32 ,             /* minor_status */
-                  const gss_OID,          /* mechanism */
-                  gss_OID_set *           /* name_types */
-                 );
-
-   OM_uint32 gss_inquire_mechs_for_name (
-                  OM_uint32 ,             /* minor_status */
-                  const gss_name_t,       /* input_name */
-                  gss_OID_set *           /* mech_types */
-                 );
-
-   OM_uint32 gss_canonicalize_name (
-                  OM_uint32 ,             /* minor_status */
-                  const gss_name_t,       /* input_name */
-                  const gss_OID,          /* mech_type */
-                  gss_name_t *            /* output_name */
-                 );
-
-   OM_uint32 gss_duplicate_name (
-                  OM_uint32 ,             /* minor_status */
-                  const gss_name_t,       /* src_name */
-                  gss_name_t *            /* dest_name */
-                 );
-
-   /*
-    * The following routines are obsolete variants of gss_get_mic,
-    * gss_verify_mic, gss_wrap and gss_unwrap.  They should be
-    * provided by GSS-API V2 implementations for backwards
-    * compatibility with V1 applications.  Distinct entrypoints
-
-
-
-Wray                        Standards Track                    [Page 96]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-    * (as opposed to #defines) should be provided, both to allow
-    * GSS-API V1 applications to link against GSS-API V2
-      implementations,
-    * and to retain the slight parameter type differences between the
-    * obsolete versions of these routines and their current forms.
-    */
-
-   OM_uint32 gss_sign
-                 (OM_uint32 ,        /* minor_status */
-                  gss_ctx_id_t,      /* context_handle */
-                  int,               /* qop_req */
-                  gss_buffer_t,      /* message_buffer */
-                  gss_buffer_t       /* message_token */
-                 );
-
-
-   OM_uint32 gss_verify
-                 (OM_uint32 ,        /* minor_status */
-                  gss_ctx_id_t,      /* context_handle */
-                  gss_buffer_t,      /* message_buffer */
-                  gss_buffer_t,      /* token_buffer */
-                  int *              /* qop_state */
-                 );
-
-   OM_uint32 gss_seal
-                 (OM_uint32 ,        /* minor_status */
-                  gss_ctx_id_t,      /* context_handle */
-                  int,               /* conf_req_flag */
-                  int,               /* qop_req */
-                  gss_buffer_t,      /* input_message_buffer */
-                  int ,              /* conf_state */
-                  gss_buffer_t       /* output_message_buffer */
-                 );
-
-
-   OM_uint32 gss_unseal
-                 (OM_uint32 ,        /* minor_status */
-                  gss_ctx_id_t,      /* context_handle */
-                  gss_buffer_t,      /* input_message_buffer */
-                  gss_buffer_t,      /* output_message_buffer */
-                  int ,              /* conf_state */
-                  int *              /* qop_state */
-                 );
-
-   #endif /* GSSAPI_H_ */
-
-
-
-
-
-
-Wray                        Standards Track                    [Page 97]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-Appendix B. Additional constraints for application binary portability
-
-   The purpose of this C-bindings document is to encourage source-level
-   portability of applications across GSS-API implementations on
-   different platforms and atop different mechanisms.  Additional goals
-   that have not been explicitly addressed by this document are link-
-   time and run-time portability.
-
-   Link-time portability provides the ability to compile an application
-   against one implementation of GSS-API, and then link it against a
-   different implementation on the same platform.  It is a stricter
-   requirement than source-level portability.
-
-   Run-time portability differs from link-time portability only on those
-   platforms that implement dynamically loadable GSS-API
-   implementations, but do not offer load-time symbol resolution. On
-   such platforms, run-time portability is a stricter requirement than
-   link-time portability, and will typically include the precise
-   placement of the various GSS-API routines within library entrypoint
-   vectors.
-
-   Individual platforms will impose their own rules that must be
-   followed to achieve link-time (and run-time, if different)
-   portability.  In order to ensure either form of binary portability,
-   an ABI specification must be written for GSS-API implementations on
-   that platform.  However, it is recognized that there are some issues
-   that are likely to be common to all such ABI specifications. This
-   appendix is intended to be a repository for such common issues, and
-   contains some suggestions that individual ABI specifications may
-   choose to reference. Since machine architectures vary greatly, it may
-   not be possible or desirable to follow these suggestions on all
-   platforms.
-
-B.1. Pointers
-
-   While ANSI-C provides a single pointer type for each declared type,
-   plus a single (void *) type, some platforms (notably those using
-   segmented memory architectures) augment this with various modified
-   pointer types (e.g. far pointers, near pointers). These language
-   bindings assume ANSI-C, and thus do not address such non-standard
-   implementations.  GSS-API implementations for such platforms must
-   choose an appropriate memory model, and should use it consistently
-   throughout.  For example, if a memory model is chosen that requires
-   the use of far pointers when passing routine parameters, then far
-   pointers should also be used within the structures defined by GSS-
-   API.
-
-
-
-
-
-Wray                        Standards Track                    [Page 98]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-B.2. Internal structure alignment
-
-   GSS-API defines several data-structures containing differently-sized
-   fields.  An ABI specification should include a detailed description
-   of how the fields of such structures are aligned, and if there is any
-   internal padding in these data structures.  The use of compiler
-   defaults for the platform is recommended.
-
-B.3. Handle types
-
-   The C bindings specify that the gss_cred_id_t and gss_ctx_id_t types
-   should be implemented as either pointer or arithmetic types, and that
-   if pointer types are used, care should be taken to ensure that two
-   handles may be compared with the == operator. Note that ANSI-C does
-   not guarantee that two pointer values may be compared with the ==
-   operator unless either the two pointers point to members of a single
-   array, or at least one of the pointers contains a NULL value.
-
-   For binary portability, additional constraints are required. The
-   following is an attempt at defining platform-independent constraints.
-
-   The size of the handle type must be the same as sizeof(void *), using
-   the appropriate memory model.
-
-   The == operator for the chosen type must be a simple bit-wise
-   comparison.  That is, for two in-memory handle objects h1 and h2, the
-   boolean value of the expression
-
-      (h1 == h2)
-
-   should always be the same as the boolean value of the expression
-
-      (memcmp(&h1, &h2, sizeof(h1)) == 0)
-
-   The actual use of the type (void *) for handle types is discouraged,
-   not for binary portability reasons, but since it effectively disables
-   much of the compile-time type-checking that the compiler can
-   otherwise perform, and is therefore not "programmer-friendly".  If a
-   pointer implementation is desired, and if the platform's
-   implementation of pointers permits, the handles should be implemented
-   as pointers to distinct implementation-defined types.
-
-B.4. The gss_name_t type
-
-   The gss_name_t type, representing the internal name object, should be
-   implemented as a pointer type.  The use of the (void *) type is
-   discouraged as it does not allow the compiler to perform strong
-   type-checking.  However, the pointer type chosen should be of the
-
-
-
-Wray                        Standards Track                    [Page 99]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-   same size as the (void *) type.  Provided this rule is obeyed, ABI
-   specifications need not further constrain the implementation of
-   gss_name_t objects.
-
-B.5. The int and size_t types
-
-   Some platforms may support differently sized implementations of the
-   "int" and "size_t" types, perhaps chosen through compiler switches,
-   and perhaps dependent on memory model.  An ABI specification for such
-   a platform should include required implementations for these types.
-   It is recommended that the default implementation (for the chosen
-   memory model, if appropriate) is chosen.
-
-B.6. Procedure-calling conventions
-
-   Some platforms support a variety of different binary conventions for
-   calling procedures.  Such conventions cover things like the format of
-   the stack frame, the order in which the routine parameters are pushed
-   onto the stack, whether or not a parameter count is pushed onto the
-   stack, whether some argument(s) or return values are to be passed in
-   registers, and whether the called routine or the caller is
-   responsible for removing the stack frame on return.  For such
-   platforms, an ABI specification should specify which calling
-   convention is to be used for GSS-API implementations.
-
-References
-
-   [GSSAPI]    Linn, J., "Generic Security Service Application Program
-               Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [XOM]       OSI Object Management API Specification, Version 2.0 t",
-               X.400 API Association & X/Open Company Limited, August
-               24, 1990 Specification of datatypes and routines for
-               manipulating information objects.
-
-Author's Address
-
-   John Wray
-   Iris Associates
-   5 Technology Park Drive,
-   Westford, MA  01886
-   USA
-
-   Phone: +1-978-392-6689
-   EMail: John_Wray@Iris.com
-
-
-
-
-
-
-Wray                        Standards Track                   [Page 100]
-
-RFC 2744                 GSS-API V2: C-bindings             January 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wray                        Standards Track                   [Page 101]
-
diff --git a/doc/standardisation/rfc3079.txt b/doc/standardisation/rfc3079.txt
deleted file mode 100644
index 4d7ba0de1..000000000
--- a/doc/standardisation/rfc3079.txt
+++ /dev/null
@@ -1,1179 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            G. Zorn
-Request for Comments: 3079                                 cisco Systems
-Category: Informational                                       March 2001
-
-
- Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   The Point-to-Point Protocol (PPP) provides a standard method for
-   transporting multi-protocol datagrams over point-to-point links.
-
-   The PPP Compression Control Protocol provides a method to negotiate
-   and utilize compression protocols over PPP encapsulated links.
-
-   Microsoft Point to Point Encryption (MPPE) is a means of representing
-   PPP packets in an encrypted form.  MPPE uses the RSA RC4 algorithm to
-   provide data confidentiality.  The length of the session key to be
-   used for initializing encryption tables can be negotiated.  MPPE
-   currently supports 40-bit, 56-bit and 128-bit session keys.  MPPE
-   session keys are changed frequently; the exact frequency depends upon
-   the options negotiated, but may be every packet.  MPPE is negotiated
-   within option 18 in the Compression Control Protocol.
-
-   This document describes the method used to derive initial MPPE
-   session keys from a variety of credential types.  It is expected that
-   this memo will be updated whenever Microsoft defines a new key
-   derivation method for MPPE, since its primary purpose is to provide
-   an open, easily accessible reference for third-parties wishing to
-   interoperate with Microsoft products.
-
-   MPPE itself (including the protocol used to negotiate its use, the
-   details of the encryption method used and the algorithm used to
-   change session keys during a session) is described in RFC 3078.
-
-
-
-
-
-
-
-Zorn                         Informational                      [Page 1]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-Table of Contents
-
-   1.  Specification of Requirements ............................... 2
-   2.  Deriving Session Keys from MS-CHAP Credentials .............. 2
-   2.1.  Generating 40-bit Session Keys ............................ 3
-   2.2.  Generating 56-bit Session Keys ............................ 3
-   2.3.  Generating 128-bit Session Keys ........................... 4
-   2.4.  Key Derivation Functions .................................. 5
-   2.5.  Sample Key Derivations .................................... 6
-   2.5.1.  Sample 40-bit Key Derivation ............................ 6
-   2.5.2.  Sample 56-bit Key Derivation ............................ 6
-   2.5.3.  Sample 128-bit Key Derivation ........................... 7
-   3.  Deriving Session Keys from MS-CHAP-2 Credentials ............ 7
-   3.1.  Generating 40-bit Session Keys ............................ 8
-   3.2.  Generating 56-bit Session Keys ............................ 9
-   3.3.  Generating 128-bit Session Keys ...........................10
-   3.4.  Key Derivation Functions ..................................11
-   3.5.  Sample Key Derivations ....................................13
-   3.5.1.  Sample 40-bit Key Derivation ............................13
-   3.5.2.  Sample 56-bit Key Derivation ............................14
-   3.5.3.  Sample 128-bit Key Derivation ...........................15
-   4.  Deriving MPPE Session Keys from TLS Session Keys ............16
-   4.1.  Generating 40-bit Session Keys ............................16
-   4.2.  Generating 56-bit Session Keys ............................17
-   4.3.  Generating 128-bit Session Keys ...........................17
-   5.  Security Considerations .....................................18
-   5.1.  MS-CHAP Credentials .......................................18
-   5.2.  EAP-TLS Credentials .......................................19
-   6.  References ..................................................19
-   7.  Acknowledgements ............................................20
-   8.  Author's Address ............................................20
-   9.  Full Copyright Statement ....................................21
-
-1.  Specification of Requirements
-
-   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
-   "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
-   described in [6].
-
-2.  Deriving Session Keys from MS-CHAP Credentials
-
-   The Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP-1)
-   [2] is a Microsoft-proprietary PPP [1] authentication protocol,
-   providing the functionality to which LAN-based users are accustomed
-   while integrating the encryption and hashing algorithms used on
-   Windows networks.
-
-
-
-
-
-Zorn                         Informational                      [Page 2]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-   The following sections detail the methods used to derive initial
-   session keys (40-, 56- and 128-bit) from MS-CHAP-1 credentials.
-
-   Implementation Note
-
-      The initial session key in both directions is derived from the
-      credentials of the peer that initiated the call and the challenge
-      used (if any) is the challenge from the first authentication.
-      This is true for both unilateral and bilateral authentication, as
-      well as for each link in a multilink bundle.  In the multi-chassis
-      multilink case, implementations are responsible for ensuring that
-      the correct keys are generated on all participating machines.
-
-2.1.  Generating 40-bit Session Keys
-
-   MPPE uses a derivative of the peer's LAN Manager password as the 40-
-   bit session key used for initializing the RC4 encryption tables.
-
-   The first step is to obfuscate the peer's password using the
-   LmPasswordHash() function (described in [2]).  The first 8 octets of
-   the result are used as the basis for the session key generated in the
-   following way:
-
-/*
-* PasswordHash is the basis for the session key
-* SessionKey is a copy of PasswordHash and is the generative session key
-* 8 is the length (in octets) of the key to be generated.
-*
-*/
-Get_Key(PasswordHash, SessionKey, 8)
-
-/*
-* The effective length of the key is reduced to 40 bits by
-* replacing the first three bytes as follows:
-*/
-SessionKey[0] = 0xd1 ;
-SessionKey[1] = 0x26 ;
-SessionKey[2] = 0x9e ;
-
-2.2.  Generating 56-bit Session Keys
-
-   MPPE uses a derivative of the peer's LAN Manager password as the 56-
-   bit session key used for initializing the RC4 encryption tables.
-
-   The first step is to obfuscate the peer's password using the
-   LmPasswordHash() function (described in [2]).  The first 8 octets of
-   the result are used as the basis for the session key generated in the
-   following way:
-
-
-
-Zorn                         Informational                      [Page 3]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-/*
-* PasswordHash is the basis for the session key
-* SessionKey is a copy of PasswordHash and is the generative session key
-* 8 is the length (in octets) of the key to be generated.
-*
-*/
-Get_Key(PasswordHash, SessionKey, 8)
-
-/*
-* The effective length of the key is reduced to 56 bits by
-* replacing the first byte as follows:
-*/
-SessionKey[0] = 0xd1 ;
-
-2.3.  Generating 128-bit Session Keys
-
-   MPPE uses a derivative of the peer's Windows NT password as the 128-
-   bit session key used for initializing encryption tables.
-
-   The first step is to obfuscate the peer's password using
-   NtPasswordHash() function as described in [2].  The first 16 octets
-   of the result are then hashed again using the MD4 algorithm.  The
-   first 16 octets of the second hash are used as the basis for the
-   session key generated in the following way:
-
-/*
-* Challenge (as described in [9]) is sent by the PPP authenticator
-* during authentication and is 8 octets long.
-* NtPasswordHashHash is the basis for the session key.
-* On return, InitialSessionKey contains the initial session
-* key to be used.
-*/
-Get_Start_Key(Challenge, NtPasswordHashHash, InitialSessionKey)
-
-/*
-* CurrentSessionKey is a copy of InitialSessionKey
-* and is the generative session key.
-* Length (in octets) of the key to generate is 16.
-*
-*/
-Get_Key(InitialSessionKey, CurrentSessionKey, 16)
-
-
-
-
-
-
-
-
-
-
-Zorn                         Informational                      [Page 4]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-2.4.  Key Derivation Functions
-
-   The following procedures are used to derive the session key.
-
-/*
- * Pads used in key derivation
- */
-
-SHApad1[40] =
-   {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
-
-SHApad2[40] =
-   {0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
-    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
-    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
-    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2};
-
-/*
- * SHAInit(), SHAUpdate() and SHAFinal() functions are an
- * implementation of Secure Hash Algorithm (SHA-1) [7]. These are
- * available in public domain or can be licensed from
- * RSA Data Security, Inc.
- *
- * 1) InitialSessionKey is 8 octets long for 56- and 40-bit
- *    session keys, 16 octets long for 128 bit session keys.
- * 2) CurrentSessionKey is same as InitialSessionKey when this
- *    routine is called for the first time for the session.
- */
-
-Get_Key(
-IN     InitialSessionKey,
-IN/OUT CurrentSessionKey
-IN     LengthOfDesiredKey )
-{
-   SHAInit(Context)
-   SHAUpdate(Context, InitialSessionKey, LengthOfDesiredKey)
-   SHAUpdate(Context, SHAPad1, 40)
-   SHAUpdate(Context, CurrentSessionKey, LengthOfDesiredKey)
-   SHAUpdate(Context, SHAPad2, 40)
-   SHAFinal(Context, Digest)
-   memcpy(CurrentSessionKey, Digest, LengthOfDesiredKey)
-}
-
-Get_Start_Key(
-IN  Challenge,
-
-
-
-Zorn                         Informational                      [Page 5]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-IN  NtPasswordHashHash,
-OUT InitialSessionKey)
-{
-   SHAInit(Context)
-   SHAUpdate(Context, NtPasswordHashHash, 16)
-   SHAUpdate(Context, NtPasswordHashHash, 16)
-   SHAUpdate(Context, Challenge, 8)
-   SHAFinal(Context, Digest)
-   memcpy(InitialSessionKey, Digest, 16)
-}
-
-2.5.  Sample Key Derivations
-
-   The following sections illustrate 40-, 56- and 128-bit key
-   derivations.  All intermediate values are in hexadecimal.
-
-2.5.1.  Sample 40-bit Key Derivation
-
-
-   Initial Values
-      Password = "clientPass"
-
-   Step 1: LmPasswordHash(Password, PasswordHash)
-      PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
-
-   Step 2: Copy PasswordHash to SessionKey
-      SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
-
-   Step 3: GetKey(PasswordHash, SessionKey, 8)
-      SessionKey = d8 08 01 53 8c ec 4a 08
-
-   Step 4: Reduce the effective key length to 40 bits
-      SessionKey = d1 26 9e 53 8c ec 4a 08
-
-2.5.2.  Sample 56-bit Key Derivation
-
-   Initial Values
-      Password = "clientPass"
-
-   Step 1: LmPasswordHash(Password, PasswordHash)
-      PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
-
-   Step 2: Copy PasswordHash to SessionKey
-      SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2
-
-   Step 3: GetKey(PasswordHash, SessionKey, 8)
-      SessionKey = d8 08 01 53 8c ec 4a 08
-
-
-
-
-Zorn                         Informational                      [Page 6]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-   Step 4: Reduce the effective key length to 56 bits
-      SessionKey = d1 08 01 53 8c ec 4a 08
-
-2.5.3.  Sample 128-bit Key Derivation
-
-Initial Values
-   Password = "clientPass"
-   Challenge = 10 2d b5 df 08 5d 30 41
-
-Step 1: NtPasswordHash(Password, PasswordHash)
-   PasswordHash = 44 eb ba 8d 53 12 b8 d6 11 47 44 11 f5 69 89 ae
-
-Step 2: PasswordHashHash = MD4(PasswordHash)
-   PasswordHashHash = 41 c0 0c 58 4b d2 d9 1c 40 17 a2 a1 2f a5 9f 3f
-
-Step 3: GetStartKey(Challenge, PasswordHashHash, InitialSessionKey)
-   InitialSessionKey = a8 94 78 50 cf c0 ac ca d1 78 9f b6 2d dc dd b0
-
-Step 4: Copy InitialSessionKey to CurrentSessionKey
-   CurrentSessionKey = a8 94 78 50 cf c0 ac c1 d1 78 9f b6 2d dc dd b0
-
-Step 5: GetKey(InitialSessionKey, CurrentSessionKey, 16)
-   CurrentSessionKey = 59 d1 59 bc 09 f7 6f 1d a2 a8 6a 28 ff ec 0b 1e
-
-3.  Deriving Session Keys from MS-CHAP-2 Credentials
-
-   Version 2 of the Microsoft Challenge-Handshake Authentication
-   Protocol (MS-CHAP-2) [8] is a Microsoft-proprietary PPP
-   authentication protocol, providing the functionality to which LAN-
-   based users are accustomed while integrating the encryption and
-   hashing algorithms used on Windows networks.
-
-   The following sections detail the methods used to derive initial
-   session keys from MS-CHAP-2 credentials.  40-, 56- and 128-bit keys
-   are all derived using the same algorithm from the authenticating
-   peer's Windows NT password.  The only difference is in the length of
-   the keys and their effective strength: 40- and 56-bit keys are 8
-   octets in length, while 128-bit keys are 16 octets long.  Separate
-   keys are derived for the send and receive directions of the session.
-
-   Implementation Note
-
-      The initial session keys in both directions are derived from the
-      credentials of the peer that initiated the call and the challenges
-      used are those from the first authentication.  This is true as
-      well for each link in a multilink bundle.  In the multi-chassis
-      multilink case, implementations are responsible for ensuring that
-      the correct keys are generated on all participating machines.
-
-
-
-Zorn                         Informational                      [Page 7]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-3.1.  Generating 40-bit Session Keys
-
-   When used in conjunction with MS-CHAP-2 authentication, the initial
-   MPPE session keys are derived from the peer's Windows NT password.
-
-   The first step is to obfuscate the peer's password using
-   NtPasswordHash() function as described in [8].
-
-      NtPasswordHash(Password, PasswordHash)
-
-   The first 16 octets of the result are then hashed again using the MD4
-   algorithm.
-
-      PasswordHashHash = md4(PasswordHash)
-
-   The first 16 octets of this second hash are used together with the
-   NT- Response field from the MS-CHAP-2 Response packet [8] as the
-   basis for the master session key:
-
-      GetMasterKey(PasswordHashHash, NtResponse, MasterKey)
-
-   Once the master key has been generated, it is used to derive two 40-
-   bit session keys, one for sending and one for receiving:
-
-      GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE)
-      GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE)
-
-   The master session keys are never used to encrypt or decrypt data;
-   they are only used in the derivation of transient session keys.  The
-   initial transient session keys are obtained by calling the function
-   GetNewKeyFromSHA() (described in [3]):
-
-GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
-GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
-                                               ReceiveSessionKey)
-
-   Next, the effective strength of both keys is reduced by setting the
-   first three octets to known constants:
-
-      SendSessionKey[0] = ReceiveSessionKey[0] = 0xd1
-      SendSessionKey[1] = ReceiveSessionKey[1] = 0x26
-      SendSessionKey[2] = ReceiveSessionKey[2] = 0x9e
-
-   Finally, the RC4 tables are initialized using the new session keys:
-
-      rc4_key(SendRC4key, 8, SendSessionKey)
-      rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
-
-
-
-
-Zorn                         Informational                      [Page 8]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-3.2.  Generating 56-bit Session Keys
-
-   When used in conjunction with MS-CHAP-2 authentication, the initial
-   MPPE session keys are derived from the peer's Windows NT password.
-
-   The first step is to obfuscate the peer's password using
-   NtPasswordHash() function as described in [8].
-
-      NtPasswordHash(Password, PasswordHash)
-
-   The first 16 octets of the result are then hashed again using the MD4
-   algorithm.
-
-      PasswordHashHash = md4(PasswordHash)
-
-   The first 16 octets of this second hash are used together with the
-   NT-Response field from the MS-CHAP-2 Response packet [8] as the basis
-   for the master session key:
-
-      GetMasterKey(PasswordHashHash, NtResponse, MasterKey)
-
-   Once the master key has been generated, it is used to derive two
-   56-bit session keys, one for sending and one for receiving:
-
-      GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE)
-      GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE)
-
-   The master session keys are never used to encrypt or decrypt data;
-   they are only used in the derivation of transient session keys.  The
-   initial transient session keys are obtained by calling the function
-   GetNewKeyFromSHA() (described in [3]):
-
-GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
-GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
-                                               ReceiveSessionKey)
-
-   Next, the effective strength of both keys is reduced by setting the
-   first octet to a known constant:
-
-      SendSessionKey[0] = ReceiveSessionKey[0] = 0xd1
-
-   Finally, the RC4 tables are initialized using the new session keys:
-
-      rc4_key(SendRC4key, 8, SendSessionKey)
-      rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
-
-
-
-
-
-
-Zorn                         Informational                      [Page 9]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-3.3.  Generating 128-bit Session Keys
-
-   When used in conjunction with MS-CHAP-2 authentication, the initial
-   MPPE session keys are derived from the peer's Windows NT password.
-
-   The first step is to obfuscate the peer's password using
-   NtPasswordHash() function as described in [8].
-
-      NtPasswordHash(Password, PasswordHash)
-
-   The first 16 octets of the result are then hashed again using the MD4
-   algorithm.
-
-      PasswordHashHash = md4(PasswordHash)
-
-   The first 16 octets of this second hash are used together with the
-   NT-Response field from the MS-CHAP-2 Response packet [8] as the basis
-   for the master session key:
-
-      GetMasterKey(PasswordHashHash, NtResponse, MasterKey)
-
-   Once the master key has been generated, it is used to derive two
-   128-bit master session keys, one for sending and one for receiving:
-
-GetAsymmetricStartKey(MasterKey, MasterSendKey, 16, TRUE, TRUE)
-GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 16, FALSE, TRUE)
-
-   The master session keys are never used to encrypt or decrypt data;
-   they are only used in the derivation of transient session keys.  The
-   initial transient session keys are obtained by calling the function
-   GetNewKeyFromSHA() (described in [3]):
-
-GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey)
-GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16,
-                                                ReceiveSessionKey)
-
-   Finally, the RC4 tables are initialized using the new session keys:
-
-      rc4_key(SendRC4key, 16, SendSessionKey)
-      rc4_key(ReceiveRC4key, 16, ReceiveSessionKey)
-
-
-
-
-
-
-
-
-
-
-
-Zorn                         Informational                     [Page 10]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-3.4.  Key Derivation Functions
-
-   The following procedures are used to derive the session key.
-
-/*
- * Pads used in key derivation
- */
-
-SHSpad1[40] =
-   {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
-
-SHSpad2[40] =
-   {0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
-    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
-    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2,
-    0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2};
-
-/*
- * "Magic" constants used in key derivations
- */
-
-Magic1[27] =
-   {0x54, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74,
-    0x68, 0x65, 0x20, 0x4d, 0x50, 0x50, 0x45, 0x20, 0x4d,
-    0x61, 0x73, 0x74, 0x65, 0x72, 0x20, 0x4b, 0x65, 0x79};
-
-Magic2[84] =
-   {0x4f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6c, 0x69,
-    0x65, 0x6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2c, 0x20,
-    0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68,
-    0x65, 0x20, 0x73, 0x65, 0x6e, 0x64, 0x20, 0x6b, 0x65, 0x79,
-    0x3b, 0x20, 0x6f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x73,
-    0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, 0x69, 0x64, 0x65,
-    0x2c, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68,
-    0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20,
-    0x6b, 0x65, 0x79, 0x2e};
-
-Magic3[84] =
-   {0x4f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6c, 0x69,
-    0x65, 0x6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2c, 0x20,
-    0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68,
-    0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20,
-    0x6b, 0x65, 0x79, 0x3b, 0x20, 0x6f, 0x6e, 0x20, 0x74, 0x68,
-    0x65, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73,
-    0x69, 0x64, 0x65, 0x2c, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73,
-
-
-
-Zorn                         Informational                     [Page 11]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-    0x20, 0x74, 0x68, 0x65, 0x20, 0x73, 0x65, 0x6e, 0x64, 0x20,
-    0x6b, 0x65, 0x79, 0x2e};
-
-
-   GetMasterKey(
-   IN  16-octet  PasswordHashHash,
-   IN  24-octet  NTResponse,
-   OUT 16-octet  MasterKey )
-   {
-      20-octet Digest
-
-      ZeroMemory(Digest, sizeof(Digest));
-
-      /*
-       * SHSInit(), SHSUpdate() and SHSFinal()
-       * are an implementation of the Secure Hash Standard [7].
-       */
-
-      SHSInit(Context);
-      SHSUpdate(Context, PasswordHashHash, 16);
-      SHSUpdate(Context, NTResponse, 24);
-      SHSUpdate(Context, Magic1, 27);
-      SHSFinal(Context, Digest);
-
-      MoveMemory(MasterKey, Digest, 16);
-   }
-
-   VOID
-   GetAsymetricStartKey(
-   IN   16-octet      MasterKey,
-   OUT  8-to-16 octet SessionKey,
-   IN   INTEGER       SessionKeyLength,
-   IN   BOOLEAN       IsSend,
-   IN   BOOLEAN       IsServer )
-   {
-
-      20-octet Digest;
-
-      ZeroMemory(Digest, 20);
-
-      if (IsSend) {
-         if (IsServer) {
-            s = Magic3
-         } else {
-            s = Magic2
-         }
-      } else {
-         if (IsServer) {
-
-
-
-Zorn                         Informational                     [Page 12]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-            s = Magic2
-         } else {
-            s = Magic3
-         }
-      }
-
-      /*
-       * SHSInit(), SHSUpdate() and SHSFinal()
-       * are an implementation of the Secure Hash Standard [7].
-       */
-
-      SHSInit(Context);
-      SHSUpdate(Context, MasterKey, 16);
-      SHSUpdate(Context, SHSpad1, 40);
-      SHSUpdate(Context, s, 84);
-      SHSUpdate(Context, SHSpad2, 40);
-      SHSFinal(Context, Digest);
-
-      MoveMemory(SessionKey, Digest, SessionKeyLength);
-   }
-
-3.5.  Sample Key Derivations
-
-   The following sections illustrate 40-, 56- and 128-bit key
-   derivations. All intermediate values are in hexadecimal.
-
-3.5.1.  Sample 40-bit Key Derivation
-
-Initial Values
-   UserName = "User"
-            =  55 73 65 72
-
-   Password = "clientPass"
-            = 63 00 6C 00 69 00 65 00 6E 00
-              74 00 50 00 61 00 73 00 73 00
-
-   AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C
-                            60 21 32 26 26 28
-   PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
-
-   Challenge = D0 2E 43 86 BC E9 12 26
-
-   NT-Response =
-   82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33
-   11 4A 3D 85 D6 DF
-
-Step 1: NtPasswordHash(Password, PasswordHash)
-   PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
-
-
-
-Zorn                         Informational                     [Page 13]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-Step 2: PasswordHashHash = MD4(PasswordHash)
-   PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
-
-Step 3: Derive the master key (GetMasterKey())
-   MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31
-
-Step 4: Derive the master send session key (GetAsymmetricStartKey())
-   SendStartKey40 = 8B 7C DC 14 9B 99 3A 1B
-
-Step 5: Derive the initial send session key (GetNewKeyFromSHA())
-   SendSessionKey40 = D1 26 9E C4 9F A6 2E 3E
-
-Sample Encrypted Message
-   rc4(SendSessionKey40, "test message") = 92 91 37 91 7E 58 03 D6
-                                           68 D7 58 98
-
-3.5.2.  Sample 56-bit Key Derivation
-
-Initial Values
-   UserName = "User"
-            =  55 73 65 72
-
-   Password = "clientPass"
-            = 63 00 6C 00 69 00 65 00 6E 00 74 00 50
-              00 61 00 73 00 73 00
-
-   AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C
-                            60 21 32 26 26 28
-   PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
-
-   Challenge = D0 2E 43 86 BC E9 12 26
-
-   NT-Response =
-   82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33
-   11 4A 3D 85 D6 DF
-
-Step 1: NtPasswordHash(Password, PasswordHash)
-   PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
-
-Step 2: PasswordHashHash = MD4(PasswordHash)
-   PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
-
-Step 3: Derive the master key (GetMasterKey())
-   MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31
-
-Step 4: Derive the master send session key (GetAsymmetricStartKey())
-   SendStartKey56 = 8B 7C DC 14 9B 99 3A 1B
-
-
-
-
-Zorn                         Informational                     [Page 14]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-Step 5: Derive the initial send session key (GetNewKeyFromSHA())
-   SendSessionKey56 = D1 5C 00 C4 9F A6 2E 3E
-
-Sample Encrypted Message
-   rc4(SendSessionKey40, "test message") = 3F 10 68 33 FA 44 8D
-                                           A8 42 BC 57 58
-
-3.5.3.  Sample 128-bit Key Derivation
-
-Initial Values
-   UserName = "User"
-            =  55 73 65 72
-
-   Password = "clientPass"
-            = 63 00 6C 00 69 00 65 00 6E 00
-              74 00 50 00 61 00 73 00 73 00
-
-   AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C
-                            60 21 32 26 26 28
-
-   PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
-
-   Challenge = D0 2E 43 86 BC E9 12 26
-
-   NT-Response =
-   82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33
-   11 4A 3D 85 D6 DF
-
-Step 1: NtPasswordHash(Password, PasswordHash)
-   PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
-
-Step 2: PasswordHashHash = MD4(PasswordHash)
-   PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
-
-Step 2: Derive the master key (GetMasterKey())
-   MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31
-
-Step 3: Derive the send master session key (GetAsymmetricStartKey())
-
-   SendStartKey128 = 8B 7C DC 14 9B 99 3A 1B A1 18 CB 15 3F 56 DC CB
-
-Step 4: Derive the initial send session key (GetNewKeyFromSHA())
-   SendSessionKey128 = 40 5C B2 24 7A 79 56 E6 E2 11 00 7A E2 7B 22 D4
-
-Sample Encrypted Message
-  rc4(SendSessionKey128, "test message") = 81 84 83 17 DF 68
-                                           84 62 72 FB 5A BE
-
-
-
-
-Zorn                         Informational                     [Page 15]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-4.  Deriving MPPE Session Keys from TLS Session Keys
-
-   The Extensible Authentication Protocol (EAP) [10] is a PPP extension
-   that provides support  for  additional  authentication methods within
-   PPP.  Transport  Level  Security  (TLS) [11] provides for mutual
-   authentication, integrity-protected ciphersuite negotiation and key
-   exchange between two  endpoints.  EAP-TLS [12] is an EAP
-   authentication type which allows the use of TLS within the PPP
-   authentication framework.  The following sections describe the
-   methods used to derive initial session keys from TLS session keys.
-   56-, 40- and 128-bit keys are derived using the same algorithm.  The
-   only difference is in the length of the keys and their effective
-   strength: 56- and 40-bit keys are 8 octets in length, while 128-bit
-   keys are 16 octets long.  Separate keys are derived for the send and
-   receive directions of the session.
-
-4.1.  Generating 40-bit Session Keys
-
-   When MPPE is used in conjunction with EAP-TLS authentication, the TLS
-   master secret is used as the master session key.
-
-   The algorithm used to derive asymmetrical master session keys from
-   the TLS master secret is described in [12].  The master session keys
-   are never used to encrypt or decrypt data; they are only used in the
-   derivation of transient session keys.
-
-   Implementation Note
-
-      If the asymmetrical master keys are less than 8 octets in length,
-      they MUST be padded on the left with zeroes before being used to
-      derive the initial transient session keys.  Conversely, if the
-      asymmetrical master keys are more than 8 octets in length, they
-      must be truncated to 8 octets before being used to derive the
-      initial transient session keys.
-
-   The initial transient session keys are obtained by calling the
-   function GetNewKeyFromSHA() (described in [3]):
-
-GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
-GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
-ReceiveSessionKey)
-
-   Next, the effective strength of both keys is reduced by setting the
-   first three octets to known constants:
-
-      SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1
-      SendSessionKey[1] = ReceiveSessionKey[1] = 0x26
-      SendSessionKey[2] = ReceiveSessionKey[2] = 0x9E
-
-
-
-Zorn                         Informational                     [Page 16]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-   Finally, the RC4 tables are initialized using the new session keys:
-
-      rc4_key(SendRC4key, 8, SendSessionKey)
-      rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
-
-4.2.  Generating 56-bit Session Keys
-
-   When MPPE is used in conjunction with EAP-TLS authentication, the TLS
-   master secret is used as the master session key.
-
-   The algorithm used to derive asymmetrical master session keys from
-   the TLS master secret is described in [12].  The master session keys
-   are never used to encrypt or decrypt data; they are only used in the
-   derivation of transient session keys.
-
-   Implementation Note
-
-      If the asymmetrical master keys are less than 8 octets in length,
-      they MUST be padded on the left with zeroes before being used to
-      derive the initial transient session keys.  Conversely, if the
-      asymmetrical master keys are more than 8 octets in length, they
-      must be truncated to 8 octets before being used to derive the
-      initial transient session keys.
-
-   The initial transient session keys are obtained by calling the
-   function GetNewKeyFromSHA() (described in [3]):
-
-GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey)
-GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8,
-ReceiveSessionKey)
-
-   Next, the effective strength of both keys is reduced by setting the
-   initial octet to a known constant:
-
-      SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1
-
-   Finally, the RC4 tables are initialized using the new session keys:
-
-      rc4_key(SendRC4key, 8, SendSessionKey)
-      rc4_key(ReceiveRC4key, 8, ReceiveSessionKey)
-
-4.3.  Generating 128-bit Session Keys
-
-   When MPPE is used in conjunction with EAP-TLS authentication, the TLS
-   master secret is used as the master session key.
-
-
-
-
-
-
-Zorn                         Informational                     [Page 17]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-   The algorithm used to derive asymmetrical master session keys from
-   the TLS master secret is described in [12].  Note that the send key
-   on one side is the receive key on the other.
-
-   The master session keys are never used to encrypt or decrypt data;
-   they are only used in the derivation of transient session keys.
-
-   Implementation Note
-
-      If the asymmetrical master keys are less than 16 octets in length,
-      they MUST be padded on the left with zeroes before being used to
-      derive the initial transient session keys.  Conversely, if the
-      asymmetrical master keys are more than 16 octets in length, they
-      must be truncated to 16 octets before being used to derive the
-      initial transient session keys.
-
-   The initial transient session keys are obtained by calling the
-   function GetNewKeyFromSHA() (described in [3]):
-
-GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey)
-GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16,
-ReceiveSessionKey)
-
-   Finally, the RC4 tables are initialized using the new session keys:
-
-      rc4_key(SendRC4key, 16, SendSessionKey)
-      rc4_key(ReceiveRC4key, 16, ReceiveSessionKey)
-
-5.  Security Considerations
-
-5.1.  MS-CHAP Credentials
-
-   Because of the way in which 40-bit keys are derived from MS-CHAP-1
-   credentials, the initial 40-bit session key will be identical in all
-   sessions established under the same peer credentials.  For this
-   reason, and because RC4 with a 40-bit key length is believed to be a
-   relatively weak cipher, peers SHOULD NOT use 40-bit keys derived from
-   the LAN Manager password hash (as described above) if it can be
-   avoided.
-
-   Since the MPPE session keys are derived from user passwords (in the
-   MS- CHAP-1 and MS-CHAP-2 cases), care should be taken to ensure the
-   selection of strong passwords and passwords should be changed
-   frequently.
-
-
-
-
-
-
-
-Zorn                         Informational                     [Page 18]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-5.2.  EAP-TLS Credentials
-
-   The strength of the session keys is dependent upon the security of
-   the TLS protocol.
-
-   The EAP server may be on a separate machine from the PPP
-   authenticator; if this is the case, adequate care must be taken in
-   the transmission of the EAP-TLS master keys to the authenticator.
-
-6.  References
-
-   [1]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
-        1661, July 1994.
-
-   [2]  Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433,
-        October 1998.
-
-   [3]  Pall, G. and G. Zorn, "Microsoft Point-to-Point Encryption
-        (MPPE) RFC 3078, March 2001.
-
-   [4]  RC4 is a proprietary encryption algorithm available under
-        license from RSA Data Security Inc.  For licensing information,
-        contact:
-               RSA Data Security, Inc.
-               100 Marine Parkway
-               Redwood City, CA 94065-1031
-
-   [5]  Pall, G., "Microsoft Point-to-Point Compression (MPPC)
-        Protocol", RFC 2118, March 1997.
-
-   [6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [7]  "Secure Hash Standard", Federal Information Processing Standards
-        Publication 180-1, National Institute of Standards and
-        Technology, April 1995.
-
-   [8]  Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759,
-        January 2000.
-
-   [9]  Simpson, W., "PPP Challenge Handshake Authentication Protocol
-        (CHAP)", RFC 1994, August 1996.
-
-   [10] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
-        Protocol (EAP)", RFC 2284, March 1998.
-
-
-
-
-
-
-Zorn                         Informational                     [Page 19]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-   [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-        2246, January 1999.
-
-   [12] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
-        RFC 2716, October 1999.
-
-7.  Acknowledgements
-
-   Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all
-   of Microsoft Corporation, significantly contributed to the design and
-   development of MPPE.
-
-   Additional thanks to Robert Friend, Joe Davies, Jody Terrill, Archie
-   Cobbs, Mark Deuser, Vijay Baliga, Brad Robel-Forrest and Jeff Haag
-   for useful feedback.
-
-   The technical portions of this memo were completed while the author
-   was employed by Microsoft Corporation.
-
-8.  Author's Address
-
-   Questions about this memo can also be directed to:
-
-   Glen Zorn
-   cisco Systems
-   500 108th Avenue N.E.
-   Suite 500
-   Bellevue, Washington 98004
-   USA
-
-   Phone: +1 425 438 8218
-   FAX:   +1 425 438 1848
-   EMail: gwz@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zorn                         Informational                     [Page 20]
-
-RFC 3079                  MPPE Key Derivation                 March 2001
-
-
-9.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zorn                         Informational                     [Page 21]
-
diff --git a/doc/standardisation/rfc3244.txt b/doc/standardisation/rfc3244.txt
deleted file mode 100644
index 0ba07ba8e..000000000
--- a/doc/standardisation/rfc3244.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           M. Swift
-Request for Comments: 3244                      University of Washington
-Category: Informational                                       J. Trostle
-                                                           Cisco Systems
-                                                               J. Brezak
-                                                               Microsoft
-                                                           February 2002
-
-
-            Microsoft Windows 2000 Kerberos Change Password
-                       and Set Password Protocols
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This memo specifies Microsoft's Windows 2000 Kerberos change password
-   and set password protocols.  The Windows 2000 Kerberos change
-   password protocol interoperates with the original Kerberos change
-   password protocol.  Change password is a request reply protocol that
-   includes a KRB_PRIV message that contains the new password for the
-   user.
-
-1. Introduction
-
-   Microsoft's Windows 2000 Kerberos change password protocol
-   interoperates with the original Kerberos change password protocol.
-   Change password is a request reply protocol that includes a KRB_PRIV
-   message that contains the new password for the user.  The original
-   change password protocol does not allow an administrator to set a
-   password for a new user.  This functionality is useful in some
-   environments, and this proposal extends the change password protocol
-   to allow password setting.  The changes are: adding new fields to the
-   request message to indicate the principal which is having its
-   password set, not requiring the initial flag in the service ticket,
-   using a new protocol version number, and adding three new result
-   codes.
-
-
-
-
-
-
-Swift, et al.                Informational                      [Page 1]
-
-RFC 3244      Microsoft Windows 2000 Kerberos Change & Set February 2002
-
-
-2.  The Protocol
-
-   The service accepts requests on UDP port 464 and TCP port 464 as
-   well.  The protocol consists of a single request message followed by
-   a single reply message.  For UDP transport, each message must be
-   fully contained in a single UDP packet.
-
-   For TCP transport, there is a 4 octet header in network byte order
-   that precedes the message and specifies the length of the message.
-
-   Request Message
-
-     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
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |         message length        |    protocol version number    |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |          AP_REQ length        |         AP_REQ data           /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /                        KRB-PRIV message                       /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   All 16 bit fields are in big-endian order.
-
-   message length field: contains the number of bytes in the message
-   including this field.
-
-   protocol version number: contains the hex constant 0xff80 (big-endian
-   integer).
-
-   AP-REQ length: length of AP-REQ data, in bytes.  If the length is
-   zero, then the last field contains a KRB-ERROR message instead of a
-   KRB-PRIV message.
-
-   AP-REQ data: (see [1]) The AP-REQ message must be for the service
-   principal kadmin/changepw@REALM, where REALM is the REALM of the user
-   who wishes to change/set his password.  The authenticator in the AP-
-   REQ must include a subsession key.  (NOTE: The subsession key must be
-   pseudo-randomly generated and must never be reused for multiple
-   authenticators.)  To enable setting of passwords, it is not required
-   that the initial flag be set in the Kerberos service ticket.
-
-   KRB-PRIV message (see [1]) This user-data field in the KRB-PRIV
-   message is encrypted using the subkey from the authenticator in the
-   AP-REQ data.  The usec and seq-number fields of the KRB_PRIV message
-   are present and have the same value as the seq-number field in the
-
-
-
-
-
-Swift, et al.                Informational                      [Page 2]
-
-RFC 3244      Microsoft Windows 2000 Kerberos Change & Set February 2002
-
-
-   authenticator from the AP_REQ message (the seq-number in the
-   authenticator will be present).  The server ignores the optional
-   r-address field in the KRB_PRIV message, if it is present.
-
-   The user-data component of the message consists of the following
-   ASN.1 structure encoded as an OCTET STRING:
-
-      ChangePasswdData ::=  SEQUENCE {
-                          newpasswd[0]   OCTET STRING,
-                          targname[1]    PrincipalName OPTIONAL,
-                          targrealm[2]   Realm OPTIONAL
-                          }
-
-   The server must verify the AP-REQ message, check whether the client
-   principal in the ticket is authorized to set/change the password
-   (either for that principal, or for the principal in the targname
-   field if present), and decrypt the new password.  The server also
-   checks whether the initial flag is required for this request,
-   replying with status 0x0007 if it is not set and should be.  An
-   authorization failure is cause to respond with status 0x0005.  For
-   forward compatibility, the server should be prepared to ignore fields
-   after targrealm in the structure that it does not understand.
-
-   The newpasswd field contains the cleartext password, and the server
-   will apply any local policy checks including password policy checks.
-   The server then generates the appropriate keytypes from the password
-   and stores them in the KDC database.  If all goes well, status 0x0000
-   is returned to the client in the reply message (see below).
-
-   Reply Message
-
-     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
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |         message length        |    protocol version number    |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |          AP_REP length        |         AP-REP data           /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /                         KRB-PRIV message                      /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   All 16 bit fields are in big-endian order.
-
-   message length field: contains the number of bytes in the message
-   including this field.
-
-
-
-
-
-
-Swift, et al.                Informational                      [Page 3]
-
-RFC 3244      Microsoft Windows 2000 Kerberos Change & Set February 2002
-
-
-   protocol version number: contains the hex constant 0x0001 (big-endian
-   integer). (The reply message has the same format as the original
-   change password protocol.)
-
-   AP-REP length: length of AP-REP data, in bytes.  If the length is
-   zero, then the last field contains a KRB-ERROR message instead of a
-   KRB-PRIV message.
-
-   AP-REP data: the AP-REP is the response to the AP-REQ in the request
-   packet.
-
-   KRB-PRIV message: This KRB-PRIV message must be encrypted with the
-   subsession key from the authenticator in the AP-REQ data.
-
-   The server will respond with a KRB-PRIV message unless it cannot
-   decode the client AP-REQ or KRB-PRIV message, in which case it will
-   respond with a KRB-ERROR message.  NOTE: Unlike change password
-   version 1, the KRB-ERROR message will be sent back without any
-   encapsulation.
-
-   The user-data component of the KRB-PRIV message, or e-data component
-   of the KRB-ERROR message, consists of the following data.
-
-     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
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |          result code          |        result string          /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   result code (16 bits) (result codes 0-4 are from the original change
-   password protocol):
-
-      The result code must have one of the following values
-      (big-endian integer):
-
-      KRB5_KPASSWD_SUCCESS             0 request succeeds (This value
-                                         is not allowed in a KRB-ERROR
-                                         message)
-
-      KRB5_KPASSWD_MALFORMED           1 request fails due to being
-                                         malformed
-
-      KRB5_KPASSWD_HARDERROR           2 request fails due to "hard"
-                                         error in processing the
-                                         request (for example, there
-                                         is a resource or other
-                                         problem causing the request
-                                         to fail)
-
-
-
-Swift, et al.                Informational                      [Page 4]
-
-RFC 3244      Microsoft Windows 2000 Kerberos Change & Set February 2002
-
-
-      KRB5_KPASSWD_AUTHERROR           3 request fails due to an error
-                                         in authentication processing
-
-      KRB5_KPASSWD_SOFTERROR           4 request fails due to a
-                                         "soft" error in processing
-                                         the request
-
-      KRB5_KPASSWD_ACCESSDENIED        5 requestor not authorized
-
-      KRB5_KPASSWD_BAD_VERSION         6 protocol version unsupported
-
-      KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
-
-      0xFFFF is returned if the request fails for some other reason.
-      Although only a few non-zero result codes are specified here, the
-      client should accept any non-zero result code as indicating
-      failure.
-
-   result string:
-
-      This field contains information which might be useful to the user,
-      such as feedback about policy failures.  The string is encoded in
-      UTF-8.  It may be omitted if the server does not wish to include
-      it.  If it is present, the client will display the string to the
-      user.
-
-3. Security Considerations
-
-   Password policies should be enforced to make sure that users do not
-   pick passwords (for change password) that are vulnerable to brute
-   force password guessing attacks.  An administrator who is authorized
-   to set other principal's passwords is highly trusted and must also
-   carefully protect his/her own credentials.
-
-4.  References
-
-   [1]   Kohl, J. and C. Neuman, "The Kerberos Network Authentication
-         Service (V5)", RFC 1510, September 1993.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Swift, et al.                Informational                      [Page 5]
-
-RFC 3244      Microsoft Windows 2000 Kerberos Change & Set February 2002
-
-
-5. Authors' Addresses
-
-   Mike Swift
-   University of Washington
-   Seattle, WA
-
-   EMail: mikesw@cs.washington.edu
-
-
-   Jonathan Trostle
-   Cisco Systems
-   170 W. Tasman Dr.
-   San Jose, CA 95134
-
-   EMail: john3725@world.std.com
-
-
-   John Brezak
-   Microsoft
-   1 Microsoft Way
-   Redmond, WA 98052
-
-   EMail: jbrezak@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Swift, et al.                Informational                      [Page 6]
-
-RFC 3244      Microsoft Windows 2000 Kerberos Change & Set February 2002
-
-
-6.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Swift, et al.                Informational                      [Page 7]
-
diff --git a/doc/standardisation/rfc3280.txt b/doc/standardisation/rfc3280.txt
deleted file mode 100644
index 433908bb7..000000000
--- a/doc/standardisation/rfc3280.txt
+++ /dev/null
@@ -1,7227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Housley
-Request for Comments: 3280                              RSA Laboratories
-Obsoletes: 2459                                                  W. Polk
-Category: Standards Track                                           NIST
-                                                                 W. Ford
-                                                                VeriSign
-                                                                 D. Solo
-                                                               Citigroup
-                                                              April 2002
-
-                Internet X.509 Public Key Infrastructure
-       Certificate and Certificate Revocation List (CRL) Profile
-
-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 (2002).  All Rights Reserved.
-
-Abstract
-
-   This memo profiles the X.509 v3 certificate and X.509 v2 Certificate
-   Revocation List (CRL) for use in the Internet.  An overview of this
-   approach and model are provided as an introduction.  The X.509 v3
-   certificate format is described in detail, with additional
-   information regarding the format and semantics of Internet name
-   forms.  Standard certificate extensions are described and two
-   Internet-specific extensions are defined.  A set of required
-   certificate extensions is specified.  The X.509 v2 CRL format is
-   described in detail, and required extensions are defined.  An
-   algorithm for X.509 certification path validation is described.  An
-   ASN.1 module and examples are provided in the appendices.
-
-Table of Contents
-
-   1  Introduction  . . . . . . . . . . . . . . . . . . . . . .   4
-   2  Requirements and Assumptions  . . . . . . . . . . . . . .   5
-   2.1  Communication and Topology  . . . . . . . . . . . . . .   6
-   2.2  Acceptability Criteria  . . . . . . . . . . . . . . . .   6
-   2.3  User Expectations . . . . . . . . . . . . . . . . . . .   7
-   2.4  Administrator Expectations  . . . . . . . . . . . . . .   7
-   3  Overview of Approach  . . . . . . . . . . . . . . . . . .   7
-
-
-
-Housley, et. al.            Standards Track                     [Page 1]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   3.1  X.509 Version 3 Certificate . . . . . . . . . . . . . .   8
-   3.2  Certification Paths and Trust . . . . . . . . . . . . .   9
-   3.3  Revocation  . . . . . . . . . . . . . . . . . . . . . .  11
-   3.4  Operational Protocols . . . . . . . . . . . . . . . . .  13
-   3.5  Management Protocols  . . . . . . . . . . . . . . . . .  13
-   4  Certificate and Certificate Extensions Profile  . . . . .  14
-   4.1  Basic Certificate Fields  . . . . . . . . . . . . . . .  15
-   4.1.1  Certificate Fields  . . . . . . . . . . . . . . . . .  16
-   4.1.1.1  tbsCertificate  . . . . . . . . . . . . . . . . . .  16
-   4.1.1.2  signatureAlgorithm  . . . . . . . . . . . . . . . .  16
-   4.1.1.3  signatureValue  . . . . . . . . . . . . . . . . . .  16
-   4.1.2  TBSCertificate  . . . . . . . . . . . . . . . . . . .  17
-   4.1.2.1  Version . . . . . . . . . . . . . . . . . . . . . .  17
-   4.1.2.2  Serial number . . . . . . . . . . . . . . . . . . .  17
-   4.1.2.3  Signature . . . . . . . . . . . . . . . . . . . . .  18
-   4.1.2.4  Issuer  . . . . . . . . . . . . . . . . . . . . . .  18
-   4.1.2.5  Validity  . . . . . . . . . . . . . . . . . . . . .  22
-   4.1.2.5.1  UTCTime . . . . . . . . . . . . . . . . . . . . .  22
-   4.1.2.5.2  GeneralizedTime . . . . . . . . . . . . . . . . .  22
-   4.1.2.6  Subject . . . . . . . . . . . . . . . . . . . . . .  23
-   4.1.2.7  Subject Public Key Info . . . . . . . . . . . . . .  24
-   4.1.2.8  Unique Identifiers  . . . . . . . . . . . . . . . .  24
-   4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . .  24
-   4.2  Certificate Extensions  . . . . . . . . . . . . . . . .  24
-   4.2.1  Standard Extensions . . . . . . . . . . . . . . . . .  25
-   4.2.1.1  Authority Key Identifier  . . . . . . . . . . . . .  26
-   4.2.1.2  Subject Key Identifier  . . . . . . . . . . . . . .  27
-   4.2.1.3  Key Usage . . . . . . . . . . . . . . . . . . . . .  28
-   4.2.1.4  Private Key Usage Period  . . . . . . . . . . . . .  29
-   4.2.1.5  Certificate Policies  . . . . . . . . . . . . . . .  30
-   4.2.1.6  Policy Mappings . . . . . . . . . . . . . . . . . .  33
-   4.2.1.7  Subject Alternative Name  . . . . . . . . . . . . .  33
-   4.2.1.8  Issuer Alternative Name . . . . . . . . . . . . . .  36
-   4.2.1.9  Subject Directory Attributes  . . . . . . . . . . .  36
-   4.2.1.10  Basic Constraints  . . . . . . . . . . . . . . . .  36
-   4.2.1.11  Name Constraints . . . . . . . . . . . . . . . . .  37
-   4.2.1.12  Policy Constraints . . . . . . . . . . . . . . . .  40
-   4.2.1.13  Extended Key Usage . . . . . . . . . . . . . . . .  40
-   4.2.1.14  CRL Distribution Points  . . . . . . . . . . . . .  42
-   4.2.1.15  Inhibit Any-Policy . . . . . . . . . . . . . . . .  44
-   4.2.1.16  Freshest CRL . . . . . . . . . . . . . . . . . . .  44
-   4.2.2  Internet Certificate Extensions . . . . . . . . . . .  45
-   4.2.2.1  Authority Information Access  . . . . . . . . . . .  45
-   4.2.2.2  Subject Information Access  . . . . . . . . . . . .  46
-   5  CRL and CRL Extensions Profile  . . . . . . . . . . . . .  48
-   5.1  CRL Fields  . . . . . . . . . . . . . . . . . . . . . .  49
-   5.1.1  CertificateList Fields  . . . . . . . . . . . . . . .  50
-   5.1.1.1  tbsCertList . . . . . . . . . . . . . . . . . . . .  50
-
-
-
-Housley, et. al.            Standards Track                     [Page 2]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   5.1.1.2  signatureAlgorithm  . . . . . . . . . . . . . . . .  50
-   5.1.1.3  signatureValue  . . . . . . . . . . . . . . . . . .  51
-   5.1.2  Certificate List "To Be Signed" . . . . . . . . . . .  51
-   5.1.2.1  Version . . . . . . . . . . . . . . . . . . . . . .  52
-   5.1.2.2  Signature . . . . . . . . . . . . . . . . . . . . .  52
-   5.1.2.3  Issuer Name . . . . . . . . . . . . . . . . . . . .  52
-   5.1.2.4  This Update . . . . . . . . . . . . . . . . . . . .  52
-   5.1.2.5  Next Update . . . . . . . . . . . . . . . . . . . .  53
-   5.1.2.6  Revoked Certificates  . . . . . . . . . . . . . . .  53
-   5.1.2.7  Extensions  . . . . . . . . . . . . . . . . . . . .  53
-   5.2  CRL Extensions  . . . . . . . . . . . . . . . . . . . .  53
-   5.2.1  Authority Key Identifier  . . . . . . . . . . . . . .  54
-   5.2.2  Issuer Alternative Name . . . . . . . . . . . . . . .  54
-   5.2.3  CRL Number  . . . . . . . . . . . . . . . . . . . . .  55
-   5.2.4  Delta CRL Indicator . . . . . . . . . . . . . . . . .  55
-   5.2.5  Issuing Distribution Point  . . . . . . . . . . . . .  58
-   5.2.6  Freshest CRL  . . . . . . . . . . . . . . . . . . . .  59
-   5.3  CRL Entry Extensions  . . . . . . . . . . . . . . . . .  60
-   5.3.1  Reason Code . . . . . . . . . . . . . . . . . . . . .  60
-   5.3.2  Hold Instruction Code . . . . . . . . . . . . . . . .  61
-   5.3.3  Invalidity Date . . . . . . . . . . . . . . . . . . .  62
-   5.3.4  Certificate Issuer  . . . . . . . . . . . . . . . . .  62
-   6  Certificate Path Validation . . . . . . . . . . . . . . .  62
-   6.1  Basic Path Validation . . . . . . . . . . . . . . . . .  63
-   6.1.1  Inputs  . . . . . . . . . . . . . . . . . . . . . . .  66
-   6.1.2  Initialization  . . . . . . . . . . . . . . . . . . .  67
-   6.1.3  Basic Certificate Processing  . . . . . . . . . . . .  70
-   6.1.4  Preparation for Certificate i+1 . . . . . . . . . . .  75
-   6.1.5  Wrap-up procedure . . . . . . . . . . . . . . . . . .  78
-   6.1.6  Outputs . . . . . . . . . . . . . . . . . . . . . . .  80
-   6.2  Extending Path Validation . . . . . . . . . . . . . . .  80
-   6.3  CRL Validation  . . . . . . . . . . . . . . . . . . . .  81
-   6.3.1  Revocation Inputs . . . . . . . . . . . . . . . . . .  82
-   6.3.2  Initialization and Revocation State Variables . . . .  82
-   6.3.3  CRL Processing  . . . . . . . . . . . . . . . . . . .  83
-   7  References  . . . . . . . . . . . . . . . . . . . . . . .  86
-   8  Intellectual Property Rights  . . . . . . . . . . . . . .  88
-   9  Security Considerations . . . . . . . . . . . . . . . . .  89
-   Appendix A.  ASN.1 Structures and OIDs . . . . . . . . . . .  92
-   A.1 Explicitly Tagged Module, 1988 Syntax  . . . . . . . . .  92
-   A.2 Implicitly Tagged Module, 1988 Syntax  . . . . . . . . . 105
-   Appendix B.  ASN.1 Notes . . . . . . . . . . . . . . . . . . 112
-   Appendix C.  Examples  . . . . . . . . . . . . . . . . . . . 115
-   C.1  DSA Self-Signed Certificate . . . . . . . . . . . . . . 115
-   C.2  End Entity Certificate Using DSA  . . . . . . . . . . . 119
-   C.3  End Entity Certificate Using RSA  . . . . . . . . . . . 122
-   C.4  Certificate Revocation List . . . . . . . . . . . . . . 126
-   Author Addresses . . . . . . . . . . . . . . . . . . . . . . 128
-
-
-
-Housley, et. al.            Standards Track                     [Page 3]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . 129
-
-1  Introduction
-
-   This specification is one part of a family of standards for the X.509
-   Public Key Infrastructure (PKI) for the Internet.
-
-   This specification profiles the format and semantics of certificates
-   and certificate revocation lists (CRLs) for the Internet PKI.
-   Procedures are described for processing of certification paths in the
-   Internet environment.  Finally, ASN.1 modules are provided in the
-   appendices for all data structures defined or referenced.
-
-   Section 2 describes Internet PKI requirements, and the assumptions
-   which affect the scope of this document.  Section 3 presents an
-   architectural model and describes its relationship to previous IETF
-   and ISO/IEC/ITU-T standards.  In particular, this document's
-   relationship with the IETF PEM specifications and the ISO/IEC/ITU-T
-   X.509 documents are described.
-
-   Section 4 profiles the X.509 version 3 certificate, and section 5
-   profiles the X.509 version 2 CRL.  The profiles include the
-   identification of ISO/IEC/ITU-T and ANSI extensions which may be
-   useful in the Internet PKI.  The profiles are presented in the 1988
-   Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1
-   syntax used in the most recent ISO/IEC/ITU-T standards.
-
-   Section 6 includes certification path validation procedures.  These
-   procedures are based upon the ISO/IEC/ITU-T definition.
-   Implementations are REQUIRED to derive the same results but are not
-   required to use the specified procedures.
-
-   Procedures for identification and encoding of public key materials
-   and digital signatures are defined in [PKIXALGS].  Implementations of
-   this specification are not required to use any particular
-   cryptographic algorithms.  However, conforming implementations which
-   use the algorithms identified in [PKIXALGS] MUST identify and encode
-   the public key materials and digital signatures as described in that
-   specification.
-
-   Finally, three appendices are provided to aid implementers.  Appendix
-   A contains all ASN.1 structures defined or referenced within this
-   specification.  As above, the material is presented in the 1988
-   ASN.1.  Appendix B contains notes on less familiar features of the
-   ASN.1 notation used within this specification.  Appendix C contains
-   examples of a conforming certificate and a conforming CRL.
-
-
-
-
-
-Housley, et. al.            Standards Track                     [Page 4]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   This specification obsoletes RFC 2459.  This specification differs
-   from RFC 2459 in five basic areas:
-
-      * To promote interoperable implementations, a detailed algorithm
-      for certification path validation is included in section 6.1 of
-      this specification; RFC 2459 provided only a high-level
-      description of path validation.
-
-      * An algorithm for determining the status of a certificate using
-      CRLs is provided in section 6.3 of this specification.  This
-      material was not present in RFC 2459.
-
-      * To accommodate new usage models, detailed information describing
-      the use of delta CRLs is provided in Section 5 of this
-      specification.
-
-      * Identification and encoding of public key materials and digital
-      signatures are not included in this specification, but are now
-      described in a companion specification [PKIXALGS].
-
-      * Four additional extensions are specified: three certificate
-      extensions and one CRL extension.  The certificate extensions are
-      subject info access, inhibit any-policy, and freshest CRL.  The
-      freshest CRL extension is also defined as a CRL extension.
-
-      * Throughout the specification, clarifications have been
-      introduced to enhance consistency with the ITU-T X.509
-      specification.  X.509 defines the certificate and CRL format as
-      well as many of the extensions that appear in this specification.
-      These changes were introduced to improve the likelihood of
-      interoperability between implementations based on this
-      specification with implementations based on the ITU-T
-      specification.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119.
-
-2  Requirements and Assumptions
-
-   The goal of this specification is to develop a profile to facilitate
-   the use of X.509 certificates within Internet applications for those
-   communities wishing to make use of X.509 technology.  Such
-   applications may include WWW, electronic mail, user authentication,
-   and IPsec.  In order to relieve some of the obstacles to using X.509
-
-
-
-
-
-
-Housley, et. al.            Standards Track                     [Page 5]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   certificates, this document defines a profile to promote the
-   development of certificate management systems; development of
-   application tools; and interoperability determined by policy.
-
-   Some communities will need to supplement, or possibly replace, this
-   profile in order to meet the requirements of specialized application
-   domains or environments with additional authorization, assurance, or
-   operational requirements.  However, for basic applications, common
-   representations of frequently used attributes are defined so that
-   application developers can obtain necessary information without
-   regard to the issuer of a particular certificate or certificate
-   revocation list (CRL).
-
-   A certificate user should review the certificate policy generated by
-   the certification authority (CA) before relying on the authentication
-   or non-repudiation services associated with the public key in a
-   particular certificate.  To this end, this standard does not
-   prescribe legally binding rules or duties.
-
-   As supplemental authorization and attribute management tools emerge,
-   such as attribute certificates, it may be appropriate to limit the
-   authenticated attributes that are included in a certificate.  These
-   other management tools may provide more appropriate methods of
-   conveying many authenticated attributes.
-
-2.1  Communication and Topology
-
-   The users of certificates will operate in a wide range of
-   environments with respect to their communication topology, especially
-   users of secure electronic mail.  This profile supports users without
-   high bandwidth, real-time IP connectivity, or high connection
-   availability.  In addition, the profile allows for the presence of
-   firewall or other filtered communication.
-
-   This profile does not assume the deployment of an X.500 Directory
-   system or a LDAP directory system.  The profile does not prohibit the
-   use of an X.500 Directory or a LDAP directory; however, any means of
-   distributing certificates and certificate revocation lists (CRLs) may
-   be used.
-
-2.2  Acceptability Criteria
-
-   The goal of the Internet Public Key Infrastructure (PKI) is to meet
-   the needs of deterministic, automated identification, authentication,
-   access control, and authorization functions.  Support for these
-   services determines the attributes contained in the certificate as
-   well as the ancillary control information in the certificate such as
-   policy data and certification path constraints.
-
-
-
-Housley, et. al.            Standards Track                     [Page 6]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-2.3  User Expectations
-
-   Users of the Internet PKI are people and processes who use client
-   software and are the subjects named in certificates.  These uses
-   include readers and writers of electronic mail, the clients for WWW
-   browsers, WWW servers, and the key manager for IPsec within a router.
-   This profile recognizes the limitations of the platforms these users
-   employ and the limitations in sophistication and attentiveness of the
-   users themselves.  This manifests itself in minimal user
-   configuration responsibility (e.g., trusted CA keys, rules), explicit
-   platform usage constraints within the certificate, certification path
-   constraints which shield the user from many malicious actions, and
-   applications which sensibly automate validation functions.
-
-2.4  Administrator Expectations
-
-   As with user expectations, the Internet PKI profile is structured to
-   support the individuals who generally operate CAs.  Providing
-   administrators with unbounded choices increases the chances that a
-   subtle CA administrator mistake will result in broad compromise.
-   Also, unbounded choices greatly complicate the software that process
-   and validate the certificates created by the CA.
-
-3  Overview of Approach
-
-   Following is a simplified view of the architectural model assumed by
-   the PKIX specifications.
-
-   The components in this model are:
-
-   end entity: user of PKI certificates and/or end user system that is
-               the subject of a certificate;
-   CA:         certification authority;
-   RA:         registration authority, i.e., an optional system to which
-               a CA delegates certain management functions;
-   CRL issuer: an optional system to which a CA delegates the
-               publication of certificate revocation lists;
-   repository: a system or collection of distributed systems that stores
-               certificates and CRLs and serves as a means of
-               distributing these certificates and CRLs to end entities.
-
-   Note that an Attribute Authority (AA) might also choose to delegate
-   the publication of CRLs to a CRL issuer.
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                     [Page 7]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   +---+
-   | C |                       +------------+
-   | e | <-------------------->| End entity |
-   | r |       Operational     +------------+
-   | t |       transactions          ^
-   | i |      and management         |  Management
-   | f |       transactions          |  transactions        PKI
-   | i |                             |                     users
-   | c |                             v
-   | a | =======================  +--+------------+  ==============
-   | t |                          ^               ^
-   | e |                          |               |         PKI
-   |   |                          v               |      management
-   | & |                       +------+           |       entities
-   |   | <---------------------|  RA  |<----+     |
-   | C |  Publish certificate  +------+     |     |
-   | R |                                    |     |
-   | L |                                    |     |
-   |   |                                    v     v
-   | R |                                +------------+
-   | e | <------------------------------|     CA     |
-   | p |   Publish certificate          +------------+
-   | o |   Publish CRL                     ^      ^
-   | s |                                   |      |  Management
-   | i |                +------------+     |      |  transactions
-   | t | <--------------| CRL Issuer |<----+      |
-   | o |   Publish CRL  +------------+            v
-   | r |                                      +------+
-   | y |                                      |  CA  |
-   +---+                                      +------+
-
-                      Figure 1 - PKI Entities
-
-3.1  X.509 Version 3 Certificate
-
-   Users of a public key require confidence that the associated private
-   key is owned by the correct remote subject (person or system) with
-   which an encryption or digital signature mechanism will be used.
-   This confidence is obtained through the use of public key
-   certificates, which are data structures that bind public key values
-   to subjects.  The binding is asserted by having a trusted CA
-   digitally sign each certificate.  The CA may base this assertion upon
-   technical means (a.k.a., proof of possession through a challenge-
-   response protocol), presentation of the private key, or on an
-   assertion by the subject.  A certificate has a limited valid lifetime
-   which is indicated in its signed contents.  Because a certificate's
-   signature and timeliness can be independently checked by a
-   certificate-using client, certificates can be distributed via
-
-
-
-Housley, et. al.            Standards Track                     [Page 8]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   untrusted communications and server systems, and can be cached in
-   unsecured storage in certificate-using systems.
-
-   ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first
-   published in 1988 as part of the X.500 Directory recommendations,
-   defines a standard certificate format [X.509].  The certificate
-   format in the 1988 standard is called the version 1 (v1) format.
-   When X.500 was revised in 1993, two more fields were added, resulting
-   in the version 2 (v2) format.
-
-   The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993,
-   include specifications for a public key infrastructure based on X.509
-   v1 certificates [RFC 1422].  The experience gained in attempts to
-   deploy RFC 1422 made it clear that the v1 and v2 certificate formats
-   are deficient in several respects.  Most importantly, more fields
-   were needed to carry information which PEM design and implementation
-   experience had proven necessary.  In response to these new
-   requirements, ISO/IEC, ITU-T and ANSI X9 developed the X.509 version
-   3 (v3) certificate format.  The v3 format extends the v2 format by
-   adding provision for additional extension fields.  Particular
-   extension field types may be specified in standards or may be defined
-   and registered by any organization or community.  In June 1996,
-   standardization of the basic v3 format was completed [X.509].
-
-   ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions
-   for use in the v3 extensions field [X.509][X9.55].  These extensions
-   can convey such data as additional subject identification
-   information, key attribute information, policy information, and
-   certification path constraints.
-
-   However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very
-   broad in their applicability.  In order to develop interoperable
-   implementations of X.509 v3 systems for Internet use, it is necessary
-   to specify a profile for use of the X.509 v3 extensions tailored for
-   the Internet.  It is one goal of this document to specify a profile
-   for Internet WWW, electronic mail, and IPsec applications.
-   Environments with additional requirements may build on this profile
-   or may replace it.
-
-3.2  Certification Paths and Trust
-
-   A user of a security service requiring knowledge of a public key
-   generally needs to obtain and validate a certificate containing the
-   required public key.  If the public key user does not already hold an
-   assured copy of the public key of the CA that signed the certificate,
-   the CA's name, and related information (such as the validity period
-   or name constraints), then it might need an additional certificate to
-   obtain that public key.  In general, a chain of multiple certificates
-
-
-
-Housley, et. al.            Standards Track                     [Page 9]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   may be needed, comprising a certificate of the public key owner (the
-   end entity) signed by one CA, and zero or more additional
-   certificates of CAs signed by other CAs.  Such chains, called
-   certification paths, are required because a public key user is only
-   initialized with a limited number of assured CA public keys.
-
-   There are different ways in which CAs might be configured in order
-   for public key users to be able to find certification paths.  For
-   PEM, RFC 1422 defined a rigid hierarchical structure of CAs.  There
-   are three types of PEM certification authority:
-
-      (a)  Internet Policy Registration Authority (IPRA):  This
-      authority, operated under the auspices of the Internet Society,
-      acts as the root of the PEM certification hierarchy at level 1.
-      It issues certificates only for the next level of authorities,
-      PCAs.  All certification paths start with the IPRA.
-
-      (b)  Policy Certification Authorities (PCAs):  PCAs are at level 2
-      of the hierarchy, each PCA being certified by the IPRA.  A PCA
-      shall establish and publish a statement of its policy with respect
-      to certifying users or subordinate certification authorities.
-      Distinct PCAs aim to satisfy different user needs.  For example,
-      one PCA (an organizational PCA) might support the general
-      electronic mail needs of commercial organizations, and another PCA
-      (a high-assurance PCA) might have a more stringent policy designed
-      for satisfying legally binding digital signature requirements.
-
-      (c)  Certification Authorities (CAs):  CAs are at level 3 of the
-      hierarchy and can also be at lower levels.  Those at level 3 are
-      certified by PCAs.  CAs represent, for example, particular
-      organizations, particular organizational units (e.g., departments,
-      groups, sections), or particular geographical areas.
-
-   RFC 1422 furthermore has a name subordination rule which requires
-   that a CA can only issue certificates for entities whose names are
-   subordinate (in the X.500 naming tree) to the name of the CA itself.
-   The trust associated with a PEM certification path is implied by the
-   PCA name.  The name subordination rule ensures that CAs below the PCA
-   are sensibly constrained as to the set of subordinate entities they
-   can certify (e.g., a CA for an organization can only certify entities
-   in that organization's name tree).  Certificate user systems are able
-   to mechanically check that the name subordination rule has been
-   followed.
-
-   The RFC 1422 uses the X.509 v1 certificate formats.  The limitations
-   of X.509 v1 required imposition of several structural restrictions to
-   clearly associate policy information or restrict the utility of
-   certificates.  These restrictions included:
-
-
-
-Housley, et. al.            Standards Track                    [Page 10]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (a)  a pure top-down hierarchy, with all certification paths
-      starting from IPRA;
-
-      (b)  a naming subordination rule restricting the names of a CA's
-      subjects; and
-
-      (c)  use of the PCA concept, which requires knowledge of
-      individual PCAs to be built into certificate chain verification
-      logic.  Knowledge of individual PCAs was required to determine if
-      a chain could be accepted.
-
-   With X.509 v3, most of the requirements addressed by RFC 1422 can be
-   addressed using certificate extensions, without a need to restrict
-   the CA structures used.  In particular, the certificate extensions
-   relating to certificate policies obviate the need for PCAs and the
-   constraint extensions obviate the need for the name subordination
-   rule.  As a result, this document supports a more flexible
-   architecture, including:
-
-      (a)  Certification paths start with a public key of a CA in a
-      user's own domain, or with the public key of the top of a
-      hierarchy.  Starting with the public key of a CA in a user's own
-      domain has certain advantages.  In some environments, the local
-      domain is the most trusted.
-
-      (b)  Name constraints may be imposed through explicit inclusion of
-      a name constraints extension in a certificate, but are not
-      required.
-
-      (c)  Policy extensions and policy mappings replace the PCA
-      concept, which permits a greater degree of automation.  The
-      application can determine if the certification path is acceptable
-      based on the contents of the certificates instead of a priori
-      knowledge of PCAs.  This permits automation of certification path
-      processing.
-
-3.3  Revocation
-
-   When a certificate is issued, it is expected to be in use for its
-   entire validity period.  However, various circumstances may cause a
-   certificate to become invalid prior to the expiration of the validity
-   period.  Such circumstances include change of name, change of
-   association between subject and CA (e.g., an employee terminates
-   employment with an organization), and compromise or suspected
-   compromise of the corresponding private key.  Under such
-   circumstances, the CA needs to revoke the certificate.
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 11]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   X.509 defines one method of certificate revocation.  This method
-   involves each CA periodically issuing a signed data structure called
-   a certificate revocation list (CRL).  A CRL is a time stamped list
-   identifying revoked certificates which is signed by a CA or CRL
-   issuer and made freely available in a public repository.  Each
-   revoked certificate is identified in a CRL by its certificate serial
-   number.  When a certificate-using system uses a certificate (e.g.,
-   for verifying a remote user's digital signature), that system not
-   only checks the certificate signature and validity but also acquires
-   a suitably-recent CRL and checks that the certificate serial number
-   is not on that CRL.  The meaning of "suitably-recent" may vary with
-   local policy, but it usually means the most recently-issued CRL.  A
-   new CRL is issued on a regular periodic basis (e.g., hourly, daily,
-   or weekly).  An entry is added to the CRL as part of the next update
-   following notification of revocation.  An entry MUST NOT be removed
-   from the CRL until it appears on one regularly scheduled CRL issued
-   beyond the revoked certificate's validity period.
-
-   An advantage of this revocation method is that CRLs may be
-   distributed by exactly the same means as certificates themselves,
-   namely, via untrusted servers and untrusted communications.
-
-   One limitation of the CRL revocation method, using untrusted
-   communications and servers, is that the time granularity of
-   revocation is limited to the CRL issue period.  For example, if a
-   revocation is reported now, that revocation will not be reliably
-   notified to certificate-using systems until all currently issued CRLs
-   are updated -- this may be up to one hour, one day, or one week
-   depending on the frequency that CRLs are issued.
-
-   As with the X.509 v3 certificate format, in order to facilitate
-   interoperable implementations from multiple vendors, the X.509 v2 CRL
-   format needs to be profiled for Internet use.  It is one goal of this
-   document to specify that profile.  However, this profile does not
-   require the issuance of CRLs.  Message formats and protocols
-   supporting on-line revocation notification are defined in other PKIX
-   specifications.  On-line methods of revocation notification may be
-   applicable in some environments as an alternative to the X.509 CRL.
-   On-line revocation checking may significantly reduce the latency
-   between a revocation report and the distribution of the information
-   to relying parties.  Once the CA accepts a revocation report as
-   authentic and valid, any query to the on-line service will correctly
-   reflect the certificate validation impacts of the revocation.
-   However, these methods impose new security requirements: the
-   certificate validator needs to trust the on-line validation service
-   while the repository does not need to be trusted.
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 12]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-3.4  Operational Protocols
-
-   Operational protocols are required to deliver certificates and CRLs
-   (or status information) to certificate using client systems.
-   Provisions are needed for a variety of different means of certificate
-   and CRL delivery, including distribution procedures based on LDAP,
-   HTTP, FTP, and X.500.  Operational protocols supporting these
-   functions are defined in other PKIX specifications.  These
-   specifications may include definitions of message formats and
-   procedures for supporting all of the above operational environments,
-   including definitions of or references to appropriate MIME content
-   types.
-
-3.5  Management Protocols
-
-   Management protocols are required to support on-line interactions
-   between PKI user and management entities.  For example, a management
-   protocol might be used between a CA and a client system with which a
-   key pair is associated, or between two CAs which cross-certify each
-   other.  The set of functions which potentially need to be supported
-   by management protocols include:
-
-      (a)  registration:  This is the process whereby a user first makes
-      itself known to a CA (directly, or through an RA), prior to that
-      CA issuing  a certificate or certificates for that user.
-
-      (b)  initialization:  Before a client system can operate securely
-      it is necessary to install key materials which have the
-      appropriate relationship with keys stored elsewhere in the
-      infrastructure.  For example, the client needs to be securely
-      initialized with the public key and other assured information of
-      the trusted CA(s), to be used in validating certificate paths.
-
-      Furthermore, a client typically needs to be initialized with its
-      own key pair(s).
-
-      (c)  certification:  This is the process in which a CA issues a
-      certificate for a user's public key, and returns that certificate
-      to the user's client system and/or posts that certificate in a
-      repository.
-
-      (d)  key pair recovery:  As an option, user client key materials
-      (e.g., a user's private key used for encryption purposes) may be
-      backed up by a CA or a key backup system.  If a user needs to
-      recover these backed up key materials (e.g., as a result of a
-      forgotten password or a lost key chain file), an on-line protocol
-      exchange may be needed to support such recovery.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 13]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (e)  key pair update:  All key pairs need to be updated regularly,
-      i.e., replaced with a new key pair, and new certificates issued.
-
-      (f)  revocation request:  An authorized person advises a CA of an
-      abnormal situation requiring certificate revocation.
-
-      (g)  cross-certification:  Two CAs exchange information used in
-      establishing a cross-certificate.  A cross-certificate is a
-      certificate issued by one CA to another CA which contains a CA
-      signature key used for issuing certificates.
-
-   Note that on-line protocols are not the only way of implementing the
-   above functions.  For all functions there are off-line methods of
-   achieving the same result, and this specification does not mandate
-   use of on-line protocols.  For example, when hardware tokens are
-   used, many of the functions may be achieved as part of the physical
-   token delivery.  Furthermore, some of the above functions may be
-   combined into one protocol exchange.  In particular, two or more of
-   the registration, initialization, and certification functions can be
-   combined into one protocol exchange.
-
-   The PKIX series of specifications defines a set of standard message
-   formats supporting the above functions.  The protocols for conveying
-   these messages in different environments (e.g., e-mail, file
-   transfer, and WWW) are described in those specifications.
-
-4  Certificate and Certificate Extensions Profile
-
-   This section presents a profile for public key certificates that will
-   foster interoperability and a reusable PKI.  This section is based
-   upon the X.509 v3 certificate format and the standard certificate
-   extensions defined in [X.509].  The ISO/IEC and ITU-T documents use
-   the 1997 version of ASN.1; while this document uses the 1988 ASN.1
-   syntax, the encoded certificate and standard extensions are
-   equivalent.  This section also defines private extensions required to
-   support a PKI for the Internet community.
-
-   Certificates may be used in a wide range of applications and
-   environments covering a broad spectrum of interoperability goals and
-   a broader spectrum of operational and assurance requirements.  The
-   goal of this document is to establish a common baseline for generic
-   applications requiring broad interoperability and limited special
-   purpose requirements.  In particular, the emphasis will be on
-   supporting the use of X.509 v3 certificates for informal Internet
-   electronic mail, IPsec, and WWW applications.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 14]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.1  Basic Certificate Fields
-
-   The X.509 v3 certificate basic syntax is as follows.  For signature
-   calculation, the data that is to be signed is encoded using the ASN.1
-   distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a
-   tag, length, value encoding system for each element.
-
-   Certificate  ::=  SEQUENCE  {
-        tbsCertificate       TBSCertificate,
-        signatureAlgorithm   AlgorithmIdentifier,
-        signatureValue       BIT STRING  }
-
-   TBSCertificate  ::=  SEQUENCE  {
-        version         [0]  EXPLICIT Version DEFAULT v1,
-        serialNumber         CertificateSerialNumber,
-        signature            AlgorithmIdentifier,
-        issuer               Name,
-        validity             Validity,
-        subject              Name,
-        subjectPublicKeyInfo SubjectPublicKeyInfo,
-        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
-                             -- If present, version MUST be v2 or v3
-        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
-                             -- If present, version MUST be v2 or v3
-        extensions      [3]  EXPLICIT Extensions OPTIONAL
-                             -- If present, version MUST be v3
-        }
-
-   Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }
-
-   CertificateSerialNumber  ::=  INTEGER
-
-   Validity ::= SEQUENCE {
-        notBefore      Time,
-        notAfter       Time }
-
-   Time ::= CHOICE {
-        utcTime        UTCTime,
-        generalTime    GeneralizedTime }
-
-   UniqueIdentifier  ::=  BIT STRING
-
-   SubjectPublicKeyInfo  ::=  SEQUENCE  {
-        algorithm            AlgorithmIdentifier,
-        subjectPublicKey     BIT STRING  }
-
-   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 15]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   Extension  ::=  SEQUENCE  {
-        extnID      OBJECT IDENTIFIER,
-        critical    BOOLEAN DEFAULT FALSE,
-        extnValue   OCTET STRING  }
-
-   The following items describe the X.509 v3 certificate for use in the
-   Internet.
-
-4.1.1  Certificate Fields
-
-   The Certificate is a SEQUENCE of three required fields.  The fields
-   are described in detail in the following subsections.
-
-4.1.1.1  tbsCertificate
-
-   The field contains the names of the subject and issuer, a public key
-   associated with the subject, a validity period, and other associated
-   information.  The fields are described in detail in section 4.1.2;
-   the tbsCertificate usually includes extensions which are described in
-   section 4.2.
-
-4.1.1.2  signatureAlgorithm
-
-   The signatureAlgorithm field contains the identifier for the
-   cryptographic algorithm used by the CA to sign this certificate.
-   [PKIXALGS] lists supported signature algorithms, but other signature
-   algorithms MAY also be supported.
-
-   An algorithm identifier is defined by the following ASN.1 structure:
-
-   AlgorithmIdentifier  ::=  SEQUENCE  {
-        algorithm               OBJECT IDENTIFIER,
-        parameters              ANY DEFINED BY algorithm OPTIONAL  }
-
-   The algorithm identifier is used to identify a cryptographic
-   algorithm.  The OBJECT IDENTIFIER component identifies the algorithm
-   (such as DSA with SHA-1).  The contents of the optional parameters
-   field will vary according to the algorithm identified.
-
-   This field MUST contain the same algorithm identifier as the
-   signature field in the sequence tbsCertificate (section 4.1.2.3).
-
-4.1.1.3  signatureValue
-
-   The signatureValue field contains a digital signature computed upon
-   the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
-   tbsCertificate is used as the input to the signature function.  This
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 16]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   signature value is encoded as a BIT STRING and included in the
-   signature field.  The details of this process are specified for each
-   of algorithms listed in [PKIXALGS].
-
-   By generating this signature, a CA certifies the validity of the
-   information in the tbsCertificate field.  In particular, the CA
-   certifies the binding between the public key material and the subject
-   of the certificate.
-
-4.1.2  TBSCertificate
-
-   The sequence TBSCertificate contains information associated with the
-   subject of the certificate and the CA who issued it.  Every
-   TBSCertificate contains the names of the subject and issuer, a public
-   key associated with the subject, a validity period, a version number,
-   and a serial number; some MAY contain optional unique identifier
-   fields.  The remainder of this section describes the syntax and
-   semantics of these fields.  A TBSCertificate usually includes
-   extensions.  Extensions for the Internet PKI are described in Section
-   4.2.
-
-4.1.2.1  Version
-
-   This field describes the version of the encoded certificate.  When
-   extensions are used, as expected in this profile, version MUST be 3
-   (value is 2).  If no extensions are present, but a UniqueIdentifier
-   is present, the version SHOULD be 2 (value is 1); however version MAY
-   be 3.  If only basic fields are present, the version SHOULD be 1 (the
-   value is omitted from the certificate as the default value); however
-   the version MAY be 2 or 3.
-
-   Implementations SHOULD be prepared to accept any version certificate.
-   At a minimum, conforming implementations MUST recognize version 3
-   certificates.
-
-   Generation of version 2 certificates is not expected by
-   implementations based on this profile.
-
-4.1.2.2  Serial number
-
-   The serial number MUST be a positive integer assigned by the CA to
-   each certificate.  It MUST be unique for each certificate issued by a
-   given CA (i.e., the issuer name and serial number identify a unique
-   certificate).  CAs MUST force the serialNumber to be a non-negative
-   integer.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 17]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   Given the uniqueness requirements above, serial numbers can be
-   expected to contain long integers.  Certificate users MUST be able to
-   handle serialNumber values up to 20 octets.  Conformant CAs MUST NOT
-   use serialNumber values longer than 20 octets.
-
-   Note: Non-conforming CAs may issue certificates with serial numbers
-   that are negative, or zero.  Certificate users SHOULD be prepared to
-   gracefully handle such certificates.
-
-4.1.2.3  Signature
-
-   This field contains the algorithm identifier for the algorithm used
-   by the CA to sign the certificate.
-
-   This field MUST contain the same algorithm identifier as the
-   signatureAlgorithm field in the sequence Certificate (section
-   4.1.1.2).  The contents of the optional parameters field will vary
-   according to the algorithm identified.  [PKIXALGS] lists the
-   supported signature algorithms, but other signature algorithms MAY
-   also be supported.
-
-4.1.2.4  Issuer
-
-   The issuer field identifies the entity who has signed and issued the
-   certificate.  The issuer field MUST contain a non-empty distinguished
-   name (DN).  The issuer field is defined as the X.501 type Name
-   [X.501].  Name is defined by the following ASN.1 structures:
-
-   Name ::= CHOICE {
-     RDNSequence }
-
-   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-   RelativeDistinguishedName ::=
-     SET OF AttributeTypeAndValue
-
-   AttributeTypeAndValue ::= SEQUENCE {
-     type     AttributeType,
-     value    AttributeValue }
-
-   AttributeType ::= OBJECT IDENTIFIER
-
-   AttributeValue ::= ANY DEFINED BY AttributeType
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 18]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   DirectoryString ::= CHOICE {
-         teletexString           TeletexString (SIZE (1..MAX)),
-         printableString         PrintableString (SIZE (1..MAX)),
-         universalString         UniversalString (SIZE (1..MAX)),
-         utf8String              UTF8String (SIZE (1..MAX)),
-         bmpString               BMPString (SIZE (1..MAX)) }
-
-   The Name describes a hierarchical name composed of attributes, such
-   as country name, and corresponding values, such as US.  The type of
-   the component AttributeValue is determined by the AttributeType; in
-   general it will be a DirectoryString.
-
-   The DirectoryString type is defined as a choice of PrintableString,
-   TeletexString, BMPString, UTF8String, and UniversalString.  The
-   UTF8String encoding [RFC 2279] is the preferred encoding, and all
-   certificates issued after December 31, 2003 MUST use the UTF8String
-   encoding of DirectoryString (except as noted below).  Until that
-   date, conforming CAs MUST choose from the following options when
-   creating a distinguished name, including their own:
-
-      (a)  if the character set is sufficient, the string MAY be
-      represented as a PrintableString;
-
-      (b)  failing (a), if the BMPString character set is sufficient the
-      string MAY be represented as a BMPString; and
-
-      (c)  failing (a) and (b), the string MUST be represented as a
-      UTF8String.  If (a) or (b) is satisfied, the CA MAY still choose
-      to represent the string as a UTF8String.
-
-   Exceptions to the December 31, 2003 UTF8 encoding requirements are as
-   follows:
-
-      (a)  CAs MAY issue "name rollover" certificates to support an
-      orderly migration to UTF8String encoding.  Such certificates would
-      include the CA's UTF8String encoded name as issuer and and the old
-      name encoding as subject, or vice-versa.
-
-      (b)  As stated in section 4.1.2.6, the subject field MUST be
-      populated with a non-empty distinguished name matching the
-      contents of the issuer field in all certificates issued by the
-      subject CA regardless of encoding.
-
-   The TeletexString and UniversalString are included for backward
-   compatibility, and SHOULD NOT be used for certificates for new
-   subjects.  However, these types MAY be used in certificates where the
-   name was previously established.  Certificate users SHOULD be
-   prepared to receive certificates with these types.
-
-
-
-Housley, et. al.            Standards Track                    [Page 19]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   In addition, many legacy implementations support names encoded in the
-   ISO 8859-1 character set (Latin1String) [ISO 8859-1] but tag them as
-   TeletexString.  TeletexString encodes a larger character set than ISO
-   8859-1, but it encodes some characters differently.  Implementations
-   SHOULD be prepared to handle both encodings.
-
-   As noted above, distinguished names are composed of attributes.  This
-   specification does not restrict the set of attribute types that may
-   appear in names.  However, conforming implementations MUST be
-   prepared to receive certificates with issuer names containing the set
-   of attribute types defined below.  This specification RECOMMENDS
-   support for additional attribute types.
-
-   Standard sets of attributes have been defined in the X.500 series of
-   specifications [X.520].  Implementations of this specification MUST
-   be prepared to receive the following standard attribute types in
-   issuer and subject (section 4.1.2.6) names:
-
-      * country,
-      * organization,
-      * organizational-unit,
-      * distinguished name qualifier,
-      * state or province name,
-      * common name (e.g., "Susan Housley"), and
-      * serial number.
-
-   In addition, implementations of this specification SHOULD be prepared
-   to receive the following standard attribute types in issuer and
-   subject names:
-
-      * locality,
-      * title,
-      * surname,
-      * given name,
-      * initials,
-      * pseudonym, and
-      * generation qualifier (e.g., "Jr.", "3rd", or "IV").
-
-   The syntax and associated object identifiers (OIDs) for these
-   attribute types are provided in the ASN.1 modules in Appendix A.
-
-   In addition, implementations of this specification MUST be prepared
-   to receive the domainComponent attribute, as defined in [RFC 2247].
-   The Domain Name System (DNS) provides a hierarchical resource
-   labeling system.  This attribute provides a convenient mechanism for
-   organizations that wish to use DNs that parallel their DNS names.
-   This is not a replacement for the dNSName component of the
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 20]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   alternative name field.  Implementations are not required to convert
-   such names into DNS names.  The syntax and associated OID for this
-   attribute type is provided in the ASN.1 modules in Appendix A.
-
-   Certificate users MUST be prepared to process the issuer
-   distinguished name and subject distinguished name (section 4.1.2.6)
-   fields to perform name chaining for certification path validation
-   (section 6).  Name chaining is performed by matching the issuer
-   distinguished name in one certificate with the subject name in a CA
-   certificate.
-
-   This specification requires only a subset of the name comparison
-   functionality specified in the X.500 series of specifications.
-   Conforming implementations are REQUIRED to implement the following
-   name comparison rules:
-
-      (a)  attribute values encoded in different types (e.g.,
-      PrintableString and BMPString) MAY be assumed to represent
-      different strings;
-
-      (b) attribute values in types other than PrintableString are case
-      sensitive (this permits matching of attribute values as binary
-      objects);
-
-      (c)  attribute values in PrintableString are not case sensitive
-      (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and
-
-      (d)  attribute values in PrintableString are compared after
-      removing leading and trailing white space and converting internal
-      substrings of one or more consecutive white space characters to a
-      single space.
-
-   These name comparison rules permit a certificate user to validate
-   certificates issued using languages or encodings unfamiliar to the
-   certificate user.
-
-   In addition, implementations of this specification MAY use these
-   comparison rules to process unfamiliar attribute types for name
-   chaining.  This allows implementations to process certificates with
-   unfamiliar attributes in the issuer name.
-
-   Note that the comparison rules defined in the X.500 series of
-   specifications indicate that the character sets used to encode data
-   in distinguished names are irrelevant.  The characters themselves are
-   compared without regard to encoding.  Implementations of this profile
-   are permitted to use the comparison algorithm defined in the X.500
-   series.  Such an implementation will recognize a superset of name
-   matches recognized by the algorithm specified above.
-
-
-
-Housley, et. al.            Standards Track                    [Page 21]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.1.2.5  Validity
-
-   The certificate validity period is the time interval during which the
-   CA warrants that it will maintain information about the status of the
-   certificate.  The field is represented as a SEQUENCE of two dates:
-   the date on which the certificate validity period begins (notBefore)
-   and the date on which the certificate validity period ends
-   (notAfter).  Both notBefore and notAfter may be encoded as UTCTime or
-   GeneralizedTime.
-
-   CAs conforming to this profile MUST always encode certificate
-   validity dates through the year 2049 as UTCTime; certificate validity
-   dates in 2050 or later MUST be encoded as GeneralizedTime.
-
-   The validity period for a certificate is the period of time from
-   notBefore through notAfter, inclusive.
-
-4.1.2.5.1  UTCTime
-
-   The universal time type, UTCTime, is a standard ASN.1 type intended
-   for representation of dates and time.  UTCTime specifies the year
-   through the two low order digits and time is specified to the
-   precision of one minute or one second.  UTCTime includes either Z
-   (for Zulu, or Greenwich Mean Time) or a time differential.
-
-   For the purposes of this profile, UTCTime values MUST be expressed
-   Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
-   YYMMDDHHMMSSZ), even where the number of seconds is zero.  Conforming
-   systems MUST interpret the year field (YY) as follows:
-
-      Where YY is greater than or equal to 50, the year SHALL be
-      interpreted as 19YY; and
-
-      Where YY is less than 50, the year SHALL be interpreted as 20YY.
-
-4.1.2.5.2  GeneralizedTime
-
-   The generalized time type, GeneralizedTime, is a standard ASN.1 type
-   for variable precision representation of time.  Optionally, the
-   GeneralizedTime field can include a representation of the time
-   differential between local and Greenwich Mean Time.
-
-   For the purposes of this profile, GeneralizedTime values MUST be
-   expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
-   times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
-   GeneralizedTime values MUST NOT include fractional seconds.
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 22]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.1.2.6  Subject
-
-   The subject field identifies the entity associated with the public
-   key stored in the subject public key field.  The subject name MAY be
-   carried in the subject field and/or the subjectAltName extension.  If
-   the subject is a CA (e.g., the basic constraints extension, as
-   discussed in 4.2.1.10, is present and the value of cA is TRUE), then
-   the subject field MUST be populated with a non-empty distinguished
-   name matching the contents of the issuer field (section 4.1.2.4) in
-   all certificates issued by the subject CA.  If the subject is a CRL
-   issuer (e.g., the key usage extension, as discussed in 4.2.1.3, is
-   present and the value of cRLSign is TRUE) then the subject field MUST
-   be populated with a non-empty distinguished name matching the
-   contents of the issuer field (section 4.1.2.4) in all CRLs issued by
-   the subject CRL issuer.  If subject naming information is present
-   only in the subjectAltName extension (e.g., a key bound only to an
-   email address or URI), then the subject name MUST be an empty
-   sequence and the subjectAltName extension MUST be critical.
-
-   Where it is non-empty, the subject field MUST contain an X.500
-   distinguished name (DN).  The DN MUST be unique for each subject
-   entity certified by the one CA as defined by the issuer name field.
-   A CA MAY issue more than one certificate with the same DN to the same
-   subject entity.
-
-   The subject name field is defined as the X.501 type Name.
-   Implementation requirements for this field are those defined for the
-   issuer field (section 4.1.2.4).  When encoding attribute values of
-   type DirectoryString, the encoding rules for the issuer field MUST be
-   implemented.  Implementations of this specification MUST be prepared
-   to receive subject names containing the attribute types required for
-   the issuer field.  Implementations of this specification SHOULD be
-   prepared to receive subject names containing the recommended
-   attribute types for the issuer field.  The syntax and associated
-   object identifiers (OIDs) for these attribute types are provided in
-   the ASN.1 modules in Appendix A.  Implementations of this
-   specification MAY use these comparison rules to process unfamiliar
-   attribute types (i.e., for name chaining).  This allows
-   implementations to process certificates with unfamiliar attributes in
-   the subject name.
-
-   In addition, legacy implementations exist where an RFC 822 name is
-   embedded in the subject distinguished name as an EmailAddress
-   attribute.  The attribute value for EmailAddress is of type IA5String
-   to permit inclusion of the character '@', which is not part of the
-   PrintableString character set.  EmailAddress attribute values are not
-   case sensitive (e.g., "fanfeedback@redsox.com" is the same as
-   "FANFEEDBACK@REDSOX.COM").
-
-
-
-Housley, et. al.            Standards Track                    [Page 23]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   Conforming implementations generating new certificates with
-   electronic mail addresses MUST use the rfc822Name in the subject
-   alternative name field (section 4.2.1.7) to describe such identities.
-   Simultaneous inclusion of the EmailAddress attribute in the subject
-   distinguished name to support legacy implementations is deprecated
-   but permitted.
-
-4.1.2.7  Subject Public Key Info
-
-   This field is used to carry the public key and identify the algorithm
-   with which the key is used (e.g., RSA, DSA, or Diffie-Hellman).  The
-   algorithm is identified using the AlgorithmIdentifier structure
-   specified in section 4.1.1.2.  The object identifiers for the
-   supported algorithms and the methods for encoding the public key
-   materials (public key and parameters) are specified in [PKIXALGS].
-
-4.1.2.8  Unique Identifiers
-
-   These fields MUST only appear if the version is 2 or 3 (section
-   4.1.2.1).  These fields MUST NOT appear if the version is 1.  The
-   subject and issuer unique identifiers are present in the certificate
-   to handle the possibility of reuse of subject and/or issuer names
-   over time.  This profile RECOMMENDS that names not be reused for
-   different entities and that Internet certificates not make use of
-   unique identifiers.  CAs conforming to this profile SHOULD NOT
-   generate certificates with unique identifiers.  Applications
-   conforming to this profile SHOULD be capable of parsing unique
-   identifiers.
-
-4.1.2.9  Extensions
-
-   This field MUST only appear if the version is 3 (section 4.1.2.1).
-   If present, this field is a SEQUENCE of one or more certificate
-   extensions.  The format and content of certificate extensions in the
-   Internet PKI is defined in section 4.2.
-
-4.2  Certificate Extensions
-
-   The extensions defined for X.509 v3 certificates provide methods for
-   associating additional attributes with users or public keys and for
-   managing a certification hierarchy.  The X.509 v3 certificate format
-   also allows communities to define private extensions to carry
-   information unique to those communities.  Each extension in a
-   certificate is designated as either critical or non-critical.  A
-   certificate using system MUST reject the certificate if it encounters
-   a critical extension it does not recognize; however, a non-critical
-   extension MAY be ignored if it is not recognized.  The following
-   sections present recommended extensions used within Internet
-
-
-
-Housley, et. al.            Standards Track                    [Page 24]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   certificates and standard locations for information.  Communities may
-   elect to use additional extensions; however, caution ought to be
-   exercised in adopting any critical extensions in certificates which
-   might prevent use in a general context.
-
-   Each extension includes an OID and an ASN.1 structure.  When an
-   extension appears in a certificate, the OID appears as the field
-   extnID and the corresponding ASN.1 encoded structure is the value of
-   the octet string extnValue.  A certificate MUST NOT include more than
-   one instance of a particular extension.  For example, a certificate
-   may contain only one authority key identifier extension (section
-   4.2.1.1).  An extension includes the boolean critical, with a default
-   value of FALSE.  The text for each extension specifies the acceptable
-   values for the critical field.
-
-   Conforming CAs MUST support key identifiers (sections 4.2.1.1 and
-   4.2.1.2), basic constraints (section 4.2.1.10), key usage (section
-   4.2.1.3), and certificate policies (section 4.2.1.5) extensions.  If
-   the CA issues certificates with an empty sequence for the subject
-   field, the CA MUST support the subject alternative name extension
-   (section 4.2.1.7).  Support for the remaining extensions is OPTIONAL.
-   Conforming CAs MAY support extensions that are not identified within
-   this specification; certificate issuers are cautioned that marking
-   such extensions as critical may inhibit interoperability.
-
-   At a minimum, applications conforming to this profile MUST recognize
-   the following extensions: key usage (section 4.2.1.3), certificate
-   policies (section 4.2.1.5), the subject alternative name (section
-   4.2.1.7), basic constraints (section 4.2.1.10), name constraints
-   (section 4.2.1.11), policy constraints (section 4.2.1.12), extended
-   key usage (section 4.2.1.13), and inhibit any-policy (section
-   4.2.1.15).
-
-   In addition, applications conforming to this profile SHOULD recognize
-   the authority and subject key identifier (sections 4.2.1.1 and
-   4.2.1.2), and policy mapping (section 4.2.1.6) extensions.
-
-4.2.1  Standard Extensions
-
-   This section identifies standard certificate extensions defined in
-   [X.509] for use in the Internet PKI.  Each extension is associated
-   with an OID defined in [X.509].  These OIDs are members of the id-ce
-   arc, which is defined by the following:
-
-   id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 25]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.2.1.1  Authority Key Identifier
-
-   The authority key identifier extension provides a means of
-   identifying the public key corresponding to the private key used to
-   sign a certificate.  This extension is used where an issuer has
-   multiple signing keys (either due to multiple concurrent key pairs or
-   due to changeover).  The identification MAY be based on either the
-   key identifier (the subject key identifier in the issuer's
-   certificate) or on the issuer name and serial number.
-
-   The keyIdentifier field of the authorityKeyIdentifier extension MUST
-   be included in all certificates generated by conforming CAs to
-   facilitate certification path construction.  There is one exception;
-   where a CA distributes its public key in the form of a "self-signed"
-   certificate, the authority key identifier MAY be omitted.  The
-   signature on a self-signed certificate is generated with the private
-   key associated with the certificate's subject public key.  (This
-   proves that the issuer possesses both the public and private keys.)
-   In this case, the subject and authority key identifiers would be
-   identical, but only the subject key identifier is needed for
-   certification path building.
-
-   The value of the keyIdentifier field SHOULD be derived from the
-   public key used to verify the certificate's signature or a method
-   that generates unique values.  Two common methods for generating key
-   identifiers from the public key, and one common method for generating
-   unique values, are described in section 4.2.1.2.  Where a key
-   identifier has not been previously established, this specification
-   RECOMMENDS use of one of these methods for generating keyIdentifiers.
-   Where a key identifier has been previously established, the CA SHOULD
-   use the previously established identifier.
-
-   This profile RECOMMENDS support for the key identifier method by all
-   certificate users.
-
-   This extension MUST NOT be marked critical.
-
-   id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }
-
-   AuthorityKeyIdentifier ::= SEQUENCE {
-      keyIdentifier             [0] KeyIdentifier           OPTIONAL,
-      authorityCertIssuer       [1] GeneralNames            OPTIONAL,
-      authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }
-
-   KeyIdentifier ::= OCTET STRING
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 26]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.2.1.2  Subject Key Identifier
-
-   The subject key identifier extension provides a means of identifying
-   certificates that contain a particular public key.
-
-   To facilitate certification path construction, this extension MUST
-   appear in all conforming CA certificates, that is, all certificates
-   including the basic constraints extension (section 4.2.1.10) where
-   the value of cA is TRUE.  The value of the subject key identifier
-   MUST be the value placed in the key identifier field of the Authority
-   Key Identifier extension (section 4.2.1.1) of certificates issued by
-   the subject of this certificate.
-
-   For CA certificates, subject key identifiers SHOULD be derived from
-   the public key or a method that generates unique values.  Two common
-   methods for generating key identifiers from the public key are:
-
-      (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
-      value of the BIT STRING subjectPublicKey (excluding the tag,
-      length, and number of unused bits).
-
-      (2) The keyIdentifier is composed of a four bit type field with
-      the value 0100 followed by the least significant 60 bits of the
-      SHA-1 hash of the value of the BIT STRING subjectPublicKey
-      (excluding the tag, length, and number of unused bit string bits).
-
-   One common method for generating unique values is a monotonically
-   increasing sequence of integers.
-
-   For end entity certificates, the subject key identifier extension
-   provides a means for identifying certificates containing the
-   particular public key used in an application.  Where an end entity
-   has obtained multiple certificates, especially from multiple CAs, the
-   subject key identifier provides a means to quickly identify the set
-   of certificates containing a particular public key.  To assist
-   applications in identifying the appropriate end entity certificate,
-   this extension SHOULD be included in all end entity certificates.
-
-   For end entity certificates, subject key identifiers SHOULD be
-   derived from the public key.  Two common methods for generating key
-   identifiers from the public key are identified above.
-
-   Where a key identifier has not been previously established, this
-   specification RECOMMENDS use of one of these methods for generating
-   keyIdentifiers.  Where a key identifier has been previously
-   established, the CA SHOULD use the previously established identifier.
-
-   This extension MUST NOT be marked critical.
-
-
-
-Housley, et. al.            Standards Track                    [Page 27]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }
-
-   SubjectKeyIdentifier ::= KeyIdentifier
-
-4.2.1.3  Key Usage
-
-   The key usage extension defines the purpose (e.g., encipherment,
-   signature, certificate signing) of the key contained in the
-   certificate.  The usage restriction might be employed when a key that
-   could be used for more than one operation is to be restricted.  For
-   example, when an RSA key should be used only to verify signatures on
-   objects other than public key certificates and CRLs, the
-   digitalSignature and/or nonRepudiation bits would be asserted.
-   Likewise, when an RSA key should be used only for key management, the
-   keyEncipherment bit would be asserted.
-
-   This extension MUST appear in certificates that contain public keys
-   that are used to validate digital signatures on other public key
-   certificates or CRLs.  When this extension appears, it SHOULD be
-   marked critical.
-
-      id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
-
-      KeyUsage ::= BIT STRING {
-           digitalSignature        (0),
-           nonRepudiation          (1),
-           keyEncipherment         (2),
-           dataEncipherment        (3),
-           keyAgreement            (4),
-           keyCertSign             (5),
-           cRLSign                 (6),
-           encipherOnly            (7),
-           decipherOnly            (8) }
-
-   Bits in the KeyUsage type are used as follows:
-
-      The digitalSignature bit is asserted when the subject public key
-      is used with a digital signature mechanism to support security
-      services other than certificate signing (bit 5), or CRL signing
-      (bit 6).  Digital signature mechanisms are often used for entity
-      authentication and data origin authentication with integrity.
-
-      The nonRepudiation bit is asserted when the subject public key is
-      used to verify digital signatures used to provide a non-
-      repudiation service which protects against the signing entity
-      falsely denying some action, excluding certificate or CRL signing.
-      In the case of later conflict, a reliable third party may
-      determine the authenticity of the signed data.
-
-
-
-Housley, et. al.            Standards Track                    [Page 28]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      Further distinctions between the digitalSignature and
-      nonRepudiation bits may be provided in specific certificate
-      policies.
-
-      The keyEncipherment bit is asserted when the subject public key is
-      used for key transport.  For example, when an RSA key is to be
-      used for key management, then this bit is set.
-
-      The dataEncipherment bit is asserted when the subject public key
-      is used for enciphering user data, other than cryptographic keys.
-
-      The keyAgreement bit is asserted when the subject public key is
-      used for key agreement.  For example, when a Diffie-Hellman key is
-      to be used for key management, then this bit is set.
-
-      The keyCertSign bit is asserted when the subject public key is
-      used for verifying a signature on public key certificates.  If the
-      keyCertSign bit is asserted, then the cA bit in the basic
-      constraints extension (section 4.2.1.10) MUST also be asserted.
-
-      The cRLSign bit is asserted when the subject public key is used
-      for verifying a signature on certificate revocation list (e.g., a
-      CRL, delta CRL, or an ARL).  This bit MUST be asserted in
-      certificates that are used to verify signatures on CRLs.
-
-      The meaning of the encipherOnly bit is undefined in the absence of
-      the keyAgreement bit.  When the encipherOnly bit is asserted and
-      the keyAgreement bit is also set, the subject public key may be
-      used only for enciphering data while performing key agreement.
-
-      The meaning of the decipherOnly bit is undefined in the absence of
-      the keyAgreement bit.  When the decipherOnly bit is asserted and
-      the keyAgreement bit is also set, the subject public key may be
-      used only for deciphering data while performing key agreement.
-
-   This profile does not restrict the combinations of bits that may be
-   set in an instantiation of the keyUsage extension.  However,
-   appropriate values for keyUsage extensions for particular algorithms
-   are specified in [PKIXALGS].
-
-4.2.1.4  Private Key Usage Period
-
-   This extension SHOULD NOT be used within the Internet PKI.  CAs
-   conforming to this profile MUST NOT generate certificates that
-   include a critical private key usage period extension.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 29]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   The private key usage period extension allows the certificate issuer
-   to specify a different validity period for the private key than the
-   certificate.  This extension is intended for use with digital
-   signature keys.  This extension consists of two optional components,
-   notBefore and notAfter.  The private key associated with the
-   certificate SHOULD NOT be used to sign objects before or after the
-   times specified by the two components, respectively.  CAs conforming
-   to this profile MUST NOT generate certificates with private key usage
-   period extensions unless at least one of the two components is
-   present and the extension is non-critical.
-
-   Where used, notBefore and notAfter are represented as GeneralizedTime
-   and MUST be specified and interpreted as defined in section
-   4.1.2.5.2.
-
-   id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::=  { id-ce 16 }
-
-   PrivateKeyUsagePeriod ::= SEQUENCE {
-        notBefore       [0]     GeneralizedTime OPTIONAL,
-        notAfter        [1]     GeneralizedTime OPTIONAL }
-
-4.2.1.5  Certificate Policies
-
-   The certificate policies extension contains a sequence of one or more
-   policy information terms, each of which consists of an object
-   identifier (OID) and optional qualifiers.  Optional qualifiers, which
-   MAY be present, are not expected to change the definition of the
-   policy.
-
-   In an end entity certificate, these policy information terms indicate
-   the policy under which the certificate has been issued and the
-   purposes for which the certificate may be used.  In a CA certificate,
-   these policy information terms limit the set of policies for
-   certification paths which include this certificate.  When a CA does
-   not wish to limit the set of policies for certification paths which
-   include this certificate, it MAY assert the special policy anyPolicy,
-   with a value of { 2 5 29 32 0 }.
-
-   Applications with specific policy requirements are expected to have a
-   list of those policies which they will accept and to compare the
-   policy OIDs in the certificate to that list.  If this extension is
-   critical, the path validation software MUST be able to interpret this
-   extension (including the optional qualifier), or MUST reject the
-   certificate.
-
-   To promote interoperability, this profile RECOMMENDS that policy
-   information terms consist of only an OID.  Where an OID alone is
-   insufficient, this profile strongly recommends that use of qualifiers
-
-
-
-Housley, et. al.            Standards Track                    [Page 30]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   be limited to those identified in this section.  When qualifiers are
-   used with the special policy anyPolicy, they MUST be limited to the
-   qualifiers identified in this section.
-
-   This specification defines two policy qualifier types for use by
-   certificate policy writers and certificate issuers.  The qualifier
-   types are the CPS Pointer and User Notice qualifiers.
-
-   The CPS Pointer qualifier contains a pointer to a Certification
-   Practice Statement (CPS) published by the CA.  The pointer is in the
-   form of a URI.  Processing requirements for this qualifier are a
-   local matter.  No action is mandated by this specification regardless
-   of the criticality value asserted for the extension.
-
-   User notice is intended for display to a relying party when a
-   certificate is used.  The application software SHOULD display all
-   user notices in all certificates of the certification path used,
-   except that if a notice is duplicated only one copy need be
-   displayed.  To prevent such duplication, this qualifier SHOULD only
-   be present in end entity certificates and CA certificates issued to
-   other organizations.
-
-   The user notice has two optional fields: the noticeRef field and the
-   explicitText field.
-
-      The noticeRef field, if used, names an organization and
-      identifies, by number, a particular textual statement prepared by
-      that organization.  For example, it might identify the
-      organization "CertsRUs" and notice number 1.  In a typical
-      implementation, the application software will have a notice file
-      containing the current set of notices for CertsRUs; the
-      application will extract the notice text from the file and display
-      it.  Messages MAY be multilingual, allowing the software to select
-      the particular language message for its own environment.
-
-      An explicitText field includes the textual statement directly in
-      the certificate.  The explicitText field is a string with a
-      maximum size of 200 characters.
-
-   If both the noticeRef and explicitText options are included in the
-   one qualifier and if the application software can locate the notice
-   text indicated by the noticeRef option, then that text SHOULD be
-   displayed; otherwise, the explicitText string SHOULD be displayed.
-
-   Note: While the explicitText has a maximum size of 200 characters,
-   some non-conforming CAs exceed this limit.  Therefore, certificate
-   users SHOULD gracefully handle explicitText with more than 200
-   characters.
-
-
-
-Housley, et. al.            Standards Track                    [Page 31]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }
-
-   anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }
-
-   certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
-
-   PolicyInformation ::= SEQUENCE {
-        policyIdentifier   CertPolicyId,
-        policyQualifiers   SEQUENCE SIZE (1..MAX) OF
-                                PolicyQualifierInfo OPTIONAL }
-
-   CertPolicyId ::= OBJECT IDENTIFIER
-
-   PolicyQualifierInfo ::= SEQUENCE {
-        policyQualifierId  PolicyQualifierId,
-        qualifier          ANY DEFINED BY policyQualifierId }
-
-   -- policyQualifierIds for Internet policy qualifiers
-
-   id-qt          OBJECT IDENTIFIER ::=  { id-pkix 2 }
-   id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
-   id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }
-
-   PolicyQualifierId ::=
-        OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
-
-   Qualifier ::= CHOICE {
-        cPSuri           CPSuri,
-        userNotice       UserNotice }
-
-   CPSuri ::= IA5String
-
-   UserNotice ::= SEQUENCE {
-        noticeRef        NoticeReference OPTIONAL,
-        explicitText     DisplayText OPTIONAL}
-
-   NoticeReference ::= SEQUENCE {
-        organization     DisplayText,
-        noticeNumbers    SEQUENCE OF INTEGER }
-
-   DisplayText ::= CHOICE {
-        ia5String        IA5String      (SIZE (1..200)),
-        visibleString    VisibleString  (SIZE (1..200)),
-        bmpString        BMPString      (SIZE (1..200)),
-        utf8String       UTF8String     (SIZE (1..200)) }
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 32]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.2.1.6  Policy Mappings
-
-   This extension is used in CA certificates.  It lists one or more
-   pairs of OIDs; each pair includes an issuerDomainPolicy and a
-   subjectDomainPolicy.  The pairing indicates the issuing CA considers
-   its issuerDomainPolicy equivalent to the subject CA's
-   subjectDomainPolicy.
-
-   The issuing CA's users might accept an issuerDomainPolicy for certain
-   applications.  The policy mapping defines the list of policies
-   associated with the subject CA that may be accepted as comparable to
-   the issuerDomainPolicy.
-
-   Each issuerDomainPolicy named in the policy mapping extension SHOULD
-   also be asserted in a certificate policies extension in the same
-   certificate.  Policies SHOULD NOT be mapped either to or from the
-   special value anyPolicy (section 4.2.1.5).
-
-   This extension MAY be supported by CAs and/or applications, and it
-   MUST be non-critical.
-
-   id-ce-policyMappings OBJECT IDENTIFIER ::=  { id-ce 33 }
-
-   PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-        issuerDomainPolicy      CertPolicyId,
-        subjectDomainPolicy     CertPolicyId }
-
-4.2.1.7  Subject Alternative Name
-
-   The subject alternative names extension allows additional identities
-   to be bound to the subject of the certificate.  Defined options
-   include an Internet electronic mail address, a DNS name, an IP
-   address, and a uniform resource identifier (URI).  Other options
-   exist, including completely local definitions.  Multiple name forms,
-   and multiple instances of each name form, MAY be included.  Whenever
-   such identities are to be bound into a certificate, the subject
-   alternative name (or issuer alternative name) extension MUST be used;
-   however, a DNS name MAY be represented in the subject field using the
-   domainComponent attribute as described in section 4.1.2.4.
-
-   Because the subject alternative name is considered to be definitively
-   bound to the public key, all parts of the subject alternative name
-   MUST be verified by the CA.
-
-   Further, if the only subject identity included in the certificate is
-   an alternative name form (e.g., an electronic mail address), then the
-   subject distinguished name MUST be empty (an empty sequence), and the
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 33]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   subjectAltName extension MUST be present.  If the subject field
-   contains an empty sequence, the subjectAltName extension MUST be
-   marked critical.
-
-   When the subjectAltName extension contains an Internet mail address,
-   the address MUST be included as an rfc822Name.  The format of an
-   rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822].  An
-   addr-spec has the form "local-part@domain".  Note that an addr-spec
-   has no phrase (such as a common name) before it, has no comment (text
-   surrounded in parentheses) after it, and is not surrounded by "<" and
-   ">".  Note that while upper and lower case letters are allowed in an
-   RFC 822 addr-spec, no significance is attached to the case.
-
-   When the subjectAltName extension contains a iPAddress, the address
-   MUST be stored in the octet string in "network byte order," as
-   specified in RFC 791 [RFC 791].  The least significant bit (LSB) of
-   each octet is the LSB of the corresponding byte in the network
-   address.  For IP Version 4, as specified in RFC 791, the octet string
-   MUST contain exactly four octets.  For IP Version 6, as specified in
-   RFC 1883, the octet string MUST contain exactly sixteen octets [RFC
-   1883].
-
-   When the subjectAltName extension contains a domain name system
-   label, the domain name MUST be stored in the dNSName (an IA5String).
-   The name MUST be in the "preferred name syntax," as specified by RFC
-   1034 [RFC 1034].  Note that while upper and lower case letters are
-   allowed in domain names, no signifigance is attached to the case.  In
-   addition, while the string " " is a legal domain name, subjectAltName
-   extensions with a dNSName of " " MUST NOT be used.  Finally, the use
-   of the DNS representation for Internet mail addresses (wpolk.nist.gov
-   instead of wpolk@nist.gov) MUST NOT be used; such identities are to
-   be encoded as rfc822Name.
-
-   Note: work is currently underway to specify domain names in
-   international character sets.  Such names will likely not be
-   accommodated by IA5String.  Once this work is complete, this profile
-   will be revisited and the appropriate functionality will be added.
-
-   When the subjectAltName extension contains a URI, the name MUST be
-   stored in the uniformResourceIdentifier (an IA5String).  The name
-   MUST NOT be a relative URL, and it MUST follow the URL syntax and
-   encoding rules specified in [RFC 1738].  The name MUST include both a
-   scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
-   scheme-specific-part MUST include a fully qualified domain name or IP
-   address as the host.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 34]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   As specified in [RFC 1738], the scheme name is not case-sensitive
-   (e.g., "http" is equivalent to "HTTP").  The host part is also not
-   case-sensitive, but other components of the scheme-specific-part may
-   be case-sensitive.  When comparing URIs, conforming implementations
-   MUST compare the scheme and host without regard to case, but assume
-   the remainder of the scheme-specific-part is case sensitive.
-
-   When the subjectAltName extension contains a DN in the directoryName,
-   the DN MUST be unique for each subject entity certified by the one CA
-   as defined by the issuer name field.  A CA MAY issue more than one
-   certificate with the same DN to the same subject entity.
-
-   The subjectAltName MAY carry additional name types through the use of
-   the otherName field.  The format and semantics of the name are
-   indicated through the OBJECT IDENTIFIER in the type-id field.  The
-   name itself is conveyed as value field in otherName.  For example,
-   Kerberos [RFC 1510] format names can be encoded into the otherName,
-   using using a Kerberos 5 principal name OID and a SEQUENCE of the
-   Realm and the PrincipalName.
-
-   Subject alternative names MAY be constrained in the same manner as
-   subject distinguished names using the name constraints extension as
-   described in section 4.2.1.11.
-
-   If the subjectAltName extension is present, the sequence MUST contain
-   at least one entry.  Unlike the subject field, conforming CAs MUST
-   NOT issue certificates with subjectAltNames containing empty
-   GeneralName fields.  For example, an rfc822Name is represented as an
-   IA5String.  While an empty string is a valid IA5String, such an
-   rfc822Name is not permitted by this profile.  The behavior of clients
-   that encounter such a certificate when processing a certificication
-   path is not defined by this profile.
-
-   Finally, the semantics of subject alternative names that include
-   wildcard characters (e.g., as a placeholder for a set of names) are
-   not addressed by this specification.  Applications with specific
-   requirements MAY use such names, but they must define the semantics.
-
-   id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }
-
-   SubjectAltName ::= GeneralNames
-
-   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 35]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   GeneralName ::= CHOICE {
-        otherName                       [0]     OtherName,
-        rfc822Name                      [1]     IA5String,
-        dNSName                         [2]     IA5String,
-        x400Address                     [3]     ORAddress,
-        directoryName                   [4]     Name,
-        ediPartyName                    [5]     EDIPartyName,
-        uniformResourceIdentifier       [6]     IA5String,
-        iPAddress                       [7]     OCTET STRING,
-        registeredID                    [8]     OBJECT IDENTIFIER }
-
-   OtherName ::= SEQUENCE {
-        type-id    OBJECT IDENTIFIER,
-        value      [0] EXPLICIT ANY DEFINED BY type-id }
-
-   EDIPartyName ::= SEQUENCE {
-        nameAssigner            [0]     DirectoryString OPTIONAL,
-        partyName               [1]     DirectoryString }
-
-4.2.1.8  Issuer Alternative Names
-
-   As with 4.2.1.7, this extension is used to associate Internet style
-   identities with the certificate issuer.  Issuer alternative names
-   MUST be encoded as in 4.2.1.7.
-
-   Where present, this extension SHOULD NOT be marked critical.
-
-   id-ce-issuerAltName OBJECT IDENTIFIER ::=  { id-ce 18 }
-
-   IssuerAltName ::= GeneralNames
-
-4.2.1.9  Subject Directory Attributes
-
-   The subject directory attributes extension is used to convey
-   identification attributes (e.g., nationality) of the subject.  The
-   extension is defined as a sequence of one or more attributes.  This
-   extension MUST be non-critical.
-
-   id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::=  { id-ce 9 }
-
-   SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
-
-4.2.1.10  Basic Constraints
-
-   The basic constraints extension identifies whether the subject of the
-   certificate is a CA and the maximum depth of valid certification
-   paths that include this certificate.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 36]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   The cA boolean indicates whether the certified public key belongs to
-   a CA.  If the cA boolean is not asserted, then the keyCertSign bit in
-   the key usage extension MUST NOT be asserted.
-
-   The pathLenConstraint field is meaningful only if the cA boolean is
-   asserted and the key usage extension asserts the keyCertSign bit
-   (section 4.2.1.3).  In this case, it gives the maximum number of non-
-   self-issued intermediate certificates that may follow this
-   certificate in a valid certification path.  A certificate is self-
-   issued if the DNs that appear in the subject and issuer fields are
-   identical and are not empty.  (Note: The last certificate in the
-   certification path is not an intermediate certificate, and is not
-   included in this limit.  Usually, the last certificate is an end
-   entity certificate, but it can be a CA certificate.)  A
-   pathLenConstraint of zero indicates that only one more certificate
-   may follow in a valid certification path.  Where it appears, the
-   pathLenConstraint field MUST be greater than or equal to zero.  Where
-   pathLenConstraint does not appear, no limit is imposed.
-
-   This extension MUST appear as a critical extension in all CA
-   certificates that contain public keys used to validate digital
-   signatures on certificates.  This extension MAY appear as a critical
-   or non-critical extension in CA certificates that contain public keys
-   used exclusively for purposes other than validating digital
-   signatures on certificates.  Such CA certificates include ones that
-   contain public keys used exclusively for validating digital
-   signatures on CRLs and ones that contain key management public keys
-   used with certificate enrollment protocols.  This extension MAY
-   appear as a critical or non-critical extension in end entity
-   certificates.
-
-   CAs MUST NOT include the pathLenConstraint field unless the cA
-   boolean is asserted and the key usage extension asserts the
-   keyCertSign bit.
-
-   id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }
-
-   BasicConstraints ::= SEQUENCE {
-        cA                      BOOLEAN DEFAULT FALSE,
-        pathLenConstraint       INTEGER (0..MAX) OPTIONAL }
-
-4.2.1.11  Name Constraints
-
-   The name constraints extension, which MUST be used only in a CA
-   certificate, indicates a name space within which all subject names in
-   subsequent certificates in a certification path MUST be located.
-   Restrictions apply to the subject distinguished name and apply to
-   subject alternative names.  Restrictions apply only when the
-
-
-
-Housley, et. al.            Standards Track                    [Page 37]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   specified name form is present.  If no name of the type is in the
-   certificate, the certificate is acceptable.
-
-   Name constraints are not applied to certificates whose issuer and
-   subject are identical (unless the certificate is the final
-   certificate in the path).  (This could prevent CAs that use name
-   constraints from employing self-issued certificates to implement key
-   rollover.)
-
-   Restrictions are defined in terms of permitted or excluded name
-   subtrees.  Any name matching a restriction in the excludedSubtrees
-   field is invalid regardless of information appearing in the
-   permittedSubtrees.  This extension MUST be critical.
-
-   Within this profile, the minimum and maximum fields are not used with
-   any name forms, thus minimum MUST be zero, and maximum MUST be
-   absent.
-
-   For URIs, the constraint applies to the host part of the name.  The
-   constraint MAY specify a host or a domain.  Examples would be
-   "foo.bar.com";  and ".xyz.com".  When the the constraint begins with
-   a period, it MAY be expanded with one or more subdomains.  That is,
-   the constraint ".xyz.com" is satisfied by both abc.xyz.com and
-   abc.def.xyz.com.  However, the constraint ".xyz.com" is not satisfied
-   by "xyz.com".  When the constraint does not begin with a period, it
-   specifies a host.
-
-   A name constraint for Internet mail addresses MAY specify a
-   particular mailbox, all addresses at a particular host, or all
-   mailboxes in a domain.  To indicate a particular mailbox, the
-   constraint is the complete mail address.  For example, "root@xyz.com"
-   indicates the root mailbox on the host "xyz.com".  To indicate all
-   Internet mail addresses on a particular host, the constraint is
-   specified as the host name.  For example, the constraint "xyz.com" is
-   satisfied by any mail address at the host "xyz.com".  To specify any
-   address within a domain, the constraint is specified with a leading
-   period (as with URIs).  For example, ".xyz.com" indicates all the
-   Internet mail addresses in the domain "xyz.com", but not Internet
-   mail addresses on the host "xyz.com".
-
-   DNS name restrictions are expressed as foo.bar.com.  Any DNS name
-   that can be constructed by simply adding to the left hand side of the
-   name satisfies the name constraint.  For example, www.foo.bar.com
-   would satisfy the constraint but foo1.bar.com would not.
-
-   Legacy implementations exist where an RFC 822 name is embedded in the
-   subject distinguished name in an attribute of type EmailAddress
-   (section 4.1.2.6).  When rfc822 names are constrained, but the
-
-
-
-Housley, et. al.            Standards Track                    [Page 38]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   certificate does not include a subject alternative name, the rfc822
-   name constraint MUST be applied to the attribute of type EmailAddress
-   in the subject distinguished name.  The ASN.1 syntax for EmailAddress
-   and the corresponding OID are supplied in Appendix A.
-
-   Restrictions of the form directoryName MUST be applied to the subject
-   field in the certificate and to the subjectAltName extensions of type
-   directoryName.  Restrictions of the form x400Address MUST be applied
-   to subjectAltName extensions of type x400Address.
-
-   When applying restrictions of the form directoryName, an
-   implementation MUST compare DN attributes.  At a minimum,
-   implementations MUST perform the DN comparison rules specified in
-   Section 4.1.2.4.  CAs issuing certificates with a restriction of the
-   form directoryName SHOULD NOT rely on implementation of the full ISO
-   DN name comparison algorithm.  This implies name restrictions MUST be
-   stated identically to the encoding used in the subject field or
-   subjectAltName extension.
-
-   The syntax of iPAddress MUST be as described in section 4.2.1.7 with
-   the following additions specifically for Name Constraints.  For IPv4
-   addresses, the ipAddress field of generalName MUST contain eight (8)
-   octets, encoded in the style of RFC 1519 (CIDR) to represent an
-   address range [RFC 1519].  For IPv6 addresses, the ipAddress field
-   MUST contain 32 octets similarly encoded.  For example, a name
-   constraint for "class C" subnet 10.9.8.0 is represented as the octets
-   0A 09 08 00 FF FF FF 00, representing the CIDR notation
-   10.9.8.0/255.255.255.0.
-
-   The syntax and semantics for name constraints for otherName,
-   ediPartyName, and registeredID are not defined by this specification.
-
-      id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }
-
-      NameConstraints ::= SEQUENCE {
-           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
-           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }
-
-      GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
-
-      GeneralSubtree ::= SEQUENCE {
-           base                    GeneralName,
-           minimum         [0]     BaseDistance DEFAULT 0,
-           maximum         [1]     BaseDistance OPTIONAL }
-
-      BaseDistance ::= INTEGER (0..MAX)
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 39]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.2.1.12  Policy Constraints
-
-   The policy constraints extension can be used in certificates issued
-   to CAs.  The policy constraints extension constrains path validation
-   in two ways.  It can be used to prohibit policy mapping or require
-   that each certificate in a path contain an acceptable policy
-   identifier.
-
-   If the inhibitPolicyMapping field is present, the value indicates the
-   number of additional certificates that may appear in the path before
-   policy mapping is no longer permitted.  For example, a value of one
-   indicates that policy mapping may be processed in certificates issued
-   by the subject of this certificate, but not in additional
-   certificates in the path.
-
-   If the requireExplicitPolicy field is present, the value of
-   requireExplicitPolicy indicates the number of additional certificates
-   that may appear in the path before an explicit policy is required for
-   the entire path.  When an explicit policy is required, it is
-   necessary for all certificates in the path to contain an acceptable
-   policy identifier in the certificate policies extension.  An
-   acceptable policy identifier is the identifier of a policy required
-   by the user of the certification path or the identifier of a policy
-   which has been declared equivalent through policy mapping.
-
-   Conforming CAs MUST NOT issue certificates where policy constraints
-   is a empty sequence.  That is, at least one of the
-   inhibitPolicyMapping field or the requireExplicitPolicy field MUST be
-   present.  The behavior of clients that encounter a empty policy
-   constraints field is not addressed in this profile.
-
-   This extension MAY be critical or non-critical.
-
-   id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 36 }
-
-   PolicyConstraints ::= SEQUENCE {
-        requireExplicitPolicy           [0] SkipCerts OPTIONAL,
-        inhibitPolicyMapping            [1] SkipCerts OPTIONAL }
-
-   SkipCerts ::= INTEGER (0..MAX)
-
-4.2.1.13  Extended Key Usage
-
-   This extension indicates one or more purposes for which the certified
-   public key may be used, in addition to or in place of the basic
-   purposes indicated in the key usage extension.  In general, this
-   extension will appear only in end entity certificates.  This
-   extension is defined as follows:
-
-
-
-Housley, et. al.            Standards Track                    [Page 40]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
-
-   ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
-
-   KeyPurposeId ::= OBJECT IDENTIFIER
-
-   Key purposes may be defined by any organization with a need.  Object
-   identifiers used to identify key purposes MUST be assigned in
-   accordance with IANA or ITU-T Recommendation X.660 [X.660].
-
-   This extension MAY, at the option of the certificate issuer, be
-   either critical or non-critical.
-
-   If the extension is present, then the certificate MUST only be used
-   for one of the purposes indicated.  If multiple purposes are
-   indicated the application need not recognize all purposes indicated,
-   as long as the intended purpose is present.  Certificate using
-   applications MAY require that a particular purpose be indicated in
-   order for the certificate to be acceptable to that application.
-
-   If a CA includes extended key usages to satisfy such applications,
-   but does not wish to restrict usages of the key, the CA can include
-   the special keyPurposeID anyExtendedKeyUsage.  If the
-   anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT
-   be critical.
-
-   If a certificate contains both a key usage extension and an extended
-   key usage extension, then both extensions MUST be processed
-   independently and the certificate MUST only be used for a purpose
-   consistent with both extensions.  If there is no purpose consistent
-   with both extensions, then the certificate MUST NOT be used for any
-   purpose.
-
-   The following key usage purposes are defined:
-
-   anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
-
-   id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
-
-   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
-   -- TLS WWW server authentication
-   -- Key usage bits that may be consistent: digitalSignature,
-   -- keyEncipherment or keyAgreement
-
-   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
-   -- TLS WWW client authentication
-   -- Key usage bits that may be consistent: digitalSignature
-   -- and/or keyAgreement
-
-
-
-Housley, et. al.            Standards Track                    [Page 41]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   id-kp-codeSigning             OBJECT IDENTIFIER ::= { id-kp 3 }
-   -- Signing of downloadable executable code
-   -- Key usage bits that may be consistent: digitalSignature
-
-   id-kp-emailProtection         OBJECT IDENTIFIER ::= { id-kp 4 }
-   -- E-mail protection
-   -- Key usage bits that may be consistent: digitalSignature,
-   -- nonRepudiation, and/or (keyEncipherment or keyAgreement)
-
-   id-kp-timeStamping            OBJECT IDENTIFIER ::= { id-kp 8 }
-   -- Binding the hash of an object to a time
-   -- Key usage bits that may be consistent: digitalSignature
-   -- and/or nonRepudiation
-
-   id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
-   -- Signing OCSP responses
-   -- Key usage bits that may be consistent: digitalSignature
-   -- and/or nonRepudiation
-
-4.2.1.14  CRL Distribution Points
-
-   The CRL distribution points extension identifies how CRL information
-   is obtained.  The extension SHOULD be non-critical, but this profile
-   RECOMMENDS support for this extension by CAs and applications.
-   Further discussion of CRL management is contained in section 5.
-
-   The cRLDistributionPoints extension is a SEQUENCE of
-   DistributionPoint.  A DistributionPoint consists of three fields,
-   each of which is optional: distributionPoint, reasons, and cRLIssuer.
-   While each of these fields is optional, a DistributionPoint MUST NOT
-   consist of only the reasons field; either distributionPoint or
-   cRLIssuer MUST be present.  If the certificate issuer is not the CRL
-   issuer, then the cRLIssuer field MUST be present and contain the Name
-   of the CRL issuer.  If the certificate issuer is also the CRL issuer,
-   then the cRLIssuer field MUST be omitted and the distributionPoint
-   field MUST be present.  If the distributionPoint field is omitted,
-   cRLIssuer MUST be present and include a Name corresponding to an
-   X.500 or LDAP directory entry where the CRL is located.
-
-   When the distributionPoint field is present, it contains either a
-   SEQUENCE of general names or a single value, nameRelativeToCRLIssuer.
-   If the cRLDistributionPoints extension contains a general name of
-   type URI, the following semantics MUST be assumed: the URI is a
-   pointer to the current CRL for the associated reasons and will be
-   issued by the associated cRLIssuer.  The expected values for the URI
-   are those defined in 4.2.1.7.  Processing rules for other values are
-   not defined by this specification.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 42]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   If the DistributionPointName contains multiple values, each name
-   describes a different mechanism to obtain the same CRL.  For example,
-   the same CRL could be available for retrieval through both LDAP and
-   HTTP.
-
-   If the DistributionPointName contains the single value
-   nameRelativeToCRLIssuer, the value provides a distinguished name
-   fragment.  The fragment is appended to the X.500 distinguished name
-   of the CRL issuer to obtain the distribution point name.  If the
-   cRLIssuer field in the DistributionPoint is present, then the name
-   fragment is appended to the distinguished name that it contains;
-   otherwise, the name fragment is appended to the certificate issuer
-   distinguished name.  The DistributionPointName MUST NOT use the
-   nameRealtiveToCRLIssuer alternative when cRLIssuer contains more than
-   one distinguished name.
-
-   If the DistributionPoint omits the reasons field, the CRL MUST
-   include revocation information for all reasons.
-
-   The cRLIssuer identifies the entity who signs and issues the CRL.  If
-   present, the cRLIssuer MUST contain at least one an X.500
-   distinguished name (DN), and MAY also contain other name forms.
-   Since the cRLIssuer is compared to the CRL issuer name, the X.501
-   type Name MUST follow the encoding rules for the issuer name field in
-   the certificate (section 4.1.2.4).
-
-   id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::=  { id-ce 31 }
-
-   CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
-
-   DistributionPoint ::= SEQUENCE {
-        distributionPoint       [0]     DistributionPointName OPTIONAL,
-        reasons                 [1]     ReasonFlags OPTIONAL,
-        cRLIssuer               [2]     GeneralNames OPTIONAL }
-
-   DistributionPointName ::= CHOICE {
-        fullName                [0]     GeneralNames,
-        nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 43]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   ReasonFlags ::= BIT STRING {
-        unused                  (0),
-        keyCompromise           (1),
-        cACompromise            (2),
-        affiliationChanged      (3),
-        superseded              (4),
-        cessationOfOperation    (5),
-        certificateHold         (6),
-        privilegeWithdrawn      (7),
-        aACompromise            (8) }
-
-4.2.1.15  Inhibit Any-Policy
-
-   The inhibit any-policy extension can be used in certificates issued
-   to CAs.  The inhibit any-policy indicates that the special anyPolicy
-   OID, with the value { 2 5 29 32 0 }, is not considered an explicit
-   match for other certificate policies.  The value indicates the number
-   of additional certificates that may appear in the path before
-   anyPolicy is no longer permitted.  For example, a value of one
-   indicates that anyPolicy may be processed in certificates issued by
-   the subject of this certificate, but not in additional certificates
-   in the path.
-
-   This extension MUST be critical.
-
-   id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::=  { id-ce 54 }
-
-   InhibitAnyPolicy ::= SkipCerts
-
-   SkipCerts ::= INTEGER (0..MAX)
-
-4.2.1.16  Freshest CRL (a.k.a. Delta CRL Distribution Point)
-
-   The freshest CRL extension identifies how delta CRL information is
-   obtained.  The extension MUST be non-critical.  Further discussion of
-   CRL management is contained in section 5.
-
-   The same syntax is used for this extension and the
-   cRLDistributionPoints extension, and is described in section
-   4.2.1.14.  The same conventions apply to both extensions.
-
-   id-ce-freshestCRL OBJECT IDENTIFIER ::=  { id-ce 46 }
-
-   FreshestCRL ::= CRLDistributionPoints
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 44]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.2.2  Private Internet Extensions
-
-   This section defines two extensions for use in the Internet Public
-   Key Infrastructure.  These extensions may be used to direct
-   applications to on-line information about the issuing CA or the
-   subject.  As the information may be available in multiple forms, each
-   extension is a sequence of IA5String values, each of which represents
-   a URI.  The URI implicitly specifies the location and format of the
-   information and the method for obtaining the information.
-
-   An object identifier is defined for the private extension.  The
-   object identifier associated with the private extension is defined
-   under the arc id-pe within the arc id-pkix.  Any future extensions
-   defined for the Internet PKI are also expected to be defined under
-   the arc id-pe.
-
-      id-pkix  OBJECT IDENTIFIER  ::=
-               { iso(1) identified-organization(3) dod(6) internet(1)
-                       security(5) mechanisms(5) pkix(7) }
-
-      id-pe  OBJECT IDENTIFIER  ::=  { id-pkix 1 }
-
-4.2.2.1  Authority Information Access
-
-   The authority information access extension indicates how to access CA
-   information and services for the issuer of the certificate in which
-   the extension appears.  Information and services may include on-line
-   validation services and CA policy data.  (The location of CRLs is not
-   specified in this extension; that information is provided by the
-   cRLDistributionPoints extension.)  This extension may be included in
-   end entity or CA certificates, and it MUST be non-critical.
-
-   id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
-
-   AuthorityInfoAccessSyntax  ::=
-           SEQUENCE SIZE (1..MAX) OF AccessDescription
-
-   AccessDescription  ::=  SEQUENCE {
-           accessMethod          OBJECT IDENTIFIER,
-           accessLocation        GeneralName  }
-
-   id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
-
-   id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
-
-   id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 45]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   Each entry in the sequence AuthorityInfoAccessSyntax describes the
-   format and location of additional information provided by the CA that
-   issued the certificate in which this extension appears.  The type and
-   format of the information is specified by the accessMethod field; the
-   accessLocation field specifies the location of the information.  The
-   retrieval mechanism may be implied by the accessMethod or specified
-   by accessLocation.
-
-   This profile defines two accessMethod OIDs: id-ad-caIssuers and
-   id-ad-ocsp.
-
-   The id-ad-caIssuers OID is used when the additional information lists
-   CAs that have issued certificates superior to the CA that issued the
-   certificate containing this extension.  The referenced CA issuers
-   description is intended to aid certificate users in the selection of
-   a certification path that terminates at a point trusted by the
-   certificate user.
-
-   When id-ad-caIssuers appears as accessMethod, the accessLocation
-   field describes the referenced description server and the access
-   protocol to obtain the referenced description.  The accessLocation
-   field is defined as a GeneralName, which can take several forms.
-   Where the information is available via http, ftp, or ldap,
-   accessLocation MUST be a uniformResourceIdentifier.  Where the
-   information is available via the Directory Access Protocol (DAP),
-   accessLocation MUST be a directoryName.  The entry for that
-   directoryName contains CA certificates in the crossCertificatePair
-   attribute.  When the information is available via electronic mail,
-   accessLocation MUST be an rfc822Name.  The semantics of other
-   id-ad-caIssuers accessLocation name forms are not defined.
-
-   The id-ad-ocsp OID is used when revocation information for the
-   certificate containing this extension is available using the Online
-   Certificate Status Protocol (OCSP) [RFC 2560].
-
-   When id-ad-ocsp appears as accessMethod, the accessLocation field is
-   the location of the OCSP responder, using the conventions defined in
-   [RFC 2560].
-
-   Additional access descriptors may be defined in other PKIX
-   specifications.
-
-4.2.2.2  Subject Information Access
-
-   The subject information access extension indicates how to access
-   information and services for the subject of the certificate in which
-   the extension appears.  When the subject is a CA, information and
-   services may include certificate validation services and CA policy
-
-
-
-Housley, et. al.            Standards Track                    [Page 46]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   data.  When the subject is an end entity, the information describes
-   the type of services offered and how to access them.  In this case,
-   the contents of this extension are defined in the protocol
-   specifications for the suported services.  This extension may be
-   included in subject or CA certificates, and it MUST be non-critical.
-
-   id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
-
-   SubjectInfoAccessSyntax  ::=
-           SEQUENCE SIZE (1..MAX) OF AccessDescription
-
-   AccessDescription  ::=  SEQUENCE {
-           accessMethod          OBJECT IDENTIFIER,
-           accessLocation        GeneralName  }
-
-   Each entry in the sequence SubjectInfoAccessSyntax describes the
-   format and location of additional information provided by the subject
-   of the certificate in which this extension appears.  The type and
-   format of the information is specified by the accessMethod field; the
-   accessLocation field specifies the location of the information.  The
-   retrieval mechanism may be implied by the accessMethod or specified
-   by accessLocation.
-
-   This profile defines one access method to be used when the subject is
-   a CA, and one access method to be used when the subject is an end
-   entity.  Additional access methods may be defined in the future in
-   the protocol specifications for other services.
-
-   The id-ad-caRepository OID is used when the subject is a CA, and
-   publishes its certificates and CRLs (if issued) in a repository.  The
-   accessLocation field is defined as a GeneralName, which can take
-   several forms.  Where the information is available via http, ftp, or
-   ldap, accessLocation MUST be a uniformResourceIdentifier.  Where the
-   information is available via the directory access protocol (dap),
-   accessLocation MUST be a directoryName.  When the information is
-   available via electronic mail, accessLocation MUST be an rfc822Name.
-   The semantics of other name forms of of accessLocation (when
-   accessMethod is id-ad-caRepository) are not defined by this
-   specification.
-
-   The id-ad-timeStamping OID is used when the subject offers
-   timestamping services using the Time Stamp Protocol defined in
-   [PKIXTSA].  Where the timestamping services are available via http or
-   ftp, accessLocation MUST be a uniformResourceIdentifier.  Where the
-   timestamping services are available via electronic mail,
-   accessLocation MUST be an rfc822Name.  Where timestamping services
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 47]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   are available using TCP/IP, the dNSName or ipAddress name forms may
-   be used.  The semantics of other name forms of accessLocation (when
-   accessMethod is id-ad-timeStamping) are not defined by this
-   specification.
-
-   Additional access descriptors may be defined in other PKIX
-   specifications.
-
-   id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
-
-   id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
-
-   id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
-
-5  CRL and CRL Extensions Profile
-
-   As discussed above, one goal of this X.509 v2 CRL profile is to
-   foster the creation of an interoperable and reusable Internet PKI.
-   To achieve this goal, guidelines for the use of extensions are
-   specified, and some assumptions are made about the nature of
-   information included in the CRL.
-
-   CRLs may be used in a wide range of applications and environments
-   covering a broad spectrum of interoperability goals and an even
-   broader spectrum of operational and assurance requirements.  This
-   profile establishes a common baseline for generic applications
-   requiring broad interoperability.  The profile defines a set of
-   information that can be expected in every CRL.  Also, the profile
-   defines common locations within the CRL for frequently used
-   attributes as well as common representations for these attributes.
-
-   CRL issuers issue CRLs.  In general, the CRL issuer is the CA.  CAs
-   publish CRLs to provide status information about the certificates
-   they issued.  However, a CA may delegate this responsibility to
-   another trusted authority.  Whenever the CRL issuer is not the CA
-   that issued the certificates, the CRL is referred to as an indirect
-   CRL.
-
-   Each CRL has a particular scope.  The CRL scope is the set of
-   certificates that could appear on a given CRL.  For example, the
-   scope could be "all certificates issued by CA X", "all CA
-   certificates issued by CA X", "all certificates issued by CA X that
-   have been revoked for reasons of key compromise and CA compromise",
-   or could be a set of certificates based on arbitrary local
-   information, such as "all certificates issued to the NIST employees
-   located in Boulder".
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 48]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   A complete CRL lists all unexpired certificates, within its scope,
-   that have been revoked for one of the revocation reasons covered by
-   the CRL scope.  The CRL issuer MAY also generate delta CRLs.  A delta
-   CRL only lists those certificates, within its scope, whose revocation
-   status has changed since the issuance of a referenced complete CRL.
-   The referenced complete CRL is referred to as a base CRL.  The scope
-   of a delta CRL MUST be the same as the base CRL that it references.
-
-   This profile does not define any private Internet CRL extensions or
-   CRL entry extensions.
-
-   Environments with additional or special purpose requirements may
-   build on this profile or may replace it.
-
-   Conforming CAs are not required to issue CRLs if other revocation or
-   certificate status mechanisms are provided.  When CRLs are issued,
-   the CRLs MUST be version 2 CRLs, include the date by which the next
-   CRL will be issued in the nextUpdate field (section 5.1.2.5), include
-   the CRL number extension (section 5.2.3), and include the authority
-   key identifier extension (section 5.2.1).  Conforming applications
-   that support CRLs are REQUIRED to process both version 1 and version
-   2 complete CRLs that provide revocation information for all
-   certificates issued by one CA.  Conforming applications are NOT
-   REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs
-   with a scope other than all certificates issued by one CA.
-
-5.1  CRL Fields
-
-   The X.509 v2 CRL syntax is as follows.  For signature calculation,
-   the data that is to be signed is ASN.1 DER encoded.  ASN.1 DER
-   encoding is a tag, length, value encoding system for each element.
-
-   CertificateList  ::=  SEQUENCE  {
-        tbsCertList          TBSCertList,
-        signatureAlgorithm   AlgorithmIdentifier,
-        signatureValue       BIT STRING  }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 49]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   TBSCertList  ::=  SEQUENCE  {
-        version                 Version OPTIONAL,
-                                     -- if present, MUST be v2
-        signature               AlgorithmIdentifier,
-        issuer                  Name,
-        thisUpdate              Time,
-        nextUpdate              Time OPTIONAL,
-        revokedCertificates     SEQUENCE OF SEQUENCE  {
-             userCertificate         CertificateSerialNumber,
-             revocationDate          Time,
-             crlEntryExtensions      Extensions OPTIONAL
-                                           -- if present, MUST be v2
-                                  }  OPTIONAL,
-        crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
-                                           -- if present, MUST be v2
-                                  }
-
-   -- Version, Time, CertificateSerialNumber, and Extensions
-   -- are all defined in the ASN.1 in section 4.1
-
-   -- AlgorithmIdentifier is defined in section 4.1.1.2
-
-   The following items describe the use of the X.509 v2 CRL in the
-   Internet PKI.
-
-5.1.1  CertificateList Fields
-
-   The CertificateList is a SEQUENCE of three required fields.  The
-   fields are described in detail in the following subsections.
-
-5.1.1.1  tbsCertList
-
-   The first field in the sequence is the tbsCertList.  This field is
-   itself a sequence containing the name of the issuer, issue date,
-   issue date of the next list, the optional list of revoked
-   certificates, and optional CRL extensions.  When there are no revoked
-   certificates, the revoked certificates list is absent.  When one or
-   more certificates are revoked, each entry on the revoked certificate
-   list is defined by a sequence of user certificate serial number,
-   revocation date, and optional CRL entry extensions.
-
-5.1.1.2  signatureAlgorithm
-
-   The signatureAlgorithm field contains the algorithm identifier for
-   the algorithm used by the CRL issuer to sign the CertificateList.
-   The field is of type AlgorithmIdentifier, which is defined in section
-   4.1.1.2.  [PKIXALGS] lists the supported algorithms for this
-   specification, but other signature algorithms MAY also be supported.
-
-
-
-Housley, et. al.            Standards Track                    [Page 50]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   This field MUST contain the same algorithm identifier as the
-   signature field in the sequence tbsCertList (section 5.1.2.2).
-
-5.1.1.3  signatureValue
-
-   The signatureValue field contains a digital signature computed upon
-   the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded tbsCertList
-   is used as the input to the signature function.  This signature value
-   is encoded as a BIT STRING and included in the CRL signatureValue
-   field.  The details of this process are specified for each of the
-   supported algorithms in [PKIXALGS].
-
-   CAs that are also CRL issuers MAY use one private key to digitally
-   sign certificates and CRLs, or MAY use separate private keys to
-   digitally sign certificates and CRLs.  When separate private keys are
-   employed, each of the public keys associated with these private keys
-   is placed in a separate certificate, one with the keyCertSign bit set
-   in the key usage extension, and one with the cRLSign bit set in the
-   key usage extension (section 4.2.1.3).  When separate private keys
-   are employed, certificates issued by the CA contain one authority key
-   identifier, and the corresponding CRLs contain a different authority
-   key identifier.  The use of separate CA certificates for validation
-   of certificate signatures and CRL signatures can offer improved
-   security characteristics; however, it imposes a burden on
-   applications, and it might limit interoperability.  Many applications
-   construct a certification path, and then validate the certification
-   path (section 6).  CRL checking in turn requires a separate
-   certification path to be constructed and validated for the CA's CRL
-   signature validation certificate.  Applications that perform CRL
-   checking MUST support certification path validation when certificates
-   and CRLs are digitally signed with the same CA private key.  These
-   applications SHOULD support certification path validation when
-   certificates and CRLs are digitally signed with different CA private
-   keys.
-
-5.1.2  Certificate List "To Be Signed"
-
-   The certificate list to be signed, or TBSCertList, is a sequence of
-   required and optional fields.  The required fields identify the CRL
-   issuer, the algorithm used to sign the CRL, the date and time the CRL
-   was issued, and the date and time by which the CRL issuer will issue
-   the next CRL.
-
-   Optional fields include lists of revoked certificates and CRL
-   extensions.  The revoked certificate list is optional to support the
-   case where a CA has not revoked any unexpired certificates that it
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 51]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   has issued.  The profile requires conforming CRL issuers to use the
-   CRL number and authority key identifier CRL extensions in all CRLs
-   issued.
-
-5.1.2.1  Version
-
-   This optional field describes the version of the encoded CRL.  When
-   extensions are used, as required by this profile, this field MUST be
-   present and MUST specify version 2 (the integer value is 1).
-
-5.1.2.2  Signature
-
-   This field contains the algorithm identifier for the algorithm used
-   to sign the CRL.  [PKIXALGS] lists OIDs for the most popular
-   signature algorithms used in the Internet PKI.
-
-   This field MUST contain the same algorithm identifier as the
-   signatureAlgorithm field in the sequence CertificateList (section
-   5.1.1.2).
-
-5.1.2.3  Issuer Name
-
-   The issuer name identifies the entity who has signed and issued the
-   CRL.  The issuer identity is carried in the issuer name field.
-   Alternative name forms may also appear in the issuerAltName extension
-   (section 5.2.2).  The issuer name field MUST contain an X.500
-   distinguished name (DN).  The issuer name field is defined as the
-   X.501 type Name, and MUST follow the encoding rules for the issuer
-   name field in the certificate (section 4.1.2.4).
-
-5.1.2.4  This Update
-
-   This field indicates the issue date of this CRL.  ThisUpdate may be
-   encoded as UTCTime or GeneralizedTime.
-
-   CRL issuers conforming to this profile MUST encode thisUpdate as
-   UTCTime for dates through the year 2049.  CRL issuers conforming to
-   this profile MUST encode thisUpdate as GeneralizedTime for dates in
-   the year 2050 or later.
-
-   Where encoded as UTCTime, thisUpdate MUST be specified and
-   interpreted as defined in section 4.1.2.5.1.  Where encoded as
-   GeneralizedTime, thisUpdate MUST be specified and interpreted as
-   defined in section 4.1.2.5.2.
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 52]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-5.1.2.5  Next Update
-
-   This field indicates the date by which the next CRL will be issued.
-   The next CRL could be issued before the indicated date, but it will
-   not be issued any later than the indicated date.  CRL issuers SHOULD
-   issue CRLs with a nextUpdate time equal to or later than all previous
-   CRLs.  nextUpdate may be encoded as UTCTime or GeneralizedTime.
-
-   This profile requires inclusion of nextUpdate in all CRLs issued by
-   conforming CRL issuers.  Note that the ASN.1 syntax of TBSCertList
-   describes this field as OPTIONAL, which is consistent with the ASN.1
-   structure defined in [X.509].  The behavior of clients processing
-   CRLs which omit nextUpdate is not specified by this profile.
-
-   CRL issuers conforming to this profile MUST encode nextUpdate as
-   UTCTime for dates through the year 2049.  CRL issuers conforming to
-   this profile MUST encode nextUpdate as GeneralizedTime for dates in
-   the year 2050 or later.
-
-   Where encoded as UTCTime, nextUpdate MUST be specified and
-   interpreted as defined in section 4.1.2.5.1.  Where encoded as
-   GeneralizedTime, nextUpdate MUST be specified and interpreted as
-   defined in section 4.1.2.5.2.
-
-5.1.2.6  Revoked Certificates
-
-   When there are no revoked certificates, the revoked certificates list
-   MUST be absent.  Otherwise, revoked certificates are listed by their
-   serial numbers.  Certificates revoked by the CA are uniquely
-   identified by the certificate serial number.  The date on which the
-   revocation occurred is specified.  The time for revocationDate MUST
-   be expressed as described in section 5.1.2.4. Additional information
-   may be supplied in CRL entry extensions; CRL entry extensions are
-   discussed in section 5.3.
-
-5.1.2.7  Extensions
-
-   This field may only appear if the version is 2 (section 5.1.2.1).  If
-   present, this field is a sequence of one or more CRL extensions.  CRL
-   extensions are discussed in section 5.2.
-
-5.2  CRL Extensions
-
-   The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2
-   CRLs [X.509] [X9.55] provide methods for associating additional
-   attributes with CRLs.  The X.509 v2 CRL format also allows
-   communities to define private extensions to carry information unique
-   to those communities.  Each extension in a CRL may be designated as
-
-
-
-Housley, et. al.            Standards Track                    [Page 53]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   critical or non-critical.  A CRL validation MUST fail if it
-   encounters a critical extension which it does not know how to
-   process.  However, an unrecognized non-critical extension may be
-   ignored.  The following subsections present those extensions used
-   within Internet CRLs.  Communities may elect to include extensions in
-   CRLs which are not defined in this specification.  However, caution
-   should be exercised in adopting any critical extensions in CRLs which
-   might be used in a general context.
-
-   Conforming CRL issuers are REQUIRED to include the authority key
-   identifier (section 5.2.1) and the CRL number (section 5.2.3)
-   extensions in all CRLs issued.
-
-5.2.1  Authority Key Identifier
-
-   The authority key identifier extension provides a means of
-   identifying the public key corresponding to the private key used to
-   sign a CRL.  The identification can be based on either the key
-   identifier (the subject key identifier in the CRL signer's
-   certificate) or on the issuer name and serial number.  This extension
-   is especially useful where an issuer has more than one signing key,
-   either due to multiple concurrent key pairs or due to changeover.
-
-   Conforming CRL issuers MUST use the key identifier method, and MUST
-   include this extension in all CRLs issued.
-
-   The syntax for this CRL extension is defined in section 4.2.1.1.
-
-5.2.2  Issuer Alternative Name
-
-   The issuer alternative names extension allows additional identities
-   to be associated with the issuer of the CRL.  Defined options include
-   an rfc822 name (electronic mail address), a DNS name, an IP address,
-   and a URI.  Multiple instances of a name and multiple name forms may
-   be included.  Whenever such identities are used, the issuer
-   alternative name extension MUST be used; however, a DNS name MAY be
-   represented in the issuer field using the domainComponent attribute
-   as described in section 4.1.2.4.
-
-   The issuerAltName extension SHOULD NOT be marked critical.
-
-   The OID and syntax for this CRL extension are defined in section
-   4.2.1.8.
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 54]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-5.2.3  CRL Number
-
-   The CRL number is a non-critical CRL extension which conveys a
-   monotonically increasing sequence number for a given CRL scope and
-   CRL issuer.  This extension allows users to easily determine when a
-   particular CRL supersedes another CRL.  CRL numbers also support the
-   identification of complementary complete CRLs and delta CRLs.  CRL
-   issuers conforming to this profile MUST include this extension in all
-   CRLs.
-
-   If a CRL issuer generates delta CRLs in addition to complete CRLs for
-   a given scope, the complete CRLs and delta CRLs MUST share one
-   numbering sequence.  If a delta CRL and a complete CRL that cover the
-   same scope are issued at the same time, they MUST have the same CRL
-   number and provide the same revocation information.  That is, the
-   combination of the delta CRL and an acceptable complete CRL MUST
-   provide the same revocation information as the simultaneously issued
-   complete CRL.
-
-   If a CRL issuer generates two CRLs (two complete CRLs, two delta
-   CRLs, or a complete CRL and a delta CRL) for the same scope at
-   different times, the two CRLs MUST NOT have the same CRL number.
-   That is, if the this update field (section 5.1.2.4) in the two CRLs
-   are not identical, the CRL numbers MUST be different.
-
-   Given the requirements above, CRL numbers can be expected to contain
-   long integers.  CRL verifiers MUST be able to handle CRLNumber values
-   up to 20 octets.  Conformant CRL issuers MUST NOT use CRLNumber
-   values longer than 20 octets.
-
-   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
-
-   CRLNumber ::= INTEGER (0..MAX)
-
-5.2.4  Delta CRL Indicator
-
-   The delta CRL indicator is a critical CRL extension that identifies a
-   CRL as being a delta CRL.  Delta CRLs contain updates to revocation
-   information previously distributed, rather than all the information
-   that would appear in a complete CRL.  The use of delta CRLs can
-   significantly reduce network load and processing time in some
-   environments.  Delta CRLs are generally smaller than the CRLs they
-   update, so applications that obtain delta CRLs consume less network
-   bandwidth than applications that obtain the corresponding complete
-   CRLs.  Applications which store revocation information in a format
-   other than the CRL structure can add new revocation information to
-   the local database without reprocessing information.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 55]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   The delta CRL indicator extension contains the single value of type
-   BaseCRLNumber.  The CRL number identifies the CRL, complete for a
-   given scope, that was used as the starting point in the generation of
-   this delta CRL.  A conforming CRL issuer MUST publish the referenced
-   base CRL as a complete CRL.  The delta CRL contains all updates to
-   the revocation status for that same scope.  The combination of a
-   delta CRL plus the referenced base CRL is equivalent to a complete
-   CRL, for the applicable scope, at the time of publication of the
-   delta CRL.
-
-   When a conforming CRL issuer generates a delta CRL, the delta CRL
-   MUST include a critical delta CRL indicator extension.
-
-   When a delta CRL is issued, it MUST cover the same set of reasons and
-   the same set of certificates that were covered by the base CRL it
-   references.  That is, the scope of the delta CRL MUST be the same as
-   the scope of the complete CRL referenced as the base.  The referenced
-   base CRL and the delta CRL MUST omit the issuing distribution point
-   extension or contain identical issuing distribution point extensions.
-   Further, the CRL issuer MUST use the same private key to sign the
-   delta CRL and any complete CRL that it can be used to update.
-
-   An application that supports delta CRLs can construct a CRL that is
-   complete for a given scope by combining a delta CRL for that scope
-   with either an issued CRL that is complete for that scope or a
-   locally constructed CRL that is complete for that scope.
-
-   When a delta CRL is combined with a complete CRL or a locally
-   constructed CRL, the resulting locally constructed CRL has the CRL
-   number specified in the CRL number extension found in the delta CRL
-   used in its construction.  In addition, the resulting locally
-   constructed CRL has the thisUpdate and nextUpdate times specified in
-   the corresponding fields of the delta CRL used in its construction.
-   In addition, the locally constructed CRL inherits the issuing
-   distribution point from the delta CRL.
-
-   A complete CRL and a delta CRL MAY be combined if the following four
-   conditions are satisfied:
-
-      (a)  The complete CRL and delta CRL have the same issuer.
-
-      (b)  The complete CRL and delta CRL have the same scope.  The two
-      CRLs have the same scope if either of the following conditions are
-      met:
-
-         (1)  The issuingDistributionPoint extension is omitted from
-         both the complete CRL and the delta CRL.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 56]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-         (2)  The issuingDistributionPoint extension is present in both
-         the complete CRL and the delta CRL, and the values for each of
-         the fields in the extensions are the same in both CRLs.
-
-      (c)  The CRL number of the complete CRL is equal to or greater
-      than the BaseCRLNumber specified in the delta CRL.  That is, the
-      complete CRL contains (at a minimum) all the revocation
-      information held by the referenced base CRL.
-
-      (d)  The CRL number of the complete CRL is less than the CRL
-      number of the delta CRL.  That is, the delta CRL follows the
-      complete CRL in the numbering sequence.
-
-   CRL issuers MUST ensure that the combination of a delta CRL and any
-   appropriate complete CRL accurately reflects the current revocation
-   status.  The CRL issuer MUST include an entry in the delta CRL for
-   each certificate within the scope of the delta CRL whose status has
-   changed since the generation of the referenced base CRL:
-
-      (a)  If the certificate is revoked for a reason included in the
-      scope of the CRL, list the certificate as revoked.
-
-      (b)  If the certificate is valid and was listed on the referenced
-      base CRL or any subsequent CRL with reason code certificateHold,
-      and the reason code certificateHold is included in the scope of
-      the CRL, list the certificate with the reason code removeFromCRL.
-
-      (c)  If the certificate is revoked for a reason outside the scope
-      of the CRL, but the certificate was listed on the referenced base
-      CRL or any subsequent CRL with a reason code included in the scope
-      of this CRL, list the certificate as revoked but omit the reason
-      code.
-
-      (d)  If the certificate is revoked for a reason outside the scope
-      of the CRL and the certificate was neither listed on the
-      referenced base CRL nor any subsequent CRL with a reason code
-      included in the scope of this CRL, do not list the certificate on
-      this CRL.
-
-   The status of a certificate is considered to have changed if it is
-   revoked, placed on hold, released from hold, or if its revocation
-   reason changes.
-
-   It is appropriate to list a certificate with reason code
-   removeFromCRL on a delta CRL even if the certificate was not on hold
-   in the referenced base CRL.  If the certificate was placed on hold in
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 57]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   any CRL issued after the base but before this delta CRL and then
-   released from hold, it MUST be listed on the delta CRL with
-   revocation reason removeFromCRL.
-
-   A CRL issuer MAY optionally list a certificate on a delta CRL with
-   reason code removeFromCRL if the notAfter time specified in the
-   certificate precedes the thisUpdate time specified in the delta CRL
-   and the certificate was listed on the referenced base CRL or in any
-   CRL issued after the base but before this delta CRL.
-
-   If a certificate revocation notice first appears on a delta CRL, then
-   it is possible for the certificate validity period to expire before
-   the next complete CRL for the same scope is issued.  In this case,
-   the revocation notice MUST be included in all subsequent delta CRLs
-   until the revocation notice is included on at least one explicitly
-   issued complete CRL for this scope.
-
-   An application that supports delta CRLs MUST be able to construct a
-   current complete CRL by combining a previously issued complete CRL
-   and the most current delta CRL.  An application that supports delta
-   CRLs MAY also be able to construct a current complete CRL by
-   combining a previously locally constructed complete CRL and the
-   current delta CRL.  A delta CRL is considered to be the current one
-   if the current time is between the times contained in the thisUpdate
-   and nextUpdate fields.  Under some circumstances, the CRL issuer may
-   publish one or more delta CRLs before indicated by the nextUpdate
-   field.  If more than one current delta CRL for a given scope is
-   encountered, the application SHOULD consider the one with the latest
-   value in thisUpdate to be the most current one.
-
-   id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
-
-   BaseCRLNumber ::= CRLNumber
-
-5.2.5  Issuing Distribution Point
-
-   The issuing distribution point is a critical CRL extension that
-   identifies the CRL distribution point and scope for a particular CRL,
-   and it indicates whether the CRL covers revocation for end entity
-   certificates only, CA certificates only, attribute certificates only,
-
-   or a limited set of reason codes.  Although the extension is
-   critical, conforming implementations are not required to support this
-   extension.
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 58]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   The CRL is signed using the CRL issuer's private key.  CRL
-   Distribution Points do not have their own key pairs.  If the CRL is
-   stored in the X.500 Directory, it is stored in the Directory entry
-   corresponding to the CRL distribution point, which may be different
-   than the Directory entry of the CRL issuer.
-
-   The reason codes associated with a distribution point MUST be
-   specified in onlySomeReasons.  If onlySomeReasons does not appear,
-   the distribution point MUST contain revocations for all reason codes.
-   CAs may use CRL distribution points to partition the CRL on the basis
-   of compromise and routine revocation.  In this case, the revocations
-   with reason code keyCompromise (1), cACompromise (2), and
-   aACompromise (8) appear in one distribution point, and the
-   revocations with other reason codes appear in another distribution
-   point.
-
-   If the distributionPoint field is present and contains a URI, the
-   following semantics MUST be assumed: the object is a pointer to the
-   most current CRL issued by this CRL issuer.  The URI schemes ftp,
-   http, mailto [RFC1738] and ldap [RFC1778] are defined for this
-   purpose.  The URI MUST be an absolute pathname, not a relative
-   pathname, and MUST specify the host.
-
-   If the distributionPoint field is absent, the CRL MUST contain
-   entries for all revoked unexpired certificates issued by the CRL
-   issuer, if any, within the scope of the CRL.
-
-   The CRL issuer MUST assert the indirectCRL boolean, if the scope of
-   the CRL includes certificates issued by authorities other than the
-   CRL issuer.  The authority responsible for each entry is indicated by
-   the certificate issuer CRL entry extension (section 5.3.4).
-
-   id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
-
-   issuingDistributionPoint ::= SEQUENCE {
-        distributionPoint          [0] DistributionPointName OPTIONAL,
-        onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
-        onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
-        onlySomeReasons            [3] ReasonFlags OPTIONAL,
-        indirectCRL                [4] BOOLEAN DEFAULT FALSE,
-        onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
-
-5.2.6  Freshest CRL (a.k.a. Delta CRL Distribution Point)
-
-   The freshest CRL extension identifies how delta CRL information for
-   this complete CRL is obtained.  The extension MUST be non-critical.
-   This extension MUST NOT appear in delta CRLs.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 59]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   The same syntax is used for this extension as the
-   cRLDistributionPoints certificate extension, and is described in
-   section 4.2.1.14.  However, only the distribution point field is
-   meaningful in this context.  The reasons and CRLIssuer fields MUST be
-   omitted from this CRL extension.
-
-   Each distribution point name provides the location at which a delta
-   CRL for this complete CRL can be found.  The scope of these delta
-   CRLs MUST be the same as the scope of this complete CRL.  The
-   contents of this CRL extension are only used to locate delta CRLs;
-   the contents are not used to validate the CRL or the referenced delta
-   CRLs.  The encoding conventions defined for distribution points in
-   section 4.2.1.14 apply to this extension.
-
-   id-ce-freshestCRL OBJECT IDENTIFIER ::=  { id-ce 46 }
-
-   FreshestCRL ::= CRLDistributionPoints
-
-5.3  CRL Entry Extensions
-
-   The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for
-   X.509 v2 CRLs provide methods for associating additional attributes
-   with CRL entries [X.509] [X9.55].  The X.509 v2 CRL format also
-   allows communities to define private CRL entry extensions to carry
-   information unique to those communities.  Each extension in a CRL
-   entry may be designated as critical or non-critical.  A CRL
-   validation MUST fail if it encounters a critical CRL entry extension
-   which it does not know how to process.  However, an unrecognized non-
-   critical CRL entry extension may be ignored.  The following
-   subsections present recommended extensions used within Internet CRL
-   entries and standard locations for information.  Communities may
-   elect to use additional CRL entry extensions; however, caution should
-   be exercised in adopting any critical extensions in CRL entries which
-   might be used in a general context.
-
-   All CRL entry extensions used in this specification are non-critical.
-   Support for these extensions is optional for conforming CRL issuers
-   and applications.  However, CRL issuers SHOULD include reason codes
-   (section 5.3.1) and invalidity dates (section 5.3.3) whenever this
-   information is available.
-
-5.3.1  Reason Code
-
-   The reasonCode is a non-critical CRL entry extension that identifies
-   the reason for the certificate revocation.  CRL issuers are strongly
-   encouraged to include meaningful reason codes in CRL entries;
-   however, the reason code CRL entry extension SHOULD be absent instead
-   of using the unspecified (0) reasonCode value.
-
-
-
-Housley, et. al.            Standards Track                    [Page 60]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 }
-
-   -- reasonCode ::= { CRLReason }
-
-   CRLReason ::= ENUMERATED {
-        unspecified             (0),
-        keyCompromise           (1),
-        cACompromise            (2),
-        affiliationChanged      (3),
-        superseded              (4),
-        cessationOfOperation    (5),
-        certificateHold         (6),
-        removeFromCRL           (8),
-        privilegeWithdrawn      (9),
-        aACompromise           (10) }
-
-5.3.2  Hold Instruction Code
-
-   The hold instruction code is a non-critical CRL entry extension that
-   provides a registered instruction identifier which indicates the
-   action to be taken after encountering a certificate that has been
-   placed on hold.
-
-   id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
-
-   holdInstructionCode ::= OBJECT IDENTIFIER
-
-   The following instruction codes have been defined.  Conforming
-   applications that process this extension MUST recognize the following
-   instruction codes.
-
-   holdInstruction    OBJECT IDENTIFIER ::=
-                    { iso(1) member-body(2) us(840) x9-57(10040) 2 }
-
-   id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
-   id-holdinstruction-callissuer
-                             OBJECT IDENTIFIER ::= {holdInstruction 2}
-   id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
-
-   Conforming applications which encounter an id-holdinstruction-
-   callissuer MUST call the certificate issuer or reject the
-   certificate.  Conforming applications which encounter an id-
-   holdinstruction-reject MUST reject the certificate.  The hold
-   instruction id-holdinstruction-none is semantically equivalent to the
-   absence of a holdInstructionCode, and its use is strongly deprecated
-   for the Internet PKI.
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 61]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-5.3.3  Invalidity Date
-
-   The invalidity date is a non-critical CRL entry extension that
-   provides the date on which it is known or suspected that the private
-   key was compromised or that the certificate otherwise became invalid.
-   This date may be earlier than the revocation date in the CRL entry,
-   which is the date at which the CA processed the revocation.  When a
-   revocation is first posted by a CRL issuer in a CRL, the invalidity
-   date may precede the date of issue of earlier CRLs, but the
-   revocation date SHOULD NOT precede the date of issue of earlier CRLs.
-   Whenever this information is available, CRL issuers are strongly
-   encouraged to share it with CRL users.
-
-   The GeneralizedTime values included in this field MUST be expressed
-   in Greenwich Mean Time (Zulu), and MUST be specified and interpreted
-   as defined in section 4.1.2.5.2.
-
-   id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
-
-   invalidityDate ::=  GeneralizedTime
-
-5.3.4  Certificate Issuer
-
-   This CRL entry extension identifies the certificate issuer associated
-   with an entry in an indirect CRL, that is, a CRL that has the
-   indirectCRL indicator set in its issuing distribution point
-   extension.  If this extension is not present on the first entry in an
-   indirect CRL, the certificate issuer defaults to the CRL issuer.  On
-   subsequent entries in an indirect CRL, if this extension is not
-   present, the certificate issuer for the entry is the same as that for
-   the preceding entry.  This field is defined as follows:
-
-   id-ce-certificateIssuer   OBJECT IDENTIFIER ::= { id-ce 29 }
-
-   certificateIssuer ::=     GeneralNames
-
-   If used by conforming CRL issuers, this extension MUST always be
-   critical.  If an implementation ignored this extension it could not
-   correctly attribute CRL entries to certificates.  This specification
-   RECOMMENDS that implementations recognize this extension.
-
-6  Certification Path Validation
-
-   Certification path validation procedures for the Internet PKI are
-   based on the algorithm supplied in [X.509].  Certification path
-   processing verifies the binding between the subject distinguished
-   name and/or subject alternative name and subject public key.  The
-   binding is limited by constraints which are specified in the
-
-
-
-Housley, et. al.            Standards Track                    [Page 62]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   certificates which comprise the path and inputs which are specified
-   by the relying party.  The basic constraints and policy constraints
-   extensions allow the certification path processing logic to automate
-   the decision making process.
-
-   This section describes an algorithm for validating certification
-   paths.  Conforming implementations of this specification are not
-   required to implement this algorithm, but MUST provide functionality
-   equivalent to the external behavior resulting from this procedure.
-   Any algorithm may be used by a particular implementation so long as
-   it derives the correct result.
-
-   In section 6.1, the text describes basic path validation.  Valid
-   paths begin with certificates issued by a trust anchor.  The
-   algorithm requires the public key of the CA, the CA's name, and any
-   constraints upon the set of paths which may be validated using this
-   key.
-
-   The selection of a trust anchor is a matter of policy: it could be
-   the top CA in a hierarchical PKI; the CA that issued the verifier's
-   own certificate(s); or any other CA in a network PKI.  The path
-   validation procedure is the same regardless of the choice of trust
-   anchor.  In addition, different applications may rely on different
-   trust anchor, or may accept paths that begin with any of a set of
-   trust anchor.
-
-   Section 6.2 describes methods for using the path validation algorithm
-   in specific implementations.  Two specific cases are discussed: the
-   case where paths may begin with one of several trusted CAs; and where
-   compatibility with the PEM architecture is required.
-
-   Section 6.3 describes the steps necessary to determine if a
-   certificate is revoked or on hold status when CRLs are the revocation
-   mechanism used by the certificate issuer.
-
-6.1  Basic Path Validation
-
-   This text describes an algorithm for X.509 path processing.  A
-   conformant implementation MUST include an X.509 path processing
-   procedure that is functionally equivalent to the external behavior of
-   this algorithm.  However, support for some of the certificate
-   extensions processed in this algorithm are OPTIONAL for compliant
-   implementations.  Clients that do not support these extensions MAY
-   omit the corresponding steps in the path validation algorithm.
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 63]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   For example, clients are NOT REQUIRED to support the policy mapping
-   extension.  Clients that do not support this extension MAY omit the
-   path validation steps where policy mappings are processed.  Note that
-   clients MUST reject the certificate if it contains an unsupported
-   critical extension.
-
-   The algorithm presented in this section validates the certificate
-   with respect to the current date and time.  A conformant
-   implementation MAY also support validation with respect to some point
-   in the past.  Note that mechanisms are not available for validating a
-   certificate with respect to a time outside the certificate validity
-   period.
-
-   The trust anchor is an input to the algorithm.  There is no
-   requirement that the same trust anchor be used to validate all
-   certification paths.  Different trust anchors MAY be used to validate
-   different paths, as discussed further in Section 6.2.
-
-   The primary goal of path validation is to verify the binding between
-   a subject distinguished name or a subject alternative name and
-   subject public key, as represented in the end entity certificate,
-   based on the public key of the trust anchor.  This requires obtaining
-   a sequence of certificates that support that binding.  The procedure
-   performed to obtain this sequence of certificates is outside the
-   scope of this specification.
-
-   To meet this goal, the path validation process verifies, among other
-   things, that a prospective certification path (a sequence of n
-   certificates) satisfies the following conditions:
-
-      (a)  for all x in {1, ..., n-1}, the subject of certificate x is
-      the issuer of certificate x+1;
-
-      (b)  certificate 1 is issued by the trust anchor;
-
-      (c)  certificate n is the certificate to be validated; and
-
-      (d)  for all x in {1, ..., n}, the certificate was valid at the
-      time in question.
-
-   When the trust anchor is provided in the form of a self-signed
-   certificate, this self-signed certificate is not included as part of
-   the prospective certification path.  Information about trust anchors
-   are provided as inputs to the certification path validation algorithm
-   (section 6.1.1).
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 64]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   A particular certification path may not, however, be appropriate for
-   all applications.  Therefore, an application MAY augment this
-   algorithm to further limit the set of valid paths.  The path
-   validation process also determines the set of certificate policies
-   that are valid for this path, based on the certificate policies
-   extension, policy mapping extension, policy constraints extension,
-   and inhibit any-policy extension.  To achieve this, the path
-   validation algorithm constructs a valid policy tree.  If the set of
-   certificate policies that are valid for this path is not empty, then
-   the result will be a valid policy tree of depth n, otherwise the
-   result will be a null valid policy tree.
-
-   A certificate is self-issued if the DNs that appear in the subject
-   and issuer fields are identical and are not empty.  In general, the
-   issuer and subject of the certificates that make up a path are
-   different for each certificate.  However, a CA may issue a
-   certificate to itself to support key rollover or changes in
-   certificate policies.  These self-issued certificates are not counted
-   when evaluating path length or name constraints.
-
-   This section presents the algorithm in four basic steps: (1)
-   initialization, (2) basic certificate processing, (3) preparation for
-   the next certificate, and (4) wrap-up.  Steps (1) and (4) are
-   performed exactly once.  Step (2) is performed for all certificates
-   in the path.  Step (3) is performed for all certificates in the path
-   except the final certificate.  Figure 2 provides a high-level
-   flowchart of this algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 65]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-                           +-------+
-                           | START |
-                           +-------+
-                               |
-                               V
-                       +----------------+
-                       | Initialization |
-                       +----------------+
-                               |
-                               +<--------------------+
-                               |                     |
-                               V                     |
-                       +----------------+            |
-                       |  Process Cert  |            |
-                       +----------------+            |
-                               |                     |
-                               V                     |
-                       +================+            |
-                       |  IF Last Cert  |            |
-                       |    in Path     |            |
-                       +================+            |
-                         |            |              |
-                    THEN |            | ELSE         |
-                         V            V              |
-              +----------------+ +----------------+  |
-              |    Wrap up     | |  Prepare for   |  |
-              +----------------+ |   Next Cert    |  |
-                      |          +----------------+  |
-                      V               |              |
-                  +-------+           +--------------+
-                  | STOP  |
-                  +-------+
-
-
-         Figure 2.  Certification Path Processing Flowchart
-
-6.1.1  Inputs
-
-   This algorithm assumes the following seven inputs are provided to the
-   path processing logic:
-
-      (a)  a prospective certification path of length n.
-
-      (b)  the current date/time.
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 66]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (c)  user-initial-policy-set:  A set of certificate policy
-      identifiers naming the policies that are acceptable to the
-      certificate user.  The user-initial-policy-set contains the
-      special value any-policy if the user is not concerned about
-      certificate policy.
-
-      (d)  trust anchor information, describing a CA that serves as a
-      trust anchor for the certification path.  The trust anchor
-      information includes:
-
-         (1)  the trusted issuer name,
-
-         (2)  the trusted public key algorithm,
-
-         (3)  the trusted public key, and
-
-         (4)  optionally, the trusted public key parameters associated
-         with the public key.
-
-      The trust anchor information may be provided to the path
-      processing procedure in the form of a self-signed certificate.
-      The trusted anchor information is trusted because it was delivered
-      to the path processing procedure by some trustworthy out-of-band
-      procedure.  If the trusted public key algorithm requires
-      parameters, then the parameters are provided along with the
-      trusted public key.
-
-      (e) initial-policy-mapping-inhibit, which indicates if policy
-      mapping is allowed in the certification path.
-
-      (f) initial-explicit-policy, which indicates if the path must be
-      valid for at least one of the certificate policies in the user-
-      initial-policy-set.
-
-      (g) initial-any-policy-inhibit, which indicates whether the
-      anyPolicy OID should be processed if it is included in a
-      certificate.
-
-6.1.2  Initialization
-
-   This initialization phase establishes eleven state variables based
-   upon the seven inputs:
-
-      (a)  valid_policy_tree:  A tree of certificate policies with their
-      optional qualifiers; each of the leaves of the tree represents a
-      valid policy at this stage in the certification path validation.
-      If valid policies exist at this stage in the certification path
-      validation, the depth of the tree is equal to the number of
-
-
-
-Housley, et. al.            Standards Track                    [Page 67]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      certificates in the chain that have been processed.  If valid
-      policies do not exist at this stage in the certification path
-      validation, the tree is set to NULL.  Once the tree is set to
-      NULL, policy processing ceases.
-
-      Each node in the valid_policy_tree includes four data objects: the
-      valid policy, a set of associated policy qualifiers, a set of one
-      or more expected policy values, and a criticality indicator.  If
-      the node is at depth x, the components of the node have the
-      following semantics:
-
-         (1)  The valid_policy is a single policy OID representing a
-         valid policy for the path of length x.
-
-         (2)  The qualifier_set is a set of policy qualifiers associated
-         with the valid policy in certificate x.
-
-         (3)  The criticality_indicator indicates whether the
-         certificate policy extension in certificate x was marked as
-         critical.
-
-         (4)  The expected_policy_set contains one or more policy OIDs
-         that would satisfy this policy in the certificate x+1.
-
-      The initial value of the valid_policy_tree is a single node with
-      valid_policy anyPolicy, an empty qualifier_set, an
-      expected_policy_set with the single value anyPolicy, and a
-      criticality_indicator of FALSE.  This node is considered to be at
-      depth zero.
-
-      Figure 3 is a graphic representation of the initial state of the
-      valid_policy_tree.  Additional figures will use this format to
-      describe changes in the valid_policy_tree during path processing.
-
-              +----------------+
-              |   anyPolicy    |   <---- valid_policy
-              +----------------+
-              |       {}       |   <---- qualifier_set
-              +----------------+
-              |     FALSE      |   <---- criticality_indicator
-              +----------------+
-              |  {anyPolicy}   |   <---- expected_policy_set
-              +----------------+
-
-      Figure 3.  Initial value of the valid_policy_tree state variable
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 68]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (b) permitted_subtrees:  A set of root names for each name type
-      (e.g., X.500 distinguished names, email addresses, or ip
-      addresses) defining a set of subtrees within which all subject
-      names in subsequent certificates in the certification path MUST
-      fall.  This variable includes a set for each name type: the
-      initial value for the set for Distinguished Names is the set of
-      all Distinguished names; the initial value for the set of RFC822
-      names is the set of all RFC822 names, etc.
-
-      (c) excluded_subtrees:  A set of root names for each name type
-      (e.g., X.500 distinguished names, email addresses, or ip
-      addresses) defining a set of subtrees within which no subject name
-      in subsequent certificates in the certification path may fall.
-      This variable includes a set for each name type, and the initial
-      value for each set is empty.
-
-      (d) explicit_policy: an integer which indicates if a non-NULL
-      valid_policy_tree is required. The integer indicates the number of
-      non-self-issued certificates to be processed before this
-      requirement is imposed.  Once set, this variable may be decreased,
-      but may not be increased. That is, if a certificate in the path
-      requires a non-NULL valid_policy_tree, a later certificate can not
-      remove this requirement. If initial-explicit-policy is set, then
-      the initial value is 0, otherwise the initial value is n+1.
-
-      (e) inhibit_any-policy: an integer which indicates whether the
-      anyPolicy policy identifier is considered a match. The integer
-      indicates the number of non-self-issued certificates to be
-      processed before the anyPolicy OID, if asserted in a certificate,
-      is ignored. Once set, this variable may be decreased, but may not
-      be increased. That is, if a certificate in the path inhibits
-      processing of anyPolicy, a later certificate can not permit it.
-      If initial-any-policy-inhibit is set, then the initial value is 0,
-      otherwise the initial value is n+1.
-
-      (f) policy_mapping: an integer which indicates if policy mapping
-      is permitted.  The integer indicates the number of non-self-issued
-      certificates to be processed before policy mapping is inhibited.
-      Once set, this variable may be decreased, but may not be
-      increased. That is, if a certificate in the path specifies policy
-      mapping is not permitted, it can not be overridden by a later
-      certificate. If initial-policy-mapping-inhibit is set, then the
-      initial value is 0, otherwise the initial value is n+1.
-
-      (g) working_public_key_algorithm: the digital signature algorithm
-      used to verify the signature of a certificate.  The
-      working_public_key_algorithm is initialized from the trusted
-      public key algorithm provided in the trust anchor information.
-
-
-
-Housley, et. al.            Standards Track                    [Page 69]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (h) working_public_key: the public key used to verify the
-      signature of a certificate.  The working_public_key is initialized
-      from the trusted public key provided in the trust anchor
-      information.
-
-      (i) working_public_key_parameters:  parameters associated with the
-      current public key, that may be required to verify a signature
-      (depending upon the algorithm).  The working_public_key_parameters
-      variable is initialized from the trusted public key parameters
-      provided in the trust anchor information.
-
-      (j) working_issuer_name:  the issuer distinguished name expected
-      in the next certificate in the chain.  The working_issuer_name is
-      initialized to the trusted issuer provided in the trust anchor
-      information.
-
-      (k) max_path_length:  this integer is initialized to n, is
-      decremented for each non-self-issued certificate in the path, and
-      may be reduced to the value in the path length constraint field
-      within the basic constraints extension of a CA certificate.
-
-   Upon completion of the initialization steps, perform the basic
-   certificate processing steps specified in 6.1.3.
-
-6.1.3  Basic Certificate Processing
-
-   The basic path processing actions to be performed for certificate i
-   (for all i in [1..n]) are listed below.
-
-      (a)  Verify the basic certificate information.  The certificate
-      MUST satisfy each of the following:
-
-         (1)  The certificate was signed with the
-         working_public_key_algorithm using the working_public_key and
-         the working_public_key_parameters.
-
-         (2)  The certificate validity period includes the current time.
-
-         (3)  At the current time, the certificate is not revoked and is
-         not on hold status.  This may be determined by obtaining the
-         appropriate CRL (section 6.3), status information, or by out-
-         of-band mechanisms.
-
-         (4)  The certificate issuer name is the working_issuer_name.
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 70]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (b)  If certificate i is self-issued and it is not the final
-      certificate in the path, skip this step for certificate i.
-      Otherwise, verify that the subject name is within one of the
-      permitted_subtrees for X.500 distinguished names, and verify that
-      each of the alternative names in the subjectAltName extension
-      (critical or non-critical) is within one of the permitted_subtrees
-      for that name type.
-
-      (c)  If certificate i is self-issued and it is not the final
-      certificate in the path, skip this step for certificate i.
-      Otherwise, verify that the subject name is not within one of the
-      excluded_subtrees for X.500 distinguished names, and verify that
-      each of the alternative names in the subjectAltName extension
-      (critical or non-critical) is not within one of the
-      excluded_subtrees for that name type.
-
-      (d)  If the certificate policies extension is present in the
-      certificate and the valid_policy_tree is not NULL, process the
-      policy information by performing the following steps in order:
-
-         (1)  For each policy P not equal to anyPolicy in the
-         certificate policies extension, let P-OID denote the OID in
-         policy P and P-Q denote the qualifier set for policy P.
-         Perform the following steps in order:
-
-            (i)  If the valid_policy_tree includes a node of depth i-1
-            where P-OID is in the expected_policy_set, create a child
-            node as follows: set the valid_policy to OID-P; set the
-            qualifier_set to P-Q, and set the expected_policy_set to
-            {P-OID}.
-
-            For example, consider a valid_policy_tree with a node of
-            depth i-1 where the expected_policy_set is {Gold, White}.
-            Assume the certificate policies Gold and Silver appear in
-            the certificate policies extension of certificate i.  The
-            Gold policy is matched but the Silver policy is not.  This
-            rule will generate a child node of depth i for the Gold
-            policy. The result is shown as Figure 4.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 71]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-                             +-----------------+
-                             |       Red       |
-                             +-----------------+
-                             |       {}        |
-                             +-----------------+   node of depth i-1
-                             |      FALSE      |
-                             +-----------------+
-                             |  {Gold, White}  |
-                             +-----------------+
-                                      |
-                                      |
-                                      |
-                                      V
-                             +-----------------+
-                             |      Gold       |
-                             +-----------------+
-                             |       {}        |
-                             +-----------------+ node of depth i
-                             |  uninitialized  |
-                             +-----------------+
-                             |     {Gold}      |
-                             +-----------------+
-
-                    Figure 4.  Processing an exact match
-
-            (ii)  If there was no match in step (i) and the
-            valid_policy_tree includes a node of depth i-1 with the
-            valid policy anyPolicy, generate a child node with the
-            following values: set the valid_policy to P-OID; set the
-            qualifier_set to P-Q, and set the expected_policy_set to
-            {P-OID}.
-
-            For example, consider a valid_policy_tree with a node of
-            depth i-1 where the valid_policy is anyPolicy.  Assume the
-            certificate policies Gold and Silver appear in the
-            certificate policies extension of certificate i.  The Gold
-            policy does not have a qualifier, but the Silver policy has
-            the qualifier Q-Silver.  If Gold and Silver were not matched
-            in (i) above, this rule will generate two child nodes of
-            depth i, one for each policy.  The result is shown as Figure
-            5.
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 72]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-                             +-----------------+
-                             |    anyPolicy    |
-                             +-----------------+
-                             |       {}        |
-                             +-----------------+ node of depth i-1
-                             |      FALSE      |
-                             +-----------------+
-                             |   {anyPolicy}   |
-                             +-----------------+
-                                /           \
-                               /             \
-                              /               \
-                             /                 \
-               +-----------------+          +-----------------+
-               |      Gold       |          |     Silver      |
-               +-----------------+          +-----------------+
-               |       {}        |          |   {Q-Silver}    |
-               +-----------------+ nodes of +-----------------+
-               | uninitialized   | depth i  | uninitialized   |
-               +-----------------+          +-----------------+
-               |     {Gold}      |          |    {Silver}     |
-               +-----------------+          +-----------------+
-
-               Figure 5.  Processing unmatched policies when a leaf node
-               specifies anyPolicy
-
-         (2)  If the certificate policies extension includes the policy
-         anyPolicy with the qualifier set AP-Q and either (a)
-         inhibit_any-policy is greater than 0 or (b) i<n and the
-         certificate is self-issued, then:
-
-         For each node in the valid_policy_tree of depth i-1, for each
-         value in the expected_policy_set (including anyPolicy) that
-         does not appear in a child node, create a child node with the
-         following values: set the valid_policy to the value from the
-         expected_policy_set in the parent node; set the qualifier_set
-         to AP-Q, and set the expected_policy_set to the value in the
-         valid_policy from this node.
-
-         For example, consider a valid_policy_tree with a node of depth
-         i-1 where the expected_policy_set is {Gold, Silver}.  Assume
-         anyPolicy appears in the certificate policies extension of
-         certificate i, but Gold and Silver do not.  This rule will
-         generate two child nodes of depth i, one for each policy.  The
-         result is shown below as Figure 6.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 73]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-                          +-----------------+
-                          |      Red        |
-                          +-----------------+
-                          |       {}        |
-                          +-----------------+ node of depth i-1
-                          |      FALSE      |
-                          +-----------------+
-                          |  {Gold, Silver} |
-                          +-----------------+
-                             /           \
-                            /             \
-                           /               \
-                          /                 \
-            +-----------------+          +-----------------+
-            |      Gold       |          |     Silver      |
-            +-----------------+          +-----------------+
-            |       {}        |          |       {}        |
-            +-----------------+ nodes of +-----------------+
-            |  uninitialized  | depth i  |  uninitialized  |
-            +-----------------+          +-----------------+
-            |     {Gold}      |          |    {Silver}     |
-            +-----------------+          +-----------------+
-
-         Figure 6.  Processing unmatched policies when the certificate
-         policies extension specifies anyPolicy
-
-         (3)  If there is a node in the valid_policy_tree of depth i-1
-         or less without any child nodes, delete that node.  Repeat this
-         step until there are no nodes of depth i-1 or less without
-         children.
-
-         For example, consider the valid_policy_tree shown in Figure 7
-         below.  The two nodes at depth i-1 that are marked with an 'X'
-         have no children, and are deleted.  Applying this rule to the
-         resulting tree will cause the node at depth i-2 that is marked
-         with an 'Y' to be deleted.  The following application of the
-         rule does not cause any nodes to be deleted, and this step is
-         complete.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 74]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-                              +-----------+
-                              |           | node of depth i-3
-                              +-----------+
-                              /     |     \
-                             /      |      \
-                            /       |       \
-                +-----------+ +-----------+ +-----------+
-                |           | |           | |     Y     | nodes of
-                +-----------+ +-----------+ +-----------+ depth i-2
-                /   \               |             |
-               /     \              |             |
-              /       \             |             |
-   +-----------+ +-----------+ +-----------+ +-----------+ nodes of
-   |           | |     X     | |           | |    X      |  depth
-   +-----------+ +-----------+ +-----------+ +-----------+   i-1
-         |                      /    |    \
-         |                     /     |     \
-         |                    /      |      \
-   +-----------+ +-----------+ +-----------+ +-----------+ nodes of
-   |           | |           | |           | |           |  depth
-   +-----------+ +-----------+ +-----------+ +-----------+   i
-
-          Figure 7.  Pruning the valid_policy_tree
-
-         (4)  If the certificate policies extension was marked as
-         critical, set the criticality_indicator in all nodes of depth i
-         to TRUE.  If the certificate policies extension was not marked
-         critical, set the criticality_indicator in all nodes of depth i
-         to FALSE.
-
-      (e)  If the certificate policies extension is not present, set the
-      valid_policy_tree to NULL.
-
-      (f)  Verify that either explicit_policy is greater than 0 or the
-      valid_policy_tree is not equal to NULL;
-
-   If any of steps (a), (b), (c), or (f) fails, the procedure
-   terminates, returning a failure indication and an appropriate reason.
-
-   If i is not equal to n, continue by performing the preparatory steps
-   listed in 6.1.4.  If i is equal to n, perform the wrap-up steps
-   listed in 6.1.5.
-
-6.1.4  Preparation for Certificate i+1
-
-   To prepare for processing of certificate i+1, perform the following
-   steps for certificate i:
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 75]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (a)  If a policy mapping extension is present, verify that the
-      special value anyPolicy does not appear as an issuerDomainPolicy
-      or a subjectDomainPolicy.
-
-      (b)  If a policy mapping extension is present, then for each
-      issuerDomainPolicy ID-P in the policy mapping extension:
-
-         (1)  If the policy_mapping variable is greater than 0, for each
-         node in the valid_policy_tree of depth i where ID-P is the
-         valid_policy, set expected_policy_set to the set of
-         subjectDomainPolicy values that are specified as equivalent to
-         ID-P by the policy mapping extension.
-
-         If no node of depth i in the valid_policy_tree has a
-         valid_policy of ID-P but there is a node of depth i with a
-         valid_policy of anyPolicy, then generate a child node of the
-         node of depth i-1 that has a valid_policy of anyPolicy as
-         follows:
-
-            (i)  set the valid_policy to ID-P;
-
-            (ii)  set the qualifier_set to the qualifier set of the
-            policy anyPolicy in the certificate policies extension of
-            certificate i;
-
-            (iii)  set the criticality_indicator to the criticality of
-            the certificate policies extension of certificate i;
-
-            (iv)  and set the expected_policy_set to the set of
-            subjectDomainPolicy values that are specified as equivalent
-            to ID-P by the policy mappings extension.
-
-         (2)  If the policy_mapping variable is equal to 0:
-
-            (i)  delete each node of depth i in the valid_policy_tree
-            where ID-P is the valid_policy.
-
-            (ii)  If there is a node in the valid_policy_tree of depth
-            i-1 or less without any child nodes, delete that node.
-            Repeat this step until there are no nodes of depth i-1 or
-            less without children.
-
-      (c)  Assign the certificate subject name to working_issuer_name.
-
-      (d)  Assign the certificate subjectPublicKey to
-      working_public_key.
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 76]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (e)  If the subjectPublicKeyInfo field of the certificate contains
-      an algorithm field with non-null parameters, assign the parameters
-      to the working_public_key_parameters variable.
-
-      If the subjectPublicKeyInfo field of the certificate contains an
-      algorithm field with null parameters or parameters are omitted,
-      compare the certificate subjectPublicKey algorithm to the
-      working_public_key_algorithm.  If the certificate subjectPublicKey
-      algorithm and the working_public_key_algorithm are different, set
-      the working_public_key_parameters to null.
-
-      (f)  Assign the certificate subjectPublicKey algorithm to the
-      working_public_key_algorithm variable.
-
-      (g)  If a name constraints extension is included in the
-      certificate, modify the permitted_subtrees and excluded_subtrees
-      state variables as follows:
-
-         (1)  If permittedSubtrees is present in the certificate, set
-         the permitted_subtrees state variable to the intersection of
-         its previous value and the value indicated in the extension
-         field.  If permittedSubtrees does not include a particular name
-         type, the permitted_subtrees state variable is unchanged for
-         that name type.  For example, the intersection of nist.gov and
-         csrc.nist.gov is csrc.nist.gov.  And, the intersection of
-         nist.gov and rsasecurity.com is the empty set.
-
-         (2)  If excludedSubtrees is present in the certificate, set the
-         excluded_subtrees state variable to the union of its previous
-         value and the value indicated in the extension field.  If
-         excludedSubtrees does not include a particular name type, the
-         excluded_subtrees state variable is unchanged for that name
-         type.  For example, the union of the name spaces nist.gov and
-         csrc.nist.gov is nist.gov.  And, the union of nist.gov and
-         rsasecurity.com is both name spaces.
-
-      (h)  If the issuer and subject names are not identical:
-
-         (1)  If explicit_policy is not 0, decrement explicit_policy by
-         1.
-
-         (2)  If policy_mapping is not 0, decrement policy_mapping by 1.
-
-         (3)  If inhibit_any-policy is not 0, decrement inhibit_any-
-         policy by 1.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 77]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (i)  If a policy constraints extension is included in the
-      certificate, modify the explicit_policy and policy_mapping state
-      variables as follows:
-
-         (1)  If requireExplicitPolicy is present and is less than
-         explicit_policy, set explicit_policy to the value of
-         requireExplicitPolicy.
-
-         (2)  If inhibitPolicyMapping is present and is less than
-         policy_mapping, set policy_mapping to the value of
-         inhibitPolicyMapping.
-
-      (j)  If the inhibitAnyPolicy extension is included in the
-      certificate and is less than inhibit_any-policy, set inhibit_any-
-      policy to the value of inhibitAnyPolicy.
-
-      (k)  Verify that the certificate is a CA certificate (as specified
-      in a basicConstraints extension or as verified out-of-band).
-
-      (l)  If the certificate was not self-issued, verify that
-      max_path_length is greater than zero and decrement max_path_length
-      by 1.
-
-      (m)  If pathLengthConstraint is present in the certificate and is
-      less than max_path_length, set max_path_length to the value of
-      pathLengthConstraint.
-
-      (n)  If a key usage extension is present, verify that the
-      keyCertSign bit is set.
-
-      (o)  Recognize and process any other critical extension present in
-      the certificate.  Process any other recognized non-critical
-      extension present in the certificate.
-
-   If check (a), (k), (l), (n) or (o) fails, the procedure terminates,
-   returning a failure indication and an appropriate reason.
-
-   If (a), (k), (l), (n) and (o) have completed successfully, increment
-   i and perform the basic certificate processing specified in 6.1.3.
-
-6.1.5  Wrap-up procedure
-
-   To complete the processing of the end entity certificate, perform the
-   following steps for certificate n:
-
-      (a)  If certificate n was not self-issued and explicit_policy is
-      not 0, decrement explicit_policy by 1.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 78]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (b)  If a policy constraints extension is included in the
-      certificate and requireExplicitPolicy is present and has a value
-      of 0, set the explicit_policy state variable to 0.
-
-      (c)  Assign the certificate subjectPublicKey to
-      working_public_key.
-
-      (d)  If the subjectPublicKeyInfo field of the certificate contains
-      an algorithm field with non-null parameters, assign the parameters
-      to the working_public_key_parameters variable.
-
-      If the subjectPublicKeyInfo field of the certificate contains an
-      algorithm field with null parameters or parameters are omitted,
-      compare the certificate subjectPublicKey algorithm to the
-      working_public_key_algorithm.  If the certificate subjectPublicKey
-      algorithm and the working_public_key_algorithm are different, set
-      the working_public_key_parameters to null.
-
-      (e)  Assign the certificate subjectPublicKey algorithm to the
-      working_public_key_algorithm variable.
-
-      (f)  Recognize and process any other critical extension present in
-      the certificate n.  Process any other recognized non-critical
-      extension present in certificate n.
-
-      (g)  Calculate the intersection of the valid_policy_tree and the
-      user-initial-policy-set, as follows:
-
-         (i)  If the valid_policy_tree is NULL, the intersection is
-         NULL.
-
-         (ii)  If the valid_policy_tree is not NULL and the user-
-         initial-policy-set is any-policy, the intersection is the
-         entire valid_policy_tree.
-
-         (iii)  If the valid_policy_tree is not NULL and the user-
-         initial-policy-set is not any-policy, calculate the
-         intersection of the valid_policy_tree and the user-initial-
-         policy-set as follows:
-
-            1.  Determine the set of policy nodes whose parent nodes
-            have a valid_policy of anyPolicy.  This is the
-            valid_policy_node_set.
-
-            2.  If the valid_policy of any node in the
-            valid_policy_node_set is not in the user-initial-policy-set
-            and is not anyPolicy, delete this node and all its children.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 79]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-            3.  If the valid_policy_tree includes a node of depth n with
-            the valid_policy anyPolicy and the user-initial-policy-set
-            is not any-policy perform the following steps:
-
-               a. Set P-Q to the qualifier_set in the node of depth n
-               with valid_policy anyPolicy.
-
-               b. For each P-OID in the user-initial-policy-set that is
-               not the valid_policy of a node in the
-               valid_policy_node_set, create a child node whose parent
-               is the node of depth n-1 with the valid_policy anyPolicy.
-               Set the values in the child node as follows: set the
-               valid_policy to P-OID; set the qualifier_set to P-Q; copy
-               the criticality_indicator from the node of depth n with
-               the valid_policy anyPolicy; and set the
-               expected_policy_set to {P-OID}.
-
-               c.  Delete the node of depth n with the valid_policy
-               anyPolicy.
-
-            4.  If there is a node in the valid_policy_tree of depth n-1
-            or less without any child nodes, delete that node.  Repeat
-            this step until there are no nodes of depth n-1 or less
-            without children.
-
-   If either (1) the value of explicit_policy variable is greater than
-   zero, or (2) the valid_policy_tree is not NULL, then path processing
-   has succeeded.
-
-6.1.6  Outputs
-
-   If path processing succeeds, the procedure terminates, returning a
-   success indication together with final value of the
-   valid_policy_tree, the working_public_key, the
-   working_public_key_algorithm, and the working_public_key_parameters.
-
-6.2  Using the Path Validation Algorithm
-
-   The path validation algorithm describes the process of validating a
-   single certification path.  While each certification path begins with
-   a specific trust anchor, there is no requirement that all
-   certification paths validated by a particular system share a single
-   trust anchor.  An implementation that supports multiple trust anchors
-   MAY augment the algorithm presented in section 6.1 to further limit
-   the set of valid certification paths which begin with a particular
-   trust anchor.  For example, an implementation MAY modify the
-   algorithm to apply name constraints to a specific trust anchor during
-   the initialization phase, or the application MAY require the presence
-
-
-
-Housley, et. al.            Standards Track                    [Page 80]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   of a particular alternative name form in the end entity certificate,
-   or the application MAY impose requirements on application-specific
-   extensions.  Thus, the path validation algorithm presented in section
-   6.1 defines the minimum conditions for a path to be considered valid.
-
-   The selection of one or more trusted CAs is a local decision.  A
-   system may provide any one of its trusted CAs as the trust anchor for
-   a particular path.  The inputs to the path validation algorithm may
-   be different for each path.  The inputs used to process a path may
-   reflect application-specific requirements or limitations in the trust
-   accorded a particular trust anchor.  For example, a trusted CA may
-   only be trusted for a particular certificate policy.  This
-   restriction can be expressed through the inputs to the path
-   validation procedure.
-
-   It is also possible to specify an extended version of the above
-   certification path processing procedure which results in default
-   behavior identical to the rules of PEM [RFC 1422].  In this extended
-   version, additional inputs to the procedure are a list of one or more
-   Policy Certification Authority (PCA) names and an indicator of the
-   position in the certification path where the PCA is expected.  At the
-   nominated PCA position, the CA name is compared against this list.
-   If a recognized PCA name is found, then a constraint of
-   SubordinateToCA is implicitly assumed for the remainder of the
-   certification path and processing continues.  If no valid PCA name is
-   found, and if the certification path cannot be validated on the basis
-   of identified policies, then the certification path is considered
-   invalid.
-
-6.3  CRL Validation
-
-   This section describes the steps necessary to determine if a
-   certificate is revoked or on hold status when CRLs are the revocation
-   mechanism used by the certificate issuer.  Conforming implementations
-   that support CRLs are not required to implement this algorithm, but
-   they MUST be functionally equivalent to the external behavior
-   resulting from this procedure.  Any algorithm may be used by a
-   particular implementation so long as it derives the correct result.
-
-   This algorithm assumes that all of the needed CRLs are available in a
-   local cache.  Further, if the next update time of a CRL has passed,
-   the algorithm assumes a mechanism to fetch a current CRL and place it
-   in the local CRL cache.
-
-   This algorithm defines a set of inputs, a set of state variables, and
-   processing steps that are performed for each certificate in the path.
-   The algorithm output is the revocation status of the certificate.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 81]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-6.3.1  Revocation Inputs
-
-   To support revocation processing, the algorithm requires two inputs:
-
-      (a)  certificate:  The algorithm requires the certificate serial
-      number and issuer name to determine whether a certificate is on a
-      particular CRL.  The basicConstraints extension is used to
-      determine whether the supplied certificate is associated with a CA
-      or an end entity.  If present, the algorithm uses the
-      cRLDistributionsPoint and freshestCRL extensions to determine
-      revocation status.
-
-      (b)  use-deltas:  This boolean input determines whether delta CRLs
-      are applied to CRLs.
-
-      Note that implementations supporting legacy PKIs, such as RFC 1422
-      and X.509 version 1, will need an additional input indicating
-      whether the supplied certificate is associated with a CA or an end
-      entity.
-
-6.3.2  Initialization and Revocation State Variables
-
-   To support CRL processing, the algorithm requires the following state
-   variables:
-
-      (a)  reasons_mask:  This variable contains the set of revocation
-      reasons supported by the CRLs and delta CRLs processed so far.
-      The legal members of the set are the possible revocation reason
-      values: unspecified, keyCompromise, caCompromise,
-      affiliationChanged, superseded, cessationOfOperation,
-      certificateHold, privilegeWithdrawn, and aACompromise.  The
-      special value all-reasons is used to denote the set of all legal
-      members.  This variable is initialized to the empty set.
-
-      (b)  cert_status:  This variable contains the status of the
-      certificate.  This variable may be assigned one of the following
-      values: unspecified, keyCompromise, caCompromise,
-      affiliationChanged, superseded, cessationOfOperation,
-      certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise,
-      the special value UNREVOKED, or the special value UNDETERMINED.
-      This variable is initialized to the special value UNREVOKED.
-
-      (c)  interim_reasons_mask:  This contains the set of revocation
-      reasons supported by the CRL or delta CRL currently being
-      processed.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 82]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   Note: In some environments, it is not necessary to check all reason
-   codes.  For example, some environments are only concerned with
-   caCompromise and keyCompromise for CA certificates.  This algorithm
-   checks all reason codes.  Additional processing and state variables
-   may be necessary to limit the checking to a subset of the reason
-   codes.
-
-6.3.3  CRL Processing
-
-   This algorithm begins by assuming the certificate is not revoked.
-   The algorithm checks one or more CRLs until either the certificate
-   status is determined to be revoked or sufficient CRLs have been
-   checked to cover all reason codes.
-
-   For each distribution point (DP) in the certificate CRL distribution
-   points extension, for each corresponding CRL in the local CRL cache,
-   while ((reasons_mask is not all-reasons) and (cert_status is
-   UNREVOKED)) perform the following:
-
-      (a)  Update the local CRL cache by obtaining a complete CRL, a
-      delta CRL, or both, as required:
-
-         (1)  If the current time is after the value of the CRL next
-         update field, then do one of the following:
-
-            (i)  If use-deltas is set and either the certificate or the
-            CRL contains the freshest CRL extension, obtain a delta CRL
-            with the a next update value that is after the current time
-            and can be used to update the locally cached CRL as
-            specified in section 5.2.4.
-
-            (ii)  Update the local CRL cache with a current complete
-            CRL, verify that the current time is before the next update
-            value in the new CRL, and continue processing with the new
-            CRL.  If use-deltas is set, then obtain the current delta
-            CRL that can be used to update the new locally cached
-            complete CRL as specified in section 5.2.4.
-
-         (2)  If the current time is before the value of the next update
-         field and use-deltas is set, then obtain the current delta CRL
-         that can be used to update the locally cached complete CRL as
-         specified in section 5.2.4.
-
-      (b)  Verify the issuer and scope of the complete CRL as follows:
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 83]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-         (1)  If the DP includes cRLIssuer, then verify that the issuer
-         field in the complete CRL matches cRLIssuer in the DP and that
-         the complete CRL contains an issuing distribution point
-         extension with the indrectCRL boolean asserted.  Otherwise,
-         verify that the CRL issuer matches the certificate issuer.
-
-         (2)  If the complete CRL includes an issuing distribution point
-         (IDP) CRL extension check the following:
-
-            (i)  If the distribution point name is present in the IDP
-            CRL extension and the distribution field is present in the
-            DP, then verify that one of the names in the IDP matches one
-            of the names in the DP.  If the distribution point name is
-            present in the IDP CRL extension and the distribution field
-            is omitted from the DP, then verify that one of the names in
-            the IDP matches one of the names in the cRLIssuer field of
-            the DP.
-
-            (ii)  If the onlyContainsUserCerts boolean is asserted in
-            the IDP CRL extension, verify that the certificate does not
-            include the basic constraints extension with the cA boolean
-            asserted.
-
-            (iii)  If the onlyContainsCACerts boolean is asserted in the
-            IDP CRL extension, verify that the certificate includes the
-            basic constraints extension with the cA boolean asserted.
-
-            (iv)  Verify that the onlyContainsAttributeCerts boolean is
-            not asserted.
-
-      (c)  If use-deltas is set, verify the issuer and scope of the
-      delta CRL as follows:
-
-         (1)  Verify that the delta CRL issuer matches complete CRL
-         issuer.
-
-         (2)  If the complete CRL includes an issuing distribution point
-         (IDP) CRL extension, verify that the delta CRL contains a
-         matching IDP CRL extension.  If the complete CRL omits an IDP
-         CRL extension, verify that the delta CRL also omits an IDP CRL
-         extension.
-
-         (3)  Verify that the delta CRL authority key identifier
-         extension matches complete CRL authority key identifier
-         extension.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 84]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   (d)  Compute the interim_reasons_mask for this CRL as follows:
-
-         (1)  If the issuing distribution point (IDP) CRL extension is
-         present and includes onlySomeReasons and the DP includes
-         reasons, then set interim_reasons_mask to the intersection of
-         reasons in the DP and onlySomeReasons in IDP CRL extension.
-
-         (2)  If the IDP CRL extension includes onlySomeReasons but the
-         DP omits reasons, then set interim_reasons_mask to the value of
-         onlySomeReasons in IDP CRL extension.
-
-         (3)  If the IDP CRL extension is not present or omits
-         onlySomeReasons but the DP includes reasons, then set
-         interim_reasons_mask to the value of DP reasons.
-
-         (4)  If the IDP CRL extension is not present or omits
-         onlySomeReasons and the DP omits reasons, then set
-         interim_reasons_mask to the special value all-reasons.
-
-   (e)  Verify that interim_reasons_mask includes one or more reasons
-   that is not included in the reasons_mask.
-
-   (f)  Obtain and validate the certification path for the complete CRL
-   issuer.  If a key usage extension is present in the CRL issuer's
-   certificate, verify that the cRLSign bit is set.
-
-   (g)  Validate the signature on the complete CRL using the public key
-   validated in step (f).
-
-   (h)  If use-deltas is set, then validate the signature on the delta
-   CRL using the public key validated in step (f).
-
-   (i)  If use-deltas is set, then search for the certificate on the
-   delta CRL.  If an entry is found that matches the certificate issuer
-   and serial number as described in section 5.3.4, then set the
-   cert_status variable to the indicated reason as follows:
-
-         (1)  If the reason code CRL entry extension is present, set the
-         cert_status variable to the value of the reason code CRL entry
-         extension.
-
-         (2)  If the reason code CRL entry extension is not present, set
-         the cert_status variable to the value unspecified.
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 85]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (j)  If (cert_status is UNREVOKED), then search for the
-      certificate on the complete CRL.  If an entry is found that
-      matches the certificate issuer and serial number as described in
-      section 5.3.4, then set the cert_status variable to the indicated
-      reason as described in step (i).
-
-      (k)  If (cert_status is removeFromCRL), then set cert_status to
-      UNREVOKED.
-
-   If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)),
-   then the revocation status has been determined, so return
-   cert_status.
-
-   If the revocation status has not been determined, repeat the process
-   above with any available CRLs not specified in a distribution point
-   but issued by the certificate issuer.  For the processing of such a
-   CRL, assume a DP with both the reasons and the cRLIssuer fields
-   omitted and a distribution point name of the certificate issuer.
-   That is, the sequence of names in fullName is generated from the
-   certificate issuer field as well as the certificate issuerAltName
-   extension.  If the revocation status remains undetermined, then
-   return the cert_status UNDETERMINED.
-
-7  References
-
-   [ISO 10646] ISO/IEC 10646-1:1993.  International Standard --
-               Information technology -- Universal Multiple-Octet Coded
-               Character Set (UCS) -- Part 1: Architecture and Basic
-               Multilingual Plane.
-
-   [RFC 791]   Postel, J.,  "Internet Protocol", STD 5, RFC 791,
-               September 1981.
-
-   [RFC 822]   Crocker, D., "Standard for the format of ARPA Internet
-               text messages", STD 11, RFC 822, August 1982.
-
-   [RFC 1034]  Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1422]  Kent, S., "Privacy Enhancement for Internet Electronic
-               Mail: Part II: Certificate-Based Key Management," RFC
-               1422, February 1993.
-
-   [RFC 1423]  Balenson, D., "Privacy Enhancement for Internet
-               Electronic Mail: Part III: Algorithms, Modes, and
-               Identifiers," RFC 1423, February 1993.
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 86]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   [RFC 1510]  Kohl, J. and C. Neuman, "The Kerberos Network
-               Authentication Service (V5)," RFC 1510, September 1993.
-
-   [RFC 1519]  Fuller, V., T. Li, J. Yu and K. Varadhan, "Classless
-               Inter-Domain Routing (CIDR): An Address Assignment and
-               Aggregation Strategy", RFC 1519, September 1993.
-
-   [RFC 1738]  Berners-Lee, T., L. Masinter and M. McCahill, "Uniform
-               Resource Locators (URL)", RFC 1738, December 1994.
-
-   [RFC 1778]  Howes, T., S. Kille, W. Yeong and C. Robbins, "The String
-               Representation of Standard Attribute Syntaxes," RFC 1778,
-               March 1995.
-
-   [RFC 1883]  Deering, S. and R. Hinden.  "Internet Protocol, Version 6
-               (IPv6) Specification", RFC 1883, December 1995.
-
-   [RFC 2044]  F. Yergeau, F., "UTF-8, a transformation format of
-               Unicode and ISO 10646", RFC 2044, October 1996.
-
-   [RFC 2119]  Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2247]  Kille, S., M. Wahl, A. Grimstad, R. Huber and S.
-               Sataluri, "Using Domains in LDAP/X.500 Distinguished
-               Names", RFC 2247, January 1998.
-
-   [RFC 2252]  Wahl, M., A. Coulbeck, T. Howes and S. Kille,
-               "Lightweight Directory Access Protocol (v3):  Attribute
-               Syntax Definitions", RFC 2252, December 1997.
-
-   [RFC 2277]  Alvestrand, H., "IETF Policy on Character Sets and
-               Languages", BCP 18, RFC 2277, January 1998.
-
-   [RFC 2279]  Yergeau, F., "UTF-8, a transformation format of ISO
-               10646", RFC 2279, January 1998.
-
-   [RFC 2459]  Housley, R., W. Ford, W. Polk and D. Solo, "Internet
-               X.509 Public Key Infrastructure: Certificate and CRL
-               Profile", RFC 2459, January 1999.
-
-   [RFC 2560]  Myers, M., R. Ankney, A. Malpani, S. Galperin and C.
-               Adams, "Online Certificate Status Protocal - OCSP", June
-               1999.
-
-   [SDN.701]   SDN.701, "Message Security Protocol 4.0", Revision A,
-               1997-02-06.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 87]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   [X.501]     ITU-T Recommendation X.501: Information Technology - Open
-               Systems Interconnection - The Directory: Models, 1993.
-
-   [X.509]     ITU-T Recommendation X.509 (1997 E): Information
-               Technology - Open Systems Interconnection - The
-               Directory: Authentication Framework, June 1997.
-
-   [X.520]     ITU-T Recommendation X.520: Information Technology - Open
-               Systems Interconnection - The Directory: Selected
-               Attribute Types, 1993.
-
-   [X.660]     ITU-T Recommendation X.660 Information Technology - ASN.1
-               encoding rules: Specification of Basic Encoding Rules
-               (BER), Canonical Encoding Rules (CER) and Distinguished
-               Encoding Rules (DER), 1997.
-
-   [X.690]     ITU-T Recommendation X.690 Information Technology - Open
-               Systems Interconnection - Procedures for the operation of
-               OSI Registration Authorities: General procedures, 1992.
-
-   [X9.55]     ANSI X9.55-1995, Public Key Cryptography For The
-               Financial Services Industry: Extensions To Public Key
-               Certificates And Certificate Revocation Lists, 8
-               December, 1995.
-
-   [PKIXALGS]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
-               Identifiers for the Internet X.509 Public Key
-               Infrastructure Certificate and Certificate Revocation
-               Lists (CRL) Profile", RFC 3279, April 2002.
-
-   [PKIXTSA]   Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,
-               "Internet X.509 Public Key Infrastructure Time-Stamp
-               Protocol (TSP)", RFC 3161, August 2001.
-
-8  Intellectual Property Rights
-
-   The IETF has been notified of intellectual property rights claimed in
-   regard to some or all of the specification contained in this
-   document.  For more information consult the online list of claimed
-   rights (see http://www.ietf.org/ipr.html).
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-
-
-
-Housley, et. al.            Standards Track                    [Page 88]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   standards-related documentation can be found in BCP 11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-9  Security Considerations
-
-   The majority of this specification is devoted to the format and
-   content of certificates and CRLs.  Since certificates and CRLs are
-   digitally signed, no additional integrity service is necessary.
-   Neither certificates nor CRLs need be kept secret, and unrestricted
-   and anonymous access to certificates and CRLs has no security
-   implications.
-
-   However, security factors outside the scope of this specification
-   will affect the assurance provided to certificate users.  This
-   section highlights critical issues to be considered by implementers,
-   administrators, and users.
-
-   The procedures performed by CAs and RAs to validate the binding of
-   the subject's identity to their public key greatly affect the
-   assurance that ought to be placed in the certificate.  Relying
-   parties might wish to review the CA's certificate practice statement.
-   This is particularly important when issuing certificates to other
-   CAs.
-
-   The use of a single key pair for both signature and other purposes is
-   strongly discouraged.  Use of separate key pairs for signature and
-   key management provides several benefits to the users.  The
-   ramifications associated with loss or disclosure of a signature key
-   are different from loss or disclosure of a key management key.  Using
-   separate key pairs permits a balanced and flexible response.
-   Similarly, different validity periods or key lengths for each key
-   pair may be appropriate in some application environments.
-   Unfortunately, some legacy applications (e.g., SSL) use a single key
-   pair for signature and key management.
-
-   The protection afforded private keys is a critical security factor.
-   On a small scale, failure of users to protect their private keys will
-   permit an attacker to masquerade as them, or decrypt their personal
-   information.  On a larger scale, compromise of a CA's private signing
-   key may have a catastrophic effect.  If an attacker obtains the
-   private key unnoticed, the attacker may issue bogus certificates and
-   CRLs.  Existence of bogus certificates and CRLs will undermine
-   confidence in the system.  If such a compromise is detected, all
-   certificates issued to the compromised CA MUST be revoked, preventing
-
-
-
-Housley, et. al.            Standards Track                    [Page 89]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   services between its users and users of other CAs.  Rebuilding after
-   such a compromise will be problematic, so CAs are advised to
-   implement a combination of strong technical measures (e.g., tamper-
-   resistant cryptographic modules) and appropriate management
-   procedures (e.g., separation of duties) to avoid such an incident.
-
-   Loss of a CA's private signing key may also be problematic.  The CA
-   would not be able to produce CRLs or perform normal key rollover.
-   CAs SHOULD maintain secure backup for signing keys.  The security of
-   the key backup procedures is a critical factor in avoiding key
-   compromise.
-
-   The availability and freshness of revocation information affects the
-   degree of assurance that ought to be placed in a certificate.  While
-   certificates expire naturally, events may occur during its natural
-   lifetime which negate the binding between the subject and public key.
-   If revocation information is untimely or unavailable, the assurance
-   associated with the binding is clearly reduced.  Relying parties
-   might not be able to process every critical extension that can appear
-   in a CRL.  CAs SHOULD take extra care when making revocation
-   information available only through CRLs that contain critical
-   extensions, particularly if support for those extensions is not
-   mandated by this profile.  For example, if revocation information is
-   supplied using a combination of delta CRLs and full CRLs, and the
-   delta CRLs are issued more frequently than the full CRLs, then
-   relying parties that cannot handle the critical extensions related to
-   delta CRL processing will not be able to obtain the most recent
-   revocation information.  Alternatively, if a full CRL is issued
-   whenever a delta CRL is issued, then timely revocation information
-   will be available to all relying parties.  Similarly, implementations
-   of the certification path validation mechanism described in section 6
-   that omit revocation checking provide less assurance than those that
-   support it.
-
-   The certification path validation algorithm depends on the certain
-   knowledge of the public keys (and other information) about one or
-   more trusted CAs.  The decision to trust a CA is an important
-   decision as it ultimately determines the trust afforded a
-   certificate.  The authenticated distribution of trusted CA public
-   keys (usually in the form of a "self-signed" certificate) is a
-   security critical out-of-band process that is beyond the scope of
-   this specification.
-
-   In addition, where a key compromise or CA failure occurs for a
-   trusted CA, the user will need to modify the information provided to
-   the path validation routine.  Selection of too many trusted CAs makes
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 90]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   the trusted CA information difficult to maintain.  On the other hand,
-   selection of only one trusted CA could limit users to a closed
-   community of users.
-
-   The quality of implementations that process certificates also affects
-   the degree of assurance provided.  The path validation algorithm
-   described in section 6 relies upon the integrity of the trusted CA
-   information, and especially the integrity of the public keys
-   associated with the trusted CAs.  By substituting public keys for
-   which an attacker has the private key, an attacker could trick the
-   user into accepting false certificates.
-
-   The binding between a key and certificate subject cannot be stronger
-   than the cryptographic module implementation and algorithms used to
-   generate the signature.  Short key lengths or weak hash algorithms
-   will limit the utility of a certificate.  CAs are encouraged to note
-   advances in cryptology so they can employ strong cryptographic
-   techniques.  In addition, CAs SHOULD decline to issue certificates to
-   CAs or end entities that generate weak signatures.
-
-   Inconsistent application of name comparison rules can result in
-   acceptance of invalid X.509 certification paths, or rejection of
-   valid ones.  The X.500 series of specifications defines rules for
-   comparing distinguished names that require comparison of strings
-   without regard to case, character set, multi-character white space
-   substring, or leading and trailing white space.  This specification
-   relaxes these requirements, requiring support for binary comparison
-   at a minimum.
-
-   CAs MUST encode the distinguished name in the subject field of a CA
-   certificate identically to the distinguished name in the issuer field
-   in certificates issued by that CA.  If CAs use different encodings,
-   implementations might fail to recognize name chains for paths that
-   include this certificate.  As a consequence, valid paths could be
-   rejected.
-
-   In addition, name constraints for distinguished names MUST be stated
-   identically to the encoding used in the subject field or
-   subjectAltName extension.  If not, then name constraints stated as
-   excludedSubTrees will not match and invalid paths will be accepted
-   and name constraints expressed as permittedSubtrees will not match
-   and valid paths will be rejected.  To avoid acceptance of invalid
-   paths, CAs SHOULD state name constraints for distinguished names as
-   permittedSubtrees wherever possible.
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 91]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-Appendix A.  Psuedo-ASN.1 Structures and OIDs
-
-   This section describes data objects used by conforming PKI components
-   in an "ASN.1-like" syntax.  This syntax is a hybrid of the 1988 and
-   1993 ASN.1 syntaxes.  The 1988 ASN.1 syntax is augmented with 1993
-   UNIVERSAL Types UniversalString, BMPString and UTF8String.
-
-   The ASN.1 syntax does not permit the inclusion of type statements in
-   the ASN.1 module, and the 1993 ASN.1 standard does not permit use of
-   the new UNIVERSAL types in modules using the 1988 syntax.  As a
-   result, this module does not conform to either version of the ASN.1
-   standard.
-
-   This appendix may be converted into 1988 ASN.1 by replacing the
-   definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
-
-A.1 Explicitly Tagged Module, 1988 Syntax
-
-PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1)
-  security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }
-
-DEFINITIONS EXPLICIT TAGS ::=
-
-BEGIN
-
--- EXPORTS ALL --
-
--- IMPORTS NONE --
-
--- UNIVERSAL Types defined in 1993 and 1998 ASN.1
--- and required by this specification
-
-UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
-        -- UniversalString is defined in ASN.1:1993
-
-BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
-      -- BMPString is the subtype of UniversalString and models
-      -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1
-
-UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-      -- The content of this type conforms to RFC 2279.
-
--- PKIX specific OIDs
-
-id-pkix  OBJECT IDENTIFIER  ::=
-         { iso(1) identified-organization(3) dod(6) internet(1)
-                    security(5) mechanisms(5) pkix(7) }
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 92]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
--- PKIX arcs
-
-id-pe OBJECT IDENTIFIER  ::=  { id-pkix 1 }
-        -- arc for private certificate extensions
-id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
-        -- arc for policy qualifier types
-id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
-        -- arc for extended key purpose OIDS
-id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
-        -- arc for access descriptors
-
--- policyQualifierIds for Internet policy qualifiers
-
-id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
-      -- OID for CPS qualifier
-id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }
-      -- OID for user notice qualifier
-
--- access descriptor definitions
-
-id-ad-ocsp         OBJECT IDENTIFIER ::= { id-ad 1 }
-id-ad-caIssuers    OBJECT IDENTIFIER ::= { id-ad 2 }
-id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
-id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
-
--- attribute data types
-
-Attribute       ::=     SEQUENCE {
-      type              AttributeType,
-      values    SET OF AttributeValue }
-            -- at least one value is required
-
-AttributeType           ::=  OBJECT IDENTIFIER
-
-AttributeValue          ::=  ANY
-
-AttributeTypeAndValue           ::=     SEQUENCE {
-        type    AttributeType,
-        value   AttributeValue }
-
--- suggested naming attributes: Definition of the following
---   information object set may be augmented to meet local
---   requirements.  Note that deleting members of the set may
---   prevent interoperability with conforming implementations.
--- presented in pairs: the AttributeType followed by the
---   type definition for the corresponding AttributeValue
---Arc for standard naming attributes
-id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
-
-
-
-Housley, et. al.            Standards Track                    [Page 93]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
--- Naming attributes of type X520name
-
-id-at-name              AttributeType ::= { id-at 41 }
-id-at-surname           AttributeType ::= { id-at 4 }
-id-at-givenName         AttributeType ::= { id-at 42 }
-id-at-initials          AttributeType ::= { id-at 43 }
-id-at-generationQualifier AttributeType ::= { id-at 44 }
-
-X520name ::= CHOICE {
-      teletexString     TeletexString   (SIZE (1..ub-name)),
-      printableString   PrintableString (SIZE (1..ub-name)),
-      universalString   UniversalString (SIZE (1..ub-name)),
-      utf8String        UTF8String      (SIZE (1..ub-name)),
-      bmpString         BMPString       (SIZE (1..ub-name)) }
-
--- Naming attributes of type X520CommonName
-
-id-at-commonName        AttributeType ::= { id-at 3 }
-
-X520CommonName ::= CHOICE {
-      teletexString     TeletexString   (SIZE (1..ub-common-name)),
-      printableString   PrintableString (SIZE (1..ub-common-name)),
-      universalString   UniversalString (SIZE (1..ub-common-name)),
-      utf8String        UTF8String      (SIZE (1..ub-common-name)),
-      bmpString         BMPString       (SIZE (1..ub-common-name)) }
-
--- Naming attributes of type X520LocalityName
-
-id-at-localityName      AttributeType ::= { id-at 7 }
-
-X520LocalityName ::= CHOICE {
-      teletexString     TeletexString   (SIZE (1..ub-locality-name)),
-      printableString   PrintableString (SIZE (1..ub-locality-name)),
-      universalString   UniversalString (SIZE (1..ub-locality-name)),
-      utf8String        UTF8String      (SIZE (1..ub-locality-name)),
-      bmpString         BMPString       (SIZE (1..ub-locality-name)) }
-
--- Naming attributes of type X520StateOrProvinceName
-
-id-at-stateOrProvinceName AttributeType ::= { id-at 8 }
-
-X520StateOrProvinceName ::= CHOICE {
-      teletexString     TeletexString   (SIZE (1..ub-state-name)),
-      printableString   PrintableString (SIZE (1..ub-state-name)),
-      universalString   UniversalString (SIZE (1..ub-state-name)),
-      utf8String        UTF8String      (SIZE (1..ub-state-name)),
-      bmpString         BMPString       (SIZE(1..ub-state-name)) }
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 94]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
--- Naming attributes of type X520OrganizationName
-
-id-at-organizationName  AttributeType ::= { id-at 10 }
-
-X520OrganizationName ::= CHOICE {
-      teletexString     TeletexString
-                          (SIZE (1..ub-organization-name)),
-      printableString   PrintableString
-                          (SIZE (1..ub-organization-name)),
-      universalString   UniversalString
-                          (SIZE (1..ub-organization-name)),
-      utf8String        UTF8String
-                          (SIZE (1..ub-organization-name)),
-      bmpString         BMPString
-                          (SIZE (1..ub-organization-name))  }
-
--- Naming attributes of type X520OrganizationalUnitName
-
-id-at-organizationalUnitName AttributeType ::= { id-at 11 }
-
-X520OrganizationalUnitName ::= CHOICE {
-      teletexString     TeletexString
-                          (SIZE (1..ub-organizational-unit-name)),
-      printableString   PrintableString
-                          (SIZE (1..ub-organizational-unit-name)),
-      universalString   UniversalString
-                          (SIZE (1..ub-organizational-unit-name)),
-      utf8String        UTF8String
-                          (SIZE (1..ub-organizational-unit-name)),
-      bmpString         BMPString
-                          (SIZE (1..ub-organizational-unit-name)) }
-
--- Naming attributes of type X520Title
-
-id-at-title             AttributeType ::= { id-at 12 }
-
-X520Title ::= CHOICE {
-      teletexString     TeletexString   (SIZE (1..ub-title)),
-      printableString   PrintableString (SIZE (1..ub-title)),
-      universalString   UniversalString (SIZE (1..ub-title)),
-      utf8String        UTF8String      (SIZE (1..ub-title)),
-      bmpString         BMPString       (SIZE (1..ub-title)) }
-
--- Naming attributes of type X520dnQualifier
-
-id-at-dnQualifier       AttributeType ::= { id-at 46 }
-
-X520dnQualifier ::=     PrintableString
-
-
-
-Housley, et. al.            Standards Track                    [Page 95]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
--- Naming attributes of type X520countryName (digraph from IS 3166)
-
-id-at-countryName       AttributeType ::= { id-at 6 }
-
-X520countryName ::=     PrintableString (SIZE (2))
-
--- Naming attributes of type X520SerialNumber
-
-id-at-serialNumber      AttributeType ::= { id-at 5 }
-
-X520SerialNumber ::=    PrintableString (SIZE (1..ub-serial-number))
-
--- Naming attributes of type X520Pseudonym
-
-id-at-pseudonym         AttributeType ::= { id-at 65 }
-
-X520Pseudonym ::= CHOICE {
-   teletexString     TeletexString   (SIZE (1..ub-pseudonym)),
-   printableString   PrintableString (SIZE (1..ub-pseudonym)),
-   universalString   UniversalString (SIZE (1..ub-pseudonym)),
-   utf8String        UTF8String      (SIZE (1..ub-pseudonym)),
-   bmpString         BMPString       (SIZE (1..ub-pseudonym)) }
-
--- Naming attributes of type DomainComponent (from RFC 2247)
-
-id-domainComponent      AttributeType ::=
-                          { 0 9 2342 19200300 100 1 25 }
-
-DomainComponent ::=     IA5String
-
--- Legacy attributes
-
-pkcs-9 OBJECT IDENTIFIER ::=
-       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
-
-id-emailAddress          AttributeType ::= { pkcs-9 1 }
-
-EmailAddress ::=         IA5String (SIZE (1..ub-emailaddress-length))
-
--- naming data types --
-
-Name ::= CHOICE { -- only one possibility for now --
-      rdnSequence  RDNSequence }
-
-RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-DistinguishedName ::=   RDNSequence
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 96]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-RelativeDistinguishedName  ::=
-                    SET SIZE (1 .. MAX) OF AttributeTypeAndValue
-
--- Directory string type --
-
-DirectoryString ::= CHOICE {
-      teletexString             TeletexString   (SIZE (1..MAX)),
-      printableString           PrintableString (SIZE (1..MAX)),
-      universalString           UniversalString (SIZE (1..MAX)),
-      utf8String              UTF8String      (SIZE (1..MAX)),
-      bmpString               BMPString       (SIZE (1..MAX)) }
-
--- certificate and CRL specific structures begin here
-
-Certificate  ::=  SEQUENCE  {
-     tbsCertificate       TBSCertificate,
-     signatureAlgorithm   AlgorithmIdentifier,
-     signature            BIT STRING  }
-
-TBSCertificate  ::=  SEQUENCE  {
-     version         [0]  Version DEFAULT v1,
-     serialNumber         CertificateSerialNumber,
-     signature            AlgorithmIdentifier,
-     issuer               Name,
-     validity             Validity,
-     subject              Name,
-     subjectPublicKeyInfo SubjectPublicKeyInfo,
-     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
-                          -- If present, version MUST be v2 or v3
-     subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
-                          -- If present, version MUST be v2 or v3
-     extensions      [3]  Extensions OPTIONAL
-                          -- If present, version MUST be v3 --  }
-
-Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }
-
-CertificateSerialNumber  ::=  INTEGER
-
-Validity ::= SEQUENCE {
-     notBefore      Time,
-     notAfter       Time  }
-
-Time ::= CHOICE {
-     utcTime        UTCTime,
-     generalTime    GeneralizedTime }
-
-UniqueIdentifier  ::=  BIT STRING
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 97]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-SubjectPublicKeyInfo  ::=  SEQUENCE  {
-     algorithm            AlgorithmIdentifier,
-     subjectPublicKey     BIT STRING  }
-
-Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension
-
-Extension  ::=  SEQUENCE  {
-     extnID      OBJECT IDENTIFIER,
-     critical    BOOLEAN DEFAULT FALSE,
-     extnValue   OCTET STRING  }
-
--- CRL structures
-
-CertificateList  ::=  SEQUENCE  {
-     tbsCertList          TBSCertList,
-     signatureAlgorithm   AlgorithmIdentifier,
-     signature            BIT STRING  }
-
-TBSCertList  ::=  SEQUENCE  {
-     version                 Version OPTIONAL,
-                                  -- if present, MUST be v2
-     signature               AlgorithmIdentifier,
-     issuer                  Name,
-     thisUpdate              Time,
-     nextUpdate              Time OPTIONAL,
-     revokedCertificates     SEQUENCE OF SEQUENCE  {
-          userCertificate         CertificateSerialNumber,
-          revocationDate          Time,
-          crlEntryExtensions      Extensions OPTIONAL
-                                         -- if present, MUST be v2
-                               }  OPTIONAL,
-     crlExtensions           [0] Extensions OPTIONAL }
-                                         -- if present, MUST be v2
-
--- Version, Time, CertificateSerialNumber, and Extensions were
--- defined earlier for use in the certificate structure
-
-AlgorithmIdentifier  ::=  SEQUENCE  {
-     algorithm               OBJECT IDENTIFIER,
-     parameters              ANY DEFINED BY algorithm OPTIONAL  }
-                                -- contains a value of the type
-                                -- registered for use with the
-                                -- algorithm object identifier value
-
--- X.400 address syntax starts here
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 98]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-ORAddress ::= SEQUENCE {
-   built-in-standard-attributes BuiltInStandardAttributes,
-   built-in-domain-defined-attributes
-                   BuiltInDomainDefinedAttributes OPTIONAL,
-   -- see also teletex-domain-defined-attributes
-   extension-attributes ExtensionAttributes OPTIONAL }
-
--- Built-in Standard Attributes
-
-BuiltInStandardAttributes ::= SEQUENCE {
-   country-name                  CountryName OPTIONAL,
-   administration-domain-name    AdministrationDomainName OPTIONAL,
-   network-address           [0] IMPLICIT NetworkAddress OPTIONAL,
-     -- see also extended-network-address
-   terminal-identifier       [1] IMPLICIT TerminalIdentifier OPTIONAL,
-   private-domain-name       [2] PrivateDomainName OPTIONAL,
-   organization-name         [3] IMPLICIT OrganizationName OPTIONAL,
-     -- see also teletex-organization-name
-   numeric-user-identifier   [4] IMPLICIT NumericUserIdentifier
-                                 OPTIONAL,
-   personal-name             [5] IMPLICIT PersonalName OPTIONAL,
-     -- see also teletex-personal-name
-   organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
-                                 OPTIONAL }
-     -- see also teletex-organizational-unit-names
-
-CountryName ::= [APPLICATION 1] CHOICE {
-   x121-dcc-code         NumericString
-                           (SIZE (ub-country-name-numeric-length)),
-   iso-3166-alpha2-code  PrintableString
-                           (SIZE (ub-country-name-alpha-length)) }
-
-AdministrationDomainName ::= [APPLICATION 2] CHOICE {
-   numeric   NumericString   (SIZE (0..ub-domain-name-length)),
-   printable PrintableString (SIZE (0..ub-domain-name-length)) }
-
-NetworkAddress ::= X121Address  -- see also extended-network-address
-
-X121Address ::= NumericString (SIZE (1..ub-x121-address-length))
-
-TerminalIdentifier ::= PrintableString (SIZE
-(1..ub-terminal-id-length))
-
-PrivateDomainName ::= CHOICE {
-   numeric   NumericString   (SIZE (1..ub-domain-name-length)),
-   printable PrintableString (SIZE (1..ub-domain-name-length)) }
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 99]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-OrganizationName ::= PrintableString
-                            (SIZE (1..ub-organization-name-length))
-  -- see also teletex-organization-name
-
-NumericUserIdentifier ::= NumericString
-                            (SIZE (1..ub-numeric-user-id-length))
-
-PersonalName ::= SET {
-   surname     [0] IMPLICIT PrintableString
-                    (SIZE (1..ub-surname-length)),
-   given-name  [1] IMPLICIT PrintableString
-                    (SIZE (1..ub-given-name-length)) OPTIONAL,
-   initials    [2] IMPLICIT PrintableString
-                    (SIZE (1..ub-initials-length)) OPTIONAL,
-   generation-qualifier [3] IMPLICIT PrintableString
-                    (SIZE (1..ub-generation-qualifier-length))
-                    OPTIONAL }
-  -- see also teletex-personal-name
-
-OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)
-                             OF OrganizationalUnitName
-  -- see also teletex-organizational-unit-names
-
-OrganizationalUnitName ::= PrintableString (SIZE
-                    (1..ub-organizational-unit-name-length))
-
--- Built-in Domain-defined Attributes
-
-BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
-                    (1..ub-domain-defined-attributes) OF
-                    BuiltInDomainDefinedAttribute
-
-BuiltInDomainDefinedAttribute ::= SEQUENCE {
-   type PrintableString (SIZE
-                   (1..ub-domain-defined-attribute-type-length)),
-   value PrintableString (SIZE
-                   (1..ub-domain-defined-attribute-value-length)) }
-
--- Extension Attributes
-
-ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF
-               ExtensionAttribute
-
-ExtensionAttribute ::=  SEQUENCE {
-   extension-attribute-type [0] IMPLICIT INTEGER
-                   (0..ub-extension-attributes),
-   extension-attribute-value [1]
-                   ANY DEFINED BY extension-attribute-type }
-
-
-
-Housley, et. al.            Standards Track                   [Page 100]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
--- Extension types and attribute values
-
-common-name INTEGER ::= 1
-
-CommonName ::= PrintableString (SIZE (1..ub-common-name-length))
-
-teletex-common-name INTEGER ::= 2
-
-TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))
-
-teletex-organization-name INTEGER ::= 3
-
-TeletexOrganizationName ::=
-                TeletexString (SIZE (1..ub-organization-name-length))
-
-teletex-personal-name INTEGER ::= 4
-
-TeletexPersonalName ::= SET {
-   surname     [0] IMPLICIT TeletexString
-                    (SIZE (1..ub-surname-length)),
-   given-name  [1] IMPLICIT TeletexString
-                    (SIZE (1..ub-given-name-length)) OPTIONAL,
-   initials    [2] IMPLICIT TeletexString
-                    (SIZE (1..ub-initials-length)) OPTIONAL,
-   generation-qualifier [3] IMPLICIT TeletexString
-                    (SIZE (1..ub-generation-qualifier-length))
-                    OPTIONAL }
-
-teletex-organizational-unit-names INTEGER ::= 5
-
-TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
-      (1..ub-organizational-units) OF TeletexOrganizationalUnitName
-
-TeletexOrganizationalUnitName ::= TeletexString
-                  (SIZE (1..ub-organizational-unit-name-length))
-
-pds-name INTEGER ::= 7
-
-PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))
-
-physical-delivery-country-name INTEGER ::= 8
-
-PhysicalDeliveryCountryName ::= CHOICE {
-   x121-dcc-code NumericString (SIZE
-(ub-country-name-numeric-length)),
-   iso-3166-alpha2-code PrintableString
-                  (SIZE (ub-country-name-alpha-length)) }
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 101]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-postal-code INTEGER ::= 9
-
-PostalCode ::= CHOICE {
-   numeric-code NumericString (SIZE (1..ub-postal-code-length)),
-   printable-code PrintableString (SIZE (1..ub-postal-code-length)) }
-
-physical-delivery-office-name INTEGER ::= 10
-
-PhysicalDeliveryOfficeName ::= PDSParameter
-
-physical-delivery-office-number INTEGER ::= 11
-
-PhysicalDeliveryOfficeNumber ::= PDSParameter
-
-extension-OR-address-components INTEGER ::= 12
-
-ExtensionORAddressComponents ::= PDSParameter
-
-physical-delivery-personal-name INTEGER ::= 13
-
-PhysicalDeliveryPersonalName ::= PDSParameter
-
-physical-delivery-organization-name INTEGER ::= 14
-
-PhysicalDeliveryOrganizationName ::= PDSParameter
-
-extension-physical-delivery-address-components INTEGER ::= 15
-
-ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter
-
-unformatted-postal-address INTEGER ::= 16
-
-UnformattedPostalAddress ::= SET {
-   printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines)
-         OF PrintableString (SIZE (1..ub-pds-parameter-length))
-         OPTIONAL,
-   teletex-string TeletexString
-         (SIZE (1..ub-unformatted-address-length)) OPTIONAL }
-
-street-address INTEGER ::= 17
-
-StreetAddress ::= PDSParameter
-
-post-office-box-address INTEGER ::= 18
-
-PostOfficeBoxAddress ::= PDSParameter
-
-poste-restante-address INTEGER ::= 19
-
-
-
-Housley, et. al.            Standards Track                   [Page 102]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-PosteRestanteAddress ::= PDSParameter
-
-unique-postal-name INTEGER ::= 20
-
-UniquePostalName ::= PDSParameter
-
-local-postal-attributes INTEGER ::= 21
-
-LocalPostalAttributes ::= PDSParameter
-
-PDSParameter ::= SET {
-   printable-string PrintableString
-                (SIZE(1..ub-pds-parameter-length)) OPTIONAL,
-   teletex-string TeletexString
-                (SIZE(1..ub-pds-parameter-length)) OPTIONAL }
-
-extended-network-address INTEGER ::= 22
-
-ExtendedNetworkAddress ::= CHOICE {
-   e163-4-address SEQUENCE {
-      number      [0] IMPLICIT NumericString
-                       (SIZE (1..ub-e163-4-number-length)),
-      sub-address [1] IMPLICIT NumericString
-                       (SIZE (1..ub-e163-4-sub-address-length))
-                       OPTIONAL },
-   psap-address [0] IMPLICIT PresentationAddress }
-
-PresentationAddress ::= SEQUENCE {
-    pSelector     [0] EXPLICIT OCTET STRING OPTIONAL,
-    sSelector     [1] EXPLICIT OCTET STRING OPTIONAL,
-    tSelector     [2] EXPLICIT OCTET STRING OPTIONAL,
-    nAddresses    [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING }
-
-terminal-type  INTEGER ::= 23
-
-TerminalType ::= INTEGER {
-   telex (3),
-   teletex (4),
-   g3-facsimile (5),
-   g4-facsimile (6),
-   ia5-terminal (7),
-   videotex (8) } (0..ub-integer-options)
-
--- Extension Domain-defined Attributes
-
-teletex-domain-defined-attributes INTEGER ::= 6
-
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 103]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-TeletexDomainDefinedAttributes ::= SEQUENCE SIZE
-   (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute
-
-TeletexDomainDefinedAttribute ::= SEQUENCE {
-        type TeletexString
-               (SIZE (1..ub-domain-defined-attribute-type-length)),
-        value TeletexString
-               (SIZE (1..ub-domain-defined-attribute-value-length)) }
-
---  specifications of Upper Bounds MUST be regarded as mandatory
---  from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
---  Upper Bounds
-
--- Upper Bounds
-ub-name INTEGER ::= 32768
-ub-common-name INTEGER ::= 64
-ub-locality-name INTEGER ::= 128
-ub-state-name INTEGER ::= 128
-ub-organization-name INTEGER ::= 64
-ub-organizational-unit-name INTEGER ::= 64
-ub-title INTEGER ::= 64
-ub-serial-number INTEGER ::= 64
-ub-match INTEGER ::= 128
-ub-emailaddress-length INTEGER ::= 128
-ub-common-name-length INTEGER ::= 64
-ub-country-name-alpha-length INTEGER ::= 2
-ub-country-name-numeric-length INTEGER ::= 3
-ub-domain-defined-attributes INTEGER ::= 4
-ub-domain-defined-attribute-type-length INTEGER ::= 8
-ub-domain-defined-attribute-value-length INTEGER ::= 128
-ub-domain-name-length INTEGER ::= 16
-ub-extension-attributes INTEGER ::= 256
-ub-e163-4-number-length INTEGER ::= 15
-ub-e163-4-sub-address-length INTEGER ::= 40
-ub-generation-qualifier-length INTEGER ::= 3
-ub-given-name-length INTEGER ::= 16
-ub-initials-length INTEGER ::= 5
-ub-integer-options INTEGER ::= 256
-ub-numeric-user-id-length INTEGER ::= 32
-ub-organization-name-length INTEGER ::= 64
-ub-organizational-unit-name-length INTEGER ::= 32
-ub-organizational-units INTEGER ::= 4
-ub-pds-name-length INTEGER ::= 16
-ub-pds-parameter-length INTEGER ::= 30
-ub-pds-physical-address-lines INTEGER ::= 6
-ub-postal-code-length INTEGER ::= 16
-ub-pseudonym INTEGER ::= 128
-ub-surname-length INTEGER ::= 40
-
-
-
-Housley, et. al.            Standards Track                   [Page 104]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-ub-terminal-id-length INTEGER ::= 24
-ub-unformatted-address-length INTEGER ::= 180
-ub-x121-address-length INTEGER ::= 16
-
--- Note - upper bounds on string types, such as TeletexString, are
--- measured in characters.  Excepting PrintableString or IA5String, a
--- significantly greater number of octets will be required to hold
--- such a value.  As a minimum, 16 octets, or twice the specified
--- upper bound, whichever is the larger, should be allowed for
--- TeletexString.  For UTF8String or UniversalString at least four
--- times the upper bound should be allowed.
-
-END
-
-A.2 Implicitly Tagged Module, 1988 Syntax
-
-PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1)
-  security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) }
-
-DEFINITIONS IMPLICIT TAGS ::=
-
-BEGIN
-
--- EXPORTS ALL --
-
-IMPORTS
-      id-pe, id-kp, id-qt-unotice, id-qt-cps,
-      -- delete following line if "new" types are supported --
-      BMPString, UTF8String,  -- end "new" types --
-      ORAddress, Name, RelativeDistinguishedName,
-      CertificateSerialNumber, Attribute, DirectoryString
-      FROM PKIX1Explicit88 { iso(1) identified-organization(3)
-            dod(6) internet(1) security(5) mechanisms(5) pkix(7)
-            id-mod(0) id-pkix1-explicit(18) };
-
-
--- ISO arc for standard certificate and CRL extensions
-
-id-ce OBJECT IDENTIFIER  ::=  {joint-iso-ccitt(2) ds(5) 29}
-
--- authority key identifier OID and syntax
-
-id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 105]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-AuthorityKeyIdentifier ::= SEQUENCE {
-    keyIdentifier             [0] KeyIdentifier            OPTIONAL,
-    authorityCertIssuer       [1] GeneralNames             OPTIONAL,
-    authorityCertSerialNumber [2] CertificateSerialNumber  OPTIONAL }
-    -- authorityCertIssuer and authorityCertSerialNumber MUST both
-    -- be present or both be absent
-
-KeyIdentifier ::= OCTET STRING
-
--- subject key identifier OID and syntax
-
-id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }
-
-SubjectKeyIdentifier ::= KeyIdentifier
-
--- key usage extension OID and syntax
-
-id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
-
-KeyUsage ::= BIT STRING {
-     digitalSignature        (0),
-     nonRepudiation          (1),
-     keyEncipherment         (2),
-     dataEncipherment        (3),
-     keyAgreement            (4),
-     keyCertSign             (5),
-     cRLSign                 (6),
-     encipherOnly            (7),
-     decipherOnly            (8) }
-
--- private key usage period extension OID and syntax
-
-id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::=  { id-ce 16 }
-
-PrivateKeyUsagePeriod ::= SEQUENCE {
-     notBefore       [0]     GeneralizedTime OPTIONAL,
-     notAfter        [1]     GeneralizedTime OPTIONAL }
-     -- either notBefore or notAfter MUST be present
-
--- certificate policies extension OID and syntax
-
-id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }
-
-anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
-
-CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
-
-PolicyInformation ::= SEQUENCE {
-
-
-
-Housley, et. al.            Standards Track                   [Page 106]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-     policyIdentifier   CertPolicyId,
-     policyQualifiers   SEQUENCE SIZE (1..MAX) OF
-             PolicyQualifierInfo OPTIONAL }
-
-CertPolicyId ::= OBJECT IDENTIFIER
-
-PolicyQualifierInfo ::= SEQUENCE {
-       policyQualifierId  PolicyQualifierId,
-       qualifier        ANY DEFINED BY policyQualifierId }
-
--- Implementations that recognize additional policy qualifiers MUST
--- augment the following definition for PolicyQualifierId
-
-PolicyQualifierId ::=
-    OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
-
--- CPS pointer qualifier
-
-CPSuri ::= IA5String
-
--- user notice qualifier
-
-UserNotice ::= SEQUENCE {
-     noticeRef        NoticeReference OPTIONAL,
-     explicitText     DisplayText OPTIONAL}
-
-NoticeReference ::= SEQUENCE {
-     organization     DisplayText,
-     noticeNumbers    SEQUENCE OF INTEGER }
-
-DisplayText ::= CHOICE {
-     ia5String        IA5String      (SIZE (1..200)),
-     visibleString    VisibleString  (SIZE (1..200)),
-     bmpString        BMPString      (SIZE (1..200)),
-     utf8String       UTF8String     (SIZE (1..200)) }
-
--- policy mapping extension OID and syntax
-
-id-ce-policyMappings OBJECT IDENTIFIER ::=  { id-ce 33 }
-
-PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-     issuerDomainPolicy      CertPolicyId,
-     subjectDomainPolicy     CertPolicyId }
-
--- subject alternative name extension OID and syntax
-
-id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 107]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-SubjectAltName ::= GeneralNames
-
-GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
-
-GeneralName ::= CHOICE {
-     otherName                       [0]     AnotherName,
-     rfc822Name                      [1]     IA5String,
-     dNSName                         [2]     IA5String,
-     x400Address                     [3]     ORAddress,
-     directoryName                   [4]     Name,
-     ediPartyName                    [5]     EDIPartyName,
-     uniformResourceIdentifier       [6]     IA5String,
-     iPAddress                       [7]     OCTET STRING,
-     registeredID                    [8]     OBJECT IDENTIFIER }
-
--- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
--- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax
-
-AnotherName ::= SEQUENCE {
-     type-id    OBJECT IDENTIFIER,
-     value      [0] EXPLICIT ANY DEFINED BY type-id }
-
-EDIPartyName ::= SEQUENCE {
-     nameAssigner            [0]     DirectoryString OPTIONAL,
-     partyName               [1]     DirectoryString }
-
--- issuer alternative name extension OID and syntax
-
-id-ce-issuerAltName OBJECT IDENTIFIER ::=  { id-ce 18 }
-
-IssuerAltName ::= GeneralNames
-
-id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::=  { id-ce 9 }
-
-SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
-
--- basic constraints extension OID and syntax
-
-id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }
-
-BasicConstraints ::= SEQUENCE {
-     cA                      BOOLEAN DEFAULT FALSE,
-     pathLenConstraint       INTEGER (0..MAX) OPTIONAL }
-
--- name constraints extension OID and syntax
-
-id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 108]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-NameConstraints ::= SEQUENCE {
-     permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
-     excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }
-
-GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
-
-GeneralSubtree ::= SEQUENCE {
-     base                    GeneralName,
-     minimum         [0]     BaseDistance DEFAULT 0,
-     maximum         [1]     BaseDistance OPTIONAL }
-
-BaseDistance ::= INTEGER (0..MAX)
-
--- policy constraints extension OID and syntax
-
-id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 36 }
-
-PolicyConstraints ::= SEQUENCE {
-     requireExplicitPolicy           [0] SkipCerts OPTIONAL,
-     inhibitPolicyMapping            [1] SkipCerts OPTIONAL }
-
-SkipCerts ::= INTEGER (0..MAX)
-
--- CRL distribution points extension OID and syntax
-
-id-ce-cRLDistributionPoints     OBJECT IDENTIFIER  ::=  {id-ce 31}
-
-CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
-
-DistributionPoint ::= SEQUENCE {
-     distributionPoint       [0]     DistributionPointName OPTIONAL,
-     reasons                 [1]     ReasonFlags OPTIONAL,
-     cRLIssuer               [2]     GeneralNames OPTIONAL }
-
-DistributionPointName ::= CHOICE {
-     fullName                [0]     GeneralNames,
-     nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
-
-ReasonFlags ::= BIT STRING {
-     unused                  (0),
-     keyCompromise           (1),
-     cACompromise            (2),
-     affiliationChanged      (3),
-     superseded              (4),
-     cessationOfOperation    (5),
-     certificateHold         (6),
-     privilegeWithdrawn      (7),
-     aACompromise            (8) }
-
-
-
-Housley, et. al.            Standards Track                   [Page 109]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
--- extended key usage extension OID and syntax
-
-id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}
-
-ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
-
-
-KeyPurposeId ::= OBJECT IDENTIFIER
-
--- permit unspecified key uses
-
-anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
-
--- extended key purpose OIDs
-
-id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
-id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
-id-kp-codeSigning            OBJECT IDENTIFIER ::= { id-kp 3 }
-id-kp-emailProtection        OBJECT IDENTIFIER ::= { id-kp 4 }
-id-kp-timeStamping           OBJECT IDENTIFIER ::= { id-kp 8 }
-id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
-
--- inhibit any policy OID and syntax
-
-id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::=  { id-ce 54 }
-
-InhibitAnyPolicy ::= SkipCerts
-
--- freshest (delta)CRL extension OID and syntax
-
-id-ce-freshestCRL OBJECT IDENTIFIER ::=  { id-ce 46 }
-
-FreshestCRL ::= CRLDistributionPoints
-
--- authority info access
-
-id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
-
-AuthorityInfoAccessSyntax  ::=
-        SEQUENCE SIZE (1..MAX) OF AccessDescription
-
-AccessDescription  ::=  SEQUENCE {
-        accessMethod          OBJECT IDENTIFIER,
-        accessLocation        GeneralName  }
-
--- subject info access
-
-id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
-
-
-
-Housley, et. al.            Standards Track                   [Page 110]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-SubjectInfoAccessSyntax  ::=
-        SEQUENCE SIZE (1..MAX) OF AccessDescription
-
--- CRL number extension OID and syntax
-
-id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
-
-CRLNumber ::= INTEGER (0..MAX)
-
--- issuing distribution point extension OID and syntax
-
-id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
-
-IssuingDistributionPoint ::= SEQUENCE {
-     distributionPoint          [0] DistributionPointName OPTIONAL,
-     onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
-     onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
-     onlySomeReasons            [3] ReasonFlags OPTIONAL,
-     indirectCRL                [4] BOOLEAN DEFAULT FALSE,
-     onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
-
-id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
-
-BaseCRLNumber ::= CRLNumber
-
--- CRL reasons extension OID and syntax
-
-id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
-
-CRLReason ::= ENUMERATED {
-     unspecified             (0),
-     keyCompromise           (1),
-     cACompromise            (2),
-     affiliationChanged      (3),
-     superseded              (4),
-     cessationOfOperation    (5),
-     certificateHold         (6),
-     removeFromCRL           (8),
-     privilegeWithdrawn      (9),
-     aACompromise           (10) }
-
--- certificate issuer CRL entry extension OID and syntax
-
-id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
-
-CertificateIssuer ::= GeneralNames
-
--- hold instruction extension OID and syntax
-
-
-
-Housley, et. al.            Standards Track                   [Page 111]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
-
-HoldInstructionCode ::= OBJECT IDENTIFIER
-
--- ANSI x9 holdinstructions
-
--- ANSI x9 arc holdinstruction arc
-
-holdInstruction OBJECT IDENTIFIER ::=
-          {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2}
-
--- ANSI X9 holdinstructions referenced by this standard
-
-id-holdinstruction-none OBJECT IDENTIFIER  ::=
-                {holdInstruction 1} -- deprecated
-
-id-holdinstruction-callissuer OBJECT IDENTIFIER ::=
-                {holdInstruction 2}
-
-id-holdinstruction-reject OBJECT IDENTIFIER ::=
-                {holdInstruction 3}
-
--- invalidity date CRL entry extension OID and syntax
-
-id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
-
-InvalidityDate ::=  GeneralizedTime
-
-END
-
-Appendix B.  ASN.1 Notes
-
-   CAs MUST force the serialNumber to be a non-negative integer, that
-   is, the sign bit in the DER encoding of the INTEGER value MUST be
-   zero - this can be done by adding a leading (leftmost) `00'H octet if
-   necessary.  This removes a potential ambiguity in mapping between a
-   string of octets and an integer value.
-
-   As noted in section 4.1.2.2, serial numbers can be expected to
-   contain long integers.  Certificate users MUST be able to handle
-   serialNumber values up to 20 octets in length.  Conformant CAs MUST
-   NOT use serialNumber values longer than 20 octets.
-
-   As noted in section 5.2.3, CRL numbers can be expected to contain
-   long integers.  CRL validators MUST be able to handle cRLNumber
-   values up to 20 octets in length.  Conformant CRL issuers MUST NOT
-   use cRLNumber values longer than 20 octets.
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 112]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
-   constructs.  A valid ASN.1 sequence will have zero or more entries.
-   The SIZE (1..MAX) construct constrains the sequence to have at least
-   one entry.  MAX indicates the upper bound is unspecified.
-   Implementations are free to choose an upper bound that suits their
-   environment.
-
-   The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt
-   as a subtype of INTEGER containing integers greater than or equal to
-   zero.  The upper bound is unspecified.  Implementations are free to
-   select an upper bound that suits their environment.
-
-   The character string type PrintableString supports a very basic Latin
-   character set: the lower case letters 'a' through 'z', upper case
-   letters 'A' through 'Z', the digits '0' through '9', eleven special
-   characters ' = ( ) + , - . / : ? and space.
-
-   Implementers should note that the at sign ('@') and underscore ('_')
-   characters are not supported by the ASN.1 type PrintableString.
-   These characters often appear in internet addresses.  Such addresses
-   MUST be encoded using an ASN.1 type that supports them.  They are
-   usually encoded as IA5String in either the emailAddress attribute
-   within a distinguished name or the rfc822Name field of GeneralName.
-   Conforming implementations MUST NOT encode strings which include
-   either the at sign or underscore character as PrintableString.
-
-   The character string type TeletexString is a superset of
-   PrintableString.  TeletexString supports a fairly standard (ASCII-
-   like) Latin character set, Latin characters with non-spacing accents
-   and Japanese characters.
-
-   Named bit lists are BIT STRINGs where the values have been assigned
-   names.  This specification makes use of named bit lists in the
-   definitions for the key usage, CRL distribution points and freshest
-   CRL certificate extensions, as well as the freshest CRL and issuing
-   distribution point CRL extensions.  When DER encoding a named bit
-   list, trailing zeroes MUST be omitted.  That is, the encoded value
-   ends with the last named bit that is set to one.
-
-   The character string type UniversalString supports any of the
-   characters allowed by ISO 10646-1 [ISO 10646].  ISO 10646-1 is the
-   Universal multiple-octet coded Character Set (UCS).  ISO 10646-1
-   specifies the architecture and the "basic multilingual plane" -- a
-   large standard character set which includes all major world character
-   standards.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 113]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   The character string type UTF8String was introduced in the 1997
-   version of ASN.1, and UTF8String was added to the list of choices for
-   DirectoryString in the 2001 version of X.520 [X.520].  UTF8String is
-   a universal type and has been assigned tag number 12.  The content of
-   UTF8String was defined by RFC 2044 [RFC 2044] and updated in RFC 2279
-   [RFC 2279].
-
-   In anticipation of these changes, and in conformance with IETF Best
-   Practices codified in RFC 2277 [RFC 2277], IETF Policy on Character
-   Sets and Languages, this document includes UTF8String as a choice in
-   DirectoryString and the CPS qualifier extensions.
-
-   Implementers should note that the DER encoding of the SET OF values
-   requires ordering of the encodings of the values.  In particular,
-   this issue arises with respect to distinguished names.
-
-   Implementers should note that the DER encoding of SET or SEQUENCE
-   components whose value is the DEFAULT omit the component from the
-   encoded certificate or CRL.  For example, a BasicConstraints
-   extension whose cA value is FALSE would omit the cA boolean from the
-   encoded certificate.
-
-   Object Identifiers (OIDs) are used throughout this specification to
-   identify certificate policies, public key and signature algorithms,
-   certificate extensions, etc.  There is no maximum size for OIDs.
-   This specification mandates support for OIDs which have arc elements
-   with values that are less than 2^28, that is, they MUST be between 0
-   and 268,435,455, inclusive.  This allows each arc element to be
-   represented within a single 32 bit word.  Implementations MUST also
-   support OIDs where the length of the dotted decimal (see [RFC 2252],
-   section 4.1) string representation can be up to 100 bytes
-   (inclusive).  Implementations MUST be able to handle OIDs with up to
-   20 elements (inclusive).  CAs SHOULD NOT issue certificates which
-   contain OIDs that exceed these requirements.  Likewise, CRL issuers
-   SHOULD NOT issue CRLs which contain OIDs that exceed these
-   requirements.
-
-   Implementors are warned that the X.500 standards community has
-   developed a series of extensibility rules.  These rules determine
-   when an ASN.1 definition can be changed without assigning a new
-   object identifier (OID).  For example, at least two extension
-   definitions included in RFC 2459 [RFC 2459], the predecessor to this
-   profile document, have different ASN.1 definitions in this
-   specification, but the same OID is used.  If unknown elements appear
-   within an extension, and the extension is not marked critical, those
-   unknown elements ought to be ignored, as follows:
-
-      (a)  ignore all unknown bit name assignments within a bit string;
-
-
-
-Housley, et. al.            Standards Track                   [Page 114]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (b)  ignore all unknown named numbers in an ENUMERATED type or
-      INTEGER type that is being used in the enumerated style, provided
-      the number occurs as an optional element of a SET or SEQUENCE; and
-
-      (c)  ignore all unknown elements in SETs, at the end of SEQUENCEs,
-      or in CHOICEs where the CHOICE is itself an optional element of a
-      SET or SEQUENCE.
-
-   If an extension containing unexpected values is marked critical, the
-   implementation MUST reject the certificate or CRL containing the
-   unrecognized extension.
-
-Appendix C.  Examples
-
-   This section contains four examples: three certificates and a CRL.
-   The first two certificates and the CRL comprise a minimal
-   certification path.
-
-   Section C.1 contains an annotated hex dump of a "self-signed"
-   certificate issued by a CA whose distinguished name is
-   cn=us,o=gov,ou=nist.  The certificate contains a DSA public key with
-   parameters, and is signed by the corresponding DSA private key.
-
-   Section C.2 contains an annotated hex dump of an end entity
-   certificate.  The end entity certificate contains a DSA public key,
-   and is signed by the private key corresponding to the "self-signed"
-   certificate in section C.1.
-
-   Section C.3 contains a dump of an end entity certificate which
-   contains an RSA public key and is signed with RSA and MD5.  This
-   certificate is not part of the minimal certification path.
-
-   Section C.4 contains an annotated hex dump of a CRL.  The CRL is
-   issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and
-   the list of revoked certificates includes the end entity certificate
-   presented in C.2.
-
-   The certificates were processed using Peter Gutman's dumpasn1 utility
-   to generate the output.  The source for the dumpasn1 utility is
-   available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>.  The
-   binaries for the certificates and CRLs are available at
-   <http://csrc.nist.gov/pki/pkixtools>.
-
-C.1  Certificate
-
-   This section contains an annotated hex dump of a 699 byte version 3
-   certificate.  The certificate contains the following information:
-   (a)  the serial number is 23 (17 hex);
-
-
-
-Housley, et. al.            Standards Track                   [Page 115]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   (b)  the certificate is signed with DSA and the SHA-1 hash algorithm;
-   (c)  the issuer's distinguished name is OU=NIST; O=gov; C=US
-   (d)  and the subject's distinguished name is OU=NIST; O=gov; C=US
-   (e)  the certificate was issued on June 30, 1997 and will expire on
-   December 31, 1997;
-   (f)  the certificate contains a 1024 bit DSA public key with
-   parameters;
-   (g)  the certificate contains a subject key identifier extension
-   generated using method (1) of section 4.2.1.2; and
-   (h)  the certificate is a CA certificate (as indicated through the
-   basic constraints extension.)
-
-  0 30  699: SEQUENCE {
-  4 30  635:   SEQUENCE {
-  8 A0    3:     [0] {
- 10 02    1:       INTEGER 2
-          :       }
- 13 02    1:     INTEGER 17
- 16 30    9:     SEQUENCE {
- 18 06    7:       OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
-          :       }
- 27 30   42:     SEQUENCE {
- 29 31   11:       SET {
- 31 30    9:         SEQUENCE {
- 33 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
- 38 13    2:           PrintableString 'US'
-          :           }
-          :         }
- 42 31   12:       SET {
- 44 30   10:         SEQUENCE {
- 46 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
- 51 13    3:           PrintableString 'gov'
-          :           }
-          :         }
- 56 31   13:       SET {
- 58 30   11:         SEQUENCE {
- 60 06    3:           OBJECT IDENTIFIER
-          :             organizationalUnitName (2 5 4 11)
- 65 13    4:           PrintableString 'NIST'
-           :           }
-           :         }
-           :       }
- 71 30   30:     SEQUENCE {
- 73 17   13:       UTCTime '970630000000Z'
- 88 17   13:       UTCTime '971231000000Z'
-           :       }
-103 30   42:     SEQUENCE {
-105 31   11:       SET {
-
-
-
-Housley, et. al.            Standards Track                   [Page 116]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-107 30    9:         SEQUENCE {
-109 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
-114 13    2:           PrintableString 'US'
-           :           }
-           :         }
-118 31   12:       SET {
-120 30   10:         SEQUENCE {
-122 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
-127 13    3:           PrintableString 'gov'
-           :           }
-           :         }
-132 31   13:       SET {
-134 30   11:         SEQUENCE {
-136 06    3:           OBJECT IDENTIFIER
-           :             organizationalUnitName (2 5 4 11)
-141 13    4:           PrintableString 'NIST'
-           :           }
-           :         }
-           :       }
-147 30  440:     SEQUENCE {
-151 30  300:       SEQUENCE {
-155 06    7:         OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
-164 30  287:         SEQUENCE {
-168 02  129:           INTEGER
-           :             00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC
-           :             FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC
-           :             48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F
-           :             22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64
-           :             3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A
-           :             C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD
-           :             35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E
-           :             5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
-           :             FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48
-           :             63 FE 43
-300 02   21:           INTEGER
-           :             00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA
-           :             55 F7 7D 57 74 81 E5
-323 02  129:           INTEGER
-           :             00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91
-           :             C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92
-           :             81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77
-           :             A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC
-           :             46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A
-           :             5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C
-           :             92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2
-           :             62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
-           :             F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE
-           :             1E 57 18
-
-
-
-Housley, et. al.            Standards Track                   [Page 117]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-           :           }
-           :         }
-455 03  133:       BIT STRING 0 unused bits, encapsulates {
-459 02  129:           INTEGER
-           :             00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 04
-           :             75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3
-           :             03 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1
-           :             2A D3 78 77 63 56 EA 96 61 4D 42 0B 7A 1D
-           :             FB AB 91 A4 CE DE EF 77 C8 E5 EF 20 AE A6
-           :             28 48 AF BE 69 C3 6A A5 30 F2 C2 B9 D9 82
-           :             2B 7D D9 C4 84 1F DE 0D E8 54 D7 1B 99 2E
-           :             B3 D0 88 F6 D6 63 9B A7 E2 0E 82 D4 3B 8A
-           :             68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 41
-           :             7B C9 55
-           :           }
-           :       }
-591 A3   50:     [3] {
-593 30   48:       SEQUENCE {
-595 30   29:         SEQUENCE {
-597 06    3:           OBJECT IDENTIFIER
-           :             subjectKeyIdentifier (2 5 29 14)
-602 04   22:           OCTET STRING, encapsulates {
-604 04   20:               OCTET STRING
-           :                 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41
-           :                 2C 29 49 F4 86 56
-           :               }
-           :           }
-626 30   15:         SEQUENCE {
-628 06    3:           OBJECT IDENTIFIER basicConstraints (2 5 29 19)
-633 01    1:           BOOLEAN TRUE
-636 04    5:           OCTET STRING, encapsulates {
-638 30    3:               SEQUENCE {
-640 01    1:                 BOOLEAN TRUE
-           :                 }
-           :               }
-           :           }
-           :         }
-           :       }
-           :     }
-643 30    9:   SEQUENCE {
-645 06    7:     OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
-           :     }
-654 03   47:   BIT STRING 0 unused bits, encapsulates {
-657 30   44:       SEQUENCE {
-659 02   20:         INTEGER
-           :           43 1B CF 29 25 45 C0 4E 52 E7 7D D6 FC B1
-           :           66 4C 83 CF 2D 77
-681 02   20:         INTEGER
-
-
-
-Housley, et. al.            Standards Track                   [Page 118]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-           :           0B 5B 9A 24 11 98 E8 F3 86 90 04 F6 08 A9
-           :           E1 8D A5 CC 3A D4
-           :         }
-           :       }
-           :   }
-
-C.2  Certificate
-
-   This section contains an annotated hex dump of a 730 byte version 3
-   certificate.  The certificate contains the following information:
-   (a)  the serial number is 18 (12 hex);
-   (b)  the certificate is signed with DSA and the SHA-1 hash algorithm;
-   (c)  the issuer's distinguished name is OU=nist; O=gov; C=US
-   (d)  and the subject's distinguished name is CN=Tim Polk; OU=nist;
-   O=gov; C=US
-   (e)  the certificate was valid from July 30, 1997 through December 1,
-   1997;
-   (f)  the certificate contains a 1024 bit DSA public key;
-   (g)  the certificate is an end entity certificate, as the basic
-   constraints extension is not present;
-   (h)  the certificate contains an authority key identifier extension
-   matching the subject key identifier of the certificate in Appendix
-   C.1; and
-   (i)  the certificate includes one alternative name - an RFC 822
-   address of "wpolk@nist.gov".
-
-     0 30  730: SEQUENCE {
-     4 30  665:   SEQUENCE {
-     8 A0    3:     [0] {
-    10 02    1:       INTEGER 2
-              :       }
-    13 02    1:     INTEGER 18
-    16 30    9:     SEQUENCE {
-    18 06    7:       OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
-              :       }
-    27 30   42:     SEQUENCE {
-    29 31   11:       SET {
-    31 30    9:         SEQUENCE {
-    33 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
-    38 13    2:           PrintableString 'US'
-              :           }
-              :         }
-    42 31   12:       SET {
-    44 30   10:         SEQUENCE {
-    46 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
-    51 13    3:           PrintableString 'gov'
-              :           }
-              :         }
-
-
-
-Housley, et. al.            Standards Track                   [Page 119]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-    56 31   13:       SET {
-    58 30   11:         SEQUENCE {
-    60 06    3:           OBJECT IDENTIFIER
-              :             organizationalUnitName (2 5 4 11)
-    65 13    4:           PrintableString 'NIST'
-              :           }
-              :         }
-              :       }
-    71 30   30:     SEQUENCE {
-    73 17   13:       UTCTime '970730000000Z'
-    88 17   13:       UTCTime '971201000000Z'
-              :       }
-   103 30   61:     SEQUENCE {
-   105 31   11:       SET {
-   107 30    9:         SEQUENCE {
-   109 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
-   114 13    2:           PrintableString 'US'
-              :           }
-              :         }
-   118 31   12:       SET {
-   120 30   10:         SEQUENCE {
-   122 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
-   127 13    3:           PrintableString 'gov'
-              :           }
-              :         }
-   132 31   13:       SET {
-   134 30   11:         SEQUENCE {
-   136 06    3:           OBJECT IDENTIFIER
-              :             organizationalUnitName (2 5 4 11)
-   141 13    4:           PrintableString 'NIST'
-              :           }
-              :         }
-   147 31   17:       SET {
-   149 30   15:         SEQUENCE {
-   151 06    3:           OBJECT IDENTIFIER commonName (2 5 4 3)
-   156 13    8:           PrintableString 'Tim Polk'
-              :           }
-              :         }
-              :       }
-   166 30  439:     SEQUENCE {
-   170 30  300:       SEQUENCE {
-   174 06    7:         OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
-   183 30  287:         SEQUENCE {
-   187 02  129:           INTEGER
-              :             00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC
-              :             FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC
-              :             48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F
-              :             22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64
-
-
-
-Housley, et. al.            Standards Track                   [Page 120]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-              :             3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A
-              :             C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD
-              :             35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E
-              :             5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
-              :             FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48
-              :             63 FE 43
-   319 02   21:           INTEGER
-              :             00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA
-              :             55 F7 7D 57 74 81 E5
-   342 02  129:           INTEGER
-              :             00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91
-              :             C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92
-              :             81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77
-              :             A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC
-              :             46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A
-              :             5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C
-              :             92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2
-              :             62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
-              :             F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE
-              :             1E 57 18
-              :           }
-              :         }
-   474 03  132:       BIT STRING 0 unused bits, encapsulates {
-   478 02  128:           INTEGER
-              :             30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB
-              :             A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C
-              :             B7 C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33
-              :             37 F4 01 0B F5 04 1F 9D 2E 1F 62 D8 84 3A
-              :             9B 25 09 5A 2D C8 46 8E 2B D4 F5 0D 3B C7
-              :             2D C6 6C B9 98 C1 25 3A 44 4E 8E CA 95 61
-              :             35 7C CE 15 31 5C 23 13 1E A2 05 D1 7A 24
-              :             1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC
-              :             46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5
-              :             95 BE
-              :           }
-              :       }
-   609 A3   62:     [3] {
-   611 30   60:       SEQUENCE {
-   613 30   25:         SEQUENCE {
-   615 06    3:           OBJECT IDENTIFIER subjectAltName (2 5 29 17)
-   620 04   18:           OCTET STRING, encapsulates {
-   622 30   16:               SEQUENCE {
-   624 81   14:                 [1] 'wpolk@nist.gov'
-              :                 }
-              :               }
-              :           }
-   640 30   31:         SEQUENCE {
-   642 06    3:           OBJECT IDENTIFIER
-
-
-
-Housley, et. al.            Standards Track                   [Page 121]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-              :             authorityKeyIdentifier (2 5 29 35)
-   647 04   24:           OCTET STRING, encapsulates {
-   649 30   22:               SEQUENCE {
-   651 80   20:                 [0]
-              :                   86 CA A5 22 81 62 EF AD 0A 89 BC AD 72
-              :                   41 2C 29 49 F4 86 56
-              :                 }
-              :               }
-              :           }
-              :         }
-              :       }
-              :     }
-   673 30    9:   SEQUENCE {
-   675 06    7:     OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
-              :     }
-   684 03   48:   BIT STRING 0 unused bits, encapsulates {
-   687 30   45:       SEQUENCE {
-   689 02   20:         INTEGER
-              :           36 97 CB E3 B4 2C E1 BB 61 A9 D3 CC 24 CC
-              :           22 92 9F F4 F5 87
-   711 02   21:         INTEGER
-              :           00 AB C9 79 AF D2 16 1C A9 E3 68 A9 14 10
-              :           B4 A0 2E FF 22 5A 73
-              :         }
-              :       }
-              :   }
-
-C.3  End Entity Certificate Using RSA
-
-   This section contains an annotated hex dump of a 654 byte version 3
-   certificate.  The certificate contains the following information:
-   (a)  the serial number is 256;
-   (b)  the certificate is signed with RSA and the SHA-1 hash algorithm;
-   (c)  the issuer's distinguished name is OU=NIST; O=gov; C=US
-   (d)  and the subject's distinguished name is CN=Tim Polk; OU=NIST;
-   O=gov; C=US
-   (e)  the certificate was issued on May 21, 1996 at 09:58:26 and
-   expired on May 21, 1997 at 09:58:26;
-   (f)  the certificate contains a 1024 bit RSA public key;
-   (g)  the certificate is an end entity certificate (not a CA
-   certificate);
-   (h)  the certificate includes an alternative subject name of
-   "<http://www.itl.nist.gov/div893/staff/polk/index.html>" and an
-   alternative issuer name of "<http://www.nist.gov/>" - both are URLs;
-   (i)  the certificate include an authority key identifier extension
-   and a certificate policies extension specifying the policy OID
-   2.16.840.1.101.3.2.1.48.9; and
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 122]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   (j)  the certificate includes a critical key usage extension
-   specifying that the public key is intended for verification of
-   digital signatures.
-
-  0 30  654: SEQUENCE {
-  4 30  503:   SEQUENCE {
-  8 A0    3:     [0] {
- 10 02    1:       INTEGER 2
-           :       }
- 13 02    2:     INTEGER 256
- 17 30   13:     SEQUENCE {
- 19 06    9:       OBJECT IDENTIFIER
-           :         sha1withRSAEncryption (1 2 840 113549 1 1 5)
- 30 05    0:       NULL
-           :       }
- 32 30   42:     SEQUENCE {
- 34 31   11:       SET {
- 36 30    9:         SEQUENCE {
- 38 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
- 43 13    2:           PrintableString 'US'
-           :           }
-           :         }
- 47 31   12:       SET {
- 49 30   10:         SEQUENCE {
- 51 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
- 56 13    3:           PrintableString 'gov'
-           :           }
-           :         }
- 61 31   13:       SET {
- 63 30   11:         SEQUENCE {
- 65 06    3:           OBJECT IDENTIFIER
-           :             organizationalUnitName (2 5 4 11)
- 70 13    4:           PrintableString 'NIST'
-           :           }
-           :         }
-           :       }
- 76 30   30:     SEQUENCE {
- 78 17   13:       UTCTime '960521095826Z'
- 93 17   13:       UTCTime '970521095826Z'
-           :       }
-108 30   61:     SEQUENCE {
-110 31   11:       SET {
-112 30    9:         SEQUENCE {
-114 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
-119 13    2:           PrintableString 'US'
-           :           }
-           :         }
-123 31   12:       SET {
-
-
-
-Housley, et. al.            Standards Track                   [Page 123]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-125 30   10:         SEQUENCE {
-127 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
-132 13    3:           PrintableString 'gov'
-           :           }
-           :         }
-137 31   13:       SET {
-139 30   11:         SEQUENCE {
-141 06    3:           OBJECT IDENTIFIER
-           :             organizationalUnitName (2 5 4 11)
-146 13    4:           PrintableString 'NIST'
-           :           }
-           :         }
-152 31   17:       SET {
-154 30   15:         SEQUENCE {
-156 06    3:           OBJECT IDENTIFIER commonName (2 5 4 3)
-161 13    8:           PrintableString 'Tim Polk'
-           :           }
-           :         }
-           :       }
-171 30  159:     SEQUENCE {
-174 30   13:       SEQUENCE {
-176 06    9:         OBJECT IDENTIFIER
-           :           rsaEncryption (1 2 840 113549 1 1 1)
-187 05    0:         NULL
-           :         }
-189 03  141:       BIT STRING 0 unused bits, encapsulates {
-193 30  137:           SEQUENCE {
-196 02  129:             INTEGER
-           :               00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E
-           :               4D 7F 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75
-           :               EC ED B6 56 96 7F 88 99 85 9A F2 3E 68 77
-           :               87 EB 9E D1 9F C0 B4 17 DC AB 89 23 A4 1D
-           :               7E 16 23 4C 4F A8 4D F5 31 B8 7C AA E3 1A
-           :               49 09 F4 4B 26 DB 27 67 30 82 12 01 4A E9
-           :               1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC 33 36
-           :               7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2
-           :               2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16
-           :               95 FF 23
-328 02    3:             INTEGER 65537
-           :             }
-           :           }
-           :       }
-333 A3  175:     [3] {
-336 30  172:       SEQUENCE {
-339 30   63:         SEQUENCE {
-341 06    3:           OBJECT IDENTIFIER subjectAltName (2 5 29 17)
-346 04   56:           OCTET STRING, encapsulates {
-348 30   54:               SEQUENCE {
-
-
-
-Housley, et. al.            Standards Track                   [Page 124]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-350 86   52:                 [6]
-           :                   'http://www.itl.nist.gov/div893/staff/'
-           :                   'polk/index.html'
-           :                 }
-           :               }
-           :           }
-404 30   31:         SEQUENCE {
-406 06    3:           OBJECT IDENTIFIER issuerAltName (2 5 29 18)
-411 04   24:           OCTET STRING, encapsulates {
-413 30   22:               SEQUENCE {
-415 86   20:                 [6] 'http://www.nist.gov/'
-           :                 }
-           :               }
-           :           }
-437 30   31:         SEQUENCE {
-439 06    3:           OBJECT IDENTIFIER
-           :             authorityKeyIdentifier (2 5 29 35)
-444 04   24:           OCTET STRING, encapsulates {
-446 30   22:               SEQUENCE {
-448 80   20:                 [0]
-           :                   08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E
-           :                   70 6A 4A 20 84 2C 32
-           :                 }
-           :               }
-           :           }
-470 30   23:         SEQUENCE {
-472 06    3:           OBJECT IDENTIFIER
-           :             certificatePolicies (2 5 29 32)
-477 04   16:           OCTET STRING, encapsulates {
-479 30   14:               SEQUENCE {
-481 30   12:                 SEQUENCE {
-483 06   10:                   OBJECT IDENTIFIER
-           :                            '2 16 840 1 101 3 2 1 48 9'
-           :                   }
-           :                 }
-           :               }
-           :           }
-495 30   14:         SEQUENCE {
-497 06    3:           OBJECT IDENTIFIER keyUsage (2 5 29 15)
-502 01    1:           BOOLEAN TRUE
-505 04    4:           OCTET STRING, encapsulates {
-507 03    2:               BIT STRING 7 unused bits
-           :                 '1'B (bit 0)
-           :               }
-           :           }
-           :         }
-           :       }
-           :     }
-
-
-
-Housley, et. al.            Standards Track                   [Page 125]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-511 30   13:   SEQUENCE {
-513 06    9:     OBJECT IDENTIFIER
-           :       sha1withRSAEncryption (1 2 840 113549 1 1 5)
-524 05    0:     NULL
-           :     }
-526 03  129:   BIT STRING 0 unused bits
-           :     1E 07 77 6E 66 B5 B6 B8 57 F0 03 DC 6F 77
-           :     6D AF 55 1D 74 E5 CE 36 81 FC 4B C5 F4 47
-           :     82 C4 0A 25 AA 8D D6 7D 3A 89 AB 44 34 39
-           :     F6 BD 61 1A 78 85 7A B8 1E 92 A2 22 2F CE
-           :     07 1A 08 8E F1 46 03 59 36 4A CB 60 E6 03
-           :     40 01 5B 2A 44 D6 E4 7F EB 43 5E 74 0A E6
-           :     E4 F9 3E E1 44 BE 1F E7 5F 5B 2C 41 8D 08
-           :     BD 26 FE 6A A6 C3 2F B2 3B 41 12 6B C1 06
-           :     8A B8 4C 91 59 EB 2F 38 20 2A 67 74 20 0B
-           :     77 F3
-           :   }
-
-C.4  Certificate Revocation List
-
-   This section contains an annotated hex dump of a version 2 CRL with
-   one extension (cRLNumber).  The CRL was issued by OU=NIST; O=gov;
-   C=US on August 7, 1997; the next scheduled issuance was September 7,
-   1997.  The CRL includes one revoked certificates: serial number 18
-   (12 hex), which was revoked on July 31, 1997 due to keyCompromise.
-   The CRL itself is number 18, and it was signed with DSA and SHA-1.
-
-  0 30  203: SEQUENCE {
-  3 30  140:   SEQUENCE {
-  6 02    1:     INTEGER 1
-  9 30    9:     SEQUENCE {
- 11 06    7:       OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
-           :       }
- 20 30   42:     SEQUENCE {
- 22 31   11:       SET {
- 24 30    9:         SEQUENCE {
- 26 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
- 31 13    2:           PrintableString 'US'
-           :           }
-           :         }
- 35 31   12:       SET {
- 37 30   10:         SEQUENCE {
- 39 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
- 44 13    3:           PrintableString 'gov'
-           :           }
-           :         }
- 49 31   13:       SET {
- 51 30   11:         SEQUENCE {
-
-
-
-Housley, et. al.            Standards Track                   [Page 126]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
- 53 06    3:           OBJECT IDENTIFIER
-           :             organizationalUnitName (2 5 4 11)
- 58 13    4:           PrintableString 'NIST'
-           :           }
-           :         }
-           :       }
- 64 17   13:     UTCTime '970807000000Z'
- 79 17   13:     UTCTime '970907000000Z'
- 94 30   34:     SEQUENCE {
- 96 30   32:       SEQUENCE {
- 98 02    1:         INTEGER 18
-101 17   13:         UTCTime '970731000000Z'
-116 30   12:         SEQUENCE {
-118 30   10:           SEQUENCE {
-120 06    3:             OBJECT IDENTIFIER cRLReason (2 5 29 21)
-125 04    3:             OCTET STRING, encapsulates {
-127 0A    1:                 ENUMERATED 1
-           :                 }
-           :             }
-           :           }
-           :         }
-           :       }
-130 A0   14:     [0] {
-132 30   12:       SEQUENCE {
-134 30   10:         SEQUENCE {
-136 06    3:           OBJECT IDENTIFIER cRLNumber (2 5 29 20)
-141 04    3:           OCTET STRING, encapsulates {
-143 02    1:               INTEGER 12
-           :               }
-           :           }
-           :         }
-           :       }
-           :     }
-146 30    9:   SEQUENCE {
-148 06    7:     OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
-           :     }
-157 03   47:   BIT STRING 0 unused bits, encapsulates {
-160 30   44:       SEQUENCE {
-162 02   20:         INTEGER
-           :           22 4E 9F 43 BA 95 06 34 F2 BB 5E 65 DB A6
-           :           80 05 C0 3A 29 47
-184 02   20:         INTEGER
-           :           59 1A 57 C9 82 D7 02 21 14 C3 D4 0B 32 1B
-           :           96 16 B1 1F 46 5A
-           :         }
-           :       }
-           :   }
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 127]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-Author Addresses
-
-   Russell Housley
-   RSA Laboratories
-   918 Spring Knoll Drive
-   Herndon, VA 20170
-   USA
-
-   EMail:  rhousley@rsasecurity.com
-
-   Warwick Ford
-   VeriSign, Inc.
-   401 Edgewater Place
-   Wakefield, MA 01880
-   USA
-
-   EMail:  wford@verisign.com
-
-   Tim Polk
-   NIST
-   Building 820, Room 426
-   Gaithersburg, MD 20899
-   USA
-
-   EMail:  wpolk@nist.gov
-
-   David Solo
-   Citigroup
-   909 Third Ave, 16th Floor
-   New York, NY 10043
-   USA
-
-   EMail:  dsolo@alum.mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 128]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 129]
-
diff --git a/doc/standardisation/rfc3281.txt b/doc/standardisation/rfc3281.txt
deleted file mode 100644
index 91266ee98..000000000
--- a/doc/standardisation/rfc3281.txt
+++ /dev/null
@@ -1,2243 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         S. Farrell
-Request for Comments: 3281                        Baltimore Technologies
-Category: Standards Track                                     R. Housley
-                                                        RSA Laboratories
-                                                              April 2002
-
-
-                   An Internet Attribute Certificate
-                       Profile for Authorization
-
-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 (2002).  All Rights Reserved.
-
-Abstract
-
-   This specification defines a profile for the use of X.509 Attribute
-   Certificates in Internet Protocols.  Attribute certificates may be
-   used in a wide range of applications and environments covering a
-   broad spectrum of interoperability goals and a broader spectrum of
-   operational and assurance requirements.  The goal of this document is
-   to establish a common baseline for generic applications requiring
-   broad interoperability as well as limited special purpose
-   requirements.  The profile places emphasis on attribute certificate
-   support for Internet electronic mail, IPSec, and WWW security
-   applications.
-
-Table of Contents
-
-   1. Introduction.................................................  2
-       1.1  Delegation and AC chains...............................  4
-       1.2  Attribute Certificate Distribution ("push" vs. "pull").  4
-       1.3  Document Structure.....................................  6
-   2. Terminology..................................................  6
-   3. Requirements.................................................  7
-   4. Attribute Certificate Profile................................  7
-       4.1  X.509 Attribute Certificate Definition.................  8
-       4.2  Profile of Standard Fields............................. 10
-           4.2.1  Version.......................................... 10
-           4.2.2  Holder........................................... 11
-
-
-
-Farrell & Housley           Standards Track                     [Page 1]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-           4.2.3  Issuer........................................... 12
-           4.2.4  Signature........................................ 12
-           4.2.5  Serial Number.................................... 12
-           4.2.6  Validity Period.................................. 13
-           4.2.7  Attributes....................................... 13
-           4.2.8  Issuer Unique Identifier......................... 14
-           4.2.9  Extensions....................................... 14
-       4.3  Extensions............................................. 14
-           4.3.1  Audit Identity................................... 14
-           4.3.2  AC Targeting..................................... 15
-           4.3.3  Authority Key Identifier......................... 17
-           4.3.4  Authority Information Access..................... 17
-           4.3.5  CRL Distribution Points.......................... 17
-           4.3.6  No Revocation Available.......................... 18
-       4.4  Attribute Types........................................ 18
-           4.4.1  Service Authentication Information............... 19
-           4.4.2  Access Identity.................................. 19
-           4.4.3  Charging Identity................................ 20
-           4.4.4  Group............................................ 20
-           4.4.5  Role............................................. 20
-           4.4.6  Clearance........................................ 21
-       4.5  Profile of AC issuer's PKC............................. 22
-   5. Attribute Certificate Validation............................. 23
-   6. Revocation................................................... 24
-   7. Optional Features............................................ 25
-       7.1  Attribute Encryption................................... 25
-       7.2  Proxying............................................... 27
-       7.3  Use of ObjectDigestInfo................................ 28
-       7.4  AA Controls............................................ 29
-   8. Security Considerations...................................... 30
-   9. IANA Considerations.......................................... 32
-   10. References.................................................. 32
-   Appendix A: Object Identifiers.................................. 34
-   Appendix B: ASN.1 Module........................................ 35
-   Author's Addresses.............................................. 39
-   Acknowledgements................................................ 39
-   Full Copyright Statement........................................ 40
-
-1. Introduction
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in BCP 14, RFC 2119.
-
-   X.509 public key certificates (PKCs) [X.509-1997, X.509-2000,
-   PKIXPROF] bind an identity and a public key.  An attribute
-   certificate (AC) is a structure similar to a PKC; the main difference
-   being that the AC contains no public key.  An AC may contain
-
-
-
-Farrell & Housley           Standards Track                     [Page 2]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   attributes that specify group membership, role, security clearance,
-   or other authorization information associated with the AC holder.
-   The syntax for the AC is defined in Recommendation X.509, making the
-   term "X.509 certificate" ambiguous.
-
-   Some people constantly confuse PKCs and ACs.  An analogy may make the
-   distinction clear.  A PKC can be considered to be like a passport: it
-   identifies the holder, tends to last for a long time, and should not
-   be trivial to obtain.  An AC is more like an entry visa: it is
-   typically issued by a different authority and does not last for as
-   long a time.  As acquiring an entry visa typically requires
-   presenting a passport, getting a visa can be a simpler process.
-
-   Authorization information may be placed in a PKC extension or placed
-   in a separate attribute certificate (AC).  The placement of
-   authorization information in PKCs is usually undesirable for two
-   reasons.  First, authorization information often does not have the
-   same lifetime as the binding of the identity and the public key.
-   When authorization information is placed in a PKC extension, the
-   general result is the shortening of the PKC useful lifetime.  Second,
-   the PKC issuer is not usually authoritative for the authorization
-   information.  This results in additional steps for the PKC issuer to
-   obtain authorization information from the authoritative source.
-
-   For these reasons, it is often better to separate authorization
-   information from the PKC.  Yet, authorization information also needs
-   to be bound to an identity.  An AC provides this binding; it is
-   simply a digitally signed (or certified) identity and set of
-   attributes.
-
-   An AC may be used with various security services, including access
-   control, data origin authentication, and non-repudiation.
-
-   PKCs can provide an identity to access control decision functions.
-   However, in many contexts the identity is not the criterion that is
-   used for access control decisions, rather the role or group-
-   membership of the accessor is the criterion used.  Such access
-   control schemes are called role-based access control.
-
-   When making an access control decision based on an AC, an access
-   control decision function may need to ensure that the appropriate AC
-   holder is the entity that has requested access.  One way in which the
-   linkage between the request or identity and the AC can be achieved is
-   the inclusion of a reference to a PKC within the AC and the use of
-   the private key corresponding to the PKC for authentication within
-   the access request.
-
-
-
-
-
-Farrell & Housley           Standards Track                     [Page 3]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   ACs may also be used in the context of a data origin authentication
-   service and a non-repudiation service.  In these contexts, the
-   attributes contained in the AC provide additional information about
-   the signing entity.  This information can be used to make sure that
-   the entity is authorized to sign the data.  This kind of checking
-   depends either on the context in which the data is exchanged or on
-   the data that has been digitally signed.
-
-1.1 Delegation and AC chains
-
-   The X.509 standard [X.509-2000] defines authorization as the
-   "conveyance of privilege from one entity that holds such privilege,
-   to another entity".  An AC is one authorization mechanism.
-
-   An ordered sequence of ACs could be used to verify the authenticity
-   of a privilege asserter's privilege.  In this way, chains or paths of
-   ACs could be employed to delegate authorization.
-
-   Since the administration and processing associated with such AC
-   chains is complex and the use of ACs in the Internet today is quite
-   limited, this specification does NOT RECOMMEND the use of AC chains.
-   Other (future) specifications may address the use of AC chains.  This
-   specification deals with the simple cases, where one authority issues
-   all of the ACs for a particular set of attributes.  However, this
-   simplification does not preclude the use of several different
-   authorities, each of which manages a different set of attributes.
-   For example, group membership may be included in one AC issued by one
-   authority, and security clearance may be included in another AC
-   issued by another authority.
-
-   This means that conformant implementations are only REQUIRED to be
-   able to process a single AC at a time.  Processing of more than one
-   AC, one after another, may be necessary.  Note however, that
-   validation of an AC MAY require validation of a chain of PKCs, as
-   specified in [PKIXPROF].
-
-1.2 Attribute Certificate Distribution ("push" vs. "pull")
-
-   As discussed above, ACs provide a mechanism to securely provide
-   authorization information to, for example, access control decision
-   functions.  However, there are a number of possible communication
-   paths for ACs.
-
-   In some environments, it is suitable for a client to "push" an AC to
-   a server.  This means that no new connections between the client and
-   server are required.  It also means that no search burden is imposed
-   on servers, which improves performance and that the AC verifier is
-
-
-
-
-Farrell & Housley           Standards Track                     [Page 4]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   only presented with what it "needs to know."  The "push" model is
-   especially suitable in inter-domain cases where the client's rights
-   should be assigned within the client's "home" domain.
-
-   In other cases, it is more suitable for a client to simply
-   authenticate to the server and for the server to request or "pull"
-   the client's AC from an AC issuer or a repository.  A major benefit
-   of the "pull" model is that it can be implemented without changes to
-   the client or to the client-server protocol.  The "pull" model is
-   especially suitable for inter-domain cases where the client's rights
-   should be assigned within the server's domain, rather than within the
-   client's domain.
-
-   There are a number of possible exchanges involving three entities:
-   the client, the server, and the AC issuer.  In addition, a directory
-   service or other repository for AC retrieval MAY be supported.
-
-   Figure 1 shows an abstract view of the exchanges that may involve
-   ACs.  This profile does not specify a protocol for these exchanges.
-
-      +--------------+
-      |              |        Server Acquisition
-      |  AC issuer   +----------------------------+
-      |              |                            |
-      +--+-----------+                            |
-         |                                        |
-         | Client                                 |
-         | Acquisition                            |
-         |                                        |
-      +--+-----------+                         +--+------------+
-      |              |       AC "push"         |               |
-      |   Client     +-------------------------+    Server     |
-      |              | (part of app. protocol) |               |
-      +--+-----------+                         +--+------------+
-         |                                        |
-         | Client                                 | Server
-         | Lookup        +--------------+         | Lookup
-         |               |              |         |
-         +---------------+  Repository  +---------+
-                         |              |
-                         +--------------+
-
-                     Figure 1: AC Exchanges
-
-
-
-
-
-
-
-
-Farrell & Housley           Standards Track                     [Page 5]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-1.3 Document Structure
-
-   Section 2 defines some terminology.  Section 3 specifies the
-   requirements that this profile is intended to meet.  Section 4
-   contains the profile of the X.509 AC.  Section 5 specifies rules for
-   AC validation.  Section 6 specifies rules for AC revocation checks.
-   Section 7 specifies optional features which MAY be supported;
-   however, support for these features is not required for conformance
-   to this profile.  Finally, appendices contain the list of OIDs
-   required to support this specification and an ASN.1 module.
-
-2. Terminology
-
-   For simplicity, we use the terms client and server in this
-   specification.  This is not intended to indicate that ACs are only to
-   be used in client-server environments.  For example, ACs may be used
-   in the S/MIME v3 context, where the mail user agent would be both a
-   "client" and a "server" in the sense the terms are used here.
-
-   Term          Meaning
-
-   AA            Attribute Authority, the entity that issues the
-                 AC, synonymous in this specification with "AC
-                 issuer"
-   AC            Attribute Certificate
-   AC user       any entity that parses or processes an AC
-   AC verifier   any entity that checks the validity of an AC and
-                 then makes use of the result
-   AC issuer     the entity which signs the AC, synonymous in this
-                 specification with "AA"
-   AC holder     the entity indicated (perhaps indirectly) in the
-                 holder field of the AC
-   Client        the entity which is requesting the action for
-                 which authorization checks are to be made
-   Proxying      In this specification, Proxying is used to mean
-                 the situation where an application server acts as
-                 an application client on behalf of a user.
-                 Proxying here does not mean granting of authority.
-   PKC           Public Key Certificate - uses the type ASN.1
-                 Certificate defined in X.509 and profiled in RFC
-                 2459.  This (non-standard) acronym is used in order
-                 to avoid confusion about the term "X.509
-                 certificate".
-   Server        the entity which requires that the authorization
-                 checks are made
-
-
-
-
-
-
-Farrell & Housley           Standards Track                     [Page 6]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-3. Requirements
-
-   This AC profile meets the following requirements.
-
-   Time/Validity requirements:
-
-   1. Support for short-lived as well as long-lived ACs.  Typical
-      short-lived validity periods might be measured in hours, as
-      opposed to months for PKCs.  Short validity periods allow ACs to
-      be useful without a revocation mechanism.
-
-   Attribute Types:
-
-   2. Issuers of ACs should be able to define their own attribute types
-      for use within closed domains.
-
-   3. Some standard attribute types, which can be contained within ACs,
-      should be defined.  Examples include "access identity," "group,"
-      "role," "clearance," "audit identity," and "charging identity."
-
-   4. Standard attribute types should be defined in a manner that
-      permits an AC verifier to distinguish between uses of the same
-      attribute in different domains.  For example, the "Administrators
-      group" as defined by Baltimore and the "Administrators group" as
-      defined by SPYRUS should be easily distinguished.
-
-   Targeting of ACs:
-
-   5. It should be possible to "target" an AC at one, or a small number
-      of, servers.  This means that a trustworthy non-target server will
-      reject the AC for authorization decisions.
-
-   Push vs. Pull
-
-   6. ACs should be defined so that they can either be "pushed" by the
-      client to the server, or "pulled" by the server from a repository
-      or other network service, including an online AC issuer.
-
-4. Attribute Certificate Profile
-
-   ACs may be used in a wide range of applications and environments
-   covering a broad spectrum of interoperability goals and a broader
-   spectrum of operational and assurance requirements.  The goal of this
-   document is to establish a common baseline for generic applications
-   requiring broad interoperability and limited special purpose
-
-
-
-
-
-
-Farrell & Housley           Standards Track                     [Page 7]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   requirements.  In particular, the emphasis will be on supporting the
-   use of attribute certificates for informal Internet electronic mail,
-   IPSec, and WWW applications.
-
-   This section presents a profile for ACs that will foster
-   interoperability.  This section also defines some private extensions
-   for the Internet community.
-
-   While the ISO/IEC/ITU documents use the 1993 (or later) version of
-   ASN.1, this document uses the 1988 ASN.1 syntax, as has been done for
-   PKCs [PKIXPROF].  The encoded certificates and extensions from either
-   ASN.1 version are bit-wise identical.
-
-   Where maximum lengths for fields are specified, these lengths refer
-   to the DER encoding and do not include the ASN.1 tag or length
-   fields.
-
-   Conforming implementations MUST support the profile specified in this
-   section.
-
-4.1 X.509 Attribute Certificate Definition
-
-   X.509 contains the definition of an AC given below.  All types that
-   are not defined in this document can be found in [PKIXPROF].
-
-            AttributeCertificate ::= SEQUENCE {
-                 acinfo               AttributeCertificateInfo,
-                 signatureAlgorithm   AlgorithmIdentifier,
-                 signatureValue       BIT STRING
-            }
-
-            AttributeCertificateInfo ::= SEQUENCE {
-                 version              AttCertVersion -- version is v2,
-                 holder               Holder,
-                 issuer               AttCertIssuer,
-                 signature            AlgorithmIdentifier,
-                 serialNumber         CertificateSerialNumber,
-                 attrCertValidityPeriod   AttCertValidityPeriod,
-                 attributes           SEQUENCE OF Attribute,
-                 issuerUniqueID       UniqueIdentifier OPTIONAL,
-                 extensions           Extensions OPTIONAL
-            }
-
-            AttCertVersion ::= INTEGER { v2(1) }
-            Holder ::= SEQUENCE {
-                  baseCertificateID   [0] IssuerSerial OPTIONAL,
-                           -- the issuer and serial number of
-                           -- the holder's Public Key Certificate
-
-
-
-Farrell & Housley           Standards Track                     [Page 8]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-                  entityName          [1] GeneralNames OPTIONAL,
-                           -- the name of the claimant or role
-                  objectDigestInfo    [2] ObjectDigestInfo OPTIONAL
-                           -- used to directly authenticate the holder,
-                           -- for example, an executable
-            }
-
-            ObjectDigestInfo ::= SEQUENCE {
-                 digestedObjectType  ENUMERATED {
-                         publicKey            (0),
-                         publicKeyCert        (1),
-                         otherObjectTypes     (2) },
-                                 -- otherObjectTypes MUST NOT
-                                 -- be used in this profile
-                 otherObjectTypeID   OBJECT IDENTIFIER OPTIONAL,
-                 digestAlgorithm     AlgorithmIdentifier,
-                 objectDigest        BIT STRING
-            }
-
-            AttCertIssuer ::= CHOICE {
-                 v1Form   GeneralNames,  -- MUST NOT be used in this
-                                         -- profile
-                 v2Form   [0] V2Form     -- v2 only
-            }
-
-            V2Form ::= SEQUENCE {
-                 issuerName            GeneralNames  OPTIONAL,
-                 baseCertificateID     [0] IssuerSerial  OPTIONAL,
-                 objectDigestInfo      [1] ObjectDigestInfo  OPTIONAL
-                   -- issuerName MUST be present in this profile
-                   -- baseCertificateID and objectDigestInfo MUST NOT
-                   -- be present in this profile
-            }
-
-            IssuerSerial  ::=  SEQUENCE {
-                 issuer         GeneralNames,
-                 serial         CertificateSerialNumber,
-                 issuerUID      UniqueIdentifier OPTIONAL
-            }
-
-            AttCertValidityPeriod  ::= SEQUENCE {
-                 notBeforeTime  GeneralizedTime,
-                 notAfterTime   GeneralizedTime
-            }
-
-
-
-
-
-
-
-Farrell & Housley           Standards Track                     [Page 9]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   Although the Attribute syntax is defined in [PKIXPROF], we repeat
-   the definition here for convenience.
-
-            Attribute ::= SEQUENCE {
-                  type      AttributeType,
-                  values    SET OF AttributeValue
-                    -- at least one value is required
-            }
-
-            AttributeType ::= OBJECT IDENTIFIER
-
-            AttributeValue ::= ANY DEFINED BY AttributeType
-
-   Implementers should note that the DER encoding (see [X.509-
-   1988],[X.208-1988]) of the SET OF values requires ordering of the
-   encodings of the values.  Though this issue arises with respect to
-   distinguished names, and has to be handled by [PKIXPROF]
-   implementations, it is much more significant in this context, since
-   the inclusion of multiple values is much more common in ACs.
-
-4.2 Profile of Standard Fields
-
-   GeneralName offers great flexibility.  To achieve interoperability,
-   in spite of this flexibility, this profile imposes constraints on the
-   use of GeneralName.
-
-   Conforming implementations MUST be able to support the dNSName,
-   directoryName, uniformResourceIdentifier, and iPAddress options.
-   This is compatible with the GeneralName requirements in [PKIXPROF]
-   (mainly in section 4.2.1.7).
-
-   Conforming implementations MUST NOT use the x400Address,
-   ediPartyName, or registeredID options.
-
-   Conforming implementations MAY use the otherName option to convey
-   name forms defined in Internet Standards.  For example, Kerberos
-   [KRB] format names can be encoded into the otherName, using a
-   Kerberos 5 principal name OID and a SEQUENCE of the Realm and the
-   PrincipalName.
-
-4.2.1   Version
-
-   The version field MUST have the value of v2.  That is, the version
-   field is present in the DER encoding.
-
-
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 10]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   Note: This version (v2) is not backwards compatible with the previous
-   attribute certificate definition (v1) from the 1997 X.509 standard
-   [X.509-1997], but is compatible with the v2 definition from X.509
-   (2000) [X.509-2000].
-
-4.2.2   Holder
-
-   The Holder field is a SEQUENCE allowing three different (optional)
-   syntaxes: baseCertificateID, entityName and objectDigestInfo.  Where
-   only one option is present, the meaning of the Holder field is clear.
-   However, where more than one option is used, there is a potential for
-   confusion as to which option is "normative", which is a "hint" etc.
-   Since the correct position is not clear from [X.509-2000], this
-   specification RECOMMENDS that only one of the options be used in any
-   given AC.
-
-   For any environment where the AC is passed in an authenticated
-   message or session and where the authentication is based on the use
-   of an X.509 PKC, the holder field SHOULD use the baseCertificateID.
-
-   With the baseCertificateID option, the holder's PKC serialNumber and
-   issuer MUST be identical to the AC holder field.  The PKC issuer MUST
-   have a non-empty distinguished name which is to be present as the
-   single value of the holder.baseCertificateID.issuer construct in the
-   directoryName field.  The AC holder.baseCertificateID.issuerUID field
-   MUST only be used if the holder's PKC contains an issuerUniqueID
-   field.  If both the AC holder.baseCertificateID.issuerUID and the PKC
-   issuerUniqueID fields are present, the same value MUST be present in
-   both fields.  Thus, the baseCertificateID is only usable with PKC
-   profiles (like [PKIXPROF]) which mandate that the PKC issuer field
-   contain a non-empty distinguished name value.
-
-   Note: An empty distinguished name is a distinguished name where the
-   SEQUENCE OF relative distinguished names is of zero length.  In a DER
-   encoding, this has the value '3000'H.
-
-   If the holder field uses the entityName option and the underlying
-   authentication is based on a PKC, the entityName MUST be the same as
-   the PKC subject field or one of the values of the PKC subjectAltName
-   field extension (if present).  Note that [PKIXPROF] mandates that the
-   subjectAltName extension be present if the PKC subject is an empty
-   distinguished name.  See the security considerations section which
-   mentions some name collision problems that may arise when using the
-   entityName option.
-
-   In any other case where the holder field uses the entityName option,
-   only one name SHOULD be present.
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 11]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   Implementations conforming to this profile are not required to
-   support the use of the objectDigest field.  However, section 7.3
-   specifies how this optional feature MAY be used.
-
-   Any protocol conforming to this profile SHOULD specify which AC
-   holder option is to be used and how this fits with the supported
-   authentication schemes defined in that protocol.
-
-4.2.3   Issuer
-
-   ACs conforming to this profile MUST use the v2Form choice, which MUST
-   contain one and only one GeneralName in the issuerName, which MUST
-   contain a non-empty distinguished name in the directoryName field.
-   This means that all AC issuers MUST have non-empty distinguished
-   names.  ACs conforming to this profile MUST omit the
-   baseCertificateID and objectDigestInfo fields.
-
-   Part of the reason for the use of the v2Form containing only an
-   issuerName is that it means that the AC issuer does not have to know
-   which PKC the AC verifier will use for it (the AC issuer).  Using the
-   baseCertificateID field to reference the AC issuer would mean that
-   the AC verifier would have to trust the PKC that the AC issuer chose
-   (for itself) at AC creation time.
-
-4.2.4   Signature
-
-   Contains the algorithm identifier used to validate the AC signature.
-
-   This MUST be one of the signing algorithms defined in [PKIXALGS].
-   Conforming implementations MUST honor all MUST/SHOULD/MAY signing
-   algorithm statements specified in [PKIXALGS].
-
-4.2.5   Serial Number
-
-   For any conforming AC, the issuer/serialNumber pair MUST form a
-   unique combination, even if ACs are very short-lived.
-
-   AC issuers MUST force the serialNumber to be a positive integer, that
-   is, the sign bit in the DER encoding of the INTEGER value MUST be
-   zero - this can be done by adding a leading (leftmost) '00'H octet if
-   necessary.  This removes a potential ambiguity in mapping between a
-   string of octets and an integer value.
-
-   Given the uniqueness and timing requirements above, serial numbers
-   can be expected to contain long integers.  AC users MUST be able to
-   handle serialNumber values longer than 4 octets.  Conformant ACs MUST
-   NOT contain serialNumber values longer than 20 octets.
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 12]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   There is no requirement that the serial numbers used by any AC issuer
-   follow any particular ordering.  In particular, they need not be
-   monotonically increasing with time.  Each AC issuer MUST ensure that
-   each AC that it issues contains a unique serial number.
-
-4.2.6   Validity Period
-
-   The attrCertValidityPeriod (a.k.a. validity) field specifies the
-   period for which the AC issuer certifies that the binding between the
-   holder and the attributes fields will be valid.
-
-   The generalized time type, GeneralizedTime, is a standard ASN.1 type
-   for variable precision representation of time.  The GeneralizedTime
-   field can optionally include a representation of the time
-   differential between the local time zone and Greenwich Mean Time.
-
-   For the purposes of this profile, GeneralizedTime values MUST be
-   expressed in Coordinated universal time (UTC) (also known as
-   Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times
-   are YYYYMMDDHHMMSSZ), even when the number of seconds is zero.
-   GeneralizedTime values MUST NOT include fractional seconds.
-
-   (Note: this is the same as specified in [PKIXPROF], section
-   4.1.2.5.2.)
-
-   AC users MUST be able to handle an AC which, at the time of
-   processing, has parts of its validity period or all its validity
-   period in the past or in the future (a post-dated AC).  This is valid
-   for some applications, such as backup.
-
-4.2.7   Attributes
-
-   The attributes field gives information about the AC holder.  When the
-   AC is used for authorization, this will often contain a set of
-   privileges.
-
-   The attributes field contains a SEQUENCE OF Attribute.  Each
-   Attribute MAY contain a SET OF values.  For a given AC, each
-   AttributeType OBJECT IDENTIFIER in the sequence MUST be unique.  That
-   is, only one instance of each attribute can occur in a single AC, but
-   each instance can be multi-valued.
-
-   AC users MUST be able to handle multiple values for all attribute
-   types.
-
-   An AC MUST contain at least one attribute.  That is, the SEQUENCE OF
-   Attributes MUST NOT be of zero length.
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 13]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   Some standard attribute types are defined in section 4.4.
-
-4.2.8   Issuer Unique Identifier
-
-   This field MUST NOT be used unless it is also used in the AC issuer's
-   PKC, in which case it MUST be used.  Note that [PKIXPROF] states that
-   this field SHOULD NOT be used by conforming CAs, but that
-   applications SHOULD be able to parse PKCs containing the field.
-
-4.2.9   Extensions
-
-   The extensions field generally gives information about the AC as
-   opposed to information about the AC holder.
-
-   An AC that has no extensions conforms to the profile; however,
-   section 4.3 defines the extensions that MAY be used with this
-   profile, and whether or not they may be marked critical.  If any
-   other critical extension is used, the AC does not conform to this
-   profile.  However, if any other non-critical extension is used, the
-   AC does conform to this profile.
-
-   The extensions defined for ACs provide methods for associating
-   additional attributes with holders.  This profile also allows
-   communities to define private extensions to carry information unique
-   to those communities.  Each extension in an AC may be designated as
-   critical or non-critical.  An AC using system MUST reject an AC if it
-   encounters a critical extension it does not recognize; however, a
-   non-critical extension may be ignored if it is not recognized.
-   Section 4.3 presents recommended extensions used within Internet ACs
-   and standard locations for information.  Communities may elect to use
-   additional extensions; however, caution should be exercised in
-   adopting any critical extensions in ACs which might prevent use in a
-   general context.
-
-4.3 Extensions
-
-4.3.1   Audit Identity
-
-   In some circumstances, it is required (e.g. by data protection/data
-   privacy legislation) that audit trails not contain records which
-   directly identify individuals.  This circumstance may make the use of
-   the AC holder field unsuitable for use in audit trails.
-
-   To allow for such cases, an AC MAY contain an audit identity
-   extension.  Ideally it SHOULD be infeasible to derive the AC holder's
-   identity from the audit identity value without the cooperation of the
-   AC issuer.
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 14]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   The value of the audit identity, along with the AC issuer/serial,
-   SHOULD then be used for audit/logging purposes.  If the value of the
-   audit identity is suitably chosen, a server/service administrator can
-   use audit trails to track the behavior of an AC holder without being
-   able to identify the AC holder.
-
-   The server/service administrator in combination with the AC issuer
-   MUST be able to identify the AC holder in cases where misbehavior is
-   detected.  This means that the AC issuer MUST be able to determine
-   the actual identity of the AC holder from the audit identity.
-
-   Of course, auditing could be based on the AC issuer/serial pair;
-   however, this method does not allow tracking of the same AC holder
-   with multiple ACs.  Thus, an audit identity is only useful if it
-   lasts for longer than the typical AC lifetime.  Auditing could also
-   be based on the AC holder's PKC issuer/serial; however, this will
-   often allow the server/service administrator to identify the AC
-   holder.
-
-   As the AC verifier might otherwise use the AC holder or some other
-   identifying value for audit purposes, this extension MUST be critical
-   when used.
-
-   Protocols that use ACs will often expose the identity of the AC
-   holder in the bits on-the-wire.  In such cases, an opaque audit
-   identity does not make use of the AC anonymous; it simply ensures
-   that the ensuing audit trails do not contain identifying information.
-
-   The value of an audit identity MUST be longer than zero octets.  The
-   value of an audit identity MUST NOT be longer than 20 octets.
-
-      name           id-pe-ac-auditIdentity
-      OID            { id-pe 4 }
-      syntax         OCTET STRING
-      criticality    MUST be TRUE
-
-4.3.2   AC Targeting
-
-   To target an AC, the target information extension, imported from
-   [X.509-2000], MAY be used to specify a number of servers/services.
-   The intent is that the AC SHOULD only be usable at the specified
-   servers/services.  An (honest) AC verifier who is not amongst the
-   named servers/services MUST reject the AC.
-
-   If this extension is not present, the AC is not targeted and may be
-   accepted by any server.
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 15]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   In this profile, the targeting information simply consists of a list
-   of named targets or groups.
-
-   The following syntax is used to represent the targeting information:
-
-            Targets ::= SEQUENCE OF Target
-
-            Target  ::= CHOICE {
-              targetName          [0] GeneralName,
-              targetGroup         [1] GeneralName,
-              targetCert          [2] TargetCert
-            }
-
-            TargetCert  ::= SEQUENCE {
-              targetCertificate    IssuerSerial,
-              targetName           GeneralName OPTIONAL,
-              certDigestInfo       ObjectDigestInfo OPTIONAL
-            }
-
-   The targetCert CHOICE within the Target structure is only present to
-   allow future compatibility with [X.509-2000] and MUST NOT be used.
-
-   The targets check passes if the current server (recipient) is one of
-   the targetName fields in the Targets SEQUENCE, or if the current
-   server is a member of one of the targetGroup fields in the Targets
-   SEQUENCE.  In this case, the current server is said to "match" the
-   targeting extension.
-
-   How the membership of a target within a targetGroup is determined is
-   not defined here.  It is assumed that any given target "knows" the
-   names of the targetGroups to which it belongs or can otherwise
-   determine its membership.  For example, the targetGroup specifies a
-   DNS domain, and the AC verifier knows the DNS domain to which it
-   belongs.  For another example, the targetGroup specifies "PRINTERS,"
-   and the AC verifier knows whether or not it is a printer or print
-   server.
-
-   Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF
-   Targets".  Conforming AC issuer implementations MUST only produce one
-   "Targets" element.  Confirming AC users MUST be able to accept a
-   "SEQUENCE OF Targets".  If more than one Targets element is found in
-   an AC, the extension MUST be treated as if all Target elements had
-   been found within one Targets element.
-
-      name           id-ce-targetInformation
-      OID            { id-ce 55 }
-      syntax         SEQUENCE OF Targets
-      criticality    MUST be TRUE
-
-
-
-Farrell & Housley           Standards Track                    [Page 16]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-4.3.3   Authority Key Identifier
-
-   The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY
-   be used to assist the AC verifier in checking the signature of the
-   AC.  The [PKIXPROF] description should be read as if "CA" meant "AC
-   issuer."  As with PKCs, this extension SHOULD be included in ACs.
-
-   Note: An AC, where the issuer field used the baseCertificateID
-   CHOICE, would not need an authorityKeyIdentifier extension, as it is
-   explicitly linked to the key in the referred certificate.  However,
-   as this profile states (in section 4.2.3), ACs MUST use the v2Form
-   with issuerName CHOICE, this duplication does not arise.
-
-      name           id-ce-authorityKeyIdentifier
-      OID            { id-ce 35 }
-      syntax         AuthorityKeyIdentifier
-      criticality    MUST be FALSE
-
-4.3.4   Authority Information Access
-
-   The authorityInformationAccess extension, as defined in [PKIXPROF],
-   MAY be used to assist the AC verifier in checking the revocation
-   status of the AC.  Support for the id-ad-caIssuers accessMethod is
-   NOT REQUIRED by this profile since AC chains are not expected.
-
-   The following accessMethod is used to indicate that revocation status
-   checking is provided for this AC, using the OCSP protocol defined in
-   [OCSP]:
-
-      id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
-
-   The accessLocation MUST contain a URI, and the URI MUST contain an
-   HTTP URL [URL] that specifies the location of an OCSP responder.  The
-   AC issuer MUST, of course, maintain an OCSP responder at this
-   location.
-
-      name           id-ce-authorityInfoAccess
-      OID            { id-pe 1 }
-      syntax         AuthorityInfoAccessSyntax
-      criticality    MUST be FALSE
-
-4.3.5   CRL Distribution Points
-
-   The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY
-   be used to assist the AC verifier in checking the revocation status
-   of the AC.  See section 6 for details on revocation.
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 17]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   If the crlDistributionPoints extension is present, then exactly one
-   distribution point MUST be present.  The crlDistributionPoints
-   extension MUST use the DistributionPointName option, which MUST
-   contain a fullName, which MUST contain a single name form.  That name
-   MUST contain either a distinguished name or a URI.  The URI MUST be
-   either an HTTP URL or an LDAP URL [URL].
-
-      name           id-ce-cRLDistributionPoints
-      OID            { id-ce 31 }
-      syntax         CRLDistPointsSyntax
-      criticality    MUST be FALSE
-
-4.3.6   No Revocation Available
-
-   The noRevAvail extension, defined in [X.509-2000], allows an AC
-   issuer to indicate that no revocation information will be made
-   available for this AC.
-
-   This extension MUST be non-critical.  An AC verifier that does not
-   understand this extension might be able to find a revocation list
-   from the AC issuer, but the revocation list will never include an
-   entry for the AC.
-
-      name           id-ce-noRevAvail
-      OID            { id-ce 56 }
-      syntax         NULL (i.e. '0500'H is the DER encoding)
-      criticality    MUST be FALSE
-
-4.4 Attribute Types
-
-   Some of the attribute types defined below make use of the
-   IetfAttrSyntax type, also defined below.  The reasons for using this
-   type are:
-
-   1. It allows a separation between the AC issuer and the attribute
-      policy authority.  This is useful for situations where a single
-      policy authority (e.g. an organization) allocates attribute
-      values, but where multiple AC issuers are deployed for performance
-      or other reasons.
-
-   2. The syntaxes allowed for values are restricted to OCTET STRING,
-      OBJECT IDENTIFIER, and UTF8String, which significantly reduces the
-      complexity associated with matching more general syntaxes.  All
-      multi-valued attributes using this syntax are restricted so that
-      each value MUST use the same choice of value syntax.  For example,
-      AC issuers must not use one value with an oid and a second value
-      with a string.
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 18]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-               IetfAttrSyntax ::= SEQUENCE {
-                    policyAuthority [0] GeneralNames    OPTIONAL,
-                    values          SEQUENCE OF CHOICE {
-                                  octets    OCTET STRING,
-                                  oid       OBJECT IDENTIFIER,
-                                  string    UTF8String
-                   }
-               }
-
-   In the descriptions below, each attribute type is either tagged
-   "Multiple Allowed" or "One Attribute value only; multiple values
-   within the IetfAttrSyntax".  This refers to the SET OF
-   AttributeValues; the AttributeType still only occurs once, as
-   specified in section 4.2.7.
-
-4.4.1   Service Authentication Information
-
-   The SvceAuthInfo attribute identifies the AC holder to the
-   server/service by a name, and the attribute MAY include optional
-   service specific authentication information.  Typically this will
-   contain a username/password pair for a "legacy" application.
-
-   This attribute provides information that can be presented by the AC
-   verifier to be interpreted and authenticated by a separate
-   application within the target system.  Note that this is a different
-   use to that intended for the accessIdentity attribute in 4.4.2 below.
-
-   This attribute type will typically be encrypted when the authInfo
-   field contains sensitive information, such as a password.
-
-      name      id-aca-authenticationInfo
-      OID       { id-aca 1 }
-      Syntax    SvceAuthInfo
-      values:   Multiple allowed
-
-           SvceAuthInfo ::=    SEQUENCE {
-                service   GeneralName,
-                ident     GeneralName,
-                authInfo  OCTET STRING OPTIONAL
-           }
-
-4.4.2   Access Identity
-
-   The accessIdentity attribute identifies the AC holder to the
-   server/service.  For this attribute the authInfo field MUST NOT be
-   present.
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 19]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   This attribute is intended to be used to provide information about
-   the AC holder, that can be used by the AC verifier (or a larger
-   system of which the AC verifier is a component) to authorize the
-   actions of the AC holder within the AC verifier's system.  Note that
-   this is a different use to that intended for the svceAuthInfo
-   attribute described in 4.4.1 above.
-
-      name      id-aca-accessIdentity
-      OID       { id-aca 2 }
-      syntax    SvceAuthInfo
-      values:   Multiple allowed
-
-4.4.3   Charging Identity
-
-   The chargingIdentity attribute identifies the AC holder for charging
-   purposes.  In general, the charging identity will be different from
-   other identities of the holder.  For example, the holder's company
-   may be charged for service.
-
-      name      id-aca-chargingIdentity
-      OID       { id-aca 3 }
-      syntax    IetfAttrSyntax
-      values:   One Attribute value only; multiple values within the
-                IetfAttrSyntax
-
-4.4.4   Group
-
-   The group attribute carries information about group memberships of
-   the AC holder.
-
-      name      id-aca-group
-      OID       { id-aca 4 }
-      syntax    IetfAttrSyntax
-      values:   One Attribute value only; multiple values within the
-                IetfAttrSyntax
-
-4.4.5   Role
-
-   The role attribute, specified in [X.509-2000], carries information
-   about role allocations of the AC holder.
-
-   The syntax used for this attribute is:
-
-         RoleSyntax ::= SEQUENCE {
-                 roleAuthority   [0] GeneralNames OPTIONAL,
-                 roleName        [1] GeneralName
-         }
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 20]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   The roleAuthority field MAY be used to specify the issuing authority
-   for the role specification certificate.  There is no requirement that
-   a role specification certificate necessarily exists for the
-   roleAuthority.  This differs from [X.500-2000], where the
-   roleAuthority field is assumed to name the issuer of a role
-   specification certificate.  For example, to distinguish the
-   administrator role as defined by "Baltimore" from that defined by
-   "SPYRUS", one could put the value "urn:administrator" in the roleName
-   field and the value "Baltimore" or "SPYRUS" in the roleAuthority
-   field.
-
-   The roleName field MUST be present, and roleName MUST use the
-   uniformResourceIdentifier CHOICE of the GeneralName.
-
-      name      id-at-role
-      OID       { id-at 72 }
-      syntax    RoleSyntax
-      values:   Multiple allowed
-
-4.4.6   Clearance
-
-   The clearance attribute, specified in [X.501-1993], carries clearance
-   (associated with security labeling) information about the AC holder.
-
-   The policyId field is used to identify the security policy to which
-   the clearance relates.  The policyId indicates the semantics of the
-   classList and securityCategories fields.
-
-   This specification includes the classList field exactly as it is
-   specified in [X.501-1993].  Additional security classification
-   values, and their position in the classification hierarchy, may be
-   defined by a security policy as a local matter or by bilateral
-   agreement.  The basic security classification hierarchy is, in
-   ascending order: unmarked, unclassified, restricted, confidential,
-   secret, and top-secret.
-
-   An organization can develop its own security policy that defines
-   security classification values and their meanings.  However, the BIT
-   STRING positions 0 through 5 are reserved for the basic security
-   classification hierarchy.
-
-   If present, the SecurityCategory field provides further authorization
-   information.  The security policy identified by the policyId field
-   indicates the syntaxes that are allowed to be present in the
-   securityCategories SET.  An OBJECT IDENTIFIER identifies each of the
-   allowed syntaxes.  When one of these syntaxes is present in the
-   securityCategories SET, the OBJECT IDENTIFIER associated with that
-   syntax is carried in the SecurityCategory.type field.
-
-
-
-Farrell & Housley           Standards Track                    [Page 21]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-            Clearance  ::=  SEQUENCE {
-                 policyId  [0] OBJECT IDENTIFIER,
-                 classList [1] ClassList DEFAULT {unclassified},
-                 securityCategories
-                           [2] SET OF SecurityCategory OPTIONAL
-            }
-
-            ClassList  ::=  BIT STRING {
-                 unmarked       (0),
-                 unclassified   (1),
-                 restricted     (2)
-                 confidential   (3),
-                 secret         (4),
-                 topSecret      (5)
-            }
-
-            SecurityCategory ::= SEQUENCE {
-                 type      [0]  IMPLICIT OBJECT IDENTIFIER,
-                 value     [1]  ANY DEFINED BY type
-            }
-
-            -- This is the same as the original syntax which was defined
-            -- using the MACRO construct, as follows:
-            -- SecurityCategory ::= SEQUENCE {
-            --      type      [0]  IMPLICIT SECURITY-CATEGORY,
-            --      value     [1]  ANY DEFINED BY type
-            -- }
-            --
-            -- SECURITY-CATEGORY MACRO  ::=
-            -- BEGIN
-            -- TYPE NOTATION ::= type | empty
-            -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
-            -- END
-
-
-
-       name      { id-at-clearance }
-       OID       { joint-iso-ccitt(2) ds(5) module(1)
-                   selected-attribute-types(5) clearance (55) }
-       syntax    Clearance - imported from [X.501-1993]
-       values    Multiple allowed
-
-4.5 Profile of AC issuer's PKC
-
-   The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage
-   extension in the PKC MUST NOT explicitly indicate that the AC
-   issuer's public key cannot be used to validate a digital signature.
-   In order to avoid confusion regarding serial numbers and revocations,
-
-
-
-Farrell & Housley           Standards Track                    [Page 22]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   an AC issuer MUST NOT also be a PKC Issuer.  That is, an AC issuer
-   cannot be a CA as well.  So, the AC issuer's PKC MUST NOT have a
-   basicConstraints extension with the cA BOOLEAN set to TRUE.
-
-5. Attribute Certificate Validation
-
-   This section describes a basic set of rules that all valid ACs MUST
-   satisfy.  Some additional checks are also described which AC
-   verifiers MAY choose to implement.
-
-   To be valid an AC MUST satisfy all of the following:
-
-   1. Where the holder uses a PKC to authenticate to the AC verifier,
-      the AC holder's PKC MUST be found, and the entire certification
-      path of that PKC MUST be verified in accordance with [PKIXPROF].
-      As noted in the security considerations section, if some other
-      authentication scheme is used, AC verifiers need to be very
-      careful mapping the identities (authenticated identity, holder
-      field) involved.
-
-   2. The AC signature must be cryptographically correct, and the AC
-      issuer's entire PKC certification path MUST be verified in
-      accordance with [PKIXPROF].
-
-   3. The AC issuer's PKC MUST also conform to the profile specified in
-      section 4.5 above.
-
-   4. The AC issuer MUST be directly trusted as an AC issuer (by
-      configuration or otherwise).
-
-   5. The time for which the AC is being evaluated MUST be within the AC
-      validity.  If the evaluation time is equal to either notBeforeTime
-      or notAfterTime, then the AC is timely and this check succeeds.
-      Note that in some applications, the evaluation time MAY not be the
-      same as the current time.
-
-   6. The AC targeting check MUST pass as specified in section 4.3.2.
-
-   7. If the AC contains an unsupported critical extension, the AC MUST
-      be rejected.
-
-   Support for an extension in this context means:
-
-   1. The AC verifier MUST be able to parse the extension value.
-
-   2. Where the extension value SHOULD cause the AC to be rejected, the
-      AC verifier MUST reject the AC.
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 23]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   Additional Checks:
-
-   1. The AC MAY be rejected on the basis of further AC verifier
-      configuration.  For example, an AC verifier may be configured to
-      reject ACs which contain or lack certain attributes.
-
-   2. If the AC verifier provides an interface that allows applications
-      to query the contents of the AC, then the AC verifier MAY filter
-      the attributes from the AC on the basis of configured information.
-      For example, an AC verifier might be configured not to return
-      certain attributes to certain servers.
-
-6. Revocation
-
-   In many environments, the validity period of an AC is less than the
-   time required to issue and distribute revocation information.
-   Therefore, short-lived ACs typically do not require revocation
-   support.  However, long-lived ACs and environments where ACs enable
-   high value transactions MAY require revocation support.
-
-   Two revocation schemes are defined, and the AC issuer should elect
-   the one that is best suited to the environment in which the AC will
-   be employed.
-
-   "Never revoke" scheme:
-
-      ACs may be marked so that the relying party understands that no
-      revocation status information will be made available.  The
-      noRevAvail extension is defined in section 4.3.6, and the
-      noRevAvail extension MUST be present in the AC to indicate use of
-      this scheme.
-
-      Where no noRevAvail is present, the AC issuer is implicitly
-      stating that revocation status checks are supported, and some
-      revocation method MUST be provided to allow AC verifiers to
-      establish the revocation status of the AC.
-
-   "Pointer in AC" scheme:
-
-      ACs may "point" to sources of revocation status information, using
-      either an authorityInfoAccess extension or a crlDistributionPoints
-      extension within the AC.
-
-   For AC users, the "never revoke" scheme MUST be supported, and the
-   "pointer in AC" scheme SHOULD be supported.  If only the "never
-   revoke" scheme is supported, then all ACs that do not contain a
-   noRevAvail extension, MUST be rejected.
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 24]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   For AC issuers, the "never revoke" scheme MUST be supported.  If all
-   ACs that will ever be issued by that AC issuer, contains a noRevAvail
-   extension, the "pointer in AC" scheme need not be supported.  If any
-   AC can be issued that does not contain the noRevAvail extension, the
-   "pointer in AC" scheme MUST be supported.
-
-   An AC MUST NOT contain both a noRevAvail and a "pointer in AC".
-
-   An AC verifier MAY use any source for AC revocation status
-   information.
-
-7. Optional Features
-
-   This section specifies features that MAY be implemented.  Conformance
-   to this profile does NOT require support for these features; however,
-   if these features are offered, they MUST be offered as described
-   below.
-
-7.1 Attribute Encryption
-
-   Where an AC will be carried in clear within an application protocol
-   or where an AC contains some sensitive information like a legacy
-   application username/password, then encryption of AC attributes MAY
-   be needed.
-
-   When a set of attributes are to be encrypted within an AC, the
-   Cryptographic Message Syntax, EnvelopedData structure [CMS] is used
-   to carry the ciphertext and associated per-recipient keying
-   information.
-
-   This type of attribute encryption is targeted.  Before the AC is
-   signed, the attributes are encrypted for a set of predetermined
-   recipients.
-
-   The AC then contains the ciphertext inside its signed data.  The
-   EnvelopedData (id-envelopedData) ContentType is used, and the content
-   field will contain the EnvelopedData type.
-
-   The ciphertext is included in the AC as the value of an encAttrs
-   attribute.  Only one encAttrs attribute can be present in an AC;
-   however, the encAttrs attribute MAY be multi-valued, and each of its
-   values will contain an independent EnvelopedData.
-
-   Each value can contain a set of attributes (each possibly a multi-
-   valued attribute) encrypted for a set of predetermined recipients.
-
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 25]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   The cleartext that is encrypted has the type:
-
-      ACClearAttrs ::= SEQUENCE {
-           acIssuer  GeneralName,
-           acSerial  INTEGER,
-           attrs     SEQUENCE OF Attribute
-      }
-
-   The DER encoding of the ACClearAttrs structure is used as the
-   encryptedContent field of the EnvelopedData.  The DER encoding MUST
-   be embedded in an OCTET STRING.
-
-   The acIssuer and acSerial fields are present to prevent ciphertext
-   stealing.  When an AC verifier has successfully decrypted an
-   encrypted attribute, it MUST then check that the AC issuer and
-   serialNumber fields contain the same values.  This prevents a
-   malicious AC issuer from copying ciphertext from another AC (without
-   knowing its corresponding plaintext).
-
-   The procedure for an AC issuer when encrypting attributes is
-   illustrated by the following (any other procedure that gives the same
-   result MAY be used):
-
-      1.   Identify the sets of attributes that are to be encrypted for
-           each set of recipients.
-      2.   For each attribute set which is to be encrypted:
-         2.1. Create an EnvelopedData structure for the data for this
-              set of recipients.
-         2.2. Encode the ContentInfo containing the EnvelopedData as a
-              value of the encAttrs attribute.
-         2.3. Ensure the cleartext attributes are not present in the
-              to-be-signed AC.
-      3.   Add the encAttrs (with its multiple values) to the AC.
-
-   Note that there may be more than one attribute of the same type (the
-   same OBJECT IDENTIFIER) after decryption.  That is, an AC MAY contain
-   the same attribute type both in clear and in encrypted form (and
-   indeed several times if the same recipient is associated with more
-   than one EnvelopedData).  One approach implementers may choose, would
-   be to merge attribute values following decryption in order to re-
-   establish the "once only" constraint.
-
-      name      id-aca-encAttrs
-      OID       { id-aca 6}
-      Syntax    ContentInfo
-      values    Multiple Allowed
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 26]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   If an AC contains attributes, apparently encrypted for the AC
-   verifier, the decryption process MUST not fail.  If decryption does
-   fail, the AC MUST be rejected.
-
-7.2 Proxying
-
-   When a server acts as a client for another server on behalf of the AC
-   holder, the server MAY need to proxy an AC.  Such proxying MAY have
-   to be done under the AC issuer's control, so that not every AC is
-   proxiable and so that a given proxiable AC can be proxied in a
-   targeted fashion.  Support for chains of proxies (with more than one
-   intermediate server) MAY also be required.  Note that this does not
-   involve a chain of ACs.
-
-   In order to meet this requirement we define another extension,
-   ProxyInfo, similar to the targeting extension.
-
-   When this extension is present, the AC verifier must check that the
-   entity from which the AC was received was allowed to send it and that
-   the AC is allowed to be used by this verifier.
-
-   The proxying information consists of a set of proxy information, each
-   of which is a set of targeting information.  If the verifier and the
-   sender of the AC are both named in the same proxy set, the AC can
-   then be accepted (the exact rule is given below).
-
-   The effect is that the AC holder can send the AC to any valid target
-   which can then only proxy to targets which are in one of the same
-   proxy sets as itself.
-
-   The following data structure is used to represent the
-   targeting/proxying information.
-
-         ProxyInfo ::= SEQUENCE OF Targets
-
-   As in the case of targeting, the targetCert CHOICE MUST NOT be used.
-
-   A proxy check succeeds if either one of the conditions below is met:
-
-   1. The identity of the sender, as established by the underlying
-      authentication service, matches the holder field of the AC, and
-      the current server "matches" any one of the proxy sets.  Recall
-      that "matches" is as defined section 4.3.2.
-
-
-
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 27]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   2. The identity of the sender, as established by the underlying
-      authentication service, "matches" one of the proxy sets (call it
-      set "A"), and the current server is one of the targetName fields
-      in the set "A", or the current server is a member of one of the
-      targetGroup fields in set "A".
-
-   When an AC is proxied more than once, a number of targets will be on
-   the path from the original client, which is normally, but not always,
-   the AC holder.  In such cases, prevention of AC "stealing" requires
-   that the AC verifier MUST check that all targets on the path are
-   members of the same proxy set.  It is the responsibility of the AC-
-   using protocol to ensure that a trustworthy list of targets on the
-   path is available to the AC verifier.
-
-      name           id-pe-ac-proxying
-      OID            { id-pe 10 }
-      syntax         ProxyInfo
-      criticality    MUST be TRUE
-
-7.3 Use of ObjectDigestInfo
-
-   In some environments, it may be required that the AC is not linked
-   either to an identity (via entityName) or to a PKC (via
-   baseCertificateID).  The objectDigestInfo CHOICE in the holder field
-   allows support for this requirement.
-
-   If the holder is identified with the objectDigestInfo field, then the
-   AC version field MUST contain v2 (the integer 1).
-
-   The idea is to link the AC to an object by placing a hash of that
-   object into the holder field of the AC.  For example, this allows
-   production of ACs that are linked to public keys rather than names.
-   It also allows production of ACs which contain privileges associated
-   with an executable object such as a Java class.  However, this
-   profile only specifies how to use a hash over a public key or PKC.
-   That is, conformant ACs MUST NOT use the otherObjectTypes value for
-   the digestedObjectType.
-
-   To link an AC to a public key, the hash must be calculated over the
-   representation of that public key which would be present in a PKC,
-   specifically, the input for the hash algorithm MUST be the DER
-   encoding of a SubjectPublicKeyInfo representation of the key.  Note:
-   This includes the AlgorithmIdentifier as well as the BIT STRING.  The
-   rules given in [PKIXPROF] for encoding keys MUST be followed.  In
-   this case, the digestedObjectType MUST be publicKey and the
-   otherObjectTypeID field MUST NOT be present.
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 28]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   Note that if the public key value used as input to the hash function
-   has been extracted from a PKC, it is possible that the
-   SubjectPublicKeyInfo from that PKC is NOT the value which should be
-   hashed.  This can occur if DSA Dss-parms are inherited as described
-   in section 7.3.3 of [PKIXPROF].  The correct input for hashing in
-   this context will include the value of the parameters inherited from
-   the CA's PKC, and thus may differ from the SubjectPublicKeyInfo
-   present in the PKC.
-
-   Implementations which support this feature MUST be able to handle the
-   representations of public keys for the algorithms specified in
-   section 7.3 of [PKIXPROF].  In this case, the digestedObjectType MUST
-   be publicKey and the otherObjectTypeID field MUST NOT be present.
-
-   In order to link an AC to a PKC via a digest, the digest MUST be
-   calculated over the DER encoding of the entire PKC, including the
-   signature value.  In this case the digestedObjectType MUST be
-   publicKeyCert and the otherObjectTypeID field MUST NOT be present.
-
-7.4 AA Controls
-
-   During AC validation a relying party has to answer the question: is
-   this AC issuer trusted to issue ACs containing this attribute?  The
-   AAControls PKC extension MAY be used to help answer the question.
-   The AAControls extension is intended to be used in CA and AC issuer
-   PKCs.
-
-         id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
-
-         AAControls ::= SEQUENCE {
-            pathLenConstraint   INTEGER (0..MAX) OPTIONAL,
-            permittedAttrs      [0] AttrSpec OPTIONAL,
-            excludedAttrs       [1] AttrSpec OPTIONAL,
-            permitUnSpecified   BOOLEAN DEFAULT TRUE
-         }
-
-         AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
-
-   The AAControls extension is used as follows:
-
-   The pathLenConstraint, if present, is interpreted as in [PKIXPROF].
-   It restricts the allowed distance between the AA CA (a CA directly
-   trusted to include AAControls in its PKCs), and the AC issuer.
-
-   The permittedAttrs field specifies a set of attribute types that any
-   AC issuer below this AA CA is allowed to include in ACs.  If this
-   field is not present, it means that no attribute types are explicitly
-   allowed.
-
-
-
-Farrell & Housley           Standards Track                    [Page 29]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   The excludedAttrs field specifies a set of attribute types that no AC
-   issuer is allowed to include in ACs.  If this field is not present,
-   it means that no attribute types are explicitly disallowed.
-
-   The permitUnSpecified field specifies how to handle attribute types
-   which are not present in either the permittedAttrs or excludedAttrs
-   fields.  TRUE (the default) means that any unspecified attribute type
-   is allowed in ACs; FALSE means that no unspecified attribute type is
-   allowed.
-
-   When AAControls are used, the following additional checks on an AA's
-   PKC chain MUST all succeed for the AC to be valid:
-
-   1. Some CA on the ACs certificate path MUST be directly trusted to
-      issue PKCs which precede the AC issuer in the certification path;
-      call this CA the "AA CA".
-
-   2. All PKCs on the path from the AA CA, down to and including the AC
-      issuer's PKC, MUST contain an AAControls extension; however, the
-      AA CA's PKC need not contain this extension.
-
-   3. Only those attributes in the AC which are allowed, according to
-      all of the AAControls extension values in all of the PKCs from the
-      AA CA to the AC issuer, may be used for authorization decisions;
-      all other attributes MUST be ignored.  This check MUST be applied
-      to the set of attributes following attribute decryption, and the
-      id-aca-encAttrs type MUST also be checked.
-
-      name           id-pe-aaControls
-      OID            { id-pe 6 }
-      syntax         AAControls
-      criticality    MAY be TRUE
-
-8. Security Considerations
-
-   The protection afforded for private keys is a critical factor in
-   maintaining security.  Failure of AC issuers to protect their private
-   keys will permit an attacker to masquerade as them, potentially
-   generating false ACs or revocation status.  Existence of bogus ACs
-   and revocation status will undermine confidence in the system.  If
-   the compromise is detected, all ACs issued by the AC issuer MUST be
-   revoked.  Rebuilding after such a compromise will be problematic, so
-   AC issuers are advised to implement a combination of strong technical
-   measures (e.g., tamper-resistant cryptographic modules) and
-   appropriate management procedures (e.g., separation of duties) to
-   avoid such an incident.
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 30]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   Loss of an AC issuer's private signing key may also be problematic.
-   The AC issuer would not be able to produce revocation status or
-   perform AC renewal.  AC issuers are advised to maintain secure backup
-   for signing keys.  The security of the key backup procedures is a
-   critical factor in avoiding key compromise.
-
-   The availability and freshness of revocation status will affect the
-   degree of assurance that should be placed in a long-lived AC.  While
-   long-lived ACs expire naturally, events may occur during its natural
-   lifetime which negate the binding between the AC holder and the
-   attributes.  If revocation status is untimely or unavailable, the
-   assurance associated with the binding is clearly reduced.
-
-   The binding between an AC holder and attributes cannot be stronger
-   than the cryptographic module implementation and algorithms used to
-   generate the signature.  Short key lengths or weak hash algorithms
-   will limit the utility of an AC.  AC issuers are encouraged to note
-   advances in cryptology so they can employ strong cryptographic
-   techniques.
-
-   Inconsistent application of name comparison rules may result in
-   acceptance of invalid targeted or proxied ACs, or rejection of valid
-   ones.  The X.500 series of specifications defines rules for comparing
-   distinguished names.  These rules require comparison of strings
-   without regard to case, character set, multi-character white space
-   substrings, or leading and trailing white space.  This specification
-   and [PKIXPROF] relaxes these requirements, requiring support for
-   binary comparison at a minimum.
-
-   AC issuers MUST encode the distinguished name in the AC
-   holder.entityName field identically to the distinguished name in the
-   holder's PKC.  If different encodings are used, implementations of
-   this specification may fail to recognize that the AC and PKC belong
-   to the same entity.
-
-   If an attribute certificate is tied to the holder's PKC using the
-   baseCertificateID component of the Holder field and the PKI in use
-   includes a rogue CA with the same issuer name specified in the
-   baseCertificateID component, this rogue CA could issue a PKC to a
-   malicious party, using the same issuer name and serial number as the
-   proper holder's PKC.  Then the malicious party could use this PKC in
-   conjunction with the AC.  This scenario SHOULD be avoided by properly
-   managing and configuring the PKI so that there cannot be two CAs with
-   the same name.  Another alternative is to tie ACs to PKCs using the
-   publicKeyCert type in the ObjectDigestInfo field.  Failing this, AC
-   verifiers have to establish (using other means) that the potential
-   collisions cannot actually occur, for example, the CPSs of the CAs
-   involved may make it clear that no such name collisions can occur.
-
-
-
-Farrell & Housley           Standards Track                    [Page 31]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   Implementers MUST ensure that following validation of an AC, only
-   attributes that the issuer is trusted to issue are used in
-   authorization decisions.  Other attributes, which MAY be present MUST
-   be ignored.  Given that the AA controls PKC extension is optional to
-   implement, AC verifiers MUST be provided with this information by
-   other means.  Configuration information is a likely alternative
-   means.  This becomes very important if an AC verifier trusts more
-   than one AC issuer.
-
-   There is often a requirement to map between the authentication
-   supplied by a particular security protocol (e.g. TLS, S/MIME) and the
-   AC holder's identity.  If the authentication uses PKCs, then this
-   mapping is straightforward.  However, it is envisaged that ACs will
-   also be used in environments where the holder may be authenticated
-   using other means.  Implementers SHOULD be very careful in mapping
-   the authenticated identity to the AC holder.
-
-9. IANA Considerations
-
-   Attributes and attribute certificate extensions are identified by
-   object identifiers (OIDs).  Many of the OIDs used in this document
-   are copied from X.509 [X.509-2000].  Other OIDs were assigned from an
-   arc delegated by the IANA.  No further action by the IANA is
-   necessary for this document or any anticipated updates.
-
-10. References
-
-   [CMC]        Myers, M., Liu, X., Schaad, J. and J. Weinstein,
-                "Certificate Management Messages over CMS", RFC 2797,
-                April 2000.
-
-   [CMP]        Adams, C. and S. Farrell, "Internet X.509 Public Key
-                Infrastructure - Certificate Management Protocols", RFC
-                2510, March 1999.
-
-   [CMS]        Housley, R., "Cryptographic Message Syntax", RFC 2630,
-                June 1999.
-
-   [ESS]        Hoffman, P., "Enhanced Security Services for S/MIME",
-                RFC 2634, June 1999.
-
-   [KRB]        Kohl, J. and C. Neuman, "The Kerberos Network
-                Authentication Service (V5)", RFC 1510, September 1993.
-
-   [LDAP]       Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
-                Access Protocol (v3)", RFC 2251, December 1997.
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 32]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   [OCSP]       Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
-                Adams, "X.509 Internet Public Key Infrastructure -
-                Online Certificate Status Protocol - OCSP", RFC 2560,
-                June 1999.
-
-   [PKIXALGS]   Bassham, L., Polk, W. and R. Housley, "Algorithms and
-                Identifiers for the Internet X.509 Public Key
-                Infrastructure Certificate and Certificate Revocation
-                Lists CRL Profile", RFC 3279, April 2002.
-
-   [PKIXPROF]   Housley, R., Polk, T, Ford, W. and Solo, D., "Internet
-                X.509 Public Key Infrastructure Certificate and
-                Certificate Revocation List (CRL) Profile", RFC 3280,
-                April 2002.
-
-   [RFC2026]    Bradner, S., "The Internet Standards Process -- Revision
-                3", BCP 9, RFC 2026, October 1996.
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [URL]        Berners-Lee, T., Masinter L. and M. McCahill, "Uniform
-                Resource Locators (URL)", RFC 1738, December 1994.
-
-   [X.208-1988] CCITT Recommendation X.208: Specification of Abstract
-                Syntax Notation One (ASN.1). 1988.
-
-   [X.209-88]   CCITT Recommendation X.209: Specification of Basic
-                Encoding Rules for Abstract Syntax Notation One (ASN.1).
-                1988.
-
-   [X.501-88]   CCITT Recommendation X.501: The Directory - Models.
-                1988.
-
-   [X.501-1993] ITU-T Recommendation X.501 : Information Technology -
-                Open Systems Interconnection - The Directory: Models,
-                1993.
-
-   [X.509-1988] CCITT Recommendation X.509: The Directory -
-                Authentication Framework.  1988.
-
-   [X.509-1997] ITU-T Recommendation X.509: The Directory -
-                Authentication Framework.  1997.
-
-   [X.509-2000] ITU-T Recommendation X.509: The Directory - Public-Key
-                and Attribute Certificate Frameworks.  2000
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 33]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-Appendix A: Object Identifiers
-
-   This (normative) appendix lists the new object identifiers which are
-   defined in this specification.  Some of these are required only for
-   support of optional features and are not required for conformance to
-   this profile.  This specification mandates support for OIDs which
-   have arc elements with values that are less than 2^32, (i.e. they
-   MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less
-   than 2^31 (i.e. less than or equal to 2,147,483,647).  This allows
-   each arc element to be represented within a single 32 bit word.
-   Implementations MUST also support OIDs where the length of the dotted
-   decimal (see [LDAP], section 4.1.2) string representation can be up
-   to 100 bytes (inclusive).  Implementations MUST be able to handle
-   OIDs with up to 20 elements (inclusive).  AA's SHOULD NOT issue ACs
-   which contain OIDs that breach these requirements.
-
-   The following OIDs are imported from [PKIXPROF]:
-
-      id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
-                dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
-      id-mod  OBJECT IDENTIFIER ::= { id-pkix 0 }
-      id-pe   OBJECT IDENTIFIER ::= { id-pkix 1 }
-      id-ad   OBJECT IDENTIFIER ::= { id-pkix 48 }
-      id-at   OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
-      id-ce   OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
-
-   The following new ASN.1 module OID is defined:
-
-      id-mod-attribute-cert        OBJECT IDENTIFIER ::= { id-mod 12 }
-
-   The following AC extension OIDs are defined:
-
-      id-pe-ac-auditIdentity       OBJECT IDENTIFIER ::= { id-pe 4 }
-      id-pe-ac-proxying            OBJECT IDENTIFIER ::= { id-pe 10 }
-      id-ce-targetInformation      OBJECT IDENTIFIER ::= { id-ce 55 }
-
-   The following PKC extension OIDs are defined:
-
-      id-pe-aaControls             OBJECT IDENTIFIER ::= { id-pe 6 }
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 34]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-   The following attribute OIDs are defined:
-
-      id-aca                       OBJECT IDENTIFIER ::= { id-pkix 10 }
-      id-aca-authenticationInfo    OBJECT IDENTIFIER ::= { id-aca 1 }
-      id-aca-accessIdentity        OBJECT IDENTIFIER ::= { id-aca 2 }
-      id-aca-chargingIdentity      OBJECT IDENTIFIER ::= { id-aca 3 }
-      id-aca-group                 OBJECT IDENTIFIER ::= { id-aca 4 }
-      id-aca-encAttrs              OBJECT IDENTIFIER ::= { id-aca 6 }
-      id-at-role                   OBJECT IDENTIFIER ::= { id-at 72 }
-      id-at-clearance              OBJECT IDENTIFIER ::=
-                  { joint-iso-ccitt(2) ds(5) module(1)
-                    selected-attribute-types(5) clearance (55) }
-
-Appendix B: ASN.1 Module
-
-   PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
-                internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-                id-mod-attribute-cert(12)}
-
-      DEFINITIONS IMPLICIT TAGS ::=
-
-      BEGIN
-
-      -- EXPORTS ALL --
-
-      IMPORTS
-
-            -- IMPORTed module OIDs MAY change if [PKIXPROF] changes
-            -- PKIX Certificate Extensions
-               Attribute, AlgorithmIdentifier, CertificateSerialNumber,
-               Extensions, UniqueIdentifier,
-               id-pkix, id-pe, id-kp, id-ad, id-at
-               FROM PKIX1Explicit88 {iso(1) identified-organization(3)
-                        dod(6) internet(1) security(5) mechanisms(5)
-                        pkix(7) id-mod(0) id-pkix1-explicit-88(1)}
-
-               GeneralName, GeneralNames, id-ce
-               FROM PKIX1Implicit88 {iso(1) identified-organization(3)
-                        dod(6) internet(1) security(5) mechanisms(5)
-                        pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ;
-
-      id-pe-ac-auditIdentity       OBJECT IDENTIFIER ::= { id-pe 4 }
-      id-pe-aaControls             OBJECT IDENTIFIER ::= { id-pe 6 }
-      id-pe-ac-proxying            OBJECT IDENTIFIER ::= { id-pe 10 }
-      id-ce-targetInformation      OBJECT IDENTIFIER ::= { id-ce 55 }
-
-      id-aca                       OBJECT IDENTIFIER ::= { id-pkix 10 }
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 35]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-      id-aca-authenticationInfo    OBJECT IDENTIFIER ::= { id-aca 1 }
-      id-aca-accessIdentity        OBJECT IDENTIFIER ::= { id-aca 2 }
-      id-aca-chargingIdentity      OBJECT IDENTIFIER ::= { id-aca 3 }
-      id-aca-group                 OBJECT IDENTIFIER ::= { id-aca 4 }
-      -- { id-aca 5 } is reserved
-      id-aca-encAttrs              OBJECT IDENTIFIER ::= { id-aca 6 }
-
-      id-at-role                   OBJECT IDENTIFIER ::= { id-at 72}
-      id-at-clearance              OBJECT IDENTIFIER ::=
-                  { joint-iso-ccitt(2) ds(5) module(1)
-                    selected-attribute-types(5) clearance (55) }
-
-             -- Uncomment this if using a 1988 level ASN.1 compiler
-             -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-
-             AttributeCertificate ::= SEQUENCE {
-                   acinfo               AttributeCertificateInfo,
-                   signatureAlgorithm   AlgorithmIdentifier,
-                   signatureValue       BIT STRING
-             }
-
-             AttributeCertificateInfo ::= SEQUENCE {
-                version        AttCertVersion  -- version is v2,
-                holder         Holder,
-                issuer         AttCertIssuer,
-                signature      AlgorithmIdentifier,
-                serialNumber   CertificateSerialNumber,
-                attrCertValidityPeriod   AttCertValidityPeriod,
-                attributes     SEQUENCE OF Attribute,
-                issuerUniqueID UniqueIdentifier OPTIONAL,
-                extensions     Extensions     OPTIONAL
-             }
-
-             AttCertVersion ::= INTEGER { v2(1) }
-
-             Holder ::= SEQUENCE {
-                   baseCertificateID   [0] IssuerSerial OPTIONAL,
-                             -- the issuer and serial number of
-                             -- the holder's Public Key Certificate
-                   entityName          [1] GeneralNames OPTIONAL,
-                             -- the name of the claimant or role
-                   objectDigestInfo    [2] ObjectDigestInfo OPTIONAL
-                             -- used to directly authenticate the
-                             -- holder, for example, an executable
-             }
-
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 36]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-             ObjectDigestInfo    ::= SEQUENCE {
-                   digestedObjectType  ENUMERATED {
-                        publicKey            (0),
-                        publicKeyCert        (1),
-                        otherObjectTypes     (2) },
-                                -- otherObjectTypes MUST NOT
-                                -- MUST NOT be used in this profile
-                   otherObjectTypeID   OBJECT IDENTIFIER  OPTIONAL,
-                   digestAlgorithm     AlgorithmIdentifier,
-                   objectDigest        BIT STRING
-             }
-
-             AttCertIssuer ::= CHOICE {
-                   v1Form   GeneralNames,  -- MUST NOT be used in this
-                                           -- profile
-                   v2Form   [0] V2Form     -- v2 only
-             }
-
-             V2Form ::= SEQUENCE {
-                   issuerName            GeneralNames  OPTIONAL,
-                   baseCertificateID     [0] IssuerSerial  OPTIONAL,
-                   objectDigestInfo      [1] ObjectDigestInfo  OPTIONAL
-                      -- issuerName MUST be present in this profile
-                      -- baseCertificateID and objectDigestInfo MUST
-                      -- NOT be present in this profile
-             }
-
-             IssuerSerial  ::=  SEQUENCE {
-                   issuer         GeneralNames,
-                   serial         CertificateSerialNumber,
-                   issuerUID      UniqueIdentifier OPTIONAL
-             }
-
-             AttCertValidityPeriod  ::= SEQUENCE {
-                   notBeforeTime  GeneralizedTime,
-                   notAfterTime   GeneralizedTime
-             }
-
-             Targets ::= SEQUENCE OF Target
-
-             Target  ::= CHOICE {
-                   targetName     [0] GeneralName,
-                   targetGroup    [1] GeneralName,
-                   targetCert     [2] TargetCert
-             }
-
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 37]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-             TargetCert  ::= SEQUENCE {
-                   targetCertificate  IssuerSerial,
-                   targetName         GeneralName OPTIONAL,
-                   certDigestInfo     ObjectDigestInfo OPTIONAL
-             }
-
-             IetfAttrSyntax ::= SEQUENCE {
-                  policyAuthority[0] GeneralNames    OPTIONAL,
-                  values         SEQUENCE OF CHOICE {
-                                 octets    OCTET STRING,
-                                 oid       OBJECT IDENTIFIER,
-                                 string    UTF8String
-                 }
-             }
-
-             SvceAuthInfo ::=    SEQUENCE {
-                   service       GeneralName,
-                   ident         GeneralName,
-                   authInfo      OCTET STRING OPTIONAL
-             }
-
-             RoleSyntax ::= SEQUENCE {
-                   roleAuthority  [0] GeneralNames OPTIONAL,
-                   roleName       [1] GeneralName
-             }
-
-             Clearance  ::=  SEQUENCE {
-                   policyId       [0] OBJECT IDENTIFIER,
-                   classList      [1] ClassList DEFAULT {unclassified},
-                   securityCategories
-                                  [2] SET OF SecurityCategory  OPTIONAL
-             }
-
-             ClassList  ::=  BIT STRING {
-                   unmarked       (0),
-                   unclassified   (1),
-                   restricted     (2),
-                   confidential   (3),
-                   secret         (4),
-                   topSecret      (5)
-             }
-
-             SecurityCategory ::= SEQUENCE {
-                   type      [0]  IMPLICIT OBJECT IDENTIFIER,
-                   value     [1]  ANY DEFINED BY type
-             }
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 38]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-             AAControls ::= SEQUENCE {
-                   pathLenConstraint INTEGER (0..MAX) OPTIONAL,
-                   permittedAttrs    [0] AttrSpec OPTIONAL,
-                   excludedAttrs     [1] AttrSpec OPTIONAL,
-                   permitUnSpecified BOOLEAN DEFAULT TRUE
-             }
-
-             AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
-
-             ACClearAttrs ::= SEQUENCE {
-                   acIssuer          GeneralName,
-                   acSerial          INTEGER,
-                   attrs             SEQUENCE OF Attribute
-             }
-
-             ProxyInfo ::= SEQUENCE OF Targets
-
-      END
-
-Author's Addresses
-
-   Stephen Farrell
-   Baltimore Technologies
-   39/41 Parkgate Street
-   Dublin 8
-   IRELAND
-
-   EMail: stephen.farrell@baltimore.ie
-
-   Russell Housley
-   RSA Laboratories
-   918 Spring Knoll Drive
-   Herndon, VA 20170
-   USA
-
-   EMail: rhousley@rsasecurity.com
-
-Acknowledgements
-
-   Russ Housley thanks the management at SPYRUS, who supported the
-   development of this specification while he was employed at SPYRUS.
-   Russ Housley also thanks the management at RSA Laboratories, who
-   supported the completion of the specification after a job change.
-
-
-
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 39]
-
-RFC 3281           An Internet Attribute Certificate          April 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell & Housley           Standards Track                    [Page 40]
-
diff --git a/doc/standardisation/rfc3820.txt b/doc/standardisation/rfc3820.txt
deleted file mode 100644
index f4e60737f..000000000
--- a/doc/standardisation/rfc3820.txt
+++ /dev/null
@@ -1,2075 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          S. Tuecke
-Request for Comments: 3820                                           ANL
-Category: Standards Track                                       V. Welch
-                                                                    NCSA
-                                                               D. Engert
-                                                                     ANL
-                                                             L. Pearlman
-                                                                 USC/ISI
-                                                             M. Thompson
-                                                                    LBNL
-                                                               June 2004
-
-
-            Internet X.509 Public Key Infrastructure (PKI)
-                       Proxy Certificate Profile
-
-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 (2004).
-
-Abstract
-
-   This document forms a certificate profile for Proxy Certificates,
-   based on X.509 Public Key Infrastructure (PKI) certificates as
-   defined in RFC 3280, for use in the Internet.  The term Proxy
-   Certificate is used to describe a certificate that is derived from,
-   and signed by, a normal X.509 Public Key End Entity Certificate or by
-   another Proxy Certificate for the purpose of providing restricted
-   proxying and delegation within a PKI based authentication system.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tuecke, et al.              Standards Track                     [Page 1]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Overview of Approach . . . . . . . . . . . . . . . . . . . . .  4
-       2.1.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  4
-       2.2.  Background . . . . . . . . . . . . . . . . . . . . . . .  5
-       2.3.  Motivation for Proxying. . . . . . . . . . . . . . . . .  5
-       2.4.  Motivation for Restricted Proxies. . . . . . . . . . . .  7
-       2.5.  Motivation for Unique Proxy Name . . . . . . . . . . . .  8
-       2.6.  Description Of Approach. . . . . . . . . . . . . . . . .  9
-       2.7.  Features Of This Approach. . . . . . . . . . . . . . . . 10
-   3.  Certificate and Certificate Extensions Profile . . . . . . . . 12
-       3.1.  Issuer . . . . . . . . . . . . . . . . . . . . . . . . . 12
-       3.2.  Issuer Alternative Name. . . . . . . . . . . . . . . . . 12
-       3.3.  Serial Number. . . . . . . . . . . . . . . . . . . . . . 12
-       3.4.  Subject. . . . . . . . . . . . . . . . . . . . . . . . . 13
-       3.5.  Subject Alternative Name . . . . . . . . . . . . . . . . 13
-       3.6.  Key Usage and Extended Key Usage . . . . . . . . . . . . 13
-       3.7.  Basic Constraints. . . . . . . . . . . . . . . . . . . . 14
-       3.8.  The ProxyCertInfo Extension. . . . . . . . . . . . . . . 14
-   4.  Proxy Certificate Path Validation. . . . . . . . . . . . . . . 17
-       4.1.  Basic Proxy Certificate Path Validation. . . . . . . . . 19
-       4.2.  Using the Path Validation Algorithm. . . . . . . . . . . 23
-   5.  Commentary . . . . . . . . . . . . . . . . . . . . . . . . . . 24
-       5.1.  Relationship to Attribute Certificates . . . . . . . . . 24
-       5.2.  Kerberos 5 Tickets . . . . . . . . . . . . . . . . . . . 28
-       5.3.  Examples of usage of Proxy Restrictions. . . . . . . . . 28
-       5.4.  Delegation Tracing . . . . . . . . . . . . . . . . . . . 29
-   6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 30
-       6.1.  Compromise of a Proxy Certificate. . . . . . . . . . . . 30
-       6.2.  Restricting Proxy Certificates . . . . . . . . . . . . . 31
-       6.3.  Relying Party Trust of Proxy Certificates. . . . . . . . 31
-       6.4.  Protecting Against Denial of Service with Key Generation 32
-       6.5.  Use of Proxy Certificates in a Central Repository. . . . 32
-   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 33
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
-       8.1.  Normative References . . . . . . . . . . . . . . . . . . 33
-       8.2.  Informative References . . . . . . . . . . . . . . . . . 33
-   9.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 34
-   Appendix A. 1988 ASN.1 Module. . . . . . . . . . . . . . . . . . . 35
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
-   Full Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . 37
-
-
-
-
-
-
-
-
-
-Tuecke, et al.              Standards Track                     [Page 2]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-1.  Introduction
-
-   Use of a proxy credential [i7] is a common technique used in security
-   systems to allow entity A to grant to another entity B the right for
-   B to be authorized with others as if it were A.  In other words,
-   entity B is acting as a proxy on behalf of entity A.  This document
-   forms a certificate profile for Proxy Certificates, based on the RFC
-   3280, "Internet X.509 Public Key Infrastructure Certificate and CRL
-   Profile" [n2].
-
-   In addition to simple, unrestricted proxying, this profile defines:
-
-   *  A framework for carrying policies in Proxy Certificates that
-      allows proxying to be limited (perhaps completely disallowed)
-      through either restrictions or enumeration of rights.
-
-   *  Proxy Certificates with unique names, derived from the name of the
-      end entity certificate name.  This allows the Proxy Certificates
-      to be used in conjunction with attribute assertion approaches such
-      as Attribute Certificates [i3] and have their own rights
-      independent of their issuer.
-
-   Section 2 provides a non-normative overview of the approach.  It
-   begins by defining terminology, motivating Proxy Certificates, and
-   giving a brief overview of the approach.  It then introduces the
-   notion of a Proxy Issuer, as distinct from a Certificate Authority,
-   to describe how end entity signing of a Proxy Certificate is
-   different from end entity signing of another end entity certificate,
-   and therefore why this approach does not violate the end entity
-   signing restrictions contained in the X.509 keyCertSign field of the
-   keyUsage extension.  It then continues with discussions of how
-   subject names are used by this proxying approach, and features of
-   this approach.
-
-   Section 3 defines requirements on information content in Proxy
-   Certificates.  This profile addresses two fields in the basic
-   certificate as well as five certificate extensions.  The certificate
-   fields are the subject and issuer fields.  The certificate extensions
-   are subject alternative name, issuer alternative name, key usage,
-   basic constraints, and extended key usage.  A new certificate
-   extension, Proxy Certificate Information, is introduced.
-
-   Section 4 defines path validation rules for Proxy Certificates.
-
-   Section 5 provides non-normative commentary on Proxy Certificates.
-
-   Section 6 discusses security considerations relating to Proxy
-   Certificates.
-
-
-
-Tuecke, et al.              Standards Track                     [Page 3]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   References, listed in Section 8, are sorted into normative and
-   information references.  Normative references, listed in Section 8.1,
-   are in the form [nXX].  Informative references, listed in Section
-   8.2, are in the form [iXX].
-
-   Section 9 contains acknowledgements.
-
-   Following Section 9, contains the Appendix, the contact information
-   for the authors, the intellectual property information, and the
-   copyright information for this document.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in BCP 14, RFC 2119 [n1].
-
-2.  Overview of Approach
-
-   This section provides non-normative commentary on Proxy Certificates.
-
-   The goal of this specification is to develop a X.509 Proxy
-   Certificate profile and to facilitate their use within Internet
-   applications for those communities wishing to make use of restricted
-   proxying and delegation within an X.509 Public Key Infrastructure
-   (PKI) authentication based system.
-
-   This section provides relevant background, motivation, an overview of
-   the approach, and related work.
-
-2.1.  Terminology
-
-   This document uses the following terms:
-
-   *  CA: A "Certification Authority", as defined by X.509 [n2]
-
-   *  EEC: An "End Entity Certificate", as defined by X.509.  That is,
-      it is an X.509 Public Key Certificate issued to an end entity,
-      such as a user or a service, by a CA.
-
-   *  PKC: An end entity "Public Key Certificate".  This is synonymous
-      with an EEC.
-
-   *  PC: A "Proxy Certificate", the profile of which is defined by this
-      document.
-
-
-
-
-
-
-
-
-Tuecke, et al.              Standards Track                     [Page 4]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   *  PI: A "Proxy Issuer" is an entity with an End Entity Certificate
-      or Proxy Certificate that issues a Proxy Certificate.  The Proxy
-      Certificate is signed using the private key associated with the
-      public key in the Proxy Issuer's certificate.
-
-   *  AC: An "Attribute Certificate", as defined by "An Internet
-      Attribute Certificate Profile for Authorization" [i3].
-
-   *  AA: An "Attribute Authority", as defined in [i3].
-
-2.2.  Background
-
-   Computational and Data "Grids" have emerged as a common approach to
-   constructing dynamic, inter-domain, distributed computing
-   environments.  As explained in [i5], large research and development
-   efforts starting around 1995 have focused on the question of what
-   protocols, services, and APIs are required for effective, coordinated
-   use of resources in these Grid environments.
-
-   In 1997, the Globus Project (www.globus.org) introduced the Grid
-   Security Infrastructure (GSI) [i4].  This library provides for public
-   key based authentication and message protection, based on standard
-   X.509 certificates and public key infrastructure, the SSL/TLS
-   protocol [i2], and delegation using proxy certificates similar to
-   those profiled in this document.  GSI has been used, in turn, to
-   build numerous middleware libraries and applications, which have been
-   deployed in large-scale production and experimental Grids [i1].  GSI
-   has emerged as the dominant security solution used by Grid efforts
-   worldwide.
-
-   This experience with GSI has proven the viability of restricted
-   proxying as a basis for authorization within Grids, and has further
-   proven the viability of using X.509 Proxy Certificates, as defined in
-   this document, as the basis for that proxying.  This document is one
-   part of an effort to migrate this experience with GSI into standards,
-   and in the process clean up the approach and better reconcile it with
-   existing and recent standards.
-
-2.3.  Motivation for Proxying
-
-   A motivating example will assist in understanding the role proxying
-   can play in building Internet based applications.
-
-   Steve is an engineer who wants to use a reliable file transfer
-   service to manage the movement of a number of large files around
-   between various hosts on his company's Intranet-based Grid.  From his
-   laptop he wants to submit a number of transfer requests to the
-   service and have the files transferred while he is doing other
-
-
-
-Tuecke, et al.              Standards Track                     [Page 5]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   things, including being offline.  The transfer service may queue the
-   requests for some time (e.g., until after hours or a period of low
-   resource usage) before initiating the transfers.  The transfer
-   service will then, for each file, connect to each of the source and
-   destination hosts, and instruct them to initiate a data connection
-   directly from the source to the destination in order to transfer the
-   file.  Steve will leave an agent running on his laptop that will
-   periodically check on progress of the transfer by contacting the
-   transfer service.  Of course, he wants all of this to happen securely
-   on his company's resources, which requires that he initiate all of
-   this using his PKI smartcard.
-
-   This scenario requires authentication and delegation in a variety of
-   places:
-
-   *  Steve needs to be able to mutually authenticate with the reliable
-      file transfer service to submit the transfer request.
-
-   *  Since the storage hosts know nothing about the file transfer
-      service, the file transfer service needs to be delegated the
-      rights to mutually authenticate with the various storage hosts
-      involved directly in the file transfer, in order to initiate the
-      file transfer.
-
-   *  The source and destination hosts of a particular transfer must be
-      able to mutual authenticate with each other, to ensure the file is
-      being transferred to and from the proper parties.
-
-   *  The agent running on Steve's laptop must mutually authenticate
-      with the file transfer service in order to check the result of the
-      transfers.
-
-   Proxying is a viable approach to solving two (related) problems in
-   this scenario:
-
-   *  Single sign-on: Steve wants to enter his smartcard password (or
-      pin) once, and then run a program that will submit all the file
-      transfer requests to the transfer service, and then periodically
-      check on the status of the transfer.  This program needs to be
-      given the rights to be able to perform all of these operations
-      securely, without requiring repeated access to the smartcard or
-      Steve's password.
-
-   *  Delegation: Various remote processes in this scenario need to
-      perform secure operations on Steve's behalf, and therefore must be
-      delegated the necessary rights.  For example, the file transfer
-
-
-
-
-
-Tuecke, et al.              Standards Track                     [Page 6]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-      service needs to be able to authenticate on Steve's behalf with
-      the source and destination hosts, and must in turn delegate rights
-      to those hosts so that they can authenticate with each other.
-
-   Proxying can be used to secure all of these interactions:
-
-   *  Proxying allows for the private key stored on the smartcard to be
-      accessed just once, in order to create the necessary proxy
-      credential, which allows the client/agent program to be authorized
-      as Steve when submitting the requests to the transfer service.
-      Access to the smartcard and Steve's password is not required after
-      the initial creation of the proxy credential.
-
-   *  The client program on the laptop can delegate to the file transfer
-      service the right to act on Steve's behalf.  This, in turn, allows
-      the service to authenticate to the storage hosts and inherit
-      Steve's privileges in order to start the file transfers.
-
-   *  When the transfer service authenticates to hosts to start the file
-      transfer, the service can delegate to the hosts the right to act
-      on Steve's behalf so that each pair of hosts involved in a file
-      transfer can mutually authenticate to ensure the file is securely
-      transferred.
-
-   *  When the agent on the laptop reconnects to the file transfer
-      service to check on the status of the transfer, it can perform
-      mutual authentication.  The laptop may use a newly generated proxy
-      credential, which is just created anew using the smartcard.
-
-   This scenario, and others similar to it, is being built today within
-   the Grid community.  The Grid Security Infrastructure's single sign-
-   on and delegation capabilities, built on X.509 Proxy Certificates,
-   are being employed to provide authentication services to these
-   applications.
-
-2.4.  Motivation for Restricted Proxies
-
-   One concern that arises is what happens if a machine that has been
-   delegated the right to inherit Steve's privileges has been
-   compromised?  For example, in the above scenario, what if the machine
-   running the file transfer service is compromised, such that the
-   attacker can gain access to the credential that Steve delegated to
-   that service?  Can the attacker now do everything that Steve is
-   allowed to do?
-
-   A solution to this problem is to allow for restrictions to be placed
-   on the proxy by means of policies on the proxy certificates. For
-   example, the machine running the reliable file transfer service in
-
-
-
-Tuecke, et al.              Standards Track                     [Page 7]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   the above example might only be given Steve's right for the purpose
-   of reading the source files and writing the destination files.
-   Therefore, if that file transfer service is compromised, the attacker
-   cannot modify source files, cannot create or modify other files to
-   which Steve has access, cannot start jobs on behalf of Steve, etc.
-   All that an attacker would be able to do is read the specific files
-   to which the file transfer service has been delegated read access,
-   and write bogus files in place of those that the file transfer
-   service has been delegated write access. Further, by limiting the
-   lifetime of the credential that is delegated to the file transfer
-   service, the effects of a compromise can be further mitigated.
-
-   Other potential uses for restricted proxy credentials are discussed
-   in [i7].
-
-2.5.  Motivation for Unique Proxy Name
-
-   The dynamic creation of entities (e.g., processes and services) is an
-   essential part of Grid computing.  These entities will require rights
-   in order to securely perform their function.  While it is possible to
-   obtain rights solely through proxying as described in previous
-   sections, this has limitations.  For example what if an entity should
-   have rights that are granted not just from the proxy issuer but from
-   a third party as well?  While it is possible in this case for the
-   entity to obtain and hold two proxy certifications, in practice it is
-   simpler for subsequent credentials to take the form of attribute
-   certificates.
-
-   It is also desirable for these entities to have a unique identity so
-   that they can be explicitly discussed in policy statements.  For
-   example, a user initiating a third-party FTP transfer could grant
-   each FTP server a PC with a unique identity and inform each server of
-   the identity of the other, then when the two servers connected they
-   could authenticate themselves and know they are connected to the
-   proper party.
-
-   In order for a party to have rights of it's own it requires a unique
-   identity.  Possible options for obtaining an unique identity are:
-
-   1) Obtain an identity from a traditional Certification Authority
-      (CA).
-
-   2) Obtain a new identity independently - for example by using the
-      generated public key and a self-signed certificate.
-
-   3) Derive the new identity from an existing identity.
-
-
-
-
-
-Tuecke, et al.              Standards Track                     [Page 8]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   In this document we describe an approach to option #3, because:
-
-      *  It is reasonably light-weight, as it can be done without
-         interacting with a third party.  This is important when
-         creating identities dynamically.
-
-      *  As described in the previous section, a common use for PCs is
-         for restricted proxying, so deriving their identity from the
-         identity of the EEC makes this straightforward.  Nonetheless
-         there are circumstances where the creator does not wish to
-         delegate all or any of its rights to a new entity.  Since the
-         name is unique, this is easily accomplished by #3 as well, by
-         allowing the application of a policy to limit proxying.
-
-2.6.  Description Of Approach
-
-   This document defines an X.509 "Proxy Certificate" or "PC" as a means
-   of providing for restricted proxying within an (extended) X.509 PKI
-   based authentication system.
-
-   A Proxy Certificate is an X.509 public key certificate with the
-   following properties:
-
-   1) It is signed by either an X.509 End Entity Certificate (EEC), or
-      by another PC.  This EEC or PC is referred to as the Proxy Issuer
-      (PI).
-
-   2) It can sign only another PC.  It cannot sign an EEC.
-
-   3) It has its own public and private key pair, distinct from any
-      other EEC or PC.
-
-   4) It has an identity derived from the identity of the EEC that
-      signed the PC.  When a PC is used for authentication, in may
-      inherit rights of the EEC that signed the PC, subject to the
-      restrictions that are placed on that PC by the EEC.
-
-   5) Although its identity is derived from the EEC's identity, it is
-      also unique.  This allows this identity to be used for
-      authorization as an independent identity from the identity of the
-      issuing EEC, for example in conjunction with attribute assertions
-      as defined in [i3].
-
-   6) It contains a new X.509 extension to identify it as a PC and to
-      place policies on the use of the PC.  This new extension, along
-      with other X.509 fields and extensions, are used to enable proper
-      path validation and use of the PC.
-
-
-
-
-Tuecke, et al.              Standards Track                     [Page 9]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   The process of creating a PC is as follows:
-
-   1) A new public and private key pair is generated.
-
-   2) That key pair is used to create a request for a Proxy Certificate
-      that conforms to the profile described in this document.
-
-   3) A Proxy Certificate, signed by the private key of the EEC or by
-      another PC, is created in response to the request.  During this
-      process, the PC request is verified to ensure that the requested
-      PC is valid (e.g., it is not an EEC, the PC fields are
-      appropriately set, etc).
-
-   When a PC is created as part of a delegation from entity A to entity
-   B, this process is modified by performing steps #1 and #2 within
-   entity B, then passing the PC request from entity B to entity A over
-   an authenticated, integrity checked channel, then entity A performs
-   step #3 and passes the PC back to entity B.
-
-   Path validation of a PC is very similar to normal path validation,
-   with a few additional checks to ensure, for example, proper PC
-   signing constraints.
-
-2.7.  Features Of This Approach
-
-   Using Proxy Certificates to perform delegation has several features
-   that make it attractive:
-
-   *  Ease of integration
-
-      o  Because a PC requires only a minimal change to path validation,
-         it is very easy to incorporate support for Proxy Certificates
-         into existing X.509 based software.  For example, SSL/TLS
-         requires no protocol changes to support authentication using a
-         PC.  Further, an SSL/TLS implementation requires only minor
-         changes to support PC path validation, and to retrieve the
-         authenticated subject of the signing EEC instead of the subject
-         of the PC for authorization purposes.
-
-      o  Many existing authorization systems use the X.509 subject name
-         as the basis for access control.  Proxy Certificates can be
-         used with such authorization systems without modification,
-         since such a PC inherits its name and rights from the EEC that
-         signed it and the EEC name can be used in place of the PC name
-         for authorization decisions.
-
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 10]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   *  Ease of use
-
-      o  Using PC for single sign-on helps make X.509 PKI authentication
-         easier to use, by allowing users to "login" once and then
-         perform various operations securely.
-
-      o  For many users, properly managing their own EEC private key is
-         a nuisance at best, and a security risk at worst.  One option
-         easily enabled with a PC is to manage the EEC private keys and
-         certificates in a centrally managed repository. When a user
-         needs a PKI credential, the user can login to the repository
-         using name/password, one time password, etc.  Then the
-         repository can delegate a PC to the user with proxy rights, but
-         continue to protect the EEC private key in the repository.
-
-   *  Protection of private keys
-
-      o  By using the remote delegation approach outlined above, entity
-         A can delegate a PC to entity B, without entity B ever seeing
-         the private key of entity A, and without entity A ever seeing
-         the private key of the newly delegated PC held by entity B.  In
-         other words, private keys never need to be shared or
-         communicated by the entities participating in a delegation of a
-         PC.
-
-      o  When implementing single sign-on, using a PC helps protect the
-         private key of the EEC, because it minimizes the exposure and
-         use of that private key.  For example, when an EEC private key
-         is password protected on disk, the password and unencrypted
-         private key need only be available during the creation of the
-         PC.  That PC can then be used for the remainder of its valid
-         lifetime, without requiring access to the EEC password or
-         private key.  Similarly, when the EEC private key lives on a
-         smartcard, the smartcard need only be present in the machine
-         during the creation of the PC.
-
-   *  Limiting consequences of a compromised key
-
-      o  When creating a PC, the PI can limit the validity period of the
-         PC, the depth of the PC path that can be created by that PC,
-         and key usage of the PC and its descendents.  Further, fine-
-         grained policies can be carried by a PC to even further
-         restrict the operations that can be performed using the PC.
-         These restrictions permit the PI to limit damage that could be
-         done by the bearer of the PC, either accidentally or
-         maliciously.
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 11]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-      o  A compromised PC private key does NOT compromise the EEC
-         private key.  This makes a short term, or an otherwise
-         restricted PC attractive for day-to-day use, since a
-         compromised PC does not require the user to go through the
-         usually cumbersome and time consuming process of having the EEC
-         with a new private key reissued by the CA.
-
-   See Section 5 below for more discussion on how Proxy Certificates
-   relate to Attribute Certificates.
-
-3.  Certificate and Certificate Extensions Profile
-
-   This section defines the usage of X.509 certificate fields and
-   extensions in Proxy Certificates, and defines one new extension for
-   Proxy Certificate Information.
-
-   All Proxy Certificates MUST include the Proxy Certificate Information
-   (ProxyCertInfo) extension defined in this section and the extension
-   MUST be critical.
-
-3.1.  Issuer
-
-   The Proxy Issuer of a Proxy Certificate MUST be either an End Entity
-   Certificate, or another Proxy Certificate.
-
-   The Proxy Issuer MUST NOT have an empty subject field.
-
-   The issuer field of a Proxy Certificate MUST contain the subject
-   field of its Proxy Issuer.
-
-   If the Proxy Issuer certificate has the KeyUsage extension, the
-   Digital Signature bit MUST be asserted.
-
-3.2.  Issuer Alternative Name
-
-   The issuerAltName extension MUST NOT be present in a Proxy
-   Certificate.
-
-3.3.  Serial Number
-
-   The serial number of a Proxy Certificate (PC) SHOULD be unique
-   amongst all Proxy Certificates issued by a particular Proxy Issuer.
-   However, a Proxy Issuer MAY use an approach to assigning serial
-   numbers that merely ensures a high probability of uniqueness.
-
-
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 12]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   For example, a Proxy Issuer MAY use a sequentially assigned integer
-   or a UUID to assign a unique serial number to a PC it issues.  Or a
-   Proxy Issuer MAY use a SHA-1 hash of the PC public key to assign a
-   serial number with a high probability of uniqueness.
-
-3.4.  Subject
-
-   The subject field of a Proxy Certificate MUST be the issuer field
-   (that is the subject of the Proxy Issuer) appended with a single
-   Common Name component.
-
-   The value of the Common Name SHOULD be unique to each Proxy
-   Certificate bearer amongst all Proxy Certificates with the same
-   issuer.
-
-   If a Proxy Issuer issues two proxy certificates to the same bearer,
-   the Proxy Issuer MAY choose to use the same Common Name for both.
-   Examples of this include Proxy Certificates for different uses (e.g.,
-   signing vs encryption) or the re-issuance of an expired Proxy
-   Certificate.
-
-   The Proxy Issuer MAY use an approach to assigning Common Name values
-   that merely ensures a high probability of uniqueness.  This value MAY
-   be the same value used for the serial number.
-
-   The result of this approach is that all subject names of Proxy
-   Certificates are derived from the name of the issuing EEC (it will be
-   the first part of the subject name appended with one or more CN
-   components) and are unique to each bearer.
-
-3.5.  Subject Alternative Name
-
-   The subjectAltName extension MUST NOT be present in a Proxy
-   Certificate.
-
-3.6.  Key Usage and Extended Key Usage
-
-   If the Proxy Issuer certificate has a Key Usage extension, the
-   Digital Signature bit MUST be asserted.
-
-   This document places no constraints on the presence or contents of
-   the key usage and extended key usage extension.  However, section 4.2
-   explains what functions should be allowed a proxy certificate by a
-   relying party.
-
-
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 13]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-3.7.  Basic Constraints
-
-   The cA field in the basic constraints extension MUST NOT be TRUE.
-
-3.8.  The ProxyCertInfo Extension
-
-   A new extension, ProxyCertInfo, is defined in this subsection.
-   Presence of the ProxyCertInfo extension indicates that a certificate
-   is a Proxy Certificate and whether or not the issuer of the
-   certificate has placed any restrictions on its use.
-
-   id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
-            dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
-
-   id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
-
-   id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }
-
-   ProxyCertInfo ::= SEQUENCE {
-        pCPathLenConstraint   INTEGER (0..MAX) OPTIONAL,
-        proxyPolicy           ProxyPolicy }
-
-
-   ProxyPolicy ::= SEQUENCE {
-        policyLanguage        OBJECT IDENTIFIER,
-        policy          OCTET STRING OPTIONAL }
-
-   If a certificate is a Proxy Certificate, then the proxyCertInfo
-   extension MUST be present, and this extension MUST be marked as
-   critical.
-
-   If a certificate is not a Proxy Certificate, then the proxyCertInfo
-   extension MUST be absent.
-
-   The ProxyCertInfo extension consists of one required and two optional
-   fields, which are described in detail in the following subsections.
-
-3.8.1.  pCPathLenConstraint
-
-   The pCPathLenConstraint field, if present, specifies the maximum
-   depth of the path of Proxy Certificates that can be signed by this
-   Proxy Certificate.  A pCPathLenConstraint of 0 means that this
-   certificate MUST NOT be used to sign a Proxy Certificate.  If the
-   pCPathLenConstraint field is not present then the maximum proxy path
-   length is unlimited.  End entity certificates have unlimited maximum
-   proxy path lengths.
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 14]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-3.8.2.  proxyPolicy
-
-   The proxyPolicy field specifies a policy on the use of this
-   certificate for the purposes of authorization.  Within the
-   proxyPolicy, the policy field is an expression of policy, and the
-   policyLanguage field indicates the language in which the policy is
-   expressed.
-
-   The proxyPolicy field in the proxyCertInfo extension does not define
-   a policy language to be used for proxy restrictions; rather, it
-   places the burden on those parties using that extension to define an
-   appropriate language, and to acquire an OID for that language (or to
-   select an appropriate previously-defined language/OID).  Because it
-   is essential for the PI that issues a certificate with a proxyPolicy
-   field and the relying party that interprets that field to agree on
-   its meaning, the policy language OID must correspond to a policy
-   language (including semantics), not just a policy grammar.
-
-   The policyLanguage field has two values of special importance,
-   defined in Appendix A, that MUST be understood by all parties
-   accepting Proxy Certificates:
-
-   *  id-ppl-inheritAll indicates that this is an unrestricted proxy
-      that inherits all rights from the issuing PI.  An unrestricted
-      proxy is a statement that the Proxy Issuer wishes to delegate all
-      of its authority to the bearer (i.e., to anyone who has that proxy
-      certificate and can prove possession of the associated private
-      key).  For purposes of authorization, this an unrestricted proxy
-      effectively impersonates the issuing PI.
-
-   *  id-ppl-independent indicates that this is an independent proxy
-      that inherits no rights from the issuing PI.  This PC MUST be
-      treated as an independent identity by relying parties.  The only
-      rights this PC has are those granted explicitly to it.
-
-   For either of the policyLanguage values listed above, the policy
-   field MUST NOT be present.
-
-   Other values for the policyLanguage field indicates that this is a
-   restricted proxy certification and have some other policy limiting
-   its ability to do proxying.  In this case the policy field MAY be
-   present and it MUST contain information expressing the policy.  If
-   the policy field is not present the policy MUST be implicit in the
-   value of the policyLanguage field itself.  Authors of additional
-   policy languages are encouraged to publicly document their policy
-   language and list it in the IANA registry (see Section 7).
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 15]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   Proxy policies are used to limit the amount of authority delegated,
-   for example to assert that the proxy certificate may be used only to
-   make requests to a specific server, or only to authorize specific
-   operations on specific resources.  This document is agnostic to the
-   policies that can be placed in the policy field.
-
-   Proxy policies impose additional requirements on the relying party,
-   because only the relying party is in a position to ensure that those
-   policies are enforced.  When making an authorization decision based
-   on a proxy certificate based on rights that proxy certificate
-   inherited from its issuer, it is the relying party's responsibility
-   to verify that the requested authority is compatible with all
-   policies in the PC's certificate path.  In other words, the relying
-   party MUST verify that the following three conditions are all met:
-
-   1) The relying party MUST know how to interpret the proxy policy and
-      the request is allowed under that policy.
-
-   2) If the Proxy Issuer is an EEC then the relying party's local
-      policies MUST authorize the request for the entity named in the
-      EEC.
-
-   3) If the Proxy Issuer is another PC, then one of the following MUST
-      be true:
-
-      a. The relying party's local policies authorize the Proxy Issuer
-         to perform the request.
-
-      b. The Proxy Issuer inherits the right to perform the request from
-         its issuer by means of its proxy policy.  This must be verified
-         by verifying these three conditions on the Proxy Issuer in a
-         recursive manner.
-
-   If these conditions are not met, the relying party MUST either deny
-   authorization, or ignore the PC and the whole certificate chain
-   including the EEC entirely when making its authorization decision
-   (i.e., make the same decision that it would have made had the PC and
-   it's certificate chain never been presented).
-
-   The relying party MAY impose additional restrictions as to which
-   proxy certificates it accepts.  For example, a relying party MAY
-   choose to reject all proxy certificates, or MAY choose to accept
-   proxy certificates only for certain operations, etc.
-
-   Note that since a proxy certificate has a unique identity it MAY also
-   have rights granted to it by means other than inheritance from it's
-   issuer via its proxy policy.  The rights granted to the bearer of a
-   PC are the union of the rights granted to the PC identity and the
-
-
-
-Tuecke, et al.              Standards Track                    [Page 16]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   inherited rights.  The inherited rights consist of the intersection
-   of the rights granted to the PI identity intersected with the proxy
-   policy in the PC.
-
-   For example, imagine that Steve is authorized to read and write files
-   A and B on a file server, and that he uses his EEC to create a PC
-   that includes the policy that it can be used only to read or write
-   files A and C.  Then a trusted attribute authority grants an
-   Attribute Certificate granting the PC the right to read file D. This
-   would make the rights of the PC equal to the union of the rights
-   granted to the PC identity (right to read file D) with the
-   intersection of the rights granted to Steve, the PI, (right to read
-   files A and B) with the policy in the PC (can only read files A and
-   C).  This would mean the PC would have the following rights:
-
-   *  Right to read file A: Steve has this right and he issued the PC
-      and his policy grants this right to the PC.
-
-   *  Right to read file D: This right is granted explicitly to the PC
-      by a trusted authority.
-
-   The PC would NOT have the following rights:
-
-   *  Right to read file B: Although Steve has this right, it is
-      excluded by his policy on the PC.
-
-   *  Right to read file C: Although Steve's policy grants this right,
-      he does not have this right himself.
-
-   In many cases, the relying party will not have enough information to
-   evaluate the above criteria at the time that the certificate path is
-   validated.  For example, if a certificate is used to authenticate a
-   connection to some server, that certificate is typically validated
-   during that authentication step, before any requests have been made
-   of the server.  In that case, the relying party MUST either have some
-   authorization mechanism in place that will check the proxy policies,
-   or reject any certificate that contains proxy policies (or that has a
-   parent certificate that contains proxy policies).
-
-4.  Proxy Certificate Path Validation
-
-   Proxy Certification path processing verifies the binding between the
-   proxy certificate distinguished name and proxy certificate public
-   key.  The binding is limited by constraints which are specified in
-   the certificates which comprise the path and inputs which are
-   specified by the relying party.
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 17]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   This section describes an algorithm for validating proxy
-   certification paths.  Conforming implementations of this
-   specification are not required to implement this algorithm, but MUST
-   provide functionality equivalent to the external behavior resulting
-   from this procedure.  Any algorithm may be used by a particular
-   implementation so long as it derives the correct result.
-
-   The algorithm presented in this section validates the proxy
-   certificate with respect to the current date and time.  A conformant
-   implementation MAY also support validation with respect to some point
-   in the past.  Note that mechanisms are not available for validating a
-   proxy certificate with respect to a time outside the certificate
-   validity period.
-
-   Valid paths begin with the end entity certificate (EEC) that has
-   already been validated by public key certificate validation
-   procedures in RFC 3280 [n2].  The algorithm requires the public key
-   of the EEC and the EEC's subject distinguished name.
-
-   To meet the goal of verifying the proxy certificate, the proxy
-   certificate path validation process verifies, among other things,
-   that a prospective certification path (a sequence of n certificates)
-   satisfies the following conditions:
-
-   (a) for all x in {1, ..., n-1}, the subject of certificate x is the
-       issuer of proxy certificate x+1 and the subject distinguished
-       name of certificate x+1 is a legal subject distinguished name to
-       have been issued by certificate x;
-
-   (b) certificate 1 is valid proxy certificate issued by the end entity
-       certificate whose information is given as input to the proxy
-       certificate path validation process;
-
-   (c) certificate n is the proxy certificate to be validated;
-
-   (d) for all x in {1, ..., n}, the certificate was valid at the time
-       in question; and
-
-   (e) for all certificates in the path with a pCPathLenConstraint
-       field, the number of certificates in the path following that
-       certificate does not exceed the length specified in that field.
-
-   At this point there is no mechanism defined for revoking proxy
-   certificates.
-
-
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 18]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-4.1.  Basic Proxy Certificate Path Validation
-
-   This section presents the algorithm in four basic steps to mirror the
-   description of public key certificate path validation in RFC 3280:
-   (1) initialization, (2) basic proxy certificate processing, (3)
-   preparation for the next proxy certificate, and (4) wrap-up. Steps
-   (1) and (4) are performed exactly once.  Step (2) is performed for
-   all proxy certificates in the path.  Step (3) is performed for all
-   proxy certificates in the path except the final proxy certificate.
-
-   Certificate path validation as described in RFC 3280 MUST have been
-   done prior to using this algorithm to validate the end entity
-   certificate.  This algorithm then processes the proxy certificate
-   chain using the end entity certificate information produced by RFC
-   3280 path validation.
-
-4.1.1.  Inputs
-
-   This algorithm assumes the following inputs are provided to the path
-   processing logic:
-
-   (a) information about the entity certificate already verified using
-       RFC 3280 path validation.  This information includes:
-
-      (1) the end entity name,
-
-      (2) the working_public_key output from RFC 3280 path validation,
-
-      (3) the working_public_key_algorithm output from RFC 3280,
-
-      (4) and the working_public_key_parameters output from RFC 3280
-          path validation.
-
-   (b) prospective proxy certificate path of length n.
-
-   (c) acceptable-pc-policy-language-set: A set of proxy certificate
-       policy languages understood by the policy evaluation code.  The
-       acceptable-pc-policy-language-set MAY contain the special value
-       id-ppl-anyLanguage (as defined in Appendix A) if the path
-       validation code should not check the proxy certificate policy
-       languages (typically because the set of known policy languages is
-       not known yet and will be checked later in the authorization
-       process).
-
-   (d) the current date and time.
-
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 19]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-4.1.2.  Initialization
-
-   This initialization phase establishes the following state variables
-   based upon the inputs:
-
-   (a) working_public_key_algorithm: the digital signature algorithm
-       used to verify the signature of a proxy certificate. The
-       working_public_key_algorithm is initialized from the input
-       information provided from RFC 3280 path validation.
-
-   (b) working_public_key: the public key used to verify the signature
-       of a proxy certificate.  The working_public_key is initialized
-       from the input information provided from RFC 3280 path
-       validation.
-
-   (c) working_public_key_parameters: parameters associated with the
-       current public key, that may be required to verify a signature
-       (depending upon the algorithm).  The
-       proxy_issuer_public_key_parameters variable is initialized from
-       the input information provided from RFC 3280 path validation.
-
-   (d) working_issuer_name: the issuer distinguished name expected in
-       the next proxy certificate in the chain.  The working_issuer_name
-       is initialized to the distinguished name in the end entity
-       certificate validated by RFC 3280 path validation.
-
-   (e) max_path_length: this integer is initialized to n, is decremented
-       for each proxy certificate in the path.  This value may also be
-       reduced by the pcPathLenConstraint value of any proxy certificate
-       in the chain.
-
-   (f) proxy_policy_list: this list is empty to start and will be filled
-       in with the key usage extensions, extended key usage extensions
-       and proxy policies in the chain.
-
-   Upon completion of the initialization steps, perform the basic
-   certificate processing steps specified in 4.1.3.
-
-4.1.3.  Basic Proxy Certificate Processing
-
-   The basic path processing actions to be performed for proxy
-   certificate i (for all i in [1..n]) are listed below.
-
-   (a) Verify the basic certificate information.  The certificate MUST
-       satisfy each of the following:
-
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 20]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-      (1) The certificate was signed with the
-          working_public_key_algorithm using the working_public_key and
-          the working_public_key_parameters.
-
-      (2) The certificate validity period includes the current time.
-
-      (3) The certificate issuer name is the working_issuer_name.
-
-      (4) The certificate subject name is the working_issuer_name with a
-          CN component appended.
-
-   (b) The proxy certificate MUST have a ProxyCertInfo extension.
-       Process the extension as follows:
-
-      (1) If the pCPathLenConstraint field is present in the
-          ProxyCertInfo field and the value it contains is less than
-          max_path_length, set max_path_length to its value.
-
-      (2) If acceptable-pc-policy-language-set is not id-ppl-
-          anyLanguage, the OID in the policyLanguage field MUST be
-          present in acceptable-pc-policy-language-set.
-
-   (c) The tuple containing the certificate subject name, policyPolicy,
-       key usage extension (if present) and extended key usage extension
-       (if present) must be appended to proxy_policy_list.
-
-   (d) Process other certificate extensions, as described in [n2]:
-
-      (1) Recognize and process any other critical extensions present in
-          the proxy certificate.
-
-      (2) Process any recognized non-critical extension present in the
-          proxy certificate.
-
-   If either step (a), (b) or (d) fails, the procedure terminates,
-   returning a failure indication and an appropriate reason.
-
-   If i is not equal to n, continue by performing the preparatory steps
-   listed in 4.1.4.  If i is equal to n, perform the wrap-up steps
-   listed in 4.1.5.
-
-4.1.4.  Preparation for next Proxy Certificate
-
-   (a) Verify max_path_length is greater than zero and decrement
-       max_path_length.
-
-   (b) Assign the certificate subject name to working_issuer_name.
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 21]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   (c) Assign the certificate subjectPublicKey to working_public_key.
-
-   (d) If the subjectPublicKeyInfo field of the certificate contains an
-       algorithm field with non-null parameters, assign the parameters
-       to the working_public_key_parameters variable.
-
-       If the subjectPublicKeyInfo field of the certificate contains an
-       algorithm field with null parameters or parameters are omitted,
-       compare the certificate subjectPublicKey algorithm to the
-       working_public_key_algorithm.  If the certificate
-       subjectPublicKey algorithm and the working_public_key_algorithm
-       are different, set the working_public_key_parameters to null.
-
-   (e) Assign the certificate subjectPublicKey algorithm to the
-       working_public_key_algorithm variable.
-
-   (f) If a key usage extension is present, verify that the
-       digitalSignature bit is set.
-
-   If either check (a) or (f) fails, the procedure terminates, returning
-   a failure indication and an appropriate reason.
-
-   If (a) and (f) complete successfully, increment i and perform the
-   basic certificate processing specified in 4.1.3.
-
-4.1.5.  Wrap-up Procedures
-
-   (a) Assign the certificate subject name to working_issuer_name.
-
-   (b) Assign the certificate subjectPublicKey to working_public_key.
-
-   (c) If the subjectPublicKeyInfo field of the certificate contains an
-       algorithm field with non-null parameters, assign the parameters
-       to the proxy_issuer_public_key_parameters variable.
-
-       If the subjectPublicKeyInfo field of the certificate contains an
-       algorithm field with null parameters or parameters are omitted,
-       compare the certificate subjectPublicKey algorithm to the
-       proxy_issuer_public_key_algorithm.  If the certificate
-       subjectPublicKey algorithm and the
-       proxy_issuer_public_key_algorithm are different, set the
-       proxy_issuer_public_key_parameters to null.
-
-   (d) Assign the certificate subjectPublicKey algorithm to the
-       proxy_issuer_public_key_algorithm variable.
-
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 22]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-4.1.6.  Outputs
-
-   If path processing succeeds, the procedure terminates, returning a
-   success indication together with final value of the
-   working_public_key, the working_public_key_algorithm, the
-   working_public_key_parameters, and the proxy_policy_list.
-
-4.2.  Using the Path Validation Algorithm
-
-   Each Proxy Certificate contains a ProxyCertInfo extension, which
-   always contains a policy language OID, and may also contain a policy
-   OCTET STRING.  These policies serve to indicate the desire of each
-   issuer in the proxy certificate chain, starting with the EEC, to
-   delegate some subset of their rights to the issued proxy certificate.
-   This chain of policies is returned by the algorithm to the
-   application.
-
-   The application MAY make authorization decisions based on the subject
-   distinguished name of the proxy certificate or on one of the proxy
-   certificates in it's issuing chain or on the EEC that serves as the
-   root of the chain.  If an application chooses to use the subject
-   distinguished name of a proxy certificate in the issuing chain or the
-   EEC it MUST use the returned policies to restrict the rights it
-   grants to the proxy certificate.  If the application does not know
-   how to parse any policy in the policy chain it MUST not use, for the
-   purposes of making authorization decisions, the subject distinguished
-   name of any certificate in the chain prior to the certificate in
-   which the unrecognized policy appears.
-
-   Application making authorization decisions based on the contents of
-   the proxy certificate key usage or extended key usage extensions MUST
-   examine the list of key usage, extended key usage and proxy policies
-   resulting from proxy certificate path validation and determine the
-   effective key usage functions of the proxy certificate as follows:
-
-   *  If a certificate is a proxy certificate with a proxy policy of
-      id-ppl-independent or an end entity certificate, the effective key
-      usage functions of that certificate is as defined by the key usage
-      and extended key usage extensions in that certificate.  The key
-      usage functionality of the issuer has no bearing on the effective
-      key usage functionality.
-
-   *  If a certificate is a proxy certificate with a policy other than
-      id-ppl-independent, the effective key usage and extended key usage
-      functionality of the proxy certificate is the intersection of the
-      functionality of those extensions in the proxy certificate and the
-      effective key usage functionality of the proxy issuer.
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 23]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-5.  Commentary
-
-   This section provides non-normative commentary on Proxy Certificates.
-
-5.1.  Relationship to Attribute Certificates
-
-   An Attribute Certificate [i3] can be used to grant to one identity,
-   the holder, some attribute such as a role, clearance level, or
-   alternative identity such as "charging identity" or "audit identity".
-   This is accomplished by way of a trusted Attribute Authority (AA),
-   which issues signed Attribute Certificates (AC), each of which binds
-   an identity to a particular set of attributes. Authorization
-   decisions can then be made by combining information from the
-   authenticated End Entity Certificate providing the identity, with the
-   signed Attribute Certificates providing binding of that identity to
-   attributes.
-
-   There is clearly some overlap between the capabilities provided by
-   Proxy Certificates and Attribute Certificates.  However, the
-   combination of the two approaches together provides a broader
-   spectrum of solutions to authorization in X.509 based systems, than
-   either solution alone.  This section seeks to clarify some of the
-   overlaps, differences, and synergies between Proxy Certificate and
-   Attribute Certificates.
-
-5.1.1.  Types of Attribute Authorities
-
-   For the purposes of this discussion, Attribute Authorities, and the
-   uses of the Attribute Certificates that they produce, can be broken
-   down into two broad classes:
-
-   1) End entity AA: An End Entity Certificate may be used to sign an
-      AC.  This can be used, for example, to allow an end entity to
-      delegate some of its privileges to another entity.
-
-   2) Third party AA: A separate entity, aside from the end entity
-      involved in an authenticated interaction, may sign ACs in order to
-      bind the authenticated identity with additional attributes, such
-      as role, group, etc.  For example, when a client authenticates
-      with a server, the third party AA may provide an AC that binds the
-      client identity to a particular group, which the server then uses
-      for authorization purposes.
-
-   This second type of Attribute Authority, the third party AA, works
-   equally well with an EEC or a PC.  For example, unrestricted Proxy
-   Certificates can be used to delegate the EEC's identity to various
-   other parties.  Then when one of those other parties uses the PC to
-   authenticate with a service, that service will receive the EEC's
-
-
-
-Tuecke, et al.              Standards Track                    [Page 24]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   identity via the PC, and can apply any ACs that bind that identity to
-   attributes in order to determine authorization rights. Additionally
-   PC with policies could be used to selectively deny the binding of ACs
-   to a particular proxy.  An AC could also be bound to a particular PC
-   using the subject or issuer and serial number of the proxy
-   certificate.  There would appear to be great synergies between the
-   use of Proxy Certificates and Attribute Certificates produced by
-   third party Attribute Authorities.
-
-   However, the uses of Attribute Certificates that are granted by the
-   first type of Attribute Authority, the end entity AA, overlap
-   considerably with the uses of Proxy Certificates as described in the
-   previous sections.  Such Attribute Certificates are generally used
-   for delegation of rights from one end entity to others, which clearly
-   overlaps with the stated purpose of Proxy Certificates, namely single
-   sign-on and delegation.
-
-5.1.2.  Delegation Using Attribute Certificates
-
-   In the motivating example in Section 2, PCs are used to delegate
-   Steve's identity to the various other jobs and entities that need to
-   act on Steve's behalf.  This allows those other entities to
-   authenticate as if they were Steve, for example to the mass storage
-   system.
-
-   A solution to this example could also be cast using Attribute
-   Certificates that are signed by Steve's EEC, which grant to the other
-   entities in this example the right to perform various operations on
-   Steve's behalf.  In this example, the reliable file transfer service
-   and all the hosts involved in file transfers, the starter program,
-   the agent, the simulation jobs, and the post-processing job would
-   each have their own EECs.  Steve's EEC would therefore issue ACs to
-   bind each of those other EEC identities to attributes that grant the
-   necessary privileges allow them to, for example, access the mass
-   storage system.
-
-   However, this AC based solution to delegation has some disadvantages
-   as compared to the PC based solution:
-
-   *  All protocols, authentication code, and identity based
-      authorization services must be modified to understand ACs.  With
-      the PC solution, protocols (e.g., TLS) likely need no
-      modification, authentication code needs minimal modification
-      (e.g., to perform PC aware path validation), and identity based
-      authorization services need minimal modification (e.g., possibly
-      to find the EEC name and to check for any proxy policies).
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 25]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   *  ACs need to be created by Steve's EEC, which bind attributes to
-      each of the other identities involved in the distributed
-      application (i.e., the agent, simulation jobs, and post-processing
-      job the file transfer service, the hosts transferring files).
-      This implies that Steve must know in advance which other
-      identities may be involved in this distributed application, in
-      order to generate the appropriate ACs which are signed by Steve's
-      ECC.  On the other hand, the PC solution allows for much more
-      flexibility, since parties can further delegate a PC without a
-      priori knowledge by the originating EEC.
-
-   There are many unexplored tradeoffs and implications in this
-   discussion of delegation.  However, reasonable arguments can be made
-   in favor of either an AC based solution to delegation or a PC based
-   solution to delegation.  The choice of which approach should be taken
-   in a given instance may depend on factors such as the software that
-   it needs to be integrated into, the type of delegation required, and
-   other factors.
-
-5.1.3.  Propagation of Authorization Information
-
-   One possible use of Proxy Certificates is to carry authorization
-   information associated with a particular identity.
-
-   The merits of placing authorization information into End Entity
-   Certificates (also called a Public Key Certificate or PKC) have been
-   widely debated.  For example, Section 1 of "An Internet Attribute
-   Certificate Profile for Authorization" [i3] states:
-
-      "Authorization information may be placed in a PKC extension or
-      placed in a separate attribute certificate (AC).  The placement of
-      authorization information in PKCs is usually undesirable for two
-      reasons.  First, authorization information often does not have the
-      same lifetime as the binding of the identity and the public key.
-      When authorization information is placed in a PKC extension, the
-      general result is the shortening of the PKC useful lifetime.
-      Second, the PKC issuer is not usually authoritative for the
-      authorization information.  This results in additional steps for
-      the PKC issuer to obtain authorization information from the
-      authoritative source.
-
-      For these reasons, it is often better to separate authorization
-      information from the PKC.  Yet, authorization information also
-      needs to be bound to an identity.  An AC provides this binding; it
-      is simply a digitally signed (or certified) identity and set of
-      attributes."
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 26]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   Placing authorization information in a PC mitigates the first
-   undesirable property cited above.  Since a PC has a lifetime that is
-   mostly independent of (always shorter than) its signing EEC, a PC
-   becomes a viable approach for carrying authorization information for
-   the purpose of delegation.
-
-   The second undesirable property cited above is true.  If a third
-   party AA is authoritative, then using ACs issued by that third party
-   AA is a natural approach to disseminating authorization information.
-   However, this is true whether the identity being bound by these ACs
-   comes from an EEC (PKC), or from a PC.
-
-   There is one case, however, that the above text does not consider.
-   When performing delegation, it is usually the EEC itself that is
-   authoritative (not the EEC issuer, or any third party AA).  That is,
-   it is up to the EEC to decide what authorization rights it is willing
-   to grant to another party.  In this situation, including such
-   authorization information into PCs that are generated by the EEC
-   seems a reasonable approach to disseminating such information.
-
-5.1.4.  Proxy Certificate as Attribute Certificate Holder
-
-   In a system that employs both PCs and ACs, one can imagine the
-   utility of allowing a PC to be the holder of an AC.  This would allow
-   for a particular delegated instance of an identity to be given an
-   attribute, rather than all delegated instances of that identity being
-   given the attribute.
-
-   However, the issue of how to specify a PC as the holder of an AC
-   remains open.  An AC could be bound to a particular instance of a PC
-   using the unique subject name of the PC, or it's issuer and serial
-   number combination.
-
-   Unrestricted PCs issued by that PC would then inherit those ACs and
-   independent PCs would not.  PCs issued with a policy would depend on
-   the policy as to whether or not they inherit the issuing PC's ACs
-   (and potentially which ACs they inherit).
-
-   While an AC can be bound to one PC by the AA, how can the AA restrict
-   that PC from passing it on to a subsequently delegated PC? One
-   possible solution would be to define an extension to attribute
-   certificates that allows the attribute authority to state whether an
-   issued AC is to apply only to the particular entity to which it is
-   bound, or if it may apply to PCs issued by that entity.
-
-   One issue that an AA in this circumstance would need to be aware of
-   is that the PI of the PC that the AA bound the AC to, could issue
-   another PC with the same name as the original PC to a different
-
-
-
-Tuecke, et al.              Standards Track                    [Page 27]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   entity, effectively stealing the AC.  This implies that an AA issuing
-   an AC to a PC need to not only trust the entity holding the PC, but
-   the entity holding the PC's issuer as well.
-
-5.2.  Kerberos 5 Tickets
-
-   The Kerberos Network Authentication Protocol (RFC 1510 [i6]) is a
-   widely used authentication system based on conventional (shared
-   secret key) cryptography.  It provides support for single sign-on via
-   creation of "Ticket Granting Tickets" or "TGT", and support for
-   delegation of rights via "forwardable tickets".
-
-   Kerberos 5 tickets have informed many of the ideas surrounding X.509
-   Proxy Certificates.  For example, the local creation of a short-lived
-   PC can be used to provide single sign-on in an X.509 PKI based
-   system, just as creation of short-lived TGT allows for single sign-on
-   in a Kerberos based system.  And just as a TGT can be forwarded
-   (i.e., delegated) to another entity to allow for proxying in a
-   Kerberos based system, so can a PC can be delegated to allow for
-   proxying in an X.509 PKI based system.
-
-   A major difference between a Kerberos TGT and an X.509 PC is that
-   while creation and delegation of a TGT requires the involvement of a
-   third party (Key Distribution Center), a PC can be unilaterally
-   created without the active involvement of a third party.  That is, a
-   user can directly create a PC from an EEC for single sign-on
-   capability, without requiring communication with a third party.  And
-   an entity with a PC can delegate the PC to another entity (i.e., by
-   creating a new PC, signed by the first) without requiring
-   communication with a third party.
-
-   The method used by Kerberos implementations to protect a TGT can also
-   be used to protect the private key of a PC.  For example, some Unix
-   implementations of Kerberos use standard Unix file system security to
-   protect a user's TGT from compromise.  Similarly, the Globus
-   Toolkit's Grid Security Infrastructure implementation of Proxy
-   Certificates protects a user's PC private key using this same
-   approach.
-
-5.3.  Examples of usage of Proxy Restrictions
-
-   This section gives some examples of Proxy Certificate usage and some
-   examples of how the Proxy policy can be used to restrict Proxy
-   Certificates.
-
-
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 28]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-5.3.1.  Example use of proxies without Restrictions
-
-   Steve wishes to perform a third-party FTP transfer between two FTP
-   servers.  Steve would use an existing PC to authenticate to both
-   servers and delegate a PC to both hosts.  He would inform each host
-   of the unique subject name of the PC given to the other host.  When
-   the servers establish the data channel connection to each other, they
-   use these delegated credentials to perform authentication and verify
-   they are talking to the correct entity by checking the result of the
-   authentication matches the name as provided by Steve.
-
-5.3.2.  Example use of proxies with Restrictions
-
-   Steve wishes to delegate to a process the right to perform a transfer
-   of a file from host H1 to host H2 on his behalf.  Steve would
-   delegate a PC to the process and he would use Proxy Policy to
-   restrict the delegated PC to two rights - the right to read file F1
-   on host H1 and the right to write file F2 on host H2.
-
-   The process then uses this restricted PC to authenticate to servers
-   H1 and H2.  The process would also delegate a PC to both servers.
-   Note that these delegated PCs would inherit the restrictions of their
-   parents, though this is not relevant to this example.  As in the
-   example in the previous Section, each host would be provided with the
-   unique name of the PC given to the other server.
-
-   Now when the process issues the command to transfer the file F1 on H1
-   and to F2 on H2, these two servers perform an authorization check
-   based on the restrictions in the PC that the process used to
-   authenticate with them (in addition to any local policy they have).
-   Namely H1 checks that the PC gives the user the right to read F1 and
-   H2 checks that the PC gives the user the right to write F2. When
-   setting up the data channel the servers would again verify the names
-   resulting from the authentication match the names provided by Steve
-   as in the example in the previous Section.
-
-   The extra security provided by these restrictions is that now if the
-   PC delegated to the process by Steve is stolen, its use is greatly
-   limited.
-
-5.4.  Delegation Tracing
-
-   A relying party accepting a Proxy Certificate may have an interest in
-   knowing which parties issued earlier Proxy Certificates in the
-   certificate chain and to whom they delegated them.  For example it
-   may know that a particular service or resource is known to have been
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 29]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   compromised and if any part of a Proxy Certificate's chain was issued
-   to the compromised service a relying party may wish to disregard the
-   chain.
-
-   A delegation tracing mechanism was considered by the authors as
-   additional information to be carried in the ProxyCertInfo extension.
-   However at this time agreement has not been reached as to what this
-   information should include so it was left out of this document, and
-   will instead be considered in future revisions.  The debate mainly
-   centers on whether the tracing information should simply contain the
-   identity of the issuer and receiver or it should also contain all the
-   details of the delegated proxy and a signed statement from the
-   receiver that the proxy was actually acceptable to it.
-
-5.4.1.  Site Information in Delegation Tracing
-
-   In some cases, it may be desirable to know the hosts involved in a
-   delegation transaction (for example, a relying party may wish to
-   reject proxy certificates that were created on a specific host or
-   domain).  An extension could be modified to include the PA's and
-   Acceptor's IP addresses; however, IP addresses are typically easy to
-   spoof, and in some cases the two parties to a transaction may not
-   agree on the IP addresses being used (e.g., if the Acceptor is on a
-   host that uses NAT, the Acceptor and the PA may disagree about the
-   Acceptor's IP address).
-
-   Another suggestion was, in those cases where domain information is
-   needed, to require that the subject names of all End Entities
-   involved (the Acceptor(s) and the End Entity that appears in a PC's
-   certificate path) include domain information.
-
-6.  Security Considerations
-
-   In this Section we discuss security considerations related to the use
-   of Proxy Certificates.
-
-6.1.  Compromise of a Proxy Certificate
-
-   A Proxy Certificate is generally less secure than the EEC that issued
-   it.  This is due to the fact that the private key of a PC is
-   generally not protected as rigorously as that of the EEC.  For
-   example, the private key of a PC is often protected using only file
-   system security, in order to allow that PC to be used for single
-   sign-on purposes.  This makes the PC more susceptible to compromise.
-
-   However, the risk of a compromised PC is only the misuse of a single
-   user's privileges.  Due to the PC path validation checks, a PC cannot
-   be used to sign an EEC or PC for another user.
-
-
-
-Tuecke, et al.              Standards Track                    [Page 30]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   Further, a compromised PC can only be misused for the lifetime of the
-   PC, and within the bound of the restriction policy carried by the PC.
-   Therefore, one common way to limit the misuse of a compromised PC is
-   to limit its validity period to no longer than is needed, and/or to
-   include a restriction policy in the PC that limits the use of the
-   (compromised) PC.
-
-   In addition, if a PC is compromised, it does NOT compromise the EEC
-   that created the PC.  This property is of great utility in protecting
-   the highly valuable, and hard to replace, public key of the EEC.  In
-   other words, the use of Proxy Certificates to provide single sign-on
-   capabilities in an X.509 PKI environment can actually increase the
-   security of the end entity certificates, because creation and use of
-   the PCs for user authentication limits the exposure of the EEC
-   private key to only the creation of the first level PC.
-
-6.2.  Restricting Proxy Certificates
-
-   The pCPathLenConstraint field of the proxyCertInfo extension can be
-   used by an EEC to limit subsequent delegation of the PC.  A service
-   may choose to only authorize a request if a valid PC can be delegated
-   to it.  An example of such as service is a job starter, which may
-   choose to reject a job start request if a valid PC cannot be
-   delegated to it.  By limiting the pCPathLenConstraint, an EEC can
-   ensure that a compromised PC of one job cannot be used to start
-   additional jobs elsewhere.
-
-   An EEC or PC can limit what a new PC can be used for by turning off
-   bits in the Key Usage and Extended Key Usage extensions.  Once a key
-   usage or extended key usage has been removed, the path validation
-   algorithm ensures that it cannot be added back in a subsequent PC.
-   In other words, key usage can only be decreased in PC chains.
-
-   The EEC could use the CRL Distribution Points extension and/or OCSP
-   to take on the responsibility of revoking PCs that it had issued, if
-   it felt that they were being misused.
-
-6.3.  Relying Party Trust of Proxy Certificates
-
-   The relying party that is going to authorize some actions on the
-   basis of a PC will be aware that it has been presented with a PC, and
-   can determine the depth of the delegation and the time that the
-   delegation took place.  It may want to use this information in
-   addition to the information from the signing EEC.  Thus a highly
-   secure resource might refuse to accept a PC at all, or maybe only a
-   single level of delegation, etc.
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 31]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   The relying party should also be aware that since the policy
-   restricting the rights of a PC is the intersection of the policy of
-   all the PCs in it's certificate chain, this means any change in the
-   certificate chain can effect the policy of the PC.  Since there is no
-   mechanism in place to enforce unique subject names of PCs, if an
-   issuer were to issue two PCs with identical names and keys, but
-   different rights, this could allow the two PCs to be substituted for
-   each other in path validation and effect the rights of a PC down the
-   chain.  Ultimately, this means the relying party places trust in the
-   entities that are acting as Proxy Issuers in the chain to behave
-   properly.
-
-6.4.  Protecting Against Denial of Service with Key Generation
-
-   As discussed in Section 2.3, one of the motivations for Proxy
-   Certificates is to allow for dynamic delegation between parties. This
-   delegation potentially requires, by the party receiving the
-   delegation, the generation of a new key pair which is a potentially
-   computationally expensive operation.  Care should be taken by such
-   parties to prevent another entity from performing a denial of service
-   attack by causing them to consume large amount of resource doing key
-   generation.
-
-   A general guideline would always to perform authentication of the
-   delegating party to prevent such attacks from being performed
-   anonymously.  Another guideline would be to maintain some state to
-   detect and prevent such attacks.
-
-6.5.  Use of Proxy Certificates with a Central Repository
-
-   As discussed in Section 2.7, one potential use of Proxy Certificates
-   is to ease certificate management for end users by storing the EEC
-   private keys and certificates in a centrally managed repository.
-   When a user needs a PKI credential, the user can login to the
-   repository using name/password, one time password, etc. and the
-   repository would then delegate a PC to the user with proxy rights,
-   but continue to protect the EEC private key in the repository.
-
-   Care must be taken with this approach since compromise of the
-   repository will potentially give the attacker access to the long-term
-   private keys stored in the repository.  It is strongly suggested that
-   some form of hardware module be used to store the long-term private
-   keys, which will serve to help prevent their direct threat though it
-   may still allow a successful attacker to use the keys while the
-   repository is compromised to sign arbitrary objects (including Proxy
-   Certificates).
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 32]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-7.  IANA Considerations
-
-   IANA has established a registry for policy languages.  Registration
-   under IETF space is by IETF standards action as described in [i8].
-   Private policy languages should be under organizational OIDs; policy
-   language authors are encouraged to list such languages in the IANA
-   registry, along with a pointer to a specification.
-
-   OID                      Description
-   ---                      -----------
-   1.3.6.1.5.5.7.21.1       id-ppl-inheritALL
-   1.3.6.1.5.5.7.21.2       id-ppl-independent
-
-8.  References
-
-8.1.  Normative References
-
-   [n1]    Bradner, S., "Key words for use in RFCs to Indicate
-           Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [n2]    Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
-           Public Key Infrastructure Certificate and Certificate
-           Revocation List (CRL) Profile", RFC 3280, April 2002.
-
-8.2.  Informative References
-
-   [i1]    Butler, R., Engert, D., Foster, I., Kesselman, C., and S.
-           Tuecke, "A National-Scale Authentication Infrastructure",
-           IEEE Computer, vol. 33, pp. 60-66, 2000.
-
-   [i2]    Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-           2246, January 1999.
-
-   [i3]    Farrell, S. and R. Housley, "An Internet Attribute
-           Certificate Profile for Authorization", RFC 3281, April 2002.
-
-   [i4]    Foster, I., Kesselman, C., Tsudik, G., and S. Tuecke, "A
-           Security Architecture for Computational Grids", presented at
-           Proceedings of the 5th ACM Conference on Computer and
-           Communications Security, 1998.
-
-   [i5]    Foster, I., Kesselman, C., and S. Tuecke, "The Anatomy of the
-           Grid: Enabling Scalable Virtual Organizations", International
-           Journal of Supercomputer Applications, 2001.
-
-   [i6]    Kohl, J. and C. Neuman, "The Kerberos Network Authentication
-           Service (V5)", RFC 1510, September 1993.
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 33]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-   [i7]    Neuman, B. Clifford, "Proxy-Based Authorization and
-           Accounting for Distributed Systems", In Proceedings of the
-           13th International Conference on Distributed Computing
-           Systems, pages 283-291, May 1993.
-
-   [i8]    Narten, T. and H. Alvestrand. "Guidelines for Writing an IANA
-           Considerations Section in RFC", RFC 2434, October 1998.
-
-9.  Acknowledgments
-
-   We are pleased to acknowledge significant contributions to this
-   document by David Chadwick, Ian Foster, Jarek Gawor, Carl Kesselman,
-   Sam Meder, Jim Schaad, and Frank Siebenlist.
-
-   We are grateful to numerous colleagues for discussions on the topics
-   covered in this paper, in particular (in alphabetical order, with
-   apologies to anybody we've missed): Carlisle Adams, Joe Bester, Randy
-   Butler, Keith Jackson, Steve Hanna, Russ Housley, Stephen Kent, Bill
-   Johnston, Marty Humphrey, Sam Lang, Ellen McDermott, Clifford Neuman,
-   Gene Tsudik.
-
-   We are also grateful to members of the Global Grid Forum (GGF) Grid
-   Security Infrastructure working group (GSI-WG), and the Internet
-   Engineering Task Force (IETF) Public-Key Infrastructure (X.509)
-   working group (PKIX) for feedback on this document.
-
-   This work was supported in part by the Mathematical, Information, and
-   Computational Sciences Division subprogram of the Office of Advanced
-   Scientific Computing Research, U.S. Department of Energy, under
-   Contract W-31-109-Eng-38 and DE-AC03-76SF0098; by the Defense
-   Advanced Research Projects Agency under contract N66001-96-C-8523; by
-   the National Science Foundation; and by the NASA Information Power
-   Grid project.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 34]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-Appendix A. 1988 ASN.1 Module
-
-   PKIXproxy88 { iso(1) identified-organization(3) dod(6)
-       internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-       proxy-cert-extns(25) }
-
-   DEFINITIONS EXPLICIT TAGS ::=
-
-   BEGIN
-
-   -- EXPORTS ALL --
-
-   -- IMPORTS NONE --
-
-   -- PKIX specific OIDs
-
-   id-pkix OBJECT IDENTIFIER ::=
-           { iso(1) identified-organization(3)
-                dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
-
-   -- private certificate extensions
-   id-pe   OBJECT IDENTIFIER ::= { id-pkix 1 }
-
-   -- Locally defined OIDs
-
-   -- The proxy certificate extension
-   id-pe-proxyCertInfo    OBJECT IDENTIFIER ::= { id-pe 14 }
-
-   -- Proxy certificate policy languages
-   id-ppl  OBJECT IDENTIFIER ::= { id-pkix 21 }
-
-   -- Proxy certificate policies languages defined in
-   id-ppl-anyLanguage     OBJECT IDENTIFIER ::= { id-ppl 0 }
-   id-ppl-inheritAll      OBJECT IDENTIFIER ::= { id-ppl 1 }
-   id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl 2 }
-
-   -- The ProxyCertInfo Extension
-   ProxyCertInfoExtension  ::= SEQUENCE {
-         pCPathLenConstraint     ProxyCertPathLengthConstraint
-                                       OPTIONAL,
-         proxyPolicy             ProxyPolicy }
-
-   ProxyCertPathLengthConstraint  ::= INTEGER
-   ProxyPolicy  ::= SEQUENCE {
-         policyLanguage          OBJECT IDENTIFIER,
-         policy                  OCTET STRING OPTIONAL }
-
-   END
-
-
-
-Tuecke, et al.              Standards Track                    [Page 35]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-Authors' Addresses
-
-   Steven Tuecke
-   Distributed Systems Laboratory
-   Mathematics and Computer Science Division
-   Argonne National Laboratory
-   Argonne, IL 60439
-
-   Phone: 630-252-8711
-   EMail: tuecke@mcs.anl.gov
-
-
-   Von Welch
-   National Center for Supercomputing Applications
-   University of Illinois
-
-   EMail: vwelch@ncsa.uiuc.edu
-
-
-   Doug Engert
-   Argonne National Laboratory
-
-   EMail: deengert@anl.gov
-
-
-   Laura Pearlman
-   University of Southern California, Information Sciences Institute
-
-   EMail: laura@isi.edu
-
-
-   Mary Thompson
-   Lawrence Berkeley National Laboratory
-
-   EMail: mrthompson@lbl.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 36]
-
-RFC 3820            X.509 Proxy Certificate Profile            June 2004
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-Tuecke, et al.              Standards Track                    [Page 37]
-
diff --git a/doc/standardisation/rfc3961.txt b/doc/standardisation/rfc3961.txt
deleted file mode 100644
index 0ac50b959..000000000
--- a/doc/standardisation/rfc3961.txt
+++ /dev/null
@@ -1,2803 +0,0 @@
-
-
-
-
-
-
-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
-      as inputs and verifies the integrity of the supplied ciphertext.
-      If the ciphertext's integrity is intact, this function produces
-      the plaintext and a new cipher state as outputs; otherwise, an
-      error indication must be returned, and the data discarded.
-
-      The result of the decryption may be longer than the original
-      plaintext, as, for example, when the encryption mode adds padding
-      to reach a multiple of a block size.  If this is the case, any
-      extra octets must come after the decoded plaintext.  An
-      application protocol that needs to know the exact length of the
-      message must encode a length or recognizable "end of message"
-      marker within the plaintext [3].
-
-      As with the encryption function, a correct specification for this
-      function must indicate not only the contents of the output octet
-      string, but also the resulting cipher state.
-
-   pseudo-random (protocol-key, octet-string)->(octet-string)
-      This pseudo-random function should generate an octet string of
-      some size that is independent of the octet string input.  The PRF
-      output string should be suitable for use in key generation, even
-      if the octet string input is public.  It should not reveal the
-      input key, even if the output is made public.
-
-   These operations and attributes are all that is required to support
-   Kerberos and various proposed preauthentication schemes.
-
-   For convenience of certain application protocols that may wish to use
-   the encryption profile, we add the constraint that, for any given
-   plaintext input size, a message size must exist between that given
-   size and that size plus 65,535 such that the length of the decrypted
-   version of the ciphertext will never have extra octets at the end.
-
-   Expressed mathematically, for every message length L1, there exists a
-   message size L2 such that
-
-      L2 >= L1
-      L2 < L1 + 65,536
-      for every message M with |M| = L2, decrypt(encrypt(M)) = M
-
-   A document defining a new encryption type should also describe known
-   weaknesses or attacks, so that its security may be fairly assessed,
-   and should include test vectors or other validation procedures for
-   the operations defined.  Specific references to information that is
-   readily available elsewhere are sufficient.
-
-
-
-
-Raeburn                     Standards Track                     [Page 8]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-4.  Checksum Algorithm Profile
-
-   A checksum mechanism profile must define the following attributes and
-   operations:
-
-   associated encryption algorithm(s)
-      This indicates the types of encryption keys this checksum
-      mechanism can be used with.
-
-      A keyed checksum mechanism may have more than one associated
-      encryption algorithm if they share the same wire-key format,
-      string-to-key function, default string-to-key-parameters, and key
-      derivation function.  (This combination means that, for example, a
-      checksum type, key usage value, and password are adequate to get
-      the specific key used to compute a checksum.)
-
-      An unkeyed checksum mechanism can be used with any encryption
-      type, as the key is ignored, but its use must be limited to cases
-      where the checksum itself is protected, to avoid trivial attacks.
-
-   get_mic function
-      This function generates a MIC token for a given specific key (see
-      section 3) and message (represented as an octet string) that may
-      be used to verify the integrity of the associated message.  This
-      function is not required to return the same deterministic result
-      for each use; it need only generate a token that the verify_mic
-      routine can check.
-
-      The output of this function will also dictate the size of the
-      checksum.  It must be no larger than 65,535 octets.
-
-   verify_mic function
-      Given a specific key, message, and MIC token, this function
-      ascertains whether the message integrity has been compromised.
-      For a deterministic get_mic routine, the corresponding verify_mic
-      may simply generate another checksum and compare the two.
-
-   The get_mic and verify_mic operations must allow inputs of arbitrary
-   length; if any padding is needed, the padding scheme must be
-   specified as part of these functions.
-
-   These operations and attributes are all that should be required to
-   support Kerberos and various proposed preauthentication schemes.
-
-   As with encryption mechanism definition documents, documents defining
-   new checksum mechanisms should indicate validation processes and
-   known weaknesses.
-
-
-
-
-Raeburn                     Standards Track                     [Page 9]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-5.  Simplified Profile for CBC Ciphers with Key Derivation
-
-   The profile outlined in sections 3 and 4 describes a large number of
-   operations that must be defined for encryption and checksum
-   algorithms to be used with Kerberos.  Here we describe a simpler
-   profile that can generate both encryption and checksum mechanism
-   definitions, filling in uses of key derivation in appropriate places,
-   providing integrity protection, and defining multiple operations for
-   the cryptosystem profile based on a smaller set of operations.  Not
-   all of the existing cryptosystems for Kerberos fit into this
-   simplified profile, but we recommend that future cryptosystems use it
-   or something based on it [4].
-
-   Not all the operations in the complete profiles are defined through
-   this mechanism; several must still be defined for each new algorithm
-   pair.
-
-5.1.  A Key Derivation Function
-
-   Rather than define some scheme by which a "protocol key" is composed
-   of a large number of encryption keys, we use keys derived from a base
-   key to perform cryptographic operations.  The base key must be used
-   only for generating the derived keys, and this derivation must be
-   non-invertible and entropy preserving.  Given these restrictions,
-   compromise of one derived key does not compromise others.  Attack of
-   the base key is limited, as it is only used for derivation and is not
-   exposed to any user data.
-
-   To generate a derived key from a base key, we generate a pseudorandom
-   octet string by using an algorithm DR, described below, and generate
-   a key from that octet string by using a function dependent on the
-   encryption algorithm.  The input length needed for that function,
-   which is also dependent on the encryption algorithm, dictates the
-   length of the string to be generated by the DR algorithm (the value
-   "k" below).  These procedures are based on the key derivation in
-   [Blumenthal96].
-
-      Derived Key = DK(Base Key, Well-Known Constant)
-
-      DK(Key, Constant) = random-to-key(DR(Key, Constant))
-
-      DR(Key, Constant) = k-truncate(E(Key, Constant,
-                                       initial-cipher-state))
-
-   Here DR is the random-octet generation function described below, and
-   DK is the key-derivation function produced from it.  In this
-   construction, E(Key, Plaintext, CipherState) is a cipher, Constant is
-   a well-known constant determined by the specific usage of this
-
-
-
-Raeburn                     Standards Track                    [Page 10]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   function, and k-truncate truncates its argument by taking the first k
-   bits.  Here, k is the key generation seed length needed for the
-   encryption system.
-
-   The output of the DR function is a string of bits; the actual key is
-   produced by applying the cryptosystem's random-to-key operation on
-   this bitstring.
-
-   If the Constant is smaller than the cipher block size of E, then it
-   must be expanded with n-fold() so it can be encrypted.  If the output
-   of E is shorter than k bits, it is fed back into the encryption as
-   many times as necessary.  The construct is as follows (where |
-   indicates concatentation):
-
-      K1 = E(Key, n-fold(Constant), initial-cipher-state)
-      K2 = E(Key, K1, initial-cipher-state)
-      K3 = E(Key, K2, initial-cipher-state)
-      K4 = ...
-
-      DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
-
-   n-fold is an algorithm that takes m input bits and "stretches" them
-   to form n output bits with equal contribution from each input bit to
-   the output, as described in [Blumenthal96]:
-
-      We first define a primitive called n-folding, which takes a
-      variable-length input block and produces a fixed-length output
-      sequence.  The intent is to give each input bit approximately
-      equal weight in determining the value of each output bit.  Note
-      that whenever we need to treat a string of octets as a number, the
-      assumed representation is Big-Endian -- Most Significant Byte
-      first.
-
-      To n-fold a number X, replicate the input value to a length that
-      is the least common multiple of n and the length of X.  Before
-      each repetition, the input is rotated to the right by 13 bit
-      positions.  The successive n-bit chunks are added together using
-      1's-complement addition (that is, with end-around carry) to yield
-      a n-bit result....
-
-   Test vectors for n-fold are supplied in appendix A [5].
-
-   In this section, n-fold is always used to produce c bits of output,
-   where c is the cipher block size of E.
-
-   The size of the Constant must not be larger than c, because reducing
-   the length of the Constant by n-folding can cause collisions.
-
-
-
-
-Raeburn                     Standards Track                    [Page 11]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   If the size of the Constant is smaller than c, then the Constant must
-   be n-folded to length c.  This string is used as input to E.  If the
-   block size of E is less than the random-to-key input size, then the
-   output from E is taken as input to a second invocation of E.  This
-   process is repeated until the number of bits accumulated is greater
-   than or equal to the random-to-key input size.  When enough bits have
-   been computed, the first k are taken as the random data used to
-   create the key with the algorithm-dependent random-to-key function.
-
-   As the derived key is the result of one or more encryptions in the
-   base key, deriving the base key from the derived key is equivalent to
-   determining the key from a very small number of plaintext/ciphertext
-   pairs.  Thus, this construction is as strong as the cryptosystem
-   itself.
-
-5.2.  Simplified Profile Parameters
-
-   These are the operations and attributes that must be defined:
-
-   protocol key format
-   string-to-key function
-   default string-to-key parameters
-   key-generation seed length, k
-   random-to-key function
-      As above for the normal encryption mechanism profile.
-
-   unkeyed hash algorithm, H
-      This should be a collision-resistant hash algorithm with fixed-
-      size output, suitable for use in an HMAC [HMAC].  It must support
-      inputs of arbitrary length.  Its output must be at least the
-      message block size (below).
-
-   HMAC output size, h
-      This indicates the size of the leading substring output by the
-      HMAC function that should be used in transmitted messages.  It
-      should be at least half the output size of the hash function H,
-      and at least 80 bits; it need not match the output size.
-
-   message block size, m
-      This is the size of the smallest units the cipher can handle in
-      the mode in which it is being used.  Messages will be padded to a
-      multiple of this size.  If a block cipher is used in a mode that
-
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 12]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-      can handle messages that are not multiples of the cipher block
-      size, such as CBC mode with cipher text stealing (CTS, see [RC5]),
-      this value would be one octet.  For traditional CBC mode with
-      padding, it would be the underlying cipher's block size.
-
-      This value must be a multiple of eight bits (one octet).
-
-   encryption/decryption functions, E and D
-      These are basic encryption and decryption functions for messages
-      of sizes that are multiples of the message block size.  No
-      integrity checking or confounder should be included here.  For
-      inputs these functions take the IV or similar data, a protocol-
-      format key, and an octet string, returning a new IV and octet
-      string.
-
-      The encryption function is not required to use CBC mode but is
-      assumed to be using something with similar properties.  In
-      particular, prepending a cipher block-size confounder to the
-      plaintext should alter the entire ciphertext (comparable to
-      choosing and including a random initial vector for CBC mode).
-
-      The result of encrypting one cipher block (of size c, above) must
-      be deterministic for the random octet generation function DR in
-      the previous section to work.  For best security, it should also
-      be no larger than c.
-
-   cipher block size, c
-      This is the block size of the block cipher underlying the
-      encryption and decryption functions indicated above, used for key
-      derivation and for the size of the message confounder and initial
-      vector.  (If a block cipher is not in use, some comparable
-      parameter should be determined.)  It must be at least 5 octets.
-
-      This is not actually an independent parameter; rather, it is a
-      property of the functions E and D.  It is listed here to clarify
-      the distinction between it and the message block size, m.
-
-   Although there are still a number of properties to specify, they are
-   fewer and simpler than in the full profile.
-
-5.3.  Cryptosystem Profile Based on Simplified Profile
-
-   The above key derivation function is used to produce three
-   intermediate keys.  One is used for computing checksums of
-   unencrypted data.  The other two are used for encrypting and
-   checksumming plaintext to be sent encrypted.
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 13]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   The ciphertext output is the concatenation of the output of the basic
-   encryption function E and a (possibly truncated) HMAC using the
-   specified hash function H, both applied to the plaintext with a
-   random confounder prefix and sufficient padding to bring it to a
-   multiple of the message block size.  When the HMAC is computed, the
-   key is used in the protocol key form.
-
-   Decryption is performed by removing the (partial) HMAC, decrypting
-   the remainder, and verifying the HMAC.  The cipher state is an
-   initial vector, initialized to zero.
-
-   The substring notation "[1..h]" in the following table should be read
-   as using 1-based indexing; leading substrings are used.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 14]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-                   Cryptosystem from Simplified Profile
-------------------------------------------------------------------------
-protocol key format       As given.
-
-specific key structure    Three protocol-format keys: { Kc, Ke, Ki }.
-
-key-generation seed       As given.
-length
-
-required checksum         As defined below in section 5.4.
-mechanism
-
-cipher state              Initial vector (usually of length c)
-
-initial cipher state      All bits zero
-
-encryption function       conf = Random string of length c
-                          pad  = Shortest string to bring confounder
-                                 and plaintext to a length that's a
-                                 multiple of m.
-                          (C1, newIV) = E(Ke, conf | plaintext | pad,
-                                          oldstate.ivec)
-                          H1 = HMAC(Ki, conf | plaintext | pad)
-                          ciphertext =  C1 | H1[1..h]
-                          newstate.ivec = newIV
-
-decryption function       (C1,H1) = ciphertext
-                          (P1, newIV) = D(Ke, C1, oldstate.ivec)
-                          if (H1 != HMAC(Ki, P1)[1..h])
-                             report error
-                          newstate.ivec = newIV
-
-default string-to-key     As given.
-params
-
-pseudo-random function    tmp1 = H(octet-string)
-                          tmp2 = truncate tmp1 to multiple of m
-                          PRF = E(DK(protocol-key, prfconstant),
-                                  tmp2, initial-cipher-state)
-
-   The "prfconstant" used in the PRF operation is the three-octet string
-   "prf".
-
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 15]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-                   Cryptosystem from Simplified Profile
-------------------------------------------------------------------------
-key generation functions:
-
-string-to-key function    As given.
-
-random-to-key function    As given.
-
-key-derivation function   The "well-known constant" used for the DK
-                          function is the key usage number, expressed as
-                          four octets in big-endian order, followed by
-                          one octet indicated below.
-
-                          Kc = DK(base-key, usage | 0x99);
-                          Ke = DK(base-key, usage | 0xAA);
-                          Ki = DK(base-key, usage | 0x55);
-
-5.4.  Checksum Profiles Based on Simplified Profile
-
-   When an encryption system is defined with the simplified profile
-   given in section 5.2, a checksum algorithm may be defined for it as
-   follows:
-
-                Checksum Mechanism from Simplified Profile
-             --------------------------------------------------
-             associated cryptosystem   As defined above.
-
-             get_mic                   HMAC(Kc, message)[1..h]
-
-             verify_mic                get_mic and compare
-
-   The HMAC function and key Kc are as described in section 5.3.
-
-6.  Profiles for Kerberos Encryption and Checksum Algorithms
-
-   These profiles describe the encryption and checksum systems defined
-   for Kerberos.  The astute reader will notice that some of them do not
-   fulfill all the requirements outlined in previous sections.  These
-   systems are defined for backward compatibility; newer implementations
-   should (whenever possible) attempt to utilize encryption systems that
-   satisfy all the profile requirements.
-
-   The full list of current encryption and checksum type number
-   assignments, including values currently reserved but not defined in
-   this document, is given in section 8.
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 16]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-6.1.  Unkeyed Checksums
-
-   These checksum types use no encryption keys and thus can be used in
-   combination with any encryption type, but they may only be used with
-   caution, in limited circumstances where the lack of a key does not
-   provide a window for an attack, preferably as part of an encrypted
-   message [6].  Keyed checksum algorithms are recommended.
-
-6.1.1.  The RSA MD5 Checksum
-
-   The RSA-MD5 checksum calculates a checksum by using the RSA MD5
-   algorithm [MD5-92].  The algorithm takes as input an input message of
-   arbitrary length and produces as output a 128-bit (sixteen octet)
-   checksum.
-
-                                  rsa-md5
-               ----------------------------------------------
-               associated cryptosystem   any
-
-               get_mic                   rsa-md5(msg)
-
-               verify_mic                get_mic and compare
-
-   The rsa-md5 checksum algorithm is assigned a checksum type number of
-   seven (7).
-
-6.1.2.  The RSA MD4 Checksum
-
-   The RSA-MD4 checksum calculates a checksum using the RSA MD4
-   algorithm [MD4-92].  The algorithm takes as input an input message of
-   arbitrary length and produces as output a 128-bit (sixteen octet)
-   checksum.
-
-                                  rsa-md4
-               ----------------------------------------------
-               associated cryptosystem   any
-
-               get_mic                   md4(msg)
-
-               verify_mic                get_mic and compare
-
-   The rsa-md4 checksum algorithm is assigned a checksum type number of
-   two (2).
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 17]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-6.1.3.  CRC-32 Checksum
-
-   This CRC-32 checksum calculates a checksum based on a cyclic
-   redundancy check as described in ISO 3309 [CRC] but modified as
-   described below.  The resulting checksum is four (4) octets in
-   length.  The CRC-32 is neither keyed nor collision-proof; thus, the
-   use of this checksum is not recommended.  An attacker using a
-   probabilistic chosen-plaintext attack as described in [SG92] might be
-   able to generate an alternative message that satisfies the checksum.
-
-   The CRC-32 checksum used in the des-cbc-crc encryption mode is
-   identical to the 32-bit FCS described in ISO 3309 with two
-   exceptions: The sum with the all-ones polynomial times x**k is
-   omitted, and the final remainder is not ones-complemented.  ISO 3309
-   describes the FCS in terms of bits, whereas this document describes
-   the Kerberos protocol in terms of octets.  To clarify the ISO 3309
-   definition for the purpose of computing the CRC-32 in the des-cbc-crc
-   encryption mode, the ordering of bits in each octet shall be assumed
-   to be LSB first.  Given this assumed ordering of bits within an
-   octet, the mapping of bits to polynomial coefficients shall be
-   identical to that specified in ISO 3309.
-
-   Test values for this modified CRC function are included in appendix
-   A.5.
-
-                                   crc32
-               ----------------------------------------------
-               associated cryptosystem   any
-
-               get_mic                   crc32(msg)
-
-               verify_mic                get_mic and compare
-
-   The crc32 checksum algorithm is assigned a checksum type number of
-   one (1).
-
-6.2.  DES-Based Encryption and Checksum Types
-
-   These encryption systems encrypt information under the Data
-   Encryption Standard [DES77] by using the cipher block chaining mode
-   [DESM80].  A checksum is computed as described below and placed in
-   the cksum field.  DES blocks are eight bytes.  As a result, the data
-   to be encrypted (the concatenation of confounder, checksum, and
-   message) must be padded to an eight byte boundary before encryption.
-   The values of the padding bytes are unspecified.
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 18]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   Plaintext and DES ciphertext are encoded as blocks of eight octets,
-   which are concatenated to make the 64-bit inputs for the DES
-   algorithms.  The first octet supplies the eight most significant bits
-   (with the octet's MSB used as the DES input block's MSB, etc.), the
-   second octet the next eight bits, and so on.  The eighth octet
-   supplies the 8 least significant bits.
-
-   Encryption under DES using cipher block chaining requires an
-   additional input in the form of an initialization vector; this vector
-   is specified below for each encryption system.
-
-   The DES specifications [DESI81] identify four 'weak' and twelve
-   'semi-weak' keys; these keys SHALL NOT be used for encrypting
-   messages for use in Kerberos.  The "variant keys" generated for the
-   RSA-MD5-DES, RSA-MD4-DES, and DES-MAC checksum types by an
-   eXclusive-OR of a DES key with a constant are not checked for this
-   property.
-
-   A DES key is eight octets of data.  This consists of 56 bits of
-   actual key data, and eight parity bits, one per octet.  The key is
-   encoded as a series of eight octets written in MSB-first order.  The
-   bits within the key are also encoded in MSB order.  For example, if
-   the encryption key is
-   (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8), where
-   B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the
-   parity bits, the first octet of the key would be B1,B2,...,B7,P1
-   (with B1 as the most significant bit).  See the [DESM80] introduction
-   for reference.
-
-   Encryption Data Format
-
-   The format for the data to be encrypted includes a one-block
-   confounder, a checksum, the encoded plaintext, and any necessary
-   padding, as described in the following diagram.  The msg-seq field
-   contains the part of the protocol message to be encrypted.
-
-                  +-----------+----------+---------+-----+
-                  |confounder | checksum | msg-seq | pad |
-                  +-----------+----------+---------+-----+
-
-   One generates a random confounder of one block, placing it in
-   'confounder'; zeros out the 'checksum' field (of length appropriate
-   to exactly hold the checksum to be computed); adds the necessary
-   padding; calculates the appropriate checksum over the whole sequence,
-   placing the result in 'checksum'; and then encrypts using the
-   specified encryption type and the appropriate key.
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 19]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   String or Random-Data to Key Transformation
-
-   To generate a DES key from two UTF-8 text strings (password and
-   salt), the two strings are concatenated, password first, and the
-   result is then padded with zero-valued octets to a multiple of eight
-   octets.
-
-   The top bit of each octet (always zero if the password is plain
-   ASCII, as was assumed when the original specification was written) is
-   discarded, and the remaining seven bits of each octet form a
-   bitstring.  This is then fan-folded and eXclusive-ORed with itself to
-   produce a 56-bit string.  An eight-octet key is formed from this
-   string, each octet using seven bits from the bitstring, leaving the
-   least significant bit unassigned.  The key is then "corrected" by
-   correcting the parity on the key, and if the key matches a 'weak' or
-   'semi-weak' key as described in the DES specification, it is
-   eXclusive-ORed with the constant 0x00000000000000F0.  This key is
-   then used to generate a DES CBC checksum on the initial string with
-   the salt appended.  The result of the CBC checksum is then
-   "corrected" as described above to form the result, which is returned
-   as the key.
-
-   For purposes of the string-to-key function, the DES CBC checksum is
-   calculated by CBC encrypting a string using the key as IV and the
-   final eight byte block as the checksum.
-
-   Pseudocode follows:
-
-        removeMSBits(8byteblock) {
-          /* Treats a 64 bit block as 8 octets and removes the MSB in
-             each octet (in big endian mode) and concatenates the
-             result.  E.g., the input octet string:
-                01110000 01100001 11110011  01110011 11110111 01101111
-                11110010 01100100
-             results in the output bitstring:
-                1110000 1100001 1110011  1110011 1110111 1101111
-                1110010 1100100  */
-        }
-
-        reverse(56bitblock) {
-          /* Treats a 56-bit block as a binary string and reverses it.
-             E.g., the input string:
-                1000001 1010100 1001000  1000101 1001110 1000001
-                0101110 1001101
-             results in the output string:
-                1011001 0111010 1000001  0111001 1010001 0001001
-                0010101 1000001  */
-        }
-
-
-
-Raeburn                     Standards Track                    [Page 20]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-        add_parity_bits(56bitblock) {
-          /* Copies a 56-bit block into a 64-bit block, left shifts
-             content in each octet, and add DES parity bit.
-             E.g., the input string:
-                1100000 0001111 0011100  0110100 1000101 1100100
-                0110110 0010111
-             results in the output string:
-                11000001 00011111 00111000  01101000 10001010 11001000
-                01101101 00101111  */
-        }
-
-        key_correction(key) {
-             fixparity(key);
-             if (is_weak_key(key))
-                  key = key XOR 0xF0;
-             return(key);
-        }
-
-        mit_des_string_to_key(string,salt) {
-             odd = 1;
-             s = string | salt;
-             tempstring = 0; /* 56-bit string */
-             pad(s); /* with nulls to 8 byte boundary */
-             for (8byteblock in s) {
-                  56bitstring = removeMSBits(8byteblock);
-                  if (odd == 0) reverse(56bitstring);
-                  odd = ! odd;
-                  tempstring = tempstring XOR 56bitstring;
-             }
-             tempkey = key_correction(add_parity_bits(tempstring));
-             key = key_correction(DES-CBC-check(s,tempkey));
-             return(key);
-        }
-
-        des_string_to_key(string,salt,params) {
-             if (length(params) == 0)
-                  type = 0;
-             else if (length(params) == 1)
-                  type = params[0];
-             else
-                  error("invalid params");
-             if (type == 0)
-                  mit_des_string_to_key(string,salt);
-             else
-                  error("invalid params");
-        }
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 21]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   One common extension is to support the "AFS string-to-key" algorithm,
-   which is not defined here, if the type value above is one (1).
-
-   For generation of a key from a random bitstring, we start with a 56-
-   bit string and, as with the string-to-key operation above, insert
-   parity bits.  If the result is a weak or semi-weak key, we modify it
-   by eXclusive-OR with the constant 0x00000000000000F0:
-
-        des_random_to_key(bitstring) {
-             return key_correction(add_parity_bits(bitstring));
-        }
-
-6.2.1.  DES with MD5
-
-   The des-cbc-md5 encryption mode encrypts information under DES in CBC
-   mode with an all-zero initial vector and with an MD5 checksum
-   (described in [MD5-92]) computed and placed in the checksum field.
-
-   The encryption system parameters for des-cbc-md5 are as follows:
-
-                               des-cbc-md5
-   --------------------------------------------------------------------
-   protocol key format      8 bytes, parity in low bit of each
-
-   specific key structure   copy of original key
-
-   required checksum        rsa-md5-des
-   mechanism
-
-   key-generation seed      8 bytes
-   length
-
-   cipher state             8 bytes (CBC initial vector)
-
-   initial cipher state     all-zero
-
-   encryption function      des-cbc(confounder | checksum | msg | pad,
-                                    ivec=oldstate)
-                            where
-                            checksum = md5(confounder | 0000...
-                                           | msg | pad)
-
-                            newstate = last block of des-cbc output
-
-   decryption function      decrypt encrypted text and verify checksum
-
-                            newstate = last block of ciphertext
-
-
-
-
-Raeburn                     Standards Track                    [Page 22]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-                               des-cbc-md5
-   --------------------------------------------------------------------
-   default string-to-key    empty string
-   params
-
-   pseudo-random function   des-cbc(md5(input-string), ivec=0)
-
-   key generation functions:
-
-   string-to-key            des_string_to_key
-
-   random-to-key            des_random_to_key
-
-   key-derivation           identity
-
-   The des-cbc-md5 encryption type is assigned the etype value three
-   (3).
-
-6.2.2.  DES with MD4
-
-   The des-cbc-md4 encryption mode also encrypts information under DES
-   in CBC mode, with an all-zero initial vector.  An MD4 checksum
-   (described in [MD4-92]) is computed and placed in the checksum field.
-
-                               des-cbc-md4
-   --------------------------------------------------------------------
-   protocol key format      8 bytes, parity in low bit of each
-
-   specific key structure   copy of original key
-
-   required checksum        rsa-md4-des
-   mechanism
-
-   key-generation seed      8 bytes
-   length
-
-   cipher state             8 bytes (CBC initial vector)
-
-   initial cipher state     all-zero
-
-   encryption function      des-cbc(confounder | checksum | msg | pad,
-                                    ivec=oldstate)
-                            where
-                            checksum = md4(confounder | 0000...
-                                           | msg | pad)
-
-                            newstate = last block of des-cbc output
-
-
-
-
-Raeburn                     Standards Track                    [Page 23]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-                               des-cbc-md4
-   --------------------------------------------------------------------
-
-   decryption function      decrypt encrypted text and verify checksum
-
-                            newstate = last block of ciphertext
-
-   default string-to-key    empty string
-   params
-
-   pseudo-random function   des-cbc(md5(input-string), ivec=0)
-
-   key generation functions:
-
-   string-to-key            des_string_to_key
-
-   random-to-key            copy input, then fix parity bits
-
-   key-derivation           identity
-
-   Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
-
-   The des-cbc-md4 encryption algorithm is assigned the etype value two
-   (2).
-
-6.2.3.  DES with CRC
-
-   The des-cbc-crc encryption type uses DES in CBC mode with the key
-   used as the initialization vector, with a four-octet CRC-based
-   checksum computed as described in section 6.1.3.  Note that this is
-   not a standard CRC-32 checksum, but a slightly modified one.
-
-                               des-cbc-crc
-   --------------------------------------------------------------------
-   protocol key format      8 bytes, parity in low bit of each
-
-   specific key structure   copy of original key
-
-   required checksum        rsa-md5-des
-   mechanism
-
-   key-generation seed      8 bytes
-   length
-
-   cipher state             8 bytes (CBC initial vector)
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 24]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-                               des-cbc-crc
-   --------------------------------------------------------------------
-   initial cipher state     copy of original key
-
-   encryption function      des-cbc(confounder | checksum | msg | pad,
-                                    ivec=oldstate)
-                            where
-                            checksum = crc(confounder | 00000000
-                                           | msg | pad)
-
-                            newstate = last block of des-cbc output
-
-   decryption function      decrypt encrypted text and verify checksum
-
-                            newstate = last block of ciphertext
-
-   default string-to-key    empty string
-   params
-
-   pseudo-random function   des-cbc(md5(input-string), ivec=0)
-
-   key generation functions:
-
-   string-to-key            des_string_to_key
-
-   random-to-key            copy input, then fix parity bits
-
-   key-derivation           identity
-
-   The des-cbc-crc encryption algorithm is assigned the etype value one
-   (1).
-
-6.2.4.  RSA MD5 Cryptographic Checksum Using DES
-
-   The RSA-MD5-DES checksum calculates a keyed collision-proof checksum
-   by prepending an eight octet confounder before the text, applying the
-   RSA MD5 checksum algorithm, and encrypting the confounder and the
-   checksum by using DES in cipher-block-chaining (CBC) mode with a
-   variant of the key, where the variant is computed by eXclusive-ORing
-   the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0.  The
-   initialization vector should be zero.  The resulting checksum is 24
-   octets long.
-
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 25]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-                                rsa-md5-des
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
-                                        conf | rsa-md5(conf | msg))
-
-      verify_mic                decrypt and verify rsa-md5 checksum
-
-   The rsa-md5-des checksum algorithm is assigned a checksum type number
-   of eight (8).
-
-6.2.5.  RSA MD4 Cryptographic Checksum Using DES
-
-   The RSA-MD4-DES checksum calculates a keyed collision-proof checksum
-   by prepending an eight octet confounder before the text, applying the
-   RSA MD4 checksum algorithm [MD4-92], and encrypting the confounder
-   and the checksum using DES in cipher-block-chaining (CBC) mode with a
-   variant of the key, where the variant is computed by eXclusive-ORing
-   the key with the constant 0xF0F0F0F0F0F0F0F0 [7].  The initialization
-   vector should be zero.  The resulting checksum is 24 octets long.
-
-                                rsa-md4-des
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
-                                        conf | rsa-md4(conf | msg),
-                                        ivec=0)
-
-      verify_mic                decrypt and verify rsa-md4 checksum
-
-   The rsa-md4-des checksum algorithm is assigned a checksum type number
-   of three (3).
-
-6.2.6.  RSA MD4 Cryptographic Checksum Using DES Alternative
-
-   The RSA-MD4-DES-K checksum calculates a keyed collision-proof
-   checksum by applying the RSA MD4 checksum algorithm and encrypting
-   the results by using DES in cipher block chaining (CBC) mode with a
-   DES key as both key and initialization vector.  The resulting
-   checksum is 16 octets long.  This checksum is tamper-proof and
-   believed to be collision-proof.  Note that this checksum type is the
-   old method for encoding the RSA-MD4-DES checksum; it is no longer
-   recommended.
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 26]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-                               rsa-md4-des-k
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-cbc(key, md4(msg), ivec=key)
-
-      verify_mic                decrypt, compute checksum and compare
-
-   The rsa-md4-des-k checksum algorithm is assigned a checksum type
-   number of six (6).
-
-6.2.7.  DES CBC Checksum
-
-   The DES-MAC checksum is computed by prepending an eight octet
-   confounder to the plaintext, padding with zero-valued octets if
-   necessary to bring the length to a multiple of eight octets,
-   performing a DES CBC-mode encryption on the result by using the key
-   and an initialization vector of zero, taking the last block of the
-   ciphertext, prepending the same confounder, and encrypting the pair
-   by using DES in cipher-block-chaining (CBC) mode with a variant of
-   the key, where the variant is computed by eXclusive-ORing the key
-   with the constant 0xF0F0F0F0F0F0F0F0.  The initialization vector
-   should be zero.  The resulting checksum is 128 bits (sixteen octets)
-   long, 64 bits of which are redundant.  This checksum is tamper-proof
-   and collision-proof.
-
-                                  des-mac
-   ---------------------------------------------------------------------
-   associated     des-cbc-md5, des-cbc-md4, des-cbc-crc
-   cryptosystem
-
-   get_mic        des-cbc(key XOR 0xF0F0F0F0F0F0F0F0,
-                          conf | des-mac(key, conf | msg | pad, ivec=0),
-                          ivec=0)
-
-   verify_mic     decrypt, compute DES MAC using confounder, compare
-
-   The des-mac checksum algorithm is assigned a checksum type number of
-   four (4).
-
-6.2.8.  DES CBC Checksum Alternative
-
-   The DES-MAC-K checksum is computed by performing a DES CBC-mode
-   encryption of the plaintext, with zero-valued padding bytes if
-   necessary to bring the length to a multiple of eight octets, and by
-   using the last block of the ciphertext as the checksum value.  It is
-   keyed with an encryption key that is also used as the initialization
-   vector.  The resulting checksum is 64 bits (eight octets) long.  This
-
-
-
-Raeburn                     Standards Track                    [Page 27]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   checksum is tamper-proof and collision-proof.  Note that this
-   checksum type is the old method for encoding the DESMAC checksum; it
-   is no longer recommended.
-
-                                 des-mac-k
-      ----------------------------------------------------------------
-      associated cryptosystem   des-cbc-md5, des-cbc-md4, des-cbc-crc
-
-      get_mic                   des-mac(key, msg | pad, ivec=key)
-
-      verify_mic                compute MAC and compare
-
-   The des-mac-k checksum algorithm is assigned a checksum type number
-   of five (5).
-
-6.3.  Triple-DES Based Encryption and Checksum Types
-
-   This encryption and checksum type pair is based on the Triple DES
-   cryptosystem in Outer-CBC mode and on the HMAC-SHA1 message
-   authentication algorithm.
-
-   A Triple DES key is the concatenation of three DES keys as described
-   above for des-cbc-md5.  A Triple DES key is generated from random
-   data by creating three DES keys from separate sequences of random
-   data.
-
-   Encrypted data using this type must be generated as described in
-   section 5.3.  If the length of the input data is not a multiple of
-   the block size, zero-valued octets must be used to pad the plaintext
-   to the next eight-octet boundary.  The confounder must be eight
-   random octets (one block).
-
-   The simplified profile for Triple DES, with key derivation as defined
-   in section 5, is as follows:
-
-                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
-              ------------------------------------------------
-              protocol key format     24 bytes, parity in low
-                                      bit of each
-
-              key-generation seed     21 bytes
-              length
-
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 28]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-                 des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
-              ------------------------------------------------
-              hash function           SHA-1
-
-              HMAC output size        160 bits
-
-              message block size      8 bytes
-
-              default string-to-key   empty string
-              params
-
-              encryption and          triple-DES encrypt and
-              decryption functions    decrypt, in outer-CBC
-                                      mode (cipher block size
-                                      8 octets)
-
-              key generation functions:
-
-              random-to-key           DES3random-to-key (see
-                                      below)
-
-              string-to-key           DES3string-to-key (see
-                                      below)
-
-   The des3-cbc-hmac-sha1-kd encryption type is assigned the value
-   sixteen (16).  The hmac-sha1-des3-kd checksum algorithm is assigned a
-   checksum type number of twelve (12).
-
-6.3.1.  Triple DES Key Production (random-to-key, string-to-key)
-
-   The 168 bits of random key data are converted to a protocol key value
-   as follows.  First, the 168 bits are divided into three groups of 56
-   bits, which are expanded individually into 64 bits as follows:
-
-   DES3random-to-key:
-         1  2  3  4  5  6  7  p
-         9 10 11 12 13 14 15  p
-        17 18 19 20 21 22 23  p
-        25 26 27 28 29 30 31  p
-        33 34 35 36 37 38 39  p
-        41 42 43 44 45 46 47  p
-        49 50 51 52 53 54 55  p
-        56 48 40 32 24 16  8  p
-
-   The "p" bits are parity bits computed over the data bits.  The output
-   of the three expansions, each corrected to avoid "weak" and "semi-
-   weak" keys as in section 6.2, are concatenated to form the protocol
-   key value.
-
-
-
-Raeburn                     Standards Track                    [Page 29]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   The string-to-key function is used to transform UTF-8 passwords into
-   DES3 keys.  The DES3 string-to-key function relies on the "N-fold"
-   algorithm and DK function, described in section 5.
-
-   The n-fold algorithm is applied to the password string concatenated
-   with a salt value.  For 3-key triple DES, the operation will involve
-   a 168-fold of the input password string, to generate an intermediate
-   key, from which the user's long-term key will be derived with the DK
-   function.  The DES3 string-to-key function is shown here in
-   pseudocode:
-
-         DES3string-to-key(passwordString, salt, params)
-             if (params != emptyString)
-              error("invalid params");
-             s = passwordString + salt
-             tmpKey = random-to-key(168-fold(s))
-             key = DK (tmpKey, KerberosConstant)
-
-   Weak key checking is performed in the random-to-key and DK
-   operations.  The KerberosConstant value is the byte string {0x6b 0x65
-   0x72 0x62 0x65 0x72 0x6f 0x73}.  These values correspond to the ASCII
-   encoding for the string "kerberos".
-
-7.  Use of Kerberos Encryption Outside This Specification
-
-   Several Kerberos-based application protocols and preauthentication
-   systems have been designed and deployed that perform encryption and
-   message integrity checks in various ways.  Although in some cases
-   there may be good reason for specifying these protocols in terms of
-   specific encryption or checksum algorithms, we anticipate that in
-   many cases this will not be true, and more generic approaches
-   independent of particular algorithms will be desirable.  Rather than
-   have each protocol designer reinvent schemes for protecting data,
-   using multiple keys, etc., we have attempted to present in this
-   section a general framework that should be sufficient not only for
-   the Kerberos protocol itself but also for many preauthentication
-   systems and application protocols, while trying to avoid some of the
-   assumptions that can work their way into such protocol designs.
-
-   Some problematic assumptions we've seen (and sometimes made) include
-   the following: a random bitstring is always valid as a key (not true
-   for DES keys with parity); the basic block encryption chaining mode
-   provides no integrity checking, or can easily be separated from such
-   checking (not true for many modes in development that do both
-   simultaneously); a checksum for a message always results in the same
-   value (not true if a confounder is incorporated); an initial vector
-   is used (may not be true if a block cipher in CBC mode is not in
-   use).
-
-
-
-Raeburn                     Standards Track                    [Page 30]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   Although such assumptions the may hold for any given set of
-   encryption and checksum algorithms, they may not be true of the next
-   algorithms to be defined, leaving the application protocol unable to
-   make use of those algorithms without updates to its specification.
-
-   The Kerberos protocol uses only the attributes and operations
-   described in sections 3 and 4.  Preauthentication systems and
-   application protocols making use of Kerberos are encouraged to use
-   them as well.  The specific key and string-to-key parameters should
-   generally be treated as opaque.  Although the string-to-key
-   parameters are manipulated as an octet string, the representation for
-   the specific key structure is implementation defined; it may not even
-   be a single object.
-
-   We don't recommend doing so, but some application protocols will
-   undoubtedly continue to use the key data directly, even if only in
-   some of the currently existing protocol specifications.  An
-   implementation intended to support general Kerberos applications may
-   therefore need to make the key data available, as well as the
-   attributes and operations described in sections 3 and 4 [8].
-
-8.  Assigned Numbers
-
-   The following encryption-type numbers are already assigned or
-   reserved for use in Kerberos and related protocols.
-
-      encryption type                etype      section or comment
-      -----------------------------------------------------------------
-      des-cbc-crc                        1             6.2.3
-      des-cbc-md4                        2             6.2.2
-      des-cbc-md5                        3             6.2.1
-      [reserved]                         4
-      des3-cbc-md5                       5
-      [reserved]                         6
-      des3-cbc-sha1                      7
-      dsaWithSHA1-CmsOID                 9           (pkinit)
-      md5WithRSAEncryption-CmsOID       10           (pkinit)
-      sha1WithRSAEncryption-CmsOID      11           (pkinit)
-      rc2CBC-EnvOID                     12           (pkinit)
-      rsaEncryption-EnvOID              13   (pkinit from PKCS#1 v1.5)
-      rsaES-OAEP-ENV-OID                14   (pkinit from PKCS#1 v2.0)
-      des-ede3-cbc-Env-OID              15           (pkinit)
-      des3-cbc-sha1-kd                  16              6.3
-      aes128-cts-hmac-sha1-96           17          [KRB5-AES]
-      aes256-cts-hmac-sha1-96           18          [KRB5-AES]
-      rc4-hmac                          23          (Microsoft)
-      rc4-hmac-exp                      24          (Microsoft)
-      subkey-keymaterial                65     (opaque; PacketCable)
-
-
-
-Raeburn                     Standards Track                    [Page 31]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   (The "des3-cbc-sha1" assignment is a deprecated version using no key
-   derivation.  It should not be confused with des3-cbc-sha1-kd.)
-
-   Several numbers have been reserved for use in encryption systems not
-   defined here.  Encryption-type numbers have unfortunately been
-   overloaded on occasion in Kerberos-related protocols, so some of the
-   reserved numbers do not and will not correspond to encryption systems
-   fitting the profile presented here.
-
-   The following checksum-type numbers are assigned or reserved.  As
-   with encryption-type numbers, some overloading of checksum numbers
-   has occurred.
-
-   Checksum type              sumtype        checksum         section or
-                                value            size         reference
-   ---------------------------------------------------------------------
-   CRC32                            1               4           6.1.3
-   rsa-md4                          2              16           6.1.2
-   rsa-md4-des                      3              24           6.2.5
-   des-mac                          4              16           6.2.7
-   des-mac-k                        5               8           6.2.8
-   rsa-md4-des-k                    6              16           6.2.6
-   rsa-md5                          7              16           6.1.1
-   rsa-md5-des                      8              24           6.2.4
-   rsa-md5-des3                     9              24             ??
-   sha1 (unkeyed)                  10              20             ??
-   hmac-sha1-des3-kd               12              20            6.3
-   hmac-sha1-des3                  13              20             ??
-   sha1 (unkeyed)                  14              20             ??
-   hmac-sha1-96-aes128             15              20         [KRB5-AES]
-   hmac-sha1-96-aes256             16              20         [KRB5-AES]
-   [reserved]                  0x8003               ?         [GSS-KRB5]
-
-   Encryption and checksum-type numbers are signed 32-bit values.  Zero
-   is invalid, and negative numbers are reserved for local use.  All
-   standardized values must be positive.
-
-9.  Implementation Notes
-
-   The "interface" described here is the minimal information that must
-   be defined to make a cryptosystem useful within Kerberos in an
-   interoperable fashion.  The use of functional notation used in some
-   places is not an attempt to define an API for cryptographic
-   functionality within Kerberos.  Actual implementations providing
-   clean APIs will probably make additional information available, that
-   could be derived from a specification written to the framework given
-   here.  For example, an application designer may wish to determine the
-   largest number of bytes that can be encrypted without overflowing a
-
-
-
-Raeburn                     Standards Track                    [Page 32]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   certain size output buffer or conversely, the maximum number of bytes
-   that might be obtained by decrypting a ciphertext message of a given
-   size.  (In fact, an implementation of the GSS-API Kerberos mechanism
-   [GSS-KRB5] will require some of these.)
-
-   The presence of a mechanism in this document should not be taken to
-   indicate that it must be implemented for compliance with any
-   specification; required mechanisms will be specified elsewhere.
-   Indeed, some of the mechanisms described here for backward
-   compatibility are now considered rather weak for protecting critical
-   data.
-
-10.  Security Considerations
-
-   Recent years have brought so many advancements in large-scale attacks
-   capability against DES that it is no longer considered a strong
-   encryption mechanism.  Triple-DES is generally preferred in its
-   place, despite its poorer performance.  See [ESP-DES] for a summary
-   of some of the potential attacks and [EFF-DES] for a detailed
-   discussion of the implementation of particular attacks.  However,
-   most Kerberos implementations still have DES as their primary
-   interoperable encryption type.
-
-   DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of
-   single-DES here avoids them.  However, DES also has 48 'possibly-
-   weak' keys [Schneier96] (note that the tables in many editions of the
-   reference contains errors) that are not avoided.
-
-   DES weak keys have the property that E1(E1(P)) = P (where E1 denotes
-   encryption of a single block with key 1).  DES semi-weak keys, or
-   "dual" keys, are pairs of keys with the property that E1(P) = D2(P),
-   and thus E2(E1(P)) = P.  Because of the use of CBC mode and the
-   leading random confounder, however, these properties are unlikely to
-   present a security problem.
-
-   Many of the choices concerning when to perform weak-key corrections
-   relate more to compatibility with existing implementations than to
-   any risk analysis.
-
-   Although checks are also done for the component DES keys in a
-   triple-DES key, the nature of the weak keys make it extremely
-   unlikely that they will weaken the triple-DES encryption.  It is only
-   slightly more likely than having the middle of the three sub-keys
-   match one of the other two, which effectively converts the encryption
-   to single-DES - a case we make no effort to avoid.
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 33]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   The true CRC-32 checksum is not collision-proof; an attacker could
-   use a probabilistic chosen-plaintext attack to generate a valid
-   message even if a confounder is used [SG92].  The use of collision-
-   proof checksums is of course recommended for environments where such
-   attacks represent a significant threat.  The "simplifications" (read:
-   bugs) introduced when CRC-32 was implemented for Kerberos cause
-   leading zeros effectively to be ignored, so messages differing only
-   in leading zero bits will have the same checksum.
-
-   [HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm.
-   Unlike [IPSEC-HMAC], the triple-DES specification here does not use
-   the suggested truncation of the HMAC output.  As pointed out in
-   [IPSEC-HMAC], SHA-1 was not developed for use as a keyed hash
-   function, which is a criterion of HMAC.  [HMAC-TEST] contains test
-   vectors for HMAC-SHA-1.
-
-   The mit_des_string_to_key function was originally constructed with
-   the assumption that all input would be ASCII; it ignores the top bit
-   of each input byte.  Folding with XOR is also not an especially good
-   mixing mechanism for preserving randomness.
-
-   The n-fold function used in the string-to-key operation for des3-
-   cbc-hmac-sha1-kd was designed to cause each bit of input to
-   contribute equally to the output.  It was not designed to maximize or
-   equally distribute randomness in the input, and conceivably
-   randomness may be lost in cases of partially structured input.  This
-   should only be an issue for highly structured passwords, however.
-
-   [RFC1851] discusses the relative strength of triple-DES encryption.
-   The relatively slow speed of triple-DES encryption may also be an
-   issue for some applications.
-
-   [Bellovin91] suggests that analyses of encryption schemes include a
-   model of an attacker capable of submitting known plaintexts to be
-   encrypted with an unknown key, as well as be able to perform many
-   types of operations on known protocol messages.  Recent experiences
-   with the chosen-plaintext attacks on Kerberos version 4 bear out the
-   value of this suggestion.
-
-   The use of unkeyed encrypted checksums, such as those used in the
-   single-DES cryptosystems specified in [Kerb1510], allows for cut-
-   and-paste attacks, especially if a confounder is not used.  In
-   addition, unkeyed encrypted checksums are vulnerable to chosen-
-   plaintext attacks: An attacker with access to an encryption oracle
-   can easily encrypt the required unkeyed checksum along with the
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 34]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   chosen plaintext. [Bellovin99]  These weaknesses, combined with a
-   common implementation design choice described below, allow for a
-   cross-protocol attack from version 4 to version 5.
-
-   The use of a random confounder is an important means to prevent an
-   attacker from making effective use of protocol exchanges as an
-   encryption oracle.  In Kerberos version 4, the encryption of constant
-   plaintext to constant ciphertext makes an effective encryption oracle
-   for an attacker.  The use of random confounders in [Kerb1510]
-   frustrates this sort of chosen-plaintext attack.
-
-   Using the same key for multiple purposes can enable or increase the
-   scope of chosen-plaintext attacks.  Some software that implements
-   both versions 4 and 5 of the Kerberos protocol uses the same keys for
-   both versions.  This enables the encryption oracle of version 4 to be
-   used to attack version 5.  Vulnerabilities to attacks such as this
-   cross-protocol attack make it unwise to use a key for multiple
-   purposes.
-
-   This document, like the Kerberos protocol, does not address limiting
-   the amount of data a key may be used with to a quantity based on the
-   robustness of the algorithm or size of the key.  It is assumed that
-   any defined algorithms and key sizes will be strong enough to support
-   very large amounts of data, or they will be deprecated once
-   significant attacks are known.
-
-   This document also places no bounds on the amount of data that can be
-   handled in various operations.  To avoid denial of service attacks,
-   implementations will probably seek to restrict message sizes at some
-   higher level.
-
-11.  IANA Considerations
-
-   Two registries for numeric values have been created: Kerberos
-   Encryption Type Numbers and Kerberos Checksum Type Numbers.  These
-   are signed values ranging from -2147483648 to 2147483647.  Positive
-   values should be assigned only for algorithms specified in accordance
-   with this specification for use with Kerberos or related protocols.
-   Negative values are for private use; local and experimental
-   algorithms should use these values.  Zero is reserved and may not be
-   assigned.
-
-   Positive encryption- and checksum-type numbers may be assigned
-   following either of two policies described in [BCP26].
-
-   Standards-track specifications may be assigned values under the
-   Standards Action policy.
-
-
-
-
-Raeburn                     Standards Track                    [Page 35]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   Specifications in non-standards track RFCs may be assigned values
-   after Expert Review.  A non-IETF specification may be assigned values
-   by publishing an Informational or standards-track RFC referencing the
-   external specification; that specification must be public and
-   published in some permanent record, much like the IETF RFCs.  It is
-   highly desirable, though not required, that the full specification be
-   published as an IETF RFC.
-
-   Smaller encryption type values should be used for IETF standards-
-   track mechanisms, and much higher values (16777216 and above) for
-   other mechanisms.  (Rationale: In the Kerberos ASN.1 encoding,
-   smaller numbers encode to smaller octet sequences, so this favors
-   standards-track mechanisms with slightly smaller messages.)  Aside
-   from that guideline, IANA may choose numbers as it sees fit.
-
-   Internet-Draft specifications should not include values for
-   encryption- and checksum-type numbers.  Instead, they should indicate
-   that values would be assigned by IANA when the document is approved
-   as an RFC.  For development and interoperability testing, values in
-   the private-use range (negative values) may be used but should not be
-   included in the draft specification.
-
-   Each registered value should have an associated unique reference
-   name.  The lists given in section 8 were used to create the initial
-   registry; they include reservations for specifications in progress in
-   parallel with this document, and certain other values believed to
-   already be in use.
-
-12.  Acknowledgements
-
-   This document is an extension of the encryption specification
-   included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much
-   of the text of the background, concepts, and DES specifications is
-   drawn directly from that document.
-
-   The abstract framework presented in this document was put together by
-   Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn,
-   and Tom Yu, and the details were refined several times based on
-   comments from John Brezak and others.
-
-   Marc Horowitz wrote the original specification of triple-DES and key
-   derivation in a pair of Internet-Drafts (under the names draft-
-   horowitz-key-derivation and draft-horowitz-kerb-key-derivation) that
-   were later folded into a draft revision of [Kerb1510], from which
-   this document was later split off.
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 36]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   Tom Yu provided the text describing the modifications to the standard
-   CRC algorithm as Kerberos implementations actually use it, and some
-   of the text in the Security Considerations section.
-
-   Miroslav Jurisic provided information for one of the UTF-8 test cases
-   for the string-to-key functions.
-
-   Marcus Watts noticed some errors in earlier versions and pointed out
-   that the simplified profile could easily be modified to support
-   cipher text stealing modes.
-
-   Simon Josefsson contributed some clarifications to the DES "CBC
-   checksum" and string-to-key and weak key descriptions, and some test
-   vectors.
-
-   Simon Josefsson, Louis LeVay, and others also caught some errors in
-   earlier versions of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 37]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-A.  Test Vectors
-
-   This section provides test vectors for various functions defined or
-   described in this document.  For convenience, most inputs are ASCII
-   strings, though some UTF-8 samples are provided for string-to-key
-   functions.  Keys and other binary data are specified as hexadecimal
-   strings.
-
-A.1.  n-fold
-
-   The n-fold function is defined in section 5.1.  As noted there, the
-   sample vector in the original paper defining the algorithm appears to
-   be incorrect.  Here are some test cases provided by Marc Horowitz and
-   Simon Josefsson:
-
-      64-fold("012345") =
-      64-fold(303132333435) = be072631276b1955
-
-      56-fold("password") =
-      56-fold(70617373776f7264) = 78a07b6caf85fa
-
-      64-fold("Rough Consensus, and Running Code") =
-      64-fold(526f75676820436f6e73656e7375732c20616e642052756e
-              6e696e6720436f6465) = bb6ed30870b7f0e0
-
-      168-fold("password") =
-      168-fold(70617373776f7264) =
-               59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
-
-      192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
-      192-fold(4d41535341434856534554545320494e5354495456544520
-               4f4620544543484e4f4c4f4759) =
-               db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
-
-      168-fold("Q") =
-      168-fold(51) =
-               518a54a2 15a8452a 518a54a2 15a8452a
-               518a54a2 15
-
-      168-fold("ba") =
-      168-fold(6261) =
-               fb25d531 ae897449 9f52fd92 ea9857c4
-               ba24cf29 7e
-
-   Here are some additional values corresponding to folded values of the
-   string "kerberos"; the 64-bit form is used in the des3 string-to-key
-   (section 6.3.1).
-
-
-
-
-Raeburn                     Standards Track                    [Page 38]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-      64-fold("kerberos") =
-               6b657262 65726f73
-      128-fold("kerberos") =
-               6b657262 65726f73 7b9b5b2b 93132b93
-      168-fold("kerberos") =
-               8372c236 344e5f15 50cd0747 e15d62ca
-               7a5a3bce a4
-      256-fold("kerberos") =
-               6b657262 65726f73 7b9b5b2b 93132b93
-               5c9bdcda d95c9899 c4cae4de e6d6cae4
-
-   Note that the initial octets exactly match the input string when the
-   output length is a multiple of the input length.
-
-A.2.  mit_des_string_to_key
-
-   The function mit_des_string_to_key is defined in section 6.2.  We
-   present here several test values, with some of the intermediate
-   results.  The fourth test demonstrates the use of UTF-8 with three
-   characters.  The last two tests are specifically constructed so as to
-   trigger the weak-key fixups for the intermediate key produced by
-   fan-folding; we have no test cases that cause such fixups for the
-   final key.
-
-UTF-8 encodings used in test vector:
-eszett    U+00DF   C3 9F   s-caron   U+0161    C5 A1
-c-acute   U+0107   C4 87   g-clef    U+1011E   F0 9D 84 9E
-
-Test vector:
-
-salt:        "ATHENA.MIT.EDUraeburn"
-                           415448454e412e4d49542e4544557261656275726e
-password:    "password"    70617373776f7264
-fan-fold result:           c01e38688ac86c2e
-intermediate key:          c11f38688ac86d2f
-DES key:                   cbc22fae235298e3
-
-salt:       "WHITEHOUSE.GOVdanny"
-                        5748495445484f5553452e474f5664616e6e79
-password:   "potatoe"   706f7461746f65
-fan-fold result:        a028944ee63c0416
-intermediate key:       a129944fe63d0416
-DES key:                df3d32a74fd92a01
-
-salt:      "EXAMPLE.COMpianist"  4558414D504C452E434F4D7069616E697374
-password:  g-clef (U+1011E)      f09d849e
-fan-fold result:                 3c4a262c18fab090
-intermediate key:                3d4a262c19fbb091
-
-
-
-Raeburn                     Standards Track                    [Page 39]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-DES key:                         4ffb26bab0cd9413
-
-salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107)
-                         415448454e412e4d49542e4544554a757269c5a169c487
-password:       eszett(U+00DF)
-                                c39f
-fan-fold result:b8f6c40e305afc9e
-intermediate key:               b9f7c40e315bfd9e
-DES key:                        62c81a5232b5e69d
-
-salt:       "AAAAAAAA"   4141414141414141
-password:   "11119999"   3131313139393939
-fan-fold result:         e0e0e0e0f0f0f0f0
-intermediate key:        e0e0e0e0f1f1f101
-DES key:                 984054d0f1a73e31
-
-salt:       "FFFFAAAA"   4646464641414141
-password:   "NNNN6666"   4e4e4e4e36363636
-fan-fold result:         1e1e1e1e0e0e0e0e
-intermediate key:        1f1f1f1f0e0e0efe
-DES key:                 c4bf6b25adf7a4f8
-
-   This trace provided by Simon Josefsson shows the intermediate
-   processing stages of one of the test inputs:
-
-      string_to_key (des-cbc-md5, string, salt)
-             ;; string:
-             ;; `password' (length 8 bytes)
-             ;; 70 61 73 73 77 6f 72 64
-             ;; salt:
-             ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
-             ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
-             ;; 65 62 75 72 6e
-      des_string_to_key (string, salt)
-             ;; String:
-             ;; `password' (length 8 bytes)
-             ;; 70 61 73 73 77 6f 72 64
-             ;; Salt:
-             ;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
-             ;; 41 54 48 45 4e 41 2e 4d  49 54 2e 45 44 55 72 61
-             ;; 65 62 75 72 6e
-      odd = 1;
-      s = string | salt;
-      tempstring = 0; /* 56-bit string */
-      pad(s); /* with nulls to 8 byte boundary */
-             ;; s = pad(string|salt):
-             ;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'
-             ;; (length 32 bytes)
-
-
-
-Raeburn                     Standards Track                    [Page 40]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-             ;; 70 61 73 73 77 6f 72 64  41 54 48 45 4e 41 2e 4d
-             ;; 49 54 2e 45 44 55 72 61  65 62 75 72 6e 00 00 00
-      for (8byteblock in s) {
-             ;; loop iteration 0
-             ;; 8byteblock:
-             ;; `password' (length 8 bytes)
-             ;; 70 61 73 73 77 6f 72 64
-             ;; 01110000 01100001 01110011  01110011 01110111 01101111
-             ;; 01110010 01100100
-      56bitstring = removeMSBits(8byteblock);
-             ;; 56bitstring:
-             ;; 1110000 1100001 1110011  1110011 1110111 1101111
-             ;; 1110010 1100100
-      if (odd == 0) reverse(56bitstring);    ;; odd=1
-      odd = ! odd
-      tempstring = tempstring XOR 56bitstring;
-             ;; tempstring
-             ;; 1110000 1100001 1110011  1110011 1110111 1101111
-             ;; 1110010 1100100
-
-      for (8byteblock in s) {
-             ;; loop iteration 1
-             ;; 8byteblock:
-             ;; `ATHENA.M' (length 8 bytes)
-             ;; 41 54 48 45 4e 41 2e 4d
-             ;; 01000001 01010100 01001000  01000101 01001110 01000001
-             ;; 00101110 01001101
-      56bitstring = removeMSBits(8byteblock);
-             ;; 56bitstring:
-             ;; 1000001 1010100 1001000  1000101 1001110 1000001
-             ;; 0101110 1001101
-      if (odd == 0) reverse(56bitstring);    ;; odd=0
-      reverse(56bitstring)
-             ;; 56bitstring after reverse
-             ;; 1011001 0111010 1000001  0111001 1010001 0001001
-             ;; 0010101 1000001
-      odd = ! odd
-      tempstring = tempstring XOR 56bitstring;
-             ;; tempstring
-             ;; 0101001 1011011 0110010  1001010 0100110 1100110
-             ;; 1100111 0100101
-
-      for (8byteblock in s) {
-             ;; loop iteration 2
-             ;; 8byteblock:
-             ;; `IT.EDUra' (length 8 bytes)
-             ;; 49 54 2e 45 44 55 72 61
-             ;; 01001001 01010100 00101110  01000101 01000100 01010101
-
-
-
-Raeburn                     Standards Track                    [Page 41]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-             ;; 01110010 01100001
-      56bitstring = removeMSBits(8byteblock);
-             ;; 56bitstring:
-             ;; 1001001 1010100 0101110  1000101 1000100 1010101
-             ;; 1110010 1100001
-      if (odd == 0) reverse(56bitstring);    ;; odd=1
-      odd = ! odd
-      tempstring = tempstring XOR 56bitstring;
-             ;; tempstring
-             ;; 1100000 0001111 0011100  0001111 1100010 0110011
-             ;; 0010101 1000100
-
-      for (8byteblock in s) {
-             ;; loop iteration 3
-             ;; 8byteblock:
-             ;; `eburn\x00\x00\x00' (length 8 bytes)
-             ;; 65 62 75 72 6e 00 00 00
-             ;; 01100101 01100010 01110101  01110010 01101110 00000000
-             ;; 00000000 00000000
-      56bitstring = removeMSBits(8byteblock);
-             ;; 56bitstring:
-             ;; 1100101 1100010 1110101  1110010 1101110 0000000
-             ;; 0000000 0000000
-      if (odd == 0) reverse(56bitstring);    ;; odd=0
-      reverse(56bitstring)
-             ;; 56bitstring after reverse
-             ;; 0000000 0000000 0000000  0111011 0100111 1010111
-             ;; 0100011 1010011
-      odd = ! odd
-      tempstring = tempstring XOR 56bitstring;
-             ;; tempstring
-             ;; 1100000 0001111 0011100  0110100 1000101 1100100
-             ;; 0110110 0010111
-
-      for (8byteblock in s) {
-      }
-             ;; for loop terminated
-
-      tempkey = key_correction(add_parity_bits(tempstring));
-             ;; tempkey
-             ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes)
-             ;; c1 1f 38 68 8a c8 6d 2f
-             ;; 11000001 00011111 00111000  01101000 10001010 11001000
-             ;; 01101101 00101111
-
-      key = key_correction(DES-CBC-check(s,tempkey));
-             ;; key
-             ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
-
-
-
-Raeburn                     Standards Track                    [Page 42]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-             ;; cb c2 2f ae 23 52 98 e3
-             ;; 11001011 11000010 00101111  10101110 00100011 01010010
-             ;; 10011000 11100011
-
-             ;; string_to_key key:
-             ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
-             ;; cb c2 2f ae 23 52 98 e3
-
-A.3.  DES3 DR and DK
-
-   These tests show the derived-random and derived-key values for the
-   des3-hmac-sha1-kd encryption scheme, using the DR and DK functions
-   defined in section 6.3.1.  The input keys were randomly generated;
-   the usage values are from this specification.
-
-   key:                 dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
-   usage:               0000000155
-   DR:                  935079d14490a75c3093c4a6e8c3b049c71e6ee705
-   DK:                  925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
-
-   key:                 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
-   usage:               00000001aa
-   DR:                  9f58e5a047d894101c469845d67ae3c5249ed812f2
-   DK:                  9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
-
-   key:                 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
-   usage:               0000000155
-   DR:                  12fff90c773f956d13fc2ca0d0840349dbd39908eb
-   DK:                  13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
-
-   key:                 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
-   usage:               00000001aa
-   DR:                  f8debf05b097e7dc0603686aca35d91fd9a5516a70
-   DK:                  f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
-
-   key:                 d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
-   usage:               6b65726265726f73 ("kerberos")
-   DR:                  2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
-   DK:                  2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
-
-   key:                 c1081649ada74362e6a1459d01dfd30d67c2234c940704da
-   usage:               0000000155
-   DR:                  348056ec98fcc517171d2b4d7a9493af482d999175
-   DK:                  348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
-
-   key:                 5d154af238f46713155719d55e2f1f790dd661f279a7917c
-   usage:               00000001aa
-   DR:                  a8818bc367dadacbe9a6c84627fb60c294b01215e5
-
-
-
-Raeburn                     Standards Track                    [Page 43]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   DK:                  a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
-
-   key:                 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
-   usage:               0000000155
-   DR:                  c813f88b3be2b2f75424ce9175fbc8483b88c8713a
-   DK:                  c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
-
-   key:                 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
-   usage:               00000001aa
-   DR:                  f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
-   DK:                  f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
-
-A.4.  DES3string_to_key
-
-   These are the keys generated for some of the above input strings for
-   triple-DES with key derivation as defined in section 6.3.1.
-
-   salt:   "ATHENA.MIT.EDUraeburn"
-   passwd: "password"
-   key:    850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
-
-   salt:   "WHITEHOUSE.GOVdanny"
-   passwd: "potatoe"
-   key:    dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
-
-   salt:   "EXAMPLE.COMbuckaroo"
-   passwd: "penny"
-   key:    6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
-
-   salt:   "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i"
-            + c-acute(U+0107)
-   passwd: eszett(U+00DF)
-   key:    16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
-
-   salt:   "EXAMPLE.COMpianist"
-   passwd: g-clef(U+1011E)
-   key:    85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
-
-A.5.  Modified CRC-32
-
-   Below are modified-CRC32 values for various ASCII and octet strings.
-   Only the printable ASCII characters are checksummed, without a C-
-   style trailing zero-valued octet.  The 32-bit modified CRC and the
-   sequence of output bytes as used in Kerberos are shown.  (The octet
-   values are separated here to emphasize that they are octet values and
-   not 32-bit numbers, which will be the most convenient form for
-   manipulation in some implementations.  The bit and byte order used
-
-
-
-
-Raeburn                     Standards Track                    [Page 44]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   internally for such a number is irrelevant; the octet sequence
-   generated is what is important.)
-
-   mod-crc-32("foo") =                                     33 bc 32 73
-   mod-crc-32("test0123456789") =                          d6 88 3e b8
-   mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") =   f7 80 41 e3
-   mod-crc-32(8000) =                                      4b 98 83 3b
-   mod-crc-32(0008) =                                      32 88 db 0e
-   mod-crc-32(0080) =                                      20 83 b8 ed
-   mod-crc-32(80) =                                        20 83 b8 ed
-   mod-crc-32(80000000) =                                  3b b6 59 ed
-   mod-crc-32(00000001) =                                  96 30 07 77
-
-B.  Significant Changes from RFC 1510
-
-   The encryption and checksum mechanism profiles are new.  The old
-   specification defined a few operations for various mechanisms but
-   didn't outline what abstract properties should be required of new
-   mechanisms, or how to ensure that a mechanism specification is
-   complete enough for interoperability between implementations.  The
-   new profiles differ from the old specification in a few ways:
-
-      Some message definitions in [Kerb1510] could be read as permitting
-      the initial vector to be specified by the application; the text
-      was too vague.  It is explicitly not permitted in this
-      specification.  Some encryption algorithms may not use
-      initialization vectors, so relying on chosen, secret
-      initialization vectors for security is unwise.  Also, the
-      prepended confounder in the existing algorithms is roughly
-      equivalent to a per-message initialization vector that is revealed
-      in encrypted form.  However, carrying state across from one
-      encryption to another is explicitly permitted through the opaque
-      "cipher state" object.
-
-      The use of key derivation is new.
-
-      Several new methods are introduced, including generation of a key
-      in wire-protocol format from random input data.
-
-      The means for influencing the string-to-key algorithm are laid out
-      more clearly.
-
-   Triple-DES support is new.
-
-   The pseudo-random function is new.
-
-   The des-cbc-crc, DES string-to-key and CRC descriptions have been
-   updated to align them with existing implementations.
-
-
-
-Raeburn                     Standards Track                    [Page 45]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   [Kerb1510] did not indicate what character set or encoding might be
-   used for pass phrases and salts.
-
-   In [Kerb1510], key types, encryption algorithms, and checksum
-   algorithms were only loosely associated, and the association was not
-   well described.  In this specification, key types and encryption
-   algorithms have a one-to-one correspondence, and associations between
-   encryption and checksum algorithms are described so that checksums
-   can be computed given negotiated keys, without requiring further
-   negotiation for checksum types.
-
-Notes
-
-   [1] Although Message Authentication Code (MAC) or Message Integrity
-       Check (MIC) would be more appropriate terms for many of the uses
-       in this document, we continue to use the term checksum for
-       historical reasons.
-
-   [2] Extending CBC mode across messages would be one obvious example
-       of this chaining.  Another might be the use of counter mode, with
-       a counter randomly initialized and attached to the ciphertext; a
-       second message could continue incrementing the counter when
-       chaining the cipher state, thus avoiding having to transmit
-       another counter value.  However, this chaining is only useful for
-       uninterrupted, ordered sequences of messages.
-
-   [3] In the case of Kerberos, the encrypted objects will generally be
-       ASN.1 DER encodings, which contain indications of their length in
-       the first few octets.
-
-   [4] As of the time of this writing, new modes of operation have been
-       proposed, some of which may permit encryption and integrity
-       protection simultaneously.  After some of these proposals have
-       been subjected to adequate analysis, we may wish to formulate a
-       new simplified profile based on one of them.
-
-   [5] It should be noted that the sample vector in appendix B.2 of the
-       original paper appears to be incorrect.  Two independent
-       implementations from the specification (one in C by Marc
-       Horowitz, and another in Scheme by Bill Sommerfeld) agree on a
-       value different from that in [Blumenthal96].
-
-   [6] For example, in MIT's implementation of [Kerb1510], the rsa-md5
-       unkeyed checksum of application data may be included in an
-       authenticator encrypted in a service's key.
-
-   [7] Using a variant of the key limits the use of a key to a
-       particular function, separating the functions of generating a
-
-
-
-Raeburn                     Standards Track                    [Page 46]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-       checksum from other encryption performed using the session key.
-       The constant 0xF0F0F0F0F0F0F0F0 was chosen because it maintains
-       key parity.  The properties of DES precluded the use of the
-       complement.  The same constant is used for similar purpose in the
-       Message Integrity Check in the Privacy Enhanced Mail standard.
-
-   [8] Perhaps one of the more common reasons for directly performing
-       encryption is direct control over the negotiation and to select a
-       "sufficiently strong" encryption algorithm (whatever that means
-       in the context of a given application).  Although Kerberos
-       directly provides no direct facility for negotiating encryption
-       types between the application client and server, there are other
-       means to accomplish similar goals (for example, requesting only
-       "strong" session key types from the KDC, and assuming that the
-       type actually returned by the KDC will be understood and
-       supported by the application server).
-
-Normative References
-
-   [BCP26]        Narten, T. and H. Alvestrand, "Guidelines for Writing
-                  an IANA Considerations Section in RFCs", BCP 26, RFC
-                  2434, October 1998.
-
-   [Bellare98]    Bellare, M., Desai, A., Pointcheval, D., and P.
-                  Rogaway, "Relations Among Notions of Security for
-                  Public-Key Encryption Schemes".  Extended abstract
-                  published in Advances in Cryptology-Crypto 98
-                  Proceedings, Lecture Notes in Computer Science Vol.
-                  1462, H. Krawcyzk ed., Springer-Verlag, 1998.
-
-   [Blumenthal96] Blumenthal, U. and S. Bellovin, "A Better Key Schedule
-                  for DES-Like Ciphers", Proceedings of PRAGOCRYPT '96,
-                  1996.
-
-   [CRC]          International Organization for Standardization, "ISO
-                  Information Processing Systems - Data Communication -
-                  High-Level Data Link Control Procedure - Frame
-                  Structure," IS 3309, 3rd Edition, October 1984.
-
-   [DES77]        National Bureau of Standards, U.S. Department of
-                  Commerce, "Data Encryption Standard," Federal
-                  Information Processing Standards Publication 46,
-                  Washington, DC, 1977.
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 47]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   [DESI81]       National Bureau of Standards, U.S. Department of
-                  Commerce, "Guidelines for implementing and using NBS
-                  Data Encryption Standard," Federal Information
-                  Processing Standards Publication 74, Washington, DC,
-                  1981.
-
-   [DESM80]       National Bureau of Standards, U.S. Department of
-                  Commerce, "DES Modes of Operation," Federal
-                  Information Processing Standards Publication 81,
-                  Springfield, VA, December 1980.
-
-   [Dolev91]      Dolev, D., Dwork, C., and M. Naor, "Non-malleable
-                  cryptography", Proceedings of the 23rd Annual
-                  Symposium on Theory of Computing, ACM, 1991.
-
-   [HMAC]         Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
-                  Keyed-Hashing for Message Authentication", RFC 2104,
-                  February 1997.
-
-   [KRB5-AES]     Raeburn, K., "Advanced Encryption Standard (AES)
-                  Encryption for Kerberos 5", RFC 3962, February 2005.
-
-   [MD4-92]       Rivest, R., "The MD4 Message-Digest Algorithm", RFC
-                  1320, April 1992.
-
-   [MD5-92]       Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
-                  1321, April 1992.
-
-   [SG92]         Stubblebine, S. and V. D. Gligor, "On Message
-                  Integrity in Cryptographic Protocols," in Proceedings
-                  of the IEEE Symposium on Research in Security and
-                  Privacy, Oakland, California, May 1992.
-
-Informative References
-
-   [Bellovin91]   Bellovin, S. M. and M. Merrit, "Limitations of the
-                  Kerberos Authentication System", in Proceedings of the
-                  Winter 1991 Usenix Security Conference, January, 1991.
-
-   [Bellovin99]   Bellovin, S. M. and D. Atkins, private communications,
-                  1999.
-
-   [EFF-DES]      Electronic Frontier Foundation, "Cracking DES: Secrets
-                  of Encryption Research, Wiretap Politics, and Chip
-                  Design", O'Reilly & Associates, Inc., May 1998.
-
-   [ESP-DES]      Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
-                  Algorithm With Explicit IV", RFC 2405, November 1998.
-
-
-
-Raeburn                     Standards Track                    [Page 48]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-   [GSS-KRB5]     Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-                  RFC 1964, June 1996.
-
-   [HMAC-TEST]    Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
-                  HMAC-SHA-1", RFC 2202, September 1997.
-
-   [IPSEC-HMAC]   Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
-                  within ESP and AH", RFC 2404, November 1998.
-
-   [Kerb]         Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-                  Kerberos Network Authentication Service (V5)", Work in
-                  Progress, September 2004.
-
-   [Kerb1510]     Kohl, J. and C. Neuman, "The Kerberos Network
-                  Authentication Service (V5)", RFC 1510, September
-                  1993.
-
-   [RC5]          Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-
-                  CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October
-                  1996.
-
-   [RFC1851]      Karn, P., Metzger, P., and W. Simpson, "The ESP Triple
-                  DES Transform", RFC 1851, September 1995.
-
-   [Schneier96]   Schneier, B., "Applied Cryptography Second Edition",
-                  John Wiley & Sons, New York, NY, 1996.  ISBN 0-471-
-                  12845-7.
-
-Editor's Address
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-
-   EMail: raeburn@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 49]
-
-RFC 3961         Encryption and Checksum Specifications    February 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the IETF's procedures with respect to rights in IETF Documents can
-   be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 50]
-
diff --git a/doc/standardisation/rfc3962.txt b/doc/standardisation/rfc3962.txt
deleted file mode 100644
index 762beedbd..000000000
--- a/doc/standardisation/rfc3962.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         K. Raeburn
-Request for Comments: 3962                                           MIT
-Category: Standards Track                                  February 2005
-
-
-      Advanced Encryption Standard (AES) Encryption 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
-
-   The United States National Institute of Standards and Technology
-   (NIST) has chosen a new Advanced Encryption Standard (AES), which is
-   significantly faster and (it is believed) more secure than the old
-   Data Encryption Standard (DES) algorithm.  This document is a
-   specification for the addition of this algorithm to the Kerberos
-   cryptosystem suite.
-
-1.  Introduction
-
-   This document defines encryption key and checksum types for Kerberos
-   5 using the AES algorithm recently chosen by NIST.  These new types
-   support 128-bit block encryption and key sizes of 128 or 256 bits.
-
-   Using the "simplified profile" of [KCRYPTO], we can define a pair of
-   encryption and checksum schemes.  AES is used with ciphertext
-   stealing to avoid message expansion, and SHA-1 [SHA1] is the
-   associated checksum function.
-
-2.  Conventions used in this Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in BCP 14, RFC 2119
-   [KEYWORDS].
-
-
-
-
-
-
-Raeburn                     Standards Track                     [Page 1]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-3.  Protocol Key Representation
-
-   The profile in [KCRYPTO] treats keys and random octet strings as
-   conceptually different.  But since the AES key space is dense, we can
-   use any bit string of appropriate length as a key.  We use the byte
-   representation for the key described in [AES], where the first bit of
-   the bit string is the high bit of the first byte of the byte string
-   (octet string) representation.
-
-4.  Key Generation from Pass Phrases or Random Data
-
-   Given the above format for keys, we can generate keys from the
-   appropriate amounts of random data (128 or 256 bits) by simply
-   copying the input string.
-
-   To generate an encryption key from a pass phrase and salt string, we
-   use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters
-   indicated below, to generate an intermediate key (of the same length
-   as the desired final key), which is then passed into the DK function
-   with the 8-octet ASCII string "kerberos" as is done for des3-cbc-
-   hmac-sha1-kd in [KCRYPTO].  (In [KCRYPTO] terms, the PBKDF2 function
-   produces a "random octet string", hence the application of the
-   random-to-key function even though it's effectively a simple identity
-   operation.)  The resulting key is the user's long-term key for use
-   with the encryption algorithm in question.
-
-   tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
-   key = DK(tkey, "kerberos")
-
-   The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the
-   passphrase and salt, as described in Appendix B.1 to PKCS#5.
-
-   The number of iterations is specified by the string-to-key parameters
-   supplied.  The parameter string is four octets indicating an unsigned
-   number in big-endian order.  This is the number of iterations to be
-   performed.  If the value is 00 00 00 00, the number of iterations to
-   be performed is 4,294,967,296 (2**32).  (Thus the minimum expressible
-   iteration count is 1.)
-
-   For environments where slower hardware is the norm, implementations
-   of protocols such as Kerberos may wish to limit the number of
-   iterations to prevent a spoofed response supplied by an attacker from
-   consuming lots of client-side CPU time; if such a limit is
-   implemented, it SHOULD be no less than 50,000.  Even for environments
-   with fast hardware, 4 billion iterations is likely to take a fairly
-   long time; much larger bounds might still be enforced, and it might
-   be wise for implementations to permit interruption of this operation
-   by the user if the environment allows for it.
-
-
-
-Raeburn                     Standards Track                     [Page 2]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-   If the string-to-key parameters are not supplied, the value used is
-   00 00 10 00 (decimal 4,096, indicating 4,096 iterations).
-
-   Note that this is not a requirement, nor even a recommendation, for
-   this value to be used in "optimistic preauthentication" (e.g.,
-   attempting timestamp-based preauthentication using the user's long-
-   term key without having first communicated with the KDC) in the
-   absence of additional information, or as a default value for sites to
-   use for their principals' long-term keys in their Kerberos database.
-   It is simply the interpretation of the absence of the string-to-key
-   parameter field when the KDC has had an opportunity to provide it.
-
-   Sample test vectors are given in Appendix B.
-
-5.  Ciphertext Stealing
-
-   Cipher block chaining is used to encrypt messages, with the initial
-   vector stored in the cipher state.  Unlike previous Kerberos
-   cryptosystems, we use ciphertext stealing to handle the possibly
-   partial final block of the message.
-
-   Ciphertext stealing is described on pages 195-196 of [AC], and
-   section 8 of [RC5]; it has the advantage that no message expansion is
-   done during encryption of messages of arbitrary sizes as is typically
-   done in CBC mode with padding.  Some errata for [RC5] are listed in
-   Appendix A and are considered part of the ciphertext stealing
-   technique as used here.
-
-   Ciphertext stealing, as defined in [RC5], assumes that more than one
-   block of plain text is available.  If exactly one block is to be
-   encrypted, that block is simply encrypted with AES (also known as ECB
-   mode).  Input smaller than one block is padded at the end to one
-   block; the values of the padding bits are unspecified.
-   (Implementations MAY use all-zero padding, but protocols MUST NOT
-   rely on the result being deterministic.  Implementations MAY use
-   random padding, but protocols MUST NOT rely on the result not being
-   deterministic.  Note that in most cases, the Kerberos encryption
-   profile will add a random confounder independent of this padding.)
-
-   For consistency, ciphertext stealing is always used for the last two
-   blocks of the data to be encrypted, as in [RC5].  If the data length
-   is a multiple of the block size, this is equivalent to plain CBC mode
-   with the last two ciphertext blocks swapped.
-
-   A test vector is given in Appendix B.
-
-
-
-
-
-
-Raeburn                     Standards Track                     [Page 3]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-   The initial vector carried out from one encryption for use in a
-   subsequent encryption is the next-to-last block of the encryption
-   output; this is the encrypted form of the last plaintext block.  When
-   decrypting, the next-to-last block of the supplied ciphertext is
-   carried forward as the next initial vector.  If only one ciphertext
-   block is available (decrypting one block, or encrypting one block or
-   less), then that one block is carried out instead.
-
-6.  Kerberos Algorithm Profile Parameters
-
-   This is a summary of the parameters to be used with the simplified
-   algorithm profile described in [KCRYPTO]:
-
-  +--------------------------------------------------------------------+
-  |               protocol key format        128- or 256-bit string    |
-  |                                                                    |
-  |            string-to-key function        PBKDF2+DK with variable   |
-  |                                          iteration count (see      |
-  |                                          above)                    |
-  |                                                                    |
-  |  default string-to-key parameters        00 00 10 00               |
-  |                                                                    |
-  |        key-generation seed length        key size                  |
-  |                                                                    |
-  |            random-to-key function        identity function         |
-  |                                                                    |
-  |                  hash function, H        SHA-1                     |
-  |                                                                    |
-  |               HMAC output size, h        12 octets (96 bits)       |
-  |                                                                    |
-  |             message block size, m        1 octet                   |
-  |                                                                    |
-  |  encryption/decryption functions,        AES in CBC-CTS mode       |
-  |  E and D                                 (cipher block size 16     |
-  |                                          octets), with next-to-    |
-  |                                          last block (last block    |
-  |                                          if only one) as CBC-style |
-  |                                          ivec                      |
-  +--------------------------------------------------------------------+
-
-   Using this profile with each key size gives us two each of encryption
-   and checksum algorithm definitions.
-
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                     [Page 4]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-7.  Assigned Numbers
-
-   The following encryption type numbers are assigned:
-
-  +--------------------------------------------------------------------+
-  |                         encryption types                           |
-  +--------------------------------------------------------------------+
-  |         type name                  etype value          key size   |
-  +--------------------------------------------------------------------+
-  |   aes128-cts-hmac-sha1-96              17                 128      |
-  |   aes256-cts-hmac-sha1-96              18                 256      |
-  +--------------------------------------------------------------------+
-
-   The following checksum type numbers are assigned:
-
-  +--------------------------------------------------------------------+
-  |                          checksum types                            |
-  +--------------------------------------------------------------------+
-  |        type name                 sumtype value           length    |
-  +--------------------------------------------------------------------+
-  |    hmac-sha1-96-aes128                15                   96      |
-  |    hmac-sha1-96-aes256                16                   96      |
-  +--------------------------------------------------------------------+
-
-   These checksum types will be used with the corresponding encryption
-   types defined above.
-
-8.  Security Considerations
-
-   This new algorithm has not been around long enough to receive the
-   decades of intense analysis that DES has received.  It is possible
-   that some weakness exists that has not been found by the
-   cryptographers analyzing these algorithms before and during the AES
-   selection process.
-
-   The use of the HMAC function has drawbacks for certain pass phrase
-   lengths.  For example, a pass phrase longer than the hash function
-   block size (64 bytes, for SHA-1) is hashed to a smaller size (20
-   bytes) before applying the main HMAC algorithm.  However, entropy is
-   generally sparse in pass phrases, especially in long ones, so this
-   may not be a problem in the rare cases of users with long pass
-   phrases.
-
-   Also, generating a 256-bit key from a pass phrase of any length may
-   be deceptive, as the effective entropy in pass-phrase-derived key
-   cannot be nearly that large given the properties of the string-to-key
-   function described here.
-
-
-
-
-Raeburn                     Standards Track                     [Page 5]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-   The iteration count in PBKDF2 appears to be useful primarily as a
-   constant multiplier for the amount of work required for an attacker
-   using brute-force methods.  Unfortunately, it also multiplies, by the
-   same amount, the work needed by a legitimate user with a valid
-   password.  Thus the work factor imposed on an attacker (who may have
-   many powerful workstations at his disposal) must be balanced against
-   the work factor imposed on the legitimate user (who may have a PDA or
-   cell phone); the available computing power on either side increases
-   as time goes on, as well.  A better way to deal with the brute-force
-   attack is through preauthentication mechanisms that provide better
-   protection of the user's long-term key.  Use of such mechanisms is
-   out of the scope of this document.
-
-   If a site does wish to use this means of protection against a brute-
-   force attack, the iteration count should be chosen based on the
-   facilities available to both attacker and legitimate user, and the
-   amount of work the attacker should be required to perform to acquire
-   the key or password.
-
-   As an example:
-
-      The author's tests on a 2GHz Pentium 4 system indicated that in
-      one second, nearly 90,000 iterations could be done, producing a
-      256-bit key.  This was using the SHA-1 assembly implementation
-      from OpenSSL, and a pre-release version of the PBKDF2 code for
-      MIT's Kerberos package, on a single system.  No attempt was made
-      to do multiple hashes in parallel, so we assume an attacker doing
-      so can probably do at least 100,000 iterations per second --
-      rounded up to 2**17, for ease of calculation.  For simplicity, we
-      also assume the final AES encryption step costs nothing.
-
-      Paul Leach estimates [LEACH] that a password-cracking dictionary
-      may have on the order of 2**21 entries, with capitalization,
-      punctuation, and other variations contributing perhaps a factor of
-      2**11, giving a ballpark estimate of 2**32.
-
-      Thus, for a known iteration count N and a known salt string, an
-      attacker with some number of computers comparable to the author's
-      would need roughly N*2**15 CPU seconds to convert the entire
-      dictionary plus variations into keys.
-
-      An attacker using a dozen such computers for a month would have
-      roughly 2**25 CPU seconds available.  So using 2**12 (4,096)
-      iterations would mean an attacker with a dozen such computers
-      dedicated to a brute-force attack against a single key (actually,
-      any password-derived keys sharing the same salt and iteration
-
-
-
-
-
-Raeburn                     Standards Track                     [Page 6]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-      count) would process all the variations of the dictionary entries
-      in four months and, on average, would likely find the user's
-      password in two months.
-
-      Thus, if this form of attack is of concern, users should be
-      required to change their passwords every few months, and an
-      iteration count a few orders of magnitude higher should be chosen.
-      Perhaps several orders of magnitude, as many users will tend to
-      use the shorter and simpler passwords (to the extent they can,
-      given a site's password quality checks) that the attacker would
-      likely try first.
-
-      Since this estimate is based on currently available CPU power, the
-      iteration counts used for this mode of defense should be increased
-      over time, at perhaps 40%-60% each year or so.
-
-      Note that if the attacker has a large amount of storage available,
-      intermediate results could be cached, saving a lot of work for the
-      next attack with the same salt and a greater number of iterations
-      than had been run at the point where the intermediate results were
-      saved.  Thus, it would be wise to generate a new random salt
-      string when passwords are changed.  The default salt string,
-      derived from the principal name, only protects against the use of
-      one dictionary of keys against multiple users.
-
-   If the PBKDF2 iteration count can be spoofed by an intruder on the
-   network, and the limit on the accepted iteration count is very high,
-   the intruder may be able to introduce a form of denial of service
-   attack against the client by sending a very high iteration count,
-   causing the client to spend a great deal of CPU time computing an
-   incorrect key.
-
-   An intruder spoofing the KDC reply, providing a low iteration count
-   and reading the client's reply from the network, may be able to
-   reduce the work needed in the brute-force attack outlined above.
-   Thus, implementations may seek to enforce lower bounds on the number
-   of iterations that will be used.
-
-   Since threat models and typical end-user equipment will vary widely
-   from site to site, allowing site-specific configuration of such
-   bounds is recommended.
-
-   Any benefit against other attacks specific to the HMAC or SHA-1
-   algorithms is probably achieved with a fairly small number of
-   iterations.
-
-
-
-
-
-
-Raeburn                     Standards Track                     [Page 7]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-   In the "optimistic preauthentication" case mentioned in section 3,
-   the client may attempt to produce a key without first communicating
-   with the KDC.  If the client has no additional information, it can
-   only guess as to the iteration count to be used.  Even such
-   heuristics as "iteration count X was used to acquire tickets for the
-   same principal only N hours ago" can be wrong.  Given the
-   recommendation above for increasing the iteration counts used over
-   time, it is impossible to recommend any specific default value for
-   this case; allowing site-local configuration is recommended.  (If the
-   lower and upper bound checks described above are implemented, the
-   default count for optimistic preauthentication should be between
-   those bounds.)
-
-   Ciphertext stealing mode, as it requires no additional padding in
-   most cases, will reveal the exact length of each message being
-   encrypted rather than merely bounding it to a small range of possible
-   lengths as in CBC mode.  Such obfuscation should not be relied upon
-   at higher levels in any case; if the length must be obscured from an
-   outside observer, this should be done by intentionally varying the
-   length of the message to be encrypted.
-
-9.  IANA Considerations
-
-   Kerberos encryption and checksum type values used in section 7 were
-   previously reserved in [KCRYPTO] for the mechanisms defined in this
-   document.  The registries have been updated to list this document as
-   the reference.
-
-10.  Acknowledgements
-
-   Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul
-   Leach, Marcus Watts, Larry Zhu, and others for feedback on earlier
-   versions of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                     [Page 8]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-A.  Errata for RFC 2040 Section 8
-
-   (Copied from the RFC Editor's errata web site on July 8, 2004.)
-
-   Reported By: Bob Baldwin; baldwin@plusfive.com
-   Date: Fri, 26 Mar 2004 06:49:02 -0800
-
-   In Section 8, Description of RC5-CTS, of the encryption method,
-   it says:
-
-       1. Exclusive-or Pn-1 with the previous ciphertext
-          block, Cn-2, to create Xn-1.
-
-   It should say:
-
-       1. Exclusive-or Pn-1 with the previous ciphertext
-          block, Cn-2, to create Xn-1.  For short messages where
-          Cn-2 does not exist, use IV.
-
-   Reported By: Bob Baldwin; baldwin@plusfive.com
-   Date: Mon, 22 Mar 2004 20:26:40 -0800
-
-   In Section 8, first paragraph, second sentence says:
-
-       This mode handles any length of plaintext and produces ciphertext
-       whose length matches the plaintext length.
-
-   In Section 8, first paragraph, second sentence should read:
-
-       This mode handles any length of plaintext longer than one
-       block and produces ciphertext whose length matches the
-       plaintext length.
-
-   In Section 8, step 6 of the decryption method says:
-
-       6. Decrypt En to create Pn-1.
-
-   In Section 8, step 6 of the decryption method should read:
-
-       6. Decrypt En and exclusive-or with Cn-2 to create Pn-1.
-          For short messages where Cn-2 does not exist, use the IV.
-
-
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                     [Page 9]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-B.  Sample Test Vectors
-
-   Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are
-   included below.
-
-   Iteration count = 1
-   Pass phrase = "password"
-   Salt = "ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
-   128-bit AES key:
-       42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15
-   256-bit PBKDF2 output:
-       cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15
-       0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37
-   256-bit AES key:
-       fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b
-       bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61
-
-   Iteration count = 2
-   Pass phrase = "password"
-   Salt="ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
-   128-bit AES key:
-       c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13
-   256-bit PBKDF2 output:
-       01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d
-       a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86
-   256-bit AES key:
-       a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61
-       02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff
-
-   Iteration count = 1200
-   Pass phrase = "password"
-   Salt = "ATHENA.MIT.EDUraeburn"
-   128-bit PBKDF2 output:
-       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
-   128-bit AES key:
-       4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a
-   256-bit PBKDF2 output:
-       5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b
-       a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13
-   256-bit AES key:
-       55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7
-       54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 10]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-   Iteration count = 5
-   Pass phrase = "password"
-   Salt=0x1234567878563412
-   128-bit PBKDF2 output:
-       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
-   128-bit AES key:
-       e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e
-   256-bit PBKDF2 output:
-       d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49
-       3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee
-   256-bit AES key:
-       97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c
-       ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31
-   (This test is based on values given in [PECMS].)
-
-   Iteration count = 1200
-   Pass phrase = (64 characters)
-     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
-   Salt="pass phrase equals block size"
-   128-bit PBKDF2 output:
-       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
-   128-bit AES key:
-       59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed
-   256-bit PBKDF2 output:
-       13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9
-       c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1
-   256-bit AES key:
-       89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0
-       56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34
-
-   Iteration count = 1200
-   Pass phrase = (65 characters)
-     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
-   Salt = "pass phrase exceeds block size"
-   128-bit PBKDF2 output:
-       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
-   128-bit AES key:
-       cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d
-   256-bit PBKDF2 output:
-       9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61
-       1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a
-   256-bit AES key:
-       d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2
-       14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 11]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-   Iteration count = 50
-   Pass phrase = g-clef (0xf09d849e)
-   Salt = "EXAMPLE.COMpianist"
-   128-bit PBKDF2 output:
-       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
-   128-bit AES key:
-       f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5
-   256-bit PBKDF2 output:
-       6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39
-       e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52
-   256-bit AES key:
-       4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c
-       57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e
-
-   Some test vectors for CBC with ciphertext stealing, using an initial
-   vector of all-zero.
-
-   AES 128-bit key:
-     0000:  63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69
-
-   IV:
-     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-   Input:
-     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-     0010:  20
-   Output:
-     0000:  c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
-     0010:  97
-   Next IV:
-     0000:  c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
-
-   IV:
-     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-   Input:
-     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20
-   Output:
-     0000:  fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
-     0010:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5
-   Next IV:
-     0000:  fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
-
-
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 12]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-   IV:
-     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-   Input:
-     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-   Output:
-     0000:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-     0010:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-   Next IV:
-     0000:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-
-   IV:
-     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-   Input:
-     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-     0020:  68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c
-   Output:
-     0000:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-     0010:  b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
-     0020:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5
-   Next IV:
-     0000:  b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
-
-   IV:
-     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-   Input:
-     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-     0020:  68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
-   Output:
-     0000:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-     0010:  9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
-     0020:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-   Next IV:
-     0000:  9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 13]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-   IV:
-     0000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-   Input:
-     0000:  49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65
-     0010:  20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43
-     0020:  68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20
-     0030:  61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e
-   Output:
-     0000:  97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84
-     0010:  39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
-     0020:  48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
-     0030:  9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
-   Next IV:
-     0000:  48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
-
-Normative References
-
-   [AC]       Schneier, B., "Applied Cryptography", second edition, John
-              Wiley and Sons, New York, 1996.
-
-   [AES]      National Institute of Standards and Technology, U.S.
-              Department of Commerce, "Advanced Encryption Standard",
-              Federal Information Processing Standards Publication 197,
-              Washington, DC, November 2001.
-
-   [KCRYPTO]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [PKCS5]    Kaliski, B., "PKCS #5: Password-Based Cryptography
-              Specification Version 2.0", RFC 2898, September 2000.
-
-   [RC5]      Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad,
-              and RC5-CTS Algorithms", RFC 2040, October 1996.
-
-   [SHA1]     National Institute of Standards and Technology, U.S.
-              Department of Commerce, "Secure Hash Standard", Federal
-              Information Processing Standards Publication 180-1,
-              Washington, DC, April 1995.
-
-
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 14]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-Informative References
-
-   [LEACH]    Leach, P., email to IETF Kerberos working group mailing
-              list, 5 May 2003, ftp://ftp.ietf.org/ietf-mail-
-              archive/krb-wg/2003-05.mail.
-
-   [PECMS]    Gutmann, P., "Password-based Encryption for CMS", RFC
-              3211, December 2001.
-
-Author's Address
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-
-   EMail: raeburn@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 15]
-
-RFC 3962             AES Encryption for Kerberos 5         February 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the IETF's procedures with respect to rights in IETF Documents can
-   be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Raeburn                     Standards Track                    [Page 16]
-
diff --git a/doc/standardisation/rfc4120.txt b/doc/standardisation/rfc4120.txt
deleted file mode 100644
index e2816aff2..000000000
--- a/doc/standardisation/rfc4120.txt
+++ /dev/null
@@ -1,7731 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          C. Neuman
-Request for Comments: 4120                                       USC-ISI
-Obsoletes: 1510                                                    T. Yu
-Category: Standards Track                                     S. Hartman
-                                                              K. Raeburn
-                                                                     MIT
-                                                               July 2005
-
-
-            The Kerberos Network Authentication Service (V5)
-
-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 provides an overview and specification of Version 5 of
-   the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects
-   of the protocol and its intended use that require more detailed or
-   clearer explanation than was provided in RFC 1510.  This document is
-   intended to provide a detailed description of the protocol, suitable
-   for implementation, together with descriptions of the appropriate use
-   of protocol messages and fields within those messages.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Neuman, et al.              Standards Track                     [Page 1]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-Table of Contents
-
-   1. Introduction ....................................................5
-      1.1. The Kerberos Protocol ......................................6
-      1.2. Cross-Realm Operation ......................................8
-      1.3. Choosing a Principal with Which to Communicate .............9
-      1.4. Authorization .............................................10
-      1.5. Extending Kerberos without Breaking Interoperability ......11
-           1.5.1. Compatibility with RFC 1510 ........................11
-           1.5.2. Sending Extensible Messages ........................12
-      1.6. Environmental Assumptions .................................12
-      1.7. Glossary of Terms .........................................13
-   2. Ticket Flag Uses and Requests ..................................16
-      2.1. Initial, Pre-authenticated, and
-           Hardware-Authenticated Tickets ............................17
-      2.2. Invalid Tickets ...........................................17
-      2.3. Renewable Tickets .........................................17
-      2.4. Postdated Tickets .........................................18
-      2.5. Proxiable and Proxy Tickets ...............................19
-      2.6. Forwardable Tickets .......................................19
-      2.7. Transited Policy Checking .................................20
-      2.8. OK as Delegate ............................................21
-      2.9. Other KDC Options .........................................21
-           2.9.1. Renewable-OK .......................................21
-           2.9.2. ENC-TKT-IN-SKEY ....................................22
-           2.9.3. Passwordless Hardware Authentication ...............22
-   3. Message Exchanges ..............................................22
-      3.1. The Authentication Service Exchange .......................22
-           3.1.1. Generation of KRB_AS_REQ Message ...................24
-           3.1.2. Receipt of KRB_AS_REQ Message ......................24
-           3.1.3. Generation of KRB_AS_REP Message ...................24
-           3.1.4. Generation of KRB_ERROR Message ....................27
-           3.1.5. Receipt of KRB_AS_REP Message ......................27
-           3.1.6. Receipt of KRB_ERROR Message .......................28
-      3.2. The Client/Server Authentication Exchange .................29
-           3.2.1. The KRB_AP_REQ Message .............................29
-           3.2.2. Generation of a KRB_AP_REQ Message .................29
-           3.2.3. Receipt of KRB_AP_REQ Message ......................30
-           3.2.4. Generation of a KRB_AP_REP Message .................33
-           3.2.5. Receipt of KRB_AP_REP Message ......................33
-           3.2.6. Using the Encryption Key ...........................33
-      3.3. The Ticket-Granting Service (TGS) Exchange ................34
-           3.3.1. Generation of KRB_TGS_REQ Message ..................35
-           3.3.2. Receipt of KRB_TGS_REQ Message .....................37
-           3.3.3. Generation of KRB_TGS_REP Message ..................38
-           3.3.4. Receipt of KRB_TGS_REP Message .....................42
-
-
-
-
-
-Neuman, et al.              Standards Track                     [Page 2]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-      3.4. The KRB_SAFE Exchange .....................................42
-           3.4.1. Generation of a KRB_SAFE Message ...................42
-           3.4.2. Receipt of KRB_SAFE Message ........................43
-      3.5. The KRB_PRIV Exchange .....................................44
-           3.5.1. Generation of a KRB_PRIV Message ...................44
-           3.5.2. Receipt of KRB_PRIV Message ........................44
-      3.6. The KRB_CRED Exchange .....................................45
-           3.6.1. Generation of a KRB_CRED Message ...................45
-           3.6.2. Receipt of KRB_CRED Message ........................46
-      3.7. User-to-User Authentication Exchanges .....................47
-   4. Encryption and Checksum Specifications .........................48
-   5. Message Specifications .........................................50
-      5.1. Specific Compatibility Notes on ASN.1 .....................51
-           5.1.1. ASN.1 Distinguished Encoding Rules .................51
-           5.1.2. Optional Integer Fields ............................52
-           5.1.3. Empty SEQUENCE OF Types ............................52
-           5.1.4. Unrecognized Tag Numbers ...........................52
-           5.1.5. Tag Numbers Greater Than 30 ........................53
-      5.2. Basic Kerberos Types ......................................53
-           5.2.1. KerberosString .....................................53
-           5.2.2. Realm and PrincipalName ............................55
-           5.2.3. KerberosTime .......................................55
-           5.2.4. Constrained Integer Types ..........................55
-           5.2.5. HostAddress and HostAddresses ......................56
-           5.2.6. AuthorizationData ..................................57
-           5.2.7. PA-DATA ............................................60
-           5.2.8. KerberosFlags ......................................64
-           5.2.9. Cryptosystem-Related Types .........................65
-      5.3. Tickets ...................................................66
-      5.4. Specifications for the AS and TGS Exchanges ...............73
-           5.4.1. KRB_KDC_REQ Definition .............................73
-           5.4.2. KRB_KDC_REP Definition .............................81
-      5.5. Client/Server (CS) Message Specifications .................84
-           5.5.1. KRB_AP_REQ Definition ..............................84
-           5.5.2. KRB_AP_REP Definition ..............................88
-           5.5.3. Error Message Reply ................................89
-      5.6. KRB_SAFE Message Specification ............................89
-           5.6.1. KRB_SAFE definition ................................89
-      5.7. KRB_PRIV Message Specification ............................91
-           5.7.1. KRB_PRIV Definition ................................91
-      5.8. KRB_CRED Message Specification ............................92
-           5.8.1. KRB_CRED Definition ................................92
-      5.9. Error Message Specification ...............................94
-           5.9.1. KRB_ERROR Definition ...............................94
-      5.10. Application Tag Numbers ..................................96
-
-
-
-
-
-
-Neuman, et al.              Standards Track                     [Page 3]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   6. Naming Constraints .............................................97
-      6.1. Realm Names ...............................................97
-      6.2. Principal Names .......................................... 99
-           6.2.1. Name of Server Principals .........................100
-   7. Constants and Other Defined Values ............................101
-      7.1. Host Address Types .......................................101
-      7.2. KDC Messaging: IP Transports .............................102
-           7.2.1. UDP/IP transport ..................................102
-           7.2.2. TCP/IP Transport ..................................103
-           7.2.3. KDC Discovery on IP Networks ......................104
-      7.3. Name of the TGS ..........................................105
-      7.4. OID Arc for KerberosV5 ...................................106
-      7.5. Protocol Constants and Associated Values .................106
-           7.5.1. Key Usage Numbers .................................106
-           7.5.2. PreAuthentication Data Types ......................108
-           7.5.3. Address Types .....................................109
-           7.5.4. Authorization Data Types ..........................109
-           7.5.5. Transited Encoding Types ..........................109
-           7.5.6. Protocol Version Number ...........................109
-           7.5.7. Kerberos Message Types ............................110
-           7.5.8. Name Types ........................................110
-           7.5.9. Error Codes .......................................110
-   8. Interoperability Requirements .................................113
-      8.1. Specification 2 ..........................................113
-      8.2. Recommended KDC Values ...................................116
-   9. IANA Considerations ...........................................116
-   10. Security Considerations ......................................117
-   11. Acknowledgements .............................................121
-   A. ASN.1 Module ..................................................123
-   B. Changes since RFC 1510 ........................................131
-   Normative References .............................................134
-   Informative References ...........................................135
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Neuman, et al.              Standards Track                     [Page 4]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-1.  Introduction
-
-   This document describes the concepts and model upon which the
-   Kerberos network authentication system is based.  It also specifies
-   Version 5 of the Kerberos protocol.  The motivations, goals,
-   assumptions, and rationale behind most design decisions are treated
-   cursorily; they are more fully described in a paper available in IEEE
-   communications [NT94] and earlier in the Kerberos portion of the
-   Athena Technical Plan [MNSS87].
-
-   This document is not intended to describe Kerberos to the end user,
-   system administrator, or application developer.  Higher-level papers
-   describing Version 5 of the Kerberos system [NT94] and documenting
-   version 4 [SNS88] are available elsewhere.
-
-   The Kerberos model is based in part on Needham and Schroeder's
-   trusted third-party authentication protocol [NS78] and on
-   modifications suggested by Denning and Sacco [DS81].  The original
-   design and implementation of Kerberos Versions 1 through 4 was the
-   work of two former Project Athena staff members, Steve Miller of
-   Digital Equipment Corporation and Clifford Neuman (now at the
-   Information Sciences Institute of the University of Southern
-   California), along with Jerome Saltzer, Technical Director of Project
-   Athena, and Jeffrey Schiller, MIT Campus Network Manager.  Many other
-   members of Project Athena have also contributed to the work on
-   Kerberos.
-
-   Version 5 of the Kerberos protocol (described in this document) has
-   evolved because of new requirements and desires for features not
-   available in Version 4.  The design of Version 5 was led by Clifford
-   Neuman and John Kohl with much input from the community.  The
-   development of the MIT reference implementation was led at MIT by
-   John Kohl and Theodore Ts'o, with help and contributed code from many
-   others.  Since RFC 1510 was issued, many individuals have proposed
-   extensions and revisions to the protocol.  This document reflects
-   some of these proposals.  Where such changes involved significant
-   effort, the document cites the contribution of the proposer.
-
-   Reference implementations of both Version 4 and Version 5 of Kerberos
-   are publicly available, and commercial implementations have been
-   developed and are widely used.  Details on the differences between
-   Versions 4 and 5 can be found in [KNT94].
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-Neuman, et al.              Standards Track                     [Page 5]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-1.1.  The Kerberos Protocol
-
-   Kerberos provides a means of verifying the identities of principals,
-   (e.g., a workstation user or a network server) on an open
-   (unprotected) network.  This is accomplished without relying on
-   assertions by the host operating system, without basing trust on host
-   addresses, without requiring physical security of all the hosts on
-   the network, and under the assumption that packets traveling along
-   the network can be read, modified, and inserted at will.  Kerberos
-   performs authentication under these conditions as a trusted third-
-   party authentication service by using conventional (shared secret
-   key) cryptography.  Extensions to Kerberos (outside the scope of this
-   document) can provide for the use of public key cryptography during
-   certain phases of the authentication protocol.  Such extensions
-   support Kerberos authentication for users registered with public key
-   certification authorities and provide certain benefits of public key
-   cryptography in situations where they are needed.
-
-   The basic Kerberos authentication process proceeds as follows: A
-   client sends a request to the authentication server (AS) for
-   "credentials" for a given server.  The AS responds with these
-   credentials, encrypted in the client's key.  The credentials consist
-   of a "ticket" for the server and a temporary encryption key (often
-   called a "session key").  The client transmits the ticket (which
-   contains the client's identity and a copy of the session key, all
-   encrypted in the server's key) to the server.  The session key (now
-   shared by the client and server) is used to authenticate the client
-   and may optionally be used to authenticate the server.  It may also
-   be used to encrypt further communication between the two parties or
-   to exchange a separate sub-session key to be used to encrypt further
-   communication.  Note that many applications use Kerberos' functions
-   only upon the initiation of a stream-based network connection.
-   Unless an application performs encryption or integrity protection for
-   the data stream, the identity verification applies only to the
-   initiation of the connection, and it does not guarantee that
-   subsequent messages on the connection originate from the same
-   principal.
-
-   Implementation of the basic protocol consists of one or more
-   authentication servers running on physically secure hosts.  The
-   authentication servers maintain a database of principals (i.e., users
-   and servers) and their secret keys.  Code libraries provide
-   encryption and implement the Kerberos protocol.  In order to add
-   authentication to its transactions, a typical network application
-   adds calls to the Kerberos library directly or through the Generic
-   Security Services Application Programming Interface (GSS-API)
-   described in a separate document [RFC4121].  These calls result in
-   the transmission of the messages necessary to achieve authentication.
-
-
-
-Neuman, et al.              Standards Track                     [Page 6]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   The Kerberos protocol consists of several sub-protocols (or
-   exchanges).  There are two basic methods by which a client can ask a
-   Kerberos server for credentials.  In the first approach, the client
-   sends a cleartext request for a ticket for the desired server to the
-   AS.  The reply is sent encrypted in the client's secret key.  Usually
-   this request is for a ticket-granting ticket (TGT), which can later
-   be used with the ticket-granting server (TGS).  In the second method,
-   the client sends a request to the TGS.  The client uses the TGT to
-   authenticate itself to the TGS in the same manner as if it were
-   contacting any other application server that requires Kerberos
-   authentication.  The reply is encrypted in the session key from the
-   TGT.  Though the protocol specification describes the AS and the TGS
-   as separate servers, in practice they are implemented as different
-   protocol entry points within a single Kerberos server.
-
-   Once obtained, credentials may be used to verify the identity of the
-   principals in a transaction, to ensure the integrity of messages
-   exchanged between them, or to preserve privacy of the messages.  The
-   application is free to choose whatever protection may be necessary.
-
-   To verify the identities of the principals in a transaction, the
-   client transmits the ticket to the application server.  Because the
-   ticket is sent "in the clear" (parts of it are encrypted, but this
-   encryption doesn't thwart replay) and might be intercepted and reused
-   by an attacker, additional information is sent to prove that the
-   message originated with the principal to whom the ticket was issued.
-   This information (called the authenticator) is encrypted in the
-   session key and includes a timestamp.  The timestamp proves that the
-   message was recently generated and is not a replay.  Encrypting the
-   authenticator in the session key proves that it was generated by a
-   party possessing the session key.  Since no one except the requesting
-   principal and the server know the session key (it is never sent over
-   the network in the clear), this guarantees the identity of the
-   client.
-
-   The integrity of the messages exchanged between principals can also
-   be guaranteed by using the session key (passed in the ticket and
-   contained in the credentials).  This approach provides detection of
-   both replay attacks and message stream modification attacks.  It is
-   accomplished by generating and transmitting a collision-proof
-   checksum (elsewhere called a hash or digest function) of the client's
-   message, keyed with the session key.  Privacy and integrity of the
-   messages exchanged between principals can be secured by encrypting
-   the data to be passed by using the session key contained in the
-   ticket or the sub-session key found in the authenticator.
-
-
-
-
-
-
-Neuman, et al.              Standards Track                     [Page 7]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   The authentication exchanges mentioned above require read-only access
-   to the Kerberos database.  Sometimes, however, the entries in the
-   database must be modified, such as when adding new principals or
-   changing a principal's key.  This is done using a protocol between a
-   client and a third Kerberos server, the Kerberos Administration
-   Server (KADM).  There is also a protocol for maintaining multiple
-   copies of the Kerberos database.  Neither of these protocols are
-   described in this document.
-
-1.2.  Cross-Realm Operation
-
-   The Kerberos protocol is designed to operate across organizational
-   boundaries.  A client in one organization can be authenticated to a
-   server in another.  Each organization wishing to run a Kerberos
-   server establishes its own "realm".  The name of the realm in which a
-   client is registered is part of the client's name and can be used by
-   the end-service to decide whether to honor a request.
-
-   By establishing "inter-realm" keys, the administrators of two realms
-   can allow a client authenticated in the local realm to prove its
-   identity to servers in other realms.  The exchange of inter-realm
-   keys (a separate key may be used for each direction) registers the
-   ticket-granting service of each realm as a principal in the other
-   realm.  A client is then able to obtain a TGT for the remote realm's
-   ticket-granting service from its local realm.  When that TGT is used,
-   the remote ticket-granting service uses the inter-realm key (which
-   usually differs from its own normal TGS key) to decrypt the TGT; thus
-   it is certain that the ticket was issued by the client's own TGS.
-   Tickets issued by the remote ticket-granting service will indicate to
-   the end-service that the client was authenticated from another realm.
-
-   Without cross-realm operation, and with appropriate permission, the
-   client can arrange registration of a separately-named principal in a
-   remote realm and engage in normal exchanges with that realm's
-   services.  However, for even small numbers of clients this becomes
-   cumbersome, and more automatic methods as described here are
-   necessary.
-
-   A realm is said to communicate with another realm if the two realms
-   share an inter-realm key, or if the local realm shares an inter-realm
-   key with an intermediate realm that communicates with the remote
-   realm.  An authentication path is the sequence of intermediate realms
-   that are transited in communicating from one realm to another.
-
-   Realms may be organized hierarchically.  Each realm shares a key with
-   its parent and a different key with each child.  If an inter-realm
-   key is not directly shared by two realms, the hierarchical
-   organization allows an authentication path to be easily constructed.
-
-
-
-Neuman, et al.              Standards Track                     [Page 8]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   If a hierarchical organization is not used, it may be necessary to
-   consult a database in order to construct an authentication path
-   between realms.
-
-   Although realms are typically hierarchical, intermediate realms may
-   be bypassed to achieve cross-realm authentication through alternate
-   authentication paths.  (These might be established to make
-   communication between two realms more efficient.)  It is important
-   for the end-service to know which realms were transited when deciding
-   how much faith to place in the authentication process.  To facilitate
-   this decision, a field in each ticket contains the names of the
-   realms that were involved in authenticating the client.
-
-   The application server is ultimately responsible for accepting or
-   rejecting authentication and SHOULD check the transited field.  The
-   application server may choose to rely on the Key Distribution Center
-   (KDC) for the application server's realm to check the transited
-   field.  The application server's KDC will set the
-   TRANSITED-POLICY-CHECKED flag in this case.  The KDCs for
-   intermediate realms may also check the transited field as they issue
-   TGTs for other realms, but they are encouraged not to do so.  A
-   client may request that the KDCs not check the transited field by
-   setting the DISABLE-TRANSITED-CHECK flag.  KDCs SHOULD honor this
-   flag.
-
-1.3.  Choosing a Principal with Which to Communicate
-
-   The Kerberos protocol provides the means for verifying (subject to
-   the assumptions in Section 1.6) that the entity with which one
-   communicates is the same entity that was registered with the KDC
-   using the claimed identity (principal name).  It is still necessary
-   to determine whether that identity corresponds to the entity with
-   which one intends to communicate.
-
-   When appropriate data has been exchanged in advance, the application
-   may perform this determination syntactically based on the application
-   protocol specification, information provided by the user, and
-   configuration files.  For example, the server principal name
-   (including realm) for a telnet server might be derived from the
-   user-specified host name (from the telnet command line), the "host/"
-   prefix specified in the application protocol specification, and a
-   mapping to a Kerberos realm derived syntactically from the domain
-   part of the specified hostname and information from the local
-   Kerberos realms database.
-
-   One can also rely on trusted third parties to make this
-   determination, but only when the data obtained from the third party
-   is suitably integrity-protected while resident on the third-party
-
-
-
-Neuman, et al.              Standards Track                     [Page 9]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   server and when transmitted.  Thus, for example, one should not rely
-   on an unprotected DNS record to map a host alias to the primary name
-   of a server, accepting the primary name as the party that one intends
-   to contact, since an attacker can modify the mapping and impersonate
-   the party.
-
-   Implementations of Kerberos and protocols based on Kerberos MUST NOT
-   use insecure DNS queries to canonicalize the hostname components of
-   the service principal names (i.e., they MUST NOT use insecure DNS
-   queries to map one name to another to determine the host part of the
-   principal name with which one is to communicate).  In an environment
-   without secure name service, application authors MAY append a
-   statically configured domain name to unqualified hostnames before
-   passing the name to the security mechanisms, but they should do no
-   more than that.  Secure name service facilities, if available, might
-   be trusted for hostname canonicalization, but such canonicalization
-   by the client SHOULD NOT be required by KDC implementations.
-
-   Implementation note: Many current implementations do some degree of
-   canonicalization of the provided service name, often using DNS even
-   though it creates security problems.  However, there is no
-   consistency among implementations as to whether the service name is
-   case folded to lowercase or whether reverse resolution is used.  To
-   maximize interoperability and security, applications SHOULD provide
-   security mechanisms with names that result from folding the user-
-   entered name to lowercase without performing any other modifications
-   or canonicalization.
-
-1.4.  Authorization
-
-   As an authentication service, Kerberos provides a means of verifying
-   the identity of principals on a network.  Authentication is usually
-   useful primarily as a first step in the process of authorization,
-   determining whether a client may use a service, which objects the
-   client is allowed to access, and the type of access allowed for each.
-   Kerberos does not, by itself, provide authorization.  Possession of a
-   client ticket for a service provides only for authentication of the
-   client to that service, and in the absence of a separate
-   authorization procedure, an application should not consider it to
-   authorize the use of that service.
-
-   Separate authorization methods MAY be implemented as application-
-   specific access control functions and may utilize files on the
-   application server, on separately issued authorization credentials
-   such as those based on proxies [Neu93], or on other authorization
-   services.  Separately authenticated authorization credentials MAY be
-   embedded in a ticket's authorization data when encapsulated by the
-   KDC-issued authorization data element.
-
-
-
-Neuman, et al.              Standards Track                    [Page 10]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Applications should not accept the mere issuance of a service ticket
-   by the Kerberos server (even by a modified Kerberos server) as
-   granting authority to use the service, since such applications may
-   become vulnerable to the bypass of this authorization check in an
-   environment where other options for application authentication are
-   provided, or if they interoperate with other KDCs.
-
-1.5.  Extending Kerberos without Breaking Interoperability
-
-   As the deployed base of Kerberos implementations grows, extending
-   Kerberos becomes more important.  Unfortunately, some extensions to
-   the existing Kerberos protocol create interoperability issues because
-   of uncertainty regarding the treatment of certain extensibility
-   options by some implementations.  This section includes guidelines
-   that will enable future implementations to maintain interoperability.
-
-   Kerberos provides a general mechanism for protocol extensibility.
-   Some protocol messages contain typed holes -- sub-messages that
-   contain an octet-string along with an integer that defines how to
-   interpret the octet-string.  The integer types are registered
-   centrally, but they can be used both for vendor extensions and for
-   extensions standardized through the IETF.
-
-   In this document, the word "extension" refers to extension by
-   defining a new type to insert into an existing typed hole in a
-   protocol message.  It does not refer to extension by addition of new
-   fields to ASN.1 types, unless the text explicitly indicates
-   otherwise.
-
-1.5.1.  Compatibility with RFC 1510
-
-   Note that existing Kerberos message formats cannot readily be
-   extended by adding fields to the ASN.1 types.  Sending additional
-   fields often results in the entire message being discarded without an
-   error indication.  Future versions of this specification will provide
-   guidelines to ensure that ASN.1 fields can be added without creating
-   an interoperability problem.
-
-   In the meantime, all new or modified implementations of Kerberos that
-   receive an unknown message extension SHOULD preserve the encoding of
-   the extension but otherwise ignore its presence.  Recipients MUST NOT
-   decline a request simply because an extension is present.
-
-   There is one exception to this rule.  If an unknown authorization
-   data element type is received by a server other than the ticket-
-   granting service either in an AP-REQ or in a ticket contained in an
-   AP-REQ, then authentication MUST fail.  One of the primary uses of
-   authorization data is to restrict the use of the ticket.  If the
-
-
-
-Neuman, et al.              Standards Track                    [Page 11]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   service cannot determine whether the restriction applies to that
-   service, then a security weakness may result if the ticket can be
-   used for that service.  Authorization elements that are optional
-   SHOULD be enclosed in the AD-IF-RELEVANT element.
-
-   The ticket-granting service MUST ignore but propagate to derivative
-   tickets any unknown authorization data types, unless those data types
-   are embedded in a MANDATORY-FOR-KDC element, in which case the
-   request will be rejected.  This behavior is appropriate because
-   requiring that the ticket-granting service understand unknown
-   authorization data types would require that KDC software be upgraded
-   to understand new application-level restrictions before applications
-   used these restrictions, decreasing the utility of authorization data
-   as a mechanism for restricting the use of tickets.  No security
-   problem is created because services to which the tickets are issued
-   will verify the authorization data.
-
-   Implementation note: Many RFC 1510 implementations ignore unknown
-   authorization data elements.  Depending on these implementations to
-   honor authorization data restrictions may create a security weakness.
-
-1.5.2.  Sending Extensible Messages
-
-   Care must be taken to ensure that old implementations can understand
-   messages sent to them, even if they do not understand an extension
-   that is used.  Unless the sender knows that an extension is
-   supported, the extension cannot change the semantics of the core
-   message or previously defined extensions.
-
-   For example, an extension including key information necessary to
-   decrypt the encrypted part of a KDC-REP could only be used in
-   situations where the recipient was known to support the extension.
-   Thus when designing such extensions it is important to provide a way
-   for the recipient to notify the sender of support for the extension.
-   For example in the case of an extension that changes the KDC-REP
-   reply key, the client could indicate support for the extension by
-   including a padata element in the AS-REQ sequence.  The KDC should
-   only use the extension if this padata element is present in the
-   AS-REQ.  Even if policy requires the use of the extension, it is
-   better to return an error indicating that the extension is required
-   than to use the extension when the recipient may not support it.
-   Debugging implementations that do not interoperate is easier when
-   errors are returned.
-
-1.6.  Environmental Assumptions
-
-   Kerberos imposes a few assumptions on the environment in which it can
-   properly function, including the following:
-
-
-
-Neuman, et al.              Standards Track                    [Page 12]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   *  "Denial of service" attacks are not solved with Kerberos.  There
-      are places in the protocols where an intruder can prevent an
-      application from participating in the proper authentication steps.
-      Detection and solution of such attacks (some of which can appear
-      to be not-uncommon "normal" failure modes for the system) are
-      usually best left to the human administrators and users.
-
-   *  Principals MUST keep their secret keys secret.  If an intruder
-      somehow steals a principal's key, it will be able to masquerade as
-      that principal or to impersonate any server to the legitimate
-      principal.
-
-   *  "Password guessing" attacks are not solved by Kerberos.  If a user
-      chooses a poor password, it is possible for an attacker to
-      successfully mount an offline dictionary attack by repeatedly
-      attempting to decrypt, with successive entries from a dictionary,
-      messages obtained which are encrypted under a key derived from the
-      user's password.
-
-   *  Each host on the network MUST have a clock which is "loosely
-      synchronized" to the time of the other hosts; this synchronization
-      is used to reduce the bookkeeping needs of application servers
-      when they do replay detection.  The degree of "looseness" can be
-      configured on a per-server basis, but it is typically on the order
-      of 5 minutes.  If the clocks are synchronized over the network,
-      the clock synchronization protocol MUST itself be secured from
-      network attackers.
-
-   *  Principal identifiers are not recycled on a short-term basis.  A
-      typical mode of access control will use access control lists
-      (ACLs) to grant permissions to particular principals.  If a stale
-      ACL entry remains for a deleted principal and the principal
-      identifier is reused, the new principal will inherit rights
-      specified in the stale ACL entry.  By not re-using principal
-      identifiers, the danger of inadvertent access is removed.
-
-1.7.  Glossary of Terms
-
-   Below is a list of terms used throughout this document.
-
-   Authentication
-      Verifying the claimed identity of a principal.
-
-   Authentication header
-      A record containing a Ticket and an Authenticator to be presented
-      to a server as part of the authentication process.
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 13]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Authentication path
-      A sequence of intermediate realms transited in the authentication
-      process when communicating from one realm to another.
-
-   Authenticator
-      A record containing information that can be shown to have been
-      recently generated using the session key known only by the client
-      and server.
-
-   Authorization
-      The process of determining whether a client may use a service,
-      which objects the client is allowed to access, and the type of
-      access allowed for each.
-
-   Capability
-      A token that grants the bearer permission to access an object or
-      service.  In Kerberos, this might be a ticket whose use is
-      restricted by the contents of the authorization data field, but
-      which lists no network addresses, together with the session key
-      necessary to use the ticket.
-
-   Ciphertext
-      The output of an encryption function.  Encryption transforms
-      plaintext into ciphertext.
-
-   Client
-      A process that makes use of a network service on behalf of a user.
-      Note that in some cases a Server may itself be a client of some
-      other server (e.g., a print server may be a client of a file
-      server).
-
-   Credentials
-      A ticket plus the secret session key necessary to use that ticket
-      successfully in an authentication exchange.
-
-   Encryption Type (etype)
-      When associated with encrypted data, an encryption type identifies
-      the algorithm used to encrypt the data and is used to select the
-      appropriate algorithm for decrypting the data.  Encryption type
-      tags are communicated in other messages to enumerate algorithms
-      that are desired, supported, preferred, or allowed to be used for
-      encryption of data between parties.  This preference is combined
-      with local information and policy to select an algorithm to be
-      used.
-
-   KDC
-      Key Distribution Center.  A network service that supplies tickets
-      and temporary session keys; or an instance of that service or the
-
-
-
-Neuman, et al.              Standards Track                    [Page 14]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-      host on which it runs.  The KDC services both initial ticket and
-      ticket-granting ticket requests.  The initial ticket portion is
-      sometimes referred to as the Authentication Server (or service).
-      The ticket-granting ticket portion is sometimes referred to as the
-      ticket-granting server (or service).
-
-   Kerberos
-      The name given to the Project Athena's authentication service, the
-      protocol used by that service, or the code used to implement the
-      authentication service.  The name is adopted from the three-headed
-      dog that guards Hades.
-
-   Key Version Number (kvno)
-      A tag associated with encrypted data identifies which key was used
-      for encryption when a long-lived key associated with a principal
-      changes over time.  It is used during the transition to a new key
-      so that the party decrypting a message can tell whether the data
-      was encrypted with the old or the new key.
-
-   Plaintext
-      The input to an encryption function or the output of a decryption
-      function.  Decryption transforms ciphertext into plaintext.
-
-   Principal
-      A named client or server entity that participates in a network
-      communication, with one name that is considered canonical.
-
-   Principal identifier
-      The canonical name used to identify each different principal
-      uniquely.
-
-   Seal
-      To encipher a record containing several fields in such a way that
-      the fields cannot be individually replaced without knowledge of
-      the encryption key or leaving evidence of tampering.
-
-   Secret key
-      An encryption key shared by a principal and the KDC, distributed
-      outside the bounds of the system, with a long lifetime.  In the
-      case of a human user's principal, the secret key MAY be derived
-      from a password.
-
-   Server
-      A particular Principal that provides a resource to network
-      clients.  The server is sometimes referred to as the Application
-      Server.
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 15]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Service
-      A resource provided to network clients; often provided by more
-      than one server (for example, remote file service).
-
-   Session key
-      A temporary encryption key used between two principals, with a
-      lifetime limited to the duration of a single login "session".  In
-      the Kerberos system, a session key is generated by the KDC.  The
-      session key is distinct from the sub-session key, described next.
-
-   Sub-session key
-      A temporary encryption key used between two principals, selected
-      and exchanged by the principals using the session key, and with a
-      lifetime limited to the duration of a single association.  The
-      sub-session key is also referred to as the subkey.
-
-   Ticket
-      A record that helps a client authenticate itself to a server; it
-      contains the client's identity, a session key, a timestamp, and
-      other information, all sealed using the server's secret key.  It
-      only serves to authenticate a client when presented along with a
-      fresh Authenticator.
-
-2.  Ticket Flag Uses and Requests
-
-   Each Kerberos ticket contains a set of flags that are used to
-   indicate attributes of that ticket.  Most flags may be requested by a
-   client when the ticket is obtained; some are automatically turned on
-   and off by a Kerberos server as required.  The following sections
-   explain what the various flags mean and give examples of reasons to
-   use them.  With the exception of the INVALID flag, clients MUST
-   ignore ticket flags that are not recognized.  KDCs MUST ignore KDC
-   options that are not recognized.  Some implementations of RFC 1510
-   are known to reject unknown KDC options, so clients may need to
-   resend a request without new KDC options if the request was rejected
-   when sent with options added since RFC 1510.  Because new KDCs will
-   ignore unknown options, clients MUST confirm that the ticket returned
-   by the KDC meets their needs.
-
-   Note that it is not, in general, possible to determine whether an
-   option was not honored because it was not understood or because it
-   was rejected through either configuration or policy.  When adding a
-   new option to the Kerberos protocol, designers should consider
-   whether the distinction is important for their option.  If it is, a
-   mechanism for the KDC to return an indication that the option was
-   understood but rejected needs to be provided in the specification of
-   the option.  Often in such cases, the mechanism needs to be broad
-   enough to permit an error or reason to be returned.
-
-
-
-Neuman, et al.              Standards Track                    [Page 16]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-2.1.  Initial, Pre-authenticated, and Hardware-Authenticated Tickets
-
-   The INITIAL flag indicates that a ticket was issued using the AS
-   protocol, rather than issued based on a TGT.  Application servers
-   that want to require the demonstrated knowledge of a client's secret
-   key (e.g., a password-changing program) can insist that this flag be
-   set in any tickets they accept, and can thus be assured that the
-   client's key was recently presented to the authentication server.
-
-   The PRE-AUTHENT and HW-AUTHENT flags provide additional information
-   about the initial authentication, regardless of whether the current
-   ticket was issued directly (in which case INITIAL will also be set)
-   or issued on the basis of a TGT (in which case the INITIAL flag is
-   clear, but the PRE-AUTHENT and HW-AUTHENT flags are carried forward
-   from the TGT).
-
-2.2.  Invalid Tickets
-
-   The INVALID flag indicates that a ticket is invalid.  Application
-   servers MUST reject tickets that have this flag set.  A postdated
-   ticket will be issued in this form.  Invalid tickets MUST be
-   validated by the KDC before use, by being presented to the KDC in a
-   TGS request with the VALIDATE option specified.  The KDC will only
-   validate tickets after their starttime has passed.  The validation is
-   required so that postdated tickets that have been stolen before their
-   starttime can be rendered permanently invalid (through a hot-list
-   mechanism) (see Section 3.3.3.1).
-
-2.3.  Renewable Tickets
-
-   Applications may desire to hold tickets that can be valid for long
-   periods of time.  However, this can expose their credentials to
-   potential theft for equally long periods, and those stolen
-   credentials would be valid until the expiration time of the
-   ticket(s).  Simply using short-lived tickets and obtaining new ones
-   periodically would require the client to have long-term access to its
-   secret key, an even greater risk.  Renewable tickets can be used to
-   mitigate the consequences of theft.  Renewable tickets have two
-   "expiration times": the first is when the current instance of the
-   ticket expires, and the second is the latest permissible value for an
-   individual expiration time.  An application client must periodically
-   (i.e., before it expires) present a renewable ticket to the KDC, with
-   the RENEW option set in the KDC request.  The KDC will issue a new
-   ticket with a new session key and a later expiration time.  All other
-   fields of the ticket are left unmodified by the renewal process.
-   When the latest permissible expiration time arrives, the ticket
-   expires permanently.  At each renewal, the KDC MAY consult a hot-list
-   to determine whether the ticket had been reported stolen since its
-
-
-
-Neuman, et al.              Standards Track                    [Page 17]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   last renewal; it will refuse to renew stolen tickets, and thus the
-   usable lifetime of stolen tickets is reduced.
-
-   The RENEWABLE flag in a ticket is normally only interpreted by the
-   ticket-granting service (discussed below in Section 3.3).  It can
-   usually be ignored by application servers.  However, some
-   particularly careful application servers MAY disallow renewable
-   tickets.
-
-   If a renewable ticket is not renewed by its expiration time, the KDC
-   will not renew the ticket.  The RENEWABLE flag is reset by default,
-   but a client MAY request it be set by setting the RENEWABLE option in
-   the KRB_AS_REQ message.  If it is set, then the renew-till field in
-   the ticket contains the time after which the ticket may not be
-   renewed.
-
-2.4.  Postdated Tickets
-
-   Applications may occasionally need to obtain tickets for use much
-   later; e.g., a batch submission system would need tickets to be valid
-   at the time the batch job is serviced.  However, it is dangerous to
-   hold valid tickets in a batch queue, since they will be on-line
-   longer and more prone to theft.  Postdated tickets provide a way to
-   obtain these tickets from the KDC at job submission time, but to
-   leave them "dormant" until they are activated and validated by a
-   further request of the KDC.  If a ticket theft were reported in the
-   interim, the KDC would refuse to validate the ticket, and the thief
-   would be foiled.
-
-   The MAY-POSTDATE flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can be ignored by application servers.
-   This flag MUST be set in a TGT in order to issue a postdated ticket
-   based on the presented ticket.  It is reset by default; a client MAY
-   request it by setting the ALLOW-POSTDATE option in the KRB_AS_REQ
-   message.  This flag does not allow a client to obtain a postdated
-   TGT; postdated TGTs can only be obtained by requesting the postdating
-   in the KRB_AS_REQ message.  The life (endtime-starttime) of a
-   postdated ticket will be the remaining life of the TGT at the time of
-   the request, unless the RENEWABLE option is also set, in which case
-   it can be the full life (endtime-starttime) of the TGT.  The KDC MAY
-   limit how far in the future a ticket may be postdated.
-
-   The POSTDATED flag indicates that a ticket has been postdated.  The
-   application server can check the authtime field in the ticket to see
-   when the original authentication occurred.  Some services MAY choose
-   to reject postdated tickets, or they may only accept them within a
-   certain period after the original authentication.  When the KDC
-   issues a POSTDATED ticket, it will also be marked as INVALID, so that
-
-
-
-Neuman, et al.              Standards Track                    [Page 18]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   the application client MUST present the ticket to the KDC to be
-   validated before use.
-
-2.5.  Proxiable and Proxy Tickets
-
-   At times it may be necessary for a principal to allow a service to
-   perform an operation on its behalf.  The service must be able to take
-   on the identity of the client, but only for a particular purpose.  A
-   principal can allow a service to do this by granting it a proxy.
-
-   The process of granting a proxy by using the proxy and proxiable
-   flags is used to provide credentials for use with specific services.
-   Though conceptually also a proxy, users wishing to delegate their
-   identity in a form usable for all purposes MUST use the ticket
-   forwarding mechanism described in the next section to forward a TGT.
-
-   The PROXIABLE flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can be ignored by application servers.
-   When set, this flag tells the ticket-granting server that it is OK to
-   issue a new ticket (but not a TGT) with a different network address
-   based on this ticket.  This flag is set if requested by the client on
-   initial authentication.  By default, the client will request that it
-   be set when requesting a TGT, and that it be reset when requesting
-   any other ticket.
-
-   This flag allows a client to pass a proxy to a server to perform a
-   remote request on its behalf (e.g., a print service client can give
-   the print server a proxy to access the client's files on a particular
-   file server in order to satisfy a print request).
-
-   In order to complicate the use of stolen credentials, Kerberos
-   tickets are often valid only from those network addresses
-   specifically included in the ticket, but it is permissible as a
-   policy option to allow requests and to issue tickets with no network
-   addresses specified.  When granting a proxy, the client MUST specify
-   the new network address from which the proxy is to be used or
-   indicate that the proxy is to be issued for use from any address.
-
-   The PROXY flag is set in a ticket by the TGS when it issues a proxy
-   ticket.  Application servers MAY check this flag; and at their option
-   they MAY require additional authentication from the agent presenting
-   the proxy in order to provide an audit trail.
-
-2.6.  Forwardable Tickets
-
-   Authentication forwarding is an instance of a proxy where the service
-   that is granted is complete use of the client's identity.  An example
-   of where it might be used is when a user logs in to a remote system
-
-
-
-Neuman, et al.              Standards Track                    [Page 19]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   and wants authentication to work from that system as if the login
-   were local.
-
-   The FORWARDABLE flag in a ticket is normally only interpreted by the
-   ticket-granting service.  It can be ignored by application servers.
-   The FORWARDABLE flag has an interpretation similar to that of the
-   PROXIABLE flag, except TGTs may also be issued with different network
-   addresses.  This flag is reset by default, but users MAY request that
-   it be set by setting the FORWARDABLE option in the AS request when
-   they request their initial TGT.
-
-   This flag allows for authentication forwarding without requiring the
-   user to enter a password again.  If the flag is not set, then
-   authentication forwarding is not permitted, but the same result can
-   still be achieved if the user engages in the AS exchange, specifies
-   the requested network addresses, and supplies a password.
-
-   The FORWARDED flag is set by the TGS when a client presents a ticket
-   with the FORWARDABLE flag set and requests a forwarded ticket by
-   specifying the FORWARDED KDC option and supplying a set of addresses
-   for the new ticket.  It is also set in all tickets issued based on
-   tickets with the FORWARDED flag set.  Application servers may choose
-   to process FORWARDED tickets differently than non-FORWARDED tickets.
-
-   If addressless tickets are forwarded from one system to another,
-   clients SHOULD still use this option to obtain a new TGT in order to
-   have different session keys on the different systems.
-
-2.7.  Transited Policy Checking
-
-   In Kerberos, the application server is ultimately responsible for
-   accepting or rejecting authentication, and it SHOULD check that only
-   suitably trusted KDCs are relied upon to authenticate a principal.
-   The transited field in the ticket identifies which realms (and thus
-   which KDCs) were involved in the authentication process, and an
-   application server would normally check this field.  If any of these
-   are untrusted to authenticate the indicated client principal
-   (probably determined by a realm-based policy), the authentication
-   attempt MUST be rejected.  The presence of trusted KDCs in this list
-   does not provide any guarantee; an untrusted KDC may have fabricated
-   the list.
-
-   Although the end server ultimately decides whether authentication is
-   valid, the KDC for the end server's realm MAY apply a realm-specific
-   policy for validating the transited field and accepting credentials
-   for cross-realm authentication.  When the KDC applies such checks and
-   accepts such cross-realm authentication, it will set the
-   TRANSITED-POLICY-CHECKED flag in the service tickets it issues based
-
-
-
-Neuman, et al.              Standards Track                    [Page 20]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   on the cross-realm TGT.  A client MAY request that the KDCs not check
-   the transited field by setting the DISABLE-TRANSITED-CHECK flag.
-   KDCs are encouraged but not required to honor this flag.
-
-   Application servers MUST either do the transited-realm checks
-   themselves or reject cross-realm tickets without
-   TRANSITED-POLICY-CHECKED set.
-
-2.8.  OK as Delegate
-
-   For some applications, a client may need to delegate authority to a
-   server to act on its behalf in contacting other services.  This
-   requires that the client forward credentials to an intermediate
-   server.  The ability for a client to obtain a service ticket to a
-   server conveys no information to the client about whether the server
-   should be trusted to accept delegated credentials.  The
-   OK-AS-DELEGATE provides a way for a KDC to communicate local realm
-   policy to a client regarding whether an intermediate server is
-   trusted to accept such credentials.
-
-   The copy of the ticket flags in the encrypted part of the KDC reply
-   may have the OK-AS-DELEGATE flag set to indicate to the client that
-   the server specified in the ticket has been determined by the policy
-   of the realm to be a suitable recipient of delegation.  A client can
-   use the presence of this flag to help it decide whether to delegate
-   credentials (grant either a proxy or a forwarded TGT) to this server.
-   It is acceptable to ignore the value of this flag.  When setting this
-   flag, an administrator should consider the security and placement of
-   the server on which the service will run, as well as whether the
-   service requires the use of delegated credentials.
-
-2.9.  Other KDC Options
-
-   There are three additional options that MAY be set in a client's
-   request of the KDC.
-
-2.9.1.  Renewable-OK
-
-   The RENEWABLE-OK option indicates that the client will accept a
-   renewable ticket if a ticket with the requested life cannot otherwise
-   be provided.  If a ticket with the requested life cannot be provided,
-   then the KDC MAY issue a renewable ticket with a renew-till equal to
-   the requested endtime.  The value of the renew-till field MAY still
-   be adjusted by site-determined limits or limits imposed by the
-   individual principal or server.
-
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 21]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-2.9.2.  ENC-TKT-IN-SKEY
-
-   In its basic form, the Kerberos protocol supports authentication in a
-   client-server setting and is not well suited to authentication in a
-   peer-to-peer environment because the long-term key of the user does
-   not remain on the workstation after initial login.  Authentication of
-   such peers may be supported by Kerberos in its user-to-user variant.
-   The ENC-TKT-IN-SKEY option supports user-to-user authentication by
-   allowing the KDC to issue a service ticket encrypted using the
-   session key from another TGT issued to another user.  The
-   ENC-TKT-IN-SKEY option is honored only by the ticket-granting
-   service.  It indicates that the ticket to be issued for the end
-   server is to be encrypted in the session key from the additional
-   second TGT provided with the request.  See Section 3.3.3 for specific
-   details.
-
-2.9.3.  Passwordless Hardware Authentication
-
-   The OPT-HARDWARE-AUTH option indicates that the client wishes to use
-   some form of hardware authentication instead of or in addition to the
-   client's password or other long-lived encryption key.
-   OPT-HARDWARE-AUTH is honored only by the authentication service.  If
-   supported and allowed by policy, the KDC will return an error code of
-   KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to
-   perform such authentication.
-
-3.  Message Exchanges
-
-   The following sections describe the interactions between network
-   clients and servers and the messages involved in those exchanges.
-
-3.1.  The Authentication Service Exchange
-
-                             Summary
-
-         Message direction       Message type    Section
-         1. Client to Kerberos   KRB_AS_REQ      5.4.1
-         2. Kerberos to client   KRB_AS_REP or   5.4.2
-                                 KRB_ERROR       5.9.1
-
-   The Authentication Service (AS) Exchange between the client and the
-   Kerberos Authentication Server is initiated by a client when it
-   wishes to obtain authentication credentials for a given server but
-   currently holds no credentials.  In its basic form, the client's
-   secret key is used for encryption and decryption.  This exchange is
-   typically used at the initiation of a login session to obtain
-   credentials for a Ticket-Granting Server, which will subsequently be
-   used to obtain credentials for other servers (see Section 3.3)
-
-
-
-Neuman, et al.              Standards Track                    [Page 22]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   without requiring further use of the client's secret key.  This
-   exchange is also used to request credentials for services that must
-   not be mediated through the Ticket-Granting Service, but rather
-   require knowledge of a principal's secret key, such as the password-
-   changing service (the password-changing service denies requests
-   unless the requester can demonstrate knowledge of the user's old
-   password; requiring this knowledge prevents unauthorized password
-   changes by someone walking up to an unattended session).
-
-   This exchange does not by itself provide any assurance of the
-   identity of the user.  To authenticate a user logging on to a local
-   system, the credentials obtained in the AS exchange may first be used
-   in a TGS exchange to obtain credentials for a local server; those
-   credentials must then be verified by a local server through
-   successful completion of the Client/Server exchange.
-
-   The AS exchange consists of two messages: KRB_AS_REQ from the client
-   to Kerberos, and KRB_AS_REP or KRB_ERROR in reply.  The formats for
-   these messages are described in Sections 5.4.1, 5.4.2, and 5.9.1.
-
-   In the request, the client sends (in cleartext) its own identity and
-   the identity of the server for which it is requesting credentials,
-   other information about the credentials it is requesting, and a
-   randomly generated nonce, which can be used to detect replays and to
-   associate replies with the matching requests.  This nonce MUST be
-   generated randomly by the client and remembered for checking against
-   the nonce in the expected reply.  The response, KRB_AS_REP, contains
-   a ticket for the client to present to the server, and a session key
-   that will be shared by the client and the server.  The session key
-   and additional information are encrypted in the client's secret key.
-   The encrypted part of the KRB_AS_REP message also contains the nonce
-   that MUST be matched with the nonce from the KRB_AS_REQ message.
-
-   Without pre-authentication, the authentication server does not know
-   whether the client is actually the principal named in the request.
-   It simply sends a reply without knowing or caring whether they are
-   the same.  This is acceptable because nobody but the principal whose
-   identity was given in the request will be able to use the reply.  Its
-   critical information is encrypted in that principal's key.  However,
-   an attacker can send a KRB_AS_REQ message to get known plaintext in
-   order to attack the principal's key.  Especially if the key is based
-   on a password, this may create a security exposure.  So the initial
-   request supports an optional field that can be used to pass
-   additional information that might be needed for the initial exchange.
-   This field SHOULD be used for pre-authentication as described in
-   sections 3.1.1 and 5.2.7.
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 23]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Various errors can occur; these are indicated by an error response
-   (KRB_ERROR) instead of the KRB_AS_REP response.  The error message is
-   not encrypted.  The KRB_ERROR message contains information that can
-   be used to associate it with the message to which it replies.  The
-   contents of the KRB_ERROR message are not integrity-protected.  As
-   such, the client cannot detect replays, fabrications, or
-   modifications.  A solution to this problem will be included in a
-   future version of the protocol.
-
-3.1.1.  Generation of KRB_AS_REQ Message
-
-   The client may specify a number of options in the initial request.
-   Among these options are whether pre-authentication is to be
-   performed; whether the requested ticket is to be renewable,
-   proxiable, or forwardable; whether it should be postdated or allow
-   postdating of derivative tickets; and whether a renewable ticket will
-   be accepted in lieu of a non-renewable ticket if the requested ticket
-   expiration date cannot be satisfied by a non-renewable ticket (due to
-   configuration constraints).
-
-   The client prepares the KRB_AS_REQ message and sends it to the KDC.
-
-3.1.2.  Receipt of KRB_AS_REQ Message
-
-   If all goes well, processing the KRB_AS_REQ message will result in
-   the creation of a ticket for the client to present to the server.
-   The format for the ticket is described in Section 5.3.
-
-   Because Kerberos can run over unreliable transports such as UDP, the
-   KDC MUST be prepared to retransmit responses in case they are lost.
-   If a KDC receives a request identical to one it has recently
-   processed successfully, the KDC MUST respond with a KRB_AS_REP
-   message rather than a replay error.  In order to reduce ciphertext
-   given to a potential attacker, KDCs MAY send the same response
-   generated when the request was first handled.  KDCs MUST obey this
-   replay behavior even if the actual transport in use is reliable.
-
-3.1.3.  Generation of KRB_AS_REP Message
-
-   The authentication server looks up the client and server principals
-   named in the KRB_AS_REQ in its database, extracting their respective
-   keys.  If the requested client principal named in the request is
-   unknown because it doesn't exist in the KDC's principal database,
-   then an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
-
-   If required to do so, the server pre-authenticates the request, and
-   if the pre-authentication check fails, an error message with the code
-   KDC_ERR_PREAUTH_FAILED is returned.  If pre-authentication is
-
-
-
-Neuman, et al.              Standards Track                    [Page 24]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   required, but was not present in the request, an error message with
-   the code KDC_ERR_PREAUTH_REQUIRED is returned, and a METHOD-DATA
-   object will be stored in the e-data field of the KRB-ERROR message to
-   specify which pre-authentication mechanisms are acceptable.  Usually
-   this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as
-   described below.  If the server cannot accommodate any encryption
-   type requested by the client, an error message with code
-   KDC_ERR_ETYPE_NOSUPP is returned.  Otherwise, the KDC generates a
-   'random' session key, meaning that, among other things, it should be
-   impossible to guess the next session key based on knowledge of past
-   session keys.  Although this can be achieved in a pseudo-random
-   number generator if it is based on cryptographic principles, it is
-   more desirable to use a truly random number generator, such as one
-   based on measurements of random physical phenomena.  See [RFC4086]
-   for an in-depth discussion of randomness.
-
-   In response to an AS request, if there are multiple encryption keys
-   registered for a client in the Kerberos database, then the etype
-   field from the AS request is used by the KDC to select the encryption
-   method to be used to protect the encrypted part of the KRB_AS_REP
-   message that is sent to the client.  If there is more than one
-   supported strong encryption type in the etype list, the KDC SHOULD
-   use the first valid strong etype for which an encryption key is
-   available.
-
-   When the user's key is generated from a password or pass phrase, the
-   string-to-key function for the particular encryption key type is
-   used, as specified in [RFC3961].  The salt value and additional
-   parameters for the string-to-key function have default values
-   (specified by Section 4 and by the encryption mechanism
-   specification, respectively) that may be overridden by
-   pre-authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO,
-   PA-ETYPE-INFO2, etc).  Since the KDC is presumed to store a copy of
-   the resulting key only, these values should not be changed for
-   password-based keys except when changing the principal's key.
-
-   When the AS server is to include pre-authentication data in a
-   KRB-ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-
-   INFO, if the etype field of the client's AS-REQ lists at least one
-   "newer" encryption type.  Otherwise (when the etype field of the
-   client's AS-REQ does not list any "newer" encryption types), it MUST
-   send both PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for
-   each enctype).  A "newer" enctype is any enctype first officially
-   specified concurrently with or subsequent to the issue of this RFC.
-   The enctypes DES, 3DES, or RC4 and any defined in [RFC1510] are not
-   "newer" enctypes.
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 25]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   It is not possible to generate a user's key reliably given a pass
-   phrase without contacting the KDC, since it will not be known whether
-   alternate salt or parameter values are required.
-
-   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 and 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.
-
-   If the requested starttime is absent, indicates a time in the past,
-   or is within the window of acceptable clock skew for the KDC and the
-   POSTDATE option has not been specified, then the starttime of the
-   ticket is set to the authentication server's current time.  If it
-   indicates a time in the future beyond the acceptable clock skew, but
-   the POSTDATED option has not been specified, then the error
-   KDC_ERR_CANNOT_POSTDATE is returned.  Otherwise the requested
-   starttime is checked against the policy of the local realm (the
-   administrator might decide to prohibit certain types or ranges of
-   postdated tickets), and if the ticket's starttime is acceptable, it
-   is set as requested, and the INVALID flag is set in the new ticket.
-   The postdated ticket MUST be validated before use by presenting it to
-   the KDC after the starttime has been reached.
-
-   The expiration time of the ticket will be set to the earlier of the
-   requested endtime and a time determined by local policy, possibly by
-   using realm- or principal-specific factors.  For example, the
-   expiration time MAY be set to the earliest of the following:
-
-      *  The expiration time (endtime) requested in the KRB_AS_REQ
-         message.
-
-      *  The ticket's starttime plus the maximum allowable lifetime
-         associated with the client principal from the authentication
-         server's database.
-
-      *  The ticket's starttime plus the maximum allowable lifetime
-         associated with the server principal.
-
-      *  The ticket's starttime plus the maximum lifetime set by the
-         policy of the local realm.
-
-   If the requested expiration time minus the starttime (as determined
-   above) is less than a site-determined minimum lifetime, an error
-   message with code KDC_ERR_NEVER_VALID is returned.  If the requested
-   expiration time for the ticket exceeds what was determined as above,
-   and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE'
-
-
-
-Neuman, et al.              Standards Track                    [Page 26]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   flag is set in the new ticket, and the renew-till value is set as if
-   the 'RENEWABLE' option were requested (the field and option names are
-   described fully in Section 5.4.1).
-
-   If the RENEWABLE option has been requested or if the RENEWABLE-OK
-   option has been set and a renewable ticket is to be issued, then the
-   renew-till field MAY be set to the earliest of:
-
-      *  Its requested value.
-
-      *  The starttime of the ticket plus the minimum of the two maximum
-         renewable lifetimes associated with the principals' database
-         entries.
-
-      *  The starttime of the ticket plus the maximum renewable lifetime
-         set by the policy of the local realm.
-
-   The flags field of the new ticket will have the following options set
-   if they have been requested and if the policy of the local realm
-   allows:  FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
-   If the new ticket is postdated (the starttime is in the future), its
-   INVALID flag will also be set.
-
-   If all of the above succeed, the server will encrypt the ciphertext
-   part of the ticket using the encryption key extracted from the server
-   principal's record in the Kerberos database using the encryption type
-   associated with the server principal's key.  (This choice is NOT
-   affected by the etype field in the request.)  It then formats a
-   KRB_AS_REP message (see Section 5.4.2), copying the addresses in the
-   request into the caddr of the response, placing any required pre-
-   authentication data into the padata of the response, and encrypts the
-   ciphertext part in the client's key using an acceptable encryption
-   method requested in the etype field of the request, or in some key
-   specified by pre-authentication mechanisms being used.
-
-3.1.4.  Generation of KRB_ERROR Message
-
-   Several errors can occur, and the Authentication Server responds by
-   returning an error message, KRB_ERROR, to the client, with the
-   error-code and e-text fields set to appropriate values.  The error
-   message contents and details are described in Section 5.9.1.
-
-3.1.5.  Receipt of KRB_AS_REP Message
-
-   If the reply message type is KRB_AS_REP, then the client verifies
-   that the cname and crealm fields in the cleartext portion of the
-   reply match what it requested.  If any padata fields are present,
-   they may be used to derive the proper secret key to decrypt the
-
-
-
-Neuman, et al.              Standards Track                    [Page 27]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   message.  The client decrypts the encrypted part of the response
-   using its secret key and verifies that the nonce in the encrypted
-   part matches the nonce it supplied in its request (to detect
-   replays).  It also verifies that the sname and srealm in the response
-   match those in the request (or are otherwise expected values), and
-   that the host address field is also correct.  It then stores the
-   ticket, session key, start and expiration times, and other
-   information for later use.  The last-req field (and the deprecated
-   key-expiration field) from the encrypted part of the response MAY be
-   checked to notify the user of impending key expiration.  This enables
-   the client program to suggest remedial action, such as a password
-   change.
-
-   Upon validation of the KRB_AS_REP message (by checking the returned
-   nonce against that sent in the KRB_AS_REQ message), the client knows
-   that the current time on the KDC is that read from the authtime field
-   of the encrypted part of the reply.  The client can optionally use
-   this value for clock synchronization in subsequent messages by
-   recording with the ticket the difference (offset) between the
-   authtime value and the local clock.  This offset can then be used by
-   the same user to adjust the time read from the system clock when
-   generating messages [DGT96].
-
-   This technique MUST be used when adjusting for clock skew instead of
-   directly changing the system clock, because the KDC reply is only
-   authenticated to the user whose secret key was used, but not to the
-   system or workstation.  If the clock were adjusted, an attacker
-   colluding with a user logging into a workstation could agree on a
-   password, resulting in a KDC reply that would be correctly validated
-   even though it did not originate from a KDC trusted by the
-   workstation.
-
-   Proper decryption of the KRB_AS_REP message is not sufficient for the
-   host to verify the identity of the user; the user and an attacker
-   could cooperate to generate a KRB_AS_REP format message that decrypts
-   properly but is not from the proper KDC.  If the host wishes to
-   verify the identity of the user, it MUST require the user to present
-   application credentials that can be verified using a securely-stored
-   secret key for the host.  If those credentials can be verified, then
-   the identity of the user can be assured.
-
-3.1.6.  Receipt of KRB_ERROR Message
-
-   If the reply message type is KRB_ERROR, then the client interprets it
-   as an error and performs whatever application-specific tasks are
-   necessary for recovery.
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 28]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-3.2.  The Client/Server Authentication Exchange
-
-                                Summary
-
-   Message direction                         Message type    Section
-   Client to Application server              KRB_AP_REQ      5.5.1
-   [optional] Application server to client   KRB_AP_REP or   5.5.2
-                                             KRB_ERROR       5.9.1
-
-   The client/server authentication (CS) exchange is used by network
-   applications to authenticate the client to the server and vice versa.
-   The client MUST have already acquired credentials for the server
-   using the AS or TGS exchange.
-
-3.2.1.  The KRB_AP_REQ Message
-
-   The KRB_AP_REQ contains authentication information that SHOULD be
-   part of the first message in an authenticated transaction.  It
-   contains a ticket, an authenticator, and some additional bookkeeping
-   information (see Section 5.5.1 for the exact format).  The ticket by
-   itself is insufficient to authenticate a client, since tickets are
-   passed across the network in cleartext (tickets contain both an
-   encrypted and unencrypted portion, so cleartext here refers to the
-   entire unit, which can be copied from one message and replayed in
-   another without any cryptographic skill).  The authenticator is used
-   to prevent invalid replay of tickets by proving to the server that
-   the client knows the session key of the ticket and thus is entitled
-   to use the ticket.  The KRB_AP_REQ message is referred to elsewhere
-   as the 'authentication header'.
-
-3.2.2.  Generation of a KRB_AP_REQ Message
-
-   When a client wishes to initiate authentication to a server, it
-   obtains (either through a credentials cache, the AS exchange, or the
-   TGS exchange) a ticket and session key for the desired service.  The
-   client MAY re-use any tickets it holds until they expire.  To use a
-   ticket, the client constructs a new Authenticator from the system
-   time and its name, and optionally from an application-specific
-   checksum, an initial sequence number to be used in KRB_SAFE or
-   KRB_PRIV messages, and/or a session subkey to be used in negotiations
-   for a session key unique to this particular session.  Authenticators
-   MUST NOT be re-used and SHOULD be rejected if replayed to a server.
-   Note that this can make applications based on unreliable transports
-   difficult to code correctly.  If the transport might deliver
-   duplicated messages, either a new authenticator MUST be generated for
-   each retry, or the application server MUST match requests and replies
-   and replay the first reply in response to a detected duplicate.
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 29]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   If a sequence number is to be included, it SHOULD be randomly chosen
-   so that even after many messages have been exchanged it is not likely
-   to collide with other sequence numbers in use.
-
-   The client MAY indicate a requirement of mutual authentication or the
-   use of a session-key based ticket (for user-to-user authentication,
-   see section 3.7) by setting the appropriate flag(s) in the ap-options
-   field of the message.
-
-   The Authenticator is encrypted in the session key and combined with
-   the ticket to form the KRB_AP_REQ message, which is then sent to the
-   end server along with any additional application-specific
-   information.
-
-3.2.3.  Receipt of KRB_AP_REQ Message
-
-   Authentication is based on the server's current time of day (clocks
-   MUST be loosely synchronized), the authenticator, and the ticket.
-   Several errors are possible.  If an error occurs, the server is
-   expected to reply to the client with a KRB_ERROR message.  This
-   message MAY be encapsulated in the application protocol if its raw
-   form is not acceptable to the protocol.  The format of error messages
-   is described in Section 5.9.1.
-
-   The algorithm for verifying authentication information is as follows.
-   If the message type is not KRB_AP_REQ, the server returns the
-   KRB_AP_ERR_MSG_TYPE error.  If the key version indicated by the
-   Ticket in the KRB_AP_REQ is not one the server can use (e.g., it
-   indicates an old key, and the server no longer possesses a copy of
-   the old key), the KRB_AP_ERR_BADKEYVER error is returned.  If the
-   USE-SESSION-KEY flag is set in the ap-options field, it indicates to
-   the server that user-to-user authentication is in use, and that the
-   ticket is encrypted in the session key from the server's TGT rather
-   than in the server's secret key.  See Section 3.7 for a more complete
-   description of the effect of user-to-user authentication on all
-   messages in the Kerberos protocol.
-
-   Because it is possible for the server to be registered in multiple
-   realms, with different keys in each, the srealm field in the
-   unencrypted portion of the ticket in the KRB_AP_REQ is used to
-   specify which secret key the server should use to decrypt that
-   ticket.  The KRB_AP_ERR_NOKEY error code is returned if the server
-   doesn't have the proper key to decipher the ticket.
-
-   The ticket is decrypted using the version of the server's key
-   specified by the ticket.  If the decryption routines detect a
-   modification of the ticket (each encryption system MUST provide
-   safeguards to detect modified ciphertext), the
-
-
-
-Neuman, et al.              Standards Track                    [Page 30]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that
-   different keys were used to encrypt and decrypt).
-
-   The authenticator is decrypted using the session key extracted from
-   the decrypted ticket.  If decryption shows that is has been modified,
-   the KRB_AP_ERR_BAD_INTEGRITY error is returned.  The name and realm
-   of the client from the ticket are compared against the same fields in
-   the authenticator.  If they don't match, the KRB_AP_ERR_BADMATCH
-   error is returned; normally this is caused by a client error or an
-   attempted attack.  The addresses in the ticket (if any) are then
-   searched for an address matching the operating-system reported
-   address of the client.  If no match is found or the server insists on
-   ticket addresses but none are present in the ticket, the
-   KRB_AP_ERR_BADADDR error is returned.  If the local (server) time and
-   the client time in the authenticator differ by more than the
-   allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is
-   returned.
-
-   Unless the application server provides its own suitable means to
-   protect against replay (for example, a challenge-response sequence
-   initiated by the server after authentication, or use of a server-
-   generated encryption subkey), the server MUST utilize a replay cache
-   to remember any authenticator presented within the allowable clock
-   skew.  Careful analysis of the application protocol and
-   implementation is recommended before eliminating this cache.  The
-   replay cache will store at least the server name, along with the
-   client name, time, and microsecond fields from the recently-seen
-   authenticators, and if a matching tuple is found, the
-   KRB_AP_ERR_REPEAT error is returned.  Note that the rejection here is
-   restricted to authenticators from the same principal to the same
-   server.  Other client principals communicating with the same server
-   principal should not have their authenticators rejected if the time
-   and microsecond fields happen to match some other client's
-   authenticator.
-
-   If a server loses track of authenticators presented within the
-   allowable clock skew, it MUST reject all requests until the clock
-   skew interval has passed, providing assurance that any lost or
-   replayed authenticators will fall outside the allowable clock skew
-   and can no longer be successfully replayed.  If this were not done,
-   an attacker could subvert the authentication by recording the ticket
-   and authenticator sent over the network to a server and replaying
-   them following an event that caused the server to lose track of
-   recently seen authenticators.
-
-   Implementation note: If a client generates multiple requests to the
-   KDC with the same timestamp, including the microsecond field, all but
-   the first of the requests received will be rejected as replays.  This
-
-
-
-Neuman, et al.              Standards Track                    [Page 31]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   might happen, for example, if the resolution of the client's clock is
-   too coarse.  Client implementations SHOULD ensure that the timestamps
-   are not reused, possibly by incrementing the microseconds field in
-   the time stamp when the clock returns the same time for multiple
-   requests.
-
-   If multiple servers (for example, different services on one machine,
-   or a single service implemented on multiple machines) share a service
-   principal (a practice that we do not recommend in general, but that
-   we acknowledge will be used in some cases), either they MUST share
-   this replay cache, or the application protocol MUST be designed so as
-   to eliminate the need for it.  Note that this applies to all of the
-   services.  If any of the application protocols does not have replay
-   protection built in, an authenticator used with such a service could
-   later be replayed to a different service with the same service
-   principal but no replay protection, if the former doesn't record the
-   authenticator information in the common replay cache.
-
-   If a sequence number is provided in the authenticator, the server
-   saves it for later use in processing KRB_SAFE and/or KRB_PRIV
-   messages.  If a subkey is present, the server either saves it for
-   later use or uses it to help generate its own choice for a subkey to
-   be returned in a KRB_AP_REP message.
-
-   The server computes the age of the ticket: local (server) time minus
-   the starttime inside the Ticket.  If the starttime is later than the
-   current time by more than the allowable clock skew, or if the INVALID
-   flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned.
-   Otherwise, if the current time is later than end time by more than
-   the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is
-   returned.
-
-   If all these checks succeed without an error, the server is assured
-   that the client possesses the credentials of the principal named in
-   the ticket, and thus, that the client has been authenticated to the
-   server.
-
-   Passing these checks provides only authentication of the named
-   principal; it does not imply authorization to use the named service.
-   Applications MUST make a separate authorization decision based upon
-   the authenticated name of the user, the requested operation, local
-   access control information such as that contained in a .k5login or
-   .k5users file, and possibly a separate distributed authorization
-   service.
-
-
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 32]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-3.2.4.  Generation of a KRB_AP_REP Message
-
-   Typically, a client's request will include both the authentication
-   information and its initial request in the same message, and the
-   server need not explicitly reply to the KRB_AP_REQ.  However, if
-   mutual authentication (authenticating not only the client to the
-   server, but also the server to the client) is being performed, the
-   KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options
-   field, and a KRB_AP_REP message is required in response.  As with the
-   error message, this message MAY be encapsulated in the application
-   protocol if its "raw" form is not acceptable to the application's
-   protocol.  The timestamp and microsecond field used in the reply MUST
-   be the client's timestamp and microsecond field (as provided in the
-   authenticator).  If a sequence number is to be included, it SHOULD be
-   randomly chosen as described above for the authenticator.  A subkey
-   MAY be included if the server desires to negotiate a different
-   subkey.  The KRB_AP_REP message is encrypted in the session key
-   extracted from the ticket.
-
-   Note that in the Kerberos Version 4 protocol, the timestamp in the
-   reply was the client's timestamp plus one.  This is not necessary in
-   Version 5 because Version 5 messages are formatted in such a way that
-   it is not possible to create the reply by judicious message surgery
-   (even in encrypted form) without knowledge of the appropriate
-   encryption keys.
-
-3.2.5.  Receipt of KRB_AP_REP Message
-
-   If a KRB_AP_REP message is returned, the client uses the session key
-   from the credentials obtained for the server to decrypt the message
-   and verifies that the timestamp and microsecond fields match those in
-   the Authenticator it sent to the server.  If they match, then the
-   client is assured that the server is genuine.  The sequence number
-   and subkey (if present) are retained for later use.  (Note that for
-   encrypting the KRB_AP_REP message, the sub-session key is not used,
-   even if it is present in the Authentication.)
-
-3.2.6.  Using the Encryption Key
-
-   After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
-   server share an encryption key that can be used by the application.
-   In some cases, the use of this session key will be implicit in the
-   protocol; in others the method of use must be chosen from several
-   alternatives.  The application MAY choose the actual encryption key
-   to be used for KRB_PRIV, KRB_SAFE, or other application-specific uses
-   based on the session key from the ticket and subkeys in the
-   KRB_AP_REP message and the authenticator.  Implementations of the
-   protocol MAY provide routines to choose subkeys based on session keys
-
-
-
-Neuman, et al.              Standards Track                    [Page 33]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   and random numbers and to generate a negotiated key to be returned in
-   the KRB_AP_REP message.
-
-   To mitigate the effect of failures in random number generation on the
-   client, it is strongly encouraged that any key derived by an
-   application for subsequent use include the full key entropy derived
-   from the KDC-generated session key carried in the ticket.  We leave
-   the protocol negotiations of how to use the key (e.g., for selecting
-   an encryption or checksum type) to the application programmer.  The
-   Kerberos protocol does not constrain the implementation options, but
-   an example of how this might be done follows.
-
-   One way that an application may choose to negotiate a key to be used
-   for subsequent integrity and privacy protection is for the client to
-   propose a key in the subkey field of the authenticator.  The server
-   can then choose a key using the key proposed by the client as input,
-   returning the new subkey in the subkey field of the application
-   reply.  This key could then be used for subsequent communication.
-
-   With both the one-way and mutual authentication exchanges, the peers
-   should take care not to send sensitive information to each other
-   without proper assurances.  In particular, applications that require
-   privacy or integrity SHOULD use the KRB_AP_REP response from the
-   server to the client to assure both client and server of their peer's
-   identity.  If an application protocol requires privacy of its
-   messages, it can use the KRB_PRIV message (section 3.5).  The
-   KRB_SAFE message (Section 3.4) can be used to ensure integrity.
-
-3.3.  The Ticket-Granting Service (TGS) Exchange
-
-                             Summary
-
-         Message direction       Message type     Section
-         1. Client to Kerberos   KRB_TGS_REQ      5.4.1
-         2. Kerberos to client   KRB_TGS_REP or   5.4.2
-                                 KRB_ERROR        5.9.1
-
-   The TGS exchange between a client and the Kerberos TGS is initiated
-   by a client when it seeks to obtain authentication credentials for a
-   given server (which might be registered in a remote realm), when it
-   seeks to renew or validate an existing ticket, or when it seeks to
-   obtain a proxy ticket.  In the first case, the client must already
-   have acquired a ticket for the Ticket-Granting Service using the AS
-   exchange (the TGT is usually obtained when a client initially
-   authenticates to the system, such as when a user logs in).  The
-   message format for the TGS exchange is almost identical to that for
-   the AS exchange.  The primary difference is that encryption and
-   decryption in the TGS exchange does not take place under the client's
-
-
-
-Neuman, et al.              Standards Track                    [Page 34]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   key.  Instead, the session key from the TGT or renewable ticket, or
-   sub-session key from an Authenticator is used.  As is the case for
-   all application servers, expired tickets are not accepted by the TGS,
-   so once a renewable or TGT expires, the client must use a separate
-   exchange to obtain valid tickets.
-
-   The TGS exchange consists of two messages: a request (KRB_TGS_REQ)
-   from the client to the Kerberos Ticket-Granting Server, and a reply
-   (KRB_TGS_REP or KRB_ERROR).  The KRB_TGS_REQ message includes
-   information authenticating the client plus a request for credentials.
-   The authentication information consists of the authentication header
-   (KRB_AP_REQ), which includes the client's previously obtained
-   ticket-granting, renewable, or invalid ticket.  In the TGT and proxy
-   cases, the request MAY include one or more of the following: a list
-   of network addresses, a collection of typed authorization data to be
-   sealed in the ticket for authorization use by the application server,
-   or additional tickets (the use of which are described later).  The
-   TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted
-   in the session key from the TGT or renewable ticket, or, if present,
-   in the sub-session key from the Authenticator (part of the
-   authentication header).  The KRB_ERROR message contains an error code
-   and text explaining what went wrong.  The KRB_ERROR message is not
-   encrypted.  The KRB_TGS_REP message contains information that can be
-   used to detect replays, and to associate it with the message to which
-   it replies.  The KRB_ERROR message also contains information that can
-   be used to associate it with the message to which it replies.  The
-   same comments about integrity protection of KRB_ERROR messages
-   mentioned in Section 3.1 apply to the TGS exchange.
-
-3.3.1.  Generation of KRB_TGS_REQ Message
-
-   Before sending a request to the ticket-granting service, the client
-   MUST determine in which realm the application server is believed to
-   be registered.  This can be accomplished in several ways.  It might
-   be known beforehand (since the realm is part of the principal
-   identifier), it might be stored in a nameserver, or it might be
-   obtained from a configuration file.  If the realm to be used is
-   obtained from a nameserver, there is a danger of being spoofed if the
-   nameservice providing the realm name is not authenticated.  This
-   might result in the use of a realm that has been compromised, which
-   would result in an attacker's ability to compromise the
-   authentication of the application server to the client.
-
-   If the client knows the service principal name and realm and it does
-   not already possess a TGT for the appropriate realm, then one must be
-   obtained.  This is first attempted by requesting a TGT for the
-   destination realm from a Kerberos server for which the client
-   possesses a TGT (by using the KRB_TGS_REQ message recursively).  The
-
-
-
-Neuman, et al.              Standards Track                    [Page 35]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Kerberos server MAY return a TGT for the desired realm, in which case
-   one can proceed.  Alternatively, the Kerberos server MAY return a TGT
-   for a realm that is 'closer' to the desired realm (further along the
-   standard hierarchical path between the client's realm and the
-   requested realm server's realm).  Note that in this case
-   misconfiguration of the Kerberos servers may cause loops in the
-   resulting authentication path, which the client should be careful to
-   detect and avoid.
-
-   If the Kerberos server returns a TGT for a realm 'closer' than the
-   desired realm, the client MAY use local policy configuration to
-   verify that the authentication path used is an acceptable one.
-   Alternatively, a client MAY choose its own authentication path,
-   rather than rely on the Kerberos server to select one.  In either
-   case, any policy or configuration information used to choose or
-   validate authentication paths, whether by the Kerberos server or by
-   the client, MUST be obtained from a trusted source.
-
-   When a client obtains a TGT that is 'closer' to the destination
-   realm, the client MAY cache this ticket and reuse it in future
-   KRB-TGS exchanges with services in the 'closer' realm.  However, if
-   the client were to obtain a TGT for the 'closer' realm by starting at
-   the initial KDC rather than as part of obtaining another ticket, then
-   a shorter path to the 'closer' realm might be used.  This shorter
-   path may be desirable because fewer intermediate KDCs would know the
-   session key of the ticket involved.  For this reason, clients SHOULD
-   evaluate whether they trust the realms transited in obtaining the
-   'closer' ticket when making a decision to use the ticket in future.
-
-   Once the client obtains a TGT for the appropriate realm, it
-   determines which Kerberos servers serve that realm and contacts one
-   of them.  The list might be obtained through a configuration file or
-   network service, or it MAY be generated from the name of the realm.
-   As long as the secret keys exchanged by realms are kept secret, only
-   denial of service results from using a false Kerberos server.
-
-   As in the AS exchange, the client MAY specify a number of options in
-   the KRB_TGS_REQ message.  One of these options is the ENC-TKT-IN-SKEY
-   option used for user-to-user authentication.  An overview of user-
-   to-user authentication can be found in Section 3.7.  When generating
-   the KRB_TGS_REQ message, this option indicates that the client is
-   including a TGT obtained from the application server in the
-   additional tickets field of the request and that the KDC SHOULD
-   encrypt the ticket for the application server using the session key
-   from this additional ticket, instead of a server key from the
-   principal database.
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 36]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   The client prepares the KRB_TGS_REQ message, providing an
-   authentication header as an element of the padata field, and
-   including the same fields as used in the KRB_AS_REQ message along
-   with several optional fields: the enc-authorizatfion-data field for
-   application server use and additional tickets required by some
-   options.
-
-   In preparing the authentication header, the client can select a sub-
-   session key under which the response from the Kerberos server will be
-   encrypted.  If the client selects a sub-session key, care must be
-   taken to ensure the randomness of the selected sub-session key.
-
-   If the sub-session key is not specified, the session key from the TGT
-   will be used.  If the enc-authorization-data is present, it MUST be
-   encrypted in the sub-session key, if present, from the authenticator
-   portion of the authentication header, or, if not present, by using
-   the session key from the TGT.
-
-   Once prepared, the message is sent to a Kerberos server for the
-   destination realm.
-
-3.3.2.  Receipt of KRB_TGS_REQ Message
-
-   The KRB_TGS_REQ message is processed in a manner similar to the
-   KRB_AS_REQ message, but there are many additional checks to be
-   performed.  First, the Kerberos server MUST determine which server
-   the accompanying ticket is for, and it MUST select the appropriate
-   key to decrypt it.  For a normal KRB_TGS_REQ message, it will be for
-   the ticket-granting service, and the TGS's key will be used.  If the
-   TGT was issued by another realm, then the appropriate inter-realm key
-   MUST be used.  If (a) the accompanying ticket is not a TGT for the
-   current realm, but is for an application server in the current realm,
-   (b) the RENEW, VALIDATE, or PROXY options are specified in the
-   request, and (c) the server for which a ticket is requested is the
-   server named in the accompanying ticket, then the KDC will decrypt
-   the ticket in the authentication header using the key of the server
-   for which it was issued.  If no ticket can be found in the padata
-   field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
-
-   Once the accompanying ticket has been decrypted, the user-supplied
-   checksum in the Authenticator MUST be verified against the contents
-   of the request, and the message MUST be rejected if the checksums do
-   not match (with an error code of KRB_AP_ERR_MODIFIED) or if the
-   checksum is not collision-proof (with an error code of
-   KRB_AP_ERR_INAPP_CKSUM).  If the checksum type is not supported, the
-   KDC_ERR_SUMTYPE_NOSUPP error is returned.  If the authorization-data
-   are present, they are decrypted using the sub-session key from the
-   Authenticator.
-
-
-
-Neuman, et al.              Standards Track                    [Page 37]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   If any of the decryptions indicate failed integrity checks, the
-   KRB_AP_ERR_BAD_INTEGRITY error is returned.
-
-   As discussed in Section 3.1.2, the KDC MUST send a valid KRB_TGS_REP
-   message if it receives a KRB_TGS_REQ message identical to one it has
-   recently processed.  However, if the authenticator is a replay, but
-   the rest of the request is not identical, then the KDC SHOULD return
-   KRB_AP_ERR_REPEAT.
-
-3.3.3.  Generation of KRB_TGS_REP Message
-
-   The KRB_TGS_REP message shares its format with the KRB_AS_REP
-   (KRB_KDC_REP), but with its type field set to KRB_TGS_REP.  The
-   detailed specification is in Section 5.4.2.
-
-   The response will include a ticket for the requested server or for a
-   ticket granting server of an intermediate KDC to be contacted to
-   obtain the requested ticket.  The Kerberos database is queried to
-   retrieve the record for the appropriate server (including the key
-   with which the ticket will be encrypted).  If the request is for a
-   TGT for a remote realm, and if no key is shared with the requested
-   realm, then the Kerberos server will select the realm 'closest' to
-   the requested realm with which it does share a key and use that realm
-   instead.  This is the only case where the response for the KDC will
-   be for a different server than that requested by the client.
-
-   By default, the address field, the client's name and realm, the list
-   of transited realms, the time of initial authentication, the
-   expiration time, and the authorization data of the newly-issued
-   ticket will be copied from the TGT or renewable ticket.  If the
-   transited field needs to be updated, but the transited type is not
-   supported, the KDC_ERR_TRTYPE_NOSUPP error is returned.
-
-   If the request specifies an endtime, then the endtime of the new
-   ticket is set to the minimum of (a) that request, (b) the endtime
-   from the TGT, and (c) the starttime of the TGT plus the minimum of
-   the maximum life for the application server and the maximum life for
-   the local realm (the maximum life for the requesting principal was
-   already applied when the TGT was issued).  If the new ticket is to be
-   a renewal, then the endtime above is replaced by the minimum of (a)
-   the value of the renew_till field of the ticket and (b) the starttime
-   for the new ticket plus the life (endtime-starttime) of the old
-   ticket.
-
-   If the FORWARDED option has been requested, then the resulting ticket
-   will contain the addresses specified by the client.  This option will
-   only be honored if the FORWARDABLE flag is set in the TGT.  The PROXY
-   option is similar; the resulting ticket will contain the addresses
-
-
-
-Neuman, et al.              Standards Track                    [Page 38]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   specified by the client.  It will be honored only if the PROXIABLE
-   flag in the TGT is set.  The PROXY option will not be honored on
-   requests for additional TGTs.
-
-   If the requested starttime is absent, indicates a time in the past,
-   or is within the window of acceptable clock skew for the KDC and the
-   POSTDATE option has not been specified, then the starttime of the
-   ticket is set to the authentication server's current time.  If it
-   indicates a time in the future beyond the acceptable clock skew, but
-   the POSTDATED option has not been specified or the MAY-POSTDATE flag
-   is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is
-   returned.  Otherwise, if the TGT has the MAY-POSTDATE flag set, then
-   the resulting ticket will be postdated, and the requested starttime
-   is checked against the policy of the local realm.  If acceptable, the
-   ticket's starttime is set as requested, and the INVALID flag is set.
-   The postdated ticket MUST be validated before use by presenting it to
-   the KDC after the starttime has been reached.  However, in no case
-   may the starttime, endtime, or renew-till time of a newly-issued
-   postdated ticket extend beyond the renew-till time of the TGT.
-
-   If the ENC-TKT-IN-SKEY option has been specified and an additional
-   ticket has been included in the request, it indicates that the client
-   is using user-to-user authentication to prove its identity to a
-   server that does not have access to a persistent key.  Section 3.7
-   describes the effect of this option on the entire Kerberos protocol.
-   When generating the KRB_TGS_REP message, this option in the
-   KRB_TGS_REQ message tells the KDC to decrypt the additional ticket
-   using the key for the server to which the additional ticket was
-   issued and to verify that it is a TGT.  If the name of the requested
-   server is missing from the request, the name of the client in the
-   additional ticket will be used.  Otherwise, the name of the requested
-   server will be compared to the name of the client in the additional
-   ticket.  If it is different, the request will be rejected.  If the
-   request succeeds, the session key from the additional ticket will be
-   used to encrypt the new ticket that is issued instead of using the
-   key of the server for which the new ticket will be used.
-
-   If (a) the name of the server in the ticket that is presented to the
-   KDC as part of the authentication header is not that of the TGS
-   itself, (b) the server is registered in the realm of the KDC, and (c)
-   the RENEW option is requested, then the KDC will verify that the
-   RENEWABLE flag is set in the ticket, that the INVALID flag is not set
-   in the ticket, and that the renew_till time is still in the future.
-   If the VALIDATE option is requested, the KDC will check that the
-   starttime has passed and that the INVALID flag is set.  If the PROXY
-   option is requested, then the KDC will check that the PROXIABLE flag
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 39]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   is set in the ticket.  If the tests succeed and the ticket passes the
-   hotlist check described in the next section, the KDC will issue the
-   appropriate new ticket.
-
-   The ciphertext part of the response in the KRB_TGS_REP message is
-   encrypted in the sub-session key from the Authenticator, if present,
-   or in the session key from the TGT.  It is not encrypted using the
-   client's secret key.  Furthermore, the client's key's expiration date
-   and the key version number fields are left out since these values are
-   stored along with the client's database record, and that record is
-   not needed to satisfy a request based on a TGT.
-
-3.3.3.1.  Checking for Revoked Tickets
-
-   Whenever a request is made to the ticket-granting server, the
-   presented ticket(s) is (are) checked against a hot-list of tickets
-   that have been canceled.  This hot-list might be implemented by
-   storing a range of issue timestamps for 'suspect tickets'; if a
-   presented ticket had an authtime in that range, it would be rejected.
-   In this way, a stolen TGT or renewable ticket cannot be used to gain
-   additional tickets (renewals or otherwise) once the theft has been
-   reported to the KDC for the realm in which the server resides.  Any
-   normal ticket obtained before it was reported stolen will still be
-   valid (because tickets require no interaction with the KDC), but only
-   until its normal expiration time.  If TGTs have been issued for
-   cross-realm authentication, use of the cross-realm TGT will not be
-   affected unless the hot-list is propagated to the KDCs for the realms
-   for which such cross-realm tickets were issued.
-
-3.3.3.2.  Encoding the Transited Field
-
-   If the identity of the server in the TGT that is presented to the KDC
-   as part of the authentication header is that of the ticket-granting
-   service, but the TGT was issued from another realm, the KDC will look
-   up the inter-realm key shared with that realm and use that key to
-   decrypt the ticket.  If the ticket is valid, then the KDC will honor
-   the request, subject to the constraints outlined above in the section
-   describing the AS exchange.  The realm part of the client's identity
-   will be taken from the TGT.  The name of the realm that issued the
-   TGT, if it is not the realm of the client principal, will be added to
-   the transited field of the ticket to be issued.  This is accomplished
-   by reading the transited field from the TGT (which is treated as an
-   unordered set of realm names), adding the new realm to the set, and
-   then constructing and writing out its encoded (shorthand) form (this
-   may involve a rearrangement of the existing encoding).
-
-   Note that the ticket-granting service does not add the name of its
-   own realm.  Instead, its responsibility is to add the name of the
-
-
-
-Neuman, et al.              Standards Track                    [Page 40]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   previous realm.  This prevents a malicious Kerberos server from
-   intentionally leaving out its own name (it could, however, omit other
-   realms' names).
-
-   The names of neither the local realm nor the principal's realm are to
-   be included in the transited field.  They appear elsewhere in the
-   ticket and both are known to have taken part in authenticating the
-   principal.  Because the endpoints are not included, both local and
-   single-hop inter-realm authentication result in a transited field
-   that is empty.
-
-   Because this field has the name of each transited realm added to it,
-   it might potentially be very long.  To decrease the length of this
-   field, its contents are encoded.  The initially supported encoding is
-   optimized for the normal case of inter-realm communication: a
-   hierarchical arrangement of realms using either domain or X.500 style
-   realm names.  This encoding (called DOMAIN-X500-COMPRESS) is now
-   described.
-
-   Realm names in the transited field are separated by a ",".  The ",",
-   "\", trailing "."s, and leading spaces (" ") are special characters,
-   and if they are part of a realm name, they MUST be quoted in the
-   transited field by preceding them with a "\".
-
-   A realm name ending with a "." is interpreted as being prepended to
-   the previous realm.  For example, we can encode traversal of EDU,
-   MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
-
-      "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
-
-   Note that if either ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were
-   endpoints, they would not be included in this field, and we would
-   have:
-
-      "EDU,MIT.,WASHINGTON.EDU"
-
-   A realm name beginning with a "/" is interpreted as being appended to
-   the previous realm.  For the purpose of appending, the realm
-   preceding the first listed realm is considered the null realm ("").
-   If a realm name beginning with a "/" is to stand by itself, then it
-   SHOULD be preceded by a space (" ").  For example, we can encode
-   traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as:
-
-      "/COM,/HP,/APOLLO, /COM/DEC".
-
-   As in the example above, if /COM/HP/APOLLO and /COM/DEC were
-   endpoints, they would not be included in this field, and we would
-   have:
-
-
-
-Neuman, et al.              Standards Track                    [Page 41]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-      "/COM,/HP"
-
-   A null subfield preceding or following a "," indicates that all
-   realms between the previous realm and the next realm have been
-   traversed.  For the purpose of interpreting null subfields, the
-   client's realm is considered to precede those in the transited field,
-   and the server's realm is considered to follow them.  Thus, "," means
-   that all realms along the path between the client and the server have
-   been traversed.  ",EDU, /COM," means that all realms from the
-   client's realm up to EDU (in a domain style hierarchy) have been
-   traversed, and that everything from /COM down to the server's realm
-   in an X.500 style has also been traversed.  This could occur if the
-   EDU realm in one hierarchy shares an inter-realm key directly with
-   the /COM realm in another hierarchy.
-
-3.3.4.  Receipt of KRB_TGS_REP Message
-
-   When the KRB_TGS_REP is received by the client, it is processed in
-   the same manner as the KRB_AS_REP processing described above.  The
-   primary difference is that the ciphertext part of the response must
-   be decrypted using the sub-session key from the Authenticator, if it
-   was specified in the request, or the session key from the TGT, rather
-   than the client's secret key.  The server name returned in the reply
-   is the true principal name of the service.
-
-3.4.  The KRB_SAFE Exchange
-
-   The KRB_SAFE message MAY be used by clients requiring the ability to
-   detect modifications of messages they exchange.  It achieves this by
-   including a keyed collision-proof checksum of the user data and some
-   control information.  The checksum is keyed with an encryption key
-   (usually the last key negotiated via subkeys, or the session key if
-   no negotiation has occurred).
-
-3.4.1.  Generation of a KRB_SAFE Message
-
-   When an application wishes to send a KRB_SAFE message, it collects
-   its data and the appropriate control information and computes a
-   checksum over them.  The checksum algorithm should be the keyed
-   checksum mandated to be implemented along with the crypto system used
-   for the sub-session or session key.  The checksum is generated using
-   the sub-session key, if present, or the session key.  Some
-   implementations use a different checksum algorithm for the KRB_SAFE
-   messages, but doing so in an interoperable manner is not always
-   possible.
-
-   The control information for the KRB_SAFE message includes both a
-   timestamp and a sequence number.  The designer of an application
-
-
-
-Neuman, et al.              Standards Track                    [Page 42]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   using the KRB_SAFE message MUST choose at least one of the two
-   mechanisms.  This choice SHOULD be based on the needs of the
-   application protocol.
-
-   Sequence numbers are useful when all messages sent will be received
-   by one's peer.  Connection state is presently required to maintain
-   the session key, so maintaining the next sequence number should not
-   present an additional problem.
-
-   If the application protocol is expected to tolerate lost messages
-   without their being resent, the use of the timestamp is the
-   appropriate replay detection mechanism.  Using timestamps is also the
-   appropriate mechanism for multi-cast protocols in which all of one's
-   peers share a common sub-session key, but some messages will be sent
-   to a subset of one's peers.
-
-   After computing the checksum, the client then transmits the
-   information and checksum to the recipient in the message format
-   specified in Section 5.6.1.
-
-3.4.2.  Receipt of KRB_SAFE Message
-
-   When an application receives a KRB_SAFE message, it verifies it as
-   follows.  If any error occurs, an error code is reported for use by
-   the application.
-
-   The message is first checked by verifying that the protocol version
-   and type fields match the current version and KRB_SAFE, respectively.
-   A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
-   error.  The application verifies that the checksum used is a
-   collision-proof keyed checksum that uses keys compatible with the
-   sub-session or session key as appropriate (or with the application
-   key derived from the session or sub-session keys).  If it is not, a
-   KRB_AP_ERR_INAPP_CKSUM error is generated.  The sender's address MUST
-   be included in the control information; the recipient verifies that
-   the operating system's report of the sender's address matches the
-   sender's address in the message, and (if a recipient address is
-   specified or the recipient requires an address) that one of the
-   recipient's addresses appears as the recipient's address in the
-   message.  To work with network address translation, senders MAY use
-   the directional address type specified in Section 8.1 for the sender
-   address and not include recipient addresses.  A failed match for
-   either case generates a KRB_AP_ERR_BADADDR error.  Then the timestamp
-   and usec and/or the sequence number fields are checked.  If timestamp
-   and usec are expected and not present, or if they are present but not
-   current, the KRB_AP_ERR_SKEW error is generated.  Timestamps are not
-   required to be strictly ordered; they are only required to be in the
-   skew window.  If the server name, along with the client name, time,
-
-
-
-Neuman, et al.              Standards Track                    [Page 43]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   and microsecond fields from the Authenticator match any recently-seen
-   (sent or received) such tuples, the KRB_AP_ERR_REPEAT error is
-   generated.  If an incorrect sequence number is included, or if a
-   sequence number is expected but not present, the KRB_AP_ERR_BADORDER
-   error is generated.  If neither a time-stamp and usec nor a sequence
-   number is present, a KRB_AP_ERR_MODIFIED error is generated.
-   Finally, the checksum is computed over the data and control
-   information, and if it doesn't match the received checksum, a
-   KRB_AP_ERR_MODIFIED error is generated.
-
-   If all the checks succeed, the application is assured that the
-   message was generated by its peer and was not modified in transit.
-
-   Implementations SHOULD accept any checksum algorithm they implement
-   that has both adequate security and keys compatible with the sub-
-   session or session key.  Unkeyed or non-collision-proof checksums are
-   not suitable for this use.
-
-3.5.  The KRB_PRIV Exchange
-
-   The KRB_PRIV message MAY be used by clients requiring confidentiality
-   and the ability to detect modifications of exchanged messages.  It
-   achieves this by encrypting the messages and adding control
-   information.
-
-3.5.1.  Generation of a KRB_PRIV Message
-
-   When an application wishes to send a KRB_PRIV message, it collects
-   its data and the appropriate control information (specified in
-   Section 5.7.1) and encrypts them under an encryption key (usually the
-   last key negotiated via subkeys, or the session key if no negotiation
-   has occurred).  As part of the control information, the client MUST
-   choose to use either a timestamp or a sequence number (or both); see
-   the discussion in Section 3.4.1 for guidelines on which to use.
-   After the user data and control information are encrypted, the client
-   transmits the ciphertext and some 'envelope' information to the
-   recipient.
-
-3.5.2.  Receipt of KRB_PRIV Message
-
-   When an application receives a KRB_PRIV message, it verifies it as
-   follows.  If any error occurs, an error code is reported for use by
-   the application.
-
-   The message is first checked by verifying that the protocol version
-   and type fields match the current version and KRB_PRIV, respectively.
-   A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE
-   error.  The application then decrypts the ciphertext and processes
-
-
-
-Neuman, et al.              Standards Track                    [Page 44]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   the resultant plaintext.  If decryption shows that the data has been
-   modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated.
-
-   The sender's address MUST be included in the control information; the
-   recipient verifies that the operating system's report of the sender's
-   address matches the sender's address in the message.  If a recipient
-   address is specified or the recipient requires an address, then one
-   of the recipient's addresses MUST also appear as the recipient's
-   address in the message.  Where a sender's or receiver's address might
-   not otherwise match the address in a message because of network
-   address translation, an application MAY be written to use addresses
-   of the directional address type in place of the actual network
-   address.
-
-   A failed match for either case generates a KRB_AP_ERR_BADADDR error.
-   To work with network address translation, implementations MAY use the
-   directional address type defined in Section 7.1 for the sender
-   address and include no recipient address.
-
-   Next the timestamp and usec and/or the sequence number fields are
-   checked.  If timestamp and usec are expected and not present, or if
-   they are present but not current, the KRB_AP_ERR_SKEW error is
-   generated.  If the server name, along with the client name, time, and
-   microsecond fields from the Authenticator match any such recently-
-   seen tuples, the KRB_AP_ERR_REPEAT error is generated.  If an
-   incorrect sequence number is included, or if a sequence number is
-   expected but not present, the KRB_AP_ERR_BADORDER error is generated.
-   If neither a time-stamp and usec nor a sequence number is present, a
-   KRB_AP_ERR_MODIFIED error is generated.
-
-   If all the checks succeed, the application can assume the message was
-   generated by its peer and was securely transmitted (without intruders
-   seeing the unencrypted contents).
-
-3.6.  The KRB_CRED Exchange
-
-   The KRB_CRED message MAY be used by clients requiring the ability to
-   send Kerberos credentials from one host to another.  It achieves this
-   by sending the tickets together with encrypted data containing the
-   session keys and other information associated with the tickets.
-
-3.6.1.  Generation of a KRB_CRED Message
-
-   When an application wishes to send a KRB_CRED message, it first
-   (using the KRB_TGS exchange) obtains credentials to be sent to the
-   remote host.  It then constructs a KRB_CRED message using the ticket
-   or tickets so obtained, placing the session key needed to use each
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 45]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   ticket in the key field of the corresponding KrbCredInfo sequence of
-   the encrypted part of the KRB_CRED message.
-
-   Other information associated with each ticket and obtained during the
-   KRB_TGS exchange is also placed in the corresponding KrbCredInfo
-   sequence in the encrypted part of the KRB_CRED message.  The current
-   time and, if they are specifically required by the application, the
-   nonce, s-address, and r-address fields are placed in the encrypted
-   part of the KRB_CRED message, which is then encrypted under an
-   encryption key previously exchanged in the KRB_AP exchange (usually
-   the last key negotiated via subkeys, or the session key if no
-   negotiation has occurred).
-
-   Implementation note: When constructing a KRB_CRED message for
-   inclusion in a GSSAPI initial context token, the MIT implementation
-   of Kerberos will not encrypt the KRB_CRED message if the session key
-   is a DES or triple DES key.  For interoperability with MIT, the
-   Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI
-   token if it is using a DES session key.  Starting at version 1.2.5,
-   MIT Kerberos can receive and decode either encrypted or unencrypted
-   KRB_CRED tokens in the GSSAPI exchange.  The Heimdal implementation
-   of Kerberos can also accept either encrypted or unencrypted KRB_CRED
-   messages.  Since the KRB_CRED message in a GSSAPI token is encrypted
-   in the authenticator, the MIT behavior does not present a security
-   problem, although it is a violation of the Kerberos specification.
-
-3.6.2.  Receipt of KRB_CRED Message
-
-   When an application receives a KRB_CRED message, it verifies it.  If
-   any error occurs, an error code is reported for use by the
-   application.  The message is verified by checking that the protocol
-   version and type fields match the current version and KRB_CRED,
-   respectively.  A mismatch generates a KRB_AP_ERR_BADVERSION or
-   KRB_AP_ERR_MSG_TYPE error.  The application then decrypts the
-   ciphertext and processes the resultant plaintext.  If decryption
-   shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY
-   error is generated.
-
-   If present or required, the recipient MAY verify that the operating
-   system's report of the sender's address matches the sender's address
-   in the message, and that one of the recipient's addresses appears as
-   the recipient's address in the message.  The address check does not
-   provide any added security, since the address, if present, has
-   already been checked in the KRB_AP_REQ message and there is not any
-   benefit to be gained by an attacker in reflecting a KRB_CRED message
-   back to its originator.  Thus, the recipient MAY ignore the address
-   even if it is present in order to work better in Network Address
-   Translation (NAT) environments.  A failed match for either case
-
-
-
-Neuman, et al.              Standards Track                    [Page 46]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   generates a KRB_AP_ERR_BADADDR error.  Recipients MAY skip the
-   address check, as the KRB_CRED message cannot generally be reflected
-   back to the originator.  The timestamp and usec fields (and the nonce
-   field, if required) are checked next.  If the timestamp and usec are
-   not present, or if they are present but not current, the
-   KRB_AP_ERR_SKEW error is generated.
-
-   If all the checks succeed, the application stores each of the new
-   tickets in its credentials cache together with the session key and
-   other information in the corresponding KrbCredInfo sequence from the
-   encrypted part of the KRB_CRED message.
-
-3.7.  User-to-User Authentication Exchanges
-
-   User-to-User authentication provides a method to perform
-   authentication when the verifier does not have a access to long-term
-   service key.  This might be the case when running a server (for
-   example, a window server) as a user on a workstation.  In such cases,
-   the server may have access to the TGT obtained when the user logged
-   in to the workstation, but because the server is running as an
-   unprivileged user, it might not have access to system keys.  Similar
-   situations may arise when running peer-to-peer applications.
-
-                             Summary
-
-       Message direction                    Message type     Sections
-       0. Message from application server   Not specified
-       1. Client to Kerberos                KRB_TGS_REQ      3.3 & 5.4.1
-       2. Kerberos to client                KRB_TGS_REP or   3.3 & 5.4.2
-                                            KRB_ERROR        5.9.1
-       3. Client to application server      KRB_AP_REQ       3.2 & 5.5.1
-
-   To address this problem, the Kerberos protocol allows the client to
-   request that the ticket issued by the KDC be encrypted using a
-   session key from a TGT issued to the party that will verify the
-   authentication.  This TGT must be obtained from the verifier by means
-   of an exchange external to the Kerberos protocol, usually as part of
-   the application protocol.  This message is shown in the summary above
-   as message 0.  Note that because the TGT is encrypted in the KDC's
-   secret key, it cannot be used for authentication without possession
-   of the corresponding secret key.  Furthermore, because the verifier
-   does not reveal the corresponding secret key, providing a copy of the
-   verifier's TGT does not allow impersonation of the verifier.
-
-   Message 0 in the table above represents an application-specific
-   negotiation between the client and server, at the end of which both
-   have determined that they will use user-to-user authentication, and
-   the client has obtained the server's TGT.
-
-
-
-Neuman, et al.              Standards Track                    [Page 47]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Next, the client includes the server's TGT as an additional ticket in
-   its KRB_TGS_REQ request to the KDC (message 1 in the table above) and
-   specifies the ENC-TKT-IN-SKEY option in its request.
-
-   If validated according to the instructions in Section 3.3.3, the
-   application ticket returned to the client (message 2 in the table
-   above) will be encrypted using the session key from the additional
-   ticket and the client will note this when it uses or stores the
-   application ticket.
-
-   When contacting the server using a ticket obtained for user-to-user
-   authentication (message 3 in the table above), the client MUST
-   specify the USE-SESSION-KEY flag in the ap-options field.  This tells
-   the application server to use the session key associated with its TGT
-   to decrypt the server ticket provided in the application request.
-
-4.  Encryption and Checksum Specifications
-
-   The Kerberos protocols described in this document are designed to
-   encrypt messages of arbitrary sizes, using stream or block encryption
-   ciphers.  Encryption is used to prove the identities of the network
-   entities participating in message exchanges.  The Key Distribution
-   Center for each realm is trusted by all principals registered in that
-   realm to store a secret key in confidence.  Proof of knowledge of
-   this secret key is used to verify the authenticity of a principal.
-
-   The KDC uses the principal's secret key (in the AS exchange) or a
-   shared session key (in the TGS exchange) to encrypt responses to
-   ticket requests; the ability to obtain the secret key or session key
-   implies the knowledge of the appropriate keys and the identity of the
-   KDC.  The ability of a principal to decrypt the KDC response and to
-   present a Ticket and a properly formed Authenticator (generated with
-   the session key from the KDC response) to a service verifies the
-   identity of the principal; likewise the ability of the service to
-   extract the session key from the Ticket and to prove its knowledge
-   thereof in a response verifies the identity of the service.
-
-   [RFC3961] defines a framework for defining encryption and checksum
-   mechanisms for use with Kerberos.  It also defines several such
-   mechanisms, and more may be added in future updates to that document.
-
-   The string-to-key operation provided by [RFC3961] is used to produce
-   a long-term key for a principal (generally for a user).  The default
-   salt string, if none is provided via pre-authentication data, is the
-   concatenation of the principal's realm and name components, in order,
-   with no separators.  Unless it is indicated otherwise, the default
-   string-to-key opaque parameter set as defined in [RFC3961] is used.
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 48]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Encrypted data, keys, and checksums are transmitted using the
-   EncryptedData, EncryptionKey, and Checksum data objects defined in
-   Section 5.2.9.  The encryption, decryption, and checksum operations
-   described in this document use the corresponding encryption,
-   decryption, and get_mic operations described in [RFC3961], with
-   implicit "specific key" generation using the "key usage" values
-   specified in the description of each EncryptedData or Checksum object
-   to vary the key for each operation.  Note that in some cases, the
-   value to be used is dependent on the method of choosing the key or
-   the context of the message.
-
-   Key usages are unsigned 32-bit integers; zero is not permitted.  The
-   key usage values for encrypting or checksumming Kerberos messages are
-   indicated in Section 5 along with the message definitions.  The key
-   usage values 512-1023 are reserved for uses internal to a Kerberos
-   implementation.  (For example, seeding a pseudo-random number
-   generator with a value produced by encrypting something with a
-   session key and a key usage value not used for any other purpose.)
-   Key usage values between 1024 and 2047 (inclusive) are reserved for
-   application use; applications SHOULD use even values for encryption
-   and odd values for checksums within this range.  Key usage values are
-   also summarized in a table in Section 7.5.1.
-
-   There might exist other documents that define protocols in terms of
-   the RFC 1510 encryption types or checksum types.  These documents
-   would not know about key usages.  In order that these specifications
-   continue to be meaningful until they are updated, if no key usage
-   values are specified, then key usages 1024 and 1025 must be used to
-   derive keys for encryption and checksums, respectively.  (This does
-   not apply to protocols that do their own encryption independent of
-   this framework, by directly using the key resulting from the Kerberos
-   authentication exchange.)  New protocols defined in terms of the
-   Kerberos encryption and checksum types SHOULD use their own key usage
-   values.
-
-   Unless it is indicated otherwise, no cipher state chaining is done
-   from one encryption operation to another.
-
-   Implementation note: Although it is not recommended, some application
-   protocols will continue to use the key data directly, even if only in
-   currently existing protocol specifications.  An implementation
-   intended to support general Kerberos applications may therefore need
-   to make key data available, as well as the attributes and operations
-   described in [RFC3961].  One of the more common reasons for directly
-   performing encryption is direct control over negotiation and
-   selection of a "sufficiently strong" encryption algorithm (in the
-   context of a given application).  Although Kerberos does not directly
-   provide a facility for negotiating encryption types between the
-
-
-
-Neuman, et al.              Standards Track                    [Page 49]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   application client and server, there are approaches for using
-   Kerberos to facilitate this negotiation.  For example, a client may
-   request only "sufficiently strong" session key types from the KDC and
-   expect that any type returned by the KDC will be understood and
-   supported by the application server.
-
-5.  Message Specifications
-
-   The ASN.1 collected here should be identical to the contents of
-   Appendix A.  In the case of a conflict, the contents of Appendix A
-   shall take precedence.
-
-   The Kerberos protocol is defined here in terms of Abstract Syntax
-   Notation One (ASN.1) [X680], which provides a syntax for specifying
-   both the abstract layout of protocol messages as well as their
-   encodings.  Implementors not utilizing an existing ASN.1 compiler or
-   support library are cautioned to understand the actual ASN.1
-   specification thoroughly in order to ensure correct implementation
-   behavior.  There is more complexity in the notation than is
-   immediately obvious, and some tutorials and guides to ASN.1 are
-   misleading or erroneous.
-
-   Note that in several places, changes to abstract types from RFC 1510
-   have been made.  This is in part to address widespread assumptions
-   that various implementors have made, in some cases resulting in
-   unintentional violations of the ASN.1 standard.  These are clearly
-   flagged where they occur.  The differences between the abstract types
-   in RFC 1510 and abstract types in this document can cause
-   incompatible encodings to be emitted when certain encoding rules,
-   e.g., the Packed Encoding Rules (PER), are used.  This theoretical
-   incompatibility should not be relevant for Kerberos, since Kerberos
-   explicitly specifies the use of the Distinguished Encoding Rules
-   (DER).  It might be an issue for protocols seeking to use Kerberos
-   types with other encoding rules.  (This practice is not recommended.)
-   With very few exceptions (most notably the usages of BIT STRING), the
-   encodings resulting from using the DER remain identical between the
-   types defined in RFC 1510 and the types defined in this document.
-
-   The type definitions in this section assume an ASN.1 module
-   definition of the following form:
-
-
-
-
-
-
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 50]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   KerberosV5Spec2 {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2) modules(4) krb5spec2(2)
-   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-   -- rest of definitions here
-
-   END
-
-   This specifies that the tagging context for the module will be
-   explicit and non-automatic.
-
-   Note that in some other publications (such as [RFC1510] and
-   [RFC1964]), the "dod" portion of the object identifier is erroneously
-   specified as having the value "5".  In the case of RFC 1964, use of
-   the "correct" OID value would result in a change in the wire
-   protocol; therefore, it remains unchanged for now.
-
-   Note that elsewhere in this document, nomenclature for various
-   message types is inconsistent, but it largely follows C language
-   conventions, including use of underscore (_) characters and all-caps
-   spelling of names intended to be numeric constants.  Also, in some
-   places, identifiers (especially those referring to constants) are
-   written in all-caps in order to distinguish them from surrounding
-   explanatory text.
-
-   The ASN.1 notation does not permit underscores in identifiers, so in
-   actual ASN.1 definitions, underscores are replaced with hyphens (-).
-   Additionally, structure member names and defined values in ASN.1 MUST
-   begin with a lowercase letter, whereas type names MUST begin with an
-   uppercase letter.
-
-5.1.  Specific Compatibility Notes on ASN.1
-
-   For compatibility purposes, implementors should heed the following
-   specific notes regarding the use of ASN.1 in Kerberos.  These notes
-   do not describe deviations from standard usage of ASN.1.  The purpose
-   of these notes is instead to describe some historical quirks and
-   non-compliance of various implementations, as well as historical
-   ambiguities, which, although they are valid ASN.1, can lead to
-   confusion during implementation.
-
-5.1.1.  ASN.1 Distinguished Encoding Rules
-
-   The encoding of Kerberos protocol messages shall obey the
-   Distinguished Encoding Rules (DER) of ASN.1 as described in [X690].
-   Some implementations (believed primarily to be those derived from DCE
-   1.1 and earlier) are known to use the more general Basic Encoding
-
-
-
-Neuman, et al.              Standards Track                    [Page 51]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Rules (BER); in particular, these implementations send indefinite
-   encodings of lengths.  Implementations MAY accept such encodings in
-   the interest of backward compatibility, though implementors are
-   warned that decoding fully-general BER is fraught with peril.
-
-5.1.2.  Optional Integer Fields
-
-   Some implementations do not internally distinguish between an omitted
-   optional integer value and a transmitted value of zero.  The places
-   in the protocol where this is relevant include various microseconds
-   fields, nonces, and sequence numbers.  Implementations SHOULD treat
-   omitted optional integer values as having been transmitted with a
-   value of zero, if the application is expecting this.
-
-5.1.3.  Empty SEQUENCE OF Types
-
-   There are places in the protocol where a message contains a SEQUENCE
-   OF type as an optional member.  This can result in an encoding that
-   contains an empty SEQUENCE OF encoding.  The Kerberos protocol does
-   not semantically distinguish between an absent optional SEQUENCE OF
-   type and a present optional but empty SEQUENCE OF type.
-   Implementations SHOULD NOT send empty SEQUENCE OF encodings that are
-   marked OPTIONAL, but SHOULD accept them as being equivalent to an
-   omitted OPTIONAL type.  In the ASN.1 syntax describing Kerberos
-   messages, instances of these problematic optional SEQUENCE OF types
-   are indicated with a comment.
-
-5.1.4.  Unrecognized Tag Numbers
-
-   Future revisions to this protocol may include new message types with
-   different APPLICATION class tag numbers.  Such revisions should
-   protect older implementations by only sending the message types to
-   parties that are known to understand them; e.g., by means of a flag
-   bit set by the receiver in a preceding request.  In the interest of
-   robust error handling, implementations SHOULD gracefully handle
-   receiving a message with an unrecognized tag anyway, and return an
-   error message, if appropriate.
-
-   In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the
-   incorrect tag is sent over a TCP transport.  The KDCs SHOULD NOT
-   respond to messages received with an unknown tag over UDP transport
-   in order to avoid denial of service attacks.  For non-KDC
-   applications, the Kerberos implementation typically indicates an
-   error to the application which takes appropriate steps based on the
-   application protocol.
-
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 52]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-5.1.5.  Tag Numbers Greater Than 30
-
-   A naive implementation of a DER ASN.1 decoder may experience problems
-   with ASN.1 tag numbers greater than 30, due to such tag numbers being
-   encoded using more than one byte.  Future revisions of this protocol
-   may utilize tag numbers greater than 30, and implementations SHOULD
-   be prepared to gracefully return an error, if appropriate, when they
-   do not recognize the tag.
-
-5.2.  Basic Kerberos Types
-
-   This section defines a number of basic types that are potentially
-   used in multiple Kerberos protocol messages.
-
-5.2.1.  KerberosString
-
-   The original specification of the Kerberos protocol in RFC 1510 uses
-   GeneralString in numerous places for human-readable string data.
-   Historical implementations of Kerberos cannot utilize the full power
-   of GeneralString.  This ASN.1 type requires the use of designation
-   and invocation escape sequences as specified in ISO-2022/ECMA-35
-   [ISO-2022/ECMA-35] to switch character sets, and the default
-   character set that is designated as G0 is the ISO-646/ECMA-6
-   [ISO-646/ECMA-6] International Reference Version (IRV) (a.k.a. U.S.
-   ASCII), which mostly works.
-
-   ISO-2022/ECMA-35 defines four character-set code elements (G0..G3)
-   and two Control-function code elements (C0..C1).  DER prohibits the
-   designation of character sets as any but the G0 and C0 sets.
-   Unfortunately, this seems to have the side effect of prohibiting the
-   use of ISO-8859 (ISO Latin) [ISO-8859] character sets or any other
-   character sets that utilize a 96-character set, as ISO-2022/ECMA-35
-   prohibits designating them as the G0 code element.  This side effect
-   is being investigated in the ASN.1 standards community.
-
-   In practice, many implementations treat GeneralStrings as if they
-   were 8-bit strings of whichever character set the implementation
-   defaults to, without regard to correct usage of character-set
-   designation escape sequences.  The default character set is often
-   determined by the current user's operating system-dependent locale.
-   At least one major implementation places unescaped UTF-8 encoded
-   Unicode characters in the GeneralString.  This failure to adhere to
-   the GeneralString specifications results in interoperability issues
-   when conflicting character encodings are utilized by the Kerberos
-   clients, services, and KDC.
-
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 53]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   This unfortunate situation is the result of improper documentation of
-   the restrictions of the ASN.1 GeneralString type in prior Kerberos
-   specifications.
-
-   The new (post-RFC 1510) type KerberosString, defined below, is a
-   GeneralString that is constrained to contain only characters in
-   IA5String.
-
-      KerberosString  ::= GeneralString (IA5String)
-
-   In general, US-ASCII control characters should not be used in
-   KerberosString.  Control characters SHOULD NOT be used in principal
-   names or realm names.
-
-   For compatibility, implementations MAY choose to accept GeneralString
-   values that contain characters other than those permitted by
-   IA5String, but they should be aware that character set designation
-   codes will likely be absent, and that the encoding should probably be
-   treated as locale-specific in almost every way.  Implementations MAY
-   also choose to emit GeneralString values that are beyond those
-   permitted by IA5String, but they should be aware that doing so is
-   extraordinarily risky from an interoperability perspective.
-
-   Some existing implementations use GeneralString to encode unescaped
-   locale-specific characters.  This is a violation of the ASN.1
-   standard.  Most of these implementations encode US-ASCII in the
-   left-hand half, so as long as the implementation transmits only
-   US-ASCII, the ASN.1 standard is not violated in this regard.  As soon
-   as such an implementation encodes unescaped locale-specific
-   characters with the high bit set, it violates the ASN.1 standard.
-
-   Other implementations have been known to use GeneralString to contain
-   a UTF-8 encoding.  This also violates the ASN.1 standard, since UTF-8
-   is a different encoding, not a 94 or 96 character "G" set as defined
-   by ISO 2022.  It is believed that these implementations do not even
-   use the ISO 2022 escape sequence to change the character encoding.
-   Even if implementations were to announce the encoding change by using
-   that escape sequence, the ASN.1 standard prohibits the use of any
-   escape sequences other than those used to designate/invoke "G" or "C"
-   sets allowed by GeneralString.
-
-   Future revisions to this protocol will almost certainly allow for a
-   more interoperable representation of principal names, probably
-   including UTF8String.
-
-   Note that applying a new constraint to a previously unconstrained
-   type constitutes creation of a new ASN.1 type.  In this particular
-   case, the change does not result in a changed encoding under DER.
-
-
-
-Neuman, et al.              Standards Track                    [Page 54]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-5.2.2.  Realm and PrincipalName
-
-   Realm           ::= KerberosString
-
-   PrincipalName   ::= SEQUENCE {
-           name-type       [0] Int32,
-           name-string     [1] SEQUENCE OF KerberosString
-   }
-
-   Kerberos realm names are encoded as KerberosStrings.  Realms shall
-   not contain a character with the code 0 (the US-ASCII NUL).  Most
-   realms will usually consist of several components separated by
-   periods (.), in the style of Internet Domain Names, or separated by
-   slashes (/), in the style of X.500 names.  Acceptable forms for realm
-   names are specified in Section 6.1.  A PrincipalName is a typed
-   sequence of components consisting of the following subfields:
-
-   name-type
-      This field specifies the type of name that follows.  Pre-defined
-      values for this field are specified in Section 6.2.  The name-type
-      SHOULD be treated as a hint.  Ignoring the name type, no two names
-      can be the same (i.e., at least one of the components, or the
-      realm, must be different).
-
-   name-string
-      This field encodes a sequence of components that form a name, each
-      component encoded as a KerberosString.  Taken together, a
-      PrincipalName and a Realm form a principal identifier.  Most
-      PrincipalNames will have only a few components (typically one or
-      two).
-
-5.2.3.  KerberosTime
-
-   KerberosTime    ::= GeneralizedTime -- with no fractional seconds
-
-   The timestamps used in Kerberos are encoded as GeneralizedTimes.  A
-   KerberosTime value shall not include any fractional portions of the
-   seconds.  As required by the DER, it further shall not include any
-   separators, and it shall specify the UTC time zone (Z).  Example: The
-   only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6
-   November 1985 is 19851106210627Z.
-
-5.2.4.  Constrained Integer Types
-
-   Some integer members of types SHOULD be constrained to values
-   representable in 32 bits, for compatibility with reasonable
-   implementation limits.
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 55]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Int32           ::= INTEGER (-2147483648..2147483647)
-                       -- signed values representable in 32 bits
-
-   UInt32          ::= INTEGER (0..4294967295)
-                       -- unsigned 32 bit values
-
-   Microseconds    ::= INTEGER (0..999999)
-                       -- microseconds
-
-   Although this results in changes to the abstract types from the RFC
-   1510 version, the encoding in DER should be unaltered.  Historical
-   implementations were typically limited to 32-bit integer values
-   anyway, and assigned numbers SHOULD fall in the space of integer
-   values representable in 32 bits in order to promote interoperability
-   anyway.
-
-   Several integer fields in messages are constrained to fixed values.
-
-   pvno
-      also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always
-      the constant integer 5.  There is no easy way to make this field
-      into a useful protocol version number, so its value is fixed.
-
-   msg-type
-      this integer field is usually identical to the application tag
-      number of the containing message type.
-
-5.2.5.  HostAddress and HostAddresses
-
-   HostAddress     ::= SEQUENCE  {
-           addr-type       [0] Int32,
-           address         [1] OCTET STRING
-   }
-
-   -- NOTE: HostAddresses is always used as an OPTIONAL field and
-   -- should not be empty.
-   HostAddresses   -- NOTE: subtly different from rfc1510,
-                   -- but has a value mapping and encodes the same
-           ::= SEQUENCE OF HostAddress
-
-   The host address encodings consist of two fields:
-
-   addr-type
-      This field specifies the type of address that follows.  Pre-
-      defined values for this field are specified in Section 7.5.3.
-
-   address
-      This field encodes a single address of type addr-type.
-
-
-
-Neuman, et al.              Standards Track                    [Page 56]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-5.2.6.  AuthorizationData
-
-      -- NOTE: AuthorizationData is always used as an OPTIONAL field and
-      -- should not be empty.
-      AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-              ad-type         [0] Int32,
-              ad-data         [1] OCTET STRING
-      }
-
-   ad-data
-      This field contains authorization data to be interpreted according
-      to the value of the corresponding ad-type field.
-
-   ad-type
-      This field specifies the format for the ad-data subfield.  All
-      negative values are reserved for local use.  Non-negative values
-      are reserved for registered use.
-
-   Each sequence of type and data is referred to as an authorization
-   element.  Elements MAY be application specific; however, there is a
-   common set of recursive elements that should be understood by all
-   implementations.  These elements contain other elements embedded
-   within them, and the interpretation of the encapsulating element
-   determines which of the embedded elements must be interpreted, and
-   which may be ignored.
-
-   These common authorization data elements are recursively defined,
-   meaning that the ad-data for these types will itself contain a
-   sequence of authorization data whose interpretation is affected by
-   the encapsulating element.  Depending on the meaning of the
-   encapsulating element, the encapsulated elements may be ignored,
-   might be interpreted as issued directly by the KDC, or might be
-   stored in a separate plaintext part of the ticket.  The types of the
-   encapsulating elements are specified as part of the Kerberos
-   specification because the behavior based on these values should be
-   understood across implementations, whereas other elements need only
-   be understood by the applications that they affect.
-
-   Authorization data elements are considered critical if present in a
-   ticket or authenticator.  If an unknown authorization data element
-   type is received by a server either in an AP-REQ or in a ticket
-   contained in an AP-REQ, then, unless it is encapsulated in a known
-   authorization data element amending the criticality of the elements
-   it contains, authentication MUST fail.  Authorization data is
-   intended to restrict the use of a ticket.  If the service cannot
-   determine whether the restriction applies to that service, then a
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 57]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   security weakness may result if the ticket can be used for that
-   service.  Authorization elements that are optional can be enclosed in
-   an AD-IF-RELEVANT element.
-
-   In the definitions that follow, the value of the ad-type for the
-   element will be specified as the least significant part of the
-   subsection number, and the value of the ad-data will be as shown in
-   the ASN.1 structure that follows the subsection heading.
-
-   Contents of ad-data                ad-type
-
-   DER encoding of AD-IF-RELEVANT        1
-
-   DER encoding of AD-KDCIssued          4
-
-   DER encoding of AD-AND-OR             5
-
-   DER encoding of AD-MANDATORY-FOR-KDC  8
-
-5.2.6.1.  IF-RELEVANT
-
-   AD-IF-RELEVANT          ::= AuthorizationData
-
-   AD elements encapsulated within the if-relevant element are intended
-   for interpretation only by application servers that understand the
-   particular ad-type of the embedded element.  Application servers that
-   do not understand the type of an element embedded within the
-   if-relevant element MAY ignore the uninterpretable element.  This
-   element promotes interoperability across implementations that may
-   have local extensions for authorization.  The ad-type for
-   AD-IF-RELEVANT is (1).
-
-5.2.6.2.  KDCIssued
-
-   AD-KDCIssued            ::= SEQUENCE {
-           ad-checksum     [0] Checksum,
-           i-realm         [1] Realm OPTIONAL,
-           i-sname         [2] PrincipalName OPTIONAL,
-           elements        [3] AuthorizationData
-   }
-
-   ad-checksum
-      A cryptographic checksum computed over the DER encoding of the
-      AuthorizationData in the "elements" field, keyed with the session
-      key.  Its checksumtype is the mandatory checksum type for the
-      encryption type of the session key, and its key usage value is 19.
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 58]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   i-realm, i-sname
-      The name of the issuing principal if different from that of the
-      KDC itself.  This field would be used when the KDC can verify the
-      authenticity of elements signed by the issuing principal, and it
-      allows this KDC to notify the application server of the validity
-      of those elements.
-
-   elements
-      A sequence of authorization data elements issued by the KDC.
-
-   The KDC-issued ad-data field is intended to provide a means for
-   Kerberos principal credentials to embed within themselves privilege
-   attributes and other mechanisms for positive authorization,
-   amplifying the privileges of the principal beyond what can be done
-   using credentials without such an a-data element.
-
-   The above means cannot be provided without this element because the
-   definition of the authorization-data field allows elements to be
-   added at will by the bearer of a TGT at the time when they request
-   service tickets, and elements may also be added to a delegated ticket
-   by inclusion in the authenticator.
-
-   For KDC-issued elements, this is prevented because the elements are
-   signed by the KDC by including a checksum encrypted using the
-   server's key (the same key used to encrypt the ticket or a key
-   derived from that key).  Elements encapsulated with in the KDC-issued
-   element MUST be ignored by the application server if this "signature"
-   is not present.  Further, elements encapsulated within this element
-   from a TGT MAY be interpreted by the KDC, and used as a basis
-   according to policy for including new signed elements within
-   derivative tickets, but they will not be copied to a derivative
-   ticket directly.  If they are copied directly to a derivative ticket
-   by a KDC that is not aware of this element, the signature will not be
-   correct for the application ticket elements, and the field will be
-   ignored by the application server.
-
-   This element and the elements it encapsulates MAY safely be ignored
-   by applications, application servers, and KDCs that do not implement
-   this element.
-
-   The ad-type for AD-KDC-ISSUED is (4).
-
-5.2.6.3.  AND-OR
-
-   AD-AND-OR               ::= SEQUENCE {
-           condition-count [0] Int32,
-           elements        [1] AuthorizationData
-   }
-
-
-
-Neuman, et al.              Standards Track                    [Page 59]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   When restrictive AD elements are encapsulated within the and-or
-   element, the and-or element is considered satisfied if and only if at
-   least the number of encapsulated elements specified in condition-
-   count are satisfied.  Therefore, this element MAY be used to
-   implement an "or" operation by setting the condition-count field to
-   1, and it MAY specify an "and" operation by setting the condition
-   count to the number of embedded elements.  Application servers that
-   do not implement this element MUST reject tickets that contain
-   authorization data elements of this type.
-
-   The ad-type for AD-AND-OR is (5).
-
-5.2.6.4.  MANDATORY-FOR-KDC
-
-   AD-MANDATORY-FOR-KDC    ::= AuthorizationData
-
-   AD elements encapsulated within the mandatory-for-kdc element are to
-   be interpreted by the KDC.  KDCs that do not understand the type of
-   an element embedded within the mandatory-for-kdc element MUST reject
-   the request.
-
-   The ad-type for AD-MANDATORY-FOR-KDC is (8).
-
-5.2.7.  PA-DATA
-
-   Historically, PA-DATA have been known as "pre-authentication data",
-   meaning that they were used to augment the initial authentication
-   with the KDC.  Since that time, they have also been used as a typed
-   hole with which to extend protocol exchanges with the KDC.
-
-   PA-DATA         ::= SEQUENCE {
-           -- NOTE: first tag is [1], not [0]
-           padata-type     [1] Int32,
-           padata-value    [2] OCTET STRING -- might be encoded AP-REQ
-   }
-
-   padata-type
-      Indicates the way that the padata-value element is to be
-      interpreted.  Negative values of padata-type are reserved for
-      unregistered use; non-negative values are used for a registered
-      interpretation of the element type.
-
-   padata-value
-      Usually contains the DER encoding of another type; the padata-type
-      field identifies which type is encoded here.
-
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 60]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-      padata-type  Name             Contents of padata-value
-
-      1            pa-tgs-req       DER encoding of AP-REQ
-
-      2            pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP
-
-      3            pa-pw-salt       salt (not ASN.1 encoded)
-
-      11           pa-etype-info    DER encoding of ETYPE-INFO
-
-      19           pa-etype-info2   DER encoding of ETYPE-INFO2
-
-      This field MAY also contain information needed by certain
-      extensions to the Kerberos protocol.  For example, it might be
-      used to verify the identity of a client initially before any
-      response is returned.
-
-      The padata field can also contain information needed to help the
-      KDC or the client select the key needed for generating or
-      decrypting the response.  This form of the padata is useful for
-      supporting the use of certain token cards with Kerberos.  The
-      details of such extensions are specified in separate documents.
-      See [Pat92] for additional uses of this field.
-
-5.2.7.1.  PA-TGS-REQ
-
-   In the case of requests for additional tickets (KRB_TGS_REQ),
-   padata-value will contain an encoded AP-REQ.  The checksum in the
-   authenticator (which MUST be collision-proof) is to be computed over
-   the KDC-REQ-BODY encoding.
-
-5.2.7.2.  Encrypted Timestamp Pre-authentication
-
-   There are pre-authentication types that may be used to pre-
-   authenticate a client by means of an encrypted timestamp.
-
-   PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
-
-   PA-ENC-TS-ENC           ::= SEQUENCE {
-           patimestamp     [0] KerberosTime -- client's time --,
-           pausec          [1] Microseconds OPTIONAL
-   }
-
-   Patimestamp contains the client's time, and pausec contains the
-   microseconds, which MAY be omitted if a client will not generate more
-   than one request per second.  The ciphertext (padata-value) consists
-   of the PA-ENC-TS-ENC encoding, encrypted using the client's secret
-   key and a key usage value of 1.
-
-
-
-Neuman, et al.              Standards Track                    [Page 61]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   This pre-authentication type was not present in RFC 1510, but many
-   implementations support it.
-
-5.2.7.3.  PA-PW-SALT
-
-   The padata-value for this pre-authentication type contains the salt
-   for the string-to-key to be used by the client to obtain the key for
-   decrypting the encrypted part of an AS-REP message.  Unfortunately,
-   for historical reasons, the character set to be used is unspecified
-   and probably locale-specific.
-
-   This pre-authentication type was not present in RFC 1510, but many
-   implementations support it.  It is necessary in any case where the
-   salt for the string-to-key algorithm is not the default.
-
-   In the trivial example, a zero-length salt string is very commonplace
-   for realms that have converted their principal databases from
-   Kerberos Version 4.
-
-   A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message
-   that requests additional pre-authentication.  Implementation note:
-   Some KDC implementations issue an erroneous PA-PW-SALT when issuing a
-   KRB-ERROR message that requests additional pre-authentication.
-   Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a
-   KRB-ERROR message that requests additional pre-authentication.  As
-   noted in section 3.1.3, a KDC MUST NOT send PA-PW-SALT when the
-   client's AS-REQ includes at least one "newer" etype.
-
-5.2.7.4.  PA-ETYPE-INFO
-
-   The ETYPE-INFO pre-authentication type is sent by the KDC in a
-   KRB-ERROR indicating a requirement for additional pre-authentication.
-   It is usually used to notify a client of which key to use for the
-   encryption of an encrypted timestamp for the purposes of sending a
-   PA-ENC-TIMESTAMP pre-authentication value.  It MAY also be sent in an
-   AS-REP to provide information to the client about which key salt to
-   use for the string-to-key to be used by the client to obtain the key
-   for decrypting the encrypted part the AS-REP.
-
-   ETYPE-INFO-ENTRY        ::= SEQUENCE {
-           etype           [0] Int32,
-           salt            [1] OCTET STRING OPTIONAL
-   }
-
-   ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
-
-   The salt, like that of PA-PW-SALT, is also completely unspecified
-   with respect to character set and is probably locale-specific.
-
-
-
-Neuman, et al.              Standards Track                    [Page 62]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   If ETYPE-INFO is sent in an AS-REP, there shall be exactly one
-   ETYPE-INFO-ENTRY, and its etype shall match that of the enc-part in
-   the AS-REP.
-
-   This pre-authentication type was not present in RFC 1510, but many
-   implementations that support encrypted timestamps for pre-
-   authentication need to support ETYPE-INFO as well.  As noted in
-   Section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's
-   AS-REQ includes at least one "newer" etype.
-
-5.2.7.5.  PA-ETYPE-INFO2
-
-   The ETYPE-INFO2 pre-authentication type is sent by the KDC in a
-   KRB-ERROR indicating a requirement for additional pre-authentication.
-   It is usually used to notify a client of which key to use for the
-   encryption of an encrypted timestamp for the purposes of sending a
-   PA-ENC-TIMESTAMP pre-authentication value.  It MAY also be sent in an
-   AS-REP to provide information to the client about which key salt to
-   use for the string-to-key to be used by the client to obtain the key
-   for decrypting the encrypted part the AS-REP.
-
-ETYPE-INFO2-ENTRY       ::= SEQUENCE {
-        etype           [0] Int32,
-        salt            [1] KerberosString OPTIONAL,
-        s2kparams       [2] OCTET STRING OPTIONAL
-}
-
-ETYPE-INFO2              ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
-
-   The type of the salt is KerberosString, but existing installations
-   might have locale-specific characters stored in salt strings, and
-   implementors MAY choose to handle them.
-
-   The interpretation of s2kparams is specified in the cryptosystem
-   description associated with the etype.  Each cryptosystem has a
-   default interpretation of s2kparams that will hold if that element is
-   omitted from the encoding of ETYPE-INFO2-ENTRY.
-
-   If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one
-   ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in
-   the AS-REP.
-
-   The preferred ordering of the "hint" pre-authentication data that
-   affect client key selection is: ETYPE-INFO2, followed by ETYPE-INFO,
-   followed by PW-SALT.  As noted in Section 3.1.3, a KDC MUST NOT send
-   ETYPE-INFO or PW-SALT when the client's AS-REQ includes at least one
-   "newer" etype.
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 63]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   The ETYPE-INFO2 pre-authentication type was not present in RFC 1510.
-
-5.2.8.  KerberosFlags
-
-   For several message types, a specific constrained bit string type,
-   KerberosFlags, is used.
-
-   KerberosFlags   ::= BIT STRING (SIZE (32..MAX))
-                       -- minimum number of bits shall be sent,
-                       -- but no fewer than 32
-
-   Compatibility note: The following paragraphs describe a change from
-   the RFC 1510 description of bit strings that would result in
-   incompatility in the case of an implementation that strictly
-   conformed to ASN.1 DER and RFC 1510.
-
-   ASN.1 bit strings have multiple uses.  The simplest use of a bit
-   string is to contain a vector of bits, with no particular meaning
-   attached to individual bits.  This vector of bits is not necessarily
-   a multiple of eight bits long.  The use in Kerberos of a bit string
-   as a compact boolean vector wherein each element has a distinct
-   meaning poses some problems.  The natural notation for a compact
-   boolean vector is the ASN.1 "NamedBit" notation, and the DER require
-   that encodings of a bit string using "NamedBit" notation exclude any
-   trailing zero bits.  This truncation is easy to neglect, especially
-   given C language implementations that naturally choose to store
-   boolean vectors as 32-bit integers.
-
-   For example, if the notation for KDCOptions were to include the
-   "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be
-   encoded had only the "forwardable" (bit number one) bit set, the DER
-   encoding MUST include only two bits: the first reserved bit
-   ("reserved", bit number zero, value zero) and the one-valued bit (bit
-   number one) for "forwardable".
-
-   Most existing implementations of Kerberos unconditionally send 32
-   bits on the wire when encoding bit strings used as boolean vectors.
-   This behavior violates the ASN.1 syntax used for flag values in RFC
-   1510, but it occurs on such a widely installed base that the protocol
-   description is being modified to accommodate it.
-
-   Consequently, this document removes the "NamedBit" notations for
-   individual bits, relegating them to comments.  The size constraint on
-   the KerberosFlags type requires that at least 32 bits be encoded at
-   all times, though a lenient implementation MAY choose to accept fewer
-   than 32 bits and to treat the missing bits as set to zero.
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 64]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Currently, no uses of KerberosFlags specify more than 32 bits' worth
-   of flags, although future revisions of this document may do so.  When
-   more than 32 bits are to be transmitted in a KerberosFlags value,
-   future revisions to this document will likely specify that the
-   smallest number of bits needed to encode the highest-numbered one-
-   valued bit should be sent.  This is somewhat similar to the DER
-   encoding of a bit string that is declared with the "NamedBit"
-   notation.
-
-5.2.9.  Cryptosystem-Related Types
-
-   Many Kerberos protocol messages contain an EncryptedData as a
-   container for arbitrary encrypted data, which is often the encrypted
-   encoding of another data type.  Fields within EncryptedData assist
-   the recipient in selecting a key with which to decrypt the enclosed
-   data.
-
-   EncryptedData   ::= SEQUENCE {
-           etype   [0] Int32 -- EncryptionType --,
-           kvno    [1] UInt32 OPTIONAL,
-           cipher  [2] OCTET STRING -- ciphertext
-   }
-
-   etype
-      This field identifies which encryption algorithm was used to
-      encipher the cipher.
-
-   kvno
-      This field contains the version number of the key under which data
-      is encrypted.  It is only present in messages encrypted under long
-      lasting keys, such as principals' secret keys.
-
-   cipher
-      This field contains the enciphered text, encoded as an OCTET
-      STRING.  (Note that the encryption mechanisms defined in [RFC3961]
-      MUST incorporate integrity protection as well, so no additional
-      checksum is required.)
-
-   The EncryptionKey type is the means by which cryptographic keys used
-   for encryption are transferred.
-
-   EncryptionKey   ::= SEQUENCE {
-           keytype         [0] Int32 -- actually encryption type --,
-           keyvalue        [1] OCTET STRING
-   }
-
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 65]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   keytype
-      This field specifies the encryption type of the encryption key
-      that follows in the keyvalue field.  Although its name is
-      "keytype", it actually specifies an encryption type.  Previously,
-      multiple cryptosystems that performed encryption differently but
-      were capable of using keys with the same characteristics were
-      permitted to share an assigned number to designate the type of
-      key; this usage is now deprecated.
-
-   keyvalue
-      This field contains the key itself, encoded as an octet string.
-
-   Messages containing cleartext data to be authenticated will usually
-   do so by using a member of type Checksum.  Most instances of Checksum
-   use a keyed hash, though exceptions will be noted.
-
-   Checksum        ::= SEQUENCE {
-           cksumtype       [0] Int32,
-           checksum        [1] OCTET STRING
-   }
-
-   cksumtype
-      This field indicates the algorithm used to generate the
-      accompanying checksum.
-
-   checksum
-      This field contains the checksum itself, encoded as an octet
-      string.
-
-   See Section 4 for a brief description of the use of encryption and
-   checksums in Kerberos.
-
-5.3.  Tickets
-
-   This section describes the format and encryption parameters for
-   tickets and authenticators.  When a ticket or authenticator is
-   included in a protocol message, it is treated as an opaque object.  A
-   ticket is a record that helps a client authenticate to a service.  A
-   Ticket contains the following information:
-
-   Ticket          ::= [APPLICATION 1] SEQUENCE {
-           tkt-vno         [0] INTEGER (5),
-           realm           [1] Realm,
-           sname           [2] PrincipalName,
-           enc-part        [3] EncryptedData -- EncTicketPart
-   }
-
-   -- Encrypted part of ticket
-
-
-
-Neuman, et al.              Standards Track                    [Page 66]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
-           flags                   [0] TicketFlags,
-           key                     [1] EncryptionKey,
-           crealm                  [2] Realm,
-           cname                   [3] PrincipalName,
-           transited               [4] TransitedEncoding,
-           authtime                [5] KerberosTime,
-           starttime               [6] KerberosTime OPTIONAL,
-           endtime                 [7] KerberosTime,
-           renew-till              [8] KerberosTime OPTIONAL,
-           caddr                   [9] HostAddresses OPTIONAL,
-           authorization-data      [10] AuthorizationData OPTIONAL
-   }
-
-   -- encoded Transited field
-   TransitedEncoding       ::= SEQUENCE {
-           tr-type         [0] Int32 -- must be registered --,
-           contents        [1] OCTET STRING
-   }
-
-   TicketFlags     ::= KerberosFlags
-           -- reserved(0),
-           -- forwardable(1),
-           -- forwarded(2),
-           -- proxiable(3),
-           -- proxy(4),
-           -- may-postdate(5),
-           -- postdated(6),
-           -- invalid(7),
-           -- renewable(8),
-           -- initial(9),
-           -- pre-authent(10),
-           -- hw-authent(11),
-   -- the following are new since 1510
-           -- transited-policy-checked(12),
-           -- ok-as-delegate(13)
-
-   tkt-vno
-      This field specifies the version number for the ticket format.
-      This document describes version number 5.
-
-   realm
-      This field specifies the realm that issued a ticket.  It also
-      serves to identify the realm part of the server's principal
-      identifier.  Since a Kerberos server can only issue tickets for
-      servers within its realm, the two will always be identical.
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 67]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   sname
-      This field specifies all components of the name part of the
-      server's identity, including those parts that identify a specific
-      instance of a service.
-
-   enc-part
-      This field holds the encrypted encoding of the EncTicketPart
-      sequence.  It is encrypted in the key shared by Kerberos and the
-      end server (the server's secret key), using a key usage value of
-      2.
-
-   flags
-      This field indicates which of various options were used or
-      requested when the ticket was issued.  The meanings of the flags
-      are as follows:
-
-   Bit(s)  Name             Description
-
-   0       reserved         Reserved for future expansion of this field.
-
-   1       forwardable      The FORWARDABLE flag is normally only
-                            interpreted by the TGS, and can be ignored
-                            by end servers.  When set, this flag tells
-                            the ticket-granting server that it is OK to
-                            issue a new TGT with a different network
-                            address based on the presented ticket.
-
-   2       forwarded        When set, this flag indicates that the
-                            ticket has either been forwarded or was
-                            issued based on authentication involving a
-                            forwarded TGT.
-
-   3       proxiable        The PROXIABLE flag is normally only
-                            interpreted by the TGS, and can be ignored
-                            by end servers.  The PROXIABLE flag has an
-                            interpretation identical to that of the
-                            FORWARDABLE flag, except that the PROXIABLE
-                            flag tells the ticket-granting server that
-                            only non-TGTs may be issued with different
-                            network addresses.
-
-   4       proxy            When set, this flag indicates that a ticket
-                            is a proxy.
-
-   5       may-postdate     The MAY-POSTDATE flag is normally only
-                            interpreted by the TGS, and can be ignored
-                            by end servers.  This flag tells the
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 68]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-                            ticket-granting server that a post-dated
-                            ticket MAY be issued based on this TGT.
-
-   6       postdated        This flag indicates that this ticket has
-                            been postdated.  The end-service can check
-                            the authtime field to see when the original
-                            authentication occurred.
-
-   7       invalid          This flag indicates that a ticket is
-                            invalid, and it must be validated by the KDC
-                            before use.  Application servers must reject
-                            tickets which have this flag set.
-
-   8       renewable        The RENEWABLE flag is normally only
-                            interpreted by the TGS, and can usually be
-                            ignored by end servers (some particularly
-                            careful servers MAY disallow renewable
-                            tickets).  A renewable ticket can be used to
-                            obtain a replacement ticket that expires at
-                            a later date.
-
-   9       initial          This flag indicates that this ticket was
-                            issued using the AS protocol, and not issued
-                            based on a TGT.
-
-   10      pre-authent      This flag indicates that during initial
-                            authentication, the client was authenticated
-                            by the KDC before a ticket was issued.  The
-                            strength of the pre-authentication method is
-                            not indicated, but is acceptable to the KDC.
-
-   11      hw-authent       This flag indicates that the protocol
-                            employed for initial authentication required
-                            the use of hardware expected to be possessed
-                            solely by the named client.  The hardware
-                            authentication method is selected by the KDC
-                            and the strength of the method is not
-                            indicated.
-
-   12      transited-       This flag indicates that the KDC for
-           policy-checked   the realm has checked the transited field
-                            against a realm-defined policy for trusted
-                            certifiers.  If this flag is reset (0), then
-                            the application server must check the
-                            transited field itself, and if unable to do
-                            so, it must reject the authentication.  If
-                            the flag is set (1), then the application
-                            server MAY skip its own validation of the
-
-
-
-Neuman, et al.              Standards Track                    [Page 69]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-                            transited field, relying on the validation
-                            performed by the KDC.  At its option the
-                            application server MAY still apply its own
-                            validation based on a separate policy for
-                            acceptance.
-
-                            This flag is new since RFC 1510.
-
-   13      ok-as-delegate   This flag indicates that the server (not the
-                            client) specified in the ticket has been
-                            determined by policy of the realm to be a
-                            suitable recipient of delegation.  A client
-                            can use the presence of this flag to help it
-                            decide whether to delegate credentials
-                            (either grant a proxy or a forwarded TGT) to
-                            this server.  The client is free to ignore
-                            the value of this flag.  When setting this
-                            flag, an administrator should consider the
-                            security and placement of the server on
-                            which the service will run, as well as
-                            whether the service requires the use of
-                            delegated credentials.
-
-                            This flag is new since RFC 1510.
-
-   14-31   reserved         Reserved for future use.
-
-   key
-      This field exists in the ticket and the KDC response and is used
-      to pass the session key from Kerberos to the application server
-      and the client.
-
-   crealm
-      This field contains the name of the realm in which the client is
-      registered and in which initial authentication took place.
-
-   cname
-      This field contains the name part of the client's principal
-      identifier.
-
-   transited
-      This field lists the names of the Kerberos realms that took part
-      in authenticating the user to whom this ticket was issued.  It
-      does not specify the order in which the realms were transited.
-      See Section 3.3.3.2 for details on how this field encodes the
-      traversed realms.  When the names of CAs are to be embedded in the
-      transited field (as specified for some extensions to the
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 70]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-      protocol), the X.500 names of the CAs SHOULD be mapped into items
-      in the transited field using the mapping defined by RFC 2253.
-
-   authtime
-      This field indicates the time of initial authentication for the
-      named principal.  It is the time of issue for the original ticket
-      on which this ticket is based.  It is included in the ticket to
-      provide additional information to the end service, and to provide
-      the necessary information for implementation of a "hot list"
-      service at the KDC.  An end service that is particularly paranoid
-      could refuse to accept tickets for which the initial
-      authentication occurred "too far" in the past.  This field is also
-      returned as part of the response from the KDC.  When it is
-      returned as part of the response to initial authentication
-      (KRB_AS_REP), this is the current time on the Kerberos server.  It
-      is NOT recommended that this time value be used to adjust the
-      workstation's clock, as the workstation cannot reliably determine
-      that such a KRB_AS_REP actually came from the proper KDC in a
-      timely manner.
-
-   starttime
-      This field in the ticket specifies the time after which the ticket
-      is valid.  Together with endtime, this field specifies the life of
-      the ticket.  If the starttime field is absent from the ticket,
-      then the authtime field SHOULD be used in its place to determine
-      the life of the ticket.
-
-   endtime
-      This field contains the time after which the ticket will not be
-      honored (its expiration time).  Note that individual services MAY
-      place their own limits on the life of a ticket and MAY reject
-      tickets which have not yet expired.  As such, this is really an
-      upper bound on the expiration time for the ticket.
-
-   renew-till
-      This field is only present in tickets that have the RENEWABLE flag
-      set in the flags field.  It indicates the maximum endtime that may
-      be included in a renewal.  It can be thought of as the absolute
-      expiration time for the ticket, including all renewals.
-
-   caddr
-      This field in a ticket contains zero (if omitted) or more (if
-      present) host addresses.  These are the addresses from which the
-      ticket can be used.  If there are no addresses, the ticket can be
-      used from any location.  The decision by the KDC to issue or by
-      the end server to accept addressless tickets is a policy decision
-      and is left to the Kerberos and end-service administrators; they
-      MAY refuse to issue or accept such tickets.  Because of the wide
-
-
-
-Neuman, et al.              Standards Track                    [Page 71]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-      deployment of network address translation, it is recommended that
-      policy allow the issue and acceptance of such tickets.
-
-      Network addresses are included in the ticket to make it harder for
-      an attacker to use stolen credentials.  Because the session key is
-      not sent over the network in cleartext, credentials can't be
-      stolen simply by listening to the network; an attacker has to gain
-      access to the session key (perhaps through operating system
-      security breaches or a careless user's unattended session) to make
-      use of stolen tickets.
-
-      Note that the network address from which a connection is received
-      cannot be reliably determined.  Even if it could be, an attacker
-      who has compromised the client's workstation could use the
-      credentials from there.  Including the network addresses only
-      makes it more difficult, not impossible, for an attacker to walk
-      off with stolen credentials and then to use them from a "safe"
-      location.
-
-   authorization-data
-      The authorization-data field is used to pass authorization data
-      from the principal on whose behalf a ticket was issued to the
-      application service.  If no authorization data is included, this
-      field will be left out.  Experience has shown that the name of
-      this field is confusing, and that a better name would be
-      "restrictions".  Unfortunately, it is not possible to change the
-      name at this time.
-
-      This field contains restrictions on any authority obtained on the
-      basis of authentication using the ticket.  It is possible for any
-      principal in possession of credentials to add entries to the
-      authorization data field since these entries further restrict what
-      can be done with the ticket.  Such additions can be made by
-      specifying the additional entries when a new ticket is obtained
-      during the TGS exchange, or they MAY be added during chained
-      delegation using the authorization data field of the
-      authenticator.
-
-      Because entries may be added to this field by the holder of
-      credentials, except when an entry is separately authenticated by
-      encapsulation in the KDC-issued element, it is not allowable for
-      the presence of an entry in the authorization data field of a
-      ticket to amplify the privileges one would obtain from using a
-      ticket.
-
-      The data in this field may be specific to the end service; the
-      field will contain the names of service specific objects, and the
-      rights to those objects.  The format for this field is described
-
-
-
-Neuman, et al.              Standards Track                    [Page 72]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-      in Section 5.2.6.  Although Kerberos is not concerned with the
-      format of the contents of the subfields, it does carry type
-      information (ad-type).
-
-      By using the authorization_data field, a principal is able to
-      issue a proxy that is valid for a specific purpose.  For example,
-      a client wishing to print a file can obtain a file server proxy to
-      be passed to the print server.  By specifying the name of the file
-      in the authorization_data field, the file server knows that the
-      print server can only use the client's rights when accessing the
-      particular file to be printed.
-
-      A separate service providing authorization or certifying group
-      membership may be built using the authorization-data field.  In
-      this case, the entity granting authorization (not the authorized
-      entity) may obtain a ticket in its own name (e.g., the ticket is
-      issued in the name of a privilege server), and this entity adds
-      restrictions on its own authority and delegates the restricted
-      authority through a proxy to the client.  The client would then
-      present this authorization credential to the application server
-      separately from the authentication exchange.  Alternatively, such
-      authorization credentials MAY be embedded in the ticket
-      authenticating the authorized entity, when the authorization is
-      separately authenticated using the KDC-issued authorization data
-      element (see 5.2.6.2).
-
-      Similarly, if one specifies the authorization-data field of a
-      proxy and leaves the host addresses blank, the resulting ticket
-      and session key can be treated as a capability.  See [Neu93] for
-      some suggested uses of this field.
-
-      The authorization-data field is optional and does not have to be
-      included in a ticket.
-
-5.4.  Specifications for the AS and TGS Exchanges
-
-   This section specifies the format of the messages used in the
-   exchange between the client and the Kerberos server.  The format of
-   possible error messages appears in Section 5.9.1.
-
-5.4.1.  KRB_KDC_REQ Definition
-
-   The KRB_KDC_REQ message has no application tag number of its own.
-   Instead, it is incorporated into either KRB_AS_REQ or KRB_TGS_REQ,
-   each of which has an application tag, depending on whether the
-   request is for an initial ticket or an additional ticket.  In either
-   case, the message is sent from the client to the KDC to request
-   credentials for a service.
-
-
-
-Neuman, et al.              Standards Track                    [Page 73]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   The message fields are as follows:
-
-AS-REQ          ::= [APPLICATION 10] KDC-REQ
-
-TGS-REQ         ::= [APPLICATION 12] KDC-REQ
-
-KDC-REQ         ::= SEQUENCE {
-        -- NOTE: first tag is [1], not [0]
-        pvno            [1] INTEGER (5) ,
-        msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
-        padata          [3] SEQUENCE OF PA-DATA OPTIONAL
-                            -- NOTE: not empty --,
-        req-body        [4] KDC-REQ-BODY
-}
-
-KDC-REQ-BODY    ::= SEQUENCE {
-        kdc-options             [0] KDCOptions,
-        cname                   [1] PrincipalName OPTIONAL
-                                    -- Used only in AS-REQ --,
-        realm                   [2] Realm
-                                    -- Server's realm
-                                    -- Also client's in AS-REQ --,
-        sname                   [3] PrincipalName OPTIONAL,
-        from                    [4] KerberosTime OPTIONAL,
-        till                    [5] KerberosTime,
-        rtime                   [6] KerberosTime OPTIONAL,
-        nonce                   [7] UInt32,
-        etype                   [8] SEQUENCE OF Int32 -- EncryptionType
-                                    -- in preference order --,
-        addresses               [9] HostAddresses OPTIONAL,
-        enc-authorization-data  [10] EncryptedData OPTIONAL
-                                    -- AuthorizationData --,
-        additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
-                                       -- NOTE: not empty
-}
-
-KDCOptions      ::= KerberosFlags
-        -- reserved(0),
-        -- forwardable(1),
-        -- forwarded(2),
-        -- proxiable(3),
-        -- proxy(4),
-        -- allow-postdate(5),
-        -- postdated(6),
-        -- unused7(7),
-        -- renewable(8),
-        -- unused9(9),
-        -- unused10(10),
-
-
-
-Neuman, et al.              Standards Track                    [Page 74]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-        -- opt-hardware-auth(11),
-        -- unused12(12),
-        -- unused13(13),
--- 15 is reserved for canonicalize
-        -- unused15(15),
--- 26 was unused in 1510
-        -- disable-transited-check(26),
---
-        -- renewable-ok(27),
-        -- enc-tkt-in-skey(28),
-        -- renew(30),
-        -- validate(31)
-
-   The fields in this message are as follows:
-
-   pvno
-      This field is included in each message, and specifies the protocol
-      version number.  This document specifies protocol version 5.
-
-   msg-type
-      This field indicates the type of a protocol message.  It will
-      almost always be the same as the application identifier associated
-      with a message.  It is included to make the identifier more
-      readily accessible to the application.  For the KDC-REQ message,
-      this type will be KRB_AS_REQ or KRB_TGS_REQ.
-
-   padata
-      Contains pre-authentication data.  Requests for additional tickets
-      (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ.
-
-      The padata (pre-authentication data) field contains a sequence of
-      authentication information that may be needed before credentials
-      can be issued or decrypted.
-
-   req-body
-      This field is a placeholder delimiting the extent of the remaining
-      fields.  If a checksum is to be calculated over the request, it is
-      calculated over an encoding of the KDC-REQ-BODY sequence which is
-      enclosed within the req-body field.
-
-   kdc-options
-      This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to
-      the KDC and indicates the flags that the client wants set on the
-      tickets as well as other information that is to modify the
-      behavior of the KDC.  Where appropriate, the name of an option may
-      be the same as the flag that is set by that option.  Although in
-      most cases, the bit in the options field will be the same as that
-      in the flags field, this is not guaranteed, so it is not
-
-
-
-Neuman, et al.              Standards Track                    [Page 75]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-      acceptable simply to copy the options field to the flags field.
-      There are various checks that must be made before an option is
-      honored anyway.
-
-      The kdc_options field is a bit-field, where the selected options
-      are indicated by the bit being set (1), and the unselected options
-      and reserved fields being reset (0).  The encoding of the bits is
-      specified in Section 5.2.  The options are described in more
-      detail above in Section 2.  The meanings of the options are as
-      follows:
-
-   Bits    Name                     Description
-
-   0       RESERVED                 Reserved for future expansion of
-                                    this field.
-
-   1       FORWARDABLE              The FORWARDABLE option indicates
-                                    that the ticket to be issued is to
-                                    have its forwardable flag set.  It
-                                    may only be set on the initial
-                                    request, or in a subsequent request
-                                    if the TGT on which it is based is
-                                    also forwardable.
-
-   2       FORWARDED                The FORWARDED option is only
-                                    specified in a request to the
-                                    ticket-granting server and will only
-                                    be honored if the TGT in the request
-                                    has its FORWARDABLE bit set.  This
-                                    option indicates that this is a
-                                    request for forwarding.  The
-                                    address(es) of the host from which
-                                    the resulting ticket is to be valid
-                                    are included in the addresses field
-                                    of the request.
-
-   3       PROXIABLE                The PROXIABLE option indicates that
-                                    the ticket to be issued is to have
-                                    its proxiable flag set.  It may only
-                                    be set on the initial request, or a
-                                    subsequent request if the TGT on
-                                    which it is based is also proxiable.
-
-   4       PROXY                    The PROXY option indicates that this
-                                    is a request for a proxy.  This
-                                    option will only be honored if the
-                                    TGT in the request has its PROXIABLE
-                                    bit set.  The address(es) of the
-
-
-
-Neuman, et al.              Standards Track                    [Page 76]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-                                    host from which the resulting ticket
-                                    is to be valid are included in the
-                                    addresses field of the request.
-
-   5       ALLOW-POSTDATE           The ALLOW-POSTDATE option indicates
-                                    that the ticket to be issued is to
-                                    have its MAY-POSTDATE flag set.  It
-                                    may only be set on the initial
-                                    request, or in a subsequent request
-                                    if the TGT on which it is based also
-                                    has its MAY-POSTDATE flag set.
-
-   6       POSTDATED                The POSTDATED option indicates that
-                                    this is a request for a postdated
-                                    ticket.  This option will only be
-                                    honored if the TGT on which it is
-                                    based has its MAY-POSTDATE flag set.
-                                    The resulting ticket will also have
-                                    its INVALID flag set, and that flag
-                                    may be reset by a subsequent request
-                                    to the KDC after the starttime in
-                                    the ticket has been reached.
-
-   7       RESERVED                 This option is presently unused.
-
-   8       RENEWABLE                The RENEWABLE option indicates that
-                                    the ticket to be issued is to have
-                                    its RENEWABLE flag set.  It may only
-                                    be set on the initial request, or
-                                    when the TGT on which the request is
-                                    based is also renewable.  If this
-                                    option is requested, then the rtime
-                                    field in the request contains the
-                                    desired absolute expiration time for
-                                    the ticket.
-
-   9       RESERVED                 Reserved for PK-Cross.
-
-   10      RESERVED                 Reserved for future use.
-
-   11      RESERVED                 Reserved for opt-hardware-auth.
-
-   12-25   RESERVED                 Reserved for future use.
-
-   26      DISABLE-TRANSITED-CHECK  By default the KDC will check the
-                                    transited field of a TGT against the
-                                    policy of the local realm before it
-                                    will issue derivative tickets based
-
-
-
-Neuman, et al.              Standards Track                    [Page 77]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-                                    on the TGT.  If this flag is set in
-                                    the request, checking of the
-                                    transited field is disabled.
-                                    Tickets issued without the
-                                    performance of this check will be
-                                    noted by the reset (0) value of the
-                                    TRANSITED-POLICY-CHECKED flag,
-                                    indicating to the application server
-                                    that the transited field must be
-                                    checked locally.  KDCs are
-                                    encouraged but not required to honor
-                                    the DISABLE-TRANSITED-CHECK option.
-
-                                    This flag is new since RFC 1510.
-
-   27      RENEWABLE-OK             The RENEWABLE-OK option indicates
-                                    that a renewable ticket will be
-                                    acceptable if a ticket with the
-                                    requested life cannot otherwise be
-                                    provided, in which case a renewable
-                                    ticket may be issued with a renew-
-                                    till equal to the requested endtime.
-                                    The value of the renew-till field
-                                    may still be limited by local
-                                    limits, or limits selected by the
-                                    individual principal or server.
-
-   28      ENC-TKT-IN-SKEY          This option is used only by the
-                                    ticket-granting service.  The ENC-
-                                    TKT-IN-SKEY option indicates that
-                                    the ticket for the end server is to
-                                    be encrypted in the session key from
-                                    the additional TGT provided.
-
-   29      RESERVED                 Reserved for future use.
-
-   30      RENEW                    This option is used only by the
-                                    ticket-granting service.  The RENEW
-                                    option indicates that the present
-                                    request is for a renewal.  The
-                                    ticket provided is encrypted in the
-                                    secret key for the server on which
-                                    it is valid.  This option will only
-                                    be honored if the ticket to be
-                                    renewed has its RENEWABLE flag set
-                                    and if the time in its renew-till
-                                    field has not passed.  The ticket to
-                                    be renewed is passed in the padata
-
-
-
-Neuman, et al.              Standards Track                    [Page 78]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-                                    field as part of the authentication
-                                    header.
-
-   31      VALIDATE                 This option is used only by the
-                                    ticket-granting service.  The
-                                    VALIDATE option indicates that the
-                                    request is to validate a postdated
-                                    ticket.  It will only be honored if
-                                    the ticket presented is postdated,
-                                    presently has its INVALID flag set,
-                                    and would otherwise be usable at
-                                    this time.  A ticket cannot be
-                                    validated before its starttime.  The
-                                    ticket presented for validation is
-                                    encrypted in the key of the server
-                                    for which it is valid and is passed
-                                    in the padata field as part of the
-                                    authentication header.
-
-   cname and sname
-      These fields are the same as those described for the ticket in
-      section 5.3.  The sname may only be absent when the ENC-TKT-IN-
-      SKEY option is specified.  If the sname is absent, the name of the
-      server is taken from the name of the client in the ticket passed
-      as additional-tickets.
-
-   enc-authorization-data
-      The enc-authorization-data, if present (and it can only be present
-      in the TGS_REQ form), is an encoding of the desired
-      authorization-data encrypted under the sub-session key if present
-      in the Authenticator, or alternatively from the session key in the
-      TGT (both the Authenticator and TGT come from the padata field in
-      the KRB_TGS_REQ).  The key usage value used when encrypting is 5
-      if a sub-session key is used, or 4 if the session key is used.
-
-   realm
-      This field specifies the realm part of the server's principal
-      identifier.  In the AS exchange, this is also the realm part of
-      the client's principal identifier.
-
-   from
-      This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
-      requests when the requested ticket is to be postdated.  It
-      specifies the desired starttime for the requested ticket.  If this
-      field is omitted, then the KDC SHOULD use the current time
-      instead.
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 79]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   till
-      This field contains the expiration date requested by the client in
-      a ticket request.  It is not optional, but if the requested
-      endtime is "19700101000000Z", the requested ticket is to have the
-      maximum endtime permitted according to KDC policy.  Implementation
-      note: This special timestamp corresponds to a UNIX time_t value of
-      zero on most systems.
-
-   rtime
-      This field is the requested renew-till time sent from a client to
-      the KDC in a ticket request.  It is optional.
-
-   nonce
-      This field is part of the KDC request and response.  It is
-      intended to hold a random number generated by the client.  If the
-      same number is included in the encrypted response from the KDC, it
-      provides evidence that the response is fresh and has not been
-      replayed by an attacker.  Nonces MUST NEVER be reused.
-
-   etype
-      This field specifies the desired encryption algorithm to be used
-      in the response.
-
-   addresses
-      This field is included in the initial request for tickets, and it
-      is optionally included in requests for additional tickets from the
-      ticket-granting server.  It specifies the addresses from which the
-      requested ticket is to be valid.  Normally it includes the
-      addresses for the client's host.  If a proxy is requested, this
-      field will contain other addresses.  The contents of this field
-      are usually copied by the KDC into the caddr field of the
-      resulting ticket.
-
-   additional-tickets
-      Additional tickets MAY be optionally included in a request to the
-      ticket-granting server.  If the ENC-TKT-IN-SKEY option has been
-      specified, then the session key from the additional ticket will be
-      used in place of the server's key to encrypt the new ticket.  When
-      the ENC-TKT-IN-SKEY option is used for user-to-user
-      authentication, this additional ticket MAY be a TGT issued by the
-      local realm or an inter-realm TGT issued for the current KDC's
-      realm by a remote KDC.  If more than one option that requires
-      additional tickets has been specified, then the additional tickets
-      are used in the order specified by the ordering of the options
-      bits (see kdc-options, above).
-
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 80]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   The application tag number will be either ten (10) or twelve (12)
-   depending on whether the request is for an initial ticket (AS-REQ) or
-   for an additional ticket (TGS-REQ).
-
-   The optional fields (addresses, authorization-data, and additional-
-   tickets) are only included if necessary to perform the operation
-   specified in the kdc-options field.
-
-   Note that in KRB_TGS_REQ, the protocol version number appears twice
-   and two different message types appear: the KRB_TGS_REQ message
-   contains these fields as does the authentication header (KRB_AP_REQ)
-   that is passed in the padata field.
-
-5.4.2.  KRB_KDC_REP Definition
-
-   The KRB_KDC_REP message format is used for the reply from the KDC for
-   either an initial (AS) request or a subsequent (TGS) request.  There
-   is no message type for KRB_KDC_REP.  Instead, the type will be either
-   KRB_AS_REP or KRB_TGS_REP.  The key used to encrypt the ciphertext
-   part of the reply depends on the message type.  For KRB_AS_REP, the
-   ciphertext is encrypted in the client's secret key, and the client's
-   key version number is included in the key version number for the
-   encrypted data.  For KRB_TGS_REP, the ciphertext is encrypted in the
-   sub-session key from the Authenticator; if it is absent, the
-   ciphertext is encrypted in the session key from the TGT used in the
-   request.  In that case, no version number will be present in the
-   EncryptedData sequence.
-
-   The KRB_KDC_REP message contains the following fields:
-
-   AS-REP          ::= [APPLICATION 11] KDC-REP
-
-   TGS-REP         ::= [APPLICATION 13] KDC-REP
-
-   KDC-REP         ::= SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
-           padata          [2] SEQUENCE OF PA-DATA OPTIONAL
-                                   -- NOTE: not empty --,
-           crealm          [3] Realm,
-           cname           [4] PrincipalName,
-           ticket          [5] Ticket,
-           enc-part        [6] EncryptedData
-                                   -- EncASRepPart or EncTGSRepPart,
-                                   -- as appropriate
-   }
-
-   EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
-
-
-
-Neuman, et al.              Standards Track                    [Page 81]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
-
-   EncKDCRepPart   ::= SEQUENCE {
-           key             [0] EncryptionKey,
-           last-req        [1] LastReq,
-           nonce           [2] UInt32,
-           key-expiration  [3] KerberosTime OPTIONAL,
-           flags           [4] TicketFlags,
-           authtime        [5] KerberosTime,
-           starttime       [6] KerberosTime OPTIONAL,
-           endtime         [7] KerberosTime,
-           renew-till      [8] KerberosTime OPTIONAL,
-           srealm          [9] Realm,
-           sname           [10] PrincipalName,
-           caddr           [11] HostAddresses OPTIONAL
-   }
-
-   LastReq         ::=     SEQUENCE OF SEQUENCE {
-           lr-type         [0] Int32,
-           lr-value        [1] KerberosTime
-   }
-
-   pvno and msg-type
-      These fields are described above in Section 5.4.1.  msg-type is
-      either KRB_AS_REP or KRB_TGS_REP.
-
-   padata
-      This field is described in detail in Section 5.4.1.  One possible
-      use for it is to encode an alternate "salt" string to be used with
-      a string-to-key algorithm.  This ability is useful for easing
-      transitions if a realm name needs to change (e.g., when a company
-      is acquired); in such a case all existing password-derived entries
-      in the KDC database would be flagged as needing a special salt
-      string until the next password change.
-
-   crealm, cname, srealm, and sname
-      These fields are the same as those described for the ticket in
-      section 5.3.
-
-   ticket
-      The newly-issued ticket, from Section 5.3.
-
-   enc-part
-      This field is a place holder for the ciphertext and related
-      information that forms the encrypted part of a message.  The
-      description of the encrypted part of the message follows each
-      appearance of this field.
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 82]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-      The key usage value for encrypting this field is 3 in an AS-REP
-      message, using the client's long-term key or another key selected
-      via pre-authentication mechanisms.  In a TGS-REP message, the key
-      usage value is 8 if the TGS session key is used, or 9 if a TGS
-      authenticator subkey is used.
-
-      Compatibility note: Some implementations unconditionally send an
-      encrypted EncTGSRepPart (application tag number 26) in this field
-      regardless of whether the reply is a AS-REP or a TGS-REP.  In the
-      interest of compatibility, implementors MAY relax the check on the
-      tag number of the decrypted ENC-PART.
-
-   key
-      This field is the same as described for the ticket in Section 5.3.
-
-   last-req
-      This field is returned by the KDC and specifies the time(s) of the
-      last request by a principal.  Depending on what information is
-      available, this might be the last time that a request for a TGT
-      was made, or the last time that a request based on a TGT was
-      successful.  It also might cover all servers for a realm, or just
-      the particular server.  Some implementations MAY display this
-      information to the user to aid in discovering unauthorized use of
-      one's identity.  It is similar in spirit to the last login time
-      displayed when logging in to timesharing systems.
-
-   lr-type
-      This field indicates how the following lr-value field is to be
-      interpreted.  Negative values indicate that the information
-      pertains only to the responding server.  Non-negative values
-      pertain to all servers for the realm.
-
-      If the lr-type field is zero (0), then no information is conveyed
-      by the lr-value subfield.  If the absolute value of the lr-type
-      field is one (1), then the lr-value subfield is the time of last
-      initial request for a TGT.  If it is two (2), then the lr-value
-      subfield is the time of last initial request.  If it is three (3),
-      then the lr-value subfield is the time of issue for the newest TGT
-      used.  If it is four (4), then the lr-value subfield is the time
-      of the last renewal.  If it is five (5), then the lr-value
-      subfield is the time of last request (of any type).  If it is (6),
-      then the lr-value subfield is the time when the password will
-      expire.  If it is (7), then the lr-value subfield is the time when
-      the account will expire.
-
-
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 83]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   lr-value
-      This field contains the time of the last request.  The time MUST
-      be interpreted according to the contents of the accompanying lr-
-      type subfield.
-
-   nonce
-      This field is described above in Section 5.4.1.
-
-   key-expiration
-      The key-expiration field is part of the response from the KDC and
-      specifies the time that the client's secret key is due to expire.
-      The expiration might be the result of password aging or an account
-      expiration.  If present, it SHOULD be set to the earlier of the
-      user's key expiration and account expiration.  The use of this
-      field is deprecated, and the last-req field SHOULD be used to
-      convey this information instead.  This field will usually be left
-      out of the TGS reply since the response to the TGS request is
-      encrypted in a session key and no client information has to be
-      retrieved from the KDC database.  It is up to the application
-      client (usually the login program) to take appropriate action
-      (such as notifying the user) if the expiration time is imminent.
-
-   flags, authtime, starttime, endtime, renew-till and caddr
-      These fields are duplicates of those found in the encrypted
-      portion of the attached ticket (see Section 5.3), provided so the
-      client MAY verify that they match the intended request and in
-      order to assist in proper ticket caching.  If the message is of
-      type KRB_TGS_REP, the caddr field will only be filled in if the
-      request was for a proxy or forwarded ticket, or if the user is
-      substituting a subset of the addresses from the TGT.  If the
-      client-requested addresses are not present or not used, then the
-      addresses contained in the ticket will be the same as those
-      included in the TGT.
-
-5.5.  Client/Server (CS) Message Specifications
-
-   This section specifies the format of the messages used for the
-   authentication of the client to the application server.
-
-5.5.1.  KRB_AP_REQ Definition
-
-   The KRB_AP_REQ message contains the Kerberos protocol version number,
-   the message type KRB_AP_REQ, an options field to indicate any options
-   in use, and the ticket and authenticator themselves.  The KRB_AP_REQ
-   message is often referred to as the "authentication header".
-
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 84]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   AP-REQ          ::= [APPLICATION 14] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (14),
-           ap-options      [2] APOptions,
-           ticket          [3] Ticket,
-           authenticator   [4] EncryptedData -- Authenticator
-   }
-
-   APOptions       ::= KerberosFlags
-           -- reserved(0),
-           -- use-session-key(1),
-           -- mutual-required(2)
-
-   pvno and msg-type
-      These fields are described above in Section 5.4.1. msg-type is
-      KRB_AP_REQ.
-
-   ap-options
-      This field appears in the application request (KRB_AP_REQ) and
-      affects the way the request is processed.  It is a bit-field,
-      where the selected options are indicated by the bit being set (1),
-      and the unselected options and reserved fields by being reset (0).
-      The encoding of the bits is specified in Section 5.2.  The
-      meanings of the options are as follows:
-
-   Bit(s)  Name             Description
-
-   0       reserved         Reserved for future expansion of this field.
-
-   1       use-session-key  The USE-SESSION-KEY option indicates that
-                            the ticket the client is presenting to a
-                            server is encrypted in the session key from
-                            the server's TGT.  When this option is not
-                            specified, the ticket is encrypted in the
-                            server's secret key.
-
-   2       mutual-required  The MUTUAL-REQUIRED option tells the server
-                            that the client requires mutual
-                            authentication, and that it must respond
-                            with a KRB_AP_REP message.
-
-   3-31    reserved         Reserved for future use.
-
-   ticket
-      This field is a ticket authenticating the client to the server.
-
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 85]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   authenticator
-      This contains the encrypted authenticator, which includes the
-      client's choice of a subkey.
-
-   The encrypted authenticator is included in the AP-REQ; it certifies
-   to a server that the sender has recent knowledge of the encryption
-   key in the accompanying ticket, to help the server detect replays.
-   It also assists in the selection of a "true session key" to use with
-   the particular session.  The DER encoding of the following is
-   encrypted in the ticket's session key, with a key usage value of 11
-   in normal application exchanges, or 7 when used as the PA-TGS-REQ
-   PA-DATA field of a TGS-REQ exchange (see Section 5.4.1):
-
-   -- Unencrypted authenticator
-   Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-           authenticator-vno       [0] INTEGER (5),
-           crealm                  [1] Realm,
-           cname                   [2] PrincipalName,
-           cksum                   [3] Checksum OPTIONAL,
-           cusec                   [4] Microseconds,
-           ctime                   [5] KerberosTime,
-           subkey                  [6] EncryptionKey OPTIONAL,
-           seq-number              [7] UInt32 OPTIONAL,
-           authorization-data      [8] AuthorizationData OPTIONAL
-   }
-
-   authenticator-vno
-      This field specifies the version number for the format of the
-      authenticator.  This document specifies version 5.
-
-   crealm and cname
-      These fields are the same as those described for the ticket in
-      section 5.3.
-
-   cksum
-      This field contains a checksum of the application data that
-      accompanies the KRB_AP_REQ, computed using a key usage value of 10
-      in normal application exchanges, or 6 when used in the TGS-REQ
-      PA-TGS-REQ AP-DATA field.
-
-   cusec
-      This field contains the microsecond part of the client's
-      timestamp.  Its value (before encryption) ranges from 0 to 999999.
-      It often appears along with ctime.  The two fields are used
-      together to specify a reasonably accurate timestamp.
-
-   ctime
-      This field contains the current time on the client's host.
-
-
-
-Neuman, et al.              Standards Track                    [Page 86]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   subkey
-      This field contains the client's choice for an encryption key to
-      be used to protect this specific application session.  Unless an
-      application specifies otherwise, if this field is left out, the
-      session key from the ticket will be used.
-
-   seq-number
-      This optional field includes the initial sequence number to be
-      used by the KRB_PRIV or KRB_SAFE messages when sequence numbers
-      are used to detect replays.  (It may also be used by application
-      specific messages.)  When included in the authenticator, this
-      field specifies the initial sequence number for messages from the
-      client to the server.  When included in the AP-REP message, the
-      initial sequence number is that for messages from the server to
-      the client.  When used in KRB_PRIV or KRB_SAFE messages, it is
-      incremented by one after each message is sent.  Sequence numbers
-      fall in the range 0 through 2^32 - 1 and wrap to zero following
-      the value 2^32 - 1.
-
-      For sequence numbers to support the detection of replays
-      adequately, they SHOULD be non-repeating, even across connection
-      boundaries.  The initial sequence number SHOULD be random and
-      uniformly distributed across the full space of possible sequence
-      numbers, so that it cannot be guessed by an attacker and so that
-      it and the successive sequence numbers do not repeat other
-      sequences.  In the event that more than 2^32 messages are to be
-      generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying
-      SHOULD be performed before sequence numbers are reused with the
-      same encryption key.
-
-      Implmentation note: Historically, some implementations transmit
-      signed twos-complement numbers for sequence numbers.  In the
-      interests of compatibility, implementations MAY accept the
-      equivalent negative number where a positive number greater than
-      2^31 - 1 is expected.
-
-      Implementation note: As noted before, some implementations omit
-      the optional sequence number when its value would be zero.
-      Implementations MAY accept an omitted sequence number when
-      expecting a value of zero, and SHOULD NOT transmit an
-      Authenticator with a initial sequence number of zero.
-
-   authorization-data
-      This field is the same as described for the ticket in Section 5.3.
-      It is optional and will only appear when additional restrictions
-      are to be placed on the use of a ticket, beyond those carried in
-      the ticket itself.
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 87]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-5.5.2.  KRB_AP_REP Definition
-
-   The KRB_AP_REP message contains the Kerberos protocol version number,
-   the message type, and an encrypted time-stamp.  The message is sent
-   in response to an application request (KRB_AP_REQ) for which the
-   mutual authentication option has been selected in the ap-options
-   field.
-
-   AP-REP          ::= [APPLICATION 15] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (15),
-           enc-part        [2] EncryptedData -- EncAPRepPart
-   }
-
-   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
-           ctime           [0] KerberosTime,
-           cusec           [1] Microseconds,
-           subkey          [2] EncryptionKey OPTIONAL,
-           seq-number      [3] UInt32 OPTIONAL
-   }
-
-   The encoded EncAPRepPart is encrypted in the shared session key of
-   the ticket.  The optional subkey field can be used in an
-   application-arranged negotiation to choose a per association session
-   key.
-
-   pvno and msg-type
-      These fields are described above in Section 5.4.1.  msg-type is
-      KRB_AP_REP.
-
-   enc-part
-      This field is described above in Section 5.4.2.  It is computed
-      with a key usage value of 12.
-
-   ctime
-      This field contains the current time on the client's host.
-
-   cusec
-      This field contains the microsecond part of the client's
-      timestamp.
-
-   subkey
-      This field contains an encryption key that is to be used to
-      protect this specific application session.  See Section 3.2.6 for
-      specifics on how this field is used to negotiate a key.  Unless an
-      application specifies otherwise, if this field is left out, the
-      sub-session key from the authenticator or if the latter is also
-      left out, the session key from the ticket will be used.
-
-
-
-Neuman, et al.              Standards Track                    [Page 88]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   seq-number
-      This field is described above in Section 5.3.2.
-
-5.5.3.  Error Message Reply
-
-   If an error occurs while processing the application request, the
-   KRB_ERROR message will be sent in response.  See Section 5.9.1 for
-   the format of the error message.  The cname and crealm fields MAY be
-   left out if the server cannot determine their appropriate values from
-   the corresponding KRB_AP_REQ message.  If the authenticator was
-   decipherable, the ctime and cusec fields will contain the values from
-   it.
-
-5.6.  KRB_SAFE Message Specification
-
-   This section specifies the format of a message that can be used by
-   either side (client or server) of an application to send a tamper-
-   proof message to its peer.  It presumes that a session key has
-   previously been exchanged (for example, by using the
-   KRB_AP_REQ/KRB_AP_REP messages).
-
-5.6.1.  KRB_SAFE definition
-
-   The KRB_SAFE message contains user data along with a collision-proof
-   checksum keyed with the last encryption key negotiated via subkeys,
-   or with the session key if no negotiation has occurred.  The message
-   fields are as follows:
-
-   KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (20),
-           safe-body       [2] KRB-SAFE-BODY,
-           cksum           [3] Checksum
-   }
-
-   KRB-SAFE-BODY   ::= SEQUENCE {
-           user-data       [0] OCTET STRING,
-           timestamp       [1] KerberosTime OPTIONAL,
-           usec            [2] Microseconds OPTIONAL,
-           seq-number      [3] UInt32 OPTIONAL,
-           s-address       [4] HostAddress,
-           r-address       [5] HostAddress OPTIONAL
-   }
-
-   pvno and msg-type
-      These fields are described above in Section 5.4.1.  msg-type is
-      KRB_SAFE.
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 89]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   safe-body
-      This field is a placeholder for the body of the KRB-SAFE message.
-
-   cksum
-      This field contains the checksum of the application data, computed
-      with a key usage value of 15.
-
-      The checksum is computed over the encoding of the KRB-SAFE
-      sequence.  First, the cksum is set to a type zero, zero-length
-      value, and the checksum is computed over the encoding of the KRB-
-      SAFE sequence.  Then the checksum is set to the result of that
-      computation.  Finally, the KRB-SAFE sequence is encoded again.
-      This method, although different than the one specified in RFC
-      1510, corresponds to existing practice.
-
-   user-data
-      This field is part of the KRB_SAFE and KRB_PRIV messages, and
-      contains the application-specific data that is being passed from
-      the sender to the recipient.
-
-   timestamp
-      This field is part of the KRB_SAFE and KRB_PRIV messages.  Its
-      contents are the current time as known by the sender of the
-      message.  By checking the timestamp, the recipient of the message
-      is able to make sure that it was recently generated, and is not a
-      replay.
-
-   usec
-      This field is part of the KRB_SAFE and KRB_PRIV headers.  It
-      contains the microsecond part of the timestamp.
-
-   seq-number
-      This field is described above in Section 5.3.2.
-
-   s-address
-      Sender's address.
-
-      This field specifies the address in use by the sender of the
-      message.
-
-   r-address
-      This field specifies the address in use by the recipient of the
-      message.  It MAY be omitted for some uses (such as broadcast
-      protocols), but the recipient MAY arbitrarily reject such
-      messages.  This field, along with s-address, can be used to help
-      detect messages that have been incorrectly or maliciously
-      delivered to the wrong recipient.
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 90]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-5.7.  KRB_PRIV Message Specification
-
-   This section specifies the format of a message that can be used by
-   either side (client or server) of an application to send a message to
-   its peer securely and privately.  It presumes that a session key has
-   previously been exchanged (for example, by using the
-   KRB_AP_REQ/KRB_AP_REP messages).
-
-5.7.1.  KRB_PRIV Definition
-
-   The KRB_PRIV message contains user data encrypted in the Session Key.
-   The message fields are as follows:
-
-   KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (21),
-                           -- NOTE: there is no [2] tag
-           enc-part        [3] EncryptedData -- EncKrbPrivPart
-   }
-
-   EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-           user-data       [0] OCTET STRING,
-           timestamp       [1] KerberosTime OPTIONAL,
-           usec            [2] Microseconds OPTIONAL,
-           seq-number      [3] UInt32 OPTIONAL,
-           s-address       [4] HostAddress -- sender's addr --,
-           r-address       [5] HostAddress OPTIONAL -- recip's addr
-   }
-
-   pvno and msg-type
-      These fields are described above in Section 5.4.1.  msg-type is
-      KRB_PRIV.
-
-   enc-part
-      This field holds an encoding of the EncKrbPrivPart sequence
-      encrypted under the session key, with a key usage value of 13.
-      This encrypted encoding is used for the enc-part field of the
-      KRB-PRIV message.
-
-   user-data, timestamp, usec, s-address, and r-address
-      These fields are described above in Section 5.6.1.
-
-   seq-number
-      This field is described above in Section 5.3.2.
-
-
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 91]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-5.8.  KRB_CRED Message Specification
-
-   This section specifies the format of a message that can be used to
-   send Kerberos credentials from one principal to another.  It is
-   presented here to encourage a common mechanism to be used by
-   applications when forwarding tickets or providing proxies to
-   subordinate servers.  It presumes that a session key has already been
-   exchanged, perhaps by using the KRB_AP_REQ/KRB_AP_REP messages.
-
-5.8.1.  KRB_CRED Definition
-
-   The KRB_CRED message contains a sequence of tickets to be sent and
-   information needed to use the tickets, including the session key from
-   each.  The information needed to use the tickets is encrypted under
-   an encryption key previously exchanged or transferred alongside the
-   KRB_CRED message.  The message fields are as follows:
-
-   KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (22),
-           tickets         [2] SEQUENCE OF Ticket,
-           enc-part        [3] EncryptedData -- EncKrbCredPart
-   }
-
-   EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-           ticket-info     [0] SEQUENCE OF KrbCredInfo,
-           nonce           [1] UInt32 OPTIONAL,
-           timestamp       [2] KerberosTime OPTIONAL,
-           usec            [3] Microseconds OPTIONAL,
-           s-address       [4] HostAddress OPTIONAL,
-           r-address       [5] HostAddress OPTIONAL
-   }
-
-   KrbCredInfo     ::= SEQUENCE {
-           key             [0] EncryptionKey,
-           prealm          [1] Realm OPTIONAL,
-           pname           [2] PrincipalName OPTIONAL,
-           flags           [3] TicketFlags OPTIONAL,
-           authtime        [4] KerberosTime OPTIONAL,
-           starttime       [5] KerberosTime OPTIONAL,
-           endtime         [6] KerberosTime OPTIONAL,
-           renew-till      [7] KerberosTime OPTIONAL,
-           srealm          [8] Realm OPTIONAL,
-           sname           [9] PrincipalName OPTIONAL,
-           caddr           [10] HostAddresses OPTIONAL
-   }
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 92]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   pvno and msg-type
-      These fields are described above in Section 5.4.1.  msg-type is
-      KRB_CRED.
-
-   tickets
-      These are the tickets obtained from the KDC specifically for use
-      by the intended recipient.  Successive tickets are paired with the
-      corresponding KrbCredInfo sequence from the enc-part of the KRB-
-      CRED message.
-
-   enc-part
-      This field holds an encoding of the EncKrbCredPart sequence
-      encrypted under the session key shared by the sender and the
-      intended recipient, with a key usage value of 14.  This encrypted
-      encoding is used for the enc-part field of the KRB-CRED message.
-
-      Implementation note: Implementations of certain applications, most
-      notably certain implementations of the Kerberos GSS-API mechanism,
-      do not separately encrypt the contents of the EncKrbCredPart of
-      the KRB-CRED message when sending it.  In the case of those GSS-
-      API mechanisms, this is not a security vulnerability, as the
-      entire KRB-CRED message is itself embedded in an encrypted
-      message.
-
-   nonce
-      If practical, an application MAY require the inclusion of a nonce
-      generated by the recipient of the message.  If the same value is
-      included as the nonce in the message, it provides evidence that
-      the message is fresh and has not been replayed by an attacker.  A
-      nonce MUST NEVER be reused.
-
-   timestamp and usec
-      These fields specify the time that the KRB-CRED message was
-      generated.  The time is used to provide assurance that the message
-      is fresh.
-
-   s-address and r-address
-      These fields are described above in Section 5.6.1.  They are used
-      optionally to provide additional assurance of the integrity of the
-      KRB-CRED message.
-
-   key
-      This field exists in the corresponding ticket passed by the KRB-
-      CRED message and is used to pass the session key from the sender
-      to the intended recipient.  The field's encoding is described in
-      Section 5.2.9.
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 93]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   The following fields are optional.  If present, they can be
-   associated with the credentials in the remote ticket file.  If left
-   out, then it is assumed that the recipient of the credentials already
-   knows their values.
-
-   prealm and pname
-      The name and realm of the delegated principal identity.
-
-   flags, authtime, starttime, endtime, renew-till, srealm, sname,
-   and caddr
-      These fields contain the values of the corresponding fields from
-      the ticket found in the ticket field.  Descriptions of the fields
-      are identical to the descriptions in the KDC-REP message.
-
-5.9.  Error Message Specification
-
-   This section specifies the format for the KRB_ERROR message.  The
-   fields included in the message are intended to return as much
-   information as possible about an error.  It is not expected that all
-   the information required by the fields will be available for all
-   types of errors.  If the appropriate information is not available
-   when the message is composed, the corresponding field will be left
-   out of the message.
-
-   Note that because the KRB_ERROR message is not integrity protected,
-   it is quite possible for an intruder to synthesize or modify it.  In
-   particular, this means that the client SHOULD NOT use any fields in
-   this message for security-critical purposes, such as setting a system
-   clock or generating a fresh authenticator.  The message can be
-   useful, however, for advising a user on the reason for some failure.
-
-5.9.1.  KRB_ERROR Definition
-
-   The KRB_ERROR message consists of the following fields:
-
-   KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
-           pvno            [0] INTEGER (5),
-           msg-type        [1] INTEGER (30),
-           ctime           [2] KerberosTime OPTIONAL,
-           cusec           [3] Microseconds OPTIONAL,
-           stime           [4] KerberosTime,
-           susec           [5] Microseconds,
-           error-code      [6] Int32,
-           crealm          [7] Realm OPTIONAL,
-           cname           [8] PrincipalName OPTIONAL,
-           realm           [9] Realm -- service realm --,
-           sname           [10] PrincipalName -- service name --,
-           e-text          [11] KerberosString OPTIONAL,
-
-
-
-Neuman, et al.              Standards Track                    [Page 94]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-           e-data          [12] OCTET STRING OPTIONAL
-   }
-
-   pvno and msg-type
-      These fields are described above in Section 5.4.1.  msg-type is
-      KRB_ERROR.
-
-   ctime and cusec
-      These fields are described above in Section 5.5.2.  If the values
-      for these fields are known to the entity generating the error (as
-      they would be if the KRB-ERROR is generated in reply to, e.g., a
-      failed authentication service request), they should be populated
-      in the KRB-ERROR.  If the values are not available, these fields
-      can be omitted.
-
-   stime
-      This field contains the current time on the server.  It is of type
-      KerberosTime.
-
-   susec
-      This field contains the microsecond part of the server's
-      timestamp.  Its value ranges from 0 to 999999.  It appears along
-      with stime.  The two fields are used in conjunction to specify a
-      reasonably accurate timestamp.
-
-   error-code
-      This field contains the error code returned by Kerberos or the
-      server when a request fails.  To interpret the value of this field
-      see the list of error codes in Section 7.5.9.  Implementations are
-      encouraged to provide for national language support in the display
-      of error messages.
-
-   crealm, and cname
-      These fields are described above in Section 5.3.  When the entity
-      generating the error knows these values, they should be populated
-      in the KRB-ERROR.  If the values are not known, the crealm and
-      cname fields SHOULD be omitted.
-
-   realm and sname
-      These fields are described above in Section 5.3.
-
-   e-text
-      This field contains additional text to help explain the error code
-      associated with the failed request (for example, it might include
-      a principal name which was unknown).
-
-
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 95]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   e-data
-      This field contains additional data about the error for use by the
-      application to help it recover from or handle the error.  If the
-      errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
-      contain an encoding of a sequence of padata fields, each
-      corresponding to an acceptable pre-authentication method and
-      optionally containing data for the method:
-
-      METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-   For error codes defined in this document other than
-   KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field
-   are implementation-defined.  Similarly, for future error codes, the
-   format and contents of the e-data field are implementation-defined
-   unless specified otherwise.  Whether defined by the implementation or
-   in a future document, the e-data field MAY take the form of TYPED-
-   DATA:
-
-   TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-           data-type       [0] Int32,
-           data-value      [1] OCTET STRING OPTIONAL
-   }
-
-5.10.  Application Tag Numbers
-
-   The following table lists the application class tag numbers used by
-   various data types defined in this section.
-
-   Tag Number(s)  Type Name      Comments
-
-   0                             unused
-
-   1              Ticket         PDU
-
-   2              Authenticator  non-PDU
-
-   3              EncTicketPart  non-PDU
-
-   4-9                           unused
-
-   10             AS-REQ         PDU
-
-   11             AS-REP         PDU
-
-   12             TGS-REQ        PDU
-
-   13             TGS-REP        PDU
-
-
-
-
-Neuman, et al.              Standards Track                    [Page 96]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   14             AP-REQ         PDU
-
-   15             AP-REP         PDU
-
-   16             RESERVED16     TGT-REQ (for user-to-user)
-
-   17             RESERVED17     TGT-REP (for user-to-user)
-
-   18-19                         unused
-
-   20             KRB-SAFE       PDU
-
-   21             KRB-PRIV       PDU
-
-   22             KRB-CRED       PDU
-
-   23-24                         unused
-
-   25             EncASRepPart   non-PDU
-
-   26             EncTGSRepPart  non-PDU
-
-   27             EncApRepPart   non-PDU
-
-   28             EncKrbPrivPart non-PDU
-
-   29             EncKrbCredPart non-PDU
-
-   30             KRB-ERROR      PDU
-
-   The ASN.1 types marked above as "PDU" (Protocol Data Unit) are the
-   only ASN.1 types intended as top-level types of the Kerberos
-   protocol, and are the only types that may be used as elements in
-   another protocol that makes use of Kerberos.
-
-6.  Naming Constraints
-
-6.1.  Realm Names
-
-   Although realm names are encoded as GeneralStrings and technically a
-   realm can select any name it chooses, interoperability across realm
-   boundaries requires agreement on how realm names are to be assigned,
-   and what information they imply.
-
-   To enforce these conventions, each realm MUST conform to the
-   conventions itself, and it MUST require that any realms with which
-   inter-realm keys are shared also conform to the conventions and
-   require the same from its neighbors.
-
-
-
-Neuman, et al.              Standards Track                    [Page 97]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Kerberos realm names are case sensitive.  Realm names that differ
-   only in the case of the characters are not equivalent.  There are
-   presently three styles of realm names: domain, X500, and other.
-   Examples of each style follow:
-
-        domain:   ATHENA.MIT.EDU
-          X500:   C=US/O=OSF
-         other:   NAMETYPE:rest/of.name=without-restrictions
-
-   Domain style realm names MUST look like domain names: they consist of
-   components separated by periods (.) and they contain neither colons
-   (:) nor slashes (/).  Though domain names themselves are case
-   insensitive, in order for realms to match, the case must match as
-   well.  When establishing a new realm name based on an internet domain
-   name it is recommended by convention that the characters be converted
-   to uppercase.
-
-   X.500 names contain an equals sign (=) and cannot contain a colon (:)
-   before the equals sign.  The realm names for X.500 names will be
-   string representations of the names with components separated by
-   slashes.  Leading and trailing slashes will not be included.  Note
-   that the slash separator is consistent with Kerberos implementations
-   based on RFC 1510, but it is different from the separator recommended
-   in RFC 2253.
-
-   Names that fall into the other category MUST begin with a prefix that
-   contains no equals sign (=) or period (.), and the prefix MUST be
-   followed by a colon (:) and the rest of the name.  All prefixes
-   expect those beginning with used.  Presently none are assigned.
-
-   The reserved category includes strings that do not fall into the
-   first three categories.  All names in this category are reserved.  It
-   is unlikely that names will be assigned to this category unless there
-   is a very strong argument for not using the 'other' category.
-
-   These rules guarantee that there will be no conflicts between the
-   various name styles.  The following additional constraints apply to
-   the assignment of realm names in the domain and X.500 categories:
-   either the name of a realm for the domain or X.500 formats must be
-   used by the organization owning (to whom it was assigned) an Internet
-   domain name or X.500 name, or, in the case that no such names are
-   registered, authority to use a realm name MAY be derived from the
-   authority of the parent realm.  For example, if there is no domain
-   name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
-   authorize the creation of a realm with that name.
-
-   This is acceptable because the organization to which the parent is
-   assigned is presumably the organization authorized to assign names to
-
-
-
-Neuman, et al.              Standards Track                    [Page 98]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   its children in the X.500 and domain name systems as well.  If the
-   parent assigns a realm name without also registering it in the domain
-   name or X.500 hierarchy, it is the parent's responsibility to make
-   sure that in the future there will not exist a name identical to the
-   realm name of the child unless it is assigned to the same entity as
-   the realm name.
-
-6.2.  Principal Names
-
-   As was the case for realm names, conventions are needed to ensure
-   that all agree on what information is implied by a principal name.
-   The name-type field that is part of the principal name indicates the
-   kind of information implied by the name.  The name-type SHOULD be
-   treated only as a hint to interpreting the meaning of a name.  It is
-   not significant when checking for equivalence.  Principal names that
-   differ only in the name-type identify the same principal.  The name
-   type does not partition the name space.  Ignoring the name type, no
-   two names can be the same (i.e., at least one of the components, or
-   the realm, MUST be different).  The following name types are defined:
-
-   Name Type       Value  Meaning
-
-   NT-UNKNOWN        0    Name type not known
-   NT-PRINCIPAL      1    Just the name of the principal as in DCE,
-                            or for users
-   NT-SRV-INST       2    Service and other unique instance (krbtgt)
-   NT-SRV-HST        3    Service with host name as instance
-                            (telnet, rcommands)
-   NT-SRV-XHST       4    Service with host as remaining components
-   NT-UID            5    Unique ID
-   NT-X500-PRINCIPAL 6    Encoded X.509 Distinguished name [RFC2253]
-   NT-SMTP-NAME      7    Name in form of SMTP email name
-                            (e.g., user@example.com)
-   NT-ENTERPRISE    10    Enterprise name - may be mapped to principal
-                            name
-
-   When a name implies no information other than its uniqueness at a
-   particular time, the name type PRINCIPAL SHOULD be used.  The
-   principal name type SHOULD be used for users, and it might also be
-   used for a unique server.  If the name is a unique machine-generated
-   ID that is guaranteed never to be reassigned, then the name type of
-   UID SHOULD be used.  (Note that it is generally a bad idea to
-   reassign names of any type since stale entries might remain in access
-   control lists.)
-
-   If the first component of a name identifies a service and the
-   remaining components identify an instance of the service in a
-   server-specified manner, then the name type of SRV-INST SHOULD be
-
-
-
-Neuman, et al.              Standards Track                    [Page 99]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   used.  An example of this name type is the Kerberos ticket-granting
-   service whose name has a first component of krbtgt and a second
-   component identifying the realm for which the ticket is valid.
-
-   If the first component of a name identifies a service and there is a
-   single component following the service name identifying the instance
-   as the host on which the server is running, then the name type
-   SRV-HST SHOULD be used.  This type is typically used for Internet
-   services such as telnet and the Berkeley R commands.  If the separate
-   components of the host name appear as successive components following
-   the name of the service, then the name type SRV-XHST SHOULD be used.
-   This type might be used to identify servers on hosts with X.500
-   names, where the slash (/) might otherwise be ambiguous.
-
-   A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an
-   X.509 certificate is translated into a Kerberos name.  The encoding
-   of the X.509 name as a Kerberos principal shall conform to the
-   encoding rules specified in RFC 2253.
-
-   A name type of SMTP allows a name to be of a form that resembles an
-   SMTP email name.  This name, including an "@" and a domain name, is
-   used as the one component of the principal name.
-
-   A name type of UNKNOWN SHOULD be used when the form of the name is
-   not known.  When comparing names, a name of type UNKNOWN will match
-   principals authenticated with names of any type.  A principal
-   authenticated with a name of type UNKNOWN, however, will only match
-   other names of type UNKNOWN.
-
-   Names of any type with an initial component of 'krbtgt' are reserved
-   for the Kerberos ticket-granting service.  See Section 7.3 for the
-   form of such names.
-
-6.2.1.  Name of Server Principals
-
-   The principal identifier for a server on a host will generally be
-   composed of two parts: (1) the realm of the KDC with which the server
-   is registered, and (2) a two-component name of type NT-SRV-HST, if
-   the host name is an Internet domain name, or a multi-component name
-   of type NT-SRV-XHST, if the name of the host is of a form (such as
-   X.500) that allows slash (/) separators.  The first component of the
-   two- or multi-component name will identify the service, and the
-   latter components will identify the host.  Where the name of the host
-   is not case sensitive (for example, with Internet domain names) the
-   name of the host MUST be lowercase.  If specified by the application
-   protocol for services such as telnet and the Berkeley R commands that
-   run with system privileges, the first component MAY be the string
-   'host' instead of a service-specific identifier.
-
-
-
-Neuman, et al.              Standards Track                   [Page 100]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-7.  Constants and Other Defined Values
-
-7.1.  Host Address Types
-
-   All negative values for the host address type are reserved for local
-   use.  All non-negative values are reserved for officially assigned
-   type fields and interpretations.
-
-   Internet (IPv4) Addresses
-
-      Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded
-      in MSB order (most significant byte first).  The IPv4 loopback
-      address SHOULD NOT appear in a Kerberos PDU.  The type of IPv4
-      addresses is two (2).
-
-   Internet (IPv6) Addresses
-
-      IPv6 addresses [RFC3513] are 128-bit (16-octet) quantities,
-      encoded in MSB order (most significant byte first).  The type of
-      IPv6 addresses is twenty-four (24).  The following addresses MUST
-      NOT appear in any Kerberos PDU:
-
-         *  the Unspecified Address
-         *  the Loopback Address
-         *  Link-Local addresses
-
-      This restriction applies to the inclusion in the address fields of
-      Kerberos PDUs, but not to the address fields of packets that might
-      carry such PDUs.  The restriction is necessary because the use of
-      an address with non-global scope could allow the acceptance of a
-      message sent from a node that may have the same address, but which
-      is not the host intended by the entity that added the restriction.
-      If the link-local address type needs to be used for communication,
-      then the address restriction in tickets must not be used (i.e.,
-      addressless tickets must be used).
-
-      IPv4-mapped IPv6 addresses MUST be represented as addresses of
-      type 2.
-
-   DECnet Phase IV Addresses
-
-      DECnet Phase IV addresses are 16-bit addresses, encoded in LSB
-      order.  The type of DECnet Phase IV addresses is twelve (12).
-
-
-
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 101]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Netbios Addresses
-
-      Netbios addresses are 16-octet addresses typically composed of 1
-      to 15 alphanumeric characters and padded with the US-ASCII SPC
-      character (code 32).  The 16th octet MUST be the US-ASCII NUL
-      character (code 0).  The type of Netbios addresses is twenty (20).
-
-   Directional Addresses
-
-      Including the sender address in KRB_SAFE and KRB_PRIV messages is
-      undesirable in many environments because the addresses may be
-      changed in transport by network address translators.  However, if
-      these addresses are removed, the messages may be subject to a
-      reflection attack in which a message is reflected back to its
-      originator.  The directional address type provides a way to avoid
-      transport addresses and reflection attacks.  Directional addresses
-      are encoded as four-byte unsigned integers in network byte order.
-      If the message is originated by the party sending the original
-      KRB_AP_REQ message, then an address of 0 SHOULD be used.  If the
-      message is originated by the party to whom that KRB_AP_REQ was
-      sent, then the address 1 SHOULD be used.  Applications involving
-      multiple parties can specify the use of other addresses.
-
-      Directional addresses MUST only be used for the sender address
-      field in the KRB_SAFE or KRB_PRIV messages.  They MUST NOT be used
-      as a ticket address or in a KRB_AP_REQ message.  This address type
-      SHOULD only be used in situations where the sending party knows
-      that the receiving party supports the address type.  This
-      generally means that directional addresses may only be used when
-      the application protocol requires their support.  Directional
-      addresses are type (3).
-
-7.2.  KDC Messaging: IP Transports
-
-   Kerberos defines two IP transport mechanisms for communication
-   between clients and servers: UDP/IP and TCP/IP.
-
-7.2.1.  UDP/IP transport
-
-   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
-   requests and SHOULD listen for them on port 88 (decimal) unless
-   specifically configured to listen on an alternative UDP port.
-   Alternate ports MAY be used when running multiple KDCs for multiple
-   realms on the same host.
-
-
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 102]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Kerberos clients supporting IP transports SHOULD support the sending
-   of UDP requests.  Clients SHOULD use KDC discovery [7.2.3] to
-   identify the IP address and port to which they will send their
-   request.
-
-   When contacting a KDC for a KRB_KDC_REQ request using UDP/IP
-   transport, the client shall send a UDP datagram containing only an
-   encoding of the request to the KDC.  The KDC will respond with a
-   reply datagram containing only an encoding of the reply message
-   (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at the
-   sender's IP address.  The response to a request made through UDP/IP
-   transport MUST also use UDP/IP transport.  If the response cannot be
-   handled using UDP (for example, because it is too large), the KDC
-   MUST return KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the
-   request using the TCP transport.
-
-7.2.2.  TCP/IP Transport
-
-   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
-   requests and SHOULD listen for them on port 88 (decimal) unless
-   specifically configured to listen on an alternate TCP port.
-   Alternate ports MAY be used when running multiple KDCs for multiple
-   realms on the same host.
-
-   Clients MUST support the sending of TCP requests, but MAY choose to
-   try a request initially using the UDP transport.  Clients SHOULD use
-   KDC discovery [7.2.3] to identify the IP address and port to which
-   they will send their request.
-
-   Implementation note: Some extensions to the Kerberos protocol will
-   not succeed if any client or KDC not supporting the TCP transport is
-   involved.  Implementations of RFC 1510 were not required to support
-   TCP/IP transports.
-
-   When the KRB_KDC_REQ message is sent to the KDC over a TCP stream,
-   the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to
-   the client on the same TCP stream that was established for the
-   request.  The KDC MAY close the TCP stream after sending a response,
-   but MAY leave the stream open for a reasonable period of time if it
-   expects a follow-up.  Care must be taken in managing TCP/IP
-   connections on the KDC to prevent denial of service attacks based on
-   the number of open TCP/IP connections.
-
-   The client MUST be prepared to have the stream closed by the KDC at
-   any time after the receipt of a response.  A stream closure SHOULD
-   NOT be treated as a fatal error.  Instead, if multiple exchanges are
-   required (e.g., certain forms of pre-authentication), the client may
-   need to establish a new connection when it is ready to send
-
-
-
-Neuman, et al.              Standards Track                   [Page 103]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   subsequent messages.  A client MAY close the stream after receiving a
-   response, and SHOULD close the stream if it does not expect to send
-   follow-up messages.
-
-   A client MAY send multiple requests before receiving responses,
-   though it must be prepared to handle the connection being closed
-   after the first response.
-
-   Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR)
-   sent over the TCP stream is preceded by the length of the request as
-   4 octets in network byte order.  The high bit of the length is
-   reserved for future expansion and MUST currently be set to zero.  If
-   a KDC that does not understand how to interpret a set high bit of the
-   length encoding receives a request with the high order bit of the
-   length set, it MUST return a KRB-ERROR message with the error
-   KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream.
-
-   If multiple requests are sent over a single TCP connection and the
-   KDC sends multiple responses, the KDC is not required to send the
-   responses in the order of the corresponding requests.  This may
-   permit some implementations to send each response as soon as it is
-   ready, even if earlier requests are still being processed (for
-   example, waiting for a response from an external device or database).
-
-7.2.3.  KDC Discovery on IP Networks
-
-   Kerberos client implementations MUST provide a means for the client
-   to determine the location of the Kerberos Key Distribution Centers
-   (KDCs).  Traditionally, Kerberos implementations have stored such
-   configuration information in a file on each client machine.
-   Experience has shown that this method of storing configuration
-   information presents problems with out-of-date information and
-   scaling, especially when using cross-realm authentication.  This
-   section describes a method for using the Domain Name System [RFC1035]
-   for storing KDC location information.
-
-7.2.3.1.  DNS vs. Kerberos: Case Sensitivity of Realm Names
-
-   In Kerberos, realm names are case sensitive.  Although it is strongly
-   encouraged that all realm names be all uppercase, this recommendation
-   has not been adopted by all sites.  Some sites use all lowercase
-   names and other use mixed case.  DNS, on the other hand, is case
-   insensitive for queries.  Because the realm names "MYREALM",
-   "myrealm", and "MyRealm" are all different, but resolve the same in
-   the domain name system, it is necessary that only one of the possible
-   combinations of upper- and lowercase characters be used in realm
-   names.
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 104]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-7.2.3.2.  Specifying KDC Location Information with DNS SRV records
-
-   KDC location information is to be stored using the DNS SRV RR
-   [RFC2782].  The format of this RR is as follows:
-
-      _Service._Proto.Realm TTL Class SRV Priority Weight Port Target
-
-   The Service name for Kerberos is always "kerberos".
-
-   The Proto can be either "udp" or "tcp".  If these SRV records are to
-   be used, both "udp" and "tcp" records MUST be specified for all KDC
-   deployments.
-
-   The Realm is the Kerberos realm that this record corresponds to.  The
-   realm MUST be a domain-style realm name.
-
-   TTL, Class, SRV, Priority, Weight, and Target have the standard
-   meaning as defined in RFC 2782.
-
-   As per RFC 2782, the Port number used for "_udp" and "_tcp" SRV
-   records SHOULD be the value assigned to "kerberos" by the Internet
-   Assigned Number Authority: 88 (decimal), unless the KDC is configured
-   to listen on an alternate TCP port.
-
-   Implementation note: Many existing client implementations do not
-   support KDC Discovery and are configured to send requests to the IANA
-   assigned port (88 decimal), so it is strongly recommended that KDCs
-   be configured to listen on that port.
-
-7.2.3.3.  KDC Discovery for Domain Style Realm Names on IP Networks
-
-   These are DNS records for a Kerberos realm EXAMPLE.COM.  It has two
-   Kerberos servers, kdc1.example.com and kdc2.example.com.  Queries
-   should be directed to kdc1.example.com first as per the specified
-   priority.  Weights are not used in these sample records.
-
-     _kerberos._udp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
-     _kerberos._udp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
-     _kerberos._tcp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
-     _kerberos._tcp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
-
-7.3.  Name of the TGS
-
-   The principal identifier of the ticket-granting service shall be
-   composed of three parts: the realm of the KDC issuing the TGS ticket,
-   and a two-part name of type NT-SRV-INST, with the first part "krbtgt"
-   and the second part the name of the realm that will accept the TGT.
-   For example, a TGT issued by the ATHENA.MIT.EDU realm to be used to
-
-
-
-Neuman, et al.              Standards Track                   [Page 105]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   get tickets from the ATHENA.MIT.EDU KDC has a principal identifier of
-   "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name).  A TGT
-   issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
-   MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm),
-   ("krbtgt", "MIT.EDU") (name).
-
-7.4.  OID Arc for KerberosV5
-
-   This OID MAY be used to identify Kerberos protocol messages
-   encapsulated in other protocols.  It also designates the OID arc for
-   KerberosV5-related OIDs assigned by future IETF action.
-   Implementation note: RFC 1510 had an incorrect value (5) for "dod" in
-   its OID.
-
-   id-krb5         OBJECT IDENTIFIER ::= {
-           iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosV5(2)
-   }
-
-   Assignment of OIDs beneath the id-krb5 arc must be obtained by
-   contacting the registrar for the id-krb5 arc, or its designee.  At
-   the time of the issuance of this RFC, such registrations can be
-   obtained by contacting krb5-oid-registrar@mit.edu.
-
-7.5.  Protocol Constants and Associated Values
-
-   The following tables list constants used in the protocol and define
-   their meanings.  In the "specification" section, ranges are specified
-   that limit the values of constants for which values are defined here.
-   This allows implementations to make assumptions about the maximum
-   values that will be received for these constants.  Implementations
-   receiving values outside the range specified in the "specification"
-   section MAY reject the request, but they MUST recover cleanly.
-
-7.5.1.  Key Usage Numbers
-
-   The encryption and checksum specifications in [RFC3961] require as
-   input a "key usage number", to alter the encryption key used in any
-   specific message in order to make certain types of cryptographic
-   attack more difficult.  These are the key usage values assigned in
-   this document:
-
-           1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with
-               the client key (Section 5.2.7.2)
-
-
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 106]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-           2.  AS-REP Ticket and TGS-REP Ticket (includes TGS session
-               key or application session key), encrypted with the
-               service key (Section 5.3)
-           3.  AS-REP encrypted part (includes TGS session key or
-               application session key), encrypted with the client key
-               (Section 5.4.2)
-           4.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with
-               the TGS session key (Section 5.4.1)
-           5.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with
-               the TGS authenticator subkey (Section 5.4.1)
-           6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
-               keyed with the TGS session key (Section 5.5.1)
-           7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes
-               TGS authenticator subkey), encrypted with the TGS session
-               key (Section 5.5.1)
-           8.  TGS-REP encrypted part (includes application session
-               key), encrypted with the TGS session key (Section 5.4.2)
-           9.  TGS-REP encrypted part (includes application session
-               key), encrypted with the TGS authenticator subkey
-               (Section 5.4.2)
-          10.  AP-REQ Authenticator cksum, keyed with the application
-               session key (Section 5.5.1)
-          11.  AP-REQ Authenticator (includes application authenticator
-               subkey), encrypted with the application session key
-               (Section 5.5.1)
-          12.  AP-REP encrypted part (includes application session
-               subkey), encrypted with the application session key
-               (Section 5.5.2)
-          13.  KRB-PRIV encrypted part, encrypted with a key chosen by
-               the application (Section 5.7.1)
-          14.  KRB-CRED encrypted part, encrypted with a key chosen by
-               the application (Section 5.8.1)
-          15.  KRB-SAFE cksum, keyed with a key chosen by the
-               application (Section 5.6.1)
-       16-18.  Reserved for future use in Kerberos and related
-               protocols.
-          19.  AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4)
-       20-21.  Reserved for future use in Kerberos and related
-               protocols.
-       22-25.  Reserved for use in the Kerberos Version 5 GSS-API
-               mechanisms [RFC4121].
-      26-511.  Reserved for future use in Kerberos and related
-               protocols.
-    512-1023.  Reserved for uses internal to a Kerberos implementation.
-        1024.  Encryption for application use in protocols that do not
-               specify key usage values
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 107]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-        1025.  Checksums for application use in protocols that do not
-               specify key usage values
-   1026-2047.  Reserved for application use.
-
-7.5.2.  PreAuthentication Data Types
-
-   Padata and Data Type    Padata-type   Comment
-                            Value
-
-   PA-TGS-REQ                  1
-   PA-ENC-TIMESTAMP            2
-   PA-PW-SALT                  3
-   [reserved]                  4
-   PA-ENC-UNIX-TIME            5        (deprecated)
-   PA-SANDIA-SECUREID          6
-   PA-SESAME                   7
-   PA-OSF-DCE                  8
-   PA-CYBERSAFE-SECUREID       9
-   PA-AFS3-SALT                10
-   PA-ETYPE-INFO               11
-   PA-SAM-CHALLENGE            12       (sam/otp)
-   PA-SAM-RESPONSE             13       (sam/otp)
-   PA-PK-AS-REQ_OLD            14       (pkinit)
-   PA-PK-AS-REP_OLD            15       (pkinit)
-   PA-PK-AS-REQ                16       (pkinit)
-   PA-PK-AS-REP                17       (pkinit)
-   PA-ETYPE-INFO2              19       (replaces pa-etype-info)
-   PA-USE-SPECIFIED-KVNO       20
-   PA-SAM-REDIRECT             21       (sam/otp)
-   PA-GET-FROM-TYPED-DATA      22       (embedded in typed data)
-   TD-PADATA                   22       (embeds padata)
-   PA-SAM-ETYPE-INFO           23       (sam/otp)
-   PA-ALT-PRINC                24       (crawdad@fnal.gov)
-   PA-SAM-CHALLENGE2           30       (kenh@pobox.com)
-   PA-SAM-RESPONSE2            31       (kenh@pobox.com)
-   PA-EXTRA-TGT                41       Reserved extra TGT
-   TD-PKINIT-CMS-CERTIFICATES  101      CertificateSet from CMS
-   TD-KRB-PRINCIPAL            102      PrincipalName
-   TD-KRB-REALM                103      Realm
-   TD-TRUSTED-CERTIFIERS       104      from PKINIT
-   TD-CERTIFICATE-INDEX        105      from PKINIT
-   TD-APP-DEFINED-ERROR        106      application specific
-   TD-REQ-NONCE                107      INTEGER
-   TD-REQ-SEQ                  108      INTEGER
-   PA-PAC-REQUEST              128      (jbrezak@exchange.microsoft.com)
-
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 108]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-7.5.3.  Address Types
-
-   Address Type                   Value
-
-   IPv4                             2
-   Directional                      3
-   ChaosNet                         5
-   XNS                              6
-   ISO                              7
-   DECNET Phase IV                 12
-   AppleTalk DDP                   16
-   NetBios                         20
-   IPv6                            24
-
-7.5.4.  Authorization Data Types
-
-   Authorization Data Type          Ad-type Value
-
-   AD-IF-RELEVANT                     1
-   AD-INTENDED-FOR-SERVER             2
-   AD-INTENDED-FOR-APPLICATION-CLASS  3
-   AD-KDC-ISSUED                      4
-   AD-AND-OR                          5
-   AD-MANDATORY-TICKET-EXTENSIONS     6
-   AD-IN-TICKET-EXTENSIONS            7
-   AD-MANDATORY-FOR-KDC               8
-   Reserved values                 9-63
-   OSF-DCE                           64
-   SESAME                            65
-   AD-OSF-DCE-PKI-CERTID             66 (hemsath@us.ibm.com)
-   AD-WIN2K-PAC                     128 (jbrezak@exchange.microsoft.com)
-   AD-ETYPE-NEGOTIATION             129  (lzhu@windows.microsoft.com)
-
-7.5.5.  Transited Encoding Types
-
-   Transited Encoding Type         Tr-type Value
-
-   DOMAIN-X500-COMPRESS            1
-   Reserved values                 All others
-
-7.5.6.  Protocol Version Number
-
-   Label               Value   Meaning or MIT Code
-
-   pvno                  5     Current Kerberos protocol version number
-
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 109]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-7.5.7.  Kerberos Message Types
-
-   Message Type   Value  Meaning
-
-   KRB_AS_REQ      10    Request for initial authentication
-   KRB_AS_REP      11    Response to KRB_AS_REQ request
-   KRB_TGS_REQ     12    Request for authentication based on TGT
-   KRB_TGS_REP     13    Response to KRB_TGS_REQ request
-   KRB_AP_REQ      14    Application request to server
-   KRB_AP_REP      15    Response to KRB_AP_REQ_MUTUAL
-   KRB_RESERVED16  16    Reserved for user-to-user krb_tgt_request
-   KRB_RESERVED17  17    Reserved for user-to-user krb_tgt_reply
-   KRB_SAFE        20    Safe (checksummed) application message
-   KRB_PRIV        21    Private (encrypted) application message
-   KRB_CRED        22    Private (encrypted) message to forward
-                           credentials
-   KRB_ERROR       30    Error response
-
-7.5.8.  Name Types
-
-   Name Type           Value  Meaning
-
-   KRB_NT_UNKNOWN        0    Name type not known
-   KRB_NT_PRINCIPAL      1    Just the name of the principal as in DCE,
-                                or for users
-   KRB_NT_SRV_INST       2    Service and other unique instance (krbtgt)
-   KRB_NT_SRV_HST        3    Service with host name as instance
-                                (telnet, rcommands)
-   KRB_NT_SRV_XHST       4    Service with host as remaining components
-   KRB_NT_UID            5    Unique ID
-   KRB_NT_X500_PRINCIPAL 6    Encoded X.509 Distinguished name [RFC2253]
-   KRB_NT_SMTP_NAME      7    Name in form of SMTP email name
-                                (e.g., user@example.com)
-   KRB_NT_ENTERPRISE    10    Enterprise name; may be mapped to
-                                principal name
-
-7.5.9.  Error Codes
-
-   Error Code                         Value  Meaning
-
-   KDC_ERR_NONE                           0  No error
-   KDC_ERR_NAME_EXP                       1  Client's entry in database
-                                               has expired
-   KDC_ERR_SERVICE_EXP                    2  Server's entry in database
-                                               has expired
-   KDC_ERR_BAD_PVNO                       3  Requested protocol version
-                                               number not supported
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 110]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   KDC_ERR_C_OLD_MAST_KVNO                4  Client's key encrypted in
-                                               old master key
-   KDC_ERR_S_OLD_MAST_KVNO                5  Server's key encrypted in
-                                               old master key
-   KDC_ERR_C_PRINCIPAL_UNKNOWN            6  Client not found in
-                                               Kerberos database
-   KDC_ERR_S_PRINCIPAL_UNKNOWN            7  Server not found in
-                                               Kerberos database
-   KDC_ERR_PRINCIPAL_NOT_UNIQUE           8  Multiple principal entries
-                                               in database
-   KDC_ERR_NULL_KEY                       9  The client or server has a
-                                               null key
-   KDC_ERR_CANNOT_POSTDATE               10  Ticket not eligible for
-                                               postdating
-   KDC_ERR_NEVER_VALID                   11  Requested starttime is
-                                               later than end time
-   KDC_ERR_POLICY                        12  KDC policy rejects request
-   KDC_ERR_BADOPTION                     13  KDC cannot accommodate
-                                               requested option
-   KDC_ERR_ETYPE_NOSUPP                  14  KDC has no support for
-                                               encryption type
-   KDC_ERR_SUMTYPE_NOSUPP                15  KDC has no support for
-                                               checksum type
-   KDC_ERR_PADATA_TYPE_NOSUPP            16  KDC has no support for
-                                               padata type
-   KDC_ERR_TRTYPE_NOSUPP                 17  KDC has no support for
-                                               transited type
-   KDC_ERR_CLIENT_REVOKED                18  Clients credentials have
-                                               been revoked
-   KDC_ERR_SERVICE_REVOKED               19  Credentials for server have
-                                               been revoked
-   KDC_ERR_TGT_REVOKED                   20  TGT has been revoked
-   KDC_ERR_CLIENT_NOTYET                 21  Client not yet valid; try
-                                               again later
-   KDC_ERR_SERVICE_NOTYET                22  Server not yet valid; try
-                                               again later
-   KDC_ERR_KEY_EXPIRED                   23  Password has expired;
-                                               change password to reset
-   KDC_ERR_PREAUTH_FAILED                24  Pre-authentication
-                                               information was invalid
-   KDC_ERR_PREAUTH_REQUIRED              25  Additional pre-
-                                               authentication required
-   KDC_ERR_SERVER_NOMATCH                26  Requested server and ticket
-                                               don't match
-   KDC_ERR_MUST_USE_USER2USER            27  Server principal valid for
-                                               user2user only
-   KDC_ERR_PATH_NOT_ACCEPTED             28  KDC Policy rejects
-                                               transited path
-
-
-
-Neuman, et al.              Standards Track                   [Page 111]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   KDC_ERR_SVC_UNAVAILABLE               29  A service is not available
-   KRB_AP_ERR_BAD_INTEGRITY              31  Integrity check on
-                                               decrypted field failed
-   KRB_AP_ERR_TKT_EXPIRED                32  Ticket expired
-   KRB_AP_ERR_TKT_NYV                    33  Ticket not yet valid
-   KRB_AP_ERR_REPEAT                     34  Request is a replay
-   KRB_AP_ERR_NOT_US                     35  The ticket isn't for us
-   KRB_AP_ERR_BADMATCH                   36  Ticket and authenticator
-                                               don't match
-   KRB_AP_ERR_SKEW                       37  Clock skew too great
-   KRB_AP_ERR_BADADDR                    38  Incorrect net address
-   KRB_AP_ERR_BADVERSION                 39  Protocol version mismatch
-   KRB_AP_ERR_MSG_TYPE                   40  Invalid msg type
-   KRB_AP_ERR_MODIFIED                   41  Message stream modified
-   KRB_AP_ERR_BADORDER                   42  Message out of order
-   KRB_AP_ERR_BADKEYVER                  44  Specified version of key is
-                                               not available
-   KRB_AP_ERR_NOKEY                      45  Service key not available
-   KRB_AP_ERR_MUT_FAIL                   46  Mutual authentication
-                                               failed
-   KRB_AP_ERR_BADDIRECTION               47  Incorrect message direction
-   KRB_AP_ERR_METHOD                     48  Alternative authentication
-                                               method required
-   KRB_AP_ERR_BADSEQ                     49  Incorrect sequence number
-                                               in message
-   KRB_AP_ERR_INAPP_CKSUM                50  Inappropriate type of
-                                               checksum in message
-   KRB_AP_PATH_NOT_ACCEPTED              51  Policy rejects transited
-                                               path
-   KRB_ERR_RESPONSE_TOO_BIG              52  Response too big for UDP;
-                                               retry with TCP
-   KRB_ERR_GENERIC                       60  Generic error (description
-                                               in e-text)
-   KRB_ERR_FIELD_TOOLONG                 61  Field is too long for this
-                                               implementation
-   KDC_ERROR_CLIENT_NOT_TRUSTED          62  Reserved for PKINIT
-   KDC_ERROR_KDC_NOT_TRUSTED             63  Reserved for PKINIT
-   KDC_ERROR_INVALID_SIG                 64  Reserved for PKINIT
-   KDC_ERR_KEY_TOO_WEAK                  65  Reserved for PKINIT
-   KDC_ERR_CERTIFICATE_MISMATCH          66  Reserved for PKINIT
-   KRB_AP_ERR_NO_TGT                     67  No TGT available to
-                                               validate USER-TO-USER
-   KDC_ERR_WRONG_REALM                   68  Reserved for future use
-   KRB_AP_ERR_USER_TO_USER_REQUIRED      69  Ticket must be for
-                                               USER-TO-USER
-   KDC_ERR_CANT_VERIFY_CERTIFICATE       70  Reserved for PKINIT
-   KDC_ERR_INVALID_CERTIFICATE           71  Reserved for PKINIT
-   KDC_ERR_REVOKED_CERTIFICATE           72  Reserved for PKINIT
-
-
-
-Neuman, et al.              Standards Track                   [Page 112]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   KDC_ERR_REVOCATION_STATUS_UNKNOWN     73  Reserved for PKINIT
-   KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74  Reserved for PKINIT
-   KDC_ERR_CLIENT_NAME_MISMATCH          75  Reserved for PKINIT
-   KDC_ERR_KDC_NAME_MISMATCH             76  Reserved for PKINIT
-
-8.  Interoperability Requirements
-
-   Version 5 of the Kerberos protocol supports a myriad of options.
-   Among these are multiple encryption and checksum types; alternative
-   encoding schemes for the transited field; optional mechanisms for
-   pre-authentication; the handling of tickets with no addresses;
-   options for mutual authentication; user-to-user authentication;
-   support for proxies; the format of realm names; the handling of
-   authorization data; and forwarding, postdating, and renewing tickets.
-
-   In order to ensure the interoperability of realms, it is necessary to
-   define a minimal configuration that must be supported by all
-   implementations.  This minimal configuration is subject to change as
-   technology does.  For example, if at some later date it is discovered
-   that one of the required encryption or checksum algorithms is not
-   secure, it will be replaced.
-
-8.1.  Specification 2
-
-   This section defines the second specification of these options.
-   Implementations which are configured in this way can be said to
-   support Kerberos Version 5 Specification 2 (5.2).  Specification 1
-   (deprecated) may be found in RFC 1510.
-
-   Transport
-
-      TCP/IP and UDP/IP transport MUST be supported by clients and KDCs
-      claiming conformance to specification 2.
-
-   Encryption and Checksum Methods
-
-      The following encryption and checksum mechanisms MUST be
-      supported:
-
-      Encryption: AES256-CTS-HMAC-SHA1-96 [RFC3962]
-      Checksums: HMAC-SHA1-96-AES256 [RFC3962]
-
-      Implementations SHOULD support other mechanisms as well, but the
-      additional mechanisms may only be used when communicating with
-      principals known to also support them.  The following mechanisms
-      from [RFC3961] and [RFC3962] SHOULD be supported:
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 113]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-      Encryption: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD
-      Checksums: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128
-
-      Implementations MAY support other mechanisms as well, but the
-      additional mechanisms may only be used when communicating with
-      principals known to support them also.
-
-      Implementation note: Earlier implementations of Kerberos generate
-      messages using the CRC-32 and RSA-MD5 checksum methods.  For
-      interoperability with these earlier releases, implementors MAY
-      consider supporting these checksum methods but should carefully
-      analyze the security implications to limit the situations within
-      which these methods are accepted.
-
-   Realm Names
-
-      All implementations MUST understand hierarchical realms in both
-      the Internet Domain and the X.500 style.  When a TGT for an
-      unknown realm is requested, the KDC MUST be able to determine the
-      names of the intermediate realms between the KDCs realm and the
-      requested realm.
-
-   Transited Field Encoding
-
-      DOMAIN-X500-COMPRESS (described in Section 3.3.3.2) MUST be
-      supported.  Alternative encodings MAY be supported, but they may
-      only be used when that encoding is supported by ALL intermediate
-      realms.
-
-   Pre-authentication Methods
-
-      The TGS-REQ method MUST be supported.  It is not used on the
-      initial request.  The PA-ENC-TIMESTAMP method MUST be supported by
-      clients, but whether it is enabled by default MAY be determined on
-      a realm-by-realm basis.  If the method is not used in the initial
-      request and the error KDC_ERR_PREAUTH_REQUIRED is returned
-      specifying PA-ENC-TIMESTAMP as an acceptable method, the client
-      SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre-
-      authentication method.  Servers need not support the PA-ENC-
-      TIMESTAMP method, but if it is not supported the server SHOULD
-      ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a
-      request.
-
-      The ETYPE-INFO2 method MUST be supported; this method is used to
-      communicate the set of supported encryption types, and
-      corresponding salt and string to key parameters.  The ETYPE-INFO
-      method SHOULD be supported for interoperability with older
-      implementation.
-
-
-
-Neuman, et al.              Standards Track                   [Page 114]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Mutual Authentication
-
-      Mutual authentication (via the KRB_AP_REP message) MUST be
-      supported.
-
-   Ticket Addresses and Flags
-
-      All KDCs MUST pass through tickets that carry no addresses (i.e.,
-      if a TGT contains no addresses, the KDC will return derivative
-      tickets).  Implementations SHOULD default to requesting
-      addressless tickets, as this significantly increases
-      interoperability with network address translation.  In some cases,
-      realms or application servers MAY require that tickets have an
-      address.
-
-      Implementations SHOULD accept directional address type for the
-      KRB_SAFE and KRB_PRIV message and SHOULD include directional
-      addresses in these messages when other address types are not
-      available.
-
-      Proxies and forwarded tickets MUST be supported.  Individual
-      realms and application servers can set their own policy on when
-      such tickets will be accepted.
-
-      All implementations MUST recognize renewable and postdated
-      tickets, but they need not actually implement them.  If these
-      options are not supported, the starttime and endtime in the ticket
-      SHALL specify a ticket's entire useful life.  When a postdated
-      ticket is decoded by a server, all implementations SHALL make the
-      presence of the postdated flag visible to the calling server.
-
-   User-to-User Authentication
-
-      Support for user-to-user authentication (via the ENC-TKT-IN-SKEY
-      KDC option) MUST be provided by implementations, but individual
-      realms MAY decide as a matter of policy to reject such requests on
-      a per-principal or realm-wide basis.
-
-   Authorization Data
-
-      Implementations MUST pass all authorization data subfields from
-      TGTs to any derivative tickets unless they are directed to
-      suppress a subfield as part of the definition of that registered
-      subfield type.  (It is never incorrect to pass on a subfield, and
-      no registered subfield types presently specify suppression at the
-      KDC.)
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 115]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-      Implementations MUST make the contents of any authorization data
-      subfields available to the server when a ticket is used.
-      Implementations are not required to allow clients to specify the
-      contents of the authorization data fields.
-
-   Constant Ranges
-
-      All protocol constants are constrained to 32-bit (signed) values
-      unless further constrained by the protocol definition.  This limit
-      is provided to allow implementations to make assumptions about the
-      maximum values that will be received for these constants.
-      Implementations receiving values outside this range MAY reject the
-      request, but they MUST recover cleanly.
-
-8.2.  Recommended KDC Values
-
-   Following is a list of recommended values for a KDC configuration.
-
-      Minimum lifetime              5 minutes
-      Maximum renewable lifetime    1 week
-      Maximum ticket lifetime       1 day
-      Acceptable clock skew         5 minutes
-      Empty addresses               Allowed
-      Proxiable, etc.               Allowed
-
-9.  IANA Considerations
-
-   Section 7 of this document specifies protocol constants and other
-   defined values required for the interoperability of multiple
-   implementations.  Until a subsequent RFC specifies otherwise, or the
-   Kerberos working group is shut down, allocations of additional
-   protocol constants and other defined values required for extensions
-   to the Kerberos protocol will be administered by the Kerberos working
-   group.  Following the recommendations outlined in [RFC2434], guidance
-   is provided to the IANA as follows:
-
-   "reserved" realm name types in Section 6.1 and "other" realm types
-   except those beginning with "X-" or "x-" will not be registered
-   without IETF standards action, at which point guidelines for further
-   assignment will be specified.  Realm name types beginning with "X-"
-   or "x-" are for private use.
-
-   For host address types described in Section 7.1, negative values are
-   for private use.  Assignment of additional positive numbers is
-   subject to review by the Kerberos working group or other expert
-   review.
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 116]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Additional key usage numbers, as defined in Section 7.5.1, will be
-   assigned subject to review by the Kerberos working group or other
-   expert review.
-
-   Additional preauthentication data type values, as defined in section
-   7.5.2, will be assigned subject to review by the Kerberos working
-   group or other expert review.
-
-   Additional authorization data types as defined in Section 7.5.4, will
-   be assigned subject to review by the Kerberos working group or other
-   expert review.  Although it is anticipated that there may be
-   significant demand for private use types, provision is intentionally
-   not made for a private use portion of the namespace because conflicts
-   between privately assigned values could have detrimental security
-   implications.
-
-   Additional transited encoding types, as defined in Section 7.5.5,
-   present special concerns for interoperability with existing
-   implementations.  As such, such assignments will only be made by
-   standards action, except that the Kerberos working group or another
-   other working group with competent jurisdiction may make preliminary
-   assignments for documents that are moving through the standards
-   process.
-
-   Additional Kerberos message types, as described in Section 7.5.7,
-   will be assigned subject to review by the Kerberos working group or
-   other expert review.
-
-   Additional name types, as described in Section 7.5.8, will be
-   assigned subject to review by the Kerberos working group or other
-   expert review.
-
-   Additional error codes described in Section 7.5.9 will be assigned
-   subject to review by the Kerberos working group or other expert
-   review.
-
-10.  Security Considerations
-
-   As an authentication service, Kerberos provides a means of verifying
-   the identity of principals on a network.  By itself, Kerberos does
-   not provide authorization.  Applications should not accept the
-   issuance of a service ticket by the Kerberos server as granting
-   authority to use the service, since such applications may become
-   vulnerable to the bypass of this authorization check in an
-   environment where they inter-operate with other KDCs or where other
-   options for application authentication are provided.
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 117]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Denial of service attacks are not solved with Kerberos.  There are
-   places in the protocols where an intruder can prevent an application
-   from participating in the proper authentication steps.  Because
-   authentication is a required step for the use of many services,
-   successful denial of service attacks on a Kerberos server might
-   result in the denial of other network services that rely on Kerberos
-   for authentication.  Kerberos is vulnerable to many kinds of denial
-   of service attacks: those on the network, which would prevent clients
-   from contacting the KDC; those on the domain name system, which could
-   prevent a client from finding the IP address of the Kerberos server;
-   and those by overloading the Kerberos KDC itself with repeated
-   requests.
-
-   Interoperability conflicts caused by incompatible character-set usage
-   (see 5.2.1) can result in denial of service for clients that utilize
-   character-sets in Kerberos strings other than those stored in the KDC
-   database.
-
-   Authentication servers maintain a database of principals (i.e., users
-   and servers) and their secret keys.  The security of the
-   authentication server machines is critical.  The breach of security
-   of an authentication server will compromise the security of all
-   servers that rely upon the compromised KDC, and will compromise the
-   authentication of any principals registered in the realm of the
-   compromised KDC.
-
-   Principals must keep their secret keys secret.  If an intruder
-   somehow steals a principal's key, it will be able to masquerade as
-   that principal or impersonate any server to the legitimate principal.
-
-   Password-guessing attacks are not solved by Kerberos.  If a user
-   chooses a poor password, it is possible for an attacker to
-   successfully mount an off-line dictionary attack by repeatedly
-   attempting to decrypt, with successive entries from a dictionary,
-   messages obtained that are encrypted under a key derived from the
-   user's password.
-
-   Unless pre-authentication options are required by the policy of a
-   realm, the KDC will not know whether a request for authentication
-   succeeds.  An attacker can request a reply with credentials for any
-   principal.  These credentials will likely not be of much use to the
-   attacker unless it knows the client's secret key, but the
-   availability of the response encrypted in the client's secret key
-   provides the attacker with ciphertext that may be used to mount brute
-   force or dictionary attacks to decrypt the credentials, by guessing
-   the user's password.  For this reason it is strongly encouraged that
-   Kerberos realms require the use of pre-authentication.  Even with
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 118]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   pre-authentication, attackers may try brute force or dictionary
-   attacks against credentials that are observed by eavesdropping on the
-   network.
-
-   Because a client can request a ticket for any server principal and
-   can attempt a brute force or dictionary attack against the server
-   principal's key using that ticket, it is strongly encouraged that
-   keys be randomly generated (rather than generated from passwords) for
-   any principals that are usable as the target principal for a
-   KRB_TGS_REQ or KRB_AS_REQ messages.  [RFC4086]
-
-   Although the DES-CBC-MD5 encryption method and DES-MD5 checksum
-   methods are listed as SHOULD be implemented for backward
-   compatibility, the single DES encryption algorithm on which these are
-   based is weak, and stronger algorithms should be used whenever
-   possible.
-
-   Each host on the network must have a clock that is loosely
-   synchronized to the time of the other hosts; this synchronization is
-   used to reduce the bookkeeping needs of application servers when they
-   do replay detection.  The degree of "looseness" can be configured on
-   a per-server basis, but it is typically on the order of 5 minutes.
-   If the clocks are synchronized over the network, the clock
-   synchronization protocol MUST itself be secured from network
-   attackers.
-
-   Principal identifiers must not recycled on a short-term basis.  A
-   typical mode of access control will use access control lists (ACLs)
-   to grant permissions to particular principals.  If a stale ACL entry
-   remains for a deleted principal and the principal identifier is
-   reused, the new principal will inherit rights specified in the stale
-   ACL entry.  By not reusing principal identifiers, the danger of
-   inadvertent access is removed.
-
-   Proper decryption of an KRB_AS_REP message from the KDC is not
-   sufficient for the host to verify the identity of the user; the user
-   and an attacker could cooperate to generate a KRB_AS_REP format
-   message that decrypts properly but is not from the proper KDC.  To
-   authenticate a user logging on to a local system, the credentials
-   obtained in the AS exchange may first be used in a TGS exchange to
-   obtain credentials for a local server.  Those credentials must then
-   be verified by a local server through successful completion of the
-   Client/Server exchange.
-
-   Many RFC 1510-compliant implementations ignore unknown authorization
-   data elements.  Depending on these implementations to honor
-   authorization data restrictions may create a security weakness.
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 119]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Kerberos credentials contain clear-text information identifying the
-   principals to which they apply.  If privacy of this information is
-   needed, this exchange should itself be encapsulated in a protocol
-   providing for confidentiality on the exchange of these credentials.
-
-   Applications must take care to protect communications subsequent to
-   authentication, either by using the KRB_PRIV or KRB_SAFE messages as
-   appropriate, or by applying their own confidentiality or integrity
-   mechanisms on such communications.  Completion of the KRB_AP_REQ and
-   KRB_AP_REP exchange without subsequent use of confidentiality and
-   integrity mechanisms provides only for authentication of the parties
-   to the communication and not confidentiality and integrity of the
-   subsequent communication.  Applications applying confidentiality and
-   integrity protection mechanisms other than KRB_PRIV and KRB_SAFE must
-   make sure that the authentication step is appropriately linked with
-   the protected communication channel that is established by the
-   application.
-
-   Unless the application server provides its own suitable means to
-   protect against replay (for example, a challenge-response sequence
-   initiated by the server after authentication, or use of a server-
-   generated encryption subkey), the server must utilize a replay cache
-   to remember any authenticator presented within the allowable clock
-   skew.  All services sharing a key need to use the same replay cache.
-   If separate replay caches are used, then an authenticator used with
-   one such service could later be replayed to a different service with
-   the same service principal.
-
-   If a server loses track of authenticators presented within the
-   allowable clock skew, it must reject all requests until the clock
-   skew interval has passed, providing assurance that any lost or
-   replayed authenticators will fall outside the allowable clock skew
-   and can no longer be successfully replayed.
-
-   Implementations of Kerberos should not use untrusted directory
-   servers to determine the realm of a host.  To allow this would allow
-   the compromise of the directory server to enable an attacker to
-   direct the client to accept authentication with the wrong principal
-   (i.e., one with a similar name, but in a realm with which the
-   legitimate host was not registered).
-
-   Implementations of Kerberos must not use DNS to map one name to
-   another (canonicalize) in order to determine the host part of the
-   principal name with which one is to communicate.  To allow this
-   canonicalization would allow a compromise of the DNS to result in a
-   client obtaining credentials and correctly authenticating to the
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 120]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   wrong principal.  Though the client will know who it is communicating
-   with, it will not be the principal with which it intended to
-   communicate.
-
-   If the Kerberos server returns a TGT for a realm 'closer' than the
-   desired realm, the client may use local policy configuration to
-   verify that the authentication path used is an acceptable one.
-   Alternatively, a client may choose its own authentication path rather
-   than rely on the Kerberos server to select one.  In either case, any
-   policy or configuration information used to choose or validate
-   authentication paths, whether by the Kerberos server or client, must
-   be obtained from a trusted source.
-
-   The Kerberos protocol in its basic form does not provide perfect
-   forward secrecy for communications.  If traffic has been recorded by
-   an eavesdropper, then messages encrypted using the KRB_PRIV message,
-   or messages encrypted using application-specific encryption under
-   keys exchanged using Kerberos can be decrypted if the user's,
-   application server's, or KDC's key is subsequently discovered.  This
-   is because the session key used to encrypt such messages, when
-   transmitted over the network, is encrypted in the key of the
-   application server.  It is also encrypted under the session key from
-   the user's TGT when it is returned to the user in the KRB_TGS_REP
-   message.  The session key from the TGT is sent to the user in the
-   KRB_AS_REP message encrypted in the user's secret key and embedded in
-   the TGT, which was encrypted in the key of the KDC.  Applications
-   requiring perfect forward secrecy must exchange keys through
-   mechanisms that provide such assurance, but may use Kerberos for
-   authentication of the encrypted channel established through such
-   other means.
-
-11.  Acknowledgements
-
-   This document is a revision to RFC 1510 which was co-authored with
-   John Kohl.  The specification of the Kerberos protocol described in
-   this document is the result of many years of effort.  Over this
-   period, many individuals have contributed to the definition of the
-   protocol and to the writing of the specification.  Unfortunately, it
-   is not possible to list all contributors as authors of this document,
-   though there are many not listed who are authors in spirit, including
-   those who contributed text for parts of some sections, who
-   contributed to the design of parts of the protocol, and who
-   contributed significantly to the discussion of the protocol in the
-   IETF common authentication technology (CAT) and Kerberos working
-   groups.
-
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 121]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   Among those contributing to the development and specification of
-   Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan
-   Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl,
-   Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn,
-   Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome
-   Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift,
-   Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar
-   Westerlund, and Nicolas Williams.  Many other members of MIT Project
-   Athena, the MIT networking group, and the Kerberos and CAT working
-   groups of the IETF contributed but are not listed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 122]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-A.  ASN.1 module
-
-KerberosV5Spec2 {
-        iso(1) identified-organization(3) dod(6) internet(1)
-        security(5) kerberosV5(2) modules(4) krb5spec2(2)
-} DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
--- OID arc for KerberosV5
---
--- This OID may be used to identify Kerberos protocol messages
--- encapsulated in other protocols.
---
--- This OID also designates the OID arc for KerberosV5-related OIDs.
---
--- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID.
-id-krb5         OBJECT IDENTIFIER ::= {
-        iso(1) identified-organization(3) dod(6) internet(1)
-        security(5) kerberosV5(2)
-}
-
-Int32           ::= INTEGER (-2147483648..2147483647)
-                    -- signed values representable in 32 bits
-
-UInt32          ::= INTEGER (0..4294967295)
-                    -- unsigned 32 bit values
-
-Microseconds    ::= INTEGER (0..999999)
-                    -- microseconds
-
-KerberosString  ::= GeneralString (IA5String)
-
-Realm           ::= KerberosString
-
-PrincipalName   ::= SEQUENCE {
-        name-type       [0] Int32,
-        name-string     [1] SEQUENCE OF KerberosString
-}
-
-KerberosTime    ::= GeneralizedTime -- with no fractional seconds
-
-HostAddress     ::= SEQUENCE  {
-        addr-type       [0] Int32,
-        address         [1] OCTET STRING
-}
-
--- NOTE: HostAddresses is always used as an OPTIONAL field and
--- should not be empty.
-HostAddresses   -- NOTE: subtly different from rfc1510,
-
-
-
-Neuman, et al.              Standards Track                   [Page 123]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-                -- but has a value mapping and encodes the same
-        ::= SEQUENCE OF HostAddress
-
--- NOTE: AuthorizationData is always used as an OPTIONAL field and
--- should not be empty.
-AuthorizationData       ::= SEQUENCE OF SEQUENCE {
-        ad-type         [0] Int32,
-        ad-data         [1] OCTET STRING
-}
-
-PA-DATA         ::= SEQUENCE {
-        -- NOTE: first tag is [1], not [0]
-        padata-type     [1] Int32,
-        padata-value    [2] OCTET STRING -- might be encoded AP-REQ
-}
-
-KerberosFlags   ::= BIT STRING (SIZE (32..MAX))
-                    -- minimum number of bits shall be sent,
-                    -- but no fewer than 32
-
-EncryptedData   ::= SEQUENCE {
-        etype   [0] Int32 -- EncryptionType --,
-        kvno    [1] UInt32 OPTIONAL,
-        cipher  [2] OCTET STRING -- ciphertext
-}
-
-EncryptionKey   ::= SEQUENCE {
-        keytype         [0] Int32 -- actually encryption type --,
-        keyvalue        [1] OCTET STRING
-}
-
-Checksum        ::= SEQUENCE {
-        cksumtype       [0] Int32,
-        checksum        [1] OCTET STRING
-}
-
-Ticket          ::= [APPLICATION 1] SEQUENCE {
-        tkt-vno         [0] INTEGER (5),
-        realm           [1] Realm,
-        sname           [2] PrincipalName,
-        enc-part        [3] EncryptedData -- EncTicketPart
-}
-
--- Encrypted part of ticket
-EncTicketPart   ::= [APPLICATION 3] SEQUENCE {
-        flags                   [0] TicketFlags,
-        key                     [1] EncryptionKey,
-        crealm                  [2] Realm,
-
-
-
-Neuman, et al.              Standards Track                   [Page 124]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-        cname                   [3] PrincipalName,
-        transited               [4] TransitedEncoding,
-        authtime                [5] KerberosTime,
-        starttime               [6] KerberosTime OPTIONAL,
-        endtime                 [7] KerberosTime,
-        renew-till              [8] KerberosTime OPTIONAL,
-        caddr                   [9] HostAddresses OPTIONAL,
-        authorization-data      [10] AuthorizationData OPTIONAL
-}
-
--- encoded Transited field
-TransitedEncoding       ::= SEQUENCE {
-        tr-type         [0] Int32 -- must be registered --,
-        contents        [1] OCTET STRING
-}
-
-TicketFlags     ::= KerberosFlags
-        -- reserved(0),
-        -- forwardable(1),
-        -- forwarded(2),
-        -- proxiable(3),
-        -- proxy(4),
-        -- may-postdate(5),
-        -- postdated(6),
-        -- invalid(7),
-        -- renewable(8),
-        -- initial(9),
-        -- pre-authent(10),
-        -- hw-authent(11),
--- the following are new since 1510
-        -- transited-policy-checked(12),
-        -- ok-as-delegate(13)
-
-AS-REQ          ::= [APPLICATION 10] KDC-REQ
-
-TGS-REQ         ::= [APPLICATION 12] KDC-REQ
-
-KDC-REQ         ::= SEQUENCE {
-        -- NOTE: first tag is [1], not [0]
-        pvno            [1] INTEGER (5) ,
-        msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
-        padata          [3] SEQUENCE OF PA-DATA OPTIONAL
-                            -- NOTE: not empty --,
-        req-body        [4] KDC-REQ-BODY
-}
-
-KDC-REQ-BODY    ::= SEQUENCE {
-        kdc-options             [0] KDCOptions,
-
-
-
-Neuman, et al.              Standards Track                   [Page 125]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-        cname                   [1] PrincipalName OPTIONAL
-                                    -- Used only in AS-REQ --,
-        realm                   [2] Realm
-                                    -- Server's realm
-                                    -- Also client's in AS-REQ --,
-        sname                   [3] PrincipalName OPTIONAL,
-        from                    [4] KerberosTime OPTIONAL,
-        till                    [5] KerberosTime,
-        rtime                   [6] KerberosTime OPTIONAL,
-        nonce                   [7] UInt32,
-        etype                   [8] SEQUENCE OF Int32 -- EncryptionType
-                                    -- in preference order --,
-        addresses               [9] HostAddresses OPTIONAL,
-        enc-authorization-data  [10] EncryptedData OPTIONAL
-                                    -- AuthorizationData --,
-        additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
-                                        -- NOTE: not empty
-}
-
-KDCOptions      ::= KerberosFlags
-        -- reserved(0),
-        -- forwardable(1),
-        -- forwarded(2),
-        -- proxiable(3),
-        -- proxy(4),
-        -- allow-postdate(5),
-        -- postdated(6),
-        -- unused7(7),
-        -- renewable(8),
-        -- unused9(9),
-        -- unused10(10),
-        -- opt-hardware-auth(11),
-        -- unused12(12),
-        -- unused13(13),
--- 15 is reserved for canonicalize
-        -- unused15(15),
--- 26 was unused in 1510
-        -- disable-transited-check(26),
---
-        -- renewable-ok(27),
-        -- enc-tkt-in-skey(28),
-        -- renew(30),
-        -- validate(31)
-
-AS-REP          ::= [APPLICATION 11] KDC-REP
-
-TGS-REP         ::= [APPLICATION 13] KDC-REP
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 126]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-KDC-REP         ::= SEQUENCE {
-        pvno            [0] INTEGER (5),
-        msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
-        padata          [2] SEQUENCE OF PA-DATA OPTIONAL
-                                -- NOTE: not empty --,
-        crealm          [3] Realm,
-        cname           [4] PrincipalName,
-        ticket          [5] Ticket,
-        enc-part        [6] EncryptedData
-                                -- EncASRepPart or EncTGSRepPart,
-                                -- as appropriate
-}
-
-EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart
-
-EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart
-
-EncKDCRepPart   ::= SEQUENCE {
-        key             [0] EncryptionKey,
-        last-req        [1] LastReq,
-        nonce           [2] UInt32,
-        key-expiration  [3] KerberosTime OPTIONAL,
-        flags           [4] TicketFlags,
-        authtime        [5] KerberosTime,
-        starttime       [6] KerberosTime OPTIONAL,
-        endtime         [7] KerberosTime,
-        renew-till      [8] KerberosTime OPTIONAL,
-        srealm          [9] Realm,
-        sname           [10] PrincipalName,
-        caddr           [11] HostAddresses OPTIONAL
-}
-
-LastReq         ::=     SEQUENCE OF SEQUENCE {
-        lr-type         [0] Int32,
-        lr-value        [1] KerberosTime
-}
-
-AP-REQ          ::= [APPLICATION 14] SEQUENCE {
-        pvno            [0] INTEGER (5),
-        msg-type        [1] INTEGER (14),
-        ap-options      [2] APOptions,
-        ticket          [3] Ticket,
-        authenticator   [4] EncryptedData -- Authenticator
-}
-
-APOptions       ::= KerberosFlags
-        -- reserved(0),
-        -- use-session-key(1),
-
-
-
-Neuman, et al.              Standards Track                   [Page 127]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-        -- mutual-required(2)
-
--- Unencrypted authenticator
-Authenticator   ::= [APPLICATION 2] SEQUENCE  {
-        authenticator-vno       [0] INTEGER (5),
-        crealm                  [1] Realm,
-        cname                   [2] PrincipalName,
-        cksum                   [3] Checksum OPTIONAL,
-        cusec                   [4] Microseconds,
-        ctime                   [5] KerberosTime,
-        subkey                  [6] EncryptionKey OPTIONAL,
-        seq-number              [7] UInt32 OPTIONAL,
-        authorization-data      [8] AuthorizationData OPTIONAL
-}
-
-AP-REP          ::= [APPLICATION 15] SEQUENCE {
-        pvno            [0] INTEGER (5),
-        msg-type        [1] INTEGER (15),
-        enc-part        [2] EncryptedData -- EncAPRepPart
-}
-
-EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
-        ctime           [0] KerberosTime,
-        cusec           [1] Microseconds,
-        subkey          [2] EncryptionKey OPTIONAL,
-        seq-number      [3] UInt32 OPTIONAL
-}
-
-KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
-        pvno            [0] INTEGER (5),
-        msg-type        [1] INTEGER (20),
-        safe-body       [2] KRB-SAFE-BODY,
-        cksum           [3] Checksum
-}
-
-KRB-SAFE-BODY   ::= SEQUENCE {
-        user-data       [0] OCTET STRING,
-        timestamp       [1] KerberosTime OPTIONAL,
-        usec            [2] Microseconds OPTIONAL,
-        seq-number      [3] UInt32 OPTIONAL,
-        s-address       [4] HostAddress,
-        r-address       [5] HostAddress OPTIONAL
-}
-
-KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
-        pvno            [0] INTEGER (5),
-        msg-type        [1] INTEGER (21),
-                        -- NOTE: there is no [2] tag
-
-
-
-Neuman, et al.              Standards Track                   [Page 128]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-        enc-part        [3] EncryptedData -- EncKrbPrivPart
-}
-
-EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
-        user-data       [0] OCTET STRING,
-        timestamp       [1] KerberosTime OPTIONAL,
-        usec            [2] Microseconds OPTIONAL,
-        seq-number      [3] UInt32 OPTIONAL,
-        s-address       [4] HostAddress -- sender's addr --,
-        r-address       [5] HostAddress OPTIONAL -- recip's addr
-}
-
-KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
-        pvno            [0] INTEGER (5),
-        msg-type        [1] INTEGER (22),
-        tickets         [2] SEQUENCE OF Ticket,
-        enc-part        [3] EncryptedData -- EncKrbCredPart
-}
-
-EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
-        ticket-info     [0] SEQUENCE OF KrbCredInfo,
-        nonce           [1] UInt32 OPTIONAL,
-        timestamp       [2] KerberosTime OPTIONAL,
-        usec            [3] Microseconds OPTIONAL,
-        s-address       [4] HostAddress OPTIONAL,
-        r-address       [5] HostAddress OPTIONAL
-}
-
-KrbCredInfo     ::= SEQUENCE {
-        key             [0] EncryptionKey,
-        prealm          [1] Realm OPTIONAL,
-        pname           [2] PrincipalName OPTIONAL,
-        flags           [3] TicketFlags OPTIONAL,
-        authtime        [4] KerberosTime OPTIONAL,
-        starttime       [5] KerberosTime OPTIONAL,
-        endtime         [6] KerberosTime OPTIONAL,
-        renew-till      [7] KerberosTime OPTIONAL,
-        srealm          [8] Realm OPTIONAL,
-        sname           [9] PrincipalName OPTIONAL,
-        caddr           [10] HostAddresses OPTIONAL
-}
-
-KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
-        pvno            [0] INTEGER (5),
-        msg-type        [1] INTEGER (30),
-        ctime           [2] KerberosTime OPTIONAL,
-        cusec           [3] Microseconds OPTIONAL,
-        stime           [4] KerberosTime,
-
-
-
-Neuman, et al.              Standards Track                   [Page 129]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-        susec           [5] Microseconds,
-        error-code      [6] Int32,
-        crealm          [7] Realm OPTIONAL,
-        cname           [8] PrincipalName OPTIONAL,
-        realm           [9] Realm -- service realm --,
-        sname           [10] PrincipalName -- service name --,
-        e-text          [11] KerberosString OPTIONAL,
-        e-data          [12] OCTET STRING OPTIONAL
-}
-
-METHOD-DATA     ::= SEQUENCE OF PA-DATA
-
-TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-        data-type       [0] Int32,
-        data-value      [1] OCTET STRING OPTIONAL
-}
-
--- preauth stuff follows
-
-PA-ENC-TIMESTAMP        ::= EncryptedData -- PA-ENC-TS-ENC
-
-PA-ENC-TS-ENC           ::= SEQUENCE {
-        patimestamp     [0] KerberosTime -- client's time --,
-        pausec          [1] Microseconds OPTIONAL
-}
-
-ETYPE-INFO-ENTRY        ::= SEQUENCE {
-        etype           [0] Int32,
-        salt            [1] OCTET STRING OPTIONAL
-}
-
-ETYPE-INFO              ::= SEQUENCE OF ETYPE-INFO-ENTRY
-
-ETYPE-INFO2-ENTRY       ::= SEQUENCE {
-        etype           [0] Int32,
-        salt            [1] KerberosString OPTIONAL,
-        s2kparams       [2] OCTET STRING OPTIONAL
-}
-
-ETYPE-INFO2             ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
-
-AD-IF-RELEVANT          ::= AuthorizationData
-
-AD-KDCIssued            ::= SEQUENCE {
-        ad-checksum     [0] Checksum,
-        i-realm         [1] Realm OPTIONAL,
-        i-sname         [2] PrincipalName OPTIONAL,
-        elements        [3] AuthorizationData
-
-
-
-Neuman, et al.              Standards Track                   [Page 130]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-}
-
-AD-AND-OR               ::= SEQUENCE {
-        condition-count [0] Int32,
-        elements        [1] AuthorizationData
-}
-
-AD-MANDATORY-FOR-KDC    ::= AuthorizationData
-
-END
-
-B.  Changes since RFC 1510
-
-   This document replaces RFC 1510 and clarifies specification of items
-   that were not completely specified.  Where changes to recommended
-   implementation choices were made, or where new options were added,
-   those changes are described within the document and listed in this
-   section.  More significantly, "Specification 2" in Section 8 changes
-   the required encryption and checksum methods to bring them in line
-   with the best current practices and to deprecate methods that are no
-   longer considered sufficiently strong.
-
-   Discussion was added to Section 1 regarding the ability to rely on
-   the KDC to check the transited field, and on the inclusion of a flag
-   in a ticket indicating that this check has occurred.  This is a new
-   capability not present in RFC 1510.  Pre-existing implementations may
-   ignore or not set this flag without negative security implications.
-
-   The definition of the secret key says that in the case of a user the
-   key may be derived from a password.  In RFC 1510, it said that the
-   key was derived from the password.  This change was made to
-   accommodate situations where the user key might be stored on a
-   smart-card, or otherwise obtained independently of a password.
-
-   The introduction mentions the use of public key cryptography for
-   initial authentication in Kerberos by reference.  RFC 1510 did not
-   include such a reference.
-
-   Section 1.3 was added to explain that while Kerberos provides
-   authentication of a named principal, it is still the responsibility
-   of the application to ensure that the authenticated name is the
-   entity with which the application wishes to communicate.
-
-   Discussion of extensibility has been added to the introduction.
-
-   Discussion of how extensibility affects ticket flags and KDC options
-   was added to the introduction of Section 2.  No changes were made to
-   existing options and flags specified in RFC 1510, though some of the
-
-
-
-Neuman, et al.              Standards Track                   [Page 131]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   sections in the specification were renumbered, and text was revised
-   to make the description and intent of existing options clearer,
-   especially with respect to the ENC-TKT-IN-SKEY option (now section
-   2.9.2) which is used for user-to-user authentication.  The new option
-   and ticket flag transited policy checking (Section 2.7) was added.
-
-   A warning regarding generation of session keys for application use
-   was added to Section 3, urging the inclusion of key entropy from the
-   KDC generated session key in the ticket.  An example regarding use of
-   the sub-session key was added to Section 3.2.6.  Descriptions of the
-   pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data
-   items were added.  The recommendation for use of pre-authentication
-   was changed from "MAY" to "SHOULD" and a note was added regarding
-   known plaintext attacks.
-
-   In RFC 1510, Section 4 described the database in the KDC.  This
-   discussion was not necessary for interoperability and unnecessarily
-   constrained implementation.  The old Section 4 was removed.
-
-   The current Section 4 was formerly Section 6 on encryption and
-   checksum specifications.  The major part of this section was brought
-   up to date to support new encryption methods, and moved to a separate
-   document.  Those few remaining aspects of the encryption and checksum
-   specification specific to Kerberos are now specified in Section 4.
-
-   Significant changes were made to the layout of Section 5 to clarify
-   the correct behavior for optional fields.  Many of these changes were
-   made necessary because of improper ASN.1 description in the original
-   Kerberos specification which left the correct behavior
-   underspecified.  Additionally, the wording in this section was
-   tightened wherever possible to ensure that implementations conforming
-   to this specification will be extensible with the addition of new
-   fields in future specifications.
-
-   Text was added describing time_t=0 issues in the ASN.1.  Text was
-   also added, clarifying issues with implementations treating omitted
-   optional integers as zero.  Text was added clarifying behavior for
-   optional SEQUENCE or SEQUENCE OF that may be empty.  Discussion was
-   added regarding sequence numbers and behavior of some
-   implementations, including "zero" behavior and negative numbers.  A
-   compatibility note was added regarding the unconditional sending of
-   EncTGSRepPart regardless of the enclosing reply type.  Minor changes
-   were made to the description of the HostAddresses type.  Integer
-   types were constrained.  KerberosString was defined as a
-   (significantly) constrained GeneralString.  KerberosFlags was defined
-   to reflect existing implementation behavior that departs from the
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 132]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   definition in RFC 1510.  The transited-policy-checked(12) and the
-   ok-as-delegate(13) ticket flags were added.  The disable-transited-
-   check(26) KDC option was added.
-
-   Descriptions of commonly implemented PA-DATA were added to Section 5.
-   The description of KRB-SAFE has been updated to note the existing
-   implementation behavior of double-encoding.
-
-   There were two definitions of METHOD-DATA in RFC 1510.  The second
-   one, intended for use with KRB_AP_ERR_METHOD was removed leaving the
-   SEQUENCE OF PA-DATA definition.
-
-   Section 7, naming constraints, from RFC 1510 was moved to Section 6.
-
-   Words were added describing the convention that domain-based realm
-   names for newly-created realms should be specified as uppercase.
-   This recommendation does not make lowercase realm names illegal.
-   Words were added highlighting that the slash-separated components in
-   the X.500 style of realm names is consistent with existing RFC 1510
-   based implementations, but that it conflicts with the general
-   recommendation of X.500 name representation specified in RFC 2253.
-
-   Section 8, network transport, constants and defined values, from RFC
-   1510 was moved to Section 7.  Since RFC 1510, the definition of the
-   TCP transport for Kerberos messages was added, and the encryption and
-   checksum number assignments have been moved into a separate document.
-
-   "Specification 2" in Section 8 of the current document changes the
-   required encryption and checksum methods to bring them in line with
-   the best current practices and to deprecate methods that are no
-   longer considered sufficiently strong.
-
-   Two new sections, on IANA considerations and security considerations
-   were added.
-
-   The pseudo-code has been removed from the appendix.  The pseudo-code
-   was sometimes misinterpreted to limit implementation choices and in
-   RFC 1510, it was not always consistent with the words in the
-   specification.  Effort was made to clear up any ambiguities in the
-   specification, rather than to rely on the pseudo-code.
-
-   An appendix was added containing the complete ASN.1 module drawn from
-   the discussion in Section 5 of the current document.
-
-END NOTES
-
-   (*TM) Project Athena, Athena, and Kerberos are trademarks of the
-   Massachusetts Institute of Technology (MIT).
-
-
-
-Neuman, et al.              Standards Track                   [Page 133]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-Normative References
-
-   [RFC3961]          Raeburn, K., "Encryption and Checksum
-                      Specifications for Kerberos 5", RFC 3961, February
-                      2005.
-
-   [RFC3962]          Raeburn, K., "Advanced Encryption Standard (AES)
-                      Encryption for Kerberos 5", RFC 3962, February
-                      2005.
-
-   [ISO-646/ECMA-6]   International Organization for Standardization,
-                      "7-bit Coded Character Set for Information
-                      Interchange", ISO/IEC 646:1991.
-
-   [ISO-2022/ECMA-35] International Organization for Standardization,
-                      "Character code structure and extension
-                      techniques", ISO/IEC 2022:1994.
-
-   [RFC1035]          Mockapetris, P., "Domain names - implementation
-                      and specification", STD 13, RFC 1035, November
-                      1987.
-
-   [RFC2119]          Bradner, S., "Key words for use in RFCs to
-                      Indicate Requirement Levels", BCP 14, RFC 2119,
-                      March 1997.
-
-   [RFC2434]          Narten, T. and H. Alvestrand, "Guidelines for
-                      Writing an IANA Considerations Section in RFCs",
-                      BCP 26, RFC 2434, October 1998.
-
-   [RFC2782]          Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS
-                      RR for specifying the location of services (DNS
-                      SRV)", RFC 2782, February 2000.
-
-   [RFC2253]          Wahl, M., Kille, S., and T. Howes, "Lightweight
-                      Directory Access Protocol (v3): UTF-8 String
-                      Representation of Distinguished Names", RFC 2253,
-                      December 1997.
-
-   [RFC3513]          Hinden, R. and S. Deering, "Internet Protocol
-                      Version 6 (IPv6) Addressing Architecture", RFC
-                      3513, April 2003.
-
-   [X680]             Abstract Syntax Notation One (ASN.1):
-                      Specification of Basic Notation, ITU-T
-                      Recommendation X.680 (1997) | ISO/IEC
-                      International Standard 8824-1:1998.
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 134]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   [X690]             ASN.1 encoding rules: Specification of Basic
-                      Encoding Rules (BER), Canonical Encoding Rules
-                      (CER) and Distinguished Encoding Rules (DER),
-                      ITU-T Recommendation X.690 (1997)| ISO/IEC
-                      International Standard 8825-1:1998.
-
-Informative References
-
-   [ISO-8859]         International Organization for Standardization,
-                      "8-bit Single-byte Coded Graphic Character Sets --
-                      Latin Alphabet", ISO/IEC 8859.
-
-   [RFC1964]          Linn, J., "The Kerberos Version 5 GSS-API
-                      Mechanism", RFC 1964, June 1996.
-
-   [DGT96]            Don Davis, Daniel Geer, and Theodore Ts'o,
-                      "Kerberos With Clocks Adrift: History, Protocols,
-                      and Implementation", USENIX Computing Systems 9:1,
-                      January 1996.
-
-   [DS81]             Dorothy E. Denning and Giovanni Maria Sacco,
-                      "Time-stamps in Key Distribution Protocols,"
-                      Communications of the ACM, Vol. 24 (8), p. 533-
-                      536, August 1981.
-
-   [KNT94]            John T. Kohl, B. Clifford Neuman, and Theodore Y.
-                      Ts'o, "The Evolution of the Kerberos
-                      Authentication System". In Distributed Open
-                      Systems, pages 78-94. IEEE Computer Society Press,
-                      1994.
-
-   [MNSS87]           S. P. Miller, B. C. Neuman, J. I. Schiller, and J.
-                      H. Saltzer, Section E.2.1: Kerberos Authentication
-                      and Authorization System, M.I.T. Project Athena,
-                      Cambridge, Massachusetts, December 21, 1987.
-
-   [NS78]             Roger M. Needham and Michael D. Schroeder, "Using
-                      Encryption for Authentication in Large Networks of
-                      Computers," Communications of the ACM, Vol. 21
-                      (12), pp. 993-999, December 1978.
-
-   [Neu93]            B. Clifford Neuman, "Proxy-Based Authorization and
-                      Accounting for Distributed Systems," in
-                      Proceedings of the 13th International Conference
-                      on Distributed Computing Systems, Pittsburgh, PA,
-                      May 1993.
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 135]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-   [NT94]             B. Clifford Neuman and Theodore Y. Ts'o, "An
-                      Authentication Service for Computer Networks,"
-                      IEEE Communications Magazine, Vol. 32 (9), p. 33-
-                      38, September 1994.
-
-   [Pat92]            J. Pato, Using Pre-Authentication to Avoid
-                      Password Guessing Attacks, Open Software
-                      Foundation DCE Request for Comments 26 (December
-                      1992.
-
-   [RFC1510]          Kohl, J. and C. Neuman, "The Kerberos Network
-                      Authentication Service (V5)", RFC 1510, September
-                      1993.
-
-   [RFC4086]          Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-                      "Randomness Requirements for Security", BCP 106,
-                      RFC 4086, June 2005.
-
-   [SNS88]            J. G. Steiner, B. C. Neuman, and J. I. Schiller,
-                      "Kerberos: An Authentication Service for Open
-                      Network Systems," p. 191-202, Usenix Conference
-                      Proceedings, Dallas, Texas, February 1988.
-
-   [RFC4121]          Zhu, L., Jaganathan, K., and S. Hartman, "The
-                      Kerberos Version 5 Generic Security Service
-                      Application Program Interface (GSS-API) Mechanism:
-                      Version 2", RFC 4121, July 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 136]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-Authors' Addresses
-
-   Clifford Neuman
-   Information Sciences Institute
-   University of Southern California
-   4676 Admiralty Way
-   Marina del Rey, CA 90292, USA
-
-   EMail: bcn@isi.edu
-
-
-   Tom Yu
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139, USA
-
-   EMail: tlyu@mit.edu
-
-
-   Sam Hartman
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139, USA
-
-   EMail: hartmans-ietf@mit.edu
-
-
-   Kenneth Raeburn
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139, USA
-
-   EMail: raeburn@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 137]
-
-RFC 4120                      Kerberos V5                      July 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Neuman, et al.              Standards Track                   [Page 138]
-
diff --git a/doc/standardisation/rfc4121.txt b/doc/standardisation/rfc4121.txt
deleted file mode 100644
index b4115143f..000000000
--- a/doc/standardisation/rfc4121.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             L. Zhu
-Request for Comments: 4121                                 K. Jaganathan
-Updates: 1964                                                  Microsoft
-Category: Standards Track                                     S. Hartman
-                                                                     MIT
-                                                               July 2005
-
-
-                        The Kerberos Version 5
-   Generic Security Service Application Program Interface (GSS-API)
-                         Mechanism: Version 2
-
-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 defines protocols, procedures, and conventions to be
-   employed by peers implementing the Generic Security Service
-   Application Program Interface (GSS-API) when using the Kerberos
-   Version 5 mechanism.
-
-   RFC 1964 is updated and incremental changes are proposed in response
-   to recent developments such as the introduction of Kerberos
-   cryptosystem framework.  These changes support the inclusion of new
-   cryptosystems, by defining new per-message tokens along with their
-   encryption and checksum algorithms based on the cryptosystem
-   profiles.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                     [Page 1]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Key Derivation for Per-Message Tokens ...........................4
-   3. Quality of Protection ...........................................4
-   4. Definitions and Token Formats ...................................5
-      4.1. Context Establishment Tokens ...............................5
-           4.1.1. Authenticator Checksum ..............................6
-      4.2. Per-Message Tokens .........................................9
-           4.2.1. Sequence Number .....................................9
-           4.2.2. Flags Field .........................................9
-           4.2.3. EC Field ...........................................10
-           4.2.4. Encryption and Checksum Operations .................10
-           4.2.5. RRC Field ..........................................11
-           4.2.6. Message Layouts ....................................12
-      4.3. Context Deletion Tokens ...................................13
-      4.4. Token Identifier Assignment Considerations ................13
-   5. Parameter Definitions ..........................................14
-      5.1. Minor Status Codes ........................................14
-           5.1.1. Non-Kerberos-specific Codes ........................14
-           5.1.2. Kerberos-specific Codes ............................15
-      5.2. Buffer Sizes ..............................................15
-   6. Backwards Compatibility Considerations .........................15
-   7. Security Considerations ........................................16
-   8. Acknowledgements................................................17
-   9. References .....................................................18
-      9.1. Normative References ......................................18
-      9.2. Informative References ....................................18
-
-1.  Introduction
-
-   [RFC3961] defines a generic framework for describing encryption and
-   checksum types to be used with the Kerberos protocol and associated
-   protocols.
-
-   [RFC1964] describes the GSS-API mechanism for Kerberos Version 5.  It
-   defines the format of context establishment, per-message and context
-   deletion tokens, and uses algorithm identifiers for each cryptosystem
-   in per-message and context deletion tokens.
-
-   The approach taken in this document obviates the need for algorithm
-   identifiers.  This is accomplished by using the same encryption
-   algorithm, specified by the crypto profile [RFC3961] for the session
-   key or subkey that is created during context negotiation, and its
-   required checksum algorithm.  Message layouts of the per-message
-   tokens are therefore revised to remove algorithm indicators and to
-   add extra information to support the generic crypto framework
-   [RFC3961].
-
-
-
-Zhu, et al.                 Standards Track                     [Page 2]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-   Tokens transferred between GSS-API peers for security context
-   establishment are also described in this document.  The data elements
-   exchanged between a GSS-API endpoint implementation and the Kerberos
-   Key Distribution Center (KDC) [RFC4120] are not specific to GSS-API
-   usage and are therefore defined within [RFC4120] rather than this
-   specification.
-
-   The new token formats specified in this document MUST be used with
-   all "newer" encryption types [RFC4120] and MAY be used with
-   encryption types that are not "newer", provided that the initiator
-   and acceptor know from the context establishment that they can both
-   process these new token formats.
-
-   "Newer" encryption types are those which have been specified along
-   with or since the new Kerberos cryptosystem specification [RFC3961],
-   as defined in section 3.1.3 of [RFC4120].  The list of not-newer
-   encryption types is as follows [RFC3961]:
-
-           Encryption Type             Assigned Number
-         ----------------------------------------------
-          des-cbc-crc                        1
-          des-cbc-md4                        2
-          des-cbc-md5                        3
-          des3-cbc-md5                       5
-          des3-cbc-sha1                      7
-          dsaWithSHA1-CmsOID                 9
-          md5WithRSAEncryption-CmsOID       10
-          sha1WithRSAEncryption-CmsOID      11
-          rc2CBC-EnvOID                     12
-          rsaEncryption-EnvOID              13
-          rsaES-OAEP-ENV-OID                14
-          des-ede3-cbc-Env-OID              15
-          des3-cbc-sha1-kd                  16
-          rc4-hmac                          23
-
-   Conventions used in this document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   The term "little-endian order" is used for brevity to refer to the
-   least-significant-octet-first encoding, while the term "big-endian
-   order" is for the most-significant-octet-first encoding.
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                     [Page 3]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-2.  Key Derivation for Per-Message Tokens
-
-   To limit the exposure of a given key, [RFC3961] adopted "one-way"
-   "entropy-preserving" derived keys, from a base key or protocol key,
-   for different purposes or key usages.
-
-   This document defines four key usage values below that are used to
-   derive a specific key for signing and sealing messages from the
-   session key or subkey [RFC4120] created during the context
-   establishment.
-
-           Name                         Value
-         -------------------------------------
-          KG-USAGE-ACCEPTOR-SEAL         22
-          KG-USAGE-ACCEPTOR-SIGN         23
-          KG-USAGE-INITIATOR-SEAL        24
-          KG-USAGE-INITIATOR-SIGN        25
-
-   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is
-   used as the usage number in the key derivation function for deriving
-   keys to be used in MIC tokens (as defined in section 4.2.6.1).
-   KG-USAGE-ACCEPTOR-SEAL is used for Wrap tokens (as defined in section
-   4.2.6.2).  Similarly, when the sender is the context initiator,
-   KG-USAGE-INITIATOR-SIGN is used as the usage number in the key
-   derivation function for MIC tokens, while KG-USAGE-INITIATOR-SEAL is
-   used for Wrap tokens.  Even if the Wrap token does not provide for
-   confidentiality, the same usage values specified above are used.
-
-   During the context initiation and acceptance sequence, the acceptor
-   MAY assert a subkey in the AP-REP message.  If the acceptor asserts a
-   subkey, the base key is the acceptor-asserted subkey and subsequent
-   per-message tokens MUST be flagged with "AcceptorSubkey", as
-   described in section 4.2.2.  Otherwise, if the initiator asserts a
-   subkey in the AP-REQ message, the base key is this subkey;  if the
-   initiator does not assert a subkey, the base key is the session key
-   in the service ticket.
-
-3.  Quality of Protection
-
-   The GSS-API specification [RFC2743] provides Quality of Protection
-   (QOP) values that can be used by applications to request a certain
-   type of encryption or signing.  A zero QOP value is used to indicate
-   the "default" protection; applications that do not use the default
-   QOP are not guaranteed to be portable across implementations, or even
-   to inter-operate with different deployment configurations of the same
-   implementation.  Using a different algorithm than the one for which
-   the key is defined may not be appropriate.  Therefore, when the new
-   method in this document is used, the QOP value is ignored.
-
-
-
-Zhu, et al.                 Standards Track                     [Page 4]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-   The encryption and checksum algorithms in per-message tokens are now
-   implicitly defined by the algorithms associated with the session key
-   or subkey.  Therefore, algorithm identifiers as described in
-   [RFC1964] are no longer needed and are removed from the new token
-   headers.
-
-4.  Definitions and Token Formats
-
-   This section provides terms and definitions, as well as descriptions
-   for tokens specific to the Kerberos Version 5 GSS-API mechanism.
-
-4.1.  Context Establishment Tokens
-
-   All context establishment tokens emitted by the Kerberos Version 5
-   GSS-API mechanism SHALL have the framing described in section 3.1 of
-   [RFC2743], as illustrated by the following pseudo-ASN.1 structures:
-
-         GSS-API DEFINITIONS ::=
-
-         BEGIN
-
-         MechType ::= OBJECT IDENTIFIER
-         -- representing Kerberos V5 mechanism
-
-         GSSAPI-Token ::=
-         -- option indication (delegation, etc.) indicated within
-         -- mechanism-specific token
-         [APPLICATION 0] IMPLICIT SEQUENCE {
-                 thisMech MechType,
-                 innerToken ANY DEFINED BY thisMech
-                    -- contents mechanism-specific
-                    -- ASN.1 structure not required
-                 }
-
-         END
-
-   The innerToken field starts with a two-octet token-identifier
-   (TOK_ID) expressed in big-endian order, followed by a Kerberos
-   message.
-
-   Following are the TOK_ID values used in the context establishment
-   tokens:
-
-          Token               TOK_ID Value in Hex
-         -----------------------------------------
-          KRB_AP_REQ            01 00
-          KRB_AP_REP            02 00
-          KRB_ERROR             03 00
-
-
-
-Zhu, et al.                 Standards Track                     [Page 5]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-   Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR
-   are defined in [RFC4120].
-
-   If an unknown token identifier (TOK_ID) is received in the initial
-   context establishment token, the receiver MUST return
-   GSS_S_CONTINUE_NEEDED major status, and the returned output token
-   MUST contain a KRB_ERROR message with the error code
-   KRB_AP_ERR_MSG_TYPE [RFC4120].
-
-4.1.1.  Authenticator Checksum
-
-   The authenticator in the KRB_AP_REQ message MUST include the optional
-   sequence number and the checksum field.  The checksum field is used
-   to convey service flags, channel bindings, and optional delegation
-   information.
-
-   The checksum type MUST be 0x8003.  When delegation is used, a
-   ticket-granting ticket will be transferred in a KRB_CRED message.
-   This ticket SHOULD have its forwardable flag set.  The EncryptedData
-   field of the KRB_CRED message [RFC4120] MUST be encrypted in the
-   session key of the ticket used to authenticate the context.
-
-   The authenticator checksum field SHALL have the following format:
-
-       Octet        Name      Description
-      -----------------------------------------------------------------
-       0..3         Lgth    Number of octets in Bnd field;  Represented
-                            in little-endian order;  Currently contains
-                            hex value 10 00 00 00 (16).
-       4..19        Bnd     Channel binding information, as described in
-                            section 4.1.1.2.
-       20..23       Flags   Four-octet context-establishment flags in
-                            little-endian order as described in section
-                            4.1.1.1.
-       24..25       DlgOpt  The delegation option identifier (=1) in
-                            little-endian order [optional].  This field
-                            and the next two fields are present if and
-                            only if GSS_C_DELEG_FLAG is set as described
-                            in section 4.1.1.1.
-       26..27       Dlgth   The length of the Deleg field in
-                            little-endian order [optional].
-       28..(n-1)    Deleg   A KRB_CRED message (n = Dlgth + 28)
-                            [optional].
-       n..last      Exts    Extensions [optional].
-
-   The length of the checksum field MUST be at least 24 octets when
-   GSS_C_DELEG_FLAG is not set (as described in section 4.1.1.1), and at
-   least 28 octets plus Dlgth octets when GSS_C_DELEG_FLAG is set.  When
-
-
-
-Zhu, et al.                 Standards Track                     [Page 6]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-   GSS_C_DELEG_FLAG is set, the DlgOpt, Dlgth, and Deleg fields of the
-   checksum data MUST immediately follow the Flags field.  The optional
-   trailing octets (namely the "Exts" field) facilitate future
-   extensions to this mechanism.  When delegation is not used, but the
-   Exts field is present, the Exts field starts at octet 24 (DlgOpt,
-   Dlgth and Deleg are absent).
-
-   Initiators that do not support the extensions MUST NOT include more
-   than 24 octets in the checksum field (when GSS_C_DELEG_FLAG is not
-   set) or more than 28 octets plus the KRB_CRED in the Deleg field
-   (when GSS_C_DELEG_FLAG is set).  Acceptors that do not understand the
-
-   Extensions MUST ignore any octets past the Deleg field of the
-   checksum data (when GSS_C_DELEG_FLAG is set) or past the Flags field
-   of the checksum data (when GSS_C_DELEG_FLAG is not set).
-
-4.1.1.1.  Checksum Flags Field
-
-   The checksum "Flags" field is used to convey service options or
-   extension negotiation information.
-
-   The following context establishment flags are defined in [RFC2744].
-
-           Flag Name              Value
-         ---------------------------------
-          GSS_C_DELEG_FLAG           1
-          GSS_C_MUTUAL_FLAG          2
-          GSS_C_REPLAY_FLAG          4
-          GSS_C_SEQUENCE_FLAG        8
-          GSS_C_CONF_FLAG           16
-          GSS_C_INTEG_FLAG          32
-
-   Context establishment flags are exposed to the calling application.
-   If the calling application desires a particular service option, then
-   it requests that option via GSS_Init_sec_context() [RFC2743].  If the
-   corresponding return state values [RFC2743] indicate that any of the
-   above optional context level services will be active on the context,
-   the corresponding flag values in the table above MUST be set in the
-   checksum Flags field.
-
-   Flag values 4096..524288 (2^12, 2^13, ..., 2^19) are reserved for use
-   with legacy vendor-specific extensions to this mechanism.
-
-
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                     [Page 7]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-   All other flag values not specified herein are reserved for future
-   use.  Future revisions of this mechanism may use these reserved flags
-   and may rely on implementations of this version to not use such flags
-   in order to properly negotiate mechanism versions.  Undefined flag
-   values MUST be cleared by the sender, and unknown flags MUST be
-   ignored by the receiver.
-
-4.1.1.2.  Channel Binding Information
-
-   These tags are intended to be used to identify the particular
-   communications channel for which the GSS-API security context
-   establishment tokens are intended, thus limiting the scope within
-   which an intercepted context establishment token can be reused by an
-   attacker (see [RFC2743], section 1.1.6).
-
-   When using C language bindings, channel bindings are communicated to
-   the GSS-API using the following structure [RFC2744]:
-
-         typedef struct gss_channel_bindings_struct {
-            OM_uint32       initiator_addrtype;
-            gss_buffer_desc initiator_address;
-            OM_uint32       acceptor_addrtype;
-            gss_buffer_desc acceptor_address;
-            gss_buffer_desc application_data;
-         } *gss_channel_bindings_t;
-
-   The member fields and constants used for different address types are
-   defined in [RFC2744].
-
-   The "Bnd" field contains the MD5 hash of channel bindings, taken over
-   all non-null components of bindings, in order of declaration.
-   Integer fields within channel bindings are represented in little-
-   endian order for the purposes of the MD5 calculation.
-
-   In computing the contents of the Bnd field, the following detailed
-   points apply:
-
-   (1) For purposes of MD5 hash computation, each integer field and
-       input length field SHALL be formatted into four octets, using
-       little-endian octet ordering.
-
-   (2) All input length fields within gss_buffer_desc elements of a
-       gss_channel_bindings_struct even those which are zero-valued,
-       SHALL be included in the hash calculation.  The value elements of
-       gss_buffer_desc elements SHALL be dereferenced, and the resulting
-       data SHALL be included within the hash computation, only for the
-       case of gss_buffer_desc elements having non-zero length
-       specifiers.
-
-
-
-Zhu, et al.                 Standards Track                     [Page 8]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a
-       valid channel binding structure, the Bnd field SHALL be set to 16
-       zero-valued octets.
-
-   If the caller to GSS_Accept_sec_context [RFC2743] passes in
-   GSS_C_NO_CHANNEL_BINDINGS [RFC2744] as the channel bindings, then the
-   acceptor MAY ignore any channel bindings supplied by the initiator,
-   returning success even if the initiator did pass in channel bindings.
-
-   If the application supplies, in the channel bindings, a buffer with a
-   length field larger than 4294967295 (2^32 - 1), the implementation of
-   this mechanism MAY choose to reject the channel bindings altogether,
-   using major status GSS_S_BAD_BINDINGS [RFC2743].  In any case, the
-   size of channel-binding data buffers that can be used (interoperable,
-   without extensions) with this specification is limited to 4294967295
-   octets.
-
-4.2.  Per-Message Tokens
-
-   Two classes of tokens are defined in this section: (1) "MIC" tokens,
-   emitted by calls to GSS_GetMIC() and consumed by calls to
-   GSS_VerifyMIC(), and (2) "Wrap" tokens, emitted by calls to
-   GSS_Wrap() and consumed by calls to GSS_Unwrap().
-
-   These new per-message tokens do not include the generic GSS-API token
-   framing used by the context establishment tokens.  These new tokens
-   are designed to be used with newer crypto systems that can have
-   variable-size checksums.
-
-4.2.1.  Sequence Number
-
-   To distinguish intentionally-repeated messages from maliciously-
-   replayed ones, per-message tokens contain a sequence number field,
-   which is a 64 bit integer expressed in big-endian order.  After
-   sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence
-   numbers SHALL be incremented by one.
-
-4.2.2.  Flags Field
-
-   The "Flags" field is a one-octet integer used to indicate a set of
-   attributes for the protected message.  For example, one flag is
-   allocated as the direction-indicator, thus preventing the acceptance
-   of the same message sent back in the reverse direction by an
-   adversary.
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                     [Page 9]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-   The meanings of bits in this field (the least significant bit is bit
-   0) are as follows:
-
-          Bit    Name             Description
-         --------------------------------------------------------------
-          0   SentByAcceptor   When set, this flag indicates the sender
-                               is the context acceptor.  When not set,
-                               it indicates the sender is the context
-                               initiator.
-          1   Sealed           When set in Wrap tokens, this flag
-                               indicates confidentiality is provided
-                               for.  It SHALL NOT be set in MIC tokens.
-          2   AcceptorSubkey   A subkey asserted by the context acceptor
-                               is used to protect the message.
-
-   The rest of available bits are reserved for future use and MUST be
-   cleared.  The receiver MUST ignore unknown flags.
-
-4.2.3.  EC Field
-
-   The "EC" (Extra Count) field is a two-octet integer field expressed
-   in big-endian order.
-
-   In Wrap tokens with confidentiality, the EC field SHALL be used to
-   encode the number of octets in the filler, as described in section
-   4.2.4.
-
-   In Wrap tokens without confidentiality, the EC field SHALL be used to
-   encode the number of octets in the trailing checksum, as described in
-   section 4.2.4.
-
-4.2.4.  Encryption and Checksum Operations
-
-   The encryption algorithms defined by the crypto profiles provide for
-   integrity protection [RFC3961].  Therefore, no separate checksum is
-   needed.
-
-   The result of decryption can be longer than the original plaintext
-   [RFC3961] and the extra trailing octets are called "crypto-system
-   residue" in this document.  However, given the size of any plaintext
-   data, one can always find a (possibly larger) size, such that when
-   padding the to-be-encrypted text to that size, there will be no
-   crypto-system residue added [RFC3961].
-
-   In Wrap tokens that provide for confidentiality, the first 16 octets
-   of the Wrap token (the "header", as defined in section 4.2.6), SHALL
-   be appended to the plaintext data before encryption.  Filler octets
-   MAY be inserted between the plaintext data and the "header."  The
-
-
-
-Zhu, et al.                 Standards Track                    [Page 10]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-   values and size of the filler octets are chosen by implementations,
-   such that there SHALL be no crypto-system residue present after the
-   decryption.  The resulting Wrap token is {"header" |
-   encrypt(plaintext-data | filler | "header")}, where encrypt() is the
-   encryption operation (which provides for integrity protection)
-   defined in the crypto profile [RFC3961], and the RRC field (as
-   defined in section 4.2.5) in the to-be-encrypted header contains the
-   hex value 00 00.
-
-   In Wrap tokens that do not provide for confidentiality, the checksum
-   SHALL be calculated first over the to-be-signed plaintext data, and
-   then over the first 16 octets of the Wrap token (the "header", as
-   defined in section 4.2.6).  Both the EC field and the RRC field in
-   the token header SHALL be filled with zeroes for the purpose of
-   calculating the checksum.  The resulting Wrap token is {"header" |
-   plaintext-data | get_mic(plaintext-data | "header")}, where get_mic()
-   is the checksum operation for the required checksum mechanism of the
-   chosen encryption mechanism defined in the crypto profile [RFC3961].
-
-   The parameters for the key and the cipher-state in the encrypt() and
-   get_mic() operations have been omitted for brevity.
-
-   For MIC tokens, the checksum SHALL be calculated as follows: the
-   checksum operation is calculated first over the to-be-signed
-   plaintext data, and then over the first 16 octets of the MIC token,
-   where the checksum mechanism is the required checksum mechanism of
-   the chosen encryption mechanism defined in the crypto profile
-   [RFC3961].
-
-   The resulting Wrap and MIC tokens bind the data to the token header,
-   including the sequence number and the direction indicator.
-
-4.2.5.  RRC Field
-
-   The "RRC" (Right Rotation Count) field in Wrap tokens is added to
-   allow the data to be encrypted in-place by existing SSPI (Security
-   Service Provider Interface) [SSPI] applications that do not provide
-   an additional buffer for the trailer (the cipher text after the in-
-   place-encrypted data) in addition to the buffer for the header (the
-   cipher text before the in-place-encrypted data).  Excluding the first
-   16 octets of the token header, the resulting Wrap token in the
-   previous section is rotated to the right by "RRC" octets.  The net
-   result is that "RRC" octets of trailing octets are moved toward the
-   header.
-
-   Consider the following as an example of this rotation operation:
-   Assume that the RRC value is 3 and the token before the rotation is
-   {"header" | aa | bb | cc | dd | ee | ff | gg | hh}.  The token after
-
-
-
-Zhu, et al.                 Standards Track                    [Page 11]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-   rotation would be {"header" | ff | gg | hh | aa | bb | cc | dd | ee
-   }, where {aa | bb | cc |...| hh} would be used to indicate the octet
-   sequence.
-
-   The RRC field is expressed as a two-octet integer in big-endian
-   order.
-
-   The rotation count value is chosen by the sender based on
-   implementation details.  The receiver MUST be able to interpret all
-   possible rotation count values, including rotation counts greater
-   than the length of the token.
-
-4.2.6.  Message Layouts
-
-   Per-message tokens start with a two-octet token identifier (TOK_ID)
-   field, expressed in big-endian order.  These tokens are defined
-   separately in the following sub-sections.
-
-4.2.6.1.  MIC Tokens
-
-   Use of the GSS_GetMIC() call yields a token (referred as the MIC
-   token in this document), separate from the user data being protected,
-   which can be used to verify the integrity of that data as received.
-   The token has the following format:
-
-         Octet no   Name        Description
-         --------------------------------------------------------------
-         0..1     TOK_ID     Identification field.  Tokens emitted by
-                             GSS_GetMIC() contain the hex value 04 04
-                             expressed in big-endian order in this
-                             field.
-         2        Flags      Attributes field, as described in section
-                             4.2.2.
-         3..7     Filler     Contains five octets of hex value FF.
-         8..15    SND_SEQ    Sequence number field in clear text,
-                             expressed in big-endian order.
-         16..last SGN_CKSUM  Checksum of the "to-be-signed" data and
-                             octet 0..15, as described in section 4.2.4.
-
-   The Filler field is included in the checksum calculation for
-   simplicity.
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 12]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-4.2.6.2.  Wrap Tokens
-
-   Use of the GSS_Wrap() call yields a token (referred as the Wrap token
-   in this document), which consists of a descriptive header, followed
-   by a body portion that contains either the input user data in
-   plaintext concatenated with the checksum, or the input user data
-   encrypted.  The GSS_Wrap() token SHALL have the following format:
-
-         Octet no   Name        Description
-         --------------------------------------------------------------
-          0..1     TOK_ID    Identification field.  Tokens emitted by
-                             GSS_Wrap() contain the hex value 05 04
-                             expressed in big-endian order in this
-                             field.
-          2        Flags     Attributes field, as described in section
-                             4.2.2.
-          3        Filler    Contains the hex value FF.
-          4..5     EC        Contains the "extra count" field, in big-
-                             endian order as described in section 4.2.3.
-          6..7     RRC       Contains the "right rotation count" in big-
-                             endian order, as described in section
-                             4.2.5.
-          8..15    SND_SEQ   Sequence number field in clear text,
-                             expressed in big-endian order.
-          16..last Data      Encrypted data for Wrap tokens with
-                             confidentiality, or plaintext data followed
-                             by the checksum for Wrap tokens without
-                             confidentiality, as described in section
-                             4.2.4.
-
-4.3.  Context Deletion Tokens
-
-   Context deletion tokens are empty in this mechanism.  Both peers to a
-   security context invoke GSS_Delete_sec_context() [RFC2743]
-   independently, passing a null output_context_token buffer to indicate
-   that no context_token is required.  Implementations of
-   GSS_Delete_sec_context() should delete relevant locally-stored
-   context information.
-
-4.4.  Token Identifier Assignment Considerations
-
-   Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF inclusive
-   are reserved and SHALL NOT be assigned.  Thus, by examining the first
-   two octets of a token, one can tell unambiguously if it is wrapped
-   with the generic GSS-API token framing.
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 13]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-5.  Parameter Definitions
-
-   This section defines parameter values used by the Kerberos V5 GSS-API
-   mechanism.  It defines interface elements that support portability,
-   and assumes use of C language bindings per [RFC2744].
-
-5.1.  Minor Status Codes
-
-   This section recommends common symbolic names for minor_status values
-   to be returned by the Kerberos V5 GSS-API mechanism.  Use of these
-   definitions will enable independent implementers to enhance
-   application portability across different implementations of the
-   mechanism defined in this specification.  (In all cases,
-   implementations of GSS_Display_status() will enable callers to
-   convert minor_status indicators to text representations.)  Each
-   implementation should make available, through include files or other
-   means, a facility to translate these symbolic names into the concrete
-   values that a particular GSS-API implementation uses to represent the
-   minor_status values specified in this section.
-
-   This list may grow over time and the need for additional minor_status
-   codes, specific to particular implementations, may arise.  However,
-   it is recommended that implementations should return a minor_status
-   value as defined on a mechanism-wide basis within this section when
-   that code accurately represents reportable status rather than using a
-   separate, implementation-defined code.
-
-5.1.1.  Non-Kerberos-specific Codes
-
-         GSS_KRB5_S_G_BAD_SERVICE_NAME
-                 /* "No @ in SERVICE-NAME name string" */
-         GSS_KRB5_S_G_BAD_STRING_UID
-                 /* "STRING-UID-NAME contains nondigits" */
-         GSS_KRB5_S_G_NOUSER
-                 /* "UID does not resolve to username" */
-         GSS_KRB5_S_G_VALIDATE_FAILED
-                 /* "Validation error" */
-         GSS_KRB5_S_G_BUFFER_ALLOC
-                 /* "Couldn't allocate gss_buffer_t data" */
-         GSS_KRB5_S_G_BAD_MSG_CTX
-                 /* "Message context invalid" */
-         GSS_KRB5_S_G_WRONG_SIZE
-                 /* "Buffer is the wrong size" */
-         GSS_KRB5_S_G_BAD_USAGE
-                 /* "Credential usage type is unknown" */
-         GSS_KRB5_S_G_UNKNOWN_QOP
-                 /* "Unknown quality of protection specified" */
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 14]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-5.1.2.  Kerberos-specific Codes
-
-         GSS_KRB5_S_KG_CCACHE_NOMATCH
-                 /* "Client principal in credentials does not match
-                    specified name" */
-         GSS_KRB5_S_KG_KEYTAB_NOMATCH
-                 /* "No key available for specified service
-                    principal" */
-         GSS_KRB5_S_KG_TGT_MISSING
-                 /* "No Kerberos ticket-granting ticket available" */
-         GSS_KRB5_S_KG_NO_SUBKEY
-                 /* "Authenticator has no subkey" */
-         GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
-                 /* "Context is already fully established" */
-         GSS_KRB5_S_KG_BAD_SIGN_TYPE
-                 /* "Unknown signature type in token" */
-         GSS_KRB5_S_KG_BAD_LENGTH
-                 /* "Invalid field length in token" */
-         GSS_KRB5_S_KG_CTX_INCOMPLETE
-                 /* "Attempt to use incomplete security context" */
-
-5.2.  Buffer Sizes
-
-   All implementations of this specification MUST be capable of
-   accepting buffers of at least 16K octets as input to GSS_GetMIC(),
-   GSS_VerifyMIC(), and GSS_Wrap().  They MUST also be capable of
-   accepting the output_token generated by GSS_Wrap() for a 16K octet
-   input buffer as input to GSS_Unwrap().  Implementations SHOULD
-   support 64K octet input buffers, and MAY support even larger input
-   buffer sizes.
-
-6.  Backwards Compatibility Considerations
-
-   The new token formats defined in this document will only be
-   recognized by new implementations.  To address this, implementations
-   can always use the explicit sign or seal algorithm in [RFC1964] when
-   the key type corresponds to not "newer" enctypes.  As an alternative,
-   one might retry sending the message with the sign or seal algorithm
-   explicitly defined as in [RFC1964].  However, this would require
-   either the use of a mechanism such as [RFC2478] to securely negotiate
-   the method, or the use of an out-of-band mechanism to choose the
-   appropriate mechanism.  For this reason, it is RECOMMENDED that the
-   new token formats defined in this document SHOULD be used only if
-   both peers are known to support the new mechanism during context
-   negotiation because of, for example, the use of "new" enctypes.
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 15]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-   GSS_Unwrap() or GSS_VerifyMIC() can process a message token as
-   follows: it can look at the first octet of the token header, and if
-   it is 0x60, then the token must carry the generic GSS-API pseudo
-   ASN.1 framing.  Otherwise, the first two octets of the token contain
-   the TOK_ID that uniquely identify the token message format.
-
-7.  Security Considerations
-
-   Channel bindings are validated by the acceptor.  The acceptor can
-   ignore the channel bindings restriction supplied by the initiator and
-   carried in the authenticator checksum, if (1) channel bindings are
-   not used by GSS_Accept_sec_context [RFC2743], and (2) the acceptor
-   does not prove to the initiator that it has the same channel bindings
-   as the initiator (even if the client requested mutual
-   authentication).  This limitation should be considered by designers
-   of applications that would use channel bindings, whether to limit the
-   use of GSS-API contexts to nodes with specific network addresses, to
-   authenticate other established, secure channels using Kerberos
-   Version 5, or for any other purpose.
-
-   Session key types are selected by the KDC.  Under the current
-   mechanism, no negotiation of algorithm types occurs, so server-side
-   (acceptor) implementations cannot request that clients not use
-   algorithm types not understood by the server.  However,
-   administrators can control what enctypes can be used for session keys
-   for this mechanism by controlling the set of the ticket session key
-   enctypes which the KDC is willing to use in tickets for a given
-   acceptor principal.  Therefore, the KDC could be given the task of
-   limiting session keys for a given service to types actually supported
-   by the Kerberos and GSSAPI software on the server.  This has a
-   drawback for cases in which a service principal name is used for both
-   GSSAPI-based and non-GSSAPI-based communication (most notably the
-   "host" service key), if the GSSAPI implementation does not understand
-   (for example) AES [RFC3962], but the Kerberos implementation does.
-   This means that AES session keys cannot be issued for that service
-   principal, which keeps the protection of non-GSSAPI services weaker
-   than necessary.  KDC administrators desiring to limit the session key
-   types to support interoperability with such GSSAPI implementations
-   should carefully weigh the reduction in protection offered by such
-   mechanisms against the benefits of interoperability.
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 16]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-8.  Acknowledgements
-
-   Ken Raeburn and Nicolas Williams corrected many of our errors in the
-   use of generic profiles and were instrumental in the creation of this
-   document.
-
-   The text for security considerations was contributed by Nicolas
-   Williams and Ken Raeburn.
-
-   Sam Hartman and Ken Raeburn suggested the "floating trailer" idea,
-   namely the encoding of the RRC field.
-
-   Sam Hartman and Nicolas Williams recommended the replacing our
-   earlier key derivation function for directional keys with different
-   key usage numbers for each direction as well as retaining the
-   directional bit for maximum compatibility.
-
-   Paul Leach provided numerous suggestions and comments.
-
-   Scott Field, Richard Ward, Dan Simon, Kevin Damour, and Simon
-   Josefsson also provided valuable inputs on this document.
-
-   Jeffrey Hutzelman provided comments and clarifications for the text
-   related to the channel bindings.
-
-   Jeffrey Hutzelman and Russ Housley suggested many editorial changes.
-
-   Luke Howard provided implementations of this document for the Heimdal
-   code base, and helped inter-operability testing with the Microsoft
-   code base, together with Love Hornquist Astrand.  These experiments
-   formed the basis of this document.
-
-   Martin Rex provided suggestions of TOK_ID assignment recommendations,
-   thus the token tagging in this document is unambiguous if the token
-   is wrapped with the pseudo ASN.1 header.
-
-   John Linn wrote the original Kerberos Version 5 mechanism
-   specification [RFC1964], of which some text has been retained.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 17]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-9.  References
-
-9.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2:
-              C-bindings", RFC 2744, January 2000.
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
-              1964, June 1996.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-9.2.  Informative References
-
-   [SSPI]     Leach, P., "Security Service Provider Interface",
-              Microsoft Developer Network (MSDN), April 2003.
-
-   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
-              Encryption for Kerberos 5", RFC 3962, February 2005.
-
-   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
-              Negotiation Mechanism", RFC 2478, December 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 18]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-Authors' Addresses
-
-   Larry Zhu
-   One Microsoft Way
-   Redmond, WA 98052 - USA
-
-   EMail: LZhu@microsoft.com
-
-
-   Karthik Jaganathan
-   One Microsoft Way
-   Redmond, WA 98052 - USA
-
-   EMail: karthikj@microsoft.com
-
-
-   Sam Hartman
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139 - USA
-
-   EMail: hartmans-ietf@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 19]
-
-RFC 4121               Kerberos Version 5 GSS-API              July 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 20]
-
diff --git a/doc/standardisation/rfc4178.txt b/doc/standardisation/rfc4178.txt
deleted file mode 100644
index 5c71d9ed8..000000000
--- a/doc/standardisation/rfc4178.txt
+++ /dev/null
@@ -1,1235 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             L. Zhu
-Request for Comments: 4178                                      P. Leach
-Obsoletes: 2478                                            K. Jaganathan
-Category: Standards Track                          Microsoft Corporation
-                                                            W. Ingersoll
-                                                        Sun Microsystems
-                                                            October 2005
-
-
-                       The Simple and Protected
-    Generic Security Service Application Program Interface (GSS-API)
-                         Negotiation Mechanism
-
-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 specifies a negotiation mechanism for the Generic
-   Security Service Application Program Interface (GSS-API), which is
-   described in RFC 2743.  GSS-API peers can use this negotiation
-   mechanism to choose from a common set of security mechanisms.  If
-   per-message integrity services are available on the established
-   mechanism context, then the negotiation is protected against an
-   attacker that forces the selection of a mechanism not desired by the
-   peers.
-
-   This mechanism replaces RFC 2478 in order to fix defects in that
-   specification and to describe how to inter-operate with
-   implementations of that specification that are commonly deployed on
-   the Internet.
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                     [Page 1]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Conventions Used in This Document ...............................3
-   3. Negotiation Protocol ............................................3
-      3.1. Negotiation Description ....................................4
-      3.2. Negotiation Procedure ......................................5
-   4. Token Definitions ...............................................7
-      4.1. Mechanism Types ............................................7
-      4.2. Negotiation Tokens .........................................7
-           4.2.1. negTokenInit ........................................8
-           4.2.2. negTokenResp ........................................9
-   5. Processing of mechListMIC ......................................10
-   6. Extensibility ..................................................13
-   7. Security Considerations ........................................13
-   8. Acknowledgments ................................................14
-   9. References .....................................................14
-      9.1. Normative References ......................................14
-      9.2. Informative References ....................................15
-   Appendix A.  SPNEGO ASN.1 Module ..................................16
-   Appendix B.  GSS-API Negotiation Support API ......................17
-      B.1.  GSS_Set_neg_mechs Call ...................................17
-      B.2.  GSS_Get_neg_mechs Call ...................................18
-   Appendix C.  Changes since RFC 2478 ...............................18
-   Appendix D.  mechListMIC Computation Example ......................20
-
-1.  Introduction
-
-   The GSS-API [RFC2743] provides a generic interface that can be
-   layered atop different security mechanisms such that, if
-   communicating peers acquire GSS-API credentials for the same security
-   mechanism, then a security context may be established between them
-   (subject to policy).  However, GSS-API does not prescribe the method
-   by which GSS-API peers can establish whether they have a common
-   security mechanism.
-
-   The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism
-   defined here is a pseudo security mechanism that enables GSS-API
-   peers to determine in-band whether their credentials support a common
-   set of one or more GSS-API security mechanisms; if so, it invokes the
-   normal security context establishment for a selected common security
-   mechanism.  This is most useful for applications that depend on GSS-
-   API implementations and share multiple mechanisms between the peers.
-
-   The SPNEGO mechanism negotiation is based on the following model: the
-   initiator proposes a list of security mechanism(s), in decreasing
-   preference order (favorite choice first), the acceptor (also known as
-   the target) either accepts the initiator's preferred security
-
-
-
-Zhu, et al.                 Standards Track                     [Page 2]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-   mechanism (the first in the list) or chooses one of the available
-   mechanisms from the offered list; if neither is acceptable, the
-   acceptor rejects the proposed value(s).  The target then informs the
-   initiator of its choice.
-
-   Once a common security mechanism is chosen, mechanism-specific
-   options MAY be negotiated as part of the selected mechanism's context
-   establishment.  These negotiations (if any) are internal to the
-   mechanism and opaque to the SPNEGO protocol.  As such, they are
-   outside the scope of this document.
-
-   If per-message integrity services [RFC2743] are available on the
-   established mechanism security context, then the negotiation is
-   protected to ensure that the mechanism list has not been modified.
-   In cases where an attacker could have materially influenced the
-   negotiation, peers exchange message integrity code (MIC) tokens to
-   confirm that the mechanism list has not been modified.  If no action
-   of an attacker could have materially modified the outcome of the
-   negotiation, the exchange of MIC tokens is optional (see Section 5).
-   Allowing MIC tokens to be optional in this case provides
-   interoperability with existing implementations while still protecting
-   the negotiation.  This interoperability comes at the cost of
-   increased complexity.
-
-   SPNEGO relies on the concepts developed in the GSS-API specification
-   [RFC2743].  The negotiation data is encapsulated in context-level
-   tokens.  Therefore, callers of the GSS-API do not need to be aware of
-   the existence of the negotiation tokens, but only of the new pseudo-
-   security mechanism.  A failure in the negotiation phase causes a
-   major status code to be returned: GSS_S_BAD_MECH.
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-3.  Negotiation Protocol
-
-   When the established mechanism context provides integrity protection,
-   the mechanism negotiation can be protected.  When acquiring
-   negotiated security mechanism tokens, per-message integrity services
-   are always requested by the SPNEGO mechanism.
-
-   When the established mechanism context supports per-message integrity
-   services, SPNEGO guarantees that the selected mechanism is mutually
-   preferred.
-
-
-
-
-Zhu, et al.                 Standards Track                     [Page 3]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-   This section describes the negotiation process of this protocol.
-
-3.1.  Negotiation Description
-
-   The first negotiation token sent by the initiator contains an ordered
-   list of mechanisms in decreasing preference order (favorite mechanism
-   first), and optionally the initial mechanism token for the preferred
-   mechanism of the initiator (i.e., the first in the list).  (Note that
-   the list MUST NOT contain this SPNEGO mechanism itself or any
-   mechanism for which the client does not have appropriate
-   credentials.)
-
-   The target then processes the token from the initiator.  This will
-   result in one of four possible states (as defined in Section 4.2.2)
-   being returned in the reply message: accept-completed, accept-
-   incomplete, reject, or request-mic.  A reject state will terminate
-   the negotiation; an accept-completed state indicates that the
-   initiator-selected mechanism was acceptable to the target, and that
-   the security mechanism token embedded in the first negotiation
-   message was sufficient to complete the authentication; an accept-
-   incomplete state indicates that further message exchange is needed
-   but the MIC token exchange (as described in Section 5) is OPTIONAL; a
-   request-mic state (this state can only be present in the first reply
-   message from the target) indicates that the MIC token exchange is
-   REQUIRED if per-message integrity services are available.
-
-   Unless the preference order is specified by the application, the
-   policy by which the target chooses a mechanism is an implementation-
-   specific, local matter.  In the absence of an application-specified
-   preference order or other policy, the target SHALL choose the first
-   mechanism in the initiator proposed list for which it has valid
-   credentials.
-
-   In case of a successful negotiation, the security mechanism in the
-   first reply message represents the value suitable for the target that
-   was chosen from the list offered by the initiator.
-
-   In case of an unsuccessful negotiation, the reject state is returned,
-   and the generation of a context-level negotiation token is OPTIONAL.
-
-   Once a mechanism has been selected, context establishment tokens
-   specific to the selected mechanism are carried within the negotiation
-   tokens.
-
-   Lastly, MIC tokens may be exchanged to ensure the authenticity of the
-   mechanism list received by the target.
-
-
-
-
-
-Zhu, et al.                 Standards Track                     [Page 4]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-   To avoid conflicts with the use of MIC tokens by SPNEGO, partially-
-   established contexts MUST NOT be used for per-message calls.  To
-   guarantee this, the prot_ready_state [RFC2743] MUST be set to false
-   on return from GSS_Init_sec_context() and GSS_Accept_sec_context(),
-   even if the underlying mechanism returned true.
-
-   Note that in order to avoid an extra round trip, the first context
-   establishment token of the initiator's preferred mechanism SHOULD be
-   embedded in the initial negotiation message (as defined in Section
-   4.2).  (This mechanism token is referred to as the optimistic
-   mechanism token in this document.)  In addition, using the optimistic
-   mechanism token allows the initiator to recover from non-fatal errors
-   encountered when trying to produce the first mechanism token before a
-   mechanism can be selected.  In cases where the initiator's preferred
-   mechanism is not likely to be selected by the acceptor because of the
-   significant cost of its generation, implementations MAY omit the
-   optimistic mechanism token.
-
-3.2.  Negotiation Procedure
-
-   The basic form of the procedure assumes that per-message integrity
-   services are available on the established mechanism context, and it
-   is summarized as follows:
-
-   a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
-      but requests that SPNEGO be used.  SPNEGO can either be explicitly
-      requested or accepted as the default mechanism.
-
-   b) The initiator GSS-API implementation generates a negotiation token
-      containing a list of one or more security mechanisms that are
-      available based on the credentials used for this context
-      establishment, and optionally on the initial mechanism token for
-      the first mechanism in the list.
-
-   c) The GSS-API initiator application sends the token to the target
-      application.  The GSS-API target application passes the token by
-      invoking GSS_Accept_sec_context().  The acceptor will do one of
-      the following:
-
-        I) If none of the proposed mechanisms are acceptable, the
-           negotiation SHALL be terminated.  GSS_Accept_sec_context
-           indicates GSS_S_BAD_MECH.  The acceptor MAY output a
-           negotiation token containing a reject state.
-
-       II) If either the initiator's preferred mechanism is not accepted
-           by the target or this mechanism is accepted but is not the
-           acceptor's most preferred mechanism (i.e., the MIC token
-           exchange as described in Section 5 is required),
-
-
-
-Zhu, et al.                 Standards Track                     [Page 5]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-           GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED.
-           The acceptor MUST output a negotiation token containing a
-           request-mic state.
-
-      III) Otherwise, if at least one additional negotiation token from
-           the initiator is needed to establish this context,
-           GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED and
-           outputs a negotiation token containing an accept-incomplete
-           state.
-
-       IV) Otherwise, no additional negotiation token from the initiator
-           is needed to establish this context, GSS_Accept_sec_context()
-           indicates GSS_S_COMPLETE and outputs a negotiation token
-           containing an accept_complete state.
-
-      If the initiator's preferred mechanism is accepted, and an
-      optimistic mechanism token was included, this mechanism token MUST
-      be passed to the selected mechanism by invoking
-      GSS_Accept_sec_context().  If a response mechanism token is
-      returned, it MUST be included in the response negotiation token.
-      Otherwise, the target will not generate a response mechanism token
-      in the first reply.
-
-   d) The GSS-API target application returns the negotiation token to
-      the initiator application.  The GSS-API initiator application
-      passes the token by invoking GSS_Init_sec_context().  The security
-      context initialization is then continued according to the standard
-      GSS-API conventions for the selected mechanism, where the tokens
-      of the selected mechanism are encapsulated in negotiation messages
-      (see Section 4) until GSS_S_COMPLETE is returned for both the
-      initiator and the target by the selected security mechanism.
-
-   e) MIC tokens are then either skipped or exchanged according to
-      Section 5.
-
-   Note that the *_req_flag input parameters for context establishment
-   are relative to the selected mechanism, as are the *_state output
-   parameters.  That is, these parameters are not applicable to the
-   negotiation process per se.
-
-   On receipt of a negotiation token on the target side, a GSS-API
-   implementation that does not support negotiation would indicate the
-   GSS_S_BAD_MECH status as though a particular basic security mechanism
-   had been requested and was not supported.
-
-   When a GSS-API credential is acquired for the SPNEGO mechanism, the
-   implementation SHOULD produce a credential element for the SPNEGO
-   mechanism that internally contains GSS-API credential elements for
-
-
-
-Zhu, et al.                 Standards Track                     [Page 6]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-   all mechanisms for which the principal has credentials available,
-   except for any mechanisms that are not to be negotiated, per
-   implementation-, site-, or application-specific policy.  See Appendix
-   B for interfaces for expressing application policy.
-
-4.  Token Definitions
-
-   The type definitions in this section assume an ASN.1 module
-   definition of the following form:
-
-      SPNEGOASNOneSpec {
-         iso(1) identified-organization(3) dod(6) internet(1)
-         security(5) mechanism(5) snego (2) modules(4) spec2(2)
-      } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-      -- rest of definitions here
-
-      END
-
-   This specifies that the tagging context for the module will be
-   explicit and non-automatic.
-
-   The encoding of the SPNEGO protocol messages shall obey the
-   Distinguished Encoding Rules (DER) of ASN.1, as described in [X690].
-
-4.1.  Mechanism Types
-
-   In this negotiation model, each OID represents one GSS-API mechanism
-   or one variant (see Section 6) of it, according to [RFC2743].
-
-      MechType ::= OBJECT IDENTIFIER
-          -- OID represents each security mechanism as suggested by
-          -- [RFC2743]
-
-      MechTypeList ::= SEQUENCE OF MechType
-
-4.2.  Negotiation Tokens
-
-   The syntax of the initial negotiation tokens follows the
-   initialContextToken syntax defined in Section 3.1 of [RFC2743].  The
-   SPNEGO pseudo mechanism is identified by the Object Identifier
-   iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).
-   Subsequent tokens MUST NOT be encapsulated in this GSS-API generic
-   token framing.
-
-   This section specifies the syntax of the inner token for the initial
-   message and the syntax of subsequent context establishment tokens.
-
-
-
-
-Zhu, et al.                 Standards Track                     [Page 7]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-      NegotiationToken ::= CHOICE {
-          negTokenInit    [0] NegTokenInit,
-          negTokenResp    [1] NegTokenResp
-      }
-
-4.2.1.  negTokenInit
-
-      NegTokenInit ::= SEQUENCE {
-          mechTypes       [0] MechTypeList,
-          reqFlags        [1] ContextFlags  OPTIONAL,
-            -- inherited from RFC 2478 for backward compatibility,
-            -- RECOMMENDED to be left out
-          mechToken       [2] OCTET STRING  OPTIONAL,
-          mechListMIC     [3] OCTET STRING  OPTIONAL,
-          ...
-      }
-      ContextFlags ::= BIT STRING {
-          delegFlag       (0),
-          mutualFlag      (1),
-          replayFlag      (2),
-          sequenceFlag    (3),
-          anonFlag        (4),
-          confFlag        (5),
-          integFlag       (6)
-      } (SIZE (32))
-
-   This is the syntax for the inner token of the initial negotiation
-   message.
-
-   mechTypes
-
-      This field contains one or more security mechanisms available for
-      the initiator, in decreasing preference order (favorite choice
-      first).
-
-   reqFlags
-
-      This field, if present, contains the service options that are
-      requested to establish the context (the req_flags parameter of
-      GSS_Init_sec_context()).  This field is inherited from RFC 2478
-      and is not integrity protected.  For implementations of this
-      specification, the initiator SHOULD omit this reqFlags field and
-      the acceptor MUST ignore this reqFlags field.
-
-      The size constraint on the ContextFlags ASN.1 type only applies to
-      the abstract type.  The ASN.1 DER requires that all trailing zero
-      bits be truncated from the encoding of a bit string type whose
-      abstract definition includes named bits.  Implementations should
-
-
-
-Zhu, et al.                 Standards Track                     [Page 8]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-      not expect to receive exactly 32 bits in an encoding of
-      ContextFlags.
-
-   mechToken
-
-      This field, if present, contains the optimistic mechanism token.
-
-   mechlistMIC
-
-      This field, if present, contains an MIC token for the mechanism
-      list in the initial negotiation message.  This MIC token is
-      computed according to Section 5.
-
-4.2.2.  negTokenResp
-
-      NegTokenResp ::= SEQUENCE {
-          negState       [0] ENUMERATED {
-              accept-completed    (0),
-              accept-incomplete   (1),
-              reject              (2),
-              request-mic         (3)
-          }                                 OPTIONAL,
-            -- REQUIRED in the first reply from the target
-          supportedMech   [1] MechType      OPTIONAL,
-            -- present only in the first reply from the target
-          responseToken   [2] OCTET STRING  OPTIONAL,
-          mechListMIC     [3] OCTET STRING  OPTIONAL,
-          ...
-      }
-
-   This is the syntax for all subsequent negotiation messages.
-
-   negState
-
-      This field, if present, contains the state of the negotiation.
-      This can be:
-
-      accept-completed
-
-         No further negotiation message from the peer is expected, and
-         the security context is established for the sender.
-
-      accept-incomplete
-
-         At least one additional negotiation message from the peer is
-         needed to establish the security context.
-
-
-
-
-
-Zhu, et al.                 Standards Track                     [Page 9]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-      reject
-
-         The sender terminates the negotiation.
-
-      request-mic
-
-         The sender indicates that the exchange of MIC tokens, as
-         described in Section 5, will be REQUIRED if per-message
-         integrity services are available on the mechanism context to be
-         established.  This value SHALL only be present in the first
-         reply from the target.
-
-      This field is REQUIRED in the first reply from the target, and is
-      OPTIONAL thereafter.  When negState is absent, the actual state
-      should be inferred from the state of the negotiated mechanism
-      context.
-
-   supportedMech
-
-      This field SHALL only be present in the first reply from the
-      target.  It MUST be one of the mechanism(s) offered by the
-      initiator.
-
-   ResponseToken
-
-      This field, if present, contains tokens specific to the mechanism
-      selected.
-
-   mechlistMIC
-
-      This field, if present, contains an MIC token for the mechanism
-      list in the initial negotiation message.  This MIC token is
-      computed according to Section 5.
-
-5.  Processing of mechListMIC
-
-   If the mechanism selected by the negotiation does not support
-   integrity protection, then no mechlistMIC token is used.
-
-   Otherwise, if the accepted mechanism is the most preferred mechanism
-   of both the initiator and the acceptor, then the MIC token exchange,
-   as described later in this section, is OPTIONAL.  A mechanism is the
-   acceptor's most preferred mechanism if there is no other mechanism
-   that the acceptor would have preferred over the accepted mechanism
-   had it been present in the mechanism list.
-
-   In all other cases, MIC tokens MUST be exchanged after the mechanism
-   context is fully established.
-
-
-
-Zhu, et al.                 Standards Track                    [Page 10]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-   a) The mechlistMIC token (or simply the MIC token) is computed over
-      the mechanism list in the initial negotiation message by invoking
-      GSS_GetMIC() as follows: the input context_handle is the
-      established mechanism context, the input qop_req is 0, and the
-      input message is the DER encoding of the value of type
-      MechTypeList, which is contained in the "mechTypes" field of the
-      NegTokenInit.  The input message is NOT the DER encoding of the
-      type "[0] MechTypeList".
-
-   b) If the selected mechanism exchanges an even number of mechanism
-      tokens (i.e., the acceptor sends the last mechanism token), the
-      acceptor does the following when generating the negotiation
-      message containing the last mechanism token: if the MIC token
-      exchange is optional, GSS_Accept_sec_context() either indicates
-      GSS_S_COMPLETE and does not include a mechlistMIC token, or
-      indicates GSS_S_CONTINUE_NEEDED and includes a mechlistMIC token
-      and an accept-incomplete state; if the MIC token exchange is
-      required, GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED
-      and includes a mechlistMIC token.  Acceptors that wish to be
-      compatible with legacy Windows SPNEGO implementations, as
-      described in Appendix C, should not generate a mechlistMIC token
-      when the MIC token exchange is not required.  The initiator then
-      processes the last mechanism token, and does one of the following:
-
-        I) If a mechlistMIC token was included and is correctly
-           verified, GSS_Init_sec_context() indicates GSS_S_COMPLETE.
-           The output negotiation message contains a mechlistMIC token
-           and an accept_complete state.  The acceptor MUST then verify
-           this mechlistMIC token.
-
-       II) If a mechlistMIC token was included but is incorrect, the
-           negotiation SHALL be terminated.  GSS_Init_sec_context()
-           indicates GSS_S_DEFECTIVE_TOKEN.
-
-      III) If no mechlistMIC token was included and the MIC token
-           exchange is not required, GSS_Init_sec_context() indicates
-           GSS_S_COMPLETE with no output token.
-
-       IV) If no mechlistMIC token was included but the MIC token
-           exchange is required, the negotiation SHALL be terminated.
-           GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
-
-   c) In the case that the chosen mechanism exchanges an odd number of
-      mechanism tokens (i.e., the initiator sends the last mechanism
-      token), the initiator does the following when generating the
-      negotiation message containing the last mechanism token: if the
-      negState was request-mic in the first reply from the target, a
-      mechlistMIC token MUST be included; otherwise, the mechlistMIC
-
-
-
-Zhu, et al.                 Standards Track                    [Page 11]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-      token is OPTIONAL.  (Note that the MIC token exchange is required
-      if a mechanism other than the initiator's first choice is chosen.)
-      In the case that the optimistic mechanism token is the only
-      mechanism token for the initiator's preferred mechanism, the
-      mechlistMIC token is OPTIONAL.  Whether the mechlistMIC token is
-      included, GSS_Init_sec_context() indicates GSS_S_CONTINUE_NEEDED.
-      Initiators that wish to be compatible with legacy Windows SPNEGO
-      implementations, as described in Appendix C, should not generate a
-      mechlistMIC token when the MIC token exchange is not required.
-      The acceptor then processes the last mechanism token and does one
-      of the following:
-
-        I) If a mechlistMIC token was included and is correctly
-           verified, GSS_Accept_sec_context() indicates GSS_S_COMPLETE.
-           The output negotiation message contains a mechlistMIC token
-           and an accept_complete state.  The initiator MUST then verify
-           this mechlistMIC token.
-
-       II) If a mechlistMIC token was included but is incorrect, the
-           negotiation SHALL be terminated.  GSS_Accept_sec_context()
-           indicates GSS_S_DEFECTIVE_TOKEN.
-
-      III) If no mechlistMIC token was included and the mechlistMIC
-           token exchange is not required, GSS_Accept_sec_context()
-           indicates GSS_S_COMPLETE.  The output negotiation message
-           contains an accept_complete state.
-
-       IV) In the case that the optimistic mechanism token is also the
-           last mechanism token (when the initiator's preferred
-           mechanism is accepted by the target) and the target sends a
-           request-mic state but the initiator did not send a
-           mechlistMIC token, the target then MUST include a mechlistMIC
-           token in that first reply.  GSS_Accept_sec_context()
-           indicates GSS_S_CONTINUE_NEEDED.  The initiator MUST verify
-           the received mechlistMIC token and generate a mechlistMIC
-           token to send back to the target.  The target SHALL, in turn,
-           verify the returned mechlistMIC token and complete the
-           negotiation.
-
-        V) If no mechlistMIC token was included and the acceptor sent a
-           request-mic state in the first reply message (the exchange of
-           MIC tokens is required), the negotiation SHALL be terminated.
-           GSS_Accept_sec_context() indicates GSS_S_DEFECTIVE_TOKEN.
-
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 12]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-6.  Extensibility
-
-   Two mechanisms are provided for extensibility.  First, the ASN.1
-   structures in this specification MAY be expanded by IETF standards
-   action.  Implementations receiving unknown fields MUST ignore these
-   fields.
-
-   Secondly, OIDs corresponding to a desired mechanism attribute (i.e.,
-   mechanism variants) may be included in the set of preferred
-   mechanisms by an initiator.  The acceptor can choose to honor this
-   request by preferring mechanisms that have the included attributes.
-   Future work within the Kitten working group is expected to
-   standardize common attributes that SPNEGO mechanisms may wish to
-   support.  At this time, it is sufficient to say that initiators MAY
-   include OIDs that do not correspond to mechanisms.  Such OIDs MAY
-   influence the acceptor's choice of mechanism.  As discussed in
-   Section 5, if there are mechanisms that, if present in the
-   initiator's list of mechanisms, might be preferred by the acceptor
-   instead of the initiator's preferred mechanism, the acceptor MUST
-   demand the MIC token exchange.  As the consequence, acceptors MUST
-   demand the MIC token exchange if they support negotiation of
-   attributes not available in the initiator's preferred mechanism,
-   regardless of whether the initiator actually requested these
-   attributes.
-
-7.  Security Considerations
-
-   In order to produce the MIC token for the mechanism list, the
-   mechanism must provide integrity protection.  When the selected
-   mechanism does not support integrity protection, the negotiation is
-   vulnerable: an active attacker can force it to use a security
-   mechanism that is not mutually preferred but is acceptable to the
-   target.
-
-   This protocol provides the following guarantees when per-message
-   integrity services are available on the established mechanism
-   context, and the mechanism list was altered by an adversary such that
-   a mechanism that is not mutually preferred could be selected:
-
-   a) If the last mechanism token is sent by the initiator, both peers
-      shall fail;
-
-   b) If the last mechanism token is sent by the acceptor, the acceptor
-      shall not complete and the initiator, at worst, shall complete
-      with its preferred mechanism being selected.
-
-   The negotiation may not be terminated if an alteration was made but
-   had no material impact.
-
-
-
-Zhu, et al.                 Standards Track                    [Page 13]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-   The protection of the negotiation depends on the strength of the
-   integrity protection.  In particular, the strength of SPNEGO is no
-   stronger than the integrity protection of the weakest mechanism
-   acceptable to GSS-API peers.
-
-   Note that where there exist multiple mechanisms with similar context
-   tokens, but different semantics, such that some or all of the
-   mechanisms' context tokens can be easily altered so that one
-   mechanism's context tokens may pass for another of the similar
-   mechanism's context tokens, then there may exist a downgrade or
-   similar attacks.  For example, if a given family of mechanisms uses
-   the same context token syntax for two or more variants and depends on
-   the OID in the initial token's pseudo-ASN.1/DER wrapper, but does not
-   provide integrity protection for that OID, then there may exist an
-   attack against those mechanisms.  SPNEGO does not generally defeat
-   such attacks.
-
-   In all cases, the communicating peers are exposed to the denial of
-   service threat.
-
-8.  Acknowledgments
-
-   The authors wish to thank Sam Hartman, Nicolas Williams, Ken Raeburn,
-   Martin Rex, Jeff Altman, Tom Yu, Cristian Ilac, Simon Spero, and Bill
-   Sommerfeld for their comments and suggestions during the development
-   of this document.
-
-   Luke Howard provided a prototype of this protocol in Heimdal and
-   resolved several issues in the initial version of this document.
-
-   Eric Baize and Denis Pinkas wrote the original SPNEGO specification
-   [RFC2478] of which some of the text has been retained in this
-   document.
-
-9.  References
-
-9.1.  Normative References
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743] Linn, J., "Generic Security Service Application Program
-             Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [X690]    ASN.1 encoding rules: Specification of Basic Encoding Rules
-             (BER), Canonical Encoding Rules (CER) and Distinguished
-             Encoding Rules (DER), ITU-T Recommendation X.690 (1997) |
-             ISO/IEC International Standard 8825-1:1998.
-
-
-
-Zhu, et al.                 Standards Track                    [Page 14]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-9.2.  Informative References
-
-   [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
-             Negotiation Mechanism", RFC 2478, December 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 15]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-Appendix A.  SPNEGO ASN.1 Module
-
-   SPNEGOASNOneSpec {
-      iso(1) identified-organization(3) dod(6) internet(1)
-      security(5) mechanism(5) snego (2) modules(4) spec2(2)
-   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-   MechType ::= OBJECT IDENTIFIER
-       -- OID represents each security mechanism as suggested by
-       -- [RFC2743]
-
-   MechTypeList ::= SEQUENCE OF MechType
-
-   NegotiationToken ::= CHOICE {
-       negTokenInit    [0] NegTokenInit,
-       negTokenResp    [1] NegTokenResp
-   }
-
-   NegTokenInit ::= SEQUENCE {
-       mechTypes       [0] MechTypeList,
-       reqFlags        [1] ContextFlags  OPTIONAL,
-         -- inherited from RFC 2478 for backward compatibility,
-         -- RECOMMENDED to be left out
-       mechToken       [2] OCTET STRING  OPTIONAL,
-       mechListMIC     [3] OCTET STRING  OPTIONAL,
-       ...
-   }
-   NegTokenResp ::= SEQUENCE {
-       negState       [0] ENUMERATED {
-           accept-completed    (0),
-           accept-incomplete   (1),
-           reject              (2),
-           request-mic         (3)
-       }                                 OPTIONAL,
-         -- REQUIRED in the first reply from the target
-       supportedMech   [1] MechType      OPTIONAL,
-         -- present only in the first reply from the target
-       responseToken   [2] OCTET STRING  OPTIONAL,
-       mechListMIC     [3] OCTET STRING  OPTIONAL,
-       ...
-   }
-
-   ContextFlags ::= BIT STRING {
-       delegFlag       (0),
-       mutualFlag      (1),
-       replayFlag      (2),
-       sequenceFlag    (3),
-       anonFlag        (4),
-
-
-
-Zhu, et al.                 Standards Track                    [Page 16]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-       confFlag        (5),
-       integFlag       (6)
-   } (SIZE (32))
-
-   END
-
-Appendix B.  GSS-API Negotiation Support API
-
-   In order to provide to a GSS-API caller (the initiator or the target
-   or both) with the ability to choose among the set of supported
-   mechanisms, a reduced set of mechanisms for negotiation and two
-   additional APIs are defined:
-
-   o  GSS_Get_neg_mechs() indicates the set of security mechanisms
-      available on the local system to the caller for negotiation, for
-      which appropriate credentials are available.
-
-   o  GSS_Set_neg_mechs() specifies the set of security mechanisms to be
-      used on the local system by the caller for negotiation, for the
-      given credentials.
-
-B.1.  GSS_Set_neg_mechs Call
-
-   Inputs:
-
-   o  cred_handle CREDENTIAL HANDLE, -- NULL specifies default
-       -- credentials
-   o  mech_set SET OF OBJECT IDENTIFIER
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the set of security mechanisms
-      available for negotiation has been set to mech_set.
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   This allows callers to specify the set of security mechanisms that
-   may be negotiated with the credential identified by cred_handle.
-   This call is intended to support specialized callers who need to
-   restrict the set of negotiable security mechanisms from the set of
-   all security mechanisms available to the caller (based on available
-
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 17]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-   credentials).  Note that if more than one mechanism is specified in
-   mech_set, the order in which those mechanisms are specified implies a
-   relative preference.
-
-B.2.  GSS_Get_neg_mechs Call
-
-   Input:
-
-   o  cred_handle CREDENTIAL HANDLE -- NULL specifies default --
-      credentials
-
-   Outputs:
-
-   o  major_status INTEGER,
-   o  minor_status INTEGER,
-   o  mech_set SET OF OBJECT IDENTIFIER
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the set of security mechanisms
-      available for negotiation has been returned in mech_set.
-
-   o  GSS_S_FAILURE indicates that the requested operation could not be
-      performed for reasons unspecified at the GSS-API level.
-
-   This allows callers to determine the set of security mechanisms
-   available for negotiation with the credential identified by
-   cred_handle.  This call is intended to support specialized callers
-   who need to reduce the set of negotiable security mechanisms from the
-   set of supported security mechanisms available to the caller (based
-   on available credentials).
-
-   Note: The GSS_Indicate_mechs() function indicates the full set of
-   mechanism types available on the local system.  Since this call has
-   no input parameter, the returned set is not necessarily available for
-   all credentials.
-
-Appendix C.  Changes since RFC 2478
-
-   SPNEGO implementations in Microsoft Windows 2000/Windows XP/Windows
-   Server 2003 have the following behavior: no mechlistMIC is produced
-   and mechlistMIC is not processed if one is provided; if the initiator
-   sends the last mechanism token, the acceptor will send back a
-   negotiation token with an accept_complete state and no mechlistMIC
-   token.  In addition, an incorrect OID (1.2.840.48018.1.2.2) can be
-   used to identify the GSS-API Kerberos Version 5 mechanism.
-
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 18]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-   The following changes have been made to be compatible with these
-   legacy implementations.
-
-   *  NegTokenTarg is changed to negTokenResp and is the message format
-      for all subsequent negotiation tokens.
-
-   *  NegTokenInit is the message for the initial negotiation message,
-      and only that message.
-
-   *  mechTypes in negTokenInit is not optional.
-
-   *  If the selected mechanism is also the most preferred mechanism for
-      both peers, it is safe to omit the MIC tokens.
-
-   If at least one of the two peers implements the updated pseudo
-   mechanism in this document, the negotiation is protected.
-
-   The following changes are to address problems in RFC 2478.
-
-   *  reqFlags is not protected, therefore it should not impact the
-      negotiation.
-
-   *  DER encoding is required.
-
-   *  GSS_GetMIC() input is clarified.
-
-   *  Per-message integrity services are requested for the negotiated
-      mechanism.
-
-   *  Two MIC tokens are exchanged, one in each direction.
-
-   An implementation that conforms to this specification will not
-   inter-operate with a strict RFC 2748 implementation.  Even if the new
-   implementation always sends a mechlistMIC token, it will still fail
-   to inter-operate.  If it is a server, it will fail because it
-   requests a mechlistMIC token using an option that older
-   implementations do not support.  Clients will tend to fail as well.
-
-   As an alternative to the approach chosen in this specification, we
-   could have documented a correct behavior that is fully backward
-   compatible with RFC 2478 and included an appendix on how to inter-
-   operate with existing incorrect implementations of RFC 2478.
-
-   As a practical matter, the SPNEGO implementers within the IETF have
-   valued interoperability with the Microsoft implementations.  We were
-   unable to choose to maintain reasonable security guarantees, to
-   maintain interoperability with the Microsoft implementations, and to
-   maintain interoperability with correct implementations of RFC 2478.
-
-
-
-Zhu, et al.                 Standards Track                    [Page 19]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-   The working group was not aware of any RFC 2478 implementations
-   deployed on the Internet.  Even if there are such implementations, it
-   is unlikely that they will inter-operate because of a critical flaw
-   in the description of the encoding of the mechanism list in RFC 2478.
-
-   With the approach taken in this specification, security is ensured
-   between new implementations all the time while maintaining
-   interoperability with the implementations deployed within the IETF
-   community.  The working group believes that this justifies breaking
-   compatibility with a correct implementation of RFC 2478.
-
-Appendix D.  mechListMIC Computation Example
-
-   The following is an example to illustrate how the mechListMIC field
-   would be computed.
-
-   The initial part of the DER encoding of NegTokenInit is constructed
-   as follows (the "nn" are length encodings, possibly longer than one
-   octet):
-
-      30 -- identifier octet for constructed SEQUENCE (NegTokenInit)
-      nn -- length
-
-         -- contents octets of the SEQUENCE begin with
-         -- DER encoding of "[0] MechTypeList":
-         A0 -- identifier octet for constructed [0]
-         nn -- length
-
-             -- contents of the constructed [0] are DER encoding
-             -- of MechTypeList (which is a SEQUENCE):
-             30 -- identifier octet for constructed SEQUENCE
-             nn -- length
-
-                -- contents octets of the SEQUENCE begin with
-                -- DER encoding of OBJECT IDENTIFIER:
-                06 -- identifier octet for primitive OBJECT IDENTIFIER
-                09 -- length
-                2A 86 48 86 F7 12 01 02 02 -- Kerberos V5
-                                           -- {1 2 840 113554 1 2 2}
-
-   If a mechlistMIC needs to be generated (according to the rules in
-   Section 5), it is computed by using the DER encoding of the type
-   MechTypeList data from the initiator's NegTokenInit token as input to
-   the GSS_GetMIC() function.  In this case, the MIC would be computed
-   over the following octets:
-
-      DER encoding of MechTypeList:
-      30 nn 06 09 2A 86 48 86 F7 12 01 02 02 ...
-
-
-
-Zhu, et al.                 Standards Track                    [Page 20]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-   Note that the identifier octet and length octet(s) for constructed
-   [0] (A0 nn) are not included in the MIC computation.
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: lzhu@microsoft.com
-
-
-   Paul Leach
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: paulle@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: karthikj@microsoft.com
-
-
-   Wyllys Ingersoll
-   Sun Microsystems
-   1775 Wiehle Avenue, 2nd Floor
-   Reston, VA  20190
-   US
-
-   EMail: wyllys.ingersoll@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 21]
-
-RFC 4178           The GSS-API Negotiation Mechanism        October 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                    [Page 22]
-
diff --git a/doc/standardisation/rfc4401.txt b/doc/standardisation/rfc4401.txt
deleted file mode 100644
index 339b58aa6..000000000
--- a/doc/standardisation/rfc4401.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        N. Williams
-Request for Comments: 4401                              Sun Microsystems
-Category: Standards Track                                  February 2006
-
-
-         A Pseudo-Random Function (PRF) API Extension for the
-    Generic Security Service Application Program Interface (GSS-API)
-
-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 (2006).
-
-Abstract
-
-   This document defines a Pseudo-Random Function (PRF) extension to the
-   Generic Security Service Application Program Interface (GSS-API) for
-   keying application protocols given an established GSS-API security
-   context.  The primary intended use of this function is to key secure
-   session layers that do not or cannot use GSS-API per-message message
-   integrity check (MIC) and wrap tokens for session protection.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-      1.1. Conventions Used in This Document ..........................2
-   2. GSS_Pseudo_random() .............................................2
-      2.1. C-Bindings .................................................5
-   3. IANA Considerations .............................................5
-   4. Security Considerations .........................................5
-   5. References ......................................................7
-      5.1. Normative References .......................................7
-      5.2. Informative References .....................................7
-
-
-
-
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 1]
-
-RFC 4401            A PRF Extension for the GSS-API        February 2006
-
-
-1.  Introduction
-
-   A need has arisen for users of the GSS-API to key applications'
-   cryptographic protocols using established GSS-API security contexts.
-   Such applications can use the GSS-API [RFC2743] for authentication,
-   but not for transport security (for whatever reasons), and since the
-   GSS-API does not provide a method for obtaining keying material from
-   established security contexts, such applications cannot make
-   effective use of the GSS-API.
-
-   To address this need, we define a pseudo-random function (PRF)
-   extension to the GSS-API.
-
-   Though this document specifies an abstract API as an extension to the
-   GSS-API version 2, update 1, and though it specifies the bindings of
-   this extension for the C programming language, it does not specify a
-   revision of the GSS-API and so does not address the matter of how
-   portable applications detect support for and ensure access to this
-   extension.  We defer this matter to an expected, comprehensive update
-   to the GSS-API.
-
-1.1.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  GSS_Pseudo_random()
-
-   Inputs:
-
-   o  context CONTEXT handle,
-
-   o  prf_key INTEGER,
-
-   o  prf_in OCTET STRING,
-
-   o  desired_output_len INTEGER
-
-
-   Outputs:
-
-   o  major_status INTEGER,
-
-   o  minor_status INTEGER,
-
-   o  prf_out OCTET STRING
-
-
-
-
-Williams                    Standards Track                     [Page 2]
-
-RFC 4401            A PRF Extension for the GSS-API        February 2006
-
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates no error.
-
-   o  GSS_S_NO_CONTEXT indicates that a null context has been provided
-      as input.
-
-   o  GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
-      provided as input.
-
-   o  GSS_S_UNAVAILABLE indicates that the mechanism lacks support for
-      this function or, if the security context is not fully
-      established, that the context is not ready to compute the PRF with
-      the given prf_key, or that the given prf_key is not available.
-
-   o  GSS_S_FAILURE indicates general failure, possibly due to the given
-      input data being too large or of zero length, or due to the
-      desired_output_len being zero; the minor status code may provide
-      additional information.
-
-   This function applies the established context's mechanism's keyed
-   pseudo-random function (PRF) to the input data ('prf_in'), keyed with
-   key material associated with the given security context and
-   identified by 'prf_key', and outputs the resulting octet string
-   ('prf_out') of desired_output_len length.
-
-   The minimum input data length is one octet.
-
-   Mechanisms MUST be able to consume all the provided prf_in input data
-   that is 2^14 or fewer octets.
-
-   If a mechanism cannot consume as much input data as provided by the
-   caller, then GSS_Pseudo_random() MUST return GSS_S_FAILURE.
-
-   The minimum desired_output_len is one.
-
-   Mechanisms MUST be able to output at least up to 2^14 octets.
-
-   If the implementation cannot produce the desired output due to lack
-   of resources, then it MUST return GSS_S_FAILURE and MUST set a
-   suitable minor status code.
-
-   The prf_key can take on the following values: GSS_C_PRF_KEY_FULL,
-   GSS_C_PRF_KEY_PARTIAL, or mechanism-specific values, if any.  This
-   parameter is intended to distinguish between the best cryptographic
-   keys that may be available only after full security context
-   establishment and keys that may be available prior to full security
-   context establishment.  For some mechanisms, or contexts, those two
-
-
-
-Williams                    Standards Track                     [Page 3]
-
-RFC 4401            A PRF Extension for the GSS-API        February 2006
-
-
-   prf_key values MAY refer to the same cryptographic keys; for
-   mechanisms like the Kerberos V GSS-API mechanism [RFC1964] where one
-   peer may assert a key that may be considered better than the others
-   they MAY be different keys.
-
-   GSS_C_PRF_KEY_PARTIAL corresponds to a key that would have been used
-   while the security context was partially established, even if it is
-   fully established when GSS_Pseudo_random() is actually called.
-   Mechanism-specific prf_key values are intended to refer to any other
-   keys that may be available.
-
-   The GSS_C_PRF_KEY_FULL value corresponds to the best key available
-   for fully-established security contexts.
-
-   GSS_Pseudo_random() has the following properties:
-
-   o  its output string MUST be a pseudo-random function [GGM1] [GGM2]
-      of the input keyed with key material from the given security
-      context -- the chances of getting the same output given different
-      input parameters should be exponentially small.
-
-   o  when successfully applied to the same inputs by an initiator and
-      acceptor using the same security context, it MUST produce the
-      _same results_ for both, the initiator and acceptor, even if
-      called multiple times (as long as the security context is not
-      expired).
-
-   o  upon full establishment of a security context, all cryptographic
-      keys and/or negotiations used for computing the PRF with any
-      prf_key MUST be authenticated (mutually, if mutual authentication
-      is in effect for the given security context).
-
-   o  the outputs of the mechanism's GSS_Pseudo_random() (for different
-      inputs) and its per-message tokens for the given security context
-      MUST be "cryptographically separate"; in other words, it must not
-      be feasible to recover key material for one mechanism operation or
-      transform its tokens and PRF outputs from one to the other given
-      only said tokens and PRF outputs.  (This is a fancy way of saying
-      that key derivation and strong cryptographic operations and
-      constructions must be used.)
-
-   o  as implied by the above requirement, it MUST NOT be possible to
-      access any raw keys of a security context through
-      GSS_Pseudo_random(), no matter what inputs are given.
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 4]
-
-RFC 4401            A PRF Extension for the GSS-API        February 2006
-
-
-2.1.  C-Bindings
-
-   #define GSS_C_PRF_KEY_FULL 0
-   #define GSS_C_PRF_KEY_PARTIAL 1
-
-   OM_uint32 gss_pseudo_random(
-     OM_uint32                     *minor_status,
-     gss_ctx_id_t                  context,
-     int                           prf_key,
-     const gss_buffer_t            prf_in,
-     ssize_t                       desired_output_len,
-     gss_buffer_t                  prf_out
-   );
-
-   Additional major status codes for the C-bindings:
-
-   o  GSS_S_CALL_INACCESSIBLE_READ
-
-   o  GSS_S_CALL_INACCESSIBLE_WRITE
-
-   See [RFC2744].
-
-3.  IANA Considerations
-
-   This document has no IANA considerations currently.  If and when a
-   relevant IANA registry of GSS-API symbols is created, then the
-   generic and language-specific function names, constant names, and
-   constant values described above should be added to such a registry.
-
-4.  Security Considerations
-
-   Care should be taken in properly designing a mechanism's PRF
-   function.
-
-   GSS mechanisms' PRF functions should use a key derived from contexts'
-   authenticated session keys and should preserve the forward security
-   properties of the mechanisms' key exchanges.
-
-   Some mechanisms may support the GSS PRF function with security
-   contexts that are not fully established, but applications MUST assume
-   that authentication, mutual or otherwise, has not completed until the
-   security context is fully established.
-
-   Callers of GSS_Pseudo_random() should avoid accidentally calling it
-   with the same inputs.  One useful technique is to prepend to the
-   prf_in input string, by convention, a string indicating the intended
-   purpose of the PRF output in such a way that unique contexts in which
-   the function is called yield unique inputs to it.
-
-
-
-Williams                    Standards Track                     [Page 5]
-
-RFC 4401            A PRF Extension for the GSS-API        February 2006
-
-
-   Pseudo-random functions are, by their nature, capable of producing
-   only limited amounts of cryptographically secure output.  The exact
-   amount of output that one can safely use, unfortunately, varies from
-   one PRF to another (which prevents us from recommending specific
-   numbers).  Because of this, we recommend that unless you really know
-   what you are doing (i.e., you are a cryptographer and are qualified
-   to pass judgement on cryptographic functions in areas of period,
-   presence of short cycles, etc.), you limit the amount of the PRF
-   output used to the necessary minimum.  See [RFC4086] for more
-   information about "Randomness Requirements for Security".
-
-   For some mechanisms, the computational cost of computing
-   GSS_Pseudo_random() may increase significantly as the length of the
-   prf_in data and/or the desired_output_length increase.  This means
-   that if an application can be tricked into providing very large input
-   octet strings and requesting very long output octet strings, then
-   that may constitute a denial of service attack on the application;
-   therefore, applications SHOULD place appropriate limits on the size
-   of any input octet strings received from their peers without
-   integrity protection.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 6]
-
-RFC 4401            A PRF Extension for the GSS-API        February 2006
-
-
-5.  References
-
-5.1.  Normative References
-
-   [GGM1]     Goldreich, O., Goldwasser, S., and S. Micali, "How to
-              Construct Random Functions", Journal of the ACM, October
-              1986.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-5.2.  Informative References
-
-   [GGM2]     Goldreich, O., Goldwasser, S., and S. Micali, "On the
-              Cryptographic Applications of Random Functions",
-              Proceedings of CRYPTO 84 on Advances in cryptology, 1985.
-
-   [RFC4086]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-              "Randomness Requirements for Security", BCP 106, RFC 4086,
-              June 2005.
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
-              1964, June 1996.
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 7]
-
-RFC 4401            A PRF Extension for the GSS-API        February 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 8]
-
diff --git a/doc/standardisation/rfc4402.txt b/doc/standardisation/rfc4402.txt
deleted file mode 100644
index c6f1d871c..000000000
--- a/doc/standardisation/rfc4402.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        N. Williams
-Request for Comments: 4402                                           Sun
-Category: Standards Track                                  February 2006
-
-
-   A Pseudo-Random Function (PRF) for the Kerberos V Generic Security
-       Service Application Program Interface (GSS-API) Mechanism
-
-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 (2006).
-
-Abstract
-
-   This document defines the Pseudo-Random Function (PRF) for the
-   Kerberos V mechanism for the Generic Security Service Application
-   Program Interface (GSS-API), based on the PRF defined for the
-   Kerberos V cryptographic framework, for keying application protocols
-   given an established Kerberos V GSS-API security context.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-      1.1. Conventions Used in This Document ..........................2
-   2. Kerberos V GSS Mechanism PRF ....................................2
-   3. IANA Considerations .............................................3
-   4. Security Considerations .........................................3
-   5. Normative References ............................................4
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 1]
-
-RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
-
-
-1.  Introduction
-
-   This document specifies the Kerberos V GSS-API mechanism's [RFC4121]
-   pseudo-random function corresponding to [RFC4401].  The function is a
-   "PRF+" style construction.  For more information see [RFC4401],
-   [RFC2743], [RFC2744], and [RFC4121].
-
-1.1.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-2.  Kerberos V GSS Mechanism PRF
-
-   The GSS-API PRF [RFC4401] function for the Kerberos V mechanism
-   [RFC4121] shall be the output of a PRF+ function based on the
-   encryption type's PRF function keyed with the negotiated session key
-   of the security context corresponding to the 'prf_key' input
-   parameter of GSS_Pseudo_random().
-
-   This PRF+ MUST be keyed with the key indicated by the 'prf_key' input
-   parameter as follows:
-
-   o  GSS_C_PRF_KEY_FULL -- use the sub-session key asserted by the
-      acceptor, if any, or the sub-session asserted by the initiator, if
-      any, or the Ticket's session key
-
-   o  GSS_C_PRF_KEY_PARTIAL -- use the sub-session key asserted by the
-      initiator, if any, or the Ticket's session key
-
-   The PRF+ function is a simple counter-based extension of the Kerberos
-   V pseudo-random function [RFC3961] for the encryption type of the
-   security context's keys:
-
-         PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
-
-         Tn = pseudo-random(K, n || S)
-
-   where '||' is the concatenation operator, 'n' is encoded as a network
-   byte order 32-bit unsigned binary number, truncate(L, S) truncates
-   the input octet string S to length L, and pseudo-random() is the
-   Kerberos V pseudo-random function [RFC3961].
-
-   The maximum output size of the Kerberos V mechanism's GSS-API PRF
-   then is, necessarily, 2^32 times the output size of the pseudo-
-   random() function for the encryption type of the given key.
-
-
-
-
-Williams                    Standards Track                     [Page 2]
-
-RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
-
-
-   When the input size is longer than 2^14 octets as per [RFC4401] and
-   exceeds an implementation's resources, then the mechanism MUST return
-   GSS_S_FAILURE and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status
-   code.
-
-3.  IANA Considerations
-
-   This document has no IANA considerations currently.  If and when a
-   relevant IANA registry of GSS-API symbols and constants is created,
-   then the GSS_KRB5_S_KG_INPUT_TOO_LONG minor status code should be
-   added to such a registry.
-
-4.  Security Considerations
-
-   Kerberos V encryption types' PRF functions use a key derived from
-   contexts' session keys and should preserve the forward security
-   properties of the mechanisms' key exchanges.
-
-   Legacy Kerberos V encryption types may be weak, particularly the
-   single-DES encryption types.
-
-   See also [RFC4401] for generic security considerations of
-   GSS_Pseudo_random().
-
-   See also [RFC3961] for generic security considerations of the
-   Kerberos V cryptographic framework.
-
-   Use of Ticket session keys, rather than sub-session keys, when
-   initiators and acceptors fail to assert sub-session keys, is
-   dangerous as ticket reuse can lead to key reuse; therefore,
-   initiators should assert sub-session keys always, and acceptors
-   should assert sub-session keys at least when initiators fail to do
-   so.
-
-   The computational cost of computing this PRF+ may vary depending on
-   the Kerberos V encryption types being used, but generally the
-   computation of this PRF+ gets more expensive as the input and output
-   octet string lengths grow (note that the use of a counter in the PRF+
-   construction allows for parallelization).  This means that if an
-   application can be tricked into providing very large input octet
-   strings and requesting very long output octet strings, then that may
-   constitute a denial of service attack on the application; therefore,
-   applications SHOULD place appropriate limits on the size of any input
-   octet strings received from their peers without integrity protection.
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 3]
-
-RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
-
-
-5.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
-              Extension for the Generic Security Service Application
-              Program Interface (GSS-API)", RFC 4401, February 2006.
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 4]
-
-RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 5]
-
diff --git a/doc/standardisation/rfc4506.txt b/doc/standardisation/rfc4506.txt
deleted file mode 100644
index 9bd6a8905..000000000
--- a/doc/standardisation/rfc4506.txt
+++ /dev/null
@@ -1,1515 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     M. Eisler, Ed.
-Request for Comments: 4506                       Network Appliance, Inc.
-STD: 67                                                         May 2006
-Obsoletes: 1832
-Category: Standards Track
-
-
-               XDR: External Data Representation Standard
-
-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 (2006).
-
-Abstract
-
-   This document describes the External Data Representation Standard
-   (XDR) protocol as it is currently deployed and accepted.  This
-   document obsoletes RFC 1832.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eisler                      Standards Track                     [Page 1]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-   2. Changes from RFC 1832 ...........................................3
-   3. Basic Block Size ................................................3
-   4. XDR Data Types ..................................................4
-      4.1. Integer ....................................................4
-      4.2. Unsigned Integer ...........................................4
-      4.3. Enumeration ................................................5
-      4.4. Boolean ....................................................5
-      4.5. Hyper Integer and Unsigned Hyper Integer ...................5
-      4.6. Floating-Point .............................................6
-      4.7. Double-Precision Floating-Point ............................7
-      4.8. Quadruple-Precision Floating-Point .........................8
-      4.9. Fixed-Length Opaque Data ...................................9
-      4.10. Variable-Length Opaque Data ...............................9
-      4.11. String ...................................................10
-      4.12. Fixed-Length Array .......................................11
-      4.13. Variable-Length Array ....................................11
-      4.14. Structure ................................................12
-      4.15. Discriminated Union ......................................12
-      4.16. Void .....................................................13
-      4.17. Constant .................................................13
-      4.18. Typedef ..................................................13
-      4.19. Optional-Data ............................................14
-      4.20. Areas for Future Enhancement .............................16
-   5. Discussion .....................................................16
-   6. The XDR Language Specification .................................17
-      6.1. Notational Conventions ....................................17
-      6.2. Lexical Notes .............................................18
-      6.3. Syntax Information ........................................18
-      6.4. Syntax Notes ..............................................20
-   7. An Example of an XDR Data Description ..........................21
-   8. Security Considerations ........................................22
-   9. IANA Considerations ............................................23
-   10. Trademarks and Owners .........................................23
-   11. ANSI/IEEE Standard 754-1985 ...................................24
-   12. Normative References ..........................................25
-   13. Informative References ........................................25
-   14. Acknowledgements ..............................................26
-
-
-
-
-
-
-
-
-
-
-
-Eisler                      Standards Track                     [Page 2]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-1.  Introduction
-
-   XDR is a standard for the description and encoding of data.  It is
-   useful for transferring data between different computer
-   architectures, and it has been used to communicate data between such
-   diverse machines as the SUN WORKSTATION*, VAX*, IBM-PC*, and Cray*.
-   XDR fits into the ISO presentation layer and is roughly analogous in
-   purpose to X.409, ISO Abstract Syntax Notation.  The major difference
-   between these two is that XDR uses implicit typing, while X.409 uses
-   explicit typing.
-
-   XDR uses a language to describe data formats.  The language can be
-   used only to describe data; it is not a programming language.  This
-   language allows one to describe intricate data formats in a concise
-   manner.  The alternative of using graphical representations (itself
-   an informal language) quickly becomes incomprehensible when faced
-   with complexity.  The XDR language itself is similar to the C
-   language [KERN], just as Courier [COUR] is similar to Mesa.
-   Protocols such as ONC RPC (Remote Procedure Call) and the NFS*
-   (Network File System) use XDR to describe the format of their data.
-
-   The XDR standard makes the following assumption: that bytes (or
-   octets) are portable, where a byte is defined as 8 bits of data.  A
-   given hardware device should encode the bytes onto the various media
-   in such a way that other hardware devices may decode the bytes
-   without loss of meaning.  For example, the Ethernet* standard
-   suggests that bytes be encoded in "little-endian" style [COHE], or
-   least significant bit first.
-
-2.  Changes from RFC 1832
-
-   This document makes no technical changes to RFC 1832 and is published
-   for the purposes of noting IANA considerations, augmenting security
-   considerations, and distinguishing normative from informative
-   references.
-
-3.  Basic Block Size
-
-   The representation of all items requires a multiple of four bytes (or
-   32 bits) of data.  The bytes are numbered 0 through n-1.  The bytes
-   are read or written to some byte stream such that byte m always
-   precedes byte m+1.  If the n bytes needed to contain the data are not
-   a multiple of four, then the n bytes are followed by enough (0 to 3)
-   residual zero bytes, r, to make the total byte count a multiple of 4.
-
-   We include the familiar graphic box notation for illustration and
-   comparison.  In most illustrations, each box (delimited by a plus
-   sign at the 4 corners and vertical bars and dashes) depicts a byte.
-
-
-
-Eisler                      Standards Track                     [Page 3]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-   Ellipses (...) between boxes show zero or more additional bytes where
-   required.
-
-        +--------+--------+...+--------+--------+...+--------+
-        | byte 0 | byte 1 |...|byte n-1|    0   |...|    0   |   BLOCK
-        +--------+--------+...+--------+--------+...+--------+
-        |<-----------n bytes---------->|<------r bytes------>|
-        |<-----------n+r (where (n+r) mod 4 = 0)>----------->|
-
-4.   XDR Data Types
-
-   Each of the sections that follow describes a data type defined in the
-   XDR standard, shows how it is declared in the language, and includes
-   a graphic illustration of its encoding.
-
-   For each data type in the language we show a general paradigm
-   declaration.  Note that angle brackets (< and >) denote variable-
-   length sequences of data and that square brackets ([ and ]) denote
-   fixed-length sequences of data.  "n", "m", and "r" denote integers.
-   For the full language specification and more formal definitions of
-   terms such as "identifier" and "declaration", refer to Section 6,
-   "The XDR Language Specification".
-
-   For some data types, more specific examples are included.  A more
-   extensive example of a data description is in Section 7, "An Example
-   of an XDR Data Description".
-
-4.1.  Integer
-
-   An XDR signed integer is a 32-bit datum that encodes an integer in
-   the range [-2147483648,2147483647].  The integer is represented in
-   two's complement notation.  The most and least significant bytes are
-   0 and 3, respectively.  Integers are declared as follows:
-
-         int identifier;
-
-           (MSB)                   (LSB)
-         +-------+-------+-------+-------+
-         |byte 0 |byte 1 |byte 2 |byte 3 |                      INTEGER
-         +-------+-------+-------+-------+
-         <------------32 bits------------>
-
-4.2.  Unsigned Integer
-
-   An XDR unsigned integer is a 32-bit datum that encodes a non-negative
-   integer in the range [0,4294967295].  It is represented by an
-   unsigned binary number whose most and least significant bytes are 0
-   and 3, respectively.  An unsigned integer is declared as follows:
-
-
-
-Eisler                      Standards Track                     [Page 4]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-         unsigned int identifier;
-
-           (MSB)                   (LSB)
-            +-------+-------+-------+-------+
-            |byte 0 |byte 1 |byte 2 |byte 3 |           UNSIGNED INTEGER
-            +-------+-------+-------+-------+
-            <------------32 bits------------>
-
-4.3.  Enumeration
-
-   Enumerations have the same representation as signed integers.
-   Enumerations are handy for describing subsets of the integers.
-   Enumerated data is declared as follows:
-
-         enum { name-identifier = constant, ... } identifier;
-
-   For example, the three colors red, yellow, and blue could be
-   described by an enumerated type:
-
-         enum { RED = 2, YELLOW = 3, BLUE = 5 } colors;
-
-   It is an error to encode as an enum any integer other than those that
-   have been given assignments in the enum declaration.
-
-4.4.  Boolean
-
-   Booleans are important enough and occur frequently enough to warrant
-   their own explicit type in the standard.  Booleans are declared as
-   follows:
-
-         bool identifier;
-
-   This is equivalent to:
-
-         enum { FALSE = 0, TRUE = 1 } identifier;
-
-4.5.  Hyper Integer and Unsigned Hyper Integer
-
-   The standard also defines 64-bit (8-byte) numbers called hyper
-   integers and unsigned hyper integers.  Their representations are the
-   obvious extensions of integer and unsigned integer defined above.
-   They are represented in two's complement notation.  The most and
-   least significant bytes are 0 and 7, respectively.  Their
-   declarations:
-
-   hyper identifier; unsigned hyper identifier;
-
-
-
-
-
-Eisler                      Standards Track                     [Page 5]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-        (MSB)                                                   (LSB)
-      +-------+-------+-------+-------+-------+-------+-------+-------+
-      |byte 0 |byte 1 |byte 2 |byte 3 |byte 4 |byte 5 |byte 6 |byte 7 |
-      +-------+-------+-------+-------+-------+-------+-------+-------+
-      <----------------------------64 bits---------------------------->
-                                                 HYPER INTEGER
-                                                 UNSIGNED HYPER INTEGER
-
-4.6.  Floating-Point
-
-   The standard defines the floating-point data type "float" (32 bits or
-   4 bytes).  The encoding used is the IEEE standard for normalized
-   single-precision floating-point numbers [IEEE].  The following three
-   fields describe the single-precision floating-point number:
-
-      S: The sign of the number.  Values 0 and 1 represent positive and
-         negative, respectively.  One bit.
-
-      E: The exponent of the number, base 2.  8 bits are devoted to this
-         field.  The exponent is biased by 127.
-
-      F: The fractional part of the number's mantissa, base 2.  23 bits
-         are devoted to this field.
-
-   Therefore, the floating-point number is described by:
-
-         (-1)**S * 2**(E-Bias) * 1.F
-
-   It is declared as follows:
-
-         float identifier;
-
-         +-------+-------+-------+-------+
-         |byte 0 |byte 1 |byte 2 |byte 3 |              SINGLE-PRECISION
-         S|   E   |           F          |         FLOATING-POINT NUMBER
-         +-------+-------+-------+-------+
-         1|<- 8 ->|<-------23 bits------>|
-         <------------32 bits------------>
-
-   Just as the most and least significant bytes of a number are 0 and 3,
-   the most and least significant bits of a single-precision floating-
-   point number are 0 and 31.  The beginning bit (and most significant
-   bit) offsets of S, E, and F are 0, 1, and 9, respectively.  Note that
-   these numbers refer to the mathematical positions of the bits, and
-   NOT to their actual physical locations (which vary from medium to
-   medium).
-
-
-
-
-
-Eisler                      Standards Track                     [Page 6]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-   The IEEE specifications should be consulted concerning the encoding
-   for signed zero, signed infinity (overflow), and denormalized numbers
-   (underflow) [IEEE].  According to IEEE specifications, the "NaN" (not
-   a number) is system dependent and should not be interpreted within
-   XDR as anything other than "NaN".
-
-4.7.  Double-Precision Floating-Point
-
-   The standard defines the encoding for the double-precision floating-
-   point data type "double" (64 bits or 8 bytes).  The encoding used is
-   the IEEE standard for normalized double-precision floating-point
-   numbers [IEEE].  The standard encodes the following three fields,
-   which describe the double-precision floating-point number:
-
-      S: The sign of the number.  Values 0 and 1 represent positive and
-            negative, respectively.  One bit.
-
-      E: The exponent of the number, base 2.  11 bits are devoted to
-            this field.  The exponent is biased by 1023.
-
-      F: The fractional part of the number's mantissa, base 2.  52 bits
-            are devoted to this field.
-
-   Therefore, the floating-point number is described by:
-
-         (-1)**S * 2**(E-Bias) * 1.F
-
-   It is declared as follows:
-
-         double identifier;
-
-         +------+------+------+------+------+------+------+------+
-         |byte 0|byte 1|byte 2|byte 3|byte 4|byte 5|byte 6|byte 7|
-         S|    E   |                    F                        |
-         +------+------+------+------+------+------+------+------+
-         1|<--11-->|<-----------------52 bits------------------->|
-         <-----------------------64 bits------------------------->
-                                        DOUBLE-PRECISION FLOATING-POINT
-
-   Just as the most and least significant bytes of a number are 0 and 3,
-   the most and least significant bits of a double-precision floating-
-   point number are 0 and 63.  The beginning bit (and most significant
-   bit) offsets of S, E, and F are 0, 1, and 12, respectively.  Note
-   that these numbers refer to the mathematical positions of the bits,
-   and NOT to their actual physical locations (which vary from medium to
-   medium).
-
-
-
-
-
-Eisler                      Standards Track                     [Page 7]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-   The IEEE specifications should be consulted concerning the encoding
-   for signed zero, signed infinity (overflow), and denormalized numbers
-   (underflow) [IEEE].  According to IEEE specifications, the "NaN" (not
-   a number) is system dependent and should not be interpreted within
-   XDR as anything other than "NaN".
-
-4.8.  Quadruple-Precision Floating-Point
-
-   The standard defines the encoding for the quadruple-precision
-   floating-point data type "quadruple" (128 bits or 16 bytes).  The
-   encoding used is designed to be a simple analog of the encoding used
-   for single- and double-precision floating-point numbers using one
-   form of IEEE double extended precision.  The standard encodes the
-   following three fields, which describe the quadruple-precision
-   floating-point number:
-
-      S: The sign of the number.  Values 0 and 1 represent positive and
-         negative, respectively.  One bit.
-
-      E: The exponent of the number, base 2.  15 bits are devoted to
-         this field.  The exponent is biased by 16383.
-
-      F: The fractional part of the number's mantissa, base 2.  112 bits
-         are devoted to this field.
-
-   Therefore, the floating-point number is described by:
-
-         (-1)**S * 2**(E-Bias) * 1.F
-
-   It is declared as follows:
-
-         quadruple identifier;
-
-         +------+------+------+------+------+------+-...--+------+
-         |byte 0|byte 1|byte 2|byte 3|byte 4|byte 5| ...  |byte15|
-         S|    E       |                  F                      |
-         +------+------+------+------+------+------+-...--+------+
-         1|<----15---->|<-------------112 bits------------------>|
-         <-----------------------128 bits------------------------>
-                                      QUADRUPLE-PRECISION FLOATING-POINT
-
-   Just as the most and least significant bytes of a number are 0 and 3,
-   the most and least significant bits of a quadruple-precision
-   floating-point number are 0 and 127.  The beginning bit (and most
-   significant bit) offsets of S, E , and F are 0, 1, and 16,
-   respectively.  Note that these numbers refer to the mathematical
-   positions of the bits, and NOT to their actual physical locations
-   (which vary from medium to medium).
-
-
-
-Eisler                      Standards Track                     [Page 8]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-   The encoding for signed zero, signed infinity (overflow), and
-   denormalized numbers are analogs of the corresponding encodings for
-   single and double-precision floating-point numbers [SPAR], [HPRE].
-   The "NaN" encoding as it applies to quadruple-precision floating-
-   point numbers is system dependent and should not be interpreted
-   within XDR as anything other than "NaN".
-
-4.9.  Fixed-Length Opaque Data
-
-   At times, fixed-length uninterpreted data needs to be passed among
-   machines.  This data is called "opaque" and is declared as follows:
-
-         opaque identifier[n];
-
-   where the constant n is the (static) number of bytes necessary to
-   contain the opaque data.  If n is not a multiple of four, then the n
-   bytes are followed by enough (0 to 3) residual zero bytes, r, to make
-   the total byte count of the opaque object a multiple of four.
-
-          0        1     ...
-      +--------+--------+...+--------+--------+...+--------+
-      | byte 0 | byte 1 |...|byte n-1|    0   |...|    0   |
-      +--------+--------+...+--------+--------+...+--------+
-      |<-----------n bytes---------->|<------r bytes------>|
-      |<-----------n+r (where (n+r) mod 4 = 0)------------>|
-                                                   FIXED-LENGTH OPAQUE
-
-4.10.  Variable-Length Opaque Data
-
-   The standard also provides for variable-length (counted) opaque data,
-   defined as a sequence of n (numbered 0 through n-1) arbitrary bytes
-   to be the number n encoded as an unsigned integer (as described
-   below), and followed by the n bytes of the sequence.
-
-   Byte m of the sequence always precedes byte m+1 of the sequence, and
-   byte 0 of the sequence always follows the sequence's length (count).
-   If n is not a multiple of four, then the n bytes are followed by
-   enough (0 to 3) residual zero bytes, r, to make the total byte count
-   a multiple of four.  Variable-length opaque data is declared in the
-   following way:
-
-         opaque identifier<m>;
-      or
-         opaque identifier<>;
-
-   The constant m denotes an upper bound of the number of bytes that the
-   sequence may contain.  If m is not specified, as in the second
-   declaration, it is assumed to be (2**32) - 1, the maximum length.
-
-
-
-Eisler                      Standards Track                     [Page 9]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-   The constant m would normally be found in a protocol specification.
-   For example, a filing protocol may state that the maximum data
-   transfer size is 8192 bytes, as follows:
-
-         opaque filedata<8192>;
-
-            0     1     2     3     4     5   ...
-         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
-         |        length n       |byte0|byte1|...| n-1 |  0  |...|  0  |
-         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
-         |<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
-                                 |<----n+r (where (n+r) mod 4 = 0)---->|
-                                                  VARIABLE-LENGTH OPAQUE
-
-   It is an error to encode a length greater than the maximum described
-   in the specification.
-
-4.11.  String
-
-   The standard defines a string of n (numbered 0 through n-1) ASCII
-   bytes to be the number n encoded as an unsigned integer (as described
-   above), and followed by the n bytes of the string.  Byte m of the
-   string always precedes byte m+1 of the string, and byte 0 of the
-   string always follows the string's length.  If n is not a multiple of
-   four, then the n bytes are followed by enough (0 to 3) residual zero
-   bytes, r, to make the total byte count a multiple of four.  Counted
-   byte strings are declared as follows:
-
-         string object<m>;
-      or
-         string object<>;
-
-   The constant m denotes an upper bound of the number of bytes that a
-   string may contain.  If m is not specified, as in the second
-   declaration, it is assumed to be (2**32) - 1, the maximum length.
-   The constant m would normally be found in a protocol specification.
-   For example, a filing protocol may state that a file name can be no
-   longer than 255 bytes, as follows:
-
-         string filename<255>;
-
-            0     1     2     3     4     5   ...
-         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
-         |        length n       |byte0|byte1|...| n-1 |  0  |...|  0  |
-         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
-         |<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
-                                 |<----n+r (where (n+r) mod 4 = 0)---->|
-                                                                  STRING
-
-
-
-Eisler                      Standards Track                    [Page 10]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-   It is an error to encode a length greater than the maximum described
-   in the specification.
-
-4.12.  Fixed-Length Array
-
-   Declarations for fixed-length arrays of homogeneous elements are in
-   the following form:
-
-         type-name identifier[n];
-
-   Fixed-length arrays of elements numbered 0 through n-1 are encoded by
-   individually encoding the elements of the array in their natural
-   order, 0 through n-1.  Each element's size is a multiple of four
-   bytes.  Though all elements are of the same type, the elements may
-   have different sizes.  For example, in a fixed-length array of
-   strings, all elements are of type "string", yet each element will
-   vary in its length.
-
-         +---+---+---+---+---+---+---+---+...+---+---+---+---+
-         |   element 0   |   element 1   |...|  element n-1  |
-         +---+---+---+---+---+---+---+---+...+---+---+---+---+
-         |<--------------------n elements------------------->|
-
-                                               FIXED-LENGTH ARRAY
-
-4.13.  Variable-Length Array
-
-   Counted arrays provide the ability to encode variable-length arrays
-   of homogeneous elements.  The array is encoded as the element count n
-   (an unsigned integer) followed by the encoding of each of the array's
-   elements, starting with element 0 and progressing through element
-   n-1.  The declaration for variable-length arrays follows this form:
-
-         type-name identifier<m>;
-      or
-         type-name identifier<>;
-
-   The constant m specifies the maximum acceptable element count of an
-   array; if m is not specified, as in the second declaration, it is
-   assumed to be (2**32) - 1.
-
-           0  1  2  3
-         +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
-         |     n     | element 0 | element 1 |...|element n-1|
-         +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
-         |<-4 bytes->|<--------------n elements------------->|
-                                                         COUNTED ARRAY
-
-
-
-
-Eisler                      Standards Track                    [Page 11]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-   It is an error to encode a value of n that is greater than the
-   maximum described in the specification.
-
-4.14.  Structure
-
-   Structures are declared as follows:
-
-         struct {
-            component-declaration-A;
-            component-declaration-B;
-            ...
-         } identifier;
-
-   The components of the structure are encoded in the order of their
-   declaration in the structure.  Each component's size is a multiple of
-   four bytes, though the components may be different sizes.
-
-         +-------------+-------------+...
-         | component A | component B |...                      STRUCTURE
-         +-------------+-------------+...
-
-4.15.  Discriminated Union
-
-   A discriminated union is a type composed of a discriminant followed
-   by a type selected from a set of prearranged types according to the
-   value of the discriminant.  The type of discriminant is either "int",
-   "unsigned int", or an enumerated type, such as "bool".  The component
-   types are called "arms" of the union and are preceded by the value of
-   the discriminant that implies their encoding.  Discriminated unions
-   are declared as follows:
-
-         union switch (discriminant-declaration) {
-         case discriminant-value-A:
-            arm-declaration-A;
-         case discriminant-value-B:
-            arm-declaration-B;
-         ...
-         default: default-declaration;
-         } identifier;
-
-   Each "case" keyword is followed by a legal value of the discriminant.
-   The default arm is optional.  If it is not specified, then a valid
-   encoding of the union cannot take on unspecified discriminant values.
-   The size of the implied arm is always a multiple of four bytes.
-
-   The discriminated union is encoded as its discriminant followed by
-   the encoding of the implied arm.
-
-
-
-
-Eisler                      Standards Track                    [Page 12]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-           0   1   2   3
-         +---+---+---+---+---+---+---+---+
-         |  discriminant |  implied arm  |          DISCRIMINATED UNION
-         +---+---+---+---+---+---+---+---+
-         |<---4 bytes--->|
-
-4.16.  Void
-
-   An XDR void is a 0-byte quantity.  Voids are useful for describing
-   operations that take no data as input or no data as output.  They are
-   also useful in unions, where some arms may contain data and others do
-   not.  The declaration is simply as follows:
-
-         void;
-
-   Voids are illustrated as follows:
-
-           ++
-           ||                                                     VOID
-           ++
-         --><-- 0 bytes
-
-4.17.  Constant
-
-   The data declaration for a constant follows this form:
-
-         const name-identifier = n;
-
-   "const" is used to define a symbolic name for a constant; it does not
-   declare any data.  The symbolic constant may be used anywhere a
-   regular constant may be used.  For example, the following defines a
-   symbolic constant DOZEN, equal to 12.
-
-         const DOZEN = 12;
-
-4.18.  Typedef
-
-   "typedef" does not declare any data either, but serves to define new
-   identifiers for declaring data.  The syntax is:
-
-         typedef declaration;
-
-   The new type name is actually the variable name in the declaration
-   part of the typedef.  For example, the following defines a new type
-   called "eggbox" using an existing type called "egg":
-
-         typedef egg eggbox[DOZEN];
-
-
-
-
-Eisler                      Standards Track                    [Page 13]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-   Variables declared using the new type name have the same type as the
-   new type name would have in the typedef, if it were considered a
-   variable.  For example, the following two declarations are equivalent
-   in declaring the variable "fresheggs":
-
-         eggbox  fresheggs; egg     fresheggs[DOZEN];
-
-   When a typedef involves a struct, enum, or union definition, there is
-   another (preferred) syntax that may be used to define the same type.
-   In general, a typedef of the following form:
-
-         typedef <<struct, union, or enum definition>> identifier;
-
-   may be converted to the alternative form by removing the "typedef"
-   part and placing the identifier after the "struct", "union", or
-   "enum" keyword, instead of at the end.  For example, here are the two
-   ways to define the type "bool":
-
-         typedef enum {    /* using typedef */
-            FALSE = 0,
-            TRUE = 1
-         } bool;
-
-         enum bool {       /* preferred alternative */
-            FALSE = 0,
-            TRUE = 1
-         };
-
-   This syntax is preferred because one does not have to wait until the
-   end of a declaration to figure out the name of the new type.
-
-4.19.  Optional-Data
-
-   Optional-data is one kind of union that occurs so frequently that we
-   give it a special syntax of its own for declaring it.  It is declared
-   as follows:
-
-         type-name *identifier;
-
-   This is equivalent to the following union:
-
-         union switch (bool opted) {
-         case TRUE:
-            type-name element;
-         case FALSE:
-            void;
-         } identifier;
-
-
-
-
-Eisler                      Standards Track                    [Page 14]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-   It is also equivalent to the following variable-length array
-   declaration, since the boolean "opted" can be interpreted as the
-   length of the array:
-
-         type-name identifier<1>;
-
-   Optional-data is not so interesting in itself, but it is very useful
-   for describing recursive data-structures such as linked-lists and
-   trees.  For example, the following defines a type "stringlist" that
-   encodes lists of zero or more arbitrary length strings:
-
-        struct stringentry {
-           string item<>;
-           stringentry *next;
-        };
-
-        typedef stringentry *stringlist;
-
-   It could have been equivalently declared as the following union:
-
-         union stringlist switch (bool opted) {
-         case TRUE:
-            struct {
-               string item<>;
-               stringlist next;
-            } element;
-         case FALSE:
-            void;
-         };
-
-   or as a variable-length array:
-
-        struct stringentry {
-           string item<>;
-           stringentry next<1>;
-        };
-
-        typedef stringentry stringlist<1>;
-
-   Both of these declarations obscure the intention of the stringlist
-   type, so the optional-data declaration is preferred over both of
-   them.  The optional-data type also has a close correlation to how
-   recursive data structures are represented in high-level languages
-   such as Pascal or C by use of pointers.  In fact, the syntax is the
-   same as that of the C language for pointers.
-
-
-
-
-
-
-Eisler                      Standards Track                    [Page 15]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-4.20.  Areas for Future Enhancement
-
-   The XDR standard lacks representations for bit fields and bitmaps,
-   since the standard is based on bytes.  Also missing are packed (or
-   binary-coded) decimals.
-
-   The intent of the XDR standard was not to describe every kind of data
-   that people have ever sent or will ever want to send from machine to
-   machine.  Rather, it only describes the most commonly used data-types
-   of high-level languages such as Pascal or C so that applications
-   written in these languages will be able to communicate easily over
-   some medium.
-
-   One could imagine extensions to XDR that would let it describe almost
-   any existing protocol, such as TCP.  The minimum necessary for this
-   is support for different block sizes and byte-orders.  The XDR
-   discussed here could then be considered the 4-byte big-endian member
-   of a larger XDR family.
-
-5.  Discussion
-
-   (1) Why use a language for describing data?  What's wrong with
-       diagrams?
-
-   There are many advantages in using a data-description language such
-   as XDR versus using diagrams.  Languages are more formal than
-   diagrams and lead to less ambiguous descriptions of data.  Languages
-   are also easier to understand and allow one to think of other issues
-   instead of the low-level details of bit encoding.  Also, there is a
-   close analogy between the types of XDR and a high-level language such
-   as C or Pascal.  This makes the implementation of XDR encoding and
-   decoding modules an easier task.  Finally, the language specification
-   itself is an ASCII string that can be passed from machine to machine
-   to perform on-the-fly data interpretation.
-
-   (2) Why is there only one byte-order for an XDR unit?
-
-   Supporting two byte-orderings requires a higher-level protocol for
-   determining in which byte-order the data is encoded.  Since XDR is
-   not a protocol, this can't be done.  The advantage of this, though,
-   is that data in XDR format can be written to a magnetic tape, for
-   example, and any machine will be able to interpret it, since no
-   higher-level protocol is necessary for determining the byte-order.
-
-   (3) Why is the XDR byte-order big-endian instead of little-endian?
-       Isn't this unfair to little-endian machines such as the VAX(r),
-       which has to convert from one form to the other?
-
-
-
-
-Eisler                      Standards Track                    [Page 16]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-   Yes, it is unfair, but having only one byte-order means you have to
-   be unfair to somebody.  Many architectures, such as the Motorola
-   68000* and IBM 370*, support the big-endian byte-order.
-
-   (4) Why is the XDR unit four bytes wide?
-
-   There is a tradeoff in choosing the XDR unit size.  Choosing a small
-   size, such as two, makes the encoded data small, but causes alignment
-   problems for machines that aren't aligned on these boundaries.  A
-   large size, such as eight, means the data will be aligned on
-   virtually every machine, but causes the encoded data to grow too big.
-   We chose four as a compromise.  Four is big enough to support most
-   architectures efficiently, except for rare machines such as the
-   eight-byte-aligned Cray*.  Four is also small enough to keep the
-   encoded data restricted to a reasonable size.
-
-   (5) Why must variable-length data be padded with zeros?
-
-   It is desirable that the same data encode into the same thing on all
-   machines, so that encoded data can be meaningfully compared or
-   checksummed.  Forcing the padded bytes to be zero ensures this.
-
-   (6) Why is there no explicit data-typing?
-
-   Data-typing has a relatively high cost for what small advantages it
-   may have.  One cost is the expansion of data due to the inserted type
-   fields.  Another is the added cost of interpreting these type fields
-   and acting accordingly.  And most protocols already know what type
-   they expect, so data-typing supplies only redundant information.
-   However, one can still get the benefits of data-typing using XDR.
-   One way is to encode two things: first, a string that is the XDR data
-   description of the encoded data, and then the encoded data itself.
-   Another way is to assign a value to all the types in XDR, and then
-   define a universal type that takes this value as its discriminant and
-   for each value, describes the corresponding data type.
-
-6.  The XDR Language Specification
-
-6.1.  Notational Conventions
-
-   This specification uses an extended Back-Naur Form notation for
-   describing the XDR language.  Here is a brief description of the
-   notation:
-
-   (1) The characters '|', '(', ')', '[', ']', '"', and '*' are special.
-   (2) Terminal symbols are strings of any characters surrounded by
-   double quotes.  (3) Non-terminal symbols are strings of non-special
-   characters.  (4) Alternative items are separated by a vertical bar
-
-
-
-Eisler                      Standards Track                    [Page 17]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-   ("|").  (5) Optional items are enclosed in brackets.  (6) Items are
-   grouped together by enclosing them in parentheses.  (7) A '*'
-   following an item means 0 or more occurrences of that item.
-
-   For example, consider the following pattern:
-
-         "a " "very" (", " "very")* [" cold " "and "]  " rainy "
-         ("day" | "night")
-
-   An infinite number of strings match this pattern.  A few of them are:
-
-         "a very rainy day"
-         "a very, very rainy day"
-         "a very cold and  rainy day"
-         "a very, very, very cold and  rainy night"
-
-6.2.  Lexical Notes
-
-   (1) Comments begin with '/*' and terminate with '*/'.  (2) White
-   space serves to separate items and is otherwise ignored.  (3) An
-   identifier is a letter followed by an optional sequence of letters,
-   digits, or underbar ('_').  The case of identifiers is not ignored.
-   (4) A decimal constant expresses a number in base 10 and is a
-   sequence of one or more decimal digits, where the first digit is not
-   a zero, and is optionally preceded by a minus-sign ('-').  (5) A
-   hexadecimal constant expresses a number in base 16, and must be
-   preceded by '0x', followed by one or hexadecimal digits ('A', 'B',
-   'C', 'D', E', 'F', 'a', 'b', 'c', 'd', 'e', 'f', '0', '1', '2', '3',
-   '4', '5', '6', '7', '8', '9').  (6) An octal constant expresses a
-   number in base 8, always leads with digit 0, and is a sequence of one
-   or more octal digits ('0', '1', '2', '3', '4', '5', '6', '7').
-
-6.3.  Syntax Information
-
-      declaration:
-           type-specifier identifier
-         | type-specifier identifier "[" value "]"
-         | type-specifier identifier "<" [ value ] ">"
-         | "opaque" identifier "[" value "]"
-         | "opaque" identifier "<" [ value ] ">"
-         | "string" identifier "<" [ value ] ">"
-         | type-specifier "*" identifier
-         | "void"
-
-      value:
-           constant
-         | identifier
-
-
-
-
-Eisler                      Standards Track                    [Page 18]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-      constant:
-         decimal-constant | hexadecimal-constant | octal-constant
-
-      type-specifier:
-           [ "unsigned" ] "int"
-         | [ "unsigned" ] "hyper"
-         | "float"
-         | "double"
-         | "quadruple"
-         | "bool"
-         | enum-type-spec
-         | struct-type-spec
-         | union-type-spec
-         | identifier
-
-      enum-type-spec:
-         "enum" enum-body
-
-      enum-body:
-         "{"
-            ( identifier "=" value )
-            ( "," identifier "=" value )*
-         "}"
-
-      struct-type-spec:
-         "struct" struct-body
-
-      struct-body:
-         "{"
-            ( declaration ";" )
-            ( declaration ";" )*
-         "}"
-
-      union-type-spec:
-         "union" union-body
-
-      union-body:
-         "switch" "(" declaration ")" "{"
-            case-spec
-            case-spec *
-            [ "default" ":" declaration ";" ]
-         "}"
-
-      case-spec:
-        ( "case" value ":")
-        ( "case" value ":") *
-        declaration ";"
-
-
-
-
-Eisler                      Standards Track                    [Page 19]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-      constant-def:
-         "const" identifier "=" constant ";"
-
-      type-def:
-           "typedef" declaration ";"
-         | "enum" identifier enum-body ";"
-         | "struct" identifier struct-body ";"
-         | "union" identifier union-body ";"
-
-      definition:
-           type-def
-         | constant-def
-
-      specification:
-           definition *
-
-6.4.  Syntax Notes
-
-   (1) The following are keywords and cannot be used as identifiers:
-   "bool", "case", "const", "default", "double", "quadruple", "enum",
-   "float", "hyper", "int", "opaque", "string", "struct", "switch",
-   "typedef", "union", "unsigned", and "void".
-
-   (2) Only unsigned constants may be used as size specifications for
-   arrays.  If an identifier is used, it must have been declared
-   previously as an unsigned constant in a "const" definition.
-
-   (3) Constant and type identifiers within the scope of a specification
-   are in the same name space and must be declared uniquely within this
-   scope.
-
-   (4) Similarly, variable names must be unique within the scope of
-   struct and union declarations.  Nested struct and union declarations
-   create new scopes.
-
-   (5) The discriminant of a union must be of a type that evaluates to
-   an integer.  That is, "int", "unsigned int", "bool", an enumerated
-   type, or any typedefed type that evaluates to one of these is legal.
-   Also, the case values must be one of the legal values of the
-   discriminant.  Finally, a case value may not be specified more than
-   once within the scope of a union declaration.
-
-
-
-
-
-
-
-
-
-
-Eisler                      Standards Track                    [Page 20]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-7.  An Example of an XDR Data Description
-
-   Here is a short XDR data description of a thing called a "file",
-   which might be used to transfer files from one machine to another.
-
-         const MAXUSERNAME = 32;     /* max length of a user name */
-         const MAXFILELEN = 65535;   /* max length of a file      */
-         const MAXNAMELEN = 255;     /* max length of a file name */
-
-         /*
-          * Types of files:
-          */
-         enum filekind {
-            TEXT = 0,       /* ascii data */
-            DATA = 1,       /* raw data   */
-            EXEC = 2        /* executable */
-         };
-
-         /*
-          * File information, per kind of file:
-          */
-         union filetype switch (filekind kind) {
-         case TEXT:
-            void;                           /* no extra information */
-         case DATA:
-            string creator<MAXNAMELEN>;     /* data creator         */
-         case EXEC:
-            string interpretor<MAXNAMELEN>; /* program interpretor  */
-         };
-
-         /*
-          * A complete file:
-          */
-         struct file {
-            string filename<MAXNAMELEN>; /* name of file    */
-            filetype type;               /* info about file */
-            string owner<MAXUSERNAME>;   /* owner of file   */
-            opaque data<MAXFILELEN>;     /* file data       */
-         };
-
-   Suppose now that there is a user named "john" who wants to store his
-   lisp program "sillyprog" that contains just the data "(quit)".  His
-   file would be encoded as follows:
-
-
-
-
-
-
-
-
-Eisler                      Standards Track                    [Page 21]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-       OFFSET  HEX BYTES       ASCII    COMMENTS
-       ------  ---------       -----    --------
-        0      00 00 00 09     ....     -- length of filename = 9
-        4      73 69 6c 6c     sill     -- filename characters
-        8      79 70 72 6f     ypro     -- ... and more characters ...
-       12      67 00 00 00     g...     -- ... and 3 zero-bytes of fill
-       16      00 00 00 02     ....     -- filekind is EXEC = 2
-       20      00 00 00 04     ....     -- length of interpretor = 4
-       24      6c 69 73 70     lisp     -- interpretor characters
-       28      00 00 00 04     ....     -- length of owner = 4
-       32      6a 6f 68 6e     john     -- owner characters
-       36      00 00 00 06     ....     -- length of file data = 6
-       40      28 71 75 69     (qui     -- file data bytes ...
-       44      74 29 00 00     t)..     -- ... and 2 zero-bytes of fill
-
-8.  Security Considerations
-
-   XDR is a data description language, not a protocol, and hence it does
-   not inherently give rise to any particular security considerations.
-   Protocols that carry XDR-formatted data, such as NFSv4, are
-   responsible for providing any necessary security services to secure
-   the data they transport.
-
-   Care must be take to properly encode and decode data to avoid
-   attacks.  Known and avoidable risks include:
-
-   *    Buffer overflow attacks.  Where feasible, protocols should be
-        defined with explicit limits (via the "<" [ value ] ">" notation
-        instead of "<" ">") on elements with variable-length data types.
-        Regardless of the feasibility of an explicit limit on the
-        variable length of an element of a given protocol, decoders need
-        to ensure the incoming size does not exceed the length of any
-        provisioned receiver buffers.
-
-   *    Nul octets embedded in an encoded value of type string.  If the
-        decoder's native string format uses nul-terminated strings, then
-        the apparent size of the decoded object will be less than the
-        amount of memory allocated for the string.  Some memory
-        deallocation interfaces take a size argument.  The caller of the
-        deallocation interface would likely determine the size of the
-        string by counting to the location of the nul octet and adding
-        one.  This discrepancy can cause memory leakage (because less
-        memory is actually returned to the free pool than allocated),
-        leading to system failure and a denial of service attack.
-
-   *    Decoding of characters in strings that are legal ASCII
-        characters but nonetheless are illegal for the intended
-        application.  For example, some operating systems treat the '/'
-
-
-
-Eisler                      Standards Track                    [Page 22]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-        character as a component separator in path names.  For a
-        protocol that encodes a string in the argument to a file
-        creation operation, the decoder needs to ensure that '/' is not
-        inside the component name.  Otherwise, a file with an illegal
-        '/' in its name will be created, making it difficult to remove,
-        and is therefore a denial of service attack.
-
-   *    Denial of service caused by recursive decoder or encoder
-        subroutines.  A recursive decoder or encoder might process data
-        that has a structured type with a member of type optional data
-        that directly or indirectly refers to the structured type (i.e.,
-        a linked list).  For example,
-
-              struct m {
-                int x;
-                struct m *next;
-              };
-
-        An encoder or decoder subroutine might be written to recursively
-        call itself each time another element of type "struct m" is
-        found.  An attacker could construct a long linked list of
-        "struct m" elements in the request or response, which then
-        causes a stack overflow on the decoder or encoder.  Decoders and
-        encoders should be written non-recursively or impose a limit on
-        list length.
-
-9.  IANA Considerations
-
-   It is possible, if not likely, that new data types will be added to
-   XDR in the future.  The process for adding new types is via a
-   standards track RFC and not registration of new types with IANA.
-   Standards track RFCs that update or replace this document should be
-   documented as such in the RFC Editor's database of RFCs.
-
-10.  Trademarks and Owners
-
-   SUN WORKSTATION  Sun Microsystems, Inc.
-   VAX              Hewlett-Packard Company
-   IBM-PC           International Business Machines Corporation
-   Cray             Cray Inc.
-   NFS              Sun Microsystems, Inc.
-   Ethernet         Xerox Corporation.
-   Motorola 68000   Motorola, Inc.
-   IBM 370          International Business Machines Corporation
-
-
-
-
-
-
-
-Eisler                      Standards Track                    [Page 23]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-11.  ANSI/IEEE Standard 754-1985
-
-   The definition of NaNs, signed zero and infinity, and denormalized
-   numbers from [IEEE] is reproduced here for convenience.  The
-   definitions for quadruple-precision floating point numbers are
-   analogs of those for single and double-precision floating point
-   numbers and are defined in [IEEE].
-
-   In the following, 'S' stands for the sign bit, 'E' for the exponent,
-   and 'F' for the fractional part.  The symbol 'u' stands for an
-   undefined bit (0 or 1).
-
-   For single-precision floating point numbers:
-
-    Type                  S (1 bit)   E (8 bits)    F (23 bits)
-    ----                  ---------   ----------    -----------
-    signalling NaN        u           255 (max)     .0uuuuu---u
-                                                    (with at least
-                                                     one 1 bit)
-    quiet NaN             u           255 (max)     .1uuuuu---u
-
-    negative infinity     1           255 (max)     .000000---0
-
-    positive infinity     0           255 (max)     .000000---0
-
-    negative zero         1           0             .000000---0
-
-    positive zero         0           0             .000000---0
-
-   For double-precision floating point numbers:
-
-    Type                  S (1 bit)   E (11 bits)   F (52 bits)
-    ----                  ---------   -----------   -----------
-    signalling NaN        u           2047 (max)    .0uuuuu---u
-                                                    (with at least
-                                                     one 1 bit)
-    quiet NaN             u           2047 (max)    .1uuuuu---u
-
-    negative infinity     1           2047 (max)    .000000---0
-
-    positive infinity     0           2047 (max)    .000000---0
-
-    negative zero         1           0             .000000---0
-
-    positive zero         0           0             .000000---0
-
-
-
-
-
-
-Eisler                      Standards Track                    [Page 24]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-   For quadruple-precision floating point numbers:
-
-    Type                  S (1 bit)   E (15 bits)   F (112 bits)
-    ----                  ---------   -----------   ------------
-    signalling NaN        u           32767 (max)   .0uuuuu---u
-                                                    (with at least
-                                                     one 1 bit)
-    quiet NaN             u           32767 (max)   .1uuuuu---u
-
-    negative infinity     1           32767 (max)   .000000---0
-
-    positive infinity     0           32767 (max)   .000000---0
-
-    negative zero         1           0             .000000---0
-
-    positive zero         0           0             .000000---0
-
-   Subnormal numbers are represented as follows:
-
-    Precision            Exponent       Value
-    ---------            --------       -----
-    Single               0              (-1)**S * 2**(-126) * 0.F
-
-    Double               0              (-1)**S * 2**(-1022) * 0.F
-
-    Quadruple            0              (-1)**S * 2**(-16382) * 0.F
-
-12.  Normative References
-
-   [IEEE]  "IEEE Standard for Binary Floating-Point Arithmetic",
-           ANSI/IEEE Standard 754-1985, Institute of Electrical and
-           Electronics Engineers, August 1985.
-
-13.  Informative References
-
-   [KERN]  Brian W. Kernighan & Dennis M. Ritchie, "The C Programming
-           Language", Bell Laboratories, Murray Hill, New Jersey, 1978.
-
-   [COHE]  Danny Cohen, "On Holy Wars and a Plea for Peace", IEEE
-           Computer, October 1981.
-
-   [COUR]  "Courier: The Remote Procedure Call Protocol", XEROX
-           Corporation, XSIS 038112, December 1981.
-
-   [SPAR]  "The SPARC Architecture Manual: Version 8", Prentice Hall,
-           ISBN 0-13-825001-4.
-
-   [HPRE]  "HP Precision Architecture Handbook", June 1987, 5954-9906.
-
-
-
-Eisler                      Standards Track                    [Page 25]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-14.  Acknowledgements
-
-   Bob Lyon was Sun's visible force behind ONC RPC in the 1980s.  Sun
-   Microsystems, Inc., is listed as the author of RFC 1014.  Raj
-   Srinivasan and the rest of the old ONC RPC working group edited RFC
-   1014 into RFC 1832, from which this document is derived.  Mike Eisler
-   and Bill Janssen submitted the implementation reports for this
-   standard.  Kevin Coffman, Benny Halevy, and Jon Peterson reviewed
-   this document and gave feedback.  Peter Astrand and Bryan Olson
-   pointed out several errors in RFC 1832 which are corrected in this
-   document.
-
-Editor's Address
-
-   Mike Eisler
-   5765 Chase Point Circle
-   Colorado Springs, CO 80919
-   USA
-
-   Phone: 719-599-9026
-   EMail: email2mre-rfc4506@yahoo.com
-
-   Please address comments to: nfsv4@ietf.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eisler                      Standards Track                    [Page 26]
-
-RFC 4506       XDR: External Data Representation Standard       May 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Eisler                      Standards Track                    [Page 27]
-
diff --git a/doc/standardisation/rfc4556.txt b/doc/standardisation/rfc4556.txt
deleted file mode 100644
index 2ff943928..000000000
--- a/doc/standardisation/rfc4556.txt
+++ /dev/null
@@ -1,2355 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             L. Zhu
-Request for Comments: 4556                         Microsoft Corporation
-Category: Standards Track                                        B. Tung
-                                                   Aerospace Corporation
-                                                               June 2006
-
-
-                      Public Key Cryptography for
-              Initial Authentication in Kerberos (PKINIT)
-
-
-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 (2006).
-
-Abstract
-
-   This document describes protocol extensions (hereafter called PKINIT)
-   to the Kerberos protocol specification.  These extensions provide a
-   method for integrating public key cryptography into the initial
-   authentication exchange, by using asymmetric-key signature and/or
-   encryption algorithms in pre-authentication data fields.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Conventions Used in This Document ...............................4
-   3. Extensions ......................................................5
-      3.1. Definitions, Requirements, and Constants ...................6
-           3.1.1. Required Algorithms .................................6
-           3.1.2. Recommended Algorithms ..............................6
-           3.1.3. Defined Message and Encryption Types ................7
-           3.1.4. Kerberos Encryption Types Defined for CMS
-                  Algorithm Identifiers ...............................8
-      3.2. PKINIT Pre-authentication Syntax and Use ...................9
-           3.2.1. Generation of Client Request ........................9
-           3.2.2. Receipt of Client Request ..........................14
-           3.2.3. Generation of KDC Reply ............................18
-                  3.2.3.1. Using Diffie-Hellman Key Exchange .........21
-                  3.2.3.2. Using Public Key Encryption ...............23
-
-
-
-Zhu & Tung                  Standards Track                     [Page 1]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-           3.2.4. Receipt of KDC Reply ...............................25
-      3.3. Interoperability Requirements .............................26
-      3.4. KDC Indication of PKINIT Support ..........................27
-   4. Security Considerations ........................................27
-   5. Acknowledgements ...............................................30
-   6. References .....................................................30
-      6.1. Normative References ......................................30
-      6.2. Informative References ....................................32
-   Appendix A.  PKINIT ASN.1 Module ..................................33
-   Appendix B.  Test Vectors .........................................38
-   Appendix C.  Miscellaneous Information about Microsoft Windows
-                PKINIT Implementations ...............................40
-
-1.  Introduction
-
-   The Kerberos V5 protocol [RFC4120] involves use of a trusted third
-   party known as the Key Distribution Center (KDC) to negotiate shared
-   session keys between clients and services and provide mutual
-   authentication between them.
-
-   The corner-stones of Kerberos V5 are the Ticket and the
-   Authenticator.  A Ticket encapsulates a symmetric key (the ticket
-   session key) in an envelope (a public message) intended for a
-   specific service.  The contents of the Ticket are encrypted with a
-   symmetric key shared between the service principal and the issuing
-   KDC.  The encrypted part of the Ticket contains the client principal
-   name, among other items.  An Authenticator is a record that can be
-   shown to have been recently generated using the ticket session key in
-   the associated Ticket.  The ticket session key is known by the client
-   who requested the ticket.  The contents of the Authenticator are
-   encrypted with the associated ticket session key.  The encrypted part
-   of an Authenticator contains a timestamp and the client principal
-   name, among other items.
-
-   As shown in Figure 1, below, the Kerberos V5 protocol consists of the
-   following message exchanges between the client and the KDC, and the
-   client and the application service:
-
-    - The Authentication Service (AS) Exchange
-
-      The client obtains an "initial" ticket from the Kerberos
-      authentication server (AS), typically a Ticket Granting Ticket
-      (TGT).  The AS-REQ message and the AS-REP message are the request
-      and the reply message, respectively, between the client and the
-      AS.
-
-
-
-
-
-
-Zhu & Tung                  Standards Track                     [Page 2]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-    - The Ticket Granting Service (TGS) Exchange
-
-      The client subsequently uses the TGT to authenticate and request a
-      service ticket for a particular service, from the Kerberos
-      ticket-granting server (TGS).  The TGS-REQ message and the TGS-REP
-      message are the request and the reply message respectively between
-      the client and the TGS.
-
-    - The Client/Server Authentication Protocol (AP) Exchange
-
-      The client then makes a request with an AP-REQ message, consisting
-      of a service ticket and an authenticator that certifies the
-      client's possession of the ticket session key.  The server may
-      optionally reply with an AP-REP message.  AP exchanges typically
-      negotiate session-specific symmetric keys.
-
-   Usually, the AS and TGS are integrated in a single device also known
-   as the KDC.
-
-                          +--------------+
-               +--------->|  KDC         |
-       AS-REQ /   +-------|              |
-             /   /        +--------------+
-            /   /          ^           |
-           /    |AS-REP   /            |
-          |     |        / TGS-REQ     + TGS-REP
-          |     |       /             /
-          |     |      /             /
-          |     |     /   +---------+
-          |     |    /   /
-          |     |   /   /
-          |     |  /   /
-          |     v /   v
-         ++-------+------+             +-----------------+
-         |  Client       +------------>|  Application    |
-         |               |    AP-REQ   |  Server         |
-         |               |<------------|                 |
-         +---------------+    AP-REP   +-----------------+
-
-       Figure 1:  The Message Exchanges in the Kerberos V5 Protocol
-
-   In the AS exchange, the KDC reply contains the ticket session key,
-   among other items, that is encrypted using a key (the AS reply key)
-   shared between the client and the KDC.  The AS reply key is typically
-   derived from the client's password for human users.  Therefore, for
-   human users, the attack resistance strength of the Kerberos protocol
-   is no stronger than the strength of their passwords.
-
-
-
-
-Zhu & Tung                  Standards Track                     [Page 3]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   The use of asymmetric cryptography in the form of X.509 certificates
-   [RFC3280] is popular for facilitating data origin authentication and
-   perfect secrecy.  An established Public Key Infrastructure (PKI)
-   provides key management and key distribution mechanisms that can be
-   used to establish authentication and secure communication.  Adding
-   public-key cryptography to Kerberos provides a nice congruence to
-   public-key protocols, obviates the human users' burden to manage
-   strong passwords, and allows Kerberized applications to take
-   advantage of existing key services and identity management.
-
-   The advantage afforded by the Kerberos TGT is that the client exposes
-   his long-term secrets only once.  The TGT and its associated session
-   key can then be used for any subsequent service ticket requests.  One
-   result of this is that all further authentication is independent of
-   the method by which the initial authentication was performed.
-   Consequently, initial authentication provides a convenient place to
-   integrate public-key cryptography into Kerberos authentication.  In
-   addition, the use of symmetric cryptography after the initial
-   exchange is preferred for performance.
-
-   This document describes the methods and data formats using which the
-   client and the KDC can use public and private key pairs to mutually
-   authenticate in the AS exchange and negotiate the AS reply key, known
-   only by the client and the KDC, to encrypt the AS-REP sent by the
-   KDC.
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-   In this protocol, both the client and the KDC have a public-private
-   key pair in order to prove their identities to each other over the
-   open network.  The term "signature key" is used to refer to the
-   private key of the key pair being used.
-
-   The encryption key used to encrypt the enc-part field of the KDC-REP
-   in the AS-REP [RFC4120] is referred to as the AS reply key.
-
-   An empty sequence in an optional field can be either included or
-   omitted: both encodings are permitted and considered equivalent.
-
-   The term "Modular Exponential Diffie-Hellman" is used to refer to the
-   Diffie-Hellman key exchange, as described in [RFC2631], in order to
-   differentiate it from other equivalent representations of the same
-   key agreement algorithm.
-
-
-
-
-Zhu & Tung                  Standards Track                     [Page 4]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-3.  Extensions
-
-   This section describes extensions to [RFC4120] for supporting the use
-   of public-key cryptography in the initial request for a ticket.
-
-   Briefly, this document defines the following extensions to [RFC4120]:
-
-   1. The client indicates the use of public-key authentication by
-      including a special preauthenticator in the initial request.  This
-      preauthenticator contains the client's public-key data and a
-      signature.
-
-   2. The KDC tests the client's request against its authentication
-      policy and trusted Certification Authorities (CAs).
-
-   3. If the request passes the verification tests, the KDC replies as
-      usual, but the reply is encrypted using either:
-
-      a. a key generated through a Diffie-Hellman (DH) key exchange
-         [RFC2631] [IEEE1363] with the client, signed using the KDC's
-         signature key; or
-
-      b. a symmetric encryption key, signed using the KDC's signature
-         key and encrypted using the client's public key.
-
-      Any keying material required by the client to obtain the
-      encryption key for decrypting the KDC reply is returned in a pre-
-      authentication field accompanying the usual reply.
-
-   4. The client validates the KDC's signature, obtains the encryption
-      key, decrypts the reply, and then proceeds as usual.
-
-   Section 3.1 of this document enumerates the required algorithms and
-   necessary extension message types.  Section 3.2 describes the
-   extension messages in greater detail.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                  Standards Track                     [Page 5]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-3.1.  Definitions, Requirements, and Constants
-
-3.1.1.  Required Algorithms
-
-   All PKINIT implementations MUST support the following algorithms:
-
-   o  AS reply key enctypes: aes128-cts-hmac-sha1-96 and aes256-cts-
-      hmac-sha1-96 [RFC3962].
-
-   o  Signature algorithm: sha-1WithRSAEncryption [RFC3370].
-
-   o  AS reply key delivery method: the Diffie-Hellman key delivery
-      method, as described in Section 3.2.3.1.
-
-   In addition, implementations of this specification MUST be capable of
-   processing the Extended Key Usage (EKU) extension and the id-pkinit-
-   san (as defined in Section 3.2.2) otherName of the Subject
-   Alternative Name (SAN) extension in X.509 certificates [RFC3280].
-
-3.1.2.  Recommended Algorithms
-
-   All PKINIT implementations SHOULD support the following algorithm:
-
-   o  AS reply key delivery method: the public key encryption key
-      delivery method, as described in Section 3.2.3.2.
-
-   For implementations that support the public key encryption key
-   delivery method, the following algorithms MUST be supported:
-
-   a) Key transport algorithms identified in the keyEncryptionAlgorithm
-      field of the type KeyTransRecipientInfo [RFC3852] for encrypting
-      the temporary key in the encryptedKey field [RFC3852] with a
-      public key, as described in Section 3.2.3.2: rsaEncryption (this
-      is the RSAES-PKCS1-v1_5 encryption scheme) [RFC3370] [RFC3447].
-
-   b) Content encryption algorithms identified in the
-      contentEncryptionAlgorithm field of the type EncryptedContentInfo
-      [RFC3852] for encrypting the AS reply key with the temporary key
-      contained in the encryptedKey field of the type
-      KeyTransRecipientInfo [RFC3852], as described in Section 3.2.3.2:
-      des-ede3-cbc (three-key 3DES, CBC mode) [RFC3370].
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                  Standards Track                     [Page 6]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-3.1.3.  Defined Message and Encryption Types
-
-   PKINIT makes use of the following new pre-authentication types:
-
-       PA_PK_AS_REQ                                 16
-       PA_PK_AS_REP                                 17
-
-   PKINIT also makes use of the following new authorization data type:
-
-       AD_INITIAL_VERIFIED_CAS                       9
-
-   PKINIT introduces the following new error codes:
-
-       KDC_ERR_CLIENT_NOT_TRUSTED                   62
-       KDC_ERR_INVALID_SIG                          64
-       KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED       65
-       KDC_ERR_CANT_VERIFY_CERTIFICATE              70
-       KDC_ERR_INVALID_CERTIFICATE                  71
-       KDC_ERR_REVOKED_CERTIFICATE                  72
-       KDC_ERR_REVOCATION_STATUS_UNKNOWN            73
-       KDC_ERR_CLIENT_NAME_MISMATCH                 75
-       KDC_ERR_INCONSISTENT_KEY_PURPOSE             77
-       KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED          78
-       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED         79
-       KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED   80
-       KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED  81
-
-   PKINIT uses the following typed data types for errors:
-
-       TD_TRUSTED_CERTIFIERS                       104
-       TD_INVALID_CERTIFICATES                     105
-       TD_DH_PARAMETERS                            109
-
-   The ASN.1 module for all structures defined in this document (plus
-   IMPORT statements for all imported structures) is given in Appendix
-   A.
-
-   All structures defined in or imported into this document MUST be
-   encoded using Distinguished Encoding Rules (DER) [X680] [X690]
-   (unless otherwise noted).  All data structures carried in OCTET
-   STRINGs MUST be encoded according to the rules specified in the
-   specifications defining each data structure; a reference to the
-   appropriate specification is provided for each data structure.
-
-
-
-
-
-
-
-
-Zhu & Tung                  Standards Track                     [Page 7]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   Interoperability note: Some implementations may not be able to decode
-   wrapped Cryptographic Message Syntax (CMS) [RFC3852] objects encoded
-   with BER; specifically, they may not be able to decode indefinite-
-   length encodings.  To maximize interoperability, implementers SHOULD
-   encode CMS objects used in PKINIT with DER.
-
-3.1.4.  Kerberos Encryption Types Defined for CMS Algorithm Identifiers
-
-   PKINIT defines the following Kerberos encryption type numbers
-   [RFC3961], which can be used in the etype field of the AS-REQ
-   [RFC4120] message to indicate to the KDC the client's acceptance of
-   the corresponding algorithms (including key transport algorithms
-   [RFC3370], content encryption algorithms [RFC3370], and signature
-   algorithms) for use with Cryptographic Message Syntax (CMS) [RFC3852]
-   [RFC3370].
-
-   Per [RFC4120], the encryption types in the etype field are in the
-   decreasing preference order of the client.  Note that there is no
-   significance in the relative order between any two of different types
-   of algorithms: key transport algorithms, content encryption
-   algorithms, and signature algorithms.
-
-   The presence of each of these encryption types in the etype field is
-   equivalent to the presence of the corresponding algorithm Object
-   Identifier (OID) in the supportedCMSTypes field as described in
-   Section 3.2.1.  And the preference order expressed in the
-   supportedCMSTypes field would override the preference order listed in
-   the etype field.
-
-    Kerberos Encryption Type Name  Num  Corresponding Algorithm OID
-    ============================== === ===============================
-    id-dsa-with-sha1-CmsOID         9  id-dsa-with-sha1 [RFC3370]
-    md5WithRSAEncryption-CmsOID    10  md5WithRSAEncryption [RFC3370]
-    sha-1WithRSAEncryption-CmsOID  11  sha-1WithRSAEncryption [RFC3370]
-    rc2-cbc-EnvOID                 12  rc2-cbc [RFC3370]
-    rsaEncryption-EnvOID           13  rsaEncryption [RFC3447][RFC3370]
-    id-RSAES-OAEP-EnvOID           14  id-RSAES-OAEP [RFC3447][RFC3560]
-    des-ede3-cbc-EnvOID            15  des-ede3-cbc [RFC3370]
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                  Standards Track                     [Page 8]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   The above encryption type numbers are used only to indicate support
-   for the use of the corresponding algorithms in PKINIT; they do not
-   correspond to actual Kerberos encryption types [RFC3961] and MUST NOT
-   be used in the etype field of the Kerberos EncryptedData type
-   [RFC4120].  The practice of assigning Kerberos encryption type
-   numbers to indicate support for CMS algorithms is considered
-   deprecated, and new numbers should not be assigned for this purpose.
-   Instead, the supportedCMSTypes field should be used to identify the
-   algorithms supported by the client and the preference order of the
-   client.
-
-   For maximum interoperability, however, PKINIT clients wishing to
-   indicate to the KDC the support for one or more of the algorithms
-   listed above SHOULD include the corresponding encryption type
-   number(s) in the etype field of the AS-REQ.
-
-3.2.  PKINIT Pre-authentication Syntax and Use
-
-   This section defines the syntax and use of the various pre-
-   authentication fields employed by PKINIT.
-
-3.2.1.  Generation of Client Request
-
-   The initial authentication request (AS-REQ) is sent as per [RFC4120];
-   in addition, a pre-authentication data element, whose padata-type is
-   PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
-   type PA-PK-AS-REQ, is included.
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- Contains a list of CAs, trusted by the client,
-                   -- that can be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-
-
-
-Zhu & Tung                  Standards Track                     [Page 9]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-
-
-
-Zhu & Tung                  Standards Track                    [Page 10]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS algorithm [RFC3370] identifiers
-                   -- that identify key transport algorithms, or
-                   -- content encryption algorithms, or signature
-                   -- algorithms supported by the client in order of
-                   -- (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so (see Section 3.2.3.1).
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly;  this nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING OPTIONAL,
-                   -- MUST be present.
-                   -- Contains the SHA1 checksum, performed over
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-   The ContentInfo [RFC3852] structure contained in the signedAuthPack
-   field of the type PA-PK-AS-REQ is encoded according to [RFC3852] and
-   is filled out as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-
-
-
-
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 11]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   2.  The eContentType field for the type SignedData is id-pkinit-
-       authData: { iso(1) org(3) dod(6) internet(1) security(5)
-       kerberosv5(2) pkinit(3) authData(1) }.  Notes to CMS
-       implementers: the signed attribute content-type MUST be present
-       in this SignedData instance, and its value is id-pkinit-authData
-       according to [RFC3852].
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type AuthPack.
-
-   4.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type AuthPack.
-
-   5.  The AuthPack structure contains a PKAuthenticator, the client
-       public key information, the CMS encryption types supported by the
-       client, and a DHNonce.  The pkAuthenticator field certifies to
-       the KDC that the client has recent knowledge of the signing key
-       that authenticates the client.  The clientPublicValue field
-       specifies Diffie-Hellman domain parameters and the client's
-       public key value.  The DH public key value is encoded as a BIT
-       STRING according to [RFC3279].  The clientPublicValue field is
-       present only if the client wishes to use the Diffie-Hellman key
-       agreement method.  The supportedCMSTypes field specifies the list
-       of CMS algorithm identifiers that are supported by the client in
-       order of (decreasing) preference, and can be used to identify a
-       signature algorithm or a key transport algorithm [RFC3370] in the
-       keyEncryptionAlgorithm field of the type KeyTransRecipientInfo,
-       or a content encryption algorithm [RFC3370] in the
-       contentEncryptionAlgorithm field of the type EncryptedContentInfo
-       [RFC3852] when encrypting the AS reply key as described in
-       Section 3.2.3.2.  However, there is no significance in the
-       relative order between any two of different types of algorithms:
-       key transport algorithms, content encryption algorithms, and
-       signature algorithms.  The clientDHNonce field is described later
-       in this section.
-
-   6.  The ctime field in the PKAuthenticator structure contains the
-       current time on the client's host, and the cusec field contains
-       the microsecond part of the client's timestamp.  The ctime and
-       cusec fields are used together to specify a reasonably accurate
-       timestamp [RFC4120].  The nonce field is chosen randomly.  The
-       paChecksum field MUST be present and it contains a SHA1 checksum
-       that is performed over the KDC-REQ-BODY [RFC4120].  In order to
-       ease future migration from the use of SHA1, the paChecksum field
-       is made optional syntactically: when the request is extended to
-       negotiate hash algorithms, the new client wishing not to use SHA1
-       will send the request in the extended message syntax without the
-       paChecksum field.  The KDC conforming to this specification MUST
-
-
-
-Zhu & Tung                  Standards Track                    [Page 12]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-       return a KRB-ERROR [RFC4120] message with the code
-       KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (see Section 3.2.3).  That
-       will allow a new client to retry with SHA1 if allowed by the
-       local policy.
-
-   7.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the KDC can verify the signature over the
-       type AuthPack.  For path validation, these certificates SHOULD be
-       sufficient to construct at least one certification path from the
-       client certificate to one trust anchor acceptable by the KDC
-       [RFC4158].  The client MUST be capable of including such a set of
-       certificates if configured to do so.  The certificates field MUST
-       NOT contain "root" CA certificates.
-
-   8.  The client's Diffie-Hellman public value (clientPublicValue) is
-       included if and only if the client wishes to use the Diffie-
-       Hellman key agreement method.  The Diffie-Hellman domain
-       parameters [IEEE1363] for the client's public key are specified
-       in the algorithm field of the type SubjectPublicKeyInfo
-       [RFC3279], and the client's Diffie-Hellman public key value is
-       mapped to a subjectPublicKey (a BIT STRING) according to
-       [RFC3279].  When using the Diffie-Hellman key agreement method,
-       implementations MUST support Oakley 1024-bit Modular Exponential
-       (MODP) well-known group 2 [RFC2412] and Oakley 2048-bit MODP
-       well-known group 14 [RFC3526] and SHOULD support Oakley 4096-bit
-       MODP well-known group 16 [RFC3526].
-
-       The Diffie-Hellman field size should be chosen so as to provide
-       sufficient cryptographic security [RFC3766].
-
-       When MODP Diffie-Hellman is used, the exponents should have at
-       least twice as many bits as the symmetric keys that will be
-       derived from them [ODL99].
-
-   9.  The client may wish to reuse DH keys or to allow the KDC to do so
-       (see Section 3.2.3.1).  If so, then the client includes the
-       clientDHNonce field.  This nonce string MUST be as long as the
-       longest key length of the symmetric key types that the client
-       supports.  This nonce MUST be chosen randomly.
-
-   The ExternalPrincipalIdentifier structure is used in this document to
-   identify the subject's public key thereby the subject principal.
-   This structure is filled out as follows:
-
-   1.  The subjectName field contains a PKIX type Name encoded according
-       to [RFC3280].  This field identifies the certificate subject by
-       the distinguished subject name.  This field is REQUIRED when
-
-
-
-Zhu & Tung                  Standards Track                    [Page 13]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-       there is a distinguished subject name present in the certificate
-       being used.
-
-   2.  The issuerAndSerialNumber field contains a CMS type
-       IssuerAndSerialNumber encoded according to [RFC3852].  This field
-       identifies a certificate of the subject.  This field is REQUIRED
-       for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
-       structures are defined in Section 3.2.2).
-
-   3.  The subjectKeyIdentifier [RFC3852] field identifies the subject's
-       public key by a key identifier.  When an X.509 certificate is
-       referenced, this key identifier matches the X.509
-       subjectKeyIdentifier extension value.  When other certificate
-       formats are referenced, the documents that specify the
-       certificate format and their use with the CMS must include
-       details on matching the key identifier to the appropriate
-       certificate field.  This field is RECOMMENDED for TD-TRUSTED-
-       CERTIFIERS (as defined in Section 3.2.2).
-
-   The trustedCertifiers field of the type PA-PK-AS-REQ contains a list
-   of CAs, trusted by the client, that can be used to certify the KDC.
-   Each ExternalPrincipalIdentifier identifies a CA or a CA certificate
-   (thereby its public key).
-
-   The kdcPkId field of the type PA-PK-AS-REQ contains a CMS type
-   SignerIdentifier encoded according to [RFC3852].  This field
-   identifies, if present, a particular KDC public key that the client
-   already has.
-
-3.2.2.  Receipt of Client Request
-
-   Upon receiving the client's request, the KDC validates it.  This
-   section describes the steps that the KDC MUST (unless otherwise
-   noted) take in validating the request.
-
-   The KDC verifies the client's signature in the signedAuthPack field
-   according to [RFC3852].
-
-   If, while validating the client's X.509 certificate [RFC3280], the
-   KDC cannot build a certification path to validate the client's
-   certificate, it sends back a KRB-ERROR [RFC4120] message with the
-   code KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for
-   this error message is a TYPED-DATA (as defined in [RFC4120]) that
-   contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
-   whose data-value contains the DER encoding of the type TD-TRUSTED-
-   CERTIFIERS:
-
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 14]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
-   TD-TRUSTED-CERTIFIERS structure identifies a CA or a CA certificate
-   (thereby its public key) trusted by the KDC.
-
-   Upon receiving this error message, the client SHOULD retry only if it
-   has a different set of certificates (from those of the previous
-   requests) that form a certification path (or a partial path) from one
-   of the trust anchors acceptable by the KDC to its own certificate.
-
-   If, while processing the certification path, the KDC determines that
-   the signature on one of the certificates in the signedAuthPack field
-   is invalid, it returns a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_INVALID_CERTIFICATE.  The accompanying e-data for this error
-   message is a TYPED-DATA that contains an element whose data-type is
-   TD_INVALID_CERTIFICATES, and whose data-value contains the DER
-   encoding of the type TD-INVALID-CERTIFICATES:
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-   Each ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the
-   TD-INVALID-CERTIFICATES structure identifies a certificate (that was
-   sent by the client) with an invalid signature.
-
-   If more than one X.509 certificate signature is invalid, the KDC MAY
-   include one IssuerAndSerialNumber per invalid signature within the
-   TD-INVALID-CERTIFICATES.
-
-   The client's X.509 certificate is validated according to [RFC3280].
-
-   Depending on local policy, the KDC may also check whether any X.509
-   certificates in the certification path validating the client's
-   certificate have been revoked.  If any of them have been revoked, the
-   KDC MUST return an error message with the code
-   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
-   revocation status but is unable to do so, it SHOULD return an error
-   message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The
-   certificate or certificates affected are identified exactly as for
-   the error code KDC_ERR_INVALID_CERTIFICATE (see above).
-
-
-
-Zhu & Tung                  Standards Track                    [Page 15]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   Note that the TD_INVALID_CERTIFICATES error data is only used to
-   identify invalid certificates sent by the client in the request.
-
-   The client's public key is then used to verify the signature.  If the
-   signature fails to verify, the KDC MUST return an error message with
-   the code KDC_ERR_INVALID_SIG.  There is no accompanying e-data for
-   this error message.
-
-   In addition to validating the client's signature, the KDC MUST also
-   check that the client's public key used to verify the client's
-   signature is bound to the client principal name specified in the AS-
-   REQ as follows:
-
-   1. If the KDC has its own binding between either the client's
-      signature-verification public key or the client's certificate and
-      the client's Kerberos principal name, it uses that binding.
-
-   2. Otherwise, if the client's X.509 certificate contains a Subject
-      Alternative Name (SAN) extension carrying a KRB5PrincipalName
-      (defined below) in the otherName field of the type GeneralName
-      [RFC3280], it binds the client's X.509 certificate to that name.
-
-      The type of the otherName field is AnotherName.  The type-id field
-      of the type AnotherName is id-pkinit-san:
-
-       id-pkinit-san OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509SanAN (2) }
-
-      And the value field of the type AnotherName is a
-      KRB5PrincipalName.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-   If the Kerberos client name in the AS-REQ does not match a name bound
-   by the KDC (the binding can be in the certificate, for example, as
-   described above), or if there is no binding found by the KDC, the KDC
-   MUST return an error message with the code
-   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
-   this error message.
-
-   Even if the certification path is validated and the certificate is
-   mapped to the client's principal name, the KDC may decide not to
-   accept the client's certificate, depending on local policy.
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 16]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   The KDC MAY require the presence of an Extended Key Usage (EKU)
-   KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
-   of the client's X.509 certificate:
-
-       id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) keyPurposeClientAuth(4) }
-              -- PKINIT client authentication.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   The digitalSignature key usage bit [RFC3280] MUST be asserted when
-   the intended purpose of the client's X.509 certificate is restricted
-   with the id-pkinit-KPClientAuth EKU.
-
-   If this EKU KeyPurposeId is required but it is not present, or if the
-   client certificate is restricted not to be used for PKINIT client
-   authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
-   an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE.  There
-   is no accompanying e-data for this error message.  KDCs implementing
-   this requirement SHOULD also accept the EKU KeyPurposeId
-   id-ms-kp-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the
-   requirement, as there are a large number of X.509 client certificates
-   deployed for use with PKINIT that have this EKU.
-
-   As a matter of local policy, the KDC MAY decide to reject requests on
-   the basis of the absence or presence of other specific EKU OIDs.
-
-   If the digest algorithm used in generating the CA signature for the
-   public key in any certificate of the request is not acceptable by the
-   KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code
-   KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED.  The accompanying e-data MUST be
-   encoded in TYPED-DATA, although none is defined at this point.
-
-   If the client's public key is not accepted with reasons other than
-   those specified above, the KDC returns a KRB-ERROR [RFC4120] message
-   with the code KDC_ERR_CLIENT_NOT_TRUSTED.  There is no accompanying
-   e-data currently defined for this error message.
-
-   The KDC MUST check the timestamp to ensure that the request is not a
-   replay, and that the time skew falls within acceptable limits.  The
-   recommendations for clock skew times in [RFC4120] apply here.  If the
-   check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
-   KRB_AP_ERR_SKEW, respectively.
-
-   If the clientPublicValue is filled in, indicating that the client
-   wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
-   check to see if the key parameters satisfy its policy.  If they do
-
-
-
-Zhu & Tung                  Standards Track                    [Page 17]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   not, it MUST return an error message with the code
-   KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED.  The accompanying e-data is a
-   TYPED-DATA that contains an element whose data-type is
-   TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
-   the type TD-DH-PARAMETERS:
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-
-   TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
-   that the KDC supports in decreasing preference order, from which the
-   client SHOULD pick one to retry the request.
-
-   The AlgorithmIdentifier structure is defined in [RFC3280] and is
-   filled in according to [RFC3279].  More specifically, Section 2.3.3
-   of [RFC3279] describes how to fill in the AlgorithmIdentifier
-   structure in the case where MODP Diffie-Hellman key exchange is used.
-
-   If the client included a kdcPkId field in the PA-PK-AS-REQ and the
-   KDC does not possess the corresponding key, the KDC MUST ignore the
-   kdcPkId field as if the client did not include one.
-
-   If the digest algorithm used by the id-pkinit-authData is not
-   acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120]
-   message with the code KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED.
-   The accompanying e-data MUST be encoded in TYPED-DATA, although none
-   is defined at this point.
-
-3.2.3.  Generation of KDC Reply
-
-   If the paChecksum filed in the request is not present, the KDC
-   conforming to this specification MUST return a KRB-ERROR [RFC4120]
-   message with the code KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED.  The
-   accompanying e-data MUST be encoded in TYPED-DATA (no error data is
-   defined by this specification).
-
-   Assuming that the client's request has been properly validated, the
-   KDC proceeds as per [RFC4120], except as follows.
-
-   The KDC MUST set the initial flag and include an authorization data
-   element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
-   ticket.  The ad-data [RFC4120] field contains the DER encoding of the
-   type AD-INITIAL-VERIFIED-CAS:
-
-
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 18]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path with which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-   The AD-INITIAL-VERIFIED-CAS structure identifies the certification
-   path with which the client certificate was validated.  Each
-   ExternalPrincipalIdentifier (as defined in Section 3.2.1) in the AD-
-   INITIAL-VERIFIED-CAS structure identifies a CA or a CA certificate
-   (thereby its public key).
-
-   Note that the syntax for the AD-INITIAL-VERIFIED-CAS authorization
-   data does permit empty SEQUENCEs to be encoded.  Such empty sequences
-   may only be used if the KDC itself vouches for the user's
-   certificate.
-
-   The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
-   containers if the list of CAs satisfies the AS' realm's local policy
-   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
-   [RFC4120]).  Furthermore, any TGS MUST copy such authorization data
-   from tickets used within a PA-TGS-REQ of the TGS-REQ into the
-   resulting ticket.  If the list of CAs satisfies the local KDC's
-   realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
-   container; otherwise, it MAY unwrap the authorization data out of the
-   AD-IF-RELEVANT container.
-
-   Application servers that understand this authorization data type
-   SHOULD apply local policy to determine whether a given ticket bearing
-   such a type *not* contained within an AD-IF-RELEVANT container is
-   acceptable.  (This corresponds to the AP server's checking the
-   transited field when the TRANSITED-POLICY-CHECKED flag has not been
-   set [RFC4120].)  If such a data type is contained within an AD-IF-
-   RELEVANT container, AP servers MAY apply local policy to determine
-   whether the authorization data is acceptable.
-
-   A pre-authentication data element, whose padata-type is PA_PK_AS_REP
-   and whose padata-value contains the DER encoding of the type PA-PK-
-   AS-REP (defined below), is included in the AS-REP [RFC4120].
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-
-
-
-Zhu & Tung                  Standards Track                    [Page 19]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is
-                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-                   -- eContent field contains the DER encoding of the
-                   -- type ReplyKeyPack.
-                   -- ReplyKeyPack is defined in Section 3.2.3.2.
-          ...
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL,
-                   -- Present if and only if dhKeyExpiration is
-                   -- present in the KDCDHKeyInfo.
-          ...
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- The KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the pkAuthenticator field
-                   -- in the request if the DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if the DH keys are reused.
-                   -- If present, the KDC's DH public key MUST not be
-                   -- used past the point of this expiration time.
-                   -- If this field is omitted then the serverDHNonce
-
-
-
-Zhu & Tung                  Standards Track                    [Page 20]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-                   -- field MUST also be omitted.
-          ...
-       }
-
-   The content of the AS-REP is otherwise unchanged from [RFC4120].  The
-   KDC encrypts the reply as usual, but not with the client's long-term
-   key.  Instead, it encrypts it with either a shared key derived from a
-   Diffie-Hellman exchange or a generated encryption key.  The contents
-   of the PA-PK-AS-REP indicate which key delivery method is used.
-
-   If the client does not wish to use the Diffie-Hellman key delivery
-   method (the clientPublicValue field is not present in the request)
-   and the KDC does not support the public key encryption key delivery
-   method, the KDC MUST return an error message with the code
-   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED.  There is no
-   accompanying e-data for this error message.
-
-   In addition, the lifetime of the ticket returned by the KDC MUST NOT
-   exceed that of the client's public-private key pair.  The ticket
-   lifetime, however, can be shorter than that of the client's public-
-   private key pair.  For the implementations of this specification, the
-   lifetime of the client's public-private key pair is the validity
-   period in X.509 certificates [RFC3280], unless configured otherwise.
-
-3.2.3.1.  Using Diffie-Hellman Key Exchange
-
-   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
-
-   The ContentInfo [RFC3852] structure for the dhSignedData field is
-   filled in as follows:
-
-   1.  The contentType field of the type ContentInfo is id-signedData
-       (as defined in [RFC3852]), and the content field is a SignedData
-       (as defined in [RFC3852]).
-
-   2.  The eContentType field for the type SignedData is the OID value
-       for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
-       security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.  Notes to CMS
-       implementers: the signed attribute content-type MUST be present
-       in this SignedData instance, and its value is id-pkinit-DHKeyData
-       according to [RFC3852].
-
-   3.  The eContent field for the type SignedData contains the DER
-       encoding of the type KDCDHKeyInfo.
-
-   4.  The KDCDHKeyInfo structure contains the KDC's public key, a
-       nonce, and, optionally, the expiration time of the KDC's DH key
-       being reused.  The subjectPublicKey field of the type
-
-
-
-Zhu & Tung                  Standards Track                    [Page 21]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-       KDCDHKeyInfo field identifies KDC's DH public key.  This DH
-       public key value is encoded as a BIT STRING according to
-       [RFC3279].  The nonce field contains the nonce in the
-       pkAuthenticator field in the request if the DH keys are NOT
-       reused.  The value of this nonce field is 0 if the DH keys are
-       reused.  The dhKeyExpiration field is present if and only if the
-       DH keys are reused.  If the dhKeyExpiration field is present, the
-       KDC's public key in this KDCDHKeyInfo structure MUST NOT be used
-       past the point of this expiration time.  If this field is
-       omitted, then the serverDHNonce field MUST also be omitted.
-
-   5.  The signerInfos field of the type SignedData contains a single
-       signerInfo, which contains the signature over the type
-       KDCDHKeyInfo.
-
-   6.  The certificates field of the type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       over the type KDCDHKeyInfo.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may be left empty if the KDC
-       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
-       used for signing.  Otherwise, for path validation, these
-       certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [RFC4158].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  If the client included the clientDHNonce field, then the KDC may
-       choose to reuse its DH keys.  If the server reuses DH keys, then
-       it MUST include an expiration time in the dhKeyExpiration field.
-       Past the point of the expiration time, the signature over the
-       type DHRepInfo is considered expired/invalid.  When the server
-       reuses DH keys then, it MUST include a serverDHNonce at least as
-       long as the length of keys for the symmetric encryption system
-       used to encrypt the AS reply.  Note that including the
-       serverDHNonce changes how the client and server calculate the key
-       to use to encrypt the reply; see below for details.  The KDC
-       SHOULD NOT reuse DH keys unless the clientDHNonce field is
-       present in the request.
-
-   The AS reply key is derived as follows:
-
-   1. Both the KDC and the client calculate the shared secret value as
-      follows:
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 22]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-          a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
-          shared secret value.  DHSharedSecret is the value ZZ, as
-          described in Section 2.1.1 of [RFC2631].
-
-      DHSharedSecret is first padded with leading zeros such that the
-      size of DHSharedSecret in octets is the same as that of the
-      modulus, then represented as a string of octets in big-endian
-      order.
-
-      Implementation note: Both the client and the KDC can cache the
-      triple (ya, yb, DHSharedSecret), where ya is the client's public
-      key and yb is the KDC's public key.  If both ya and yb are the
-      same in a later exchange, the cached DHSharedSecret can be used.
-
-   2. Let K be the key-generation seed length [RFC3961] of the AS reply
-      key whose enctype is selected according to [RFC4120].
-
-   3. Define the function octetstring2key() as follows:
-
-           octetstring2key(x) == random-to-key(K-truncate(
-                                    SHA1(0x00 | x) |
-                                    SHA1(0x01 | x) |
-                                    SHA1(0x02 | x) |
-                                    ...
-                                    ))
-
-      where x is an octet string; | is the concatenation operator; 0x00,
-      0x01, 0x02, etc. are each represented as a single octet; random-
-      to-key() is an operation that generates a protocol key from a
-      bitstring of length K; and K-truncate truncates its input to the
-      first K bits.  Both K and random-to-key() are as defined in the
-      kcrypto profile [RFC3961] for the enctype of the AS reply key.
-
-   4. When DH keys are reused, let n_c be the clientDHNonce and n_k be
-      the serverDHNonce; otherwise, let both n_c and n_k be empty octet
-      strings.
-
-   5. The AS reply key k is:
-              k = octetstring2key(DHSharedSecret | n_c | n_k)
-
-3.2.3.2.  Using Public Key Encryption
-
-   In this case, the PA-PK-AS-REP contains the encKeyPack field where
-   the AS reply key is encrypted.
-
-   The ContentInfo [RFC3852] structure for the encKeyPack field is
-   filled in as follows:
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 23]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   1.  The contentType field of the type ContentInfo is id-envelopedData
-       (as defined in [RFC3852]), and the content field is an
-       EnvelopedData (as defined in [RFC3852]).
-
-   2.  The contentType field for the type EnvelopedData is id-
-       signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
-       pkcs (1) pkcs7 (7) signedData (2) }.
-
-   3.  The eContentType field for the inner type SignedData (when
-       decrypted from the encryptedContent field for the type
-       EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
-       internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
-       Notes to CMS implementers: the signed attribute content-type MUST
-       be present in this SignedData instance, and its value is id-
-       pkinit-rkeyData according to [RFC3852].
-
-   4.  The eContent field for the inner type SignedData contains the DER
-       encoding of the type ReplyKeyPack (as described below).
-
-   5.  The signerInfos field of the inner type SignedData contains a
-       single signerInfo, which contains the signature for the type
-       ReplyKeyPack.
-
-   6.  The certificates field of the inner type SignedData contains
-       certificates intended to facilitate certification path
-       construction, so that the client can verify the KDC's signature
-       for the type ReplyKeyPack.  The information contained in the
-       trustedCertifiers in the request SHOULD be used by the KDC as
-       hints to guide its selection of an appropriate certificate chain
-       to return to the client.  This field may be left empty if the KDC
-       public key specified by the kdcPkId field in the PA-PK-AS-REQ was
-       used for signing.  Otherwise, for path validation, these
-       certificates SHOULD be sufficient to construct at least one
-       certification path from the KDC certificate to one trust anchor
-       acceptable by the client [RFC4158].  The KDC MUST be capable of
-       including such a set of certificates if configured to do so.  The
-       certificates field MUST NOT contain "root" CA certificates.
-
-   7.  The recipientInfos field of the type EnvelopedData is a SET that
-       MUST contain exactly one member of type KeyTransRecipientInfo.
-       The encryptedKey of this member contains the temporary key that
-       is encrypted using the client's public key.
-
-   8.  The unprotectedAttrs or originatorInfo fields of the type
-       EnvelopedData MAY be present.
-
-
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 24]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   If there is a supportedCMSTypes field in the AuthPack, the KDC must
-   check to see if it supports any of the listed types.  If it supports
-   more than one of the types, the KDC SHOULD use the one listed first.
-   If it does not support any of them, it MUST return an error message
-   with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
-
-   Furthermore, the KDC computes the checksum of the AS-REQ in the
-   client request.  This checksum is performed over the type AS-REQ, and
-   the protocol key [RFC3961] of the checksum operation is the replyKey,
-   and the key usage number is 6.  If the replyKey's enctype is "newer"
-   [RFC4120] [RFC4121], the checksum operation is the required checksum
-   operation [RFC3961] of that enctype.
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP, i.e., the
-                   -- AS reply key.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-   Implementations of this RSA encryption key delivery method are
-   RECOMMENDED to support RSA keys at least 2048 bits in size.
-
-3.2.4.  Receipt of KDC Reply
-
-   Upon receipt of the KDC's reply, the client proceeds as follows.  If
-   the PA-PK-AS-REP contains the dhSignedData field, the client derives
-   the AS reply key using the same procedure used by the KDC, as defined
-   in Section 3.2.3.1.  Otherwise, the message contains the encKeyPack
-   field, and the client decrypts and extracts the temporary key in the
-   encryptedKey field of the member KeyTransRecipientInfo and then uses
-   that as the AS reply key.
-
-   If the public key encryption method is used, the client MUST verify
-   the asChecksum contained in the ReplyKeyPack.
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 25]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   In either case, the client MUST verify the signature in the
-   SignedData according to [RFC3852].  The KDC's X.509 certificate MUST
-   be validated according to [RFC3280].  In addition, unless the client
-   can otherwise verify that the public key used to verify the KDC's
-   signature is bound to the KDC of the target realm, the KDC's X.509
-   certificate MUST contain a Subject Alternative Name extension
-   [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
-   defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
-   matches the name of the TGS of the target realm (as defined in
-   Section 7.3 of [RFC4120]).
-
-   Unless the client knows by some other means that the KDC certificate
-   is intended for a Kerberos KDC, the client MUST require that the KDC
-   certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
-
-       id-pkinit-KPKdc OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           pkinit(3) keyPurposeKdc(5) }
-              -- Signing KDC responses.
-              -- Key usage bits that MUST be consistent:
-              -- digitalSignature.
-
-   The digitalSignature key usage bit [RFC3280] MUST be asserted when
-   the intended purpose of the KDC's X.509 certificate is restricted
-   with the id-pkinit-KPKdc EKU.
-
-   If the KDC certificate contains the Kerberos TGS name encoded as an
-   id-pkinit-san SAN, this certificate is certified by the issuing CA as
-   a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
-
-   If all applicable checks are satisfied, the client then decrypts the
-   enc-part field of the KDC-REP in the AS-REP, using the AS reply key,
-   and then proceeds as described in [RFC4120].
-
-3.3.  Interoperability Requirements
-
-   The client MUST be capable of sending a set of certificates
-   sufficient to allow the KDC to construct a certification path for the
-   client's certificate, if the correct set of certificates is provided
-   through configuration or policy.
-
-   If the client sends all the X.509 certificates on a certification
-   path to a trust anchor acceptable by the KDC, and if the KDC cannot
-   verify the client's public key otherwise, the KDC MUST be able to
-   process path validation for the client's certificate based on the
-   certificates in the request.
-
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 26]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   The KDC MUST be capable of sending a set of certificates sufficient
-   to allow the client to construct a certification path for the KDC's
-   certificate, if the correct set of certificates is provided through
-   configuration or policy.
-
-   If the KDC sends all the X.509 certificates on a certification path
-   to a trust anchor acceptable by the client, and the client can not
-   verify the KDC's public key otherwise, the client MUST be able to
-   process path validation for the KDC's certificate based on the
-   certificates in the reply.
-
-3.4.  KDC Indication of PKINIT Support
-
-   If pre-authentication is required but was not present in the request,
-   per [RFC4120] an error message with the code KDC_ERR_PREAUTH_FAILED
-   is returned, and a METHOD-DATA object will be stored in the e-data
-   field of the KRB-ERROR message to specify which pre-authentication
-   mechanisms are acceptable.  The KDC can then indicate the support of
-   PKINIT by including an empty element whose padata-type is
-   PA_PK_AS_REQ in that METHOD-DATA object.
-
-   Otherwise if it is required by the KDC's local policy that the client
-   must be pre-authenticated using the pre-authentication mechanism
-   specified in this document, but no PKINIT pre-authentication was
-   present in the request, an error message with the code
-   KDC_ERR_PREAUTH_FAILED SHOULD be returned.
-
-   KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
-   the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
-   STRING), and clients MUST ignore this and any other value.  Future
-   extensions to this protocol may specify other data to send instead of
-   an empty OCTET STRING.
-
-4.  Security Considerations
-
-   The security of cryptographic algorithms is dependent on generating
-   secret quantities [RFC4086].  The number of truly random bits is
-   extremely important in determining the attack resistance strength of
-   the cryptosystem; for example, the secret Diffie-Hellman exponents
-   must be chosen based on n truly random bits (where n is the system
-   security requirement).  The security of the overall system is
-   significantly weakened by using insufficient random inputs: a
-   sophisticated attacker may find it easier to reproduce the
-   environment that produced the secret quantities and to search the
-   resulting small set of possibilities than to locate the quantities in
-   the whole of the potential number space.
-
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 27]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   Kerberos error messages are not integrity protected; as a result, the
-   domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
-   with by an attacker so that the set of domain parameters selected
-   could be either weaker or not mutually preferred.  Local policy can
-   configure sets of domain parameters acceptable locally, or disallow
-   the negotiation of DH domain parameters.
-
-   The symmetric reply key size and Diffie-Hellman field size or RSA
-   modulus size should be chosen so as to provide sufficient
-   cryptographic security [RFC3766].
-
-   When MODP Diffie-Hellman is used, the exponents should have at least
-   twice as many bits as the symmetric keys that will be derived from
-   them [ODL99].
-
-   PKINIT raises certain security considerations beyond those that can
-   be regulated strictly in protocol definitions.  We will address them
-   in this section.
-
-   PKINIT extends the cross-realm model to the public-key
-   infrastructure.  Users of PKINIT must understand security policies
-   and procedures appropriate to the use of Public Key Infrastructures
-   [RFC3280].
-
-   In order to trust a KDC certificate that is certified by a CA as a
-   KDC certificate for a target realm (for example, by asserting the TGS
-   name of that Kerberos realm as an id-pkinit-san SAN and/or
-   restricting the certificate usage by using the id-pkinit-KPKdc EKU,
-   as described in Section 3.2.4), the client MUST verify that the KDC
-   certificate's issuing CA is authorized to issue KDC certificates for
-   that target realm.  Otherwise, the binding between the KDC
-   certificate and the KDC of the target realm is not established.
-
-   How to validate this authorization is a matter of local policy.  A
-   way to achieve this is the configuration of specific sets of
-   intermediary CAs and trust anchors, one of which must be on the KDC
-   certificate's certification path [RFC3280], and, for each CA or trust
-   anchor, the realms for which it is allowed to issue certificates.
-
-   In addition, if any CA that is trusted to issue KDC certificates can
-   also issue other kinds of certificates, then local policy must be
-   able to distinguish between them; for example, it could require that
-   KDC certificates contain the id-pkinit-KPKdc EKU or that the realm be
-   specified with the id-pkinit-san SAN.
-
-   It is the responsibility of the PKI administrators for an
-   organization to ensure that KDC certificates are only issued to KDCs,
-   and that clients can ascertain this using their local policy.
-
-
-
-Zhu & Tung                  Standards Track                    [Page 28]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   Standard Kerberos allows the possibility of interactions between
-   cryptosystems of varying strengths; this document adds interactions
-   with public-key cryptosystems to Kerberos.  Some administrative
-   policies may allow the use of relatively weak public keys.  When
-   using such weak asymmetric keys to protect/exchange stronger
-   symmetric Keys, the attack resistant strength of the overall system
-   is no better than that of these weak keys [RFC3766].
-
-   PKINIT requires that keys for symmetric cryptosystems be generated.
-   Some such systems contain "weak" keys.  For recommendations regarding
-   these weak keys, see [RFC4120].
-
-   PKINIT allows the use of the same RSA key pair for encryption and
-   signing when doing RSA encryption-based key delivery.  This is not
-   recommended usage of RSA keys [RFC3447]; by using DH-based key
-   delivery, this is avoided.
-
-   Care should be taken in how certificates are chosen for the purposes
-   of authentication using PKINIT.  Some local policies may require that
-   key escrow be used for certain certificate types.  Deployers of
-   PKINIT should be aware of the implications of using certificates that
-   have escrowed keys for the purposes of authentication.  Because
-   signing-only certificates are normally not escrowed, by using DH-
-   based key delivery this is avoided.
-
-   PKINIT does not provide for a "return routability" test to prevent
-   attackers from mounting a denial-of-service attack on the KDC by
-   causing it to perform unnecessary and expensive public-key
-   operations.  Strictly speaking, this is also true of standard
-   Kerberos, although the potential cost is not as great, because
-   standard Kerberos does not make use of public-key cryptography.  By
-   using DH-based key delivery and reusing DH keys, the necessary crypto
-   processing cost per request can be minimized.
-
-   When the Diffie-Hellman key exchange method is used, additional pre-
-   authentication data [RFC4120] (in addition to the PA_PK_AS_REQ, as
-   defined in this specification) is not bound to the AS_REQ by the
-   mechanisms discussed in this specification (meaning it may be dropped
-   or added by attackers without being detected by either the client or
-   the KDC).  Designers of additional pre-authentication data should
-   take that into consideration if such additional pre-authentication
-   data can be used in conjunction with the PA_PK_AS_REQ.  The future
-   work of the Kerberos working group is expected to update the hash
-   algorithms specified in this document and provide a generic mechanism
-   to bind additional pre-authentication data with the accompanying
-   AS_REQ.
-
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 29]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   The key usage number 6 used by the asChecksum field is also used for
-   the authenticator checksum (cksum field of AP-REQ) contained in the
-   PA-TGS-REQ preauthentication data contained in a TGS-REQ [RFC4120].
-   This conflict is present for historical reasons; the reuse of key
-   usage numbers is strongly discouraged.
-
-5.  Acknowledgements
-
-   The following people have made significant contributions to this
-   document: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
-   Astrand, Ken Raeburn, Nicolas Williams, John Wray, Tom Yu, Jeffrey
-   Hutzelman, David Cross, Dan Simon, Karthik Jaganathan, Chaskiel M
-   Grundman, and Jeffrey Altman.
-
-   Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay, and
-   Chris Walstad discovered a binding issue between the AS-REQ and AS-
-   REP in draft -26; the asChecksum field was added as the result.
-
-   Special thanks to Clifford Neuman, Matthew Hur, Ari Medvinsky, Sasha
-   Medvinsky, and Jonathan Trostle who wrote earlier versions of this
-   document.
-
-   The authors are indebted to the Kerberos working group chair, Jeffrey
-   Hutzelman, who kept track of various issues and was enormously
-   helpful during the creation of this document.
-
-   Some of the ideas on which this document is based arose during
-   discussions over several years between members of the SAAG, the IETF
-   CAT working group, and the PSRG, regarding integration of Kerberos
-   and SPX.  Some ideas have also been drawn from the DASS system.
-   These changes are by no means endorsed by these groups.  This is an
-   attempt to revive some of the goals of those groups, and this
-   document approaches those goals primarily from the Kerberos
-   perspective.
-
-   Lastly, comments from groups working on similar ideas in DCE have
-   been invaluable.
-
-6.  References
-
-6.1.  Normative References
-
-   [IEEE1363] IEEE, "Standard Specifications for Public Key
-              Cryptography", IEEE 1363, 2000.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 30]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol", RFC
-              2412, November 1998.
-
-   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
-              2631, June 1999.
-
-   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
-              Identifiers for the Internet X.509 Public Key
-              Infrastructure Certificate and Certificate Revocation List
-              (CRL) Profile", RFC 3279, April 2002.
-
-   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
-              Algorithms", RFC 3370, August 2002.
-
-   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-   [RFC3560]  Housley, R., "Use of the RSAES-OAEP Key Transport
-              Algorithm in Cryptographic Message Syntax (CMS)", RFC
-              3560, July 2003.
-
-   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
-              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
-              RFC 3766, April 2004.
-
-   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC
-              3852, July 2004.
-
-   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
-              Kerberos 5", RFC 3961, February 2005.
-
-   [RFC3962]  Raeburn, K., "Advanced Encryption Standard (AES)
-              Encryption for Kerberos 5", RFC 3962, February 2005.
-
-   [RFC4086]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-              "Randomness Requirements for Security", BCP 106, RFC 4086,
-              June 2005.
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 31]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
-              Information technology - Abstract Syntax Notation One
-              (ASN.1): Specification of basic notation.
-
-   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
-              Information technology - ASN.1 encoding Rules:
-              Specification of Basic Encoding Rules (BER), Canonical
-              Encoding Rules (CER) and Distinguished Encoding Rules
-              (DER).
-
-6.2.  Informative References
-
-   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
-              future, Designs, Codes, and Cryptography (1999)".  April
-              1999.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121, July
-              2005.
-
-   [RFC4158]  Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
-              Nicholas, "Internet X.509 Public Key Infrastructure:
-              Certification Path Building", RFC 4158, September 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 32]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-Appendix A.  PKINIT ASN.1 Module
-
-       KerberosV5-PK-INIT-SPEC {
-               iso(1) identified-organization(3) dod(6) internet(1)
-               security(5) kerberosV5(2) modules(4) pkinit(5)
-       } DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-       IMPORTS
-
-           SubjectPublicKeyInfo, AlgorithmIdentifier
-               FROM PKIX1Explicit88 { iso (1)
-                 identified-organization (3) dod (6) internet (1)
-                 security (5) mechanisms (5) pkix (7) id-mod (0)
-                 id-pkix1-explicit (18) }
-                 -- As defined in RFC 3280.
-
-           KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum
-               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
-                 dod(6) internet(1) security(5) kerberosV5(2)
-                 modules(4) krb5spec2(2) };
-                 -- as defined in RFC 4120.
-
-       id-pkinit OBJECT IDENTIFIER ::=
-         { iso(1) identified-organization(3) dod(6) internet(1)
-           security(5) kerberosv5(2) pkinit (3) }
-
-       id-pkinit-authData      OBJECT IDENTIFIER  ::= { id-pkinit 1 }
-       id-pkinit-DHKeyData     OBJECT IDENTIFIER  ::= { id-pkinit 2 }
-       id-pkinit-rkeyData      OBJECT IDENTIFIER  ::= { id-pkinit 3 }
-       id-pkinit-KPClientAuth  OBJECT IDENTIFIER  ::= { id-pkinit 4 }
-       id-pkinit-KPKdc         OBJECT IDENTIFIER  ::= { id-pkinit 5 }
-
-       id-pkinit-san OBJECT IDENTIFIER ::=
-         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
-           x509SanAN (2) }
-
-       pa-pk-as-req INTEGER ::=                  16
-       pa-pk-as-rep INTEGER ::=                  17
-
-       ad-initial-verified-cas INTEGER ::=        9
-
-       td-trusted-certifiers INTEGER ::=        104
-       td-invalid-certificates INTEGER ::=      105
-       td-dh-parameters INTEGER ::=             109
-
-       PA-PK-AS-REQ ::= SEQUENCE {
-          signedAuthPack          [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded
-
-
-
-Zhu & Tung                  Standards Track                    [Page 33]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo
-                   -- is id-signedData (1.2.840.113549.1.7.2),
-                   -- and the content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type AuthPack.
-                   -- AuthPack is defined below.
-          trustedCertifiers       [1] SEQUENCE OF
-                      ExternalPrincipalIdentifier OPTIONAL,
-                   -- Contains a list of CAs, trusted by the client,
-                   -- that can be used to certify the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-                   -- The information contained in the
-                   -- trustedCertifiers SHOULD be used by the KDC as
-                   -- hints to guide its selection of an appropriate
-                   -- certificate chain to return to the client.
-          kdcPkId                 [2] IMPLICIT OCTET STRING
-                                      OPTIONAL,
-                   -- Contains a CMS type SignerIdentifier encoded
-                   -- according to [RFC3852].
-                   -- Identifies, if present, a particular KDC
-                   -- public key that the client already has.
-          ...
-       }
-
-       DHNonce ::= OCTET STRING
-
-       ExternalPrincipalIdentifier ::= SEQUENCE {
-          subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a PKIX type Name encoded according to
-                   -- [RFC3280].
-                   -- Identifies the certificate subject by the
-                   -- distinguished subject name.
-                   -- REQUIRED when there is a distinguished subject
-                   -- name present in the certificate.
-         issuerAndSerialNumber   [1] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Contains a CMS type IssuerAndSerialNumber encoded
-                   -- according to [RFC3852].
-                   -- Identifies a certificate of the subject.
-                   -- REQUIRED for TD-INVALID-CERTIFICATES and
-                   -- TD-TRUSTED-CERTIFIERS.
-         subjectKeyIdentifier    [2] IMPLICIT OCTET STRING OPTIONAL,
-                   -- Identifies the subject's public key by a key
-                   -- identifier.  When an X.509 certificate is
-                   -- referenced, this key identifier matches the X.509
-
-
-
-Zhu & Tung                  Standards Track                    [Page 34]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-                   -- subjectKeyIdentifier extension value.  When other
-                   -- certificate formats are referenced, the documents
-                   -- that specify the certificate format and their use
-                   -- with the CMS must include details on matching the
-                   -- key identifier to the appropriate certificate
-                   -- field.
-                   -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
-          ...
-       }
-
-       AuthPack ::= SEQUENCE {
-          pkAuthenticator         [0] PKAuthenticator,
-          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
-                   -- Type SubjectPublicKeyInfo is defined in
-                   -- [RFC3280].
-                   -- Specifies Diffie-Hellman domain parameters
-                   -- and the client's public key value [IEEE1363].
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-                   -- This field is present only if the client wishes
-                   -- to use the Diffie-Hellman key agreement method.
-          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
-                                      OPTIONAL,
-                   -- Type AlgorithmIdentifier is defined in
-                   -- [RFC3280].
-                   -- List of CMS algorithm [RFC3370] identifiers
-                   -- that identify key transport algorithms, or
-                   -- content encryption algorithms, or signature
-                   -- algorithms supported by the client in order of
-                   -- (decreasing) preference.
-          clientDHNonce           [3] DHNonce OPTIONAL,
-                   -- Present only if the client indicates that it
-                   -- wishes to reuse DH keys or to allow the KDC to
-                   -- do so.
-          ...
-       }
-
-       PKAuthenticator ::= SEQUENCE {
-          cusec                   [0] INTEGER (0..999999),
-          ctime                   [1] KerberosTime,
-                   -- cusec and ctime are used as in [RFC4120], for
-                   -- replay prevention.
-          nonce                   [2] INTEGER (0..4294967295),
-                   -- Chosen randomly; this nonce does not need to
-                   -- match with the nonce in the KDC-REQ-BODY.
-          paChecksum              [3] OCTET STRING OPTIONAL,
-                   -- MUST be present.
-                   -- Contains the SHA1 checksum, performed over
-
-
-
-Zhu & Tung                  Standards Track                    [Page 35]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-                   -- KDC-REQ-BODY.
-          ...
-       }
-
-       TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies a list of CAs trusted by the KDC.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       TD-INVALID-CERTIFICATES ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Each ExternalPrincipalIdentifier identifies a
-                   -- certificate (sent by the client) with an invalid
-                   -- signature.
-
-       KRB5PrincipalName ::= SEQUENCE {
-           realm                   [0] Realm,
-           principalName           [1] PrincipalName
-       }
-
-       AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
-                      ExternalPrincipalIdentifier
-                   -- Identifies the certification path based on which
-                   -- the client certificate was validated.
-                   -- Each ExternalPrincipalIdentifier identifies a CA
-                   -- or a CA certificate (thereby its public key).
-
-       PA-PK-AS-REP ::= CHOICE {
-          dhInfo                  [0] DHRepInfo,
-                   -- Selected when Diffie-Hellman key exchange is
-                   -- used.
-          encKeyPack              [1] IMPLICIT OCTET STRING,
-                   -- Selected when public key encryption is used.
-                   -- Contains a CMS type ContentInfo encoded
-                   -- according to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-envelopedData (1.2.840.113549.1.7.3).
-                   -- The content field is an EnvelopedData.
-                   -- The contentType field for the type EnvelopedData
-                   -- is id-signedData (1.2.840.113549.1.7.2).
-                   -- The eContentType field for the inner type
-                   -- SignedData (when unencrypted) is
-                   -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
-                   -- eContent field contains the DER encoding of the
-                   -- type ReplyKeyPack.
-                   -- ReplyKeyPack is defined below.
-          ...
-
-
-
-Zhu & Tung                  Standards Track                    [Page 36]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-       }
-
-       DHRepInfo ::= SEQUENCE {
-          dhSignedData            [0] IMPLICIT OCTET STRING,
-                   -- Contains a CMS type ContentInfo encoded according
-                   -- to [RFC3852].
-                   -- The contentType field of the type ContentInfo is
-                   -- id-signedData (1.2.840.113549.1.7.2), and the
-                   -- content field is a SignedData.
-                   -- The eContentType field for the type SignedData is
-                   -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
-                   -- eContent field contains the DER encoding of the
-                   -- type KDCDHKeyInfo.
-                   -- KDCDHKeyInfo is defined below.
-          serverDHNonce           [1] DHNonce OPTIONAL,
-                   -- Present if and only if dhKeyExpiration is
-                   -- present.
-          ...
-       }
-
-       KDCDHKeyInfo ::= SEQUENCE {
-          subjectPublicKey        [0] BIT STRING,
-                   -- The KDC's DH public key.
-                   -- The DH public key value is encoded as a BIT
-                   -- STRING according to [RFC3279].
-          nonce                   [1] INTEGER (0..4294967295),
-                   -- Contains the nonce in the pkAuthenticator field
-                   -- in the request if the DH keys are NOT reused,
-                   -- 0 otherwise.
-          dhKeyExpiration         [2] KerberosTime OPTIONAL,
-                   -- Expiration time for KDC's key pair,
-                   -- present if and only if the DH keys are reused.
-                   -- If present, the KDC's DH public key MUST not be
-                   -- used past the point of this expiration time.
-                   -- If this field is omitted then the serverDHNonce
-                   -- field MUST also be omitted.
-          ...
-       }
-
-       ReplyKeyPack ::= SEQUENCE {
-          replyKey                [0] EncryptionKey,
-                   -- Contains the session key used to encrypt the
-                   -- enc-part field in the AS-REP, i.e., the
-                   -- AS reply key.
-          asChecksum              [1] Checksum,
-                  -- Contains the checksum of the AS-REQ
-                  -- corresponding to the containing AS-REP.
-                  -- The checksum is performed over the type AS-REQ.
-
-
-
-Zhu & Tung                  Standards Track                    [Page 37]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-                  -- The protocol key [RFC3961] of the checksum is the
-                  -- replyKey and the key usage number is 6.
-                  -- If the replyKey's enctype is "newer" [RFC4120]
-                  -- [RFC4121], the checksum is the required
-                  -- checksum operation [RFC3961] for that enctype.
-                  -- The client MUST verify this checksum upon receipt
-                  -- of the AS-REP.
-          ...
-       }
-
-       TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
-                   -- Each AlgorithmIdentifier specifies a set of
-                   -- Diffie-Hellman domain parameters [IEEE1363].
-                   -- This list is in decreasing preference order.
-       END
-
-Appendix B.  Test Vectors
-
-   Function octetstring2key() is defined in Section 3.2.3.1.  This
-   section describes a few sets of test vectors that would be useful for
-   implementers of octetstring2key().
-
-   Set 1:
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
-     75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 38]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   Set 2:
-   =====
-   Input octet string x is:
-
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
-     a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
-
-
-   Set 3:
-   ======
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
-     0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
-     0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
-     0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
-     73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
-
-
-   Set 4:
-   =====
-   Input octet string x is:
-
-     00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
-     10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
-     0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
-     0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
-     0d 0e 0f 10 00 01 02 03 04 05 06 07 08
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 39]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-   Output of K-truncate() when the key size is 32 octets:
-
-     00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
-     59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
-
-Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
-             Implementations
-
-   Earlier revisions of the PKINIT I-D were implemented in various
-   releases of Microsoft Windows and deployed in fairly large numbers.
-   To enable the community to interoperate better with systems running
-   those releases, the following information may be useful.
-
-   KDC certificates issued by Windows 2000 Enterprise CAs contain a
-   dNSName SAN with the DNS name of the host running the KDC, and the
-   id-kp-serverAuth EKU [RFC3280].
-
-   KDC certificates issued by Windows 2003 Enterprise CAs contain a
-   dNSName SAN with the DNS name of the host running the KDC, the id-
-   kp-serverAuth EKU, and the id-ms-kp-sc-logon EKU.
-
-   It is anticipated that the next release of Windows is already too far
-   along to allow it to support the issuing KDC certificates with id-
-   pkinit-san SAN as specified in this RFC.  Instead, they will have a
-   dNSName SAN containing the domain name of the KDC, and the intended
-   purpose of these KDC certificates will be restricted by the presence
-   of the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
-
-   In addition to checking that the above are present in a KDC
-   certificate, Windows clients verify that the issuer of the KDC
-   certificate is one of a set of allowed issuers of such certificates,
-   so those wishing to issue KDC certificates need to configure their
-   Windows clients appropriately.
-
-   Client certificates accepted by Windows 2000 and Windows 2003 Server
-   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
-   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
-   contains a UTF8-encoded string whose value is that of the Directory
-   Service attribute UserPrincipalName of the client account object, and
-   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
-   certificate is to validate the client mapping (in other words, the
-   client's public key is bound to the account that has this
-   UserPrincipalName value).
-
-   It should be noted that all Microsoft Kerberos realm names are
-   domain-style realm names and strictly in uppercase.  In addition, the
-   UserPrincipalName attribute is globally unique in Windows 2000 and
-   Windows 2003.
-
-
-
-Zhu & Tung                  Standards Track                    [Page 40]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: lzhu@microsoft.com
-
-
-   Brian Tung
-   Aerospace Corporation
-   2350 E. El Segundo Blvd.
-   El Segundo, CA  90245
-   US
-
-   EMail: brian@aero.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 41]
-
-RFC 4556                         PKINIT                        June 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Zhu & Tung                  Standards Track                    [Page 42]
-
diff --git a/doc/standardisation/rfc4557.txt b/doc/standardisation/rfc4557.txt
deleted file mode 100644
index fe9a8810d..000000000
--- a/doc/standardisation/rfc4557.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             L. Zhu
-Request for Comments: 4557                                 K. Jaganathan
-Category: Standards Track                          Microsoft Corporation
-                                                             N. Williams
-                                                        Sun Microsystems
-                                                               June 2006
-
-
-         Online Certificate Status Protocol (OCSP) Support for
-                      Public Key Cryptography for
-              Initial Authentication in Kerberos (PKINIT)
-
-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 (2006).
-
-Abstract
-
-   This document defines a mechanism to enable in-band transmission of
-   Online Certificate Status Protocol (OCSP) responses in the Kerberos
-   network authentication protocol.  These responses are used to verify
-   the validity of the certificates used in Public Key Cryptography for
-   Initial Authentication in Kerberos (PKINIT), which is the Kerberos
-   Version 5 extension that provides for the use of public key
-   cryptography.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Conventions Used in This Document ...............................2
-   3. Message Definition ..............................................2
-   4. Security Considerations .........................................3
-   5. Acknowledgements ................................................4
-   6. References ......................................................4
-      6.1. Normative References .......................................4
-      6.2. Informative References .....................................4
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                     [Page 1]
-
-RFC 4557                OCSP Support for PKINIT                June 2006
-
-
-1.  Introduction
-
-   Online Certificate Status Protocol (OCSP) [RFC2560] enables
-   applications to obtain timely information regarding the revocation
-   status of a certificate.  Because OCSP responses are well bounded and
-   small in size, constrained clients may wish to use OCSP to check the
-   validity of the certificates for Kerberos Key Distribution Center
-   (KDC) in order to avoid transmission of large Certificate Revocation
-   Lists (CRLs) and therefore save bandwidth on constrained networks
-   [OCSP-PROFILE].
-
-   This document defines a pre-authentication type [RFC4120], where the
-   client and the KDC MAY piggyback OCSP responses for certificates used
-   in authentication exchanges, as defined in [RFC4556].
-
-   By using this OPTIONAL extension, PKINIT clients and the KDC can
-   maximize the reuse of cached OCSP responses.
-
-2.  Conventions Used in This Document
-
-   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
-   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
-   and "OPTIONAL" are to be interpreted as described in [RFC2119].
-
-3.  Message Definition
-
-   A pre-authentication type identifier is defined for this mechanism:
-
-              PA-PK-OCSP-RESPONSE              18
-
-   The corresponding padata-value field [RFC4120] contains the DER [X60]
-   encoding of the following ASN.1 type:
-
-          PKOcspData ::= SEQUENCE OF OcspResponse
-                         -- If more than one OcspResponse is
-                         -- included, the first OcspResponse
-                         -- MUST contain the OCSP response
-                         -- for the signer's certificate.
-                         -- The signer refers to the client for
-                         -- AS-REQ, and the KDC for the AS-REP,
-                         -- respectively.
-
-          OcspResponse ::= OCTET STRING
-                         -- Contains a complete OCSP response,
-                         -- as defined in [RFC2560].
-
-   The client MAY send OCSP responses for certificates used in PA-PK-
-   AS-REQ [RFC4556] via a PA-PK-OCSP-RESPONSE.
-
-
-
-Zhu, et al.                 Standards Track                     [Page 2]
-
-RFC 4557                OCSP Support for PKINIT                June 2006
-
-
-   The KDC that receives a PA-PK-OCSP-RESPONSE SHOULD send a PA-PK-
-   OCSP-RESPONSE containing OCSP responses for certificates used in the
-   KDC's PA-PK-AS-REP.  The client can request a PA-PK-OCSP-RESPONSE by
-   using a PKOcspData containing an empty sequence.
-
-   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
-   PA-PK-OCSP-RESPONSE from the client.
-
-   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
-   certificates used in PA-PK-AS-REP [RFC4556].
-
-   Note the lack of integrity protection for the empty or missing OCSP
-   response; lack of an expected OCSP response from the KDC for the
-   KDC's certificates SHOULD be treated as an error by the client,
-   unless it is configured otherwise.
-
-   When using OCSP, the response is signed by the OCSP server, which is
-   trusted by the receiver.  Depending on local policy, further
-   verification of the validity of the OCSP servers may be needed
-
-   The client and the KDC SHOULD ignore invalid OCSP responses received
-   via this mechanism, and they MAY implement CRL processing logic as a
-   fall-back position, if the OCSP responses received via this mechanism
-   alone are not sufficient for the verification of certificate
-   validity.  The client and/or the KDC MAY ignore a valid OCSP response
-   and perform its own revocation status verification independently.
-
-4.  Security Considerations
-
-   The pre-authentication data in this document do not actually
-   authenticate any principals, but are designed to be used in
-   conjunction with PKINIT.
-
-   There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
-   data and PKINIT pre-authentication data other than a given OCSP
-   response corresponding to a certificate used in a PKINIT pre-
-   authentication data element.  Attacks involving removal or
-   replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
-   are, at worst, downgrade attacks, where a PKINIT client or KDC would
-   proceed without use of CRLs or OCSP for certificate validation, or
-   denial-of-service attacks, where a PKINIT client or KDC that cannot
-   validate the other's certificate without an accompanying OCSP
-   response might reject the AS exchange or might have to download very
-   large CRLs in order to continue.  Kerberos V does not protect against
-   denial-of-service attacks; therefore, the denial-of-service aspect of
-   these attacks is acceptable.
-
-
-
-
-
-Zhu, et al.                 Standards Track                     [Page 3]
-
-RFC 4557                OCSP Support for PKINIT                June 2006
-
-
-   If a PKINIT client or KDC cannot validate certificates without the
-   aid of a valid PA-PK-OCSP-RESPONSE, then it SHOULD fail the AS
-   exchange, possibly according to local configuration.
-
-5.  Acknowledgements
-
-   This document was based on conversations among the authors, Jeffrey
-   Altman, Sam Hartman, Martin Rex, and other members of the Kerberos
-   working group.
-
-6.  References
-
-6.1.  Normative References
-
-   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
-                  Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2560]      Myers, M., Ankney, R., Malpani, A., Galperin, S., and
-                  C. Adams, "X.509 Internet Public Key Infrastructure
-                  Online Certificate Status Protocol - OCSP", RFC 2560,
-                  June 1999.
-
-   [RFC4120]      Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-                  Kerberos Network Authentication Service (V5)", RFC
-                  4120, July 2005.
-
-   [RFC4556]      Zhu, L. and B. Tung, "Public Key Cryptography for
-                  Initial Authentication in Kerberos (PKINIT)", RFC
-                  4556, June 2006.
-
-   [X690]         ASN.1 encoding rules: Specification of Basic Encoding
-                  Rules (BER), Canonical Encoding Rules (CER) and
-                  Distinguished Encoding Rules (DER), ITU-T
-                  Recommendation X.690 (1997) | ISO/IEC International
-                  Standard 8825-1:1998.
-
-6.2.  Informative References
-
-   [OCSP-PROFILE] Deacon, A. and R. Hurst, "Lightweight OCSP Profile for
-                  High Volume Environments", Work in Progress, May 2006.
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                     [Page 4]
-
-RFC 4557                OCSP Support for PKINIT                June 2006
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: lzhu@microsoft.com
-
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: karthikj@microsoft.com
-
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                     [Page 5]
-
-RFC 4557                OCSP Support for PKINIT                June 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Zhu, et al.                 Standards Track                     [Page 6]
-
diff --git a/doc/standardisation/rfc4559.txt b/doc/standardisation/rfc4559.txt
deleted file mode 100644
index fa63f621e..000000000
--- a/doc/standardisation/rfc4559.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      K. Jaganathan
-Request for Comments: 4559                                        L. Zhu
-Category: Informational                                        J. Brezak
-                                                   Microsoft Corporation
-                                                               June 2006
-
-
-           SPNEGO-based Kerberos and NTLM HTTP Authentication
-                          in Microsoft Windows
-
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes how the Microsoft Internet Explorer (MSIE)
-   and Internet Information Services (IIS) incorporated in Microsoft
-   Windows 2000 use Kerberos for security enhancements of web
-   transactions.  The Hypertext Transport Protocol (HTTP) auth-scheme of
-   "negotiate" is defined here; when the negotiation results in the
-   selection of Kerberos, the security services of authentication and,
-   optionally, impersonation (the IIS server assumes the windows
-   identity of the principal that has been authenticated) are performed.
-   This document explains how HTTP authentication utilizes the Simple
-   and Protected GSS-API Negotiation mechanism.  Details of Simple And
-   Protected Negotiate (SPNEGO) implementation are not provided in this
-   document.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Conventions Used in This Document ...............................2
-   3. Access Authentication ...........................................2
-      3.1. Reliance on the HTTP/1.1 Specification .....................2
-   4. HTTP Negotiate Authentication Scheme ............................2
-      4.1. The WWW-Authenticate Response Header .......................2
-   5. Negotiate Operation Example .....................................4
-   6. Security Considerations .........................................5
-   7. Normative References ............................................6
-
-
-
-
-Jaganathan, et al.           Informational                      [Page 1]
-
-RFC 4559        HTTP Authentication in Microsoft Windows       June 2006
-
-
-1.  Introduction
-
-   Microsoft has provided support for Kerberos authentication in
-   Microsoft Internet Explorer (MSIE) and Internet Information Services
-   (IIS), in addition to other mechanisms.  This provides the benefits
-   of the Kerberos v5 protocol for Web applications.
-
-   Support for Kerberos authentication is based on other previously
-   defined mechanisms, such as SPNEGO Simple And Protected Negotiate
-   (SPNEGO) [RFC4178] and the Generic Security Services Application
-   Program Interface(GSSAPI).
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
-   be interpreted as described in [RFC2119].
-
-3.  Access Authentication
-
-3.1.  Reliance on the HTTP/1.1 Specification
-
-   This specification is a companion to the HTTP/1.1 specification
-   [RFC2616], and it builds on the authentication mechanisms defined in
-   [RFC2617].  It uses the augmented BNF section of that document (2.1),
-   and it relies on both the non-terminals defined in that document and
-   other aspects of the HTTP/1.1 specification.
-
-4.  HTTP Negotiate Authentication Scheme
-
-   Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate".
-   The auth-params exchanged use data formats defined for use with the
-   GSS-API [RFC2743].  In particular, they follow the formats set for
-   the SPNEGO [RFC4178] and Kerberos [RFC4121] mechanisms for GSSAPI.
-   The "Negotiate" auth-scheme calls for the use of SPNEGO GSSAPI tokens
-   that the specific mechanism type specifies.
-
-   The current implementation of this protocol is limited to the use of
-   SPNEGO with the Kerberos and Microsoft(NT Lan Manager) NTLM
-   protocols.
-
-4.1.  The WWW-Authenticate Response Header
-
-   If the server receives a request for an access-protected object, and
-   if an acceptable Authorization header has not been sent, the server
-   responds with a "401 Unauthorized" status code, and a "WWW-
-   Authenticate:" header as per the framework described in [RFC2616].
-   The initial WWW-Authenticate header will not carry any gssapi-data.
-
-
-
-Jaganathan, et al.           Informational                      [Page 2]
-
-RFC 4559        HTTP Authentication in Microsoft Windows       June 2006
-
-
-   The negotiate scheme will operate as follows:
-
-           challenge       = "Negotiate" auth-data
-           auth-data       = 1#( [gssapi-data] )
-
-   The meanings of the values of the directives used above are as
-   follows:
-
-   gssapi-data
-
-   If the gss_accept_security_context returns a token for the client,
-   this directive contains the base64 encoding of an
-   initialContextToken, as defined in [RFC2743].  This is not present in
-   the initial response from the server.
-
-   A status code 200 status response can also carry a "WWW-Authenticate"
-   response header containing the final leg of an authentication.  In
-   this case, the gssapi-data will be present.  Before using the
-   contents of the response, the gssapi-data should be processed by
-   gss_init_security_context to determine the state of the security
-   context.  If this function indicates success, the response can be
-   used by the application.  Otherwise, an appropriate action, based on
-   the authentication status, should be taken.
-
-   For example, the authentication could have failed on the final leg if
-   mutual authentication was requested and the server was not able to
-   prove its identity.  In this case, the returned results are suspect.
-   It is not always possible to mutually authenticate the server before
-   the HTTP operation.  POST methods are in this category.
-
-   When the Kerberos Version 5 GSSAPI mechanism [RFC4121] is being used,
-   the HTTP server will be using a principal name of the form of
-   "HTTP/hostname".
-
-4.2.  The Authorization Request Header
-
-   Upon receipt of the response containing a "WWW-Authenticate" header
-   from the server, the client is expected to retry the HTTP request,
-   passing a HTTP "Authorization" header line.  This is defined
-   according to the framework described in [RFC2616] and is utilized as
-   follows:
-
-           credentials             = "Negotiate" auth-data2
-           auth-data2              = 1#( gssapi-data )
-
-   gssapi-data
-
-
-
-
-
-Jaganathan, et al.           Informational                      [Page 3]
-
-RFC 4559        HTTP Authentication in Microsoft Windows       June 2006
-
-
-   This directive contains the base64 encoding of an
-   InitialContextToken, as defined in [RFC2743].
-
-   Any returned code other than a success 2xx code represents an
-   authentication error.  If a 401 containing a "WWW-Authenticate"
-   header with "Negotiate" and gssapi-data is returned from the server,
-   it is a continuation of the authentication request.
-
-   A client may initiate a connection to the server with an
-   "Authorization" header containing the initial token for the server.
-   This form will bypass the initial 401 error from the server when the
-   client knows that the server will accept the Negotiate HTTP
-   authentication type.
-
-5.  Negotiate Operation Example
-
-   The client requests an access-protected document from server via a
-   GET method request.  The URI of the document is
-   "http://www.nowhere.org/dir/index.html".
-
-           C: GET dir/index.html
-
-   The first time the client requests the document, no Authorization
-   header is sent, so the server responds with
-
-           S: HTTP/1.1 401 Unauthorized
-           S: WWW-Authenticate: Negotiate
-
-   The client will obtain the user credentials using the SPNEGO GSSAPI
-   mechanism type to identify generate a GSSAPI message to be sent to
-   the server with a new request, including the following Authorization
-   header:
-
-           C: GET dir/index.html
-           C: Authorization: Negotiate a87421000492aa874209af8bc028
-
-   The server will decode the gssapi-data and pass this to the SPNEGO
-   GSSAPI mechanism in the gss_accept_security_context function.  If the
-   context is not complete, the server will respond with a 401 status
-   code with a WWW-Authenticate header containing the gssapi-data.
-
-           S: HTTP/1.1 401 Unauthorized
-           S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356
-
-   The client will decode the gssapi-data, pass this into
-   Gss_Init_security_context, and return the new gssapi-data to the
-   server.
-
-
-
-
-Jaganathan, et al.           Informational                      [Page 4]
-
-RFC 4559        HTTP Authentication in Microsoft Windows       June 2006
-
-
-           C: GET dir/index.html
-           C: Authorization: Negotiate 89a8742aa8729a8b028
-
-   This cycle can continue until the security context is complete.  When
-   the return value from the gss_accept_security_context function
-   indicates that the security context is complete, it may supply final
-   authentication data to be returned to the client.  If the server has
-   more gssapi data to send to the client to complete the context, it is
-   to be carried in a WWW-Authenticate header with the final response
-   containing the HTTP body.
-
-           S: HTTP/1.1 200 Success
-           S: WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca
-
-   The client will decode the gssapi-data and supply it to
-   gss_init_security_context using the context for this server.  If the
-   status is successful from the final gss_init_security_context, the
-   response can be used by the application.
-
-6.  Security Considerations
-
-   The SPNEGO HTTP authentication facility is only used to provide
-   authentication of a user to a server.  It provides no facilities for
-   protecting the HTTP headers or data including the Authorization and
-   WWW-Authenticate headers that are used to implement this mechanism.
-
-   Alternate mechanisms such as TLS can be used to provide
-   confidentiality.  Hashes of the TLS certificates can be used as
-   channel bindings to secure the channel.  In this case clients would
-   need to enforce that the channel binding information is valid.  Note
-   that Kerb-TLS [RFC2712] could be used to provide both authentication
-   and confidentiality, but this requires a change to the TLS provider.
-
-   This mechanism is not used for HTTP authentication to HTTP proxies.
-
-   If an HTTP proxy is used between the client and server, it must take
-   care to not share authenticated connections between different
-   authenticated clients to the same server.  If this is not honored,
-   then the server can easily lose track of security context
-   associations.  A proxy that correctly honors client to server
-   authentication integrity will supply the "Proxy-support:  Session-
-   Based-Authentication" HTTP header to the client in HTTP responses
-   from the proxy.  The client MUST NOT utilize the SPNEGO HTTP
-   authentication mechanism through a proxy unless the proxy supplies
-   this header with the "401 Unauthorized" response from the server.
-
-
-
-
-
-
-Jaganathan, et al.           Informational                      [Page 5]
-
-RFC 4559        HTTP Authentication in Microsoft Windows       June 2006
-
-
-   When using the SPNEGO HTTP authentication facility with client-
-   supplied data such as PUT and POST, the authentication should be
-   complete between the client and server before sending the user data.
-   The return status from the gss_init_security_context will indicate
-   that the security context is complete.  At this point, the data can
-   be sent to the server.
-
-7.  Normative References
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2", 2, Update 1", 2743, January 2000.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
-              Simple and Protected GSS-API Generic Security Service
-              Application Program Interface (GSS-API) Negotiation
-              Mechanism", 4178, October 2005.
-
-   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
-              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
-              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
-   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
-              Leach, P., Luotonen, A., and L. Stewart, "HTTP
-              Authentication: Basic and Digest Access Authentication",
-              RFC 2617, June 1999.
-
-   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121, July
-              2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.           Informational                      [Page 6]
-
-RFC 4559        HTTP Authentication in Microsoft Windows       June 2006
-
-
-Authors' Addresses
-
-   Karthik Jaganathan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: karthikj@microsoft.com
-
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: lzhu@microsoft.com
-
-
-   John Brezak
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   EMail: jbrezak@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jaganathan, et al.           Informational                      [Page 7]
-
-RFC 4559        HTTP Authentication in Microsoft Windows       June 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Jaganathan, et al.           Informational                      [Page 8]
-
diff --git a/doc/standardisation/rfc5587.txt b/doc/standardisation/rfc5587.txt
deleted file mode 100644
index 1670bc58f..000000000
--- a/doc/standardisation/rfc5587.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        N. Williams
-Request for Comments: 5587                                           Sun
-Category: Standards Track                                      July 2009
-
-
-        Extended Generic Security Service Mechanism Inquiry APIs
-
-Abstract
-
-   This document introduces new application programming interfaces
-   (APIs) to the Generic Security Services API (GSS-API) for extended
-   mechanism attribute inquiry.  These interfaces are primarily intended
-   to reduce instances of hardcoding of mechanism identifiers in GSS
-   applications.
-
-   These interfaces include mechanism attributes and attribute sets, a
-   function for inquiring the attributes of a mechanism, a function for
-   indicating mechanisms that possess given attributes, and a function
-   for displaying mechanism attributes.
-
-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) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 1]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Conventions Used in This Document ...............................2
-   3. New GSS-API Interfaces ..........................................3
-      3.1. Mechanism Attributes and Attribute Sets ....................3
-      3.2. List of Known Mechanism Attributes .........................4
-      3.3. Mechanism Attribute Sets of Existing Mechs .................6
-      3.4. New GSS-API Function Interfaces ............................8
-           3.4.1. Mechanism Attribute Criticality .....................8
-           3.4.2. GSS_Indicate_mechs_by_attrs() .......................9
-           3.4.3. GSS_Inquire_attrs_for_mech() .......................10
-           3.4.4. GSS_Display_mech_attr() ............................10
-           3.4.5. New Major Status Values ............................11
-           3.4.6. C-Bindings .........................................11
-   4. Requirements for Mechanism Designers ...........................13
-   5. IANA Considerations ............................................13
-   6. Security Considerations ........................................13
-   7. References .....................................................13
-      7.1. Normative References ......................................13
-      7.2. Informative References ....................................14
-Appendix A. Typedefs and C Bindings ..................................15
-
-1.  Introduction
-
-   GSS-API [RFC2743] mechanisms have a number of properties that may be
-   of interest to applications.  The lack of APIs for inquiring about
-   available mechanisms' properties has meant that many GSS-API
-   applications must hardcode mechanism Object Identifiers (OIDs).
-   Ongoing work may result in a variety of new GSS-API mechanisms.
-   Applications should not have to hardcode their OIDs.
-
-   For example, the Secure Shell version 2 (SSHv2) protocol [RFC4251]
-   supports the use of GSS-API mechanisms for authentication [RFC4462]
-   but explicitly prohibits the use of Simple and Protected GSS-API
-   Negotiation (SPNEGO) [RFC4178].  Future mechanisms that negotiate
-   mechanisms would have to be forbidden as well, but there is no way to
-   implement applications that inquire what mechanisms are available and
-   then programmatically exclude mechanisms "like SPNEGO".
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 2]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-3.  New GSS-API Interfaces
-
-   We introduce a new concept -- that of mechanism attributes.  By
-   allowing applications to query the set of attributes associated with
-   individual mechanisms and to find out which mechanisms support a
-   given set of attributes, we allow applications to select mechanisms
-   based on their attributes without having to hardcode mechanism OIDs.
-
-   Section 3.1 describes the mechanism attributes concept.  Sections
-   3.4.2, 3.4.3, and 3.4.4 describe three new interfaces that deal in
-   mechanisms and attribute sets:
-
-   o  GSS_Indicate_mechs_by_attrs()
-
-   o  GSS_Inquire_attrs_for_mech()
-
-   o  GSS_Display_mech_attr()
-
-3.1.  Mechanism Attributes and Attribute Sets
-
-   An abstraction for the features provided by mechanisms and pseudo-
-   mechanisms is needed in order to facilitate the programmatic
-   selection of mechanisms.  Pseudo-mechanisms are mechanisms that make
-   reference to other mechanisms in order to provide their services.
-   For example, SPNEGO is a pseudo-mechanism, for without other
-   mechanisms SPNEGO is useless.
-
-   Two data types are needed: one for individual mechanism attributes
-   and one for mechanism attribute sets.  To simplify the mechanism
-   attribute interfaces, we reuse the 'OID' and 'OID set' data types and
-   model individual mechanism attribute types as OIDs.
-
-   To this end, we define an open namespace of mechanism attributes and
-   assign them arcs off of this OID:
-
-   <1.3.6.1.5.5.13>
-
-   Each mechanism has a set of mechanism attributes that it supports as
-   described in its specification.
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 3]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-3.2.  List of Known Mechanism Attributes
-
-      +-------------------------+---------+-------------------------+
-      | Mech Attr Name          | OID Arc | Arc Name                |
-      +-------------------------+---------+-------------------------+
-      | GSS_C_MA_MECH_CONCRETE  |     (1) | concrete-mech           |
-      | GSS_C_MA_MECH_PSEUDO    |     (2) | pseudo-mech             |
-      | GSS_C_MA_MECH_COMPOSITE |     (3) | composite-mech          |
-      | GSS_C_MA_MECH_NEGO      |     (4) | mech-negotiation-mech   |
-      | GSS_C_MA_MECH_GLUE      |     (5) | mech-glue               |
-      | GSS_C_MA_NOT_MECH       |     (6) | not-mech                |
-      | GSS_C_MA_DEPRECATED     |     (7) | mech-deprecated         |
-      | GSS_C_MA_NOT_DFLT_MECH  |     (8) | mech-not-default        |
-      | GSS_C_MA_ITOK_FRAMED    |     (9) | initial-is-framed       |
-      | GSS_C_MA_AUTH_INIT      |    (10) | auth-init-princ         |
-      | GSS_C_MA_AUTH_TARG      |    (11) | auth-targ-princ         |
-      | GSS_C_MA_AUTH_INIT_INIT |    (12) | auth-init-princ-initial |
-      | GSS_C_MA_AUTH_TARG_INIT |    (13) | auth-targ-princ-initial |
-      | GSS_C_MA_AUTH_INIT_ANON |    (14) | auth-init-princ-anon    |
-      | GSS_C_MA_AUTH_TARG_ANON |    (15) | auth-targ-princ-anon    |
-      | GSS_C_MA_DELEG_CRED     |    (16) | deleg-cred              |
-      | GSS_C_MA_INTEG_PROT     |    (17) | integ-prot              |
-      | GSS_C_MA_CONF_PROT      |    (18) | conf-prot               |
-      | GSS_C_MA_MIC            |    (19) | mic                     |
-      | GSS_C_MA_WRAP           |    (20) | wrap                    |
-      | GSS_C_MA_PROT_READY     |    (21) | prot-ready              |
-      | GSS_C_MA_REPLAY_DET     |    (22) | replay-detection        |
-      | GSS_C_MA_OOS_DET        |    (23) | oos-detection           |
-      | GSS_C_MA_CBINDINGS      |    (24) | channel-bindings        |
-      | GSS_C_MA_PFS            |    (25) | pfs                     |
-      | GSS_C_MA_COMPRESS       |    (26) | compress                |
-      | GSS_C_MA_CTX_TRANS      |    (27) | context-transfer        |
-      | <reserved>              | (28...) |                         |
-      +-------------------------+---------+-------------------------+
-
-                                  Table 1
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 4]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-   +-------------------------+-----------------------------------------+
-   | Mech Attr Name          | Purpose                                 |
-   +-------------------------+-----------------------------------------+
-   | GSS_C_MA_MECH_CONCRETE  | Indicates that a mech is neither a      |
-   |                         | pseudo-mechanism nor a composite        |
-   |                         | mechanism.                              |
-   | GSS_C_MA_MECH_PSEUDO    | Indicates that a mech is a              |
-   |                         | pseudo-mechanism.                       |
-   | GSS_C_MA_MECH_COMPOSITE | Indicates that a mech is a composite of |
-   |                         | other mechanisms.  This is reserved for |
-   |                         | a specification of "stackable"          |
-   |                         | pseudo-mechanisms.                      |
-   | GSS_C_MA_MECH_NEGO      | Indicates that a mech negotiates other  |
-   |                         | mechs (e.g., SPNEGO has this            |
-   |                         | attribute).                             |
-   | GSS_C_MA_MECH_GLUE      | Indicates that the OID is not for a     |
-   |                         | mechanism but for the GSS-API itself.   |
-   | GSS_C_MA_NOT_MECH       | Indicates that the OID is known, yet it |
-   |                         | is also known not to be the OID of any  |
-   |                         | GSS-API mechanism (or of the GSS-API    |
-   |                         | itself).                                |
-   | GSS_C_MA_DEPRECATED     | Indicates that a mech (or its OID) is   |
-   |                         | deprecated and MUST NOT be used as a    |
-   |                         | default mechanism.                      |
-   | GSS_C_MA_NOT_DFLT_MECH  | Indicates that a mech (or its OID) MUST |
-   |                         | NOT be used as a default mechanism.     |
-   | GSS_C_MA_ITOK_FRAMED    | Indicates that the given mechanism's    |
-   |                         | initial context tokens are properly     |
-   |                         | framed as per Section 3.1 of [RFC2743]. |
-   | GSS_C_MA_AUTH_INIT      | Indicates support for authentication of |
-   |                         | initiator to acceptor.                  |
-   | GSS_C_MA_AUTH_TARG      | Indicates support for authentication of |
-   |                         | acceptor to initiator.                  |
-   | GSS_C_MA_AUTH_INIT_INIT | Indicates support for "initial"         |
-   |                         | authentication of initiator to          |
-   |                         | acceptor.  "Initial authentication"     |
-   |                         | refers to the use of passwords, or keys |
-   |                         | stored on tokens, for authentication.   |
-   |                         | Whether a mechanism supports initial    |
-   |                         | authentication may depend on IETF       |
-   |                         | consensus (see Security                 |
-   |                         | Considerations).                        |
-   | GSS_C_MA_AUTH_TARG_INIT | Indicates support for initial           |
-   |                         | authentication of acceptor to           |
-   |                         | initiator.                              |
-   | GSS_C_MA_AUTH_INIT_ANON | Indicates support for                   |
-   |                         | GSS_C_NT_ANONYMOUS as an initiator      |
-   |                         | principal name.                         |
-
-
-
-Williams                    Standards Track                     [Page 5]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-   | GSS_C_MA_AUTH_TARG_ANON | Indicates support for                   |
-   |                         | GSS_C_NT_ANONYMOUS as a target          |
-   |                         | principal name.                         |
-   | GSS_C_MA_DELEG_CRED     | Indicates support for credential        |
-   |                         | delegation.                             |
-   | GSS_C_MA_INTEG_PROT     | Indicates support for per-message       |
-   |                         | integrity protection.                   |
-   | GSS_C_MA_CONF_PROT      | Indicates support for per-message       |
-   |                         | confidentiality protection.             |
-   | GSS_C_MA_MIC            | Indicates support for Message Integrity |
-   |                         | Code (MIC) tokens.                      |
-   | GSS_C_MA_WRAP           | Indicates support for WRAP tokens.      |
-   | GSS_C_MA_PROT_READY     | Indicates support for per-message       |
-   |                         | protection prior to full context        |
-   |                         | establishment.                          |
-   | GSS_C_MA_REPLAY_DET     | Indicates support for replay detection. |
-   | GSS_C_MA_OOS_DET        | Indicates support for out-of-sequence   |
-   |                         | detection.                              |
-   | GSS_C_MA_CBINDINGS      | Indicates support for channel bindings. |
-   | GSS_C_MA_PFS            | Indicates support for Perfect Forward   |
-   |                         | Security.                               |
-   | GSS_C_MA_COMPRESS       | Indicates support for compression of    |
-   |                         | data inputs to GSS_Wrap().              |
-   | GSS_C_MA_CTX_TRANS      | Indicates support for security context  |
-   |                         | export/import.                          |
-   +-------------------------+-----------------------------------------+
-
-                                  Table 2
-
-3.3.  Mechanism Attribute Sets of Existing Mechs
-
-   The Kerberos V mechanism [RFC1964] provides the following mechanism
-   attributes:
-
-   o  GSS_C_MA_MECH_CONCRETE
-
-   o  GSS_C_MA_ITOK_FRAMED
-
-   o  GSS_C_MA_AUTH_INIT
-
-   o  GSS_C_MA_AUTH_TARG
-
-   o  GSS_C_MA_DELEG_CRED
-
-   o  GSS_C_MA_INTEG_PROT
-
-   o  GSS_C_MA_CONF_PROT
-
-
-
-
-Williams                    Standards Track                     [Page 6]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-   o  GSS_C_MA_MIC
-
-   o  GSS_C_MA_WRAP
-
-   o  GSS_C_MA_PROT_READY
-
-   o  GSS_C_MA_REPLAY_DET
-
-   o  GSS_C_MA_OOS_DET
-
-   o  GSS_C_MA_CBINDINGS
-
-   o  GSS_C_MA_CTX_TRANS (some implementations, using implementation-
-      specific exported context token formats)
-
-   The Kerberos V mechanism also has a deprecated OID that has the same
-   mechanism attributes as above as well as GSS_C_MA_DEPRECATED.
-
-   The mechanism attributes of the Simple Public-Key GSS-API Mechanism
-   (SPKM) [RFC2025] family of mechanisms will be provided in a separate
-   document, as SPKM is currently being reviewed for possibly
-   significant changes due to problems in its specifications.
-
-   The Low Infrastructure Public Key (LIPKEY) mechanism [RFC2847] offers
-   the following attributes:
-
-   o  GSS_C_MA_MECH_CONCRETE
-
-   o  GSS_C_MA_ITOK_FRAMED
-
-   o  GSS_C_MA_AUTH_INIT_INIT
-
-   o  GSS_C_MA_AUTH_TARG (from SPKM-3)
-
-   o  GSS_C_MA_AUTH_TARG_ANON (from SPKM-3)
-
-   o  GSS_C_MA_INTEG_PROT
-
-   o  GSS_C_MA_CONF_PROT
-
-   o  GSS_C_MA_REPLAY_DET
-
-   o  GSS_C_MA_OOS_DET
-
-   o  GSS_C_MA_CTX_TRANS (some implementations, using implementation-
-      specific exported context token formats)
-
-
-
-
-
-Williams                    Standards Track                     [Page 7]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-      (LIPKEY should also provide GSS_C_MA_CBINDINGS, but SPKM-3
-      requires clarifications on this point.)
-
-   The SPNEGO mechanism [RFC4178] provides the following attributes:
-
-   o  GSS_C_MA_MECH_NEGO
-
-   o  GSS_C_MA_ITOK_FRAMED
-
-   All other mechanisms' attributes will be described elsewhere.
-
-3.4.  New GSS-API Function Interfaces
-
-   Several new interfaces are given by which, for example, GSS-API
-   applications may determine what features are provided by a given
-   mechanism and what mechanisms provide what features.
-
-   These new interfaces are all OPTIONAL.
-
-   Applications should use GSS_Indicate_mechs_by_attrs() instead of
-   GSS_Indicate_mechs() wherever possible.
-
-   Applications can use GSS_Indicate_mechs_by_attrs() to determine what,
-   if any, mechanisms provide a given set of features.
-
-   GSS_Indicate_mechs_by_attrs() can also be used to indicate (as in
-   GSS_Indicate_mechs()) the set of available mechanisms of each type
-   (concrete, mechanism negotiation pseudo-mechanism, etc.).
-
-3.4.1.  Mechanism Attribute Criticality
-
-   Mechanism attributes may be added at any time.  Not only may
-   attributes be added to the list of known mechanism attributes at any
-   time, but the set of mechanism attributes supported by a mechanism
-   can be changed at any time.
-
-   For example, new attributes might be added to reflect whether a
-   mechanism's initiator must contact an online infrastructure and/or
-   whether the acceptor must do so.  In this example, the Kerberos V
-   mechanism would gain a new attribute even though the mechanism itself
-   is not modified.
-
-   Applications making use of attributes not defined herein would then
-   have no way of knowing whether a GSS-API implementation and its
-   mechanisms know about new mechanism attributes.  To address this
-   problem, GSS_Indicate_mechs_by_attrs() and
-   GSS_Inquire_attrs_for_mech() support a notion of critical mechanism
-   attributes.  Applications can search for mechanisms that understand
-
-
-
-Williams                    Standards Track                     [Page 8]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-   mechanism attributes that are critical to the application, and the
-   application may ask what mechanism attributes are understood by a
-   given mechanism.
-
-3.4.2.  GSS_Indicate_mechs_by_attrs()
-
-   Inputs:
-
-   o  desired_mech_attrs SET OF OBJECT IDENTIFIER -- set of GSS_C_MA_*
-      OIDs that the mechanisms indicated in the mechs output parameter
-      MUST offer.
-
-   o  except_mech_attrs SET OF OBJECT IDENTIFIER -- set of GSS_C_MA_*
-      OIDs that the mechanisms indicated in the mechs output parameter
-      MUST NOT offer.
-
-   o  critical_mech_attrs SET OF OBJECT IDENTIFIER -- set of GSS_C_MA_*
-      OIDs that the mechanisms indicated in the mechs output parameter
-      MUST understand (i.e., mechs must know whether critical attributes
-      are or are not supported).
-
-   Outputs:
-
-   o  major_status INTEGER
-
-   o  minor_status INTEGER
-
-   o  mechs SET OF OBJECT IDENTIFIER -- set of mechanisms that support
-      the given desired_mech_attrs but not the except_mech_attrs, and
-      all of which understand the given critical_mech_attrs (the caller
-      must release this output with GSS_Release_oid_set()).
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates success; the output mechs parameter MAY
-      be the empty set (GSS_C_NO_OID_SET).
-
-   o  GSS_S_FAILURE indicates that the request failed for some other
-      reason.
-
-   GSS_Indicate_mechs_by_attrs() returns the set of OIDs corresponding
-   to mechanisms that offer at least the desired_mech_attrs but none of
-   the except_mech_attrs, and that understand all of the attributes
-   listed in critical_mech_attrs.
-
-   When all three sets of OID input parameters are the empty set, this
-   function acts as a version of GSS_indicate_mechs() that outputs the
-   set of all supported mechanisms.
-
-
-
-Williams                    Standards Track                     [Page 9]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-3.4.3.  GSS_Inquire_attrs_for_mech()
-
-   Inputs:
-
-   o  mech OBJECT IDENTIFIER -- mechanism OID
-
-   Outputs:
-
-   o  major_status INTEGER
-
-   o  minor_status INTEGER
-
-   o  mech_attrs SET OF OBJECT IDENTIFIER -- set of mech_attrs OIDs
-      (GSS_C_MA_*) supported by the mechanism (the caller must release
-      this output with GSS_Release_oid_set()).
-
-   o  known_mech_attrs SET OF OBJECT IDENTIFIER -- set of mech_attrs
-      OIDs known to the mechanism implementation (the caller must
-      release this output with GSS_Release_oid_set()).
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates success; the output mech_attrs parameter
-      MAY be the empty set (GSS_C_NO_OID_SET).
-
-   o  GSS_S_BAD_MECH indicates that the mechanism named by the mech
-      parameter does not exist or that the mech is GSS_C_NO_OID and no
-      default mechanism could be determined.
-
-   o  GSS_S_FAILURE indicates that the request failed for some other
-      reason.
-
-   GSS_Inquire_attrs_for_mech() indicates the set of mechanism
-   attributes supported by a given mechanism.
-
-3.4.4.  GSS_Display_mech_attr()
-
-   Inputs:
-
-   o  mech_attr OBJECT IDENTIFIER -- mechanism attribute OID
-
-   Outputs:
-
-   o  major_status INTEGER
-
-   o  minor_status INTEGER
-
-
-
-
-
-Williams                    Standards Track                    [Page 10]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-   o  name OCTET STRING, -- name of mechanism attribute (e.g.,
-      GSS_C_MA_*).
-
-   o  short_desc OCTET STRING, -- a short description of the mechanism
-      attribute (the caller must release this output with
-      GSS_Release_buffer()).
-
-   o  long_desc OCTET STRING -- a longer description of the mechanism
-      attribute (the caller must release this output with
-      GSS_Release_buffer()).
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates success.
-
-   o  GSS_S_BAD_MECH_ATTR indicates that the mechanism attribute
-      referenced by the mech_attr parameter is unknown to the
-      implementation.
-
-   o  GSS_S_FAILURE indicates that the request failed for some other
-      reason.
-
-   This function can be used to obtain human-readable descriptions of
-   GSS-API mechanism attributes.
-
-3.4.5.  New Major Status Values
-
-   A single, new, major status code is added for
-   GSS_Display_mech_attr():
-
-   o  GSS_S_BAD_MECH_ATTR,
-
-   roughly corresponding to GSS_S_BAD_MECH but applicable to mechanism
-   attribute OIDs rather than to mechanism OIDs.
-
-   For the C-bindings of the GSS-API [RFC2744], GSS_S_BAD_MECH_ATTR
-   shall have a routine error number of 19 (this is shifted to the left
-   by GSS_C_ROUTINE_ERROR_OFFSET).
-
-3.4.6.  C-Bindings
-
-   Note that there is a bug in the C bindings of the GSS-APIv2u1
-   [RFC2744] in that the C 'const' attribute is applied to types that
-   are pointer typedefs.  This is a bug because it declares that the
-   pointer argument is 'const' rather than that the object pointed by it
-   is const.  To avoid this error, we hereby define new typedefs, which
-   include const properly:
-
-
-
-
-Williams                    Standards Track                    [Page 11]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-      typedef const gss_buffer_desc * gss_const_buffer_t;
-      typedef const struct gss_channel_bindings_struct *
-         gss_const_channel_bindings_t;
-      typedef const <platform-specific> gss_const_ctx_id_t;
-      typedef const <platform-specific> gss_const_cred_id_t;
-      typedef const <platform-specific> gss_const_name_t;
-      typedef const gss_OID_desc * gss_const_OID;
-      typedef const gss_OID_set_desc * gss_const_OID_set;
-
-                         Figure 1: const typedefs
-
-   Note that only gss_const_OID and gss_const_OID_set are used below.
-   We include the other const typedefs for convenience since the C
-   bindings of the GSS-API do use const with pointer typedefs when it
-   should often instead use the above typedefs instead.
-
-      #define GSS_S_BAD_MECH_ATTR (19ul << GSS_C_ROUTINE_ERROR_OFFSET)
-
-      OM_uint32 gss_indicate_mechs_by_attrs(
-         OM_uint32         *minor_status,
-         gss_const_OID_set  desired_mech_attrs,
-         gss_const_OID_set  except_mech_attrs,
-         gss_const_OID_set  critical_mech_attrs,
-         gss_OID_set       *mechs);
-
-      OM_uint32 gss_inquire_attrs_for_mech(
-         OM_uint32         *minor_status,
-         gss_const_OID      mech,
-         gss_OID_set       *mech_attrs,
-         gss_OID_set       *known_mech_attrs);
-
-      OM_uint32 gss_display_mech_attr(
-         OM_uint32         *minor_status,
-         gss_const_OID      mech_attr,
-         gss_buffer_t       name,
-         gss_buffer_t       short_desc,
-         gss_buffer_t       long_desc);
-
-                           Figure 2: C bindings
-
-   Note that output buffers must be released via gss_release_buffer().
-   Output OID sets must be released via gss_release_oid_set().
-
-   Please see Appendix A for a full set of typedef fragments defined in
-   this document and the necessary code license.
-
-
-
-
-
-
-Williams                    Standards Track                    [Page 12]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-4.  Requirements for Mechanism Designers
-
-   All future GSS-API mechanism specifications MUST:
-
-   o  list the set of GSS-API mechanism attributes associated with them.
-
-5.  IANA Considerations
-
-   The namespace of programming-language symbols with names beginning
-   with GSS_C_MA_* is reserved for allocation by IETF Consensus.  IANA
-   allocated a base OID, as an arc of 1.3.6.1.5.5, for the set of
-   GSS_C_MA_* described herein, and registered all of the GSS_C_MA_*
-   values described in Section 3.2.
-
-6.  Security Considerations
-
-   This document specifies extensions to a security-related API.  It
-   imposes new requirements on future GSS-API mechanisms, and the
-   specifications of future protocols that use the GSS-API should make
-   reference to this document where applicable.  The ability to inquire
-   about specific properties of mechanisms should improve security.
-
-   The semantics of each mechanism attribute may include a security
-   component.
-
-   Application developers must understand that mechanism attributes may
-   be added at any time -- both to the set of known mechanism attributes
-   as well as to existing mechanisms' sets of supported mechanism
-   attributes.  Therefore, application developers using the APIs
-   described herein must understand what mechanism attributes their
-   applications depend critically on, and must use the mechanism
-   attribute criticality features of these APIs.
-
-7.  References
-
-7.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-
-
-
-
-
-Williams                    Standards Track                    [Page 13]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-7.2.  Informative References
-
-   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
-              RFC 1964, June 1996.
-
-   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
-              (SPKM)", RFC 2025, October 1996.
-
-   [RFC2847]  Eisler, M., "LIPKEY - A Low Infrastructure Public Key
-              Mechanism Using SPKM", RFC 2847, June 2000.
-
-   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
-              Simple and Protected Generic Security Service Application
-              Program Interface (GSS-API) Negotiation Mechanism",
-              RFC 4178, October 2005.
-
-   [RFC4251]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
-              Protocol Architecture", RFC 4251, January 2006.
-
-   [RFC4462]  Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
-              "Generic Security Service Application Program Interface
-              (GSS-API) Authentication and Key Exchange for the Secure
-              Shell (SSH) Protocol", RFC 4462, May 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                    Standards Track                    [Page 14]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-Appendix A.  Typedefs and C Bindings
-
-   This appendix contains the full set of code fragments defined in this
-   document.
-
-   Copyright (c) 2009 IETF Trust and the persons identified as authors
-   of the code.  All rights reserved.
-
-   Redistribution and use in source and binary forms, with or without
-   modification, are permitted provided that the following conditions
-   are met:
-
-   - Redistributions of source code must retain the above copyright
-     notice, this list of conditions and the following disclaimer.
-
-   - Redistributions in binary form must reproduce the above copyright
-     notice, this list of conditions and the following disclaimer in the
-     documentation and/or other materials provided with the
-     distribution.
-
-   - Neither the name of Internet Society, IETF or IETF Trust, nor the
-     names of specific contributors, may be used to endorse or promote
-     products derived from this software without specific prior written
-     permission.
-
-   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-   A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
-   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-   typedef const gss_buffer_desc * gss_const_buffer_t;
-   typedef const struct gss_channel_bindings_struct *
-      gss_const_channel_bindings_t;
-   typedef const <platform-specific> gss_const_ctx_id_t;
-   typedef const <platform-specific> gss_const_cred_id_t;
-   typedef const <platform-specific> gss_const_name_t;
-   typedef const gss_OID_desc * gss_const_OID;
-   typedef const gss_OID_set_desc * gss_const_OID_set;
-
-
-
-
-
-
-
-Williams                    Standards Track                    [Page 15]
-
-RFC 5587               Extended GSS Mech Inquiry               July 2009
-
-
-   #define GSS_S_BAD_MECH_ATTR (19ul << GSS_C_ROUTINE_ERROR_OFFSET)
-
-   OM_uint32 gss_indicate_mechs_by_attrs(
-      OM_uint32         *minor_status,
-      gss_const_OID_set  desired_mech_attrs,
-      gss_const_OID_set  except_mech_attrs,
-      gss_const_OID_set  critical_mech_attrs,
-      gss_OID_set       *mechs);
-
-   OM_uint32 gss_inquire_attrs_for_mech(
-      OM_uint32         *minor_status,
-      gss_const_OID      mech,
-      gss_OID_set       *mech_attrs,
-      gss_OID_set       *known_mech_attrs);
-
-   OM_uint32 gss_display_mech_attr(
-      OM_uint32         *minor_status,
-      gss_const_OID      mech_attr,
-      gss_buffer_t       name,
-      gss_buffer_t       short_desc,
-      gss_buffer_t       long_desc);
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                    Standards Track                    [Page 16]
-
diff --git a/doc/standardisation/rfc5588.txt b/doc/standardisation/rfc5588.txt
deleted file mode 100644
index ee2a13ecf..000000000
--- a/doc/standardisation/rfc5588.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        N. Williams
-Request for Comments: 5588                                           Sun
-Category: Standards Track                                      July 2009
-
-
-   Generic Security Service Application Program Interface (GSS-API)
-              Extension for Storing Delegated Credentials
-
-Abstract
-
-   This document defines a new function for the Generic Security Service
-   Application Program Interface (GSS-API), which allows applications to
-   store delegated (and other) credentials in the implicit GSS-API
-   credential store.  This is needed for GSS-API applications to use
-   delegated credentials as they would use other credentials.
-
-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) 2009 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents in effect on the date of
-   publication of this document (http://trustee.ietf.org/license-info).
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Conventions Used in This Document ...............................3
-   3. GSS_Store_cred() ................................................3
-   4. C-Bindings ......................................................5
-   5. Examples ........................................................6
-   6. Security Considerations .........................................6
-   7. Normative References ............................................7
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 1]
-
-RFC 5588                    GSS_Store_cred()                   July 2009
-
-
-1.  Introduction
-
-   The GSS-API [RFC2743] clearly assumes that credentials exist in an
-   implicit store whence they can be acquired using GSS_Acquire_cred()
-   and GSS_Add_cred() or through use of the default credential.
-   Multiple credential stores may exist on a given host, but only one
-   store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
-   given time.
-
-   This assumption can be seen in Sections 1.1.1.2 and 1.1.1.3 of
-   [RFC2743] as well as in Section 3.5 of [RFC2744].
-
-   Applications may be able to change the credential store from which
-   credentials can be acquired, either by changing user contexts (where
-   the applications have the privilege to do so) or by other means
-   (where a user may have multiple credential stores).
-
-   Some GSS-API acceptor applications always change user contexts, after
-   accepting a GSS-API security context and making appropriate
-   authorization checks, to the user context corresponding to the
-   initiator principal name or to a context requested by the initiator.
-   The means by which credential stores are managed are generally beyond
-   the scope of the GSS-API.
-
-   In the case of delegated credential handles however, such credentials
-   do not exist in the acceptor's credential store or in the credential
-   stores of the user contexts to which the acceptor application might
-   change.  The GSS-API provides no mechanism by which delegated
-   credential handles can be made available for acquisition through
-   GSS_Acquire_cred()/GSS_Add_cred().  The GSS-API also does not provide
-   any credential import/export interfaces like the GSS-API context
-   import/export interfaces.
-
-   Thus, acceptors are limited to making only direct use of delegated
-   credential handles and only with GSS_Init_sec_context(),
-   GSS_Inquire_cred*(), and GSS_Release_cred().  This limitation is
-   particularly onerous on Unix systems where a call to exec() to
-   replace the process image obliterates any delegated credentials
-   handle that may exist in that process.
-
-   In order to make delegated credentials generally as useful as
-   credentials that can be acquired with GSS_Acquire_cred() and
-   GSS_Add_cred(), a primitive is needed that allows storing of
-   credentials in the implicit credential store.  We call this primitive
-   "GSS_Store_cred()".
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 2]
-
-RFC 5588                    GSS_Store_cred()                   July 2009
-
-
-2.  Conventions Used in This Document
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC2119].
-
-3.  GSS_Store_cred()
-
-   Inputs:
-
-   o  input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
-      NOT be GSS_C_NO_CREDENTIAL.
-
-   o  cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
-      2=ACCEPT-ONLY.
-
-   o  desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID, then
-      store all the elements of the input_cred_handle, otherwise, store
-      only the element of the corresponding mechanism.
-
-   o  overwrite_cred BOOLEAN, -- if TRUE, replace any credential for the
-      same principal in the credential store.
-
-   o  default_cred BOOLEAN -- advisory input; if TRUE, make the stored
-      credential available as the default credential (for acquisition
-      with GSS_C_NO_NAME as the desired name or for use as
-      GSS_C_NO_CREDENTIAL).
-
-   Outputs:
-
-   o  major_status INTEGER.
-
-   o  minor_status INTEGER.
-
-   o  mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
-      mechanism OIDs for which credential elements were successfully
-      stored.
-
-   o  cred_usage_stored INTEGER -- like cred_usage, but indicates what
-      kind of credential was stored (useful when the cred_usage input
-      parameter is set to INITIATE-AND-ACCEPT).
-
-   Return major_status codes:
-
-   o  GSS_S_COMPLETE indicates that the credentials were successfully
-      stored.
-
-
-
-
-
-Williams                    Standards Track                     [Page 3]
-
-RFC 5588                    GSS_Store_cred()                   July 2009
-
-
-   o  GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had
-      expired or expired before they could be stored.
-
-   o  GSS_S_NO_CRED indicates that no input credentials were given.
-
-   o  GSS_S_UNAVAILABLE indicates that the credential store is not
-      available.
-
-   o  GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
-      credential could not be stored because a credential for the same
-      principal exists in the current credential store and the
-      overwrite_cred input argument was FALSE.
-
-   o  GSS_S_FAILURE indicates that the credential could not be stored
-      for some other reason.  The minor status code may provide more
-      information if a non-GSS_C_NULL_OID desired_mech_element was
-      given.
-
-   GSS_Store_cred() is used to store, in the current credential store, a
-   given credential that has either been acquired from a different
-   credential store or been accepted as a delegated credential.
-
-   Specific mechanism elements of a credential can be stored one at a
-   time by specifying a non-GSS_C_NULL_OID mechanism OID as the
-   desired_mech_element input argument; in which case, the minor status
-   output SHOULD have a mechanism-specific value when the major status
-   is not GSS_S_COMPLETE.
-
-   The initiator, acceptor, or both usages of the input credential may
-   be stored as per the cred_usage input argument.
-
-   The credential elements that were actually stored, when the major
-   status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
-   and mech_elements_stored function outputs.
-
-   If credentials already exist in the current store for the principal
-   of the input_cred_handle, then those credentials are not replaced
-   with the input credentials unless the overwrite_cred input argument
-   is TRUE.
-
-   In the GSS-API, the default credential can be used by using
-   GSS_C_NO_CREDENTIAL or a CREDENTIAL handle acquired by calling
-   GSS_Acquire_cred() or GSS_Add_cred() with the desired_name input set
-   to GSS_C_NO_NAME.
-
-   If the default_cred input argument is TRUE, and the input credential
-   can be successfully stored, then the input credential SHOULD be
-   stored as the default credential (see above).
-
-
-
-Williams                    Standards Track                     [Page 4]
-
-RFC 5588                    GSS_Store_cred()                   July 2009
-
-
-   If the current credential store has no default credential (see
-   above), then the implementation MAY make the stored credentials
-   available as the default credential regardless of the value of the
-   default_cred input argument.
-
-4.  C-Bindings
-
-   The C-Bindings for GSS_Store_cred() make use of types from and are
-   designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
-
-         OM_uint32 gss_store_cred(
-            OM_uint32         *minor_status,
-            gss_cred_id_t     input_cred_handle,
-            gss_cred_usage_t  cred_usage,
-            const gss_OID     desired_mech,
-            OM_uint32         overwrite_cred,
-            OM_uint32         default_cred,
-            gss_OID_set       *elements_stored,
-            gss_cred_usage_t  *cred_usage_stored)
-
-                        Figure 1
-
-   The two boolean arguments, 'overwrite_cred' and 'default_cred', are
-   typed as OM_uint32; 0 corresponds to FALSE, non-zero values
-   correspond to TRUE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 5]
-
-RFC 5588                    GSS_Store_cred()                   July 2009
-
-
-5.  Examples
-
-   The intended usage of GSS_Store_cred() is to make delegated
-   credentials available to child processes of GSS-API acceptor
-   applications.  Example pseudo-code:
-
-      /*
-       * <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE,
-       * an initiator name (hereafter, "src_name") and a delegated
-       * credential handle (hereafter "deleg_cred").>
-       *
-       * <"requested_username" is a username derived from the
-       * initiator name or explicitly requested by the initiator
-       * application.>
-       */
-      ...
-
-      if (authorize_gss_client(src_name, requested_username)) {
-         /*
-          * For Unix-type platforms this may mean calling setuid() and
-          * it may or may not also mean setting/unsetting such
-          * environment variables as KRB5CCNAME and what not -- all
-          * OS-specific details.
-          */
-         if (change_user_context(requested_username))
-            (void) gss_store_cred(&minor_status, deleg_cred,
-                                  GSS_C_INITIATE, actual_mech,
-                                  0, 1, NULL, NULL);
-         }
-         else ...
-      }
-      else ...
-
-6.  Security Considerations
-
-   Acceptor applications MUST only store delegated credentials into
-   appropriate credential stores and only after proper authorization of
-   the authenticated initiator principal to the requested service(s).
-
-   Acceptor applications that have no use for delegated credentials MUST
-   release them (such acceptor applications that use the GSS-API C-
-   Bindings may simply provide a NULL value for the
-   delegated_cred_handle argument to gss_accept_sec_context()).
-
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 6]
-
-RFC 5588                    GSS_Store_cred()                   July 2009
-
-
-7.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
-              C-bindings", RFC 2744, January 2000.
-
-Author's Address
-
-   Nicolas Williams
-   Sun Microsystems
-   5300 Riata Trace Ct
-   Austin, TX  78727
-   US
-
-   EMail: Nicolas.Williams@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                    Standards Track                     [Page 7]
-
diff --git a/lib/wind/rfc3454.txt b/lib/wind/rfc3454.txt
index 26a1e6c74..5bef0b55c 100644
--- a/lib/wind/rfc3454.txt
+++ b/lib/wind/rfc3454.txt
@@ -1,5037 +1,7048 @@
+   ----- Start Table A.1 -----
 
+   0221
 
+   0234-024F
 
+   02AE-02AF
 
+   02EF-02FF
 
+   0350-035F
 
-Network Working Group                                         P. Hoffman
-Request for Comments: 3454                                    IMC & VPNC
-Category: Standards Track                                    M. Blanchet
-                                                                Viagenie
-                                                           December 2002
-
-
-        Preparation of Internationalized Strings ("stringprep")
-
-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 (2002).  All Rights Reserved.
-
-Abstract
-
-   This document describes a framework for preparing Unicode text
-   strings in order to increase the likelihood that string input and
-   string comparison work in ways that make sense for typical users
-   throughout the world.  The stringprep protocol is useful for protocol
-   identifier values, company and personal names, internationalized
-   domain names, and other text strings.
+   0370-0373
 
-   This document does not specify how protocols should prepare text
-   strings.  Protocols must create profiles of stringprep in order to
-   fully specify the processing options.
+   0376-0379
 
-Table of Contents
+   037B-037D
 
-   1. Introduction....................................................3
-     1.1 Terminology..................................................4
-     1.2 Using stringprep in protocols................................4
-   2. Preparation Overview............................................6
-   3. Mapping.........................................................7
-     3.1 Commonly mapped to nothing...................................7
-     3.2 Case folding.................................................8
-   4. Normalization...................................................9
-   5. Prohibited Output..............................................10
-     5.1 Space characters............................................11
-     5.2 Control characters..........................................11
-     5.3 Private use.................................................12
+   037F-0383
 
+   038B
 
+   038D
 
-Hoffman & Blanchet          Standards Track                     [Page 1]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-     5.4 Non-character code points...................................12
-     5.5 Surrogate codes.............................................13
-     5.6 Inappropriate for plain text................................13
-     5.7 Inappropriate for canonical representation..................13
-     5.8 Change display properties or deprecated.....................13
-     5.9 Tagging characters..........................................14
-   6. Bidirectional Characters.......................................14
-   7. Unassigned Code Points in Stringprep Profiles..................15
-     7.1 Categories of code points...................................16
-     7.2 Reasons for difference between stored strings and queries...17
-     7.3 Versions of applications and stored strings.................18
-   8. References.....................................................19
-     8.1 Normative references........................................19
-     8.2 Informative references......................................19
-   9. Security Considerations........................................19
-     9.1 Stringprep-specific security considerations.................19
-     9.2 Generic Unicode security considerations.....................20
-   10. IANA Considerations...........................................21
-   11. Acknowledgements..............................................22
-   A. Unicode repertoires............................................23
-     A.1 Unassigned code points in Unicode 3.2.......................23
-   B. Mapping Tables.................................................31
-     B.1 Commonly mapped to nothing..................................31
-     B.2 Mapping for case-folding used with NFKC.....................32
-     B.3 Mapping for case-folding used with no normalization.........61
-   C. Prohibition tables.............................................78
-     C.1 Space characters............................................78
-       C.1.1 ASCII space characters..................................78
-       C.1.2 Non-ASCII space characters..............................79
-     C.2 Control characters..........................................79
-       C.2.1 ASCII control characters................................79
-       C.2.2 Non-ASCII control characters............................79
-     C.3 Private use.................................................80
-     C.4 Non-character code points...................................80
-     C.5 Surrogate codes.............................................80
-     C.6 Inappropriate for plain text................................80
-     C.7 Inappropriate for canonical representation..................81
-     C.8 Change display properties or are deprecated.................81
-     C.9 Tagging characters..........................................81
-   D. Bidirectional tables...........................................81
-     D.1 Characters with bidirectional property "R" or "AL"..........81
-     D.2 Characters with bidirectional property "L"..................82
-   Authors' Addresses................................................90
-   Full Copyright Statement..........................................91
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 2]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-1. Introduction
-
-   Application programs can display text in many different ways.
-   Similarly, a user can enter text into an application program in a
-   myriad of fashions.  Internationalized text (that is, text that is
-   not restricted to the narrow set of US-ASCII characters) has many
-   input and display behaviors that make it difficult to compare text in
-   a consistent fashion.
-
-   This document specifies a framework of processing rules for Unicode
-   text.  Other protocols can create profiles of these rules; these
-   profiles will allow users to enter internationalized text strings in
-   applications and have the highest chance of getting the content of
-   the strings correct.  In this case, "correct" means that if two
-   different people enter what they think is the same string into two
-   different input mechanisms, the strings should match on a character-
-   by-character basis.
-
-   This framework does not describe how data is transcoded from other
-   character sets into Unicode.  In systems that uses non-Unicode
-   character sets, the transcoding algorithm is a critical part of
-   enabling secure and "correct" operation of internationalized text
-   strings.
-
-   In addition to helping string matching, profiles of stringprep can
-   also exclude characters that should not normally appear in text that
-   is used in the protocol.  The profile can prevent such characters by
-   changing the characters to be excluded to other characters, by
-   removing those characters, or by causing an error if the characters
-   would appear in the output.  For example, because the backspace
-   character can cause unpredictable display results, a profile can
-   specify that a string containing a backspace character would cause an
-   error.
-
-   A profile of stringprep converts a single string of input characters
-   to a string of output characters, or returns an error if the output
-   string would contain a prohibited character.  Stringprep profiles
-   cannot both emit a string and return an error.
-
-   Stringprep profiles cannot account for all of the variations that
-   might occur or that a user might expect.  In particular, a profile
-   will not be able to account for choice of spellings in all languages
-   for all scripts because the number of alternative spellings of words
-   and phrases is immense.  Users would probably expect all spelling
-   equivalents to be made equivalent, or none of them to be.  Examples
-   of spelling equivalents include "theater" vs. "theatre", and
-   "hemoglobin" vs. "h<U+00E6>moglobin" in American vs. British English.
-   Other examples are simplified Chinese spellings of names (for
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 3]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   03A2
 
+   03CF
 
-   example,"<U+7EDF><U+4E00><U+7801>") vs. the equivalent traditional
-   Chinese spelling (for example, "<U+7D71><U+4E00><U+78BC>").
-   Language-specific equivalences such as "Aepfel" vs. "<U+00C4>pfel",
-   which are sometimes considered equivalent in German, may not be
-   considered equivalent in other languages.
+   03F7-03FF
 
-1.1 Terminology
+   0487
 
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in BCP 14, RFC 2119
-   [RFC2119].
+   04CF
 
-   Note: A glossary of terms used in Unicode and ISO/IEC 10646 can be
-   found in [Glossary].  Information on the 10646/Unicode character
-   encoding model can be found in [CharModel].
+   04F6-04F7
 
-   Character names in this document use the notation for code points and
-   names from the Unicode Standard [Unicode3.2] and ISO/IEC 10646
-   [ISO10646].  For example, the letter "a" may be represented as either
-   "U+0061" or "LATIN SMALL LETTER A".  In the lists of mappings and the
-   prohibited characters, the "U+" is left off to make the lists easier
-   to read.  The comments for character ranges are shown in square
-   brackets (such as "[CONTROL CHARACTERS]") and do not come from the
-   standards.
+   04FA-04FF
 
-1.2 Using stringprep in protocols
+   0510-0530
 
-   The stringprep protocol does not stand on its own; it has to be used
-   by other protocols at precisely-defined places in those other
-   protocols.  For example, a protocol that has strings that come from
-   the entire ISO/IEC 10646 [ISO10646] character repertoire might
-   specify that only strings that have been processed with a particular
-   profile of stringprep are legal.  Another example would be a protocol
-   that does string comparison as a step in the protocol; that protocol
-   might specify that such comparison is done only after processing the
-   strings with a specific profile of stringprep.
+   0557-0558
 
-   When two protocols that use different profiles of stringprep
-   interoperate, there may be conflict about what characters are and are
-   not allowed in the final string.  Thus, protocol developers should
-   strongly consider re-using existing profiles of stringprep.
+   0560
 
-   When developers wish to allow users as wide of a range of characters
-   as possible in input text strings, they should, where possible, cause
-   stringprep to convert characters from the input string to a canonical
-   form instead of prohibiting them.
+   0588
 
+   058B-0590
 
+   05A2
 
+   05BA
 
-Hoffman & Blanchet          Standards Track                     [Page 4]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   05C5-05CF
 
+   05EB-05EF
 
-   Although it would be easy to use the stringprep process to "correct"
-   perceived mis-features or bugs in the current character standards,
-   stringprep profiles SHOULD NOT do so.
+   05F5-060B
 
-   A profile of stringprep can create tables different from those in the
-   appendixes of this document, but it will be an exception when they
-   do.  The intention of stringprep is to define the tables and have the
-   profiles of stringprep select among those defined tables.
+   060D-061A
 
-   A profile of stringprep MUST include all of the following:
+   061C-061E
 
-   - The intended applicability of the profile
+   0620
 
-   - The character repertoire that is the input and output to stringprep
-     (which is Unicode 3.2 for this version of stringprep)
+   063B-063F
 
-   - The mapping tables from this document used (as described in section
-     3)
+   0656-065F
 
-   - Any additional mapping tables specific to the profile
+   06EE-06EF
 
-   - The Unicode normalization used, if any (as described in section 4)
+   06FF
 
-   - The tables from this document of characters that are prohibited as
-     output (as described in section 5)
+   070E
 
-   - The bidirectional string testing used, if any (as described in
-     section 6)
+   072D-072F
 
-   - Any additional characters that are prohibited as output specific to
-     the profile
+   074B-077F
 
-   Each profile MUST state the character repertoire on which the profile
-   will operate.  Appendix A lists the Unicode repertoires that can be
-   selected.  No repertoire is ever complete, and it is expected that
-   characters will be added to the Unicode repertoire for the
-   foreseeable future.  Section 7 of this document describes how to
-   handle characters that are assigned in later versions of the Unicode
-   repertories.  Subsections of appendix A also list unassigned code
-   points for each repertoire.
+   07B2-0900
 
-   This document is for Unicode version 3.2, and should not be
-   considered to automatically apply to later Unicode versions.  The
-   IETF, through an explicit standards action, may update this document
-   as appropriate to handle later Unicode versions.
 
 
 
 
 
 
-Hoffman & Blanchet          Standards Track                     [Page 5]
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   This document lists the unassigned code points in the range 0 to
-   10FFFF for Unicode 3.2 in appendix A.  The list in appendix A MUST be
-   used by implementations of this specification.  If there are any
-   discrepancies between the list in appendix A and the Unicode 3.2
-   specification, the list in appendix A always takes precedence.
-
-   Each profile of stringprep MUST be registered with IANA.  The
-   registration procedure is described in the IANA Considerations
-   appendix; basically, the IESG must review each profile of stringprep.
-   Protocol developers are strongly encouraged to look through the IANA
-   profile registry when creating new profiles for stringprep, and to
-   re-use logic from earlier profiles where possible in new profiles.
-   In some cases, an existing profile can be reused by a different
-   protocol.
-
-2. Preparation Overview
-
-   The steps for preparing strings are:
-
-   1) Map -- For each character in the input, check if it has a mapping
-      and, if so, replace it with its mapping.  This is described in
-      section 3.
-
-   2) Normalize -- Possibly normalize the result of step 1 using Unicode
-      normalization.  This is described in section 4.
-
-   3) Prohibit -- Check for any characters that are not allowed in the
-      output.  If any are found, return an error.  This is described in
-      section 5.
-
-   4) Check bidi -- Possibly check for right-to-left characters, and if
-      any are found, make sure that the whole string satisfies the
-      requirements for bidirectional strings.  If the string does not
-      satisfy the requirements for bidirectional strings, return an
-      error.  This is described in section 6.
-
-   The above steps MUST be performed in the order given to comply with
-   this specification.
 
-   The mappings described in section 3, and the optional Unicode
-   normalization described in section 4, can be one-to-none, one-to-one,
-   one-to-many, many-to-one, or many-to-many.  That is, some characters
-   might be eliminated or replaced by more than one character, and the
-   output of this step might be shorter or longer than the input.
-   Because of this, the system using stringprep MUST be prepared to
-   receive a longer or shorter string than the one input in the
-   stringprep algorithm.
 
 
 
 
-Hoffman & Blanchet          Standards Track                     [Page 6]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-3. Mapping
-
-   Each character in the input stream MUST be checked against a mapping
-   table.  The mapping table SHOULD come from this document, although
-   the mapping table MAY be added to or altered by the profile.  The
-   mapping tables are subsections of appendix B.
+   0904
 
-   The lists in appendix B MUST be used by implementations of this
-   specification.  If there are any discrepancies between the lists in
-   appendix B and subsections below, the lists in appendix B always
-   takes precedence.
+   093A-093B
 
-   For any individual character, the mapping table MAY specify that a
-   character be mapped to nothing, or mapped to one other character, or
-   mapped to a string of other characters.
+   094E-094F
 
-   Mapped characters are not re-scanned during the mapping step.  That
-   is, if character A at position X is mapped to character B, character
-   B which is now at position X is not checked against the mapping
-   table.
+   0955-0957
 
-3.1 Commonly mapped to nothing
+   0971-0980
 
-   The following characters are simply deleted from the input (that is,
-   they are mapped to nothing) because their presence or absence in
-   protocol identifiers should not make two strings different.  They are
-   listed in Table B.1.
+   0984
 
-   Some characters are only useful in line-based text, and are otherwise
-   invisible and ignored.
+   098D-098E
 
-   00AD; SOFT HYPHEN
-   1806; MONGOLIAN TODO SOFT HYPHEN
-   200B; ZERO WIDTH SPACE
-   2060; WORD JOINER
-   FEFF; ZERO WIDTH NO-BREAK SPACE
+   0991-0992
 
-   Some characters affect glyph choice and glyph placement, but do not
-   bear semantics.
+   09A9
 
-   034F; COMBINING GRAPHEME JOINER
-   180B; MONGOLIAN FREE VARIATION SELECTOR ONE
-   180C; MONGOLIAN FREE VARIATION SELECTOR TWO
-   180D; MONGOLIAN FREE VARIATION SELECTOR THREE
-   200C; ZERO WIDTH NON-JOINER
-   200D; ZERO WIDTH JOINER
-   FE00; VARIATION SELECTOR-1
-   FE01; VARIATION SELECTOR-2
+   09B1
 
+   09B3-09B5
 
+   09BA-09BB
 
-Hoffman & Blanchet          Standards Track                     [Page 7]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   FE02; VARIATION SELECTOR-3
-   FE03; VARIATION SELECTOR-4
-   FE04; VARIATION SELECTOR-5
-   FE05; VARIATION SELECTOR-6
-   FE06; VARIATION SELECTOR-7
-   FE07; VARIATION SELECTOR-8
-   FE08; VARIATION SELECTOR-9
-   FE09; VARIATION SELECTOR-10
-   FE0A; VARIATION SELECTOR-11
-   FE0B; VARIATION SELECTOR-12
-   FE0C; VARIATION SELECTOR-13
-   FE0D; VARIATION SELECTOR-14
-   FE0E; VARIATION SELECTOR-15
-   FE0F; VARIATION SELECTOR-16
-
-3.2 Case folding
-
-   If a profile is going to map characters for case-insensitive
-   comparison, that profile SHOULD map using either appendix B.2 or
-   appendix B.3.  appendix B.2 is for profiles that also use Unicode
-   normalization form KC, while appendix  B.3 is for profiles that do
-   not use Unicode normalization.  These tables map from uppercase to
-   lowercase characters.  Note that this could have been "change all
-   lowercase characters into uppercase characters".  However, the
-   upper-to-lower folding was chosen because there is a tradition of
-   using lowercase in current Internet applications and protocols.
-
-   If a profile creates its own mapping tables for case folding, they
-   SHOULD be based on [UTR21], and SHOULD map from uppercase characters
-   to lowercase.  The "CaseFolding.txt" file from the Unicode database
-   SHOULD be used to prepare the mapping table. The profile SHOULD do
-   full case mapping (that is, using statuses C, F, and I).
-
-   If the profile is using Unicode normalization form KC (as described
-   in section 4 of this document), it is important to note that there
-   are some characters that do not have mappings in [UTR21] but still
-   need processing.  These characters include a few Greek characters and
-   many symbols that contain Latin characters.  The list of characters
-   to add to the mapping table can determined by the following
-   algorithm:
-
-   b = NormalizeWithKC(Fold(a));
-   c = NormalizeWithKC(Fold(b));
-   if c is not the same as b, add a mapping for "a to c".
-
-   Because NormalizeWithKC(Fold(c)) always equals c, the table is stable
-   from that point on.
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 8]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   09BD
 
+   09C5-09C6
 
-   Appendix B.3 is derived from the CaseFolding-3.txt file associated
-   with Unicode 3.2; appendix B.2 is based on appendix B.3 with the
-   additional characters added from the algorithm above.
+   09C9-09CA
 
-   Authors of profiles of this document need to consider the effects of
-   changing the mapping of any currently-assigned character when
-   updating their profiles.  Adding a new mapping for a currently-
-   assigned character, or changing an existing mapping, could cause a
-   variance between the behavior of systems that have been updated and
-   systems that have not been updated.
+   09CE-09D6
 
-4. Normalization
+   09D8-09DB
 
-   The output of the mapping step is optionally normalized using one of
-   the Unicode normalization forms, as described in [UAX15].  A profile
-   can specify one of two options for Unicode normalization:
+   09DE
 
-   - no normalization
+   09E4-09E5
 
-   - Unicode normalization with form KC
+   09FB-0A01
 
-   A profile MAY choose to do no normalization.  However, such a profile
-   can easily yield results that will be surprising to typical users,
-   depending on the input mechanism they use.  For example, some input
-   mechanisms enter compatibility characters that look exactly like the
-   underlying characters, but have different code points.  Another
-   example of where Unicode normalization helps create predictable
-   results is with characters that have multiple combining diacritics:
-   normalization orders those diacritics in a predictable fashion.
+   0A03-0A04
 
-   On the other hand, Unicode normalization requires fairly large tables
-   and somewhat complicated character reordering logic.  The size and
-   complexity should not be considered daunting except in the most
-   restricted of environments, and needs to be weighed against the
-   problems of user surprise from comparing unnormalized strings.  Note
-   that the tables used for normalization are not given in this
-   document, but instead must be derived from the Unicode database, as
-   described in [UAX15].
+   0A0B-0A0E
 
-   There is a third form of normalization, Unicode normalization with
-   form C.  If a profile is going to use a Unicode normalization, it
-   MUST use Unicode normalization form KC.  Form KC maps many
-   "compatibility characters" to their equivalents.  Some user interface
-   systems make it possible to enter compatibility characters instead of
-   the base equivalents.  Thus, using form KC instead of form C will
-   cause more strings that users would expect to match to actually
-   match.
+   0A11-0A12
 
+   0A29
 
+   0A31
 
+   0A34
 
-Hoffman & Blanchet          Standards Track                     [Page 9]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   0A37
 
+   0A3A-0A3B
 
-   A profile that specifies Unicode normalization MUST use the
-   normalization in [UAX15] that is associated with the version of the
-   Unicode character set specified for the profile.
+   0A3D
 
-   The composition process described in [UAX15] requires a fixed
-   composition version of Unicode to ensure that strings normalized
-   under one version of Unicode remain normalized under all future
-   versions of Unicode.
+   0A43-0A46
 
-   The IETF is relying on Unicode not to change the normalization of
-   currently-assigned characters in future versions of normalization.
-   If a future version of the normalization tables changes the
-   normalized value of an existing character, authors of profiles of
-   this document have to look at the changes very carefully before they
-   update their normalization tables.  Such a change could cause a
-   variance between the behavior of systems that have been updated and
-   systems that have not been updated.
+   0A49-0A4A
 
-5. Prohibited Output
+   0A4E-0A58
 
-   Before the text can be emitted, it MUST be checked for prohibited
-   code points.  There are a variety of prohibited code points, as
-   described in this section.  A profile of this document MAY use all or
-   some of the tables in appendix C.
+   0A5D
 
-   The stringprep process never emits both an error and a string.  If an
-   error is detected during the checking for prohibited code points,
-   only an error is returned.
+   0A5F-0A65
 
-   Note that the subsections below describe how the tables in appendix C
-   were formed.  They are here for people who want to understand more,
-   but they should be ignored by implementors.  Implementations that use
-   tables MUST map based on the tables themselves, not based on the
-   descriptions in this section of how the tables were created.
+   0A75-0A80
 
-   The lists in appendix C MUST be used by implementations of this
-   specification.  If there are any discrepancies between the lists in
-   appendix C and subsections below, the lists in appendix C always take
-   precedence.
+   0A84
 
-   Some code points listed in one section may also appear in other
-   sections.
+   0A8C
 
-   It is important to note that a profile of this document MAY prohibit
-   additional characters.
+   0A8E
 
+   0A92
 
+   0AA9
 
+   0AB1
 
+   0AB4
 
+   0ABA-0ABB
 
-Hoffman & Blanchet          Standards Track                    [Page 10]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   0AC6
 
+   0ACA
 
-   Each subsection of this section has a matching subsection in appendix
-   C.  For example, the characters listed in section 5.1 are listed in
-   appendix C.1.
+   0ACE-0ACF
 
-5.1 Space characters
+   0AD1-0ADF
 
-   Space characters can make accurate visual transcription of strings
-   nearly impossible and could lead to user entry errors in many ways.
-   Note that the list below is split into two tables in appendix C:
-   Table C.1.1 contains the ASCII code points, while Table C.1.2
-   contains the non-ASCII code points.  Most profiles of this document
-   that want to prohibit space characters will want to include both
-   tables.
+   0AE1-0AE5
 
-   0020; SPACE
-   00A0; NO-BREAK SPACE
-   1680; OGHAM SPACE MARK
-   2000; EN QUAD
-   2001; EM QUAD
-   2002; EN SPACE
-   2003; EM SPACE
-   2004; THREE-PER-EM SPACE
-   2005; FOUR-PER-EM SPACE
-   2006; SIX-PER-EM SPACE
-   2007; FIGURE SPACE
-   2008; PUNCTUATION SPACE
-   2009; THIN SPACE
-   200A; HAIR SPACE
-   200B; ZERO WIDTH SPACE
-   202F; NARROW NO-BREAK SPACE
-   205F; MEDIUM MATHEMATICAL SPACE
-   3000; IDEOGRAPHIC SPACE
 
-5.2 Control characters
 
-   Control characters (or characters with control function) cannot be
-   seen and can cause unpredictable results when displayed.  Note that
-   the list below is split into two tables in appendix C: Table C.2.1
-   contains the ASCII code points, while Table C.2.2 contains the non-
-   ASCII code points.  Most profiles of this document that want to
-   prohibit control characters will want to include both tables.
 
-   0000-001F; [CONTROL CHARACTERS]
-   007F; DELETE
-   0080-009F; [CONTROL CHARACTERS]
-   06DD; ARABIC END OF AYAH
-   070F; SYRIAC ABBREVIATION MARK
-   180E; MONGOLIAN VOWEL SEPARATOR
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 11]
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   200C; ZERO WIDTH NON-JOINER
-   200D; ZERO WIDTH JOINER
-   2028; LINE SEPARATOR
-   2029; PARAGRAPH SEPARATOR
-   2060; WORD JOINER
-   2061; FUNCTION APPLICATION
-   2062; INVISIBLE TIMES
-   2063; INVISIBLE SEPARATOR
-   206A-206F; [CONTROL CHARACTERS]
-   FEFF; ZERO WIDTH NO-BREAK SPACE
-   FFF9-FFFC; [CONTROL CHARACTERS]
-   1D173-1D17A; [MUSICAL CONTROL CHARACTERS]
 
-5.3 Private use
 
-   Because private-use characters do not have defined meanings, they are
-   likely to be prohibited.  The private-use characters are:
 
-   E000-F8FF; [PRIVATE USE, PLANE 0]
-   F0000-FFFFD; [PRIVATE USE, PLANE 15]
-   100000-10FFFD; [PRIVATE USE, PLANE 16]
 
-5.4 Non-character code points
 
-   Non-character code points are code points that have been allocated in
-   ISO/IEC 10646 but are not characters.  Because they are already
-   assigned, they are guaranteed not to later change into characters.
+   0AF0-0B00
 
-   FDD0-FDEF; [NONCHARACTER CODE POINTS]
-   FFFE-FFFF; [NONCHARACTER CODE POINTS]
-   1FFFE-1FFFF; [NONCHARACTER CODE POINTS]
-   2FFFE-2FFFF; [NONCHARACTER CODE POINTS]
-   3FFFE-3FFFF; [NONCHARACTER CODE POINTS]
-   4FFFE-4FFFF; [NONCHARACTER CODE POINTS]
-   5FFFE-5FFFF; [NONCHARACTER CODE POINTS]
-   6FFFE-6FFFF; [NONCHARACTER CODE POINTS]
-   7FFFE-7FFFF; [NONCHARACTER CODE POINTS]
-   8FFFE-8FFFF; [NONCHARACTER CODE POINTS]
-   9FFFE-9FFFF; [NONCHARACTER CODE POINTS]
-   AFFFE-AFFFF; [NONCHARACTER CODE POINTS]
-   BFFFE-BFFFF; [NONCHARACTER CODE POINTS]
-   CFFFE-CFFFF; [NONCHARACTER CODE POINTS]
-   DFFFE-DFFFF; [NONCHARACTER CODE POINTS]
-   EFFFE-EFFFF; [NONCHARACTER CODE POINTS]
-   FFFFE-FFFFF; [NONCHARACTER CODE POINTS]
-   10FFFE-10FFFF; [NONCHARACTER CODE POINTS]
+   0B04
 
+   0B0D-0B0E
 
+   0B11-0B12
 
+   0B29
 
+   0B31
 
-Hoffman & Blanchet          Standards Track                    [Page 12]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   0B34-0B35
 
+   0B3A-0B3B
 
-   The non-character code points are listed in the PropList.txt file
-   from the Unicode database.
+   0B44-0B46
 
-5.5 Surrogate codes
+   0B49-0B4A
 
-   The following code points are permanently reserved for use as
-   surrogate code values in the UTF-16 encoding, will never be assigned
-   to characters in the Unicode repertoire, and are therefore
-   prohibited:
+   0B4E-0B55
 
-   D800-DFFF; [SURROGATE CODES]
+   0B58-0B5B
 
-5.6 Inappropriate for plain text
+   0B5E
 
-   The following characters do not appear in regular text.
+   0B62-0B65
 
-   FFF9; INTERLINEAR ANNOTATION ANCHOR
-   FFFA; INTERLINEAR ANNOTATION SEPARATOR
-   FFFB; INTERLINEAR ANNOTATION TERMINATOR
-   FFFC; OBJECT REPLACEMENT CHARACTER
+   0B71-0B81
 
-   Although the replacement character (U+FFFD) might be used when a
-   string is displayed,  it doesn't make sense for it to be part of the
-   string itself.  It is often displayed by renderers to indicate "there
-   would be some character here, but it cannot be rendered".  For
-   example, on a computer with no Asian fonts, a string with three
-   ideographs might be rendered with three replacement characters.
+   0B84
 
-   FFFD; REPLACEMENT CHARACTER
+   0B8B-0B8D
 
-5.7 Inappropriate for canonical representation
+   0B91
 
-   The ideographic description characters allow different sequences of
-   characters to be rendered the same way, which makes them
-   inappropriate for strings that have to have a single canonical
-   representation.
+   0B96-0B98
 
-   2FF0-2FFB; [IDEOGRAPHIC DESCRIPTION CHARACTERS]
+   0B9B
 
-5.8 Change display properties or are deprecated
+   0B9D
 
-   The following characters can cause changes in display or the order in
-   which characters appear when rendered, or are deprecated in Unicode.
+   0BA0-0BA2
 
-   0340; COMBINING GRAVE TONE MARK
-   0341; COMBINING ACUTE TONE MARK
-   200E; LEFT-TO-RIGHT MARK
-   200F; RIGHT-TO-LEFT MARK
+   0BA5-0BA7
 
+   0BAB-0BAD
 
+   0BB6
 
-Hoffman & Blanchet          Standards Track                    [Page 13]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   0BBA-0BBD
 
+   0BC3-0BC5
 
-   202A; LEFT-TO-RIGHT EMBEDDING
-   202B; RIGHT-TO-LEFT EMBEDDING
-   202C; POP DIRECTIONAL FORMATTING
-   202D; LEFT-TO-RIGHT OVERRIDE
-   202E; RIGHT-TO-LEFT OVERRIDE
-   206A; INHIBIT SYMMETRIC SWAPPING
-   206B; ACTIVATE SYMMETRIC SWAPPING
-   206C; INHIBIT ARABIC FORM SHAPING
-   206D; ACTIVATE ARABIC FORM SHAPING
-   206E; NATIONAL DIGIT SHAPES
-   206F; NOMINAL DIGIT SHAPES
+   0BC9
 
-5.9 Tagging characters
+   0BCE-0BD6
 
-   The following characters are used for tagging text and are invisible.
+   0BD8-0BE6
 
-   E0001; LANGUAGE TAG
-   E0020-E007F; [TAGGING CHARACTERS]
+   0BF3-0C00
 
-6. Bidirectional Characters
+   0C04
 
-   Most characters are displayed from left to right, but some are
-   displayed from right to left.  This feature of Unicode is called
-   "bidirectional text", or "bidi" for short.  The Unicode standard has
-   an extensive discussion of how to reorder glyphs for display when
-   dealing with bidirectional text such as Arabic or Hebrew.  See [UAX9]
-   for more information.  In particular, all Unicode text is stored in
-   logical order.
+   0C0D
 
-   A profile MAY choose to ignore bidirectional text.  However, ignoring
-   bidirectional text can cause display ambiguities.  For example, it is
-   quite easy to create two different strings with the same characters
-   (but in different order) that are correctly displayed identically.
-   Therefore, in order to avoid most problems with ambiguous
-   bidirectional text display, profile creators should strongly consider
-   including the bidirectional character handling described in this
-   section in their profile.
+   0C11
 
-   The stringprep process never emits both an error and a string.  If an
-   error is detected during the checking of bidirectional strings, only
-   an error is returned.
+   0C29
 
-   [Unicode3.2] defines several bidirectional categories; each character
-   has one bidirectional category assigned to it.  For the purposes of
-   the requirements below, an "RandALCat character" is a character that
-   has Unicode bidirectional categories "R" or "AL"; an "LCat character"
-   is a character that has Unicode bidirectional category "L".  Note
+   0C34
 
+   0C3A-0C3D
 
+   0C45
 
+   0C49
 
-Hoffman & Blanchet          Standards Track                    [Page 14]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   0C4E-0C54
 
+   0C57-0C5F
 
-   that there are many characters which fall in neither of the above
-   definitions; Latin digits (<U+0030> through <U+0039>) are examples of
-   this because they have bidirectional category "EN".
+   0C62-0C65
 
-   In any profile that specifies bidirectional character handling, all
-   three of the following requirements MUST be met:
+   0C70-0C81
 
-   1) The characters in section 5.8 MUST be prohibited.
+   0C84
 
-   2) If a string contains any RandALCat character, the string MUST NOT
-      contain any LCat character.
+   0C8D
 
-   3) If a string contains any RandALCat character, a RandALCat
-      character MUST be the first character of the string, and a
-      RandALCat character MUST be the last character of the string.
+   0C91
 
-   Note that requirement 3 prohibits strings such as <U+0627><U+0031>
-   ("aleph 1") but allows strings such as <U+0627><U+0031><U+0628>
-   ("aleph 1 beh").  [UAX9] goes into great detail about the display
-   order of strings that contain particular categories of characters in
-   particular sequences.
+   0CA9
 
-   Table D.1 lists the characters that belong to Unicode bidirectional
-   categories "R" and "AL".  Table D.2 lists all the characters that
-   belong to Unicode bidirectonal category "L".  These tables are
-   derived from [Unicode3.2].
+   0CB4
 
-7. Unassigned Code Points in Stringprep Profiles
 
-   This section describes two different types of strings in typical
-   protocols where internationalized strings are used: "stored strings"
-   and "queries".  Of course, different Internet protocols use strings
-   very differently, so these terms cannot be used exactly in every
-   protocol that needs to use stringprep.  In general, "stored strings"
-   are strings that are used in protocol identifiers and named entities,
-   such as names in digital certificates and DNS domain name parts.
-   "Queries" are strings that are used to match against strings that are
-   stored identifiers, such as user-entered names for digital
-   certificate authorities and DNS lookups.
 
-   All code points not assigned in the character repertoire named in a
-   stringprep profile are called "unassigned code points".  Stored
-   strings using the profile MUST NOT contain any unassigned code
-   points.  Queries for matching strings MAY contain unassigned code
-   points.  Note that this is the only part of this document where the
-   requirements for queries differs from the requirements for stored
-   strings.
 
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 15]
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   Using two different policies for where unassigned code points can
-   appear removes the need for versioning in protocols that use
-   stringprep profiles.  This is very useful since it makes the overall
-   processing simpler and does not impose a "protocol" to handle
-   versioning.  It is expected that the ISO/IEC 10646 and Unicode
-   repertoires will be updated fairly frequently; at the time that this
-   document is being written, it has happened approximately once a year.
-   Each time a new version of a repertoire appears, a new version of a
-   profile MAY be created.  Some end users will want to use the new code
-   points as soon as they are defined.
-
-   The list of unassigned code points MUST be given in a profile, and
-   that list MUST be used by implementations of the profile.
 
-   The goal of the requirements in this section is to prevent
-   comparisons between two strings that were both permitted to contain
-   unassigned code points.  When two strings X and Y are compared and
-   string Y was prepared in a way that permits unassigned code points, a
-   negative result to the comparison is not definitive; it's possible
-   that the strings don't match even though they would match if a more
-   recent version of the profile were used for Y.  However, if both X
-   and Y were prepared in a way that permits unassigned code points,
-   something worse can happen: even a positive result for the comparison
-   is not definitive.  It is possible that the strings do match even
-   though they would not match if a more recent version of the profile
-   were used (one that prohibits a code point appearing in both X and
-   Y).
 
-   Due to the way that versioning is handled in this section, stored
-   strings that are embedded in structures that cannot be changed (such
-   as the signed parts of digital certificates) MUST NOT contain any
-   unassigned code points.
 
-7.1 Categories of code points
 
-   Each code point in a repertoire named by a profile of stringprep can
-   be categorized by how it acts in the process described in earlier
-   sections of this document:
 
-      AO      Code points that can be in the output
-
-      MN      Code points that cannot be in the output because they
-              never appear as output from mapping or normalization
-
-      D       Code points that cannot be in the output because they are
-              disallowed in the prohibition step
-
-      U       Unassigned code points
+   0CBA-0CBD
 
+   0CC5
 
+   0CC9
 
-Hoffman & Blanchet          Standards Track                    [Page 16]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   A subsequent version of a profile that references a newer version of
-   a repertoire with new code points will inherently have some code
-   points move from category U to either D, MN, or AO.  For backwards
-   compatibility, a subsequent version of a profile MUST NOT move code
-   points from any other category.  That is, current AO, MN, or D code
-   points MUST NOT ever change to a different category.
-
-   Stored strings MUST NOT contain any code points outside of AO for the
-   latest version of a profile.  That is, they are forbidden to contain
-   code points from the MN, D, or U categories.
-
-   Applications creating queries MUST treat U code points as if they
-   were AO when preparing the query to be entered in the process
-   described by a profile of stringprep.  Those applications MAY
-   optionally have a preprocessor that provide stricter checks: treating
-   unassigned code points in the input as errors, or warning the user
-   about the fact that the code point is unassigned in the version of a
-   profile that the software is based on; such a choice is a local
-   matter for the software.
-
-7.2 Reasons for the difference between stored strings and queries
-
-   Different software using different versions of a stringprep profile
-   need to interoperate with maximal compatibility.  The scheme
-   described in this section (stored strings MUST NOT contain unassigned
-   code points, queries MAY include unassigned code points) allows that
-   compatibility without introducing any known security or
-   interoperability issues.
-
-   The list below shows what happens if a query contains a code point
-   from category U that is allowed in a newer version of a profile.  The
-   query either matches the string that was intended, or matches no
-   string at all.  In this list, the query comes from an application
-   using version "oldVersion" of a profile, the stored string was
-   created using version "newVersion" of the same profile, and the code
-   point X was in category U in oldVersion, and has changed category to
-   AO, MN, or D.  There are 3 possible scenarios:
-
-   1. X is assigned to AO -- In newVersion, X is in category AO.
-      Because the application passed X through, it gets back a positive
-      match with the stored string.  There is one exceptional case,
-      where X is a combining mark.
-
-      The order of combining marks is normalized, so if another
-      combining mark Y has a lower combining class than X then XY will
-      be put in the canonical order YX.  (Unassigned code points are
-      never reordered, so this doesn't happen in oldVersion).  If the
-      query contains YX, the query will get positive match with the
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 17]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   0CCE-0CD4
 
+   0CD7-0CDD
 
-      stored string.  However, no string can be stored with XY, so a
-      query with XY will get a negative answer to the test for matching.
+   0CDF
 
-   2. X is assigned to MN -- In newVersion, X is normalized to code
-      point "nX" and therefore X is now put in category MN.  This cannot
-      exist in any stored string, so any query containing X will get a
-      negative answer to the test for matching.  Note, however, if the
-      query had contained the letter nX, it would have positively
-      matched.
+   0CE2-0CE5
 
-   3. X is assigned to D -- In newVersion, X is in category D.  This
-      cannot exist in any stored string, so any query containing X will
-      get a negative answer to the test for matching.
+   0CF0-0D01
 
-   In none of the cases does the query get data for a stored string
-   other than the one it actually tried to match against.
+   0D04
 
-   Profiles are stable between versions in the following sense: If a
-   string S has been prepared using newVersion, then it will not change
-   if it is subsequently prepared using oldVersion.
+   0D0D
 
-7.3 Versions of applications and stored strings
+   0D11
 
-   Another way to see that this versioning system works is to compare
-   what happens when an application uses a newer or older version of a
-   profile.
+   0D29
 
-   Newer query application -- Suppose that a querying application is
-   using version newVersion and the stored string was created using
-   version oldVersion.  This case is simple: there will be no characters
-   in the stored string that cannot be queried by the application
-   because the new profile uses a superset of the code points used for
-   making the stored string.
+   0D3A-0D3D
 
-   Newer stored string -- Suppose that a querying application is using
-   oldVersion and the stored string was created using a profile that
-   uses newVersion.  Because the querying application let unassigned
-   code points pass through, the user can query on stored strings that
-   use code points in newVersion.  No stored strings can have code
-   points that are unassigned in newVersion, since that is illegal.  In
-   order to get a match, the querying application has to enter the
-   unassigned code points in the proper order, and has to use unassigned
-   code points that would make it through both the mapping and the
-   normalization steps.
+   0D44-0D45
 
+   0D49
 
+   0D4E-0D56
 
+   0D58-0D5F
 
+   0D62-0D65
 
+   0D70-0D81
 
+   0D84
 
-Hoffman & Blanchet          Standards Track                    [Page 18]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   0D97-0D99
 
+   0DB2
 
-8. References
+   0DBC
 
-8.1 Normative references
+   0DBE-0DBF
 
-   [UAX15]      Mark Davis and Martin Duerst. Unicode Standard Annex
-                #15:  Unicode Normalization Forms, Version 3.2.0.
-                <http://www.unicode.org/unicode/reports/tr15/tr15-
-                22.html>.
+   0DC7-0DC9
 
-   [Unicode3.2] The Unicode Consortium. The Unicode Standard, Version
-                3.2.0 is defined by The Unicode Standard, Version 3.0
-                (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
-                as amended by the Unicode Standard Annex #27: Unicode
-                3.1 (http://www.unicode.org/reports/tr27/) and by the
-                Unicode Standard Annex #28: Unicode 3.2
-                (http://www.unicode.org/reports/tr28/).
+   0DCB-0DCE
 
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
+   0DD5
 
-8.2 Informative references
+   0DD7
 
-   [CharModel]  Unicode Technical Report;17, Character Encoding Model.
-                <http://www.unicode.org/unicode/reports/tr17/>.
+   0DE0-0DF1
 
-   [Glossary]   Unicode Glossary, <http://www.unicode.org/glossary/>.
+   0DF5-0E00
 
-   [ISO10646]   ISO/IEC, "Information Technology - Universal Multiple-
-                Octet Coded Character Set (UCS) - Part 1: Architecture
-                and Basic Multilingual Plane", ISO/IEC 10646-1:2000,
-                October 2000.
+   0E3B-0E3E
 
-   [RFC2434]    Narten, T. and H. Alvestrand, "Guidelines for IANA
-                Considerations", BCP 26, RFC 2434, October 1998.
+   0E5C-0E80
 
-   [UAX9]       The Unicode Consortium. Unicode Standard Annex #9, The
-                Bidirectional Algorithm,
-                <http://www.unicode.org/unicode/reports/tr9/>.
+   0E83
 
-   [UTR21]      Mark Davis. Case Mappings. Unicode Technical Report 21.
-                <http://www.unicode.org/unicode/reports/tr21/>.
+   0E85-0E86
 
-9. Security Considerations
+   0E89
 
-   Stringprep is used with Unicode characters.  There are security
-   considerations that are specific to stringprep, and others that are
-   generic to using Unicode.
+   0E8B-0E8C
 
+   0E8E-0E93
 
+   0E98
 
+   0EA0
 
-Hoffman & Blanchet          Standards Track                    [Page 19]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   0EA4
 
+   0EA6
 
-9.1 Stringprep-specific security considerations
+   0EA8-0EA9
 
-   The Unicode and ISO/IEC 10646 repertoires have many characters that
-   look similar.  In many cases, users of security protocols might do
-   visual matching, such as when comparing the names of trusted third
-   parties.  Because it is impossible to map similar-looking characters
-   without a great deal of context such as knowing the fonts used,
-   stringprep does nothing to map similar-looking characters together
-   nor to prohibit some characters because they look like others.  User
-   applications can help disambiguate some similar-looking characters by
-   showing the user when a string changes between scripts.
+   0EAC
 
-   Most profiles of stringprep can cause changes in strings that are
-   input to stringprep.  Because of this, protocols that have sets of
-   non-allowed characters or sequences MUST check for the non-allowed
-   characters or sequences after the stringprep processing.
+   0EBA
 
-   This document does not mandate the checking of bidirectional
-   characters in section 6.  If the requirements in section 6 are not
-   used in a profile of stringprep, it is easy to create many strings
-   whose characters are in different order but are displayed
-   identically.  This can cause security-related user confusion similar
-   to look-alike characters, as described above.
+   0EBE-0EBF
 
-   Stringprep does not do anything to assure that any algorithms
-   translating characters from non-Unicode into Unicode produce the same
-   output in all implementations.
+   0EC5
 
-   Some Unicode codepoints are invisible.  Protocols that allow these
-   characters (that is, do not map them out or prohibit them in
-   stringprep) can cause users confusion when two identical-looking
-   strings do not match.
+   0EC7
 
-9.2 Generic Unicode security considerations
+   0ECE-0ECF
 
-   Using Unicode characters explicitly forces applications to use
-   multi-octet characters.  Converting an application from one that uses
-   single-octet characters to one that uses multi-octet characters must
-   be done very carefully, particularly in an application that checks
-   for values of characters or sorts characters.
 
-   Protocols that use stringprep usually also use encodings of Unicode,
-   such as UTF-8 or UTF-16.  Some applications using those encodings
-   have been known to not check for illegal or ill-formed sequences in
-   the encodings, and thereby have not detected sequences of octets that
-   would have been detected if they used just ASCII.  For example, in
 
 
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 20]
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   UTF-8 the octet sequence "0xC0 0xAB" is an illegal formation of
-   U+002B (plus sign).  All programs should reject any string that is an
-   illegal or ill-formed octet sequence for the encoding being used.
-
-   Both Unicode normalization and conversion between Unicode encodings
-   can cause strings to grow or shrink.  Programs that used fixed-size
-   buffers, or that make assumptions that buffers will always be greater
-   than or less than particular sizes, are likely to fail in insecure
-   fashions when using Unicode normalization or encoding conversions.
-
-   Covering an extensive list of security threats and considerations on
-   the use of current and future versions of Unicode is outside of the
-   scope of this document.
-
-10. IANA Considerations
-
-   Stringprep profiles MUST have IETF consensus as described in
-   [RFC2434].  Each profile MUST be reviewed by the IESG before it is
-   registered.  The IESG MAY change a profile before registration.
-
-   IANA has set up a registry of stringprep profiles.  This registry is
-   a single text file that lists the known profiles.  Each entry in the
-   registry has three fields:
-
-   - Profile name
-
-   - RFC in which the profile is defined
-
-   - Indicator whether or not this is the newest version of the profile
-
-   Each version of a profile will remain listed in the registry forever.
-   That is, if a new version of a profile supersedes an earlier version,
-   both versions will continue to be listed in the registry, but the
-   current version indicator will be turned off for the earlier version
-   and turned on for the newer version.
 
-   It is probably harmful if a large number of profiles of stringprep
-   proliferate.  Therefore, the IESG may reject proposals for new
-   profiles and instead suggest that protocols reuse existing profiles.
 
 
 
 
+   0EDA-0EDB
 
+   0EDE-0EFF
 
+   0F48
 
+   0F6B-0F70
 
+   0F8C-0F8F
 
+   0F98
 
+   0FBD
 
+   0FCD-0FCE
 
-Hoffman & Blanchet          Standards Track                    [Page 21]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-11. Acknowledgements
-
-   Many people from the IETF IDN Working Group and the Unicode Technical
-   Committee contributed ideas that went into the first document of this
-   document.  Mark Davis and Patrik Faltstrom were particularly helpful
-   in some of the ideas, such as the versioning description.
-
-   The IDN nameprep design team made many useful changes to the first
-   document.  That team and its advisors include:
-
-   Asmus Freytag
-   Cathy Wissink
-   Francois Yergeau
-   James Seng
-   Marc Blanchet
-   Mark Davis
-   Martin Duerst
-   Patrik Faltstrom
-   Paul Hoffman
-
-   Additional significant improvements were proposed by:
-
-   Jonathan Rosenne
-   Kent Karlsson
-   Scott Hollenbeck
-   Dave Crocker
-   Erik Nordmark
-   Matitiahu Allouche
-
+   0FD0-0FFF
 
+   1022
 
+   1028
 
+   102B
 
+   1033-1035
 
+   103A-103F
 
+   105A-109F
 
+   10C6-10CF
 
+   10F9-10FA
 
+   10FC-10FF
 
+   115A-115E
 
+   11A3-11A7
 
+   11FA-11FF
 
+   1207
 
+   1247
 
+   1249
 
+   124E-124F
 
+   1257
 
+   1259
 
+   125E-125F
 
+   1287
 
+   1289
 
-Hoffman & Blanchet          Standards Track                    [Page 22]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   128E-128F
 
+   12AF
 
-A. Unicode repertoires
+   12B1
 
-   The following is the only repertoire covered in this document:
+   12B6-12B7
 
-   Unicode 3.2, as defined in [Unicode3.2].
+   12BF
 
-A.1 Unassigned code points in Unicode 3.2
+   12C1
 
-   ----- Start Table A.1 -----
-   0221
-   0234-024F
-   02AE-02AF
-   02EF-02FF
-   0350-035F
-   0370-0373
-   0376-0379
-   037B-037D
-   037F-0383
-   038B
-   038D
-   03A2
-   03CF
-   03F7-03FF
-   0487
-   04CF
-   04F6-04F7
-   04FA-04FF
-   0510-0530
-   0557-0558
-   0560
-   0588
-   058B-0590
-   05A2
-   05BA
-   05C5-05CF
-   05EB-05EF
-   05F5-060B
-   060D-061A
-   061C-061E
-   0620
-   063B-063F
-   0656-065F
-   06EE-06EF
-   06FF
-   070E
-   072D-072F
-   074B-077F
-   07B2-0900
+   12C6-12C7
 
+   12CF
 
+   12D7
 
-Hoffman & Blanchet          Standards Track                    [Page 23]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   12EF
 
+   130F
 
-   0904
-   093A-093B
-   094E-094F
-   0955-0957
-   0971-0980
-   0984
-   098D-098E
-   0991-0992
-   09A9
-   09B1
-   09B3-09B5
-   09BA-09BB
-   09BD
-   09C5-09C6
-   09C9-09CA
-   09CE-09D6
-   09D8-09DB
-   09DE
-   09E4-09E5
-   09FB-0A01
-   0A03-0A04
-   0A0B-0A0E
-   0A11-0A12
-   0A29
-   0A31
-   0A34
-   0A37
-   0A3A-0A3B
-   0A3D
-   0A43-0A46
-   0A49-0A4A
-   0A4E-0A58
-   0A5D
-   0A5F-0A65
-   0A75-0A80
-   0A84
-   0A8C
-   0A8E
-   0A92
-   0AA9
-   0AB1
-   0AB4
-   0ABA-0ABB
-   0AC6
-   0ACA
-   0ACE-0ACF
-   0AD1-0ADF
-   0AE1-0AE5
+   1311
 
+   1316-1317
 
+   131F
 
-Hoffman & Blanchet          Standards Track                    [Page 24]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   1347
 
+   135B-1360
 
-   0AF0-0B00
-   0B04
-   0B0D-0B0E
-   0B11-0B12
-   0B29
-   0B31
-   0B34-0B35
-   0B3A-0B3B
-   0B44-0B46
-   0B49-0B4A
-   0B4E-0B55
-   0B58-0B5B
-   0B5E
-   0B62-0B65
-   0B71-0B81
-   0B84
-   0B8B-0B8D
-   0B91
-   0B96-0B98
-   0B9B
-   0B9D
-   0BA0-0BA2
-   0BA5-0BA7
-   0BAB-0BAD
-   0BB6
-   0BBA-0BBD
-   0BC3-0BC5
-   0BC9
-   0BCE-0BD6
-   0BD8-0BE6
-   0BF3-0C00
-   0C04
-   0C0D
-   0C11
-   0C29
-   0C34
-   0C3A-0C3D
-   0C45
-   0C49
-   0C4E-0C54
-   0C57-0C5F
-   0C62-0C65
-   0C70-0C81
-   0C84
-   0C8D
-   0C91
-   0CA9
-   0CB4
+   137D-139F
 
+   13F5-1400
 
 
-Hoffman & Blanchet          Standards Track                    [Page 25]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
 
 
-   0CBA-0CBD
-   0CC5
-   0CC9
-   0CCE-0CD4
-   0CD7-0CDD
-   0CDF
-   0CE2-0CE5
-   0CF0-0D01
-   0D04
-   0D0D
-   0D11
-   0D29
-   0D3A-0D3D
-   0D44-0D45
-   0D49
-   0D4E-0D56
-   0D58-0D5F
-   0D62-0D65
-   0D70-0D81
-   0D84
-   0D97-0D99
-   0DB2
-   0DBC
-   0DBE-0DBF
-   0DC7-0DC9
-   0DCB-0DCE
-   0DD5
-   0DD7
-   0DE0-0DF1
-   0DF5-0E00
-   0E3B-0E3E
-   0E5C-0E80
-   0E83
-   0E85-0E86
-   0E89
-   0E8B-0E8C
-   0E8E-0E93
-   0E98
-   0EA0
-   0EA4
-   0EA6
-   0EA8-0EA9
-   0EAC
-   0EBA
-   0EBE-0EBF
-   0EC5
-   0EC7
-   0ECE-0ECF
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 26]
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0EDA-0EDB
-   0EDE-0EFF
-   0F48
-   0F6B-0F70
-   0F8C-0F8F
-   0F98
-   0FBD
-   0FCD-0FCE
-   0FD0-0FFF
-   1022
-   1028
-   102B
-   1033-1035
-   103A-103F
-   105A-109F
-   10C6-10CF
-   10F9-10FA
-   10FC-10FF
-   115A-115E
-   11A3-11A7
-   11FA-11FF
-   1207
-   1247
-   1249
-   124E-124F
-   1257
-   1259
-   125E-125F
-   1287
-   1289
-   128E-128F
-   12AF
-   12B1
-   12B6-12B7
-   12BF
-   12C1
-   12C6-12C7
-   12CF
-   12D7
-   12EF
-   130F
-   1311
-   1316-1317
-   131F
-   1347
-   135B-1360
-   137D-139F
-   13F5-1400
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 27]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
 
 
    1677-167F
+
    169D-169F
+
    16F1-16FF
+
    170D
+
    1715-171F
+
    1737-173F
+
    1754-175F
+
    176D
+
    1771
+
    1774-177F
+
    17DD-17DF
+
    17EA-17FF
+
    180F
+
    181A-181F
+
    1878-187F
+
    18AA-1DFF
+
    1E9C-1E9F
+
    1EFA-1EFF
+
    1F16-1F17
+
    1F1E-1F1F
+
    1F46-1F47
+
    1F4E-1F4F
+
    1F58
+
    1F5A
+
    1F5C
+
    1F5E
+
    1F7E-1F7F
+
    1FB5
+
    1FC5
+
    1FD4-1FD5
+
    1FDC
+
    1FF0-1FF1
+
    1FF5
+
    1FFF
+
    2053-2056
+
    2058-205E
+
    2064-2069
+
    2072-2073
+
    208F-209F
+
    20B2-20CF
+
    20EB-20FF
+
    213B-213C
+
    214C-2152
+
    2184-218F
+
    23CF-23FF
+
    2427-243F
+
    244B-245F
+
    24FF
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 28]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    2614-2615
+
    2618
+
    267E-267F
+
    268A-2700
+
    2705
+
    270A-270B
+
    2728
+
    274C
+
    274E
+
    2753-2755
+
    2757
+
    275F-2760
+
    2795-2797
+
    27B0
+
    27BF-27CF
+
    27EC-27EF
+
    2B00-2E7F
+
    2E9A
+
    2EF4-2EFF
+
    2FD6-2FEF
+
    2FFC-2FFF
+
    3040
+
    3097-3098
+
    3100-3104
+
    312D-3130
+
    318F
+
    31B8-31EF
+
    321D-321F
+
    3244-3250
+
    327C-327E
+
    32CC-32CF
+
    32FF
+
    3377-337A
+
    33DE-33DF
+
    33FF
+
    4DB6-4DFF
+
    9FA6-9FFF
+
    A48D-A48F
+
    A4C7-ABFF
+
    D7A4-D7FF
+
    FA2E-FA2F
+
    FA6B-FAFF
+
    FB07-FB12
+
    FB18-FB1C
+
    FB37
+
    FB3D
+
    FB3F
+
    FB42
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 29]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    FB45
+
    FBB2-FBD2
+
    FD40-FD4F
+
    FD90-FD91
+
    FDC8-FDCF
+
    FDFD-FDFF
+
    FE10-FE1F
+
    FE24-FE2F
+
    FE47-FE48
+
    FE53
+
    FE67
+
    FE6C-FE6F
+
    FE75
+
    FEFD-FEFE
+
    FF00
+
    FFBF-FFC1
+
    FFC8-FFC9
+
    FFD0-FFD1
+
    FFD8-FFD9
+
    FFDD-FFDF
+
    FFE7
+
    FFEF-FFF8
+
    10000-102FF
+
    1031F
+
    10324-1032F
+
    1034B-103FF
+
    10426-10427
+
    1044E-1CFFF
+
    1D0F6-1D0FF
+
    1D127-1D129
+
    1D1DE-1D3FF
+
    1D455
+
    1D49D
+
    1D4A0-1D4A1
+
    1D4A3-1D4A4
+
    1D4A7-1D4A8
+
    1D4AD
+
    1D4BA
+
    1D4BC
+
    1D4C1
+
    1D4C4
+
    1D506
+
    1D50B-1D50C
+
    1D515
+
    1D51D
+
    1D53A
+
    1D53F
+
    1D545
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 30]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1D547-1D549
+
    1D551
+
    1D6A4-1D6A7
+
    1D7CA-1D7CD
+
    1D800-1FFFD
+
    2A6D7-2F7FF
+
    2FA1E-2FFFD
+
    30000-3FFFD
+
    40000-4FFFD
+
    50000-5FFFD
+
    60000-6FFFD
+
    70000-7FFFD
+
    80000-8FFFD
+
    90000-9FFFD
+
    A0000-AFFFD
+
    B0000-BFFFD
+
    C0000-CFFFD
-   D0000-DFFFD
-   E0000
-   E0002-E001F
-   E0080-EFFFD
-   ----- End Table A.1 -----
 
-B. Mapping Tables
+   D0000-DFFFD
 
-   The following is the mapping table from section 3.  The table has
-   three columns:
+   E0000
 
-   - the code point that is mapped from
-   - the zero or more code points that it is mapped to
-   - the reason for the mapping
+   E0002-E001F
 
-   The columns are separated by semicolons.  Note that the second column
-   may be empty, or it may have one code point, or it may have more than
-   one code point, with each code point separated by a space.
+   E0080-EFFFD
 
-B.1 Commonly mapped to nothing
+   ----- End Table A.1 -----
 
    ----- Start Table B.1 -----
+
    00AD; ; Map to nothing
+
    034F; ; Map to nothing
+
    1806; ; Map to nothing
+
    180B; ; Map to nothing
+
    180C; ; Map to nothing
+
    180D; ; Map to nothing
+
    200B; ; Map to nothing
+
    200C; ; Map to nothing
+
    200D; ; Map to nothing
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 31]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    2060; ; Map to nothing
+
    FE00; ; Map to nothing
+
    FE01; ; Map to nothing
+
    FE02; ; Map to nothing
+
    FE03; ; Map to nothing
+
    FE04; ; Map to nothing
+
    FE05; ; Map to nothing
+
    FE06; ; Map to nothing
+
    FE07; ; Map to nothing
+
    FE08; ; Map to nothing
+
    FE09; ; Map to nothing
+
    FE0A; ; Map to nothing
+
    FE0B; ; Map to nothing
+
    FE0C; ; Map to nothing
+
    FE0D; ; Map to nothing
+
    FE0E; ; Map to nothing
+
    FE0F; ; Map to nothing
+
    FEFF; ; Map to nothing
-   ----- End Table B.1 -----
 
-B.2 Mapping for case-folding used with NFKC
+   ----- End Table B.1 -----
 
    ----- Start Table B.2 -----
+
    0041; 0061; Case map
+
    0042; 0062; Case map
+
    0043; 0063; Case map
+
    0044; 0064; Case map
+
    0045; 0065; Case map
+
    0046; 0066; Case map
+
    0047; 0067; Case map
+
    0048; 0068; Case map
+
    0049; 0069; Case map
+
    004A; 006A; Case map
+
    004B; 006B; Case map
+
    004C; 006C; Case map
+
    004D; 006D; Case map
+
    004E; 006E; Case map
+
    004F; 006F; Case map
+
    0050; 0070; Case map
+
    0051; 0071; Case map
+
    0052; 0072; Case map
+
    0053; 0073; Case map
+
    0054; 0074; Case map
+
    0055; 0075; Case map
+
    0056; 0076; Case map
+
    0057; 0077; Case map
+
    0058; 0078; Case map
+
    0059; 0079; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 32]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    005A; 007A; Case map
+
    00B5; 03BC; Case map
+
    00C0; 00E0; Case map
+
    00C1; 00E1; Case map
+
    00C2; 00E2; Case map
+
    00C3; 00E3; Case map
+
    00C4; 00E4; Case map
+
    00C5; 00E5; Case map
+
    00C6; 00E6; Case map
+
    00C7; 00E7; Case map
+
    00C8; 00E8; Case map
+
    00C9; 00E9; Case map
+
    00CA; 00EA; Case map
+
    00CB; 00EB; Case map
+
    00CC; 00EC; Case map
+
    00CD; 00ED; Case map
+
    00CE; 00EE; Case map
+
    00CF; 00EF; Case map
+
    00D0; 00F0; Case map
+
    00D1; 00F1; Case map
+
    00D2; 00F2; Case map
+
    00D3; 00F3; Case map
+
    00D4; 00F4; Case map
+
    00D5; 00F5; Case map
+
    00D6; 00F6; Case map
+
    00D8; 00F8; Case map
+
    00D9; 00F9; Case map
+
    00DA; 00FA; Case map
+
    00DB; 00FB; Case map
+
    00DC; 00FC; Case map
+
    00DD; 00FD; Case map
+
    00DE; 00FE; Case map
+
    00DF; 0073 0073; Case map
+
    0100; 0101; Case map
+
    0102; 0103; Case map
+
    0104; 0105; Case map
+
    0106; 0107; Case map
+
    0108; 0109; Case map
+
    010A; 010B; Case map
+
    010C; 010D; Case map
+
    010E; 010F; Case map
+
    0110; 0111; Case map
+
    0112; 0113; Case map
+
    0114; 0115; Case map
+
    0116; 0117; Case map
+
    0118; 0119; Case map
+
    011A; 011B; Case map
+
    011C; 011D; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 33]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    011E; 011F; Case map
+
    0120; 0121; Case map
+
    0122; 0123; Case map
+
    0124; 0125; Case map
+
    0126; 0127; Case map
+
    0128; 0129; Case map
+
    012A; 012B; Case map
+
    012C; 012D; Case map
+
    012E; 012F; Case map
+
    0130; 0069 0307; Case map
+
    0132; 0133; Case map
+
    0134; 0135; Case map
+
    0136; 0137; Case map
+
    0139; 013A; Case map
+
    013B; 013C; Case map
+
    013D; 013E; Case map
+
    013F; 0140; Case map
+
    0141; 0142; Case map
+
    0143; 0144; Case map
+
    0145; 0146; Case map
+
    0147; 0148; Case map
+
    0149; 02BC 006E; Case map
+
    014A; 014B; Case map
+
    014C; 014D; Case map
+
    014E; 014F; Case map
+
    0150; 0151; Case map
+
    0152; 0153; Case map
+
    0154; 0155; Case map
+
    0156; 0157; Case map
+
    0158; 0159; Case map
+
    015A; 015B; Case map
+
    015C; 015D; Case map
+
    015E; 015F; Case map
+
    0160; 0161; Case map
+
    0162; 0163; Case map
+
    0164; 0165; Case map
+
    0166; 0167; Case map
+
    0168; 0169; Case map
+
    016A; 016B; Case map
+
    016C; 016D; Case map
+
    016E; 016F; Case map
+
    0170; 0171; Case map
+
    0172; 0173; Case map
+
    0174; 0175; Case map
+
    0176; 0177; Case map
+
    0178; 00FF; Case map
+
    0179; 017A; Case map
+
    017B; 017C; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 34]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    017D; 017E; Case map
+
    017F; 0073; Case map
+
    0181; 0253; Case map
+
    0182; 0183; Case map
+
    0184; 0185; Case map
+
    0186; 0254; Case map
+
    0187; 0188; Case map
+
    0189; 0256; Case map
+
    018A; 0257; Case map
+
    018B; 018C; Case map
+
    018E; 01DD; Case map
+
    018F; 0259; Case map
+
    0190; 025B; Case map
+
    0191; 0192; Case map
+
    0193; 0260; Case map
+
    0194; 0263; Case map
+
    0196; 0269; Case map
+
    0197; 0268; Case map
+
    0198; 0199; Case map
+
    019C; 026F; Case map
+
    019D; 0272; Case map
+
    019F; 0275; Case map
+
    01A0; 01A1; Case map
+
    01A2; 01A3; Case map
+
    01A4; 01A5; Case map
+
    01A6; 0280; Case map
+
    01A7; 01A8; Case map
+
    01A9; 0283; Case map
+
    01AC; 01AD; Case map
+
    01AE; 0288; Case map
+
    01AF; 01B0; Case map
+
    01B1; 028A; Case map
+
    01B2; 028B; Case map
+
    01B3; 01B4; Case map
+
    01B5; 01B6; Case map
+
    01B7; 0292; Case map
+
    01B8; 01B9; Case map
+
    01BC; 01BD; Case map
+
    01C4; 01C6; Case map
+
    01C5; 01C6; Case map
+
    01C7; 01C9; Case map
+
    01C8; 01C9; Case map
+
    01CA; 01CC; Case map
+
    01CB; 01CC; Case map
+
    01CD; 01CE; Case map
+
    01CF; 01D0; Case map
+
    01D1; 01D2; Case map
+
    01D3; 01D4; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 35]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    01D5; 01D6; Case map
+
    01D7; 01D8; Case map
+
    01D9; 01DA; Case map
+
    01DB; 01DC; Case map
+
    01DE; 01DF; Case map
+
    01E0; 01E1; Case map
+
    01E2; 01E3; Case map
+
    01E4; 01E5; Case map
+
    01E6; 01E7; Case map
+
    01E8; 01E9; Case map
+
    01EA; 01EB; Case map
+
    01EC; 01ED; Case map
+
    01EE; 01EF; Case map
+
    01F0; 006A 030C; Case map
+
    01F1; 01F3; Case map
+
    01F2; 01F3; Case map
+
    01F4; 01F5; Case map
+
    01F6; 0195; Case map
+
    01F7; 01BF; Case map
+
    01F8; 01F9; Case map
+
    01FA; 01FB; Case map
+
    01FC; 01FD; Case map
+
    01FE; 01FF; Case map
+
    0200; 0201; Case map
+
    0202; 0203; Case map
+
    0204; 0205; Case map
+
    0206; 0207; Case map
+
    0208; 0209; Case map
+
    020A; 020B; Case map
+
    020C; 020D; Case map
+
    020E; 020F; Case map
+
    0210; 0211; Case map
+
    0212; 0213; Case map
+
    0214; 0215; Case map
+
    0216; 0217; Case map
+
    0218; 0219; Case map
+
    021A; 021B; Case map
+
    021C; 021D; Case map
+
    021E; 021F; Case map
+
    0220; 019E; Case map
+
    0222; 0223; Case map
+
    0224; 0225; Case map
+
    0226; 0227; Case map
+
    0228; 0229; Case map
+
    022A; 022B; Case map
+
    022C; 022D; Case map
+
    022E; 022F; Case map
+
    0230; 0231; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 36]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    0232; 0233; Case map
+
    0345; 03B9; Case map
+
    037A; 0020 03B9; Additional folding
+
    0386; 03AC; Case map
+
    0388; 03AD; Case map
+
    0389; 03AE; Case map
+
    038A; 03AF; Case map
+
    038C; 03CC; Case map
+
    038E; 03CD; Case map
+
    038F; 03CE; Case map
+
    0390; 03B9 0308 0301; Case map
+
    0391; 03B1; Case map
+
    0392; 03B2; Case map
+
    0393; 03B3; Case map
+
    0394; 03B4; Case map
+
    0395; 03B5; Case map
+
    0396; 03B6; Case map
+
    0397; 03B7; Case map
+
    0398; 03B8; Case map
+
    0399; 03B9; Case map
+
    039A; 03BA; Case map
+
    039B; 03BB; Case map
+
    039C; 03BC; Case map
+
    039D; 03BD; Case map
+
    039E; 03BE; Case map
+
    039F; 03BF; Case map
+
    03A0; 03C0; Case map
+
    03A1; 03C1; Case map
+
    03A3; 03C3; Case map
+
    03A4; 03C4; Case map
+
    03A5; 03C5; Case map
+
    03A6; 03C6; Case map
+
    03A7; 03C7; Case map
+
    03A8; 03C8; Case map
+
    03A9; 03C9; Case map
+
    03AA; 03CA; Case map
+
    03AB; 03CB; Case map
+
    03B0; 03C5 0308 0301; Case map
+
    03C2; 03C3; Case map
+
    03D0; 03B2; Case map
+
    03D1; 03B8; Case map
+
    03D2; 03C5; Additional folding
+
    03D3; 03CD; Additional folding
+
    03D4; 03CB; Additional folding
+
    03D5; 03C6; Case map
+
    03D6; 03C0; Case map
+
    03D8; 03D9; Case map
+
    03DA; 03DB; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 37]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    03DC; 03DD; Case map
+
    03DE; 03DF; Case map
+
    03E0; 03E1; Case map
+
    03E2; 03E3; Case map
+
    03E4; 03E5; Case map
+
    03E6; 03E7; Case map
+
    03E8; 03E9; Case map
+
    03EA; 03EB; Case map
+
    03EC; 03ED; Case map
+
    03EE; 03EF; Case map
+
    03F0; 03BA; Case map
+
    03F1; 03C1; Case map
+
    03F2; 03C3; Case map
+
    03F4; 03B8; Case map
+
    03F5; 03B5; Case map
+
    0400; 0450; Case map
+
    0401; 0451; Case map
+
    0402; 0452; Case map
+
    0403; 0453; Case map
+
    0404; 0454; Case map
+
    0405; 0455; Case map
+
    0406; 0456; Case map
+
    0407; 0457; Case map
+
    0408; 0458; Case map
+
    0409; 0459; Case map
+
    040A; 045A; Case map
+
    040B; 045B; Case map
+
    040C; 045C; Case map
+
    040D; 045D; Case map
+
    040E; 045E; Case map
+
    040F; 045F; Case map
+
    0410; 0430; Case map
+
    0411; 0431; Case map
+
    0412; 0432; Case map
+
    0413; 0433; Case map
+
    0414; 0434; Case map
+
    0415; 0435; Case map
+
    0416; 0436; Case map
+
    0417; 0437; Case map
+
    0418; 0438; Case map
+
    0419; 0439; Case map
+
    041A; 043A; Case map
+
    041B; 043B; Case map
+
    041C; 043C; Case map
+
    041D; 043D; Case map
+
    041E; 043E; Case map
+
    041F; 043F; Case map
+
    0420; 0440; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 38]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    0421; 0441; Case map
+
    0422; 0442; Case map
+
    0423; 0443; Case map
+
    0424; 0444; Case map
+
    0425; 0445; Case map
+
    0426; 0446; Case map
+
    0427; 0447; Case map
+
    0428; 0448; Case map
+
    0429; 0449; Case map
+
    042A; 044A; Case map
+
    042B; 044B; Case map
+
    042C; 044C; Case map
+
    042D; 044D; Case map
+
    042E; 044E; Case map
+
    042F; 044F; Case map
+
    0460; 0461; Case map
+
    0462; 0463; Case map
+
    0464; 0465; Case map
+
    0466; 0467; Case map
+
    0468; 0469; Case map
+
    046A; 046B; Case map
+
    046C; 046D; Case map
+
    046E; 046F; Case map
+
    0470; 0471; Case map
+
    0472; 0473; Case map
+
    0474; 0475; Case map
+
    0476; 0477; Case map
+
    0478; 0479; Case map
+
    047A; 047B; Case map
+
    047C; 047D; Case map
+
    047E; 047F; Case map
+
    0480; 0481; Case map
+
    048A; 048B; Case map
+
    048C; 048D; Case map
+
    048E; 048F; Case map
+
    0490; 0491; Case map
+
    0492; 0493; Case map
+
    0494; 0495; Case map
+
    0496; 0497; Case map
+
    0498; 0499; Case map
+
    049A; 049B; Case map
+
    049C; 049D; Case map
+
    049E; 049F; Case map
+
    04A0; 04A1; Case map
+
    04A2; 04A3; Case map
+
    04A4; 04A5; Case map
+
    04A6; 04A7; Case map
+
    04A8; 04A9; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 39]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    04AA; 04AB; Case map
+
    04AC; 04AD; Case map
+
    04AE; 04AF; Case map
+
    04B0; 04B1; Case map
+
    04B2; 04B3; Case map
+
    04B4; 04B5; Case map
+
    04B6; 04B7; Case map
+
    04B8; 04B9; Case map
+
    04BA; 04BB; Case map
+
    04BC; 04BD; Case map
+
    04BE; 04BF; Case map
+
    04C1; 04C2; Case map
+
    04C3; 04C4; Case map
+
    04C5; 04C6; Case map
+
    04C7; 04C8; Case map
+
    04C9; 04CA; Case map
+
    04CB; 04CC; Case map
+
    04CD; 04CE; Case map
+
    04D0; 04D1; Case map
+
    04D2; 04D3; Case map
+
    04D4; 04D5; Case map
+
    04D6; 04D7; Case map
+
    04D8; 04D9; Case map
+
    04DA; 04DB; Case map
+
    04DC; 04DD; Case map
+
    04DE; 04DF; Case map
+
    04E0; 04E1; Case map
+
    04E2; 04E3; Case map
+
    04E4; 04E5; Case map
+
    04E6; 04E7; Case map
+
    04E8; 04E9; Case map
+
    04EA; 04EB; Case map
+
    04EC; 04ED; Case map
+
    04EE; 04EF; Case map
+
    04F0; 04F1; Case map
+
    04F2; 04F3; Case map
+
    04F4; 04F5; Case map
+
    04F8; 04F9; Case map
+
    0500; 0501; Case map
+
    0502; 0503; Case map
+
    0504; 0505; Case map
+
    0506; 0507; Case map
+
    0508; 0509; Case map
+
    050A; 050B; Case map
+
    050C; 050D; Case map
+
    050E; 050F; Case map
+
    0531; 0561; Case map
+
    0532; 0562; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 40]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    0533; 0563; Case map
+
    0534; 0564; Case map
+
    0535; 0565; Case map
+
    0536; 0566; Case map
+
    0537; 0567; Case map
+
    0538; 0568; Case map
+
    0539; 0569; Case map
+
    053A; 056A; Case map
+
    053B; 056B; Case map
+
    053C; 056C; Case map
+
    053D; 056D; Case map
+
    053E; 056E; Case map
+
    053F; 056F; Case map
+
    0540; 0570; Case map
+
    0541; 0571; Case map
+
    0542; 0572; Case map
+
    0543; 0573; Case map
+
    0544; 0574; Case map
+
    0545; 0575; Case map
+
    0546; 0576; Case map
+
    0547; 0577; Case map
+
    0548; 0578; Case map
+
    0549; 0579; Case map
+
    054A; 057A; Case map
+
    054B; 057B; Case map
+
    054C; 057C; Case map
+
    054D; 057D; Case map
+
    054E; 057E; Case map
+
    054F; 057F; Case map
+
    0550; 0580; Case map
+
    0551; 0581; Case map
+
    0552; 0582; Case map
+
    0553; 0583; Case map
+
    0554; 0584; Case map
+
    0555; 0585; Case map
+
    0556; 0586; Case map
+
    0587; 0565 0582; Case map
+
    1E00; 1E01; Case map
+
    1E02; 1E03; Case map
+
    1E04; 1E05; Case map
+
    1E06; 1E07; Case map
+
    1E08; 1E09; Case map
+
    1E0A; 1E0B; Case map
+
    1E0C; 1E0D; Case map
+
    1E0E; 1E0F; Case map
+
    1E10; 1E11; Case map
+
    1E12; 1E13; Case map
+
    1E14; 1E15; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 41]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1E16; 1E17; Case map
+
    1E18; 1E19; Case map
+
    1E1A; 1E1B; Case map
+
    1E1C; 1E1D; Case map
+
    1E1E; 1E1F; Case map
+
    1E20; 1E21; Case map
+
    1E22; 1E23; Case map
+
    1E24; 1E25; Case map
+
    1E26; 1E27; Case map
+
    1E28; 1E29; Case map
+
    1E2A; 1E2B; Case map
+
    1E2C; 1E2D; Case map
+
    1E2E; 1E2F; Case map
+
    1E30; 1E31; Case map
+
    1E32; 1E33; Case map
+
    1E34; 1E35; Case map
+
    1E36; 1E37; Case map
+
    1E38; 1E39; Case map
+
    1E3A; 1E3B; Case map
+
    1E3C; 1E3D; Case map
+
    1E3E; 1E3F; Case map
+
    1E40; 1E41; Case map
+
    1E42; 1E43; Case map
+
    1E44; 1E45; Case map
+
    1E46; 1E47; Case map
+
    1E48; 1E49; Case map
+
    1E4A; 1E4B; Case map
+
    1E4C; 1E4D; Case map
+
    1E4E; 1E4F; Case map
+
    1E50; 1E51; Case map
+
    1E52; 1E53; Case map
+
    1E54; 1E55; Case map
+
    1E56; 1E57; Case map
+
    1E58; 1E59; Case map
+
    1E5A; 1E5B; Case map
+
    1E5C; 1E5D; Case map
+
    1E5E; 1E5F; Case map
+
    1E60; 1E61; Case map
+
    1E62; 1E63; Case map
+
    1E64; 1E65; Case map
+
    1E66; 1E67; Case map
+
    1E68; 1E69; Case map
+
    1E6A; 1E6B; Case map
+
    1E6C; 1E6D; Case map
+
    1E6E; 1E6F; Case map
+
    1E70; 1E71; Case map
+
    1E72; 1E73; Case map
+
    1E74; 1E75; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 42]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1E76; 1E77; Case map
+
    1E78; 1E79; Case map
+
    1E7A; 1E7B; Case map
+
    1E7C; 1E7D; Case map
+
    1E7E; 1E7F; Case map
+
    1E80; 1E81; Case map
+
    1E82; 1E83; Case map
+
    1E84; 1E85; Case map
+
    1E86; 1E87; Case map
+
    1E88; 1E89; Case map
+
    1E8A; 1E8B; Case map
+
    1E8C; 1E8D; Case map
+
    1E8E; 1E8F; Case map
+
    1E90; 1E91; Case map
+
    1E92; 1E93; Case map
+
    1E94; 1E95; Case map
+
    1E96; 0068 0331; Case map
+
    1E97; 0074 0308; Case map
+
    1E98; 0077 030A; Case map
+
    1E99; 0079 030A; Case map
+
    1E9A; 0061 02BE; Case map
+
    1E9B; 1E61; Case map
+
    1EA0; 1EA1; Case map
+
    1EA2; 1EA3; Case map
+
    1EA4; 1EA5; Case map
+
    1EA6; 1EA7; Case map
+
    1EA8; 1EA9; Case map
+
    1EAA; 1EAB; Case map
+
    1EAC; 1EAD; Case map
+
    1EAE; 1EAF; Case map
+
    1EB0; 1EB1; Case map
+
    1EB2; 1EB3; Case map
+
    1EB4; 1EB5; Case map
+
    1EB6; 1EB7; Case map
+
    1EB8; 1EB9; Case map
+
    1EBA; 1EBB; Case map
+
    1EBC; 1EBD; Case map
+
    1EBE; 1EBF; Case map
+
    1EC0; 1EC1; Case map
+
    1EC2; 1EC3; Case map
+
    1EC4; 1EC5; Case map
+
    1EC6; 1EC7; Case map
+
    1EC8; 1EC9; Case map
+
    1ECA; 1ECB; Case map
+
    1ECC; 1ECD; Case map
+
    1ECE; 1ECF; Case map
+
    1ED0; 1ED1; Case map
+
    1ED2; 1ED3; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 43]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1ED4; 1ED5; Case map
+
    1ED6; 1ED7; Case map
+
    1ED8; 1ED9; Case map
+
    1EDA; 1EDB; Case map
+
    1EDC; 1EDD; Case map
+
    1EDE; 1EDF; Case map
+
    1EE0; 1EE1; Case map
+
    1EE2; 1EE3; Case map
+
    1EE4; 1EE5; Case map
+
    1EE6; 1EE7; Case map
+
    1EE8; 1EE9; Case map
+
    1EEA; 1EEB; Case map
+
    1EEC; 1EED; Case map
+
    1EEE; 1EEF; Case map
+
    1EF0; 1EF1; Case map
+
    1EF2; 1EF3; Case map
+
    1EF4; 1EF5; Case map
+
    1EF6; 1EF7; Case map
+
    1EF8; 1EF9; Case map
+
    1F08; 1F00; Case map
+
    1F09; 1F01; Case map
+
    1F0A; 1F02; Case map
+
    1F0B; 1F03; Case map
+
    1F0C; 1F04; Case map
+
    1F0D; 1F05; Case map
+
    1F0E; 1F06; Case map
+
    1F0F; 1F07; Case map
+
    1F18; 1F10; Case map
+
    1F19; 1F11; Case map
+
    1F1A; 1F12; Case map
+
    1F1B; 1F13; Case map
+
    1F1C; 1F14; Case map
+
    1F1D; 1F15; Case map
+
    1F28; 1F20; Case map
+
    1F29; 1F21; Case map
+
    1F2A; 1F22; Case map
+
    1F2B; 1F23; Case map
+
    1F2C; 1F24; Case map
+
    1F2D; 1F25; Case map
+
    1F2E; 1F26; Case map
+
    1F2F; 1F27; Case map
+
    1F38; 1F30; Case map
+
    1F39; 1F31; Case map
+
    1F3A; 1F32; Case map
+
    1F3B; 1F33; Case map
+
    1F3C; 1F34; Case map
+
    1F3D; 1F35; Case map
+
    1F3E; 1F36; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 44]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1F3F; 1F37; Case map
+
    1F48; 1F40; Case map
+
    1F49; 1F41; Case map
+
    1F4A; 1F42; Case map
+
    1F4B; 1F43; Case map
+
    1F4C; 1F44; Case map
+
    1F4D; 1F45; Case map
+
    1F50; 03C5 0313; Case map
+
    1F52; 03C5 0313 0300; Case map
+
    1F54; 03C5 0313 0301; Case map
+
    1F56; 03C5 0313 0342; Case map
+
    1F59; 1F51; Case map
+
    1F5B; 1F53; Case map
+
    1F5D; 1F55; Case map
+
    1F5F; 1F57; Case map
+
    1F68; 1F60; Case map
+
    1F69; 1F61; Case map
+
    1F6A; 1F62; Case map
+
    1F6B; 1F63; Case map
+
    1F6C; 1F64; Case map
+
    1F6D; 1F65; Case map
+
    1F6E; 1F66; Case map
+
    1F6F; 1F67; Case map
+
    1F80; 1F00 03B9; Case map
+
    1F81; 1F01 03B9; Case map
+
    1F82; 1F02 03B9; Case map
+
    1F83; 1F03 03B9; Case map
+
    1F84; 1F04 03B9; Case map
+
    1F85; 1F05 03B9; Case map
+
    1F86; 1F06 03B9; Case map
+
    1F87; 1F07 03B9; Case map
+
    1F88; 1F00 03B9; Case map
+
    1F89; 1F01 03B9; Case map
+
    1F8A; 1F02 03B9; Case map
+
    1F8B; 1F03 03B9; Case map
+
    1F8C; 1F04 03B9; Case map
+
    1F8D; 1F05 03B9; Case map
+
    1F8E; 1F06 03B9; Case map
+
    1F8F; 1F07 03B9; Case map
+
    1F90; 1F20 03B9; Case map
+
    1F91; 1F21 03B9; Case map
+
    1F92; 1F22 03B9; Case map
+
    1F93; 1F23 03B9; Case map
+
    1F94; 1F24 03B9; Case map
+
    1F95; 1F25 03B9; Case map
+
    1F96; 1F26 03B9; Case map
+
    1F97; 1F27 03B9; Case map
+
    1F98; 1F20 03B9; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 45]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1F99; 1F21 03B9; Case map
+
    1F9A; 1F22 03B9; Case map
+
    1F9B; 1F23 03B9; Case map
+
    1F9C; 1F24 03B9; Case map
+
    1F9D; 1F25 03B9; Case map
+
    1F9E; 1F26 03B9; Case map
+
    1F9F; 1F27 03B9; Case map
+
    1FA0; 1F60 03B9; Case map
+
    1FA1; 1F61 03B9; Case map
+
    1FA2; 1F62 03B9; Case map
+
    1FA3; 1F63 03B9; Case map
+
    1FA4; 1F64 03B9; Case map
+
    1FA5; 1F65 03B9; Case map
+
    1FA6; 1F66 03B9; Case map
+
    1FA7; 1F67 03B9; Case map
+
    1FA8; 1F60 03B9; Case map
+
    1FA9; 1F61 03B9; Case map
+
    1FAA; 1F62 03B9; Case map
+
    1FAB; 1F63 03B9; Case map
+
    1FAC; 1F64 03B9; Case map
+
    1FAD; 1F65 03B9; Case map
+
    1FAE; 1F66 03B9; Case map
+
    1FAF; 1F67 03B9; Case map
+
    1FB2; 1F70 03B9; Case map
+
    1FB3; 03B1 03B9; Case map
+
    1FB4; 03AC 03B9; Case map
+
    1FB6; 03B1 0342; Case map
+
    1FB7; 03B1 0342 03B9; Case map
+
    1FB8; 1FB0; Case map
+
    1FB9; 1FB1; Case map
+
    1FBA; 1F70; Case map
+
    1FBB; 1F71; Case map
+
    1FBC; 03B1 03B9; Case map
+
    1FBE; 03B9; Case map
+
    1FC2; 1F74 03B9; Case map
+
    1FC3; 03B7 03B9; Case map
+
    1FC4; 03AE 03B9; Case map
+
    1FC6; 03B7 0342; Case map
+
    1FC7; 03B7 0342 03B9; Case map
+
    1FC8; 1F72; Case map
+
    1FC9; 1F73; Case map
+
    1FCA; 1F74; Case map
+
    1FCB; 1F75; Case map
+
    1FCC; 03B7 03B9; Case map
+
    1FD2; 03B9 0308 0300; Case map
+
    1FD3; 03B9 0308 0301; Case map
+
    1FD6; 03B9 0342; Case map
+
    1FD7; 03B9 0308 0342; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 46]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1FD8; 1FD0; Case map
+
    1FD9; 1FD1; Case map
+
    1FDA; 1F76; Case map
+
    1FDB; 1F77; Case map
+
    1FE2; 03C5 0308 0300; Case map
+
    1FE3; 03C5 0308 0301; Case map
+
    1FE4; 03C1 0313; Case map
+
    1FE6; 03C5 0342; Case map
+
    1FE7; 03C5 0308 0342; Case map
+
    1FE8; 1FE0; Case map
+
    1FE9; 1FE1; Case map
+
    1FEA; 1F7A; Case map
+
    1FEB; 1F7B; Case map
+
    1FEC; 1FE5; Case map
+
    1FF2; 1F7C 03B9; Case map
+
    1FF3; 03C9 03B9; Case map
+
    1FF4; 03CE 03B9; Case map
+
    1FF6; 03C9 0342; Case map
+
    1FF7; 03C9 0342 03B9; Case map
+
    1FF8; 1F78; Case map
+
    1FF9; 1F79; Case map
+
    1FFA; 1F7C; Case map
+
    1FFB; 1F7D; Case map
+
    1FFC; 03C9 03B9; Case map
+
    20A8; 0072 0073; Additional folding
+
    2102; 0063; Additional folding
+
    2103; 00B0 0063; Additional folding
+
    2107; 025B; Additional folding
+
    2109; 00B0 0066; Additional folding
+
    210B; 0068; Additional folding
+
    210C; 0068; Additional folding
+
    210D; 0068; Additional folding
+
    2110; 0069; Additional folding
+
    2111; 0069; Additional folding
+
    2112; 006C; Additional folding
+
    2115; 006E; Additional folding
+
    2116; 006E 006F; Additional folding
+
    2119; 0070; Additional folding
+
    211A; 0071; Additional folding
+
    211B; 0072; Additional folding
+
    211C; 0072; Additional folding
+
    211D; 0072; Additional folding
+
    2120; 0073 006D; Additional folding
+
    2121; 0074 0065 006C; Additional folding
+
    2122; 0074 006D; Additional folding
+
    2124; 007A; Additional folding
+
    2126; 03C9; Case map
+
    2128; 007A; Additional folding
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 47]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    212A; 006B; Case map
+
    212B; 00E5; Case map
+
    212C; 0062; Additional folding
+
    212D; 0063; Additional folding
+
    2130; 0065; Additional folding
+
    2131; 0066; Additional folding
+
    2133; 006D; Additional folding
+
    213E; 03B3; Additional folding
+
    213F; 03C0; Additional folding
+
    2145; 0064; Additional folding
+
    2160; 2170; Case map
+
    2161; 2171; Case map
+
    2162; 2172; Case map
+
    2163; 2173; Case map
+
    2164; 2174; Case map
+
    2165; 2175; Case map
+
    2166; 2176; Case map
+
    2167; 2177; Case map
+
    2168; 2178; Case map
+
    2169; 2179; Case map
+
    216A; 217A; Case map
+
    216B; 217B; Case map
+
    216C; 217C; Case map
+
    216D; 217D; Case map
+
    216E; 217E; Case map
+
    216F; 217F; Case map
+
    24B6; 24D0; Case map
+
    24B7; 24D1; Case map
+
    24B8; 24D2; Case map
+
    24B9; 24D3; Case map
+
    24BA; 24D4; Case map
+
    24BB; 24D5; Case map
+
    24BC; 24D6; Case map
+
    24BD; 24D7; Case map
+
    24BE; 24D8; Case map
+
    24BF; 24D9; Case map
+
    24C0; 24DA; Case map
+
    24C1; 24DB; Case map
+
    24C2; 24DC; Case map
+
    24C3; 24DD; Case map
+
    24C4; 24DE; Case map
+
    24C5; 24DF; Case map
+
    24C6; 24E0; Case map
+
    24C7; 24E1; Case map
+
    24C8; 24E2; Case map
+
    24C9; 24E3; Case map
+
    24CA; 24E4; Case map
+
    24CB; 24E5; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 48]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    24CC; 24E6; Case map
+
    24CD; 24E7; Case map
+
    24CE; 24E8; Case map
+
    24CF; 24E9; Case map
+
    3371; 0068 0070 0061; Additional folding
+
    3373; 0061 0075; Additional folding
+
    3375; 006F 0076; Additional folding
+
    3380; 0070 0061; Additional folding
+
    3381; 006E 0061; Additional folding
+
    3382; 03BC 0061; Additional folding
+
    3383; 006D 0061; Additional folding
+
    3384; 006B 0061; Additional folding
+
    3385; 006B 0062; Additional folding
+
    3386; 006D 0062; Additional folding
+
    3387; 0067 0062; Additional folding
+
    338A; 0070 0066; Additional folding
+
    338B; 006E 0066; Additional folding
+
    338C; 03BC 0066; Additional folding
+
    3390; 0068 007A; Additional folding
+
    3391; 006B 0068 007A; Additional folding
+
    3392; 006D 0068 007A; Additional folding
+
    3393; 0067 0068 007A; Additional folding
+
    3394; 0074 0068 007A; Additional folding
+
    33A9; 0070 0061; Additional folding
+
    33AA; 006B 0070 0061; Additional folding
+
    33AB; 006D 0070 0061; Additional folding
+
    33AC; 0067 0070 0061; Additional folding
+
    33B4; 0070 0076; Additional folding
+
    33B5; 006E 0076; Additional folding
+
    33B6; 03BC 0076; Additional folding
+
    33B7; 006D 0076; Additional folding
+
    33B8; 006B 0076; Additional folding
+
    33B9; 006D 0076; Additional folding
+
    33BA; 0070 0077; Additional folding
+
    33BB; 006E 0077; Additional folding
+
    33BC; 03BC 0077; Additional folding
+
    33BD; 006D 0077; Additional folding
+
    33BE; 006B 0077; Additional folding
+
    33BF; 006D 0077; Additional folding
+
    33C0; 006B 03C9; Additional folding
+
    33C1; 006D 03C9; Additional folding
+
    33C3; 0062 0071; Additional folding
+
    33C6; 0063 2215 006B 0067; Additional folding
+
    33C7; 0063 006F 002E; Additional folding
+
    33C8; 0064 0062; Additional folding
+
    33C9; 0067 0079; Additional folding
+
    33CB; 0068 0070; Additional folding
+
    33CD; 006B 006B; Additional folding
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 49]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    33CE; 006B 006D; Additional folding
+
    33D7; 0070 0068; Additional folding
+
    33D9; 0070 0070 006D; Additional folding
+
    33DA; 0070 0072; Additional folding
+
    33DC; 0073 0076; Additional folding
+
    33DD; 0077 0062; Additional folding
+
    FB00; 0066 0066; Case map
+
    FB01; 0066 0069; Case map
+
    FB02; 0066 006C; Case map
+
    FB03; 0066 0066 0069; Case map
+
    FB04; 0066 0066 006C; Case map
+
    FB05; 0073 0074; Case map
+
    FB06; 0073 0074; Case map
+
    FB13; 0574 0576; Case map
+
    FB14; 0574 0565; Case map
+
    FB15; 0574 056B; Case map
+
    FB16; 057E 0576; Case map
+
    FB17; 0574 056D; Case map
+
    FF21; FF41; Case map
+
    FF22; FF42; Case map
+
    FF23; FF43; Case map
+
    FF24; FF44; Case map
+
    FF25; FF45; Case map
+
    FF26; FF46; Case map
+
    FF27; FF47; Case map
+
    FF28; FF48; Case map
+
    FF29; FF49; Case map
+
    FF2A; FF4A; Case map
+
    FF2B; FF4B; Case map
+
    FF2C; FF4C; Case map
+
    FF2D; FF4D; Case map
+
    FF2E; FF4E; Case map
+
    FF2F; FF4F; Case map
+
    FF30; FF50; Case map
+
    FF31; FF51; Case map
+
    FF32; FF52; Case map
+
    FF33; FF53; Case map
+
    FF34; FF54; Case map
+
    FF35; FF55; Case map
+
    FF36; FF56; Case map
+
    FF37; FF57; Case map
+
    FF38; FF58; Case map
+
    FF39; FF59; Case map
+
    FF3A; FF5A; Case map
+
    10400; 10428; Case map
+
    10401; 10429; Case map
+
    10402; 1042A; Case map
+
    10403; 1042B; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 50]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    10404; 1042C; Case map
+
    10405; 1042D; Case map
+
    10406; 1042E; Case map
+
    10407; 1042F; Case map
+
    10408; 10430; Case map
+
    10409; 10431; Case map
+
    1040A; 10432; Case map
+
    1040B; 10433; Case map
+
    1040C; 10434; Case map
+
    1040D; 10435; Case map
+
    1040E; 10436; Case map
+
    1040F; 10437; Case map
+
    10410; 10438; Case map
+
    10411; 10439; Case map
+
    10412; 1043A; Case map
+
    10413; 1043B; Case map
+
    10414; 1043C; Case map
+
    10415; 1043D; Case map
+
    10416; 1043E; Case map
+
    10417; 1043F; Case map
+
    10418; 10440; Case map
+
    10419; 10441; Case map
+
    1041A; 10442; Case map
+
    1041B; 10443; Case map
+
    1041C; 10444; Case map
+
    1041D; 10445; Case map
+
    1041E; 10446; Case map
+
    1041F; 10447; Case map
+
    10420; 10448; Case map
+
    10421; 10449; Case map
+
    10422; 1044A; Case map
+
    10423; 1044B; Case map
+
    10424; 1044C; Case map
+
    10425; 1044D; Case map
+
    1D400; 0061; Additional folding
+
    1D401; 0062; Additional folding
+
    1D402; 0063; Additional folding
+
    1D403; 0064; Additional folding
+
    1D404; 0065; Additional folding
+
    1D405; 0066; Additional folding
+
    1D406; 0067; Additional folding
+
    1D407; 0068; Additional folding
+
    1D408; 0069; Additional folding
+
    1D409; 006A; Additional folding
+
    1D40A; 006B; Additional folding
+
    1D40B; 006C; Additional folding
+
    1D40C; 006D; Additional folding
+
    1D40D; 006E; Additional folding
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 51]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1D40E; 006F; Additional folding
+
    1D40F; 0070; Additional folding
+
    1D410; 0071; Additional folding
+
    1D411; 0072; Additional folding
+
    1D412; 0073; Additional folding
+
    1D413; 0074; Additional folding
+
    1D414; 0075; Additional folding
+
    1D415; 0076; Additional folding
+
    1D416; 0077; Additional folding
+
    1D417; 0078; Additional folding
+
    1D418; 0079; Additional folding
+
    1D419; 007A; Additional folding
+
    1D434; 0061; Additional folding
+
    1D435; 0062; Additional folding
+
    1D436; 0063; Additional folding
+
    1D437; 0064; Additional folding
+
    1D438; 0065; Additional folding
+
    1D439; 0066; Additional folding
+
    1D43A; 0067; Additional folding
+
    1D43B; 0068; Additional folding
+
    1D43C; 0069; Additional folding
+
    1D43D; 006A; Additional folding
+
    1D43E; 006B; Additional folding
+
    1D43F; 006C; Additional folding
+
    1D440; 006D; Additional folding
+
    1D441; 006E; Additional folding
+
    1D442; 006F; Additional folding
+
    1D443; 0070; Additional folding
+
    1D444; 0071; Additional folding
+
    1D445; 0072; Additional folding
+
    1D446; 0073; Additional folding
+
    1D447; 0074; Additional folding
+
    1D448; 0075; Additional folding
+
    1D449; 0076; Additional folding
+
    1D44A; 0077; Additional folding
+
    1D44B; 0078; Additional folding
+
    1D44C; 0079; Additional folding
+
    1D44D; 007A; Additional folding
+
    1D468; 0061; Additional folding
+
    1D469; 0062; Additional folding
+
    1D46A; 0063; Additional folding
+
    1D46B; 0064; Additional folding
+
    1D46C; 0065; Additional folding
+
    1D46D; 0066; Additional folding
+
    1D46E; 0067; Additional folding
+
    1D46F; 0068; Additional folding
+
    1D470; 0069; Additional folding
+
    1D471; 006A; Additional folding
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 52]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1D472; 006B; Additional folding
+
    1D473; 006C; Additional folding
+
    1D474; 006D; Additional folding
+
    1D475; 006E; Additional folding
+
    1D476; 006F; Additional folding
+
    1D477; 0070; Additional folding
+
    1D478; 0071; Additional folding
+
    1D479; 0072; Additional folding
+
    1D47A; 0073; Additional folding
+
    1D47B; 0074; Additional folding
+
    1D47C; 0075; Additional folding
+
    1D47D; 0076; Additional folding
+
    1D47E; 0077; Additional folding
+
    1D47F; 0078; Additional folding
+
    1D480; 0079; Additional folding
+
    1D481; 007A; Additional folding
+
    1D49C; 0061; Additional folding
+
    1D49E; 0063; Additional folding
+
    1D49F; 0064; Additional folding
+
    1D4A2; 0067; Additional folding
+
    1D4A5; 006A; Additional folding
+
    1D4A6; 006B; Additional folding
+
    1D4A9; 006E; Additional folding
+
    1D4AA; 006F; Additional folding
+
    1D4AB; 0070; Additional folding
+
    1D4AC; 0071; Additional folding
+
    1D4AE; 0073; Additional folding
+
    1D4AF; 0074; Additional folding
+
    1D4B0; 0075; Additional folding
+
    1D4B1; 0076; Additional folding
+
    1D4B2; 0077; Additional folding
+
    1D4B3; 0078; Additional folding
+
    1D4B4; 0079; Additional folding
+
    1D4B5; 007A; Additional folding
+
    1D4D0; 0061; Additional folding
+
    1D4D1; 0062; Additional folding
+
    1D4D2; 0063; Additional folding
+
    1D4D3; 0064; Additional folding
+
    1D4D4; 0065; Additional folding
+
    1D4D5; 0066; Additional folding
+
    1D4D6; 0067; Additional folding
+
    1D4D7; 0068; Additional folding
+
    1D4D8; 0069; Additional folding
+
    1D4D9; 006A; Additional folding
+
    1D4DA; 006B; Additional folding
+
    1D4DB; 006C; Additional folding
+
    1D4DC; 006D; Additional folding
+
    1D4DD; 006E; Additional folding
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 53]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1D4DE; 006F; Additional folding
+
    1D4DF; 0070; Additional folding
+
    1D4E0; 0071; Additional folding
+
    1D4E1; 0072; Additional folding
+
    1D4E2; 0073; Additional folding
+
    1D4E3; 0074; Additional folding
+
    1D4E4; 0075; Additional folding
+
    1D4E5; 0076; Additional folding
+
    1D4E6; 0077; Additional folding
+
    1D4E7; 0078; Additional folding
+
    1D4E8; 0079; Additional folding
+
    1D4E9; 007A; Additional folding
+
    1D504; 0061; Additional folding
+
    1D505; 0062; Additional folding
+
    1D507; 0064; Additional folding
+
    1D508; 0065; Additional folding
+
    1D509; 0066; Additional folding
+
    1D50A; 0067; Additional folding
+
    1D50D; 006A; Additional folding
+
    1D50E; 006B; Additional folding
+
    1D50F; 006C; Additional folding
+
    1D510; 006D; Additional folding
+
    1D511; 006E; Additional folding
+
    1D512; 006F; Additional folding
+
    1D513; 0070; Additional folding
+
    1D514; 0071; Additional folding
+
    1D516; 0073; Additional folding
+
    1D517; 0074; Additional folding
+
    1D518; 0075; Additional folding
+
    1D519; 0076; Additional folding
+
    1D51A; 0077; Additional folding
+
    1D51B; 0078; Additional folding
+
    1D51C; 0079; Additional folding
+
    1D538; 0061; Additional folding
+
    1D539; 0062; Additional folding
+
    1D53B; 0064; Additional folding
+
    1D53C; 0065; Additional folding
+
    1D53D; 0066; Additional folding
+
    1D53E; 0067; Additional folding
+
    1D540; 0069; Additional folding
+
    1D541; 006A; Additional folding
+
    1D542; 006B; Additional folding
+
    1D543; 006C; Additional folding
+
    1D544; 006D; Additional folding
+
    1D546; 006F; Additional folding
+
    1D54A; 0073; Additional folding
+
    1D54B; 0074; Additional folding
+
    1D54C; 0075; Additional folding
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 54]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1D54D; 0076; Additional folding
+
    1D54E; 0077; Additional folding
+
    1D54F; 0078; Additional folding
+
    1D550; 0079; Additional folding
+
    1D56C; 0061; Additional folding
+
    1D56D; 0062; Additional folding
+
    1D56E; 0063; Additional folding
+
    1D56F; 0064; Additional folding
+
    1D570; 0065; Additional folding
+
    1D571; 0066; Additional folding
+
    1D572; 0067; Additional folding
+
    1D573; 0068; Additional folding
+
    1D574; 0069; Additional folding
+
    1D575; 006A; Additional folding
+
    1D576; 006B; Additional folding
+
    1D577; 006C; Additional folding
+
    1D578; 006D; Additional folding
+
    1D579; 006E; Additional folding
+
    1D57A; 006F; Additional folding
+
    1D57B; 0070; Additional folding
+
    1D57C; 0071; Additional folding
+
    1D57D; 0072; Additional folding
+
    1D57E; 0073; Additional folding
+
    1D57F; 0074; Additional folding
+
    1D580; 0075; Additional folding
+
    1D581; 0076; Additional folding
+
    1D582; 0077; Additional folding
+
    1D583; 0078; Additional folding
+
    1D584; 0079; Additional folding
+
    1D585; 007A; Additional folding
+
    1D5A0; 0061; Additional folding
+
    1D5A1; 0062; Additional folding
+
    1D5A2; 0063; Additional folding
+
    1D5A3; 0064; Additional folding
+
    1D5A4; 0065; Additional folding
+
    1D5A5; 0066; Additional folding
+
    1D5A6; 0067; Additional folding
+
    1D5A7; 0068; Additional folding
+
    1D5A8; 0069; Additional folding
+
    1D5A9; 006A; Additional folding
+
    1D5AA; 006B; Additional folding
+
    1D5AB; 006C; Additional folding
+
    1D5AC; 006D; Additional folding
+
    1D5AD; 006E; Additional folding
+
    1D5AE; 006F; Additional folding
+
    1D5AF; 0070; Additional folding
+
    1D5B0; 0071; Additional folding
+
    1D5B1; 0072; Additional folding
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 55]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1D5B2; 0073; Additional folding
+
    1D5B3; 0074; Additional folding
+
    1D5B4; 0075; Additional folding
+
    1D5B5; 0076; Additional folding
+
    1D5B6; 0077; Additional folding
+
    1D5B7; 0078; Additional folding
+
    1D5B8; 0079; Additional folding
+
    1D5B9; 007A; Additional folding
+
    1D5D4; 0061; Additional folding
+
    1D5D5; 0062; Additional folding
+
    1D5D6; 0063; Additional folding
+
    1D5D7; 0064; Additional folding
+
    1D5D8; 0065; Additional folding
+
    1D5D9; 0066; Additional folding
+
    1D5DA; 0067; Additional folding
+
    1D5DB; 0068; Additional folding
+
    1D5DC; 0069; Additional folding
+
    1D5DD; 006A; Additional folding
+
    1D5DE; 006B; Additional folding
+
    1D5DF; 006C; Additional folding
+
    1D5E0; 006D; Additional folding
+
    1D5E1; 006E; Additional folding
+
    1D5E2; 006F; Additional folding
+
    1D5E3; 0070; Additional folding
+
    1D5E4; 0071; Additional folding
+
    1D5E5; 0072; Additional folding
+
    1D5E6; 0073; Additional folding
+
    1D5E7; 0074; Additional folding
+
    1D5E8; 0075; Additional folding
+
    1D5E9; 0076; Additional folding
+
    1D5EA; 0077; Additional folding
+
    1D5EB; 0078; Additional folding
+
    1D5EC; 0079; Additional folding
+
    1D5ED; 007A; Additional folding
+
    1D608; 0061; Additional folding
+
    1D609; 0062; Additional folding
+
    1D60A; 0063; Additional folding
+
    1D60B; 0064; Additional folding
+
    1D60C; 0065; Additional folding
+
    1D60D; 0066; Additional folding
+
    1D60E; 0067; Additional folding
+
    1D60F; 0068; Additional folding
+
    1D610; 0069; Additional folding
+
    1D611; 006A; Additional folding
+
    1D612; 006B; Additional folding
+
    1D613; 006C; Additional folding
+
    1D614; 006D; Additional folding
+
    1D615; 006E; Additional folding
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 56]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1D616; 006F; Additional folding
+
    1D617; 0070; Additional folding
+
    1D618; 0071; Additional folding
+
    1D619; 0072; Additional folding
+
    1D61A; 0073; Additional folding
+
    1D61B; 0074; Additional folding
+
    1D61C; 0075; Additional folding
+
    1D61D; 0076; Additional folding
+
    1D61E; 0077; Additional folding
+
    1D61F; 0078; Additional folding
+
    1D620; 0079; Additional folding
+
    1D621; 007A; Additional folding
+
    1D63C; 0061; Additional folding
+
    1D63D; 0062; Additional folding
+
    1D63E; 0063; Additional folding
+
    1D63F; 0064; Additional folding
+
    1D640; 0065; Additional folding
+
    1D641; 0066; Additional folding
+
    1D642; 0067; Additional folding
+
    1D643; 0068; Additional folding
+
    1D644; 0069; Additional folding
+
    1D645; 006A; Additional folding
+
    1D646; 006B; Additional folding
+
    1D647; 006C; Additional folding
+
    1D648; 006D; Additional folding
+
    1D649; 006E; Additional folding
+
    1D64A; 006F; Additional folding
+
    1D64B; 0070; Additional folding
+
    1D64C; 0071; Additional folding
+
    1D64D; 0072; Additional folding
+
    1D64E; 0073; Additional folding
+
    1D64F; 0074; Additional folding
+
    1D650; 0075; Additional folding
+
    1D651; 0076; Additional folding
+
    1D652; 0077; Additional folding
+
    1D653; 0078; Additional folding
+
    1D654; 0079; Additional folding
+
    1D655; 007A; Additional folding
+
    1D670; 0061; Additional folding
+
    1D671; 0062; Additional folding
+
    1D672; 0063; Additional folding
+
    1D673; 0064; Additional folding
+
    1D674; 0065; Additional folding
+
    1D675; 0066; Additional folding
+
    1D676; 0067; Additional folding
+
    1D677; 0068; Additional folding
+
    1D678; 0069; Additional folding
+
    1D679; 006A; Additional folding
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 57]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1D67A; 006B; Additional folding
+
    1D67B; 006C; Additional folding
+
    1D67C; 006D; Additional folding
+
    1D67D; 006E; Additional folding
+
    1D67E; 006F; Additional folding
+
    1D67F; 0070; Additional folding
+
    1D680; 0071; Additional folding
+
    1D681; 0072; Additional folding
+
    1D682; 0073; Additional folding
+
    1D683; 0074; Additional folding
+
    1D684; 0075; Additional folding
+
    1D685; 0076; Additional folding
+
    1D686; 0077; Additional folding
+
    1D687; 0078; Additional folding
+
    1D688; 0079; Additional folding
+
    1D689; 007A; Additional folding
+
    1D6A8; 03B1; Additional folding
+
    1D6A9; 03B2; Additional folding
+
    1D6AA; 03B3; Additional folding
+
    1D6AB; 03B4; Additional folding
+
    1D6AC; 03B5; Additional folding
+
    1D6AD; 03B6; Additional folding
+
    1D6AE; 03B7; Additional folding
+
    1D6AF; 03B8; Additional folding
+
    1D6B0; 03B9; Additional folding
+
    1D6B1; 03BA; Additional folding
+
    1D6B2; 03BB; Additional folding
+
    1D6B3; 03BC; Additional folding
+
    1D6B4; 03BD; Additional folding
+
    1D6B5; 03BE; Additional folding
+
    1D6B6; 03BF; Additional folding
+
    1D6B7; 03C0; Additional folding
+
    1D6B8; 03C1; Additional folding
+
    1D6B9; 03B8; Additional folding
+
    1D6BA; 03C3; Additional folding
+
    1D6BB; 03C4; Additional folding
+
    1D6BC; 03C5; Additional folding
+
    1D6BD; 03C6; Additional folding
+
    1D6BE; 03C7; Additional folding
+
    1D6BF; 03C8; Additional folding
+
    1D6C0; 03C9; Additional folding
+
    1D6D3; 03C3; Additional folding
+
    1D6E2; 03B1; Additional folding
+
    1D6E3; 03B2; Additional folding
+
    1D6E4; 03B3; Additional folding
+
    1D6E5; 03B4; Additional folding
+
    1D6E6; 03B5; Additional folding
+
    1D6E7; 03B6; Additional folding
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 58]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1D6E8; 03B7; Additional folding
+
    1D6E9; 03B8; Additional folding
+
    1D6EA; 03B9; Additional folding
+
    1D6EB; 03BA; Additional folding
+
    1D6EC; 03BB; Additional folding
+
    1D6ED; 03BC; Additional folding
+
    1D6EE; 03BD; Additional folding
+
    1D6EF; 03BE; Additional folding
+
    1D6F0; 03BF; Additional folding
+
    1D6F1; 03C0; Additional folding
+
    1D6F2; 03C1; Additional folding
+
    1D6F3; 03B8; Additional folding
+
    1D6F4; 03C3; Additional folding
+
    1D6F5; 03C4; Additional folding
+
    1D6F6; 03C5; Additional folding
+
    1D6F7; 03C6; Additional folding
+
    1D6F8; 03C7; Additional folding
+
    1D6F9; 03C8; Additional folding
+
    1D6FA; 03C9; Additional folding
+
    1D70D; 03C3; Additional folding
+
    1D71C; 03B1; Additional folding
+
    1D71D; 03B2; Additional folding
+
    1D71E; 03B3; Additional folding
+
    1D71F; 03B4; Additional folding
+
    1D720; 03B5; Additional folding
+
    1D721; 03B6; Additional folding
+
    1D722; 03B7; Additional folding
+
    1D723; 03B8; Additional folding
+
    1D724; 03B9; Additional folding
+
    1D725; 03BA; Additional folding
+
    1D726; 03BB; Additional folding
+
    1D727; 03BC; Additional folding
+
    1D728; 03BD; Additional folding
+
    1D729; 03BE; Additional folding
+
    1D72A; 03BF; Additional folding
+
    1D72B; 03C0; Additional folding
+
    1D72C; 03C1; Additional folding
+
    1D72D; 03B8; Additional folding
+
    1D72E; 03C3; Additional folding
+
    1D72F; 03C4; Additional folding
+
    1D730; 03C5; Additional folding
+
    1D731; 03C6; Additional folding
+
    1D732; 03C7; Additional folding
+
    1D733; 03C8; Additional folding
+
    1D734; 03C9; Additional folding
+
    1D747; 03C3; Additional folding
+
    1D756; 03B1; Additional folding
+
    1D757; 03B2; Additional folding
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 59]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1D758; 03B3; Additional folding
+
    1D759; 03B4; Additional folding
+
    1D75A; 03B5; Additional folding
+
    1D75B; 03B6; Additional folding
+
    1D75C; 03B7; Additional folding
+
    1D75D; 03B8; Additional folding
+
    1D75E; 03B9; Additional folding
+
    1D75F; 03BA; Additional folding
+
    1D760; 03BB; Additional folding
+
    1D761; 03BC; Additional folding
+
    1D762; 03BD; Additional folding
+
    1D763; 03BE; Additional folding
+
    1D764; 03BF; Additional folding
+
    1D765; 03C0; Additional folding
+
    1D766; 03C1; Additional folding
+
    1D767; 03B8; Additional folding
+
    1D768; 03C3; Additional folding
+
    1D769; 03C4; Additional folding
+
    1D76A; 03C5; Additional folding
+
    1D76B; 03C6; Additional folding
+
    1D76C; 03C7; Additional folding
+
    1D76D; 03C8; Additional folding
+
    1D76E; 03C9; Additional folding
+
    1D781; 03C3; Additional folding
+
    1D790; 03B1; Additional folding
+
    1D791; 03B2; Additional folding
+
    1D792; 03B3; Additional folding
+
    1D793; 03B4; Additional folding
+
    1D794; 03B5; Additional folding
+
    1D795; 03B6; Additional folding
+
    1D796; 03B7; Additional folding
+
    1D797; 03B8; Additional folding
+
    1D798; 03B9; Additional folding
+
    1D799; 03BA; Additional folding
+
    1D79A; 03BB; Additional folding
+
    1D79B; 03BC; Additional folding
+
    1D79C; 03BD; Additional folding
+
    1D79D; 03BE; Additional folding
+
    1D79E; 03BF; Additional folding
+
    1D79F; 03C0; Additional folding
+
    1D7A0; 03C1; Additional folding
+
    1D7A1; 03B8; Additional folding
+
    1D7A2; 03C3; Additional folding
+
    1D7A3; 03C4; Additional folding
+
    1D7A4; 03C5; Additional folding
+
    1D7A5; 03C6; Additional folding
+
    1D7A6; 03C7; Additional folding
+
    1D7A7; 03C8; Additional folding
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 60]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1D7A8; 03C9; Additional folding
+
    1D7BB; 03C3; Additional folding
-   ----- End Table B.2 -----
 
-B.3 Mapping for case-folding used with no normalization
+   ----- End Table B.2 -----
 
    ----- Start Table B.3 -----
+
    0041; 0061; Case map
+
    0042; 0062; Case map
+
    0043; 0063; Case map
+
    0044; 0064; Case map
+
    0045; 0065; Case map
+
    0046; 0066; Case map
+
    0047; 0067; Case map
+
    0048; 0068; Case map
+
    0049; 0069; Case map
+
    004A; 006A; Case map
+
    004B; 006B; Case map
+
    004C; 006C; Case map
+
    004D; 006D; Case map
+
    004E; 006E; Case map
+
    004F; 006F; Case map
+
    0050; 0070; Case map
+
    0051; 0071; Case map
+
    0052; 0072; Case map
+
    0053; 0073; Case map
+
    0054; 0074; Case map
+
    0055; 0075; Case map
+
    0056; 0076; Case map
+
    0057; 0077; Case map
+
    0058; 0078; Case map
+
    0059; 0079; Case map
+
    005A; 007A; Case map
+
    00B5; 03BC; Case map
+
    00C0; 00E0; Case map
+
    00C1; 00E1; Case map
+
    00C2; 00E2; Case map
+
    00C3; 00E3; Case map
+
    00C4; 00E4; Case map
+
    00C5; 00E5; Case map
+
    00C6; 00E6; Case map
+
    00C7; 00E7; Case map
+
    00C8; 00E8; Case map
+
    00C9; 00E9; Case map
+
    00CA; 00EA; Case map
+
    00CB; 00EB; Case map
+
    00CC; 00EC; Case map
+
    00CD; 00ED; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 61]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    00CE; 00EE; Case map
+
    00CF; 00EF; Case map
+
    00D0; 00F0; Case map
+
    00D1; 00F1; Case map
+
    00D2; 00F2; Case map
+
    00D3; 00F3; Case map
+
    00D4; 00F4; Case map
+
    00D5; 00F5; Case map
+
    00D6; 00F6; Case map
+
    00D8; 00F8; Case map
+
    00D9; 00F9; Case map
+
    00DA; 00FA; Case map
+
    00DB; 00FB; Case map
+
    00DC; 00FC; Case map
+
    00DD; 00FD; Case map
+
    00DE; 00FE; Case map
+
    00DF; 0073 0073; Case map
+
    0100; 0101; Case map
+
    0102; 0103; Case map
+
    0104; 0105; Case map
+
    0106; 0107; Case map
+
    0108; 0109; Case map
+
    010A; 010B; Case map
+
    010C; 010D; Case map
+
    010E; 010F; Case map
+
    0110; 0111; Case map
+
    0112; 0113; Case map
+
    0114; 0115; Case map
+
    0116; 0117; Case map
+
    0118; 0119; Case map
+
    011A; 011B; Case map
+
    011C; 011D; Case map
+
    011E; 011F; Case map
+
    0120; 0121; Case map
+
    0122; 0123; Case map
+
    0124; 0125; Case map
+
    0126; 0127; Case map
+
    0128; 0129; Case map
+
    012A; 012B; Case map
+
    012C; 012D; Case map
+
    012E; 012F; Case map
+
    0130; 0069 0307; Case map
+
    0132; 0133; Case map
+
    0134; 0135; Case map
+
    0136; 0137; Case map
+
    0139; 013A; Case map
+
    013B; 013C; Case map
+
    013D; 013E; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 62]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    013F; 0140; Case map
+
    0141; 0142; Case map
+
    0143; 0144; Case map
+
    0145; 0146; Case map
+
    0147; 0148; Case map
+
    0149; 02BC 006E; Case map
+
    014A; 014B; Case map
+
    014C; 014D; Case map
+
    014E; 014F; Case map
+
    0150; 0151; Case map
+
    0152; 0153; Case map
+
    0154; 0155; Case map
+
    0156; 0157; Case map
+
    0158; 0159; Case map
+
    015A; 015B; Case map
+
    015C; 015D; Case map
+
    015E; 015F; Case map
+
    0160; 0161; Case map
+
    0162; 0163; Case map
+
    0164; 0165; Case map
+
    0166; 0167; Case map
+
    0168; 0169; Case map
+
    016A; 016B; Case map
+
    016C; 016D; Case map
+
    016E; 016F; Case map
+
    0170; 0171; Case map
+
    0172; 0173; Case map
+
    0174; 0175; Case map
+
    0176; 0177; Case map
+
    0178; 00FF; Case map
+
    0179; 017A; Case map
+
    017B; 017C; Case map
+
    017D; 017E; Case map
+
    017F; 0073; Case map
+
    0181; 0253; Case map
+
    0182; 0183; Case map
+
    0184; 0185; Case map
+
    0186; 0254; Case map
+
    0187; 0188; Case map
+
    0189; 0256; Case map
+
    018A; 0257; Case map
+
    018B; 018C; Case map
+
    018E; 01DD; Case map
+
    018F; 0259; Case map
+
    0190; 025B; Case map
+
    0191; 0192; Case map
+
    0193; 0260; Case map
+
    0194; 0263; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 63]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    0196; 0269; Case map
+
    0197; 0268; Case map
+
    0198; 0199; Case map
+
    019C; 026F; Case map
+
    019D; 0272; Case map
+
    019F; 0275; Case map
+
    01A0; 01A1; Case map
+
    01A2; 01A3; Case map
+
    01A4; 01A5; Case map
+
    01A6; 0280; Case map
+
    01A7; 01A8; Case map
+
    01A9; 0283; Case map
+
    01AC; 01AD; Case map
+
    01AE; 0288; Case map
+
    01AF; 01B0; Case map
+
    01B1; 028A; Case map
+
    01B2; 028B; Case map
+
    01B3; 01B4; Case map
+
    01B5; 01B6; Case map
+
    01B7; 0292; Case map
+
    01B8; 01B9; Case map
+
    01BC; 01BD; Case map
+
    01C4; 01C6; Case map
+
    01C5; 01C6; Case map
+
    01C7; 01C9; Case map
+
    01C8; 01C9; Case map
+
    01CA; 01CC; Case map
+
    01CB; 01CC; Case map
+
    01CD; 01CE; Case map
+
    01CF; 01D0; Case map
+
    01D1; 01D2; Case map
+
    01D3; 01D4; Case map
+
    01D5; 01D6; Case map
+
    01D7; 01D8; Case map
+
    01D9; 01DA; Case map
+
    01DB; 01DC; Case map
+
    01DE; 01DF; Case map
+
    01E0; 01E1; Case map
+
    01E2; 01E3; Case map
+
    01E4; 01E5; Case map
+
    01E6; 01E7; Case map
+
    01E8; 01E9; Case map
+
    01EA; 01EB; Case map
+
    01EC; 01ED; Case map
+
    01EE; 01EF; Case map
+
    01F0; 006A 030C; Case map
+
    01F1; 01F3; Case map
+
    01F2; 01F3; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 64]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    01F4; 01F5; Case map
+
    01F6; 0195; Case map
+
    01F7; 01BF; Case map
+
    01F8; 01F9; Case map
+
    01FA; 01FB; Case map
+
    01FC; 01FD; Case map
+
    01FE; 01FF; Case map
+
    0200; 0201; Case map
+
    0202; 0203; Case map
+
    0204; 0205; Case map
+
    0206; 0207; Case map
+
    0208; 0209; Case map
+
    020A; 020B; Case map
+
    020C; 020D; Case map
+
    020E; 020F; Case map
+
    0210; 0211; Case map
+
    0212; 0213; Case map
+
    0214; 0215; Case map
+
    0216; 0217; Case map
+
    0218; 0219; Case map
+
    021A; 021B; Case map
+
    021C; 021D; Case map
+
    021E; 021F; Case map
+
    0220; 019E; Case map
+
    0222; 0223; Case map
+
    0224; 0225; Case map
+
    0226; 0227; Case map
+
    0228; 0229; Case map
+
    022A; 022B; Case map
+
    022C; 022D; Case map
+
    022E; 022F; Case map
+
    0230; 0231; Case map
+
    0232; 0233; Case map
+
    0345; 03B9; Case map
+
    0386; 03AC; Case map
+
    0388; 03AD; Case map
+
    0389; 03AE; Case map
+
    038A; 03AF; Case map
+
    038C; 03CC; Case map
+
    038E; 03CD; Case map
+
    038F; 03CE; Case map
+
    0390; 03B9 0308 0301; Case map
+
    0391; 03B1; Case map
+
    0392; 03B2; Case map
+
    0393; 03B3; Case map
+
    0394; 03B4; Case map
+
    0395; 03B5; Case map
+
    0396; 03B6; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 65]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    0397; 03B7; Case map
+
    0398; 03B8; Case map
+
    0399; 03B9; Case map
+
    039A; 03BA; Case map
+
    039B; 03BB; Case map
+
    039C; 03BC; Case map
+
    039D; 03BD; Case map
+
    039E; 03BE; Case map
+
    039F; 03BF; Case map
+
    03A0; 03C0; Case map
+
    03A1; 03C1; Case map
+
    03A3; 03C3; Case map
+
    03A4; 03C4; Case map
+
    03A5; 03C5; Case map
+
    03A6; 03C6; Case map
+
    03A7; 03C7; Case map
+
    03A8; 03C8; Case map
+
    03A9; 03C9; Case map
+
    03AA; 03CA; Case map
+
    03AB; 03CB; Case map
+
    03B0; 03C5 0308 0301; Case map
+
    03C2; 03C3; Case map
+
    03D0; 03B2; Case map
+
    03D1; 03B8; Case map
+
    03D5; 03C6; Case map
+
    03D6; 03C0; Case map
+
    03D8; 03D9; Case map
+
    03DA; 03DB; Case map
+
    03DC; 03DD; Case map
+
    03DE; 03DF; Case map
+
    03E0; 03E1; Case map
+
    03E2; 03E3; Case map
+
    03E4; 03E5; Case map
+
    03E6; 03E7; Case map
+
    03E8; 03E9; Case map
+
    03EA; 03EB; Case map
+
    03EC; 03ED; Case map
+
    03EE; 03EF; Case map
+
    03F0; 03BA; Case map
+
    03F1; 03C1; Case map
+
    03F2; 03C3; Case map
+
    03F4; 03B8; Case map
+
    03F5; 03B5; Case map
+
    0400; 0450; Case map
+
    0401; 0451; Case map
+
    0402; 0452; Case map
+
    0403; 0453; Case map
+
    0404; 0454; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 66]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    0405; 0455; Case map
+
    0406; 0456; Case map
+
    0407; 0457; Case map
+
    0408; 0458; Case map
+
    0409; 0459; Case map
+
    040A; 045A; Case map
+
    040B; 045B; Case map
+
    040C; 045C; Case map
+
    040D; 045D; Case map
+
    040E; 045E; Case map
+
    040F; 045F; Case map
+
    0410; 0430; Case map
+
    0411; 0431; Case map
+
    0412; 0432; Case map
+
    0413; 0433; Case map
+
    0414; 0434; Case map
+
    0415; 0435; Case map
+
    0416; 0436; Case map
+
    0417; 0437; Case map
+
    0418; 0438; Case map
+
    0419; 0439; Case map
+
    041A; 043A; Case map
+
    041B; 043B; Case map
+
    041C; 043C; Case map
+
    041D; 043D; Case map
+
    041E; 043E; Case map
+
    041F; 043F; Case map
+
    0420; 0440; Case map
+
    0421; 0441; Case map
+
    0422; 0442; Case map
+
    0423; 0443; Case map
+
    0424; 0444; Case map
+
    0425; 0445; Case map
+
    0426; 0446; Case map
+
    0427; 0447; Case map
+
    0428; 0448; Case map
+
    0429; 0449; Case map
+
    042A; 044A; Case map
+
    042B; 044B; Case map
+
    042C; 044C; Case map
+
    042D; 044D; Case map
+
    042E; 044E; Case map
+
    042F; 044F; Case map
+
    0460; 0461; Case map
+
    0462; 0463; Case map
+
    0464; 0465; Case map
+
    0466; 0467; Case map
+
    0468; 0469; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 67]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    046A; 046B; Case map
+
    046C; 046D; Case map
+
    046E; 046F; Case map
+
    0470; 0471; Case map
+
    0472; 0473; Case map
+
    0474; 0475; Case map
+
    0476; 0477; Case map
+
    0478; 0479; Case map
+
    047A; 047B; Case map
+
    047C; 047D; Case map
+
    047E; 047F; Case map
+
    0480; 0481; Case map
+
    048A; 048B; Case map
+
    048C; 048D; Case map
+
    048E; 048F; Case map
+
    0490; 0491; Case map
+
    0492; 0493; Case map
+
    0494; 0495; Case map
+
    0496; 0497; Case map
+
    0498; 0499; Case map
+
    049A; 049B; Case map
+
    049C; 049D; Case map
+
    049E; 049F; Case map
+
    04A0; 04A1; Case map
+
    04A2; 04A3; Case map
+
    04A4; 04A5; Case map
+
    04A6; 04A7; Case map
+
    04A8; 04A9; Case map
+
    04AA; 04AB; Case map
+
    04AC; 04AD; Case map
+
    04AE; 04AF; Case map
+
    04B0; 04B1; Case map
+
    04B2; 04B3; Case map
+
    04B4; 04B5; Case map
+
    04B6; 04B7; Case map
+
    04B8; 04B9; Case map
+
    04BA; 04BB; Case map
+
    04BC; 04BD; Case map
+
    04BE; 04BF; Case map
+
    04C1; 04C2; Case map
+
    04C3; 04C4; Case map
+
    04C5; 04C6; Case map
+
    04C7; 04C8; Case map
+
    04C9; 04CA; Case map
+
    04CB; 04CC; Case map
+
    04CD; 04CE; Case map
+
    04D0; 04D1; Case map
+
    04D2; 04D3; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 68]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    04D4; 04D5; Case map
+
    04D6; 04D7; Case map
+
    04D8; 04D9; Case map
+
    04DA; 04DB; Case map
+
    04DC; 04DD; Case map
+
    04DE; 04DF; Case map
+
    04E0; 04E1; Case map
+
    04E2; 04E3; Case map
+
    04E4; 04E5; Case map
+
    04E6; 04E7; Case map
+
    04E8; 04E9; Case map
+
    04EA; 04EB; Case map
+
    04EC; 04ED; Case map
+
    04EE; 04EF; Case map
+
    04F0; 04F1; Case map
+
    04F2; 04F3; Case map
+
    04F4; 04F5; Case map
+
    04F8; 04F9; Case map
+
    0500; 0501; Case map
+
    0502; 0503; Case map
+
    0504; 0505; Case map
+
    0506; 0507; Case map
+
    0508; 0509; Case map
+
    050A; 050B; Case map
+
    050C; 050D; Case map
+
    050E; 050F; Case map
+
    0531; 0561; Case map
+
    0532; 0562; Case map
+
    0533; 0563; Case map
+
    0534; 0564; Case map
+
    0535; 0565; Case map
+
    0536; 0566; Case map
+
    0537; 0567; Case map
+
    0538; 0568; Case map
+
    0539; 0569; Case map
+
    053A; 056A; Case map
+
    053B; 056B; Case map
+
    053C; 056C; Case map
+
    053D; 056D; Case map
+
    053E; 056E; Case map
+
    053F; 056F; Case map
+
    0540; 0570; Case map
+
    0541; 0571; Case map
+
    0542; 0572; Case map
+
    0543; 0573; Case map
+
    0544; 0574; Case map
+
    0545; 0575; Case map
+
    0546; 0576; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 69]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    0547; 0577; Case map
+
    0548; 0578; Case map
+
    0549; 0579; Case map
+
    054A; 057A; Case map
+
    054B; 057B; Case map
+
    054C; 057C; Case map
+
    054D; 057D; Case map
+
    054E; 057E; Case map
+
    054F; 057F; Case map
+
    0550; 0580; Case map
+
    0551; 0581; Case map
+
    0552; 0582; Case map
+
    0553; 0583; Case map
+
    0554; 0584; Case map
+
    0555; 0585; Case map
+
    0556; 0586; Case map
+
    0587; 0565 0582; Case map
+
    1E00; 1E01; Case map
+
    1E02; 1E03; Case map
+
    1E04; 1E05; Case map
+
    1E06; 1E07; Case map
+
    1E08; 1E09; Case map
+
    1E0A; 1E0B; Case map
+
    1E0C; 1E0D; Case map
+
    1E0E; 1E0F; Case map
+
    1E10; 1E11; Case map
+
    1E12; 1E13; Case map
+
    1E14; 1E15; Case map
+
    1E16; 1E17; Case map
+
    1E18; 1E19; Case map
+
    1E1A; 1E1B; Case map
+
    1E1C; 1E1D; Case map
+
    1E1E; 1E1F; Case map
+
    1E20; 1E21; Case map
+
    1E22; 1E23; Case map
+
    1E24; 1E25; Case map
+
    1E26; 1E27; Case map
+
    1E28; 1E29; Case map
+
    1E2A; 1E2B; Case map
+
    1E2C; 1E2D; Case map
+
    1E2E; 1E2F; Case map
+
    1E30; 1E31; Case map
+
    1E32; 1E33; Case map
+
    1E34; 1E35; Case map
+
    1E36; 1E37; Case map
+
    1E38; 1E39; Case map
+
    1E3A; 1E3B; Case map
+
    1E3C; 1E3D; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 70]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1E3E; 1E3F; Case map
+
    1E40; 1E41; Case map
+
    1E42; 1E43; Case map
+
    1E44; 1E45; Case map
+
    1E46; 1E47; Case map
+
    1E48; 1E49; Case map
+
    1E4A; 1E4B; Case map
+
    1E4C; 1E4D; Case map
+
    1E4E; 1E4F; Case map
+
    1E50; 1E51; Case map
+
    1E52; 1E53; Case map
+
    1E54; 1E55; Case map
+
    1E56; 1E57; Case map
+
    1E58; 1E59; Case map
+
    1E5A; 1E5B; Case map
+
    1E5C; 1E5D; Case map
+
    1E5E; 1E5F; Case map
+
    1E60; 1E61; Case map
+
    1E62; 1E63; Case map
+
    1E64; 1E65; Case map
+
    1E66; 1E67; Case map
+
    1E68; 1E69; Case map
+
    1E6A; 1E6B; Case map
+
    1E6C; 1E6D; Case map
+
    1E6E; 1E6F; Case map
+
    1E70; 1E71; Case map
+
    1E72; 1E73; Case map
+
    1E74; 1E75; Case map
+
    1E76; 1E77; Case map
+
    1E78; 1E79; Case map
+
    1E7A; 1E7B; Case map
+
    1E7C; 1E7D; Case map
+
    1E7E; 1E7F; Case map
+
    1E80; 1E81; Case map
+
    1E82; 1E83; Case map
+
    1E84; 1E85; Case map
+
    1E86; 1E87; Case map
+
    1E88; 1E89; Case map
+
    1E8A; 1E8B; Case map
+
    1E8C; 1E8D; Case map
+
    1E8E; 1E8F; Case map
+
    1E90; 1E91; Case map
+
    1E92; 1E93; Case map
+
    1E94; 1E95; Case map
+
    1E96; 0068 0331; Case map
+
    1E97; 0074 0308; Case map
+
    1E98; 0077 030A; Case map
+
    1E99; 0079 030A; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 71]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1E9A; 0061 02BE; Case map
+
    1E9B; 1E61; Case map
+
    1EA0; 1EA1; Case map
+
    1EA2; 1EA3; Case map
+
    1EA4; 1EA5; Case map
+
    1EA6; 1EA7; Case map
+
    1EA8; 1EA9; Case map
+
    1EAA; 1EAB; Case map
+
    1EAC; 1EAD; Case map
+
    1EAE; 1EAF; Case map
+
    1EB0; 1EB1; Case map
+
    1EB2; 1EB3; Case map
+
    1EB4; 1EB5; Case map
+
    1EB6; 1EB7; Case map
+
    1EB8; 1EB9; Case map
+
    1EBA; 1EBB; Case map
+
    1EBC; 1EBD; Case map
+
    1EBE; 1EBF; Case map
+
    1EC0; 1EC1; Case map
+
    1EC2; 1EC3; Case map
+
    1EC4; 1EC5; Case map
+
    1EC6; 1EC7; Case map
+
    1EC8; 1EC9; Case map
+
    1ECA; 1ECB; Case map
+
    1ECC; 1ECD; Case map
+
    1ECE; 1ECF; Case map
+
    1ED0; 1ED1; Case map
+
    1ED2; 1ED3; Case map
+
    1ED4; 1ED5; Case map
+
    1ED6; 1ED7; Case map
+
    1ED8; 1ED9; Case map
+
    1EDA; 1EDB; Case map
+
    1EDC; 1EDD; Case map
+
    1EDE; 1EDF; Case map
+
    1EE0; 1EE1; Case map
+
    1EE2; 1EE3; Case map
+
    1EE4; 1EE5; Case map
+
    1EE6; 1EE7; Case map
+
    1EE8; 1EE9; Case map
+
    1EEA; 1EEB; Case map
+
    1EEC; 1EED; Case map
+
    1EEE; 1EEF; Case map
+
    1EF0; 1EF1; Case map
+
    1EF2; 1EF3; Case map
+
    1EF4; 1EF5; Case map
+
    1EF6; 1EF7; Case map
+
    1EF8; 1EF9; Case map
+
    1F08; 1F00; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 72]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1F09; 1F01; Case map
+
    1F0A; 1F02; Case map
+
    1F0B; 1F03; Case map
+
    1F0C; 1F04; Case map
+
    1F0D; 1F05; Case map
+
    1F0E; 1F06; Case map
+
    1F0F; 1F07; Case map
+
    1F18; 1F10; Case map
+
    1F19; 1F11; Case map
+
    1F1A; 1F12; Case map
+
    1F1B; 1F13; Case map
+
    1F1C; 1F14; Case map
+
    1F1D; 1F15; Case map
+
    1F28; 1F20; Case map
+
    1F29; 1F21; Case map
+
    1F2A; 1F22; Case map
+
    1F2B; 1F23; Case map
+
    1F2C; 1F24; Case map
+
    1F2D; 1F25; Case map
+
    1F2E; 1F26; Case map
+
    1F2F; 1F27; Case map
+
    1F38; 1F30; Case map
+
    1F39; 1F31; Case map
+
    1F3A; 1F32; Case map
+
    1F3B; 1F33; Case map
+
    1F3C; 1F34; Case map
+
    1F3D; 1F35; Case map
+
    1F3E; 1F36; Case map
+
    1F3F; 1F37; Case map
+
    1F48; 1F40; Case map
+
    1F49; 1F41; Case map
+
    1F4A; 1F42; Case map
+
    1F4B; 1F43; Case map
+
    1F4C; 1F44; Case map
+
    1F4D; 1F45; Case map
+
    1F50; 03C5 0313; Case map
+
    1F52; 03C5 0313 0300; Case map
+
    1F54; 03C5 0313 0301; Case map
+
    1F56; 03C5 0313 0342; Case map
+
    1F59; 1F51; Case map
+
    1F5B; 1F53; Case map
+
    1F5D; 1F55; Case map
+
    1F5F; 1F57; Case map
+
    1F68; 1F60; Case map
+
    1F69; 1F61; Case map
+
    1F6A; 1F62; Case map
+
    1F6B; 1F63; Case map
+
    1F6C; 1F64; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 73]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1F6D; 1F65; Case map
+
    1F6E; 1F66; Case map
+
    1F6F; 1F67; Case map
+
    1F80; 1F00 03B9; Case map
+
    1F81; 1F01 03B9; Case map
+
    1F82; 1F02 03B9; Case map
+
    1F83; 1F03 03B9; Case map
+
    1F84; 1F04 03B9; Case map
+
    1F85; 1F05 03B9; Case map
+
    1F86; 1F06 03B9; Case map
+
    1F87; 1F07 03B9; Case map
+
    1F88; 1F00 03B9; Case map
+
    1F89; 1F01 03B9; Case map
+
    1F8A; 1F02 03B9; Case map
+
    1F8B; 1F03 03B9; Case map
+
    1F8C; 1F04 03B9; Case map
+
    1F8D; 1F05 03B9; Case map
+
    1F8E; 1F06 03B9; Case map
+
    1F8F; 1F07 03B9; Case map
+
    1F90; 1F20 03B9; Case map
+
    1F91; 1F21 03B9; Case map
+
    1F92; 1F22 03B9; Case map
+
    1F93; 1F23 03B9; Case map
+
    1F94; 1F24 03B9; Case map
+
    1F95; 1F25 03B9; Case map
+
    1F96; 1F26 03B9; Case map
+
    1F97; 1F27 03B9; Case map
+
    1F98; 1F20 03B9; Case map
+
    1F99; 1F21 03B9; Case map
+
    1F9A; 1F22 03B9; Case map
+
    1F9B; 1F23 03B9; Case map
+
    1F9C; 1F24 03B9; Case map
+
    1F9D; 1F25 03B9; Case map
+
    1F9E; 1F26 03B9; Case map
+
    1F9F; 1F27 03B9; Case map
+
    1FA0; 1F60 03B9; Case map
+
    1FA1; 1F61 03B9; Case map
+
    1FA2; 1F62 03B9; Case map
+
    1FA3; 1F63 03B9; Case map
+
    1FA4; 1F64 03B9; Case map
+
    1FA5; 1F65 03B9; Case map
+
    1FA6; 1F66 03B9; Case map
+
    1FA7; 1F67 03B9; Case map
+
    1FA8; 1F60 03B9; Case map
+
    1FA9; 1F61 03B9; Case map
+
    1FAA; 1F62 03B9; Case map
+
    1FAB; 1F63 03B9; Case map
+
    1FAC; 1F64 03B9; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 74]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1FAD; 1F65 03B9; Case map
+
    1FAE; 1F66 03B9; Case map
+
    1FAF; 1F67 03B9; Case map
+
    1FB2; 1F70 03B9; Case map
+
    1FB3; 03B1 03B9; Case map
+
    1FB4; 03AC 03B9; Case map
+
    1FB6; 03B1 0342; Case map
+
    1FB7; 03B1 0342 03B9; Case map
+
    1FB8; 1FB0; Case map
+
    1FB9; 1FB1; Case map
+
    1FBA; 1F70; Case map
+
    1FBB; 1F71; Case map
+
    1FBC; 03B1 03B9; Case map
+
    1FBE; 03B9; Case map
+
    1FC2; 1F74 03B9; Case map
+
    1FC3; 03B7 03B9; Case map
+
    1FC4; 03AE 03B9; Case map
+
    1FC6; 03B7 0342; Case map
+
    1FC7; 03B7 0342 03B9; Case map
+
    1FC8; 1F72; Case map
+
    1FC9; 1F73; Case map
+
    1FCA; 1F74; Case map
+
    1FCB; 1F75; Case map
+
    1FCC; 03B7 03B9; Case map
+
    1FD2; 03B9 0308 0300; Case map
+
    1FD3; 03B9 0308 0301; Case map
+
    1FD6; 03B9 0342; Case map
+
    1FD7; 03B9 0308 0342; Case map
+
    1FD8; 1FD0; Case map
+
    1FD9; 1FD1; Case map
+
    1FDA; 1F76; Case map
+
    1FDB; 1F77; Case map
+
    1FE2; 03C5 0308 0300; Case map
+
    1FE3; 03C5 0308 0301; Case map
+
    1FE4; 03C1 0313; Case map
+
    1FE6; 03C5 0342; Case map
+
    1FE7; 03C5 0308 0342; Case map
+
    1FE8; 1FE0; Case map
+
    1FE9; 1FE1; Case map
+
    1FEA; 1F7A; Case map
+
    1FEB; 1F7B; Case map
+
    1FEC; 1FE5; Case map
+
    1FF2; 1F7C 03B9; Case map
+
    1FF3; 03C9 03B9; Case map
+
    1FF4; 03CE 03B9; Case map
+
    1FF6; 03C9 0342; Case map
+
    1FF7; 03C9 0342 03B9; Case map
+
    1FF8; 1F78; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 75]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1FF9; 1F79; Case map
+
    1FFA; 1F7C; Case map
+
    1FFB; 1F7D; Case map
+
    1FFC; 03C9 03B9; Case map
+
    2126; 03C9; Case map
+
    212A; 006B; Case map
+
    212B; 00E5; Case map
+
    2160; 2170; Case map
+
    2161; 2171; Case map
+
    2162; 2172; Case map
+
    2163; 2173; Case map
+
    2164; 2174; Case map
+
    2165; 2175; Case map
+
    2166; 2176; Case map
+
    2167; 2177; Case map
+
    2168; 2178; Case map
+
    2169; 2179; Case map
+
    216A; 217A; Case map
+
    216B; 217B; Case map
+
    216C; 217C; Case map
+
    216D; 217D; Case map
+
    216E; 217E; Case map
+
    216F; 217F; Case map
+
    24B6; 24D0; Case map
+
    24B7; 24D1; Case map
+
    24B8; 24D2; Case map
+
    24B9; 24D3; Case map
+
    24BA; 24D4; Case map
+
    24BB; 24D5; Case map
+
    24BC; 24D6; Case map
+
    24BD; 24D7; Case map
+
    24BE; 24D8; Case map
+
    24BF; 24D9; Case map
+
    24C0; 24DA; Case map
+
    24C1; 24DB; Case map
+
    24C2; 24DC; Case map
+
    24C3; 24DD; Case map
+
    24C4; 24DE; Case map
+
    24C5; 24DF; Case map
+
    24C6; 24E0; Case map
+
    24C7; 24E1; Case map
+
    24C8; 24E2; Case map
+
    24C9; 24E3; Case map
+
    24CA; 24E4; Case map
+
    24CB; 24E5; Case map
+
    24CC; 24E6; Case map
+
    24CD; 24E7; Case map
+
    24CE; 24E8; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 76]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    24CF; 24E9; Case map
+
    FB00; 0066 0066; Case map
+
    FB01; 0066 0069; Case map
+
    FB02; 0066 006C; Case map
+
    FB03; 0066 0066 0069; Case map
+
    FB04; 0066 0066 006C; Case map
+
    FB05; 0073 0074; Case map
+
    FB06; 0073 0074; Case map
+
    FB13; 0574 0576; Case map
+
    FB14; 0574 0565; Case map
+
    FB15; 0574 056B; Case map
+
    FB16; 057E 0576; Case map
+
    FB17; 0574 056D; Case map
+
    FF21; FF41; Case map
+
    FF22; FF42; Case map
+
    FF23; FF43; Case map
+
    FF24; FF44; Case map
+
    FF25; FF45; Case map
+
    FF26; FF46; Case map
+
    FF27; FF47; Case map
+
    FF28; FF48; Case map
+
    FF29; FF49; Case map
+
    FF2A; FF4A; Case map
+
    FF2B; FF4B; Case map
+
    FF2C; FF4C; Case map
+
    FF2D; FF4D; Case map
+
    FF2E; FF4E; Case map
+
    FF2F; FF4F; Case map
+
    FF30; FF50; Case map
+
    FF31; FF51; Case map
+
    FF32; FF52; Case map
+
    FF33; FF53; Case map
+
    FF34; FF54; Case map
+
    FF35; FF55; Case map
+
    FF36; FF56; Case map
+
    FF37; FF57; Case map
+
    FF38; FF58; Case map
+
    FF39; FF59; Case map
+
    FF3A; FF5A; Case map
+
    10400; 10428; Case map
+
    10401; 10429; Case map
+
    10402; 1042A; Case map
+
    10403; 1042B; Case map
+
    10404; 1042C; Case map
+
    10405; 1042D; Case map
+
    10406; 1042E; Case map
+
    10407; 1042F; Case map
+
    10408; 10430; Case map
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 77]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    10409; 10431; Case map
+
    1040A; 10432; Case map
+
    1040B; 10433; Case map
+
    1040C; 10434; Case map
+
    1040D; 10435; Case map
+
    1040E; 10436; Case map
+
    1040F; 10437; Case map
+
    10410; 10438; Case map
+
    10411; 10439; Case map
+
    10412; 1043A; Case map
+
    10413; 1043B; Case map
+
    10414; 1043C; Case map
+
    10415; 1043D; Case map
+
    10416; 1043E; Case map
+
    10417; 1043F; Case map
+
    10418; 10440; Case map
+
    10419; 10441; Case map
+
    1041A; 10442; Case map
+
    1041B; 10443; Case map
+
    1041C; 10444; Case map
+
    1041D; 10445; Case map
+
    1041E; 10446; Case map
+
    1041F; 10447; Case map
+
    10420; 10448; Case map
+
    10421; 10449; Case map
+
    10422; 1044A; Case map
-   10423; 1044B; Case map
-   10424; 1044C; Case map
-   10425; 1044D; Case map
-   ----- End Table B.3 -----
 
-C. Prohibition tables
+   10423; 1044B; Case map
 
-   The tables in this appendix consist of lines with one prohibited code
-   point per line.  The format of the lines are the value of the code
-   point, a semicolon, and a comment which is the name of the code
-   point.
+   10424; 1044C; Case map
 
-C.1 Space characters
+   10425; 1044D; Case map
 
-C.1.1 ASCII space characters
+   ----- End Table B.3 -----
 
    ----- Start Table C.1.1 -----
-   0020; SPACE
-   ----- End Table C.1.1 -----
-
-
-
 
+   0020; SPACE
 
+   ----- End Table C.1.1 -----
 
-Hoffman & Blanchet          Standards Track                    [Page 78]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-C.1.2 Non-ASCII space characters
    ----- Start Table C.1.2 -----
+
    00A0; NO-BREAK SPACE
+
    1680; OGHAM SPACE MARK
+
    2000; EN QUAD
+
    2001; EM QUAD
+
    2002; EN SPACE
+
    2003; EM SPACE
+
    2004; THREE-PER-EM SPACE
+
    2005; FOUR-PER-EM SPACE
+
    2006; SIX-PER-EM SPACE
+
    2007; FIGURE SPACE
+
    2008; PUNCTUATION SPACE
+
    2009; THIN SPACE
+
    200A; HAIR SPACE
+
    200B; ZERO WIDTH SPACE
+
    202F; NARROW NO-BREAK SPACE
+
    205F; MEDIUM MATHEMATICAL SPACE
-   3000; IDEOGRAPHIC SPACE
-   ----- End Table C.1.2 -----
 
-C.2 Control characters
+   3000; IDEOGRAPHIC SPACE
 
-C.2.1 ASCII control characters
+   ----- End Table C.1.2 -----
 
    ----- Start Table C.2.1 -----
+
    0000-001F; [CONTROL CHARACTERS]
+
    007F; DELETE
-   ----- End Table C.2.1 -----
 
-C.2.2 Non-ASCII control characters
+   ----- End Table C.2.1 -----
 
    ----- Start Table C.2.2 -----
+
    0080-009F; [CONTROL CHARACTERS]
+
    06DD; ARABIC END OF AYAH
+
    070F; SYRIAC ABBREVIATION MARK
+
    180E; MONGOLIAN VOWEL SEPARATOR
+
    200C; ZERO WIDTH NON-JOINER
+
    200D; ZERO WIDTH JOINER
+
    2028; LINE SEPARATOR
+
    2029; PARAGRAPH SEPARATOR
+
    2060; WORD JOINER
+
    2061; FUNCTION APPLICATION
+
    2062; INVISIBLE TIMES
+
    2063; INVISIBLE SEPARATOR
+
    206A-206F; [CONTROL CHARACTERS]
+
    FEFF; ZERO WIDTH NO-BREAK SPACE
+
    FFF9-FFFC; [CONTROL CHARACTERS]
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 79]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1D173-1D17A; [MUSICAL CONTROL CHARACTERS]
-   ----- End Table C.2.2 -----
 
-C.3 Private use
+   ----- End Table C.2.2 -----
 
    ----- Start Table C.3 -----
+
    E000-F8FF; [PRIVATE USE, PLANE 0]
+
    F0000-FFFFD; [PRIVATE USE, PLANE 15]
+
    100000-10FFFD; [PRIVATE USE, PLANE 16]
-   ----- End Table C.3 -----
 
-C.4 Non-character code points
+   ----- End Table C.3 -----
 
    ----- Start Table C.4 -----
+
    FDD0-FDEF; [NONCHARACTER CODE POINTS]
+
    FFFE-FFFF; [NONCHARACTER CODE POINTS]
+
    1FFFE-1FFFF; [NONCHARACTER CODE POINTS]
+
    2FFFE-2FFFF; [NONCHARACTER CODE POINTS]
+
    3FFFE-3FFFF; [NONCHARACTER CODE POINTS]
+
    4FFFE-4FFFF; [NONCHARACTER CODE POINTS]
+
    5FFFE-5FFFF; [NONCHARACTER CODE POINTS]
+
    6FFFE-6FFFF; [NONCHARACTER CODE POINTS]
+
    7FFFE-7FFFF; [NONCHARACTER CODE POINTS]
+
    8FFFE-8FFFF; [NONCHARACTER CODE POINTS]
+
    9FFFE-9FFFF; [NONCHARACTER CODE POINTS]
+
    AFFFE-AFFFF; [NONCHARACTER CODE POINTS]
+
    BFFFE-BFFFF; [NONCHARACTER CODE POINTS]
+
    CFFFE-CFFFF; [NONCHARACTER CODE POINTS]
+
    DFFFE-DFFFF; [NONCHARACTER CODE POINTS]
+
    EFFFE-EFFFF; [NONCHARACTER CODE POINTS]
+
    FFFFE-FFFFF; [NONCHARACTER CODE POINTS]
+
    10FFFE-10FFFF; [NONCHARACTER CODE POINTS]
-   ----- End Table C.4 -----
 
-C.5 Surrogate codes
+   ----- End Table C.4 -----
 
    ----- Start Table C.5 -----
+
    D800-DFFF; [SURROGATE CODES]
-   ----- End Table C.5 -----
 
-C.6 Inappropriate for plain text
+   ----- End Table C.5 -----
 
    ----- Start Table C.6 -----
+
    FFF9; INTERLINEAR ANNOTATION ANCHOR
+
    FFFA; INTERLINEAR ANNOTATION SEPARATOR
+
    FFFB; INTERLINEAR ANNOTATION TERMINATOR
+
    FFFC; OBJECT REPLACEMENT CHARACTER
+
    FFFD; REPLACEMENT CHARACTER
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 80]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
 
 
-   ----- End Table C.6 -----
 
-C.7 Inappropriate for canonical representation
+
+
+   ----- End Table C.6 -----
 
    ----- Start Table C.7 -----
+
    2FF0-2FFB; [IDEOGRAPHIC DESCRIPTION CHARACTERS]
-   ----- End Table C.7 -----
 
-C.8 Change display properties or are deprecated
+   ----- End Table C.7 -----
 
    ----- Start Table C.8 -----
+
    0340; COMBINING GRAVE TONE MARK
+
    0341; COMBINING ACUTE TONE MARK
+
    200E; LEFT-TO-RIGHT MARK
+
    200F; RIGHT-TO-LEFT MARK
+
    202A; LEFT-TO-RIGHT EMBEDDING
+
    202B; RIGHT-TO-LEFT EMBEDDING
+
    202C; POP DIRECTIONAL FORMATTING
+
    202D; LEFT-TO-RIGHT OVERRIDE
+
    202E; RIGHT-TO-LEFT OVERRIDE
+
    206A; INHIBIT SYMMETRIC SWAPPING
+
    206B; ACTIVATE SYMMETRIC SWAPPING
+
    206C; INHIBIT ARABIC FORM SHAPING
+
    206D; ACTIVATE ARABIC FORM SHAPING
+
    206E; NATIONAL DIGIT SHAPES
+
    206F; NOMINAL DIGIT SHAPES
-   ----- End Table C.8 -----
 
-C.9 Tagging characters
+   ----- End Table C.8 -----
 
    ----- Start Table C.9 -----
+
    E0001; LANGUAGE TAG
-   E0020-E007F; [TAGGING CHARACTERS]
-   ----- End Table C.9 -----
 
-D. Bidirectional tables
+   E0020-E007F; [TAGGING CHARACTERS]
 
-D.1 Characters with bidirectional property "R" or "AL"
+   ----- End Table C.9 -----
 
    ----- Start Table D.1 -----
+
    05BE
+
    05C0
+
    05C3
+
    05D0-05EA
+
    05F0-05F4
+
    061B
+
    061F
+
    0621-063A
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 81]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    0640-064A
+
    066D-066F
+
    0671-06D5
+
    06DD
+
    06E5-06E6
+
    06FA-06FE
+
    0700-070D
+
    0710
+
    0712-072C
+
    0780-07A5
+
    07B1
+
    200F
+
    FB1D
+
    FB1F-FB28
+
    FB2A-FB36
+
    FB38-FB3C
+
    FB3E
+
    FB40-FB41
+
    FB43-FB44
+
    FB46-FBB1
+
    FBD3-FD3D
+
    FD50-FD8F
+
    FD92-FDC7
+
    FDF0-FDFC
+
    FE70-FE74
+
    FE76-FEFC
-   ----- End Table D.1 -----
 
-D.2 Characters with bidirectional property "L"
+   ----- End Table D.1 -----
 
    ----- Start Table D.2 -----
+
    0041-005A
+
    0061-007A
+
    00AA
+
    00B5
+
    00BA
+
    00C0-00D6
+
    00D8-00F6
+
    00F8-0220
+
    0222-0233
+
    0250-02AD
+
    02B0-02B8
+
    02BB-02C1
+
    02D0-02D1
+
    02E0-02E4
+
    02EE
+
    037A
+
    0386
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 82]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    0388-038A
+
    038C
+
    038E-03A1
+
    03A3-03CE
+
    03D0-03F5
+
    0400-0482
+
    048A-04CE
+
    04D0-04F5
+
    04F8-04F9
+
    0500-050F
+
    0531-0556
+
    0559-055F
+
    0561-0587
+
    0589
+
    0903
+
    0905-0939
+
    093D-0940
+
    0949-094C
+
    0950
+
    0958-0961
+
    0964-0970
+
    0982-0983
+
    0985-098C
+
    098F-0990
+
    0993-09A8
+
    09AA-09B0
+
    09B2
+
    09B6-09B9
+
    09BE-09C0
+
    09C7-09C8
+
    09CB-09CC
+
    09D7
+
    09DC-09DD
+
    09DF-09E1
+
    09E6-09F1
+
    09F4-09FA
+
    0A05-0A0A
+
    0A0F-0A10
+
    0A13-0A28
+
    0A2A-0A30
+
    0A32-0A33
+
    0A35-0A36
+
    0A38-0A39
+
    0A3E-0A40
+
    0A59-0A5C
+
    0A5E
+
    0A66-0A6F
+
    0A72-0A74
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 83]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    0A83
+
    0A85-0A8B
+
    0A8D
+
    0A8F-0A91
+
    0A93-0AA8
+
    0AAA-0AB0
+
    0AB2-0AB3
+
    0AB5-0AB9
+
    0ABD-0AC0
+
    0AC9
+
    0ACB-0ACC
+
    0AD0
+
    0AE0
+
    0AE6-0AEF
+
    0B02-0B03
+
    0B05-0B0C
+
    0B0F-0B10
+
    0B13-0B28
+
    0B2A-0B30
+
    0B32-0B33
+
    0B36-0B39
+
    0B3D-0B3E
+
    0B40
+
    0B47-0B48
+
    0B4B-0B4C
+
    0B57
+
    0B5C-0B5D
+
    0B5F-0B61
+
    0B66-0B70
+
    0B83
+
    0B85-0B8A
+
    0B8E-0B90
+
    0B92-0B95
+
    0B99-0B9A
+
    0B9C
+
    0B9E-0B9F
+
    0BA3-0BA4
+
    0BA8-0BAA
+
    0BAE-0BB5
+
    0BB7-0BB9
+
    0BBE-0BBF
+
    0BC1-0BC2
+
    0BC6-0BC8
+
    0BCA-0BCC
+
    0BD7
+
    0BE7-0BF2
+
    0C01-0C03
+
    0C05-0C0C
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 84]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    0C0E-0C10
+
    0C12-0C28
+
    0C2A-0C33
+
    0C35-0C39
+
    0C41-0C44
+
    0C60-0C61
+
    0C66-0C6F
+
    0C82-0C83
+
    0C85-0C8C
+
    0C8E-0C90
+
    0C92-0CA8
+
    0CAA-0CB3
+
    0CB5-0CB9
+
    0CBE
+
    0CC0-0CC4
+
    0CC7-0CC8
+
    0CCA-0CCB
+
    0CD5-0CD6
+
    0CDE
+
    0CE0-0CE1
+
    0CE6-0CEF
+
    0D02-0D03
+
    0D05-0D0C
+
    0D0E-0D10
+
    0D12-0D28
+
    0D2A-0D39
+
    0D3E-0D40
+
    0D46-0D48
+
    0D4A-0D4C
+
    0D57
+
    0D60-0D61
+
    0D66-0D6F
+
    0D82-0D83
+
    0D85-0D96
+
    0D9A-0DB1
+
    0DB3-0DBB
+
    0DBD
+
    0DC0-0DC6
+
    0DCF-0DD1
+
    0DD8-0DDF
+
    0DF2-0DF4
+
    0E01-0E30
+
    0E32-0E33
+
    0E40-0E46
+
    0E4F-0E5B
+
    0E81-0E82
+
    0E84
+
    0E87-0E88
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 85]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    0E8A
+
    0E8D
+
    0E94-0E97
+
    0E99-0E9F
+
    0EA1-0EA3
+
    0EA5
+
    0EA7
+
    0EAA-0EAB
+
    0EAD-0EB0
+
    0EB2-0EB3
+
    0EBD
+
    0EC0-0EC4
+
    0EC6
+
    0ED0-0ED9
+
    0EDC-0EDD
+
    0F00-0F17
+
    0F1A-0F34
+
    0F36
+
    0F38
+
    0F3E-0F47
+
    0F49-0F6A
+
    0F7F
+
    0F85
+
    0F88-0F8B
+
    0FBE-0FC5
+
    0FC7-0FCC
+
    0FCF
+
    1000-1021
+
    1023-1027
+
    1029-102A
+
    102C
+
    1031
+
    1038
+
    1040-1057
+
    10A0-10C5
+
    10D0-10F8
+
    10FB
+
    1100-1159
+
    115F-11A2
+
    11A8-11F9
+
    1200-1206
+
    1208-1246
+
    1248
+
    124A-124D
+
    1250-1256
+
    1258
+
    125A-125D
+
    1260-1286
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 86]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1288
+
    128A-128D
+
    1290-12AE
+
    12B0
+
    12B2-12B5
+
    12B8-12BE
+
    12C0
+
    12C2-12C5
+
    12C8-12CE
+
    12D0-12D6
+
    12D8-12EE
+
    12F0-130E
+
    1310
+
    1312-1315
+
    1318-131E
+
    1320-1346
+
    1348-135A
+
    1361-137C
+
    13A0-13F4
+
    1401-1676
+
    1681-169A
+
    16A0-16F0
+
    1700-170C
+
    170E-1711
+
    1720-1731
+
    1735-1736
+
    1740-1751
+
    1760-176C
+
    176E-1770
+
    1780-17B6
+
    17BE-17C5
+
    17C7-17C8
+
    17D4-17DA
+
    17DC
+
    17E0-17E9
+
    1810-1819
+
    1820-1877
+
    1880-18A8
+
    1E00-1E9B
+
    1EA0-1EF9
+
    1F00-1F15
+
    1F18-1F1D
+
    1F20-1F45
+
    1F48-1F4D
+
    1F50-1F57
+
    1F59
+
    1F5B
+
    1F5D
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 87]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    1F5F-1F7D
+
    1F80-1FB4
+
    1FB6-1FBC
+
    1FBE
+
    1FC2-1FC4
+
    1FC6-1FCC
+
    1FD0-1FD3
+
    1FD6-1FDB
+
    1FE0-1FEC
+
    1FF2-1FF4
+
    1FF6-1FFC
+
    200E
+
    2071
+
    207F
+
    2102
+
    2107
+
    210A-2113
+
    2115
+
    2119-211D
+
    2124
+
    2126
+
    2128
+
    212A-212D
+
    212F-2131
+
    2133-2139
+
    213D-213F
+
    2145-2149
+
    2160-2183
+
    2336-237A
+
    2395
+
    249C-24E9
+
    3005-3007
+
    3021-3029
+
    3031-3035
+
    3038-303C
+
    3041-3096
+
    309D-309F
+
    30A1-30FA
+
    30FC-30FF
+
    3105-312C
+
    3131-318E
+
    3190-31B7
+
    31F0-321C
+
    3220-3243
+
    3260-327B
+
    327F-32B0
+
    32C0-32CB
+
    32D0-32FE
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 88]
+
+
+
+
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
+
+
+
 
 
    3300-3376
+
    337B-33DD
+
    33E0-33FE
+
    3400-4DB5
+
    4E00-9FA5
+
    A000-A48C
+
    AC00-D7A3
+
    D800-FA2D
+
    FA30-FA6A
+
    FB00-FB06
+
    FB13-FB17
+
    FF21-FF3A
+
    FF41-FF5A
+
    FF66-FFBE
+
    FFC2-FFC7
+
    FFCA-FFCF
+
    FFD2-FFD7
+
    FFDA-FFDC
-   10300-1031E
-   10320-10323
-   10330-1034A
-   10400-10425
-   10428-1044D
-   1D000-1D0F5
-   1D100-1D126
-   1D12A-1D166
-   1D16A-1D172
-   1D183-1D184
-   1D18C-1D1A9
-   1D1AE-1D1DD
-   1D400-1D454
-   1D456-1D49C
-   1D49E-1D49F
-   1D4A2
-   1D4A5-1D4A6
-   1D4A9-1D4AC
-   1D4AE-1D4B9
-   1D4BB
-   1D4BD-1D4C0
-   1D4C2-1D4C3
-   1D4C5-1D505
-   1D507-1D50A
-   1D50D-1D514
-   1D516-1D51C
-   1D51E-1D539
-   1D53B-1D53E
-   1D540-1D544
-   1D546
 
+   10300-1031E
 
+   10320-10323
 
-Hoffman & Blanchet          Standards Track                    [Page 89]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
+   10330-1034A
 
+   10400-10425
 
-   1D54A-1D550
-   1D552-1D6A3
-   1D6A8-1D7C9
-   20000-2A6D6
-   2F800-2FA1D
-   F0000-FFFFD
-   100000-10FFFD
-   ----- End Table D.2 -----
+   10428-1044D
 
-Authors' Addresses
+   1D000-1D0F5
 
-   Paul Hoffman
-   Internet Mail Consortium and VPN Consortium
-   127 Segre Place
-   Santa Cruz, CA  95060 USA
+   1D100-1D126
 
-   EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org
+   1D12A-1D166
 
+   1D16A-1D172
 
-   Marc Blanchet
-   Viagenie inc.
-   2875 boul. Laurier, bur. 300
-   Ste-Foy, Quebec, Canada, G1V 2M2
+   1D183-1D184
 
-   EMail: Marc.Blanchet@viagenie.qc.ca
+   1D18C-1D1A9
 
+   1D1AE-1D1DD
 
+   1D400-1D454
 
+   1D456-1D49C
 
+   1D49E-1D49F
 
+   1D4A2
 
+   1D4A5-1D4A6
 
+   1D4A9-1D4AC
 
+   1D4AE-1D4B9
 
+   1D4BB
 
+   1D4BD-1D4C0
 
+   1D4C2-1D4C3
 
+   1D4C5-1D505
 
+   1D507-1D50A
 
+   1D50D-1D514
 
+   1D516-1D51C
 
+   1D51E-1D539
 
+   1D53B-1D53E
 
+   1D540-1D544
 
+   1D546
 
 
 
@@ -5039,61 +7050,25 @@ Authors' Addresses
 
 
 
-Hoffman & Blanchet          Standards Track                    [Page 90]
 
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
 
 
 
 
 
+   1D54A-1D550
 
+   1D552-1D6A3
 
+   1D6A8-1D7C9
 
+   20000-2A6D6
 
+   2F800-2FA1D
 
+   F0000-FFFFD
 
+   100000-10FFFD
 
+   ----- End Table D.2 -----
 
-Hoffman & Blanchet          Standards Track                    [Page 91]
-
diff --git a/lib/wind/rfc3490.txt b/lib/wind/rfc3490.txt
deleted file mode 100644
index d2e0b3b75..000000000
--- a/lib/wind/rfc3490.txt
+++ /dev/null
@@ -1,1235 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       P. Faltstrom
-Request for Comments: 3490                                         Cisco
-Category: Standards Track                                     P. Hoffman
-                                                              IMC & VPNC
-                                                             A. Costello
-                                                             UC Berkeley
-                                                              March 2003
-
-
-         Internationalizing Domain Names in Applications (IDNA)
-
-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 (2003).  All Rights Reserved.
-
-Abstract
-
-   Until now, there has been no standard method for domain names to use
-   characters outside the ASCII repertoire.  This document defines
-   internationalized domain names (IDNs) and a mechanism called
-   Internationalizing Domain Names in Applications (IDNA) for handling
-   them in a standard fashion.  IDNs use characters drawn from a large
-   repertoire (Unicode), but IDNA allows the non-ASCII characters to be
-   represented using only the ASCII characters already allowed in so-
-   called host names today.  This backward-compatible representation is
-   required in existing protocols like DNS, so that IDNs can be
-   introduced with no changes to the existing infrastructure.  IDNA is
-   only meant for processing domain names, not free text.
-
-Table of Contents
-
-   1. Introduction..................................................  2
-      1.1 Problem Statement.........................................  3
-      1.2 Limitations of IDNA.......................................  3
-      1.3 Brief overview for application developers.................  4
-   2. Terminology...................................................  5
-   3. Requirements and applicability................................  7
-      3.1 Requirements..............................................  7
-      3.2 Applicability.............................................  8
-         3.2.1. DNS resource records................................  8
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 1]
-
-RFC 3490                          IDNA                        March 2003
-
-
-         3.2.2. Non-domain-name data types stored in domain names...  9
-   4. Conversion operations.........................................  9
-      4.1 ToASCII................................................... 10
-      4.2 ToUnicode................................................. 11
-   5. ACE prefix.................................................... 12
-   6. Implications for typical applications using DNS............... 13
-      6.1 Entry and display in applications......................... 14
-      6.2 Applications and resolver libraries....................... 15
-      6.3 DNS servers............................................... 15
-      6.4 Avoiding exposing users to the raw ACE encoding........... 16
-      6.5  DNSSEC authentication of IDN domain names................ 16
-   7. Name server considerations.................................... 17
-   8. Root server considerations.................................... 17
-   9. References.................................................... 18
-      9.1 Normative References...................................... 18
-      9.2 Informative References.................................... 18
-   10. Security Considerations...................................... 19
-   11. IANA Considerations.......................................... 20
-   12. Authors' Addresses........................................... 21
-   13. Full Copyright Statement..................................... 22
-
-1. Introduction
-
-   IDNA works by allowing applications to use certain ASCII name labels
-   (beginning with a special prefix) to represent non-ASCII name labels.
-   Lower-layer protocols need not be aware of this; therefore IDNA does
-   not depend on changes to any infrastructure.  In particular, IDNA
-   does not depend on any changes to DNS servers, resolvers, or protocol
-   elements, because the ASCII name service provided by the existing DNS
-   is entirely sufficient for IDNA.
-
-   This document does not require any applications to conform to IDNA,
-   but applications can elect to use IDNA in order to support IDN while
-   maintaining interoperability with existing infrastructure.  If an
-   application wants to use non-ASCII characters in domain names, IDNA
-   is the only currently-defined option.  Adding IDNA support to an
-   existing application entails changes to the application only, and
-   leaves room for flexibility in the user interface.
-
-   A great deal of the discussion of IDN solutions has focused on
-   transition issues and how IDN will work in a world where not all of
-   the components have been updated.  Proposals that were not chosen by
-   the IDN Working Group would depend on user applications, resolvers,
-   and DNS servers being updated in order for a user to use an
-   internationalized domain name.  Rather than rely on widespread
-   updating of all components, IDNA depends on updates to user
-   applications only; no changes are needed to the DNS protocol or any
-   DNS servers or the resolvers on user's computers.
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 2]
-
-RFC 3490                          IDNA                        March 2003
-
-
-1.1 Problem Statement
-
-   The IDNA specification solves the problem of extending the repertoire
-   of characters that can be used in domain names to include the Unicode
-   repertoire (with some restrictions).
-
-   IDNA does not extend the service offered by DNS to the applications.
-   Instead, the applications (and, by implication, the users) continue
-   to see an exact-match lookup service.  Either there is a single
-   exactly-matching name or there is no match.  This model has served
-   the existing applications well, but it requires, with or without
-   internationalized domain names, that users know the exact spelling of
-   the domain names that the users type into applications such as web
-   browsers and mail user agents.  The introduction of the larger
-   repertoire of characters potentially makes the set of misspellings
-   larger, especially given that in some cases the same appearance, for
-   example on a business card, might visually match several Unicode code
-   points or several sequences of code points.
-
-   IDNA allows the graceful introduction of IDNs not only by avoiding
-   upgrades to existing infrastructure (such as DNS servers and mail
-   transport agents), but also by allowing some rudimentary use of IDNs
-   in applications by using the ASCII representation of the non-ASCII
-   name labels.  While such names are very user-unfriendly to read and
-   type, and hence are not suitable for user input, they allow (for
-   instance) replying to email and clicking on URLs even though the
-   domain name displayed is incomprehensible to the user.  In order to
-   allow user-friendly input and output of the IDNs, the applications
-   need to be modified to conform to this specification.
-
-   IDNA uses the Unicode character repertoire, which avoids the
-   significant delays that would be inherent in waiting for a different
-   and specific character set be defined for IDN purposes by some other
-   standards developing organization.
-
-1.2 Limitations of IDNA
-
-   The IDNA protocol does not solve all linguistic issues with users
-   inputting names in different scripts.  Many important language-based
-   and script-based mappings are not covered in IDNA and need to be
-   handled outside the protocol.  For example, names that are entered in
-   a mix of traditional and simplified Chinese characters will not be
-   mapped to a single canonical name.  Another example is Scandinavian
-   names that are entered with U+00F6 (LATIN SMALL LETTER O WITH
-   DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH
-   STROKE).
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 3]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   An example of an important issue that is not considered in detail in
-   IDNA is how to provide a high probability that a user who is entering
-   a domain name based on visual information (such as from a business
-   card or billboard) or aural information (such as from a telephone or
-   radio) would correctly enter the IDN.  Similar issues exist for ASCII
-   domain names, for example the possible visual confusion between the
-   letter 'O' and the digit zero, but the introduction of the larger
-   repertoire of characters creates more opportunities of similar
-   looking and similar sounding names.  Note that this is a complex
-   issue relating to languages, input methods on computers, and so on.
-   Furthermore, the kind of matching and searching necessary for a high
-   probability of success would not fit the role of the DNS and its
-   exact matching function.
-
-1.3 Brief overview for application developers
-
-   Applications can use IDNA to support internationalized domain names
-   anywhere that ASCII domain names are already supported, including DNS
-   master files and resolver interfaces.  (Applications can also define
-   protocols and interfaces that support IDNs directly using non-ASCII
-   representations.  IDNA does not prescribe any particular
-   representation for new protocols, but it still defines which names
-   are valid and how they are compared.)
-
-   The IDNA protocol is contained completely within applications.  It is
-   not a client-server or peer-to-peer protocol: everything is done
-   inside the application itself.  When used with a DNS resolver
-   library, IDNA is inserted as a "shim" between the application and the
-   resolver library.  When used for writing names into a DNS zone, IDNA
-   is used just before the name is committed to the zone.
-
-   There are two operations described in section 4 of this document:
-
-   -  The ToASCII operation is used before sending an IDN to something
-      that expects ASCII names (such as a resolver) or writing an IDN
-      into a place that expects ASCII names (such as a DNS master file).
-
-   -  The ToUnicode operation is used when displaying names to users,
-      for example names obtained from a DNS zone.
-
-   It is important to note that the ToASCII operation can fail.  If it
-   fails when processing a domain name, that domain name cannot be used
-   as an internationalized domain name and the application has to have
-   some method of dealing with this failure.
-
-   IDNA requires that implementations process input strings with
-   Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP],
-   and then with Punycode [PUNYCODE].  Implementations of IDNA MUST
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 4]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   fully implement Nameprep and Punycode; neither Nameprep nor Punycode
-   are optional.
-
-2. Terminology
-
-   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
-   and "MAY" in this document are to be interpreted as described in BCP
-   14, RFC 2119 [RFC2119].
-
-   A code point is an integer value associated with a character in a
-   coded character set.
-
-   Unicode [UNICODE] is a coded character set containing tens of
-   thousands of characters.  A single Unicode code point is denoted by
-   "U+" followed by four to six hexadecimal digits, while a range of
-   Unicode code points is denoted by two hexadecimal numbers separated
-   by "..", with no prefixes.
-
-   ASCII means US-ASCII [USASCII], a coded character set containing 128
-   characters associated with code points in the range 0..7F.  Unicode
-   is an extension of ASCII: it includes all the ASCII characters and
-   associates them with the same code points.
-
-   The term "LDH code points" is defined in this document to mean the
-   code points associated with ASCII letters, digits, and the hyphen-
-   minus; that is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an
-   abbreviation for "letters, digits, hyphen".
-
-   [STD13] talks about "domain names" and "host names", but many people
-   use the terms interchangeably.  Further, because [STD13] was not
-   terribly clear, many people who are sure they know the exact
-   definitions of each of these terms disagree on the definitions.  In
-   this document the term "domain name" is used in general.  This
-   document explicitly cites [STD3] whenever referring to the host name
-   syntax restrictions defined therein.
-
-   A label is an individual part of a domain name.  Labels are usually
-   shown separated by dots; for example, the domain name
-   "www.example.com" is composed of three labels: "www", "example", and
-   "com".  (The zero-length root label described in [STD13], which can
-   be explicit as in "www.example.com." or implicit as in
-   "www.example.com", is not considered a label in this specification.)
-   IDNA extends the set of usable characters in labels that are text.
-   For the rest of this document, the term "label" is shorthand for
-   "text label", and "every label" means "every text label".
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 5]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   An "internationalized label" is a label to which the ToASCII
-   operation (see section 4) can be applied without failing (with the
-   UseSTD3ASCIIRules flag unset).  This implies that every ASCII label
-   that satisfies the [STD13] length restriction is an internationalized
-   label.  Therefore the term "internationalized label" is a
-   generalization, embracing both old ASCII labels and new non-ASCII
-   labels.  Although most Unicode characters can appear in
-   internationalized labels, ToASCII will fail for some input strings,
-   and such strings are not valid internationalized labels.
-
-   An "internationalized domain name" (IDN) is a domain name in which
-   every label is an internationalized label.  This implies that every
-   ASCII domain name is an IDN (which implies that it is possible for a
-   name to be an IDN without it containing any non-ASCII characters).
-   This document does not attempt to define an "internationalized host
-   name".  Just as has been the case with ASCII names, some DNS zone
-   administrators may impose restrictions, beyond those imposed by DNS
-   or IDNA, on the characters or strings that may be registered as
-   labels in their zones.  Such restrictions have no impact on the
-   syntax or semantics of DNS protocol messages; a query for a name that
-   matches no records will yield the same response regardless of the
-   reason why it is not in the zone.  Clients issuing queries or
-   interpreting responses cannot be assumed to have any knowledge of
-   zone-specific restrictions or conventions.
-
-   In IDNA, equivalence of labels is defined in terms of the ToASCII
-   operation, which constructs an ASCII form for a given label, whether
-   or not the label was already an ASCII label.  Labels are defined to
-   be equivalent if and only if their ASCII forms produced by ToASCII
-   match using a case-insensitive ASCII comparison.  ASCII labels
-   already have a notion of equivalence: upper case and lower case are
-   considered equivalent.  The IDNA notion of equivalence is an
-   extension of that older notion.  Equivalent labels in IDNA are
-   treated as alternate forms of the same label, just as "foo" and "Foo"
-   are treated as alternate forms of the same label.
-
-   To allow internationalized labels to be handled by existing
-   applications, IDNA uses an "ACE label" (ACE stands for ASCII
-   Compatible Encoding).  An ACE label is an internationalized label
-   that can be rendered in ASCII and is equivalent to an
-   internationalized label that cannot be rendered in ASCII.  Given any
-   internationalized label that cannot be rendered in ASCII, the ToASCII
-   operation will convert it to an equivalent ACE label (whereas an
-   ASCII label will be left unaltered by ToASCII).  ACE labels are
-   unsuitable for display to users.  The ToUnicode operation will
-   convert any label to an equivalent non-ACE label.  In fact, an ACE
-   label is formally defined to be any label that the ToUnicode
-   operation would alter (whereas non-ACE labels are left unaltered by
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 6]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   ToUnicode).  Every ACE label begins with the ACE prefix specified in
-   section 5.  The ToASCII and ToUnicode operations are specified in
-   section 4.
-
-   The "ACE prefix" is defined in this document to be a string of ASCII
-   characters that appears at the beginning of every ACE label.  It is
-   specified in section 5.
-
-   A "domain name slot" is defined in this document to be a protocol
-   element or a function argument or a return value (and so on)
-   explicitly designated for carrying a domain name.  Examples of domain
-   name slots include: the QNAME field of a DNS query; the name argument
-   of the gethostbyname() library function; the part of an email address
-   following the at-sign (@) in the From: field of an email message
-   header; and the host portion of the URI in the src attribute of an
-   HTML <IMG> tag.  General text that just happens to contain a domain
-   name is not a domain name slot; for example, a domain name appearing
-   in the plain text body of an email message is not occupying a domain
-   name slot.
-
-   An "IDN-aware domain name slot" is defined in this document to be a
-   domain name slot explicitly designated for carrying an
-   internationalized domain name as defined in this document.  The
-   designation may be static (for example, in the specification of the
-   protocol or interface) or dynamic (for example, as a result of
-   negotiation in an interactive session).
-
-   An "IDN-unaware domain name slot" is defined in this document to be
-   any domain name slot that is not an IDN-aware domain name slot.
-   Obviously, this includes any domain name slot whose specification
-   predates IDNA.
-
-3. Requirements and applicability
-
-3.1 Requirements
-
-   IDNA conformance means adherence to the following four requirements:
-
-   1) Whenever dots are used as label separators, the following
-      characters MUST be recognized as dots: U+002E (full stop), U+3002
-      (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
-      (halfwidth ideographic full stop).
-
-   2) Whenever a domain name is put into an IDN-unaware domain name slot
-      (see section 2), it MUST contain only ASCII characters.  Given an
-      internationalized domain name (IDN), an equivalent domain name
-      satisfying this requirement can be obtained by applying the
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 7]
-
-RFC 3490                          IDNA                        March 2003
-
-
-      ToASCII operation (see section 4) to each label and, if dots are
-      used as label separators, changing all the label separators to
-      U+002E.
-
-   3) ACE labels obtained from domain name slots SHOULD be hidden from
-      users when it is known that the environment can handle the non-ACE
-      form, except when the ACE form is explicitly requested.  When it
-      is not known whether or not the environment can handle the non-ACE
-      form, the application MAY use the non-ACE form (which might fail,
-      such as by not being displayed properly), or it MAY use the ACE
-      form (which will look unintelligle to the user).  Given an
-      internationalized domain name, an equivalent domain name
-      containing no ACE labels can be obtained by applying the ToUnicode
-      operation (see section 4) to each label.  When requirements 2 and
-      3 both apply, requirement 2 takes precedence.
-
-   4) Whenever two labels are compared, they MUST be considered to match
-      if and only if they are equivalent, that is, their ASCII forms
-      (obtained by applying ToASCII) match using a case-insensitive
-      ASCII comparison.  Whenever two names are compared, they MUST be
-      considered to match if and only if their corresponding labels
-      match, regardless of whether the names use the same forms of label
-      separators.
-
-3.2 Applicability
-
-   IDNA is applicable to all domain names in all domain name slots
-   except where it is explicitly excluded.
-
-   This implies that IDNA is applicable to many protocols that predate
-   IDNA.  Note that IDNs occupying domain name slots in those protocols
-   MUST be in ASCII form (see section 3.1, requirement 2).
-
-3.2.1. DNS resource records
-
-   IDNA does not apply to domain names in the NAME and RDATA fields of
-   DNS resource records whose CLASS is not IN.  This exclusion applies
-   to every non-IN class, present and future, except where future
-   standards override this exclusion by explicitly inviting the use of
-   IDNA.
-
-   There are currently no other exclusions on the applicability of IDNA
-   to DNS resource records; it depends entirely on the CLASS, and not on
-   the TYPE.  This will remain true, even as new types are defined,
-   unless there is a compelling reason for a new type to complicate
-   matters by imposing type-specific rules.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 8]
-
-RFC 3490                          IDNA                        March 2003
-
-
-3.2.2. Non-domain-name data types stored in domain names
-
-   Although IDNA enables the representation of non-ASCII characters in
-   domain names, that does not imply that IDNA enables the
-   representation of non-ASCII characters in other data types that are
-   stored in domain names.  For example, an email address local part is
-   sometimes stored in a domain label (hostmaster@example.com would be
-   represented as hostmaster.example.com in the RDATA field of an SOA
-   record).  IDNA does not update the existing email standards, which
-   allow only ASCII characters in local parts.  Therefore, unless the
-   email standards are revised to invite the use of IDNA for local
-   parts, a domain label that holds the local part of an email address
-   SHOULD NOT begin with the ACE prefix, and even if it does, it is to
-   be interpreted literally as a local part that happens to begin with
-   the ACE prefix.
-
-4. Conversion operations
-
-   An application converts a domain name put into an IDN-unaware slot or
-   displayed to a user.  This section specifies the steps to perform in
-   the conversion, and the ToASCII and ToUnicode operations.
-
-   The input to ToASCII or ToUnicode is a single label that is a
-   sequence of Unicode code points (remember that all ASCII code points
-   are also Unicode code points).  If a domain name is represented using
-   a character set other than Unicode or US-ASCII, it will first need to
-   be transcoded to Unicode.
-
-   Starting from a whole domain name, the steps that an application
-   takes to do the conversions are:
-
-   1) Decide whether the domain name is a "stored string" or a "query
-      string" as described in [STRINGPREP].  If this conversion follows
-      the "queries" rule from [STRINGPREP], set the flag called
-      "AllowUnassigned".
-
-   2) Split the domain name into individual labels as described in
-      section 3.1.  The labels do not include the separator.
-
-   3) For each label, decide whether or not to enforce the restrictions
-      on ASCII characters in host names [STD3].  (Applications already
-      faced this choice before the introduction of IDNA, and can
-      continue to make the decision the same way they always have; IDNA
-      makes no new recommendations regarding this choice.)  If the
-      restrictions are to be enforced, set the flag called
-      "UseSTD3ASCIIRules" for that label.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 9]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   4) Process each label with either the ToASCII or the ToUnicode
-      operation as appropriate.  Typically, you use the ToASCII
-      operation if you are about to put the name into an IDN-unaware
-      slot, and you use the ToUnicode operation if you are displaying
-      the name to a user; section 3.1 gives greater detail on the
-      applicable requirements.
-
-   5) If ToASCII was applied in step 4 and dots are used as label
-      separators, change all the label separators to U+002E (full stop).
-
-   The following two subsections define the ToASCII and ToUnicode
-   operations that are used in step 4.
-
-   This description of the protocol uses specific procedure names, names
-   of flags, and so on, in order to facilitate the specification of the
-   protocol.  These names, as well as the actual steps of the
-   procedures, are not required of an implementation.  In fact, any
-   implementation which has the same external behavior as specified in
-   this document conforms to this specification.
-
-4.1 ToASCII
-
-   The ToASCII operation takes a sequence of Unicode code points that
-   make up one label and transforms it into a sequence of code points in
-   the ASCII range (0..7F).  If ToASCII succeeds, the original sequence
-   and the resulting sequence are equivalent labels.
-
-   It is important to note that the ToASCII operation can fail.  ToASCII
-   fails if any step of it fails.  If any step of the ToASCII operation
-   fails on any label in a domain name, that domain name MUST NOT be
-   used as an internationalized domain name.  The method for dealing
-   with this failure is application-specific.
-
-   The inputs to ToASCII are a sequence of code points, the
-   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
-   ToASCII is either a sequence of ASCII code points or a failure
-   condition.
-
-   ToASCII never alters a sequence of code points that are all in the
-   ASCII range to begin with (although it could fail).  Applying the
-   ToASCII operation multiple times has exactly the same effect as
-   applying it just once.
-
-   ToASCII consists of the following steps:
-
-   1. If the sequence contains any code points outside the ASCII range
-      (0..7F) then proceed to step 2, otherwise skip to step 3.
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 10]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   2. Perform the steps specified in [NAMEPREP] and fail if there is an
-      error.  The AllowUnassigned flag is used in [NAMEPREP].
-
-   3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
-
-     (a) Verify the absence of non-LDH ASCII code points; that is, the
-         absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
-
-     (b) Verify the absence of leading and trailing hyphen-minus; that
-         is, the absence of U+002D at the beginning and end of the
-         sequence.
-
-   4. If the sequence contains any code points outside the ASCII range
-      (0..7F) then proceed to step 5, otherwise skip to step 8.
-
-   5. Verify that the sequence does NOT begin with the ACE prefix.
-
-   6. Encode the sequence using the encoding algorithm in [PUNYCODE] and
-      fail if there is an error.
-
-   7. Prepend the ACE prefix.
-
-   8. Verify that the number of code points is in the range 1 to 63
-      inclusive.
-
-4.2 ToUnicode
-
-   The ToUnicode operation takes a sequence of Unicode code points that
-   make up one label and returns a sequence of Unicode code points.  If
-   the input sequence is a label in ACE form, then the result is an
-   equivalent internationalized label that is not in ACE form, otherwise
-   the original sequence is returned unaltered.
-
-   ToUnicode never fails.  If any step fails, then the original input
-   sequence is returned immediately in that step.
-
-   The ToUnicode output never contains more code points than its input.
-   Note that the number of octets needed to represent a sequence of code
-   points depends on the particular character encoding used.
-
-   The inputs to ToUnicode are a sequence of code points, the
-   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
-   ToUnicode is always a sequence of Unicode code points.
-
-   1. If all code points in the sequence are in the ASCII range (0..7F)
-      then skip to step 3.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 11]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   2. Perform the steps specified in [NAMEPREP] and fail if there is an
-      error.  (If step 3 of ToASCII is also performed here, it will not
-      affect the overall behavior of ToUnicode, but it is not
-      necessary.)  The AllowUnassigned flag is used in [NAMEPREP].
-
-   3. Verify that the sequence begins with the ACE prefix, and save a
-      copy of the sequence.
-
-   4. Remove the ACE prefix.
-
-   5. Decode the sequence using the decoding algorithm in [PUNYCODE] and
-      fail if there is an error.  Save a copy of the result of this
-      step.
-
-   6. Apply ToASCII.
-
-   7. Verify that the result of step 6 matches the saved copy from step
-      3, using a case-insensitive ASCII comparison.
-
-   8. Return the saved copy from step 5.
-
-5. ACE prefix
-
-   The ACE prefix, used in the conversion operations (section 4), is two
-   alphanumeric ASCII characters followed by two hyphen-minuses.  It
-   cannot be any of the prefixes already used in earlier documents,
-   which includes the following: "bl--", "bq--", "dq--", "lq--", "mq--",
-   "ra--", "wq--" and "zq--".  The ToASCII and ToUnicode operations MUST
-   recognize the ACE prefix in a case-insensitive manner.
-
-   The ACE prefix for IDNA is "xn--" or any capitalization thereof.
-
-   This means that an ACE label might be "xn--de-jg4avhby1noc0d", where
-   "de-jg4avhby1noc0d" is the part of the ACE label that is generated by
-   the encoding steps in [PUNYCODE].
-
-   While all ACE labels begin with the ACE prefix, not all labels
-   beginning with the ACE prefix are necessarily ACE labels.  Non-ACE
-   labels that begin with the ACE prefix will confuse users and SHOULD
-   NOT be allowed in DNS zones.
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 12]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6. Implications for typical applications using DNS
-
-   In IDNA, applications perform the processing needed to input
-   internationalized domain names from users, display internationalized
-   domain names to users, and process the inputs and outputs from DNS
-   and other protocols that carry domain names.
-
-   The components and interfaces between them can be represented
-   pictorially as:
-
-                    +------+
-                    | User |
-                    +------+
-                       ^
-                       | Input and display: local interface methods
-                       | (pen, keyboard, glowing phosphorus, ...)
-   +-------------------|-------------------------------+
-   |                   v                               |
-   |          +-----------------------------+          |
-   |          |        Application          |          |
-   |          |   (ToASCII and ToUnicode    |          |
-   |          |      operations may be      |          |
-   |          |        called here)         |          |
-   |          +-----------------------------+          |
-   |                   ^        ^                      | End system
-   |                   |        |                      |
-   | Call to resolver: |        | Application-specific |
-   |              ACE  |        | protocol:            |
-   |                   v        | ACE unless the       |
-   |           +----------+     | protocol is updated  |
-   |           | Resolver |     | to handle other      |
-   |           +----------+     | encodings            |
-   |                 ^          |                      |
-   +-----------------|----------|----------------------+
-       DNS protocol: |          |
-                 ACE |          |
-                     v          v
-          +-------------+    +---------------------+
-          | DNS servers |    | Application servers |
-          +-------------+    +---------------------+
-
-   The box labeled "Application" is where the application splits a
-   domain name into labels, sets the appropriate flags, and performs the
-   ToASCII and ToUnicode operations.  This is described in section 4.
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 13]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6.1 Entry and display in applications
-
-   Applications can accept domain names using any character set or sets
-   desired by the application developer, and can display domain names in
-   any charset.  That is, the IDNA protocol does not affect the
-   interface between users and applications.
-
-   An IDNA-aware application can accept and display internationalized
-   domain names in two formats: the internationalized character set(s)
-   supported by the application, and as an ACE label.  ACE labels that
-   are displayed or input MUST always include the ACE prefix.
-   Applications MAY allow input and display of ACE labels, but are not
-   encouraged to do so except as an interface for special purposes,
-   possibly for debugging, or to cope with display limitations as
-   described in section 6.4..  ACE encoding is opaque and ugly, and
-   should thus only be exposed to users who absolutely need it.  Because
-   name labels encoded as ACE name labels can be rendered either as the
-   encoded ASCII characters or the proper decoded characters, the
-   application MAY have an option for the user to select the preferred
-   method of display; if it does, rendering the ACE SHOULD NOT be the
-   default.
-
-   Domain names are often stored and transported in many places.  For
-   example, they are part of documents such as mail messages and web
-   pages.  They are transported in many parts of many protocols, such as
-   both the control commands and the RFC 2822 body parts of SMTP, and
-   the headers and the body content in HTTP.  It is important to
-   remember that domain names appear both in domain name slots and in
-   the content that is passed over protocols.
-
-   In protocols and document formats that define how to handle
-   specification or negotiation of charsets, labels can be encoded in
-   any charset allowed by the protocol or document format.  If a
-   protocol or document format only allows one charset, the labels MUST
-   be given in that charset.
-
-   In any place where a protocol or document format allows transmission
-   of the characters in internationalized labels, internationalized
-   labels SHOULD be transmitted using whatever character encoding and
-   escape mechanism that the protocol or document format uses at that
-   place.
-
-   All protocols that use domain name slots already have the capacity
-   for handling domain names in the ASCII charset.  Thus, ACE labels
-   (internationalized labels that have been processed with the ToASCII
-   operation) can inherently be handled by those protocols.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 14]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6.2 Applications and resolver libraries
-
-   Applications normally use functions in the operating system when they
-   resolve DNS queries.  Those functions in the operating system are
-   often called "the resolver library", and the applications communicate
-   with the resolver libraries through a programming interface (API).
-
-   Because these resolver libraries today expect only domain names in
-   ASCII, applications MUST prepare labels that are passed to the
-   resolver library using the ToASCII operation.  Labels received from
-   the resolver library contain only ASCII characters; internationalized
-   labels that cannot be represented directly in ASCII use the ACE form.
-   ACE labels always include the ACE prefix.
-
-   An operating system might have a set of libraries for performing the
-   ToASCII operation.  The input to such a library might be in one or
-   more charsets that are used in applications (UTF-8 and UTF-16 are
-   likely candidates for almost any operating system, and script-
-   specific charsets are likely for localized operating systems).
-
-   IDNA-aware applications MUST be able to work with both non-
-   internationalized labels (those that conform to [STD13] and [STD3])
-   and internationalized labels.
-
-   It is expected that new versions of the resolver libraries in the
-   future will be able to accept domain names in other charsets than
-   ASCII, and application developers might one day pass not only domain
-   names in Unicode, but also in local script to a new API for the
-   resolver libraries in the operating system.  Thus the ToASCII and
-   ToUnicode operations might be performed inside these new versions of
-   the resolver libraries.
-
-   Domain names passed to resolvers or put into the question section of
-   DNS requests follow the rules for "queries" from [STRINGPREP].
-
-6.3 DNS servers
-
-   Domain names stored in zones follow the rules for "stored strings"
-   from [STRINGPREP].
-
-   For internationalized labels that cannot be represented directly in
-   ASCII, DNS servers MUST use the ACE form produced by the ToASCII
-   operation.  All IDNs served by DNS servers MUST contain only ASCII
-   characters.
-
-   If a signaling system which makes negotiation possible between old
-   and new DNS clients and servers is standardized in the future, the
-   encoding of the query in the DNS protocol itself can be changed from
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 15]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   ACE to something else, such as UTF-8.  The question whether or not
-   this should be used is, however, a separate problem and is not
-   discussed in this memo.
-
-6.4 Avoiding exposing users to the raw ACE encoding
-
-   Any application that might show the user a domain name obtained from
-   a domain name slot, such as from gethostbyaddr or part of a mail
-   header, will need to be updated if it is to prevent users from seeing
-   the ACE.
-
-   If an application decodes an ACE name using ToUnicode but cannot show
-   all of the characters in the decoded name, such as if the name
-   contains characters that the output system cannot display, the
-   application SHOULD show the name in ACE format (which always includes
-   the ACE prefix) instead of displaying the name with the replacement
-   character (U+FFFD).  This is to make it easier for the user to
-   transfer the name correctly to other programs.  Programs that by
-   default show the ACE form when they cannot show all the characters in
-   a name label SHOULD also have a mechanism to show the name that is
-   produced by the ToUnicode operation with as many characters as
-   possible and replacement characters in the positions where characters
-   cannot be displayed.
-
-   The ToUnicode operation does not alter labels that are not valid ACE
-   labels, even if they begin with the ACE prefix.  After ToUnicode has
-   been applied, if a label still begins with the ACE prefix, then it is
-   not a valid ACE label, and is not equivalent to any of the
-   intermediate Unicode strings constructed by ToUnicode.
-
-6.5  DNSSEC authentication of IDN domain names
-
-   DNS Security [RFC2535] is a method for supplying cryptographic
-   verification information along with DNS messages.  Public Key
-   Cryptography is used in conjunction with digital signatures to
-   provide a means for a requester of domain information to authenticate
-   the source of the data.  This ensures that it can be traced back to a
-   trusted source, either directly, or via a chain of trust linking the
-   source of the information to the top of the DNS hierarchy.
-
-   IDNA specifies that all internationalized domain names served by DNS
-   servers that cannot be represented directly in ASCII must use the ACE
-   form produced by the ToASCII operation.  This operation must be
-   performed prior to a zone being signed by the private key for that
-   zone.  Because of this ordering, it is important to recognize that
-   DNSSEC authenticates the ASCII domain name, not the Unicode form or
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 16]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   the mapping between the Unicode form and the ASCII form.  In the
-   presence of DNSSEC, this is the name that MUST be signed in the zone
-   and MUST be validated against.
-
-   One consequence of this for sites deploying IDNA in the presence of
-   DNSSEC is that any special purpose proxies or forwarders used to
-   transform user input into IDNs must be earlier in the resolution flow
-   than DNSSEC authenticating nameservers for DNSSEC to work.
-
-7. Name server considerations
-
-   Existing DNS servers do not know the IDNA rules for handling non-
-   ASCII forms of IDNs, and therefore need to be shielded from them.
-   All existing channels through which names can enter a DNS server
-   database (for example, master files [STD13] and DNS update messages
-   [RFC2136]) are IDN-unaware because they predate IDNA, and therefore
-   requirement 2 of section 3.1 of this document provides the needed
-   shielding, by ensuring that internationalized domain names entering
-   DNS server databases through such channels have already been
-   converted to their equivalent ASCII forms.
-
-   It is imperative that there be only one ASCII encoding for a
-   particular domain name.  Because of the design of the ToASCII and
-   ToUnicode operations, there are no ACE labels that decode to ASCII
-   labels, and therefore name servers cannot contain multiple ASCII
-   encodings of the same domain name.
-
-   [RFC2181] explicitly allows domain labels to contain octets beyond
-   the ASCII range (0..7F), and this document does not change that.
-   Note, however, that there is no defined interpretation of octets
-   80..FF as characters.  If labels containing these octets are returned
-   to applications, unpredictable behavior could result.  The ASCII form
-   defined by ToASCII is the only standard representation for
-   internationalized labels in the current DNS protocol.
-
-8. Root server considerations
-
-   IDNs are likely to be somewhat longer than current domain names, so
-   the bandwidth needed by the root servers is likely to go up by a
-   small amount.  Also, queries and responses for IDNs will probably be
-   somewhat longer than typical queries today, so more queries and
-   responses may be forced to go to TCP instead of UDP.
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 17]
-
-RFC 3490                          IDNA                        March 2003
-
-
-9. References
-
-9.1 Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [NAMEPREP]   Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
-                Profile for Internationalized Domain Names (IDN)", RFC
-                3491, March 2003.
-
-   [PUNYCODE]   Costello, A., "Punycode: A Bootstring encoding of
-                Unicode for use with Internationalized Domain Names in
-                Applications (IDNA)", RFC 3492, March 2003.
-
-   [STD3]       Braden, R., "Requirements for Internet Hosts --
-                Communication Layers", STD 3, RFC 1122, and
-                "Requirements for Internet Hosts -- Application and
-                Support", STD 3, RFC 1123, October 1989.
-
-   [STD13]      Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034 and "Domain names -
-                implementation and specification", STD 13, RFC 1035,
-                November 1987.
-
-9.2 Informative References
-
-   [RFC2535]    Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [RFC2181]    Elz, R. and R. Bush, "Clarifications to the DNS
-                Specification", RFC 2181, July 1997.
-
-   [UAX9]       Unicode Standard Annex #9, The Bidirectional Algorithm,
-                <http://www.unicode.org/unicode/reports/tr9/>.
-
-   [UNICODE]    The Unicode Consortium. The Unicode Standard, Version
-                3.2.0 is defined by The Unicode Standard, Version 3.0
-                (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
-                as amended by the Unicode Standard Annex #27: Unicode
-                3.1 (http://www.unicode.org/reports/tr27/) and by the
-                Unicode Standard Annex #28: Unicode 3.2
-                (http://www.unicode.org/reports/tr28/).
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 18]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   [USASCII]    Cerf, V., "ASCII format for Network Interchange", RFC
-                20, October 1969.
-
-10. Security Considerations
-
-   Security on the Internet partly relies on the DNS.  Thus, any change
-   to the characteristics of the DNS can change the security of much of
-   the Internet.
-
-   This memo describes an algorithm which encodes characters that are
-   not valid according to STD3 and STD13 into octet values that are
-   valid.  No security issues such as string length increases or new
-   allowed values are introduced by the encoding process or the use of
-   these encoded values, apart from those introduced by the ACE encoding
-   itself.
-
-   Domain names are used by users to identify and connect to Internet
-   servers.  The security of the Internet is compromised if a user
-   entering a single internationalized name is connected to different
-   servers based on different interpretations of the internationalized
-   domain name.
-
-   When systems use local character sets other than ASCII and Unicode,
-   this specification leaves the the problem of transcoding between the
-   local character set and Unicode up to the application.  If different
-   applications (or different versions of one application) implement
-   different transcoding rules, they could interpret the same name
-   differently and contact different servers.  This problem is not
-   solved by security protocols like TLS that do not take local
-   character sets into account.
-
-   Because this document normatively refers to [NAMEPREP], [PUNYCODE],
-   and [STRINGPREP], it includes the security considerations from those
-   documents as well.
-
-   If or when this specification is updated to use a more recent Unicode
-   normalization table, the new normalization table will need to be
-   compared with the old to spot backwards incompatible changes.  If
-   there are such changes, they will need to be handled somehow, or
-   there will be security as well as operational implications.  Methods
-   to handle the conflicts could include keeping the old normalization,
-   or taking care of the conflicting characters by operational means, or
-   some other method.
-
-   Implementations MUST NOT use more recent normalization tables than
-   the one referenced from this document, even though more recent tables
-   may be provided by operating systems.  If an application is unsure of
-   which version of the normalization tables are in the operating
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 19]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   system, the application needs to include the normalization tables
-   itself.  Using normalization tables other than the one referenced
-   from this specification could have security and operational
-   implications.
-
-   To help prevent confusion between characters that are visually
-   similar, it is suggested that implementations provide visual
-   indications where a domain name contains multiple scripts.  Such
-   mechanisms can also be used to show when a name contains a mixture of
-   simplified and traditional Chinese characters, or to distinguish zero
-   and one from O and l.  DNS zone adminstrators may impose restrictions
-   (subject to the limitations in section 2) that try to minimize
-   homographs.
-
-   Domain names (or portions of them) are sometimes compared against a
-   set of privileged or anti-privileged domains.  In such situations it
-   is especially important that the comparisons be done properly, as
-   specified in section 3.1 requirement 4.  For labels already in ASCII
-   form, the proper comparison reduces to the same case-insensitive
-   ASCII comparison that has always been used for ASCII labels.
-
-   The introduction of IDNA means that any existing labels that start
-   with the ACE prefix and would be altered by ToUnicode will
-   automatically be ACE labels, and will be considered equivalent to
-   non-ASCII labels, whether or not that was the intent of the zone
-   adminstrator or registrant.
-
-11. IANA Considerations
-
-   IANA has assigned the ACE prefix in consultation with the IESG.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 20]
-
-RFC 3490                          IDNA                        March 2003
-
-
-12. Authors' Addresses
-
-   Patrik Faltstrom
-   Cisco Systems
-   Arstaangsvagen 31 J
-   S-117 43 Stockholm  Sweden
-
-   EMail: paf@cisco.com
-
-
-   Paul Hoffman
-   Internet Mail Consortium and VPN Consortium
-   127 Segre Place
-   Santa Cruz, CA  95060  USA
-
-   EMail: phoffman@imc.org
-
-
-   Adam M. Costello
-   University of California, Berkeley
-
-   URL: http://www.nicemice.net/amc/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 21]
-
-RFC 3490                          IDNA                        March 2003
-
-
-13. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 22]
-
diff --git a/lib/wind/rfc3491.txt b/lib/wind/rfc3491.txt
deleted file mode 100644
index dbc86c7fe..000000000
--- a/lib/wind/rfc3491.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         P. Hoffman
-Request for Comments: 3491                                    IMC & VPNC
-Category: Standards Track                                    M. Blanchet
-                                                                Viagenie
-                                                              March 2003
-
-
-                   Nameprep: A Stringprep Profile for
-                  Internationalized Domain Names (IDN)
-
-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 (2003).  All Rights Reserved.
-
-Abstract
-
-   This document describes how to prepare internationalized domain name
-   (IDN) labels in order to increase the likelihood that name input and
-   name comparison work in ways that make sense for typical users
-   throughout the world.  This profile of the stringprep protocol is
-   used as part of a suite of on-the-wire protocols for
-   internationalizing the Domain Name System (DNS).
-
-1. Introduction
-
-   This document specifies processing rules that will allow users to
-   enter internationalized domain names (IDNs) into applications and
-   have the highest chance of getting the content of the strings
-   correct.  It is a profile of stringprep [STRINGPREP].  These
-   processing rules are only intended for internationalized domain
-   names, not for arbitrary text.
-
-   This profile defines the following, as required by [STRINGPREP].
-
-   -  The intended applicability of the profile: internationalized
-      domain names processed by IDNA.
-
-   -  The character repertoire that is the input and output to
-      stringprep:  Unicode 3.2, specified in section 2.
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 1]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-   -  The mappings used: specified in section 3.
-
-   -  The Unicode normalization used: specified in section 4.
-
-   -  The characters that are prohibited as output: specified in section
-      5.
-
-   -  Bidirectional character handling: specified in section 6.
-
-1.1 Interaction of protocol parts
-
-   Nameprep is used by the IDNA [IDNA] protocol for preparing domain
-   names; it is not designed for any other purpose.  It is explicitly
-   not designed for processing arbitrary free text and SHOULD NOT be
-   used for that purpose.  Nameprep is a profile of Stringprep
-   [STRINGPREP].  Implementations of Nameprep MUST fully implement
-   Stringprep.
-
-   Nameprep is used to process domain name labels, not domain names.
-   IDNA calls nameprep for each label in a domain name, not for the
-   whole domain name.
-
-1.2 Terminology
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
-   in this document are to be interpreted as described in BCP 14, RFC
-   2119 [RFC2119].
-
-2. Character Repertoire
-
-   This profile uses Unicode 3.2, as defined in [STRINGPREP] Appendix A.
-
-3. Mapping
-
-   This profile specifies mapping using the following tables from
-   [STRINGPREP]:
-
-   Table B.1
-   Table B.2
-
-4. Normalization
-
-   This profile specifies using Unicode normalization form KC, as
-   described in [STRINGPREP].
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 2]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-5. Prohibited Output
-
-   This profile specifies prohibiting using the following tables from
-   [STRINGPREP]:
-
-   Table C.1.2
-   Table C.2.2
-   Table C.3
-   Table C.4
-   Table C.5
-   Table C.6
-   Table C.7
-   Table C.8
-   Table C.9
-
-   IMPORTANT NOTE: This profile MUST be used with the IDNA protocol.
-   The IDNA protocol has additional prohibitions that are checked
-   outside of this profile.
-
-6. Bidirectional characters
-
-   This profile specifies checking bidirectional strings as described in
-   [STRINGPREP] section 6.
-
-7. Unassigned Code Points in Internationalized Domain Names
-
-   If the processing in [IDNA] specifies that a list of unassigned code
-   points be used, the system uses table A.1 from [STRINGPREP] as its
-   list of unassigned code points.
-
-8. References
-
-8.1 Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [IDNA]       Faltstrom, P., Hoffman, P. and A. Costello,
-                "Internationalizing Domain Names in Applications
-                (IDNA)", RFC 3490, March 2003.
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 3]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-8.2 Informative references
-
-   [STD13]      Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034, and "Domain names -
-                implementation and specification", STD 13, RFC 1035,
-                November 1987.
-
-9. Security Considerations
-
-   The Unicode and ISO/IEC 10646 repertoires have many characters that
-   look similar.  In many cases, users of security protocols might do
-   visual matching, such as when comparing the names of trusted third
-   parties.  Because it is impossible to map similar-looking characters
-   without a great deal of context such as knowing the fonts used,
-   stringprep does nothing to map similar-looking characters together
-   nor to prohibit some characters because they look like others.
-
-   Security on the Internet partly relies on the DNS.  Thus, any change
-   to the characteristics of the DNS can change the security of much of
-   the Internet.
-
-   Domain names are used by users to connect to Internet servers.  The
-   security of the Internet would be compromised if a user entering a
-   single internationalized name could be connected to different servers
-   based on different interpretations of the internationalized domain
-   name.
-
-   Current applications might assume that the characters allowed in
-   domain names will always be the same as they are in [STD13].  This
-   document vastly increases the number of characters available in
-   domain names.  Every program that uses "special" characters in
-   conjunction with domain names may be vulnerable to attack based on
-   the new characters allowed by this specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 4]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-10. IANA Considerations
-
-   This is a profile of stringprep.  It has been registered by the IANA
-   in the stringprep profile registry
-   (www.iana.org/assignments/stringprep-profiles).
-
-      Name of this profile:
-         Nameprep
-
-      RFC in which the profile is defined:
-         This document.
-
-      Indicator whether or not this is the newest version of the
-      profile:
-         This is the first version of Nameprep.
-
-11. Acknowledgements
-
-   Many people from the IETF IDN Working Group and the Unicode Technical
-   Committee contributed ideas that went into this document.
-
-   The IDN Nameprep design team made many useful changes to the
-   document.  That team and its advisors include:
-
-      Asmus Freytag
-      Cathy Wissink
-      Francois Yergeau
-      James Seng
-      Marc Blanchet
-      Mark Davis
-      Martin Duerst
-      Patrik Faltstrom
-      Paul Hoffman
-
-   Additional significant improvements were proposed by:
-
-      Jonathan Rosenne
-      Kent Karlsson
-      Scott Hollenbeck
-      Dave Crocker
-      Erik Nordmark
-      Matitiahu Allouche
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 5]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-12. Authors' Addresses
-
-   Paul Hoffman
-   Internet Mail Consortium and VPN Consortium
-   127 Segre Place
-   Santa Cruz, CA  95060 USA
-
-   EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org
-
-
-   Marc Blanchet
-   Viagenie inc.
-   2875 boul. Laurier, bur. 300
-   Ste-Foy, Quebec, Canada, G1V 2M2
-
-   EMail: Marc.Blanchet@viagenie.qc.ca
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 6]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-13.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 7]
-
diff --git a/lib/wind/rfc4013.txt b/lib/wind/rfc4013.txt
deleted file mode 100644
index 54a1d3158..000000000
--- a/lib/wind/rfc4013.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        K. Zeilenga
-Request for Comments: 4013                           OpenLDAP Foundation
-Category: Standards Track                                  February 2005
-
-
-       SASLprep: Stringprep Profile for User Names and Passwords
-
-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 how to prepare Unicode strings representing
-   user names and passwords for comparison.  The document defines the
-   "SASLprep" profile of the "stringprep" algorithm to be used for both
-   user names and passwords.  This profile is intended to be used by
-   Simple Authentication and Security Layer (SASL) mechanisms (such as
-   PLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols
-   exchanging simple user names and/or passwords.
-
-1.  Introduction
-
-   The use of simple user names and passwords in authentication and
-   authorization is pervasive on the Internet.  To increase the
-   likelihood that user name and password input and comparison work in
-   ways that make sense for typical users throughout the world, this
-   document defines rules for preparing internationalized user names and
-   passwords for comparison.  For simplicity and implementation ease, a
-   single algorithm is defined for both user names and passwords.
-
-   The algorithm assumes all strings are comprised of characters from
-   the Unicode [Unicode] character set.
-
-   This document defines the "SASLprep" profile of the "stringprep"
-   algorithm [StringPrep].
-
-   The profile is designed for use in Simple Authentication and Security
-   Layer ([SASL]) mechanisms, such as [PLAIN], [CRAM-MD5], and
-   [DIGEST-MD5].  It may be applicable where simple user names and
-
-
-
-Zeilenga                    Standards Track                     [Page 1]
-
-RFC 4013                        SASLprep                   February 2005
-
-
-   passwords are used.  This profile is not intended for use in
-   preparing identity strings that are not simple user names (e.g.,
-   email addresses, domain names, distinguished names), or where
-   identity or password strings that are not character data, or require
-   different handling (e.g., case folding).
-
-   This document does not alter the technical specification of any
-   existing protocols.  Any specification that wishes to use the
-   algorithm described in this document needs to explicitly incorporate
-   this document and provide precise details as to where and how this
-   algorithm is used by implementations of that specification.
-
-2.  The SASLprep Profile
-
-   This section defines the "SASLprep" profile of the "stringprep"
-   algorithm [StringPrep].  This profile is intended for use in
-   preparing strings representing simple user names and passwords.
-
-   This profile uses Unicode 3.2 [Unicode].
-
-   Character names in this document use the notation for code points and
-   names from the Unicode Standard [Unicode].  For example, the letter
-   "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
-   In the lists of mappings and the prohibited characters, the "U+" is
-   left off to make the lists easier to read.  The comments for
-   character ranges are shown in square brackets (such as "[CONTROL
-   CHARACTERS]") and do not come from the standard.
-
-   Note: A glossary of terms used in Unicode can be found in [Glossary].
-   Information on the Unicode character encoding model can be found in
-   [CharModel].
-
-2.1.  Mapping
-
-   This profile specifies:
-
-      -  non-ASCII space characters [StringPrep, C.1.2] that can be
-         mapped to SPACE (U+0020), and
-
-      -  the "commonly mapped to nothing" characters [StringPrep, B.1]
-         that can be mapped to nothing.
-
-2.2.  Normalization
-
-   This profile specifies using Unicode normalization form KC, as
-   described in Section 4 of [StringPrep].
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 2]
-
-RFC 4013                        SASLprep                   February 2005
-
-
-2.3.  Prohibited Output
-
-   This profile specifies the following characters as prohibited input:
-
-      - Non-ASCII space characters [StringPrep, C.1.2]
-      - ASCII control characters [StringPrep, C.2.1]
-      - Non-ASCII control characters [StringPrep, C.2.2]
-      - Private Use characters [StringPrep, C.3]
-      - Non-character code points [StringPrep, C.4]
-      - Surrogate code points [StringPrep, C.5]
-      - Inappropriate for plain text characters [StringPrep, C.6]
-      - Inappropriate for canonical representation characters
-        [StringPrep, C.7]
-      - Change display properties or deprecated characters
-        [StringPrep, C.8]
-      - Tagging characters [StringPrep, C.9]
-
-2.4.  Bidirectional Characters
-
-   This profile specifies checking bidirectional strings as described in
-   [StringPrep, Section 6].
-
-2.5.  Unassigned Code Points
-
-   This profile specifies the [StringPrep, A.1] table as its list of
-   unassigned code points.
-
-3.  Examples
-
-   The following table provides examples of how various character data
-   is transformed by the SASLprep string preparation algorithm
-
-   #  Input            Output     Comments
-   -  -----            ------     --------
-   1  I<U+00AD>X       IX         SOFT HYPHEN mapped to nothing
-   2  user             user       no transformation
-   3  USER             USER       case preserved, will not match #2
-   4  <U+00AA>         a          output is NFKC, input in ISO 8859-1
-   5  <U+2168>         IX         output is NFKC, will match #1
-   6  <U+0007>                    Error - prohibited character
-   7  <U+0627><U+0031>            Error - bidirectional check
-
-4.  Security Considerations
-
-   This profile is intended to prepare simple user name and password
-   strings for comparison or use in cryptographic functions (e.g.,
-   message digests).  The preparation algorithm was specifically
-   designed such that its output is canonical, and it is well-formed.
-
-
-
-Zeilenga                    Standards Track                     [Page 3]
-
-RFC 4013                        SASLprep                   February 2005
-
-
-   However, due to an anomaly [PR29] in the specification of Unicode
-   normalization, canonical equivalence is not guaranteed for a select
-   few character sequences.  These sequences, however, do not appear in
-   well-formed text.  This specification was published despite this
-   known technical problem.  It is expected that this specification will
-   be revised before further progression on the Standards Track (after
-   [Unicode] and/or [StringPrep] specifications have been updated to
-   address this problem).
-
-   It is not intended for preparing identity strings that are not simple
-   user names (e.g., distinguished names, domain names), nor is the
-   profile intended for use of simple user names that require different
-   handling (such as case folding).  Protocols (or applications of those
-   protocols) that have application-specific identity forms and/or
-   comparison algorithms should use mechanisms specifically designed for
-   these forms and algorithms.
-
-   Application of string preparation may have an impact upon the
-   feasibility of brute force and dictionary attacks.  While the number
-   of possible prepared strings is less than the number of possible
-   Unicode strings, the number of usable names and passwords is greater
-   than as if only ASCII was used.  Though SASLprep eliminates some
-   Unicode code point sequences as possible prepared strings, that
-   elimination generally makes the (canonical) output forms practicable
-   and prohibits nonsensical inputs.
-
-   User names and passwords should be protected from eavesdropping.
-
-   General "stringprep" and Unicode security considerations apply.  Both
-   are discussed in [StringPrep].
-
-5.  IANA Considerations
-
-   This document details the "SASLprep" profile of the [StringPrep]
-   protocol.  This profile has been registered in the stringprep profile
-   registry.
-
-      Name of this profile: SASLprep
-      RFC in which the profile is defined: RFC 4013
-      Indicator whether or not this is the newest version of the
-      profile: This is the first version of the SASPprep profile.
-
-6.  Acknowledgement
-
-   This document borrows text from "Preparation of Internationalized
-   Strings ('stringprep')" and "Nameprep: A Stringprep Profile for
-   Internationalized Domain Names", both by Paul Hoffman and Marc
-   Blanchet.  This document is a product of the IETF SASL WG.
-
-
-
-Zeilenga                    Standards Track                     [Page 4]
-
-RFC 4013                        SASLprep                   February 2005
-
-
-7.  Normative References
-
-   [StringPrep]  Hoffman, P. and M. Blanchet, "Preparation of
-                 Internationalized Strings ("stringprep")", RFC 3454,
-                 December 2002.
-
-   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
-                 3.2.0" is defined by "The Unicode Standard, Version
-                 3.0" (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-
-                 61633-5), as amended by the "Unicode Standard Annex
-                 #27: Unicode 3.1"
-                 (http://www.unicode.org/reports/tr27/) and by the
-                 "Unicode Standard Annex #28: Unicode 3.2"
-                 (http://www.unicode.org/reports/tr28/).
-
-8.  Informative References
-
-   [Glossary]    The Unicode Consortium, "Unicode Glossary",
-                 <http://www.unicode.org/glossary/>.
-
-   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
-                 #17, Character Encoding Model", UTR17,
-                 <http://www.unicode.org/unicode/reports/tr17/>, August
-                 2000.
-
-   [SASL]        Melnikov, A., Ed., "Simple Authentication and Security
-                 Layer (SASL)", Work in Progress.
-
-   [CRAM-MD5]    Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in
-                 Progress.
-
-   [DIGEST-MD5]  Leach, P., Newman, C., and A. Melnikov, "Using Digest
-                 Authentication as a SASL Mechanism", Work in Progress.
-
-   [PLAIN]       Zeilenga, K., Ed., "The Plain SASL Mechanism", Work in
-                 Progress.
-
-   [PR29]        "Public Review Issue #29: Normalization Issue",
-                 <http://www.unicode.org/review/pr-29.html>, February
-                 2004.
-
-Author's Address
-
-   Kurt D. Zeilenga
-   OpenLDAP Foundation
-
-   EMail: Kurt@OpenLDAP.org
-
-
-
-
-Zeilenga                    Standards Track                     [Page 5]
-
-RFC 4013                        SASLprep                   February 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the IETF's procedures with respect to rights in IETF Documents can
-   be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 6]
-
diff --git a/lib/wind/rfc4518.txt b/lib/wind/rfc4518.txt
deleted file mode 100644
index f886bdfb5..000000000
--- a/lib/wind/rfc4518.txt
+++ /dev/null
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        K. Zeilenga
-Request for Comments: 4518                           OpenLDAP Foundation
-Category: Standards Track                                      June 2006
-
-
-             Lightweight Directory Access Protocol (LDAP):
-                  Internationalized String Preparation
-
-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 (2006).
-
-Abstract
-
-   The previous Lightweight Directory Access Protocol (LDAP) technical
-   specifications did not precisely define how character string matching
-   is to be performed.  This led to a number of usability and
-   interoperability problems.  This document defines string preparation
-   algorithms for character-based matching rules defined for use in
-   LDAP.
-
-1.  Introduction
-
-1.1.  Background
-
-   A Lightweight Directory Access Protocol (LDAP) [RFC4510] matching
-   rule [RFC4517] defines an algorithm for determining whether a
-   presented value matches an attribute value in accordance with the
-   criteria defined for the rule.  The proposition may be evaluated to
-   True, False, or Undefined.
-
-      True      - the attribute contains a matching value,
-
-      False     - the attribute contains no matching value,
-
-      Undefined - it cannot be determined whether the attribute contains
-                  a matching value.
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 1]
-
-RFC 4518       LDAP: Internationalized String Preparation      June 2006
-
-
-   For instance, the caseIgnoreMatch matching rule may be used to
-   compare whether the commonName attribute contains a particular value
-   without regard for case and insignificant spaces.
-
-1.2.  X.500 String Matching Rules
-
-   "X.520: Selected attribute types" [X.520] provides (among other
-   things) value syntaxes and matching rules for comparing values
-   commonly used in the directory [X.500].  These specifications are
-   inadequate for strings composed of Unicode [Unicode] characters.
-
-   The caseIgnoreMatch matching rule [X.520], for example, is simply
-   defined as being a case-insensitive comparison where insignificant
-   spaces are ignored.  For printableString, there is only one space
-   character and case mapping is bijective, hence this definition is
-   sufficient.  However, for Unicode string types such as
-   universalString, this is not sufficient.  For example, a case-
-   insensitive matching implementation that folded lowercase characters
-   to uppercase would yield different results than an implementation
-   that used uppercase to lowercase folding.  Or one implementation may
-   view space as referring to only SPACE (U+0020), a second
-   implementation may view any character with the space separator (Zs)
-   property as a space, and another implementation may view any
-   character with the whitespace (WS) category as a space.
-
-   The lack of precise specification for character string matching has
-   led to significant interoperability problems.  When used in
-   certificate chain validation, security vulnerabilities can arise.  To
-   address these problems, this document defines precise algorithms for
-   preparing character strings for matching.
-
-1.3.  Relationship to "stringprep"
-
-   The character string preparation algorithms described in this
-   document are based upon the "stringprep" approach [RFC3454].  In
-   "stringprep", presented and stored values are first prepared for
-   comparison so that a character-by-character comparison yields the
-   "correct" result.
-
-   The approach used here is a refinement of the "stringprep" [RFC3454]
-   approach.  Each algorithm involves two additional preparation steps.
-
-   a) Prior to applying the Unicode string preparation steps outlined in
-      "stringprep", the string is transcoded to Unicode.
-
-   b) After applying the Unicode string preparation steps outlined in
-      "stringprep", the string is modified to appropriately handle
-      characters insignificant to the matching rule.
-
-
-
-Zeilenga                    Standards Track                     [Page 2]
-
-RFC 4518       LDAP: Internationalized String Preparation      June 2006
-
-
-   Hence, preparation of character strings for X.500 [X.500] matching
-   [X.501] involves the following steps:
-
-      1) Transcode
-      2) Map
-      3) Normalize
-      4) Prohibit
-      5) Check Bidi (Bidirectional)
-      6) Insignificant Character Handling
-
-   These steps are described in Section 2.
-
-   It is noted that while various tables of Unicode characters included
-   or referenced by this specification are derived from Unicode
-   [Unicode] data, these tables are to be considered definitive for the
-   purpose of implementing this specification.
-
-1.4.  Relationship to the LDAP Technical Specification
-
-   This document is an integral part of the LDAP technical specification
-   [RFC4510], which obsoletes the previously defined LDAP technical
-   specification [RFC3377] in its entirety.
-
-   This document details new LDAP internationalized character string
-   preparation algorithms used by [RFC4517] and possible other technical
-   specifications defining LDAP syntaxes and/or matching rules.
-
-1.5.  Relationship to X.500
-
-   LDAP is defined [RFC4510] in X.500 terms as an X.500 access
-   mechanism.  As such, there is a strong desire for alignment between
-   LDAP and X.500 syntax and semantics.  The character string
-   preparation algorithms described in this document are based upon
-   "Internationalized String Matching Rules for X.500" [XMATCH] proposal
-   to ITU/ISO Joint Study Group 2.
-
-1.6.  Conventions and Terms
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in BCP 14 [RFC2119].
-
-   Character names in this document use the notation for code points and
-   names from the Unicode Standard [Unicode].  For example, the letter
-   "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
-   In the lists of mappings and the prohibited characters, the "U+" is
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 3]
-
-RFC 4518       LDAP: Internationalized String Preparation      June 2006
-
-
-   left off to make the lists easier to read.  The comments for
-   character ranges are shown in square brackets (such as "[CONTROL
-   CHARACTERS]") and do not come from the standard.
-
-   Note: a glossary of terms used in Unicode can be found in [Glossary].
-   Information on the Unicode character encoding model can be found in
-   [CharModel].
-
-   The term "combining mark", as used in this specification, refers to
-   any Unicode [Unicode] code point that has a mark property (Mn, Mc,
-   Me).  Appendix A provides a definitive list of combining marks.
-
-2.  String Preparation
-
-   The following six-step process SHALL be applied to each presented and
-   attribute value in preparation for character string matching rule
-   evaluation.
-
-      1) Transcode
-      2) Map
-      3) Normalize
-      4) Prohibit
-      5) Check bidi
-      6) Insignificant Character Handling
-
-   Failure in any step causes the assertion to evaluate to Undefined.
-
-   The character repertoire of this process is Unicode 3.2 [Unicode].
-
-   Note that this six-step process specification is intended to describe
-   expected matching behavior.  Implementations are free to use
-   alternative processes so long as the matching rule evaluation
-   behavior provided is consistent with the behavior described by this
-   specification.
-
-2.1.  Transcode
-
-   Each non-Unicode string value is transcoded to Unicode.
-
-   PrintableString [X.680] values are transcoded directly to Unicode.
-
-   UniversalString, UTF8String, and bmpString [X.680] values need not be
-   transcoded as they are Unicode-based strings (in the case of
-   bmpString, a subset of Unicode).
-
-   TeletexString [X.680] values are transcoded to Unicode.  As there is
-   no standard for mapping TeletexString values to Unicode, the mapping
-   is left a local matter.
-
-
-
-Zeilenga                    Standards Track                     [Page 4]
-
-RFC 4518       LDAP: Internationalized String Preparation      June 2006
-
-
-   For these and other reasons, use of TeletexString is NOT RECOMMENDED.
-
-   The output is the transcoded string.
-
-2.2.  Map
-
-   SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code
-   points are mapped to nothing.  COMBINING GRAPHEME JOINER (U+034F) and
-   VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also
-   mapped to nothing.  The OBJECT REPLACEMENT CHARACTER (U+FFFC) is
-   mapped to nothing.
-
-   CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE
-   TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR)
-   (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020).
-
-   All other control code (e.g., Cc) points or code points with a
-   control function (e.g., Cf) are mapped to nothing.  The following is
-   a complete list of these code points: U+0000-0008, 000E-001F, 007F-
-   0084, 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063,
-   206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F.
-
-   ZERO WIDTH SPACE (U+200B) is mapped to nothing.  All other code
-   points with Separator (space, line, or paragraph) property (e.g., Zs,
-   Zl, or Zp) are mapped to SPACE (U+0020).  The following is a complete
-   list of these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029,
-   202F, 205F, 3000.
-
-   For case ignore, numeric, and stored prefix string matching rules,
-   characters are case folded per B.2 of [RFC3454].
-
-   The output is the mapped string.
-
-2.3.  Normalize
-
-   The input string is to be normalized to Unicode Form KC
-   (compatibility composed) as described in [UAX15].  The output is the
-   normalized string.
-
-2.4.  Prohibit
-
-   All Unassigned code points are prohibited.  Unassigned code points
-   are listed in Table A.1 of [RFC3454].
-
-   Characters that, per Section 5.8 of [RFC3454], change display
-   properties or are deprecated are prohibited.  These characters are
-   listed in Table C.8 of [RFC3454].
-
-
-
-
-Zeilenga                    Standards Track                     [Page 5]
-
-RFC 4518       LDAP: Internationalized String Preparation      June 2006
-
-
-   Private Use code points are prohibited.  These characters are listed
-   in Table C.3 of [RFC3454].
-
-   All non-character code points are prohibited.  These code points are
-   listed in Table C.4 of [RFC3454].
-
-   Surrogate codes are prohibited.  These characters are listed in Table
-   C.5 of [RFC3454].
-
-   The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
-
-   The step fails if the input string contains any prohibited code
-   point.  Otherwise, the output is the input string.
-
-2.5.  Check bidi
-
-   Bidirectional characters are ignored.
-
-2.6.  Insignificant Character Handling
-
-   In this step, the string is modified to ensure proper handling of
-   characters insignificant to the matching rule.  This modification
-   differs from matching rule to matching rule.
-
-   Section 2.6.1 applies to case ignore and exact string matching.
-   Section 2.6.2 applies to numericString matching.
-   Section 2.6.3 applies to telephoneNumber matching.
-
-2.6.1.  Insignificant Space Handling
-
-   For the purposes of this section, a space is defined to be the SPACE
-   (U+0020) code point followed by no combining marks.
-
-       NOTE - The previous steps ensure that the string cannot contain
-              any code points in the separator class, other than SPACE
-              (U+0020).
-
-   For input strings that are attribute values or non-substring
-   assertion values:  If the input string contains no non-space
-   character, then the output is exactly two SPACEs.  Otherwise (the
-   input string contains at least one non-space character), the string
-   is modified such that the string starts with exactly one space
-   character, ends with exactly one SPACE character, and any inner
-   (non-empty) sequence of space characters is replaced with exactly two
-   SPACE characters.  For instance, the input strings
-   "foo<SPACE>bar<SPACE><SPACE>", result in the output
-   "<SPACE>foo<SPACE><SPACE>bar<SPACE>".
-
-
-
-
-Zeilenga                    Standards Track                     [Page 6]
-
-RFC 4518       LDAP: Internationalized String Preparation      June 2006
-
-
-   For input strings that are substring assertion values: If the string
-   being prepared contains no non-space characters, then the output
-   string is exactly one SPACE.  Otherwise, the following steps are
-   taken:
-
-   -  If the input string is an initial substring, it is modified to
-      start with exactly one SPACE character;
-
-   -  If the input string is an initial or an any substring that ends in
-      one or more space characters, it is modified to end with exactly
-      one SPACE character;
-
-   -  If the input string is an any or a final substring that starts in
-      one or more space characters, it is modified to start with exactly
-      one SPACE character; and
-
-   -  If the input string is a final substring, it is modified to end
-      with exactly one SPACE character.
-
-   For instance, for the input string "foo<SPACE>bar<SPACE><SPACE>" as
-   an initial substring, the output would be
-   "<SPACE>foo<SPACE><SPACE>bar<SPACE>".  As an any or final substring,
-   the same input would result in "foo<SPACE>bar<SPACE>".
-
-   Appendix B discusses the rationale for the behavior.
-
-2.6.2.  numericString Insignificant Character Handling
-
-   For the purposes of this section, a space is defined to be the SPACE
-   (U+0020) code point followed by no combining marks.
-
-   All spaces are regarded as insignificant and are to be removed.
-
-   For example, removal of spaces from the Form KC string:
-       "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>"
-   would result in the output string:
-       "123456"
-   and the Form KC string:
-       "<SPACE><SPACE><SPACE>"
-   would result in the output string:
-       "" (an empty string).
-
-2.6.3.  telephoneNumber Insignificant Character Handling
-
-   For the purposes of this section, a hyphen is defined to be a
-   HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010),
-   NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS
-   (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by
-
-
-
-Zeilenga                    Standards Track                     [Page 7]
-
-RFC 4518       LDAP: Internationalized String Preparation      June 2006
-
-
-   no combining marks and a space is defined to be the SPACE (U+0020)
-   code point followed by no combining marks.
-
-   All hyphens and spaces are considered insignificant and are to be
-   removed.
-
-   For example, removal of hyphens and spaces from the Form KC string:
-       "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>"
-   would result in the output string:
-       "123456"
-   and the Form KC string:
-       "<HYPHEN><HYPHEN><HYPHEN>"
-   would result in the (empty) output string:
-       "".
-
-3.  Security Considerations
-
-   "Preparation of Internationalized Strings ("stringprep")" [RFC3454]
-   security considerations generally apply to the algorithms described
-   here.
-
-4.  Acknowledgements
-
-   The approach used in this document is based upon design principles
-   and algorithms described in "Preparation of Internationalized Strings
-   ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet.  Some
-   additional guidance was drawn from Unicode Technical Standards,
-   Technical Reports, and Notes.
-
-   This document is a product of the IETF LDAP Revision (LDAPBIS)
-   Working Group.
-
-5.  References
-
-5.1.  Normative References
-
-   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
-                 Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3454]     Hoffman, P. and M. Blanchet, "Preparation of
-                 Internationalized Strings ("stringprep")", RFC 3454,
-                 December 2002.
-
-   [RFC4510]     Zeilenga, K., "Lightweight Directory Access Protocol
-                 (LDAP): Technical Specification Road Map", RFC 4510,
-                 June 2006.
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 8]
-
-RFC 4518       LDAP: Internationalized String Preparation      June 2006
-
-
-   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
-                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
-                 2006.
-
-   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
-                 3.2.0" is defined by "The Unicode Standard, Version
-                 3.0" (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-
-                 61633-5), as amended by the "Unicode Standard Annex
-                 #27: Unicode 3.1"
-                 (http://www.unicode.org/reports/tr27/) and by the
-                 "Unicode Standard Annex #28: Unicode 3.2"
-                 (http://www.unicode.org/reports/tr28/).
-
-   [UAX15]       Davis, M. and M. Duerst, "Unicode Standard Annex #15:
-                 Unicode Normalization Forms, Version 3.2.0".
-                 <http://www.unicode.org/unicode/reports/tr15/tr15-
-                 22.html>, March 2002.
-
-   [X.680]       International Telecommunication Union -
-                 Telecommunication Standardization Sector, "Abstract
-                 Syntax Notation One (ASN.1) - Specification of Basic
-                 Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
-5.2.  Informative References
-
-   [X.500]       International Telecommunication Union -
-                 Telecommunication Standardization Sector, "The
-                 Directory -- Overview of concepts, models and
-                 services," X.500(1993) (also ISO/IEC 9594-1:1994).
-
-   [X.501]       International Telecommunication Union -
-                 Telecommunication Standardization Sector, "The
-                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
-                 2:1994).
-
-   [X.520]       International Telecommunication Union -
-                 Telecommunication Standardization Sector, "The
-                 Directory: Selected Attribute Types", X.520(1993) (also
-                 ISO/IEC 9594-6:1994).
-
-   [Glossary]    The Unicode Consortium, "Unicode Glossary",
-                 <http://www.unicode.org/glossary/>.
-
-   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
-                 #17, Character Encoding Model", UTR17,
-                 <http://www.unicode.org/unicode/reports/tr17/>, August
-                 2000.
-
-
-
-
-Zeilenga                    Standards Track                     [Page 9]
-
-RFC 4518       LDAP: Internationalized String Preparation      June 2006
-
-
-   [RFC3377]     Hodges, J. and R. Morgan, "Lightweight Directory Access
-                 Protocol (v3): Technical Specification", RFC 3377,
-                 September 2002.
-
-   [RFC4515]     Smith, M., Ed. and T. Howes, "Lightweight Directory
-                 Access Protocol (LDAP): String Representation of Search
-                 Filters", RFC 4515, June 2006.
-
-   [XMATCH]      Zeilenga, K., "Internationalized String Matching Rules
-                 for X.500", Work in Progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 10]
-
-RFC 4518       LDAP: Internationalized String Preparation      June 2006
-
-
-Appendix A.  Combining Marks
-
-   This appendix is normative.
-
-   This table was derived from Unicode [Unicode] data files; it lists
-   all code points with the Mn, Mc, or Me properties.  This table is to
-   be considered definitive for the purposes of implementation of this
-   specification.
-
-         0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1
-         05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670
-         06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A
-         07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963
-         0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7
-         09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D
-         0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD
-         0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57
-         0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03
-         0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83
-         0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03
-         0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA
-         0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A
-         0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19
-         0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97
-         0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714
-         1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9
-         20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23
-         1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B
-         1D1AA-1D1AD
-
-Appendix B.  Substrings Matching
-
-   This appendix is non-normative.
-
-   In the absence of substrings matching, the insignificant space
-   handling for case ignore/exact matching could be simplified.
-   Specifically, the handling could be to require that all sequences of
-   one or more spaces be replaced with one space and, if the string
-   contains non-space characters, removal of all leading spaces and
-   trailing spaces.
-
-   In the presence of substrings matching, this simplified space
-   handling would lead to unexpected and undesirable matching behavior.
-   For instance:
-
-   1) (CN=foo\20*\20bar) would match the CN value "foobar";
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 11]
-
-RFC 4518       LDAP: Internationalized String Preparation      June 2006
-
-
-   2) (CN=*\20foobar\20*) would match "foobar", but
-      (CN=*\20*foobar*\20*) would not.
-
-   Note to readers not familiar with LDAP substrings matching: the LDAP
-   filter [RFC4515] assertion (CN=A*B*C) says to "match any value (of
-   the attribute CN) that begins with A, contains B after A, ends with C
-   where C is also after B."
-
-   The first case illustrates that this simplified space handling would
-   cause leading and trailing spaces in substrings of the string to be
-   regarded as insignificant.  However, only leading and trailing (as
-   well as multiple consecutive spaces) of the string (as a whole) are
-   insignificant.
-
-   The second case illustrates that this simplified space handling would
-   cause sub-partitioning failures.  That is, if a prepared any
-   substring matches a partition of the attribute value, then an
-   assertion constructed by subdividing that substring into multiple
-   substrings should also match.
-
-   In designing an appropriate approach for space handling for
-   substrings matching, one must study key aspects of X.500 case
-   exact/ignore matching.  X.520 [X.520] says:
-
-      The [substrings] rule returns TRUE if there is a partitioning of
-      the attribute value (into portions) such that:
-
-         -  the specified substrings (initial, any, final) match
-            different portions of the value in the order of the strings
-            sequence;
-
-         -  initial, if present, matches the first portion of the value;
-
-         -  final, if present, matches the last portion of the value;
-
-         -  any, if present, matches some arbitrary portion of the
-            value.
-
-   That is, the substrings assertion (CN=foo\20*\20bar) matches the
-   attribute value "foo<SPACE><SPACE>bar" as the value can be
-   partitioned into the portions "foo<SPACE>" and "<SPACE>bar" meeting
-   the above requirements.
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 12]
-
-RFC 4518       LDAP: Internationalized String Preparation      June 2006
-
-
-   X.520 also says:
-
-      [T]he following spaces are regarded as not significant:
-
-         -  leading spaces (i.e., those preceding the first character
-            that is not a space);
-
-         -  trailing spaces (i.e., those following the last character
-            that is not a space);
-
-         -  multiple consecutive spaces (these are taken as equivalent
-            to a single space character).
-
-   This statement applies to the assertion values and attribute values
-   as whole strings, and not individually to substrings of an assertion
-   value.  In particular, the statements should be taken to mean that if
-   an assertion value and attribute value match without any
-   consideration to insignificant characters, then that assertion value
-   should also match any attribute value that differs only by inclusion
-   nor removal of insignificant characters.
-
-   Hence the assertion (CN=foo\20*\20bar) matches
-   "foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values
-   only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal
-   of insignificant spaces.
-
-   Astute readers of this text will also note that there are special
-   cases where the specified space handling does not ignore spaces that
-   could be considered insignificant.  For instance, the assertion
-   (CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>"
-   (insignificant spaces present in value) or " " (insignificant spaces
-   not present in value).  However, as these cases have no practical
-   application that cannot be met by simple assertions, e.g., (cn=\20),
-   and this minor anomaly can only be fully addressed by a preparation
-   algorithm to be used in conjunction with character-by-character
-   partitioning and matching, the anomaly is considered acceptable.
-
-Author's Address
-
-   Kurt D. Zeilenga
-   OpenLDAP Foundation
-
-   EMail: Kurt@OpenLDAP.org
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 13]
-
-RFC 4518       LDAP: Internationalized String Preparation      June 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 14]
-